These probably apply cross-BSD, but in this case, it’s DragonFly tips for printing with CUPS.
If you have a Core2 processor in a DragonFly system, it may not work with accelerated video. If that happens to you with this (admittedly old) processor, switch to VESA for now.
For those of you running DragonFly-current, the already-mentioned library privatization going on means that ports have to be rebuilt. You will want to do it yourself, or wait a little bit before upgrading if you want to install binaries.
BSDNow 126 has an interview with Ken Moore and Kris Moore of PC-BSD, along with the usual news roundup. There’s a DragonFly mention in the “open source work helps your career” news item that I did not know about but am happy to see.
That’s a pretty cryptic headline, isn’t it? John Marino has ‘privatized’ several libraries in DragonFly, so that they can’t get included involuntarily as part of a port build. That may mean you will need to perform a full rebuild of your system if you are tracking DragonFly-current.
(This is the way to fix ‘system’ languages like Perl was in FreeBSD 4.x – keep them clearly separate from the port version. It’s about a decade too late for that idea to work out, though.)
For those of you with i915 video on your DragonFly system, there’s another update bringing DragonFly support to match what’s in the Linux 4.1 kernel. ValleyView and Skylake processor owners will benefit, along with a slew of other bugfixes and improvements.
Are you using a i915 video chipset? Are you using the DisplayPort? Imre Vadasz has added a tunable that may make it work better.
Note: keep in mind this is a client bug – it’s an information leak when you as a client connect out to somewhere else. A server, as an endpoint, is not affected.
John Marino has opened up his new utility for testing: Synth. It’s made for building custom package repositories, similar to poudriere, but much less setup work. If you’ve ever said “I like binary installs, but I want my own build options”, this is for you. The README includes screenshots to show all the things it can do.
Francois Tigeot has updated DragonFly to match the video support found in the Linux 4.0 kernel. This will benefit you most if you are running Skylake, Cherryview, or Valleyview chipsets. Don’t ask me how to tell; the improvement has been so rapid I’ve lost track of which model codename is which.
There’s some DragonFly links I snuck in here because why not?
- OpenBSD Innovation List. (via)
- How to block traffic based off country – pFSense (via)
- pfSense 2.2.6 is released.
- Orchestrating multiple FreeBSDs?
- Hacking the PS4, part 3: FreeBSD Kernel exploitation. (via)
- PIC32-RetroBSD Open Source Hardware Board running Unix like RetroBSD OS. (via)
- Is there a way to cite the FreeBSD handbook and other documentation in APA format?
- Newbie testing out new OS’s
- OPNsense 15.7.23 Released
- [PSA] 1920×1080 on DragonFlyBSD 4.4 under QEMU/KVM.
- The DragonFly 4.4 release article on linuxfr.org – always in-depth.
- Faces of FreeBSD 2015: Erin Clark.
- n2k15: bluhm@ on MP networking (out from under biglock)
- n2k15: vgross@ on deep surgery in TCP/IP stack code
- n2k15: krw@ on fdisk, installboot, dhclient, GPT fixes
- n2k15: reyk@ on hosting a hackathon, vmd, and the switch
- n2k15: mpi@ on MP networking progress
- n2k15: stsp@ on 11n mode wifi, testing
- OpenBSD’s sndiod: now with privsep
- Problems with Systemd and Why I Like BSD Init. (via)
- DiscoverBSD for 2015/12/21.
- AsiaBSDCon 2016 is happening March 10-13, 2016, in Tokyo. The call for papers is out and due by January 8th. Tutorial proposals are due at the end of the month.
A number of people have reported problems with qemu and DragonFly, both running locally and on a host. It turns out to be a problem with the getcontext(), setcontext(), and swapcontext() functions, but Matthew Dillon fixed it in a way that doesn’t affect performance very much.
That apparently wasn’t good enough, so he added _quick versions of those same functions, so it became not just a fix, but an improvement.
In related qemu news: qemu-devel can use vknetd similar to a vkernel, now.
For those of you that are very bandwidth-constrained, or just impatient, there are xz-compressed images of DragonFly 4.4 available. (see ‘download live image’ area) The mirrors should have them too.
The DragonFly installer has been modified to produce disk arrangements that will generally match between UFS and Hammer installs, plus directories where you usually don’t want Hammer history or backups (like /tmp or /usr/obj) are now under /build and null-mounted to where you’d expect, since null-mounting works transparently well on DragonFly. Matthew Dillon has a note explaining the whole thing.
For those of you looking to rent a place to run DragonFly, Nuno Antunes has very helpfully written out his procedure for installing DragonFly on a Digital Ocean ‘droplet’.
As mentioned previously, Sepherosa Ziehau is printing up some DragonFly T-shirts for WeChat users. He’s going to have a few left over, so he is sending them to me to hand to non-China people. If you want one, leave a note saying so in the comments. Here’s the front and back.
You need to provide some way for me to contact you – preferably email, and the size you’d want. (Use the Land’s End Men’s Shirts chart for sizing, because why not.) I’ll only have a few, so no guarantees.
Update: I have more responses than probable shirts at this point – sorry! I’ll get in contact with each of you once the shirts come in and arrange delivery.
Hammer now defaults to ‘noatime’, meaning the date and time of last access are not updated on every file action. Note that creation and modification date and time are still recorded. This will help with speed and disk activity.
This may cause a problem with any software expecting this to change – mutt, possibly? We will find out. This change was done after the 4.4 branch, so it’s not in the current release of DragonFly.
If you are a WeChat user and want a DragonFly BSD shirt, send your Chinese address and mobile number to firstname.lastname@example.org, or scan this image to join the WeChat DragonFly BSD group.
This is exclusive to China right now, as it’s being done by DragonFly developer Sepherosa Ziehau – who, as you might guess by now, is based in China.
John Marino has created two custom make variables – .MAKE.DF.OSREL and .MAKE.DF.VERSION. (They return the current DragonFly versioning, if you can’t tell from the name.) Apparently, if you build all 22,000 or so ports together, about 15% of the total time is just awk looking up the system version, and this removes that repeated task.
Matthew Dillon has added two Hammer2 directives – ‘info’ and ‘mountall’. See his commit message for a explanation of each. This predates the 4.4 branch, so it’s available in the current release. The usual caveat applies: Hammer2 is for development only; don’t use this to store data you want to use.
I am taking this moment away from my significant backlog of things to post to note that there have been a lot of games fixes in DPorts lately. Thanks to Rimvydas, many small bugs that kept games from compiling on DragonFly are now fixed. The easiest way to see is to look at the commits from December 8th and back, but the best way is to pick one and play.
Sharp-eyed users will note that release is happening with version 4.4.1, rather than the 4.4.0 you’d expect. That’s because I tagged 4.4.0, built the images, and then OpenSSL 1.0.1q was released. Rather than make everyone who installs DragonFly need to immediately update, Sascha Wildner brought in the OpenSSL update to the 4.4 branch, and I built 4.4.1 instead.
I’m combining two items because news happens faster than I can post: Tomohiro Kusumi has added a ‘dm-flakey’ target to the disk mapper, so you can simulate an unreliable disk, reliably.
DragonFly has historically performed very well with NFS. I don’t have hard numbers to point at (an interesting exercise if someone wanted it), but in any case: DragonFly now can tune up to a much larger iosize, which means better NFS performance. DragonFly <-> DragonFly NFS performance can now max out a GigE link, or with anything else that can handle the larger iosize. That plus additional readahead, also in that commit, means easier netboots.
I have a huge backlog of things to post, so this is originating from the 17th: Matthew Dillon has been working for some time on hardlinks and Hammer 2. Hardlinks are the same file, presented in multiple places. This can be a problem when your filesystem keeps infinite, writable snapshots. The solution he just commited is called ‘xlink’ and the commit message has details.
Since DragonFly 4.4 has been branched, bleeding-edge DragonFly is now at version 4.5. As John Marino detailed in his post, that means pkg on 4.5 systems will look in a new place for downloads. (“dragonfly:4.6:x86:64”, since it always uses even numbers)
To cover for this, set ABI to point at DragonFly 4.4 packages in pkg.conf for now. They’re freshly built and functionally the same, anyway. Once there’s a 4.6 download path, that ABI setting can be removed. Packages for DragonFly-current are available now and probably at the mirrors by the time this posts.
Update: as John Marino pointed out to me, anyone on DragonFly-master who upgrades now will be at version 4.5. This means pkg will get the new (4.5) packages on the next pkg upgrade. That means a mix of old and new packages unless you either reinstall anything (pkg update -f) or hardcode the 4.4 download path until you are ready to switch everything.
So: DragonFly-current users should either hardcode the 4.4 path for now or force an pkg upgrade for everything. DragonFly 4.2-release users are unaffected.
Did you need to use SLIP on DragonFly? Do you remember what SLIP is? Well, it’ll work with a USB modem on DragonFly, even if you are making a face right now and saying, “SLIP? Who uses that?”
The default linker in DragonFly has been switched to gold, the newer version of ld. (get it, go-ld?) It’s faster, cleaner, going by the commit message. It’s possible to switch back to the old one if needed. This predates the recent branch for 4.4, so it will be default in the release, too.
Imre Vadász fixed top so that hitting ‘c’ filters displayed processes by command name. I am mentioning this not because it’s a huge change, but because I forget about all the interactive elements that are possible with top.
Does that count as alliteration? Anyway, Matthew Dillon has increased the size of the starting window in TCP. If you are on a higher-latency link and/or fetching lots of small files, you should notice better performance.
I don’t think I linked to this anywhere else: Why did I choose the DragonFlyBSD Operating System? By Siju George, at BSD Magazine.
John Marino sent a helpful link to show the cross-platform work he’s been involved in: He brought the locale work from Illumos into DragonFly over the summer (look for his name on commits), and now it has been brought from DragonFly into FreeBSD, with Baptiste Daroussin reporting on the process. If there’s any OpenBSD/NetBSD developers reading, with an interest in locales, this may be useful..
(someone correct me if that’s not the right Illumos link)
If you are using bleeding-edge DragonFly (4.3) on a machine with Intel video, the i915 module has been renamed. This means you will probably need to rebuild xf86-video-intel from source to have it match. There should be a matching binary package soon.
If you are on DragonFly 4.2, this does not affect you.
Sascha Wildner has brought over support for the Realtek 8168H. This may be useful because at least one low-cost server provider – Kimsufi, I think? – uses them by default in their product line.
Via EFNet #dragonflybsd, “Booting DragonFlyBSD with Hammer on a GPT drive“.
For those of you with DragonFly and an Intel i915 chipset, Francois Tigeot has moved support up another notch, to match Linux 3.18. This will help Cherryview and Broadwell chipset users the most.
I think at this point, Sepherosa Ziehau is able to improve the DragonFly network stack by just standing near his computer and concentrating for a few minutes. For example, he’s unearthed another improvement to connect rate/reduction of CPU usage.
There’s a new version of the Intel video driver in dports – xf86-video-intel-2.99.2015.09.09. If you update to this and you experience an xorg-server crash, Matthew Dillon found that changing the acceleration method from SNA to XAA fixes the problem. Don’t change it unless you actually see the problem, of course.
The package x11-themes/dragonfly-wallpapers exists, thanks to John Marino, and gives you DragonFly-themed backgrounds in KDE. Or probably any other window manager, if you install it and point your wm at the directory.
Update: John Marino helpfully posted a link to the images. It’s not yet built as a binary, but it’s not exactly time-consuming to build from source.
MIDI support has been (re) added in DragonFly, if I read this recent commit correctly. You may have supported hardware and not even realize it.
If you happen to still be running DragonFly 4.0 – that’s two releases ago and not supported – you may be noticing less ports are building. There’s been enough significant changes in DragonFly since that release that it’s reducing the number of buildable ports.
DragonFly 4.0 to 4.2 is not a difficult jump, so jump when you can. The converse of this, of course, is that there’s even more building on 4.2 and DragonFly-current.
John Marino is working on versioning libc, and as part of that process, libc is no longer loaded into executable memory. Here is I think an explanation of lib versioning that may apply, and of course moving things that aren’t supposed to execute, out of executable memory areas, is good for security. There’s more on that topic, too – W^X may be a similar example.
This is a complicated topic that I’m not part of, so suggest better descriptions in the comments, please.
HAMMER2 recently gained the ability to be used as the root mount for your DragonFly system. Live deduplication of data is also now possible, which means fast copy operations, less space used, and no need to wait for an overnight batch process to do it. If you want to try it, you need a bleeding edge DragonFly system and the WANT_HAMMER2 option. It’s still not ready for production use, so don’t try it with any data you want to keep.
Francois Tigeot has stepped i915 support in DragonFly even farther, this time bringing it to match Linux 3.17. This may be most useful for those with Broadwell and Cherryview chipsets.
I don’t note it enough, but Tomohiro Kusumi has been making constant updates to HAMMER, the version we have now. Often they are the sort of update that makes the code more readable, or fixes possible problems, and so on. Very essential, but hard to post about it. In any case, I’m using his recent improvements to hammer volume-del to note his contributions, of which there are much more than the day’s worth I link here.
Matthew Dillon posted an extended description of how to run Firefox in a way that completely locks it away from your user account. As a side effect of this, the current crop of dports binaries has been updated.
Most of the news is about Intel video support, but Radeon direct rending improvements are coming too. ‘zrj’ have brought up drm/radeon support to match what is in Linux 3.12. Worth trying if you’ve had problems with your Radeon and audio, going by what I’ve seen people report in IRC.