Perhaps I read this wrong, but the complaint sounds a lot like Linux developers are treating the DSDT like Microsoft developers treated HTML circa IE6. i.e.: It was coming from broken sources and the best option is to throw your hands up in the air and forego any attempt at sanely handling the results in a way consistent with expectations.

Well, that's wrong. I mean, yes, it's bad that Microsoft might have gotten everyone into the situation and we should shame them, and it would be nice if a standards body came along to force them and OEMs to be consistent here... But that is an ought, not an is.

So why is it so totally impossible to implement quirks parsing in the DSDT to emulate Windows behavior? What makes it so difficult that I have read only posts complaining about ACPI DSDTs produced by bad Microsoft software, and no posts about simply dealing with the situation for the benefit of end users?

This is a fine idea but you end up with spaghetti code, with many layers of these hooks. To support all the various features of ZFS would require a great deal of modules all hooking the API at various levels. You have to remember, a hook is essentially an INTERCAL "COME FROM" statement. It's a goto on adderall.

On the contrary, they could be negatively affected if all those proprietary languages which are locking them in cannot be re-implemented under the force of law. Those proprietary languages right now have to stay competitive knowing that high prices would encourage an alternative to enter the market. To put it another way, if Microsoft doubled the price of Windows, they might retain enough users to make more money, but they'd also risk a flight to WINE, and I guarantee you a lot of those potential customers, particularly large businesses, would look at moving away from a dependency on Win32/Windows. Now imagine if Microsoft didn't have to worry about the competitive pressure of WINE, and no one else could legally duplicate Win32?

Now, of course, Microsoft has other competitive pressures, and their price choice is probably not dominated by the potential for competition, but for niche programming languages and environments, I would guess they are. My friend, an economics major, was faced with the potential of having to spend $500 for a single user license for some very niche regression analysis software that had a particular API and programming language. If they can get away with charging college students and academics $500, they must not be overly concerned with competition. A ruling on the copyrightability of APIs in favor of Oracle would make it so they wouldn't have to worry about any competitors claiming "compatibility" with their software.

That's irrelevant though, and you're just picking a fight. I was responding to Joe_Dragon's completely inane objection to Windows 8 from a business standpoint, see his title: "that will be a death note to enterprise use". No, it won't be, and I explained why.

Do you want to engage on a debate on Windows Live logins as well? Because you should know before you start that the Windows Live login has minimum security requirements, doesn't appear to store the Windows Live password locally, and appears to follow some pretty damn good security practices. Now, I haven't fully verified all of these claims, but the login process for Windows Live login appears to use local passwords and certificates to verify the local account password against The Cloud(tm) when available. This is actually an astoundingly good process, as I don't think the hash of the Windows Live password is ever stored on the computer, rather, it can be used to access the local password, but I don't think physical access to a Windows 8 machine can possibly give you access to a user's Windows Live credentials. You can only gain access to local, unencrypted data.

There are bits of this I haven't verified, but are based off hunches of exploring the system and poking and prodding it. I haven't disassembled the login routines to verify what I think is happening is the actual process, but it appears that Microsoft has very much followed good security practices here. I was extremely impressed to notice that enabling Windows Live login merely downloads a certificate to the user's local certificate store (encrypted by a local password) and that other mechanisms appear to be in place to mitigate security risks.

If you took the cursory amount of time to research this, you'd find that (a.) no, Microsoft doesn't expect business users to rely on authenticating against Windows Live, and (b.) that Windows Live log in is optional and not necessary, and a local account works just fine. You just don't get access to some easy synchronization items, but you can still access the windows store and apps by manually logging in.

But hey, this is slashdot. Who needs to verify before they make grandiose claims?

If the Android version doesn't have a (securely) locked bootloader too then yes you will be able to.

The situation with Windows 8 on ARM *sucks*, I don't like it and I don't think they should dictate to OEMs that they must not allow custom mode. In my opinion, they went too far with locking down ARM and freeing up x86. For Windows 8 x86 machines, it is required that the OEMs provide a mechanism to install alternative operating systems. For ARM, it is required that they not. This is, to me, wrong. But c'est la vie, it is actually not too different from other tablets, most Android tablets I believe have locked bootloaders that had to be circumvented to install other OSes. And of course, the iPad is a black box.

Slow down cowboy, I think he's referring to the tablet and mobile market, in which Apple does have a large market share and they have:

* Restricted users from installing other OSes? Check.
* Bundled their own apps? Check.
* Restricted users from installing apps whose functionality overlaps with the bundled apps? Check.
* Restricted app developers from using advertising providers that aren't Apple? Check.

The list goes on, and on. The iOS developer agreement is a hideous, monstrous, terrible blight on the software world and should never have happened. But Apple has gone further in embracing lock-in and bundling and anti-competitive practices with iOS than Microsoft has *ever* gone with Windows. If you produce an app and Apple decides to make that part of the core functionality in the next version, they'll take your toy, kick sand in your face and eject you from the app store. Only the immense amount of pressure of some very large companies lobbying Apple for leniency on particular apps has caused them to yield on *certain things* and they are very particular about what those things are.

Doesn't work. Just rerun the picture test enough times to deduce that the constant is that you always get cars and flowers, but other items are subject to change. So then by induction, you try one more thing. Three constant things. Well then there are only 6 ways to choose 2 elements. Fine, make all say, 9 pictures constant "things", one of which is a car and one of which is a flower. How many 2-permutations? 72.

Surely an accomplished individual like him could put out a serious paper on why picture passwords aren't good security, if they aren't. The math seemed alright in the Microsoft blog, so I don't know what the problem is.

Oh, I know what it is, he's the head of a company that offers alternative security products that use multi-factor authentication. *Of course* well implemented multi-factor auth is more secure than single-factor, but if he weren't in charge of a company trying to sell a product, would this article even exist? Probably not.

The law is what you can successfully litigate.

An anonymous coward writes

"Slashdot readers have decided to label recent articles as tainted crap for significant journalistic flaws. These articles reportedly lack substance, appear to be written by a child, and have other problems. With Slashdot articles being flagged as tainted crap, they will be taken less seriously by their readers."

I don't think Verisign will sign your private root certificate, no matter how much you ask. At the very least, I doubt they'd sign it with flags that make it able to sign other certificates in a chain, it'd just be for verifying the authenticity of the (your) private root.

Yes! I've discovered lately when evaluating Chrome for workstation use that Chrome now has a (ever-growing) list of group policies available. Grab the adm/admx templates and MSI installer and check them out.

Coincidentally, the latest Chromium/Chrome Canary/Chrome Dev builds also started ignoring IE's trusted zone lists and so windows integrated authentication (Kerberos Negotiate) stopped working. Boo. Supposedly there's a new policy that I can set to fix this. I reported the issue but am waiting for clarification on whether this is intended behavior, a security issue, or what.

Which way it's pointed.