DragonFly BSD 3.4 Released, With New Packaging System

← Back to Stories (view on slashdot.org)

DragonFly BSD 3.4 Released, With New Packaging System

Posted by timothy on Tuesday April 30, 2013 @01:04AM from the diversity-matters dept.

An anonymous reader writes "DragonFly BSD has released version 3.4. This version is the first BSD to support GCC 4.7, and contains a new experimental Aptitude-like binary package installed called DPorts, which uses the FreeBSD ports collection as a base."

75 comments

Min score:

Reason:

Sort:

Excuse my ignorance by Chrisq · 2013-04-30 01:08 · Score: 1

But could someone explain how BSD package management compares to .rpm and .deb?
1. Re:Excuse my ignorance by Anonymous Coward · 2013-04-30 01:17 · Score: -1
  
  Sorry, no excuses here, you ingorant and insesnsitive clod!
2. Re:Excuse my ignorance by Anonymous Coward · 2013-04-30 01:20 · Score: 3, Informative
  
  The regular package management for BSDs, the ports collection, is not like .rpm or .deb at all. The closest Linux equivilent would be Gentoo, since it was based on Ports, and improved upon from there (improved in the opinion of the people doing the improving anyway.) Everything there is compiled from source based on some pretty beefy makefiles.
  I don't know much about this new package system, but if it's based on Aptitude, it's probably better to compare it to apt-get or Yum than to .rpm and .deb.
3. Re:Excuse my ignorance by Anonymous Coward · 2013-04-30 01:26 · Score: 0
  
  No excuses for you as well, CmdrTypo!
4. Re:Excuse my ignorance by Anonymous Coward · 2013-04-30 01:30 · Score: 1
  
  pkg_add -r has always been similar I guess. sysinstall has provided a menu for binary package installation for as long as I can remember.
  I don't know what makes DPorts special or more aptitude-like.
5. Re:Excuse my ignorance by Anonymous Coward · 2013-04-30 01:34 · Score: 4, Informative
  
  One big difference between *BSD and most Linux systems is that a *BSD system consists of a base system plus packages. With a lot of the Linux systems, the whole system consists of packages. So for example, with a Debian system, your kernel is managed with apt thus it is managed with a package manager. In *BSD, the kernel is part of the base system.
6. Re:Excuse my ignorance by Pricetx · 2013-04-30 01:35 · Score: 4, Informative
  
  Wikipedia has a rather well written article on FreeBSD's ports system (and being that FreeBSD has the largest user base of the *BSDs, it is often thought of as "the BSD system"). http://en.wikipedia.org/wiki/FreeBSD_Ports
  Additionally, it may be worth noting that FreeBSD is transitioning over to a new binary package system called "pkgng", (to replace pkg_add, not ports). I don't personally know much about it, but the trusty old FreeBSD handbook has a section on it: http://www.freebsd.org/doc/en/books/handbook/pkgng-intro.html
7. Re:Excuse my ignorance by ByOhTek · 2013-04-30 01:55 · Score: 4, Informative
  
  FreeBSD has had packages for years. It's not transitioning, it's allowing another option.
  Ports in FreeBSD, in my experience, if you follow a production-like attitude, rather than an ADD OH-NOEZ-THIS-PORT-IS-30-SECONDS-OUT-OF-DATE-MUST-UPDATE methodology, works better than any package manager I've seen (rpm, deb, yum, apt).
  The BSD package systems tend to be more like apt or yum, than simple rpm/deb. They grab your binary packages and their dependencies automatically.
  
  --
  Self proclaimed typo king, and inventor of the bear destroying coffee table (patent not pending).
8. Re:Excuse my ignorance by Ash-Fox · 2013-04-30 02:02 · Score: 1
  
  The regular package management for BSDs, the ports collection, is not like .rpm or .deb at all. The closest Linux equivilent would be Gentoo, since it was based on Ports, and improved upon from there (improved in the opinion of the people doing the improving anyway.) Everything there is compiled from source based on some pretty beefy makefiles.
  Not like .deb at all? So how is this not like apt-build again?
  
  --
  Change is certain; progress is not obligatory.
9. Re:Excuse my ignorance by FORTRANslinger · 2013-04-30 02:07 · Score: 1
  
  Who the hell mod'ed this informative - Linux is the "base system" (you know - the kernel?) and then you pile all the other stuff on top (via packages, source, or whatever method floats your boat)
  
  --
  I'm looking over the wall; and the're looking at me!
