"meaning that these "people" would not be capable of speech or abstract thought (or really much more than rats or similar-sized animals are capable of)."
Brains are not equal. A parrot does a lot with a tiny brain for example. I think the rest of the argument is more compelling
"
No need to announce your arrival any more than your departure, just fuck off
Yes, you trolls certainly are small people.
That's a great concept of a plan!
So as long as they can keep secrets until they get approval they're home free? This is as thoughtless as all of your proposals.
You are begging the question.
The answer to that question is no.
And yet precisely none of the data indicates it as such. Not trends, not current values.
Tried looking at wealth inequality?
You thought what? Are you trolling? You're claiming you saw me, karmawarrior, on the Debian mailing list?
No, here on Slashdot.
sysvinit is literally why virtually every Linux distribution has had rescue disks since the beginning. Even Windows doesn't come with one.
IME, grub is that reason.
Literally an NFS mount not mounting in
You should have noauto in your options. Or today, better yet, use autofs.
The entire Unix world disagees that a set of fragile shell scripts is a great way to boot an operating system. That's why Mac OS X uses LaunchD/SystemStarter, and why the majority of BSDs have switched from a tightly written non-modular shell script intended (bypassing sysvinit altogether) to OpenRC
You mean where they're still using scripts?
Your anecdotal evidence that systemd once crashed on you but you somehow never ever had an unbootable Linux system with sysvinit suggests you've never actually maintained a serious Unix-like system with any complexity.
I've been maintaining serious Unix-like systems since I was a teenager, when at home I had a Sun SLC netbooting Xkernel from a 486 running Linux so I could run Netscape on a fanless system by my bed. Now I run Devuan with root on encrypted ZFS for funsies. You don't need to tell me about boot problems. I just don't blame my problems on sysvinit because I know which components are actually responsible, and it has never failed me. It does one job and does it well. I too have had my system be problematic because I could have done better with my fstab, but that's not sysvinit's fault.
You're pretty weird. Are you mad that he doesn't take your bait so you're going to come at me or what? Unfortunately, you are pretty boring. If you would like to make me mad, please come up with some new material. Peace!
Sure, that's a reasonable approach, if you can keep it up. But evidence says we can't.
"Capitalism forces the worst people to keep each other in check."
Yeah we can see how well that works when they all go fuck kids on the same island.
I now conservatives will squirm at the very thought of giving a living wage to someone who doesn't work for it.
Which is ironic because they completely do support that happening for the owning class, but not for them, even though they are promoting their own demise by supporting that class.
But sure maybe THIS TIME will be different right?
This time is already different. You don't need a crystal ball, you need glasses.
Claimed by whom?
The people at Debian who chose to adopt systemd with less than the usual amount of debate, and at other distributions as well. I thought you participated in these discussions at the time? Guess not.
sysvinit has been responsible for a number of unbootable environments over the years personally speaking, while I've always been able to log into a systemd system
sysvinit has never stopped me from booting, but systemd has. In fact I got into a situation where in order to troubleshoot booting, I would have had to use a debugger. That's when I noped out forever.
Pick something. Just not sysvinit. The latter hasn't been appropriate since the 1990s, it's ridiculous we continued using it as long as we did.
sysvinit with startpar and the LSB-derived daemon management boilerplate is more than adequate. If you want to use another init system, feel free, but there is absolutely no justification for deprecating sysvinit. You do not need sleep commands, you need to read the headers of some init scripts and see that they contain dependency information, then use dependency chaining to ensure that scripts fire in the correct order. It's really not different from filling out the appropriate fields of a unit file.
"Being against torture ought to be sort of a multipartisan thing." -- Karl Lehenbauer, as amended by Jeff Daiell, a Libertarian
