Emacs or vi: neither (Rob Pike)(usesthis.com)
usesthis.com
Emacs or vi: neither (Rob Pike)
https://usesthis.com/interviews/rob.pike/
26 comments
He's at Google. Many people there seem to think of network connectivity the same way we think of clean water, electricity, and natural gas - things that are just always there, in whatever quantity you want. Ditto for storage and computational power, because for them all those things are like utilities. Never mind that people in many parts of the world can't even take those "old fashioned" utilities for granted. People who live in bubbles tend to lose touch with the outside world.
Thinks like the Andrew File System and Coda were actually developed to try and work around this, to provide resilience and allow one to have "soft" state in the presence of outages. The interest was not there, certainly not when most people were working on standalone Windows boxes or Macs, and didn't have any idea of the sort of power that was available in research labs via X and Ethernet.
It's a shame, because not only did research groups think about these issues, 20 solid years ago, but also several strong contenders for solutions were implemented. Society did not see the value in supporting further work on the projects and so the researchers moved on.
Pike is not an idiot. He is a pragmatist.
It's a shame, because not only did research groups think about these issues, 20 solid years ago, but also several strong contenders for solutions were implemented. Society did not see the value in supporting further work on the projects and so the researchers moved on.
Pike is not an idiot. He is a pragmatist.
How is it "pragmatic" to assume infinite connectivity instead of working to solve the problems when that assumption fails? That word does not mean what you want it to mean. I've worked on those problems for a couple of decades too. I also bemoan the relative lack of attention given to them. That's exactly why I find his attitude so disappointing.
It's pragmatic to delegate that aspect to other people who are/were working on it. It is not pragmatic to try and solve all the different problems involved all at the same time.
Pike was brought in to Google to do something about log management (hence Sawmill -- it was a disaster prior to his arrival). The solution was pragmatic: awk on GFS.
It would be nice if more attention to intermittent connectivity solved the problem. The trouble is that I see no interest from research funders and not much motive for commercial funders. As best as I can tell, it is in fact quite pragmatic to leave that detail (important as it may be) aside until there's enough interest in stateless "dumb" workstations to reintroduce it.
It's pragmatic to make flawed assumptions so that you can get something done in the common-within-Google case, and come back later for the common-outside-of-Google case, at least if you happen to be within Google.
Pike was brought in to Google to do something about log management (hence Sawmill -- it was a disaster prior to his arrival). The solution was pragmatic: awk on GFS.
It would be nice if more attention to intermittent connectivity solved the problem. The trouble is that I see no interest from research funders and not much motive for commercial funders. As best as I can tell, it is in fact quite pragmatic to leave that detail (important as it may be) aside until there's enough interest in stateless "dumb" workstations to reintroduce it.
It's pragmatic to make flawed assumptions so that you can get something done in the common-within-Google case, and come back later for the common-outside-of-Google case, at least if you happen to be within Google.
That would be fine if he had been talking about what he was doing within Google, but he was specifically talking about his dream system. Here's an analogy.
"I have a dream about a programming language and runtime that will automatically determine how serial code can be distributed across a bunch of machines, and do so without totally screwing up performance or failure semantics. But that's somebody else's problem. I'm not even going to mention any actual ideas about how to do it."
Would you say "pragmatic" is the right word to describe that? I wouldn't. We left the realm of pragmatism as soon as we started talking about dreams. It's not necessarily wrong for me to mention such a dream. Such a compiler would make my life a lot easier. However, it misses an opportunity to inspire would-be collaborators in areas where I have concrete ideas and actually am working to make a difference. It contributes less to actual progress than another answer might have, and that's disappointing.
"I have a dream about a programming language and runtime that will automatically determine how serial code can be distributed across a bunch of machines, and do so without totally screwing up performance or failure semantics. But that's somebody else's problem. I'm not even going to mention any actual ideas about how to do it."
Would you say "pragmatic" is the right word to describe that? I wouldn't. We left the realm of pragmatism as soon as we started talking about dreams. It's not necessarily wrong for me to mention such a dream. Such a compiler would make my life a lot easier. However, it misses an opportunity to inspire would-be collaborators in areas where I have concrete ideas and actually am working to make a difference. It contributes less to actual progress than another answer might have, and that's disappointing.
Fair enough.
Pike is tending to his current scope.
The thing about people like Pike, from my perspective: When that scope changes, they tend to be effective at addressing this and coming up with practical, efficient solutions.
I don't expect better from him than from myself: Tend to the problems at hand.
In fact, I too often get too lost in the "big picture". Maybe one reason I don't have a comparable level of achievement.
Not that Pike doesn't see the big picture. Maybe he just chunks it better. :-)
The thing about people like Pike, from my perspective: When that scope changes, they tend to be effective at addressing this and coming up with practical, efficient solutions.
I don't expect better from him than from myself: Tend to the problems at hand.
In fact, I too often get too lost in the "big picture". Maybe one reason I don't have a comparable level of achievement.
Not that Pike doesn't see the big picture. Maybe he just chunks it better. :-)
I personally think Rob's dream setup sounds horrible. I love having my own phone -- it was shitty having to look for a pay phone or buy a beer in a bar just to use the phone.
And I don't use my phone or laptop for the local storage. If I lose either one I buy a new one and I reconnect to some accounts and I'm ready to go. That doesn't mean i don't appreciate having my own that I can carry around.
Next time I'm hiking in the middle of the forest using Google Maps Offline and want to take a pic of something, I'll think of Rob rolling out his paper map trying to figure out how to get to the nearest camera rental place. Sorry, no storage for pics or maps on your unrolling pen screen.
And I don't use my phone or laptop for the local storage. If I lose either one I buy a new one and I reconnect to some accounts and I'm ready to go. That doesn't mean i don't appreciate having my own that I can carry around.
Next time I'm hiking in the middle of the forest using Google Maps Offline and want to take a pic of something, I'll think of Rob rolling out his paper map trying to figure out how to get to the nearest camera rental place. Sorry, no storage for pics or maps on your unrolling pen screen.
I'll think of Rob rolling out his paper map
I was just down in southern Oregon, and between the frequent "No Service" and the shitty Google and Apple maps, I would have killed for a decent paper map. It's a good thing I had my Garmin app on my phone; it's not reliant on cell service.
My parents and I traveled 9000+ miles around the country in 1974, using a Rand McNally atlas to guide us. The experience was far more pleasant than the maps Google offered up just a few days ago. "Offline" wouldn't have helped, the map quality is abysmal. Locations pop in and out of existence as you zoom in. Many features are totally unlabelled (e.g. rivers). The UI sucks as well.
I was just down in southern Oregon, and between the frequent "No Service" and the shitty Google and Apple maps, I would have killed for a decent paper map. It's a good thing I had my Garmin app on my phone; it's not reliant on cell service.
My parents and I traveled 9000+ miles around the country in 1974, using a Rand McNally atlas to guide us. The experience was far more pleasant than the maps Google offered up just a few days ago. "Offline" wouldn't have helped, the map quality is abysmal. Locations pop in and out of existence as you zoom in. Many features are totally unlabelled (e.g. rivers). The UI sucks as well.
I think there is a middle ground. Paper and contact does have a categorical advantage for field use: at least, anything with batteries has a categorical disadvantage. On the other hand, it's nice that you can print 1 map of your own to cover terrain that used to be split over the corners of 4 published maps. And it's a pretty cool feeling when you click on contours that the surveyors got wrong and drag them into the right place.
There is a place for automation, but that place isn't everywhere.
There is a place for automation, but that place isn't everywhere.
You do realize that there is other software out there for displaying maps?
Including Google Maps? And some of that software can store maps off-line, if
you only care enough to pre-fetch the area you're going to (similar action to
buying a paper map in advance)?
That being said, I prefer paper maps. Because batteries, because view size, because I personally like paper more than electronics.
That being said, I prefer paper maps. Because batteries, because view size, because I personally like paper more than electronics.
I agree that we have a long way to go before offline mapping (and online mapping in many contexts) is high quality. That's beside the point though. In the ideal world those things would work perfectly offline on the device I carry around. Paper maps aren't categorically better.
I think part of the "dream" in "dream setup" implies that there would be great connectivity in the forest.
I think he's imagining a world where his map would somehow get an internet connection even way out in the boondocks.
Or, in the event that a connection was lacking, local state would be maintained only as long as required to allow usable work to get done. Google "coda" or "intermezzo" or "andrew file system". You might be surprised how many people worked on these things. I was, and I worked on some of them.
Somewhat, but not wholly, tangential: when I read research papers, one of the first things I do is to look at how old their oldest references are. If the references are less than 50 years old, one of two things is usually true (sometimes 0, rarely 2, but usually 1):
1) The field is quite new (e.g. CRISPR-Cfp1 gene editing)
2) The authors don't have experienced mentors to guide them through the enormous literature, particularly in mathematics, physics, and chemistry.
It is very rare to see Option 1 in practice. It is incredibly rare for someone of Pike's experience to fall into category 2. This interview is not a research paper; nonetheless, Pike did quite a bit of distributed systems research and is familiar with all of what I mentioned. Networks weren't always ubiquitous or reliable, but the fundamental idea of efficient compute resource sharing has always been attractive enough to view this as a complication rather than a deal-breaker.
Somewhat, but not wholly, tangential: when I read research papers, one of the first things I do is to look at how old their oldest references are. If the references are less than 50 years old, one of two things is usually true (sometimes 0, rarely 2, but usually 1):
1) The field is quite new (e.g. CRISPR-Cfp1 gene editing)
2) The authors don't have experienced mentors to guide them through the enormous literature, particularly in mathematics, physics, and chemistry.
It is very rare to see Option 1 in practice. It is incredibly rare for someone of Pike's experience to fall into category 2. This interview is not a research paper; nonetheless, Pike did quite a bit of distributed systems research and is familiar with all of what I mentioned. Networks weren't always ubiquitous or reliable, but the fundamental idea of efficient compute resource sharing has always been attractive enough to view this as a complication rather than a deal-breaker.
I actually sort of agree with his idea that our portable devices should be stateless, but the way he puts it comes off way too much like "storage is magic that someone else should deal with" for me. Scalable storage with a usable interface (i.e. not an HTTP-based eventually-consistent object store) is hard enough even in a LAN environment. Making it happen in a WAN environment, which is what he's asking for, involves some very hard tradeoffs and engineering problems equivalent to anything you might do with the data once you get it. It's very disappointing to see what amounts to "other people's problem" from someone of his stature.
That's a bit silly. His perspective is that of someone who watched tractable solutions to the cached-state and resync/reconciliation problems be implemented and then marginalized, since no one at the time saw the point. Now, 20-30 years later, it's starting to dawn on people, and the response is essentially a kludge.
I'm disappointed, and I was never at Bell Labs. I imagine Pike is being diplomatic, to be honest. Research is incredibly frustrating when it depends so much on fashion.
I'm disappointed, and I was never at Bell Labs. I imagine Pike is being diplomatic, to be honest. Research is incredibly frustrating when it depends so much on fashion.
Pike has at least 15 years of experience using stateless client devices on a large LAN (at Bell Labs) and being one of the leaders of a team providing the infrastructure (Plan 9) to make those devices usable.
I do love this little pearl:
> In summary, it used to be that phones worked without you having to carry them around, but computers only worked if you did carry one around with you. The solution to this inconsistency was to break the way phones worked rather than fix the way computers work.
He's right, it used to be that I could jump from machine to machine in a Unix environment and really the only thing I gave a shit about locally was my login shell. (I started out using Irix in an SGI/AFS environment, so our logins were essentially stateless; since openGL/XGL worked over the wire, I ran demos in DC on hardware in NY just because, and it was fucking great).
I was sad when the majority of businesses and individuals seemingly decided that Microsoft's single-user desktop worldview was preferable to the Bold Old World of Unix and Plan9, which at that point, thanks to things like XGL and the Andrew File System, was quite multi-user and network-centric. This is why Pike's little pearl speaks to me.
The cloud was a good idea 20 years ago, too. But only recently has it become the focus it should have been, and in a way that isn't quite as satisfying as MIT and CMU were attempting in the 90s. It really was a spectacular time. VR in research labs was, then, ahead of where it is, now, in most respects; certainly for things like molecular dynamics, we viewed it as a given that you'd want to wander around and poke the computed empirical force field for a molecule. I guess the up side is that it should be a lot faster and easier to catch up given the ubiquitous and powerful CPUs of today -- a Raspberry Pi is more powerful than my old SGI Indigo ever was. Just a matter of will and intent if society wants to recover and surpass the progress we made back when, and democratize it much further than it was.
> In summary, it used to be that phones worked without you having to carry them around, but computers only worked if you did carry one around with you. The solution to this inconsistency was to break the way phones worked rather than fix the way computers work.
He's right, it used to be that I could jump from machine to machine in a Unix environment and really the only thing I gave a shit about locally was my login shell. (I started out using Irix in an SGI/AFS environment, so our logins were essentially stateless; since openGL/XGL worked over the wire, I ran demos in DC on hardware in NY just because, and it was fucking great).
I was sad when the majority of businesses and individuals seemingly decided that Microsoft's single-user desktop worldview was preferable to the Bold Old World of Unix and Plan9, which at that point, thanks to things like XGL and the Andrew File System, was quite multi-user and network-centric. This is why Pike's little pearl speaks to me.
The cloud was a good idea 20 years ago, too. But only recently has it become the focus it should have been, and in a way that isn't quite as satisfying as MIT and CMU were attempting in the 90s. It really was a spectacular time. VR in research labs was, then, ahead of where it is, now, in most respects; certainly for things like molecular dynamics, we viewed it as a given that you'd want to wander around and poke the computed empirical force field for a molecule. I guess the up side is that it should be a lot faster and easier to catch up given the ubiquitous and powerful CPUs of today -- a Raspberry Pi is more powerful than my old SGI Indigo ever was. Just a matter of will and intent if society wants to recover and surpass the progress we made back when, and democratize it much further than it was.
Everything you wrote was quite interesting up until the last sentence. Seriously do we really need this tired old OS flamebait crap here?
Edit: @apathy gracefully edited out the offending last sentence so my comment above is no longer valid, however I'll leave here to provide context for the replies below.
Edit: @apathy gracefully edited out the offending last sentence so my comment above is no longer valid, however I'll leave here to provide context for the replies below.
Probably not. However, an OS is a tool, and your tools inevitably shape the way you view what you are working on. I'm going to revise my comment to tone it down, but the fact remains that network-native multiuser OSes (Unix, Plan9) encourage a very different view of the world than desktop-centric single-user OSes (Windows, in particular). That's not really something that needs further explanation if you've seriously used both, and the differences were much, much starker in the late 90s.
Fixed.
If I were implementing such setup today, would AFS still be my best option?
Independence is a virtue. Even in the old phones-as-infrastructure case, there were many times when there was simply no working phone around, or available. Broken down on the road, being in an industrial area of town on the weekend, etc.
If everything your life revolves around requires working and accessible infrastructure to access it, you're going to have times where you're left staring at a connection error screen, or no screen at all. And because the universe hates you, that will happen at the worst possible times. ;-)