Just another reminder to use strong passwords, password managers, and change them often. It's a pain, but it's the reality of the digital world.
Sure, but mobile apps make this sort of thing a pain.
I have apps that want you to enter your password frequently. That encourages trivial passwords unless you have some way to have a password vault app to fill them in for you, and that doesn't always work.
Then you have stuff like Android only supporting full-device encryption if your encryption key is the same as your screen lock PIN. Screen-lock PINs normally only have to defeat online attacks, and they can throttle attempts, lock out, etc to defeat brute force attacks. The whole point of disk encryption is to defeat offline attacks, so you need to use strong keys to make it work. You can potentially make them readable if you use multiple rounds to make cracking harder, but you can't make it a 4-digit number unless you design it such that the correct key takes a day and drains your battery to unlock the thing on the first attempt.
In the mobile world we really need to get away from hand-entered passwords. They're an acceptable one-time kludge during app setup, but after then you really need to move to some kind of token stored in a vault, and then use sandboxing at the OS level to keep the app safe from tampering.
Do you really want to stick a whole PC in a lab, expose it to chemicals, and put its CPU through repeated heat/cool cycles just to save on a thermocycler?
They mention costs like $19k to obtain one otherwise. I'm sure they sell for that much just as I'm sure you can go spend $2000 on a linux license, but all a thermocycler needs to do is heat samples and cool them. Clearly the CPU isn't going to be a high-performance cycler - you could probably build a little cycler that just uses radiative cooling and some resistive heating for $50. I see peltier heat sinks selling for $40 these days, so I'm sure for $100 you could build a thermocycler on the cheap.
An ideal thermocycler just needs to heat samples to about 95C for a few seconds, cool them down to about room temperature for a few seconds, and then hold them at something around body temperature for a minute or two, The time spent ramping temperature up/down is basically dead time, and you have to repeat this 20-30 times, so if your cycler can change temperature in seconds instead of minutes you can save a LOT of time per test. Peltier effect tends to be the way things are done, or at least it was back when I was using these in the labs.
It looks like openpcr.org has a unit for $600. I'm sure it could be improved on, but I imagine that as you get cheaper, you lose precision, and that does matter. I can't imagine that a CPU can maintain a temperature +/- 0.5C without quite a bit of effort.
I'll agree that I have seen issues where the default dependencies don't always catch everything. I run DNS and NFS on the same box, and I have DNS names in my exports, and often nfsd tries to do its job before DNS is running, and by default DNS isn't required for network-online, and even network-online is fairly new so many things don't use it.
It is still pretty rough around the edges all around.
It isn't that hard to add a dependency to a service though - you can do this with a drop-in.
Oh, I understand what you're saying. There are plenty of trolls to go around, and I don't think that some of the key systemd devs help things. There are also plenty of level-headed folks on either side who see the pros and cons and make reasonable contributions to the debate. I just try to be the latter...:)
Oh, I doubt openrc will go away completely, as long as somebody cares to maintain it. Gentoo never really turns away oddball configurations entirely. What you might find is more and more packages that lack an openrc script - even before systemd came along you could find the oddball package that lacked a script, and if many devs switch over you might find a lower level of support for openrc.
But, nobody is going to tell you, "you're not allowed to run openrc." Despite all the noise people make publicly, the reality is that within Gentoo the maintainers of systemd, udev, eudev, and openrc work fairly closely together to try to keep things running smoothly. Heck, there was just a discussion about whether systemd should support being able to switch back-and-forth with openrc by default, and the answer was yes, even though it involves installing a few files that are otherwise unneeded by systemd. Current policy is that when it comes to installing stuff like init scripts both systems should be supported by default so that people who want to switch either way don't have to rebuild half the system just to get some scripts. Of course, if you're talking about stuff like gnome3 you're not going to find equal support for both.
It drives us Americans crazy too, at least for those of us who actually read stuff hosted outside the US. It is also fun when traveling to have to deal with redirection into a language you can't read. If I wanted the japanese version of your site, I'd have asked for it.
The military needs to there own version of everything to make sure things work in times of national crisis, emergency, or security.
The military has their own radios for just that reason. They aren't going to depend on cell phones in a national security crisis. They certainly aren't going to try to harden a consumer cell phone and use it as a substitute for whatever the tanks on the battlefield use to communicate.
This came up in Iraq (I think that was Iraq v2, but maybe it happened in v1). The guys in the field had big clunky milspec GPS receivers, and many found consumer GPS units to be more featured and easier to use. The problem the military confronted was that they didn't want to be reliant on those consumer GPS units since they: 1. Couldn't handle spoofing. 2. Wouldn't work in a crisis that required the government to turn selective availability back on. 3. Probably wouldn't handle stuff like EMPs/etc.
Sure, that milspec receiver did 1/10th as much for 10x the cost and 3x the weight, but it handled all the contingencies that consumers don't care about.
Communications is important to the military. They're not going to rely on a consumer cell phone - they already degrade with relatively minor disasters let alone stuff like World War III.
If they indeed are Chinese (or otherwise foreign) spy towers, and so easily detected (the authors of the article didn't seem to have a hard time finding such towers), there's something terribly, terribly wrong with your homeland security.
The problem is that when any little police department is allowed to deploy this sort of thing and it ends up being ubiquitous, how do you even detect when somebody is using one to spy on you.
I mean, if the Chinese (or whoever your favorite boogeyman is) drove a tank up I-95 towards Washington DC, you can bet that somebody would notice and put a stop to it before it could do anything serious. On the other hand, if every police department routinely patrolled the highways with tanks just in case they ran into an armored car running drugs, then the Chinese could probably slip a whole battalion of them into DC without anybody noticing.
Well, they are FCC regulated within the US, but you're basically talking about the government regulating itself. Mostly the FCC's concern is going to be interference - not even the Air Force wants to spend a billion dollars on some fancy radar system only to find out that the Navy spent a billion dollars building a fancy communications system that uses the same frequencies/etc. Obviously spread spectrum mitigates many of these issues, but not entirely so.
I can't imagine the FCC is going to tell DHS that they can't use some anti-terror toy.
The problem is that the typical smartphone is designed to protect the baseband OS from the front-end OS, and not the other way around. If that baseband OS has full access to memory/IO and it is subverted, then you're talking about a rootkit detection problem from inside the rootkitted OS, and that is always tricky to do. The major vendors don't even try.
The solution security vendors like Blackphone and such pursue is to contain the baseband OS. For FCC reasons they probably still have to protect it from the front-end OS, but there is no reason that the firewall can't go both ways. Instead of giving the baseband CPU full access to memory/IO, they just partition up the phone so that it is like two computers in one box with a tightly-controlled interface between them.
Usually that sort of thing is the result of a kernel bug. Both init and systemd will wait for zombies, but if there is a kernel bug that doesn't always work.
Linux doesn't always handle resources becoming unavailable in a graceful manner. Sure, you can delete an in-use file and that is clever, but try to do the same thing with a mountpoint, or hardware device, and you end up with zombieland, BUGs, or even PANICs.
For y'all who are systemd proponents, if you actually want it to be adopted, then spend some money on a good tech writer and document the damn thing. I've read what documentation there is and it sucks. Really.
Seems like systemd isn't really hurting for people to adopt it. Just about every major linux distro already is doing so. Documentation tends to lag features on FOSS - I doubt that will change anytime soon, but I'm sure the docs will come. I too have been a bit annoyed having to reverse-engineer systemd features.
I haven't touched Gentoo in ages so don't know how it evolved but it appears to me that the FreeBSD ports collection is the very practical embodiment of what was being aimed at.
It should be, since that was what inspired the design of Gentoo.:)
From what I understand, FreeBSD Ports does not support USE flags, and I don't believe that FreeBSD is quite as flexible around overall configuration. Gentoo generally supports to some degree swapping out just about any component of the system. Heck, you can run it under OSX as non-root.
I agree with your point, but a problem is that many units use the simple model. That means that systemd considers launching the daemon to be a success, even if it terminates with an error 1ms later. There isn't a simple solution to this with any init system - if the daemon doesn't fork then there is no way to know how long to wait to see if it is going to stay alive.
If you use the forking model and the process doesn't fork, or if you use one of the more sophisticated models then systemd can capture errors in launching a daemon.
I suspect that these sorts of problems will take care of themselves as systemd becomes more common and upstream projects start integrating with it. Forking isn't actually the cleanest solution either - it is much better to just have the process check in when all sockets are ready to use.
The problem is that volunteer effort isn't fungible. You can't force people to invest in something that exists instead of creating something new, and much of the progress in the FOSS world actually comes from reinventing the wheel. This is less of a problem for non-volunteer-dominated projects, since they can just pay people to work on something boring.
OpenRC has its own limitations as well.
Systemd uses a very different approach to solving the problem than the solutions it replaces. That will introduce its own set of limitations, but it also can help it to surmount fundamental limitations that aren't easily handled by other solutions.
One way to scam that is to put a shim in the terminal, forcing it offline. Look for an extra cable coming from the card reader.
Just don't support offline mode on the terminals then. Or maybe design the terminals so that offline mode only works if a manager enables it, and then it only works for 15 minutes. This would allow stores to not grind to a halt when there is a communications problem, but it would prevent stores from just systematically ignoring that 99% of their terminals are in offline mode 24x7.
ATM cards support offline PIN verification too, or at least the spec does. Nobody ever used it because it was known to be insecure since the 70s (or maybe early 80s - whenever it was invented). Defeating that just requires reading/writing the magnetic strip.
Offline mode will already break debit cards. It seems far more sane to just require a network connection to use the payment system at all - and by all means have a backup modem link or whatever.
If Putin sent tanks into Estonia, do you really think the US/EU would send thousands of soldiers to their deaths, and open what is likely to be an unbounded conventional war with Russia?
Maybe if it got as far as Poland NATO would mean something. Maybe it would have to go all the way to Germany. I just don't see the average European willing to tolerate paying a bit more for heating in the winter over Estonia, let alone going to war.
> Uh, tell me how to adjust an init.d script such that: > 1. You add support for running the daemon with an ionice level which was missing from the original script. AND > 2. The next distro upgrade won't blow your changes away, and you won't have to manually re-combine your changes with their new init script which adds some new feature yours lacks?
Usualy, you make such changes in/etc/sysconfig/[daemon]. If you need to completely rewrite the daemon init script, you turn off the old script, write a new script with a new name such as 'daemon-ionice', make sure it has a 'Provides: daemon' line, and use that for init options. This is also the common approach if you need to run multiple copies of the same daemon, running on alternative configurations, such as SSH or Tomcat.
So, if you disable the distro-supplied script then it would not meet the criteria "you won't have to manually re-combine your changes with their new init script which adds some new feature yours lacks." I was well-aware of the approach you state when I posted that.
The problem is that traditional sysvinit scripts are just that, scripts - they are turing-complete and in general it isn't easy to blindly merge changes to code without causing issues. Systemd units are just a list of variables and their settings, and each variable just does one thing. That means that you can override a single variable and usually you get predictable and contained behavior. Sure, there are some variables where that isn't as safe, but ionice isn't one of them.
With systemd you can still override the entire script if you want to, but this usually isn't the right way to do things, since it has all the downsides of doing the same thing with sysvinit - you basically forked the script off of your distro and you don't benefit from later work done by your distro.
I'll tell you how - the way smart admins have always done it, by keeping their changes in a different file stored in version control that get's merged with whatever's in/etc after a dist-upgrade.
I keep my/etc in git. My distro also automatically renames modified files in/etc and I have an automated tool that does 3-way merging of changes when new changes come along that handles these updates without any intervention about 90% of the time, and the other 10% of the time it pops up meld for a manual 3-way merge which is usually pretty trivial.
I STILL think systemd does it better.
They say the same thing about excel spreadsheets. Most spreadsheets are still a hideous mess to maintain. I think you just proved the "against" argument.
Your argument is: 1. SystemD uses a declarative programming model. 2. Excel uses a declarative programming model. 3. Excel sucks. 4. Therefore systemd sucks?
The problem with Excel is that it tends to involve a LOT of inter-cell dependencies, which turns it into a rats nest, and "variables" are typically unnamed. Neither of those issues applies to systemd - variables all have meaningful names, and they rarely depend on each other.
I do get that boot order is non-deterministic, and that can make it more complex to deal with. On the other hand, if you have a lot of services I'd probably prefer a dependency-oriented approach to trying to figure out manually what order to load them all in. I haven't used a distro that just numbers all of its init scripts in a decade - it feels like the days of having line numbers in BASIC and hoping you leave enough room in-between them.
Failed boot, which coincidently has started happening more under systemd than I ever remember with Linux.
Typically this is the result of incorrect unit files. This sort of thing can happen with any init system, and the only reason you haven't encountered it with more traditional sysvinit implementations is that you probably haven't adopted distros before they have become popular. New (non-derivative) distros have this kind of problem all the time, but they tend to gain word-of-mouth popularity after these kinds of growing pains have passed.
The other issue is that systemd starts services MUCH more quickly so race conditions tend to become more apparent. If you have some process that takes 100ms to initialize then in the bash days that probably wouldn't have caused problems, but now that systemd is launching a process every 10ms it becomes a problem if the launching unit terminates before the process has created all of its sockets/etc.
The other problem I've tended to run into is when you have non-typical dependencies between services due to your configuration. Maybe in 90% of cases there is no dependency between two services, but you have one of them configured in a way that creates a dependency. My biggest problem tends to be with DNS, because most people don't host other services on a DNS server, and nobody supplies a BIND unit that waits until the server is running yet and I haven't had time to hack one together myself.
Compile an update to a systemd managed service that includes a library upgrade, then restart the service. Watch those containers and namespaces without orphans work out real well for you as systemd hangs on to the now defunct filehandle for the now missing, upgraded library and frantically tries to restart the service that half the server and by extension the users depend on.
It isn't clear to me exactly what you're doing here. I've yet to have problems with updating libraries that are used by services, and I'm running Gentoo which breaks ABI all the time. Also, I was talking about containers and half the point of containers is to keep them self-contained. Typically I shut them down, snapshot them, and start them up before doing an upgrade (all of this takes about 100ms), then I test the functionality of that container to make sure that it works (which is usually easy since that container doesn't provide 47 different services). If for some reason it doesn't work I can just roll back the snapshot.
Instead of fixing the broken code, broken apps and moving forward I get to diagnose yet another startup problem on a server that, before systemd,had 4+ years of uptime.
Honestly, this sounds like an issue with deploying a major change into a production environment before it was fully tested. If you have a well-oiled datacenter running on sysvinit it is unlikely that simply replacing that with systemd across the board is going to be issue-free.
SystemD works just fine on Gentoo whether you use Gnome 3 or not. It is just a required dependency if you run Gnome 3 since that is the direction Gnome is moving in.
As long as people take care of OpenRC I'm sure that will always be an option. I wouldn't be surprised if at some point the install tarballs stop bundling sysvinit/openrc - much as they do not bundle cron, syslog, or even a kernel, leaving the choice of what sysvinit to install up to the user.
Slashdot Mirror
Just another reminder to use strong passwords, password managers, and change them often. It's a pain, but it's the reality of the digital world.
Sure, but mobile apps make this sort of thing a pain.
I have apps that want you to enter your password frequently. That encourages trivial passwords unless you have some way to have a password vault app to fill them in for you, and that doesn't always work.
Then you have stuff like Android only supporting full-device encryption if your encryption key is the same as your screen lock PIN. Screen-lock PINs normally only have to defeat online attacks, and they can throttle attempts, lock out, etc to defeat brute force attacks. The whole point of disk encryption is to defeat offline attacks, so you need to use strong keys to make it work. You can potentially make them readable if you use multiple rounds to make cracking harder, but you can't make it a 4-digit number unless you design it such that the correct key takes a day and drains your battery to unlock the thing on the first attempt.
In the mobile world we really need to get away from hand-entered passwords. They're an acceptable one-time kludge during app setup, but after then you really need to move to some kind of token stored in a vault, and then use sandboxing at the OS level to keep the app safe from tampering.
Do you really want to stick a whole PC in a lab, expose it to chemicals, and put its CPU through repeated heat/cool cycles just to save on a thermocycler?
They mention costs like $19k to obtain one otherwise. I'm sure they sell for that much just as I'm sure you can go spend $2000 on a linux license, but all a thermocycler needs to do is heat samples and cool them. Clearly the CPU isn't going to be a high-performance cycler - you could probably build a little cycler that just uses radiative cooling and some resistive heating for $50. I see peltier heat sinks selling for $40 these days, so I'm sure for $100 you could build a thermocycler on the cheap.
An ideal thermocycler just needs to heat samples to about 95C for a few seconds, cool them down to about room temperature for a few seconds, and then hold them at something around body temperature for a minute or two, The time spent ramping temperature up/down is basically dead time, and you have to repeat this 20-30 times, so if your cycler can change temperature in seconds instead of minutes you can save a LOT of time per test. Peltier effect tends to be the way things are done, or at least it was back when I was using these in the labs.
It looks like openpcr.org has a unit for $600. I'm sure it could be improved on, but I imagine that as you get cheaper, you lose precision, and that does matter. I can't imagine that a CPU can maintain a temperature +/- 0.5C without quite a bit of effort.
I'll agree that I have seen issues where the default dependencies don't always catch everything. I run DNS and NFS on the same box, and I have DNS names in my exports, and often nfsd tries to do its job before DNS is running, and by default DNS isn't required for network-online, and even network-online is fairly new so many things don't use it.
It is still pretty rough around the edges all around.
It isn't that hard to add a dependency to a service though - you can do this with a drop-in.
Oh, I understand what you're saying. There are plenty of trolls to go around, and I don't think that some of the key systemd devs help things. There are also plenty of level-headed folks on either side who see the pros and cons and make reasonable contributions to the debate. I just try to be the latter... :)
Oh, I doubt openrc will go away completely, as long as somebody cares to maintain it. Gentoo never really turns away oddball configurations entirely. What you might find is more and more packages that lack an openrc script - even before systemd came along you could find the oddball package that lacked a script, and if many devs switch over you might find a lower level of support for openrc.
But, nobody is going to tell you, "you're not allowed to run openrc." Despite all the noise people make publicly, the reality is that within Gentoo the maintainers of systemd, udev, eudev, and openrc work fairly closely together to try to keep things running smoothly. Heck, there was just a discussion about whether systemd should support being able to switch back-and-forth with openrc by default, and the answer was yes, even though it involves installing a few files that are otherwise unneeded by systemd. Current policy is that when it comes to installing stuff like init scripts both systems should be supported by default so that people who want to switch either way don't have to rebuild half the system just to get some scripts. Of course, if you're talking about stuff like gnome3 you're not going to find equal support for both.
It drives us Americans crazy too, at least for those of us who actually read stuff hosted outside the US. It is also fun when traveling to have to deal with redirection into a language you can't read. If I wanted the japanese version of your site, I'd have asked for it.
The military needs to there own version of everything to make sure things work in times of national crisis, emergency, or security.
The military has their own radios for just that reason. They aren't going to depend on cell phones in a national security crisis. They certainly aren't going to try to harden a consumer cell phone and use it as a substitute for whatever the tanks on the battlefield use to communicate.
This came up in Iraq (I think that was Iraq v2, but maybe it happened in v1). The guys in the field had big clunky milspec GPS receivers, and many found consumer GPS units to be more featured and easier to use. The problem the military confronted was that they didn't want to be reliant on those consumer GPS units since they:
1. Couldn't handle spoofing.
2. Wouldn't work in a crisis that required the government to turn selective availability back on.
3. Probably wouldn't handle stuff like EMPs/etc.
Sure, that milspec receiver did 1/10th as much for 10x the cost and 3x the weight, but it handled all the contingencies that consumers don't care about.
Communications is important to the military. They're not going to rely on a consumer cell phone - they already degrade with relatively minor disasters let alone stuff like World War III.
If they indeed are Chinese (or otherwise foreign) spy towers, and so easily detected (the authors of the article didn't seem to have a hard time finding such towers), there's something terribly, terribly wrong with your homeland security.
The problem is that when any little police department is allowed to deploy this sort of thing and it ends up being ubiquitous, how do you even detect when somebody is using one to spy on you.
I mean, if the Chinese (or whoever your favorite boogeyman is) drove a tank up I-95 towards Washington DC, you can bet that somebody would notice and put a stop to it before it could do anything serious. On the other hand, if every police department routinely patrolled the highways with tanks just in case they ran into an armored car running drugs, then the Chinese could probably slip a whole battalion of them into DC without anybody noticing.
Of course no one was punished or disciplined, and certainly no one lost their badge, because, hey, they are cops, and boys will be boys.
Why, that is an outrageous accusation. I'm sure somebody was given an extra paid vacation, err, put on temporary suspension, when this hit the press.
Well, they are FCC regulated within the US, but you're basically talking about the government regulating itself. Mostly the FCC's concern is going to be interference - not even the Air Force wants to spend a billion dollars on some fancy radar system only to find out that the Navy spent a billion dollars building a fancy communications system that uses the same frequencies/etc. Obviously spread spectrum mitigates many of these issues, but not entirely so.
I can't imagine the FCC is going to tell DHS that they can't use some anti-terror toy.
The problem is that the typical smartphone is designed to protect the baseband OS from the front-end OS, and not the other way around. If that baseband OS has full access to memory/IO and it is subverted, then you're talking about a rootkit detection problem from inside the rootkitted OS, and that is always tricky to do. The major vendors don't even try.
The solution security vendors like Blackphone and such pursue is to contain the baseband OS. For FCC reasons they probably still have to protect it from the front-end OS, but there is no reason that the firewall can't go both ways. Instead of giving the baseband CPU full access to memory/IO, they just partition up the phone so that it is like two computers in one box with a tightly-controlled interface between them.
Usually that sort of thing is the result of a kernel bug. Both init and systemd will wait for zombies, but if there is a kernel bug that doesn't always work.
Linux doesn't always handle resources becoming unavailable in a graceful manner. Sure, you can delete an in-use file and that is clever, but try to do the same thing with a mountpoint, or hardware device, and you end up with zombieland, BUGs, or even PANICs.
For y'all who are systemd proponents, if you actually want it to be adopted, then spend some money on a good tech writer and document the damn thing. I've read what documentation there is and it sucks. Really.
Seems like systemd isn't really hurting for people to adopt it. Just about every major linux distro already is doing so. Documentation tends to lag features on FOSS - I doubt that will change anytime soon, but I'm sure the docs will come. I too have been a bit annoyed having to reverse-engineer systemd features.
I haven't touched Gentoo in ages so don't know how it evolved but it appears to me that the FreeBSD ports collection is the very practical embodiment of what was being aimed at.
It should be, since that was what inspired the design of Gentoo. :)
From what I understand, FreeBSD Ports does not support USE flags, and I don't believe that FreeBSD is quite as flexible around overall configuration. Gentoo generally supports to some degree swapping out just about any component of the system. Heck, you can run it under OSX as non-root.
I agree with your point, but a problem is that many units use the simple model. That means that systemd considers launching the daemon to be a success, even if it terminates with an error 1ms later. There isn't a simple solution to this with any init system - if the daemon doesn't fork then there is no way to know how long to wait to see if it is going to stay alive.
If you use the forking model and the process doesn't fork, or if you use one of the more sophisticated models then systemd can capture errors in launching a daemon.
I suspect that these sorts of problems will take care of themselves as systemd becomes more common and upstream projects start integrating with it. Forking isn't actually the cleanest solution either - it is much better to just have the process check in when all sockets are ready to use.
you mean journalctl -f | grep?
The problem is that volunteer effort isn't fungible. You can't force people to invest in something that exists instead of creating something new, and much of the progress in the FOSS world actually comes from reinventing the wheel. This is less of a problem for non-volunteer-dominated projects, since they can just pay people to work on something boring.
OpenRC has its own limitations as well.
Systemd uses a very different approach to solving the problem than the solutions it replaces. That will introduce its own set of limitations, but it also can help it to surmount fundamental limitations that aren't easily handled by other solutions.
One way to scam that is to put a shim in the terminal, forcing it offline. Look for an extra cable coming from the card reader.
Just don't support offline mode on the terminals then. Or maybe design the terminals so that offline mode only works if a manager enables it, and then it only works for 15 minutes. This would allow stores to not grind to a halt when there is a communications problem, but it would prevent stores from just systematically ignoring that 99% of their terminals are in offline mode 24x7.
ATM cards support offline PIN verification too, or at least the spec does. Nobody ever used it because it was known to be insecure since the 70s (or maybe early 80s - whenever it was invented). Defeating that just requires reading/writing the magnetic strip.
Offline mode will already break debit cards. It seems far more sane to just require a network connection to use the payment system at all - and by all means have a backup modem link or whatever.
If Putin sent tanks into Estonia, do you really think the US/EU would send thousands of soldiers to their deaths, and open what is likely to be an unbounded conventional war with Russia?
Maybe if it got as far as Poland NATO would mean something. Maybe it would have to go all the way to Germany. I just don't see the average European willing to tolerate paying a bit more for heating in the winter over Estonia, let alone going to war.
> Uh, tell me how to adjust an init.d script such that:
> 1. You add support for running the daemon with an ionice level which was missing from the original script.
AND
> 2. The next distro upgrade won't blow your changes away, and you won't have to manually re-combine your changes with their new init script which adds some new feature yours lacks?
Usualy, you make such changes in /etc/sysconfig/[daemon]. If you need to completely rewrite the daemon init script, you turn off the old script, write a new script with a new name such as 'daemon-ionice', make sure it has a 'Provides: daemon' line, and use that for init options. This is also the common approach if you need to run multiple copies of the same daemon, running on alternative configurations, such as SSH or Tomcat.
So, if you disable the distro-supplied script then it would not meet the criteria "you won't have to manually re-combine your changes with their new init script which adds some new feature yours lacks." I was well-aware of the approach you state when I posted that.
The problem is that traditional sysvinit scripts are just that, scripts - they are turing-complete and in general it isn't easy to blindly merge changes to code without causing issues. Systemd units are just a list of variables and their settings, and each variable just does one thing. That means that you can override a single variable and usually you get predictable and contained behavior. Sure, there are some variables where that isn't as safe, but ionice isn't one of them.
With systemd you can still override the entire script if you want to, but this usually isn't the right way to do things, since it has all the downsides of doing the same thing with sysvinit - you basically forked the script off of your distro and you don't benefit from later work done by your distro.
I'll tell you how - the way smart admins have always done it, by keeping their changes in a different file stored in version control that get's merged with whatever's in /etc after a dist-upgrade.
I keep my /etc in git. My distro also automatically renames modified files in /etc and I have an automated tool that does 3-way merging of changes when new changes come along that handles these updates without any intervention about 90% of the time, and the other 10% of the time it pops up meld for a manual 3-way merge which is usually pretty trivial.
I STILL think systemd does it better.
They say the same thing about excel spreadsheets. Most spreadsheets are still a hideous mess to maintain. I think you just proved the "against" argument.
Your argument is:
1. SystemD uses a declarative programming model.
2. Excel uses a declarative programming model.
3. Excel sucks.
4. Therefore systemd sucks?
The problem with Excel is that it tends to involve a LOT of inter-cell dependencies, which turns it into a rats nest, and "variables" are typically unnamed. Neither of those issues applies to systemd - variables all have meaningful names, and they rarely depend on each other.
I do get that boot order is non-deterministic, and that can make it more complex to deal with. On the other hand, if you have a lot of services I'd probably prefer a dependency-oriented approach to trying to figure out manually what order to load them all in. I haven't used a distro that just numbers all of its init scripts in a decade - it feels like the days of having line numbers in BASIC and hoping you leave enough room in-between them.
Failed boot, which coincidently has started happening more under systemd than I ever remember with Linux.
Typically this is the result of incorrect unit files. This sort of thing can happen with any init system, and the only reason you haven't encountered it with more traditional sysvinit implementations is that you probably haven't adopted distros before they have become popular. New (non-derivative) distros have this kind of problem all the time, but they tend to gain word-of-mouth popularity after these kinds of growing pains have passed.
The other issue is that systemd starts services MUCH more quickly so race conditions tend to become more apparent. If you have some process that takes 100ms to initialize then in the bash days that probably wouldn't have caused problems, but now that systemd is launching a process every 10ms it becomes a problem if the launching unit terminates before the process has created all of its sockets/etc.
The other problem I've tended to run into is when you have non-typical dependencies between services due to your configuration. Maybe in 90% of cases there is no dependency between two services, but you have one of them configured in a way that creates a dependency. My biggest problem tends to be with DNS, because most people don't host other services on a DNS server, and nobody supplies a BIND unit that waits until the server is running yet and I haven't had time to hack one together myself.
Compile an update to a systemd managed service that includes a library upgrade, then restart the service. Watch those containers and namespaces without orphans work out real well for you as systemd hangs on to the now defunct filehandle for the now missing, upgraded library and frantically tries to restart the service that half the server and by extension the users depend on.
It isn't clear to me exactly what you're doing here. I've yet to have problems with updating libraries that are used by services, and I'm running Gentoo which breaks ABI all the time. Also, I was talking about containers and half the point of containers is to keep them self-contained. Typically I shut them down, snapshot them, and start them up before doing an upgrade (all of this takes about 100ms), then I test the functionality of that container to make sure that it works (which is usually easy since that container doesn't provide 47 different services). If for some reason it doesn't work I can just roll back the snapshot.
Instead of fixing the broken code, broken apps and moving forward I get to diagnose yet another startup problem on a server that, before systemd ,had 4+ years of uptime.
Honestly, this sounds like an issue with deploying a major change into a production environment before it was fully tested. If you have a well-oiled datacenter running on sysvinit it is unlikely that simply replacing that with systemd across the board is going to be issue-free.
Looks like Slackware and Gentoo are the last of the faithful. The rest are infidels...
Uh, systemd works just fine on Gentoo, though openrc comes pre-installed at this point.
SystemD works just fine on Gentoo whether you use Gnome 3 or not. It is just a required dependency if you run Gnome 3 since that is the direction Gnome is moving in.
As long as people take care of OpenRC I'm sure that will always be an option. I wouldn't be surprised if at some point the install tarballs stop bundling sysvinit/openrc - much as they do not bundle cron, syslog, or even a kernel, leaving the choice of what sysvinit to install up to the user.
What I don't understand is why systemd advocates continue to not understand the perspective of those against it.
This suffers a bit from the "everybody in the world would agree with me if they only understood everything as well as I do" school of thought...
It is entirely possible that they understand the counter-arguments, but simply do not agree with them.