Devuan 1.0 Makes It To A Release Candidate: Debian Without Systemd

[TheBlackCat]

Sure, I know this, My point is systemd is a symptom of the problems with Linux, its not the cause by itself. it's the culture and the way they go about designing stuff. btrfs is another example. epoll another, kvm is another and it goes on and on and on it doesn't end because you don't see the problems with taking shortcuts to system design and how it will hurt you. You just implement it and hope it gets better/fixed. Linux isn't a small simple system anymore, that no longer works you need to actually plan stuff out now.

Except that this is the exact opposite of what happened with systemd. sysv was the shortcut, relying on distros to code their own fragile shell scripts to actually do the work. systemd, on the other hand, was a planned-out system designed to satisfy the needs of modern computers. Developers took the lessons from previous init systems, and looked at what modern computers needed to do and where they were headed in the near future, and designed a system that could handle that in a sane manner.

But if systemd doesn't qualify, what would you consider a piece of software of similar scope where they "actually planned stuff out"?

[anarki2]

I see the SystemDeath acolytes are starting to come out in force in this thread.

And Phoronix turns into Slashdot once again....

It's not being acolytes, dude. Keep it real. A whiny bunch is simply not enough to provide alternative to a project of this magnitude. Both Debian and Red Hat deploy systemd which is basically 95% of all Linux installs in use (counting descendant distros). This means service files will only get tested on systemd systems. New projects will also support systemd primarily, and the rest is up to the minorities to maintain.

So you get less tested (in other words, more buggy) init scripts for existing packages and nonexistent init scripts for new stuff. Question is, why on earth woud you want to use such a distro, other than being butthurt that thank god, at last we have a standard init script format. I mean I know there's this kind of person who always wants to be a hipster outsider and fall for the underdog, but come on, complain about an init system? Who cares?

Once again, this is just another project trying to solve a problem that doesn't exist. 99.99% of people don't even care what the init system is called. I personally couldn't care less if I have to "update-rc.d nginx defaults", "chkconfig nginx on" or "systemctl enable nginx". Like literally, I don't give a flying f*ck. Just like the overwhelming majority.

These special snowflakes have been trying to convince us how super important this debate is, but no, it really isn't. Back in the day we wrote init scripts for custom stuff, now we write systemd units. So what. They work just fine. So you might as well go on with your life and do something more productive (read: anything else).

[franglais125]

Debian Stretch is about to be released, and Devuan only now manages to get a RC based on jessie. What is the lifespan of this release going to be? Jessie has 1 more year of regular support, and then 2 more of LTS support, which doesn't cover security updates for all packages.

If at some point they want to rebase on Stretch, for Devuan 2.0 or whatever, I can only foresee that things will get harder. As anarki2 pointed out, services are being tested against systemd more than anything else.

PS: I might be a bit off with the number of years of support remaining for jessie, but the point still holds: Devuan "1.0" has a very limited lifespan.

[dungeon]

Debian Stretch is about to be released, and Devuan only now manages to get a RC based on jessie. What is the lifespan of this release going to be? Jessie has 1 more year of regular support, and then 2 more of LTS support, which doesn't cover security updates for all packages.

If at some point they want to rebase on Stretch, for Devuan 2.0 or whatever, I can only foresee that things will get harder. As anarki2 pointed out, services are being tested against systemd more than anything else.

PS: I might be a bit off with the number of years of support remaining for jessie, but the point still holds: Devuan "1.0" has a very limited lifespan.

3 more years, up to April/May 2020

https://wiki.debian.org/LTS

Of course that is not definite (has a sign(?)), it is yet to be decided how much and which architectures and packages actually will be supported by LTS... so one year more for sure, but for LTS it is up to LTS team and up to what sponsors wants i guess Whatever, that LTS seems goes well enough but average Joe shouldn't count on more, until it is announced

Either for Debian but particulary for that Devuan, i don't think anybody cares because not every package is supported by LTS... Debian Sid has about 56K packages built from 26K sources... no one can support any of these for more

