Does it have a use case other than being a hobby distro.
Well, yes...
The whole back end of our shop runs arch linux. Server, parts, technicians machines, the service dept. Has for about 6+ years now. I did that when It finally became my responsibility.
The front part, the customer service area, and the office people have to have windows, I'm sure that you know that routine. Trying to get them to use something other than windows...forget it.
And the Arch machines are trouble free. And that is do to the shop part being technical people with brains that work, and know how to use a puter, and Arch sits there and works. The only time I concentrate on the arch machines is during a whole shop update. And I do that on Saturday, or when no one is there. You could get a surprise there. But even that is only with 1 machine ususally because of hardware or a kernel something.
The windows machines(10) always have problems, and that's do to them being microsoft machines, and no technical brained people in front. Does make a big difference.
]]>]]>I did not want to sound like a troll.
Yes.
]]>Convincing the team to embrace Linux was easy -- When I inherited the project, it was Windows 7 based (not a domain, just non-enterprise workstations) and neigh unmanageable. They had been bridging wired and wireless networks and it almost worked a majority of the time. Most of the network issues vanished when we went to Linux, created rational routing rules, and implemented NAT to route between networks rather than trying to create one gigantic subnet.
And, once we have a working solution, we tend to lock it down then give it to the Information Assurance guys to do their penetration testing test. Once they approve of our images, we don't change anything anyway making the issue of being a rolling release moot. I should also note these are private networks that are not connected to the public internet.
]]>What this gives me is predictable upgrade sequence at all times with instant, 100% working roll back. Lets say I started an upgrade and it went to shits - no worries. I try and fix it if I can. If I can't - roll back btrfs snapshot, get the system back online - go figure out the issue on my own schedule. If answer is found, I can try upgrade and fix again, if not - sometimes i just wait a few releases and try again. Sometimes i'd spin up another instance, btrfs send the whole disk and try the upgrade somewhere else - in a safe testing environment.
Even when the issue is tricky - lets say upgrade went fine, but then in a couple of weeks we have noticed something is off. Still not an issue. In one case I just copied the latest database to a 2 week old snapshot, started everything up and it was working 100% for another month while we were figuring out the issue neatly planned fix tickets in sprints.
I never have to maintain this on weekends, evenings, nights, etc. I always have plenty of time to figure things out, test them on and off site. I have options to roll-back, wait, or do whatever. In a majority of cases the issue I am trying to fix is incremental, trackable and... currently discussed on Arch forums or posted about on Arch blog. Once it is fixed - it doesn't come up again.
We are not a big company by any means, just a bunch of remote devs doing things. But everywhere I worked before, all those RHEL and Oracle super stable systems - every other production release is a freaking forest fire. Companies with continuous deployment fair better, but you still log in on weekends. Rolling distro in production done right works, but in a context of large organization -- i don't think it has ever been tried. In any case, it may not work due to organizational and complexity issues (100s of servers to maintain is not the same as 5), but from purely technical perspective rolling on the server is far superior IMHO.
]]>@steam deck running Arch: Steam Deck doesn't run Arch, it runs something that's based on Arch called SteamOS 3.0.
]]>Also, with the advent of containers, there's little, to no reason, to not use the distro you want on a professional setting. I develop software on Arch, use containers varying from debian to alpine, passing through Arch itself, and I can be productive. Also, thinking about corporate usage of Arch, there are several companies using it too, as servers. It depends much more on your workflow, than on which distro you use.
Finally, we're about to have thousands of devices deployed by Valve running Arch Linux. So, easy up with the loaded questions and answering your own questions, and try to evaluate this with the proper mindset.
]]>So which is more stable, a flat path leading to a cliff, or a constant smooth incline. I'd never want to use a non-rolling release distro on a server unless I knew for sure that the whole purpose of the server would sundown prior to the EOL of the distro selected ... so, you could say I'd see Debian could be ok for, you know, some little hobby project.
In case the tongue-in-check mockery of the "hobby" characterization isn't obvious, I have absolutely nothing against Debian. I don't have much experience with it, but have every reason to think highly of it. But 1) it's not for me, and 2) I resent the patronizing implication that Debian would be for professionals and Arch for "toys" or "hobbies" and hope that presenting my argument for the opposite highlights how that is both incorrect and inappropriate.
]]>$ mysql -u hwdb -p hwdb
Enter password:
Reading table information for completion of table and column names
You can turn off this feature to get a quicker startup with -A
Welcome to the MariaDB monitor. Commands end with ; or \g.
Your MariaDB connection id is 148239703
Server version: 10.5.12-MariaDB-0+deb11u1 Debian 11
Copyright (c) 2000, 2018, Oracle, MariaDB Corporation Ab and others.
Type 'help;' or '\h' for help. Type '\c' to clear the current input statement.
MariaDB [hwdb]> select count(*) from system where system.operating_system = 'Arch Linux';
+----------+
| count(*) |
+----------+
| 1291 |
+----------+
1 row in set (0.002 sec)
MariaDB [hwdb]>
To get some perspective:
MariaDB [hwdb]> select count(*) from system where system.operating_system = 'Windows 10';
+----------+
| count(*) |
+----------+
| 21 |
+----------+
1 row in set (0.001 sec)
MariaDB [hwdb]>
Back in the day when I selected the OS for our newest-generation digital signage systems, I deliberately chose Arch Linux, because it has a stable community, is rolling-release and uses binary packages.
I decided against Debian and CentOS due to their limited lifecycle and scalability and against Gentoo because... compiling.
But Debian is _much_ more stable.
That is… objectively correct, congratulations. Debian is stable, Arch is rolling.
I know what are you going to say. "I use Arch in my home server. It never broke on me". But on the other hand, more people prefer to use more stable distros like Debian on servers.
Depends on the use case.
Personal use? I will prefer Arch in almost all cases because it's the distro I know best (and therefore know best how to pull it out of the swamp if it ever breaks). And version stability is not something I'm too concerned about, so rolling is fine for me.
Enterprise use? It's usually not up to me to choose the distro anyway. And there we're in the World of RHEL and SLES and Oracle and… yes, occasionally Debian.
Does it have a use case other than being a hobby distro.
Yes. There's other use cases than "hobby systems" and "critical, productive server environments", after all.
(It is _not_ a rant, it is a question)
To be honest, it feels mostly like a trolling attempt.
]]>But Debian is _much_ more stable.
Not for me it wasn't. But if you feel it is, then go use Debian. You've asked a loaded question implying from the outset that anyone who uses arch professionally is in the wrong, and then you asked for a show of hands of which people you've labeled wrong.
I'm one of them. Judge me as you wish.
]]>