Date: Tue, 24 Nov 2015 11:50:30 +0200 From: Dan Partelly <dan_partelly@rdsor.ro> To: Mark Heily <mark@heily.com> Cc: freebsd-hackers@freebsd.org, Allan Jude <allanjude@freebsd.org> Subject: Re: libUCL / UCL as FreeBSD config question Message-ID: <663FAC89-8B0B-4E20-85F2-36C346A3AC73@rdsor.ro> In-Reply-To: <CAGfo=8nMqnwM5%2Bys3oA5NXpMHP7wbW3jDPPS6wus7SjD57dcLQ@mail.gmail.com> 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>
next in thread | previous in thread | raw e-mail | index | archive | help
> IMHO, it would be better for libucl to focus on being a = general-purpose library for parsing/generating configuration files, and = have another layer like stated(8) that manages things like concurrency = and transactions. >=20 >=20 It=E2=80=99s not that simple. Mandatory locking is the minimal = protection you need . And mandatory locking is not available by default = on most unixes, it needs to be specifically enabled . (Windows NT and = derivated kernels offer support)=20 And even with mandatory locking the support would be iffy. With text = files there is the constant temptation to just throw vi on them. Unless = your daemon keeps all the time a mandatory lock on all confif files, = this is not going to work well. 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. See, allegedly, some ppl from Linux world went as far as gathering = bitcoin to pay for a hit on the author of systemd, Lennart Pottering. = Systemd might not be perfect, might be buggy, not =E2=80=9Cready=E2=80=9D= yet for enterprise , (or it might, I dontr really use any kind of = Linux, so I cant tell ) but it is much needed innovation. Can=E2=80=99t = really even call it innovation, =20 Windows servers have such features since long ago. Its merely catch up. = ( NT derived kernels are awesome beasts IMO, with very cool design ) Also, it is my opinion that every BSD desktop distribution started with = the left foot. Instead of developing window managers and desktop = managers and reinventing the wheel , their focus should have been = translating some utils from BSD base in libraries, write some daemons = like notifyd, launchd (just general examples, not necessarily copy their = implementation ) and build frameworks to manage geom objects. network interfaces,protocol = configuration, cron like features and so on. Instead all invent new = desktops and WMs and so on.=20 But the issue is, those all sit on a flimsy scaffolding, of = frankensteined toolkits and Rube Goldberg contraptions. IMO, not a = single BSD desktop distribution is attacking the right problem. The = problem of the unix desktop must be solved starting at OS framework = level. Ironically, some of the features which are desirable to have in a modern = =E2=80=9Centerprise=E2=80=9D OS rest on much the same daemons and = frameworks which would make the proper unix desktop possible. > On 23 Nov 2015, at 00:24, Mark Heily <mark@heily.com> wrote: >=20 >=20 > On Nov 21, 2015 3:07 AM, "Dan Partelly" <dan_partelly@rdsor.ro = <mailto:dan_partelly@rdsor.ro>> wrote: > > > >=20 > > Absent the will to adopt a proper, fully transactional and atomic = mechanism of storing OS configuration, > > I would go back to the drawing board for a while. >=20 > The creation of a "proper" mechanism for storing OS configuration = aligns well with the mental roadmap that I have for the StateD = project... >=20 > The current version of stated(8) provides the front end for a unified = configuration system with pub/sub notifications. The next incremental = step is to build the backend, and the initial implementation will just = scrape the configuration files in /etc and present them in a read-only = fashion. >=20 > For the next major step, we could build an entirely new backend that = uses libUCL to provide read/write access to configuration settings. This = access would be mediated through stated(8) to provide history, = transactions, locking, atomicity, and notifications. >=20 > For example, imagine that one could change the host name and domain = name with this command: >=20 > statectl set hostname=3Dfoo domain=3Dbar.com <http://bar.com/>; > Behind the scenes, stateD would acquire a lock on appropriate current = configuration file(s), make a backup copy of the current state, use = libucl to modify the files to reflect the desired changes, unlock the = file(s), and generate notifications. >=20 > IMHO, it would be better for libucl to focus on being a = general-purpose library for parsing/generating configuration files, and = have another layer like stated(8) that manages things like concurrency = and transactions. >=20
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?663FAC89-8B0B-4E20-85F2-36C346A3AC73>