Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Linux from Scratch

linuxfromscratch.org

Post reply on HN
Print view View original

91–100 of 164 posts

Re: Linux from Scratch

#91

Post by zenoprax »

_ank_it wrote: post #89
hollerith wrote: post #85

Earlier quoted context omitted.

NixOS separates packages. If the package foo contains a file /usr/bin/foo, NixOS installs it in /nix/store/67c25d7ad7b2b64c67c25d7ad7b2b64c-foo/usr/bin/foo. In order to make this separation work, Nix must sometimes rewrite binaries so that all references in the binary to /usr/bin/foo becomes references to /nix/store/67c25d7ad7b2b64c67c25d7ad7b2b64c-foo/usr/bin/foo. The advantage of this approach is that it gives more…

Extremely noob here, I was trying nixos and got real confused about how to install python packages as pip was not allowed at system level.

I'm new as well - it's good to remember that NixOS, nix-shell, and the programming language of Nix are all separate. You can start with your current distro to learn nix-shell first.

I still have no idea how it all works but it seemed prudent for me to at least try.

Re: Linux from Scratch

#92

Post by pino82 »

bee_rider wrote: post #66
pino82 wrote: post #61

Earlier quoted context omitted.

Reading and actually understanding non-trivial text is hard if you are part of a generation that was never challenged to actually learn it. For those people, YouTube (and a few similar shops) are the default way to consume any content. That's what they do all the time. Sure, they somehow know those legacy emojis that you call the latin alphabet. It will just not lead to a deep understanding of text. Another aspect is…

I dunno. I’m a millennial so all sorts of stuff was just ascribed to my generation. As a result, I tend to just assume these differences are overstated. I worked with college students fairly recently. They did often reach reflexively for video. But when the written material was good enough, they used it.

We are probably more or less the same age. And yes, they said it about us as well. And they were right. It's a slow downward trend. And it's still continuing. Do you also see these young mothers on the streets which would just ram you with their baby buggy, because they are deeeeply involved into some toktok swiping ceremony? Addicts. What do we expect from that?

> But when the written material was good enough, they used it.

To some extent, yes, as we all do, they will try to make a good show for you when they feel that there is an audience for that show and it might somehow pay off.

Re: Linux from Scratch

#93

Post by machinestops »

bee_rider wrote: post #39
akdev1l wrote: post #33

Earlier quoted context omitted.

You would start with LFS to build a base and then add your own package manager to make a “true” distro. If you want to just build an existing distro from scratch then they all have ways of doing that as they need to rebuild packages regularly. Eg: It’s a lot simpler to build a fedora image from scratch by using Koji/OSBuild vs LFS as Koji/OSBuild basically automate the whole LFS process. Additionally in order to have…

I wonder if some sort of “BSD from scratch” would be a more fruitful exercise. Since they include more of the overall system, you’d end up with something approximating a regular BSD install pretty well at the end.

A "BSD from scratch" project would end up closer to something along the lines of "Debian from scratch" or "Redhat from scratch". You would be performing an exercise in bootstrapping, and little else.

Re: Linux from Scratch

#94

Post by machinestops »

andrewmcwatters wrote: post #73

I remember trying to automate non-distribution builds of a functional GNU/Linux operating system and trying to not read Linux from Scratch but just official kernel.org documentation.[1] Unfortunately, the state of Linux documentation is so poor, you can't do it. You need to reference a number of third-party articles that kernel.org itself sometimes links you to. I believe kernel.org might also mention Linux from Scra…

> why you need particular dependencies straight out of initramfs.

It came as a shock to me to learn that initramfs is mostly optional. It can be skipped, and you can boot straight into userland.

Re: Linux from Scratch

#95

Post by pino82 »

bee_rider wrote: post #76
chgs wrote: post #68

Earlier quoted context omitted.

Us millenials are old. My 43rd birthday is coming up fast. College students are the next generation. Most millenials remember dialup or at most a time before mainstream streaming video. College students today have seen their formative years being constantly on with instant access to more material in any format they want than they could ever grasp the concept of.

Yeah, I was just abstracting from the experience of having everything I did attributed to my generation, and then applying that experience to the next generation. They handle some things a little differently and sometimes reach for different defaults, but in the end, it isn’t like they are coming from some totally alien planet or anything like that.

Very often when I discuss it, someone argues along the lines of "yes, it looks different, and maybe even weird at first glance, but everything is indeed fine, and look how access to all that content even makes them more competent than older generations in many ways".

And I'm always asking myself what is wrong with me that all that completely does not reflect my practical experiences at all.

Re: Linux from Scratch

#96

Post by hi-v-rocknroll »

cloudripper wrote: post #48

