From: Digestifier To: Linux-Development@senator-bedfellow.mit.edu Reply-To: Linux-Development@senator-bedfellow.mit.edu Date: Mon, 22 Nov 93 06:13:06 EST Subject: Linux-Development Digest #247 Linux-Development Digest #247, Volume #1 Mon, 22 Nov 93 06:13:06 EST Contents: crc error during install (JIANFANG LI) WANTED: xBASE Compiler or Interpreter for Linux (Robert Broughton) Re: WANTED: COBOL compiler (Charles T Wilson -- Personal Account) no SIGHUP on process termination? (Gero Kuhlmann) Re: rawrite.exe is too slow (Ng Pheng Siong) Re: Some ideas and reasons for a more modular kernel. (Ed H. Chi) Re: STRLEN() == 3 ??!?? (Ove Kalkan) Some Benchmarks on different machines:: (Klaus ZLOEBL) Re: Some ideas and reasons for a more modular kernel. (Urban Koistinen) Linux and io piping (Brian Roy) Re: Don't use Motif for free sw: it now requires runtime royalties! (pfox@Ingres.COM) Re: Inherited File System only on SLS? (Dominik Kubla) Re: TAMU X INSTALL (Dirk Hohndel) Re: Some ideas and reasons for a more modular kernel. (Andrew Martin) Re: Don't use Motif for free sw: it now requires runtime royalties! (Marc Andreessen) ---------------------------------------------------------------------------- From: jli@mtu.edu (JIANFANG LI) Subject: crc error during install Date: 21 Nov 1993 20:27:31 -0500 I am trying to install 0.99.13 version of SLS linux and found out following problem. I tried almost a hundred times of my installation, but the install program kept giving me "crc error" from gzip, or tar: "skipping to next file header. stdin: invalide compressed data-- crc error". This error happens in different files each time, even through I used same disk for installation.(i.e: my installation file on a2-a4 are the same during different installation.) I suspect it's communication chanel noise corrupt the file. But I tried to download them from different sites, at different time. Also, I tested them out under my SUN os account, before I downloaded them to my PC. The files turned out OK in my SUN os account, and I could use gzip and untar to uncompress file without problem under DOS without any problem. However, it turned out the other way when you use "doinstall" under linux(I booted linux using a1). I would appreciate if any kind soul can give me a suggestion of what the problem is. --eve p.s. It's not hardware problem either, because I once successfully installed the minimum and it works for two days. ------------------------------ From: Robert_Broughton@mindlink.bc.ca (Robert Broughton) Subject: WANTED: xBASE Compiler or Interpreter for Linux Date: 22 Nov 93 01:33:08 GMT The subject says it all. I know that dbMAN has been ported to several unixes, and I recall reading that Quicksilver, an excellent product, was ported to at least one unix. -- *-*-*-*-*-*-*-*-*-*-* Robert Broughton Robert_Broughton@mindlink.bc.ca "We calm and reassure. We embrace people with the message that we're all in it together. That our leaders are infallible and that there is nothing, absolutely nothing wrong." - Miles Drentell, _thirtysomething_ ------------------------------ From: ctwilson@rock.concert.net (Charles T Wilson -- Personal Account) Crossposted-To: comp.os.linux.help Subject: Re: WANTED: COBOL compiler Date: 22 Nov 1993 03:42:05 GMT In article <2cl4cb$pof@crl.crl.com>, Mark A. Horton wrote: > >Fascinating... a thread on COBOL with no mention of COBOL itself! This must >be some hitherto unbeknownst to me usage of the term "COBOL!" Perhaps a >change of the name of this thread would be in order? Just curious. Well, perhaps...I personally agree with Dijkstra about it, and probably shouldn't even allow the subject line to mention it :-) -- /-----------------------------------------------------------------------\ | Tom Wilson | "I can't complain, but sometimes | | ctwilson@rock.concert.net | I still do." | | | -Joe Walsh | ------------------------------ From: gero@gkminix.han.de (Gero Kuhlmann) Subject: no SIGHUP on process termination? Date: Sun, 21 Nov 93 18:22:40 GMT Hello, today I found out, that obviously the kernel doesn't send a SIGHUP to all processes in a session group, as it should do. The actual problem was that a serial port wasn't closed after leaving a login bash with a running background job. The background processes, which didn't terminate due to the missing SIGHUP, kept the stdin/out from getting closed by sys_exit(). That meant that uugetty wasn't able to open the port again, and thus that port seemed to be dead for dialins. I tracked the problem down to kernel/exit.c, which reads: /* * This loop does two things: * * A. Make init inherit all the child processes * B. Check to see if any process groups have become orphaned * as a result of our exiting, and if they have any stopped * jobs, send them a SIGHUP and then a SIGCONT. (POSIX 3.2.2.2) */ while ((p = current->p_cptr) != NULL) { [...] if ((p->pgrp != current->pgrp) && (p->session == current->session) && is_orphaned_pgrp(p->pgrp) && has_stopped_jobs(p->pgrp)) { kill_pg(p->pgrp,SIGHUP,1); kill_pg(p->pgrp,SIGCONT,1); } } Why is it that SIGHUP gets only sent to stopped jobs? What happens if I remove this line (e.g. the call to has_stopped_jobs)? Does anybody know of a solution to the problem? gero. -- A verbal contract isn't worth the paper it's written on. - S. Goldwyn -- Gero Kuhlmann, Hannover 0511/6043245 (Voice) gero@gkminix.han.de ------------------------------ From: ngps@nova.np.ac.sg (Ng Pheng Siong) Subject: Re: rawrite.exe is too slow Date: 22 Nov 1993 13:53:12 +0800 In article , Orest Zborowski wrote: >One of the reasons rawrite is slow is that it only writes 3 sectors at a time, I use rawrite under OS/2 2.1, and it is much faster than whe run under Dos. - PS -- Ng Pheng Siong * ngps@np.ac.sg * npngps@solomon.technet.sg Computer Centre, Ngee Ann Polytechnic, Singapore ------------------------------ From: ehhchi@maroon.tc.umn.edu (Ed H. Chi) Subject: Re: Some ideas and reasons for a more modular kernel. Date: Mon, 22 Nov 1993 06:33:31 GMT In article , Zeyd M. Ben-Halim wrote: >BUT 'modules' is a set of patches to 0.99.10 and will not fit in newer >kernels. What it needs is an automated way of generating a kernel symbol >map. I was hoping Linus will get around to incorporating into the kernel >proper or providing an alternative. > >A loadable-driver feature will make development of drivers much easier. >No need to compile and link the entire kernel. You load and unload drivers >at run-time. Yes... yes. This loadable driver thing has been talked about before, and people just said, "there is this module thing on the QIC-80 directory." There has been no move of it into the standard kernel distribution. So, how about it, Linus? This could make a lot of device drivers happy. -- o/ \ / \ / / \o email: ehhchi@epx.cis.umn.edu /# ##o # o## #\ chi@mermaid.micro.umn.edu / \ / \ /o\ / |\ / \ Dumping messy-dos, running Linux! ------------------------------ From: kalkan@ramz.ing.tu-bs.de (Ove Kalkan) Subject: Re: STRLEN() == 3 ??!?? Date: Mon, 22 Nov 1993 06:50:23 GMT In article <1993Nov17.114140.4064@Informatik.TU-Muenchen.DE>, wiserner@Informatik.TU-Muenchen.DE (Bernd Wiserner) writes: |> Your environment SHOULD coredump. Not neccesarily. Normaly reading wrong memory segments doesn't cause coredumps while writing often but not always does. |> It should in no case return 3. In generell NULL is nothing else than a number, so why won't you try to find a string there? In this case *NULL+3 seems to be '\0' Bye, Ove. -- =================================================================== Product: Request or statement (see above) Warranty: Normaly less than half'n hour, but sometimes longer Reason: My opinion changes very quick cause it depends on creative processes of thinking and not on doctrins like common politicians do. Ove Kalkan (kalkan@ramz.ing.tu-bs.de) Below this line I could write a sentence of A.Lincoln, but he's allready fallen to dust and it would be unfair cause he wouldn't be able to correct his words. =================================================================== ------------------------------ From: zloebl@piis10.joanneum.ac.at (Klaus ZLOEBL) Subject: Some Benchmarks on different machines:: Date: 22 Nov 1993 08:28:44 GMT Hi, for all interested: calculation part written in fortran, for PC (both with linux) we used f2c and gcc (2.4.5) -O6 for VAX (under VMS) VAX fortran PC 386DX40 128k Cache 8Mb 500s PC 486DX50 128k Cache 8Mb 144s DEC VAXstation 3100 8Mb 709s DEC VAX 6000 128Mb 132s (not optimized) DEC 3000 AXP 96Mb 15s -- Klaus Zloebl | E-Mail: zloebl@piis10.joanneum.ac.at Joanneum Research | PSI : PSI%2631102911::ZLOEBL Steyrergasse 17 | A-8020 Graz | Phone: ++43/316/8020/243 AUSTRIA | ------------------------------ From: md85-epi@hemul.nada.kth.se (Urban Koistinen) Subject: Re: Some ideas and reasons for a more modular kernel. Date: Mon, 22 Nov 1993 08:53:00 GMT In johnsonm@calypso.oit.unc.edu (Michael K. Johnson) writes: >I don't want to denigrate your ideas about compressed blocks, but I >would like to point out that device drivers as user processes isn't >the only way to do it. Your compressed block device could also be >provided within the kernel proper as a part of the Logical Disk >Manager that I intend to work on. This is a layer implemented as a >special (no pun intended) block device that can be insterted between >the buffer cache and other block devices, and into which almost any >modular mapping of blocks to blocks, including compression, could be >fit. Will it be done this month? Another use would be encryption. Encrypted swap anyone? >I still think that a compressed filesystem is better for compressed >disk access, because I don't think that inode and other metadata >should be compressed... While I think this is good for a RW file system, inode and other metadata could be stored compressed on a read-only file system. -- Urban Koistinen - md85-epi@nada.kth.se Stop software patents, interface copyrights: contact lpf@uunet.uu.net ------------------------------ From: broy@cs.umr.edu (Brian Roy) Subject: Linux and io piping Date: Mon, 22 Nov 1993 07:39:07 GMT Good morning. I am something of a newcomer to the *nix world, and I hope someone can help shed some light on how the operating system handles this sort of thing. To take a hypothetical case, we have two commands, and we want the output of one process to be used as input to another, so we invoke them like so: cmda | cmdb and that should sort of hook stdout for cmda to stdin for cmdb, if I understand this at all. What happens if cmda is generating output much faster than cmdb is consuming it? Is there an upper limit to the amount of data linux will buffer? How is this determined? Can it be changed? One of the projects I am now involved with has the strong probability of creating a great deal of data and doing so much faster than the second process can hope to cope with it. Can anyone point me in the right direction to substantiate system behaviour under these conditions? I would hate to have it all come screeching to a halt after months of work... If you don't want to consume the extra bandwidth in the news, replies would be most welcome at broy@umrgec.eec.umr.edu. Thanks for reading my plea! Brian A. Roy Dir. Software Implementation HEURIS Logic ------------------------------ Crossposted-To: comp.windows.x From: pfox@Ingres.COM Subject: Re: Don't use Motif for free sw: it now requires runtime royalties! Date: 22 Nov 93 09:22:37 GMT Subject: Re: Dont't use Motif for free sw: it now requires runtime royalties! Hi guys. Thought I would chuck in and add my sentiments to this whole affair. I am the author of the editor CRISP and have been following this Motif license issue with absolute and total disgust. It seems to me the OSF has held to ransom the whole of the computing community in a manner as distasteful as Microsoft with there 'DOS/Windows' royalties on PCs sold. The OSF has seriously disadvantaged small and PD software developers to the extent that OSF & Motif are to be treated as the Nazi's of the computing community - i.e. you get shot in the head if you are not a member, dont have the right amount of $$$'s, dont have that 'Aryan' look about you. I am willing to be totally flamed for this, but the evidence I see presented by OSF employees shows this: As a software manaufacturer you must ensure that sites you are selling software to are either Motif licensed or you pay a license on behalf of the customer. Static/dynmic linking do not come into it. This is total pig shit. As a pretty experienced X11 programmer having developed CRISP to run using Athena, Motif, XView, Windows/3 and OLIT, I am therefore proposing to either offer my services to implement a PD Motif library from scratch or help in the implementation of one if a group is already getting the ball rolling. Jeeze, next we'll have Microslush copyrighting the ADD instruction and we'll all be figuring out how to write programs without subroutines. Is this the 20th century or am I just dreaming. All email contacts to: Paul Fox fox@crisp.demon.co.uk ---- Paul Fox ------------------------------ From: kubla@wilbur.zdv.Uni-Mainz.DE (Dominik Kubla) Subject: Re: Inherited File System only on SLS? Date: 22 Nov 1993 09:21:37 GMT Roland Kwee (rkwee@ursula.ee.pdx.edu) wrote: : I noticed on the SLS FAQ the Inherited File System feature, allowing : to modify files on a (read-only) CD with the help of the hard disk. : On the Yggdrasil docs it is never mentioned. It even uses lots of : symbolic links, which I find hard to puzzle out. : Is this feature only on SLS? Wouldn't it be nice to have it standard in : Linux? Can I add this feature to regular Linux versions? : --Roland Kwee RolandKwee@ACM.org No. It was introduced by W. Almesberger and you should be able to find its sources in any ALPHA directory (at least you should be able to find it at tsx-11). But as far as i know, Werner has not updated the patches for the recent kernel releases, so a patch might stall. -- Cheers, Dominik +---------------------------------------------------------------------------+ | eMail: kubla@goofy.zdv.Uni-Mainz.DE | | sMail: Dominik Kubla, Steinsberg 34, 56355 Nast"atten, F. R. Germany | +---------------------------------------------------------------------------+ | | | "Linux: The choice of a GNU generation" --S. Frampton | | | +---------------------------------------------------------------------------+ DISCLAIMER: Everything written above are the expressed thoughts of the author and in no way connected to 'Johannes Gutenberg Universit"at', Mainz (Germany). This way, they do not have to care about what I say ... ------------------------------ From: hohndel@informatik.uni-wuerzburg.de (Dirk Hohndel) Subject: Re: TAMU X INSTALL Date: 22 Nov 1993 09:55:39 GMT Patrick J. Volkerding (volkerdi@mhd1.moorhead.msus.edu) wrote: : In article <2cnkl9$3il@winx03.informatik.uni-wuerzburg.de> hohndel@informatik.uni-wuerzburg.de (Dirk Hohndel) writes: : > : >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. : It's not like you *couldn't* know the clocks you're using if you wanted to. : If you look at the order in which the clocks are detected by the server, : these are the same clocks that get numbered, 1, 2, 3, etc. Now, if you go : down below and cut out modes on the Modes line that use clocks that you : feel are too high, how unsafe could cycling through really be? Err... and this is `easy' and improves the setup process for the beginner ? This means he not only has to fiddle around with calculating, he additionally has to find out the clocks he is using... C'mon... : >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. : I asked the net whether anyone knew of a real case where this had happened. : Until we hear of one, it is "theoretical", don't you think? Right now I : have zero reports of problems. (and counting :^) Well. We have at least four reports of people ruining their cards with stable looking modes. I cannot say whether any of these used Xconfig.1M So it is not `thoretical' at all. Anyway, I think that trying to ridicule a risk the developers of software point out, isn't a GoodThing... : If you use it, it's entirely at you own risk. However, until I hear real : reports of damage resulting from THIS file (and not from overclocking : while testing an alpha XFree version WITHOUT this file) I'll continue to : consider the dangers of this system to be highly overrated. And I'll continue to call this wrong. : I mean really, this is just about the only thing I haven't gotten a bug : report on. It's been included in TAMU since XFree86 1.1, and in : Slackware since June. If it was really frying monitors all over the planet, : don't you think we would have heard by now? My problem with this is that it has potential danger. You wouldn't include a bomb with your CD, write on it `don't touch' and only because you haven't heard of someone killed call this `save', would you ? (before you flame me on that one, I know it sucks, but you get the picture...) Dirk -- _ _ _ _ _ | Lehrstuhl Informatik I | | | |_) |/ |_| | | |_| |\ | | | |_ | | Universitaet Wuerzburg |_/ | | \ |\ | | |_| | | | \| |_/ |_ |_ | Am Hubland, D-97074 Wuerzburg ------------------------------ From: dok423@cvx12.inet.dkfz-heidelberg.de (Andrew Martin) Subject: Re: Some ideas and reasons for a more modular kernel. Reply-To: dok423@cvx12.UUCP (Andrew Martin) Date: Mon, 22 Nov 93 10:33:57 GMT In article <1993Nov19.183129.333@ulk.rmt.sub.de> uli@ulk.rmt.sub.de (Ulrich Karl) writes: >dok423@cvx12.inet.dkfz-heidelberg.de (Andrew Martin) writes: > >>This all sounds suspiciously like the way the AmigaDOS operating system >>does things. >What do you want to say? Throw away your linux PCs, buy AMIGA machines? >Perhaps it's a good design, but many linux user have to use a PC for their >daily work (with DOS, Windows or other ugly things running on them) - they >are glad to have a free unix on another partition. Why (especially in Germany) >do so many AMIGA users write articles about a 68000 based linux if they have >perfect machines? > >Ulrich Karl uli@ulk.rmt.sub.org No, this is not what I'm saying though it sounds maybe a good idea :-) Linux on PC's is wonderful and most of all gives you compatibility with the wider world of UNIX machines; you can develop software for UNIX/X and then run it on SGI's HP's or whatever if that's what you need to do. What I'm saying is that the Amiga has a superb operating system with very fast task switching; it is properly multi-tasking like UNIX yet requires minimal disk space/memory, etc. to run (how many UNIXes do you know which can be run on a 512k machine with on 880k floppy drive?). Obviously more memory and a large hard disk makes the system more useable. I imagine the reasone for wanting Linux on the Amiga is the same as wanting it on a PC; for compatibility with bigger machines. I was simply pointing out that the original suggestion of devices as tasks was not a bad idea and that it has been done elsewhere; I'm not saying AmigaDOS is perfect (it doesn't have virtual memory or task protection though VM is available as a third party product). Indeed, I'm planning to buy a Linux PC in the next month for compatibility reasons though my Amiga will remain my main working machine. Andrew -- =========================================================================== Dr.Andrew Martin,SciTech Software,23 Stag Leys,Ashtead,Surrey,KT21 2TD,U.K. At DKfz, Heidelberg until 26Nov1993 (dok423@cvx12.inet.dkfz-heidelberg.de) ------------------------------ From: marca@ncsa.uiuc.edu (Marc Andreessen) 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: 22 Nov 93 05:10:31 In article ellis@nova.gmi.edu (R. Stewart Ellis) writes: [...] the rather unfortunate decision of the Mosaic team to develop with Motif. When I raised an alarm on the use of Motif several months ago, Marc Andreessen justified the choice on ease of using the widgets, but excused the choice by pointing out that Mosaic would be available statically linked for most significant platforms at NCSA. The Linux crowd have been posting statically linked versions of Mosaic on sunsite and other sites for some time now, even with builtin term support I believe. Mosaic is perhaps the single most important free Internet application and the modal way of acquiring it is to ftp it from one of these sites, already statically linked. If the statements about license fees for every distributed copy are true, then those of us who have been getting Mosaic this way will be cut off. Responding to both this post and others... (a) Our academic site license lets us distribute free, statically-linked binaries of Mosaic compiled with Motif 1.2 all we want. We can distribute dynamically-linked binaries of Mosaic compiled with Motif 1.2 as well, as long as we don't distribute the Motif libraries themselves along with the dynamically-linked binaries (which we would't). Please don't argue with me on these points unless you're an OSF lawyer, as they are -- so far as I know, and based on conversations with OSF folks -- facts. And remember, Motif 1.1 was even less restrictive, and is still widely used (our own Sun binaries, for example, are linked to 1.1). (b) EVERY significant workstation vendor has committed to Motif, and everyone but Sun has been shipping it for quite some time. (Sun is apparently finally getting around to shipping it as beta software to some Solaris customers, and will have it out in force early next year -- it is damned annoying that they've stalled on this as long as they have. But that's Sun.) Motif is the closest thing there is to a de facto interface standard on Unix workstations. (Athena does *not* count, and neither does tcl/tk -- flames will be ineffectual as we take Mosaic too seriously to base it on anything not directly supported by the majority of hw/sw vendors out there. And besides, there's already a fine tcl/tk browser.) No, Motif isn't free, and it doesn't come with Linux and similar systems. All I can say is that for Mosaic for X's target user base, the vendors have it covered, and for the user base of which Linux is a part (Intel 386/486/Pentium), we're developing Mosaic for Windows. Not a perfect solution, but it does give us broader coverage than any of the imaginable alternatives with the foundation of vendor-supported technology on each platform. Also, don't get me wrong -- I love the idea of running Mosaic for X under Linux, and will probably be doing that myself in the not too distant future; remember, all it really takes is someone with an academic site license for Motif and a Linux box to make a binary everyone can use, or donate us a development system and we'll do it. Cheers, Marc -- Marc Andreessen Software Development Group National Center for Supercomputing Applications marca@ncsa.uiuc.edu (MIME welcomed here) ------------------------------ ** 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 ******************************