Free means no restrictions, ironic the FSF's GPL forces restrictions, isn't it? What's your definition of free?
First off, we all believe in the basic idea of copyright here, even the gnu hippies. He who creates something is allowed to dictate the terms under which it is sold or used for gain. If *you* would like to write some software and release it to the public domain, you are more than free to do so.
Some people of the FSF mind have a different plan, which is "I want to release my work to the public domain for people to use, but I don't want someone then taking advantage of my generosity by adding a small tweak to my idea and selling it at a greedy profit - therefore I'll place a copyright restriction which dictates that you can only redistribute my work (plus your derivations of it) under the same original free terms, to keep the greedy people from taking advantage of my contribution."
Then there's people like you, who are handed this freebie which has anti-greediness protections, and bitch about it not being fully free. Please, cry me a river. The authors of whatever GPL program you'd like to make money derivating could have just locked their code up and sold it proprietary. Instead they gave you a limited free gift, and you're bitching about the limits. Go write your own damn code, and you can be as public domain or greedy as you want to be with it.
Yeah no shit. If you buy anything at Fry's, ever, make sure it appears to be sealed from the manufacturer and doesn't have a little white Fry's tag on it that's supposed to have the details of why it was returned. My best guess based on experience is that they start out with a stock of new items, and anything that gets returned to them (for any reason, be it they didn't want it, bought the wrong model, or the product was buggy or flat out broken), they do their best to repackage it, stick on of those tags on it, and put it back out with the new goods. Sometimes it's obvious (motherboards in boxes that look like they've been run over by a car, with half the docs and cables missing and a big sticker on the front that says returned), and sometimes it's not.
They do the same thing with memory simms, only there's no way to tell based on packaging. Basically if they sell a bad stick (a small percentage of all memory sticks sold will be bad), and the customer actually uses a memory tester and figures it out and returns it, they put it right back into stock (they claim they test em first, but I don't think they do). As a result, the available pool of simms of any given type that you buy from at Fry's has a considerably higher rate of defects than average.
I'd think before you even start messing with all the other things you say they do, the most fundamental step in securing your linux box is to type "netstat -anp|grep LISTEN", and be able to account for every line you see. Know what process is listening to what ports on what interfaces, and why, and ask yourself whether the ones which seem to be facing the broader internet should be. Disable various services from your startup scripts and/or modify config files as neccesary until it you get it down to where it should be. This is the most basic of security measures against network-based attacks, and one often not even looked at by people who try many other more complicated methods of securing the system.
On this first model, these watch faces are in black and white. But Fossil is looking into a model with variable color faces and is considering creating a Web site where users could download new and different watch faces, or even post watch faces they have created themselves. You could imagine watch faces with various logos, slogans or photos.
Yeah, I can imagine Wal-mart selling them at a 30% discount with a permanent Wal-mart logo face. And then I can imagine someone writing a De-WalMart hack to replace the logo, and going to court for violating the DMCA because they thwarted the rot13 encryption neccesary to bypass the logo lock. Same shit, different year.
You're right it sounds like bad policy. I guess what you're fighting there is that who's authorized changes quickly and the system isn't designed to facilite rapidly changing permissions. Perhaps medical works and patients should have mag cards on them in a hospital, where they can scan into terminals in the room to indicate who's treating who at what time? Then you could set policies based on scans (if a Dr has a scan record with this patient within X hours of a recorded event in their patient history, grant access...)
I may not have done a good job of explaining, but you've done a good job of tearing me apart on bad grounds. I'm not a babbling audiophile. I don't own any high end stereo equipment. I am a former musician, I do understand the harmonics that instruments create, and what I'm saying does have validity.
Audio waves do interfere with each other while reflecting off of a surface, as noted more precisely in another response.
Any yes, there's lots of stereo equipment out there that *will* reproduce sounds that most ears can't hear. I believe many speakers typically respond up to 40khz, and of course "CD-quality" audio samples at 44khz, which effectively sets a maximum frequency for it. Most humans (unless they have very good, young, undamaged hearing) can't discern things beyond 20khz, maybe 25 at best for joe average. However, the sounds in the 30's that will come out of a standard recording into your living room do affect the tone your brain ends up processing, like it or not.
These are just another tool, which when employed with other layers of tools, *may* help provide you some circumstantial evidence of malintent.
As noted in other comments, if you just put in some trigger to notice on the database system itself if anyone access JFK's record - well, if the database system is compromised, the trigger can be bypassed as well. It will catch only "legit" accesses without system compromise - as in someone pulling the record through a normal interface such as a hospital records application, in which case the failure was on the part of whoever implemented your security policies and allowed the record to be accessed through this interface, it was not a hack.
The more interesting usage is the fake SSNs and CCs. These could prove more useful it would seem. If 5% of the credit cards in your company's database are known-fakes, and you register these known-fakes with Visa/MC centrally, then even if your DB was infiltrated carefully, they'll be caught when they try to use the numbers by Visa or MC themselves, a seperate system unlikely to have been simultaneously compromised.
But for numbers like SSNs and CCs, this really isn't a solution, it just raises the bar a notch. If this were common practice, then the intelligent theif would rip off CC databases from 2-3 seperate major retailers and compare them to figure out which were dupes. If there was a central list of fake cards from Visa that everyone used so that they matched, you'd just have to work at another company that also used the dupe list to have your own copy of the numbers to avoid. In the case of SSNs, before you go off using them for malicious purposes, you'd probably compare them against another database from state driver records or some such thing to filter out the bad ones...
In other words, you've made their job a bit harder, but it's not a magic bullet by far, nothing ever will be.
I'm no acoustics expert, but I know enough to know that in the case of audio, those higher harmonics which the human ear cannot hear still make a difference. So I'm going to take the time to lay down some education:
Natural harmonics:
First you have to understand what the hell a harmonic is. When a Violin plays a single "C" note alone, there is actually a subtle chord being made by the instrument which gives a distinctive nature to the sound. At a much reduced volume than the C being played that you mainly "hear", there's some related notes at specific intervals above that note (for those with a music theory background, the intervals are X octaves off of the main note, and then further can be the same note or up a maj 3rd, a fifth, etc... standard harmonic intervals like piano chords) which are also coming out of the instrument at a much lower volume. These intervals continue upwards well out of human hearing range, decreasing in volume as you go. While they're not consciously audible, they do change the tone of the instrument. When you hear two violins that sound "different" than each other, some of that is the waveform of the sound itself, and some of the difference is the varying volumes of different harmonics, which change with differences in instrument shape and composition.
These same tone-altering "harmonics" can also be produced by interferences between the various notes being played by several different instruments. Again these affect the tone of what you hear, and again they also go beyond hearing range.
Now in both cases, in a naive sense you could say that once the harmonics cross the boundary of human hearing, they no longer contribute to the tone you hear, therefore the ones up that high are irrelevant to everyone but geeks with frequency counting equipment.
However, you'd be wrong. Again because of the same types of interference, and also because tones can be modulated by the surfaces they reflect off of (including those in your head), and can affect each other at reflection points, the reproduction of those beyond-hearing harmonics (especially in any multi-speaker reproduction) does alter the human-hearable part of the tone that your brain ends up perceiving.
Also, if you ever wanted to record high pitched music for your dog to listen to, you'd be SOL with human-range recording and playback equipment, so do it for the dogs' sake.
is my general response - this is no longer the stock option era we were in before.
But for a datapoint from the past, at WorldCom the "good" package for well-liked VPs and senior technical staff was worth on average about 150-250k/year pre-tax value after cashing them out (if you did so immediately). Of course that's all very rough numbers, dependant on values that they could have only vaguely predicted. They were good for another 7 years afterwards which could have led the values much higher, or could have led the values way below zero (as happened to be the actual case for those who didn't cash out back when they had the chance).
The "standard" package they gave virtually every full-time employee by contrast was worth on the order of 5-15k I think (I don't remember for sure what they were valued at).
Everyone tries to replace make and freinds, and everybody fails. (Well, at least fails to be a true replacement that's actually better in every way). A few small tweaks aside, you can't really make serious design improvements to the standard unix make and related tools without taking some large tradeoffs that make it unacceptable for at least some uses. It's a very flexible tool as it stands, and it's hard to make it better without losing that flexibility.
I sometimes wish I could make a single collective response to all the responses to a post I've made, I'll have to settle for responding to this one and hoping the rest will look around the conversation.
To further define the question, you have to ask yourself "What do I mean by the term '64-bit Operating System?'"
If your definition of a 64-bit operating system is one that runs exclusively on 64-bit processors, then you've by definition excluded the possibility of a 64-bit OS on a 32-bit processor, but I don't think that has much practical value.
In practical terms, an OS being "64-bit" means that the OS is capable of handling 64-bit quantities in all the right places - which means support for large volumes, large files, etc... has 64-bit interfaces for system and library calls which accept 64-bit data types usefully... etc, etc...
When you go by this practical definition of what constitutes a 64-bit OS, it's plain that it can be implemented on a 32-bit processor. Obviously if said 32-bit processor can't actually map address space beyond 4GB the whole point is moot, but at least in the case of recent IA32, you can map way over 4GB with PAE. There's no reason a given OS kernel and the requisite OS libraries can't support 64-bit calls and types and sizes and whatnot natively on a 32-bit OS - it of course costs twice as much register and memory space to pass and store arguments and to perform calculations on them, so it would suffer performance-wise in that respect, but not as horrible as something like CPU emulation.
I'm under the impression that current IA32 Linux falls into this category of "64-bit OS running on a 32-bit CPU" that I'm describing (64-bit interfaces in the requisite places like filesystems and memory management), but since I don't care much about the topic and haven't ever looked at the code to see, I can't say for sure.
The difference is the general level of hassle and red tape, as well as accountability. Of course if you're up there in intelligence I'm sure you can unaccountably "tap" the land phone network at will using more advanced systems (Echelon and whatever's come since come to mind) - but if you're just part of some FBI field office trying to handle an immediate situation akin to the Chechnya incident the landline option means you have to get authorization and go on record for doing it, and you have to be precise about what you're tapping, and you could be delayed by all the BS. If you can tap the airwaves easily (supposing you have a laptop that can crack the effectively 54-bit encryption of a GSM call on the air), you can do it without the fuss and without being accountable.
Don't forget also that finding the right landline call to tap might be a needle in a haystack problem, but finding the right cellular call can be fairly easy if you're on-site near the caller, since you can just look for strong enough signal strength to be within a given radius of you physically, and furthermore even triangulate the signals' positions.
Is it really so wonderful an advance? I can solve that mystery for you in 10 seconds: The flashing lights have a greater rate and range of change in brightness (quick changes trigger rod cells in your retina which look for motion), loud sounds are freakin loud, you hear them better. Case closed.
What would really make this interesting would be if someone would make it possible to run x-box games on such a box. Assuming the same graphics and sound chips the games should almost run unmodified, would just take a little bit of compatibility layer and perhaps a copy of the xbox rom?
Based on my past experiences, I have the very subjective view that for the most part if you're blindly buying a case based on specs from an online retailer, go with Antec. They've never once let me down, whereas many of the other major brands have. The only case that ever impressed me more than an Antec was CoolerMaster's ATC-201C, if I was looking for really good thermal properties for a known-hot setup, I'd probably buy from them again. But in the overall, it's Antec for general purpose stuff. On a related note, even in my CoolerMaster I use Antec's power supplies, they're hard to beat, especially the newer TruePower series.
While it's not 3G, T-mobile currently offers unmetered GPRS (I believe at 40kbps, so it's like a 56k modem in bandwidth, but closer to the always-on digital nature of DSL). Their unlimited GPRS internet plan is 29.95/mo by itself (like if you're using a GSM/GPRS pcmcia card and don't need any voice), or 19.95/mo if you're adding it onto a standard voice plan on a phone.
When you use these "properties", will you still catch all the bugs you would catch by testing all input sequences though? Perhaps because of a couple small subtle flaws in a few independant peices of your code that are affected by the same input data stream, everything works fine until a config file contains the sequence " ]D[", at which point your code goes into an infinite loop and never comes back. These things do happen (although typical there's something more obvious involved, like terminal bytes and off-by-one errors in lengths or loop iterators).
Whatever your math may say, the Industry's standard is the one you disagree with. If they stick 1000 drives in an array, run them for 1 year, and only a single drive fails during that year, the MTBF for that model of drive is 500 years.
Well, yes but you'll notice the very limited data domains of your examples. Programs designed to output a fixed string "Hello World", or count the static range of 1-10, are pretty easy to solve the halting problem on.
What about real input and output though? It becomes quite a task when the user can input (through a keyboard, hardware device, a config file, etc....) essentially unlimited amounts of input data. You can't conceive or test all possible input value permutations in reasonable time, and therefore cannot "prove" the correction operation of the software in all circumstances reasonably.
There's really not all that much to it... bundling some scripting in the language of your choice around parallel ssh session is a pretty decent solution that most people seem to arrive at.
Doesn't "proving" the perfection of a body of code mathematically sound like it would basically face the same barriers as encountered in the infamous halting problem? That's not to say it can't be done with sufficient resources for a sufficiently simple body of code, but I would think there would be no general solution that always works in reasonable time for validating real code.
Yeah but you can also just run some (cheap these days) fiber between floors/buildings/campuses). I'm pretty use Gig-E longwave longhaul stuff goes like 10km.
It's the nature of the GPL and whatnot that make it possible. Whatever number of man-hours RedHat invests in their AS kernel, the majority of those hours go into work that can be freely downloaded and re-used. You can get that 4-way 8GB Oracle server running as well as RH AS using some run of the mill base platform like Gentoo with just some patch-mangling skills and whatnot, because Redhat's code contributions are out there, you just have to dig them out and get it all together the right way.
Well, the information on FEAD available by going where the/. submission references shows a pretty picture along with some very convoluted wording that seem to indicate that they're using the word "compression" to describe dynamic loading of peices of the application over the network, thereby "compressing" the original install download.
Slashdot Mirror
First off, we all believe in the basic idea of copyright here, even the gnu hippies. He who creates something is allowed to dictate the terms under which it is sold or used for gain. If *you* would like to write some software and release it to the public domain, you are more than free to do so.
Some people of the FSF mind have a different plan, which is "I want to release my work to the public domain for people to use, but I don't want someone then taking advantage of my generosity by adding a small tweak to my idea and selling it at a greedy profit - therefore I'll place a copyright restriction which dictates that you can only redistribute my work (plus your derivations of it) under the same original free terms, to keep the greedy people from taking advantage of my contribution."
Then there's people like you, who are handed this freebie which has anti-greediness protections, and bitch about it not being fully free. Please, cry me a river. The authors of whatever GPL program you'd like to make money derivating could have just locked their code up and sold it proprietary. Instead they gave you a limited free gift, and you're bitching about the limits. Go write your own damn code, and you can be as public domain or greedy as you want to be with it.
Yeah no shit. If you buy anything at Fry's, ever, make sure it appears to be sealed from the manufacturer and doesn't have a little white Fry's tag on it that's supposed to have the details of why it was returned. My best guess based on experience is that they start out with a stock of new items, and anything that gets returned to them (for any reason, be it they didn't want it, bought the wrong model, or the product was buggy or flat out broken), they do their best to repackage it, stick on of those tags on it, and put it back out with the new goods. Sometimes it's obvious (motherboards in boxes that look like they've been run over by a car, with half the docs and cables missing and a big sticker on the front that says returned), and sometimes it's not.
They do the same thing with memory simms, only there's no way to tell based on packaging. Basically if they sell a bad stick (a small percentage of all memory sticks sold will be bad), and the customer actually uses a memory tester and figures it out and returns it, they put it right back into stock (they claim they test em first, but I don't think they do). As a result, the available pool of simms of any given type that you buy from at Fry's has a considerably higher rate of defects than average.
I'd think before you even start messing with all the other things you say they do, the most fundamental step in securing your linux box is to type "netstat -anp|grep LISTEN", and be able to account for every line you see. Know what process is listening to what ports on what interfaces, and why, and ask yourself whether the ones which seem to be facing the broader internet should be. Disable various services from your startup scripts and/or modify config files as neccesary until it you get it down to where it should be. This is the most basic of security measures against network-based attacks, and one often not even looked at by people who try many other more complicated methods of securing the system.
Yeah, I can imagine Wal-mart selling them at a 30% discount with a permanent Wal-mart logo face. And then I can imagine someone writing a De-WalMart hack to replace the logo, and going to court for violating the DMCA because they thwarted the rot13 encryption neccesary to bypass the logo lock. Same shit, different year.
You're right it sounds like bad policy. I guess what you're fighting there is that who's authorized changes quickly and the system isn't designed to facilite rapidly changing permissions. Perhaps medical works and patients should have mag cards on them in a hospital, where they can scan into terminals in the room to indicate who's treating who at what time? Then you could set policies based on scans (if a Dr has a scan record with this patient within X hours of a recorded event in their patient history, grant access...)
I may not have done a good job of explaining, but you've done a good job of tearing me apart on bad grounds. I'm not a babbling audiophile. I don't own any high end stereo equipment. I am a former musician, I do understand the harmonics that instruments create, and what I'm saying does have validity.
Audio waves do interfere with each other while reflecting off of a surface, as noted more precisely in another response.
Any yes, there's lots of stereo equipment out there that *will* reproduce sounds that most ears can't hear. I believe many speakers typically respond up to 40khz, and of course "CD-quality" audio samples at 44khz, which effectively sets a maximum frequency for it. Most humans (unless they have very good, young, undamaged hearing) can't discern things beyond 20khz, maybe 25 at best for joe average. However, the sounds in the 30's that will come out of a standard recording into your living room do affect the tone your brain ends up processing, like it or not.
These are just another tool, which when employed with other layers of tools, *may* help provide you some circumstantial evidence of malintent.
As noted in other comments, if you just put in some trigger to notice on the database system itself if anyone access JFK's record - well, if the database system is compromised, the trigger can be bypassed as well. It will catch only "legit" accesses without system compromise - as in someone pulling the record through a normal interface such as a hospital records application, in which case the failure was on the part of whoever implemented your security policies and allowed the record to be accessed through this interface, it was not a hack.
The more interesting usage is the fake SSNs and CCs. These could prove more useful it would seem. If 5% of the credit cards in your company's database are known-fakes, and you register these known-fakes with Visa/MC centrally, then even if your DB was infiltrated carefully, they'll be caught when they try to use the numbers by Visa or MC themselves, a seperate system unlikely to have been simultaneously compromised.
But for numbers like SSNs and CCs, this really isn't a solution, it just raises the bar a notch. If this were common practice, then the intelligent theif would rip off CC databases from 2-3 seperate major retailers and compare them to figure out which were dupes. If there was a central list of fake cards from Visa that everyone used so that they matched, you'd just have to work at another company that also used the dupe list to have your own copy of the numbers to avoid. In the case of SSNs, before you go off using them for malicious purposes, you'd probably compare them against another database from state driver records or some such thing to filter out the bad ones...
In other words, you've made their job a bit harder, but it's not a magic bullet by far, nothing ever will be.
I'm no acoustics expert, but I know enough to know that in the case of audio, those higher harmonics which the human ear cannot hear still make a difference. So I'm going to take the time to lay down some education:
Natural harmonics:
First you have to understand what the hell a harmonic is. When a Violin plays a single "C" note alone, there is actually a subtle chord being made by the instrument which gives a distinctive nature to the sound. At a much reduced volume than the C being played that you mainly "hear", there's some related notes at specific intervals above that note (for those with a music theory background, the intervals are X octaves off of the main note, and then further can be the same note or up a maj 3rd, a fifth, etc... standard harmonic intervals like piano chords) which are also coming out of the instrument at a much lower volume. These intervals continue upwards well out of human hearing range, decreasing in volume as you go. While they're not consciously audible, they do change the tone of the instrument. When you hear two violins that sound "different" than each other, some of that is the waveform of the sound itself, and some of the difference is the varying volumes of different harmonics, which change with differences in instrument shape and composition.
These same tone-altering "harmonics" can also be produced by interferences between the various notes being played by several different instruments. Again these affect the tone of what you hear, and again they also go beyond hearing range.
Now in both cases, in a naive sense you could say that once the harmonics cross the boundary of human hearing, they no longer contribute to the tone you hear, therefore the ones up that high are irrelevant to everyone but geeks with frequency counting equipment.
However, you'd be wrong. Again because of the same types of interference, and also because tones can be modulated by the surfaces they reflect off of (including those in your head), and can affect each other at reflection points, the reproduction of those beyond-hearing harmonics (especially in any multi-speaker reproduction) does alter the human-hearable part of the tone that your brain ends up perceiving.
Also, if you ever wanted to record high pitched music for your dog to listen to, you'd be SOL with human-range recording and playback equipment, so do it for the dogs' sake.
is my general response - this is no longer the stock option era we were in before.
But for a datapoint from the past, at WorldCom the "good" package for well-liked VPs and senior technical staff was worth on average about 150-250k/year pre-tax value after cashing them out (if you did so immediately). Of course that's all very rough numbers, dependant on values that they could have only vaguely predicted. They were good for another 7 years afterwards which could have led the values much higher, or could have led the values way below zero (as happened to be the actual case for those who didn't cash out back when they had the chance).
The "standard" package they gave virtually every full-time employee by contrast was worth on the order of 5-15k I think (I don't remember for sure what they were valued at).
Everyone tries to replace make and freinds, and everybody fails. (Well, at least fails to be a true replacement that's actually better in every way). A few small tweaks aside, you can't really make serious design improvements to the standard unix make and related tools without taking some large tradeoffs that make it unacceptable for at least some uses. It's a very flexible tool as it stands, and it's hard to make it better without losing that flexibility.
I sometimes wish I could make a single collective response to all the responses to a post I've made, I'll have to settle for responding to this one and hoping the rest will look around the conversation.
To further define the question, you have to ask yourself "What do I mean by the term '64-bit Operating System?'"
If your definition of a 64-bit operating system is one that runs exclusively on 64-bit processors, then you've by definition excluded the possibility of a 64-bit OS on a 32-bit processor, but I don't think that has much practical value.
In practical terms, an OS being "64-bit" means that the OS is capable of handling 64-bit quantities in all the right places - which means support for large volumes, large files, etc... has 64-bit interfaces for system and library calls which accept 64-bit data types usefully... etc, etc...
When you go by this practical definition of what constitutes a 64-bit OS, it's plain that it can be implemented on a 32-bit processor. Obviously if said 32-bit processor can't actually map address space beyond 4GB the whole point is moot, but at least in the case of recent IA32, you can map way over 4GB with PAE. There's no reason a given OS kernel and the requisite OS libraries can't support 64-bit calls and types and sizes and whatnot natively on a 32-bit OS - it of course costs twice as much register and memory space to pass and store arguments and to perform calculations on them, so it would suffer performance-wise in that respect, but not as horrible as something like CPU emulation.
I'm under the impression that current IA32 Linux falls into this category of "64-bit OS running on a 32-bit CPU" that I'm describing (64-bit interfaces in the requisite places like filesystems and memory management), but since I don't care much about the topic and haven't ever looked at the code to see, I can't say for sure.
The difference is the general level of hassle and red tape, as well as accountability. Of course if you're up there in intelligence I'm sure you can unaccountably "tap" the land phone network at will using more advanced systems (Echelon and whatever's come since come to mind) - but if you're just part of some FBI field office trying to handle an immediate situation akin to the Chechnya incident the landline option means you have to get authorization and go on record for doing it, and you have to be precise about what you're tapping, and you could be delayed by all the BS. If you can tap the airwaves easily (supposing you have a laptop that can crack the effectively 54-bit encryption of a GSM call on the air), you can do it without the fuss and without being accountable.
Don't forget also that finding the right landline call to tap might be a needle in a haystack problem, but finding the right cellular call can be fairly easy if you're on-site near the caller, since you can just look for strong enough signal strength to be within a given radius of you physically, and furthermore even triangulate the signals' positions.
Therefore backwards compat is not an acceptable excuse.
Is it really so wonderful an advance? I can solve that mystery for you in 10 seconds: The flashing lights have a greater rate and range of change in brightness (quick changes trigger rod cells in your retina which look for motion), loud sounds are freakin loud, you hear them better. Case closed.
What would really make this interesting would be if someone would make it possible to run x-box games on such a box. Assuming the same graphics and sound chips the games should almost run unmodified, would just take a little bit of compatibility layer and perhaps a copy of the xbox rom?
Based on my past experiences, I have the very subjective view that for the most part if you're blindly buying a case based on specs from an online retailer, go with Antec. They've never once let me down, whereas many of the other major brands have. The only case that ever impressed me more than an Antec was CoolerMaster's ATC-201C, if I was looking for really good thermal properties for a known-hot setup, I'd probably buy from them again. But in the overall, it's Antec for general purpose stuff. On a related note, even in my CoolerMaster I use Antec's power supplies, they're hard to beat, especially the newer TruePower series.
While it's not 3G, T-mobile currently offers unmetered GPRS (I believe at 40kbps, so it's like a 56k modem in bandwidth, but closer to the always-on digital nature of DSL). Their unlimited GPRS internet plan is 29.95/mo by itself (like if you're using a GSM/GPRS pcmcia card and don't need any voice), or 19.95/mo if you're adding it onto a standard voice plan on a phone.
When you use these "properties", will you still catch all the bugs you would catch by testing all input sequences though? Perhaps because of a couple small subtle flaws in a few independant peices of your code that are affected by the same input data stream, everything works fine until a config file contains the sequence " ]D[", at which point your code goes into an infinite loop and never comes back. These things do happen (although typical there's something more obvious involved, like terminal bytes and off-by-one errors in lengths or loop iterators).
Whatever your math may say, the Industry's standard is the one you disagree with. If they stick 1000 drives in an array, run them for 1 year, and only a single drive fails during that year, the MTBF for that model of drive is 500 years.
Well, yes but you'll notice the very limited data domains of your examples. Programs designed to output a fixed string "Hello World", or count the static range of 1-10, are pretty easy to solve the halting problem on.
What about real input and output though? It becomes quite a task when the user can input (through a keyboard, hardware device, a config file, etc....) essentially unlimited amounts of input data. You can't conceive or test all possible input value permutations in reasonable time, and therefore cannot "prove" the correction operation of the software in all circumstances reasonably.
There's really not all that much to it... bundling some scripting in the language of your choice around parallel ssh session is a pretty decent solution that most people seem to arrive at.
Doesn't "proving" the perfection of a body of code mathematically sound like it would basically face the same barriers as encountered in the infamous halting problem? That's not to say it can't be done with sufficient resources for a sufficiently simple body of code, but I would think there would be no general solution that always works in reasonable time for validating real code.
Yeah but you can also just run some (cheap these days) fiber between floors/buildings/campuses). I'm pretty use Gig-E longwave longhaul stuff goes like 10km.
It's the nature of the GPL and whatnot that make it possible. Whatever number of man-hours RedHat invests in their AS kernel, the majority of those hours go into work that can be freely downloaded and re-used. You can get that 4-way 8GB Oracle server running as well as RH AS using some run of the mill base platform like Gentoo with just some patch-mangling skills and whatnot, because Redhat's code contributions are out there, you just have to dig them out and get it all together the right way.
Well, the information on FEAD available by going where the