I just went and tested the Linux 3.13.5 modern-xiafs module against Linux 3.14.2, and it built, loaded, and works just fine. The README has been updated to reflect that fact, but there’s nothing else to add; all previous warnings about xiafs before still stand, as said before.
Version 0.4.0 of goiardi, the chef server written in go, has been released.
From the CHANGELOG:
- Fix bug with pessimistic matching (https://github.com/ctdk/goiardi/issues/1)
- Add authentication, authorization as an option.
- Add SSL as an option.
- Fixed a few small bugs that turned up while working on authentication.
- Improved test coverage further, both with go tests and a forked chef-pedant (https://github.com/ctdk/chef-pedant)
- Updated and expanded documentation.
Full announcement here.
Update: This was quickly followed by a minor 0.4.1 goiardi release.
From this version’s CHANGELOG entry:
- Small documentation tweaks
- Fix bug with parsing config file options and rearrange setting some of those config struct items, fix typo in sample config file.
- Add disable-webui option for command line and config file to disable the chef webui rails app from connecting to goiardi.
Not a lot there, but since the work was done and it seemed like a good thing to do, I cut a new release. The 0.4.1 announcement is here.
Update: And once again in quick succession, version 0.4.2 came out. Fun fact: most of the work on that release came while I had the day off after getting a spinal tap and I was a little bored.
From the CHANGELOG:
- Perm tweak for nodes updating themselves.
- Small change with validating role descriptions when creating or updating from JSON.
- Fix issue with saving complicated indexed objects to disk where improperly flattened indexable objects were making the gob encoder puke all over itself when encoding the tries in the index docs.
- Fixed a possible regression with synchronizing cookbooks that did not show up in testing, but only in real use.
- An absolutely bonkers fix for listing cookbook files with webui. Webui wants all of the cookbook top level attributes sent over with a request to /cookbooks/<name>/<version>, but this is the exact opposite of the behavior chef-pedant wants, where empty definitions, attributes, etc. are not sent over. Knife also seems quite content with this, so the fix for now, since the two cases are mutually exclusionary, is to only send the empty hashes for those top level attributes with a GET if the request is coming from the webui. Bizarre, but it seems to be what’s necessary.
Full 0.4.2 announcement here.
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 Mach-O (update: I’m not sure how I horked that one up. I must have either been thinking of COFF for some reason, or read something else that claimed OS X used COFF, or I don’t even know what. Fixed, in any case.). 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.