11,113 karma · joined March 10, 2009
Résumé: CMU (Mach, Coda) -> Apple (Newton) -> Microsoft (Windows, IE, MSN, etc.) -> Jackson Fish Market (adorable consumer apps) -> CareZone (helping you manage healthcare) -> Walmart (still healthcare, but bigger) -> Invaio (healthcare for plants) -> consulting
Send mail to user walter on host waltersmith.us.
http://waltersmith.us/ (if it's not broken)
Not to mention, they simultaneously said it was a supply chain risk and that it would continue to be used by agencies that were already using it in a critical capacity. Which makes absolutely no sense.
That’s going to make it rather risky for anyone to sign licenses with the DoD. In fact, it renders the licenses pointless since you just have to do anything the licensee says.
One example was a site that had fiber and coax, from different companies. They might have shared a pipe at some point along their length, hard to say. But both connections went down at the same time for digital reasons, not physical. The providers had simultaneous unrelated backend router problems and the site lost contact to both gateways.
This was with a nice SD-WAN system that routed everything dynamically across both pipes to address latency and errors, but if the packets get dropped at the first hop in both networks, there's not much you can do!
The saving grace in that case was the third redundant connection, a 4G cell modem, with a lot less bandwidth but able to keep the critical transactions going. These days I'd certainly want Starlink on the roof as well.
The focus on building stuff as the measure of accomplishment is one reason I so enjoyed being at CMU a few decades ago, so I'm very happy to see this sentiment is still expressed by the new generation of faculty.
“the question it raises matters more than the answer” ???
“So ‘the river drifts from cool to warm’ is not a figure of speech.” Oh really?
The whole thing is organized around building explicit abstractions. You’re always making models, and choosing what to pay attention to and what to ignore. By making the real circuit match the model closely enough, you get to ignore the circuit and use it as building block for bigger things. This same approach is used from resistors to amplifiers to logic gates to CPUs.
Of course this how engineering actually works, but I haven’t seen an intro course presented this way so rigorously. If you’re a software person who deals with black box abstractions all day, it feels like home.
The course introduces concepts in order of simplicity, meaning you get MOSFETs and digital gates before you get BJTs. Many courses are arranged chronologically, so after you do Ohm’s law and capacitors you get dumped into BJTs, which are one of the most complicated things in the discrete toolkit, and hardly ever found in common use nowadays (except as cheap switches). Instead, you’re happily making amplifiers, switches, and logic with FETs, a much gentler introduction.
I also remember somewhere in the course lectures the professor says (paraphrased) “You may be thinking, why do I need to learn how a logic family works? Won’t I just be using some existing chip? This is MIT — you’re supposed to be the one making the chip.”
Whew, good thing it’s too late to be accountable for that now, huh? Water under the bridge. Mistakes were made. Eggs, omelets.
As a random sample of one, I looked at one of the bugs this reported on Tailscale (first thing on the homepage) [0], and the pull request ends with "Apologies for the lack of due diligence here. I'll go ahead and close this out."
This misses the point entirely. If you know proposition X is true or false, you won’t bother spending years trying to prove or disprove it, developing deep understanding and potentially even developing entire new fields of math in the process. (See FLT.)
That’s why it’s so destructive to the discovery process to have an LLM just generate a proof or counterexample without the side effect of generating useful explanatory or generative structures that we can build on.
That said, there are examples like Ramanujan where someone did an info dump of unexplained theorems that people try to mine useful structures from, but that’s not at all the mainstream of mathematical progress.
By essentially the same reasoning, I’ve been arguing for prioritizing in-person design/code reviews over code-only async PR comments.
The important thing is to verify that the human has a coherent design in mind and can demonstrate that it got implemented, regardless of who or what was at the keyboard. “I dunno, I guess Claude thought this was a good idea” is not a coherent design.
My impression from audio developers is that the audio infrastructure is very badly documented (like so much of MacOS nowadays) and using it properly requires a combination of luck, WWDC videos, and devrel threads. Also, Apple introduces changes that are genuine improvements in theory, but break undocumented assumptions.
The lack of rigor is a bit surprising given that audio is probably the only mission-critical hard-real-time thing MacOS does. People routinely run an entire live concert on a Mac and an audio glitch is not OK! (Yes, if it’s Taylor Swift budget then there are at least two machines in sync with a big red button to switch over…)
But given what they’re dealing with, I understand why it’s more involved than just “the developers didn’t try the betas”.
Um, hang on, if you meant that to be taken literally then we have a major problem. If you want to do something criminal, you just need to ask ChatGPT to do it for you?
I’m still not at all clear on why OpenAI shouldn’t be facing CFAA charges over this.
The PARC interface (by which I guess you mean the Xerox Star) had significant differences, and I think would confuse any modern computer user far worse than the Finder. The Lisa was closer to the Star but the Mac used a simplified model that just equated files to icons.
Source: I lived through this process and used all of these for actual work at some point. The Finder’s influence on GUI file management was rather like the iPhone’s influence on phone management.