Using ALFS/LFS build as a base for a new distro, a few questions
Well, I guess this is my third post in this forum and this is going to be about LFS like the other 2. Fine, I have experience with Linux (used as my main desktop OS from 2011 to 2020 before I get a mac) and then recently, I got back to Linux somehow.
It's a long story which is irrelevant here, but I had to configure and create some systems based on Raspberry Pi and Orange Pi single board computers and you guessed it, You need Linux for those babies. I personally love to work with Linux machines, so I decided to do something myself. I made LFS and ALFS systems before (if you look at my profile you'll realize I asked a question about ALFS in 2019) and it was an enjoyable procedure. However, I still have some big questions, since I have done a lot of stuff just for fun and learning and not as a very serious project.
And I have to say that I asked pretty much the same thing on reddit as well and I didn't get the answer I needed. I hope I get here! Thanks! |
IME, LFS is not as well supported as it once was. The LFS book is up to date, but many other projects have lapsed. But it's one huge bash script that needs constant tweaking. ALFS I don't know the state of. For Macs, Asahi Linux is aimed at M1-M3 machines, and is the only distro I know of with Mac graphic drivers. I'm no great authority, I should add.
For SBCs like RazPi & Orange Pi: to get running you need
Debian are paid (I imagine) to package an Arm distro for each SBC with the relevant boot setup. It can be downloaded as a binary image, and transferred to sdcard or usb drive with dd or their windows imager. Look on the manufacturer's site (e.g. raspberrypi.com). Slackware has Slackware Arm & slarm64, official & unofficial Arm ports respectively. I use Slarm64 on my RazPi 4, because the raspberrypi software sucks, & I prefer it to the 'official' port. Slackware Arm is too like the x86_64 original, and Aarch64 ≠ x86_64. |
Well, my Mac is Intel based and I already managed to have major/famous distributions on that (since you've mentioned Asahi here, I just wanted to point it out) and my question was basically about the whole LFS ecosystem. By the way thanks for the useful information you've provided to me, it shines light on my path obviously.
This is more of a personal opinion than a fact. I guess LFS approach for SBCs isn't really a good one since most of them may have an industrial (or at least semi-industrial) application. In my case with those, I used them for a lot of automation and stuff and I used Debian for them. Recently, one of my Raspberry Pi boards (which is somehow a make-shift PC for me) runs Arch Linux, and that's cool for a very minimal desktop computer in my honest opinion. So, I believe I can still take the LFS approach for x86_64 and get results out of that. What do you think? |
Quote:
|
LFS runs fine on SBO's.
From RPi1->RPi4, also a couple of RockPi SBO's. All run fine with wirless and graphics ( when needed, I usually run them headless ). Used for media servers, including books, comics. music, films etc. Also used to use an RPi as an appache server. |
Quote:
Quote:
|
I'm not sure I've understood the question, but anyways... I've made my own distro, based on LFS, and kept it updated for 11 years. I don't use ALFS, I've made my own scripts which just automate the build process, following the book. I install a package manager, pacman and it's dependencies, in the tool chain. And in the chroot I create packages and install in the chroot. And I continue building everything in the chroot. When I update I do fullsystem backup to a different partition and just update with the new packages. If it doesn't work I can just reboot back to the old system. I look a lot at Arch and their PKBUILDs, but most often I follow (B)LFS. When I update different packages I usually compile them in a chroot. Especially the core packages, so I can test them in the chroot before installing them on the running system. So I guess one can say that my distro is some kind of hybrid between source based and binary distro.
|
Quote:
One question, can I know the name of your distribution? |
Quote:
|
Quote:
|
Quote:
Quote:
|
You're not the only variation on LFS. http://kevux.org is another. The guy is fed up with glibc, and was using µClibc when I built it 20 years ago. No locales in ÚClibc. I haven't tried it.
As the Arm guys also showed (or found out) there's a big difference between a bunch of gnu programs compiled, and an OS. Design decisions have to be made. Most put 64bit libraries in /lib & /usr/lib, and 32bit ones in /lib/32 or /usr/lib/32 or the like. Slackware uses /lib(=32bit) & /lib64(guess!), which imho is superior. But much time is lost with things like udev, or maybe eudev, dbus, init systems, packaging, dependency tracking. In the case of LFS, I disagree with several of their choices. But in varying it, you're 'cruising for a bruising' unless you're smart. and 11 years down the road, I guess you know what you're doing. I would call your distro a fork of LFS. lfs-hag?:D |
if you’re feeling adventurous check out sourcemage. i’ve converted jhalfs scripts into a sourcemage grimoire and used sorcery to build the packages. then convert the packages to slackware using makepkg and use slackware pkgtools as your package manager
|
also i would highly suggest not building blfs by hand, or even building lfs by hand more than a couple times. learn how to use jhalfs.
|
All times are GMT -5. The time now is 08:31 PM. |