From owner-freebsd-stable@FreeBSD.ORG Tue Mar 29 18:54:29 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 863B41065672 for ; Tue, 29 Mar 2011 18:54:29 +0000 (UTC) (envelope-from cptsalek@gmail.com) Received: from mail-ew0-f54.google.com (mail-ew0-f54.google.com [209.85.215.54]) by mx1.freebsd.org (Postfix) with ESMTP id 0E36C8FC17 for ; Tue, 29 Mar 2011 18:54:28 +0000 (UTC) Received: by ewy1 with SMTP id 1so179481ewy.13 for ; Tue, 29 Mar 2011 11:54:27 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=cUGcqZoRRIY6OFgeOPnRCjb0AobXafJjv0lhE3tGPps=; b=AB9cvxhJAvegnzOzU/fk+qsjNPjxd+OqAGhhbyCTyNFK24ntr39IDWt/FL6p7MCRKL 7Se/+l+EaS2AMjI4i5oYnRiVc4hC28pn0hjf408t2uO++SzWiZ20/Gbf9Mdd8y42Nlkq Vsoldkb5rDOEX++KELhWWo8wRmH1wHBrOnVkc= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=jrmTHZQNgRJlxfj9E4RFEL9lRC8VeLv6QEBfGfcCSOqT38XjdseqXBeXpCvJzz1gGv k2FQDR218mjTJleLwisSkEHu6u5bkDqDnq7Mkgy0IMP3C8cgfbIZgigRGvx4eP3A9Z7n zdEyetLJF87+XIEJU2Zt0QEiHue+jTGc7VDCs= MIME-Version: 1.0 Received: by 10.213.20.213 with SMTP id g21mr388097ebb.56.1301424866384; Tue, 29 Mar 2011 11:54:26 -0700 (PDT) Received: by 10.213.29.83 with HTTP; Tue, 29 Mar 2011 11:54:26 -0700 (PDT) In-Reply-To: <1301403219.71335.111.camel@xenon> References: <20110329013223.ddca7453.jhsu802701@jasonhsu.com> <1301391185.71226.36.camel@xenon> <1301403219.71335.111.camel@xenon> Date: Tue, 29 Mar 2011 20:54:26 +0200 Message-ID: From: Christian Walther To: Michal Varga Content-Type: text/plain; charset=ISO-8859-1 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 18:54:29 -0000 On 29 March 2011 14:53, Michal Varga wrote: > Hi, > [Port building, mplayer/mencoder example w/o options] Packages are build with the default ports options. These turn out to be suitable for me, so I guess they are suitable for others, as well. I never said that building from source is pointless -- at least this was not my intention. > 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]. Certainly. This is a question of the use case. I haven't seen a single case where mplayer was unable to playback a file. [FreeBSD user complaining about missing mplayer capabilities] IMO this is about education. Firstly I expect FreeBSD users to read the documentation, in this case "Packages and ports", which at least should give them a hint that packages are not everything in existence. Secondly there are mailing lists and forums where one can ask in case something doesn't work as expected. Changing an OS or distro just because something doesn't work IMO doesn't count as problem solving strategy. ;) And I think that the problem with mplayer exists on Linux as well, due to licensing and legal issues. > 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. Exactly. > 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. Yes, it's about freedom, really. :) And since the OP asked of how to proceed I think it's fair to mention packages. I entirely disregarded pre built packages time, because I thought it best to compile everything myself. When I state that my T30 takes two days to build all ports I need and want is not a claim, I've seen it several times. ;) We have some great tools to deal with updates, but even with those and "make config-recursive" I occasionally checked the machine in the morning and saw a dialog window asking for a ports configuration. This is not a real problem but costs precious hour. And the machine consumes energy. Download packages enables me to run a shutdown when I go to bed. >> 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?). Yes, I know. And I decided not do so -- which is my choice. >> 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. Well, you gain much by the speed of the CPU alone. ;) And I reckon that most tools that I use really don't care if they're build for i386 or i686. It does make sense for video encoding, decoding of course, and number crunching (raytracing for example). [Optimization and debuging] > 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. It's not only that, wrong compiler options can really break valid code. We're not talking about -O2 here, but -O3 on gcc 4.x is a candidate here. And then there are really harmful ones, such as -funroll-loops and -fforce-mem. Thing is, there are Gentoo folks who have those set system wide. A nice read IRT to optimization is http://www.gentoo.org/doc/en/gcc-optimization.xml They basically recommend to stick to -march, -O, and -pipe Yes, I once had a Gentoo system running, which is why I became conservative when it comes to optimization. ;) [Snipped the NVidia part -- got it :)]