ripped off from internet (from random chat box)

#x86 #scratch

my slandering: it is just every day geek frustration, which is totally different story than ripping of human rights.

there is "hate" and hate. a huge difference. also wanted to make sure that i don't get associated with the latter.

i might be an asshole sometimes but definitely not a monster :-)

Since I've said negative things about Microsoft and Windows in the past, I also have to give credit where it is due (because otherwise I would not have any integrity).

Thanks MS for taking the righteous path, my respect for the company raised by factors:

https://www.hrgrapevine.com/us/content/article/2025-01-21-apple-microsoft-double-down-on-dei-as-trump-begins-dei-dismantling

We can have our differences in tech matters but then there are things that actually matter like human rights for instance.

#apple #microsoft #dei #inclusiveness

@Conan_Kudo Also I think it was good to think it through myself rather read the feedback. If I had started to read the feedback I would have run away at instant. Now I've modeled the problem areas myself and have better clarity. Feedback can be also a huge distraction factor when u are starting :-) Not same as ignoring it but one way to cause unnecessary paralysis at starting point.

@musicmatze Because that way I don't have to install Nix to my host system.

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.