Arch has the fewest deviations from "regular" linux of any distribution I've tried, probably because keeping everything as close as possible to vanilla is one of the core principles of the distribution. It still has all the convenience of the one command software install or upgrade, but it doesn't place itself between you and the software once it is installed like so many other distributions do. It's great if vanilla linux is what you've grown up using, it's probably a moot point if you don't default to trying to do things the standard, vanilla way.
I have had other distributions autogenerate and overwrite hand-modified /etc files, and not just system-level ones but even daemon config files! It was something like the distribution required you to edit a distribution-unique "local changes" file for the daemon, not the daemon's actual config file, all so the package manager could incorporate parameters out of some sort of "friendly" config database into a new autoregenerated config file.
Many distributions require that you run a custom command just to do something as stupidly simple as create the /etc/localtime symlink, sometimes even dropping you into a GUI (to create a symlink! Arch is guilty of autocreating this symlink too, but at least it's controlled by a single ASCII line in the distribution's one main distribution-specific config file, rc.conf). Or some distributions have "SysV"-type init systems but require you to use a custom command to handle creating and deleting the symlinks for starting and stopping daemons. Again, usually to allow a package manager to alter those same files without having to figure out what a human has done to them. Those are the sort of "hoops" I'm thinking of.
My complaint's not that those systems exist for people to use, especially if it makes things easier for them, it's just that everyone is forced to use them. Those custom commands/the package manager integration is usually pretty delicate and almost always breaks completely if you try to do things the standard way, without going through them, or if they don't break they stay resilient by silently erasing your changes.
I'm sure there are great advantages to be had by committing fully to a given distribution's custom systems. People managing large or many systems probably find a lot of problems solved by the distributions' custom methods of doing things and the tight integration of those methods with their package managers (but I'm just running a laptop). I'm sure they're also just fine if you first learn how to do a specific configuration change on that distribution, and then don't even need to care what the real output of your manipulations of the distribution's configuration system is.
But if you already know the form of the change you want to happen, the exact line in a config file that you want changed or the exact flag passed to a daemon on startup, it's incredibly frustrating. You have to wade through all of a distribution's weird changes to a piece of software and its added config system layers just to figure out how to mangle your change in such a way that the distribution will unmangle it back into the exact form you could have just edited into the program's config file by hand in 3 seconds.
It's been a long time since I've tried Debian, I don't know what it's like in its modern form, how much you are required to actually cooperate with the distribution's unique systems or if you can ignore them without breaking anything. But the presence of debconf, alternatives, and update-rc.d all sound very discouraging.
I have had other distributions autogenerate and overwrite hand-modified /etc files, and not just system-level ones but even daemon config files! It was something like the distribution required you to edit a distribution-unique "local changes" file for the daemon, not the daemon's actual config file, all so the package manager could incorporate parameters out of some sort of "friendly" config database into a new autoregenerated config file.
Many distributions require that you run a custom command just to do something as stupidly simple as create the /etc/localtime symlink, sometimes even dropping you into a GUI (to create a symlink! Arch is guilty of autocreating this symlink too, but at least it's controlled by a single ASCII line in the distribution's one main distribution-specific config file, rc.conf). Or some distributions have "SysV"-type init systems but require you to use a custom command to handle creating and deleting the symlinks for starting and stopping daemons. Again, usually to allow a package manager to alter those same files without having to figure out what a human has done to them. Those are the sort of "hoops" I'm thinking of.
My complaint's not that those systems exist for people to use, especially if it makes things easier for them, it's just that everyone is forced to use them. Those custom commands/the package manager integration is usually pretty delicate and almost always breaks completely if you try to do things the standard way, without going through them, or if they don't break they stay resilient by silently erasing your changes.
I'm sure there are great advantages to be had by committing fully to a given distribution's custom systems. People managing large or many systems probably find a lot of problems solved by the distributions' custom methods of doing things and the tight integration of those methods with their package managers (but I'm just running a laptop). I'm sure they're also just fine if you first learn how to do a specific configuration change on that distribution, and then don't even need to care what the real output of your manipulations of the distribution's configuration system is.
But if you already know the form of the change you want to happen, the exact line in a config file that you want changed or the exact flag passed to a daemon on startup, it's incredibly frustrating. You have to wade through all of a distribution's weird changes to a piece of software and its added config system layers just to figure out how to mangle your change in such a way that the distribution will unmangle it back into the exact form you could have just edited into the program's config file by hand in 3 seconds.
It's been a long time since I've tried Debian, I don't know what it's like in its modern form, how much you are required to actually cooperate with the distribution's unique systems or if you can ignore them without breaking anything. But the presence of debconf, alternatives, and update-rc.d all sound very discouraging.