Comment highlights

Nuclear strike orders do not require high bandwidth. The orders contain targeting information and arming codes, all of which is pre-programmed on the missiles (the target package is specified with a "pointer" -- the computers on the missiles already have all the details, the order simply identifies which set of details should be used). For ICBM crews it is conceivable that orders could be transmitted on high-bandwidth systems, but for submarines that is not even possible (ELF bands have to be used because of the physical properties of ocean water). The basic launch sequence is this: a missile crew receives a series of characters and both missileers write the characters down. They check against a codebook and verify that they both heard the same message and that it is a valid launch order. If the message is valid, they unlock the launch keys (from a box secured by two combination locks, each missileer knows the combination for one lock), insert the keys, enter the missile launch unlock code, enter the warhead arming code, turn the keys, and then that's that. (There are several other steps -- go watch a video of a test launch and listen to the operators read off the checklist, there are quite a few steps. If you are wondering why such information is public, it is meant to reassure the other side that there is no possibility of unauthorized or unintentional launches -- we want our adversaries to know how we control our nuclear forces so they don't panic and preemptively attack us)

Back in my Navy days, we were taught HF is the less susceptible to jamming so is used for critical comms like these in serious situations. My ship performed in one exercise related to a doomsday scenario. We sat all day listening to an HR receiver until we heard these same messages, and we would then record the characters spoken. The message was repeated so we could make sure what we wrote was accurate. We never responded. Instead, we then repeated the same messages on an HF transmitter, presumably as part of some relay.

The most successful push on spelling was when the Chicago Tribune switched to simplified spelling in the 1940s through the 1960s.[1] They started with about 40 words, and gradually expanded. But after McCormick died, the company gave up, retaining only "tho" for "though". That ended in 1975.[2] [1] https://www.spellingsociety.org/uploaded_media/tribune-media... [2] https://www.nytimes.com/1975/09/30/archives/thru-is-through-...

Hi, I'm the creator of Docker and came across this post. It's always fun to see other engineers think about how you designed a system. I haven't been involved in developing Docker in many years, but it's a fun trip down memory lane. I'm happy to answer any questions you may have.

It's almost a shame it includes the private key and doesn't bruteforce it in-band for every request.

> Because the alarm wire carried current only during a fault, an open 25-inch strap produced the same electrical state at the receiving end as a healthy power plant. I’m a building automation and controls tech in Manhattan, and for this exact reason digital feedback points and alarms are always normally-closed, and analog points are 4-20mA. This allows differentiation between nominal zero values and a fault in the loop. Disasters like this are what our best practices are borne from.

Some years back, I helped build a Twinkie cannon, which was mounted in the front of a Twinkie-decorated car, built on a dune buggy chassis. We had to remove the roll cage to fit the fluffy cake body (made of airbrushed yellow fiberglass insulation), so we made sure to drive it quite slowly, but it was a beast underneath if you wanted it to be. (I once drag-raced a pizza driver, and only afterward noticed the cop on the next streetcorner. Luckily it's hard to write a ticket while doubled-over laughing.) The CO2-powered cannon was capable of way more power than cellophane-wrapped Twinkies can handle. Dial the regulator up past halfway, and they'd just shred on exiting the barrel, splattering anyone near the front of the car with sticky creamy filling and cake crumbs. That was both messy, and disappointing to folks down-range who'd been hoping to catch a snack. (And it immediately summoned a cleanup crew of seagulls, who then wanted more...) So we learned to keep it modest, and developed a decent sense of pressure vs range. The car geometry allowed only limited variation of the barrel angle, so it wasn't a full-on GORILLA.BAS experience, but it was pretty close. Culinary ballistics keeps you young. I highly encourage it.

Man, when I was doing my PhD at CERN the most far out thing that we were generally allowed to use was boosted decision trees :) getting anything other than that approved for any Higgs-related analysis was… not a thing.

Oh man, this makes me wish I had photos from the electric skateboard I made when I was probably ~13 years old. It didn't use a drill but a motor I harvested from an actual electric scooter. (that scooter's charging circuit was defective and nearly burned down our house) All I did was mount it to an existing skateboard as a friction drive on one of the rear wheels, with a primitive switch on a wire as the control. It was not really practical, but I was kind of surprised just how well it worked for what it was. If I remember correctly, I had to adjust my center of gravity to keep it straight, but not by as much as one might expect. I later reused that motor to build a pretty badass Van Der Graaf generator. I really admire the wiring job on this scooter! Goes way beyond what I did for the skateboard. And I imagine the scooter would have to navigate via only left turns. :D That is unless maybe a small third wheel were added to the end of it?

