I was born too late and missed most of the fun, but still managed to catch the trailing end of fidonet in the late 2000s. Pretty much everything was over IP already, there wasn't a single proper dial-up node in my local network (which was pretty small already, around 20 nodes in its heyday), but for me this IP connection happened to be a pay-by-the-minute dialup ISP, so the offline nature of fidonet helped me stay glued to the computer and actively participate in dozens of communities with just a few expensive online minutes per day. Later in highschool (I even managed to find a teenage crush my age from another city in some echo! we exchanged pics with uuencode in netmail =D) I ran my own dialup node just for fun on an old PII with NT4 in a cardboard box under my bed. It survived multiple hardware and geographical moves and was running over IP up to about 2012-ish, and was finally nuked from the nodelist in 2018. I still have all the configs in the backups somewhere and the active NCs contact, so technically could get it back up if really wanted to. Too bad there's nobody there to speak to.
Addition: turned out, nowadays you can just run the "normal" FTN stack (binkd, husky, golded) in a docker container and access it with a browser. "It's not dead, it's just smells like it". https://kuehlbox.wtf/projects,fidian - no affiliation.
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.
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.
He is a great source of knowledge on physical security for laymen and professionals alike, and leaves an impression of an extremely amicable and well-rounded human being.
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.
I haven't heard about Optane before, but the concept of persistent memory reminds me of PhantomOS[0], which is based around the idea that from the app perspective everything is already in memory and the kernel/runtime (JVM-ish, so object-aware) takes care of {,de}serialization to a non-volatile storage by virtue of a highly sophisticated virtual memory manager so the app programmer doesn't have to think about it. I remember seeing it being presented at some conference around 2012 and the live demo running Tetris game slowed down to a crawl and crashed after a few blocks due to bugs in GC.
Back in 2018 I've been involved in a product development based on TX2. I had to untangle the entire nasty mess of Bash and Python spaghetti that is JetPack SDK to get everything sensibly integrated into our custom firmware build system and workflow (no, copying your application files over prebaked rootfs on a running board is absolutely NOT how it's normally done). You basically need a few deb packages with nvidia libs for your userspace, and swipe a few binaries from Jetpack that have to be run with like 20 undocumented arguments in right order to do the rest (image assembly, flashing, signing, secure boot stuff, etc), the rest of the system could be anything. Right when I was finished, a 3rd party Yocto layer implementing essentially the same stuff that I came up with, and the world could finally forget about horrors of JetPack for good. I also heard that it has somewhat improved later on, but I have not touch any NVidia SoCs since (due to both trauma and moving to a different field).