3 ms·

Yeah, it's mind boggling how everything hard depends on glibc, even critical graphics systems. I've become obsessed with getting rid of it, especially after I

Yeah, it's mind boggling how everything hard depends on glibc, even critical graphics systems. I've become obsessed with getting rid of it, especially after I realized that contributing to GNU itself was a dead end. Freestanding Linux programming turned out to be much more fun anyway. All libraries out there should adopt the SQLite design: programmers provide it with all the necessary functions. Instead of libraries hard depending on glibc, we get to inject the libc-ish subset it needs. Then we can use whatever we want under the hood. I'm working on porting SQLite to freestanding Linux system calls so it can run with zero dependencies. Wish I could say the same for software like mesa, I'd need a lot of help for this one...

yxhuvud 2mo ago
Modularizing (and versioning each part independently) libc would go a long way. There is also a need to separate the stuff needed for system integration with what is necessary for users of the C language to actually do stuff.
- matheusmoreira 2mo ago
  > Modularizing Can't be done. The libc is legacy, it can't be changed without breaking everything. It's also mandatory on every operating system other than Linux. 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. I once worked on a liblinux project that embodied this... Stopped because Linux itself has a nolibc thing in the kernel tree and I didn't want to compete with it. Now I'm working on the Rust version. > what is necessary for users of the C language to actually do stuff Surprisingly little. I wrote an entire lisp interpreter in freestanding C with Linux system calls. It managed to survive for a rather long time without any memory allocation at all. The system layer is refreshingly tiny. It consists of a memory allocator and extremely basic functions like memmove and strlen. I successfully got rid of total nonsense like thread local errno, locales, implicit buffering, cached global state, possibly more. All that stuff is gone! Exactly one global survived: the stack canary generated by GCC and clang. Every other symbol in the ELF is controlled by me. Wasn't able to get rid of the NUL terminator. Linux itself needs it. To get rid of that little billion dollar mistake requires an entirely new kernel with zero UNIX/POSIX influence. I had to make my peace with that one. All my buffers maintain an extra NUL byte at the end.
  - pg83 2mo ago
    > 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?
    - Splizard 2mo ago
      exactly
    - matheusmoreira 2mo ago
      Yeah, that's the annoying part. Been wondering about this for years, and graphics support was among the first issues raised on the lone lisp GitHub repository. At this point I've even started exploring the mesa codebase, made some patches but didn't submit them yet due to the AI stigma. With Linux system calls alone it should be possible to set up kernel mode setting without depending on any toolkit at all. This should be enough to get a framebuffer for software rendering. For hardware acceleration though, one must give this graphics context to an OpenGL ES implementation. That's where it gets ugly. There is no way to divorce that from the libc short of literally rewriting it. Maybe Vulkan will enable it? I can't say for sure at my current knowledge level.
      - pjmlp 2mo ago
        Vulkan is designed to only load core statically and the whole extension spaghetti dynamically, using driver entry points. https://vulkan.lunarg.com/doc/view/latest/mac/LoaderInterfaceArchitecture.html https://vulkan.lunarg.com/doc/view/latest/mac/LoaderInterfac...
    - inigyou 2mo ago
      Modern 3D APIs are built around passing around a few buffers per frame and long command queues. Should be doable with IPC.
  - dwattttt 2mo ago
Root_Access 2mo ago
We have a similar no dependency philosophy SQLite already does this with its VFS layer. You hand it the OS functions it needs instead of it grabbing them, etc. You could look at going straight to syscalls, mesa would be a rewrite nightmare I went zero-dependency on a production CMS. Rust, no framework, no external crates beyond argon2 for password hashing. Running live on client sites. The hard part wasn't building it, it was accepting that everything you reach for is pulling glibc or similar assumptions back in through the side door. SQLite's VFS model is the right pattern. More things should work that way.
stevefan1999 2mo ago
The concept you mentioned is just dependency injection in software engineering design, but instead of giving a class and protocol/interface you give a bunch of function pointers, which is, well, some kind of interface anyway

yxhuvud 2mo ago

Modularizing (and versioning each part independently) libc would go a long way. There is also a need to separate the stuff needed for system integration with what is necessary for users of the C language to actually do stuff.

matheusmoreira 2mo ago
> Modularizing Can't be done. The libc is legacy, it can't be changed without breaking everything. It's also mandatory on every operating system other than Linux. 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. I once worked on a liblinux project that embodied this... Stopped because Linux itself has a nolibc thing in the kernel tree and I didn't want to compete with it. Now I'm working on the Rust version. > what is necessary for users of the C language to actually do stuff Surprisingly little. I wrote an entire lisp interpreter in freestanding C with Linux system calls. It managed to survive for a rather long time without any memory allocation at all. The system layer is refreshingly tiny. It consists of a memory allocator and extremely basic functions like memmove and strlen. I successfully got rid of total nonsense like thread local errno, locales, implicit buffering, cached global state, possibly more. All that stuff is gone! Exactly one global survived: the stack canary generated by GCC and clang. Every other symbol in the ELF is controlled by me. Wasn't able to get rid of the NUL terminator. Linux itself needs it. To get rid of that little billion dollar mistake requires an entirely new kernel with zero UNIX/POSIX influence. I had to make my peace with that one. All my buffers maintain an extra NUL byte at the end.
- pg83 2mo ago
  > 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?
  - Splizard 2mo ago
    exactly
  - matheusmoreira 2mo ago
    Yeah, that's the annoying part. Been wondering about this for years, and graphics support was among the first issues raised on the lone lisp GitHub repository. At this point I've even started exploring the mesa codebase, made some patches but didn't submit them yet due to the AI stigma. With Linux system calls alone it should be possible to set up kernel mode setting without depending on any toolkit at all. This should be enough to get a framebuffer for software rendering. For hardware acceleration though, one must give this graphics context to an OpenGL ES implementation. That's where it gets ugly. There is no way to divorce that from the libc short of literally rewriting it. Maybe Vulkan will enable it? I can't say for sure at my current knowledge level.
    - pjmlp 2mo ago
      Vulkan is designed to only load core statically and the whole extension spaghetti dynamically, using driver entry points. https://vulkan.lunarg.com/doc/view/latest/mac/LoaderInterfaceArchitecture.html https://vulkan.lunarg.com/doc/view/latest/mac/LoaderInterfac...
  - inigyou 2mo ago
    Modern 3D APIs are built around passing around a few buffers per frame and long command queues. Should be doable with IPC.
- dwattttt 2mo ago

Root_Access 2mo ago

We have a similar no dependency philosophy SQLite already does this with its VFS layer. You hand it the OS functions it needs instead of it grabbing them, etc. You could look at going straight to syscalls, mesa would be a rewrite nightmare I went zero-dependency on a production CMS. Rust, no framework, no external crates beyond argon2 for password hashing. Running live on client sites. The hard part wasn't building it, it was accepting that everything you reach for is pulling glibc or similar assumptions back in through the side door. SQLite's VFS model is the right pattern. More things should work that way.

stevefan1999 2mo ago

The concept you mentioned is just dependency injection in software engineering design, but instead of giving a class and protocol/interface you give a bunch of function pointers, which is, well, some kind of interface anyway