Remove the ability to log directly in to Flock to initiate a search. Add new "initiate Flock search" button in the digital evidence management (DEMS) case screen that sends the case number directly into Flock to open the Flock search interface. Lots of ways to accomplish that with varying levels of security, but the point is, the user should never be able to initiate a search without it being tied to a case inside DEMS and should never be able to just enter whatever they want in place of a case number. Ideally, now DEMS has a direct link inside its case to the Flock search and results. Yeah, this means Flock has to have an API of some kind that DEMS can integrate with, and DEMS has to be enhanced to do so. But, these are the kinds of guardrails that should have been there from the start to minimize abuse.

Of course, this moves the attack (abuse) surface from Flock into DEMS. But, DEMS should already have strong guardrails around creating new cases (should always be linked to CAD / Records to start with). This kind of inter-system linkage is complex, but necessary, not just to mitigate Flock abuse.

They could just call it "Multics" instead.

Why yes, I am rather old. Why do you ask?

Microdosing Lithium (1mg lithium orotate, not carbonate) seems like a potentially good idea. It's cheap and available over the counter. Here's an article: https://hms.harvard.edu/news/could-lithium-explain-treat-alzheimers-disease

Functional MRI while playing Crazy Taxi might be worth a try to study this.

I don't drive a cab, but there are a bunch of video game maps burned into my brain (Original DOOM, COD4 Broadcast, Crossfire, and Crash, some newer FPS maps, etc.). I also tend to create a brand new Minecraft world every few days and then learn to navigate it without a map. I'm just wondering if "virtual" spatial relations are similarly correlated with real-world spatial relations.

Some brief history (from memory, not AI, so a few facts may be wrong here and there):

Motorola was founded in 1928 as Galvin Manufacturing Co. After creating the first commercial car radio in 1930 (the "Motor Victrola", or "Motorola") they renamed the company. It has a long history of creating new businesses and then either spinning them off or selling them outright to other companies (usually right before they become low margin / commodity). Televisions, pagers, semiconductors, etc.

The handset (and cable modem, set-top box, and cable infrastructure) business was spun off in 2011. The only unusual thing about that transaction was that due to the significant consumer brand recognition for handsets at the time, the new company took the "Motorola" name, while the old company was renamed again to Motorola Solutions (but can still put the "Motorola" name on non-consumer products like police radios, etc.). Yes, this is confusing.

Then, Google bought that company, sold the cable business to Arris, stripped out the core handset engineering teams (which now design Pixel phones for Google), and sold the rest to Lenovo for just under $3B.

Motorola Solutions currently has a market cap around four times larger than all of Lenovo, not just the part of Lenovo descended from the Motorola handset division they eventually bought from Google. They still make police radios, but also body worn cameras, command center solutions (911 call-taking, dispatch, etc.) and a whole bunch of fixed surveillance cameras under various brands.

When I learned C++, back in the 1980s, the "compiler" (Cfront) was really just a translator that generated C code. That was a good thing, because it occasionally generated bad code, and being able to keep the intermediate C code around during compilation meant you could figure out what was going wrong at that level instead of having to dig into the assembly code. Code-generation bugs still happen occasionally in compilers, I'm sure, but not like it was in those days. Now, it's rare anyone has to worry about the code that ends up executing being functionally different from what was expressed in the higher level language (at least not due to code generation bugs).

But that semantic gap (the levels of abstraction between what the programmer considers as an abstract execution model and what the hardware actually executes) was increased by going from C to C++, and Cfront was the tool that enabled that expansion. Newer, even higher level languages have continued to increase that semantic gap, aiding productivity gains. But, they still generate code in a predictable, consistent way. The same code, compiled by the same compiler version, will generate the same executable code every time.

