Re: native inotify implementation

On Sun, Jul 6, 2025 at 12:14 AM Vadim Goncharov <vadimnuclight@gmail.com>
wrote:

> On Fri, 4 Jul 2025 18:14:20 -0700
> Rick Macklem <rick.macklem@gmail.com> wrote:
>
> > > Yes, and no. While it's often useful in short-term perspective, such
> > > approach leaves FreeBSD without unique features so it becomes yet
> another
> > > "Linux, just poorer" with obvious then "why choose it?". It's
> > > understandable that in some cases it is simple to implement compatible
> > > API, but an alternative like "have more general solution with a
> > > compatibility shim layer via which their API is implemented" is better,
> > > when possible.
> > >
> > > It's late in which particular topic as commit was landed, but for
> future we
> > > should think how to extend kqueue to be able more.
> > > [E.g. I'd want to have notifications for my protocol with multiple
> streams
> > > inside one socket (think like QUIC), but it does not fit nicely into
> > > current struct kevent or socket API (multiple socket buffers with
> separate
> > > reading)]
> > The flip side of this is "Why would anyone build a significant open
> > source software
> > project that uses a FreeBSD specific API and cannot be built for Linux
> > systems?".
> >
> > Basically, 99.999% (just a guess) of the open source systems out there
> are
> > Linux based and, as such, open source software projects will be built to
> use
> > their APIs. imho.
> >
> > A "more general solution" almost no one will use is not particularly
> > useful, again
> > imho.
>
> That's exactly what I'm talking about - if we have no unique features, then
> choices will be in favour of Linux, and as a consequence if everybody will
> choose Linux, then why we have a reason to exist at all?
>
> So this bad chain should be broken at the beginning.
>
> --
> WBR, @nuclight
>
>
Operating systems don't only compete on features, they also compete on the
quality of those features.

For example, some years ago, Facebook put out a job posting for a software
developer that could make Linux's IPv6 stack as fast as FreeBSD's ;-).

Now how good is our file monitoring API? Does it perform as well or better
than Linux? What is its memory usage? Can it do things that Linux can't?


Damjan