Date: Sat, 06 Jan 1996 13:55:27 -0800 From: "Jordan K. Hubbard" <jkh@time.cdrom.com> To: "Kaleb S. KEITHLEY" <kaleb@x.org> Cc: hackers@freefall.freebsd.org Subject: Re: Demand loading (Re: FreeBSD, Zappa & PCI) Message-ID: <17133.820965327@time.cdrom.com> In-Reply-To: Your message of "Sat, 06 Jan 1996 14:49:25 EDT." <199601061949.TAA17491@exalt.x.org>
next in thread | previous in thread | raw e-mail | index | archive | help
> Next thing you'll be telling me I don't want a malloc that agressively > sbrks memory back to the system. I'm the customer damn it. What I want is > not right or wrong, it's just what I want. If you don't want to give it > to me, I'm sure I can find someone else who will! Linux perhaps? Linux > has ELF, Linux has gnumalloc in libc. Gee, Linux looks mighty damn good. I think we're getting a little overheated here, perhaps, albeit with the odd smiley still in attendance. Perhaps it's not too late. Look, I don't think that it's worth-while debating the technical merits of ELF here. I think that, all things considered, it's probably a better mousetrap than a.out and sort of a moot point in the comparison anyway since SVR4 and Linux have both adopted it and we're going to be bombarded with ELF fanatics from now until doomsday until *some* type of support emerges. Ultimately, the "customers" will win out. However, everything is a question of trade-offs and Kaleb, being from the X Consortium, should be well aware of that. Hell, being from the X Consortium, I think he'd be *more* than aware of that. Let's see if we can't use X itself as something of an analogy: <XFLAME> X is probably a shining example of one of the greatest technological crocks-through-compromise of our time and, come the revolution, I suspect that everyone responsible at MIT will be among the first up against the walls and shot (right after everyone in Redmond has first been put to the sword and Bill's head paraded through the city on a pike). Nonetheless, despite being Evil Incarnate in almost every conceivable way, X has been a more-than-moderate success (and the less said about Bill and his minions the better). Why? Because they compromised enough to get it running on everybody's hardware, eschewing less technically elegant solutions that wouldn't have worked on the aging Sun 3/50's (4MB! Soldered to the motherboard!) of the day. They decided to not make anybody mad by imposing a pre-conceived notion of Look-And-Feel, and suckered everyone into thinking that their "mechanism not policy" credo was a Good Thing for long enough to get them signed up (at which stage, they all clamored for a unified Look-and-Feel, of course, but it was already too late). Compromise compromise compromise. Above all, X never made the slightest attempt to appease the *users* of the system, just the hackers who were its early proponents. There were no interface builders at the start, nor was the toolkit even usable until the later days of X11. When the user's started making far too much noise about the lack of any kind of L&F policy, In short, it was a technological disaster and has since, quite naturally, taken over the world. X is, in short, in almost complete refutation of every point Kaleb makes about giving the customers what they want! </XFLAME> What does all this have to do with ELF and a.out? Well, I'll tell you. Despite all of X's now-obvious shortcomings, I don't think they could have done it in any other way. An early toolkit that tried to impose look-and-feel probably would have sunk under the shellfire of numerous vendors who didn't feel it matched their local asthetic. Sticking a more extensible mechanism into the server would probably have made it slow and unusable on the early Sun machines which probably did more to bootstrap X than anything else (the native Suntools was, you see, completely awful). In other words, if they'd tried to make X into NeWS right at the start, X would probably be where NeWS is today (dead). Where they screwed it up was in not throwing some weight around just as it looked like their base technology was truly taking off, and trying to impose some sort of order on the rabble. If they'd taken 5 or 6 of their best and redirected their efforts to providing more "complete solution" oriented tools before the commercial programmers had even figured out what X *was*, they'd have blown the commercial desktop offerings away and gotten more defacto standards in place before the forces of mediocrity and bloat from HP and DEC got organized. As it was, things like DECWindows and Motif were developed to fill the vacuum, and they all still sucked. We don't have to make the same mistakes. We can spend the next year or so with FreeBSD totally obsessed with improving the underlying tools so they'll be good enough for the hackers and ignoring the greater needs of our user base, or we can down tools on certain parts of it, declaring them "good enough!" for the time being, and spending some time dealing with fires burning elsewhere. We can and should try to round FreeBSD out on a *number* of fronts and not just the pieces we're most personally interested in. To use X as an analogy again, it's no good getting caught up in the technology of putting pixels on the screen if you're going to drop the far more important questions of *why and when you'd want them there* on the floor. Saying that such things can safely be left to others is also an obvious untruth - we've all seen what happened when that kind of thing got left to others. ELF is one of those technologies that may well prove useful to us someday, but we need to be careful about when we go to it. Right now, we're just trying to repair our reputation for stability that was tarnished somewhat in the 2.0 merger and another big shake-up right now would be really poorly timed. We also need to be wary of adopting technologies for adopting's sake. I've heard some good reasons why ELF would be *nice*, but I see no reason why it'd be *necessary* at this particular point in time. I can think of a lot of other things that are pretty necessary, however, and it would seem to be an effective *compromise* to agree to look at those things first. As I said, I fully expect Kaleb to be aware of the need to compromise occasionally.. :) Jordan
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?17133.820965327>