Build yourself a Linux • Hacker News Board

Re: Build yourself a Linux

#11

Post by digi_owl » Thu, May 04, 2017, 8:20 PM UTC

djsumdog wrote: post #8

digi_owl wrote: 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…

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 given name installed at the same time (Debian apparently works around this by including soname-like info in the package names).

Re: Build yourself a Linux

#12

Post by tanderson92 » Thu, May 04, 2017, 8:35 PM UTC

djsumdog wrote: post #8

digi_owl wrote: 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…

Have you tried out Exherbo? In many ways it is an improvement over Gentoo (disclaimer: I used to be a Gentoo developer ~10 years ago, still am an Exherbo dev). It might feel familiar because the package manager, paludis, also works as a package manager for Gentoo.

But the package format has numerous additional features and the distribution does as well.

Re: Build yourself a Linux

#13

Post by tanderson92 » Thu, May 04, 2017, 8:38 PM UTC

digi_owl wrote: post #11

djsumdog wrote: post #8

Earlier quoted context omitted.

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…

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…

Exherbo and Gentoo both solve this problem with something called "slots". Namely, you can install various slots of a package, you can depend on a slot, etc.

In Exherbo you can tell optionally one package to runtime-depend on the slot of another package that you built it with.

Re: Build yourself a Linux

#14

Post by vbezhenar » Thu, May 04, 2017, 8:51 PM UTC

djsumdog wrote: post #8

digi_owl wrote: 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…

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, and they are much more complex than chroot. Logging is complicated. In the past I could try to load and then mount partition from livecd or another OS and read logs, now I don't know how to do it. Init scripts were simple bash scripts. They were verbose, may be buggy, but after all they were just bash scripts and every Linux user knows bash, so every Linux user could write or modify init script. Now systemd uses its own format, I'm spending hours every time I need to write new service or timer for RedHat. SELinux is just so complex. I know about UNIX permissions. They are so simple and elegant. I'm using them everywhere, when I need security. I could explain them in 2 minutes. SELinux has books. I have those books in bookmarks, may be I'll read them sometimes. But until then, I just use copy-pasta from internets to solve my tasks, like allow ssh to listen at non-standard port. I don't think that it's good, that I have to run some random strings on my computer from root without fully understanding what they are doing. SELinux has binary compiled configurations and some encrypted logs for tools to decipher them, what a mess! Sometimes I just disable it to get things done.

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.

Re: Build yourself a Linux

#15

Post by derefr » Thu, May 04, 2017, 8:52 PM UTC

digi_owl wrote: post #11

djsumdog wrote: post #8

Earlier quoted context omitted.

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…

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

Re: Build yourself a Linux

#16

Post by digi_owl » Thu, May 04, 2017, 8:56 PM UTC

vbezhenar wrote: post #14

djsumdog wrote: post #8

Earlier quoted context omitted.

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…

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.

Re: Build yourself a Linux

#17

Post by digi_owl » Thu, May 04, 2017, 9:00 PM UTC

derefr wrote: post #15

digi_owl wrote: post #11

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…

This seems to head into "have your cake and eat it" territory.

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.

Re: Build yourself a Linux

#18

Post by thom_nic » Thu, May 04, 2017, 9:14 PM UTC

A similar process is building a custom kernel and rootfs for an ARM device such as the beaglebone. Olimex actually has a good tutorial for their device: https://www.olimex.com/wiki/AM335x

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.

Re: Build yourself a Linux

#19

Post by thom_nic » Thu, May 04, 2017, 9:14 PM UTC

A similar process is building a custom kernel and rootfs for an ARM device such as the beaglebone. Olimex actually has a good tutorial for their device: https://www.olimex.com/wiki/AM335x

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.

Re: Build yourself a Linux

#20

Post by derefr » Thu, May 04, 2017, 9:18 PM UTC

digi_owl wrote: post #17

derefr wrote: 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…

This seems to head into "have your cake and eat it" territory. 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.

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

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