
One of the three OpenBSD users - fcambus
http://blog.tintagel.pl/2015/11/22/one-of-the-three-openbsd-users.html
======
JoshTriplett
Such a bug didn't deserve the snarkiness it got; as the article author notes,
Linux itself remains a minor platform for end users, and benefits from people
doing ports to Linux of software that has more users on other platforms. (For
instance, Firefox and Chrome both have far more users on Windows than Linux.)
But apart from the unnecessarily snarky response, I think this played out
exactly as it should have. A kinder response would have been "none of us run
OpenBSD, but if you can provide a non-invasive patch, we'll merge it". Which
ended up happening anyway.

~~~
rewqfdsa
> Linux itself remains a minor platform for end users

What the fuck? Android is one of the most popular operating systems in the
world.

~~~
umanwizard
When people say linux, they don't care what kernel they're running - they mean
GNU/Linux that has a reasonably close interface to that of a typical UNIX
machine. I agree with Stallman &co. that the name "Linux" is imprecise, but
you shouldn't pretend you don't understand what people mean.

------
bcoates
More importantly, why doesn't OpenBSD have procfs? Is there something
fundamentally wrong with the idea? Is there some more standard alternative
that portable software should be using?

~~~
asveikau
Trying to answer this I found this old thread:

[http://marc.info/?t=125341144400003&r=1&w=2](http://marc.info/?t=125341144400003&r=1&w=2)

Arguments I see here:

* it's old code and not maintained.

* the interface has inherent race conditions (see Theo's comment about reading from procfs one byte at a time with sleep calls in between - I presume with the values changing underneath you)

Unrelated to this thread I found googling that OpenBSD and NetBSD have had a
small but nonzero number of security issues in procfs over the years.

------
vezzy-fnord
It wasn't long ago that Linux users fancied themselves the underdog being
sidelined in favor of Windows. Now, the Linux users have become the Goliath
flaunting their weight and key spokespeople even encouraging the rejection of
all other platforms. It is a community defined by myopia, arrogance and a
refusal to look outside its borders.

~~~
JoshTriplett
Linux has many different communities, not all of whom share the same opinions
(or level of snarkiness). Some Linux developers may feel as you suggest, or
more charitably, perhaps they just want to conserve their limited development
resources focusing on providing the most benefit to the most users. But I
don't think that view has become universal or even a majority, and I still
regularly see projects merging support for other platforms, especially other
Free Software platforms. I've merged such patches myself, written portability
libraries, and even gone out of my way to test software I've written on
GNU/Hurd. I've also seen ideas from such platforms influence Linux, and vice
versa.

I certainly hope nobody views Linux and its community as consisting entirely
of the kinds of people whose snarky remarks make the news. We could do with
far less of those people.

In my more idealistic moments, I wonder how much better we could do if we
focused on making one kernel better rather than half a dozen. Then again, in
those same moments, I also wonder how much better we could do if we focused on
making one desktop environment or browser better, too. None of those seem
likely to happen.

~~~
vu3rdd
While what you are saying is very true, recent developments around systemd
seem to have changed a few people to target linux-kernel based systems than
the BSDs.

As the autoconf files suggest, a lot of GNU software was written in the most
general way possible, targeting even the macos/osx/windows/aix/hpux etc.

In this age of easy virtual machine installations, it seems odd that software
authors of popular software are not targeting at least the BSDs.

~~~
JoshTriplett
> As the autoconf files suggest, a lot of GNU software was written in the most
> general way possible, targeting even the macos/osx/windows/aix/hpux etc.

GNU software originally ran on proprietary UNIX systems by necessity (because
no non-proprietary UNIX systems existed), hence their portability; even after
Free Software systems existed, having such software available on proprietary
UNIX systems provided a great advertisement for GNU (especially since the GNU
software typically worked better, and users could obtain tools for free with
full source that they previously had to purchase separately in binary form).

More recent software (GNU and otherwise) doesn't typically include
compatibility with obscure proprietary UNIX systems (especially long-dead
ones), because such systems no longer particularly matter, and seem unlikely
to gain new users. Portability to, for instance, HP-UX or Cray systems isn't
even worth the time spent detecting and maintaining crazy build-time
conditionals, or even the minor chance of introducing a bug. And, perhaps more
importantly, the authors of the software don't particularly want to _test_ on
such systems, and a port you don't regularly test won't keep working.

Even a back-of-the-envelope order-of-magnitude estimate of the total amount of
developer time, system time, and power consumed running ./configure scripts
that autodetect conditions nobody seems likely to ever use again produces some
_scary_ numbers. ./configure takes an obscenely long time to run, often far
longer than make.

> In this age of easy virtual machine installations, it seems odd that
> software authors of popular software are not targeting at least the BSDs.

That doesn't seem odd to me at all.

For most software, I wouldn't mind taking patches to support BSD, but that
doesn't mean I'll go install a BSD system, try to figure out BSD conventions
and policy, fix portability issues myself, and maintain continuous integration
for BSD to make sure it _keeps_ working. If I wanted to put time and effort
into testing my software for portability to other systems, I'd first confirm
that it built and ran on Fedora in addition to Debian; I've encountered issues
with that due to Fedora's incompatible paths for 32-bit/64-bit libraries.

There are exceptions: I went out of my way to do exactly that as part of
making sure XCB ran on the Hurd. I did that partly for novelty (I knew nothing
about the Hurd, and afterward I knew slightly more than nothing), and partly
because XCB needs to run everywhere X and Xlib can. Even then, though, the
resulting port got maintained by actual Hurd users.

So while I'd take a patch to support BSD, I'd rely on the submitter of the
patch to keep it working over time, and to let me know if it broke. (And if
someone felt sufficiently dedicated to do so, I'd probably give them commit
access to help maintain it.) But in the absence of a dedicated BSD developer
interested in maintaining the port, I can definitely understand why people
wouldn't go out of their way to target BSD.

------
anarcat
what happened to syncthing usage since october? it seems the numbers have been
dropping since the 0.12 upgrade...

