University of Florida CISE: Now More Than Ever

By now you've likely heard the proposal that the University of Florida plans to drastically restructure its Computer Science department, CISE.

While the details are not as provocative a picture as the Forbes article paints, the proposal is still bad for the university and its students (read the actual proposal). Also, as an alumnus, the proposal is, frankly, embarrassing.

At a time when the United States needs more STEM graduates than ever, universities ought be doubling down on their Computer Science programs. I encourage you to write to the university. Even if unaffiliated with Florida, this restructuring sets a bad precedent for other institutions.

Today, I sent this email:

President Machen & Dean Abernathy,

I am writing to express my concern with the proposed changes to CISE. Contra more provocative coverage, I understand that the department is to undergo restructure and not outright elimination. I also understand the significant budgetary pressures facing Florida. Nonetheless, the proposed changes to CISE are wrong for the university and wrong for its students. Moreover, they set an ill precedent for other institutions at a time when the world needs not fewer, but more, CS graduates.

The proposed restructuring will irremediably harm the ability of Florida to attract top-caliber CS instructors, researchers, and students. The elimination of graduate and research programs will result in the loss of existing top faculty and place current students, who enrolled in graduate programs in good faith, in an unfortunate and precarious situation.

I am an engineer at Google and sit on a Hiring Committee, responsible for hiring decisions across my office. I am also an engineering manager. While we look for smart, driven individuals of varied and many backgrounds, this proposal will assuredly hurt Florida graduates beginning their careers. Universities with strong software--that is, CS--curricula and deep research programs matriculate students best equipped to excel in today's technology companies--or start the companies of tomorrow.

When the largest, most successful companies in the world are software companies clamoring for more and better engineers, Florida should increase, not decrease, its investment in Computer Science.

I understand these budget cuts were imposed upon you. I wish they were not. Important decisions are rarely easy, but you must revert this proposal.

Yours sincerely,

Robert Love
Staff Software Engineer, Google
BA Math & BS CS, UF '04

Update: Hours after my email becomes the focus of his day, President Machen issued this statement to the university community regarding the budget:

Engineering Dean Abernathy has agreed to set aside the previously announced proposal as the department chairmen of CISE and ECE continue to flesh out details of a new proposal in consultation with students, faculty, staff, alumni and industry partners. The college has no plans to close any departments.

The budgetary issues facing our states and public universities are not over. Nor do I believe that the threat to Florida's CISE department is past. Nonetheless, this is an important victory, a crucial step worthy of celebration.

Google+

This being 2012, I'm not blogging much. I apologize.

I have, however, been playing around on Google+. It offers an opportunity to do longer form posts—more akin to a blog—than, say, Twitter. I am enjoying it; perhaps you will too.

Follow Robert Love on Google+.

Paris in Diorama

A week in Paris in the Spring. Pour être jeune et dans l'amour. I made some dioramas:

Passerelle Debilly, Paris, France

Palais de Chaillot, Paris, France

Champ de Mars and École Militaire, Paris, France

See also my dioramas from around Spain.

Kindle 3 Kernel

I really dig the Kindle 3. The small improvements add up to a significant improvement in usability. As my friend Chris put it, "as soon as I turned it on I realized I did the right thing."

For the curious, I got ahold of the Kindle 3's source code and generated a patch against 2.6.26 (I did the same for the Kindle 1's kernel).

The patch is big and noisy, but here's what stands out: Ingo's RT kernel, which converts most spinlocks to priority-inheriting mutexes, removing most regions of non-preemption in the kernel; ARM architecture updates; driver for the Atheros AR6002 802.11a/b/g device; driver for the Freescale MC13783 voltage regulator; driver for E Ink; driver for the Asahi-Kasei AK4647 audio device; lots more.

From the source, the Kindle is still code named Fiona internally.

Anyone spot anything neat I am missing?

Google Instant

Google Instant, which we announced yesterday, is at its best after you have used it for a bit, and allowed the interactive experience to refine and improve how you search.

