Packer is superb for e.g. testing kernel:

https://www.packer.io/

I like to use it together with NixOS so I end up with two files describing the operating system.

#packer #nixos

@pinkforest Yeah, take these with a great of salt. Not 100% serious.

If I think product business for a smaller company, I think AGPL is actually quite good deal overall, over proprietary, for stuff in the web. This is what Signal does for their backend. Then the evidence of legit use and also unfair use get best exposure.

So I guess:

1. GPLv3 > Closed Source
2. Closed Source > Apache/MIT

Like as of 2025. From governance standpoint. E.g. *BSD operating systems are very badly AI governed. Maybe they would need a more restrictive license (something between GPL and BSD) because reality is what it is.

I've noticed two things I tend to do in the post-AI world:

1. Take away as much stuff as I can. Not sick level but if something is not necessary to hang on Internet, I'll tend to delete.
2. Prefer GPLv3 over any other license in situations where I otherwise might have used MIT/Apache.

Maybe it is time for closed source movement ;-)

It provides better AI governance.

#AI #LLM

I took my home page (jarkko dot codeberg dot page) and resume away only for the sake reducing scavenger exposure a bit. For job queries I can always email my resume, not a big deal really.

Similar ideas also support reducing social media profile descriptions to OpenPGP ID (which I did).

#AI #LLM

@Conan_Kudo sure and it will happen :-)

@Conan_Kudo Personally I don't believe that loophole is commercially viable at least not in volumes (maybe for some niche product) but I leave that burden to LKML discussion :-)

PS. I meant to like your encouraging comment but for some reason Mastodon sometimes does like me to like :-) Anyway thanks!

@Conan_Kudo sorry for responding with million messages tho :-) sometimes can't help myself...

@Conan_Kudo I should learn to not write a spam thread but yeah for better or worse this is how i aim.

@Conan_Kudo Hmm... So I have guess what has happened in "meta-level" with previous submissions: if you don't have a smoke test you hang yourself to the existing user space toolchain and the API is really the part here that sucks the most and needs a lot of rework. It's racy and bad. So what I do in meta-level here correctly that I took pause writing kernel code, and made a trivial smoke test program. That's why I believe that I will eventually deliver.

@Conan_Kudo I promised to Steve Klabnik to test out DMA Rust patch set when he was complaining about that in Bluesky.

The selfish goal in that is that while I do this, that pushes me to rework my BR environment to be "Rust enabled" and testing some actual Rust kernel code probably helps me to draw the mental picture how to make this work in Rust.

... and obviously keeping that promise because if I say something, I usually also execute it (with some delays ofc like in this case) :-)

@Conan_Kudo ... once you get the grip,

@Conan_Kudo Bookmarked as source material for the cover letter. But yeah "eventual Rust driver" is my plan with first steps in C. Rewriting a driver takes me a day once I have the design in my head so it is only fun then...

@Conan_Kudo

I don't know and I knowingly do not check the previous submission albeit I know it exists. I check that only when I plan to send this. It is a risk because it might dilate my creative thinking :-) I don't care if the first submission does not end up anywhere as I don't have any rush for this, i.e. can do as many iterations as required. I'm also pretty seasoned and patent when it comes to LKML ;-) I.e. that part is least of my worries, or I don't give a fuck to say it straight :-)

Please take this with a grain of salt how the code is *right now* (i.e. not yet ready for review) as I've had to take a break from this (had not free bandwidth).

https://git.kernel.org/pub/scm/linux/kernel/git/jarkko/linux-tpmdd.git/commit/?h=v4l2-loopback&id=4a4a2cfa6724dc546e1ab4d56e8a15461512e7ce

I also have a matching test program, which tracks 1:1 the ioctl changes:

https://codeberg.org/jarkko/v4l2-loopback-test/

The commit on top is my staging area not something you see in the final patch set. The test program helps me to make sure that I don't catastrophically break anything.

I'll basically do for RFC (not final proposal):

1. NOT clean up the code because of cleaning up :-) Changing "presumable messy" is a risk. Any clean ups are only a side-effects of doing something actually useful. I also highly respect others peoples work in open source so I always have crystal clear reason for any possible delta.
2. Refactor ioctl signatures and structures to be ABI agnostic.
3. open(/dev/v4l2-loopback): create a new loopback driver.
4. V4L2LOOPBACK_CTL_ADD: add a new capture/output device to the loopback driver.
5. close(/dev/v4l2-loopback): tear down the driver (and obviously also devices it has created).
6. Define a sane locking model for the internals. I'm not 100% if it works but at least it does not have good coherence. It should be dead obvious how locks work in any driver and should documented in the header (which I'll do).

For cover letter I'll put an option to rewrite with Rust since it is hardware agnostic (and thus that would make sense in new driver). The first RFC version is in C in order to draw a clear path from OTT, to in-kernel C and finally to Rust.

I don't care how many iterations it takes as it is just a hobby sudoku for me.

Phew. Well this was good because 3 weeks gone since last lookup. I'm happy that I have a test program since especially after changing how devices are created and adding necessary anonymous inode shenanigans you need to be able to test those iterations as you go.

"keep calm and hack linux"

My job situation back to more Linux oriented work, which should allow me to have space to work on also on my unfinished patch sets i.e.

1. Continue with v4l2-loopback (according to Git last time touched 2025-19-01)
2. TPM2 asymetric keys (2024-11-18).

Nothing is fully closed yet but having a meeting for one decent opportunity tomorrow that I will consider. Thus, also open for queries since you never know until ink is on the paper of course ;-)

@garrett The conclusion that Grub must die is anyway pretty obvious one.

Grub is what it is because it was "UEFI" before UEFI.

@garrett I use systemd-boot e.g. in my ad-hoc VM's and stuff like that but for my host desktop I don't care how it boots, as long as it boots (unless I'm paid to figure out, not saying it wouldn't be fun and interesting).

In that sense +1 for systemd-boot. I don't mind as long my computer boots.

@garrett Fedora uses it as the default? :-) At least my Fedora 41 installation uses Grub.

Ketä Iltalehdessä on oikein töissä!? Esikoululaisia?

(Silti salaa naureskelen...)

IL: "Nainen pieraisi puhelimeen"
IL: "Outokumpulaisesta syväreiästä tehtiin haiseva löytö"