Live data from Hacker News

Linux from Scratch

linuxfromscratch.org

151–160 of 164 posts

Re: Linux from Scratch

#151

I gave LFS a go earlier this year. I learned a lot through the process - but I definitely went outside the guardrails. I use NixOS as my daily driver and found myself curious of whether I could complete LFS using a "Nix" approach. I was only a basic Nix user at that time and that choice made a difficult process much more difficult. However, the declarative nature of Nix meant that I had clear notes of every step of m…

Why did you need to chmod every ~2,600 files? man pages, docs, includes. Why not chmod -R or something? https://github.com/cloudripper/NixLFS/blob/64e333f60cca4bec5...

Fair questions. If the question is "why did I need to chmod those files", the answer is that permissions modifications in the mkderivation build environment are not propagated to the build output. The quick and dirty solution I came up with was to make a chmod wrapper that logged the calls so that I could apply them after the entire build completed.

For why I did not chmod the directories - that is something I should probably do when I get time again (cleaning up permissions handling more broadly). In my case at the time, I had the logs from the wrappers and did a quick filter before directly adding them to the script as a last hurdle to having a bootable machine after a month-long grind.

The kernel config handling needs a good amount of attention too. I have a cleaner approach to that in mind that I haven't had the opportunity to work on.

It will likely be December before I am able to invest much more time into it, but definitely open to any input generally.

Re: Linux from Scratch

#152
post #3

I really like the idea, really tried following the process several times. But each time it just turned into a copy-incomprehensible-commands-into-the-terminal exercise at some point, and I lost motivation. Did anyone experience the same?

At the risk of sounding very distasteful, you could always just ask one of the gippities to understand what a command does. Though this would be less painful, I suppose you would lose out on having to go through the man pages and learning how to navigate those effectively. I myself don't really like looking into the man pages for answers. I just go in there for confirming the answers.

Re: Linux from Scratch

#153

I always thought Slackware [1] was the basic Linux distro which people could use to 'understand' Linux. How does Slackware compare to LFS in terms of understanding the Linux fundamentals? [1]: http://www.slackware.com/

Slackware is more like a BSD of Linux, to stretch an analogy. A very solid base system, all packaged up as a complete operating system.

LFS is utterly different. There is no installer, there is no base system, there is nothing even approaching the power of Slackware's package manager, as barebones as it seems today.

This is compile everything from source in a separate environment and put everything in the right place essentially manually*.

Of course, `make`-and-friends will usually do the actual lifting, but you're in charge of giving direction, there isn't a distro community patching packages and build-scripts to adhere to a consistent FSH or the like.

Re: Linux from Scratch

#155

Earlier quoted context omitted.

Why did you need to chmod every ~2,600 files? man pages, docs, includes. Why not chmod -R or something? https://github.com/cloudripper/NixLFS/blob/64e333f60cca4bec5...

Fair questions. If the question is "why did I need to chmod those files", the answer is that permissions modifications in the mkderivation build environment are not propagated to the build output. The quick and dirty solution I came up with was to make a chmod wrapper that logged the calls so that I could apply them after the entire build completed. For why I did not chmod the directories - that is something I should…

> The kernel config handling needs a good amount of attention too.

https://github.com/cloudripper/NixLFS/blob/64e333f60cca4bec5...

Could you speak a bit about why you did it this way instead of maintaining a complete copy of the kernel .config you wanted?

Re: Linux from Scratch

#156
post #61

Earlier quoted context omitted.

Reading and actually understanding non-trivial text is hard if you are part of a generation that was never challenged to actually learn it. For those people, YouTube (and a few similar shops) are the default way to consume any content. That's what they do all the time. Sure, they somehow know those legacy emojis that you call the latin alphabet. It will just not lead to a deep understanding of text. Another aspect is…

