[PC-BSD Dev] RFC: Choice of a Less Error-Prone Scripting Language for Configuration Scripts + Standard Data Format

Torsten Eichstädt torsten.eichstaedt at web.de
Fri Mar 8 04:10:58 PST 2013

Hello everybody!

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 
Qt+Python is a mess -- ok, maybe that's not much better with JavaScript or 
Lua, but I expect some usable capabilities at least for JavaScript 'cause it's 
"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...
URL: <http://lists.pcbsd.org/pipermail/dev/attachments/20130308/14e696a3/attachment.html>

More information about the Dev mailing list