10. Re:Excuse my ignorance by fnj · 2013-04-30 02:18 · Score: 4, Informative
  
  You missed the entire point. In BSD the kernel is not itself a package. In linux the kernel is a package just like any other package. THAT's why he is informative.
11. Re:Excuse my ignorance by Anonymous Coward · 2013-04-30 02:18 · Score: 0
  
  Like not like it at all...
  All is built and installed from source.
  Well, if you download apt-src packages, compile them, and then install the package on your machine for any install. Then it is barely similar...
12. Re:Excuse my ignorance by Anonymous Coward · 2013-04-30 02:22 · Score: 1
  
  With only a kernel, you barely can do anything. The base system in most *BSD systems consists of the kernel, some userland utilities (text editors, utilities to manage your files, etc), a compiler, X.org and other stuff. So without any packages installed on a *BSD base system, you can do all kinds of tasks already. With only a kernel (if you call that the base system), that is going to be a little bit hard, I guess.
13. Re:Excuse my ignorance by FORTRANslinger · 2013-04-30 02:27 · Score: 1
  
  I get my Linux kernel as a source - that is not a "package" - there is a BIG difference between "Linux" and "distributions built on top of Linux". You absolutely do not have to use packages to use Linux...
  
  --
  I'm looking over the wall; and the're looking at me!
14. Re:Excuse my ignorance by Yebyen · 2013-04-30 02:30 · Score: 2
  
  It's actually more like, but imagine apt-build out on the front of the interface. In the newest FreeBSD pkg-ng, there are no binary packages other than a few that are able to be used for bootstrapping pkg-ng, so you are compelled to build them (with portmaster or manually mucking with makefiles in /usr/ports)
  There is a "non-ng" pkg tools set, classic pkg_add pkg_delete pkg_info etc that has many packages that you can download (would it be accurate to say most of ports tree? I don't think so), but they are not generally kept up-to-date outside of releases and probably security updates. You are encouraged to use portmaster or another tool to keep your packages up to date.
  The difference (at least in FreeBSD) is that you can't generally have current packages without building them (but all of the atomic guarantees about installing and removing packages you've come to expect from dpkg/apt-get are still there, to my knowledge).
  In Debian there is always sid, or Ubuntu (next), where you can keep up to date just by downloading binary packages. I don't know how this dragonfly package system 'dports' compares to that.
  
  --
  Restating the obvious since nineteen aught five.
15. Re:Excuse my ignorance by Ash-Fox · 2013-04-30 02:30 · Score: 2
  
  Like not like it at all...
  All is built and installed from source.
  apt-build takes the sources and produces a deb that is then installed.
  
  Well, if you download apt-src packages, compile them, and then install the package on your machine for any install. Then it is barely similar...
  A parallel then. Ports downloads application sources, compiles and installs.
  The only difference is one produces a package file before installing, I wouldn't say that's 'barely' different.
  
  --
  Change is certain; progress is not obligatory.
16. Re:Excuse my ignorance by Ash-Fox · 2013-04-30 02:31 · Score: 1
  
  Correction: I wouldn't say that's "barely similar..."
  
  --
  Change is certain; progress is not obligatory.
17. Re:Excuse my ignorance by Yebyen · 2013-04-30 02:34 · Score: 2
  
  No, you're wrong. The kernel is in a package and you can upgrade it via apt-get [dist-]upgrade. In FreeBSD and ilk, you have to gather up /usr/src and make buildkernel to get a new kernel. Frequently you will also want make world, which compiles the rest of the base system (think GNU toolchain, but this is definitely not GNU) that are not in packages.
  You can't really boot just a kernel without any child processes to positive effect (source?), so Linux is not the "base system" -- GNU/Linux is that. In BSD, that's 'world' and ports is everything not world or kernel.
  
  --
  Restating the obvious since nineteen aught five.
18. Re:Excuse my ignorance by Yebyen · 2013-04-30 02:38 · Score: 2
  
  I don't think most people on Debian are rebuilding their systems using apt-build. Then again I'm not most people. My boss insists there's some reason to use aptitude but whenever I try to corner him, he tells me about the use case for dist-upgrade without naming dist-upgrade, and can't give other reasons.
  "apt-get will leave packages in held state"
  yeah, when there's a dependency that was not previously installed, you have to use dist-upgrade to insist that apt-get installs new packages, step that's not usually part of an upgrade.
  I'm going out on a limb and guess that neither of us knew about apt-build.
  
  --
  Restating the obvious since nineteen aught five.
