Planet OLPC

The Challenges of Electronic Reading

2008-07-03T10:10:14+00:00

Last week, I spent a fair amount of time stumbling through the various available methods for reading on a computer. Our current method is that of the .pdf. Well, if your are at all like me, you hate reading a .pdf soft-copy. I always end up printing the damn thing, so I can sit down and mark it up. This option obviously won’t work in Nepali schools, because they don’t have access to a printer, and even if they did, it would not be cost effective.

In searching for a reasonable alternative to .pdfs, I came across a few “flip-books,” and a decent program called Sophie. The flip-books were pretty cool, although they do tend to lag pretty severely on the XO, and there is occasionally significant quality loss when converting from .pdf to the flip-book. Incidentally, this is the same issue I had with Sophie. What lies at the root of the problem is transference of Nepali characters. I for one do not have the ability to understand the characters, however, even if I did, the process of re-typing the characters of a page into Sophie would be far too time consuming.

So what does that leave us with? Well the flip-book’s look pretty authentic, and there may be some potential partnerships for acquiring content, but for the immediate future we are left with existing formating. I conducted a comparison of features between Sophie and Adobe, and here are the results:

Reader Comparison

Author Comparison

So as you can probably see, there are some issues with Sophie, especially due to the fact that is very much a beta package, and there are many platform kinks still needing to be worked out. Sophie actually worked great on my mac, but this does little to help with the XO, or with creating docs. None-the-less, it appears that for the time being, .pdf will have to be the answer for Pustakalaya (the e-library).

We are exploring the use of other options, but for now, I hope you can enjoy our observations.

Doug

The present is 30 years ago (in design theory)

2008-07-03T04:30:09+00:00

We picked up a book a year ago that I've been intending to read but never seemed to get the time; "Architectural Theory from the Renaissance to the Present" (Taschen, 2006). Today I wound up with some dead time sitting in offices and got a chance to read through part of the chapter on the 20th century.

By way of background, Soni met another architectural design theorist at the Cafe Scientifique half a year ago and she arranged a chance for all of us to sit down over crepes to discuss theory. Thing is, we studied rather different areas of theory. She was focussed exclusively on the most current post-modern theorists. My thesis stopped with the early theorists of architectural postmodernism, though I read a few of the later theorists, none seemed to have much in the way of non-trivial insights (to my young mind).

The number of times I've met another design theorist can be counted on a single finger, so rather than not having any common ground to discuss, I figured I'd bone up on the major theories of current post-modern theoretical thought. Toward that end, the "to the Present" in the title was promising. I was intending to sit down and read the book's (encyclopedically-styled) introduction to the major theorists of post-modernism so that I could put together a reading list to pick up from the architecture library at U of T.

Except the book leaves off right where my thesis did. That is, it covers up to the era of Venturi and Koolhaas and then stops, apparently having exhausted the interesting postmodern theorists. Or did they just not have time to cover the later theorists? Or were they later theorists just not in their field of study? For whatever reason, the present seems to stop 30 years ago in terms of architectural ideas.

Since I had the time, I also browsed through some of the older entries. Some are pretty obviously uninteresting (e.g. folks creating how-to books for constructing gothic style features during the eclectic period), some are more theoretical. It will probably be worth it to go through the book in a more systematic way and see if there's anyone I've overlooked in my studies, but it doesn't seem it's going to help with updating to the debates of the day.

What is a voltage regulator?

2008-07-02T22:56:56+00:00

Because we’ve been getting questions on “what is a voltage regulator?” (a voltage regulator being one of the many things we’re building this summer), here’s how I’d explain it to a 10-year-old.

The XO is designed for children in developing nations, kids who may
not live with easy access to a reliable power grid they can charge
their laptops from. Most laptops need a very precise voltage and
amperage into them to have them charge properly (and not explode). This
is like only being able to eat purple-colored fruit - you can survive,
but it’s somewhat inconvenient compared to being able to eat fruit of
any color.

The ability to plug any power source (a solar panel, a
diesel generator, a car battery, etc.) into a computer and have it
“just work” would be awfully handy, and greatly expands the types of
conditions under which the XO can be used. While the XO is already
designed to accept a range of power inputs (11-20V), anything that can
be done to extend that range would help; in particular, some types of
power sources a child might want to use (human power, animal power, car
batteries, solar panels) can fall outside that range or have current
spikes greater than the XO’s power circuitry can handle.

We’re building a voltage regulator that will help people using
off-grid power peripherals for the XO. It’s a device that sits between
the laptop and a power source, takes in whatever random power input
it’s given (within limits - but very broad limits), and gives you two
things: an 18V, 0.944A output to charge your XO by, and an “overflow”
output of excess wattage which can be dumped into a battery, a motor,
or (in the default worst case) a dissipator/heatsink. (Hey, it’s better
than frying your laptop.) To mangle the earlier analogy, it’s like a
magic hat that enables you to eat red, green, and blue fruit instead of
just purple fruit when you put it on.

On reference counting

2008-07-02T16:16:54+00:00

I made a little bit of documentation on reference counting. It’s not yet really finished, but I’ve let two other developers review it now. I guess that means it’s somewhat ready.

The reason I made it was because as I browsed and contributed to GNOME’s code, I noticed that a lot of developers seem to either ignore reference counting or they use it incorrectly all over their code.

I even saw people removing their valid reference usage because they had a memory leak they wanted to solve. As if introducing a race condition is the right fix for a memory leak! Some people have rather strange ways of fixing bugs.

