In the early days of the Internet (by which I mean 1981-1983, not 1997) there were ICMP Source Quench messages. This provided a way for routers to say to an end node "Slow Down." Back when I was working on congestion control, I had our TCP implementation (a modified 3COM UNET; this was before Berkeley got into TCP) set to cut down the size of the congestion window when a Source Quench was received. I took the position that Source Quench messages should be sent before the packet-drop point was reached, so that a well-behaved TCP should never have a packet dropped for congestion reasons.
This didn't catch on, though. There was concern that sending Source Quench messages would choke the network, since as the network congests, routers need to send more Source Quench messages. That sort of behavior creates an unstable condition. And coming up with a generally applicable Source Quench policy was hard. Eventually, ICMP Source Quench was deprecated.
Without Source Quench, there's not much a router can say to an end node about congestion. A router can still send ICMP Destination Unreachable messages, though. What Comcast ought to be doing if they want to reject a connection is to send back ICMP Destination Unreachable, Code 13 (communication administratively prohibited). That's a legitimate action by a router, and it makes it clear who's complaining. Some firewalls will send such messages, so they're not unheard of; however, some NAT boxes don't translate them properly, so they may not reach home clients.
But faking a TCP RST, or worse, sending an ACK for something that didn't reply at all, is just wrong.
So far, Google has been in only minor trouble with the "Homeland Security" goons.
Of course, Google StreetView has no Washington, D.C. area coverage. They're being cautious about that. Full coverage of Manhattan, though.
Coverage of my old house near Palo Alto is so good that you can read the license plates of
the cars in the driveway. You can even see me through a window, but it's just a faint
outline because their images don't have enough dynamic range to look inside a dark room
from a sunny street.
It's different this time.
Performance increases in PCs have slowed down. Until now, hardware was keeping ahead of bloatware. Not this time. Vista is a price/performance lose for corporate buyers. If Microsoft pushes too hard here, big customers will stop buying new machines until the recession is over. Or move to the new "low end PCs", which still run XP and are enough for 80-90% of corporate users. Watch for a boom in low-cost XP Flash-based desktops aimed at the corporate market.
Instead, it was always meant to monitor users (and more importantly, user aggregates) and determine what kind of traffic they were sending.
Yeah, right. If you want aggregate information for traffic management purposes, you randomly sample one in every 100,000 packets or so and analyze those. Anybody who says they need detailed per-user data for network provisioning is lying.
NebuAd products do collect and use the following kinds of anonymous information:
Web pages viewed and links clicked on
Web search terms
The amount of time spent at some Web sites
Response to advertisements
System settings, such as the browser used and speed of the connection
ZIP code or postal code
Now that's way out of line for an ISP to collect, let alone send to an ad agency.
We may be able to do something about this.
We run SiteTruth AdRater, which rates advertisers. We have a Firefox extension which displays a rating icon for each ad served.
When an ad link goes by, and it's not in the browser cache, the extension contacts our server for a rating of the advertiser. So we collect, over time, a list of advertisers for various ad systems. We're not collecting data about users; we're interested in advertiser behavior.
(You can read the source code for the plug-in, so there's no mystery about what we're doing.)
We're not currently tracking NebuAd, Front Porch, or Phorm ads; we've been focusing on the bigger players. It looks like we need to be tracking this behavior. If anyone can find ad links from those services, please post the ad link here, or mail it to "info@sitetruth.com". We need some examples so we can modify the plug-in to recognize them.
If we can collect sufficient information about this class of advertisers, we may publish their customer list, which would be useful for boycott purposes. Thanks.
BGP and the intra-domain routing protocols assume there is at most one correct route from a given source address to a given destination address.
Interestingly, the original ARPANET didn't make that assumption and would load-share across links.
The ARPANET was a denser mesh than the Internet today, but with much lower bandwidth links, only 56Kb/s.
Incidentally, the original MILNET, which was a purely military network using ARPANET nodes, was about six-connected; that is, each node had connections to about six other nodes. They wanted that thing to stay up no matter what.
The lappy makers may not be either. Palm could have done exactly that, but kept pursuing more expensive offerings.
Others, however, did produce low priced Palm Pilot clones. You'll find them in the pencil and calculator section. Or, in some case, the toy department; remember the 1999 Hasbro "Clueless Organizer".
TCP is mostly controlled by round trip time measurement and window size. Response to packet loss is a backup mechanism. If packet loss were the primary control mechanism, TCP would never work.
It's much better to throttle back before packet loss occurs, since any lost packet has to be resent and uses up resources from the sender to the drop point. Since the main bandwidth bottleneck is at the last mile to the consumer, the drop point tends to be close to the destination.
Don't trust the "Clean Slate Internet" project too much. That started as telco-supported scheme to move more functionality to the telcos so they can add charges for specific services, like cell phone providers.
From the article:
On traditional hard drives, the more separate files which the operating system has to load, the more seeking across the hard drive is required, and therefore overall performance takes a hit.... In Windows 7, Microsoft will break from the Windows' norm by breaking previous API compatibility, offering new API frameworks as a native solution, and providing support for legacy frameworks (COM, ATL,.NET Framework, etc) through monolithic libraries designed to provide the functionality of all previous revisions of the modules in question.
And so, the answer is to put everything in one bloated DLL?
It apparently hasn't yet penetrated to the Windows 7 group that computers aren't going to get much more powerful for years to come. That stopped once laptops started outselling desktops. In laptops, what matters is size, weight, and battery life. The future is the OLPC and the Asus Eee. In a few years, laptops in bubble-packs for $89.95 will be hanging on racks at the drugstore. Microsoft isn't ready for that.
Progress now will come from reducing software bloat. Microsoft has, in desperation, extended the life of Windows XP for little machines. That's only a stopgap measure. Now they need to de-bloat their whole product line and get their costs down.
They had to wait until the US was losing in Iraq
on
New Dune Movie Confirmed
·
· Score: -1, Flamebait
Dune's notion of desert warfare looked silly after Desert Storm.
But now that the ragheads are winning, a sequel might sell. The Iraqui insurgents have figured out a doctrine that works against armor. That's new.
Why is Brookhaven National Labs working on this? That's a tax-funded national lab. If they have people and resources to compete with Hollywood, they need a budget cut.
Commercial web hosting is so cheap that there's no reason to do it on a home machine. Don't get it from your ISP; there are hundreds of competing web hosting companies. You can get quite decent capabilities for under $10/month.
The real money was made back in the 1960s, when the theoreticians figured out that blackjack was beatable but the gambling industry didn't know that yet.
Lately, I seem to see "podcasting" used as simply a name for MPEG 4 video files. That's useful, because it promotes a standardized format, instead of yet another proprietary Microsoft codec with DRM features that phone home.
TrustE is more of an apologist than a regulator. TrustE stopped being serious about privacy in 1997, when they "simplified" their seal program. A TrustE seal doesn't mean that any standard has been met. All it means now is that the company claims to comply with their own privacy statement, whatever it says. That's it.
The way to get this changed would be to put a roadside detector near some Washington freeway, near a programmable billboard. Make a deal with the billboard operator to buy time on demand, and, when a known car goes by, put up "Good Morning, Senator Smith".
Furthermore, the general case of recognizing cycles is an unsolvable problem, thanks to the halting problem. If it was a solvable problem, it would have already been solved at run-time.
No. Recognizing cycles is not unsolveable. It's not even hard. See this introduction to graph algorithms. See section 1.4: "In order to detect cycles, we use a modified depth first search called a colored DFS. All nodes are initially
marked white. When a node is encountered, it is marked grey, and when its descendants are completely
visited, it is marked black. If a grey node is ever encountered, then there is a cycle."
6-bit colors? In 2008? What were they thinking? The trend is towards 10 bits. At 6 bits, gradients look awful; false edges appear. Go into Photoshop, generate a single color gradient, and then "posterize" to 64 colors to see what this looks like. Yuck.
Dithering won't help; it puts noise into a nice, smooth gradient.
Very nice. One photon, emitted in a useful direction, no less. Unfortunately, the current approach has to be done at liquid helium temperatures, but maybe someone will make progress
on that.
Reading stuff like this makes one realize how good we're getting at quantum mechanics. It's not just statistical any more.
This thing is a one-pixel display being scanned in 2D by a MEMS mirror. One pixel scanned displays have been tried before, and they're usually annoying. One of the neat things about LCD displays, plasma panels, and TI DLP mirror systems is that there's no flicker at all, because the display has full persistence. This brings back flicker, big time; all the persistence is in the eye. This idea has been tried before, in bigger displays, and abandoned. So this isn't going to look great, but it will have niche uses.
>It introduces a sort of concurrency into otherwise sequential programs, leading to timing jitter (at least), stalls (maybe), and nonrepeatable bugs.
Not at all. IBM even has a real time Java (hard real time).
That's WebSphere Real Time Java, a research effort from IBM. You can order it (with mandatory and expensive technical support), but it's more of a semi-custom product. They had to make some drastic compromises to get that to work. Arrays are split into "arraylets", so that no one chunk is so big that it can't be moved during the garbage collection freeze. This allows them to get the freeze time down below a millisecond. There are still freezes, but they're shorter.
>Garbage collection and destructors do not play well together. See "Managed C++".
No, that's not true either. C++ has RAII, so the point is not valid.
That's the problem. Resource Allocation as Initialization and garbage collection do not play well together. Do you want to wait until the next GC before a window closes?
> Concurrent garbage collection requires some support from the memory management unit and operating system, so the hardware can detect "dirty pages"
No, it does not. All that's required is CAS operations.
If you want to avoid freezes during garbage collection, you need more than that. IBM's concurrent collector for Java still has brief freezes for the "mark" phase. Microsoft's patented approach (U.S. Patent #6,502,111) has a freeze: "The application is paused after the marking act is complete. Next, a second marking act of marking all reachable memory objects...". Boehm's collector is "mostly concurrent", and requires "the write protect facilities that are now widely available". The general idea is to write protect pages while the program is running, then run the marking phase of garbage collection on them. If the running program writes to a write-protected page, the page is unlocked and the write performed, but the garbage collector has to do that page again.
Page level write protection/dirty page bit hardware, or periodic freezes. Pick one.
> Calling destructors from another thread in the garbage collector can introduce race conditions or deadlocks.
It depends on what your destructor is doing.
And that's the problem. There are some subtle no-nos in destructors called from garbage collectors. C++ doesn't prevent them. Errors here result in very intermittent bugs that are very hard to find.
Garbage collection is fine for programs at a somewhat higher level, like Java, but you probably don't want it inside your operating system kernel or media player.
You mix two totally unrelated domains. A OS kernel can have GC, but usually it is too low level to have one. On the other hand, a media player can have GC, since a media player does not constantly allocate and deallocate memory blocks.
In Java, programmers worry about garbage collection and finalizers.
Don't underestimate the power of cycles! cycles can be introduced indirectly, through inheritance, and then it's very very difficult to track them...trust me, I've been hunting a memory leak introduced by a subclass which obtained a shared ptr from a factory interface, only to discover that the the base class was already already referenced somewhere from the object returned by the factory; the cycle was not obvious, until the program accumulated lots of craft after a long operation.
I'm arguing for a debug mode in which cycles are detected at the moment of creation.
Cycles are typically a design time problem; if a program generates cycles, it will probably generate cycles on every execution. This tells you when you need weak pointers.
If your data structure is anything like a tree, the cycle problem can usually be fixed
Google sells an enterprise search appliance. It's not cheap.
"Starts at $30,000 for searching up to 500,000 documents", for a 2U server. That's probably what this is about.
auto_ptr is on, what, standardization try #4? It sucks less, but it's still not airtight.
The fact that you can't make it airtight indicates some of the fundamental problems in C++.
Garbage collection isn't a panacea, though. It introduces a sort of concurrency into otherwise sequential programs, leading to timing jitter (at least), stalls (maybe), and nonrepeatable bugs. Garbage collection and destructors do not play well together. See
"Managed C++". Concurrent garbage collection requires some support from the memory management unit and operating system, so the hardware can detect "dirty pages". Not all target machines have that hardware; most handheld devices don't, for example. Calling destructors from another thread in the garbage collector can introduce race conditions or deadlocks. Conservative garbage collection can result in memory leaks, and offers a new avenue for denial of service attacks if someone can send you buffers full of carefully constructed junk.
Garbage collection is fine for programs at a somewhat higher level, like Java, but you probably don't want it inside your operating system kernel or media player.
There's something to be said for reference counts. In C and C++, memory management gets much attention. In Java, programmers worry about garbage collection and finalizers. But in Perl and Python, which are reference counted, programmers seem to mostly ignore
memory management without problems. With reference counts, destruction is deterministic.
Reference counts have three problems - keeping them correct (C++ reference count template packages tend to leak raw pointers, leading to bugs), updating cost (many reference count updates could be hoisted out of loops if the compiler understood reference counts, but few implementations of any language do that), and cycles. The answer to cycles may be to provide weak pointers, then simply prohibit cycles, with a debug tool to catch them. If you need some complex structure with heavy interlinking, like a window manager, make all the window objects owned by some collection, then make all the inter-widget links weak.
The "move semantics" mess arises from the fact that parameter passing in C++ is an assignment, invoking the "=" operator. This leads to a temptation to redefine the "=" operator. If you have reference counts, though, you don't have this problem.
Slashdot Mirror
In the early days of the Internet (by which I mean 1981-1983, not 1997) there were ICMP Source Quench messages. This provided a way for routers to say to an end node "Slow Down." Back when I was working on congestion control, I had our TCP implementation (a modified 3COM UNET; this was before Berkeley got into TCP) set to cut down the size of the congestion window when a Source Quench was received. I took the position that Source Quench messages should be sent before the packet-drop point was reached, so that a well-behaved TCP should never have a packet dropped for congestion reasons.
This didn't catch on, though. There was concern that sending Source Quench messages would choke the network, since as the network congests, routers need to send more Source Quench messages. That sort of behavior creates an unstable condition. And coming up with a generally applicable Source Quench policy was hard. Eventually, ICMP Source Quench was deprecated.
Without Source Quench, there's not much a router can say to an end node about congestion. A router can still send ICMP Destination Unreachable messages, though. What Comcast ought to be doing if they want to reject a connection is to send back ICMP Destination Unreachable, Code 13 (communication administratively prohibited). That's a legitimate action by a router, and it makes it clear who's complaining. Some firewalls will send such messages, so they're not unheard of; however, some NAT boxes don't translate them properly, so they may not reach home clients.
But faking a TCP RST, or worse, sending an ACK for something that didn't reply at all, is just wrong.
So far, Google has been in only minor trouble with the "Homeland Security" goons. Of course, Google StreetView has no Washington, D.C. area coverage. They're being cautious about that. Full coverage of Manhattan, though.
Coverage of my old house near Palo Alto is so good that you can read the license plates of the cars in the driveway. You can even see me through a window, but it's just a faint outline because their images don't have enough dynamic range to look inside a dark room from a sunny street.
Nah. Microsoft will extend XP's life again.
It's different this time. Performance increases in PCs have slowed down. Until now, hardware was keeping ahead of bloatware. Not this time. Vista is a price/performance lose for corporate buyers. If Microsoft pushes too hard here, big customers will stop buying new machines until the recession is over. Or move to the new "low end PCs", which still run XP and are enough for 80-90% of corporate users. Watch for a boom in low-cost XP Flash-based desktops aimed at the corporate market.
NYC and Company(tm), Inc., the marketing arm of NYC(tm) has been very aggressive in trademarking. Just ask the locals. (tm).
Apple isn't going to win this one.
Instead, it was always meant to monitor users (and more importantly, user aggregates) and determine what kind of traffic they were sending.
Yeah, right. If you want aggregate information for traffic management purposes, you randomly sample one in every 100,000 packets or so and analyze those. Anybody who says they need detailed per-user data for network provisioning is lying.
I just checked NebuAd's Privacy policy:
NebuAd products do collect and use the following kinds of anonymous information:
Now that's way out of line for an ISP to collect, let alone send to an ad agency.
We may be able to do something about this.
We run SiteTruth AdRater, which rates advertisers. We have a Firefox extension which displays a rating icon for each ad served. When an ad link goes by, and it's not in the browser cache, the extension contacts our server for a rating of the advertiser. So we collect, over time, a list of advertisers for various ad systems. We're not collecting data about users; we're interested in advertiser behavior. (You can read the source code for the plug-in, so there's no mystery about what we're doing.)
We're not currently tracking NebuAd, Front Porch, or Phorm ads; we've been focusing on the bigger players. It looks like we need to be tracking this behavior. If anyone can find ad links from those services, please post the ad link here, or mail it to "info@sitetruth.com". We need some examples so we can modify the plug-in to recognize them.
If we can collect sufficient information about this class of advertisers, we may publish their customer list, which would be useful for boycott purposes. Thanks.
BGP and the intra-domain routing protocols assume there is at most one correct route from a given source address to a given destination address.
Interestingly, the original ARPANET didn't make that assumption and would load-share across links. The ARPANET was a denser mesh than the Internet today, but with much lower bandwidth links, only 56Kb/s.
Incidentally, the original MILNET, which was a purely military network using ARPANET nodes, was about six-connected; that is, each node had connections to about six other nodes. They wanted that thing to stay up no matter what.
The lappy makers may not be either. Palm could have done exactly that, but kept pursuing more expensive offerings.
Others, however, did produce low priced Palm Pilot clones. You'll find them in the pencil and calculator section. Or, in some case, the toy department; remember the 1999 Hasbro "Clueless Organizer".
TCP is mostly controlled by round trip time measurement and window size. Response to packet loss is a backup mechanism. If packet loss were the primary control mechanism, TCP would never work.
It's much better to throttle back before packet loss occurs, since any lost packet has to be resent and uses up resources from the sender to the drop point. Since the main bandwidth bottleneck is at the last mile to the consumer, the drop point tends to be close to the destination.
Don't trust the "Clean Slate Internet" project too much. That started as telco-supported scheme to move more functionality to the telcos so they can add charges for specific services, like cell phone providers.
From the article: On traditional hard drives, the more separate files which the operating system has to load, the more seeking across the hard drive is required, and therefore overall performance takes a hit. ... In Windows 7, Microsoft will break from the Windows' norm by breaking previous API compatibility, offering new API frameworks as a native solution, and providing support for legacy frameworks (COM, ATL, .NET Framework, etc) through monolithic libraries designed to provide the functionality of all previous revisions of the modules in question.
And so, the answer is to put everything in one bloated DLL?
It apparently hasn't yet penetrated to the Windows 7 group that computers aren't going to get much more powerful for years to come. That stopped once laptops started outselling desktops. In laptops, what matters is size, weight, and battery life. The future is the OLPC and the Asus Eee. In a few years, laptops in bubble-packs for $89.95 will be hanging on racks at the drugstore. Microsoft isn't ready for that.
Progress now will come from reducing software bloat. Microsoft has, in desperation, extended the life of Windows XP for little machines. That's only a stopgap measure. Now they need to de-bloat their whole product line and get their costs down.
Dune's notion of desert warfare looked silly after Desert Storm. But now that the ragheads are winning, a sequel might sell. The Iraqui insurgents have figured out a doctrine that works against armor. That's new.
Why is Brookhaven National Labs working on this? That's a tax-funded national lab. If they have people and resources to compete with Hollywood, they need a budget cut.
If the goal is to make it different every time it's played, it's music.
So if you feed the MIDI track into a drum machine with drum hit randomization, it's music?
Commercial web hosting is so cheap that there's no reason to do it on a home machine. Don't get it from your ISP; there are hundreds of competing web hosting companies. You can get quite decent capabilities for under $10/month.
The real money was made back in the 1960s, when the theoreticians figured out that blackjack was beatable but the gambling industry didn't know that yet.
Lately, I seem to see "podcasting" used as simply a name for MPEG 4 video files. That's useful, because it promotes a standardized format, instead of yet another proprietary Microsoft codec with DRM features that phone home.
TrustE is more of an apologist than a regulator. TrustE stopped being serious about privacy in 1997, when they "simplified" their seal program. A TrustE seal doesn't mean that any standard has been met. All it means now is that the company claims to comply with their own privacy statement, whatever it says. That's it.
Even worse, a site with a TrustE seal is more likely to have badware than one without a seal.
TrustE has revoked only two certificates in its ten year history.
The way to get this changed would be to put a roadside detector near some Washington freeway, near a programmable billboard. Make a deal with the billboard operator to buy time on demand, and, when a known car goes by, put up "Good Morning, Senator Smith".
Furthermore, the general case of recognizing cycles is an unsolvable problem, thanks to the halting problem. If it was a solvable problem, it would have already been solved at run-time.
No. Recognizing cycles is not unsolveable. It's not even hard. See this introduction to graph algorithms. See section 1.4: "In order to detect cycles, we use a modified depth first search called a colored DFS. All nodes are initially marked white. When a node is encountered, it is marked grey, and when its descendants are completely visited, it is marked black. If a grey node is ever encountered, then there is a cycle."
6-bit colors? In 2008? What were they thinking? The trend is towards 10 bits. At 6 bits, gradients look awful; false edges appear. Go into Photoshop, generate a single color gradient, and then "posterize" to 64 colors to see what this looks like. Yuck.
Dithering won't help; it puts noise into a nice, smooth gradient.
Very nice. One photon, emitted in a useful direction, no less. Unfortunately, the current approach has to be done at liquid helium temperatures, but maybe someone will make progress on that.
Reading stuff like this makes one realize how good we're getting at quantum mechanics. It's not just statistical any more.
Here's the company site. No mention of battery life issues.
This thing is a one-pixel display being scanned in 2D by a MEMS mirror. One pixel scanned displays have been tried before, and they're usually annoying. One of the neat things about LCD displays, plasma panels, and TI DLP mirror systems is that there's no flicker at all, because the display has full persistence. This brings back flicker, big time; all the persistence is in the eye. This idea has been tried before, in bigger displays, and abandoned. So this isn't going to look great, but it will have niche uses.
Brightness is 10 lumens, incidentally.
>It introduces a sort of concurrency into otherwise sequential programs, leading to timing jitter (at least), stalls (maybe), and nonrepeatable bugs.
Not at all. IBM even has a real time Java (hard real time).
That's WebSphere Real Time Java, a research effort from IBM. You can order it (with mandatory and expensive technical support), but it's more of a semi-custom product. They had to make some drastic compromises to get that to work. Arrays are split into "arraylets", so that no one chunk is so big that it can't be moved during the garbage collection freeze. This allows them to get the freeze time down below a millisecond. There are still freezes, but they're shorter.
>Garbage collection and destructors do not play well together. See "Managed C++".
No, that's not true either. C++ has RAII, so the point is not valid.
That's the problem. Resource Allocation as Initialization and garbage collection do not play well together. Do you want to wait until the next GC before a window closes?
> Concurrent garbage collection requires some support from the memory management unit and operating system, so the hardware can detect "dirty pages"
No, it does not. All that's required is CAS operations.
If you want to avoid freezes during garbage collection, you need more than that. IBM's concurrent collector for Java still has brief freezes for the "mark" phase. Microsoft's patented approach (U.S. Patent #6,502,111) has a freeze: "The application is paused after the marking act is complete. Next, a second marking act of marking all reachable memory objects...". Boehm's collector is "mostly concurrent", and requires "the write protect facilities that are now widely available". The general idea is to write protect pages while the program is running, then run the marking phase of garbage collection on them. If the running program writes to a write-protected page, the page is unlocked and the write performed, but the garbage collector has to do that page again.
Page level write protection/dirty page bit hardware, or periodic freezes. Pick one.
> Calling destructors from another thread in the garbage collector can introduce race conditions or deadlocks.
It depends on what your destructor is doing.
And that's the problem. There are some subtle no-nos in destructors called from garbage collectors. C++ doesn't prevent them. Errors here result in very intermittent bugs that are very hard to find. Garbage collection is fine for programs at a somewhat higher level, like Java, but you probably don't want it inside your operating system kernel or media player. You mix two totally unrelated domains. A OS kernel can have GC, but usually it is too low level to have one. On the other hand, a media player can have GC, since a media player does not constantly allocate and deallocate memory blocks. In Java, programmers worry about garbage collection and finalizers.
Don't underestimate the power of cycles! cycles can be introduced indirectly, through inheritance, and then it's very very difficult to track them...trust me, I've been hunting a memory leak introduced by a subclass which obtained a shared ptr from a factory interface, only to discover that the the base class was already already referenced somewhere from the object returned by the factory; the cycle was not obvious, until the program accumulated lots of craft after a long operation.
I'm arguing for a debug mode in which cycles are detected at the moment of creation. Cycles are typically a design time problem; if a program generates cycles, it will probably generate cycles on every execution. This tells you when you need weak pointers.
If your data structure is anything like a tree, the cycle problem can usually be fixed
Google sells an enterprise search appliance. It's not cheap. "Starts at $30,000 for searching up to 500,000 documents", for a 2U server. That's probably what this is about.
Their latest monstrosity is move semantics,
auto_ptr is on, what, standardization try #4? It sucks less, but it's still not airtight. The fact that you can't make it airtight indicates some of the fundamental problems in C++.
Garbage collection isn't a panacea, though. It introduces a sort of concurrency into otherwise sequential programs, leading to timing jitter (at least), stalls (maybe), and nonrepeatable bugs. Garbage collection and destructors do not play well together. See "Managed C++". Concurrent garbage collection requires some support from the memory management unit and operating system, so the hardware can detect "dirty pages". Not all target machines have that hardware; most handheld devices don't, for example. Calling destructors from another thread in the garbage collector can introduce race conditions or deadlocks. Conservative garbage collection can result in memory leaks, and offers a new avenue for denial of service attacks if someone can send you buffers full of carefully constructed junk.
Garbage collection is fine for programs at a somewhat higher level, like Java, but you probably don't want it inside your operating system kernel or media player.
There's something to be said for reference counts. In C and C++, memory management gets much attention. In Java, programmers worry about garbage collection and finalizers. But in Perl and Python, which are reference counted, programmers seem to mostly ignore memory management without problems. With reference counts, destruction is deterministic. Reference counts have three problems - keeping them correct (C++ reference count template packages tend to leak raw pointers, leading to bugs), updating cost (many reference count updates could be hoisted out of loops if the compiler understood reference counts, but few implementations of any language do that), and cycles. The answer to cycles may be to provide weak pointers, then simply prohibit cycles, with a debug tool to catch them. If you need some complex structure with heavy interlinking, like a window manager, make all the window objects owned by some collection, then make all the inter-widget links weak.
The "move semantics" mess arises from the fact that parameter passing in C++ is an assignment, invoking the "=" operator. This leads to a temptation to redefine the "=" operator. If you have reference counts, though, you don't have this problem.