pg83

The README.md link describes cosmopolitan's approach, among other things, and it's worse than mine.

> i'm not sure how much people realize that the modern "graphics driver" is actually just "the kernel multiplexes userspace messages to/from the GPU and we've taught mesa to understand each family of GPU you'd ever care to support."

In the case of OpenGL, it has a fairly sophisticated state tracker, which you can carry around with you. For example, I can statically compile ANGLE this way.

But even OpenGL/Vulkan have a shader compiler that's unique to the hardware (it's expensive to carry it around with every piece of hardware in the universe).

And I'm not even talking about libdrm, which is quite tightly tied to the kernel version.

I know exactly what I'm talking about, because I can also statically compile Mesa into my application.

Or may be not.

Any software WILL break on future distributions, sooner or later.

These decisions, and these studies, were made a VERY long time ago. It's completely unclear why the decisions made then are relevant now, and why they can't be challenged.

I disagree that this is a niche problem.

Yes, on the one hand, each specific distribution doesn't have this problem because it can pick up everything it needs.

But for us, independent developers of small programs, the problem is truly stark: we can't afford to build our programs for every distribution. And we can't afford to waste time navigating all the idiosyncrasies of various package repositories, both technical and political (not all repositories allow easy access).

And we can't count on someone else packaging our work until we become incredibly popular.

It's so good that Linus thinks differently!

Thanks a lot, guys!

> A change in paradigm is necessary. Freestanding C, not hosted C. This completely gets rid of the libc and is a surprisingly clean language. Linux only, because it's the only kernel with a stable binary interface. Every other OS forces a C runtime.

Great choice for small programs, but what if I want hardware accelerated 3d?

Of course, I remember those times very well.

And I also remember very well that dynamic linking appeared ONLY because we were catastrophically short on memory; everything else was added much later.

Now we have plenty of memory, and we can very well return to our blessed roots!

This means the user will update the binary with my program and continue using it happily.

I'm not offering a silver bullet, but the approach I've implemented is much better than what the industry currently offers.

> One advice I'd give you is to _really_ take care regarding SysV/ELF ABI conventions, there's tons of undocumented stuff in there and it's really easy to mess something up or cause a security defect (see AT_SECURE)

Yes, it's not trivial, but I hope that over time everything will settle down.

> if I understood your implementation correctly you're hooking this into an already running musl which could cause backwards compatibility issues if musl changes under you

No, I hook this to musl, which is statically linked into my binary, and I have complete control over it.

Windows handles this much better than any other OS. The API passes versions (== structure sizes on the calling side), and WinAPI can handle that.

As for older Windows systems not being able to load new DLLs, they can; the format hasn't changed in a very long time. I've had experience with installing some DLLs on Windows NT 3.51 and running a modern Firefox, which is about 20 years behind the times.

> And that's the correct approach.

Who said that? This approach has many problems that have already been discussed here, not to mention the fact that it leaves Alpine and Bionic-based systems out in the cold.

Let me remind you that Bionic is the most widespread libc in the Linux world, and Alpine is the most popular Docker layer.

The world doesn't end with glibc. And it doesn't begin with it.