What people who don’t want to care about it should do, and I agree with them, is to use Vala instead.(Or D, or Python, or C#, or Java, before I get hordes of language fans in my comments again. Oh! Or C++ with smartpointers too! - oeps, I almost forgot about the poor céé plus plus guys -)

Anyway, I’m sure my guidelines are not correct according to some people, as there are probably a lot of opinions on reference counting. In general I do think that whenever you pass an instance to another context (another thread or a callback) that you simply must add a reference. If you do this consistently you’ll have far less problems with one context finalizing while another context is still using it.

It’s a wiki page, I’m subscribed. You can just change the content if you disagree. Being subscribed I’ll notice your changes and I’ll review them that way.

http://live.gnome.org/ReferenceCounting

It’s not the first such item that I wrote down. Here are a few others:

After reviewing this document José Dapena promised me he’s going to make a page about reference count debugging in gdb, like adding watches on the ref_count field of instances. To make sure he keeps to his promise I decided to put a note about that here. <g>

Move In Day

2008-07-02T16:00:23+00:00

Yesterday we moved into the final home of ILXO, a slightly larger office just down the hall from our current location. The room we’ve been occupying for the past few weeks was just a temporary setup, meant to house us for the first few days before the office we’re actually leasing was available for us. Moving went fairly quickly taking only about 1.5 hrs compared to the 3 or so days of trips back and forth between Glenview and Chicago that it first took to move all of our things in.

We present the new home of ILXO:

It’s quite a bit larger than our previous space so we’re thinking we might use the space to host some small workshops over the next few weeks.

Also in the works at ILXO:

-Mel & I are working on a basic voltage regulator to allow XOs to accept various power inputs without frying the boards. We should have a design ready by sometime early next week.

-Mel’s cousin Melanie joined us yesterday and will be helping us out around the office over the new few days.

-We opened up our old oscilloscope yesterday and found a true relic of technology. The tracer on the machine currently isn’t working so we’ll likely need to replace the CRT sometime over the new few days.

-Nikki and Tank are working on putting together a repairs webcast. If you’re interested in learning how to safely take your XO apart, you should tune in at 3pm CT tomorrow. Details to follow soon.

Bit more maintenance work on OpenGLContext

2008-07-02T04:15:44+00:00

Doing a bit of bit-rot fighting in OpenGLContext this evening. Got the visual shell running again, so that you can load up a world in one window and type commands into another to modify the running world. Mostly was just updating to use wx 2.8 and the new loader structure.

Also took the time to begin reading up on the OBJ format. It's large-ish, nothing that doesn't seem to already be covered by OpenGLContext's subset of VRML (with the nurbs extensions), but way more work than I want to undertake without having some geometry to exercise the features.

Blender is built on this machine. Wings is failing to build due to erlang-sdl failing to build. I've always wound up put off by the need to memorize dozens of key-bindings to do even the simplest thing in Blender, but I suppose I should just go ahead and do it one of these days.

Dont upset the fearless leader

2008-07-01T14:09:00+00:00

What should you never do at fudcon?

Upset the fearless leader

Ask Me Anything

2008-07-01T08:43:39+00:00

When I’m giving a talk that doesn’t have a firm time limit, I like to end it with an Ask Me Anything™ segment, which I briefly described before:

That’s where I brilliantly field all questions I can answer, and make up incredibly convincing answers for any I can’t. (In the past, I’ve been asked about computer science, geophysics, abstract algebra, and British post-modern literary theory. Really.)

As an experiment, we’ll try to do the same right here. If you have a question for me, ask away in the comments. Ideally you would ask about things like systems security, programming, scalable systems and Python, but I’ll take humorous questions about education, technology, educational technology, math, British post-modern literary theory and just about any other subject. The questions you leave won’t show up below this post, but I’ll read them all and answer any interesting ones in a followup post. Bonus points for making me think, and don’t be shy. And please don’t ask why I’m so handsome — there’s just no accounting for good genes.

30th June, 2008

2008-06-30T16:09:59+00:00

Summer of Code Updates
Julen has been showing awesome progress with his SoC project. He has already completed implementing the first feature in the project roadmap, and his ideas on feature #2 looks excellent.
Going back home
Today, I go back home, after spending around two weeks in Cambridge. It has been an exciting and productive visit - I got the chance to interact with a lot of people, and to do a lot of brainstorming on some of the problems that have been bugging us, and my personal TODO list for the next few months seems to be quite interesting.
Some statistics
People often wonder about the exact number of OLPC XO-1 laptops out there. Till date,
Number of laptops shipped: 390,000
Number of laptops being built per month (currently): 50,000
That would be, I guess, one of the single largest Fedora derivative deployments out there :-).

XO-101

2008-06-30T03:37:55+00:00

We filmed our first webcast workshop on Friday. Admittedly, we were a bit lacking in audience, but we’re still trying to get filming techniques down. I don’t have a picture of our rig at the moment, but I ended up surrounded by the XO, camera, and my own laptop, each upon its own stack of boxes for height. It was interesting, to say the least.

Our work can be found here, at Ustream.tv - it covers the basics of connecting to wireless, downloading and running a new activity, and sharing an activity such as chat with another XO. (So yes, something aimed at new users.)

We’re scheduled to do one on Disassembly and Repairs this coming Thursday, which demands much better filmwork than our previous effort. I’d like to solicit advice for effective visual communication, keeping in mind that we are limited to a pretty simple webcam (no zoom capabilities) and a pretty low frame rate. Any clever workarounds?

Other 90% of OBJ files still pending

2008-06-30T03:36:22+00:00

Playing with the OBJ file loader for OpenGLContext this evening (briefly). Forgot to check in a number of fixes on Friday (oops). Anyway, as of now CVS OpenGLContext with CVS PyOpenGL can load OBJs from the internet via the (now somewhat inappropriately named) bin/vrml_view.py script. Still haven't found any samples where there's .MTL files (and/or textures) connected to the files. OpenGLContext should be able to process those links, but the functionality is still untested.

Anyway, with a little magnolia object that gets compiled to ~3000 vertex triangle arrays my workstation (with a rather outdated GeForce 7600 GS) easily renders at 100fps (capped render rate for OpenGLContext) with around 10% CPU usage (using VBO support). Obviously textures, colours and the like would alter the speed, but it doesn't seem slow enough to worry about it at this point.

As mentioned, I'd like to get something put together that's GPGPU-ish so that I can be sure we're really supporting the GPGPU operations. If you have PyOpenGL code that you feel provides a great sample of what people want to do with GPGPU in Python, let me know.

Things I'm curious about:

would it be useful to create an array wrapper object that tries to translate your numpy-like operations into a recipe to be executed on the GPU, or would you rather write the GL-level code yourself to have complete control? Or is it that both approaches would be needed?
would you want to handle "streaming" data for very large data-sets yourself, or have the system choose the largest available window and stream the data automatically? What kind of feedback do you need for this kind of thing, what kind of resumability is important (if at all)?
would you rather have the system kick out a low-level recipe to run on dozens of machines, or work interactively to let you play with the numbers, or both?
would you want the results to be computed as-needed, or to explicitly trigger their generation with a command?
would you want to integrate the operations with the iPython cluster operations, or are those generally different types of operation? i.e. would you need to scatter/gather your data-sets across many machines? If so, how automatic would you need it to be?

I'm sure I'll see a lot of the decisions the CUDA people have made when I poke into the pycuda stuff. I'm more interested here in what real PyOpenGL users would want from PyOpenGL to support their use cases. My assumption at the moment is that 95% of the GPGPU code shouldn't be in PyOpenGL, but I'm not sure if we need some 5% to make it easier to write the 95% externally.

Flackery

2008-06-29T15:21:47+00:00

Inexplicably, my e-mail address seems to have wound up on the distribution lists of a number of PR people, who are now sending me press releases announcing new hardware and software a few days before the news officially hit the wire.

There are lots of problems with this setup. Notably:

Since I didn’t ask for these releases, they’re unsolicited. Since they’re not addressed to me but mailed to a distribution list, they’re bulk messages. Since they’re transferred by e-mail, this makes them unsolicited bulk e-mail, which is the official name for spam. To say nothing of the fact that most of the e-mails include no obvious way to opt-out from future communiques.
These are press releases, so they’re written to absolutely destroy my chances of gleaning any useful information whatsoever about the product being discussed. This is by design, as press releases focus on explaining what industry the product will revolutionize and how it will increase leveraged synergies for the manufacturer instead of, you know, telling me why the hell I should care about the product.
Possessing no useful information about the product, and not having seen it since it hasn’t even been announced yet, what am I supposed to do with the “information”? Write or care about it, sight unseen, based on the press release?

So, new rules. I’m usually interested in both new software and hardware. If you want me to look at software you’ve built, send me a short technical description of why I should care, along with a link to a demo install if it’s a web app or a download link if it’s not. If you want me looking at hardware, send me the technical specs and tell me how, if you’ve managed to interest me, I can get my hands on a unit to play with — you can have it back in perfect condition when I’m done. In both cases, include the e-mail address of a technical contact, which is someone I can ask questions and expect intelligent technical answers. In neither case should you actually send me the press release itself.

Following these simple guidelines, dear PR people, will win you a reprieve from my spam filter despite the fact that you’re still sending me spam. Failure to follow them will, on the other hand, earn you a permanent date with said spam filter (he goes by “Bubba”) and cause me to report you to Spamhaus, your ISP for violating their terms of service, and inform the company you’re representing of your uncouth business practices.

Much love.

OBJ loader for OpenGLContext

2008-06-27T21:57:08+00:00

Have been working on PyOpenGL and OpenGLContext all day. Have redone the OpenGLContext loader module and ported the OBJ loader from pyglet over. The OBJ loader seems to work fine, but I didn't find any OBJ files that include material information to test that. I'm going to have to fix the face-culling, seems that the OBJ files are not always CCW. Should add "group" support too.

