| Newsgroups |
gmane.linux.lfs.beyond.devel |
| Message-ID |
<[email protected]> |
On Tue, 2025-09-02 at 12:33 +0200, Thomas Trepl wrote:
> *) We should discuss the topics in such a manifest separately. A few of
> them, but definitely not limited to, would be imho:
> - What is B/LFS
> Still educational stuff showing how things are done to get a working,
> personalized Linux based OS? Customization was the motivation of Gerard,
> later it became material for university courses afaik. Or are we working
> toward a distro? Or something in between?
Is there a significant importance to invent yet another a non-
educational distro?
> - Is B/LFS refusing to use binary objects
> what about firmware, bootstrap binaries for Java, FreePascal, FreeBasic,
> gcc-ada, gcc-d, ...?
We refuse to *support* (not "use") *non-cooperating* binary objects.
Say if the bootstrap binary for Rust spits an ICE I can at least modify
the code and rebuild it with a working Rust compiler as an attempt, and
when I report a bug to Rust they often try to fix it as long as I can
provide diagnostic information. But I cannot do a thing for N****A
binary driver, and based on my experience with those vendors they tend
to ignore my bug report and/or blame the distro I use no matter if the
distro maintainers have attempted to "support."
> - B/LFS does not include libs to book if none of the books pkgs do use it
> Why not? As long as someone maintains it? Whats the difference to
> applications? I do not use KDE nor GNOME, why are they in the book? Ah,
> other people do use it. So, maybe others do use that library?
If you are going to maintain the library anyway you need to test if it
works, and you need to build and test the application when you tag the
library for the book. So why not adding the application into the book
too?
> - B/LFS uses stable versions of packages
> If true, why do we rush behind the socalled stable kernel instead of
> using a longterm version which is what can be understood as 'stable'? Is it
> about supporting new hardware? Are we in a competition with lets say
> ArchLinux to be most-current? Or would a stable line (which is updated from
> time to time is something important happened) be enough for showing how
> things work?
My (and many Linux users I know personally) consider the stable kernel
running better than the so-called "longterm" kernels for us, as long as
we don't need an out-tree module.
And even consider out-of-tree module, it's generally still better if you
can adapt it for the latest stable kernel. For example when I adapted
an out-of-tree non-x86 platform GPU module for Linux 6.16, the
performance increased significantly (I didn't make any attempt to
optimize it, I just replaced the uses of removed API functions with the
currently used ones; and those new API functions already exist in 6.14
so I also tried the modified module on 6.14, and the performance still
increased significantly on 6.14 compared with the original one which
already "works" on 6.14).
--
Xi Ruoyao <[email protected]>
--
http://lists.linuxfromscratch.org/sympa/info/blfs-dev
Unsubscribe: See the above information page