Re: flowtable usable or not

[Adrian Chadd]

I've had the same problem with wireless.

For some users, wireless works flawlessly.

For other users, it's completely unusable.

Trying to get any kind of useful feedback from people has been
impossible at best. I've even had FreeBSD developers, sitting in the
developers IRC channel, say wifi is so broken on FreeBSD they have to
boot into windows to get anything done.

Yet I still haven't seen any PRs about this.

This is why I've been pushing people to keep filing PRs. I can't even
begin to investigate what I don't know is broken and if the
_developers_ don't use FreeBSD because supported wifi stuff is broken,
then .. well, no hope, etc.

The honest truth is this: for any system to work, there needs to be:

* sufficient users reporting issues;
* sufficient developers (and/or companies) wanting it to work and
keeping the bug fixes coming;
* a healthy cycle between the above two.

If _either_ there are no developers or there is no feedback to the
developer(s), the cycle breaks, and things rot in very annoying ways.
Then you have the next problem, which is:

* if it doesn't work, noone will use it
* if noone uses it, noone will work on it.

Try breaking that cycle.

2c,


Adrian
_______________________________________________
freebsd...@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-curre...@freebsd.org"

[O. Hartmann]

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

[Garrett Cooper]

2012/3/2 Julian Elischer <jul...@freebsd.org>:
> On 3/2/12 10:21 AM, Doug Barton wrote:
>>
>> On 03/02/2012 03:44, K. Macy wrote:
>
> not sure who wrote:
>>>
>>> Correct. However, I'm not sure the analogy is flawed. I am, to some
>>> degree, guilty of the same sin. I now run Ubuntu and have never had a
>>> single problem keeping my package system up date, in stark contrast to
>>> my experiences of slow and nightmarishly error-ridden port updates.
>
> but I use the PBIs from pcbsd..  you REALLY don't have this problem with
> them.

(Thanks Kip for the heads up on the thread)
It's well known that software has bugs; unfortunately PCBSD (I
mention this because of PBIs noted above) isn't immune from bugs
either -- they're just manifested in a different way.
I think everyone here on the CC list has FreeBSD's best intentions
in mind, but let's work together to improve the OS instead of causing
discord with one another. Personally, I think that adding knobs with
sane defaults (and we can debate about that and there will be
disagreement on what is important and what is not) will go a long way
because then people can pick and choose what they want to keep and
what they want to toss as far as OS support is concerned. This is one
of the strong selling points of Linux, OSX, Solaris, Windows, etc.
Less effort is required to get greater profit without having to mess
around with things because they fit the generic case as opposed to a
number of niche cases or provide OS features that a user may or may
not use.
Thanks,
-Garrett

[K. Macy]

> Less effort is required to get greater profit without having to mess
> around with things because they fit the generic case as opposed to a
> number of niche cases or provide OS features that a user may or may
> not use.

My initial venting of my frustrations at Doug appears to have turned
an open-ended discussion of FreeBSD's merits as a desktop vs. a server
OS. I don't have the inclination to read every response closely, but I
think that it is generating more heat than light. I have three points
that I would like to make before I attempt to transition this thread
back to its initial purpose:

a) We as a members of the community are collectively responsible for
the state of FreeBSD. Simply disabling features or removing
functionality that doesn't work or doesn't work optimally and / or
filing bug reports but not being able or willing to respond to
feedback requests is in essence a form of neglect. Although we all
have day to day obligations for which the use of FreeBSD is extremely
impractical if not impossible ... any progress, any improvements, any
advancements will only happen because *we* made it happen.

b) There are many features and many changes that are introduced in to
FreeBSD which extend the potential user base which are of no obvious
benefit to many users. Just because one doesn't need a feature and
doesn't hear users crying out for it, doesn't mean that it isn't
important.

c) My grievance was in no way with Doug Barton or ports per se, but
with his response as a representative instance of a behaviour which
bothers me, and, taken over time, is detrimental to the whole.


Back to the initial subject line: "flowtable usable or not"

It is possible to re-structure the routing code to have a smaller
cache footprint / shorter lookup time / and eliminate all locking in
the packet transmit path (ip_output, ip_forward). However, it would
take more time and effort than I have to do so as a recreational
activity. The set of people able to fund such an effort is
non-intersecting with the set of people who would benefit the most
heavily from it. Hence, for the time being, for those who want to be
able to approach anywhere near 1Mpps, much less 10 or 15 times that,
whilst continuing to use the regular stack (i.e. not running netmap)
we are left only with flowtable for bypassing the locking and compute
overhead of per-packet route lookups.

It is beyond debate that under some, if not many, circumstances
flowtable was unusable and perhaps continues to be. Hence, any further
reports of "it was broken so I turned it off, and now my life is
better" should be left unsent. If you, the reader, are willing to
contribute to the testing of changes, provide backtraces from cores
etc. please follow up.


Thank you for your support.

Cheers,
Kip


--
   “The real damage is done by those millions who want to 'get by.'
