Date: Thu, 29 Nov 2001 00:31:39 -0600 From: Mike Meyer <mwm@mired.org> To: "Anthony Atkielski" <anthony@freebie.atkielski.com> Cc: "Randall Hamilton" <nitedog@silly.pikachu.org>, "GB Clark II" <gclarkii@vsservices.com>, "Mike Meyer" <mwm@mired.org>, <chat@FreeBSD.ORG>, <smorton@acm.org>, Subject: Re: Feeding the Troll (Was: freebsd as a desktop ?) Message-ID: <15365.54859.140475.279838@guru.mired.org> In-Reply-To: <01bc01c17892$f2dea380$0a00000a@atkielski.com> References: <15365.11290.211107.464324@guru.mired.org> <006101c17854$c6aa2570$0a00000a@atkielski.com> <3C0574C4.3040001@verizon.net> <016e01c17889$23dfd990$0a00000a@atkielski.com> <3C05BD9D.4000909@verizon.net> <01c601c17896$12bbf560$0a00000a@atkielski.com> <15365.48855.19705.7956@guru.mired.org> <01c101c17895$a2691360$0a00000a@atkielski.com> <01112817112006.13219@prime.vsservices.com> <016301c17888$c1be3cc0$0a00000a@atkielski.com> <000901c17892$28e1ce90$0301a8c0@nitedog> <01bc01c17892$f2dea380$0a00000a@atkielski.com>
next in thread | previous in thread | raw e-mail | index | archive | help
Anthony Atkielski <anthony@freebie.atkielski.com> types: > However, I should be _very_ upset if FreeBSD were "enhanced" to make it more GUI > friendly. I consider FreeBSD to be a superlative _server_ OS, and anything that > might be done to it to enhance the GUI "desktop experience" would almost > certainly diminish its utility as a server dramatically. I agree with that. People come along every so often saying "If you want to take over the desktop, you need to ...". I don't want it to take over the desktop; I want to to be a fast, stable computing platform. That's the major problem I see with Unix - the major distributions have concentrated on trying to take over the desktop, so it's a major PITA to set them up as a server, or doing something slightly unusual. In other words, in trying to compete with Windows, they're adding all the problems I have with Windows. Anthony Atkielski <anthony@freebie.atkielski.com> types: > Mike writes: > > You're asserting something that over a decade > > and a half of experience says is false. > A decade and a half of _your_ experience, perhaps. Yup. How much experience do you have with Unix as a desktop? > > As you've already noted, Unix provides a *minimal* > > multi-user environment. > Minimal compared to Multics, but still orders of magnitude superior to that > provided by Windows. But not that provided by *your* choice of desktop environments, Windows NT. Either way, it's a long way from the the "huge emphasis" you claimed. > Why else would every process have its own effective user ID, if the intent were > not to enhance multiuser environments? You certainly don't need that on a > single-user system. True. Many hammers have a claw on them that can be used to pull nails. You certainly don't need that to drive nails with them, but it doesn't make them any less effective at driving nails. > > SGI has the most complex GUI I've ever run > > into, and they didn't require hardware dependency. > How many hardware platforms were supported? I honestly don't know. Three comes to mind, but you should check with an expert. I can do that if you want. > > They *do* require a well-defined API that > > makes it possible to access the hardware > > efficiently - but that's a completely different > > animal. > Is it? Sounds like just splitting out part of the system to a > hardware-dependent set of components to me. Yup. That's called a "driver". > > I'm mildly amused by the fact that Unix is considered > > a "small, light-weight OS" these days, having dealt > > with systems that provided a faster desktop environment > > than Unix on hardware that cost about 10% of what > > a good Unix box did. > > In the olden days, UNIX and the hardware it ran on had 90% margins, and it was > expensive to build to begin with. UNIX was a heavyweight in those days > (although still stripped in comparison with its ancestor, Multics, or other > proprietary systems like MVS). Today, the same horsepower that cost millions > back then costs a few hundred dollars and will sit on your desk, and since the > core of UNIX has not really changed, it now runs like greased lightning on > virtually any system on which you care to install it. I'm quite certain my > little desktop PC running UNIX here would support 200 timesharing users or more > very easily--it has a thousand times the processing power of UNIX hardware > thirty years ago, and at least 1000 times as much memory, and hundreds of times > as much mass storage space. Actually, you forgot the single most important resource for supporting hundreds of users - I/O throughput - but it's probably got that as well. I replaced several large multi-bus VAX servers with Unix workstations - after retuning the kernel for that use, of course. It was sort of boggling to compute the values for those things, and realize that the pizza box and a couple of shoeboxes had more of everything important than the two refrigerators it replaced. > So UNIX hasn't really gotten smaller or more efficient, but hardware has gotten > bigger, and now UNIX is incredibly compact and efficient compared with other > operating systems. I'm well aware of that. It's gotten larger. It's just that the standards it's being compared to have gone from CP/M, Flex, MS-DOS and OS/9 to various versions Windows. > > In other words, my typical usage patterns for > > Unix workstations qualify as "heavy desktop use", > > and Unix handles them perfectly adequately, > > doing everythiong I call upon it to do. > Yes. However, if you were choosing new systems for the same purpose, Windows > would probably be a better choice, unless you had UNIX-specific applications > that were essential to your purpose. I did that evaluation of desktops in '98. After considering the consumer versions of Windows, BeOS, the Mac, Linux, various RISC-based Eunices, and all three BSD versions, I settled on FreeBSD. Windows and the Mac lacked stability. Windows, the Mac and BeOS had GUI's I couldn't stand using, and no easy way to change them. That's why I didn't bother looking at Windows NT. The RISC-based Eunices didn't provide the bang/buck a Wintel box did, and I didn't need the extra features they provided on my workstation. FreeBSD had the ports tree and Linux emulation, which was why I settled on it instead of Linux > > You seem to be contradicting yourself. > No. See above. Yes. See above. > > Because you might want to let more than one person > > use the computer, and have a little security > > between them? > It's not a single-user system then. How many home systems really are single-user computers? Most of the ones I'm familiar with are used by everyone in the family. > > It may mean you're using a Saturn V for a signal > > flare. > In the context of multiuser support on a desktop, this is true, for UNIX. It > provides far more capability in this domain than any desktop user is ever likely > to require. Fortunately, since it is such a lean OS, this is not much overhead, > although it does impose other technical constraints. I pushed my old system - dual PII/Xeons@450MHz with 2MB of cache, with multiple scsi controllers and no IDE at all - to the point of being unresponsive to keystrokes on the console. All by my little old lonesome. > > Running vi on a Cray means that all that > > nice, fast array processing hardware Seymour put > > into them is going unused, but I can assure you > > from first-hand experience that vi runs just fine > > on a Cray. > It should, with teraflops available to process the interrupts produced by every > single keystroke on your terminal. This is *vi* we're talking about: guru$ pwd /usr/src/contrib/nvi guru$ find . -name '*.c' | xargs grep float ./common/put.c: * floating around. guru$ find . -name '*.c' | xargs grep double ./ex/ex.c: * Command lines that start with a double-quote are comments. ./vi/vi.c: * the *single* characters don't mean anything but the *doubled* ./vi/vi.c: * Commands that have motion components can be doubled to ./vi/vi.c: * appropriately. If not a doubled command, run the function to get guru$ There are no floating point variables in vi, so all those teraflops are commpletely wasted. In fact, the reason it was a tad slower than the VAX was because it took most of a dozen integer instructions for it to convert a byte pointer to a word address and then get the byte you wanted out of the word in question. The VAX did that in one instruction. <mike -- Mike Meyer <mwm@mired.org> http://www.mired.org/home/mwm/ Q: How do you make the gods laugh? A: Tell them your plans. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-chat" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?15365.54859.140475.279838>