But, for me, the simplest sell is searching for the weather. Last week, you might have searched for weather 02116 (and a decade ago, you'd have watched the evening news). Today, you hit w:

Try it out on google.com.

Spain in Diorama

So I got married.

For our honeymoon, we rented a sporty convertible and took off on a road trip around Spain. Three weeks, 3485 kilometers, fifteen Michelin stars.

I built these "dioramas" of places we visited.

Granada in Diorama

San Sebastián in Diorama

Barcelona in Diorama

Igeldo in Diorama

Hopefully the marriage will stick.

Linux Kernel Development, Third Edition

I'll mention this only once, promise.

The third edition of my best-selling Linux kernel primer, Linux Kernel Development, is now shipping. The publisher is Addison-Wesley and you can find the book in better local and online booksellers.

What's new? Lots. The text is clarified, reworked, and reorganized. The material is fully updated and now based on the 2.6.34 kernel. I also note if and how the 2.6.32 kernel differs, as that release is a "long-term stable" version and thus likely relevant to many readers.

New material includes treatment of the Completely Fair Scheduler, an analysis of the flusher threads component to page writeback, and a chapter devoted to kernel data structures.

Whether you already own an earlier edition, whether you are a kernel developer or just curious how it all works, Linux Kernel Development is an excellent addition to your bookshelf. But don't take my word for it. From one of the many five-star Amazon reviews (this one of the second edition):

The content is one part why this book is great, but I think bigger points go to Robert Love's delivery. His style is casual yet not willy nilly. A subject like the kernel is both dense and minutia-filled and in turn is so much easier to grasp when it's not presented in a dry academic style. The way I would characterize this book—it's as if you're older brother took you aside and taught you how to hack the mainframe.

And:

I have been doing Linux kernel/system level development on and off since 1999. This is the book that I think should be owned by any Linux newbie who wants [to get into] kernel hacking. Even if people do not directly do Linux kernel development, it is a good book complementary to any serious operating systems course in college—it helps gain a better idea of how and why.

Buy it from Amazon.

Buy it from Barnes & Noble.

Buy it from the publisher.

Micro Four Thirds

Wanting a lighter kit than the Canon 5D Mark II for my honeymoon, I recently jumped on the Micro Four Thirds bandwagon with a purchase of the Olympus E-PL1 and Panasonic 20mm pancake lens.

This crazy sunset is my first shot:

Sunset over Boston's Back Bay

Shot in JPEG, not RAW, and oversharpened a bit, but the image quality is quite good. What's with the grey sky and bright red sunlight?

iPhone OS 4 and Multitasking

What follows is a first-look at the just-announced multitasking features in the next iPhone OS. It is solely my opinion.

As I predicted in my previous post on the iPad & iPhone and multitasking, Apple is adding multitasking-like support to iPhone OS 4. And as I wildly speculated, that support is largely (although not completely) in the form of background services. Let's take an initial look.

First, as I wrote in my previous post, both the iPad and iPhone support multitasking today. At the system level, many processes run concurrently, and Apple-provided applications are allowed to multitask. What we are discussing here when we say "multitasking" is specifically the ability for third-party applications to multitask.

Second, this is a very early look at what Apple announced at today's event, which is still going on as I type this. Thus, cut me some slack. Developers should consult more detailed documents, which ought to crop up over the next few days and weeks.

What did Apple announce? A lot of spin, actually, but also two simple features. These features do not allow third-party applications to multitask. That is, on iPhone OS 4, as with now, only one applications runs at a time. What these new features do enable is functionality that fulfills many of the same use cases as multitasking. Let's look at them:

Services. Apple is adding a set of service APIs that allow background processes access to a subset of the device's functionality. Such services have access to, at least, notifications, geolocation, deferred computation, VoIP, and media playback. Having a service API limits the ability of background applications to run errant and destroy battery, but that is not a primary concern. As I stated in my previous post, the real concern with multitasking on an embedded, swapless device is memory consumption. Battery life is a straw man. So how do services solve the memory consumption problem? Alone, as described in the event, they don't. But iPhone OS will continue to kill applications that leave the foreground. Thus, applications will need to be refactored to provide a background component that only uses the new Service APIs. Without the risk of unbounded multitasking, memory pressure is greatly relieved.

Serialization. This was tacked onto the end of the discussion of the new services API, as if it was another service. But it is not. Described as "fast app switching" during the event, this is essentially a serialization API. When apps exit, they may choose to save their state to the backing store. When they restart, they reload this state. iPhone OS provides a simple object serializer today, called NSCoder. It is unclear if Apple is just pushing for better use of this class, or if they are adding additional APIs to make serialization both easier and more powerful. Either way, this will make it appear as if applications are actually multitasking—even though they are not—by allowing them to recover their exact state on restart.

So what about these solutions is "gonna be the best?" Nothing. In fact, what was announced is not even multitasking. Moreover, the new functionality isn't anything that other platforms don't offer today. Android, for example, provides excellent support for both of these features via Services and Bundles, respectively. The new iPhone APIs are not novel. But, despite the spin, that isn't what matters. All that matters is the user. If these APIs are sufficiently robust, they will benefit the user by enabling developers to make better apps.

One difference between Android and iPad & iPhone is that Android does not kill applications on task switch. The iPad & iPhone will continue to do so. Thus, in some sense, Android has a third solution to application multitasking: We allow apps to actually multitask until the system experiences memory pressure, at which point our OOM killer is able to kill applications in least-recently-used order. Then, our serialization solution kicks in, making their reload transparent to the user.

Why the iPad and iPhone don’t Support Multitasking

Why don't the iPad and iPhone support multitasking? The answer isn't what you think.

There is a lot of misconception around support for multitasking in the iPhone and its giant cousin, the iPad. What follows is my analysis of the situation. I am not privy to any insider Apple information. Moreover, while my knowledge is certainly colored by my work on Android, I’m not drawing a comparison or using any Google-specific knowledge.

First, obviously the iPhone and the iPad do support multitasking. This is 2010 and both are built on modern, powerful operating systems that provide support for preemptive multitasking. Indeed, at the system level, there are many processes running concurrently. And some Apple-provided applications, such as the music player, clearly multitask.

So let’s redefine the complaint. What in actuality is not supported is the ability for third-party applications to multitask. That is, the system enforces a policy whereby once an application leaves the foreground, it terminates. In some ways, this makes sense. The iPad and iPhone user interfaces are single window, single document. Not allowing for background applications probably works out for a whole lot of use cases.

Apple says they do not support multitasking because it is a hamper to stability and a drain on battery life. That clearly isn’t true—the iPad has plenty of processing power and battery capacity. Rumor is that Apple is going to add multitasking in a future OS release. This rumor likely is true. Is Apple somehow going to make background applications not consume any battery? Of course not. These excuses are straw men.

The real reason that the iPad and iPhone do not allow third-party applications to multitask is likely more complex, more technical. Bear with me here. Both the iPad and iPhone, as mobile devices, have limited memory (256MB in the current incarnations) and no hard drive. No hard drive means no swap file. Limited memory and no swap imply that applications have a small, fixed amount of memory at their disposal. They don’t have the luxury of seemingly-infinite memory, as a modern system with swap has. Memory consumption is thus a critical system constraint. Like most systems, the iPad and iPhone deal with this by killing applications that use too much memory via a mechanism called the out of memory (OOM) killer. Unlike most systems, applications designed for the iPad and iPhone know how much memory they have at their disposal, and are designed to operate within those constraints. This is classic memory management in embedded programming. No swap, fixed memory, you deal.

What would happen if third-party applications could multitask? Some number of applications would be in the background. But each application was written presuming it had access to some fixed amount of memory. Thus, if the background applications consumed too much memory, the operating system would have to kill them. But the user would expect that he or she could switch back to an old application, and it would still be running where it was left. He or she certainly doesn’t expect applications to just die every time a new application is run, losing state and even data.

Simply put, the reason the iPad and iPhone do not support multitasking is because it is hard to allow multitasking in a system with no swap and a limited amount of memory. Apple could enable multitasking—indeed, there is no reason that the devices couldn’t support it right now, with a one or two line code change—but your applications would constantly be killed. That isn’t a very useful feature.

So how is Apple going to enable support for multitasking? Likely similar to how Android allows it. The Android platform was designed from the ground up for use on phones and other embedded devices. Consequently, we built in a mechanism whereby applications can save their state, including their current view, with the system. In fact, through this state saving mechanism, which we call Bundles, Android applications can operate as if they are stateless.

Thus, allowing for multitasking on Android is easy. Like the iPad and iPhone, we have a powerful, modern operating system (in Android’s case, based on the Linux kernel). Unlike the iPad and iPhone, we also have Bundles, which allow apps to save their state. Android’s OOM killer is aware of background applications and is capable of killing them in least-recently-used order. If the user switches back to an application that has been killed, the Android platform reloads the application’s state via Bundles. The whole process is seamless. Because Android has this state-saving framework, multitasking is feasible even on a device with limited memory and no swap.

In summary, the iPad and iPhone don’t support multitasking not because it would hurt battery life, but because it is hard to do so on a swapless, embedded device without platform support for serialization, which the devices lack. It is likely that Apple will add the requisite functionality in a future OS release. Until then, enjoy your giant iPhone. Or rock a Nexus One, which multitasks.

Update: Folks have asked me how a serialization system such as Bundles enable support for persistent applications, such as music players or IM clients. You wouldn't want these applications killed, even in low memory situations, and their state is ever changing so saving it isn't productive. There are many ways Apple can provide this support. On Android, we do so via Services. Most applications use the Bundle framework to save their state and are thus easily interruptible. Applications that provide a service to other applications, are a server, or function as a long-running background task use the Service framework. These applications are managed by the system more like Unix daemons and are not killed in least-recently-used order when memory is low.