The ordinary men who just want to be left in peace. Those who don’t
want their little lives disturbed by anything bigger than themselves.
Those with no sides and no causes. Those who won’t take measure of
their own strength, for fear of antagonizing their own weakness. Those
who don’t like to make waves—or enemies.

   Those for whom freedom, honour, truth, and principles are only
literature. Those who live small, love small, die small. It’s the
reductionist approach to life: if you keep it small, you’ll keep it
under control. If you don’t make any noise, the bogeyman won’t find
you.

   But it’s all an illusion, because they die too, those people who
roll up their spirits into tiny little balls so as to be safe. Safe?!
>From what? Life is always on the edge of death; narrow streets lead to
the same place as wide avenues, and a little candle burns itself out
just like a flaming torch does.

   I choose my own way to burn.”

   Sophie Scholl

[Doug Barton]

On 03/03/2012 08:53, K. Macy wrote:
> a) We as a members of the community are collectively responsible for
> the state of FreeBSD. Simply disabling features or removing
> functionality that doesn't work or doesn't work optimally and / or
> filing bug reports but not being able or willing to respond to
> feedback requests is in essence a form of neglect. Although we all
> have day to day obligations for which the use of FreeBSD is extremely
> impractical if not impossible ... any progress, any improvements, any
> advancements will only happen because *we* made it happen.

Since we're reiterating key points, I'll do mine one more time. While I
sympathize with what you wrote above, if you continue to believe that
users have a responsibility to help you debug new features you're going
to be disappointed and frustrated.


Doug

--

This .signature sanitized for your protection

[Doug Barton]

On 03/02/2012 16:05, Adrian Chadd wrote:
> Try breaking that cycle.

... one of the things I've been asking for years. :)

Julian's right though, I think PC-BSD will help, but I still think that
committers should run -current. I've asked privately for our committers
to go back to -current and then have some dedicated development time
where we work together to fix the problems that *we* find in order to
make the project more desktop-friendly overall. I was (figuratively)
laughed out of the room.

[K. Macy]

On Sat, Mar 3, 2012 at 9:54 PM, Doug Barton <do...@freebsd.org> wrote:
> On 03/03/2012 08:53, K. Macy wrote:
>> a) We as a members of the community are collectively responsible for
>> the state of FreeBSD. Simply disabling features or removing
>> functionality that doesn't work or doesn't work optimally and / or
>> filing bug reports but not being able or willing to respond to
>> feedback requests is in essence a form of neglect. Although we all
>> have day to day obligations for which the use of FreeBSD is extremely
>> impractical if not impossible ... any progress, any improvements, any
>> advancements will only happen because *we* made it happen.
>
> Since we're reiterating key points, I'll do mine one more time. While I
> sympathize with what you wrote above, if you continue to believe that

*users*

> have a responsibility to help you debug new features you're going
> to be disappointed and frustrated.

Users don't, community members do. So I guess I rest my case for you
Doug. You're an end user at the end of the day who thinks he is a
member of the community. As you've made apparent on other threads.

In your mind Other People(TM) are responsible for FreeBSD's welfare
for consuming your dogfood because you know the people who eat it.
FreeBSD would still be at the UP stage or worse the 5.x stage if
everyone thought the way you do. Individuals who fail to understand
the distinction between simple user and community member and are
confused by which role they play can only further contribute to the
acrimony.

-Kip

[Doug Barton]

On 03/03/2012 13:03, K. Macy wrote:
> On Sat, Mar 3, 2012 at 9:54 PM, Doug Barton <do...@freebsd.org> wrote:
>> On 03/03/2012 08:53, K. Macy wrote:
>>> a) We as a members of the community are collectively responsible for
>>> the state of FreeBSD. Simply disabling features or removing
>>> functionality that doesn't work or doesn't work optimally and / or
>>> filing bug reports but not being able or willing to respond to
>>> feedback requests is in essence a form of neglect. Although we all
>>> have day to day obligations for which the use of FreeBSD is extremely
>>> impractical if not impossible ... any progress, any improvements, any
>>> advancements will only happen because *we* made it happen.
>>
>> Since we're reiterating key points, I'll do mine one more time. While I
>> sympathize with what you wrote above, if you continue to believe that
>
> *users*
>
>> have a responsibility to help you debug new features you're going
>> to be disappointed and frustrated.
>
> Users don't, community members do.

You're drawing a distinction that I don't.

> So I guess I rest my case for you
> Doug. You're an end user at the end of the day who thinks he is a
> member of the community. As you've made apparent on other threads.
>
> In your mind Other People(TM) are responsible for FreeBSD's welfare
> for consuming your dogfood because you know the people who eat it.

Um, wow.

Clearly you are either unable or unwilling to see my point, so I wish
you all the best.

--

This .signature sanitized for your protection

[K. Macy]

