Slashdot videos: Now with more Slashdot!

Everyone sounds revolutionary in whitepapers when they're looking for money. See if that revolutionary talk sticks around after they mass-produce their new hardware and have to support it. That's always when the magic disappears.

Transmeta couldn't build anything that competed with Intel's offerings. The power consumption was lower, but the performance sucked. They were about a generation ahead on power consumption but about 2-3 generations behind on performance.

Code morphing has an inherent penalty---negligible for some instructions, severe for others. Same for emulation. Now that Intel is focusing on performance per watt, these "efficient" architectures are going to get buried by a truly efficient native x86 implementation.

Transmeta existed in an environment where Intel was focused on improving performance almost exclusively. They had a little niche of the market all to themselves, and they couldn't even survive then. Now that Intel cares about power consumption, I wouldn't bet on anyone else gaining a foothold.

You might think something like that unless you actually read the article.

From the description and the diagram, it appears rather clear that they are acting as a local seed for clients on their network.

This is an obvious win-win. It reduces their transit to other networks and keeps BT traffic off their backbone routers (provided the "local peer servers" are distributed regionally). Users get higher speeds from a virtually dedicated seed connection.

The obvious downside is that the ISP knows which torrents are being downloaded by which users, so there are potential privacy or legal issues. From a technical standpoint, however, both the ISP and the users would see an improvement.

This is actual innovation from an American ISP. I'm shocked that it happened, and even more shocked that people are upset about it.

That does not work since he is accessing Amazon, Netflix, and whatever CDNs are caching his shows.

With the growth of online video and IoT devices---and their resulting need for CDNs, redundancy, and resilience vs load/DDoS---simple IP filtering is becoming increasingly difficult for even a modestly connected household. And the difficulty is only going to increase over time.

I'm at the point where I'm about to give up on manual filtering entirely, and I don't have a lot of the shiny new networked devices. In the past, "dumber" devices have ended up being relegated to the cheapest bargain-basement hardware on the market. There are very few premium "dumb" devices anywhere.

I want privacy and security, and I want those things without being forced to buy the bottom-of-the-line crap. If they don't stop making invasive, insecure "smart" devices, I see bigger problems looming.

And if we notice any behaviors harming our overall social environment while simultaneously enriching businesses, we can pass laws to prohibit those behaviors.

It's certainly feasible to prohibit known-bad behaviors preemptively rather than waiting for the market to discover and react to individual acts of malfeasance or breaches of trust.

In addition, a violation of established regulations or commerce law generally provides firm legal footing for a civil suit against the violators. These cases tend to be litigated much more quickly and successfully. Or settled without taking the matter to court at all, which is really ideal.

