This is actually two bets, isn't it? One is that I live to be 93. Not terribly likely.

OK, you're on. Not that $10,000 is likely to be worth as much in 2050.

Let's make a bet then. You pay me $1 if there is no credible commercially utilized cold fusion by 2024. I'll pay you $10,000 if there is. And please don't bother me until then.

Let me preface this with the fact that I'm an intellectual property specialist. I bill $450/hour, and still have lots of time to work on my startup without having to take venture capital.

I thought about some educational answers for your questions, but the insult at the start of your comment rubs me wrong and I decided I don't owe you anything. So, I'll save them.

The first symptom of a new but incomplete understanding of patents is gold fever. That is when you have an idea that what you are holding is extremely valuable and that you must protect it from others at all costs. People tend to get irrational about it.

So here is some reality: The fact that you have even published your video (which is "use in commerce" under patent law) invalidates future patents that you might file on that same art. Then there is the prior art (including art you are not aware of), and the recent court finding in Alice v. CLS Bank that invalidates most process and method patents which describe software. These all work against the potential that your thesis is going to make you rich through patent licensing.

You can get a patent awarded, perhaps, that you can use to hoodwink an investor, but forcing an automotive company to pay you? Much less likely and it will cost $10 Million in attorney fees to get there.

Probably your school wants 51% of the revenue and your grant funding sources (and those of your college department) may have their own policies on patents.

Yes, this is definitely a "WTF?" moment in the history of Slashdot. I suggest that you all just move on to the next story and refuse to feed the troll by asking him questions.

Slashdot, obviously, has to innovate in order to stay current. Thus, they are now taking the next step after "Anonymous Cowards". The new "Identified Troll" feature will include interviews of people who have prostituted their personal credibility to some company's calculated disinformation campaign.

Google filters out ~100-200 spams a day from my email box (which I universally forward all my domain mail through) and leaves me with (usually) only one or two that I have to specifically mark as spam. I've never been able to do better running my own spam filter.

-Matt

https://www.youtube.com/watch?... should help explain it to you.

For mobile internet connections... for dual mobile internet connections. I haven't done that but I have used VPNs over mobile hotspots extensively. There is just no way to get low latency even over multiple mobile links. The main problem is that the bandwidth capabilities of the links are fluctuating all of the time, and if you try to dup the packets you will end up overloading one or the other link randomly as time progresses because the TCP protocol will get acks from the other link and thus not backoff as much as it should. An overloaded mobile link will drop out, POOF. Dead for a while.

For VPN over mobile links, the key is to NOT run the VPN on the mobile devices themselves. Instead, run it on a computer (laptop etc) that is connected to the mobile devices. Then use a standard link aggregation protocol with a ~1 second ping and a ~10 second timeout. You will not necessarily get better latency but it should solve the dropout problem... it will glitch for a few seconds when it fails over but the tcp connections will not be lost.

-Matt

I run a dual VPN link over two telcos (Comcast and U-Verse in my case), between my home and a colo. I don't try to repeat the traffic on both links, however, because they have different bandwidth capabilities and it just doesn't work well if the line becomes saturated. Instead I use PF and FAIRQ in both directions to remove packet backlogs at border routers in both directions, and to ensure that priority traffic gets priority. Either an aggregation-with-failover or a straight failover configuration works the best (the TCP connection isn't lost since it's a VPN'd IP). That way if you lose one link, the other will take over within a few seconds.

The most important feature of using a VPN to a nearby colo is being able to prioritize and control the bandwidth in BOTH directions. Typically you want to reserve at least 10% for pure TCP acks in the reverse direction, and explicitly limit the bandwidth to just below the telco's capabilities to avoid backlogging packets on either your outgoing cablemodem/u-verse/etc router or on the telco's incoming router (which you have no control over without a VPN). Then use fair queueing or some other mechanism to ensure that bulk connections (such as streaming movies) do not interfere with the latency for other connections.

In anycase, what you want to do just won't work in real life when you are talking about two different telco links. I've tried it with TCP (just dup'ing the traffic). It doesn't improve anything. The reason is that one of the two is going to have far superior latency over the other. If you are talking Comcast cable vs U-Verse, for example (which, the comcast cable will almost certainly have half the latency of the U-Verse. If you are talking about Comcast vs Verizon FIOS, then it is a toss-up. But one will win, and not just some of the time... 95% of the time. So you might as well route your game traffic over the one that wins.

-Matt

Actually, I know of some people who have built their own network appliances to perform this task. It's feasible and can work but requires encapsulate and decapsulation on each end. You can MSS clamp for TCP and timestamp/reassemble the UDP frames. Not impossible, but certainly requires effort. The people I know who did this was for redundancy between DSL + Business DOCSIS services so they would get the fastest performance of each direction from their links with redundancy should one fail.

It's that simple. Even with the patches, bash is still running the contents of environment variables through its general command parser in order to parse the procedure. That's ridiculously dangerous... the command parser was never designed to be secure in that fashion. The parsing of env variables through the command parser to pass sh procedures OR FOR ANY OTHER REASON should be removed from bash outright. Period. End of story. Light a fire under the authors someone. It was stupid to use env variables for exec-crossing parameters in the first place. No other shell does it that I know of.

This is a major attack vector against linux. BSD systems tend to use bash only as an add-on, but even BSD systems could wind up being vulnerable due to third party internet-facing utilities / packages which hard-code the use of bash.

-Matt