When used for its one and only legitimate purpose, the SSN has no need for strong protection. Who's going to be idiot enough to deliberately pay taxes into someone *else's* retirement account? The whole system is designed around the notion that there's no incentive to steal SSNs. That's why there's no photo on the card, and in fact you almost never need to show the card -- you can recite any nine-digit number that passes the checksum test and it will be accepted without question. If you call that secure, I hope you don't work for my bank.
A "universal" ID system will have to be much, much stronger or it will be worthless. No, less than worthless -- a weak ID system would have negative value.
There probably is a way to decentralize the system so that you can't scoop all of the accounts or all of the columns with one penetration. The more subsystems you have to enter, the more alarms you will trip. But there will still have to be a predefined process for unwinding system compromises and regaining trust, because it will be penetrated eventually. And there will have to be substantial reserves backing up an indemnification of some sort, so it may be possible to design and build the system for free but it sure ain't gonna *operate* for free.
Actually the power grid is an iffy example because it is already a distributed network both physically and administratively. It does seem to be fragile at the moment, but that's because there's sort of a priority inversion in its operating rules. The Three Laws of Distributed Infrastructure:
1. My network must protect its own existence. 2. My network must support the uninterrupted operation of its partners, except where that would conflict with the First Law. 3. My network must facilitate load sharing for financial purposes, except where that would conflict with the First or Second Laws.
If your neighbor's network is failing, it's your responsibility to *let it fail*, and then help to pick up the pieces so that subscribers all have power restored quickly. But the grid today is run mostly for the purpose of implementing the Third Law, and they don't drop the interconnects until it's too late.
Actually I can't think of any Java programs which are noticeably slow once they are running. However, it takes Java just this side of forever to heave itself into memory and settle in before the app. starts, even with a box on which most other (non-Gnome) graphical app.s blink on instantly.
I would love to know what the JRE, Mozilla, OpenOffice, etc. *do* with all of the billions of cycles they spend before anything appears.
That looks like becoming the new direction at NASA: transfer the solved problems to industry and get back into the business of doing stuff that doesn't yet have a market value.
See, that's exactly the problem. You glorify exploration and the drive to understand that way, and sooner or later some kid is going to want to do some himself. And we can't have that, can we.
Stuff 'em down the memory hole -- we've got more important things to do than learn.
I can't think of a better use for it than to clean it up and continue to remind ourselves that once upon a time we had the guts to do something really splendid.
Oh, dear, I can see it now: someone takes a close look and discovers that all the algae, weeds, etc. are endangered species and organizes a protest to forbid washing the thing.:-P
So is there some design document somewhere which lays out what all the this.js, that.js, t'other.na*, $dingus.rdf, cert[123456789].db etc. are and how they're used?
This raises an important point. The profile importer should not be in the installer; it should be in the product itself. I should be able to (re)import portions of old or alternate profiles at any time. I might have totally trashed my profile and want to recover bits from a backup done when I had a previous version, for example. Or I might want to merge in a copy of a profile from another machine. The possibilities are many; sadly the capabilities are one and you only get one try.
As for documenting the profile layout: hear, hear! Then I could write my own bloody profile tools. (UTSL does not work; I tried, and went nuts descending through thousands of layers of "method A rearranges its arguments, calls method B, then returns what B returned. Method B rearranges its arguments and calls method C, then returns what C returned.")
So, can I pay a sensible price for online access to news and get a contract with the publisher saying that for consideration received he promises not to release my personal data to anyone for any reason ever (barring court orders)? With none of those "ha-ha,we can change the rules at any time and there's nothing you can do about it" clauses? Oh, and the no-release clause should survive the termination of the contract, too.
I might also pay a small premium to be *guaranteed* no flashing, moving, or noisy ad.s.
Okay, I applaud you for being in the tiny minority of MS Windows users who try to be good citizens and manage their machines properly. Unfortunately the thousands who do still have to suffer from the indifference or timidity of the millions who don't. The world needs more like you and fewer of the other sort.
It isn't just Japan. Read Mark Twain's little essay on getting around Munich (was it "the German Chicago"?) for some venting on the subject of street signs.
Oh, my, that's getting into "isn't even wrong" territory. Let's see: verb and subject don't agree; in polite conversation you *never* ask someone whether he desires something without using the subjunctive; "wurden" throws the sentence into the subjunctive mood anyway; "mit dem" *what*?; and isn't "pommes frites" French?
I'm still waiting for someone to convince me that packet voice makes sense -- that it won't be made useless by dropouts, garbles, stalls, etc. just like RealAudio, Quicktime, et al. Packet networks are designed to get the message there eventually. You can hit congestion or have a packet trashed in flight at any time, and then you have two options: wait or do without. Either choice destroys the continuity of a voice connection.
Lest you think I'm just suffering from some horrible slow noisy dialup, and a shiny new DSL drop would make my problems all go away: I test this stuff at work (yes, testing multimedia players is part of my job), and I'm colocated with the NOC for a big swathe of Internet 2, with inconceivable bandwidth leading off in all directions. The problem ain't *my* connection, and that's the only part of the path which I control.
Spend hundreds of man-years adding to Linux all the stuff that makes MS Windows heavy and slow, and surprise! the result is heavy and slow.
One of the reasons I migrated to Linux was to get *away* from all that frosting. The app.s I use do their jobs whether I have a "desktop environment" or not, and having used both ways I definitely prefer not. fvwm is at least as much as I need to control these boxes.
Even the stuff I run could be improved, though, if so many programs weren't each dependent on dozens of fat Gnome libraries which then have to be kept updated even though I don't use Gnome. *Those* app.s are slow even though everything else is fast.
I've been watching space probe operations since the 1960s. They always say, "Mission X will last a maximum of six weeks" and then five years later we are still getting useful data from the thing. Their estimation skills are almost as poor as mine.:-/
It remains to be seen just what SCO would have to sell in the way of "Unix rights". Apparently Novell still owns Unix System V and merely permits SCO to take a small percentage in exchange for selling it on Novell's behalf. There's some suggestion that SCO may own the System V *documentation*. The name "Unix" belongs to yet another party.
And don't forget that IBM has its own breach of contract countersuit waiting in the wings. They may get everything SCO has left, including whatever "Unix rights" SCO turn out to have, when they win that one. Or they could beat SCO down to the point that, when RHAT win *their* suit, *they* get the "Unix rights" in lieu of the cash SCO no longer has.
Read SCO's recent court filings. They think they own every bit of every Unix *and anything you add to it*. Rewrite the allegedly-infringing bits (assuming you can get SCO to tell you what, specifically, they are on about) and they will claim ownership of the replacement.
When used for its one and only legitimate purpose, the SSN has no need for strong protection. Who's going to be idiot enough to deliberately pay taxes into someone *else's* retirement account? The whole system is designed around the notion that there's no incentive to steal SSNs. That's why there's no photo on the card, and in fact you almost never need to show the card -- you can recite any nine-digit number that passes the checksum test and it will be accepted without question. If you call that secure, I hope you don't work for my bank.
A "universal" ID system will have to be much, much stronger or it will be worthless. No, less than worthless -- a weak ID system would have negative value.
There probably is a way to decentralize the system so that you can't scoop all of the accounts or all of the columns with one penetration. The more subsystems you have to enter, the more alarms you will trip. But there will still have to be a predefined process for unwinding system compromises and regaining trust, because it will be penetrated eventually. And there will have to be substantial reserves backing up an indemnification of some sort, so it may be possible to design and build the system for free but it sure ain't gonna *operate* for free.
Actually the power grid is an iffy example because it is already a distributed network both physically and administratively. It does seem to be fragile at the moment, but that's because there's sort of a priority inversion in its operating rules. The Three Laws of Distributed Infrastructure:
1. My network must protect its own existence.
2. My network must support the uninterrupted operation of its partners, except where that would conflict with the First Law.
3. My network must facilitate load sharing for financial purposes, except where that would conflict with the First or Second Laws.
If your neighbor's network is failing, it's your responsibility to *let it fail*, and then help to pick up the pieces so that subscribers all have power restored quickly. But the grid today is run mostly for the purpose of implementing the Third Law, and they don't drop the interconnects until it's too late.
"Specifications"? Where *have* you been. "Code first, design later (or never), and sneer at anyone who asks for documentation" is the new paradigm.
Actually I can't think of any Java programs which are noticeably slow once they are running. However, it takes Java just this side of forever to heave itself into memory and settle in before the app. starts, even with a box on which most other (non-Gnome) graphical app.s blink on instantly.
I would love to know what the JRE, Mozilla, OpenOffice, etc. *do* with all of the billions of cycles they spend before anything appears.
Well, keep it to yourself until you get over it. Some of us still believe that we are capable of great things if we're willing to do the work.
That looks like becoming the new direction at NASA: transfer the solved problems to industry and get back into the business of doing stuff that doesn't yet have a market value.
See, that's exactly the problem. You glorify exploration and the drive to understand that way, and sooner or later some kid is going to want to do some himself. And we can't have that, can we.
Stuff 'em down the memory hole -- we've got more important things to do than learn.
Sure, burn down all the museums, raze all the libraries. None of them have anything to do with making granola so they're useless.
Not!
I can't think of a better use for it than to clean it up and continue to remind ourselves that once upon a time we had the guts to do something really splendid.
We paid attention in third-grade spelling class. What's wrong with you?
Oh, dear, I can see it now: someone takes a close look and discovers that all the algae, weeds, etc. are endangered species and organizes a protest to forbid washing the thing. :-P
*sigh* Yeah, I must've been having a flashback from the hours I spent getting Netscape 7 tucked in. Sorry.
You obviously don't understand benchmarking. The first rule of benchmarking is to compare your product only to something you know you can beat.
So is there some design document somewhere which lays out what all the this.js, that.js, t'other.na*, $dingus.rdf, cert[123456789].db etc. are and how they're used?
This raises an important point. The profile importer should not be in the installer; it should be in the product itself. I should be able to (re)import portions of old or alternate profiles at any time. I might have totally trashed my profile and want to recover bits from a backup done when I had a previous version, for example. Or I might want to merge in a copy of a profile from another machine. The possibilities are many; sadly the capabilities are one and you only get one try.
As for documenting the profile layout: hear, hear! Then I could write my own bloody profile tools. (UTSL does not work; I tried, and went nuts descending through thousands of layers of "method A rearranges its arguments, calls method B, then returns what B returned. Method B rearranges its arguments and calls method C, then returns what C returned.")
So, can I pay a sensible price for online access to news and get a contract with the publisher saying that for consideration received he promises not to release my personal data to anyone for any reason ever (barring court orders)? With none of those "ha-ha,we can change the rules at any time and there's nothing you can do about it" clauses? Oh, and the no-release clause should survive the termination of the contract, too.
I might also pay a small premium to be *guaranteed* no flashing, moving, or noisy ad.s.
Okay, I applaud you for being in the tiny minority of MS Windows users who try to be good citizens and manage their machines properly. Unfortunately the thousands who do still have to suffer from the indifference or timidity of the millions who don't. The world needs more like you and fewer of the other sort.
It isn't just Japan. Read Mark Twain's little essay on getting around Munich (was it "the German Chicago"?) for some venting on the subject of street signs.
Because so many other companies recently haven't. That's sort of set the tone for any new commercial product incorporating Linux.
Obviously you are unacquainted with KFC's prices nowadays.
Oh, my, that's getting into "isn't even wrong" territory. Let's see: verb and subject don't agree; in polite conversation you *never* ask someone whether he desires something without using the subjunctive; "wurden" throws the sentence into the subjunctive mood anyway; "mit dem" *what*?; and isn't "pommes frites" French?
I'm still waiting for someone to convince me that packet voice makes sense -- that it won't be made useless by dropouts, garbles, stalls, etc. just like RealAudio, Quicktime, et al. Packet networks are designed to get the message there eventually. You can hit congestion or have a packet trashed in flight at any time, and then you have two options: wait or do without. Either choice destroys the continuity of a voice connection.
Lest you think I'm just suffering from some horrible slow noisy dialup, and a shiny new DSL drop would make my problems all go away: I test this stuff at work (yes, testing multimedia players is part of my job), and I'm colocated with the NOC for a big swathe of Internet 2, with inconceivable bandwidth leading off in all directions. The problem ain't *my* connection, and that's the only part of the path which I control.
Spend hundreds of man-years adding to Linux all the stuff that makes MS Windows heavy and slow, and surprise! the result is heavy and slow.
One of the reasons I migrated to Linux was to get *away* from all that frosting. The app.s I use do their jobs whether I have a "desktop environment" or not, and having used both ways I definitely prefer not. fvwm is at least as much as I need to control these boxes.
Even the stuff I run could be improved, though, if so many programs weren't each dependent on dozens of fat Gnome libraries which then have to be kept updated even though I don't use Gnome. *Those* app.s are slow even though everything else is fast.
I've been watching space probe operations since the 1960s. They always say, "Mission X will last a maximum of six weeks" and then five years later we are still getting useful data from the thing. Their estimation skills are almost as poor as mine. :-/
It remains to be seen just what SCO would have to sell in the way of "Unix rights". Apparently Novell still owns Unix System V and merely permits SCO to take a small percentage in exchange for selling it on Novell's behalf. There's some suggestion that SCO may own the System V *documentation*. The name "Unix" belongs to yet another party.
And don't forget that IBM has its own breach of contract countersuit waiting in the wings. They may get everything SCO has left, including whatever "Unix rights" SCO turn out to have, when they win that one. Or they could beat SCO down to the point that, when RHAT win *their* suit, *they* get the "Unix rights" in lieu of the cash SCO no longer has.
Read SCO's recent court filings. They think they own every bit of every Unix *and anything you add to it*. Rewrite the allegedly-infringing bits (assuming you can get SCO to tell you what, specifically, they are on about) and they will claim ownership of the replacement.