But here we are again. LLM-generated code is just the new "Cfront", taking very high level language descriptions of what we want, in the form of "prompts", and translating them into code at one (higher) level of semantic gap into another (lower) level of semantic gap. Great. Except now we're back to having to deal with "bugs" in the code generation. Worse yet, it doesn't generate the same code consistently, because the "temperature" parameter is a trade-off between output quality and consistency. Perhaps one day we'll get to where modern compilers and code generators are. Until then, we are still responsible, even liable, for the code we create, either directly or via some LLM-based model. So, we'd better be able to read and understand the code being generated at the layer most prone to bugs, until that layer gets to the same level of reliability as modern compilers are at today.

When launching a container, they boot a Linux VM that just has a single, statically-linked executable inside: vminitd. No systemd or other daemons. No libc or even ld.so, just vminitd.

That process is responsible for talking to things outside the VM, and for launching the container, etc. When the container process exits, vminitd exits and shuts down the VM. Starting the VM takes ~100ms, and the amount of memory and CPU cores it gets are taken directly from the container configuration. So, it's not terrible in terms of memory usage. It's sort of ideal for short-lived containers, since it starts up so fast and only uses as much memory as the container ends up actually allocating (not what it asked for). I'm not sure how they manage to boot Linux in a VM that fast, honestly. Maybe they have a pickled pre-booted image ready to be mapped into memory so they can tell Linux it's just woken up from being suspended? I have read some of the documentation, but I haven't dug into the code yet.

Meanwhile, it uses Rosetta2 to execute x86 code, so you can both build and run multi-platform containers.

I don't know that I'll actually use it myself, since Rancher Desktop is pretty slick, and I need Kubernetes. But, maybe someone will get k3s working on this and I can get away from having to run a big VM all the time. In any case, it's nice to see Apple recognizing how many people use their machines to build Linux containers, and it's nice to see them making it open source while they're at it. It isn't perfect, but it's at least somewhat clever.

