First, let me say that I totally agree that "regular" users -- those who are not programmers or testers or system administrators -- do not typically need administrative rights, nor do they, in the ideal case, need the ability to run unauthorized third-party programs.

HOWEVER, my concern is that there will be many inappropriate and heavy-handed uses of this technology called "Device Guard" by IT departments that are not effectively satisfying the needs of their users.

Firstly, every IT department would, in an ideal world, be willing to get over themselves and accept the fact that software development can, and should, happen in departments other than the official IT department. The larger and more diverse your organization is, the truer this statement is. An employee shouldn't have to be within the reporting chain of the CIO or IT Director in order to be able to develop software as part of their official responsibilities. And yes, if an employee's management chain officially assigns them software development duties, and these responsibilities are accepted as legitimate by a corporate officer who isn't in IT, then this software development *is* official, even if IT isn't aware of it.

The next thing is, IT organizations need to assign appropriate permissions and trust (e.g. local admin rights) to these external development organizations. Trust them to do their job correctly, and only crack down if there is an actual violation. If you're worried about compliance, give them your security policies and make them provide a compliance report before deploying the software. Come up with some *minimally-invasive* hoops they'd have to jump through to get approval to deploy their finished software. *Don't* try to take ownership of their product lifecycle.

In an IT shop meeting these simple minimal criteria, I think this Device Guard feature would be mostly harmless. Jane the Executive Assistant tries to run an .exe screensaver with cat pictures and is blocked; too bad. Tom the software developer who doesn't work for IT submits a ticket and gets local admin rights within 48 hours so he can get his job done. Before deployment, he gets IT to roll out a patch to all their workstations whitelisting his codesigning cert, which was purchased on his (non-IT) department's dime. Everybody is happy (except Jane, but she'll live).

My concern is that there are hundreds of IT shops out there in the wild which do NOT have the political or social intelligence to enact policies like these, and would rather bury their heads in the sand and pretend there's not a problem. They are so averse to risk and change that they would rather see their company stagnate due to the unavailability of necessary tools and technologies, instead of working through the growing pains of becoming an organization that can accommodate the realities of the fast-paced 21st century business culture, such as the necessity of software development done locally to the people who will be using the software (advantages: reduced cost, shorter lifecycle, more relevant and accessible to the end-users, faster response to change requests, etc.)

These same shops without the above will be all too happy to turn on Device Guard for its security benefits, without making the required accommodations for the many existing Shadow IT organizations in their company, half of whom are afraid of IT's potential overreaction to their project and have thus never come forward and told IT what they're doing.

Mark my words: the day that IT departments roll out Windows 10 and turn on Device Guard, the shit is going to hit the fan. You'd better have already worked out the proper preparations with *all* the software developers in your user base -- not just the IT department -- to support their production software, or random pieces of your mission-critical software are just going to stop working one day, and an angry CxO is going to want to know why IT broke their systems.

If some of the IT departments I've had to tangle with in the past were doing their jobs correctly, anyone doing software development -- whether an "official" part of the IT department or not -- would be able to easily obtain local admin rights on their workstation.

If they were doing their jobs correctly, it wouldn't take 2-3 years to develop, test and deploy a simple productivity enhancement or workflow automation solution that might take 40-80 hours to actually code, and maybe another 100 hours to design, test and document. Not to mention, anyone who's actually gone through the whole 2-3 year lifecycle often ends up paying way more than they wanted to, for a way over-engineered solution that tries to solve every problem anyone's ever had, instead of just solving the problem at hand.

Also, IT departments never have any free bandwidth for new requests, which is why it takes at least a year for them to even start looking at a problem someone comes to them with. This is not entirely their fault: the CFO will often demand the IT director to keep all of their staff 100% utilized on required projects, so if the IT director tried to keep some staff semi-available for new requests that come in, the CFO would just reduce their head count until they had just enough people to work the projects that are already in development.

I'm not saying *all* IT Administrators do their jobs poorly or take too long to get things done. I'm saying that the processes and bureaucracy in place -- which, let's face it, most of the IT folks hate just as much as their "customers" -- make the IT organization very inefficient for handling anything that needs a quick turnaround. They are good for managing general use computer rollout with bog standard Office software and Internet access. Beyond that, if a manager or director wants something different, and they want it done *this* year, they are probably going to have to hire their own software folks, interns, or tap internal talent of people who happen to know software development (whether or not it's in their job description). At that point, they've just created a Shadow IT organization.

My point is that Shadow IT isn't a bad thing if the people working it know what they're doing, and can avoid pitfalls like downloading malware, pirating commercial software, etc. One good way to go about it is to develop your solution in an open source environment (e.g. Java, a GCC language, Ruby, etc.) and to only pull in third-party libraries that are MIT-licensed. It's very, very hard to run afoul of the three-clause BSD license or MIT license; you just create a LICENSE.txt that fulfills the attribution obligations, and off you go.

This "Device Guard" feature, as I understand it, will actively block non-administrators from being able to compile and run their own executable code, or to install third-party software or runtimes that might enable the same. They then have one of two options: either talk to IT, or try to get around it by using runtimes that already exist on the computer.

