Having an "enabled" and "disabled" state for services is thus a very good idea.
man update-rc.d - disabling a service is as easy as update-rc.d -f remove . Re-enabling the service has a specific syntax to give the runlevels you want it started in, as well as its order number in that runlevel. You could put this in a fancy GUI if you wanted.
This thinking implies that a lack of a degree makes one unworthy of consideration for employment.
You are correct that his statement could be read two different ways. You read it that anyone without a degree is instantly eliminated, where I think of it in terms of a stack; the degrees are at the top of the stack for first consideration, and the non-degrees are at the bottom, which is likely to never be reached simply due to the vast number of applicants who do have degrees and are thus going to be considered first.
Aside from helping to prove my own point, where your would-be refutation falls short is that while having a BS is evidence that a person may be motivated, it "does not constitute proof" that one is motivated or (pick your adjective).
Again, you are correct. I should have added a BS from an accredited university and/or an institution where the employer has had a positive history of hiring useful candidates from. A BS constitutes proof that the individual met the standards of the particular school he went to, which may or may not match the standards of the employer. This is why having a wide variety of extracurricular activities and previous employment on a resume is important, because it makes your package even more convincing.
Not hiring a non-degree candidate may be a hasty generalization or it may be based on past experience. It's difficult to convincingly berate employers in general for ignoring non-degree candidates, because their choice whether or not to do so is entirely dependent on their experiences with such candidates as well as the demands of their particular environment.
Actually, as of right now you're correct, since testing is being used for the sarge release freeze. There used to be a 'frozen' distro that was used for release QA before becoming stable, but for some reason frozen and testing have been merged. I don't particularly like that approach.
A better approach would be to use smartctl -t long/dev/hda and let the drive test itself. Modern drives will mask many errors from the user, so your badblocks test will gloss over problems that a firmware test would report.
RenderAccel has nothing to do with 3D games, it is enabling using 3D hardware to accelerate the XFree86 RENDER extension, typically used e.g. by Freetype to render anti-aliased fonts.
testing is a better choice for a desktop. Unstable eventually will bite you one way or the other. I use unstable on my development machine just to stay bleeding edge with everything. My desktops are testing, and my servers are stable with automatic security updates as I mentioned.
That's a bad idea. You'll pull in things that aren't necessarily security updates, e.g. if a new stable release is made. I use cron-apt and have it daily install only patches from security.debian.org. That way I don't have to intervene, and my system is guaranteed not to break because of a security update.
By your logic a person is unmotivated and has no work ethic just because they haven't a big B.S. tatooed on their forehead.
No, you're reading something that isn't there. Lack of proof of a claim does not constitute proof of the contrary. In other words, having a BS is evidence that you are motivated. But not having a BS doesn't mean you are not motivated. And no reasonable employer would think this, but that doesn't keep them from going with the safe bet, the BS.
The system software on IA-32 has no control over what is stored in the cache aside from invalidating it. The fact that one OS would run on cache that another wouldn't is pure coincidence, not a metric of tolerance of bad hardware. Flakey peripheral hardware on the other hand you will find consistently more useful in open source systems because users send in their custom workarounds to be included in the drivers. Also, you can use bad RAM in Linux by telling the kernel not to use the defective regions.
However it's clear that if smoking had been banned a long time ago, fewer people would have died as a result.
How's that? You assume that fewer people will smoke under prohibition. Obviously, if you look at the history of alcohol and drug prohibition, that is not a reasonable assumption.
Opera is an excellent piece of proprietary software.
It follows open standards.
There is no file format lock-in; configuration files, bookmarks, etc are plaintext.
It is available for multiple hardware platforms and operating systems.
It is well-supported with newsgroups and a bug tracker.
It is reasonably priced proportional to the competition.
With each upgrade comes significant new features.
Put that all together with a company which is clearly committed to producing a quality product instead of megalomania, and it's really hard to build a case against Opera, aside from it being under a proprietary license with no source code available.
No, he's saying that a proper IP stack will not respond to a request for service from a TCP/UDP port that has no service listening to it on that machine.
He's wrong; this would be in violation of the RFC. A "proper" stack would respond by refusing the connection, not by blackholing the request.
Sure, if you want to run 5-years-old G-series hardware. They have completely abandoned Linux aside from a poorly maintained x86 binary driver for their new cards.
That'd be strange, considering PPC is an open architecture with freely available documentation, and Gassee was ex-Apple CEO. You're telling me he pulled zero weight with his old company on getting documentation, for an open architecture, in an effort that would only sell more Apple hardware in the end?
One thing in userland that could really use looking at is PAM. Its design is utterly archaic and fraught with gotchas, while the overall idea remains obviously useful and popular. If PAM were more useful and secure, Linux systems would by extension be more useful and secure.
It's also called smartmontools in a lot of distros.
You can use Grub over a serial console.
Not hiring a non-degree candidate may be a hasty generalization or it may be based on past experience. It's difficult to convincingly berate employers in general for ignoring non-degree candidates, because their choice whether or not to do so is entirely dependent on their experiences with such candidates as well as the demands of their particular environment.
Actually, as of right now you're correct, since testing is being used for the sarge release freeze. There used to be a 'frozen' distro that was used for release QA before becoming stable, but for some reason frozen and testing have been merged. I don't particularly like that approach.
A better approach would be to use smartctl -t long /dev/hda and let the drive test itself. Modern drives will mask many errors from the user, so your badblocks test will gloss over problems that a firmware test would report.
RenderAccel has nothing to do with 3D games, it is enabling using 3D hardware to accelerate the XFree86 RENDER extension, typically used e.g. by Freetype to render anti-aliased fonts.
testing is a better choice for a desktop. Unstable eventually will bite you one way or the other. I use unstable on my development machine just to stay bleeding edge with everything. My desktops are testing, and my servers are stable with automatic security updates as I mentioned.
I think you're confused. Calculus is mathematics; it is irrefutable. The scientific theory of evolution is not nearly as solid.
That's a bad idea. You'll pull in things that aren't necessarily security updates, e.g. if a new stable release is made. I use cron-apt and have it daily install only patches from security.debian.org. That way I don't have to intervene, and my system is guaranteed not to break because of a security update.
STOPCLK? Don't you mean HLT? STOPCLK is a bus signal, not an instruction.
The system software on IA-32 has no control over what is stored in the cache aside from invalidating it. The fact that one OS would run on cache that another wouldn't is pure coincidence, not a metric of tolerance of bad hardware. Flakey peripheral hardware on the other hand you will find consistently more useful in open source systems because users send in their custom workarounds to be included in the drivers. Also, you can use bad RAM in Linux by telling the kernel not to use the defective regions.
Um, how is a 4MB aperture the "sanest" setting? A tiny aperture will utterly cripple AGP performance.
- It follows open standards.
- There is no file format lock-in; configuration files, bookmarks, etc are plaintext.
- It is available for multiple hardware platforms and operating systems.
- It is well-supported with newsgroups and a bug tracker.
- It is reasonably priced proportional to the competition.
- With each upgrade comes significant new features.
Put that all together with a company which is clearly committed to producing a quality product instead of megalomania, and it's really hard to build a case against Opera, aside from it being under a proprietary license with no source code available.That'd be strange, considering PPC is an open architecture with freely available documentation, and Gassee was ex-Apple CEO. You're telling me he pulled zero weight with his old company on getting documentation, for an open architecture, in an effort that would only sell more Apple hardware in the end?
The WinAMP source was opened a long time ago. See http://www.wasabidev.org/.
One thing in userland that could really use looking at is PAM. Its design is utterly archaic and fraught with gotchas, while the overall idea remains obviously useful and popular. If PAM were more useful and secure, Linux systems would by extension be more useful and secure.
Yes you can. If you have a shielded cable and connect the shield on both ends, you have just created a ground loop.
Please post a link to the lists where you brought this issue up and a developer responded as you claim.