Re: NetBSD vs FreeBSD
Chavdar Ivanov
> Hello Aleksej,
>
> On 08/03/2011 09:47 AM, Aleksej Saushev wrote:
>>
>> Another thing I didn't like in FreeBSD after getting acquainted with
>> NetBSD,
>> is its ports. Having performed few critical upgrades of FreeBSD
>> installations
>> I know pretty well where pkgsrc would have helped us not doing extra
>> manual
>> work under hard time constraints.
>
> I'd be interested in hearing about ports vs pkgsrc. I thought that they were
> largely the same thing with a different name because the word "port" already
> means something in NetBSD.
The obvious first difference is that pkgsrc is OS-agnostic, whereas
ports is FreeBSD-specific. Take your pick between universality on one
side and the supposed better integration with the OS on the other.
Chavdar Ivanov
>
> Daniel.
> --
> I'm not overweight, I'm undertall.
Ditto.
>
--
----
--
Posted automagically by a mail2news gateway at muc.de e.V.
Please direct questions, flames, donations, etc. to news-...@muc.de
Daniel Carrera
Still curious about the differences between NetBSD and FreeBSD, so
Googling around I came across this post:
http://mail-index.netbsd.org/port-i386/2009/02/09/msg001189.html
The poster says that NetBSD is faster.
Does anyone here agree/disagree? I ask because I thought FreeBSD was
supposed to be the speedy one. In general I don't care much about speed,
but some times I run simulations on my computer. I have no idea if any
BSD or Linux is particularly good for that.
Cheers,
Daniel.
--
I'm not overweight, I'm undertall.
--
Al Zick
On Aug 2, 2011, at 3:33 PM, Alex Goncharov wrote:
> ,--- You/Daniel (Tue, 02 Aug 2011 21:12:48 +0200) ----*
> |
> | http://mail-index.netbsd.org/port-i386/2009/02/09/msg001189.html
> |
> | The poster says that NetBSD is faster.
>
> Since it was in response to my explorations: no offense to the NetBSD
> users and developers, but after trying to use NetBSD for a while, I
> had to turn back to FreeBSD, completely. The performance of my
> desktop environment has never been an issue for me, and if some
> programs run 5% slower on FreeBSD, why would I care? (But they
> probably not, in recent FreeBSDs).
I use to run a site that had an Alexa rating of less than 500,000 on
a 68k box. Can you guess what OS I used?
> In my experiments, FreeBSD proved to be an altogether better
> environment, with a superior developer support (just more people in
> the project, perhaps).
I just done a remote install of NetBSD on a leased server because I
was unhappy with their chooses of OSes.
> ,--- You/Daniel (Tue, 02 Aug 2011 21:16:37 +0200) ----*
> |
> | Isn't Xen just a virtual machine like QEMU, VirtualBox, etc? What
> makes
> | Xen special that people here talk about it while they don't talk
> about
> | QEMU and VirtualBox?
>
> VirtualBox works well on FreeBSD, and was significantly easier to
> configure than Xen on NetBSD when I used that. Also, that Xen (about
> three years ago) used only one processor of a dual processor machine
> -- I didn't like that at all and my Xen was quickly gone.
I don't see any reason that you can run NetBSD on VirtualBox if you
wanted to. Someone correct me if I am wrong, but I would think you
would want XEN on a server and not any of these others.
-Al
Alex Goncharov
| Essentially, one needs to keep the video card driver availability in
| mind when selecting the OS.
,--- Daniel Carrera (Wed, 03 Aug 2011 14:10:46 +0200) ----*
| Indeed. One of the possible concerns with a small team like NetBSD is
| that the OS might not support all my hardware. Not just graphics card,
| but printer, webcam, etc.
`---------------------------------------------------------*
Then there is www/opera, "The most full-featured Internet power tool
on the market".
Opera (the company) builds perfect FreeBSD binaries. No NetBSD
(http://www.opera.com/browser/download/requirements/).
,--- Johnny Billquist (Wed, 03 Aug 2011 12:16:10 +0200) ----*
| I understand the experience, but the reason behind it is the total
| opposite, I'd say. The disk labeling system in NetBSD is the more
| flexible of the two. But that comes with an added complexity.
How is that NetBSD flexibility useful? What can I do with disk in
NetBSD that I cannot in FreeBSD? (I know what FreeBSD slices give me
over Linux partitioning.)
| However, the complexity arise from the fact that there is another
| partitioning scheme as well (for PC systems). The NetBSD disk
| partitioning is the pure, original BSD disk labels, which are machine
| agnostic and are designed for clean disks. The additional cruft in a PC
| is what creates all the confusion, with the MBR partitioning.
| NetBSD bascially ignores it (well, it can read this, manipulate it, and
| use it to help you setup a BSD partition), and only uses its own
| partitioning. That causes confusion unless you understand all of it.
I think I finally understood it, and it didn't feel like empowering me
at all.
I realize that the NetBSD partitioning is probably never going to
change and not complaining -- this is about a realistic assessment of
two BSDs. From my experience, I feel that the NetBSD partitioning is
a huge PITA for a new user coming to an OS with reasonable today's
expectations. I.e. unless you gave NetBSD the whole disk and don't
really care.
| The partitioning in other systems acts as sub-partitioning under the PC
| MBR partitioning scheme.
Yes... so...?
FreeBSD slices and partitions are a huge convenience, especially when
your disk size is modest and you want to install multiple OSes there.
| For me, that is a much more confusing thing, since I look at the BSD
| partitioning as the master (I'm used to non-PC systems).
|
| The BSD partitioning, as set up on a NetBSD system is free to use all or
| nothing of the disk, as you want. Total freedom. Total flexibility.
I am free to use all or nothing of the disk with FreeBSD, Linux, and
probably Solaris (haven't used that for a long time, though.)
|
`-----------------------------------------------------------*
I understand the sentimental attachment of long-term NetBSD users to,
well, NetBSD.
But for a new user, who had given NetBSD a most impartial evaluation,
there was *nothing* in it that would make it a first choice for any
reason, other than, perhaps, Xen vitalization.
I did hope Xen would make me want to use NetBSD: I'd be running the
Xen host there, slowly learning this OS, and the guests would be
running at least FreeBSD, to support my daily needs. But, as we just
saw in this thread:
1. NetBSD Xen guests can't currently use more than one CPU on the
system.
2. They can't run FreeBSD.
Whoever and whatever are the reason for these two critical
deficiencies, doesn't matter for an me -- it's just that with them,
NetBSD loses all potential advantages over the alternatives.
When items 1 and 2 addressed, I may gladly give NetBSD another try.
-- Alex -- alex-go...@comcast.net --
Alex Goncharov
| | The poster says that NetBSD is faster.
|
| users and developers, but after trying to use NetBSD for a while, I
| had to turn back to FreeBSD, completely.
On the topic of the "vs".
A huge difference between Net* and Free* is the disk labeling and
partitioning schemas: I spent innumerable hours learning the
subtleties of the NetBSD partitioning and had to modify the labels by
hand setting four OSes on one system: i386 and amd64 of each NetBSD
and FreeBSD. NetBSD partitioning felt unbelievably complex and
inflexible compared to the FreeBSD. A new install of NetBSD on a disk
was practically a guaranteed way to disable or blow away an existing
FreeBSD installation, wherever a FreeBSD has never done any damage to
anything already on the disk in my long use of it.
And on the laptop side: Nvidia builds drivers for Linux and FreeBSD. I
am not sure it does that for NetBSD.
Just summarizing my experience.
-- Alex -- alex-go...@comcast.net --
--
Daniel Carrera
On 08/03/2011 09:47 AM, Aleksej Saushev wrote:
> Another thing I didn't like in FreeBSD after getting acquainted with NetBSD,
> is its ports. Having performed few critical upgrades of FreeBSD installations
> I know pretty well where pkgsrc would have helped us not doing extra manual
> work under hard time constraints.
I'd be interested in hearing about ports vs pkgsrc. I thought that they
were largely the same thing with a different name because the word
"port" already means something in NetBSD.
Daniel.
Julio Merino
> Hello,
>
> Still curious about the differences between NetBSD and FreeBSD, so
> Googling around I came across this post:
>
> http://mail-index.netbsd.org/port-i386/2009/02/09/msg001189.html
>
> The poster says that NetBSD is faster.
>
> Does anyone here agree/disagree? I ask because I thought FreeBSD was
> supposed to be the speedy one.
Hola Daniel,
These generalizations are misleading and harmful. Both systems are very
fast and optimized. In the vast majority of cases, the speed at which
they perform operations will depend on the workload and benchmarks,
because no single system is faster than all the others in all possible
situations. You will have to evaluate the systems for your use case and
decide accordingly.
> In general I don't care much about speed,
> but some times I run simulations on my computer. I have no idea if any
> BSD or Linux is particularly good for that.
The general advice is to try them all and decide which one suits your
needs best.
Personally, I like NetBSD over the other systems because there is a lot
of focus in "doing the right thing" technically, and the community
around it is very smart. As a result, NetBSD is a very clean and
consistent system. But this is only my personal opinion!
Cheers,
--
Julio Merino / @jmmv
Alex Goncharov
| On 08/03/2011 12:00 PM, Alex Goncharov wrote:
| > And on the laptop side: Nvidia builds drivers for Linux and FreeBSD. I
| > am not sure it does that for NetBSD.
|
| NetBSD on the desktop but not for laptops?
It doesn't mean that: I don't know if Nvidia builds any drivers for
NetBSD (didn't notice any when searching for the Linux ones).
I should have said, "On the graphics side" but I was specifically
looking for a laptop card driver, and thus my incorrect phrasing came.
(The end result with my laptop and Nvidia: the driver was there, for
both Linux and FreeBSD).
Essentially, one needs to keep the video card driver availability in
mind when selecting the OS.
-- Alex -- alex-go...@comcast.net --
--
Alex Goncharov
| Alex Goncharov <alex-go...@comcast.net> writes:
| > In my experiments, FreeBSD proved to be an altogether better
| > environment, with a superior developer support (just more people in
| > the project, perhaps).
|
| Given the number of people in project, FreeBSD has much worse performance
| in my opinion.
Curious, in what areas?
| I have no other explanation why documentation and simple
| one-line fixes have to sit in PR database for two years before being committed
| (yes, it was exactly that what pissed me off the most around year 2007).
I googled "Aleksej Saushev FreeBSD" hoping to hit a FreeBSD list with
your PRs, just to see the areas and histories -- no easy hit. Can you
give me a pointer -- for my education, not to counter your points?
-- Alex -- alex-go...@comcast.net --
Dustin Marquess
<alex-go...@comcast.net> wrote:
> VirtualBox works well on FreeBSD, and was significantly easier to
> configure than Xen on NetBSD when I used that. Also, that Xen (about
> three years ago) used only one processor of a dual processor machine
> -- I didn't like that at all and my Xen was quickly gone.
This seems like a common misconception. Under NetBSD/Xen, NetBSD
itself can only use a single CPU, but the Xen hypervisor itself can
use all of them. So your VMs can have multiple CPUs and the
hypervisor will schedule them correctly.
I agree with one of the other commenters about NetBSD doing the right
thing. Part of the reason I love NetBSD is because it seems clean and
well designed. FreeBSD just doesn't have that same feeling to me. In
fact, the only reason I ever use FreeBSD anymore is if I need ZFS, and
I can't use a Solaris derivative. While it's a fine OS, it just
doesn't have the same feeling of "done right", although it's miles
ahead in that area compared to Linux :).
Since this is all personal opinion, take it with a huge grain of salt,
especially since my first true *IX love was OSF/1 / DEC UNIX / Tru64,
so I'm sure that marks me as crazy :).
-Dustin
Alex Goncharov
| On Tue, Aug 2, 2011 at 12:33 PM, Alex Goncharov
| <alex-go...@comcast.net> wrote:
| > VirtualBox works well on FreeBSD, and was significantly easier to
| > configure than Xen on NetBSD when I used that. Also, that Xen (about
| > three years ago) used only one processor of a dual processor machine
| > -- I didn't like that at all and my Xen was quickly gone.
|
| This seems like a common misconception. Under NetBSD/Xen, NetBSD
| itself can only use a single CPU, but the Xen hypervisor itself can
| use all of them. So your VMs can have multiple CPUs and the
| hypervisor will schedule them correctly.
Without trying it then, I realized it, but it was not good for my
purposes: I wanted one VM guest at a time, using the whole processing
power of the system. Wouldn't work.
| I agree with one of the other commenters about NetBSD doing the right
| thing. Part of the reason I love NetBSD is because it seems clean and
| well designed. FreeBSD just doesn't have that same feeling to me. In
| fact, the only reason I ever use FreeBSD anymore is if I need ZFS, and
| I can't use a Solaris derivative. While it's a fine OS, it just
| doesn't have the same feeling of "done right", although it's miles
| ahead in that area compared to Linux :).
(FreeBSD 8 and 9 (beta) seem very clean to me).
Depends on the needs: sometimes I wonder why I am not using Fedora 14
or Debian on more of my systems. FUSE support, working with iPod --
something I haven't been able to do on FreeBSD. And nothing
offensive, once you set up your desktop environment.
-- Alex -- alex-go...@comcast.net --
--
Ian D. Leroux
Fixed below.
On Tue, 02 Aug 2011 21:12 +0200, "Daniel Carrera" <dcar...@gmail.com>
wrote:
> Hello,
> Still curious about the differences between NetBSD and FreeBSD, so
> Googling around I came across this post:
>
> http://mail-index.netbsd.org/port-i386/2009/02/09/msg001189.html
>
> The poster says that NetBSD is faster.
Such sweeping performance claims are nearly always silly.
> Does anyone here agree/disagree? I ask because I thought FreeBSD was
> supposed to be the speedy one. In general I don't care much about
> speed, but some times I run simulations on my computer. I have no
> idea if any BSD or Linux is particularly good for that.
Historically, the received wisdom was that FreeBSD was more heavily
and effectively optimised for i386 performance (especially server
performance) than NetBSD. FreeBSD put a lot of effort into SMP in the
early-mid 2000s which initially did bad things for single-core
performance (the infamous 5.x series, now long behind them) but gave
them a head start on effective use of multi-core processors. NetBSD
put a lot of work into this area more recently and has mostly caught
up. A very impressive series of presentations came out along with the
NetBSD-5 release to publicise this fact, showing NetBSD outrunning
FreeBSD on a number of standard benchmarks; I'll bet the post you link
to was about them. They laid to rest the idea that NetBSD was
generally slower, but I don't think they prove that NetBSD is
generally faster. Even if it was at the time the benchmarks were run,
both systems are constantly evolving.
Remember that many of the speed comparisons you see online are for
servers, or benchmarks that try to approximate server workloads. The
requirements for number-crunching simulations are likely to be quite
different, making those benchmarks more than usually useless. For
instance, in the limit that your simulations are CPU-bound the OS
should make no difference at all. In reality, differences in memory
management and disk i/o will probably have an influence, but it's very
difficult to guess how much without a careful benchmark of the
workload you care about.
In practise, proper configuration of your system is likely to make a
much bigger difference to performance than choice of OS. That, in
turn, implies that you should look for good documentation and a
community of people using the OS for purposes similar to your own, so
that you can learn how to get the best out of it.
Ian Leroux
David Wetzel
Von meinem iPhone gesendet
Alex Goncharov
|
| is its ports. Having performed few critical upgrades of FreeBSD installations
| I know pretty well where pkgsrc would have helped us not doing extra manual
| work under hard time constraints.
My impression from using NetBSD was that it's basically the same as ports:
make -C X/a/b install [package] -> Y/(bin,lib,...)
only an X and Y being different for the two OSes:
NetBSD: X=/usr/pkgsrc, Y=/usr/pkg
FreeBSD: X=/usr/ports, Y=/usr/local
I.e. if you use a "source" install, not installing pre-built packages.
Do you remember any specifics about the ports pains you had, absent from pkgsrc?
-- Alex -- alex-go...@comcast.net --
--
Daniel Carrera
> am not sure it does that for NetBSD.
"On the laptop side"? Does this mean that Nvidia builds drivers for
NetBSD on the desktop but not for laptops? I hadn't even realized that
the chipsets were different. Is this correct?
I'm curious because "one day" I hope to experiment with CUDA on an
Nvidia graphics card.
Daniel Carrera
On 08/02/2011 09:37 PM, Julio Merino wrote:
> These generalizations are misleading and harmful. Both systems are very
> fast and optimized. In the vast majority of cases, the speed at which
> they perform operations will depend on the workload and benchmarks,
> because no single system is faster than all the others in all possible
> situations. You will have to evaluate the systems for your use case and
> decide accordingly.
Ok. I've been running all the BSDs under QEMU so I have a general feel
of what they're like, but QEMU is very slow so it is difficult to go
very far in a comparison. I'm hoping to buy a new computer in the
future, when I do I'll take a few days to play with the BSDs before I
turn it into my work machine.
In principle I could take a slice of my current disk for *BSD, but
dual-booting would mean rebooting and I never reboot my computer.
> Personally, I like NetBSD over the other systems because there is a lot
> of focus in "doing the right thing" technically, and the community
> around it is very smart. As a result, NetBSD is a very clean and
> consistent system. But this is only my personal opinion!
Ok. Is this something that NetBSD and OpenBSD have in common? I know
that they share some history and both seem to have a stronger focus on
technical correctness. I've already decided I don't want OpenBSD on my
desktop but I am curious about NetBSD.
Ian D. Leroux
>
> http://mail-index.netbsd.org/port-i386/2009/02/09/msg001189.html
>
> The poster says that NetBSD is faster.
Such sweeping performance claims are nearly always silly.
> Does anyone here agree/disagree? I ask because I thought FreeBSD was
> supposed to be the speedy one. In general I don't care much about speed,
> but some times I run simulations on my computer. I have no idea if any
> BSD or Linux is particularly good for that.
Historically, the received wisdom was that FreeBSD was more heavily and
Ian Leroux
Alex Goncharov
|
| Aside:
| This caught my eye 'cos I wondered if google was necessary
| for this, so I tried the FreeBSD send-pr web direct not via
| google (using my own name first as test case)
|
| http://www.freebsd.org/cgi/query-pr-summary.cgi
| Tick: "Closed reports too:"
| Paste into Originator: s...@inbox.ru
| Nothing
|
| Paste into Originator: Aleksej Saushev
| 2 entries
"No matches to your query" for me (with either "Aleksej Saushev" or "Saushev")
And what these are:
--------------------
Closed-Date: Mon Dec 24 22:56:11 UTC 2007
Last-Modified: Mon Dec 24 22:56:11 UTC 2007
Originator: Aleksej Saushev
Release: FreeBSD 6.2-RELEASE i386
During installkernel phase of RELENG_7 into DESTDIR, too many
warnings are reported:
On Mon, Dec 24, 2007 at 01:20:36PM +0300, Yuri Pankov wrote:
> These messages are harmful and were discussed on mailing lists. Please
Sorry, I meant harmless, of course :-(
--------------------
Last-Modified: Sun Apr 16 16:33:54 GMT 2006
Originator: Aleksej Saushev
Release: FreeBSD 5.3-RELEASE i386
Category: docs
Severity: non-critical
Priority: low
--------------------
Doesn't make a case for either poor performance in FreBSD 7+ or poor developers'
responsiveness.
| Maybe he may might have also filed more under a different email
| name or with or without a middle initial (both variants make a
| difference on searching with my name) Russian names also might be
| changed to slightly different Latin font set representation by owner
| after some years ?
Maybe. (Having a Russian name myself, cannot imagine that.)
-- Alex -- alex-go...@comcast.net --
--
Aleksej Saushev
Alex Goncharov <alex-go...@comcast.net> writes:
> ,--- You/Daniel (Tue, 02 Aug 2011 21:12:48 +0200) ----*
> |
> | http://mail-index.netbsd.org/port-i386/2009/02/09/msg001189.html
> |
> | The poster says that NetBSD is faster.
>
> In my experiments, FreeBSD proved to be an altogether better
> environment, with a superior developer support (just more people in
> the project, perhaps).
I turned to NetBSD from FreeBSD just because of these reasons.
Given the number of people in project, FreeBSD has much worse performance
in my opinion. I have no other explanation why documentation and simple
one-line fixes have to sit in PR database for two years before being committed
(yes, it was exactly that what pissed me off the most around year 2007).
This also explains why it is better first to read NetBSD documentation
and then check for difference between systems when dealing with FreeBSD.
Another thing I didn't like in FreeBSD after getting acquainted with NetBSD,
is its ports. Having performed few critical upgrades of FreeBSD installations
I know pretty well where pkgsrc would have helped us not doing extra manual
work under hard time constraints.
> ,--- You/Daniel (Tue, 02 Aug 2011 21:16:37 +0200) ----*
> |
> | Isn't Xen just a virtual machine like QEMU, VirtualBox, etc? What makes
> | Xen special that people here talk about it while they don't talk about
> | QEMU and VirtualBox?
>
> VirtualBox works well on FreeBSD, and was significantly easier to
> configure than Xen on NetBSD when I used that.
Howto is pretty straightforward, I don't understand where you have found
problems in this respect.
--
HE CE3OH...
Alex Goncharov
|
|
| The poster says that NetBSD is faster.
Since it was in response to my explorations: no offense to the NetBSD
users and developers, but after trying to use NetBSD for a while, I
had to turn back to FreeBSD, completely. The performance of my
desktop environment has never been an issue for me, and if some
programs run 5% slower on FreeBSD, why would I care? (But they
probably not, in recent FreeBSDs).
In my experiments, FreeBSD proved to be an altogether better
environment, with a superior developer support (just more people in
the project, perhaps).
But NetBSD technical lists are useful to watch, so here I am, even not
planning to use NetBSD again.
| Does anyone here agree/disagree?
I have seen no reason to agree.
,--- You/Daniel (Tue, 02 Aug 2011 21:16:37 +0200) ----*
|
| Isn't Xen just a virtual machine like QEMU, VirtualBox, etc? What makes
| Xen special that people here talk about it while they don't talk about
| QEMU and VirtualBox?
VirtualBox works well on FreeBSD, and was significantly easier to
configure than Xen on NetBSD when I used that. Also, that Xen (about
three years ago) used only one processor of a dual processor machine
-- I didn't like that at all and my Xen was quickly gone.
-- Alex -- alex-go...@comcast.net --
Julian H. Stacey
> ,--- You/Aleksej (Wed, 03 Aug 2011 11:47:27 +0400) ----*
> | Alex Goncharov <alex-go...@comcast.net> writes:
> | > In my experiments, FreeBSD proved to be an altogether better
> | > environment, with a superior developer support (just more people in
> | > the project, perhaps).
> |
> | I turned to NetBSD from FreeBSD just because of these reasons.
> | Given the number of people in project, FreeBSD has much worse performance
> | in my opinion.
>
> Curious, in what areas?
>
> | I have no other explanation why documentation and simple
> | one-line fixes have to sit in PR database for two years before being committed
> | (yes, it was exactly that what pissed me off the most around year 2007).
>
> I googled "Aleksej Saushev FreeBSD" hoping to hit a FreeBSD list with
> your PRs, just to see the areas and histories -- no easy hit. Can you
> give me a pointer -- for my education, not to counter your points?
>
> -- Alex -- alex-go...@comcast.net --
Aside:
This caught my eye 'cos I wondered if google was necessary
for this, so I tried the FreeBSD send-pr web direct not via
google (using my own name first as test case)
http://www.freebsd.org/cgi/query-pr-summary.cgi
Tick: "Closed reports too:"
Paste into Originator: s...@inbox.ru
Nothing
Paste into Originator: Aleksej Saushev
2 entries
Maybe he may might have also filed more under a different email
name or with or without a middle initial (both variants make a
difference on searching with my name) Russian names also might be
changed to slightly different Latin font set representation by owner
after some years ?
PS I've had some PRs sit a Lot longer than 2 years in FreeBSD. (
Not complaining though. Our BSDs are volunteer efforts,
Our send-pr's are sent in hope of catching the eyes of commiters
who have other real life commitments too :-)
Cheers,
Julian
--
Julian Stacey, BSD Unix Linux C Sys Eng Consultants Munich http://berklix.com
Reply below, not above; Indent with "> "; Cumulative like a play script.
Format: Plain text. Not HTML, multipart/alternative, base64, quoted-printable.
Johnny Billquist
> ,--- I/Alex (Tue, 02 Aug 2011 15:33:06 -0400) ----*
> |
> | users and developers, but after trying to use NetBSD for a while, I
> | had to turn back to FreeBSD, completely.
>
> On the topic of the "vs".
>
> A huge difference between Net* and Free* is the disk labeling and
> partitioning schemas: I spent innumerable hours learning the
> subtleties of the NetBSD partitioning and had to modify the labels by
> hand setting four OSes on one system: i386 and amd64 of each NetBSD
> and FreeBSD. NetBSD partitioning felt unbelievably complex and
> inflexible compared to the FreeBSD. A new install of NetBSD on a disk
> was practically a guaranteed way to disable or blow away an existing
> FreeBSD installation, wherever a FreeBSD has never done any damage to
> anything already on the disk in my long use of it.
>
> And on the laptop side: Nvidia builds drivers for Linux and FreeBSD. I
> am not sure it does that for NetBSD.
>
> Just summarizing my experience.
I understand the experience, but the reason behind it is the total
opposite, I'd say. The disk labeling system in NetBSD is the more
flexible of the two. But that comes with an added complexity.
However, the complexity arise from the fact that there is another
partitioning scheme as well (for PC systems). The NetBSD disk
partitioning is the pure, original BSD disk labels, which are machine
agnostic and are designed for clean disks. The additional cruft in a PC
is what creates all the confusion, with the MBR partitioning.
NetBSD bascially ignores it (well, it can read this, manipulate it, and
use it to help you setup a BSD partition), and only uses its own
partitioning. That causes confusion unless you understand all of it.
The partitioning in other systems acts as sub-partitioning under the PC
MBR partitioning scheme.
For me, that is a much more confusing thing, since I look at the BSD
partitioning as the master (I'm used to non-PC systems).
The BSD partitioning, as set up on a NetBSD system is free to use all or
nothing of the disk, as you want. Total freedom. Total flexibility.
Johnny
peas...@shaw.ca
Date: Wed, 03 Aug 2011 12:16:10 +0200
> I understand the experience, but the reason behind it is the total
> opposite, I'd say. The disk labeling system in NetBSD is the more
> flexible of the two. But that comes with an added complexity.
>
> However, the complexity arise from the fact that there is another
> ...
> ... Total freedom. Total flexibility.
Helpful explanation. If not in formal documentation already, it
should be.
Thanks, ... Peter E.
--
Telephone 1 360 450 2132. bcc: peasthope at shaw.ca
Shop pages http://carnot.yi.org/ accessible as long as the old drives survive.
Personal pages http://members.shaw.ca/peasthope/ .
Dave Huang
On Aug 2, 2011, at 2:17 PM, David Wetzel wrote:
> FreeBSD has a better new USB stack but nobody seems to be interested to have it on netbsd.
I'm interested, but I probably don't have the skills needed to port it over :(
That's assuming it'll fix things like http://mail-index.netbsd.org/netbsd-users/2011/02/11/msg007808.html , the lack of EHCI transaction translator support, and occasional kernel traps when unplugging devices.
Ian D. Leroux
> From: Johnny Billquist <b...@softjar.se> Date: Wed, 03 Aug 2011
> 12:16:10 +0200
> > I understand the experience, but the reason behind it is the total
> > opposite, I'd say. The disk labeling system in NetBSD is the more
> > flexible of the two. But that comes with an added complexity.
> >
> > However, the complexity arise from the fact that there is another
> > partitioning scheme as well (for PC systems). ... ... ... Total
> > freedom. Total flexibility.
>
> Helpful explanation. If not in formal documentation already, it
> should be.
I'd add that NetBSD behaves consistently everywhere (or at least tries
really hard), including quite a few platforms that don't have DOS-style
MBRs on their disks. The price you pay for cross-platform consistency
is occasional failure to conform to the local conventions of particular
platforms. Whether consistency within the OS is more or less important
than consistency with other OSen on particular hardware is a matter of
taste.
Ian Leroux
Ian D. Leroux
Ian D. Leroux
Aleksej Saushev
> ,--- You/Aleksej (Wed, 03 Aug 2011 11:47:27 +0400) ----*
> |
> | Another thing I didn't like in FreeBSD after getting acquainted with NetBSD,
> | is its ports. Having performed few critical upgrades of FreeBSD installations
> | I know pretty well where pkgsrc would have helped us not doing extra manual
> | work under hard time constraints.
>
> My impression from using NetBSD was that it's basically the same as ports:
>
> make -C X/a/b install [package] -> Y/(bin,lib,...)
>
> only an X and Y being different for the two OSes:
>
> NetBSD: X=/usr/pkgsrc, Y=/usr/pkg
> FreeBSD: X=/usr/ports, Y=/usr/local
If you don't go any further than just installing few packages and
updating leaf ones, then you may have this impression. Real life is more
complex than that.
> I.e. if you use a "source" install, not installing pre-built packages.
>
> Do you remember any specifics about the ports pains you had, absent from pkgsrc?
Sure.
The first and the main problem is that FreeBSD packages don't depend on
packages, they depend on files instead. This means that if you have some
stray file in your /usr/local, you get wrong assumptions when building.
Consequences go far beyond a mere inconvenience: you have to manipulate
your installed packages to get consistently built dependents, you have
to watch out for correct handling of packaging list, the latter is
non-trivial given the complete absence of staged installation support,
there's no way to restrict versions of compatible packages, which means
that you have to watch for it yourself, and so on. In conjunction with
no isolation of build environment from installed packages this can cause
an update nightmare.
Another problem is that it is impossible (or rather hard at the very least)
to deploy parallel installation of packages under another prefix.
This means that once you need to use a conflicting package, you have
to employ various overly complex tricks for it. With pkgsrc I bootstrap
another set of tools and after that I have easy access to another
version of PostgreSQL client and server, another set of MPI tools,
another set of TCL tools, packages from another pkgsrc branch, and so on.
This also allows rather convenient maintainance approach, when you never
update your packages (you build and install new ones instead, just use
another prefix like "/usr/pkg-2011Q2").
--
HE CE3OH...
Daniel Carrera
>> Do you remember any specifics about the ports pains you had, absent from pkgsrc?
>
>
> The first and the main problem is that FreeBSD packages don't depend on
> packages, they depend on files instead.
Ooops! That's not package management at all. That sounds totally
unreliable. I'm sure that it works "fine" most of the time, but I still
wouldn't trust it.
Out of curiosity, do you know if the same is true for OpenBSD?
Daniel.
--
I'm not overweight, I'm undertall.
--
Alistair Crooks
> I.e. if you use a "source" install, not installing pre-built packages.
>
> Do you remember any specifics about the ports pains you had, absent from pkgsrc?
my main gripe, as a user, was the absence of audit-packages, and the
need to specify either the precise version number of a package, or
remember to wildcard things, when using the pkg_install tools, with
possibly interesting effects if dealing with something like libtool-\*
and libtool-base-\*
pkgsrc is quite a different beast these days. my 2002 talk at
eurobsdcon outlined some of the differences between ports and pkgsrc,
and there were 50+ slides in that section - since then, pkgsrc has
diverged even more.
the main differences i'd point out nowadays are the ...ummm
portability of pkgsrc, the dewey comparison of version numbers making
it possible to do audit-packages and the like, and pkgsrc's buildlink
infrastructure, which has two advantages:
1. it allows pkgsrc packages to be built with exactly the versions of
software that are wanted, and not what happens to be already installed
in /usr/local - to illustrate, imagine that ncurses is installed, and
another package's configure script checks for the presence of ncurses
(bad example, since i think freebsd has ncurses in base, but ykwim)
2. isolates dependencies so that dangling or hidden dependencies just
do not happen.
the net effect of this is to simplfy pkgsrc entry makefiles - take a look
at the bottom of pkgsrc/sysutils/libvirt/Makefile:
.include "../../lang/python/application.mk"
.include "../../lang/python/extension.mk"
.include "../../devel/gettext-lib/buildlink3.mk"
.include "../../devel/readline/buildlink3.mk"
.include "../../security/gnutls/buildlink3.mk"
.include "../../security/cyrus-sasl/buildlink3.mk"
.include "../../textproc/libxml2/buildlink3.mk"
.include "../../textproc/py-xml/buildlink3.mk"
.include "../../www/curl/buildlink3.mk"
.include "../../mk/pthread.buildlink3.mk"
.include "../../mk/bsd.pkg.mk"
for more on buildlink, see
http://www.netbsd.org/docs/pkgsrc/buildlink.html
in addition, from a user's pov, pkgsrc's config file handling is done
in a smart way so that any changes to standard configs are preserved,
rc.d scripts can optionally be installed to /etc so that they work out
of the box, and much, much more.
regards,
alistair
Alex Goncharov
| Alex Goncharov <alex-go...@comcast.net> writes:
| > ,--- You/Aleksej (Wed, 03 Aug 2011 11:47:27 +0400) ----*
| >
| >
| > make -C X/a/b install [package] -> Y/(bin,lib,...)
| >
| > only an X and Y being different for the two OSes:
| >
| > NetBSD: X=/usr/pkgsrc, Y=/usr/pkg
| > FreeBSD: X=/usr/ports, Y=/usr/local
|
| updating leaf ones, then you may have this impression. Real life is more
| complex than that.
I update my FreeBSD packages roughly every two weeks, building them from
the source. Hickups do happen, but nothing non-surmountable. Besides,
now FreeBSD has a powerful 'portmaster' tool to handle complex
dependencies -- gets a lot of attention and effort (but I don't use it).
| The first and the main problem is that FreeBSD packages don't depend on
| packages,
They do:
----------------------------------------
pkg_info -xr emacs| head -n 4
Information for emacs-23.3_1,2:
Depends on:
Dependency: xineramaproto-1.2
----------------------------------------
make -C editors/emacs all-depends-list | head -n 4
/usr/ports/devel/gmake
/usr/ports/x11/libX11
/usr/ports/x11/libXpm
/usr/ports/x11-fonts/libXft
----------------------------------------
| they depend on files instead.
See above.
| This means that if you have some
| stray file in your /usr/local, you get wrong assumptions when building.
You may, due to gconf and such. Don't have stray files in /usr/local.
Don't 'ln -s true false' etc.
| Another problem is that it is impossible (or rather hard at the very least)
| to deploy parallel installation of packages under another prefix.
Hmm... From /usr/ports/Mk/bsd.port.mk:
----------------------------------------
# X11BASE - Where X11 ports install things.
# Default: ${LOCALBASE}
# LOCALBASE - Where non-X11 ports install things.
# Default: /usr/local
----------------------------------------
| This means that once you need to use a conflicting package, you have
| to employ various overly complex tricks for it. With pkgsrc I bootstrap
| another set of tools and after that I have easy access to another
| version of PostgreSQL client and server, another set of MPI tools,
| another set of TCL tools, packages from another pkgsrc branch, and so on.
| This also allows rather convenient maintainance approach, when you never
| update your packages (you build and install new ones instead, just use
| another prefix like "/usr/pkg-2011Q2").
So, on FreeBSD
make -C editors/emacs LOCALBASE=/usr/pkg-2011Q2 install
would probably work. I guess. Won't try due to the lack of a need.
| HE CE3OH...
подумал Штирлиц... и сплюнул... в сугроб...
Daniel Carrera
> Alex Goncharov<alex-go...@comcast.net> writes:
>> I.e. if you use a "source" install, not installing pre-built packages.
>>
>> Do you remember any specifics about the ports pains you had, absent from pkgsrc?
>
> need to specify either the precise version number of a package, or
> remember to wildcard things, when using the pkg_install tools, with
> possibly interesting effects if dealing with something like libtool-\*
> and libtool-base-\*
Yesterday I started experimenting with OpenBSD again and I noticed that.
It has been quite irritating. I don't like using wildcards, so half the
time I end up typing the "pkg_add" command twice: Once to find out the
exact package name and another to actually install.
Another annoyance, as a noob, is that OpenBSD by default partitions your
disk into umpteen partitions and /usr/local turned out to be too small
for all the things I wanted to install (I basically want a full desktop
system) so now I have to re-install and learn the partition tool. With
NetBSD and FreeBSD I didn't have to learn the partition tool, I could
just say "use the whole disk and don't bother me with the details".
> pkgsrc is quite a different beast these days. my 2002 talk at
> eurobsdcon outlined some of the differences between ports and pkgsrc,
> and there were 50+ slides in that section - since then, pkgsrc has
> diverged even more.
Do you have that talk somewhere?
> the main differences i'd point out nowadays are the ...ummm
> portability of pkgsrc, the dewey comparison of version numbers making
> it possible to do audit-packages and the like, and pkgsrc's buildlink
> infrastructure, which has two advantages:
Can you explain the audit part? I don't know what you mean.
> 1. it allows pkgsrc packages to be built with exactly the versions of
> software that are wanted, and not what happens to be already installed
> in /usr/local - to illustrate, imagine that ncurses is installed, and
> another package's configure script checks for the presence of ncurses
> (bad example, since i think freebsd has ncurses in base, but ykwim)
OpenBSD seems to do that too. I had installed python 2.5 and when I
installed something else (I think it was GIMP) it downloaded python 2.6.
Maybe I missed your point?
> 2. isolates dependencies so that dangling or hidden dependencies just
> do not happen.
Can you explain this part? I'm a noob to all BSD.
> for more on buildlink, see
>
> http://www.netbsd.org/docs/pkgsrc/buildlink.html
*click*
Daniel.
--
I'm not overweight, I'm undertall.
--
Aleksej Saushev
> ,--- You/Aleksej (Thu, 04 Aug 2011 02:08:19 +0400) ----*
> | Alex Goncharov <alex-go...@comcast.net> writes:
> | > ,--- You/Aleksej (Wed, 03 Aug 2011 11:47:27 +0400) ----*
> | >
> | > My impression from using NetBSD was that it's basically the same as ports:
> | >
> | > make -C X/a/b install [package] -> Y/(bin,lib,...)
> | >
> | > only an X and Y being different for the two OSes:
> | >
> | > NetBSD: X=/usr/pkgsrc, Y=/usr/pkg
> | > FreeBSD: X=/usr/ports, Y=/usr/local
> |
> | If you don't go any further than just installing few packages and
> | updating leaf ones, then you may have this impression. Real life is more
> | complex than that.
>
> I update my FreeBSD packages roughly every two weeks, building them from
> the source. Hickups do happen, but nothing non-surmountable. Besides,
> now FreeBSD has a powerful 'portmaster' tool to handle complex
> dependencies -- gets a lot of attention and effort (but I don't use it).
>
> | The first and the main problem is that FreeBSD packages don't depend on
> | packages,
>
> They do:
>
> ----------------------------------------
> pkg_info -xr emacs| head -n 4
> Information for emacs-23.3_1,2:
>
> Depends on:
> Dependency: xineramaproto-1.2
> ----------------------------------------
> make -C editors/emacs all-depends-list | head -n 4
> /usr/ports/devel/gmake
> /usr/ports/x11/libX11
> /usr/ports/x11/libXpm
> /usr/ports/x11-fonts/libXft
> ----------------------------------------
>
> | they depend on files instead.
>
> See above.
What is it in makefiles?
> | This means that if you have some
> | stray file in your /usr/local, you get wrong assumptions when building.
>
> You may, due to gconf and such. Don't have stray files in /usr/local.
> Don't 'ln -s true false' etc.
"Don't have stray files" is an advice akin to "don't make mistakes" and
"don't write buggy code." Does FreeBSD's ports collection support staged
installation? How many packages are there that are not converted?
> | Another problem is that it is impossible (or rather hard at the very least)
> | to deploy parallel installation of packages under another prefix.
>
> Hmm... From /usr/ports/Mk/bsd.port.mk:
>
> ----------------------------------------
> # X11BASE - Where X11 ports install things.
> # Default: ${LOCALBASE}
> # LOCALBASE - Where non-X11 ports install things.
> # Default: /usr/local
> ----------------------------------------
Can I have more than one LOCALBASE?
> | This means that once you need to use a conflicting package, you have
> | to employ various overly complex tricks for it. With pkgsrc I bootstrap
> | another set of tools and after that I have easy access to another
> | version of PostgreSQL client and server, another set of MPI tools,
> | another set of TCL tools, packages from another pkgsrc branch, and so on.
> | This also allows rather convenient maintainance approach, when you never
> | update your packages (you build and install new ones instead, just use
> | another prefix like "/usr/pkg-2011Q2").
>
> So, on FreeBSD
>
> make -C editors/emacs LOCALBASE=/usr/pkg-2011Q2 install
>
> would probably work. I guess.
Do you mean that I am to pass all those settings along?
Am I to implement some dispatching in mk.conf?
Will those packages check /usr/local when building? What if they do?
(I remember programs that used to check and maybe still check for
libraries in /usr/local when building on FreeBSD.) This may surprise
you not in an unpleasant way some day.
> Won't try due to the lack of a need.
That's what I mean when I tell of simplistic usage patterns.
--
HE CE3OH...
Jeremy C. Reed
> > the main differences i'd point out nowadays are the ...ummm
> > portability of pkgsrc, the dewey comparison of version numbers making
> > it possible to do audit-packages and the like, and pkgsrc's buildlink
> > infrastructure, which has two advantages:
>
> Can you explain the audit part? I don't know what you mean.
pkg_admin fetch-pkg-vulnerabilities
pkg_admin audit
(oh I have much to upgrade :)
Some NetBSD developers maintain a text file listing packages that have
vulnerabilities. audit-packages (the old name) is used to compare your
installed packages with that list. The output gives a very short keyword
description and a URL for details (for every match).
> > 1. it allows pkgsrc packages to be built with exactly the versions of
> > software that are wanted, and not what happens to be already installed
> > in /usr/local - to illustrate, imagine that ncurses is installed, and
> > another package's configure script checks for the presence of ncurses
> > (bad example, since i think freebsd has ncurses in base, but ykwim)
>
> OpenBSD seems to do that too. I had installed python 2.5 and when I
> installed something else (I think it was GIMP) it downloaded python
> 2.6. Maybe I missed your point?
A new package should be installed consistently the same regardless of
what you already had installed on your system.
> > 2. isolates dependencies so that dangling or hidden dependencies just
> > do not happen.
>
> Can you explain this part? I'm a noob to all BSD.
One way is creating wrappers and symlinks for much of the dependencies
and then forcing the build to use them instead.
(Not BSD specific.)
Daniel Carrera
>> Can you explain the audit part? I don't know what you mean.
>
> pkg_admin fetch-pkg-vulnerabilities
>
> pkg_admin audit
>
> (oh I have much to upgrade :)
>
> Some NetBSD developers maintain a text file listing packages that have
> vulnerabilities. audit-packages (the old name) is used to compare your
> installed packages with that list. The output gives a very short keyword
> description and a URL for details (for every match).
That's interesting. Thanks.
>>> 2. isolates dependencies so that dangling or hidden dependencies just
>>> do not happen.
>>
>> Can you explain this part? I'm a noob to all BSD.
>
>
> One way is creating wrappers and symlinks for much of the dependencies
> and then forcing the build to use them instead.
>
> (Not BSD specific.)
Ok.
--
I'm not overweight, I'm undertall.
--
Alex Goncharov
|
| > | they depend on files instead.
| >
| > See above.
|
Can't understand your question.
| > So, on FreeBSD
| >
| > make -C editors/emacs LOCALBASE=/usr/pkg-2011Q2 install
| >
| > would probably work. I guess.
|
| Do you mean that I am to pass all those settings along?
| Am I to implement some dispatching in mk.conf?
|
| Will those packages check /usr/local when building? What if they do?
| (I remember programs that used to check and maybe still check for
| libraries in /usr/local when building on FreeBSD.) This may surprise
| you not in an unpleasant way some day.
|
| > Won't try due to the lack of a need.
|
| That's what I mean when I tell of simplistic usage patterns.
Contrary to most other posts in this thread, I find this one (yours,
that is) written from the perspective, "Never surrender". pkgsrc may
have some advantage over the port system, as outlined in this message:
,--- Alistair Crooks (Thu, 4 Aug 2011 06:29:49 +0200) ----*
|
| my main gripe, as a user, was the absence of audit-packages, and the
| need to specify either the precise version number of a package, or
| remember to wildcard things, when using the pkg_install tools, with
| possibly interesting effects if dealing with something like libtool-\*
| and libtool-base-\*
|
`---------------------------------------------------------*
but:
a. Nothing prevents you from using it on FreeBSD (AFAIU).
b. You haven't demonstrated, with an example (I could run it for you
on a FreeBSD, if it's brief enough) any functional deficiency of
a FreeBSD port system.
I realize that you don't have a reason to do "b", just pointing that
fact out.
Jeremy C. Reed
> | my main gripe, as a user, was the absence of audit-packages, and the
> | need to specify either the precise version number of a package, or
> | remember to wildcard things, when using the pkg_install tools, with
> | possibly interesting effects if dealing with something like libtool-\*
> | and libtool-base-\*
> |
> `---------------------------------------------------------*
>
> but:
>
> a. Nothing prevents you from using it on FreeBSD (AFAIU).
Our vulnerability database contains pkgsrc package versioning. They will
most likely not match up with FreeBSD's port's package versions.
Anyways, FreeBSD does have similar tool: portaudit and its FreeBSD ports
security issues database. (I have set it up a few times for daily
reports.)
I use FreeBSD ports on a few systems for work.
Some things I like about pkgsrc:
- use on multiple operating systems. I use it on Linux, Solaris, Mac OS
X, and other systems. (Even on old FreeBSD systems where ports was
desupported.)
- pkgsrc developers make it a priority to portably patch (so not just
specific to NetBSD) and share patches back upstream.
- choose to use an operating system's own X or pkgsrc's X Windowing
System.
- not interactive (once I set it up to use sudo). (I know FreeBSD ports
can be configured to not prompt me.)
- customize where configurations are placed and used and it doesn't
overwrite configurations. (And rc.d scripts)
- help from make (describe and teaches about options and commands)
- option framework (FreeBSD has similar and has nice interactive menu
too).
- staged installs which also verify constitency (now by default)
- may choose between native dependencies versus using packages (for many
things)
- depot-style installs (some still use it, but I have not used it in a
few years)
- automated wrappers for build system and consistent build environments
and more resulting in consistent packaging regardless of what may be
installed.
- multiple tools and techniques for upgrades (both binary packages and
pkgsrc builds)
- pkg_summary database
- detailed documentation on pkgsrc
- pkgsrc-wip (others can contribute and a playground for testing)
- can override specific version dependencies (dangerous but I use it)
- miscellaneous options like papersize
- specific user and group management for packages
- emailing of MESSAGE files.
- some pkgsrc builds allow running their tests
- choosing acceptable or not-acceptable licenses.
- able to check for library versions (FreeBSD has this some too, but I
think is done manually)
- in some cases, pkgsrc has more up-to-date packages for what I need at
that time. (But that argument can easily be reversed for others
needs.)
- use pkgsrc as non-root and install and use in my own home
But overall both do basically the same thing and FreeBSD does have more
packages (and Debian has more too :)
Alex Goncharov
| Alex Goncharov <alex-go...@comcast.net> writes:
| > Do you remember any specifics about the ports pains you had, absent from pkgsrc?
|
| need to specify either the precise version number of a package,
On audit-packages, I know nothing, no comment.
On the version, I don't completely understand you:
1. It would be helpful if you and others, when talking about the
FreeBSD ports system, clearly differentiated between installing a
package (e.g 'pkg_add emacs-23.3_1,2.tbz') and "from a port"
(e.g. 'make -C editors/emacs').
2. If the former is meant:
a. And you install from /usr/ports/packages/All, what's the
problem with specifying a version -- and how could it work
without one if there were multiple emacs-*tbz files in that
directory?
b. And you install remotely, via 'pkg_add -r', you don't need to
specify a version: 'pkg_add -r emacs' will fetch and install
something meaningful for you, doing necessary checks.
3. If the later is meant, the major version may have to be
specified -- because it matters:
make -C java/openjdk<X> (X: one of 6 or 7 -- very different.)
| remember to wildcard things, when using the pkg_install tools, with
| possibly interesting effects if dealing with something like libtool-\*
| and libtool-base-\*
On my 8.2 system now:
----------------------------------------
ls -d /usr/ports/devel/libtool*
=>
/usr/ports/devel/libtool/
----------------------------------------
| the main differences i'd point out nowadays are the ...ummm
| portability of pkgsrc,
Where do people want to port FreeBSD ports system? What people? Why
would that be important for a FreeBSD user?
| the dewey comparison of version numbers making
| it possible to do audit-packages and the like, and pkgsrc's buildlink
| infrastructure, which has two advantages:
|
| 1. it allows pkgsrc packages to be built with exactly the versions of
| software that are wanted, and not what happens to be already installed
| in /usr/local - to illustrate, imagine that ncurses is installed, and
| another package's configure script checks for the presence of ncurses
| (bad example, since i think freebsd has ncurses in base, but ykwim)
This all seems very far-fetched.
----------------------------------------
ls -d1 /usr/ports/databases/postgresql*server
/usr/ports/databases/postgresql82-server/
/usr/ports/databases/postgresql83-server/
/usr/ports/databases/postgresql84-server/
/usr/ports/databases/postgresql90-server/
/usr/ports/databases/postgresql91-server/
ls -d1 /usr/ports/databases/mysql*server
/usr/ports/databases/mysql323-server/
/usr/ports/databases/mysql40-server/
/usr/ports/databases/mysql41-server/
/usr/ports/databases/mysql50-server/
/usr/ports/databases/mysql51-server/
/usr/ports/databases/mysql55-server/
s -d1 /usr/ports/editors/openoffice.org-*
/usr/ports/editors/openoffice.org-2/
/usr/ports/editors/openoffice.org-3/
/usr/ports/editors/openoffice.org-3-RC/
/usr/ports/editors/openoffice.org-3-devel/
/usr/ports/editors/openoffice.org-vcltesttool/
----------------------------------------
Does one really need more than that?
| 2. isolates dependencies so that dangling or hidden dependencies just
| do not happen.
'pkgdb -F' won't do it for you on FreeBSD?
| in addition, from a user's pov, pkgsrc's config file handling is done
| in a smart way so that any changes to standard configs are preserved,
| rc.d scripts can optionally be installed to /etc so that they work
| out
Any port rc.d script is installed (with either install method) under
/usr/local/etc/rc.d and works out of the box (subject to rc.conf
X_enable=YES, of course).
| of the box, and much, much more.
It is quite possible that pkgsrc has some advantages for a very
sophisticated use, but it seems to me that in comparing it with
FreeBSD ports some of the obvious capacities of the latter are
overlooked.
Such as '-p' and '-P' of pkg_add:
----------------------------------------
PKG_ADD(1) FreeBSD General Commands Manual PKG_ADD(1)
NAME
pkg_add -- a utility for installing software package distributions
SYNOPSIS
pkg_add [-viInfFrRMSK] [-t template] [-p prefix] [-P prefix]
[-C chrootdir] pkg-name [pkg-name ...]
pkg-name [pkg-name ...]
The named packages are installed. A package name of - will cause
pkg_add to read from stdin. If the packages are not found in the
current working directory, pkg_add will search them in each
directory named by PKG_PATH.
-p, --prefix prefix
Set prefix as the directory in which to extract files from a
package. If a package has set its default directory, it will be
overridden by this flag. Note that only the first @cwd directive
will be replaced, since pkg_add has no way of knowing which
directory settings are relative and which are absolute. It is
rare in any case to see more than one directory transition made,
but when such does happen and you wish to have control over *all*
directory transitions, then you may then wish to look into the
use of MASTER and SLAVE modes (see the -M and -S options). If
the -p flag appears after any -P flag on the command line, it
overrides its effect, causing pkg_add not to use the given prefix
recursively.
-P prefix
Does the same as the -p option, except that the given prefix is
also used recursively for the dependency packages, if any. If
the -P flag appears after any -p flag on the command line, it
overrides its effect, causing pkg_add to use the given prefix
recursively.
----------------------------------------
Alex Goncharov
| On Thu, 4 Aug 2011, Alex Goncharov wrote:
|
|
| Some things I like about pkgsrc:
|
| - use on multiple operating systems. I use it on Linux, Solaris, Mac OS
| X, and other systems. (Even on old FreeBSD systems where ports was
| desupported.)
I would undoubtedly use 'pkgsrc' had I regularly need open-source
software on Solaris or AIX... and maybe even on Linux... But on
FreeBSD all my needs are met by ports. "My needs" -- not claiming
"everybody's", but I am probably more typical than an atypical FreeBSD
user.
| - choose to use an operating system's own X or pkgsrc's X Windowing
| System.
"Own X" -- not Xorg, I figure? How well does it work with modern X
applications? What's the reason for not using Xorg? (There has been
maddening upgrade problems with that, but for the last couple of years
Xorg seems to be good and painless.)
| - not interactive (once I set it up to use sudo). (I know FreeBSD ports
| can be configured to not prompt me.)
To my shame, I haven't found an option not to pop up an option menu
when a port is first installed. Didn't try hard enough, perhaps. I
see your point here.
| - customize where configurations are placed and used and it doesn't
| overwrite configurations. (And rc.d scripts)
For all ports I am using, the configurations have never been
overwritten by an upgrade.
| - help from make (describe and teaches about options and commands)
Nice!
| - option framework (FreeBSD has similar and has nice interactive menu
| too).
I wish I knew how to avoid the menus and just use the defaults (see
above.)
| - miscellaneous options like papersize
This is in FreeBSD ports options, somewhere; e.g. I set papersize to
'letter'.
| - able to check for library versions (FreeBSD has this some too, but I
| think is done manually)
There are some checks, on a port-by-port basis...
| - in some cases, pkgsrc has more up-to-date packages for what I need at
| that time. (But that argument can easily be reversed for others
| needs.)
This is a function of a specific port maintainer's activity. In my
experience, the key ports track the upstream quickly enough. Just
"install from ports" rather than wait for a package.
Yours was a very good itemized description of "pkgsrc" vs. "ports"
potential differences -- thank you!
| But overall both do basically the same thing and FreeBSD does have more
| packages (and Debian has more too :)
At last: "overall both do basically the same thing"!.. Thank you!
(I've felt similarly.)
Jeremy C. Reed
> | 1. it allows pkgsrc packages to be built with exactly the versions of
> | software that are wanted, and not what happens to be already installed
> | in /usr/local - to illustrate, imagine that ncurses is installed, and
> | another package's configure script checks for the presence of ncurses
> | (bad example, since i think freebsd has ncurses in base, but ykwim)
>
> This all seems very far-fetched.
It is certainly a real issue. Many software when built outside of ports
(or outside of pkgsrc) defaults to installing to /usr/local/. So simply
the addition of an include file, some binary, some library, some
pkg-config file, et cetera, may in the future
enable/disable/break/enhance or otherwise change some later "ports"
build resulting in a package possible different than what was expected.
Even if the package list is the same, it may have new dependencies or
capabilities not expected. And after removing the "/usr/local" addition
(whatever it was) may break the package like removing a shared library
(and since not registered as a package dependency it won't warn you).
Even if you choose a custom localbase, the problem is still possible
since /usr/local is often still looked at. pkgsrc builds work very
hard to make sure /usr/local and /usr/pkg are not looked at when
building packages.
> ----------------------------------------
> ls -d1 /usr/ports/databases/postgresql*server
> /usr/ports/databases/postgresql82-server/
> /usr/ports/databases/postgresql83-server/
> /usr/ports/databases/postgresql84-server/
> /usr/ports/databases/postgresql90-server/
> /usr/ports/databases/postgresql91-server/
>
>
> ls -d1 /usr/ports/databases/mysql*server
> /usr/ports/databases/mysql323-server/
> /usr/ports/databases/mysql40-server/
> /usr/ports/databases/mysql41-server/
> /usr/ports/databases/mysql50-server/
> /usr/ports/databases/mysql51-server/
> /usr/ports/databases/mysql55-server/
>
> s -d1 /usr/ports/editors/openoffice.org-*
> /usr/ports/editors/openoffice.org-2/
> /usr/ports/editors/openoffice.org-3/
> /usr/ports/editors/openoffice.org-3-RC/
> /usr/ports/editors/openoffice.org-3-devel/
> /usr/ports/editors/openoffice.org-vcltesttool/
>
> ----------------------------------------
>
> Does one really need more than that?
I think there was a misunderstanding, so I don't understand context of
that.
> | 2. isolates dependencies so that dangling or hidden dependencies just
> | do not happen.
>
> 'pkgdb -F' won't do it for you on FreeBSD?
Also different. That is for fixing later.
The "hidden" dependencies in question are those detected at build time
(described above).
> | in addition, from a user's pov, pkgsrc's config file handling is done
> | in a smart way so that any changes to standard configs are preserved,
> | rc.d scripts can optionally be installed to /etc so that they work
> | out
>
> Any port rc.d script is installed (with either install method) under
> /usr/local/etc/rc.d and works out of the box (subject to rc.conf
> X_enable=YES, of course).
Yes. pkgsrc offers "staged" rc.d scripts, so they are installed as
examples and optionally put in place to use (if a custom version is not
already there).
> | of the box, and much, much more.
>
> It is quite possible that pkgsrc has some advantages for a very
> sophisticated use, but it seems to me that in comparing it with
> FreeBSD ports some of the obvious capacities of the latter are
> overlooked.
>
> Such as '-p' and '-P' of pkg_add:
pkgsrc had those too. I think the master/slave mode was removed, but
basic functionality of these are the same. Note that the FreeBSD-style
of "staged" (master/slave) mode at binary package install time is
different than pkgsrc's build-time staged installs. (I am curious does
anyone use FreeBSD's pkg_add master/slave installs and why?)
The concept of changing the install prefix at pkg_add time is much
different than choosing a custom prefix at build time.
Alistair Crooks
> | But overall both do basically the same thing and FreeBSD does have more
> | packages (and Debian has more too :)
>
> At last: "overall both do basically the same thing"!.. Thank you!
> (I've felt similarly.)
Beware of playing the numbers game, since a "package" or a
"ports/pkgsrc entry" may not mean the same thing. Debian packages
tend to split things up into the smallest component - Debian's boost
had 27 packages - one for headers, one for docs, etc, and this was
back in 2006. pkgsrc counts 2 "packages" for py25 and py26 packages,
although 1 pkgsrc entry (the packages are derived from the same pkgsrc
entry). Same for php packages. pkgsrc doesn't tend to do mass CPAN
or CTAN entries as much as ports did.
However, as I've said many times before, size doesn't matter.
It's breadth that matters, and pkgsrc has 16 times the breadth of ports.^U^U^U
(sorry, that useless innuendo was uncalled for).
FreeBSD undoubtedly has more ports than pkgsrc, even including wip,
and no-one is doubting that. Neither am I trying to play a "my packaging
system is better than yours" game. But I usually find that if a package
isn't known about on pkgsrc.se (another valuable resource, btw), then
I or someone else will add it fairly quickly.
Regards,
Alistair
Alex Goncharov
| On Thu, 4 Aug 2011, Alex Goncharov wrote:
| > | 1. it allows pkgsrc packages to be built with exactly the versions of
| > | software that are wanted, and not what happens to be already installed
| > | in /usr/local - to illustrate, imagine that ncurses is installed, and
| > | another package's configure script checks for the presence of ncurses
| > | (bad example, since i think freebsd has ncurses in base, but ykwim)
| >
| > This all seems very far-fetched.
|
| It is certainly a real issue. Many software when built outside of ports
| (or outside of pkgsrc) defaults to installing to /usr/local/. So simply
| the addition of an include file, some binary, some library, some
| pkg-config file, et cetera, may in the future
| enable/disable/break/enhance or otherwise change some later "ports"
| build resulting in a package possible different than what was expected.
| Even if the package list is the same, it may have new dependencies or
| capabilities not expected. And after removing the "/usr/local" addition
| (whatever it was) may break the package like removing a shared library
| (and since not registered as a package dependency it won't warn you).
I seem to beginning to understand it: the problem may happen if you
combine building from ports/pkgsrc -- and "by hand". Right?
Makes sense, even though this has never been an issue for me
personally -- I always specify '--prefix' to something different than
'/usr/local' (and for a long time I don't even build anything outside
of ports on FreeBSD -- only on other platforms).
| Even if you choose a custom localbase, the problem is still possible
| since /usr/local is often still looked at. pkgsrc builds work very
| hard to make sure /usr/local and /usr/pkg are not looked at when
| building packages.
I see. How does this work when one needs the information about
installed packages? E.g. for x11-related things (gconf), or for ODBC
drivers, which need some information from things like 'pg_config' or
'odbc_config'?
| > ----------------------------------------
| > ls -d1 /usr/ports/databases/postgresql*server
| > ls -d1 /usr/ports/databases/mysql*server
| > ----------------------------------------
| >
| > Does one really need more than that?
| I think there was a misunderstanding, so I don't understand context of
| that.
I was trying to illustrate the wide choice of available versions in
ports. Not so significant, we can move on.
| > | 2. isolates dependencies so that dangling or hidden dependencies just
| > | do not happen.
| >
| > 'pkgdb -F' won't do it for you on FreeBSD?
|
| Also different. That is for fixing later.
|
| The "hidden" dependencies in question are those detected at build time
| (described above).
I see.
| > | in addition, from a user's pov, pkgsrc's config file handling is done
| > | in a smart way so that any changes to standard configs are preserved,
| > | rc.d scripts can optionally be installed to /etc so that they work
| > | out
| >
| > Any port rc.d script is installed (with either install method) under
| > /usr/local/etc/rc.d and works out of the box (subject to rc.conf
| > X_enable=YES, of course).
|
| Yes. pkgsrc offers "staged" rc.d scripts, so they are installed as
| examples and optionally put in place to use (if a custom version is not
| already there).
As in ports.
| > | of the box, and much, much more.
| >
| > It is quite possible that pkgsrc has some advantages for a very
| > sophisticated use, but it seems to me that in comparing it with
| > FreeBSD ports some of the obvious capacities of the latter are
| > overlooked.
| >
| > Such as '-p' and '-P' of pkg_add:
|
| pkgsrc had those too. I think the master/slave mode was removed, but
| basic functionality of these are the same. Note that the FreeBSD-style
| of "staged" (master/slave) mode at binary package install time is
| different than pkgsrc's build-time staged installs. (I am curious does
| anyone use FreeBSD's pkg_add master/slave installs and why?)
Have no clue, don't even know what it is.
|
| The concept of changing the install prefix at pkg_add time is much
| different than choosing a custom prefix at build time.
OK.
Thank you for the detailed analysis!
-- Alex -- alex-go...@comcast.net --
Alex Goncharov
| > | software that are wanted, and not what happens to be already installed
| >
|
| It is certainly a real issue. Many software when built outside of ports
For the record, I want to formulate the two points which probably
everybody will agree with:
1. The FreeBSD 'ports' system is adequate for most common use cases of
open source software, but the (platform-neutral) 'pkgsrc' system
offers some advantages over it, at least for sophisticated users.
2. FreeBSD loses to NetBSD in (at least) one respect: in addition to
the (superior) 'pkgsrc' package system, it allows one to use the
(inferior) 'ports' system. Not only does FreeBSD allow to use
'ports', it actively encourages one to do it, and obscures the fact
that there is a more powerful packaging system, 'pkgsrc', which
could also be used on that platform.
NetBSD doesn't provide for uses of packaging systems inferior to
'pkgsrc', and this is its strong point.
Am I accurate?
-- Alex -- alex-go...@comcast.net --
--
Jeremy C. Reed
> I seem to beginning to understand it: the problem may happen if you
> combine building from ports/pkgsrc -- and "by hand". Right?
Yes, by hand but also using ports/pkgsrc systems. That is a packager
builds a package and the results and experience is based on what was
installed on that developer's system. Another user of the port
specification has a different environment which may result in a
different build.
> | Even if you choose a custom localbase, the problem is still possible
> | since /usr/local is often still looked at. pkgsrc builds work very
> | hard to make sure /usr/local and /usr/pkg are not looked at when
> | building packages.
>
> I see. How does this work when one needs the information about
> installed packages? E.g. for x11-related things (gconf), or for ODBC
> drivers, which need some information from things like 'pg_config' or
> 'odbc_config'?
Some pkgsrc buildlink specifications have things like:
BUILDLINK_FILES.subversion-base+= bin/svn-config
BUILDLINK_FILES.libnet10+= bin/libnet10-config
BUILDLINK_FILES.tk= bin/wish*
So packages that depend on these have these symlinks in its build PATH
before the system's possible versions of the same.
> | > | in addition, from a user's pov, pkgsrc's config file handling is done
> | > | in a smart way so that any changes to standard configs are preserved,
> | > | rc.d scripts can optionally be installed to /etc so that they work
> | > | out
> | >
> | > Any port rc.d script is installed (with either install method) under
> | > /usr/local/etc/rc.d and works out of the box (subject to rc.conf
> | > X_enable=YES, of course).
> |
> | Yes. pkgsrc offers "staged" rc.d scripts, so they are installed as
> | examples and optionally put in place to use (if a custom version is not
> | already there).
>
> As in ports.
As far as I see, FreeBSD ports does not install the rc.d scripts nor
configuration files to any examples directory. Maybe on a case-per-case
basis and I am just overlooking it? (I do see some FreeBSD ports do
install foo.default or foo.sample configurations right in the
/usr/local/etc/ but as far as I know this is not consistent and
certainly could be messy over time and with many packages.)
For pkgsrc, it is the default procedure fo any configuration file is
installed to an examples directory. This is nice so you can easily
compare any time. At deinstall time, it can compare and remove installed
configurations that have not changed. And on new install, configurations
may be different so new version is only into examples directory and a
message tells you about this. This is consistent across all software in
pkgsrc installing configurations.
$ ls -l /usr/pkg/share/examples/wget/ /usr/pkg/etc/wgetrc
-rw-r--r-- 1 root wheel 4224 Aug 26 2008 /usr/pkg/etc/wgetrc
/usr/pkg/share/examples/wget/:
total 12
-r--r--r-- 1 root wheel 4224 Aug 26 2008 wgetrc
I can easily tell pkgsrc builds to use /etc if I choose.
peas...@shaw.ca
Date: Tue, 02 Aug 2011 15:37:52 -0400
> Personally, I like NetBSD over the other systems because there is a lot
> of focus in "doing the right thing" technically, and the community
> around it is very smart. As a result, NetBSD is a very clean and
> consistent system. But this is only my personal opinion!
Striking that there has been no mention of Inferno or Oberon
or A2. For every BMW on the road, there have always been many
Chevys, primarily because of the cost I suppose. But Inferno
doesn't cost much more than Linux. Entrenchment and familiarity
are big factors in adoption of computer systems.
Regards, ... Peter E.
--
Telephone 1 360 450 2132. bcc: peasthope at shaw.ca
Shop pages http://carnot.yi.org/ accessible as long as the old drives survive.
Personal pages http://members.shaw.ca/peasthope/ .
Alex Goncharov
|
| On Thu, 4 Aug 2011, Alex Goncharov wrote:
|
| > I seem to beginning to understand it: the problem may happen if you
| > combine building from ports/pkgsrc -- and "by hand". Right?
|
| builds a package and the results and experience is based on what was
| installed on that developer's system. Another user of the port
| specification has a different environment which may result in a
| different build.
I see.
| > I see. How does this work when one needs the information about
| > installed packages? E.g. for x11-related things (gconf), or for ODBC
| > drivers, which need some information from things like 'pg_config' or
| > 'odbc_config'?
|
| Some pkgsrc buildlink specifications have things like:
|
| BUILDLINK_FILES.subversion-base+= bin/svn-config
| So packages that depend on these have these symlinks in its build PATH
| before the system's possible versions of the same.
OK, thanks.
| > | Yes. pkgsrc offers "staged" rc.d scripts, so they are installed as
| > | examples and optionally put in place to use (if a custom version is not
| > | already there).
| >
| > As in ports.
|
| As far as I see, FreeBSD ports does not install the rc.d scripts nor
| configuration files to any examples directory. Maybe on a case-per-case
| basis and I am just overlooking it?
On my system (don't want to trim the long lists):
----------------------------------------
/bin/ls /usr/local/etc/*.sample | xargs -n1 -t pkg_which
=>
pkg_which /usr/local/etc/asound.conf.sample
alsa-lib-1.0.23
pkg_which /usr/local/etc/cdrecord.sample
cdrtools-3.00_1
pkg_which /usr/local/etc/dhcpd.conf.sample
isc-dhcp41-server-4.1.e_1,2
pkg_which /usr/local/etc/dhcpd6.conf.sample
isc-dhcp41-server-4.1.e_1,2
pkg_which /usr/local/etc/dict.conf.sample
dict-1.12.0_1
pkg_which /usr/local/etc/fetchmailrc.sample
fetchmail-6.3.20
pkg_which /usr/local/etc/mtools.conf.sample
mtools-4.0.10_3
pkg_which /usr/local/etc/pkgtools.conf.sample
portupgrade-2.4.8_1,2
pkg_which /usr/local/etc/portmaster.rc.sample
portmaster-3.9.1
pkg_which /usr/local/etc/smartd.conf.sample
smartmontools-5.41_2
pkg_which /usr/local/etc/sudoers.sample
sudo-1.8.1_5
pkg_which /usr/local/etc/wgetrc.sample
wget-1.12_4
----------------------------------------
/bin/ls /usr/local/etc/rc.d/* | xargs -n1 -t pkg_which
=>
pkg_which /usr/local/etc/rc.d/avahi-daemon
avahi-app-0.6.29
pkg_which /usr/local/etc/rc.d/avahi-dnsconfd
avahi-app-0.6.29
pkg_which /usr/local/etc/rc.d/cupsd
cups-base-1.4.6_5
pkg_which /usr/local/etc/rc.d/dbus
dbus-1.4.6
pkg_which /usr/local/etc/rc.d/exim
exim-4.76
pkg_which /usr/local/etc/rc.d/fetchmail
fetchmail-6.3.20
pkg_which /usr/local/etc/rc.d/ffserver
ffmpeg-0.7.1_4,1
pkg_which /usr/local/etc/rc.d/fusefs
fusefs-kmod-0.3.9.p1.20080208_7
pkg_which /usr/local/etc/rc.d/git_daemon
git-1.7.6
pkg_which /usr/local/etc/rc.d/hald
hal-0.5.14_17
pkg_which /usr/local/etc/rc.d/isc-dhcpd
isc-dhcp41-server-4.1.e_1,2
pkg_which /usr/local/etc/rc.d/isc-dhcpd6
isc-dhcp41-server-4.1.e_1,2
pkg_which /usr/local/etc/rc.d/linux_adobe
acroreadwrapper-0.0.20110529
pkg_which /usr/local/etc/rc.d/mysql-server
mysql-server-5.5.14
pkg_which /usr/local/etc/rc.d/postgresql
postgresql-server-8.4.8_1
pkg_which /usr/local/etc/rc.d/smartd
smartmontools-5.41_2
pkg_which /usr/local/etc/rc.d/snmpd
net-snmp-5.5_4
pkg_which /usr/local/etc/rc.d/snmptrapd
net-snmp-5.5_4
pkg_which /usr/local/etc/rc.d/svnserve
subversion-freebsd-1.6.17_2
----------------------------------------
| (I do see some FreeBSD ports do install foo.default or foo.sample configurations right in the
| /usr/local/etc/ but as far as I know this is not consistent and certainly could be messy over time
| and with many packages.)
Haven't seen it to become messy.
| For pkgsrc, it is the default procedure fo any configuration file is
| installed to an examples directory.
----------------------------------------
ls /usr/share/examples/
=>
BSD_daemon/ cvsup/ hast/ iscsi/ nwclient/ printing/
FreeBSD_version/ dialog/ hostapd/ kld/ perfmon/ scsi_target/
IPv6/ diskless/ ibcs2/ libdialog/ pf/ ses/
bc/ drivers/ indent/ libvgl/ portal/ smbfs/
bootforth/ etc/ ipfilter/ mdoc/ ppi/ sunrpc/
cvs/ find_interface/ ipfw/ netgraph/ ppp/ tcsh/
----------------------------------------
| This is nice so you can easily compare any time. At deinstall time, it can compare and remove
| installed configurations that have not changed. And on new install, configurations may be
| different so new version is only into examples directory and a message tells you about this. This
| is consistent across all software in pkgsrc installing configurations.
|
| $ ls -l /usr/pkg/share/examples/wget/ /usr/pkg/etc/wgetrc
| -rw-r--r-- 1 root wheel 4224 Aug 26 2008 /usr/pkg/etc/wgetrc
----------------------------------------
ls /usr/share/examples/etc | wc -l; ls /usr/share/examples/etc | head -n 4
71
README.examples
amd.map
apmd.conf
auth.conf
----------------------------------------
| I can easily tell pkgsrc builds to use /etc if I choose.
I don't see such a need with ports.
Jeremy C. Reed
> /bin/ls /usr/local/etc/*.sample | xargs -n1 -t pkg_which
Yes, I already see such on my own systems. But as far as I know, there
are not samples for every configuration nor every package that provides
configurations. That is the significant difference. (A minor difference
is that the samples are kept in a different directory so less clutter
under the etc/.)
> /bin/ls /usr/local/etc/rc.d/* | xargs -n1 -t pkg_which
> =>
I understand that they are not enabled by default, but still may
all be ran by default and hopefully do nothing.
This is slightly different. pkgsrc by default does not install these for
rc.d use. (They may be put in place manually or pkgsrc/pkg_add can be
told to install them.)
> | For pkgsrc, it is the default procedure fo any configuration file is
> | installed to an examples directory.
>
> ----------------------------------------
> ls /usr/share/examples/
Mostly unrelated. As far as I know, none of these are from the ports.
> ls /usr/share/examples/etc | wc -l; ls /usr/share/examples/etc | head -n 4
> 71
I think are not from ports.
> | I can easily tell pkgsrc builds to use /etc if I choose.
>
> I don't see such a need with ports.
There is not need. It is a personal preference by some to choose where
they want to keep their system-wide configurations.
Alex Goncharov
| > ----------------------------------------
| > ls /usr/share/examples/
|
| Mostly unrelated. As far as I know, none of these are from the ports.
|
| > 71
|
|
Sorry, I goofed up, should have been:
----------------------------------------
ls /usr/local/share/examples | wc -l; ls /usr/local/share/examples | head -n 4
25
IO-Socket-SSL/
Net-SSLeay/
bison/
check-0.9.8/
----------------------------------------
Rhialto
> my main gripe, as a user, was the absence of audit-packages
It is called "portaudit":
$ portaudit
0 problem(s) in your installed packages found.
$
-Olaf.
--
___ Olaf 'Rhialto' Seibert -- There's no point being grown-up if you
\X/ rhialto/at/xs4all.nl -- can't be childish sometimes. -The 4th Doctor