Extortion scams like that require a money laundering service to process the payments. e-Gold is apparently popular.
Another is WebMoney, mentioned on the spammer board SpamForum.biz.
It's a anonymous money transfer service
in Moscow. Elaborate crypto. Special downloaded
applications. Schemes for transferring money
between customers, and finally out into the banking
system. Accounts can be in euros, dollars, rubles,
or hryvnias. Address is supposedly 71 Sadovnicheskaya Street,
Moscow, Russia, 115035. Same address as the "Three
Monkeys", which is a gay nightclub.
There are a number of services like this. They come and go. There's Gold-Cash, in Latvia. There's EvoCash, at an undisclosed "offshore" location. (Well, there was EvoCash; they ceased operations on October 19th.)
They even have a trade association, which rates services as "Platinum", "Gold", "Silver", "Copper", "Carbon", or "Chlorine", which gives a hint of the problems in this area.
Then there are brokers who transfer money between these services. These can be used to perform the "rinse cycle" in money laundering. But that's another story.
Our Overbot is built on the Polaris Ranger platform, which, like the Gator, has six wheels. The Ranger has a little more power, true 6 wheel drive, and a faster top speed of 40MPH.
However, in Mac OS X, Mach is linked with other kernel components into a single kernel address space. This is primarily for performance; it is much faster to make a direct call between linked components than it is to send messages or do remote procedure calls (RPC) between separate tasks.
It had to be done that way because the IPC system Mach bolted onto a BSD kernel is slow.
Retrofitting message passing onto a kernel that wasn't designed for it seems to consistently result in a slow message passing system. This is because message passing has to be tightly integrated with CPU dispatching to get really good performance. It's not the data copying that kills you. It's the extra trips through the scheduler.
Mach has simplex ports, like UNIX pipes. Big mistake. To get high performance message passing, you have to make subroutine-call like operations work really efficiently. The basic operations in QNX are MsgSend/MsgRecv/MsgReply, which has the effect of a subroutine call between two processes.
Process A does a MsgSend to process B, which is hopefully waiting in a MsgRecv for some work to do. Process A blocks, and process B unblocks. The trick is that when this happens, the normal case, where process B is waiting, is handled by an immediate transfer of control from process A to process B, without a pass through the scheduler to find the next ready to run process. To return, process B does a MsgReply, which immediately unblocks process A.
If you do this with Mach-type simplex ports, where the primitives were ill-chosen, it requires several trips through the scheduler, because the primitives don't lend themselves to simple transfer-control semantics. A does a write, which unblocks B but doesn't block A. So A keeps going. Then A does a read, which blocks A and causes a trip through the scheduler, at which point B is found ready to run and started. The same thing happens in the other direction. Two extra trips through the scheduler.
Worse, if there's another CPU-bound process ready to run, a trip through the scheduler may pick it instead. After all, it's been waiting longer. So each interprocess call results in a chance of losing your current time slice. This adds latency.
This is why message passing and CPU dispatching must be well-integrated, or performance is terrible. All the retrofits of IPC to UNIX type kernels seem to suffer from this problem.
Incidentally,
MacOS X is based on Mach 2.x, which is a modified BSD kernel with Mach extensions. Mach 3.x, CMU's rewrite and a true microkernel, never really worked very well. But a few pieces of it made it into MacOS X, which gives Apple some Mach 3 bragging rights. But it's not a microkernel. It's a BSD kernel with extensions.
You can buy a DVD player for $29.95 at Best Buy. The sub-$100 computer can't be that far out of reach.
An XBOX is basically an appliance PC. That's what a sub-$100 PC will look like. There have to be millions of identical ones, with no options, so the manufacturing line just runs and runs.
Microkernel architecture is really hard to get right. If you get it right, microkernels are fast and stable, like VM for IBM mainframes and QNX.
Both have long, long uptimes, run important systems, and are modified very seldom.
But most architects don't get it right.
If you get it wrong, like Mach, no amount of patching will fix it. Because open source development has a "patch" mentality, it's almost impossible to fix fundamental architectural problems in an open source project.
The HURD people finally dumped Mach and went to L4, which is a half-finished academic microkernel.
That's not working either.
I'd like to see a high-security microkernel OS in widespread use, but the HURD guys aren't going to deliver it. And we really need one.
We've done this already. Three times. Once with Netscape. Once with IE. And once with Mozilla.
Browsers, as a "platform", suck.
You really don't want browsers downloading and executing code. It's just too insecure. That way lies the hell of Active-X. The great thing about HTML is that it's basically descriptive, not executable. Downloading code in some interpretive language is only slightly less insecure, and much slower. (Or, when there's a page with a dumb ad on screen, CPU usage goes to 100%)
Asking the user for permission to run code doesn't work. Not only will users answer "yes" for hostile code, they'll implicitly agree to EULAs your business's lawyers would never agree to.
Most free "plugins" are in some sense hostile code. They phone home. They look around the host machine. They burn CPU time when not doing anything for the user. Even the "good ones", like Google's toolbar, overreach. Others are much worse.
What we really need are good extensions to HTML for forms. Better validation and help are all things that can be done descriptively, rather than by running executable code on the user's machine. HTML forms are lame; they can't even set up a field that must, say, have five numeric digits and must be filled in. You could do that on IBM green-screen terminals thirty years ago.
It's a historical accident that graphics processors are peripherals, though. Early SGI machines had the 4x4 multiplier as a coprocessor, not tied to the display. Apple's first attempt at 3D acceleration had a 3D coprocessor separate from the display. But because the CPU manufacturers ignored graphics for a long, long time, the 3D market was based on add-ons, and those had to be sold as plug-in boards. Peripheral bandwidth was too low to usefully put a coprocessor on a plug-in board. Hence the "3D graphics board".
Bank of America's bill-paying service is still available.
If the receiver has a BofA merchant account, the transfer occurs electronically.
If not, BofA prints up a check and sends it.
I'd much rather get services like that from a legitimate commercial bank than some flakey service like PayPal.
Realistically, you don't want to send money to a "merchant" that can't qualify for a Visa/MC merchant account. I've run mail-order software sales out of my house, and I had a real merchant account from a major bank (not a reseller), a business license, a fictitious name filing, and a Dun and Bradstreet rating. All those things are easy to get. Someone who doesn't have them is probably doing something wrong.
Having two non-identical CPUs in the same package, or in the same machine, isn't that useful. Typically, the "wierd" ones sit idle unless whatever application that specifically uses them is running.
The operating system usually has no idea what to do with the "wierd" processor, so it gets managed as a peripheral, which doesn't work very well.
There were some wierd Mac variations in the 1980s with a second CPU on a plug-in board. They could run Photoshop faster, but otherwise were useless.
There are really only two multi-CPU architectures that are generally useful: shared-memory symmetrical multiprocessors, and networked clusters with no shared memory. Many other architectures have been tried - partially shared memory machines, shared-memory machines where some CPUs lacked some features like floating point, hypercubes, single-instruction-multiple-datastream machines, and dataflow processors. None has achieved lasting success.
About the only unusual architecture ever sold in volume is the Playstation 2, with two vector processors. Even there, the vector processors are mostly used as a GPU. (Although one major game physics engine actually runs in the PS2 vector processors, an impressive achievement.)
Programming for wierd architectures is hard, requires much tool development, and results in programs tied to specific hardware. So it doesn't happen much. That's why the wierd architectures fail. They're never that much faster, and by the time the software works, the hardware market is somewhere else.
After several months of wandering around in the $3.50 range, SCOX is down to $3.08.
The last year of SCOX on a log scale is roughly a straight line from $18 down to $3. This seems to reflect roughly the cash SCO has left as they spend money with the lawyers.
Remember, IBM's killer summary judgement motions are still pending. This case could change drastically any day now, and not in SCO's favor.
Aluminaut, the other deep-diving research submersible from the 1960s, is also retired.
They're all gone now, the record-holding vehicles of the 1960s. The Concorde, the SR-71, the Saturn V, Alvinn, the Aluminaut. All gone, with the will to replace them gone as well.
About fifteen years ago,the big problem with robotics R&D was the lack of off the shelf platforms. Too much academic time was going into building motorized bases.
But that's no longer the case. There are many good off the shelf bases. Cybermotion, iRobot, Arrick, ActiveMedia, Klephera, and Zagros all make wheeled robot bases. Even legged machines are available.
Right now, the big bottleneck is sensing. Visual processing still doesn't work (the hardware is fine, but the theory doesn't work), true 3D laser rangefingers aren't here yet (although I've seen one working on an optical bench) and submillimeter radar hasn't reached production yet (millimeter radar has limited resolution.) Most of the hobbyist world is still using 1980s ultrasonic devices, IR reflectance sensors, and feelers, which don't work any better than they did in the 1980s.
Which is about typical for "invention shows". I went to the British one in 2002, when it was at the Barbican in London. The people who exhibit there have no clue how to check for prior art.
The "expandable airport walkway" is found at smaller airports today. Santa Barbara, California, has several.
Retractable parking posts are widely used. Most are solid (there's now a big "security" market for the things) but there are lightweight ones that can be driven over.
Everything else listed has been found by someone else, so I won't rehash that.
What you want for security are little processes communicating through narrow interfaces. That's RPC.
The problem is that Microsoft's approach to RPC is insecure, because it comes from the old OLE system under Windows 3.1. Authorization and authentication across RPC connections is weak.
Not that Linux is any better. The RPC systems for Linux/UNIX are clunky afterthoughts built on top of sockets.
They're talking about a graphics card with little if any 3D acceleration. You usually get something at least that good, if not better, in the motherboard chipset. As an external graphics board, a 2D board, in 2004, is totally unnecessary.
It might be more worthwhile to work on better relationships between Linux developers and Via. Via sells a large fraction of the motherboard chipsets (if it's not Intel, it's probably Via) and, as a commodity part manufacturer, doesn't have a strong business interest in a proprietary interface.
If Via can be brought on board (assuming it isn't already) that provides more leverage for dealing with other vendors, like nVidia.
It's not that big a deal, but it is a correct historical note. I did considerable work on network congestion in the early days (look at the RFCs that bear my name, John Nagle), so I was aware of that problem back then.
I was in favor of more effective ICMP Source Quench. I wanted a Source Quench to cut the size of the TCP congestion window for a while. This worked reasonably well.
But back then, we didn't have hostile packet floods to contend with. Today, any congestion control system must be protected against spoofing, or it will become a vehicle for denial of service attacks.
Instead we have Random Early Drop. Congestion notification by packet dropping is like traffic control by randomly kicking cars off the freeway.
It has a useful effect on congestion, but it hurts individuals.
The way the Internet really works is that the backbone has far more bandwidth than it really needs, because fibre is cheap and hardware routers are really fast. If the backbone gets congested, the network works very, very badly. (Remember in the mid-1990s, when MAE-WEST would congest and the whole West Coast would see 60% packet loss rates?)
We really don't know how to handle mid-network congestion very well. Fortunately, that problem has been eliminated by throwing bandwidth at the problem.
Near the fringes, we have congestion, but the number of different streams going through a choke point like an edge router is small enough that "fair queuing" (or "traffic shaping", in fancier forms) works.
This works well with TCP, which throttles down based on round trip time. It prevents sources that don't throttle from hogging all the bandwidth.
Usually, there's only one organization on a edge router, so if you want some other policy (like giving priority to video streams) it doesn't affect other users.
Somewhat to my surprise, after twenty years, we have an Internet that works better than I'd expected after huge scaleup. But really, the main reason it works is excess backbone bandwidth.
From what I've read, C++ has the same difficulty as the original FORTRAN did; the original parser was ad hoc, so that it was a nightmare to parse with reasonable techniques, and arguably therefore harder for humans to deal with.
No, that's not what went wrong. The original version of C (not "K&R", but earlier, as in V6 UNIX circa 1978) didn't have "typedef". That version was LALR(1), and parsable by a simple parser that knew only the reserved words. Wnen "typedef" went in, the grammar became context-dependent - you couldn't parse it without knowing the type names.
One undefined typename and the parser gets lost.
The syntax went downhill from there.
Pascal doesn't have that problem, because the syntax
var foo: bar;
is unambiguous. The C form
foo bar;
can't be parsed until you know that "foo" is a type.
One implication of the C/C++ parsing problem is that there are few tools that do much with source code. Even a reliable indenter for C++ is hard.
Berkeley Pascal was awful. It's responsible for much of Pascal's bad reputation.
It was basically a new parser for the C compiler. Anything the back end of the C compiler didn't have had to be faked by the front end. Subscript checking was horrendously inefficient, with a subroutine call for every subscript check.
Variant records were implemented by allocating separate storage for each variant. It optimized almost nothing. And it was a straight ISO Pascal, with a minimal hack for external compilation.
As a result, a generation of UNIX programmers grew up thinking that Pascal was much less efficient than C.
Ever use a Roomba? It's really dumb, navigates by bumping into things, gets tangled in cords, and doesn't clean very well. I'd expected better from Rod Brooks. Even for a purely reactive robot, it's unusually stupid.
There are better automated vacuums. There was a good one back in the 1980s, from Denning Robotics, but it was a huge riding vacuum for malls and airports. Good technology, but too big. There's a new small robot vacuum that doesn't bump into stuff, but it's priced around $1000. That's the technology to watch.
TCP assumes all packet losses are due to congestion.
The original idea was that TCP assumed packet losses were due to transmission errors. Congestion information was supposed to come in via ICMP Source Quench. But the BSD people didn't implement Source Quench, which broke that approach. So TCP had to assume that packet losses meant congestion, and slow down accordingly. That's how we got here.
Actually, if there's an OS in a car today, it's probably QNX.
QNX's maker, QSSL, keeps a low profile; you don't see their logo on end user products. But somewhere inside, there's the little OS that just works.
I've heard that Microsoft made a presentation to some big car company, and insisted that Microsoft had to control the content of the startup screen. The car people did not like that at all.
Slashdot Mirror
Bore your friends with your vacation photos? Carry around PowerPoint presentations?
This sounds like a "hey, we can add this useless feature for no hardware cost" idea.
Another is WebMoney, mentioned on the spammer board SpamForum.biz. It's a anonymous money transfer service in Moscow. Elaborate crypto. Special downloaded applications. Schemes for transferring money between customers, and finally out into the banking system. Accounts can be in euros, dollars, rubles, or hryvnias. Address is supposedly 71 Sadovnicheskaya Street, Moscow, Russia, 115035. Same address as the "Three Monkeys", which is a gay nightclub.
There are a number of services like this. They come and go. There's Gold-Cash, in Latvia. There's EvoCash, at an undisclosed "offshore" location. (Well, there was EvoCash; they ceased operations on October 19th.) They even have a trade association, which rates services as "Platinum", "Gold", "Silver", "Copper", "Carbon", or "Chlorine", which gives a hint of the problems in this area.
Then there are brokers who transfer money between these services. These can be used to perform the "rinse cycle" in money laundering. But that's another story.
See our video (6MB, Quicktime) here. This is our DARPA Grand Challenge vehicle.
However, in Mac OS X, Mach is linked with other kernel components into a single kernel address space. This is primarily for performance; it is much faster to make a direct call between linked components than it is to send messages or do remote procedure calls (RPC) between separate tasks.
It had to be done that way because the IPC system Mach bolted onto a BSD kernel is slow. Retrofitting message passing onto a kernel that wasn't designed for it seems to consistently result in a slow message passing system. This is because message passing has to be tightly integrated with CPU dispatching to get really good performance. It's not the data copying that kills you. It's the extra trips through the scheduler.
Mach has simplex ports, like UNIX pipes. Big mistake. To get high performance message passing, you have to make subroutine-call like operations work really efficiently. The basic operations in QNX are MsgSend/MsgRecv/MsgReply, which has the effect of a subroutine call between two processes. Process A does a MsgSend to process B, which is hopefully waiting in a MsgRecv for some work to do. Process A blocks, and process B unblocks. The trick is that when this happens, the normal case, where process B is waiting, is handled by an immediate transfer of control from process A to process B, without a pass through the scheduler to find the next ready to run process. To return, process B does a MsgReply, which immediately unblocks process A.
If you do this with Mach-type simplex ports, where the primitives were ill-chosen, it requires several trips through the scheduler, because the primitives don't lend themselves to simple transfer-control semantics. A does a write, which unblocks B but doesn't block A. So A keeps going. Then A does a read, which blocks A and causes a trip through the scheduler, at which point B is found ready to run and started. The same thing happens in the other direction. Two extra trips through the scheduler.
Worse, if there's another CPU-bound process ready to run, a trip through the scheduler may pick it instead. After all, it's been waiting longer. So each interprocess call results in a chance of losing your current time slice. This adds latency.
This is why message passing and CPU dispatching must be well-integrated, or performance is terrible. All the retrofits of IPC to UNIX type kernels seem to suffer from this problem.
Incidentally, MacOS X is based on Mach 2.x, which is a modified BSD kernel with Mach extensions. Mach 3.x, CMU's rewrite and a true microkernel, never really worked very well. But a few pieces of it made it into MacOS X, which gives Apple some Mach 3 bragging rights. But it's not a microkernel. It's a BSD kernel with extensions.
An XBOX is basically an appliance PC. That's what a sub-$100 PC will look like. There have to be millions of identical ones, with no options, so the manufacturing line just runs and runs.
Microkernel architecture is really hard to get right. If you get it right, microkernels are fast and stable, like VM for IBM mainframes and QNX. Both have long, long uptimes, run important systems, and are modified very seldom.
But most architects don't get it right. If you get it wrong, like Mach, no amount of patching will fix it. Because open source development has a "patch" mentality, it's almost impossible to fix fundamental architectural problems in an open source project.
The HURD people finally dumped Mach and went to L4, which is a half-finished academic microkernel. That's not working either.
I'd like to see a high-security microkernel OS in widespread use, but the HURD guys aren't going to deliver it. And we really need one.
Browsers, as a "platform", suck.
You really don't want browsers downloading and executing code. It's just too insecure. That way lies the hell of Active-X. The great thing about HTML is that it's basically descriptive, not executable. Downloading code in some interpretive language is only slightly less insecure, and much slower. (Or, when there's a page with a dumb ad on screen, CPU usage goes to 100%)
Asking the user for permission to run code doesn't work. Not only will users answer "yes" for hostile code, they'll implicitly agree to EULAs your business's lawyers would never agree to.
Most free "plugins" are in some sense hostile code. They phone home. They look around the host machine. They burn CPU time when not doing anything for the user. Even the "good ones", like Google's toolbar, overreach. Others are much worse.
What we really need are good extensions to HTML for forms. Better validation and help are all things that can be done descriptively, rather than by running executable code on the user's machine. HTML forms are lame; they can't even set up a field that must, say, have five numeric digits and must be filled in. You could do that on IBM green-screen terminals thirty years ago.
It's a historical accident that graphics processors are peripherals, though. Early SGI machines had the 4x4 multiplier as a coprocessor, not tied to the display. Apple's first attempt at 3D acceleration had a 3D coprocessor separate from the display. But because the CPU manufacturers ignored graphics for a long, long time, the 3D market was based on add-ons, and those had to be sold as plug-in boards. Peripheral bandwidth was too low to usefully put a coprocessor on a plug-in board. Hence the "3D graphics board".
I'd much rather get services like that from a legitimate commercial bank than some flakey service like PayPal.
Realistically, you don't want to send money to a "merchant" that can't qualify for a Visa/MC merchant account. I've run mail-order software sales out of my house, and I had a real merchant account from a major bank (not a reseller), a business license, a fictitious name filing, and a Dun and Bradstreet rating. All those things are easy to get. Someone who doesn't have them is probably doing something wrong.
There were some wierd Mac variations in the 1980s with a second CPU on a plug-in board. They could run Photoshop faster, but otherwise were useless.
There are really only two multi-CPU architectures that are generally useful: shared-memory symmetrical multiprocessors, and networked clusters with no shared memory. Many other architectures have been tried - partially shared memory machines, shared-memory machines where some CPUs lacked some features like floating point, hypercubes, single-instruction-multiple-datastream machines, and dataflow processors. None has achieved lasting success.
About the only unusual architecture ever sold in volume is the Playstation 2, with two vector processors. Even there, the vector processors are mostly used as a GPU. (Although one major game physics engine actually runs in the PS2 vector processors, an impressive achievement.)
Programming for wierd architectures is hard, requires much tool development, and results in programs tied to specific hardware. So it doesn't happen much. That's why the wierd architectures fail. They're never that much faster, and by the time the software works, the hardware market is somewhere else.
The Concorde first flew on 2 March 1969.
The last year of SCOX on a log scale is roughly a straight line from $18 down to $3. This seems to reflect roughly the cash SCO has left as they spend money with the lawyers.
Remember, IBM's killer summary judgement motions are still pending. This case could change drastically any day now, and not in SCO's favor.
They're all gone now, the record-holding vehicles of the 1960s. The Concorde, the SR-71, the Saturn V, Alvinn, the Aluminaut. All gone, with the will to replace them gone as well.
Getting to orbit is much harder. But useful.
But that's no longer the case. There are many good off the shelf bases. Cybermotion, iRobot, Arrick, ActiveMedia, Klephera, and Zagros all make wheeled robot bases. Even legged machines are available.
Right now, the big bottleneck is sensing. Visual processing still doesn't work (the hardware is fine, but the theory doesn't work), true 3D laser rangefingers aren't here yet (although I've seen one working on an optical bench) and submillimeter radar hasn't reached production yet (millimeter radar has limited resolution.) Most of the hobbyist world is still using 1980s ultrasonic devices, IR reflectance sensors, and feelers, which don't work any better than they did in the 1980s.
The "expandable airport walkway" is found at smaller airports today. Santa Barbara, California, has several.
Tilting-ramp mousetraps have been around for years and are quite effective.
Retractable parking posts are widely used. Most are solid (there's now a big "security" market for the things) but there are lightweight ones that can be driven over.
Everything else listed has been found by someone else, so I won't rehash that.
Not that Linux is any better. The RPC systems for Linux/UNIX are clunky afterthoughts built on top of sockets.
It might be more worthwhile to work on better relationships between Linux developers and Via. Via sells a large fraction of the motherboard chipsets (if it's not Intel, it's probably Via) and, as a commodity part manufacturer, doesn't have a strong business interest in a proprietary interface.
If Via can be brought on board (assuming it isn't already) that provides more leverage for dealing with other vendors, like nVidia.
I was in favor of more effective ICMP Source Quench. I wanted a Source Quench to cut the size of the TCP congestion window for a while. This worked reasonably well. But back then, we didn't have hostile packet floods to contend with. Today, any congestion control system must be protected against spoofing, or it will become a vehicle for denial of service attacks.
Instead we have Random Early Drop. Congestion notification by packet dropping is like traffic control by randomly kicking cars off the freeway. It has a useful effect on congestion, but it hurts individuals.
The way the Internet really works is that the backbone has far more bandwidth than it really needs, because fibre is cheap and hardware routers are really fast. If the backbone gets congested, the network works very, very badly. (Remember in the mid-1990s, when MAE-WEST would congest and the whole West Coast would see 60% packet loss rates?) We really don't know how to handle mid-network congestion very well. Fortunately, that problem has been eliminated by throwing bandwidth at the problem.
Near the fringes, we have congestion, but the number of different streams going through a choke point like an edge router is small enough that "fair queuing" (or "traffic shaping", in fancier forms) works. This works well with TCP, which throttles down based on round trip time. It prevents sources that don't throttle from hogging all the bandwidth. Usually, there's only one organization on a edge router, so if you want some other policy (like giving priority to video streams) it doesn't affect other users.
Somewhat to my surprise, after twenty years, we have an Internet that works better than I'd expected after huge scaleup. But really, the main reason it works is excess backbone bandwidth.
No, that's not what went wrong. The original version of C (not "K&R", but earlier, as in V6 UNIX circa 1978) didn't have "typedef". That version was LALR(1), and parsable by a simple parser that knew only the reserved words. Wnen "typedef" went in, the grammar became context-dependent - you couldn't parse it without knowing the type names. One undefined typename and the parser gets lost. The syntax went downhill from there.
Pascal doesn't have that problem, because the syntax
is unambiguous. The C formcan't be parsed until you know that "foo" is a type.One implication of the C/C++ parsing problem is that there are few tools that do much with source code. Even a reliable indenter for C++ is hard.
One of the big problems with C++ is that the syntax is so messed up that you can't even express it with a chart like that.
It was basically a new parser for the C compiler. Anything the back end of the C compiler didn't have had to be faked by the front end. Subscript checking was horrendously inefficient, with a subroutine call for every subscript check. Variant records were implemented by allocating separate storage for each variant. It optimized almost nothing. And it was a straight ISO Pascal, with a minimal hack for external compilation.
As a result, a generation of UNIX programmers grew up thinking that Pascal was much less efficient than C.
Ever use a Roomba? It's really dumb, navigates by bumping into things, gets tangled in cords, and doesn't clean very well. I'd expected better from Rod Brooks. Even for a purely reactive robot, it's unusually stupid.
There are better automated vacuums. There was a good one back in the 1980s, from Denning Robotics, but it was a huge riding vacuum for malls and airports. Good technology, but too big. There's a new small robot vacuum that doesn't bump into stuff, but it's priced around $1000. That's the technology to watch.
The original idea was that TCP assumed packet losses were due to transmission errors. Congestion information was supposed to come in via ICMP Source Quench. But the BSD people didn't implement Source Quench, which broke that approach. So TCP had to assume that packet losses meant congestion, and slow down accordingly. That's how we got here.
I've heard that Microsoft made a presentation to some big car company, and insisted that Microsoft had to control the content of the startup screen. The car people did not like that at all.