From mboxrd@z Thu Jan 1 00:00:00 1970 MIME-Version: 1.0 In-Reply-To: <2972B139-9F41-4F6F-B906-7249E0B5CCCF@vaughan.pe> References: <703b2539-027e-4f9f-a739-00b59f6d3d82@v28g2000vbb.googlegroups.com> <20101113192425.GC22589@nibiru.local> <20101114091030.GA793@polynum.com> <4CDFBF0D.1060604@gmx.net> <2972B139-9F41-4F6F-B906-7249E0B5CCCF@vaughan.pe> Date: Mon, 15 Nov 2010 10:48:11 -0500 Message-ID: From: Dan Cross To: Fans of the OS Plan 9 from Bell Labs <9fans@9fans.net> Content-Type: text/plain; charset=UTF-8 Subject: Re: [9fans] Plan9 development Topicbox-Message-UUID: 7eed8624-ead6-11e9-9d60-3106f5b1d025 On Sun, Nov 14, 2010 at 11:29 PM, Gary V. Vaughan wrote: > You can either try to remember what all of those are, or use something > like autoconf to probe for known bugs, and gnulib to plug them, or > you can link against a shim library like GNU libposix which will > do all of that automatically when it is built and installed, allowing > you to write to the POSIX APIs with impunity. I've read this discussion with interest. Something that strikes me is that there are certain underlying beliefs and assumptions in the Plan 9 community that are taken for granted and rarely articulated, but that frame many of the comments from 9fans. Further, those are, in many ways, contrary to the assumptions and requirements Gary is constrained by when working on libtool. I believe that one of the most powerful decisions that the original plan 9 developers made was consciously resisting backwards compatibility with Unix. That's not to say that they completely ignored it, or that it was actively worked against, but that it was not a primary consideration and did not (overly) constrain either design or implementation. This freed them to revisit assumptions, rethink many of the decisions in the base system, and clean up a lot of rough edges. For instance, and relevant to this discussion, take a look at how cross-compilation and platform independence on Plan 9 "just works" in a simple, consistent way across multiple architectures. I was surprised how an earlier message in this discussion when Gary said, > If you have never tried to build and link shared libraries from the same > code-base on 30 (or even 3) separate incompatible architectures, then > you are probably missing the point, and needn't read any further. Granted, I think the key thing here is that Gary's talking about shared libraries (which, as Russ said, the Plan 9 developers simply punted on), instead of just building, but I can't help but feel that this overlooks part of the plan 9 way of doing things. The plan 9 developers made a decision to break with the convention of naming object files with a ".o" extension, assigned a letter to each archicture, established the convention that object files and libraries would use that letter in their filenames, and renamed the compiler, assembler and linker accordingly. Then they modified the filesystem hierarchy to have archiecture specific directory trees for architecture specific things (which is easy to do with you've got mutable namespaces). Mk was smart enough that these conventions could be used in the build system pretty easily. None of these are name changes are particularly deep; in many ways, they are simply cosmetic. However, they led to a simplification that makes building for different architectures out of the same tree nearly trivial. Just by setting an environment variable, I can build the entire system for a different architecture, in the same tree, with a single command, with no conflicts. Since the compiler for each architecture is just another program, cross-compilation isn't special or complicated. Compare this to setting up gcc for cross compilation. And that's sort of the point. 9fans tend not to ask, "how can I make this work across multiple systems that are immutable as far as I'm concerned as a developer" but rather they ask, "how can the system support me doing this in a simpler, orthogonal, more consistent way?" If that means shedding some convention and replacing it with something else that makes life easier, there's less hesitation to do that. To that end, libtool, autoconf and automake, etc, all seem to answer the wrong question. From the 9fans perspective (and take this with a grain of salt; I can't claim to speak for all of us), libtool seems "crazy" because it puts a bandaid on a wart instead of trying to solve the underlying problem of complex, inconsistent interfaces across systems. In this way, it is reactionary. Autoconf et al are analogous to a bunch of nested #ifdef's, and most 9fans would chose to program to some sort of shim library that provided a consistent interface as a matter of course. Better yet, they'd go fix the underlying systems so that they correctly implemented the relevant standard or interface. I'm not sure that's possible with Unix, as Gary rightly points out, because of the weight of the installed base, fragmentation between variants and the requirements of backwards compability. Though unrealistic, it's certainly idealistic. One of the enduring benefits of Plan 9 is that it is (still) a good example of how well-reasoned engineering tradeoffs and a modicum of good taste can produce a powerful and elegant system with a simple implementation. Rob Pike is (in?)famously quoted as saying, "not only is Unix dead, it's starting to smell really bad" (note to Rob: is this apocryphal? I've never found an original source). I think that's often taken out of context; Unix may be dead as an exciting venue for the exploration of fundamentally new ways of doing things, for all the reasons that have been mentioned. That doesn't mean it's not useful for getting real work done. In this sense it's more like a large wooden support beam; it's dead in the sense that the tree it came from (presumably) isn't growing anymore, even though the beam serves some useful purpose. Libtool is more inline with this view of the world. It facilitates divergent systems doing useful things (in the sense of end-users finding those systems useful; my mom could care less what hardware and software platform gmail runs on, as long as she can communicate with family and friends). It fits the world view of the massive number of developers who are already familiar with the Unix and Linux model and who aren't particularly interested in other models. But it's not exciting as tool for figuring out how to make those systems better in and of themselves. The assumptions that 9fans make are that the latter is more important than the former. Sorry, this was long-winded. - Dan C.