Jarkko Sakkinen
Posts
5046Following
330Followers
504OpenPGP: 3AB05486C7752FE1
Jarkko Sakkinen
repeated
repeated
Jan Wildeboer 😷
jwildeboer@social.wildeboer.net
Edited 1 month ago
In my personal opinion: Instead of banning, say, Chinese companies from delivering infrastructure components like the EU is pondering with Huawei and mobile networks, the ultimate goal should be to demand open source software/firmware for these components and reproducible builds of all software components so #DigitalSovereignty becomes default.
8
15
0
@tshepang and not saying this is the exact pattern what should be followed. Just one way to look at the problem. Being ubiquitos and maximizing deployabiltiy and being "at the bleeding edge" tend to be two contradicting goals that exist in any possible language and tool ecosystem, and thus they need to be balanced out.
1
0
0
@tshepang OK thanks, that is fair question :-) I just answer always based on context.
For a project like Gix I'd probably ollow Debian stable's rustc if possible (by realistic measures).
And if rustc in stable is getting old lookup:
1. If backports has a newer version consider that.
2. If testing branch of Debian has been freezed that might also be good choice.
I picked Debian because it has the most concervative baselines overall. If you can maintain your project within those constraints your Linux distribution converage is literally all the major Linux operating systems in existence.
And yeah sorry, of course I will retry Gitoxide one day again when I get out of recent frustrations with it. You just have to say one nasty childish thing to get over it :-) Sorry about that.
For a project like Gix I'd probably ollow Debian stable's rustc if possible (by realistic measures).
And if rustc in stable is getting old lookup:
1. If backports has a newer version consider that.
2. If testing branch of Debian has been freezed that might also be good choice.
I picked Debian because it has the most concervative baselines overall. If you can maintain your project within those constraints your Linux distribution converage is literally all the major Linux operating systems in existence.
And yeah sorry, of course I will retry Gitoxide one day again when I get out of recent frustrations with it. You just have to say one nasty childish thing to get over it :-) Sorry about that.
2
0
1
Jarkko Sakkinen
jarkko
I wrote my views about AI policy proposal:
https://lore.kernel.org/all/aRKeLRx2NeozFUrc@kernel.org/
#linux #kernel #ai
https://lore.kernel.org/all/aRKeLRx2NeozFUrc@kernel.org/
#linux #kernel #ai
0
0
1
@ljs personally, when i see patch think "why that person needs this" or 'why company X needs this" and stuff like that. Bots don't need any of the changes they supply, which is a problem (at least for me). I don't want to serve the needs of those who don't have needs because well, it's fucking crazy for instance :-)
0
0
0
Jarkko Sakkinen
jarkko
@lkundrak the nam shub of enki and kiki ill, top of the pops from australia (including macarena) https://namshubofenki.bandcamp.com/album/the-nam-shub-of-enki-meets-kiki-ill-in-the-valley-of-mood
0
0
0
Jarkko Sakkinen
jarkko
1
0
0
@penguin_brian TBH, it is gibberrish :-)
Thanks for asking. I was trying to refer to minimum supported rust version (MSRV).
Thanks for asking. I was trying to refer to minimum supported rust version (MSRV).
0
0
0
Pipeline is also float free with subpixel accurate integer rendering to keep shit simple and translatable.
And I do have a plan to get a real scrolling experience not just page flipping (to what sixel actually scales). I just need to test my theory first...
And I do have a plan to get a real scrolling experience not just page flipping (to what sixel actually scales). I just need to test my theory first...
0
0
1
Jarkko Sakkinen
jarkko
Edited 1 month ago
Developing a rendering engine for mailweb 0.3. The gist in that is Servo rendering the mail as a set of offline rendered tiles.
Given that Servo is complicated I'm figuring offline rendering part in a separate project.
I needed some tileable content to work with so I wrote "a classic" fractal cloud generator out of my memory (decades ago literally) ("diamond alike" recursion and periodic perlin noise) :-)
This was also great finding: https://github.com/rust-windowing/softbuffer
Given that Servo is complicated I'm figuring offline rendering part in a separate project.
I needed some tileable content to work with so I wrote "a classic" fractal cloud generator out of my memory (decades ago literally) ("diamond alike" recursion and periodic perlin noise) :-)
This was also great finding: https://github.com/rust-windowing/softbuffer
1
0
1
Jarkko Sakkinen
jarkko
What is a common set of algorithms in a "typical" TPM2 chip at Chinese market. I.e., something like Infineon 967x but SM3 based?
I dropped MockTPM from tpm2sh but I'm plannig to resurrect it as a focused and almost zero configuration TPM emulator with exactly two preset configuration. I will pay also attention to QEMU integration. I think presets could be even named after chips.
Options will be something along lines:
1. --cache-dir
2. --preset (not sure about option name yet)
3. Options for supplying certificates for endorsement CA.
That's it.
#linux #kernel #mocktpm #tpm
I dropped MockTPM from tpm2sh but I'm plannig to resurrect it as a focused and almost zero configuration TPM emulator with exactly two preset configuration. I will pay also attention to QEMU integration. I think presets could be even named after chips.
Options will be something along lines:
1. --cache-dir
2. --preset (not sure about option name yet)
3. Options for supplying certificates for endorsement CA.
That's it.
#linux #kernel #mocktpm #tpm
0
0
1
Jarkko Sakkinen
repeated
repeated
Brad Linder
bradlinder@fosstodon.orgMaemo Leste is a mobile Linux distro that carries on the legacy of Nokia's short-lived Linux-based smartphone OS. Ccurrently based on Devuan Daedalus (Debian Bookworm), work is underway to migrate to Excalibur (Trixie). Here's a summary of recent developments. https://maemo-leste.github.io/maemo-leste-2025-daedalus-release.html #MobileLinux #MaemoLeste #Maemo #Debian #Duvian
0
6
2
@epage And in the end of the day this is a cultural and a process issue.
E.g., let's imagine if Gitoxide tried to control RVSP better than today. That would ripple to its dependencies via build regression reports (in some cases).
"Pure Rust" makes only sense (from pragmatic AND *in production* perspective) if it delivers at least being as ubiquitos as an equivalent C-library. It's bare minimum expected to consider Gitoxide as a serious alternative to libgit2, which one of the most mature and stress tested libraries in existence.
E.g., let's imagine if Gitoxide tried to control RVSP better than today. That would ripple to its dependencies via build regression reports (in some cases).
"Pure Rust" makes only sense (from pragmatic AND *in production* perspective) if it delivers at least being as ubiquitos as an equivalent C-library. It's bare minimum expected to consider Gitoxide as a serious alternative to libgit2, which one of the most mature and stress tested libraries in existence.
0
0
0
@epage It's not like I "want it to suck". Just noticed that I only need to add e.g., BuildRoot to the equation and it'll be hell with anything using Gitoxide :-) So I migrated already functional code using Gitoxide back to libgit2 because I don't want to spend my days and focus with that crate.
1
0
0
Jarkko Sakkinen
jarkko
@epage, For such as serious lib crate I'd proactively maintain fairly conservative RSVM for the full nested dependency graph.
Otherwise, in the end of the day, the developer experience will suck and the crate does not scale, which means also scaling *down* (for some amount) when going to e.g., embedded builds.
Otherwise, in the end of the day, the developer experience will suck and the crate does not scale, which means also scaling *down* (for some amount) when going to e.g., embedded builds.
2
0
0
Jarkko Sakkinen
jarkko
Edited 1 month ago
Through dependency graph GItoxide has a RSVM requirement of 1.88.
For me that means exactly to never use Gitoxide and stick using libgit2 bindings because they retain software ubiquitos across environment and toolchains.
This also thought me an important lesson: using well established C-library throught bindings is 9/10 times a better choice than using equivalent "pure Rust" implementation. This does not mean that the Rust implementation would be somehow"worse", generally it just seems that Rust developers are completely ignorant of optimizing things like RSVM.
That leaves you two options.
1. Use a really old version of "pure Rust" library in order to maintain RSVM of your choice. Usually this means using a version, which never will be updated.
2. Use Rust-bindings of a C-library and have always up to date version of the dependency while retaining RSVM of your choice.
The crazy RSVM requirement of Gitoxide zeros down its applicability for anything production. I will never touch it again.
#rustlang
For me that means exactly to never use Gitoxide and stick using libgit2 bindings because they retain software ubiquitos across environment and toolchains.
This also thought me an important lesson: using well established C-library throught bindings is 9/10 times a better choice than using equivalent "pure Rust" implementation. This does not mean that the Rust implementation would be somehow"worse", generally it just seems that Rust developers are completely ignorant of optimizing things like RSVM.
That leaves you two options.
1. Use a really old version of "pure Rust" library in order to maintain RSVM of your choice. Usually this means using a version, which never will be updated.
2. Use Rust-bindings of a C-library and have always up to date version of the dependency while retaining RSVM of your choice.
The crazy RSVM requirement of Gitoxide zeros down its applicability for anything production. I will never touch it again.
#rustlang
2
0
0
