Ironic choice of example given that the Chernobyl disaster was literally caused by people executing a test:

During a hurried late night power-failure stress test, in which safety systems were deliberately turned off, a combination of inherent reactor design flaws, together with the reactor operators arranging the core in a manner contrary to the checklist for the stress test, eventually resulted in uncontrolled reaction conditions[.]

+1 and it works on OS X as well.

Cool! Thanks for pointing that out. (edits: grammar)

My one qualm with entr is how it deals with new files. It should handle that itself, not require calling it in a loop.

Not just JavaScript frontend frameworks, but an entirely new numbering system. The number that is currently between 44 and 46 shouldn’t have to even be considered by anyone.

The footnote seems important here:

1. Let’s face the truth: What I really wanted, was experimenting with this syscall. Docker images are more of a (good) pretext.

I’m sure they will get the fixes in and this laptop will be running Linux great out-of-box.

Are they likely to do that? As you say it would be great if I could just format with a 2016 Linux distro and everything just worked. I’m not a Linux compiling sort though, so I won’t be buying one at the moment.

Agreed. To me, though, the major difference between this and some of the efforts we saw from Dell and others five or ten years back (plus the “Linux on netbooks” debacle) is that the hardware support is being added to the kernel. Being pretty hopeful about this laptop, I was heartened to see that the fixes were all kernel commits, not weird binary blobs or some custom distro I end up locked into.

Ooph, indeed. I was hoping they’d have ironed out all the major issues before releasing the Linux edition. I really liked the previous Linux model, though, and will definitely get the new one, but I’d rather wait a month or two instead of spending the nights patching my kernel.

Kind of all the same caveat: the touchpad is simply too awesome for older kernels to handle it. :)

:-) The first thing I did after reading the introduction was instinctively google to see if there was an org-exporter for it.

I see org being the standard for notes and documents of Emacs users, but Markdown is the de facto standard for lightweight markup on forums, like right here.

I’m still a bit mad every time I write bbcode though. Or MediaWiki’s pre-Markdown but not quite markup.

This would simplify my life a great deal.

Some of us can’t use emacs, for various reasons, the most important being fear of RSI, frankly.

Perhaps because many of your filesystem directories are merely ephemeral staging areas for files whose true existence is in a loosely-connected web of Git repositories, eternally recording their history and backing them up around the globe, and so the actual most important thing to know about those files is whether they contain changes that might be accidentally lost.

Odd, it seems most commenters so far have never pretty formatted their own custom git aliases or added git status/branch to their shell prompt. And power tools like glances? Real users eschew even top and cat /proc directly! </sarcasm>

The block and hard link counts is great. More transparency into my files and filesystem is welcome!

I looked through the code; the git integration is completely optional. Everything git-related is guarded with a feature flag, so you can disable it at compile time if you don’t like it: https://github.com/ogham/exa/blob/master/src/dir.rs#L81

This is the part of the essay that made me laugh out loud. Why should Google care that anyone thinks they squandered an opportunity? It’s their time and resources and they are free to waste them however they like.

People who take issue with this seem to be implying that something terrible has happened because some people at Google didn’t agree with a particular definition of “good”. As if all those smart people wasting their energy on creating Go should be better directed creating something they don’t personally love but would be more pleasing to the writer.

The existence of one language does not harm or hinder any others, so I really do have to laugh when people shake their heads at the terrible waste.

Their setup is less insane than most (at least they don’t have all the plaintext data on their server locally, and use unique per-user keys). Many issues remain, like the fact that most SMTP traffic is not end-to-end encrypted, so mail comes in and often goes out in plain text. So even if the transport protocol is probably encrypted (TLS), every mail server in the delivery chain can intercept or modify the data.

The point in the article you linked though, is not entirely applicable here. They’re not trying to replace TLS/SSL with JavaScript client-side encryption. They’re just trying to encrypt/decrypt some data in Javascript. Their Javascript and probably encrypted emails are still channeled through an authenticated HTTPS connection.

Their client-side crypto is an additional layer on top of HTTPS, which provides something HTTPS does not: the fact that the server side must not know the plaintext of the payload data.

There is still a need to provide some kind of authentication for the Javascript library which is doing the decrypting/encrypting, and all code calling into that library, and I’m not sure how or if they will provide this. Is there a way to sign Javascript and warn the user about updates to such code?

Not necessarily true. If you are familiar with crypto primitives you can make well designed schemes to achieve what this article describes. I would prefer that the tone was “learn about crypto because it has real world use” rather than “look this stuff is easy,” because it’s not easy.

The author uses simple examples, a fixed number of required fields. If you stick to that, it’s pretty easy to get right, and still really useful.

The behavior described in the article didn’t seem very “monadic” to me either. Swallowing errors appears to be the opposite of what Monads are about - treating side effects explicitly. That said, I can definitely see the benefit of this behavior in certain cases, for example when it matters more to make something work than to make it correct.

Objective-C’s bottom propagation seems to work really well; perhaps it’s a cultural and not a technical distinction?

You’re absolutely right that implicit handling of nil can cause errors to be detected further from their causes–but the same is true of currying, which allows type errors to arise from widely separated parts of a program. Different languages have different habits around these kinds of convenience/safety tradeoffs.

FWIW, I find Clojure’s nil handling generally more convenient than a hindrance–functions which define nil often serve as their own base case in recursive algorithms, for example, which reduces the need for explicit branching. This is especially helpful when building up maps! And while I agree that Clojure’s default nil behaviors can make it easier to make mistakes, core.typed is quite effective at preventing NPEs when you want that degree of safety.