Announcement

Collapse
No announcement yet.

Linux From Scratch 12.0 Published For Rolling Your Own Linux Build

Collapse
X
 
  • Filter
  • Time
  • Show
Clear All
new posts

  • Linux From Scratch 12.0 Published For Rolling Your Own Linux Build

    Phoronix: Linux From Scratch 12.0 Published For Rolling Your Own Linux Build

    For those with extra time over the US Labor Day holiday weekend, Linux From Scratch 12 has been published for those wishing to hand-roll their own Linux system build from source. Linux From Scratch 12.0 is accompanied by the Beyond Linux From Scratch (BLFS) 12.0 release too, including the systemd variant, for further extending LFS installations with more packages...

    Phoronix, Linux Hardware Reviews, Linux hardware benchmarks, Linux server benchmarks, Linux benchmarking, Desktop Linux, Linux performance, Open Source graphics, Linux How To, Ubuntu benchmarks, Ubuntu hardware, Phoronix Test Suite

  • #2
    LFS is something I always wanted to attempt, I last attempted it in highschool and I've learned so much about Unix and Linux since then. Upgrading it is probably the only thing keeping me from using it. Maybe over the Christmas holiday I can try this out this winter?

    Comment


    • #3
      Originally posted by kylew77 View Post
      LFS is something I always wanted to attempt, I last attempted it in highschool and I've learned so much about Unix and Linux since then. Upgrading it is probably the only thing keeping me from using it. Maybe over the Christmas holiday I can try this out this winter?
      It's good for learning quite a bit...

      It's good for learning how insane it can be to put together a Linux distribution. You quickly find out why early Linux people started building packaging tools to manage the insanity of mutually exclusive versions, version specific bugs or breakages, etc. Nightmare.

      It's good for learning why upstream X does Y, and how that may be different than a distribution wants or needs to do it.

      Why crotchety old Unix people regularly scream RTFM when you bug them about questions that have already been answered... I'll point out that asking questions already answered is different than asking where to find an answer or asking for a clarification on an answer.

      Following on the last point... Linux documentation sucks. So even though someone may be irritably screaming RTFM! Doesn't mean there actually is a manual or the manual is accurate, up-to-date, or complete.

      ...even if you get an answer from the crotchety old Unix person who swears up and down it's true... it may not actually be true because "It's common sense," or "It's common knowledge," isn't a legitimate explanation and is often wrong, subtly or otherwise, more often then correct.

      Code never documents itself not even if the programmer's ego is bigger than a super massive black hole's event horizon.

      The people that build, maintain, and contribute to the Arch Linux Documentation Wiki are modern day saints as are the people that take the time to put together the LFS (Linux From Scratch) guide.
      Last edited by stormcrow; 01 September 2023, 10:54 PM.

      Comment


      • #4
        My experience is that most complexity comes not from building toolchain but from building toolchain into another prefix. That needs various ./configure flags to be correctly specified.

        ON the other hand, if instead of LFS you try bootstrapping from a tiny subsector sized seed and follow https://github.com/fosslinux/live-bo...ster/parts.rst in some sense it becomes even then if you pick LFS as starting point.

        Comment


        • #5
          Originally posted by stormcrow View Post

          It's good for learning quite a bit...

          It's good for learning how insane it can be to put together a Linux distribution. You quickly find out why early Linux people started building packaging tools to manage the insanity of mutually exclusive versions, version specific bugs or breakages, etc. Nightmare.

          It's good for learning why upstream X does Y, and how that may be different than a distribution wants or needs to do it.

          Why crotchety old Unix people regularly scream RTFM when you bug them about questions that have already been answered... I'll point out that asking questions already answered is different than asking where to find an answer or asking for a clarification on an answer.

          Following on the last point... Linux documentation sucks. So even though someone may be irritably screaming RTFM! Doesn't mean there actually is a manual or the manual is accurate, up-to-date, or complete.

          ...even if you get an answer from the crotchety old Unix person who swears up and down it's true... it may not actually be true because "It's common sense," or "It's common knowledge," isn't a legitimate explanation and is often wrong, subtly or otherwise, more often then correct.

          Code never documents itself not even if the programmer's ego is bigger than a super massive black hole's event horizon.

          The people that build, maintain, and contribute to the Arch Linux Documentation Wiki are modern day saints as are the people that take the time to put together the LFS (Linux From Scratch) guide.
          When you say "Linux documentation suck", what do you mean? I think it's actually pretty good: https://docs.kernel.org/

          And I mean, LFS is one giant documentation on how you build a distro from scratch. How does that suck?

          Comment


          • #6
            I did LFS 23 years ago when recovering from an accident. My biggest achievement was modifying the build scripts for Xorg to have more parallelism on dual-processor machines. It was fun.

            Comment


            • #7
              I was surprised by just how many "non-default" setting some packages took. I flicked through LFS in terms of "build this, then build this", but yeah: if you want it to actually do something sensible, you need to pass 10 parameters to ./configure

              Comment


              • #8
                Definitely on my bucket list of things to do, but before that I want to finish moving through Wiley publishing's Linux Command Line and Shell Scripting Bible, and pick a decent language or two on the way, Tcl, Python, I have a book on C programming but man, C you talk about time consuming and lifespan dedication. When it comes to some things I start questioning myself am I smart enough to even begin tackling such tasks.

                Not trying to knock myself but sometimes all things considered people need to know their limits. I might ought to have a multitrack editor and mixer window open trying to have fun making music instead of focusing on this stuff.

                All of the above mentioned I may be settling on Tcl.
                Last edited by creative; 02 September 2023, 03:24 PM.

                Comment


                • #9
                  Originally posted by Sonadow
                  Using Debian with a 6.5 kernel, custom Mesa, Intel OneVPL, Vulkan, LLVM, ffmpeg, the entire shitton of av codecs and V4L2 LFS-ed over it.

                  Fucking pain to maintain and basically means installing crosscompile tools or installing WINE is no longer possible because the repository will insist on overriding my custom stuff.
                  This is where Fedora's "toolbox" comes incredibly handy. Not sure if it can work on Debian though.
                  Last edited by jacob; 02 September 2023, 06:00 AM.

                  Comment


                  • #10
                    Keeping LFS project alive is NECESSARY for all of us as a community (even if every one of us never use it)

                    Comment

                    Working...
                    X