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.
... is a Poettering-Free Zone!
#DeleteChrome
Wait, we need to have a doctorate to bitch about systemd now?
Except for losing log messages and not providing a proper exit status. It's really hard to troubleshoot problems without log messages.
Seems legit
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.
I've had my own ideas about how to "better" engineer Devuan, but there are so many things to do and so little Bruce. :-)
With respect, I think your argument is mooted by the fact that Debian itself exists and is a viable alternative if you want to load SystemD. However, it is entirely possible for you to create what you believe is missing in Devuan, and provide it. You can ignore the fact that such a thing would be more for a ritual definition of universality than for anyone to practically use it - since you have stated your own belief that fulfilling that definition is important.
Thanks
Bruce
Bruce Perens.
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"
Thanks for the bit on mother Theresa. You seem to have your brains together so can you explain what the problems with ststemd are?
caveat: my brain is known to be made of mush, sometimes. as in, some form of dyslexia / delay means i get basic boolean logic wrong, ok? :)
* the first clue is this: https://cve.mitre.org/cgi-bin/... which contains 27 separate and distinct entries, three of them for this year alone. by contrast try searching for "sysvinit" and you get *ONE* entry dating back to 1999. you'd need to start searching for "bash" and start doing a bit more investigation (a bash search refers to several variants) to get a proper comparison.
* the systemd team have been known to ignore bugreports, closing them arbitrarily. not just once but repeatedly. i've seen posts made by people on here which gave references. basically they don't listen to constructive feedback.
* the scope creep on systemd is very insidious and dangerous. there's no consultation about the impact of the changes being made: they're just blithely "handed out" and if you don't like it go fuck yourself is the general attitude. management of firewall rules, fstab, networking, process control: all these things are completely insane to be managed exclusively by PID 1. one mistake and your entire system is compromised (or falls over).
so basically it's down to abdication of responsibility of developers and users to a team that has repeatedly demonstrated a total lack of willingness to recognise and take seriously the responsibility of their role... or more to the point that the distro maintainers *CHOSE WITHOUT CONSULTATION* to forcibly abdicate responsibility on BEHALF of users, the maintenance and running of their system to systemd's developers. if you are not familiar with what happened with the debian "vote": systemd was the absolute worst and least-favoured choice by far and above... and absolutely no explanation as to why that vote was completely and utterly ignored has ever been given.
there are many many articles and examples of why systemd is an extremely dangerous *technical* choice, but mainly it's down to the fact that the users haven't been given any choice - right across the board - due to all major GNU/Linux distros swapping over all at the same time like a flock of birds / shoal of fish. try doing "apt-get --purge remove libsystemd1" and see what happens (or equivalent on fedora, or archlinux). that there *is* no choice is in itself a dangerous precedent (a monoculture).
basically it's really hard to describe.
"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
Their product is crap of no value to me. I will ignore your whiny suggestion that I help improve it.
Devuan isn't Gentoo. It's supposed to be a collection of binary packages with good dependency management. Systemd is by design a poor fit for any such collection that offers an option other than systemd. That's why if you decide to install a Debian Jessie system with SysV init, you have no choice but to install some pieces of systemd as well.
I've had my own ideas about how to "better" engineer Devuan, but there are so many things to do and so little Bruce. :-)
With respect, I think your argument is mooted by the fact that Debian itself exists and is a viable alternative if you want to load SystemD. However, it is entirely possible for you to create what you believe is missing in Devuan, and provide it. You can ignore the fact that such a thing would be more for a ritual definition of universality than for anyone to practically use it - since you have stated your own belief that fulfilling that definition is important.
Thanks
Bruce
appreciated the response, bruce. there is however a caveat in the approach that you recommend (create what i believe is missing and provide it), so let's go through it, to illustrate.
question: what would happen if i did that? created an alternative which included systemd *in* devuan? would the devuan developers accept it? no they would not... because i have spoken to them and they are ABSOLUTELY adamant that systemd be excluded from devuan.
question: so what would be needed instead? an entire fork of devuan would be needed, wouldn't it? so that's something that i would need to maintain, on my own, wouldn't it? bear in mind that it would be a fork of a fork of debian.
question: where would i get the money from to support my family, pay for their food and accommodation and upkeep, whilst doing this work AND paying for the hosting of hundreds of modified packages of a fork of a fork of debian?
what i am saying is that it is a total myth that individuals may achieve "big" things on their own. a project needs a reason: it needs a story. it needs mind-share. it needs FINANCIAL support (based on offers supporting the story) it needs RESOURCES (based on offers supporting the story). it needs people to "buy in" to the story: technical contributions, coding, website maintenance that makes the story real.
the *story* is far more important than anything else, as without the story (the "why") there *is* no motivation. this is codified in simon sinek's ted talk "why great leaders inspire action".
i think, ultimately, you recognise this yourself, as you said: "there are so many things and so little Bruce" :) yes, all of us are only "one". to galvanise us and achieve things bigger than ourselves, we need motivation, we need a "why" that's big enough to sell not just to ourselves but to other people, and backers.
devuan succeeded in selling the story, "let's do debian by removing systemd and adding alternatives in its place", which is itself an incredible feat. but that story was sold on the basis of being AGAINST systemd. it's hurt devuan to do that, as they've effectively lied in their mission statement "devuan is universal and inclusive": it's *not* (because systemd is deliberately excluded).
the next step will be to very carefully heal the damage caused by that decision, and that means putting systemd *back* into devuan (as just another init option). how do you (plural, collectively) sell that story? i don't know. do i have time and funds and resources to even focus on *selling* that story, beyond the occasional slashdot comment? no, not really: i'm focussing on RISC-V and other things full-time, now.
do i have the funds and resources to "do the work myself"? absolutely not! i've been down that road many times and people have fucked me over enough times, spongeing off of my efforts for me to know that i'm not going to be doing it again. but more than that, even if i did it would be a dis-service to everyone in the devuan project, as it would deprive them of the opportunity to heal themselves of the psychological harm caused by being "against" systemd.
I've had my own ideas about how to "better" engineer Devuan, but there are so many things to do and so little Bruce. :-)
With respect, I think your argument is mooted by the fact that Debian itself exists and is a viable alternative if you want to load SystemD.
apologies i missed this the first time, however it's probably best done as a separate response anyway. so it goes like this:
1. i have used debian since 1996, since phil hands donated me a 486SX25 laptop so that i could work on samba 1.9.16 and beyond, on the move. its flexibility and reach means i will not use anything else.
2. systemd is so bad - the developers so psychologically damaged - that i will not use it. i will not even tolerate libsystemd1 being on systems that i manage, so it has to go (entirely).
3. devuan *would* be ok... but the same analysis-mind-set that says "libsystemd1 has to go" *also* has me looking at the conflict in devuan's mission statement, and i won't use it because they are *AGAINST* systemd... it's the other side of exactly the same coin.
4. with the sheer overwhelming volume of packages, files and so on from debian that i have (dating back nearly 10 years) "upgrading" to devuan, or dropping debian and going with FreeBSD, or anything basically *other* than "sticking with debian" is simply not possible. period. some of my systems are still "apparently" on debian 7.0 except they're not: they've just been on debian/testing all that time and continuously upgraded as necessary... and i do NOT mean "apt-get dist-upgrade"d.
5. so i am stuck between a rock and a hard place.... and THANK GOD... angband.pl exists. it contains recompiled MODERN (maintained) debian packages, modifying them to have "--without-systemd" in the necessary xorg, pulseaudio, samba, udev, cups and dozens of other packages... and also *REINTRODUCES* console-kit, polkit, udisks2 and many many other packages that were REMOVED (foolishly) from debian as "no longer necessary".
the situation is so stark that i even at one point actually removed libsystemd0 (and udev) from a live-running debian system. i had to use /sbin/MAKEDEV from /etc/rc.local to do it. it was... awful. but, i got what i wanted. then, thank god, i heard about angband.pl. https://news.slashdot.org/stor...
bottom line is: debian is fine (as long as you want debian *and* systemd). devuan is fine (as long as you want debian-like and *don't* want systemd). however that leaves absolutely no room for people who do not want debian with systemd, who cannot (for whatever reason) install or convert to devuan.
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...
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/
Well, logically you should give that piece to Debian. It would fulfill Debian's (ill-considered, IMO) decision to include SystemD, and would make life easier for Devuan, and it's nice for Debian to make life easier for its derivatives. Now, I guess Debian could be a stick-in-the-mud about that. Have you asked them?
Bruce Perens.
Seriously. For my life, i cannot understand why the Linux community is so worked up over it.
Smart people would conclude that that might mean that systemd is actually solving essential problems.
"I know I will be modded down for this": where's the option '-1, Asking for it'?
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.
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.
Considering that I've had one problem with init scripts ever, and it was so long ago I found the solution in an actual paper book, I'd conclude that you're talking out of Lennart's arse.
Confucius say, "Find worm in apple - bad. Find half a worm - worse."
Comment removed based on user account deletion
One anecdote, versus just about all distribution maintainers. I know how I believe.
"I know I will be modded down for this": where's the option '-1, Asking for it'?
Sorry, but if you don't understand why a service manager should know about which file systems are mounted and whether or not the network is up before starting services, you have absolutely no authority to talk about these things.
As for process control: that's been a badly implemented part of init since its very beginning, as the ultimate ancestor process on a *nix machine. That systemd in its role as init and cgroup manager allows more fine-grained process control is a good thing.
And firewalling isn't even handled by systemd. The closest thing is the IPAddressAllow directive in unit files, which is a direct re-implementation of tcpwrappers, not firewalling.
"I know I will be modded down for this": where's the option '-1, Asking for it'?
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)
"Uuuuuhhhh... Kinda need pick this one apart. They aren't managed by PID1:" - you are onto a loser there, the anti-systemd mob thinks everything in the systemd project is mandatory and runs PID1 - no amount of explanation will cure them of that.
"The hands that help are better far than lips that pray." - Robert Ingersoll (1833-1899)
The same is true in devuan.
Devuan ASCII even rolled back on the removal of the libsystemd dependency that it started to removed in Jessie. Now the packages that were only changed to not depend on libsystemd are again taken straight from debian and include that again.
Devuan ASCII also ships with elogind, which provides the same APIs that systemd-logind provides on debian and undid all the changes that were in devuan jessie that removed the dependency on those APIs. They even celebrate that "archivement" in the devuan release notes!
Devuan ASCII is much closer to debian than devuan jessie was. The only non-trivial diff at this point is the branding and that they block the systemd deb (but none of the rest build from the same sources) from their distribution.
I do not understand why devuan is even hailed as systemd-free at this point. With jessie they at least tried to remove systemd tentacles, but they have given up on that entirely in ASCII.
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?)
I've said for years that Bruce Perens is an insufferable narcissist with an ego the size of mount Everest. If that sentence doesn't convince you, I don't know what does...
"A door is what a dog is perpetually on the wrong side of" - Ogden Nash
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.
Most of them are not related to systemd. For example:
I do not see anything bad with that sentence. Time is a finite resource, and doing things requires time. Also: he put "better" in quotes. To me that seems like an acknowledgement that better is not an absolute term.
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.
This comment is completely disingenuous. The bugs on that list are just for things that mention systemd. Like CVE-2018-1196, the second on the list, which is simply launched by an init service. Better yet, check out CVE-2017-11565. You think that's a "bug" in systemd? (Hint: it's more like -1 bugs for systemd---starting with a systemd unit makes the system resistant to the attack).
Also---due to the scope creep of systemd---systemd is obviously going to pick up bugs that would just have been in other programs. That doesn't mean they're bugs in PID1.
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?
So if we find another guy who have had just a single problem with systemd then that will immediately change your mind and you will switch to systemd?
You mean like dropping logs and not providing a proper exit status? Both of which are false btw.
No, that's not me.
Search for COME FROM, btrfs, RAID1.
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
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.'"
After it became quite obvious that the NSA's selinux project was a little too obvious a vector for backdoors, an alternative method for introducing opaque, complex, unneeded, and bug riddled code as close to the kernel as possible was needed. Systemd is not so much a technical product as it is a social engineering one.
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
... 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.
What are you referring to? I am running Devuan ASCII from a default install and it has only libsystemd0 installed (a systemd stub).
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.'"
what would happen if i did that? created an alternative which included systemd *in* devuan? would the devuan developers accept it? no they would not... because i have spoken to them and they are ABSOLUTELY adamant that systemd be excluded from devuan.
question: so what would be needed instead? an entire fork of devuan would be needed, wouldn't it? so that's something that i would need to maintain, on my own, wouldn't it? bear in mind that it would be a fork of a fork of debian.
Point the first, not getting your packages included in a distribution does not prevent them from being used. You can even create your own metadistribution which includes them into another distribution if users adopt your repository.
Point the second, you're asking about putting seeds back into seedless watermelon. You don't do that. You just go get a watermelon with seeds in. We still have them. And we still have Debian.
"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.
I'm glad :)
"First they came for the slanderers and i said nothing."
Fine grained control is useful. I'm afraid that the grasping intrusion into other systems, reliant on deep integration with the Linux kernel, is non-portable and intrusive to many other stable parts of the system. So was the non-necessary binary system logging, which could have been left as plain ASCII, the intrusion into network configuration with the DHCP components, the intrusions into auto-mounting, the unnecessary and undesirable intrusion into user process monitoring and hardcoded killing of background user processes without notification. So was the intrusion also includes an extremely confusing and destructive rewraping of SysV init scripts into systemd which silently and unnecessarily _discards_ the ordered startup formerly inherent in systemd init scripts. It's been confusing, unnecessary, and optimized based on what can be _added_ to systemd to expand its approach, rather than what can safely be left out.
I'm afraid the result has cost Linux market share and hindered major Linux OS releases.
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
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
So, if all we need to run X without being root is to use a relatively small daemon, then use that daemon. There's no need to assimilate it into an ever-growing behemoth of incomprehensibility.
Whether it's systemd or Microsoft, the problem is not the software but with the politics of the organization behind it.
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.
Ego? Nah. If I really had that kind of ego, I'd be telling you about my huge... oh, never mind.
Bruce Perens.
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.
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.
> 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.
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.
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.
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.
The problems with systemd are technically features, not bugs, because they're working as intended.
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."
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
But you know it isn't.
Watch this Heartland Institute video
At a more practical level, Debian already provides Debian with systemd and it would be a waste of anybody's time to add that, not just yours.
Hell. Debian also provides Debian without systemd.
What, exactly is the point of Devuan?
Watch this Heartland Institute video
Hey, you're talking to LKCL, a well known loony. Don't expect logic.
Watch this Heartland Institute video
No, she wasn't pro war.
She was pro death and suffering, however.
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
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."
you show me a system where systemd_logind runs as PID1 then. Mine's currently running as PID 796
"The hands that help are better far than lips that pray." - Robert Ingersoll (1833-1899)
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.
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."
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.'"
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.
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.