HN user
Yep! There was a submariner-turned-astronaut that mentioned the smell was pretty similar, and also that submarine deployments can be described as "breathing recycled farts for six months." At least submarines have replacement oxygen handy!
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.
Plus the closer you are to the equator, the less (very fuel-expensive) orbital correction you need to get to geostationary orbit. Being close to the Tropic of Cancer, Florida's pretty well-positioned in this respect.
Not necessarily. The Fortran standard allows for floating-point reordering that can produce value errors. All that's required is that the new system's compiler optimize differently than the last one; there isn't necessarily a bug anywhere. See https://software.intel.com/sites/default/files/article/16438...
Bluespec's thing is that rules are atomic, so they won't ever (appear to) fire in parallel. This is in contrast to Verilog and friends where that isn't guaranteed. The nondeterminism comes in when two conflicting rules are both ready to fire: they can't both fire, so the system needs to choose one. You're warned when the compiler detects this, and it can be resolved by giving one a higher priority.
I personally didn't find the semantics to be unreasonably complicated, but the type system is very much based on Haskell's so if you're not used to that there'll be more of a learning curve.
One difference from Verilog/VHDL is that Cx will handle state machines for procedural code automatically. Bluespec has a similar facility. Also like Bluespec, it makes the clock implicit which makes a lot of code less noisy.
Practical Common Lisp is a very good introduction. It's very much targeted at competant non-academics.
What advantage does this site give over just pasting the data directly? The shortened URL aspect is gone, so the only "advantage" I can see is obfuscation. And if you want that you can base64 your text directly.
It's not even an issue in languages (C) that don't strongly type for performance reasons, or because you get closer hardware access as a result (though these count as features themselves). The problem is that in Javascript, you don't get either of these -- there's no benefits, there are only new bug vectors. This wouldn't be as big of an issue if the default coercion behaviour was generally helpful, but it's not. It's just a pain.
> what would you expect?
I expect a type error, like I said before. Implicit coercion between types is the definition of weak typing, and is part of what separates Python from Javascript.
> blessed language
Granted, hence why the GNOME devs didn't choose Vala. That doesn't explain why they didn't choose a cleaner, easier language, and it certainly doesn't explain why they chose the ass-end of web development.
> already know
The developers that Already Know only Javascript are not, in my opinion, the ones that GNOME will garner the most benefit in attracting.