19. Re:Excuse my ignorance by fnj · 2013-04-30 02:59 · Score: 1
  
  Yes, FreeBSD has had "pkg_add -r" for a while to install binary packages, but it has been a poor relation to ports. They have not made available anywhere near as much in binary packages as there is in ports, they are not kept up to date as religiously, and there never was any pkg_update to give the ability to update all installed packages easily. Pkgng and an expanded binary package repo properly maintained will be fixing this.
20. Re:Excuse my ignorance by petermgreen · 2013-04-30 03:00 · Score: 2
  
  Freebsd and gentoo at least also have binary package systems.
  Afaict the difference is that on BSD/gentoo building from source at install time is the primary method while installing binaries is an extra. On debian installing binary packages is the primary method while building from source at install time is an extra.
  
  --
  note: i'm known as plugwash most places but i screwd up registering that here somehow in the past and now can't register
21. Re:Excuse my ignorance by Ash-Fox · 2013-04-30 03:04 · Score: 2
  
  I don't think most people on Debian are rebuilding their systems using apt-build.
  
  I don't think most people would need to on any OS unless the OS forced them.
  I have used apt-build on custom architectures (targeting a custom arch, like when I was building packages for my Nintendo DS) and for specific packages that needed extra features the package maintainer failed to provide (usually from a 3rd party repo rather than distro repos).
  
  My boss insists there's some reason to use aptitude but whenever I try to corner him, he tells me about the use case for dist-upgrade without naming dist-upgrade, and can't give other reasons.
  I don't know why you're telling me this.
  
  "apt-get will leave packages in held state"
  Does this even matter since we know how to deal with this trivially?
  
  --
  Change is certain; progress is not obligatory.
22. Re:Excuse my ignorance by Yebyen · 2013-04-30 03:30 · Score: 1
  
  > My boss insists there's some reason to use aptitude but whenever I try to corner him, he tells me about the use case for dist-upgrade without naming dist-upgrade, and can't give other reasons.
  Because, in another thread, I explained that FreeBSD pretty much _does_ make you build the packages, and to that extent GP was right, they are not the same. To compare, Debian has lots of ways that are not really different from each other for not building the packages, and you've just told me about apt-build which I did not ever hear of before, as evidence of this. I know about debian/rules, debuild, debootstrap, kernel-package, dpkg-dev, devscripts, but not apt-build. (Thanks!)
  In FreeBSD, either you're installing packages from pkg, so you're getting something that's as old as the release... or you're using pkgng, which means you must have built the totality of all of your packages (at present there are no distributions of any pkgng target binaries that I know, due to risk of transmitting something naughty), or you're not using binary packages at all (other than once you've compiled them, since it can't be avoided and happens transparently, even if you do "make install" from within the /usr/ports tree, you get packages in some format)
  
  --
  Restating the obvious since nineteen aught five.
23. Re:Excuse my ignorance by fast+turtle · 2013-04-30 03:32 · Score: 1
  
  Yep and it's about as usable as an LFS (linux from scratch) build is. No package manager and not much more then the damn shell (bash).
  As a gentoo user, I'm considering starting with an LFS build after converting portage from python over to pure "C" as LFS does include enough of the toolchain to build things.
  
  --
  Mod me up/Mod me down: I wont frown as I've no crown
24. Re:Excuse my ignorance by Yebyen · 2013-04-30 03:32 · Score: 1
  
  In summary, it's not really different, you're really just moving the location of the curtain to in front, or behind... someone had to build the distribution packages up from source, and that person was not extracting tarballs by hand.
  
  --
  Restating the obvious since nineteen aught five.
25. Re:Excuse my ignorance by unixisc · 2013-04-30 03:41 · Score: 2
  
  In the FBSD family, there are the portsng, and then, there are the PC-BSD based PBI system. PBI is really good in that it checks for all version dependencies, and then frees up space by removing the genuinely redundant dependencies using a hash table. In fact, FreeBSD is being distributed on the same media in the same format, and even pFsense has adapted this PBI distribution.
  I am surprised therefore that DragonFlyBSD didn't choose to go with this solution. On a different note, DragonFly is still on GCC? I'd have thunk that they'd be interested in LLVM/Clang or PCC or some such...
