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