I was personally fine with firewalld and AppArmor, rich rules of firewalld are incredibly flexible if you just need it for server usage otherwise nftables all the way through. SELinux can suck a fat fucking dick though, that piece of shit caused me so many headaches and I wished so many times to disable it.
Honestly? Firewalld really isn't
that bad if all you're doing is manually opening/closing ports with
firewall-cmd. It's certainly more verbose than
ufw, but you can learn to live with it. Having lived with Fedora for basically... 5-6 months(?), my biggest gripe with SELinux (at least within a Fedora desktop context) is the fact that the default policy is unintentionally restrictive in the worst fucking ways. I've whinged at length about my audio woes on Linux, the workaround involves a boot override from
hdajackretask, and SELinux prevents the boot override from functioning.
hdajackretask is packaged within the default Fedora repositories; it's not an RPM Fusion package. I have to do some
restorecon shenanigans to adjust the policy to allow that specific boot override to function.
I understand
why SELinux functions the way that it does; it's meant specifically for enterprise/server contexts where the sysadmin in question has control over dozens, if not hundreds of computers. AppArmor doesn't scale cleanly because it's application+path-based, whereas SELinux is file+flag-based. It's 100% rational within that context, but SELinux on any given Fedora desktop version like bringing a fully loaded MK-5 to a paintball fight. The funny thing is that Fedora desktops are incredibly generous with the Firewalld setup, considering how there are tons of ports that are accessible by default. You'd think that the Fedora release engineering committee would get the memo and tweak SELinux to make it bearable for home users and hobbyists, but nope. We get the same fucking policy that ships with RHEL.
Many of the new rust rewrites are MIT-licensed. Which means they move to being proprietary at a later date without consequence.
Theoretically yes. The problem is that the permissive license betrayal shtick only works if the software in question is of exceptional quality, and was authored by someone with actual clout in the world of computer science. Andrew Tanenbaum's MINIX was hijacked by Intel for their Management Engine, much to his own horror, and now it's used as the "premier" example of why permissive licensing is highly flawed. The biggest issue with all these Rust rewrites like
sudo-rs and
uutils is that they're rewrites of non-trivial programs. Honestly? the calculus for a rewrite makes some modicum of sense depending on the context, but the Rustaceans who insist on their way or the highway aren't fucking capable of writing meaningful, battle-tested code. Much less maintaining it over the span of multiple decades.
sudo was already known to be overly complex and
/etc/sudoers being almost impossible to manually edit by hand because of the project's aforementioned complexity. This is 100% valid grounds for a rewrite, and that's precisely why the OpenBSD team wrote
doas and replaced
sudo with it in 2015. The goal was to basically do the same thing as
sudo but with minmaxed LOCs, while also making
/etc/doas.conf much easier to understand and edit than
/etc/sudoers.
doas was ported over to Linux in 2015 (
ArchWiki article), and appending
permit persist setenv {PATH=/usr/local/bin:/usr/local/sbin:/usr/bin:/usr/sbin} :wheel into
/etc/doas.conf basically makes it 1:1 like
sudo where you have sustained root privileges for the next 5 minutes. The best part?
doas is licensed under the ISC License, a permissive software license that's basically equivalent to the MIT/X11/Zlib license.
sudo-rs being licensed under MIT terms doesn't mean jack if it's measurably worse compared to
doas, where the latter was written in C of all things, runs leaner, has a much simpler configuration file, and is basically just as free to appropriate as the former.
coreutils is more contentious because the program's been around for decades, already has tons of optimisations accumulated over that span of time, and is already ubiquitous within the broader Linux ecosystem. Yet it's not perfect; its footprint is huge and doesn't necessarily lend itself well to embedded or otherwise resource-constrained settings. This is a known issue, and workarounds already exist:
busybox being the most popular, and its contentious derivative licensed under permissive terms being
toybox. Alpine is the best example of a non-GNU Linux distribution that functions entirely off
busybox and
musl, but that environment doesn't necessarily lend itself to home computing or even business/enterprise computing at scale.
uutils, when divorced of any abstract promises of memory safety makes sense as a clean rewrite of an otherwise large software project. Unfortunately, its quality is abject dogshit and hasn't improved to an extent that would make it feasible as a drop-in replacement. Even if the project claims that it replicates 75-80% of
coreutils's functionality, it's still not good enough because you still have substantial problems with edge cases with that missing 20% functionality. If it doesn't come within 95% of
coreutils on Day 1 of shipping out as a replacement, it
will piss people off and make them immediately roll back (re: Ubuntu 24.10, 25.04)
Even in the realm of permissive software that's permissively licensed, you have superior alternatives to any Rustware you come across. Amoral corporate psychopaths won't waste their time on troonslop Rustware when they could just turn their eyes over to the BSD realm and interact with them the way they always have.
Rust itself isn't an inherently bad language. Null literally writes tons of Rust code that's already in production here on Kiwi Farms, and he basically justifies it by saying that nothing hurts a trannycel developer more than using their own technology against them. He even has burner accounts on Discord to run for help when troubleshooting obscure issues. RMS literally said that if a Nazi wrote code and licensed it under the GPL, that still counts as free software and the community shouldn't shy away from using it. So why shouldn't the reverse be true?
The biggest issue I have with Rust is the fact that it's basically been around for a decade and change at this point, and it simultaneously wants to be a low-level systems programming language
and a low-floor, high-ceiling multipurpose programming language for user applications and web development. These are two fundamentally incompatible design goals, and the longer Rust tries to do both, the more evident it becomes that it's fundamnetally incapable. Not even capable of doing it poorly, I mean outright incapable. It's been around for a decade, and it
still can't self-bootstrap; it
needs Clang and LLVM. How the hell can you call yourself a low-level programming language if you can't even self-bootstrap? Go came out in 2009, and it was capable of self-bootstrapping in 2015...
right when Rust first made the rounds.
The memory safety is basically the only thing Rustaceans can bring up because that's all they fucking have. Using Rust is like going to a bowling alley and having the rails up to prevent you from gutter balling. To be absolutely fair here: this approach is invaluable within permission-constrained environments like web development, even user applications that don't interact with root/admin privileges whatsoever. For low-level contexts, you need to deliberately flout the guardrails with
unsafe, which theoretically is acceptable but practically unacceptable to the broader Rust community. If you admit to using
unsafe, you get told that you're doing it wrong,
even if you specifically need to invoke unsafe to do what you need to do.
Furthermore, the memory safety argument is fucking bullshit when you realise that there's far more pressing categories of bugs that
don't emerge from memory issues. Y'know what's far more commonplace? Programmer error when they're hundreds if not thousands of LOCs deep into a codebase, and they do something they shouldn't have because their focus was diminishing for that little moment right there. Human error has an uncanny ability to manifest regardless of how many guardrails you put into place, and I'm sick and tired of Rustaceans pretending that it isn't the case. Why care about optimising your code to not consume so much fucking RAM because oh it's all memory safe anyway because you wrote it in Rust? Why care about how many dependencies you're pulling in through cargo because oh hey, they write it all in Rust too and it's all memory safe and nothing bad ever happens? Spoiler alert: your standalone Rust code could be immaculate and you'll still fuck up by pulling in something from cargo that was compromised without you ever fucking knowing it.
If Rust specifically picked a lane, like going all-in on memory safe user+web application development
or going all-in on low level yet categorically unsafe code, if it was capable of self-bootstrapping, and if the cargo ecosystem wasn't a horrific monstrosity that pulls in packages willy nilly without the user's consent, I'd actually think Rust is a worthwhile language to learn. As it stands? I'm far more inclined to trust C as the standard bearer and immovable titan of software development.
now im curious as to why you prefer sysvinit over literally anything else
sysvinit's problems were already well-documented with plenty of known issues, but there is real value in learning it. Linux from Scratch has simultaneously maintained systemd and sysvinit books for basically a decade at this point. The big differentiator here is that learning Linux within a sysvinit context teaches you how a GNU/Linux distribution is meant to function in the barest of ways possible. Then learning systemd would teach you exactly how vast in scope the project is, and how much functionality got subsumed by it. That's my personal justification for seeing value in it, not
@RACISM's.
ok so to follow up since you disagreed with "users that are looking at alt inits should not go with sysvinit but instead a modern init" familiarity doesn't work there so what's your reason for recommending sysvinit specifically
The alternative init space isn't really promising. sysvinit has the highest pedigree because it was "default" for basically all of GNU/Linux's history until like 2015ish when the broader Linux ecosystem began agglomerating around it. OpenRC can be run as a standalone init system, it works well in that context, but it was originally designed to interface with sysvinit. Still goes without saying that OpenRC is basically your next best bet because Gentoo ships with it and people who've fiddled with Gentoo at any point in their lives will have inevitably heard of it. Anything else is basically an exercise in "how much pain am I willing to inflict on myself for not living with systemd, and going off the beaten path by eschewing OpenRC. runit is technically older than OpenRC, but it never saw any mainstream (or even mainstream-adjacent) adoption before systemd because Canonical's upstart ironically upstaged it in 2006. Both Ubuntu (from 2006-2012) and RHEL (RHEL+CentOS 6.x) shipped with, and maintained upstart for the longest time. If that wasn't bad enough, s6 basically has no notoriety to speak of other than "Oh yeah, Artix gives it an ISO."
Hot take that I'm guessing most disagree with in here but BSD license is my favourite.
You're in good company with me. The GPL is invaluable insofar as maintaining accessibility of the code long-term, but it just attracts the most histrionic freaks. BSD license at least implies you're gonna be using FreeBSD or OpenBSD.
