📄 00000275.htm
字号:
backup count?...OK...darn, where'd I leave the floppies?") <BR> OK, guessed I proved that statement wrong. Granted, the quicktime <BR> movie I'm watching 8 times is less than 20 megabytes, so it fits in <BR> RAM. If I had to wait for my IDE drive to fetch 8 different movies <BR> totalling more than my total RAM then I'd have problems under any OS. <BR> Formatting a floppy and checking email are trivial; moving my mouse <BR> around and typing uses more CPU time. Unzipping a backup is pretty <BR> nasty although most of the problem is disk I/O. <BR> Actually if BeOS has better disk scheduling and buffering than Linux <BR> (which isn't very hard as Linux's filesystems are very much on the <BR> "dumb" end of the scale) then it probably does the job better. But <BR> it's not true that Linux can't do the job at all. <BR> Some of the claims are pretty funny, like "maximum advantage of any <BR> number of CPU's without developers having to specifically code in <BR> multi-proc support." You need developer cooperation to take maximum <BR> advantage of multiple CPU's. A certain amount of automation makes <BR> multiple-CPU designs easier, but most of that automation happens in <BR> the compiler and libraries (if not the programming language itself), <BR> not at the OS level. The stuff at the OS level is probably quite <BR> similar between BeOS and Linux. But then again maybe that was the <BR> original author's point: BeOS comes with better libraries and <BR> development tools for multiprocessing. It's important to be clear on <BR> this so that we can write it up on the OSS To-Do list. ;-) <BR> BMessages and built-in scriptability? Uhhh, like OLE/Gnome/KDE, or <BR> even Tcl/Tk? (OK, they might be more "elegant"). I'm not even going to <BR> say the words "Bourne Shell"...D'oh! <BR> These are not things that should be tied to an OS. Linux, Windows, and <BR> BeOS are capable of implementing this kind of functionality in user <BR> space, given a nice abstracting library and adequate shared memory <BR> support. <BR> "The days of thinking "one computer, one operating <BR> system" are over"...uhhh...gee, I was kind of hoping the days of <BR> thinking "I might have to reboot this machine for reasons other than <BR> hardware changes or power failure" were over. I don't want multiple <BR> OSes on one machine. I don't even want a single OS on one machine. As <BR> a consumer (i.e. not doing my paying software development job, but <BR> simply buying consumer electronics and using them) I want lots of <BR> cheap little machines doing cheap little tasks, and I don't care if <BR> they're all running one OS each or one OS for all of them as long as <BR> they work and as long as they are extensible through addition of <BR> third-party software. Argh...I think I just said I wanted Java. <BR> <BR> Zygo Blaxell - Subject: And now that I've read the comparison chart... <BR> (1998-12-09 13:41:18) <BR> This is a significant beef with me: Perceived installation complexity <BR> on supported hardware. <BR> In the past year I've installed and configured five Linux servers (two <BR> at work, two at home, one owned by colleagues). In each case the <BR> installation process was: insert CD, power on, accept default <BR> settings, wait for colorful bar graphs to go by, remove CD, reboot. <BR> Heck, I was able to network-boot a Sparcstation running Linux/sparc <BR> without much trouble (assuming you know how to network-boot a <BR> Sparcstation in the first place, which can be _heavily_ geekish, <BR> installing Linux instead of Solaris is a simple matter of substituting <BR> CD's on the network server). <BR> I've also attempted to install Solaris and QNX on a i386 machine using <BR> my choice of partitioning. In one case it was necessary to move the <BR> CD-ROM drive to a different IDE interface, while the other case <BR> required changing the partition table in a very inconvenient way. Both <BR> of these OS's are no-brainers to install on blank hard disks but <BR> trying to install on an existing system is a nightmare. <BR> Be might have this sort of thing down to a fine art, but Linux is a <BR> close second. <BR> Is Linux actually POSIX-certified now? I thought it was still trying <BR> to get certification but didn't have it yet. Or am I thinking of <BR> Caldera's X/Open Unix certification? <BR> I wouldn't say porting BeOS is easier than porting Linux to new CPU <BR> architectures until I had done both. Porting an OS to a different CPU <BR> architecture means rewriting basic memory management and IRQ stuff, <BR> device drivers, any code with register-size and byte-sex issues, and <BR> any assembly language in your run-time libraries. This takes <BR> person-*years* of time for an OS and enough tools to develop <BR> applications. <BR> I'd like to see if POSIX-compliant programs can "take full advantage <BR> of any number of processors automatically," or only BeOS-specific <BR> ones. <BR> <BR>=================== End of readers' comments===================== <BR> Then what's your comment? Come on to tell it on SMTH/Linux....:) <BR>-- <BR>|======================+========================+====================| <BR>| 以无法为有法 , | 拳本无法,有法也空; | 我爱GNU/Linux, | <BR>| 以无限为有限 | 一法不立,无法不容。| 因为我爱自由! | <BR>| | | | <BR>| 截拳道宗师-李小龙 | 意拳宗师-王芗斋 | 土人 Linuxrat | <BR>|======================+========================+====================| <BR> <BR>※ 来源:·BBS 水木清华站 smth.org·[FROM: 202.112.168.252] <BR><CENTER><H1>BBS水木清华站∶精华区</H1></CENTER></BODY></HTML>
⌨️ 快捷键说明
复制代码
Ctrl + C
搜索代码
Ctrl + F
全屏模式
F11
切换主题
Ctrl + Shift + D
显示快捷键
?
增大字号
Ctrl + =
减小字号
Ctrl + -