
Boiling frog, or when did we lose it with /etc? - vezzy-fnord
http://blog.surgut.co.uk/2015/03/boiling-frog-or-when-did-we-loose-it.html
======
Someone1234
Everyone always gives the Windows Registry guff. But while I think the Windows
Registry has a lot of problems, it also is a step forward on the mess if
incompatible configuration files found within /etc (and /usr/local/etc) on
your average modern UNIX-like OS. And now you're seeing tooling, like Docker,
which is specifically designed to isolate the mess around each mess-user
(essentially creating a bundle of mess).

The whole filesystem layout is pretty poor, with massive amounts of
inconsistencies (/bin, /sbin, /usr/bin, /usr/local/bin, /usr/local/sbin)
between different software and even distributions. So you just wind up with
everything scattered all over the place, and package managers exist
essentially to corral the mess.

Everyone loves to talk about how UNIX is simple, and how UNIX concepts date
back to at least the 1970s, and while that is true in theory, in practice the
inconsistent behaviour and lack of much evolution has ultimately meant that
UNIX's simplicity doesn't scale very well as the systems become more complex
with more moving pieces.

But nobody is willing to touch or even criticise the mess that is modern UNIX
because they know they will get massively criticised by the old guard and the
die hards (see systemd, which is trying to evolve classic UNIX concepts and
getting massively attacked, even death threats as a result).

Windows' file system is also a mess. But at least Microsoft are trying
something with Windows RT "Apps," at least they're trying to move forward and
progress. The UNIX world is in cryogenic suspension, even Apple has only
hidden a lot of the mess and not really fixed much of it.

~~~
vezzy-fnord
_But while I think the Windows Registry has a lot of problems, it also is a
step forward on the mess if incompatible configuration files found within /etc
(and /usr/local/etc) on your average modern UNIX-like OS._

Not really. You have certain apps using the file system and others that use
the highly limited key-value quasi-file system that is the Registry. There is
no single point of truth at all.

 _see systemd, which is trying to evolve classic UNIX concepts and getting
massively attacked, even death threats as a result_

Yeah, that flame war's pretty visceral, but there's plenty of reasons systemd
gets criticized (chief of which is the perception that it in fact _devolves_
classic concepts).

 _Windows ' file system is also a mess._

Windows' file system hierarchy is an _enormous_ mess far surpassing the FHS in
Unix. /etc/hosts vs C:\windows\System32\drivers\etc\hosts. Enough said. The
FHS at least has _some_ semantic meaning that is more-or-less consistent or
can be easily deduced, but Windows is just a hodgepodge.

 _The UNIX world is in cryogenic suspension_

No, there's many people who are trying new approaches. The problem really
isn't the use of a hierarchical file system, it's the lack of semantic
categorization of configuration locations.

~~~
TazeTSchnitzel
> The FHS at least has some semantic meaning that is more-or-less consistent
> or can be easily deduced, but Windows is just a hodgepodge.

Really?

C:\Windows - Windows itself

C:\Program Files - Applications

C:\Users - User data

~~~
johnchristopher
It seems clearer but when you install wamp or xampp you'll find a php.ini in
c:\wamp\apache and c:\wamp\php (or sthg).

Nice names (be it /etc or C:\Users) don't prevent developers to put their
config file wherever they can read it.

Usually in C:\Users\Alice\Ubisoft if they are in the game business.

Or C:\Program Files\Steam\Steamapss if they are in the game business.

~~~
wvenable
Talking about where PHP (a unix program) puts it's configuration on Windows is
hardly a valid point. Even on Linux, that sucker can be hard to find. On my
Linux server it is at least 5 levels deep and I have to run phpinfo() just to
find it.

~~~
johnchristopher
> Talking about where PHP (a unix program) puts it's configuration on Windows
> is hardly a valid point.

That's because it's not my point but an example of "it's up to the dev to be
consistent or to follow the platform's guideline" which is my point along and
with "`Program Files' is a nice folder name but you are going to find some
user configuration files in there'".

