Ceres is also a dwarf planet. An increasingly interesting one at that. Really I find it pretty amazing that space exploration has practically ignored such a large, nearby body with tons of launch windows up to this point.

And it is a planet. It's a dwarf planet. Dwarf means small. Planet means planet. Dwarf planet means small planet. So what's the problem?

How many exoplanets pass the current IAU definition of 'planet'? I bet a bunch don't.

Of the ones identified thusfar? I'd wager "the vast majority if not literally 100%". We can't see little stuff. Everything we see is big, which means strong orbit-clearing power. And usually also close to its star, which also helps clear the orbit.

Exactly. There are many categories of planets, including but not limited to:

  * Terrestrial planets
  * Gas giants
  * Ice giants
  * Hot jupiters
  * Superearths

And so forth. Why does the concept of another category, dwarfs, enrage people?

Really, the only categorization issue that I'm adamant about is that Pluto-Charon is called a binary. The Pluto-Charon barycentre is not inside Pluto, therefore Charon is not rotating around Pluto, the two are corotating around a common point of space between them. That's a binary.

I think that the apps are supposed to be signed(at least to get useful elevated priviliges, like access to the network or to the player local storage); but if a signed, legitimate, app makes a network request to a server that is no longer friendly, then it becomes a question of input validation, even if the application signing scheme is 100% in order and nobody screwed any part of that up.

Call me a pessimist; but I'd bet nontrivial money that a lot of the 'interactive' cruft that is pumped out to bulk up 'special edition' releases is barely up to the challenge of presenting a helpful error message if it gets a 404 from the remote host, much less not falling over and wagging its tail against moderately clever malice. In that case, it'd be a fully signed and approved app doing the work, but taking action based on (ill-founded) trust in content it downloaded.

I'd not be terribly interested in the capabilities of the players themselves(routers make better zombies and are way more internet facing and unlikely to be turned off, and generally atrocious on security); but I would be very, very, nervous about anything that serves as a nice, subtle, persistent implant on a LAN.

Even enterprises have a nasty habit of pretending that they can get away with a little sloppiness 'inside the firewall', and consumer gear often can't be persuaded not be absurdly trusting of anything that happens to share a subnet with, in the interests of ease-of-use, 'autodiscovery', and similar. If you can get an implant on one device, especially one that nobody is going to suspect(and may have few options, short of replacing, if they do), you can reinfect other devices as they pop up more or less at your leisure.

Unfortunately, it's not just blu ray: 'BD-J' is their specific variant; but it is based on the so-called 'Globally Executable MHP', a truly horrifying acronym-standard-soup constructed to enable vaguely interoperable java-based UI atrocities for various flavors of set top box associated with DVB-T, DVB-S, and DVB-C(Basically, all digital broadcast and cable activity that isn't ATSC, ISDB, DTMB, or some fully proprietary oddball).

BD-J is North America's main point of contact with this delightful substance; but it enjoys near-total ubiquity in the parts of the world that also use DVB.

It doesn't rank terribly high on the list of choices, given that it would be a pain in the ass to get your malware pressed into a reasonable number of disks(without suitable insider access to the later stages of disk manufacture process, in which case you might have some real room for fun); but there is one little detail that might get rather ugly:

With 'BD Live', disks can be authored to include access to network resources, as well as locally stored assets, in their Java-driven interactive content stuff. Now, there is no way for an attacker to change the URLs a disk requests; but nor is there a way for anyone else to do so. Whatever was stamped into the disk at production will remain until the disk leaves use.

Given that companies come and go, and company interest in specific products tends to wane even faster, I would be very, very, very, surprised if the various companies releasing 'BD Live' disks have managed to always retain control of the domain names that their disks will attempt to access. It wouldn't be a terribly high value exploit; but since a disk will attempt to access exactly the same URLs until it dies, you might be able to score a steady trickle of reliable re-infections by snapping up any lapsed domains associated with BD Live disks and adding a little 'bonus content'.

I suspect that there are a number of ways in, given the usual attention given to firmware quality; but blu-ray isn't helped by having a security model marked by absolute paranoia about the precious 'content' escaping, combined with some amount of incompetence and a lot of pure apathy about any other security concern.

With both the BD+ vm and the BD-J stuff, there is a lot of attention paid to 'ooh, the an unauthorized player attempting to do unauthorized things with the content on the disk?!'; but the contents of the disk are largely treated as trusted and the playback device is treated almost entirely as a potential adversary, not as a potential target, either from the disk side or the network side.

Videconferencing + whiteboard. It's a very common combination (as it is no longer uncommon to work with remote teams.)

Zoom right in on the bits that you think are white, so that they fill your entire monitor. They're obviously blue. For a lot of us, that's the colour that we see when we look at it in context as well. I can see how you'd interpret it as being white by overcompensating for the colour in the bottom right, but that doesn't stop you from being wrong. The gold bits are gold when you zoom in (mostly, some are black), but a shiny black often looks yellow-gold in overexposed photos.

Ah, that's annoying. We can't play directly from BRDs? Bah.

Technically, yes, with the caveat that you'd need regular floating reboost platforms with significant power generation scattered all throughout the Pacific, and of course maintaining the track perfectly straight while floating (one presumes at a fixed depth under the water) provides its own engineering challenges. But room-temperature rarified hydrogen instead of rarified air would allow one to make the journey at about Mach 4. Faster if it's hot hydrogen.

Are you under the misconception that hyperloop is a pneumatic tube system?

Hyperloop is a magnetically-accelerated a ground-effect aircraft operating in the sort of extremely rarified air normally only found at high altitudes. The tube's purpose is to provide such a rarified atmosphere near the ground. It's not a pneumatic train. It's not a vactrain. It's not maglev. It's a ground-effect aircraft.

Branching would be really tricky, but there's no physical barriers. Note that even Musk's proposal isn't as far as you can take the concept. If you fill the tube with very low pressure water vapor instead of very low pressure air (via more pumping to overwhelm leaks, plus water vapor injection), your top speed jumps 40%. Fill it with hydrogen and it jumps 300% (normally hydrogen is a real pain to work with due to flammability, embrittlement, etc, but the densities in question are so low that such issues are mostly avoided). So we're talking the potential for hyperloop "speedways" for long distance runs that could blow airplanes out of the water.

The low numbers of passengers per capsule is really key to making the concept economical. Compare, say, monorail track with a full sized rail bridge. The former is vastly cheaper per unit distance because the peak loadings are so much lower, because the mass of the monorail trains are so much lower. A computer-controlled high launch rate of small, high speed capsules means you're spreading the loading out greatly, which means greatly reduced loading and thus materials costs.

Still, while Musk has been thinking of Hyperloop stations in the "airport" concept, he really needs to get out of that mindset. His proposed plan had them on the outskirts of cities. Airports are only on the outskirts of cities because they *must* be. You greatly reduce your utility by doing that, by making people catch connecting trains. Hyperloop can extend just fine into towns; with his two proposed endpoints in particular there are excellent rail routes into town that are quite straight that it could be built over.

.\\// from http://news.slashdot.org/comme...