On Tue, 25 Apr 2006 13:46:58 +0100, Roy Schestowitz wrote:
>> Just as an example, explain to me the absolutely compelling, "cannot ship
>> until it's done" reason for changing the Apache 2 configuration file
>> location from /etc/apache2 to, say, /etc/http/apache2.
> Which not use a command like 'find' or even 'which' for binaries? I agree.
> It's not too hard, but there is also a merit to having consistency, which is
> almost a synonym of standards.
I assume you mean "Why don't you use find..." The issue isn't finding
them _for me_. it's in writing, say, consistent management tools,
configuration applications, and so forth.
In one case, I *always* know where the configuration for Apache will be,
so I only need to write the code to handle the one location. In the other
case, I have to spew all over the drive, looking for files which aren't in
their proper place, and may have even been renamed, for all I know.
Ran across an interesting one yesterday. I've got a lot of Linux desktop
systems about, and every single one of them works in the same basic way as
far as one detail goes. Specifically, if they run the GUI, it's done via
/etc/init.d/*dm. That could be gdm or kdm or simply dm, but it's always
in the same place, for every single distro I've ever run, far as I can
Except yesterday, I ran across a box where it wasn't run from a *dm init
script. Worse, xorg, startx, all the usual haunts, are not referenced in
_any_ of the init scripts.
So, for example, if I wanted to disable GUI booting, I could remove the
file here, or remove the symlinks in, say, /etc/rc5.d. Except the script
that launches the GUI is not in the correct place. In fact, it is nowhere
I can find it.
This sort of crap adds no benefit whatsoever to anyone, and is nothing
more than a pointless way of jumping up and announcing to the universe
"We're too stupid to do things right, so we'll do 'em our way, instead."
>> God, I hate that kind of mindless crap. They can't be happy unless
>> they've peed in the pot. Screw that, there's enough _useful_ things to
>> work on that introducing gratuitous inconsistencies should be grounds
>> for instant banishment to a lifetime of never being able to use
>> anything but Windows ME.
> Actually, not much work is involved in changing of paths and file
Good. So I'll move /etc/http to /etc/apache2. And, of course, everything
from new server modules being installed, to log reporting apps to webmin
will all automagically get the paths right - including upgrading to newer
versions of the software, which will now always put the files in the
_right_ place. Right?
Fine; if it's that easy, there's no reason to fuck it up in the first
place, so the idiot distro jerkwads who have nothing useful to offer can
kindly please take this crap, fold it until it's all sharp corners, and
stick it where the sun don't shine.
> That said, scripts can be broken in the process
So it's not that easy. But these idiots had to break it in the first
place, then "fix" it to use their screwed up paths. The fix is far
simpler: a sledgehammer to the head of the next idiot to try this sort of
> to needed maintenance on the client's end. The cost would be noticed in
> the short term, yet in the _long term_, scripts, skills and
> knowledgebases would becomes more generalisable and widely applicable.
> You can't just ignore the advantage of that. I, for one, disagree.
You're talking about a considerable expenditure of effort and skills
acquisition to solve a *purely manufactured* problem. If these idiots
didn't insist in breaking something that works, your entire notion would
not need to exist _at all_. The correct solution is to educate the idiots
that change is only good when it results in a _benefit_. Not when it's
simply to mark your own territory.
Does moving the apache config files from /etc/apache to /etc/httpd - or
vice-versa - make *anything* work better? Enough to warrant the
completely unnecessary inconsistency this brings between distros? I don't
buy it. Not for a second. It's not a benefit, it's just them peeing in
the pot until they like the flavor better.