I can understand the appeal of the idea, but this feels like a significant mistake. It would be like an automaker saying, "We are using exclusively 17 mm bolts for fasteners." Sure, it saves you time with finding a wrench. But I can't begin to imagine the number of compromises or additional complexities you introduce this way.
It seems like a goal founded in an academic ideal rather than a design benefiting from engineering practicalities.
I spend 10 hrs a week under cars, and i say, hell yeah! I want this! For all cars!
Some standardization is a great idea, but including the word "all" is what makes it academic and impractical. And if you're not going to be absolutist about it, then you're just using marketspeak.
So can you be more specific about the kind of compromises you have in mind and whether they are currently affecting Guix?
To the better, right? Right? The last two years yielded so horrible regressions to me that I'm again considering giving up on Linux.
Second, have you tried windows or macOS recently?
I used to run Alpine Linux on servers, decided i wanted to change to something less exotic and found that Debian is no less buggy. No idea how to go on.
Windows is consistently worse, i haven't tried macOS as it is not really popular here.
The lts is fine, no problems at all.
What were the issues you faced with Debian on your servers?
I run arch and so I bump into those once in a blue moon but it's rare.
Debian runs older versions so you miss recent bug fixes but at the same time you should see minimal regressions. Pick your poison.
You might be extra sensitive to bugs. I'm that way too but at least I can fix them when I have the source.
I also only use a few apps (Firefox, eMacs, VLC, gimp) and i3 as my window manager. It's been a long time since I hit a bug that actually impacted usability.
The suggestion with the bug sensitivity is belittling, cut that out.
I have utmost respect to apt, especially since I switched my daily workstation to Arch and learned how the life without it looks like.
There's also a matter of packaging practices, which isn't entirely a pacman vs. apt thing but rather Arch vs. Debian (although package manager design does influence and is influenced by packaging practices). In Arch, the package manager will happily let you install or keep an out-of-epoch package installed during an upgrade that will just fail to function. apt usually won't let you proceed with an upgrade that would lead to such outcome in the first place. It's a thing that's ridiculously easy to stumble upon as soon as you use AUR, but since user's discovery of the issue is delayed, most people probably don't attribute it to package management at all - they just see an application getting broken one day for some unknown reason, while apt screams at them and appears broken right away when they try to use apt.
To be frank, I don't know for sure that relations between packages that Debian uses couldn't all be expressed with pacman, maybe it's possible. What I know though is that I've never seen a Debian-like system that used pacman, and I know that makepkg-based tooling is very far away from debhelper so even if it's theoretically possible with pacman, you'd have a long way to get there with your tooling anyway.
What I'll actually cut out is responding. Good luck with your bugs.
How did you manage to do that? I use Debian on about half my home fleet (about a dozen machines or so) and apt has caused me no issues in the past decade and half.
I haven't had to go into the shell to change anything yet, the default files, software center all work as I expect out of the box, including mounting USB drives which has always been an annoyance to me.
Now I'm investing in learning CentOS Stream and SELinux, happy with the learning curve thus far.
On servers? How do you notice? Maybe you are doing things we don't?
We already have enough UNIX clones, and moved away from TUIs 40 years ago for a reason.
Funnily enough, init.rc used to be on the top of it, as well as all the numerous process/job management gotchas. Systemd + control groups = step forward. Plan9-style fuse-based systems = step forward. Kernel data structures exposed as files = step forward. And so on.
CLI utils will probably have their place like forever, TUIs as well, with the main benefit being the ease of development and staying in the CLI context.
Perhaps ironically systemd is one case I would point to as being an acceptable breakage. The software itself definitely fulfils the license's promise of "NOT FIT FOR ANY PURPOSE", but as an idea it's mostly sound. It suffers from bad design in that e.g. it has no concept of "ready state" so there is no way to express "The VPN service needs the network to be online" and "The NFS mount needs the VPN to be connected"; thus it also has no way to express "you must wait for the NFS to be cleanly unmounted before stopping the VPN" - only "you must execute umount before tearing down the VPN (but without waiting)". Similarly if you have a bind mount you can't make it wait for the target to be mounted before the bind mount is executed (i.e. if I have an NFS mount at /mnt/nfs/charlie and bind mount /mnt/nfs/charlie/usr/autodesk to /usr/autodesk, I could find no way to make systemd wait for the NFS mount to be done before bind-mounting a nonexistent directory - contrary to the man page for /etc/fstab it executes all mounts in parallel rather than serial). All that said, you can work around it by sticking to bash scripts, which is the good part - it still retains a good bit of the old interface.
The problem really comes when a completely new way of doing things is invented to replace the old way, e.g. ip vs ifconfig, nftables vs iptables - now you have to learn a new tool and keep knowledge of both the new and old tool for a while (about a decade or two) until the old tool has gone completely out of use in every system you administer.
This was the kind of thing we used to make fun of Microsoft for in the '00s. Every year a new framework replacing the old framework and asking you to rewrite everything. In the end people just kept using the Win32 API and Microsoft actually kind of stabilised their churn. Now Linux is making the same mistakes and alienating existing users. I'm not sure how things will play out this time, I just gave up about ten years ago and run Windows on my PC. My worry is that the Linux world will get stuck in a cycle of perpetual churn, chasing the One True Perfect Form of Linux and repeat all the same mistakes as Microsoft did twenty-thirty years ago except without the massive funding behind it.
Or put another way, I can no longer trust Free Software. The people writing it have shown over and over again that they do not respect users at all, certainly much less than a commercial vendor does. Idealism trumps practicality in the Free Software world.
Have you tried RequiresMountsFor/WantsMountsFor ? You'd have to create a new unit that just does the bind mount though..
With regards to Windows I use ways from NT era, Windows Vista/7, and Windows 10 to configure Windows, and I bet they added stuff in 11, too. It is a mess, supposedly by a company which makes a super user friendly UI (/s)
NFS is a very simple yet archaic filesystem, with nice throughput, but it comes from a LAN era where LAN clients were trusted. I don't know if it got modernized but I just use SSH over FUSE or CIFS over Wireguard.