Slashdot is powered by your submissions, so send in your scoop


Forgot your password?

Comment Re:And the purpose of this exercise is? (Score 1) 421 421

Ha ha ha ha ha ha, did you just compare damage to a 'bridge inside borders' to a bridge over the ocean?

I compared a bridge across a large body of water to a bridge across an only slightly larger body of water. Whether the bridge goes from one country to another is largely irrelevant unless the leaders of one country or the other are idiots. After all, they would both have to pay part of the cost of any future repairs to that bridge, which is a powerful disincentive to bombing it in a fit of stupidity. If anything, the nature of such a bridge might even serve to stabilize relations between the two countries.

The only bottleneck there is a port and ports are much easier and faster to build than additional bridges to increase throughput.

Ports can only increase bandwidth. What shippers care about is latency. The only way you can improve latency with boats is to build faster boats, and the faster the boat, the less it can carry (and the more fuel it takes), so there are very real practical limitations involved.

A burning bridge stops all cargo from being moved, while a burning ship only stops that ship. Shipping docks are a scalable solution, while a bridge is a fixed throughput solution that cannot be scaled without building a second bridge.

A burning dock stops all cargo from being moved. Your point? You think that after Russia and the U.S. build a multi-billion-dollar bridge, one of them is going to suddenly decide to blow it up on a whim? Periods of international tension might very well close the bridge, but I can't imagine them being shortsighted enough to blow it up.

Also, bridges can be repaired pretty quickly these days, for the most part. When a tanker fire destroyed an elevated road segment in San Francisco back in 2007 and caused it to fall on top of another elevated road segment (requiring significant repairs), they had the lower segment repaired in eight days, and the upper one rebuilt in just 25 days. And with the floating bridge I described, assuming you build some extra segments, damage could be repaired in hours simply by towing another identical segment into place and fastening it to the adjacent segments. You just have to provide enough of a financial incentive to grease the wheels of the bridge building company. :-)

Comment Re:And the purpose of this exercise is? (Score 1) 421 421

And how long does it take two trucks to ship the same amount of goods as a fully loaded freighter?

I'm not sure how that's relevant unless your company needs to ship a full freighter-load of goods. I'm not talking about the biggest companies here. I'm talking about the myriad companies that routinely use international shipping in much lower volume. For those companies, what matters is latency—how long they must wait for something to arrive stateside—not bandwidth.

