https://www.aaup.org/brief/columbia-university-364-nlrb-no-9...

I think Douglas Hofstadter satisfactorily answered this question.

> We can't even answer if we have free will or not.

Sure we can, it's just that most people don't like the answer.

He didn't prove anything. It's a theory, just like many others: https://plato.stanford.edu/entries/consciousness-higher/

> Sure we can, it's just that most people don't like the answer.

Again, not proven

Don't mistake continued debate amongst "experts" as being a signal that something is unsettled.

[1]: I imagine this includes things like mental heath help, housing, and other related social safety nets.

This is far from true. On the experimental side, gate fidelities and physical qubit numbers have increased significantly (a couple of orders of magnitude). On the theory side, error correction techniques have improved astronomically -- overhead to of error corrections has dropped by many orders of magnitude. On the error correction side progress has been feverish over the last 4 years in particular.

If they buy startups, a thousand more will spring up hoping to be bought. Investors love this game.

And if you think undercutting works, read up on the story of Dow and how they broke the German bromine monopoly [1].

There is no such thing as a natural monopoly. Only governments can create monopolies, usually through regulation.

[1] https://en.wikipedia.org/wiki/Herbert_Henry_Dow#Breaking_a_m...

Bleeding edge gaming and multiplayer anti-cheat is one area where I think having a big company owning the OS probably helps them stay ahead, as that structure probably lets them work with hardware designers to get the capabilities in use (i.e. in new versions of DirectX) and available to software developers first. There's generally a lag in adoption for new features within Vulkan and then usage downstream in wine/proton to get compatibility parity with windows, then the games themselves being able to run feature/performance parity. It'd be interesting to see what cooperation would be needed to have the linux gaming stack equal at the point new features are released, and with the least amount of manual hacks or command line tweaking required for the users. As discussed a few weeks back, tough anti-cheat for linux seems like a paradox with the current methods.

Microsoft doesn't give a fuck about private customers any more. They don't have money.

What has money though is enterprise/government sales, and MS got these customers tightly locked in. Compliance audits and tooling for insurances or legal stuff (SOX, GDPR, ...) are built against a full Microsoft stack of MS Server, Active Directory, Azure, Teams, Office 365 and Windows desktops.

You might be able to get away with replacing AD and GPO with Samba servers but even that is already a pain when the auditors come knocking. Everything else? There is no single FOSS based "standard offering" (i.e. a combination of everything needed to run an on-prem enterprise site, Office replacement, remote collaboration tooling), so every audit for such setups must be custom made and involves a lot of extra work.

A second leg is industrial control machines, medical devices and the likes. That's all stuff built by third party vendors and integrators. They need to continue on Windows because switching to an alternative OS would require redoing everything from scratch on the software and certification side. These customers buy the LTSC IoT stuff.

And that is why you see Microsoft pushing enshittification so hard on private customers... extract the last few cents you can from them. But the real money comes from the large customers.

WSL is already there for the folks that want to play with Linux.

Secondly, I do acknowlege your 40k reference.

The same with some multimedia CD's from its day. Scummvm it's partially implementing Macromedia Director support but the mentioned game had a custom engine. The Scummvm devs would RE in few weeks (it's a simple 2D game bundle, nothing difficult, with virtually no animations, almost everything it's still images) but no one began yet.

AFAICT, Wine can run WIN16 programs. I don't know if it can run DOS programs. There's a WineHQ wiki page that says it can load DOS programs, but various internet fora seem to believe that Wine's DOS support is pretty broken. I've never tried it, and have no DOS programs handy, so I can't verify those claims.

https://arstechnica.com/gaming/2025/06/games-run-faster-on-s...

Finally some embrace, extend, and extinguish love right back at Microsoft!

For x86, that's Windows. For mobile/VR, it's Android.

What glibc does not provide is forward compatibility. An application built with glibc 2.12 will not necessarily work with any older version.

Such application could be rebuilt to work with an older glibc as the API is stable. The ABI is not which is why the application would need to be rebuilt.

glibc does not provide ABI compatibility because from their perspective the software should be rebuilt for newer/older versions as needed. Maintaining a stable ABI mostly helps proprietary software where the source is not available for recompilation. Naturally the gnu guys building glibc don’t care about that use case much.

I guess you didn’t mention glibc in your comment but I already typed this out

Is this correct? I think you perhaps have it backward? If I compile something against the glibc on my system (Debian testing), it may fail to run on older Debian releases that have older glibc versions. But I don't see why an app built against glibc 2.12 wouldn't run on Debian testing. glibc actually does a good job of using symbol versioning, and IIRC they haven't removed any public functions, so I don't see why this wouldn't work.

More at issue would be the availability of other dependencies. If that old binary compiled against glibc 2.12 was also linked with, say, OpenSSL 0.9.7, I'd have to go out and build a copy of that myself, as Debian no longer provides it, and OpenSSL 3.x is not ABI-compatible.

