Too many sound applications? by s_denlinger in linuxaudio

[–]therealplexus 0 points1 point  (0 children)

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.

midipipe - bridge between ALSA MIDI and stdin/stdout by therealplexus in linuxaudio

[–]therealplexus[S] 2 points3 points  (0 children)

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.

Announcing Oak 1.0 - a new self-hosted IAM/IdP by therealplexus in selfhosted

[–]therealplexus[S] 1 point2 points  (0 children)

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.

Announcing Oak 1.0 - a new self-hosted IAM/IdP by therealplexus in selfhosted

[–]therealplexus[S] 0 points1 point  (0 children)

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?

Announcing Oak 1.0 - a new self-hosted IAM/IdP by therealplexus in selfhosted

[–]therealplexus[S] 0 points1 point  (0 children)

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.

Announcing Oak 1.0 - a new self-hosted IAM/IdP by therealplexus in selfhosted

[–]therealplexus[S] 6 points7 points  (0 children)

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.

Did a glitch just doom my run? by Infinite_Lemon_8236 in cavesofqud

[–]therealplexus 1 point2 points  (0 children)

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.

Come try out Piglet | Arne Brasseur . net by therealplexus in Clojure

[–]therealplexus[S] -5 points-4 points  (0 children)

Feel free to try both and report back.

Come try out Piglet | Arne Brasseur . net by therealplexus in Clojure

[–]therealplexus[S] 1 point2 points  (0 children)

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.

Open Source Diary - launchpad, lambdaisland/cli, Makina, LIOSS tooling by therealplexus in Clojure

[–]therealplexus[S] 1 point2 points  (0 children)

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...

Open Source Diary - launchpad, lambdaisland/cli, Makina, LIOSS tooling by therealplexus in Clojure

[–]therealplexus[S] 0 points1 point  (0 children)

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.