Stories
Slash Boxes
Comments

SoylentNews is people

posted by mrpg on Friday May 26 2017, @06:59AM   Printer-friendly
from the good-luck dept.

Devuan just released their LTS stable Jessie system:

Devuan GNU+Linux is a fork of Debian without systemd. The latest 1.0.0 Jessie release (LTS) marks an important milestone towards the sustainability and the continuation of Devuan as a universal base distribution. Since the Exodus declaration in 2014, infrastructure has been put in place to support Devuan's mission to offer users control over their system. Devuan Jessie provides continuity as a safe upgrade path from Debian 7 (Wheezy) and a flawless switch from Debian 8 (Jessie) that ensures the right to Init Freedom and avoids entanglement.

And if getting it has to be a secret, check out http://devuanzuwu3xoqwp.onion

-- hendrik

[See also the Devuan 1.0.0 stable release (LTS) announcement for more information on how to install/upgrade, the support services that are available (bug tracking/reporting, user forums, etc.) --martyb]


Original Submission

 
This discussion has been archived. No new comments can be posted.
Display Options Threshold/Breakthrough Mark All as Read Mark All as Unread
The Fine Print: The following comments are owned by whoever posted them. We are not responsible for them in any way.
  • (Score: 2) by NCommander on Sunday June 18 2017, @06:30AM

    by NCommander (2) Subscriber Badge <michael@casadevall.pro> on Sunday June 18 2017, @06:30AM (#527377) Homepage Journal

    While it's not spam, I do think it's inaccurate at best, and does everything possible to ignore systemd's flaws. Systemd is *not* drop in compatible with sysv scripts, and frequently tends to break them in difficult to debug ways. Let me debunk this:

    Myth: systemd is monolithic.

    This is only true in the literal sense. As the article points out, a full systemd build spits out 69 binaries (which likely has gone up). What it doesn't tell you is those binaries are interconnected with each other and can't be used independently. Want to use systemctl but not have binary logging?

    Sorry.

    Want to use logind (for GNOME), but not the rest of the stack. Sorry. systemd is as modular as Windows is; you take the whole thing, and have to use all the parts together or it won't work.

    Myth: systemd is about speed.

    This one is actually true, but misleading. systemd specifically gets boot time improvements by doing things different than sysvinit. I worked at Canonical when systemd was born and we had upstart to tackle the speed problem. Red Hat did ship upstart in Red Hat 6.5, but replaced it with systemd later. While I have no definitive answer on why RH replaced upstart w/ systemd, much of my gut suggests it was the same political reasons that allowed systemd into Debian stable.

    Myth: systemd's fast boot-up is irrelevant for servers

    Actually it is. Faster server startup time only matters in cases where you don't have an HA system. Due various issues with Linode, and Ubuntu, we have a 10-15 minute system restart time at SoylentNews, but the main site is HA. Much of our slow boot time is waiting for network services to fully come up, and for MySQL Cluster to successfully synchronize and come fully online. There is an argument to be had about when you're spinning up new VMs in mass for testing or scale up, but even then that's a relatively small bit of the pie. Under most loads, sysvinit startup time for a heavy server was 1-2 minutes, while systemd might be half that.

    The funny thing is OpenRC, upstart, and ruint (and many others) have managed to get similar speed boots without being a pile of crap.

    Myth: Myth: systemd is incompatible with shell scripts.

    Having a unit file point at a shell script misses the entire point. Yes, its technically possible to get systemd to play with sysvinit style boot scripts (Debian uses it). Good look debugging it when it goes wrong. I just had that experience trying to get stunnel4 working, and eventually scrapped its init script for a unit file because I couldn't figure out why it won't work.

    Myth: systemd is difficult.

    True as far as writing unit files. False as far as determining what the hell went wrong when a unit file fails to load, or claims it started but no daemon is running, etc. SYstemd is damn near impossible to debug when it goes wrong, and how to debug it is poorly documented.

    Myth: systemd is not modular.

    Already addressed

    Myth: systemd is only for desktops.

    Also already addressed. I'll also note that systemd is very much a thing you DON'T want on embedded devices because it requires a stupid amount of kernel dependencies, dbus, and code bloat.

    Myth: systemd was created as result of the NIH syndrome.

    Honestly, I don't know if this one is true or false. I know Red Hat ran with upstart for awhile, and changed it out.

    ---

    At this point, I've already gone 30 minutes writing this comment so I'm calling it here, but if you want to get modded up, post something that isn't pro-systemd propaganda. A good way to tell if something is propaganda is if it doesn't point out the negatives in a solution.

    --
    Still always moving
    Starting Score:    1  point
    Karma-Bonus Modifier   +1  

    Total Score:   2