The Preview2 Release of the GoBSD distro is now available for download here . GoBSD is a BSD distro based off of DragonFlyBSD which uses pkgsrc. With this release you can build Xorg and other large packages using pkgsrc which is included on the ISO.
this is a testament to the well engineered pjgsrc from NetBSD. congratulations to both GoBSD and more so to the pjgsrc developers.
I think 2006 will be he year that well engineered but slightly shy projects start getting some recognition – NetBSD 2.0 being an excellent example.
I’m also looking forward to the desktop multimedia and server benefits of a Dragonfly kernel – video playing whilst doing desktop stuuf, running a heavily threaded application server…
Then we have the supposed to be more secure version of FreeBSD called TrustedBSD and DragonFly which takes another direction from FreeBSD 4.x. And more ones? Any which counts?
In any way atleast there is a difference in what is beeing done with them, it’s not like there is 100+ versions of FreeBSD + ports.
GoBSD and FireFlyBSD (based on DragonFlyBSD) and EccoBSD (based on OpenBSD, now discontinued). Also Darwin (and OpenDarwin) belongs to the BSD family and hence MacOS X. Debian/BSD is another one.
But sure, we’re not anywhere near the grand brand mess that’s called Linux.
If you compile packages with pkgsrc remember to use /usr/pkg/bin/bmake instead of the regular make. It’s in the wiki somewhere, but I still got burned by it myself.
i agree with the previous posters. there is sanity in taking the considered, reviews, designed approach of BSD than the chaotic organic growth of linux.
but you can’t argue with the fact that linux performs ans scales better for now.
pkgsrc still suffers from the problem that an upgrade of one package will cause all dependent packages to be rebuilt. The major issue with this is that pkgsrc first deletes all the packages then rebuilds them. If one build fails (as it seems to do quite often), the other packages will fail and we’re left in a bad state.
portupgrade in FreeBSD does not have this problem nor (of course) do the binary upgrade mechanisms of Linux like apt and yum.
This makes NetBSD maintenance much more painful for me and is the major reason I no longer plan on building NetBSD servers.
Portupgrade is kind of hit and miss. For the occasional small package I’ll use it. But I no longer trust it to upgrade anything big/complex. I tried upgrading from Gnome2.6 to 2.8, and portupgrade messed everything up, to the extent that reverting back to 2.6 didn’t even work. Plus the package db or always gets in an inconsistent state and you have to mess around fixing it with some command with a cryptic UI.
I didn’t have any luck with portmanager either — it got confused when a port was “moved” in the ports tree — asked me if I wanted to nuke it, and I assumed it would just rebuild it from the new location — wrong! it proceeded to nuke it along with all dependencies…
I’ve never had portupgrade leave me in a state where critical packages were missing from my system. There may have been build errors, but the existing packages were spared. I can’t say the same for NetBSD, especially when the OpenSSL package would not build. That was the definition of pain.
Well I don’t dispute what you claim about NetBSD, because I myself have suffered the same downfalls of pkgsrc.
But portupgrade is really only a bandaid fix for a much aging ports system. It’s not that the ports system is bad, it’s just that it’s starting to show it’s age. In all truth it’s probably due to be replaced. I was hoping that JKH would come up with something great with the darwinports project, but that (at the present) seems to be ailing due to lack of direction and project leadership (and is potentially no longer cross-platform).
As for the DragonFly devs, I’ve read a few of the papers they’ve written, and talked to them on IRC a bit, but I’m not really sure anything has been done yet. I think maybe everyone’s waiting for Matt to get the ball rolling and come up with something brilliant. Unfortunately he seems to be pre-occupied with other things such as the VFS & Journalling work.
This is an article on how to upgrade packages without the pain of having every dependent package deleted before being rebuilt by using pkg_comp in a chroot sandbox. http://www.bsdfreak.org/modules/news/article.php?storyid=1 not a perfect solution but better than nothing. Hopefully pkgsrc will have better upgrade utilities in the future.
It’s too bad it’s not the default, but portupgrade’s “-b” option is very nice. It will create a binary package of the installed version of a program before it does the upgrade. That way, if the upgrade fails, you just “pkg_add /path/to/backup/package” to revert to the old version.
Does pkgsrc include any methods for building binary packages? If so, then you should be able to configure it to create packages of the old versions before uninstalling them.
One thing a lot people seem to forget about FreeBSD’s ports tree: you need to read /usr/ports/UPDATING everytime you run cvsup. In there you’ll find details on any problems or gotchas that may come up when upgrading large packages (like perl, or GNOME, or KDE). Just like you need to read /usr/src/UPDATING when doing buildworld, you need to read /usr/ports/UPDATING when doing port upgrades.
If you take your time and do things one-step-at-a-time (don’t use “portupgrade -a” or “portupgrade -rR”), then you’ll never have problems.
“Portupgrade is kind of hit and miss. For the occasional small package I’ll use it. But I no longer trust it to upgrade anything big/complex. I tried upgrading from Gnome2.6 to 2.8, and portupgrade messed everything up, to the extent that reverting back to 2.6 didn’t even work. Plus the package db or always gets in an inconsistent state and you have to mess around fixing it with some command with a cryptic UI.
I didn’t have any luck with portmanager either — it got confused when a port was “moved” in the ports tree — asked me if I wanted to nuke it, and I assumed it would just rebuild it from the new location — wrong! it proceeded to nuke it along with all dependencies…”
Of course it did.. if you bothered to read the gnome 2.6 to 2.8 upgrade manual, you would have noticed there is a gnome_upgrade.sh script and it’s clearly written there portupgrade will mess the installation. Don’t blame it on portupgrade, it works very well.
I installed and used FreeBSD 5.x for about 4 months now in my laptop. It is is a decent operating system but then I installed the latest SUSE linux and almost cried from frustration. FreeBSD is soo slow! I am wondering if anybody has used Dragonfly or GoBSD for a desktop and can compare it with the linux 2.6 kernel. …
I believe the default ‘make upgrade’ will call pkg_tarup on the installed package before attempting to delete/reinstall it, so you should never be left in a state you cannot recover from.
No, I’m sorry, but a good package system shouldn’t require the user to sift through a bunch of docs or do things manually.
At bare minimum, there should be a flag in the port that tells portupgrade that it can’t upgrade that specific port. Then portupgrade should crap out and tell you that for whatever reason this specific port cannot be upgraded safely.
But this doesn’t exist, because portupgrade isn’t part of the base system, and never will be as long as it uses ruby.
DragonFly still has a few issues performance-wise (as far as desktop use goes). I don’t think they’ve tweaked/rewritten the userland scheduler yet.
Compared to FreeBSD 4.11 (on the exact same hardware), I had jerky-ness issues when watching DVDs. Admittedly this isn’t much of a benchmark, but most desktop related benchmarks are usually subjective (how fast it ‘feels’). There was definite visual lugging, chugging, and jerking going on.
The responsiveness of FreeBSD 5.x also depends on which scheduler you are using. I wasn’t super impressed with 5.x, although at the same time it wasn’t as bad as most people made it out to be.
They are all DragonFlyBSD. Also, FireflyBSD is probably a sponsor because DragonFly developer David Rhodus @ http://www.dragonflybsd.org/main/team.cgi is the man behind GoBSD and is also one of the persons behind FireflyBSD http://fireflybsd.com/management.php Here is his explanation of what GoBSD is about, taken from dragonfly.users mailinglist/newsgroup:
Haven’t lost the count yet, like in case with Linux, but that’s where it’s going.
this is a testament to the well engineered pjgsrc from NetBSD. congratulations to both GoBSD and more so to the pjgsrc developers.
I think 2006 will be he year that well engineered but slightly shy projects start getting some recognition – NetBSD 2.0 being an excellent example.
I’m also looking forward to the desktop multimedia and server benefits of a Dragonfly kernel – video playing whilst doing desktop stuuf, running a heavily threaded application server…
Uhm, BSD/OS, FreeBSD, NetBSD, OpenBSD.
Then we have the supposed to be more secure version of FreeBSD called TrustedBSD and DragonFly which takes another direction from FreeBSD 4.x. And more ones? Any which counts?
In any way atleast there is a difference in what is beeing done with them, it’s not like there is 100+ versions of FreeBSD + ports.
GoBSD and FireFlyBSD (based on DragonFlyBSD) and EccoBSD (based on OpenBSD, now discontinued). Also Darwin (and OpenDarwin) belongs to the BSD family and hence MacOS X. Debian/BSD is another one.
But sure, we’re not anywhere near the grand brand mess that’s called Linux.
If you compile packages with pkgsrc remember to use /usr/pkg/bin/bmake instead of the regular make. It’s in the wiki somewhere, but I still got burned by it myself.
i agree with the previous posters. there is sanity in taking the considered, reviews, designed approach of BSD than the chaotic organic growth of linux.
but you can’t argue with the fact that linux performs ans scales better for now.
pkgsrc still suffers from the problem that an upgrade of one package will cause all dependent packages to be rebuilt. The major issue with this is that pkgsrc first deletes all the packages then rebuilds them. If one build fails (as it seems to do quite often), the other packages will fail and we’re left in a bad state.
portupgrade in FreeBSD does not have this problem nor (of course) do the binary upgrade mechanisms of Linux like apt and yum.
This makes NetBSD maintenance much more painful for me and is the major reason I no longer plan on building NetBSD servers.
Portupgrade is kind of hit and miss. For the occasional small package I’ll use it. But I no longer trust it to upgrade anything big/complex. I tried upgrading from Gnome2.6 to 2.8, and portupgrade messed everything up, to the extent that reverting back to 2.6 didn’t even work. Plus the package db or always gets in an inconsistent state and you have to mess around fixing it with some command with a cryptic UI.
I didn’t have any luck with portmanager either — it got confused when a port was “moved” in the ports tree — asked me if I wanted to nuke it, and I assumed it would just rebuild it from the new location — wrong! it proceeded to nuke it along with all dependencies…
I’ve never had portupgrade leave me in a state where critical packages were missing from my system. There may have been build errors, but the existing packages were spared. I can’t say the same for NetBSD, especially when the OpenSSL package would not build. That was the definition of pain.
Well I don’t dispute what you claim about NetBSD, because I myself have suffered the same downfalls of pkgsrc.
But portupgrade is really only a bandaid fix for a much aging ports system. It’s not that the ports system is bad, it’s just that it’s starting to show it’s age. In all truth it’s probably due to be replaced. I was hoping that JKH would come up with something great with the darwinports project, but that (at the present) seems to be ailing due to lack of direction and project leadership (and is potentially no longer cross-platform).
As for the DragonFly devs, I’ve read a few of the papers they’ve written, and talked to them on IRC a bit, but I’m not really sure anything has been done yet. I think maybe everyone’s waiting for Matt to get the ball rolling and come up with something brilliant. Unfortunately he seems to be pre-occupied with other things such as the VFS & Journalling work.
This is an article on how to upgrade packages without the pain of having every dependent package deleted before being rebuilt by using pkg_comp in a chroot sandbox. http://www.bsdfreak.org/modules/news/article.php?storyid=1 not a perfect solution but better than nothing. Hopefully pkgsrc will have better upgrade utilities in the future.
It’s too bad it’s not the default, but portupgrade’s “-b” option is very nice. It will create a binary package of the installed version of a program before it does the upgrade. That way, if the upgrade fails, you just “pkg_add /path/to/backup/package” to revert to the old version.
Does pkgsrc include any methods for building binary packages? If so, then you should be able to configure it to create packages of the old versions before uninstalling them.
One thing a lot people seem to forget about FreeBSD’s ports tree: you need to read /usr/ports/UPDATING everytime you run cvsup. In there you’ll find details on any problems or gotchas that may come up when upgrading large packages (like perl, or GNOME, or KDE). Just like you need to read /usr/src/UPDATING when doing buildworld, you need to read /usr/ports/UPDATING when doing port upgrades.
If you take your time and do things one-step-at-a-time (don’t use “portupgrade -a” or “portupgrade -rR”), then you’ll never have problems.
Whatever happened to patience and diligence??
“Portupgrade is kind of hit and miss. For the occasional small package I’ll use it. But I no longer trust it to upgrade anything big/complex. I tried upgrading from Gnome2.6 to 2.8, and portupgrade messed everything up, to the extent that reverting back to 2.6 didn’t even work. Plus the package db or always gets in an inconsistent state and you have to mess around fixing it with some command with a cryptic UI.
I didn’t have any luck with portmanager either — it got confused when a port was “moved” in the ports tree — asked me if I wanted to nuke it, and I assumed it would just rebuild it from the new location — wrong! it proceeded to nuke it along with all dependencies…”
Of course it did.. if you bothered to read the gnome 2.6 to 2.8 upgrade manual, you would have noticed there is a gnome_upgrade.sh script and it’s clearly written there portupgrade will mess the installation. Don’t blame it on portupgrade, it works very well.
I installed and used FreeBSD 5.x for about 4 months now in my laptop. It is is a decent operating system but then I installed the latest SUSE linux and almost cried from frustration. FreeBSD is soo slow! I am wondering if anybody has used Dragonfly or GoBSD for a desktop and can compare it with the linux 2.6 kernel. …
I believe the default ‘make upgrade’ will call pkg_tarup on the installed package before attempting to delete/reinstall it, so you should never be left in a state you cannot recover from.
Don’t blame portupgrade for a problem it caused?
No, I’m sorry, but a good package system shouldn’t require the user to sift through a bunch of docs or do things manually.
At bare minimum, there should be a flag in the port that tells portupgrade that it can’t upgrade that specific port. Then portupgrade should crap out and tell you that for whatever reason this specific port cannot be upgraded safely.
But this doesn’t exist, because portupgrade isn’t part of the base system, and never will be as long as it uses ruby.
DragonFly still has a few issues performance-wise (as far as desktop use goes). I don’t think they’ve tweaked/rewritten the userland scheduler yet.
Compared to FreeBSD 4.11 (on the exact same hardware), I had jerky-ness issues when watching DVDs. Admittedly this isn’t much of a benchmark, but most desktop related benchmarks are usually subjective (how fast it ‘feels’). There was definite visual lugging, chugging, and jerking going on.
The responsiveness of FreeBSD 5.x also depends on which scheduler you are using. I wasn’t super impressed with 5.x, although at the same time it wasn’t as bad as most people made it out to be.
GoBSD is a community advocacy site sponsored by Firefly BSD, Inc.
They are all DragonFlyBSD. Also, FireflyBSD is probably a sponsor because DragonFly developer David Rhodus @ http://www.dragonflybsd.org/main/team.cgi is the man behind GoBSD and is also one of the persons behind FireflyBSD http://fireflybsd.com/management.php Here is his explanation of what GoBSD is about, taken from dragonfly.users mailinglist/newsgroup:
Subject: Re: GoBSD.com
From: David Rhodus <[email protected]>
Reply-To: [email protected]
Newsgroups: dragonfly.users
Date: Fri, 10 Dec 2004 02:39:45 +0000
On Thu, 9 Dec 2004 07:50:02 +0200, Atte Peltomaki <[email protected]> wrote:
> With great amazement I have been observing the birth of GoBSD. I have to
> admit, I do not understand all of their motives and objectives. Why do
> people insist on splitting DragonFlyBSD?
GoBSD is not a fork. There are no code differences between gobsd and
DragonFly. GoBSD is a timely collection of DragonFly bits and ports
that have been tested to work well together put together by DragonFly
developers and users. The site is to promote all BSD’s by giving a
central place for BSD users and developers to communicate.
—
-David
Steven David Rhodus
<[email protected]>