> Reading and actually understanding non-trivial text is hard if you are part of a generation that was never challenged to actually learn it. I don't think this is fair to say. Could be said for the generation after me. Maybe not. I think this kind of sweeping generalisation is not fair on any generation though. There are motivated and lazy people in all generations, as there are people with good/bad attention spans.…

You tried (and failed) to install Arch many many times, based on YT, and you have not even considered that there might be some kinds of helpful resources directly from Arch outside of YT.

Sorry to say that, and even more sorry that you'll probably not even understand what I mean, but this actually doesn't need any further comments.

Re: Linux from Scratch

#157
post #101
post #63

Between LFS and Stage 1 and 2 Gentoo installs back in the early 2000s during High School, this gave me a big leg up in my journey of learning about computers and Linux. I can't thank those project maintainers enough for helping me get my footing at such a young age and peaking my interest in computing. I ended up printing out the LFS book in segments on one of the printers in High School and brought it home in pieces…

Same, ricing Gentoo taught me a lot about linux and mainly how to fix it. 20+ year career later... I'm still learning how to fix it :)

I recommend uninstalling python. Great learning experience.

Re: Linux from Scratch

#158
post #102

Earlier quoted context omitted.

Yep. Recompile all the things with different USE flags.

Recompiling the entire openoffice so it loads 1 second quicker.. just using a hacked up distcc cluster and a day's worth of CPU time. Bargain!

It can actually be a bargain though. CPU time I can buy with money, life time is a lot more difficult to extend (not to mention the frustration a second of startup time can cause).

Re: Linux from Scratch

#159

Earlier quoted context omitted.

Fair questions. If the question is "why did I need to chmod those files", the answer is that permissions modifications in the mkderivation build environment are not propagated to the build output. The quick and dirty solution I came up with was to make a chmod wrapper that logged the calls so that I could apply them after the entire build completed. For why I did not chmod the directories - that is something I should…

> The kernel config handling needs a good amount of attention too. https://github.com/cloudripper/NixLFS/blob/64e333f60cca4bec5... Could you speak a bit about why you did it this way instead of maintaining a complete copy of the kernel .config you wanted?

There's a couple reasons for that.

First, for my initial attempt at the project I wanted to make as close of an adaptation from LFS guidance to Nix that I could. While I did sprinkle in some custom kernel configurations (from BLFS guidance), I otherwise tried to make a direct adaption from the book. The LFS guidance for the kernel build uses `make menuconfig`. That requires user interaction which, as far as I am aware, is not feasible in a Nix derivation (and really wouldn't make sense to achieve reproducibility as far as I understand the term). So I used `make defconfig` within the derivation and attempted to sed the kernel .config to achieve a matching config to that of LFS guidance (coupled with a few sprinkles of custom configs). In retrospect, I don't like how that block currently flows and would like to make it a bit cleaner and easier to declare configuration preferences.

Second, my approach with the entire project was to limit external inputs to the derivations with the goal of trying to be as reproducible as I could. If I recall correctly, the only external inputs used in the whole project were the sources and patches provided by the LFS project. That said, I hadn't considered that it might be a lot simpler to set it up in a "Bring Your Own Config" kind of way. I will stew on that more and would definitely be open to more thoughts on either and/or another approach.

Re: Linux from Scratch

#160

Earlier quoted context omitted.

> The kernel config handling needs a good amount of attention too. https://github.com/cloudripper/NixLFS/blob/64e333f60cca4bec5... Could you speak a bit about why you did it this way instead of maintaining a complete copy of the kernel .config you wanted?

There's a couple reasons for that. First, for my initial attempt at the project I wanted to make as close of an adaptation from LFS guidance to Nix that I could. While I did sprinkle in some custom kernel configurations (from BLFS guidance), I otherwise tried to make a direct adaption from the book. The LFS guidance for the kernel build uses `make menuconfig`. That requires user interaction which, as far as I am awar…

Well, for as critical as I might sound, you did absolutely awesome and the project literally inspires awe in me. I look forward to trying it. It is really, really cool and well done so thank you again.
Post reply on HN