correnos's comments

Iirc they've got a one-year timeout for updates, after which they'll make you sign in with a unifi web account in order to update. Deeply frustrating.

Personally I use the emacs android port with org-roam, with syncthing for sync to back home. I've got ctrl and meta mapped to volume up and down. I don't know that I'd call it a good way, but it works well enough for me :).

IMO this is a strong argument for proper threads over async: you can try and guess what will and won't block as an async framework dev, but you'll never fully match reality and you end up wasting resources when an executor blocks when you weren't expecting.

Agreed. Vermont, Maine, Alaska and Hawaii all ban billboards, and they're all nicer to drive in as a result.

So, "canonical" here means "for a given tree of data this is one unambiguous binary representation for it," which is a useful property for crypto signatures. It does not mean "this is a blessed way to write sexp's", though folks can be forgiven for not realizing that since the docs here don't say much about the when's or why's of use.

The docs could do a better job of spelling it out, but csexp's really do only represent "trees of bytestrings". They're not a particularly rich format. If you're looking for "transfer this lambda over the network" semantics that's obviously a lot more complicated, but there's at least some research-project Schemes that've done it. The one I know of is Termite Scheme, which builds an Erlang-style distributed process model.

The "suffix" there is a docs mistake. if you look at the example csexp's on the page the lengths are prefixed. I think that the csexp's of this package are compatible with Rivest's format.

An EMT friend described her take as, you need empathy in order to help people, but you need to be able to switch it off because sometimes what you're about to do is going to hurt them.

It's like any of our instinctual responses. Sometimes it helps, sometimes it's in the way.

Of the three compilers I've worked on in-depth, only one of them had a "normal" memory management scheme.

One of them was unburdened by any thought of freeing stuff, and relied entirely on the application exiting for cleanup. This was very convenient to work with, and never ended up posing an issue.

Another used a series of allocation arenas, where certain arenas would be cleared at certain points in the compiler pipeline. This made for both speedy alloc/freeing and avoided leaks, since you weren't at risk of "forgetting" a data structure. It was also a major headache to keep track of exactly what the longest lifetime of a long-lived datastructure might be, and to pick an arena that won't be cleared in the meantime. Unfortunately the programs compiled with this compiler were large enough that we certainly couldn't have gotten away with just leaking memory; we sometimes OOMed as-is!

The third used standard C++ memory management. This compiler was quite simple, and the vast majority of its data used stack-based lifetimes. For a more complex compiler this would've become a headache.

I think that all of these compilers chose the correct allocation strategy for what they were doing. "Good practices" aren't as universal as we might like to believe, they depend entirely on the context in which a tool is designed to operate. And yes, we can guard to some extent against that context changing, but for the most part that's why we keep getting paid.

I think parent was talking about navigation more than surveillance, so VORs and similar. Between that and inertial navigation, there's plenty of other location sources if your GPS receiver does fail.

Though if we're feeling pessimistic, we can guess at how a failure might occur. Let's say that your GPS receiver is poorly written enough that it just starts returning wrong location data on week rollover. Let's also say that that receiver is the aircraft's main time provider. Since the inertial navigation system also needs an accurate time source, it could be hooked up to this same time source. Hopefully it wouldn't be, but we're assuming the aircraft in question here is all-around subtly defective. The INS doesnt't include handling for bogus time jumps, so its speed and location tracking is also corrupted. So, you and your unfortunate copilot could find yourselves without your two main navigation sources a few hours into a trans-pacific flight, and assumedly the GPS-coupled autopilot had pointed you well off course before you'd noticed. In this situation you'd have to get yourselves reoriented based off your compass and best guess of a location. Hopefully you have enough fuel reserves after you little diversion to find land search for an airfield.

So that would be a pretty bad situation. I wouldn't worry though, aircraft systems are generally better isolated than that.

Municipalities don't have airspace regulations. That's all managed federally. Also the Alpha Electro is already legal to test. It's apparently registered as an Experimental aircraft in the US currently, which means it can be used by owners but not commercially (e.g. for flight training). The market Pipistrel's aiming for is the Light Sport Aircraft category, but electric planes can't be registered as LSA in the US so Pipistrel would have to go through the standard airworthiness certification process. Which is long and expensive.

They suck. I've flown in a Cessna with a touchscreen transponder, and it was nearly impossible to enter the required four-number code in light turbulence.

edit: That said, you could probably make a decent aviation touchscreen. The main issue with off-the-shelf screens is it's easy to brush the wrong thing. A screen that takes significant pressure to register a touch would probably be usable, and for all I know this system might do that.

The reasoning is that some people cancel their reservations, so if you have a good statistic for how often that happens you can overbook to take up the slack and still have a full plane. Airliner margins are pretty thin, so they jump at opportunities to avoid "waste" like this.

Scammy? Ehhh. People get way more than their money back for switching flights, which I consider enough to make it un-scammy. Others might reasonably disagree.

The nature of commercial flying is such that actual incidents are pretty rare (150 or so a year recently[1]), and very very expensive. So taking the "data-driven" approach to pushing what's safe really isn't economically feasible, to say nothing of the ethics issues. Instead the principle of "if it seems unsafe, it's probably unsafe" applies. I believe the situation mentioned in the article of riding for fourteen hours then flying for nine is allowed by the FAA, but if the pilots aren't rested (reasonable after riding in a cargo plane for a day), then the airline shouldn't be asking them to fly.

[1]: https://en.wikipedia.org/wiki/Aviation_accidents_and_inciden...

> As in nature the language that thrives is the fittest for its environment, not the most powerful.

Now hold on. The most successful sprog of nature is humanity[citation needed] and we're a case study in the fact that raw intelligence is more effective than fitness for any particular niche. So: as in nature, there may be a bunch of niche languages, but in time they'll find themselves with a conservation status while a smart language rules the earth.

wrt "darcs is slow": the darcs source repo is 59M and took 3:27 for me to clone. Git's repo is 117M and took 6:02 to clone. So per repo size they're pretty similar. Darcs has its issues, but under normal conditions it's not notably slower than git.

Well, you could embed a machine-checked proof that instruction sequences of the targeted form will sometimes survive previous optimization passes and therefore the given optimization will always be contributing something.

But that's hard, so every compiler I've used leaves it to human engineering instead.

I think by "vacancies" they mean "vacant homes on the market", versus "vacant homes the owner is sitting on." A tax would encourage vacant homes to be put on the market.

Excuse you, that was General Ripper. As for fixing this: it will not be difficult, mein fuhrer!

We don't have to still program this way - you can write code with very strict types, with machine-checked proofs that it works correctly, etc, etc. We don't do this very often because it turns out this level of rigor is incredibly time-intensive.