I made the same recommendation. Sadly the “latest” version in 64 bit only. Unsurprising as it is Debian based.
The older release is still available and still supported though. It would be a great option though the clock is ticking on it of course.
The most “batteries included” distro that is I can think of that is not Debian based is Adelie.
DSL is just AntiX with a curated list of software in a CD image. Just go with AntiX if you want to go that route.
Another option to consider is Q4OS Trinity. Trinity is essentially the KDE 3 desktop which is still surprisingly good and very light on resources.
All of these, including MX Linux, are Debian based and have access to the full Debian repos.
A potential issue with all these Debian based distros though is that Debian itself has moved away from 32 bit in Debian 13. It is hard to say how long these others will stay the course.
Adelie Linux is another one people forget about and certainly worth giving a spin. It is not Debian based.
Tiny Core will be the “fastest” as it runs out of RAM but of course that leaves you even less RAM for other things (like a browser). So it depends on your use case.
Are you sure CachyOS has 32 bit support?
Yes, it is gorgeous
Agreed. That does not change what I said though.
For me, “baloo” is the worst offender.
Also, great to see another btop fan. I use it a lot.
No argument.
I do not see much chance of a middle-man though and the alternative means much less adoption.
My issue is not with Kent’s strong technical opinions. I like those. Well, except that abusing other people as cover for his inability to follow the rules is not cool.
Linus can be a dick but he is typically making technical arguments at least (and usually quite good ones). Kent likes to play the “engineering” card but the drama is always about process, not technology, and he is the one being called out. So trying to pretend he is defending better engineering just makes the behaviour worse.
NVIDIA were breaking the rules (legally even). They have come around.
More big endiian in the kernel for no reason is a negative.
Not sure about the Intel engineer. Linus can be a jerk though so not assuming he was right if I do not know the situation.
And, while I like old hardware, the first x86-64 chips shipped in 2003. So, this is not exactly a Windows 11 situation.
Hardware older than that is going to struggle with modern browsers. A PC from that era would probably have less than 1 GB of RAM and perhaps a max RAM well under 4 GB (the theoretical limit). Using older software versions is probably best anyway.
Ironically, I think it may be because of Skia. So Google.
The replies here make me so mad at Kent Overstreet.
I love bcachefs and was using it on quite a few systems. When it was in the mainline kernel, interest was building. I feel like we could have been just a few months from experimental coming off and adoption skyrocketing.
Then Kent got it pulled from the kernel (so not interested in the “fighting for users” misdirection). Now, as evidenced by the comments here, most users will not touch it.
I needed it in the kernel so I have been migrating away too but it breaks my heart.
I am sure somebody will use it, maybe even more than the small number that have historically. And Kent will probably tell himself that is ok.
It sucks.
Now, I did not write a COW filesystem. So I guess I am getting what I am owed (nothing). That does not dull the sting much though.
It was quite good for a while but I feel like it has crept up again. It is over 1.5G at start for me these days.
It used to be under a gig.
It makes a difference when you only have 8G on a laptop.
Niri is a scrolling tiler. You do not even have to scroll if you really don’t want to.
Niri is absolutely the best tier for a laptop with a smaller screen. It provides all the benefits of tiling without the tiny, cramped windows that tiling tends to result in.
On other tilers, you end up using workspaces for single apps to avoid splitting the screen.
The official statement from the CPC pretty much confirms the culture he is talking about. This statement absolutely drips petty, vindictive, childishness.
“Chris d’Entremont, who established himself a liar after wilfully deceiving his voters, friends and colleagues because he was upset he didn’t get his coveted deputy speaker role, is now spinning more lies after crossing the floor. He will fit in perfectly in the Liberal caucus,” a spokesperson for the Office of the Leader of the Official Opposition (OLO) said in a Sunday morning statement to CBC News.
The industry cannot code safely. There are many reports, studies, and corporate disclosures highlighting that memory related bugs are the primary source of critical security issues in C and C++ code. That is why even NIH companies like Google and Microsoft are adopting Rust in their core products.
That you want to publicly ignore all that evidence to paint it as an individual skill issue does not come across as competent or intelligent. Few of us are going to assume your code is free of these kinds of bugs.
The fact that your have to say it so dismissively makes me think that you know it too.
Yes. There is also a GCC front-end for Rust (does not go to C first).
The timeline is not super abrupt, especially for architectures where all he is asking is to ensure that your Rust toolchain is in order. That is especially true when you consider that Rust is already well maintained on all the Debian architectures that people actually use.
The abruptness (almost rudeness) is in the second part where he basically says that, if you cannot get Rust going in time, you should just stop releasing Debian for that architecture.
It is mostly just poorly worded though. Because none of these architectures have “official” support even now. This will not be the only way they are behind. So, there is not reason to be so dramatic.
And that would be my response to him. Another option here is that these alternative architectures just continue to ship an older version of APT for now. Emergency avoided. Few of them ship with up-to-date versions of APT even now.
Another solution is to use one of the multiple projects that is working to make Rust code build with the GCC compiler back-end. At least one of these projects has already announced that they want to work with these Debian variants to ensure that APT builds with them.
So, the 6 month timeline is a reasonable impetus to make that happen which would be quite a good thing beyond just APT.
There are many other useful tools written in Rust you are going to want to use on these architectures. It will be a fantastic outcome if this pressure from APT kickstarts that happening for some of these long abandoned architectures (by the mainstream at least).
Rust is generally not going to outperform well optimized C code.
That said, it is far easier to write performant Rust code than C code. So, what we see, is that projects that move to Rust frequently see performance gains.
That just means the initial C code was not that great (performance wise). From observation, most C projects are fairly unoptimized.
There is this really strange perception amongst Wayland critics that it had low market share and nobody was using it.
The majority of Linux desktop users are on Wayland and we still have people posting that nobody is using it or even that it “doesn’t work”.
Wayland switched to the default in places where it was already popular and is becoming required in places where few are switching away from the default.
I fully agree with you. I have converted a few “regular user” Windows desktops to LMDE in recent months. They are all quite happy and the “tech support” required has been almost zero.
The OP made “Wayland first” a criteria which disqualifies LMDE as it will default to X11 for perhaps another year.
While I agree with their Wayland comments, I think LMDE (and Mint in general) are great new user distros. Both offer “comfortable” UX for Windows users. A new user probably does not care about Wayland vs X11. Mint has made it clear that the future is Wayland and may even go Wayland by default in 2026 and they will auto migrate users when they do. They are just being conservative in terms of declaring it ready. Is that a bad thing?
Debian has stopped 32 but in Debian 13. He is talking about Debian 12 which is still supported.
The Debian 12 based version of Q4OS has committed to supporting 32 bit through 2028.