The tpm(4) driver has been added by Sascha Wildner, ported from FreeBSD. What’s it do?
From the man page: “The tpm driver provides support for various trusted platform modules (TPM) that can store cryptographic keys.” Crypto keys stored in hardware, where they are in theory unmangleable, instead of on the disk. At least, that’s my impression after 30 seconds of research.
Sepherosa Ziehau has posted some numbers showing improvements in ip forwarding rates. He’s done this before, except this time it’s with bnx(4), probably because of his recent commits.
John Marino managed to update GCC from 4.7.2 to 4.7.3 (4.7 changelog), zlib from 1.2.7 to 1.2.8 (changelog), and awk from 20110810 to 20121220 (can’t find a changelog).
In other update news, Matt Dillon has been working on HAMMER2′s flush sequencing.
Update: tcsh too.
In the week after DragonFly 3.4 was released, Francois Tigeot was tracking downloads for each type of packaging system. It looks like dports downloads far outnumber pkgsrc. I think there’s reasons it appears different in uptake, but it’s still neat to see people trying the new system.
If you have a sili(4) device, Francois Tigeot needs you to run a particular patch and tell him what happens. He’s testing a larger I/O request size, and wants to see how it will work out “in the field”.
I’ve put the 3.4 release images up on terasaur, a Bittorrent seeding site. Please try pulling them and let me know how it goes. I haven’t torrented many things, so I am unsure how to even verbify “torrent’. Hopefully that sentence and those links work out.
If you’re looking to install DragonFly on a Kimsufi server, and you can read French, this explanation may help you. (via Enjolras on EFNet #dragonflybsd)
If you’ve ever wondered about how you can resize/move a HAMMER filesystem, follow this thread for a variety of answers.
Have you ever wondered about how the booting process works on DragonFly? Well, Ivan Uemlianin did, out loud. Several different recommendations followed, so now you can learn too.
It’s been 2 years since the pkgsrc packages for DragonFly 2.12/2.13 were getting updated, so I am going to remove them. If you’re running DragonFly 2.12, you’ll want to either build from source or upgrade DragonFly.
‘william opensource4you’ posted a summary of the steps he took for setting up a DragonFly system with XFCE4, using dports. It’s pretty straightforward, and thanks to dport’s binary nature, should be exactly reproducible.
John Marino brought up a point every operating system project will have to think about: when does support for i386 (i.e. 32-bit x86 processors) stop? Follow the thread for details. There’s no final answer, yet.
As posted in my email to users@: Version 3.4 of DragonFly is officially out.
The release ISO/IMG files are all available at the usual mirrors:
http://www.dragonflybsd.org/mirrors/
The release notes have details on all the changes:
http://www.dragonflybsd.org/release34/
If you are planning to try the new dports system for installing third-party software, check the DPorts Howto page:
http://www.dragonflybsd.org/docs/howtos/HowToDPorts/
If you have an installed DragonFly 3.2 system and you are looking to upgrade, these (not directly tested) steps should work, as root:
cd /usr/src
git fetch origin
git branch DragonFly_RELEASE_3_4 origin/DragonFly_RELEASE_3_4
git checkout DragonFly_RELEASE_3_4
… And then go through the normal buildworld/buildkernel process found in /usr/src/UPDATING. If you are running a generic kernel, that can be as simple as
make buildworld && make buildkernel && make installkernel && make installworld && make upgrade
(and then reboot)
If you encounter problems, please report them at bugs.dragonflybsd.org. I get better at testing for each release, but I also get better at discovering new problems just after release.
Are you using hotplugd? If you are, this post from ‘william opensource4you’ about a small patch he made may be useful to you.
John Marino has committed updates for libmpfr, diff utils, grep, and libexpat/libbsdxml. Libmpfr, the one item that I suspect doesn’t spring instantly to mind, is a library for floating-point computation.
As I described in a post to the kernel@ mailing list, the DragonFly 3.4 images are getting uploaded for mirroring and downloaded for testing. Assuming no surprises happen, we will be able to release very soon.
Now’s the time to put in your application for Summer of Code projects, if you’re a student. The application period runs until May 3rd. There’s already been some proposals on the mailing lists; now they can be put in officially.
I’ll point out the last link is from a returning GSoC student, and has a lot of detail; use that as an example if you’re thinking about your own application.
If you administer one of the DragonFly mirrors, there’s a new /dports directory that can be mirrored. See that second link for details.
Ivan Uemlianin expressed a desire to read about the boot process, and how BSD works in general. I made a short list of suggestions.
John Marino published a ‘cheatsheet‘ (also, typo fix)for DragonFly 3.5 users who want to try dports, using DragonFly 3.4 packages.
John Marino has a concise explanation of why dports mostly uses gcc 4.4 still to compile, even if you’re building DragonFly itself with the default 4.7. It’s a reason to not use NO_GCC44 – yet.
Here’s a status report on the 3.4 release, pulled right from my mailing list post:
I’d like to have the release available with binary packages for dports immediately, because I anticipate a number of people wanting to try it out. So, the release will be delayed a few days while the packages upload.
DPorts is based off of FreeBSD’s ports, but it’s possible to add software packages to it that don’t exist in FreeBSD’s ports system and have them build as any other packages. This is briefly detailed in this GitHub bug report, along with a number of the ports that already exist that way.
Matthew Dillon wrote a note about SSDs, HDDs, and swapcache that may be useful for anyone building a system soon. Conversations about SSDs, swapcache, and so on have happened before.
Peter Avalos has updated ftp in DragonFly. It’s actually tnftp, which is the same base ftp client used in FreeBSD/NetBSD/Mac OS X/etc. It’s the 20121224 version, and the 3.4 release branch has it too.
The DragonFly page on the Summer of Code site is set up. If you are a potential mentor that I’ve talked to before, I’ve already sent you an email with details. If you are a potential mentor I haven’t talked to, you can email me or send a request via the DragonFly page. (Google has a new ‘connections’ method for signup this year.)
If you’re an interested student, take a look at the DragonFly Projects Page. Keep in mind that your proposal does not have to be one of those ideas – new projects are always welcome, and often have the advantage of being unique instead of being one of several similar proposals. (hint, hint)
We’re accepted! The application requirements, etc. will be up on the Google Summer of Code site as soon as I can fill out the forms.
The upcoming DragonFly 3.4 release will not include the USB4BSD port from Markus Pfeiffer; he’s hoping for it to become default in the next release after 3.4.
You can still try it, as it’s present in DragonFly but not on by default. Help with driver porting is always welcome, of course.
Constantine Aleksandrovich Murenin has put together a new site, bxr.su. His announcement to users@ goes into a lot of detail, but here’s a preview: it’s an OpenGrok site that has a forked version of OpenGrok that’s both speedy and takes BSD into account, along with other nice features.
Here’s the catch: it’s currently IPv6 only. IPv4 will be on as a test just today, and on for good shortly after. Read that announcement I mentioned for details.
John Marino has posted about the state of dports: over 19500 ports built, build logs available, and patches to add even more can be sent through github. XFCE4, KDE3, and KDE4 are building, though he could use some help with GNOME2.
Man, I’m stretching it to make that “Over nine thousand!” joke, now.
If you have a DragonFly 3.2 system and you want to try the 3.4 release candidate, you can delete your local source, edit the Makefile to pull down 3.4 instead of 3.2, and run it.
cd /usr
rm -rf src
vi /usr/Makefile;
(in vi) :%s/DragonFly_RELEASE_3_2/DragonFly_RELEASE_3_4/g
(save, quit vi)
make src-create-shallow
… then proceed to make buildworld and so on, as normal.
The caveats: I haven’t tested this yet, and this assumes you don’t have any local changes in /usr/src that you want to save. The usual warnings about lighting your computer on fire, etc., apply.
The DragonFly Git repository of pkgsrc now has the 2013Q1 branch. You can switch to it by editing your /usr/Makefile (look for existing references to either pkgsrc master or pkgsrc-2012Q3) and using the normal commands.
If you have a mfi(4) device – in other words, a LSI MegaRAID SAS driver – you can now see/import/clear/etc. foreign configurations, thanks to this commit from Sascha Wildner, tested by Francois Tigeot, and originally from FreeBSD.
For the confused, ‘foreign’ means any disk hooked to a RAID controller that isn’t part of a configuration the RAID device already knows about. A replacement disk, or more worryingly, a good disk gone bad/unrecognizable. (I’ve had both.)
If you have an ath(4), wpi(4) or iwi(4) wireless network link, and you’re running DragonFly-master, please update. Sepherosa Ziehau has pushed Johannes Hoffman’s wlan_serialize branch, which means bringing up wlan0 is a bit easier – and less crashy.
It needs to be tested for wpi(4) and iwi(4), however, so if you have success or failure with those devices, please say so in reply.
(new post category starting now: “Please test”)
DragonFly 3.4 is branched – as a release candidate, with the current target for 3.4.0 release as the weekend of April 13-14. See the tagging commit note for a list of all the commit messages.
Note that in previous releases, we tagged “x.y.0″ on branch, and “x.y.1″ on release. I’m now tagging “x.y.0rc” for the release candidate at branch time, and we’ll tag with a more normal (to my ears) “x.y.0″ for the release.
If you build a 3.4.0rc image right now, you’ll get an older quarterly release of pkgsrc. That’ll be changed tomorrow as the DragonFly pkgsrc git source is updated and I change where 3.4′s /usr/Makefile points.
The 2013Q1 branch of pkgsrc has been announced. Along with the normal quarterly material, there’s several notes: preliminary Cygwin support is present, ruby 1.8 will be retired in favor of 1.9 after this release, and the pkgsrc.org web page now has a very nice new look and logo.
I plan to branch DragonFly 3.4 very soon, and that version will have 2013Q1 as default.
Update: The 2013Q1 branch should be available by tomorrow on DragonFly’s git; the repository needs to update and convert from NetBSD’s CVS and that takes a little time. I’ll post when it’s ready.
I saw this Hacker News post and figured I should emphasize: pkgsrc is still going to be available in the 3.4 release of DragonFly; we’re not suddenly switching to dports. I don’t want anyone to think they’re going to have to rip out all their packages and go to a new, untried system, all at once.
If you were thinking, “Hey, I’d like to try an early version of DragonFly 3.4 before it’s released”, I’ll just point you at the recent daily snapshots of 3.3. These are close enough to a release candidate, I think.
The next release of DragonFly will be 3.4, and it’s probably going to be mid-April.
OpenGrok is a source browser that I have not used extensively, but many people say is a great tool. The same people say it’s difficult to run. Zafer Aydogan just posted that DragonFly’s source is available now from his perfectly-functional OpenGrok installation.
(I’ll put it in the links sidebar here, too.)
NetBSD is using/will be using? ‘npf’, a new version of pf similarly-named-but completely-different firewall from pf. Hubert Feyrer put together a bunch of links talking about it. I link this because DragonFly is using a version of pf equivalent to what OpenBSD 4.8, and there’s been some discussion of what to do next; it appears FreeBSD and NetBSD are forking off separately from OpenBSD’s version.
Update: npf and pf share 2 letters in the name and nothing else, as Joerg told me – corrected.
Hey, look, DragonFly BSD showing in tweetspam! Don’t bother following the tweeted links; they don’t have anything useful. It’s entertaining to see the structure and coding of these bots; they’re no horse_ebooks, of course.
There’s an as-yet-undiagnosed problem with the @dragonflybsd.org mailing lists; you won’t see any mail from them right now. I don’t have an ETA for a fix because I don’t know the underlying cause yet…
Update: Fixed; I think – dragonflybsd.org DNS server was not responding, and it had a ripple effect.
I’ve put in an application for DragonFly to be a Google Summer of Code mentoring organization for the 6th year in a row – we have mentors lined up, so we’ll know by the Friday after next. See my post on kernel@ for pretty much what I just said.
Peter Avalos has committed another batch of updates to sh(1), from FreeBSD. I was going to comment on how strange it was to see software getting updated so many years later; you’d think everything there was to update for /bin/sh had been done at this point. Digging casually, the oldest bit on sh that I can find is from 1991 – 22 years old. The man page mentions a rewrite in 1989 based on System V Release 4 UNIX, and there were versions of sh all the way back to version 1.
Here’s a trivia question – what’s the oldest Unix utility, and what’s the oldest code still in use? I don’t know the answer.
It seems Sepherosa Ziehau won’t rest until he’s reached peak performance for every network card in DragonFly; he’s added multiple ring/MSI-X support for Broadcom 5709/5716 chipsets in DragonFly. In more concrete terms, this means better speeds when transmitting and receiving multiple streams of data.
(at least, I think so.)
I wasn’t aware of this, but apparently DragonFly’s version of patch(1) comes from OpenBSD and NetBSD. FreeBSD’s old version of patch is being replaced by this and modified to match the old one’s behaviors. It would be worthwhile to bring these changes back, if possible, just to reduce the differences in a utility that’s already been around the world, so to speak.
As an aside, I always thought patch was one of Larry Wall’s unsung successes, and I’m entertained by any program that has “Hmm…” as one of its official outputs.
Here’s 3 recent and different commits to DragonFly that I’m commenting on all at once:
I really wish the other BSD projects would include commit lines in the mail message subjects, so it was easier to catch things like these.
If you want to take advantage of the binary packages of DPorts, and have a x86_64 system with a recent DragonFly 3.3 on it: Francois Tigeot has you covered. There’s no i386 packages yet, which are the ones I could use right now, darnit.
If you want to try DPorts, see my earlier article.
The new vm.read_shortcut option has been turned on by default by Matthew Dillon, which should lead to some performance improvements. That improvement has been measured for tmpfs, at least. There’s also some buffer cache improvments that help on x86_64 systems, too.
Update: As Venkatesh Srinivas pointed out, tmpfs also no longer uses the mplock, so it’ll take better advantage of multiple processors.
Thanks to Antonio Huete Jimenez, it’s now possible to set the MAC address for each interface and specify the disk serial number in the command line for a vkernel.
John Marino proposed a method for backing up world when upgrading, for those rare but catastrophic cases where the installed programs can’t run. After some discussion, he committed an automatic backup method, and there’s a ‘restoreworld’ target to take advantage of it.
The kernel already gets renamed to kernel.old as a backup, if I remember correctly.
If DragonFly is going to participate in Google Summer of Code for 2013, we need project ideas, and lots of them, at any size. There’s an existing project page that anyone can add to, especially if you’re a student and looking to add your ideas.
Sepherosa Ziehau has posted more statistics on his ifnet/ifaddr per-CPU stats work. It’s doing so well that he’s very close to reaching the maximum physical capacity of the 4x gigabit ethernet hardware he’s using.
As Sepherosa Ziehau mentions in his latest commit, DragonFly now collects IFNET/IFADDR statistics on a per-CPU basis. This makes it more accurate, but may mess with any third-party program that accessed it directly. I don’t know if there’s anything in pkgsrc that does that…
I know OpenSSL in DragonFly was just updated, but Peter Avalos has done it again, bringing it to version 1.01e. I assume this new version is to fix some recently-exposed problems. He also has updated libdialog, which was previously not located in contrib/, as sime third-party software needed a more modern version. As a side effect from that, tzsetup in DragonFly now matches the version in FreeBSD and NetBSD. And, Sascha Wildner has updated the locale files on DragonFly, also to match FreeBSD and NetBSD.
If you’re near Germany, or like IPv6, the Schlund Technologies mirror for DragonFly is for you – it supports HTTP, FTP, and rsync.
The machines at dragonflybsd.org are now on a different part of the Internet, so if you were having problems connecting over the past few days, it should be better now. Matthew Dillon wrote up details of what he changed and why he changed it, including a note about future blade server plans.
Added: Peter Avalos has updated OpenSSL to version 1.0.1d – see the changelog.
Removed: support for ISA sound cards, by Sascha Wildner. Goodbye sb16; I’ll remember you fondly.
It’s announced! If DragonFly is going to participate again for the sixth year in a row (wow!), we need mentor volunteers…
Matthew Dillon is moving dragonflybsd.org’s network link to a new VPN today. (It may have already happened; I only just read the email.) This may help the people that have reported their network path to dragonflybsd.org seems to die somewhere in the Cogent network…
The emx(4) driver now has support for multiple TX queues, but it’s not on by default. There’s scenarios where multiple queues work out with that hardware, but you have to be sure you are actually in the right setup for that first. Check Sepherosa Ziehau’s commit message for the details.
Sepherosa Ziehau has merged the hardware abstraction layer (HAL) for em(4) and igb(4), along with updating em(4)/emx(4) to version 7.3.4 and igb(4) to version 2.3.7.
John Marino has set gcc 4.7 as the default compiler in DragonFly. This replaces the previous default of gcc 4.4. The 4.4 version is still available, and while you can set NO_GCC44 to keep it from being built, John’s commit message notes that it’s still useful especially for some ports that don’t work with gcc 4.7.
If you have git installed, and you are trying to upgrade it, you may have problems. The scmgit-docs package dependency requires some DocBook files that aren’t always accessible. If you do run into this problem, there’s 3 separate options:
Sepherosa Ziehau has posted a detailed message showing the speeds he gets with multiple transmission queues, using igb(4). The short version:
Quick summary, the multiple TX queue support gives me: +200Kpps for 2 bidirectional normal IP forwarding (now 4.40Mpps) +160Kpps for 2 bidirectional fast IP forwarding (now 5.23Mpps)
GCC version 4.7 is already available now in DragonFly 3.2, but it’s not the default compiler. John Marino intends to make it default for the next release. What’s that mean for us? Nothing other than a new compiler, since he’s already fixing related issues.
Markus Pfeiffer reports success using Xen HVM to run DragonFly, which may be useful for any of you Xen users. He reports not being able to use more than 2 virtual CPUs, though Scott Tincman reports successfully using 4 (with qemu), so your mileage may vary.
Updated: noting qemu usage as Markus pointed out in comments.
Sepherosa Ziehau makes commits almost daily to DragonFly’s network infrastructure, but I have a hard time quantifying it into Digest posts in part because it’s often very technical. His most recent commits come with an explanation, however. He has done plenty of work to improve overall transmission speeds in DragonFly, and now he’s working on ‘fairness’. Fair, in this case, means ensuring that packet transmitting and receiving happen without either one monopolizing the connection. In real world terms, this translates to much more constant speeds. His recent commit details what he’s doing and some numbers to prove it.
Remember I said he’s improved speeds? Note that in his example, he’s reaching stable peaks of 981 Mbps. This is on a line that I assume theoretically maxes out at 1000.
Based on this bug report on the recently updated m4, you may need to perform some extra steps to update m4 as part of a normal upgrade:
# cd /usr/src/usr.bin/m4 # make # make install clean
If you have a DragonFly 3.3 system with DPorts, can you install xorg, then ssh -Y from another machine to there, and see if you can remotely run an X program like xterm with local display? I’ve done this twice on two different machines with DPorts and it won’t work. xorg won’t write the security info to ~/.Xauthority, with ssh or xhost or whatever. It’s driving me crazy.
(Yeah, slow news day.)
Peter Avalos has updated m4 for DragonFly. This will bring us a little more in sync with the other BSDs. Also, John Marino has updated flex, which is apparently 17 years old? Meaning it hasn’t been updated in DragonFly ever, and then not in FreeBSD before that, for a long time. Looking at the timeline on the flex web page appears to match.
Dave Hayes asked for some “best practices” ideas for setting up a HAMMER (1) system. I replied, and the conversation turned to RAID, as these often do. If you’re thinking of purchasing disk hardware in the near future, this will be useful to you.
Sepherosa Ziehau has added a generic form of support for multiple transmit queues in DragonFly. This means less contention when transmitting. It’s not done; he has drivers to set up and as he said, it’s “step 1 of many“.
If you are a brave soul and have an IPv6-only DragonFly installation, there’s now a git mirror of DragonFly that is available on IPv6.
