Did I mention that I’m now on GitHub? See: https://github.com/jd-boyd
I figured that would be easier that uploading raw source code into WordPress. I could always post my own git archives, but GitHub provides online browsing nice visualization features, so I finally joined the crowd.
I’ve been continuing to poke at the ReferURL.net URL shortening service I run. Recently I’ve added the following new features:
I like using ReferURL.net a lot better now, and I hope you do as well.
First, I renamed it from msgQ to RESTq (or more likely just restq). Also, I’ve joined the modern age and pushed it up to github:
https://github.com/jd-boyd/restq
Up next, I shall put it into real use, and I do still want to add clients for more languages. Also, just because I can, I might rewrite the server in more languages (Python will probably remain the main one). I’m thinking of Go, perhaps C, and of course from the beginning I meant to also do so in erlang.
The symbol is Pi. I point that out since it doesn’t render very nicely in my web browser. The URL for the paper is:
http://proness.kix.in/misc/%CF%80p-v2.pdf
Yes, they stuck the symbol into the file name as well. Plan9 people seem to like to do such things just because they invented UTF-8 and were the first to heavily use unicode.
πp intends to replace NFS, SMB/CIFS, HTTP, FTP, 9p2000/Styx (the former plan9 file system), as well as more obscure options like Coda. To that goal, it tries to contain all of the features of those different choices that the authors deemed still useful into one new protocol. Ideas like extended metadata, non-file files (meaning the target on the other end is a file representing a printer, raw disk, or any other sort of device), offline operation, caching, and tolerance for proxies (possibly also caching) in the middle.
So, I think there are some features and decisions to like here. Here are a few.
File versioning can serve two purposes. It can be used to preserve history and it can be used for cache invalidation. πp intends to support both. File versioning to support history is potentially the most handy feature, but it will only work if it is matched with an appropriate on disk file system that supports file versioning. ZFS, one file system that can support versioning (by snapshots, but it doesn’t keep every revision automatically), doesn’t need the file sharing protocol’s help to support looking at the versions from remote systems. On ZFS, the snapshot history can be accessed in a directories .zfs sub-directory.
Without such a file system that supports versioning, πp’s versioning feature can still work for cache invalidation by setting an extended attribute on file systems that have some mechanism for doing so (xattr on some, resource forks on others). Personally, I think that supporting caching is largely only of use when πp is used as a replacement for http, which is further discussed later.
Pipelining would help resolve a major NFS complaint of mine, but it also seems like a large pit of danger. I’d be happy to consider using this protocol, but only for applications that don’t depend on heavy synchronous behavior out of concern about this feature, until it is better proven.
Extended support for special files is great for remotely sharing devices. This was always one of the nice features of plan9 (at least so it sounded, since I never gotten around to using plan9).
OTOH, here are some “features” that I require convincing of.
To replace http, the author’s get rid of the plain text parts. In web development, having those parts be human readable are tremendously useful and I doubt they waste much time in any given session. They also make web connections stateful using this protocol, while being stateless has always been one of http’s strong points (albeit one with some pain). Also extended file attributes seem like a poor alternative to http request and response headers.
Supporting lossy file transmission is rather a head scratcher. Their idea is that it could make for efficient streaming video transport, but still I’m not convinced. Does the client or server decide that the response is to be lossy? It looks like this is a client decision (client choosing by opening the πp connection over TCP versus UDP), however how is the client to know in advance which type of file this is? Is it supposed to query first? That seems ludicrous.
My conclusion though is that if you drop the usage ideas that I don’t like, I don’t see any changes being required in the protocol itself. This idea is obviously in the early states, but it looks like it could be worth exploring when there is more code to run.
On a side note, one thing that did interest me in the paper is that they wrote the initial implementation in Go, and then translate that to C. I didn’t know that Go existed on Plan9, but in looking into that it seems that it still doesn’t quite exist on plan9 since the runtime has yet to be ported. Oh well, one can hope for the future.
It also made me wonder how many plan9 from user space users make use of 9p still?
Today, I tried upgrading to a newer SlateDroid than what came on the device.
BTW, a small tip for use on Ubuntu:
sudo apt-get install p7zip p7zip-full p7zip-rar
Find the new firmware at: http://www.slatedroid.com/downloads.php?do=file&id=99
Stupidly, to get the download link, you must create an account on the SlateDroid forums to do so. Did I mention that many aspects of the Android community are really aggravating? Would it really be that bad to use github or sourceforge for this sort of thing?
Anyway a direct link is: http://www.mp4doggie.com/calver/M001%20Slatedroid%20Mercury%20Beta%202.7z
Note, by using this, you may miss out on newer versions. Also, this seems to be on a rather slow server, which would raise reliability concerns.
Once you have the file, extract it some where. In the long directory created, there will be a text file and a script folder. Copy the entire folder to the root directory of a SD card, then move the card to the M001, and reboot the M001.
You will get a message indicating that it will re-install in a few seconds, and if you do nothing, it just runs for about 2-5 minutes, then ask you to remove the SD card, and when you do it turns off. Turn it back on and it takes a very long time to boot the first time, about 10 minutes for me. Easy Peasy, but I would have felt better if the process was described.
After booting into the updated OS, the first thing I noticed is that screen rotate is no longer working. I checked the settings for this, but nothing jumped out as wrong. I didn’t put much more effort into why this was mis-behaving.
Since battery life was supposed to be one area of improvement, I tested that out with a full charge. What I found was that with light usage of contacts, web browser, flipping around through menus and ebooks, but not playing any audio (other than default system sound effects) or any video, the battery lasted under 2 hours. 2 hours is about double what the battery life was was before.
While I ran through various menus, web sites and so on, I paid attention to the responsiveness of the system. It may be a bit more responsive than the ealier SlateDroid firmware, but it is hard to be sure. The M001 is still is rather tricky to navigate. Scrolling in particular is difficult. Half the time I try to do so, it registers a click as I swipe across a list item, which means I enter a new menu, have to hit the back button, then try scrolling again. I haven’t a clue why this behavior exists. Is the touch screen not good enough? Is the processor too slow? Is the software too un-optimized? Or is it that there are ill timed software pauses that cause it to miss a beat? I don’t know, but if someone would work this out, it would be really nice.
This software upgrade brought the Aldiko e-book reader. This program is nice. You swipe to flip pages, and unlike general list scrolling, this actually works reliably. If you had decent battery life and wanted to use only this program, this could be worthwhile. Certainly if that was the goal, you could turn off wifi, which would help a little.
Web Browsing is the same after the upgrade as it was before. It is a real web browser. Web sites tend to just work correctly, including javascript. It is no speed demon. Scrolling is very sluggish, but unless there are lots of links on the page, you at least don’t have to worry about it mistaking a scroll for a click.
One weird note is the continued inclusion of the phone dialer. Why? There is no phone here.
I think that is about it for me and this device. I could load Debian on it still, but I just don’t feel motivated to try. While I could then try using it as a music player, I still have the problem of major noise on the output. With Debian I could use it to show pictures, but the screen still sucks even compared to my bargain basement picture frame. Of course, on Debian there don’t seem to be any polished enough WebKit based web browsers, so using it for the web doesn’t seem realistic (at this point Firefox on 128 megs of RAM is not pretty). I don’t see a lot of point.
I could keep it as a platform to hack on, but it doesn’t seem to be as open as other choices like the OMAPs, so if I was to get around to it, time would probably be better spent on my HawkBoard.
So, I say Adieu. Maybe I’ll try some Android 2.1 (or better still 2.2) tablet in the future.
I recently purchased an Eken M001, one of the cheap android tablets that you can find on eBay.
There are a lot of the super cheap tablets using Via WonderMedia chips. Based on online specs, the biggest differentiator between different models is whether it has 128 or 256 megs of RAM. It is possible that the displays vary.
My first complaint is that the screen and audio quality are poor. The screen has a strong screen door effect. The audio is subject to hiss and a large amount of internal interference (so, you can somewhat hear the machine “think”).
My second complaint is that the device is slow. I suspect that it is possible to wring a lot more performance out of this chip through better optimization of Android better for it, but while the SlateDroid team has made updated firmware for this device, I see no evidence that further optimization can be expected.
Battery life is poor, and the device doesn’t seem to go into much of a power saving mode. Again, I think this is largely a software issue, but also again I see no evidence that anyone is going to try and fix it.
The touch screen feels very unresponsive. I don’t know if this is a poor choice in touch screen technology and hardware, or if this is also software. Some people say it is obviously going to be poor since it is resistive instead of capacitive, but it is much worse than the resistive screens in old handhelds, such as Palm devices.
I will say that on the upside, Android 1.6’s web browser works extremely well (albeit sluggishly). In some ways, that makes the speed issues all the more aggravating, since it is a painful taste at what could be a really nice experience.
One possibility for this machine is to run Debian on it. I haven’t tried this yet, but it is supposed to be a simple operation. Debian on this would allow you to write code to use it as a control panel or display status information on it. You could also use it as a digital picture frame, but there are cheaper digital picture frames out there with a much nicer display.
In writing this, I see that there is a newer SlateDroid firmware available (now based on Android 2.0), so I will have to try that and post an update in the future.
emacs -nw myfile.c -e “ps-print-buffer” -e “save-buffers-kill-terminal”
By extension, you can keep stacking -e’s with interactive functions that take no arguments for as many commands as you want. I would imagine there is a way to pass arguments to the functions you list, but I haven’t found that yet. Also, it might be nice to be able to do something like -e “(+ 5 9)”, but I haven’t found the proper way to do that either.
David has a new hat to wear to his grandparents.
I don’t know where I got the idea from, but I’ve long thought that knowing how hot a pan is would be tremendously handy. And of course, the obvious way to measure surface temperature is with an infrared thermometer. So, I went and got a Ryobi IR001 Non-contact Infrared Thermometer (with Laser) from Amazon (see http://amzn.com/B001O7H61Y).
So far, it is particularly handy for seeing how close to boiling water is (212°F) and when a pan is hot enough to saute (350-400°F).
My only complaint is that it tops out at about 600 °F, and sometimes higher would be nice.
Also, I really wish that I would remember to keep notes on temperatures for frying eggs, pancakes, and what exactly is high, medium, and medium high?
The post C/C++ Message Passing from June ’08 is one or the more popular ones, if Google Analytics is to be believed. Not only that, but every one who arrived there by Google search was looking for C++, not C.
Upon re-reading it, it occurs to me that it would be a good candidate for being a lock free structure. With C++0x, this should be pretty simple to do, using the new atomic template. For straight C though, I would have to use compiler specific extensions (or inline assembly), so there may be little reason not to make a C++ specific version of the code that is lock free.
I’ve also thought of trying to use C++0x to construct a purely functional data structure library. In that case, C++0x would be chosen because of the new shared_ptr addition. I might have to have a post soon exploring that idea a bit further.
So far, I’ve converted this to be a C++ class and to use templates instead of void*s. Otherwise, it still behaves the same and still uses pthread locking directly. Additional versions will be forthcoming. Here is the recent work.
Hopefully it will be of use to some of the searchers. Keep an eye out for future revisions.