Slashdot Mirror
Systemd-Free Devuan 2.0 'ASCII' Officially Released (devuan.org)
"Dear Init Freedom Lovers..." begins the announcement at Devuan.org:
We are happy to announce that Devuan GNU+Linux 2.0 ASCII Stable is finally available. Devuan is a GNU+Linux distribution committed to providing a universal, stable, dependable, free software operating system that uses and promotes alternatives to systemd and its components.
Devuan 2.0 ASCII runs on several architectures. Installer CD and DVD ISOs, as well as desktop-live and minimal-live ISOs, are available for i386 and amd64. Ready-to-use images can be downloaded for a number of ARM platforms and SOCs, including Raspberry Pi, BeagleBone, OrangePi, BananaPi, OLinuXino, Cubieboard, Nokia and Motorola mobile phones, and several Chromebooks, as well as for Virtualbox/QEMU/Vagrant. The Devuan 2.0 ASCII installer ISOs offer a variety of Desktop Environments including Xfce, KDE, MATE, Cinnamon, LXQt, with others available post-install. The expert install mode now offers a choice of either SysVinit or OpenRC as init system...
We would like to thank the entire Devuan community for the continued support, feedback, and collaboration....
The release notes include information on Devuan's new network of package repository mirrors, and they're also touting their "direct and easy upgrade paths" from Devuan Jessie, Debian Jessie and Debian Stretch.
Devuan 2.0 ASCII runs on several architectures. Installer CD and DVD ISOs, as well as desktop-live and minimal-live ISOs, are available for i386 and amd64. Ready-to-use images can be downloaded for a number of ARM platforms and SOCs, including Raspberry Pi, BeagleBone, OrangePi, BananaPi, OLinuXino, Cubieboard, Nokia and Motorola mobile phones, and several Chromebooks, as well as for Virtualbox/QEMU/Vagrant. The Devuan 2.0 ASCII installer ISOs offer a variety of Desktop Environments including Xfce, KDE, MATE, Cinnamon, LXQt, with others available post-install. The expert install mode now offers a choice of either SysVinit or OpenRC as init system...
We would like to thank the entire Devuan community for the continued support, feedback, and collaboration....
The release notes include information on Devuan's new network of package repository mirrors, and they're also touting their "direct and easy upgrade paths" from Devuan Jessie, Debian Jessie and Debian Stretch.
I'm waiting for Devuan EBCDIC personally.
"First they came for the slanderers and i said nothing."
I was the second Debian project leader. These days, I prefer to run Devuan, a true Debian derivative engineered the way I would probably have decided to make it. It's efficient and trouble-free. Thanks to the Devuan developers for all of the work!
Bruce Perens.
Grabs popcorn,
waits for systemMD guys to be triggered & the non-obligatory rants.
#munchmunch
Great job Devuan! :-)
Greekgeek
... is a Poettering-Free Zone!
#DeleteChrome
i run all the computers for a fortune 500 IT company and all our servers have been switched to devuan from the red hat and we are seeing MASSIVE improvements in everything from uptime to performance and reliability. as the originator of the plan to switch and the lead in doing it i saved our company MILLIONS of dollars and now i'm in line for a 6 figure bonus this year. if you are still using the systemD and gnome/pulseaudio then you are just a plain stupid loser.
Except for losing log messages and not providing a proper exit status. It's really hard to troubleshoot problems without log messages.
caveat: systemd has done an insane amount of damage to the GNU/Linux eco-system. people are not really sure why, because it's not about the technical aspects per se, it's that the mindset of the developers *behind* systemd is psychologically damaged, and that mental instability is, by virtue of systemd being PID 1, subsequently spreading like a cancer throughout every single GNU/Linux distro that supports it. the cancer analogy is an appropriate one because it's not really visible until it's far too late.
so the fact that devuan takes a well-known stable distro and provides and maintains an "incremental" system to remove systemd is extremely good, and a huge relief. they've done an extremely competent job of modifying a few base packages then letting the repository "fall through" like an HTTP Transparent Proxy onto *standard* debian packages, such that the (small) team only has to maintain and host relatively few packages, NOT forty thousand, requiring over 100 gigabytes of space.
where devuan goes wrong is - and i really hesitate to say this - the hypocrisy of the claim that they are UNIVERSAL. if they were truly universal, they would have included systemd DESPITE ALL THE PROBLEMS IT CAUSES.
if they had done this, the simplest way to have done it would have been to include build profiles in the various packages xorg, pulesaudio, udev, samba and many more (in a constantly-increasing list) that instead of *REMOVING* systemd allowed building of PARALLEL packages with AND WITHOUT systemd, from the same debian source package.
if they had done that, then interestingly, debian could have considered picking up those modifications and including them *in* debian, thus making devuan's life easier rather than harder.
but they haven't done that, and the hypocrisy and lack of integrity towards the claim that they are "universal" is why i cannot use devuan: instead i use angband.pl on top of debian (and occasionally have to download the source of those packages, modify the build-deps and recompile them).
devuan is a backlash *against* something, and that never goes as people intend. mother theresa was the first person i learned this lesson from, after she famously was invited to an "anti-war" rally, she refused... and said "but if you ever have a peace rally, i'll be delighted to attend".
Log message problems can be fixed (maybe by a different team, though), if that were the worst thing, it wouldn't be a problem. The problem is systemd is crappy architecture, and you don't want to build stuff on top of crappy architecture to get it embedded deeply within the system, you want to keep it flexible and replaceable. That's why this project is good even if you never use it, because it will improve the quality of the software you do use. And those people who do like systemd can use it.
"First they came for the slanderers and i said nothing."
Funny how people who support systemd are either blind or run a full memory purge after reading any story about systemd on /.. Good examples are all over the comments on /.. If you didn't see them, you're either new here or you pointedly missed them.
Funny how so many people claim systemd is a lousy architecture to build upon, yet never provide any evidence to support those claims
Nah, I did a fairly long analysis of the strengths and weaknesses of systemd in my journal. If you disagree, go ahead and tell me: it will increase my knowledge.
"First they came for the slanderers and i said nothing."
Listing of grievances about systemd.
Feats of speed.
OS miracles.
Domestic spying is now "Benign Information Gathering"
?? When did it not give you proper exit status? Can you give a bit of context?
I do a lot of work systemd based systems (RHEL 7.x) and I see exit statuses logged to the system log rather often by system log if there's an abnormal exit code:
Jun 07 18:32:04 testserver-124772 systemd[1]: testservice.service failed.
Jun 07 18:32:04 testserver-124772 systemd[1]: Unit testservice.service entered failed state.
Jun 07 18:32:04 testserver-124772 systemd[1]: testservice.service: main process exited, code=killed, status=9/KILL
If it's an auto restart service then it should automatically log that in the system log. One shots or non auto restarting services I'm not sure about atm.
"You're not paying for this racoon we are setting loose in your kitchen, so you have no place to make demands of someone who is giving you a raccoon for free."
I saw a similar title earlier today and gave 1 fuck, "what a dumb name". Fuck, why are OS names so shitty?
What difference does that make?
I think Windows is a lame name and Solaris is cool but that didn't stop the former from becoming more successful than the latter.
I also think most rappers have exceedingly stupid names but many of them are multi-millionaires and I'm not.
Pain is merely failure leaving the body
Instead of creating fragmentation in the Linux community
It's creative destruction. Read your Marx.
Their product is crap of no value to me. I will ignore your whiny suggestion that I help improve it.
MOD UP
It may be just as well I don't have mod points, I can't decide between 'Funny' or 'Insightful'
https://ewontfix.com/14/ is a good article which goes into detail about why systemd is a bad architecture.
That "nobody cares" comment really hurt you, didn't it? You should seek therapy.
Actually, no.
SystemD is controlled primarily by Redhat employees -- and, they are very, very, very hostile to commits that aren't 100% behind their 'everything is a VM' goalposts. Even normal, sane bugs results in an almost instant screaming response, and closed bugs.
And fork? Pffft. That's what you're against, right? So, one can either fork systemd and 'do it right', or... not use it.
A company that makes it money by selling Linux support introduces this monolith of untested and unproven code upon paying customers...
Funny that I've been running BSD based servers for damn near 20 years and I have yet to see any daemon just go off and die without a reason.
It's great that those of you have the power to choose to run Duuvan or FreeBSD at work. I don't! I use what they use or get fired and replaced by someone else who can get the job done.
I maybe up for a promotion using Redhat/CentOS in a few months and will be judged on uptime and ability to recover from reboots. I am nervous after reading all the hate here.
If everyone is using system D it can't be that bad right? Amazon uses it and so does every fortune 1,000 company. Is there a tutorial on how to use it reliably or is using FreeBSD or Duuvan the only non Windows option?
http://saveie6.com/
...says the guy with imaginary persecutors on a tech website.
I hate systemd. But the open source movement is about choice. People who like systemd should be able to keep it. But those of us who dislike systemd should not be forced to use it (or else to give up Linux). Currently, I am running Gentoo with sysvinit. It's simple, straightforward, and does what I want. There are valid reasons for people to use systemd; they just aren't worth the trouble in my case.
I'm glad for Devuan. I hope other distros will also provide choices without systemd for those of us who don't want to use systemd.
Seriously. For my life, i cannot understand why the Linux community is so worked up over it.
systemd is the fragmentation. Using sysvinit is the original way of things on Linux that should never have been replaced by systemd and its ilk. Go tell Lennart Poettering not to fork shit with systemd and pulseaudio, rather than confusing the issue with your nonsense.
Just write the dam' code. Do it properly, with skilled authors and designers so it doesn't contain (so many) bugs and then TEST IT. Not just for function - and that only seems to be that the expected input produces the expected output, but for integration, backwards-compatibility, security and reliability.
That would actually have added value worth paying for. Then every year or two, do it again with a new release.
politicians are like babies' nappies: they should both be changed regularly and for the same reasons
Didn't we have this talk already? If you're going to be pedantic enough to insist on using GNU then go all the way and make it GNU+BSD+Assorted non-associated contributed packages+Linux then.
Could be fun for the type of person who enjoys this sort of thing.
While there are a handful of informative posts, they get drowned out by other up modded posts like this that don't add anything. Depending on the story, sometimes there are almost no informative posts and just a lot of "No, it just sucks", even to polite requests for more information or for someone to back up a specific claim.
I have a repurposed consumer grade NAS. It lacks any special bells or whistles. It has no sound hardware. It has only a small list of services that I want it to run. It has no god-damned-need for systemD.
Finally, I can use something reasonably mature (like debian), without SystemD's clusterfuckery.
(Because frankly, I fail to see why I need to carry all that shit around just to boot a minimalistic embedded linux, M'kay?)
As that article is 4 years old now, I'd be interested to read an updated view on how systemd has changed since then (the single PID-1 thing appears to be at least partially outdated, if it's comprised of ~60 programs now). It may not have changed much, but 4 years is a fairly long time.
[1] systemd created the fragmentation, so you don't get to lay that off.
[2] I don't rally around people with ugly ideologies either, in the name of unity.
Comment removed based on user account deletion
Excellent, smelly basement dwellers at 10 paces, keyboards fully loaded.
Grabs popcorn.
you won't get any context on here, the myths and rants have been ongoing since version 0.1. seems everyone else and his dog seem to get on with systemd fine bar a few on here.
"The hands that help are better far than lips that pray." - Robert Ingersoll (1833-1899)
Not a single good thing comes from systemd. we hand a simple robust init system, with other tools to monitor and restart services if needed. Now we have this systemd cancerous abomination that has invaded everything due to redhat's agenda and product map despite systemd being BAD FOR LINUX.
systemd is actually the worst thing that has happened, technically and otherwise, for Linux and the community, for as long as I can remember (in, what, over 25 years?)
But considering the bugs where it exits with a 0 even on failure and they just can't seem to not drop most log messages on daemon start, has much really changed?
They've made it difficult to search for text encoding issues in this release of Devuan.
It is more like: there is now a racoon in the free park that you also frequent, and other visitors seemed to like it.
Graphical stuff is the big one that I see a lot of (mostly segfaults), but no shortage of daemons that get murdered by the OOM kernel killer because the main service on that VM has a memory leak.
No one likes it.
We'd rather salute the folks who worked so hard behind the scenes to slip systemd into distros before the users had time to realise what was going on—much less protest—with a hearty "Fuck you, assholes".
Il n'y a pas de Planet B.
I'm pretty sure that Narcocide != APK.
Il n'y a pas de Planet B.
Neither claim which is true. No logs have ever been dropped by systemd and the exit on failure is because the daemon fails after systemd did it's thing and people not fully understanding how asynchronous starting works.
systemd was not the first init replacement so your #1 claim does not hold water. And btw none of the BSDs use SYSV Init either.
Except of course that none of this is true. If "systemctl start XXX" returns 0 when the XXX fails then that is because XXX failed after systemd did it's thing, often this can be traced back to the old start script performing pre-launch checks that the new unit file does not have (i.e the people who wrote the unit file didn't do a proper job).
But there is no evidence, just anonymous anecdotes from people who claim to have switched to BSD for ages ago but still seam to comment on every Linux article they find.
They are talking about "systemctl start XXX" returning 0 when XXX fails to start. This is always due to XXX failing after it forks so systemctl does not see the failure before it has already done it's thing.
Lot's of the older sysv init scripts contains lots of pre-flight tests on daemons where the script writes knew that the daemon would fork first and look for configuration files etc later and then when the unit files where created these pre-flight checks where removed (but there is nothing that prevents a unit file from having pre-flight checks) by maintainers that didn't fully understand why these checks where there.
I have posted much more detailed critiques myself. Don't lie./
And which secret sauce in BSD protects a third party daemon like say apache or sendmail from bugs as compare with when they execute on another OS?
There are several things still broken with SystemD, but what riles me most is that proper signaling the process group doesn't work. And that fixing such a fundamental *nix basic feature does't seem to interest those implementing at all.
You mean like dropping logs and not providing a proper exit status? Both of which are false btw.
False equivalence: systemd is unlikely to harm you or your property or spread disease. Nor can one bugfix a raccoon, but one *can* bugfix systemd with a little more elbow grease and a little less complaining.
No, that's not me.
Search for COME FROM, btrfs, RAID1.
If you interpret a text response as "screaming" then this may say more about you and your mental state than it does Red Hat.
the single PID-1 thing appears to be at least partially outdated, if it's comprised of ~60 programs now
It was already wrong when the article appeared years ago, but that didn't stop people...
You like it so much, you won't publicly associate your pseudonym to liking systemd.
> While it comes with some problems of its own it, does solve real problems and is an improvement.
Really? "Real" problems in a systems event reporter that has worked near flawlessly since its inception, over twenty years ago? What might those have been?
There is no America. There is no democracy. There is only IBM and AT&T and DuPont, Dow, General Electric, and Exxon
So, are you saying that none of the distros had a discussion about whether systemd would be a suitable init replacement? That none of them voted on the matter?
Are you, in fact, saying that somebody:
There are always the BSDs, if the Linux corporations become too nasty.
Don't whine, switch.
"How do I know there is nothing better? All the major distros have adopted systemd. If there was a better alternative I'm sure they would adopt it."
Bollocks. They adopted it because it became a dependency of other software, because the devs of that software were lazy and/or incompetent, like gnome. All except redhat of course which did it deliberately to the rest of us.
"You're right," Fisheye says. "I should have set it on 'whip' or 'chop.'"
There are plenty of alternatives ("Better" I'll leave for others to decide) . The daemontools-based inits (s6, nosh), continuation of the init system but with dependencies added (OpenRC), and some programs in their own class (launchd been ported a billion times).
The reason for the distros standardising on systemd have more to do with network effects than a conscientious decision - init was long in the tooth, and once RedHat wenr systemd, everyone else could piggy on their work.
Clearly one of us is wrong about this assertion. How does that feel?
I've heard that claim made before too... Are we really in a situation where a combination of laziness and conspiracy has forced most distros on to systemd, yet there is apparently enough support to build a fork of Debian without it?
Wouldn't it make more sense to, say, fix Gnome and a few other key bits of software to work without systemd, thus freeing all these distros that were forced to adopt it? Or just move to other window managers?
const int one = 65536; (Silvermoon, Texture.cs)
SJW, n: "Someone I don't like, and by the way I'm a fuckwit" - AC
You're lying. A quick search through bugzilla will prove you're lying.
hxxps :// bugs.freebsd.org/bugzilla/buglist.cgi?component=Individual%20Port%28s%29&product=Ports%20%26%20Packages&query_format=advanced&short_desc=crash&short_desc_type=allwordssubstr
You're not paying for this racoon we are setting loose in your kitchen
I don't remember anyone forcing me to use a systemd distro.
systemd is Roko's Basilisk.
Some parts of the "community" need a bad guy to be outraged over. It used to be Microsoft but less so nowadays, although the recent GitHub news caused a slight resurgence. They're a certain demographic (usually male, over 35) and tend not to have anything of substance in their complaints.
It appears to be outrage for the sake of being outraged.
... by maintainers that didn't fully understand why these checks where there.
This is the crux of vast majority of complains about systemd. Maintainers who don't understand systemd and write bad configuration. Just look at Debian for example. The nginx service file is using start-stop-daemon !!!
ls -lh /lib/systemd/systemd /lib/systemd/systemd
-rwxr-xr-x 1 root root 1.6M Feb 1 23:31
It's clearly not a lithe, slender little thing running as pid 1.
"First they came for the slanderers and i said nothing."
Perhaps you have an alternative explanation, if so I would like to hear it.
Yeah, I do, I discussed it at length in my journal, with this particular entry being the core. Lennart Poettering spent a lot of time working with distro builders and figuring out what would make things easier for them. So that one use case it does well, and I commend it for that.
And I would say there are other use cases it does well, but that is the most important one. Why am I against it? Again I discussed it at length, but the short answer I will restate from above: when pieces of the system become too entwined, that's bad architecture.
"First they came for the slanderers and i said nothing."
Wait, they used start-stop-daemon in a unit file, WTF?
Sorry, but Slashdot gave me " No matches found. Try a different search or head back to the main stories. ". However I use BTRFS in a RAID1 configuration with Ubuntu+systemd on several of our servers without any issue so it seams to work for me, which of course is not the same thing that it works for you. Should I also write down every single time sysv init failed me on various configurations?
I don't remember anyone forcing me to use a systemd distro.
Then I guess you do not work where I work
But with that said, to me systemd has been a big meh. Had no issues with it nor does it excite me. At home I run Slackware and I find a bit faster and easier to deal with than what I use at work and personally, prefer it over other distros.
BTW my work hardware is more beefed-up than I have at home, but none of the performance has to do with systemd but with background tasks I need to have running at work.
Agree completely.
I've been using a systemd system for years now. Not one problem related to systemd. Unless you call fast start up and shut down a problem. The old init scripts were a mess, each one slightly different with no easy way to tell what commands each one would accept, and no way to get something simple, like the human readable purpose of the script. Systemd is a big improvement, for some reason rejected by people that somehow feel empowered because they can hack startup/shutdown scripts.
We hope the inclusion of OpenRC in ASCII's installer (expert mode) can be a concrete answer to your question. OpenRC is also what good BSD folks are adopting.
I've heard that claim made before too... Are we really in a situation where a combination of laziness and conspiracy has forced most distros on to systemd, yet there is apparently enough support to build a fork of Debian without it?
All the available evidence says yes on all counts.
Wouldn't it make more sense to, say, fix Gnome and a few other key bits of software to work without systemd, thus freeing all these distros that were forced to adopt it? Or just move to other window managers?
Yes, yes it would. But that's not the course that was taken. Debian went to systemd with a slim majority vote, but people act like it was a unanimous decision and foregone conclusion. Well, it was neither.
"You're right," Fisheye says. "I should have set it on 'whip' or 'chop.'"
Thanks, that explains a lot. So there needs to be an alternative that suits distro devs as well as users in order to replace systemd.
const int one = 65536; (Silvermoon, Texture.cs)
SJW, n: "Someone I don't like, and by the way I'm a fuckwit" - AC
Neither claim which is true. No logs have ever been dropped by systemd
Many people who have tried to troubleshoot early boot issues (mostly with RAID) disagree with you, including myself.
and the exit on failure is because the daemon fails after systemd did it's thing
*its
and people not fully understanding how asynchronous starting works.
Too bad they had to make it so complicated to understand. It just worked before.
"You're right," Fisheye says. "I should have set it on 'whip' or 'chop.'"
Sorry, but Slashdot gave me " No matches found. Try a different search or head back to the main stories. ".
You used slashdot's search function? You must be noob here.
"You're right," Fisheye says. "I should have set it on 'whip' or 'chop.'"
You're not paying for this racoon we are setting loose in your kitchen
I don't remember anyone forcing me to use a systemd distro.
Exactly. Systemd is mainly something that allows the ford versus chevy crew to get outraged about.
I guess they got tired of the text editor wars.
It isn't like there are no options if a person doesn't like systemd. In fact, for the most discriminating Linux cognoscenti, they can roll their own, with not a thing to disturb their delicate sensibilities : http://www.linuxfromscratch.or...
The shepherds did so well protecting the flock that the sheep no longer believed that wolves existed.
Why should I do that when non systemd distributions already solve the problems systemd brings? I'd rather put my efforts into improving those.
I find it interesting that everyone can see the flaws in systemd (and particularly in Poettering's attitude), but no-one has come up with a better alternative.
How do I know there is nothing better? All the major distros have adopted systemd. If there was a better alternative I'm sure they would adopt it.
Perhaps you have an alternative explanation, if so I would like to hear it.
Hans Reiser did...
I'm glad :)
"First they came for the slanderers and i said nothing."
Too bad they had to make it so complicated to understand. It just worked before.
As someone who had to wring bootup performance out of server spinup instances, I can tell you that nothing about SysVInit or upstart "just worked". Getting them to spinup fast was an ugly mess. For many cases, this only had to be done once, but it was still a headache that nobody wanted or needed. Since the switch to systemd, startup times have been as fast or faster than before, and it requires zero maintenance on our part.
It should also be noted that hot swapping was a royal pain under the old architecture, and the code involved held many bugs related to the fact that the daemons that handled the hot swapping could not run as PID 1. This is the single biggest reason that systemd runs as PID 1, and hot swapping works a damn sight more reliably now, especially on more obscure hardware.
Early boot issues have always been a problem, and always will be. until you have enough OS in place to properly handle persistent media, there is no way to log anything, other than to keep the information in memory and hope there will be an opportunity to dump the data later. systemd has had little impact on this either way, and for the vast majority of users, early boot problems simply dont exist, or are a symptom of faulty/flaky hardware. If you are developing drivers for hardware that needs to spin up during early boot, then I will fully agree that you don't want systemd, but you should probably also have some specialty hardware (like a serial monitor) that gives you someplace to dump early boot diagnostics anyways.
For what it is worth, my experience with RAID devices has been that the controllers are mostly shit unless you are willing to drop 10k to get top of the line. Everything else tends to be under-tested junk that works with windows and nothing else. My last raid card from Dell fried all four hard drives attached to it when it failed.
I wish I had a good sig, but all the good ones are copyrighted
You should probably be aware of the reasons for the introduction of cgroups, the limitations of pidfiles with respect to process tracking, and the difficulties involved in setting resource limits for processes without kernel-level support. There may or may not be anything too badly wrong with systemd (hopefully not, as OpenRC is pretty similar), but people who are still clinging to sysvinit are fools.
Those who advocate genocide deserve every protection afforded by law, and none afforded by common human decency.
when pieces of the system become too entwined, that's bad architecture.
That depends on how coupled the underlying principles are. If your word processor and your audio sub-system are tightly coupled, then that is bad architecture because audio and word processing have nothing to do with each other.
However, when init and hot swapping are tightly coupled, that makes sense, and is good architecture because both interactions have code that has to do the exact same thing, and both need to handle the same conditions and requirements.
The UNIX philosophy has its own set of limitations, and directly led to many of the interoperability problems that Linux suffered in the late 90's and early aughts. Just like programming languages, one size does not fit all when it comes to system architectures, and using the right design for the job is critical.
Those who argue against anything that does not fit the "do one thing only" program model remind me of the purist Object Oriented programmers. They single mindedly believe their way is always the best, even when it isn't, and anyone not doing things their way is an idiot.
I wish I had a good sig, but all the good ones are copyrighted
Wait, they used start-stop-daemon in a unit file, WTF?
I have seen a lot of this. Developers who have an existing package under upstart, and saw the switch to systemd, wanted to be ready, so they "wrapped" their upstart script in a systemd unit file, and pretended it was all good. The practical result is that the package works fine under normal conditions, but any failure turns into a complete undiagnosable mess because the developer didn't take the time to understand what systemd is or how it works.
systemd does have one fundamental flaw, and it is the only truly real one it ever had: The documentation sucks ass. The one thing it really needs is a how-to instruction on porting from an upstart service to a systemd service, written by someone who actually knows how to do it properly instead of the droves of rank amateurs out there who "got something working" and are just documenting their own screwed up attempt. RedHat has a few examples, but they are geared to RedHat, and most were written in the last year or so, which did absolutely no good for the people who needed this 2+ years ago.
I wish I had a good sig, but all the good ones are copyrighted
The Unix philosophy is not "each piece does one thing." It's complex and you should understand it.
If I were designing it, the init system and the hot swapping system would completely separate, but the init system would call into the hot swapping system through a minimal interface when needed. That would give you maximal flexibility.
"First they came for the slanderers and i said nothing."
It isn't like there are no options if a person doesn't like systemd. In fact, for the most discriminating Linux cognoscenti, they can roll their own, with not a thing to disturb their delicate sensibilities :
I saw an init system written by a young person without any formal CS education, using Boost as a style guide and dbus as the only requirement. Wow was that thing messed up.
I wish I had a good sig, but all the good ones are copyrighted
SystemD is controlled primarily by Redhat employees -- and, they are very, very, very hostile to commits that aren't 100% behind their 'everything is a VM' goalposts. Even normal, sane bugs results in an almost instant screaming response, and closed bugs.
I'm not saying bullshit, but I think links are appropriate given the accusation you just made.
I wish I had a good sig, but all the good ones are copyrighted
I had some issues with some modern distros but this worked fine, maybe I will learn how to manage they system with the new service manager, bit now I have too much work to do.
I'd like to be able to cleanly install a regular Debian/Redhat/Suse system and choose at install time what sort of init I want the machine to use. Kludges like those at http://without-systemd.org/ are nice, but let's have something that doesn't require such tinkering. Is that too hard to do? If so, why?
Why does Poettering still have a job pushing systemd and pulseaudio all the discord he's sown?
False equivalence: systemd is unlikely to harm you or your property or spread disease. Nor can one bugfix a raccoon, but one *can* bugfix systemd with a little more elbow grease and a little less complaining.
Or I can avoid the disease infesting systemd altogether and save myself some elbow grease!
So we are finally past the whole tabs vs spaces thing?
Would you do that? please?
Your reading comprehension requires work. Perhaps use some of the elbow grease that you saved by not helping to fix the alleged problems.
Let me ask you this?
Do you use Linux professionally as a programmer/user or as a system administrator?
It seems the later who switched to FreeBSD and Duvuan for good reason have a complex environment with hundreds of racks and virtual machines where a reboot means things like your array or SAN don't get mounted and daemons randomly get shut down with no logs on why seem common. I could be wrong but systemD is great on a laptop for faster boots but professionally sounds like a nightmare when the CIO is breathing down your neck for uptime and your servers are being stupid
http://saveie6.com/
keep it flexible and replaceable.
Exactly! I've been using Unix since before Linux existed. The original philosophy was that it worked as a bunch of simple, self-contained components. Commands are terse and to-the-point. If you want something more complex, pipe them together. Even the shell was replaceable.
Oh, and everything could be treated like a file, including devices. This concept seems to have gone a step farther in Linux, where even processes can be accessed through /proc.
Before pulseaudio Linux audio was rubbish if you were a desktop user.
I can't think the Devuan developers enough. I'm not a distribution developer nor a sysadmin (except for my family's PCs...). I'm not even averse to using systemd-based distributions. But - I know the wrong choice has been made, and I know this needs to be rectified. I plan on switching my home PC from GNU/Linux Mint to Devuan GNU/Linux 2 next time I need to install a distribution.
I encourage everyone to try using Devuan, to support the project with hardware, with money and with QA/bug reporting. Even if you think SystemD is not as bad as it's made out to be - you should consider supporting the project, or at least not bashing it - if only in the name of diversity. Monoculture and single point of failure are problematic.
I like it.
Instead of the zillion different gaffertaped together scripts used in different distros we now have a standard
Why don't you just use Windows?
Yes, it used to be pretty horrible. I am not sure to what puslseaudio specifically may have fixed, but it is a bit better now, although still a bit of a mess. But it might have got better without pulseaudio, so it's hard to know if this was correlation or causation. Some things (MIDI) still seems to be better supported via ALSA. And then jack is required for some things to work properly, integrating with ALSA or pulseaudio. So yes, still a mess, but at least my audio mostly works now.
LOLOLOLOL.
It's great to see a systemd-free distro making progress. Hope they keep releasing.
And remember, Slackware is the oldest GNU/Linux distro in active maintenance, and is also free of systemd. Even the development version (Slackware-current) has no systemd.
-- Look to the Rose that blows about us--"Lo, Laughing," she says, "into the World I blow..."
Playing devil's advocate, plate tectonics used to be the fragmentation. Just because it may lead to short, or even long term, fragmentation, doesn't mean it's not the appropriate course of action.
You are explaining Unix philosophy when you have no idea what you are talking about. Google unix philosophy please and learn it before discussing how much better systemd is. Thanks.
He owns 1 Linux box with systemd on it. It's never crashed. Flawless systemd configuration. You should see it. It made Jesus weep.
> Log message problems can be fixed...
I'm beginning to think the logging problems with systemd can't be fixed since they've been broken for so many years. Just sucks that there's so often nothing in the journal except the exit status and that output, especially to stdout or stderr, is just swallowed. It's ridiculous that you can start something by hand, see the error message, and fix the problem in a few seconds while systemd can't do the same.
In other words, you have no real argument.
Would you do that? please?
No, he's busy telling people that they are doing it wrong and that he would do it right, if only he had time.
Racoons are dangerous! Great comparison with systemd, IMO.
Fast, stable, flexible, and systemd free.
Like old (real) Debian, it has excellent package management.
Other distros get more bloated, less flexible, and more authoritarian; Devaun embraces the true ideals of Linux, and UNIX.
> Why does Poettering still have a job pushing systemd and pulseaudio all the discord he's sown?
Because Red Hat, and it's business partner Microsoft, want to effectively control the Linux universe.
Can't blame them, they are public corporations, and their first duty is to their shareholders, not the Linux community.
It seems the later who switched to FreeBSD and Duvuan for good reason
Wow, it seems you live in a parallel reality. Devuan is really unpopular, they barely have found a few unexperienced people working on it (there is a reason it takes more than a year after Debian was released to update the 70 packages Devuan has).
My test case (in a VM) was configured to allow mounting degraded. Then I failed one of the drives in the VM and booted. Systemd wouldn't even attempt to mount the volume, just the cylon followed by the emergency shell. After digging around in the twisty mess of configuration filed, I found there is no way to make systemd just try the mount command as an imperitive. It decided the volume couldn't come up and so it wasn't going to try.
Of course, since degraded mode was configured, issuing the mount command manually in the emergency shell mounted it up with no issue at all.
Meanwhile, remember the Apr fools joke COMEFROM command? Systemd actually implements it.
In general, systemd isn't all that flexible. If you have an unusual situation, you'll have to use something other than systemd to bring it up. Unfortunately, systemd doesn't play nice with others so that means replacing systemd. Unfortunately, systemd has it's tenticles embedded into everything, so that's going to be a much harder task than it should be, involving a lot of recompiling. Hope you didn't want to use Gnome in that configuration.
The systemd project would have developers write daemons with dependencies on systemd. ("come into my parlor" said the spider to the fly). DON'T DO IT! Your project, like Gnome will end up as part of a vendor lock-in that way.
In the long term, that's bad for Linux. There's no reason that everything systemd does couldn't have been done the Unix way with smaller interchangeable tools that could inter-operate.
Is this the OS equivalent of Godwins law?
The cunt who designed and wrote it had a history of writing buggy ill conceived shit.
He is far from the best person for the job.
Also he isnâ(TM)t a huge Linux User. Heâ(TM)s part of the laptop brigade, and while thatâ(TM)s important, itâ(TM)s not essential.
Quite frankly, Linux on a laptop or desktop is a fundamentally different beast to Linux on a server or virtual machine.
I bet that cunt pottering uses a Mac, has a hard on for it, and gave us a half arsed implementation of launchd.
But mounting root at that stage is not the work of any init so if I have to guess the problem that you experienced with the degraded btrfs has to do with the initramfs image on your distribution and not with systemd, but having not seen this myself I will of course not say that systemd had nothing to do with it but it sounds odd since / is mounted before init is called by the booting kernel. And I've read many storied about default initramfs:s having trouble with degraded raid1 btrfs so I think you blamed systemd too early there.
Gnome are not vendor locked-in, their dependency upon logind is #1 something that can be disabled with a compile-flag and #2 the dependency is on the logind DBUS namespace and thus anyone can implement something that speaks that namespace (which is how the BSDs implemented it on their end). And the logind thing solves a problem for Gnome which is why they choose to go with it.
In the long term, that's bad for Linux. There's no reason that everything systemd does couldn't have been done the Unix way with smaller interchangeable tools that could inter-operate.
Which accidentally is just how the various systemd are implemented, it's a bunch of smaller interchangeable applications that inter-operate via DBUS. The only dependecy each tool have is the DBUS namespace so as long as you implement that you can change each and every systemd tool.
otoh, ls -lh /sbin/init /sbin/init
-rwxr-xr-x 1 root root 37K May 29 2015
(devuan jessie, haven't upgraded yet)
If you don't see logs from early boot on RAID issues then check the unit files for the tools that set up your raid, there is a chance that they are set up in a stupid way that disables logging from these tools. Because anything that comes out of a tool when run under systemd regardless of if it's from stdout, stderr or syslog is captured and sent to the journal.
But unfortunately some maintainers create faulty unit files here. I have seen some where the daemon is invoked with arguments like "--quiet" which of course makes the daemon create no log output at all. Another example is mediatomb where the unit-file from debian makes it log to "/var/log/mediatomb" instead of just letting it log to stdout which means that "journalctl -u mediatom.service" only yields the logs from systemd when it starts and stops the deamon which looks like logs are dropped but instead they are stored differently.
But using start-stop-daemon on upstart would be a complete waste of time as well... Personally I found "man systemd.unit" to be quite good but then if people are using start-stop-daemon under upstart then I don't know if any documentation would save them.
There are still systemd-free distros out there, support them if you care. I'm happy with the above.
ERROR 144 - REBOOT ?
But you can only change the systemd tool for a clone of that tool.
As for the systemd test, NOW it has been moved to the initramfs NOT running systemd. That is a kludge to make it work. You could say that systemd accidentally developed a dependency on the old SysV init. But it was definitely systemd, that's why the cylon followed by the emergency shell. But systemd won't do any better for a non-root volume and NOW, the plan was always to use something else in the initramfs. And we have always been at war with Eastasia.
If you are running hundreds of servers with shitty hardware that suffers race conditions at boot, then you got what you paid for.
Get a real god damn server with a raid controller that isn't fucking garbage. Or use NAS and real NICs that aren't garbage.
The problems with systemd are technically features, not bugs, because they're working as intended.
Agreed about the rappers names. Fucking dumb.
Funny I do not have these problems with SysInit. It is a SystemD problem. Not a hardware/driver problem. SystemD is not consistent at all.
This. Everything was fine with Linux until systemd and pulse-audio. A good example of Microsoft EEE.
http://big-elephants.com/2013-...
How is this a mess ? This can only be a mess if you have no idea what you're doing, in which case you shouldn't be commenting, worrying or thinking about Systemd or "old init scripts".
Unfortunately "they" decided to impose this massive pile of crap that does everything now ( opposite of what UNIX should be - and because of what UNIX is is why we use it... otherwise everybody would be running Windows on their servers ).
But it's politics. Redhat is doing it because of Political reasons. Sneaky and crappy... it's something Microsoft would do.
tbh I'd really like to spend some time getting Enlightenment Desktop working nicely, because I think it has a lot of potential. Next year, maybe.
"First they came for the slanderers and i said nothing."
Reading comprehension seems not to be your strength, but go on claiming everything runs in PID 1.
Linux is too important to risk being tied down. Without the Linux wildcard I suspect Microsoft and Apple wouldn't be able to avoid even more draconian demands from Hollywood and Governments. Once someone corrals Linux the whole landscape changes.
Don't let anyone put a saddle on Linux much less a bit in it's teeth!
professionally sounds like a nightmare when the CIO is breathing down your neck for uptime and your servers are being stupid
I am not the parent but match his and your description. Lots of systems with lots of uptime required. Complex but not stupid crazy (a few iscsi and serious storage DB hosts with lots of adapters but most virtual machines in large clusters running various apps).
I've (we've since no tickets on it either) never had systemd get in the way. Ok maybe that was true 3 or 4 years ago but since then I've actually bothered to learn how systemd works so that your above quote doesn't actually happen. Its called learning new techniques for your job.
At home I don't have any sort of complex startup requirements so who gives a shit. At work I have a few hard requirements about 'this before this' and systemd works fine for that since all my requirements come as distro defaults anyway.
Bravo to devuan, cheers to the enthusiasts, but everyone else has moved on, and this should help the stupid 'systemd sucks' war finally cool down a bit I hope, just so the ubuntu refugees can finally have a home.
Thanks for Devuan jaromil. There is still hope for the internet as long as people like you are around.
I just made a quick test of the live DVD in WMware 12 workstation. Doesn't work... It boots, but X-windows malfunctions.
Why don't you just use Windows?
Because Windows doesn't come with systemd, obviously.
Watch this Heartland Institute video
Log message problems can be fixed
They could be fixed if anyone made an actual bug report about them.
Watch this Heartland Institute video
Oh, and everything could be treated like a file, including devices. This concept seems to have gone a step farther in Linux, where even processes can be accessed through /proc.
For values of "Linux" that are equal to SVR4.
(Which goes further than Linux, replacing the ugly ptrace(2) by I/O ops on /proc).
Of course, neither of them goes as far as Plan9.
Watch this Heartland Institute video
They could be fixed if anyone could demonstrate that they exist.
Watch this Heartland Institute video
Everything was fine with Linux until pulse-audio.
Well, except that sound didn't work.
Watch this Heartland Institute video
In other words, init has to do some things hot swapping has to do, but hot swapping doesn't need to do other things init needs to do.
It seems that init needs to be very light, only starting and managing two high level hierarchy deamons: hardware (devices) manager, and software (processes) manager, and the two should optionally synchronize if system dependencies require it. Then, when the two managers are ready, a high level, secondary init proces PID 4 should be started to bring up the system as scripted.
for me it's very simple
TL;DR --> systemd changes kept breaking parts of my linux system
Long story:
I used Debian for over a decade before systemd and only once did I have an update causing serious breakage in that time
Then suddenly systemd dependencies starting showing up everywhere.
Which WOULD be fine except that, sudden
is fine came systemd and suddenly I had problems every couple of months, all of which turned out to be 'software function X that has worked ok since forever, now uses systemd and the upgrade broke things'. And ily I'm having a major breakage every couple of weeks/months, and all of them turned out to be 'subsystem now uses something provided by systemd no no longer works'
In all cases the easier fix was 'switch to something without the systemd dependenc' (cause systemd is an opaque spaghetti system with bad documentation.)
I got tired of it, and have been running devuan without problems, since shortly after it became available
Hi Bruce,
Nice to see that you're still taking an interest in Debian ;-)
Perhaps you can explain why you favour Devuan over simply running Debian with the init of your choice installed.
The reason that I ask is that (prompted by a comment down the thread) I just tried out the live version of Devuan ASCII, and I see that is is true that Devuan now includes libsystemd0.
While I personally see nothing wrong with that, I've gained the strong impression that the fundamental reason for setting up Devuan in the first place was to avoid including that library.
If one is motivated to avoid every scrap of systemd, then I don't see how Devuan can now be considered satisfactory.
If on the other hand one is willing to accept having libsystemd0 (so that programs can sensibly accommodate running on systems with and without systemd) then I'm wondering what is supposed to be better about using Devuan than simply using Debian having selected one of the several alternative inits.
Is this about bugs that are being left unjustifiably unfixed in Debian?
If that's the case, and there are reasonable bugs that are being ignored, then I'm confident that the Technical Committee would give such cases a sympathetic hearing (and I say that as a current member of the committee).
Cheers, Phil.
Debian: GNU/Linux done the Linux way
It is incredibly common to see people who don't read the manual or refuse to to end up with issues around logging, daemons shutting down etc.
Systemd does a lot of things poorly but it's behaviour on starting / stopping daemons and logging is well documented and unfortunately also highly configurable. There are some definite bugs with mounting network filesystems during boot and the like, but whenever I hear about someone missing logs or having a daemon randomly disappear, that is entirely user / distribution maintainer error.
In other news the Linux kernel doesn't fit on a floppy disk. I fail to get upset about 1.6MB of something doing something more intelligent than relying on 100s of customised scripts and dumping PID files somewhere.
It just worked before.
Someone put a fuckton of effort into making sure what little the system was capable of worked in your case. This was not a glowing review of sysvinit.
Bollocks. They adopted it because it became a dependency of other software
You know when you look back at the history of something you need to start at the beginning and go forward, not start at today and go backwards. There was precisely zero software that depended on systemd when major distros adopted it.
Even now the amount of software that has a dependency on systemd can be counted on one finger, and some prominent systemd distributions actually didn't even feature said software.
I get it though, understanding the motivations behind people is hard when they hold their technical discussions on open mailing lists. When it's all done behind closed doors we can start conspiracy theories, but now... reading... uah!
In terms of memory or disk space it's trivial. In terms of 1.6MB of compiled code, that's a lot of code, a lot of room for bugs.
"First they came for the slanderers and i said nothing."
Tell me about it. How can we trust this Linux kernel thing! The amount of access it has to the system is incredible and just look at its size!
Many of us dont want systemd because systemd tries to fix something that isnt broke and is trying to be something nothing should ever be.
It is just another spyware telemetry attempt to fuck with people. Stop defending it you retard.
No, the only thing that you have to clone is the D-BUS namespace, which of course is the exact same for any other situation where you can replace tools in the Unix-way. It's not like you could replace e.g sed with a tool that no longer listens to stdin and cannot understand space separated strings.
It's one thing to depend on a fundamental API of Unix, quite another to kitchen sink an entire API and support subsystem in as a dependency.
Actually, that's pretty-much what happened for all existing Ubuntu and Debian users. There was no freedom to stay with sysv. Just a "take it or leave it". And the cost of leaving it was having to learn another package manager and another init system (OpenRC) but at least the learning curve was way gentler and there were logs to tell me what I did wrong. And I still got parallel start and a faster boot time on the same machine with the same devices than I did with systemd.
Yeah, actually, you shouldn't call the Linux kernel secure, and no one (not even Linus) would call it small.
"First they came for the slanderers and i said nothing."
Actually it does, in a similar form: srvman - runs everything
Anton
Someone put a fuckton of effort into making sure what little the system was capable of worked in your case. This was not a glowing review of sysvinit.
Yeah, they did that and made it reliable. Now it doesn't work reliably, what an improvement
"You're right," Fisheye says. "I should have set it on 'whip' or 'chop.'"
You know when you look back at the history of something you need to start at the beginning and go forward, not start at today and go backwards. There was precisely zero software that depended on systemd when major distros adopted it.
Uh, no. GNOME was the primary reason Debian adopted systemd.
"You're right," Fisheye says. "I should have set it on 'whip' or 'chop.'"
when i first came across it i investigated the reasons why it was needed. Parallelism was one of the main gists i got. Seems odd to redesign a system init, take away pid 0 all for that. Coming from RH was even stranger or do they constantly reboot their servers? But the real laughing point was logging. Binary logs that apparently stop hacking, lol, and unauthorised access, false syslog entries but then allow u to use syslog anyway... then there's core dump handling which is an abomination. now they do dns and have their tentacles in window managers. Shees, if this is the future of linux i will soon be using apple products.
Anton
But mounting root at that stage is not the work of any init so if I have to guess the problem that you experienced with the degraded btrfs has to do with the initramfs image on your distribution and not with systemd,
It does not matter even slightly whether systemd caused the problem if it exacerbates the problem.
but having not seen this myself I will
...ramble anyway, about things you don't know about.
"You're right," Fisheye says. "I should have set it on 'whip' or 'chop.'"
Like I said, when you willfully ignore the technical discussions you can justify ANYTHING. Personally I think it was leprechauns. They are the reason Debian adopted systemd. Makes as much sense as a package that didn't depend on systemd being the cause. Makes as much sense as anything you want to make up despite the fact that their discussion on the topic is public.
Now go educate yourself ignorantpoo.
Pulseaudio had some issues when I first used it (Ubuntu 8.04 IIRC) but since 10.04 I've never had a single problem with it, including hotplugging audio devices etc.
Systemd? Had to learn the new journal command, took a few minutes. Otherwise it's been fine.
Good for Devuan providing an alternative, choice is good. Now I wish the whingers would just use Devuan (or *BSD or whatever) and stop whinging, particularly on threads that are *nothing to do with systemd*.
But I expect they'll still be at it in 5,10 years.
So throw out all software that depends on a API designed after 1970? No need for SQL-servers because SQL is not a fundamental Unix API, no need for REST/SOAP services because neither is a fundamental Unix API. Seriously now you are just being obtuse, I get that you don't like systemd and I'm fine with that but please don't go completely overboard now.
How can it exacerbate the problem if it's not even involved with the mound process of root to begin with? It's not like sysv init would magically mount it either, you would end up in a busybox or kernel hang either way (and I've been there many many many times with sysv init, e.g right now I have a remote server running sysv init that sometimes can survive a remote reboot and sometimes ends up in busybox).
Note, the OS is able to boot just fine without any of the involved system programs understanding REST or SQL. I would absolutely object to a system that won't even boot far enough to log in and debug without REST or SQL. Applications and non-system services are free to use SQL and REST as needed.
Overly complex dependencies result in brittle systems. There's a lot of good to be said for a system where if the kernel can manage to execute /bin/bash, the admin can do something useful.
Actually, SysV init can and did mount it, following my instructions to allow degraded mode. For the simple reason that SysV doesn't treat admin configuration as a suggestion.
Before pulseaudio Linux audio was rubbish if you were a desktop user.
What? How so? OSS worked fine. You could play games or watch movies and it all worked great. The main limitation is that with OSS you couldn't have sounds playback from multiple apps at once. But honestly playing multiple sounds at once is such bullshit anyways because it's usually a browser pop-under playing an ad.
ALSA was a great improvement over OSS. And if your app was not written by an idiot you could share the audio between them. For me, as a musician, ALSA really improved MIDI in Linux over OSS.