Everything ends up as a fork eventually
2022, September 3th
Because language's a b****, bro.
2023, July
Changes with Archiso are a lot now. It seems to me the codebase here is way more clear and readable.
I'd like upstream to merge this fork back but I apparently can't manage to get a comment on or a full code review on non-feature changes on the drafts.
I am still confident they are gonna merge/backport some of the changes back eventually, because I am sure they are able to see good (or at least better than current, or at least in a good direction) code restructuring has happened.
I joined and chit-chatted last month about this fork on Arch Linux Telegram chat channel, too, to have some fun and to catch attention from external code reviewers, without success.
Unfortunately, I must leave a negative review of that group, where apparently cold-blood admins who have aliased the ban command to the mute command are allowed to behave as sheriffs.
I help administer some quite big chat groups on Telegram myself, too and I never got a single complain about my bans or my way of dealing with communication issues between users. This is to say I know what I am talking about.
What has happened, the fact after weeks I am still out, the fact I've been explicitly said Telegram chat events are influencing reviews of my code forces me to talk about this here.
Changes
- most of the code here is documented
- here code redundancy is way lower
- most of the lines of code here are under 60 characters
- most of the code here is structured as a set of independent functions
- volumes are treated uniformly1
- here is more security focused because a no-install system is required2
- in general here more things are wanted and more often3
Notes
-
so for example EFI system partition image file is simply the
efi_boot
fat volume, built with the same functions as the root file system (airootfs
).↩ -
support for BIOS GRUB MBR boot has still not added because no chainloading for PXE has been published; see archlinux/archiso#194;
↩