I remember playing a pirated version of Wolfenstein on the Commodore 64. It was a kludgy hybrid of BASIC and machine code; and used KoVox Voice Master-style speech synthesis to have the guards actually say a few words. Of course, the screen froze or blanked to recover enough cycles to actually do it....
Never was any good at it, it was horribly laggy (BASIC) and would have all sorts of weird things happen if you were incautious with holding down a key and it repeated too much. And I'd invariably hit the STOP key when I didn't want to and wind up at "READY." again.
I only miss _some_ software of my youth, and actually I don't miss any of it, 'cause I've got it all on emulation (PET/VIC/C64) or I've still got it (Amiga, 68K Mac).
Just need a converter to hook Amiga RGB to HDTV YPrPb....
Also, you may find some makers use the U.S. gallon (about 3.7L) and others use the U.K. gallon (about 4.3L), so you have to convert from the L/100km numbers to get comparable fuel economy numbers.
Not to detract from the humour.... If you incorporate without a name, you get to be known by the serial number associated with your incorporation.
There was a similar scam in Canada, with some registrar sending out renewal notices to other registrar's customers. I forwarded one to the RCMP fraud division, and they said it wasn't technically illegal so they wouldn't do anything.
That, and accepting the bank phone number provided by the customer.
On the rare occasion my bank phones me, I ask them how I can call back with information I have (on my ATM card, on my statement, in my telephone book). Every single time they have complimented me on that procedure and provided the name and extension number to reach them. (OK, some times they've told me anyone in the call centre can help, and I don't need to talk to the person who called me in the first place.)
If you're verifying something someone provides you, you cannot use the information they provide you....
Not only are there Windows tools (some of which even use the CDDA Paranoia library), but even iTunes should have a setting to do the same thing; the OS X version does, and it'd be a dumb thing to leave out. It'll have a warning about slowing down ripping; but who cares how quickly you can get a bad rip?
Yup, you missed 75 ohm (CATV coax) and 50 ohm (professional video coax).
Then there's the multiples of CATV modulation standards; "normal", "HRC" and "IRC" leap out of the depths of memory.
And the multiple naming systems for CATV channels. 13-whatever weren't supposed to be numbered ('cause those were UHF); they were lettered A-Z then AA-ZZ. But that was hard to do on a 7-segment readout....
Now there's ATSC and other standards for broadcast, different ones for cablecast and satellite....
You can get defective anything... or the old cable just wasn't up to the HDMI standard properly, and had been fraudulently marked.
I recently hooked up an older cable I had to a friend's new TV; it didn't work. No signal, not even enough for EDID handshake. It should have been HDMI 1.2 compatible, and cost about $25 new. Since the TV is only a 720p set, that should have been fine. At the very least, the "there's a monitor out there" handshake is all at low-speed and will work on wet string and tin cans.
I then tried an HDMI 1.3a cable from Monoprice (so like $7), and it worked fine. (Prices not corrected for inflation.)
Problem? The connector on the old cable was too loose, and wasn't properly mating with the plug on the TV. I'm pretty sure some gentle pressure in a vise would fix it... but it's also useful cut up into pieces and used for prototyping hook-up wire.
Price, independent of quality, is not a reliable indicator.
Another way: You can pay less and get something worse. But paying more doesn't mean you will get something better.
If you have some minor skill at soldering, and a crappy USB game pad, and a DB9 male connector, you can just hack the game pad. More fun and possibly cheaper.
I made one, and the leads on the controller chip inside were long enough I could solder to them. So it actually still works as a gamepad, but that wasn't what I had in mind when I grabbed it out of the discount bin.
Plug in my old Wico Command Control bat-handle stick and fire up Power64 and find out I still suck at Jumpman.
And having been arrested can be used by the U.S. border guards to deny Canadian citizens visa-waiver entry.
Which means that the streetcar operator picked up in one of the G20 sweeps may have to get a travel visa from the consulate to visit the U.S. Even though he was not charged: the question isn't "arrested with just cause", it's just "arrested".
Frankly, it's making the European Union and Commonwealth countries look like much better travel destinations. Which is annoying, 'cause it's really hard to drive to Europe from Canada.
Since many current systems implement PCI via a PCIe to PCI bridge chip, there is no reason a riser or backplane card cannot be made to connect to the PCIe bus.
In fact, a quick search for such a beast hit a Google Ad that offered a variety of combinations, starting with one that will connect a low-profile PCI card to a PCIe slot for EUR49.
And system vendors can do the same thing to keep offering PCI slots on the motherboard itself.
Changing the disk in the last-gen Mini isn't too hard. You have to do all the work to pull the disks to get at the RAM anyway.
Just be sure to remove the heat sensor from the HDD, rather than trying to unplug it. Not all units have a plug like the one in the iFixit tear-down, and you might need a soldering iron if you do it wrong. Don't ask me how I know.
I don't remember if there was enough clearance to fit a 12.5mm 1TB 2.5" disk. Standard 9.5mm ones fit no problem, any SATA one will be fine.
Yeah; I had to set up a 4-way stripe set to get sustained writes over 200 MB/s. Each drive tops out at about 65 MB/s as you get closer to the hub. They start off with an impressive 125 MB/s at the outer rim, but that's only a fraction of the capacity.
And those are $100/each SATA drives on a $150/each 8-port PCI-e SAS controller. You don't need to spend a fortune to get acceptable aggregate speed, but you do have to get the right bits.
One of the few problems I have is, suspend/hibernate don't work right. The usual finger-pointing is to the binary nVidia drivers.
But with the binary drivers, CPU load for playing back Blu-Ray ".m4ts" stream files is less than 10%--the GPU is doing all the heavy lifting. Anything DVD resolution is background noise. (I got the dual-core ION; that's probably overkill.)
If you're really into Linux and PXE boot servers, you can run them without any disk drives at all. Just the Zotac ION board, some RAM, power supply, and Ethernet. Plug in HDMI and digital audio and off you go.
(I don't have audio over HDMI working, but I don't really care, because my receiver can't handle 1080p so the HDMI has to go right to the TV and the audio to the receiver anyway....)
Apple's Developer Agreement for the iPhone SDK explicitly specified that your application must comply with open-source license terms.
So if someone puts up a GPL application on the App Store without the source, they're not just in violation of the GPL, they're also in violation of Apple's terms.
From http://adcdownload.apple.com/iphone/iphone_sdk_3.2__final/iphone_sdk_agreement.pdf, "3.3.16 If Your Application includes any FOSS, You agree to comply with all applicable FOSS licensing terms. You also agree not to use any FOSS in the development of Your Application in such a way that would cause the non-FOSS portions of the SDK to be subject to any FOSS licensing terms or obligations."
In part, obviously, this is to keep someone from trying to lever open Apple's code with an FOSS license. But they've written it so that it also protects FOSS users and developers. It reads, to me, a lot like the GPL clause that says, "if you can't follow all these rules, you can't distribute the software."
Many attackable flaws--like SQL injection--are also bugs. That is, unsanitized data is put into something that's parsed for meaning.
(This is a long-known problem, at least in UNIX circles, as it is the SQL equivalent of command quoting problems.)
These bugs show up as crashes and odd behaviour with incorrect user input, or unanticipated user input. (Ask Apple how much it cost for an incorrectly quoted "rm" command in the iTunes update script.)
You test for this stuff by feeding your program the whole range of input characters and string lengths. You especially don't test expected inputs: you test unexpected inputs. And it's often difficult for the people who write a program to do these kinds of tests, because they all know "that input is wrong, you wouldn't do that". Like someone who never thinks to try "1/0" because you can't do that.
So you run a test with every character in the input code set. You test with spaces, variable expansion characters, quote marks, the lot.
On the input side, you whitelist. If you know your program is safe with upper- and lower-case letters, verify the input only contains those characters. Never look for characters you know are bad; that means you have to know everything, even the future.
This way, your program is hardened against typos as well as attacks. You can give the user meaningful guidance as to what went wrong: "User names can only be 8 characters consisting of upper- and lower-case letters and underscore", for example. Rather than, "Segmentation fault (core dumped)" or "/tmp/a: file not found; user: file not found" or any of the other weird things that can happen when input gets over-parsed.
Also, make sure you can deal with data damaged by I/O errors. Sure, you've got a lovely XML file. But the 7th block on disk got trashed when the file was being updated and the power went out, and now you get 512 ASCII NULs where that data used to be. What does your program do? Or the file pointers got trashed and you're actually getting the data that makes up/bin/ls instead of your config file... what happens?
Use the right APIs. On UNIX, we can pass arbitrary and dangerous arguments to subprocesses by using the 'exec' family of system calls, which do not invoke the shell (unless you invoke a shell script). So you can safely call, say, "rm" with "a funny name", because the shell won't be invoked and won't want to split the argument on spaces. Basically, never use "system" or any moral equivalent. (On Windows, you can't avoid this, because it doesn't work that way; anything you call with an argument vector will produce a space-separated string for the process to parse on its own. So be aware of that, and take great care in program invocation.)
Don't call an outside program for something your language and libraries can do in your process. Don't use system("rm file") when you can unlink("file"). Especially don't system("echo message"); I wish I was kidding about that one.
Don't use wildcards in program commands. What will happen if someone creates really funny filenames, like "\n", or ";", or "; rm -rf.;^H^H^H^H^H^H^H^H^Hinnocent file". If the host operating system allows every octet except NUL and / in a filename, can your program deal with it?
If you really must do wildcards, use something like 'find' which can be reliably controlled: a wildcard argument to find will never be treated as a shell command. (You're already bypassing the shell, right? Or quoting properly from a shell script?)
Learn the difference between "$*" and "$@". UNIX shell scripts can easily handle arbitrary weird names... but you have to be religious about quoting to do it. And learn about the POSIX "--" end-of-option marker, and the "./${filename}" trick, so you can call commands with arguments that begin with -.
All of this protects you from a variety of injection attacks. But it also protects against input errors, too; and as long as humans are on the console, there will be input errors.
...which, arguably, is 1/100th of an OS. Though in SI we'd just write cOS... and then get confused about the unexpected trig.
That's not anywhere near as good as 1/2 of an OS IBM used to sell: OS/2.
But it's still better than the 1/400th of an OS they had back then, too: OS/400. You had to run that on 1/400th of an Advanced System.
If you really wanted something fractional, you could get 1/6000 of a RISC System, and run 6*10**-4 of an Advanced Interactive Executive on it.
(Somewhat seriously, I run CentOS for real on a few servers for small-budget groups. It's even better than Red Hat; no stupid registration and 'yum' works right out of the box.)
To avoid dealing with stupid BIOS issues, my systems boot from a flash card with/boot on it and nothing else.
So the OS can see a single disk with an MBR partition table and a single primary bootable partition and all that rot. GRUB can deal with the BIOS and load initrd and vmlinuz.
Once Linux is going, then it can get at all the "good" disks: GPT partitioned, software RAID 1 and LVM all over the place. Connected via non-booting controllers, or ones with dodgy boot ROMs, or any number of issues all Go Away if you don't have to worry about the bloody BIOS.
And, of course,/boot rarely changes so the flash will last for ages. And I can prevent it booting simply by yanking the card from the slot, so an accidental power-on won't be able to start the machine when it's on the service bench for testing or... experiments.
Just about all of the evidence Bell submitted was sealed.
Therefore, in any form of public governing body, I fail to see how this can be considered evidence.
Especially since the little that they showed over the throttling issue suggested that the saturation times were transient and only in a limited number of nodes; minor capital upgrades on those nodes would eliminate it.
The real thing that's happening is Bell is pushing out TV via IP using VDSL, and has been hard at work upgrading plant all over their service area. However, they've managed to avoid the "equal access" ruling so far, and so no competing ISP can offer a sync rate over 5 mbps up/800 kbps down.
By limiting people to 60 GB a month, they make it effectively impossible for competing TV over IP subscription services to work.
(This stuff has been done to death over on broadbandreports.com....)
Oh, one more thing: TekSavvy, for example, gets less than $10/month on their $30/month DSL fee. The rest goes to Bell. Plus, you only get that fee if you already have a wire-line telephone you're paying Bell for, otherwise, you pay a dry-loop fee as well. You should be able to get unlimited 10 mbps symmetric lines at wholesale for that kind of rate.
And what's paid to Bell doesn't connect you to the Internet; it connects you to TekSavvy. TekSavvy has their own peering arrangements, paid for out of their $10/month share of your fee.
Remember when the phone companies didn't operate ISPs?
I destroyed an 8GB USB drive with an electrostatic discharge in an environment with a lot of synthetic materials (especially chair seats) and very, very, very, very low humidity. It's probable just the interface chips that were damaged, and were it truly valuable, the memory chips may well have been intact and salvageable.
On magnetic media, it's easier to separate the solid-state (static-sensitive) part from the mechanical part (shock-, magnetism-, and so on sensitive).
Magnetic tape, of course, stores the media separate from the electronics.
So, once again, we're back to "diversity": multiple media categories as well as multiple copies. No one technology is flawless.
Though it's always amazed me at how hard media is to destroy on purpose... and how easy it is to do it by accident. Rubbing a magnet over a floppy never worked for me; but accidentally putting it with a magnet would, for example.
Right; if I give something away, I know I'm going to need it in the next 6 to 12 months.
I gave away my last AGP video card a couple of years back. 4 weeks later, my fileserver went down with bad capacitors on its AGP video card.
I gave away my solderless breadboards. I've since had to replace them....
Power supplies... RAM DIMMs... you name it.
(Part of this is because I'm the fix-it guy for a small start-up and all my friends, especially the ones with "restricted finances" let's say.)
Anything that's truly not needed, I can't give away: QIC 150 SCSI tape drive, for example, or 3X CD-ROM caddy-loading drives.
So I'll stick with organizing things instead of trying to get rid of them. If I do get a new technology X, it's best to try and sell the old one right away. Don't wait a year or two until it's beyond obsolete, but not a classic.
I'm curious as to why a company would spend a lot of money making something that other people will give away for free.
It had better be really special.
My experience in software houses over the last 20 years suggests that they are opposed to letting customers see their source code because then customers will know, beyond any doubt, that they have been thoroughly fleeced. If the vendor delivers binaries only, at least there's still the possibility that the code is good quality, cleverly engineered, or whatever they're convincing people to pay for.
Even if it is a hash, the old UNIX crypt(3C) function only hashed the first 8 characters. So you could have what you thought was an arbitrarily-long password, but an attacker only needed to go after the first 8 characters.
If you were using the presumed length to use an English phrase (for example), you could wind up with a very weak password. "passwordisreallylongsoimsafe" would be unlocked with "password", which is fairly early in the dictionary attacks I've seen.
I normally think it's acceptable to trade entropy density for memorability: English is fairly low entropy, but I can remember a 12-word passphrase without too much trouble, so the total entropy is OK compared to a line-noise 8 character string. But that requires the hashing functions work with the complete input; so on systems which still use crypt(3C) or something like it, I go with the line-noise.
OK; my fastest SATA drives will do an average of 80 MB/s across the platter; they peak at 125 MB/s at the outer rim. On SATA, with a PCI-Express SAS card, they actually run at the advertised speeds. Actually, 4 drives at a time will run at those speeds; when I get 6 going at once, I see the average _on all 6 drives_ drop to about 60 MB/s. Which makes me very very very happy with that card, mind you; it blows the Promise TX4 PCI card into little pieces of slow crap.
Those same drives in a USB 2.0 chassis will write all day at ~40 MB/s; you never get the peak speed at the rim, but then, since the USB line is the bottleneck, you don't get the drop at the hub, either. Obviously there isn't much else happening on that USB controller channel, and it's in the southbridge.
So if you're getting a 20x difference between USB 2.0 and eSATA, it's probably more the case that your eSATA connection is on a much better-performing bus device, and/or you've got too much contention for USB. Which doesn't negate eSATA solving your problem, of course.
But on a laptop, typically you're not going to have hub-webs of USB devices, so 2.0 is fair. 3.0/eSATA would be better, but FireWire 800 is nice instead, and all your legacy FireWire 400 and DV gear works with that, too.
Especially given the insides of the MacBook family. They are full; adding any connector would mean asking, "What should we remove?" It's really amazing to look inside one, there's no "gap" where you could fit another feature. It really is like a unibody car design; the case is both structure and enclosure.
Just remember to align your screwdriver with the slightly-angled screws properly, or you'll risk cross-threading and that would be bad.
Now, I recently stuck some last-generation Seagate 750 MB PATA drives in some FireWire enclosures on a dodgy controller on Linux. Those things aren't doing well; about 20 MB/s tops. The controller is probably crap. I'm also pretty sure the PCI Express to PCI bridge on my mainboard is crap, too; so you really don't want to push data through PCI on it. The enclosures have USB2.0 as well, so I really should try that; or one of the other FireWire controllers in the junk-pile.
I suspect crappy PCI bridges are very common, even though it's very hard to find a mainboard without PCI slots.
Slashdot Mirror
Bah!
I remember playing a pirated version of Wolfenstein on the Commodore 64. It was a kludgy hybrid of BASIC and machine code; and used KoVox Voice Master-style speech synthesis to have the guards actually say a few words. Of course, the screen froze or blanked to recover enough cycles to actually do it....
Never was any good at it, it was horribly laggy (BASIC) and would have all sorts of weird things happen if you were incautious with holding down a key and it repeated too much. And I'd invariably hit the STOP key when I didn't want to and wind up at "READY." again.
I only miss _some_ software of my youth, and actually I don't miss any of it, 'cause I've got it all on emulation (PET/VIC/C64) or I've still got it (Amiga, 68K Mac).
Just need a converter to hook Amiga RGB to HDTV YPrPb....
Also, you may find some makers use the U.S. gallon (about 3.7L) and others use the U.K. gallon (about 4.3L), so you have to convert from the L/100km numbers to get comparable fuel economy numbers.
Not to detract from the humour.... If you incorporate without a name, you get to be known by the serial number associated with your incorporation.
There was a similar scam in Canada, with some registrar sending out renewal notices to other registrar's customers. I forwarded one to the RCMP fraud division, and they said it wasn't technically illegal so they wouldn't do anything.
That, and accepting the bank phone number provided by the customer.
On the rare occasion my bank phones me, I ask them how I can call back with information I have (on my ATM card, on my statement, in my telephone book). Every single time they have complimented me on that procedure and provided the name and extension number to reach them. (OK, some times they've told me anyone in the call centre can help, and I don't need to talk to the person who called me in the first place.)
If you're verifying something someone provides you, you cannot use the information they provide you....
Not only are there Windows tools (some of which even use the CDDA Paranoia library), but even iTunes should have a setting to do the same thing; the OS X version does, and it'd be a dumb thing to leave out. It'll have a warning about slowing down ripping; but who cares how quickly you can get a bad rip?
Yup, you missed 75 ohm (CATV coax) and 50 ohm (professional video coax).
Then there's the multiples of CATV modulation standards; "normal", "HRC" and "IRC" leap out of the depths of memory.
And the multiple naming systems for CATV channels. 13-whatever weren't supposed to be numbered ('cause those were UHF); they were lettered A-Z then AA-ZZ. But that was hard to do on a 7-segment readout....
Now there's ATSC and other standards for broadcast, different ones for cablecast and satellite....
You can get defective anything... or the old cable just wasn't up to the HDMI standard properly, and had been fraudulently marked.
I recently hooked up an older cable I had to a friend's new TV; it didn't work. No signal, not even enough for EDID handshake. It should have been HDMI 1.2 compatible, and cost about $25 new. Since the TV is only a 720p set, that should have been fine. At the very least, the "there's a monitor out there" handshake is all at low-speed and will work on wet string and tin cans.
I then tried an HDMI 1.3a cable from Monoprice (so like $7), and it worked fine. (Prices not corrected for inflation.)
Problem? The connector on the old cable was too loose, and wasn't properly mating with the plug on the TV. I'm pretty sure some gentle pressure in a vise would fix it... but it's also useful cut up into pieces and used for prototyping hook-up wire.
Price, independent of quality, is not a reliable indicator.
Another way: You can pay less and get something worse. But paying more doesn't mean you will get something better.
Wow. Just when you thought people couldn't be more gullible....
I'm not sure what's worse, that such a product exists, or that it gets a 4.4 out of 5 "value for price" rating.
If they were to actually gold-coat the optical part of the connector, I'm pretty sure that would create a "mirror".
If you have some minor skill at soldering, and a crappy USB game pad, and a DB9 male connector, you can just hack the game pad. More fun and possibly cheaper.
I made one, and the leads on the controller chip inside were long enough I could solder to them. So it actually still works as a gamepad, but that wasn't what I had in mind when I grabbed it out of the discount bin.
Plug in my old Wico Command Control bat-handle stick and fire up Power64 and find out I still suck at Jumpman.
And having been arrested can be used by the U.S. border guards to deny Canadian citizens visa-waiver entry.
Which means that the streetcar operator picked up in one of the G20 sweeps may have to get a travel visa from the consulate to visit the U.S. Even though he was not charged: the question isn't "arrested with just cause", it's just "arrested".
Frankly, it's making the European Union and Commonwealth countries look like much better travel destinations. Which is annoying, 'cause it's really hard to drive to Europe from Canada.
Since many current systems implement PCI via a PCIe to PCI bridge chip, there is no reason a riser or backplane card cannot be made to connect to the PCIe bus.
In fact, a quick search for such a beast hit a Google Ad that offered a variety of combinations, starting with one that will connect a low-profile PCI card to a PCIe slot for EUR49.
And system vendors can do the same thing to keep offering PCI slots on the motherboard itself.
Changing the disk in the last-gen Mini isn't too hard. You have to do all the work to pull the disks to get at the RAM anyway.
Just be sure to remove the heat sensor from the HDD, rather than trying to unplug it. Not all units have a plug like the one in the iFixit tear-down, and you might need a soldering iron if you do it wrong. Don't ask me how I know.
I don't remember if there was enough clearance to fit a 12.5mm 1TB 2.5" disk. Standard 9.5mm ones fit no problem, any SATA one will be fine.
Yeah; I had to set up a 4-way stripe set to get sustained writes over 200 MB/s. Each drive tops out at about 65 MB/s as you get closer to the hub. They start off with an impressive 125 MB/s at the outer rim, but that's only a fraction of the capacity.
And those are $100/each SATA drives on a $150/each 8-port PCI-e SAS controller. You don't need to spend a fortune to get acceptable aggregate speed, but you do have to get the right bits.
They're great. I've got one running XBMC Live.
One of the few problems I have is, suspend/hibernate don't work right. The usual finger-pointing is to the binary nVidia drivers.
But with the binary drivers, CPU load for playing back Blu-Ray ".m4ts" stream files is less than 10%--the GPU is doing all the heavy lifting. Anything DVD resolution is background noise. (I got the dual-core ION; that's probably overkill.)
If you're really into Linux and PXE boot servers, you can run them without any disk drives at all. Just the Zotac ION board, some RAM, power supply, and Ethernet. Plug in HDMI and digital audio and off you go.
(I don't have audio over HDMI working, but I don't really care, because my receiver can't handle 1080p so the HDMI has to go right to the TV and the audio to the receiver anyway....)
Apple's Developer Agreement for the iPhone SDK explicitly specified that your application must comply with open-source license terms.
So if someone puts up a GPL application on the App Store without the source, they're not just in violation of the GPL, they're also in violation of Apple's terms.
From http://adcdownload.apple.com/iphone/iphone_sdk_3.2__final/iphone_sdk_agreement.pdf, "3.3.16 If Your Application includes any FOSS, You agree to comply with all applicable FOSS licensing terms. You also agree not to use any FOSS in the development of Your Application in such a way that would cause the non-FOSS portions of the SDK to be subject to any FOSS licensing terms or obligations."
In part, obviously, this is to keep someone from trying to lever open Apple's code with an FOSS license. But they've written it so that it also protects FOSS users and developers. It reads, to me, a lot like the GPL clause that says, "if you can't follow all these rules, you can't distribute the software."
Many attackable flaws--like SQL injection--are also bugs. That is, unsanitized data is put into something that's parsed for meaning.
(This is a long-known problem, at least in UNIX circles, as it is the SQL equivalent of command quoting problems.)
These bugs show up as crashes and odd behaviour with incorrect user input, or unanticipated user input. (Ask Apple how much it cost for an incorrectly quoted "rm" command in the iTunes update script.)
You test for this stuff by feeding your program the whole range of input characters and string lengths. You especially don't test expected inputs: you test unexpected inputs. And it's often difficult for the people who write a program to do these kinds of tests, because they all know "that input is wrong, you wouldn't do that". Like someone who never thinks to try "1/0" because you can't do that.
So you run a test with every character in the input code set. You test with spaces, variable expansion characters, quote marks, the lot.
On the input side, you whitelist. If you know your program is safe with upper- and lower-case letters, verify the input only contains those characters. Never look for characters you know are bad; that means you have to know everything, even the future.
This way, your program is hardened against typos as well as attacks. You can give the user meaningful guidance as to what went wrong: "User names can only be 8 characters consisting of upper- and lower-case letters and underscore", for example. Rather than, "Segmentation fault (core dumped)" or "/tmp/a: file not found; user: file not found" or any of the other weird things that can happen when input gets over-parsed.
Also, make sure you can deal with data damaged by I/O errors. Sure, you've got a lovely XML file. But the 7th block on disk got trashed when the file was being updated and the power went out, and now you get 512 ASCII NULs where that data used to be. What does your program do? Or the file pointers got trashed and you're actually getting the data that makes up /bin/ls instead of your config file... what happens?
Use the right APIs. On UNIX, we can pass arbitrary and dangerous arguments to subprocesses by using the 'exec' family of system calls, which do not invoke the shell (unless you invoke a shell script). So you can safely call, say, "rm" with "a funny name", because the shell won't be invoked and won't want to split the argument on spaces. Basically, never use "system" or any moral equivalent. (On Windows, you can't avoid this, because it doesn't work that way; anything you call with an argument vector will produce a space-separated string for the process to parse on its own. So be aware of that, and take great care in program invocation.)
Don't call an outside program for something your language and libraries can do in your process. Don't use system("rm file") when you can unlink("file"). Especially don't system("echo message"); I wish I was kidding about that one.
Don't use wildcards in program commands. What will happen if someone creates really funny filenames, like "\n", or ";", or "; rm -rf .;^H^H^H^H^H^H^H^H^Hinnocent file". If the host operating system allows every octet except NUL and / in a filename, can your program deal with it?
If you really must do wildcards, use something like 'find' which can be reliably controlled: a wildcard argument to find will never be treated as a shell command. (You're already bypassing the shell, right? Or quoting properly from a shell script?)
Learn the difference between "$*" and "$@". UNIX shell scripts can easily handle arbitrary weird names... but you have to be religious about quoting to do it. And learn about the POSIX "--" end-of-option marker, and the "./${filename}" trick, so you can call commands with arguments that begin with -.
All of this protects you from a variety of injection attacks. But it also protects against input errors, too; and as long as humans are on the console, there will be input errors.
...which, arguably, is 1/100th of an OS. Though in SI we'd just write cOS... and then get confused about the unexpected trig.
That's not anywhere near as good as 1/2 of an OS IBM used to sell: OS/2.
But it's still better than the 1/400th of an OS they had back then, too: OS/400. You had to run that on 1/400th of an Advanced System.
If you really wanted something fractional, you could get 1/6000 of a RISC System, and run 6*10**-4 of an Advanced Interactive Executive on it.
(Somewhat seriously, I run CentOS for real on a few servers for small-budget groups. It's even better than Red Hat; no stupid registration and 'yum' works right out of the box.)
To avoid dealing with stupid BIOS issues, my systems boot from a flash card with /boot on it and nothing else.
So the OS can see a single disk with an MBR partition table and a single primary bootable partition and all that rot. GRUB can deal with the BIOS and load initrd and vmlinuz.
Once Linux is going, then it can get at all the "good" disks: GPT partitioned, software RAID 1 and LVM all over the place. Connected via non-booting controllers, or ones with dodgy boot ROMs, or any number of issues all Go Away if you don't have to worry about the bloody BIOS.
And, of course, /boot rarely changes so the flash will last for ages. And I can prevent it booting simply by yanking the card from the slot, so an accidental power-on won't be able to start the machine when it's on the service bench for testing or... experiments.
Just about all of the evidence Bell submitted was sealed.
Therefore, in any form of public governing body, I fail to see how this can be considered evidence.
Especially since the little that they showed over the throttling issue suggested that the saturation times were transient and only in a limited number of nodes; minor capital upgrades on those nodes would eliminate it.
The real thing that's happening is Bell is pushing out TV via IP using VDSL, and has been hard at work upgrading plant all over their service area. However, they've managed to avoid the "equal access" ruling so far, and so no competing ISP can offer a sync rate over 5 mbps up/800 kbps down.
By limiting people to 60 GB a month, they make it effectively impossible for competing TV over IP subscription services to work.
(This stuff has been done to death over on broadbandreports.com....)
Oh, one more thing: TekSavvy, for example, gets less than $10/month on their $30/month DSL fee. The rest goes to Bell. Plus, you only get that fee if you already have a wire-line telephone you're paying Bell for, otherwise, you pay a dry-loop fee as well. You should be able to get unlimited 10 mbps symmetric lines at wholesale for that kind of rate.
And what's paid to Bell doesn't connect you to the Internet; it connects you to TekSavvy. TekSavvy has their own peering arrangements, paid for out of their $10/month share of your fee.
Remember when the phone companies didn't operate ISPs?
Geez, with logic like that, next you'll ask for the Mozilla applications to use the system's native SSL certificate store.
I just love telling people they have to add CA root certificates at least twice: OS, Firefox, Thunderbird, Opera, ....
OK, so maybe Opera isn't Mozilla's fault.
Different failure modes for solid-state.
I destroyed an 8GB USB drive with an electrostatic discharge in an environment with a lot of synthetic materials (especially chair seats) and very, very, very, very low humidity. It's probable just the interface chips that were damaged, and were it truly valuable, the memory chips may well have been intact and salvageable.
On magnetic media, it's easier to separate the solid-state (static-sensitive) part from the mechanical part (shock-, magnetism-, and so on sensitive).
Magnetic tape, of course, stores the media separate from the electronics.
So, once again, we're back to "diversity": multiple media categories as well as multiple copies. No one technology is flawless.
Though it's always amazed me at how hard media is to destroy on purpose... and how easy it is to do it by accident. Rubbing a magnet over a floppy never worked for me; but accidentally putting it with a magnet would, for example.
Right; if I give something away, I know I'm going to need it in the next 6 to 12 months.
I gave away my last AGP video card a couple of years back. 4 weeks later, my fileserver went down with bad capacitors on its AGP video card.
I gave away my solderless breadboards. I've since had to replace them....
Power supplies... RAM DIMMs... you name it.
(Part of this is because I'm the fix-it guy for a small start-up and all my friends, especially the ones with "restricted finances" let's say.)
Anything that's truly not needed, I can't give away: QIC 150 SCSI tape drive, for example, or 3X CD-ROM caddy-loading drives.
So I'll stick with organizing things instead of trying to get rid of them. If I do get a new technology X, it's best to try and sell the old one right away. Don't wait a year or two until it's beyond obsolete, but not a classic.
I'm curious as to why a company would spend a lot of money making something that other people will give away for free.
It had better be really special.
My experience in software houses over the last 20 years suggests that they are opposed to letting customers see their source code because then customers will know, beyond any doubt, that they have been thoroughly fleeced. If the vendor delivers binaries only, at least there's still the possibility that the code is good quality, cleverly engineered, or whatever they're convincing people to pay for.
Even if it is a hash, the old UNIX crypt(3C) function only hashed the first 8 characters. So you could have what you thought was an arbitrarily-long password, but an attacker only needed to go after the first 8 characters.
If you were using the presumed length to use an English phrase (for example), you could wind up with a very weak password. "passwordisreallylongsoimsafe" would be unlocked with "password", which is fairly early in the dictionary attacks I've seen.
I normally think it's acceptable to trade entropy density for memorability: English is fairly low entropy, but I can remember a 12-word passphrase without too much trouble, so the total entropy is OK compared to a line-noise 8 character string. But that requires the hashing functions work with the complete input; so on systems which still use crypt(3C) or something like it, I go with the line-noise.
OK; my fastest SATA drives will do an average of 80 MB/s across the platter; they peak at 125 MB/s at the outer rim. On SATA, with a PCI-Express SAS card, they actually run at the advertised speeds. Actually, 4 drives at a time will run at those speeds; when I get 6 going at once, I see the average _on all 6 drives_ drop to about 60 MB/s. Which makes me very very very happy with that card, mind you; it blows the Promise TX4 PCI card into little pieces of slow crap.
Those same drives in a USB 2.0 chassis will write all day at ~40 MB/s; you never get the peak speed at the rim, but then, since the USB line is the bottleneck, you don't get the drop at the hub, either. Obviously there isn't much else happening on that USB controller channel, and it's in the southbridge.
So if you're getting a 20x difference between USB 2.0 and eSATA, it's probably more the case that your eSATA connection is on a much better-performing bus device, and/or you've got too much contention for USB. Which doesn't negate eSATA solving your problem, of course.
But on a laptop, typically you're not going to have hub-webs of USB devices, so 2.0 is fair. 3.0/eSATA would be better, but FireWire 800 is nice instead, and all your legacy FireWire 400 and DV gear works with that, too.
Especially given the insides of the MacBook family. They are full; adding any connector would mean asking, "What should we remove?" It's really amazing to look inside one, there's no "gap" where you could fit another feature. It really is like a unibody car design; the case is both structure and enclosure.
Just remember to align your screwdriver with the slightly-angled screws properly, or you'll risk cross-threading and that would be bad.
Now, I recently stuck some last-generation Seagate 750 MB PATA drives in some FireWire enclosures on a dodgy controller on Linux. Those things aren't doing well; about 20 MB/s tops. The controller is probably crap. I'm also pretty sure the PCI Express to PCI bridge on my mainboard is crap, too; so you really don't want to push data through PCI on it. The enclosures have USB2.0 as well, so I really should try that; or one of the other FireWire controllers in the junk-pile.
I suspect crappy PCI bridges are very common, even though it's very hard to find a mainboard without PCI slots.