But you apparently aren't rolling out anything (since you claimed to have not to care and to have no horse in the race). The arguments have been made and they are quite clear.
I object to systemd because it wedges itself in with dependencies in such a way that it will become difficult to replace with something better. I object to it's piss-poor design as well.
You may want it to be just Luddites but that has nothing to do with it. You need to pull your fingers out of your ears and quit singing LA LA LA now.
Actually, Debian offers a BSD kernel based distro. You can choose between gdm,kdm,and xdm and nothing unrelated breaks depending on your choice. You can install another X if you can find one and no mysterious breakage of unrelated components. So no, none of those are crammed down your throat.
OTOH, dare to not choose systemd and your GUI desktop breaks, what the hell is that?!?
They make credit card chips that can do RSA, so there shouldn't be a big problem there. Also, the receiver shouldn't draw as much power as the transmitter.
Failing that, if making an actually secure keyless entry isn't feasible, surely making a crappy one and lying about it's security isn't the right answer.
logind depends on systemd. Gnome depends on logind.
There is a patch made for logind that frees it from systemd dependence (proving it isn't necessary) but it remains external to the systemd project. Note well that the systemd project fully intended that not installing systemd would break your desktop.
So why does systemd insist on being PID 1 or replacing init and scripts at all? My proposal would do neither of those things and so nobody gets pissed off. It's nice to see that you agree that something done the Unix way could easily achieve the same thing as systemd.
So the question remains, why then does systemd insist on doing it wrong to piss people off?
If you need it to come up that fast from power off, suspend to disk and be done with it. Neither systemd or sysvinit will beat the time to unsuspend.
In the desktop machine, due to power management, you can for the most part just leave it on. Businesses can easily enough schedule PCs to power on and boot 15 minutes before the start of the workday.
Of course, there are various parallel boot systems that work with scripts.
In debian, it was a split vote among 8 people. That's right, out of the 8 people who voted on systemd, 4 voted against leaving the chairman to break the tie. Is that what you call overwhelming support? Now there is a resolution in discussion which would forbid other packages from depending on systemd and maintain at least the option of other init systems (reachable from the advanced install menu).
Tell me again how overwhelming the support for systemd is in Debian!
If the resolution passes, it wouldn't surprise me if other distros build on the work of keeping dependencies out and also make systemd optional. Otherwise, many of the Debian fork people seem quite serious and are qualified. There's also uselessd. Once that matures, I wouldn't be surprised to see systemd lose support.
Like what? What seriously cool administrative feature does it offer?
When you answer, you should know that I did some serious hacking on beoboot at one time. Hacking that would have been a lot less feasible had systemd been wedged into the system.
Are you sure? Why did you reboot to fix heartbleed? Why not stop, update, and then start the affected services?
I have some very old binaries (compiled static) that still work just fine. Other than a recentish foobar in glibc that finds older kernels unsettle it's delicate sensibilities (someone needs to lose a finger...) I haven't seen much trouble with careful mixing and matching.
This isn't windows, I can do security updates without rebooting. There are occasionally security updates to the kernel, but not all of them need to be addressed immediately on all systems. A good admin knows which is which. There is a system to update a running kernel as well. Personally I find that all too fiddly and so prefer to reboot when a kernel update is required.
But note, if the update only affects a module, it may be feasible to rmmod and insmod that module alone.
Failing that, there are at least two approaches in the works to fork it if necessary. One would fork Debian, the other is uselessd to fork systemd into something a bit less pernicious.
And as a result, when you do/etc/init.d/apache stop, apache stops. When you do/etc/init.d/apache start, (drumroll please), apacghe starts. Just exactly what he said.
Honestly, some of the individual rc scripts have become too clever by half. When it becomes too much, I replace it with one that has about 10 simple lines in it and it works great.
But if you find it all too much, answer a question no systemd proponant has yet managed to answer, why not start with the parallel startup in wheezy and add a helper app that runs the daemon in a cgroup and sticks around to manage it? Just stick that in the script like:
...
start)/sbin/manage start apache;;
stop)/sbin/manage stop apache;;
You could even do something like/sbin/manage waitfor nfs start apache
All the advantages, none of the problems presented by systemd. When starting, manage could register on dbus as well if desired. The desktop people could use that and the old school people could safely ignore it. Done right, manage need not freak out if dbus isn't running.
Any reason other than failure to force systemd on the world why that shouldn't make both camps happy?
Rate limiting would help a LOT, but may not be enough if the bad guys rig up a strong transmitter. If you are in a crowded parking lot, you probably don't much care which BMW you steal, the first one to unlock will be good enough.
It's not like BMWs are bargain basement cars, surely they could have spent a bit on an actually secure keyless entry system.
Sure there's a difference. I don't have genes to produce lignin.
As for the tifton85, you apparently don't know that it is still being used as forage and that it only rarely produces cyanide under stressed conditions, like sorghum and other grasses.
Tifton-85 is also sterile, so unlike some of the GM crops, it isn't likely to spread far (other than via rhizomes).
However, I never said breeding CAN'T go wrong, just that it tends not to go as wrong as quickly. The issues you noted are exactly that warning that you don't get with GM.
Slashdot Mirror
But you apparently aren't rolling out anything (since you claimed to have not to care and to have no horse in the race). The arguments have been made and they are quite clear.
If you made changes to a script that normally needs no changes, you have to put your big-boy pants on and look after it.
Not sure what you mean by physically doing it. You can also configure apt to not ask you anything if there is a default.
OK, you made a good case for cgroups, but you failed to advocate systemd.
You are wrong about multiple instances. Have a look at PostgreSQL in Debian. Have a look at libvirt. It can start as many VMs as you want.
But note well, some believe mercury amalgam fillings are a bad solution to cavities. That does not make blasting gel the correct answer.
When apt asks you what to do, tell it to keep your local version (the default). OOOOOOOOhhhhh, so hard.
How about the complexity of the interpreter for those unit files? You didn't think they did their thing with elfen magic did you?
In contrast, shell interpreters are vastly better tested for much longer.
Most people who object to eating dog poop haven't tried it in a souffle either.
That's not a bad thing.
I object to systemd because it wedges itself in with dependencies in such a way that it will become difficult to replace with something better. I object to it's piss-poor design as well.
You may want it to be just Luddites but that has nothing to do with it. You need to pull your fingers out of your ears and quit singing LA LA LA now.
Actually, Debian offers a BSD kernel based distro. You can choose between gdm,kdm,and xdm and nothing unrelated breaks depending on your choice. You can install another X if you can find one and no mysterious breakage of unrelated components. So no, none of those are crammed down your throat.
OTOH, dare to not choose systemd and your GUI desktop breaks, what the hell is that?!?
Personally, I blame the pathetic cowards who shriek, hike up their skirts and do the mousey dance every time someone sneezes at the airport.
They make credit card chips that can do RSA, so there shouldn't be a big problem there. Also, the receiver shouldn't draw as much power as the transmitter.
Failing that, if making an actually secure keyless entry isn't feasible, surely making a crappy one and lying about it's security isn't the right answer.
I dont need to fork it because A) I dont have a horse in this race and B) I dont particularly care either way.
?Then why are you sticking your nose in it?
logind depends on systemd. Gnome depends on logind.
There is a patch made for logind that frees it from systemd dependence (proving it isn't necessary) but it remains external to the systemd project. Note well that the systemd project fully intended that not installing systemd would break your desktop.
So why does systemd insist on being PID 1 or replacing init and scripts at all? My proposal would do neither of those things and so nobody gets pissed off. It's nice to see that you agree that something done the Unix way could easily achieve the same thing as systemd.
So the question remains, why then does systemd insist on doing it wrong to piss people off?
It's init. What input? start or stop. I think we can manage.
If you need it to come up that fast from power off, suspend to disk and be done with it. Neither systemd or sysvinit will beat the time to unsuspend.
In the desktop machine, due to power management, you can for the most part just leave it on. Businesses can easily enough schedule PCs to power on and boot 15 minutes before the start of the workday.
Of course, there are various parallel boot systems that work with scripts.
In debian, it was a split vote among 8 people. That's right, out of the 8 people who voted on systemd, 4 voted against leaving the chairman to break the tie. Is that what you call overwhelming support? Now there is a resolution in discussion which would forbid other packages from depending on systemd and maintain at least the option of other init systems (reachable from the advanced install menu).
Tell me again how overwhelming the support for systemd is in Debian!
If the resolution passes, it wouldn't surprise me if other distros build on the work of keeping dependencies out and also make systemd optional. Otherwise, many of the Debian fork people seem quite serious and are qualified. There's also uselessd. Once that matures, I wouldn't be surprised to see systemd lose support.
Why don't you fork it? Unlike systemd, sysvinit and others aren't designed with a hairball of dependencies that make them hard to replace.
Like what? What seriously cool administrative feature does it offer?
When you answer, you should know that I did some serious hacking on beoboot at one time. Hacking that would have been a lot less feasible had systemd been wedged into the system.
Are you sure? Why did you reboot to fix heartbleed? Why not stop, update, and then start the affected services?
I have some very old binaries (compiled static) that still work just fine. Other than a recentish foobar in glibc that finds older kernels unsettle it's delicate sensibilities (someone needs to lose a finger...) I haven't seen much trouble with careful mixing and matching.
This isn't windows, I can do security updates without rebooting. There are occasionally security updates to the kernel, but not all of them need to be addressed immediately on all systems. A good admin knows which is which. There is a system to update a running kernel as well. Personally I find that all too fiddly and so prefer to reboot when a kernel update is required.
But note, if the update only affects a module, it may be feasible to rmmod and insmod that module alone.
We were here first, YOU fork it.
Failing that, there are at least two approaches in the works to fork it if necessary. One would fork Debian, the other is uselessd to fork systemd into something a bit less pernicious.
And as a result, when you do /etc/init.d/apache stop, apache stops. When you do /etc/init.d/apache start, (drumroll please), apacghe starts. Just exactly what he said.
Honestly, some of the individual rc scripts have become too clever by half. When it becomes too much, I replace it with one that has about 10 simple lines in it and it works great.
But if you find it all too much, answer a question no systemd proponant has yet managed to answer, why not start with the parallel startup in wheezy and add a helper app that runs the daemon in a cgroup and sticks around to manage it? Just stick that in the script like:
...
start) /sbin/manage start apache ;;
stop) /sbin/manage stop apache ;;
You could even do something like /sbin/manage waitfor nfs start apache
All the advantages, none of the problems presented by systemd. When starting, manage could register on dbus as well if desired. The desktop people could use that and the old school people could safely ignore it. Done right, manage need not freak out if dbus isn't running.
Any reason other than failure to force systemd on the world why that shouldn't make both camps happy?
Apparently, it is. At least to the severely damaged palates that have been eating processed crap rather than real food.
Rate limiting would help a LOT, but may not be enough if the bad guys rig up a strong transmitter. If you are in a crowded parking lot, you probably don't much care which BMW you steal, the first one to unlock will be good enough.
It's not like BMWs are bargain basement cars, surely they could have spent a bit on an actually secure keyless entry system.
Sure there's a difference. I don't have genes to produce lignin.
As for the tifton85, you apparently don't know that it is still being used as forage and that it only rarely produces cyanide under stressed conditions, like sorghum and other grasses.
Tifton-85 is also sterile, so unlike some of the GM crops, it isn't likely to spread far (other than via rhizomes).
However, I never said breeding CAN'T go wrong, just that it tends not to go as wrong as quickly. The issues you noted are exactly that warning that you don't get with GM.