Hey, thanks for reminding me about that. We were inspired by Atari's Pong, to which I had devoted many quarters at the bar during my undergrad days. Nolan Bushnell came to visit Autodesk at our invitation, and we gave him a demo of our 3D version of Pong. Later, Nolan gave me some of my first business lessons at a meeting held at the Thai Garden restaurant at the corner of Page Mill and El Camino. Memories... I agree that VR isn't the best modality for precision CAD work, although it can be great for visualization. These days I just dictate what I want using a local Whisper instance, have Hemes-webui get my local LLM to write Python code, and then let FreeCAD generate the geometry. For me, that works much better than drawing in midair.

Two reasons: 1. Product decisions require far more knowledge than coding and architecture decisions, and that knowledge is harder to come by. It often requires research, talking to customers, understanding the organization of the company, the company's mission, the company's employees, their performance, stakeholders, the competitive landscape, funding, growth/sales/marketing strategies and budgets, customer buying patterns, company strategy, etc. Not to mention the code, the coding backlog, etc. Companies have to compete in a hostile, competitive, capitalistic market, which means they're trying to beat other companies, which means a seemingly very good product decision can actually be bad solely because other people are doing it better. Imagine if your perfectly functional code failed to compile simply by nature of the fact that better programmers exist. 2. Product design requires taste, and taste is partly a function of novelty, but there aren't that many LLMs, so everyone's using the same few LLMs, therefore everyone's getting the same designs, therefore the designs look like clones of each other rather than novel thoughtful design, therefore they fail the taste bar. In addition, LLMs simply weren't trained on good vs. bad visual or product design nearly as much as they've been trained on good vs. bad, functional vs. non-functional code.

I've been having a silent panic attack for the last 3 days, and I don't really have anyone to talk to that would understand my concern. I run a small pro audio company, we make guitar pedals and audio effects mostly. My current key objective is building up a processor similar to the Eventide H90, that would compete on having top-notch algorithms for reverb, delay, chorus etc. we already have single-effect pedals on the market that are very successful. In the past 72 hours I have ONE-SHOT decompiled 3 of my main competitors products, including the Strymon Big Sky. I just... have their award winning algorithms now. Like, I could in theory just stick them in a box and resell them. It took one prompt and 3 hours for opus 5.5 to work that out. The lexicon 224 then got added. While Claude was prepping It found someone else had already done the same thing 1 weeks earlier and dumped the result on GitHub, so it just stole that code and saved some time. It took all of 20 minutes to do the entire Ursa Major product range. And yes, I've tested them all - and they all sound phenomenal. I specifically asked Claude to first build an emulator and execute the original firmware/ROM so I could be certain it wasn't just making "something similar" but actually executing the same code. Then I asked it to convert it into a self contained c++ library and compare the result to the emulator. The problem is, everyone can now do this to my products as well. Basically, anyone with a Claude subscription can now rip of any best-in-class algorithm from any competitor. While I'm not going to do that, I know there are 30 Chinese companies that happily would. The moat of hardware effects processors has just vanished.

