4 ms·

They're more expensive first of all. and each one has to be administrated individually, especially if it has a local disk. If the kernel is kept locally, then y

by smorrow 12y ago

They're more expensive first of all. and each one has to be administrated individually, especially if it has a local disk. If the kernel is kept locally, then you have to go around each machine every time you compile a new one. Same thing for applications. Same thing for let's say /usr/dict or something stupid. Plus it's another mechanical component which can fail. If the user directories are local instead of on a central box, then you 1) need to be at a specific one to get your stuff, and you 2) can't just cd into someone else's /usr/*/src and collaborate. The Labs word for timesharing was "communal" computing, if that helps. For a school or company, in which the computers are provided by the organisation itself, the Plan 9 way is very obviously better than insular systems. There's more, but it's another whole tangent. Since you asked, the main Plan 9 paper ("Plan 9 from Bell Labs", 1995) does say "the early focus on having private machines made it difficult for networks of machines to serve as seamlessly as the old monolithic timesharing systems. Timesharing centralized the management and amortization of costs and resources; personal computing fractured, democratized, and ultimately amplified administrative problems." but even more to the point would be: with a terminal, you just plug it in and turn it on.

pmontra 12y ago
Instead of having a common /usr/src/* for a dev team (I remember I had one in the 80s) we have our sources on github now which allows for larger and more distributed dev teams. Not exactly the same way to collaborate but it's solving the same problem with a bigger central server. Time is round, old solutions always resurface with some differences.
cwyers 12y ago
"For a school or company, in which the computers are provided by the organisation itself, the Plan 9 way is very obviously better than insular systems." Only if you can guarantee 100% (or close to) access to high-speed network connections at all time. The value of a computer with meaningful local storage and execution is that it continues to work when the network is gone or isn't performing well. And it takes a lot less bandwidth to send data to a user's computer and let local applications worry about dealing with the data than it is to send a full screen to the user, if you're talking about GUI. You can also smooth out latency issues a lot easier. So I don't think it's obviously better in those cases. But it's very obviously worse OUTSIDE of those institutions. Here's Pike's description of his dream setup[1]: "I want no local storage anywhere near me other than maybe caches. No disks, no state, my world entirely in the network. Storage needs to be backed up and maintained, which should be someone else's problem, one I'm happy to pay to have them solve. Also, storage on one machine means that machine is different from another machine. At Bell Labs we worked in the Unix Room, which had a bunch of machines we called 'terminals'. Latterly these were mostly PCs, but the key point is that we didn't use their disks for anything except caching. The terminal was a computer but we didn't compute on it; computing was done in the computer center. The terminal, even though it had a nice color screen and mouse and network and all that, was just a portal to the real computers in the back. When I left work and went home, I could pick up where I left off, pretty much. My dream setup would drop the "pretty much" qualification from that." That's fine, so long as all you want to do on your home computer is do more work. But that's such an incredibly narrow vision of computing. The truly personal computer enabled a lot of things that weren't possible under the old dumb terminal model Pike pines for, and has made computers accessible to many more people. We'll continue to get some of the benefits of this as the "cloud" continues to be integrated into things, but I don't think we're going back to the "communal" computing model, and if we do, it's going to be because someone looks at the benefits of the personal computer model and finds a way to provide them in the communal model, rather than sitting there and pining about how it was in the old days before the peasants ruined everything. 1) http://rob.pike.usesthis.com/ http://rob.pike.usesthis.com/, thanks to tjgq for providing the link below
- smorrow 12y ago
  > dumb terminal > send a full screen to the user I think you're confusing Plan 9 with thin clients. Even the Blit in the video was a smart terminal ("you can run programs on it"). The way Plan 9 works is > send data to a user's computer and let local applications worry about dealing with the data. It was apparently different in the 90's ("terminal was a computer but we didn't compute on it") but nowadays in Plan 9 you do nearly everything on the terminal. For different reasons: the WM, the browsers, the editors run on the terminal for responsiveness; image and music decoders run on the terminal because they need a higher bandwidth to the screen/speakers than to the fs (jpegs, mp3s, etc are compressed); plumber and factotum run on your terminal so that you get exactly one instance of them per session, and that they die as soon as you end your session. The central boxes are only really used for FS/backup, auth, cron, maybe mail servers or whatever. So nearly everything runs on the terminal, but it's a Plan 9 terminal so it's still just a matter of plug it in, turn it on, set up netbooting (once). > it's very obviously worse OUTSIDE of those institutions. What I was going to say before I decided that it was too much of a tangent was: and Plan 9 NOT being a proper distributed OS could be a plus: it's possible to use recover(4) or lapfs(4) and bring the laptop outside the network. No-one actually does that, and lapfs isn't even a real Plan 9 program in C. but it's still made feasible by the fact that your editor and so on is not on the far side of a connection and isn't going to go anywhere. unlike on e.g. an Amoeba terminal, which really is just a window manager, no editors locally, no browsers or viewers. I dunno about using "backup" to describe the Plan 9 file server, but that's even more unrelated to my original comment.

by smorrow 12y ago

pmontra 12y ago

Instead of having a common /usr/src/* for a dev team (I remember I had one in the 80s) we have our sources on github now which allows for larger and more distributed dev teams. Not exactly the same way to collaborate but it's solving the same problem with a bigger central server. Time is round, old solutions always resurface with some differences.

cwyers 12y ago

"For a school or company, in which the computers are provided by the organisation itself, the Plan 9 way is very obviously better than insular systems." Only if you can guarantee 100% (or close to) access to high-speed network connections at all time. The value of a computer with meaningful local storage and execution is that it continues to work when the network is gone or isn't performing well. And it takes a lot less bandwidth to send data to a user's computer and let local applications worry about dealing with the data than it is to send a full screen to the user, if you're talking about GUI. You can also smooth out latency issues a lot easier. So I don't think it's obviously better in those cases. But it's very obviously worse OUTSIDE of those institutions. Here's Pike's description of his dream setup[1]: "I want no local storage anywhere near me other than maybe caches. No disks, no state, my world entirely in the network. Storage needs to be backed up and maintained, which should be someone else's problem, one I'm happy to pay to have them solve. Also, storage on one machine means that machine is different from another machine. At Bell Labs we worked in the Unix Room, which had a bunch of machines we called 'terminals'. Latterly these were mostly PCs, but the key point is that we didn't use their disks for anything except caching. The terminal was a computer but we didn't compute on it; computing was done in the computer center. The terminal, even though it had a nice color screen and mouse and network and all that, was just a portal to the real computers in the back. When I left work and went home, I could pick up where I left off, pretty much. My dream setup would drop the "pretty much" qualification from that." That's fine, so long as all you want to do on your home computer is do more work. But that's such an incredibly narrow vision of computing. The truly personal computer enabled a lot of things that weren't possible under the old dumb terminal model Pike pines for, and has made computers accessible to many more people. We'll continue to get some of the benefits of this as the "cloud" continues to be integrated into things, but I don't think we're going back to the "communal" computing model, and if we do, it's going to be because someone looks at the benefits of the personal computer model and finds a way to provide them in the communal model, rather than sitting there and pining about how it was in the old days before the peasants ruined everything. 1) http://rob.pike.usesthis.com/ http://rob.pike.usesthis.com/, thanks to tjgq for providing the link below

smorrow 12y ago
> dumb terminal > send a full screen to the user I think you're confusing Plan 9 with thin clients. Even the Blit in the video was a smart terminal ("you can run programs on it"). The way Plan 9 works is > send data to a user's computer and let local applications worry about dealing with the data. It was apparently different in the 90's ("terminal was a computer but we didn't compute on it") but nowadays in Plan 9 you do nearly everything on the terminal. For different reasons: the WM, the browsers, the editors run on the terminal for responsiveness; image and music decoders run on the terminal because they need a higher bandwidth to the screen/speakers than to the fs (jpegs, mp3s, etc are compressed); plumber and factotum run on your terminal so that you get exactly one instance of them per session, and that they die as soon as you end your session. The central boxes are only really used for FS/backup, auth, cron, maybe mail servers or whatever. So nearly everything runs on the terminal, but it's a Plan 9 terminal so it's still just a matter of plug it in, turn it on, set up netbooting (once). > it's very obviously worse OUTSIDE of those institutions. What I was going to say before I decided that it was too much of a tangent was: and Plan 9 NOT being a proper distributed OS could be a plus: it's possible to use recover(4) or lapfs(4) and bring the laptop outside the network. No-one actually does that, and lapfs isn't even a real Plan 9 program in C. but it's still made feasible by the fact that your editor and so on is not on the far side of a connection and isn't going to go anywhere. unlike on e.g. an Amoeba terminal, which really is just a window manager, no editors locally, no browsers or viewers. I dunno about using "backup" to describe the Plan 9 file server, but that's even more unrelated to my original comment.