yourapostasy

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.

private schools can run how they want...

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.

Not all tools need to be used everyday. I can't remember the last time I used my 3/8" wrench.

Now our 10mm sockets on the other hand, would be used everyday if we could ever lay our hands on one when we need them.

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.

[1] https://en.wikipedia.org/wiki/Connections_(British_TV_series...

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?

Thank you Kind Internet Stranger!

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.

[1] https://danluu.com/input-lag/*

Oh ye of little faith in the possible.

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.

Money and fame. Lots of money and fame.

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.

Even as the field evolves, the phoning home telemetry of closed models creates a centralized intelligence monopoly. If open source atrophies, we lose the public square of architectural and design reasoning, the decision graph that is often just as important as the code. The labs won't just pick up new patterns; they will define them, effectively becoming the high priests of a new closed-loop ecosystem.

However, the risk isn't just a loss of "truth," but model collapse. Without the divergent, creative, and often weird contributions of open-source humans, AI risks stagnating into a linear combination of its own previous outputs. In the long run, killing the commons doesn't just make the labs powerful. It might make the technology itself hit a ceiling because it's no longer being fed novel human problem-solving at scale.

Humans will likely continue to drive consensus building around standards. The governance and reliability benefits of open source should grow in value in an AI-codes-it-first world.

We're probably close enough to a future with the technology and engineering able to implement it, to justify designing 48-bit perceptual bit depth standards. Optimistically presuming breakthroughs enabling in vivo biological upgrades to our eyes to match those of mantis shrip, we could design 160-bit standards knowing that is a "proven" biological technology capability. That gets within the same galactic supercluster of the known limits of physics limits.

At the currently known limits of physics where Heisenberg Uncertainty Principle, Abbe's Limit, Quantum Shot Noise and such become our sensing barriers, we suspect we need only about 6000 bits per pixel to represent a digital twin of the electromagnetic field of the sensor-covered volume of space. At 60 fps, that is 1.8 Zettabits per second. Scale out data volume accordingly when using using 18.5 sexdecillion fps (Planck time fps).

What surprises me is these "limits of the fabric of reality as we know it" mind experiments fairly concretely point the way on the many roads towards Kardashev Scale implementations, and is not that different from Archimedes' "Sand Reckoner" and Hindu cosmological Kalpa time scales. History doesn't quite repeat, but rhymes yet again.

LLMs are merely copying these decisions.

This I strongly suspect is the crux of the boundaries of their current usefulness. Without accompanying legibility/visibility into the lineage of those decisions, LLM's will be unable to copy the reasoning behind the "why", missing out on a pile of context that I'm guessing is necessary (just like with people) to come up to speed on the decision flow going forward as the mathematical space for the gradient descent to traverse gets both bigger and more complex.

We're already seeing glimmers of this as the frontier labs are reporting that explaining the "why" behind prompts is getting better results in a non-trivial number of cases.

I wonder whether we're barely scratching the surface of just how powerful natural language is.

The challenge not addressed with this line of reasoning is the required sheer scale of output validation on the backend of LLM-generated code. Human hand-developed code was no great shakes at the validation front either, but the scale difference hid this problem.

I’m hopeful what used to be tedious about the software development process (like correctness proving or documentation) becomes tractable enough with LLM’s to make the scale more manageable for us. That’s exciting to contemplate; think of the complexity categories we can feasibly challenge now!

In the enterprise deployments of GitHub Copilot I've seen at my clients that authenticate over SSO (typically OIDC with OAuth 2.0), connecting Copilot to anything outside of what Microsoft has integrated means reverse engineering the closed authentication interface. I've yet to run across someone's enterprise Github Copilot where the management and administrators have enabled the integration (the sites have enabled access to Anthropic models within the Copilot interface, but not authorized the integration to Claude Code, Opencode, or similar LLM coding orchestration tooling with that closed authentication interface).

While this is likely feasible, I imagine it is also an instant fireable offense at these sites if not already explicitly directed by management. Also not sure how Microsoft would react upon finding out (never seen the enterprise licensing agreement paperwork for these setups). Someone's account driving Claude Code via Github Copilot will also become a far outlier of token consumption by an order(s) of magnitude, making them easy to spot, compared to their coworkers who are limited to the conventional chat and code completion interfaces.

If someone has gotten the enterprise Github Copilot integration to work with something like Claude Code though (simply to gain access to the models Copilot makes available under the enterprise agreement, in a blessed golden path by the enterprise), then I'd really like to know how that was done on both the non-technical and technical angles, because when I briefly looked into it all I saw were very thorny, time-consuming issues to untangle.

