OK, maybe "AI" should have been in quotes. If you're going by the Turing Test definition, then no we haven't. But a lot of people would consider Siri, Watson, etc. to be "AI", and the line is becoming increasingly fuzzy. The study presumably focused on the general public, so we need to use the general public's idea of what constitutes "AI".

54% *claim* to have never interacted with an AI. They probably have (at least indirectly), and just don't realize it.

I just learned recently that my employer uses an AI to vet expense reports for errors and potential fraud. I'd give decent odds that similar things are being done across the financial industry, even if it is not explicitly referred to as "AI".

While "clean up after yourself" is generally a good idea (ask your mom!), in this case it is going to cause a lot of problems because it is being enforced from above in ways that will have unintended consequences because the enforcement mechanism doesn't understand context. I am sure that screen/tmux aren't the only tools affected.

Heck, I implicitly rely on persistence of background processes myself on a semi-regular basis. Doing something that runs counter to this expectation is going to break random stuff, and result in a lot of pissed off sysadmins. This behavior arguably makes sense for desktop distros, but given that Debian is primarily a server distro it should not be the default. Let downstream desktop distros like Ubuntu/Mint/etc. modify the default behavior, if they deem it appropriate (it doesn't even require a code change, it is a config option).

It is also symptomatic of the "all bow down before systemd" mentality, and I have a big problem with that. They may have good intentions, but there are some serious issues with how they're going about implementing their vision.

Sure, Virgin is building a "millionaire thrill ride". I don't dispute that. But more broadly useful technical knowledge and expertise will still be gained in the process. Furthermore, the test pilots know the risks, and accept them willingly; I'm sure if Virgin asked for volunteers, there would be a long line of people (both qualified and not) lining up to test these things.

If you're going to criticize it for not doing enough to help us get to Mars, you might as well criticize any and all non-essential spending of any kind that doesn't help us get there. Or if you really want to look at the cost/benefit angle, should we not be prioritizing fixing the problems on this planet first, before we embark on the exceedingly expensive and dangerous endeavor of putting humans on another one (which, lest we forget, is extremely hostile to Earth-based life)? If we are (as the author seems to be) worried about a "dinosaur killer" asteroid event, we should put the money into figuring out how to detect and deflect incoming asteroids. Seems to me that would be much more cost-effective, and have higher odds of success than evacuating humanity to Mars.

They seem to be the only vendor of USB serial chips whose products seem to "just work" under the majority of use cases, on both Windows and Linux. Every time I have had a weird USB serial problem (on either OS), the solution has been to get a FTDI-based device. Problem solved.

If 3rd party vendors are illegally appropriating their IP, then they can go after those vendors in court. I also have no problem with them rigging their driver so that it does not work with "clone" products. But intentionally damaging devices they do not own steps over the line.

I do not think a boycott is the answer. Yes, they made a mistake with this driver update; but do you really want to (potentially) drive the designer of the best existing USB serial chip out of business? If we go that route, everyone loses.

I've been using Asus almost exclusively for roughly a decade. My initial reason for doing so was the fact that they continued to support ECC on their consumer AMD motherboards while other vendors did not.

Linux compatibility out-of-box has been so-so, but all issues I've encountered have been solvable. Ubuntu 10.04 had problems with the NIC, audio, and temperature/fan monitoring on the Asus M5A97 EVO; all issues were addressed via use of out-of-tree drivers, and with 12.04/14.04 everything "just works". Getting Linux to boot from a software RAID-1 array on the Asus M5A97 R2.0 was a pretty major PITA, but some of that came down to my own lack of familiarity with UEFI and GPT.

The fact that AMD hasn't released a new chipset for Socket AM3+ in a very long time actually has a silver lining for Linux users -- it means their chipset driver support in current distros is mature and stable.

I have no first-hand info about their Intel boards either, as I haven't built an Intel-based system since the age of the dinosaurs. A former co-worker built an Intel-based Debian system on an Asus motherboard a couple of years ago though, and I don't recall him having any real issues aside from the same audio codec problem I hit with the M5A97 EVO and Ubuntu 10.04.

Hmm... Microsoft behaving like a spastic bull in a china shop? Who would've thought it was possible...

All well and good that they're trying to fight the good fight against malware; but taking out millions of legitimate users as collateral damage is simply unacceptable. Somebody really botched this operation. I hope there's some sort of accountability (but I'm not going to hold my breath).

While C# may get you ahead in the business world, IMO you really need to go with something more OS-agnostic unless you're OK with limiting yourself to MS platforms. C++ (or Java... maybe) and OpenGL are the way to go IMO.

That's tough. If it is months, or even (a small number of) years, then there's hope. If it is on the bad side of "if ever" then the question needs to be asked: how likely is it that technology will be capable of giving her a quality of life that she is willing to accept? I have no idea what the legal ramifications are, but since she is obviously conscious and aware, in a sane world her wishes -- based on the best information available -- should take priority over all else.

If the undo/redo history is reliably saved, then yes I agree. But if the application is crashing often enough that you care about this, do you trust the undo/redo history to get saved properly along with the document?

Yeah, that was my initial thought too. But I've already come to terms with the fact that I'm ancient, so it didn't really bother me! ;-)

Agreed. Definitely a case of "please do what I asked for, not what you think I wanted". A properly implemented auto-save feature does not overwrite the original document; it saves a secondary copy, to be used only if the system crashes and you need to recover your edits.

...control-S (XOFF) was used to pause the scrolling on a "dumb" CRT terminal. I don't think I have ever used it to save a document.

Systems I care about (i.e. anything I use for "real work") are on UPSes. If the hardware or software is unstable enough that it crashes unexpectedly more often than once every couple of months (give or take), I fix/replace the hardware or start looking for alternative software to accomplish the same task.

First of all, my condolences. That is a terrible, terrible thing to have happen. I feel especially bad for your sister-in-law, as this is pretty much a worst-case scenario -- conscious and aware, but unable to do anything. The mere thought of being in that kind of state terrifies me.

The brain is quite resilient. Your idea of some sort of brainwave device may actually have some merit; the "biofeedback" craze of the 1970s and '80s demonstrated that you can train yourself to modify your own brainwaves (and other "involuntary" bodily functions), and people have been working on brainwave-based control devices ever since. I'm not sure what's currently out there, but perhaps a creative combination of off-the-shelf sensors and some hacked-together interfaces to a laptop or Raspberry Pi type device could yield some useful results.

If you don't mind telling, what is her prognosis for recovery? Is this believed to be a temporary, or (shudder) long-term/permanent condition? This will certainly affect how you will want to proceed.

If you're primarily focused on meeting the letter of "service level agreements", IMO you've already entered what I'll call "metrics hell" -- a desolate realm where meeting some (more likely than not) ill-conceived measure of "performance" takes precedence over actually helping your users get their jobs done more efficiently. Closing helpdesk tickets within some predefined timeframe is meaningless in the grand scheme of things if you haven't actually solved the users' problems.