There are a few people I think of as having "saved" the internet at various points in time. Van Jacobson and Sally Floyd, of course. But Dave Taht deserves to be in that group, in my humble opinion. Van saved us from congestion collapse in the late 1980s and early 1990s by introducing the core congestion control algorithm in TCP. Sally Floyd (Van's grad student at the time, and, sadly, no longer with us either) created Random Early Detection as much improved queue drop policy in routers that reduced latency and improved throughput.

But Dave took queue management a gigantic step beyond that, figuring out, for example, how to control the flow of outbound ACK packets in order to minimize inbound queue lengths on intermediate routers, minimizing the amount of data sitting in those queues waiting to be serialized onto each outbound link.

I only interacted with him briefly, but he was clearly brilliant, energetic, and just wanted the internet to work as well as it possibly could. Since the algorithms he was working with needed to be running in consumer routers, he spent a bunch of time reaching out directly to as many router manufacturers as he could, critiquing their implementations and offering insightful suggestions for how to improve them, and asking for no more than a lunch in return. Things like internet telephony, FaceTime, Zoom, Google Meet, etc. are all feasible because of his relentless efforts.

Not a doctor â€" engineer. ICU visiting hours are longer, but not 24 hours per day. So I'd come home for a few hours, fix a meal and eat it while reading every published medical paper I could find. I definitely learned a lot. Like, don't try to supplement with albumin. One paper studied that went it made the already poor survival rate significantly worse. I think a lot of engineers and scientists cope by diving in to learn as much as possible.

My then-wife nearly died from Group A Strep Toxic Shock Syndrome nearly twenty years ago. She'd been vomiting for a couple of days and was severely dehydrated. Her skin appeared sunburned. The outer layer would eventually completely shed in sheets about a week later. Once they got an IV drip going, fluid built up in her lungs, likely due to hypoalbuminemia, which is a key feature of STSS. This landed her in ICU on a BiPAP mask (intubation would have been the next step had the BiPAP not worked).

Two IVs plus a twin-lead PIC with five infusion pumps running multiple antibiotics plus IV immunoglobulin and, later, a big bag of lipids. Multiple organ failure, including kidneys meant her electrolytes were way off, and that triggered a latent conduction path problem in her heart. A couple episodes of tachycardia were addressed using a drug that (briefly) stopped her heart completely each time. That was unpleasant.

It took several days for them to even diagnose what it was. But, one day, a young doctor we'd never met before burst into the room and, without introducing herself, said "I know what you have!" After that, doctors from all over the area (a large metropolitan area with over 8 million residents at that time) to examine her just to see what a patient with this extremely rare condition looks like. It was touch-and-go for about a week during her 10 days in the ICU. Recovery took about a year, and left some permanent damage to her gallbladder.

0/10 - would not recommend.

Oof, I wasn't aware the fuel cell wear involved actually losing the catalysts. That does make recycling the fuel cells a lot less useful.

Fuel cell vehicles typically do include a battery. This is necessary because the peak current from the fuel cell stack isn't enough by itself to, e.g., get started going up a hill, or just from a dead stop on flat ground with a heavy load, or accelerating down the on-ramp of a freeway. This does mean they can take advantage of regenerative braking, too. But, that also means those batteries wear out, too. Interestingly, they have the same issue with battery wear that ICE hybrid vehicles do: the total number of charge/discharge cycles is higher on a per-cell basis for a hybrid than for a pure BEV. This is because the smaller battery pack is discharging more deeply when accelerating, and charging more deeply during regenerative braking. So, just like ICE hybrids, a hydrogen fuel cell vehicle will need to plan for battery replacement much sooner than a similar BEV would.

Regarding #2, my understanding is the current fueling stations all have to have compressors between a larger storage tank (that may start out at high pressure when it's filled, but will drop as it is used) and a smaller filler tank that is higher than the destination pressure. This small filler tank drains quickly while filling a vehicle, so even if the first vehicle can be filled quickly, the next one in line has to wait for the compressor to repressurize the filler tank. In short, compressor energy is required at the filling site, and results in relatively low refill throughput when measured over multiple vehicles. So, yeah, we'd need compressors at multiple stages of the system, including production, distribution, and filling.

Regarding #4, not only are the fuel cells expensive to start with, they wear out and need to be replaced for any long-lived or high-use vehicle (like a truck). If we were making a lot of fuel cells, we'd probably find a way to extract those expensive metals and recycle them (similar to battery recycling). But, they are still going to be expensive.

Regarding #5, yes, the tanks are heavy (and expensive). But, just like the fuels cells, they also wear out and need to be replaced for things like trucks.

So, vehicles that are expected to last a long time and drive a lot of miles will have to be designed to allow easy replacement of both the fuel cell stack and the high pressure tanks just to minimize the labor costs. But, those replacements are still going to be expensive.

It's not just the price of the hydrogen itself. It's also the cost of the tanks and fuel cells, which both wear out (and are both expensive). The tanks in a Mirai are rated for 15 years, which sounds ok for a sedan, but a truck would be expected to have a much longer service life than that. I suspect the pressure cycling in a truck would put more stress on the tanks as well. Building them for longer life would make them even more expensive and even heavier.

The fuel cells themselves also wear out. Toyota currently rates the Mirai fuel cell for 150,000 to 200,000 miles. A long-haul truck would do that in less than two years. Short-haul trucking wouldn't, but is better served with batteries.

So, I don't see a place for hydrogen itself in many transportation applications. As feed stock for a synthetic fuel... maybe? Not cheap, though. We'll need lots of hydrogen to make fertilizer and steel, so I don't see the price coming down all that quickly.

Temporary pacemakers are used after various types of heart surgery, especially anything that requires stopping the heart (like most cardiac arterial bypass graft procedures). Those pacemakers are external, except for a couple of wires that go through the skin and under the sternum. They are removed by pulling on them after a few days, if everything is going well. But, that makes them an avenue for infection, and if they get pulled on too early by accident, you could end up needing to go back in to place them again. So, I would expect something like this would be used in that type of scenario: place it during the surgical procedure and then close completely (ok, except for a chest tube for drainage, but eliminating the external pacemaker wires is probably still a win).