[PC-BSD Dev] RFC: Choice of a Less Error-Prone Scripting Language for Configuration Scripts + Standard Data Format
torsten.eichstaedt at web.de
Fri Mar 8 04:10:58 PST 2013
Rob, you don't have to quote such a long mail back to the list ;)
[When I speak of "all", "none", "everyone" etc. it should be clear that every
rule has it's exceptions. That's a philosophical question]
Am Donnerstag, 7. März 2013, 17:23:23 schrieben Sie:
> I would love to see a tool that could be used to apply and manage
> custom configurations on one or many PCBSD machines.
Yes, that's desirable for any networked pool of computers and that's why it is
a multi-billion-$ market and that's why thousands of suites exist and that's
why I do not propose to weave SNMP (note the leading "S") or CORBA or XML or
[you name it] into the PC-BSD cfg-mgmt.
The focus I'd like to keep is the configuration & installation
scripts/tools/backends of PC-BSD. They're much too _fragile_. And that's not
because the programmers are dumb or lazy, the root cause are the inherent
weaknesses of the programming language and data formats used.
Rob, if some (inclusion of existing) standards and guidelines get agreed upon
the PC-BSD developers, will you join? Or are you already one of those?
The point is: you can -- and will -- still make mistakes in a more advanced
language, handling advanved data formats. But the chance to detect trivial
flaws is higher. The chance to make flaws is lower. Mature libraries to
handle the data in a secure and robust way are available. And shell scripts
are hard to re-use, the language was not made for that. It's good for quick,
specialized, _small_ solutions. Not more. To get an ad-hoc solution to work
is often fastest with it. But after a certain point related to project size
and complexity, development velocity slows down rapidly, and, much more
important, robustness goes _backwards_.
Look through the bug-tracker and the forums, if you didn't stumble over nasty
bugs yourself. Three examples, in realitas the list contains well over a
hundred bugs, and all have at least the following in common:
- improper string handling:
Inherent weakness of shell scripts
- lack of exception handling:
Too complicated in shell scripts
There just is no "try-catch-throw" you could use
- lack to check the validity of tacit assumptions:
too complicated in shell scripts
- Some tool/backend, don't know which one, writes empty lines into
[string handling, inproper data file & format handling]
Most probably just a simple, small flaw, but with high risk. It's one
of the most important system config files that's affected here.
It is _pure_luck_ that the file is not emptied or scrambled completely
by this bug.
- The installer fails when you change any of the properties of the ZFS
root FS ("no root FS")
[string handling, lack to check tacid assumtions]
- The installer & the user manager fails when your ZFS layout differs from the
built-in, _hard_coded_ defaults (e.g. tank/home mounted on /usr/home).
[string handling, bad programming style, lack to check tacid a.]
But with the capabilities of shell scripts, you're tempted to do so
because a correct solution would be _much_ more complicated. With
advanced string handling capabilities, the correct solution would be
just a few more lines of code.
I've quickly read over some of the scripts. Thus I'm convinced that their
authors _do_ know about the basic principles of programming. It's just that
if you give a goldsmith a carpenter's hammer, he can't make you an earring.
> Why re-invent the wheel? There are quite a number of configuration
> management solutions out there that have a head start on this task. We
> use puppet at work but are working on switching towards salt
> (http://saltstack.com/community.html), an MIT licensed configuration
> management and remote execution framework written in Python. Salt uses
Guess what, (some of) the main backends of IBM Tivoli are written in Prolog!
That's one of my favorite programming languages ;) -- seriously, I love it!
But I'm clever enough not to propose that for basic cfg mgmt. Who knows,
maybe in 50 years it'll be common to do so.
The main focus of PCBSD install & cfg is _basic_ configuration of a _single_
computer. Hopefully iXsystems is not building up a nice botnet with PC-BSD ;)
Of course there's an automated install. But I'd say that most companies &
institutions who want to integrate a pool of FreeBSD/PC-BSD clients already
have a heterogeneous network as well as some of the various cfg-mgmt suites.
It wouldn't be wise to ship them one more. If they do not have one already,
they probably want to choose themselves.
I'm certainly not the Napoleon Bonaparte of Software Engineering. But
frankly, I did not propose Python on purpose. It's too big. Debuging
"built-in" QML. Anyway, the debuging capabilities of shell scripts are very
limited, too ("set -x").
IMHO it's vital to mind the KISS principle and stick to something simple, but
powerful enough to provide better string- and exception handling,
modularisation, re-usability, and test capabilities.
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Dev