I know I'll get flamed for saying this, but it seems to me that the Shellshock bug represents a weakness in the Unix philosophy. On Windows, if a similar issue happened with cmd.exe or PowerShell, it would have only a limited effect, because the Windows shell is basically just an administration tool, and no one in their right mind would use it to pass untrusted input of any sort. In contrast, "the Unix way" encourages piping of shell commands to other shell commands, and the use of shelling out as a substitute for proper APIs. To me as a Windows power user, the idea that a basic feature like DHCP is using a shell script behind the scenes seems crazy. The better way to write re-usable code is to do the C/C++ API first, then build both the command line and GUI tools on top of that API. "The Unix way" is a clumsy hack in comparison – and it leaves the shell as a security-critical single point of failure.

Another way to think of it is that Linux is now dealing with an issue that Windows has been struggling with for over a decade: how to fix inherently insecure design decisions without breaking compatibility with a million different legacy applications in the process. Maybe they'll need to implement the equivalent of "UAC" whenever a program tries to shell out?

I actually find myself liking google keep. I wanted a simple thing to make quick on-the-fly lists/notes.. and it delivers.

Google Keep is nice. Sucks that there's no public API, though.

Obviously, people doing low-level systems programming do need to have the background to understand this stuff. But that doesn't really matter – there are a hundred application programmers for every systems programmer. It's like saying all programmers need to be able to write in assembly and count cycles, just because some embedded work still requires that sort of stuff.

Most coders don't actually program. They just write some lines of code that connect libraries together. They wouldn't know where to even begin if asked to write the libraries themselves, or write the networking protocols, or the operating system, or the compilers, or the GUI frameworks, or the browser, or even a simple scripting language.

Converting business requirements into executable processes that a computer can understand is programming, regardless of what language or API is used. There's nothing noble about re-inventing the wheel just to prove you can do it; it's just stupid and inefficient.

More to the point, organizations don't care about hiring well-rounded Renaissance Men. They want people who can get a specific job done. Whether that job satisfies non-customers in some far-off ivory tower is completely irrelevant.

But someone who can code AND knows the theory is better than some stupid code-only monkey anyday.

It's true that "pure" coding is becoming less valuable, but that doesn't mean that Comp Sci skills are your only way (or even the best way) out of that niche. Being able to understand business requirements and translate them into functional products is a lot more important than understanding five different sort algorithms that you'll never use (since the API handles all that crap for you).

There's plenty of blame to go around on both sides here.

The motherboard manufacturers – pretty much all of them – are to blame for developing and shipping really crappy firmware. (Unfortunately, this is pretty much par for the course – 95% of all firmware is crap, no matter what it's for. Modern hardware companies, with a few obvious exceptions like Apple, just don't do software very well at all.)

The Linux kernel devs are to blame for being stubborn about "standards-compliance" versus the real world. From what I can tell in clicking through a few links, the ACPM feature was working in the past, but the kernel devs then deliberately broke it by changing it to only work if the BIOS advertises it properly. Yes, the standard says that's what is supposed to happen. But we know from experience that manufacturers often don't follow standards. Linux needs to deal with the world as it is, not as the devs wish it would be.

Nope. A website that has to hook into a bunch of poorly maintained, poorly documented databases. That's the hard part.

This kind of crap is par for the course. I've had to figure out poorly designed databases without documentation, and it didn't cost millions of dollars to do that. Admittedly, insurance company big iron is probably much hairier to deal with than what I'm used to... but $240 million worth? Sorry, I just don't see how this adds up.

The real problem here is that Europe hasn't given the vacuum cleaners enough R&D time to make more efficient vacuums; should have been a ban for 2018+ not 2014.

Why not just use the same designs that are currently sold in the United States? As others have noted, we're pretty much limited to 1600W already, because of the maximum capacity of standard household circuits (120V/15A).

You need properly trained and aware users

In other words, we're doomed.

One major problem with security is that the permission model on both Windows and Unix doesn't really give you the tools you need to keep yourself safe. We're still stuck in the 1970s university mentality where the user is assumed to have written or at least compiled the program themselves, and is supposed to have a good understanding of what it does. The program is assumed to be operating as an agent of the user, so it inherits all the user's permissions. On modern systems, with semi-trusted and untrusted code downloaded from the Internet, this assumption is absurd and dangerous.

