Mumbling about stuff

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

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