libUCL / UCL as FreeBSD config question

Dan Partelly dan_partelly at rdsor.ro
Tue Dec 1 10:11:53 UTC 2015


>  I continue to adminster my Macintosh
> systems via "sudo" from a shell window, because the result makes
> sense.

And Windows is often administered with powershell. I think the result also make 
“sense”.

> 1) convenient

Convenience is the only advantage of text files. It is often easier/more ingrained  to 
just vi /etc/rc.conf than using a tool  sysrc(8) to adminster it. But sysrc(8) exists for
a reason. It is safer to use. And , I personally would trade some convenience for
atomicity and transactions any time of the day.

> 2) comprehensible

I think all systems are equal comprehensible. Practically, there is 0 difference 
between the human readbale format you see in a text file, and the output of 
system tools. They do output text for most of the information.

> 3) backwards compatible (upgrading from before isn't a PITA) 

When talking about OS databases, backwards compatibility means —
keep the same language. Using a different language than the one in which 
the ad-hoc databases are specified today (a language with no formal specification)
will automatically break backwards compatibility.  Various levels of PITA will 
always exist.

> 4) forwards compatible (I don't have to reprogram my brain every other release) 

All solutions are forward compatible if minimal good engineering  principles are applied.
You can break a text based databases in countless way and ditch compatibility as easily 
as you can doit for binary databases.

> 5) accessible when the system is somewhat crippled (single user mode
> after a failure)

implementation detail. Are sane solutions are implemented this way.

> It's doubtless possible to design a non-text system that provides the
> benefits that text based systems get for free.

It is indeed possible. But as far as text files goes, the only advantage IMO is on the 
lines of convenience. All others are just biases. The future is IMO a web of 
interconnected machines at different scales, a world where issues of 
concurrency - the ability to guarantee atomic and transactional aceeses to
 OS databases - is increasingly important. 

Traditional OS databases in Unix do not have a special language, but they are easy 
to understand and humanly read. UCL is both easy to to humanly and machine read.
If introduced in freeBSD , the only thing it would accomplish is uniformity of language,
and easier programtic access. (and this is desirable and by all means no small feat). But 
thats where any advantage  stops. Nobody in this UCL for FreeBSD woking group seems 
to have thought at the future,  and did not posed any questions  regarding concurrency and 
transactions.

It’s the same as with the init system. There is a  working solution , which is a glorified 
autoexec.bat. It doesnt offer any real facilities to monitor services,  configure actions to be take
on faults, log faults, manage cron jobs and their lifecycles and the list can go on and on.

In my opinion 3 areas in BSDs  are problematic and coherent, future proof , solutions to those 
problems must be found:

1.  OS services system (service management, fault management, reporting , cron management ) 
2.  OS configuration. Powerful OS databases and system management demons.
3. Binary code reuse.  IMO key utilities in base should be lib-ified , and frameworks of libs should be built over
key system demons (config demons, fault management demons, log demons, systemwide 
notification demon (funnelling from multiple sources , as devd, file system events, service fault events, service 
normal lifetime events.



> On 01 Dec 2015, at 01:22, Arlie Stephens <arlie at worldash.org> wrote:
> 
> On Nov 24 2015, Dan Partelly wrote:
>> A proper solution might need kernel support,and quit using text
>> files for OS config.  Hence IMO a proper solution has very few
>> chances  to be implemented.  Most people seem to have some fetish
>> with text files, and  like to be stuck in past.  It is like somehow
>> magically .txt files are immune to corruption, but any other format
>> is not. 
> 
> Ugh!  Text files tend to make things human comprehensible, in ways
> that configuration tools do not.  I continue to adminster my Macintosh
> systems via "sudo" from a shell window, because the result makes
> sense.
> 
> Show me a system that's 
> 1) convenient
> 2) comprehensible
> 3) backwards compatible (upgrading from before isn't a PITA) 
> 4) forwards compatible (I don't have to reprogram my brain every other release) 
> 5) accessible when the system is somewhat crippled (single user mode
> after a failure)
> 
> And I might get over my "fetish" for text files.  
> 
> And for the record, I've used various "registry" solutions to kernel
> config., notably the one added to HPUX around about their 11.0, and
> even developed code that used this system. 
> 
> It's doubtless possible to design a non-text system that provides the
> benefits that text based systems get for free. Unfortunately, I've
> never seen such a system where that remained a consistent priority. 
> 
> -- 
> Arlie
> 
> (Arlie Stephens					arlie at worldash.org)
> _______________________________________________
> freebsd-hackers at freebsd.org mailing list
> https://lists.freebsd.org/mailman/listinfo/freebsd-hackers
> To unsubscribe, send any mail to "freebsd-hackers-unsubscribe at freebsd.org"



More information about the freebsd-hackers mailing list