Added Vertex Buffer Object support to the ArrayGeometry class in OpenGLContext. Didn't seem to have all that much of an effect, so I tried profiling OpenGLContext rendering a big mesh (of a fish, incidentally)... and the actual rendering code (the OpenGL stuff) was totally drowned in the scenegraph overhead. That is, the actually pushing of vertices across the bus was nothing compared to the overhead inside the scenegraph. The scenegraph might be slow, but almost 99% of the total time? That just didn't make sense.

So I pulled out wxProfile2 (a hacked up version of wxProfile, which seems to have disappeared) and actually dug into the data (I was using raw Stats objects before that). Turns out that OpenGLContext's IndexedFaceSet object was re-compiling the array-based geometry for every frame, the recompilation is extremely expensive compared to redrawing (because it has to deal with the very general VRML97 model). Fixed that and frame-rates jumped by a factor of 10 or so.

We also got PyOpenGL (and OpenGLContext) tested under Mac OSX 10.5 (Leopard) on a PowerPC Mac G4. A few issues in OpenGLContext, but PyOpenGL seems fine. All in all a very productive day. There's going to be some work to do cleaning up client code that used OpenGLContext's old VRML-specific loading interface at some point, but that's not for today.

Exploded XO Design

2008-06-27T16:27:58+00:00

As someone running a repair center, I often find myself wishing I could test parts easily. While I can teardown an XO in 10 to 15 minutes (and put it back together in another 10), this is still a significant amount of effort per XO, especially tearing down both machines and keeping track of all their parts. This has sparked a lot of discussion about making “exploded XO” systems that could be used to quickly swap parts in and out and run diagnostics on them. This is particularly valuable for determining the status of components in a nonbooting macine, as well as helping determine why a machine won’t turn on.

To that end, Andrea and I started prototyping ideas for an exploded XO stand. We started out with cardboard, although the design we came up with would probably be easier to make out of plastic (it’s cheap, and we can get it laser cut for free during the school year). We started with a fairly simple design, just making a stand to hold the keyboard and touchpad, and another slotted stand for the screen and motherboard. Pulling the cables connecting the two halves out of the hinge frees up space and weight, and allows the pieces to be moved around easily for quick swapping. We even pulled the battery connector out of the molder plastic (it unscrews nicely) to test batteries with the rig.

Making the stand for the keyboard.

Finished keyboard stand!

Since the weight of the keyboard holds everything together on the stand, we only need 2 screws to hold in the board (for speed).

Next we cut out stands for the screen and motherboard.

Our finished rig.

Obviously, this is a first-gen prototype, so there are a lot of ways to imrove this. Going forward, we’d like to come up with a CADed model that can be lasercut from sheets of plastic, and another one that can easily be made from cardboard (we’re looking at a shoebox idea right now, since that would be about the right dimensions). We’d also like to add a better way to hold the battery, proper insulation for the pieces in contact with the motherboard, and a side stand for peripherals like speakers, microphone, and wireless ears.

Open house

2008-06-26T18:17:08+00:00

Yesterday was the ILXO open house.

Yes, this means we have an office (thanks to Kevin and Sheila for scouting out locations!) We’re at 200 S. Wacker Drive, on the 31st floor, literally across the street from the Sears tower, in a tiny room with no windows and what we believe to be the only speaker system in the area. Then again, we also appear to be the only group in the area that wears tshirts instead of suits…

We now have fewer broken XOs and more working XOs, thanks to two 10-year-olds who came in yesterday, grabbed some screwdrivers (and gummi bears), sat down with Nikki Lee, and set to work swapping out a broken screen. XOs were reflashed with latest stable builds, the hand-crank was cranked, and several events started popping up on schedules after animated discussions with community members who stopped by.

In the works:

a Game Jam - tentative dates are set for July 11-13
a Teacher Jam - either on the 12th or 19th of July
a series of hang-outs/playdates for children with XOs (and children without XOs - this is why we have loaner machines at the office) to get together and explore. These will be hosted in various locations across the state, usually in backyards and living rooms and basements

More vaguely in the works:

a math workshop, probably in Evanston at the end of July or the beginning of August
community testing of build 708 during the month of July
And more

In order to break in our new electronics workbench (magically stocked by a wonderful anonymous donor), Chris built up a voltage regulator - the white things on the board are wire-wrap resistors (you may laugh, but they’re what we had).

I also discovered that when no hammer is present, the base of a set of helping hands will suffice for assembling shelves; it is heavy, hard, and can jam tacks into particleboard with no apparent damage to itself. These bookshelves are now filled with books (thanks to O’Reilly) and XOs (thanks to OLPC, who loaned us a batch of 20 for the summer to use for workshops, gatherings, and projects).

In general, the office looks like this - the photograph is representative of both the side (small) and chaos (high) within the area, although it’s gotten more quirky since we picked up our inflatable hedgehog chair-cushion.

More photos are available here.

Where is OLPC today

2008-06-26T17:54:00+00:00

Where is OLPC today?

Building and Shipping 50,000 laptops a month. Each and every one of them running Fedora. so far there has been over 390,000 laptops shipped. Which im guessing is the largest single Fedora Install base. Thats kinda mind boggling to realise. Going forward over half a million will be shipped in the next couple of months

What can Fedora do here?

Make the suagr experience in Fedora better. We have Packaging guidelines. we have a ton of Activities. Lets get them into Fedora. Lets look at what packages OLPC forks, work out why, and work out how we can eliminate that need. switching from Fedora 7 to Fedora 9 we pulled in an extra 100 packages. That needs to be cut down. There are needs on the school server. If you can give a little time to help out and want to know what else you can do contact me. I really want OLPC and Fedora to work better together.

Big day for Modest and Tinymail

2008-06-24T16:58:48+00:00

Quim Gil announces why.

It’s a little bit frightening … I guess quite a lot of people will now start using our code.

I’m also proud of having been involved with such a great team of software developers working on Modest and Tinymail.

I think I succeeded at creating a healthy free software project suitable for both commercial and purely free software appliances. People are contributing for and from different angles. Different companies are involved. I am trying to blend the contributions a bit more in order to get more “passion contributions” rather than “just the minimum must work, here’s a quick-fix”-patches. It’s improving, though.

Nokia (however) gave me ‘the’ opportunity to create Tinymail. They allowed me to work on it full time for more than a year. Everything was always immediately free software, and happened completely in the open too. Go check if you don’t believe that.

You can accuse Nokia of a lot of things, but they did great at fostering several free software projects. They made mistakes, of course. In my opinion, the handling of this project was done in a very healthy way: very open minded and very much the way free software can be commercially successful. I hope they learned free software won’t do wonders but that it can help you finding experts in specific fields, working together on the bigger picture: the actual consumer device. Working together with free software inspires a certain kind of passion among engineers. Capitalizing on that is fine, as long as you have respect for the passion. Just like the engineers have respect for the passion of solving the problem of producing and bringing millions of devices to the customers in time. Both enemy and friend know no company can do this better than Nokia.

I don’t think there’s anything controversial in respecting the hardware dudes’s jobs. In the end we humans are all about our passions.

I didn’t succeed at making a release before Modest was thrown to the Maemo users. That should happen very soon now, though. I’m very much in agreement with that “release often, release fast” - meme. But I also only want to call something a one-point-zero if it’s really stuff that works, behaves as expected and has all API that people’s E-mail clients require. The problem is that as an engineer I’ll never think that any of my software is finished. Everything can be better. Living near Eindhoven I grew up with the slogan “Let’s make things better“. I agree with the meme in that slogan.

