Jarkko Sakkinen
jarkko
Does kernel.org have Matrix? This use would be really mainly for kernel stuff.
And actually if I want personal Matrix, I'd like to create a separate one for that.
And actually if I want personal Matrix, I'd like to create a separate one for that.
1
0
1
Jarkko Sakkinen
jarkko
RISC-V with MMU has neither complete spec: https://marcin.juszkiewicz.com.pl/2026/03/10/risc-v-is-sloooow/
0
0
0
@pinkforest LGPL terms are technically very hard to implement when using Rust. How the linking works enforces GPL to anything using that dependency, even if you purposely wanted to use LGPL+ to allow fair even proprietary use (like e.g., ffmpeg).
1
0
0
@pinkforest OK so how does it allow to use copyleft licenses effectively in those tiny units? I'm lost with this talk about storage space and runtime overhead, which have absolutely nothing to do with the topic. This is about IP protection e.g. with LGPL.
1
0
0
Jarkko Sakkinen
jarkko
Edited 1 month ago
For open source to surive, I think there should be radical shift towards wider use of copyleft licenses. This is the reality now, and it is better to accept it. And BTW, I was never a huge GPL advocate before.
How to tackle this with Rust and especially cargo, is an open question that needs to be resolved.
Throwing one potential solution: theoretically cargo could detect LGPL in dependency chains and make DSOs of these crates, which would be piggybacked into a virtual filesystem in the executable.
I'm not sure tho does that still comply for LGPL 2.1 when used e.g., in proprietary context.
There's also ABI work ongoing to get a stable DSO ABI for Rust but perhaps distribution problem could be resolved without resolving the ABI problem?
How to tackle this with Rust and especially cargo, is an open question that needs to be resolved.
Throwing one potential solution: theoretically cargo could detect LGPL in dependency chains and make DSOs of these crates, which would be piggybacked into a virtual filesystem in the executable.
I'm not sure tho does that still comply for LGPL 2.1 when used e.g., in proprietary context.
There's also ABI work ongoing to get a stable DSO ABI for Rust but perhaps distribution problem could be resolved without resolving the ABI problem?
2
1
4
Jarkko Sakkinen
jarkko
I totally get now why Logic Pro is AU-only. Having multiple plugin hosts in a DAW has devastative effect on latency compensation.
By having only CLAP latency compensation becomes a problem, which is elegant to resolve, not least because the standard has this inevitable reality recognized and addressed.
Thus, in my world everything is CLAP :-)
By having only CLAP latency compensation becomes a problem, which is elegant to resolve, not least because the standard has this inevitable reality recognized and addressed.
Thus, in my world everything is CLAP :-)
0
1
0
Jarkko Sakkinen
repeated
repeated
openSUSE Linux
opensuse@fosstodon.org#openSUSE is dropping pcr-oracle in Full Disk Encryption #FDE. systemd-pcrlock now handles #TPM2 policy, fixing rollback attacks and simplifying maintenance. Migration is just two commands! 🔒🐧 Find out more. #Linux https://news.opensuse.org/2026/03/11/dropping-pcr-oracle/
0
5
0
@pinkforest
Recipes:
1. Have a local Git hosting.
2. Understand in detail your licensing framework.
3. Never publish until understanding both source code and licensing framework in-depth.
4. Learn about supplemental claims. Look examples of this. Plugin hosts is one of the examples where this needs special attention.
5. Learn not to publish because the opposite is preprogrammed feature of human psychology. We like to show our shit too eagerly and sometimes this causes troubles :-)
6. For the rest of your life, for better or worse, failing or not failing, you plan everything when it comes to:
6a. licensing
6b. releases (e.g. time line for initial publication)
7. Understand the source code. Don't push anything until you do. There are no ways to get around this. By doing this e.g., LLM becomes a tool, and you become a contributor.
There's stuff that Rust and also Cargo could do here and change the game a bit but enough is enough, let's save for another day :-)
Recipes:
1. Have a local Git hosting.
2. Understand in detail your licensing framework.
3. Never publish until understanding both source code and licensing framework in-depth.
4. Learn about supplemental claims. Look examples of this. Plugin hosts is one of the examples where this needs special attention.
5. Learn not to publish because the opposite is preprogrammed feature of human psychology. We like to show our shit too eagerly and sometimes this causes troubles :-)
6. For the rest of your life, for better or worse, failing or not failing, you plan everything when it comes to:
6a. licensing
6b. releases (e.g. time line for initial publication)
7. Understand the source code. Don't push anything until you do. There are no ways to get around this. By doing this e.g., LLM becomes a tool, and you become a contributor.
There's stuff that Rust and also Cargo could do here and change the game a bit but enough is enough, let's save for another day :-)
0
1
2
@pinkforest
Recipes:
1. Have a local Git hosting.
2. Understand in detail your licensing framework.
3. Never publish until understanding both source code and licensing framework in-depth.
4. Learn about supplemental claims. Look examples of this. Plugin hosts is one of the examples where this needs special attention.
5. Learn not to publish because the opposite is preprogrammed feature of human psychology. We like to show our shit too eagerly and sometimes this causes troubles :-)
6. For the rest of your life, for better or worse, failing or not failing, you plan everything when it comes to:
6a. licensing
6b. releases (e.g. time line for initial publication)
7. Understand the source code. Don't push anything until you do. There are no ways to get around this. By doing this e.g., LLM becomes a tool, and you become a contributor.
There's stuff that Rust and also Cargo could do here and change the game a bit but enough is enough, let's save for another day :-)
Recipes:
1. Have a local Git hosting.
2. Understand in detail your licensing framework.
3. Never publish until understanding both source code and licensing framework in-depth.
4. Learn about supplemental claims. Look examples of this. Plugin hosts is one of the examples where this needs special attention.
5. Learn not to publish because the opposite is preprogrammed feature of human psychology. We like to show our shit too eagerly and sometimes this causes troubles :-)
6. For the rest of your life, for better or worse, failing or not failing, you plan everything when it comes to:
6a. licensing
6b. releases (e.g. time line for initial publication)
7. Understand the source code. Don't push anything until you do. There are no ways to get around this. By doing this e.g., LLM becomes a tool, and you become a contributor.
There's stuff that Rust and also Cargo could do here and change the game a bit but enough is enough, let's save for another day :-)
0
1
2
I'm developing this like a proprietary product which ships when it is ready despite likely releasing it with one of the copyleft licenses.
This is to both allow me to fulfill my artistic vision and also maximize my abilities to defend intellectual property rights given a single data entity nature off the license protected object.
This is to both allow me to fulfill my artistic vision and also maximize my abilities to defend intellectual property rights given a single data entity nature off the license protected object.
0
0
4
Jarkko Sakkinen
jarkko
It has finally crystalized me what I'm really doing with my leisure time activity since early Fall :-)
"A Linux-focused DAW built from scratch around its own desktop-like UI, deterministic rendering and input handling, a CLAP-only plugin architecture, and persistent CoW snapshot-based history — all aimed at delivering extremely accurate low-latency behavior and eventually industry-leading audio/MIDI routing."
It makes total sense to me now that it is on paper.
#linux #audio #dsp #musicproduction
"A Linux-focused DAW built from scratch around its own desktop-like UI, deterministic rendering and input handling, a CLAP-only plugin architecture, and persistent CoW snapshot-based history — all aimed at delivering extremely accurate low-latency behavior and eventually industry-leading audio/MIDI routing."
It makes total sense to me now that it is on paper.
#linux #audio #dsp #musicproduction
1
2
8
@pinkforest deepest condolences with that.
In 2024 I made decision to stick GPLv3.
With my DAW I will be 100% GPLv3 including libraries. Makes my life easier i.e., less weird stuff.
And to keep pickiest of FSF happy I'll add small exception for loading (not distributing with) proprietary plugin through the CLAP host.
Complicating my life with LGPL2.1+ libraries is such energy loss for me. E.g., if there was incident it's one single blob with one license if I use GPLv3. Easier at latest at court.
Such incident would surely piss me off enough that I would not stop until I get justice no matter the cost...
In 2024 I made decision to stick GPLv3.
With my DAW I will be 100% GPLv3 including libraries. Makes my life easier i.e., less weird stuff.
And to keep pickiest of FSF happy I'll add small exception for loading (not distributing with) proprietary plugin through the CLAP host.
Complicating my life with LGPL2.1+ libraries is such energy loss for me. E.g., if there was incident it's one single blob with one license if I use GPLv3. Easier at latest at court.
Such incident would surely piss me off enough that I would not stop until I get justice no matter the cost...
0
0
0
Jarkko Sakkinen
repeated
repeated
Random Mandelbrot
mrandelbot@aus.social-0.8309720144822054 + -0.18479928945814048i at zoom 1.1482443609e+12.
0
2
0
Jarkko Sakkinen
jarkko
Last glitches fixed. I've fully realized a binary DAW project format, which does not have concept of "saving" or "backup files".
Combining the best features of tracker modules and modern developments of file system snapshots. I like how opposite poles these topics are but this actually works :-)
Combining the best features of tracker modules and modern developments of file system snapshots. I like how opposite poles these topics are but this actually works :-)
0
0
2
Jarkko Sakkinen
jarkko
daw making is sick if you get into it. like model railroads type of madness.
i find myself happily making little knob and slider widgets to my UI framework for the use of my clap plugins. and still not bored.
I did read some recentish publications on latency compensaiton, studied clap, and realized that if I fix up to everything is clap I can make things sync really well. Worts case is when you have multiple hosts and bridges and whanot.
i find myself happily making little knob and slider widgets to my UI framework for the use of my clap plugins. and still not bored.
I did read some recentish publications on latency compensaiton, studied clap, and realized that if I fix up to everything is clap I can make things sync really well. Worts case is when you have multiple hosts and bridges and whanot.
0
0
1
Jarkko Sakkinen
repeated
repeated
How much water do the data centres use? It's a secret.
Do you want Immortan Joes? Because this is how you get Immortan Joes. Roanoke gets its drinking water from Carvins Cove Reservoir. The locals tried to find out just how much water Google would be...
https://jwz.org/b/yk4G
2
7
0
Jarkko Sakkinen
jarkko
Edited 1 month ago
My new guidelines for a new open source project in 2026:
1. Do not publish your test suite.
2. Delay the initial public repository as far away towards future as possible.
3. Do not aim for cross-os portability. Aim for cross-os non-portability.
4. Do not provide any other documentation except minimal man page and README. Less detailed documentation is better documentation.
In my DAW project I apply these best practices and levaraging Pipewire and Linux without any shim layers and at full scale will address the bullet three :-)
1. Do not publish your test suite.
2. Delay the initial public repository as far away towards future as possible.
3. Do not aim for cross-os portability. Aim for cross-os non-portability.
4. Do not provide any other documentation except minimal man page and README. Less detailed documentation is better documentation.
In my DAW project I apply these best practices and levaraging Pipewire and Linux without any shim layers and at full scale will address the bullet three :-)
0
2
1
Jarkko Sakkinen
jarkko
Dropped macOS/CoreAudio support from my DAW because of limited time and I want to see what you can accomplish with Linux-exclusive e.g., by taking full advantage of syscalls and Pipewire. Cross-architecture on the other hand is a high priority.
0
0
0