Yeah, yeah I know the history of its development and how log files are binary and the whole debug kernel flag fiasco. And I don't care. By the time I used systemd, that had already long passed.
I switched from Squeeze to Jessie a couple years ago, had some growing pains as I learned how to use systemd... but that was it. No stability issues, no bugs. Can't say whether things run better, but they definitely don't run worse.
I had only really been using Linux for a few years before the onset of systemd, and hon
Perhaps you have had no problems with systemd because you aren't trying to use it to do much.
Lots of people, myself included, have had issues trying to get things which are trivial in pre-systemd or on other OSes to work properly and consistently on systemd. There are many, many, many examples of issues. If someone asked me for examples, I'd have a hard time deciding where to start because so many things have been gratuitously changed. If you really think there aren't examples, just read this thread.
On the other hand, I have yet to see real technical discussion about problems that systemd apparently is fixing. I honestly and openmindedly am curious about what makes systemd good, so I've tried on several occasions to find these discussions where good technical reasoning is used to explain the motivations behind systemd. If they exist, I haven't found any yet. I'm hoping some will appear as a result of this thread.
But you bring up the idea that the "market has spoken"? You do realize that a majority of users use Windows, right? And people in the United States are constantly electing politicians who directly hurt the people who vote for them more than anyone else. It's called marketing. Just because something has effective marketing doesn't mean it doesn't suck.
Don't let the perfect be the enemy of the good. If you have so many examples that you "don't know where to start", then start anywhere. You don't have to come at me with the best, most perfect example. Any example will do! I'm actually very interested. And I have, out of curiosity, looked a bit. But like you looking for why systemd is better, I came across a similar problem.
Your reply just continues the cycle I spoke of, where people who potentially know better than me, like you, claim there are problems bu
systemd fails silently if something is wrong in/etc/fstab. It just doesn't finish booting. Which is moderately annoying if you have access to the system console and you can guess that an unchanged/etc/fstab from before systemd that worked for a while with systemd is now suddenly toxic
If you do not have easy access to the system console or you are not blessed with divine inspiration, that is quite a bit more than annoying. Thanks to the binary log files you cannot even boot something random and read the logs, but at least you aren't missing anything, because nothing pertinent to the error is logged anyway.
The problem is that one camp won't admit that old init is a pile of shit from the 80's whose only virtue is that the stench has faded over time, and the other camp won't admit that their new shiny toy needs to be understandable and debuggable.
A proper init system needs dependencies and service monitoring. init + monit does not cut it today. Systemd does that bit rather impressively well. It's just terrible at actually booting the system, all the early boot stuff that you could depend on old init to get right every time, or at least spit out aggressive messages about why it failed.
Meanwhile here I am, running Gentoo, with init scripts that have had real dependencies for over 15 years (as well as a bash-based but much nicer scaffolding to write them), with simple to use admin tools and fully based on text files, with cgroup-based process monitoring (these days), and I'm wondering why everyone else didn't get the memo and suddenly decided to switch to systemd instead and bring along all the other baggage it comes with. Debian and Ubuntu had garbage init systems, and yet it seems *nobody* ever took notice of how Gentoo has been doing things right for a decade and a half. You can also use systemd with Gentoo if you want, because user choice is a good thing.
and yet it seems *nobody* ever took notice of how Gentoo has been doing things right for a decade and a half.
Gentoo does everything right except exist. On alternate days you can follow the install instructions identically and get totally different results. Gentoo is its own worst enemy.
With that said, lots of people have screamed often and loudly in many locations that Gentoo proves that this stuff is possible without systemd, and that there are at least two init systems which were already in relatively common use when systemd was shat out which support parallel init. This has simply been resoundingly ignored by t
I ran Linux on the desktop (and LOTS of servers) for 19 years, but finally got Mac religion about 4 years ago. As I had used Gentoo for about 5 years over this time, I was wondering how they had handled this. Found this: https://wiki.gentoo.org/wiki/G... [gentoo.org]. Looks like it's just as straightforward as I would have hoped, and the documentation was just a clear as usual for the project. It actually makes me want to emerge a new desktop system, just for old time's sake.
At one point I did have exactly the problem addressed in the article; I followed the steps therein, and the problem went away, and hasn't recurred since. I won't pretend I've never had issues with Gentoo; I have, although probably 80% turned out to have been self-inflicted. Nonetheless I find that it has bought me valuable time to not have to deal with all the systemd nonsense so long as I don't try to run Gnome, which I wouldn't anyway (I prefer XFCE). I've no doubt that sooner or later I will be forced
systemd fails silently if something is wrong in/etc/fstab. It just doesn't finish booting. Which is moderately annoying if you have access to the system console and you can guess that an unchanged/etc/fstab from before systemd that worked for a while with systemd is now suddenly toxic
It retries for a bit, but it DOES eventually fail and kick you out to a recovery shell. It just doesn't do it immediately because it assumes that the device may just need some time to come up.
Thanks to the binary log files you cannot even boot something random and read the logs,
What do you mean "boot something random"? I don't see why a generic recovery disk can't have journalctl installed. How about a Debian install disk?
but at least you aren't missing anything, because nothing pertinent to the error is logged anyway.
Not true at all. If you don't know how to use journalctl, that's on you.
Nothing pertinent to the error was logged. Feel free to not believe it.
I don't believe it. Feel free to provide details on how you were looking through the logs.
It did not fail to a recovery shell after being left overnight.
There is a way to boot into an emergency shell when this happens.
Your attitude is part of why systemd is so reviled.
I could say the same about yours. I mean, the parsing of fstab by the local-fs.target is VERY well documented. And so are the early boot debugging features. Why would you upgrade a system before at least taking a cursory look at the documentation? I successfully migrated a moderately complex system dependent on an external ZFS disk array, several NFS expo
There is a way to boot into an emergency shell when this happens.
Yet you don't seem to be willing to share that information. That's probably the attitude he's talking about, if I had to guess. I remember a time when a member of the Linux community would have responded with something helpful along the lines of:
You can add break to your kernel line to get a shell on your initram, you can even decide to get it before or after mounting...
Possibly even elaborating on just how to go about doing that but, at the very least, pointing the user in the right direction.
There was a time when ignorance was met with information, rather than ridicule. If you want people to embrace your beloved systemd, perhap
Which is moderately annoying if you have access to the system console and you can guess that an unchanged/etc/fstab from before systemd that worked for a while with systemd is now suddenly toxic
As far as I know, this (correct according to documentation/intent) behaviour has been the same since any stable distribution shipped systemd as the default init.
If you do not have easy access to the system console or you are not blessed with divine inspiration, that is quite a bit more than annoying.
And should teach you to always 'mount -a' when you have made a change to your/etc/fstab.
Thanks to the binary log files you cannot even boot something random and read the logs, but at least you aren't missing anything, because nothing pertinent to the error is logged anyway.
In most of the cases I have seen this, it is when someone wrote a service unit file without even bothering to read systemd.service(5) and didn't put a Ty
Here we go again with all the insinuations and accusations. The/etc/fstab was correct with the old init. It was incorrect with systemd. Therefore no amount of mount -a would have helped.
"So, you were relying on bugs to boot your systems?"
Have you stopped beating your mother when she tells you to come out of your basement?
Well, I have never seen this myself, or seen valid bug report about. Yes, if your fstab entry was correct and that caused systemd to not boot, you should file a bug report.
However, I have also seen soooo many invalid complaints about systemd where the systemd beaviour was correct but other implementations were wrong (conflicted with the sgstem documentation).
systemd's approach is to boot correctly, or if a required resource is not available to not boot into a partial state.
Here's a few. It has no concept of imperative (Just do what I said), or best effort (everything must be perfect or it won't even try to continue). It hard codes things that should be configurable or external. For example, it has it's own idea of what makes a device ready for a filesystem to mount and it can't be told otherwise.
All of that is why soft RAID must be assembled in the initrd before systemd has a chance to screw it up. Otherwise, there is simply no way to tell systemd to complete the boot process
And once again a systemd opponent proves to be an idiot or a liar. Handling a degraded array and making it bootable has always been the job of the initramfs. See this Debian bug dealing with this issue [debian.org], for example, where the maintainer himself admits so.
Funny thing is, you were so desperate to deny the systemd bug that you pulled up the wrong issue entirely.
The initramfs HAS to handle the RAID for the root filesystem, naturally. Non-root RAID is supposed to be handled after transferring control to the actual init.
Same for non-root btrfs.
If there's an idiot or liar in this thread, it isn't me.
The initramfs has to handle all degraded arrays, otherwise they will be marked inactive, and not mounted. The right place to fix issues with degraded arrays being marked inactive (and thus umountable) is in the initramfs.
Which the Debian maintainer admitted; it was his change in the initramfs scripts that marked the arrays inactive and made them fail to mount.
Again, you are so bound up in your systemd hate that you fail to read.
I read just fine. The workaround is in initramfs, but that's just because systemd is incapable of handling it. Prior to that, the old sysV init handled it just fine.
Not that when I first tested systemd, it was on a working test dummy with a btrfs. It worked just fine before, including when I degraded btrfs. Then I 'upgraded' to systemd and it wouldn't boot. It wouldn't just fail to mount the btrfs (non-root), it just dropped to an emergency shell with no remote services running.
While I do have concerns about systemd, most dependency schemes have a way for a component to declare itself a prereq to an unwitting third party component. It's a valuable cabability in general when trying to enhance behaviors of existing systems without modifying components needlessly.
I'll grant the similarity, but at least the Debian scripts don't create hard dependencies. The boot won't stop as a result. That system might refuse to implement a new configuration if it detects that the advisory dependency cannot be met, but end of the day, the links in/etc/rcN.d will be control the boot and if one fails, it will move on.
The X- prefix provides some indication of knowledge that it's a dirty hack, but it is somewhat less problematic given the small number of init.d scripts all kept in one
There's many hours of reading the Debian CTTE and bug archives about the system init discussion if you have a bit of time and are that interested.
A short version, which is mostly still applicable and accurate for the large part from the past 2 years, is the Debian debate wiki pages with the arguments for and against various init systems to switch to. It's notable that *no-one* wanted to use sysvinit moving into Jessie, and the votes for upstart were heavily partisan being current and ex-canonical employee
Systemd has three fundamental issues: -It's not systemd versus sysv, it's systemd vs. sysv/syslog/cron/at/user session management. That's a whole lot of potential controversy to take on for a project that you either adopt as a distro or you don't, and giving the users choice in a matter like this is an impractical thing for most distributions. It also creates challenges for security, because something you do to provide user-level access to some capabilities becomes a potential path for a vulnerability (of
The simple fact of the matter is both *for* and *against* are necessarily going to be a matter of opinion. Poeple *like* or *don't like* certain things. There are sometimes objective pieces of data (time for computer to do X, amount of memory consumed to do y), but other than boot performance, there isn't an objective good or bad to argue here, it's a matter of consensus and pissing off the fewest people and accommodating the tastes of the most people possible. The logistics of managing processes and sta
But 'who to piss off least' is a factual assertion masquerading as an opinion. There is simply no proof that systemd pisses off more people than SysV. Given that we don't see a massive rise in BSD usage, that Red Hat senior officers say they see no impact on RHEL7 deployments and that Devuan is not advancing in any meaningful way, there is in fact a strong possibility that systemd pisses of a majority of loud whiners, but that is not the same.
One, it would be nice to have more than the opinion of officials who stand to look the worst if there were a problem. Even if there were a problem, people in that position stand to benefit by making that problem invisible.
Two, as time passes, it becomes increasingly difficult to justify staying with RHEL6 era software all *just* to avoid systemd. That doesn't mean customers *happily* go to systemd, but that they have to.
Three, even should systemd be a make or break vendors
It is really strange how for some reason disregarding well-founded statements and just saying that there is a hidden reason why they don't fit seem to be common among systemd opponents and crazy right-wingers.
Given the amount of invective coming out of the anti-systemd camp, complaining about mild epithets like 'whiners' also sounds a lot like the standard alt-right tactic "Yes, but you're the real racists|sexists|whatever".
In other words, snowflake, shut up and come back when you have actual hard facts to
Standard facilities to 'daemonize' software without the software having to do the right double fork and exit dance. It would have been one thing if libc had provided a function, but it hasn't so every daemon has had to do that weird dance itself, and many of them get it wrong, particularly home-grown software
Systemd has three fundamental issues: -Piss poor community engagement. Their reaction to any request or security report is to first say the requester or reporter is an idiot. For example: https://github.com/systemd/sys... [github.com] where he claims that it's perfectly valid for a confused systemd to just run user as root instead of error out.
If I read *just* that bug report, the part of the community engagement that is not working well is from the community of incensed (seemingly Debian) users who insult people in bug reports.
Pottering explained the general approach they took which was:
In systemd we generally follow the rule that when we encounter a unit setting that does not validate syntax-wise we'll log about it and ignore it, for compat reasons. We do the same for User= here as for all other options.
However, he was open to taking a different approach for most security-related settings, and as such the issue is fixed [github.com]
Lots of people, myself included, have had issues trying to get things which are trivial in pre-systemd or on other OSes to work properly and consistently on systemd. There are many, many, many examples of issues
Many, many examples which are never described in detail, or when enough detail is given to reproduce them turn out to not exist or have already been fixed.
The road to ruin is always in good repair, and the travellers pay the
expense of it.
-- Josh Billings
I have no problem with systemd (Score:4, Interesting)
Yeah, yeah I know the history of its development and how log files are binary and the whole debug kernel flag fiasco. And I don't care. By the time I used systemd, that had already long passed.
I switched from Squeeze to Jessie a couple years ago, had some growing pains as I learned how to use systemd... but that was it. No stability issues, no bugs. Can't say whether things run better, but they definitely don't run worse.
I had only really been using Linux for a few years before the onset of systemd, and hon
Re:I have no problem with systemd (Score:5, Insightful)
Perhaps you have had no problems with systemd because you aren't trying to use it to do much.
Lots of people, myself included, have had issues trying to get things which are trivial in pre-systemd or on other OSes to work properly and consistently on systemd. There are many, many, many examples of issues. If someone asked me for examples, I'd have a hard time deciding where to start because so many things have been gratuitously changed. If you really think there aren't examples, just read this thread.
On the other hand, I have yet to see real technical discussion about problems that systemd apparently is fixing. I honestly and openmindedly am curious about what makes systemd good, so I've tried on several occasions to find these discussions where good technical reasoning is used to explain the motivations behind systemd. If they exist, I haven't found any yet. I'm hoping some will appear as a result of this thread.
But you bring up the idea that the "market has spoken"? You do realize that a majority of users use Windows, right? And people in the United States are constantly electing politicians who directly hurt the people who vote for them more than anyone else. It's called marketing. Just because something has effective marketing doesn't mean it doesn't suck.
Re: (Score:3)
Don't let the perfect be the enemy of the good. If you have so many examples that you "don't know where to start", then start anywhere. You don't have to come at me with the best, most perfect example. Any example will do! I'm actually very interested. And I have, out of curiosity, looked a bit. But like you looking for why systemd is better, I came across a similar problem.
Your reply just continues the cycle I spoke of, where people who potentially know better than me, like you, claim there are problems bu
Re:I have no problem with systemd (Score:5, Insightful)
systemd fails silently if something is wrong in /etc/fstab. It just doesn't finish booting. Which is moderately annoying if you have access to the system console and you can guess that an unchanged /etc/fstab from before systemd that worked for a while with systemd is now suddenly toxic
If you do not have easy access to the system console or you are not blessed with divine inspiration, that is quite a bit more than annoying. Thanks to the binary log files you cannot even boot something random and read the logs, but at least you aren't missing anything, because nothing pertinent to the error is logged anyway.
The problem is that one camp won't admit that old init is a pile of shit from the 80's whose only virtue is that the stench has faded over time, and the other camp won't admit that their new shiny toy needs to be understandable and debuggable.
A proper init system needs dependencies and service monitoring. init + monit does not cut it today. Systemd does that bit rather impressively well. It's just terrible at actually booting the system, all the early boot stuff that you could depend on old init to get right every time, or at least spit out aggressive messages about why it failed.
Re:I have no problem with systemd (Score:4, Interesting)
Meanwhile here I am, running Gentoo, with init scripts that have had real dependencies for over 15 years (as well as a bash-based but much nicer scaffolding to write them), with simple to use admin tools and fully based on text files, with cgroup-based process monitoring (these days), and I'm wondering why everyone else didn't get the memo and suddenly decided to switch to systemd instead and bring along all the other baggage it comes with. Debian and Ubuntu had garbage init systems, and yet it seems *nobody* ever took notice of how Gentoo has been doing things right for a decade and a half. You can also use systemd with Gentoo if you want, because user choice is a good thing.
Re: (Score:2)
and yet it seems *nobody* ever took notice of how Gentoo has been doing things right for a decade and a half.
Gentoo does everything right except exist. On alternate days you can follow the install instructions identically and get totally different results. Gentoo is its own worst enemy.
With that said, lots of people have screamed often and loudly in many locations that Gentoo proves that this stuff is possible without systemd, and that there are at least two init systems which were already in relatively common use when systemd was shat out which support parallel init. This has simply been resoundingly ignored by t
Re: (Score:2)
I ran Linux on the desktop (and LOTS of servers) for 19 years, but finally got Mac religion about 4 years ago. As I had used Gentoo for about 5 years over this time, I was wondering how they had handled this. Found this: https://wiki.gentoo.org/wiki/G... [gentoo.org]. Looks like it's just as straightforward as I would have hoped, and the documentation was just a clear as usual for the project. It actually makes me want to emerge a new desktop system, just for old time's sake.
Re: (Score:2)
Re: (Score:2)
I must admit that I did not know about Gentoos init system. It seems very sensible.
Re: (Score:2)
systemd fails silently if something is wrong in /etc/fstab. It just doesn't finish booting. Which is moderately annoying if you have access to the system console and you can guess that an unchanged /etc/fstab from before systemd that worked for a while with systemd is now suddenly toxic
It retries for a bit, but it DOES eventually fail and kick you out to a recovery shell. It just doesn't do it immediately because it assumes that the device may just need some time to come up.
Thanks to the binary log files you cannot even boot something random and read the logs,
What do you mean "boot something random"? I don't see why a generic recovery disk can't have journalctl installed. How about a Debian install disk?
but at least you aren't missing anything, because nothing pertinent to the error is logged anyway.
Not true at all. If you don't know how to use journalctl, that's on you.
Re: (Score:2)
It did not fail to a recovery shell after being left overnight.
And a generic recovery disk can obviously have journalctl installed. It just didn't. Which meant I had to mess with PXE and all that again.
Nothing pertinent to the error was logged. Feel free to not believe it.
Your attitude is part of why systemd is so reviled.
Re: (Score:2)
Nothing pertinent to the error was logged. Feel free to not believe it.
I don't believe it. Feel free to provide details on how you were looking through the logs.
It did not fail to a recovery shell after being left overnight.
There is a way to boot into an emergency shell when this happens.
Your attitude is part of why systemd is so reviled.
I could say the same about yours. I mean, the parsing of fstab by the local-fs.target is VERY well documented. And so are the early boot debugging features. Why would you upgrade a system before at least taking a cursory look at the documentation? I successfully migrated a moderately complex system dependent on an external ZFS disk array, several NFS expo
Re: (Score:3)
There is a way to boot into an emergency shell when this happens.
Yet you don't seem to be willing to share that information. That's probably the attitude he's talking about, if I had to guess. I remember a time when a member of the Linux community would have responded with something helpful along the lines of:
You can add break to your kernel line to get a shell on your initram, you can even decide to get it before or after mounting...
Possibly even elaborating on just how to go about doing that but, at the very least, pointing the user in the right direction.
There was a time when ignorance was met with information, rather than ridicule. If you want people to embrace your beloved systemd, perhap
Re: (Score:2)
systemd fails silently if something is wrong in /etc/fstab. It just doesn't finish booting.
So, it behaves correctly according to the fstab(5)man page from the release before they switched to systemd? [debian.org]
Which is moderately annoying if you have access to the system console and you can guess that an unchanged /etc/fstab from before systemd that worked for a while with systemd is now suddenly toxic
As far as I know, this (correct according to documentation/intent) behaviour has been the same since any stable distribution shipped systemd as the default init.
If you do not have easy access to the system console or you are not blessed with divine inspiration, that is quite a bit more than annoying.
And should teach you to always 'mount -a' when you have made a change to your /etc/fstab.
Thanks to the binary log files you cannot even boot something random and read the logs, but at least you aren't missing anything, because nothing pertinent to the error is logged anyway.
In most of the cases I have seen this, it is when someone wrote a service unit file without even bothering to read systemd.service(5) and didn't put a Ty
Re: (Score:2)
Here we go again with all the insinuations and accusations. The /etc/fstab was correct with the old init. It was incorrect with systemd. Therefore no amount of mount -a would have helped.
"So, you were relying on bugs to boot your systems?"
Have you stopped beating your mother when she tells you to come out of your basement?
Re: I have no problem with systemd (Score:2)
Well, I have never seen this myself, or seen valid bug report about. Yes, if your fstab entry was correct and that caused systemd to not boot, you should file a bug report.
However, I have also seen soooo many invalid complaints about systemd where the systemd beaviour was correct but other implementations were wrong (conflicted with the sgstem documentation).
systemd's approach is to boot correctly, or if a required resource is not available to not boot into a partial state.
I have seen enough failure modes
Re: (Score:2)
If you think your feedback was constructive, I suggest you re-read it.
Re: (Score:2)
Did you upgrade Ubuntu and find out that /var/spool/mail is a symlink to /var/mail and you can't mount to a symlink in fstab?
Re: (Score:3)
Here's a few. It has no concept of imperative (Just do what I said), or best effort (everything must be perfect or it won't even try to continue). It hard codes things that should be configurable or external. For example, it has it's own idea of what makes a device ready for a filesystem to mount and it can't be told otherwise.
All of that is why soft RAID must be assembled in the initrd before systemd has a chance to screw it up. Otherwise, there is simply no way to tell systemd to complete the boot process
Re: (Score:2)
And once again a systemd opponent proves to be an idiot or a liar. Handling a degraded array and making it bootable has always been the job of the initramfs. See this Debian bug dealing with this issue [debian.org], for example, where the maintainer himself admits so.
Re: (Score:2)
Funny thing is, you were so desperate to deny the systemd bug that you pulled up the wrong issue entirely.
The initramfs HAS to handle the RAID for the root filesystem, naturally. Non-root RAID is supposed to be handled after transferring control to the actual init.
Same for non-root btrfs.
If there's an idiot or liar in this thread, it isn't me.
Re: (Score:2)
The initramfs has to handle all degraded arrays, otherwise they will be marked inactive, and not mounted. The right place to fix issues with degraded arrays being marked inactive (and thus umountable) is in the initramfs.
Which the Debian maintainer admitted; it was his change in the initramfs scripts that marked the arrays inactive and made them fail to mount.
Again, you are so bound up in your systemd hate that you fail to read.
Re: (Score:3)
I read just fine. The workaround is in initramfs, but that's just because systemd is incapable of handling it. Prior to that, the old sysV init handled it just fine.
Not that when I first tested systemd, it was on a working test dummy with a btrfs. It worked just fine before, including when I degraded btrfs. Then I 'upgraded' to systemd and it wouldn't boot. It wouldn't just fail to mount the btrfs (non-root), it just dropped to an emergency shell with no remote services running.
Note that at one time, system
Re: (Score:2)
While I do have concerns about systemd, most dependency schemes have a way for a component to declare itself a prereq to an unwitting third party component. It's a valuable cabability in general when trying to enhance behaviors of existing systems without modifying components needlessly.
Re: (Score:2)
I would be interested in knowing what one or more of those are.
Re: (Score:2)
For example, Debian's SysV init scripts:
https://wiki.debian.org/LSBIni... [debian.org]
X-Start-Before: boot_facility_1 [boot_facility_2...]
X-Stop-After: boot_facility_1 [boot_facility_2...]
provide reverse dependencies, that appear as if the listed facilities had should-start and should-stop on the package with these headers.
Re: (Score:2)
I'll grant the similarity, but at least the Debian scripts don't create hard dependencies. The boot won't stop as a result. That system might refuse to implement a new configuration if it detects that the advisory dependency cannot be met, but end of the day, the links in /etc/rcN.d will be control the boot and if one fails, it will move on.
The X- prefix provides some indication of knowledge that it's a dirty hack, but it is somewhat less problematic given the small number of init.d scripts all kept in one
Re: (Score:2)
There's many hours of reading the Debian CTTE and bug archives about the system init discussion if you have a bit of time and are that interested.
A short version, which is mostly still applicable and accurate for the large part from the past 2 years, is the Debian debate wiki pages with the arguments for and against various init systems to switch to. It's notable that *no-one* wanted to use sysvinit moving into Jessie, and the votes for upstart were heavily partisan being current and ex-canonical employee
Re: (Score:1)
In other words, just like all other anti-systemd idiots you have nothing concrete and you are just parotting your echo chamber.
Re: (Score:3)
Systemd has three fundamental issues:
-It's not systemd versus sysv, it's systemd vs. sysv/syslog/cron/at/user session management. That's a whole lot of potential controversy to take on for a project that you either adopt as a distro or you don't, and giving the users choice in a matter like this is an impractical thing for most distributions. It also creates challenges for security, because something you do to provide user-level access to some capabilities becomes a potential path for a vulnerability (of
Re: (Score:2)
The simple fact of the matter is both *for* and *against* are necessarily going to be a matter of opinion. Poeple *like* or *don't like* certain things. There are sometimes objective pieces of data (time for computer to do X, amount of memory consumed to do y), but other than boot performance, there isn't an objective good or bad to argue here, it's a matter of consensus and pissing off the fewest people and accommodating the tastes of the most people possible. The logistics of managing processes and sta
Re: (Score:2)
But 'who to piss off least' is a factual assertion masquerading as an opinion. There is simply no proof that systemd pisses off more people than SysV. Given that we don't see a massive rise in BSD usage, that Red Hat senior officers say they see no impact on RHEL7 deployments and that Devuan is not advancing in any meaningful way, there is in fact a strong possibility that systemd pisses of a majority of loud whiners, but that is not the same.
Re: (Score:2)
The goalpost keeps moving here...
One, it would be nice to have more than the opinion of officials who stand to look the worst if there were a problem. Even if there were a problem, people in that position stand to benefit by making that problem invisible.
Two, as time passes, it becomes increasingly difficult to justify staying with RHEL6 era software all *just* to avoid systemd. That doesn't mean customers *happily* go to systemd, but that they have to.
Three, even should systemd be a make or break vendors
Re: (Score:2)
It is really strange how for some reason disregarding well-founded statements and just saying that there is a hidden reason why they don't fit seem to be common among systemd opponents and crazy right-wingers.
Given the amount of invective coming out of the anti-systemd camp, complaining about mild epithets like 'whiners' also sounds a lot like the standard alt-right tactic "Yes, but you're the real racists|sexists|whatever".
In other words, snowflake, shut up and come back when you have actual hard facts to
Re: (Score:2)
Re: (Score:2)
Standard facilities to 'daemonize' software without the software having to do the right double fork and exit dance. It would have been one thing if libc had provided a function, but it hasn't so every daemon has had to do that weird dance itself, and many of them get it wrong, particularly home-grown software
This should have been added long ago.
Re: (Score:2)
Systemd has three fundamental issues:
-Piss poor community engagement. Their reaction to any request or security report is to first say the requester or reporter is an idiot. For example: https://github.com/systemd/sys... [github.com] where he claims that it's perfectly valid for a confused systemd to just run user as root instead of error out.
If I read *just* that bug report, the part of the community engagement that is not working well is from the community of incensed (seemingly Debian) users who insult people in bug reports.
Pottering explained the general approach they took which was:
In systemd we generally follow the rule that when we encounter a unit setting that does not validate syntax-wise we'll log about it and ignore it, for compat reasons. We do the same for User= here as for all other options.
However, he was open to taking a different approach for most security-related settings, and as such the issue is fixed [github.com]
Re: (Score:1)
Lots of people, myself included, have had issues trying to get things which are trivial in pre-systemd or on other OSes to work properly and consistently on systemd. There are many, many, many examples of issues
Many, many examples which are never described in detail, or when enough detail is given to reproduce them turn out to not exist or have already been fixed.