Hacker News new | past | comments | ask | show | jobs | submit login
The Night Watch (2013) [pdf] (microsoft.com)
83 points by Manishearth on June 6, 2015 | hide | past | favorite | 21 comments



> The systems programmer has written drivers for buggy devices whose firmware was implemented by a drunken child or a sober goldfish

This accurately describes my experience lately.

I knew those goldfish weren't to be trusted.

Edit:

> “Why would someone write code in a grotesque language that exposes raw memory addresses? Why not use a modern language with garbage collection and functional programming and free massages after lunch?” Here’s the answer: Pointers are real. They’re what the hardware understands. Somebody has to deal with them. You can’t just place a LISP book on top of an x86 chip and hope that the hardware learns about lambda calculus by osmosis.

This accurately describes my experience every time I click on a HN topic about Rust.


  > This accurately describes my experience every time I 
  > click on a HN topic about Rust.
Hm? Rust doesn't have garbage collection, let alone free massages. It does have pointers and it does have raw memory access. Like C++14, it's thoroughly a systems language with a few functional niceties floating around.


THANK YOU!

I'm in the Go camp myself (largely because I speak Unix and with Pike being involved it was inevitable) but I've read a lot on Rust and have been procrastinating learning it for about two years now.

It's a very interesting language. Has a lot of helpful constructs. I'm quite convinced it's a better systems language than C++.

However, every time something about Rust or Heartbleed hits the net, people flock around and dream of a world of Rust where Bad Stuff can't happen because Rust doesn't let you write programs that do Bad Stuff.

Indeed, Rust doesn't let you write C++-branded Bad Stuff in Rust. Real life, however, leads me to believe that Rust-branded Bad Stuff will be trivial to write in Rust, and it is not the panacea that everyone hopes it is.

It won't just magically make systems programming better and safer. People somehow managed to have buffer overflows in firmware written in that hideous form of Pascal that had the length of the array as part of the type, so foo(int x[10]) only compiled if you passed it an array of ten ints. They'll manage to write shitty, unsafe code in Rust, too.

Edit:

> let alone free massages.

If you know of a language with free massages please share that information with me because I definitely want to learn it :-).

I'm not nitpicking, it's just such a funny typo!


Umm, he was quoting "and free massages after lunch?" Not a typo :-)


Oh. Crap. Joke's on me.


I think the joke is about people criticizing Rust for having pointers, etc.


Look, osmosis is a verified scientific fact! It's bound to work at some point! We've just got to adjust some simple parameters...

<tightens clamp on chip-book assemblage>


Pointers are only real if you ignore MMUs and cache lines and imagine that C actually gives a good model of real modern hardware.


> Pointers are only real if you ignore MMUs

Which is true on architectures without MMUs, which probably account for about 90% of the computing devices in use. Okay, maybe 85% since tablets and smartphones became important.

And is also obviously true in MMU code.

And then they're just pointing at an imaginary address that the MMU "projects", so they're still very real in the sense that the author is using (i.e. in one form or another, we're going to keep having to write arbitrary values at arbitrary addresses that mean something until someone figures out a better way to talk to devices).

I don't think that better way doesn't exist. Like anyone who ever found himself wishing PDP-11 would just fucking die already, I even have a few ideas of my own about a better way. Alas, I'm probably wrong about them and I don't know of any commercially-available processor that has a better way of doing that.

> ...and cache lines

Which you can generally do as long as you remember to account for it when it comes to timing and you don't have a buggy cache.

I know a guy who spent about an year and a half chasing a bug that got traced to a bug in the IP. It would occasionally decide to flush the cache, even though it didn't. Talk about dedication.

> and imagine that C actually gives a good model of real modern hardware.

It never really did, not even on the PDP-11, but that's hardly the point. LISP didn't really give that good a model of the LISP Machine either, but it provided an abstraction that was close enough to be useful and allow you to reason about what you had to do.


I've always enjoyed his papers. They carry their own brand of absurdity/hilarity. Here are some others I've seen posted in the past [pdf warning]:

http://research.microsoft.com/en-us/people/mickens/nestofhor...

http://research.microsoft.com/en-us/people/mickens/thisworld...

http://research.microsoft.com/en-us/people/mickens/thesaddes...


He has written 6 of these and they're all available on his page (scroll down to the line on the USENIX online magazine): http://research.microsoft.com/en-us/people/mickens/


I have seen this reposted a lot of times, but I reread it every time. It is simply amazing.


Very witty and fun read on the importance of system engineers. If I had to choose a tl;dr:

  I’m glad that people are working on new kinds of bouncing 
  icons because they believe that humanity has solved cancer 
  and homelessness and now lives in a consequence-free world
  of immersive sprites. That’s exciting, and I wish that I
  could join those people in the 27th century. But I live 
  here, and I live now, and in my neighborhood, people are 
  dying in the streets. It’s like, French is a great idea, but 
  nobody is going to invent French if they’re constantly being
  attacked by bears. Do you see? SYSTEMS HACKERS SOLVE THE 
  BEAR MENACE.


James recently announced he is leaving Microsoft Research to be a professor at Harvard. I can't wait to see what the Harvard University Press thinks of him.


He will be missed.


That's so 1970s systems programming. We've made progress since then. For one thing, now you usually have enough computers to have a test environment.


Can't stop laughing... this guy synthesizes pure comedy gold with a touch of absurdity and a lot of cynicism.


Read this with high "NoSQL Bane" expectations...

...was still overwhelmed.


I'd totally support a Patreon for Mickens to do recorded readings of his papers.


Ah right, forgot about his Bane talk. For those who haven't seen it, also great: https://vimeo.com/95066828


slightly over the top but awesome.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: