I usually think about building LFS. Not only for learning purposes, I'd like to have something usable, lightweight, tightly controlled and with core packages coming directly from source without needing central repositories like other distros, even rolling-release ones like Arch or Gentoo.

The only distro I could find similar to this was one called sourcemage. But it seems abandoned and unmaintained.

I then started considering building LFS and installing guix and flatpak. Guix and flatpak are centralized, but they're, AFAIK, distro agnostic. This seems very interesting, it would allow me to have a "small" set of core packages built directly from source and recent versions of all the other software installed and updated from guix and flatpak, which are distro agnostic.

One problem still remains: how to easily update the core packages? Anyone has experience using LFS continually and as something more than a learning exercise? I'd be curious to know how easy it is to automatically detect new releases and update LFS core packages. Having LFS to automatically detect new releases of and update its core packages would be the ultimate rolling release distro.

I would recommend using crux, arch, void, alpine, or any other system with a shell-based packaging system for LFS. Select the packages you require, modify or create the package files as necessary, compile and install. You will get a usable and maintainable system, learn just as much, and have less headaches in the long run.

You can easily track core packages using rss or git and some scripts, but maintaining a small set by hand isn't really that hard, and it gives you a sense of perspective on what actually needs to be upgraded constantly.

I’ve built LFS 5. It took about a weekend but I learned a TON about linux in the process.

Back in those days we had to compile kernels if we wanted anything more than the distro provided (depends on distro).

I started with slackware and had to compile in support for cdrom.

Good times.

> Back in those days we had to compile kernels if we wanted anything more than the distro provided (depends on distro). > I started with slackware and had to compile in support for cdrom. > Good times.

Damn, are we that old? :c I remember someone helping me install Gentoo through SSH when I was 14 or something. It took a weekend to compile OpenOffice.

You may want to look into Tinycore Linux. Lot of what you describe.

Congrats on another release! It's great to see basic, well core, tools like this get the attention they deserve. Changes to improve performance by crafting code specifically for hardware where appropriate is especially nice IMHO.

Meta, but why is this on Ask HN?

Because no URL was provided and the title doesn't start with "Show HN:"

That seems like a strange way to do it. I've seen and posted actually relevant content beginning with "Ask HN:" that never saw the light of /ask.

Gotta rustle up code-reviews somehow!

But more importantly... how? I thought Ask HN was just a collection of submissions containing "Ask HN" in the title and having a certain threshold score.

https://github.com/coreutils/coreutils/blob/v9.0/src/stat.c#...

        case S_MAGIC_VXFS: /* 0xA501FCF5 remote */
          /* Veritas File System can run in single instance or clustered mode,
             so mark as remote to cater for the latter case.  */
          return "vxfs";

From comments earlier in the file about aufs, it seems like the question is whether the filesystem could possibly be remote, because it controls whether tools rely on inotify or do polling - not whether it's definitely remote.

Clutered mode is supported on HP-UX. When did you check?

except almost no one uses hp-ux.

if you're using vxfs as a filesystm, you're probably running vcs on linux.

So coreutils rejects cp/mv features because it's "feature complete", but when a committer finds an idea for new features, it's accepted. Double standards

Nothing in the list above seems to be a feature adding or changing end-user-visible behavior, they are performance optimizations. They make cp/mv work the same way but faster.

I think we'll need more context here. What's the background story?