Outside those environments, there are lots of options to consume Claude Code via Github Copilot like with Visual Studio Code extensions. So much smaller companies and individuals seem to be at the forefront of adoption for now. I'm sure this picture will improve, but the rapid rate of change in the field means those whose work environment is like those enterprise constrained ones I described but also who don't experiment on their own will be quite behind the industry leading edge by the time it is all sorted out in the enterprise context.

Non-technical home users in my circles are fed up with Windows 11's changes from Windows 10 without a suitable transition that eases them into the changes. They are nowhere near good candidates to migrate to any flavor of Linux, though. There are still plenty of sharp edges. So lots of cursing and griping at Windows 11 continues.

More interesting to me however, are the macOS technical friends in my circles. A trickle of them are switching to various Linux desktop distributions. This was inconceivable to me a mere 10 years ago. But I have to admit the quality of the Apple ecosystem has slid an astounding amount, which is driving the more advanced technical users into the arms of Linux. There are still plenty of Apple ecosystem-specific integration points and features that are still not available on Linux, like Apple Notes/iMessage/AirDrop/AirPlay/Handoff between macOS and iOS, system-wide kinetic/momentum scrolling, iCloud sync, system-comprehensive battery management that includes working sleep and suspend, advanced trackpad gestures, uneven Unicode support, uneven human interface guideline adherence, limited laptop LLM inference, etc. So I'm not expecting this trickle to turn into a flood soon, but the solid lock Apple used to have on developer mindshare is not as solid any longer.

With the Netflix infrastructure, I'm surprised they broadcast it so conventionally. Different channels running at the same time (with the crowd at the bottom, with the crowds as he passed each floor, with his wife watching, with pro climbers talking technical climbing stuff with simultaneous 8K online illustrating graphics, etc.), different audio tracks (with commentators, with crowd at bottom only, etc.*). Alex Honnold was paid only $500K for the event, so maybe there simply wasn't a lot of money allocated to the project to get fancy with the live broadcast.

Inference leans heavily on GPU RAM and RAM bandwidth for the decode phase where an increasingly greater amount of time is being spent as people find better ways to leverage inference. So NVIDIA users are currently arguably going to demand a different product mix when the market shifts away from the current training-friendly products. I suspect there will be more than enough demand for inference that whatever power we release from a relative slackening of training demand will be more than made up and then some by power demand to drive a large inference market.

It isn’t the panacea some make it out to be, but there is obvious utility here to sell. The real argument is shifting towards the pricing.

I am satisfied when someone tells us we cannot change requirements, to get their acknowledgement that what we bring up does extract a specific trade-off, and their reason for accepting the trade-off, then recording it into design and operational documentation. The moment many people recognize this trade-off will be explicitly documented with their and their team's accountability in detail, is when you surface genuine trade-offs made with the debt to pay off in the future in mind and in the meantime a rationale to grant a ton of leeway to the team burdened with the externality going forward, and trade-offs made without understanding their externalities upon other teams (which happens a tremendous amount in large organizations).

Most of the time, people are just very reasonably and understandably focusing tightly on their lane and honestly had no idea of the externalities of their conclusions and decisions, and I'm happy to have experienced all those times a rebalancing of the trade-offs that everyone can accept and is grateful to have documented to justify spending the story points upon cleaning up later instead of working on new features while the externality debt's unwanted impact keeps piling up.

In fewer than a handful of times, I run into people deliberately, consciously with malice aforethought of the full externalities making trade-offs for the sake of expediently shifting burdens of of them without first consulting with partner teams they want to shift the burdens onto, simply so they can fatten their promo packet sooner at the expense of making other teams look worse. Getting these trade-offs documented about half the time makes them back down to a more reasonable trade-off, about half the time they don't back down but your team is now protected by explicit documentation and caveats upon the externality your team now has to carry, and 100% of the time my team and I put a ring fence upon all future interactions with that personality for at least the remaining duration of my gig.

I am hopeful autodidacts will leverage an LLM world like they did with an Internet search world from a library world from a printed word world. Each stage in that progression compressed the time it took for them to encompass a span of comprehension of a new body of understanding before applying to practice, expanded how much they applied the new understanding to, and deepened their adoption scope of best practices instead of reinventing the wheel.

In this regard, I see LLM's as a way for us to way more efficiently encode, compress, convey and enable operational practice our combined learned experiences. What will be really exciting is watching what happens as LLM's simultaneously draw from and contribute to those learned experiences as we do; we don't need full AGI to sharply realize massive benefits from just rapidly, recursively enabling a new highly dynamic form of our knowledge sphere that drastically shortens the distance from knowledge to deeply-nuanced praxis.