26. Re:Excuse my ignorance by hobarrera · 2013-04-30 03:43 · Score: 2
  
  Ports are generally small scripts that retreive source and build a binary package that is then installed.
  OpenBSD uses special Makefiles that do exactly this. The few binary packages provided are just those generated by these makefiles (only some are provided in binary form).
  Archlinux uses PKGBUILDs which are quite similar (in nature, not in syntax) to BSD's ports. While arch uses binary repositories, building a package is just a matter of running makepkg with the correct PKGBUILD file.
  Compared to rpm and deb? Most of the everyday features are there. I'm sure some of the less-common rpm/deb features are missing. Dependency management has existed for ages, of course.
27. Re:Excuse my ignorance by hobarrera · 2013-04-30 03:45 · Score: 1
  
  In most GNU/Linux distributions, "linux" is just another package, that gets updated via the package manager.
  In BSDs, the kernel (and the rest of the base system) is NOT updated via de package manager, but must be upgraded separately.
28. Re:Excuse my ignorance by The+Moof · 2013-04-30 03:56 · Score: 3, Informative
  
  The regular package management for BSDs, the ports collection
  The regular package management for BSDs is the pkg utilities, the ports collection is a source control tree of available software that you compile yourself.
29. Re:Excuse my ignorance by fnj · 2013-04-30 03:56 · Score: 1
  
  Yes, you're absolutely right. I wrote that with 99.9% of linux users in mind and avoided making the post 10 times longer than it had to be, just to be rigourously pedantic.
  The fact is, in RHEL, Debian, Ubuntu, etc, etc, etc; all the distros the vast majority of linux users use, the kernel is a binary package.
30. Re:Excuse my ignorance by Anonymous Coward · 2013-04-30 04:00 · Score: 2, Informative
  
  To be fair, only FreeBSD uses the Ports Collection, but also uses 'pkg' which fetches precompiled binaries and installs them and handles dependancies, which is pretty much exactly like apt and rpm. NetBSD and IIRC, OpenBSD both use pkgsrc, which also fetches binary packages, exactly like apt and rpm. All three have had this sort of package management forever.
31. Re:Excuse my ignorance by Just+Some+Guy · 2013-04-30 04:02 · Score: 3, Insightful
  
  Ports in FreeBSD, in my experience, if you follow a production-like attitude, rather than an ADD OH-NOEZ-THIS-PORT-IS-30-SECONDS-OUT-OF-DATE-MUST-UPDATE methodology, works better than any package manager I've seen (rpm, deb, yum, apt).
  My only complaint about FreeBSD ports is that, somehow or another, everything you install wants to depend on X.
  
  $ sudo portmaster -a Upgrade foo-ldap-4.3.5_1 to foo-ldap-4.3.9 Install net/openldap24-sasl-client Upgrade postgresql-server-9.1.2 to postgresql-server-9.1.9 Upgrade tcl-8.5.9 to tcl-8.5.11 Upgrade vim-7.3.81 to vim-7.3.897 Install X11/every-damn-thing ===>>> Proceed? y/n [y] n
  
  ...followed by bisecting to see which port wants to install the perl-tk package so it can install a config tool you'd never actually run on a production server. It desperately needs a WITHOUT_X11_I_MEAN_IT_DAMMIT=yes option.
  
  --
  Dewey, what part of this looks like authorities should be involved?
32. Re:Excuse my ignorance by Anonymous Coward · 2013-04-30 07:04 · Score: 0
  
  Put this in your /etc/make.conf:
  WITHOUT_X11=yes
33. Re:Excuse my ignorance by Just+Some+Guy · 2013-04-30 07:17 · Score: 1
  
  Yeah, but that doesn't work nearly as effectively as the name would imply. I still end up with X11 trying to sneak its way in.
  
  --
  Dewey, what part of this looks like authorities should be involved?
