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 darkfeline on Friday May 26 2017, @07:28PM (5 children)

    by darkfeline (1030) on Friday May 26 2017, @07:28PM (#516089) Homepage

    Uh, how is this spam? Has SN fallen so low as to Spam-mod anything that goes against the echo chamber?

    --
    Join the SDF Public Access UNIX System today!
    Starting Score:    1  point
    Karma-Bonus Modifier   +1  

    Total Score:   2  
  • (Score: 0) by Anonymous Coward on Friday May 26 2017, @09:32PM

    by Anonymous Coward on Friday May 26 2017, @09:32PM (#516142)

    Ha, wake up if you haven't realized this for, like, FOREVER! I'm one with a few "crazy" thoughts around here, like that maybe Snowden's shit actually does stink a little, or the vast overwhelming number of police officers are decent people who are trying to serve the public well, so I guess I've been seeing this for a long time now. Nice to see that you've swallowed the blue pill (or is it the red pill; shit I can never remember which one it is supposed to be).

  • (Score: 5, Insightful) by jmorris on Friday May 26 2017, @10:07PM (1 child)

    by jmorris (4844) on Friday May 26 2017, @10:07PM (#516157)

    Probably because it looks so cut/paste from a pro RedHat OS blog instead of actual original content?

    The objection is not just to systemd, it is the preference to stay on the UNIX side of the fork. RedHat and Pottering are building an entirely new OS atop the Linux kernel that differs from UNIX as much as, if not more than, Android. It's ideas are mostly derived from Windows thought processes. Now I have no problem with Open Source exploring any problem space developers care about or are paid to write code for. What I, and almost everyone on the Devuan side of the fork, object to is RedHat using their control of several critical Open Source codebases to drive out the UNIX side and force adoption of RedHat OS. They also apparently are using direct financial and political power. All of these forces were used to hammer Debian into abandoning previous principles to adopt systemd/Redhat OS. It is explicitly Linux only, something Debian had invested considerable resources into not being, aiming to the the "Universal Operating System", with BSD and HURD support, any arch enough volunteers could be found to maintain, etc.

    Systemd is not the end goal, it was merely the base enabling tech Red Hat required to build the rest of it atop. Although lately it appears their new trick is to simply suck everything else into the vortex of systemd. NTP and DHCP really needed to be reimplemented inside the systemd morass? Really? Then all of networking itself? We suffered a decade from the failings of NetworkManager (also a curse inflicted by Red Hat) and when it was finally approaching a working state it was tossed for an all new rewrite?

    It makes perfect sense when one remembers Red Hat's business model is support services. If it requires a full time dedication to simply keep current on where everything is configured this month, it makes a lot of sense to simply outsource admin to Red Hat. Reliable is always good, but stable breaks Red Hat's revenue model.

    • (Score: 3, Interesting) by srobert on Saturday May 27 2017, @12:04AM

      by srobert (4803) on Saturday May 27 2017, @12:04AM (#516204)

      "If it requires a full time dedication to simply keep current on where everything is configured this month, it makes a lot of sense to simply outsource admin to Red Hat."

      Over 2 decades I've distro-hopped with about 25 different desktop linux distributions. Slackware, Suse, Fedora, Archlinux, LFS, Manjaro, Gentoo, Debian, etc. Spent quite a bit of time learning how each of them does things. About 5 or 6 years ago, I installed FreeBSD on a laptop that was well equipped for it. FreeBSD is by far my favorite desktop O.S. largely because it doesn't have the problem you just mentioned there. Mostly things are configured where they always were, unless there is a compelling reason to change it. I suspect FreeBSD's /etc folder will look largely the same after systemd is in the dustbin of Linux history.

  • (Score: 1, Informative) by Anonymous Coward on Sunday June 04 2017, @07:09AM

    by Anonymous Coward on Sunday June 04 2017, @07:09AM (#520127)

    Because the opening link is to Poettering's blog, where he misrepresents and deflects criticism against systemd. Yet his faithful followers parade that blog posting out again and again as the definitive proof that the systemd critics are just "trolls" and "haters".

  • (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