Neither did I reach a bunch of technical goals. I have so many things in mind that would make Tinymail based E-mail clients by far the best kind of mobile E-mail clients ever created. Although Polymer, damn you Dave Cridland! :-), makes it hard to really be the best. Subjects ranging from pipelining to supporting CONVERT, forward without download, streaming media as attachments, and many more. IMAP has a few interesting limitations that I would like to address too, like Lemonade does. And then you have the IMAP servers … grmbl.

Regretfully a lot of people think of E-mail as a simple subject. They should figure out then why so many teams have tried to write good E-mail clients, yet relatively few succeeded. I’ll spare you the details and I’ll just point out that a lot of ’stuff’ is involved that you won’t expect. But really, if it wasn’t a challenge, I wouldn’t have been interested anyway. I’m not complaining, I enjoyed and I am enjoying a hard task ahead of me.

Meanwhile, I enjoy working on Tracker for Nokia. It was time for something different. Incubation time for Tinymail, perhaps? I’m working a lot with SQLite, who knows what will come out of that symbiosis? Perhaps I learn that it’s not suitable? Perhaps it is? I haven’t had the chance to explore cursors in SQLite. That’s what I’d be interested in most for things like Tinymail.

I should stop thinking about it too much, before I end up hacking until eight in the morning again.

One Heckuva Nice Guy

2008-06-24T04:22:10+00:00

Bernie Innocenti arrived in Kathmandu a week ago and he has changed the OLE Nepal office in so many ways. For one thing, this guy knows linux inside and out, in so much more depth than anyone else on the team. He has already made a big impact on the sysadmin team by showing us how to set up LVM RAID 1 for our E-Pustakalaya (E-Library). He is teaching us about Sugar and helping us optimize our activity performance.

Sometimes, I get the impression that Bernie can do anything and knows everything about linux. Yesterday, I had a problem with Apache and I told Sulo “I was going to consult with the Oracle,” Bernie.

He not only is darn helpful but is a super nice guy. It truly is a pleasure to have him hear. The guys in the office are already trying to figure out how to match him with Miss Nepal 2007 so he will stay here longer. Word on the street is that she likes Linux and C

Try to get some time to play with PyCUDA

2008-06-24T03:06:41+00:00

Nvidia's got a GPGPU library called CUDA. There's a Python binding. Thinking it would be interesting to try it out if I can get some time. It's a C++ wrapper, looks reasonably elegant and seems to integrate nicely with numpy (just going by the documentation).

Not that I actually have anything to do with the GPGPU at the moment, I just think it would be interesting to learn.

Ubuntu rejects Soni's old Machine

2008-06-24T03:01:06+00:00

Have a rather nice older machine here, P4 with a reasonable video card and memory. Should be a kick-arse Linux machine for our niece and nephew. Except that Ubuntu can't seem to see the disks. It's nothing special, Asus P4P800 SE motherboard with an Intel IDE controller. Should be dirt-simple, but the disk is just are not showing up as a device with any BIOS settings I try.

Guess I'll have to give into the dark side and re-install the (corrupted, infected, ridiculously slow) XP it came with.

Upcoming travel

2008-06-23T14:38:17+00:00

I’m off to Vancouver tomorrow to keynote the 20th annual FIRST conference, where I get to tell a bunch of smart security people that we’re massively screwing the pooch as an industry. It’s great fun. In fact, I’m pretty sure I’m becoming the official boogeyman of the security conference circuit — costume ideas appreciated.

Anyway, if you’re in Vancouver, New York, Helsinki, Concepción (Chile) or Barcelona in the upcoming months — see the handy-dandy talk list — and want to grab a beer or commiserate about the world, the human condition, and the heart-breaking ennui of it all, send an e-mail. The boogeyman will oblige. First scare is free.

Frame Buffer Objects are Easy (ish)

2008-06-22T06:02:35+00:00

