4 ms·

I've not done LFS, but have worked a bit with Linux on arm devices, and I would avoid choosing an arm device for this purpose because the state of upstream kern

I've not done LFS, but have worked a bit with Linux on arm devices, and I would avoid choosing an arm device for this purpose because the state of upstream kernel support for many devices that arm manufacturers use is, well, shit. You'll almost certainly have to use some old, unmaintained manufacturer kernel to get all of the devices working (e.g. graphics). Edit: It actually doesn't seem that bad for some(?) rpi devices: https://elinux.org/RPi_Upstreaming https://elinux.org/RPi_Upstreaming Not sure if that list includes all devices found on even the newer ones too.

giancarlostoro 8y ago
I'm fine with older kernels / older devices. My goal is to see how it all comes together and learn more about the internals. I like SBC's because they're usually cheap and can be replaced quickly and easily enough.
- craftyguy 8y ago
  Older devices is fine, but you can start to run into trouble with older kernels. For example, newer glibc versions are notorious for requiring newer kernels [0]. So then you're stuck with an old glibc for your kernel. Not all applications (especially newer ones) will successfully link against that, so then you're looking for replacements or older versions that do (if there are any). What about other libc implementations, like musl? There are differences between musl and glibc[1] that will drive you nuts trying to find things that will link in musl that were originally written to link against glibc. 0. https://mirrors.edge.kernel.org/pub/software/libs/glibc/hjl/compat/ https://mirrors.edge.kernel.org/pub/software/libs/glibc/hjl/... 1. https://wiki.musl-libc.org/functional-differences-from-glibc.html https://wiki.musl-libc.org/functional-differences-from-glibc...
Jaruzel 8y ago
My problems with LFS are: 1. The documentation is always in flux. You may get lucky and it's accurate, or you may not, and spend hours looking for tarballs that no longer exist online, or worse find them and they are no longer compatible with LFS - They don't host the required source archives along with the LFS book, and a lot of links to parts you need end up going nowhere. 2. As a step-by-step it does do what it says on the tin, but as a learning tool, there's a lot missing. When I was less knowledgeable about Linux I found myself following the LFS book with little to no idea about what I was actually doing and why. It would say things like 'chroot in the build folder' without actually explaining why, and what chroot actually did. 3. The whole thing can fail at any point, leaving you with a broken build, that more often than not, you'd have to wipe and start over. As most of the steps involve compiling, that's a lot of lost hours.

giancarlostoro 8y ago

I'm fine with older kernels / older devices. My goal is to see how it all comes together and learn more about the internals. I like SBC's because they're usually cheap and can be replaced quickly and easily enough.

craftyguy 8y ago
Older devices is fine, but you can start to run into trouble with older kernels. For example, newer glibc versions are notorious for requiring newer kernels [0]. So then you're stuck with an old glibc for your kernel. Not all applications (especially newer ones) will successfully link against that, so then you're looking for replacements or older versions that do (if there are any). What about other libc implementations, like musl? There are differences between musl and glibc[1] that will drive you nuts trying to find things that will link in musl that were originally written to link against glibc. 0. https://mirrors.edge.kernel.org/pub/software/libs/glibc/hjl/compat/ https://mirrors.edge.kernel.org/pub/software/libs/glibc/hjl/... 1. https://wiki.musl-libc.org/functional-differences-from-glibc.html https://wiki.musl-libc.org/functional-differences-from-glibc...

Jaruzel 8y ago

My problems with LFS are: 1. The documentation is always in flux. You may get lucky and it's accurate, or you may not, and spend hours looking for tarballs that no longer exist online, or worse find them and they are no longer compatible with LFS - They don't host the required source archives along with the LFS book, and a lot of links to parts you need end up going nowhere. 2. As a step-by-step it does do what it says on the tin, but as a learning tool, there's a lot missing. When I was less knowledgeable about Linux I found myself following the LFS book with little to no idea about what I was actually doing and why. It would say things like 'chroot in the build folder' without actually explaining why, and what chroot actually did. 3. The whole thing can fail at any point, leaving you with a broken build, that more often than not, you'd have to wipe and start over. As most of the steps involve compiling, that's a lot of lost hours.