Re: flowtable usable or not

On 03/03/12 07:44, H wrote:
> Doug Barton wrote:
>> [...] Sure,
>> our strength is servers, and that is not going to change. 

I agree and disagree. Based upon the struggle with desktop usage and
focus on development, FreeBSD is de facto more server oriented. But in
comparison to several other non-BSD opensource server OS projects, the
corridor of advantages in FreeBSD became and still become smaller and
smaller. This is the experience of using FreeBSD now since 1995 as my
favorite OS for servers I maintained for scientific projects and my
personal desktop(s).
Please don't take me wrong, but the conclusion of the strength of FBSD
is due to its weakness - and this is not willingly, it is coincidentialy.


>> But how many real-life bugs have I personally uncovered in -current as
>> a result of actually running it (mostly) daily? I'm not the only one,
>> certainly, but if the numbers were flipped and the vast majority of
>> our developers *did* use FreeBSD routinely, how much better off would
>> we be?

Well, for an "open" source project this sounds to me a bit strange.
Developers do not use the OS they developing for as their platform? This
might be new to me and an old information for the majority of you
developers, but I see strange implications ins that fact. FreeBSD is
considered an open source project ran by "volunteers" (I receive this
magic message in all forums I ever complained about some problems ...).
Honestly and in terms on logic, I can not line up several points, sorry,
I might be too dumb. Obviously not a development by heart but by
payment? But this is OT here and I never could emphaszie people to
follow my philosophical tracks (which might be inadequate for some sets
of people ...).

> let's face some reality. Forever installing FreeBSD Desktop, either KDE
> or Gnome, was a nightmare process, or better, to make it appear on
> screen was a nightmare.

Since myself (and some remnant "we") use FreeBSD for both servers
(development of scientific software, processing scientific stuff,
modelling, rendering for PR products related in astrodynamics and
planetary sciences) and as the desktop system of choice, I never found a
friend in that performance eating thing "KDE" or "GNOME" and stayed long
time with fvwm and now with windowmaker. Yes, this sounds like an echo
from the past, but living like a monk and celebrating askesis in that
fashion made me faster in some ways and independent from "fast" hardware
and recent developments in X11, in which FreeBSd now turns out to get a
position "last" in terms of modern display driver architectures. But I'm
still impressed by the fancy and coloured desktops of PC-BSD, which I
have ran for some people to lurde them into the BSD world ...

> 
> Even if somebody got all packages into his system (by miracle?), it
> still did not popped up. Without some special knowledge _no_chance_.
> 
> who knows, the guys who created and battled on area51 knew why they
> chose this name :)
> 
> Still now, kde4, hours of install, missing packages, compiling and still
> nothing, somewhere over the process, flies over the screen please set
> kdm4_enable="YES"  ... I guess that will not be noticed by any user
> 
> Even if some smart guy figures out that he needs xorg-server, the port
> or package do not select all it needs for running, its own drivers and
> so. How a user should know that? There is a windeco which installs
> hundreds of deps, even sound what do not work on FreeBSD, but xorg do
> not have deps for its functionality? goooood ... ohhh I forgot, that has
> nothing to do with the desktop itself , sorry for mentioning ...

Maybe the logic behind the dependency system need a refurbish? I feel
lost when trying to look into the vast number of of *.mk files and
having to figure out myself how they get involved when building some
essential ports. Each "tweak" seems to go into those files undocumented
and the logical hierarchy isn't obvious, since many dependencies are
hidden in GNOME/KDE related files.

Not to mention the mess that ariose when I tried to follow a strict
separartion of building the core FreeBSD UNIX only with /etc/src.conf
leaving compiler options for non-/usr/src related software in make.conf.
Obviously, they are mixed up in a way I get tired as a non-developer to
keep on pace with.CLANG is a nice compiler, I like it, I use it now as
the base compiler for everything, but the lack of OpenMP and
optimizations for modern CPUs (Core-i7/Sandy Bridge/-E) makes it a bit
unapplicable to several software packages I'd like to use. And the
confusion using the legacy, outdated gcc 4.2.1 in the base system and
replace it "easily" by gcc 4.6.3 or now 4.7.X is taking valuable working
time. I think, and this is my personal opinion and view, it would be
much better to sort out the confusion in the build system(s) and then
start over. I guess there are a lot of options to do so, even now, but
how to find documentation? Crawling scripts and source code to find out
the logic and vast numbers of variables isn't a way.



> Even if lots of you do not like it to hear, fact is that we must look
> around and see how others do it. Windows, whatever it is, it is easy to
> install for everybody.

