mforney

I followed the code path when you change the cabinet type, and saw it write some values to the DSP based on a 2D array of doubles, one for each cabinet, each with 41 values, and it was processing them 5 at a time. Looking at the values, they were all in the range -2 to 2, and were very reminiscent of biquad filters I had learned about in another project (https://mforney.org/blog/2025-06-06-babyface-midi-protocol.h...) which was still pretty fresh in my mind.

I tried plotting them, and I got something that looked right when I inverted the denominator coefficients. I guess this is fairly standard practice because then the difference equation is all positive sums and it can be implemented with a bunch of multiply-accumulates.

However there were still some discrepancies in overall gain between different types (most lined up, but a couple did not). I saw another array of integers indexed by the cabinet type that had negative values, most with -23 but a couple with -12, which I figured must be a decibel gain correction. It was only after accounting for that and seeing the final graph in the post where everything lined up and looked plausible that I was pretty sure I had it right.

So, mostly just general familiarity with digital EQ filters and a bit of luck.

Unfortunately there were no firmware updates for the THR10c, so the only way to get the firmware is to dump it from the device.

git -C /src/oasis pull && samu commit && doas git -C / merge

The first command pulls updates from the source repository, the second command builds a new filesystem tree and commits it, the third command merges that commit into your / repository.

Sorry for the confusing wording. I meant that oasis has more similarities to a BSD than a typical Linux distribution.

I've updated the README to be a bit clearer.

A simple way to fix this would be to shift c by 24u, "(c << 24u)" which would promote both values to unsigned int

This works for most arithmetic operators, but not shift: "The type of the result is that of the promoted left operand". The type of the right-hand-side has no effect on the type of the result.

To fix this, you'd need to cast the left-hand-side to a type that is wide enough.

Yep, you can install firefox via pkgsrc or nix. Due to the complexity of the modern web browser and all of its dependencies, it is unlikely to ever be part of oasis itself.

There is rudimentary hardware acceleration for certain older GPUs that I own in wld (intel at https://github.com/michaelforney/wld/blob/master/intel.c and nouveau https://github.com/michaelforney/wld/blob/master/nouveau.c).

But, for everything else there is only software rendering via pixman. I started working on a new library called libblit that will support amdgpu, and I managed to draw some rectangles and textures, but there is still a ways to go on that: https://git.sr.ht/~mcf/libblit/tree/master/amdgpu

I was ever so slightly disappointed to see how manual the packaging is, with every .c file listed in each lua script. It looks quite maintenance-intensive.

I was worried about this, too, but it turns out most of the cost in just the initial packaging. Packages do not tend to change their build system very much in between releases, so updating is usually just `git diff` between the version tags, sometimes adding/removing a couple source files to `gen.lua`, and regenerating `config.h`.

I'm just one person, but I've been able to keep these 100 or so packages up-to-date fairly easily, while still spending most of my time developing my own projects.

I was almost hoping for some kind of meta-build system which could parse automake etc. files and hoist the dependency graph into the main system build.

This would be amazing, but I think it is too difficult a problem to solve, especially with the huge variety of build systems (which are sometimes used pretty creatively). For some packages I get part of the way there with scripts or command snippets to extract source lists from the upstream build system. Here's an example: https://github.com/oasislinux/oasis/blob/master/pkg/mpv/gens...

One of the main motivations for the oasis build system is that it is often very difficult to get the upstream build system to do what you want. It is very common for projects to ignore your CFLAGS or LDFLAGS, ignore special include/lib directories for dependencies, or have automagic dependencies (to borrow a term from gentoo) that can't be enabled/disabled explicitly with a configure switch. Also, most build systems don't work very well for building things statically. libtool will intercept your -static flag, hiding it from the compiler, and libraries which are dependencies of other libraries get left out from the linking command.

I suppose you could argue that, but it is not a package manager in the traditional sense.

My main point here is that once you build the system, there is no longer any notion of "package", just files that make up your root filesystem. There is no package database tracking which files came from which packages. Instead, if you want to add/remove/update a package, you rebuild the system with a different specification, and then sync the resulting tree it to /.

Statically linking all the OS utilities to their dependency libraries, over and over again? Dear god that sounds awful.

Just curious, why does that sound awful to you? Are you worried that it will take a long time to relink the binaries? The oasis build system is incremental, so updates to a library only involve relinking dependent binaries, which is quite fast. Even a full rebuild from scratch only takes a few minutes (assuming you have the sources downloaded already).

If it's just the idea of relinking all the dependencies over and over again, note that with dynamic linking you do this at runtime every time you execute a binary.

The idea with oasis is to choose smaller software with fewer dependencies that offsets the slightly higher disk usage, as well as to deliberately not have thousands of binaries.

It exists because I wanted a complete system where I could easily experiment with various minimal/alternative software. I wanted this so that I could easily understand and hack on any component without spending weeks/months familiarizing with massive code-bases and waiting for things to compile.

I made it for myself, and honestly that's all there is to it. I tried to describe the things that make oasis unique in the README, and I think some of those are pretty cool, but I'm not trying to market this to anyone. If it doesn't sound interesting to you, then feel free to disregard the project.

Yes, but with the oasis build system this is just a single command to do an incremental build that relinks your binaries and takes a matter of seconds.

The user experience is essentially the same as updating your system on a dynamically-linked system. There is no "partial build" where some binaries get relinked but not others.

You bring up some good points here. Here are some of my experiences with these problems when working on oasis (my static linux distro).

1. symbol collisions -> accidental interposition (and crashes);

I've encountered symbol collisions only twice, but both resulted in linker errors due to multiple function definitions. I'm not sure how this could happen accidentally. Maybe you are referring to variables in the common section getting merged into a single symbol? Recent gcc enables -fno-common by default, so those will be caught by the linker as well.

2. you have to flatten the dependency tree into a topological sort at the final link-edit.

Yes, this is pretty annoying. pkg-config can solve this to some degree with its --static option, but that only works if your libraries supply a .pc file (this is often the case, though).

I think libtool also can handle transitive dependencies of static libraries, but it tries hard to intercept the -static option before it reaches the compiler so it links everything but libc statically. You can trick it by passing `-static --static`.

For oasis, I use a separate approach to linking involving RSP files (i.e. linking with @libfoo.rsp), which really are just lists of other libraries they depend on.

Besides fixing these issues, the C dynamic linking universe also enables things like: - run-time code injection via LD_PRELOAD and intended interposition

Yes, this can be a problem. I wanted to do this recently to test out the new malloc being developed for musl libc, but ended up having to manually integrate it into the musl sources instead of just using LD_PRELOAD.

- run-time code loading/injection via dlopen(3)

In particular, this is a big problem for scripting languages that want to use modules written in compiled languages, as well as OpenGL which uses dlopen to load a vendor-specific driver.

Dynamically-linked programs will load faster when their dependencies are already loaded in memory, and slower otherwise. The biggest win here is the C library.

But doesn't the dynamic linker still have to do extra work to resolve the relocations in the executable, even when the dependency libraries are already loaded?

I'm not sure what you mean here. Are you asking whether I build my kernel drivers as modules or built-in? Personally, I build my kernels without modules, but I've never heard of that technique being called "static-linking Linux".

I don't think stali has seen any activity in several years.

As far as I know, the only completely statically linked Linux distribution that is actively developed is my own project (inspired by stali), oasis: https://github.com/oasislinux/oasis

Most Linux/musl systems support it. On Alpine, gcc is built with `--enable-default-pie` so all static libraries can be linked into a static PIE.

On vanilla gcc (since version 8 when static PIE was upstreamed), `-static` means non-PIE static executable and there is a separate flag for `-static-pie` for static PIE. Alpine patches gcc so that `-static` and `-pie` are independent flags, so both `cc -static` and `cc -static-pie` will produce a static PIE.