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

Torsten Eichstädt torsten.eichstaedt at web.de
Sat Mar 9 11:36:21 PST 2013

Am Freitag, 8. März 2013, 10:56:31 schrieb Rob Messick:
> Torsten, I agree with your points about using shell scripts and the
> advantages of using a common data format and I'm certainly not trying to
> argue against you doing work on PC-BSD.  I believe the work the

Why not? This is a discussion list.  My views might be wrong, 'cause I lack 
some knowlegde or do not have enough background of what has already been tried 
and failed, or what was going on in the past.  That's why I tried to start a 

> would hope that as much configuration would be done outside the
> installer as possible. Other than setting up the loader.conf is there
> much configuration that couldn't be deferred to some sort of
> configuration management tool?  The installer (or other GUI system
> management tools) could write out a set of parameters, in a common data
> format, that would then be applied by the configuration management tool.

.. on 1st boot of the freshly installed system.
AFAIC this is how it's been done right now, and rightly so.

> I do and disable PC-BSD features and have to be extra careful about
> upgrades clobbering my configurations. It would be nice to provide a
> nice easy auditable way for me to hook into the configurations that are
> applied by PCBSDs scripts (maybe there is one that I'm not using?). A
> user could always disable this service.

This is one of my concerns:  PC-BSD is not a pure add-on on top of FreeBSD.  
It changes some important aspects of FreeBSD's (and e.g. KDE's) 
(configuration-) behaviour.

There might be some arguments for doing so, but it also bears risks:
	- you cannot use some of the tools and mechanisms of those SW systems
	  (if you do, you run in trouble)
	- you have to rely on a very small team to provide solid substitutes
	  for the things that are done differently in PC-BSD
	- PC-BSD bears extra effort to adjust and patch more and more upstream
	  modules of FreeBSD and the desktop environments
	- PC-BSD drifts away from FreeBSD and the DEs.

My biggest concern here is that the PC-BSD team is _much_ too small to handle 
all this in a solid and well thought out manner:
	- there's little discussion; naturally, they are only two developers
	- thus they might implement sub-optimal solutions too often
	- some solutions are (and more will be) "quick hacks"
	- thus fragile, not fault-tolerant, not solid, not robust
	- it's not driven by the community, but by a small team of

I'm not saying they do everything bad.  But naturally such a small team will 
miss some important points.  Thus I think it's better to minimize the focus 
and not try to create a new BSD distribution with a team of five: two 
developers, a community & communications mgr, a marketing man, plus a chef who 
keeps the overview.  Correct me if I'm wrong.

> I'm not sure what you mean by "too big" but python is included in the
> base PCBSD system (At least indirectly by the inclusion of py-fail2ban
> in base metapkg). PC-BSD is a significantly fat distribution by most
> standards but I think that can be an advantage because ideas like this
> could be considered.

I had better written "too heavy".  IMHO JavaScript and Lua are much simpler 
and leaner than Python.  For cfg scripts, I consider this a major requirement; 
they should be easy to read and quick to understand by novices.

You gave a good example above, you need to adjust some things to match your 
setup, or find a hook/port to link some custom scripts to.  Even if you're not 
a programmer, you'll have a much better chance to succeed with JavaScript or 
Lua than with Python.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.pcbsd.org/pipermail/dev/attachments/20130309/ba178833/attachment.html>

More information about the Dev mailing list