Live data from Hacker News

Build yourself a Linux

github.com

21–30 of 91 posts

Re: Build yourself a Linux

#21
post #15

Earlier quoted context omitted.

I am of two minds about package managers after having used Gobolinux for some years. 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…

They balk because there's usually only one major version of a package that's still receiving security updates upstream. 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 t…

"They balk because there's usually only one major version of a package that's still receiving security updates upstream."

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.

Re: Build yourself a Linux

#22
post #21
post #15

Earlier quoted context omitted.

They balk because there's usually only one major version of a package that's still receiving security updates upstream. 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 t…

"They balk because there's usually only one major version of a package that's still receiving security updates upstream." 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 tho…

Ah, sure, I'm sort of treating the concept of "package" as being equivalent to "ports-system build formula" here. In pretty much all modern package managers, `pkgmgr install foo` can have any of N prebuilt binary versions of a package like foo-1.0.3 laying around on the package repo server, one of which might be used to satisfy the formula if they match the installation options you passed.

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.

Re: Build yourself a Linux

#23
post #8
post #6

Both this and LFS reminds me that Linux makes sense until you get the DEs involved. At that point shit just sprawls all over the place as there are no longer any notion of layers.

Back in 2002 I ran LFS for a semester and a half. Then I got tired of saving all my ./configure flags and switch to Redhat and gained a respect for package management. :-P Eventually I started using Gentoo. 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…

Gentoo's installation guide is great.

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.

Re: Build yourself a Linux

#24
Following this guide will get you something very close to a base Alpine Linuxwith busybox. Alpine is fairly minimal out of the box and even eschews grub for syslinux.

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.

Re: Build yourself a Linux

#27

Earlier quoted context omitted.

I did exactly the same in 2005. I even wrote my own init scripts, so I really understood a lot what's going on at startup time. Linux was quite simple at that time. I could write my own init, if I wanted. Unfortunately now this knowledge is obsolete. Systemd is a complex beast which uses a lot of arcane techniques, I'm hardly understanding it. chroot was a really simple concept, but nowadays people use containers, an…

What is that legal term again, "Different in degree, not kind"? 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.

Isn't the whole idea to kill Unix?

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...

Re: Build yourself a Linux

#29
post #25

Have you even looked at the LFS project[1]? And what does your guide provide that LFS doesn't? [1] http://www.linuxfromscratch.org/

Actually LFS teaches you about the whole GNU Userland, getting a kernel up and running with busybox is much easier. This project does just that - teaching you the bare minimum.

Re: Build yourself a Linux

#30
This is awesome. I've been building almost the exact same project, along almost the same timeline (based on the commit history). Mostly an excuse to learn more advanced Bash, and Linux Internals/Features I've never had a good excuse to explore. Gonna release next week. Hope I get as warm a reception. Kudos on an awesome project!
Post reply on HN