Felt a little under the weather after a good party (apparently I picked up some soy, which I can't digest well) I decided to learn a little bit about Frame Buffer Objects in OpenGL. These are the new system that allows you to do "off screen" rendering and "rendering to texture" behaviours. Turns out they are a rather elegant, simple system. Whereas I'd always been scared off by the messy platform-dependent pbuffer system, FBOs are simple and reasonably portable.

I only hit one "gotcha" while following through this C tutorial in PyOpenGL. The tutorial mentions the gotcha, but doesn't draw the line to the problem you encounter if you the leave the operation out. The setting of image parameters is required. If you don't do it you will likely get an unsupported format error when you check to see that your FBO is "complete" (ready to render).

Anyway, the test code is in PyOpenGL CVS if you want to take a look (test_fbo), the tutorial linked above is very good about walking you through the logic and background of the extension. I'm guessing that GPGPU people would want a wrapper around the FBO setup code for doing their calculations, probably want something for day-to-day use in any system.

Not sure that belongs in PyOpenGL, however, as the API is already pretty straightforward. Might want to wrap up the check for completeness in a convenience function that explains the enumerants more humanely though.

OpenGL Vertex Buffer Objects (VBO)

2008-06-21T01:54:30+00:00

Only had 1/2 day to work on PyOpenGL today (client needed work done this morning), so just played around with the Vertex Buffer Object (VBO) extension. In particular I added support for mapping data into the arrays and automatically deleting the arrays if the user forgets to do so. For those following along at home...

What are Vertex Buffer Objects?

As you will recall from PyOpenGL 101, there are two major approaches to speeding up PyOpenGL code. Both can be thought of as 'push the data as close to the hardware as possible'. The first approach is to use display lists, the second to use (large) arrays of contiguous data.

Display lists are mechanisms that let you run your client side (i.e. Python or C) code in a special mode where the GL records the set of operations performed. When you want to replay that sequence of events, you can tell the GL to replay the entire sequence with a single command.

The GL can optimize the operations within the display list if it knows how, but I don't think there's all that much optimization done on current hardware. That said, display lists can be wickedly fast for static models and let you use whatever exotic algorithms you want to generate the model. You can use low-level GL primitives (glNormal, glVertex, glColor, those present in OpenGL since 1.0) which are easy for new OpenGL programmers to understand.

The second major approach to speeding up OpenGL code is to make use of large arrays of homogenous data. This approach was introduced in OpenGL 1.1. It sets up Single Instruction Multiple Dispatch (SIMD) data-streaming operations to process your model from arrays of data-points to sets of graphics operations. It is especially effective in the most common case where your pieces of geometry are composed of extremely large numbers of elements which are all treated in approximately the same way (think higher-resolution modern models).

Particularly with PyOpenGL, the use of array-based data lets you avoid the cost of the large numbers of primitive OpenGL calls associated with creating large geometric objects in the "traditional" (OpenGL 1.1) form. A given PyOpenGL function call is likely 100 to 10,000 times slower than the equivalent C call, so defining geometry with 100s of thousands of data-points can be ridiculously slow using primitive OpenGL calls.

The SIMD approach amplifies the effect of each OpenGL operation. Array-using code is able to minimize the overhead of running in Python considerably. By pushing all of our data into a couple of large arrays we can reduce the Python overhead of rendering even extremely large scenes to a couple of function calls.

Interesting note; OpenGL-ES, the spec for lightweight mobile implementations of OpenGL is entirely array-centric. If you want to develop for the iPhone you better learn the array-based approach to OpenGL. It seems that with arrays we have solved all the problems of OpenGL (yay!).

Problem Solved?

In OpenGL there are two sets of code which are communicating, the client code (the code you write) and the GL. The GL is normally implemented as a mix of software (driver) and hardware, with modern cards often having extremely advanced hardware implementations that can churn through vast amounts of data and have almost as much memory as the host system.

Display lists, textures and rendering areas are all stored in the card's hardware memory whenever possible. Only if they exceed the memory available are they stored in the GL's "software" buffers. Whenever data is available only in the software buffers the GL has to transfer the data each time it is rendered across the graphics bus. Even though this bus is normally the fastest peripheral bus in your system and has special operations to help with the sharing and streaming of data (the acronym AGP referred to such a mechanism), transferring large amounts of data across it is going to limit your rendering speed.

This is why your cards are constantly growing more and more memory. You want to avoid copies across the graphics bus as much as possible. You want to make sure that as much of your data is over on the card as is possible. Polygon (vertex, colour, normal) data was not in OpenGL 1.1 times, however, normally stored on the card (other than in display lists).

In OpenGL 1.1 times, the bulk of the space for your world-models was in textures, so it makes sense that one of the first things to move to the GL's storage was textures. At the time, models would be a few thousand polygons at most, as that was about what cards could chew through in terms of textured polygons. Those same models, however, might have a couple of megabytes of textures to be applied.

There might have been a few hundred KB of data in given scene's polygonal data (and that only if full precision models were used). Compared to the bandwidth and memory consumed by large collections of textures, the polygonal data was just noise, so there was no reason to complicate the hardware by storing the polygonal data there.

As a result, with the OpenGL 1.1 (array-based) approach, you would transfer your few hundred KB of vertex data across the bus every time you wanted to render a model. This meant that you could modify your array-based data in memory as the next time you sent it the new data would be transferred. Compared to (static) display lists, this made array-based data the natural choice for frequently updated geometry.

Why Vertex Buffer Objects Now?

Graphics processors have advanced a long way since the days of OpenGL 1.1. Today's high-end implementations are capable of rendering meshes with around 10 million vertices. While they can process meshes with millions of vertices, with OpenGL 1.1 style arrays the (uncompressed, full-precision) data required to represent millions of vertices would be hundreds of MB, needing to be tranferred ~60 times per second across the graphics bus. That is, while graphics processors can process vast amounts of vertex data, they can't access it fast enough if we use traditional OpenGL 1.1 array storage.

The VBO is another example of moving data over to the graphics card as much as possible. In this case, we move the (now very large) vertex data to the card then tell the card to use the stored data instead of client-side vertex-sets when we want to render our geometry using array-based operations. This is the same basic operation we've done with textures and display lists. We store the data on the card with an ID for later reference and trigger its use when we would normally re-transfer the data.

However, recall that arrays have commonly been used for dynamic data. That is, we often want to change the data in a model. Consider for instance when we want to make our character "bend" in a game to take a bow. We want to remap (normally a portion of) the data with new locations, preferably without having to re-transfer the whole data-set (colours, normals, texture coordinates, the unchanged vertices).

To support this kind of usage, the VBO needs to provide a mechanism whereby the client code can (cheaply) update portions of certain VBOs (just the dynamic ones). VBOs handle this by allowing you to either "map" the current contents into memory (get a pointer to the data which you can manipulate as you wish) or by allowing you to transfer portions of the data to replace parts of the current data.

What VBOs Look Like

VBO code looks pretty much like regular OpenGL 1.1 array-using code. You build the same arrays (e.g. with Numpy), but instead of passing the arrays into PyOpenGL, you set up a VBO and load the data into it:

id = glGenBuffersARB(1)
glBindBufferARB(target, id)
glBufferDataARB(target, data, usage)

where target is basically one of vertex data or index data and usage is an enumerant telling the system how often you intend to update the buffer (static, dynamic or streaming) so that it can decide where/how to store the data.

When you want to use the data, you bind the buffer again and then pass 0/NULL to the OpenGL 1.1 array-drawing code as the data-pointer for your array.

glVertexPointerd( 0 )
glDrawElements( GL_LINE_LOOP, len(indices), GL_UNSIGNED_INT, indices )

unbinding the vbo after you've finished drawing your data.

If you want to update a range of your vertex data, you can use:

glBufferSubData(target, start, size, dataptr)

which maps a range of raw data (bytes) into your array in the GL. You can also map portions of the array data into your application's memory space by using:

glMapBufferARB(target, access)

Though to be honest I still haven't figured out what to do with this other than reading the value out, which might be useful for pixel data, but doesn't seem as useful for the vertex data.

What am I doing with VBOs in PyOpenGL?

At the moment I'm really just playing around with possible APIs to make an elegant, Pythonic API that integrates nicely with PyOpenGL. It makes the VBO look like a regular FormatHandler type, that is, a type of thing in which data is stored, similar to Numpy arrays or Ctypes arrays/pointers. You define the VBO by passing in a data-array, you update portions of it with slice assignment, you pass it as the argument to e.g. glVertexPointer. When you delete the VBO object the VBO is deleted on the back-end.

Originally (last week) I had the VBO automatically binding itself when you got its data-pointer, but that just seemed too "magic-y", now you have to manually bind your VBO by calling its "bind" method and unbind it with the unbind method.

I still need to do some work with frame buffer objects (textures to which you can render) to see if there's code that wants to be shared. I also need to see whether providing a mapping api is useful for something in PyOpenGL.

I've very much a newbie with VBO usage, so I'd love feedback from heavy VBO users on what you need in an API. The OpenGL.arrays.vbo module isn't likely to suit every project, but I'd like it to be a fairly generic mechanism that lets the beginning PyOpenGL developer use the feature without too much effort and with maximal benefit.

The current code is available in CVS.

ILXO exists!

2008-06-20T20:39:21+00:00

We’ve been busy of late - The past week and a half was filled with Grassroots Bootcamp, Grassroots Jam, and getting moved in and settled in Chicago. We’re still working on the latter, but, as Nikki says (and, as much as I hate resorting to cliched statements) — we’re going to have to hit the ground running.

Can I say that last week’s grassroots events have prepared us for our own little start-up? I’m not sure - I’d say we’re far more acutely aware of the infrastructural problems within grassroots groups. We have plenty to learn about the business-side things of running an office - management (both of people and time), planning (something very much not in my nature, and yet, I’m charged with workshops — we’ll see!), communication, and so on. Let’s see, then, if we can stick to our not-to-do list

I’ll admit, I’ve been super lax about noting our problems and successes as we’ve been going along. It seems silly, after all, to write down all the small things we’ve been up to - however, I’m sure other small groups wouldn’t mind having the reminders, for example, to look into vehicle registration procedures (beauracracy has delayed the reunion in our group, after all). It’s an easily overcomable obstacle, but the little things are inconvenient, and it’s times like these that I often wish we had some sort of model to follow for guidance. Then, I remember - oh wait, that’s one of those things we’re doing this summer.

We’re not useful guinea pigs unless we have useful record-keeping. (Compulsive documentation is slowly being drilled into me…)

Major lesson two? The importance of structure. As much as I loved having freeform problem-solving time at Grassroots Bootcamp, it also allowed people to get stuck on their own personal agendas for the week. I don’t doubt that progress made on those projects was valuable. For example, fixing the pathways for community and newbies to OLPC (social networking, wiki structure, etc) is necessary, no question - I just wish the emphasis during the week hadn’t skewed so heavily towards it. However, I feel like the event from a whole could have benefited from more adherence to its original plan to include as much diversity of topic in regards to grassroots groups as possible.

The Pilot-in-a-Box project at Grassroots Jam was also impeded by, again, the lack of unity in personal agendas. We outlined goals for weekend, though those were broad enough to leave room for a variety of interpretations. Again, lots of great ideas were generated - but in terms of producing any sort of cohesive whole, we didn’t necessarily have a unified sense of purpose, much less direction.

Which, of course, brings me back to ILXO. We’re slowly generating structure - the off-grid power project has a set of tangible outputs we want by mid-August, workshops are coming to life, the Chicago office is unpacked (if lacking in decor), etc. We still have quite some ways to go, though - Workshops, for example, still need a timeline and concrete outlines for the sessions. We need to figure out how to advertise/promote our organization. We need to figure out how to get to downtown Chicago most cost-effectively. We need to prove our credibility to the community.

So, my question is - how does one balance delegation and group work? The above are all things well within the capabilities of one person. However, the decisions have impacts beyond that one person. Maybe it’s because I’m the young’un of the group, but I don’t feel comfortable singularly representing ILXO in such capacities, and waiting for feedback from all members hurts our efficiency (essential for a two-month venture!), even among only four people.

As we’re starting to move into physical-implementation-of-our-office territory, I think we need more internal structure. I’m not sure entirely what that’d consist of - likely timelines for projects, concrete and tangible goals, increased use of our task tracker. Any more seasoned grassroots people have any advice they can throw our way?

And just note - the grassroots events may have had their own flaws - but I wouldn’t write them off for those. It was pretty amazing — not to mention, inspiring — to see what people have gotten up to, often with very little initial structure or resources. This whole start-up thing kind of terrifies me some days, but interacting with others and hearing their stories re-opens ones sense of possibility. I love it.

I spoke to a family friend last night - he joked, “Hey, why are you trying to change the world already? It’s still my world, you know - stop trying to make my generation obsolete!” Hee. Youthful idealism and our newfangled ideas :)

