mohta@necom830.cc.titech.ac.jp (Masataka Ohta) (05/16/91)
In article <1991May16.002617.15386@ladc.bull.com> fmayhar@hermes.ladc.bull.com writes: >-> The problem is that NO OS support shared libraries right, perhaps because >-> there is no way to do so. >Again I ask, what do you consider a "right" way to implement them? As opposed >to what you consider a "wrong" way. Ignore existing implementations. I mean, >in the best of all possible worlds, how should shared libraries be implemented. >(And don't say that in the best of all possible worlds, shared libraries >wouldn't exist. See the last paragraph, below.) I say, in a good world, shared libraries shouldn't exist. Because, in a good world, unless someone proof something is really necessary, it shouldn't exist. I have already proved that 1) its space saving is negligible 2) shared libraries dose not help software version up from /etc/hosts to DNS So, why you think shared libraries should exist? >In >other terms, such as ease of maintenance or disk or memory usage (given >that shared libraries' instruction space is sharable) it can be much >more efficient. This is the tradeoff. Some claimed that with examples. And, with their examples, I made measurement and investigation and proved they are wrong. So, there is no tradeoff, so far. Masataka Ohta
sef@kithrup.COM (Sean Eric Fagan) (05/16/91)
In article <196@titccy.cc.titech.ac.jp> mohta@necom830.cc.titech.ac.jp (Masataka Ohta) writes: >I have already proved that > 1) its space saving is negligible It is *not* negligible. It can easily amount to *many* megabytes, with X11, toolkits, and the like. *Each* X application gets many, many Kbytes' worth of code; putting this in a shared library greatly reduces amount of disk space. On a SparcStation 2, in /usr/bin/X11, xterm in dynamically linked, xtex isn't. xterm is about 180k, xtex is 590k. A version of emacs 19 is statically linked, and is over 3MBytes. A program I found called 'xgif'. Static-linked is 270k; a dynamic-linked version (same compiler, just let it use dynamic linking, which was the default) 73k. size says: text data bss dec hex 155648 49152 47376 252176 3d910 xgif 24576 8192 36552 69320 10ec8 xgif.dynalink Let's see... that's a savings of 131072 bytes in text alone, not counting the data. Now, let's be conservative, and say that you have only about, say, a dozen X applications on your system (the X server, xterm, xclock, xbiff, xgif, xtrek, a few programs you've grabbed and compiled). Using shared libraries is a savings of 1572864 bytes. That's 1.5Mbytes. Taking up disk space all of the time, whether the programs are in use or not. That is a *very* conservative estimate. I don't know about you, but I have *definitely* been on systems where even an extra 1Mbyte would have saved a lot of hassle and pain. > 2) shared libraries dose not help software version up > from /etc/hosts to DNS Please tell that to all of the Sun sites who upgrade to using a nameserver simply by installing *one new file* (the shared library). But I forgot: you don't accept the fact that people can code to use the new structures and still use /etc/hosts. -- Sean Eric Fagan | "I made the universe, but please don't blame me for it; sef@kithrup.COM | I had a bellyache at the time." -----------------+ -- The Turtle (Stephen King, _It_) Any opinions expressed are my own, and generally unpopular with others.
rickert@mp.cs.niu.edu (Neil Rickert) (05/16/91)
In article <196@titccy.cc.titech.ac.jp> mohta@necom830.cc.titech.ac.jp (Masataka Ohta) writes: >I say, in a good world, shared libraries shouldn't exist. > > 1) its space saving is negligible > > 2) shared libraries dose not help software version up > from /etc/hosts to DNS > >So, why you think shared libraries should exist? If shared libraries are properly designed, a common set of code in memory is shared by all uses of the shared library. For library routines in use concurrently by only one or two modules, this is no big deal. But anything used by many modules can result in reduced memory requirements for each, and in particular, in reduced virtual storage paging activity. If appropriately used, the reduced paging can be adequate justification. -- =*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*= Neil W. Rickert, Computer Science <rickert@cs.niu.edu> Northern Illinois Univ. DeKalb, IL 60115 +1-815-753-6940
mjr@hussar.dco.dec.com (Marcus J. Ranum) (05/17/91)
sef@kithrup.COM (Sean Eric Fagan) writes: [Re: space savings of shared libraries] >> 1) its space saving is negligible > >[....] It can easily amount to *many* megabytes, with X11, >toolkits, and the like. *Each* X application gets many, many Kbytes' worth >of code; putting this in a shared library greatly reduces amount of disk >space. Heaving X windows out or putting it on a diet would *REALLY* reduce the amount of required disk space. To forestall flamage about all of X' vaunted "functionality" take a look at the size of MGR and the "functionality" it offers before you follow-up, please. Using shared libraries to cure X-windows bloat is really stupid, if you consider that you'll further slow stuff down (depending on the shlib implementation) and you'll still have X slowing your system down, and it'll take a huge amount of effort to get the shared libs *right* - effort that could be spent on a smaller more efficient user interface, if that is what you need. mjr.
sef@kithrup.COM (Sean Eric Fagan) (05/17/91)
In article <1991May16.173305.11403@decuac.dec.com> mjr@hussar.dco.dec.com (Marcus J. Ranum) writes: > Using shared libraries to cure X-windows bloat is really stupid, if >you consider that you'll further slow stuff down (depending on the shlib >implementation) and you'll still have X slowing your system down, and it'll >take a huge amount of effort to get the shared libs *right* - effort that >could be spent on a smaller more efficient user interface, if that is what >you need. I agree. Now, go convince all the customers out there, POSIX, XPG, OSF, FSF, CSRG, OSF, and USL of this. After you've done all of that, then we can talk. For now, X is a (disgusting) fact of life. Now, one can either grumble about it and not do anything, grumble and work on something else, or do something to make it less painful. While the second one is probably best, it is the least realistic. Sad, isn't it? -- Sean Eric Fagan | "I made the universe, but please don't blame me for it; sef@kithrup.COM | I had a bellyache at the time." -----------------+ -- The Turtle (Stephen King, _It_) Any opinions expressed are my own, and generally unpopular with others.
mcnally@wsl.dec.com (Mike McNally) (05/17/91)
In article <196@titccy.cc.titech.ac.jp>, mohta@necom830.cc.titech.ac.jp (Masataka Ohta) writes: |> I have already proved that |> |> 1) its space saving is negligible I have counterexamples. Does that invalidate the proof? |> |> 2) shared libraries dose not help software version up |> from /etc/hosts to DNS When did this particular issue become the critical feature of a shared library implementation? Does this mean that if I have an mechanism for shared libraries that makes everyone happy and solves the Mideast crisis, but doesn't help software go from /etc/hosts to DNS, then I should dump it? |> Some claimed that with examples. And, with their examples, I made |> measurement and investigation and proved they are wrong. So, there is |> no tradeoff, so far. OK, here are my numbers (roughly; the machine is down now so I'll have to get the real ones later): I have sharable libc, libtermcap, libm, libcurses, libX11, libXt, libXaw, libXext, and libXmu, and a bunch of clients (xterm, xclock, twm, bitmap, and a couple others) linked to them. The savings is about 1.5meg, taking into account the fact that all those libraries will be loaded. Prove me wrong. Oh, and I don't have the server linked shared (against libc), nor are my utilites shared yet. I guess you'll tell me that'll just make it worse. -- * "In the Spirit as my automatics, * Mike McNally * Lystra and Zelda were one third * Coolie * as large as the infinite Cosmos." * DEC Western Software Lab * --- D. S. Ashwander * mcnally@wsl.dec.com
mohta@necom830.cc.titech.ac.jp (Masataka Ohta) (05/17/91)
In article <1991May16.200404.29262@kithrup.COM> sef@kithrup.COM (Sean Eric Fagan) writes: >For now, X is a (disgusting) fact of life. Now, one can either grumble >about it and not do anything, grumble and work on something else, or do >something to make it less painful. While the second one is probably best, >it is the least realistic. X is not a fact of life. I am not using X at all and doing many things. I feel no pain. You may not. You may insist on X and continue to use X. So, DO IT PAINFULLY. Even with shared libraries, you are not free from pain. So, don't make us painful by introducing unnecessary shared libraries. Masataka Ohta
mohta@necom830.cc.titech.ac.jp (Masataka Ohta) (05/17/91)
In article <1991May16.083123.26599@kithrup.COM> sef@kithrup.COM (Sean Eric Fagan) writes: First, as I don't think X is necessary, measurement on X is nothing to me. But you may claim I am conservative. >Now, let's be conservative, and say that you have only about, say, a dozen X >applications on your system (the X server, xterm, xclock, xbiff, xgif, >xtrek, a few programs you've grabbed and compiled). Using shared libraries >is a savings of 1572864 bytes. That's 1.5Mbytes. Taking up disk space all >of the time, whether the programs are in use or not. >That is a *very* conservative estimate. I don't think your estimate with xterm, xclock, xbiff, xgif, xtrek, a few programs you've grabbed and compiled, is conservative. Though some people around me use X, they usually only use xterm and sometimes xdvi or xtex. That's all. And, even with your radical example, 1.5Mbytes is negligible for a machine which run xterm, xclock, xbiff, xgif, xtrek, a few programs you've grabbed and compiled. >On a SparcStation 2, in /usr/bin/X11, xterm in dynamically linked, xtex >isn't. How much memory dose YOUR SS2 have? I remember minimum is 16MB, which is much larger than 1.5MB. >> 2) shared libraries dose not help software version up >> from /etc/hosts to DNS >Please tell that to all of the Sun sites who upgrade to using a nameserver >simply by installing *one new file* (the shared library). After changing gethostbyent structure, that is, RECOMPILAION, all of the Sun sites can fully upgrade to DNS, of course. And, as I have proved, the change and, thus, recompilation was necessary because of DNS. >But I forgot: you don't accept the fact that people can code to use the new >structures and still use /etc/hosts. Yes, you forgot I accept. As I already stated for the measurment data of SONY's NWS3800, people can code to use the new structures and still use /etc/hosts with negligible amount of code space. Recompilation is not necessary even if they change mind to use DNS or NIS. The same thing hold with MIPS RISC/OS 4.5. Masataka Ohta
sef@kithrup.COM (Sean Eric Fagan) (05/17/91)
And now we see the One True Way for all operating systems to go: whatever Masataka Ohta says. Witness: In article <200@titccy.cc.titech.ac.jp> mohta@necom830.cc.titech.ac.jp (Masataka Ohta) writes: >X is not a fact of life. >I am not using X at all and doing many things. I feel no pain. >You may not. >You may insist on X and continue to use X. >So, DO IT PAINFULLY. >Even with shared libraries, you are not free from pain. This is the man who denied he was being close-minded earlier. -- Sean Eric Fagan | "I made the universe, but please don't blame me for it; sef@kithrup.COM | I had a bellyache at the time." -----------------+ -- The Turtle (Stephen King, _It_) Any opinions expressed are my own, and generally unpopular with others.
sef@kithrup.COM (Sean Eric Fagan) (05/17/91)
In article <201@titccy.cc.titech.ac.jp> mohta@necom830.cc.titech.ac.jp (Masataka Ohta) writes: >I don't think your estimate with xterm, xclock, xbiff, xgif, xtrek, a few >programs you've grabbed and compiled, is conservative. I usually run xterm, xclock, xbiff, and, occasionally, emacs; some previous coworkers also would run xtrek and/or xconq. One would run an x-based gif viewer almost constantly. When I'm in a development mood, I can easily run several other X applications (InterViews, actually, usually). >And, even with your radical example, 1.5Mbytes is negligible for a machine >which run xterm, xclock, xbiff, xgif, xtrek, a few programs you've grabbed >and compiled. No, it's not. I've been on machines, doing *all* of that, that had 6Mbytes. Granted, I tended to cut down what I was doing real quick, *because the X code was so large*. >How much memory dose YOUR SS2 have? I remember minimum is 16MB, which >is much larger than 1.5MB. Not when you have 13+ people working on it, most doing something with xterms, quite a few doing some development with X. When are you going to understand something: just because *you* don't use something, does not mean that nobody else wants to, or that it's not a good thing for other people. For example, some people like keeping short-lived (but longer lived than the next boot cycle) things in /tmp... -- Sean Eric Fagan | "I made the universe, but please don't blame me for it; sef@kithrup.COM | I had a bellyache at the time." -----------------+ -- The Turtle (Stephen King, _It_) Any opinions expressed are my own, and generally unpopular with others.
mohta@necom830.cc.titech.ac.jp (Masataka Ohta) (05/17/91)
In article <1991May16.135009@wsl.dec.com> mcnally@wsl.dec.com writes: >|> 2) shared libraries dose not help software version up >|> from /etc/hosts to DNS >When did this particular issue become the critical feature of a shared >library implementation? The critical feature? No. Please follow the thread of discusison. Those who support shared libraries claimed it is good for software upgrade. I disagreed. Usual software upgrade is not so simple. As THEIR (not mine) example was introduction of DNS, I proved they are wrong. >Does this mean that if I have an mechanism for >shared libraries that makes everyone happy and solves the Mideast crisis, >but doesn't help software go from /etc/hosts to DNS, then I should dump >it? Those who claimed shared libraries good because they help software upgrade such as from /etc/hosts to DNS has lost. Masataka Ohta
barmar@think.com (Barry Margolin) (05/17/91)
In article <202@titccy.cc.titech.ac.jp> mohta@necom830.cc.titech.ac.jp (Masataka Ohta) writes: >Those who support shared libraries claimed it is good for software upgrade. >I disagreed. Usual software upgrade is not so simple. As THEIR (not mine) >example was introduction of DNS, I proved they are wrong. There are two kinds of software upgrades: those which change the interface to the library, and those which only change the implementation. Most of the common shared library designs only make the second kind simple. That's certainly better than nothing. Note that an upgrade to use the DNS didn't *have* to include support for multiple addresses. It just so happened that the implementors chose to make both changes at the same time, because the ability to access more hosts made this misfeature more noticeable. I believe they also enhanced the /etc/hosts version of the routine to return multiple addresses (our /etc/hosts file has several host names with multiple addresses). Shared libraries help with the conversion to DNS, but not with the conversion to multiple addresses. In Multics, library design guidelines also make the first kind easy. Most library routines with non-trivial parameters take most of the parameters as a pointer to a structure. By convention, the first member of the structure is a version number or version string (in the 80's we started using an 8-character string containing a structure-specific prefix and a version suffix, so that structures would be recognizable in memory dumps). The library routine can look at the version number and determine whether it is being called with an old version of the parameter structure, and then emulate the old version of the routine (or return an error code if support for that version has been dropped, which was rare for documented library routines). Some old programs that predated the version conventions look at the contents of the structure and use heuristics to decide whether it's an old or new version. For instance, if the original version of the structure starts with a number that should never be negative, an upgrade might implement versioning by requiring that a negative number be placed there, followed by a version string. The library routine would emulate the old version when the structure begins with a non-negative number, but look at the explicit version string if it's negative. -- Barry Margolin, Thinking Machines Corp. barmar@think.com {uunet,harvard}!think!barmar
boyd@prl.dec.com (Boyd Roberts) (05/17/91)
Ahh bugger it... Time to post... The only reason I'd want a shared library is so I can modify a routine and then not have to re-compile the universe. That would be neat. It is only in these latter days that the problem of software bloat would persuade me that a shared library would be a good idea in an effort to save resources. Remove the bloat (although it's a bit late now) and I don't have the need. But, you still need a shared and non-shared library. /etc/init should not use a shared library. Sure, you organise it so it would work with a shared library, but the consequences of a damaged root file-system could be severe. Implementation: Now that's hard. You have to think about this problem carefully (otherwise you end up with a mess like SysVile shared libs -- pus). It may not be hard to implement, but you have to think about it first. Get it wrong and you have a (possibly non-portable) mess. This discussion is tedious. Boyd Roberts boyd@prl.dec.com ``When the going gets wierd, the weird turn pro...''
boyd@prl.dec.com (Boyd Roberts) (05/17/91)
In article <200@titccy.cc.titech.ac.jp>, mohta@necom830.cc.titech.ac.jp (Masataka Ohta) writes: > > Even with shared libraries, you are not free from pain. > Just depends on how much Jack Daniels you've had. Boyd Roberts boyd@prl.dec.com ``When the going gets wierd, the weird turn pro...''
mohta@necom830.cc.titech.ac.jp (Masataka Ohta) (05/20/91)
In article <1991May17.053735.2123@kithrup.COM> sef@kithrup.COM (Sean Eric Fagan) writes: >>How much memory dose YOUR SS2 have? I remember minimum is 16MB, which >>is much larger than 1.5MB. >Not when you have 13+ people working on it, most doing something with >xterms, quite a few doing some development with X. If you have 13+ people, you have very few merit (if any) with shared libraries. As text of a binary is shared and most are using xterm, the same binary is shared. The total amount of extra memory is still 1.5MB, which is much more negligible compared to the total amount of memory which is large enough (perhaps 32~64MB) to hold data area of 13+ people. >When are you going to understand something: just because *you* don't use >something, does not mean that nobody else wants to, or that it's not a good >thing for other people. I say we shouldn't use shared libraries because it is no good. >For example, some people like keeping short-lived >(but longer lived than the next boot cycle) things in /tmp... For what exmaple? Do you want to claim keeping short-lived things in /tmp is a bad habit? Strange. Though I don't do that, it is OK for someone else to do so. Masataka Ohta
mohta@necom830.cc.titech.ac.jp (Masataka Ohta) (05/20/91)
In article <1991May17.075555.29787@Think.COM> barmar@think.com writes: >>Those who support shared libraries claimed it is good for software upgrade. >>I disagreed. Usual software upgrade is not so simple. As THEIR (not mine) >>example was introduction of DNS, I proved they are wrong. >There are two kinds of software upgrades: those which change the interface >to the library, and those which only change the implementation. >Most of the common shared library designs only make the second kind simple. >That's certainly better than nothing. And, my claim is that the second kind is almost nothing. Your (those who support shared libraries) example of DNS prove that. Most software upgrade is a little more complex than can be processed by mere library change. >I believe they also enhanced >the /etc/hosts version of the routine to return multiple addresses (our >/etc/hosts file has several host names with multiple addresses). You believe what? No. They didn't do so. You should not have said what you believe. Instead, see lib/libc/net/hosttable/gethostnamadr.c of 4.3BSD source. There is only one IP address entry provided for gethostbyname(). As you don't know enough about host name look up and accompanied complexities of its management, don't say: >Note that an upgrade to use the DNS didn't *have* to include support for >multiple addresses. unless you want to be dishonest. >In Multics, library design guidelines also make the first kind easy. Most >library routines with non-trivial parameters take most of the parameters as >a pointer to a structure. By convention, the first member of the structure >is a version number or version string The only parameter for gethostbyname() is, trivially, a string. Masataka Ohta
fmayhar@hermes.ladc.bull.com (Frank Mayhar) (05/21/91)
In article <196@titccy.cc.titech.ac.jp>, mohta@necom830.cc.titech.ac.jp (Masataka Ohta) writes:
-> In article <1991May16.002617.15386@ladc.bull.com> I write:
-> >Again I ask, what do you consider a "right" way to implement them? As opposed
-> >to what you consider a "wrong" way. Ignore existing implementations. I mean,
-> >in the best of all possible worlds, how should shared libraries be implemented.
-> >(And don't say that in the best of all possible worlds, shared libraries
-> >wouldn't exist. See the last paragraph, below.)
->
-> I say, in a good world, shared libraries shouldn't exist.
Go back and reread what I wrote. You're copping out.
-> Because, in a good world, unless someone proof something is really
-> necessary, it shouldn't exist.
OK, then, I have a counterargument: Computers aren't necessary. You can
do just as well (albeit somewhat more slowly) using pencil and paper. After
all, people got by without computers for thousands of years.
Define "necessary." Are 1-gigabyte disks "necessary?" What don't you use
a teletype, a CRT isn't really "necessary," is it?
-> I have already proved that
-> 1) its space saving is negligible
I beg to differ. There is clear evidence that the savings, in both disk and
memory, is significant. The larger the system, and the more users it has, the
more significant the savings becomes. I'll let the statistics posted by Sean
and Nick speak for themselves. Even with the overhead of such things as
indirect jumps, there are still significant savings.
-> 2) shared libraries dose not help software version up
-> from /etc/hosts to DNS
So what? And, in fact, in certain situations, it does. I was able to go from
/etc/hosts to DNS by adding _one_ shared library to my Sun. And I didn't have
to recompile or relink a _single_ program. I think that that's significant.
And many other kinds of upgrades are made much simpler by using shared
libraries. You can replace a single library instead of replacing dozens of
applications.
-> So, why you think shared libraries should exist?
See above, and my original post.
-> >In
-> >other terms, such as ease of maintenance or disk or memory usage (given
-> >that shared libraries' instruction space is sharable) it can be much
-> >more efficient. This is the tradeoff.
-> Some claimed that with examples. And, with their examples, I made
-> measurement and investigation and proved they are wrong. So, there is
-> no tradeoff, so far.
Funny, I didn't see any sort of proof. I saw a number of flat statements,
unsupported by data of any kind, but no proof. What is your proof that it
saves neither disk space, memory, nor maintenance time? I challenge you to
back up your assertions with real data.
I reiterate: There is a tradeoff in the implementation of shared libraries
between various forms of efficiency, e.g. runtime versus memory or disk
savings, etc., but this certainly does not obviate the need for them. Like
anything else with tradeoffs, there are arguments both for and against shared
libraries. The thing to remember, though, for people in both camps is that
while shared libraries are extremely useful in certain situations, they
aren't always the best solution, in all cases.
Of course, this is probably falling on deaf ears, as it appears that both
this issue and the utility of windowing systems are religious issues to
you.
--
Frank Mayhar fmayhar@hermes.ladc.bull.com (..!{uunet,hacgate}!ladcgw!fmayhar)
Bull HN Information Systems Inc. Los Angeles Development Center
5250 W. Century Blvd., LA, CA 90045 Phone: (213) 216-6241barmar@think.com (Barry Margolin) (05/21/91)
In article <211@titccy.cc.titech.ac.jp> mohta@necom830.cc.titech.ac.jp (Masataka Ohta) writes: >In article <1991May17.075555.29787@Think.COM> barmar@think.com writes: >>There are two kinds of software upgrades: those which change the interface >>to the library, and those which only change the implementation. >And, my claim is that the second kind is almost nothing. ... >Most software upgrade is a little more complex than can be processed by >mere library change. How many standard C and Unix library functions have had changes to their interface? I'm sure there have been some changes over the years to the implementations of most of these library routines, but the interfaces have stayed nearly constant. >>I believe they also enhanced >>the /etc/hosts version of the routine to return multiple addresses (our >>/etc/hosts file has several host names with multiple addresses). > >You believe what? No. They didn't do so. Thank you for correcting me. >You should not have said what you believe. If I shouldn't say what I believe, what should I say? Everything else is things that I don't believe, and saying them would be lying. > Instead, see >lib/libc/net/hosttable/gethostnamadr.c of 4.3BSD source. There is only >one IP address entry provided for gethostbyname(). I think I may have been confusing the /etc/hosts version with Sun's YP version. We don't use the DNS version of gethostbyname(), but I've been told that our Suns will use both addresses. >As you don't know enough about host name look up and accompanied complexities >of its management, don't say: > >>Note that an upgrade to use the DNS didn't *have* to include support for >>multiple addresses. > >unless you want to be dishonest. What I meant was just as the /etc/hosts version ignores multiple addresses, the designers of the DNS version could have decided to return only one address, in order to leave the interface the same. Note that the predecessor to the Domain system, the standard HOSTS.TXT file, supported multiple host addresses; it's not new to the DNS, except in the BSD implementation. The original gethostbyname() designers clearly screwed up when they had it only return one address. >>In Multics, library design guidelines also make the first kind easy. Most >>library routines with non-trivial parameters take most of the parameters as >>a pointer to a structure. By convention, the first member of the structure >>is a version number or version string > >The only parameter for gethostbyname() is, trivially, a string. If the structure to be filled in were an in-out parameter, as we generally did in Multics, then the version number could be put there. For library routines that allocate their output structure we would pass the expected version as a separate parameter. The Multics calling sequence also includes the number of arguments, and often includes the argument types (whenever the function is "varargs" or any of the arguments has variable length), so a function could look at the number and types of arguments and infer the version of the caller. No, it's not easy to retrofit these calling conventions onto an established system. These problems are, in my opinion, a legacy of Unix's simplistic original design. On Multics, dynamic linking is used extensively, with many users having personal versions of various library routines, and there were few problems from these interface enhancements. It just requires reasonable system design. -- Barry Margolin, Thinking Machines Corp. barmar@think.com {uunet,harvard}!think!barmar
jim@segue.segue.com (Jim Balter) (05/22/91)
In article <211@titccy.cc.titech.ac.jp> mohta@necom830.cc.titech.ac.jp (Masataka Ohta) writes: >Your (those who support shared libraries) example of DNS prove that. If the example offered to support shared libraries doesn't do so, then it is by definition a bad example and proves nothing. A bad argument for something is not a good argument against it. You are clearly engaging in rhetorical games. This likewise has no bearing upon the accuracy of your position, but will necessarily affect how it is received. More substantively, there are plenty of examples where the interface is well defined, and it is possible to make desired changes to the implementation merely by replacing the library. Even if I personally had not encountered many of these, I could easily envisage such scenarios. But in fact I have greatly benefited from this facility, as have many others that have distributed shared libraries. Anyone who has ever made a kernel change that didn't require user-level changes (most cases) has benefited in the same way. Seizing upon one example that conveniently allows you to argue to death whether the library change entails a user-level change is sophistry and rhetorical manipulation that has nothing to do with the technical merits of anything. >Most software upgrade is a little more complex than can be processed by >mere library change. Most software upgrade, in properly designed systems, includes both changes in implementations for existing interfaces and additions to interfaces. Incompatible interface changes are to be avoided and generally are. As long as they are, libraries can be replaced with upward compatible versions without modifying existing executables. This is so common a practice that I am really surprised you are not familiar with it.
cks@hawkwind.utcs.toronto.edu (Chris Siebenmann) (05/22/91)
mohta@necom830.cc.titech.ac.jp (Masataka Ohta) writes: | As you don't know enough about host name look up and accompanied | complexities of its management, don't say: | >Note that an upgrade to use the DNS didn't *have* to include support for | >multiple addresses. | unless you want to be dishonest. Either I am misunderstanding something here, or I have been the victim of a very clever and subtle plot, for I could swear that at least one bind/named distribution allows you to compile a resolver library that uses the old 4.2BSD one-IP-address struct hostents and that I compiled and ran many applications happily using this library on Ultrix 2.2. In fact, some of these applications are still running on some of our machines (we upgrade only rarely, especially on machines used mostly as X terminals these days). They all seem to work fine. -- Sorry, I don't close-caption for the humour impaired. cks@hawkwind.utcs.toronto.edu ...!{utgpu,utzoo,watmath}!utgpu!cks
mohta@necom830.cc.titech.ac.jp (Masataka Ohta) (05/22/91)
In article <1991May21.170435.22610@kithrup.COM> sef@kithrup.COM (Sean Eric Fagan) writes: >>If you have 13+ people, you have very few merit (if any) with shared >>libraries. As text of a binary is shared and most are using xterm, the >>same binary is shared. The total amount of extra memory is still 1.5MB, >>which is much more negligible compared to the total amount of memory >>which is large enough (perhaps 32~64MB) to hold data area of 13+ >>people. >Note that I also said "development with X." Guess what: Oh, I don't want to guess. So, give us usable data. You even don't show how much memory the system has. >those libraries >aren't shared, it works out to about 1.5Mbytes *per X application*, and, >with a dozen or so people doing that, that *is* a considerable amount of >memory. 1.5Mbyte per X application? The code segment size of fully linked xterm (a rather large application) is less than 600KB on SONY NWS3860 (the machine, on which I measured FACTS and post the result with sufficient figures). On sun4 (SunOS3.2), it is about 450KB. So far, What I write is fact. Below is mere guess. I guess the sharable part of the code of xterm is less than 250K on Sun4. I also guess that your 1.5MB is the sum of code sizes of all referred libraries (if you don't use shared libraries, you don't have to link unreferenced part of the library). Then, you can't save memory unless you have at least 7 kinds of binaries (processes withas the same binary share text) running at once. Masataka Ohta
mohta@necom830.cc.titech.ac.jp (Masataka Ohta) (05/22/91)
In article <1991May21.055103.25680@Think.COM> barmar@think.com writes: >>Most software upgrade is a little more complex than can be processed by >>mere library change. >How many standard C and Unix library functions have had changes to their >interface? Many. >I'm sure there have been some changes over the years to the >implementations of most of these library routines, but the interfaces have >stayed nearly constant. Yes, as they stayed nearly constant, recompilation was often enough. ^^^^^^ For shared libraries be applicable, it must have stayed exactly constant. >>You should not have said what you believe. > >If I shouldn't say what I believe, what should I say? Everything else is >things that I don't believe, and saying them would be lying. You should have said it with supporting facts. >>>Note that an upgrade to use the DNS didn't *have* to include support for >>>multiple addresses. >What I meant was just as the /etc/hosts version ignores multiple addresses, >the designers of the DNS version could have decided to return only one >address, in order to leave the interface the same. So what? What was discussed is how shared libraries is not useful for the change from /etc/hosts to DNS in the real world. Masataka Ohta
gary@neptune.ctc.contel.com (Gary Bisaga x4219) (05/22/91)
mohta@necom830.cc.titech.ac.jp (Masataka Ohta) writes: >I have already proved that > > 1) its space saving is negligible > > 2) shared libraries dose not help software version up > from /etc/hosts to DNS Sorry, I haven't seen either of these "proved". You obviously believe it but that doesn't mean it's proved. In article <1991May16.173305.11403@decuac.dec.com>, mjr@hussar.dco.dec.com (Marcus J. Ranum) writes: > Heaving X windows out or putting it on a diet would *REALLY* reduce > the amount of required disk space. To forestall flamage about all of X' > vaunted "functionality" take a look at the size of MGR and the "functionality" > it offers before you follow-up, please. > > Using shared libraries to cure X-windows bloat is really stupid, ... If I was of the suspicious bent, I would call this erecting a straw man. The fact that X has problems, or for that matter the fact that DNS has problems, has nothing to do with whether shared libraries are useful.
mohta@necom830.cc.titech.ac.jp (Masataka Ohta) (05/22/91)
In article <1991May21.055103.25680@Think.COM> barmar@think.com writes: >If the structure to be filled in were an in-out parameter, as we generally >did in Multics, then the version number could be put there. For library >routines that allocate their output structure we would pass the expected >version as a separate parameter. The Multics calling sequence also >includes the number of arguments, and often includes the argument types >(whenever the function is "varargs" or any of the arguments has variable >length), so a function could look at the number and types of arguments and >infer the version of the caller. That's overly complex. Such interface will increase code size considerably. If you think you need shared libraries because your code size is important, well, ... >No, it's not easy to retrofit these calling conventions onto an established >system. These problems are, in my opinion, a legacy of Unix's simplistic >original design. You reversed order in time. Because it's not easy to retrofit simple calling conventions onto an established system: Multics, UNIX was born (there are many other reasons of course). BTW, I don't mind what multics did. Many OS has done many wrong things or right things in a wrong manner. This is comp.unix.internals and what I have been saying is don't put shared libraries into Unix. Masataka Ohta
richard@aiai.ed.ac.uk (Richard Tobin) (05/23/91)
In article <1991May21.170435.22610@kithrup.COM> sef@kithrup.COM (Sean Eric Fagan) writes: >Note that I also said "development with X." Guess what: those libraries >aren't shared, it works out to about 1.5Mbytes *per X application*, and, >with a dozen or so people doing that, that *is* a considerable amount of >memory. While Sun's shared libraries are far from perfect, they have certainly made X development here a lot less tedious for another reason. The time to link a binary has dropped from about a minute to about 10 seconds, due to not having to write out the huge a.out file. [Yes, I know, it's all the fault of NFS.] -- Richard -- Richard Tobin, JANET: R.Tobin@uk.ac.ed AI Applications Institute, ARPA: R.Tobin%uk.ac.ed@nsfnet-relay.ac.uk Edinburgh University. UUCP: ...!ukc!ed.ac.uk!R.Tobin
guy@auspex.auspex.com (Guy Harris) (05/23/91)
>>There are two kinds of software upgrades: those which change the interface >>to the library, and those which only change the implementation. > >>Most of the common shared library designs only make the second kind simple. >>That's certainly better than nothing. > >And, my claim is that the second kind is almost nothing. > >Your (those who support shared libraries) example of DNS prove that. No, it proves no such thing. *ONE* example won't prove anything like that; you'd have to have a reasonably exhaustive list of changes of the two types listed, and that list would have to show that almost all the changes were of the first kind. Changes of the second kind include: 1) bug fixes to bugs in the implementation, rather than the specification, of a routine; 2) performance improvements that don't require specification changes; 3) functionality improvements that don't require specification changes (e.g., changing some lookup routine to check an indexed version of the file being checked, or a network database, such as changing "getpw{nam,uid}()" to use an "ndbm" database, 4.3BSD-style, or to use the NCS Registry or ONC NIS or Hesiod). And as for whether the DNS upgrade is of the first or second kind, read on.... >>I believe they also enhanced >>the /etc/hosts version of the routine to return multiple addresses (our >>/etc/hosts file has several host names with multiple addresses). > >You believe what? No. They didn't do so. No, what Berkeley did in 4.3BSD was: 1) change the specification of "gethost*()" so that, instead of them returning a structure containing, among other members, a "char *" pointing to a single network address, they returned a structure containing a "char **" pointing to the first member of an array of "char *"s pointing to network addresses, the array being terminated by a NULL pointer; 2) provided an "/etc/hosts"-based implementation of that specification that always returned a pointer to an array with one pointer to a network address, followed by a NULL pointer; 3) provided a DNS-based implementation of that specification that would return a pointer to an array with one or more pointers to network addresses; 4) modified at least some programs (e.g, "telnet" and "ftp") so that they would use elements of that array other than the first, if they were provided. Thus, you have two binary-compatible implementations of the same specification, and at least some programs capable of making use of the added capabilities of the second implementation. What Sun did in SunOS 4.0 was: 1) pick up Berkeley's change to the specification of "gethost*()"; 2) provide an "/etc/hosts"-or-NIS-based implementation of that specification that provided only one host address; 3) provided, after 4.0 came out, a version of "libc" that included a DNS-based implementation of that specification that, being based on the 4.3BSD implementation, presumably could provide more than one host address; 4) picked up, as I remember, at least some of the 4.3BSD modified versions of the programs in question, e.g. "telnet" and "ftp" - can anybody who's actually dropped in the DNS-based version of "libc", and tried to connect to a host with multiple addresses using any of those programs, verify that those programs will try more than just the first address? Thus, you have any program that uses "gethostbyname()" capable of picking up the first address for a host from the DNS simply by dropping in the new shared library; while it won't necessarily handle all the addresses, it will handle the first, which is better than nothing, and no worse than what you get with vanilla 4.3BSD. Those programs that are supplied, in 4.x, in a form that *does* know about multiple addresses - "telnet" and "ftp" might be among those programs - will be able to handle all the addresses that the DNS-based implementation gives them. >>In Multics, library design guidelines also make the first kind easy. Most >>library routines with non-trivial parameters take most of the parameters as >>a pointer to a structure. By convention, the first member of the structure >>is a version number or version string > >The only parameter for gethostbyname() is, trivially, a string. And so is the first parameter to "index()"/"strchr()". So what? He didn't say the first parameter was "a string", he said it was "a *VERSION* number or a *VERSION* string". If UNIX routines had followed a Multics-like convention, the first parameter to "gethostbyname()" would be a version number or version string, with the host name a later parameter; old programs that expect a 4.2BSD-like interface would pass in a version number of 1, and would have the returned structure contain a pointer to one host address, and new programs that expect a 4.3BSD-like interface would pass in a version number of 2, and would have the returned structure contain a pointer to an array of pointers to host addresses. This still wouldn't mean that programs - whether built for the 4.2BSD-style interface or the 4.3BSD-style interface - that don't know about the array would magically start using all the addresses they'd been provided, but they would still use the only (4.2BSD-style) or first (4.3BSD-style) address they were given, which, again, is no less than what you get with 4.3BSD. In this particular case, that version-number trick wouldn't have made a difference, as shared libraries weren't available prior to 4.0, so any programs expecting the 4.2BSD-style *binary* interface wouldn't be affected by the change to the interface. So what exactly *was* the point you were trying to make with that comment? Is it at all relevant to the discussion, or was it a random unrelated bit of information?
torek@elf.ee.lbl.gov (Chris Torek) (05/23/91)
I thought I might do something silly like inject a fact or two into this, ah, `discussion'. :-) The following two log messages were extracted from the master SCCS files for the BSD distributions. They show exactly when (a) the name server was put into effect and (b) multiple IP addresses were added. In fact, the interface change for multiple IP addresses was done almost six months after changing to name servers. D 5.5 85/09/11 16:46:46 bloom 17 16 00049/00031/00132 implement multiple address return from gethostby* routines D 4.9 85/03/25 13:51:20 ralph 10 9 00110/00089/00028 version which uses resolver & name server. Shared libraries are neither a panacea nor completely valueless. Any attempt to `prove' one or the other will only stir up more flames. -- In-Real-Life: Chris Torek, Lawrence Berkeley Lab CSE/EE (+1 415 486 5427) Berkeley, CA Domain: torek@ee.lbl.gov
dave@fps.com (Dave Smith) (05/23/91)
In article <223@titccy.cc.titech.ac.jp> mohta@necom830.cc.titech.ac.jp (Masataka Ohta) writes: >1.5Mbyte per X application? The code segment size of fully linked xterm >(a rather large application) is less than 600KB on SONY NWS3860 (the >machine, on which I measured FACTS and post the result with sufficient >figures). On sun4 (SunOS3.2), it is about 450KB. > >So far, What I write is fact. > Excuse me? SunOS 3.2 on a Sun 4 (i.e. SPARC?)? I don't think so. The statically linked X11R4 xterm for SunOS 3.4 on a 3/50 is 524288 bytes. On a Sun 4 running SunOS 4.1.1 the X11R4 xterm, dynamically linked is 188416 bytes. This is a significant difference in my opinion. I don't have a statically linked Sun4 xterm lying about, so I can't do an apples to apples comparison, but I think we can all agree that SPARC code tends to be bigger than 680x0 code. Furthermore, a du of /usr/bin/X11 on the Sun 3 reveals 14M of executables and a du /usr/bin/X11 on the Sun4 reveals 3.7 M of executables, with 3 additional executables in the Sun4 directory! This debate has gone off the edge of silliness. Masataka, we do not live in fantasyland where we can dismiss things because they are inelegant. X is here to stay and so are dynamic libraries. You can bemoan this fact all you like, but it is nonetheless true. The computer market is just that, a market, driven by market forces. The market dictates that X is the way to do graphics. X is large and X is bloated so the market once again whines about disk and memory usage which dictates shared libraries. I believe that we could probably develop better solutions than X and shared libraries. However they are SOLUTIONS. Your "solutions" like "Don't use such a bloated window system" solve nothing and are rightly dismissed as being frivolous and arrogant. -- David L. Smith FPS Computing, San Diego ucsd!celit!dave or dave@fps.com "It was time to stop playing games. It was time to put on funny hats and eat ice cream. Froggie played his oboe" - Richard Scarry
richard@aiai.ed.ac.uk (Richard Tobin) (05/23/91)
In article <223@titccy.cc.titech.ac.jp> mohta@necom830.cc.titech.ac.jp (Masataka Ohta) writes: >1.5Mbyte per X application? 1.5 Mbyte is rather large, but I have many X programs (using both xview and motif toolkits) that have around a megabyte of text and which are less than 100 Kbytes when dynamically linked. For example: bute% ls -l xvserver* -rwxr-xr-x 1 richard 139264 May 22 21:28 xvserver* -rwxr-xr-x 1 richard 1286144 Mar 11 18:01 xvserver.static* bute% size xvserver* text data bss dec hex 32768 8192 5360 46320 b4f0 xvserver 942080 131072 16376 1089528 109ff8 xvserver.static How much is really shared? Obviously it depends on what other programs are being run. But we might well run several different xview programs simultaneously, and the saving in disk space is also substantial. -- Richard -- Richard Tobin, JANET: R.Tobin@uk.ac.ed AI Applications Institute, ARPA: R.Tobin%uk.ac.ed@nsfnet-relay.ac.uk Edinburgh University. UUCP: ...!ukc!ed.ac.uk!R.Tobin
igb@fulcrum.bt.co.uk (Ian G Batten) (05/23/91)
In article <7972@auspex.auspex.com> guy@auspex.auspex.com (Guy Harris) writes: > If UNIX routines had followed a Multics-like convention, the first > parameter to "gethostbyname()" would be a version number or version > string, with the host name a later parameter; old programs that expect a > 4.2BSD-like interface would pass in a version number of 1, and would > have the returned structure contain a pointer to one host address, and > new programs that expect a 4.3BSD-like interface would pass in a version > number of 2, and would have the returned structure contain a pointer to > an array of pointers to host addresses. I'm surprised that no one has pointed out the isomorphism between the Multics calling convention (yes, I did hack Multics for a few years) and the program/function/version number strategy of the (Sun) rpc mechanism. That, to me, provides a fairly clean way for library routines to be upgraded, possibly with changes to interface, while providing support for callers that still want to use the older versions. I've got a project for which about 60% of access to a set of routines will be over the network and about 40% will be local. I'm quite happy to accept the overhead of making local remote procedure calls on that 40% in order to get the benefits seen above. ian
sef@kithrup.COM (Sean Eric Fagan) (05/23/91)
In article <226@titccy.cc.titech.ac.jp> mohta@necom830.cc.titech.ac.jp (Masataka Ohta) writes: >>How many standard C and Unix library functions have had changes to their >>interface? >Many. Name 20 out of more-or-less generic-unix libc. >For shared libraries be applicable, it must have stayed exactly constant. No, that's why you have "version numbers" in your shared library, a la SunOS et al. (Not knowing multics, I can't comment on what it did.) >You should have said it with supporting facts. Any facts any of us have posted you have dismissed as irrelevent, useless for anybody but dweebs, or outright wrong, despite supporting evidence. >So what? What was discussed is how shared libraries is not useful for the >change from /etc/hosts to DNS in the real world. Gee, I think that dozens/hundreds/thousands of Sun machines count as "the real world." -- Sean Eric Fagan | "I made the universe, but please don't blame me for it; sef@kithrup.COM | I had a bellyache at the time." -----------------+ -- The Turtle (Stephen King, _It_) Any opinions expressed are my own, and generally unpopular with others.
jay@retix.retix.com (Jay Logue) (05/24/91)
In article <211@titccy.cc.titech.ac.jp> mohta@necom830.cc.titech.ac.jp (Masataka Ohta) writes: >In article <1991May17.075555.29787@Think.COM> barmar@think.com writes: > >>There are two kinds of software upgrades: those which change the interface >>to the library, and those which only change the implementation. > >>Most of the common shared library designs only make the second kind simple. >>That's certainly better than nothing. > >And, my claim is that the second kind is almost nothing. > >Your (those who support shared libraries) example of DNS prove that. > >Most software upgrade is a little more complex than can be processed by >mere library change. > > Masataka Ohta I have been following this (lively?) thread for a while, but given the statements above, perhaps I've missed something along the way. You seem to be saying that the ability to upgrade a program or set of programs without recompilation by replacing a common shared library is of no value, and does not in itself or coupled with any other ability justify the use of shared libraries. You cite the previous discussion about DNS as a proof of this assertion. However, this proof provides the DNS example as its only argument, whereas your assertion of the value of shared libraries applies to all possible shared library uses. Are you also stating that the DNS example is universal for all uses of shared libraries for the purposes of software maintainance/configuration? That it is the only possible scenario for the use of shared libraries? Do you mean to say that someone could not (and has not) come up with a use of shared libraries that is in some way valuable to themselves and their customers? If this is the case, I challange you to prove it. If this is not the case, then I can see nothing that supports your conclusion. As for myself, I believe that your argument is far too narrow to invalidate the value of shared libraries. Furthermore, I believe that the use of shared libraries for the purposes we are discussing is very valuable and will become even more so in the future. It is very easy to imagine two applications developed by seperate companies that co-operate using a shared library interface module that is coded and _maintained_ by a third company. The maintainance relationship would exist between the end-user and the third company directly and, indeed, the two applications development compaines need not even be aware that their applications co-operation let alone aware of the fact that the code with which they co-operate is the subject of periodic updates. I believe this sort of relationship exists right now within the OS/2 environment (with Microsoft being the third company). As a final note, I would ask you to be a little less confrontational in your reply than you have been in previous replies. In posting this message, my intention is to promote a discussion which has, at least up to this point, been very educational for me. I am not interested in receiving a reply littered with rude remarks or personal attacks. Jay Logue =============================================================================== INGREDIENTS: Jay Logue's personal opinions, cute signature, physical/electronic addresses, and one or more of the following used as a filler: assorted quotations, extraneous punctuation, white-space. CONTAINS NO OFFICIAL EMPLOYER OPINIONS OR POSITIONS. Not to be taken internally. If accidentally injested, flush with generous quantities of Jose Quervo Gold and consult your nearest bartender immediately. =============================================================================== Retix USMail: 2644 30th Street, Santa Monica, CA 90405-3009 U.S.A Tel: (213) 399-1611 Fax: (213) 458-2685 Telex: 4944307 E-mail: jay@retix.com X.400: C=US;ADMD=TELEMAIL;PRMD=RETIX;O=OSI ONE;S=LOGUE;G=JAY ===============================================================================
mohta@necom830.cc.titech.ac.jp (Masataka Ohta) (05/30/91)
Now, perhaps, it is time to show that shared libraries often increase memory consumption. If, as if often the case, we are running only one X applications, you lose. In article <4757@skye.ed.ac.uk> richard@aiai.UUCP (Richard Tobin) writes: >bute% ls -l xvserver* >-rwxr-xr-x 1 richard 139264 May 22 21:28 xvserver* >-rwxr-xr-x 1 richard 1286144 Mar 11 18:01 xvserver.static* >bute% size xvserver* >text data bss dec hex >32768 8192 5360 46320 b4f0 xvserver >942080 131072 16376 1089528 109ff8 xvserver.static >How much is really shared? Obviously it depends on what other programs >are being run. But we might well run several different xview programs >simultaneously, and the saving in disk space is also substantial. I asked Richard the size of library shared. And lines below are his reply: :bute% ldd winserver/xvserver : -lxview.3 => /usr/bute/local/lib/libxview.so.3.0 : -lolgx.3 => /usr/bute/local/lib/libolgx.so.3.0 : -lX11.4 => /usr/bute/local/lib/libX11.so.4.2 : -lc.1 => /usr/lib/libc.so.1.5 : :bute% ls -l /usr/local/lib/lib{xview,olgx,X11}.so* /usr/lib/libc.so* :-rwxr-xr-x 1 root 516096 Feb 8 1990 /usr/lib/libc.so.1.5* :-rw-rw-r-- 1 richard 229376 Jan 18 1990 /usr/local/lib/libX11.so.4.2 :-rwxr-xr-x 1 richard 57344 Jan 30 15:23 /usr/local/lib/libolgx.so.3.0* :-rwxr-xr-x 1 richard 1040384 Jan 30 15:25 /usr/local/lib/libxview.so.3.0* :bute% size /usr/local/lib/lib{xview,olgx,X11}.so* /usr/lib/libc.so* :text data bss dec hex :868352 73728 2544 944624 e69f0 /usr/local/lib/libxview.so.3.0 :40960 8192 0 49152 c000 /usr/local/lib/libolgx.so.3.0 :180224 24576 3584 208384 32e00 /usr/local/lib/libX11.so.4.2 :442368 16384 0 458752 70000 /usr/lib/libc.so.1.5 Thank you, Richard. According to his data, total text space required for xvserver is: 940Kbytes without shared libraries and 1560Kbytes with shared libraries. Though not all functions in 1.56Mbytes are actually called, most pages are swapped in if at least one function in the same page is called. Of course, libc is shared with other system processes, and if we are running other X clients, more is shared. But, what matters here is the size of the working set. Thus, if all other processes are inactive, there memory consumption is very small. Memory consumption is determined by the working sets of active processes. So, for example, as is often the case with personal workstations, if users are concentrated on xvserver only, memory is wasted. To save memory with shared libraries, we must running two or more similar (that is, sharing most libraries) but not exactly same programs. It may sometimes true with large server type machine shared by many people. But, then, the machine is running many programs and, because of text sharing, data size tends to dominate the memory consumption. The example above is of xvserver (according to Richard, it is a graphical front-end to prolog), but the same holds for a very common type of X users. That is, if a user only uses multiple xterms or he concentate only on a drawing tool, only active processes are xterms, thus memory is wasted. Masataka Ohta
rob@array.UUCP (Rob Marchand) (05/30/91)
In article <4752@skye.ed.ac.uk> richard@aiai.UUCP (Richard Tobin) writes: >In article <1991May21.170435.22610@kithrup.COM> sef@kithrup.COM (Sean Eric Fagan) writes: >>Note that I also said "development with X." Guess what: those libraries >>aren't shared, it works out to about 1.5Mbytes *per X application*, and, >>with a dozen or so people doing that, that *is* a considerable amount of >>memory. > >While Sun's shared libraries are far from perfect, they have certainly >made X development here a lot less tedious for another reason. The >time to link a binary has dropped from about a minute to about 10 >seconds, due to not having to write out the huge a.out file. > I would tend to agree with Richard here; although I don't have a great deal of experience in this area, I have noted that a SunView application (a small one, just a simple rasterfile viewer) went from over 600K on disk (pre SunOS shared libraries) to 24K. And, as Richard notes, the link time improves as well.... Seems to me that there are people on two sides of the fence here, and that it is unlikely anyone is going to change their mind :-) Cheers! Rob Marchand -- Rob Marchand UUCP : uunet!attcan!lsuc!array!rob Array Systems Computing ARPA : rob%array.UUCP@uunet.UU.NET 401 Magnetic Drive, Unit 24 Phone : +1(416)736-0900 Fax: (416)736-4715 Downsview, Ont CANADA M3J 3H9 Telex : 063666 (CNCP EOS TOR) .TO 21:ARY001
dfields@radium.urbana.mcd.mot.com (David Fields) (05/31/91)
From mohta@necom830.cc.titech.ac.jp (Masataka Ohta): >Now, perhaps, it is time to show that shared libraries often increase >memory consumption. >If, as if often the case, we are running only one X applications, you >lose. If your assertion of only running one X app holds true, then you may or may not increase memory consumption. It depends on the order in which objects are loaded in both the static binary and the shared object. However, your assertion is false for the systems which I help build! The environment I work in uses X-terminals and a couple of server machines. I currently am running 13 instantiations of 6 different X applications and there are several more people running on these machines. Dave Fields // Motorola Computer Group // dfields@urbana.mcd.mot.com
terryl@sail.LABS.TEK.COM (06/01/91)
In article <264@titccy.cc.titech.ac.jp> mohta@necom830.cc.titech.ac.jp (Masataka Ohta) writes: +Now, perhaps, it is time to show that shared libraries often increase +memory consumption. Yes, I actually do agree with what you said above; unfortunately, you really haven't shown what you claim. +If, as if often the case, we are running only one X applications, you +lose. Maybe in your idealized world that is true, but I can assure you out in the REAL world, MANY X applications are running at once, not one at a time. Here's a partial ps listing of a local workstation running X: 181 ? 0:00 xdm 184 ? 2:04 X 191 ttyp1 0:01 xterm 192 ? 0:00 sh 201 ? 0:00 sh 211 ? 0:01 xterm 214 ? 0:10 mwm 252 ? 0:32 xterm 253 ? 0:00 xterm 255 ? 68:19 xclock 256 ? 0:05 xeyes 261 ttyp4 0:00 csh 258 ttyp3 0:01 csh 259 ttyp2 0:01 csh 1783 ? 0:14 rlogind 1784 ttyp5 0:01 csh 1965 ttyp5 0:00 ps 1043 ttyp7 0:01 csh 1040 ? 0:03 xterm 1945 ttyp2 0:45 gdb I count 5 different X applications running (xdm, xterm, mwm, xclock, xeyes), plus the server (listed as X in the above listing). +In article <4757@skye.ed.ac.uk> richard@aiai.UUCP (Richard Tobin) writes: + +>bute% ls -l xvserver* +>-rwxr-xr-x 1 richard 139264 May 22 21:28 xvserver* +>-rwxr-xr-x 1 richard 1286144 Mar 11 18:01 xvserver.static* +>bute% size xvserver* +>text data bss dec hex +>32768 8192 5360 46320 b4f0 xvserver +>942080 131072 16376 1089528 109ff8 xvserver.static + +>How much is really shared? Obviously it depends on what other programs +>are being run. But we might well run several different xview programs +>simultaneously, and the saving in disk space is also substantial. + +I asked Richard the size of library shared. And lines below are his reply: +:bute% size /usr/local/lib/lib{xview,olgx,X11}.so* /usr/lib/libc.so* +:text data bss dec hex +:868352 73728 2544 944624 e69f0 /usr/local/lib/libxview.so.3.0 +:40960 8192 0 49152 c000 /usr/local/lib/libolgx.so.3.0 +:180224 24576 3584 208384 32e00 /usr/local/lib/libX11.so.4.2 +:442368 16384 0 458752 70000 /usr/lib/libc.so.1.5 +Thank you, Richard. + +According to his data, total text space required for xvserver is: + 940Kbytes without shared libraries +and + 1560Kbytes with shared libraries. You make one strange assumption here, and I'll ask you like you asked Richard: do you have ANY facts to back up the claim that you seem to making?? The claim is "If a shared library is used, ALL of the space of the shared library(at least the text) will be loaded in the executable image". I make this claim by adding together the text sizes of the shared libraries, along with the text size of the original object file, and that's my interpretation of what you are saying. +Though not all functions in 1.56Mbytes are actually called, most pages +are swapped in if at least one function in the same page is called. Again, I'll ask you to provide some facts (and preferably figures, too) to back up your claim "most pages ... same page is called". Given a reasonable virutal memory subsystem, I doubt that this is true.
mohta@necom830.cc.titech.ac.jp (Masataka Ohta) (06/03/91)
In article <9613@sail.LABS.TEK.COM> terryl@sail.LABS.TEK.COM writes: >+If, as if often the case, we are running only one X applications, you >+lose. > > Maybe in your idealized world that is true, but I can assure you out in >the REAL world, MANY X applications are running at once, not one at a time. Your "the REAL world" is only a part of the real world. I'm in the real world and not using window systems at all. Moreover, along this discussion, several people said that they are using X just because they want multiple terminal windows at once. >Here's a partial ps listing of a local workstation running X: >I count 5 different X applications running (xdm, xterm, mwm, xclock, xeyes), >plus the server (listed as X in the above listing). On the other hand, you are the only person who has done this. No other people, who say they require many X applications, have shown what they are running. And, even you have not yet shown the result of 'ldd' and 'size'. Without that, you can say nothing. Please be technical. > do you have ANY facts to back up the claim that you seem to making?? >The claim is "If a shared library is used, ALL of the space of the shared >library(at least the text) will be loaded in the executable image". I make this >claim by adding together the text sizes of the shared libraries, along with the >text size of the original object file, and that's my interpretation of what you >are saying. You misinterpreted what I wrote. >+Though not all functions in 1.56Mbytes are actually called, most pages >+are swapped in if at least one function in the same page is called. > Again, I'll ask you to provide some facts (and preferably figures, too) >to back up your claim "most pages ... same page is called". Given a reasonable >virutal memory subsystem, I doubt that this is true. It is obvious. As I counted, there are 479 functions defined and 250 object modules (*.o files) 'ar'ed in libX11.a. The text size of libX11.a is about 180K. Thus, the average code size of a object module is about 720 bytes. If you have 8K page (a reasonable virtual memory subsystem, 16K might be more common), a typical page contains about 11 object modules. If you use 20% of modules (1 in 5 modules), unless there is strong correlation on calling pattern of library routines (most of strong correlation is already used up as strongly correlated functions are often already packed in a single object module), and unless you reorder object modules in the library, almost all text pages are swapped in. By using the (possibly non-existing) above correlation, you might be able to reduce memory consumption. And still, the same thing can be done a lot better with statically linked text, as even when there is no specific pattern as a shared library, there may be specific pattern as a private library of each program. Unshared shared libraries always use more real memory than statically linked ones. Judging from the measurement result of the REAL system: >+According to his data, total text space required for xvserver is: >+ 940Kbytes without shared libraries >+and >+ 1560Kbytes with shared libraries. the ratio is, perhaps, near 1:1.5. Masataka Ohta
terryl@sail.LABS.TEK.COM (06/05/91)
In article <275@titccy.cc.titech.ac.jp> mohta@necom830.cc.titech.ac.jp (Masataka Ohta) writes: +In article <9613@sail.LABS.TEK.COM> terryl@sail.LABS.TEK.COM writes: + +>+If, as if often the case, we are running only one X applications, you +>+lose. +> +> Maybe in your idealized world that is true, but I can assure you out in +>the REAL world, MANY X applications are running at once, not one at a time. + +Your "the REAL world" is only a part of the real world. + +I'm in the real world and not using window systems at all. Fine. You work in your "real world", and I'll work in my "real world". One thing I do know to be true: If I had to work in your "real world", I would NOT be as productive as I am in my "real world". Here's a suggestion (NOT a request): Do a little survey of a company, and find out how many workstations are running some sort of windowing system (be it X, News, <whatever>). Since this discussion sort of started about Sun and their workstations, me thinks Sun would be a good candidate.... +>Here's a partial ps listing of a local workstation running X: + +>I count 5 different X applications running (xdm, xterm, mwm, xclock, xeyes), +>plus the server (listed as X in the above listing). + +On the other hand, you are the only person who has done this. No other +people, who say they require many X applications, have shown what they +are running. Ah, I see: proof of your assertions by lack of repsonse on the other side. Not something that I'd want to count on.... +And, even you have not yet shown the result of 'ldd' and 'size'. + +Without that, you can say nothing. + +Please be technical. I have been technical, and who said anything about ldd & size??? I happen to be running on a workstation that doesn't support shared libraries, and as such I wasn't responding to specific shared libraries questions (except for my response below). What I was responding to was your claim that "only one X application runs at a time", and as such, provided some proof that it wasn't true. You, on the other hand, haven't provided ANY proof of your claim, so I'm having a hard time believing ANYTHING you say. +> do you have ANY facts to back up the claim that you seem to making?? +>The claim is "If a shared library is used, ALL of the space of the shared +>library(at least the text) will be loaded in the executable image". I make this +>claim by adding together the text sizes of the shared libraries, along with the +>text size of the original object file, and that's my interpretation of what you +>are saying. + +You misinterpreted what I wrote. No, I didn't misinterpret what you wrote, but it doesn't matter anyhow, since it has already been validated by a disinterested third party that the claim I asked about "shared libraries will load ALL of the text space" is actually true. Since I asked you a direct question, one that I thought was reasonably clear in intention, and you chose not to answer the question, again you haven't provided any proof for your claims, so by now I'm inclined not to put much faith in anything you say. +>+Though not all functions in 1.56Mbytes are actually called, most pages +>+are swapped in if at least one function in the same page is called. + +> Again, I'll ask you to provide some facts (and preferably figures, too) +>to back up your claim "most pages ... same page is called". Given a reasonable +>virutal memory subsystem, I doubt that this is true. + +It is obvious. As I counted, there are 479 functions defined and 250 object +modules (*.o files) 'ar'ed in libX11.a. The text size of libX11.a is about +180K. Thus, the average code size of a object module is about 720 bytes. If +you have 8K page (a reasonable virtual memory subsystem, 16K might be more +common), a typical page contains about 11 object modules. Thank you for at least providing some concrete proof here, but just because there are quite a few "functions per page", you still haven't provided any numbers on which functions are actually called, nor how often they are called. Also, just because a function has been called before, unless it is called fairly consistently, most reasonable virtual memory subsystems would probably have it paged out (not swapped in). +If you use 20% of modules (1 in 5 modules), unless there is strong +correlation on calling pattern of library routines (most of strong correlation +is already used up as strongly correlated functions are often already packed +in a single object module), and unless you reorder object modules in the +library, almost all text pages are swapped in. Again, I'll ask: how often are these modules called??? Once, twice, mul- tiple times?? With my (admittedly limited) experience in X, most functions are called just once, with just a few routines (Xgetnextevent, draw thingies, etc) dominating the time spent in the libraries. +By using the (possibly non-existing) above correlation, you might be able +to reduce memory consumption. And still, the same thing can be done a lot +better with statically linked text, as even when there is no specific pattern +as a shared library, there may be specific pattern as a private library +of each program. + +Unshared shared libraries always use more real memory than statically +linked ones. No, you haven't proven this one yet. The ONLY thing that has been proven is that executables linked with shared libraries use more VIRTUAL memory than statically linked executables, due to the fact that ALL of the text space of a shared library gets loaded. I haven't seen any facts to support the leap to PHYSICAL memory, yet. __________________________________________________________ Terry Laskodi "There's a permanent crease of in your right and wrong." Tektronix Sly and the Family Stone, "Stand!" __________________________________________________________
mohta@necom830.cc.titech.ac.jp (Masataka Ohta) (06/06/91)
In article <9640@sail.LABS.TEK.COM> terryl@sail.LABS.TEK.COM writes: > Here's a suggestion (NOT a request): Do a little survey of a company, and >find out how many workstations are running some sort of windowing system (be it >X, News, <whatever>). > I have been technical, and who said anything about ldd & size??? I happen You are quite commercial (in itself, not bad), not technical at all. >What I was responding to was your claim that "only one X >application runs at a time", That is not my claim at all. > No, you haven't proven this one yet. The ONLY thing that has been proven >is that executables linked with shared libraries use more VIRTUAL memory than >statically linked executables, due to the fact that ALL of the text space of >a shared library gets loaded. As text (including text of shared libraries) can be demand paged from executable files, you don't have to provide any swap space for text >I haven't seen any facts to support the leap >to PHYSICAL memory, yet. You had better be technical and accept the result of the measurement. Masataka Ohta
paul@uxc.cso.uiuc.edu (Paul Pomes - UofIllinois CSO) (06/06/91)
mohta@necom830.cc.titech.ac.jp (Masataka Ohta) writes: >>I haven't seen any facts to support the leap >>to PHYSICAL memory, yet. > >You had better be technical and accept the result of the measurement. Reading your postings always reminds me of a Will Rogers saying, "It's not what you don't know that's dangerous. It's what you know that isn't so." /pbp -- Paul Pomes, Computing Services Office University of Illinois - Urbana Email to Paul-Pomes@uiuc.edu
terryl@sail.LABS.TEK.COM (06/07/91)
In article <300@titccy.cc.titech.ac.jp> mohta@necom830.cc.titech.ac.jp (Masataka Ohta) writes: >In article <9640@sail.LABS.TEK.COM> terryl@sail.LABS.TEK.COM writes: > >> Here's a suggestion (NOT a request): Do a little survey of a company, and >>find out how many workstations are running some sort of windowing system (be it >>X, News, <whatever>). > >> I have been technical, and who said anything about ldd & size??? I happen > >You are quite commercial (in itself, not bad), not technical at all. Beautiful ad homiem attack. Stick to the facts. >>What I was responding to was your claim that "only one X >>application runs at a time", > >That is not my claim at all. Oh, yes it was. It wasn't your only claim, just one of many. To wit, see article with Message-ID of 264@titccy.cc.titech.ac.jp; you start the article thusly: Now, perhaps, it is time to show that shared libraries often increase memory consumption. If, as if often the case, we are running only one X applications, you lose. Other people have already responded to your other claims, so I chose not to. >> No, you haven't proven this one yet. The ONLY thing that has been proven >>is that executables linked with shared libraries use more VIRTUAL memory than >>statically linked executables, due to the fact that ALL of the text space of >>a shared library gets loaded. > >As text (including text of shared libraries) can be demand paged from >executable files, you don't have to provide any swap space for text And what does that have to do with the price of pickles in Denmark?? Your response has absolutely nothing to do with my remarks above. As you are so fond of saying, be technical. >>I haven't seen any facts to support the leap >>to PHYSICAL memory, yet. > >You had better be technical and accept the result of the measurement. What measurements?? I haven't seen any yet. The only measurements I've seen that I'll accept as fact is the fact I stated above (about using more VIRTUAL memory...). My suggestion is that YOU be technical and provide the measurements. As a start, I'll provide some additional measurements on my system (without shared libraries): F S UID PID PPID C PRI NI ADDR SZ:RSS WCHAN TTY TIME COMD 10 S 17185 1040 1 0 26 24 13c528 246:183 1b9d88 ? 0:09 xterm 10 S 17185 256 211 0 26 24 13b9fc 171:59 1b9d88 ? 0:25 xeyes 10 S 17185 255 211 0 26 24 13b8f8 176:76 1b9d88 ? 201:38 xclock 10 S 17185 253 211 0 26 24 13b6f0 245:114 1b9d88 ? 0:00 xterm 10 S 17185 214 211 0 26 24 13b4e8 326:265 1b9d88 ? 0:12 mwm 10 S 17185 211 201 0 26 20 13b3e4 245:122 1b9d88 ? 0:01 xterm 10 S 0 191 185 0 26 20 13afd4 245:124 1b9d88 ttyp1 0:01 xterm 10 S 0 185 181 0 30 20 139e90 224:93 139e70 ttyp0 0:01 xdm 10 S 0 184 181 0 26 20 13997c 2037:564 1b9d88 ? 3:38 X What's interesting here is the SZ:RSS column. SZ is the VIRTUAL memory size of the process, and RSS is the Resident Set Size (i.e. the amount of PHYSICAL memory it is currently occupying). Sizes are in terms of 4k pages. For example, the X server (listed as X in the above listing), consumes a little under 8 Mbytes of VIRTUAL memory, but is using only a little over 2 Mbytes of PHYSICAL memory, a little more than 25 % of its VIRTUAL size. Unfortunately, there is no ready (or easy way) to tell how much of the PHYSICAL memory is text vs. data. This will be my last post on this. When people have to resort to lying to prove their point, it's not worth my time or effort to respond to it. __________________________________________________________ Terry Laskodi "There's a permanent crease of in your right and wrong." Tektronix Sly and the Family Stone, "Stand!" __________________________________________________________
mohta@necom830.cc.titech.ac.jp (Masataka Ohta) (06/07/91)
In article <9659@sail.LABS.TEK.COM> terryl@sail.LABS.TEK.COM writes: > Oh, yes it was. It wasn't your only claim, just one of many. To wit, see >article with Message-ID of 264@titccy.cc.titech.ac.jp; you start the article >thusly: > Now, perhaps, it is time to show that shared libraries often increase ^^^^^ > memory consumption. You should have quote my post from the beginning, as suggested in news.announce.newusers. >>>What I was responding to was your claim that "only one X >>>application runs at a time", >> >>That is not my claim at all. Thus, my claim is, "when only one X application runs at a time, as is often the case, then memory consumption increases with shared libraries". Don't distort what I wrote. >>You had better be technical and accept the result of the measurement. > What measurements?? Meaningful measurements. > For example, the X server (listed as X in the above listing), consumes a >little under 8 Mbytes of VIRTUAL memory, but is using only a little over 2 >Mbytes of PHYSICAL memory, a little more than 25 % of its VIRTUAL size. A totally meaningless measurement. >Unfortunately, there is no ready (or easy way) to tell how much of the PHYSICAL >memory is text vs. data. Thus, as you know, your measurement is meaningless. On the other hand, what I measured and post is the code size of binaries and shared libraries, which is meaningful. > This will be my last post on this. When people have to resort to lying to >prove their point, it's not worth my time or effort to respond to it. Nice, you don't have to lie anymore. Close your mouth and open your eyes. Masataka Ohta
andreess@mrlaxs.mrl.uiuc.edu (Marc Andreessen) (06/07/91)
In article <301@titccy.cc.titech.ac.jp> mohta@necom830.cc.titech.ac.jp (Masataka Ohta) writes: >>>>What I was responding to was your claim that "only one X >>>>application runs at a time", >>>That is not my claim at all. >Thus, my claim is, "when only one X application runs at a time, as is often >the case, then memory consumption increases with shared libraries". Why in the world would someone 'often' use X to only run one application at a time? For that matter, does the server count? How about the window manager? Marc -- Marc Andreessen___________University of Illinois Materials Research Laboratory Internet: andreessen@uimrl7.mrl.uiuc.edu____________Bitnet: andreessen@uiucmrl
cs@cci632.cci.com (Craig Schmackpfeffer) (06/07/91)
In article <300@titccy.cc.titech.ac.jp> mohta@necom830.cc.titech.ac.jp (Masataka Ohta) writes: > >You had better be technical and accept the result of the measurement. > > Masataka Ohta So far Masataka has only provided one "I Ohta" of measurement!-) Sorry folks, I couldn't resist. -Craig = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = Me: Craig Schmackpfeffer (another damn yankee) Disclaimer: Disclaim'er? I don't even know her! Address: ccird1!cs@cci632.UUCP Go Bills! = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = =
mohta@necom830.cc.titech.ac.jp (Masataka Ohta) (06/09/91)
In article <1991Jun7.050655.27873@ux1.cso.uiuc.edu> andreess@mrlaxs.mrl.uiuc.edu (Marc Andreessen) writes: >>Thus, my claim is, "when only one X application runs at a time, as is often >>the case, then memory consumption increases with shared libraries". >Why in the world would someone 'often' use X to only run one application at a >time? Only one application (multiple xterms are counted as one application, because of text sharing) on each host. You may be using multiple hosts with multiple xterms. BTW, as a broader claim, I should have said, "is actively running" instead of "runs". When you are writing a program, or drawing a picture, you often concentrate on a single application. Then, unless you are running something like xeyes, there is only one "actively running" process. >For that matter, does the server count? How about the window manager? If you are running them on the machine with xterms, they count, but you may not. And, still, the server count for saving of libc.a, but not for libX*.a. Window managers count more, but it dose not mean fair amount of sharing is possible. % size twm mwm xterm text data bss dec hex 327680 61440 30416 419536 666d0 twm 1028096 192512 31088 1251696 131970 mwm 602112 139264 41536 782912 bf240 xterm Judging from the large difference in text size between xterm and window managers shown above, memory consumption is, perhaps, dominated by mwm (if you are running mwm and xterm) or xterm (if you are running twm and xterm). Masataka Ohta
andy@research.canon.oz.au (Andy Newman) (06/09/91)
In article <311@titccy.cc.titech.ac.jp> mohta@necom830.cc.titech.ac.jp (Masataka Ohta) writes: >When you are writing a program, or drawing a picture, you often concentrate >on a single application. Then, unless you are running something like xeyes, >there is only one "actively running" process. ...and a clock, and a mail minder, and a manual browser, a couple of performance monitors, a calendar manager, etc, etc... Soon adds up. -- Andy Newman (andy@research.canon.oz.au)
dan@kfw.COM (Dan Mick) (06/10/91)
In article <9659@sail.LABS.TEK.COM> terryl@sail.LABS.TEK.COM writes: >In article <300@titccy.cc.titech.ac.jp> mohta@necom830.cc.titech.ac.jp (Masataka Ohta) writes: >> >>That is not my claim at all. > > Oh, yes it was. It wasn't your only claim, just one of many. To wit, see >article with Message-ID of 264@titccy.cc.titech.ac.jp; you start the article >thusly: > > Now, perhaps, it is time to show that shared libraries often increase > memory consumption. > > If, as if often the case, we are running only one X applications, you > lose. Ah, yes, the age-old, time-honored tradition of "selective electronic argument" falls to the reproducibility of computer-stored statements once again... Thanks, Terry...you've just conclusively proved to me that everything M. Ohta says is to be ignored on its face. Besides being incomprehensibly phrased, it's also allowed to be self-inconsistent *and* abrasive. Go away, Masataka. Or should I say "You had better go away" to retort with that attitude of omniscience you're so fond of transmitting?
mohta@necom830.cc.titech.ac.jp (Masataka Ohta) (06/10/91)
In article <1991Jun9.104502.2167@research.canon.oz.au> andy@research.canon.oz.au (Andy Newman) writes: >>When you are writing a program, or drawing a picture, you often concentrate >>on a single application. Then, unless you are running something like xeyes, >>there is only one "actively running" process. >...and a clock, and a mail minder, and a manual browser, a couple of >performance monitors, a calendar manager, etc, etc... Soon adds up. Though I can't stop you from bloating your environment, not everybody believes in bloatation. Along this discussion, I remember two people said they use window system only because they need multiple terminals (their articles have expired on my site). If one is running only one active process because he has limited amount of real memory, memory consumption increase and performance decrease by shared libraries is a curse. Masataka Ohta
sef@kithrup.COM (Sean Eric Fagan) (06/10/91)
In article <315@titccy.cc.titech.ac.jp> mohta@necom830.cc.titech.ac.jp (Masataka Ohta) writes: >Though I can't stop you from bloating your environment, not everybody >believes in bloatation. So therefore shared libraries aren't necessary. Great chain of logic: I don't think it's necessary for me, therefore it's not necessary for anyone, therefore anything which might support it is not necessary. >Along this discussion, I remember two people said >they use window system only because they need multiple terminals (their >articles have expired on my site). I'm one of them. These days, I run several terminals, a mail reader, a file browser, a dictionary, and a thesaurus. Of those, the mail reader and terminals get the most use. Given that I only have 8Mbytes on the machine, *any* savings helps, despite what you seem to think. -- Sean Eric Fagan | "I made the universe, but please don't blame me for it; sef@kithrup.COM | I had a bellyache at the time." -----------------+ -- The Turtle (Stephen King, _It_) Any opinions expressed are my own, and generally unpopular with others.
boyd@prl.dec.com (Boyd Roberts) (06/10/91)
In article <311@titccy.cc.titech.ac.jp>, mohta@necom830.cc.titech.ac.jp (Masataka Ohta) writes: > > BTW, as a broader claim, I should have said, "is actively running" instead > of "runs". > So, call me slow, but are you trying to say that ``Shared libraries are not necessary''? Gee, I'm glad we've clarified that one... hai ima wakarimashita!! I just wish that I could persuade the not ``...actively running'' processes on my 3max to free up their resources. Hey, I could write a new system call... No... a kernel daemon... with a user mode configuration file and a set of tools to manipulate the file on... dumb terminals and X displays. And, then I could post it to comp.sources.unix... Wow! Boyd Roberts boyd@prl.dec.com ``When the going gets wierd, the weird turn pro...''
fmayhar@hermes.ladc.bull.com (Frank Mayhar) (06/11/91)
In article <1991Jun9.223900.7413@kfw.COM>, dan@kfw.COM (Dan Mick) writes:
-> Go away, Masataka. Or should I say "You had better go away" to retort with
-> that attitude of omniscience you're so fond of transmitting?
He probably won't go away, but that's OK. Early on in his tirade against
shared libraries (etc.), he and I exchanged several pieces of email. Based
on his comments therein, his name now has a prominent position in my kill
file. Right after John Palmer.
This guy is apparently one of those who has his mind made up, regardless of
any contradictory facts that may be brought to his attention. Debating with
him is a waste of time, as you have seen.
'Nuff said.
--
Frank Mayhar fmayhar@hermes.ladc.bull.com (..!{uunet,hacgate}!ladcgw!fmayhar)
Bull HN Information Systems Inc. Los Angeles Development Center
5250 W. Century Blvd., LA, CA 90045 Phone: (213) 216-6241andy@research.canon.oz.au (Andy Newman) (06/12/91)
In article <315@titccy.cc.titech.ac.jp> mohta@necom830.cc.titech.ac.jp (Masataka Ohta) writes: >Though I can't stop you from bloating your environment, not everybody >believes in bloatation. Those people are still running CP/M (or are they plugging away in hex on a Kim-1?). > Masataka Ohta Enough Said! -- Andy Newman (andy@research.canon.oz.au)
dave@aspect.UUCP (Dave Corcoran) (06/15/91)
In article <1906@array.UUCP>, rob@array.UUCP (Rob Marchand) writes: > > Seems to me that there are people on two sides of the fence here, > and that it is unlikely anyone is going to change their mind :-) > Thats ok, it's a great way to learn about stuff you don't get from the books. -- David Corcoran -@@ uunet!aspect!dave ~ Having the right to do something is not the same as being right in doing it. -- C.K. Chesterson