Date: Sun, 19 Jan 2020 09:41:42 +0100 From: Polytropon <freebsd@edvax.de> To: Ihor Antonov <ihor@antonovs.family> Cc: freebsd-questions@freebsd.org Subject: Re: sysctl and /sysfs Message-ID: <20200119094142.0bc64292.freebsd@edvax.de> In-Reply-To: <3038969.aeNJFYEL58@t800> References: <4538784.31r3eYUQgx@t800> <20200119064151.7f781748.freebsd@edvax.de> <3038969.aeNJFYEL58@t800>
next in thread | previous in thread | raw e-mail | index | archive | help
On Sat, 18 Jan 2020 23:49:31 -0800, Ihor Antonov wrote: > On Saturday, January 18, 2020 9:41:51 PM PST Polytropon wrote: > > > In context of Linux... > > > > https://www.youtube.com/watch?v=9-IWMbJXoLM#t=8m20s > > > > Sorry, couldn't resist. ;-) > > Thanks, I really enjoyed this talk. I agree that "everything is > a file" is not > applicable everywhere. Exactly. There just is no "one size fits all" approach to things that are fundamentally different, both in what they do (and why) and when they were invented. > > The core "problem" (which actually isn't a problem at all) > > is that exposing _everything_ as a file or a hierarchical > > filesystem doesn't seem to work for each and every case. > > That's why different approaches have been taken that worked > > out in a better way. With sysctl, direct access to kernel > > system information has been unified. There is still some > > kind of hierarchy preserved. > > > > See "man 3 sysctl" and "man 1 sysctl" for details. > > > > > Sidenote: > > > > Watching "What UNIX Cost Us" by Benno Rice at "linux.conf.au" > > (LCA) 2020 does actually help understanding _why_ the use of > > the "everything is a file" metaphor doesn't always work. > After watching this talk I also watched another talk of his: > > Tragedy of Systemd: https://www.youtube.com/watch?v=o_AIw9bGogo > > And I must say, Benno has a point. FreeBSD definitely lacks something like > systemd (and I want to stress "like", not "exactly" ) Do you know of any > ongoing efforts to bring a unified system management functionality to > FreeBSD? I'm not sure. The rc.d mechanism present in FreeBSD to manage system services, their order and dependencies, is somewhat tied into devd, a mechanism that allows you to "dynamically react to system events". However, it more or less lacks the "dynamic" aspect. For static start / stop / restart actions, it works quite nicely, and it does _not_, as opposed to Systemd, try to incorporate all the things into some "thingd" with a separate configuration directory "/etc/thing.d/". Note that it hasn't been the case all the time: in the past, specific rc.<something> scripts handled things, but they had to do lots on their own. With rc.d, things like prequisites, start order, provided functionalities and user-specific keywords can be managed more easily, and it is the same concept both for the OS in /etc/rc.d/, and for 3rd party programs that supply such scripts in /usr/local/etc/rc.d/; furthermore, user-specific directories can be added, let's say /opt/rc.d/, for something managed entirely independently. In Linux land, there are several startup management systems, with systemd probably being the most prominent one. My assumption is: Before FreeBSD attempts to implement something comparable, maybe Linux should be standardized... but yeah, I know, that's not going to happen... ;-) -- Polytropon Magdeburg, Germany Happy FreeBSD user since 4.0 Andra moi ennepe, Mousa, ...
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20200119094142.0bc64292.freebsd>