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?
It feels to me like you have approached this with a wrong mindset, like you focused too much on finishing the whole process.
With LFS you must put substantial amount of value into the journey itself. It's not about copy-pasting commands, it's about trying to actually understand what and, more importantly, why your are doing each step. My recollection is that LFS docs were good in helping with that. Or maybe it was coming from reading docs of the actual components as I went along? I don't remember, probably some mix of both.
I did set LFS system up once, I think it was 2001 or 2002. I specifically remember that it took many days (due to compilation times), was very interesting, and at the end I was putting final touches to my mutt and slrn configs. With a vague memory that I had some TODO for mutt that I didn't finish, still lingering in my mind, apparently! :)
All in all, great and satisfying learning experience.
I would not use such system as a daily driver, though. I think it's good only if you have time and want to learn. I'm curious if someone here is brave enough to have different approach.
LFS to a computer scientist should be like soap to a chemist. Something you can do as a fun, educational experiment, but not where you source a necessary tool for your life.
I daily drove it for a few months, back in the early 2000s (like many in this thread, it seems.)
I kept it updated by subscribing to Freshmeat emails for releases, and I'd download and install the tarball.
My review is that I'm glad I did it, it's a terrible idea, and it's debatable (honestly, not facetiously) as to whether the classes I skipped were more valuable.
I built my LFS around 20 years ago. While I followed instructions most of the time, I built some components myself. I remember that I wrote by own init scripts and I think I wrote my own initramfs (not completely sure about it, but I definitely remember tinkering with it and it probably was LFS).
I also wanted to implement an isolated build system and my own package manager (basically tar wrapper with file database to be able to uninstall, no fancy dependency stuff), but containers were not invented back then and my skills were not good enough to properly utilize fakeroot, so it never was implemented, although I spent some time experimenting. Today I would do it with docker, exciting time.
I haven't tried this but I have used https://github.com/MichielDerhaeg/build-linux during my trainings and all my students quite enjoyed the experience. It basically builds a Kernel, libc, busybox, init etc. and gets the whole thing running inside qemu.
I found it quite educational and worth the little time I spent on it.
When I was in highschool I had a bunch of free time outside of school days. I used a YouTube guide to install Arch. I failed many many times. But in doing so I almost kind of learnt what each command was doing.
I had the same experience when I installed Gentoo.
In both cases at first I was copy/pasting commands, but through failure I ended up understanding a lot of what the commands did.
And what someone else said below is true as well, actually try and force yourself to understand what you're typing. Even briefly just scanning a man page helps a lot.
I wonder if the wiki would have been an easier start, than YouTube. YouTube is nice for learning things with a visual component, but installing Linux is all text, all the time. The ability to easily hop around and re-read sections on the wiki where necessary (I mean, jumping around is possible on YouTube of course, but it is really easy on the wiki) seem like it would be a big help.
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 probably that watching YT clips always has a feeling of being part of something. Some movement, some bubble, some society, whatever. They don't install Arch bcs they want to learn sth, or make some use of the OS. They do it _because_ they found it on YT and they want to be part of it. Maybe they even write comments or make a 'reaction' video. Today it's Arch, tomorrow it's a special pizza recipe from that other guy on Insta. It doesn't really matter.
I dunno. I’m a millennial so all sorts of stuff was just ascribed to my generation. As a result, I tend to just assume these differences are overstated.
I worked with college students fairly recently. They did often reach reflexively for video. But when the written material was good enough, they used it.
Us millenials are old. My 43rd birthday is coming up fast.
College students are the next generation. Most millenials remember dialup or at most a time before mainstream streaming video. College students today have seen their formative years being constantly on with instant access to more material in any format they want than they could ever grasp the concept of.
Yeah, I was just abstracting from the experience of having everything I did attributed to my generation, and then applying that experience to the next generation.
They handle some things a little differently and sometimes reach for different defaults, but in the end, it isn’t like they are coming from some totally alien planet or anything like that.
Very often when I discuss it, someone argues along the lines of "yes, it looks different, and maybe even weird at first glance, but everything is indeed fine, and look how access to all that content even makes them more competent than older generations in many ways".
And I'm always asking myself what is wrong with me that all that completely does not reflect my practical experiences at all.
I dunno, hard to say, if our experiences don’t match maybe we’re just in different environments. No particular reason to assume mine is the ground truth of course.
One possible skew could be: often it is professors who complain about this stuff, but the type of person who goes on to be a professor tends to be pretty clever and surround themselves with clever friends. So if you are a professor or a highly skilled programmer or something, keep in mind that you probably have a rosy picture of the average competence of the past.
I'm not clever, no. A few of my friends are, but I never was. I would call myself a skilled software developer, yes. And other, more skilled ones, would maybe disagree. :) But all that says nothing about real life cleverness.
I can clearly see that there are unfortunate patterns, even back then when I was young, and it just got worse and worse. Which is no surprise imho. Of course it propagates. If the parents are already 'social media' addicts, and their friends, and the teachers as well, what shall happen with their children. The issues just 'normalize' - that's what we see, but it doesn't _solve_ them.
The thing is, our societies love to chatter about all kinds of issues and troubles, as long as they are somewhere else or at least the bad guys are far enough away. Something not binding. But as soon as an inconvenient discussion about themselves start, about what they do wrong and what issues we get by them, it turns into silence. So we also do not discuss much about more and more incompetent social media addicts. Since the majority is addicted, and the ground for public discussions is social media only nowadays, who should even start this discussion - and where...
We are probably more or less the same age. And yes, they said it about us as well. And they were right. It's a slow downward trend. And it's still continuing. Do you also see these young mothers on the streets which would just ram you with their baby buggy, because they are deeeeply involved into some toktok swiping ceremony? Addicts. What do we expect from that?
> But when the written material was good enough, they used it.
To some extent, yes, as we all do, they will try to make a good show for you when they feel that there is an audience for that show and it might somehow pay off.
To be fair, though, people have been complaining about the younger generations for hundreds and thousands of years.
I've read accounts of newspapers and common books rotting people's minds (including the "they aren't talking to each other!" concern,) and ancient Greeks complaining about the next generation.
I can't negate any specific point this way, but I do try to think about history repeating itself whenever I see someone notably younger annoying me.
(Also, the complaints that younger generations have about the older generations are just as ancient.)
Yes, another thing that often happens in those discussions: Someone cites Socrates with very similar complaints. To me this is not a contradiction. E.g. maybe the Socrates era has seen it going downhill as we do today, and between there were times with upward movement (maybe forced by some bigger event or development - things are complex). I don't know.
What I know is, when I talk to e.g. colleagues, the younger there are, the more they feel like materialized YT clips. And that's not a good thing. Of course I try to compensate for their younger age when I do the comparison. And of course I could be wrong, e.g. biased in some way. But I would sat that I really try to be fair, and I must be veeeery off if you say there are no such issues.
> 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.
And what you've said about YouTube might be true, but it wasn't for me. I did not go to YouTube for the community aspect, but only because like I said before I didn't even know that the Arch wiki was an install guide as well.
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.
I was 13 and had never touched any OSS software in my entire life give me a break.
> you have not even considered that there might be some kinds of helpful resources directly from Arch outside of YT.
You're speaking about this as if it happened yesterday. This experience happened over a decade ago. I am not a teenager, and I am now accustomed to reading and actually learning on the internet. Don't fault me or my entire attention span for some minor, naïve behaviour/mistake I made as a teenager.
Arch wiki would've almost definitely been a way better start!
But I had _just_ ventured into this space. And at the time the wiki format wasn't something I'd ever seen outside of Wikipedia so i never put 2-2 together to figure out the wiki could be used as an install guide. Plus the walls of text were kind of intimidating?
I would say "explained". As a layman, who worked with linux previously (and even tried LFS a long time ago), but definitely don't have a deep understanding of linux, and eve my knowledge is not up-to-date:
The sed command is not explained at all. Even the description is non-sense if you don't know already what they are talking about. What is this "default directory", why do you need to set it, why there and only there, why that command works? Even the command itself is something, which I need to check the manual what the heck it does, because it's not a simple one.
> -enable-default-pie and --enable-default-ssp
The description is almost unusable. So we don't need it, but it's "cleaner", which in this context means exactly nothing. So what happens if I left out? Nothing? Then why should I care?
> --disable-multilib
Okay, it doesn't support "something". I have no idea what is multilib, or why I should care. Basically the next arguments' description tells me that because it wouldn't work the compilation otherwise. And then..
But why would they fail? I want to understand what's happening here, and I need to blindly trust the manual because they just tell me, that "they won't work, believe us".
> --enable-languages=c,c++
Why are these the only languages which we need? What are the other languages?
So at the end, descriptions are not really helping to understand what's happening, if you don't know already. The last time when I started LFS (about 10 years ago), that was my main problem. That you already need to know almost everything to understand what's really happening, and why, or reading manuals, or trying to find basically unsearchable information (like why libatomic compiling would fail at this step). So after a while, I started the blind copy-pasting, because I didn't have the patience of literary months, and when I realized that this was pointless, I gave up.
Go deeper. You're right on the cusp of it since all of your questions are fantastic. Even digging into one of your questions will bring up highly relevant material for understanding how a Linux system functions.
> The sed command is not explained at all. Even the description is non-sense if you don't know already what they are talking about. What is this "default directory", why do you need to set it, why there and only there, why that command works? Even the command itself is something, which I need to check the manual what the heck it does, because it's not a simple one.
By "default directory" they just mean that the upstream GCC source code has a file with default variables and they are modifying those variables with the sed command to use $prefix/lib and $prefix/usr/lib instead of $prefix/lib64 and $prefix/usr/lib64, e.g. lines that contain "m64=" and replacing "lib64" to be "lib". This is what sed is used for: To make string substitutions based on pattern matching. Think through ways of writing the sed command and testing on your own file to see how it behaves. This will lead you to more tools like diff, grep and awk.
> > -enable-default-pie and --enable-default-ssp
> The description is almost unusable. So we don't need it, but it's "cleaner", which in this context means exactly nothing. So what happens if I left out? Nothing? Then why should I care?
Go back and re-read the sections up to this point. Make note that you're in Chapter 5, which is the bootstrapping phase for the toolchain cross-compilers. Then look into the features that are mentioned. You can see descriptions by running the ./configure --help most times or looking up the GCC documentation. Those features are for security purposes and if you put that in perspective of the bootstrap phase they aren't needed if the only purpose of the temporary GCC binaries is to compile the final GCC in a later phase. To your point, perform an experiment and enable those features to see if there really is a difference other than time spent to compile. GCC incrementally adds security features like this and they are a big thing in hardened distributions.
> > --disable-multilib
> Okay, it doesn't support "something". I have no idea what is multilib, or why I should care. Basically the next arguments' description tells me that because it wouldn't work the compilation otherwise. And then..
A great feature to look up! Check out https://gcc.gnu.org/install/configure.html and search for the option and you'll find that it has to do with supporting a variety of target calling conventions. I can see how that'd be pretty confusing. It has to do with the underlying hardware support for application binary interfaces that GCC can utilize and it turns out you probably only need to support your native hardware (e.g. x86_64). That is, you're compiling your system from scratch and it'll only run on your native hardware (x86_64) but if you were a C/C++ programmer maybe you'd want to have support for other hardware (64-bit ARM systems are pretty common today as an example). So you can save time/space by disabling the defaults and honestly the defaults it includes are just not all that relevant on most systems today.
> > --disable-threads, --disable-libatomic, --disable-libgomp, --disable-libquadmath, --disable-libssp, --disable-libvtv, --disable-libstdcxx
> But why would they fail? I want to understand what's happening here, and I need to blindly trust the manual because they just tell me, that "they won't work, believe us".
Try it and find out. I would expect that they would fail due to reliance on other dependencies that may not have been installed or included in this bootstrapped build. Or maybe be/c those components don't behaved well with the LFS-based bootstrap methodology and ultimately aren't needed to bootstrap. Sure trust the LFSers but also think through a way to test your own assertions of the build process and try it out!
> > --enable-languages=c,c++
> Why are these the only languages which we need? What are the other languages?
GCC supports many language front-ends. See https://gcc.gnu.org/frontends.html. Only C/C++ is needed be/c you're bootstrapping only C and C++ based package sources. You can validate this as you build the remaining sections. It's conceivable that if you needed other languages in the bootstrap you could include them.
> So at the end, descriptions are not really helping to understand what's happening, if you don't know already. The last time when I started LFS (about 10 years ago), that was my main problem. That you already need to know almost everything to understand what's really happening, and why, or reading manuals, or trying to find basically unsearchable information (like why libatomic compiling would fail at this step). So after a while, I started the blind copy-pasting, because I didn't have the patience of literary months, and when I realized that this was pointless, I gave up.
It's a steep learning curve, especially of a bootstrap which by its nature is circular! tbh, that's sort of the utility of LFS, it can take you up to a certain point but there are so many options and pitfalls in building a Linux system (or really any complex piece of software) and the real usefulness is pushing through, picking something and learning about it. Then using what you learned to apply to the unknown. GCC is one of the most important packages too, so there's a lot to unpack in understanding anything about it, but the impact is large.
> Every step is explained and every used parameter is documented.
That’s almost the exact opposite of the truth, and your example demonstrates his point. Almost none of the commands—let alone their parameters—are explained, beyond a high level summary of what the goal of the step is.
Is this phenomenon the explanation for why almost all documentation sucks? Experienced developers delude themselves into imagining that their docs have a level of detail and explanation that they simply just don’t have?
it's better if you try to work out what the commands and options are doing. I did this a long time ago, and 15 years later, I realise that it gave me a big advantage over my colleagues who haven't done something like that. "missing xxxxx.so" - they don't even know what that means, whereas I'm already trying to find the so and putting it in ld_library_path to see if it helps.
In my experience, whenever a .so was missing it was either due to a missing package on the os package manager level, or a completely broken gcc or llvm setup. I never needed to explicitly add single .so files to a path. (Besides the use case where I specifically wanted to override a malloc implementation.)
In which cases did/do you need to add individual files?
In my case, when I was a Slackware user before Slackbuilds was created, sometimes I wanted to try out programs for which there was no package. Usually they required a .so file that was not installed and a workaround was to put it manually from a package of another distribution compiled for the same architecture. When the .so file was there, but on another path, a symbolic link was sufficient. The ldd command was a good friend.
Of course that was not the best and cleanest solution, having things outside the package management system bothered, but it was enough to experiment programs and I kept track of the changes so I could have the prior state of things. Later on, the Slackbuilds project eased the work and I contributed by writing code to automate the creation of a few packages. I learned a lot from these issues.
In my case, I work with proprietary EDA tools. Vendors love messing with LD_LIBRARY_PATH. Chaos ensues when they override a system library or two versions require mutually incompatible versions.
I agree with the comment you are replying to. Having broken my home Linux installs too many times has taught me how to diagnose and fix this sort of issues.
in this case it's an in-house monstrosity that's got a lot of various languages and build systems involved, and the moment you update a compiler or build system, everything jumps into a new location for no good reasons. it was just an example though - same issue with .h not found during compilation, or using a different compiler from the system wide one.
Last time I tried (probably well over 10 years ago) I struggled more with how long stuff took to compile. The main learning I remember from it was the chroot concept, which then later helped me grasp containerization easier
Same for me. I tried it about 20 years ago. I didn't fell like I was learning anything, just copy paste like you say. I haven't retried since, but I think it would be much better if they explain what you are doing and why.
I tried several times, and tried again just recently. I share your sentiment. It perhaps gave me a renewed appreciation of the huge benefits Linux ditributions and package managers give us.
Yes. I got a little bit out of it, certainly, but it really is mostly an exercise of compiling packages. I was a little disappointed but in the end LFS inspired me to take on a rewrite of the Unix Coreutils in Golang. I learned far more about Unix systems from doing this than anything else. It also improved my skills a lot, I look back on some of this code and cringe a little bit.
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.
Nope. It's a launchpad not meant solely to follow blindly. The point is trial and error experimentation along the way. Can I switch the order of these packages or enable dependency X?
It also helps to have a fast x86_64 box with zillions of cores and plenty of RAM and SSD, and also a compiler cache like sccache to speed up rebuilds.
For most people the whole reason to do the exercise is to understand what is involved in a bootstrap process. When you don't understand something you stop and figure out what is going on. There is not much point in blindly running commands that you don't understand.
Nope. I never execute commands without understanding its meaning. Maybe you expect to complete a LFS installation in very little time. Which cannot be the case in general and in this very case in particular
