Why not a combination of stereovision, range finding, and a digital horizon to enable real time mapping based off a visual system?
Stereo vision has two fundamental limitations. First, it doesn't work very well unless the scene has clean, sharp edges to match up. Second, the accuracy decreases rapidly with range, beause you're measuring a narrow triangle from angles at the base.
The algorithms for stereo vision aren't all that forgiving. There are basically two flavors. One finds and matches "features", usually corners. This works nicely for indoor scenes and badly on dirt roads. The other does a straightforward correlation between matching scan lines from two cameras, sliding them back and forth looking for the best match. This has a high false alarm rate on surfaces with high-frequency detail, like gravel roads.
Practical problems include the fact that correlation algorithms are sensitive to high-frequency noise, so any thermal noise from the camera is a major problem. Also, keeping two cameras aligned to within a pixel while jouncing along on an off-road vehicle requires a very rigid mounting with the cameras near the center of gravity along the inter-camera axis. (For an example of a good one, see the Bumblebee from Point Grey. They have the most successful stereo vision products.)
To date, the most successful outdoor stereo vision system used on a mobile robot was on the NASA Hyperion robot. They were able to achieve a range of about 7 meters on rocky terrain with hard edges. This is about a third the range that theory predicts.
A DARPA Grand Challenge vehicle needs at least 20 meters of range, and if you want to go fast, 50 meters. You need 1.5 to 2x your stopping distance.
We have a stereo camera setup working on my desk here, and we've had it for over a year. We've tried that.
Stereo from motion, where you work with successive frames from a single camera, has potential. The baseline is the distance you move between frames, which can be much bigger than the distance between two cameras. But people have been trying to make that work for years without much success. If you want to work on vision, that's a good problem. Especially since you can just take data from a camcorder and crunch on it - no special hardware required for development.
Modern x86 CPUs go to incredible lengths to support self-modifying code. PowerPCs, by comparison, don't support it at all; they have separate instruction and data caches. If you modify code in a PowerPC, you have to flush the instruction cache or it won't work. There are system calls for this under the MacOS. And nobody notices. In fact, the PPC 601 didn't even have the instruction cache flush instruction. For some years, Linux for PPCs had to flush the cache by preventing interrupts and loading a big block of junk data to invalidate the entire data cache. About the only time this is done is during fork/exec sequences.
There's some history of self-modifying code from the 16-bit DOS world, but it's probably time to kill that off.
It's been a long time since self-modifying code improved performance. Today, self-modifying code on an x86 machine works something like this.
The processor is going along, fetching ahead perhaps ten instructions, and executing as many as possible simulataneously. Ten to twenty instructions may be in the pipelines. The retirement unit is running ten to twenty cycles behind the execution units, committing results back into cached memory and registers once all possibility of trouble has passed.
Trouble usually comes in the form of mispredicted branches, which are handled reasonably efficiently using cached bits that record which way the branch went the last few times. Less common is an exception, like a floating point overflow, which looks like a forced branch. Least common is a modified instruction.
The superscalar x86 machines (Pentium Pro/2/3/4 and later) check for modified instructions. Storing into an instruction immediately ahead will be handled properly. People on the Pentium Pro team sweat blood over making this work right. And it does work. But not rapidly. The retirement unit views the instruction as an "operand" for collision detection purposes, so a change to that "operand" invalidates all the results that depend on it.
The CPU then has to deal with the mess. Retirement stops. Instruction fetching stops. The pipelines are flushed. The functional units are idled. Instruction fetching is backed up to the modified instruction and restarted. The CPU pipelines refill with the new program. After a few tens of cycles have been lost, instruction execution is moving forward again.
In AMD land, it's even worse. AMD's approach to superscalar CPU design involves expanding instructions into a RISC-like fixed length form at cache load time. Storing into an instruction not only requires flushing the CPU, but the whole block of instructions has to be reparsed.
So, in general, self-modifying code is not going to help performance. Generating blocks of code and then making them executable is fine, but changing code you're about to execute went out with "ALTER paragraph-name TO PROCEED THROUGH paragraph-name" in COBOL.
With the possible exception of CMU, nobody had a system that could avoid a ditch or a pothole.
Stereo vision won't do a good enough job on dirt for long range ditch/pothole detection. All the laser rangefinders except CMU's were fixed line scanners, so they couldn't possibly profile the ground ahead reliably from a bouncing vehicle.
CMU's approach is a big hammer. They took a stock line-scanning laser rangefinder and put it in a huge 3-axis gimbal, which they then actively stabilize. That should be able to profile terrain, but it's a huge mechanical kludge. If you miss a spot because you hit a bump, you have a hole in your data. At that point you can either slow down and rescan, or plow ahead blindly. They may eventually complete the course with that rig, but no way is it a commercially viable technology.
The next generation of sensor technology may be ready in time. There are at least three groups with usable sensors in the prototype stage. We're talking to two of them. But that's all I'm going to say for now.
(We're recruiting. See our jobs page. No pay, some risk, a fraction of the prize, we cover all expenses. Silicon Valley only. We have our own shop in an industrial park in Redwood City. If you're local, come over and see the thing.)
In addition to popup blocking, we need some better handling of popup windows in browsers:
Windows opened from scripting are treated as children of the parent window. When the parent window closes, so must the child window. When the parent window is moved to the back or minimized, the child windows must do the same. (You can still minimize or dismiss the child window, of course.)
Windows opened by scripting should retain some visual association with the parent window. They
should overlap it at least slightly, unless the
user moves the window.
Windows opened by scripting have a user-settable maximum size. Anything bigger than this comes up with scroll bars.
Flash animations must be closeable and blockable.
Flash, and all other "controls", should run in a jail, permitted to talk to the screen and the originating site only. There must be right-click menu options to kill any "control", whether it likes it or not.
All windows have close buttons.
No script can open more than one window per user click.
We need to keep control of the browser GUI in the user's hands, no matter what the site tries to do.
This was shown publicly last year, and published in September 2003.
Super high resolution monitors have been done before, but usually as CRTs. Greyscale CRTs are easy to make, and have been used for medical X-ray viewing, where 5-megapixel displays are often used. The medical monitor makers are now offering 5-megapixel greyscale LCD panels. Color panels still have lower resolutions.
Yeah. You'd think that the FBI could divert some of those 200 agents in the Baltimore office who work child pornography to tracking this down. Put in a few credit card numbers and wait for the first transactions that use them. Then pounce.
Screen too small. Keys too small. Not going to get better in those respects.
Personally, I want a phone with better voice recognition (at least as good as Wildfire or TellMe), no screen, and good integration with Directory Assistance.
IBackup is a secure, online storage/ backup, access and sharing solution for consumers and businesses with a unique combination of backup and storage functions. Protect your information assets with IBackup.
But read their terms:
Accordingly, your use of your account and the
service is at your sole risk. Your account and the
service is provided to on an "as is" and "as
available" basis. Pro Softnet, on behalf of itself and its distributors, advertisers and suppliers, disclaims all warranties adn condtions, express or implied, arising by law or otherwise, with respect to your account and the service.....
Pro Softnet makes no representation or warranty...
that the data and files you store in your account will not be lost or damaged.
So the Ibackup service is worthless. They don't stand behind it.
LiveVault offers a warranty, but not much of one. If they lose your data, you get the last three months of service fees back. That's not great, but it's way ahead of IBackup.
The FTC had a conference on this subject back in April. How did this get on the BBC now?
The FTC issue here is that the FTC has some antitrust responsibilities, and there are situations under which antitrust law can overcome patent law.
A crucial issue here is patents which cover de-facto standards. Anyone can get a very narrow patent by narrowing the claims. Normally, a narrow patent isn't useful, because it's easy to do the same thing in some other way. But if, say, Microsoft comes up with a unique way of doing something, makes it a de-facto standard, and patents it, such a patent can prevent interoperability.
But enforcing such a patent may be an antitrust violation. That's where the FTC comes in. If a patent is only useful if you're the dominant player, the patent is valid but enforcing it is a violation of antitrust law. It's not a patentability issue; it's a restraint of trade issue, which is the FTC's area.
If antitrust enforcement hadn't been out to lunch since the Carter administration, we'd have more cases on this and the obnoxious use of narrow patents by dominant players would be far less of a problem. Maybe the FTC is waking up. It seems unlikely from the Bush administration, but some good stuff has actually been happening over there.
Realize that the Linux command line model isn't the only one. It isn't even a very good one. It's what could be implemented on a PDP-11 without trying too hard. The DEC 36-bit machines had far better command line environments, including intelligent command completion and option presentation for most commands.
The UNIX command line presents the user with the "parser puzzle". The system knows the syntax, and the user has to satisfy the system, without much help. And, typically, the user gets zero help from the system in keeping things consistent.
Of course users are bitching.
Keeping things consistent is the real problem. But I've written on that before. For now, let me point out that the command line lacks a basic function we expect in everything else in computing - undo. Think hard about why that's the case.
It's not fundamental that command lines can't have undo. Command line systems that support undo exist. It's just that the UNIX model doesn't support it. If you want to think about this clearly, understand what a transaction is in the SQL sense, and how commit and revert work in the database world.
The input side of UNIX commands is cryptic, but the output side is worse. Especially for scripting. One of the fundamental design mistakes of UNIX is that programs have arguments on the input side, but all they return is a single integer. If programs called other programs and got answers back in argc/argv, or the environment variables, scripts would be much more effective and reliable.
Error messages from programs that called other programs might look like the designer had a clue.
Scripts tend to blindly plow ahead, even when doing something totally bogus, or fail at the first problem, leaving the system in some wierd state. That's not a good thing.
I've been using UNIX-like systems since 1978. I'm not impressed with people who think they're l33t because they know most of the options to "ls" and can write simple regular expressions.
If that describes you, go read "The Inmates are Running the Asylum" before replying.
The killer app will be one that takes in existing singing, works backwards to get a model of the singer, and then can generate songs from MIDI and lyrics as if sung by that singer. Instant cover albums.
Once the Webb telescope is launched ~2010, the Hubble will re-enter the Earth's atmosphere around that time, depending on the impact of the Sun on the upper atmosphere.
Well, actually, the Hubble will re-enter whether or not a replacement is launched.
NASA threw $300 million at the Flight Telerobotic Servicer project in the 1990s. That project had roughtly the same spec this one does - a 4-year project to develop a remotely controlled robot for satellite maintenance.
Total failure. Not even a ground-based prototype. Lots of studies and papers on components, but no real results. It's so NASA.
The project manager on that project is still on the NASA payroll. That, too, is so NASA.
Moving to Windows 2000 is an upgrade. Moving from Windows 2000 to Windows XP is a downgrade.
Windows 2000 works for you. Windows XP works for Microsoft. "Updates are ready for download" (which can appear on machines with no network connection), tightly integrated IE, and more restrictive licensing terms, all make it clear that XP is optimized for Microsoft's benefit, not yours.
There's a good reason that most of corporate America is still running Windows 2000. It's one of Microsoft's most solid versions, probably the most stable one since NT 3.51.
If you're still running anything Microsoft prior to Win2K, upgrade to Win2K. If you're running Win2K, the next available upgrade is to Linux.
I dunno. Feeding multiple tracks of 192Kb/s analog audio through a 25-pin D-sub connector seems tacky.
I would have expected one coax per channel. But it's probably good enough for popular music.
I went to Case from 1966-1970. Back then, they offered a good, solid engineering education, but they were already in decline. Case was the only school ever kicked off the ARPAnet. They had an ARPAnet connection in the late 1960s and lost it because they didn't perform on some contracts.
Computing at Case took a wierd turn. In 1968, the school spun off the CS department as a private company, called Chi Corporation. Chi operated as a computer service bureau, developed their own operating system, and sold CPU time to the university and its students. (Chi went through a long series of mergers and selloffs. At one point its major business was school-bus scheduling).
The food manufacturing industry makes millions of tons of prepared food every day. With consistent quality. That doesn't happen by accident.
There are flavor chemists. Engineers. Thermodynamics experts. Plumbers. Quality control. Cooks are for kitchens, not plants.
The processes are not the ones you see in kitchens, either. Homogenizers, oil-curtain continuous fryers, and encapsulators aren't seen even in hotel kitchens, but they're standard units in food processing plants.
In food manufacturing, as in other manufacturing, recipes have tolerances. Those tolerances were determined in test kitchens and pilot plants, where the process failure points were explored.
Temperature, humidity, time, viscosity, and other process parameters can be controlled if necessary.
They're routinely controlled to the point that the process works every time.
Face it. Many foods made on an industrial scale, especially cakes, cookies, and candies, are better than those made at home. Most other prepared food is better than the average homemaker can do, and far more consistent.
The compromises in industrial food preparation have mostly to do with storage and shelf life, not manufacturing.
This is a cry for help from Sun. It's a desperate attempt to create a new revenue stream.
The basic conflict in computing today is that users want to buy something, turn it on, get work done, and not deal with the vendor again. Think of this as the "Wal-Mart model". Vendors want an "ongoing relationship" involving regular payments from the customer. Think of this as the "cell phone" model.
Now that everybody in the developed world who has any need for a computer already has one, it's all replacement business. This is driving vendor profitability through the floor. They've reduced warranties on disk drives, delivered software that requires constant patching, and come out with machines in multiple case colors. But it's not working.
Customers hate the cell phone model of business, where the vendor has you under their thumb. Absent a monopoly situation, it doesn't sell. Sun is in no position to monopolize anything. So they can want this, but it's not going to happen.
If you want to visualize the future of computing, imagine a boot stepping on a face, forever.
Zuse Z3 (1938-1941) - small general purpose relay computer. Good architecture, but limited by relay speeds to a 5Hz (yes, Hz) clock. First floating point unit. No jump instruction, due to a low budget. The later Z4 (1945-1949) had jumps and conditional branches.
Atanasoff-Berry
(1937-1942) Programmable, electronic arithmetic, binary, but memory was a rotating drum of capacitors.
ENIAC (1943-1946) - plugboard-programmed tube machine. No general purpose memory, just registers. Tube ALU.
IBM 603 Electronic Multiplier (1946) - first commercial electronic computing product. Punched card I/O, not truly programmable, but electronic multiplication and division.
Most of these machines had electronic arithmetic units.
The big problem was memory. There were no good memory technologies yet, and none of those machines had much memory. They all basically had a few registers, like a calculator. Each bit of memory required a relay, a tube, or a discrite capacitor and switchgear.
Finally, the memory problem was solved.
EDVAC, (1947-1952), had 1K of mercury-tank delay line memory. This was a lousy main memory technology (you had to wait for the word you wanted to come around, like a disk), but allowed reasonable memory sizes. It was clunky, but at last, there was memory.
With the memory problem partially solved, various groups started building machines. Pilot ACE, ACE, and IAS date from this period.
The UNIVAC I (1948-1951) had it all - memory (1K words, in mercury tanks), console, tape drives, console typewriter, programmability, electronic arithmetic, a reasonable instruction set, and self-checking. It was built, sold, and used. UNIVAC I was the first of these machines that a modern programmer would consider usable.
As others have mentioned, it's worth a visit. But go on a weekend, when the volunteers show up. I went on a weekday, and the tour guide was more into English country architecture than cryptography.
Actually, TV-sized plasma panels are expected to drop in price by a factor of 2 or 3 in the next year, as the low-end consumer electronics manufacturers get into volume production.
The fabrication problem is tough. Plasma panels have a back part, with the electrodes and drive lines, and a front part, with the phosphors. These have to align within a fraction of a pixel. But, as is typical with manufacturing processes, slowly the problems are solved and the process becomes routine and reliable.
I use recent versions of Mozilla for everything, on Windows, Linux, and QNX, and I'm not too impressed. It has long pauses. It crashes. It corrupts its mail files. It corrupts XUL.MFL and won't start until you delete that file. And all those problems have been occuring for years.
One of the lessons that developers keep forgetting is that databases are hard. Look at the classic troublesome applications: Sendmail, BIND, and Netscape/Mozilla. Each of those programs has its own third-rate home-grown database system. In each case, the database has little or no integrity-preserving or checking machinery. So the database and applications break down.
Microsoft uses Jet, their little embedded database system, for such things. Jet isn't a great database, but it's better than most of the amateur efforts that show up inside open source apps.
If you need a database, use a database. At least something at the BerkeleyDB level.
Slashdot Mirror
Stereo vision has two fundamental limitations. First, it doesn't work very well unless the scene has clean, sharp edges to match up. Second, the accuracy decreases rapidly with range, beause you're measuring a narrow triangle from angles at the base.
The algorithms for stereo vision aren't all that forgiving. There are basically two flavors. One finds and matches "features", usually corners. This works nicely for indoor scenes and badly on dirt roads. The other does a straightforward correlation between matching scan lines from two cameras, sliding them back and forth looking for the best match. This has a high false alarm rate on surfaces with high-frequency detail, like gravel roads.
Practical problems include the fact that correlation algorithms are sensitive to high-frequency noise, so any thermal noise from the camera is a major problem. Also, keeping two cameras aligned to within a pixel while jouncing along on an off-road vehicle requires a very rigid mounting with the cameras near the center of gravity along the inter-camera axis. (For an example of a good one, see the Bumblebee from Point Grey. They have the most successful stereo vision products.)
To date, the most successful outdoor stereo vision system used on a mobile robot was on the NASA Hyperion robot. They were able to achieve a range of about 7 meters on rocky terrain with hard edges. This is about a third the range that theory predicts. A DARPA Grand Challenge vehicle needs at least 20 meters of range, and if you want to go fast, 50 meters. You need 1.5 to 2x your stopping distance.
We have a stereo camera setup working on my desk here, and we've had it for over a year. We've tried that.
Stereo from motion, where you work with successive frames from a single camera, has potential. The baseline is the distance you move between frames, which can be much bigger than the distance between two cameras. But people have been trying to make that work for years without much success. If you want to work on vision, that's a good problem. Especially since you can just take data from a camcorder and crunch on it - no special hardware required for development.
There's some history of self-modifying code from the 16-bit DOS world, but it's probably time to kill that off.
It's been a long time since self-modifying code improved performance. Today, self-modifying code on an x86 machine works something like this.
So, in general, self-modifying code is not going to help performance. Generating blocks of code and then making them executable is fine, but changing code you're about to execute went out with "ALTER paragraph-name TO PROCEED THROUGH paragraph-name" in COBOL.
CMU's approach is a big hammer. They took a stock line-scanning laser rangefinder and put it in a huge 3-axis gimbal, which they then actively stabilize. That should be able to profile terrain, but it's a huge mechanical kludge. If you miss a spot because you hit a bump, you have a hole in your data. At that point you can either slow down and rescan, or plow ahead blindly. They may eventually complete the course with that rig, but no way is it a commercially viable technology.
The next generation of sensor technology may be ready in time. There are at least three groups with usable sensors in the prototype stage. We're talking to two of them. But that's all I'm going to say for now.
John Nagle / Team Overbot.
(We're recruiting. See our jobs page. No pay, some risk, a fraction of the prize, we cover all expenses. Silicon Valley only. We have our own shop in an industrial park in Redwood City. If you're local, come over and see the thing.)
-
Windows opened from scripting are treated as children of the parent window. When the parent window closes, so must the child window. When the parent window is moved to the back or minimized, the child windows must do the same. (You can still minimize or dismiss the child window, of course.)
-
Windows opened by scripting should retain some visual association with the parent window. They
should overlap it at least slightly, unless the
user moves the window.
-
Windows opened by scripting have a user-settable maximum size. Anything bigger than this comes up with scroll bars.
-
Flash animations must be closeable and blockable.
Flash, and all other "controls", should run in a jail, permitted to talk to the screen and the originating site only. There must be right-click menu options to kill any "control", whether it likes it or not.
-
All windows have close buttons.
-
No script can open more than one window per user click.
We need to keep control of the browser GUI in the user's hands, no matter what the site tries to do.Super high resolution monitors have been done before, but usually as CRTs. Greyscale CRTs are easy to make, and have been used for medical X-ray viewing, where 5-megapixel displays are often used. The medical monitor makers are now offering 5-megapixel greyscale LCD panels. Color panels still have lower resolutions.
We don't really have consumer level HD cameras yet. JVC's offering is only 720/30p.
Tonight, at the Sony Metreon in SF: Harry Potter and the Prisoner of Azkaban in IMAX . Now that's the way to see the movie.
Yeah. You'd think that the FBI could divert some of those 200 agents in the Baltimore office who work child pornography to tracking this down. Put in a few credit card numbers and wait for the first transactions that use them. Then pounce.
Personally, I want a phone with better voice recognition (at least as good as Wildfire or TellMe), no screen, and good integration with Directory Assistance.
But read their terms:
So the Ibackup service is worthless. They don't stand behind it.
LiveVault offers a warranty, but not much of one. If they lose your data, you get the last three months of service fees back. That's not great, but it's way ahead of IBackup.
The FTC issue here is that the FTC has some antitrust responsibilities, and there are situations under which antitrust law can overcome patent law. A crucial issue here is patents which cover de-facto standards. Anyone can get a very narrow patent by narrowing the claims. Normally, a narrow patent isn't useful, because it's easy to do the same thing in some other way. But if, say, Microsoft comes up with a unique way of doing something, makes it a de-facto standard, and patents it, such a patent can prevent interoperability.
But enforcing such a patent may be an antitrust violation. That's where the FTC comes in. If a patent is only useful if you're the dominant player, the patent is valid but enforcing it is a violation of antitrust law. It's not a patentability issue; it's a restraint of trade issue, which is the FTC's area.
If antitrust enforcement hadn't been out to lunch since the Carter administration, we'd have more cases on this and the obnoxious use of narrow patents by dominant players would be far less of a problem. Maybe the FTC is waking up. It seems unlikely from the Bush administration, but some good stuff has actually been happening over there.
The UNIX command line presents the user with the "parser puzzle". The system knows the syntax, and the user has to satisfy the system, without much help. And, typically, the user gets zero help from the system in keeping things consistent. Of course users are bitching.
Keeping things consistent is the real problem. But I've written on that before. For now, let me point out that the command line lacks a basic function we expect in everything else in computing - undo. Think hard about why that's the case. It's not fundamental that command lines can't have undo. Command line systems that support undo exist. It's just that the UNIX model doesn't support it. If you want to think about this clearly, understand what a transaction is in the SQL sense, and how commit and revert work in the database world.
The input side of UNIX commands is cryptic, but the output side is worse. Especially for scripting. One of the fundamental design mistakes of UNIX is that programs have arguments on the input side, but all they return is a single integer. If programs called other programs and got answers back in argc/argv, or the environment variables, scripts would be much more effective and reliable. Error messages from programs that called other programs might look like the designer had a clue. Scripts tend to blindly plow ahead, even when doing something totally bogus, or fail at the first problem, leaving the system in some wierd state. That's not a good thing.
I've been using UNIX-like systems since 1978. I'm not impressed with people who think they're l33t because they know most of the options to "ls" and can write simple regular expressions. If that describes you, go read "The Inmates are Running the Asylum" before replying.
The killer app will be one that takes in existing singing, works backwards to get a model of the singer, and then can generate songs from MIDI and lyrics as if sung by that singer. Instant cover albums.
Good open source project for music geeks.
Well, actually, the Hubble will re-enter whether or not a replacement is launched.
Total failure. Not even a ground-based prototype. Lots of studies and papers on components, but no real results. It's so NASA.
The project manager on that project is still on the NASA payroll. That, too, is so NASA.
Windows 2000 works for you. Windows XP works for Microsoft. "Updates are ready for download" (which can appear on machines with no network connection), tightly integrated IE, and more restrictive licensing terms, all make it clear that XP is optimized for Microsoft's benefit, not yours.
There's a good reason that most of corporate America is still running Windows 2000. It's one of Microsoft's most solid versions, probably the most stable one since NT 3.51.
If you're still running anything Microsoft prior to Win2K, upgrade to Win2K. If you're running Win2K, the next available upgrade is to Linux.
I dunno. Feeding multiple tracks of 192Kb/s analog audio through a 25-pin D-sub connector seems tacky. I would have expected one coax per channel. But it's probably good enough for popular music.
Computing at Case took a wierd turn. In 1968, the school spun off the CS department as a private company, called Chi Corporation. Chi operated as a computer service bureau, developed their own operating system, and sold CPU time to the university and its students. (Chi went through a long series of mergers and selloffs. At one point its major business was school-bus scheduling).
There are flavor chemists. Engineers. Thermodynamics experts. Plumbers. Quality control. Cooks are for kitchens, not plants.
The processes are not the ones you see in kitchens, either. Homogenizers, oil-curtain continuous fryers, and encapsulators aren't seen even in hotel kitchens, but they're standard units in food processing plants.
In food manufacturing, as in other manufacturing, recipes have tolerances. Those tolerances were determined in test kitchens and pilot plants, where the process failure points were explored. Temperature, humidity, time, viscosity, and other process parameters can be controlled if necessary. They're routinely controlled to the point that the process works every time.
Face it. Many foods made on an industrial scale, especially cakes, cookies, and candies, are better than those made at home. Most other prepared food is better than the average homemaker can do, and far more consistent. The compromises in industrial food preparation have mostly to do with storage and shelf life, not manufacturing.
The basic conflict in computing today is that users want to buy something, turn it on, get work done, and not deal with the vendor again. Think of this as the "Wal-Mart model". Vendors want an "ongoing relationship" involving regular payments from the customer. Think of this as the "cell phone" model.
Now that everybody in the developed world who has any need for a computer already has one, it's all replacement business. This is driving vendor profitability through the floor. They've reduced warranties on disk drives, delivered software that requires constant patching, and come out with machines in multiple case colors. But it's not working.
Customers hate the cell phone model of business, where the vendor has you under their thumb. Absent a monopoly situation, it doesn't sell. Sun is in no position to monopolize anything. So they can want this, but it's not going to happen.
If you want to visualize the future of computing, imagine a boot stepping on a face, forever.
Most of these machines had electronic arithmetic units. The big problem was memory. There were no good memory technologies yet, and none of those machines had much memory. They all basically had a few registers, like a calculator. Each bit of memory required a relay, a tube, or a discrite capacitor and switchgear.
Finally, the memory problem was solved. EDVAC, (1947-1952), had 1K of mercury-tank delay line memory. This was a lousy main memory technology (you had to wait for the word you wanted to come around, like a disk), but allowed reasonable memory sizes. It was clunky, but at last, there was memory.
With the memory problem partially solved, various groups started building machines. Pilot ACE, ACE, and IAS date from this period.
The UNIVAC I (1948-1951) had it all - memory (1K words, in mercury tanks), console, tape drives, console typewriter, programmability, electronic arithmetic, a reasonable instruction set, and self-checking. It was built, sold, and used. UNIVAC I was the first of these machines that a modern programmer would consider usable.
As others have mentioned, it's worth a visit. But go on a weekend, when the volunteers show up. I went on a weekday, and the tour guide was more into English country architecture than cryptography.
The fabrication problem is tough. Plasma panels have a back part, with the electrodes and drive lines, and a front part, with the phosphors. These have to align within a fraction of a pixel. But, as is typical with manufacturing processes, slowly the problems are solved and the process becomes routine and reliable.
That was Dennis Richie. As an exercise for the original poster, find the famous published paper in which Richie described this.
One of the lessons that developers keep forgetting is that databases are hard. Look at the classic troublesome applications: Sendmail, BIND, and Netscape/Mozilla. Each of those programs has its own third-rate home-grown database system. In each case, the database has little or no integrity-preserving or checking machinery. So the database and applications break down.
Microsoft uses Jet, their little embedded database system, for such things. Jet isn't a great database, but it's better than most of the amateur efforts that show up inside open source apps.
If you need a database, use a database. At least something at the BerkeleyDB level.