Here's a list of actual problems that should have been solved instead of introducing the nightmare of systemd upon the Linux (Debian specifically) world:
- Forceful, unconditional kernel operations. When I say "unmount this filesystem," I'm not asking a question. When I say "terminate this process," I expect the process to be removed from memory and the runqueue, regardless of consequences.
- When I say "reboot" I mean "reboot." Hangs are not okay, ever.
- Actual, real soft NFS failures. Do not hang duri
Thank you! Finally someone actually outlines specific issues instead of just complaining.
But I have to say, I'm using Jessie and I have not experienced any of the problems you have cited... When I kill a process, it gets killed. When I reboot or shutdown, it reboots or shuts down. When I mount/unmount something, it gets mounted/unmounted. The other stuff I can't speak to.
Just my $0.02 as well. Not a 25-year Linux admin, I've run my own server for ~5 years, so I didn't have that much experience before the ch
Thank you! Finally someone actually outlines specific issues instead of just complaining.
Well most of the issues he complained about weren't actually related to Systemd.
But I have to say, I'm using Jessie and I have not experienced any of the problems you have cited... When I kill a process, it gets killed. When I reboot or shutdown, it reboots or shuts down. When I mount/unmount something, it gets mounted/unmounted. The other stuff I can't speak to.
Can I ask, why don't you and other admins/devs like you start to contribute to systemd? Obviously there are huge philosophical differences between the systemd devs and parts of the Linux community, but if people like you never get involved in systemd development because of those issues, can you really expect them to change?
For one thing contributing to a project like that is a massive commitment, but more to the point the poster is fundament
For one thing contributing to a project like that is a massive commitment
Sure, that's totally understandable. But there are people who have enough time to fork entire distros, like Devaun... So while you could make that argument on an individual basis, you can't honestly say that "only the people who like systemd's philosophy have time to contribute to systemd".
but more to the point the poster is fundamentally opposed to the underlying philosophy of Systemd.
That's fair too, but that's life. Sometimes you have to deal with things you are fundamentally opposed to. As long as that's the position someone is going to take, they shouldn't really expect things to change. Again, sel
>To me, the fact that the major distros have adopted systemd is strong evidence that it is probably better
"Better" is a subjective term. Software (and any product really) does not have some absolute measurable utility. It's utility is specific to an audience. The fact that the major distros switch is probably strong evidence that systemd is "better" for distro developers. But the utility it brings them may not apply to all users, or even any particular user. A big part of the reason people were upset was exactly that - the key reasons distros had for switching was benefits to people building distros which subsequent users would never experience. These should not have trumped the user experience.
All that would still have been fine - we could easily have ended up with a world that had systemd for those who wanted it, and didn't have it for those who didn't want it. Linux systems are supposed to be flexible enough that you can set them up to whatever purpose you desire.
So where the real anger came in was the systemd's obsessive feature-creep made it go into a lots and lots of areas that have nothing to do with it's supposed purpose (boot process management), in that area it's biggest advantages are only useful to people building distributions (who have to maintain thousands of packages and ensure they reliable handle their bootup requirements regardless of what combination of them is actually installed- systemd genuinely did make that easier on them - but no user or admin ever experiences that scenario). But that feature creep itself wasn't even the issue, the issue was that - as it entered into all these unrelated areas (login was the first of many) - it broke compatibility with the existing software to do those jobs. This meant that, if you built a system to support systemd, that same system could not use any alternatives. So now, you had to create hard dependencies on systemd to support it at all - for distros to gain those benefits, they had to remove the capacity for anybody to forgo them, or alternatively provide two versions of every package - even ones that never touch the boot process and get no benefit from systemd's changes there.
And the trouble is - in none of those other areas has it offered anything of significant value to anybody. Logind doesn't actually do anything that good old login didn't do anyway, but it's incompatible so a distro that compiles it's packages around logind can't work with anything else. Replacing the process handler... and not only did it not add any new functionality it broke some existing functionality (granted, in rarer edge cases -but there was no reason for any breakage at all because these were long-solved problems).
Many years ago, I worked as a unix admin for a company that developed for lots of different target unix systems. As such I had to maintain test environments running all the targets. I had several linux systems running about 5 different distros, I had solaris boxes with every version from 8 onwards (yep, actual Sparcs), I had IBM's running AIX, I even had two original (by then 30 year old) DEC Alphas running Tru64... and I had several HPUX boxes.
At the time, while adminning all these disparate unix environments on a day-to-day basis and learning all their various issues and problems - I came to announce routinely that Solaris pre-Version-10 had the worst init system in the word to admin, but the worst Unix in the world was definitely HPUX because HPUX was the only Unix where I could not, with absolute certainty, know that if I kill -9 a process - that process would definitely be gone. WIped out of memory and the process table with absolutely no regard for anything else - it's a nuclear option, and it's supposed to work that way - because sometimes that what you need to keep things running. SystemD brought to Linux an init system that replicated everything I used to hate about the Solaris 8/9 init system - but what's worse than that, it brought the one breakage that got me to declare HPUX the absolute worst unix system in history: it made kill -9 less than one hundred percent absolutely, infallibly reliable (nothing less than perfect is good enough - because perfect HAS been achieved there, in fact outside of HPUX and SystemD - no other Unix system has ever had anything LESS than absolute perfection on this one).
I absolutely despise it. And yet I'm running systemd systems - both professionally and at home, because I'm a grown man now, I have other responsibilities, I don't want to spend all my time working and even my home playing-with-the-computer time is limited so I want to focus on interesting stuff - there is simply not enough time for the amount of effort required to use a non-niche distro. I don't have the time to custom build the many software the small distros simply don't have packages for and deal with the integration issues of not using proper distro-built-and-tested packages. I live with systemd. I tolerate it. It's not an unsurvivable trainsmash -but I still hate it. It still makes my life harder than it used to be. It makes my job more difficult and time-consuming. it makes my personal ventures more complicated and annoying. It adds no value whatsoever to my life (seriously - who reboots a Linux system often enough to CARE about boot-time - you only DO that if you have a security patch for the kernel or glibc - anything else is a soft-restart) it just adds hassle and extra effort... the best thing I can say about it is that it adds LESS extra effort than avoiding it does, but that's not because it's superior to me in any way - it's because it's taken over every distro with a decent sized package repository that isn't "built-by-hand" like arch or gentoo.
Tough question. Depends what that functionality is. Compatibility is valuable but sometimes it must be sacrificed to deal with technical debt or make genuine progress. Even Microsoft had a huge compatibility break with Vista which was needed at the time (even if Vista itself was atrocious). It would depend what those features were, what benefits it gave me. It would be a trade off and should be evaluated as such. A major sacrifice requires an even more major advantage to be worthwhile. I've yet to see any such advantage from anything systemd has added. I'm not saying advantages don't exist, I'm saying whatever they may be they do not benefit me, personally, in any measurable way. The disadvantages however do, and compatibility is the least of them. Config outside/etc is a major deal - it utterly breaks with a standard around which disk space allocation is done professionally./use ought to not even need backups because everything there is supposed to be installed and never hand edited. It means modifying backup strategy which is a big, very risky, cange. Logs aren't where I expect them. Boot errors flash on screen and disappear before you can read them so you have to remember to go look in the binary log to figure out if it was something serious.
I was never a fan of system V. It was a complicated, slow, mess if code duplication. It needed a replacement. I was championing Richard Gooch's make-init circa 2001 (and his devfs, the forerunner to udev, was in my kernels - I built a powerful hardware autoconfig system on it in 2005 when I built the first installable live CD distribution, the way they all work now: I invented it [I later discovered that pclinuxos had invented the same thing independently at the same time but Ubuntu for example still came on two disks, a live CD and separate text based installation disk and more than once I had machines where the live cd ran great but the installed system broke due to disparate hardware setup systems]). Later I praised upstart - it was a fantastic unit system that solved the issues with system V, retained compatibility but was easy to admin, standards and philosophy compliant and fast. It was even parallel.
That is the system that should have won the unit wars. I'm not a huge fan of Ubuntu's eclectic side, unity has always been a fugly unusable mess of a desktop to me - but upstart was great, that and PPAs are Ubuntu two most amazing accomplishments. Sadly one got lost instead of being the world changing tech it deserved to be and it lost to a wholly inferior technology for no sane reason.
systemd has no site dependent configuration outside of/etc.
The files installed in/usr/lib/systemd by packages are not supposed to be modified by the sysadmin -- that's what/etc/systemd is for, putting things that override the distro defaults.
And/etc/default is good enough for every other package but not for systemd.
Eh? There are plenty of packages that pull default configs out of some location in/usr, with/etc/ being an override./etc has long (apart from systemd even) been considered the user-editable configuration, and/usr/share the non-user-editable configuration area (among other things).
No. I didn't change anything. No configs, editable or otherwise, should exist outside/etc. Configs installed by packages which should be overridden rather than edited (what you described the ones under/usr as being) belong under/etc/default. They no more belong under/usr than the similar files installed by a thousand other packages do.
Mostly these are packages that predate the establishment of the/etc/default standard, or packages that are small third-party things that aren't shipped by distros, or are so badly coded that you can't actually change installation paths during the build process. Because even if packages typically don't do it, distros would usually change that- even when it means applying patches to the code while building packages (official debian packages almost always have patches included to modify the package to debian s
Mostly these are packages that predate the establishment of the/etc/default standard,
Given all the packages I've had to mess around with over the years and seeing how they like to do things, I think/etc/default was a very short-lived standard that most just didn't pick up. I'm looking backwards at some of the distros I've used over the years, and I just don't see that it got a lot of traction.
Even if you are right it doesn't follow that text config files belong in/usr/lib does it? That's where libraries go. At the very least if it had to be under/usr it ought to have been in/usr/share/SystemD
Clearly you have spent time thinking about systemd, and so some questions:
1) Any chance systemd will improve? I think about how gnome3 seems to be slowly gaining more acceptance, perhaps this will be similar?
2) One of the challenges, even for a general-purpose computer distro, is to run on a wide variety of hardware with different needs. Example: Portable computer needs to be able to sleep, use graphics switching (start quicker??) while on a server these might be less important. It seems that systemd is
I think about how gnome3 seems to be slowly gaining more acceptance
Gnome 3 has always had a superior workflow, aside from its alt-tab behavior (which can take you to a different desktop, then back to a different window from the same application, then tab you between those two--no rapid swapping between the last 2 windows you touched). With the Activities view, it became possible to just press Meta and swap up/down through desktops, or press Meta and type an application name or keyword ("DVD burner" etc.), and press enter to take the first result. You can tap the corner
1) It's possible - a big part of Gnome3's growth however was weakening the "we know what's good for you" arrogance of the developers (partly due to the huge user-losses they suffered on release) and actually listening to their users. Thus far, systemd seems quite uninterested in that.
2) This leads into the other problem with systemd - which may make the odds of improvement lower. It is more on the fundamental design level. There is a reason the unix philosophy is what it is. "Small programs that do one thi
But downstream isn't one place, there are multiple stops along the way. The assessment of "Better" was made on stop down (the distro packagers) but nobody every really considered the question of whether it would be "better" (by your own measure) for the those even further downstream - the users, the sysadmins, the devops engineers.
I think, objectively, that it wasn't - at least for a large subset of those further downstream (notably experts and sysadmins).
I find that logs still get pumped out to/var/log on Ubuntu, yet journalctl captures information that never went to those logs, so it has been an absolute boon in troubleshooting things I'd never understood before. There was a time when I'd occasionally try to run the application myself, or modify the init script; frequently I found this nigh-on-impossible with the ultra-complex, 700-line bash scripts Redhat and Debian like to shove into init.d.
I've never found journalctl to contain anything that wasn't in/var/log - but if you only checked one file in a folder full of logs you'd likely have missed things.
And if you recall, I said in my original post that System-V had issues - you mention one of the worst, I just don't think SystemD was the best answer available - it wasn't even in the top-5 best alternatives that were available at the time. Personally I think upstart was but there were several other very good ones, and none of them should have be
Lots of daemons don't capture stdout. On some systems, you can see logs spew to the console, making tty1 unusable.
Upstart was another SystemV-like, but better. I generally think of Upstart and whatever Gentoo uses as "SystemV" because they attempt to be that with new capabilities.
Just imagine if they all integrated Supervisord instead.
Upstart was in no way system V like, it had a backwards compatibility feature that led system V scripts work but that was only for non-updated third party software. Upstart's own system used config files, not scripts. Its wrapper utility commands were compatible with older ones created for system V but were drop in replacement code. Upstart was parallel capable, sensibly structured (dependency model) and fast. It was the right way to improve init. And it was just init. Upstart didn't mess with anything else
Problems with Linux that should have been solved (Score:5, Insightful)
Here's a list of actual problems that should have been solved instead of introducing the nightmare of systemd upon the Linux (Debian specifically) world:
- Forceful, unconditional kernel operations. When I say "unmount this filesystem," I'm not asking a question. When I say "terminate this process," I expect the process to be removed from memory and the runqueue, regardless of consequences.
- When I say "reboot" I mean "reboot." Hangs are not okay, ever.
- Actual, real soft NFS failures. Do not hang duri
Re: (Score:1)
Thank you! Finally someone actually outlines specific issues instead of just complaining.
But I have to say, I'm using Jessie and I have not experienced any of the problems you have cited... When I kill a process, it gets killed. When I reboot or shutdown, it reboots or shuts down. When I mount/unmount something, it gets mounted/unmounted. The other stuff I can't speak to.
Just my $0.02 as well. Not a 25-year Linux admin, I've run my own server for ~5 years, so I didn't have that much experience before the ch
Re: (Score:2)
Thank you! Finally someone actually outlines specific issues instead of just complaining.
Well most of the issues he complained about weren't actually related to Systemd.
But I have to say, I'm using Jessie and I have not experienced any of the problems you have cited... When I kill a process, it gets killed. When I reboot or shutdown, it reboots or shuts down. When I mount/unmount something, it gets mounted/unmounted. The other stuff I can't speak to.
Usually no, but it happens [noah.org]
Can I ask, why don't you and other admins/devs like you start to contribute to systemd? Obviously there are huge philosophical differences between the systemd devs and parts of the Linux community, but if people like you never get involved in systemd development because of those issues, can you really expect them to change?
For one thing contributing to a project like that is a massive commitment, but more to the point the poster is fundament
Re: (Score:2)
For one thing contributing to a project like that is a massive commitment
Sure, that's totally understandable. But there are people who have enough time to fork entire distros, like Devaun... So while you could make that argument on an individual basis, you can't honestly say that "only the people who like systemd's philosophy have time to contribute to systemd".
but more to the point the poster is fundamentally opposed to the underlying philosophy of Systemd.
That's fair too, but that's life. Sometimes you have to deal with things you are fundamentally opposed to. As long as that's the position someone is going to take, they shouldn't really expect things to change. Again, sel
Re:Problems with Linux that should have been solve (Score:5, Insightful)
>To me, the fact that the major distros have adopted systemd is strong evidence that it is probably better
"Better" is a subjective term. Software (and any product really) does not have some absolute measurable utility. It's utility is specific to an audience. The fact that the major distros switch is probably strong evidence that systemd is "better" for distro developers. But the utility it brings them may not apply to all users, or even any particular user.
A big part of the reason people were upset was exactly that - the key reasons distros had for switching was benefits to people building distros which subsequent users would never experience. These should not have trumped the user experience.
All that would still have been fine - we could easily have ended up with a world that had systemd for those who wanted it, and didn't have it for those who didn't want it. Linux systems are supposed to be flexible enough that you can set them up to whatever purpose you desire.
So where the real anger came in was the systemd's obsessive feature-creep made it go into a lots and lots of areas that have nothing to do with it's supposed purpose (boot process management), in that area it's biggest advantages are only useful to people building distributions (who have to maintain thousands of packages and ensure they reliable handle their bootup requirements regardless of what combination of them is actually installed- systemd genuinely did make that easier on them - but no user or admin ever experiences that scenario). But that feature creep itself wasn't even the issue, the issue was that - as it entered into all these unrelated areas (login was the first of many) - it broke compatibility with the existing software to do those jobs. This meant that, if you built a system to support systemd, that same system could not use any alternatives. So now, you had to create hard dependencies on systemd to support it at all - for distros to gain those benefits, they had to remove the capacity for anybody to forgo them, or alternatively provide two versions of every package - even ones that never touch the boot process and get no benefit from systemd's changes there.
And the trouble is - in none of those other areas has it offered anything of significant value to anybody. Logind doesn't actually do anything that good old login didn't do anyway, but it's incompatible so a distro that compiles it's packages around logind can't work with anything else. Replacing the process handler... and not only did it not add any new functionality it broke some existing functionality (granted, in rarer edge cases -but there was no reason for any breakage at all because these were long-solved problems).
Many years ago, I worked as a unix admin for a company that developed for lots of different target unix systems. As such I had to maintain test environments running all the targets. I had several linux systems running about 5 different distros, I had solaris boxes with every version from 8 onwards (yep, actual Sparcs), I had IBM's running AIX, I even had two original (by then 30 year old) DEC Alphas running Tru64... and I had several HPUX boxes.
At the time, while adminning all these disparate unix environments on a day-to-day basis and learning all their various issues and problems - I came to announce routinely that Solaris pre-Version-10 had the worst init system in the word to admin, but the worst Unix in the world was definitely HPUX because HPUX was the only Unix where I could not, with absolute certainty, know that if I kill -9 a process - that process would definitely be gone. WIped out of memory and the process table with absolutely no regard for anything else - it's a nuclear option, and it's supposed to work that way - because sometimes that what you need to keep things running.
SystemD brought to Linux an init system that replicated everything I used to hate about the Solaris 8/9 init system - but what's worse than that, it brought the one breakage that got me to declare HPUX the absolute worst unix system in history: it made kill -9 less than one hundred percent absolutely, infallibly reliable (nothing less than perfect is good enough - because perfect HAS been achieved there, in fact outside of HPUX and SystemD - no other Unix system has ever had anything LESS than absolute perfection on this one).
I absolutely despise it. And yet I'm running systemd systems - both professionally and at home, because I'm a grown man now, I have other responsibilities, I don't want to spend all my time working and even my home playing-with-the-computer time is limited so I want to focus on interesting stuff - there is simply not enough time for the amount of effort required to use a non-niche distro. I don't have the time to custom build the many software the small distros simply don't have packages for and deal with the integration issues of not using proper distro-built-and-tested packages.
I live with systemd. I tolerate it. It's not an unsurvivable trainsmash -but I still hate it. It still makes my life harder than it used to be.
It makes my job more difficult and time-consuming. it makes my personal ventures more complicated and annoying. It adds no value whatsoever to my life (seriously - who reboots a Linux system often enough to CARE about boot-time - you only DO that if you have a security patch for the kernel or glibc - anything else is a soft-restart) it just adds hassle and extra effort... the best thing I can say about it is that it adds LESS extra effort than avoiding it does, but that's not because it's superior to me in any way - it's because it's taken over every distro with a decent sized package repository that isn't "built-by-hand" like arch or gentoo.
Re: (Score:2)
So would you be okay with it if it still broke compatibility but that was necessary to add some really important/useful features?
Re: Problems with Linux that should have been solv (Score:4, Insightful)
Tough question. Depends what that functionality is. Compatibility is valuable but sometimes it must be sacrificed to deal with technical debt or make genuine progress. Even Microsoft had a huge compatibility break with Vista which was needed at the time (even if Vista itself was atrocious). /etc is a major deal - it utterly breaks with a standard around which disk space allocation is done professionally. /use ought to not even need backups because everything there is supposed to be installed and never hand edited. It means modifying backup strategy which is a big, very risky, cange. Logs aren't where I expect them. Boot errors flash on screen and disappear before you can read them so you have to remember to go look in the binary log to figure out if it was something serious.
It would depend what those features were, what benefits it gave me. It would be a trade off and should be evaluated as such. A major sacrifice requires an even more major advantage to be worthwhile. I've yet to see any such advantage from anything systemd has added. I'm not saying advantages don't exist, I'm saying whatever they may be they do not benefit me, personally, in any measurable way. The disadvantages however do, and compatibility is the least of them.
Config outside
I was never a fan of system V. It was a complicated, slow, mess if code duplication. It needed a replacement. I was championing Richard Gooch's make-init circa 2001 (and his devfs, the forerunner to udev, was in my kernels - I built a powerful hardware autoconfig system on it in 2005 when I built the first installable live CD distribution, the way they all work now: I invented it [I later discovered that pclinuxos had invented the same thing independently at the same time but Ubuntu for example still came on two disks, a live CD and separate text based installation disk and more than once I had machines where the live cd ran great but the installed system broke due to disparate hardware setup systems]). Later I praised upstart - it was a fantastic unit system that solved the issues with system V, retained compatibility but was easy to admin, standards and philosophy compliant and fast. It was even parallel.
That is the system that should have won the unit wars. I'm not a huge fan of Ubuntu's eclectic side, unity has always been a fugly unusable mess of a desktop to me - but upstart was great, that and PPAs are Ubuntu two most amazing accomplishments. Sadly one got lost instead of being the world changing tech it deserved to be and it lost to a wholly inferior technology for no sane reason.
It's the Amiga of the Linux world.
Re: Problems with Linux that should have been sol (Score:2)
I should not comment from my phone. Man autocorrect rapes my text...
Re: (Score:1)
Config outside /etc is a major deal
It's also a major misunderstanding of systemd.
systemd has no site dependent configuration outside of /etc.
The files installed in /usr/lib/systemd by packages are not supposed to be modified by the sysadmin -- that's what /etc/systemd is for, putting things that override the distro defaults.
Re: (Score:2)
Right... /etc/default is good enough for every other package but not for systemd.
And
You know, if you don't follow the standards and "misconceptions" arise - it's the fault of bad development.
Re: (Score:1)
Great groaning sound as the goalposts are shifted.
You're changing "Config outside /etc is a major deal" to "Config outside /etc/default is a major deal" now?
Are you unable to admit that one of your complaints about systemd, which you described as "a major deal" was simply wrong?
Re: (Score:2)
And /etc/default is good enough for every other package but not for systemd.
Eh? There are plenty of packages that pull default configs out of some location in /usr, with /etc/ being an override. /etc has long (apart from systemd even) been considered the user-editable configuration, and /usr/share the non-user-editable configuration area (among other things).
Re: Problems with Linux that should have been sol (Score:2)
No. I didn't change anything. No configs, editable or otherwise, should exist outside /etc. Configs installed by packages which should be overridden rather than edited (what you described the ones under /usr as being) belong under /etc/default. They no more belong under /usr than the similar files installed by a thousand other packages do.
Re: (Score:1)
No. I didn't change anything.
Oh yes you did. You said:
/use ought to not even need backups because everything there is supposed to be installed and never hand edited
I pointed out that that was exactly the case with systemd and now you've changed the claim to:
No configs, editable or otherwise, should exist outside /etc.
with exactly zero justification.
Re: (Score:2)
Re: (Score:2)
Mostly these are packages that predate the establishment of the /etc/default standard, or packages that are small third-party things that aren't shipped by distros, or are so badly coded that you can't actually change installation paths during the build process.
Because even if packages typically don't do it, distros would usually change that- even when it means applying patches to the code while building packages (official debian packages almost always have patches included to modify the package to debian s
Re: (Score:2)
Mostly these are packages that predate the establishment of the /etc/default standard,
Given all the packages I've had to mess around with over the years and seeing how they like to do things, I think /etc/default was a very short-lived standard that most just didn't pick up. I'm looking backwards at some of the distros I've used over the years, and I just don't see that it got a lot of traction.
Re: Problems with Linux that should have been sol (Score:2)
Even if you are right it doesn't follow that text config files belong in /usr/lib does it? That's where libraries go. At the very least if it had to be under /usr it ought to have been in /usr/share/SystemD
Re: (Score:2)
1) Any chance systemd will improve? I think about how gnome3 seems to be slowly gaining more acceptance, perhaps this will be similar?
2) One of the challenges, even for a general-purpose computer distro, is to run on a wide variety of hardware with different needs. Example: Portable computer needs to be able to sleep, use graphics switching (start quicker??) while on a server these might be less important. It seems that systemd is
Re: (Score:2)
I think about how gnome3 seems to be slowly gaining more acceptance
Gnome 3 has always had a superior workflow, aside from its alt-tab behavior (which can take you to a different desktop, then back to a different window from the same application, then tab you between those two--no rapid swapping between the last 2 windows you touched). With the Activities view, it became possible to just press Meta and swap up/down through desktops, or press Meta and type an application name or keyword ("DVD burner" etc.), and press enter to take the first result. You can tap the corner
Re: (Score:2)
1) It's possible - a big part of Gnome3's growth however was weakening the "we know what's good for you" arrogance of the developers (partly due to the huge user-losses they suffered on release) and actually listening to their users. Thus far, systemd seems quite uninterested in that.
2) This leads into the other problem with systemd - which may make the odds of improvement lower. It is more on the fundamental design level. There is a reason the unix philosophy is what it is. "Small programs that do one thi
Re: (Score:2)
Generally, the improvement is in if it lowers labor required downstream. That's the absolute measure of "better".
Re: (Score:2)
But downstream isn't one place, there are multiple stops along the way. The assessment of "Better" was made on stop down (the distro packagers) but nobody every really considered the question of whether it would be "better" (by your own measure) for the those even further downstream - the users, the sysadmins, the devops engineers.
I think, objectively, that it wasn't - at least for a large subset of those further downstream (notably experts and sysadmins).
Re: (Score:2)
I find that logs still get pumped out to /var/log on Ubuntu, yet journalctl captures information that never went to those logs, so it has been an absolute boon in troubleshooting things I'd never understood before. There was a time when I'd occasionally try to run the application myself, or modify the init script; frequently I found this nigh-on-impossible with the ultra-complex, 700-line bash scripts Redhat and Debian like to shove into init.d.
Docker has also been a godsend.
The one time shit pissed me
Re: (Score:2)
I've never found journalctl to contain anything that wasn't in /var/log - but if you only checked one file in a folder full of logs you'd likely have missed things.
And if you recall, I said in my original post that System-V had issues - you mention one of the worst, I just don't think SystemD was the best answer available - it wasn't even in the top-5 best alternatives that were available at the time. Personally I think upstart was but there were several other very good ones, and none of them should have be
Re: (Score:2)
Lots of daemons don't capture stdout. On some systems, you can see logs spew to the console, making tty1 unusable.
Upstart was another SystemV-like, but better. I generally think of Upstart and whatever Gentoo uses as "SystemV" because they attempt to be that with new capabilities.
Just imagine if they all integrated Supervisord instead.
Re: Problems with Linux that should have been solv (Score:2)
Upstart was in no way system V like, it had a backwards compatibility feature that led system V scripts work but that was only for non-updated third party software. Upstart's own system used config files, not scripts. Its wrapper utility commands were compatible with older ones created for system V but were drop in replacement code. Upstart was parallel capable, sensibly structured (dependency model) and fast. It was the right way to improve init. And it was just init. Upstart didn't mess with anything else
Re: (Score:2)
Today I learned that "conversations of slashdot" are consider "coding" by some people...