34. Re:Excuse my ignorance by greg1104 · 2013-04-30 08:08 · Score: 1
  
  Ports in FreeBSD, in my experience, if you follow a production-like attitude, rather than an ADD OH-NOEZ-THIS-PORT-IS-30-SECONDS-OUT-OF-DATE-MUST-UPDATE methodology, works better than any package manager I've seen (rpm, deb, yum, apt).
  It's manageable for a single system. The installations I've seen switch away from FreeBSD over this issue mainly cited how much effort it took to synchronize package sets on lots of machines at once. Let's say you kick off adding a new machine every week and need four of them. By the end, the odds are significant that the last system will not have the same setup as the first, given that three weeks have gone by. The actual compile time involved means that you can't even be assured that systems are identical even if you kick off a port update at the same time. If one machine is faster than the rest, it might end up with a different package set.
  You can try to manage this with enough work and knowledge of the ports system. But that knowledge isn't very widely available. It's a whole lot easier to get a repeatable build with an easy to find Linux administrator. It's trivial to make a farm of RedHat Linux systems all have identical package sets for example. If you get official RHEL, they even provide a dashboard to help with the job.
35. Re:Excuse my ignorance by Yebyen · 2013-04-30 08:39 · Score: 1
  
  I know that it's verbodten but I do this in my personal crontab:
  4 0 * * * sudo portsnap cron update && sudo ezjail-admin update -P
  Could probably pick a better time than 4 minutes after midnight, but I'm unlikely to be upgrading ports late at night (in a jail) at that time.
  This takes 90% of the hurt out of upgrading ports. If you're not comfortable that you might want to upgrade ports around midnight, then pick a day, say Sunday, or the 30th, and make that the day. The remaining hurt is taken away by upgrading ports in each jail edging towards _more_ than once every 3 weeks, and away from _less_ than once every 3 quarters of a year.
  portmaster -y --clean-distfiles
  This also comes in handy, knowing that without doing it before executing portmaster -a, I'm not only going to have to answer any config questions that have changed upfront before examining the list of packages to upgrade, but I'm also going to get prompted to delete old source packages after compiling but before installing each port that has left a stale source package lying around.
  That was the worst part, knowing it's going to take small bits of my attention for the whole (N minutes/hours) that are required to compile as many updates as I need, extra time spent not compiling but waiting for my approval to continue. Then I found the man page.
  I would speculate that there are thousands of people who have done this type of work on most popular open systems, and some of them most certainly have dozens of machines to keep up to date.
  
  --
  Restating the obvious since nineteen aught five.
36. Re:Excuse my ignorance by greg1104 · 2013-04-30 09:22 · Score: 1
  
  I would speculate that there are thousands of people who have done this type of work on most popular open systems, and some of them most certainly have dozens of machines to keep up to date.
  One of the large anecdote examples I was on the edge of was how the PostgreSQL project migrated infrastructure from a heavy use of FreeBSD toward Linux. I'm not quite familiar enough with FreeBSD to comment on how many of their problems were specific to the jails structure they were using. But even with the relatively good pull PostgreSQL has for finding volunteers, we were able to find exactly zero people who felt comfortable they could solve the project's issues around package management. Switching to Linux instead has vastly increased the number of people able to help.
  To any extent that the BSDs can move toward binary packaging that acts more like Linux's, I think that's a good thing. ports is great for a lot of situations and you certainly can solve a variety of use cases with it. It really could be a lot easier for non-experts to use in a way that gets repeatable server builds though.
37. Re:Excuse my ignorance by Tarlus · 2013-04-30 11:02 · Score: 1
  
  Well, even a distro that provides a package management system does not force you to use a packaged kernel. You can roll your own from vanilla and have it coexist happily with other pre-packaged kernels in /boot. I did this in Debian for years.
  
  --
  /* No Comment */
38. Re:Excuse my ignorance by Anonymous Coward · 2013-04-30 12:25 · Score: 0
  
  Gentoo has basically the same issue, and it has a -X useflag. The issue that has been cropping up in it a lot is packaes that have dependencies in them they dont actually need, which force X to be pulled in.
39. Re:Excuse my ignorance by theArtificial · 2013-04-30 13:14 · Score: 1
  
  While the topic of the discussion is about DragonFly BSD, I'd like to expand upon your broad post concerning all BSDs and "everything" being compiled from source.
  
  The regular package management for BSDs, the ports collection, is not like .rpm or .deb at all...Everything there is compiled from source based on some pretty beefy makefiles.
  Binary packages are also available for many ports, this is not a new thing for the ports collection or pkgsrc which is what DragonFly BSD uses. In addition to the various formats software may be obtained from the ports collection there are various branches one may follow: unstable, stable, and release. With regards to staying up to date, FreeBSD uses a rolling release for their ports so staying on top of things can become involved if one is using a release machine in a desktop role, ya know with lots of client side libraries for Gnome/KDE/etc. If you're updating multiple machines a build server is one way to go, here is an interesting discussion addressing updating FreeBSD.
  
  While I like FreeBSD keeping it up to date requires more effort, than say Debian, this will become apparent when there are multiple machines to tend to.
  
  --
  Man blir trött av att gå och göra ingenting.
