Hubert Feyrer wrote a review of Ansible 0.9, a management tool for multiple systems, similar to Puppet or maybe Chef. Just after doing that, Ansible 1.0 came out, with support for pkgsrc via pkgin-installed packages. This is the first solution (that I know of) that supports pkgsrc package management for multiple systems.
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.
If you’ve been feeling the need for reading about filesystems, Daniel Phillips has posted more notes about his Tux3 filesystem design, which can be contrasted with HAMMER. (thanks, Venkatesh Srinivas)
I meant to post this a while ago; it’s a few days old but still useful. John Marino gave some stats on DPorts progress, plus he and Francois Tigeot also had some tips on xorg setup. The successful build count is higher by now, and I think KDE3 is done, though I haven’t tried it.
If you have a BSD Certification, and it’s nearing the end of its 5-year term, the BSD Certification Group has published the guidelines for re-certification. Has it really been 5 years since the first certifications happened? Geez.
I found this off of the NYCBUG mailing list, so hat tip to them.
It’s a very short week this week. I was on the road for work, so I didn’t see anywhere as much of the Internet as I may have liked. Count my dports writeup yesterday as part of this and it averages out to a good amount of reading.
- Favorite Linux Commands. Not all of them are Linux/bash specific. (via)
- Advanced Vim Registers. Or buffers, or clipboards, if you want to get messy with terms. (via)
- “I hate BSD so much!”, he yelled at his spittle-flecked monitor.
- TOME, a roguelike. Read through the comments for discussion of many other roguelike games.
Your unrelated link of the week: New Tokyo Ondo. via Jesse Moynihan, whose Forming comic on that site is an epic read. Epic, as in it’s actually telling a NSFW world creation story.
John Marino’s DPorts project, mentioned here briefly before, is interesting. I had two separate people ask me how it works, so a better explanation is in order. I’ve tried it out on a test machine over the past few weeks.
Background:
Dports is an effort to use FreeBSD’s ports system as a base for DragonFly, and the pkg tool as a way to manage binary packages built from DPorts. This is complicated, so I’ll explain each part in order.
- FreeBSD ports are a FreeBSD-specific collection of software installation files that automate building 3rd-party software on FreeBSD. You’ve probably already heard of them. (Note there’s no mention of DragonFly.)
- DPorts is a collection of files that map to existing FreeBSD ports, and contain any changes necessary to make that port also build on DragonFly. Many of those programs build without changes on DragonFly. DPorts builds from source.
- pkg is used for package management, and is usable on FreeBSD and on DragonFly. The binary packages produced from building with DPorts can be installed from remote locations and managed separately using pkg, so that software upgrades and installation can be performed with binaries only. (It’s much faster that way.)
Every port seen in DPorts is known to build on DragonFly. John Marino adds a port only after it builds successfully, using poudriere as a bulk software tool. Ports are only updated to a newer version when that newer version builds, too, so once something arrives in DPorts, it should never break from being updated at some point in the future.
Installing:
To use DPorts, you need two things:
- DragonFly 3.3 or later, though 3.3 is the most recent right now.
- You need to rename /usr/pkg so that your existing pkgsrc binary programs don’t get accidentally used while working with DPorts, causing confusion. If anything goes wrong with DPorts when you are installing it and you want to go back, remove all the DPorts packages and rename /usr/pkg back to normal.
(Don’t confuse pkg, the management tool, with /usr/pkg, the normal installation directory for pkgsrc. ) For the installation of the base port files:
cd /usr make dports-create-shallow
If you’ve already renamed your /usr/pkg directory, git won’t be in your path any more. You can instead download a tarball and unpack it, which also happens to be possible automatically via that same Makefile.
cd /usr make dports-download
Downloading via git is fastest, so if you do need to use the tarball via make dports-download, build devel/git, delete /usr/dports, and then pull it again with make dports-create-shallow. This all comes from John Marino’s Github site for DPorts.
Managing DPorts
DPorts doesn’t use pkg_info, pkg_add, and the other tools traditionally seen on DragonFly for pkgsrc. Instead, package management is done with pkg. Use pkg info, pkg install, pkg remove, and pkg update to list, install, delete, and upgrade various packages on your system. Packages built from source or downloaded as prebuilt binaries are managed the same way, using these tools.
See some of the other writing about pkg for FreeBSD for details on how it works.
Since DPorts doesn’t update a package until it gets a successful build, and installations are of successfully built binary packages, upgrades with prebuilt packages should always succeed. Since they’re binary, they should be fast. There’s a lot of ‘shoulds’ in this sentence, but these are reasonable suppositions.
What about pkgsrc?
Pkgsrc and DPorts shouldn’t be used at the same time, since one system’s packages may be at different versions but still get picked up during building for the other system. That’s about it for restrictions.
I intend to try building an experimental release of DragonFly with DPorts, to see if all the right packages can be added, but no guarantees. DPorts is brand new and does not yet have a repository for downloading packages, so the normal caveats apply; don’t install it on a mission-critical machine, and be ready to deal with any surprises from using it if you do try it out.
What packages are available?
Browsing the Github repo will show you all listed packages. More complex packages like xorg, openjdk7, and libreoffice install, as does xfce. Parts of KDE 3 and KDE 4 are in there. (I haven’t tried either.) I’m not sure about Gnome, but I don’t think anyone ever is. There’s no vim, but there is emacs.
That’s just what I see at this exact minute. It changes daily as more packages are built. Changes from DragonFly builds are sometimes relevant to the original FreeBSD port, so there’s benefits for everyone here.
What next?
Try it now if it has all the packages you need, or wait for a binary repository to be created to speed things up. Remember, this is a new project, so a willingness to deal with problems and contribute to fixes is necessary.
It’s actually been out since the start of January, but the release announcement is available now.
Stéphane Russell, on the users@ mailing list, pointed out an in-depth article about DragonFly’s 3.2 release, on linuxfr.org. It’s in French, which means I’m just going to have to trust his word about the contents.
Ishan Thilina asked for some project ideas, and Samuel Greear gave a list of links that may be useful for anyone looking for a project of their own. I offered strategy. It didn’t work out, but this information’s still useful.
The Open Graphics Project, which is building a completely open video card, needs a wiki maintainer. It’s a volunteer effort. If you were perhaps thinking you wanted to step up to a more complex project but didn’t want to just be writing code, here is a perfect opportunity.
(Not too different from maintaining a project work blog, after all, and I know that’s rewarding.)
There’s a short thread running on the DragonFly users@ list about disk encryption; there’s some descriptions of encryption work there for the curious.
I could have sworn I noted it before, but as Venkatesh Srinivas points out, there’s a port of cpdup to Linux. Also, if you’re using cpdup to copy material out of a Hammer volume’s history, use the -VV switch.
DragonFly 3.2.2 has been tagged. The tag commit has a list of the fixes; this is a bugfix release, but it’s a good one. Download an ISO (they should be at the mirrors by now) or update your system.
There’s been a large number of fixes and improvements to DragonFly 3.2 lately, so I’m planning to roll DragonFly 3.2.2 this weekend so there’s an image with them all.
If you were thinking you wanted to try gcc 4.7 with pkgsrc, John Marino’s described the option you need to set. It only works in pkgsrc-master right now (because of changes John made), and not every package in pkgsrc will build.
The advantage is that it’s also possible, with the same syntax, to set pkgsrc to build with gcc 4.4. This means the default compiler in DragonFly can be changed to gcc 4.7 and pkgsrc packages that aren’t compatible can still be built.
Update: Check this minor change: ‘?=’ instead of ‘=’.
Whomever submitted this story to Slashdot really doesn’t like FreeBSD; they’re describing FreeBSD’s annual end-of-year fund drive as failed. The month-long drive is only about a week old and has already picked up donations at a faster rate than any previous year’s donation drive, but apparently the poster – and Slashdot’s editors – can’t be bothered to do math. While we’re on the topic, donate to the FreeBSD Foundation; they do good things.
(There’s DragonFly too, though we’re not as ambitious or officially 501(c)(3) non-profit.)
Matthew Dillon has written up another update on his progress with HAMMER2. (I need to be consistent in how I write that.) He has disks being exported and mounted on other systems, and adds an explanation of some of the issues around creating reliable multi-master setups. Before you get too excited, no, multi-master isn’t working yet, and this is not production ready.
There’s more benchmarks for DragonFly vs. other systems on Phoronix. It has the same problem as previous benchmarks; some of the benchmarks may have no connection to reality (what does the “Himeno Poisson Pressure Solver” actually test?), and almost every system has a different version of the gcc compiler. So it’s meaningless in terms of comparative or absolute performance. On the other hand, DragonFly doesn’t do badly.
You can also look at the comments to see someone absolutely freak out over the very existence of things that aren’t Linux. I’m not sure if it’s actually trolling, since the comments are so exactly wrong.
Shopping! This is the big holiday shopping weekend in the US, and I usually put together something here.
- Buy an SSD for someone who doesn’t have one – including you if that’s the case. There’s better and worse SSDs out there, but you’ll get a speed benefit no matter what, and other bonuses are possible.
- The Tea Bag Buddy, which also comes in a color-changing version. Because tea.
- My perennial Science! suggestions: ThinkGeek, American Science and Surplus, Ward’s Scientific, Carolina, and United Nuclear, The Bone Room, and Skulls Unlimited.
- The Best of BSD 2011 and Last Year in BSD Security, from the BSD Magazine publisher.
- For more BSD, there’s always the orgs themselves. FreeBSD, NetBSD, and OpenBSD – no DragonFly, though there ought to be. Also, ISC.
- For lists of gifts, there’s the Verge Gift Guide, which has some interesting offshoots.
- Another long list: The Comics Reporter’s Shopping List.
If you have suggestions, please comment!