So the model here seems to be, people coming out of near-death experiences have these memories, and while they're likely not "real", they're a record of some sequence of cognitive states, and the puzzle is, how can we detect these cognitive states? There seems to be an underlying assumption that the memories are a faithful chronological record of something, and the investigation is, what is the something -- what is the brain recording while it's apparently inert.

This may well be right, they seem to have good evidence of apparently-inert brains being not-so-inert, so at this point I suppose I'm quibbling.

But the part I have never understood about discussions of near-death experiences (IANAneurologist) is, why do so many of these stories assume that the memories people wake up with were created during the apparently-inert time? It's true that the memories are subjectively of long duration, people report that they remember spending a lot of time flying towards the light or conversing with the angels, but surely they can be sincere without being right.

We know a fair amount now about how memories can be manipulated, and how recollections depend on the environment -- memories are very slippery things. So, isn't it possible that, during the apparently-inert period of a near-death experience, the brain actually is inert, and not forming memories, and that at the time of recovery, during which there is plenty of obvious brain activity, the memories are all formed in a brief period, but with the subjective sense of having taken place over a longer period? This means the memories are basically wrong, but this seems to me to be a much lower bar to clear than requiring chronologically faithful memory construction in quiescent gray matter.

Any neurologists in the crowd care to comment?

They're completely unhackable!.

Soon they'll be mandatory in Enterprise deployments.

Well, in fairness, it was prepared for the Queen, not necessarily by the Queen. It was her advisers who imagined the solemn and awful duty falling to her.

Not only Yahoo's index, they're blocking indexing for Google and Bing also. Presumably via robots.txt or similar.

As you hint at, it's the libdvdcss capability that's the main problem under anti-circumvention provisions of the US DMCA.

You can get versions of VLC which only use FOSS and patent-unencumbered codecs. Debian used to (maybe still does, I haven't looked in a while) make this distinction pretty clear, the "main" packaged VLC was unencumbered, and you had to go outside the main package tree to get the other stuff.

So, in most practical installations, you're right, but it's not literally true that "VLC is illegal in the US."

So the article and summary hint at a common problem -- "the ministry has its own system for ... sharing documents", which "doesn't always function well outside of Japan". I've seen this in more than one enterprise, where the IT guys meet the need of users to securely move data around by buying or building a secure solution, and they pay very careful attention to the security, but less attention to the usability. Users will go for ease-of-use every time, and aren't thinking about security, so mistakes like this happen.

The obvious solution is to make the secure system easy to use, but usability itself is hard to get right, secure usability is very hard.

As a naturalized US citizen who actually took a small quiz on this, I am honor-bound to point out that the fine quotation you have provided is actually from the Declaration of Independence, and not the Constitution. While it certainly reflects the aspirations of the founders, and may well represent my or your best hopes, it's not actually the law of the land. The constitution is clearer about its jurisdiction.

Any host-based intrusion detection system will have a hash of the executable, and will report when it changes. This is not some new cutting-edge security precaution, it's routine for many, many installations.

Seriously, he's a lawyer, in what particular does he think the rejection is wrong?

  The nearest thing to a substantive accusation is that the examiner is simply rejecting the application because he's lazy and that's easy. But it's my understanding that, in fact, patent examiners face a lot of pressure to approve applications, which is faster and easier than rejection, because it takes less effort to justify approval, and because approvals don't generally get appealed by the applicant. So while I am sure laziness afflicts patent examiners from time to time, it's not obvious that this is an example.

As for "doing his job", his job is not to approve applications, it's to examine them and make a determination. Rejection is one possible outcome, and is not by itself proof that the job wasn't done.

So, yeah, faceless bureaucrats are lazy and stupid, ha ha. Tell me again what problem you solved by making this assertion?

I've been using it for a long time, too, it's a perfectly respectable choice, and if I had to use it for ten more years, that would be OK.

However, particularly for back-up systems, I am ready for snapshots and block-level deduplication. I tried to deploy something like this with XFS over LVM a few years ago, but discovered that the write performance of LVM snapshots degrades rapidly when there are a lot of them, and it helps a lot if you can guess the size in advance, which is hard. There's also a hard limit of 255 snapshots, but in our environment, performance became unacceptable before we got anywhere near that.

You're right that XFS "ain't broke", but I for one am ready for more features.

What you say is likely true for almost all users, but for server management, the network transparency features that come with server-client separation are a huge asset. My own "use-case" is that I frequently need to install commercial scientific software on remote headless systems, e.g. the head node of a computational cluster in the server room. These installers invariably have GUIs, which I use by SSH-ing into the box with a forwarded X connection and just running it.

There are other ways to do this, of course, you can use some kind of remote desktop scheme to accomplish the same goal, but you don't actually need the whole desktop, you really only need to operate the remote GUI on your existing local desktop. X can do this, Wayland (and Windows and Quartz) sacrifice this in order to have better local display performance.

I also worry that it's part of a general trend towards more monolithic software, and towards doing less in order to do it better. Unix (and Linux) were initially attractive to me because of their mind-set of having a good set of powerful, conceptually simple tools that I could chain together to accomplish my goals. Now, it seems like I'm seeing more and more conceptually complex, monolithic applications that are very, very good at solving the most frequent use case, but are somewhere between useless and harmful if you try something the developer didn't anticipate, because it's a niche requirement or a corner case. I'm starting to miss systems that worked in the corner cases.

FTFS: "Three serial interfaces are available via the expansion headers." So it's a connector and a few minutes of soldering.

Robert Zubrin, the "case for Mars" guy who seems to have thought a lot about months-long space journeys, believes that low-gravity bone loss can be mitigated by exercise. His data point is Shannon Lucid, who spent 179 days on the Mir space station, rigorously followed the prescribed exercise regime, and came back in significantly better physical condition than other members of her crew, who weren't as disciplined with their exercise regimes.

Even if he's wrong, this is a problem to be solved, rather than a reason not to try.

Seriously? Emergency medical technician, aka paramedic. The guy in the ambulance who does the cardio-pulmonary resuscitation.

Obligatory link.

It turns out this hypothetical scenario actually was too extreme, it was set much too far in the future...