Date: Sun, 27 Aug 1995 12:35:30 -0800 From: "Jim Howard" <jiho@sierra.net> To: freebsd-questions@freefall.FreeBSD.org Subject: Re: gnumalloc Message-ID: <199508272104.AA15909@diamond.sierra.net>
next in thread | raw e-mail | index | archive | help
Chuck Robey once said to Terry Lambert about me: > > If I got this next point wrong, I'm surprised, but I thought Jim was > > making a case for not having such areaa of non-shared tools, like /slib. > > Nor an /sbin. Didn't he say he'd link init shared? I agree on maximal > > sharing, but I _do_ leave myself an emergency recovery method. Jim was > > saying that if he needed an emergency recovery, he'd dump the whole > > installation and rebuild. I think that's overkill. Yes, actually I do have init linked shared. It's crazy, I know, but it was there to be done. ALL of /bin and /sbin, *en masse*. That naturally includes tools like ln. So when I rebuilt libc to use GNU malloc instead of BSD malloc (the launching pad of this entire thread, remember), to get the replacement libc installed I copied the original statically linked ln off the CD (suitably renamed) and used it (after mv'ing the old libc) to set up a symbolic link so I can easily switch between the two libc's. (I also had to use chflags to loosen up the old libc so I could mv it. And getting the new libc built with GNU malloc wasn't all that easy to begin with, but that's another story.....) That put me in a position where, had the new libc failed to work right, upon rebooting init might have failed, in which case I would have had to use MY emergency recovery method, which is an elaborate system of floppies (one boot, one mounted by the boot) containing a kernel and a bunch of statically linked and compressed file system repair tools (including ln, so I could switch back to the old libc). All of which would probably be intolerable to a site administrator, but it makes sense to me as an individual in control of my own machine, and that's the point on the "perspective" issue, I think. There might be other, more efficient ways to do some things when the target machine is someone's personal system and priorities are different. (Although those repair floppies do raise a few questions about what "efficient" means and in what context.....) Oh, and by the way, GNU malloc seems to save perhaps a couple of hundred KBs here and there over BSD malloc (it's hard to tell), but that quickly gets drowned in the flood of memory usage generated by X and its clients and their libraries, and you're STILL overflowing into swap just to bring up fvwm and xfm on my 8 MB machine. GNU malloc may be good for the fastidious, but it's no cure for swapping with X. Nothing that has been stated so far really addresses that, because it's endemic to X itself. Terry Lambert then responded to Chuck Robey: > I think you need root level system binaries to the point that /usr *can* > be mounted seperately, even if it isn't the default case. That's CERTAINLY true for servers, and probably true for a lot of personal systems as well. > I didn't get anything from Jim's post that would imply he thought > otherwise, only that the argument of "what if this goes wrong AND > this goes wrong AND this goes wrong..." is complicated to the point > of a reinstall being a better option than worrying about contingencies > to the point of losing sight of the real problem. > > Its the case of "don't optimize the boot code" or more colloquailly, > "don't miss the forest for the trees". Perhaps the forest I'm crawling toward, is one where there might be two distinct configurations of FreeBSD, one for multi-user servers and one for personal systems, with appropriate size-versus-speed tradeoffs for each. Personal system users tend not to notice MINOR speed losses due to size optimizations, but they do notice MAJOR size losses due to speed optimizations. And many of the security issues that afflict multi-user servers are moot on the personal system. Of course, I recognize that there are situations where a personal system might have to double as a multi-user server of a sort, so it might not be a black-and-white issue. And purists would no doubt howl at the whole issue anyway. But it can be done, for character mode, command line FreeBSD, anyway. X (the memory usage of which started this whole thing, by raising the issue of GNU malloc) may be hopeless, because its basic design goals make no sense for a personal system. X was designed, structured and optimized to run with servers and clients separated over a network. That architectural vision drove all the choices in its development (just as the architectural vision of a VAX with a horde of character terminals plugged into it drove all the choices in BSD's development). But for X to really make sense on a personal system, you'd have to fundamentally restructure the server and the client libraries and their interrelationships and rewrite the whole thing from the ground up, and then it wouldn't be X anymore, but something else emulating X. I guess maybe we SHOULD be glad that FreeBSD runs X "fine" with 16 MB of RAM! Edward Wolpert said: > The location where I work is planning to go to disk-less > workstations... Basically a full X-terminal on each desk. (Or run > freebsd on their pc's??? ;-) X terminal market is just starting in the > US, but it's big elsewhere (Well, Japan I believe. Great for > sysadmins. Precisely the point: Great for sysadmins, but what does that do for personal systems? I read several YEARS ago about the X terminal market "just starting." And where is it big? Japan, you "believe"? Hmm..... Obviously, there are situations where the X terminal concept is just the ticket, but that seems like a niche market to me. I think the exceptions prove the rule. Your site probably wouldn't even consider that, if overloaded costs weren't a factor! Finally, Chuck Robey asked me: > to make a 30 minute sojourn amongst my books. I don't think this makes > me very different than most FreeBSD hackers, does it? I really don't > want to 'dumb down', and would probably drop this OS if that became a > major goal. Personally, I think there's very little chance of that > happening. If this means that we'll never be as large a group as Windoze > users, I can live with that, I've never been all that keen on running > with the herd. Have you? No and no, and I'm not suggesting FreeBSD "dumb down." Although I do sometimes grumble when I'm forced into a steep learning curve that I would rather enter at my leisure, so to speak. But if I ever started to feel "shut out of the system" I would look elsewhere, too. I guess I have a split-level attitude on this: I want a sleek, easy-to-drive car, but I want to get under the hood, understand it, and turn wrenches as well. Perhaps I think ideally the latter should be, uh, more optional? My main point revolves around efficient resource usage on the small personal system. Do you think personal systems shouldn't be small? --Jim Howard
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199508272104.AA15909>