Sascha Wildner brought in ACPICA 20140214, and his commit message has a list of the updates.
The DragonFly Mail Agent is being suggested as a possible sendmail replacement for FreeBSD.
I’ve tagged version 3.6.1 of DragonFly, and built ISO/img files of it. They should be available by now on mirrors if you need them, or you can just upgrade as normal. See the linked tag commit message for what’s changed.
Grep /var/run/dmesg.boot for PMM, and if it turns up, Sepherosa Ziehau has a patch he’d like you to try.
If you have i915 chipset-based video on DragonFly, and you get a “Output xxx has no Monitor section” complaint in your xorg logs, look at this fix using xrandr.
As I mentioned on kernel@, I’m going to roll a point release of DragonFly soon. Push in your changes if you want to get them in!
Antonio Huete put together a list of goals for the next release on the DragonFly bugtracker. Some of them are pretty ambitious, some of them are relatively easy, but they are all very useful.
We’ve got Go builders running for DragonFly, but nobody actively maintaining Go itself on DragonFly. The dports version builds, but there’s a Go release coming up and having native support would be much better than relying on chance FreeBSD build compatibility.
The current error as I type this is a TLS problem that sounds like a simple fix, if only I knew where it was.
Here’s a potential DragonFly and Summer of Code project: adding support for more than 63 cores to DragonFly. Matthew Dillon has already outlined how.
There seems to be a lot of ACPI-related updates lately: Sascha Wildner has updated ACPICA in DragonFly to what I think is the very latest version. See his commit for the differences.
John Marino updated daemon(8) on DragonFly. For some reason, I didn’t know it was a standalone program. I knew about the idea of daemons as helpers based inside the computer, which is why so many server programs end with a ‘d’ – sshd, ftpd, and so on. Inexplicably, I never actually saw the program itself.
As you read this, I’m at NYCBSDCon – or at least should be.
- FOSDEM 2014 videos are up. The second item listed is about the new version of ports, which includes dports. (via)
- Crochet-FreeBSD, a system for building bootable FreeBSD images for a variety of platforms including x86, ARM, and VM. (via Markus Pfieffer on IRC, indirectly)
- Effective Spam and Malware Countermeasures. Seen previously at BSDCan. ‘Greytrapping’, mentioned in the article, is new to me.
- Email delivery headaches. Mailing many people is somehow almost always a low-level irritation.
- DiscoverBSD’s 2014/02/03 roundup.
- Another n2k14 hackathon report. DragonFly uses that DHCP client he’s talking about.
- PC-BSD on eWeek.
- bsd-cloudinit – FreeBSD on OpenStack. (via)
- OpenBSD gained some VAX hardware. The only VAX hardware I ever saw was 6 feet tall; I can’t imagine these are easy to ship.
- OpenBSD updated to ldns 1.6.17.
- Seen via a pkgsrc list: Berlios.de is closing down its hosting, so this may affect you if you usually grab your pkgsrc packages from there.
- The proper way to break the FreeBSD ABI.
- Robert Watson’s privilege ideas.
- How to switch between mfi(4) and mrsas(4) on FreeBSD. mrsas(4) sounds like MRSA to me, which is a bit more worrisome
- FreeBSD supports MegaRAID Fury cards.
- The plan for ATF removal in NetBSD.
- DragonFly takes the FreeBSD patch(1) updates, and that’s fine, because FreeBSD made those changes to an import of DragonFly’s patch(1). Hooray for cross-pollination!
Probably because of the C-state changes, Sepherosa Ziehau wants people to use a new set of sysctls instead of the hw.cpu_mwait* ones – at least on x86_64. This won’t affect you if you aren’t already familiar with them, probably.
It’s now possible to reach deeper power-saving C-states with DragonFly, thanks to work from Sepherosa Ziehau. It’s possible to have it auto-adjusted by setting two sysctls.
I put in the application for Google Summer of Code 2014, for DragonFly. Will we get in for a 7th year? I hope so!
(I still want more mentors; contact me if you’re interested.)
I already asked this question on kernel@, but I’ll repeat it here. Who is interested in mentoring for DragonFly, for Google Summer of Code 2014? The org application period is starting today, and it would be neat to do this for a seventh year in a row.
There’s been periodic commits updating the USB4BSD support in DragonFly; I haven’t been linking to them because they are generally incremental. However, it’s good to (re?)mention just how you can build DragonFly with that new USB support.
xf86-video-intel-2.21.15 should now work on your DragonFly system. I don’t see it in dports, yet, though.
Recent updates to tzcode apparently fixed a long-standing time zone bug in DragonFly. POSIX says the America/New_York timezone is picked as default if nothing else has been selected. That didn’t happen in DragonFly – until recently. If your timezone seemed to suddenly jump to U.S. Eastern time, that’s because you never picked before.
Brad Fitzpatrick showed up on the users@ list and mentioned that for DragonFly to be supported in Go, it needed to show up in the Go Dashboard with building reports. I now have the Go builder running on pkgbox32/pkgbox64.dragonflybsd.org. Check the builder page to see status.
Note: Installing the port of Go from Dports works just fine; this is the mechanism for testing Go on a per-commit basis for the people who work on Go – so a ‘fail’ notice on the builder page doesn’t necessarily mean anything, unless you are developing Go itself. This may already be clear to you.
With everyone buying tablets lately, the low end of computers is getting pretty low-cost indeed. Creating single-purpose computers is possible, and I was thinking of doing that to create a Go-testing system. (Though probably not necessary for me.) It got me to thinking, though…
How low-cost a system could run DragonFly? The master-slave and low system requirements of Hammer lead to some interesting possibilities. There’s no Arduino equivalent for DragonFly because there’s no DragonFly on ARM, despite all my wishing. DragonFly has been run on Soekris systems before, and might work on a PCEngines ALIX board. Ebay, my basement, or Craigslist are options too, but not as fun. Who has suggestions?
If you want to test out the latest (20131218) update to ACPICA, Sepherosa Ziehau’s got a patch for you.
This will be good for anyone who wants to use less electricity. (updated to reflect this doesn’t enable deeper C-states as I thought it did.)
I didn’t post this before, and should have: Matthew Dillon posted a summary of all the trackpad improvements he added, and how to make use of the various features.
Markus Pfieffer has committed Larisa Grigore’s Google Summer of Code work, “SysV IPC in userspace”. It’s been a bit since the event finished, but it’s in DragonFly now.
If you want to track the bleeding edge of DragonFly, which is currently version 3.7, I happened to describe it in a reply to Filippo Moretti, on users@. Long-time users will know this/do this already, but it’s worth repeating just because new users may not realize how easy it is.
Things are picking up again after the break.
- Faces of FreeBSD: Isabell Long. Note that she came in via Google Code-In. That’s the value of those programs.
- OpenBSD: Randomness, sooner.
- OpenBSD’s change to PIE for i386 means special upgrade procedures – if you’re on i386. Also, here’s PIE. atexit(3) changes also changes the upgrade method this one time for… all platforms? I’m not sure.
- The DiscoverBSD roundup for 12/31/2013.
- The FreeBSD Test Suite. It’s similar to what NetBSD has, but see the source link for comments on what’s different. DragonFly has a test setup too, though I’ve never tried it – is there one for OpenBSD?
- Pkgsrc-2013Q4 is branched.
- FreeBSD has improved NFS performance.
- NetBSD has updated libpcap, tcpdump, wpa, bind, and dhcpcd.
- OpenBSD has updated xterm, glproto, and some other xenocara parts.
Here’s how my upgrade from DragonFly 3.4 to 3.6 for this server went.
The system install went normally. I rebooted before performing ‘make upgrade’, as noted in UPGRADING and elsewhere.
I already have dports installed, so a binary upgrade should be possible. I had heard of people with older version of pkg, having trouble getting it to notice upgrades. I rebuilt pkg, and ran ‘pkg upgrade’. A number of the updates coredumped. Here’s one example:
[156/160] Upgrading gtk2 from 2.24.19 to 2.24.19_2...Segmentation fault (core dumped)
After the upgrade, I had two problems: PHP wasn’t working for the website, and some programs would segfault.
The random segfault was fixable by forcing a binary upgrade of all packages. Since there were some programs on the system that were still new enough that the version number was the same as on the remote repository, pkg didn’t upgrade them. Those packages were linked against old versions of system libraries that predated the locale changes in DragonFly 3.6, so they’d crash. Forcing the update for all packages fixed the issue.
The other problem, PHP on the web server, is not new to me. The binary package for PHP does not include the module for Apache. The solution is to build from source with that option selected. I understand that pkg is destined to support (some?) port options in the future. There’s also an immediate workaround for locking it.
However, the port would not build because of a security issue. The binary package installed without any warning. This, I am told, will change to pkg giving you the option to install if you are aware of the security problem, and whether it really affects you. (which is just what I want, yay!)
Anyway, other than the system changes biting me because I didn’t realize some packages weren’t updated, it went very quickly. That is the reason for binary updates through pkg, or at least a major one.
ISA device support is really gone. Well, except for keyboard and some spots where it can’t be be removed. I don’t think I’ve even seen an ISA card in some years…
I had a sometimes-great, sometimes-difficult trip to New York City over the past few days, and while I was there, I met the ball of energy that is George Rosamond of NYCBUG (which is having a huge party right now.) He and I talked for a bit about various aspects of the BSD ecosystem, and one thing he noted was that people aren’t generally aware of all the licenses in use for the different software packages on the system, or even the individual licenses in the system files.
There is an ACCEPTABLE_LICENSES setting in pkgsrc, where software licensed under terms not in that list won’t install. That’s useful, but frustrating, because it keeps people from getting what they asked for – a software install. Something that would be useful – and it could be cross-BSD very easily – would be a license audit summary.
There’s meta-data on every package in FreeBSD’s ports and DragonFly’s dports and pkgsrc and OpenBSD’s port system. Why not say ‘pkg licenses’ in the same way you can say ‘pkg info’, and get a summary of the licenses you have installed in the system? (or pkg_licenses, etc. You get the idea) This wouldn’t prevent people from installing software, but it would give a very quick view of what you were using.
> pkg licenses
Software package License
foo-2.2.26 Apache license
It could be extended to the base system, but I’d like to see this in all the packaging systems as a common idea, in the same way that ‘info’ in a packaging command always shows what’s installed.
Rett Kent has volunteered for maintaining i386 support under dports. Good luck! 3rd-party software management is difficult.
This post from Konrad Neuwirth asking how to do a minimal installation of DragonFly led to this list of all the ‘knobs’ you can set to make your installation smaller, from John Marino. (And your buildworld faster, if that’s appealing to you.) I also pointed at rconfig and PFI, which are criminally underdocumented.
pkg 1.2 is coming out. This brings a number of new features, but as John Marino posted, you may want to delete your old pkg.conf to keep the new version from complaining about an old config file. This upgrade is a step on the way to signed packages, which is a Good Idea.
John Marino posted a possible ‘roadmap’ for DragonFly, now that we’re past the 3.6 release. The thread went on for some ways as it was discussed, including my crazy ideas. Notably, several suggested items have already been tackled – an iwn(4) upgrade has already happened, and an update to bmake, based on John’s vendor branch update instructions.
This is a little old, but Matthew Dillon noted the status of his Hammer2 work a little while ago. Some highlights: he’s intending Hammer2 to be usable on a single host by the time of the next DragonFly release (summer 2014), the Summer of Code project for compression has already been integrated, and he listed different parts of the work that may be interesting for anyone wanting to chip in.
Slightly related: Matt posted some Hammer2 comments on the DragonFly 3.6 release story on Slashdot that may be interesting. Don’t bother reading the other comments; they’ll make your eyeballs bleed.
If you’re planning to run DragonFly in KVM, remember this post from Matthew Dillon, giving the settings he uses. This will save you a bit of time.
If you’re upgrading dports (and you probably are if you are going from DragonFly 3.4 to 3.6), there’s a minor issue in dports, inherited from FreeBSD ports: you need to manually remove perl before upgrading. It’s all of one command, so it’s not a huge burden. Joris Giovanngeli spotted it first.
Eitan Adler is the newest DragonFly committer; you may recognize his name from some previous commits added by others, where he synced up various work between the BSDs.
For those updating from 3.4 to 3.6: there’s an ABI change, so you will have to upgrade all your packages. If you’re using pkgsrc and ready to switch to dports, now’s the time. If you already switched to dports on your 3.4 system, binary packages for 3.6 have already been built and you can use pkg to upgrade.
Also for upgrades from 3.4: You can pull the 3.6 source normally:
git fetch origin
git branch DragonFly_RELEASE_3_6 origin/DragonFly_RELEASE_3_6
git checkout DragonFly_RELEASE_3_6
But there’s a slight change needed for the 3.4 to 3.6 transition: an extra reboot in the build process:
# make buildworld && make buildkernel && make installkernel && make installworld && reboot
# make upgrade
This is all noted in /usr/src/UPDATING and in the release notes, but I’m taking no chances.
As noted on the kernel@ list, it’s tagged but not yet in image form.
John Marino isn’t interested in supporting the i386 architeecture for DragonFly and dports, so he’s not going to actively work on it. (Packages for DragonFly 3.6 are already built, so that’s not a problem for release.) If you feel like taking on a significant but interesting workload, check his message about the work involved.
BSDNow episode 11 is up, with conversations about OpenSSH, FUSE, building an OpenBSD router, etc… and a whole hour of me talking about the upcoming DragonFly 3.6 release and this very Digest, too!
I just finished a whole hour of gabbing on about DragonFly and BSD work in general for BSDNow. Because I am a ninny, I didn’t post something here earlier today so that people would know to watch the livestream. Sorry! However, it should be showing up in the next day or so on the BSDNow site. When it does, I’ll link it.
Not sure why, but there wasn’t a lot of things this week to pick out.
- A short discussion of Perfect Forward Secrecy on pkgsrc-users.
- PC-BSD apparently (used to) play a movie on first boot.
- FreeBSD now has a ‘mini-memstick‘ install option. (a later messages says ~200M in size.)
- FreeBSD has updated aacraid.
- OpenBSD supports the RTS5229 card reader in rtsx(4).
- OpenBSD has updated OpenSSH, and NetBSD has updated. (DragonFly has a fix for the underlying problem.)
- OpenBSD has FUSE support.
Matthew Dillon did some more performance tuning for DragonFly. I’ll just pull a paragraph from the commit message, since that will have more impact than anything I say:
Improves fork/exec concurrency on monster of static binaries from 14200/sec to 55000/sec+. For dynamic binaries improve from around 2500/sec to 9000/sec or so (48 cores fork/exec’ing different dynamic binaries). For the same dynamic binary it’s more around 5000/sec or so.
“monster” is a 48-core machine used for testing.
The venerable (from 1979!) program, lpr, has been superseded by CUPS in many installations. Francois Tigeot suggested removing it, but it’s still directly usable in specific situations and easier to just shift out of the way. It’s staying, but it’s interesting to see how it still gets used.
Update: Predrag Punosevac has descriptions of the various tools involved.
I’m planning to branch DragonFly 3.6 this weekend. The actual release will come 2 weeks later. (Ignore what I wrote about a dports installer/image.)
Matthew Dillon wrote a roundup post summarizing all the changes he’s made to DragonFly to improve SMP performance in the last few weeks. He’s removed almost all contention from DragonFly. This means better performance, scaling upward depending on the number of processors.
‘monster’, the system that builds all 20,000 items in dports, can complete the run in 15 hours. Compare this to the 2 weeks it used to take me to build the 12,000 packages in pkgsrc. This is admittedly on different hardware and different packaging systems, but it gives a sense of the scale of the improvement.
The ‘poweroff’ command, the equivalent of ‘halt -p’, has been added based on a suggestion from Robin Hahling.