-
None of these. I use the LFS build system to start the core build and then fork to my custom build about 3/4 through to include other tools and packages I require on hosts.
do you use the Debian/Ubuntu package manager? PACman (Arch Linux), Portage(Gentoo), BitBake OE? ... or have you implemented your own package manager with a dependency resolver?
and do you use "recipes" and/or "ebuilds" from other distros?
I am going to replace "emerge" with something written in C, able to also use "recipes", and based on a true database.
# mypac
> db import /var/db/pkg
> db save
(how it will import from the Gentoo text-based packages database)
I don't like Python-based tools, and I need to support EAPI from 1 to 8. Two years ago Gentoo dropped all the support for EAPI<5.
No. I build all upgrades from sources. I resolve dependencies by examining the source build notes and the configure scripts.
Since the system I build are very lean there are not that many packages to be concerned with. I've eliminated all the useless bloat that mainstream distros have.
The only time I do a full OS rebuild is when there are major updates to gcc, glibc or Linux, as this tends to have an effect on everything.
-
No. I build all upgrades from sources.
I am talking about that! Gentoo and BitBake both compile stuff from sources unless you need a binary package
e.g. to compile gnat, you first need a binary "bootstrapper", basically a compiler able to compile Ada
e.g. Java{c,jre} is a binary package, a tarball that contains stuff that will be installed in /opt
e.g. since Yaboot is broken on PowerMac and nobody (except me) wants to fix it, if you don't want to use Grub2, you can only install Yaboot-staticCode: [Select]sys-boot/yaboot <----------------------- it will be compiled from the source
Description: PPC Bootloader
sys-boot/yaboot-static <----------------------- it's a tarball that contains the binary program
Description: Static yaboot ppc boot loader for machines with open firmware
I always compile stuff from the source, but you still have to consider and resolve dependencies!
What has to be compiled, and in which order. Sometimes there are also conflicts, and you have to resolve them.
There are also conflicts with user flags! Which features enable which rebuild -> sometimes you have to choose mutually exclusive.
The Portage has "slots" to facilitate the tasks. OE has a similar concept, but "recipes" are simpler than "ebuilds".
That's the job of the package manager! Plus, it needs to keep information about which file belongs to which package, and how every single package has emerged! -
I like this approach in theory, but it's much too time consuming, unfortunately.
The day I might go as far as that, I might as well write my own kernel too. (Something I'd like to experiment with, but too big an endeavour unless sticking to a very very small set of hardware.)
-
Mint is good thesedays, MATE version is good if you just want the OS to run and don't care about more modern looking graphics, though some of the default settings are terrible (like a fat ungainly cursor without a sharp indicating point) and need changing right away when you install. Ubuntu is pretty similar to Mint except that with more recent versions Ubuntu is moving in the rather corporate "we'll handle all the settings, don't worry your pretty little head" direction whereas Mint still has menus which let you get at most things easily. Obviously command line gives you yet more control on either distro.
-
I run OpenBSD on some Fuloong boxes which are file servers and emulation hosts.
oh, arch/mips/loongson64 -> ~MIPS64/LE
They're great little green servers
-
Personal use / preference:
Servers - Debian Stable
Desktops - Arch
At $dayjob:
Servers - Mostly Ubuntu Server, some CentOS
Desktop - Kubuntu -
No. I build all upgrades from sources.
I am talking about that! Gentoo and BitBake both compile stuff from sources unless you need a binary package
e.g. to compile gnat, you first need a binary "bootstrapper", basically a compiler able to compile Ada
e.g. Java{c,jre} is a binary package, a tarball that contains stuff that will be installed in /opt
e.g. since Yaboot is broken on PowerMac and nobody (except me) wants to fix it, if you don't want to use Grub2, you can only install Yaboot-staticCode: [Select]sys-boot/yaboot <----------------------- it will be compiled from the source
Description: PPC Bootloader
sys-boot/yaboot-static <----------------------- it's a tarball that contains the binary program
Description: Static yaboot ppc boot loader for machines with open firmware
I always compile stuff from the source, but you still have to consider and resolve dependencies!
What has to be compiled, and in which order. Sometimes there are also conflicts, and you have to resolve them.
There are also conflicts with user flags! Which features enable which rebuild -> sometimes you have to choose mutually exclusive.
The Portage has "slots" to facilitate the tasks. OE has a similar concept, but "recipes" are simpler than "ebuilds".
That's the job of the package manager! Plus, it needs to keep information about which file belongs to which package, and how every single package has emerged!
I've been building my own distro for around 20 years now.
The original bootstrap system was an old Fedora/Redhat installation. This was used to build the toolchain required to compile the sources in a chroot environment.
These days I just use the existing system to build a new system.
I identify the dependencies and install what is needed with just the options that I want on the system. I do this for all packages.
I have it well documented and scripted so it's not too time consuming. I have many types of servers running this OS, from Supermicro rack servers to desktop boxes to NUC boxes. Usually all that is needed is the addition of a network driver if there is different network hardware. After booting I can rebuild the kernel with additional support for things like sensors if needed.
-
I identify the dependencies and install what is needed with just the options that I want on the system. I do this for all packages.
Nowadays, whenever I compile stuff from Git or elsewhere, I write a build script capable of pulling the sources from git (unless the directory already exists), running ./configure options..., make et cetera, that I keep around even after deleting the actual sources (and binaries). It makes rebuilding stuff much, much easier, since the cognitive load is minimal. (I of course do read the script first, because it can remind me of oddities in particular software projects.)
I have it well documented and scripted so it's not too time consuming.
I never liked the Automated Linux From Scratch approach of extracting the commands from the XML LFS or BLFS book(s), and instead always preferred to put the commands for each package into a script. Prefixing the script with a three or four-digit order number, you could just execute them in series to compile an entire system.
For Debian derivatives, I like that script to build a .deb package, and then install the built package by hand, because it makes system maintenance simpler – especially so if you bother to set the prerequisites/required packages/conflicting packages right. Even when no suitable debian/ exists for a particular package (often one from another derivative works fine; sometimes may need small edits), it is very easy to add yourself; see Guide for Debian Maintainers, especially chapters 8.3 and 8.2, because they cover the most typical cases.
I used to do the same for .rpm packages under RedHat derivatives, but haven't used RHEL/Fedora-derivatives as my workhorse for a few years now. Adding the details to build an RPM package is quite similar process, though; see e.g. RPM Packaging Guide, or the packaging guide for your distribution. -
I identify the dependencies and install what is needed with just the options that I want on the system. I do this for all packages.
Nowadays, whenever I compile stuff from Git or elsewhere, I write a build script capable of pulling the sources from git (unless the directory already exists), running ./configure options..., make et cetera, that I keep around even after deleting the actual sources (and binaries). It makes rebuilding stuff much, much easier, since the cognitive load is minimal. (I of course do read the script first, because it can remind me of oddities in particular software projects.)
I have it well documented and scripted so it's not too time consuming.
I never liked the Automated Linux From Scratch approach of extracting the commands from the XML LFS or BLFS book(s), and instead always preferred to put the commands for each package into a script. Prefixing the script with a three or four-digit order number, you could just execute them in series to compile an entire system.
Agreed. I build my own scripts because I decide on what is needed and what is not needed as options for each package configuration, primarily for security and performance.
-
I build my own scripts because I decide on what is needed and what is not needed as options for each package configuration, primarily for security and performance.
Yup; for me a major part was also thorough understanding of how the various parts of a working system interact.
Nowadays, few server admins realize that keeping e.g. server configurations in their standard locations is problematic, because it causes new related services to be "enabled" (if that is what distro maintainers have configured it to) by default when installed, and that can conflict with the existing configuration. My favourite example of this is Apache (the HTTP/HTTPS server). Many packages provide "utility" components accessible via the local server, and even in Debian, some of them are enabled by default. Personally, I move its configuration directory elsewhere, and require any new features to be added to the actual configuration by hand by an administrator. (Combined with admin action tracking even across 'sudo su -', this leaves an immutable log of which admin has enabled what additional features.)
One can be pleasantly surprised how much better performance one can get from an Apache or Nginx installation, with properly tuned settings and chosen modules. (The related security issues, especially using multiple user accounts per site, with server-side code unable to modify itself or create new server-side executables, is one of my buttons I could rant about for hours on end.)
It is doubly important when you have a server with multiple sites, and user administrators of various levels (including students) and occasionally across subsites; I developed a well-working local groups based scheme with only a couple of helper utilities needed for that scenario.
At the time I maintained my own distro, around the turn of the century, one was a qmail mail server and DNS server/cache and NAT gateway for a subnet, and another was a file and print server for Mac OS (pre-X) and Windows clients, using Mars NWE and Samba, for sharing the same volumes. I did a lot of work around proper file locking (for MS Office users), but I cannot recall whether I got it bullet-proof or not. (It was good enough to not have issues I did not have workarounds for, though.) I had very good relations with the IT dept at that uni, but unfortunately my own stuff worked so well and I didn't advertise it enough that the dept heads had no idea what I did –– they just saw everything working as it should, with no effort... Started my own downfall, that. -
Thanks everyone for input. Unexpectedly, it came in all over the map, but Debian or its cousins were the majority. I will give it more thought as this is a good chance to rearchitect my home system.
Thanks again.
Though I'd add a postscript to this. After trying to find a setup I like for an rpi4, I've just configured one with Debian server (Bookworm) plus XFCE desktop plus tightvncserver, wih good results so far.
Haven't tried that setup yet on an rpi3.
So I can see Mint or Debian plus XFCE becoming my standard setup for PCs, Udoo boards, rpis and the like. I'll be looking for Debian or Mint compatibility in any future hardware for my
home system.
-
I use Ubuntu, Debian (both WSL), CasaOs and Zorin Pro.
-
Former Sysadmin here (20+ years experience in 3rd line support), so my experiences related below primary relate to server rather than desktop usage.
For several years, RedHat (prior to Fedora) and CentOS were my favourites, but then I started running into package dependency issues.
I ran into stability issues with Fedora so switched to Debian, which I have used almost exclusively for the past 10 years or so.
I rarely ever used Linux on the desktop (I used to manage mixed environments so needed the Windows tools) however I note that most of the software developers I provided support for favoured Ubuntu and CentOS with a tiny percentage liking Linux mint.
More recently (and having developed a dislike for Systemd) I have been using Void Linux which uses runit instead of systemd (although I note that runit is now available in Debian).
I have also had brief encounters with Slackware (I find the package management a bit clunky) and Gentoo (also found managing packages a bit tedious), although in fairness I think both of these have improved in recent years. I've not tried them for a long while.
-
For several years, RedHat (prior to Fedora) and CentOS were my favourites, but then I started running into package dependency issues.
I ran into stability issues with Fedora so switched to Debian, which I have used almost exclusively for the past 10 years or so.
It's a long time ago since Redhat and the most common derivatives had dependency issues. The repositories are rock solid nowadays and testing and quality control is top class. Where you can get some hiccups, is with third party repositories that don't have the same quality control. Even Fedora that has a fast development pace with latest versions of everything, doesn't have any issues nowadays. I would say around 10 years ago or so, there were sometimes issues with Fedora. Nowadays it's a solid desktop distribution. I wouldn't use it on a server, though. Even CentOS Stream would be easier to maintain. (Written from a Fedora desktop). -
I started with Slackware and then RedHat in the early/mid 90's. I still have a commercial boxed copy of RH 3.0 (on 3.5" floppies) on the shelf. I still remember installing from FTP servers. When RedHat split the distro between RHEL and Fedora, I started looking at others. I've dabbled in several, but have mostly landed on Debian and Ubuntu LTS distros. I do some desktop work but it's primarily server and CLI based development work, so I don't need a Linux GUI. When I need a GUI then I'm typically needing MacOS or Windows.
-
Ubuntu since 6.06 (2006) is my daily and go-to distro. I install others only if needed for a particular reason.
-
I have been using Linux Mint for quite some years now and I am very happy with it on the whole. I do miss some things from Windows like the Device Manager and mint still has some bugs that bother me but, on the whole, I am happy and would not go back to Windows. I absolutely refuse the concept of the software as a service and the "telemetry" spying, etc. No way.
Linux Mint requires much less in resources and will run efficiently in machines that would choke on Windows 10. When Covid arrived I installed Mint on a bunch of old laptops so the kids could attend remote classes. Those laptops were older dual cores that would choke on Windows.
Mint has some bugs that bother me and I do not understand why they are not fixed. One is the desktop icons not behaving, moving, etc. It seems so basic.
I am running Linux Mint and then Win XP SP3 Pro as a virtual machine with VMWare. -
Too lazy for Gentoo
so it's Arch even though it sucks massive donkey balls 
Debian derivatives I can't stand, their package managers are weird and have crap UX. -
I am experimenting with fedora for the first time. Previously, I used MX Linux. The reason for fedora is simple - Framework 13 laptop. However, I am not friends with Gnome. It is weird but some say one gets used to it.
-
Debian derivatives I can't stand, their package managers are weird and have crap UX.
LOL I'm the opposite. I love me some apt! Everytime I have to use a non-apt based distro I curse as much as I type. It's become second nature to me. I came from RedHat back in the 90's when RPM was state of the art over building from tarballs, though dependency management was still hell. Yum was just gaining ground on RH-based distros when I shifted to Debian-based builds. Yum is okay but I'm far more proficient with apt.
If you're referring to the GUI UX, then I can't speak to that as I rarely use it. I do all of my sysadmin stuff from the CLI. -
No, I'm talking all the apt-* dpkg-* stuff.
A million executables with a billion subcommands, no single man page, IIRC some of them are only usable after fetching additional data which are not downloaded by "apt-get update",
I presume one can get used to it and become proficient, but I'm not there yet. -
Debian, minimal on the little print server I made from a junk netbook, whatever the default desktop is on the desktop machine (meh, it works well enough I haven't bothered to change, yet).
-
I am experimenting with fedora for the first time. Previously, I used MX Linux. The reason for fedora is simple - Framework 13 laptop. However, I am not friends with Gnome. It is weird but some say one gets used to it.
I think what most people who are happily running Fedora get used to is you select one of the other desktops, like Mate or XFCE, as you install it. Fedora has them all packaged up nicely, so they install just as smoothly as Gnome. Gnome took a weird turn at version 3, that they won't retreat from.
I've used Fedora and RedHat before that for the last 25 years. However, recent changes to Fedora have finally made me seriously experiment with Debian. I haven't been finding any issues I can't live with, although the apt world seems clunkier than the rpm+dnf world.
-
Gnome took a weird turn at version 3, that they won't retreat from.
What actually, did they do? Gnome 2 was great. But I landed up in a Windows world just as G3 was getting substantial enough to consider transitioning. -
Gnome took a weird turn at version 3, that they won't retreat from.
What actually, did they do? Gnome 2 was great. But I landed up in a Windows world just as G3 was getting substantial enough to consider transitioning.
its quite fine if all your gonna click on the desktop is a few apps, its the desktop to give to your mum, big icons, all staring right at you, can't get confused about that?.
For anyone else its insanely inadequate. And please, doing a search to get at all your special apps,its WTF?