On Sat, Mar 3, 2012 at 10:09 PM, Doug Barton <do...@freebsd.org> wrote:
> On 03/03/2012 13:03, K. Macy wrote:
>> On Sat, Mar 3, 2012 at 9:54 PM, Doug Barton <do...@freebsd.org> wrote:
>>> On 03/03/2012 08:53, K. Macy wrote:
>>>> a) We as a members of the community are collectively responsible for
>>>> the state of FreeBSD. Simply disabling features or removing
>>>> functionality that doesn't work or doesn't work optimally and / or
>>>> filing bug reports but not being able or willing to respond to
>>>> feedback requests is in essence a form of neglect. Although we all
>>>> have day to day obligations for which the use of FreeBSD is extremely
>>>> impractical if not impossible ... any progress, any improvements, any
>>>> advancements will only happen because *we* made it happen.
>>>
>>> Since we're reiterating key points, I'll do mine one more time. While I
>>> sympathize with what you wrote above, if you continue to believe that
>>
>> *users*
>>
>>> have a responsibility to help you debug new features you're going
>>> to be disappointed and frustrated.
>>
>> Users don't, community members do.
>
> You're drawing a distinction that I don't.
>

I'm drawing a distinction that you don't make or can't make? Like I
said I expect a group of people whose existence as a distinct entity
you are unaware of to be helpful. The initial conflict stemmed from
confusion on my part that you belong to that group. However, as you've
repeatedly made clear you don't, so I was wrong to have been critical
of you. I apologize for the confusion.

Cheers

[Adrian Chadd]

2012/3/3 Doug Barton <do...@freebsd.org>:

> On 03/02/2012 16:05, Adrian Chadd wrote:
>> Try breaking that cycle.
>
> ... one of the things I've been asking for years. :)
>
> Julian's right though, I think PC-BSD will help, but I still think that
> committers should run -current. I've asked privately for our committers
> to go back to -current and then have some dedicated development time
> where we work together to fix the problems that *we* find in order to
> make the project more desktop-friendly overall. I was (figuratively)
> laughed out of the room.

There's a magic intersection between "need to run current" and "need
to keep stuff unbroken enough to get work done."

I have 9.0-REL and -HEAD boxes at the moment which I actually use for
development. But enough things are going wonky with kde4 for now that
getting "actual work done" is hard. Upgrading ports will become a lot
less painful with pkgng, so I hope to try and migrate to that when
it's (more) ready.

This is the unfortunate side effect of things being mostly run by
volunteers who have to work to eat. :-)


Adrian

[Doug Barton]

On 3/4/2012 2:04 PM, Adrian Chadd wrote:
> 2012/3/3 Doug Barton <do...@freebsd.org>:
>> On 03/02/2012 16:05, Adrian Chadd wrote:
>>> Try breaking that cycle.
>>
>> ... one of the things I've been asking for years. :)
>>
>> Julian's right though, I think PC-BSD will help, but I still think that
>> committers should run -current. I've asked privately for our committers
>> to go back to -current and then have some dedicated development time
>> where we work together to fix the problems that *we* find in order to
>> make the project more desktop-friendly overall. I was (figuratively)
>> laughed out of the room.
>
> There's a magic intersection between "need to run current" and "need
> to keep stuff unbroken enough to get work done."

Personally I have a -current partition (slice) that I keep up to date,
and an 8-stable'ish slice that I purposely keep in a known-good state,
and only update if -current has been running good for a while (which it
has more often than not in the last several years).

I have both slices set up to share data such as /home, my cvs and svn
trees, etc. This has worked really well for me (and others, I originally
got the idea and some of my configuration from David Wolfskill) for over
a decade.


hth,

Doug

[Adrian Chadd]

You haven't been bitten by the storage layer or filesystem hackery
bits which has caused filesystem corruption. :)

That said, FFS+SUJ has made recover-from-kernel-panic so much less
painful. Thankyou Jeffr and others!

What I tend to do is either run current on a VM or organise some
dedicated -current laptops. And run the bits of -current I'm testing
on -8 and -9.




Adrian

[Doug Barton]

On 3/6/2012 2:12 AM, Adrian Chadd wrote:
> You haven't been bitten by the storage layer or filesystem hackery
> bits which has caused filesystem corruption. :)

Ummm, I have, actually. I was one of the early adopters of SU+J and
complained loudly when it ate my /var/ for lunch. I also use a lot of
separate slices/partitions, so my system partition isn't getting written
to very often, isn't using SU+J, and almost always comes up clean after
a crash. My layout looks like this:

FreeBSD 1 & 2 are the same:
/ + /usr
/var
/tmp (memory disk)
/usr/local/ (this is the big partition, things like ports WRKDIRPREFIX
and /usr/obj go here)

Then I have separate ext2fs filesystems for /home, /data (cvs, svn,
other big trees). These are accessible from my Linux partition, which is
also where the shared swap partition is.

Using ext2fs for things I really care about (like /home) or things that
would take a long time to reproduce (like cvs and svn trees) has helped
avoid some of the more exciting corruption/data loss events, and
everything on the /usr/local's is either backed up, or trivially
reproducable.

> That said, FFS+SUJ has made recover-from-kernel-panic so much less
> painful. Thankyou Jeffr and others!

It's also made a mess out of snapshots ... The only thing I use SU+J for
is /var and /usr/local (see above).

> What I tend to do is either run current on a VM or organise some
> dedicated -current laptops. And run the bits of -current I'm testing
> on -8 and -9.

Well you get a gold start for actually running it at all, so there you
go. :)


Doug