[TUHS] UNIX of choice these days?
kevin.bowling at kev009.com
Sun Oct 1 06:29:55 AEST 2017
I never really considered proc vs sysctl as deeply as this discussion.
Both seem like a little bit of a stretch and cause some impedance
mismatch in ways they are actually used. For instance on FreeBSD you
can pass opaque structures around and that's how some of the utils
work -- these aren't displayed using sysctl(8). So now you have ABI
over a text API anyway.
I seem to recall proc is loosely deprecated in Linux anyway in favor
of sysfs. GregKH mentioned people misuse both, for instance making
them output pretty histograms instead of simple text values, that
defeat the fundamental design tenants of these interfaces -- which is
to try and maintain a stable API.
One thing I think Linux did pretty well is the whole object
orientation in C thing with kobject, and that nets you automatic sysfs
directories and nodes for pretty much everything.
Lots of gymnastics trying to solve a fundamentally more simple problem
of a text API vs ABI, hierarchy and maybe some object orientation. At
risk of ridicule, I think the AIX ODM was the best planned and
executed take on all that :)
On Sat, Sep 30, 2017 at 8:17 AM, Norman Wilson <norman at oclsc.org> wrote:
> Warner Losh:
> It's an abundance of caution thing. This code had security problems in the
> past, we're not 100% sure that we've killed all the issues, though we
> believe we have.
> And if there isn't anyone who's actively interested in the
> code, willing to dig in to clean it up and make security
> issues less likely, deal with multiprocessing matters, and
> so on, that's a perfectly reasonable stance.
> I think it's an unfortunate result, and I wonder how much
> of it comes from a cultural view that sysctl >> /proc.
> (Recall how Ken and Dennis originally resisted Doug's push
> for pipelines and filters, because--as Dennis once put it
> in a talk--it just wasn't the way programs worked?)
> But as someone who is sometimes credited with removing
> more code than he wrote while working on the latter-day
> Research kernel, it's hard for me to argue with the principle.
> A lot of the code I tossed out was complicated stuff that
> was barely used if used at all, and that nobody was willing
> to step up to volunteer to maintain.
> Norman Wilson
> Toronto ON
More information about the TUHS