218 karma · joined May 21, 2020
My one other point is that incentivized labor is not the same as the value it creates. Indeed, it must be less. Otherwise, our economic system could support only a fixed number of people (subsistence), which would decay inevitably because there is no margin for error. But my point is that margin in reality isn’t fully realized, even by trillionaires, because then there would be no growth to support more people growing in their standard of living. There must be slack in this distributed system and the slack wasn’t valued: it’s free labor. It’s mixed in with incentivized labor, so I understand if you reject the premise entirely, but I do believe this is the essence of modern (specialized) capitalism. If skilled workers try to optimize or invent, more resources will be available for distribution for the same incentive (i.e. “worker productivity”). You can say “yeah that’s their job,” and I can say “that productivity wasn’t fully monetized because otherwise productivity would be lower overall.”
So, incentivized labor presupposes free labor, and economic productivity is a mix of free and monetized labor.
And so my point: the place where people best know how to make chips competitively in a cutthroat industry is NOT in schools, but in private companies that have signed all the NDAs. The information is literally locked away, unable to diffuse into the open where universities efficiently operate. Professors cannot teach what they don’t know or cannot legally share.
Chip design is a journeyman industry. Building fault-tolerant, fast, power-efficient, correct, debuggable, and manufacturable designs is table stakes. Because if not, there are already a ton of chip varieties available. Don’t reinvent the wheel because the intersection of logic, supply chain logistics, circuit design, large scale multi objective optimization, chemistry, physics, materials science, and mathematical verification is unforgiving.
[0]: https://infini-gram.io [1]: https://arxiv.org/abs/2410.04265v1
The telephone and electrical power networks were vast in scope (and still are), enabling interstate communication and power utilities. Echoes of the transportation utilities enabled through railroads. Multics was architected partially with the commercial goal of scaling up with users, a computing utility. But in a time with especially expensive memory, a large always resident kernel was a lot of overhead. The hardware needed a lot of memory and would be contending with some communication network whose latency could not be specified at the OS design time. Ergo, asynchronous I/O was key.
Put differently, Multics bet that computing hardware would continue to be expensive enough to be centralized, thereby requiring a CPU to contend with time-sharing across various communication channels. The CPU would be used for compute and scheduling.
Unix relaxed the hardware requirements significantly at the cost of programmer complexity. This coincided roughly with lower hardware costs, favoring compute (in broad strokes) over scheduling duties. The OS should get out of the way as much as possible.
After a bunch of failed grand hardware experiments in the 1980s, the ascendant Intel rose with a dominant but relatively straightforward CPU design. Designs like the Connection Machine were distilled into Out of Order Execution, a runtime system that could extract parallelism while contending with variable latency induced by the memory subsystem and variable instruction ordering. Limited asynchronous execution mostly hidden away from the programmer until more recently with HeartBleed.
Modern SoCs encompass many small cores, each running a process or maybe an RTOS, along with multiple CPU cores, many GPU cores, SIMD engines, signal processing engines, NPU cores, storage engines, etc. A special compute engine for all seasons, ready to be configured and scheduled by the CPU OS, but whose asynchronous nature (a scheduling construct!) no longer hidden from the programmer.
I think the article reflects how even on a single computer, the duty of the CPU (and therefore OS) has tilted in some cases towards scheduling over compute for the CPU. And of course, this is without considering yet cloud providers, the spiritual realization of a centralized computing utility.
In other words, how holistic is the metric "reading time?"
It could be from a requirements perspective: “I understand what I can build easily, but not what you want.”
It could be from an engineering perspective: “I understand what you want, but I don’t understand how to build that cohesively.”
It could be from a scientific perspective: “No one knows what tools we need to investigate this.”
I saw mentioned in other comments that CAD software doesn’t allow for sketching. As someone who was originally trained in drafting the old way, and who has used modern CAD systems to produce models for fantastically large physical simulations, I largely agree that sketching is lost. But the sketching that I can do on paper is just not at the same level of complexity as I can kinda do on my computer.
But the complexity of using the new tool obscures the fact that my model is much more complicated than I could otherwise manage using old tools. And that’s because I’m still learning. In fact, I have to “deploy” while I’m still in learning mode about a problem, unlike before, where I had to understand the problem in order to use the tools to draft the thing.
Being able to do something with a half-formed idea sounds like sketching, but when non-experts rely upon it, it’s pretty fragile. Because it wasn’t done.
Building a memex (something the author disparages multiple times) is super hard because we still don’t understand how to represent ideas separately from language, our original mental sketching tool. But people built Altavista and Google and LLMs anyway. And yeah, they’re super complex.
How does TCP/IP work over wireless connections? Poorly and with a lot of complexity. Why? Because the concept of a connection is ill-defined when communication relies on ephemeral signaling.
But despite the complexity, it is useful and fun to use only half-baked ideas. Just like it’s fun to use language to describe stuff I don’t understand, but merely experience. Graduation. Being a parent to a sick child. Losing a loved one.
As for detecting unauthorized apps, I would imagine that once you’ve taken over control of the OS kernel, it’s game over for such software-based restrictions. The Halting theorem guarantees such limitations to any software-based restriction. And as long as you can form a Turing complete mechanism from pieces of the computer, such software limitations will apply.