The point of a canary is that it's cryptographically signed, and it's possible to set up a duress passphrase that will delete the key when entered, so if everything works correctly an unauthorized party can't keep posting signed canaries.
Even if locked bootloaders weren't a thing, not being able to just buy a phone with an open Android pre-installed means it would get relegated to the Linux Zone, with a whole lot of "security alert" and "device not supported". Also, low popularity leads to fewer development resources, so it would probably suffer from lack of polish.
I would argue the term "gatekeeping" is being twisted around when it comes to AI. I see genuine gatekeeping when people with a certain skill or qualification try to discourage newcomers by making their field seem mysterious and only able to be done by super special people, and intimidating or making fun of newbies who come along and ask naive questions.
"Gatekeeping" is NOT when you require someone to be willing learn a skill in order to join a community of people with that skill.
And in fact, saying "you are too stupid to learn that on your own, use an AI instead" is kind of gatekeeping on its own, because it implicitly creates a shrinking elite who actually have the knowledge (that is fed to the AI so it can be regurgitated for everyone else), shutting out the majority who are stuck in the "LLM slum".
To be fair, and to offer context to non-hams: the morse requirement dated back to a time when morse code was _mostly_ the only way to communicate over radio. The problem is that it was held over as a requirement well after voice modes became commonplace on the air. Far longer than it probably should have.
I'm pretty sure quantum mechanics already forgoes conventional causality. Attosecond interactions take place in such narrow slices of time that the uncertainty principle turns everything into a blur where events can't be described linearly. In other words, the math sometimes requires that effect precedes cause. As far as we can tell, causality and conservation of energy is only preserved on a macroscopic scale. (IANAQP, but I'm going off my recollections of books by people who are.)
Einstein laid the theoretical foundations for lasers in 1917, and it took over 40 years of "impractical" scientific work before the first functioning laser was built. It took decades more for them to become a cheap, ubiquitous technological building-block. The research is still continuing, and there's no reason to assume it will stop eventually bearing fruit (for the societies that haven't decimated their scientific workforce, anyways). Look at the insanity required to design and build the EUV lasers in ASML's machines, which were used to fabricate the CPU I'm using right now, over a century after Einstein first scribbled down those obscure equations!
I sincerely wonder how someone that is unaware of any of this finds their way onto HN, but at the same time it is an educational opportunity. 'nothing practical' indeed...
What's interesting is how many things can be made to lase, and how many ways there are to do it. The list appears to be never ending and new entries are made all the time.
That's one of the reasons I built zlob. It literally has an endpoint to do this but if you are talking about glibc there are 2 options
1. fnmatch function which is not ideal because it doesn't take into account all the path specific optimizations and does not support BRACE
2. ALTDIRFUNC flag for globbing let you simulate file system which absolutely sucks
in zlob you can simply call zlob_match_paths(<pattern>, <list>, flags, ptr)
where list would be either c string or rust/zig like slices
As I understand it, compiling each source file separately and linking together the result was historically kind of a hack too, or at least a compromise, because early unix machines didn't have enough memory to compile the whole program at once (or even just hold multiple source files in memory at a time). Although later on, doing it this way did allow for faster recompilation because you didn't need to re-ingest source files that hadn't been changed (although this stopped being true for template-heavy C++ code).
> quite explicit furry art, is very common on bluesky
Now there's an understatement. It's bloody impossible to get rid of. People here are sneering at all the political content but they're ignoring the curvaceous elephant in the room. I think maybe bsky has improved things now, but a while back their adult content filters were not up to the task. When I first made an account I almost gave up on it because until I got all the right filter words set up it was nothing but weird porn whac-a-mole (actually that's probably a poor choice of words...)
I absolutely do not understand moving "report spam" under "report misleading". The UX for this is terrible. There are lots of bots posting SEO junk, at a rate and scale that definitely wastes resources, and now bsky has interfered with one of the signals it should be using to combat the problem.
I designed the electronics for a heavy-duty industrial 3D printer and used a 555 in the failsafe circuit (alongside the manual e-stop). If it didn't get reset by a heartbeat from the embedded computer/software, it would unpower the heaters and actuators.
That's the only use for one that isn't (always) a design smell - it makes a really nice missing pulse detector, better than you can easily do with comparators. But if you have the budget, a purpose-made watchdog chip or a tiny microcontroller really can make a better watchdog.
Supervisor chips are not complicated. In some ways simpler than a homebrew analog watchdog, and the good ones will handle failure modes a simple watchdog won't, like those that result in an oscillating output.
Yes, a simple purpose-made chip designed to be used in safety-critical situations, with high tolerances for voltage etc, would probably be better. Although one thing the 555 design has going for it is that a seasoned EE could take one look at the physical circuit and know exactly what it does.
But I would never trust anything that ran software for something like this.
The chips themselves add a bunch of new failure states to consider beyond software bugs, too. Maybe a bad wire or component puts too much load on the microcontroller's wee internal pin drivers and they melt into a permanent "on" state. Or a voltage fluctuation browns out the chip on boot, partially randomizing its RAM or registers. Or the chip manufacturer fixes some errata or discontinues a particular part number and now a pin you've left floating has become a hardware heisenbug. Or the wrong bit flips in your EEPROM after being in a hot machine for a few years. Suddenly a boring 555 looks pretty good. (Keep in mind, we're talking about "turn off heater after pulses stop", not "abort launch sequence if tank 3 pressure low". The latter is way above my pay grade.)
For every task you could also use a 555 timer for (with dedicated analog support complexity,) you are talking about tens of lines of user code at most.
Even if you had to do everything directly with registers, the amount of C or Rust here is minuscule.
Not if you go to the cheap "Asian brands" like you're thinking with micros, plus with your cheap micro you'll need a reset controller. And budget isn't all BOM cost.
reply