Hacker Newsnew | past | comments | ask | show | jobs | submitlogin
Linux from Scratch 10.0 (linuxfromscratch.org)
219 points by caution on Sept 2, 2020 | hide | past | favorite | 49 comments



The fact that it, got "promoted/voted" to the front-page(again) is that not in itself proof that is is valuable and still worthwhile to be submitted again ?


You seem to think @dang is in disagreement, but by sharing the relevant previous posts, he's both supporting the new post, and helping reduce the number of kneejerk "but this was already posted" responses.


No, it's definitely not in itself proof of that. If we went with that standard, the front page would be mostly dupes. The few most popular/sensational stories would get upvoted over and over again. And then the threads would mostly be full of complaints about the dupes.

Posts about new releases by well-known projects are something of a grey area, but if you want to read a long explanation of how we treat them, one is here: https://news.ycombinator.com/item?id=23071428.


Thanks @dang. I also read your linked thread. I now better understand your original comment and HN.


This is a great resource for those building embedded systems and want to understand how everything is really put together.

Did this years ago and learned a ton, that said I'd probably never do it again. Once you know, you know. And sometimes you wish you knew less.


I did it about 20 years ago. It was basically copy and paste. Very little explanation of why are we doing this and what are the options. That is my memory of it.


I also did it 20 years ago, but I got a lot more out of it. As each piece went in, I looked at it and what it did, and understood it as part of the whole that was built at the end.

If you don't do it reflectively, and simply copy and paste command lines, then I agree, you're not going to get anything out of it.

As it was, I had to debug a few build issues here and there, with version drift; that too was educational.

The biggest thing to come out of it for me, apart from understanding the Linux boot process better and a greater appreciation for chroot, was getting comfortable with ./configure [options] && make && make install for installing software from source.


Exactly my experience, around 4 years ago


Same experience with Gentoo and Arch.


It's not an in-depth theoretical guide, true, but it is still an awesome introduction and source of muscle-memory.


How would you compare the experience of Gentoo / Arch vs LFS? I used to do a lot of Gentoo back in the day, and nowadays occasionally Arch, and while I believe it lead me to have a very solid foundation of a lot the system, especially the kernel bootstrapping process is a bit of a gray area to me (how do initial ramdisks fit in the picture for example).

Is my understanding correct that these are the things that you definitely have to work through with LFS?


It's lower level than either gentoo or arch. You are literally going through and running the build process for each installed package.

As for bootstrapping, it's been a while since I did it, but that was mostly just setting up grub and pointing it at your newly minted kernel. Grub handles all the "where is this on the disk" issues for you.


Gentoo/Arch build a LFS for you.


>And sometimes you wish you knew less

This is how I felt when learning Go, coming from a background of OOP languages. But it was worth it.


Better not learn Lisp then (do, it's worth it).


Interesting, what about Go made you feel that you wished you knew less and why was it worth it? (I am mostly familiar with OOP languages and not so much with Go)


probably because Go lacks a lot of features for abstraction that more powerful languages have. Once you've worked with generics for instance, its hard to go back to copy-pasting entire code snippets for data structures only to change a few lines here and there.


@reticentraccoon

Parent has answered the first part of your question. As for why Go was worth the trouble, is because of its Utility nature, it has been the perfect replacement for Python as it doesn't have performance limitations(no need to find C extensions) and I'm rolling out production applications faster than ever before with Go.


lmao totally agree. I once took a operating system course on a whim. Built primitives for an mips system. Absolutely loved it but wouldn't do it again :)


Why you need to build OS for a new device from scratch? To quadruple efforts needed?


I never followed this but in ca 1995 I built a Linux boot / rescue floppy disk from scratch. The amount of confidence this gave me with Linux was insane, and I benefit from it to this day.


I have similar experience. I did couple LFS build around 2000 and the understanding of how everything is put together profits to this day.

I would suggest anybody thinking seriously about Linux (if you want to call yourself devops or SRE) to go through a full build at least once.


While it isn’t LFS I’ve been building custom OS distros with bitbake/openembedded for a work project recently. I’d be curious if someone here has done both LFS and used bitbake/OE to see what their thoughts are comparing the two.


I am eager to try this out. As a self-taught developer, I'm in a big turtles-all-the-way-down phase and I feel learning the ins-and-outs of Linux will give me intellectual satisfaction.

I would appreciate some thoughts on whether to go by the systemd route or the non-systemd route. The pros and cons.


I'm not sure what you mean by the ins and outs of Linux. I assume you mean the userspace plumbing rather than the kernel?

In any case, I would only go the systemd route if it is what you want to learn. Otherwise just use runit -- much simpler and probably a bit easier to bootstrap. That leaves you time and energy to spend on other areas.


I would like have some proficient understanding over the architecture of Linux. Both in terms of how the kernel works, and how everything is configured up to userspace.

I'm inclined to go the systemd route because I use it myself regularly, but I also understand that systemd is a bit of a monolithic piece within Linux. I suspected that it might hide a lot of things that used to be more discrete and manual (but more unix-y).


Do non systemd, then do systemd


Is it possible to do the systemd book and then non-systemd?

I did the systemd one a few weeks ago and I think that besides a few small affordances for some systemd quirk, the main issue was installing all the prereqs for building systemd (namely meson, ninja, which openrc probably doesn't require).

They give a nifty tar command to snapshot the disk, which could help create a "fork point" for the setup. `pixz` is very helpful addition in this case (e.g. `tar -cp $LFS | pixz -9 > my_backup.tar.xz`)


If you install to a VM most also have snapshot features you can use.


Thank you. Could you also tell me why you suggest this? I'm genuinely curious.


It's not like you will be up to your neck trying to set up dozens of services in LFS, is it? I mean does the choice really matter?


My concern is in how much systemd does as a management layer in Linux. I feel that it might hide a lot of internal details that were more explicit before systemd.


I put together and maintained a from-scratch embedded distro in the 2006-2010 time frame. I took a hint or two from Linux from Scratch.

I introduced the idea of using quilt for applying all the patches. I've noticed more recently that OpenEmbedded and Yocto do the same thing.


I've often wondered how one can do this. Good resource.


I followed it as a teenager. LFS is excellent at teaching you all the ins and outs of how linux works. As you build your own linux distro, you get a great feel for what goes into standard distros.


LFS and buildroot taught me a lot about how linux is build from scratch. A very valuable learning experience. Thanks to both projects for their work.


They used to have a live CD for this but not anymore. What kinda setup does anybody who does this go for? I been wanting to try LFS for a while.


You just need a linux distro. I did it back in the day with mandrake linux.

Probably easiest to start with ubuntu.

LFS walks through isolation when you are building the system, so it doesn't really matter what you start with.


LFS works best on Unbuntu/Debian I find.

The biggest issue with doing it is the time it takes. Some of the compiling can take ages, and you tend to forget you are waiting for it, and get busy with something else, only to come back 3 days later with no idea what stage you got to!

My advice is to use the fastest machine you have as the host for the LFS build process - it'll take a lot of the pain away.


At this point I'd recommend starting with Manjaro. Nothing compares to the AUR.


You don't need the AUR for LFS.


Well, the ultimate achievement when building an LFS system is to plug it to an existing package manager so you don't have to keep updating stuff manually.


Mandrake ! Now there is a name I haven't heard in a long time :D


RedHat + KDE! :D


I don’t think they intent is to use it for a daily driver OS, but rather to teach/learn how Linux works,Or at least that’s what my mentors have told me


Found a typo: "gccc-10.2.0" is supposed to be "gcc-10.2.0".


ah, the GNU Crazy Compiler Collection


isn’t that GCC :)))




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: