Linked by Thom Holwerda on Mon 24th Sep 2007 21:52 UTC, submitted by Oliver
PC-BSD "The PC-BSD team is pleased to announce the availability of PC-BSD 1.4 (da Vinci edition)! This release is made available via the efforts of many developers and testers, who have spent the past months refining and improving upon the core PC-BSD experience." This release comes with Xorg 7.2, KDE 3.5.7, Compiz-Fusion 0.5.2, support for Flash7, and much more. There are release notes, a changelog, and downloads.
Thread beginning with comment 274289
To view parent comment, click here.
To read all comments associated with this story, please click here.
RE[3]: The future of PC-BSD
by stestagg on Tue 25th Sep 2007 17:19 UTC in reply to "RE[2]: The future of PC-BSD"
stestagg
Member since:
2006-06-03

Your sarcasm is misplaced. I don't dispise GUIs, I use a nice modded version of XP for day-to-day work and for 95% of computer usage, graphical tools are good.

But for security critical applications that are based on textual configuration files, abstracting the configuration is A BAD THING. A bit like relying on autopilot for airplanes. It's ok ONLY as long as you have a fully qualified pilot sitting ready to get his/her hands dirty.

Reply Parent Score: 4

RE[4]: The future of PC-BSD
by Morin on Tue 25th Sep 2007 19:27 in reply to "RE[3]: The future of PC-BSD"
Morin Member since:
2005-12-31

> But for security critical applications that are based on textual
> configuration files, abstracting the configuration is A BAD THING.

But who said "abstracting"? If you have an option in the config file that can be set to either "yes" or "no", then a check box in a GUI dialog will give you the exact same choice. Result: The user can use a GUI, need not remember the config file syntax, and concentrate on the essential stuff. A lot of configuration files can be treatet this way.

Of course, some configuration formats feel more like scripting languages than simple (declarative) settings, in the sense that they rely on step-by-step interpretation and massive internal state of the interpreter (e.g. local variables, or even sub-procedures). But then, if the application programmer insists on blatantly violating the KISS principle, he/she shouldn't be doing security-related programming anyway.

Reply Parent Score: 3