Follow Slashdot blog updates by subscribing to our blog RSS feed


Forgot your password?
Check out the new SourceForge HTML5 internet speed test! No Flash necessary and runs on all devices. ×

Comment Not the point (Score 1) 47

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.

Comment Re:No, C and C++ are the most important. (Score 1) 190

C and C++ are only the foundation because the happened to become popular due to a bunch of misc. factors, not because they are inherently great inventions in themselves. [ ... ]

No, C *was* a great invention. That there are other choices today doesn't change that. It was perhaps the first HLL (high level language) that was small, efficient, and yet also usable for low-level tasks. It was "small" in the sense that that it provided a minimal number of constructs and didn't provide any hard to parse features (unlike, for example, Ada). The fact that it was small was probably a big factor in C having one of the very first machine independent compilers, the Portable C Compiler.

From the Wikipeda C entry:

C is a general-purpose, imperative computer programming language, supporting structured programming, lexical variable scope and recursion, while a static type system prevents many unintended operations. By design, C provides constructs that map efficiently to typical machine instructions, and therefore it has found lasting use in applications that had formerly been coded in assembly language, including operating systems, as well as various application software for computers ranging from supercomputers to embedded systems.

Comment Re:Security in various protocols (Score 1) 162

[ Vendors ] are designing security into newer protocols...

That's nice... *today*. Well, assuming every protocol someone designs and that someone implements will be free of security flaws... But, "nice today" is not very useful long term.

Imagine, for example, that something is running using Windows XP or a decades old Linux distro. They could have had the best available security when they were built, but they would suck now. A decades old SSH would now be vulnerable.

It seems that historically, sites always end up with some sort of old cruft in existence. As long as you have to account for equipment not being patched or upgraded, the quality of that equipment's security is insufficient. You need layers. Sane physical controls. An architecture of least privilege. You probably want some sort of VPN that has a guarantee of ongoing security maintenance even when everything else doesn't. Even then, the network access should have some of the attributes you'd use in physical controls - you don't let Joe Whoever into just any control room, so *try* to not allow network connection from just anywhere.

Of the above layers, the architecture may be the most important. For example, if it's OK to be air-gapped, that takes a lot of attack vectors off the table.

Slashdot Top Deals

To invent, you need a good imagination and a pile of junk. -- Thomas Edison