Having been a long time user of LFS as my main desktop, I have decided to throw in the tail and use a prebuilt distro ( Void, more on that later ).
I have always had a great deal of respect for the LFS devs, but it seem s LFS is rapidly going down hill, Version 10.1 was the last ( in my opinion ) well made version, every thing "Just worked".
I tried version 11.x and found with a bit of tweaking it was a reasonable system.

Version 12.0 was a nightmare and needed constant hacks and fiddling to get working, when the system was finally up and running I found all sorts of problems, with anything using the various web view packages, the gtk webkit I just couldn't get compiled, falkon had problems with websites, mostly dynamic content, videos etc, I gave up trying to build chromium and opted for a repacked chrome deb file, but still with visual problems.

I noticed that the devs had got lazy like many other distro devs and symlinked /bin and /lib to /usr/* I don't know at which version this was introduced but it's awful, one of the great things about Linux I found after starting to use it was the separation of user binary's and lib's etc, unlike windows and macos ( at the time ) that just dumped everything into a few folders, making debugging an errant install way more difficult than it need to be, and also compounding the problems of screwing up a folder, ( we ALL do it! ).

The Devs also elected to install packages via pip rather than using setuptools, even arch doesn't do this! It's just plain lazy, I also noticed creep in the basic system, installing a pip packager into the basic system is just wrong, put it in BLFS if you want but it doesn't belong in the main system, I found a number of other packages that needed patches from arch/slackware to build/function, but I did get it built and running and worked around the various problems, but it was a far from stable system.

Version 12.1 What a piece of crud! I think I first installed LFS at about version 6/7.x and have never had as many problems with the basic system, I managed to get it built/installed with no errors except passwd hung, so I figured I would sort that later so just copied my /etc/passwd files, and hey it booted, but no modules would load, so back t a fresh build, after 4 or five tries I have finally given up, the system builds but wont function, never did find out why passwd hung on confirm password, couldn't get modules to load, spent two weeks on this, still no go, so goodbye LFS, I learnt a lot but I pity anyone building a new version, they just wont learn much, and will end up frustrated.

So now a prebuilt system, first of course I tried going back to Slackware but unfortunately slack seems to be lagging a long way behind the rest of the Linux ecosystem, nice to see they haven't given in to that systemd crud, but too much of slack is too old, so I tried Void, to start it uses runnit as the init system, and some of you may remember a few of us here got runnit working well on LFS, ignored by the LFS devs of course, "Not invented here!" syndrome strikes again.

Void has a number of install options and a really nice bootstrap from a chroot, which is the method I opted for, and it went without a hitch, Void is not a "hold your hand" system like debian etc, so needs some knowledge, but it's package manager is fast and easy to use, I had forgotten how nice a binary package manager could be, it also doesn't drag in huge numbers of deps like some others, I have been using Void for about two weeks now and it's fast and stable, I would definitely recommend it.

sorry to hear about your issues. i had no trouble building and running 12.1 including all four desktop environments

I didn't realise there was a new one out. I just checked my existing LFS and it seems, from the packages in /sources, to be version 11. I'll try to build the current one and see how far I get.

Some of the creep wasn't their fault. A lot of packages build with meson/ninja nowadays so you need to have python as a basic tool, though it feels wrong. But I really didn't like the switch in the structure of the build. The old sequence with all the tools in /tools was much more logical.

@Keith: if Slackware is too old for you, why not try Slackware-current? During the long reign of Slackware 14.2, a lot of people switched to current out of frustration. It was never intended to be a rolling release distro but it became one in effect and I have noticed that a lot of people here use it.

1 members found this post helpful.

I agree about the /tools folder its was WAY better than this sort of half and half method they are using now.


I didn't try slack current, didn't think of it just version 15.x I think, I may give current a a whirl, but at the moment I am enjoying Void, which seems to be getting updated quite frequently.

Glad yours built OK, could be my hardware is getting past it, but being on a fixed income I can't afford a new machine.

Even Devuan is going to be afflicted with the (IMO harmful) changes to the file system hierarchy.

If you are willing to consider a major pivot, then either OpenBSD or FreeBSD might be options.

OpenBSD is quite light weight, at least in the base system. It's quite clean and well-organized on all levels. One of the very nice things about OpenBSD is that it does almost nothing that you yourself did not tell it to do. It has the best written documentation by far of any project I have encountered so far. That takes getting used to. As for packages, you can add heavier packages as your hardware permits, such as one of the painful, graphical browsers needed seemingly everywhere these days.

FreeBSD is much more complicated but doable too. It has an extensive handbook but unfortunately the handbook is needed. However, there are several FreeBSD-based desktop systems like MidnightBSD and GhostBSD which do much of the setup for you.

The mess in Linux is not because of technical decisions but from outside politics making its way deep into the general work flow, combined with loss of control of key institutions like the Linux Foundation and the Open Source Initiative.

wait until they start “fixing” this xz thing

Moin,

Sorry to hear about your issues and the resulting decision. Here i had more luck: Looks like i was able to build B/LFS-12.1 without any of the issues you experienced on a pretty old machine. (see: https://www.linuxquestions.org/quest...pu-4175735078/ )
(In my case i have the issue, that xorg won't start, but i think it's my fault and i had to postpone this, because i need the space the Dell occupied on my workbench for something different).

I'm also not happy with all of the changes which happened during the times since i'm working with LFS (i think my first LFS was 3.3). But i doubt, that there's much the LFS-developers could do about it.
What i see with worries during the time:

* way more dependencies for almost every package, especially the circular dependencies in BLFS are growing in a worrying way.

* The "Python-cancer" sneaks further in. At the same time, for me it looks the Python fans don't really work on elder packages to make them work with newer Python versions. So, now in BLFS-12.1 you need to have 3 different versions of Python installed: One for building Mozilla-Software, one up-to-date-Version and still a Python-2 for some old packages...

* Theres an unhealty grow in the number of build-Systems (cmake, meson, ninja, wheel, cargo, ...) and crap needed to generate documentation (I think, thats because nobody likes to write documentation, so all try to write software to do it...). But again: this is nothing, which could be changed by the LFS-developers.

* I'm also not a big fan of systemd which also sneaks deep into everything, so you will need parts of it also, when building LFS with sysvinit.

I hope that the current xz-issue wakes up some people, but i think it's just a small bacon of hope (as our foreign minister would express ;-)

cheers,
WK

Amen to that! I tried last time around to avoid building that cumbersome documentation system but had to give in in the end.
Yes, I was puzzled to see that systemd is required. At first I thought that they must have combined the two LFS variants into one book, but then I noticed a separate systemd volume as before. Just what is going on here?

Personaly I try to avoid cargo and wheel like the plague, in fact neither are on my my system now ( Void ).
I think the devs sould have tried harder to keep to the FHS after all most build systems allow you to specify where binary's/libs are installed and whre they don't they can be manually moved ( LFS does this in a number of places ), it seem's to me that the devs apear to only want to use certain packages like pip and python, as I said in my OP I used to have a great deal of respect for the hard work that the (B)LFS devs put in but they seem to be frittering that respect away.

Don't even get me started on systemd

More and more I also found errors in the docs for various packages so started to not build them where possible and went to using inline documentation.

Info: According to the Book, the systemd download is for extracting udev. I called up the developers' mailing list to find out why they can't continue to use Gentoo's eudev as they have done for years and it turns out that it's too old and incompatible with some of the other software.

You can fight systemd but you can't win.

Thanks for posting this. Definitely gonna take a closer look at Void. It would be great if the LFS crew switched to runit and consolidated both books but I don't expect that to happen anytime soon. My main issues with current LFS:

- The way the books are now rendered with each page having a static title bar at the top with the content in a 'frame' below (not sure of the terminology here) - it results in much less vertical viewing area.

- Using systemd tarball to build udev. You could still use current eudev with the boot scripts from the 11.3 book (i think only a sed is required with eudev) but would like to stick with the current book for something as important as the boot scripts. It caused me to switch to systemd on my last build (12.1).

- I would like to see PAM moved from BLFS to the main LFS book.

I do like current method of installing python modules. I use porg to trace the installation so i know what files are installed. To upgrade a module i first remove it with 'porg -r <mod>' (that also removes it from the PIP 'database'). Then i just install the new module as usual.

For a distro that is supposed t be built from source using pip sort of defeats the object of the exercise, also the python setup tools do the job perfectly well and they integrate well into a package manager, arch uses setup tools instead of pip.

For me, the use of rust already did that. That was when I stopped building apps like firefox and the gimp so that I could actually use LFS as a working distro. This time around, I probably won't even build X; I'll just build LFS itself to make sure I still can.

I agree about rust, but what do you use instead of GIMP? Some things can be done with Imagemagick, but I do quite a bit of graphics work so would be interested in somthing to replace GIMP.