Office pictures will soon follow.

unmadindu -> 1CC

2008-06-19T14:50:36+00:00

I am visiting the OLPC offices at Cambridge, Massachusetts for two weeks. The CCU->LHR->BOS flight was a bit painful (around 26 hours, including the wait time at Heathrow), but apart from that, things seem to be in an excellent state.
Was quite shocked to see this in the dev_at_l10n.openoffice.org list, glad to see that things have been sorted out.

Introducing 3 new members of the OLE Nepal Community

2008-06-19T13:02:09+00:00

This week, Bernie Innocenti, Sunil Pokhrel, and Uttam Sharma joined the OLE Nepal Community. They are all extremely talented in their various fields, and welcome additions to OLE Nepal.

Bernie, as you may be able to tell from his last name, is from Florence, Italy. Bernie is a self-described geek, and will be with us until the end of August.

Bernie is something of a computer guru, and admits that computers are his life. He enjoys breaking computers (hopefully only his own), only because he likes to fix them afterwards. Beyond his talents with hardware, Bernie is also a programmer. While he likes all programming languages, when forced to choose one, he chose C as his favorite. This week, Bryan has been especially thankful to have his help with RAID.

During his time here, Bernie hopes to help build a bridge between real-world deployments and sugar developers. In his free-time, Bernie likes traveling around the world (and has actually traveled all the way around the world), both as a volunteer and for fun.

Sunil is from Lubhu, Shankadevi, Lalitpur, Nepal. He attended St. Xaviers in Kathmandu, and has spent the last eight years teaching classes 7-11 in Nepal. While here, Sunil will develop activities and curriculum for the software developers to create for the XO. He hopes to contribute good activities for poor Nepali kids, and is very interested in showing the benefits of OLPC and ICT education deployments.

In his free-time, Sunil enjoys hiking and walks with his son, Subodh. He is married to Kabita Pokhrel.

Last, but not least, Uttam, who is from Pokhara, Nepal, comes to us from the University of Minnesota. He earned a Bachelors Degree from Brandeis University in Massachusetts, a Masters from the University of Maryland, and is currently a Doctoral Candidate at the University of Minnesota, in the field of Applied Economics. Uttan will be conducting an evaluation of the initial deployment at the two pilot schools during the next two months. While here, Uttam hopes to gain a better understanding of how the OLE deployment is working, how it is percieved from within and without the program, and which areas are in need of attention.

In his free-time, Uttam enjoys surfing the internet when not studying.

-Doug

�

Explaining Complex Things

2008-06-19T05:17:12+00:00

We went to the last Cafe Scientifique of the season in Toronto tonight. Topic was a fairly generic "the future of medecine". A bit disappointing in that the focus was all on the ultra-high-tech possibilities that might or might not show up. That is, it was all about reactive medicine, rather than proactive. Nothing substantive about movements to improve people's diet, exercise programmes, mental-health or happiness; all things that are far more likely to keep you alive and healthy than any given miracle cure costing as much as a large scale educational program in the schools.

Was struck by an interesting thought as I sat there. Wasn't the science fiction writer (on the panel) really just a person who was taking complex (often technological) concepts and helping people understand how they relate to their lives and society? I know, I know, I tried my hand at Science Fiction before and came up rather short... still, an attractive thought to toy with as I'm finishing up my 12 billable hour day and contemplating getting up in 5.5 hours to charge into another long day of mucking about with (ick) C++.

Biggest problem is that 90% of the time you wouldn't actually get to talk to people... I want to talk to people, not sit in front of a computer.

Grassroots bootcamp recap

2008-06-17T00:16:15+00:00

The first OLPC Grassroots Bootcamp ran last week at Boston at OLPC headquarters - thanks to all who attended, presented, and participated and helped us build community infrastructures, share best practices for grassroots movements, compile a list of Grassroots problems to work on, flesh out a Volunteering process, flesh out the role of ...

Grassroots bootcamp, day 4

2008-06-16T23:12:41+00:00

Technology was the focus of the last day of our 4-day grassroots bootcamp, kicking off with a school server (XS) installation walkthrough led by Ankur Verma, Dan Drake, and Chris Carrick. Disassembly, repair centers and repair kits, how to write funding proposals, and more were covered in side conversations throughout ...

Grassroots bootcamp, day 3

2008-06-16T23:12:41+00:00

Bootcamp day 3 is done!* See: http://wiki.laptop.org/go/Grassroots_bootcamp/Results Highlights include: Feedback from Tuesday's classroom roleplay - next round, we need to find a way to actually work with kids during the bootcamp. This time around was tough because of end-of-school-year scheduling and during-the-day bootcamp timing.Pre-luncheon guests Kim Quirk ...

OpenGLContext Updated to wxPython 2.8 (finally)

2008-06-15T23:09:28+00:00

Finally got around to fixing my wxPython install on my workstation. Turns out you need to do an "eselect wxwidgets" operation to get the wxPython links to set up properly. With that done, updated the OpenGLContext wxPython context so that it works with wxPython 2.8.

That lets the "browser.visual" module work again. This is a cheap little hack that tries to create a vPython-like environment for writing "my first 3D world" scripts. Under the covers the world is actually a VRML97 environment (though it uses simplified custom nodes) and you can load any VRML97 code OpenGLContext can handle into your context.

Continue reading "OpenGLContext Updated to wxPython 2.8 (finally)"

Programming Limits

2008-06-15T22:48:57+00:00

Work with old, large systems enough and you start to get a persistent feeling of Deja Vu. Get large enough and you always seem to grow a set of features that is almost like every other large system, just implemented in a completely different way so that code sharing is simply impossible.

How many file-system abstraction mechanisms have we collectively written? How many inter-thread communications mechanisms? How often have we re-implemented configuration management, object-relational mappers, caching, indexing, page-layout, and hundreds of other big sub-systems?

When you're starting out, it's just too much work to figure out the "other guy's" byzantine system for handling almost every possible corner case of the problem domain. You only have to do this one thing. You'll never need all that. You can just code up what you need and be done in a few hours instead of spending days or weeks learning how to debug the huge mass of meta-programming in someone else's system.

