Uh, this blog says “introducing”, but this is hardly new. I have seen this crate around for a while, and https://crates.io/crates/crabtime/versions corroborates that.

Is this an old blog? I can’t find a date on it.

This actually sounds like a good idea.

I strongly disagree. I’m going to quote myself from reddit here:

Why would you expect to be able to use an old compiler and new crates? Shouldn’t you just pin everything to the old versions? The MSRV aware resolver (that we had stably for a year now) makes that seamless. I don’t see why they expect to be able to eat their cake and have it too.

This comes up again and again by LTS fans, be it safety critical or Debian packages. Yet no one have managed to explain why they can’t use a new compiler but can use new crates? Their behaviour lacks consistency.

And from a later reply:

Now if they want to fund the maintenance in question, that is an entirely different question (and would be a net benefit for everyone). But that tends to be quite rare in open source. https://xkcd.com/2347/ very much applies.

I found the discussion quite interesting over all: https://old.reddit.com/r/rust/comments/1qcxa9o/what_does_it_take_to_ship_rust_in_safetycritical/ (it is a shame lemmy is so much less active than reddit still).

I think some fixed-size collections and stuff like that would be super nice in core.

If you don’t mind using a crate: take a look at the well regarded https://lib.rs/crates/heapless (but yeah, having it in core would be nice, but might be too niche).

It isn’t open source, but DaVinci Resolve is available for Linux. With limited features if you don’t pay. Might be overkill for what you do, and I understand it can be finicky to get it working (needs nvidia, poor support for AMD, very limited format support unless you get the paied version, …).

I don’t really do video stuff, but I did play around with it a few years ago, and it seemed very comprehensive.

I don’t use Gnome, but they hate to expose settings in general it seems and like to dumb down everything (and that is why I don’t use it). The issue here is that the you need KDE, Sway, Niri, Xfce, etc all to implement a setting for this. Middle mouse paste is useful and has been standard on Unix-likes for decades. There is literally no reason to remove it.

No, it was your assertion that a wheel being too fiddly. It seemed quite broad (stating it as an universal truth). It might be for you, but not for most people (but you wrote it as an unqualified statement).

Not true, if there is no user visible setting for it. Changing a hidden gsetting via a command line is essentially removing it since it will likely bitrot and then be fully removed in a few years.

For many people this is a non-issue. I think this a case of just accepting we are different and don’t need to force our view on everyone else.

Maybe 15 years ago I had a mouse with a tilting scroll wheel (for side scrolling), on that one I did have issues with middle click, for about a month until I got used to clicking straight down.

So maybe it is just a question of practice? Maybe not. But since both options exist there is no need to get upset.

I ran Gentoo from 2005 to 2009 or so. Took too much time compiling the software, nor doing that again. Apart from that it had some pretty neat ideas.

V2 is about Nehalem. V3 is approximately Haswell (iirc it corresponds to some least common denominator of AMD and Intel from around that time). V4 needs AVX512 (that is really the only difference in enabled instructions compared to V3).

Both my daily driver computers can do v3, but not v4. (I like retro computing, so I also have far older computers that can’t even do 64-bit at all, but I don’t run modern software on those for the most part.)

As far as I know they do a few things (but it is hard to find a comprehensive list), including build packages for newer microarchitectures such as the aforementioned x86-64-v3. The default on x86-64 Linux is still to build programs that work on the original AMD Athlon 64 from the early 2000s. That really doesn’t make sense any more, and v3 is a good default that still covers the last several years of CPUs.

There are many interesting added instructions and for some programs it can make a large difference, but that will vary wildly from program to program. Phoronix has also done some benchmarks of Arch vs Cachy, and since Phoronix Test Suit mostly uses it’s own binaries, what that shows is the difference that the kernel, glibc and system tuning alone makes. And those results do look promising.

I don’t want to spill some memes worth Arch elitism here, but I just doubt Arch derivatives crowd knows what x86-64-v3 thing is. Truth be told, I barely understand that myself.

I think you just did show a lot of elitism and arrogance there. I expect software developers working on any distro to know about this, but not necessarily the users of said distros. (For me, knowing about low level optimisation is part of my dayjob.)

Also, for Cachy in particular they do seem to have some decent developers. One of their devs is the guy who maintains the legacy nvidia drivers on AUR, which involves a fair bit of kernel programming to adapt to changes in new kernel releases (nvidia themselves no longer do so after the first year of drivers becoming legacy).

I too run an Arch and am happy with it, and I would like to know why Cachy. The only reason I can see is having x86-64-v3 packages instead of baseline. That is nice, but on it’s own doesn’t feel worth the effort of switching over.

Defaults don’t matter to me much, as I automate and manage my system config in git (using a tool I wrote myself: https://github.com/VorpalBlade/paketkoll/tree/main/crates/konfigkoll inspired by https://github.com/CyberShadow/aconfmgr). It makes it a breeze to set up a new computer as I want it.

12th verse: I’m sane, I promise

Hmm…

As to LLVM and alloca, it doesn’t optimise or even work well in practise. Some basic cases work, others are less well tested. There are lots of “should” that “doesn’t” in practice in LLVM.

I have not looked at alloca in LLVM myself but from what I have heard from those who are experts on this, it is quite brittle.

Second of all: sub is my favourite allocator

https://docs.rs/bumpalo/latest/bumpalo/ (and bump allocators in general).

Fourth of all: second point is literally a skill issue idk, especially if your compiler is already proving bounds anyway.

In general proving bounds for stack growth is very difficult. With recursion it is undecidable. This follows directly from Rice’s Theorem. (This is my favourite theorem, it is nice to know that something is impossible rather than a skill issue.)

(Of course you could have a static analyser that instead of yes/no returns yes/no/don’t know, and then you assign don’t know to be either of the other classes depending on if you care more about false positives or false negatives. This is how the rust borrow checker works: forbid if it can’t prove it is safe, but there will be safe code that it doesn’t allow.)

Alloca for buffers is generally a bad idea:

• If you have an upper known bound, just use that. If you don’t you risk stack overflow. Especially on a malicious input.
• Alloca optimises poorly (especially with LLVM) since the compiler can’t really see how large the stack frame is.

The only reasonable usage I have seen is in the Swift ABI. See this blog post on the topic by a rust compiler developer: https://faultlore.com/blah/swift-abi/ (and even there it is only for some cases that it can be used).

Not really. Heapless uses compile time sized backing buffers to implement Vec, string etc with a max upper size. You would typically use heapless with a statically allocated variable, but it is possible to use it on the stack too.

Alloca is different and allocates a dynamically sized block on the stack. Rust doesn’t really support alloca, but there is a crate for it that works by calling through a helper function in C: https://lib.rs/crates/alloca

Also worth noting is smallvec and compact_str crates. These are useful when you most of the time have small data that you want inline, but are OK with falling back to heap allocation for the occasional outlier.

I have used both inside structs to optimise cache usage. For these uses i tend to use rather short smallvec.

And smallvec in particular is also useful on the stack in a larger variant in hot functions where you might have a Vec that almost always is less than (say) 32 elements, but the program should gracefully handle the occasional long case. I found this offered a small speed up in some batch data processing code I wrote.

• https://docs.rs/smallvec
• https://docs.rs/compact_str