I've only ever seen GSA approved containers use old-style rotery dial locks; never seen anything electronic.

There is no such thing as a secure electronic system. All electronic systems can be hacked or back-doored. "But I audited the opensource code", you say? Did you see what is hardwired or hardcoded in all the chips? No? Then it is not secure. Also, many, if not most, affordable electronic locks can be defeated with a magnet becuse they usually work on a solenoid.

The problem with java is the 'conventions' that have arisen on how to use it. The convention in Java is to encourage over-abstraction to the point of absurdity. When you download and look at any project, you must spend considerable time trying to detangle and understand the thousands of lines of spaghetti abstract interfaces and 'helper' classes. It is a huge cognitive load.

There is a joke hello world at http://foreigndispatches.typep... that really isn't far from the truth about how java programs are actually implemented by some coders. I seems some java coders think: Why just print a string when you could instead instantiate a new string-writer class implementing an abstract string writer factory with a text-writer interface? And instead of hardcoding a constant value, use an xml or json configuration file, even if you will never actually change the value.

from the TFA:

So what went wrong? The single most expensive item that I could not predict was our ongoing litigation against the non-practicing patent entity that has never stopped trying to destroy us. If we had that million dollars we would be in a very different state right now

Adopting a naval rank structure would ensure the Space Force is indeed a separate service instead of an appendage of the Air Force. Compare the Navy and the Marine Corps, both part of the Dept of the Navy, but we regard the them as different services. While the Space Force is part of the Dept of the Air Force, it needs to establish it's own identify similar to how the Marines have established theirs. Different uniforms, different ranks, different traditions, and even different culture and ethos.

The only thing rocketing to space for this project is the astronomical budget overrun.

Many thanks to the author and to O'Reilly. Can some post the link to the pdf? Or do I have to start the trial at O'Reilly?

The data (USB-3 plug) is plugged directly into the Pi, but the Kinect has a separate 12v power supply (wall-wart), so I would not expect it to be pulling power off the USB port, but I'll check out using a hub just in case.

I have the 4GB Pi 4. If you are running Raspbian, you may be OK, but support/performance has been spotty with other OSes. I'm running (or trying to run) Ubuntu with an arm64 kernel because I'm working on a ROS robot. I bought the Pi 4 specifically for the USB-3 ports so that I would be able to (hopefully) put a kinect on the robot for depth/3d vision. I went with Ubuntu because ROS (my primary app) is best developed and supported on Ubuntu and has binaries available through apt-get. I went with Arm64 because I bought the 4 GB version (more is better, right) and 32-bit OSes have practical limits that prevent addressing the entire 4GB. Well.... its been crazy. Everything works well for about 2 minutes and then the kernel and USB ports freak out over setting the CPU frequency. After working well for about 2 minutes, the USB port loses connection to the kinect, kernel errors flood syslog, and the whole things slows to a such a crawl that using the mouse becomes impossible. Prior to January, the Ubuntu team acknowledged that they didn't fully support USB on the 4GB model with the recommended work around being to set the kernel memory limit to 3GB. They recently released a new kernel that they think resolved the situation and supports the full 4GB. I'm running the new kernel, but still having problems. I'm getting ready to send a bug report to the Ubuntu arm64 list.

My point here is ... if your use-case supports Raspbian, then you are probably OK. But if your use-case requires another distribution, be prepared for a trip back to the fiddly-bit days of the mid-1990s and trying to making linux run on unsupported hardware.

I'm working on a robot project and I just got one. I haven't had a chance to integrate it into my project yet or play with it but Coral is supposed to allow you to use TensorFlow-lite for things like visual object recognition with a Raspberry Pi without overloading the Pi. I'm hoping this will let my robot recognize object and maybe even process (a limited subset) natural language with purely on-board processing and not having to ship the transaction back and forth over a network. Check out this guy's project. The project I'm working on is much larger (about 70kg or around 150 lbs), but this guy's project can give you an idea of what coral can do. https://youtu.be/aso3N4YiCAQ

Imagine a beowulf cluster of these.....

If I remember correctly, Exim is, or was at one time, the default mail agent on Debian and was installed by default on 'full installations'. I'd guess that most Exim installations are essentially installed-but-unused on Debian and Debian-based box.

Back to the future.....
Gopher Protocol
Also.....
Lynx Text-Only HTML Browswer

Hydrogen can be used as a drop in replacement for anything running internal combustion or just combustion for heat (smelting or kilning). The hydrogen can be produced via electrolysis of water and any form of clean power can run that process.

However, where CO2 emission is part of the actual industrial process such as converting iron to steel (adding carbon via coke is the entire point) or kilning cement (CO2 is part of the chemical reaction for some types of cement), there really isn't a good means of reducing CO2. Certainly you can reduce the CO2 from the power supply end with alternative energy sources, but not as a direct by-product of manufacture.

ses beams of light to deliver high-speed, high-capacity connectivity over long distances

I read the article. It was short on technical specifics. So I looked it up on wikipedia. Free Space Optical Communications (FSOC).
So what makes them choose this as a better choice than older proven line-of-sight technologies like Microwave radio relay. Microwave formed the backbone of AT&T and MCI long-lines and had enough umph to carry live video. Does the light relay system really have that much more bandwidth than microwave? FSOC looks inferior to me. Shorter distance (a few hundred meters vs hundreds of kilometers for mw and more attenuation with weather (fog, rain).