40. Re:Excuse my ignorance by iggymanz · 2013-04-30 15:14 · Score: 1
  
  OpenBSD has LOTS of binary packages,over 7000 of them installable with just a pgk_add -i
  sure, you can use ports too, but the preferred way for average user is the binary package sytem
41. Re:Excuse my ignorance by Anonymous Coward · 2013-04-30 16:45 · Score: 0
  
  If you use RedHat family distros its the samething. There are packages out there that dont require CUPS but it will get installed because some dependency chain requires it. On my servers I do not want CUPS. I only want CUPS if I absolutely need it, which I 99.99999% of the time never need CUPS. Then there was the audit package in RHEL 4 where if you tried to uninstall it there would go the entire system as a result because every package required it. This was fixed in RHEL 5 but uninstalling audit was a requirement because in RHEL 5 it used to have a bug where it would hang the entire system.
42. Re:Excuse my ignorance by Anonymous Coward · 2013-04-30 23:01 · Score: 1
  
  DPorts fully uses pkgng. Actually, old tools pkg_* are not even present. pkgng is somethink like a GNU package manager. You can use pkg install, pkg autoremove etc. Dependencies are managed by the package manager.
  The policy is to keep two sets of packages : RELEASE, binaries freezed at the release time, and LATEST, were packages are updated when an update is avaible.
  Dports currently comes with more than 19 000 binary packages for both x86_64 and i386.
43. Re:Excuse my ignorance by Anonymous Coward · 2013-05-01 04:27 · Score: 0
  
  BSD packages were built with source as an initial thought and binaries as an afterthought, which is the inverse of debian / redhat based package management. On both ends there are the options to install packages with binaries or to download source packages, compile them into binaries, and turn that (through an automated process) into a package which is then installed just the same. There is more emphasis on the source side in the BSD world. I wouldn't say that the ports collection is regular for BSDs. It's one of the two most popular, the other being pkgsrc, which DragonflyBSD used prior. The only big difference would be in the format of the .deb vs .rpm vs .tbz that's generated by the package management system, with ports using gzipped tarballs, redhat using cpio archives, and debian using ar archives.
44. Re:Excuse my ignorance by lemur3 · 2013-05-04 11:42 · Score: 1
  
  openbsd allows getting a selection of each archs precompiled binaries as well as the option to build from source the entire port tree.
  some ports are available as source only, to be compiled by the enduser
Wait? by kurt555gs · 2013-04-30 01:15 · Score: 0

I read on Slashdot that BSD was dead. And, Netcraft proves it. So, what is this?

--
* Carthago Delenda Est *
1. Re:Wait? by Aguazul2 · 2013-04-30 01:37 · Score: 2
  
  They have some nice ideas. The one that particularly interests me is settings up a bunch of DragonFlyBSD servers and having jobs run transparently across them, load-balancing across the cluster. This is like multi-core at the server level -- the same kind of underlying abstractions as well. Not sure if they've got it up and running yet.
2. Re:Wait? by Anonymous Coward · 2013-04-30 01:37 · Score: 0
  
  A slow news day?
3. Re:Wait? by Anonymous Coward · 2013-04-30 02:02 · Score: 0
  
  That exists in Linux, DragonFly is just marketing-fluffizing it. It's certainly not like multi-core at the server level, and doesn't work for a lot (most) workloads.
Poor scalability by Anonymous Coward · 2013-04-30 01:49 · Score: 0

I like how "large multicore" is a little 4 socket thing. This was the BSD that completely rewrote their locking primitives and redid locking of subsystems in order to be multiprocessor scalable.
1. Re:Poor scalability by LizardKing · 2013-04-30 01:54 · Score: 1
  
  The stability issue was on 48 core systems. That would be something like a ARM Bulldozer setup if it only had four sockets, and that's certainly not a "little thing".
2. Re:Poor scalability by LizardKing · 2013-04-30 02:28 · Score: 1
  
  AMD even ...
