OS/2 version 1.3 was, IMHO, the best small multithreaded OS ever created. Period. Gorden Letwin and his team did an amazing job with it. Those who are interested might want to scrounge up a copy of "Inside OS/2" by Letwin and give it a read.
IBM's versions, from 2.0 onwards, extended that with better GUI support, real multi-platform interoperability and backwards compatibility. I was an OS/2 developer from 1.0 through 2.1, and a participant in IBM's OS/2 developer's program (I even purchased several big PS/2 machines, very nice for their day, and gave presentations to groups of bored scientists about it). I was also heartbroken when Gerstner pulled the plug on OS/2 and effectively doomed it to obscurity. But, I've since moved on to Linux and FreeBSD, and I haven't looked back.
If OS/2 was going to be open-sourced, I think the parts of real interest would be the pre-2.0 code and some of the 2.x kernel extensions. But, so far as I know, 1.x is mostly MS code, and will never see the light of day. I don't know if there's enough of the 2.x that isn't legally encumbered to be of interest to anyone.
It's a pity, though, because it could have been what Windows wanted to be, and Linux could be. But, that could be said for NextOS and BeOS as well. Just because something is a good idea doesn't mean it will enjoy success in the real world.
A good design document starts with good requirements. It also requires that your process have some way to capture and fold changes back into the documentation as necessary.
A good place to look is "Software Requirements--Revision" by Alan Davis (1993). I don't agree with everything Davis has to say, but the book is full of good ideas and potential "gotchas" to watch out for. Another good reference is DO-178B, the guidelines used for the development and testing of safety-critical software in commercial aerospace applications. It is available from the RTCA for about $50.
If you're doing an OO project, then you might want to look at Booch's book: "Object Oriented Analysis and Design" and the UML 2.0 specification.
But, most importantly, you MUST have some kind of design documentation (requirements, at a minimum) and that documentation needs to be flexible enough to accomodate changes without causing everything else to grind to a halt while the revisions happen. Expecting to get good software with inadequate formal documentation, minimal planning and insufficient requirements is why 70% of all commercial software projects end in failure (documented and published statistic).
Anyone who says you can do good software by shooting from the hip is nuts. And they don't work for me.
I love it when people post things that clearly indicate that they have never been to the place in question and experienced it for themselves, but feel compelled to express a cliched opinion.
I've been there, and not just to the big tourist-friendly places like Beijing, but to the interior as well. Everywhere you look you see forward progress, even in the rural areas. Many of the things the article mentions aren't just for the party elite, they're widespread. Sure, it's a centralized Communist government, but in reality it has a lot in common with the type of government China has known for the past 2000 years--central authority, distribution of authority to outlying cities and provinces, and a system of reporting back to HQ how things are going in the rest of the country. Add to that the Chinese cultural emphasis on unity and harmony, and you have a system that works relatively well (at least nowadays) for them. The Chinese government wants to modernize, and they know that they must modernize to be a player on the world stage, but they want to do so in a way that will not result in discord in their culture.
But, politics aside, to make the claim that "the vast majority" of the country doesn't have access to this "technology" is ludicrous. Almost all of the examples mentioned were public technologies. Everyone can benefit from smart traffic lights, and it's true that cellphones are almost everywhere (I once saw a fellow sitting on his ancient motorized tricycle thing with a huge stack of what looked like sticks, talking on his cellphone way out in the countryside). China is awash in cybercafes, television is ubiquitous, and even the bus system actually works like a bus system is supposed to--for everyone.
The statement about per capita income is also specious, at best, since everything in China costs less than here in the US. You can (and I have) hired a car with a driver for something like $30US a day, and we wandered all over the place. Food is cheaper, rent is way cheaper, utilities are cheaper. So to try and say that because the per capita incoming is below $5000US a year is an indicator of major poverty just demonstrates some major ignorance. In China, you can definately get by on $5000US a year, and even less depending on location.
If they hold their present course it's just a matter of time (and not that long) until the Chinese will be trully able to stand with the US and Europe as an economic and political power to be reckoned with. The real question is how we're going to deal with that--as ideological adversaries, or friendly competitors.
Really, Ballmer is so full of crap it runs out his nose. There, I feel better having said that. Now, here's why:
I have first-hand knowledge of both Thailand and China, and I can tell you that the hardware there is already cheap by our standards. But it's still beyond the reach of most of the population. Ballmer does make a semi-interesting point about the cybercafes (although he manages to scramble it, like most of his other utterances)--the people can't afford to have a PC at home, so they have adopted a scheme that they can afford. And therein lies a fundamental point that Ballmer and Co. just don't get: They would have to practically give away PC's with Windows already loaded to get these people interesting in taking one home with them.
The other issue facing MS is one of national pride, which they also don't seem to get. I know from my own experiences that many Asians regard MS as an arrogant and obnoxious US company, and their monopolistic game plan causes a significant amount of anxiety, and some degree of embarrassment, for both governments and end users. When they pay for Windows, where does their money go? Back into Thailand or China? No, it goes into Ballmer and Gates' pockets. And then they get to watch Ballmer on video do his "monkey-boy" prancing at MS presentations, or Gates going on about his great vision for the future, which is something that even makes me squirm to watch. Do the Thai and the Chinese resent giving their hard-earned money to a bunch of greedy American bozos? Hell yes they do.
Trying to sell marginally usable and drastically overpriced software to people in other countries without giving them some reason to feel good about their money going overseas is never going to work for MS, or any other company. You've got to give something back, and you've got to make the buyers and users feel like they have a stake in it, otherwise you're just another foreigner intent on taking advantage of the locals. The Chinese still remember the Boxer Rebellion and the occupation of Manchuria very clearly. A little thought will show why the Chinese want their own version of Linux and not Windows on their PC's. It makes perfect sense from a Chinese point of view.
Ballmer's biggest problem with Asia is that he appears to be completely incapable, like many Americans, of even recognizing that the Chinese, the Thai, or anyone else in Asia, might have a point of view different than his own.
"In regards to Fact 37 ("Rigorous inspections [code reviews] can remove up to 90% of errors before the first test case is run, but are so mentally and emotionally exhausting that we rarely do them."): so what?"
Two reasons (there are more, but these are the best ones that come to mind immediately):
(1) The next time you park yourself on a commercial airliner you can be thankful that the software controlling the engines, the autopilot and the cabin pressure controls, to name just a few subsystems, was reviewed exhaustively at every step in the life cycle. They do this for a reason: It finds errors that testing alone cannot detect. [DO-178B, Section 6, available here]
(2) If fixing an error during implemention costs, say, 1 unit of resources (the baseline), then fixing that same error during requirements generation will only cost 0.2, and fixing it after deployment will cost upwards of 20 times the baseline. [from Software Requirements, by Alan M. Davis]
People who don't do reviews during the requirements, design and implementation phases are destined to spend their time poking their buggers and trying to explain to annoyed customers why the software doesn't work. Putting the effort up-front into good requirements design and code reviews makes the final testing and verification so much easier.
As for myself, I detest debugging at the tail-end of the life cycle; I'd much rather be moving on to the next fun project. Wouldn't you?
Whew... I'm glad your instructor doesn't design the embedded software for digital engine controllers on commercial jet aircraft (I do, BTW). The requirements documents for these are typically 200+ pages in length, and the code ranges between 10K and 50K lines of either Ada or C (with some C++ for those who like to chase fads and make their own lives difficult). If commercial software was developed with the same attentiveness to requirements and verifiability as the stuff used to keep you and your fellow passengers from becoming greasy spots in some corn field in Kansas we wouldn't be spending so much time whining about bugs and bloat in our desktop and enterprise apps. We wouldn't have to.
Requirements are both good and necessary, but they do require something that I've noticed a severe lack of amongst programmers: Discipline. The discipline to develop preliminary functional models, perform up front what-if analysis, do the FMEA's and maybe a few MSC models for the interfaces. Then map it all back into what the customer says they want and walk them though it. Sound like a lot of work? It is. It also requires a modest amount of negotiating skill and the willingness to both educate the customer, when necessary, and the determination to stick to your guns when you know you are right, always.
I can hire truckloads of happy little coders who don't have a clue about requirements, and then train them (which I often have to do), but I treasure the software engineer who knows and understands the value of requirements, knows what the term "traceability" means, and can effectively translate the customer's needs and wants into a set of models and requirements definitions that accurately and adequately capture the design objectives.
And, yes, things do change during the course of a project, and new things are discovered. That's why the requirements specification is a "live" document subject to continuous review, and there are things called "derived requirements".
And, just one other thing to consider. If you assume a unit cost of defect removal of one (1) at the coding stage, then it's been shown that finding and removing a defect at the requirements stage only costs around.2! That's right. It gets better. Over half of all errors in SW are introduced at the requirements stage. Not doing any requirements? Then brace yourself for some long and agonizing test and debug sessions. Don't believe me? Take a look at this report:
Then again, I guess there are some folks who enjoy whacking away at their software, growing it "incrementally" (no relation to the formal model, BTW), and spending their time at the back end of the project listening to the customer scream about missed delivery dates while they frantically do the compile-test-debug dance over and over. For myself, I'd rather see it just work with a minimum of verification hassle from the outset and then get on with my life.
I'm wondering how many people actually bothered to read the referenced article...
If I'm not mistaken the article is talking about media mastering, not playback. There's a BIG difference there. Also, the article mentions that the market is expanding, which implies that they have either already sold some units or plan to do so real soon, not 10 years out as someone claimed.
Another point: If you read the specs attached to the article you'll notice the phrase "Vacuum seal air spindle motor". Unless they're referring to something different than what I've worked with, that means getting a rotating mechanism into a vacuum chamber using either a magnetic coupled drive shaft or a rotary vacuum seal.
And for those of you wondering how an electron beam DVD device is going to work with your current PC: Well, the simple answer is that it won't. Not unless you have a vacuum chamber sitting next to your PC and bunch of multi-stage pumps and gas traps sitting underneath. Electrons don't remain focused and usable for very long outside of a vacuum. They tend to either dissapate or show up as sparks or arcs.
And, lastly, to answer someone's question about a homemade SEM. Yeah, you can build one, and it's been discussed before. It's really not that hard, just expensive (you'll need the previously mentioned vacuum pumps and assorted plumbing, and a couple of precision power supplies in the 10 to 50KV range will come in handy as well).
This line in the article, for me, is the key issue: "Where might I find some guidance on this, and why is this already taking too freaking long?"
I'm busy. I have things to do. I don't have time to fiddle with someone else's idea of cleverness, or a badly designed interface that can't decide on how to assign command key functions consistently, or which lacks any useful help (the CUPS example is just a case in point). Nor am I interested in solving puzzles or pondering the greater mysteries of my Inner Tux. I just want to get the damn thing up and running so I can get on with what I wanted to do in the first place.
Perhaps it's a matter of perspective: If the computer is an end unto itself, then things like usability for a wider audience aren't really relevant. But for a lot of folks, myself included, the computer is nothing more than a tool with which I hope to get some useful work accomplished. I'll use whatever works, even if it is Windows. Occasional crashes and lock-ups aside, Windows does help me get the job done and I don't have to spend half a day reading man pages and badly written "manuals" trying to figure out how to install and configure something, and that's what really counts for me.
The bottom line is that I'll rm -rf a badly written tool's source tree just as fast as I'll pitch a cheap pair of pliers into the trashcan. They're both useless to me if they waste my time and impede my progress.
Eric Raymond sums it up nicely with the statement that "the problem is that these simple things never occurred to developers who bring huge amounts of already-acquired knowledge to bear every time they look at their user interfaces."
So the next time you look down your nose at some poor slob who just can't figure out how to install and configure something that you could do in your sleep, just keep in mind that there's a reason MS still rules the desktop, and it has a lot to do with millions of those poor clueless slobs.
I didn't intend to imply that it was inferior, I said it was awkward, and I'll stand by that. My first thought on seeing a terse help screen pop up when I thought I'd hit the right key (lessee, do I press space here, or is it enter?) was of a neophyte Linux user with a "deer in the headlights" look on their face after trying to do this. Do enough admin work and you get real familiar with that expression. Unfortunately, it's those folks who more often than not cut the paychecks, so things have got to be as smooth and graceful as possible. At least with Redhat the control inputs were consistent and more in line with other software packages.
I did like the way that I was able to install packages without the annoying dependency issues that Redhat sometimes has, but something has got to be done with the UI for the installation. Ugh. Redhat was at least on the right track, so I know it can be done. I hope someone is working on that for debian.
I'm really rather dissapointed by this. Although I wasn't too impressed with the way that Redhat liked to play games with the files and directories in/etc (among other things), I've always been pleased with how easy it was to get a RH distro installed and running. After just making the switch to Debian and going through the agony of selecting packages with an ackward selection tool, I appreciate RH's RPM system even more.
It extracts data by looking at the return levels at the various wavelenghts of the filters, among other things. With image processing software like IRAF you can get an amazing amount of information out of an image. Also, conventional comsumer CCD cameras use one CCD device with a RGB patterned color filter literally painted onto the face of the CCD to get red, green and blue. High-end cameras use three CCD's with seperate filters in front of each imaging device and splitter prisms to direct the light. Since things like weight and complexity are issues when building spacecraft, they accomplish the same thing as the high-end cameras here on earth by using one CCD and a filter wheel. This approach also allows them to do other things, such as take images through polarizers, or have magnification if they need it, and all in one camera package. And, last but not least, these cameras are tested and calibrated to within an inch of their lives before they ever leave the ground, so the researchers know exactly what the dark current (electronic noise), flat field (pixal responsiveness across the entire CCD) and defect characteristics for the CCD are. This information is then used to subtract out a lot of the noise and imperfections, leaving as much of the original data for analysis as possible. That analysis is the stuff of research papers like this one.
After looking at the claims on this guy's web site it occurred to me that he probably should have spent a wee bit of time with something like The Handbook of Artificial Intelligence (in four volumes), and Erik Mueller's "Daydreaming in Humans and Machines", an earlier version of which is available for download here, although I would recommend purchasing the hard-cover version. The first reference is a must-have collection of papers for anyone interested in where AI research has been and what's already been acheived, and Mueller's book absolutely knocked my socks off when I first read it. Another reference this guy obviously missed is Kosslyn and Koenig's "Wet Mind", which provides a very interesting, if somewhat speculative (I'm being nice here, OK?) blueprint for a cognitive system. And then of course there's Dan Dennet and his theories of cognition. And Pylyshyn, Stich, Foder, Minsky, etc., etc., etc..
The AI and cognitive science fields already have such a large body of published theories and experimental work that I think this guy has basically wasted his money getting himself a vanity patent, and demonstrated his own deep level of ignorance about the whole field in the process. The first time he tries to collect his millions of dollars he's going to discover what's lurking in a field of study with hordes of earnest researchers and a 50 year history.
So I'm not worried about him and his patent, it will blow away with the first little breeze of reality, but I am profoundly disturbed about a U.S. Patent Office which hands out BS like this to anyone with a filing fee and the right format for the paperwork. Now, that's the real travesty here.
But, wait, didn't they make this prediction back around, oh, 1966 or so? Nifty theorem provers would unlock the power of the computer for real Artifical Intelligence? No, actually, it was predicted even earlier than that, by no less than Turing. He figured we'd have machines capable of passing his "imitation game" test by the end of the 20th century.
Wrong on all counts. Speech recognition software still requires training and it's clumsy to use. Contents filters (as now mandated for libraries receiving federal funding, thanks to the oh-so-technically-savvy U.S. Supreme Court) still can't reliably tell the difference between breasts as in breast cancer and breasts as in porno. And the AI crowd is still grappling with things like knowledge representation schemas and semantic networks.
IMHO what we will most likely see are systems with huge lookup tables and canned procedural responses driving complex state machines, not flexible systems capable of introspection or foresight. It might even begin to exhibit what the philosophy/cognitive science crowd likes to call "emergent properties". It may even begin to become useful, but it most definately won't be sentient.
I have to admit, though, it would be nice to able to ask my house AI to list my appointments for the day and assemble a personalized news report from the wires while I brush my teeth and get dressed. But I trully don't think that'll be a reality until about the time I decide to pack it in and retire, if then. And then I won't really need it, or even care.
Pfft! They promised us flying cars and video phones, too, and I haven't seen any of those running lately, either.
What an ugly little box! It reminds me of a Muntz 8-track tape player. (yeah, yeah, I'm really that old--so what?)
But, wait... Maybe it IS an 8-track tape player! Someone finally figured out what to do with all those left over cases after the Muntz company folded sometime last century. Yeah, that's it. Recycling!
The RIAA and the MPAA haven't figured out how to have a good time screwing each other, so they're going to give their customers the shaft instead.
If all the fancy RIAA and MPAA business managers couldn't figure out something that Ron Jeremy did!
Ron's got it easy: Unzip, insert, money shot, go home and get a beer. The fancy business managers are still working on the money shot bit, but they have figured out how to insert their heads up their rectums. I give the RIAA and the MPAA about 24 months before they manage to drive a large number of their member companies into Chapter 13.
In fact when I first set up a Linux box I was amazed at how easy it was, especially after hearing comments like yours over and over again.
Interesting point. OK, I'll concede that things have gotten easier (at least recently). Which is a Good Thing. There are, however, reasons for why these things continue to be said, and it has a lot to do with the long, deep history of Unix-like OS's and all the whirly-twirly that's lurking under that pretty KDE desktop. It's when the user wants to go beyond just what comes out of the box and past the install that things start to get problematic. Which, IMHO, is probably more an indication of the archaic nature of the underlying OS architecture than an indication of a problem at the user interface level.
But there is hope, I think. As I stated in the original post:
Apparently someone at Lindows did bother to pay attention and start to make the Linux experience less painful for those without the inclination or ability to fiddle around under the hood.
And I say more power to 'em. I hope they get filthy rich, or at least financially comfortable.
Their test was biased: The mom in question already had a clue. They should have tried the test with my mom. Here's a typical "call for help":
Mom: Hi. The power went off over here and now I can't get my computer to work.
Me: Uhm, OK. Does it do anything at all?
Mom: Well, the printer is on, and the screen says "Check connection".
Me: Hmmm. Alright. Is everything plugged in?
Mom: Yes, it looks like it. All the little doohickies are in the back of the computer.
Me: (avoiding this until the last--it just can't be the cause) Is the computer turned on?
Mom: I think so. There's something on the screen.
Me: Uhm, I meant, did you actually push the power button on the computer?
Mom: Nooo. Should I?
Me: (after a pause) Yeah, that might be a good idea.
Mom: Oh! There it is! Now it's working!
Me: (sigh) Well, there you go. Let me know if you have any other problems with it.
Now, if they'd tried their test with my mom, I don't think they would have faired quite as well.
One of the biggest stumbling blocks to the adoption of Linux on the desktop has been the nerdish nature of the whole installation, configuration and user experience. Your average PC user (and most likely non-/. reader) is doing good to figure out how to get a printer connected to their Windows machine. The typical Linux distro is a no-go for these folks. Forget configuring a NIC, modifying the defaults for Gnome or KDE, or trying to figure out how to FTP a file from an xterm shell prompt. It just won't happen. MS has made Windows what it is not on its technical merits, but because it's been dumbed-down to the point where almost anyone can make it do something useful right out of the box with only a modest amount of coaching. A while back Russ Mitchell offered this rather negative view of Linux's chances on the desktop. While not everything he says is golden, a lot of it does apply, and should be seriously considered by anyone with dreams of seeing MS pushed into the backseat. Apparently someone at Lindows did bother to pay attention and start to make the Linux experience less painful for those without the inclination or ability to fiddle around under the hood.
And before you poo-poo those poor sods who can't grok a regular expression or launch a background task from bash, just remember this: They're the ones with most of the disposable income, not us nerds, and Bill Gates et. al. know it.
If it's GPL, people have to talk to you to use it commercially, you know?
No, they don't. Read sections 2 and 3 of the GPL (version 2) again. Carefully. The FSF's short write-up on selling GPL'ed software might come as something of a surprise to some folks who've not taken the time to look into it.
Placing software under the GPL helps to ensure that it will remain free and that the author will retain the copyright, but it doesn't guarantee that anyone will come offering money to use it. So long as the next person/company down the line abides by the terms of the GPL regarding copyright notices and source code availability the original author isn't automatically entitled to any monetary compensation.
GPL'ed stuff has been a part of some commercial products for a while now. Bundling useful GPL stuff with a Non-GPL proprietary product is a way to provide customers with a set of useful tools which enjoy a wide base of support. WindRiver's V5.1 VxWorks RTOS development suite for SunOS/Solaris is a case in point. And it's perfectly OK under the GPL so long as there's a clear seperate between the GPL and Non-GPL code. GPL code can form the basis for a viable commercial product, even if the source must be readily available, since the number of people with the skills and/or resources to duplicate the derivative work will undoubtedly be much less than those who just want to make use of it without poking under the hood. And for those who do want to poke around, more power to them.
A good example of a commercial product built on Linux and GPL'ed code is Tivo. You can download the source and fiddle around with it if you want to. Has that stopped Tivo from making money? No. Do they pay royalties or other monies back to the original authors of the GPL'ed code? Only if they feel inclined to do so. I don't know if they do or not.
IMHO the LRP died not for lack of technical elegance or application potential, but more for lack of marketing inspiration. Placing a project under the GPL means that one must think about capitalizing on the free distribution and the exposure offered by the open source environment. It's my considered opinion that unless one is willing to offering consulting services, custom modifications, or a useful product in a nicely packaged form ready for use, then just GPL'ing something and expecting the bucks to start rolling in when someone else picks it up and runs with it is only somewhat less realistic than buying weekly lottery tickets and hoping to hit the jackpot.
The alternative, and naive, view that GPL means that it's all free (as in free beer), while wrong according to the FSF, is perhaps a more kindly and community-minded take on it. But it too will lead to starvation just as quickly as unrealistic expectations of income.
So if someone takes some GPL'ed code, modifies it to suit their needs, puts it on a nice silk-screened CD, writes a manual and makes money off of it, then so long as they also make the sources available to the purchaser and keep the copyright notices intact, about the only thing the original author can say is "Shucks, I should have thought of that".
Slashdot Mirror
IBM's versions, from 2.0 onwards, extended that with better GUI support, real multi-platform interoperability and backwards compatibility. I was an OS/2 developer from 1.0 through 2.1, and a participant in IBM's OS/2 developer's program (I even purchased several big PS/2 machines, very nice for their day, and gave presentations to groups of bored scientists about it). I was also heartbroken when Gerstner pulled the plug on OS/2 and effectively doomed it to obscurity. But, I've since moved on to Linux and FreeBSD, and I haven't looked back.
If OS/2 was going to be open-sourced, I think the parts of real interest would be the pre-2.0 code and some of the 2.x kernel extensions. But, so far as I know, 1.x is mostly MS code, and will never see the light of day. I don't know if there's enough of the 2.x that isn't legally encumbered to be of interest to anyone.
It's a pity, though, because it could have been what Windows wanted to be, and Linux could be. But, that could be said for NextOS and BeOS as well. Just because something is a good idea doesn't mean it will enjoy success in the real world.
A good place to look is "Software Requirements--Revision" by Alan Davis (1993). I don't agree with everything Davis has to say, but the book is full of good ideas and potential "gotchas" to watch out for. Another good reference is DO-178B, the guidelines used for the development and testing of safety-critical software in commercial aerospace applications. It is available from the RTCA for about $50.
If you're doing an OO project, then you might want to look at Booch's book: "Object Oriented Analysis and Design" and the UML 2.0 specification .
But, most importantly, you MUST have some kind of design documentation (requirements, at a minimum) and that documentation needs to be flexible enough to accomodate changes without causing everything else to grind to a halt while the revisions happen. Expecting to get good software with inadequate formal documentation, minimal planning and insufficient requirements is why 70% of all commercial software projects end in failure (documented and published statistic).
Anyone who says you can do good software by shooting from the hip is nuts. And they don't work for me.
I've been there, and not just to the big tourist-friendly places like Beijing, but to the interior as well. Everywhere you look you see forward progress, even in the rural areas. Many of the things the article mentions aren't just for the party elite, they're widespread. Sure, it's a centralized Communist government, but in reality it has a lot in common with the type of government China has known for the past 2000 years--central authority, distribution of authority to outlying cities and provinces, and a system of reporting back to HQ how things are going in the rest of the country. Add to that the Chinese cultural emphasis on unity and harmony, and you have a system that works relatively well (at least nowadays) for them. The Chinese government wants to modernize, and they know that they must modernize to be a player on the world stage, but they want to do so in a way that will not result in discord in their culture.
But, politics aside, to make the claim that "the vast majority" of the country doesn't have access to this "technology" is ludicrous. Almost all of the examples mentioned were public technologies. Everyone can benefit from smart traffic lights, and it's true that cellphones are almost everywhere (I once saw a fellow sitting on his ancient motorized tricycle thing with a huge stack of what looked like sticks, talking on his cellphone way out in the countryside). China is awash in cybercafes, television is ubiquitous, and even the bus system actually works like a bus system is supposed to--for everyone.
The statement about per capita income is also specious, at best, since everything in China costs less than here in the US. You can (and I have) hired a car with a driver for something like $30US a day, and we wandered all over the place. Food is cheaper, rent is way cheaper, utilities are cheaper. So to try and say that because the per capita incoming is below $5000US a year is an indicator of major poverty just demonstrates some major ignorance. In China, you can definately get by on $5000US a year, and even less depending on location.
If they hold their present course it's just a matter of time (and not that long) until the Chinese will be trully able to stand with the US and Europe as an economic and political power to be reckoned with. The real question is how we're going to deal with that--as ideological adversaries, or friendly competitors.
I have first-hand knowledge of both Thailand and China, and I can tell you that the hardware there is already cheap by our standards. But it's still beyond the reach of most of the population. Ballmer does make a semi-interesting point about the cybercafes (although he manages to scramble it, like most of his other utterances)--the people can't afford to have a PC at home, so they have adopted a scheme that they can afford. And therein lies a fundamental point that Ballmer and Co. just don't get: They would have to practically give away PC's with Windows already loaded to get these people interesting in taking one home with them.
The other issue facing MS is one of national pride, which they also don't seem to get. I know from my own experiences that many Asians regard MS as an arrogant and obnoxious US company, and their monopolistic game plan causes a significant amount of anxiety, and some degree of embarrassment, for both governments and end users. When they pay for Windows, where does their money go? Back into Thailand or China? No, it goes into Ballmer and Gates' pockets. And then they get to watch Ballmer on video do his "monkey-boy" prancing at MS presentations, or Gates going on about his great vision for the future, which is something that even makes me squirm to watch. Do the Thai and the Chinese resent giving their hard-earned money to a bunch of greedy American bozos? Hell yes they do.
Trying to sell marginally usable and drastically overpriced software to people in other countries without giving them some reason to feel good about their money going overseas is never going to work for MS, or any other company. You've got to give something back, and you've got to make the buyers and users feel like they have a stake in it, otherwise you're just another foreigner intent on taking advantage of the locals. The Chinese still remember the Boxer Rebellion and the occupation of Manchuria very clearly. A little thought will show why the Chinese want their own version of Linux and not Windows on their PC's. It makes perfect sense from a Chinese point of view.
Ballmer's biggest problem with Asia is that he appears to be completely incapable, like many Americans, of even recognizing that the Chinese, the Thai, or anyone else in Asia, might have a point of view different than his own.
Two reasons (there are more, but these are the best ones that come to mind immediately):
(1) The next time you park yourself on a commercial airliner you can be thankful that the software controlling the engines, the autopilot and the cabin pressure controls, to name just a few subsystems, was reviewed exhaustively at every step in the life cycle. They do this for a reason: It finds errors that testing alone cannot detect. [DO-178B, Section 6, available here]
(2) If fixing an error during implemention costs, say, 1 unit of resources (the baseline), then fixing that same error during requirements generation will only cost 0.2, and fixing it after deployment will cost upwards of 20 times the baseline. [from Software Requirements, by Alan M. Davis]
People who don't do reviews during the requirements, design and implementation phases are destined to spend their time poking their buggers and trying to explain to annoyed customers why the software doesn't work. Putting the effort up-front into good requirements design and code reviews makes the final testing and verification so much easier.
As for myself, I detest debugging at the tail-end of the life cycle; I'd much rather be moving on to the next fun project. Wouldn't you?
Where does it say in the GPL that I'm restricted in regards to where I can use GPL'ed code? Non-commercial use only?
Requirements are both good and necessary, but they do require something that I've noticed a severe lack of amongst programmers: Discipline. The discipline to develop preliminary functional models, perform up front what-if analysis, do the FMEA's and maybe a few MSC models for the interfaces. Then map it all back into what the customer says they want and walk them though it. Sound like a lot of work? It is. It also requires a modest amount of negotiating skill and the willingness to both educate the customer, when necessary, and the determination to stick to your guns when you know you are right, always.
I can hire truckloads of happy little coders who don't have a clue about requirements, and then train them (which I often have to do), but I treasure the software engineer who knows and understands the value of requirements, knows what the term "traceability" means, and can effectively translate the customer's needs and wants into a set of models and requirements definitions that accurately and adequately capture the design objectives.
And, yes, things do change during the course of a project, and new things are discovered. That's why the requirements specification is a "live" document subject to continuous review, and there are things called "derived requirements".
And, just one other thing to consider. If you assume a unit cost of defect removal of one (1) at the coding stage, then it's been shown that finding and removing a defect at the requirements stage only costs around .2! That's right. It gets better. Over half of all errors in SW are introduced at the requirements stage. Not doing any requirements? Then brace yourself for some long and agonizing test and debug sessions. Don't believe me? Take a look at this report:
NIST study on software defects
It's big, but chock full of good information.
For an introduction to requirements engineering, this is one of my favorite books:
Davis' book on software requirements techniques
And lastly, here are some links for the curious:
FMEA/FMECA info
Good article on DO-178B
Some more info on DO-178B
A paper on requirements traceability
Info on SDL and MSC
Then again, I guess there are some folks who enjoy whacking away at their software, growing it "incrementally" (no relation to the formal model, BTW), and spending their time at the back end of the project listening to the customer scream about missed delivery dates while they frantically do the compile-test-debug dance over and over. For myself, I'd rather see it just work with a minimum of verification hassle from the outset and then get on with my life.
If I'm not mistaken the article is talking about media mastering, not playback. There's a BIG difference there. Also, the article mentions that the market is expanding, which implies that they have either already sold some units or plan to do so real soon, not 10 years out as someone claimed.
Another point: If you read the specs attached to the article you'll notice the phrase "Vacuum seal air spindle motor". Unless they're referring to something different than what I've worked with, that means getting a rotating mechanism into a vacuum chamber using either a magnetic coupled drive shaft or a rotary vacuum seal.
And for those of you wondering how an electron beam DVD device is going to work with your current PC: Well, the simple answer is that it won't. Not unless you have a vacuum chamber sitting next to your PC and bunch of multi-stage pumps and gas traps sitting underneath. Electrons don't remain focused and usable for very long outside of a vacuum. They tend to either dissapate or show up as sparks or arcs.
And, lastly, to answer someone's question about a homemade SEM. Yeah, you can build one, and it's been discussed before. It's really not that hard, just expensive (you'll need the previously mentioned vacuum pumps and assorted plumbing, and a couple of precision power supplies in the 10 to 50KV range will come in handy as well).
I'm busy. I have things to do. I don't have time to fiddle with someone else's idea of cleverness, or a badly designed interface that can't decide on how to assign command key functions consistently, or which lacks any useful help (the CUPS example is just a case in point). Nor am I interested in solving puzzles or pondering the greater mysteries of my Inner Tux. I just want to get the damn thing up and running so I can get on with what I wanted to do in the first place.
Perhaps it's a matter of perspective: If the computer is an end unto itself, then things like usability for a wider audience aren't really relevant. But for a lot of folks, myself included, the computer is nothing more than a tool with which I hope to get some useful work accomplished. I'll use whatever works, even if it is Windows. Occasional crashes and lock-ups aside, Windows does help me get the job done and I don't have to spend half a day reading man pages and badly written "manuals" trying to figure out how to install and configure something, and that's what really counts for me.
The bottom line is that I'll rm -rf a badly written tool's source tree just as fast as I'll pitch a cheap pair of pliers into the trashcan. They're both useless to me if they waste my time and impede my progress.
Eric Raymond sums it up nicely with the statement that "the problem is that these simple things never occurred to developers who bring huge amounts of already-acquired knowledge to bear every time they look at their user interfaces."
So the next time you look down your nose at some poor slob who just can't figure out how to install and configure something that you could do in your sleep, just keep in mind that there's a reason MS still rules the desktop, and it has a lot to do with millions of those poor clueless slobs.
I did like the way that I was able to install packages without the annoying dependency issues that Redhat sometimes has, but something has got to be done with the UI for the installation. Ugh. Redhat was at least on the right track, so I know it can be done. I hope someone is working on that for debian.
I'm really rather dissapointed by this. Although I wasn't too impressed with the way that Redhat liked to play games with the files and directories in /etc (among other things), I've always been pleased with how easy it was to get a RH distro installed and running. After just making the switch to Debian and going through the agony of selecting packages with an ackward selection tool, I appreciate RH's RPM system even more.
Hope that was useful.
The AI and cognitive science fields already have such a large body of published theories and experimental work that I think this guy has basically wasted his money getting himself a vanity patent, and demonstrated his own deep level of ignorance about the whole field in the process. The first time he tries to collect his millions of dollars he's going to discover what's lurking in a field of study with hordes of earnest researchers and a 50 year history.
So I'm not worried about him and his patent, it will blow away with the first little breeze of reality, but I am profoundly disturbed about a U.S. Patent Office which hands out BS like this to anyone with a filing fee and the right format for the paperwork. Now, that's the real travesty here.
But, wait, didn't they make this prediction back around, oh, 1966 or so? Nifty theorem provers would unlock the power of the computer for real Artifical Intelligence? No, actually, it was predicted even earlier than that, by no less than Turing. He figured we'd have machines capable of passing his "imitation game" test by the end of the 20th century.
Wrong on all counts. Speech recognition software still requires training and it's clumsy to use. Contents filters (as now mandated for libraries receiving federal funding, thanks to the oh-so-technically-savvy U.S. Supreme Court) still can't reliably tell the difference between breasts as in breast cancer and breasts as in porno. And the AI crowd is still grappling with things like knowledge representation schemas and semantic networks.
IMHO what we will most likely see are systems with huge lookup tables and canned procedural responses driving complex state machines, not flexible systems capable of introspection or foresight. It might even begin to exhibit what the philosophy/cognitive science crowd likes to call "emergent properties". It may even begin to become useful, but it most definately won't be sentient.
I have to admit, though, it would be nice to able to ask my house AI to list my appointments for the day and assemble a personalized news report from the wires while I brush my teeth and get dressed. But I trully don't think that'll be a reality until about the time I decide to pack it in and retire, if then. And then I won't really need it, or even care.
Pfft! They promised us flying cars and video phones, too, and I haven't seen any of those running lately, either.
But, wait... Maybe it IS an 8-track tape player! Someone finally figured out what to do with all those left over cases after the Muntz company folded sometime last century. Yeah, that's it. Recycling!
If all the fancy RIAA and MPAA business managers couldn't figure out something that Ron Jeremy did!
Ron's got it easy: Unzip, insert, money shot, go home and get a beer. The fancy business managers are still working on the money shot bit, but they have figured out how to insert their heads up their rectums. I give the RIAA and the MPAA about 24 months before they manage to drive a large number of their member companies into Chapter 13.
And I, for one, won't be sad to see them go.
Oops. The reply got attached to the wrong posting. (Did I do that? Probably, but I'd rather blame Gremlins. Oh well)
Interesting point. OK, I'll concede that things have gotten easier (at least recently). Which is a Good Thing. There are, however, reasons for why these things continue to be said, and it has a lot to do with the long, deep history of Unix-like OS's and all the whirly-twirly that's lurking under that pretty KDE desktop. It's when the user wants to go beyond just what comes out of the box and past the install that things start to get problematic. Which, IMHO, is probably more an indication of the archaic nature of the underlying OS architecture than an indication of a problem at the user interface level.
But there is hope, I think. As I stated in the original post:
And I say more power to 'em. I hope they get filthy rich, or at least financially comfortable.
Mom: Hi. The power went off over here and now I can't get my computer to work.
Me: Uhm, OK. Does it do anything at all?
Mom: Well, the printer is on, and the screen says "Check connection".
Me: Hmmm. Alright. Is everything plugged in?
Mom: Yes, it looks like it. All the little doohickies are in the back of the computer.
Me: (avoiding this until the last--it just can't be the cause) Is the computer turned on?
Mom: I think so. There's something on the screen.
Me: Uhm, I meant, did you actually push the power button on the computer?
Mom: Nooo. Should I?
Me: (after a pause) Yeah, that might be a good idea.
Mom: Oh! There it is! Now it's working!
Me: (sigh) Well, there you go. Let me know if you have any other problems with it.
Now, if they'd tried their test with my mom, I don't think they would have faired quite as well.
One of the biggest stumbling blocks to the adoption of Linux on the desktop has been the nerdish nature of the whole installation, configuration and user experience. Your average PC user (and most likely non-/. reader) is doing good to figure out how to get a printer connected to their Windows machine. The typical Linux distro is a no-go for these folks. Forget configuring a NIC, modifying the defaults for Gnome or KDE, or trying to figure out how to FTP a file from an xterm shell prompt. It just won't happen. MS has made Windows what it is not on its technical merits, but because it's been dumbed-down to the point where almost anyone can make it do something useful right out of the box with only a modest amount of coaching. A while back Russ Mitchell offered this rather negative view of Linux's chances on the desktop. While not everything he says is golden, a lot of it does apply, and should be seriously considered by anyone with dreams of seeing MS pushed into the backseat. Apparently someone at Lindows did bother to pay attention and start to make the Linux experience less painful for those without the inclination or ability to fiddle around under the hood.
And before you poo-poo those poor sods who can't grok a regular expression or launch a background task from bash, just remember this: They're the ones with most of the disposable income, not us nerds, and Bill Gates et. al. know it.
No, they don't. Read sections 2 and 3 of the GPL (version 2) again. Carefully. The FSF's short write-up on selling GPL'ed software might come as something of a surprise to some folks who've not taken the time to look into it.
Placing software under the GPL helps to ensure that it will remain free and that the author will retain the copyright, but it doesn't guarantee that anyone will come offering money to use it. So long as the next person/company down the line abides by the terms of the GPL regarding copyright notices and source code availability the original author isn't automatically entitled to any monetary compensation.
GPL'ed stuff has been a part of some commercial products for a while now. Bundling useful GPL stuff with a Non-GPL proprietary product is a way to provide customers with a set of useful tools which enjoy a wide base of support. WindRiver's V5.1 VxWorks RTOS development suite for SunOS/Solaris is a case in point. And it's perfectly OK under the GPL so long as there's a clear seperate between the GPL and Non-GPL code. GPL code can form the basis for a viable commercial product, even if the source must be readily available, since the number of people with the skills and/or resources to duplicate the derivative work will undoubtedly be much less than those who just want to make use of it without poking under the hood. And for those who do want to poke around, more power to them.
A good example of a commercial product built on Linux and GPL'ed code is Tivo. You can download the source and fiddle around with it if you want to. Has that stopped Tivo from making money? No. Do they pay royalties or other monies back to the original authors of the GPL'ed code? Only if they feel inclined to do so. I don't know if they do or not.
IMHO the LRP died not for lack of technical elegance or application potential, but more for lack of marketing inspiration. Placing a project under the GPL means that one must think about capitalizing on the free distribution and the exposure offered by the open source environment. It's my considered opinion that unless one is willing to offering consulting services, custom modifications, or a useful product in a nicely packaged form ready for use, then just GPL'ing something and expecting the bucks to start rolling in when someone else picks it up and runs with it is only somewhat less realistic than buying weekly lottery tickets and hoping to hit the jackpot.
The alternative, and naive, view that GPL means that it's all free (as in free beer), while wrong according to the FSF, is perhaps a more kindly and community-minded take on it. But it too will lead to starvation just as quickly as unrealistic expectations of income.
So if someone takes some GPL'ed code, modifies it to suit their needs, puts it on a nice silk-screened CD, writes a manual and makes money off of it, then so long as they also make the sources available to the purchaser and keep the copyright notices intact, about the only thing the original author can say is "Shucks, I should have thought of that".
You missed one: "Never underestimate the power of human stupidity." - Robert Heinlein