andymatuschak.org: archive

A little birdy at Apple told me that my plan detailed in the previous post won’t work at all, since Software Update will (for obvious security reasons) refuse to install any update packages not signed by Apple.

Oh, well. Back to the drawing board!

When high school seniors try to decide where they’re going for college, they often make lists of pros and cons for each prospective school. By balancing these lists, they can in theory determine a quantitative winner.

I never made any kind of pro/con list to decide I wanted to come to Caltech, but lately I’ve been thinking about each side quite a lot.

The Pros

The thing about Caltech is that while it advertises its superior academia and serious research opportunities and so on, I very much doubt that we’re actually better than MIT, Harvard, or Berkeley in those departments.

The reason I came to Caltech is the people: the students here are absolutely brilliant, intensely driven, and they’re insanely good at what they do. No one was accepted because we needed more of a minority: there are maybe three Latino students here, despite the exterior demographics of Southern California. No one was accepted because we needed a great basketball player: we just won our first game in eleven years. And unlike our colleagues to the East, no one was accepted because we need more girls. Even though the ratio is nearly 3:1 male to female.

The real reason I came to Caltech is that everyone here deserves to be here. It’s really exciting.

The Cons

These same brilliant, excited people quickly evidence what’s so wrong with Caltech.

By the end of the first year, nearly everyone is bitter. Really bitter. This is so universal among students that in Blacker, there’s a ceremony in which the one or two people every year who manage to escape their sad fate are honored with the title of “perma-frosh” for the rest of their stay. It’s so striking that when I visit another school, I’m always shocked by how relaxed and happy people are.

Of course, the same reason this place is so great is the reason it’s made everyone so bitter: the same absolutely insane level of difficulty that drew all those students here in the first place.

To give some illustration, most students have about 5-7 hours of homework a night, and classes from 10 am to 4 pm, perhaps with some gaps in between classes. Dinner’s 6-7 pm. And think about it: to get up for class at 10 am and get a good night’s sleep, a bedtime around 1 am is a must. So with 6-8 hours of homework a night, what does that leave? Nearly nothing. An hour or two a day, tops. With even one extracurricular, forget about any extra time at all.

When things get really bad, my days go like this: wake up, go to class, work, dinner, work, collapse. Straight from class to work to sleep, day after day after day. My life went on like this for about a week and a half for me recently, and though I had until then remained steadfast against bitterness, those around me could distinctly see my spirit breaking.

What are a student’s options? Well, he can stay up later to relax some and miss class, but then he just gets behind, and homework takes even longer. He can take a lighter workload, but doing even the minimum to graduate in four years is obscenely heavy—and this “heavy” is heavy for Caltech students, who are essentially all at least in the top 0.1% of their peers.

A huge portion of graduates are so burnt out and tired of science that by the time they leave, they feel like they never want to put on a lab coat again.

The Core

What makes things worse is also what makes things better: the Caltech core. If you haven’t heard about it, our core curriculum—for every student—consists of:

• Five terms of math: analytical and multivariable calculus, linear algebra, differential equations, and statistics.
• Five terms of physics: mechanics, special relativity, electricity, magnetism, waves, quantum mechanics, and thermodynamics.
• Three terms of chemistry: basic inorganic and organic chemistry, physical chemistry, and thermochemistry, and a basic inorganic chemistry lab.
• A term of biology: a survey, currently physical biology focused on virology.
• A menu class: an introduction to geology, astronomy, or information theory.
• Another lab: solid state electronics, physical mechanics, or organic chemistry.

The first two points are especially insane: the curriculum we cover for every student is equivalent to an entire 4-year program of both physics and math at a huge number of universities.

This is lovely because everyone here has a thorough and broad understanding of many scientific fields. I can talk to any of my classmates about quantum computing, and we all know much of the theoretical background necessary to understand what’s going on. If I’m talking about some obscure machine learning algorithm, even non-computer scientists understand the statistical and probabilistic material well enough to follow.

Despite all its benefits, the core is a huge part of what makes people here so bitter. Take me, for example: I’m a sophomore, and I’m currently taking my first actual CS class. And I’m only taking one this term. For most majors, the real course-load doesn’t start until well into sophomore year.

