The day started at 5:30 AM. Boo, hiss.
We drove out to the tour office, and my sister started throwing up - luckily, it was temporary, probably from waking up so damn early; she was fine for the important parts of the day. After we signed a bunch of forms, the tour people drove us out to the airport, where we got in the smallest plane I have ever flown in. It was an 8-person plane, so my youngest sister actually got to sit in the co-pilot's seat on the way there. I was kind of jealous. D:
After a flight of about an hour, we landed at this little airstrip out in the middle of nowhere. (Why did we fly? There are no roads anywhere near there.) We grabbed icy water bottles, took a quick nature hike through the rainforest, and after admiring a few random plants and miscellaneous buildings (and also some rainforest fauna [1]), we started to hear a roar off in the distance and we knew we were getting close. Then the source of the roar was right in front of us (that amount of vegetation muffles sounds like crazy) and we were standing on a tiny lip of rock jutting out over Kaieteur Falls [2].
I have seen Niagara Falls up close, so trust me when I say that Kaieteur Falls is freaking unbelievably huge.
Surveyors agree with me; at 741 feet straight down, it's the worlds tallest waterfall. The water is the color of iced tea, which is an effect that I'll touch on more later. The bottom half of the fall is completely covered by mist half the time, but the other half of the time, it's just completely breathtaking. One thing that you can't help but notice is the complete lack of guardrails or other safety features - this isn't some coddled first-world natural wonder, where you go out on a little boat wearing a custom-made poncho, and stop by the gift shop on the way back. [3] The only thing to stop you from crawling right up to the edge and sticking your head over is the tour guide, who became increasingly agitated with my mom when she did exactly that. It was kind of scary, actually - he was trying to tell her that the rocks were slippery, and that she shouldn't do that, and she was completely oblivious that he was saying anything, or that the rest of us were trying to get her attention. "Mom! The tour guide has been yelling at you for the past two minutes to come back from there, and so have the rest of us." "Whaa?"
On the way back I actually managed to stay awake for most of the plane ride (Dramamine knocks me right out, apparently), and got some nice videos. One thing most people don't realize about the rainforest: there are a hell of a lot of trees in there. I seriously would estimate that I saw a few million trees today. Horizon to horizon, nothing to see but the tops of trees.
The next leg of the trip was to a smallish riverfront resort, which was a nice change from hiking through the woods. We got there via a small boat, because - surprise, surprise - there are no roads going there. The first thing that strikes you is the water. In the Demerara river, the water is the color of chocolate milk, because of all the silt it picks up. In the tributary we spent most of our time in, on the other hand, the water was the color of iced tea, because of all the dead leaves that are in the water. (Probably the same reason that Kaieteur Falls is that color.) [4] (Looking back at the analogies we came up with, it's possible that we were a little bit thirsty after sitting on a boat for two hours during the hottest part of the day.)
The resort was really really nice - beach volleyball (that we lost horribly at, but still) and kayaking. They also had rice, dal, and assorted other foods. (I don't think that a day has gone by on this trip that we haven't eaten rice and dal. It's kind of the quintessential Guyanese food.) They even had hammocks, which are amazing under pretty much any circumstances, but especially so in the tropics. Not a lot to say about the resort, really. It was very nice, but not a lot happened.
Te tributary we used to get to it has an interesting property - the flow changes direction based on the tide, every six hours. I'm not completely certain, but I'm pretty sure that we went upstream both ways, going and coming. We got back just before it got completely dark out, which was kind of a relief. We were going down the river without any lights, and it was kind of dicey toward the end. Still, we made it. (I could swear I saw a completely black butterfly on the way back, but I may have imagined it. Still, the two people that read my blog and have seen Bleach may appreciate the reference.)
The day ended with a lot of Chinese food. Best day of the vacation so far? I think so.
[1] Rainforest ants = holy fucking insanely huge. I was just walking along when I saw an ant carrying something, the damn thing must have been an inch long.
[2] "Kaieteur Falls" is actually a misnomer, according to our tour guide. "Kaieteur" means "Kai Falls" in whichever language it came from, so the name everybody uses is redundant. And, for the curious, it's pronounced "kai-choor."
[3] On a somewhat more sobering note, there was a suicide there last year. Both our tour guide and our driver remembered it; the latter mentioned that he knew because there was one fewer seat filled in his van on the next leg of the trip. :(
[4] I know it's ridiculous, but given Guyana's history, I can't help but imagine a mad Englishman at the head of the river, dancing around a machine he's built which can prepare enough tea to fill a river with it.
Saturday, March 20, 2010
Thursday, March 18, 2010
The One-Dimensional City
Blogging live from Guyana! Because if I don't write this stuff down now, I'm going to forget it by the time I get back and have reliable Internet access.
So the first thing I noticed about driving in Guyana is that they drive on the left side of the road here. I guess that makes sense; it was originally a British colony after all, but it's still unsettling to see. With the caveat that my experience is all secondhand, from the passenger seats in taxis, driving in Guyana doesn't seem as awful as someplace like India. There are still pedestrians walking in the street randomly, as well as feral dogs [1], and cows and donkeys in the rural areas. But it's certainly not as crowded as the city streets in New Delhi, and the roads are actually pretty good here. As good as the roads in Houston, at least, which definitely surprised me.
The last taxi ride we took (from a Chinese restaurant back to the hotel) cost us $300, but that's not so bad when you consider that the exchange rate from Guyanese dollars to US dollars is 200:1. It turns out that Chinese food is big in Guyana - probably even more so than Indian food. Considering the number of Indians that live here, this is actually pretty surprising.
But anyway, the reason I'm talking about roads is the Big Road. I'm calling it that, because I can't find an official name for it. Between Georgetown and Skeldon, there's one long highway that runs across half of Guyana's coastline. It's just your basic two lane highway, except that there are houses and offices and basically all sorts of buildings running along it uninterrupted the whole way down. Aside from a few empty lots, or a few acres of farmland here and there, it's one long unbroken urban area. In most places, the development only goes back a few lots, so you end up with an urban area that's several dozen miles long and a few hundred feet wide. It's like an entire city was stretched out along a single road. Somewhat arbitrarily, it's divided into villages; I think the divisions might even be on mile markers. If I recall correctly, the villages are numbered one to sixty-something, going from West to East.
All of this was necessary for the next bit to make sense: we visited the house where my mom grew up, in 43. Really, the official name is Village #43, but everybody just calls them by their numbers. (We also visited the school she used to go to - that was neat, if a little embarrassing. She even ended up making a speech. D:) It's kind of amusing/amazing how many people know our family. We joke about how everybody in Guyana knows everybody else, but only because there's a grain of truth to it. Example: at the hotel we stayed at the other night, the owner heard that my uncle's last name was S_____. He asked, "Not the S_____'s from 43?" Similar scenes have happened several times, believe it or not. It's really cool and at the same time a bit disturbing.
Anyway, speaking of my uncle, this is his laptop, so this is all I can write for now. The next post is going to be about waterfalls, and if I'm late enough writing it, it may contain videos.
[1] Feral puppies: just as adorable as tame puppies. (From a distance, of course.)
So the first thing I noticed about driving in Guyana is that they drive on the left side of the road here. I guess that makes sense; it was originally a British colony after all, but it's still unsettling to see. With the caveat that my experience is all secondhand, from the passenger seats in taxis, driving in Guyana doesn't seem as awful as someplace like India. There are still pedestrians walking in the street randomly, as well as feral dogs [1], and cows and donkeys in the rural areas. But it's certainly not as crowded as the city streets in New Delhi, and the roads are actually pretty good here. As good as the roads in Houston, at least, which definitely surprised me.
The last taxi ride we took (from a Chinese restaurant back to the hotel) cost us $300, but that's not so bad when you consider that the exchange rate from Guyanese dollars to US dollars is 200:1. It turns out that Chinese food is big in Guyana - probably even more so than Indian food. Considering the number of Indians that live here, this is actually pretty surprising.
But anyway, the reason I'm talking about roads is the Big Road. I'm calling it that, because I can't find an official name for it. Between Georgetown and Skeldon, there's one long highway that runs across half of Guyana's coastline. It's just your basic two lane highway, except that there are houses and offices and basically all sorts of buildings running along it uninterrupted the whole way down. Aside from a few empty lots, or a few acres of farmland here and there, it's one long unbroken urban area. In most places, the development only goes back a few lots, so you end up with an urban area that's several dozen miles long and a few hundred feet wide. It's like an entire city was stretched out along a single road. Somewhat arbitrarily, it's divided into villages; I think the divisions might even be on mile markers. If I recall correctly, the villages are numbered one to sixty-something, going from West to East.
All of this was necessary for the next bit to make sense: we visited the house where my mom grew up, in 43. Really, the official name is Village #43, but everybody just calls them by their numbers. (We also visited the school she used to go to - that was neat, if a little embarrassing. She even ended up making a speech. D:) It's kind of amusing/amazing how many people know our family. We joke about how everybody in Guyana knows everybody else, but only because there's a grain of truth to it. Example: at the hotel we stayed at the other night, the owner heard that my uncle's last name was S_____. He asked, "Not the S_____'s from 43?" Similar scenes have happened several times, believe it or not. It's really cool and at the same time a bit disturbing.
Anyway, speaking of my uncle, this is his laptop, so this is all I can write for now. The next post is going to be about waterfalls, and if I'm late enough writing it, it may contain videos.
[1] Feral puppies: just as adorable as tame puppies. (From a distance, of course.)
Friday, March 12, 2010
Pre-vacation idea dump
I'm going to be out of the country for a week and a half! Gotta braindump this stuff or I will forget it by the time I get back.
Mobile filesystem
My search for a network filesystem that supports offline writes can best be described as a dismal failure. AFS is the closest thing that I could find, and it was designed in the '80s and is kind of archaic, and looks to be a pain to set up. (Plus I doubt my home stuff will ever scale up to tens of thousands of computers. :p) DRBD+NFS was the next best candidate, but I dunno. I'm sick of all the interesting stuff being implemented at the block layer, while filesystem designers are still dicking around with consistency models (see for instance the drama last year with ext4 and fsync()). Plus it won't do me any good for disconnected operation, whoops. Rsync is the third best candidate, which is seriously just sad. (Honorable mention goes to XtreemFS, which (in addition to having a truly awful name) only supports read-only replication. Way to only solve the easy problems, guys!)
So, fine. If it doesn't exist, I'll just build the damn thing myself.
My design is based on BTRFS writable snapshots, for a lot of reasons. First because they're freaking cool, second because it means this design degrades in the worst case to a completely usable filesystem. Third, because they're really freaking cool. :D
So, computer A wants to sync with computer B. A creates a writable snapshot, and then uses rsync to pull in the updates from B. Now A has a copy of the current state of B's filesystem, without using up excessive space because it was copied over a snapshot, and we're assuming that the differences are relatively small. (Directory renames mess this up, and are a weakness of this approach, but not a deal-breaker.) This can all happen in the background, so far. Now, the user at A can apply a merge strategy using a hypothetical merge program, and bring their main copy of the data into sync with B's copy. They can do this at their convenience, because the data's all stored locally, so there's no need for B to even be connected. If there are conflicting changes, we can look back at the original data (because we have a snapshot) and the two divergent copies; a three-way merge is pretty much the best we can hope for here. Advantages of using writable snapshots: saves disk space, lets this strategy work with any number of other computers, freaking cool.
The merge program is completely hypothetical, because whoops, it turns out that merging sets of files automatically is a fundamentally hard problem. Still, there are all sorts of useful heuristics we can use, before we kick the problem up to the user. If a copy of the filesystem isn't being used, it could be set in a "receiver" mode, where it just takes all the updates it sees from other computers. Files that are only modified on one side or the other of the merge could also be copied safely, probably. Er, maybe not. Gotta think about that more carefully. N-way merges could be handled as a series of 2-way merges, I think.
Vector clocks are basically magic, and this scheme will have to use them to keep track of merge results (so that they can be propagated), and for garbage collection (because disk space is cheap, but it's not that cheap). All the accounting information can be stored as a special file in the filesystem, which is doubly convenient because it means that every system has access to the state of every other system. Ooooh, we could store the vector clock across all of those - it needs to store a logical clock per-replica, and we conveniently have per-replica storage already because of the nature of the system. Slick. :D
Structured (JSON) pipes
The philosophy of UNIX involves creating programs as commands that can receive input from other programs, and pass output to other programs. In that sense, UNIX has failed us. Text streams can be easy to read, and they can be easy for a program to parse, but they are rarely both. This is really a topic for a proper rant, some other time.
But what to do about it? My solution (which I will implement when I get some free time) is structured pipes. Pipes should take a stream of JSON objects (or some other format, but JSON is nice for this sort of thing) on standard input, and write a stream of JSON objects to standard output. Then, instead of writing fragile and error prone nonsense to parse text using cut and awk and sed and miscellaneous tools, we could have a standard JSON query command that pulls out a given field of an object. Instead of trying to use the same output stream for humans and programs, we could have a standard program to translate the JSON stream to something human-readable. (Hell, a terminal could do this automatically - then we wouldn't even have to think about the JSON layer underneath. Everything would just work.) Programs could output a format specifier as part of the stream - then we could get output at least as nice looking as the crap we have now, and the potential for it to be a lot better. Plus, programs could change their output format without breaking every damn script that uses them written in the past three decades. (Example: df. It's hopelessly out of date, and there's no good way to shoehorn information about RAID, or compression, or modern disk stuff, into its output. But nobody can change the output format, because scripts depend on it.)
UNIX also sucks at delimiting fields, which you'd think would be a basic thing when your entire operating system philosophy is based on processing text streams. It uses a random mishmash of spaces, tabs, and null characters for cases when whitespace won't do. Why not set a standard delimiter? Like, I don't know, one of the ASCII characters explicitly set aside for use as delimiters? The problem is, UNIX text streams have no concept of escaping, so any character could potentially appear in the stream. UNIX gets around this, when it bothers to address the problem at all, by letting you choose between a few output delimiters. For instance, if you think your output will have newlines, you can tell the find command to use nulls instead. This complicates the program reading the output of find, of course, so the ones that are likely to be hooked up to find (xargs, for example) also have special cases for handling null-terminated input.
This is kind of turning into a rant, so I will summarize: The whole thing is an ugly mess. And using JSON as an intermediate format would also get us standard delimiters for free.
When I write this, I suppose I'll have to also write a set of core utilities that operates on JSON streams. It shouldn't be too much work, I don't think.
Mobile filesystem
My search for a network filesystem that supports offline writes can best be described as a dismal failure. AFS is the closest thing that I could find, and it was designed in the '80s and is kind of archaic, and looks to be a pain to set up. (Plus I doubt my home stuff will ever scale up to tens of thousands of computers. :p) DRBD+NFS was the next best candidate, but I dunno. I'm sick of all the interesting stuff being implemented at the block layer, while filesystem designers are still dicking around with consistency models (see for instance the drama last year with ext4 and fsync()). Plus it won't do me any good for disconnected operation, whoops. Rsync is the third best candidate, which is seriously just sad. (Honorable mention goes to XtreemFS, which (in addition to having a truly awful name) only supports read-only replication. Way to only solve the easy problems, guys!)
So, fine. If it doesn't exist, I'll just build the damn thing myself.
My design is based on BTRFS writable snapshots, for a lot of reasons. First because they're freaking cool, second because it means this design degrades in the worst case to a completely usable filesystem. Third, because they're really freaking cool. :D
So, computer A wants to sync with computer B. A creates a writable snapshot, and then uses rsync to pull in the updates from B. Now A has a copy of the current state of B's filesystem, without using up excessive space because it was copied over a snapshot, and we're assuming that the differences are relatively small. (Directory renames mess this up, and are a weakness of this approach, but not a deal-breaker.) This can all happen in the background, so far. Now, the user at A can apply a merge strategy using a hypothetical merge program, and bring their main copy of the data into sync with B's copy. They can do this at their convenience, because the data's all stored locally, so there's no need for B to even be connected. If there are conflicting changes, we can look back at the original data (because we have a snapshot) and the two divergent copies; a three-way merge is pretty much the best we can hope for here. Advantages of using writable snapshots: saves disk space, lets this strategy work with any number of other computers, freaking cool.
The merge program is completely hypothetical, because whoops, it turns out that merging sets of files automatically is a fundamentally hard problem. Still, there are all sorts of useful heuristics we can use, before we kick the problem up to the user. If a copy of the filesystem isn't being used, it could be set in a "receiver" mode, where it just takes all the updates it sees from other computers. Files that are only modified on one side or the other of the merge could also be copied safely, probably. Er, maybe not. Gotta think about that more carefully. N-way merges could be handled as a series of 2-way merges, I think.
Vector clocks are basically magic, and this scheme will have to use them to keep track of merge results (so that they can be propagated), and for garbage collection (because disk space is cheap, but it's not that cheap). All the accounting information can be stored as a special file in the filesystem, which is doubly convenient because it means that every system has access to the state of every other system. Ooooh, we could store the vector clock across all of those - it needs to store a logical clock per-replica, and we conveniently have per-replica storage already because of the nature of the system. Slick. :D
Structured (JSON) pipes
The philosophy of UNIX involves creating programs as commands that can receive input from other programs, and pass output to other programs. In that sense, UNIX has failed us. Text streams can be easy to read, and they can be easy for a program to parse, but they are rarely both. This is really a topic for a proper rant, some other time.
But what to do about it? My solution (which I will implement when I get some free time) is structured pipes. Pipes should take a stream of JSON objects (or some other format, but JSON is nice for this sort of thing) on standard input, and write a stream of JSON objects to standard output. Then, instead of writing fragile and error prone nonsense to parse text using cut and awk and sed and miscellaneous tools, we could have a standard JSON query command that pulls out a given field of an object. Instead of trying to use the same output stream for humans and programs, we could have a standard program to translate the JSON stream to something human-readable. (Hell, a terminal could do this automatically - then we wouldn't even have to think about the JSON layer underneath. Everything would just work.) Programs could output a format specifier as part of the stream - then we could get output at least as nice looking as the crap we have now, and the potential for it to be a lot better. Plus, programs could change their output format without breaking every damn script that uses them written in the past three decades. (Example: df. It's hopelessly out of date, and there's no good way to shoehorn information about RAID, or compression, or modern disk stuff, into its output. But nobody can change the output format, because scripts depend on it.)
UNIX also sucks at delimiting fields, which you'd think would be a basic thing when your entire operating system philosophy is based on processing text streams. It uses a random mishmash of spaces, tabs, and null characters for cases when whitespace won't do. Why not set a standard delimiter? Like, I don't know, one of the ASCII characters explicitly set aside for use as delimiters? The problem is, UNIX text streams have no concept of escaping, so any character could potentially appear in the stream. UNIX gets around this, when it bothers to address the problem at all, by letting you choose between a few output delimiters. For instance, if you think your output will have newlines, you can tell the find command to use nulls instead. This complicates the program reading the output of find, of course, so the ones that are likely to be hooked up to find (xargs, for example) also have special cases for handling null-terminated input.
This is kind of turning into a rant, so I will summarize: The whole thing is an ugly mess. And using JSON as an intermediate format would also get us standard delimiters for free.
When I write this, I suppose I'll have to also write a set of core utilities that operates on JSON streams. It shouldn't be too much work, I don't think.
Tuesday, March 9, 2010
Donut math
There is a little donut shop down the street from me, called Ken's Donuts. The donuts are good (better than any chain I've ever eaten at, at least), cheap, and best of all, they're open 24 hours a day. They have maple-glazed donuts, which are kind of seriously amazing. And to top it all off, they have samosas!
So, because I am trying to save money, I've started quantifying impulse buys in terms of Ken's donuts. As in, the money I want to spend on this could buy me X donuts. Will it make me happier than X donuts? (Yes, there's the obvious fallacy with diminishing returns. Obviously I don't apply this logic to stuff like groceries, jeez.) Mediocre fast-food value meals don't look quite so good next to a dozen donuts. Or, on the flip side, a slice of cheese at that Death Metal Pizza place on 6th Street will cost me about five donuts, but it's worth it because I can say I've eaten at a Death Metal pizza place.
But then, I was thinking as I was trying to fall asleep. My rent is $1300 per month, split with my sister, so $650 per month. Over the course of the academic year, this comes out to about $6000 that I'm spending on rent. A bit of quick mental arithmetic reveals that instead of living here, I could buy about ten thousand donuts.
Ten.
Thousand.
Donuts.
I would be the world's happiest hobo.
So, because I am trying to save money, I've started quantifying impulse buys in terms of Ken's donuts. As in, the money I want to spend on this could buy me X donuts. Will it make me happier than X donuts? (Yes, there's the obvious fallacy with diminishing returns. Obviously I don't apply this logic to stuff like groceries, jeez.) Mediocre fast-food value meals don't look quite so good next to a dozen donuts. Or, on the flip side, a slice of cheese at that Death Metal Pizza place on 6th Street will cost me about five donuts, but it's worth it because I can say I've eaten at a Death Metal pizza place.
But then, I was thinking as I was trying to fall asleep. My rent is $1300 per month, split with my sister, so $650 per month. Over the course of the academic year, this comes out to about $6000 that I'm spending on rent. A bit of quick mental arithmetic reveals that instead of living here, I could buy about ten thousand donuts.
Ten.
Thousand.
Donuts.
I would be the world's happiest hobo.
Subscribe to:
Posts (Atom)