That takes me back to an early 1980s incident where I was criticized for an early computer-generated proof. This was when I was building a program verifier at an aerospace company. We had the first SAT solver, the Oppen-Nelson simplifier, and the first constructive theorem prover, the Boyer-Moore prover.[1] I wanted to show that the four axioms of arrays, which the simplifier assumed to be true, were valid in Boyer-Moore theory. Boyer and Moore had warned me of the soundness risks of adding axioms to their prover. So I tried to prove them from basic Boyer-Moore theory, which is close to the Peano axioms. Boyer-Moore theory is LISP-like in form. You start with (ZERO) and (ADD1 X). So two is represented as (ADD1 (ADD1 (ZERO))). It's all lists of tuples at the bottom. Equality is strict. (EQUAL A B) is true only if the representations of both A and B are identical. This creates a problem. An array can be represented as a list of (index, value), but for EQUAL to work, the list has to be ordered by subscript and each subscript unique. So storing into an array is represented as insertion into an ordered list. That generates a lot of special cases. Accessing an array is a linear list search by recursion: (DEFN selecta (A I) (IF (EQUAL (array-elt-subscript A) I) (array-elt-value A) (IF (EQUAL (array-prev A) (empty-array)) (UNDEFINED) (selecta (array-prev A) I)))) That's around line 3276 in [2]. The other definitions of array operations are similarly simple. Then we get to proving the classic four axioms of arrays. Around 3000 lines later, the classic four "axioms" of arrays have been proved. Much grinding through special cases. It's a neat result, but bulky. So I submitted a paper to JACM. Reviewer comments included "I hate to see something this complicated at the foundations of computer science", and just "This is unnecessary." People were really upset by all that case analysis. The theoretical problem was that I didn't have set theory. I could have built up set theory first, before array theory, then used set theory to prove array theory. That probably would have made mathematicians happier. Or not. Set theory is traditionally axiomatic, but it can be built up from constructive Boyer-Moore tuple theory if desired. I didn't argue with the reviewers. I probably could have found a more elegant path to this result, by creating intermediate lemmas, rather than letting the prover grind through the cases on automatic. But I wasn't going for a PhD. I had real work to do at an aerospace company. So, I've been beaten on by the academic community for a bulky machine proof. Today, nobody would be bothered by this approach. It's only a few thousand lines, and a human can follow it. You can be too early. (You can still run this prover today. I converted it to GNU Common LISP a decade ago. It takes about one second on a modern machine to go from the Peano-like axioms to array theory. It took 45 minutes on the VAX 11/780 I was using back in the early 1980s.) [1] https://github.com/John-Nagle/nqthm [2] https://github.com/John-Nagle/pasv/blob/master/src/work/temp...

This is a nice spin on the Aaronson oracle: > In a class I taught at Berkeley, I did an experiment where I wrote a simple little program that would let people type either “f” or “d” and would predict which key they were going to push next. It’s actually very easy to write a program that will make the right prediction about 70% of the time. Most people don’t really know how to type randomly. They’ll have too many alternations and so on. There will be all sorts of patterns, so you just have to build some sort of probabilistic model. Even a very crude one will do well. I couldn’t even beat my own program, knowing exactly how it worked. I challenged people to try this and the program was getting between 70% and 80% prediction rates. Then, we found one student that the program predicted exactly 50% of the time. We asked him what his secret was and he responded that he “just used his free will.”

I wrote "CGI Programming Unleashed" when I was 16, a scant 31 years ago (it was published in 1996, but not written in 1996). So this sort of brings me back. Almost as much as watching people review the book 20 years later and be like "it seems dated". I think the conclusion that CGI made sense to die then but not now is probably correct, but for a different reason. The main reason CGI died in large part is because it wasn't fast enough. Not the only reason for sure, but this is the general consensus. Spawning cgi children was slow, etc. Solutions were built to do in-process CGI, or separate CGI daemons. This even happened per-language with in-process CGI support for Perl, etc. In the end, as people wanted more speed, they moved away from CGI to various other ways of doing things (client side, etc). This aspect probably no longer makes sense - i'd be shocked if you couldn't make CGI "fast enough" these days without anywhere near as many hoops. To the degree hoops are necessary, they are probably saner to implement. That doesn't mean folks should move back to CGI of course - but as i said, it is probably accurate that the main reason it died probably does not hold up anymore.

I was the Associate Product Manager assigned to Orkut as it prepared to launch. It was not 20% of his time ;-) Orkut was the backup name we had to go with because we couldn't reach a deal to get the name he wanted (eden.com) from a domain squatter.

