Date: Tue, 1 Dec 2015 12:11:44 +0200 From: Dan Partelly <dan_partelly@rdsor.ro> To: Arlie Stephens <arlie@worldash.org> Cc: freebsd-hackers@freebsd.org, Allan Jude <allanjude@freebsd.org>, Mark Heily <mark@heily.com> Subject: Re: libUCL / UCL as FreeBSD config question Message-ID: <1912F461-882E-462A-A3C6-6BC1A15D4353@rdsor.ro> In-Reply-To: <20151130232235.GA11581@worldash.org> References: <5B598F72-C5DD-48FD-866D-F90E117D646E@rdsor.ro> <564F6118.5030702@freebsd.org> <5576AC9A-791F-4B52-9433-32D2806D35C9@rdsor.ro> <564F8E1F.8060600@freebsd.org> <CE91041D-0888-412D-BCBA-448A874D38BA@rdsor.ro> <CAGfo=8nMqnwM5%2Bys3oA5NXpMHP7wbW3jDPPS6wus7SjD57dcLQ@mail.gmail.com> <663FAC89-8B0B-4E20-85F2-36C346A3AC73@rdsor.ro> <20151130232235.GA11581@worldash.org>
next in thread | previous in thread | raw e-mail | index | archive | help
> 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=20 =E2=80=9Csense=E2=80=9D. > 1) convenient Convenience is the only advantage of text files. It is often easier/more = ingrained to=20 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=20 between the human readbale format you see in a text file, and the output = of=20 system tools. They do output text for most of the information. > 3) backwards compatible (upgrading from before isn't a PITA)=20 When talking about OS databases, backwards compatibility means =E2=80=94 keep the same language. Using a different language than the one in which=20= the ad-hoc databases are specified today (a language with no formal = specification) will automatically break backwards compatibility. Various levels of = PITA will=20 always exist. > 4) forwards compatible (I don't have to reprogram my brain every other = release)=20 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=20 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=20 lines of convenience. All others are just biases. The future is IMO a = web of=20 interconnected machines at different scales, a world where issues of=20 concurrency - the ability to guarantee atomic and transactional aceeses = to OS databases - is increasingly important.=20 Traditional OS databases in Unix do not have a special language, but = they are easy=20 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=20 thats where any advantage stops. Nobody in this UCL for FreeBSD woking = group seems=20 to have thought at the future, and did not posed any questions = regarding concurrency and=20 transactions. It=E2=80=99s the same as with the init system. There is a working = solution , which is a glorified=20 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=20 problems must be found: 1. OS services system (service management, fault management, reporting = , cron management )=20 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=20 notification demon (funnelling from multiple sources , as devd, file = system events, service fault events, service=20 normal lifetime events. > On 01 Dec 2015, at 01:22, Arlie Stephens <arlie@worldash.org> wrote: >=20 > 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.=20 >=20 > 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. >=20 > Show me a system that's=20 > 1) convenient > 2) comprehensible > 3) backwards compatible (upgrading from before isn't a PITA)=20 > 4) forwards compatible (I don't have to reprogram my brain every other = release)=20 > 5) accessible when the system is somewhat crippled (single user mode > after a failure) >=20 > And I might get over my "fetish" for text files. =20 >=20 > 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.=20 >=20 > 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.=20 >=20 > --=20 > Arlie >=20 > (Arlie Stephens = arlie@worldash.org) > _______________________________________________ > freebsd-hackers@freebsd.org mailing list > https://lists.freebsd.org/mailman/listinfo/freebsd-hackers > To unsubscribe, send any mail to = "freebsd-hackers-unsubscribe@freebsd.org"
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?1912F461-882E-462A-A3C6-6BC1A15D4353>