3. Re:Poor scalability by Anonymous Coward · 2013-04-30 02:37 · Score: 0
  
  No, it would have been an 4 socket Magny Cours Opteron. From AMD, not ARM.
  And yes, that is a little thing. It is not a "large multicore" these days. A small "large multicore" would have tens of sockets and hundreds of cores. POWER7, for example can have 32 sockets, 256 cores, 1024 threads. UV Altix can have up to 256 x86 CPUs with 2048 cores (earlier generations of Altix actually went larger in terms of nodes and interconnect mesh size).
  Something that can fit on a single motherboard can not be considered large multicore, I'm sorry.
4. Re:Poor scalability by fast+turtle · 2013-04-30 03:43 · Score: 1
  
  and part of the reason they got off their asses was Intel demo'd that 100core cpu. How about having 12 or more of them if they're low-power (ARM range) but full x86_64 compat?
  
  --
  Mod me up/Mod me down: I wont frown as I've no crown
5. Re:Poor scalability by greg1104 · 2013-04-30 08:35 · Score: 1
  
  Saying that something isn't a large multi-core server until it hits supercomputer scales is setting the bar a bit higher than I think most people care about. I get exposed to more leading edge hardware than most people, since I'm well known for doing database performance tuning. I see 48 core servers all the time at businesses; even my toy server at home has 24 cores nowadays. I have seen SGI Altix hardware with a very large number of cores, and most recently I had root access and some testing time on a 256 core server. I see those as pretty exceptional cases though. There's very few people who care about scaling above 48 cores right now.
6. Re:Poor scalability by Anonymous Coward · 2013-04-30 11:11 · Score: 0
  
  No, a system on a single motherboard is simply not a "large multicore". The big POWER7 boxes are not supercomputers, they're enterprise servers. But I didn't say you have to go that large to qualify as a large multicore; I said tens of sockets and hundreds of cores.
  In terms of numbers, of course these are exceptional, and there are relatively few people who use them. By contrast, 4 socket is pretty common and not really worth getting hyped up over. The real news is the fact that they sucked so badly on a small system before this release.
Yawn... by FORTRANslinger · 2013-04-30 01:56 · Score: -1, Flamebait

"... BSD has released version ..." ...and nobody gives a fuck. And the world keeps spinning...

--
I'm looking over the wall; and the're looking at me!
1. Re:Yawn... by Anonymous Coward · 2013-04-30 03:01 · Score: -1
  
  Why don't you kill yourself so the rest of us who are not assholes can get on with our lives.
2. Re:Yawn... by Anonymous Coward · 2013-04-30 06:37 · Score: -1
  
  He's right, though...
Supports gcc 4.7 by fnj · 2013-04-30 03:03 · Score: 1, Interesting

Gcc 4.8 has been totally stable for a while now, so I'm just a bit underwhelmed.
1. Re:Supports gcc 4.7 by kthreadd · 2013-04-30 03:13 · Score: 1
  
  The summary is a bit off. They are using gcc 4.7 as the system compiler. GCC 4.8 supports BSDs just fine.
2. Re:Supports gcc 4.7 by fnj · 2013-04-30 03:59 · Score: 1
  
  Yes, and interestingly, "GCC 4.4 remains on the system and still has an important role as the primary DPorts compiler."
3. Re:Supports gcc 4.7 by Anonymous Coward · 2013-04-30 06:25 · Score: 0
  
  Yes, and interestingly, "GCC 4.4 remains on the system and still has an important role as the primary DPorts compiler."
  Cause dports is using FreeBSD's ports as a base, and as noted, DragonFly is the first BSD to use GCC 4.7. FreeBSD has... GCC 4.2? 4.4? I forget. Anyway, it's for compatibility.
4. Re:Supports gcc 4.7 by greg1104 · 2013-04-30 08:40 · Score: 1
  
  The leading edge for what compiler is used to build the system packages lags pretty far behind current, and that's not necessarily a bad thing. To put this in perspective, right now the business mainstream RHEL6 is using gcc 4.4. It's particularly easy to rebuild your whole system with a later compiler given the ports system.
GNU compiler on BSD by dutchwhizzman · 2013-04-30 04:15 · Score: 1

What is happening here? Heretics dare to use GNU code on a BSD system? Sacrilage!

