There's an rc file for each runlevel, and switching between them causes the appropriate file to get run.
Say you want to switch from one multiuser runlevel to another, (admittedly not as common, but it's what init and runlevels are for). Say they're runlevels 2 and 3. Daemons foo, bar, and baz run in both runlevels. quux runs only in runlevel 2, and qiix runs only in runlevel 3.
A sysvinit setup will, when going from runlevel 2 to 3, stop quux and start qiix, without stopping or starting anything else.
Where is the information stored in Slackware's rc scripts to do this?
*sigh*, if only that was consistent. Not everything responds to -HUP appropriately, and some things simply will not reread config files unless you stop/start them (the NFS daemons didn't even handle this correctly until August 1998).
Plus, looking up the PID isn't convenient, and killall can be dangerous to use if you don't know what you're about to kill.
There isn't an easy Makefile (etc) script to tie together all the downloading, installing dependancies, compiling, and package installation, but it's far more automatic and consistent than doing everything by hand.
Get the.dsc,.diff.gz, and.orig.tar.gz You can do this with either 'debget packagename' or 'apt-get source packagename', or any ftp client or web browser.
Extract and patch the tarball dpkg-source -x.dsc
Mess around with whatever you were going to mess around with
Build the package (apt-get source -b packagename will extract and build for you), or you can run debian/rules binary
It's more difficult for a random package to include itself (or remove itself!) in the system's startup if it has to put a few lines in a shell script. Definately easier from a distribution maker's point of view to plunk a file down in/etc/init.d and make some symlinks using update-rc.d.
Slackware's init scripts don't handle switching between runlevels well, either. The info on what needs to be stopped and started just isn't there.
Also,/etc/init.d/randomservice restart is a big convenience for an admin.
Yes, your hypothetical virus could drop you into a fake bash that looks just like real bash, then also present you a fake su, capture your password, then run the command you wished under the real su transparently as well as do whatever it was gonna do as root.
Luckily the kernel sysrq feature has a secure attention key (for the console anyway), all you have to do is get in the habit of using it.
If electric motors were inefficient, this would be a great competition that would spur advances in motor technology. But motors are already 90-95% efficient.
If batteries were unable to give massive amounts of current, this competition would spur advances in battery technology. But your average lead-acid car battery can already pump 600 amps, and NiCad cells have an even lower internal resistance (a single D-cell sized NiCad rechargable can put out 50 amps).
No, the problem with electric vehicles is the combination of power and range. Battery technology today simply cannot store a tenth of the energy that is stored chemically in a modest tank of gasoline. I don't see these competitions as improving this.
Ok, so you can link Qt to GPL apps. Can you link GPL apps to Qt though?
The grounds are unlikely but possible. A copyright holder of an originally-non-Qt'd GPL app would have to file a suit against someone who was distributing (GPL covers distribution) the Qt version of the app.
Slashdot Mirror
The RIAA is going after Superpimp, authors of pan.
Luckily, we've put the constitution in charge of granting us rights rather than Microsoft.
If you have a picture of a 1500 watt PEP ham amp mounted in your car, that's just something I've got to see.
On the other hand, if you have a centimeter-band yagi running 5 watts, that'd be pretty cool too :)
Say you want to switch from one multiuser runlevel to another, (admittedly not as common, but it's what init and runlevels are for). Say they're runlevels 2 and 3. Daemons foo, bar, and baz run in both runlevels. quux runs only in runlevel 2, and qiix runs only in runlevel 3.
A sysvinit setup will, when going from runlevel 2 to 3, stop quux and start qiix, without stopping or starting anything else.
Where is the information stored in Slackware's rc scripts to do this?
Plus, looking up the PID isn't convenient, and killall can be dangerous to use if you don't know what you're about to kill.
It also states that binaries shouldn't go in /var/lib :)
You can do this with either 'debget packagename' or 'apt-get source packagename', or any ftp client or web browser.
dpkg-source -x
(apt-get source -b packagename will extract and build for you), or you can run debian/rules binary
dpkg -i file.deb
Debian users do, those who track unstable do it rather often in fact :)
Usually if you get bit by something, it's not because of an improper install, it's because the new libc behaves differently.
Slackware's init scripts don't handle switching between runlevels well, either. The info on what needs to be stopped and started just isn't there.
Also, /etc/init.d/randomservice restart is a big convenience for an admin.
-- Former Slackware user :)
Luckily the kernel sysrq feature has a secure attention key (for the console anyway), all you have to do is get in the habit of using it.
Have fun getting your new toy to spread :P
You can't ptrace setuid processes, and if you ptrace the parent bash process, you don't get the keystrokes from the su process.
If batteries were unable to give massive amounts of current, this competition would spur advances in battery technology. But your average lead-acid car battery can already pump 600 amps, and NiCad cells have an even lower internal resistance (a single D-cell sized NiCad rechargable can put out 50 amps).
No, the problem with electric vehicles is the combination of power and range. Battery technology today simply cannot store a tenth of the energy that is stored chemically in a modest tank of gasoline. I don't see these competitions as improving this.
The grounds are unlikely but possible. A copyright holder of an originally-non-Qt'd GPL app would have to file a suit against someone who was distributing (GPL covers distribution) the Qt version of the app.
I'd imagine the Celeron 450 was running at 100mhz bus speed though... 66mhz to 100mhz is a 50% bus speed increase.
What everyone else is saying is that that is the case with KDE.