> glibc does not provide ABI compatibility because from their perspective the software should be rebuilt for newer/older versions as needed.

If true (I don't think it is), that is a hard showstopper for most companies that want to develop for Linux. And I wouldn't blame them.

If the application is built against 2.12 it may link against symbols which are versioned 2.12 and may not work against 2.11 - the opposite (building against 2.11 and running on 2.12) will work

>If true (I don't think it is), that is a hard showstopper for most companies that want to develop for Linux.

Not really a show stopper, vendors just do what vendors do and bundle all their dependencies in. Similar to windows when you use anything outside of the win32 API.

The only problem with this approach is that glibc cannot have multiple versions running at once. We have “fixed” this with process namespaces and hence containers/flatpak where you can bundle everything including your own glibc.

Naturally the downside is that each app bundles their own libraries.

that's not correct. libraries have versions for a reason. the only thing preventing the installation of multiple glibc versions is the package manager or the package versioning.

this makes building against an older version of glibc non-trivial, because there isn't a ready made package that you can just install. the workarounds take effort:

https://stackoverflow.com/questions/2856438/how-can-i-link-t...

the problem for companies developing on linux is that it is not trivial

So in practice you can only have 1 linker, 1 glibc (unless you do chroot or containers and at that point just build your stuff in Ubuntu 12.04 or whatever environment)

In the context of games, that will likely be Steam Runtime.

the only way to achieve that is to get the older libraries installed on a newer system, or you could try backporting the new toolchain to the older system. but that's a lot harder.

From a bit of research it looks like FreeBSD for example only provides a stable ABI within minor versions and I imagine if you build something for FreeBSD 14 it won’t work on 13.

Stable ABI literally only benefits software where the user doesn’t have the source. Any operating system which assumes you have the source will not prioritize it.

(Edit: actually thinking harder MacOS/iOS is actually much worse on binary compatibility, as for example Intel binaries will stop working entirely due to M-cpu transition - Apple just hits developers with a stick to rebuild their apps)

> Stable ABI literally only benefits software where the user doesn’t have the source.

It also benefits people who don't want to have to do busywork every time the OS updates.

At Yahoo, we'd build on 4.3-4.8, and run on 4.x - 8.x. At WhatsApp, I think I remember mostly building on 8.x and 9.x, for 8.x - 11.x. The only thing that I remember causing major problems was extending the bitmask for CPU pinning; there were a couple updates where old software + old kernel CPU pinning would work, and old software + new kernel CPU pinning failed; eventually upstream made that better as long as you don't run old software on a system with more cores than fit in the bitmask. I'm sure there were a few other issues, but I don't remember them ...

Stable ABI benefits everyone. If I need to recompile a hundred packages with every OS update instead of doing real work then there's something seriously wrong with my OS.

By that point they already hit the developers enough to get them to port to aarch64

(arguably though this could be a special case because it is due to architectural transition)

I ask because my current laptop is getting long in the tooth, and if I were just buying it for productivity stuff, the current MBPs are beasts, but last time I checked years ago, gaming on os x was in a sad state, even compared to linux.

Apple may require rebuilds at some point for their Mac Store (or whatever they call it), but it's not required from a technical perspective.

The one exception here is CPU architecture changes, and even then, Apple has provided seamless emulation/translation layers that they keep around for quite a few years before dropping support.

https://developer.apple.com/support/xcode/

for example here is a 20 year old binary of the game mirrormagic that runs just fine on my modern fedora machine:

    ~/Downloads/mirrormagic-2.0.2> ldd mirrormagic
        linux-gate.so.1 (0xf7f38000)
        libX11.so.6 => /lib/libX11.so.6 (0xf7db5000)
        libm.so.6 => /lib/libm.so.6 (0xf7cd0000)
        libc.so.6 => /lib/libc.so.6 (0xf7ad5000)
        libxcb.so.1 => /lib/libxcb.so.1 (0xf7aa9000)
        /lib/ld-linux.so.2 (0xf7f3b000)
        libXau.so.6 => /lib/libXau.so.6 (0xf7aa4000)
    ~/Downloads/mirrormagic-2.0.2> ls -la mirrormagic
    -rwxr-xr-x. 1 em-bee em-bee 203633 Jun  7  2003 mirrormagic

The real magic of LLMs comes when they iterate until completion until the code compiles and the test passes, and you don't even bother looking at it until then.

Each step is pretty stupid, but the ability to very quickly doggedly keep at it until success quite often produces great work.

If you don't have linters that are checking for valid syntax and approved coding style, if you don't have tests to ensure the LLM doesn't screw up the code, you don't have good CI, you're going to have a bad time.

LLMs are just like extremely bright but sloppy junior devs - if you think about putting the same guardrails in place for your project you would for that case, things tend to work very well - you're giving the LLM a chance to check its work and self correct.

It's the agentic loop that makes it work, not the single-shot output of an LLM.

There are techniques that can help deal with this but none of them work perfectly, and most of the time some direct oversight from me is required. And this really clips the potential productivity gains, because in order to effectively provide oversight you need to page in all the context of what's going on and how it ought to work, which is most of what the LLMs are in-theory helping you with.

LLMs are still very useful for certain tasks (bootstrapping in new unfamiliar domains, tedious plumbing or test fixture code), but the massive productivity gains people are claiming or alluding to still feel out of reach.

For instance, if you are working on a compiler and have a huge test database of code to compile that all has tests itself, "all sample code must compile and pass tests, ensuring your new optimizer code gets adequate branch coverage in the process" - the underlying task can be very difficult, but you have large amounts of test coverage that have a very good chance at catching errors there.

At the very least "LLM code compiles, and is formatted and documented according to lint rules" is pretty basic. If people are saying LLM code doesn't compile, then yes, you are using it very incorrectly, as you're not even beginning to engage the agentic loop at all, as compiling is the simplest step.

Sure, a lot of more complex cases require oversight or don't work.

But "the code didn't compile" is definitely in "you're holding it wrong" territority, and it's not even subtle.

But honestly I think sane code organization is the bigger hurdle, which is a lot harder to get right without manual oversight. Which of course leads to the temptation to give up on reviewing the code and just trusting whatever the LLM outputs. But I'm skeptical this is a viable approach. LLMs, like human devs, seem to need reasonably well-organized code to be able to work in a codebase, but I think the code they output often falls short of this standard.

(But yes agree that getting the LLM to iterate until CI passes is table-stakes.)

I think getting good code organization out of an LLM is one of the subtler things - I've learned quite a bit about what sort of things need to be specified, realizing that the LLM isn't actively learning my preferences particularly well, so there are some things about code organization I just have to be explicit about.

Which is more work, but less work than just writing the code myself to begin with.

If you read my post, you’d see that Claude code didn’t do that, I had to intervene in the agent loop and when I did it undid my fixes.

In fact, I find that with a strict feedback loop set up (i.e. a lot of lint rules, a strict type checker and fast unit tests), it will almost always generate what I want.

As someone else said, each step might be pretty stupid, but if you have a fast iteration loop, it can run until everything passes cleanly. My recommendation is to specify what really counts as "done" in your AGENTS.md/CLAUDE.md.

I didn't give my Agent any tools, it hallucinated code.

...well, yes. It's like evaluating a programmer's skill by having one-shot a program on paper with zero syntax errors.

And this was from two people who were 100% aligned on agentic AI coding. I've been using AI for years now and agentic AI for several months now. I was told that I bring out the worst in LLMs. Except... I was able to achieve better results, WITH LLMs, on OTHER frameworks. So like, ?

It may be easier to draw the boundary between "AI and non AI users", but as AI becomes prolific, the us vs them angle that people keep using won't apply anymore.

The age old "user versus tool" debate goes on, but it seems like gaslighting is popular these days. I classify it as gaslighting because I'm clearly a falsifiable test case, I'm even gung ho for LLMs, yet any kind of dissent is immediately warped into user error. It doesn't matter what you say or where you are on the spectrum, if you have 1 bad experience and speak up about it it's an issue. Guess that's not really an issue for the human condition though.

What the US does is bad, but somehow Americans think that means everywhere else is better.

Illegal immigration really isn’t a thing in China beyond a few North Koreans in Dongbei and a few Laotians in Yunnan. So they just won’t assume you are an illegal immigrant.

That does not seem to be all that related to the original post I was answering to. An average person / citizen / visitor has way less to worry about around (trained) Chinese police than they have to worry about around an (gangster) American ICE agent.

Re: the compilation latency discussion — it's a real tension. JIT gives you expressiveness but kills startup. AOT gives you instant start but limits flexibility. Interesting that most GPU languages went JIT when the GPU itself runs pre-compiled SPIR-V/PTX anyway.

Maybe the mass of the kids at the first round were what you describe, but very quickly the focus turned to the top 20% who were very much "reputation laundering" and "CV padding" internships at labs, not actual curiosity driven independent exploration

At the same time, the reason they're doing the CV padding is because we, the adults in control of those systems they wish to gain access to (which is not the science fair), have made it so they need to pad their CV in the first place.

So as much as we want them to be purely driven by curiosity and independent exploration, our society at large does not allow for that kind of thing. Fixing those kinds of macro incentives doesn't happen by reforming the science fair.

If we want curiosity driven independent exploration for children, our society should provide that modality for adults. That we don't provide it for adults is reflected on our children; because we impose credentialism on adults, the adults understand credentialism is important to success and they impose it on their children. If adults understood that creative inquiry and independent exploration are paths to success, then more children would be encouraged to pursue that at the elite level.