Once again, the new version 3.13 series of the Linux kernel has required an update to modern-xiafs. This particular update was quite small, although not quite as small as the update for 3.12.1. There’s not a lot more to add; all the previous warnings and statements about xiafs from before still stand.
I recently had to replace my main workstation because of a graphics card dying. It wasn’t all that big of a deal, thanks to the magic of regular backups and whatnot, but I found a very strange problem where when I tried to use
knife to do any chef work that required editing anything in knife, I got the message:
ERROR: RuntimeError: Please set EDITOR environment variable
This was odd, since EDITOR was in fact set.
Turns out the solution is simple: I had installed MacVim with homebrew and set up my usual .vimrc stuff. I had
EDITOR=vi in my .bashrc, but the vi in my path was the default OS X
/usr/bin/vi. Unfortunately my .vimrc makes the default OS X vi gripe a little, and it exits with an exit status of 1. It still works fine, but that’s enough to make knife think that it failed miserably and it spits out the misleading message about the EDITOR variable above. To fix this, either fix the error in your .vimrc or make a symlink of
/usr/local/bin/mvim. After that everything should be good.
NB: This situation probably applies to configurations for other editors as well, but I haven’t tested that at all. Still, if you have an emacs config that works and edits files fine but exits with a non-zero status, I imagine knife would be unhappy about that as well. I have no suggestions on how to fix emacs though.
Update: It was pointed out to me that you can also set
knife[:editor] explicity in knife.rb:
That’s in the docs, of course (although I’ve never had much good luck with using the gui vim with knife; YMMV), and I tried setting
knife[:editor] = "/usr/bin/vi". Still, it took me a while to figure out what the error about the EDITOR not being set even meant here and what was causing it. It wasn’t obvious at first that the problem was with one particular vi interacting with the .vimrc. However, explicitly setting
knife[:editor] to the right editor you want with the full path would fix it too.
While I’ve had some of those sharing type buttons on this site ever since I moved it over to Octopress a while back, I’ve never been real keen on them. In fact, I never actually use them anywhere and don’t really like them, so in order to do my part to improve the Internet I’m taking them off. As an added bonus, posts should load slightly faster too. If you feel inclined to share something from here, suck it up and copy n’ paste the URL like a normal person would.
Ah, feels good. I did find it a little amusing to have Twitter, G+, and ADN share buttons, but no Facebook “Like” button, but it’s not all that funny, and I don’t think anyone noticed anyway.
I’m pleased to reveal that I’ve completed an annotated version of the xiafs sources, to hopefully provide an understandable explanation of what’s going on inside a filesystem kernel module. It’s no Lion’s Book or anything, but I hope that it’s informative in its own way. If it sounds interesting, take a look.
Xv6, if you haven’t heard about it, is a reimplementation of Version 6 Unix in ANSI C for x86 processors for an operating systems class at MIT. When I first came across it a while back I wanted to play with it, but unfortunately it’s rather harder to get working under OS X because xv6 uses ELF for its executables while OS X uses COFF. You have to build a cross compiler to get xv6 building under OS X. Unfortunately that isn’t a very straightforward process, and I wasn’t real interested in devoting tons of time getting it to all work right. I had found instructions for getting xv6 to build on OS X using MacPorts (and other instructions too), but never had any luck with the assembler actually building anything.
The other day, though, I bumped into xv6 again and decided to take a look once more. Someone out there was trying to build xv6 with clang somehow, and it got me thinking about the cross compiler thing again. Googling a little, I saw that someone made just the homebrew formulas for the cross compilers that I needed, so I downloaded those, put them in with my homebrew formulas, and ran
brew install i386-elf-gcc and
brew install i386-elf-gdb. I had already installed qemu and the prerequisites mentioned on that gist about trying to build xv6 with clang, so after making some little changes to the Makefile (seen here, between lines 32 and 78) xv6 finally built and started up for me.
Of course, xv6 doesn’t actually do much. I’ve been dinking around with it some though (because obviously what I need is another project), adding some simple utilities and whatnot, that I’ve tossed up on github. So far all I’ve done is add some simple versions of basic utilities, but I’m exploring. Even if it doesn’t do much, it’s pretty interesting.
Version 0.3.0 of goiardi adds the ability to save the in-memory data store and the search index to disk, rather than losing everything everytime the server restarts. If the options are set, goiardi will save when it receives a SIGTERM or SIGINT signal, as well as save in the background periodically. The interval defaults to five minutes, but can be specified as an option as well. In the interest of safety and data integrity, goiardi will first save to a temporary file before renaming it to the save file name.
Of course, goiardi will also still happily run entirely in memory as before.
NB: Bear in mind that even if the data has been saved to disk goiardi still keeps the data store and search index in memory while it’s running. This could cause problems if you try to shove too much data into it. I expect most use cases would have no problems (famous last words), but the appropriate caution is warranted.
It still does no authentication or permission checking, and while it does its best to avoid data corruption and data loss it is not a real database and should not be relied on as such. It may be useful for situations where you do not want or need a full real Chef server, but could use persistent data which you don’t get with chef-zero.
Next tasks coming up: provide a way to reindex the data, improve existing docs as needed and write more, make actual go tests, fork chef-pedant and make a “goiardi” mode to simplify testing against chef-pedant.
Anyway, that’s what this release has. Have fun with it if you’re so inclined, and thank you if you do.
A while back, I decided that I would like to learn Go, which is a pretty neat language all around (in my humble opinion). I had to come up with some sort of project that would be ambitious enough to teach myself a lot of the language features, but not so huge that I’d give up in frustration. Then I thought of a name, and realized what I had to do.
After many evenings spent coding, I’m proud to announce the first offical release of Goiardi, an in-memory Chef server written in Go (the README has more information). (I started on it before I found out about Chef-Zero, but I decided to keep at it anyway. Chef-Zero was also a huge help in figuring out what the Chef server behavior ought to be.) At this time it has pretty much all the features Chef-Zero does, but sorting searches isn’t working yet. If anyone has real examples of how those sorts are specified, I’d love to hear them.
Goiardi does not support authenication or validation at all, so it isn’t very secure. Of course, it also doesn’t persist its contents, so you probably shouldn’t rely on it for your infrastructure provisioning needs.
Aside from the authentication and permission tests, goiardi performs pretty well against chef-pedant. There are a few minor tests that fail because of slight JSON formatting differences or error messages that don’t agree with chef-pedant, but otherwise it does quite well. Improving its performance against chef-pedant is, of course, an ongoing concern. It should do fine as a stand-in for chef-zero though, or some other situation where you need a chef server running but don’t care if it loses all its information when it quits.
Goiardi is, like many Chef things, open source and licensed under version 2.0 of the Apache License.
Where to go from here? Goiardi certainly has a lot of room for improvement. The first things I intend to do with it are allowing you to use a config file to store options, and allowing freezing the in-memory data structures to disk so they persist when goiardi is shut down. Those aren’t in this release because if I kept adding “just one more thing” before making a formal release, I’d never actually get it out.
Further in the future, handling real authenication and permissions is pretty important. A real Chef Server mode, where goiardi uses Solr and a real database, is on the roadmap down the road as well. SSL, better documentation, and making the Go code more idiomatic where needed are also on the TODO list.
Anyway, there is is. Feel free to check it out, bang on it, see where it breaks (and where it works). Suggestions, code, and comments are always welcome. Hopefully the comments are nice, but this is the Internet.
Update: At least part of the future is now. Goiardi has config file support now with 0.2.1, huzzah! This release also fixes a problem building goiardi with more recent versions of go-flags.
Goiardi has been tested to compile with the native go compiler and run on Mac OS X (10.7 and 10.8), Debian ‘wheezy’, and Arch Linux. It also builds and runs with gccgo (using the
-compiler gccgo option to
go), tested on Arch Linux. Efforts are ongoing to get it to build with gccgo without the
go command on OmniOS, but so far they’ve been unsuccessful.
If you’re wondering about the name, Ettore Boiardi was the real Chef Boyardee. Wakka wakka.
Last year I started working on observing the Herschel 400 (and cataloged my results for 2012 back in October). While for a variety of reasons 2013 wasn’t the best year for amateur astronomy for me, I was still able to get some observing time in and added some more objects to my Herschel 400 tally. How did I do in 2013?
- NGC 752
- NGC 1245
- NGC 2548 (Messier 48)
- NGC 3007
- NGC 3034 (Messier 82)
- NGC 3607
- NGC 3608
- NGC 4216
- NGC 4251
- NGC 4261
- NGC 4273
- NGC 4274
- NGC 4281
- NGC 4303 (Messier 61)
- NGC 4631
- NGC 4656
- NGC 5273
- NGC 5557
- NGC 5866
- NGC 5907
- NGC 6207
- NGC 6229
- NGC 6633
- NGC 6755
- NGC 6781
- NGC 6826
- NGC 6882
- NGC 6885
- NGC 6934
- NGC 7000
- NGC 7006
- NGC 7008
- NGC 7009
- NGC 7062
- NGC 7160
- NGC 7217
- NGC 7296
- NGC 7331
- NGC 7790
After removing some duplicates, I have 39 new Herschel 400 objects observed in 2013. Combined with the 38 before, I currently have 77 in total, for 19.25% of the entire list. As mentioned previously, many of the Herschel 400 objects are quite difficult in the city and I didn’t get many opportunities in 2013 to travel to dark sites. At home, while I was able to snag a few galaxies from the list, a lot of my time was spent looking for planetary nebulae (which are pretty cool) and open clusters (which are probably my least favorite astronomical object). Here’s hoping 2014 ends up being more productive.
Also, if you have SkySafari, there’s a SkySafari observing list for the Herschel 400 if you’d like to go through the list as well. This saves you the effort of looking through a list in a book or on Wikipedia yourself or creating the list from scratch yourself.
There’s a new 2.19.3 update for bsdgames-osx this holiday season. The previous update that fixed mille compilation errors with more recent versions of clang accidentally clobbered a variable that was supposed to be a bool that was really a tristate variable. Ooops. An astute commenter brought the issue to my attention, and last night I finally got around to fixing it. Now you can happily play mille to your heart’s content (and it’s surprisingly fun).
Once again, there is an updated homebrew formula for bsdgames-osx.
The modern-xiafs module, a delightfully useless thing that allows modern Linux kernels to mount and use the ancient xiafs filesystem, has been updated to work with Linux 3.12.1. This was the smallest update yet (one function in inlude/linux/mm.h had been changed). Nothing else of note is in this update, and previous warnings not to use it in production (which would be pretty stupid, seeing as it has those max 2GB volume/64MB file size limitations) and that it could conceivably set your computer on fire or run off with your cookware/checkbook/long term companion remain in effect.