I gave LFS a go earlier this year. I learned a lot through the process - but I definitely went outside the guardrails. I use NixOS as my daily driver and found myself curious of whether I could complete LFS using a "Nix" approach. I was only a basic Nix user at that time and that choice made a difficult process much more difficult. However, the declarative nature of Nix meant that I had clear notes of every step of m…

While Nix/NixOS solved RPM dependency hell and side-by-side multiple concurrent version installation issues, it created its own problems.

The problem with Nix/NixOS is everything is too isolated to be configurable or usable, and so almost everything is broken because it doesn't work like any other OS. Chasing down all of the oddities and gotcha problems becomes a full-time IT job that slows everything else down, and then with a fragile special snowflake of patches and workarounds, it becomes very expensive and slow to do anything or to count on it being reliable. Furthermore, the syntax and nature of the packaging DSL is also too clever special snowflake that could've made do with declarative data or imperative procedural with something widespread like Python, Bourne shell, or JS to reduce the friction of customization and contribution.

Like Qubes, an over-optimization for particular goal(s) ends up becoming Achille's footguns because of a lack of compatibility and usability with everything else that came before.

Re: Linux from Scratch

#97

Post by hi-v-rocknroll »

dvno42 wrote: post #63

Between LFS and Stage 1 and 2 Gentoo installs back in the early 2000s during High School, this gave me a big leg up in my journey of learning about computers and Linux. I can't thank those project maintainers enough for helping me get my footing at such a young age and peaking my interest in computing. I ended up printing out the LFS book in segments on one of the printers in High School and brought it home in pieces…

Yep. Recompile all the things with different USE flags.

Re: Linux from Scratch

#98

Post by hi-v-rocknroll »

sieste wrote: post #3

I really like the idea, really tried following the process several times. But each time it just turned into a copy-incomprehensible-commands-into-the-terminal exercise at some point, and I lost motivation. Did anyone experience the same?

Nope. It's a launchpad not meant solely to follow blindly. The point is trial and error experimentation along the way. Can I switch the order of these packages or enable dependency X?

It also helps to have a fast x86_64 box with zillions of cores and plenty of RAM and SSD, and also a compiler cache like sccache to speed up rebuilds.

Re: Linux from Scratch

#99

Post by hi-v-rocknroll »

I wrote an (unreleased) Bash-based framework for Docker container- and exo-Docker VM-based LFS builds.

Dir listing: https://pastebin.com/JrPkftgr

Dockerfile (it's still missing throwing away intermediate layers b/c it's optimized for caching and dev speed):

    FROM quay.io/centos/centos:stream9

    COPY files/bashrc /root/.bashrc
    COPY files/bash_profile /root/.bash_profile
    
    COPY --chmod=755 files/sysdiff /usr/bin/sysdiff
    
    WORKDIR /mnt/lfs
    
    COPY files/functions.inc files/
    COPY --chmod=755 files/run files/
    
    COPY scripts/0000-install-deps scripts/
    RUN files/run install 0000-install-deps
    
    # Docker host runs a memcache instance to cache build artifacts in RAM
    COPY scripts/0010-install-sccache scripts/
    COPY files/sccache-wrapper.c files/
    RUN files/run install 0010-install-sccache
    
    COPY scripts/1000-setup scripts/
    COPY files/hosts files/passwd files/group files/shells files/inputrc files/fstab.in files/locale.conf.in files/
    RUN files/run install 1000-setup
    
    ...

Re: Linux from Scratch

#100

Post by j0057 »

_ank_it wrote: post #89
hollerith wrote: post #85

Earlier quoted context omitted.

NixOS separates packages. If the package foo contains a file /usr/bin/foo, NixOS installs it in /nix/store/67c25d7ad7b2b64c67c25d7ad7b2b64c-foo/usr/bin/foo. In order to make this separation work, Nix must sometimes rewrite binaries so that all references in the binary to /usr/bin/foo becomes references to /nix/store/67c25d7ad7b2b64c67c25d7ad7b2b64c-foo/usr/bin/foo. The advantage of this approach is that it gives more…

Extremely noob here, I was trying nixos and got real confused about how to install python packages as pip was not allowed at system level.

If other distros allow pip-installing into the system, that could be considered a bug or at least an anti-feature, because it's almost always a bad idea: it can clash with distro-managed Python packages, it will break on Python upgrades, and sooner or later you will run into version conflicts (a.k.a. DLL Hell). Recent versions of pip refuse to install into the system by default, for all of these reasons.

It's better to instead pip-install Python packages into virtual environments, recent Pythons havr `venv` built in for this purpose. For user-scoped or system-scoped utilities, `pipx` can manage dedicated virtual environments and symlink them into the search path.

Post reply on HN