Also, Ubuntu using a non-GPL licensed userland means they can pull all kinds of tricks to allow more TiVoization in the Linux ecosystem.
Combine this with what Amutable (systemd guys) are building, and you can have monolithic, closed source, non-user-modifiable Linux distributions or flavors.
Ubuntu and companies which embed Linux into their products will love this from a business perspective.
Consider: An end to end signature-enabled, verified, attestable, Linux environment with completely closed source util-linux and userland packages, down to the "ls" and "cd". Deliciously apocalyptic.
We're two stops away from this, and there are no shortage of momentum or funding to enable teh future.
Sure, but util-linux and the BSDs won't suddenly cease to exist. If you don't like what Ubuntu is doing, just don't use it.
And then websites and applications stop working if you're not using a verified, attested, locked-down OS and you're stuck with your nice free software system that will not do your online banking, let you chat with your friends, or access your company resources.
At that point I'll just move into the woods with a typewriter and chat with my friends via HAM radio
Edit: Also, why would some userspace components in a slightly-less-free license cause this to happen? if the powers-that-be want to shut you out of the internet, they can do it now; lots of proprietary software already exists.
Also, why would some userspace components in a slightly-less-free license cause this to happen?
It won't, in itself, but it appears to be yet another little push forward on the slippery slope that probably will end where it appears to inevitably end.
but again, the bsd userspace already has a permissive license. if the mustache twirling villains want to lock down stuff, they can do it now. they don't need any push forward.
Yeah, but people don't really want to use the BSD userspace. A lot of the Linux stuff people want to build on assumes a GNU userland and it's not trivial to build a BSD/Linux that actually does relevant computer stuff.
But in places where that stuff isn't relevant, we already see a lot of locked-down devices like the Nintendo Switch and PlayStation based on BSD precisely because they can leverage free software but still lock it down. macOS with its BSD userland is also kind of like this -- the OS is getting gradually more locked down over time, but the frog boils slowly.
If you tighten the screws too hard and fast then people will scream and yell and maybe leave your business for a competitor -- even though it's technically feasible, that means you can't disallow access to banking websites for generic-browser-on-generic-OS now. But we are, brick by brick, building a foundation where that will seem inevitable.
The argument is basically that making it easier to lock down general purpose computing devices like desktop computers (by, for example, making a non-GPL drop-in replacement for GNU *utils) will eventually aid in making it happen. The powers that be will use tried-and-true arguments about security and think-of-the-kids etc to make it seem like running a mutable, untrusted OS is an unacceptable risk.
>that means you can't disallow access to banking websites for generic-browser-on-generic-OS now. But we are, brick by brick, building a foundation where that will seem inevitable.
If you have too much non-standard stuff going on in your browser or mobile device, this is already happening, to a degree. Not a hard block, but increasing difficulties
People give away their freedoms all the time. Most people are walking around with facebook and tiktok tracking their every move. they don't care.
Some linux users aren't going to stop this sort of thing from happening. If Chase Bank wants to only allow MacOS and Windows 11 computers to access their website, the 1% of their userbase that uses something else isn't going to move the needle, and 99% of their users won't care (or even notice).
If this was going to happen, it would have already happened. The pieces are all there already.
People give away their freedoms all the time. Most people are walking around with facebook and tiktok tracking their every move. they don't care.
This is absolutely true. I'm saying someone should care, because it does matter.
Some linux users aren't going to stop this sort of thing from happening. If Chase Bank wants to only allow MacOS and Windows 11 computers to access their website, the 1% of their userbase that uses something else isn't going to move the needle, and 99% of their users won't care (or even notice).
For some businesses, losing 1% of your customers is actually a lot of customers and a lot of money, and all else being equal they would prefer to not lose them.
If this was going to happen, it would have already happened. The pieces are all there already.
No, they really aren't. Again, it's perhaps technically feasible to flip the switch, but it doesn't make business sense yet.
How many people are doing online banking without running on a fully cryptographically verifiable/attestable OS? This means everyone not using a TPM, Secure Boot, etc. This means grandpa with an old Windows 10 machine or an old Mac that perhaps he should not still be using but he doesn't care, he just wants to pay his bills. I don't have numbers of course but I bet you this starts looking like a hell of a lot more than 1% of the userbase.
There are web APIs for this sort of thing in all major browsers but no one is really using them yet. But they exist for a reason, much like Windows 11 requires a TPM for a reason, and this tech will at some point be deployed for things like online banking. Of course it will.
> If this was going to happen, it would have already happened. The pieces are all there already.
Same things were said for:
- Removal of DRM from music: Happened.
- Age verification in the internet: Happening.
- Locked down personal devices: Happened.
- Total surveillance in cities: Happened.
- Not being able to buy but only rent: Happened in many digital formats.
- Internet activation of software: Happened.
- Tracking individual persons real-time: Happened.
- Browser attestation: Google is trying hard.
- Attestation for Internet Banking: Reality in S. Korea.
This resonates. The after effects of age verification and the general exclusion of freedom loving coders is going to leave me standing here in the tumbleweeds with my 90s toyota and laptop with solar panels and unregulated radio frequencies my only communication with the outside world.
Its like those movies coming true. I've already had casual user accounts frozen just for accessing via VPN, or some other inscrutable reason.
I'm with you and the only solace in this dystopia is the fact that I increasingly feel like I just don't care. I don't really like using computers anymore. I liked them when they represented freedom and creativity.
So fine, exclude me from all your platforms, there's nothing there for me. It's all bad content from bad people (or increasingly: not even people) running on bad software. I'm not giving up my freedom to partake in that, I'd rather just stop using your shit.
(But I would very much like to be able to pay my bills and buy my train tickets, so I'll play your game and have a smartphone. Fine. You win this round.).
I don't use Ubuntu anywhere, so there's no actions I need to take.
> Upstream debian has been much more stable for as long as Ubuntu has existed...
Well, I use Debian before Ubuntu has existed, and it was never unstable to begin with. I understand the value of more eyes looking into something and its advantages, but let's say, Ubuntu has acted with selfish reasons towards Debian in some cases. I personally taken side in one of these debates, even.
Yes, I follow debian-devel, and even leaded a Debian derivative distro for some time.
Meandwhile the Canonical employee who's responsible for some aspects of apt has decided to insert rust code. Because of this, and just this, Debian dropped 4 entire architectures. https://lists.debian.org/debian-devel/2025/10/msg00285.html
>I plan to introduce hard Rust dependencies and Rust code into APT, no earlier than May 2026. This extends at first to the Rust compiler and standard library, and the Sequoia ecosystem. ... If you maintain a port without a working Rust toolchain, please ensure it has one within the next 6 months, or sunset the port. It's important for the project as whole to be able to move forward and rely on modern tools and technologies and not be held back by trying to shoehorn modern software on retro computing devices.
If you think Canonical isn't going to lead Debian around by the nose on this you haven't been paying attention.
```
Rust is already a hard requirement on all Debian release
architectures and ports except for alpha, hppa, m68k, and
sh4 (which do not provide sqv).
```
It seems to me that the APT change was just a nail in the coffin of these older architectures, which would have eventually been sunset anyway, due to sqv not being available. If you really want to run some kind of Linux on these very old machines, godspeed, but you can't expect them to be maintained by a project with it's fingers in so many pies forever.
Look at how the proposal for making netplan the default network manager in Debian went. Not good, from Canonical's perspective.
Making /tmp behave the way systemd guys want also went not according to plan. The behavior is modified somewhat because of the discussion.
Rust's influence doesn't come from Canonical per se, but from its promise to eradicate memory related bugs. The initial hype was off the charts, but it's coming down, and the shortcomings are becoming obvious.
Canonical is trying to affect Debian, that's true, but it's not always a given.
The fact that Canonical has always been happy to ship software that they know fully well shouldn't be shipped doesn't fill me with hope that it will even work decently without causing massive issues to everyone (remember when they started to use pulseaudio? In the end it was such a mess that the solution was to abandon it).
It was rough for a while, but my debian machine still runs pulseaudio and it works pretty well. I agree that ubuntu doesn't do enough testing before releasing stuff, but I am grateful that so many people are willing to grind themselves against the bugs before they hit more conservative distributions
I certainly don't and that's why I'm advocating the userspace shall stay GPL. The freedom has two pillars. Kernel and userspace. If you mow one of the two down, you lose everything.
If we stop fighting for anything just because someone said it's long gone, we'd have nothing.
World's history has changed through wars where some people said that winning [said war] is impossible.
Nothing is set in stone. World is changing more drastically than ever. Assuming that we can't change things or things will stay a certain way is a funny fallacy, at best.
Permanence is an illusion. The pendulum is on the move. It might be moving in a way I don't like, but it can't continue like that forever. I'm just doing what I feel right. I'd rather die trying than regretting that I didn't try.
There's nothing about using permissive licenses that reduces freedom. Even if someone makes a closed fork of some software down the line, the original will always be there and will still be just as free. Comparing permissive licensing to a loss of freedom is not a valid comparison.
> Even if someone makes a closed fork of some software down the line, the original will always be there and will still be just as free.
Like MinIO, Solaris, Elasticsearch, Hashicorp Suite and countless others. The versions before the license changes are healthy as a doornail. You're absolutely right.
Some of them are re-forked, some did not.
Also, sometimes that closed fork is the only viable option, making the hardware it's running on an expensive doornail. I also don't like that.
I remember using SDKs and software forked from open ones with version numbers like "1.8.7-really1.9.0-internal-thishardwareonly-special-3.2.5-unlocked" which only runs on a distro from 2006 when it's full moon on 29th of February, and the sum of digits of the date is divisible by 7 and 11 at the same time.
Can you patch this? I guess you can, but where's the source? I bet somebody deleted it by accident and it's not present anymore.
Permissive licenses don't take away the four freedoms, but add a fifth one. The ability to take the other four away. Without prior notice. This is what I don't like personally.
In short, I don't like doornails which are not actual doornails. Permissive licenses enable that freedom.
History probably says I'm being naive, but I feel like I don't hate this possibility (hear me out!).
Personally, I'd always choose to use a distribution with open source userland packages and utils, but if closed source alternatives exist and conform to the same specifications (i.e. we get "embrace" without the "extend and extinguish") then I don't mind if a company has closed sourced tech, especially if it'll help there business case, potentially boosting funding for open source linux projects.
Maybe that's all naive, I guess we'll find out if ubuntu really do go for more and more closed source options.
I understand the optimism, but after being burned by what Microsoft did to the Linux community for the last 20+ years, I'll just distance myself more from Ubuntu ecosystem.
When you put Snaps, Juju, uutils, etc. as a list, it all smells like a path to lockdown, not dissimilar to what RedHat did with their "unbranded" patches recently (IBM being IBM, which was unsurprising).
Also, remembering how Canonical worked together with Microsoft on some projects like WSL, which felt like "Surrender servers to Linux, and save the Windows desktop by allowing Linux run as a slave inside a VM" type of deal, I do not trust them a bit.
So, Linux is maturing, but it'll also bring a couple of very big cracks through ecosystem, and it'll be noisy and painful. Personally, I'm on Debian for the last 20+ years, and not planning to move anywhere for now.
I understand that there needs to be an economy, but money is not more important than destroying what we're standing on. Let it be physical like our planet, or virtual like the free software and the culture we built around it.
i.e. we get "embrace" without the "extend and extinguish"
This only ever happens when the party trying to EEE is fighting a losing battle. If they have the upper hand, they will always get to the extend and extinguish part. Do we think movements for user freedom have the upper hand right now?
> They used outdated linux (Debian-family) because its lower cost to maintain.
Ubuntu forks Sid, and evolves from there. They don't downstream Debian Stable.
> All around, never use debian-family outside servers. Fedora is the future. Maybe OpenSUSE too. (Note these are not Arch or related to Arch)
Daily driving Debian stable on servers and Testing on desktops for more than two decades. Testing is a rolling distribution and you install it once (ever). The only time I reinstalled it was to migrate to 64 bit architecture back in the day.
Also, considering stable to stable upgrades take 5 minutes, I have no problems with Debian Stable, either.
Fedora is nice, but it's RedHat's lab. While I have nothing against them, it's not user oriented as much as it looks. Debian Testing is much more stable than many (if not almost all) of the alternative distros, and follows versions reasonably well.
IF I want cutting edge, I can go Arch or Gentoo way. Lastly, Debian is an iceberg. Looks simple from outside, and once you start to develop it, you understand why Debian is considered one of the golden standards. The underbelly is a rich ecosystem of very well designed yet simple subsystems.
>> All around, never use debian-family outside servers. Fedora is the future.
That take in of itself also feels... uncommon?
My experience matches yours more or less, I've run both Debian (and their LTS project version at one point) and Ubuntu LTS on my servers, both have been generally okay, albeit with a snag or two along the way.
Aside from a few cases of not-very-serious configurations with off the shelf hardware having issues that I get to write the occasional rant about (back when I had an "Everything is broken" section in my blog), it's been surprisingly stable otherwise.
I've had far more issues with RHEL-compatible distros (hate that they killed CentOS, Oracle Linux is sometimes weird but kinda works, outside of work stuff I'd personally reach for Rocky Linux which is a nicer experience) both when it comes to running stuff like Docker (way before Podman was even stable, RHEL-compatibles didn't play nicely with Docker when it came to SELinux and networking) and also support for slightly more uncommon consumer hardware, like my netbook touchpad didn't work at all by default on Fedora, but did work on DEB distros.
The 10 year EOL is really nice, though, and if they had something as nice as Proxmox (for free), I'd probably be using RPM distros for my hypervisors right now!
That's also kind of why I think saying that either of those don't have much of a future would be an odd statement - in my experience, both have their occasional issues but are still generally good for desktop and server use cases.
As an addendum, however, snaps suck, viva la Linux Mint for desktop, plus, Cinnamon is a nice desktop and it's still close enough to Ubuntu LTS I run on servers if I ever need that familiarity in regards to packages!
Once upon a time Mandrake was great for consumer hardware, alongside SuSE, both kind of ignored nowadays, then came Ubuntu, which no one apparently should be using.
So we're kind of left out of options, because there is hardly another distro on Distrowatch that has a similar success rate being installed on random laptops that normies want to try GNU/Linux on.
Systemd is just another init system. People said the same thing about how it can exist with other ones in a level playing field.
By the virtue of having some motivated backers, not only they have pushed everyone out from any distro which matters or acts as a root for others, they have formed a neat little company called Amutable which produces tech allowing anyone to lockdown any installation to an immutable, untouchable state.
Yeap, systemd is just another init system existing on a level playing field. They just dare to be successful by tackling problems that people have today over trying to deliver solutions designed in 1989.
> They just dare to be successful by tackling problems that people have today over trying to deliver solutions designed in 1989.
Thanks for your input. Can you please elaborate about these problems a bit more? I'm pretty new on this Linux thing. Using for just 20 years or so, and managing a quite a few hundred servers only. systemd didn't make my life drastically different or smoother.
Oh, I also used to be a tech-lead of a Debian derivative, and also did some country-wide rollouts of the thing we developed, but I'm sure it has no addition to my already extremely limited knowledge of how things work.
Maybe this is because I'm a noob, or not using enough machines, or not have enough downtime, IDK.
Because well funded projects start to hire developers all over the place to add dependencies and it's very difficult to do otherwise when you have an army of salaried people who do that 40h a week.
I've only used GNU/Linux since 2012, but I do think we have to face the fact that there is a fair amount of ~~choice~~ fragmentation in the ecosystem. Deb/RPM/Flatpak/Snap/PKGBUILD/Nix, GNOME/KDE/Cosmic/Cinnamon/Xfce/LXQt/MATE/Budgie/Sway/Hyprland, AppArmor/SELinux, GTK/Qt/Electron/Tauri/WxWidgets there's even distributions which use musl libc instead of GNU libc or non-systemd inits. Sure, you can just pick one and focus on it, but if someone else picks something else then they may need to duplicate some effort to get things working on their preferred setup.
When you put down your project in a sound and standards compliant way, packaging doesn't matter much. RPM and DEB automatically builds your code and packages it. DEB also has a lot of tools which allows you to make sure that everything is done correctly. I'm sure RPM has similar tools, but I didn't use them a lot.
Desktop environment doesn't matter much, because GTK and Qt works on every Linux Desktop. I'm using KDE, but I don't know which tools I use are GTK, which are Qt, etc. Qt and GTK teams collaborate a ton both in window management and desktop underpinnings side. Also there are tons of standards, and things just work if you follow them. Even the standard libraries of programming languages and Linux userland gives the tools to utilize these standards.
C libraries are mostly interoperable. I operate with GNU's C library, but aside from interesting behavioral differences, the API is not different.
If you're not writing daemons, you have no business with your init system in 99% of the cases, unless you want to utilize a special feature of any of them. You can just ship the service files. daemon() function is part of libc, not your init system.
In total, after your code builds, you can add these layers step by step, one at a time, and have a codebase which works everywhere with minimal effort.
Eroding user's rights is good if it means users have fewer choices because choice is bad? I suppose it would mean that resources could concentrate in a smaller, more focused set of software, but I really can't see how that would justify the harm caused.
Just think about how easy it would be though - imagine - one single OS, one single version always immediately up to date, one consistent set of installed software, attestation to ensure no adversaries are attempting to modify or install unsupported software, full accurate and thorough analytics, what a dream...
Yea what a Fall of Rome type dream - just look what happened when people overused a specific measure - we had Crowdstrike with around 8.5 million devices crashed to BSoD.
Identical OS, identical apps, identical updates, identical crashes at same time.
If you centralise then it is not the question "Will?" but "When?" it will fail.
The defining characteristic is that everyone is using it, not that it's your personal ideal operating system. We have a few major players trying to create their version of the one single os. They're already nobodies ideal, and they have the luxury of telling people to go elsewhere if the system isn't right for them. Imagine how much worse it would be if they had to support everything.
> Also, Ubuntu using a non-GPL licensed userland means they can pull all kinds of tricks to allow more TiVoization in the Linux ecosystem.
Can we stop this conspiracy nonsense? They have explicitly stated that licensing was not a motivation, and even if you think they're lying it wouldn't make any sense anyway! No Tivoization is foiled by Coreutils being GPL. That's ridiculous for so many reasons, not least you can just use the BSD versions, as Apple does (and they still release the source code!).
Because GPL doesn't play well with static linking, the new favourite of programming languages rediscovering the pre-1990's ways of most operating systems linkers (aka binders).
The license has been decided way before my time. I am 0 interest in starting a license debate (I care if the license is DFSG - Debian Free Software Guidelines) and spend time on it. I would rather use my limited time to make rust/coreutils ready for production.
From what I understood, they don't "believe" in GPL and don't like the idea of "having to keep it open". They believe in Developer Freedom(TM), not User Freedom(TM), so they don't care whether their code is closed by others or not.
To summarize #834: We don't like GPL. We'll do MIT, thanks.
If they can earn my trust, why not? I'm not a pointlessly stubborn person. I have changed my views in the past, and can certainly change in the future. This my view resulting from my experiences, and jury is still out from my perspective. If you want to trust Canonical and Co., you can. Don't let me stop you.
> They have explicitly stated that licensing was not a motivation, and even if you think they're lying it wouldn't make any sense anyway!
Who prevents forking Ubuntu and taking that extra mile, esp. now we have a company which wants to enable exactly that lockdown?
> No Tivoization is foiled by Coreutils being GPL.
Belts have holes. They can be used to hold or to choke. Adding more holes to a belt allows more different uses.
> That's ridiculous for so many reasons,
Can you give me more reasons to believe me that I'm a tinfoil wearing crazy weirdo?
> not least you can just use the BSD versions, as Apple does (and they still release the source code!).
Same Apple removing any GPLv3 (and possibly GPLv2) tool from their roster in every iteration from their OS. Same Apple which provides no way to verify that what's published is what's running on their hardware. Same Apple which provides SIP to seal their system partitions which can't be modified without breaking tons of guarantees and seals. Same Apple which controls from their processor to software, without any gaps.
Having the source have no meaning there. You can't use that source. You can't modify the machine you use, you can't install any other OS or just test something.
Ubuntu oozes over debian like a parasitic malaise of vile chicanery. Their entire goal is to, essentially, use the work of untold millions, provided for free, to build their own cathedral.
People complain about AWS and others taking OSS projects and profiting wildly off them, but they're all children compared to the machinations of Ubuntu.
It's been this way from the start. The constant conflict of interest, where Ubuntu devs manipulate debian democratic processes, and the inclusion of systemd and its ridiculous swiss-army-knife implementation of an init system and surrounding tools.
You ever see those knives, the huge ones, with a screwdriver, plyers, and 100 other tools on them? Thing is, they're all crap. They work for an odd case, but you always need to reach for a real tool.
That's systemd. Whether systemd-timesync, its dns services, or anything else it does, it's kiddie time. Barely functional, broken in inane ways, and leaving any professional in a situation of endless masking of a myriad of barely cogent and horribly malign services.
We didn't gain anything with systemd, except for an init system 1000 times larger, codebase wise, and a collection of tools you have to replace anyhow.
And now these guys want to do Amutable. I hope they fail, for if they succeed, they will sink us further into this absurd system. Systemd for death. For despair. For dislike. For dumb. For disregard, devilment, debased, disturbed, systemd is all these things, and more, all packaged for you, all presented to you, all given to you, to all of us, dragging us down, destroying us.
If there is an apocalypse, it'll be somehow some bug in systemd that causes it. Nukes will fly due to its broken code, viral containment systems will fail due to buffer overruns in its code, systemd is the end-of-world waiting to happen, its over-complicated, poorly written code a guillotine waiting to fall upon us all.
I run thousands of sysvinit, and thousands of systemd systems.
Which ones, do you think, have the worse record of "something stupid" bringing down a service, a machine, preventing a boot up, you name it, it's systemd.
I swear to God that Trump exists because of systemd somehow. I place all the ills, perils, at the feet of systemd. It represents everything wrong in the tech ecosystem, its tendrils spreading dark, deep disturbing dreams of madness through all it touches.
Just learning how to use systemd, destroys the logic centres of the mind, rendering advocates incapable of productive work.
All wrong and ill that befalls this world, is at its feet.
I suspect through some incomprehensible twist of fate, the entire fabric of the universe may unravel, undoing all that is, and ever was. All lost, all gone, all because of systemd.
I am beginning to suspect I dislike systemd.
(Send $19.95 to my address, if you wish to subscribe to my newsletter, and hear my REAL, UNFILTERED opinions about systemd)
I could have gotten behind the first three paragraphs until you started mentioning systemd. After that everything you've written sounds like the rambling of a crazy person.
systemd won the init system wars because it is pretty damn good from a technical perspective. The competition didn't even try to participate.
>Barely functional, broken in inane ways, and leaving any professional in a situation of endless masking of a myriad of barely cogent and horribly malign services.
Everything you're complaining about was even more true of previous init systems and barely true for systemd at all.
Meanwhile Ubuntu is a garbage fire from a technical perspective. Snaps are garbage and forced down your throat.
systemd won because of politics, and absolutely nothing more. Debian, the root of the most used tree of Linux distros, only adopted systemd due to pressure from Redhat/Gnome, and threats that if it didn't?
Gnome would no longer work on Debian.
Understand, that many of the issues "resolved" by systemd, were redhat issues. And further, not even init issues.
For example, the most predominant being "predictable NIC names", which were already a thing with Debian. Or bootup times, of which Debian had excellent parallelization and boot times of a similar scope to how "fast" systemd was.
There's really nothing good, from a technical perspective, when something is enlarged 1000x the requirement. If you look at the code for sysvinit, it's maybe 10k lines. Systemd is > 1M lines of code, likely approaching 1.5M by now. So I suppose, 100x the size.
It needs to be understood that the more code you have, the more bugs. It's just the way it is. There have been more security issues in core systemd yearly, than sysvinit in its entire lifespan. That's not even systemd's fault, it's just a simple fact, you have more code, you have more bugs.
And when you say "systemd", you're likely referring to all the inane nonsense it does? How broken it is managing mounts, which really isn't an init's job anyhow? Or the absurd nature of having shutdown and startup identical, with automatic ordering, so you end up in all sorts of ridiculous edge cases?
Why would anyone presume that start and stop MUST be mirror images of each other. The very logic is broken, and shows an immense lack of comprehension of how the real world works.
And you speak of "it won" for superior this and that? At the start, it didn't even have an easy way to extend stop time. Hell, even now it just sends SIGTERM and a nanosecond later SIGKILL, as if shutting down a box FAST FAST NOW NOW is more important that data integrity or properly closed tcp connections or processes doing any form of proper cleanup.
The number of mysql/database issues caused by this behaviour in the early days was insane.
Look, I get you like systemd. But it's provided no real value, and certainly, even if there is some? The detractors outweigh it as the sun turns meat to leather.
> There's really nothing good, from a technical perspective, when something is enlarged 1000x the requirement. If you look at the code for sysvinit, it's maybe 10k lines. Systemd is > 1M lines of code, likely approaching 1.5M by now. So I suppose, 100x the size.
The systemd repo is a mono repo for other tools in addition to the init system.
I've heard from many sysadmins and distribution maintainers that systemd has been amazing. We went from ad hoc shell scripts to declarative plain text files. I think that's a huge win.
> We went from ad hoc shell scripts to declarative plain text files. I think that's a huge win.
Current sysadmin and former distro maintainer here, who respectfully disagrees with you and your friends.
Many, if not all software packages followed a well-defined SYS-V service file stub, esp. after so-called "Parallel SYS-V". We were able to order services, define dependencies and deterministically boot systems at the speed of light. Nothing broke, and the systems fully supported "pull the plug if you want, it won't break" promise.
While I don't hate systemd, I don't like its many ways. It's something like X11 before auto-configuring support for me. The less I touch it, less grumpy I am. Technical parts aside, remembering the ugliness surrounding it (people, ecosystem and predatory aspects) makes me really angry sometimes.
The only plus for Amutable, is that it may finally cause a sane systemd fork.
My immense, strong suspicion here, is that they believe they can use their control over the systemd project, to add immense layers of code and change, to support Amutable's needs.
When this happens, there will likely be pushback of some sort. I'm hoping a fork will happen at that time, and even better, hoping that maybe the project can go someplace saner.
Getting rid of all tcp support (eg, systemd providing inetd functionality) from an init system would be an excellent start. The absurdity of pid 1 having networking hooks is absolutely madness.
Splitting start/stop ordering would be an additional benefit.
Removing all daemons, and all support code, and forking them (for legacy support) would be next. No horribly enacted timesyncd, or resolvd.
Dropping the absurd journal and returning to a syslog solution would be next. Literal kiddie town, to have no centralized logging as a default when first created. There are now attempts to entirely re-skin the cat, with systemd-journal-gatewayd, yet every single appliance and piece of hardware supports... that's right, syslog protocol, not systemd's proprietary journalling protocol or formats.
There is so much about systemd that is just about re-writing the entire universe, not for immense gain, not for immense improvement, but instead for the tiniest, smallest shred of edge-case betterment, and meanwhile, creating massive, overwhelming denigration of every other aspect of that same use case.
Has the journal improved anything for anyone, anywhere, in any real, meaningful way? Absolutely not. All searching, etc is available on text files with | grep. Zero improvement.
Has the journal improved performance? No.
And the ridiculous and absurd and inane concept of the journal being removed at each reboot?
It's as if the people writing systemd, had absolutely no real-world experience with servers, maintaining them, or working with them, and simply made design decisions predicated upon rumour, with no actual understanding of edge cases, or why things are, or were, as they are.
--
An example would be some aspects of Hyundais. They are relatively new, in many ways, to much of the market they have entered. Yes, I know, decades may not seem like that, but it is so. And until they stole all of Toyota's QA methods by hiring engineers (which also took all documentation), they were of horrible quality.
That said, I say in one of their newer SUVs, electric, the other day. Their dashboard, down at the bottom, ended in a sharp corner. When I sat in the car, I realised that should I be in an accident, or even brake aggressively, my kneecap would mash into this non-rounded, extremely square, sharp angle. I could literally see my kneecap being sliced/popped off.
This sort of "it's silly to have round everywhere, let's do something new ascetically, and make it a sharp edge down there!", coupled with "There aren't many people 6'3" in S. Korea, so we'll never notice how dangerous this is", is a prime example of this.
The authors had no idea of edge cases, and the litany of bug reports over the last decade has shown all their supposed improvements filed away, as they have basically had to conform to logical design standards, developed by people far wiser than they, over the last half century.
No, someone-new-to-the-entire-unix-ecosystem, the phrase "but we can just" isn't a viable means to determine sensible design methodology.
Go ahead, enact change, just make sure it makes some sense.
b112 wrote a substantial comment already, but I'll give a single line summary:
yes, systemd changed how I manage my systems, but it didn't bring in speed, safety or integration I didn't have before them. Moreover, they brought out secure-boot related shenanigans in house and integrated to everything it touches. Before that the line was drawn at the bootloader.
Combine this with what Amutable (systemd guys) are building, and you can have monolithic, closed source, non-user-modifiable Linux distributions or flavors.
Ubuntu and companies which embed Linux into their products will love this from a business perspective.
Consider: An end to end signature-enabled, verified, attestable, Linux environment with completely closed source util-linux and userland packages, down to the "ls" and "cd". Deliciously apocalyptic.
We're two stops away from this, and there are no shortage of momentum or funding to enable teh future.