Debian 10.3
debian.org
debian.org
With a tiny exception for the two most complex packages, Chromium and Firefox, which have different support cycles from Debian plus different levels of arch support. For those you get a wholesale application upgrade which may or may not work given your arch and version of stable.
Not a big deal atm, but if the web or the arm architecture ever takes off this may become an issue.
The name Debian itself is a portmanteau of the names Ian Murdock (the creator of Debian) and Debra Lynn (his then-girlfriend, later ex-wife). As a result, this name has been called a curiously personal name for such a community-oriented project.[3]
I was using Fedora and Ubuntu in 2007 when a member of a local Linux User Group (LUG) introduced me to Debian. Its simplicity and elegance, its vast package repository, and its stability and robustness made me an ardent user of this distribution pretty quickly. Thirteen years later, I still use Debian on my laptops, Linode servers, and virtual machines. I run my personal website[4] on Debian too. I have got so used to "apt-get install" and the large number of tools available in the Debian repositories that I keep a Debian VM or a remote shell handy when I am working on a non-Debian system. Over these years, I have gradually moved from GNOME 2 to GNOME 3 and then to Xfce 4. It really helps that Debian provides an installation CD with Xfce as the default[5]. In case anyone is interested, I have documented and shared my Debian setup notes on GitHub[6].
[1]: https://pixar.fandom.com/wiki/Etch_A_Sketch
[2]: https://pixar.fandom.com/wiki/Buster
[3]: https://archive.org/download/lud098mag/LU%26D098%20-%20Andro...
[4]: https://susam.in/
[5]: https://cdimage.debian.org/debian-cd/current/amd64/iso-cd/#i...
[6]: https://github.com/susam/dotfiles/blob/master/docs/debian-se...
I remember back around 2005, I missed meeting him by a ~week. My college Linux users group was having a birthday party for Debian, and Ian was an alumnus of that school, so he was going to attend. It was right before the semester started, so I was out of town.
> Debian releases
Not Debian itself.
From "A Brief History of Debian, Chapter 3 - Debian Releases" [0]:
> This was the first Debian release with a code name. It was taken, like all others so far, from a character in one of the Toy Story movies...
"Bo" was the first version of Debian that I played with. I switched to Debian "full-time" shortly after "Hamm" came about.
[0]: https://www.debian.org/doc/manuals/project-history/ch-releas...
My first was Debian 4. Ran it on a 550mhz PIII.
The client went away, and so did I.
Then some month ago, the client came back. The Debian 5 is still online and still running (but we plan to move on a new infra with a Buster soon).
I'm curious why were you so impressed by Debian in comparison to Ubuntu? Ubuntu is based on Debian and shares most of the mentioned features, yet your observation sounds like you experienced them as two very different systems.
Fortunately, it only takes a minute to grab the latest mini.iso, mount it, grab the kernel and initial ramdisk images (and "cat" the non-free/unofficial firmware to the end of the ramdisk), push 'em up to the TFTP server, and be right back in business.
When it does break, it literally takes less than five minutes to get it working again. Looks like I'd been using the previous kernel and initramfs since 2019-09-05 and, well, I can deal with spending five minutes on an issue once every five months -- especially considering all the time that it saves me!
(At one point, I insisted -- for some unknown reason! -- on using the weekly "unstable" images so the breakage was much, much more frequent. Fortunately for my sanity, I finally gave up and went back to just using the latest "stable" mini.iso.)
Thanks for the suggestion but, no, this won't work for me.
---
Long answer:
Unfortunately, no, that doesn't help me as I don't really even need an ISO image at all. What I really need is just the new version of the kernel ("linux") and initial ramdisk ("initrd.gz") files.
I don't need the regular ("cdrom") ones (like you might find on a regular ISO image), though. I need the "netboot" ones -- yes, they're different! Well, the kernel is usually the same but the initrd.gz is different.
When a new version of the kernel and modules show up on the servers (and once my local "cache/proxy" notices them and downloads the newer version of the modules), my network installs will start failing. See, a host PXE boots the existing version of the kernel but when debian-installer launches and starts downloading the modules it needs, it finds that they were built for a different version of the kernel than what it booted from. This causes "that oh so familiar error message" to be thrown [0] and the installation to fail.
The "fix", obviously, is to boot the new kernel instead of the old one.
As I mentioned, all that I really need to do is replace the existing versions of the linux and initrd.gz files on my TFTP server with the new ones. In theory, I could just SSH into the TFTP server, "cd" to the appropriate directory, fire off a single "wget" (the URLs for those two files don't even change!), and be done; real life is, however, (only slightly) more difficult!
Now, once in a very great while, I will actually do an installation on a VM where I do use an ISO image instead of performing a network install. That's why I just go ahead and grab the ("netboot") "mini.iso" file and extract the linux and initrd.gz files out of it instead of downloading just those files in the first place.
The other thing has to do with the "non-free" firmware. Although they provide ISO images that include it, it was easier for me to just do it myself. Once I've got the linux and initrd.gz files downloaded, all that is needed is to download the "firmware.cpio.gz" file if I don't already have it (or if a newer version is available or something) and (literally) "cat" initrd.gz and firmware.cpio.gz together.
Then, I replace the existing linux and initrd.gz files on my TFTP server with these two new files and reboot the host so that it restarts the network install! Depending on the hardware, it sometimes takes the server longer to POST and get to the point where it actually starts booting than it takes for the actual OS installation (I'm looking at you, Dell PowerEdge servers!).
It may sound like a fustercluck but it's actually pretty simple (just a few commands) and from "uh oh, the install failed" to "okay, it's working again" is almost always less than five minutes (well, it is now that I switched back to using the "stable" mini.iso images instead of the daily or weekly "unstable" ones!). I could write a script to automate it, I suppose, but it doesn't seem worth it as it only happens two or three times a year.
(That's a rather long way of saying "no, that doesn't help" but since you offered a suggestion I wanted to explain why and not simply dismiss it with a "no, that doesn't help"!)
---