If they try to talk to IT, chances are good that IT will ask that the entire shadow IT project be canceled, and that they be allowed to develop (or buy, COTS) the solution themselves. Once you're in that trap, you automatically know it's going to take 2 years at a minimum. The project you're working on may not even be relevant that far down the road. If you don't agree to letting them work it into their pipeline, then they likely won't agree to give you admin rights. These talks very rarely go over well, unless you're in a very progressive company; but if you were, you'd probably have admin rights in the first place, or at least a separate computer or VM with a sandboxed subnet without access to any sensitive stuff on the LAN, where you have full admin rights.

This is why shadow IT organizations often just choose to write their stuff in VBA or VBScript. Java is usually a viable option too, but if you need native libraries or any third-party components that need native libraries, you're probably out of luck with this new Device Guard technology.

You can call shadow IT the "worst of the worst users", but just remember that there are many of us out there in the wild who get things done, on time and with a razor-thin budget. Without us, the daily operations of large enterprises and governments would be even more inefficient and dysfunctional than they already are.

Not sure what you're on about with the intelligence thing, though. It's really not about intelligence. Shadow IT folks are often *not* particularly intelligent. We're just at the right place, at the right time, with the right skills to solve a problem. The "official" IT organizations, on the other hand, traditionally have too much bureaucracy to be agile enough to do the same. That's all.

This is true for home users, but anyone connected to an enterprise domain who doesn't work for the help desk probably knows the pain of not having an administrator account. Even people who fall under the auspices of "IT" often don't have administrator accounts, if they aren't part of the team that holds the keys to the castle.

I know many software engineers who don't have admin rights on their PCs. It'll be interesting to see the tug of war over this, between paranoid IT guys and the rest of the people who are just trying to get their work done, whether by installing third-party software, or by compiling executable code themselves.

When Corporate America IT organizations start deploying this with Windows 10 rollouts in, oh, 2020 or so, a whole slew of things that are necessary to keep companies operational are just going to stop working.

IT "administrators" will be unable to resist the temptation to enable this "feature", surmising that any user running an .exe that wasn't signed by a shortlist of vendors must be doing something illegal.

So that business process automation workflow that saves thousands of hours every year? It depends on, say, Ruby, or 7-zip .exes. Poof; gone.

How about that little Office add-in that the CFO really likes because he can rubber stamp all the incoming requests in one batch? Well, it'll probably block .dlls too, so that's gone.

That customer deliverable that people have been pulling 16 hour shifts to get done, which is due tomorrow? It depends on a complicated .NET app written in C# using heavy Excel automation. Now they have to rewrite it in VBA, or maybe your deliverable just won't get delivered.

