From 9e0a31d9a594181fb55315a5cfa34dc89ab4f5d5 Mon Sep 17 00:00:00 2001 From: YellowJacketLinux Date: Mon, 7 Oct 2024 20:55:20 -0700 Subject: [PATCH] Mumbling about stuff --- THE-PLAN.md | 254 ++++++++++++++++++++++++++++++++++++++++++++++++++++ THE_WHY.md | 104 +++++++++++++++++++++ 2 files changed, 358 insertions(+) create mode 100644 THE-PLAN.md create mode 100644 THE_WHY.md diff --git a/THE-PLAN.md b/THE-PLAN.md new file mode 100644 index 0000000..04ad3b3 --- /dev/null +++ b/THE-PLAN.md @@ -0,0 +1,254 @@ +The Plan +======== + +This is an attempt to create a new GNU/Linux distribution. The why I will +document elsewhere. + +The new distribution will be called ‘Yellow-Jacket GNU/Linux’ (abbreviated as +‘YJL’) and will be heavily based upon ‘Linux From Scratch’ (LFS) but will have +many influences from my years with Red Hat Linux, including use of RPM as the +package manager. + +I first started this in early 2023 however my efforts were cut short by a busted +water pipe in the ceiling over my bedroom, which also is my office. Extensive +water damage resulted. + +After that, there were some medical issues with family members that took a lot +of my time and *still* take a lot of my time, but I am back on track. + +Initially, YJL was going to use SystemV Init and the LFS I built in early 2023 +is a SystemV Init system. However I am now convinced that SystemD is the better +way to go even though I really like the simplicity of SystemV Init. + + +Phase One: LFS Bootstrap +------------------------ + +This phase is what this git repository is about. Create the needed shell scripts +to build the current SystemD LFS (12.2 as I type) on a USB thumb drive that can +then boot an 'x86_64' system and rebuild itself to the hard drive of that +system. It does not need to be able to make a network connection, the needed +source tarballs and patches and scripts will be preserved in '/home/lfs' on the +bootable USB thumb drive. + +I am hoping a 128 GB thumb drive will be enough. + +My build host is the LFS 11.3 system I build in 2023 (fortunately my PC did +survive the water damage). As of today (2024-11-07) I have LFS 12.2 properly +building through Chapter 8 with my minor modifications (e.g. LibreSSL) but +the build scripts do need some work still and stripping binaries etc. still +needs to be scripted. + +I am using '/mnt/newlfs' as the install path rather than '/mnt/lfs' because I +do not want someone playing with these scripts to accidentally nuke their own +LFS system. + +If someone stumbles upon this repository, do not use it to learn about LFS. +Do the LFS project from the LFS book. These scripts are for my automation of +my way of doing things which are not necessarily the best way build an LFS +system to learn about GNU/Linux. + + +Phase Two: GCC Bootstrap +------------------------ + +The GCC built by LFS does not support building the Ada or D compilers. Both of +those compilers are useful on a GNU/Linux system. + +Once I have a hard-disk install booting, the very first order of business is to +rebuild GCC for full compiler support. + +To compile GCC with Ada and D support, a working Ada and D compiler is needed. + +My LFS 11.3 system has those. What I did back then, on CentOS 7.9 (my build host +for LFS 11.3) I built GCC 7.5.0 with Ada ('gnat') and D ('gdc') support, with an +install prefix of '/opt/gcc750'. GCC 7.5.0 was the newest GCC I could get to +build in CentOS 7.9 with Ada and D support. + +I had to copy a few shared libraries from the CentOS 7 system into +'/opt/gcc750/lib' but once I did that, I was able to use that GCC in LFS 11.3 to +then build an Ada and D capable GCC 10.4.0 within '/opt/gcc1040', GCC 7.5.0 +would not succesfully build an Ada and D capable GCC 12.2.0. + +However I was then able to use GCC 10.4.0 to build the Ada and D capable GCC +12.2.0 which is the GCC version in LFS 11.3. + +For the LFS 12.2 GCC bootstrap, I *suspect* I can use the Ada and D capable GCC +GCC 12.2.0 in LFS 11.3 to build an Ada and D capable GCC 14.2.0 installed in +'/opt/gcc1420' that I can then use in LFS 12.2 to bootstrap the system GCC, of +course running the full test suite before installing. + +I tried adding Ada and D support to the GCC building of LFS 12.2 Chapter 5 and +it caused a build failure, so it is *possible* I will need another intemediary. + +Anyway, boostrapping an Ada and D capable GCC within LFS 12.2 will be my first +priority once it is booting. + + +Phase Three: RPM Bootstrap +-------------------------- + +The needed libraries to build RPM will need to be built and installed, and then +RPM will be built and installed. + +Once RPM is built and installed comes the long and tedious task of writing the +needed RPM spec files to rebuild every package on the system in RPM. Much of +that work has already been done from my LFS 11.3 system but the spec files need +to be updated and some still needed to be written when the water pipe broke. + + +Phase Four: XFCE +---------------- + +Once the system is RPM bootstrapped, I can start building the software needed +for the XFCE desktop environment. + +My *personal* preferred desktop environment is actually MATE but XFCE is what I +am building as the default desktop environment for YJL. + + +Phase Five: Installer +--------------------- + +With XFCE running, an bootable USB thumb drive that can install the system from +RPM packages will have the be created. That will be when YJL becomes a reality +and not just a concept I am working towards. + + +Beyond YJL +---------- + +I really dislike the current GNU/Linux ecosystems where a distribution tries to +package everything under the sun. + +I much preferred the older days, pre Fedora, when 'yum' was new and you could +install Red Hat Linux and then use add-on package repositories that met your +specific needs. + +YJL will be kept small with a boring LTS kernel, the idea is that those who want +something different than my *personal* vision can build package repositories +that meet *their* vision and needs. + +Maybe there could be a small package repository with software suited for running +a Mastodon server. Maybe there could be a small package repository with software +suited for running a video streaming service. Maybe there could be a small +package repository with software suited for running a competitor to Overleaf +that actually uses a current TeXLive backend. + +I will probably maintain a package repository for MATE. I have no desire to +*personally* maintain one for GNOME or KDE or whatever but if there are people +who do have such a desire, they can run those repositories even with the freedom +to have their repositories *replace* YJL packages as needed. + + +YJL Kernel Philosophy +--------------------- + +Back when I first started using GNU/Linux, it was fun to always run the latest +kernel. In fact, I would run the ‘Alan Cox’ patch to the 2.4 series. + +Benefits to running the bleeding edge kernel now do not seem as apparent to me +and maybe they were only imagined back then. + +I am not a kernel hacker and even if the YJL project takes off, hiring a kernel +hacker does not seem like a wise use of resources. By running a LTS kernel in +YJL, security issues can be fixed by updating to the latest in the LTS series +from 'kernel.org' without needing to backport patches. Using an LTS kernel means +that YJL does not have to hire a kernel hacker to remain secure without needing +to break some systems with a kernel update when a particular kernel series is +no longer maintained, the LTS kernels are maintained for a very long time. + +Users who want a newer kernel are absolutely free to build one and I am sure +that many will, but then compatibility issues are their issue, not the issue of +YJL. + +Some examples of where this is an issue: I had a system in a room without a +wired network jack. I went and bought a PCI WiFi card with a Tux logo on it that +claimed Linux compatibility. Well, that was only partially true. + +The card required a closed source driver that worked just fine with older +kernels. In fact for CentOS, 'elrepo' had a package for it, but I could not get +the card to work in Fedora because the kernel was too new. I also had a similar +issue with an nVidia GPU. + +Using an LTS kernel does not guarantee that such hardware will work however when +the hardware does work with the kernel, it it likely to continue working with +updates to the same LTS kernel series. + +Users and add-on package repositories are of course free to package kernels from +newer series but then what to do when 'kernel.org' stop pushing updates to that +series is their problem, not mine. They can backport fixes, or they can update +to an even newer series, but doing the latter may break some systems. + +I actually encourage people to build their own kernels using a kernel +configuration that is well-suited for their specific hardware, and of course +many users will decide to do so using a newer kernel series. The LTS kernel that +ships with YJL should be a safe generic kernel configuration but the user need +not be restricted to those options. + +I would like YJL to have a tool that allows users to specify what kernel series +they would like to use that then monitors 'kernel.org' for updates to that +series and then creates a 'src.rpm' for them (using 'make oldconfig') that they +can rebuild and install. Sometimes updates have new options so it can not be +totally automated. Of course such a tool would need to verify the signature of +the updated source. + +### YJL Versioning + +YJL itself will only ship a LTS kernel and the series shipped will be used as +the version number of YJL. For example, the current LTS kernel I am using is +the 6.6 series so if I shipped YJL today, it would be YJL 6.6. + +If this project does take off, it is probable that I will not ship a new +version of YJL every time 'kernel.org' tags a new kernel series as an LTS +series. There is a good chance I will only make a new YJL for every other LTS +kernel. + +The 6.6 series was initially released in October, 2023 and has a projected EOL +of December, 2026. My guess is there will be another LTS series before I have an +installer ready, and that it will likely also have about a three year lifespan. + +My guess is that the initial installer will probably have kernel configuration +that needs a lot of improvement. Updated installers with updated packages are a +sure thing. A hyphen can be users for that, e.g. ‘YJL 6.6-3’ would indicate the +third installer revision of YJL that uses the 6.6 LTS kernel series. + + +TeXLive Philosophy +------------------ + +I am an avid LaTeX user, since the days of teTeX before TeXLive was a thing. I +hate distribution packaging of TeXLive. + +If someone wants to create an RPM package repository for TeXLive packages, more +power to them. The problems I have is that it really is better to just have all +of CTAN anyway and when you have been using TeXLive for any amount of time, you +likely want to have several versions around. + +If I need to tweak a document I made in 2016 using pdfLaTeX from TeXLive 2016, +there is a decent chance it will properly compile in TeXLive 2024 but very often +I find I need to make a lot of changes to it. However if I instead make the +tweak and rebuild it using pdfLaTeX from TeXLive 2016, there very rarely is an +issue. I might port it to LuaLaTeX in a modern TeXLive if I think there will be +more than just a tweak made, but if I just need to tweak it, it is good to have +the old versions available. + +TeXLive should be installed in '/opt/texlive/YYYY' where 'YYYY' is the year. +The system should have a user named 'texlive' that has write permission to it, +and that user account can update the install as needed using 'tlmgr' and when a +new version of TeXLive is released, the 'texlive' user can install it without +nuking the older versions. + +YJL will provide the shell scripts needed to set this up, YJL will not package +TeXLive. Third parties that want to create an RPM package repository, have at +it, I just think distribution packaging is the wrong approach to TeXLive. + + + + + + + + + + diff --git a/THE_WHY.md b/THE_WHY.md new file mode 100644 index 0000000..ab86b21 --- /dev/null +++ b/THE_WHY.md @@ -0,0 +1,104 @@ +The Why +======= + +Well, this is at least a partial explanation at *why* I am attempting to create +my own GNU/Linux distribution. + +I have less and less fond of the current GNU/Linux distribution landscape. It +seems that each distribution has a specific way of doing things and you do it +their way or do not do it at all. Each distribution likes to package everything +under the sun and you use their packages or you build from source. + +I have a different philosophy. I do not like monopoly power. I do not like the +power that Amazon has, I do not like the power that Facebook has, I do not like +the power that Chase has, I think diversity in options is key to consumer +quality. + +It is true that there are many different GNU/Linux distributions to choose from +but it seems that each one is trying to be a monopoly power and dictate how +things are to be done. + +The first GNU/Linux distribution I ever used was MKLinux DR3 on a PowerPC G3. +For those unaware, MKLinux DR3 was a port of Red Hat 5.1 to the Mach Mikrokernel +by Apple Computer. + +Before long I was running LinuxPPC 1999 (a port of Red Hat 6) and it was on +LinuxPPC 1999 that I first did the LFS Project, LFS 2.0. That is where I learned +the most about GNU/Linux. + +Eventually I ended up on 'x86' hardware running Red Hat Linux. Life was good. +Red Hat provided a good base and there were several different third party RPM +packagers for software beyond what Red Hat provided. When I say life was good, +of course we will ignore the whole GCC 2.96 debacle...but the third party +package repositories provided GCC 2.95. + +And then Fedora happened. Fedora as ‘Fedora Extras’ was a good thing, and it was +not the only option people had to extend software beyond what shipped with Red +Hat. But then Red Hat Linux ceased and became Fedora Core and then Fedora. The +software was always bleeding edge and just when it started to mature and become +stable, it became ‘End of Life’ and us users were forced to install a new +version with new bugs. I hated it. Basically it was not profitable for Red Hat +to produce a consumer distribution so they turned it into a testing ground for +their Enterprise product. To their corporate mindset, us users were nothing more +that free beta testers for what would go into their commercial enterprise +product (RHEL). + +I switched to CentOS at that time. The software wasn’t bleeding edge, but it was +stable and it worked. CentOS 5 was my first version of CentOS. + +When necessary---such as with Apache, MySQL, and PHP---we could install newer +versions on it either from source or from add-on repositories, but the operating +system itself was solid and stable and well-maintained. + +CentOS (developed as a clone of RHEL) became aquired by Red Hat and CentOS 7 was +the last version I felt comfortable with. I simply do not like the direction +that Red Hat has gone with it. + +Debian is still a really good choice, I ran it on an m68k system (Apple SE/30 to +be specific) back when I was first learning GNU/Linux but I felt like I just did +not fit into the Debian world. At the time, mail lists were the method of user +support and the mail lists for Debian seemed more hostile to me than they were +in the Red Hat world, I just did not feel welcome. + +The issue, my brain works differently. I am not dumb but I do not always +understand explanations people give because my brain works differently. On the +Red Hat related lists, it seems people were more patient when I had trouble +with an explanation but on the Debian lists, I was treated like an imbecile. So +I never felt welcome in the Debian world. The distribution however is fantastic. + +At one point I tried Ubuntu. After installing it, I did not see where the GIMP +was installed so I used their search tool thingy to search for it, and I was +sent to an Amazon web page offering me books on The GIMP. Fuck that, I wiped it +and put CentOS on that system that very day. + +I later learned that not only was Ubuntu sending my search request to Amazon but +it was doing it without a secure connection. Who the fuck approved that and why +wasn’t that caught in beta testing? It generated enough complaints that they +stopped doing it but I have to wonder when they will try something like that +again. It seems the bigger a company is, the more likely it is that they lose +sight on the importance of user privacy. The consumer becomes the product they +sell to other big companies, and that even happens in the FLOSS world. In the +FLOSS world though we, the users, have the power to do something about it. +Well, in theory we do anyway. + +Fast forward several years... + +When it was announced that CentOS 7 was ‘End of Life’ I tried the modern Debian, +Fedora, and Ubuntu options. All of them installed on my hardware and all of them +kernel panicked on first boot. LFS works fine, even with modern kernels, so it +seems that the GNU/Linux distributions have something selected in their kernel +that causes a kernel panic but is not used in their installer. I could try to +track it down, I suspect it was a bug in the open source nVidia driver, but +honestly I think rolling my own GNU/Linux distribution is going to give me +happier results. + +Worst case scenario, I am my only user. Would that really be so bad? + +My hope is that there are others like me who agree that a small ‘Core’ +distribution with user choice in package repositories for software beyond that +‘Core’ is the right way to do things. + +Such a philosophy does sometimes result in conflicts between package +repositories but such conflicts can usually be solved without too much work. + +