So you roll your own and it works. You're an elite hacker. Maybe you even pat yourself on the back for having avoided a dependency. Then the customers ask for one more feature. No problem, a day at most. Another, a bit bigger, you refactor the codebase and now it's elegant and ever so much more general. A few years along, you are the (proud?) owner of a byzantine system that handles every possible case except the 5 that the other system handles. Unfortunately, with completely different substrates and totally alien structures, they can't be used together or even talk to each other, so some of the people use yours, some the other, and the potential pool of devlopers and users is halved.

I'm wondering (more throwing out a straw-man) if the problem really is one of documentation? If every large system came with two pieces of documentation:

Documentation that let another meta-progammer (the type who could create such a system themselves) sit down and figure out all the corner cases from a set of principles and rules, something that let you understand the totality of the codebase and walked you through the exceptions and caveats until you could predict what would be in the code base as easily as you would your own code.

Documentation that exhaustively linked to (runnable, tested) code examples for accomplishing every common (and uncommon) task. It could be backed by some sort of Trac-like system so that every bug report, every mailing-list post, every question that came up was turned into a runnable test/example, with people able to push new examples in...

Would it be enough? Would anyone care? I know the second would be very useful, most programmers seem to start off with copying code samples and altering them to work for their purposes, so maybe it would be enough. Maybe the first document is really a red herring, something you pour your work into, but which isn't necessary, because the people who really want to hack on the code have already got some investment and want to know how to make that one needed effect happen. Maybe it's the code library that needs to be front-and-center to make your library pull people in and avoid having the other systems split the community.

Or maybe the Romans had the right idea, and the beauty of each thing is the thing itself, not the Greek ideal shining through from some platonic realm. Maybe each large system's implementation of the dozens of similar sub-systems is what makes the whole magical.

Canadian DMCA

2008-06-15T04:11:20+00:00

Won't spend much time on this, since others are covering it far better than I. Suffice it to say that if you are Canadian and don't want to let the government sneak in a major trojan horse to take away your freedoms you probably want to look into the new bill that has been introduced. It's apparently pretending to be giving all sorts of rights while taking them away with the fine print. Michael Geist is covering it extensively.

Guiding Hands

2008-06-15T03:29:32+00:00

Interesting chat with one of our friends this evening. We were batting around the big problems of the day; energy crisis, resource exhaustion, pollution, that kind of thing and looking at the various solutions proposed and possible.

One thing kept coming up, namely the fact that as energy prices soar, alternatives become more affordable comparatively and more time and interest focusses on solving the problem. Which sounds a lot like the magical guiding hand of Adam Smith taking care of us, if only we would be dispassionate voracious consumers interested solely in our own narrow self-interest.

Indeed, a lot of the issues, such as localizing production, encouraging more efficient usage/technologies, and lots of other necessary tasks are all addressed by the increasing cost of oil. So we don't have to do anything, apparently. After all higher prices and decreasing supply of oil (the peak oil theory) might force consumers to really solve the issue of climate change, to address it with hard choices that might actually impact their lifestyles and make a real difference. Things such as driving less (or not at all), buying locally produced produce rather than that flown in from other countries, and using less energy. Once again, lassez faire economics solves a thorny issue in the most efficient and effective way possible, or so it would seem.

What's missing, though, is agreement to prevent alternative, just-as-bad (or worse) technologies from showing up as solutions to the "problem" of high oil prices. That is, the guiding hand may very well discover a solution worse than the original problem. Particularly when we do not have an economic cost associated with pollution, the market does not attempt to optimize out the pollution. Of course, that's what the cap-and-trade proposals are about, making the cost of pollution visible to the market forces. How successful they could be remains to be seen.

Cryptographic Nonsenseware

2008-06-15T01:48:52+00:00

A new malware variant by the name Gpcode.ak has been raising eyebrows in the security community. Upon infecting a computer, the trojan will encrypt the user’s documents, leaving a text file which demands money in exchange for a decryption key.

There are no new ideas here: encryption malware has been around for the better part of a decade, Adam Young and Moti Yung wrote a book about cryptovirology in 2004, and even Gpcode itself has been around since 2005, albeit with a far more primitive approach to encryption that the current incarnation.

The latest instance gets the crypto mostly right: it creates a unique 128-bit RC4 (Arcfour) key on each machine and uses a random initialization vector for each file it targets. The IV is written to the beginning of the file, encrypted by the per-machine key, run through MD5, and the output constitutes the per-file key, used to encrypt each file with RC4. At the end, the main per-machine RC4 key is encrypted with a 1024-bit RSA public key which the malware carries within its payload. The malware author can then send a tailored, per-machine decryptor to folks who pay up.

If you keep backups, you can obviously treat this attack as a simple data loss scenario. And if you don’t have backups and badly need the files back, you have no option but to pay: when used correctly, cryptography works. In their encrypted form and without the RSA private key, the files are as good as garbage. Anti-virus companies have no technological defense against this, can’t make any, and are being appropriately forthcoming:

A security company on Friday asked for help cracking an encryption key central to an extortion scheme that demands money from users whose PCs have been infected by malware. … “Along with antivirus companies around the world, we’re faced with the task of cracking the RSA 1024-bit key,” said Aleks Gostev, a senior virus analyst [at Kaspersky Lab].

See? Completely reasonab… wait, what? Factor the key? Seriously?

Arjen Lenstra and Eric Verheul estimate that, in 2009, a machine that can factor a RSA-1024 key in a day would cost $250 million. With a massive cluster of regular computers, such a computation would take years. And it gets better: 2048-bit RSA keys are considered impractical to factor before the year 2030, while 3072-bit keys are likely to provide protection beyond then. Do you see where this is going?

Even if the present key is factored, it’ll take the malware author mere minutes to generate a stronger one, insert it into the malware payload, and send it on its merry way. And we won’t be able to factor that one.

In fact, focusing on the cryptography in the malware misses the point entirely. What the malware is exposing is the far simpler fact that our desktop security systems are fundamentally broken, as there is no reason that a piece of malware executing silently in the background should have access to a user’s files without interaction or approval. If file access was securely brokered, we wouldn’t have to care about the crypto.

We know how to build desktop systems that are both drastically more secure and more usable than the ones in use today. Prototypes like CapDesk and Polaris demonstrate this on mainstream systems, while my own Bitfrost does so on the OLPC laptops. You won’t see ransomware on the XO-1.

When it comes to Gpcode, factoring the RSA key is the dumbest possible course of action. I know it, the security community knows it, and Kaspersky Lab knows it. It’s a press gambit, and one that I found distasteful at first. But I’ve come around: it grabs headlines, and maybe a proliferation of headline-grabbing, panic-sowing, fear-inducing threats like cryptoviral ransomware is exactly what’s needed to overcome inertia from operating system vendors and finally move us towards a more secure desktop.

Much love, Kaspersky Lab. Let’s go factor some keys.

Uncle Vanya

2008-06-14T02:58:40+00:00

After work we went to the distillery district to see Uncle Vanya. It
was enjoyable, though I found the motivations post-intermission were
hard to empathize with... pre-intermission I was really identifying
with the characters, they seemed human, dreaming of a better world, but
trapped in the mire of the day-to-day.

We want to make the world a better place, we dream of doing great things, yet day to day we slog away on the trivial affairs of life. There's always the fear that maybe we'll get to the end and find that what we've done was of no consequence, that we were supporting the wrong ideal, or helping someone who didn't deserve our dedication.

We chafe at the day-to-day restrictions imposed by the need to find food and shelter, afraid that we will spend our whole life grubbing in the mud. We know it's wise, yet we want to throw it away and make the big gamble, follow the dream and become the most that we could be, and so we regret the life we live. So is it really wiser to be afraid to follow your dreams? Or is it wiser to follow them and love the life you lead.

PyOpenGL 3.0.0b3 without a Jukebox

2008-06-14T02:50:08+00:00

