And no matter what the charter is, if they are liquidated the court will sell all of your data to the highest bidder to pay off creditors.

That is true if the user data is considered part of the bankruptcy estate. But that won't necessarily be the case. Under US law, everyone automatically has copyright for anything they write or compose. If the primary concern is to protect user privacy, the user agreement for the site could stipulate that users retain copyright to all their data, and the site has a nonexclusive, nontransferrable license to use that data so long as they adhere to the privacy terms. In the case of bankruptcy, the only "asset" would be the nontransferrable license – not the data itself, which would still belong to the end users.

I expect issues like this to come up once a few mid-size or large cloud providers go broke. I don't think the courts are going to allow the creditors to seize data assets belonging to customers in these instances.

If your process involves generating Office, documents, it's generally the easiest way. The server automation tools for generation of Office documents are basically scripts and wrappers around.... Office. So if you want to generate some report that spits out an Excel file at the end, you can bet it was generated in Excel the first time around because the reporting tool actually called Excel to fill in the fields.

This may have been correct 5 to 10 years ago, but you should never do this in a modern installation if you can possibly help it. Microsoft's official position is that "Microsoft does not recommend or support server-side Automation of Office."

You should be using the Open XML SDK to create Office documents in your web application. The default classes and methods are somewhat opaque, but fortunately, there are a lot of helper toolkits that run on top of OOXML SDK to make things much easier. I used Simple OOXML, which hasn't been updated for a while and has limited documentation, but works pretty well, and is free. These solutions are not only much more robust in a server-side situation, but you don't have to devote an Office license to the server.

This is going to be a real problem with embedded systems. At my last workplace, we had coin/bill vending units hooked up to PCs, which were connected using a FTDI serial-to-USB connection. I think the chip was legit – but how would I be able to tell? We purchased these vending units from a manufacturer, which in turn, I'm sure, bought the serial-to-USB chips (or even pre-made boards) from another vendor. What if that other vendor used clone chips without telling anyone?

And yes, we did occasionally install FTDI driver updates on these. If one of these units were to be bricked, FTDI is going to be open to some very substantial lawsuits. Arguing "unclean hands" won't work when the people getting hurt are about four steps removed from any actual culpability.

Not going to happen, the same way that it didn't happen when DirectTV (or dish, whoever) bricked all of those pirate hardware years ago

No claims were made in that case because anyone who came forward would have to admit committing a federal crime. In contrast, there are plenty of ways that someone could wind up with a bricked device that they had no knowledge was not authentic, and could not reasonably have known.

I actually like the Ribbon in Office, because the Office apps have so many features that regular menus/toolbars hinder discoverability. (I suppose I might feel differently if I had invested a lot of time into memorizing the Office 2003 menus, but I didn't.) On most other applications, Ribbon is overkill, taking up too much space (and vertical space is especially precious on widescreens).

Maybe I am wrong, but over the years I have noted an increasing condescendension of IT people over "mere users". I wonder why that is. Bear in mind that IT typically isn't the company's cash cow, but "overhead", making this condescension rather inappropriate imho.

All this is the sign of a poorly run organization with excessive siloing. IT should be working with other departments, helping to streamline and automate their processes, making other people's jobs easier and less tedious. If people think of IT as "the computer janitors", your organization is throwing away a tremendous amount of potential productivity. It's bad for morale on both sides, too.

I wonder when Microsoft will learn that a lot of us would rather use our CPU and GPU cycles for something other than eye candy? While computers can be used for fun purposes, we shouldn't all be left with the feel that what we have is little more than a technotoy.

Windows has always offered the option to turn off animations. (System Properties -> Advanced System Settings -> Performance gives a bunch of checkboxes for this on both Win7 and Win10.) Flip it around: why shouldn't those of us with good mid-range or high-end desktops be able to use a small portion of our CPU and GPU power to make things look nicer? Why should we be hamstrung to what the crappiest tablet with a half-dead battery can handle?

This is a good start (assuming you can turn these animations off if you don't like them). Hopefully they'll bring back Aero Glass-style transparency soon.

There are also a lot more substantive flaws that need to be addressed. The Start menu (which is Win10's big selling point!) doesn't currently do DPI scaling properly. It's disappointing enough to see this flaw with third-party software, but for a core part of the OS, it's inexcusable. And there is still no way to remove the obtrusive Search and Task View icons from the taskbar. (Both of these issues have hundreds of votes on Feedback; hopefully they will be addressed.)

There are also a bunch of smaller annoyances – unlike in Win7, I can't get the useless "Homegroup" option to disappear from the left panel of File Explorer, even if I leave all homegroups completely. They also shove OneDrive down your throat. And if I rename "This PC" back to "My Computer", it displays under my preferred name in most places, but not in the tile half of the Start menu – it appears fine in the left-hand list portion, but the tile always says "This PC" no matter what it has been renamed to.

There are some encouraging signs, but this is definitely an alpha-class release in my experience. Glad I installed it in a VM.

But all that means is that the user sees a yellow splat in the system tray. Not really a big deal. You can still actually access the Internet on Windows even if NCSI thinks it's down. The Belkin issue is a much bigger deal.

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.