Follow Slashdot blog updates by subscribing to our blog RSS feed

 



Forgot your password?
typodupeerror
×

Comment Re:Fermi Paradox (Score 1) 103

Is this why we don't see aliens? They destroy themselves by trying to discover the universe's secrets?

We're unwilling to spend a tiny fraction of GDP on discovering more about particle physics. The aliens are probably unwilling to spend 25% of GDP on a 50-year unmanned (unaliened?) mission to fly by their nearest star at high speed, let alone a thousand year mission to distant Sol.

Comment Re:An old concern (Score 1) 148

The sole reason they use fresh water and not connect the two salt water bodies is exactly because of the environmentalists of the early 20th century.

Is this correct? The French started building a sea level canal in 1881 and went bankrupt in 1889. Then the Comité Technique of the successor Compagnie Nouvelle came up with a plan with eight sets of locks and two high level lakes in 1898. However, in 1906 a US engineering panel recommended a sea level canal. To quote wikipedia:

But in 1906 Stevens, who had seen the Chagres in full flood, was summoned to Washington; he declared a sea-level approach to be "an entirely untenable proposition". He argued in favor of a canal using a lock system to raise and lower ships from a large reservoir 85 ft (26 m) above sea level. This would create both the largest dam (Gatun Dam) and the largest human-made lake (Gatun Lake) in the world at that time.

The factors at play appear to be excavation costs and the seasonal flooding of the Chagres river, which the lake plan works around.

Comment Re:Any day now! (Score 1) 320

That is a bit rich, coming from the person who wrote "lazy brain", "blow smoke", "IPv6 cultists", "Bunch of wankers telling each other what geniuses they are", "arrogant asses", and more. How high or low is the bar for being an ass? I've been unfailingly polite to you and you have just come back with abuse.

Beyond your 30,000ft generalizations the only suggestion connecting these "USBs" together without upgrading everything is a horrible kludge that I re-invented.

Comment Re:Any day now! (Score 1) 320

The wifi router sends 32-bit packets to www.OldCo.com.au on 4.3.2.1 and 64-bit packets to www.NewCo.co.uk on 8.7.6.5.4.3.2.1, That sounds like it is running dual stack, where the protocol used depends on the capabilities of the destination. Just like my wifi router sending IPv6 to comcast.net and IPv4 to slashdot.org.

Comment Re:Any day now! (Score 1) 320

I think there is a way to make this work using DNS. If there is, say, an "AA" record for the extended address then the NAT box intercepts the DNS query from the 32-bit end system and makes sure it translates future traffic to that address.

Extended world: www.NewCo.com has AA record 1.2.3.4.5.6.7.8 and no A record (otherwise they are effectively running dual stack)

32-bit router asks for DNS of www.NewCo.com

NAT box intercepts reply and sends a bogus "A" record back to 32-bit system - something like 10.0.0.5 (need a lot of numbers to track 64-bit destinations separately)

32-bit system sends 32-bit (conventional IPv4) packets to 10.0.0.5

NAT box does its NAT stuff and sends 64-bit address packets to www.newco.com, with reverse translation on the way back.

Comment Re:Any day now! (Score 1) 320

Extend the system that works, like AMD did to get from 32 to 64 bit processors.

That's a great example of why networking changes like this are difficult:

64-bit processor: Engineer it so that 32-bit instructions can be run painlessly.

32-bit processor: Carries on doing what it is doing. Nobody expects it to run 64-bit instructions.

Send packet from 64-bit IP address to 32-bit IP address: Relatively simple by carving out a /32 in the 64-bit protocol (or /96 in IPv6, which has been done a couple of times).

Send packet from 32-bit IP address to 64-bit IP address: Not at all easy. Possible solutions are a transition period with big restrictions on the 64-bit side, or translation boxes in the middle of the network where the protocols meet (which in turn will be shifting as carriers upgrade). These need a level of Internet governance that we don't currently have.

Comment Re:Any day now! (Score 1) 320

Backwards compatibility is difficult. A 32-bit IPv4 end system can reach 2^32 destinations. Those destinations must be shared between unmodified IPv4 end systems and the new expandable IPv4 stack. This makes having an expandable stack of questionable value until a big fraction of end systems have converted. So the success of the program depends on persuading businesses who have enough addresses to convert their end systems to the new system, even if it doesn't give them any short term gain. As well as the end systems, every backbone router on the internet between them needs to understand the extended protocol with bigger addresses. The global IPv4 BGP table needs to be extended. But that takes some serious consideration if backwards compatibility is a requirement. There will be routers with the current 32-bit routing table, and they will get a fraction of the new table with the 64-bit (or whatever) addresses excluded. Likewise DNS will need some kind of old/new distinction, and the old unmodified DNS servers have to be kept in the loop. Businesses, who have a system that is perfectly working already, have to convert their back office systems relating to IP address allocation, their DNS, their end systems, their routers, etc..

This sounds like the problems of IPv6, where progress depends on a lot of people with no particular motivation, as they already have enough addresses. But it also introduces an interesting wrinkle, which is that the new systems must fully interoperate with the old unmodified systems. There's an assumption that you can't rely on _everybody_ to move to the new system, so every single change you make to the new system has to work nicely with the installed base. That is quite different from dual stack, where the new system only has to interwork with itself.

The slow rollout of IPv6 demonstrates that _any_ new system has a hard time being established when most of the current base have no financial interest in converting. 32-bit/64-bit IPv4 (or whatever) has that obstacle _plus_ any exciting interworking issues breaking the 32-bit network.

Comment Re:Any day now! (Score 4, Interesting) 320

Slightly longer than that, as IPv6 RFCs came out in 1995-1998. But the address space advantage of IPv6 only kicked in in the early 2010s when it became much more expensive to obtain IPv4 address space. In 2011 Microsoft piad Nortel $7.5m for IPv4 address space ($11.25 per address). It was only a matter of time before that sort of cost got passed on to customers by companies like AWS.

Comment Re:10% c not 20% (Score 1) 113

Yes, I did miss the point you were making. From this article it looks like 10 minutes of acceleration to get to 0.2c, which I think is an acceleration of 17000g. I have no idea if this is feasible. It should be possible to reach high speeds with gentler acceleration, though. For example, 120 days at 1g should achieve the same speed as 10min at 17000g.

Comment Re:10% c not 20% (Score 1) 113

Electrons travel at ~ .1c I'm highly doubtful that we can accelerate whole molecules faster than that.

Electrons can go a lot faster than that. If you plug 100GeV from the Large Electron-Positron Collider into this calculator you get more than 99.9% of the speed of light. Likewise for lead ions at >500TeV in the Large Hadron Collider.

Slashdot Top Deals

A morsel of genuine history is a thing so rare as to be always valuable. -- Thomas Jefferson

Working...