Power steering makes your car nearly unturnable if that fails.
Not true -- I've had threads on the pressure side of the pump (where the hose screws in) fail and cause the power-steering fluid to shoot out all over the road. At highway speeds you'd never know the difference, because the wheels are spinning quickly and you're steering gently enough that you're really only moving the wheels at a slight angle for each tire revolution. Less rubber fighting you for each increment of steering angle means easier turning.
You'd start to notice below 30 mph, and it was definitely a pain to parallel-park, but I drove it that way for quite a while before coming up with the money for a replacement pump. In retrospect I should have used a plumbing tape or similar to pad the threads, but I knew I'd be replacing the pump anyways and it really wasn't that big of a problem.
Power breaks provide so much extra breaking power that if they fail, your car is basically going to be nearly brake-less anyway.
Also wrong -- brakes can fail for a few reasons, and I've had many of them. Most systems are split in such a way that if pressure loss results in one end of the system (front or back), the other still has pressure. A bad wheel cylinder, a nick in the brake lines, many things can cause this to happen, and failsafes exist.
If you're losing pressure in the front, it's more serious and you do need additional stopping distance. However, you can stop by pumping the brakes to build pressure manually. I've had vehicles stall such that I've had to do this, and you'd be quite surprised how quickly you can get enough pressure built up to stop the vehicle.
If you lose fluid but the power booster still works, some air in the lines will help you to stop. Again, you'll need some extra distance, but you can stop.
Have you ever driven a car without a power booster? It's not as bad as you seem to think. Many classic cars didn't have power boosters at all. Newer cars use them to assist, but it's an assist, not a replacement.
When I was much younger my sister dated a guy with a compact without power steering, and the times my Crown Vic has been without power steering I've gotten by.
695 sucks. I had a rant about rubberneckers who fear merging and changing lanes, but deleted it for being in such poor taste. 695 is the best example of the need for "slower traffic keep right" laws I can come up with.
If you RTFA on the 'Xen' kernel, you'd see what's news. The Xen kernel supports some Nifty Virtual Machine Stuff which you won't find in a standard kernel
Bzzt. There is no mention of the "Xen kernel" in the articles cited, so it's unclear as to which Fucking Article you're talking about.
Xen is a layer which allows the user to boot multiple operating systems at the same time. It happens to include modifications to the Linux kernel which allow the user to do virtualization stuff that may seem "New and Cool" to the average X86 user who hasn't heard of virtual machines, but is more like "Old and Busted" for those who've heard of IBM outside of the SCO case.
"Since 1972, VM has been providing the capabilities to "virtualize" the complete S/370, S/390, and zSeries architecture allowing a single physical processor to run multiple guest operating system [sic] simultaneously with each guest thinking it has complete control of the system. Historically, MVS and VSE the operating systems most likely to be run as VM guests, but now with the increasing role of Linux in the data center, it is becoming a popular VM guest system as well."
More informative than the links provided is the Xen user documentation, especially sections 2.3.3, 2.4.1, and most of 3.
A good start for reading about the history of VM would be to Google for "IBM VM".
This is true to a large extent, and I realize that correct code is much less likely to be exploitable. However, in certain instances plugging in imperfect code and documenting the shortcomings could allow novice contributors to jump in and help out in ways that don't require tons of knowledge of the code.
I agree quite a lot with the KDE folks, and appreciate the overall quality of their efforts. However, I have heard of the KHTML developers complaining about how few people actively work on the code. Letting a few less-than-perfect patches in and documenting the hell out of the shortcomings would provide the additional features while making it clear where the untrusted stuff lies and giving newcomers a more clear point of entry for helping out.
I agree with the spirit of what they're saying (i.e., people shouldn't assume that Safari development will automatically benefit all KHTML users). I do think that complaining about the lack of quality in Apple's changes is unlikely to result in any practical benefit, and has the added problem of scaring off potential contributors due to the barriers of acceptance implied by all of the complaints. You want integration help? How about starting with a list of patches against the codebase, noting how much modification would have to be done to each in order to integrate into KHTML, and making the information available so that less experienced coders will be able to help?
It's a practical solution that does require some work but brings more people into the code and also keeps Safari and KHTML closer to each other. Apple benefits from the fixes, KHTML benefits from the feature development, more people get to contribute, Slashdot gets less ad revenue from the resultant flamewars and is forced to post something interesting for a change.
From the "About Us" page at computereconomics.com:
Computer Economics is an independent research organization that specializes in providing economic and strategic analysis and data to IT and business executives.
The intended audience here isn't folks installing Debian or ricing out Gentoo, it's people who buy hardware with support contracts and often expect their software to have the same. It's interesting to see that these people are starting to realize the power that vendor lock-in has, and the value in avoiding it.
Stallman has been saying this for years -- with Free software, nobody has control over what you're doing with the software, and everyone has equal access to making improvements and modifications. Anyone can become an expert, and anyone can support it given enough time investment to become familiar with the product. You can shop around for support, and it'll only get better.
In fact, the "Valuing independence" reads quite a bit like an RMS essay, except that it insists on the label "open source" while talking about freedom. Stallman insists on the distinction because while the definitions of "open source software" and "Free software" include many of the same ideas, the term Free software is intended to emphasize the freedom that the user has from operate their machines without being artificially dependent upon others. "Open source" generally has a larger focus on the technical benefits of access to the source code as described in the writings of ESR and Bruce Perens -- "open source" refers to technically better software, while Free refers to software which does not enslave or limit the user.
A few choice quotes from the article:
With most types of software, administration and support costs overshadow initial software license cost and annual maintenance fees--the costs that are minimized by open source.... Therefore, low cost, although important, is not the key advantage of open source....
[S]oftware buyers must feel some level of dependence on proprietary software vendors, from which they desire freedom.
Older versions of open source products continue to be supported through [...] third party support providers as long as there is demand in the marketplace for such support. The key appeal of open source software is that it avoids vendor lock-in and gives buyers the freedom to choose what to do and when to do it.
Don't lock-in buyers and buyers won't be as likely to leave.... For software buyers, the best strategy is to consider mature and established open source products as well as proprietary software products that adhere to open standards. In this way, buyers can choose the best software product... without locking the organization in to a single vendor solution.
Emphasis mine. I think I like the approach of this article overall -- they recommend that IT decision makers consider long-term freedom in their purchasing decisions in a forum whose recommendationd they're more likely to respect.
Out of curiosity, I just searched for a Starbucks near the area where I used to live. The nearest is 15 miles away -- hardly within walking distance (I've walked almost that far, but not for a coffee break), with none closer than that "Coming soon" either.
Right now I'm living in Pittsburgh, but I often miss living in less populated areas because I found it much less distracting without three Starbuck's within walking distance.
I actually walked more when living in the country, but less often, because walking was an excuse to contemplate for a few hours where it's now a twenty minute coffee break.
I agree that it's totally not worth the crowds just to see a [pre/se]qual to some of the most overrated movies of all time. I'll see it in theaters sometime, as it's gotten much more favorable reviews than the train wrecks for which Lucas is recently known, but definitely not while the crowds are in full effect.
However, you cite being "out of town" as a reason for not seeing it in theaters. Just how "out of town" will you be that there won't be a theater showing this nearby?
Good idea, except that to be truly effective they should require a logo of some form to be displayed throughout so that the identification cannot be easily edited away.
The common practice at the moment is to say, 'This is Doug Smith reporting... for the FDA'. They leave in such a gap between 'reporting' and the mention of the government agency that anyone could easily find the right place to cut off the identification, and to leave it intact sounds awkward.
The bill text wouldn't prevent such practice, and thus basically sounds like a nod toward those who made a fuss that won't actually cause anything to change.
No. They are the same type purely mechanical types used in your standard elevator. If the cable breaks on a normal elevator, they also need to have some means of preventing you from plummeting to your death. The same systems are in use. Engineers thought long long ago about power failures during emergencies. You aren't the first to think about it.
...except that the "purely mechanical" safety in a typical elevator depends on cable tension to keep the brakes from activating. When cable tension is lost, the brakes are no longer held back. Thus, if the cable is cut or snaps, the brakes are pressed into action by springs who are now free to expand.
However, you assert that this same mechanism is used in a system which has no cable to provide tension in the first place. Can you explain how this works?
You're damned right -- my most recent card purchase was a PCI Matrox G400. I paid more for it than for other cards that would have served my needs, but when I'd last purchased a card they were willing to provide Free software developers with access to hardware information.
Sadly, they've since closed off access to the specs, even the same information that was available in 1999. They do provide drivers for their AGP cards, but my old Proliant 800 with its lack of AGP is left without a well-supported card. This means that I've got no reason to pay more for Matrox -- I can get better performance elsewhere and still have to deal with closed drivers. I was and am willing to pay more for hardware that I know will work well from a company that will provide hardware specifications. Matrox is no longer that company.
For me, 3D performance isn't worth dealing with non-free software. There's no reason a video card shouldn't be as well-supported as a network card -- it's the lack of willingness to share information that keeps the current hardware back in terms of interoperability.
The current market is supported by those who value 3D performance over interoperability -- if enough people were willing to stop buying closed hardware (closed in the sense that specifications aren't available) we'd see some of the current manufacturers start playing a little nicer.
11) Some might refuse to buy what, according to original copyright terms, should be in the public domain at present anyways.
12) Some might feel that the industry's track record with regards to fairly compensating artists is far from spotless. It's hard to listen to the same industry which will gladly take away the creator's ownership of their works or sell off rights to the highest bidder accuse the public of denying artists fair compensation.
Meta-comment: Slashdot's lack of support for "<ol start=11>" is irritating.
Some people spend 10 hours tweaking compiler settings and optimizations to get an extra 5% performance from their code.
Other people spend 2 hours selecting the proper algorithm in the first place and get an extra 500% performance from their code.
While there's a lot of truth to the idea that some algorithms scale much better than others, there's also the fact that modern CPU architectures require *tons* of bit twiddling to ensure optimal performance, and that's something that a good compiler can do fairly well. Algorithmic choice can mean large differences in runtime; however, a good compiler could realistically improve an inner loop's runtime several times over simply by choosing the best execution path.
Wasting time over 5% is often just that -- wasting time. However, a good compiler should allow an algorithm to use the hardware to its fullest whenever possible.
People will dump tons of time into microoptimization and trying to guess which compiler options will do the best things with a given piece of code. What I don't see is why a firm interested in high-performance code wouldn't invest resources into optimizing the compiler's output... it seems to me that the cost vs. benefit is much more attractive to spend that time actually improving the compiler rather than writing the oft-cited genetic algorithms for choosing a good set of compiler flags and hoping somehow to get amazing results by hitting upon some magic combination.
Spend time tailoring the code to the compiler, and you've fixed the code, once. Teach the compiler to do the right thing, and all of your code will benefit.
To some, the fact that SCO sees Linux as a Unix clone not only makes holding that view morally wrong but requires the immediate repudiation of nonbelievers and indeed the remarketing of Linux as "not Unix"
HAHAHAHAHAHAHAHAHAHAAHAHAHAHAHA!
Okay, follow me here. Linux is a kernel. On top of the kernel lies the rest of the operating system. Most Linux-based systems use the same components to build the core operating system.
What are these other components, you ask? They're provided by the GNU project. In fact, these components are so vital to the production of a UNIX-like operating system that without them, the Linux kernel wouldn't itself be very UNIX-like, as it doesn't provide shells, a C library, and so on.
Any guess as to what GNU stands for? It's "GNU's not UNIX." In fact, at present www.gnu.org is the number one result for a Google search of "not unix".
hankaholic asks, "I have a ton of nails I'd like to pound into a board for a project I've got going. Googling for solutions I just find hardware stores advising me to hit them with a sturdy object, which seems like more an way to damage a blunt object than a real nail-driving measure. What do Slashdot readers do with their nails? With so many construction techniques in today's society, what else do you all use to get those nail-based projects off of the drawing board?"
Buy a cross-cut shredder. As mentioned by someone else, if you're too cheap for that, fire will work as well.
The one thing that people don't necessarily think of is checking their mail in the first place -- I know an older couple whose mail kept getting stolen, and the thief was using the information contained in the mail to do all kinds of things in their names.
If at all possible, ask the companies sending you bills and statements whether there's a paperless option -- I've heard that many companies are now providing statements online with the option to stop mailing you a physical copy. Someone can't steal what isn't produced in the first place.
Is it just me that wonders why science can run along happily trying to create in reality what science fiction has been creating decades before it, yet seemingly blatantly ignoring all the lessons that were there to be learned in the science fiction stories?
This would be more valid if the majority of the sci-fi out there weren't utter crap. You didn't provide more specific examples of non-crap, and spoke quite vaguely of "figuring out the dangers".
Assume teleportation were possible. Would you suggest we ignore it because of the lessons "The Fly" had to teach us? How about AI research? Should we ban that because of the lessons of "The Matrix"? What about genetic engineering? Should we avoid that as well, since obviously Jeff Goldblum insisting that "life will find a way" provides all requires scientific justification as to whether it is truly possible for such biological situations to rear their recombinant heads?
I'm convinced that the appeal of sci-fi is the idea of modeling human behavior in hypothetical situations which are non-threatening viewers who are not social in the traditional sense. As an exercise, watch a ST:TNG episode and wait for the moment when they pull some solution out of their ass and indicate that it's due to some character's abilities (such as those listed above) that the answer was found. Note how little actual science was involved. Turn on the Sci-Fi channel. Think further about how little scientific fact and possibility comprise the typical sci-fi premise.
There's a difference between something a writer pulls out of their ass and scientific possibility or likeliness. It's just a pity that it's a boring sci-fi work which covers the fact that in reality it's a damned hard task to create an organism which can survive outside of the laboratory in ideal conditions, let alone turn the planet into some form of gelatenous goo. The idea of a laboratory-created organism which isn't robust enough to survive simply doesn't make for a very compelling plot unless you're getting into the emotional strain of working hard to produce things which keeps dying despite your best efforts, and that hardly sounds like a sci-fi work to me.
The simple fact is that the further scientists deviate from organisms which exist presently, the more rapidly the long-term viability approaches zero. Genetically engineered corn is still pretty damned close to corn -- no tentacles, no sentience that we've noticed thus far, just corn. There's a reason why most mutations die off -- it's a large combination of factors which are required to allow a species to persist. We are far from understanding these factors in terms of "this protein structure is stable and will generate an organism capable of everything required to survive outside of the laboratory", let alone being able to build it from the ground up.
However, I might be wrong. It might be that science fiction has produced a large body of scientific truths which are best heeded, aside from "don't make Brundleflies or use DNA from animals which are known to change genders to recreate animals which will want to eat us". If that is the case, it would be greatly beneficial if you'd point the uninformed Slashdot masses of which I take part towards a compendium of conclusions. If these truths are not yet compiled in a single place, I encourage you to consider starting a Wiki and saving the planet.
However, it just may be possible that these people aren't total idiots and realize that making, for example, a race of highly reproductive, highly violent, superintelligent monkeys with an insatiable thirst for human blood would probably not further their long-term career goals long before the realization sinks in that the eventual results would converge in some way upon the plotline of "Planet of the Apes".
Many people have added the idea of using PICO or a clone for basic text editing.
I'd like to suggest using joe -- it's a nice editor with a good user interface (in that it's easy to figure out how to use based on the interface, without resorting to man pages/tutorials/etc.). It's got a PICO emulation (invoked with "jpico") for those who insist on using keybindings from a badly licensed editor, but offers more commands than PICO and clones.
It's not guaranteed to be "all the editor you'll ever need", but it offers enough features that the average user will find their requirements to be comfortably met long after they'd have outgrown PICO and been forced to switch editors.
did you ever try to configure a kernel these days?
What is this "these days"? To build a new kernel, you untar the source, copy linux-old/.config to the new linux-2.6.xx directory, run "make oldconfig" (which will ask you only about new configuration items) if you like, make bzImage && make modules && su make modules_install.
It's about eight commands to untar, copy old config, cd into new source directory, configure, build, and update your bootloader (with an extra if you still use LILO). It's the same set of commands it's always been, and you only have to worry about configuration options which are new to the kernel you're building. Good vendors will even provide you their default configuration (Debian does, for instance) so you can start with a known configuration and tailor to your needs.
Some kernels even export the configuration from which they were built as/proc/config or/proc/config.gz, making it easier than ever to start with a given system and tailor it to your needs.
"make oldconfig" and/proc/config* are your friends.
I'm a right-tool-for-the-right-job fan, which means that this question wasn't directed at me. I'll answer the question anyways, because I find the answer interesting.
when was the last time you saw an ATM with an error that wasn't an Window error?
Answer: When it was made by Diebold. I'm not sure what OS they chose for their machines. The maintenance GUI does not look like the Windows widget set, but I can tell you that more often than not I'd get the damned application software to lock up when doing the required daily maintenance on it(*).
You'd be saddened to discover that the same company making those famous voting machines can't seem to produce an ATM that can reliably handle even the simplest of tasks. I'm reminded of Joel Spolsky's essay about eating one's own dog food -- for the tens of thousands of dollars Diebold charges for an ATM (I've heard $50,000, but don't quote me), I'd have expected them to have performed testing to verify basic functionality before shipping the damned things. The customer interface seemed fairly robust, but when it came to maintenance tasks, "reliable" is not a word that comes to mind.
This is not to argue against your claims that Windows isn't reliable -- this is to assert that in my experience, Diebold software is much, much worse.
(*) This including pulling the deposits out for human processing, and "changing it over" into the next business day. This is similar to the teller systems transacting towards the next business day after a given time. Both the teller systems and the ATMs have to be told to finish the day's processing, a process we called "going into late work" for the tellers and "changeover" for the ATM.
Slashdot Mirror
Sarcasm, my good man, sarcasm.
But replies are always good anyways.
How do you know that this version is fuzzy with garbled sound? Huh? HUH?
It's statements like that one that'll get the MPAA a-knockin'.
And Lucas deserves the money as much as P.T. Barnum did. Take that as you will.
I'd assumed that chiming in when browsers are mentioned was part of Opera's EULA.
Thanks for the correction!
Not true -- I've had threads on the pressure side of the pump (where the hose screws in) fail and cause the power-steering fluid to shoot out all over the road. At highway speeds you'd never know the difference, because the wheels are spinning quickly and you're steering gently enough that you're really only moving the wheels at a slight angle for each tire revolution. Less rubber fighting you for each increment of steering angle means easier turning.
You'd start to notice below 30 mph, and it was definitely a pain to parallel-park, but I drove it that way for quite a while before coming up with the money for a replacement pump. In retrospect I should have used a plumbing tape or similar to pad the threads, but I knew I'd be replacing the pump anyways and it really wasn't that big of a problem.
Also wrong -- brakes can fail for a few reasons, and I've had many of them. Most systems are split in such a way that if pressure loss results in one end of the system (front or back), the other still has pressure. A bad wheel cylinder, a nick in the brake lines, many things can cause this to happen, and failsafes exist.
If you're losing pressure in the front, it's more serious and you do need additional stopping distance. However, you can stop by pumping the brakes to build pressure manually. I've had vehicles stall such that I've had to do this, and you'd be quite surprised how quickly you can get enough pressure built up to stop the vehicle.
If you lose fluid but the power booster still works, some air in the lines will help you to stop. Again, you'll need some extra distance, but you can stop.
Have you ever driven a car without a power booster? It's not as bad as you seem to think. Many classic cars didn't have power boosters at all. Newer cars use them to assist, but it's an assist, not a replacement.
When I was much younger my sister dated a guy with a compact without power steering, and the times my Crown Vic has been without power steering I've gotten by.
695 sucks. I had a rant about rubberneckers who fear merging and changing lanes, but deleted it for being in such poor taste. 695 is the best example of the need for "slower traffic keep right" laws I can come up with.
I'm a little unclear on how a developer who implements what will most benefit the client is evil and causes suffering.
Bzzt. There is no mention of the "Xen kernel" in the articles cited, so it's unclear as to which Fucking Article you're talking about.
chet@chet:~$ links -dump http://www.cl.cam.ac.uk/Research/SRG/netos/xen/ | grep -i kernel
chet@chet:~$ links -dump http://cosi.clarkson.edu/xen/ | grep -i kernel
chet@chet:~$
Xen is a layer which allows the user to boot multiple operating systems at the same time. It happens to include modifications to the Linux kernel which allow the user to do virtualization stuff that may seem "New and Cool" to the average X86 user who hasn't heard of virtual machines, but is more like "Old and Busted" for those who've heard of IBM outside of the SCO case.
According to some article sponsored by IBM:
More informative than the links provided is the Xen user documentation, especially sections 2.3.3, 2.4.1, and most of 3.
A good start for reading about the history of VM would be to Google for "IBM VM".
This is effective within a 50 foot radius.
For a slightly higher-tech solution, try this or even this.
This is true to a large extent, and I realize that correct code is much less likely to be exploitable. However, in certain instances plugging in imperfect code and documenting the shortcomings could allow novice contributors to jump in and help out in ways that don't require tons of knowledge of the code.
I agree quite a lot with the KDE folks, and appreciate the overall quality of their efforts. However, I have heard of the KHTML developers complaining about how few people actively work on the code. Letting a few less-than-perfect patches in and documenting the hell out of the shortcomings would provide the additional features while making it clear where the untrusted stuff lies and giving newcomers a more clear point of entry for helping out.
I agree with the spirit of what they're saying (i.e., people shouldn't assume that Safari development will automatically benefit all KHTML users). I do think that complaining about the lack of quality in Apple's changes is unlikely to result in any practical benefit, and has the added problem of scaring off potential contributors due to the barriers of acceptance implied by all of the complaints. You want integration help? How about starting with a list of patches against the codebase, noting how much modification would have to be done to each in order to integrate into KHTML, and making the information available so that less experienced coders will be able to help?
It's a practical solution that does require some work but brings more people into the code and also keeps Safari and KHTML closer to each other. Apple benefits from the fixes, KHTML benefits from the feature development, more people get to contribute, Slashdot gets less ad revenue from the resultant flamewars and is forced to post something interesting for a change.
From the "About Us" page at computereconomics.com:
Computer Economics is an independent research organization that specializes in providing economic and strategic analysis and data to IT and business executives.
The intended audience here isn't folks installing Debian or ricing out Gentoo, it's people who buy hardware with support contracts and often expect their software to have the same. It's interesting to see that these people are starting to realize the power that vendor lock-in has, and the value in avoiding it.
Stallman has been saying this for years -- with Free software, nobody has control over what you're doing with the software, and everyone has equal access to making improvements and modifications. Anyone can become an expert, and anyone can support it given enough time investment to become familiar with the product. You can shop around for support, and it'll only get better.
In fact, the "Valuing independence" reads quite a bit like an RMS essay, except that it insists on the label "open source" while talking about freedom. Stallman insists on the distinction because while the definitions of "open source software" and "Free software" include many of the same ideas, the term Free software is intended to emphasize the freedom that the user has from operate their machines without being artificially dependent upon others. "Open source" generally has a larger focus on the technical benefits of access to the source code as described in the writings of ESR and Bruce Perens -- "open source" refers to technically better software, while Free refers to software which does not enslave or limit the user.
A few choice quotes from the article:
With most types of software, administration and support costs overshadow initial software license cost and annual maintenance fees--the costs that are minimized by open source.... Therefore, low cost, although important, is not the key advantage of open source....
[S]oftware buyers must feel some level of dependence on proprietary software vendors, from which they desire freedom.
Older versions of open source products continue to be supported through [...] third party support providers as long as there is demand in the marketplace for such support. The key appeal of open source software is that it avoids vendor lock-in and gives buyers the freedom to choose what to do and when to do it.
Don't lock-in buyers and buyers won't be as likely to leave.... For software buyers, the best strategy is to consider mature and established open source products as well as proprietary software products that adhere to open standards. In this way, buyers can choose the best software product... without locking the organization in to a single vendor solution.
Emphasis mine. I think I like the approach of this article overall -- they recommend that IT decision makers consider long-term freedom in their purchasing decisions in a forum whose recommendationd they're more likely to respect.
Out of curiosity, I just searched for a Starbucks near the area where I used to live. The nearest is 15 miles away -- hardly within walking distance (I've walked almost that far, but not for a coffee break), with none closer than that "Coming soon" either.
Thanks for the reply!
Right now I'm living in Pittsburgh, but I often miss living in less populated areas because I found it much less distracting without three Starbuck's within walking distance.
I actually walked more when living in the country, but less often, because walking was an excuse to contemplate for a few hours where it's now a twenty minute coffee break.
At any rate, good luck with your studies!
I agree that it's totally not worth the crowds just to see a [pre/se]qual to some of the most overrated movies of all time. I'll see it in theaters sometime, as it's gotten much more favorable reviews than the train wrecks for which Lucas is recently known, but definitely not while the crowds are in full effect.
However, you cite being "out of town" as a reason for not seeing it in theaters. Just how "out of town" will you be that there won't be a theater showing this nearby?
Good idea, except that to be truly effective they should require a logo of some form to be displayed throughout so that the identification cannot be easily edited away.
The common practice at the moment is to say, 'This is Doug Smith reporting... for the FDA'. They leave in such a gap between 'reporting' and the mention of the government agency that anyone could easily find the right place to cut off the identification, and to leave it intact sounds awkward.
The bill text wouldn't prevent such practice, and thus basically sounds like a nod toward those who made a fuss that won't actually cause anything to change.
However, you assert that this same mechanism is used in a system which has no cable to provide tension in the first place. Can you explain how this works?
You're damned right -- my most recent card purchase was a PCI Matrox G400. I paid more for it than for other cards that would have served my needs, but when I'd last purchased a card they were willing to provide Free software developers with access to hardware information.
Sadly, they've since closed off access to the specs, even the same information that was available in 1999. They do provide drivers for their AGP cards, but my old Proliant 800 with its lack of AGP is left without a well-supported card. This means that I've got no reason to pay more for Matrox -- I can get better performance elsewhere and still have to deal with closed drivers. I was and am willing to pay more for hardware that I know will work well from a company that will provide hardware specifications. Matrox is no longer that company.
For me, 3D performance isn't worth dealing with non-free software. There's no reason a video card shouldn't be as well-supported as a network card -- it's the lack of willingness to share information that keeps the current hardware back in terms of interoperability.
The current market is supported by those who value 3D performance over interoperability -- if enough people were willing to stop buying closed hardware (closed in the sense that specifications aren't available) we'd see some of the current manufacturers start playing a little nicer.
A few additions:
11) Some might refuse to buy what, according to original copyright terms, should be in the public domain at present anyways.
12) Some might feel that the industry's track record with regards to fairly compensating artists is far from spotless. It's hard to listen to the same industry which will gladly take away the creator's ownership of their works or sell off rights to the highest bidder accuse the public of denying artists fair compensation.
Meta-comment: Slashdot's lack of support for "<ol start=11>" is irritating.
This has always bugged me.
Some people spend 10 hours tweaking compiler settings and optimizations to get an extra 5% performance from their code.
Other people spend 2 hours selecting the proper algorithm in the first place and get an extra 500% performance from their code.
While there's a lot of truth to the idea that some algorithms scale much better than others, there's also the fact that modern CPU architectures require *tons* of bit twiddling to ensure optimal performance, and that's something that a good compiler can do fairly well. Algorithmic choice can mean large differences in runtime; however, a good compiler could realistically improve an inner loop's runtime several times over simply by choosing the best execution path.
Wasting time over 5% is often just that -- wasting time. However, a good compiler should allow an algorithm to use the hardware to its fullest whenever possible.
People will dump tons of time into microoptimization and trying to guess which compiler options will do the best things with a given piece of code. What I don't see is why a firm interested in high-performance code wouldn't invest resources into optimizing the compiler's output... it seems to me that the cost vs. benefit is much more attractive to spend that time actually improving the compiler rather than writing the oft-cited genetic algorithms for choosing a good set of compiler flags and hoping somehow to get amazing results by hitting upon some magic combination.
Spend time tailoring the code to the compiler, and you've fixed the code, once. Teach the compiler to do the right thing, and all of your code will benefit.
Shortsighted bastards, all of them.
To some, the fact that SCO sees Linux as a Unix clone not only makes holding that view morally wrong but requires the immediate repudiation of nonbelievers and indeed the remarketing of Linux as "not Unix"
HAHAHAHAHAHAHAHAHAHAAHAHAHAHAHA!
Okay, follow me here. Linux is a kernel. On top of the kernel lies the rest of the operating system. Most Linux-based systems use the same components to build the core operating system.
What are these other components, you ask? They're provided by the GNU project. In fact, these components are so vital to the production of a UNIX-like operating system that without them, the Linux kernel wouldn't itself be very UNIX-like, as it doesn't provide shells, a C library, and so on.
Any guess as to what GNU stands for? It's "GNU's not UNIX." In fact, at present www.gnu.org is the number one result for a Google search of "not unix".
hankaholic asks, "I have a ton of nails I'd like to pound into a board for a project I've got going. Googling for solutions I just find hardware stores advising me to hit them with a sturdy object, which seems like more an way to damage a blunt object than a real nail-driving measure. What do Slashdot readers do with their nails? With so many construction techniques in today's society, what else do you all use to get those nail-based projects off of the drawing board?"
Buy a cross-cut shredder. As mentioned by someone else, if you're too cheap for that, fire will work as well.
The one thing that people don't necessarily think of is checking their mail in the first place -- I know an older couple whose mail kept getting stolen, and the thief was using the information contained in the mail to do all kinds of things in their names.
If at all possible, ask the companies sending you bills and statements whether there's a paperless option -- I've heard that many companies are now providing statements online with the option to stop mailing you a physical copy. Someone can't steal what isn't produced in the first place.
This would be more valid if the majority of the sci-fi out there weren't utter crap. You didn't provide more specific examples of non-crap, and spoke quite vaguely of "figuring out the dangers".
Assume teleportation were possible. Would you suggest we ignore it because of the lessons "The Fly" had to teach us? How about AI research? Should we ban that because of the lessons of "The Matrix"? What about genetic engineering? Should we avoid that as well, since obviously Jeff Goldblum insisting that "life will find a way" provides all requires scientific justification as to whether it is truly possible for such biological situations to rear their recombinant heads?
I'm convinced that the appeal of sci-fi is the idea of modeling human behavior in hypothetical situations which are non-threatening viewers who are not social in the traditional sense. As an exercise, watch a ST:TNG episode and wait for the moment when they pull some solution out of their ass and indicate that it's due to some character's abilities (such as those listed above) that the answer was found. Note how little actual science was involved. Turn on the Sci-Fi channel. Think further about how little scientific fact and possibility comprise the typical sci-fi premise.
There's a difference between something a writer pulls out of their ass and scientific possibility or likeliness. It's just a pity that it's a boring sci-fi work which covers the fact that in reality it's a damned hard task to create an organism which can survive outside of the laboratory in ideal conditions, let alone turn the planet into some form of gelatenous goo. The idea of a laboratory-created organism which isn't robust enough to survive simply doesn't make for a very compelling plot unless you're getting into the emotional strain of working hard to produce things which keeps dying despite your best efforts, and that hardly sounds like a sci-fi work to me.
The simple fact is that the further scientists deviate from organisms which exist presently, the more rapidly the long-term viability approaches zero. Genetically engineered corn is still pretty damned close to corn -- no tentacles, no sentience that we've noticed thus far, just corn. There's a reason why most mutations die off -- it's a large combination of factors which are required to allow a species to persist. We are far from understanding these factors in terms of "this protein structure is stable and will generate an organism capable of everything required to survive outside of the laboratory", let alone being able to build it from the ground up.
However, I might be wrong. It might be that science fiction has produced a large body of scientific truths which are best heeded, aside from "don't make Brundleflies or use DNA from animals which are known to change genders to recreate animals which will want to eat us". If that is the case, it would be greatly beneficial if you'd point the uninformed Slashdot masses of which I take part towards a compendium of conclusions. If these truths are not yet compiled in a single place, I encourage you to consider starting a Wiki and saving the planet.
However, it just may be possible that these people aren't total idiots and realize that making, for example, a race of highly reproductive, highly violent, superintelligent monkeys with an insatiable thirst for human blood would probably not further their long-term career goals long before the realization sinks in that the eventual results would converge in some way upon the plotline of "Planet of the Apes".
Many people have added the idea of using PICO or a clone for basic text editing.
I'd like to suggest using joe -- it's a nice editor with a good user interface (in that it's easy to figure out how to use based on the interface, without resorting to man pages/tutorials/etc.). It's got a PICO emulation (invoked with "jpico") for those who insist on using keybindings from a badly licensed editor, but offers more commands than PICO and clones.
It's not guaranteed to be "all the editor you'll ever need", but it offers enough features that the average user will find their requirements to be comfortably met long after they'd have outgrown PICO and been forced to switch editors.
What is this "these days"? To build a new kernel, you untar the source, copy linux-old/.config to the new linux-2.6.xx directory, run "make oldconfig" (which will ask you only about new configuration items) if you like, make bzImage && make modules && su make modules_install.
It's about eight commands to untar, copy old config, cd into new source directory, configure, build, and update your bootloader (with an extra if you still use LILO). It's the same set of commands it's always been, and you only have to worry about configuration options which are new to the kernel you're building. Good vendors will even provide you their default configuration (Debian does, for instance) so you can start with a known configuration and tailor to your needs.
Some kernels even export the configuration from which they were built as
"make oldconfig" and
I'm a right-tool-for-the-right-job fan, which means that this question wasn't directed at me. I'll answer the question anyways, because I find the answer interesting.
Answer: When it was made by Diebold. I'm not sure what OS they chose for their machines. The maintenance GUI does not look like the Windows widget set, but I can tell you that more often than not I'd get the damned application software to lock up when doing the required daily maintenance on it(*).
You'd be saddened to discover that the same company making those famous voting machines can't seem to produce an ATM that can reliably handle even the simplest of tasks. I'm reminded of Joel Spolsky's essay about eating one's own dog food -- for the tens of thousands of dollars Diebold charges for an ATM (I've heard $50,000, but don't quote me), I'd have expected them to have performed testing to verify basic functionality before shipping the damned things. The customer interface seemed fairly robust, but when it came to maintenance tasks, "reliable" is not a word that comes to mind.
This is not to argue against your claims that Windows isn't reliable -- this is to assert that in my experience, Diebold software is much, much worse.
(*) This including pulling the deposits out for human processing, and "changing it over" into the next business day. This is similar to the teller systems transacting towards the next business day after a given time. Both the teller systems and the ATMs have to be told to finish the day's processing, a process we called "going into late work" for the tellers and "changeover" for the ATM.