From: Digestifier To: Linux-Misc@senator-bedfellow.mit.edu Reply-To: Linux-Misc@senator-bedfellow.mit.edu Date: Wed, 1 Sep 93 14:13:15 EDT Subject: Linux-Misc Digest #81 Linux-Misc Digest #81, Volume #1 Wed, 1 Sep 93 14:13:15 EDT Contents: Re: Linux and Corporate America (Tim Smith) Re: coprocessor makes LOTS of difference (Robert P Glamm-1) TeXcad for linux? (CARSTEN@AWORLD.aworld.de) Re: Ian Jackson (Lars Wirzenius) Re: Term security flaw (Re: Term limitation...) (sn) IDE Multiple Mode - It works. (Mark Lord) Re: What, if anything, should be statically (David C. Niemi) Compressing file systems ("David Herron") Re: coprocessor makes LOTS of difference (Mark Lord) Re: What, if anything, should be statically linked (Lars Wirzenius) Re: Windows Pop Quiz Re: NT versus Linux (Bill Poitras) ---------------------------------------------------------------------------- From: tzs@hardy.u.washington.edu (Tim Smith) Subject: Re: Linux and Corporate America Date: 1 Sep 1993 15:37:03 GMT Thomas Aaron Insel wrote: >A nominal fee is required to register a copyright in the US. However, >registration isn't required to enforce a copyright. To elaborate, the nominal fee is <= $20. The form that is required is simple (~1 page). There are two very good reasons to register: (1) Statutory damages. If you don't register, you are only going to be able to recover actual damages. For software that you give away, this is going to be small. U.S. copyright law allows people who register to opt for damages specified in the copyright law, rather than actual damages. The range of statutory damages is something liek $500 to $10000, with the actual amount up to the judge. (2) Attorney fees. If you register, when you sue and win the other side has to pay your attorney fees. If you don't register, you have to pay your own attorney fees. --Tim Smith ------------------------------ From: glam0001@gold.tc.umn.edu (Robert P Glamm-1) Subject: Re: coprocessor makes LOTS of difference Date: Wed, 1 Sep 1993 15:42:12 GMT >> Based on preliminary testing, a 386-DX 40 with a Cyrix 83D87 40 Mhz >> FPU chip is faster than a 486-33. >> >> This is based on POV 1.0 tracing the file ntreal.pov. >> Results: >> 386-40 with Cyrix: 9 hours 23 minutes >> 486-33 : 11 hourand 10 minutes >> >>The tests were executed on unloaded machines, using the same quality >>and size options for the rayracer. >> >...something is wrong here. Was the 486 an intel, or a Cyrix, or an AMD? >Was the 486 crippled with minimal memory? Or was the 486 suffering from >not having memory above 16M cached (if so equipped.)?? If the 486 was >a clone, did it also have a co-processor? >Other possibilities -- does POV do heavy graphics rendering? If so, are >the video cards similar? (...a slow Trident vs. an et4000 perhaps?) >>Since I purchased my Cyrix , X performance has improved dramatically. >>PostScript rendering has also improved a lot. >> >>If anyone is thinking of buying a new system (and price _does_ matter for you) >>I definitely recommend the 386-40 with a coprocessor combo over against >>a 486. Ok, my turn. On a true 486DX-33, the built in coprocessor is FOUR TIMES as fast as a 386/387 combo running at the same speed. Let's do a little math here: 33 MHz "487" = 129 MHz 387. This should mean that the "487" should go 3.225 times FASTER than your Cyrix 386/387 running at 40 MHz. But, according to the above results, your Cyrix is running the test in 84% of the time. Which means that, for example, the SIN operation on ST(0) is running at 241/(3.225/.84)= 63 clocks!!! I can only wish for a coprocessor like that... especially since the MINIMUM time for a 387 SIN operation running at 33 MHz is 122 clocks, with the *AVERAGE* somewhere around 400 clocks. The question here is: Was that 486-33 a DX or an SX? I can see a 486-33SX w/ floating point emulation running that slow. Getting a coprocessor would *definitely* improve X performance and PostScript redering. What we should do is write a program that uses a giant loop of floating point and test it; I've got a 486DX-33, so I could do one test; you could test your Cyrix 386/387 combo. Bob Glamm glam0001@student.tc.umn.edu -- IsfbhfkEslwkN o o Bob Glamm o o hOEOwEDnkfosoco xLhgfkVyWDdsa ( ) 900 Washington Ave SE klIqoemvbiohle, jsl1fjeDslviI ^ Minneapolis, MN 55414 ( ^ ) xjerVsAjdWijfkk kOsifdjANjAWL \_____/ glam0001@student.tc.umn.edu O iVLjwkle;lNIjee ------------------------------ From: CARSTEN@AWORLD.aworld.de Subject: TeXcad for linux? Date: Wed, 1 Sep 93 07:39:00 CET hello, does anybody now if there exist a simple graphic interface for LaTeX-style graphics (picture-environment)? i mean an equivalent for the TeXcad program of the emTeX package for DOS, where a LaTeX output file is created while you are drawing CAD like. tschuess carsten ## CrossPoint v2.1 R ## ------------------------------ From: wirzeniu@klaava.Helsinki.FI (Lars Wirzenius) Crossposted-To: comp.os.linux.help Subject: Re: Ian Jackson Date: 1 Sep 1993 19:43:59 +0300 keating@acf2.nyu.edu (keating) writes: > **READ THIS BEFORE POSTING** > You are an intolerant ass who should not have the priviledge of being > allowede on the Internet. > Cheers and tallyHo. > C The summary said something about wasting bandwith, but failed to specify whether it was Ian or keating who was doing that. From the tone of the posting quoted above, I can only assume he/she/it/they meant Ian, so I guess it's the provocation I need to defend the daily posting (again). Some people claim that the daily posting wastes bandwidth. At first, it might seem that way, since it is, after all, several kilobytes and is posted every day. However, this calculation does not take into account the fact that the daily actually reduces the number of articles posted to the Linux groups because it makes known some more or less generally accepted guidelines of good behaviour on the groups, and points out some places where information can be found without posting to the group. You are free to not believe it has that effect. There are, to my knowledge, no hard facts that support it, but it has been my "gut feeling" (if that's the expression I want [1]) that it does, or at least used to. For a while, since some time before the split of comp.os.linux, I've noticed more and more inappropriate posts again. [ Crossposted to c.o.l.misc, with followups also directed there; it is the most appropriate of the Linux groups for this issue. ] -- Lars.Wirzenius@helsinki.fi (finger wirzeniu@klaava.helsinki.fi) MS-DOS, you can't live with it, you can live without it. [1] Nope, I'm not related to Bertie, except perhaps by sharing I.Q. levels. ------------------------------ From: sn@plato.chemietechnik.uni-dortmund.de (sn) Subject: Re: Term security flaw (Re: Term limitation...) Date: 1 Sep 1993 15:40:11 GMT mjalava@alpha.hut.fi (Mika Matti Jalava) writes: >In article <25dh4c$gjo@nz12.rz.uni-karlsruhe.de> s_titz@ira.uka.de (Olaf Titz) writes: >>read: you still can get in via *tredir* and telnet. >Could someone please summarize the ports to be redirected for each >service or at least point out where such information is easily >available. > Mika Have a look at /etc/services or /conf/net/services (Depending on your net software. -Sven ------------------------------ From: mlord@bnr.ca (Mark Lord) Subject: IDE Multiple Mode - It works. Date: Wed, 1 Sep 93 16:13:44 GMT In article <1993Aug31.155710.9018@unlv.edu> maniac@unlv.edu writes: ... >Does anyone have the address of Promise Technology, Inc, the people >that make VLB IDE controllers? Or better yet, anyone have programming >information for the chips, particularly the non-caching controller >(uses DC2000.SYS driver). I suspect that the same software will work >with both controllers, but I want to get my controller working full >speed first, before I test it. > >BTW, before someone insists that a noncaching VLB controller cannot >improve IDE disk speeds over an ISA adapter on an 8Mhz bus, and Of course VLB will work faster! The interface is clocked at 33Mhz rather than 8.3Mhz, so assuming a fast IDE drive, data transfers can be much faster! >8 Mhz ISA Controller : 52 minutes >13 Mhz ISA Controller : 39 minutes >VLB controller : 35 minutes > >BTW, this is without 32bit transfers and IDE multiple commands >(which is why I'm looking for this info). Coming soon to patch near you.. I have the "IDE multiple commands" working on my system as of last night, and the difference is awesome on benchmarks: 2Mbyte/sec data transfers on WRITEs, versus roughly 1Mbyte/sec without multiple mode (Micropolis 2112A). Curiously enough, the READs only seem to achieve about 1Mbyte/sec, probably since the onboard cache in the IDE drive helps more for writes than for reads. (with writes it can buffer the data and write it while linux prepares the next request, making effective speed seem greater -- drive can do 5.6MB/sec -- but for reads it has to wait for the data, and linux grabs it as fast as it arrives, and the drive probably doesn't guess what to read-ahead next). More importantly, kernel overhead is now roughly 40% (or less) rather than 90% of the total time reported by time(1). This makes sense in theory too, as most disk transfers are for 1024byte blocks = 2 sectors.. using "multiple mode", only half as many kernel interrupts are required. For larger numbers of sectors, the kernel overhead drops even more, as expected. Still to do: scatter/gather to combine multiple requests into fewer commands to the drive (using multiple mode). I expect to post the (short) patches to hd.c later this week, possibly including a simply scatter/gather implementation. I also would like to add DMA support for IDE drives, but the two IDE cards that I have don't have the DMArq/ac signals connected to anything.. cannot barnacle them either, cuz they don't even have the ISA "fingers" for those signals from the backplane. Oh well. 'Guess I'll have to cobble something together later once I get a copy of the IDE standard (ANSI X3.221). -- mlord@bnr.ca Mark Lord BNR Ottawa,Canada 613-763-7482 ------------------------------ From: niemidc@oasis.gtefsd.com (David C. Niemi) Subject: Re: What, if anything, should be statically Date: 1 Sep 1993 17:34:54 GMT Reply-To: niemidc@oasis.gtefsd.com In article 93Aug31230228@apex.cs.tufts.edu, gowen@apex.cs.tufts.edu (Gregory Owen) writes: > >In the ongoing thread about staticly linked binaries, >niemidc@oasis.gtefsd.com (David C. Niemi) wrote: >> I am basing this primarily on what commands I HAD TO have when fixing >> badly crashed Suns that I did not have an alternate boot medium for >> (or did, but did not have shared libraries available). > > I had to bring up a smoked sparc today, and I found myself >repeatedly wishing I could just pop the boot/root combo into the 3.5 >drive, just like Linux. As it happened, we booted off of two seperate >hard drives, a cd-rom and a tape drive before we got anywhere. (not >that we got very far). Boot floppies are a very powerful tool, especially when they are as well- implemented as they are under Linux (and fit so much good stuff onto one floppy). Many times, I wished I had such a thing for SPARCs (I do for the Sun386i). But some Suns don't even have floppy drives. > Oh yeah... my point. First, what use are statically linked >binaries when a boot floppy with a root partition fits onto a floppy >or two? This is vaguely hypothetical, but I think that is a very >practical way to fix things -- I've used it on my linux box several >times. Better than static binaries, IMHO. What's wrong with a bit of both? It is not always practical or necessary to use a boot floppy. Furthermore, what do you do when you ACCIDENTALLY hose your libc and cannot shut down properly? A boot floppy is of no help there. That is why I believe "sync" and "update" gotta be statically linked, if nothing else. "mv" gives you a good chance of fixing the problem, too. I certainly don't advocate doing "lots" of statically linked binaries, but some are ESSENTIAL. > Secondly, and another idea that hit me whilst playing doctor >to that 'puter today, wouldn't it do to have a floppy with selected >static binaries on it? Then all you need is "mount" on the system and >you can get that floppy mounted, from which you'll have most of the >commands you need. Sort of a "Linux doctor disk." I'd be willing to >look into building one if people thought it would be useful. If you >do, drop me a line; if I get enough lines, I'll have a page... er, I >mean I'll investigate what utilities people would want (although I'll >tell you RIGHT NOW emacs won't fit. Learn VI. 8). > Sun trivia question: fsck is not _really_ in /etc; its a link >to /usr/bin/fsck. Which is the most annoying thing in the world when >you keep trying to /etc/fsck the /usr partition. True on SPARC SunOS 4.x. The Sun386i has "fsck" in /sbin, along with about 580 KB total stuff (presumably more than we'd want to be statically linked for Linux): fsck init netconfig sh ifconfig mount reboot Note that reboot is used instead of sync, and they also added ifconfig/netconfig and mount. "update" is statically linked too, but not in sbin. --- David C. Niemi: David.Niemi@oasis.gtegsc.com I have seen th' darkness an' th' pain, Griffy... I have frolicked in th' Devil's Themepark...I have lain down with dawgs... ------------------------------ From: "David Herron" Subject: Compressing file systems Date: Wed, 1 Sep 1993 17:33:50 GMT I am familiar with an SunOS package called Power Drive which invisibly (de)compresses your files. It operates somewhere around the file system interface but does not show up as something you `mount' anywhere. When a powerdrive-compressed file is accessed (for read) power drive kicks in and decompresses the file. So on the first block there's a pause, then every other read happens at normal speed because the file is completely uncompressed. It stays uncompressed until recompressed. At 3:00 in the morning (or whenever you tell cron to do so) you start up powerdrive telling it to compress the files in your system. You list in a file which files to *not* compress. (Important things like dump, restore, /vmunix, the programs ran in `rc' before the powerdrive driver is loaded, etc). All this solves, at least, the problem of random access into the file. <- David Herron (work) (home) <- <- All hard work brings a profit, but mere talk leads only to poverty. <- Proverbs 14:23 ------------------------------ From: mlord@bnr.ca (Mark Lord) Subject: Re: coprocessor makes LOTS of difference Date: Wed, 1 Sep 93 17:20:42 GMT In article glam0001@gold.tc.umn.edu writes: > >>> Based on preliminary testing, a 386-DX 40 with a Cyrix 83D87 40 Mhz >>> FPU chip is faster than a 486-33. >>> >>> This is based on POV 1.0 tracing the file ntreal.pov. >>> Results: >>> 386-40 with Cyrix: 9 hours 23 minutes >>> 486-33 : 11 hourand 10 minutes >>> >>>The tests were executed on unloaded machines, using the same quality >>>and size options for the rayracer. >>> >>...something is wrong here. Was the 486 an intel, or a Cyrix, or an AMD? >>Was the 486 crippled with minimal memory? Or was the 486 suffering from >>not having memory above 16M cached (if so equipped.)?? If the 486 was >>a clone, did it also have a co-processor? > >>Other possibilities -- does POV do heavy graphics rendering? If so, are >>the video cards similar? (...a slow Trident vs. an et4000 perhaps?) > >>>Since I purchased my Cyrix , X performance has improved dramatically. >>>PostScript rendering has also improved a lot. >>> > >>>If anyone is thinking of buying a new system (and price _does_ matter for you) >>>I definitely recommend the 386-40 with a coprocessor combo over against >>>a 486. > >Ok, my turn. On a true 486DX-33, the built in coprocessor is FOUR TIMES as >fast as a 386/387 combo running at the same speed. Let's do a little math >here: > 33 MHz "487" = 129 MHz 387. > >This should mean that the "487" should go 3.225 times FASTER than your Cyrix >386/387 running at 40 MHz. But, according to the above results, your Cyrix Something that is being missed here is that the third-party "387" vendors generally have faster implmentations than the Intel'387 series. They require fewer external clocks to complete their calculations. This (and price) is their prime raison d'etre. So yes, perhaps this "487" is being run 3.225 times faster, but if it is only 1/3 as efficient internally, they might come out about the same. -- mlord@bnr.ca Mark Lord BNR Ottawa,Canada 613-763-7482 ------------------------------ From: wirzeniu@klaava.Helsinki.FI (Lars Wirzenius) Subject: Re: What, if anything, should be statically linked Date: 1 Sep 1993 20:56:57 +0300 niemidc@oasis.gtefsd.com writes: > In article pgo@klaava.Helsinki.FI, wirzeniu@klaava.Helsinki.FI (Lars Wirzenius) writes: > >Just for fun, I compiled the fileutils package both with static and > >dynamic linking. The total disk usage of cp, dd, ln, ls, mkdir, mv, > >rm was 72 kB when linked dynamically, 558 kB when linked statically. > >I think the difference is large enough that many people do not with to > >have statically linked programs if they can avoid it. For > >installation floppies, there is not chance of being able to fit the > >statically linked copies in there. > > This is a sign that Linux is using a good libc. It is exactly why the > statically linked utilities should be limited to only those truly necessary. The problem is, which utilities _are_ truly necessary? The answer depends heavily on the preferences of the user/sysadmin on the machine. E.g., I'm more than glad to save even a couple of hundred kilobytes on my hard disk and risk having to reboot a system without shutting down properly (syncing is done by /etc/update or /etc/init every 30 seconds or so, so that is usually not a problem for me). Other may disagree. Also, the answers depend on exactly what kinds of scenarios one can think of; if I happen to log out of all shells before noticing the problem, getty, login, the shell, and ln need to be statically linked. I have the impression that the problem of missing shared library images occurs mostly when updating the symlink (using rm/ln instead of ln -sf), so for most people the truly necessary program to have is a program to install a new shared library image, or, failing that, a statically linked copy of ln. -- Lars.Wirzenius@helsinki.fi (finger wirzeniu@klaava.helsinki.fi) MS-DOS, you can't live with it, you can live without it. ------------------------------ From: bill@msi.com (Bill Poitras) Crossposted-To: comp.os.ms-windows.advocacy Subject: Re: Windows Pop Quiz Re: NT versus Linux Date: 1 Sep 1993 18:09:39 GMT Reply-To: bill@msi.com Mark A. Davis (mark@taylor.uucp) wrote: : sills@mv.mv.com (Glenn Sills) writes: : >Clearly, it is because all the other OS's suck as much or even more than Windows. : That presupposes that MS-"Windows" is an operating system, which by all : definitions I have known, it is not. Current temperature: 68 degrees? This touched off a very uninteresting thread. Lets get back to the subject at hand: Windows NT vs. Linux. Lets assume for sake of argument that they are indeed OSes. Why can either group say to advocate their favorite? -- +-------------------+----------------------------+------------------------+ | Bill Poitras | Molecular Simulations Inc. | Tel (617)229-9800 | | bill@msi.com | Burlington, MA 01803-5297 | FAX (617)229-9899 | +-------------------+----------------------------+------------------------+ |FTP Mail |mail ftpmail@decwrl.dec.com | Offers:ftp via email | | |Subject:helpquit | | +-------------------------------------------------------------------------+ ------------------------------ ** FOR YOUR REFERENCE ** The service address, to which questions about the list itself and requests to be added to or deleted from it should be directed, is: Internet: Linux-Misc-Request@NEWS-DIGESTS.MIT.EDU You can send mail to the entire list (and comp.os.linux.misc) via: Internet: Linux-Misc@NEWS-DIGESTS.MIT.EDU Linux may be obtained via one of these FTP sites: nic.funet.fi pub/OS/Linux tsx-11.mit.edu pub/linux sunsite.unc.edu pub/Linux End of Linux-Misc Digest ******************************