Can you explain what the examples are showcasing? I looked at the Audio and Webserver examples. They give the LF syntax for doing something that is easier to do directly in Python. I'm missing the advantages of LF and why you'd want to do this in the first place.
One example (Carla) showcases asynchronous components. In a game, you can write a big, single threaded loop, but that means that all components must be ready to produce the next frame, so you either reduce the frame rate to give them more time, or you cut the heavy computational parts. When you run each component asynchronously, e.g. the model might update at a higher rate than the frame renderer, leading to a more accurate simulation, or vice versa, giving a better frame rate when the simulator stutters.
Now think more complex, like a factory. If you run a system with many inputs, distributed to multiple monitors and controllers, this approach looks very interesting. If you want to add some extra monitor, e.g. to compare the output of a controller with some other state, it's really easy to add.
It's not magic, of course. You still need to think about what you're doing...
Have you checked out Pianoteq? It is physical modeling and sounds incredible. It even runs on a RaspberryPi of you want.
When it comes to real instruments, Roland ships physical modeling in some of their instruments. They are a mainstream company.
So I think physical modeling is there but harder to get right than recording samples of piano keys being pressed. The results can be been convincing and it's nice that it requires little memory compared to sample based techniques.
I recall seeing a audio technician test some of the modern VSTs and it seemed extremely impressive to me as an amateur.
It's to the point where you virtually put microphones around the virtual instrument and it behaves (according to the person who does it for a living) creates an intuitively correct sound.
Edit: and to be clear this was a demo from before the LLM times so it's something built the traditional way.
9P is a filesystem protocol (like NFS or CIFS) rather than a local file system (like btrfs or NTFS). It's used to share files between the host and the guest. That way there's no need to copy files between the host and the guest.
Thanks for the clarification and another example of my ignorance about it. The only time I've ever seen it is when I was trying to build a "slender" kernel and I was removing all the stuff I've never used(eg: 9P ).
The only thing I did know about it was that it was named after the movie "Plan 9 from Outer Space". Kinda cool reference.
virt-builder is an alternative to installing a guest OS from scratch. It has a selection of popular guest OSes template images that you can quickly install non-interactively.
It's convenient when you don't want to manually install a guest and also don't want to figure out preseed/kickstart/etc.
It makes creating new KVM guests easier and has handy features like the ability to copy in ssh keys so you can connect to the guest right away.
I think this is a backwards way to set up VMs. "Installing a guest" is the wrong concept. Use a VM image pre-prepared from your favourite distro to skip that step. cloud-init is the standard way for it to specialize to your use case.
> The full build of all Git functionality in Rust is currently around 27M, but since a large part of it is a library, it could clearly be easily split up into domains of functionality - subcrates that do specific things.
I downloaded v0.3.99 for Linux x86_64 and stripped the binary. It ends up at 31 MB. The .text section is 25 MB.
I'm surprised by the large size. On my system /usr/bin/git is 4.7 MB, although git is split up into multiple programs. I'm not comparing apples to apples, but this is weird.
If anyone digs into the binary size, please share what you find.
I haven't dug into this at all yet, nor have I tried to optimize the size (or really, anything else).
However, the library part will be less than half of this - a lot of code is spent on the CLI specific stuff and would not be part of the library, which is mostly what I care about for the purposes of this project. The CLI part is just to try to prove the point that it actually does what Git does. The library part is what might be useful in that nothing else exists that does all of the things that it does (provide a reentrant linkable library that is feature complete with Git).
Looking at just the `grit` executable, 58 of the top 200 largest file->resulting code sources are from clap-rs' derive functionality i.e. it's the command-line parsing. The #1 largest is, surprisingly, merge_trees[1] which comes in at 183kiB final binary size. There isn't so much code in that file that it seems reasonable, so it's potentially one of the derives in use (Debug being a common culprit for bloat) that's blowing it out. After those outliers it starts to level out quickly.
Splitting it by crate: `grit` is 13.6MiB, `grit_lib` is 4.8MiB and then it's `std`, `rustls` and `regex_automata` that are the next largest. So as pure library you could hopefully shave off quite a bit of that 25MiB.
Nice, I haven't dug into this yet. If we can get this usable, it would be pretty cool to have a small lib or a series of much smaller, directed libs that can be used by simpler interfaces and you can just compose the parts you need.
It's a thin HTTP/2 and HTTP/3 tunneling protocol for TCP, UDP, and ICMP traffic.
It should be easy to write an independent implementation based on this specification provided you already have an HTTP/2 or HTTP/3 library. Pretty neat!
More or less, built on top of it with added udp/icmp.
When writing server and client a lot of time is consumed by additional features, not on implementing the spec itself. For instance, in order to be truly stealthy we have to make sure that it looks *exactly* like Chromium on the outside, and then maintain this similarity as Chromium changes TLS implementation from version to version. Or here’s another example: on the server-side we need to have an anti-probing protection to make it harder to detect what the server does.
We support both H2 and H3 and this is necessary. QUIC is not bad, but there are places where it either does not work at all or works too slow.
And one more thing, even though the code and spec is only published now, we’ve been using TrustTunnel for a long time, started before CONNECT_UDP became a thing.
We’re considering switching to it though (or having an option to use it) just to make the server compatible with more clients.
Ah, so you resolve domains before to apply the routes to the profile, I see. As per the spec, network extensions are not allowed to reroute traffic outside the tunnel, destinations set in the tunnel network settings must be routed inside the tunnel. This means that users have to know their domains upfront, the app cannot do this dynamically, if only to comply with apple rules.
Actually, no, we don't resolve them. We scan the incoming ClientHello before making a decision on where to route the connections. If the connection should be bypassed we make a connection by ourselves and proxy traffic. Implementing it that way requires having a TCP stack right in the client.
In Linux (Wayland) you can copy text from the terminal without pressing Ctrl+C at all. Just select the text. To paste it in another Window, press the middle mouse button.
This is called the Primary Selection and is separate from the Clipboard (Ctrl+C/Ctrl+V). IMO the Primary Selection is more convenient than the Clipboard.
That's an X11 thing that Wayland had to reimplement because it's so convenient. The problem is when pasting into the terminal something that another program copied into the clipboard. That's ctrl-shift-c.
I thought about remapping copy and paste to their own keys, possibly a single one. Maybe on the number pad, which I never use. Or remapping ctrl-c.
There's always Ctrl+Insert for copy and Shift+Insert for paste. I know that there's some laptops lacking an insert key, which is terrible, but for keyboard with an insert key the Ctrl/Shift + Insert combos are useful at times.
Especially because one does not have to push three keys with the same hand, which is not nice to tendons. I think I did that for a while time ago, then forgot about it. Thanks.
Yeah I know. I missed this for the first couple days, but didn't take much before forgetting it after the change to Windows. (anyway I keep using Linux at home)
But that doesn't go into clipboard history. And severely restricts what you can do between copying and pasting in general (very importantly makes it a pain to do replace (i.e. select+(implicit-delete+)paste)) as any intermediate selection before pasting destroys your Primary Selection. And if you realize you did that, recopying takes manually reselecting the text, or the otherwise-never-used ctrl+insert to recopy, instead of just repeating the same old ctrl+c as you always do with the clipboard in any sane application.
Of course still a nice option (esp. in terminals where the proper copy/paste are nerfed and selecting for editing is annoyingly not a thing), but far from a replacement for the proper clipboard.
Speaking for myself (although I suspect many others), I haven't used a mouse in well over a decade. To be clear, I am in the terminal all the time. So this is not a universal solution.
There's some secret sauce there I don't know if I'm allowed to talk about yet, so I'll just address the existing tech that we didn't use: most things either didn't have a good enough license, cost too much, would take a TON of ramp-up and expertise we don't currently have to manage and maintain, but generally speaking, our stuff allows us to fully control it.
Entirely programmable storage so far has allowed us to try a few different things to try and make things efficient and give us the features we want. We've been able to try different dedup methods, copy-on-write styles, different compression methods and types, different sharding strategies... All just as a start. We can easily and quickly create a new experimental storage backends and see exactly how pg performs with it side-by-side with other backends.
We're a kubernetes shop, and we have our own CSI plugin, so we can also transparently run a pg HA pair with one pg server using EBS and the other running in our new storage layer, and easily bounce between storage types with nothing but a switchover event.
> would take a TON of ramp-up and expertise we don't currently have to manage and maintain
But you think you have resources to maintain a distributed strongly-consistent replicating block store?
The edge cases in RDB are literally why Ceph takes expertise to manage! Things like failure while recovering from failure while trying to maintain performance are inherently tricky.
I was struck by how similar this seems to Ceph/RADOS/RBD. I.e. how they implemented snapshotted block storage on top, sounds more or less exactly the same as how RBD is implemented on top of RADOS in ceph.
One of the problems with Ceph is that it doesn't operate at the highest possible throughput or the lowest possible latency point.
DAOS seemed promising a couple of years ago. But in terms of popularity it seems to be stuck. No Ubuntu packages, no wide spread deployment, Optane got killed.
Yet the NVMe + metadata approach seemed promising.
Would love to see more databases fork it to do what you need from it.
Or if folks have looked at it and decided not to do it, an analysis of why would be super interesting.
