131–140 of 169 posts
Ok maybe this is dumb question and is addressed somewhere: If a security problem is found, e.g. in muscl (the C lib), then is the user supposed to rebuild everything that statically linked it??
Good luck maintaining 100.000 statically linked libraries embedded in 10.000 applications.
Earlier quoted context omitted.
That's a searing hot take, to be sure. There is no alternative to the C ABI. If you look at stable ABIs in other programming languages, they're either identical to or thin shims around the C ABI! Even COM, with the caveat of calling convention on MSVC. Regardless of ABI stability you also need software to have API stability for stable distribution. The two solutions to this problem are to statically link everything o…
> Then to launch the software you need a shell script that overrides the loader search path and move on with your life. > The ultimate solution is the .app/.bundle paradigm of MacOS. Everything should copy that. All ELF systems support the $ORIGIN RPATH macro. It lets you build and package an application exactly like, if not better than, you would a macOS bundle. Specifically, it let's you specify at compile time a l…
Earlier quoted context omitted.
Hot take: A great tragedy of the GNU/Linux ecosystem is the fact that ABI+API is still not figured out, and the most common interface between programs is the C ABI, which is embarassingly primitive even by 80's/90's standards. Some people in the FOSS community just want to leave things as-is to hinder propiertary software, and it's the same story with device drivers. You can debate the merits rightfully so, but then…
That's a searing hot take, to be sure. There is no alternative to the C ABI. If you look at stable ABIs in other programming languages, they're either identical to or thin shims around the C ABI! Even COM, with the caveat of calling convention on MSVC. Regardless of ABI stability you also need software to have API stability for stable distribution. The two solutions to this problem are to statically link everything o…
Would be cool to get a bit of a "why this matters" intro on repos like this. I clicked through the details, but left wondering if I have any potential use for this. Can I compile this onto a USB stick and use it as a throw-away boot Linux for maintenance tasks? Can I cross-compile this for embedded devices? What is the statically-linked advantage here? Not trying to minimize the effort, I would actually love to see m…
Earlier quoted context omitted.
> I prefer to have things clearly separated in functionality and easily upgradeable. What is your thinking here? Are you talking about a use case where you have an application that uses a library and a bug fix is issued for that library, so you want to just get the new .so for the library and have the application use it? That feels like a niche use case to me. Maybe there is another benefit, or this use case is more…
> That feels like a niche use case to me. I wouldn't call it a niche use case at all, it's exactly how the software for all major Linux and BSD operating systems are packaged and built. For example, when (not if) a vulnerability is found in OpenSSL, package maintainers just commit an update to the openssl package and users only have to download and install one package to patch their system against the vulnerability.…
DLL loading is full of security risks. Static binaries are free of them.
DLLs are compiled separately from the binaries that load them. Compilers cannot optimize code that calls into a DLL. Compiler optimizers are amazing these days. Compared to a separately optimized binary + DLL, a completely optimized binary will consume less CPU, use less memory, and cause less heap pressure and fragmentation.
DLL's original purpose is reducing memory and disk usage. Since we have different needs now, DLLs are just technical debt.
I'm also not happy with Ubuntu's move towards snaps which also seem to increase complexity and overhead with minimal benefit.
An app-as-directory setup, like the one that was used in NeXTSTEP and is still used in macOS, also seems to work OK.
This would be 10x faster and smaller if they just built these components into Busybox. Package management, library management, etc are solved problems when it comes to Linux distros. The only practical improvement you can make is containers (or similar). Static binaries cannot deal with external dependencies, and many applications require external dependencies that cannot be compiled in . But even by trying to compil…
> Package management, library management, etc are solved problems when it comes to Linux distros. The only practical improvement you can make is containers (or similar). To me this basically reads as "we added a bunch of complexity on top of the problem without actually solving it". Package managers are supposed to prevent conflicts and manage giant dependency graphs, but they're so shit at doing that while actually…
It solved it as much as is possible within the current state of software design.
> Package managers are supposed to prevent conflicts and manage giant dependency graphs
Actually, they can't do that. They can look for the conflicts they're programmed to look for by packages, and they can walk dependency graphs that are generated by the packages in the repos maintained by a person. The root of the problem is that modern software architecture (even for trendy languages) cannot express the dependencies in the first place.
I wrote you an explanation, but it ran to 1,355 words, so I Gist'd it here https://gist.github.com/peterwwillis/e96854532f471c739983c0b...
Would be cool to get a bit of a "why this matters" intro on repos like this. I clicked through the details, but left wondering if I have any potential use for this. Can I compile this onto a USB stick and use it as a throw-away boot Linux for maintenance tasks? Can I cross-compile this for embedded devices? What is the statically-linked advantage here? Not trying to minimize the effort, I would actually love to see m…
Earlier quoted context omitted.
Hot take: A great tragedy of the GNU/Linux ecosystem is the fact that ABI+API is still not figured out, and the most common interface between programs is the C ABI, which is embarassingly primitive even by 80's/90's standards. Some people in the FOSS community just want to leave things as-is to hinder propiertary software, and it's the same story with device drivers. You can debate the merits rightfully so, but then…
Stable ABIs don't seem like a good solution though. It is preferable that the system running the code should make the decisions on how best execute it. Especially as hardware becomes more specialized and diverse. Additionally, guarantees of stability necessarily increase maintenance burdens, so they should be avoided whenever possible. IMO, the best solution would be something like SPIR-V. That is, programs are shipp…