Rather than the program inheriting the user's permissions by default, a decent modern security model would instead restrict it to a sandbox unless it was explicitly given permission to get out – and even then the user should be given veto power over specific sandbox breaches. (Android used to work like this, but Google dumbed it down for reasons that are not clear.)

By default, a program should only be able to do the following:

• * Get input from the keyboard and mouse (only when the application has focus)
• * Get input from game controllers (even if the application doesn't have focus)
• * Output video and sound using the normal system APIs
• * Read/write temporary files to a scratch directory
• * Open and save files only through standard system dialog boxes that are under the OS's control

Anything else – Internet access, ability to freely read and write to files/folders, ability to get keyboard input when not in focus – should require explicit user permission. And the user should have the option of unchecking any or all of these authorizations and continuing to run the app without it being able to do those things. These permissions should be as fine-grained as possible, so an application could have permission to only read certain specific folders, or could be allowed to access the Internet only through a particular API (say, for handling registration or online high scores) and only for certain domains.

It was tied to the operating system, unnecessarily. The browser has exactly zilch to do with the operating system. ActiveX controls, tying versions of the browser with versions of the OS, varying behaviour of same browser version on different OS versions etc. If IE is renamed, it should be delinked from the OS like other browsers.

I agree that tying versions of IE to specific versions of Windows was a really bad idea. Many web developers are still stuck with supporting IE8 because it is the latest version that runs on XP, and many users (and even companies) still haven't upgraded. This has clearly retarded the adoption of modern technologies like canvas and SVG support, which is a serious problem.

But at this point you really can't fully remove IE from Windows without breaking stuff. Sure, you can use the uninstall option to remove iexplore.exe (and newer versions of Windows let you do that), but if the back-end components like mshtml.dll were also removed, then a non-negligible amount of existing software would break. Since backward compatibility is really Microsoft's strongest selling point, this is a non-starter. Don't forget that Microsoft Help files also use HTML, so the Trident rendering engine is needed to view them. You could argue that this is unnecessary tying, but I'm not sure a custom proprietary format would really have been a better choice than HTML for help files – it seems a fairly sensible choice.

I never understood why drivers had to be on the kernel ring anyway. Every single peripheral (GPU, sound card, etc.) driver I've ever encountered has had a history of stability problems. You'd think the largest point of failure on the computer could be moved to userland and restarted when necessary.

Audio drivers were moved to user mode starting with Windows Vista. (That's why DirectSound 3D is no longer supported.) Video drivers, however, pretty much have to be in the kernel for performance reasons.

How is this not a violation of the Computer Fraud and Abuse Act (CFAA)? They bypassed security measures (deletion) to access someone else's personal information without authorization. Given how broadly this has been interpreted in the past (Andrew Auernheimer was prosecuted for visiting public URLs on the Internet), Avast's act clearly should be considered a violation. Or is this a case of "if a corporation does it, it is not illegal"?

Bringing back an actual Start menu is an important part of what needs to be fixed, but it's not the only thing. Windows 8, with its solid color design, looks flat and ugly compared to Windows 7 with Aero. Even if they plan to stick with the more spartan look, they should at least bring back frame translucency. (There is an add-on for Windows 8 that can do this, but it's still in beta and requires installation by hacking AppInit_DLL.) And the centered window titles are even more annoying. From Windows 95 onward, the title has always been left-justified. That's where my eyes are used to looking for it, and have been for nearly 20 years. Windows 8 moved it to the center because some graphics designer thought it looks cool, but this completely breaks my eye-tracking, wasting a few seconds here and there while I go hunting for the title that's not where my muscle memory says it should be. I don't care if they expose this in the UI, but there should at least be a registry key to fix that.

There are laws governing obtaining informed consent from humans before performing psychological experiments on them.

That only applies to federally funded research (which means almost all colleges and universities). Attempting to apply this to the private sector would raise serious First Amendment questions. What one person calls "psychological experiments", another might call "protected free speech".