I think you mis-understand me. It's not a question of interrupting the signal at a local level. It's that when the local broadcast operator built their transmitter infrastructure, I would guess they assumed that there would only be a single signal for a given "station", both NTSC and ATSC. I'm thinking the equipment probably doesn't have the capability of sometimes transmitting different source signals. There's probably one communications path from the broadcast studio to the transmitter. Why would they design for two?
"I never did figure out why they simulcast the 'How to switch' PSAs on their digital channels."
I'm just guessing, but I assume it's because otherwise they'd have to have twice the signal distribution infrastructure upstream from the transmitters (one with the PSA for analog, one with something else for digital). And only for the few months the PSAs are being broadcast. That's a lot of cost they wouldn't want to buy. I don't blame them.
"You are under the illusion that an SSL cert (ought to) assert(s) meatspace identity"
I believe that SSL certificates that don't assert *something* about meatspace aren't worth the paper they're printed on.
Yes, this means that I believe current SSL certificates are almost worthless. I was taking that as a given, and I think I made that clear enough.
"You are mixing / begging the question on a few concepts here, including: - granularity of identification - strength of identification verification - reputation"
Granularity of identification isn't really something I was thinking about here.
Identification and reputation I do tend to consider together, mainly because identification without reputation isn't worth much, either. Nobody really cares that I'm "Benjamin Scott". What matters is what my name stands for. Do I keep my word? Do I pay my debts? And so on. Even if it's a matter of individual, one-on-one exchanges. You trust your friends/associates because they've proven to be trustworthy, not because you recognize their face.
A domain name without a reputation is worthless for the same reasons.
This holds even if we want to postulate the idea that an "anonymous" entity can prove itself trustworthy over time though its behavior, a la the cypherpunk wet dream. In that case, the anonymous entity itself becomes identity and reputation. We don't need a CA to validate that; the self-signed certificate we got back on day one is good enough.
To reiterate and summarize: A CA PKI without a mechanism for validating identity/reputation is worthless.
"It is up to us (and the browser makers [?]) to ensure that those policies are sufficient for our purposes."
I guess I would have to suppose that current policies are not sufficient for any practical purpose.
"I wouldn't expect the SSL cert to do anything more than verify that the site your connected to is, in fact, controlled by the person who registered the domain you're trying to connect to..."
Well, that would certainly justify putting SSL certs into DNS. But I have to wonder, what exactly does this get us, in practical terms? Anything at all? We've already established that merely registering an arbitrary domain is just about worthless, and that control of a particular domain is pretty weak. As a guess, I'd speculate it would be easier to hijack a domain from the registrar than it would be to intercept TCP connections to a web server. So I don't think SSL-certs-in-DNS would even be of much value to the small-time, private domain holder.
To be clear: I don't see significant value in current SSL certificates, either. It seems like mostly security theater to me. Lots of crypto is done, and lots of money changes hands, but is anything made significantly more secure?
"DNS is trusted... then, theoretically, public keys could be stored there."
That doesn't really address the original poster's objection to the current SSL PKI. DNSSEC is just lets resolvers be sure the DNS records they got are really the records from the publicly delegated nameservers. But the domain name registration process is even more wide-open than the SSL certificate process. People can register a domain name with no credentials at all. And changing the delegated nameservers generally just requires a username/password at the registrar; no cryptographically strong authentication there.
In short, it's just some random operator on the 'net whose only real credential is they paid the fee needed to register a domain name (or SSL certificate).
Don't get me wrong, SSL certs in DNSSEC does have some applications, especially for those who don't have a need for strong authentication but would would still like some basic crypto on general principles.
The real problem here is that "trust" is just a very hard problem. It's labor-intensive to establish trust. What should want? Two forms of ID? Credit references? Notarized forms? Personal appearance? Background check investigations?
The idea of "Extended Validation" SSL certificates seems like it might be a step in the right direction here, but I'm far from convinced it's actually going to prove in practice to be significantly better than "regular" SSL certificates.
Further, delegating the privilege of granting trust -- i.e., trusting someone else to establish trust for us, which is what we do with VeriSign, et. al. -- is that much harder. Now we're trusting a company -- whose interests aren't necessarily coincident with ours -- to authenticate others for us.
"By-the-way, when I asked "who" I was thinking that there will be some institutional thing with the keys locked away in some vault that requires multiple people to agree to open."
Even better is when the master key is split into multiple pieces. Each piece is independently encrypted and then stored in a physically secure location. Each piece/location gets a different person.
VeriSign claims this is how they protect their master keys, FWIW. I'm not sure I believe them.
Yah, they definitely went overboard with the pipes. But I thought this might have been an attempt at a homage: In the TOS, the corridor sets were basically featureless, except they would have random occasional orange piping. You generally couldn't see it on TV, but reportedly these pipes were often stenciled "GNDN", which stood for "Goes Nowhere Does Nothing" -- an in-joke by the set design crew. I think that might have inspired the plumping fetish. But they took it too far. I also thought of a brewery at one point.
And the scene with Neo-Scotty in the gratuitously transparent, gratuitously serpentine water pipes can only be described as laughable. I was laughing quite hard, but in the "at it, not with it" sense. I couldn't help thinking of that scene in Galaxy Quest where Tim Allen and Sigourney Weaver encounter the hallway full of crushing platforms, which was included just because the script of one episode featured such a thing.
Weaver: What is this thing? I mean, it serves no useful purpose for there to be a bunch of chompy, crushy things in the middle of a hallway. No, I mean we shouldn't have to do this, it makes no logical sense, why is it here? Allen: 'Cause it's on the television show. Weaver: Well forget it! I'm not doing it! This episode was badly written!
"I don't think disassembling the drives is part of their procedure."
I remembered that being permitted, provided certain requirements were met by the degaussing equipment. I just double-checked, the EPL and it seems there is more such equipment than I remembered. Perhaps things have improved since I last looked, or perhaps my memory was just faulty. I know we were only interested in the cheaper hand wands, which do require disassembly, so perhaps my memory magnified that part of the document.
You can find the NSA Evaluated Products List online:
"While you're having fun, note that there is a good chance that the degausser just fries the electronics (by inducing strong currents where they don't belong) but leaves the data on the platters intact"
Any degausser being used to sanitize a hard disk which contained classified information must be purchased from the NSA's Evaluated Products List, and used in accordance with NSA standards. Those typically include removing the platters from the drive enclosure and degaussing them individually. I'm pretty sure it's more than just the electronics. Mission objectives aside, the NSA knows what they are doing.
"These have been superceded by NIST Special Publication 800-88:"
NIST does not have jurisdiction over DoD. NIST 800-88 doesn't supersede 5220.22-M. 5220.22-M is still in effect; the most current edition is 2006. (See my post here for where to get it.) It doesn't specify methods, though; as far as I can tell, it never did.
Most DoD and NISP jurisdictions are under DSS authority; the DSS publishes their own Clearing and Sanitization Matrix for this sort of thing. I discuss that in that post, too.
GAH!! Not this again. DoD 5220.22-M, full title "National Industrial Security Program Operating Manual", more commonly called NISPOM, is not and never was a wipe standard. It is a 150 page document that covers all aspects of the National Industrial Security Program (NISP). NISP is the jurisdiction for most commercial contractors doing classified work. Sanitization is about two paragraphs in this document. In every edition published within the past 15 years or so, I've never seen seen it get into specifics about methods -- it just says the CSA (Cognizant Security Authority) gets to set them. I've seen one document of uncertain origin, dated 1995, which did provide a list of methods, but there were several options depending on the nature of the medium and the data.
Most NISP jurisdictions have to follow the DSS Clearing and Sanitization Matrix. As of ISL 2007-01 (Oct 2007), the C&SM does not permit overwriting for destruction. Only degaussing or physical destruction is acceptable.
Further, the degaussing standards require one to remove and degauss each individual platter. As someone else noted, degaussing a modern hard drive erases the factory formatting and renders it unusable.
For physical destruction, it's not enough to drill a hole through the platter, either. Every bit (pardon the pun) of surface area must be obliterated. Grinding, sandblasting, incineration, liquidation, vaporization, pulverization, etc.
"But the 6502? A lucky near-clone of the 6800 that was popular not because it was particularly innovative, but because it was cheap. The 8088? The bastard stepchild of the 8086 which lucked out in getting picked over the 68000 in the IBM PC."
The article is entitled, "25 Microchips That Shook the World". The criteria is chips which were influential in their impact. That doesn't necessarily mean they had clean or clever designs, or were particularly innovative, or even "good" by any objective measure. It means that they mattered in the course of industry.
You dismiss the 6502 because it's only innovation was low cost. That still counts, and arguably more than most other distinctions. The Ford Model T, the Apple II, the IBM-PC clones, even books printed on the Gutenberg printing press -- their big difference was that they were cheap enough to bring their products to a much wider market. Legions of people who couldn't afford technology before suddenly could.
The 8088's big feature was being in the right place at the right time, no doubt about it. But it still went on to propel the x86 in to being the dominant architecture for general-purpose computers today. Wintel uses it. Apple Mac uses it. Most free *nix boxes use it. Sun uses it in many of their products. Even supercomputers use it. Quite simply, x86 is everywhere. That's "world shaking" by any definition I can think of.
There's a lesson here, too. Many times engineers and geeks favor technically sophisticated or clean designs, and reject designs which don't meet those criteria, and loose big time when their theoretically "better" design loose out to a cheaper or more practical alternative. Call it "worst is better" if you like, but putting all your money on a horse that loses the race isn't good, either.
"Systems containing classified data are NEVER connected to the internet."
Who says it was classified? My guess is that this would be a contractor doing sensitive-but-unclassified work on a production UNCLASS network.
The WSJ even said someone said that avionics and other critical systems are on computers physically separated from the network. I'm guessing that would be the classified stuff.
Most DoD projects have a classified component and an unclassified component. Mainly for cost reasons.
"I strongly suspect that this is another case of fear mongering by an organization trying to get additional funding. "
To paraphrase Heinlein, "Never attribute to intent that which can be adequately explained by stupidity." I think somewhere, some security manager (or the PHB controlling the security money) screwed the pooch and is now in the process of being nailed to the wall for it. All that hammering prolly attracted notice.
"why the DoD has sensitive information hooked up to the net in any way"
Dollars to donuts, it's a contractor system. Prolly a network that never had more than corporate security standards applied to it. Maybe even the same systems the contractor uses for their civilian/commercial systems design.
DoD classified stuff is usually physically isolated from untrusted networks. (A so-called "air gap" firewall.)
The big problem US government faces today is that there's a huge amount of unclassified information out there that's still valuable. There are lots of rules for the classified stuff -- and just as important, jurisdiction to enforce those rules. The sensitive-but-unclassified stuff is much less standardized. Some installations will be a model of perfect security. Others... less so.
At the same time, there's a big push to keep as much stuff as possible unclassified, because the security measures mandated for classified stuff cost big bucks.
On a somewhat related note: I was somewhat amused to see the F-35 called the most expensive plane ever, right after the funding was cut for the previous most expensive plane ever (F-22 Raptor). Maybe part of the reason these planes are so expensive is that they keep reallocating the funding to different projects...
"You can't say you "support" a platform these days unless your tests pass on it."
Um, Mozilla is still a FOSS project, yes? So support is basically on a best-effort, volunteer basis anyway, right? It's not like they're promising Firefox will work for sure on Vista, and it's not like I get my money back if it doesn't. I could seem them saying "Hey, we're not going to go out of our way to fix problems that only show up on Windows 2000", but the use of the term "support" seems strange. They're taking away the nothing they already promise.
So, like, if someone submits a patch to fix a bug that shows only up on Win 2000, does that mean the patch will be rejected?
"Supporting it also means crippling any software that wants to use APIs that later versions of the platform supports. "
Firefox already runs on several different platforms, including the radically different Windows and *nix, and the fairly different Mac OS X and traditional *nix, plus all the many *nix variants. It's already multi-platform all over the place, and already implements a great many things internally because they can't depend on the host OS providing any given function. They don't even appear to use the Windows native common dialogs; they appear to implement their own. So there isn't much difference across Windows versions that should matter to Firefox, I would think.
One thing that may be an issue, though, is the build toolchain. I don't know what tjhe Mozilla people are using, but I know Microsoft drops support in their compilers and other tools for old versions of Windows just like they do with everything else. So maybe it's a question of having to run two different toolchains to target older platforms. I could see where *that* would be a pain.
"Compared to existing technology (magnetic platters), the $/GB is still quite high."
Um... so it is, but it seems to me that your statement is kind of a non sequitur. My post is all about the pace of change, the the slope, how fast things change from "new" to "old". Not the current state.
"Something tells me the SSD scene is moving so fast that within literally 6 months one of these 2 companies (or a competitor taking note) will have a product superior in size, speed and price to those 2 very very soon."
And this is different from the rest of the computer hardware world how?:) Everything is always getting bigger, faster, cheaper, smaller, whatever.
One thing I've learned is that, in general, one should decide on a budget and make your purchase based on what's available today. Something better is *always* coming down the pike.:)
"That's no reason not to have a massive multi-path infrastructure within cities."
I saw someone on NANOG saying these cuts were in a narrow geographical corridor. In their words, "your paths are 'one side of the tracks' and 'the other side of the tracks'". Dunno if they're correct or full of it.
"PCs would always assume that the number of tracks was (eighty?) and the number of sectors was (something), regardless of what was actually written into a floppy's format descriptor thingy. "
That's because that's the only format stock MS-DOS could cope with. There wasn't any point in doing detection if it couldn't read such a diskette anyway.
Not everything bad in MS-DOS is due to brain damage; much of it is due to its incredibly limited functional capabilities. (This is not a complement.)
Yes, and that's been a danger since day one. The removable media should _never_ have been the default: it should have been the fallthrough boot medium,
On "day one" the *ONLY* option was "removable media".
Oh, I beg to differ. On "day one" the only option was no media.
The original consumer-market home micros (e.g., Apple ][, Commodore 64) didn't even come with a floppy drive. You had RAM and that was it. Maybe an audio cassette interface if you were lucky (I never could get that to work). I clearly remember being envious of the handful of Apple ]['s at school that had the floppy drive option kit (controller card and drive).
I'm sure I'm not the only one here on Slashdot who remembers spending hours typing in BASIC programs from source code listings in magazines, debugging the typos, and then finally getting the thing working, and then leave a note on the computer saying not to turn it off or reboot it, since there was no way to save all that work.
(I'm sure someone will want to come in here and belittle me for having the luxury of audio cassettes, or RAM, or electricity, or paper, or whatever. Folks, it's been done. At least provide an original anecdote if you must play the grandpa game.)
I remember getting my Tandy 1000 SL and being uber-impressed that it came with the MS-DOS core in ROM, so you could boot to a command prompt without even a floppy diskette. I never got asked to insert the disk with the command interpreter, thanks to that.
I also worked out that when working in the DeskMate word processor, if I wanted to open a file, I could type-ahead during program load to execute the File -> Open command, and send the "Retry diskette read" command three times. You see, if I sent a retry three times, that kept the floppy disk spindle motor going long enough while I was changing diskettes (switching from program disk to data disk). Retaining that angular momentum shaved a good 0.75 seconds off the time it took to load the directory from my data diskette. Whoo-who! Now we're flying...
"problem: some users are idiots solution: treat all users like idiots"
Close but not quite. That should be:
Problem: Almost all users are idiots
As soon as you come to grips with that, many large organization decisions make sense. If they can help 80% of the customer base at the cost of annoying 5% of the customer base, they'll do it, every time. (The 15% margin is for people aren't total morons and might fall on either side.)
"POSIX may allow it, but I was under the impression that filesystems should try and remain in a sane state."
You're asking for all I/O operations to be done serially. Linux doesn't do this today, and I don't think it has for more than a decade. Most OSes don't do this. The reason is performance. If you've got a bunch of writes to do in one part of the disk, you do them all there, and then do all the other writes for another part of the disk. Thus writes can be done out-of-order. This is called "I/O scheduling" or "elevator algorithm". If you've got multiple tasks doing serious I/O to the disk, you really want it.
If you want a way to for an application to request a group of operations to be done atomically, that's called a transaction. I wrote about that in my cousin post.
Slashdot Mirror
I think you mis-understand me. It's not a question of interrupting the signal at a local level. It's that when the local broadcast operator built their transmitter infrastructure, I would guess they assumed that there would only be a single signal for a given "station", both NTSC and ATSC. I'm thinking the equipment probably doesn't have the capability of sometimes transmitting different source signals. There's probably one communications path from the broadcast studio to the transmitter. Why would they design for two?
"I never did figure out why they simulcast the 'How to switch' PSAs on their digital channels."
I'm just guessing, but I assume it's because otherwise they'd have to have twice the signal distribution infrastructure upstream from the transmitters (one with the PSA for analog, one with something else for digital). And only for the few months the PSAs are being broadcast. That's a lot of cost they wouldn't want to buy. I don't blame them.
"You are under the illusion that an SSL cert (ought to) assert(s) meatspace identity"
I believe that SSL certificates that don't assert *something* about meatspace aren't worth the paper they're printed on.
Yes, this means that I believe current SSL certificates are almost worthless. I was taking that as a given, and I think I made that clear enough.
"You are mixing / begging the question on a few concepts here, including:
- granularity of identification
- strength of identification verification
- reputation"
Granularity of identification isn't really something I was thinking about here.
Identification and reputation I do tend to consider together, mainly because identification without reputation isn't worth much, either. Nobody really cares that I'm "Benjamin Scott". What matters is what my name stands for. Do I keep my word? Do I pay my debts? And so on. Even if it's a matter of individual, one-on-one exchanges. You trust your friends/associates because they've proven to be trustworthy, not because you recognize their face.
A domain name without a reputation is worthless for the same reasons.
This holds even if we want to postulate the idea that an "anonymous" entity can prove itself trustworthy over time though its behavior, a la the cypherpunk wet dream. In that case, the anonymous entity itself becomes identity and reputation. We don't need a CA to validate that; the self-signed certificate we got back on day one is good enough.
To reiterate and summarize: A CA PKI without a mechanism for validating identity/reputation is worthless.
"It is up to us (and the browser makers [?]) to ensure that those policies are sufficient for our purposes."
I guess I would have to suppose that current policies are not sufficient for any practical purpose.
"I wouldn't expect the SSL cert to do anything more than verify that the site your connected to is, in fact, controlled by the person who registered the domain you're trying to connect to..."
Well, that would certainly justify putting SSL certs into DNS. But I have to wonder, what exactly does this get us, in practical terms? Anything at all? We've already established that merely registering an arbitrary domain is just about worthless, and that control of a particular domain is pretty weak. As a guess, I'd speculate it would be easier to hijack a domain from the registrar than it would be to intercept TCP connections to a web server. So I don't think SSL-certs-in-DNS would even be of much value to the small-time, private domain holder.
To be clear: I don't see significant value in current SSL certificates, either. It seems like mostly security theater to me. Lots of crypto is done, and lots of money changes hands, but is anything made significantly more secure?
"DNS is trusted ... then, theoretically, public keys could be stored there."
That doesn't really address the original poster's objection to the current SSL PKI. DNSSEC is just lets resolvers be sure the DNS records they got are really the records from the publicly delegated nameservers. But the domain name registration process is even more wide-open than the SSL certificate process. People can register a domain name with no credentials at all. And changing the delegated nameservers generally just requires a username/password at the registrar; no cryptographically strong authentication there.
In short, it's just some random operator on the 'net whose only real credential is they paid the fee needed to register a domain name (or SSL certificate).
Don't get me wrong, SSL certs in DNSSEC does have some applications, especially for those who don't have a need for strong authentication but would would still like some basic crypto on general principles.
The real problem here is that "trust" is just a very hard problem. It's labor-intensive to establish trust. What should want? Two forms of ID? Credit references? Notarized forms? Personal appearance? Background check investigations?
The idea of "Extended Validation" SSL certificates seems like it might be a step in the right direction here, but I'm far from convinced it's actually going to prove in practice to be significantly better than "regular" SSL certificates.
Further, delegating the privilege of granting trust -- i.e., trusting someone else to establish trust for us, which is what we do with VeriSign, et. al. -- is that much harder. Now we're trusting a company -- whose interests aren't necessarily coincident with ours -- to authenticate others for us.
"By-the-way, when I asked "who" I was thinking that there will be some institutional thing with the keys locked away in some vault that requires multiple people to agree to open."
Even better is when the master key is split into multiple pieces. Each piece is independently encrypted and then stored in a physically secure location. Each piece/location gets a different person.
VeriSign claims this is how they protect their master keys, FWIW. I'm not sure I believe them.
"Somebody likes plumbing too much. "
Yah, they definitely went overboard with the pipes. But I thought this might have been an attempt at a homage: In the TOS, the corridor sets were basically featureless, except they would have random occasional orange piping. You generally couldn't see it on TV, but reportedly these pipes were often stenciled "GNDN", which stood for "Goes Nowhere Does Nothing" -- an in-joke by the set design crew. I think that might have inspired the plumping fetish. But they took it too far. I also thought of a brewery at one point.
And the scene with Neo-Scotty in the gratuitously transparent, gratuitously serpentine water pipes can only be described as laughable. I was laughing quite hard, but in the "at it, not with it" sense. I couldn't help thinking of that scene in Galaxy Quest where Tim Allen and Sigourney Weaver encounter the hallway full of crushing platforms, which was included just because the script of one episode featured such a thing.
Weaver: What is this thing? I mean, it serves no useful purpose for there to be a bunch of chompy, crushy things in the middle of a hallway. No, I mean we shouldn't have to do this, it makes no logical sense, why is it here?
Allen: 'Cause it's on the television show.
Weaver: Well forget it! I'm not doing it! This episode was badly written!
"I don't think disassembling the drives is part of their procedure."
I remembered that being permitted, provided certain requirements were met by the degaussing equipment. I just double-checked, the EPL and it seems there is more such equipment than I remembered. Perhaps things have improved since I last looked, or perhaps my memory was just faulty. I know we were only interested in the cheaper hand wands, which do require disassembly, so perhaps my memory magnified that part of the document.
You can find the NSA Evaluated Products List online:
http://www.nsa.gov/ia/_files/Government/MDG/NSA_CSS-EPL-9-12.PDF
"While you're having fun, note that there is a good chance that the degausser just fries the electronics (by inducing strong currents where they don't belong) but leaves the data on the platters intact"
Any degausser being used to sanitize a hard disk which contained classified information must be purchased from the NSA's Evaluated Products List, and used in accordance with NSA standards. Those typically include removing the platters from the drive enclosure and degaussing them individually. I'm pretty sure it's more than just the electronics. Mission objectives aside, the NSA knows what they are doing.
"These have been superceded by NIST Special Publication 800-88:"
NIST does not have jurisdiction over DoD. NIST 800-88 doesn't supersede 5220.22-M. 5220.22-M is still in effect; the most current edition is 2006. (See my post here for where to get it.) It doesn't specify methods, though; as far as I can tell, it never did.
Most DoD and NISP jurisdictions are under DSS authority; the DSS publishes their own Clearing and Sanitization Matrix for this sort of thing. I discuss that in that post, too.
"Taken from DoD 5220.22-M Wipe Standard:"
GAH!! Not this again. DoD 5220.22-M, full title "National Industrial Security Program Operating Manual", more commonly called NISPOM, is not and never was a wipe standard. It is a 150 page document that covers all aspects of the National Industrial Security Program (NISP). NISP is the jurisdiction for most commercial contractors doing classified work. Sanitization is about two paragraphs in this document. In every edition published within the past 15 years or so, I've never seen seen it get into specifics about methods -- it just says the CSA (Cognizant Security Authority) gets to set them. I've seen one document of uncertain origin, dated 1995, which did provide a list of methods, but there were several options depending on the nature of the medium and the data.
You can download the NISPOM from the official source here: https://www.dss.mil/GW/ShowBinary/DSS/isp/fac_clear/download_nispom.html Sanitization is Section 8-301(b) on page 8-3-1 (ordinal page 75).
Most NISP jurisdictions have to follow the DSS Clearing and Sanitization Matrix. As of ISL 2007-01 (Oct 2007), the C&SM does not permit overwriting for destruction. Only degaussing or physical destruction is acceptable.
Further, the degaussing standards require one to remove and degauss each individual platter. As someone else noted, degaussing a modern hard drive erases the factory formatting and renders it unusable.
For physical destruction, it's not enough to drill a hole through the platter, either. Every bit (pardon the pun) of surface area must be obliterated. Grinding, sandblasting, incineration, liquidation, vaporization, pulverization, etc.
"But the 6502? A lucky near-clone of the 6800 that was popular not because it was particularly innovative, but because it was cheap. The 8088? The bastard stepchild of the 8086 which lucked out in getting picked over the 68000 in the IBM PC."
The article is entitled, "25 Microchips That Shook the World". The criteria is chips which were influential in their impact. That doesn't necessarily mean they had clean or clever designs, or were particularly innovative, or even "good" by any objective measure. It means that they mattered in the course of industry.
You dismiss the 6502 because it's only innovation was low cost. That still counts, and arguably more than most other distinctions. The Ford Model T, the Apple II, the IBM-PC clones, even books printed on the Gutenberg printing press -- their big difference was that they were cheap enough to bring their products to a much wider market. Legions of people who couldn't afford technology before suddenly could .
The 8088's big feature was being in the right place at the right time, no doubt about it. But it still went on to propel the x86 in to being the dominant architecture for general-purpose computers today. Wintel uses it. Apple Mac uses it. Most free *nix boxes use it. Sun uses it in many of their products. Even supercomputers use it. Quite simply, x86 is everywhere. That's "world shaking" by any definition I can think of.
There's a lesson here, too. Many times engineers and geeks favor technically sophisticated or clean designs, and reject designs which don't meet those criteria, and loose big time when their theoretically "better" design loose out to a cheaper or more practical alternative. Call it "worst is better" if you like, but putting all your money on a horse that loses the race isn't good, either.
"Ninjas don't leave evidence nor any other trace , kinda part of being a ninja. "
Then how the hell do we know about Ninjas in the first place?
Reminds me of every time someone on the news talks about a "secret government project". If it's so bloody secret, why's it on the news? :)
"Systems containing classified data are NEVER connected to the internet."
Who says it was classified? My guess is that this would be a contractor doing sensitive-but-unclassified work on a production UNCLASS network.
The WSJ even said someone said that avionics and other critical systems are on computers physically separated from the network. I'm guessing that would be the classified stuff.
Most DoD projects have a classified component and an unclassified component. Mainly for cost reasons.
"I strongly suspect that this is another case of fear mongering by an organization trying to get additional funding. "
To paraphrase Heinlein, "Never attribute to intent that which can be adequately explained by stupidity." I think somewhere, some security manager (or the PHB controlling the security money) screwed the pooch and is now in the process of being nailed to the wall for it. All that hammering prolly attracted notice.
"why the DoD has sensitive information hooked up to the net in any way"
Dollars to donuts, it's a contractor system. Prolly a network that never had more than corporate security standards applied to it. Maybe even the same systems the contractor uses for their civilian/commercial systems design.
DoD classified stuff is usually physically isolated from untrusted networks. (A so-called "air gap" firewall.)
The big problem US government faces today is that there's a huge amount of unclassified information out there that's still valuable. There are lots of rules for the classified stuff -- and just as important, jurisdiction to enforce those rules. The sensitive-but-unclassified stuff is much less standardized. Some installations will be a model of perfect security. Others... less so.
At the same time, there's a big push to keep as much stuff as possible unclassified, because the security measures mandated for classified stuff cost big bucks.
On a somewhat related note: I was somewhat amused to see the F-35 called the most expensive plane ever, right after the funding was cut for the previous most expensive plane ever (F-22 Raptor). Maybe part of the reason these planes are so expensive is that they keep reallocating the funding to different projects...
"You can't say you "support" a platform these days unless your tests pass on it."
Um, Mozilla is still a FOSS project, yes? So support is basically on a best-effort, volunteer basis anyway, right? It's not like they're promising Firefox will work for sure on Vista, and it's not like I get my money back if it doesn't. I could seem them saying "Hey, we're not going to go out of our way to fix problems that only show up on Windows 2000", but the use of the term "support" seems strange. They're taking away the nothing they already promise.
So, like, if someone submits a patch to fix a bug that shows only up on Win 2000, does that mean the patch will be rejected?
"Supporting it also means crippling any software that wants to use APIs that later versions of the platform supports. "
Firefox already runs on several different platforms, including the radically different Windows and *nix, and the fairly different Mac OS X and traditional *nix, plus all the many *nix variants. It's already multi-platform all over the place, and already implements a great many things internally because they can't depend on the host OS providing any given function. They don't even appear to use the Windows native common dialogs; they appear to implement their own. So there isn't much difference across Windows versions that should matter to Firefox, I would think.
One thing that may be an issue, though, is the build toolchain. I don't know what tjhe Mozilla people are using, but I know Microsoft drops support in their compilers and other tools for old versions of Windows just like they do with everything else. So maybe it's a question of having to run two different toolchains to target older platforms. I could see where *that* would be a pain.
"Compared to existing technology (magnetic platters), the $/GB is still quite high."
Um... so it is, but it seems to me that your statement is kind of a non sequitur. My post is all about the pace of change, the the slope, how fast things change from "new" to "old". Not the current state.
"Something tells me the SSD scene is moving so fast that within literally 6 months one of these 2 companies (or a competitor taking note) will have a product superior in size, speed and price to those 2 very very soon."
And this is different from the rest of the computer hardware world how? :) Everything is always getting bigger, faster, cheaper, smaller, whatever.
One thing I've learned is that, in general, one should decide on a budget and make your purchase based on what's available today. Something better is *always* coming down the pike. :)
"That's no reason not to have a massive multi-path infrastructure within cities."
I saw someone on NANOG saying these cuts were in a narrow geographical corridor. In their words, "your paths are 'one side of the tracks' and 'the other side of the tracks'". Dunno if they're correct or full of it.
"AmigaOS 1.0 did that"
Big deal. Could AmigaOS run x86 code without a bridge board? I didn't think so.
What's that? I'm asking for capabilities that don't exist in the hardware?
Thanks for making my point for me.
"PCs would always assume that the number of tracks was (eighty?) and the number of sectors was (something), regardless of what was actually written into a floppy's format descriptor thingy. "
That's because that's the only format stock MS-DOS could cope with. There wasn't any point in doing detection if it couldn't read such a diskette anyway.
Not everything bad in MS-DOS is due to brain damage; much of it is due to its incredibly limited functional capabilities. (This is not a complement.)
Yes, and that's been a danger since day one. The removable media should _never_ have been the default: it should have been the fallthrough boot medium,
On "day one" the *ONLY* option was "removable media".
Oh, I beg to differ. On "day one" the only option was no media.
The original consumer-market home micros (e.g., Apple ][, Commodore 64) didn't even come with a floppy drive. You had RAM and that was it. Maybe an audio cassette interface if you were lucky (I never could get that to work). I clearly remember being envious of the handful of Apple ]['s at school that had the floppy drive option kit (controller card and drive).
I'm sure I'm not the only one here on Slashdot who remembers spending hours typing in BASIC programs from source code listings in magazines, debugging the typos, and then finally getting the thing working, and then leave a note on the computer saying not to turn it off or reboot it, since there was no way to save all that work.
(I'm sure someone will want to come in here and belittle me for having the luxury of audio cassettes, or RAM, or electricity, or paper, or whatever. Folks, it's been done. At least provide an original anecdote if you must play the grandpa game.)
I remember getting my Tandy 1000 SL and being uber-impressed that it came with the MS-DOS core in ROM, so you could boot to a command prompt without even a floppy diskette. I never got asked to insert the disk with the command interpreter, thanks to that.
I also worked out that when working in the DeskMate word processor, if I wanted to open a file, I could type-ahead during program load to execute the File -> Open command, and send the "Retry diskette read" command three times. You see, if I sent a retry three times, that kept the floppy disk spindle motor going long enough while I was changing diskettes (switching from program disk to data disk). Retaining that angular momentum shaved a good 0.75 seconds off the time it took to load the directory from my data diskette. Whoo-who! Now we're flying...
"problem: some users are idiots
solution: treat all users like idiots"
Close but not quite. That should be:
Problem: Almost all users are idiots
As soon as you come to grips with that, many large organization decisions make sense. If they can help 80% of the customer base at the cost of annoying 5% of the customer base, they'll do it, every time. (The 15% margin is for people aren't total morons and might fall on either side.)
"who's ever heard of clicking without looking?"
Heard of it? Hell, that's two-thirds of the malware problem, right there.
"POSIX may allow it, but I was under the impression that filesystems should try and remain in a sane state."
You're asking for all I/O operations to be done serially. Linux doesn't do this today, and I don't think it has for more than a decade. Most OSes don't do this. The reason is performance. If you've got a bunch of writes to do in one part of the disk, you do them all there, and then do all the other writes for another part of the disk. Thus writes can be done out-of-order. This is called "I/O scheduling" or "elevator algorithm". If you've got multiple tasks doing serious I/O to the disk, you really want it.
If you want a way to for an application to request a group of operations to be done atomically, that's called a transaction. I wrote about that in my cousin post.