mcclend@infonode.ingr.com (William D McClendon) (06/10/91)
Mssr. Ohta et al, You entirely miss the point. Your own quote seeks to discuss the use of shared libraries for one user/client/process. The concept of shared libraries is based on the precept that there are several users (multiuser). If an application will be used by several users/clients at one point, you should build your code with shared libraries. If not, build your code without. End of argument. Bill
richard@aiai.ed.ac.uk (Richard Tobin) (06/13/91)
In article <1991Jun10.154811.11965@infonode.ingr.com> mcclend@infonode.ingr.com (William D McClendon) writes: >You entirely miss the point. Your own quote seeks to discuss the use of >shared libraries for one user/client/process. The concept of shared >libraries >is based on the precept that there are several users (multiuser). If an >application will be used by several users/clients at one point, you should >build your code with shared libraries. If not, build your code without. I think you have things the wrong way round. If the library is to be used by many different applications simultaneously, it should be shared between them. The fact that the application is used by many users simultaneously makes no difference under most unix systems, since the program text is shared regardless of whether you use shared libraries. >End of argument. I think not. -- 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
mohta@necom830.cc.titech.ac.jp (Masataka Ohta) (06/19/91)
In article <4945@skye.ed.ac.uk> richard@aiai.UUCP (Richard Tobin) writes: >>End of argument. > >I think not. I think the argument might have end. Let's summaries. So far, no one has shown any usable data on how much code is shared with shared libraries under their usual load. So, perhaps, shared libraries dose not help to decrease memory consumption so much. On the other hand, I showed a measurement result of increase of memory consumption based on some configuration (not my own configuration but other people's typical configuration). As for the software upgrade flexibility, its only example, /etc/hosts to DNS, was denied (note that Chris Torek's fact has nothing to do with the denial, as it can be interpreted that people in Berkeley noticed the necessity to change struct hostent after half year of experience with DNS) and no other supporting fact has shown. So, it should be concluded that there is no usable software upgrade flexibility in shared libraries. With shared libraries, disk consumption is surely decreased. So it might be useful in some cases. But such cases are, I think, rare. If the environment is networked and there is large shared servers (the case when shared libraries is really shared with many programs), there is large disk for unshared user data and the size of command files, which are already shared by networking, matters little. Are there any natural and common configuration where disk consumption really matters? Masataka Ohta
mcnally@wsl.dec.com (Mike McNally) (06/19/91)
Why can't I resist this stupid thread? In article <337@titccy.cc.titech.ac.jp>, mohta@necom830.cc.titech.ac.jp (Masataka Ohta) writes: |> So far, no one has shown any usable data on how much code is shared with |> shared libraries under their usual load. Well, Masataka, *you* might not be able to use the numbers, but I guess I'm not surprised at that. Several people have posted numbers that seemed pretty clear to me. |> So, perhaps, shared libraries dose not help to decrease memory consumption |> so much. Perhaps, perhaps not. I like that hard, purely technical wording too: "not...so much". |> |> On the other hand, I showed a measurement result of increase of memory |> consumption based on some configuration (not my own configuration |> but other people's typical configuration). You never convinced me that your sample set was representative of typical usage. You ask everybody to "be technical", so now I want some evidence that your survey of workstation users is meaningful. |> As for the software upgrade flexibility, its only example, /etc/hosts to |> DNS, was denied . . . |> So, it should be concluded that there is no usable software upgrade |> flexibility in shared libraries. Geez. OK, here's another example. I was working on debugging a system that had a malloc/free problem. There were several programs that exhibited the problem, and all were big. I was greatly aided in the debugging effort by being able to re-build libc over and over again with versions of malloc which included debug scaffolding. The time it took to rebuild the shared libc was minimal compared to the time it took to re-link all the programs. Using your reasoning, we're back to "no conclusion", I guess. If I find another example, I'll be up 2-1; will it them be appropriate that there is a usable software upgrade flwexibility? This seems so obvious it's amazing that you don't believe it. Do you think it's impossible that a vendor might make performance enhancements to a standard library? If so, wouldn't it be a lot easier to ship just the library rather than all applications? Have you ever been in a position to worry about distribution costs, or, indeed, given this statement: |> Are there any natural and common configuration where disk |> consumption really matters? have you ever been in a position to worry about costs at all? Did you buy the machine you're using? What's the budget of the organizatioon that did? Is it infinite? There are lots of people in this world (LOTS) using small 386-based PC systems. From real experience, I know that many of these people are *very* price sensitive. If a vendor can deliver a big operating system like UNIX and use substanntially less disk space, these people are happy; they might be able to get away with *one* disk partitioned for UNIX and DOS. Oh, but I guess you'll say these configurations are "unnatural"; I doubt you can say they're uncommon. -- * "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
mjs@hpfcso.FC.HP.COM (Marc Sabatella) (06/21/91)
> As for the software upgrade flexibility, its only example, /etc/hosts to > DNS, was denied . . . > So, it should be concluded that there is no usable software upgrade > flexibility in shared libraries. OK, a potential real example: In comp.sys.hp, people have been noticing printf() prints floating point numbers really slowly on a 68040. This is because the conversion routines use the old packed decimal instructions that no longer exist. To fix this problem, all we will need to do is ship a new shared C library - no need for customers to recompile or relink. > Are there any natural and common configuration where disk > consumption really matters? Have you ever had to make purchasing decisions? My guess is no, since this is incredibly common. Again, considering most of the world really does use X, we are talking about an order of magnitude size savings here. This makes a HUGE difference. As for the memory savings, well, I am still unconvinced either way. You've shown one set of numbers suggesting the savings doesn't exist if all you use is xterm. I have no trouble believing that. I am one one of those who fits that category (OK, I also have an xclock in the corner), so I probably don't get that benefit. But looking around me, I see that I am atypical - most people around here really do have lots of whizzy things up at once. The fact that none have bothered to compute the numbers and presented them to you in a manner you can accept should not be construed as saying the savings doesn't exist. -------------- Marc Sabatella (marc@hpmonk.fc.hp.com) Disclaimers: 2 + 2 = 3, for suitably small values of 2 Bill and Dave may not always agree with me
mohta@necom830.cc.titech.ac.jp (Masataka Ohta) (06/24/91)
In article <18370003@hpfcso.FC.HP.COM> mjs@hpfcso.FC.HP.COM (Marc Sabatella) writes: >> So, it should be concluded that there is no usable software upgrade >> flexibility in shared libraries. >OK, a potential real example: > >In comp.sys.hp, people have been noticing printf() prints floating point >numbers really slowly on a 68040. This is because the conversion routines use >the old packed decimal instructions that no longer exist. To fix this problem, >all we will need to do is ship a new shared C library - no need for customers >to recompile or relink. It is rather a minor bug fix than a software upgrade like /etc/hosts to DNS. I don't deny shared libraries are sometimes (but not always) useful for minor bug fix. >This is because the conversion routines use the old packed decimal >instructions that no longer exist. The real bug here is that HP used assembler (I don't think C compiler generate packed decimal instrucitons) for the conversion in printf. The real fix is to use C. >> Are there any natural and common configuration where disk >> consumption really matters? > >Have you ever had to make purchasing decisions? I am working in the campus computer center and investigating what to buy next is one of my main job. > My guess is no, since this is >incredibly common. We think fast (and redundant) network and large (and redundant) file servers is the way to go. On the way, we don't need shared libraries. >Again, considering most of the world really does use X, Consider most of the world really does use X with fast network. >we >are talking about an order of magnitude size savings here. This makes a HUGE >difference. I personally have a workstation, on which, X11R4 is fully installed as supplied by the vendor. Still, /usr/bin/X11 consumes only 20MB. My home directly consumes 200MB, most of which is data (but not disk consuming picture data). So, order of magnitude size saving on 20MB dose not matter at all. Moreover, I think, if disk consumption is somewhat lessed by shared libraries, much more unnecessary X tools will be distributed by vendors, which cancels any saving. >As for the memory savings, well, I am still unconvinced either way. You've >shown one set of numbers suggesting the savings doesn't exist if all you use is >xterm. I have no trouble believing that. I am one one of those who fits that >category (OK, I also have an xclock in the corner), so I probably don't get >that benefit. What benefit? What I showed is demerit of shared libraries in some cases, not lack of benefit. On the other hand, no one showed shared libraries have benefit on memory savings. BTW, don't rely on xclock especially on leap year. >But looking around me, I see that I am atypical - most people >around here really do have lots of whizzy things up at once. So what? In the old days, many untalented OS designers and most users of non-UNIX OSes (that is, most users of computers) blindly beleived that file types and logical record length and many other complicated things are good things. They are now blindly using UNIX with thier own way. Masataka Ohta
mjs@hpfcso.FC.HP.COM (Marc Sabatella) (06/25/91)
>>> So, it should be concluded that there is no usable software upgrade >>> flexibility in shared libraries. > >>OK, a potential real example: > >It is rather a minor bug fix than a software upgrade like /etc/hosts to DNS. > >I don't deny shared libraries are sometimes (but not always) useful for >minor bug fix. Argue syntax all you want. I'd prefer to call it a "performance enhancement" rather than a bug fix - using assembly was indeed faster in the 68010 days, so I would call using it "bug". Anyhow, the point is, shared libraries may make distribution easier. Bug fixes and performance enhancements happen at *every* release; major new pieces of functionality are relatively rare. You tell me which is more important to handle transparently. >I personally have a workstation, on which, X11R4 is fully installed as >supplied by the vendor. Still, /usr/bin/X11 consumes only 20MB. My home >directly consumes 200MB, most of which is data (but not disk consuming >picture data). So, order of magnitude size saving on 20MB dose not matter >at all. Wait a minute here. Are you saying /usr/bin/X11 consumes only 20MB with things built with archive libraries? Sounds like you've just gone through it and deleted everything just to make your point. My server's /usr/bin/X11 is close to 10 MB even with shared libraries. It would be well over 100 MB otherwise. That competes pretty well with your 200 MB of data, now, doesn't it? >What I showed is demerit of shared libraries in some cases, not lack of >benefit. On the other hand, no one showed shared libraries have benefit on >memory savings. Right, but again, just because no one took the trouble to do so doesn't mean there is never a benefit. No one denies shared libraries are unnecessary if you live your life around saving memory and disk space in all other ways. But X11 is an unfortunate fact of life these days. There is a similar flame war in rec.bicycles over whether or not people should need cars. The analagous statement being made there is, just make sure you live within a few miles of where you work, move every time your work location changes, don't engage in any social behavior that might require you to get from point A to B at speeds over 30 MPH, or have to cover distances of more than 100 miles in a day, and you'll never need a car. For most people, however, that's simply not practical. -------------- Marc Sabatella HP Colorado Language Lab (CoLL) marc@hpmonk
chip@tct.com (Chip Salzenberg) (06/25/91)
According to mohta@necom830.cc.titech.ac.jp (Masataka Ohta): >I don't deny shared libraries are sometimes (but not always) useful for >minor bug fix. Well, then, will you stop trying to claim they're not worth their cost? In my book, ease of library bug fixes is very high on my WIBNI (Wouldn't It Be Nice If...) list. >We think fast (and redundant) network and large (and redundant) file >servers is the way to go. On the way, we don't need shared libraries. Well, here at TCT, we think that a fast, large and redundant phone system is the way to go. On the way, we don't need a FAX machine. -- Chip Salzenberg at Teltronics/TCT <chip@tct.com>, <uunet!pdn!tct!chip> "I want to mention that my opinions whether real or not are MY opinions." -- the inevitable William "Billy" Steinmetz
mohta@necom830.cc.titech.ac.jp (Masataka Ohta) (06/26/91)
In article <18370004@hpfcso.FC.HP.COM> mjs@hpfcso.FC.HP.COM (Marc Sabatella) writes: >>>> So, it should be concluded that there is no usable software upgrade >>>> flexibility in shared libraries. >>I don't deny shared libraries are sometimes (but not always) useful for >>minor bug fix. >Argue syntax all you want. I'd prefer to call it a "performance enhancement" >rather than a bug fix OK. Anyway, it is not software upgrade such ans /etc/hosts to DNS. With shared libraries, you can do "minor improvement of libraly" (including minor bug fix and performance enchancement) with relatively small amount of distributed storage. But, amount of distributed storage dose not matter so much. Announcement, provision, installation and customer support cost much more than media especially with CDROMs. >Anyhow, the point is, shared libraries may make >distribution easier. Bug fixes and performance enhancements happen at *every* >release; major new pieces of functionality are relatively rare. You tell me >which is more important to handle transparently. I can't understand why you mention transparency here. You can do bug fixes and performance enhancements at *every* release without losing transparency. >>I personally have a workstation, on which, X11R4 is fully installed as ^^^^^^^^^^^^^^^^^^^^^^^^^^^ >>supplied by the vendor. Still, /usr/bin/X11 consumes only 20MB. My home ^^^^^^^^^^^^^^^^^^^^^^^^^ >>directly consumes 200MB, most of which is data (but not disk consuming >>picture data). So, order of magnitude size saving on 20MB dose not matter >>at all. >Wait a minute here. Are you saying /usr/bin/X11 consumes only 20MB with things >built with archive libraries? Sounds like you've just gone through it and >deleted everything just to make your point. No. I have four vendor standard installation options: 1) not install X11 at all 2) install core of X11 3) install a little more of X11 4) fully install X11 I choose 4, partly because someone else might want to use X11 and partly becuase I have enough disk. The measurement is done with SONY's NEWS-OS 4.0C. SONY is a rather active member of X consorcium and will, I think, provide standard tools of X11. % du /usr/bin/X11 20742 /usr/bin/X11 % ls -l /usr/bin/X11 X muncher startx xev xmj Xnews mwm tterm xeyes xmkmf appres oclock twm xfd xmodmap atobm plaid uil xfontsel xmon2cfg bdftosnf puzzle viewres xgc xpr bitmap resize xauth xgraph xprev bmtoa ripxrtmetric xbiff xhost xprop editres sessreg xcalc xinit xrdb hterm showrgb xcdp xkill xrefresh ico showsnf xclipboard xload xsed imake sjx xclock xlogo xset jterm sjxdemo xcutsel xlsatoms xsetroot listres snmpxbar xditview xlsclients xstdcmap makedepend snmpxconn xdm xlsfonts xterm maze snmpxmon2 xdmshell xlswins xvmap mkdirhier snmpxperf xdpr xmag xwd mkfontdir snmpxperfmon xdpyinfo xman xwininfo mterm snmpxrtmetric xedit xmh xwud >My server's /usr/bin/X11 is close >to 10 MB even with shared libraries. Perhaps because shared libraries dose not save so much disk space, or perhaps because your /usr/bin/X11 is deseparetely bloated with totally unnecessary tools. Anyway, my /usr/bin/X11 is sufficient for you as it even has xclock. >>What I showed is demerit of shared libraries in some cases, not lack of >>benefit. On the other hand, no one showed shared libraries have benefit on >>memory savings. >Right, but again, just because no one took the trouble to do so doesn't mean >there is never a benefit. The problem is not that no one post the measurement result but that no one seemed to have measured the actual merit of shared libraries on memory saving. Have you measure it, or are you just thinking someone should have measured it, or are you merely using your common sense (to be scientific, you shouldn't rely on your common sense)? >No one denies shared libraries are unnecessary if you live your life around >saving memory and disk space in all other ways. I am saving memory and disk space, of course. >There is a similar flame war in rec.bicycles over whether >or not people should need cars. The analagous statement being made there is, >just make sure you live within a few miles of where you work, move every time >your work location changes, don't engage in any social behavior that might >require you to get from point A to B at speeds over 30 MPH, or have to cover >distances of more than 100 miles in a day, and you'll never need a car. Bicycles? No. I am not saying you should use slow workstations. We should use the state of the art hardware in a reasonable way. Haven't you played SimCity? Using shared libraries for X is like building highways for cars. You can't solve traffic jam problem that way. So use railways. With the same technology level, railways have much more transportation capability. The reality of life in Tokyo (and urban area in Japan) is that you had better use railways (especially metros) than cars. Railways are much faster transport than cars in Tokyo. I have had simlar experience also in Boston, though Boston is much smaller city than Tokyo. The distance between home and office is longer than 50 miles for large amount of people. For longer distance, Tokyo and Osaka is connected by super express Hikari with 250Km/h (while maximum legal speed on freeway by car in Japan is only 100Km/h), in 3 hours, which is often even faster than air plains as transport between point A and B because airports are often located at inconvenient locations (if you play SimCity you can understand why airports should be located far from the center of the city). It should be noted that cars and X promote to waste resources. >For most people, however, that's simply not practical. Just because a major (in case of SimCity and most cities in USA) or a vendor (in case of window systems) dose not recognize what is good for thier citizens or customers (some short-sighted vendors might think that shared libraries are profittable for them becuase it accelerate waste of resources). Masataka Ohta
barmar@think.com (Barry Margolin) (06/27/91)
In article <349@titccy.cc.titech.ac.jp> mohta@necom830.cc.titech.ac.jp (Masataka Ohta) writes: >You can do bug fixes and performance enhancements at *every* release without >losing transparency. With static libraries, how do you incporporate bug fixes and performance enhancements transparently? You have to relink things to make them pick up the improvements. Commercial software is often distributed as prelinked executables, without the original .o files, so you can't even relink it if you want to. New versions of shared libraries, however, are used automatically. -- Barry Margolin, Thinking Machines Corp. barmar@think.com {uunet,harvard}!think!barmar
peter@ficc.ferranti.com (Peter da Silva) (06/28/91)
In article <349@titccy.cc.titech.ac.jp> mohta@necom830.cc.titech.ac.jp (Masataka Ohta) writes: > But, amount of distributed storage dose not matter so much. Announcement, > provision, installation and customer support cost much more than media > especially with CDROMs. So, you distribute all the third-party and local software on that CDROM as well? Or do you think people should only run software provided by their hardware vendor? The Amiga uses shared libraries extensively, and with each release programs were updated behind their backs to maintain the latest features of the operating system. For example, in 2.0 the appearance and behaviour of scroll bars was changed, and all Amiga programs automagically started using the new scrollbars. Including third-party and locally written software. > You can do bug fixes and performance enhancements at *every* release without > losing transparency. In your widgets? So your expensive third-party software benefits? -- Peter da Silva; Ferranti International Controls Corporation; +1 713 274 5180; Sugar Land, TX 77487-5012; `-_-' "Have you hugged your wolf, today?"
mjs@hpfcso.FC.HP.COM (Marc Sabatella) (06/28/91)
>With shared libraries, you can do "minor improvement of libraly" (including >minor bug fix and performance enchancement) with relatively small amount of >distributed storage. > >I can't understand why you mention transparency here. Becuase that is what I am concerned with, not storage. The idea is, you give the customer a new library (or it just comes along when he updates to a new version of the OS or product supplying the library) and suddenly, applications he had already compiled, or had picked up from a third party, start working "better". No recompile or relink necessary. Without shared libraries, a customer would have to recompile/relink his application, or convince the third party to do so, in order to take advantage of the improvement. That is what I mean by "transparent". >>My server's /usr/bin/X11 is close >>to 10 MB even with shared libraries. > >Perhaps because shared libraries dose not save so much disk space, or perhaps >because your /usr/bin/X11 is deseparetely bloated with totally unnecessary >tools. > >Anyway, my /usr/bin/X11 is sufficient for you as it even has xclock. xclock is sufficient for me, but not for the other members of my cluster. Our shared libraries do save disk space. The average Motif application saves over a megabyte. I guarantee you would not not fit 60+ Motif applications in under 100 MB without shared libraries. Do you need 60+ Motif applications? Well, I know you don't, and I probably don't either, but get enough people in the cluster, ones that, for better or for worse, like wizzy toys, and you'll need them. You say the problem is that the vendors are letting customers get away with using pigs like X. Be realistic. Remember what happened to Sun when they tried to say their customers didn't need X? How much longer do you suppose they'll get away with not shipping Motif? I give them about 6 months. It is the height of arrogance for a company to tell their customers what they need. As the saying goes, when they say "jump", we have to say "how high". >The problem is not that no one post the measurement result but that no one >seemed to have measured the actual merit of shared libraries on memory >saving. > >Have you measure it, or are you just thinking someone should have measured it, >or are you merely using your common sense (to be scientific, you shouldn't >rely on your common sense)? No I haven't measured it. But that doesn't prevent me from believing it is possible. -------------- Marc Sabatella (marc@hpmonk.fc.hp.com) Disclaimers: 2 + 2 = 3, for suitably small values of 2 Bill and Dave may not always agree with me