BearSSL development’s seems to have stopped and it’s lacking TLS1.3. Are there promising alternatives?
Oasis – a small, statically-linked Linux system
91–100 of 288 posts
Re: Oasis – a small, statically-linked Linux system
#92Earlier quoted context omitted.
This alone “musl maintainers not even agreeing it’s a problem” should be a good reason to avoid musl imho
What's a better option for static linking? glibc is religiously against it; they have far worse dogmatic beliefs than this musl DNS thing. I'd be happy to choose a better alternative if one exists, but if one does not, I have to live with the options at hand. From where I'm standing, musl seems like the only game in town. uClibc doesn't seem like it's appropriate for general purpose Linux applications on desktop comp…
Static linking doesn't actually solve any problem. Just use dynamic linking with (probably relative) rpath, and compile against a sufficiently old libc.
There's some common FUD about rpath being insecure, but that only applies if the binary is setuid (or otherwise privileged) and the rpath is writable by someone other than the binary's owner (all relative rpaths are writable since you can use symlinks; absolute rpaths are writable if they point to /tmp/ or a similar directory, which used to be common on buildbots).
This is really not hard; working around all static linking's quirks is harder.
Re: Oasis – a small, statically-linked Linux system
#93Earlier quoted context omitted.
> dependency hell Dependency hell comes from bad dependencies that don't do semver properly. Choose your deps carefully, and that's perfectly fine. > Feels like every single app is a bundled web browser these days anyways. Yep, that's apparently the best way to use the bad libraries people want to use and not give a damn about semver.
Semver is nearly impossible to do "properly" because of https://xkcd.com/1172 . With a sufficient number of users, all bug fixes are breaking changes. If the behavior can possibly be observed in any way, some user will be depending on it, deliberately or otherwise.
Semver defines what is breaking and not-breaking. E.g., Rust semver says that "code should continue compiling with a minor version bump, but not necessarily for a major version bump"
Re: Oasis – a small, statically-linked Linux system
#94Earlier quoted context omitted.
A linker typically only includes the parts of the library it needs for each binary so some parts will definately have many copies of the same code when you statically link but it will not make complete copies. But I wouldnt consider this bloat. To me it is just a better seperation of concerns. To me bloat would be to have a system that has to keep track of all library dependencies instead, both from a packaging persp…
Dynamic linking served us when OS upgrades came infrequently, user software was almost never upgraded short of mailing out new disks, and vendors had long lead times to incorporate security fixes. In the days of fast networks, embedded OSs, emphemeral containers, and big hard drives, a portable static binary is way less complex and only somewhat less secure (unless you're regularly rebuilding your containers/execs in…
As far as I can see, it would be unwise to roll back 30 years of (Linux) systems building with dynamic linking in favor of static linking. It mostly works very well and does save some memory, disk, and has nice security properties. Both have significant pros and cons.
I've been thinking (not a Linux expert by any means) the ideal solution would be to have better dependency management: I think a solution could be if say binaries themselves carried dependency information. That way you get the benefits of dynamic and static linking by just distributing binaries with embedded library requirements. Also, I think there should be a change of culture in library development to clearly mark compatibility breaks (I think something like semantic versioning works like that?).
That way, your software could support any newer version up to a compatibility break -- which should be extremely rare. And if you must break compatibility there should be an effort to keep old versions available, secure and bug free (or at least the old versions should be flagged as insecure in some widely accessible database).
Moreover, executing old/historical software should become significantly easier if library information was kept in the executable itself (you'd just have to find the old libraries, which could be kept available in repositories).
I think something like that could finally enable portable Linux software? (Flatpak and AppImage notwithstanding)
Re: Oasis – a small, statically-linked Linux system
#95BearSSL development’s seems to have stopped and it’s lacking TLS1.3. Are there promising alternatives?
wolfSSL. Open source, widely used, flexible licensing model, TLS + DTLS 1.3 support, support for all modern ciphers and protocol extensions, extremely tuneable for performance/size, FIPS module, excellent customer support, the list goes on....
Re: Oasis – a small, statically-linked Linux system
#96Earlier quoted context omitted.
glibc is LGPL. Static linking your application implies some obligation on your part. Musl being MIT is less restrictive.
[flagged]
No it doesn't. The MIT license is objectively less restrictive than the LGPL. Whether it's a good or bad thing to be less restrictive is a matter of opinion, but whether or not it is less restrictive is a matter of fact.
Re: Oasis – a small, statically-linked Linux system
#97Earlier quoted context omitted.
I'll take bloat over dependency hell every day of the week. Feels like every single app is a bundled web browser these days anyways.
Dynamic Library hell is why Docker exists. If operating systems had less global state and less ambient authority, our systems would be vastly more tractable. Instead we still create environments that look like replicas of whole hosts. Might as well go all in and use something with pervasive virtualization like Qubes. https://www.qubes-os.org/
[deleted]
Re: Oasis – a small, statically-linked Linux system
#98Earlier quoted context omitted.
> Can someone explain a couple use cases for something like this? At this point, it would be more useful if someone explained a couple of use cases for dynamic linking.
Plugins, unless you want to have one process per plugin. Which in the days of running Kubernetes clusters on laptops maybe isn't a big deal.
You can still call dlopen from your static binary, if you really want to.
Re: Oasis – a small, statically-linked Linux system
#99Earlier quoted context omitted.
A linker typically only includes the parts of the library it needs for each binary so some parts will definately have many copies of the same code when you statically link but it will not make complete copies. But I wouldnt consider this bloat. To me it is just a better seperation of concerns. To me bloat would be to have a system that has to keep track of all library dependencies instead, both from a packaging persp…
Dynamic linking served us when OS upgrades came infrequently, user software was almost never upgraded short of mailing out new disks, and vendors had long lead times to incorporate security fixes. In the days of fast networks, embedded OSs, emphemeral containers, and big hard drives, a portable static binary is way less complex and only somewhat less secure (unless you're regularly rebuilding your containers/execs in…
> In the days of fast networks, embedded OSs, emphemeral containers, and big hard drives, a portable static binary is way less complex and only somewhat less secure
If what you're trying to do is run a single program on a server somewhere, then yes absolutely a static binary is the way to go. There are lots of cases, especially end user desktops, where this doesn't really apply though.
In my opinion the debate over static vs dynamic linking is resolved by understanding that they are different tools for different jobs.
Re: Oasis – a small, statically-linked Linux system
#100Earlier quoted context omitted.
In a way, that's what Nix sets out to do, isolating even dynamically linked libraries: if two derivations depend on the same shared lib derivation then it's reused, if not then they don't conflict. Each leaf derivation can be handled completely independently of the others, and independently of the original system†. And then when Nix† is not an option at runtime, dockerTools†† can build a Docker image to do the minimi…
So Nix keeps track of different versions of shared libraries?
Yeah, each package/lib is stored in a unified directory by it's hash https://zero-to-nix.com/concepts/nix-store. Different variation different hash.