If you're one of those rare companies that can fill a freighter, then your company is clearly in the category that can afford to bring in its first two weeks' supply by air while the boats are carrying the next month's supply, and the boat latency doesn't matter (unless you're a shipping company). But even for those big companies, it could still cut out the second week of air shipments, which could be a significant financial win. And for shipping companies that provide services to smaller companies, being able to offer a level of service between "very expensive" and "glacial" would be a significant win, too.

Comment Re:And the purpose of this exercise is? (Score 1) 421 421

Nobody can predict what will happen between the U.S. and Russia, but I'd be really surprised if things got so bad that U.S. companies didn't feel comfortable shipping goods through Russia. It's not like we're talking about a third-world country or anything.

And what you say about damage is downright silly, because the same concern applies equally for a bridge inside our borders. In fact, by your standards, the docks where those boats load their cargo should never have been built, because if one of the minimum-wage immigrants carrying cargo on his shoulders out to a small boat in waist-deep water dies of a heart attack, it doesn't prevent other workers from loading cargo, whereas if a dock collapses, it does, and those workers can be used for other things if we suddenly no longer need boat shipping. I mean, the only way that logic even starts to make sense is if a serious failure is highly probable, and if that's the case, then it means they got the design wrong.

Besides, the cost of a Bering Strait bridge could be a lot lower than you might think. They would need one segment of it to be tall enough to let shipping traffic through—possibly between the two Diomede Islands—but the rest of it could ostensibly be a simple pontoon bridge, which is relatively cheap.

Most of the cost of the project would likely be for that one span between the two islands that's tall enough to let ships pass under it. That would cost several billion dollars, in all likelihood. The remaining 55 miles, assuming other pontoon bridges are any indication of cost, should be the neighborhood of $5 million to $10 million per lane-mile. At 55 miles long, a four-lane pontoon bridge should cost a couple of billion dollars, give or take, which is about as much money as we waste on a single B-2 bomber.

Of course, a pontoon bridge in that area would have to be specifically designed to withstand the rather severe storms that the Bering sea experiences, which could drive the cost way up. On the other hand, the project is so huge that economies of scale would kick in and bring the component cost way, way down (because you'd be building over 18,000 identical 16-foot segments), which would probably balance that out to a large extent.

Of course, I am not a bridge engineer, so my estimates could be way off, but I wouldn't be at all surprised if someone were able to come up with a design that fell under the $10 billion mark, or about twice the cost of the Bay Bridge. Heck, the tunnel that Russia proposed was only sixty or seventy billion, so that estimate probably isn't too far off the mark.

Comment Re:And the purpose of this exercise is? (Score 2) 421 421

But not cheaper and faster. A boat from China or Japan takes 10-14 plus loading and unloading time (which, if you're sharing a boat with a bunch of other companies, can potentially add weeks of delay before the boat leaves the dock), and air shipping is relatively expensive. With two or drivers trading off, you could potentially do California to Japan by truck in about a week.

Having a bridge between North America and Asia could be absolutely huge for shipping, as a potential midpoint between the two shipping methods. Whether it will be or not is another question.

Comment Re: Just goes to show you UNIX SUX (Score 1) 62 62

So if you are an ISP providing a secondary DNS service, you're happy to create accounts with ssh/rsync access for 10 000 customers who all have more lax security than you do?

Sure. You give them all a shell account with access to their own zone files, and you require them to provide a public key for authentication (no passwords to attack). Then, you have a separate process that watches for changes and updates the official zone files that the daemon reads. Clearly, a daemon that has write access to all of the zone files is inherently less safe than a series of ssh accounts, each with access to only a single user's files, coupled with a daemon that has only read-only access to copies of the original zone files.

Comment Re: Just goes to show you UNIX SUX (Score 1) 62 62

Actually, it's not that simple. The DNS compression scheme is horrendous, although that can be easily isolated. Most of the complexity of DNS servers come from the 1) caching, recursive logic for client-side servers, 2) automating zone transfers, 2) various schemes for avoiding DoS attacks. Dedicated servers like NSD and unbound, which either server a zone _or_ implement recursive lookups for clients, can be a little simpler.

I've never understood why DNS servers bother with zone transfers. These days, it would take an average admin three minutes to toss together something involving a cron job, rsync, and ssh that would do the same job without adding all that extra code and the extra attack surface that comes along with it. Heck, with access to platform-specific file system event APIs, you could probably come up with something that worked a lot better, up to and including near-instantaneous updates. That entire feature just seems like pure bloat, and that's coming from somebody who actually uses zone transfers....

Comment Re:Swift (Score 1) 352 352

Swift isn't going to make it so "anybody can write apps." That is something that's been tried for decades, with things like drag-and-drop programming. SQL was originally intended for non-programmers. It doesn't work, because the difficulty of programming isn't the syntax. The difficulty of programming is logic.

While true, the danger exists that making the syntax easier will encourage more people who don't understand logic to try to write code anyway, usually with disastrous results. Maybe it's the UNIX greybeard in me, but I've always seen the complexity of language as sort of a "you must be this tall to ride" bar, limiting the amount of damage that clueless people can cause.

And it isn't just that the software that new programmers create is usually bad. It also clogs the marketplace with low-quality apps. The more bad apps people write, the harder it will be for well-written new apps to gain footing, because they'll start out with several times as many poorly written apps ahead of them in their sales ranking.

But the biggest problem with making it easier to write code is that every step down that path requires ever-increasing resources. Right now, it takes about an order of magnitude more effort to write a beginning programming guide than to write a programming guide for experienced programmers, even for a moderately complex technology. And that's if you assume that people understand basic logic, control flow, etc. If you go one step beyond that and try to make it practical for non-programmers to write code, you'll spend two or three years writing a good, solid introductory textbook. And I have yet to see any evidence suggesting that any significant percentage of those folks will be able to write decent code even after reading such a book.

The kernel is stable not just because it has to be, but also because it scares people away until they are reasonably competent at programming. The web is filled with bad code because it doesn't. IMO, apps should be more like the former than the latter. Just my $0.02.

Comment Re:No kidding. (Score 1) 258 258

Neither of those provides any mechanism for downsampling an image before uploading it. In fact, from a same-origin security model perspective, JS code isn't even supposed to be able to access the image data before uploading it, though I think they've left some holes where devs can get around that....

Comment Re:No kidding. (Score 1) 258 258

Sure there is. That's exactly what RSS [] was made to do. Not only can you visit a site, get a feed, and add it yourself, but there are also applications that curate and categorize popular RSS feeds so that you can search for and add them without having to visit the websites first.

The problem is that RSS is one-directional. If I want to post, I still have to go back to a browser window and use whatever random, horrible, non-mobile-friendly interface the site designers came up with. And posting is usually the part where a native app would be beneficial; the reading part is easy by comparison....

"Anyone attempting to generate random numbers by deterministic means is, of course, living in a state of sin." -- John Von Neumann