Like the author, I am saddened by systemd. I'm not rabidly opposed to it. I use it because Debian uses it and I like debian. And in some ways, I like the consistency better than the plethora of init script/run levels I used to have to deal with. But it does lack (to me) the Unix gestalt of having composable little pieces that could be pretty well put together and are each individually documentable and compose well in conceptual space as well. There was less surprises and nuanced side effects.
As an init manager, systemd is the best thing that has happened to the wider linux ecosystem. Being able to indicate dependencies, document order and being able to let an application tell the init manager it is done and dependents of it can be started makes starting up way better.
I understand the downsides people have of systemd, but I have the feeling the huge upside is often overlooked.
I've worked with init.d style init systems that had those features using special comments and sourced helper functions, but I bet if you wanted to do it all properly you'd end up with something like systemd. Or GNU Shepherd!
It is more than merely an "init manager". And I disagree that it is the best thing ever - it is perfectly possible to operate linux without systemd.
> but I have the feeling the huge upside is often overlooked.
It is fine to objectively compare trade-offs. However had, it has to be a fair comparison; we can not start with "init manager" because systemd does a lot more, so how can a comparison to any software with less code be fair then? runit doesn't do much more than for initializing.
I wholeheartedly I agree with the author and you. It is sad how Linux is incrementally reshaped based on ideas which often betray the original principles that made UNIX, it derivatives, and copies great. But it is on us to create alternatives. It is free software after all.
Great timing this article. I came to HN to escape a frustration point where this blooming script behaves differently when wrapped in a systemd service than when I run it on its own. I suspect there's some systemd punctuatory dance with a throwaway character here or there to semaphore me off to neverneverland. It's so inscrutable sometimes.
As a former hater of systemd it surprises me that people still have this disdain of systemd especially due to the so called "Unix philosophy", which in the Linux world mainly survives due to GNU writing GNUtils a rewriting of the Unix commands.
I remember embracing systemd funny enough due to when I was running alpine as my server and I had to write my own r script and boy did that quickly make me remember the awful times on freebsd debugging sh.
Same for me, I remember trying to configure cron to run a task periodically and it just did not budge. No error but also did not work. Systemd was working on first attempt with basic debugging when timer will be triggered again and what is the log of executed process after it has been triggered. Also manually triggering something to test if command is correct? Awesome.
This is precisely why it is valid to say that systemd doesn't align with the Unix philosophy, and yet it's also valid that many people such as yourself like it.
I don't want my init system to replace cron. I don't want it to manage logging. I don't want it to have any debugging capabilities. All of these things can be done with other programs, arguably in a much more flexible and robust way.
An init system should do one thing (well): manage system services. Within that context, it should start services on boot, keep them running in the background, and allow the user to create, stop, and start services. That's it. And it could be argued that even those responsibilities are too broad for a single program.
So I understand that you and many others like that systemd provides solutions to all of these tasks in an integrated way. But you should also understand that this does in fact go against the Unix philosophy, of small, independent, but composable programs with a single responsibility. It "proposes" alternatives to many other tools for no particular reason, until users are effectively using GNU/systemd/Linux.
And, yes, I know that technically systemd is not a monolith and is composed of many programs, but that is a moot point. It is a single project, maintained by a strongly opinionated team, and given the importance of it, most distros go all-in, so users are strongly recommended, if not forced, to use all of its programs. In many cases it's not even possible to use one individual systemd program idependently from another. This is why systemd is seen as a kraken that takes over the entire system if you do decide to use one part of it.
This shows a lack of understanding. I'll skip repeating the issues with regard to systemd here, so instead on just a few points you mentioned.
- You claim that the Unix philosophy only survives to the GNUtils. Well, that shows to me a lack of understanding what the philosophy is about. Everything is a file is similar to the OOP approach of everything is an object. I recommend watching Ken Thompson when he was young here: https://www.youtube.com/watch?v=tc4ROCJYbm0
It does not capture all the UNIX philosophy but it does extend on the reasons why that philosophy works well. The philosophy is bigger than that of course but it helps serve as a counter-argument.
- The example of "writing your own script" is no different to a non-systemd system. Why would a script work or not work based on systemd? You mention as example FreeBSD debugging a shell script. Well, others use proper languages such as ruby or python. Everything that can be done via systemd I can do without it too and, in fact, have been doing so. Ruby essentially runs my system as the primary layer on everything (granted, it runs Linux, and thus mostly C, and ruby is at the end of the day a syntactic wrapper over C). I never understood why systemd would matter. I read the advertisement of the systemd devs - none of this applied to my use cases, so I never "embraced" systemd, simply because I never needed it. I did point out the increased complexity of it as a negative trade-off and this has been true til this day.
- Former "hater" also implies that criticism is not based on rationale and logic. This is not the case either. It's funny to me how the pro-systemd camp isn't really able to come up with compelling arguments on their own.
I would say your comment either shows a lack of understanding, or that you completely missed the point.
> The example of "writing your own script" is no different to a non-systemd system. Why would a script work or not work based on systemd?
Of course, you can write the service itself in Python or Ruby or whatever regardless the service manager. The point is that with systemd, or upstart, or other service managers like this that make things more declarative (launchd?), you don't have to write a script to manage the service at all.
On systemd, you declare which services yours depend on, how to run it, which user should be used to run your service, and many things are handled for you, including many security mechanisms you don't need to think about and provide further config for this stuff that would be a mess to handle with the traditional way of writing a custom rc script per service.
The problem is not being able to write in languages like ruby or python. It's to have to write something at all.
systemd makes many things declarative that were historically procedural, potentially painful to debug, code.
This eases distro maintenance and I suppose is one of the top reasons most distros adopted it.
wrt the Unix philosophy, discussions about it related to systemd are often (always?) too abstract to be useful, I'd suggest talking about specific problematic points.
It's funny how many people fall in love with the Unix philosophy because they enjoy using an OS with a macrokernel that ships with awk, tar, and find, which they operate with useless uses of cat.
Macrokernel or microkernel or a grain of salt, whatever kernel you use does not matter when it comes to seeing the advantages of 'the *nix philosophy'. As to the 'useless uses of cat' these often make the pipe easier to grasp because the first step is always the same:
(just pointing this out in the hope it can be of interest to someone reading the thread, I don't personally care that much about UUOC - "useless" is quite subjective, one can still reasonably find the cat version more readable).
Oh I don't care: I do it all the time when I compose cli commands. But is it doing one thing, and doing it well, to use `cat – concatenate and print files` to open a file?
I think it's a good example of when it's worth straying from the philosophy.
> But is it doing one thing, and doing it well, to use `cat – concatenate and print files` to open a file?
Yes, it 'prints' the file to stdout which is consumed by the pipe and turned into the input for the next command in the pipeline. It doesn't matter whether you're only 'printing' a single file or a bunch of them.
And it numbers empty lines (-b) and non-empty lines (-n) and the end of lines (-E) and elides empty lines (-s) and search-and-replaces tabs (-T) and nonprinting characters (-v)
A kernel is a very special program, and splitting it into individual components would be orthogonal to the Unix philosophy, which is about user space programs. Besides, Linux is quite modular, and only loads what it needs, so the fact that it's monolithic is not a major concern. Yes, it would be better if kernel panics wouldn't impact the system, but nowadays these are very rare, and are usually related to hardware rather than software issues.
As for GNU utils and the examples you mention, those indeed align with the Unix philosophy, which you clearly misunderstand.
I was a UNIX developer (kernel, as well as userland programs like troff) for 7 years, working for the first company to provide commercial support. (Our founder, the former head of the Cornell CompSci department, while at RAND, had them make legal arrangements for Western Electric to provide RAND with a commercial license for $20,000 for the no-support tape that they provided to universities for $300 ... from there the commercial UNIX world took off.) Later I started my Linux life with the Yggdrasil distro, my first of many. Nowadays, in retirement, I do development on WSL on Windows. (Getting a working and convenient emacs environment on it was a bit of effort but now it's how I do all of my editing.)
Why would you not love linux? MacOS is a walled garden that keeps you from running things you wrote on the machine you own, and windows is gestures at everything. What else is there?
Those are solid reasons not to like MacOS and Windows but I'm left without your case for loving Linux. I'm reminded of when people advocate for politicians by attacking their opposition, not by praising their own candidate.
SUSE is using btrfs as the default filesystem in all their offerings. I think that SLES is less widespread than RHEL, but I also think those people at SUSE know what they are doing. It's not like we hear of massive data loss from SLES environments all the time.
Even the much-maligned raid5/6 is basically fine†.
If you're concerned about the write hole, use -m DUP/raid1/raid1c2 instead of -m raid5. Plus raid-stripe-tree†† is coming - didn't check the status of it recently.
Many horror stories are because, while btrfs is fine, the operational model and tooling have some footguns which can cause either straight up data loss (due to operator error, but arguably that's really due to bad UX) or possible-but-hard-to-get-out-of situations.
I use btrfs because using zfs has been painful for me, for two reasons:
- btrfs can "shapeshift": I progressively moved _live_ from 2hdd raid1 to 5hdd raid5 data + raid1c2 meta with varying experiments in between. Probably five or six rebalance to change its shape over the years.
- the zfs module situation: when I tried it, the module silently failed to build properly and this resulted in a broken system til I fixed it; this happened twice over six months. Luckily I anticipated this failure mode and only the data array (not the root fs) was zfs, so I could still boot and login into a full system to fix.
Compared to zfs, btrfs is slow to scrub and rebalance though.
I've lost my laptops SSD (as in: no longer mountable, only got data out of it with some rescue tools) at some point between 2017 and 2020, don't remember when exactly. I've also had a weird experience where a btrfs filesystem formatted on my desktop PC was not mountable on a Raspberry Pi, and vice versa formatted on the Pi was not mountable on the desktop. That didn't instill confidence either.
On the other hand, I've been running a btrfs RAID1 on two HGST datacenter drives for a few years and haven't had issues with that.
I used btrfs for most of the 2010's. I nearly lost some data once, and was able to recover it. Afterwards, I moved to ZFS and never looked back.
btrfs may be great now, and more power to people who use it and are happy. However, I am so used to the ergonomics of ZFS (and zed, and ZFS integrated encryption) that I don't see a reason to migrate back.
for features declared stable it's been an urban legend for a long time.
I use BTRFS in prod since I think 2016 which was also the last year I lost data to an BTRFS Bug
Windows is going downhill in a hurry, while MacOS is stagnated (at best), while Linux is constantly advancing, slowly, maybe sometime the wrong path, but always moving.
When I bought a new Windows 11 machine I foolishly copied over my data from the last machine without doing any research. It was only after I was done that I realized by default Windows copies my user directory to Microsoft's "cloud", so all my tax returns and other personal data are bouncing around Microsoft's servers somewhere. I sure hope their security is good.
By default Windows shows ads in my start menu. It also shows me ads in my notifications. I guess I could understand if it was free, but it's not.
Don't forget forced online account for an offline operating system and the default browser edge sharing all visited full urls with microsoft in the name of smartcreen safe browsing.
- Respect privacy
- Is integrating better AI: no invasive AI, yet available if wanted
- Usability and stability of UI and intefaces
MacOS and BSD [disclaimer: big fan of BSD] are somewhat stagnated. Depending on what you want to do, many open source projects are "linux first" what can be a problem (ask me how I know!)
On my home desktop PC Windows 10 is saying I can't upgrade to Windows 11 and doesn't give any explanation. There's nothing wrong with the machine and I hate Windows 11 anyway (I have to use it on my work laptop) so there is no chance that I will buy a completely new PC just to run Windows 11.
So Linux has always been getting slowly better over the years (I first used it more than 30 years ago) and Windows has been getting a lot worse - so Linux easily wins.
Linux kernel is just waaaaayyyyy better than Windows, at this point. Better hardware support, better stability, more features. And it keeps getting better.
Windows kernel is not _bad_, but it's developed by far fewer people.
Linux also has systemd with its unified system resource management. I can slice and dice my system as I want between containers. Oh, and containers are also awesome (Windows has them, macOS doesn't).
Desktop environments are a matter of personal taste. I like my DE very minimal: status bar, quick launcher panel, and that's it.
That's a curious take. Today's Linux distributions are more reliable than ever with more long-term support than ever.
What changed is that you usually do not run a snowflake anymore which you carefully update to the next version in situ, but some amount of compute and storage. Today everything is blue-green and updates mean deploy, destroy behind a load balancer.
They do. And yes, choosing a good distribution will help.
But the fact that most servers run Linux isn't indicating it's the best choice.
Most desktops run Windows - and this doesn't mean it's the best desktop OS :-)
> But the fact that most servers run Linux isn't indicating it's the best choice
True, but server choice is typically made by professionals, while desktop choice typically isn't. So people measure those two by a (imo correct) double standard
I still think the Cathedral is a better model than the Bazaar when it comes to user facing software. For me, Linux as a server OS is great but as a desktop OS is not so great.
> ... Cathedral is a better model than the Bazaar ...
well, for the desktop possible choices from the `Cathedral` are:
- windows, and
- macos
of late, both seem to have gone in directions that are antithetical to what $random user wants f.e. pushing ai-features, tahoe ui snafu respectively etc. etc.
in `Bazaar` mode, xfce has been an *excellent* choice for quite a while now, and should probably serve `Cathedral` refugees quite well.
all in all, not super convinced of the argument that you seem to be proffering here.
It's already the best OS for development and doesn't even need to do anything to get more appealing whilst Microsoft continues to enshittify Windows 11+ and Apple turns macOS into a locked down iPad.
Even as someone who regularly gets pissed off at some issues that I kept having with Ubuntu. Linux is AMAZING. It's ridiculous that we have a fully functioning open source OS which not only works but is the basis for almost everything that runs a web server.
The experimental flavors are also insane in their creativity. Alpine linux is an entire OS in tens of megabytes. That's crazy!
> The BSDs and the illumos distributions generally follow an approach to design and development that aligns more closely with the way I think
My impression has been that Linux is simply better than the BSDs. Now, BSD users may disagree; my point is primarily that Linux is more flexible overall. Take LFS/BLFS - you basically have extensive documention how to adjust Linux. Where is that available for BSD on an equal basis? And that is just one example of many more.
I remember in the past how NetBSD on the mailing list acknowledged that Linux runs on more computers, including the very important toasters, than NetBSD. Momentum means a lot. Top 500 supercomputers run Linux too: https://www.top500.org/statistics/details/osfam/1/
These may all be small reasons but they add up eventually.
> To give an example, I am not against systemd on principle
And it is possible to use Linux without systemd too.
Nobody wants a corporate-controlled project in Linux anyway.
Where does Poettering work? ;)
> Therefore, in certain cases, the GPL becomes a double-edged sword: on one hand, it protects the software and ensures that contributions remain available. On the other, it risks creating a situation where the most "influential" player can totally direct development
But that is possible in the MIT/BSD world too. See Shopify controlling RubyCentral and thus the ruby ecosystem. Money makes the world go round. I don't think this complaint is really down to the GPL. The GPL is strict; it ensures that corporations need to open up their own modifications.
> And so yes, despite all this, I (still) love Linux.
I don't have any "love" for Linux as such. I simply think it is a good operating system. It is also a tinker-friendly operating system. I significantly prefer ruby as such; I also would not say I "love" ruby, but ruby is a very well-designed language (even ignoring the meta-influence by the shopify overlord). At the end of the day, though, these are just tools. They do things. They ideally help save time and cost. Having the same in the Windows world is not really possible, not even via WSL. WSL just makes windows suck less but windows still sucks immensely; I know because I also use windows almost daily. And I use ruby there too, which makes windows suck less, but it's not a great experience compared to linux.
> Because it has been my life companion for 30 years and has contributed significantly to putting food on the table and letting me sleep soundly. Because it allowed me to study without spending insane amounts on licenses or manuals. Because it taught me, first, to think outside the box. To be free.
> So thank you, GNU/Linux.
It's a strange summary to me. I also call Linux just Linux, without the prefaced GNU. I understand RMS; I just don't think you need to fight in an ideological way. Let the facts and advantages speak for themselves - that suffices. And pick the right licence too. But ... "life companion"? What does that even mean? And what does "to be free" even mean? You still depend on code written by other people. So you depend on those people too. It's better than depending on Microsoft, but I don't fully understand that blog entry really.
Like the author, I am saddened by systemd. I'm not rabidly opposed to it. I use it because Debian uses it and I like debian. And in some ways, I like the consistency better than the plethora of init script/run levels I used to have to deal with. But it does lack (to me) the Unix gestalt of having composable little pieces that could be pretty well put together and are each individually documentable and compose well in conceptual space as well. There was less surprises and nuanced side effects.
As an init manager, systemd is the best thing that has happened to the wider linux ecosystem. Being able to indicate dependencies, document order and being able to let an application tell the init manager it is done and dependents of it can be started makes starting up way better.
I understand the downsides people have of systemd, but I have the feeling the huge upside is often overlooked.
I've worked with init.d style init systems that had those features using special comments and sourced helper functions, but I bet if you wanted to do it all properly you'd end up with something like systemd. Or GNU Shepherd!
It is more than merely an "init manager". And I disagree that it is the best thing ever - it is perfectly possible to operate linux without systemd.
> but I have the feeling the huge upside is often overlooked.
It is fine to objectively compare trade-offs. However had, it has to be a fair comparison; we can not start with "init manager" because systemd does a lot more, so how can a comparison to any software with less code be fair then? runit doesn't do much more than for initializing.
> As an init manager,
The objection to it is not to it as an init manager. To quote the description from the systemd site:
> systemd is a suite of basic building blocks for a Linux system
I wholeheartedly I agree with the author and you. It is sad how Linux is incrementally reshaped based on ideas which often betray the original principles that made UNIX, it derivatives, and copies great. But it is on us to create alternatives. It is free software after all.
Great timing this article. I came to HN to escape a frustration point where this blooming script behaves differently when wrapped in a systemd service than when I run it on its own. I suspect there's some systemd punctuatory dance with a throwaway character here or there to semaphore me off to neverneverland. It's so inscrutable sometimes.
Is Devuan not an option? It's explicitly advertised as Debian without systemd.
As a former hater of systemd it surprises me that people still have this disdain of systemd especially due to the so called "Unix philosophy", which in the Linux world mainly survives due to GNU writing GNUtils a rewriting of the Unix commands.
I remember embracing systemd funny enough due to when I was running alpine as my server and I had to write my own r script and boy did that quickly make me remember the awful times on freebsd debugging sh.
Same for me, I remember trying to configure cron to run a task periodically and it just did not budge. No error but also did not work. Systemd was working on first attempt with basic debugging when timer will be triggered again and what is the log of executed process after it has been triggered. Also manually triggering something to test if command is correct? Awesome.
That seems to me a complaint about cron. I always used ruby to schedule tasks instead.
One does not need cron or systemd for scheduling tasks.
What tool do you use to schedule tasks?
Have you written your own Cron in Ruby?
This is precisely why it is valid to say that systemd doesn't align with the Unix philosophy, and yet it's also valid that many people such as yourself like it.
I don't want my init system to replace cron. I don't want it to manage logging. I don't want it to have any debugging capabilities. All of these things can be done with other programs, arguably in a much more flexible and robust way.
An init system should do one thing (well): manage system services. Within that context, it should start services on boot, keep them running in the background, and allow the user to create, stop, and start services. That's it. And it could be argued that even those responsibilities are too broad for a single program.
So I understand that you and many others like that systemd provides solutions to all of these tasks in an integrated way. But you should also understand that this does in fact go against the Unix philosophy, of small, independent, but composable programs with a single responsibility. It "proposes" alternatives to many other tools for no particular reason, until users are effectively using GNU/systemd/Linux.
And, yes, I know that technically systemd is not a monolith and is composed of many programs, but that is a moot point. It is a single project, maintained by a strongly opinionated team, and given the importance of it, most distros go all-in, so users are strongly recommended, if not forced, to use all of its programs. In many cases it's not even possible to use one individual systemd program idependently from another. This is why systemd is seen as a kraken that takes over the entire system if you do decide to use one part of it.
This shows a lack of understanding. I'll skip repeating the issues with regard to systemd here, so instead on just a few points you mentioned.
- You claim that the Unix philosophy only survives to the GNUtils. Well, that shows to me a lack of understanding what the philosophy is about. Everything is a file is similar to the OOP approach of everything is an object. I recommend watching Ken Thompson when he was young here: https://www.youtube.com/watch?v=tc4ROCJYbm0
It does not capture all the UNIX philosophy but it does extend on the reasons why that philosophy works well. The philosophy is bigger than that of course but it helps serve as a counter-argument.
- The example of "writing your own script" is no different to a non-systemd system. Why would a script work or not work based on systemd? You mention as example FreeBSD debugging a shell script. Well, others use proper languages such as ruby or python. Everything that can be done via systemd I can do without it too and, in fact, have been doing so. Ruby essentially runs my system as the primary layer on everything (granted, it runs Linux, and thus mostly C, and ruby is at the end of the day a syntactic wrapper over C). I never understood why systemd would matter. I read the advertisement of the systemd devs - none of this applied to my use cases, so I never "embraced" systemd, simply because I never needed it. I did point out the increased complexity of it as a negative trade-off and this has been true til this day.
- Former "hater" also implies that criticism is not based on rationale and logic. This is not the case either. It's funny to me how the pro-systemd camp isn't really able to come up with compelling arguments on their own.
> This shows a lack of understanding.
I would say your comment either shows a lack of understanding, or that you completely missed the point.
> The example of "writing your own script" is no different to a non-systemd system. Why would a script work or not work based on systemd?
Of course, you can write the service itself in Python or Ruby or whatever regardless the service manager. The point is that with systemd, or upstart, or other service managers like this that make things more declarative (launchd?), you don't have to write a script to manage the service at all.
On systemd, you declare which services yours depend on, how to run it, which user should be used to run your service, and many things are handled for you, including many security mechanisms you don't need to think about and provide further config for this stuff that would be a mess to handle with the traditional way of writing a custom rc script per service.
The problem is not being able to write in languages like ruby or python. It's to have to write something at all.
systemd makes many things declarative that were historically procedural, potentially painful to debug, code.
This eases distro maintenance and I suppose is one of the top reasons most distros adopted it.
wrt the Unix philosophy, discussions about it related to systemd are often (always?) too abstract to be useful, I'd suggest talking about specific problematic points.
> ruby is at the end of the day a syntactic wrapper over C
No.
It's funny how many people fall in love with the Unix philosophy because they enjoy using an OS with a macrokernel that ships with awk, tar, and find, which they operate with useless uses of cat.
Macrokernel or microkernel or a grain of salt, whatever kernel you use does not matter when it comes to seeing the advantages of 'the *nix philosophy'. As to the 'useless uses of cat' these often make the pipe easier to grasp because the first step is always the same:
instead of especially when confronted with filters which need their input to be fed in different ways It may be less 'pure' to use cat as the first step in a pipe but who cares?You can keep the order of things even if you want to avoid using cat:
(just pointing this out in the hope it can be of interest to someone reading the thread, I don't personally care that much about UUOC - "useless" is quite subjective, one can still reasonably find the cat version more readable).Oh I don't care: I do it all the time when I compose cli commands. But is it doing one thing, and doing it well, to use `cat – concatenate and print files` to open a file?
I think it's a good example of when it's worth straying from the philosophy.
> But is it doing one thing, and doing it well, to use `cat – concatenate and print files` to open a file?
Yes, it 'prints' the file to stdout which is consumed by the pipe and turned into the input for the next command in the pipeline. It doesn't matter whether you're only 'printing' a single file or a bunch of them.
And it numbers empty lines (-b) and non-empty lines (-n) and the end of lines (-E) and elides empty lines (-s) and search-and-replaces tabs (-T) and nonprinting characters (-v)
A kernel is a very special program, and splitting it into individual components would be orthogonal to the Unix philosophy, which is about user space programs. Besides, Linux is quite modular, and only loads what it needs, so the fact that it's monolithic is not a major concern. Yes, it would be better if kernel panics wouldn't impact the system, but nowadays these are very rare, and are usually related to hardware rather than software issues.
As for GNU utils and the examples you mention, those indeed align with the Unix philosophy, which you clearly misunderstand.
I was a UNIX developer (kernel, as well as userland programs like troff) for 7 years, working for the first company to provide commercial support. (Our founder, the former head of the Cornell CompSci department, while at RAND, had them make legal arrangements for Western Electric to provide RAND with a commercial license for $20,000 for the no-support tape that they provided to universities for $300 ... from there the commercial UNIX world took off.) Later I started my Linux life with the Yggdrasil distro, my first of many. Nowadays, in retirement, I do development on WSL on Windows. (Getting a working and convenient emacs environment on it was a bit of effort but now it's how I do all of my editing.)
I spent a day fixing an important server in a DataCenter because of the tight coupling between SystemD and the Kernel version.
What a mess.
Why would you not love linux? MacOS is a walled garden that keeps you from running things you wrote on the machine you own, and windows is gestures at everything. What else is there?
Those are solid reasons not to like MacOS and Windows but I'm left without your case for loving Linux. I'm reminded of when people advocate for politicians by attacking their opposition, not by praising their own candidate.
From the blog post:
> Even if your btrfs, after almost 18 years, still eats data in spectacular fashion.
Is this (by now) an urban legend ? Is btrfs any less reliable than, say, xfs/ext4 etc. nowadays ?
SUSE is using btrfs as the default filesystem in all their offerings. I think that SLES is less widespread than RHEL, but I also think those people at SUSE know what they are doing. It's not like we hear of massive data loss from SLES environments all the time.
Even the much-maligned raid5/6 is basically fine†.
If you're concerned about the write hole, use -m DUP/raid1/raid1c2 instead of -m raid5. Plus raid-stripe-tree†† is coming - didn't check the status of it recently.
Many horror stories are because, while btrfs is fine, the operational model and tooling have some footguns which can cause either straight up data loss (due to operator error, but arguably that's really due to bad UX) or possible-but-hard-to-get-out-of situations.
I use btrfs because using zfs has been painful for me, for two reasons:
- btrfs can "shapeshift": I progressively moved _live_ from 2hdd raid1 to 5hdd raid5 data + raid1c2 meta with varying experiments in between. Probably five or six rebalance to change its shape over the years.
- the zfs module situation: when I tried it, the module silently failed to build properly and this resulted in a broken system til I fixed it; this happened twice over six months. Luckily I anticipated this failure mode and only the data array (not the root fs) was zfs, so I could still boot and login into a full system to fix.
Compared to zfs, btrfs is slow to scrub and rebalance though.
† https://unixdigest.com/articles/battle-testing-zfs-btrfs-and...
†† https://lore.kernel.org/linux-btrfs/cover.1698679287.git.dst...
I've lost my laptops SSD (as in: no longer mountable, only got data out of it with some rescue tools) at some point between 2017 and 2020, don't remember when exactly. I've also had a weird experience where a btrfs filesystem formatted on my desktop PC was not mountable on a Raspberry Pi, and vice versa formatted on the Pi was not mountable on the desktop. That didn't instill confidence either.
On the other hand, I've been running a btrfs RAID1 on two HGST datacenter drives for a few years and haven't had issues with that.
I used btrfs for most of the 2010's. I nearly lost some data once, and was able to recover it. Afterwards, I moved to ZFS and never looked back.
btrfs may be great now, and more power to people who use it and are happy. However, I am so used to the ergonomics of ZFS (and zed, and ZFS integrated encryption) that I don't see a reason to migrate back.
BTRFS is fine if you use it on enterprise grade hardware, if you use it on consumer hardware expect to lose data.
No, Linux is made of legends that never die.
Traditionally it was btrfs RAID5/6 that really sucked. I've not played with it.
for features declared stable it's been an urban legend for a long time. I use BTRFS in prod since I think 2016 which was also the last year I lost data to an BTRFS Bug
I wouldn't know I've been running ZFS for well over a decade.
Still? Linux is better than ever!
I would argue it's getting better than Windows in relative terms by leaps and bounds. Mostly because Windows is getting worse, but still.
Windows is going downhill in a hurry, while MacOS is stagnated (at best), while Linux is constantly advancing, slowly, maybe sometime the wrong path, but always moving.
In what ways do you think Linux is getting better than Windows? Do you also think Linux is getting better than macOS or FreeBSD?
When I bought a new Windows 11 machine I foolishly copied over my data from the last machine without doing any research. It was only after I was done that I realized by default Windows copies my user directory to Microsoft's "cloud", so all my tax returns and other personal data are bouncing around Microsoft's servers somewhere. I sure hope their security is good.
By default Windows shows ads in my start menu. It also shows me ads in my notifications. I guess I could understand if it was free, but it's not.
And then there's Copilot...
Don't forget forced online account for an offline operating system and the default browser edge sharing all visited full urls with microsoft in the name of smartcreen safe browsing.
Linux > Windows
- Respect privacy - Is integrating better AI: no invasive AI, yet available if wanted - Usability and stability of UI and intefaces
MacOS and BSD [disclaimer: big fan of BSD] are somewhat stagnated. Depending on what you want to do, many open source projects are "linux first" what can be a problem (ask me how I know!)
On my home desktop PC Windows 10 is saying I can't upgrade to Windows 11 and doesn't give any explanation. There's nothing wrong with the machine and I hate Windows 11 anyway (I have to use it on my work laptop) so there is no chance that I will buy a completely new PC just to run Windows 11.
So Linux has always been getting slowly better over the years (I first used it more than 30 years ago) and Windows has been getting a lot worse - so Linux easily wins.
Linux kernel is just waaaaayyyyy better than Windows, at this point. Better hardware support, better stability, more features. And it keeps getting better.
Windows kernel is not _bad_, but it's developed by far fewer people.
Linux also has systemd with its unified system resource management. I can slice and dice my system as I want between containers. Oh, and containers are also awesome (Windows has them, macOS doesn't).
Desktop environments are a matter of personal taste. I like my DE very minimal: status bar, quick launcher panel, and that's it.
It is better since at least 2006, otherwise I'd choose another OS to use since then, and I didn't.
For a desktop experience? Sure! For a server that needs to be supported for many years? Well...
That's a curious take. Today's Linux distributions are more reliable than ever with more long-term support than ever.
What changed is that you usually do not run a snowflake anymore which you carefully update to the next version in situ, but some amount of compute and storage. Today everything is blue-green and updates mean deploy, destroy behind a load balancer.
Well what? Don't most servers run Linux? And support is good assuming you pick a distro that fits
They do. And yes, choosing a good distribution will help. But the fact that most servers run Linux isn't indicating it's the best choice. Most desktops run Windows - and this doesn't mean it's the best desktop OS :-)
Sure, but that's also why I asked you explain your comment.
I've explained it here, even if it's a bit long: https://www.youtube.com/watch?v=UnVp25-6Qao
> But the fact that most servers run Linux isn't indicating it's the best choice
True, but server choice is typically made by professionals, while desktop choice typically isn't. So people measure those two by a (imo correct) double standard
Is this a different timeline where suddenly everything is the other way round?
For desktop? If you not using gnome then yes.
I still think the Cathedral is a better model than the Bazaar when it comes to user facing software. For me, Linux as a server OS is great but as a desktop OS is not so great.
> ... Cathedral is a better model than the Bazaar ...
well, for the desktop possible choices from the `Cathedral` are:
of late, both seem to have gone in directions that are antithetical to what $random user wants f.e. pushing ai-features, tahoe ui snafu respectively etc. etc.in `Bazaar` mode, xfce has been an *excellent* choice for quite a while now, and should probably serve `Cathedral` refugees quite well.
all in all, not super convinced of the argument that you seem to be proffering here.
BSD is given as an example of the cathedral in the book.
It's already the best OS for development and doesn't even need to do anything to get more appealing whilst Microsoft continues to enshittify Windows 11+ and Apple turns macOS into a locked down iPad.
Even as someone who regularly gets pissed off at some issues that I kept having with Ubuntu. Linux is AMAZING. It's ridiculous that we have a fully functioning open source OS which not only works but is the basis for almost everything that runs a web server.
The experimental flavors are also insane in their creativity. Alpine linux is an entire OS in tens of megabytes. That's crazy!
> The BSDs and the illumos distributions generally follow an approach to design and development that aligns more closely with the way I think
My impression has been that Linux is simply better than the BSDs. Now, BSD users may disagree; my point is primarily that Linux is more flexible overall. Take LFS/BLFS - you basically have extensive documention how to adjust Linux. Where is that available for BSD on an equal basis? And that is just one example of many more.
I remember in the past how NetBSD on the mailing list acknowledged that Linux runs on more computers, including the very important toasters, than NetBSD. Momentum means a lot. Top 500 supercomputers run Linux too: https://www.top500.org/statistics/details/osfam/1/
These may all be small reasons but they add up eventually.
> To give an example, I am not against systemd on principle
And it is possible to use Linux without systemd too.
Nobody wants a corporate-controlled project in Linux anyway. Where does Poettering work? ;)
> Therefore, in certain cases, the GPL becomes a double-edged sword: on one hand, it protects the software and ensures that contributions remain available. On the other, it risks creating a situation where the most "influential" player can totally direct development
But that is possible in the MIT/BSD world too. See Shopify controlling RubyCentral and thus the ruby ecosystem. Money makes the world go round. I don't think this complaint is really down to the GPL. The GPL is strict; it ensures that corporations need to open up their own modifications.
> And so yes, despite all this, I (still) love Linux.
I don't have any "love" for Linux as such. I simply think it is a good operating system. It is also a tinker-friendly operating system. I significantly prefer ruby as such; I also would not say I "love" ruby, but ruby is a very well-designed language (even ignoring the meta-influence by the shopify overlord). At the end of the day, though, these are just tools. They do things. They ideally help save time and cost. Having the same in the Windows world is not really possible, not even via WSL. WSL just makes windows suck less but windows still sucks immensely; I know because I also use windows almost daily. And I use ruby there too, which makes windows suck less, but it's not a great experience compared to linux.
> Because it has been my life companion for 30 years and has contributed significantly to putting food on the table and letting me sleep soundly. Because it allowed me to study without spending insane amounts on licenses or manuals. Because it taught me, first, to think outside the box. To be free.
> So thank you, GNU/Linux.
It's a strange summary to me. I also call Linux just Linux, without the prefaced GNU. I understand RMS; I just don't think you need to fight in an ideological way. Let the facts and advantages speak for themselves - that suffices. And pick the right licence too. But ... "life companion"? What does that even mean? And what does "to be free" even mean? You still depend on code written by other people. So you depend on those people too. It's better than depending on Microsoft, but I don't fully understand that blog entry really.