I write this primarily to one-up these guys, and it's also like a public-access log of my life, if my life consisted only of isolated geeky incidents occurring about every 3 weeks.
Dates are of the format YYYY-MM-DD.
Why this page is so simply formatted
rioBack on the 15th, I finally got bothered enough by rio to take action. Rio is the Plan 9 windowing system, and unlike basically all X window managers (including the p9p rio port), it doesn't support multiple virtual desktops. Oh, sure, the biggest apologists will tell you to just run multiple big rio windows and use winwatch to manage them, but that's crappy--I doubt any of them do it.
I cracked open the rio source around 1 p.m. In under half an hour, I was able to understand basically what was going on with the mouse menus. I stuck in some extra logic that called a new function called button2virt whenever the middle mouse button was pressed outside of an open window. This pops up a menu allowing you to choose a virtual desktop between zero and five. When a desktop is selected, the vswitch() function is called to switch the desktop. I went in and added an int virt variable to the Window struct and gave rio its own cvirt variable to keep track of its current desktop. Vswitch() merely goes through each window and checks its virt number against the cvirt number; if they match, that window gets drawn, but if they don't match the window gets 'undrawn'.
The whole exercise took probably four hours, when you count testing and some later bugfixes I made. To my mind, it really illustrates the ease with which Plan 9 code is modified. The windowing system rio is simply and clearly written, in part because the libraries and other conventions lead naturally to such code, but also because of the very smart people who wrote rio in the first place.
Here's a screenshot showing the new virtual desktops menu; on the left is a cpu session to my server at RIT, in the upper right is a window running the command to capture the screen.
Since Monday I've been at the International Conference on Supercomputing at IBM Watson, in Yorktown Heights, New York. It seems that everybody is really into Linux and the Cell processor. We've heard how the Roadrunner system is a savior of scientific computing, but by Ron's account it took way too long to install, and everyone who spoke about working on Roadrunner mentioned that it is very hard to program for the Cell. There have also been some talks on transactional memory, network optimization, stuff like that. However, Im afraid not very much is really applicable to what we're doing with Plan 9 and BlueGene.
I'd say I'm actually learning more at lunch and during breaks, when Ron, Eric, and Charles (Plan 9 guys) get together and talk about Plan 9 and supercomputers without all the obfuscation of the talks.
Last night we went for a boat cruise around NYC as the conference excursion. Although the weather was rather poor, we did get an enjoyable trip. Among other things, we saw the Brooklyn Bridge, the Statue of Liberty, the World Trade Center, Ellis Island, the Empire State Building, and a whole lot of other historic places. After the tour we got dinner at a rather nice place... remember, the higher empty-plate to food ratio, the classier the restaurant is.
Right now, I'm sitting in a presentation on evaluating high performance communication... it's not really my area but we'll see.
Ok guys, you're all up in arms because Time Warner wants to put caps on bandwidth. The fact is, the Internet is pretty much the only service you don't pay by usage; the only other thing that comes to mind is cable, but it costs the same to TW if all of Rochester watches TV or if nobody watches TV. ISPs have to pay for their bandwidth; the reason Internet access has been uncapped (in the States, at least--NZ and Australia, among others, have been capped forever) is that prior to the Web 2.0 Youtube/Hulu/Gmail/everydamnthing explosion, most people didn't use much bandwidth. Your average user would browse some static pages, read the news, check email, maybe play a Flash game. Then Youtube and its brethren came along. Now an hour of web browsing involves downloading a gig of data, perhaps. Google, who run Youtube, is losing millions due to their bandwidth costs. The fact is that today's infrastructure cannot support unlimited downloads, so we're going to have to pay. This isn't a particularly new concept--back in the day, a lot of people paid by the minute for dialup unless they forked over the extra money for unlimited connection time... does this sound familiar at all?
That's right, Web 2.0-weenies. Your precious brilliant idea of putting everything back on a server so we have to download our own data again and again has brought an end to unlimited bandwidth. Congratulations. I hope this kills Twitter, by the way.
Forget One Laptop Per Child--everybody else has, anyway. Here's a better idea: One Engineer Per Village. I know it's been done before (that's kinda the idea behind the Peace Corps, right?), but it's surely a better idea than the current "give third world citizens high tech and surely they'll come out ok" plans that seem to come about all the time.
Bringing simple, modern tools to places like sub-Saharan Africa is better than giving them laptops. Build dams, increase the amount of land the people are farming, give them some good strong new shovels, plows, hammers, saws. Make sure they're familiar with crop rotation to avoid soil depletion. Teach what modern animal husbandry is feasible--make sure people who own cattle, for instance, know how to birth a calf, identify common illnesses, and use simple cheap medicines such as sulfanamides to save valuable animals. Provide BOOKS! Relevant texts in basic civil engineering, medicine, agriculture can be free or nearly so: a 20 year old book on simple (subsistence) farming is not going to be outdated in this context.
Most important, I think, is including someone who has lived with these things his whole life, is good at solving problems, and has a practical mind--an engineer, in other words. Ideally an engineer who, like myself, grew up on a farm and has a good idea of what sort of things are important and how to do them. Someone who will organize work on projects, arrange for payment of those who help, maintain the reference library, and in general be someone people can go to for help. Equipped with a satellite phone and a laptop, he can communicate with outside experts and synthesize solutions.
In my opinion, it's important to develop a certain level of basic comfort and stability before high tech is useful. I don't want to be condescending, and I admit there are lots of places where this alone wouldn't help. I won't pretend Westerners are so perfect and have all the answers, but if nothing else we're very good at exploiting natural resources, which is exactly what is needed in this case.
First, get rid of the emphasis on phone calls. We should be thinking in terms of powerful mobile computers which happen to be able to make phone calls. Let me bring in some Plan 9 concepts here.
Plan 9 is all about running programs from a remote server on the local terminal. The Octopus system has taken that even further, giving users a persistent session that gives easy access to the terminal's resources. A user runs one machine as a "PC" which stores files and programs, but he accesses the PC from other devices acting as terminals and using each other's resources. One of the papers leading to the Octopus is called "Give Me Back My Personal Mainframe!", which really highlights the idea. Each user should have a powerful computer somewhere which can be accessed from elsewhere easily.
What I'd like to see is a powerful phone which can act as the personal mainframe. You carry it in your pocket; it stores your files and programs. The phone can be used directly, but the real breakthrough in functionality would come indirectly. Imagine: you sit down at a computer and authenticate to your phone, which is plugged into the computer's USB port, or into a wired ethernet port, or it picks up wireless, or just sticks with cell data transfers. After logging in, you can access your data and programs stored on the phone. Programs run on the computer you're using, but the binaries come from the phone.
The result is that your data follows you; we're saved from the cloud computing apocalypse by keeping mainframes in our pockets. Now that hardware is a cheap resource, it's time to do more thinking about how we can better manage the important stuff--our data.
Because I'm all wakeful after the long flight in from California, I'd like to share something we realized (extremely late) over at Sandia. Sandia tends to filter a lot of stuff on the network; http has to go through a proxy, and many other ports are just plain blocked.
I had run into problems several times where I wanted to access some service outside Sandia but couldn't because the ports were blocked. Similarly, since Plan 9's rather simplistic web browser doesn't do proxying, I hadn't been able to use it for web stuff. The other day, though, Ron pointed out a simple solution to my problem:
import csplan9 /net
That is, I could import the network stack from csplan9, which isn't proxied or filtered at all, and just hit the Internet to my heart's content. This really points out the futility of proxying or blocking ports; as long as ONE port is opened outgoing, you can run a server on the outside that will make connections for you, effectively circumventing the local security measures. The IT guys are guarding the front door because people usually go through the door, but in this case the door is blocked--so they're going in and out through the windows. The difference is that when users can use the network normally, IT can monitor traffic to some extent and respond to problems. When ports get blocked and users start doing tricks like the import above, IT loses all their monitoring potential; all they get to see is a single encrypted 9P connection to a server somewhere.
It seems to me that the best solution is to keep outgoing ports opened by default, but monitor the connections to find abuse or security breaches. All the current measures are doing is making life harder for people trying to do legitimate things.
With devtrace done, I spent today on the other main task for the trip. Ron got a Coraid SR1661 ATA-over-Ethernet (AOE) box some time ago, so I get to set it up. The SR1661 is a rackmounted system with a small motherboard running Plan 9 (booting off a compact flash device) and controlling 16 1 terabyte drives. ATA over Ethernet means that with a simple driver (included in Plan 9) you can access the Coraid box's files over the network just as if it were a drive plugged into the motherboard.
It's a great system; I only spent about 10 minutes figuring out how to set it up and access it from Plan 9. I connected via the serial console and set it up to run 15 disks in RAID-5, giving me a single 14 TB array; the 16th disk is an online spare in case one of the drives dies. A quick bind and an echo later and I was able to see /dev/sde0 on my Plan 9 server, size 14 TB. Right now (as I write this, probably) it is initializing the parity stuff on the RAID. When I get in tomorrow, I'm going to create Venti partitions on the Coraid box to access from the Plan 9 server. This will give us a system with 80 GB of fossil (fronting store to venti) and 14 TB of Venti archival backing store. Frankly, I'm not sure what we're going to do with all that space, but I don't think storage is going to be a problem in the near future.
Today I had a great demonstration of how writing portable code can help you. As I've written before, I helped Ron Minnich complete the devtrace system for Plan 9, which allows you to monitor entries and exits into sections of code--I've found it useful to see exactly what functions a given program calls, but it can also be used to see just how many times a function is called over a period of time. Anyway, during my co-op I took the prototype version on the x86 platform, adapted it to amd64, and completed it. This was all on the new development kernel. Then I backported it to x86 again on the old kernel. At this point, devtrace consists of a large-ish C portion and two small functions in assembly. In porting to amd64, it was necessary to generalize the C code so it does not depend on the word length or anything else specific to the architecture; the only architecture-specific code is in the assembly functions.
The practical upshot of this is that porting to a new platform involves nothing more than writing two short assembly functions (about 30 lines total) and compiling the kernel. The assembly functions all do the same thing--push the caller's arguments onto the stack again along with the caller's PC, then call a tracing function--so it isn't particularly difficult to write them.
I started work on a port to BlueGene/P this morning. By 3 p.m. or so all the code was written (it took a while because I was working on other projects too and I had to research how the BG/P stack works). By quitting time, we had compiled the kernel, booted it on a real BlueGene, and verified that everything worked.
By writing code that focused on being portable with a minimum of architecture-specific bits which were kept separate from the portable parts, we werew able to save a lot of time in porting. This is basically the whole idea behind Plan 9's kernel too--lots of C, with as much common to all architectures as possible, and just the bare minimum of assembly. Side note: we're updating the devtrace paper in the next couple days and submitting it to Supercomputing 2009.
I'm currently grading an Operating Systems 1 project, and I've got to say this is some of the worst style I've seen in a long time. Everyone in this class should have already taken and passed CS 1 through 4, yet they still manage to screw up the most basic formatting. The project is to write a simple shell in C; I'm just going to look at the formatting issues, never mind the actual logical problems.
if (foo) {
bar();
}
else {
foobar();
}
because it looks STUPID. Just remove all those newlines between the if's } and the else.
%ls foo.txt mlar.txt shell.c %rather than
%ls foo.txt mlar.txt shell.c %I understand that it can sometimes be hard to remember where you're putting in newlines, but please just test your code before submitting it. This goes for all output, not just interactive output.
printf("I'm a boofhead\n");
/* sleep for a while to let the user digest that */
sleep(1000);