On Sun, 12 May 2024 17:23:10 +0100 Leah Rowe <i...@minifree.org> wrote: > https://www.mirrorservice.org/sites/libreboot.org/release/canoeboot/20240510/canoeboot-20240510_src.tar.xz
> ** Configuration, building, installation: > It might or might not use Autoconf/Automake, but it must meet GNU > standards. [...] > Does not meet standards at all, but neither does GNU Boot and neither > did the erstwhile GNU Libreboot; it was accepted both then and now > that the design is different, but that GNU needed a viable > FSDG-compliant coreboot distro. GNU Boot didn't meet the standard at the beginning, and now we use autotools since very recently, but despite that I'm unsure if we meet it or not since I used autotools in some non-standard way. At some point we will use autotools in more standard ways. But I'm unsure how much Canoeboot and GNU Boot could collaborate on that in the long run because GNU Boot started to diverge more and more from Libreboot and Canoeboot. > ** Documentation: > We require using Texinfo > ([24]http://www.gnu.org/software/texinfo/) for documentation, and > recommend writing both reference and tutorial information in the same > manual. Please see > [25]http://www.gnu.org/prep/standards/html_node/GNU-Manuals.html > > Pandoc Markdown is used. See: cbwww.git > > The Untitled Static Site Generator is used to generate it. > > This is what GNU Boot also uses, and it has Markdown, and was > accepted. We have preliminary code to convert to Texinfo and still use Untitled and also preliminary code to move from Untitled to haunt but that was not tested with Texifo. That work is not finished though but there is room for collaboration here (for instance me and the future Canoeboot maintainer or Canoeboot contributor(s) could work together to finish that work and make it usable by both projects). The neat thing about Haunt is that it also supports Texinfo, so you could use the Texinfo files to generate both regular manuals but also publish the manual on the website. Guix and probably more GNU projects do exactly that. > I wasn't going to make this request to gnueval, but since GNU Boot > isn't really a thing anymore (no commits in over 4 months on their > main branch, and generally slow development before then), I thought: > why not? I don't know what went wrong here, the only gap that big is between Jan 13 and Apr 30, and after that there is a more regular push of commits. This can be seen with 'git log --pretty=fuller' in https://git.savannah.gnu.org/git/gnuboot.git. Another thing is that you participate to the GNU Boot patches mailing list, so you probably didn't miss the activity there. So maybe you prepared this mail in April and forgot to update it? Generally speaking it's a good idea to try not to do things like that and respect people's time on the other end: this way things are already OK and there is no need to correct everything after the facts. > The way I see it, there will always be a demand for a fully free > coreboot distro, and Canoeboot is currently the only viable project > in this regard. The two projects have very different approaches. That makes comparison not very relevant unless the bigger picture is taken into account. GNU Boot has a more long term focus. For instance we want to reduce out of tree patches, bring back the KGPE-D16 in Coreboot to make sure we can keep supporting it in the long run, reduce the maintenance costs by using Guix, and we are also are actively working on solving the issues mentioned above, and while doing all that we also take care of not breaking what already works. In contrast Canoeboot does exactly the opposite for many of the things above: it carries a lot more of out tree patches, and Leah even tried to convince GNU boot to use some of these patches, the build system used is custom and way less powerful than Guix but probably way easier to learn, and it currently focuses on updating the packages first instead of doing ground work for having a better GNU integration for instance. > Canoeboot is superior to GNU Boot for these reasons: > > * Much more up to date. Uses coreboot, GRUB and SeaBIOS revisions > from 2024, whereas GNU Boot uses revs from late 2021. Updating the version of packages we use is not GNU Boot's top priority, it will happen at some point but many other things are order of magnitude more urgent or important than that. > * Build system is more efficient: 6 shell scripts instead of GNU > Boot's 50, and about 1300 lines of code in the build system, versus > GNU Boot's ~5000. Generally cleaner coding style in Canoeboot. > > * Despite being smaller, Canoeboot actually has more features. Such > as building of serprog images (to make cheap SPI flashers), support > for building U-Boot payload on ARM devices (and they boot), and more > hardware support. > > [...] > > * GNU Boot is going to become more complex, because they want/wanted > to rewrite it all in Guille and use the GUix package manager to build > everything. While this would make individual building easier, it > would vastly increase the maintenance burden and introduce many > moving parts to the project, making it unmaintainable over time. > Canoeboot's design is much simpler and I'm also working on > bootstrapping (e.g. musl-cross-make integration) GNU Boot is migrating to Guix, so in the longer run both will look very different. And the way we use Guix creates almost 0 moving parts (build are hermetic and use fixed Guix revisions). The moving parts is all the rest (basically the shell scripts that don't use Guix). In fact Guix even has the ability to go back in time and build older Guix packages, and can even transparently use a VM to do that to fix the CPU model and time to avoid some timebombs. > * GNU Boot uses Libreboot's old build system design, which is why > it's much bigger. I did a series of audits in 2023 to vastly increase > the code quality in the build system. The advantage of that design for us is that it makes our migration to Guix easier. The disadvantage is indeed that the code quality is bad, but that code will go away step by step. > * GNU Boot lacks many of Libreboot's newer security features, such as > Argon2 KDF support for LUKS2 boot Which are not upstream in GRUB. So there are pros and cons to both approaches here. > I actually did initially try to help GNU Boot instead. The problem > with GNU Boot is that it's based on a really old Libreboot version > and hasn't been changed much since, and they've basically been in > "development hell". [...] > I sent them extensive patches fgixing build > issues, so that it builds on modern distros, andh I sent them patches > updating it to newer upstream revisions e.g. coreboot, but none of my > patches were reviewed. Did you write that the patches were never reviewed because you forgot to update your mail before sending it? You sent many patch series at the same time and expected the maintainers to review them all. What happened instead is that we reviewed some of them and many were rejected because they should be sent upstream instead, other were postponed, some still need to be reviewed, and so far only one could make it and that was after extensive rework from me. So here it looks more like conflicting goals, and different ways of interacting with upstream, and also the fact that I had to take a break from contributing to free software because of urgent personal issues (hence the 4 month delay mentioned above). As for the patches that we expect in general, we try to prioritize patches that don't do too much at the same time, and cannot break the images that have been tested by people and that already work. That said we also have a way to review patches that can potentially break images: after reviewing them we can simply add them in some other branch like gnuboot-next, and merge them when the right time comes, but since we didn't look at all your patches yet (there are a lot), we might still find some that we can merge directly (after reworking them or not, depending on the state of the patch), so these will take priority. In general the long term focus of GNU Boot has a lot of implications. As explained before on IRC and probably on the GNU Boot mailing list as well, GNU Boot work a bit like many other hardware related upstream projects like GRUB, Linux, u-boot, etc, and less like some distributions where every committer can push things fast without reviews. But maybe explaining that one more time isn't very useful, so another way to understand that could be to instead upstream more and more code in any of these hardware related projects again and again over years. The GRUB patch I've been talking about looks a really good candidate since it's useful for everybody and even helps Libreboot and Canoeboot as its wider adoption paves the way for more general migrations from LUKS1 to LUKS2 to protect users as not having this patch prevents migrating some users. At the same time doing that can help getting more fluent with getting patches accepted in similar projects as it take a lot of time adjusting to the requirements of such projects. And it often shows similar and different ways of dealing with projects management, which both help with improving patches acceptation. Since you already contributed several small patches to Coreboot, the jump should not be that hard. For instance it's common in many projects to have patches not reviewed and there is usually a standard procedure for that where you ping maintainers after at least 1 or 2 weeks. And projects like Linux also refuse to review patch sets that are too big or too many patch sets from the same person, but I probably already told you the later. And at the end of the day these requirements is also what makes it possible to keep things maintainable without having to break users use cases. Denis.
pgpS9XysTn1T0.pgp
Description: OpenPGP digital signature
_______________________________________________ libreplanet-discuss mailing list libreplanet-discuss@libreplanet.org https://lists.libreplanet.org/mailman/listinfo/libreplanet-discuss
