SoylentNews is people
SoylentNews
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]
(Score: 0, Interesting) by Anonymous Coward on Friday May 26 2017, @04:51PM (10 children)
To cover many of the myths about systemd: http://0pointer.de/blog/projects/the-biggest-myths.html [0pointer.de] . It is extremely damaging to the Linux ecosystem for people to continue to spout lies about systemd that are not true. Most people when confronted with the facts about systemd and the benefits it offers and the fact it takes nothing away, you are free to have sysv style shell scripts to your hearts content because systemd is fully backward compatable with the old init system, and is actually MORE modular and decentralized than the old system, agree that it is a benefit to Linux.
Please, stop spreading lies about systemd.
Ubuntu has had systemd type init for years because of Upstart, so with systemd, we are simply seeing standardization with what the other distros are doing. So, this kind of init model is nothing new to Ubuntu.
The opposition to systemd is nonsensical. Because you can continue to use SysV init because it supports that, the additional functionality is additive, it adds onto what was there before. Because SysV is still there, and you can start your services that way, you have nothing to complain about and there is no reason to oppose systemd.
One big benefit is the service files which are shorter, simpler and easier to read than shell script and actually make starting services easier. You can still write shell scripts to your hearts content, but for most people service files are easier because of the declarative format.
systemd is actually more decentralized than the old system and is more configurable. This is because of the D-BUS based design. That is, you can write a D-BUS daemon that monitors the system bus for whatever events you are interested in and write your own custom code to decide when to start a process. This allows you to trigger something when multiple other events happen and allow you to do so cleanly and easily because you are watching a standardized protocol over DBUS. It would be much much harder to do this without a standardized loosely coupled design of DBUS. Events can include kernel events and events generated by other processes, including other processes starting. Your daemon can also generate its own event messages when it starts or stops a process. The reason Gnome uses some features associated with systemd is that Gnome for instance wants UI notifications for different system events for the user being able to monitor the system via a user interface.
Some utilities have had a D-BUS backend added, for instance, su. This is to allow users to have a process started when a user logins in. It is a lie to say that su has become built into one big massive monolithic systemd process. This is not the case at all. All that was added to some utilities is a small amount of d-bus code;. They are still completely seperate binaries and are not a part of a monolithic systemd process because the utilities are still completely seperate, in fact it keeps the utilties seperate because the whole point of d-bus as a loosely coupled architecture is to allow applications to communicate without these applications having to be directly linked or even know who each other are.
Systemd in this way is far more modularized than the old init system was.
(Score: 1, Insightful) by Anonymous Coward on Friday May 26 2017, @05:01PM
That's all fine except when it takes away choice and the ability to administer/run a system the way you want to. Open, free software is about choice and freedom. Systemd could shit gold bars and I wouldn't want it because...I DON"T WANT IT.
(Score: 2) by darkfeline on Friday May 26 2017, @07:28PM (5 children)
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!
(Score: 0) by Anonymous Coward on Friday May 26 2017, @09:32PM
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)
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
"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
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
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
(Score: 5, Insightful) by tibman on Friday May 26 2017, @09:23PM
Making programs dependent on a specific init system doesn't make the OS more modular. Exactly the opposite. Now you can't replace the init system of your OS without replacing all those other programs that depend on it. Linux typically has very loosely coupled components so that any single part can be swapped out with a different implementation. Systemd breaks that.
Systemd is dependent on linux (can't run any other OS kernel). So programs that depend on systemd now also become unportable. As-in they can't be used by a BSD or other unix. That's just stupid.
SN won't survive on lurkers alone. Write comments.
(Score: 4, Insightful) by digitalaudiorock on Friday May 26 2017, @10:09PM
Oh ffs! That same tired "biggest myths" link that the pro-systemd trolls have been posting since it was written four year ago. There's NOTHING in that piece of flaming bullshit that hasn't been debunked 1000 times over. Give it a rest.
Good to hear about Devuan. Happily still using Gentoo here.
(Score: 1, Informative) by Anonymous Coward on Sunday June 04 2017, @07:21AM
Upstart was a init, yes, systemd is much much more (how about a dns "client" that again and again is found to have flaws fixed in the likes of Bind for a decade already).
And systemd supports sysv rc files, as long as they are simple ones. Try anything complicated and you can be sure it barfs itself.
service files are only "simple" when compared to sysv rc files, but that is because sysv rc files are required to have all the boilerplate internally. BSD init for example put that into a source-able script file instead, massively reducing the size of the individual rc files. Never mind that systemd keeps growing new keywords, and combinations of keywords on near every release to cover "corner cases" that could instead be handled on a case by case basis using scripts. Expect services files to be Turing complete soon.
Except that d-bus was never designed to be system critical, and have massive performance overhead. After all, they did try to push a variant (kdbus) of it into the Linux kernel a year or two back and got rebuffed by Torvalds, even when the likes of GregKH was backing it.
And su having a dbus backend, what the fuck?! If that was the case, why did Poettering call it fundamentally broken and systemd produce their own tool for the same job?!
Put the pipe down and back away, whatever you are smoking is not healthy for you what so ever.