111–120 of 288 posts
Earlier quoted context omitted.
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.
What is the comparison between using musl and traditional glibc? Is there performance differences between the two? I have been seeing musl used more and more in both Rust and Zig ecosystems lately.
https://wiki.musl-libc.org/functional-differences-from-glibc...
Earlier quoted context omitted.
You miss UNIX developer experience until mid-1980's, before shared objects came to be.
Heh...rebuilding gcc on slackware to enable shared libs was an adventure - but that wasn't till the late 90s(??). I think I spent like a week bootstrapping the new gcc, rebuilding glibc and rebuilding all the stuff I used.
I cant speak much about the system, it just works, but the community was really nice when I interacted with them over IRC I had the plan to build oasis with bazel for some immutable OS images that could run as kubernetes nodes. I succeeded with a little pointing.
I cant speak much about the system, it just works, but the community was really nice when I interacted with them over IRC I had the plan to build oasis with bazel for some immutable OS images that could run as kubernetes nodes. I succeeded with a little pointing.
Why did you need to use bazel?
I also have a small, but burning, passion for reproducible builds, distributed compilation and distributed caching.
Being able to build an entire OS and essentially anything I want on top in a reproducible and relatively organic way (with incremental compilation) is pretty dope.
Earlier quoted context omitted.
I mean, if you ran every single executable on your desktop in a separate container I think you'd see problems. There are a pretty large number of programs running on most desktops, plus all the programs that get called by shell scripts, etc. Running a handful of containers representing major applications is more reasonable and the memory wastage may be worth it to avoid dependency conflicts.
You've just described Qubes OS!
Containers make a lot of sense to me on servers ("deploy a controlled environment"), but often on Desktop I feel like they are used as a solution to "I don't know how to handle dependencies" or "My dependencies are so unstable that it is impossible to install them system-wide", both of which should be solved by making slightly better software.
michaelforney was also who did the wayland port of st: https://github.com/michaelforney/st oasis's predecessor would be https://dl.suckless.org/htmlout/sta.li
Michaelforney has also built croc [1], a qbe based C compiler. Really impressive! [1]: https://github.com/michaelforney/cproc
Earlier quoted context omitted.
If you want an optimized Musl, try Cosmopolitan in `make toolchain MODE=tinylinux`, since it's based on Musl, and its string routines go 2x faster.
I don’t think that was around back then but I can add it to the backlog of things to try for next round. Does that play nice with rust? Presumably I’d have to at least build the standard library from scratch (which I’d want to do against musl as a separate benchmark anyway since it’s now a single environment variable away). (Not that the codebase makes much string function usage.)
Earlier 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.
That's the thing: I feel like people tend to call "dependency hell" what I would consider downright malpractice. "Shared libraries don't work because they require good practice" is, IMO, not a good argument against shared libraries. If you need to design your tool with the constraints that "users will use it wrongly", then it's already lost.