Maybe the Chevy Tahoes were priced as the initial capex, and a maintenance and support contract covering capex and opex for the next X years with a local dealership? I’ve sometimes seen this in corporate budgeting. Some companies prefer to lock in support and maintenance in advance for a more expensive fixed price instead of pay a variable but lower price over the same time period because of the budgeting vagaries that entails.
Considering the amount of time and the number of expensive management staff involved in them I’ve seen some budgeting knife fights burn up, I see the logic.
> Real heavy hitters are actually eerily quiet. They don't have anything to prove.
I've had the rare privilege to meet former SOF soldiers from a couple different nations, and working US cowboys, ranchers and farmers. While I know there are exceptions, in my personal anecdotal experience, to a man they were all quiet in the stoic sense. Nothing to prove, indeed.
> ...whereas aerospace patents are more legitimately about hardware that indeed took years and millions to develop and optimize.
Something that leaps out at me reading through semiconductor and aerospace patents is a noticeable fraction of them are basically saying, "hey, <non-obvious process understanding that pushes our limits of comprehension of physics required> to achieve some desired effect was found to be useful, but it consumed <years and millions to develop and optimize> because it was such a convoluted journey filled with zillions of dead ends, so we want a patent on that because the end result only looks obvious in hindsight". I don't see as much of this in software at this time, though I suspect it may change in the future.
> ...governments don't know how to mandate good corporate governance...
For a very brief moment, under the existential crisis condition of total war in WW2, the US government was somehow able to corral corporate governance towards a semblance of common purpose (survival). As I understand it from historians malfeasance was still widespread, but we arguably maybe got a good enough outcome?
This is the corporate equivalent of the shirtsleeves to shirtsleeves in three generations problem. And if that corollary is true, then I suspect the remedy is similarly not entirely amenable to deterministic antiseptic metrics and processes; they're necessary but not sufficient conditions.
> Now is the time to adapt, not push back. Keep an open mind or you’ll be left behind.
That’s not the gating factor. Who picks up the liability accountability and picks up the pager duty at o’dark thirty when it breaks in production, that’s the big gate. That long tail of accountability for operational risk weeds out a ton of Eager Ethan’s who want to see something go live yesterday. Because the success of launching has many fathers while the failures in the operational long tail is an orphan.
Get them to sign up for the long tail troubleshooting operations of the product. They are after all, now the SME on the product having built 90% of it. The full promise of AI in such a world is deploying and operating an AI-forward application is an artificial distinction, and full conviction means fully committing to the operational model.
This cuts both ways. Very well-known, competitive private schools conservatively financed have a waiting list a line around the block long and can enforce high standards. Private schools that are struggling for funding can find the compromises more tempting than they can bear. Finding that difference in the moment instead of as past historical anecdotes is surprisingly hard, though if someone has come up with a formula I’m all ears.
> They never address the long-tail nature of productivity...
Mondragon tries to address this through accepting bounded inequality. 9:1 pay ratio from highest-paid to lowest-paid is allowed (still far below US median corporation 192:1 ratio). They decouple democratic ownership from operational management. They funnel profits into individual internal capital accounts in proportion to the worker's pay, payable upon retirement or dissociation from the cooperative. They heavily subsidize continuing education to lift the long tail baseline skillsets.
However, I suspect none of the above is effective without the right cultural context. The Basque region where Mondragon's cultural center of gravity still heavily draws upon and resides within, laid the fertile cultural cues the cooperative leverages. High competence individuals are rewarded within this Basque-centric cultural context with high social status, reasonable job security, and the psychological reward of building up their own community.
If that supposition is true, then the uncomfortable reality is the dominant, hyper-individualistic American cultural context will always be a poor fit to co-ops. That might be made irrelevant through demographic replacement: everywhere the hyper-individualistic culture dominates, it is currently eliminating families with no demographic end in sight. We shall see.
I want to hear James Burke of Connections [1] and his writer team to have a free wheeling discussion for a few hours on what they see will happen with LLM’s making these connections with more conscious intent a lot easier. The awesome compression of knowledge aspect of LLM’s is a far undersold aspect of the technology.
That's a fair point. The equivalent in my day was when the PDP-11 with punched paper tape for offline storage could run BASIC (and lots else), but as soon as most kids saw it couldn't drive Asteroids, their attention waned after the first few weeks. I was church mouse poor, and didn't have the cash for the coinop arcades, much less for a microcomputer back then. I took what I could get.
So the bar to clear to get to gaming is much lower now, and it makes sense fewer kids get to the point where they must tinker to get at those games.
Which brings up a point I've been wondering over the years.
Where are the hordes of kids like us back then who were content with the afternoons, evenings and wee early morning hours of endless fiddling? What I realize now is those years spent fiddling sharpened our debugging senses in both ineffable and tractable ways.
A larger proportion of the juniors I see coming through the corporate halls these days than I remember from even 10 years ago do not have that knack for fiddling, nor history when it comes up. And it shows in their debugging temperament. LLM's are making this worse.
Oh yep, looks Turing complete just not performant enough for that use case. But that’s not an issue for APT-style attacks that take their sweet time. So am I off base here?
While standalone CSS is not yet Turing complete, I worry about the new attack vector categories opened up by moving it towards that state. Already I believe attackers have a choice to spread the attack payload between CSS, HTML and JavaScript to evade current detectors and analysis at the network borders, and evade CSP's since we're well into undecidability territory, like using CSS attribute selectors if the CSP allows external images or fonts. But I'm far from proficient at web browser red teaming. Is this worry unfounded?
I use Linux exclusively on the backend, a Windows laptop is usually what my clients issue to me for gigs, and I migrated years ago from macOS to a Linux laptop as my personal primary daily driver (though I still use macOS, just not where I spend 90% of my personal time). I agree with Windows having its own issues like you pointed out. To be fair however, Linux and macOS daily driver experiences are also not without their annoyances.
The Linux daily driver windmills I am currently tilting at are the lack of 3D infrared sensor-based secure facial recognition. On Linux we currently are missing true 3D mapping, the option to bind the biometric data to the onboard TPM, and running the matching in something like the Protected Media Path stack Windows uses, so Linux facial recognition solutions like Howdy are not as secure as on Windows.
Other deep gaps in the Linux daily driver role are not having a solution to encrypt our disks and hibernate under Secure Boot, nor a comprehensive common application framework for power management like Apple's IOKit and IOPowerSources so my Linux laptop gets far less battery life than my macOS laptop. Linux has many different ways for applications to participate in power management, so as a result there isn't a single way for the applications to cooperatively negotiate for this centralized scarce resource based upon user preferences.
But the death by a thousand tiny cuts I was experiencing on macOS led me to reluctantly conclude I'd rather face the thousand tiny cuts in Linux where at least I have the option to go to the source and address or fix it myself a particular cut got annoying enough. In my clients' corporate land, I hide behind a small army of desktop teams that grind away most of the annoyances you list (mainly through the pricing discrimination magic of Windows enterprise licensing).
I've resigned myself to not hold out hope for re-experiencing what I felt was my personal peak user experience of the early 2000's PowerPC PowerBook and Intel MacBook Pro and early Mac OS X. It was a portable Unix workstation that could run a full virtual Windows box inside, giving me the best of all worlds, and It Just Works bled into every nook and cranny of the entire stack.
I believe a lot of it came down to that Steve Jobs was an intensely personal user of his own products from the perspective of someone doing it himself as much as someone who is the head of a multinational multi-billion dollar corporation could be, with as little corporate desktop support as necessary, and he had an extreme intolerance for annoyances in the small details.
Linux as a daily driver has many, many rough edges. But at least I can durably contribute into it as I solve my own annoying small details, and hope a flywheel effect eventually takes place in the future.
> Regardless of OS, they all seem extremely fast, and feel faster and faster as time goes on.
The modern throughput is faster by far. However, what some people mean when they talk about "slower" is the latency snappiness that characterizes early microcomputer systems. That has definitely gotten way worse in an empirically measurable fashion.
Dan Luu's article explains this very well [1].
It is difficult today to go through that lived experience of that low latency today because you don't appreciate it until you lived it for years. Few people have access to an Apple ][ rig with a composite monitor for years on end any longer. The hackers that experienced that low latency never forgot it, because the responsiveness feels like a fluid extension of your thoughts in a way higher latency systems cannot match.
We still don’t have truly transparent transference in locally-run software. Go anywhere in the world, and your locally running software tags along with precisely preserved state no matter what device you happen to be dragging along with you, with device-appropriate interfacing.
We still don’t have single source documentation with lineage all the way back to the code.
We still don’t treat introspection and observability as two sides of a troubleshooting coin (I think there are more “sides” but want to keep the example simple). We do not have the kind of introspection on modern hardware that Lisp Machines had, and SOTA observability conversations still revolve around sampling enough at the right places to make up for that.
We still don’t have coordination planes, databases, and systems in general capable of absorbing the volume of queries generated by LLM’s. Even if LLM models themselves froze their progress as-is, they’re plenty sophisticated enough when deployed en masse to overwhelm existing data infrastructure.
The list is endless.
IMHO our software world has never been so fertile with possibilities.
> ...nothing replaces the camraderie of the small, local BBSs.
Nothing quite replaces the drama level and drama complexity of the small, local BBSs. Especially when the denizens met in the big room with the blue ceiling.
There is no shortage of Olympic hopeful elite athletes every four years, despite the incredibly small pool of competitors at each Games.
Same for musicians.
This kind of Winner-Take-All Economics or Superstar Market is what capital wants in their ideal world in markets with near-zero marginal costs of distribution. Even if software creation in the long-term does not fall to this kind of labor market, LLM's can establish a "market can be irrational longer than you can stay solvent" dynamic where capital can run the labor market like this for software for a generation or three before having to face the reflexivity music, like they did for US manufacturing.
> The underlying assumption is that most people don't know how to write high-performance concurrent code anyway, so why not just ask them to command the AI instead.
The data economics reflexivity of LLM input means that when you reduce the future volume of that input to the few experts who "know how to write X anyway", the LLM labs just lost one of the most important inputs. All those non-experts who voted with their judgement and left in the wake of their effort to use the expert-written code, grist for the LLM input weighing mill.
I find it is usually the non-experts that run into the sharp operational edges the experts didn't think of. When you throw the non-experts out of the marketplace of ideas, you're often left with hazardous tooling that would just as soon cut your hand off than help you. It would be a hoot if the LLM's and experts decided to output everything and training in Common Lisp, though.
If handed just Babbage's Difference Engine, or the PDP-11 Unix V7 source code and nothing else, LLM's could speed-run and eventually re-derive the analogs of Zig, ffmpeg, YouTube, and themselves, I'll grant that "just let them cook with the experts" is a valid strategy. The information imparted by the activity around the source code is deeply recursive, and absent that I'm not sure how the labs are going to escape a local minima they're digging themselves into by materially shrinking that activity. If my hypothesis is correct, then LLM labs are industrial-scale stripping away the very topsoil that their products rely upon, and it is a single-turn cheap game that gets enormously more expensive in further iterations to create synthetic topsoil.
Considering the amount of time and the number of expensive management staff involved in them I’ve seen some budgeting knife fights burn up, I see the logic.