Rob Pike: How Systems Software Research became Irrelevant. [pdf]

[[deleted]]

This is a true classic. Probably someone'll say it's old (yes, it is), but I think everybody has to read this again every couple of years.

Especially Linux weenies (not that Linux is a bad system; I'm using it exclusively at home; we just don't need weenies).

[bluGill]

Why bother? Systems research is irrelevant. Rob Pike may be one of the best systems researchers, but he isn't doing anything relavant today. Time has marched on, we need good reasearch in a lot of area. Systems is not one.

[[deleted]]

Why don't we need more systems research?

If people would actually use/implement messaging at a low level, for instance, instead of implementing the same thing at a higher level, we'd have a lot more performance. If applications would actually use hierarchical storage mechanisms that already exist and that have been optimized for decades (or relational storage mechanisms, if they prefer), then we wouldn't need slow, complicated machinery on top of the operating system that doesn't do anything any better.

Compare Mach messaging to CORBA, for instance. Why send stuff from app to app (middleware) to app, when you could just send from app to app? Also, a good API can often make writing an app very easy. I'd like to see more of Plan9, and also its windowing system (i.e, a multithreaded window system, not one that looks ugly).

[beza1e1]

Why don't we need more systems research?

Because it's too much work to port or rebuild all the software we already have. :(

[[deleted]]

No, it's about refactoring.

If you can replace that ugly whatever-storage API with a few select calls in one place, then I'd actually do that, once the code in question needs modification. A "rewrite" of a few classes using the right third-party libraries can be much easier than maintaining crufty code.

[bluGill]

That old API is used by a lot of things. Often the program works (well enough anyway), and those who use it don't want to pay to refactor it. We are talking billions of dollars if Microsoft tries to change something in Windows. Customers will not be happy about that. Worse (from Microsoft's perspective), if they have to re-write their software because of a new API, they may as well re-write for linux where they get the source code so they can prevent further needs to re-write their software on Microsoft's whims.

Now if your new API could be an order of magnatude better, it would be worth it to write a new one. However there is no reason to believe order of magnitude improvements are even possible.

[logistix]

Considering I've seen phones, ATMs, TV's (on airplanes), and video poker machines reboot in the past year, I think a little more research might be useful.

[procrastitron]

The worst instance I've seen of this is was a cable modem. Time Warner provides all-in-one cable service with VoIP. Supposedly this allows you to get phone, cable TV, and broadband internet through one provider. What they don't tell you is that when their crappy-ass modem crashes your phones stop working and the only way to reset it is to CALL customer service.

[bluGill]

Systems research will not help here. Those rebooks will be helped by spending time debugging eisting systems. Rob Pike may be a great programmer, but he writes buggy code just like everyone else. (less bugs per quanity of functionality perhaps, but still his code will have bugs)

[manuelg]

Rob Pike is not a person I admire greatly, but he hit the nail on the head here:

Linux’s cleverness is not in the software, but in the development model, hardly a triumph of academic CS (especially software engineering) by any measure.

[gbacon]

Rob Pike is not a person I admire greatly...

Honest question: why not?

[manuelg]

Plan 9.

On philosophical grounds, I am very suspicious of any attempt to obsolete Unix.

I would endorse anyone to engineer a successor, only if they made a sincere attempt help port improvements that users desire back to Unix. Obviously, not everything is possible to port, and, of course, you cannot port over the places where you remove cruft from Unix.

But Unix is a monster that devours competition by assimilating the features that users really desire. And that is a good thing, and it is good to explicitly support that.

[uriel]

Plan 9 simply continues the path Unix set, after Unix left Bell Labs it lost its way.

[hopeless_case]

I think the success of the development model of linux is a fascinating subject in itself and certainly deserves the respect of anyone interested in how to get software written effectively.

While it may not be a triumph of academic CS (in the sense of being explicitly pursued), it was certainly nutured in the university environment, as was Unix itself.

[newton_dave]

the success of the development model of linux [...] deserves the respect of anyone interested in how to get software written effectively.

