From: Digestifier To: Linux-Development@senator-bedfellow.mit.edu Reply-To: Linux-Development@senator-bedfellow.mit.edu Date: Sun, 21 Nov 93 12:13:11 EST Subject: Linux-Development Digest #244 Linux-Development Digest #244, Volume #1 Sun, 21 Nov 93 12:13:11 EST Contents: Re: Don't use Motif for free sw: it now requires runtime royalties! (Frank Lofaro) Re: TAMU X INSTALL (Helmut Geyer) Re: Don't use Motif for free sw: it now requires runtime royalties! (Matt Ranney) Re: Don't use Motif for free sw: it now requires runtime royalties! (Matt Ranney) Re: Don't use Motif for free sw: it now requires runtime royalties! (Lawrence Foard) How I got the atdisk2 patch to work on a GW2000 4DX2-66V. (Timothy E. Neto) Linux Kernel Buffer questions... (Kelly Evanson) Re: TAMU X INSTALL (Dirk Hohndel) Re: No core dumped? (Nicholas Ambrose) ---------------------------------------------------------------------------- Crossposted-To: comp.infosystems.www,comp.windows.x,comp.windows.x.i386unix,comp.windows.x.motif,gnu.misc.discuss,comp.sources.d From: ftlofaro@unlv.edu (Frank Lofaro) Subject: Re: Don't use Motif for free sw: it now requires runtime royalties! Date: Sun, 21 Nov 93 06:10:17 GMT In article <1993Nov20.201945.25355@spectrum.xerox.com> leisner@eso.mc.xerox.com writes: >I recall when Motif was coming out there was a request not to use it since >its not free... > >I'm not an X programmer (yet) but an X user/builder/debugger of >C code... > >From what I've seen its not clear what you accomplish with motif you >can't accomplish with the Athena widgets... >maybe its a little harder (?? -- how much?) but at >least its free to give away... > I agree! If we could port the freeware Motif apps (most notably, xmosaic), to use Athena widgets, it would end a lot of these sticky problems. Plus, I find the motif look and feel to be "cheesy" sometimes. (twm {does this use the Athena widgets?} is nicer than mwm, as far a I'm concerned). The Athena widgets come standard with X, (and free), it would make things much easier if people used that! (not only less copyright problems, but no additional libraries that are not standard with X would be needed, taking up space) ------------------------------ From: geyer@polyhymnia.iwr.uni-heidelberg.de (Helmut Geyer) Subject: Re: TAMU X INSTALL Date: Sun, 21 Nov 93 06:35:36 GMT Phil Perucci (philp@universe.digex.net) wrote: :>In article <1993Nov20.050819.6807@msus1.msus.edu>, :>Patrick J. Volkerding wrote: :>>Quite to my surprise, I found myself flamed by some of the XFree people :>>over including this in the Slackware distribution. I've never had any :>>problems with it, and I don't know of anyone who has. I imagine there are :>>some people out there who never did get it to work, but I've used it to :>>great success on a variety of accelerated and non-accelerated cards. :>> :>>So, I'd like to hear if anyone out there has experienced trouble with :>>this package, such as hardware problems during the initial setup, or later :>>while using a mode that seems to work. :>> :>>Reports of success would be good, too. :^) :>> :>I remember reading related posts some time back. It seems the danger :>is for people without multisync monitors. Multisync monitors are reported :>to be safe in that they can not be driven beyond safe operating limits. :>Non-multisync monitor CAN be driven outside safe limits. This can :>quickly result in blown fly-back transformers! Bummer! Here come another myth. Not all Multisync monitors are safe, there are several reports of frying Multisync monitors. The more intelligent multisyncs do not turn on the tube until being sure which frequency they are syncing at the moment and until verifyiong that this frequency is within specs. These monitors can very easily be fried , too. There have been reports of fried multisyncs, so this is not only some theoretical blabla. You can drive nearly any monitor 10% over specs (at least any I have seen yet). Even this may damage your monitor, multisync or not. Furthermore there are multisync monitors with holes in the sync areas (i.e. syncing capability from 30kHz-40kHz and from 50-60kHz e.g.). You have to be very careful with those, as they often have good specs for any resolution, but will stumble over low refresh high resolution modes. :>My multisync happens to be NEC, but I believe other non-NEC multisyncs :>should be OK (safe)... There is no such thing as safety if you do not take your pocket calculator and multifly these Xconfig numbers to see whether they are good for your monitor. It is not TO hard to multiply two or three numbers and compare the resulting numbers with the specs of the monitor. So this step must be part of ANY Xconfig setup. :>Still, next time I eagerly install the latest and greatest Linux :>(Slackware) I will 1) use my current Xconfig as a go-by and 2) look :>at /usr/X386/lib/X11/etc/modeDB.txt. Helmut :>-- :>============================================================================== :> Phil Perucci | "All postings are my own opinion - all comments :> Systems Programmer | are intended for research/educational purposes" :>============================================================================== -- ============================================================================== Helmut Geyer geyer@kalliope.iwr.uni-heidelberg.de ------------------------------ Crossposted-To: comp.infosystems.www,comp.windows.x,comp.windows.x.i386unix,comp.windows.x.motif,gnu.misc.discuss,comp.sources.d From: mjr@syl.dl.nec.com (Matt Ranney) Subject: Re: Don't use Motif for free sw: it now requires runtime royalties! Date: Sun, 21 Nov 1993 07:11:08 GMT ftlofaro@unlv.edu (Frank Lofaro) writes: >I agree! If we could port the freeware Motif apps (most notably, xmosaic), to >use Athena widgets, it would end a lot of these sticky problems. Plus, I >find the motif look and feel to be "cheesy" sometimes. (twm {does this use the >Athena widgets?} is nicer than mwm, as far a I'm concerned). Well I happen to *like* the Motif look and feel. I don't use mwm, but I like to use Motif apps. I think using the Athena widgets would take away much of the slickness of Mosaic for X. Motif is the standard. We just need a free implementation of that standard. -- Matt Ranney - mjr@syl.dl.nec.com "You know, I don't think theres a man, woman, or child alive today who doesn't enjoy a lovely beverage." -DL ------------------------------ Crossposted-To: comp.windows.x,comp.windows.x.i386unix,comp.windows.x.motif,gnu.misc.discuss,comp.sources.d From: mjr@syl.dl.nec.com (Matt Ranney) Subject: Re: Don't use Motif for free sw: it now requires runtime royalties! Date: Sun, 21 Nov 1993 07:58:15 GMT strat@cbs.ksu.ksu.edu (Steve Davis) writes: >>Tell that to the thousands of people who run the static binary of >>NCSA's Mosaic for X on their Suns. >I run a static binary of NCSA's Mosaic on suns. >strat@cbs:~> size `which Mosaic` >text data bss dec hex >1826816 172032 167280 2166128 210d70 >And this is with a number of optional packages commented out of the >makefile. If Rick couldn't say it, I certainly can: Statically >linked Motif binaries are simply too large ... "too large" for what? He said they were "too large to be useful," which is obviously incorrect because there are thousands of people out there like me who get use out of it. You must get use out of it too, otherwise why would you have it on your disk? Plus, it's a lousy 2 megs. Big deal. Once you get a bunch of images going, it can easily take up an additional 2 megs or more. The gcc dir on my system is around 12 megs, and it's probably about that much on your system too, assuming it wasn't "too large" for you. -- Matt Ranney - mjr@syl.dl.nec.com "You know, I don't think theres a man, woman, or child alive today who doesn't enjoy a lovely beverage." -DL ------------------------------ Crossposted-To: comp.windows.x,comp.windows.x.i386unix,comp.windows.x.motif,gnu.misc.discuss,comp.sources.d From: entropy@world.std.com (Lawrence Foard) Subject: Re: Don't use Motif for free sw: it now requires runtime royalties! Date: Sun, 21 Nov 1993 08:48:13 GMT In article <2ce3p0$kc3@elroy.jpl.nasa.gov>, >>Finally a personal note: I think that this decision of the OSF is ill >>considered; I am hard pressed to think of *any* supplier of graphical >>libraries of any sort that requires the payment of a royalty on every >>copy of a program using a runtime library. > >I agree on the latter point. It stinks. But from a business perspective, >they've got the customers. They may as well "turn the screw". Look at who >you're dealing with: IBM, Dec, etc, companies that are very comfortable with >getting others in a tight spot and then making all the money they can from >them. The only alternative solution is a new "standard" library and I don't >think you'll see that unless something develops with Windows NT. There is another solution, spend a few days making your own tools. I did this for my current job, I didn't want to add the Motif license fee to the cost of the product, and didn't like the look of athena's widgets. The salary they paid me for that week has already been paid for several times in saved licensing fees. Don't believe the "don't reinvent the wheel" stuff. If your making a product that you plan to sell or give away many copies of, it generally makes sense to build your own wheel you can use over and over again for free. -- ====== Legalize: >==--< | have given us jacks. . . \ / You are ~1,000,000,000,000,000 .1ms NAND gates have a nice day. . . . \/ The true theory of everything will run on a finite turing machine. . . . ------------------------------ From: ten0772@halcyon.com (Timothy E. Neto) Subject: How I got the atdisk2 patch to work on a GW2000 4DX2-66V. Date: 21 Nov 1993 00:28:41 -0800 Hi all, Well for the longest time I've trying to get the atdisk2 patch to work on my Gateway 2000 4DX2-66V system. It has taken some tweaking and a kernel upgrade, but I have it working now. Well, sort of. I've upgraded my kernel to Linux 0.99pl13, and I used the atdisk2-0.6 patch on the new kernel. The atdisk2-0.6 patch has a diff file for the pl13 kernel. My system's 3 IDE hard drives are: 1: C: /dev/hda MSDOS Western Digital 340M 2: /dev/hdb Ext2 (Linux) Western Digital 340M 3: /dev/hd1a Ext2 (Linux) Conner 80M The Gateway comes with 2 IDE interfaces built into the motherboard. Thus, I didn't have to do any hardware modifications to a IDE interface card. Gateway uses IRQ 14 for drive 1 & 2, and uses IRQ 15 for drives 3 & 4. I tried following the atdisk2 instructions on specifying the HD1_TYPE hard drive specifications, but it didn't work. My boot up always became stuck with the OS reporting a Sync error. So, I played around on getting my hd1.c hd_geninit routine to obtain the drive information from my system's CMOS. I copied the CMOS code from hd.c and did not define a HD1_TYPE in my linux/config.h file. At first I received a bunch of errors and a stuck boot up again. Next I moved the BIOS pointer up 16. (BIOS += 16;) I recompiled and hey, it worked, or so I thought. {P.S. I did try multiples of 16 added to the BIOS pointer, i.e. 16, 32, 48, & 64, but none worked.} Well, it does; it just that I'm getting the BIOS specs on drive 2 for drive 3. When I do a fdisk on /dev/hd1a I get a max of 1010 cylinders. The Conner 80M only has 251 cylinders. Well, I think at least I have access to the drive. Thus I fdisk a partition with 251 cylinders and make a Ext2 file system with 82828 blocks. If anyone knows the correct offset on the Gateway's Phoenix BIOS for the second AT interface, drive 3 & 4, please let me know. If anyone wants a copy of my hd1.c file, E-Mail me a note. Use the Internet address in my sig. Good Luck... -- Indecision is the key | Timothy E. Neto 1 000 to flexibility. | Neat'o Gadget & Widget Works 1 0. .0 You can't E-Mail God. | Unix & X Applications Development 1 0 _ 0 Opinions are all mine. | Seattle, WA ten0772@halcyon.com 1 000 ------------------------------ From: evanson@plains.NoDak.edu (Kelly Evanson) Subject: Linux Kernel Buffer questions... Date: Sun, 21 Nov 1993 10:09:55 GMT I have been using Linux for a while now (using the Slackware distribution currently) and I have a few questions about how the kernel operates. Mainly requarding the use of memory as buffers. The first time I booted Linux I was surprised to see that I only had 450K free memory out of 16MB until I looked and saw that the rest of the memory was being used by kernel buffers. As I require more and more memory, I see that Linux frees up buffers for me. Now regarding this procedure, I have a few questions: #1. If I load up my machine (ie Xwindows+30 Clients+compiles+etc) and I run out of regular memory (ie, > 16MB) and start to swap, is there a minimum amount of memory withheld to use as a buffer or do I completely lose my buffers. Is there a way to configure the minimum amount of free buffers to be allocated? #2. Assuming I kill all the processes from #1 and return to a shell and a few daemons (basically an Idle state) what method is used to return the new free memory to buffer memory? Or do I ever get it back? #3. What are the buffers, buffering? I've used SCO and it lets you individually configure various buffer memory, ie Inodes, Disk blocks, TCPIP buffers, etc. Mainly I curious to how the buffers recover from high to low load transitions and vice-versa. If I turn my machine on an let it run for 3 weeks without a reset, assuming I periodically log-in, run a large number of processes and memory and then log-out until the next day or whenever; 3 weeks down the road, will I still be seeing the same performance level that I did when I initially booted the machine? Kelly Evanson evanson@plains.NoDak.edu ------------------------------ From: hohndel@informatik.uni-wuerzburg.de (Dirk Hohndel) Subject: Re: TAMU X INSTALL Date: 21 Nov 1993 11:50:01 GMT Helmut Geyer (geyer@polyhymnia.iwr.uni-heidelberg.de) wrote: : Here come another myth. Not all Multisync monitors are safe, there are several : reports of frying Multisync monitors. The more intelligent multisyncs do not : turn on the tube until being sure which frequency they are syncing at the moment : and until verifyiong that this frequency is within specs. These monitors can : very easily be fried , too. There have been reports of fried multisyncs, so this : is not only some theoretical blabla. Of course Helmut is 100% right, There are lots of brandname montors that you can fry. early NEC 3D come to mind... (so much about NEC) : :>My multisync happens to be NEC, but I believe other non-NEC multisyncs : :>should be OK (safe)... :-( see above. : There is no such thing as safety if you do not take your pocket calculator : and multifly these Xconfig numbers to see whether they are good for your : monitor. It is not TO hard to multiply two or three numbers and compare : the resulting numbers with the specs of the monitor. So this step must be part : of ANY Xconfig setup. The problem with the Xconfig file this thread is about, is that you cannot use your calculator on the modes therein, as it uses 1 2 3 ... for clock names so that you don't know which clocks really are used. People blindly cycling through the modes risk their monitor and their graphic cards. The fun part is, that tou may find a mode that looks nice and stable, and running this mode for a week will kill your card and your monitor. This is not theoretical bla bla, I can prove that this is true. This means, that even if you want calculate whether you are save, you cannot, and even if you find a stable mode, it may fry your card. People PLEASE stop using this file (and carefully analyze the modes you found using it) : :>Still, next time I eagerly install the latest and greatest Linux : :>(Slackware) I will 1) use my current Xconfig as a go-by and 2) look : :>at /usr/X386/lib/X11/etc/modeDB.txt. That's the way to go. Look at modeDB.txt and use your calculator. Everyone that has a good mode (within the specs !!) for a monitor NOT in modeDB.txt, please send it to me or David Wexelblat so that we can include it in the next release of modeDB.txt. Dirk -- _ _ _ _ _ | Lehrstuhl Informatik I | | | |_) |/ |_| | | |_| |\ | | | |_ | | Universitaet Wuerzburg |_/ | | \ |\ | | |_| | | | \| |_/ |_ |_ | Am Hubland, D-97074 Wuerzburg ------------------------------ From: na2@doc.ic.ac.uk (Nicholas Ambrose) Crossposted-To: comp.os.linux.admin Subject: Re: No core dumped? Date: 21 Nov 1993 13:57:58 -0000 In article <2cgic0$nq4@fbi-news.informatik.uni-dortmund.de>, muenx@heike.informatik.uni-dortmund.de (Holger Muenx) writes: |> |> Guten Tag! |> |> During a major upgrade session on weekend I installed the kernel 0.99.13 and |> libs 4.4.4. Everything seems to work fine, except the fact that programs |> refuse to dump core. |> |> That's good news, you say. |> |> Not really: Those programs are buggy and cause segmentation faults and other |> nasty problems. After a segmentation fault I do not find a "core" or |> "core." file anywhere. Moreoever, in the message "Segmentation |> fault" the usual "core dumped" is omitted. |> |> Does anybody else experience that problem? How can I get rid of it? |> | perhaps it`s possible that you may have 'limit coredumpsize 0' in your .bashrc or similar file ? Nick -- In the long run, every program becomes rococo, and then rubble. -- Alan Perlis ------------------------------ ** 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-Development-Request@NEWS-DIGESTS.MIT.EDU You can send mail to the entire list (and comp.os.linux.development) via: Internet: Linux-Development@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-Development Digest ******************************