And it’s not as if these courses are easy just because they’re general, introductory courses: I was two points away from failing Math 1a, and I consistently spent twelve hours a week on my Physics 1c sets.

This is really frustrating. Here’s a real conversation I had with a non-Techer friend:

Him: “Hey, why’s it been so long since you updated Sparkle?”
Me: “I’m really busy with schoolwork.”
Him: “But so many people use it and are waiting for you!”
Me: “I know, but I’ve really got to get this Bio set done.”
Him: “Bio set? What?”
Me: “Yeah, it’s on how HIV fuses with the cell membrane and injects its contents.”
Him: “What? Why are you taking that?”
Me: “I have to. Everyone has to take it.”
Him: “But you’re a computer scientist! It’s not the least bit useful!”
Me: “Believe me, I know.“

It’s often hard to justify going through all this when if I just wrote some software, I’d be making money instead of paying. Especially when having a successful product is better for employment opportunities than a degree, even from Caltech.

Maybe I’m just impatient. The material is slowly getting more applicable to me. I’m taking a course in discrete mathematics that’ll be useful for Sparkle, and the machine learning is very neat. Core courses will eventually go away.

But not before they’ve taken their toll on my spirits, like they have on everyone else here.

The really sad conflict that comes out of all this is that the workload makes everyone here bittermdash;but that all these wonderful people wouldn’t be here in the first place if it weren’t so insane.

Christopher Atlan has been committing some really useful patches to Sparkle trunk as of late. Among them are support for plugins, support for pkg and mpkg updates, and a couple nice bugfixes. Thanks, Chris!

Sparkle 2 Updates

I haven’t had a chance to actually code on Sparkle 2 (dohgod, Caltech’s killing me so hard), but I thought I’d update blog readers with what I’m thinking, vision-wise, since I haven’t had a chance to update the Conspiratory:

Lots of people in #macsb pointed out that they don’t want their apps asking users if they want to install some third-party crazy preference pane thing that requires authorization. This is understandable. I’m going to make Sparkle 2 a little friendlier than that.

First, there’s the developer side: Sparkle.framework, which contains all the core functionality: code to parse appcasts, to make the version poset, to check authenticity, and so on. Your app can use Sparkle.framework as before to just do updates completely within-app. No creepy install-y prompts.

Then there’s Sparkle, the user-focused thing (should it have some other name? or should Sparkle.framework?). When users install this, they start a localhost-only webserver on some obscure port that acts as the Software Update server for the real, bonafide Software Update.app. This doesn’t require any crazy SIMBL-hackery or anything: a simple preferences .plist setting specifies the host Apple SWU supposed to use to retrieve its update catalog.

So this webserver will serve up .sucatalog files (example) made from the union of the genuine Apple update catalog and a generated catalog of updates available for the apps on your computer. A daemon will update the webserver’s .sucatalog file every so often (daily-ish) by pinging all the appcasts.

A preference pane will switch the webserver on and off; users can switch back to the genuine Apple update server easily, so it shouldn’t be too scary.

And finally, like with Growl, developers can choose to call a quick method in Sparkle.framework that’ll offer to download + install the user-side Sparkle solution. Totally optional, opt-in.

There are some technical details to be worked out behind the software update proxy thing, but I’m pretty confident I can make it happen—this’ll offer the best solution to users, since it’ll be integrated into the interface they already know. There’s only one set of settings for updating, and no duplicated UI.

Not that this’ll actually happen until Caltech stops beating me up and taking my lunch money.

Okay, school’s had me really busy, so Sparkle 2 is still a long way off, but the problem is that there’s lots of known bugs in Sparkle 1.1—bugs that have been fixed! And there have been other improvements in trunk. Big ones include Panther compatibility, support for plugins, a much more graceful restart method, and support for DMGs in 10.4.9+ / Leopard.

So I think I want to do a Sparkle 1.2 release to tide people over until Sparkle 2 comes out: Sparkle 1.1 is really old, and everyone should be using trunk, but that’s scary, so people don’t.

I need my kind readers to check out the trunk version of Sparkle and test it with their apps: see if it works for your scheme! I think everything is still working great, but I want to be sure.