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?
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.
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 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 found it quite educational and worth the little time I spent on it.
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.
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 worked with college students fairly recently. They did often reach reflexively for video. But when the written material was good enough, they used it.
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.
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.
And I'm always asking myself what is wrong with me that all that completely does not reflect my practical experiences at all.
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 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...
> 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.
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.)
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.
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.
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.
> 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.
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?
So I jumped to what i knew; YouTube tutorials.
https://www.linuxfromscratch.org/lfs/view/stable-systemd/cha...
Every step is explained and every used parameter is documented.
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..
> --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".
> --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.
> 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..
> > --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".
> > --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.
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?
In which cases did/do you need to add individual files?
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.
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.
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.
It is a fun experience though!
Aren't those two opposites?
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.