That doesn't help much when the caller is in another jurisdiction such as India.
It also doesn't help when some scummy debt collector has randomly associated your number with an alleged debtor that you don't know. They call relentlessly and refuse to accept that you don't even know the person. They claim do-not-call doesn't apply because they have a 'business relationship' with the debtor. They claim you can't order them to stop calling because you said you weren't the debtor. They are the biggest assholes you will ever have the mis-fortune to communicate with.
They will happily run up huge cellphone bills for completely innocent 3rd parties if they are allowed to "wrong number" dial your cellphone over and over.
That works for some cases (as long as the btrfs doesn't contain parts that systemd needs) but still fails when the root filesystem is btrfs (of course, then it's the kernel commandline that systemd refuses to just shut up and do in the initramfs). That's a bit ironic given that Lennart's big plan to replace package management would require btrfs as the root filesystem.:-)
As I understand from the mailing lists, it has the same problem if the root filesystem is on a degraded RAID.
I agree. It seems to me that they lack experience in general. More experience would teach them to either make the effort to capture the use cases or at least to build a toolset that could be configured to match use cases after the fact. It's a lot of effort just to produce one of the most actively hated pieces of software in the Free world.
Unless you want to see the actual flow of the boot process, that is. In a proper programming language, you would write a function and call it with each set of parameters.
I'm no fan of MS (and I'm sure my posting history will bear that out), but there are other considerations here. No, MS shouldn't get a complete skate on this. They have proven that they need their feet held to the fire to get things to happen. BUT, there needs to be some slack in the system. If they appear to have been working on the problem in earnest and have a release plan, it's worth giving them time to complete it.
Unlike a building with a flaw, there aren't lives at stake here and releasing the details of the flaw in advance of the fix increase the chances of trouble. Further, if the likelihood of a problem in the immediate future is small enough, builders are often given the chance to make corrections before the details come out.
You should probably know that you cannot hire 12 or 3 people AND get them up to speed enough to fix the bug in 90 days. It'll take 30 to 60 just to hire them.
There does need to be some kind of deadline or too many corporations will just pay a bit of lip service and forget all about it, but not everything fits neatly into a 90 day window that starts with no warning.
Google is developing quite a rep for being impossible to reason with (literally, there exists no contact available to mere mortals for anyone who even has the ability to do anything about anything.
Some distros have chosen to over-complicate things, but they're not really interlocking. If you want to see what's going on, there aren't a lot of places you have to look.
I'm guessing you have never looked at the OTHER configuration files for systemd. The ones in/lib, for example.
I have looked at the sysV scripts and I have looked at the systemd configs. There were more config files scattered all over the place and not even a hint which runs when. Some of them are templates that systemd uses to creat temporary conffig files at boot time!
systemd configs are an order of magnitude more complex than a typical sysVinit AND that doesn't even count the source code of systemd itself.
Running without ls is trivial (the standard scripts don't use it). You can (and I have) run without udev, just stick the devnodes in a static/dev.
Embedded devices may well not have/bin/sh on them. Just have init directly call the one and only app. You can even invent your own scripting language and use that interpreter.
Actually, I don't mind the shell because I have many to choose from. I don't even actually have to have one. I CAN replace rcS with a binary for embedded apps pretty easily if I need to. All those other tools are necessary if I want a more or less normal userspace anyway, but if I don't want a typical userspace, I can leave them out.
Sometimes I replace the lot of that with busybox. Sometimes busybox is only there as a convenience for debugging through a serial port inside the device. Depending on the environment, login may or may not be involved. If it is just for debugging in-house, I can just have it directly launch a root shell on the serial port.
And the apps I run on top of that don't care which of those options I choose. That leaves me completely free to choose the best solution for the job.
I suppose if you were qualified to judge the merits of an init system, you would have known all of that.
Because it's not willing to move past seeing that there is a storage volume with a missing dependency (the dead drive) so it stops right then and there. If I could get it to ignore that and move on, that would be fine but since nobody on the dev team ever considered the possibility, the capability isn't there.
I haven't seen any way to tell it that things systemd wants to do before it even parses the services are dependent on a script being run.
Excellemt, do tell how I might run the time server (which is actually an sntp server, not ntp) but not journald or systemd. But udevd is kinda nice so throw that in.
It is incorrect. The tools are inseparable. The traditional Unix tools can be freely mixed and matched and in general are widely portable to other systems. Systemd is somewhat modular, but it is not a toolbox.
If, for example you want to run the systemd project's time server, you must run systemd and so journald and dbus. Because of that, you cannot use sysvinit or anything that wants to use cgroups (unless it is re-written to talk to systemd). Oddly enough, it also means you can't boot the server with a degraded RAID.
OTOH, if I want to just run the old ntpd, no problem.
Ah, totally interchangable tools! Great, I think I'll just run the ntpd part and... That doesn't work? How about if I just run journald and ntpd? Still no? OK, how about just systemd and I'll have some other logger. Damn, still no!
Some people run servers that MUST be up and running. They have no time for bullshit. They have no time to pick through a bazillion little config files when it's not up and running. They need the machine to just do what they tell it to and do it now. Systemd just thumbs it's nose at that. It does only a limited number of things and only in the way that it wants to do them. If that's not what you need done, too bad.
The hate is amplified by the concerted effort to cram systemd down their throats. That's a perfectly understandable reaction IMHO.
For example, I built a test machine with btrfs and set it up to mount in degraded mode such that even if a disk fails, it should still boot up. In production, it would email me that a disk failed and I could decide between replace the disk immediately or rebalance to make sure everything is still redundant.
Systemd absolutely refuses to do it. It won't even attempt the mount command because it has decided that a drive isn't there and even though it is completely redundant systemd calls it a show stopper. Nobody can seem to tell me how to make systemd issue the mount command anyway (the systemd maioling lists have discussed that very problem wrt RAID and can't seem to solve the problem), nor can anyone give me a solution to make systemd ignore fstab entirely and run a script I wrote instead (a script that only needs one command, 'mount -a'). Apparently, you can't actually do that.
Consider, RAID and similar are high availability features. Their whole reason to be is making sure the system is available even if a drive fails. Systemd single-handedly defeats that whole purpose by refusing to even try to mount the root filesystem. That's really a poor showing, but the insight it gives me into the project is even worse. It tells me that in spite of the importance of redundancy (some enterprises spend gadzillions on it) and the fact that it has worked well under SysVinit for over a decade, not one person on the systemd team even considered it. Not one. Now that it has been brought to their attention, they can't even come up with a workaround for it (see what I said above about do what I say and do it now). All I need is an unconditional 'mount -a' and apparently it can't be done. In spite of that, the various systemd boosters refuse to admit the problem even exists. I have even had a few claim it's a feature meant to protect my data.
So there it is. It's not a matter of opinion, it's a simple boolean: "Did my system boot" and the objective answer is no. There is the followup, "how then, can I make systemd boot it" and the answer is [crickets].
Fortunately, it was just a VM I stood up for testing and not an actual server that I needed up. As a quick test, I replaced systemd with sysVinit using apt and suddenly, it just worked.
And that is why everyone is so keen on making sure nothing else becomes dependent on systemd.
Wrong. That base still wouldn't boot my server for me and the systemd people would still be spinning in circles unable to even conceive of a way to fix it. You see, I want the server to boot w/ btrfs in degraded mode should it suffer a drive failure. But systemd won't do it.
I don't know about Suse, byt Red Hat does not. Otherwise they'd have noticed that sysadmins are sticking with RHEL6 to avoid systemd trouble.
Nonsense. I did look at it and concluded it's a hairball of interdependent bits that cannot stand alone. As for the 'simplicity', anyone who claims it is more maintainable than a handfull or 2 of init scripts needs to actually look under the hood (where you have to look for anything but the simple cases). It's a nightmare of interlocking configuration files. I thought the "come from" (as opposed to GOTO) statement was a joke until I saw the functionality actually implemented in systemd (with all of the un-maintainability that implies).
PID 1 doesn't do all of that itself, but all of that includes PID 1 in the inseparable hairball.
Slashdot Mirror
I live in the U.S. Here, for some godawful reason, cellular customers pay to receive the call.
THIS! They will call every man, woman, and child in the U.S. once, then fold up their tents and open under a new name so they can do it again.
It's about time for these shoddy businesses to be taught that I do not owe them my time or ears.
That doesn't help much when the caller is in another jurisdiction such as India.
It also doesn't help when some scummy debt collector has randomly associated your number with an alleged debtor that you don't know. They call relentlessly and refuse to accept that you don't even know the person. They claim do-not-call doesn't apply because they have a 'business relationship' with the debtor. They claim you can't order them to stop calling because you said you weren't the debtor. They are the biggest assholes you will ever have the mis-fortune to communicate with.
They will happily run up huge cellphone bills for completely innocent 3rd parties if they are allowed to "wrong number" dial your cellphone over and over.
I have seen that as well.
That works for some cases (as long as the btrfs doesn't contain parts that systemd needs) but still fails when the root filesystem is btrfs (of course, then it's the kernel commandline that systemd refuses to just shut up and do in the initramfs). That's a bit ironic given that Lennart's big plan to replace package management would require btrfs as the root filesystem. :-)
As I understand from the mailing lists, it has the same problem if the root filesystem is on a degraded RAID.
I agree. It seems to me that they lack experience in general. More experience would teach them to either make the effort to capture the use cases or at least to build a toolset that could be configured to match use cases after the fact. It's a lot of effort just to produce one of the most actively hated pieces of software in the Free world.
Unless you want to see the actual flow of the boot process, that is. In a proper programming language, you would write a function and call it with each set of parameters.
9 Women cannot make a baby in a month.
I'm no fan of MS (and I'm sure my posting history will bear that out), but there are other considerations here. No, MS shouldn't get a complete skate on this. They have proven that they need their feet held to the fire to get things to happen. BUT, there needs to be some slack in the system. If they appear to have been working on the problem in earnest and have a release plan, it's worth giving them time to complete it.
Unlike a building with a flaw, there aren't lives at stake here and releasing the details of the flaw in advance of the fix increase the chances of trouble. Further, if the likelihood of a problem in the immediate future is small enough, builders are often given the chance to make corrections before the details come out.
You should probably know that you cannot hire 12 or 3 people AND get them up to speed enough to fix the bug in 90 days. It'll take 30 to 60 just to hire them.
There does need to be some kind of deadline or too many corporations will just pay a bit of lip service and forget all about it, but not everything fits neatly into a 90 day window that starts with no warning.
Google is developing quite a rep for being impossible to reason with (literally, there exists no contact available to mere mortals for anyone who even has the ability to do anything about anything.
Some distros have chosen to over-complicate things, but they're not really interlocking. If you want to see what's going on, there aren't a lot of places you have to look.
I'm guessing you have never looked at the OTHER configuration files for systemd. The ones in /lib, for example.
I have looked at the sysV scripts and I have looked at the systemd configs. There were more config files scattered all over the place and not even a hint which runs when. Some of them are templates that systemd uses to creat temporary conffig files at boot time!
systemd configs are an order of magnitude more complex than a typical sysVinit AND that doesn't even count the source code of systemd itself.
Running without ls is trivial (the standard scripts don't use it). You can (and I have) run without udev, just stick the devnodes in a static /dev.
Embedded devices may well not have /bin/sh on them. Just have init directly call the one and only app. You can even invent your own scripting language and use that interpreter.
But thank you for playing, please try again.
Actually, I don't mind the shell because I have many to choose from. I don't even actually have to have one. I CAN replace rcS with a binary for embedded apps pretty easily if I need to. All those other tools are necessary if I want a more or less normal userspace anyway, but if I don't want a typical userspace, I can leave them out.
Sometimes I replace the lot of that with busybox. Sometimes busybox is only there as a convenience for debugging through a serial port inside the device. Depending on the environment, login may or may not be involved. If it is just for debugging in-house, I can just have it directly launch a root shell on the serial port.
And the apps I run on top of that don't care which of those options I choose. That leaves me completely free to choose the best solution for the job.
I suppose if you were qualified to judge the merits of an init system, you would have known all of that.
Any config anywhere in the whole mush can declare itself to be a pre-requisite for some other script.
Because it's not willing to move past seeing that there is a storage volume with a missing dependency (the dead drive) so it stops right then and there. If I could get it to ignore that and move on, that would be fine but since nobody on the dev team ever considered the possibility, the capability isn't there.
I haven't seen any way to tell it that things systemd wants to do before it even parses the services are dependent on a script being run.
Excellemt, do tell how I might run the time server (which is actually an sntp server, not ntp) but not journald or systemd. But udevd is kinda nice so throw that in.
It is incorrect. The tools are inseparable. The traditional Unix tools can be freely mixed and matched and in general are widely portable to other systems. Systemd is somewhat modular, but it is not a toolbox.
If, for example you want to run the systemd project's time server, you must run systemd and so journald and dbus. Because of that, you cannot use sysvinit or anything that wants to use cgroups (unless it is re-written to talk to systemd). Oddly enough, it also means you can't boot the server with a degraded RAID.
OTOH, if I want to just run the old ntpd, no problem.
Ah, totally interchangable tools! Great, I think I'll just run the ntpd part and... That doesn't work? How about if I just run journald and ntpd? Still no? OK, how about just systemd and I'll have some other logger. Damn, still no!
So what do I have to not run in order to have glibc? Does glibc need to be any particular PID?
Answers, nothing and no respectively, so my stance is that it's just fine.
So, if I compile just the timeserver part, it'll run on my sysVinit system?
No, it will only run if I also run systemd, so it is not just an independent tool. It is a wholly dependent module.
Systemd is modular, but due to the inter-dependencies, it is not a toolkit like coreutils.
I WISH I didn't notice it in userspace.
Some people run servers that MUST be up and running. They have no time for bullshit. They have no time to pick through a bazillion little config files when it's not up and running. They need the machine to just do what they tell it to and do it now. Systemd just thumbs it's nose at that. It does only a limited number of things and only in the way that it wants to do them. If that's not what you need done, too bad.
The hate is amplified by the concerted effort to cram systemd down their throats. That's a perfectly understandable reaction IMHO.
For example, I built a test machine with btrfs and set it up to mount in degraded mode such that even if a disk fails, it should still boot up. In production, it would email me that a disk failed and I could decide between replace the disk immediately or rebalance to make sure everything is still redundant.
Systemd absolutely refuses to do it. It won't even attempt the mount command because it has decided that a drive isn't there and even though it is completely redundant systemd calls it a show stopper. Nobody can seem to tell me how to make systemd issue the mount command anyway (the systemd maioling lists have discussed that very problem wrt RAID and can't seem to solve the problem), nor can anyone give me a solution to make systemd ignore fstab entirely and run a script I wrote instead (a script that only needs one command, 'mount -a'). Apparently, you can't actually do that.
Consider, RAID and similar are high availability features. Their whole reason to be is making sure the system is available even if a drive fails. Systemd single-handedly defeats that whole purpose by refusing to even try to mount the root filesystem. That's really a poor showing, but the insight it gives me into the project is even worse. It tells me that in spite of the importance of redundancy (some enterprises spend gadzillions on it) and the fact that it has worked well under SysVinit for over a decade, not one person on the systemd team even considered it. Not one. Now that it has been brought to their attention, they can't even come up with a workaround for it (see what I said above about do what I say and do it now). All I need is an unconditional 'mount -a' and apparently it can't be done. In spite of that, the various systemd boosters refuse to admit the problem even exists. I have even had a few claim it's a feature meant to protect my data.
So there it is. It's not a matter of opinion, it's a simple boolean: "Did my system boot" and the objective answer is no. There is the followup, "how then, can I make systemd boot it" and the answer is [crickets].
Fortunately, it was just a VM I stood up for testing and not an actual server that I needed up. As a quick test, I replaced systemd with sysVinit using apt and suddenly, it just worked.
And that is why everyone is so keen on making sure nothing else becomes dependent on systemd.
Wrong. That base still wouldn't boot my server for me and the systemd people would still be spinning in circles unable to even conceive of a way to fix it. You see, I want the server to boot w/ btrfs in degraded mode should it suffer a drive failure. But systemd won't do it.
I don't know about Suse, byt Red Hat does not. Otherwise they'd have noticed that sysadmins are sticking with RHEL6 to avoid systemd trouble.
That's funny, I thought it was solved by startpar!
Look under the hood a bit and try to tell me that hot mess is easier to config than a handful of init scripts.
And totally sidestepped any of the very legitimate concerns of the people who have a principled objection to systemd.
Nonsense. I did look at it and concluded it's a hairball of interdependent bits that cannot stand alone. As for the 'simplicity', anyone who claims it is more maintainable than a handfull or 2 of init scripts needs to actually look under the hood (where you have to look for anything but the simple cases). It's a nightmare of interlocking configuration files. I thought the "come from" (as opposed to GOTO) statement was a joke until I saw the functionality actually implemented in systemd (with all of the un-maintainability that implies).
PID 1 doesn't do all of that itself, but all of that includes PID 1 in the inseparable hairball.