"We start seeing these new accounts being created,
but that could be an anomaly of the system," Miller
said. "After a day or two, we realized it was
someone hacking into the system."
Sounds like it's OK if accounts create themselves, as long as it isn't too frequent. Just when you get a lot of them is it indicative of a breakin?
If any attempts to download or transfer the source code were made, such activity
was not recorded in Microsoft's logs, Miller said, adding that it is unlikely any
source code files were copied because of their immense size.
Good grief! What were they writing? Software bloat as a protection against theft? So, if it's so big, how do they know it wasn't hacked?
Microsoft's source codes are the most coveted in the multibillion-dollar industry.
I still can't figure out who would want Microsoft source code. Basing a new product on code you have transferred from another group is hard enough with their cooperation, basing it on a snapshop stolen from a breaking would seem to be pointless: you are better off starting from scratch.
With access to these software blueprints, competitors could write programs that
undermine Microsoft--or use the data to identify vulnerabilities, making computer
break-ins and virus writing easier.
Ah, the media fully buying into the "security by obscurity" approach. The underlying assumption is that any software must be so full of security holes that we couldn't possibly let people look at the sources. How clueless.
I don't think one could have written a better satire if one tried. It is sad, however, that technical reporters write this kind of drivel as serious reporting (probably directly copied from some PR releases) and people in power believe it.
The police has a finite amount of resources for tracking criminals and they can't track down every criminal, and there are many crimes where they don't do much more than take a report (as you would find out if your car did get stolen).
Computer crime investigations can be expensive.
Let's say we are spending $XXX on trying to find whoever broke into Microsoft's system. Who are they likely going to find? A couple of high school students with no special skills: they apparently used a well-known exploit.
That money could have gone to catching some violent criminal, or helping people with drug rehabilitation, or any of a number of purposes that would improve the lives of thousands of people.
On the list of social priorities, the crime that has been committed against Microsoft is very low: it has virtually no consequences to anyone (other than Microsoft's PR and marketing), and the people who perpetrated it are unlikely to be a threat to anyone.
Sure you can do something about [begin held at gunpoint]; you can carry a weapon yourself.
You can't realistically defend yourself with a gun against someone who is reasonably skilled with a gun; if you try, you assume a huge risk. Defending yourself against an E-mail virus, however, exposes you to no risk at all and has almost no cost.
And that's the reason why I would like to see our police going out on the streets tracking down gun toting criminals. OTOH, tracking down some "script kiddies" won't make my life or anybody else's life any safer. It won't even restore anything to Microsoft. All it does is waste a lot of money that could have been spent better.
A crime has been committed, and Microsoft has both ethical and
legal claims. If they can prove that stolen code was used in someone else's project, they
will win in court.
Whether Microsoft can claim IP once in court is an entirely separate issue from whether the police or legal system should make any significant effort in tracking down the people who broke in.
However, while it is popular in some circles to try to invent new forms of IP protection, reality is that it's not clear they actually have much IP protection. There are really only four major forms of IP: copyrights, patents, trade secrets, and trademarks. Only trade secrets would seem to apply here (possibly copyrights, but they don't contaminate). And the legal reality is that trade secrets need to be protected carefully in order to receive any legal protection.
That architecture doesn't necessarily make it harder to program, it can actually make it easier. Roughly, you have to worry much less about how to arrange your data in memory or how to make incremental changes to it, you just get a fresh copy when you need it. In fact, there are excellent patterns and languages for programming systems composed of multiple units and fast interconnects.
It does make it harder for people steeped in the C/C++/Windows tradition to deal with, who generally aren't used at all to dealing with those kinds of systems. But maybe it's time to move beyond old approaches and learn something new.
I use CF, SM, and MS a lot with digital cameras. I don't like CF as much because it has lots of pins and because it is fairly big and rigid.
I find SmartMedia ideal: it's small, light, slightly flexible, and you can wipe the connectors clean if they get dirty. It's also manufactured by many companies and there are many readers for it, including a number of USB readers.
The MemoryStick is an OK design as well. Unfortunately, it's much less widely supported. One consequence is that you may have a harder time finding a reader that works for you.
Well, CNN, Fox, and other certainly picked it up. But Microsoft went to the FBI, and Microsoft keeps claiming that there is nothing wrong with the way their clients handle attachments and scripting. They could have kept quiet, or, even better, they could have said "oops, we made a mistake; we are going to fix our software, and here is what you should do to avoid the same problem".
This whole incident looks almost like a publicity and PR stunt. Microsoft seems to have succeeded at two things.
First, they have created the impression that Windows source code actually has significant commercial value. That's, of course, nonsense. The only reason Windows source code is valuable is because of Microsoft's market position and commitment to enhancing it, not because there is anything intrinsically clever about it.
Second, Microsoft seem to have gotten people to believe that being infected by an E-mail virus is kind of like being the victim of a robbery at gunpoint--something they can't do anything about. That's, of course, non-sense, too. It would have been very easy for them to protect themselves from this kind of threat. Susceptibility to this kind of threat is a defect in Microsoft products (other products and systems have defects, too, but the issue is who Microsoft blames for their defects, not the existence of defects in other products).
Microsoft has to take reasonable care in protecting valuable trade secrets. It is clear that they haven't. Even if they believe that their E-mail client has sufficient security, if they believe their source code is as valuable as it is, it should reside on a more protected part of the network. Microsoft is merely trying to avoid responsibility for their product defects and for their poor security policies.
It is an outrage that the taxpayer now even has to foot the bill for trying to track down people who took advantage of security defects in Microsoft products. That would be like GM selling cars with no locks and then claiming it's the taxpayer's responsibility to find all the stolen cars.
It is still good advice for open source projects to stay away from any Microsoft source, legally or illegally obtained. But don't get suckered into believing that Microsoft has any ethical claims: they were negligent. And, objectively, they ought not to have any hope of legal success either--they should fix their products instead and stop shifting the cost of their defective products onto law enforcement and, ultimately, the tax payer. As long as they can get away with shifting cost and responsibility onto others, they will have no economic incetives to fix their software or procedures.
It's not that there is some evil conspiracy to smear Microsoft. Microsoft does themselves in. After all, they claim near perfect security yet don't meet their own standards. They run off to the FBI to waste tax dollars on tracking down some teenager in Russia, and they are the ones that state that someone looking at Windows source code is the end of the world (as if anybody really cared).
The attitude more commonly found among UNIX sysadmins seems healthier. Yes, we know it's buggy. Yes, we aren't perfect. And if it's broken, it's our fault, and we'll try to fix it. And let's try to keep important stuff somewhere nice and isolated.
Microsoft explicitly stated that E-mail attachments are not dangerous because, after all, you don't have to open them. In fact, of course, it's common practice to delete all E-mail from people you don't know sight unseen. So, you must be wrong: Microsoft said so when the Melissa virus came around.
I think that danger doesn't exist. Microsoft was negligent in protecting their source code, and that like means that it isn't protected as a trade secret or confidential information anymore.
Let's just hope that the Microsoft source code doesn't infect open source projects with its lack of style or lack of attention to design.
Lots of sites get compromised. Most people just don't put important information on visible computers and they don't blame hackers when it happens--they fix it.
Microsoft, on the other hand, inflates the importance of what happened. I mean, after all, who gives a damn about their source code? And then they are crying out of the FBI to help them track down the evil criminals, costing tax payers lots of money, rather than admitting that they did something stupid, fix their processes, and move on.
On the other hand, by treating ourselves like morons, we're allowing ourselves to be morons; nay, expecting ourselves to be morons.
I'm willing to become an expert on some things that interest me. But consumer companies (including Microsoft) specifically advertise that I do not have to become an expert. They also promise that their products will save time and be more convenient compared to the traditional way of doing things. If they don't deliver, I think the product is defective, not me.
...like when an auto company was recently sued successfully...
Usually, when you follow up on these stories, you'll find that there is quite a bit of justification for the judgement.
(In this case, I suspect this refers to a design flaw many US cars have that makes it unnecessarily easy to accidentally lock yourself out.)
If you do not know how to use one of these items and cannot just figure it out, what do you
do? Ask someone a question, right?
No, actually I don't. If I was promised a no hassles, easy-to-use box and got something that requires studying the manual and fiddling with drivers, I return the thing and buy something from a different company.
In the final analysis, the end user (of any merchandise) is solely responsible for implementation and proper operation.
Sure, I fully accept my responsibility. And here is the box back.
Sometimes it isn't all about the pricetag and intuitive usablility.
Sometimes it isn't. But for many of the @Home customers it apparently is. And whether it is or isn't is for me to decide, not anybody else.
@Home isn't like your business.
Communities have given @Home permission
(probably even exclusive in some cases) to
dig up roads and public land. In return,
@Home has special responsibilities to serve
customers. Otherwise, maybe communities should
simply revoke permission for them to use public
lands.
As for confidentiality, while there are some additional protections for companies (questionable, in my opinion), it's fundamentally still the responsibility of @Home to protect the confidentiality of their own documents. If we ever got to the point where merely stamping something "confidential" would allow a company to force anybody to stop distributing that information, we'd be in trouble.
This has nothing to do with "responsibility", it's simple economics: companies that don't make easy to use consumer devices will feel the wrath of consumers. In particular, companies that answer their tech support lines by saying "RTFM" are missing the point: it's a fact that consumers just don't, it's a fact that consumers (myself included) don't feel it's rational to pore over manuals for what often amounts to a little gimmick, and it's a fact that many consumers will go elsewhere if they have a choice.
As for your computer and nuclear waste analogy, clearly, there are devices and processes for which it is either necessary or interesting to learn a lot about them. But that's driven either by professional needs ("nuclear waste") or interest (Linux). If every alarm clock, automobile, lightbulb, refridgerator, washer, drying, etc., demanded that kind of attention, we'd never have time for anything else.
Or, to put it more succinctly, if a consumer device requires more expense in terms of time to set up than the benefit in terms of fun or time savings derived from it, it's not rational to keep it. And since the fun or time savings derived from many consumer devices is pretty small, having to read a manual often crosses that threshold.
Of course, the vast majority of calls to tech support are from people who haven't read the manual.
When you sell stuff to consumers, it should work when it's plugged in and it should be obvious how to use it. It shouldn't require reading lots of manuals. That's not just because it's a nuisance, but if the thing is so complicated to use that it requires reading a manual, it just won't be very useful. The manual will get lost, other family members won't bother, the person who originally waded through the manual will forget, and within six months, it will get tossed or it will be obsolete, repeating the cycle all over again. Consumer devices are supposed to make life easier and provide fun; and these days, that means a minimal investmnet of itme. I've returned consumer devices that required reading the manual: it's a sign of poor design and poor value.
In fact, the same ought to be true for stuff sold to professionals, but professionals have less choice in the matter because for them, stuff they get sold is needed to get a job done.
If @Home pushes platforms (Windows, MacOS) that require tricky installations and can be misconfigured in a myriad of ways, they have to pay for that in terms of support costs. If they don't, they won't get a lot of customers, of course. In the short term, that's the way business works for everybody. In the long term, maybe that will provide sufficient incentive for @Home to support consumer friendly hardware and software (and, no, I don't mean Linux either).
Pardon me, but why do they "deserve my dollars"? Their software is quite expensive (about the same price as a low-end PC), and they got started with the Bochs software Kevin wrote and let them have for free.
Buy VMware if you like. I bought a few copies. But I certainly feel under no moral obligation to give them my money, and neither, I think should anybody else. If you want to do a good deed, support Mandrake and the Plex86 project financially.
In any case, the only reason why this is so hard to begin with is because of limitations of the x86 and PC architecture. If the PIII were built to be virtualizable and the PC didn't have such a ridiculously messy set of hardware interfaces, none of this would be a big deal.
The prices I have heard for the X-box were around $400-500. And that's roughly what this kind of box should cost; after all, that's roughly what a low-end, somewhat subsidized PC costs, and that's what this thing is.
As for speed, the PC and Pentium architecture is burdened with a lot of stuff that's completely irrelevant to game or console development. The PC and Pentium architecture are adapted to a market that consists of zillions of custom systems, made from cheap if suboptimal components.
With the PS2 Sony has its own volume market. They can dedicate the same chip area that the Pentium dedicates to compromises and backwards compatibility to performance. If Sony hasn't screwed up (and I doubt it--their engineers are good), the PS2 should perform better at a lower cost than a 700MHz PIII (which itself is hardly state of the art anymore) and some nVidia chip.
As for software, I find the Microsoft tools and platform plenty "goofy" and "quirky", so being based on Windows to me is more of a disadvantage. I haven't seen the PS2 APIs, but the situation is probably similar to WinCE vs. PalmOS: WinCE is burdened by its heritage, while PalmOS is well adapted to just the tasks it is supposed to do (even if PalmOS is, by now, showing its age).
Finally, what does Sony benefit from opening up the platform? Nothing if you think that the PS2 is only about commercial console games: then it really just comes down to who markets better to teenagers and who makes better deals with game developers. But if that's all the PS2 is about, it will be irrelevant soon, given the stiff competition. That's the mistake I hope Sony won't fall into.
If, on the other hand, the PS2 becomes an actual home computing platform, an alternative to the PC, then Sony stands to gain a lot if lots of people develop software for it.
The PS2 is a great deal, and it deserves to catch on--if development for it is opened up. If it remains proprietary too long, I think the platform will falter. The reason is that many of the best and most innovative games come from people that don't have huge amounts of money to invest up front.
But Microsoft has its own problems. The X-Box looks like it's going to be both expensive (because of its reliance on PC technology) and significantly behind the curve in terms of performance. And from what it looks like so far, the X-Box software architecture isn't exactly going to be pretty either; close ties to Windows APIs are both a blessing and a curse.
I think whichever box ends up more open and more hackable will win in the market, if for slightly different reasons. I hope Sony figures this out before it's too late. Microsoft, with their choice of fairly standard PC technologies, may end up not being able to do anything about winning in the market that way, but their victory may be Pyrrhic, as they see their nice X-boxes turned into even nicer, Microsoft-subsidized Linux machines.
The US Census used to be specifically exempt from providing any personal data to other government agencies. That's something the US Census Bureau has been taking very seriously until now. You were not supposed to get into trouble for incriminating yourself on census forms.
The reason for these kinds of protections is that the government needs accurate statistical data on what is going on in the country to make policy decisions. Laying open US Census information would only result in non-response. The net result would only be that the government would have much less accurate statistical data.
If the CBO, or some other government office, wants to correlate data, they can submit IRS, INS, and other data to the Census Bureau, the Census Bureau can do the correlation, and provide aggregate statistical results back to other government agencies. If the US Census Bureau continues to take privacy as seriously as they have in the past, this should not raise significant privacy concerns.
If Dan Miller doesn't understand the need for safeguarding the ability of the US government to collect accurate statistical data, and the profoundly negative effect tampering with the current privacy guarantees of the US Census would have on that ability, he should probably not be on the congressional census committee.
Konqueror is a good OSS browser and was developed rapidly. Even M18 is not too bad, but it needs a bit more bug fixing (but, then, it's much more than a browser). The OSS movement doesn't have to be ashamed.
Chances are that if it doesn't work with Netscape on Linux, there are lots of other problems with it. What about Opera users? What about user who use browsers with accessibility features? Thin clients? Old browser versions on Windows? People who have turned off JavaScript for security reasons?
Online banking and other sites should work with JavaScript, CSS, and images turned off, and only with basic HTML. If not, the bank is doing something seriously wrong IMO, and they'll sooner or later lose a lot more than 1% of their customers.
What about Windows? Right now, developing for Windows, I have to deal with Windows 95/98, ME, NT4, 2000, CE, and possibly still 3.1, all of which have come out over roughly the span of a decade. "Windows" has four almost completely different kernels (and I'm not even counting DOS). The Windows APIs have been mutating between Win16, various incompatible flavors of Win32, MFC, COM, COM+, ActiveX, and god knows what else. Microsoft cannot make up their mind whether they are going to support C++, Java, C#, VB, or something else.
Linux follows in a long tradition of UNIX systems, and while they have never offered much in the way of binary compatibility, UNIX/Linux has always provided much more source-level compatibility among its implementations than any other multi-vendor OS. It has also, amazingly, offered much more source-level compatibility than Microsoft ever managed to offer among their own line of operating systems.
Stable APIs and predictable evolution are one of the main reasons I choose Linux over Windows. Well-written code from 20 years ago still works just fine on Linux and takes full advantage of fast processors and large memories. If Microsoft wants to compete on this basis, they have to first reach that level of standardization of their own platforms. Until then, the best choice Windows programmers have is to insulate themselves from the haphazard nature of the Windows APIs and Microsoft corporate strategy by going with something like Java, wxWindows, or Delphi.
Or, to put it differently, a penguin with rabbit ears is still a penguin. Microsoft has been producing a whole zoo instead.
Well, I use C++ professionally, too. In my opinion, STL is the worst thing that happened during C++ standardization.
If you look at what most C++ frameworks and applications actually use, it's very little: some kind of array/list, maybe a multidimensional array, and a hash table. That is what C++ should have provided in its standard library.
If people had wanted something of the complexity and generality of STL, they could always have gotten it as an add-on (or, better yet, used a language in which STL-like frameworks are much simpler, like SML or GJ).
STL is out of any proportion to the needs of most C++ programmers. Its adoption has delayed the acceptance of standard collection classes for C++ by many years, because compilers needed to catch up with it and because people needed to learn it. That has done untold damage to the language in the market.
And despite its complexity, STL still fails to satisfy the basic needs of many applications, meaning that most application frameworks still include a number of incompatible collection classes.
By any measure, I think STL failed: it didn't help the adoption of C++, it didn't standardize existing practice, and it doesn't satisfy the basic needs of working C++ programmers.
The reason why there isn't a single bytecode is because supporting C/C++ semantics and the semantics of most other languages simultaneously is such a pain. It's mostly that C/C++ programs don't have enough type information in the source.
For example, in C/C++, a string can be a "char *", but that might also be a pointer to a local variable of type "char", or a single heap-allocated byte, or a pointer into the middle of a heap-allocated struct, etc. Other languages have the same concepts, but they use separate types. C/C++'s design choice is simple, but it inherently makes many kinds of runtime checks very expensive, and it makes it nearly impossible to automate the type conversions that occur in multi-language environments. Either the programmers has to write an IDL specification that really expresses what the code intends, or the runtime has to keep track of a lot of extra information.
Until C/C++ changes and deprecates its "pointer" construct in favor of a variety of other constructs (similar to what happened with casts in C++), an efficient universal runtime for both C/C++ and other languages is always going to be a big project.
If C/C++ isn't one of the target languages, a universal runtime is pretty straightforward. You could easily do a nice, universal runtime for Java, Modula-3, Prolog, Lisp, and many other languages.
Maybe "normal" universes have life flourishing throughout. Maybe it's only our own where stuff has collapsed into stars and planets, with a few carbon-based entities clinging precariously to some tiny planets.
Slashdot Mirror
Sounds like it's OK if accounts create themselves, as long as it isn't too frequent. Just when you get a lot of them is it indicative of a breakin?
Good grief! What were they writing? Software bloat as a protection against theft? So, if it's so big, how do they know it wasn't hacked?
I still can't figure out who would want Microsoft source code. Basing a new product on code you have transferred from another group is hard enough with their cooperation, basing it on a snapshop stolen from a breaking would seem to be pointless: you are better off starting from scratch.
Ah, the media fully buying into the "security by obscurity" approach. The underlying assumption is that any software must be so full of security holes that we couldn't possibly let people look at the sources. How clueless.
I don't think one could have written a better satire if one tried. It is sad, however, that technical reporters write this kind of drivel as serious reporting (probably directly copied from some PR releases) and people in power believe it.
Computer crime investigations can be expensive. Let's say we are spending $XXX on trying to find whoever broke into Microsoft's system. Who are they likely going to find? A couple of high school students with no special skills: they apparently used a well-known exploit.
That money could have gone to catching some violent criminal, or helping people with drug rehabilitation, or any of a number of purposes that would improve the lives of thousands of people.
On the list of social priorities, the crime that has been committed against Microsoft is very low: it has virtually no consequences to anyone (other than Microsoft's PR and marketing), and the people who perpetrated it are unlikely to be a threat to anyone.
You can't realistically defend yourself with a gun against someone who is reasonably skilled with a gun; if you try, you assume a huge risk. Defending yourself against an E-mail virus, however, exposes you to no risk at all and has almost no cost.
And that's the reason why I would like to see our police going out on the streets tracking down gun toting criminals. OTOH, tracking down some "script kiddies" won't make my life or anybody else's life any safer. It won't even restore anything to Microsoft. All it does is waste a lot of money that could have been spent better.
Whether Microsoft can claim IP once in court is an entirely separate issue from whether the police or legal system should make any significant effort in tracking down the people who broke in.
However, while it is popular in some circles to try to invent new forms of IP protection, reality is that it's not clear they actually have much IP protection. There are really only four major forms of IP: copyrights, patents, trade secrets, and trademarks. Only trade secrets would seem to apply here (possibly copyrights, but they don't contaminate). And the legal reality is that trade secrets need to be protected carefully in order to receive any legal protection.
It does make it harder for people steeped in the C/C++/Windows tradition to deal with, who generally aren't used at all to dealing with those kinds of systems. But maybe it's time to move beyond old approaches and learn something new.
I find SmartMedia ideal: it's small, light, slightly flexible, and you can wipe the connectors clean if they get dirty. It's also manufactured by many companies and there are many readers for it, including a number of USB readers.
The MemoryStick is an OK design as well. Unfortunately, it's much less widely supported. One consequence is that you may have a harder time finding a reader that works for you.
Well, CNN, Fox, and other certainly picked it up. But Microsoft went to the FBI, and Microsoft keeps claiming that there is nothing wrong with the way their clients handle attachments and scripting. They could have kept quiet, or, even better, they could have said "oops, we made a mistake; we are going to fix our software, and here is what you should do to avoid the same problem".
Microsoft has to take reasonable care in protecting valuable trade secrets. It is clear that they haven't. Even if they believe that their E-mail client has sufficient security, if they believe their source code is as valuable as it is, it should reside on a more protected part of the network. Microsoft is merely trying to avoid responsibility for their product defects and for their poor security policies.
It is an outrage that the taxpayer now even has to foot the bill for trying to track down people who took advantage of security defects in Microsoft products. That would be like GM selling cars with no locks and then claiming it's the taxpayer's responsibility to find all the stolen cars.
It is still good advice for open source projects to stay away from any Microsoft source, legally or illegally obtained. But don't get suckered into believing that Microsoft has any ethical claims: they were negligent. And, objectively, they ought not to have any hope of legal success either--they should fix their products instead and stop shifting the cost of their defective products onto law enforcement and, ultimately, the tax payer. As long as they can get away with shifting cost and responsibility onto others, they will have no economic incetives to fix their software or procedures.
The attitude more commonly found among UNIX sysadmins seems healthier. Yes, we know it's buggy. Yes, we aren't perfect. And if it's broken, it's our fault, and we'll try to fix it. And let's try to keep important stuff somewhere nice and isolated.
Microsoft explicitly stated that E-mail attachments are not dangerous because, after all, you don't have to open them. In fact, of course, it's common practice to delete all E-mail from people you don't know sight unseen. So, you must be wrong: Microsoft said so when the Melissa virus came around.
Let's just hope that the Microsoft source code doesn't infect open source projects with its lack of style or lack of attention to design.
Microsoft, on the other hand, inflates the importance of what happened. I mean, after all, who gives a damn about their source code? And then they are crying out of the FBI to help them track down the evil criminals, costing tax payers lots of money, rather than admitting that they did something stupid, fix their processes, and move on.
I'm willing to become an expert on some things that interest me. But consumer companies (including Microsoft) specifically advertise that I do not have to become an expert. They also promise that their products will save time and be more convenient compared to the traditional way of doing things. If they don't deliver, I think the product is defective, not me.
Usually, when you follow up on these stories, you'll find that there is quite a bit of justification for the judgement.
(In this case, I suspect this refers to a design flaw many US cars have that makes it unnecessarily easy to accidentally lock yourself out.)
No, actually I don't. If I was promised a no hassles, easy-to-use box and got something that requires studying the manual and fiddling with drivers, I return the thing and buy something from a different company.
In the final analysis, the end user (of any merchandise) is solely responsible for implementation and proper operation.
Sure, I fully accept my responsibility. And here is the box back.
Sometimes it isn't all about the pricetag and intuitive usablility.
Sometimes it isn't. But for many of the @Home customers it apparently is. And whether it is or isn't is for me to decide, not anybody else.
As for confidentiality, while there are some additional protections for companies (questionable, in my opinion), it's fundamentally still the responsibility of @Home to protect the confidentiality of their own documents. If we ever got to the point where merely stamping something "confidential" would allow a company to force anybody to stop distributing that information, we'd be in trouble.
As for your computer and nuclear waste analogy, clearly, there are devices and processes for which it is either necessary or interesting to learn a lot about them. But that's driven either by professional needs ("nuclear waste") or interest (Linux). If every alarm clock, automobile, lightbulb, refridgerator, washer, drying, etc., demanded that kind of attention, we'd never have time for anything else.
Or, to put it more succinctly, if a consumer device requires more expense in terms of time to set up than the benefit in terms of fun or time savings derived from it, it's not rational to keep it. And since the fun or time savings derived from many consumer devices is pretty small, having to read a manual often crosses that threshold.
When you sell stuff to consumers, it should work when it's plugged in and it should be obvious how to use it. It shouldn't require reading lots of manuals. That's not just because it's a nuisance, but if the thing is so complicated to use that it requires reading a manual, it just won't be very useful. The manual will get lost, other family members won't bother, the person who originally waded through the manual will forget, and within six months, it will get tossed or it will be obsolete, repeating the cycle all over again. Consumer devices are supposed to make life easier and provide fun; and these days, that means a minimal investmnet of itme. I've returned consumer devices that required reading the manual: it's a sign of poor design and poor value.
In fact, the same ought to be true for stuff sold to professionals, but professionals have less choice in the matter because for them, stuff they get sold is needed to get a job done.
If @Home pushes platforms (Windows, MacOS) that require tricky installations and can be misconfigured in a myriad of ways, they have to pay for that in terms of support costs. If they don't, they won't get a lot of customers, of course. In the short term, that's the way business works for everybody. In the long term, maybe that will provide sufficient incentive for @Home to support consumer friendly hardware and software (and, no, I don't mean Linux either).
Buy VMware if you like. I bought a few copies. But I certainly feel under no moral obligation to give them my money, and neither, I think should anybody else. If you want to do a good deed, support Mandrake and the Plex86 project financially.
In any case, the only reason why this is so hard to begin with is because of limitations of the x86 and PC architecture. If the PIII were built to be virtualizable and the PC didn't have such a ridiculously messy set of hardware interfaces, none of this would be a big deal.
As for speed, the PC and Pentium architecture is burdened with a lot of stuff that's completely irrelevant to game or console development. The PC and Pentium architecture are adapted to a market that consists of zillions of custom systems, made from cheap if suboptimal components.
With the PS2 Sony has its own volume market. They can dedicate the same chip area that the Pentium dedicates to compromises and backwards compatibility to performance. If Sony hasn't screwed up (and I doubt it--their engineers are good), the PS2 should perform better at a lower cost than a 700MHz PIII (which itself is hardly state of the art anymore) and some nVidia chip.
As for software, I find the Microsoft tools and platform plenty "goofy" and "quirky", so being based on Windows to me is more of a disadvantage. I haven't seen the PS2 APIs, but the situation is probably similar to WinCE vs. PalmOS: WinCE is burdened by its heritage, while PalmOS is well adapted to just the tasks it is supposed to do (even if PalmOS is, by now, showing its age).
Finally, what does Sony benefit from opening up the platform? Nothing if you think that the PS2 is only about commercial console games: then it really just comes down to who markets better to teenagers and who makes better deals with game developers. But if that's all the PS2 is about, it will be irrelevant soon, given the stiff competition. That's the mistake I hope Sony won't fall into.
If, on the other hand, the PS2 becomes an actual home computing platform, an alternative to the PC, then Sony stands to gain a lot if lots of people develop software for it.
But Microsoft has its own problems. The X-Box looks like it's going to be both expensive (because of its reliance on PC technology) and significantly behind the curve in terms of performance. And from what it looks like so far, the X-Box software architecture isn't exactly going to be pretty either; close ties to Windows APIs are both a blessing and a curse.
I think whichever box ends up more open and more hackable will win in the market, if for slightly different reasons. I hope Sony figures this out before it's too late. Microsoft, with their choice of fairly standard PC technologies, may end up not being able to do anything about winning in the market that way, but their victory may be Pyrrhic, as they see their nice X-boxes turned into even nicer, Microsoft-subsidized Linux machines.
The reason for these kinds of protections is that the government needs accurate statistical data on what is going on in the country to make policy decisions. Laying open US Census information would only result in non-response. The net result would only be that the government would have much less accurate statistical data.
If the CBO, or some other government office, wants to correlate data, they can submit IRS, INS, and other data to the Census Bureau, the Census Bureau can do the correlation, and provide aggregate statistical results back to other government agencies. If the US Census Bureau continues to take privacy as seriously as they have in the past, this should not raise significant privacy concerns.
If Dan Miller doesn't understand the need for safeguarding the ability of the US government to collect accurate statistical data, and the profoundly negative effect tampering with the current privacy guarantees of the US Census would have on that ability, he should probably not be on the congressional census committee.
Konqueror is a good OSS browser and was developed rapidly. Even M18 is not too bad, but it needs a bit more bug fixing (but, then, it's much more than a browser). The OSS movement doesn't have to be ashamed.
Online banking and other sites should work with JavaScript, CSS, and images turned off, and only with basic HTML. If not, the bank is doing something seriously wrong IMO, and they'll sooner or later lose a lot more than 1% of their customers.
Linux follows in a long tradition of UNIX systems, and while they have never offered much in the way of binary compatibility, UNIX/Linux has always provided much more source-level compatibility among its implementations than any other multi-vendor OS. It has also, amazingly, offered much more source-level compatibility than Microsoft ever managed to offer among their own line of operating systems.
Stable APIs and predictable evolution are one of the main reasons I choose Linux over Windows. Well-written code from 20 years ago still works just fine on Linux and takes full advantage of fast processors and large memories. If Microsoft wants to compete on this basis, they have to first reach that level of standardization of their own platforms. Until then, the best choice Windows programmers have is to insulate themselves from the haphazard nature of the Windows APIs and Microsoft corporate strategy by going with something like Java, wxWindows, or Delphi.
Or, to put it differently, a penguin with rabbit ears is still a penguin. Microsoft has been producing a whole zoo instead.
If you look at what most C++ frameworks and applications actually use, it's very little: some kind of array/list, maybe a multidimensional array, and a hash table. That is what C++ should have provided in its standard library.
If people had wanted something of the complexity and generality of STL, they could always have gotten it as an add-on (or, better yet, used a language in which STL-like frameworks are much simpler, like SML or GJ).
STL is out of any proportion to the needs of most C++ programmers. Its adoption has delayed the acceptance of standard collection classes for C++ by many years, because compilers needed to catch up with it and because people needed to learn it. That has done untold damage to the language in the market.
And despite its complexity, STL still fails to satisfy the basic needs of many applications, meaning that most application frameworks still include a number of incompatible collection classes.
By any measure, I think STL failed: it didn't help the adoption of C++, it didn't standardize existing practice, and it doesn't satisfy the basic needs of working C++ programmers.
For example, in C/C++, a string can be a "char *", but that might also be a pointer to a local variable of type "char", or a single heap-allocated byte, or a pointer into the middle of a heap-allocated struct, etc. Other languages have the same concepts, but they use separate types. C/C++'s design choice is simple, but it inherently makes many kinds of runtime checks very expensive, and it makes it nearly impossible to automate the type conversions that occur in multi-language environments. Either the programmers has to write an IDL specification that really expresses what the code intends, or the runtime has to keep track of a lot of extra information.
Until C/C++ changes and deprecates its "pointer" construct in favor of a variety of other constructs (similar to what happened with casts in C++), an efficient universal runtime for both C/C++ and other languages is always going to be a big project.
If C/C++ isn't one of the target languages, a universal runtime is pretty straightforward. You could easily do a nice, universal runtime for Java, Modula-3, Prolog, Lisp, and many other languages.
Maybe "normal" universes have life flourishing throughout. Maybe it's only our own where stuff has collapsed into stars and planets, with a few carbon-based entities clinging precariously to some tiny planets.