Plus, most of these sprays contain benzalkonium chloride as a preservative, and that stuff can cause its own problems.

I've been running Fedora on mine for a few months. I had some early problems with wireless, but on my most recent trip (a few kernel updates later) it was fine. The touchpad seems to be working better too. My only real gripe at this point is that the battery doesn't quite last all day like my 13" MBA can, but then the Zenbook's considerably cheaper than most in the under-three-pound category so I guess sacrifices had to be made somewhere.

Yes, there is such a law. 40 CFR 86.1809-10 - Prohibition of defeat devices. So much for the "if it's legal it's wonderful" pseudo-argument.

It's because they throw out a lot of POSIX features/requirements - e.g. nested directories, rename, links, durability/consistency guarantees. In other areas, such as permissions, they have their own POSIX-incompatible alternatives. These shortcuts do make implementation easier, allowing a stronger focus on pure scalability. The theory is that the combined complexity of POSIX semantics and dealing with high scale (including issues such as performance and fault handling) is just too much, and it becomes an either/or situation. As a member of the GlusterFS team, I strongly disagree. My colleagues, including those on the Ceph team, probably do as well. The semantics of object stores like S3 have been designed to make their own developers' lives easier, and to hell with the users.

Not all POSIX features are necessary. Some are outdated, poorly specified, or truly too cumbersome to live. On the other hand, the object-store feature set is *too* small. I've seen too many users start with an object store, then slowly reimplement much of what's missing themselves. The result is a horde of slow, buggy, incompatible implementations of functionality that should be natively provided by the underlying storage. That's a pretty lousy situation even before we start to talk about being able to share files/objects with any kind of sane semantics. You want to write a file on one machine, send a message to another machine, and be sure they'll read what you just wrote? Yeah, you can do that, but the techniques you'll have to use are the same ones that are already inside your distributed object store. Even if both their implementation and yours are done well, the duplication will be disastrous for both performance and fault handling. It would be *far* better to enhance object stores than to keep making those mistakes . . . or you could just deploy a distributed file system and use the appropriate subset of the functionality that's already built in.

A semantically-rich object store like Ceph's RADOS can be a wonderful thing, but the dumbed-down kind is a disgrace.

That is very untrue. I'm on the GlusterFS team, and we've had users providing "POSIX style FS access in a cloud-like environment" for years. Amazon recently started doing the same with EFS, and there are others. It's sure not easy, I wouldn't say any of the alternatives have all of the isolation or ease of use that they should, but it's certainly possible.

Tis better to be mauled by a single bull than trampled by a herd of sheep.

I've been around bulls and I've been around sheep. The odds of survival aren't what you think.

Only a misanthrope who's also somewhere within the BPD/NPD complex would have gotten so upset over that distinction.

Below the line are languages that are more popular on GitHub. Above the line are languages that are more popular on Sewer Overflow. There's a distinct difference. The "GH" languages tend to be systems languages (Go/Rust/D) and CS favorites (Haskell/OCaml/Erlang). The "SO" languages tend to be more lightweight and application-specific - Visual Basic, Matlab, ColdFusion. "Assembly" seems to be an outlier, but other than that the pattern seems pretty consistent. Conclusions about the audiences for the two sites are best left as an exercise for the reader.

If you think weather forecasting is easy, let's see some of your forecasts. A forecast which has been substantially correct for New England and merely didn't extend as far south as had been expected only underscores the difficulty of the exercise. Occam's Razor suggests that no cause beyond "honest mistake" need be posited. I know some people like to take every opportunity to prattle on about government overreach, but you're *really* stretching that fabric too thin this time. Get a grip.

So, from "this isn't to say that we should throw intelligence out" you conclude that they want to throw intelligence out? Truly, you have a dizzying intellect. I can see that you enjoy playing "devil's advocate" (to use the more polite term) but when you have to try so hard that you make yourself look ridiculous maybe it's time to find a new game.

What Poropat, Duckworth, and others suggest is that multiple traits - including "grit" - contribute to success. He even provides evidence to back up that hardly-surprising conclusion. So how does Kohn respond? By immediately projecting a "one trait uber alles" mentality onto the grit proponents. To be even more clear, he's attributing to them exactly the idea they're trying to refute. Then he cherry-picks examples of excessive persistence leads to adverse outcomes, ignoring the issue of whether those outcomes would be likely to occur in people who had developed other traits such as curiosity and openness. In the end he only demonstrates further the problems with any single-trait theory of learning, supporting exactly the point he meant to oppose.

Maybe his parents or teachers should have helped Kohn develop some more of those other traits. Like honesty.

I agree with the first part of your comment, and came here to say almost the same thing. The law of unintended consequences strikes again.

The second part makes you seem like a moron. Seriously, losing access to your e-toy for a minute or two is worth killing over? Get a grip.

About five years ago, I was involved in the installation of a thousand-node cluster in Boulder. We knew *before we went in* that we needed to change our EDAC (memory error correction) code to account for the higher rate of bit-flips due to the altitude. Some of the people we were working with had been there when those same problems nearly caused a months-long delay in a larger installation at NCAR nearby. We ended up running into a more subtle problem involving lower air density, heat and voltage, but *this* problem was incredibly old news even then.

Good point. In fact, what made me think of mentioning Adventure is that I'm hacking on Adventure 2.5 (a.k.a. 550) to make it playable with my daughter. I've already added code to work around one build error, modified some of the game logic having to do with save/restore annoyances, and found one crash if you "say" something too long. The point is that all of this is happening in Linux, based on code that was written well before Linux even existed. Surely there's a lesson there. Thanks for clarifying it.