--
I was promised a flying car. Where is my flying car?
1. Re:GNU compiler on BSD by iggymanz · 2013-04-30 04:49 · Score: 1
  
  the BSD are considering other compilers, FreeBSD going to CLang and NetBSD might go to pcc
2. Re:GNU compiler on BSD by Anonymous Coward · 2013-04-30 05:39 · Score: 0
  
  What is happening here? Heretics dare to use GNU code on a BSD system? Sacrilage!
  DragonFly BSD is not developped by crazy and integralist ideologists as is the case of the FreeBSD project.
  Remember that DragonFly was a fork of FreeBSD. And it's ironic because had Sun not made the ZFS license compatible with BSD just to spit on Linux, DragonFly BSD would have left FreeBSD in the dust years ago.
3. Re:GNU compiler on BSD by unixisc · 2013-04-30 09:40 · Score: 1
  
  I believe OpenBSD has already gone to PCC. In the meantime, Minix, which uses NetBSD userland, has also gone LLVM/Clang
4. Re:GNU compiler on BSD by iggymanz · 2013-04-30 10:56 · Score: 1
  
  not yet, it can compile openbsd on some architecture but I see it's still using gcc even for the new 5.3
5. Re:GNU compiler on BSD by idunham · 2013-04-30 16:23 · Score: 1
  
  > What is happening here? Heretics dare to use GNU code on a BSD system? Sacrilege!
  BSD has used GNU tools for ages, but most of them have lagged behind.
  FreeBSD is sticking to GPL2, which is GCC 4.2.1--but you can get a newer one from ports.
  OpenBSD has 4.2.1 and 2.95.3.
  NetBSD is the other BSD to use a GPL3 GCC, with GCC 4.5 as far as I can tell.
  MirBSD is on GCC 3.4.
  And the most fun difference: DragonFly BSD uses git as vcs, rather than cvs/svn.
6. Re:GNU compiler on BSD by unixisc · 2013-04-30 21:09 · Score: 1
  
  Uh, in version 10, FBSD is fully deprecating GCC and going w/ LLVM/Clang, as is OBSD fork Bitrig. OBSD will go PCC, while Minix, which uses NBSD userland, will be using LLVM/Clang. I'm not sure what NBSD or MirBSD are planning, but the BSD guys in general are all walking away from GCC due to GPL3
7. Re:GNU compiler on BSD by idunham · 2013-05-02 07:27 · Score: 1
  
  True, but surprise at a BSD using GCC (note that the OP did not mention GPL3) is not warranted by the existing conditions (note that deprecating does not mean dropping, it means stating that they intend to drop it, at FBSD 11 or later).
  Judging by the fact that Thorsten Glaser (MirBSD/MirOS developer/maintainer) is a frequent poster on the pcc-devel list, I'd guess PCC. Also, some of the other MirOS projects are in a similar vein.
  I suspect that NetBSD will use whatever compiler supports more of their architectures, with a preference for Clang when it's roughly equivalent...
8. Re:GNU compiler on BSD by unixisc · 2013-05-02 07:35 · Score: 1
  
  The Bitrig project, which is a fork of OBSD, was initially using GCC to compile it, but has to date managed to build OBSD using LLVM/Clang. Only limitation of theirs - portability is not their goal like it was w/ OBSD, so one doesn't see legacy UnixServers like Suns being supported by it, just x86 systems
ZFS, Hammer & FBSD by unixisc · 2013-04-30 09:46 · Score: 1

ZFS followed Sun's CDDL, and BSD has nothing against combining any sort of code with it. It's other licenses that may have problems w/ BSDL, but not vice versa. So was CDDL BSDL incompatible, which Sun fixed? Besides, had FBSD gone w/ Hammer, they'd have had a fully compatible license. Incidentally, what are the advantages of Hammer over ZFS? I thought that the only advantage of DragonFly itself was that it was very well optimized for SMP systems - more so than FBSD. Is that a misconception?
1. Re:ZFS, Hammer & FBSD by Anonymous Coward · 2013-04-30 11:49 · Score: 0
  
  They are different. Hammer isn't striving to be a file system and volume manager in one. The main goal of Hammer is multi-master clustering(even over internet) and file versioning. Hammer1 was a step in between as using btree didn't prove to be good enough, and supports only read-only slaves. Hammer2 on the other hand will be a different beast, designed from scratch to support multi-master replication, while keeping all the good things Hammer1 did.