Slashdot Mirror
Devuan Jessie 1.0 Officially Released (softpedia.com)
prisoninmate quotes a report from Softpedia: Announced for the first time back in November 2014, Devuan is a Debian fork that doesn't use systemd as init system. It took more than two and a half years for it to reach 1.0 milestone, but the wait is now over and Devuan 1.0.0 stable release is here. Based on the packages and software repositories of the Debian GNU/Linux 8 "Jessie" operating system, Devuan 1.0.0 "Jessie" is now considered the first stable version of the GNU/Linux distribution, which stays true to its vision of developing a free Debian OS without systemd. This release is recommended for production use. As Devuan 1.0.0 doesn't ship with systemd, several adjustments needed to be made. For example, the distro uses a systemd-free version of the NetworkManager network connection manager and includes several extra libsystemd0-free packages in its repository.
So, how do I install systemd on this?
Props to them for the commitment but systemd ( and all its warts) has won the day.
Get your PostgreSQL here: http://www.commandprompt.com/
In other news, I've installed my own country inside my house, without Trump as president.
How does this affect anyone? Linux has 2% market share. That tiny percentage is dominated by Ubuntu and Red Hat. Why does anyone care about this distribution? Nobody will use it. It is inconsequential and isn't news at all.
Developers use Ubuntu; server admins use Debian. And server admins who consider systemd to be a destabilizing atrocity that chucks reliability out the window in favor of GNOME edge cases now have an option.
What I'd really love is a Fedora fork (or EL clone, such as Scientific Linux) that reverts to the EL6 initscript build-out and considers systemd as just another option to be used on top of a standard SysV base -- much like xinetd. There if you need it, but not affecting the core.
Hire a Linux system administrator, systems engineer,
but i already have slackware14.2 fixed up nice the way i like it, and i am not wiping all that off to try out a 1.0 release, but still i have to say kudos to Devuan because i am one of those hardcoded systemD haters http://without-systemd.org/wik...
Politics is Treachery, Religion is Brainwashing
How does this affect anyone? Linux has 2% market share. That tiny percentage is dominated by Ubuntu and Red Hat. Why does anyone care about this distribution? Nobody will use it. It is inconsequential and isn't news at all.
While I agree with your general sentiment, I think your counting is off. I think there are a few non-desktop systems that run linux, so that 2% number may be a little low.
If Devuan was offered as a default AWS AMI, I would prefer to use it over Debian.
Often wrong but never in doubt.
I am Jack9.
Everyone knows me.
Obviously, they didn't do it for market share. They did it for themselves and then shared it with everybody. Bravo to them.
> Linux has 2% market share.
He said, posting from a machine that doesn't use Linux, the packets quickly routed through a machine that uses Linux, to a farm of Linux boxes, to a box that runs Linux, which stored the information.
> I learned Unity.
Unity3D, the multiplatform development environment, or Unity, the now-defunct user interface?
> I learned systemd. It's not bad at all.
The problem is really how quickly it blazed through the community, as major distro after major distro switched to it, and how it was suddenly present in everything. Opting out was overly difficult. If it had moved slower, you'd have seen systemdless distros pop up in due time, instead of after the fact.
Complains about trolls by trolling about it. Then it gets modded up. Self awareness, fuckers. Do it. It's never too late to better yourself.
Unity3D, the multiplatform development environment, or Unity, the now-defunct user interface?
This is a very stupid question, cfalcon.
server admins use Debian. And server admins who consider systemd to be a destabilizing atrocity that chucks reliability out the window in favor of GNOME edge cases
What are these server admins doing? I have the defaults on EL7 and Debian 8 and all I notice is the VM's come up much faster and with fewer race conditions than under previous inits.
This is over dozens of unique VM images, but they're all doing pretty standard server stuff. What unusual things are people doing that break systemd-based distros?
I understand that some people have philosophical objections - fine - but I haven't heard any of my colleagues complaining of actual instability or unreliability.
My God, it's Full of Source!
OUTSIDE_IP=$(dig +short my.ip @outsideip.net)
Do you still pay taxes to Trump's country?
If so, hahahahahahahahahaha.
I've run Debian on laptops/desktops since 2002. I might give this a shot. SystemD sucks.
Yes, yes, that's all very interesting, but let's see how inclusive their Code of Conduct is, and what their project diversity stats look like, before we decide to take them seriously.
I hate systemd but there's no way I'm running any software dominated by a bunch of privileged white men.
Amazon's Default AMI Linux is systemd-less, and is very possibly the most widely deployed linux distribution in use on servers.
Defunct? Did it somehow stop working after it was announced that Unity8 won't be officially delivered? Did the code vanish, break or otherwise stop doing what it does? Don't forget Ubuntu 16.04 LTS will support it officially for many more years to come, and Unity7 will only migrate over from main to universe.
That said... it's the best desktop environment I've ever used. So many things done properly over GNOME. As of 17.10, Ubuntu will DOWNGRADE it's desktop.
Fascinating. By the same logic, ACs have around 0.001% of the intelligence of normal people. Hey, that one may actually be true!
Most ACs are not even worth the keystrokes to insult them. Be generically insulted by this and ignored otherwise.
and OS instead of children: R! /path/to/remove/.*
https://github.com/systemd/sys...
Pottering's Response:
I am not sure I'd consider this much of a problem. Yeah, it's a UNIX pitfall, but "rm -rf /foo/.*" will work the exact same way, no?
Unrelated, I also found sound worked much easier in FreeBSD than it did in Linux with pulseaudio. I wonder who designed that trash.
Well the rest of us that need to do real work have moved to FreeBSD
I genuinely mean it, good on them. Systemd isn't of that bigger deal to me, but at least these people have gone ahead and done something instead of just sitting around complaining about the fact that they don't agree with having systemd in a Debian default install. That's my biggest peeve with a lot of people in the Open Source community.....they're good at complaining, but they never do anything about it. These people actually have.
I wish them all the best and I hope Devuan has a long and happy life. Perhaps I'll check it out some time :)
I have installed Devuan on a laptop so far, and will be switching my other systems over time. I had one problem, the lack of a good replacement for network manager, and it seemed that as soon as I complained that the developers put network-manager in the next test release.
Bruce Perens.
c-title
I don't see how this is modded as flamebait, except that this community has a pretty obvious anti-systemd bias. Mr McGonigle was pointing out the hyperbole used by the vocal systemd opponents.
/. account to comment on systemd stories. Maybe I take exception to the level of hate directed at the members of the "community" for the work that they've done. If you see this Lennary Poettering, thank you for all your contributions! Ignore the haters, systemd is great and people don't have to use it if they don't like it.
My own anecdotal systemd experience has been positive, on desktops and servers. It is a major improvement over sysvinit, and many of the improvements make it a lot easier to admin a server.
For some reason I only ever use my
Why is this marked as flamebait? It is a legit question: what conditions cause server stability problems with systemd? I've heard of problems with some hardware that is pretty specific to desktop computers, and complaints about using the logging tools. But similar to the parent poster, I've had no problems with it on server farms.
. If it had moved slower, you'd have seen systemdless distros pop up in due time, instead of after the fact.
What? There are still well maintained distros that never included systemd, others that don't enable it by default, and some major ones that can be configured to not use it even when it is the default init. Slower uptake wouldn't have gave us systemd-less distros sooner, as they have always been there.
...or if he posted it from his tablet or phone, better than even odds that was also a machine using Linux.
"Nine times out of ten, starting a fire is not the best way to solve the problem." - my wife
I've been using Devuan for some time now. I actually lack a lot of the required technical expertise to really have an opinion one way or the other about systemd.
However, I've been around long enough to know what kind of effect, 'dumbing things down has', and it's a great staple in American culture.
It's this sort of why have 5 buttons when you can have 1 button do everything. If you know what I'm talking about I don't need to explain it, and if you don't, you probably don't care and enjoy things being dumbed down. I'm sure I also enjoy a few things others would consider dumbed down, but...
When there are moves to take away, 'options', I'm against it. Convenience, should not be confused with simple and elegant efficiency. So for me, as soon as I heard about Devuan, I was on board.
Glad to hear Devuan reached 1.0.0 finally! Great job folks. I appreciate it. I have the option and have had for some time now, to use one of my favorite Distributions with the OPTION to not have to use systemd.
I don't see how this is modded as flamebait, ...
Because some moderators downgrade things they don't agree with or understand - like contrary opinions or sarcasm.
Welcome to /.
It must have been something you assimilated. . . .
How does this affect anyone? Linux has 2% market share. That tiny percentage is dominated by Ubuntu and Red Hat. Why does anyone care about this distribution? Nobody will use it. It is inconsequential and isn't news at all.
Let's see... Windows only holds a majority in the DESKTOP market.
In mobile, the vast majority of devices are Android, and iOS comes in second. All Android devices are Linux. They also don't use systemd.
In servers, Windows holds a minority market share. Guess who the leader is? Linux. Even on Microsoft's own cloud (Azure) a hugely significant portion of users are using Linux - the numbers keep going up for Linux - started out 1:5 use Linux when they first published about it, and it's something like 1:3 now.
Want a super computer? The market is pretty much dominated by Linux.
Want a main frame? Well, you're either looking at Linux or one of the older systems.
Oh, and embedded? Linux outpaces most everyone when a non-custom OS is possible; even many custom OS's are tending to be based on Linux.
So yeah...Linux has a huge world-wide, cross market, cross functional market share. All-in-all, we're probably talking somewhere in the 70-90% range of the computer industry is using Linux in some form.
Truth is like the sun. You can shut it out for a time, but it ain't goin' away. - Elvis Presley (source: imdb.com)
Perfectly legitimate question. As a sysadmin myself, only problem I've had with systemd is when I upgraded one system. It had an entry in the /etc/fstab file for a removable USB drive. I had to append "nofail" to the options for that entry, to ensure the system booted properly.
Otherwise, it's been smooth sailing. From a practical perspective, systemd works fine.
Someone with mod points and a liking for sceptical attitudes will soon ensure you're modded up again.
Oh shit, I didn't realize that my software has to be the most popular for me to use it. I totally should have read the manual more closely.
“Common sense is not so common.” — Voltaire
REMEMBER THE MURDER OF IAN MURDOCH, creator of Debian Linux and leading member of the Free Software community, killed Christmas 2015 by the notoriously corrupt San Francisco police department.
Everytime I read about the systemd wars I think of this Dilbert comic strip and smile!
I gave systemD a spin on a VM to see if it would be suitable. Unfortunately, it flunked when I disconnected a redundant drive and it flatly refused to even attempt to mount /home in degraded mode. It just dropped me to the emergency shell. I attempted the mount command by hand to see the diagnostics and iot worked perfectly. It seems there is no way to make a command imperative. I looked on the mailing lists and found exactly the same problem with RAID. The response was a collective shrug.
I can absolutely work around that problem, but I can't just put aside the fact that the developers just don't give a crap because it would be a hard problem and their architecture won't accommodate a solution cleanly.
It's just too brittle for me to want it in charge of a server.
How dare you defend systemd! Only the opinions of crusty old sys admins who were around when Linus' balls dropped are relevant here!
But seriously I don't really get it either. I made the change from Squeeze to Jessie for my server and while it was a little frustrating at first I soon learned my way around systemd. I haven't had any stability or unreliability issues either. Then again I've only been using Linux regularly for the past 5-6 years, so I don't really have any emotional attachment to the way things used to be.
Only crack the nuts that crack. You don't put the ones that don't crack in the sack.
Somehow this gets modded down, yet a reply gets modded up that doesn't even know what Unity is or that this is not that first systemD free distro.
Can I do apt-get install systemd ?
The dangers of excessive individualism are nothing compared to the oppressiveness of excessive collectivism
From what I see in the discussion, the correction has been merged. So it has been recognized as a bug, and corrected as such.
I i was a cop with a Debian system i would also be tempted
The dangers of excessive individualism are nothing compared to the oppressiveness of excessive collectivism
That shit is not "linux".
An option that's merely 2.5 years out of date compared to Debian proper. Which is already not famed for being bleeding edge.
"I know I will be modded down for this": where's the option '-1, Asking for it'?
The initial implementation of systemd on CentOS 7 left a great deal to be desired.
Whether it's Lennart's fault or someone else's it managed to piss a few people off - hence some of the (frequently shouted down) comments about systemd here.
Not really an server admin, but all I can say is that I've spent more time trying to clean up systemd related problems the last couple of years than I have on all other similar problems since I started using Linux 20 years ago, possibly excluding X11-configuration in the nineties.
DHCP hasn't worked for a year, since every time wicd assigns an IP address, systemd removes it again. Mounting crypted disks broke because the config file was parsed differently. For reasons unknown, it often takes several minutes to shut down a machine. But hey, my laptop boots around one second faster, so it's supposedly a win since boot time apparently trumps all. On the other hand, waiting ninety seconds, serially, for non mountable items in fstab has been fun on a few machines.
These are off the top of my head, I've really lost count of the number of systemd related issues we've have to dealt with, but it's been a huge time sink.
Everything that runs the linux kernel is linux. If the userland is GNU or Android or whatever else doesn't matter.
Public shaming works.
You got a collective shrug because the problem was with mdadm not reporting the UUID correctly early in the boot process and not with systemd itself. This was fixed last year in mdadm 3.4.4 and if you search on the topic you won't find a problem of booting degraded affecting current releases of Debian, Ubuntu or CentOS, unless your mdadm config specifically says to not boot degraded.
The thing people are complaining about is precisely what lead to this problem in the first place. Everyone complains about the monoculture of systemd, but the monoculture of sysvinit not being effected by some design bugs in other software is what is causing a lot of this other software to fail due to undocumented or unexpected behaviour. Then people misattribute it to systemd and complain when systemd developers don't bend over backwards to accommodate bugs in other people's software.
Appreciate the work the Devuan team has done to make another Linux distribution option.
I wonder who designed that trash.
Someone who wanted an audio subsystem capable of meeting the user requirements of people in the 2000s instead of people in the 80s. It's quite telling that every distribution adopted it despite your assertion that it's "trash".
One, as you say, it's a philosophical issue. It goes against the small sharp tools principle, and also people don't like being forced.
Two, you say it works for you. That's nice, but it seems that there are people for whom it doesn't work, and when it doesn't work it doesn't work big time. It's like a dog that doesn't bite until the day it chews a kid's face off.
Confucius say, "Find worm in apple - bad. Find half a worm - worse."
I am so happy. It boot (from SSD) fast. At same speed than Ubuntu 16.04
It takes a couple of seconds extra to shut down, but I will survive.
It is a relief to see Linux working without SystemD around doing extra and unneeded tasks.
I installed with Mate. It seems I will be comfortable and will not miss ubuntu 16.04. We will see.
I had a couple of cases that a server broke bad and I suspect of system D. It is a point of failure strong because everything depends of System D in Ubuntu 16.04
I was waiting to migrate my servers from ubuntu 14.04 because all the updates I have to do to scripts.... Now with Devuan there is not more need of waiting for me
Who "implemented" it on CentOS 7? If its just related to CentOS 7 i would hazard a guess that its a bad implementation by the distro, i think most distros went through some early config teething problems.
"The hands that help are better far than lips that pray." - Robert Ingersoll (1833-1899)
What are these server admins doing?
I can't speak for them, however in our use cases we use initd to control server processes where we want control over the application latency, generally using CPU isolation and affinity. We built a test lab to understand how systemd would interact with our application and so we could learn it well ahead of our clients attempting deployment. This is a quality mindset used in ISO environments that prevents downtime.
For some inexplicable reason a lot of people seem to think that if you want to use initd you don't know anything about systemd which I find to be a poor understanding of the sheer variety of use cases and perhaps a little condescending.
My reasoning for using initd is specific and based on our test cases. Some of those reasons (off the top of my head) initd isn't a large monolithic process that generates a lot of software interrupts, we don't want a process manager to manage an event system we don't need, unit files are soft replacement for not knowing how to shell script properly, journalctl and binary logging poses a threat to uptime and timely root cause analysis, initd doesn't presume a large base of (potentially redundant) knowledge of the properties required to control it.
Sure there are some good points about systemd and some valid criticisms of initd (particularly the way the rc scripts are used) however all that speaks to is that it is initd needs a matching event management system that controls and is controlled by initd. systemd tries to be that and a process management system.
I have the defaults on EL7 and Debian 8 and all I notice is the VM's come up much faster and with fewer race conditions than under previous inits.
That's great, however systemd has no effect on application processes that take time to start. These are easily parallelizable by using initd's existing inittab file so it doesn't impact boot.
This in practical terms means the difference between going home and doing an all nighter.
My ism, it's full of beliefs.
Someone who wanted an audio subsystem capable of meeting the user requirements of people in the 2000s instead of people in the 80s. It's quite telling that every distribution adopted it despite your assertion that it's "trash".
why not.. like.. umm.. late 90's? you know, when it it just worked.
world was created 5 seconds before this post as it is.
The proposed correction was merged even before Poettering's comment.
You can still run Debian with an init system that is not systemd. In fact, several Debian Developers are doing exactly that. There are even packages in the archive which facilitate using software that would otherwise require systemd as an init system to work without it (see systemd-shim). So what is Devuan doing that Debian doesn't offer already? Is it that Devuan compiles everything without even libsystemd0? But what harm is having libsystemd0 installed if you can at the same time still use your init system of choice? Is this really about everything systemd being evil and that's why it must also be evil to link against their shared library? I hoped this was a matter of how one likes to start and manage system services for which there are many init systems available but also rejecting a shared library seems to me like there is some emotional nonsense mixed in as well?
"poettering locked and limited conversation to collaborators on 17 Apr"
Ah yeah, smart move.
I don't understand why everyone seems to love Ubuntu. The desktop is horrific. It makes me long for Windows Vista. It's truly awful.
Fedora with KDE seems to be the most sane option at the moment. Might try Debian with KDE because apt is rather nice and I'm used to running it on various Pis and VMs.
const int one = 65536; (Silvermoon, Texture.cs)
SJW, n: "Someone I don't like, and by the way I'm a fuckwit" - AC
Ahem, but isn't it the same argument we hear about systemd: if all distros use it, so it must be good?
Funny thing, when you do not use it, things no longer work. Things that worked for decades. Because the code that was there before was removed (remember David Edmundson from KDE, concluded that "In many cases [systemd] allows us to throw away large amounts of code whilst at the same time providing a better user experience https://linux.slashdot.org/sto... ).
So, from a distro perspective, not using it mean doing the extra work to make things work as they did before. Work to get nothing more than what was before. Work for nothing, in short. Who wants to afford that? Because it is not meant as an alternative but a replacement for all.
Now, does that benefits to the end user? Well, as long as the replacement suits your needs, no problem. When it breaks, that is another story. /foo/.*" will work the exact same way, no?", not only it shows lack of knowledge (annoying considering how much his decisions can affect GNU/Linux main distros), it shows lack of concern about other people priority. /foo/.* and rm -rf /). But what when it is not an issue with such an obvious answer? Well... Guess.
And, then, how the Poettering and his gang manage things is quite important. When Poettering write "I am not sure I'd consider this much of a problem. Yeah, it's a UNIX pitfall, but "rm -rf
And, here, we can laugh about it because he is so obviously wrong (as shown in the comments, tests about rm -rf
You must have been using a different audio system to me in the late 90s if yours "just worked". By contrast, audio on Linux is now in the "solved problem" category, for me at least.
Public shaming works retroactively.
Sound on Linux in the late 1990s didn't really "just work". If you were lucky, you could get one application (and only one) to send audio to your audio card. The situation was so bad that many people used ESD, a quick and dirty hack from the Enlightenment people with horrible latency, to try to get something approximating to manageable sound on the GNU/Linux desktop.
The reason you probably think sound "worked" during the late 1990s was that it was considered a small miracle if sound worked at all, given the lack of drivers, and most people were happy if they reached the point that they got anything to work. Back then it wouldn't matter if running your MP3 player meant no notification noises, because the chances are the latter weren't important (and could be resolved with ESD anyway), and the MP3 player being capable of playing MP3s was "good enough". This problem ran right into the early 2000s.
It was once the drivers started to work, ALSA reached critical mass, etc, that the shortcomings of having the kernel manage audio as a single device started to really show up.
PulseAudio has a bad reputation not because it isn't necessary, but because early versions (1) had problems, (2) clashed with mountains of hacks that everyone else had installed to get around the problems kernel audio, and (3) the developer had a reputation for being a little bit prickly.
If PA wasn't necessary, then given 1-3, do you really think all significant GNU/Linux distributions would have adopted it?
You are not alone. This is not normal. None of this is normal.
So basically your complaint is that systemd does provide something that developers like David find useful?
How about providing something equally useful that KDE/Gnome can use instead?
I don't think many of the people complaining about systemd are "crusty old sys admins", I think we're talking about mostly hobbyists who don't like change. SysV init has never been considered a thing of beauty by those who have to maintain GNU/Linux (or any *ix) systems. That's why systemd is the latest in a long line of replacements, from Apple's LaunchD (also about to be used in FreeBSD) to Ubuntu's Upstart.
And much of hate seems to be the developer rather than anything to do with the program itself. Upstart never got this amount of hate, and many claim, probably trollishly, that they switched to FreeBSD, which is in the process of upgrading from the simpler and less flexible BSD Init and has never, to the best of my knowledge, run sysvinit.
You are not alone. This is not normal. None of this is normal.
Every time I see this kind of drivel, I have to wonder who are you trying to convince? You do realize that if DHCP didn't work in SystemD, not a single GNU/Linux distribution would actually work properly, right? Everyone would have mass dropped use of Ubuntu, RHEL, CentOS, Debian, or stuck to older versions, because their computers no longer connected to the network.
And mounting encrypted disks "broke because the config file was parsed differently"? Really? You mean you didn't configure it properly, and you're blaming systemd?
As for the rest: I have multiple Ubuntu machines, and I can tell you not a single one takes more than a few seconds to power down. Windows, yeah, that takes an age for some reason. Ubuntu? Nope. What are you running your systems on, an 80386?
Also not a server admin -- but admin for multiple workstations and portables. You've reproduced my experience exactly, except that I'd say "in even the last couple of months" instead of "in the last couple of years." And I've been running and administering Linux systems since the mid-Nineties (i.e., over twenty years).
"My opinions are my own, and I've got *lots* of them!"
The only brittle thing is your understanding and lack of skills. Perhaps OSX would suit your better.
> Maybe I take exception to the level of hate directed at the
Maybe because some of us simply prefer not to use systemd, and see piles and piles of hate and derision directed at us. Some of that hatred has come directly from Lennart Poettering, as well.
The living have better things to do than to continue hating the dead.
Problem is, when it doesn't work it is 99% usually one of the following problems,
A) They intentionally broke it, or were doing something to workaround missing initd functionality and it clashed with systemd. For example, see above post where user is using wicd without disabling an already existing network daemon, probably networkmanager. They blame this on systemd. Solution: use a clean systemd distro, and migrate old configs on a case-by-case basis as the need arises. Many old and crusty initd workaround are no longer needed, and if you blindly go in trying to use them anyway, you are going to create problems for yourself.
B) Software has bugs in it, bugs that were not noticed before with initd because initd did not depend on that functionality working correctly. For example, see above post where user couldn't boot in degraded mode because of a bug in mdadm. They blame this on systemd when all systemd is doing is depending on mdadm to report the drive UUID correctly. The fix in mdadm fixes the problem. Probably, in this case, initd is not affected because it doesn't (or can be made to not) use the UUID when mounting the pool, which is a generally bad practice overall. There is a fair quibble to be had here with distro maintainers who have not properly vetted all aspects of the system to uncover these bugs earlier in the process, but getting these bugs out into the open is the only way they get fixed.
For some inexplicable reason a lot of people seem to think that if you want to use initd you don't know anything about systemd
It would help if you didn't reinforce that perception with such a poor use case justification.
initd isn't a large monolithic process that generates a lot of software interrupts
Systemd is not a large monolithic process. By software interrupts, I assume you mean it uses dbus instead of just piping everything to stdout. The difference really is whether there is a defined message pattern to the IPC (dbus) or just a dump of whatever data in whatever random format that has to be parsed by the receiving process (FIFO). While the latter has certainly worked, I think it is hard to argue against the former as a generally good practice.
unit files are soft replacement for not knowing how to shell script properly,
Why should you have to know how to shell script to boot your system properly? How is it better to have a full shell interpreter executing arbitrary logic to load system services better than just parsing a config file? That argument just makes no sense whatsoever. Shell scripts were a quick and dirty way of getting a system up and running. The fact that they have lasted so long is a testament to how flexible the shell scripting languages are, but viewing it as anything other than a workaround for lack of necessary functionality in init is crazy.
journalctl and binary logging poses a threat to uptime and timely root cause analysis
Another argument that makes no sense whatsoever. Nothing inherent about binary logging prevents root cause analysis. Teach your tools to read the binary log, and it will actually be better because you will get a lot more information.
however all that speaks to is that it is initd needs a matching event management system that controls and is controlled by initd
You are contradicting yourself, because you just said,
we don't want a process manager to manage an event system we don't need
So, which is it?
It's a fair point to argue that initd worked fine for you and you don't see a reason to change and don't want to learn a new system. But just say that and save yourself the time.
Seconded. I work for a relatively small company, we have maybe seventy or so virtual machines running CentOS 7.3. There haven't been any systemd-related problems.
git and emacs go against the "small sharp tools principle", and I don't see anybody yelling that we should be using RCS and ed.
More importantly, nobody is being forced. Every developer and contributor anywhere is completely free to make their own Linux distribution without systemd, or fork an existing one. You can't say, "The Fedora and Debian developers picked systemd, and I don't want it, so they're forcing me!!!!!" - you don't have the right to make other free software contributors use the specific tools you like. If the entire Debian team wants to rewrite their display environments to look like Pac-man, I don't have to like it but they still aren't forcing me to do anything.
And again, I think the failure cases are grossly over-reported. But even if it does happen, it's like anything else - someone will fix it. We don't insist on using kernel 2.26 because there were some regressions in the 3.x and 4.x series.
Right, because there's no such thing as a static IP.
I'll go one step further.
1. Allow alternative init systems
2. Implement systemd as a modular architecture. That is, instead of glopping everything together Windows-style, make the binary logging a plugin, allowing the traditional loggers (and possible new ones) to re-assert themselves. Instead of taking over cron functions, make the systemd timer services optional. Ditto for mounting, etc.
There's a lot to like about systemd, but the hubris is too much. And aside from any personal hurt feelings I might have, I cannot respect an amorphous mess. We spent something like 30 years evolving from big modules full of spaghetti code to small object-oriented modules in the programming world, but in Linux, it looks more like the trip ran in the opposite direction.
Ian committed suicide.
Support my political activism on Patreon.
Systemd is a modular architecture with many small pieces plugged together.
Support my political activism on Patreon.
I am not a server admin guru or anything, but I do admin quite a few CentOS 6 & 7 machines, mostly VMs. With our stack, we haven't had any issues with systemd. Ok, a slight adjustment in a few commands, but CentOS 7 is just as solid as all our other versions have been.
Is there a reason OSX and Windows don't spam my network with audio data? I forget which distro/version but PulseAudio had multicast on by default.
every distribution
And FreeBSD didn't yet in 2017 my audio works. It shows up as a simple device in /dev. It behaves like any other device. Doesn't spam my network with audio chatter.
You have it backwards. If it worked with sysvinit without problems for years and breaks with systemd, the fault lies with systemd and it needs to be fixed in systemd. If the design of systemd makes that hard, well tough luck. Fix the design then.
The problem is really how quickly it blazed through the community
You know just the other day I was reading about how some people were bemoaning the Firefox piece that pointed out Google for how big it was and how little we have in the way for emergency braking should Google start abusing that power with respect to W3C and web standards (basically, Google is in a position to stomp out the relevance of W3C, make the web work the way they feel it should, and little to nothing anyone can do to stop that, should it come to pass and thus we might want to rethink how the governance of the web standard works. However, it mostly descended into Firefox is just bitching, someone call the waanbulance, but I digress). This blazing through the distros is exactly the same. This is all a symptom of loose governance. That's not to say the model is weak or bad or anything of that nature, but when you operate a loosely governed project, having a run away task/project/person dominate all is one of those things that you get, sometimes. Not every project has this happened to it, but when it does, it really gets a specific group of folks up in arms, but then when you ask them to do something about it before the next time it happens, they shrug and say things like, "it dog eat dog out there" or something similar to that effect.
I've just gone ahead and chalked it up as, there's always going to be that group that's in perpetual bitch mode (PBM) about the way the community is heading just like those old farts that sit around and say that the current generation is messing up/moral decline. I'm glad the Devuan people did what they did, I was one of those folks when systemd was "blazing" the trail that if people want a systemd free environment, then they'll build one. I for one welcome the Devuan folks as a third option for Linux systemd-free (really you all should be using Slackware but that's just me).
I know keep getting off-topic here, but if people want to prevent these projects from "blazing" through, then the folks in PBM of the community need to get off their rear-ends and choose a different model of governance. Aside from that, learn to deal.
OI!
why not.. like.. umm.. late 90's? you know, when it it just worked.
I'm going to add my 2c here - sound on Linux in the late 90s didn't just work, it was a PITA. Maybe you were better than me at figuring it out (wouldn't be hard) or you got lucky, but I used lots of distros back then and sound was always a sticking point.
>If PA wasn't necessary, then given 1-3, do you really think all significant GNU/Linux distributions would have adopted it?
Yes, because you missed the most important part of sound history: 4front and paid sound drivers (which actually worked).
Guess what, distributions didn't want to charge users $xx and give all the money to 4front, because they know it would never work as a business model.
PulseAudio does what 4front's mixer did, but for free. Unfortunately, it does a shit job. But it is free. It is not the first time we have seen shitty-but-free beat good-but-paid in the linux world. Fortunately, it has been improved (as tends to happen with problem-solving shitty open source software) and is mostly not shitty now.
why not.. like.. umm.. late 90's? you know, when it it just worked
I can see you first used Linux in 2005. Certainly didn't use it in the 90s if you thought it "just worked". Hell the forget "just". Often it didn't work with a huge amount of effort and hacks.
Say what you want about pulseaudio, it was required to make Linux a possible desktop operating system capable of any kind of multi-media.
Ahem, but isn't it the same argument we hear about systemd: if all distros use it, so it must be good?
I didn't say it was good. I said it wasn't trash, implying it had a purpose. But yes that is the same arguement. All three base distros went through a technical evaluation (except maybe RedHat which probably assumes everything Lennart touches is pure gold), and they all adopted it on technical merits. That is documented in mailing lists regardless of what people think.
Things that worked for decades
Are we still talking about sound? Tell me you're not talking about sound. Because if you're talking about sound you deserve a +5 funny for that sentence alone. Linux sound was a horrid clusterfuck of workarounds just to be able to get sound from one place to a soundcard, and even that more or less rarely worked.
If you're talking about the init system well it worked for decades, you're delusional. It worked through a set of hacks to make it work. It got the system booted and then basically left the rest to crap on itself. It allowed services to turn into zombie processes, it lost track if PID files got upset, it was incapable of handling system events so it spawned yet another service that it didn't control which handled network events to control more services that the init system didn't even track at all.
But yes I'm sure it worked well, and that Poettering is the only one who wanted to mess with it. It's not like anyone else thought the same way. Not like the guys who wrote OpenRC, or the guys who wrote Upstart. The sysvinit did have something going for it, it was small. But yet too big which gave us busybox-init for embedded systems. But yeah it's the Unix way right? Well Solaris also replaced sysvinit with SMF. It's almost like people who adopt Linux or Unix have for the longest time tried to get rid of that piece of shit. Like Apple, the first thing they did after adopting a Unix base for it's OS is create launchd (what systemd is based on).
But yes, let's all focus on that one rm -rf /foo/.* issue and use that to claim that a person who has now written the underpinnings of a large part of the OS has no clue. What an idiot he must be.
Tell you what, why don't you write a better system.
So you don't know how to change a setting and you're complaining. *golfclap*.
You also know what FreeBSD did in the late 90s and early 2000s? Oh man you're not going to believe this when I tell you. You ready for it? Really? : They abandoned the god fucking awful Linux OSS / ALSA combination and rewrote it from scratch.
Linux audio was for want of a more technical term: fucked. With pulse audio it now works, despite your weird network / RTFM problem. Not that this is a pulseaudio issue. It's not Pulseaudio's job to set defaults, it's the distribution maintainers.
So you don't know how to change a setting and you're complaining. *golfclap*
I spent a week trying to diagnose *why* my machine was so chatty before narrowing it down to PA. Then turning it off took no time. But having a default setting like that makes no sense.
rewrote it from scratch.
No one is claiming that it didn't need re-written. Just like I'm not claiming the old init method couldn't be improved. I take issue with what it was rewritten into. Which is the flaming pile of PulseAudio and SystemD.
launchd has been out for 12 years now. Ported to FreeBSD and running as NextBSD's init. I have yet to hear of issues like those caused by systemd. But it was also designed to do one, launch programs.
> and I don't see anybody yelling that we should be using RCS and ed.
No, we say you should use vim instead of emacs, and git actually WAS designed as a bunch of small sharp tools.
Unicode killed the ASCII-art *
Radical changes are justified by radical improvements.
Systemd is certainly not a radical improvement.
So how is systemd justified?
> Apple's LaunchD (also about to be used in FreeBSD) to Ubuntu's Upstart.
I don't think LaunchD is about to be used in FreeBSD.
> Upstart never got this amount of hate
Upstart is just an init system. SystemD radically changes everything about Linux.
> Unrelated, I also found sound worked much easier in FreeBSD than it did in Linux with pulseaudio.
But firefox will not work without pulseaudio.
I think you can only run old versions of chrome on FreeBSD.
I know you can only run old version of LibreOffice on FreeBSD.
vim goes even more against the "small sharp tools principle" than emacs: vim reimplements diff and friends internally instead of using the system tool.
Not a single statement you made is true.
You can turn off PulseAudio in make config.
Latest download on LibreOffice's website: 5.3.3
Latest FreeBSD package available: 5.3.3
Latest available stable chrome(ium)
58.0.3029.110
Latest available in FreshPorts: 58.0.3029.110
.
> 2017
> still using UIs;
We can safely discount your opinion on Ubuntu use from that alone.
Anybody choosing a Linux distro because of its desktop is missing the point by a country mile. ALL linux desktop systems are fugly and unusable.
systemd was adopted on technical merits? Probably. Do these technicals merits affects me? I tried and used systemd before any distribution adopted it. Then I noticed it broke stuff I relied on and wanted to switch back to another init, because why not, eh? And then I found out people around (like KDE, like provided earlier) remove code and functionalities of software because it would make a duplicate with systemd. So switching back was no longer an easy option.
And many of these functionalities are way beyond the scope of an init system. It is almost a system. So that, for me, itself, raise quertions.
The rm -rf /foo/. might be insignificant if we were talking about a guy that contributes to an init system. It is quite different when it is about one of the guy that have a say on the system that gradually all other software depends on.
As you said "underpinnings of a large part of the OS". It is not about an init anymore.
Fact that a new init system is welcome does not mean that it is so great to have a new system on top of GNU/Linux, much more than an actual init system.
When considerable amount of software regress (upower, etc) because their functionalities are now handled by systemd, in an effort of rationalization, for distros, it does not make much sense not to use systemd, because it forces them to chase all these regressions that are being made day after day. Which mean working just to keep things as they were, instead of improving anything.
And it is not like a new thing in the libre software community, to write a blank check to some crowd (Helixcode, Eazel, etc) due to marketing and promises more than results while there was obvious warning sign to where it would, in the end, lead (and which it did - kind of joke to have GNOME, part of GNU, led by people that ultimately were releasing proprietary software).
I wont get in details about sound. In the past, it was shitty to set up but once it was set, it was working reliably. Not my feeling right now. At least, old audio system was not providing functionalities while advising not to use them (PulseAudio as a system daemon). Here there is a pattern about the development process (writing code you want people not to use? why? because you need to pretend there is no regression?).
Finally, what is the meaning of your last sentence? Is it not allowed not to enjoy systemd until you wrote yourself some systemd? I need to be president of the USA to have an opinion about president USA ? I need to be famous singer to like or not to like some famous song? WTF.
You forgot that part.
What hate are you talking about? I'm asking for real. I do know that Mr Poettering has sometimes reacted negatively, but that's normal for humans that put a bunch of work into something and then get harassed.
But what are you talking about?
the mentality behind Devuan is ludicrous. Lets remove a far more modular, flexible and powerful init system and make a distribution that is less flexible and less modular and less configurable. That is because systemd is actually more flexible, easier to configurable and more modular than the old system was.
To cover many of the myths about systemd: http://0pointer.de/blog/projects/the-biggest-myths.html [0pointer.de] . It is extremely damaging to the Linux ecosystem for people to continue to spout lies about systemd that are not true. Most people when confronted with the facts about systemd and the benefits it offers and the fact it takes nothing away, you are free to have sysv style shell scripts to your hearts content because systemd is fully backward compatable with the old init system, and is actually MORE modular and decentralized than the old system, agree that it is a benefit to Linux.
Please, stop spreading lies about systemd.
Ubuntu has had systemd type init for years because of Upstart, so with systemd, we are simply seeing standardization with what the other distros are doing. So, this kind of init model is nothing new to Ubuntu.
The opposition to systemd is nonsensical. Because you can continue to use SysV init because it supports that, the additional functionality is additive, it adds onto what was there before. Because SysV is still there, and you can start your services that way, you have nothing to complain about and there is no reason to oppose systemd.
One big benefit is the service files which are shorter, simpler and easier to read than shell script and actually make starting services easier. You can still write shell scripts to your hearts content, but for most people service files are easier because of the declarative format.
systemd is actually more decentralized than the old system and is more configurable. This is because of the D-BUS based design. That is, you can write a D-BUS daemon that monitors the system bus for whatever events you are interested in and write your own custom code to decide when to start a process. This allows you to trigger something when multiple other events happen and allow you to do so cleanly and easily because you are watching a standardized protocol over DBUS. It would be much much harder to do this without a standardized loosely coupled design of DBUS. Events can include kernel events and events generated by other processes, including other processes starting. Your daemon can also generate its own event messages when it starts or stops a process. The reason Gnome uses some features associated with systemd is that Gnome for instance wants UI notifications for different system events for the user being able to monitor the system via a user interface.
Some utilities have had a D-BUS backend added, for instance, su. This is to allow users to have a process started when a user logins in. It is a lie to say that su has become built into one big massive monolithic systemd process. This is not the case at all. All that was added to some utilities is a small amount of d-bus code;. They are still completely seperate binaries and are not a part of a monolithic systemd process because the utilities are still completely seperate, in fact it keeps the utilties seperate because the whole point of d-bus as a loosely coupled architecture is to allow applications to communicate without these applications having to be directly linked or even know who each other are.
Systemd in this way is far more modularized than the old init system was.
systemd has a lot of functionality but you are not required to use it, but its there if you need it. Its probably better to have a simple sequential startup for many services, you can still do that with systemd. systemd takes nothing away. want sysV type init? Feel free to use it on systemd, its still supported.
I don't think many of the people complaining about systemd are "crusty old sys admins", I think we're talking about mostly hobbyists who don't like change. SysV init has never been considered a thing of beauty by those who have to maintain GNU/Linux (or any *ix) systems. That's why systemd is the latest in a long line of replacements, from Apple's LaunchD (also about to be used in FreeBSD) to Ubuntu's Upstart.
Strongly disagree here, at least from RedHat land. SysV-style init scripts have been a solved problem for quite a while. If there are problems, they're usually a result of the daemon/app itself having problems that workarounds are needed for -- workarounds that usually end up in the systemd.service files as well unless upstream finally did something about the underlying issues.
Seriously, when I need to create an init script for something in EL6, just cut and paste https://fedoraproject.org/wiki/EPEL:SysVInitScripts?rd=Packaging:SysVInitScript#Initscript_template, change a few variables and/or add customization needed, and you're done. It's not rocket science and worked perfectly adequately. BSD folks complained about using chkconfig to manage your rcX.d/ structure (compared to rc.conf), but that wasn't that hard to figure out.
Debian (and Ubuntu) init scripts, on the other hand, seem to more or less be an unmitigated dumpster fire of strange techniques and non-standardization. But I've been a RH guy for forever. If systemd had come out of Debian-world, I'd totally understand its genesis and probably sympathize more. That it came out of Fedora/RH strikes me as quite bizarre. The only thing systemd could use to really justify itself with at F14/F15 time was boot speed, something which Debian had seen good improvements at by swapping https://wiki.debian.org/DashAsBinSh. Had Fedora/RH adopted that, we might not have seen systemd exalted to the degree it was.
Hire a Linux system administrator, systems engineer,
I tried and used systemd before any distribution adopted it.
Great. Your views are outdated. There have been hundreds of commits and bug fixes not to mention work to incorporate and make it stable in distributions.
So switching back was no longer an easy option
Also wrong. Not a single piece of major software doesn't work on non-systemd systems.
And many of these functionalities are way beyond the scope of an init system. It is almost a system
That was kind of the point. Starting a system and letting it be is 80s era OS design. Continual system management is what it's about. systemd is NOT an init system, it's a system management daemon, it's right there in the name.
When considerable amount of software regress (upower, etc)
If upower actually worked it wouldn't be abandoned. That's the problem with nasty hacks to try and make a system look like it's in control. When the system actually gets control the hacks become useless. If upower is important the non-systemd distros will support it.
In the past, it was shitty to set up but once it was set, it was working reliably
Reliable and functional are not the same things. Once you eventually battled through the setting the system up you were still stuck with a shitty architecture which couldn't cope with something as complicated and mindblowingly advanced like plugging in a set of headphones. The Linux sound system sucked. FreeBSD's system is better, they too completely abandoned the Linux variant due to it's horribleness.
Finally, what is the meaning of your last sentence? Is it not allowed not to enjoy systemd until you wrote yourself some systemd?
Of course you are. You're not allowed to shit on someone who doesn't realise one single thing while at the same time writing large parts of the fundamental parts of an OS, at least not until you yourself have contributed that much and have shown yourself to be *certified flawless*. The whole thing about the rm thing just shows how childish the entire debate is.
See for example systemd.exec(5) for a list of directives that can be used in service and some other unit files.
With some simple directives in unit files (which are simple INI style data files, not scripts) you can access some powerful features, for example ReadOnlyPaths, PrivateNetwork, PrivateUsers, ProtectHome.
systemd also brings instantiated services, socket activation, a simple cgroups interface. Want to limit CPU for a running service, or for everything currently running for a user without restarting any processes? "systemctl set-property" can be used for both because of the way cgroups are abstracted. There's even a simple native container system that's integrated with systemctl and journalctl so you can use -M $CONTAINER to control or view logs for that container, or "-m" to see all logs for host and container.
It's not just that systemd can do these things, but that it does them in a way that is easy to understand. Unit files are clear and easy to read compared to what you'd need to do in an init script to accomplish things that systemd can do with simple directives.
journald/journalctl is also a pretty radical improvement once you start to use it, and on Debian journald is used to supplement syslog not replace it, so the text log files are still there.
If you haven't experienced any of these improvements, go check them out! Seriously give systemd another try if you haven't used it recently. It's not perfect, but it's a powerful tool and in retrospect will probably be recognized as the most important improvement since dependency resolution in package managers IMHO at least.
OSS in the 90s supported mixing multiple sound sources into a single audio output stream ... on systems other than Linux. Linux imported a crap version of OSS, never improved it, and declared OSS as dead and outdated ... when other OSes were using it just fine.
FreeBSD still defaults to OSS and supports pretty much all the same non-networked features as pulse.
OpenBSD has a sndio setup that supports pretty much all the same non-networks features as pulse, also running on top of OSS. sndio is also supported on FreeBSD and NetBSD.
There's also an OSSv4 release that can be installed on most Unix-like OSes.
It was only the Linux devs in the 90s who couldn't get OSS working properly. So they scrapped it and wrote a new sound system (ALSA), which didn't really fix anything. Which lead to the development of sound servers running on top to try and hide/work around the issues in ALSA. But they didn't work very well. So PulseAudio was developed to hide/work around the issues with ALSA. And it mostly works. But it's a bandaid, on top of a bandaid, running on a bandaid, with bandaids wrapped around it to hold it all together.
All that being said, PulseAudio does work fairly well these days, and can be used with ALSA or OSS backends on pretty much any Unix-like OS.
unit files are soft replacement for not knowing how to shell script properly,
Why should you have to know how to shell script to boot your system properly? How is it better to have a full shell interpreter executing arbitrary logic to load system services better than just parsing a config file? That argument just makes no sense whatsoever.
If you do not know how to shell script, you have no business administering a server (ie, being a sysadmin) in a real-world environment. systemd may be fine for end-user graphical boot desktop environments (launchd works great for OS X), but this experience is from systems engineering and administration's perspective.
There are plenty of reasons why having logic over a config file is a tenable position. It basically boils down to: If you start with complex logic in a simple language, you can always simplify your implementation. If you start with simple logic in a complex language, you're stuck with that complexity as soon as anyone else starts using it. Config files are not a net win, and the win they do give you (boilerplating the most simple initscript cases) could easily be achieved a different way (like variables sent to a shell script that executes library code, a la /etc/init.d/functions.
Hire a Linux system administrator, systems engineer,
Systemd is a modular architecture with many small pieces plugged together.
It may theoretically be a modular architecture, but it forces an entirely novel paradigm on the system... and it did so through strong-arm tactics. A replacement for systemd that doesn't end up just reverting back to SysV will have to end up looking a lot like systemd as a result. Welcome to complexity lock-in that no one asked for.
Hire a Linux system administrator, systems engineer,
A replacement for systemd that doesn't end up just reverting back to SysV will have to end up looking a lot like systemd as a result.
In other words, nobody can think of anything better, and would just rewrite SystemD?
Support my political activism on Patreon.
But having a default setting like that makes no sense.
Blame your distro manufacturer.
I take issue with what it was rewritten into. Which is the flaming pile of PulseAudio and SystemD.
Do better. Plenty of people have tried and this is the best we've got winning out on all technical merits.
I have yet to hear of issues like those caused by systemd.
Funny how you don't hear about closed source very well integrated and tightly controlled processes not having the issues of early adopted into the wide clusterfuck ecosystem that is Linux has.
But it was also designed to do one, launch programs.
If that's what you think then you know just as much about launchd as you do about systemd. Not a lot.
"Also wrong. Not a single piece of major software doesn't work on non-systemd systems."
Last time I checked, upower (working without functionalities is not working). upower is not major. But KDE power management is (was ?) done by upower. So power management in KDE does not, at least without workarounds. An example among others. I wont make a catalog, just to point out that your argument is kind of flawed.
(when you write "That's the problem with nasty hacks to try and make a system look like it's in control. When the system actually gets control the hacks become useless" I am under the impression you are clueless about the topic)
"Starting a system and letting it be is 80s era OS design. Continual system management is what it's about. systemd is NOT an init system, it's a system management daemon, it's right there in the name."
You cannot claim systemd is not an init and yet say that people should not complain because it is just a change of init.
I was fine with the notion of an init system. I am not interested in this continual system management why I managed to find broke in my uses cases already a few time.
"You're not allowed to shit on someone who doesn't realise one single thing while at the same time writing large parts of the fundamental parts of an OS"
Reality check: I am. Fact is I liked this OS better before he touched it. Fact is I am using now distros that does not contains the changes he made. But dont make it personal. It is not about one person. /foot/." is not a problem. Because that was the point you apparently missed, the problem is not that they guy is clueless about it but the fact that, because he was clueless about it, he decided we should not care.
And I am perfectly untitled not to trust someone that find "rm -f
Well, it seems I rarely share view with this guys about what matters. So I can only welcome people doing something else, like Devuan does.
Since I was using BTRFS, I sincerely doubt mdadm was the problem. What I was seeing was another manifestation of the same basic issue, systemD THOUGHT it understood the dependencies but in fact, it did not. That's why it wouldn't even try the mount command.
The systemd design failure is that it refuses to acknowledge that there can be such a situation where it has no idea what the dependencies might be. It demands that everything else must conform to it's concept of what constitutes a dependency. It doesn't even have a way to tell it "use this external program to decide if dependencies have been met" nor does it have a way to tell it just give it a try and if the command returns no error, all is well.
Bottom line, stubbing systemd out and using SysV to bring the VM up worked flawlessly. One of MS's sins is that they demand a perfect world in order to work correctly and will not allow the admin to tell it to just give it a try. Systemd shares that sin. Without systemd, a great advantage of Linux is that when the actually intelligent human knows more than the system, the system will defer to his of her judgement and the job gets done.
A replacement for systemd that doesn't end up just reverting back to SysV will have to end up looking a lot like systemd as a result.
In other words, nobody can think of anything better, and would just rewrite SystemD?
There are legitimate criticisms about code quality and -- certainly -- project design, management, and organization within systemd, but there are others that object philosophically to the systemd paradigm to begin with.
There may be benefits to rewriting systemd, but I count myself among the latter. IMO, the init system (and other building blocks needed to boot the system to or past the equivalent of a single-user mode) should be fundamentally distinct from service management. Hence my comment above -- systemd would be fine if it was a replacement for xinetd, or an option like daemontools, hanging off of the existing imperative init system.
Hire a Linux system administrator, systems engineer,
Now this needs to be modded insightful. +5
https://lists.freedesktop.org/...
Specifically:
> Unless the systemd-haters prepare another kdbus userspace until
> then this will effectively also mean that we will not support
> non-systemd systems with udev anymore starting at that point.
> Gentoo folks, this is your wakeup call.
>
> Lennart
Now another thing in there. Just because I prefer not to run systemd, I have been characterized as a "hater". Other than the fact that I'm also not into Taylor Swift, I'm not that much into the whole "hater" thing, but I recognize that I'm being categorized and insulted.
I actually tried being an early adopter of systemd, years before its widespread adoption, and found that it didn't work for me. By the time it started getting widespread adoption, the THERE CAN BE ONLY ONE! attitude really annoyed me. If it were just the attitude I could probably get over it, but I also have technical and software-philosophical objections. But none of that appears to matter in discourse, because it all comes down to haters and steamrollers, instead of real discussion.
The living have better things to do than to continue hating the dead.
That's disingenuous and contradictory. By adding SystemD dependencies to all sorts of unrelated software (including the entirety of GNOME), Lennart et. al. really are asserting that they have some right to make other free software contributors use the specific tools they like.
It is insane to be forced to choose my desktop environment based on its compatibility with my init system.
"[Regarding the 'cloud,'] ownership was what made America different than Russia." -- Woz
If is only a solved problem if you do not do anything complicated on your servers. If you start needing things like services that depend on cluster file systems that reside on iSCSI, you end up needing to manually edit the init scripts and I can tell you based on first hand experience that it is much easier to do that on systemd based systems than on the old init system.
Are they holding the GNOME developers at gunpoint? Are they blackmailing them? No, they released a piece of software with features, and the GNOME developers adopted it. No force. And they haven't shut down Xfce, Blackbox, Ratpoison, IceWM, or the other desktops either.
I'm not trying to convince anyone, I'm just relating my experience. I'm sure DHCP works in an all systemd setup, with NetworkManager. I don't like NetworkManager, because it's non GUI interface is horrible. So I use wicd, which worked fine until some update silently started removing the IP address it assigns to my interface. I'm sure I could spend time figuring out exactly which systemd meta service to block to make things work again, and then it'd be yet another item on the long list of things we've had to fix. So I just relented.
And no, our crypto configuration wasn't broken. systemd decided to add new restrictions to it and not be compatible with cryptsetup, so going from wheezy to jessie broke working things, in ways I haven't seen Debian break during an upgrade since forever.
Your "it works for me" stories are not particularly helpful. The fact is, that while there are people (such as you) that are happy and problem free with systemd, there are others (such as me) that have run into an unending stream of problems because of it. I'm not trying to convince you with my "drivel," but I can assure you, that neither are you convincing me with "it works for me, therefore it must work you as well" response.
Yeah? Who uses the git tools with any piece of software other than git? Ever fire up "git cherry-pick" while working with Subversion? Ever use "git fetch" instead of rsync? Ever "git revert" your SQLite database? It's a monolithic tool with a bunch of executables - and that's fine.
And Vim with its plugin systems, buffers, diff tools, regular expressions, shell out and redirect, etc... etc... system is damned close to having feature parity with emacs. So it's still a monster tool instead of itty bitty 'ed' or 'nano'. But nobody is screaming that we should all be using 'ed'.
I'm sorry but citing Mr. Poettering's use of the term "systemd-haters" is a little thin as evidence of piles of hate directed towards systemd opponents. Especially with the context that he has frequently been the target of harassment for his work. Best choice of words? Perhaps not, but certainly not indicative of piles of hate.
Perhaps you need to re-calibrate your hate sensors here... or maybe you've somehow missed out on the vitriol that's been directed at him and his fellow developers.
I'm not trying to say here that Mr. Poettering's behaviour is always the best. He's a person with faults just like the rest of us, and I honestly don't know how I would handle the amount of hate that he does. Probably badly. But referring to systemd opponents as systemd-haters is a far cry from piles of hate.
Please don't take this personally, I don't anything about you as an individual, but in the aggregate I've really started to see the opposition to systemd as analogous to the alt-right. Both seem to be emotionally driven, fact resistant, knee-jerk reaction against progress, ardent defenders of an systems many of them don't truly understand, opposed to changes that would actually benefit them if they took a moment away from their ideological perceptions.
More importantly, nobody is being forced. Every developer and contributor anywhere is completely free to make their own Linux distribution without systemd, or fork an existing one.
Are you daft? This whole story is about the fact that that's what someone did. Fork a dist to produce one without systemd. And your suggestion is to... fork a dist to produce one without systemd? What the actual fuck?
Regarding sound in Firefox, default support for anything but PulseAudio has already been pulled and they are planning to remove the code supporting anything but PulseAudio in the near future.
https://bugzilla.mozilla.org/s...
No, you keyed off of the wrong sentence. Look at, "Gentoo folks, this is your wakeup call." Up until the Devuan fork, Gentoo and Slackware were the only Linux distributions not converting to systemd. There was context surrounding this quote, implying the inexorable forcing of systemd into Gentoo.
I will add that you've got a bit of the attitude here, too. Note your words, "fact resistant, knee-jerk reaction against progress". There are certainly interesting ideas in systemd, I'll grant that. However overall I don't consider it progress, so in wishing to not adopt it I don't consider myself anti-progress.
If you really wished to engage in a technical discussion about this, what I like and what I don't like about systemd, I'd be happy to. However your last paragraph has lumped me as a systemd-hater, and therefore I cannot possibly have technical arguments to make. That is not true, I (and others) have technical and software-philosophical arguments, its just that nobody from the systemd camp (There, how's that for polarizing?) wants to hear them.
The living have better things to do than to continue hating the dead.
Unix systems fundamentally do not function without services. As well, I can easily argue that the paradigm of systemd is a better reflection of the Unix philosophy than classical init: systemd actually supplies small, sharp tools for things like process communication and logging, while we have a pile of blunt hacks to cobble shit together with sysvinit.
sysvinit is your services manager. It brings up your syslog daemon; it initializes your graphical display; it changes your system context to determine if you've got networking up or down. The sysvinit system is tasked with managing the whole process of getting system services running, and it does a terrible job of it.
Code quality aside, systemd is a collection of tools, daemons, and libraries. It's not a giant, monolithic clusterfuck that loads itself to start with; the init system brings up a bunch of other services of which it is aware. Each service makes use of other services. Various services use libraries to make use of systemd-supplied facilities such as interprocess communication and device management.
The real, fundamental difference between systemd and sysvinit is systemd is more-aware of all the little components of an init system. Classical sysvinit relies on some sort of hardware management service to ensure network devices are in place, drivers are loaded, and device files are created; systemd relies on such a service as well, and is aware of a particular interface to communicate with such a service. The service manager in systemd can bring up a service, and also is aware of the logging daemon and can send console output to the daemon, in the context of the service; the daemon itself can also send log messages directly to the logging daemon.
It's a collection of tools replacing older, blunter tools. That collection is called "systemd".
Support my political activism on Patreon.
"I'm not a hater! I just hate it and want to argue with people who disagree with me!"
Or maybe you want state-defined infrastructure and continuous integration, not just a bunch of ad-hoc scripts holding everything together with glue and tape. You can have logic in a config file if you think you really need it (see nginx, for example) without running a full blown interpreter with arbitrary code execution capabilities and complete freedom to operate as the root user anywhere on your system.
It basically boils down to: If you start with complex logic in a simple language, you can always simplify your implementation. If you start with simple logic in a complex language, you're stuck with that complexity as soon as anyone else starts using it.
I have no idea what you mean by this. Accurately defining the dependency graph for booting a system in a general way (ie: for any type of system with any type of hardware) is not a simple process in any language.
So you've obviously decide that there are no possible technical or software-philosophical faults with systemd.
I'm not trying to sit here and argue with YOU. I'm requesting that people quit questioning my sanity or technical chops for not using systemd.
The living have better things to do than to continue hating the dead.
Funny how you don't hear about closed source very well integrated and tightly controlled processes
launchd is opensource. Which is how it made it into FreeBSD.
I read that part as: "watch out, there is some work headed your way to keep your fork of udev up to date!" and understand it as a bit very well formulated early warning of changes that are to come.
That's also not a pile of hate. You could say it's not polite, but the implied message that I pick up on here is that Gentoo will need to implement alternatives to systemd technologies if they want to continue to benefit from other software projects that use systemd.
I apologize for not making it clear enough that my alt-right comparison was not about you, but my overall impression of the resistance to systemd. Maybe the analogy was a little stretched, but there is an element out there elevating the clamour against systemd to conspiracy theory levels of Red Hat pushing their stack on the rest of the community or similar nonsense. Again, that's not about you just what I've seen from others arguing against it.
That's great, but I didn't see any technical arguments from you. Maybe I missed them. What I did see and responded to was you saying:
And then you provided an example of the piles of hate, which amounts to using the term "systemd-haters" and giving a heads up to colleagues of some changes down the road. Also it's you who is saying that a hater cannot possibly have technical arguments to make, not me. If you would like to argue technical merits, I do have another comment in this very thread on that very topic.
Anyways, I hope you're not too upset, and I do encourage you to give systemd another try if only because of how prevalent it has become. Maybe you'll find something to like about it, who knows?
It would help if you didn't reinforce that perception with such a poor use case justification.
I don't profess to be a systemd expert, just that I've tested it and tried to see what benefits it can offer.
Systemd is not a large monolithic process.
systemd has its own lib directory. It is a much more memory intensive process than init.
By software interrupts, I assume you mean it uses dbus instead of just piping everything to stdout.
No. I mean it generates interrupts for service from the CPU and steals context from other processes. If it write I/O it forces other processes to minor page fault back to ram and off the CPU core. Though I still have more research in this area about systemd behavior.
That argument just makes no sense whatsoever. Shell scripts were a quick and dirty way of getting a system up and running.
Which shows you are using inncorect assumptions and don't know how to configure initd properly.
Teach your tools to read the binary log, and it will actually be better because you will get a lot more information.
Which is not very useful if some problem causes you to loose your last buffer full of critical information that you need to determine why you system went down.
You are contradicting yourself, because you just said,
No I am not. An evet management system and a process managenment system *should* be separate process entities that interact.
My ism, it's full of beliefs.
> That's also not a pile of hate. You could say it's not polite, but the implied message that I pick up on here is that Gentoo will need to implement alternatives to systemd technologies if they
> want to continue to benefit from other software projects that use systemd.
The you missed something in earlier lines in that post. Gentoo already maintains its own udev fork, eudev, so that's not the issue. He spoke of moving kernel event signalling from netlink to kdbus, which "breaks userspace" at a much more fundamental level, not just Gentoo's eudev.
I put "breaks userspace" in quotes, because the statement of simply changing interfaces like that breaks normal kernel practices, like keeping published APIs around for years of non-use before removing them. I've no problem with a kernel config switch that says something like "netlink or bus1 for event signalling", that's fine, breaking currently in-use and in-development software isn't. This betrays either a lack of familiarity or lack of regard for normal practices, neither of which belongs in a piece of infrastructure as important as systemd has become.
> That's great, but I didn't see any technical arguments from you. Maybe I missed them.
You didn't. I've mentioned technical or software philosophy several times, and this is the first time in this thread that anyone has picked up on it, or expressed any interest.
1 - PID1 is critical. If it crashes, the whole system crashes. I know that everything in systemd is not PID1, but it's still got a big one. Every line of code may someday translate into a bug or a crash. Proof, look at the bug history of IEFBR14 some time - that really is quite literally a one-liner, that managed to accumulate multiple bugs. My hair is grey, I used to use IEFBR14 all the time.
From what I've seen the functionality of systemd's PID1 could have readily been separated into a much smaller PID1 that did less, and one or more helpers that PID1 could restart as needed. That would have also allowed updating systemd without rebooting the system, as long as the PID1 portion hadn't changed, and being much smaller, that would have been more likely.
2 - Unix philosophy - small pieces each of which does one job and does it well. Then tie them together to do bigger things. In other discussions on this topic, I've been told that the Unix philosophy is obsolete, but I disagree. It has kept Unix running for some 40 years, through orders of magnitude of change in every aspect of computing. I'd be hesitant about throwing it out that quickly.
3 - I like initscripts written in a Turing-complete shell script language. You don't always need it, but when you do, you've got it. I've never written an initscript from scratch, but I have so heavily modified some that they practically end up from-scratch. From what I've ready, systemd has a decent configuration language for service units, but it's not Turing complete, and if they did, why not just use something that already exists and is well-debugged - shell script?
4 - Right now systemd is one package, even though it has many parts. That means that a bug in its logger requires a complete sytemd update... Or a bug in its new resolver subsystem, etc, etc. If the packaging were split, kind of the way the old functions that systemd has been subsuming were, then such updates would be simpler. Don't forget that a systemd update requires rebooting.
I could go on, but that's a few.
By the way, when attempting to make technical arguments like this, I've been called quite a few names, along the names I've been called when calling for network transparency out of Wayland. I try to let it roll off my back, but it can get to you after a while, especially when technical arguments are answered with insults and name-calling, rather than counter technical arguments.
The living have better things to do than to continue hating the dead.
systemd has its own lib directory. It is a much more memory intensive process than init.
No. I mean it generates interrupts for service from the CPU and steals context from other processes. If it write I/O it forces other processes to minor page fault back to ram and off the CPU core. Though I still have more research in this area about systemd behavior.
You are comparing apples and oranges. Initd farms out all of its work to the shell, so if you're going to look at memory consumption and software interrupts, you need to include the shell processes when comparing with init. And systemd is much better in this regard than init.
Which shows you are using inncorect assumptions and don't know how to configure initd properly.
The primary arguments behind using shell scripts are a) flexibility, and b) the shell is already there. So in other words, you can write a quick boot process for your system without properly designing system bootup. Once you have a proper dependency tree for bootup, you no longer need the flexibility of shell scripts and you can put a better system in place.
Which is not very useful if some problem causes you to loose your last buffer full of critical information that you need to determine why you system went down.
That doesn't happen.
No I am not. An evet management system and a process managenment system *should* be separate process entities that interact.
Maybe, maybe not. It depends on a lot of things. If your events need to spawn processes and your processes send events, there's a good argument to be made that they can't be easily separated. As an analogy, in the old days of compositing window managers, it was originally thought that a separate compositing manager could be made that would just communicate with the window manager. That turned out not to work because compositing needed to know more about window placement than originally thought and window placement need to know more about the compositing layer, so the necessary bi-directional communication was just creating too much latency overhead.
Initd farms out all of its work to the shell, so if you're going to look at memory consumption and software interrupts, you need to include the shell processes when comparing with init.
So what? unit files are going to run shell scripts and systemd has both problems, however you've missed the point - but I'll get to that next and address the new point you've raised first.
You are falling into the same flawed thinking all systemd proponents fall into, that the mis-used rc system (incidentally designed by red hat) is the justification for ditching initd and replacing it with systemd. Your example fails to take into account system processes that are compiled, executed from inittab with their environment managed by a shell that exits after it has done it's work, which is how the init system is supposed to be used.
For your example to be true I have to mis-configure init, and then configure systemd so that it won't spawn a shell for a process, which is common however the bar for failure on unix systems is generally so high that a shell process has to be so absurdly bad for it to become a problem. That's common between systemd and initd, so it's hardly a fair comparison.
Out of curiosity I tested your premise on a desktop linux box and found that systemd remains in the top 10 processes consuming CPU and memory resources top(pped) only by firefox, X11. Even with 60 shell processes running they don't even make it into the top 80 processes consuming resources on my system. So I'll be interested in trying this on a server when I get back into the office.
So let's get back to the point.
And systemd is much better in this regard than init.
Only if the linux CPU scheduler has been re-written in the time between now when I posted my OP. systemd generates I/O and initd writes small messages to stdout as a char device. So as far as I can tell your premise, like the design of systemd, is based on flawed thinking because the CPU scheduler *will* bump processes off cores that hog resources in favor of I/O bound processes. In other words systemd can bump my important CPU intensive tasks that I want to be extremely responsive off a CPU core unless I configure the scheduler, which most people do not.
So unless systemd is now assuming the role of the kernel's CPU scheduler it is a Post Incident Review in waiting compared to initd.
The primary arguments behind using shell scripts are a) flexibility, and b) the shell is already there. So in other words, you can write a quick boot process for your system without properly designing system bootup. Once you have a proper dependency tree for bootup, you no longer need the flexibility of shell scripts and you can put a better system in place.
That's windows registry thinking, why the hell would I want that?
I want shell scripts to set up and check the dependencies are in place before my process is initialized in its appropriate runlevel. The thinking you have cited is the core reason for objections to systemd, that the flawed thinking is so apparent and obvious and forces us into a flawed paradigm by people who wrote a solution to a problem they did not properly understand.
That doesn't happen.
Well unless you can explain to me how systemd writes the log blocks to disk as a machine crashes we are relegated by systemd to scan through memory dumps to find that last block of information that should be in a log file. Sure the class type logging of systemd is pretty good, but not at the expense of root cause information that we may need to fix our own fuck-ups.
This is what highlights the fundamental design flaw of systemd. To write I/O for logging it demands CPU resources that otherwise would be consumed by a client process (breaking the usefulness of top as well), or it's less demanding of CPU with a higher chance of loosing logging and root cause information.
An analogy would be the ty
My ism, it's full of beliefs.
Maybe you don't remember, but the original question that I asked was:
Specifically I was asking about examples of piles of hate. It's okay if you want to retract that statement.
As for your technical argmuments:
If there were an epidemic of systemd related failures hitting multiple organizations and getting reported on in mainstream press, then I would probably stop using systemd as well. The reality is that the sky hasn't fallen, and almost all of the systemd fail stories I have read follow the theme "i tried it once, couldn't figure out a problem and gave up."
Feel free to use what you want. We got into this discussion because I asked for examples of the piles and piles of hate, which you seem to have wavered on. Best of luck, and I hope you feel a little less hated now :)
> Specifically I was asking about examples of piles of hate. It's okay if you want to retract that statement.
No, but I'm not sure I feel like retreading that ground at the moment. I may keep one of these links around, in case I do. In the meantime, I'm running my computer as I see fit, and am only mildly inconvenienced by the things that require systemd. Incidentally, as far as userspace goes, I never had packages that required sysv, upstart, or whatever. Usually once the system is up, applications have been init-system agnostic. That's another thing I don't particularly like about systemd.
You're right, the sky hasn't fallen - yet. But so far systemd doesn't really have a lot of penetration in the big server space, where rebooting really is a big deal. By the same token, there have been a few laughably bad bugs found in systemd, and other than mentioning them in this sentence, I'm not hammering on them. I'll simply say that nobody has yet started the real bug search - the subtle bugs, timing bugs, the nasty stuff that takes years to discover - and get hidden by TLAs, and that type of stuff.
Perhaps that's the most disturbing thing about sytemd. It came in and practically took over the Linux ecosystem in about a year or so, and it was only a few years old at the time. It takes many years for software to truly get wrung out, to get the subtle bugs out. Systemd is too young for that to have happened, so most of the Linux ecosystem is part of a big experiment and learning curve.
Note that I'm not hammering specifically on systemd for being immature, this is part of the curve for any software. It's just that I think systemd has become too ubiquitous, too soon, for all of our good. Time will tell.
The living have better things to do than to continue hating the dead.
If only all online debates could wrap up so cordially. It was a pleasure :)
I don't know and I don't care. I don't maintain the distros, or contribute to them. They are just a tool that I use. The standards for that tool change, and because I need the tool, I adapt to that change.
Also, I'm not taking your assertion that systemd isn't an improvement as a given. I don't know whether that's the case or not.
Only crack the nuts that crack. You don't put the ones that don't crack in the sack.
So what? unit files are going to run shell scripts
No, unit files don't run shell scripts. They can as an easy migration path, but they are designed to operate independently of the shell.
You are falling into the same flawed thinking all systemd proponents fall into,
Look, it's pointless to argue about this because it really comes down to a matter of needs and opinions. Systemd was designed to solve problems that are not easily solvable with initd. If you don't have those problems with initd, then you don't see the need for systemd. Furthermore, if you happen to like initd, you probably hate systemd. But it is not about right or flawed thinking. It is just a matter of opinion. You don't like systemd, that's fine you are entitled to your opinion.
Out of curiosity I tested your premise on a desktop linux box and found that systemd remains in the top 10 processes consuming CPU and memory resources
Systemd as PID1 doesn't sleep. If you are looking at that and comparing it to an idle bash process, you are not looking at the right thing. There is a lot of documentation on benchmarking of systemd if you really care about it, but if not feel free to keep building up strawmen just so you can knock them down.
Well unless you can explain to me how systemd writes the log blocks to disk as a machine crashes
The same way syslog does. Do you also complain about syslogd hogging CPU resources? Seriously, what are you smoking?
No, it depends on one thing. Does the first process manage system processes or everything? An event manager is a system process listening and acting on events. They are two different things.
What if the event manager responds to events by spawning processes? I guess it would then need to signal some kind of event to the process manager to do that.... <head splodes>
When you are only confined by your imagination, anything is possible. You won't actually know, though, until you try to implement it. There are plenty of cases in software development where the ideal of perfect modularity has been compromised to meet practical benchmarks. Go talk to Linus sometime about monolithic vs microkernels if you don't believe me.
My conclusions is systemd has several fatal design flaws, some presented here, that make it unsuitable for server systems.
Well, for your use cases that may be true, but it clearly isn't generally true. Some of the most enthusiastic systemd adopters are server admins and systems integrators.
I've had this discussion with MrKaos. Their use case and philosophies tend to be unique. Yes, init and inittab were designed to do some things that sysvinit and systemd reimplemented, but no, that's not necessarily a good reason to prefer using those tools. MrKaos should refrain from generalizing about systemd based on their own experiences and use cases.
Those who advocate genocide deserve every protection afforded by law, and none afforded by common human decency.
Systemd was not about speed, although that should be a side effect of a parallelized (dependency-resolving) init system. The point of system is not boot speed but accurate process management. PIDs are a stupid hack. Process management needs to be handled by the kernel, because the kernel is the final source of truth about processes in the system, and because the kernel can make guarantees about process resources that userspace cannot. The reason that systemd exists has nothing to do with init scripts and everything to do with cgroups. The rest of the decisions are more or less what any modern init system would do, and in point of fact OpenRC has implemented most of the same features (and implemented them almost exclusively in C, just like systemd).
The depth of ignorance displayed by systemd detractors is telling. You guys assumed that because you didn't know the reason why it exists, and that you know everything about Unix, therefore there was no reason for systemd and the developers were just doing this for no reason. In reality, every commercial Unix replaced sysvinit, because scripts relying on PID values are fundamentally a stupid idea.
I get the attraction of an OS that is all scripts, even if you're brain-damaged enough to think that Bash is a good language for that. I even get that there was a sweet spot in the 90s and early naughties where bash and perl and sysvinit were all the best tools for the job and complimented each other nicely. That era is over, and we have better tools now. You're going to have to retrain and skill up just like the rest of us, or at the very least you're going to have to admit that there is a way forward and it is not your preferred path (and presumably quit complaining about things not going your way).
There are packages out there that indirectly depend on systemd being the init process of the system. You are right there. Finally we have an init process that does something useful:-)
The init process starts and stops services and limits what those services can do: It stuffs them I to cgroups and namespaces as necessary. It also provides a nice interface to manage cgroups and namespaces.
That interface is used mostly by systemd-logind to manage user sessions.
Other software that needs information about these user sessions use logind to manage those.
So you got a classic layered architecture here.
systemd has only won the day by fiat.
No need to lie, the processes were all public. Your side lost on technical merit, and you've never even bothered to familiarize yourself with the arguments. The simple truth is that not only were there good reasons to replace sysvinit, but every other commercial Unix and OpenRC and Upstart replaced sysvinit for the same good reasons. Fundamentally, scripts are a bad way to manage system processes, which is why there have been twenty years of effort trying to introduce kernel-level process management in Linux. Systemd is the result of a long development effort that you ignored from inception until after it was the dominant technology, and now instead of learning about this new technology you're walling yourself off from it. Good. Stay that way. Hopefully devuan can be the shibboleth that identifies ossified intellects and those who reject change on principle.
Those who advocate genocide deserve every protection afforded by law, and none afforded by common human decency.
No, unit files don't run shell scripts. They can as an easy migration path, but they are designed to operate independently of the shell.
I realise that. I said unit files are *going* to run shell scripts, in fact they are going to run *existing* int.d entries for most vendors that .
The way you *say* unit files *should* be configured is how inittab entries are configured after *optionally* being set up by shell scripts in the rc system, that is why a dependency tree isn't required. This misuse case is consistently demonstrated in these arguments and I haven't seen a distribution that utilizes initd properly. Which is crazy.
Systemd was designed to solve problems that are not easily solvable with initd. If you don't have those problems with initd, then you don't see the need for systemd.
Well what are they? I keep asking this question and I get no clear answer. I see plenty of vendors and distributions not using initd properly. They look at the steaming pile of shit scripts that Red Hat created in their misunderstanding of the rc system and throw their hands up, and I don't blame them.
What I don't buy is the same group that had a crap understanding of sysVinit and the rc system in the first place is now leading the charge to replace initd <slaps forehead> WTF? Perhaps my tolerance of bullshit is just extremely low.
Furthermore, if you happen to like initd, you probably hate systemd.
It's not about liking it. It's about how valuable the return on investment in learning a bad idea or investing effort in calling it out for what it is. The best argument offered by systemd proponents is 'well you must be stupid, cause RTFM systemd" but have they ever spent any effort figuring how to actually use initd properly?
Have you? Have you ever configured a custom runlevel? or figured out how an rc script and an intitab entry should be used together? If you haven't where are your grounds for criticism? I've invested effort in learning systemd, it looks like a whole lot of domain knowledge to me. I don't really want to invest any more of my time into it, but I have to because inevitably I am going to encounter it somewhere.
What I don't like is being maneuvered into learning software and putting effort into something I can see is pretty awful.
but if not feel free to keep building up strawmen just so you can knock them down.
And you just feel free to ignore all the arguments about how the CPU scheduler actually works. How you can call that a strawman just boggles my mind with evidence that you are relying on social proof.
Seriously, what are you smoking?
Look, I don't really understand why you what to hurl emotive language around about operating system concepts. I can do it too, I just prefer not to. Yep, you can piss me off if you want but so far I've conducted a conversation with you about these things through a hang-over and a pretty bad headache right now, so maybe if you can keep it civil instead of treating me like a jerk maybe we can both learn something. Is that ok?
If systemd is so good, why can't you guys explain to me why instead of ignoring my arguments?
I sincerely want to know why I'm being asked to replace skill with a whole lot of dead wood domain knowledge? You're suggesting to replace an elegant and subtly powerful initd with a complete paradigm shift, by the people who couldn't use initd properly in the first place and the best reason you can give me is, because someone else knows better. How can I take that argument seriously?
The same way syslog does. Do you also complain about syslogd hogging CPU resources?
No I don't, I just don't want my init process to do it. I want it to be lightweight and I want it to be out of my applications way. I don't want it to generate application latency. I don't care about syslog gener
My ism, it's full of beliefs.
Or maybe you want state-defined infrastructure and continuous integration
I think you'll find the reason that Etcetera has not answered you is because this is the primary operating mode of initd. These sorts of arguments for systemd are flimsy at best because they ignore existing functionality in initd.
I have no idea what you mean by this. Accurately defining the dependency graph for booting a system in a general way (ie: for any type of system with any type of hardware) is not a simple process in any language.
He is telling you initd is not complex, it is a foundation that you build complex modular interactions on, and that you can't make systemd less complex because it already is. Etcetera is telling you that you don't need a dependency graph because you are attempting to solve the wrong problem.
My ism, it's full of beliefs.
Well what are they? I keep asking this question and I get no clear answer.
That's because you're not listening. You're just shouting people down saying the problems aren't really problems. As I said earlier, it comes down to your opinion. You don't think they are problems, so you don't see them.
I see plenty of vendors and distributions not using initd properly.
Well, if you think it's so straightforward, why don't you lead the charge and implement all of systemd's features with init+inittab? Why is it taking so long for the anti-systemd crowd to come up with a suitable replacement? If it was really that easy, I would have expected to see it years ago.
It's not about liking it. It's about how valuable the return on investment in learning a bad idea or investing effort in calling it out for what it is.
An hour of reading man pages and learning how to use some new utilities doesn't seem like that much an investment to me.
You're suggesting to replace an elegant and subtly powerful initd with a complete paradigm shift, by the people who couldn't use initd properly in the first place and the best reason you can give me is, because someone else knows better.
You see, you don't understand why nobody is explaining it to you, but it has been explained many times by many people. I could make a list, but I'm tired of doing it, and you probably won't listen anyway. There are a ton of whitepapers and discussion topics on the init system and the various ways of implementing it. It is you who is ignoring all of the arguments in favor of your preference.
No I don't, I just don't want my init process to do it.
Your init process (systemd) doesn't do it. Journald does.
You seem to thing having an highly active init process that generates I/O is a good thing
An event manager/dispatcher is going to generate I/O. I don't consider that a good or a bad thing inherently. It depends on how much (or if) you need the event manager. Considering that it is generating polling events at the same level as the watchdog and kworker threads, I don't think this is a huge problem to worry about. If you are going to make the argument that it causes significant application latency, then show me a real benchmark. Otherwise, this is just hand-wringing.
I think that initd could use a complementary event management subsystem, which is what I thought systemd was. If you understood how initd worked, the answer would be immediately apparent because it is obvious.
The only "obvious" thing that comes to mind from your description is an event manager that switches runlevels for you. Such a thing would be so inferior to what systemd does that it would laughable.
I was responding to Hognoxious' post, in which he or she (or it) wrote "and also people don't like being forced."
So you and I are saying the same thing - there's no force involved. Devuan's existence is proof there is no force involved.
That's because you're not listening. You're just shouting people down saying the problems aren't really problems. As I said earlier, it comes down to your opinion. You don't think they are problems, so you don't see them.
Bullshit. I ask one simple question What is the use case that systemd answers that initd does not and so far all I hear is crickets. I have repeatedly asked this question and still I have no answer. You are trying to reframe the arguments you yourself have not been able to answer. If any systemd advocate was able to answer they would simply answer the question with a concise justification.
Considering systemd advocates also have the benefit of hindsight to provide that concise justification of why you should use systemd, why don't you?
I'm listening, intently, for the use case over all the crickets.
Well, if you think it's so straightforward, why don't you lead the charge and implement all of systemd's features with init+inittab? Why is it taking so long for the anti-systemd crowd to come up with a suitable replacement? If it was really that easy, I would have expected to see it years ago.
I'm pro-initd, it's better than anti-systemd and much better than being anti-initd. You can't even justify the existence of systemd with a concise use case, so what exactly has to be written?
That said the reason I have been asking is for that exact reason: what complementary piece of software is required, what does it need to do, how should it interact with initd. So far the answer is software to make the core features of initd available to a wider audience because they aren't being used, that SCO effectively stole core functionality from initd with the AT&T source code license, Cgroups and, of course, better documentation. Most of all, is to free initd from that bloated crapware rc implementation that Red Hat surrounded it with.
So yes, I'll contribute to the devuan effort as I ascertain what exactly is required.
An hour of reading man pages and learning how to use some new utilities doesn't seem like that much an investment to me.
And how much time did you invest learning initd? A question you have avoided.
Considering I have a lab of VMs with systemd testing our applications, that I got my head around unit files, journalctl, systemctl, exploring its multitude of properties over a year ago because I have to be able to understand its impact. Guys like you are professing that it is so good that anyone using initd must be fucking idiot, all I've seen you and many systemd advocates profess is your ignorance of how to use initd properly and that someone says systemd is really good and that I should use it too.
I'm not a systemd expert, I'm still testing it. You and all the other systemd experts are supposed to tell me why I *should* use it, what I'm missing, why it's so great and you haven't and I think that is a rather hypocritical and disingenuous position that you maintain. Testing systemd so far hasn't shown me a good reason to use it, however it has shown me a few reasons why I should not.
You see, you don't understand why nobody is explaining it to you, but it has been explained many times by many people. I could make a list, but I'm tired of doing it, and you probably won't listen anyway. There are a ton of whitepapers and discussion topics on the init system and the various ways of implementing it. It is you who is ignoring all of the arguments in favor of your preference.
No, you won't make a list because you don't know. You've had two weeks and the only argument you can provide is to twist my words, ignore my questions and be rude. Pretty typical of someone arguing from a position of social proof to be unable to answer counter-rationalism and instead replies with moral superiority.
You should examine your own position relative to your accusations.
If you are going t
My ism, it's full of beliefs.
Bullshit. I ask one simple question What is the use case that systemd answers that initd does not and so far all I hear is crickets.
Multiple people have tried to tell you. There are plenty of whitepaper documents that describe the use cases. There is the entire Debian debate topic on the subject. In what way is any of this an insufficient justification? Why do you need yet another justification. Fact is, it doesn't matter the justification. You've decided systemd is unnecessary, so any justification that is provided you will refute or ignore. Like I said earlier, it comes down to a matter of preference. If you don't need it for your use cases and/or you prefer initd, that's fine. Go ahead and keep using it. Those of us that like systemd and need it will continue using it.
So far the answer is software to make the core features of initd available to a wider audience because they aren't being used
No. What it comes down to is, I don't want to replicate systemd functionality by writing a bunch of shell scripts. I know it can be done. Apparently you enjoy doing that sort of thing. I don't. I want core functionality (ie: booting a system with a complex set of dependencies) to be readily available by writing/modifying a few configuration files, and that's it. Moreover, if I want to determine the status of a process and do something with that information, I think it is quite handy that systemd provides that interface. I don't have to scrape a bunch of logs or test for sockets and such. That information is just there for me to grab in a standardized, easily parseable format, provided by systemd.
Considering I have a lab of VMs with systemd testing our applications, that I got my head around unit files, journalctl, systemctl
You claim that, but you still don't seem to know the difference between systemd and journald.
Guys like you are professing that it is so good that anyone using initd must be fucking idiot
Actually, if you look up in the thread, you will see that I am, and have been, saying the exact opposite. If you want/like initd, by all means keep using it. I have no problem with that. But if you call me an idiot for liking/preferring systemd, that's what I take issue with.
You and all the other systemd experts are supposed to tell me why I *should* use it
Answer: use it if you want to, it has nice features. If you want to redo all of that with a bunch of custom shell scripts, go ahead and do it. Clear enough?
You've had two weeks and the only argument you can provide is to twist my words, ignore my questions and be rude.
I don't have a lot of time to write long, detailed responses. I apologize for being curt; it is not my intention to be rude. But I don't see how I'm twisting your words. You are making claims about impact on performance without evidence and I'm asking for proof. You are making statements like "it generates i/o and therefore it is worse than a bunch idle processes doing nothing", which doesn't make any sense at all. And you assert that somehow the principal operation of journald is so inherently different from syslogd that you lose information, which is just wrong.
And there we have it. You yourself are now citing Red Had's dumb serialization of initd's functionality with a crappy set of runlevel shell scripts and your limited understanding of initd's functionality
Speaking of twisting words, that is not what I said. However you choose to do it, rc scripts or some other mechanism, ultimately your "event manager" would have to initiate a runlevel change. That's the only thing init can do in response to some sort of "event".
http://www.manpages.info/linux...
Being forced into following fools who can't make an
Multiple people have tried to tell you. There are plenty of whitepaper documents that describe the use cases. There is the entire Debian debate topic on the subject. In what way is any of this an insufficient justification? Why do you need yet another justification.
Multiple people have demonstrated that they didn't use initd properly in the first place. If you have further documentation to send me that demonstrates a full understanding of initd functionality before advocating replacing it send it. So far all of the articles I've read don't demonstrate that understanding.
Even you have demonstrated a consistent lack of understanding of initd functionality and when asked, three times now, how much time you've invested in learning it, you ignore the question. This double standard again reeks of social proof.
You've decided systemd is unnecessary, so any justification that is provided you will refute or ignore.
No, I'm looking for the irrefutable systemd use case that initd isn't capable of answering and so far no one has provided it.
You are making claims about impact on performance without evidence and I'm asking for proof. You are making statements like "it generates i/o and therefore it is worse than a bunch idle processes doing nothing", which doesn't make any sense at all.
My advice is you understand how the CPU scheduler functions to understand this. As I said, I'm still testing systemd and it involves doing work to understand it.
Moreover, if I want to determine the status of a process and do something with that information, I think it is quite handy that systemd provides that interface. I don't have to scrape a bunch of logs or test for sockets and such. That information is just there for me to grab in a standardized, easily parseable format, provided by systemd.
You mean like the /proc interface.
Perhaps we will see a shell like interface emerging for systemd next?
You claim that, but you still don't seem to know the difference between systemd and journald.
I also claim not to be a systemd expert and that I am getting my head around it and in the process have found that it is a monolithic concentration of domain knowledge.
I've also repeatedly asked for the use case it answers that initd cannot so I can test it.
I don't have a lot of time to write long, detailed responses. I apologize for being curt; it is not my intention to be rude.
ok, appreciated.
rc scripts or some other mechanism, ultimately your "event manager" would have to initiate a runlevel change. That's the only thing init can do in response to some sort of "event".
No, just no. Obviously this is why better documentation is required.
Answer: use it if you want to, it has nice features. If you want to redo all of that with a bunch of custom shell scripts, go ahead and do it. Clear enough?
What you are arguing is a change of paradigm and mindset. You are arguing that complex is better than simple and I am arguing that simple can become complex.
And here you are, again, accusing me of being rude while in the same breadth calling me (and everyone else) a fool and/or idiot, but I digress...
No, who is the fool, the fool or those who follow the fool. Being forced to use systemd in some distributions is what I mean by being forced to follow fools.
The theme throughout systemd discussions is that those advocates refuse to listen to dissenting opinion and when challenged with counter-rationalism have nothing to offer. That is a sign of foolishness.
If you're going to claim that it's because everybody is an idiot, then that's a reasoning that is pretty hard to accept.
This is the first time I've lost my patience and I di
My ism, it's full of beliefs.
Even you have demonstrated a consistent lack of understanding of initd functionality and when asked, three times now, how much time you've invested in learning it, you ignore the question.
I have not made a concerted effort to learn about undocumented features of init. I have used the features various distributions have provided for me to use. That's why distributions exist after all. If I were interested in building my own distribution, maybe we would be having a different discussion. As it is, I am more interested in just maintaining my systems and keeping things running smoothly. So I use the distribution tools that are provided to me. In the past it was initd and I used it without complaint. Now it is systemd, and I'm glad for the change.
What you are arguing is a change of paradigm and mindset.
No, I'm not. I am simply accepting of the fact that distro maintainers have chosen to replace initd with systemd. I have learned the new tools. I like them. I don't see the huge problem.
You are arguing that complex is better than simple
No. I'm arguing that simple is not simple. It just seems that way because you are used to it. When you've piled up a bunch of hacks and workarounds and have become used to implementing on your own or doing without missing functionality, you may think everything is great but it's not.
and I am arguing that simple can become complex.
If you want to write it. That's the whole point. I don't want to write it. I want the functionality to just be there.
The theme throughout systemd discussions is that those advocates refuse to listen to dissenting opinion and when challenged with counter-rationalism have nothing to offer.
You may think you are offering counter-rationalism, but you're not. Your entire argument boils down to "initd is better because I prefer doing things that way." You yourself have offered no other compelling reason for it. There is nothing wrong with a dissenting opinion, but understand that you are arguing for a preference, and other people have different preferences.
and I didn't call anyone an idiot
Well, I didn't call anyone an idiot either. So I guess we're even.
No, I'm looking for the irrefutable systemd use case that initd isn't capable of answering and so far no one has provided it.
Ok, I have time for one: socket activation. Tell me how to do that with initd. Don't say I don't need it. I want it. And don't say inetd. That's not good enough.
The depth of ignorance displayed by systemd detractors is telling. You guys assumed that because you didn't know the reason why it exists, and that you know everything about Unix, therefore there was no reason for systemd and the developers were just doing this for no reason. In reality, every commercial Unix replaced sysvinit, because scripts relying on PID values are fundamentally a stupid idea.
I get the attraction of an OS that is all scripts, even if you're brain-damaged enough to think that Bash is a good language for that. I even get that there was a sweet spot in the 90s and early naughties where bash and perl and sysvinit were all the best tools for the job and complimented each other nicely. That era is over, and we have better tools now.
And you're missing the point completely (or haven't looked at a RedHat-style initscript in a while).
There's nothing inherent in the SysV Initscript interface that mandates the use of pid files. For many/most daemons that are reliable, that's probably good enough, but it doesn't have to be. /sbin/service status, is just a call to a script. If there's something more involving service management that is a better mechanism than pid files than determining the state, so be it. (The killproc function RH provides in /etc/init.d/functions doesn't even use PID files by default unless provided one.) The point is, whatever it's doing to determine status a) has a well-defined interface (the script call), and b) is in most cases pretty simple and grokkable and *debuggable*, and not a bunch of complex C code.
Your larger point is begging the question, however. SysVInit is about starting services, not managing services (except to the extent it starts and stops things when switching runlevels). If you need realtime service babysitting, or on-demand forking, then you should use a system started by SysVInit that specializes in that. inet, xinetd, and a daemontools package (and even a systemd package focused solely on service management!) could all function this way, while still providing deterministic, script-driven startup and control for the things that don't need that layer of complexity. By combining /bin/init, rc system scripts, and service initscripts all into a single binary blob, it removed those interface layers and smooshed it all into a single one-size-fits-all black box.
I (and many others) would prefer the flexibility of being able to swap in control daemons without handing over control of my entire system to this monstrous blob.
Hire a Linux system administrator, systems engineer,