Build yourself a Linux
github.com
github.com
Still, I've finally gotten to a somewhat practical self-hosting system. My laptop runs it on the metal and all of the infrastructure (website, bugzilla, git hosting, mirrors) is on a server running my distro too. It's taken almost a year of frustration, but it's very rewarding.
I see the educational purpose. Although you probably get similar experience/understanding/education if you use something like Gentoo and you would have to invest much less time because all the nasty corner cases are already taken care of.
I'm writing up a blog post on it now, I realize I haven't done that yet.
I'm certain (because I learned with Slackware before there was Gentoo) that those nasty corner cases are actually where the rewarding part is. The progression of distros for me was, ZipSlack (fit on a 100MB Zip Disk), Red Hat, Mandrake, then back to Slackware once I actually had a real decent internet connection, and I can say for sure that dealing with those naturally occurring corner cases was a lot more fun than dealing with those "it's packaged, but for a different version of RedHat, so it won't work on your Mandrake install"
Eventually I switched to Debian and was able to just stop caring about that stuff for the most part until something was too fresh to find a package.
(I'd run Unstable, and everything was either packaged already or the vast majority of the dependencies were already packaged.)
I don't know if there was any tangible reward from learning to build Enlightenment, and a full stack of graphical libraries underneath, but at least I did get Enlightenment from it. (!!)
It's not the goal, it's not the OS. But the documentation is a sight to behold! Very clear, detailed, interesting writing style, and it puts together quite a few frustrating topics in a simple, structured matter. Wow and kudos! Keep on writing docs, please!
Still, I'm really glad I built and ran an LFS for nearly a year. It helped me build a really in-dept knowledge of Linux that's helped me as I later moved into embedded development.
Today I still use Gentoo (which feels like LFS with package management) and Void and would recommend either for Linux devs.
Don't get me wrong. I think that Linux looks more professional, more robust, especially for system administrators, who can devote their lives to learn about those systems. But for hobbyists, who doesn't have a lot of time, Linux became much less transparent.
May be if I didn't have that prior knowledge, it would be easier to learn those things from scratch. But I doubt it.
Systemd is a religious argument at this point, but if you want simplicity check out Void. It uses runit and I love it. It's incredibly simple. Startup files are often less than 4 lines. I don't really like systemd either, but I will admit, as a package maintainer, it does make packaging a lot easier/universal. It'd be nice if there were drop in replacements for systemd that uses the target files for services and trashed everything else. UselessD was a cool project that attempted it, but it became to difficult to maintain. :(
I currently work at a docker shop and I will say, containers are pretty nice. They're better isolated chroots with a lot of cool versioning support. There are pluses and minuses, but overall, I think docker is a nice evolution from chroots. Now all the eco-systems around docker: kubernets, DC/OS/marathon, nomad .. all totally different, proprietary and over-complicated.
The more i find out about systemd and surrounding projects, the more i feel they should stop branding anything using it as Linux.
It seems to be heading into Android territory, where it may have the kernel in common with classic (GNU?) Linux, but beyond that it is a whole new beast.
Use funding to keep keep the 'cool things' purposefully incompatible, GPL'ed, and controlled via influence by well-staffed and funded corporate sponsors..
This keeps the IT people from getting too powerful w/r/t the managers...
20 years ago, there was the same scream about Redhat going to destroy Linux when switching from bsdinit to SysV init, or from libc5 to glibc2.
Here we are today. Redhat is going to destroy Linux again. This time by switching from SysV init (or whatever).
https://plus.google.com/+LennartPoetteringTheOneAndOnly/post...
Because once i got familiar with Gobolinux and how it handles things, i can't shake the feel that most package managers introduce as many problems as they solve.
The biggest is that while _nix have sonames to handle multiple lib versions installed at the same time, most package managers balk at there being more than one package of a given name installed at the same time (Debian apparently works around this by including soname-like info in the package names).
Thus, a package being able to depend on an old version of another package, is basically morally equivalent to depending on an unmaintained package. Which, if the packge author is gonna do that, they might as well just vendor the dependency.
The "version numbers in package names" thing is basically to indicate exceptions to this: cases where there are secondary living packages, with either upstream-tracking or distro-backported security updates.
Ideally, there'd be a way to do the same thing just using pure semver heuristics—but any major-version release-stream can just peter out at any time and dependent packages will be none the wiser. So you sort of need your package manager's notion of a package's major-version release streams to be something equivalent to their own "packages" anyway, so that you can have somewhere to put package-alike metadata, e.g. "depending on this is deprecated", when the release-stream for said version gets EOLed upstream.
If upstream wants people to stick with the latest and "greatest" then they need to stop breaking APIs and ABIs at the drop of a hat.
We do not live in a world where computers encased in concrete at the bottom of the ocean is a sane option for doing computing.
"Upstream" usually doesn't care about that. Upstreams—developers who write things that get packaged—almost always have a philosophy of "eh, just vendor it." Which is where things like Docker images come from.
Instead, it's the distros that care about being able to update a package's deps out from under it; because this lets them have one copy of e.g. OpenSSL on the system and fix everything that depends on that package, whenever there's a new vuln discovered in it, by just updating that package. They're the ones trying to eat a cake and have it—even as the upstream devs take the view that you should just eat their ingredients directly and never bother baking a cake in the first place. :)
---
As a tangent: I'm almost beginning to agree with the Golang philosophy: a "package" is its ABI. New ABI = new package with a separate identifier, that everyone has to explicitly update to.
Doing this has two incentive-system effects:
1. It makes package-authors much more reluctant to make breaking changes to their ABIs, which in turn encourages them to think through their ABI before their initial release;
2. The semantics of a semver major version are transferred entirely to the package identifier itself. Almost nobody uses semver major-versions correctly; but if you collapse those semantics up a level, the package-manager can enforce the semantics. So you, as a downstream consumer, can actually be sure there are no breaking ABI changes as long as you're tracking the same package identifier.
This is not entirely true, because this one version usually can be configured to produce a lot of slightly different versions of that one version. For example, even simply swapping glibc with musl gets you two different versions of the same version of every package. There are a lot more issues though, nix's paper explains some.
Package management is a huge mess at this point, docker even managed to capitalize on that.
The non-BSD-inspired distros, rather than having a separate concept of build artifacts, tend to put the options to match in the "build" part of a package's version string—making them technically separate releases. But it does the same thing in the end.
But that's a separate thing from a distro keeping multiple forks of the package itself, with separate release cadences—which mostly only happens as a way to keep individual efforts to create releases from upstream major-versions, or backport to dead upstream major-versions, distinct from one-another.
Most package managers are some form of automatic transmission. Some provide paddle shifting, some are CVT, some have two clutches and 9 gears, and some just basic four speed boxes of swirling fluid. Almost all of them are a nightmare for a regular person to maintain.
That's part of why I use Slackware, which uses Pkgtool. It doesn't track dependencies. It doesn't resolve conflicts. It doesn't roll back changes. It doesn't do much of anything. And it's absolutely wonderful. The only time it ever gets in your way is if you intentionally break it. Of course, i'm on the extreme end of a "power user", but the damn thing is so simple that even a total newbie can grok how it works and the potential for catastrophe if they misuse it (like a manual in a car).
Of the ~8 package managers I've used, RPM is the closest to a simple, coherent, complete system. It's still not great, though.
In Exherbo you can tell optionally one package to runtime-depend on the slot of another package that you built it with.
ABI breakages are far less painful than on gentoo.
But the package format has numerous additional features and the distribution does as well.
https://wiki.gentoo.org/wiki/Handbook:AMD64/Full/Installatio...
I don't use Gentoo anymore, it's been 8+ years, but I learned a lot from that distribution.
I remember at the time writing a series of very intricate build scripts to download and update the kernel on my desktop with every single release, specifically with the ac-sources patches that Alan Cox was maintaining at the time. Probably one of the first non-trivial programming projects I did.
Thus you can switch out what makes up the various layers as you see fit.
The very goal of a desktop environment is to create an entire environment, rather than using the one that is already there.
Desktop environments like GNOME and MADE have so many worthless parts that are tightly coupled dependencies, they end up becoming the same bloated mess that Windows and OS X are.
If a desktop environment focused on creating separate packages that played well with the underlying system, they would not have this problem.
This is only slightly more complicated due to the need to cross-build but I found it fairly easy with qemu-static-arm and prebuilt cross toolchain packages for Ubuntu/ Debian.
The benefit is that you can develop for a target device that is not your PC, so no worry about messing up the bootloader and leaving your PC in a state where you need a recovery CD to fix it and boot. Just get a USB-serial cable :)
You can also try buildroot or yocto, although I had no interest in building every package manually versus relying on Debian's repos.
I guess you're right, they change only every few years :)
(Also: QuickBASIC 4.5 forever! Assuming that's the meaning of your nick).
Is there a distro builder for dummies?
You can pick packages and build a distro from browser.
NixOS - You can make one config file to specify how your system should look like. It's easy to make GUI for it.
Oh, and NixOps is awesome for managing multiple machines. And it can automagically set up VMs corresponding to your production network.
SUSE Studio has a nice GUI and is easy to get started with, but AFAIK it doesn't have a nice story for configuration management, or managing the systems after they've been deployed.
But if you want it quick install debian or arch or whatever and simply start only X11 and whatever application you want to run. If there is no window manager or an extremely limited mode, you got kiosk mode.
The upside with Alpine is if you need features and packages they are an install away. But if the purpose is to learn about compiling the kernel and how the system initalizes this is a decent start.