Submitted by Matt Dillon has announced that the next release of DragonFly BSD will use NetBSD’s pkgsrc as its official package management system, instead of “dfports” (FreeBSD’s Ports with DragonFly overrides), which had already been abandoned by developers in favour of pkgsrc over the last few months. pkgsrc is a portable package management system, developed by NetBSD, and supports DragonFly officially since October 2004.
IMHO, it’s good to see different operating systems using the same package management system. It’s such a big waste of resources with each OS keeping their own packages collection up-to-date. They mostly contain the same packages in a comparable infrastructure anyway.
It is a little disappointing to see the hopes of a next-gen packaging system dashed but pkgsrc is here now and it works pretty well, so I understand the decision. DragonFly doesn’t have enough developers to devote to working on a pie-in-the-sky perfect package manager at this point in time.
As Matt Dillon say on his email to the mailing list.
the developers dont have enought time to keep making chage to the dfports, in more than 90 days only a few changes was maded. so this is the best choise for the project to keep growing.
I’ve used pkgsrc on NetBSD and Solaris and it works very well. The DF team is pretty small and this will allow them to concentrate on the OS core. They’re pretty nice actually, much easier to deal with than the Texas-sized ego people that rule FreeBSD.
I have had an easy time submitting new ports and patches to old ports for FreeBSD. Some changes have made it into the port subsystem or better versions of those changes.
Whose ego, preferably with links, are you speaking about? Remember that just because someone refuses (or wants to hold off for a time) changes does not necessarily mean ego is involved.
They’re pretty nice actually, much easier to deal with than the Texas-sized ego people that rule FreeBSD.
I think you’re confusing the FreeBSD team with the OpenBSD team
They’re pretty nice actually, much easier to deal with than the Texas-sized ego people that rule FreeBSD.
I think you’re confusing the FreeBSD team with the OpenBSD team
Heh… exactly what I was thought too.
Seriously though, as much as I am a fan of the FreeBSD ports, if this leaves the devs with more time to work on DFBSD itself then it’s probably a really good move. Although I haven’t had a chance to check it out (yet) I’ve heard good things and maybe this will prompt me to get my ass in gear
Compatibility requires a lot more than that, such as the same version of different libraries. Binary compatibility can be remedied by simply distributing source, but in many cases two systems are not even source compatible because they use completely different major versions of a typical libraries.
And how does this apply to the announcement or any of the previous comments?
Also – when you use the same package repository for 2 OSes where will you get the different major versions of typical libraries from? I’d say the only thing that will differ is the ‘core’ which is pretty much standarized by ANSI C and POSIX.
This just points out a serious problem for the *Nix community. Where are the open standards for software installation? Why does every distro need its own proprietary ports or package installation?
The standards are open, the problem is that everyone choses different ones 8)
But they aren’t that many IMO. In the BSD-world there’s now ports and pkgsrc. Sure, there’s a lot of different ones in Linux but it’s mostly rpm/yum or apt that are used. Not saying that portage or pacman isn’t as good, they’re just not as common.
deb has a pretty solid following too
Just one more reason to join DFlyBSD and abandon FreeBSD
Managing FreeBSD ports on DragonFly was a very painful task in the past. In my opinion, FreeBSD ports lost all of its attractiveness after switching to this portsupgrade crap (instead of the former pkg_version variant which worked well and fast).
If they could provide an INDEX file in /usr/pkgsrc like on OpenBSD it would be even better
(FreeBSD ports also had this before breaking everything that worked…but that’s another story…)
In my opinion, FreeBSD ports lost all of its attractiveness after switching to this portsupgrade crap
Heh, the portupgrade “crap” works nicely for me. It’s just a convenience – in fact, portupgrade is itself a port, not part of the base system, so you don’t have to use it at all. You can use traditional ports or packages if you prefer.
Back to DFly – dfports breakage was becoming a headache for me, so I’m glad to see the project move to the pkgsrc alternative. I’m looking forward to trying it out.
I heard Matt Dillon left FreeBSD since he was not satisfied with FreeBSD 5.x for technical reasons. Has DragonFlyBSD already proven to be anyhow “better” than FreeBSD or is it too early to tell yet?
Disclaimer, I’m a DragonFly fan, and have not been at all impressed with any release of 5.x (especially since 5.4 and 6.0 Betas don’t run on my hardware ;^) but it really is too early to tell. They both have strengths and weaknesses.
They are both works in progress, despite what people in the FreeBSD camp will say about 6.0. I would love to see some serious performance benchmarks between the two, as useless as such things seem to be IRL.
They are both works in progress, despite what people in the FreeBSD camp will say about 6.0. I would love to see some serious performance benchmarks between the two, as useless as such things seem to be IRL.
What benchmarks would you like to see? I think that it’s time for a bake-off between FreeBSD 6.0, FC4, and DFly 1.x. And let’s compare real hardware too, not just whatever UP desktop machine is under one’s desk. 2, 4, 8, and 12 processor machines would be quite interesting.
don’t forget gentoo and debian
anyway… I would be supprised if a review such as this would happen, 2 processor and 4 processor, yeah, but once you get to the 8+ processor systems that starts to get quite pricey, not a lot of people with this hardware would be willing to take it offline for any period of time to install and test various os’s.
I have a dualie coming into my hands soon, i’de be happy to do a review with it.
I might be able to get my hands on a 4 to 8 way machine but it wouldn’t be modern. It’d be an older, Alpha 2xx or P2/3 machine. So obviously performance would be…well, not up to certain specs now adays but it’d offer a scaling test obviously.
– Chris
[email protected]
AIM: andurilsba
All the recent benchmarks have been done under multi-processor machines, instead lets see on under a UP machine.
> Has DragonFlyBSD already proven to be anyhow “better” than FreeBSD or is it too early to tell yet?
It is too early, but I am really sure DragonFly will be very impressive 😉 Just look at the amazing work Matt is currently doing on the journaling front!
I would really like to see good benchmarks measuring the performance of the TCP/IP stack on the BSD systems (after Andre has optimized FreeBSD’s one). Jeffrey Hsu already improved DragonFly’s stack a lot.
pkgsrc is so portable, it also runs on Linux.
Why didn’t OpenBSD go with pkgsrc and reinvented the wheel? I dunno, by the look of some things posted in misc, it’s as if they’re reinventing the wheel and reproducing mistakes as well as hainv the same issues others already faced (and solved).
Maybe because of the build process?
Uh, because ports have been around longer and is working just fine?
to portage.
Boo yea!
They could switch to gentoo/freebsd
http://dev.gentoo.org/~citizen428/doc/gentoo-freebsd.html
“Gentoo/FreeBSD is an effort effort to provide a fully-capable FreeBSD operating system with Gentoo’s design sensibilities. ”
Great. So what are Gentoo’s design sensibilities?
Hahah. Gentoo != Sensible. Haha LOLOMFGROFLMAOFFF
Because the openbsd project are looking for secure ports not “alot is better” ports. Programs that are with good design and secure is the main goal for openbsd ports system
Although I was looking forward to a “new and improved/more advanced than everything else” ports+package system, I’ve always liked pkgsrc. I’ve used it on NetBSD, FreeBSD (well, just for one program that was at the time wasn’t easy to compile out of the box and didn’t have a port yet) and GNU/Linux (I prefer it over portage or apt) and liked it tremendously.
I think portability is quite important for libraries and userland level tools, and it will be beneficial for DragonFly to have something that already works in an area that they aren’t interested in hacking. Plus as a side effect they effectively get all of the support and rigorous testing done by the NetBSD people. So essentially Dragonfly will become useable (that was the main showstopper for me anyway, I need to be assured that most applications will “just work” on whatever operating system that I’m using) for more casual users in a few months, or maybe even now.
This is a win-win situation if you ask me. Not only will Dragonfly have tons of working applications, assured by Dragonfly’s official support of pkgsrc, but pkgsrc will become more robust and more portable, thus benefiting the NetBSD community. Awesome.
–Tim
Also, I wonder if pkgsrc being supported by DragonFly will result in stuff like the NVIDIA driver being ported to NetBSD? Perhaps not the NVIDIA driver due to different internals, but in general I think that more ports will be available for NetBSD as a result of this.
Finally I think that pkgsrc-wip is a fantastic idea, it lets amateurs make quick homemade ports so they can cleanly install applications without waiting for the port to be formally made by maintainers.
–Tim
Finally I think that pkgsrc-wip is a fantastic idea, it lets amateurs make quick homemade ports so they can cleanly install applications without waiting for the port to be formally made by maintainers.
You can also make “homemade ports” without pkgsrc-wip. Just create your own pkgsrc category directory and create packages there.