Is it just the same if I only decide to update arch every 6 months or so compared to a point release distro? Actually now I write that I remember that doesn't work because due to file conflicts between old and new versions of things full updates are forced upon you.

I do update more often now due to learning that partial upgrades break stuff so I will do a full update when I want to install a new package which might be every month or two.

How does it work with point release distros when you want to install a new package? What I mean is with arch you usually have to do a system upgrade because the new program, or an existing one, will end up breaking due to dependency conflicts or library dependency breakage from old package and new breaking things.

I would not be interested in doing a full upgrade every time with arch if it weren't for this.

So wondering how point release distros work in that sense? Is it that all packages you pull from their respective package manager are 'frozen' to that particular release number so the above issues would not happen?

I suppose my main question is what is the best way to have the least intervention as possible with your system if you like a stable system and don't like updating unless absolutely necessary?

I like the philosophy of if it aint broke don't fix it but arch's philosophy seems to be welcome system breakage through incessant updating as the sooner you update and find the problem the sooner you can fix it. This seems flawed to me since most times the system breaks due to the updating itself when the system was perfectly fine before.

That's precisely the point. When any library can be upgraded at any time, the system becomes fragile. In a point release distro, it's the job of the developers to ensure that upgrades don't break the system.
Some packages are effectively frozen. It's very unusual to have a glibc update. When I started using Linux, glibc and kernel headers had to be upgraded in step or not at all. I don't know if that's still the case today. But most components aren't that critical. A library update may affect dependent programs if the binary interface has changed but not otherwise.
If a distro is designed to be stable, then nothing should break in an update. If it's designed to be bleeding edge, like Arch, then you will get ample warning about the possibility of things breaking.
It's a matter of temperament. I used Arch briefly and didn't like it so I moved on. If you want a hands-on distro suitable for experienced users but you find the fragility of Arch annoying, use Slackware. It never breaks.

1 members found this post helpful.

There was a long thread in the slackware subforum when I asked if slackware was a good fit for me given many recommendations similar to yours however I got turned off by the massive mandatory install size of the whole kitchen sink.

Even with arch's update issues I prefer the modular approach of a lean initial system and only installing what packages you wish to thereafter.

Didn't settle on a distro yet that would achieve both the stability (or similar) of slackware with the modularity of arch.

That's very much what I think too. I don't really care for the "full install" philosophy; like you, I prefer to install only what I actually need. But you can actually do that with Slackware if you know what you're doing and are prepared to spend the necessary time.

I started from my experience of building LFS/BLFS. From LFS I knew more or less what packages I had to install to make the system work at all. BLFS tells you about graphics and applications and what dependencies they have. I also did a lot of detective work, running ldd on applications in a terminal and seeing what libraries they were missing. And later I acquired from someone in this forum a script that automated the detection process.

I wouldn't recommend this for anyone who is short of time or patience, but I'm retired and have plenty of time for eccentric projects. What I have ended up with is a Slackware that occupies only 12G on my hard drive and contains only what interests me. I've been using it for years now and it's as stable as a rock.

1 members found this post helpful.

Debian.

1 members found this post helpful.

Stable but more likely to go wrong than Slackware because of its complicated update manager. It also uses systemd. However neither of these points should bother someone coming over to Debian from Arch!

1 members found this post helpful.

Yes the rebuke I got on the slackware thread was that "data is so cheap why on earth does it matter what space it takes up?" That is 'wrongheaded' imo. I, rather, think of it like those 'demoscene' guys who try to cram as much as they can onto the atari or such old computers just to show off their skills. It is a matter of pride I guess to keep things as simple as possible.

Saying "what does it matter" is like saying "what does it matter how sloppy and bloated your codebase is so long as the machine can handle it".

Here is the thread if you were not part of it when it came around.

I did get a few comments like yours, that it could be tailored how you want, but I then wondered if there might not be a more suitable distro to suit those needs. I am not afraid of the work be if something already does it better for what I want no need to reinvent the wheel.

Also when you have a rock solid machine like that just how you want it, how do you manage security updates for internet facing programs like browsers and such? Do you still keep them frozen or update security patches as they become available? Does slackware support those none contemporary versions of, say firefox, as per their release cycle so you won't have a new version of firefox until they make a new release but will get security patches for the current version you have for x amount of yours til the next point release comes out?

So you would see debian as the 'lesser evil' of the two? with slack still being the clear winner in terms of stability?

I have been 'brought up' on systemd since arch already had it as standard when I began my linux journey in 2016 so I do not have any reference to anything else and as such do not have the hate that much of the linux community seems to have for it.

Still doesn't mean I am not open to trying something else if there are good arguments it will be more suited to my general KISS philosophy.

While I am not fully retired yet I do have indefinite free time for the moment due to indefinite passive income from previous online work. I have been at rather a loose end for quite some time and in between moving at the moment so have been looking for something to engage my mind in the interim. So one of the 'hardcore' distros with the modifications you are suggesting to make it how I want may be a good thing to sink my teeth into.

I wouldn't want to do that for my desktop right away and have a broken machine perhaps for several months so I could just do it on a qemu vm couldn't I, keeping arch as the host for now, until I learned the ropes?

I do a normal update once a month using slackpkg (the Slackware equivalent of apt) but I don't use the generally recommended install-new option. This means that I get browser upgrades, security fixes and so on, but only for the packages currently installed. I suppose it may occasionally happen that some package acquires a new dependency and stops working but, if it does, I should be able to find out why and fix it by hand. Just running the app from a terminal would usually highlight the missing item. Linux, unlike Windows, has wonderfully explicit error messages.

Actually, looking back on what I have just written, I think new dependencies for existing packages are less likely to pop up in Slackware than in Debian. It's not really the way Patrick does things. Stability is his fetish.

Yes, definitely. I don't use Debian any more, although I used to use it a lot.
I didn't hate systemd when it first appeared. In fact I built a systemd version of LFS. I liked the speed with which it booted and shut down. But I hate how it has wormed its way into applications like cups which now can't easily be run without it. In a free software environment, your ability to use an application shouldn't be restricted by your choice of bootloader (or, worse still, someone else's).
Why not just dual-boot? It's much simpler.

Simpler? How? I cannot imagine how it would be.

It's very simple. You let the first distro install your preferred bootloader (in my case that's Slackware's elilo), and you then install the other distro without a bootloader. You make that distro bootable by simply adding it to the existing loader configuration.

Mind you it doesn't always work the way it should. For example, when I installed AntiX alongside Slackware, I skipped the bootloader section because AntiX uses GRUB, which I don't like. Afterwards, I couldn't get it to boot from elilo. The kernel booted OK but then it always went straight to an emergency shell, despite the initramfs image that I had created for it. The problem, I found, was that the mkinitramfs program didn't work properly because the installer hadn't populated the sample initrd tree correctly. That essential job had been placed in the "install bootloader" branch of the sequence where imho it doesn't belong. Maybe that's a general problem with Debian distros.

A point of style: if you want to answer just one point in a long post, edit your quote so that only that point shows. It avoids silting up the display.

Ok but I didn't find a way to multiquote on this forum so quote all and respond to all. I see the multiquote button on posts but haven't been able to find the insert quotes button when making a reply.

I still do not see the above as being preferable. Maybe it is easy to implement but I prefer the isolation of a vm and if I muck it up easier to simply wipe that than having multiple different installs on the same drive (unisolated).