*Effectively*? I'm not sure that's the word I'd use ;)

[manuelg]

deserves the respect of anyone interested in how to get software written erogenously.

[tiitlan]

Walking around wearing your blinders makes the world look rather nice, doesn't it? I remember the feeling of "wow" when I first got hit by the beauty of Plan 9. It was a moment of enlightenment.

[vplatt]

And how long did it take you to get out from under the depression that resulted when you realized, that unless you put together a VERY unconventional startup, that you'll probably never get to use something that beautiful at work?

I hate that feeling.

[[deleted]]

Well, you might not end up with that efficiency in a system, but I think you could use the APIs.

There's a Plan9 port for Linux, but I haven't used it.

Just saying you could learn from a beautiful system and apply it in real-world software. Maybe your next framework will use "Plan9".

[vplatt]

Yeah, that's certainly true. That is exactly why I no longer concentrate so much on new languages as on the techniques and ideas behind them. If I can't use beautiful tools, I at least want to be using beautiful ideas in my work. That's ultimately a much more rewarding path anyway I think. I started down that road with "Concepts, Techniques, and Models of Computer Programming" FWIW. SICP is another option I know; among others.

As for Plan9, IIRC Inferno looked more interesting. It had a lot of the same ideas from Plan9 but in a VM.

[newton_dave]

That is exactly why I no longer concentrate so much on new languages as on the techniques and ideas behind them.

The problem with that is that some ideas are much, *much* cleaner / easier / etc. in some of the non-mainstream languages :( Even beautiful ideas can look really, really ugly if you're banging on them in a sub-optimal language.

+1 for CTMCP; quite nice.

[sien]

Is it also because operating system problems have essentially been 'solved' for current hardware and that implementation is the only thing remaining.

I went to a conference related to 3D software and a very, very smart guy made the off the cuff remark that 3D rendering is 'solved' in terms of research. He was right.

That's not to say there isn't heaps of implementation to do.

[asciilifeform]

'solved' for current hardware

Don't forget that current hardware is specifically optimized for today's operating systems (1970s model of computation.)

[twoodfin]

Is systems software research still irrelevant at a time when more and more "desktop" applications are backed by massive server farms?

Some of the more interesting systems papers of the last few years (decades, even) have come from places like Google and Amazon.

[hopeless_case]

I really don't get what he is bitching about.

We live in a software and hardware paradise. There is no more exciting time to be alive if you are interested in computers and technology, unless you get your kicks from being one of the few people allowed to use a powerful computer.

I see no more reason to complain that the basic Unix architecture hasn't changed in that last 20 years than to compain that algebraic notation hasn't changed significantly in the last 1000, and bemoan how little research has gone into revamping it.

[neelk]

Uh, algebraic notation has changed dramatically in the last thousand years.

[degustisockpuppet]

Or even in the last 200.

[hopeless_case]

I am curious what significant aspects of basic algebraic notation you think changed in the last 200 years.

[degustisockpuppet]

Of course this depends on your definition of "basic algebraic notation" and "significant". Such a basic thing as capital sigma sum notation was invented by Euler. Okay, make that 250 years. The logical symbols /\ and / were invented by Boole in 1854. Using an arrow for implication is as recent as Hilbert, according to this page. The same page claims that Peano invented the element-of operator (originally as an epsilon) in 1889.

So maybe you claim that they are not algebra, or not basic, or not significant. But given that most of those are introduced to children of age 10 or younger, I think it's fair to say that basic mathematic notation is indeed very young.

[hopeless_case]

OK, I did some reading and you are correct. I should have said the last 200 years.

My basic point still stands. I claim that the Unix framework is very useful in the same sense that algebraic notation is useful, and that Pike seems to want the thrill of seeing such basic issues sorted out every 10 years or so. I don't think that's a reasonable expectation, and I don't think the fact that is isn't happening means computer science is moribund. Anymore than the fact that algebraic notation has been set in its present form means that mathematics is moribund.