If I remember correctly Foobar asks you when installing where to put its
configuration files: user home, or program files. It should not. It should be
in C:\Users\Alice\Local Settings (or was it LocalApps ?).

~~~
chinpokomon
There are guidelines for where developers are supposed to store configuration,
and since Vista, it isn't in Program Files. In fact, making changes in Program
Files is restricted to the System, or elevated processes. It is often times an
indicator that a program is violating accepted practices if it requires
elevation of privilege to run. Changes like that are supposed to be stored in
the users AppData directory.

For backwards compatibility. Vista and descendants provides a virtualized
space where writes to restricted directories are allowed, but they are
committed to a different isolated space on the disk, preventing a rogue
program from, modifying files for which it should not have access.

Neither Windows or Linux are perfect in this respect, but for a decade,
Microsoft has been trying to unify how applications store user specific data
and configuration. There are still ways for developers to abuse the system,
but they are considerably restricted from the most glaring mistakes and in
general it has gotten better with each revision.

------
ekidd
From the article: _When was the last time you looked at /etc and thought - "I
honestly know what every single file in here is". Or for example had a thought
"Each file in here is configuration changes that I made"._

I first started administering Linux servers and workstations in 1998, and
/etc/ was already full of scores of config files, including such horrors as
X86Config and M4-generated sendmail.cf files. (And sendmail.cf itself dates
from the 80s.) There were conf.d directories and mysterious networking
configuration files, nearly all of which were supplied by the OS.

In other words, this frog was thoroughly boiled 20 years ago. If the world
you're looking for ever existed, it would have been back when VAXes still
roamed the earth.

~~~
nailer
Ditto. My name's likely in your Linux distro, but I also started in 98, and
even then you would _never_ expect a given package to work without default
config files.

------
cosarara97
When did blogs start showing a 'loading' screen, then doing a weird scroll
thing at load, and having stuff unfolding near the scrollbar?

~~~
stephengillie
When they got bloated down by designers trying to reinvent HTML 1.1 in
Javascript.

This page won't show with Javascript disabled, and that's a shame. There's
nothing on that page that can't exist as flat HTML. There's nothing on that
page that requires Javascript, but the page won't function without it for some
reason.

Do we still downvote/flag comments that aren't directly related to the content
of the linked material?

~~~
JustSomeNobody
Have an up vote. I get down voted every time I complain about the
javascriptification of the web.

------
ars
Having no files in /etc is considerably less discoverable.

It can be handled with good documentation or example files in /usr/share/doc
but it's still harder that way.

Of course there are downsides that this article brings up. But is the problem
simply the existence of a file in /etc ? Because that doesn't seem to be a
problem to me, instead the problem is upgrades that are harder because they
have to merge changes.

Seems to me the solution is to use 3 way diffs like how source control system
do it, and update configuration files automatically as much as possible.

~~~
joosters
I love the discoverability of /etc files, and the ability to read & edit them
with whatever tools you like. If the files only included changes to default
settings, and the defaults are hidden away in program binaries, how are we to
discover what settings even exist in the first place?

Verbose /etc config files are human-friendly and that's a good thing. Managing
updates and merging config changes is still do-able. The logic to do the
merges might be more complicated, but I'd rather let the complicated stuff be
handled by the upgrade tools and not forced upon the user.

------
felixgallo
The desktop linux dudes sure do pick weird topics to get excited about.

First it was cold boot time, resulting in the hilarious neverending clown
rodeo that is systemd.

Then it was that they didn't understand IPC, so it was the gloriously
undesigned protocol 'dbus' which has to get wedged into the kernel because the
user space version is so bad that it's useless.

Now it's that there's a number of config files in /etc? And so we should take
that number down to zero, because reasons?

Can't wait for them to discover that bytes are 8 bits, rather than a more
pleasing 5 or 10.

~~~
Shorel
Hey!

