Re: *BSD co-operation.

[Hugo Silva <hugo%barafranca.com@localhost>]

On 08/23/11 09:40, Greg A. Woods wrote:
> At Mon, 22 Aug 2011 19:39:18 +0200, "Julian H. Stacey" 
> <jhs%berklix.com@localhost> wrote:
> Subject: Ports & Packages infrastructure & feature import. (fwd)
>>
>> My suggestions:
>> - Subscribe a list or 2 on [SomeOther]BSD[s].org
>> - Encourage people on [SomeOther]BSD.org to subscribe a list on 
>> [Your]BSD.org.
>> - Encourage BSD people to share ideas on best tools, methods, formats, 
>> imports.

What I have to say about all this is that I find the 3 BSDs that I use
(Net/Free/Open) very valuable,
each in it's own way, with considerable overlap. I have no opinion on
Dragonfly, as I've given it only a cursory look (in huge part because
there's no Xen port, and as someone mentioned in that thread @
freebsd-arch, even FreeBSD suffered quite a lot by not having a usable
Xen port soon enough; back in the days, if most people were anything
like me and the guys I know/knew, an old p200 would serve as the testing
grounds for $os.. these days you launch a vm), but their stuff looks
solid too.


I try to contribute what I can, mostly by running current (in
production) and whining about bugs encountered along the way, but also
telling people about *BSD and encouraging experimentation. At work I'm
lucky enough to be in a position to select which OS we use, most of the
time. For some tasks, as it stands today, no *BSD is a viable choice,
but thankfully I find those cases in the minority. I'm happy to say 98%
of the systems @work run a *BSD; Something like:

 - NetBSD for virtualization and simple domUs (like wikis, openssl+
encrypted CAs (cgd + custom scripts), etc)
 - FreeBSD for web, mail (increasingly not using it on real
hardware, choosing instead to go with NetBSD and then virtualizing
FreeBSD with HVM+PV/amd64, but the lack of dom0 MP limits what you can
do, because on high I/O scenarios the dom0 is perpetually cpu-starved)
 - OpenBSD for firewalling and routing.

Today, for the reasons stated above, NetBSD gathers my attention
increasingly, altough I still use FreeBSD regularly (it may be the fact
that I've used it for 10+ years, but ports, even with the deficiencies
that people keep pointing out, seem to be easier to manage than pkgsrc..
to this day (it's been about 2 years since I started with NetBSD) I
still haven't managed to fully upgrade all packages on a NetBSD system
without downtime/something fscking up.. maybe I've been doing something
wrong, though; It's mainly for this reason that I still prefer FreeBSD
as a webserver or mail server (where there are many packages installed))
- the other being jails -- I find it so much easier to set up different
parts of a mail server on different jails, for maintenance and security
reasons (and yes, I know it's the same kernel); Dedicated Xen domUs for
this task seems to me as too heavyweight.

Personally I think that's an area NetBSD could improve on, lightweight
virtualization a la jails/zones; Another thing I miss from OpenBSD is
systrace (did that critical problem with it ever get solved?).

As for OpenBSD, it tends to just work for what I do with it
(routing/firewalls), and the documentation is quite good. Altough MP
performance isn't the best (doesn't matter much for the workloads I use
it on, anyway it seems this will be addressed in 5.0), their system is
remarkably stable too.

One negative about it (imho) is the lack of a Xen port (for ideological
reasons, according to google): increasingly we deploy many VMs in a NetBSD
dom0, with many bridges and "virtual routers" between different VMs.

While we use OpenBSD (I like the way their releases are integrated, and
for a simple firewall it's simpler to setup than any other system; also they
always have the most recent PF version (NetBSD/npf might be a game
changer here)) for this task, it can't get past
routing ~4MB/s, due to the immense HVM I/O overhead.

This is fine for most uses I give to it, but for more demanding stuff I
have to go with NetBSD (which right now is limited to 1CPU, altough this
will change in the near future, if things go well (thanks Cherry!).

I no longer consider FreeBSD the top choice for routing/firewalling
purposes since ~4.11-RELEASE (5.x was a nightmare, 6.x barely registers
in my memory, 7.x and beyond is considerably bloated compared to 4.x,
and a firewall should be, in my opinion, a very simple system), and in
any case, even with some bug fixes from the freebsd-xen guys, I still
can't get FreeBSD to run well virtualized (top shows processes using
0.00% CPU, yet the summary says (for example) 90% user, >1 CPUs will
make the system randomly hang, and the kernel has serious problems
keeping time (under Xen, possibly other virtualization products),
something I'm trying to get help with at this moment on the freebsd xen
list)

Still more than happy to run it in other settings, though. I especially
like it for ZFS, and Pawel's contributions in general (hast, zfs, geom..
in the disk management arena I think FreeBSD is way ahead of NetBSD, or
any of the other BSDs (but I haven't looked at dfly/hammer yet)). And
bloated or not, it's also quite stable.

What divides me about FreeBSD these days is that with the amount of CPUs
and memory one tends to get on servers, it no longer makes sense in most
cases to install it on the real hardware, and jails have serious
limitations (you can't set memory limits or assign cpus X and Y to a
jail with base system tools or anything in ports, to the best of my
knowledge) in the resource limitation arena.



I guess the point I'm trying to make is that all *BSDs are valuable
projects, and altough we SAs and users don't shower the devs with praise
and compliments every day, I think I can speak for the majority when I
say that we truly appreciate the work you put in. I'm sure that many
others live the life they live only because people like you learned to
hack unix. Just like some people live the life they live only because
their systems are running stable and uncompromised (good unix system
(devs) + competent sysadmin(s) (and network engineers, and programmers,
and ...)).

It's an ecosystem.
For us to even be able to do our thing, someone else needs (among 1000
other things) to have an understanding of the laws of physics, etc.

I like to see it as new patterns emerging from the understanding of the
level 'beneath'.

So all this talk of *BSD fading away.. I don't buy it.. as long as you
guys are still having some fun and gusto developing the system, and
as mentioned on that freebsd-arch thread, also implementing what the
zeitgeist needs (if SAs and users can't get the OS to do what they need
it to do, clearly they have to look elsewhere).. sure, we need new blood
to keep the thing going.. devs, sas and users.. but as someone else
said, if the systems implement
what people are looking for, new users should continue arriving. And
some of them will go on to become developers, or write documentation, or
both. The ones that don't go on and build solutions and products based
on *BSD :)

Sure, on some levels (some) functionality has fallen behind (on $x
BSD).. altough I won't claim to understand most of the code, don't all
the BSDs have well designed abstractions to work from? And are not the
developers in all the
BSDs great at coming up with excellent abstractions that consistently
turn out to be a good choice, lasting for decades?

If that's the case, and I think it is, then perhaps all we need is to
pause and reflect on the direction of the projects.. what people need,
what needs to be implemented, what needs to go and what needs to be
created, that sort of stuff.