Skip site navigation (1)Skip section navigation (2)
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: <http://docs.FreeBSD.org/cgi/mid.cgi?20200119094142.0bc64292.freebsd>