From: Digestifier To: Linux-Development@senator-bedfellow.mit.edu Reply-To: Linux-Development@senator-bedfellow.mit.edu Date: Tue, 30 Nov 93 01:13:19 EST Subject: Linux-Development Digest #273 Linux-Development Digest #273, Volume #1 Tue, 30 Nov 93 01:13:19 EST Contents: Re: Free Software and Motif (was: Re: Don't use Motif for free sw: ...) (Tom LaStrange) Re: [Q] .13s and AT1500 Ethernet cards (Jason Cash) Re: 0.99.14 (was Re: Found slow socket bug :)) (Richard Krehbiel) Re: Free Software and Motif (was: Re: Don't use Motif for free sw: ...) (Warner Losh) Re: Don't use Motif for free sw: it now requires runtime royalties! (Peter D. Bartok) Re: Don't use Motif for free sw: it now requires runtime royalties! (Frank Peters) Re: 0.99.14 (was Re: Found slow socket bug :)) (Matthew Donadio) Re: Comments from the "TAMU Crap" author (H. Peter Anvin N9ITP) Re: 0.99.14 (was Re: Found slow socket bug :)) (Curtis Yarvin) Makefile Bug In 0.99.14 Kernel (Christopher Shaulis) Re: 0.99.14 (was Re: Found slow socket bug :)) (H. Peter Anvin N9ITP) Re: Don't use Motif for free sw: it now requires runtime royalties! (Marc VanHeyningen) Re: Don't use Motif for free sw: it now requires runtime royalties! (Jack D. Unrue) Mitsumi FX-001D & Yggdrasil GX (Paul W Filsinger) Re: Makefile Bug In 0.99.14 Kernel (David Barr) Re: AHA274x SCSI driver for linux (Drew Eckhardt) Re: Creeping featuritis (post --rant --flame) (D. J. Bernstein) ---------------------------------------------------------------------------- From: toml@pure.LaStrange.COM (Tom LaStrange) Crossposted-To: comp.infosystems.www,comp.windows.x,comp.windows.x.i386unix Subject: Re: Free Software and Motif (was: Re: Don't use Motif for free sw: ...) Date: 29 Nov 1993 23:44:24 GMT Reply-To: toml@LaStrange.COM In article , rhealey@sirius.aggregate.com (Rob Healey) writes: |> In article , |> Mike Hopkirk wrote: |> >p> It is very disturbing for one major reason: the conditions for Motif |> >p> licensing require a lawyer or an expert system to figure. |> > |> >Which I presume is why Darrel did the human readable version ... |> > |> But human readable forms are almost always legally inaccurate. |> |> >This seems *fair* to everyone ( OSF and users and developers ). |> >If you dislike it you can always not distribute any licensable |> >OSF code with your app. |> > |> Ahhh, but here is the rub. OSF now has a MONOPOLY on THE GUI for |> UNIX based systems. There is no other alternative now that |> OpenLook has been defeated. If you want to sell a product in |> to the UNIX(tm) market you MUST use OSF Motif L&F, you have NO ^^^ |> other choice. Historically MONOPOLYS are usually bad news for |> everyone except the MONOPOLY itself. This is the real issue here. |> |> Until there is another source for the L&F which the industry has ^^^ |> deemed necessary for UNIX products you are stuck in the traditional |> proprietary trap. Not surprising since the founders of OSF were |> masters of proprietary entrapment of end users... B^(. |> |> Hopefully a Free implementation of the L&F will come out in the ^^^ |> near future to provide a "balance of terror" so to speak against |> OSF's wild and wacky licensing. There are alternatives to OSF/Motif to get the Motif L&F. How about tcl/tk (free) OI (free on Linux) Galaxy Now all these may not implement all the features (or the bugs) of OSF/Motif so your mileage may vary as to whether or not they're useful. The point being is that the L&F is independent of the OSF/Motif code. -- Tom LaStrange toml@LaStrange.COM ------------------------------ From: cash@stimpy.eecis.udel.edu (Jason Cash) Subject: Re: [Q] .13s and AT1500 Ethernet cards Date: 30 Nov 1993 00:28:54 GMT In article <1993Nov253@super.org> becker@super.org (Donald J. Becker) writes: >In article <2cune3$dqf@louie.udel.edu>, >Jason Cash wrote: [lockup problem des. deleted] >Yes, this is a bug I introduced in pl13s. It should affect only the new >">16M" LANCE driver -- the other drivers are started after time_init() in >main.c as they used to be. The autoIRQ code assumes that "jiffies" are >ticking, and goes into an infinite loop when they are not. > >A work-around is to explicitly specify the LANCE IRQ so that the autoIRQ code >isn't run. You can do that with a boot time parameter -- see the ethernet >HowTo for details. Thanks for the quick reply and fix, this works great. For those who haven't been paying attention to the ether-net how-to (I'm guilty), it has changed 100% from the August version. > >A source code fix is to use my new autoIRQ code on >ftp.super.org:/pub/linux/pl14/auto_irq.c >which changes a '>=' to a '>' so that zero timeouts don't depend on jiffies. >(This change in my private version is why I didn't notice the problem.) Sadly, this change does not seem to fix the problem. I have tried this in conjunction with 3 different machines (all using at1500) on each patch level from 13s -> 14. The lockup still occurs. Since there is the workaround, and 13r runs very well if you don't want manually set the IRQ, this is not a big problem. Perhaps 14a will incorporate the functional auto_irq.c ? > >The right fix is for me to actually write my planned autoIRQ code, which >reads the 8259 IRR and timer directly instead of installing interrupt handlers >and spinning on 'jiffies'. > >Donald Becker becker@super.org Jason Cash cash@udel.edu ------------------------------ From: richk@netcom6.netcom.com (Richard Krehbiel) Subject: Re: 0.99.14 (was Re: Found slow socket bug :)) Date: Tue, 30 Nov 1993 00:37:18 GMT In article <2dcnhn$84r@klaava.Helsinki.FI> torvalds@klaava.Helsinki.FI (Linus Torvalds) writes: > Linux 0.99 patchlevel 14 is available on nic.funet.fi in the usual place I have a modest question. What is it that's preventing any of these Linux releases from being version 1.0? Is there a particular ideal that isn't yet realized, a particular the feature set that has not yet been met? Or is it just that the idea of releasing the big ONE-DOT-OH is frightening? -- Richard Krehbiel richk@netcom.com Picture a clever one-liner here... ------------------------------ Crossposted-To: comp.infosystems.www,comp.windows.x,comp.windows.x.i386unix From: imp@boulder.parcplace.com (Warner Losh) Subject: Re: Free Software and Motif (was: Re: Don't use Motif for free sw: ...) Date: Tue, 30 Nov 1993 00:18:52 GMT In article rhealey@sirius.aggregate.com (Rob Healey) writes: > Ahhh, but here is the rub. OSF now has a MONOPOLY on THE GUI for > UNIX based systems. There is no other alternative now that > OpenLook has been defeated. If you want to sell a product in > to the UNIX(tm) market you MUST use OSF Motif L&F, you have NO > other choice. Historically MONOPOLYS are usually bad news for > everyone except the MONOPOLY itself. This is the real issue here. Ah, the OSF doesn't have a monopoly on the look and feel. The OI toolkit has had it for years (and there are no runtimes). OI, for those who don't know, is a C++ X toolkit that implements both OPEN LOOK and Motif and is available on a wide range of platforms. To be fair to the competion, there are other toolkits as well that have a Motif look and feel as well. OSF's Xm isn't the only game in town. Warner -- Warner Losh imp@boulder.parcplace.COM ParcPlace Boulder I've almost finished my brute force solution to subtlety. ------------------------------ Crossposted-To: comp.infosystems.www,comp.windows.x,comp.windows.x.i386unix,comp.windows.x.motif,gnu.misc.discuss,comp.sources.d From: root@devnull.novell.de (Peter D. Bartok) Subject: Re: Don't use Motif for free sw: it now requires runtime royalties! Date: Tue, 30 Nov 1993 01:36:33 GMT strat@tonto.ksu.ksu.edu (Steve Davis) writes: >Charles Henrich (henrich@rs560.cl.msu.edu) writes: >:I applaud the efforts of Eric Bina and Marc Andreeson in producing Mosaic for >:X, if I had been charged with the same task, I certainly would have chosen >:Motif as well. >Agreed. I would be willing to buy Mosaic if I had to - I don't think Mosaic would be Mosaic if it had been written with Athena or whatever. Peter D. Bartok pbartok@c3p0.Novell.DE -- Peter Dennis Bartok "I wish I knew what I'm doin' here all day!" Unix Systems Support Novell Ease Administrator Novell European Support Center pbartok@c3p0.Novell.DE D-40549 Duesseldorf Fax: +49 211 5277 772 ------------------------------ From: Frank.Peters@MsState.Edu (Frank Peters) Crossposted-To: comp.infosystems.www,comp.windows.x,comp.windows.x.i386unix,comp.windows.x.motif,gnu.misc.discuss,comp.sources.d Subject: Re: Don't use Motif for free sw: it now requires runtime royalties! Date: 29 Nov 1993 19:43:36 -0600 Reply-To: fwp@CC.MsState.Edu In article gjunker@ddt.eng.uc.edu (Gregory Junker) says: > >No (and you have most-likely already been through this), don't use Motif for >anything...It's > > - Ugly Subjective. I happen to agree with you but its still subjective. > - Slow I doubt it. You may have a slow X server or slow hardware or a slow Motif application (or a slow Motif window manager, which is just another application). I've seen and heard nothing to suggest that the Motif toolkit inherently makes your applications slow. > - Difficult (read impossible) to program I can't really argue this since I've never tried to write a Motif program. But the various applications out there seem to argue against this. > - Licensed That's certainly a drawback...but its a drawback for a lot of things. Are you suggesting people shouldn't write applications fro UNIX since its licensed for example? It would be nice if the technology were free. That isn't an absolute necessity in my opinion...especially as its cost becomes bundled in with the cost of most commercial OS offerings. >Why > - Does there need to be a workstation interface "standard" ? Because users want it. They hate having to learn an army of different applications, each with a different convention for mouse behavior and so on. The Mac didn't get popular because of its speed or (at least initially) the wide variety of applications. It got popular because once you learned to use one application (including the finder) you had stored up a wealth of knowledge about how other applications would behave. Consistency, more than any other factor, made the Macintosh. > - Does it need to be Motif (as it seems to be by default) It doesn't "need" to be Motif. Their only serious competitor, though, was Sun with Open Look and they have, for better or worse, conceded defeat. And Motif support is specified in some significant percent (don't have the numbers to hand) of bid specifications for new systems and software...in other words, purchasers have been asking for it for whatever reason. >Just waiting for GNU to come out with an interface spec... :-) A couple of years ago it might have been possible for FSF (the GNU people) or some other body to come up with a specification and implementation and gained some significant support. By now it is probably too late though it may be worth a shot. ------------------------------ From: donadio@mxd120.rh.psu.edu (Matthew Donadio) Subject: Re: 0.99.14 (was Re: Found slow socket bug :)) Date: 30 Nov 1993 01:17:54 GMT Richard Krehbiel (richk@netcom6.netcom.com) wrote: : I have a modest question. What is it that's preventing any of these : Linux releases from being version 1.0? Is there a particular ideal Not again... -- Beaker aka Matt Donadio | Life is short, --- __ o __~o __ o donadio@mxd120.rh.psu.edu | ride like ---- _`\<, _`\<, _`\<, --- Penn State Cycling ---| the wind. --- ( )/( ) ( )/( ) ( )/( ) ------------------------------ From: hpa@ahab.eecs.nwu.edu (H. Peter Anvin N9ITP) Subject: Re: Comments from the "TAMU Crap" author Reply-To: hpa@nwu.edu (H. Peter Anvin) Date: Tue, 30 Nov 1993 01:46:26 GMT In article <1993Nov29.223559.5060@kf8nh.wariat.org> of comp.os.linux.development, bsa@kf8nh.wariat.org (Brandon S. Allbery) writes: > > I can confirm that; my mother bought a PS/1, and I was horrified by the lack > of specifications. I have no idea whatsoever how to configure her monitor. > I think one way of approaching the problem might be the way OS/2 goes about it. When you install and configure OS/2, it opens a (full-screen, of course) DOS/real mode session, in which it calls the BIOS to set the modes (which most, if not all BIOSes let you do) and then reads the timings directly off the video board. Such a probing program should be a lot safer since it gets the video timings from BIOS, and the BIOS video timings are usually safe (although maybe not optimal, but it's better than nothing). Such a probing program may or may not be practical to implement in a Linux VM86 session; if not it could always be constructed as a self-bootable floppy (just so we don't require DOS!). A floppy could store the timing data on the floppy itself from which a program could restore it and convert to an Xconfig file. A program that spawns a VM86 task probably could get the data via some form of IPC. /hpa -- INTERNET: hpa@nwu.edu FINGER/TALK: hpa@ahab.eecs.nwu.edu IBM MAIL: I0050052 at IBMMAIL NeXTMAIL: hpa@speedy.acns.nwu.edu FIDONET: 1:115/511 or 1:115/989.4 HAM RADIO: N9ITP or SM4TKN Linux system administrator (3 systems on the net, one off) ------------------------------ From: curtis@snake.CS.Berkeley.EDU (Curtis Yarvin) Subject: Re: 0.99.14 (was Re: Found slow socket bug :)) Date: 29 Nov 1993 18:05:10 -0800 In article , H. Peter Anvin N9ITP wrote: > >We are currently waiting for the networking code to stabilize. Fred >and Alan are doing intense development on the network code, but many >crucial features are still only available in rather unreliable form. >We are getting close, to be sure, but once the network code is good I >think everyone will agree it is time for 1.0. And BREAK SELECT AGAIN! It's silly to have a system with everything broken perfectly to Posix spec, except for select(). The way to handle this is in the C library - leave the old select entry in the shared libraries so as not to break binaries, leave the old system call as linux_select(), and for new compiles alias select() to a library routine that provides the Posix behavior by calling linux_select(). This may seem like trivial nitpicking, but Linux is good enough that this is now a serious problem, and the longer we wait to fix it the worse it will get. c ------------------------------ From: cjs@netcom.com (Christopher Shaulis) Subject: Makefile Bug In 0.99.14 Kernel Date: Tue, 30 Nov 1993 01:42:52 GMT I believe that there is a bug in the new 0.99.14 kernel's makefile. Apparently the symbol KERNELHDRS is defined but never used, so none of the sub-makefiles (and thus the programs spawned from them) have any earthly idea where to look for the include files. The quickest solution to the problem seems to be appending "-I /usr/src/linux/include" to line 77 of the main make file. That is the line which defines the symbol CC. Hope this helps someone, Christopher cjs@netcom.com ------------------------------ From: hpa@ahab.eecs.nwu.edu (H. Peter Anvin N9ITP) Subject: Re: 0.99.14 (was Re: Found slow socket bug :)) Date: 30 Nov 93 01:35:01 GMT Reply-To: hpa@nwu.edu (H. Peter Anvin) In article of comp.os.linux.development, richk@netcom6.netcom.com (Richard Krehbiel) writes: > > I have a modest question. What is it that's preventing any of these > Linux releases from being version 1.0? Is there a particular ideal > that isn't yet realized, a particular the feature set that has not yet > been met? Or is it just that the idea of releasing the big ONE-DOT-OH > is frightening? > We are currently waiting for the networking code to stabilize. Fred and Alan are doing intense development on the network code, but many crucial features are still only available in rather unreliable form. We are getting close, to be sure, but once the network code is good I think everyone will agree it is time for 1.0. Part of the reason is that 1.0 marks the point where we are telling everyone that Linux is ready for public consumption, not just if you are willing to tinker with it. If you *are* willing to tinker with it, the version number shouldn't matter. Probably a lot of people will look at Linux 1.0 and make a judgement (pro or con) for Linux once and for all, and we'd like it to be pro. As for me, I am a happy tinkerer who manage three networked Linux systems, two of them NFS-linked together, and one SLIP only system. I am *very* happy with it. /hpa -- INTERNET: hpa@nwu.edu FINGER/TALK: hpa@ahab.eecs.nwu.edu IBM MAIL: I0050052 at IBMMAIL NeXTMAIL: hpa@speedy.acns.nwu.edu FIDONET: 1:115/511 or 1:115/989.4 HAM RADIO: N9ITP or SM4TKN Linux system administrator (3 systems on the net, one off) ------------------------------ Crossposted-To: comp.infosystems.www,comp.sources.d,comp.windows.x,comp.windows.x.i386unix,comp.windows.x.motif,gnu.misc.discuss From: Marc VanHeyningen Subject: Re: Don't use Motif for free sw: it now requires runtime royalties! Date: Mon, 29 Nov 1993 22:27:23 -0500 Thus said mib@geech.gnu.ai.mit.edu (Michael I Bushnell): >In article <2ddjqv$bb1@vanbc.wimsey.com> markh@vanbc.wimsey.com (Mark C. Henderson) writes: > Consider that one probably won't be able to use the GNU libraries for > projects that are politically incorrect according to the FSF standard > of political correctness. > >For libraries which are released under the LGPL (into which category >GMP does not fall), these concerns utterly vanish. True; however, as you point out, many libraries are not released under LGPL. I thought the LGPL experiment was not considered successful, and FSF was not planning to license anything else under it. > In some ways, libraries which cost $$$ are cheaper. One might even > argue that they give one more freedom. > >They give you more freedom in just the same way a weapon can give you >more freedom to steal from your neighbors. I don't follow this at all. Mark is merely saying that vendors are generally in business to make money and therefore are happy as long as they get some. The FSF, on the other hand, is in "business" to promote its ideology of how software should be, and you can't just pay for the rights you want. Which of these is more restriaining is a topic I would not like to see debated, but it's pretty clear that each has its restrictions and its benefits, none of which have anything to do with armed robbery. -- Marc VanHeyningen mvanheyn@cs.indiana.edu MIME, RIPEM & HTTP spoken here ------------------------------ Crossposted-To: comp.windows.x.motif From: junrue@nyx10.cs.du.edu (Jack D. Unrue) Subject: Re: Don't use Motif for free sw: it now requires runtime royalties! Date: Tue, 30 Nov 93 04:21:07 GMT In article <2de8g8$cqi@jester.cc.msstate.edu>, Frank Peters wrote: >In article > gjunker@ddt.eng.uc.edu (Gregory Junker) says: >> >> - Slow > >I doubt it. You may have a slow X server or slow hardware or a slow >Motif application (or a slow Motif window manager, which is just another >application). I've seen and heard nothing to suggest that the Motif >toolkit inherently makes your applications slow. > UIL is inherently slow. Or at least, it slows an application down. The next time you detect a "slow" Motif app, check to see if there's a .uid file that goes with it. Some folks choose not to use UIL... -- Jack ------------------------------ From: pfilsing@herman.cs.uoguelph.ca (Paul W Filsinger) Subject: Mitsumi FX-001D & Yggdrasil GX Date: 30 Nov 1993 04:25:52 GMT Nope, this isn't the announcement of a driver for it, just some information that might help someone make one. I can say for SURE that it won't be hard to patch Linux for this drive. Here's why. The drive works FINE with my Yggdrasil LGX Beta release (Spring '93 i *think*). I was somewhat surprised to discover this after having the drive fail to work with the Yggdrasil F93 LGX release. I discovered this by accident (stuck my old beta boot disk in by mistake). I don't have the technical knowledge to fix the driver myself, or I would. I hope this helps someone else do it. Note: The FX-001D is an AWESOME drive. Real fast and dirt cheap. ------------------------------ From: barr@pop.psu.edu (David Barr) Subject: Re: Makefile Bug In 0.99.14 Kernel Date: 30 Nov 1993 04:33:28 GMT In article , Christopher Shaulis wrote: >I believe that there is a bug in the new 0.99.14 kernel's makefile. >Apparently the symbol KERNELHDRS is defined but never used, so none >of the sub-makefiles (and thus the programs spawned from them) have >any earthly idea where to look for the include files. The quickest >solution to the problem seems to be appending "-I /usr/src/linux/include" >to line 77 of the main make file. That is the line which defines >the symbol CC. A better solution is to simply add the required symlinks in /usr/include/{asm,linux} to /usr/src/linux/include, as documented in the README. --Dave -- lose: v. to miss from one's possession. loose: adj. not securely fastened. v. to set free. ------------------------------ From: drew@kinglear.cs.colorado.edu (Drew Eckhardt) Subject: Re: AHA274x SCSI driver for linux Date: Tue, 30 Nov 1993 04:45:09 GMT In article , wrote: >Does anyone know of any scsi driver for adaptec aha274x written for linux??? Some one is writing a driver, although it's not even in pre-alpha yet. If you're interested in ALPHA testing, your best bet is going to be joining the SCSI channel of the mailing list and waiting patiently for an anouncement. ------------------------------ From: djb@silverton.berkeley.edu (D. J. Bernstein) Crossposted-To: gnu.misc.discuss Subject: Re: Creeping featuritis (post --rant --flame) Date: 30 Nov 93 04:06:06 GMT In article <1993Nov25.024226.19108@kf8nh.wariat.org> bsa@kf8nh.wariat.org (Brandon S. Allbery) writes: > ("yes" > is from V7; I'm still waiting for some helpful idiot to invent "yes -n" to > number "yes"'s output!) Ach, don't do that: I've already set up ``yes -n 50'' to mean ``print 50 lines of y's.'' [smile] ---Dan ------------------------------ ** 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 ******************************