To flash/update or not to flash/update firmware.

Maybe with a small amount of build/run dependencies and many build options, boot programs could run/be built on many systems.

Also with less dependencies there may be less "attack surface" as less code will be needed.

And that could also give end users more choice in what programs they wish to have on their computer.

https://forums.hyperbola.info/viewtopic.php?id=1029

shows information about "Construction of gnuboot in Hyperbola"

and I see a user called throgh there typed

The problem is that neither GNU Boot, nor Libreboot respect alternative implementations and await "standards". As you can see in the repositories: Grub can surely be build without gettext. The problem is more: What is grub awaiting in the version used? So alternative implementations like Hyperbola and surely also others are not really supported using the configurations for GNU Boot or Libreboot. I would perhaps recommend a rather different approach as you can try install a bigger system within qemu on Hyperbola: https://wiki.hyperbola.info/doku.php?id=en:manual:virtual_machine_manager

There you could build the current ROM-image and use it direct with Hyperbola also. The idea behind is also perhaps good as you can backup your created VM and use it at any given time.

This only shows part of the discussion, so continuing that discussion there may be more helpful than here, but I like the idea about having many options/alternative implementations.

So maybe more alternative implementations/forks?/options could also help as well as showing commitment to "free as in freedom" supporting software.

Though names of the program would also have to be easy to change, to show how it was a fork. I do not know how to quickly change a program's name in a repository yet. Only how to clone the repository.

https://www.gnu.org/distros/free-system-distribution-guidelines.html

shows in part

Nor should the distribution refer to third-party repositories that are not committed to only including free software; even if they only have free software today, that may not be true tomorrow.

So developers should also have shown a long track record of not including non-free things, so that could be why some people like things like Gnu Boot. This could help with building some trust with end users.

https://wiki.hyperbola.info/doku.php?id=en:philosophy:incompatible_packages

shows

There is no easy patch!

Please be also aware that even if it would be possible to patch several dependencies out for packaging a concrete version: This patch would only work for a concrete version and release. With any new released version the whole work would be done again or even worse is no longer possible. Also take into your perspective that even a questionable dependency is once optional it may be changed in coming new releases. For a small system and project like Hyperbola this is not acceptable. You cannot select the fitting convinient way, just some packages are not fitting and others do. Either to follow the whole strict way for not ignoring issues or staying pragmatic. The decision for the project is oriented onto not ignore all issues!

Also large changes to the code, or if developers try to add/remove many things to the code, it may not look like the code is stable in Hyperbola's use of the word stable, as in their system. It is also hard to check all the changes fast, if there are many of them.

So patching out non-free code in large programs, or in programs quickly or largely changed could be hard.

https://wiki.hyperbola.info/doku.php?id=en:project:update_philosophy

If stable in software means something like "long-term support" or mostly just adding security backports but not changing much of the code.

I do not know much about stable vs bleeding edge software development.

Though fully free software is much more user friendly than non-free software. As non-free can force updates or do things the end users do not wish it should do.

Though does firmware get changed often?

https://en.wikipedia.org/wiki/Firmware

I thought some things have a low read/write cycle and flashing many times could lower the "lifespan" of a device.

The program wipe even shows in Trisquel's Synaptic Package Manager shows

Wipe can permanently delete data in hard disks and flash drives (caution!
several writes can damage solid medias).

in part of it's description.

A user called bio at the Hyperbola forum typed

I see.

Then I'm going to attack the two-sided problem:

1) Build gnuboot in VM-compatible system; and,
2) Forward the issue for gnuboot and libreboot projects.

Who knows they don't care, since we're part of the group that value their systems?

Gnu Boot and Canoeboot developers may both be working on boot programs.

Though maybe the above reasons is why Gnu boot may update less than some other boot programs. To give it's users time and choices to chose what they wish to update as well as if they wish to make any fork/alternative implementations. And to understand the code. Not because Gnu Boot development is slow as the latest update was at least maybe 2024-05-21, so very recent.

I used git clone https://git.savannah.gnu.org/git/gnuboot.git

Maybe I'm mixing up boot programs and eeprom like firmware though.

A person named Ben Eater showed how to program an eeprom on a 8-bit machine, and also showed how to program it both with an Arduino and with a hand make hardware thing on a breadboard.

https://archive.org/details/ben-eater-youtube-archive

Though this is only a simple computer,

https://en.wikipedia.org/wiki/Simple-As-Possible_computer

I do not yet know if Gnu Boot or Canoeboot needs an internet connection to download more things from the internet. Or if both can have all code downloaded and checked before building, so as to build even without an internet connection.

https://www.gnu.org/software/gnuboot/web/

https://canoeboot.org/