4 ms·

Evolution of the Unix System Architecture: An Exploratory Case Study

46 points by rodrigo975 3y ago

dmvdoug 3y ago
This kind of thing, studying the history of a complex system in order to try to derive generalizable conclusions about large, complex systems in general, seems to me to be such a fool’s errand. Much better to study it in all the richness and complexity of its historical context to understand how it, specifically, came about, not to try to predict how future complex systems will evolve.
- dmvdoug 3y ago
  That said, there’s a very nice “timeline of Unix’s major releases and architectural design decisions” (figure 1) on p. 1138.
- vincent-manis 3y ago
  I don't know how else one can have anything useful to say about how software systems evolve. One can question the methodology used, especially given that the source data was sketchy (they are counting entities from code in some editions, and manual pages in others), but at least we get some insights into how Unix evolved. What would be interesting would be to compare these results with those from a similar system of similar age. IBM's IMS system (1966—) comes to mind. Again, not a perfect match (IMS was and is developed by IBM, while Unix is the result of work at many sites). Unfortunately, since IMS is proprietary, I imagine there would be difficulties in gathering data.
  - ngcc_hk 3y ago
    Totally agree. History does not repeat And study history is not about prediction. It is about learning. In a sense perhaps we never learn from our mistakes totally and keep on loop on our karma. But still might be helpful. After all we are dealing with complex systems, from human body to society. These artificial one help and by itself interesting.
    - dmvdoug 3y ago
      I think your comment means you agree with me, not the comment you responded to, because it sounds like we share the same position: "History does not repeat And study history is not about prediction." :)
  - dmvdoug 3y ago
    You... study how they evolve, in context. You're going to have to go do real historical research. Read the documentation and source code, absolutely. But also read emails, get access to participants' papers, interview participants, study the environment(s) in which the software grew up and spread, study the background contexts (what else was happening in computing at the time: licensing, etc.), and so forth. Do real history, in other words. This is one of the major flaws of research on software history to this day, and it's not like I'm making this up on my own. Real historians who study computer history have commented on this problem. Software history needs to be treated like... history and studied accordingly.

46 points by rodrigo975 3y ago

This kind of thing, studying the history of a complex system in order to try to derive generalizable conclusions about large, complex systems in general, seems to me to be such a fool’s errand. Much better to study it in all the richness and complexity of its historical context to understand how it, specifically, came about, not to try to predict how future complex systems will evolve.

dmvdoug 3y ago
That said, there’s a very nice “timeline of Unix’s major releases and architectural design decisions” (figure 1) on p. 1138.
vincent-manis 3y ago
I don't know how else one can have anything useful to say about how software systems evolve. One can question the methodology used, especially given that the source data was sketchy (they are counting entities from code in some editions, and manual pages in others), but at least we get some insights into how Unix evolved. What would be interesting would be to compare these results with those from a similar system of similar age. IBM's IMS system (1966—) comes to mind. Again, not a perfect match (IMS was and is developed by IBM, while Unix is the result of work at many sites). Unfortunately, since IMS is proprietary, I imagine there would be difficulties in gathering data.
- ngcc_hk 3y ago
  Totally agree. History does not repeat And study history is not about prediction. It is about learning. In a sense perhaps we never learn from our mistakes totally and keep on loop on our karma. But still might be helpful. After all we are dealing with complex systems, from human body to society. These artificial one help and by itself interesting.
  - dmvdoug 3y ago
    I think your comment means you agree with me, not the comment you responded to, because it sounds like we share the same position: "History does not repeat And study history is not about prediction." :)
- dmvdoug 3y ago
  You... study how they evolve, in context. You're going to have to go do real historical research. Read the documentation and source code, absolutely. But also read emails, get access to participants' papers, interview participants, study the environment(s) in which the software grew up and spread, study the background contexts (what else was happening in computing at the time: licensing, etc.), and so forth. Do real history, in other words. This is one of the major flaws of research on software history to this day, and it's not like I'm making this up on my own. Real historians who study computer history have commented on this problem. Software history needs to be treated like... history and studied accordingly.