I love my Ubuntu cold boot time of less than a second.

~~~
digi_owl
And then spend a minute watching the unresponsive desktop because all the
deferred daemons being started?

~~~
Shorel
Not really. I click on Skype and it's three seconds until all contacts appear,
and those seconds can be blamed on the network.

The only thing that loads slowly is Chrome with my 50 open tabs, and I don't
think it's the fault of the OS.

In the same hardware what you describe actually happens every time with
Windows 7 (I can't upgrade the Windows version, corporate policy) and it's a
really annoying process.

------
protomyth
OpenBSD has been reducing the files in the directory. I was in a bit of a
panic when I noticed sysconfig.conf was missing. Now if you need to change the
settings you add a local file.

~~~
agumonkey
Every time I read about BSDs I wanna try. The core team appear to make a
coherent cohesive tractable system. Unlike the bazaar model used by Linux
(intractable but working).

~~~
c22
Why not give it a shot? Running BSD is a low cost proposition.

~~~
agumonkey
I don't know, the fear of hardware support, some random source of resistance
that delay it. I'm sure one day I'll switch, just like when I told that old
friend Windows he'd only be 3% of my computer time now. Right now I have a
crippled nas4free running but I can't mess with the system too much. I'm
already surprised to see subtle differences between linux base utilities.
Makes you think. Also feels like LFS.

~~~
c22
Try it out in virtualbox? Even less investment.

~~~
plorkyeran
Doesn't tell you if your hardware will work with it, and it's too easy to just
switch to the host OS when you hit something you don't know how to do rather
than having to learn how to do it in the OS you're trying out.

------
andmarios
Sorry, no. Even if it is the default configuration I want to know it, see it
and be able to manipulate it whether it is my 1st or 100th time of configuring
a particular software.

What puzzles me most, is why one would spent so much time looking inside /etc.
Editing files inside /etc? Sure, many times per day. Opening /etc inside a
file manager? Never. Running ls inside /etc? Maybe once a month.

------
5bolts
its not even just a windows / unix thing.. my software company can't even pick
a method.

registry keys .exe.config files .xml files .ini files .cfg files

true false entries, bitwise operators... custom "hosts" file type configs

all for one application... each developer that gets an enhancement uses
whatever they want to to build/configure it.

------
gtirloni
Is there anything out there trying to describe a whole system in a consistent
way? Probably not, but some minimal standard would go a long way.

For me the fact that each software has a different syntax (some even use
programming language for configuration purposes) is what makes life hard.

~~~
fineIllregister
NixOS

> In NixOS, the entire operating system — the kernel, applications, system
> packages, configuration files, and so on — is built by the Nix package
> manager from a description in a purely functional build language. The fact
> that it’s purely functional essentially means that building a new
> configuration cannot overwrite previous configurations. Most of the other
> features follow from this.

> You configure a NixOS system by writing a specification of the functionality
> that you want on your machine in /etc/nixos/configuration.nix.

[https://nixos.org/nixos/about.html](https://nixos.org/nixos/about.html)

and

GuixSD

> The Guix System Distribution supports a consistent whole-system
> configuration mechanism. By that we mean that all aspects of the global
> system configuration—such as the available system services, timezone and
> locale settings, user accounts—are declared in a single place. Such a system
> configuration can be instantiated—i.e., effected.

> One of the advantages of putting all the system configuration under the
> control of Guix is that it supports transactional system upgrades, and makes
> it possible to roll-back to a previous system instantiation, should
> something go wrong with the new one (see Features). Another one is that it
> makes it easy to replicate the exact same configuration across different
> machines, or at different points in time, without having to resort to
> additional administration tools layered on top of the system’s own tools.

[http://www.gnu.org/software/guix/](http://www.gnu.org/software/guix/)

[http://www.gnu.org/software/guix/manual/html_node/System-
Con...](http://www.gnu.org/software/guix/manual/html_node/System-
Configuration.html)

