Domain registrar recommendations?
In a couple of months, one of my domains is up for renewal. I've been using Dotster for years now, ever since I ran screaming from Verisign nee Network Solutions back in the day, but my eye is wandering.
Mainly because Dotster does not, nor does it have any plans to, support DNSSEC and IPv6 glue records.
If this goes well, then I'll be moving the rest over as they eventually expire.
Sunday Hackery
Faced with no getting-my-hands-dirty offline projects today, I decided to spend some time on various F/OSS projects that I've neglected as of late.
The morning started with a flurry CW1200 driver hacking; this time focusing on simplifying its interrupt handling. In the process I eliminated two more compile options and three bus-level virtual functions. As nice as it is to write code, it's even nicer when you delete it without any loss of functionality!
After that, I put my money where my mough was and wrote a systemd unit file for Photo Organizer's background workers. For years I've been using screen and a sudo-driven cmdline to fire them off, because I could never come up with a reliable (and portable) init script to do the trick. No longer. As an aside, systemd is brilliantly put together and worlds beyond anything that's come before. It JustWorks(tm).
Then I pulled out my notes and turned my attention to Gutenprint. The Kodak 1400's unexpected complications derailed my plans a bit, but there were still three related printers whose spool formats I'd decoded -- The Kodak 8500, the Mitsubishi CP3020D/DU/DE, and the Mitsubishi CP3020DA/DAE. They are now all supported by Gutenprint, and awaiting testing. The latter two are the ones I'm most concerned with, as I took a few liberties with the spool format.
Basically, the Mitsubishi-branded printers don't spool the data linearly into the printer; they basically write the color-interleaved data in backward chunks. Consequently, the printer can't start printing until all the data is received. To simplify things, I'm sending the data linearly in one big chunk. Hopefully it will work. We'll find out.
On that note, if there's someone out there with one or more of these printers, care to help out? Either by doing some test prints for me, or better yet, sending me the printers? :)
... and the day is far from over.
Okay... this is certainly strange..
Date: Tue, 22 Jan 2013 20:49:36 -0500
From: Jay Ronkonkoma
To: undisclosed-recipients: ;
Subject: Thank You for your hard work
I'm a big fan of your work on Wireshark. I was wondering what else you had
going on, what you were doing that was new, anything I could read would
be greatly appreciated.
Also, if you have the time and inclination. please mail a postcard to my
daughter Amanda. She would love to get a little post card from you. she
is now 7 going on 15 if you know what I mean.
I would appreciate it, and I know she would love it. If you don't I
appreciate your time
Amanda Elia
[[ address snipped ]]
Ronkonkoma, NY 11779
Humbly,
Jay Elia
I can't help but think this a soliticitation for highly illegal
activities, if you know what I mean.
It's also been something like six years since my last contribution to
Wireshark, so it would seem someone's busy harvesting addresses from
old commit logs or somesuch.
EDIT: I've reported this email to google via gmail's abuse form.
Going to pass this on to the feds too, once I figure out how to do that.
EDIT2: I've reported this to the feds.
EDIT3: Two others have told me they've received this too.
Success with the Kodak Professional 1400
About a week ago a massive box was left on my doorstep containing a lightly-used Kodak 1400 large-format dye-sublimation printer. Lightly used to the grand total of a whopping 72 prints, according to the self-test page.
Unfortunately, my elation turned sour when I discovered that I couldn't just dump the raw spool file to the printer. Firing up a USB sniffer under WinXP, I discovered that the to-the-printer protocol bore little resemblance to the spool file -- even the image data itself used a different format. To top it all off, the printer needed intelligent buffering.
So, armed with the USB sniffer output, I heavily modified the spooler I wrote for the Canon SELPHY printers. Last night, I achieved success, and succesfully printed the WinXP test page I'd previously generated, but also an image printed using gutenprint.
The Kodak 805 printer that replaced this one probably needs a similar treatment (given that it uses the same spool file format) but unless someone sends me a printer (or cash) I won't be able to test that theory out.
I still have to generate another couple of test prints under WinXP to decode two remaining protocol options, but other than that, the Kodak 1400 printer is now usable under Linux!
Oh, this is the first image I printed on this thing via Gutenprint. I wish I could say it was something I took.
More driver hackery
This morning, I submitted the third pass at the CW1200 WLAN driver to the linux-wireless list. The changelog is too long to list here, but the bulk of the changes were teased from a code dump that Sony released. It seems they went through much the same pain as I did, and of course none of the changes made it upstream.
Aside from the Sony changes, the single biggest change was a rebalancing of the tx/rx handling, so that it's now considerably fairer. Of course, there was the usual pile of small changes, including a fix for an OOPS triggered by the broken IBSS code. It's still broken, but at least it's not crashing anything now.
We'll see where v3 goes. Hopefully merged into linux-next, or barring that some meaningful feedback on what I need to do next.
In other news, Before the new year I added support to Gutenprint for the Kodak 9810 dyseub printer. None of the code's been committed yet, but there's no real rush. I'm now waiting on a Kodak 1400 printer to show up -- Once I've verified my core gutenprint changes are sound and that printer works, I'll commit everything, marking the untested models as experimental.
Then I'll tackle the Kodak 8500 and the Mitsubishi CP3020D/CP3020DA, not that I'll be able to test those either.. Afterwards, I'll see about the more modern Mitsubishi printers if I'm feeling so inclined.
I really need to start getting rid of this pile of Canon dyseub printers. Maybe four, instead of twelve. At least the incoming Kodak 1400 is a large-format model!
CSS hackery
One of the tasks I got up to during my recent "vacation" was the first real hacking on the code powering my photo site in more than a year. This time, the changes are mostly cosmetic in nature. I've been removing javascript/DOM hacks in favor of CSS3 to style the buttons, checkboxes/selections.
The result is far simpler markup and faster page loads because there's no javascript rewriting the page on the fly. In fact, the only javascript present now is the code that inverts the image selection, and even that's far simpler because it just walks the list of checkboxes and toggles them.
I'm also giving attention to the layout and especially element spacing; trying to generally improve the intangible "feel" of the site through subtle tweaks that make things much more visually pleasing.
The goal here is to clean out as much legacy cruft as possible, so I can more easily make more complex (but necessary) UI changes. There are still too many tables used for layout/formatting; I'll be trying to eliminate those next.
I'm back to working on this thing for my sake, solving my own needs, making it into something I want to keep on using, and I must say it's a nice change. Yay for (useful) productivity!
More reverse engineering goodness
I decided to make a sweep of it and decode the raw spool formats for the remaining "Professional" Kodak photo printers, the 8500 and 9810. This means that all of Kodak's professional dyesub printers will be supported, save for the long-since-discontinued ML-500.
But I digress. It turns out the 8500 is essentially a rebadged/tweaked Mitsubishi CP3020D, albeit without 8x12 support and a third variation of the Mitsubishi block-chunked image format -- packed BGR data, sent in one ginormous data block but wrapped in the "traditional' 3020D control blocks. That will require no changes to gutenprint to support, so I'll probably implement support for the 8500 before the CP3020D/DA models it's based on.
Meanwhile, The 9810 is very different from the other Kodak models. It uses a command-stream type of format that's on the verbose side but is otherwise well-structured, with the raw RGB data being sent in a plane-interleaved fashion. Supporting it will require no core changes either.
so, this is my plan of attack over the next couple of days:
Anyway. Time to go to bed.
Another two Kodak printers supported..
Just added support to Gutenprint for the Kodak 605 and 805 dyesub printers. They were mostly the same as the 6800 and 1400 (respectively) they replaced.
I've also reverse-engineered the raw dump formats of the Mitsubishi CP3020D and the CP3020DA 8x10 dyesub printers. They use a somewhat convoluted block-oriented format, with the former using CMY-based plane interleaving and the latter using RGB-based scanline interleaving. To add joy to the mix, the blocks are sent to the printer in reverse order (bottom-up), but within each block the scanlines are top-down.
Once the Kodak 1400/805/6800/6850/605 support is reviewed and committed into Gutenprint, I'll start working on the low-level changes necessary to support these Mitsubishi printers.
Maybe a grateful user will mail one of them to me in thanks? (hint hint)
And then there were two more
Just added support for Kodak 6800 and 6850 photo printers to Gutenprint. The main difference between them is that the 6850 is faster -- 8s (vs 11s) for a 4x6 print -- and natively supports 5x7 media.
There are many thousands of these printers deployed in self-serve photo kiosks, and they're trivial to find on ebay. Cost per 4x6 print is under $0.17 and media refills are very easy to obtain.
Meanwhile, the 6800/6850 has been superceded by the 605, and the 1400 has been superceded by the 805. If I'm still motivated I may try to add support for those models too..
Pre-Holiday Hackery
It's been a busy few days, and my vacation hasn't even started yet.
I accomplished two major tasks this weekend. First, I finally kicked off new attempt to mainline a Linux driver for the ST-E CW1100/CW1200 WLAN chipsets. The first post to linux-wireless went over fairly well, and the suggestions (many of which were already on the pending list) kicked off a flurry of updates culminating in a second revision posted later that day.
Those submissions have spawned a fair amount of commentary and some patches; I've spent most of the day so far incorporating a massive code drop from Sony, for example. That's undergoing some testing now, and I'm hoping other interested parties will step up and get some wider test coverage in so we can get this driver into the next Linux release cycle (3.9). I created a public git repo of my working tree, which will live on until the driver is accepted upstream:
git://git.shaftnet.org/compat-wireless-cw1200.git
I'm going to hold off on submitting a v3 patch until I get more feedback and testing, which means it probably won't happen until after the new year. Apparently most folks take it easy this time of year.
Thankfully, I've had another project to keep me busy. I've spent a fair amount of time working on the Gutenprint printer driver package too, fixing support for the Kiosk-scale Sony UPP-DR150 photo printer (~8 seconds for a 4x6 print!) and adding support for the larger-format (8x10/8x12) Kodak Professional 1400 printer. I don't own either printer; instead I reverse-engineeried the raw data generated by the printers' Win32 drivers.
Not bad for two and a half days' work, eh?
Meanwhile, there are now twelve Canon SELPHY photo printers on my desk. The entire line is supported except for the CP-790, CP-530, and CP-520 -- and then only because we don't know what their USB PIDs are. The only one with known problems is the positively-ancient CP10, which locks up after the first (successful!) print. All other models JustWork(tm) now. I should start getting rid of most of these.
If I find myself with more time on my hands I may try to add support to Gutenprint for another Dye Sublimation printer. Ideally it would be one still commercially available, not too expensive, and a larger format (eg 8x10) because I can put that to use. We shall see..
If I'm feeling particularly masochistic, I'll continue with my fumbling efforts to implement dock detection for Rockbox on the Sansa Fuze v2. I haven't made much headway on that gargantuan reverse-engineering effort; it's mainly an exercise in learning a new set of skills.
I've also started reworking my website's CSS to improve its curb appeal. Like any other software undertaking, days when you delete more than you add fill me with joy. If I'm feeling particularly ambitions, I'll try doing the same to my photo archive; it could use some sprucing up too, but its underlying plumbing is what could use some real hardcore loving. It's been neglected for far too long, but even that's beginning to pick up, as I've begun to experiment with different workflows.
I'm really enjoying this burst of coding. It's especially nice when you have something to show for it!
New HTML Parser: The long-awaited libxml2 based HTML parser code is live. It needs further work but already handles most markup better than the original parser.
Keep up with the latest Advogato features by reading the Advogato status blog.
If you're a C programmer with some spare time, take a look at the mod_virgule project page and help us with one of the tasks on the ToDo list!
