From owner-freebsd-stable@FreeBSD.ORG Tue Mar 29 12:53:46 2011 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 4C2B5106566C for ; Tue, 29 Mar 2011 12:53:46 +0000 (UTC) (envelope-from varga.michal@gmail.com) Received: from mail-bw0-f54.google.com (mail-bw0-f54.google.com [209.85.214.54]) by mx1.freebsd.org (Postfix) with ESMTP id BA6348FC16 for ; Tue, 29 Mar 2011 12:53:45 +0000 (UTC) Received: by bwz12 with SMTP id 12so163857bwz.13 for ; Tue, 29 Mar 2011 05:53:44 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:subject:from:to:cc:in-reply-to:references :content-type:organization:date:message-id:mime-version:x-mailer :content-transfer-encoding; bh=nN7gE8zjU/f4O8AHbpek3zXMyUk1W3Y46vtEvAhmi9Q=; b=EwpASHcDwIc0GAQOrp1Y3R8KrUpN1Lu5gd79FSbICGI8Av1bpMwxUa/uCTaVoVuM9f Ep0KWn1PKYBVoFwjoSXa4xyWlzu1YNzVBVNJkiN5WOG3v0c6V8qpmYk3P6Y817BirI3F mAgx1VnhVKPv8YKwgLJ5eqPM/xsUCiZSDw/eM= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=subject:from:to:cc:in-reply-to:references:content-type:organization :date:message-id:mime-version:x-mailer:content-transfer-encoding; b=K7G5nsi+uCfrATcC15RJe2W/0XmRC79fnb3CIQ8a897hRCo1VfMbKk/s87B4ReOPpX SczYh4iKsC0/e1jJj0z7dCZfrSONz2XrRf4VcS0+ieJZJGFHnF5HyE4vm32L/wTmci3t HnTHZzELgvGLdYAr2XYGNeZeMIrHEb7irmDpg= Received: by 10.204.133.91 with SMTP id e27mr4987264bkt.23.1301403223205; Tue, 29 Mar 2011 05:53:43 -0700 (PDT) Received: from [10.0.101.2] (254.166.broadband10.iol.cz [90.177.166.254]) by mx.google.com with ESMTPS id t1sm3406826bkx.7.2011.03.29.05.53.41 (version=TLSv1/SSLv3 cipher=OTHER); Tue, 29 Mar 2011 05:53:42 -0700 (PDT) From: Michal Varga To: Christian Walther In-Reply-To: References: <20110329013223.ddca7453.jhsu802701@jasonhsu.com> <1301391185.71226.36.camel@xenon> Content-Type: text/plain; charset="UTF-8" Organization: Stonehenge Date: Tue, 29 Mar 2011 14:53:39 +0200 Message-ID: <1301403219.71335.111.camel@xenon> Mime-Version: 1.0 X-Mailer: Evolution 2.32.1 FreeBSD GNOME Team Port Content-Transfer-Encoding: 7bit Cc: Jason Hsu , freebsd-stable@freebsd.org Subject: Re: Best way to switch from Linux to BSD 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: Tue, 29 Mar 2011 12:53:46 -0000 Hi, On Tue, 2011-03-29 at 12:59 +0200, Christian Walther wrote: > What's the benefit of building everything from source? Yes, you can > configure some of the ports, but in these days you'll end up with > stuff you don't want to have anyway. I'm a zsh user and have hardly > any need for bash, except that there are ports that have it as run > and/or build dependency. And I reckon it's rather difficult to setup a > system without having python and ruby installed. Well, port options aren't only about removing unneeded stuff, but also the other way around - make that application actually able to perform some task so in the end, you don't need three different ones to successfully finish a single specific process. Take, as one example, the mplayer/mencoder combo (which Thomas Zander [re]started actively maintaining recently, and is doing an awesome job with that). Get mplayer, turn off every possible option you can and all you get is a glorified "hello world" program (well, it might be even able to display that hello world graphically, yay). Now do it the other way, learn what all the respective techs (and so dependencies) mean and do, pull in whatever stuff you need to get your work (or entertainment time or whatever else) done, fine tune your compiler whistles (multimedia processing benefits heavily from extended instruction sets, I obviously don't need to stress that), and poof, you end up with a single most complete multimedia playback AND transcoding package that covers most people's 99% needs [citation needed]. But many people don't get that (sometimes just simply don't know), so they end up with systems polluted with multiple sets of multimedia packages that "sometimes work, sometimes don't". Then a user comes to you complaining how FreeBSD sucks, that this or that video stream doesn't work, DVDs don't work, some things work in Totem, some only work in crappy VLC, "ZOMG I need flashez for my Youtubez!" (yeah, sure you do), some even keep Xine backends for "this or that that only plays with it", some run Windows video encoding software over Wine to get their stuff done (and crashing five times during the process). Now you ask the guy - "But why are you doing that? I'm perfectly sure that for example, mplayer covers everything you just mentioned and I know first hand that these things work there as they should, everybody does it, I do that daily, for years straight without any issues." "No no no they don't, look I tried it, it just said soemthing about not supported or whatever and then crashed after or dunno it simply didn't work, so I used Totem like that's the other media thingie and that didn't work either dunno some graphics driver or what error heh but who cares, brb going to boot up Windows". "Sigh, fine, but then out of curiosity, where did you get that mplayer of yours?" "Like how, where? I only did the 'pkg_add -something mplayer' or whatever like they said on the web, and it sucks and doesn't work, sorry but it's the FreeBSD way, it's simply that FreeBSD is broken, and it sucks, everybody says that, so it must be, like, true. Yeah." "Duh.. Ok. Yeah then." Now you probably see where I'm getting at with all the fine-tuning mumbo and configurations and customizations. Yes, FreeBSD takes time, but it gives you the possibility and opportunity to do it. You don't need to - there are prebuilt generic packages that do generic stuff (somehow), there are systems like PC-BSD that already come "complete" and well - do stuff - somehow, but FreeBSD *lets* you do much more, the moment you realize that you need to. To put it as a hyperbole - if you just want generic stock off-the-shelf crap, yes, FreeBSD has that (too). Some, or *most* of it might even work. Some might be bloated, some might be insufficiently 'stock-configured' so instead of one, you will end up with system stuffed with multiple applications of the same kind, only because "some of them sometimes work with something and some with the rest". But for people that want the control and need the control and need to get under the hood and tune it for the best possible outcome, FreeBSD offers everything all the way down like no other OS does. It's probably not worth the hassle for your regular grandma, but then, that's why there is this other "FreeBSD for dummies", it's called Mac OSX. And it's pretty good. > Compiling from source can be done on fast, modern systems, e.g. amd64. > My primary "workstation" is a rusty Thinkpad T30. Building all ports > from scratch takes two days, and we're not talking about any IDE. You can always build your "tuned" ports infrastructure someplace else and deploy everything on T30 via packages after (see what I did here?). Sure, it's probably not worth it simply for a single personal machine (you can keep running the T over night and let it crunch through your own FreeBSD "universe", you rarely rebuild totally everything from scratch), but try maintaining a larger workplace and the return is instantly huge. That's when you realize what a lumbering 7-legged dinosaur the stock FreeBSD is and why it needs to be cleansed with fire, first, and repeatedly. > Additionally, using compiler optimization doesn't seem to be that > recommended anymore, since it can break code, thus leading to nasty > results. I wouldn't agree there. The basic O2 is perfectly safe for ages now (O3 not so, *but* depends on your time and resources to put into testing and possible troublesolving, and even then you might still turn out to be a winner in most cases in the end). Processor specific optimizations are a must too, otherwise you don't even need the fancy new one with the latest SSSSSE9-THIS-TIME-IN-STEREO, when your plan is to keep using just the raw i386 out of it, that's like buying a latest state-of-the-art sportbike and for the rest of the life keep dragging it tied behind a Pinto. > Which is why several developers state in their trouble > shooting guide to rebuild their application with default settings > before opening a bug report. This further decreases the benefit of > compiling everything from scratch. "State". Several developers are simply lazy and nobody pays them to debug someone elses issues. Keeping it simple and unified saves anyone's time, but mostly theirs. I personally support this approach and everyone sane should. [I snipped a large part because this is getting seriously way too long, but I agree with many of your points there, so now just to one more thing...] > On the downside there seem to be some work needing to be done IRT > kernel based 3D acceleration. I don't know the current status, but the > last I heard was that NVidias drivers can't be ported to FreeBSD > because the kernel lacks some functionality required (something > related to addressing the graphics board directly from software, > AFAIK). Nvidia has 100% support on FreeBSD (not comparable to their Windows/Linux support, but great nevertheless): http://www.nvidia.com/object/freebsd-x86-260.19.44-driver.html http://www.nvidia.com/object/freebsd-x64-260.19.44-driver.html Nvidia's drivers on FreeBSD are pure complete awesome sauce and they would cook you a dinner if you asked them to, and clean up in the morning afterwards. (No, really, I don't work for Nvidia and I'm probably years away from any possibilities for fanboy-ishms, but this is how it really is.. So you are mistaken, Nvidia single handedly saved FreeBSD on desktops many years ago and does it till present times, over and over. No, they're not that much into charity, but some of their corporate customers run FreeBSD, so this is the outcome, and it's pretty good). > So if you want the latest features and eye candy (say, KDE4s Plasma) > and make heavy use of xcompmgr, there might be better choices. Don't believe that (see above). m. -- Michal Varga, Stonehenge (Gmail account)