Date: Thu, 20 Dec 2012 05:29:08 +0100 From: Polytropon <freebsd@edvax.de> To: Ralf Mardorf <ralf.mardorf@rocketmail.com> Cc: freebsd-questions@freebsd.org Subject: Re: Upgrading FreeBSD 8.3 amd64 Message-ID: <20121220052908.e1120684.freebsd@edvax.de> In-Reply-To: <1355976819.2501.368.camel@q> References: <1355852561.2501.10.camel@q> <20121218185757.f10640e0.freebsd@edvax.de> <1355933062.2501.19.camel@q> <CAJ5UdcMNBcDVV88AD6n49awtm7DjjCgNbHcZBZYLK%2BWN4cuPsQ@mail.gmail.com> <1355936956.2501.72.camel@q> <20121220091216.40d1644b@X220.ovitrap.com> <1355976819.2501.368.camel@q>
next in thread | previous in thread | raw e-mail | index | archive | help
On Thu, 20 Dec 2012 05:13:39 +0100, Ralf Mardorf wrote: > Thank you Erich :) > > ok, so "FreeBSD release" is the version of the kernel and not a > labelling for the collection of all the software. No. The version specification refers to the version of the kernel _and_ the operating system (which form a unit maintained by the FreeBSD team). Those typically have to be in sync. Depending on what branch you follow, this can be: a) a static release number, e. g. 8.2-RELEASE b) a release, enriched by security updates, e. g. 8.2-RELEASE-p2 c) a stable version, e. g. 8-STABLE of a specific date (this is "work in progress" that has been considered working) d) a development version, e. g. 10-CURRENT (this may or _may not_ even compile, it's experimental) Depending on what branch you follow, updating techniques may differ: freebsd-update (the binary way) can be used for a) and b); for c) and d) you update from source. > For Linux major distros there usually is a labelling for the collection > of the software, independent of the kernel version. Linux doesn't know the differentiation between "the operating system" (consisting of the OS kernel and the OS programs, the "world" in FreeBSD terminology) and "everything else" (third party contributed applications, in FreeBSD provided by the ports collection). > On Linux I usually install binaries for the base system and desktop > environment, but for important software, in my case it's audio, > compiling from source is very important. The ports collection allows both binary installation and by source. There are tools that help managing them. Note that unlike Linux, FreeBSD draws a line between "the OS" and "installed applications" - you need to install and update them separately. This is a big benefit as a failed program installation can never harm your OS. > The author of the snd_hdspe driver for FreeBSD seems to need testers. It > seems to be that nobody ever tested if ADAT is working and I'll test it. > OTOH I suspect bug fixes for the driver have to be added by recompiling > the kernel or at least the driver for the kernel, so I still could use > binaries for the applications. Of course. The separation I've mentioned explicitely allows this method to function. What you need to do is to update your sources in /usr/src and then recompile the kernel and, if required, the world, as explained in /usr/src/Makefile's comment header. > Since audio on FreeBSD seems to be a niche, I wonder if it's more > promising, to go the source or to go the binary rout. I'd say: Use the source Luke. :-) Experimental changes and "bleeding edge updates" are typically a domain of source installations. With svn you can track smallest changes very quickly, apply them to your system and have a test run. Doesn't work? Undo the change, or wait for a new version. > I suspect if it's impossible or at least less good to mix binaries and > from source build software for FreeBSD, I should chose to build from > source. Basically there is no problem. One thing you have to pay attention to is dependency versions, but that's what port management tools like portmaster can do for you. -- Polytropon Magdeburg, Germany Happy FreeBSD user since 4.0 Andra moi ennepe, Mousa, ...
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20121220052908.e1120684.freebsd>