Devuan Jessie 1.0.0 stable release candidate
lists.dyne.org
lists.dyne.org
For those who forgot what Devuan was, like i did – basically a Debian fork without systemd.
I'll bite.
Why?
Being "functional" and using "Scheme for all stuff" is just a means to an end. What value does it bring me as a user or administrator?
Because I can think of at least one obvious downside: Scheme has no mainstream adoption. So they've picked a niche language (yes Scheme is niche) that users now have to learn.
So the value it brings, in terms of features, maintainability, etc, better be significant in order to justify that pain.
And I'm talking real value, not the value of intellectual rigor or functional purity. I'm talking about actual, real, tangible features that can't be gotten anywhere else.
Most sysadmin operations are non-destructive. This has huge implications.
That is nice, to have a supported path of simply add sources, signing keys and apt-get dist-upgrade. Impressive work.
I'm personally not convinced there's a viable near future for Linux without systemd (not counting the mess that is android (as a potential workstation / server distro) - I think Debian/kFreeBSD is a better path.
But I'd love to be wrong.
Is there an assumption that once Debian decided to go with systemd and an increasing amount of Debian standard software depended on it, the kFreeBSD port will have to be given up at some point?
Of course, when you irreversibly mess things up by adding a hard dbus dependency, integrate udev in the init system, put systemd-resolved on 127.0.0.53 everywhere plus tons of other mess, then of course it's hard to "port" everything because you messed everything up so badly that it only works with your init system now.
https://devuan.org/os/debian-fork/stable-candidate-announce-...
It has to be pronounced as this: http://danex.nexlab.it/devuan.wav
The first release has been named "jessie" cause it's a 1:1 replacement of debian jessie, and for our luck jessie is also a name of a minor planet, so, it match our nomenclature and reflect that is a very close path to switch from debian jessie, as Devuan consider itself the "real" continuation of debian after wheezy.
Keep in mind that they originally wanted to release their version on Jessie in early 2015...
How do you pronounce it then?
[1] I doesn't even matter too much to me _which_ solution we have as long as it's reasonable (e.g. upstart wasn't) and a reasonably complete daemon supervision solution which can actually capture the output of the daemon's it's running, etc.
I sort of understand the reason for using systemd on desktop computers, where things may be rather volatile, but in a stable environment such as a server or a mainframe, the value that this complex piece of software brings to the table is not obvious to me; besides, others have mentioned that it is a sysadmin's nightmare, so...
It's certainly not the best solution out there for any single thing it does, but the standardization - i.e., that it is integrated with my distro and also every other distro - is extremely useful. Most existing things I want to run tend to have systemd support, and most homegrown things are very easy to write systemd units for.
Also, there are a lot of reasons to want fast reboots for servers, and systemd provides this. (Again, so do other approaches, but the standardization means this actually happens.)
It's worth noting that there are sort of two debates: systemd vs. other similar systems (upstart, SMF, launchd, whatever) or systemd/similar systems vs. sysvinit. From experienced, large-scale UNIX admins, I think the wide consensus is that the answer to the second question is "definitely anything other than sysvinit". See, for instance, that the Debian tech committee debate was about systemd vs. upstart vs. insserv or something else, and nobody voted for sysvinit.
What a nightmare that was to debug and fix.
I'll be happy to go with a system with fewer moving parts, even if that means reboots take a minute longer.
(You could have also hit the infamous NFS unmount bug which is basically just a kernel fuck-up.)
Hanging during reboot is something that, IMO, should never happen.
In my anecdotal experience that's the _only_ case where systemd has failed to reboot, and it's not exactly systemd's fault that the kernel just hangs indefinitely.
Again, I'm comparing systemd to pre-systemd Linux distros (including Devuan, which explicitly continues that tradition), not to systems broadly comparable to systemd. If Devuan had a different fancy init system or service manager (which could just be bundling runit configuration for everything the OS ships with) instead of an old-school init system + old-school init scripts, this would be a very different comparison.
Any examples? If anything I'd expect systemd to make things easier for sysadmins, would be interested in finding out what challenges sysadmins face because of systemd.
That is the real value of standardization.
EDIT: As far as I can tell as an outsider systemd is at least engineered well enough that these things can be solved, eventually. That wasn't the case before: Everybody had their own quarter-assed solutions that only worked for their specific case and would fail horribly in other cases, etc. etc.
But the Linux community has always prided itself on freedom and diversity. Otherwise we might as well be all using one "standard" Linux distribution.
As to freedom: I'm not sure what you're driving at here. Can you expound?
> freedom and diversity simply do not exist one without the other.
"freedom and diversity" defense. Nobody's trying to take that away, FWIW.
It may feel threatened, but I assure you that systemd is the least of your worries if you really care about F&D.
There is a real risk this approach ends up concentrating power and influence and destroying dynamism. I suspect Linux would not have got to where it is with 'gatekeepers'.
For proper standardization the design and development has to be done openly with the collaboration of major open source vendors and inputs of users to prevent one entity gaining control rather than now of trying to push vendor controlled projects as standards which looks too self serving.
If the project is already done the vendor should be willing to give up control to a 'standards body'. 'Standards' can't be controlled by a single vendor. It's not a standard then.
> I suspect Linux would not have got to where it is with 'gatekeepers'.
Uh, Linus? ... and distros, in general? There are very few people who decide to fork their own distro because, ultimately, good enough is good enough.
You're portraying this as some of cabal of nefarious shady characters trying to do back-handed deals... it really was just a case of the other non-RH distros realizing that systemd was actually good enough.
This is still all Free/Libre software, so if things go awry there's always the option of forking.
That seems to be the only credible way to create workable standards. Open source ecosystems clearly do not yet have the thinking and infrastructure around standardization so it may take concerted effort and time to develop the right processes.
I think the "forking threat" applies nonetheless as long as RH doesn't at least broadly go along with the "committee" of the (F)OSS community. Honestly, I don't really see how they would extract any value from not doing that, so I'm mildly mystified by all the "they're trying to take over the world" rhetoric.
EDIT: Aside: Honestly, I don't see much value in trying to "de jure" (as in: ISO or similar) standardize a thing like systemd. Do you see value in doing that?
EDIT#2: I used to work in the semi-embedded space, and I'm sure many of the people I was working with would kind of see a value prop, but I would point out that they were already working with 2-5 years out-of-date Linux distros anyway...
Software is not static and decisions need to be made by everyone the standard impacts. Which is why it is important that control rests in a collective that represents everyone's interests. I think that's the only way we could call it a 'standard' without taking liberties with the word. Wouldn't you agree?
Yes, it's a last resort and that does give the incumbent a bit of leverage. However, we've seen this type of thing before in the (F)OSS world: EGCS is an almost model example.
> Software is not static and decisions need to be made by everyone the standard impacts.
Sure, but systemd actually has very good reference documentation which you can hold them to.
> Which is why it is important that control rests in a collective that represents everyone's interests.
That may be the thing we disagree about, actually. I actually do think that the systemd maintainers actually do have everyone's best interests at heart and not just RH. That doesn't mean that they formally represent everyone's best interest, obviously. (I readily acknowledge that I may have this perception because I happen to agree with them on many issues, but I do try to be as impartial as possible when discussing it.)
>I think that's the only way we could call it a 'standard' without taking liberties with the word. Wouldn't you agree?
I don't. Off the top of my head, my best example would be AC vs. DC[1]: They were both 'standards', but were basically pioneered by two individuals. (For -- as it turns out -- absurd reasons.)
The point is that a 'standard' for me means something more along lines of a 'standard of service' or 'standard of care'. It's more about having a formalized set of parameters of X. It's not so much about the process itself.
[1] Oh, how I wish I could do a real proper link on those words, but here you go anyway: https://www.youtube.com/watch?v=v2AC41dglnM