Spent the day mostly on PyOpenGL. Released a new beta3 of 3.0.0, mostly just a bug-fix release. Also hacked up a test/demo of a vertex-buffer-object data-storage mechanism that seems to work quite elegantly.

I was intending to build a Celestial Jukebox... then I actually sat down and described it to Dave at the caffe. He's ridiculously positive about all things cool and tech... and he didn't bat an eye at it... along with two other complete yawn-responses made me realize it's not really all that interesting as a project.

So, no PyGTA topic prepared yet. Maybe I should work up some GPGPU stuff in PyOpenGL tomorrow, people have data they want to process, maybe they want to process it on their graphics cards.

Particularly Perplexing Pronunciations

2008-06-12T13:58:27+00:00

The four consecutive consonants in my last name, Krstić, make it well nigh unpronounceable to the delicate American tongue, and lead to much hilarity every time someone tries to introduce me at a conference.

Now Ubuntu’s Kevin Cole points out a news item on the upcoming flick Get Smart:

[Steve] Carell plays Maxwell Smart, a newly assigned field agent for the super-secret agency CONTROL. He stars opposite Anne Hathaway as Agent 99 and Alan Arkin as the Chief in the reboot of the classic 1960s spy-spoof TV series.

“I try specifically not to laugh when someone else is doing their thing, because if you laugh and ruin someone else’s take, if someone’s doing something inspired or incredibly funny, it’s a gift, and to take that away by laughing and ruining it, that’s a cardinal sin in my mind,” Carell said. “But there are some times you just can’t help yourself. The scene in the movie, when Alan is trying to pronounce a name [in] the Cone of Silence sequence, … the scene probably took five times longer than it should have because … I couldn’t control myself. And so I took that gift from Alan Arkin.”

Arkin improvised some of the scene, in which he struggles to pronounce the name of an enemy agent, Krstić.

“That just killed me,” Carell said.

Look, it’s okay to use my name, but Hollywood and I have a deal: no biopics. My life as a super-secret enemy agent is off limits. Evidently director Peter Segal didn’t get the memo.

The henchmen have been dispatched.

Presentation on Network Security and Vulnerabilities

2008-06-12T06:55:00+00:00

Yesterday I decided to share with the team an overview of a Wired and Wireless Network and how certain loopholes in them can pose a threat to our data and confidential information. Due to lack of time I could not cover, “How to secure the network from such vulnerabilities” Which I hope to cover another time along with Web Server Security.

Below are the topics that were covered during the presentation.

Network Analyzer and Sniffers:
An overview of Wired and Wireless Networks & key distinctions between them.
Wired Equivalent Privacy (WEP) on wireless networks.
Gateways and Routers.
Address Resolution Protocol (ARP) and how ARP requests could be re-routed to a specific MAC.
Mac Cloning, Ip Spoofing.
Creation of fake RSA certification for a MITM (Man in the middle) attack.
MITM attack with ARP poisoning and Denial of Service (DOS).
Decryption SSL dumps.
DEMO given on the above, to read captured passwords from a live ssl session over Wired/Wireless Network.

Remote administration tools:
Trojans.
DLL injection.
Firewall bypassing methods even over NAT.
Key-loggers.
Browser Hi-jacker.
Anti-virus bypassing methods with the use of Compilers, Packers and Compressors.
Anti-virus Signatures.
Demo given with a Yahoo IM Trojan with DLL injection capabilities and how confidential information could be retrieved without the user knowing off it.

Later had a feedback from the guys, that they had thoroughly enjoyed the presentation and were looking forward to more of such stuff in the future.

On workshops

2008-06-11T20:51:03+00:00

While these haven’t officially been launched through the appropriate mailing lists (and really, that’s only because we’d like to set at least one concrete social event before we do so), I’ve been busy fleshing out our workshops. (Mel briefly mentioned them last week, though they’ve come much further since.)

I’m super excited about workshops, so I’m really hoping the local community takes us up on what we have to offer - teaching terrifies me, but I enjoy it nonetheless. (I highly recommend “Disassembly & Repairs” - we’ve informally run a bunch of people through the process. It’s awesome!)

The part that makes me particularly happy about these workshops is the broad topic range - we’re not sticking just to the standard “Learn about your XO”. We’re also covering topics such as knitting, photography, Inventor’s Workshop, and “Everything is a bathtub” (an Olin reference, admittedly, but bear with us). A friend of mine will guest-workshop for us and teach about linguistics, if there’s interest.

Basically, we get to integrate our own personal interests and explore potential applications of an XO in the learning environment. (That’s the part that really excites me - Francesca, an OLPC intern, frequently expresses the fear that some people end up treating XOs as “a $200 typewriter” - We’re going to push to see to what extent we can relevantly integrate usage of the XO into as much as humanly possible. I love diverse interests!)

If you’re interested in scheduling a workshop (or know someone who might be), please contact us! I’d love to hear your comments about the existing offerings, suggestions for additional classes, or anything else you’d like to say.

Oh, and do keep in mind - just because it’s “One Laptop Per Child” doesn’t mean we’re limiting our workshops by age — we’re firm believers in lifelong learning, too :)

Charles Rennie Mackintosh

2008-06-11T05:08:49+00:00

In other news, we went to Scotland a few weeks ago. I learned a number of things about Charles Rennie Mackintosh that were a bit surprising for me. For one thing, the thing that attracted me to his work, and I think largely contributes to his popularity is something that he was in the process of eliminating.

Mackintosh was working around the turn of the 20th century, about the same time as Wright and Loos. His most famous works can be described as abstracted ornamentalism. They look like the Scottish Baronial style reduced to a minimalist sketch, evocative, modern-feeling. They also happen to be much less expensive than the full baronial style, as the hints of organics can be accomplished with a couple of carved loops set between the bars of otherwise simple (thus cheap) geometries.

Mackintosh used repetition, ordering schemas and abstraction to create the impression of depth and complexity, and the resulting environments are reasonably attractive to the general populace, while still feeling "modern". Much of what he could accomplish was dramatically limited by budget, but he did a lot with what he had.

Thing is, he doesn't seem to have understood why people liked his work, and this is something I missed. What I missed at the simplest level was the chronology of the works. I'd assumed a particular school was his earliest work, before he found his voice. It was actually his final work in Scotland. We arrived about 5 minutes before the school closed but were shown around by the extremely enthusiastic security guard, who waxed eloquent about the school and Mackintosh well past the closing hour.

The school could best be described as pedestrian compared with the earlier works. There were details here and there that someone who knows Mackintosh would pick out as indicative of his style, but there was none of the lavish layering and implied complexity about the place. In short, it looked like a modernist building, pleasant, well designed, with a few stylistic details, but unremarkable. If you didn't know it as Mackintosh you would be just as content to imagine it a local community centre designed any time in the last 100 years.

Yet this was the peak of Mackintosh's design ark. This is where he was going (at least, according to our friend)... and given the chronology that would seem to follow. The earlier buildings were steps on the path to this non-descript (for us, now, when the stripped style is the norm) architecture.

I'd thought Mackintosh was a revolutionary resisting the modernist program with a call to organic architecture. I'd thought he was using the power of implication and minimalism to introduce the organic and human back into a sterile architecture. Instead it seems he was a reasoned modernist picking his way from a complex and organic tradition toward the modernist programme of Loos and the like.

Cellestial Jukebox

2008-06-11T05:02:45+00:00

I'm trying to spend one day a week on Open Source projects again. Currently most of my time has been spent on PyOpenGL, but this week I'm thinking I'll spend some quality time with StarPy. A year or so ago one of the chaps at the PyGTA meeting mentioned that the CNIB has a big media library that they want to make available to their users via phones. I'm thinking it would be a very cool demonstration application for StarPy.