Re: The Strengths and Weakness of Fedora/RHEL OS management

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Avi Alkalay <avi@xxxxxxx> wrote:
> Bill Crawford <billcrawford1970 gmail com> wrote:

> > Dunno where you got this obsession, but just because you can represent
> > data as "key/value pairs" doesn't mean that's always the best layout.

> Maybe not for your or my eyes. The best layout is the one accessible
> by the broadest range of ways. Currently, human-readable files are
> accessible by human-beings only, or by configuration file "compilers",
> that are difficult, unique, that nobody wants to write or maintain
> except for the original software writer (e.g. the Samba developer with
> the smb.conf file).

That they do anyway (hell, it is the /only/ way to get the configuration
for the application!) there must be some reason...

[...]

> > There's a reason why programs aren't written for the old Turing
> > Machine, and that's that however well it might be able to represent any
> > possible program, it's incredibly verbose.

> The only reason I can see is historical.

As they asy around here, there is no worse blind than the one who doesn't
want to see...

>                                          Since there is now projects
> integration efforts in the OSS world, everybody uses its own format.

Non sequitur.

> So you may think there is a reason, lost in time, but there is
> actually no reason why BIND named.conf file look that way,

... which is /totally/ different from the format used not that far back...

>                                                            which is
> different from /etc/passwd,

... which has to describe /completely/ different sorts of things...

>                             which is different from smb.conf,

... which is yet different...

>                                                               which is
> different from httpd.conf.

... and again something else completely.

>                            Well, the real reason I can see is selfish
> developers that enjoy rewriting config file parsing code and invent
> configuration file layouts that seems best suited for their apps.

Sure, there are wheel-reinventation-worshippers around, but it is not as
bad as you paint it.

>                                                                   But
> when you strip the syntax fat, they all are not more than key and
> value pairs on a hierarchy.

Really? Or ist it just that everything can be described that way (even if
that is not at all convenient, just as Turing machines aren't nice to
program)?

> So to make the discussion productive, please enlighten us with the
> reasons you think exists somewhere, or please don't speculate.

Please do show you do understand the differences between configurations
syntaxes, and how to overcome them, before you expect us to believe you are
on to something useful...

> > The examples which have appeared in this thread have all made things *less*
> > clear afaics.

> Again, maybe for our human eyes, but are 100% clear for software.

System administrators aren't software.

99% of the problem is understanding /what/ you want to do, and /how/ to do
it with very complex tools subject to all class of non-intuitive
environmental conditions.  Finding out how to read and write the
configuration files is usually trivial in comparison.

Making complex stuff driven by nice "simplified for normal user" GUIs
doesn't make it simple, it just makes it look simple (and the ensuing
breakage isn't nice to contemplate).

>                                                                   And
> the end-goal is leverage better software integration between
> themselves, so we, human-beings, will have to look at configuration
> element everyday less.

This has been the holy grail of system administration from day one. Doesn't
look that much closer today, as the job is getting every day more complex
while the tools desperately play catch-up.
-- 
Dr. Horst H. von Brand                   User #22616 counter.li.org
Departamento de Informatica                     Fono: +56 32 654431
Universidad Tecnica Federico Santa Maria              +56 32 654239
Casilla 110-V, Valparaiso, Chile                Fax:  +56 32 797513

-- 
fedora-devel-list mailing list
fedora-devel-list@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/fedora-devel-list

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Index of Archives]     [Fedora Announce]     [Fedora Kernel]     [Fedora Testing]     [Fedora Formulas]     [Fedora PHP Devel]     [Kernel Development]     [Fedora Legacy]     [Fedora Maintainers]     [Fedora Desktop]     [PAM]     [Red Hat Development]     [Gimp]     [Yosemite News]
  Powered by Linux