1. They probably derive from value from the vendor lock-in than they expect from sharing. The rival OSes can already join an Active Directory domain (some require third-party tools, some don't). Right now, if you want to manage a fleet of Windows desktops you need a few Windows Server licenses for your domain controllers---and the requisite CALs. There are already open source AD clones anyway, which is probably why 2008, 2008 R2, and 2012 functional levels have such nice new features. They want to maximize the number of Microsoft products you're using.

2. Until Microsoft storage demonstrates the reliability of EMC or Compellent, no one is going to care. Linux and Windows can both work as an iSCSI target, and that's good enough for people who want cheap, accessible storage. Customers who already demand reliability and performance are paying for it because they need it. Maybe there is a bigger market for people who could benefit from some middle tier of storage, but there are plenty of vendors in that range too. So, the question still boils down to "Why put that storage in a server and trust Microsoft to present it?"

3. At the enterprise level, if you're relying on AV detection to find malware, you're already behind the curve. Most of the new security features are targeted at the network-connected enterprise machines, with some trickle-down benefits for consumers. The VM/hypervisor idea will wreak havoc on the two performance areas that matter for Windows desktops---CAD and gaming. While I agree with the principle, it's not happening. Microsoft started research on Singularity almost 10 years ago, and little of that work has shown up in Windows.

Modern versions of Windows (Vista and newer) will find your license server automatically, unless you configure either your OS image or your license server to do otherwise.

It's a simple matter of having the right SRV record in DNS, and the license server will add it automatically if it's setup by a user with the necessary privileges.

The current license server supports all modern Windows versions. I wonder if that will change once Vista leaves its extended support phase. I expect it will take minimal effort to maintain activation support for an older OS, so I doubt they will simply drop it and risk irritating their enterprise customers. At this point, they're the only ones willing to pay a substantial amount of money for an operating system license.

Takeoff is the absolute worst time for an engine failure.

They still made it from LAX to Manchester with a failed engine. That's pretty impressive.

A dual-engine aircraft would not have fared nearly as well. The best expected outcome would be an emergency landing at the nearest airport.

If the company had a history of never patching vulnerabilities or even being spotty and refusing to support new products, then it makes sense to out them immediately.

But Microsoft has been issuing monthly patches for supported versions of Windows for years.

Yes, they'll delay or rescind a patch once in a while when it breaks things. Any company can be in that position though, and that's OK too provided they reissue a good patch when it's ready.

Instead of publishing exploit details and POC code automatically after 90 days, they should publish mitigation measures immediately (to actually help admins secure their assets) and sit on the more technical details for longer than 90 days if they reasonably expect the vendor to issue a patch. Maybe set a hard cap of 180 days to avoid being strung along indefinitely. While 90 days is a good starting point, no two bugs are the same.

An automatic one-size-fits-all approach is draconian and stupid. Some bugs require multiple rounds of testing because things get broken unexpectedly by the first "fix". Large software projects often end up with hidden dependencies that complicate bugfixing; it's a fact of life, and ignoring reality in favor of ideologically-driven rules usually ends poorly.

It was detected during testing. Their entire retrievable/reusable concept is being developed and tested right now. Their contractual requirement is to put payload into orbit. The landing mechanism is merely an economic advantage for the company that will keep their costs lower; their contracts certainly don't specify it as a requirement.

Some shops use an iterative design process. It usually comes with being new to the market (and thus lacking the funds for extended pre-operative testing).

Some shops even do iterative design as standard practice when they are well-funded.

They were only required to launch supplies to the ISS. The ability to test and refine their landing mechanism is a bonus for the company. Hell, NASA's other contractor doesn't even have a reusable vehicle.

In conclusion: Do you know what we call a service that fulfills its contractual requirements? A success.

Pretty much.

The Windows Store has more granular permissions, restricted UI modes, and reduced legacy API support. These things will lead to apps using modern security and UI conventions, which is mostly a good thing.

A curated app store is probably good for normal users. As long as sideloading apps is always supported, this should make some headway on taming the burden of legacy software.

I expect to see an unending avalanche of shitty Win32 apps for the rest of my life, but the Windows Store at least offers some vague hope that it will diminish over time.

Applications and config/data files that need to be available for multiple users can be installed to C:\Users\Public by default without admin privileges. This location is available in an environment variable in case the admin has changed it (can't remember the variable name off the top of my head).

Applications with per-user installation or config files can use the %USERPROFILE% environment variable to find a safe place to store their data (defaults to C:\Users\username). Creating your own directory there is probably a good idea and is permitted by default.

There are guidelines for using the pre-established directories for Desktop, Documents, Downloads, Music, Pictures, and Videos though, since they are shared with the OS and other applications.

Chrome has a Windows installer that does not require elevation. The single-user installer unpacks to a directory in the user's personal profile and runs from there.

Since it cannot install the updater service without admin privileges, Chrome cannot upgrade seamlessly---the browser must be running to detect the update, so it must be restarted afterward. I suspect this is why the standalone installer is not the default option and not widely advertised.

The latest version is always linked at https://support.google.com/ins... if you need to grab a copy.

You identify two systems as examples of your new "security" feature, but both of them have been laughably compromised. Neither scheme lasted more than a year in the wild, and with a PC security standard you'd need to manage a bit more than that.

I bolded the part that is problematic. How does one burn a key into the device as part of a driver, exactly? With security, the devil is in the details, and your proposed system sounds no better than similar systems which have failed in the past.

Nice ad hominem, but maybe you should have provided a substantive argument instead.

I believe your explanation rather than my intelligence is at fault here. You identify two systems as functional examples of your new "security" feature---neither of which is effective in practice. AACS has been compromised repeatedly, which shows that simply revoking the exposed keys and hoping new equipment fares better is not an effective strategy.

Can you explain, clearly, how your system differs in such a way as to render it immune to similar attacks? If not, then there is absolutely no reason to take your proposal seriously.

If you don't see a problem with PRIVATE KEYS being distributed inside mass-produced hardware, I do not even know where to begin criticizing your position.

Every piece of equipment would need significant anti-tampering measures because as soon as the keys are retrieved from one device, it is game over.

This is why DRM software keeps getting cracked over and over in spite of the billions of dollars being spent on developing it. If your scheme requires a secret that the user needs to operate the device, it will be compromised.

People crack stuff like this for fun. We've seen it happen year after year. Do you think there will be more or less cracking attempts when there are serious espionage or financial incentives?

What? USB devices in general, and HIDs in particular, do not authenticate with the OS when plugged in.

You plug it in, and it negotiates with the host controller automatically. The host controller notifies the OS that the device is there, and then the OS queries the device for its properties. The device is perfectly capable of lying about what it is and what it does.

If the device identifies as a keyboard, mouse, Smart Card reader, or removable storage, by default the OS will load its native drivers and handle the device seamlessly. The device could have nefarious functionality, but the OS has no way of knowing about that.

Various OS security tools and third-party utilities can attempt to restrict the use of USB devices. None of them are pleasant to use---from the standpoint of either the administrator or the end user.

Not terribly practical or interesting. This idea probably came from someone who watches too many "hacker" movies. Anyone who is concerned about restricting USB devices probably already has a solution for detecting rogue Wifi clients and APs. If not, they can buy one off the shelf. This is something I would expect to see in a Hollywood movie.

Rogue USB devices are not something a hacker is going to use against some random citizen in hopes of scoring access to their checking account. This is something enterprises and governments are going to be worried about, and they have options for mitigating the threat.