If Apple wanted support for regular UNIX GUIs, they would integrate XDarwin into OSX--it could be done more easily and more transparently than Carbon or Java are integrated right now.
Apple wants people to port their applications to Cocoa. That's the only kind of GUI they want on OSX. They have said so. I think it's stupid. I think it makes OSX pretty unattractive for UNIX workstation users. But it's Apple's wish, and it's Apple strategy. I don't see any point in fighting it, and I don't see any point for open source efforts to waste any time on doing something Apple doesn't want in the first place.
For me, it means that I'm going to continue to use my Mac mostly as a decorative jukebox, and my Linux machine to replace my UNIX workstation.
A database system is defined by the language it supports. SQL systems are not, and cannot be, relational systems, because SQL violates fundamental principles of the relational model.
I think any reasonable database system and query language should be Turing complete. That means that, no matter what front-end you put onto it, you can express the same queries in it. And since they have to solve the same problems, any reasonable database system better perform well on those problems, too.
Yet I can tell you are committing a serious logical problem in equating SQL to relational.
I'm not equating SQL to relational. I am saying: SQL is just a query language.
Unproven? Let me see. This idea single-handledly changed its field overnight, obsoleted all other practices, forced everyone to redefine not only their ideas but their concepts and the very terms and methods they used to think about databases.
You're contradicting yourself. On the one hand, you claim it single-handedly changed the field, on the other hand, you claim nobody is actually implementing it. Which is it?
Hm? Is set theory and predicate logic enough evidence for you?
No. Good theoretical foundations are neither necessary nor sufficient for building good practical systems. Turing machines, for example, are wonderful and well-founded theoretical models of computation, yet we don't use them as the basis for designing programming languages.
Furthermore, there are many other ways for translating set theory and predicate calculus into database systems. Date and Darwen's approach seems woefully dusty and cumbersome; those guys are stuck somewhere in the 1960's, and they completely muddle up issues of syntax, data representation, algorithms, and abstractions.
Well, first of all, the chips have been shipping and benchmarked.
Furthermore, 64bit really matters to a lot of people; it's not just a few more instructions. And the other main alternative, Itanium, is hugely expensive, a pain to deploy, doesn't run a lot of software, and doesn't perform all that well.
Sure, AMD may still fail to pull this off for a variety of reasons. But it really looks to me like they are very serious about making it work.
It looks like Athlon64 performance is going to be quite good. But even if it weren't, I hope AMD wouldn't hold up the release of the Athlon64 over concerns with benchmarks. If the price is reasonable, we'd buy them right now even if they ran at half the speed of a top-of-the-line Pentium4. The ability to address greater than 4 Gbytes of memory directly just outweighs even fairly significant differences in raw CPU performance. In different words, even a slow pointer dereference is still a lot faster than read/seek/write.
No, you are thinking RDBMS == SQL, and that is not true. SQL is indeed too complex and slow,
No, I'm not. Don't tell me what I'm thinking. I said that RDBMSs are a horrible idea for a general purpose file system, and that's what I meant. SQL is a query language, not a database system.
Besides, the kinds of database engines that are sitting underneath SQL are what Microsoft claims they want to put into the file system.
The only true RDBMSs now existing is Alphora Dataphor, and it is not yet a full, portable DBMS.
Well, yeah, right: you and Alphora's marketing department think that.
Besides, the evidence that any more "pure" relational query language than SQL is better is thin at best. If you are going to redesign databases from scratch, there are better choices than either SQL or some unproven 1960's idea.
Patents used to be about specific technology: a way of accomplishing a desirable goal. These days, anybody who has a "wouldn't it be nifty if we could do X" patents it, no matter whether they have a clue of how to do "X" or not.
In fact, arguably a large chunk of furniture and clothes design is about "dynamically adapting" to the tastes and moods of the user. It's just that the most cost effective means so far have been manually operated.
Workstations based on the Itanium or SPARC capable of addressing more than 2-4Gbytes of RAM are very expensive (above $10k). IBM's Power4-based systems are even more expensive.
Lots of data-intensive applications desperately need more than 2Gbytes of RAM. If Opteron can deliver that for only a modest premium over regular Athlon-bsaed PCs, it will be a huge success. And if it can run existing binaries in 32bit mode and work with existing drivers, that's icing on the cake. There is just nothing else like it out there.
As soon as they come out, assuming Linux does run reasonably well on them and there are no unexpected show-stoppers, we are going to buy half a dozen of them. We want a Beowulf cluster of these.
Last I checked, Linux was desperately trying to clone Windows
There are several Linux projects to clone the appearance and behavior of the Windows desktop environment, to make people moving from Windows to Linux feel more comfortable. Nobody is trying to clone the Windows software architecture, however: all major Linux environments are properly layered on top of a POSIX kernel and the X11 window system.
so as not to remain completely irrelevant.
Linux is probably costing Microsoft half its server market, and, if anything, Microsoft is falling behind. Now, Linux is making inroads on the client as well.
Linux clients and servers require far less staff to install, support, maintain, update, and secure than Windows clients or server installations. That's in addition to not having to pay the steep Microsoft licensing fees, of course.
Microsoft management is scared, and they have reason to be.
I don't see Windows adding in bizarre installers, removing hardware support, or require convoluted commands for simple procedures like Linux, so I don't know what you're talking about.
Well, it's obvious that you don't know what I'm talking about.
In theory, object file systems, an object component environment and so forth CAN be a simplification of things.
Object storage is useful, but an object file system isn't merely object storage, it's object storage in the kernel. Does object storage need to be in the kernel? Does the kernel need to know how to invoke arbitrary user-defined methods on file system objects? I don't think so.
A modest amount of additional flexibility in the UNIX/Linux file system may be desirable. Plan9 lets you hook up a well-defined, fixed set of user-defined methods to file system objects. That may be a good idea, although it can still be done in user space (and perhaps is better done there). ReiserFS makes small files and large directories more efficient. Some additional kernel support permits change notification. Those are the kind of incremental changes to the proven concept of a "file system" that make sense to me. Taking an OODBMS or RDBMS and putting it into the kernel is asking for failure.
Oh, I think a "true RDBMS" is an absolutely horrible idea for a general purpose file system: it's way too complex and has way too much overhead. And it's been tried before several times and never caught on--for good reason, I think.
UNIX/Linux file systems are actually a database: a very specific kind of database. If the UNIX/Linux file system needs to evolve at all, it's in the ReiserFS and Plan9 directions. Those systems really do improve aspects of how file systems are used in the real world.
Removing command line editing? How is that an advantage? I use that constantly!
Command line editing and job control have been moved from shell built-ins into separate programs. That makes those capabilities much more easily reusable and extensible.
You can get something similar for Linux: "cle" is a generic command line editor, and "screen" is something like job control.
Desktop environments and graphical applications still crash a lot under GNU/Linux
Desktop environments like XFCE and IceWM are rock solid, as is the X11 server itself.
Gnome, Mozilla, OpenOffice, and KDE, of course, are works in progress, but no worse in my experience than what Microsoft ships. I still see "Send Bug Report to Microsoft" dialog boxes regularly on Windows XP, while I hardly ever see a GUI application crash on Linux.
Beyond that, there are, of course, plenty of buggy GUI applications for all platforms.
I'm sorry, but you are barking up the wrong tree. My argument was not about whether copying is good or bad; I happen to think copying can be quite good, actually: open source software and biological evolution both involve a lot of copying. I simply pointed out that the Microsoft GUI wasn't created in some long-term master plan, as NineNine claimed, but instead was a long series of short-term reactions to market pressures.
Yes, there are plenty of command line tools for system administration that come included with Windows. Nominally, you can do pretty much everything with them that you can from the GUI. In practice, however, you can't.
First of all, since most people use the GUI most of the time, if you want to move on to scripting, you have to learn both entirely new commands and figure out how to script them together. Not even the concepts and paradigms of how to manipulate the system are easily mapped onto one another.
Also, the command line tools don't seem to keep up with what's in the GUI, and any third party components that require administration often don't come with command line tools at all.
Finally, Windows doesn't ship with a lot of the glue necessary to make scripting work. Apart from the pathetic cmd.exe, most devices are not accessible through the file system and many important command line programs are just missing. Some come and go (NT used to come with pax.exe, but it seems to have disappeared now, leaving no archiver around).
It has nothing to do with luck. Embrace-and-extend works if, like Microsoft, you have a monopoly. And Microsoft didn't even earn that monopoly themselves, they got it handed for free by IBM.
I think that they DID make that tradeoff. I'm sure that by building a very solid GUI first wasn't accidental.
Leaving aside the question of what a "very solid GUI" might be or whether Microsoft can even remotely be argued to have one, you are ascribing too much long-range planning to Microsoft.
Microsoft responds to the market like a leaf in the wind. All their various approaches to GUIs were driven by a panicky reaction to competition. Their first GUI was a reaction to Macintosh. MFC was driven by the success of competitive object oriented GUI libraries. The 3D look was a reaction to Motif. GUI builders were a reaction to third party tools and NeXT. RDP was an attempt to clone X11's remote access features. And their latest, C#/CLR is basically a Java clone.
Now, Microsoft feels extremely threatened by Linux, both on the client and on the server, and they are desparately trying to clone the essence of Linux so that their servers won't become completely irrelevant.
Microsoft doesn't plan or strategize anything for the long term. Microsoft is driven by paranoia, "not invented here", and the usual geek attitude of "if we implement it, it will be better". Nothing could be further from the truth, of course.
they're going to absolutely pummel any competitors on the server end.
Microsoft already has their own scripting environment, and you can already get the most popular shell environments (Bash, Korn) for Windows for free. It doesn't help, because the system just isn't built for scripting.
They've got stability, they've got security, and now they're gonna have good scripting. Wow. Who would'a thunk?
Very funny. XP can be fairly stable and secure--if you dedicate machines to individual tasks and disable most multiuser features. Running Apache and ssh helps, too. But, compared to UNIX and Linux, XP's stability and security are still ridiculously poor. And that's not because lacks features, it's because it has too many features.
MS is #1 for a reason: they do what the users want.
Yeah: they collect every possible feature under the sun into a gigantic feature list. Then they hire away a number of experts from other companies that feel constrained not to be able to do what they wanted to do at their previous jobs and give them lots of money and programmers. And instead of having to compete for market share with their ideas, they just get to dump whatever they come up with into the Windows distribution. The result spells out "second system effect" in big letters.
Good design requires restraint and tradeoffs. It requires figuring out how to pick a small set of features that get most of the work done. It requires actually competing in the market place, where not only dysfunctional systems fail to find acceptance, but also systems that are too complex and big for mere humans to figure out. Microsoft completely lacks the taste, corporate culture, or ability to make those tradeoffs.
But you are right: this approach is indeed why they are number one. There are many morons out there who do indeed think that the longest feature list is what makes a system good.
I am sure Microsoft will do everything they promise, and as a result, their new shell will be absolutely awful. Microsoft's response to everything is "we'll implement something with more features, more technology". What they don't get is that simplicity and restraint is valuable in itself. You can see this throughout their systems. Their file systems are becoming databases. Their programming environment is fully object based and component based. Their file system protection allows you to specify arbitrary ACLs on arbitrary files. And on and on. In different words, just about every single one of Microsoft's products suffers from the "second system effect".
Look, in contrast, at the "next generation UNIX shell", rc, from Bell Labs. "rc" intends to simplify, remove unnecessary functionality, and factor out features like job control and command line editing.
Experiments with Farnsworth's "Fusor" in the early-to-mid 1960s were impressive but inconclusive: despite tremendous "neutron counts" (the evidence of fusion),
If it produces neutrons, some of those neutrons will escape, get captured, and produce radioactive waste. It may or may not be as bad as fission, but it's still a problem.
Regardless, Mitnick aside, I don't for a second believe the break-in described here had anything to do with clueless hackers. These were burglars who would just be going after other prizes if these were unavailable. I suspect an inside job, which is particularly hard to defend against.
I agree that these people probably were after the hardware and that it probably was an inside job. However, they may well re-sell the data now and find it more valuable than the hardware.
How the hardware was stolen shouldn't matter, however, for the security of the data: it is easy to ensure that data becomes inaccessible when hardware is physically removed. Not putting such mechanisms in place is where I think the company was negligent. (Similar comments apply to when criminals manage to steal credit card and customer databases from web sites--with a minimally security conscious design, that's trivial to prevent.)
Sadly, the same is true for many other companies. I think most companies probably don't even realize that they can protect the data in such cases; their "technologists" are lost somewhere in a haze of ASP/.NET/J2EE and can't be bothered with pesky details like disk encryption.
But if this became a high-profile prosecution of both the company and the CIO for mishandling of private data, resulting in stiff fines or worse, you can bet that other companies would (1) realize that they can do something to prevent this and (2) invest the modest amount of money necessary to deal with it.
Even a single infraction is worth $10,000. Expect to see some large fines by the end of 2003.
We'll see to what degree prosecutors will take advantage of this. In cases where there are existing laws (anything involving fiduciary duties), I have yet to see a high profile case prosecuted.
AFAIK, there are no laws for banks not to be morons, so comparing the two isn't really useful.
The concern in this case is not primarily about the health care information, it's about possible identity theft resulting from the availability of the information. Disclosure of health care information may be embarrassing and lead to discrimination, but identity theft can lead to instant ruin.
Existing liability law may well cover these cases already. The problem is enforcement: how many companies have been prosecuted under them? What large damage awards can you point to?
From my own experience, I can tell you that when my bank exposed my financial records through lousy on-line security and exposed me to identity theft, exactly nothing happened to them.
But I still don't understand "rather than" instead of "also."
You need to read more carefully: the "rather than" was qualified by "clueless hackers". I think some cyber criminals should still be tracked down and prosecuted: organized crime, people who deliberately injure or kill by hacking, etc. But people like Mitnick aren't worth it. We have limited resources for law enforcement and the legal system, and we need to allocate them carefully to protect the most vulnerable in our society, not companies too cheap or clueless to protect their computer systems.
I'm sure Mitnick's fate, just or unjust, has others very worried about crossing the line and getting caught.
And Mitnick's fate will give companies further excuse to avoid their responsibility to run their systems securely.
Instilling fear in a huge hacker population isn't going to be very effective because there are enough self-destructive people around to do this sort of thing anyway. On the other hand, instilling fear in corporate CIOs about liability is going to work much better: they have enough to lose (civil and possibly criminal liability), and they can, in fact, secure their systems with a small investment.
That's why going after negligent companies and not going after people like Mitnick is important if we are ever going to get any kind of information security.
Mitnick was largely tracked down by a private party, anyway.
Fine. Let the private party sue him in civil court, at the private party's expense. There is no need to burden the tax payer or legal system with this.
But no amount of a victim's stupidity exonerates the crook. If both are guilty, punish both.
I never said it "exonerated" the crook. But we make decisions on who we track down and prosecute every day. And the sad fact in America is that the police and legal system, right now, does not seem to try very hard to protect and enforce the rights of individuals.
Slashdot Mirror
Apple wants people to port their applications to Cocoa. That's the only kind of GUI they want on OSX. They have said so. I think it's stupid. I think it makes OSX pretty unattractive for UNIX workstation users. But it's Apple's wish, and it's Apple strategy. I don't see any point in fighting it, and I don't see any point for open source efforts to waste any time on doing something Apple doesn't want in the first place.
For me, it means that I'm going to continue to use my Mac mostly as a decorative jukebox, and my Linux machine to replace my UNIX workstation.
I think any reasonable database system and query language should be Turing complete. That means that, no matter what front-end you put onto it, you can express the same queries in it. And since they have to solve the same problems, any reasonable database system better perform well on those problems, too.
Yet I can tell you are committing a serious logical problem in equating SQL to relational.
I'm not equating SQL to relational. I am saying: SQL is just a query language.
Unproven? Let me see. This idea single-handledly changed its field overnight, obsoleted all other practices, forced everyone to redefine not only their ideas but their concepts and the very terms and methods they used to think about databases.
You're contradicting yourself. On the one hand, you claim it single-handedly changed the field, on the other hand, you claim nobody is actually implementing it. Which is it?
Hm? Is set theory and predicate logic enough evidence for you?
No. Good theoretical foundations are neither necessary nor sufficient for building good practical systems. Turing machines, for example, are wonderful and well-founded theoretical models of computation, yet we don't use them as the basis for designing programming languages.
Furthermore, there are many other ways for translating set theory and predicate calculus into database systems. Date and Darwen's approach seems woefully dusty and cumbersome; those guys are stuck somewhere in the 1960's, and they completely muddle up issues of syntax, data representation, algorithms, and abstractions.
Furthermore, 64bit really matters to a lot of people; it's not just a few more instructions. And the other main alternative, Itanium, is hugely expensive, a pain to deploy, doesn't run a lot of software, and doesn't perform all that well.
Sure, AMD may still fail to pull this off for a variety of reasons. But it really looks to me like they are very serious about making it work.
It looks like Athlon64 performance is going to be quite good. But even if it weren't, I hope AMD wouldn't hold up the release of the Athlon64 over concerns with benchmarks. If the price is reasonable, we'd buy them right now even if they ran at half the speed of a top-of-the-line Pentium4. The ability to address greater than 4 Gbytes of memory directly just outweighs even fairly significant differences in raw CPU performance. In different words, even a slow pointer dereference is still a lot faster than read/seek/write.
No, I'm not. Don't tell me what I'm thinking. I said that RDBMSs are a horrible idea for a general purpose file system, and that's what I meant. SQL is a query language, not a database system.
Besides, the kinds of database engines that are sitting underneath SQL are what Microsoft claims they want to put into the file system.
The only true RDBMSs now existing is Alphora Dataphor, and it is not yet a full, portable DBMS.
Well, yeah, right: you and Alphora's marketing department think that.
Besides, the evidence that any more "pure" relational query language than SQL is better is thin at best. If you are going to redesign databases from scratch, there are better choices than either SQL or some unproven 1960's idea.
In fact, arguably a large chunk of furniture and clothes design is about "dynamically adapting" to the tastes and moods of the user. It's just that the most cost effective means so far have been manually operated.
Lots of data-intensive applications desperately need more than 2Gbytes of RAM. If Opteron can deliver that for only a modest premium over regular Athlon-bsaed PCs, it will be a huge success. And if it can run existing binaries in 32bit mode and work with existing drivers, that's icing on the cake. There is just nothing else like it out there.
As soon as they come out, assuming Linux does run reasonably well on them and there are no unexpected show-stoppers, we are going to buy half a dozen of them. We want a Beowulf cluster of these.
There are several Linux projects to clone the appearance and behavior of the Windows desktop environment, to make people moving from Windows to Linux feel more comfortable. Nobody is trying to clone the Windows software architecture, however: all major Linux environments are properly layered on top of a POSIX kernel and the X11 window system.
so as not to remain completely irrelevant.
Linux is probably costing Microsoft half its server market, and, if anything, Microsoft is falling behind. Now, Linux is making inroads on the client as well.
Linux clients and servers require far less staff to install, support, maintain, update, and secure than Windows clients or server installations. That's in addition to not having to pay the steep Microsoft licensing fees, of course.
Microsoft management is scared, and they have reason to be.
I don't see Windows adding in bizarre installers, removing hardware support, or require convoluted commands for simple procedures like Linux, so I don't know what you're talking about.
Well, it's obvious that you don't know what I'm talking about.
Object storage is useful, but an object file system isn't merely object storage, it's object storage in the kernel. Does object storage need to be in the kernel? Does the kernel need to know how to invoke arbitrary user-defined methods on file system objects? I don't think so.
A modest amount of additional flexibility in the UNIX/Linux file system may be desirable. Plan9 lets you hook up a well-defined, fixed set of user-defined methods to file system objects. That may be a good idea, although it can still be done in user space (and perhaps is better done there). ReiserFS makes small files and large directories more efficient. Some additional kernel support permits change notification. Those are the kind of incremental changes to the proven concept of a "file system" that make sense to me. Taking an OODBMS or RDBMS and putting it into the kernel is asking for failure.
UNIX/Linux file systems are actually a database: a very specific kind of database. If the UNIX/Linux file system needs to evolve at all, it's in the ReiserFS and Plan9 directions. Those systems really do improve aspects of how file systems are used in the real world.
Command line editing and job control have been moved from shell built-ins into separate programs. That makes those capabilities much more easily reusable and extensible.
You can get something similar for Linux: "cle" is a generic command line editor, and "screen" is something like job control.
Desktop environments like XFCE and IceWM are rock solid, as is the X11 server itself.
Gnome, Mozilla, OpenOffice, and KDE, of course, are works in progress, but no worse in my experience than what Microsoft ships. I still see "Send Bug Report to Microsoft" dialog boxes regularly on Windows XP, while I hardly ever see a GUI application crash on Linux.
Beyond that, there are, of course, plenty of buggy GUI applications for all platforms.
I'm sorry, but you are barking up the wrong tree. My argument was not about whether copying is good or bad; I happen to think copying can be quite good, actually: open source software and biological evolution both involve a lot of copying. I simply pointed out that the Microsoft GUI wasn't created in some long-term master plan, as NineNine claimed, but instead was a long series of short-term reactions to market pressures.
First of all, since most people use the GUI most of the time, if you want to move on to scripting, you have to learn both entirely new commands and figure out how to script them together. Not even the concepts and paradigms of how to manipulate the system are easily mapped onto one another.
Also, the command line tools don't seem to keep up with what's in the GUI, and any third party components that require administration often don't come with command line tools at all.
Finally, Windows doesn't ship with a lot of the glue necessary to make scripting work. Apart from the pathetic cmd.exe, most devices are not accessible through the file system and many important command line programs are just missing. Some come and go (NT used to come with pax.exe, but it seems to have disappeared now, leaving no archiver around).
It has nothing to do with luck. Embrace-and-extend works if, like Microsoft, you have a monopoly. And Microsoft didn't even earn that monopoly themselves, they got it handed for free by IBM.
Leaving aside the question of what a "very solid GUI" might be or whether Microsoft can even remotely be argued to have one, you are ascribing too much long-range planning to Microsoft.
Microsoft responds to the market like a leaf in the wind. All their various approaches to GUIs were driven by a panicky reaction to competition. Their first GUI was a reaction to Macintosh. MFC was driven by the success of competitive object oriented GUI libraries. The 3D look was a reaction to Motif. GUI builders were a reaction to third party tools and NeXT. RDP was an attempt to clone X11's remote access features. And their latest, C#/CLR is basically a Java clone.
Now, Microsoft feels extremely threatened by Linux, both on the client and on the server, and they are desparately trying to clone the essence of Linux so that their servers won't become completely irrelevant.
Microsoft doesn't plan or strategize anything for the long term. Microsoft is driven by paranoia, "not invented here", and the usual geek attitude of "if we implement it, it will be better". Nothing could be further from the truth, of course.
Microsoft already has their own scripting environment, and you can already get the most popular shell environments (Bash, Korn) for Windows for free. It doesn't help, because the system just isn't built for scripting.
They've got stability, they've got security, and now they're gonna have good scripting. Wow. Who would'a thunk?
Very funny. XP can be fairly stable and secure--if you dedicate machines to individual tasks and disable most multiuser features. Running Apache and ssh helps, too. But, compared to UNIX and Linux, XP's stability and security are still ridiculously poor. And that's not because lacks features, it's because it has too many features.
Yeah: they collect every possible feature under the sun into a gigantic feature list. Then they hire away a number of experts from other companies that feel constrained not to be able to do what they wanted to do at their previous jobs and give them lots of money and programmers. And instead of having to compete for market share with their ideas, they just get to dump whatever they come up with into the Windows distribution. The result spells out "second system effect" in big letters.
Good design requires restraint and tradeoffs. It requires figuring out how to pick a small set of features that get most of the work done. It requires actually competing in the market place, where not only dysfunctional systems fail to find acceptance, but also systems that are too complex and big for mere humans to figure out. Microsoft completely lacks the taste, corporate culture, or ability to make those tradeoffs.
But you are right: this approach is indeed why they are number one. There are many morons out there who do indeed think that the longest feature list is what makes a system good.
Look, in contrast, at the "next generation UNIX shell", rc, from Bell Labs. "rc" intends to simplify, remove unnecessary functionality, and factor out features like job control and command line editing.
No, it doesn't; neutrons eventually stick to something.
If it produces neutrons, some of those neutrons will escape, get captured, and produce radioactive waste. It may or may not be as bad as fission, but it's still a problem.
I agree that these people probably were after the hardware and that it probably was an inside job. However, they may well re-sell the data now and find it more valuable than the hardware.
How the hardware was stolen shouldn't matter, however, for the security of the data: it is easy to ensure that data becomes inaccessible when hardware is physically removed. Not putting such mechanisms in place is where I think the company was negligent. (Similar comments apply to when criminals manage to steal credit card and customer databases from web sites--with a minimally security conscious design, that's trivial to prevent.)
Sadly, the same is true for many other companies. I think most companies probably don't even realize that they can protect the data in such cases; their "technologists" are lost somewhere in a haze of ASP/.NET/J2EE and can't be bothered with pesky details like disk encryption.
But if this became a high-profile prosecution of both the company and the CIO for mishandling of private data, resulting in stiff fines or worse, you can bet that other companies would (1) realize that they can do something to prevent this and (2) invest the modest amount of money necessary to deal with it.
We'll see to what degree prosecutors will take advantage of this. In cases where there are existing laws (anything involving fiduciary duties), I have yet to see a high profile case prosecuted.
AFAIK, there are no laws for banks not to be morons, so comparing the two isn't really useful.
The concern in this case is not primarily about the health care information, it's about possible identity theft resulting from the availability of the information. Disclosure of health care information may be embarrassing and lead to discrimination, but identity theft can lead to instant ruin.
From my own experience, I can tell you that when my bank exposed my financial records through lousy on-line security and exposed me to identity theft, exactly nothing happened to them.
You need to read more carefully: the "rather than" was qualified by "clueless hackers". I think some cyber criminals should still be tracked down and prosecuted: organized crime, people who deliberately injure or kill by hacking, etc. But people like Mitnick aren't worth it. We have limited resources for law enforcement and the legal system, and we need to allocate them carefully to protect the most vulnerable in our society, not companies too cheap or clueless to protect their computer systems.
I'm sure Mitnick's fate, just or unjust, has others very worried about crossing the line and getting caught.
And Mitnick's fate will give companies further excuse to avoid their responsibility to run their systems securely.
Instilling fear in a huge hacker population isn't going to be very effective because there are enough self-destructive people around to do this sort of thing anyway. On the other hand, instilling fear in corporate CIOs about liability is going to work much better: they have enough to lose (civil and possibly criminal liability), and they can, in fact, secure their systems with a small investment.
That's why going after negligent companies and not going after people like Mitnick is important if we are ever going to get any kind of information security.
Mitnick was largely tracked down by a private party, anyway.
Fine. Let the private party sue him in civil court, at the private party's expense. There is no need to burden the tax payer or legal system with this.
But no amount of a victim's stupidity exonerates the crook. If both are guilty, punish both.
I never said it "exonerated" the crook. But we make decisions on who we track down and prosecute every day. And the sad fact in America is that the police and legal system, right now, does not seem to try very hard to protect and enforce the rights of individuals.