Want to read Slashdot from your mobile device? Point it at m.slashdot.org and keep reading!


Forgot your password?
Check out the new SourceForge HTML5 internet speed test! No Flash necessary and runs on all devices. Also, Slashdot's Facebook page has a chat bot now. Message it for stories and more. ×

Comment Re:No robots here, son (Score 1) 45

"remotely operated robots" are NOT robots any more than one of those remotely controlled model airplanes is a robot.

Real robots are programmed to control themselves and do NOT require a human to operate them.

Read some of the works by Isaac Asimov for an education.

Didn't read the TFA, but I have to guess this is a form of "fly by wire" where, for example, you might tell the robot where to go but not how to dodge obstacles. In other words, somewhere between a fully manually controlled RC plane and a scifi robot.

Comment Re:Not the point (Score 1) 57

The need is pretty clear: Processing of data that needs to be secure against the cloud-provider. That this is very likely infeasible [...] a malicious hypervisor could just run on entirely different hardware and simulate all the protection features [ ... ]

Right - there's a need for secure remote computing.

But, remote security in general is a different topic than discussing VMs on hostile hypervisors. If you don't trust the people who control the hypervisor, any discussion of vectors of access to the VMs is academic. Because there *will* be ways - both software and hardware (for example, dual ported memory and ICE).

So, the TFA seems to be fluff and FUD in attacking the lack of a pointless feature.

Any solutions for secure remote computing probably need to involve a hosting setup where you have full control over the hardware, not a VM on hardware controlled by the site.

Comment Not the point (Score 1) 57

We show how a malicious hypervisor can force the guest...

So, having access to the physical hardware means game over? Gee, what a surprise. Preventing one VM from accessing or affecting another is useful. Offhand, I can't imagine much of a need to preventing a hypervisor from accessing the VMs that it controls...

Comment Re:not just live sports (Score 1) 137

I almost think they should change the rules to favor the team that's behind to keep the score closer. "Socialized" sports? Worth a try. The main purpose of sports is entertainment anyhow: they are not factories. Blowouts suck, with or without recording

Preventing predictable blowouts is exactly what is behind many of the NFL's policies. Salary caps, player free agency, easier schedules for teams that did poorly the prior year, and better draft picks for teams that did poorly are all designed to make it harder for any team to dominate. The idea is that on "any given Sunday" anyone might win.

Comment Re:Sounds fine to me... (Score 1) 101

Just to play Devil's advocate a bit here, but isn't this exactly the way the system is supposed to work?

No. Period, full stop. Very few think the "system" should gather as much data as possible on as many people as possible. I don't know the U.K. laws, but in the U.S., the authorities aren't allowed to search out whatever they want about you without probable cause and/or warrants.

Having information on someone is what puts them in the "no security interest" category, rather than the "unknown" category. In reviewing that information, crimes like copyright infringement may be discovered, and that puts the person in a different category entirely

So, we should hoover up all the information we can about everyone, so we can be sure we know who would be "of interest"? Cardinal Richelieu would be delighted.

Now, if understand the typical Slashdotter's perspective, the government shouldn't be allowed to gather information on people of "no security interest", but they can't know who that is without gathering information. Naturally, then, we will lobby to prohibit all gathering of information, and when successful, we will mock the government's eventual failure to find people who are of "security interest" with their then-nonexistent capabilities.

Why, yes, most of us on Slashdot use a silly fake paradox to conclude that no investigative effort should ever gather any information. Idiot.

The real question is are you a troll or do you just come from a black and white world?

Comment Re:Packets ARE equal (Score 1) 135

VOIP and other time-sensitive packets must be prioritized over other packets or performance of those services won't be acceptable to users.

ISPs want to argue that, but it's not as relevant as it looks. Because QOS priorities really only matter if the network is congested. And, the ISP shouldn't have congested backbone links.

The car analogies the ISPs offer up are broken. It's not really about being able to have a faster than *normal* lane. Having a higher QOS priority is more like driving in a normal speed toll lane during rush hour because the the non-toll lanes are congested. But, outside of rush hour, when the non-toll lanes are running just as fast, there's no point to paying to drive in the toll lane. ISPs shouldn't have the congested links that are analogous to the rush hour though.

