17 ms·

The Good, the Bad, and the Ugly: The Unix Legacy (by Rob Pike)

24 points by silentbicycle 18y ago

amanfredi 18y ago
I was looking forward to reading the comments on this after finishing reading the presentation, but there aren't any yet!
- windsurfer 18y ago
  Well there are now!
ars 18y ago
And it has some horrible mistakes: (Ugly) The preprocessor Conditional compilation Quite disagree - this feature is what makes C programs so portable. And yes I saw the thing about Plan 9 compiling a kernel for all arch's with no ifdefs - well they only way you can do that is by cheating and either making your own preprocessor, or a fancy makefile. So big whoop. I read some more, but rapidly came to the conclusion that this is unreadable without the associated (verbal) commentary.
- silentbicycle 18y ago
  Elsewhere in the plan9 writings, Rob Pike says that he structured it by putting all of the stuff that would need to be ported in one group of files (which export the same interface), conditionally compiling the relevant subset of those, and then writing everything else in terms of those. (A better packaging/namespace system could handle this much more elegantly, though.) Also, the C preprocessor is largely ignorant of C syntax. Am I the only one who finds that incredibly strange?
  - vorador 18y ago
    What would be the advantages of a preprocessor knowing the syntax ?
    - silentbicycle 18y ago
      While it probably wouldn't be as useful as Lisp macros, due to the comparatively complex syntax, it would at least avoid bugs involving things like #define macros that evaluate their arguments multiple times. OTOH, not having the C pp tied to C means it can be used for other stuff. The only thing I can think of offhand that uses it is the BSD calendar system, though, and that's largely just #include.
  - philwelch 18y ago
    If the preprocessor knew the syntax, it would happen after parsing rather than before, which is exactly how every language other than C handles things that C handles using the preprocessor (turning "using" or "include" or "import" into keywords instead of preprocessor directives). I'm really not sure in what way it would be a pre-processor at that point. So perhaps it's more accurate to say preprocessors aren't particularly useful.
- beza1e1 18y ago
  His point is to use C instead of the preprocessor. #ifdef MIPS mips_stuff(); #endif should be if (MIPS) { mips_stuff(); } Even a mediocre compiler should be able to eliminate the then-body in the non-MIPS case. Another possibility is to generate the same symbols in every architecture specific component and link the one you want to use.
- devin 18y ago
  "And yes I saw the thing about Plan 9 compiling a kernel for all arch's with no ifdefs - well they only way you can do that is by cheating and either making your own preprocessor, or a fancy makefile. So big whoop." I think that's a rather reductionist assessment. See: http://ntu.csie.org/~piaip/plan9/archives/000005.html http://ntu.csie.org/~piaip/plan9/archives/000005.html
  - ars 18y ago
    "Conditional compilation, even with #ifdef, is used sparingly in Plan 9. The only architecture-dependent #ifdefs in the system are in low-level routines in the graphics library." So, in other words - yah, you need need a preprocessor with ifdef's, because sometimes there is no other way to do it. And in other places he basically says he avoided ifdef's by using a fancy makefile, which doesn't seem an improvement to me, since the makefile essentially becomes a (less flexible) pre-processor. The point about dead-branch pruning instead of ifdef is well taken though. (But there are cases where that doesn't work.)
andeka 18y ago
1. What is the best thing about Unix? A: The community. 2. What is the worst thing about Unix? A: That there are so many communities. Learning the insides of things is what got me into UNIX. I wanted to know how hardware and operating systems worked together. Rooted in academia and science, the community and culture drew me in, It is a problem solvers platform. You will find many a startup trying to make their dream come true by hacking together their idea in C/Linux. Microsoft may develop a great business application platform. But if you want to learn and experiment with new computer science concepts you have UNIX.
pugio 18y ago
His main point is that a strong community is a strength, but many different communities leads to too many fragmented (and incompatible) codebases and ideas. Some counterpoints: 1. The number of different implementations grew as the number of available computers and users grew. The number of smart people using each distro nowadays is probably still more than the total number of users of some of the original Unix implementations - the same implementations he says spawned the most good ideas. 2. Many different distros allows for many different ideas and paradigms to be tried out. Over time, the best ideas will escape their parent communities and become adopted by all the major versions. Ideas that may never have gained traction in one massive community might find purchase in some of these splinter groups. The fracturing of the distros was a natural and necessary step in the evolution of the nix system. Yes, Microsoft managed to assert its dominance because it presented a single unified solution, but its heyday is nearing an end. Slowly, the myriad good ideas coming from the countless nix's are again unifying into a very strong front. Mac OS X (FreeBSD Unix) and Ubuntu (Debian Linux) are two great examples of how many different ideas have coalesced into a pleasing and usable system. Rob Pike ends his message with an injunction to the Unix users of the world to unite, to work together as opposed to walling themselves off in their own segmented communities. While I think the segmentation was beneficial and necessary, I do agree that a strong effort towards unifying the current crop of ideas into a uniform package is beneficial, if only to provide a seed for a whole new set of distros splintering off in new and unique directions.
- thisrod 18y ago
  "Over time, the best ideas will escape their parent communities and become adopted by all the major versions." It's taking a very long time. At the current rate of transfer, Linux will take the whole 21st century to absorb the progress Plan 9 made in the 1980s. What I hope will happen, is that Linux will focus on the traditional OS role of abstracting hardware, and become purely a hypervisor system. That would exploit its strengths: the vast collection of device drivers, and systems such as network packet munging and LVM. It would provide a sane, consistent hardware interface, that sane, consistent application interfaces such as Plan 9, Oberon, and Alan Kay's new system could easily support.
devin 18y ago
I totally agree with Rob's final statement (Community = Good), (Communities = Bad). In fact, you can apply the same analogy to all sorts of other relevant real world situations. Think: politically, racially, religiously, etc.

