From owner-freebsd-stable@FreeBSD.ORG Sat Mar 3 11:55:50 2012 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 515E8106567E for ; Sat, 3 Mar 2012 11:55:50 +0000 (UTC) (envelope-from ohartman@zedat.fu-berlin.de) Received: from outpost1.zedat.fu-berlin.de (outpost1.zedat.fu-berlin.de [130.133.4.66]) by mx1.freebsd.org (Postfix) with ESMTP id BF8828FC1A for ; Sat, 3 Mar 2012 11:55:48 +0000 (UTC) Received: from inpost2.zedat.fu-berlin.de ([130.133.4.69]) by outpost1.zedat.fu-berlin.de (Exim 4.69) with esmtp (envelope-from ) id <1S3nJI-0003jF-Ur>; Sat, 03 Mar 2012 12:39:37 +0100 Received: from e178025231.adsl.alicedsl.de ([85.178.25.231] helo=thor.walstatt.dyndns.org) by inpost2.zedat.fu-berlin.de (Exim 4.69) with esmtpsa (envelope-from ) id <1S3nJI-0007pw-NU>; Sat, 03 Mar 2012 12:39:36 +0100 Message-ID: <4F5202F0.1020205@zedat.fu-berlin.de> Date: Sat, 03 Mar 2012 12:39:28 +0100 From: "O. Hartmann" User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:10.0.2) Gecko/20120223 Thunderbird/10.0.2 MIME-Version: 1.0 To: freebsd-stable@freebsd.org, Current FreeBSD References: <20120221143537.Horde.deyFDZjmRSRPQ52pxBIpnLA@webmail.leidinger.net> <4F4BA707.5070608@wasikowski.net> <4F4C3FE7.3040802@FreeBSD.org> <4F4D51CB.2010508@FreeBSD.org> <4F4D5E5D.9040302@FreeBSD.org> <4F4DD288.5060106@FreeBSD.org> <4F4ED889.2070608@FreeBSD.org> <4F500BB9.4040307@FreeBSD.org> <4F5088CA.1090108@FreeBSD.org> <4F510FBD.50008@FreeBSD.org> <4F513B2D.6010809@FreeBSD.org> <4F5148A7.4080408@FreeBSD.org> <4F51BDDA.3020602@hm.net.br> In-Reply-To: <4F51BDDA.3020602@hm.net.br> X-Enigmail-Version: 1.3.5 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enigCDD584BCDD94D7E19CD4691B" X-Originating-IP: 85.178.25.231 Cc: Subject: Re: flowtable usable or not X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 03 Mar 2012 11:55:50 -0000 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enigCDD584BCDD94D7E19CD4691B Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable On 03/03/12 07:44, H wrote: > Doug Barton wrote: >> [...] Sure, >> our strength is servers, and that is not going to change.=20 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 ... >=20 > Even if somebody got all packages into his system (by miracle?), it > still did not popped up. Without some special knowledge _no_chance_. >=20 > who knows, the guys who created and battled on area51 knew why they > chose this name :) >=20 > Still now, kde4, hours of install, missing packages, compiling and stil= l > nothing, somewhere over the process, flies over the screen please set > kdm4_enable=3D"YES" ... I guess that will not be noticed by any user >=20 > 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 ha= s > 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=3Dno_no, packages=3DYES= 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. >=20 > 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. >=20 > 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". >=20 > Such a decision would help FreeBSD in all means and would help the user= s > 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 ... >=20 > 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 ..= =2E > 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 ... :) >=20 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 --------------enigCDD584BCDD94D7E19CD4691B Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.18 (FreeBSD) iQEcBAEBAgAGBQJPUgL4AAoJEOgBcD7A/5N8s9gH/A3KdiTIyL9ayJGxHJ+Z8gve Hu08UXUH4sR1F3vXwSyroxSVEpz9KWa3WCkjMugeGJqT1sNegEHCQornaaVFRiat TcbiSOYgyOdwSWFaFo2KOfQgjL/ppP3oUQoYTP/dIKZBS+NwCjj1in48XLK+NKB0 YfxH3ktivLTHpCBQUi0OMuZunNBb1EGgoZy6F/8xn5EyOFSfHWjXFJ2Ilpkz8KT0 EWzAVuCSxWd9BVrkwfa2pLah4XIQ2fc7g+RXN37SEOrFhYodTnLmB2zX0tK0dWss 5J/grdI4lFju1atHGBB8OvzDCNFrPh7I3r+vBb6zK3LIe3ad33mqfzCI6FY+8aw= =pIUK -----END PGP SIGNATURE----- --------------enigCDD584BCDD94D7E19CD4691B--