Hi David,
On 12/25/2010 9:06 AM, David Brown wrote:
>>> Here in Norway, Christmas is celebrated mainly on the 24th rather than
>>
>> Then "Merry Christmas" (let's see... I guess it's still the 24th, there,
>> as I type this)
>
> It's now the 25th, and a day for relaxing here (in my house, anyway -
> traditions vary). Merry Christmas to everyone else, or "Happy Holidays"
> for those that prefer that (I can't understand the reasoning behind that
> phrase, but each to his own).
I believe it is intended to be sanitized of religious references.
E.g., "safe to use in mixed company"
>>>> The *BSD's have a "package" system with the same functionality.
>>>> As with any "true" UN*X tool, it just pieces together actions
>>>> performed by other (existing) tools. E.g., consult "database"
>>>> for package (to identify dependencies), "install" dependencies
>>>> (which requires examining database for that package's dependencies,
>>>> etc.), etc.
>>>
>>> The BSD "ports" system has a lot in common with the various Linux
>>
>> *BSD's tend to treat "ports" as things you build and "packages"
>> as those same things, prebuilt.
>>
>> Then, you also have to deal with the various *ports* to different
>> CPU's... :-/ Sort of like the terminology overloading that comes
>> to play wrt "partitions", etc. <frown>
>
> I thought "ports" was the name of FreeBSD's package manager, but I could
> be wrong.
<frown> It's hard to be pedantic, here -- hence my use of quotation
marks -- as the terms are heavily overloaded. And, as I mentioned,
the introduction of support for different architectures adds yet
another dimension to the "mix".
First, the distinction that all *BSD's contain more than just
a kernel. I.e., "NetBSD" is *a* kernel (usually several different
configurations are shipped in each release -- PER ACHITECTURE)
*plus* a set of core tools/services. So, with *a* BSD, you have
a complete working system (whatever that means). You can write
code, compile it, run X (and a core set of x apps), support a
full set of network services (httpd is NOT included but things
like tftpd, ftpd, ntp, etc. *are*), build new kernels, etc.
(you can opt NOT to install large portions of *BSD -- e.g.,
all the X related stuff, fonts, sources, etc. -- if you really
to minimize your disk footprint).
Beyond that, all of the "applications" are handled by the "ports
collection" (port being a bad choice of word as it is also used for
a "port" to another architecture -- I suspect the origin of the
term in this context was in light of "porting an application *to*
*BSD"). So, emacs is NOT present in any of the BSD's but is
added as an "application". Ditto for apache, KDE, GIMP, etc.
The mechanism that allows for this application support exists
in two different forms. You can chose to download and install a
PREBUILT "package". Or, you can build that package yourself
from "pkgsrc" (this being little more than a hierarchy of patches,
makefiles, scripts and "relationships" between "packages").
The "packages" are created by "someone" sitting down and building
an app *in* the pkgsrc distribution. E.g.,
# cd /usr/pkgsrc (typically)
# cd archivers/zip
edit system-wide pkg configuration -- or specify pertinent options
for this particular application
# make (build the application)
# make (I forget what the name of the target is to bundle the
installable files into a "pkg")
# make clean
I.e., the "packager" saves you the trouble of having your machine
crunch through the compile (I've run NetBSD on 40MHz SPARCs;
FreeBSD on 25MHz 386's; etc. You used to be able to run FBSD
on a 5MB 16MHz 386sx -- can you imagine trying to make kde
on such a box?? Just wqaqtching the disk thrash would feel like
inhuman punishment!)
>>> package managers, such as apt, yum, portage, etc. There are differences
>>> in the details and the functionality, but all are designed to make it
>>> easy to get hold of a package and any other packages that it depends on,
>>> and to keep everything updated (if you want it to).
>>
>> I don't think the *BSD approach automates "updates". IIRC, there
>> are hooks that let you periodically check to see if any of the
>> packages on *your* machine have (new) security advisories that
>> are applicable. But, I think you still have to explicitly decide
>> that you want to go find a new version, etc. Most "packages"
>> are only supported in one or two "releases" (at a time). So,
>> going back to a particular release may be impossible once the
>> system "marches on" (i.e., I keep snapshots of pkgsrc)
>
> I don't know of any Linux distributions that try to force new updates on
> you, or even make it the default. Many /check/ for updates by default,
> but it's your choice to install them or not.
I don't think that capability exist in the pkgsrc or ports collection.
I know you can have pkgsrc fetch an updated "vulnerabilities" file
and then examine the pkgs installed on your system to inform you of
any "vulnerabilities" that may have been discovered since you
built/installed them.
>> the BSD's, you end up with a functional system -- the typical
>> "core services and utilities" (X, inetd, ntpd, ftpd, nfsd/c, etc.)
>> right out of the box. And, there is no (real) change in them
>> between BSD's.
>
> The huge majority of these parts are common between Linux and *BSD.
>
> It's just a slight difference in the terminology. Technically, "Linux"
> is just the kernel. What people actually use, is a Linux distribution
> (or a "GNU/Linux" distribution if you prefer, since many important parts
> of the system are GNU). But people typically refer to the whole system
> as "Linux", or by distribution name.
My point was that "Linux" doesn't mean anything -- you have to
reference which distribution you are talking about.
OTOH, OpenBSD/NetBSD/picoBSD/FreeBSD/etc. each define a particular
"core system" (which varies from release to release). So, configuring
"ntpd" on OpenBSD has definite connotations. (in fact, it is
probably the same for all of the BSD's -- though there are some
personality induced differences :> ) Saying the same for
"Linux" begs the followup questions, "Which distro? Which kernel
version?"
> In the *BSD world, there are three BSD's - OpenBSD, NetBSD and FreeBSD.
> I think they all operate on much the same principle. These are all
> roughly equivalent to Linux distributions in that they cover the whole
> system packaging, but differ in that it is the same group that develops
> the kernel and the packaging.
But a BSD system is typically more narrowly defined than a Linux
distro. E.g., you *won't* find kde in any of the BSD's (well,
I may be wrong here as I am two full releases out of date and
haven't watched FreeBSD since 2.6 or so).
There are three groups associated with BSD maintenance.
Kernel hackers maintain the three different (where "different"
means "incredibly similar" :> ) kernels; others provide the
assorted "core utilities" that flesh out the "system".
Then, there are a group of "packagers" that work on porting
the various "applications" -- usually, WITHOUT regard to
a particular BSD. I.e., the files in the pkgsrc hierarchy
have a lot *literally* shared between all of the BSD's and
some tweeks for each *particular* BSD. So, if one camp
wants "packages" in /usr/pkg while another wants them
in /usr/local...
> Then there are a few odd-bod systems - Debian packages with a BSD
> kernel, non-standard BSD distributions, etc.
>
>> OTOH, the "rest of the distro" in the Linux world drags in things that
>> BSD treats as "applications" -- relegated to the packages/ports
>> system.
>>
>> For example, starting X leaves me with a "rootweave" screen and
>> an xterm. I *think* twm is probably there.
>>
>> But, kde, gnome, etc. -- none of that cruft is even present in the
>> filesystem! Want to browse the web? Sorry. Want to view a PNG?
>> Sorry (i.e., libpng doesn't exist!).
>
> It's all there in the BSD package manager system. You install it if you
> want.
> All you are really saying here is that the BSD system /you/ installed
No, you're missing the point. If I download *BSD, I *don't* get
any of the PNG sources. There is nothing *in* the BSD's that
needs them so the philosophy is (or at least "had been") to
not deal with them in the various BSD's but, instead, deal
with them as "application" issues.
IIRC, the options I have(had) for installing NetBSD:
- base
- comp
- etc
- games
- kernel(s)
- man
- misc
- text
- source
- xbase
- xfonts
- xcomp
- xfonts
- xserver
So, if I don't want X, I don't bother unpacking the x* groups.
If I don't want man pages, I don't install the man group. If
I don't want to build/compile anything, then I omit the comp
group. I think the bare minimum system can be run with etc,
base and *a* kernel from the kernel group. A "full install"
would include all of the above (this is the *binary* distribution).
Note that this exists on a "per architecture" basis. I.e., the
SPARC "base" is different from the i386 "base" (some are
shared -- like man)
Then, there are the "source" groups:
- gnusrc
- sharesrc
- src
- pkgsrc
- syssrc
- xsrc
The syssrc is typically the kernel sources. Xsrc is obviously
the X sources. The src group is the bulk of the system. There
is an active attempt to quarantine all GNU/GPL software in the
gnusrc group (UNLIKE Linux, you can distribute the BSD's
*without* source code -- including the changes that YOU make
to the kernel, applications, etc.).
The pkgsrc is the issue I was talking about earlier.
I have downloaded/installed ALL OF THE ABOVE. Yet, there is no
libpng, libjpeg, etc. on my system AT THAT POINT. It is only
when I delve into applications that I build out of the pkgsrc
hierarchy that these things get drawn into the picture -- but,
*separate* from NetBSD itself!
> was fairly minimal. You can do that with Linux too. Many distributions
> will include the browser and Gnome in the base install. Others have very
> little, while most of the "big" distros (Debian, Fedora, Ubuntu) have
> something like Gnome by default, but you can choose not to install it if
> you don't want it.
>
>> Where folks will tout "damn small linux", this is relatively *easy*
>> to get to in the BSD camps -- because none of the "other crap"
>> is there to begin with!
>
> Oh, it's all there, because it is not "crap" but is useful software.
> These things are personal choice - for some people, "twm" is all the
> window manager they need. Other people - the great majority of users -
> prefer something more advanced, such as Gnome or KDE. BSD makes it easy
> to install Gnome too.
>
>> So, each time you drag a "package/port" onto your machine, you start
>> pulling in all this extra cruft. When I build ports, I keep an
>> ordered list of what I build and when. This allows me to tackle
>> the "common prerequisites" early so that I am sure I have them
>> configured the way *I* want them -- without relying on the
>> system building them 'automatically' to satisfy a prerequisite
>> for some other "port"
>
> You seem to go through an awful lot of effort here - effort that the
> very clever folks at FreeBSD (or NetBSD or OpenBSD, if that's what you
> use) have already made. They have already done all this work precisely
> so that users like yourself will not have to bother. Of course, clever
> though they are, they are not perfect, and may make mistakes or have not
> tested or considered some particular special situations. And you
> certainly have the /choice/ to do this work yourself. But it's not
> necessary - only a tiny proportion of BSD or Linux users micro-manage
> their systems in this way.
The reason for taking on the responsibility myself hails back to the
"three groups" that maintain the sources. Look at them as concentric
rings -- kernel maintainers in the center, pkgsrc authors at the
periphery. The skill set required *tends* to increase as one
moves inward -- the repercussions of mis-steps increase.
Given the shear number of applications (thousands!), the number of
folks authoring and maintaining "packages" exceeds those maintaining
the kernel. And, the commitment of folks in package land is usually
much less than that of the core team (kernel + system).
As it is a volunteer effort, there is no one riding herd over
these people verifying the quality of their work, enforcing
conventions, etc. (keep in mind, I got on the NetBSD bandwagon
at 0.8 -- early 1990's -- I think they are now at 5.mumble)
Since I don't take a kitchen sink approach with my UN*X boxen
(I pick, carefully, what I will use on each), I *can* invest
the time to carefully examine *how* a package is being built.
I can make changes that are more in favor with the way I want
to use a package. I can chase down bugs that are important to
me (with that number of packages, some are obviously NOT going
to see regular usage) without waiting/hoping for the "package
author" or "port maintainer" to stumble on the same problem.
(for years, my primary contribution to FreeBSD was in this
role -- just feeding patches to friends who would dress them
up and submit them formally to "whomever". I no longer do that
as I don't chase the current releases unless I am researching
a particular bug/problem)
>>> work with the main package (and thus there is little extra). I'll not
>>> claim there is no wastage, just that there isn't much extra. It is
>>> certainly an order of magnitude better than the windows style of
>>> including copies of every library with every program.
>>
>>>>>> If you just install a prebuilt package, you are putting your
>>>>>> faith in the "builder" that he understood the various (inevitable)
>>>>>> compiler warnings, dependancies, etc. and made smart choices about
>>>>>> what to do in each case (too often, people just blindly build things
>>>>>> and as long as make ends "successfully" they figure "all is well").
>>>>>
>>>>> How is that any different from anything else you install on your
>>>>> machine, Windows or Linux? You are also putting your faith in the
>>>>> programmer that wrote the software in the first place. All I can
>>>>> say is
>>>>
>>>> The *programmer* is different from the "package maintainer"!
>>>
>>> True, but who is to say that the programmer is better at this job than
>>> the package maintainer? As an example, the typical programmer has tested
>>> his code on one or two machines, probably with the same cpu
>>
>> Granted. In one case, you rely on the programmer to have written
>> a portable piece of code. OTOH, you rely on the "package author"
>> to know how to ensure things are portable AS WELL AS understand
>> the code he is "porting" (packaging?). My experience has been
>> that people fixated on "porting" the code often are just trying to
>> get it to compile -- hopefully "clean". But, they don't often
>> look *into* the code to see if that "clean build" *should* have
>> been clean or if there isn't an error lurking behind this
>> seemingly "perfect" build.
>>
>> [and, of course, more often than not, the build *isn't* clean]