I was in Amsterdam for the weekend and it was freezing. I'd underpacked and didn't have a proper sweater, plus it was one of those days where shorts seemed appropriate in the morning, gloves and mittens in the afternoon - so in a frenzy I searched for something warm. There it was, in the window of some boutique .. a sweater composed of two sweaters, cut up, re-assembled so that the colour swaths represented an origami paper crane. Gregarious perhaps (I'm a shy white guy), but warm nevertheless, so I bought it. That one sweater has gotten me more compliments, and random approaches from strangers, than any other device in my life. To the point now that I keep an eye out for the origami paper crane symbol wherever I go, and now have a small collection of badges and embroideries and so on. The world wants peace. The paper crane is a great symbol for that. I've worn that sweater in very hostile environments (Palestine vs. Zionist demonstrations) and have, categorically, made friends on both sides with that symbol, alone. If you haven't learned how to fold one, I highly recommend it. Leaving it for the bar help or waiters always brings a smile ..

The thing you actually want is rejection sampling: https://en.wikipedia.org/wiki/Rejection_sampling. That Wiki page makes it sound very complicated but for this purpose our implementation can be laughably simple which has the advantage that you know why it works and can maintain it properly with confidence. Get suitably large inputs, for example if you're trying to pick integers between 2 and 11 inclusive, a nibble (half a byte) would be fine. Now, is the random input in the range you wanted? If so, you've got your answer. If not, throw this random input away and get more. Too many programmers act as though random numbers were a precious resource.

> Then at Apple's World Wide Developer Conference (WWDC) in June of 2003, along with the G5 processor and OS X 10.3 panther, Apple announced "iChat AV". This is wonderful. I love that people are still using this! I worked on iChat AV video. We also added 4-way video conferencing with H.264 support in 2004. Really did feel cutting edge back then. Lots of all-nighters in those days, hand-writing altivec and hand-optimizing h.264 to work on iMacs and iBooks that didn’t have simd..

A co-worker once went into cardiac arrest and, thankfully, survived due to another co-worker performing CPR. I held the affected co-worker's head while the CPR was being performed. I write more about the whole process here: https://x.com/alexpotato/status/2094412327785316661 Some key takeaways: - I had taken CPR many times before - I watched the entire even unfold from watching co-worker walk in to seizure like symptoms to not breathing to urinating on themselves - I essentially "froze" - This was despite having years of working in high stress environments (sports tournaments/SRE on a trading floor) - I was literally overcome by events and could not process what was happening (despite the prior training and dealing with outages etc etc) I HIGHLY recommend that everyone, at a minimum, watch a video on how to perform CPR. Even better, take a class. And even if you take a class, practice on a couch cushion every once in a while. It's just like with 911: there are stories of people in an emergency dialing 411 b/c they were overwhelmed. In other words, fire drills exist for a reason and the same concept can be used for CPR.

I remember playing a crap web game in college, kinda like gunslinger, where you try to shoot people who turn around with a gun (and not those without). When I graduated college, Ian--one of my good friends at work--ended up being one of those guys in the game! Turns out that game I was playing was built by Tom Fulp, and he was using his friends (like Ian) as characters in his games pre-Newgrounds. All that messing around with crap games on the internet paid off. He had started Newgrounds while in college, and had quit to do it. Met Tom once, and he was a cool guy, but he didn't believe in the stuff that they taught in CS. He had a long rant about how learning string diff algorithms were useless. Anyway, it turns out later on, he went back to college to finish his degree. When his classmate(s) found out who he was, this one kid was so excited to sit next to him. "Do you know who he is?!" he would exclaim to his professor, to Tom's embarrassment. I wonder if he had to do string diff algos when he went back to finish college.

It’s mainly mucus, from a piece of mouse colon that was cut open and gently flushed out, leaving the inner mucus layer attached. The actual mucus is black here by default but there is another channel you can turn on in the sidebar to see it. On top of it we added bacteria (green) and bacteria sized beads (red). On the bottom are colon lining cells (blue). The inner mucus layer of the colon was generally thought to be impenetrable to bacteria, serving as a way to protect you from the trillions of bacteria in the gut. It turns out that actually, it’s really easy for bacteria to swim through mucus by using flagella. We found some bacterial mutants that swim through mucus (the green ones). The red beads serve as a control marking the top of the mucus since they can’t get through the mucus. Find this and other images in my paper: https://pmc.ncbi.nlm.nih.gov/articles/PMC11784811/ The real question is then - if they can get through the mucus at any time, why don’t they? And there are various theories about this - which I’m happy to elaborate on this you want. The basic idea is there is a risk whenever you cross the mucus (you get closer to the immune system) and mucus actually feeds and tames bacteria over time by providing them with various sugars and things like that. But if they get desperate/starve, then they will cross. Mucus is still a mystery - there are substructures within mucus, take a look at this image for example: https://mucus-atlas-viewer.pazimzadeh.chatgpt.site/?sample=f... And here is a good paper too from my collaborator (who actually took these images) who discovered a sub-type of mucus and mucus-producing cells: https://pubmed.ncbi.nlm.nih.gov/33859001/

So titanium alloys are not completely resistant to all forms of corrosion. They are particularly prone to galvanic corrosion, which means that specific tools must be used, all forms of ferritic contamination must be avoided, special tools must be used, and they must be stored separately, etc. This is very labour-intensive, which is why it is generally carried out in dedicated workshops, with specialised equipment, and so on, by staff who have been specifically trained and do nothing else. If you add jigs, production-specific tools, and so on, all of that has been lost and needs to be recreated: staff need to be trained, QA defined and workshops need to be reorganised. This can take decades to return to the expected standard. You can throw as much money at this sort of problem as you like without actually being able to speed things up. Finding the drawings and dimensions is the easy part of reverse engineering a mechanical device. The real challenges lie in identifying the manufacturing processes and quality control procedures, and achieving the expected performance with an acceptable scrap rate. If I place a monocrystalline turbine blade on your desk, you’d be able to draw up the plans for it. But that would tell you absolutely nothing about the processes required to produce a monocrystalline ingot of a nickel superalloy. Source: former mechanical engineer in the nuclear industry, managing obsolescence was one of my day-to-day tasks.

As the co-founder of Sincerely (at this time in 2011), I remember this keynote very specifically because it felt like we'd been Sherlocked. We were busy building out Postagram and Sincerely Ink, both from-iPhone-to-printed-card apps. afaik we were the first app to do this, and we were at that time gaining a lot of momentum. I remember seeing the announcement for Cards and feeling a mix of fear and anger that it felt like Apple was using their clout to take our idea. I seem to recall my co-founder being somewhat more optimistic about the whole thing. And sure enough, we found that the announcement really only seemed to boost awareness. Apple Cards was an extremely limited and flawed product, and we already had some distinct technical and feature set advantages. It was clear Apple didn't have their heart in it nor know what they were doing. When they retired it shortly thereafter it wasn't a shock, and I ironically recall feeling somewhat sad.

[I work on Claude Code] I broadly agree with the author’s point: plan mode was useful, and is no longer useful. In Claude Code, all plan mode does is add a little reminder to every user message along the lines of “you’re in plan mode, please don’t code yet”. It’s something I came up with late on a Sunday night many months ago, when I got tired of asking Claude to plan with me first before coding in each new session. Something people might not realize is plan mode has always been a prompt — it has never changed the toolset because doing so would break the prompt cache, and so would be expensive for users. This worked well for a while, until a few months ago, using early versions of Fable, I realized that I wasn’t using plan mode anymore because the model just got it, and because for the increasingly complex work I asked the model to do, planning had become interactive and iterative. With Opus 5.5, I feel Opus has gotten to that point too. For codebase understanding, I sometimes ask Claude to generate an artifact that explains some aspect of its changes. For complex diffs to core parts of the system, I will often ask it to make diagrams or even interactive demos so I can better understand the change and alternatives considered. I don’t do this very often, but it’s a useful way to explain code when you need it. I ask Claude to attach these artifacts to its PRs also, so others can understand and future Claudes have the context.

A certain nuclear power plant had a Windows NT 4.0 machine running as late as 2007. The reason is interesting. The machine's purpose was to report status of the control rods that mitigate nuclear reactions. Basically, "are the rods inserted, and if so, how many / how far?". I want to emphasize that this was reporting only, NOT control. The original software was written back in the 80's, when the plant was originally commissioned, for AmigaOS. Of course, it's hard to buy Amigas anymore, and the original one died long ago (nobody remembers when). So in the mid '90s, the utility purchased an AmigaOS emulator that ran on Windows NT 4.0, which was current at the time. The emulator (IIRC) was developed by a firm in the UK. The firm went out of business sometime in the late '90s. The control rod monitoring software ran under this emulator on top of NT4. Windows NT 4.0 was the last OS to allow the emulation software direct access to the physical hardware that produced the status signal. Later versions of Windows abstracted the hardware access away, and the monitoring software broke. Because the emulation company had gone belly up, there was no way to fix the incompatibility. So the utility had a choice: get new hardware/software certified (by NRC?), or keep doing what they were doing with the software (and hardware) that they had. They chose the latter. So this is how, in 2007, during a tour of the facility, I stumbled across a Pentium 1 system running an AmigaOS emulator on Windows NT 4.0 that was responsible for displaying the status of the control rods of a nuclear power plant. Spare hardware for this setup was purchased off of eBay and stocked on an adjacent shelf.

Speaking of vtables, at Kristen Nygaard's 100-year birthday celebration Bjarne Stroustrup also gave a fascinating talk after Alan Kay's, and they had some spicy back-and-forth discussion afterwards! Both call themselves Nygaard's heirs, anbd it was a delightful and respectful interplay between very different world views. Kay came to Simula as a reader, turned it into Smalltalk, and later knew Nygaard and Dahl as colleagues. Stroustrup was taught by Nygaard in person, as a student at Aarhus, and then used Simula for his PhD. Roughly: Stroustrup said he never took much from Smalltalk. What he took from Simula was the static part, compile-time guarantees and a direct map to hardware with zero-overhead abstraction, and C++ was never meant to be just an object-oriented language, since not everything is a class hierarchy or a virtual function. Kay argued that late binding pays for itself because the human is the slow part of an interactive system, and that static typing is a good idea applied prematurely. They agreed that the real job of an operating system or the internet is never to crash and never lose anything, and came at it from opposite ends: Stroustrup is working on guarantees against dangling pointers, out of range access, and uninitialized memory in C++, while Kay pointed out that Smalltalk protected every object dynamically. Alan Kay's talk: https://au.cloud.panopto.eu/Panopto/Pages/Viewer.aspx?id=fe0... Bjarne Stroustrup's talk: https://au.cloud.panopto.eu/Panopto/Pages/Viewer.aspx?id=fe0... The discussion afterwards: https://au.cloud.panopto.eu/Panopto/Pages/Viewer.aspx?id=fe0... If you hate llm generated summaries then you can stop here and go watch the entire video yourself, but here are timestamps and summaries for people who don't have five hours to spare (although I highly recommend it -- I was watching it in real time when I witnessed the feedback performance between talks): 4:56:49: Stroustrup says he was never much inspired by Smalltalk. What he took from Simula was the static part: compile-time guarantees. "It would be nice to say yes, but to be honest, not much." 4:58:25: Stroustrup on garbage collection versus scope-based resource management (RAII): nobody has managed to combine them. Java's finalizers are his example, and somene mentions Lars Bak, "also from here" (Aarhus), says never use finalizers, they're evil. 5:00:24: Banter. Someone asks whether there's anything he likes about Smalltalk, and the reply is "Anything you like about me?" 5:00:47: Kay agrees reuse isn't a good reason for much, asks why people cling to old languages, and brings up the CrowdStrike crash taking down hospitals. 5:02:05: Stroustrup says CrowdStrike was a violated configuration rule, not a language problem. Programmers and managers are conservative and "confuse familiar with simplicity." He's not saying C++ is right for everything, and Python's all-dynamic approach is successful. 5:04 to 5:06: Kay says late-bound slowness pays for itself because humans are the slow part of interactive computing. Computing is held back by corporate legacy, and PARC was lucky to build all its own hardware and software. 5:07: An audience question about the next ten years. Kay says operating systems and the internet put you in a different seat of responsibility: the goal is never to crash and never to lose anything. 5:08:59: Stroustrup agrees, but says he doesn't control any operating system. He's working on guarantees in C++: no dangling pointers, no out-of-range access, no uninitialized memory. 5:09:55: Kay says typing is a really good idea, just premature in its static form. Smalltalk's dynamic typing protected every object. 5:10:34: Stroustrup says it's very hard to get hardcore developers to stop believing they can crash a system. 5:11:59 to 5:13:40: Kay says the Smalltalk image was a complete operating system, and that he made a living writing microcode. The field is guilty of not keeping up with the hardware. Stroustrup says he tried to talk hardware makers into adding support features, in his PhD, and failed.

I'm a member of Market Street Railway (https://www.streetcar.org/) which does a lot of advocacy to keep these street cars maintained. Many of these cars were either purchased long ago from other cities that would have otherwise scrapped them (most of the PCCs, the long sleek ones) and others are often either preserved Muni originals or donated / purchased by Market Street Railway. Car 162 just came back into service and was purchased by Market Street Railway and worked on by volunteers (and Muni) [1] I obviously am I biased, and think this is very very cool. There are many intangibles here beyond the budget numbers; a bit of history, a bit of whimsy, a bit of color to what is often utilitarian (public transit). It certainly attracts tourists to the city (I was pretty surprised at the number of out of towners at Muni heritage weekend). But I do think it's important, not just for tourism but also as a legitimate connector along the Embarcadero corridor that otherwise has no public transit along it. Agree that a breakout of the cost of maintaining these things would be appreciated, not sure if that exists in clear terms, but I don't think it's massive. For example Car 162 was damaged in a collision in 2014, and took 12 years to fix and return to service. For many gripmen / Muni restorationists working for the city, it's a side project. And while I'm here, I'd be remiss if I didn't post an article about Maurice Klebolt, one of the biggest advocates for vintage transit in San Francisco. It describes how he acquired car 106 from the Soviet Union [2] [1]: https://www.streetcar.org/streetcars/162-162-muni-1950s-live... [2]: https://www.streetcar.org/remembering_a_trolley_titan/

I started out in a "data centre" in 1998/1999 in the North West of England. Things are radically different now. When I joined that ISP we had ~2000 subscribers, and one modem rack that could take 30 concurrent 33.6k dial-ins. The company had just been acquired by a small independent telco in Cheshire, headquartered in a small town that is most famous for a weekly farmers market and an annual steam rally. We shared that headquarters at first with the founder's other business - a dating agency for rich people in later years - and slowly took over. The building was a farmhouse of sorts. We'd turned into a rabbit warren of offices, and then, we decided to expand. First we turned one of the offices into a "machine room". We didn't even bother with fire suppression that first time, we just ripped up the carpet and laid some laminate, put some 19" racks in and got the power upgraded. The air-con was insufficient in that room and the following summer I had to wheel in portable units and had a Cisco router in there report that the inlet fan had a temperature of ~80C. That was around the same time the chief of staff was asking us why we wore jeans and t-shirts and couldn't we wear suits? No, no we could not wear suits. Bit by bit we took over more rooms through the building, we started working in a portacabin in the car park (where the neighbouring farmer's sheepdog would join us for lunch). At some point we needed to install ~20k modems, (Nortel CVX1800s - 56kbps had arrived!), and the telephone switch to run it, so somebody bought a second hand DMS100 that went into another room we had converted. By that point the dating agency had moved out. We needed another ~100 servers as well to manage email, web hosting, and so on. Those came in parts (motherboards, cases, RAM sticks, hard drives - about £500k worth in 1999 money), and we had to build them and install BSD on them (first OpenBSD, then FreeBSD, long story). We also had to make our own ethernet cables, which is where I learned I can't wire ethernet cables if my life depended on it. Within 12 months from when we started, we were handling 750,000 dial-in customers. Around September of 1999 I left and that was when the company had heard about a custom built data centre that was up for sale in Milton Keynes, so decided to move everything there. Around that time they were pouring concrete under the floors of all those rooms we'd thrown racks in because the timber floor joists (!) were starting to give way under the weight of the kit. That company got acquired and then went through a weird route, but basically it's still going as a major UK ISP. I'll keep the name private to protect the guilty. :) 2000 subscribers, and one modem rack to that and a business still operating 27 years later. A lot of sausage rolls, plenty of sticking plasters for the cuts from those shitty cases, and almost every day ending with a couple of pints in a pub somewhere. One of my old colleagues and I often think back to that being one of the best years of work in our lives. But... data centre work is horrid, dirty, hot, and underpaid for what it is. But you can - sometimes - be part of something kind of cool and fun, and something very few people get to see or understand. But there's a reason I've stuck to software ever since. :)

Sure! I worked on the digital logic that connects the rover to one of the scientific instruments on board, specifically the Mars Organic Molecule Analyser[0]. [0]https://en.wikipedia.org/wiki/Mars_Organic_Molecule_Analyser