>IBM still obtains boku bucks
The word you're looking for is "beaucoup." You seem super-high.
Might have been trying to say "goku". That would make GP super-saiyan.
I'm a web programmer who loves Linux,
but the kernal and start-up are still black magic to me.
SysV init is really quite simple. Just a few minutes playing around with it on a system and you'll get the hang of it. First off, there are several run-levels. Let's focus on just one run-level for now since most people only ever edit one (they'll use run-level 0: shutdown, and run-level 6: reboot, unknowingly). Within each runlevel directory (let's choose
Maybe an init system can be simple. I don't understand why even shell scripts are needed. Seems like they should be the exception, not the rule.
Editing init scripts is the exception, but because it happens enough times, the scripts should exist as a rule. Scripts allow for high-configurability while keeping some level of separation. The things ntpd does on startup could be parameters, and even the above ntpdate functionality (which is considered bad form in the ntp world: trusting the network time too greatly) could be compiled into the ntp daemon. But who wants to include every hack every sysadmin comes up with for their own environments in the main codebase for ntpd? And who amongst all the sysadmins wants to recompile ntpd for every change and essentially maintain their own fork? Not to mention the differences between distributions for configuration file locations, log files, etc. It's much easier to use scripts as that happy medium where sysadmins can edit without need for constant recompiles.
Why not one big super-script then...
Seems like configuration should be a single file that lists the programs to start from top to bottom
...this violates the separation principle. And would be slightly annoying too. It's easier to handle the individual scripts for their respective daemons than it is to isolate the section that is needed, and as pointed out before, a mere list of executable paths isn't enough, even with parameters; not configurable enough. Let's say you make a change on server 1's init script for ntpd. Now you want to copy that configuration to all 10,000 servers you have. Easy-peasy for a specialized init-script (assuming they're all the same distro and version): just copy the file to every machine and restart ntpd. But with a monolithic script, if you copy it to every machine, you'll be copying entries for daemons that the other servers might not have, or worse: removing entries for vital daemons on the target servers. Keeping them separate is best. Just as keeping them highly configurable is best.
We know how to induce fusion via a multitude of methods. The thing is, none of them are net positive in energy production. None. Of. Them.
H-bombs are fairly net positive. Slightly uncontrolled, but it's a start.
Yes. DCAU, along with Jeffrey Combs, took the Question and made him into a star.
And created Harley Quinn from whole cloth.
My gradnfather fought in a real war. From what he told me, it was nothing like this.
Some great uncles of mine were on the beach at Normandy. One of them got a blueprint copied directly from his entire left leg. He survived, but only because a quick thinking medic was able to replace it with a pin-up from the landing craft. He still gets compliments on that leg.
The first thing I learned about storing passwords is that you use a salted hash, which is impossible to decrypt back into plaintext. Am I missing something, or is this practice not standard practically everywhere now?
Apparently you are missing something because while common practice, it's not ubiquitous. And like all common practices, it gets spoken of less and less until new developers reinvent the wheel and decide they want passwords in plain text to make password recovery 'easier' ("click on the http link in your email and you'll see your password!")