lexszero_

Seamless integration with fax-based workflows!

Just curious, what come first and second in this use of the phrase applied to computer security? I came to know the expression from fire circus performance and adjacent circles, where first and second are safety of the audience and the venue, and third is your own. I use it often when I'm about to knowingly do something sketchy or potentially dangerous without applying safety practices required "by the book", acknowledging the present danger to myself and accepting the risk. I never saw it used in infosec context.

Nitpicking, IBM did non develop _the_ Apollo Guidance Computer (the one in the spacecraft with people), it was Raytheon. They did, however, developed the Launch Vehicle Digital Computer that controlled the Saturn rocket in Apollo missions. AGC had very innovative design, while LVDC was more conventional for that time.

Some pocket calculators from not too long ago supported this unit for some reason, along with radians and degrees. That's the third option on "DRG" button.

"You are so poor that when AWS goes down, you still can get into your house" -- seen somewhere

For a short while, I worked at one of Samsung subsidiaries on their TV firmware, mostly fixing Linux kernel bugs introduced by the product teams cannibalizing upstream features to serve their needs (including intentionally disabling reasonable kernel security measures that happened to be in their way). I've seen things, both technical and organizational, that led me to pledge never to give my money to that company, or have their devices connected to networks I care about. I don't trust any of it, if not due to evil intent, but just incompetence.

"Letting go" belongs in the same HR phrasebook. They didn't ask permission to quit and the company were so generous to let them, the initiative was from the other side.

Here in Finland mechanical locks with electronic keying are pretty common in some places. Some of them like iLOQ or Abloy eCLIQ are actually pretty clever: electrical bits of the lock are powered from mechanical action of inserting and turning the key, so you don't have to worry about batteries. In theory, they promise significant cost savings in scenarios like rental apartment buildings where tenants move in and out, need access to common areas, lose keys, etc, without compromising security or having to replace or recode locks - they just give you a generic key, click some buttons in the admin panel, and your key could be provisioned accordingly once you first enter the building and interact with one of the "smarter" locks that are externally powered and networked to the mothership.

In practice, in addition to the usual bugs you would expect from a software-based system managed and maintained by a plethora of organizations and contractors, they tend to become very annoying as parts wear out, so you have to fiddle with the key reinserting it repeatedly trying to find just the right angle so it will make a good contact to be recognized by the lock (for example the iLOQ system by my landlord communicates over a thin contact strip molded into the key opposite of the cutting and separated from the rest of the key with a thin layer of plastic).

> Almost nobody in the space produces anything professional and everything uses Yocto even for two person projects where Multistrap would be more productive.

While I agree with your sentiment that there's a lot of poor software engineering in embedded space (especially in consumer-oriented novelty products, less so in established fields like industrial or telco), I can't but wonder what's wrong with Yocto? In my experience, it's quite the opposite: Yocto is the quickest path to get the firmware for a new device assembled, once you have climbed its pretty steep learning curve. I have built a few homebrew firmware build systems out of Debian and make/shell scripts (not my choice), you pretty quickly find yourself reinventing half of the stuff that Yocto does out of the box, but it's all bespoke, janky and hard to maintain. While with Yocto you just take the vendor's meta layer for BSP, put your application in another, and it bakes you a set of flashable images on the other end, complete with SDKs and other goodies for your dev workflow, reproducibly. It doesn't get significantly more sophisticated once you start to need kernel customizations, firmware updates with A/B partition layout, readonly rootfs, manage board- or customer-specific variants and other features that are very common in embedded systems but poorly or not at all supported in standard distros.

Interestingly, ISO standard documents are sold for a non-insignificant price and DRMed, while people writing them are volunteers and/or paid by their employers to participate in standardization committees. A company willing to build equipment for an industry running on ISO/IEC communication protocols (like electric power distribution) may have to pay thousands for relevant standards, or rely on someone's interpretation of said standards to implement the protocol before they even begin, not considering certification costs.

And part of the reason for that is compatibility with existing light fixtures using legacy sockets designed 150 years ago at the dawn of electrification for incandescent bulbs, where the part dissipating the most heat was the light emitting element itself, and not whatever lays between it and the mains power source. If the customer doesn't want to pay for a slightly more expensive LED lightbulb, they sure as hell won't pay for a whole new fixture specifically designed around LED technology that will last forever.

This is anecdata, but I haven't replaced a single LED bulb since I bought the current set ~7 years ago, and it's nothing fancy, just basic IKEA stuff.