24 points by silentbicycle 18y ago

I was looking forward to reading the comments on this after finishing reading the presentation, but there aren't any yet!

windsurfer 18y ago
Well there are now!

ars 18y ago

And it has some horrible mistakes: (Ugly) The preprocessor Conditional compilation Quite disagree - this feature is what makes C programs so portable. And yes I saw the thing about Plan 9 compiling a kernel for all arch's with no ifdefs - well they only way you can do that is by cheating and either making your own preprocessor, or a fancy makefile. So big whoop. I read some more, but rapidly came to the conclusion that this is unreadable without the associated (verbal) commentary.

silentbicycle 18y ago
Elsewhere in the plan9 writings, Rob Pike says that he structured it by putting all of the stuff that would need to be ported in one group of files (which export the same interface), conditionally compiling the relevant subset of those, and then writing everything else in terms of those. (A better packaging/namespace system could handle this much more elegantly, though.) Also, the C preprocessor is largely ignorant of C syntax. Am I the only one who finds that incredibly strange?
- vorador 18y ago
  What would be the advantages of a preprocessor knowing the syntax ?
  - silentbicycle 18y ago
    While it probably wouldn't be as useful as Lisp macros, due to the comparatively complex syntax, it would at least avoid bugs involving things like #define macros that evaluate their arguments multiple times. OTOH, not having the C pp tied to C means it can be used for other stuff. The only thing I can think of offhand that uses it is the BSD calendar system, though, and that's largely just #include.
- philwelch 18y ago
  If the preprocessor knew the syntax, it would happen after parsing rather than before, which is exactly how every language other than C handles things that C handles using the preprocessor (turning "using" or "include" or "import" into keywords instead of preprocessor directives). I'm really not sure in what way it would be a pre-processor at that point. So perhaps it's more accurate to say preprocessors aren't particularly useful.
beza1e1 18y ago
His point is to use C instead of the preprocessor. #ifdef MIPS mips_stuff(); #endif should be if (MIPS) { mips_stuff(); } Even a mediocre compiler should be able to eliminate the then-body in the non-MIPS case. Another possibility is to generate the same symbols in every architecture specific component and link the one you want to use.
devin 18y ago
"And yes I saw the thing about Plan 9 compiling a kernel for all arch's with no ifdefs - well they only way you can do that is by cheating and either making your own preprocessor, or a fancy makefile. So big whoop." I think that's a rather reductionist assessment. See: http://ntu.csie.org/~piaip/plan9/archives/000005.html http://ntu.csie.org/~piaip/plan9/archives/000005.html
- ars 18y ago
  "Conditional compilation, even with #ifdef, is used sparingly in Plan 9. The only architecture-dependent #ifdefs in the system are in low-level routines in the graphics library." So, in other words - yah, you need need a preprocessor with ifdef's, because sometimes there is no other way to do it. And in other places he basically says he avoided ifdef's by using a fancy makefile, which doesn't seem an improvement to me, since the makefile essentially becomes a (less flexible) pre-processor. The point about dead-branch pruning instead of ifdef is well taken though. (But there are cases where that doesn't work.)

andeka 18y ago

1. What is the best thing about Unix? A: The community. 2. What is the worst thing about Unix? A: That there are so many communities. Learning the insides of things is what got me into UNIX. I wanted to know how hardware and operating systems worked together. Rooted in academia and science, the community and culture drew me in, It is a problem solvers platform. You will find many a startup trying to make their dream come true by hacking together their idea in C/Linux. Microsoft may develop a great business application platform. But if you want to learn and experiment with new computer science concepts you have UNIX.

pugio 18y ago

His main point is that a strong community is a strength, but many different communities leads to too many fragmented (and incompatible) codebases and ideas. Some counterpoints: 1. The number of different implementations grew as the number of available computers and users grew. The number of smart people using each distro nowadays is probably still more than the total number of users of some of the original Unix implementations - the same implementations he says spawned the most good ideas. 2. Many different distros allows for many different ideas and paradigms to be tried out. Over time, the best ideas will escape their parent communities and become adopted by all the major versions. Ideas that may never have gained traction in one massive community might find purchase in some of these splinter groups. The fracturing of the distros was a natural and necessary step in the evolution of the nix system. Yes, Microsoft managed to assert its dominance because it presented a single unified solution, but its heyday is nearing an end. Slowly, the myriad good ideas coming from the countless nix's are again unifying into a very strong front. Mac OS X (FreeBSD Unix) and Ubuntu (Debian Linux) are two great examples of how many different ideas have coalesced into a pleasing and usable system. Rob Pike ends his message with an injunction to the Unix users of the world to unite, to work together as opposed to walling themselves off in their own segmented communities. While I think the segmentation was beneficial and necessary, I do agree that a strong effort towards unifying the current crop of ideas into a uniform package is beneficial, if only to provide a seed for a whole new set of distros splintering off in new and unique directions.

thisrod 18y ago
"Over time, the best ideas will escape their parent communities and become adopted by all the major versions." It's taking a very long time. At the current rate of transfer, Linux will take the whole 21st century to absorb the progress Plan 9 made in the 1980s. What I hope will happen, is that Linux will focus on the traditional OS role of abstracting hardware, and become purely a hypervisor system. That would exploit its strengths: the vast collection of device drivers, and systems such as network packet munging and LVM. It would provide a sane, consistent hardware interface, that sane, consistent application interfaces such as Plan 9, Oberon, and Alan Kay's new system could easily support.

devin 18y ago

I totally agree with Rob's final statement (Community = Good), (Communities = Bad). In fact, you can apply the same analogy to all sorts of other relevant real world situations. Think: politically, racially, religiously, etc.