Just for plain interest how to make ollama running in NVIDIA GPU useful for something? Not for being LLM prompt. Just ideas what would be applications :-) Like, could I make it analyze local network traffic for instance or be part of that type of scheme?

I'll create a rootns AUR repository for Arch Linux kernel with rootns patches. I want to run it in my desktop for some time to get more feel for it and fix any glitches.

I think it is pretty good but for a namespace it is better to try to use it for a while before submitting anything.

The idea of rootns is to namespace root / superblock i.e., that way this dilates from David Howell's original series (or by evolution actually following all review comments from Al and Eric). In David's series topologically container object was something managed by task_struct. In this series, rootns is part of nsproxy, and purely a namespace.

You would think that root is part of filesystem namsepace but actually formally filesystem namespace is all non-empty sets of mount trees not including empty state (there's BUG_ON() to underline this in VFS code). This namespace plays only with detached roots and that way can give guarantees of not mixing up the kernel state.

Once again (as with swcam driver), I ripped off the SRCU/spinlock locking scheme from SGX driver and there are no loops inside spinlock or anything weird like that. I should remember to add cond_resched()'s tho to iterations :-)

I think the gist of David's code had absolutely a reason to exist. It was just not enough constrained, scoped and explained. And it was completely misunderstood by most. I have to give credit to Eric Biedermann giving such great (and many) review comments despite being in existential opposition. This is uncommon and shows high-standards professionalism in a person.

Super useful tidbit on serum wavetables (44 kHz vs 48 khz): https://backstage.polyend.com/t/workflow-making-wavetables-on-tracker/4742

Making a tracker feels more and more like implementing interpreter. Probably a good first class optimization would be to have some kind of JIT the pattern data. And you do get stuck into infinite loops because of misinterpretation of note delays, jumps etc. And all that must be considered both in context of looping a pattern or playing a song.

Would be nice if there was also external bootlin toolchains for LLVM.

E.g., if you want to compile bpftrace to a BuildRoot image. Most of the time when compiling image is spent on LLVM compilation.

wavetable oscillator is not working yet properly and all those sounds sound like shit but anyhow some early success with mt playback :-) feat legowelt - italosynthpop #polyend #tracker

A tracker is essentially a interpreter where each instruction within thresholds (low and high) takes the same amount of time.

pattern editor might make it seem that my tracker is almost done but actually it will take ages to polish it and do all the details right (at least a year) :-)

and as long as i have vision what is not right open sourcing it right now would only add stress. i publish it once i don't know what to do with it :-)

My mind says my tracker is good as it is in Rust but my heart says "rewrite it in C, you want to do it Jarkko, let's make it small and tight just the way you want it, together".

Can't resist... the force is too strong... :-)

The first version of loader/saver for Polyend's MT project files and MTP pattern files done :-) PTI instruments were already. Scaffolding done also for wavetable and granular synthesis...

Lo behold rootns: https://git.kernel.org/pub/scm/linux/kernel/git/jarkko/linux-tpmdd.git/log/?h=rootns

#linux #kernel #container

I call the new namespace as root namespace. It's reduced and focused version, and re-defining root is the whole point.

I could perhaps create (maintained) DKMS repository of swcam driver since V4L2 subystem does not want it.

It addresses at least all the security issues of v4l2-loopback, which is in wide use.

I got crazy idea of dawproject import and export for this tracker project (within limits).

Doing an export from tracker to DAW can generate quite large dump of data in the worst case given that in each lane instrument can change per step and other hand commonly in DAWs each instrument has a dedicated lane.

Import can simply require sampled instrument only and then figure out whether the dawproject file can be mapped to tracker patterns.

To 16 tracker lanes one can fit obviously at minimum 16 DAW lanes.

But depending on many factors one can take advantage of re-usability of lanes for as many instruments as there are steps.

I really enjoy working on this tracker project. When I got pattern editor, I knew that it will become something. It will take at least a year to really nail every bit but it has the critical mass of getting done (eventually) :-)

Very early work on sample editor.

I guess I just follow the lead :D

❯ find -name json_writer.c
./tools/testing/selftests/container/json_writer.c
./tools/testing/selftests/bpf/json_writer.c
./tools/bpf/bpftool/json_writer.c
./tools/net/ynl/ynltool/json_writer.c

Maybe we should have shared json_writer.h/c for selftests?

This looks "pre-done" :-)

https://git.kernel.org/pub/scm/linux/kernel/git/jarkko/linux-tpmdd.git/tree/include/uapi/linux/container.h?h=container

Better to distance off for a while and then revisit.

I thought that rather than focusing on reversing Polyend Trackers MT song format it is better to build a "DAW" that can support its features. I'd figure the lack of such program has blocked any major progress.

So there you have it I'm building a retro-modern tracker ;-)

UV bars :-)

also has polyend's 8 channel view :-) in this view text fields need some work but yeah looking pretty good