stolcke@ICSI.Berkeley.EDU (Andreas Stolcke) (12/20/90)
In article <80@tdatirv.UUCP>, sarima@tdatirv.UUCP (Stanley Friesen) writes: |> In article <1990Dec14.001146.3131@eng.umd.edu> stripes@eng.umd.edu (Joshua Osborne) writes: |> >In article <1990Dec5.214857.13863@agate.berkeley.edu> you write: |> >> ... which are now running SunOS4.1 and have become unbearably slow when |> >> running standalone X (mostly through the dynamic linking business, |> >> we believe). |> |> >Compile a staticly linked set of X programs, your already poor throughput will |> >become really *really* poor (on a 4Meg system at least). |> First, let me explain a bit what I meant in my original posting about 4.1 being slower that 3.5 with X. Dynamic libraries buy you reduced total virtual memory requirement, thereby reducing swapping and speeding up things. Actually I checked that using pstat -s, and it turns out that my standard initial X desktop uses 9600k under 3.5, but only 7144k under 4.1. Add emacs and latex and the gap increases to 14872k vs. 10904. In fact with swap space being as tight as it is around here, some people could almost do nothing with their machines once X was started, because there wasn't even enough space left for a simple latex run. Obviously this problem was partly taken care of in 4.1. So far, so good. Now the flip side of shared libs is that they have to be linked dynamically, i.e. on every invocation of a program /usr/lib/ld.so is called to resolve references to dynamic libs. The delay this causes on a 3/50 is non-negligible (it probably is on a Sparc), but probably won't be too bad for usual interactive work. Also, most commands use only the shared C lib, so there is not too much dynamic linking to be done. During the startup phase of X, however, a flury of background jobs all requiring dynamic linking against the X libs are created, and this is simply too much for the poor little 3/50s. Again, using my standard X environment, it takes < 2mins to start up under 3.5, but almost 4mins under 4.1. So I should have been more precise in talking about `slowness', making it clear I was talking about startup time. |> I would like to emphasize the truth of this. I, too, believed that the |> dynamic linkng was a speed problem, until we got FrameMaker 2.1X from Frame |> Technologies. That monster is statically linked. True, shelltool takes a |> longish time to *start*, but once it is running it is quite good. Maker |> on the other hand starts slow and then generates a paging fit whenever I |> switch from one activity to another. Talk about *sloooow*! (Frame Technology |> are you listening? - at *least* make xlib and libc dynamic linking!) |> The reason for Frame's using statically linked binaries is probably that they want to prevent against someone getting smart and breaking their license control scheme by `patching' libc.so. I'm not familiar with the details of their implementation, but suppose it gets the host id to match it against a built-in licence. It would be easy to fudge the relevant system calls to always provide the `right' host id... I don't see a reason to not use shared X libs, though, and that would be a *big* win in terms of memory efficiency. Maybe they don't every customer to have a shared version of X libs, but then they could make it an option. -- Andreas Stolcke International Computer Science Institute stolcke@icsi.Berkeley.EDU 1957 Center St., Suite 600, Berkeley, CA 94704 (415) 642-4274 ext. 126
mouse@LIGHTNING.MCRCIM.MCGILL.EDU (12/20/90)
> The reason for Frame's using statically linked binaries is probably > that they want to prevent against someone getting smart and breaking > their license control scheme by `patching' libc.so. [...by fudging > the return from gethostid()...] Even that is pretty simple to fudge, given what you can do with ptrace under 4.1. Look at trace(1) and ptrace(3) and tell me how tough it would be to write a trace(1)-like program that just hacks gethostid() calls...not that that's all you'd need to do a proper copy-protect breaker, but it's most of it. (I have a sort of side contest going with another person here - each of us is trying to produce a copy-protected binary the other can't break. Not much has happened yet, but it's made me look at the available tools....) der Mouse old: mcgill-vision!mouse new: mouse@larry.mcrcim.mcgill.edu
stripes@eng.umd.edu (Joshua Osborne) (12/27/90)
In article <1990Dec19.191336.14848@agate.berkeley.edu>, stolcke@ICSI.Berkeley.EDU (Andreas Stolcke) writes: > First, let me explain a bit what I meant in my original posting about > 4.1 being slower that 3.5 with X. Dynamic libraries buy you reduced > total virtual memory requirement, [...] > > So far, so good. Now the flip side of shared libs is that they have to be > linked dynamically, i.e. on every invocation of a program /usr/lib/ld.so > is called to resolve references to dynamic libs. The delay this causes on > a 3/50 is non-negligible (it probably is on a Sparc), but probably won't > be too bad for usual interactive work. Also, most commands use only the > shared C lib, so there is not too much dynamic linking to be done. > During the startup phase of X, however, a flury of background jobs all > requiring dynamic linking against the X libs are created, and this is simply > too much for the poor little 3/50s. Again, using my standard X environment, > it takes < 2mins to start up under 3.5, but almost 4mins under 4.1. > So I should have been more precise in talking about `slowness', making it > clear I was talking about startup time. I also had this problem, I was starting up so much stuff that it took 10min to start X on a 3/50. Since I was creating the "default user enviroment" for our users, that was not acceptable. With careful use of vmstat I found peoper places to insert sleeps of the right length. On a 4M 3/50 running SunOS 4.1 starting 2 xterms, an xconsole, a dclock, a xbiff, a xcal, twm, xrdb, and a few other things I'm sure I forgot takes... (drumroll please!) one minute and thirty-two seconds! I can post this amazeing .xinitrc, but it's probbly useless to everyone :-) You can get a aproxmation of my results by inserting a small sleep (11 secons) between starting applications, one you start your xterms (or after every 3rd xterm if you have that many). If you are willing to spend time at it rlogin to the machene you want to tune your login for, and run "vmstat 1". Then play with diffrent delay values in diffrent places. (this is how I got my 3/50, 3/60, and 4/60 values; and how I will get my DECStation 3100 values when I get around to it) [Someone upset because frame doesn't use shared libs] > The reason for Frame's using statically linked binaries is probably that > they want to prevent against someone getting smart and breaking their > license control scheme by `patching' libc.so. I'm not familiar with the > details of their implementation, but suppose it gets the host id to > match it against a built-in licence. It would be easy to fudge the > relevant system calls to always provide the `right' host id... Or to edit the binary, it is easy to find syscalls (hint: run it under a debugger). Or make hostid a per-process value (small, ugly kernel hack). This is a dumb reason to use a static libc, and on our systems would make frame difficult to use (our libc uses DNS, our /etc/host table is very small), and slow (memmory). > I don't see a reason to not use shared X libs, though, and that would be a > *big* win in terms of memory efficiency. Maybe they don't every customer to > have a shared version of X libs, but then they could make it an option. Presumabilly if they used shared libs of any sort it would provide the users another way to break the licence manager. A (more) valid point is that it is a real pain for support. They would need to find out the libc, libX11 version numbers, and god help them if someone (like us) has a non-standard shared lib! This seems to be a tipical vender addatude, 'tho some of the more enlightened ones ship a version that uses shared libs and a staticly linked version. The first thing they ask you to do when you phone in a problem is ask what happens when you run the static version... ...normally they don't provide much help if it works. (normally they don't have to, most people take workarounds without complaint). [NOTE: this info was gained from friends who work places that make products, some of them are on the support side, some are on the bulding side...] -- stripes@eng.umd.edu "Security for Unix is like Josh_Osborne@Real_World,The Multitasking for MS-DOS" "The dyslexic porgramer" - Kevin Lockwood "Don't over-comment" - p151 The Elements of Programming Style 2nd Edition Kernighan and Plauger
guy@auspex.auspex.com (Guy Harris) (01/05/91)
In article <1990Dec19.191336.14848@agate.berkeley.edu>, stolcke@ICSI.Berkeley.EDU (Andreas Stolcke) writes: > The reason for Frame's using statically linked binaries is probably that > they want to prevent against someone getting smart and breaking their > license control scheme by `patching' libc.so. I'm not familiar with the > details of their implementation, but suppose it gets the host id to > match it against a built-in licence. It would be easy to fudge the > relevant system calls to always provide the `right' host id... As the other poster who followed up noted, you can fudge the relevant system call by replacing the "/vmunix" shared library (:-) :-) :-)) and break even statically-linked-in host-ID-checking licensing schemes. And note also: auspex% file maker maker: symbolic link to maker2.exe auspex% file maker2.exe maker2.exe: sparc demand paged dynamically linked executable auspex% ldd maker -lsuntool.0 => /usr/lib/libsuntool.so.0.40 -lsunwindow.0 => /usr/lib/libsunwindow.so.0.40 -lpixrect.2 => /usr/lib/libpixrect.so.2.4 -lc.1 => /usr/lib/libc.so.1.3 This is Frame 2.0, with network licensing, so at least for *that* version they either didn't know about the risk of breaking the licensing scheme, didn't care, or somehow arranged that it couldn't be broken (dunno if the floating license stuff uses "gethostid()") 'cuz they sure used dynamic linking out the wazoo, "libc" and all.... In article <1990Dec26.214324.28624@eng.umd.edu> stripes@eng.umd.edu (Joshua Osborne) writes: >A (more) valid point is that it is a real pain for support. They would need to >find out the libc, libX11 version numbers, and god help them if someone (like >us) has a non-standard shared lib! This sounds a bit more plausible, as until recently SunOS didn't come standard with Open Windows (4.0[.x] didn't, I think 4.1 did only if you got one of the diskful machines with SunOS pre-installed, 4.1.1 seems to come standard with it). They'd either have to build with the OW versions - one built against the OW 2.0 libraries might work when run against the MIT version, but perhaps with warnings, as I've heard the OW 2.0 libraries have the same major version numbers as the MIT libraries, but a marger minor version number, perhaps because of some of the stuff like compose-key support added to Xlib in OW 2.0 - or build with the MIT versions. Perhaps they were nervous about having to deal with both the MIT and OW version.... ("libc" is presumably not an issue, given that the SunView version uses a shared "libc".)