* Pilots are very concerned about life and safety and are heavily exposed to drone “incident” related anecdotes, so they err far on the side of caution with drone sightings. Which is to say a very low percentage of them are real.
* Poorly implemented cUAS systems, especially ones based on passive or active RF locating (radar) can actually make the problem worse: they hallucinate everything into drones, pilots hallucinate everything into drones, and now everything is a drone. This also happens frequently when people try to repurpose military systems (which are usually designed to operate in significantly less crowded environments and trigger at the slightest hint of an issue, due to mostly orthogonal-to-airports threat models people discuss at length on this thread like “dark drones”) into urban use.
This type of array based directionfinding system is cool and it could work as a small ingredient in a drone detection system, but it’s not anywhere near the state of the art in the space and most airports are probably already ahead of this to some extent.
Most major airports will already have a counter-UAS system, it's a huge industry.
One big issue with radar is that it has the same problem pilots and human observers do: it struggles to distinguish drones from anything else in the sky (birds, balloons, planes, etc.). This is an active and improving research space, but by and large with radar, when your pilots report a drone, you still don't know how to figure out if it's the typical mis-identification or something real.
This is weird to me too, especially to say in the present tense in 2026.
I think I get the point about "Rust culture" (although it's too vague to agree or disagree with, probably on purpose).
But in 2026, Rust is fully a commodity language, and especially to compare it to Zig in this angle is bizarre. Even turning my stereotypes to 11 and thinking back to when I worked with a team developing Rust professionally in 2021, I'd say we got mostly ended up hiring "proglang enthusiasts" and not "Rust people." In terms of "cultural dilution" alone Zig is orders of magnitude more culty than Rust because that many fewer people use it.
It’s a huge problem. The most common approach to address it is called smearing; the duration of each second for a 24 hour period ahead of the “leap” is adjusted. For strict ordering systems this works as each device maintains time sync with the global clock, the duration of a clock cycle is just slightly different. I think this was in the original Spanner paper, actually.
Some rare systems use monotonic oscillator seconds and ignore the earth rotation second, but if you ever have to translate those to real time, you get an accumulating disaster over time and it’s generally regarded as not a good idea.
To your point about `fetch` in the sibling comment; yes, I would also be annoyed by a website which downloaded 4GB in the background without asking me, too.
I don't think this is some moral outrage, to be clear; it's well within Google's rights, it doesn't seem "sketchy" at all, and it is kind of a cool feature, but it feels like they could have done a lot better by just making it opt-in and a little less fingerprintable.
Just the availability wouldn't be that bad from a fingerprinting standpoint (getting one bit that a majority of Chrome users have is just the same bits you already have, usually), except, it also exposes whether the underlying hardware is "eligible," and once it's running, you can also benchmark the language model performance. It's a mess. I think it might also be broken and work in iframes, which would be an even bigger mess; there are a few bug reports suggesting this although many of them look like slop.
This feature was massively bungled; I actually don't overall hate the idea of it (having a shared, pre-downloaded model that can run effectively from JS is kind of awesome versus sites downloading stuff into LocalStorage to use with hacked up wasm/webgl inference engines), but it really, really needed a permissions dialog and a proper anti-fingerprinting model.
Impression v. Lexmark is directly relevant to the patent situation here; in a case involving reprogrammed ink cartridges, the Supreme Court held that patent rights are exhausted by first sale doctrine; that is, if you sell me something patented, you can't sue me for patent infringement for using the thing you sold me, even if I do something later that makes you upset.
It's also been widely held that ink cartridge compatibility tools/hacks are allowed under DMCA.
However, it does seem likely that there's probably some shenanigan involved in the area - one example I could think of would be if HP have patented the way the ink cartridges are retained in the printer, for example, that would have to be carefully audited. And there will be license and trade secrets issues with the use of the cartridges, although if they were reverse engineered cleanly and the printer doesn't come with cartridges, those are probably pretty easily side-stepped.
> A vulnerability can’t leak your key if the TPM doesn’t know the entire key and relies on the user to supply the missing parts of the key in the form of a PIN.
First off: I agree with your thesis, BitLocker with PIN is Just Fine, equivalent in all practical senses to most disk encryption strategies, and an enterprise standard.
I post this to reinforce what you're saying, because there are a ton of weird theories about how this works that make people think it's weaker than it is.
BitLocker with PIN works like this:
* BitLocker seals an encrypted key IK into the TPM using a policy on the TPM which requires the SHA-256 of the PIN to be sent to the TPM to unlock the record (and has anti-hammering at the TPM level).
* Encryption using another key called the SK. Once the OS acquires the e(IK) from the TPM, it needs to derive SK to decrypt the IK. The SK is generated by applying a salt and 0x100000 rounds SHA256 to the PIN.
* The IK can then decrypt the VMK, which can decrypt the FVEK which is the actual data encryption key used on the on-disk data.
Fully offline (no TPM access) decryption is hopeless; the IK is random and not attached to the PIN at all.
Fully online decryption relies on TPM anti-hammering; if you can manage to hammer the TPM and find a PIN where h(PIN) matches, you can then use the PIN to generate both h(PIN) (unseal TPM) and reverse e(IK).
Partially offline decryption (imagining TPM content is somehow dumped, for example by bus sniff while a user uses their PIN) relies on bruteforcing the key for e(IK), which is possible but difficult (IMO Microsoft should ratchet this up or use a more expensive algorithm than SHA-256 in order to deal with modern hardware capabilities, but they have issues like FIPS to deal with that make new algorithm selection difficult).
For the system drive they seem to really strongly prefer PIN, which also doesn't have the problems linked above. I was going to use PIN as my example but didn't want to explain another set of recent BitLocker conspiracy theories yet again; maybe I should have.
It is annoying that they hate password for system drive _so_ much; the reason is actually pretty obvious when you think about how their "happy path" AD-driven enterprise deployment with stupid password rotation requirements works (and FileVault is a nightmare in this scenario), but I wish they'd make it easier for individual power users.
Having dealt with FileVault in this context, it's also frustrating; it's really common to have it fail to follow the logged-in user's credentials, and if you use any kind of federated login, you will frequently get users with FileVault passwords that are either ahead of or behind their system login password.
I think both approaches are valid trade-offs and I think that the default Secure Boot BitLocker configuration, for all its architectural tradeoffs, can probably be credited for an enormous amount of data loss mitigation originating from used hard drives alone.
The issues you linked with BitLocker are obvious properties of BitLocker-with-SecureBoot-only architecture. If you configure Linux that way, you get similar issues (for example, it's pretty easy to mis-configure TPM sealed disk encryption on Linux to still allow a recovery shell, which will run with the disk unsealed).
BitLocker with a password (the equivalent of the LUKS configuration in question) does not share these issues.
For "copter" style drones, 3D printing is basically a "noob" meme at this point; everyone thinks it's a good idea, tries it, and realizes that it's actually really hard and doesn't work.
Copter-style drones are exposed to vibration across a huge frequency range in every axis, and it's almost impossible to avoid really nasty resonance issues using generally-printable FDM filaments and "standard" design techniques; it's a lot easier to just use super-stiff carbon fiber and CNC it.
For planes, like what you linked, 3D printing is more "plausible" than for copters but also not really practical; you can 3D print a good plane, but plastic lacks the durability and favorable weight characteristics of foam - plastic planes tend to be "one time crashed" while foam is easy to repair, restore, and rebuild.
Low end and most open source stuff will use a PID inner loop for “fast path” control (stabilization) and either a second PID loop or something a little better (Kalman filter etc) for the slow path (position / path hold).
Higher end stuff will use a ton of inputs (visual odometry, binocular vision, lidar, range finding, etc) fused into some kind of proprietary blended algorithm that you could probably call an MPC.
RL is pretty cutting edge, especially for fast path motor control; there are a lot of university competitions for drone control that lead to a lot of papers and projects in the space (some promising) but most commercial stuff has not adopted this yet, certainly not at the low end.
Most filament based printed frames end up with really nasty resonance; it’s possible to engineer damping around the issue with some clever 3D design if the parameters of the prints are measured, but overall 3D printing copter frames doesn’t tend to be a straightforward solution.
Ahh, thanks for the correction, it's the window manager that's closed (lipstick-jolla-home). Regardless, I will stand by my statement that a fully open-source build of AOSP is significantly more complete and useful than a fully open-source build of Jolla.
If we're going to start counting forks, we get to count LineageOS and GrapheneOS for Android, and then the goalposts really move.
I don't think this is true at all? AOSP is completely open source modulo driver blobs (which Sailfish has too) and Google services.
One can make a fully functional system, modulo drivers, out of only open-source components using AOSP. It's not possible to do this using Sailfish; the compositor, UI libraries (Silica), and most of the "core" apps are still closed source.
> Somehow hardware giants like Dell, HP, SuperMicro, etc didn't make a product like this, even at their peak in 2000s or during cloud boom in 2010s.
Not so sure about this one. HCI (Hyperconverged) rack units (where storage and compute live in the same racked systems) and "blade servers" have been a thing for a really long time now; compute sleds aren't what's novel here.
Rack-level DC conversion is also not particularly novel, although underutilized IMO. It was pretty popular in HPC style density applications for awhile (see HP/SGI Altix 4000 for a good old example).
What's unique about Oxide is that they went all the way down to the firmware and then back up, rather than doing commodity hardware integration or reselling - for example, you can get something like a Supermicro EVO:Rail, but it will be running VMWare, not a fully integrated platform.
No? The article extensively discusses the use of XOrg. With that said, the Wine graphics abstractions are a lot better now and there are many working backends (winex11, winemac, winewayland, winehaiku, etc.)