Date: Sat, 14 Apr 2001 16:15:02 -0500 From: Mike Meyer <mwm@mired.org> To: Joseph Mallett <jmallett@newgold.net> Cc: John Baldwin <jhb@FreeBSD.org>, FreeBSD Chat <chat@FreeBSD.org> Subject: Re: Just an observation - MUA's seen in the lists Message-ID: <15064.48598.415646.715767@guru.mired.org> In-Reply-To: <Pine.BSO.4.21.0104141636440.5404-100000@aphex.newgold.net> References: <XFMail.010414133447.jhb@FreeBSD.org> <Pine.BSO.4.21.0104141636440.5404-100000@aphex.newgold.net>
next in thread | previous in thread | raw e-mail | index | archive | help
Joseph Mallett <jmallett@newgold.net> types:
> Yes but if it's done in Windows(tm) it's a Bad Thing (sm), however when a
> Unix does it, moreover, FreeBSD, it's known as centralising configuration.
And if it's done on Unix (tm) the way it's done on Windows (tm), it's
still a Bad Thing (sm). The problem with the registry isn't that it's
a central repository. There are two problems with the implementation.
The first problem is that *everything* is in it, including information
critical to booting the system. If that's sufficiently screwed up, you
can't get the system to a point where you can use the tools required
for dealing with it's binary format running to fix things. That leaves
you SOL.
I could, similarly, put all the Unix config files in an SQL
database. If the system got so fried I couldn't start the database,
I'd be in a *bad* way. Having everything in flat text files may not be
as convenient, but it means I can fix the things with nothing more
than a statically linked copy of ed.
> Imagine having to do this to back up configuration:
> find / -name '*.conf' -exec cp {} /backup/ ';'
> And then imagine restoring everything to its proper home.
> And then imagine all the files you missed because application X decided it
> didn't want to name its files with .conf, X11 comes to mind.
Yup - having a lot of undocumented .ini files that you frob with
point-n-click tools is bad becase, as you so aptly illustrated, you
don't know where they are because you normally use the point-n-click
tools to edit them. This makes them hard to find to fix if things are
broken to the point the that those tools aren't working. The Registry
has replaced those files with a bunch of undocumented registry
variables that have the same problems, with the added problem that you
can break things so badly that you can't edit them even if you know
where they are.
The config files on Unix have or at least can be - horror of horrors -
edited by hand. As a result, every configuration file on all my unix
systems is either in the state it was installed in, or backed up in my
perforce server. The exception is the password file, and the crontab
files in /var/cron, because those break don't follow that rule.
While some people call the results of hiding the information you need
to fix things behind GUI interfaces "user-friendly", I'd say that
"idiot-friendly" is more appropriate, as it assumes the user is an
idiot who can't fix things anyway. I don't think the public is that
stupid, and even if I'm wrong, hiding that information from users who
aren't idiots isn't friendly to those users.
> Anyway, it isn't bad, it's a good, efficient idea, or at least, the best
> one someone's found that I know of, or at least, that Microsoft/Unix/Apple
> would care to use.
Yup, it's a good, efficient idea. It's the MS implementation that's
FUBAR.
<mike
--
Mike Meyer <mwm@mired.org> http://www.mired.org/home/mwm/
Independent WWW/Perforce/FreeBSD/Unix consultant, email for more information.
To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-chat" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?15064.48598.415646.715767>