Well, this is right. But do not forget that even those fancy and easy to
use installation framework hide a lot of the underlying system's
hierarchy and logic. Look at all the Linux systems, trying to get on par
with Windows. How long did they raped Linux to get it that way looking?
In and on FreeBSD, speaking now for the server, I receive a problem or
get aware of a problem. Since the system hasn't been overpolluted and
made suffering with logic and structure covering scripts like, for
instance in Suse Linux or Ubuntu, I often know were to look for a
solution. On our Linux systems (CentOS, Ubuntu, Suse), I need to consult
fancy scripts. Yes, the scripts work - in most cases, but I do not know
what is going on beneath ... In terms of security, privacy and total
control this is a very bad feeling situation.

> If it was my decision, it should be go to ports=no_no, packages=YES

In such a case, there would be no reason anymore to use FreeBSD! I want
to use the system as fast as possible on desktop, so binary packages
should be all right. But on servers, I'd like to squeeze out the last
nanosecond I can grab by using dedicated compiler options. So I wnt to
have the choise! My freedom, my responsibility and also the freedom to
decide for my own how much "brain" I want to invest into understanding
my OS - or even not. At this very point, I "can", up to a certain point,
decide how much time I want to spend on understanding. Others "can not",
by natural selection, they need to be stuck with binaries. or they
won't, because they are more in business than science and have no
interest in other things than money. Or, even in more soft words, they
need a working horse to perform the daily work they are interested in.

> 
> I mean, as long as the packages are not complete and ready, no new port
> version should be released or announced

Why not? How should the "free" open source community then ever help to
debug? I guess what you think about is to have a more strict
"RELEASE/STABLE/CURRENT/ based policy also for the ports system? I would
agree.

> 
> So who dares,understand and can or like adventures, compiles from ports

It is not simple as that. The "logic" starts at the compiler's point.
GCC 4.2.1 isn't an option in many cases, CLANG unsuitable (openMP).

On the other hand, who should provide all the binary coverage? As you
could see, the user domain of FreeBSD is shrinking. And even my
department is not willing to spend my time, traffic volume and hardware
to provide a build server for FreeBSD binaries to provide a better
coverage for "world" or even only for the mid of Germany. They like to
be better with Linux, preferably "Ubuntu".

> 
> Such a decision would help FreeBSD in all means and would help the users
> as well, in any case it will create more users

Yes, well said, but a bit false. World has changed since the last 50
years, politically. Monolithic capitalism with a herd of dumb, mean
animals only want to "touch and use". Monolithic socialism creates mean
people from the same source, greedy, envy to share and kick-asses those
who can and are bright enough. The "bright" go to capitalism, sonce they
get sucked in by monstrous large companies, the remnants remain in
"socialism" pools. The so called Bourgeoisie is getting smaller, but
this is also OT, sorry ...

> 
> Why somebody should chose FreeBSD as his daily desktop, oh man, only
> some die-hard-guys like you and me, but you know, that is not hours of
> work, that is days, weeks and constant setbacks for whatever reasons ...
> that is not for anybody. And you are right, no traffic on the specific
> lists, why? because the three on the list, two can help themselves (you
> and me) and the other is the moderator ... :) not even the port
> maintainer/packager is on that list ...  :)
> 

Well, these days dying on FreeBSD is much quicker than years before - in
my special case.
Linux is faster in (our) network. Linux response faster in (our) NFSv4
(environment). Linux has a better scalability (NUMA awareness seems to
be better on our 2-socket servers). Linux adopt faster new architectures
due to a better maintaining of the necessary compiler(s). And I'm going
to face another development that will let FreeBSD die faster in certain
scientific areas (were the BSD has been born!). This is mainly due to
the lack of the support of modern GPGPU stuff. I'm forced to replace
several FreeBSD servers now by Suse Linux machines. Reason: GPGPU. We
can use OpenCL/CUDA on the TESLA boards we obtained, we can use
OpenCL/CUDA on the desktop boxes equipted with expensive and fast GPU
hardware (and we do this very intensive now). We modell, simulate and
optimize on GPGPU code developed by scientists in our depeartment, based
on OpenCL.
Since we are also dependend on funding from the government (we have to
present so called "PR products" which include scientifically prepared
and rendered products of solar system objects like Mars or the Saturnian
icy moons), we need to build up a "render cluster", which we do with a
well known open source rendering software which has now GPGPU support.
Even on "out of the box server Linux" this can not be performed "out of
the box" and need "die hard" people. But they do not die hard on FBSD
anymore.

Call it "natural selection".

Regards,
oh