New comment by fungilife on void-packages repository

https://github.com/void-linux/void-packages/pull/41420#issuecomment-1493054737

Comment:
limine.cfg

I packaged limine for the joborun linux distro and recently upgraded.  I still find the limine.cfg sample lacking and haven't yet reached a level of expertise to create one of my own (and possibly share it here),  I would think a good sample .cfg would utilize the maximum of options available and not be a minimal functional .cfg.  Guessing what the correct syntax for the variables/fields have become a hopeless and endless guestwork experiment.

I find your philosophy.md rather contradictory and I do not share much of this same philosophy, which is not a problem for either one of us but contradiction is for both of us.  One the one hand you adopt the industrial motion (I wouldn't call every choice industry makes either progress or development) for non-bios non-legacy booting, on the other hand you reject it in the fashion of filesystem selection.  Either drop ext(n) all together and limit your scope in Fat32, dropping the linux marketing approach all together, or do add other common linux fs support.  Maybe as modules that can be configured at build-time whether to be included or not.

I wouldn't make an argument for zfs or btrfs, as I despise one and never used the later,  but xfs is a close cousin of ext in philosophy and functionality with significant advantages (i.e resizing a mounted system partition, strict accuracy on writing data).  Since the distant past xfs had a minor advantage in speed over ext mainly due to its journaling outside the partition ability.  This small advantage with the continuous development of speed of read/write of SSD/M2 technology and multitasking/multiprocessing has become a measurable significant advantage.   Hence the resurrection of interest in that fs.  

Where the limine sw is located and to what fs it can be written may be both a system and policy issue, but dictating to what fs the kernel should be written and whether it should be separated from the partition of the remaining system is a bit beyond the scope of a bootloader.  It borderlines the dictatorial approach of systemd/ibm legacy.

Then there is the issue of people multibooting MS systems that seem to be moving to strict NTFS efi partitions which is an additional mess a bootloader must deal with, if it is not to alienate all those users who must be able to boot MS-w for work requirements.

Hence the characterization of contradictory in reference to philosophy.  I'd say drop the ext support as it was never there as an easy route.  And so goes industrial trends of calling themselves evolution and development when they are accumulating one mess on top of another to enforce their products and displace those of "competing" interests.

Legacy in terms of booting should be perceived strictly as bios with mbr/dos table where nothing other than text configuration files of a bootloader can exist within the "system".  It is getting harder and harder to distinguish wolves in sheep''s clothing and Trojan horses in FOSS.

Where would "the industry" be if unix/linux wasn't able to boot anymore on their new toys?  Why is everyone rushing to comply so much to "development"?  So MS/IBM/Google/Facebook/Oracle  engineers can write and compile code on FOSS?  F* them!