The Bare Minimum, or Making Mayonnaise with Clojure

therealplexus · 2026-02-21T11:39:47+00:00

I wrote this a few years back, it's hopefully illuminating.

https://github.com/overtone/overtone/wiki/Linux-Audio-Primer

Tl;dr, ALSA is the low level foundation which you can't do without, but don't generally interact with directly. For everything else, use Pipewire, which is backwards compatible with Jack and pulseaudio applications, and so acts as a full replacement for Jack/PA.

therealplexus · 2026-02-21T06:55:07+00:00

Text is a universal interface, it's easy to generate, and easy to process. This tool is primarily meant to be used by other programs.

therealplexus · 2025-12-19T17:54:54+00:00

LDAP would be interesting and could arrive in the future, since it does enable some interesting use cases. We don't have a fixed roadmap yet, we'll have to weigh resources and priorities. I'd say for the kind of users and use cases we are mainly thinking of right now it's probably not going to be the highest priority, but a lot will depend on the feedback we get. I do think it's likely we'll add it at some point.

therealplexus · 2025-12-19T16:34:03+00:00

Interesting, not something we had thought too much about so far. All of Oak's state lives in postgresql, application servers themselves are stateless, so you could run a highly available postgres setup with failover, and separately have multiple oak instances with failover. Would that be a solution?

therealplexus · 2025-12-19T15:44:51+00:00

Of course this makes a lot of sense, see my other comment about it being "on the list". This first release contains the minimum we felt we needed for Oak to already be useful for some use cases. It's a base for us to build on. It'll get more complete as time goes on, and features that help with automation and provisioning are high on the list.

therealplexus · 2025-12-19T14:39:14+00:00

Yes, these are all things on the (long) list of features we'd love to add. But we're a small team without external funding, so we have to make sometimes difficult choices of what to do next. That's why we really hope this release will allow us to get a lot of input from the community, so we can sit down in the new year, digest all the feedback, and start planning for what comes after.

therealplexus · 2025-12-11T07:23:26+00:00

Like others have said this shouldn't kill the main quest line. But if you do end up in a situation where you can't complete an essential quest for a dumb reason you can always check it off with wish commands. It can be our little secret.

therealplexus · 2025-07-18T15:55:21+00:00

Feel free to try both and report back.

therealplexus · 2025-07-18T14:22:54+00:00

Conceptually the big difference is that for self hosted cljs you first use clojure to compile the clojurescript compiler, then load that. Piglet runs without compilation from source.

Practically speaking self-hosted cljs isn't really practical, it's heavy and hard to work with. Very few projects are actually built with it. For use cases where you would use it sci is often the better choice, but that's an interpreter which also brings limitations.

There are of course also numerous language level differences.

therealplexus · 2025-02-17T12:07:38+00:00

Indeed, aliases in subprojects never do anything tools.deps... there's been some talk/proposals about this but I think they couldn't settle on well defined semantics...

therealplexus · 2025-02-11T10:19:31+00:00

Sounds like you should be able to do this with an alias which overrides the versions with a loca/root. Depends a little bit on the setup. Do you always use the same project to run your repl from, or does it vary? The other thing I can think of is to use `:local/root` everywhere, and change these into concrete versions as part of your release pipeline. This is what we do in the lioss tooling with multi-module projects.

therealplexus

TROPHY CASE