This is bad, bad news for the skunkworks that keep the world spinning. Better start rewriting everything in Java (make sure it's compatible with the ancient version of Java that comes preinstalled on every system) and calling into native land via JNA. Uhh, provided that Windows will let you dynamically load the JNA .dll into the Java process, that is...

Actually, that probably won't work because of the aforementioned JNA .dll. Let's just rewrite everything in VBA forever and ship our "applications" as Word documents. Who needs proper threading or actually good performance, anyway?

Admittedly, Brad Paisley is the (credited) author of this song, but Shatner spoke the words. Maybe he should listen to the track again.

"I'd love to help the world and all its problems
But I'm an entertainer, and that's all
So the next time there's an asteroid or a natural disaster
I'm flattered that you thought of me
But I'm not the one to call"

I think drought qualifies as a natural disaster. Why the change of heart, Mr. Shatner?

I use the "compact" version of this with a TrackPoint (no Trackpad). I love it and swear by it. I even have the Bluetooth variant for when I'm on the go. It's so much easier to mouse when the mouse is in the center of the keyboard.

Slot? This is a consumer device. It's not user serviceable. The SSD is probably either soldered in, or behind so much glue that you'll never be able to put the thing back together again properly once you install the replacement.

You seem to take it for granted that the changes made to Firefox were universally bad for all users, and that everyone hates them.

As a regular user of Firefox on multiple platforms (Android, Fedora, and Windows), I have no problem with the changes they have made. I like the customization of the new menus and I like my tabs on top (though I could of course revert back to the old way if I wanted to, because they made it customizable and configurable). Almost everything they've done with Firefox from the 3.x releases up to the latest stable has been a net positive change for me, even when I've occasionally scratched my head at questionable decisions. Even their choices to completely disable certain broken websites have turned out for the better, because in every case where I've had such a broken website that I depended upon, the developers have come around to fixing the problem instead of making people run IE 6 or a patched browser that's deliberately insecure.

The UI changes are not what is killing Firefox. The disruptive security policy enhancements that break sites are not what is killing Firefox.

What's killing Firefox is the critical mass of Google Chrome, because it's being pre-loaded onto PCs out of the shop; is much faster for general use (faster page rendering and startup, so don't give me JS benchmark results), and more compatible with more sites. There is huge word of mouth support for Chrome among Joe User type people now -- people who swore by IE just a couple years ago. There's also Chrome's app store, which is causing many third party devs to release stuff that only supports Chrome, leaving competitors in the dust. Firefox may be able to match Chrome in some limited respect in some of these things, but they simply don't have the same word of mouth support that Chrome does among the vast majority of users. Oh, and it's the default browser on the mobile OS with the largest installed base in the world (since ICS anyway).

Rather than Firefox being especially bad in any particular way (except for its abysmal startup time on mechanical hard drives when the files aren't in page cache), it's pretty much just that Chrome is better for your regular user who doesn't care about privacy, just functionality and speed. They are losing to a superior competitor. Even though they are accelerating the rate at which Firefox is getting better, Chrome is accelerating way faster than they can muster.

Nope. On my desktop at home with an i7-3770K and 32 GB of RAM, maybe. On my phone or my work computer, not a chance.

With an i5-2520M, 8 GB of RAM, a Samsung 850 Pro 1 TB SSD, a 10 Mbps internet connection (shared among a handful of users), integrated graphics, and Chrome 41, pages on Dice websites with Adblock disabled take about 10 to 35 seconds to finish loading and be responsive to scrolling, with much of that time dedicated to parsing all the scripts and elements on the page and loading them into the GPU (as semi-scientifically evidenced by pegged CPU usage in the task manager, the whirring of the CPU/GPU fans, the extremely low render framerate judged by the responsiveness of scrolling, and the time it takes to see the entire page loaded).

With uBlock enabled, that drops to 3 to 5 seconds, with most of that time spent in the network stack actually downloading the non-ad resources on the page, and very little time spent on rendering and parsing. And that's not even with NoScript on -- all the functionality of the site except for the ads is being loaded and executed.

The difference is significantly less on my beastly desktop at home, but if you're going to say that everyone should always use beastly desktops or not bother using the web, I'd like you to tell that to my employer so they'll buy me a $3000 laptop.

Because it costs me more than .000007 cents' worth of my time to twiddle my thumbs while the advertisement payload downloads from the Internet and loads into my browser.

The Internet is for porn. It's universally accepted, so therefore it must be true!

Now all libraries are getting bumped way down on the page rankings because they claim in their "About Us" page, something along the lines of, the Internet is a place for gaining knowledge, communicating ideas, etc. etc.

I guess "armor" would help to a certain extent depending on the circumstances, but remember, the relative velocity between a satellite and a tiny piece of space debris can *far* exceed the velocity of a bullet on impact down here in the thick part of the atmosphere, because you don't have all that drag.

A piece of space debris the size of a fingernail can cause as much destruction in space as a bullet in atmosphere that's many times heavier. I don't think our materials science can produce materials strong enough to withstand the impact of even a small actual bullet (or other matter of equivalent mass) traveling at a typical orbital relative velocity.

Question to those of you with some knowledge of how satellites are set up, where they're put in orbit, probable trajectory, etc., keeping in mind that my "knowledge" of orbital mechanics is only slightly more sophisticated than an enthusiastic player of Kerbal Space Program:

Is the space junk created by this explosion likely to remain around for a very long time (on the human lifespan timescale), or are we looking at a high probability that most/all of the debris will reenter the atmosphere and burn up some time soon?

If we assume a uniform distribution of debris exploding from a point within the satellite's center of mass, a "sphere" of debris would get created, where some of it would receive a fairly large push down toward the atmosphere and likely reenter very soon... what about the pieces that were given a large delta-v *away* from the atmosphere? What'll happen to those pieces?

It absolutely is.

Software fragmentation at a high level hasn't been all that scary of a specter for Android yet. Hook into a few core APIs that pretty much work everywhere, and off you go. There haven't been any successful whole-system Android forks that have been able to challenge mainline Android with any semblance of significance in market share.

The problem is in the details of the hardware, and to a lesser degree, software implementations. Screen resolutions; GPU capabilities; the difference in performance between the slowest and fastest (non-obsolete) device on the market; highly variable amounts of storage, VRAM, network bandwidth; limited vs unlimited data plans; the amount of other crap (that may interference) that the user or manufacturer has already installed on their phone; etc. etc.

A lot of devs are starting to whitelist their apps for specific phones, or at least for specific SoC make/model/generations. Your OpenGL fragment shader may run fine on a Qualcomm Snapdragon platform with an Adreno GPU, but crash the app or the whole system on ARM Mali. Your game may get 30-60 FPS reliably on a modern Tegra GPU, but deliver a slideshow on a Droid Mini from late 2013.

And that brings me to my second point: the hardware advances too quickly. A lot of people expect their smartphone to last them 4 years, maybe longer. But if you look at how far phone specs have come since 2010, it's pretty ridiculous. Most 2014 Android games and even non-trivial business apps won't even *launch* on a phone with specs 1/10th as capable as the state of the art.

These problems are hard enough to solve on their own. Most devs don't even have time to think about supporting other core systems with forks or replacements of the core Android APIs.