On 2024-07-10 06:45, Simon Josefsson wrote:
Jing Luo <[email protected]> writes:formatted the rootfs as btrfs, with linux-generic-64k-hwe-11.0-edgeWhat is the benefit of the 64k kernels? The package description doesn'treally say one would just them over the other ones. Are there performance differences?
From what I understand, larger page size means that the memory allocation will be less computationally expensive. But so far I don't know if there is real, visible difference in performance. However, larger page sizes can break compatibility, like Proxmox uses a certain Rust jemalloc that only supports 4K page size (so I've heard). Your Talos II should default to 64K page size, I remember only seeing the 64K option in linux's menuconfig for ppc64el. Also, Raspberry Pi foundation ships 16K page size kernel (non-free) with Raspberry Pi 5.
https://en.wikipedia.org/wiki/Page_%28computer_memory%29#TLB_usage
Right now, I am using linux-libre 6.9.8 on my machine (thanks Jason for releasing gnu-2.0 versions in gzip format!) because of a known (mostly cosmetic) bug with the mpt3sas driver that also occurs on amd64. I didn't have any issues with the vanilla trisquel kernel before adding the LSI card to the machine. I tried the linux-libre-lts 6.6 packages and they work fine on this machine too.
Ah yes! Although from a user's perspective, I usually don't recommend using upstream packages directly, be it linux or linux-libre (freesh), because they tend to be raw and unrefined. Downstreams like Trisquel (or even Debian) have a more refined config/preset and is more suitable for day-to-day uses. An example would be the issue you encountered with gzipped/uncompressed vmlinuz, Trisquel or Debian didn't break when freesh did (no offense to our hero Jason).
There are plans to improve the node stack, as Ecne will be adding riscv and more load to arm, but that's is still on it's way. Using community vm/nodes might require to layout some security policies, and some other directives, we'll need to find some time to define those if moving in that direction.I am also happy sponsor build machines here, but I understand the dilemma about riscv. Either you purchase some riscv machine and set it up yourself (I am happy to donate funding for this), but then as far as I understand the requirements, we would need to make sure it runs ononly free software and no blobs. I got my Milky-V Pioneer riscv machineworking via upstream's kernel image and Debian debootstrap. I have tried installing both Debian and linux-libre kernels, but I just get a blank screen when booting. I have been hoping for months that the Debian people make progress on a kernel for this hardware, but I don't know if there is any known problem or just lack of time. So we don't really know if this machine can ever boot without some non-free blob ornot. The alternative is to build in people's VM, and I'm happy to setupa VM on the riscv machine I have, but then there are BOTH trust issues with the hoster and the uncertainty about freedom of the hardware. I don't know of a way to resolve this... I would be unhappy if ecne won't ship with riscv due to this. There are not that many unique packages in trisquel, it would be entirely possible to rebuild all of them on a new hardware eventually to increase trust in the packages.
I would be happy if Trisquel becomes the first 100% libre distro that officially supports riscv64. Before that happens...I'm stuck with debian sid.
I think if you build u-boot and linux(-libre) from source for a certain board, you should know if that board can boot with only free software. I also have a few SBCs that won't boot with upstream or debian's kernel, so I ported many patches from "vendor kernel" then build the kernel myself. They are buggy, many drivers won't work properly, but at least they are libre, unlike the blob-ridden "vendor kernel". However, I have a RK3588 based ROCK 5B that requires me to insert a blob when compiling u-boot, that was when I realized RK3588 requires non-free software... So the conclusion is, if the board can boot with a "clean" u-boot and linux-libre, then it doesn't require non-free blobs to boot. However, in many cases, HDMI and GPU won't work without blobs, but I gave up on those already (who needs framebuffer support anyway? :)
I've heard stories that it's hard to make Milk-V Pioneer boot, but I have confidence to make it work :) I plan to buy the board when I save enough money and US dollar is not so strong. Anyway, for Pioneer, two months ago I looked at upstream linux 6.8 device tree, it seems that the support for this board is very minimal: only serial console, CPU and RAM are supported. Judging from kernel.org mailing lists and Debian's salsa, I don't think anyone is working on it. The manufacturer Milk-V in China (located in my hometown actually) doesn't seem to care about upstream support at all, like most other SBC manufacturers. But in any cases, if I do get this board and make it work this year, I would also like to host a node for Trisquel's build farm.
-- Jing Luo About me: https://jing.rocks/about/ GPG Fingerprint: 4E09 8D19 00AA 3F72 1899 2614 09B3 316E 13A1 1EFC
signature.asc
Description: OpenPGP digital signature
_______________________________________________ Trisquel-devel mailing list [email protected] https://listas.trisquel.info/mailman/listinfo/trisquel-devel
