I knew of joeyh from hn and a previous hn post is how we ended up talking[1].
The episode is a lot about the experience of being in the Debian community in the early days and the experience of being a free software developer, or at least that is the part of of his story that was most interesting to me and that I tried to highlight. How communities form and how they build up a shared understanding and culture is something I'm trying to understand.
Debian is my preferred distribution for servers, I'm simply in awe of what the community has achieved. Most of the good features that people associate with Ubuntu are actually in Debian, with none of the proprietary weirdness that creeps into Ubuntu year over year.
The project does, however, sometimes have its share of people who dogmatic/pedantic to the point where it really doesn't help the cause. This might be expected from something that's a passion project for many of its contributors, and to Debian's credit, they've always been able to resolve these conflicts eventually.
The article mentions the systemd drama. The recent kerfuffle around the 'which' command might be a smaller example of this kind of thing: https://news.ycombinator.com/item?id=29026623 And note: As silly as that discussion was, when it got widespread attention, it was actually already resolved.
Regarding systemd, I'm not sure if majority wanted it.
The fact that it heats the temperature means that it is not true, more like 50/50 are for/against.
I didn't follow this at all at the time and thought it was something like 90% for. Turns out, it was closer to 50/50:
> The vote came down much as expected, with a 4:4 split between systemd and Upstart proponents. Anthony Towns analyzed the votes and declared a tie between systemd and Upstart, which left it up to the chairman to decide by using the casting vote. Garbee did just that, voting for systemd, which makes it the Debian Linux default init for jessie.
I'm very much in the "Thank God"-ish camp (if ya'll welcome others, non denominations & non-believers), but... wouldn't it be interesting if. It's convenient that we've consolidated down, but that famous freedom of choice seems to be circumscribed now by a ellipse with systemd at one focus point, and refusenik shell-script-only minimal pid1s at the other.
Having a more active & ongoing paradigmatic discourse would have been interesting.
So I kind of want a synopsis for upstart. These threads might provide some of that material. I'd touched upstart a couple times back so long ago, & the words "event-based" keep flashing before me, but I don't have much recall on upstart. What was it bad at? What didn't people like? What did people like? What was novel & interesting? What had potential but didn't quite work out? What was the best operational parts of it? There's so much tech in the world that doesn't quite make it, or which did make it & fell (CORBA), & we really need more Speakers For the Dead, people who can try to tell us the story of the tech earnestly, who can help us memorialize something by drawing together as much understanding, from as many points of view as they can.
I've been using Debian for both server and desktop work for years (wow, actually decades) now. I like that I don't have to fiddle with it. Once set up, it just works well, basically forever. No fear of running apt-get dist-upgrade and having to shave yaks for an afternoon getting everything working again. I have no need to live on the bleeding edge of every package update, and not a big fan of some of the choices made by Ubuntu and other Debian-based distributions, so Debian is perfect for me. I didn't even know Drama among the project maintainers existed, so they seem to have managed to keep personnel issues out of the actual software distribution, which is also a bonus.
10x this. Install it. Set autoupdates. Come back in 3 years when it's time to think about upgrading to the next major release. Maybe don't upgrade, because, why? Everything works. I just want to keep things working.
To be honest, Desktops reached their peak for me with Gnome 2. I'm using MATE and I'm good.
> Most of the good features that people associate with Ubuntu are actually in Debian, with none of the proprietary weirdness that creeps into Ubuntu year over year.
A lot of what you find in Debian also comes from what Ubuntu does. In fact, I believe that many people hired by Ubuntu in the early days were experienced maintainers for Debian.
20 years ago, the problem was all about getting Linux consumer desktop friendly. On the server side, it was mostly OK, people there were not afraid of a TTY, because it was the primary entry point to learning Linux, and Unix in general, whereas in the Windows world, people first approach was (and still is) the GUI. Debian wasn't as good as it is today in the desktop area.
Ubuntu appeared on the market mainly to solve that problem (they were not the first ones to do that), and "leverage" on the acquired expertise to make money.
Nowadays, the money is in servers and IoT, so they are focusing to that segment of the market.
The nature of open source meant that of course, Debian benefits from their work.
Personally I'm sad about debian. I've been debian-only user since ca. 2000. It was always the model for a stable, no nonsense distro where everything worked. People complained about slow change but to me that's a huge feature. I want the system to continue working for years, not constantly break with the latest API-breaking updates.
The systemd drama of a few years back really soured me on debian though. On the plus side, it has made me explore OpenBSD and FreeBSD, both of which I use these days. Also I'm using Devuan where I need or want Linux.
Still, I miss having the old debian which eschewed trendiness and valued stability more.
I wouldn't say it's "resolved" quite yet. I just saw the deprecation warning for the first time while using `which` in termux right after running an update.
If you ever read "The Cathedral and the Bazaar"... Debian feels very far from this original vision, endless drama and politics. Similar to Gnome and Mozilla.
There was a proposal, disagreement, and a vote, which ruled in keeping the "which" command where it is for at least the next major version. "which" is in no danger of disappearing at the moment.
The discussion went approximately:
"`which` is nonstandard and doesn't always work the same. Maybe we should remove it and have everybody use `command -v` instead, which is standard. Also, in testing, I've added a deprecation notice to prepare for it."
"Let's have a vote to see. A lot of people use `which`, and that deprecation notice breaks some builds.
...
Vote says no. Remove the deprecation notice and leave `which` where it is for the next release"
Later, on Hacker News: "Debian might be removing "which"! Why are they doing this?"
Most of the commenters, it seems, never actually read the entire story.
It's stupid. An immense and completely unjustified waste of time. which(1) requires maintenance no more than once per decade. In terms of the amount of maintenance that which(1) requires, the entire debate took centuries' worth of the maintainer's time to settle, and much more of everyone else's time. The entire effort to get others to switch from which(1) will take untold amounts of _their_ time.
In conclusion: Debian couldn't care less about their users' time. No respect for the users.
I'm trying to make my real thoughts on this palpable. Idiotic doesn't even begin to cover it.
I think it may benefit to take a step back before assuming bad faith. The issue was (and still is) that "which" is not portable and it's difficult to detect what version you have installed.
Depraved indifference (we don't care how much this will annoy users) rather than bad faith. Given the lack of maintenance burden and the amount of stuff that would break in $bignum scripts, the idea that removing it was seriously even considered speaks volumes.
I'm not sure what "volumes" you're talking about. Those scripts already risk being broken and causing maintenance burden by depending on the non-standard behavior in the first place. If you actually had this specified in your dependencies then it would be easy to spot the necessary change and fix it.
If you want to have intellectually stimulating conversations then please avoid using hyperbole, that's not a way to have a discussion. You can just mention your reasons for disagreeing instead of claiming that a differing view is indefensible.
Actually you may want to take a step back and read some of the comments, the behavior of "which" can be inconsistent even between two systems of the same distribution depending on what shell you are using.
Inspiring interview, as the interviewer says there's a zen about Joey where he's dedicated himself to producing great open source software (git-annex, debhelper, ikiwiki) instead of trying to make millions.
Surely he can look back over the last few decades and feel proud of his work and the benefit it has brought to so many users. The tech treadmill can cause us to lose focus on the things that really matter or that really inspired us to begin with, so this is a refreshing perspective.
1. go ahead and pull that Ethernet cable, your precious networked daemon will restart thus having to lose whatever cached or learned data. This is a major problem for designer of custom daemons.
2. Try and interface with Juniper DHCP servers at major ISP using systemd-networking and /etc/systemd/network settings. You’ll be forced to revert back to ISC DHCP server and/or NetworkManager.
3. Bootup and actually making your IP-address-senstitive daemon croak because your custom Ethernet NIC requires ‘ip addr/link up’ in /etc/rc.local
4. Bootup and get to network-online state only to find out that your netdev really hasn't gotten a dynamic IP address yet, your networked daemon that requires those IP address to be defined on the netdev will croak if not handled properly.
5. You cannot firewall against PID 1.
For UNIX box that are true server or not cloistered behind an ISP-provided gateway/router, that was more than enough to ditch systemd and go Devuan distro.
It sounds like you stopped using Debian. Were you also a contributor and had trouble fixing these issues because of the governance issues described in the article?
precisely. and every six month, Id take a peek to see if RedHat employee or Debian maintainer fixed it.
You cannot operate without systemd in Debian 11+. It’s now a REQUIRED “feature” and a veritable albatross around Debian’s neck for those serious server needs.
Are you sure? I know this is the case for Debian buster (I am using sysvinit on buster on a low-RAM NAS), but on bullseye on my laptop, if I try to install sysvinit & sysv-rc, it wants to remove things like network-manager and lightdm.
Installing openrc doesn't do that, but also doesn't remove any systemd components, so unclear what would happen if I tried to do that.
Yeah but that shouldn't affect your init system. Libsystemd is just a utility library, most of its functions don't require systemd, and the few that do are a no-op when systemd isn't present.
I'm still not sure I understand, what is it you're trying to do exactly? Those other tools should continue to work, systemd will only conflict if you explicitly enable its eBPF stuff.
You firewall against network connections, not against PIDs. What is PID 1 connecting to/accepting connections from that blocking them breaks the system?
A lot of people hate systemd. However as a user who came into Linux after systemd was established. I m pretty happy with it. The more I learn about it and use it the more I appreciate it.
This may be wrong but it feels like people were stuck in a local maximum and don't realize that if they move more than a little from where they were, then they'd actually be in a better place. On the other hand, solving again a problem you 've already solved, is not the most enticing part of the linux experience ;)
I started using Linux professionally on the cusp of the change (RHEL 6 to 7). I've never had any trouble with the init system but journald isn't really my jam, nor is any of the other creeping overcomplexity brought about by systemd's component interdependencies.
In other words: I'm not a fan on ideological grounds but from a practical standpoint it seems to work just fine.
Just like any other complex, tightly-integrated system, systemd had its share of bugs, quirks, and new ways of doing things that forced people to change. It's not hard to imagine why it faced some resistance.
Eh, it's been a while now, though, and I guess most of that has gotten worked out.
> ...It's just that we all have different ideas about what that is.
This in a nutshell is why all progress is always a god awful painful mess. No matter how modest.
I used to be self-proclaimed advocate for change. Technological, organizational, political, all of it. Everyone marching arm-in-arm towards our glorious future.
Now I'm happy when any one manages to change anything at all. I no longer even care how good or bad an idea is. Better to try and then learn from failure than never try at all.
Exactly: Any _individual_ change may or may not be good - but change _in general_ is good, because without it there's no chance of getting better. And any hope of improvement is infinitely better than no hope of improvement.
One of my major objections to systemd is precisely that it sticks us forever at a local maximum, since it ate a bunch of other low-level components, so now if you come up with a superior service manager... good luck; nobody will ever use it since 1. everyone's just decided to support systemd and will never consider an alternative, and 2. you will have to provide replacements for all the other stuff that systemd does. And the continued EEE ensures that it will only get worse.
hard disagree. usually arguments are the other way, that systemd pid1 implies that there's not going to be competition for systemd-timesync or systemd-networkd or systemd-bootd. but none of these fears have panned out: it's easy to drop in other modules in these spots, and there are many offerings still.
and to address this new concern, i dont think replacing systemd would be so hard. and i dont think it would be so difficult to replace systemd init/pid1 while still using other systemd services. systemd is more a mono-repo; there's very little notable hard runtime coupling between the different pieces.
i expressed elsewhere in the comments a sadness that upstarts death has lead us to monoculturism. i do want to see us exploring & trying. but i dont think systemd init/pid1 is deeply rooted, i dont think it's a particularly difficult thing to replace. some not-very-big translation layers will get through 99.9% of what distos actually use, to address point 1. and i simply disagree on point 2..there already are competing offerings and what systemd kffers does not often insist on being run under systemd.
I did. I'm still not happy with the way it was forced in, and how the predictions of teething pains of a from scratch init system being developed by inexperienced developers came true. I still remember the growing pains from PulseAudio, the previous project by the same developers.
But SystemD was a response to the definite problems of past init systems. It might not be the optimal UNIX philosophy architecture, but it's grown into something stable and powerful.
At the end of the day, as a working IT or SWEng professional, you just want to get shit done, so you learn a new abstraction for the zillionth time, put it to practice, and get on with the problem you were trying to solve. Having moved from MS-DOS, to OS/2, to Slackware, to RedHat, then Debian (and staying on Debian for decades, for desktop and server), I trust the Debian devs to put out the most stable and reliable OS I've ever seen.
I don't think it is a lie. If you click "all episodes", it's the last one listed, dated Nov 2 with a "New!" badge. The prior episode was posted october 4th
> I was perfectly happy with systemd myself. I did empathize with people who didn’t like it for whatever reason, but it was clear to me that every Linux distribution except for one or two would be switching to systemd eventually. And I felt that I was pretty good at prognosticating, this kind of thing. So I was, if Debian can’t make the obvious decision without all this much drama, it’s too much for me.
His way is thinking is basically the same as of all Systemd supporters. "I see no problem, it is obvious, everybody is doing it so we will do it sooner or later, anyway."
But this is not, and never has been the point. The crux of the matter was very technical[0]: by gluing GDM to Systemd, the Systemd developers made it very difficult for distributors to support other init systems. They basically forced everybody to switch, and Systemd was not bug-free - it gave sysadmins around the world quite some work, and in some cases, also caused unforeseen problems.
In hindsight, we can see it was unnecessary. Devuan should never have to exist. Debian is offering some support for System V init now. All this drama was completely redundant if someone had not made one controversial architectural decision. Yes, we would have probably transitioned anyway - but on our own terms and at the time we could choose. And Joey would probably be part of Debian still.
[0] Maybe it was also political, but this is beside the point and doesn't change anything.
GDM depends on logind which is normally provided by systemd, but Debian has packaged elogind since the Jessie release in order to support other init systems.
> I did empathize with people who didn’t like it for whatever reason
This is a pretty clear indicator right here that influential people weren't listening on the issue. Any time you state "for whatever reason" is a clear sign you don't care for their reasons.
I've heard quite a lot of these reasons. In my opinion, most of them either come from a place where the person is missing some key piece of information, or their use case was already better served by other tools anyway. So the reasons seem to be not particularly important. If you know something that you think everyone else missed, then you can mention it.
> So the reasons seem to be not particularly important. If you know something that you think everyone else missed, then you can mention it.
Is the existence of Devuan not a good example of a conglomeration of reasons so that I don’t have to spend time doing research for this request you probably don’t want answered? You’re still pushing the reasoning aside and saying “those reasons weren’t good enough so we put them in the whatever catgory”. I understand it’s often easier to hand-wave away well after the fact and the damage has been done. The Debian community didn’t move on from it, it split.
Well no, it's still not entirely clear to me what Devuan does process-wise that is actually different from Debian. I understand that they have a different set of base packages but so does every other modified version of Debian, of which there are several, it's not like Devuan was the first group to split off. What makes this one special? Why are these reasons any more important than any other time somebody shipped a Debian derivative for niche purposes? I honestly don't want to hand wave it away but I've never received good answers for this from Devuan people that themselves weren't hand-wavey, and you don't seem to want to discuss it either so... I guess that answers my question? I don't know, you tell me.
> I understand that they have a different set of base packages but so does every other modified version of Debian, of which there are several, it's not like Devuan was the first group to split off.
So does every other version of Linux. If this enough to dissuade that there is no difference of opinion or difference in values and process handling and isolation then I cannot help you on this topic.
You are misunderstanding, I'm asking what those differences of opinion or values are. That part has not been explained to me. It doesn't appear to be about init systems anymore, because Debian also has sysvinit and openrc and all that stuff.
Edit: Also, the proliferation of Linux distributions is illustrative of the same problem I think. There are a lot of distros out there that seemingly cannot really justify themselves, I've been using Linux for 20 years and for some of these distros it's still really hard for me to figure out what the difference is or why anybody would use it without spending days digging around and analyzing patchsets in random git repositories somewhere. Now just imagine how utterly incomprehensible this is to a non-technical person who doesn't have a clue what an init system is...
TLDR; Debian chose to make room for systemd which broke the Unix compatibility. This decision created a precedent that Unix compatibility was no longer important. Devuan is distro that maintains the init daemon and tooling Unix compatibility promise and freedom as their philosophy titled Init Freedom. You got me to do the research.
From the homepage:
> Devuan GNU+Linux is a fork of Debian without systemd that allows users to reclaim control over their system by avoiding unnecessary entanglements and ensuring Init Freedom.
From the Init Freedom page:
> Init Freedom is about restoring a sane approach to PID1 that respects portability, diversity and freedom of choice.
> Other Free Unices Without systemd
> One of the critical arguments against systemd is the lack of portability to other Unices and the possibility that Linux-based systems using systemd would detach from the UNIX world. OpenBSD, FreeBSD and other BSD OSes are de facto incompatible with systemd or rather, systemd is incompatible with Unices not running Linux.
Sorry I should have been clear. I've already seen all that, I know what the home page says, and I've used Devuan on and off since it was released. That doesn't really do a good job explaining and only seems to confuse the issue because, like I said before, Debian also supports operating without systemd. So it's not obvious what is actually being provided here.
For me, in general it just seems really difficult to justify creating an entirely new Linux distribution because you're waiting for somebody to port a few packages to BSD. That logic doesn't really follow. That's what I meant before, even the Devuan home page has some really hand-wavey and confusing statements.
Sure but the bigger issue was that the actions taken had set precedent that portability can be broken. Once precedent is set, you open up a hole for everybody with reasons to become incompatible. People felt that this precedent was bad for a distro that prides itself on compatibility so they forked.
Whether the results are the same is irrelevant to the difference in approach.
I'm really not sure what you mean, that precedent has existed since the very beginning of BSD when it was forked off from Version 6 Unix and they decided to change some things. There are a ton of other upstream Linux/Solaris/MacOS/whatever packages that don't work well or at all on BSD unless they are ported. That's why every BSD has a "ports" tree...
Edit: I am also even more confused as to what that has to do with init systems because BSD never used a system V style init, whereas Linux distros typically did for that period before systemd. So this stuff wasn't portable anyway. See what I mean that the logic doesn't follow? I really can't understand what someone meant when they wrote that.
I guess just consider it this way: A group broke away, for whatever reasons beyond your understanding and because they broke away and don’t seem to still agree or seem to enjoy being a subset Debian, they continue to exist. Some people find value in this.
Yeah I get that but that's just restating the question. If you just want to look at it from that perspective then they would have found some other reason to break away and find value and there is nothing upstream could have done about it, so complaining about them seems pointless. I'm not saying there's anything morally wrong with it, clearly they can do whatever they like with the open source code that they find on the net. But if it can't be explained simply and easily, maybe it seems there is some value elsewhere that was missed or misunderstood.
To answer this question. This is about base compatibility so ports don’t apply. The ports collection has to be installed separately, hence incompatibility.
I don't understand what you mean base compatibility, a port doesn't happen until some interested party does it. It doesn't actually matter if it's in the ports tree or not, that's just a convenient place for BSD people to put things. Truly "portable" software is a myth, either you are using some abstraction layer that somebody else built, or you put in the work to do a port.
Base compatibility about what’s included in the system when you install it. Since Unix systems have a Unix philosophy they will not use systemd. Ports aren’t included in the base system, there for systemd would not be compatible with a base system that doesn’t include it.
I don't understand what this has to do with the "unix philosophy" or what that is supposed to mean, and the base systems between Devuan and BSD are not compatible anyway. I mentioned that earlier, BSD doesn't use sysvinit...
What's funny is that some of these technical details are irrelevant now (some bugs have been fixed, some components decoupled etc.). But at that particular point in time, you had a very strange situation where one crucial system component was being completely replaced by another without supporting both for an extended period of time. Normally it takes years like with Xorg and Wayland etc. Once the new kid on the block gets mature, everybody is switching anyway. All that drama was totally avoidable with some imagination.
I don't really see how that's the case, systemd was always intentionally backwards compatible with sysvinit scripts. I'm not sure what other issues you're referring to but in most cases it seems one could probably just fall back to a shell script to implement a workaround like it would have been done previously anyway.
"...by gluing GDM to Systemd, the Systemd developers made it very difficult for distributors to support other init systems. They basically forced everybody to switch..."
I'm sorry but I don't buy this, I think you and those sysadmins missed something. The situation with consolekit was so bad that something had to be done about it, if you were blindsided by it, you probably weren't paying attention to that area until it was too late. That's unfortunate but it doesn't really make sense to blame the systemd developers for "making it difficult" when they were the only ones trying to actually solve the problem at that time. IIRC the upstart developers never made progress on this.
I am learning about FreeBSD and its jails system precisely because of systemd. I don't intend to ever again install a systemd based OS for lightweight virtualization.
So in that sense, systemd is helping retain some diversity in Unix like systems...
In my experience Debian has always had it's share of community drama and static. Around 2002 I used to publish a couple of RPMs and since I used to use Debian myself for some of my own servers I decided to publish .debs as well. So some debian folks asked me to "make them official". I found becoming a Debian dev such a pita I just abandoned the attempt. Literally at one point one Debian dev who was a co-worker of mine in real life refused to sign my key because he said "how could he really sure of my identity". Dude, we work together, for a regulated financial institution that does background checks. How could I get away with having some kind of secret identity?
I just decided to avoid the friction and not bother publishing my .debs.
Why didn't you just verify when co-working that yes, you are the one who is asking to have your key signed? Wouldn't that have solved it all in one go?
Usually the verification is as simple as taking a look at the key owner's ID card (Social Security card) or driver license, or any similar legal doc, just to make sure the key owner name matches the real person.
I got my key signed with the same simple procedure. The only troublesome part was to find Debian devs to meet physically, because there were only 3 in where I live (Hong Kong), and only one of them had a valid key (others have expired or just lost keys). Two signatures are needed, so I needed one more. Luckily, I happened had to travel to the US for work, so I solved my problem.
100 comments
[ 2.6 ms ] story [ 141 ms ] threadI knew of joeyh from hn and a previous hn post is how we ended up talking[1].
The episode is a lot about the experience of being in the Debian community in the early days and the experience of being a free software developer, or at least that is the part of of his story that was most interesting to me and that I tried to highlight. How communities form and how they build up a shared understanding and culture is something I'm trying to understand.
https://news.ycombinator.com/item?id=27721883
The project does, however, sometimes have its share of people who dogmatic/pedantic to the point where it really doesn't help the cause. This might be expected from something that's a passion project for many of its contributors, and to Debian's credit, they've always been able to resolve these conflicts eventually.
The article mentions the systemd drama. The recent kerfuffle around the 'which' command might be a smaller example of this kind of thing: https://news.ycombinator.com/item?id=29026623 And note: As silly as that discussion was, when it got widespread attention, it was actually already resolved.
I didn't follow this at all at the time and thought it was something like 90% for. Turns out, it was closer to 50/50:
> The vote came down much as expected, with a 4:4 split between systemd and Upstart proponents. Anthony Towns analyzed the votes and declared a tie between systemd and Upstart, which left it up to the chairman to decide by using the casting vote. Garbee did just that, voting for systemd, which makes it the Debian Linux default init for jessie.
Having a more active & ongoing paradigmatic discourse would have been interesting.
So I kind of want a synopsis for upstart. These threads might provide some of that material. I'd touched upstart a couple times back so long ago, & the words "event-based" keep flashing before me, but I don't have much recall on upstart. What was it bad at? What didn't people like? What did people like? What was novel & interesting? What had potential but didn't quite work out? What was the best operational parts of it? There's so much tech in the world that doesn't quite make it, or which did make it & fell (CORBA), & we really need more Speakers For the Dead, people who can try to tell us the story of the tech earnestly, who can help us memorialize something by drawing together as much understanding, from as many points of view as they can.
The author of systemd addresses this question in the original blog post which announced the systemd project (look under the heading “On Upstart”):
http://0pointer.net/blog/projects/systemd
Upstart is still used by ChromiumOS: https://www.chromium.org/chromium-os/chromiumos-design-docs/...
To be honest, Desktops reached their peak for me with Gnome 2. I'm using MATE and I'm good.
https://wiki.gnome.org/Projects/GnomeFlashback
Same; I've yet to find anything more stable and well put together.
Solution: switch to antiX, MX Linux or Devuan.
A lot of what you find in Debian also comes from what Ubuntu does. In fact, I believe that many people hired by Ubuntu in the early days were experienced maintainers for Debian.
20 years ago, the problem was all about getting Linux consumer desktop friendly. On the server side, it was mostly OK, people there were not afraid of a TTY, because it was the primary entry point to learning Linux, and Unix in general, whereas in the Windows world, people first approach was (and still is) the GUI. Debian wasn't as good as it is today in the desktop area.
Ubuntu appeared on the market mainly to solve that problem (they were not the first ones to do that), and "leverage" on the acquired expertise to make money.
Nowadays, the money is in servers and IoT, so they are focusing to that segment of the market.
The nature of open source meant that of course, Debian benefits from their work.
The systemd drama of a few years back really soured me on debian though. On the plus side, it has made me explore OpenBSD and FreeBSD, both of which I use these days. Also I'm using Devuan where I need or want Linux.
Still, I miss having the old debian which eschewed trendiness and valued stability more.
I am very happy with OpenSuse.
The discussion went approximately:
"`which` is nonstandard and doesn't always work the same. Maybe we should remove it and have everybody use `command -v` instead, which is standard. Also, in testing, I've added a deprecation notice to prepare for it."
"Let's have a vote to see. A lot of people use `which`, and that deprecation notice breaks some builds.
...
Vote says no. Remove the deprecation notice and leave `which` where it is for the next release"
Later, on Hacker News: "Debian might be removing "which"! Why are they doing this?"
Most of the commenters, it seems, never actually read the entire story.
In conclusion: Debian couldn't care less about their users' time. No respect for the users.
I'm trying to make my real thoughts on this palpable. Idiotic doesn't even begin to cover it.
That which(1) is not portable is utter nonsense.
Surely he can look back over the last few decades and feel proud of his work and the benefit it has brought to so many users. The tech treadmill can cause us to lose focus on the things that really matter or that really inspired us to begin with, so this is a refreshing perspective.
1. go ahead and pull that Ethernet cable, your precious networked daemon will restart thus having to lose whatever cached or learned data. This is a major problem for designer of custom daemons.
2. Try and interface with Juniper DHCP servers at major ISP using systemd-networking and /etc/systemd/network settings. You’ll be forced to revert back to ISC DHCP server and/or NetworkManager.
3. Bootup and actually making your IP-address-senstitive daemon croak because your custom Ethernet NIC requires ‘ip addr/link up’ in /etc/rc.local
4. Bootup and get to network-online state only to find out that your netdev really hasn't gotten a dynamic IP address yet, your networked daemon that requires those IP address to be defined on the netdev will croak if not handled properly.
5. You cannot firewall against PID 1.
For UNIX box that are true server or not cloistered behind an ISP-provided gateway/router, that was more than enough to ditch systemd and go Devuan distro.
You cannot operate without systemd in Debian 11+. It’s now a REQUIRED “feature” and a veritable albatross around Debian’s neck for those serious server needs.
Installing openrc doesn't do that, but also doesn't remove any systemd components, so unclear what would happen if I tried to do that.
you just cannot unplug systemd 100% thereby contaminating the disk with useless stuff.
If you could mention these services that require it, we could look at the services and see what needs to be done.
cannot uninstall them.
Most of the issues you raise sound like you simply didn't want to investigate in depth even though you knew you had an exotic setup.
This may be wrong but it feels like people were stuck in a local maximum and don't realize that if they move more than a little from where they were, then they'd actually be in a better place. On the other hand, solving again a problem you 've already solved, is not the most enticing part of the linux experience ;)
In other words: I'm not a fan on ideological grounds but from a practical standpoint it seems to work just fine.
Eh, it's been a while now, though, and I guess most of that has gotten worked out.
It's just that we all have different ideas about what that is.
daemontools-style supervisors are what I prefer, myself. I also acknowledge that there isn't a clear winner in that space.
What I object to are people enforcing systemd by making it a requirement for other projects.
This in a nutshell is why all progress is always a god awful painful mess. No matter how modest.
I used to be self-proclaimed advocate for change. Technological, organizational, political, all of it. Everyone marching arm-in-arm towards our glorious future.
Now I'm happy when any one manages to change anything at all. I no longer even care how good or bad an idea is. Better to try and then learn from failure than never try at all.
and to address this new concern, i dont think replacing systemd would be so hard. and i dont think it would be so difficult to replace systemd init/pid1 while still using other systemd services. systemd is more a mono-repo; there's very little notable hard runtime coupling between the different pieces.
i expressed elsewhere in the comments a sadness that upstarts death has lead us to monoculturism. i do want to see us exploring & trying. but i dont think systemd init/pid1 is deeply rooted, i dont think it's a particularly difficult thing to replace. some not-very-big translation layers will get through 99.9% of what distos actually use, to address point 1. and i simply disagree on point 2..there already are competing offerings and what systemd kffers does not often insist on being run under systemd.
I did. I'm still not happy with the way it was forced in, and how the predictions of teething pains of a from scratch init system being developed by inexperienced developers came true. I still remember the growing pains from PulseAudio, the previous project by the same developers.
But SystemD was a response to the definite problems of past init systems. It might not be the optimal UNIX philosophy architecture, but it's grown into something stable and powerful.
At the end of the day, as a working IT or SWEng professional, you just want to get shit done, so you learn a new abstraction for the zillionth time, put it to practice, and get on with the problem you were trying to solve. Having moved from MS-DOS, to OS/2, to Slackware, to RedHat, then Debian (and staying on Debian for decades, for desktop and server), I trust the Debian devs to put out the most stable and reliable OS I've ever seen.
Unfortunately, this kind of mistake on dates is usually a plain lie to fool the SEO and get more visits. It's so frequent it's not even surprising.
https://corecursive.com/category/podcast/
> I was perfectly happy with systemd myself. I did empathize with people who didn’t like it for whatever reason, but it was clear to me that every Linux distribution except for one or two would be switching to systemd eventually. And I felt that I was pretty good at prognosticating, this kind of thing. So I was, if Debian can’t make the obvious decision without all this much drama, it’s too much for me.
His way is thinking is basically the same as of all Systemd supporters. "I see no problem, it is obvious, everybody is doing it so we will do it sooner or later, anyway."
But this is not, and never has been the point. The crux of the matter was very technical[0]: by gluing GDM to Systemd, the Systemd developers made it very difficult for distributors to support other init systems. They basically forced everybody to switch, and Systemd was not bug-free - it gave sysadmins around the world quite some work, and in some cases, also caused unforeseen problems.
In hindsight, we can see it was unnecessary. Devuan should never have to exist. Debian is offering some support for System V init now. All this drama was completely redundant if someone had not made one controversial architectural decision. Yes, we would have probably transitioned anyway - but on our own terms and at the time we could choose. And Joey would probably be part of Debian still.
[0] Maybe it was also political, but this is beside the point and doesn't change anything.
This is a pretty clear indicator right here that influential people weren't listening on the issue. Any time you state "for whatever reason" is a clear sign you don't care for their reasons.
Is the existence of Devuan not a good example of a conglomeration of reasons so that I don’t have to spend time doing research for this request you probably don’t want answered? You’re still pushing the reasoning aside and saying “those reasons weren’t good enough so we put them in the whatever catgory”. I understand it’s often easier to hand-wave away well after the fact and the damage has been done. The Debian community didn’t move on from it, it split.
So does every other version of Linux. If this enough to dissuade that there is no difference of opinion or difference in values and process handling and isolation then I cannot help you on this topic.
Edit: Also, the proliferation of Linux distributions is illustrative of the same problem I think. There are a lot of distros out there that seemingly cannot really justify themselves, I've been using Linux for 20 years and for some of these distros it's still really hard for me to figure out what the difference is or why anybody would use it without spending days digging around and analyzing patchsets in random git repositories somewhere. Now just imagine how utterly incomprehensible this is to a non-technical person who doesn't have a clue what an init system is...
From the homepage:
> Devuan GNU+Linux is a fork of Debian without systemd that allows users to reclaim control over their system by avoiding unnecessary entanglements and ensuring Init Freedom.
From the Init Freedom page:
> Init Freedom is about restoring a sane approach to PID1 that respects portability, diversity and freedom of choice.
> Other Free Unices Without systemd
> One of the critical arguments against systemd is the lack of portability to other Unices and the possibility that Linux-based systems using systemd would detach from the UNIX world. OpenBSD, FreeBSD and other BSD OSes are de facto incompatible with systemd or rather, systemd is incompatible with Unices not running Linux.
Also, the statement about portability is weak, as someone did manage to port systemd to BSD: https://github.com/InitWare/InitWare
For me, in general it just seems really difficult to justify creating an entirely new Linux distribution because you're waiting for somebody to port a few packages to BSD. That logic doesn't really follow. That's what I meant before, even the Devuan home page has some really hand-wavey and confusing statements.
Whether the results are the same is irrelevant to the difference in approach.
Edit: I am also even more confused as to what that has to do with init systems because BSD never used a system V style init, whereas Linux distros typically did for that period before systemd. So this stuff wasn't portable anyway. See what I mean that the logic doesn't follow? I really can't understand what someone meant when they wrote that.
To answer this question. This is about base compatibility so ports don’t apply. The ports collection has to be installed separately, hence incompatibility.
All hundreds of them. That was debated ad nauseam both here and on practically all Linux websites. See https://ihatesystemd.com/ or https://nosystemd.org/ for some examples.
I'm sorry but I don't buy this, I think you and those sysadmins missed something. The situation with consolekit was so bad that something had to be done about it, if you were blindsided by it, you probably weren't paying attention to that area until it was too late. That's unfortunate but it doesn't really make sense to blame the systemd developers for "making it difficult" when they were the only ones trying to actually solve the problem at that time. IIRC the upstart developers never made progress on this.
So in that sense, systemd is helping retain some diversity in Unix like systems...
I just decided to avoid the friction and not bother publishing my .debs.
I got my key signed with the same simple procedure. The only troublesome part was to find Debian devs to meet physically, because there were only 3 in where I live (Hong Kong), and only one of them had a valid key (others have expired or just lost keys). Two signatures are needed, so I needed one more. Luckily, I happened had to travel to the US for work, so I solved my problem.