Much of the ISP's desire to do shaping seems to be about having intentionally under-provisioned links and then either charging a toll to "uncongest" or making a competitor's traffic suffer while the ISP's traffic doesn't.

Comment Re:Huh?? (Score 1) 136

Abortions are not a right, never were: have been illegal for the past more than 100 years, ...

I'm sure you have some lame pseudo-legal argument that you think proves that statement, but you're wrong. Whatever your argument is, it's not something people are actually prosecuted under. Some abortions are legal. If they weren't, all the abortion clinics would have been closed down. The people that want to use the legal system to stop abortions are finding other ways. They do things like passing the recent Texas law that required that abortions only be done in facilities that have more surgical capabilities than is required for other more complex surgical procedures.

Comment Re-implementations *are* OK (Score 1) 118

No, almost all the posters have it wrong - a carefully done re-implementation can be legit. You can't use the exact same potentially trade-marked names. You can't re-distribute the original art work. But, you can do things like create a new engine and anyone who owns the original game can then re-use the content in the new engine. See the article on Game Engine Recreation or the OpenMW project that's creating a version of the Elder Scrolls III: Morrowind game in a new engine.

That said, I don't know if this Metal Gear Solid remake wasn't careful to follow the rules or if maybe they did, but Konami gave them enough grief to make them stop anyway.

Comment Re:Asinine (Score 1) 128

This is asinine. ... undercover agent, or something along those lines, leaking that information could make those people or their families vulnerable to kidnapping and violence.

How the hell is that +5 Insightful?!? I seriously doubt undercover FBI agents are using their real names! The only time their real name should come out is sometimes at trial.

Just because you have unauthorized access to do something and you have the skills to do so, that doesn't make it right.


Comment Re:The one lesson developers should learn (Score 1) 39

[ Depending on a service offering (especially a dirt cheap one) is a risk ]

Which is why you should use layers of abstraction.

In this example, it would be sensible to support at least two services for back-end data storage. If you want a minimal footprint, you don't even have to ship your mobile app with multiple back-ends enabled (nor the config options to choose a back-end). You'd still be in a position to more quickly provide an update if the service disappears or looks like it's about to.

Comment Re:O RLY? (Score 1) 310

[...] you also have to create low-cost reusable rockets designed for repeat operation on the moon with little to no maintenance, fueled by materials from the lunar surface. Which is a vastly harder, more expensive task. After all, it makes no financial sense to mine a tonne of water from the surface of the moon and then deliver it into lunar orbit or beyond with 10 tonnes of hardware/propellant sent from Earth, which in turn took 100 tonnes to get off the surface of the Earth. Everything has to be long-term operable entirely in the lunar environment with lunar resources.
There's not any realistic budgeting scenario where it's even remotely cheaper, all capital costs included, to get your water from the moon in the remotely near future than to just launch it from the earth on existing rockets.

Electromagnetic mass drivers might make more sense than rockets for launching raw materials from the moon. At least that was what Gerard K. O'Neill and company concluded decades ago... Of course, you still have to build the mass driver on-site or deliver it there and run a mining operation.

I have to think that for sufficiently large scale offworld operations, you're going to want to mine materials from somewhere - either the moon or asteroids. As interesting as the topic is, I don't think we'll be building semi-permanent moon bases, Babylon 5, or mars colonies within ten years though.

Comment Re:Isn't this what --preserve-root is for? (Score 1) 699

[ ... ] It's completely normal for a *nix based system to expose something like UEFI variables through the filesystem. It's a concept called Everything is a File and is the same reason why root can read and poke places in /proc and /dev to get information about the system or make changes to it.

Sure. But is the mapping provided here sane? It makes sense to provide a view of the variables as files. Reading the file should return that variables value. Writing the file should change that variables value. OK, so far.

If deleting the file is to have any effect on the actual UEFI variables, it should mean deleting the variable, not zeroing it. Does deleting UEFI variables from the BIOS even make sense? Note that for /dev, the files represent read/write/ioctl access to a device but that deleting a /dev file is like deleting a pointer to an object - it removes your pointer but has no effect on the object itself (and any other similar pointers are still usable). I strongly suspect that the filesystem for these variables should work the same way. Even if creating entirely new variables and deleting them from UEFI is a valid thing to do, it probably needs to be done by a mechanism other than filesystem semantics.

Slashdot Top Deals

There are never any bugs you haven't found yet.