I guess these Devuan users are minimal users, they won't use full blown Gnome 3 neither minimal or any Gnome for that matter so if only base is supported that is kind of enough... they probably use something else on top of that base and maintain their own scripts so who cares base and a bit of most common used packages is mostly what matters

As i see, even they use "universal base" wording, so i am probably right ;D

Devuan as a universal base distribution.

https://devuan.org/

Some Debian users do just that, install just base... OK probably a bit more, but then just do other things on their own and out of regular repos

[jrch2k8]

Sure, I know this, My point is systemd is a symptom of the problems with Linux, its not the cause by itself. it's the culture and the way they go about designing stuff. btrfs is another example. epoll another, kvm is another and it goes on and on and on it doesn't end because you don't see the problems with taking shortcuts to system design and how it will hurt you. You just implement it and hope it gets better/fixed. Linux isn't a small simple system anymore, that no longer works you need to actually plan stuff out now.

epoll is awesome, the hell you talking about? select and poll are abominations from hell that no decent developer will ever touch without puke for a week. If you mean kqueue sure its good but is too abstract and broad in functionality, I prefer the epoll concept of file descriptors only and just add the ability to batch multiple interests updates in the few corner cases it make sense.

KVM? sure is not Xen but is only second to it and from someone who uses it heavily I find it excellent with extremely low overhead, easy of use, proper PCIe passthrough, excellent isolation, very low memory overhead, and very good 2d support, proper UEFI emulation, ZFS volumes support. I admit 3d emulation is lacking tho but is light years ahead of byhve, virtual box, HyperV, etc.

BTRFS, here maybe we can agree even tho is very decently designed but their problem is more about lack of manpower for the titanic task of a linux version of ZFS that even Sun back in the good days took them a whole decade to complete. but yeah ZFS is king for me to the point all my Arch systems got converted to boot directly from GPT ZFS[ZoL] raids 1 using UEFI with systemd-boot[lennart got my eternal love with systemd-boot]

[Ekland]

I think this is a good thing. Instead of whining incessantly about systemd, this is actually doing something, and if there are enough systemd haters out there then this distro will thrive, if not, it's obvious it was just a small group being very loud.

[jacob]

Great news. I'm sure all three users will throw a party!

[dungeon]

Great news. I'm sure all three users will throw a party!

These who like OOTB systemd-free are probably happy

Someone said here you can do that on regular Jessie too, and indeed it is possible, but there is a lot of crufts to remove and to maintain these changed packages (and updates of these of course)... so if somebody like someone else to do that for them, from that point this is fine

[caligula]

2.) Musl problems for mass adoption are actually technical
a.) is not part of GNU so some distros are allergic to it

That's not a technical problem.

b.) Musl is not totally 100% supported on GCC and clang unlike Glibc, so is not as trivial as you think for distros makers to use it

Care to explain this? I'm pretty sure GCC and Clang were used to develop musl so of course they support it.

c.) is not binary interchangeable with glibc, so is not trivial to adopt

Statically linked stuff works just fine on a system with non-native libc loader. Nobody wants a system with numerous parallel libc implementations installed. The real problem is compiling broken stuff that assumes glibc. For instance systemd.

d.) musl don't support certain ancient code still present in Glibc and that will break many very old commercial applications out there(I don't care too much about this one tho)

chroot, containers, ... not really a problem

[profoundWHALE]

A guy here commented about FreeBSD being the 'right way' to do non-systemd.

The last major news that I heard about FreeBSD was the NextBSD project (https://github.com/NextBSD/NextBSD) that was going to implement the Mach API so they could start being compatible with OS X things. That is a direction closer to systemd rather than further.

The sooner that we can all decide on Wayland (mir is dead), and systemd (upstart is dead), the faster that development will happen on all platforms. People were freaking out over what Canonical was doing and the fragmentation, and now stuff like this happens.

That being said, there should be a distro like this available for those who use sysvinit extensively already, much in the same way that Canonical will still support maintaining basic Mir functionality for IoT.