From: Digestifier To: Linux-Misc@senator-bedfellow.mit.edu Reply-To: Linux-Misc@senator-bedfellow.mit.edu Date: Tue, 14 Sep 93 06:13:08 EDT Subject: Linux-Misc Digest #130 Linux-Misc Digest #130, Volume #1 Tue, 14 Sep 93 06:13:08 EDT Contents: To: scorpio.metro.co.uk... (Michael O'Reilly) Re: NT versus Linux (Kevin Brown) tex 3.1415 (Thomas Esser) Re: e2fsck: root inode not a directory [HELP!] (Brian Leary) Re: xlock in SLS dist broken (Terry Evans) Problem installing LINUX with OS/2 2.1 (Solved!) (Jason Lei) Re: 16550's (Mark Kassab) [Q] libc 4.4.2 sources ... (Stefan Bohm) The talk daemon problem over CSLIP/SLIP (Gene Choi) 0.99.9 SLIP?? (jP@hpacv.com) ---------------------------------------------------------------------------- From: oreillym@tartarus.uwa.edu.au (Michael O'Reilly) Subject: To: scorpio.metro.co.uk... Date: 14 Sep 1993 03:37:16 GMT Original was: Replied: Tue, 14 Sep 1993 09:38:00 +0800 Replied: root@scorpio.metro.co.uk Return-Path: root Return-Path: Received: from eros.britain.eu.net (eros.Britain.EU.net [192.91.199.2]) by tartarus.uwa.edu.au (8.1C/8.1) with SMTP id XAA26630; Mon, 13 Sep 1993 23:20:17 +0800 Received: from scorpio.metro.co.uk by eros.britain.eu.net with UUCP id ; Mon, 13 Sep 1993 16:20:04 +0100 Received: from scorpio by metrologie.co.uk; Mon, 13 Sep 93 17:19:06 GMT Received: by scorpio.metrologie.co.uk (Smail3.1.28.1 #6) id m0ocGID-0005nLC; Mon, 13 Sep 93 15:58 GMT Message-Id: From: root@scorpio.metro.co.uk Subject: Andrew Toolkit for Linux To: oreillym@tartarus.uwa.edu.au Date: Mon, 13 Sep 1993 15:58:17 +0000 (GMT) X-Mailer: ELM [version 2.4 PL21] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 212 Hi Mike, Are there diffs available for the 5.1 distribution for Linux. I have all the source cod for 5.1, it would seem silly to download another 5MB of binaries when I could compile it myself. Cheers Alan ==================================================== Return-Path: root Return-Path: Received: from localhost (localhost) by tartarus.uwa.edu.au (8.1C/8.1) with internal id JAB05455; Tue, 14 Sep 1993 09:38:12 +0800 Date: Tue, 14 Sep 1993 09:38:12 +0800 From: Mail Delivery Subsystem Subject: Returned mail: Host unknown Message-Id: <199309140138.JAB05455@tartarus.uwa.edu.au> To: ----- The following addresses failed ----- ----- Transcript of session follows ----- 550 ... Host unknown ----- Unsent message follows ----- Return-Path: oreillym@tartarus.uwa.edu.au Received: from tartarus.uwa.edu.au (localhost [127.0.0.1]) by tartarus.uwa.edu.au (8.1C/8.1) with SMTP id JAA05453; Tue, 14 Sep 1993 09:38:12 +0800 Message-Id: To: root@scorpio.metro.co.uk Subject: Re: Andrew Toolkit for Linux In-reply-to: Your message of "Mon, 13 Sep 1993 15:58:17 GMT." Date: Tue, 14 Sep 1993 09:37:44 +0800 From: "Michael O'Reilly" > > Hi Mike, > > Are there diffs available for the 5.1 distribution for Linux. I have > all the source cod for 5.1, it would seem silly to download another 5MB of > binaries when I could compile it myself. > > Cheers > > Alan > Hmm. Have you got 100Megs free disk space? The source expands to 35 mesgs, and it uses well over 100 megs while compiling... Diffs are tartarus.uwa.edu.au:/pub/oreillym/andrew.diffs Michael. ------------------------------ Crossposted-To: comp.os.ms-windows.advocacy From: kevin@frobozz.sccsi.com (Kevin Brown) Subject: Re: NT versus Linux Date: Tue, 14 Sep 1993 03:03:29 GMT In article strobl@gmd.de (Wolfgang Strobl) writes: >In <1993Sep11.231221.1535@microsoft.com> muzok@microsoft.com (Muzaffer Kal) writes: > >>In article strobl@gmd.de wrote: >>> >>> A design is always limited. In what way is 16M better than 1M? Supporting >> ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ >>this is a joke right ? > >No, it was a serious question. > > >> Even today 16M of physical memory is enough for most of >>the systems and apps. > >Well, this is quite similar to the argument twelve years ago: most >of the systems in use have 32, 48 or 64K, and even today 640K of >physical memory is enough for most of the systems and apps. Yeah, but the point is that Motorola came out with a chip that supported 16 meg at a time when 64k was the most that was being used by programs on personal computers. And the limits of today's processors isn't 16 meg, even though that's all that's currently being used by most people: it's 4 gigabytes. This is *precisely* where things should be, and should have been all this time: limitations of the pocketbook determining how much memory you can use, not limitations of the CPU. If the Motorola chip had been used (and if it had been possible to use it), then the situation of hitting the 640k *hard* CPU barrier wouldn't have happened. Why? Because (a) the internals of the 68000 support 32-bit addressing, and (b) Motorola came out with a processor with a true 32-bit address bus (the 68020) well before people were coming close to using 16 megabytes. >>Also there is nothing implicit in the software architecture >>of 68000 which creates a 16MB limit. > >The very same statement can be made about the 80286. Well, it *can* be said about the 286, but the limit is smaller than it is for the 68000. The 286 descriptors have 24 bits for the base, and since this is shifted left 4 times for address calculation, that affords you 28 bits of addressing grand total (thus, you can internally address 256 meg). But the external address bus is 24 bits, so *externally* you can only address 16 megabytes. >>The only problem is that the chip has 24 address >>lines and it is in no way reflected to the software. All the address registers are >>32 bits. The moment you upgrade to a 32 bit address bus, you get all the 4G space. > >>> only a flat, linear address space is a limited design, when compared >>> with segmented memory, IMHO. > >>> >>> What was the first thing Apple did when they implemented the memory management >>> for the Mac? Right: they implemented memory segmenting on the 68000, > >>Again there is nothing implicit in 68000 which requires such an implementation. > >But perhaps there was something implicit in the design for a software system >like the Macs OS which requires such an implementation? The fact that >Windows took a very similar approach could make one believe so. Windows was written explicitly for the Intel line of processors (in particular, the 286), so you can't use that as an example of a decision to deal with segments, because they were *forced* to use segments as a result of the architecture of the processors they wanted to support. Apple had no such excuse. >>This is because of the brain-dead design of Apple. They didn't want to use 32 bit >>offsets and their compiler generates jumps only with 16 bit offsets so the problem >>of 32K segments. > >They had to fit their whole system into one 64K ROM and some part of >128K RAM, if I'm not mistaken. Changing a system which consists mainly >of pointers from 16 bit pointers to 32 bit pointers blows it up by a >factor of two. This is still a bad design. If they were really concerned about this sort of issue, they could just as easily have built a list of 32-bit vectors and used that as part of the system call interface, and thus it wouldn't *matter* where they moved things. They have the source code. Moving addresses around isn't a problem. Retaining compatibility with existing applications is a problem only if you move the jump tables around or implement a brain-dead design. If you're *really* intelligent, you'll have a system call in your OS that will tell you where the library base is for whatever library you're interested in. If you're even more intelligent, you'll have the library be loaded dynamically at runtime if it isn't already loaded, when such a system call is made. Turns out that this is the approach the Amiga takes. As I describe below, you can use this approach to describe the interface to the kernel as well as to DLLs. >Does the 68000 have 32-bit offsets for PC-relative jumps (which are >a necessity for position-independant code)? No, and this is probably why they designed things that way. Note that the Amiga takes a different approach: the operating system looks like a set of libraries, and a library is a list of 32-bit vectors. Executables have addresses resolved at load time rather than at link time, so the OS can load a program anywhere and the program can use any 68000 addressing mode. >>> quite similar to the 286s 64K segmenting, without bounds checking and, > >>but unlike a 8086 vs 286 comparison, there is no mode switching in 68000 family. >>68000 doesn't force you into using only 16M, it keeps all the 32 bits addressing >>info. Of course if you are dumb and use the top byte of the address for book-keeping >>(against the advise of Motorola, saying that 32 bit processors are on the way) >>then you deserve all you get and have to wait for "32 bit clean" software to run on >>your Quadra. > >Well, I don't have a Quadra, I'm just waiting for 32 bit clean software >to run on my Windows NT machine :-). > > >>Also 286 forces you into only these 3 segment cache registers at any time and only >>8K segment tables. > >There are FOUR segment registers, and the 8K LDT/GDT limit is just as >invisible to ordinary application programs as the aforementioned 24 bit >adress lines limitation. On the 286, the internal address space is 256 meg (28 bits). This is still less than the 32 bit internal address space of the 68000, and on a chip that came out several years after the 68000 did. >>So the brain-dead segmented architecture >>of 286 is not very usefull. > >Calling something bread-dead doesn't convince me much. An architecture >which is limited to segments of less than 64K bytes size is limited >to memory sizes of a few MBytes at most, to be usefull. Oh, then you *do* agree that the 286 is a brain-dead architecture. :-) >So perhaps >Intel should have had built long segments into the 80286 instead >of keeping that for the 80386, where it came to late, IMHO. Exactly. The 386 is actually reasonable because segment bases are 32 bits and segment offsets are also 32 bits. That makes for a 36 bit internal address space, but more importantly it means that processes can actually use a flat address memory model just like they can on the 68000 (note that on the 68000, there really isn't a virtual address space, so the code has to have symbol resolution happen at load time rather than link time if you're going to allow processes to use all the addressing modes of the 68000). The 286 can make a process think its code and data start at address zero, but only for 64k chunks. You still have to worry about memory models for the user processes. You don't if you're running on a 386. >>I think nobody can argue that >>the x86 family of processors was the worst problem we have had in the last 10 years.) > >Aren't we doing this just now? :-) > >Anyway, I'd argue that Intel processors have a lot of problems and design >faults, segments limited to 64K being one of them. But segmenting itself >isn't a design fault, IMO. Just to the contrary, it nicely solves a lot of >software problems (relocation, reentrancy, multiple instances, code >sharing) which have to be solved by resorting to various kludges >on flat memory designs. Yup. We definitely agree here, and this is basically what I pointed out early on in this debate. But Intel didn't get it right until they introduced the 386, long after the 68020+68851 combination came out. >There is only one thing which really annoys me about the Intel processors: >they can't virtualize themselves. A capability like this can solve a >lot of problems, as demonstrated by IBMs VM system. Hmm...I thought the 386 had a virtual mode for most of its instructions, but a few of them weren't. Maybe it's those few instructions that you're talking about. -- Kevin Brown kevin@frobozz.sccsi.com This is your .signature virus: < begin 644 .signature (9V]T8VAA(0K0z end > This is your .signature virus on drugs: <> Any questions? ------------------------------ From: te@ipc1.rrzn.uni-hannover.de (Thomas Esser) Subject: tex 3.1415 Date: Mon, 13 Sep 1993 21:10:54 GMT in the ChangeLog of SLS a tex-version of "tex 3.1415" is mentioned. My question: has SLS an own method of numbering ore are the sources for tex3.1415 on the net? If yes, where can I find them? (If not, where can I find the latest tex-version ?) I would like to update the tex3.14 that is currently running on our SUNs, if the is a newer version. Thanks a lot, Thomas ------------------------------ From: bleary@nyx.cs.du.edu (Brian Leary) Subject: Re: e2fsck: root inode not a directory [HELP!] Crossposted-To: comp.os.linux.development,comp.os.ms-windows.advocacy Date: 14 Sep 93 05:20:41 GMT >>>>> On 14 Sep 93 03:08:52 GMT, gt8134b@prism.gatech.EDU (Howlin' Bob) said: |> I can't get to my Linux sources to look at ext2fs. Can anyone help |> me out here? Some simple pointers as to where to look, how to tell |> where the first inode starts on disk, and which bits to set to make |> it a directory would be great. Is this the same ext2fs you were recently touting as being rock solid? One suggestion might be to switch to NTFS. Hahaha! -Bri ------------------------------ From: tevans%sunset.cs.utah.edu@cs.utah.edu (Terry Evans) Subject: Re: xlock in SLS dist broken Date: 13 Sep 93 23:43:28 MDT jsc@slayer.mit.edu wrote: : The xlock that comes with the SLS Linux distribution is broken; it : doesn't use the shadow password stuff, and therefore won't let you back : into your account once you've locked the screen. The fix is a quick hack : to getPassword() in xlock.c to get it to use getspnam(). If you want to get back in just hit the return key. No password is needed :-) Terry tevans@cs.utah.edu ------------------------------ Crossposted-To: comp.os.os2.setup,comp.os.linux.help,comp.os.os2.misc From: leij@mentor.cc.purdue.edu (Jason Lei) Subject: Problem installing LINUX with OS/2 2.1 (Solved!) Date: Tue, 14 Sep 1993 05:38:40 GMT In article jcburt@gats486.larc.nasa.gov writes: >In article <26vv2s$52p@inxs.concert.net> ctwilson@rock.concert.net (Charles T Wilson -- Personal Account) writes: > In article leij@mentor.cc.purdue.edu (Jason Lei) writes: > > > d. rebooting or skipping reboot (which made no difference) > > e. mke2fs -c /dev/hda3 123060 (hda3 is the LINUX partition > > prepared by OS/2, 123060 is the size in block shown from > > the LINUX fdisk table) > > you look okay here too. > > >Finally, I got "mke2fs: Unable to find a block for the inode table." > >Did I miss something? Any help would be appreciated. > > I'd take the installable flag off that partition; I'm betting that's > where your missing block is (although I could be all wet..wouldn't be > the first time) > >Or, you could try just doing mke2fs -c /dev/hda3 >(notice no "number of blocks" specified). Sometimes mke2fs >is able to figure out a way around the above mentioned error if you >don't force it to use a specific number of blocks (it will use the >largest it can). if that doesn't work, try playing with the #blocks >term (i.e. reducing the size of the filesystem) until the message goes >away... It turns out that the problem was that mke2fs uses 8192 blocks as a group. 123060 is equal to 15.02 groups and the '.02' group caused the problem. I reduced the size to 120000 (maybe too much) and it did go through. One netter e-mailed me and suggested 122880 (or 122881) would also work. Now if only I want to reformat the partition and gain more space. ;^) Thank the netters who replied!! Jason -- Jason Lei Horticulture Purdue University West Lafayette, IN 47907 ------------------------------ Crossposted-To: mtl.general,alt.sys.pc-clone.gateway2000,comp.sys.ibm.pc.hardware From: mark@macs.ee.mcgill.ca (Mark Kassab) Subject: Re: 16550's Reply-To: mark@macs.ee.mcgill.ca Date: Tue, 14 Sep 1993 08:55:30 GMT Are the 16550's compatible with 16450's? That is, can you just plug in a 16550 in place of a 16450? I'm running Linux 0.99pl12 and connecting with SLIP at 38400. I frequently get disconnected though. I doubt that line noise can be that bad (my ZyXEL U-1496E is pretty resistant to noise). Could it be possible that my GatewayDX2-66v can't keep up with the 16450's interrupts and hence the small buffers overflows and I get disconnected? Sorry for the cross posting, but I really want to get to the bottom of this. Thanks in advance, Mark =============================================================================== Mark Kassab | Lab : (514)398-3937 | Keep stress out of your MACS Laboratory | Home : (514)934-3718 | life. Give it to others McGill University | Email: mark@macs.ee.mcgill.ca | instead. Montreal, Canada | m.kassab@ieee.org | =============================================================================== ------------------------------ From: stefanb@aquila.uni-muenster.de (Stefan Bohm) Subject: [Q] libc 4.4.2 sources ... Date: 14 Sep 1993 08:58:54 GMT -- Hi! Does anybody know where to obtain the libc 4.4.2 sources? Thanks for any help in advance. Stefan ------------------------------ From: genie@scam.Berkeley.EDU (Gene Choi) Subject: The talk daemon problem over CSLIP/SLIP Date: 14 Sep 1993 09:16:26 GMT I remember reading about problems people were having getting talk to work properly over a SLIP line (NET-2 code). Well, now that I've finally gotten CSLIP working, I can't seem to get the talk/talkdaemon to work properly. I remember someone mentioning that ytalk was able to talk to all sorts of different daemons (both old sun and new versions). This still doesn't solve the problem (the problem seems to be that the talk daemon can't reach anyone outside of localhost). To compound the problem, ytalk complains of this: ################################################################## # YTalk error: Warning: cannot write to YTalk daemon # # System error: Invalid argument # # # # Press ESC to continue: # ################################################################## I've been unsuccessful in communicating with talk to anyone other system besides this single linux host. Is there any fix for this? Gene ------------------------------ From: jP@hpacv.com Subject: 0.99.9 SLIP?? Date: Tue, 14 Sep 1993 05:45:03 GMT [ Article crossposted from comp.os.linux.admin ] [ Author was jP@hpacv.com ] [ Posted on Tue, 14 Sep 1993 05:44:08 GMT ] Help! I have recently installed / setup 0.99.9 on 3 machines using NE2000 cards and all is wonderful! No problems on the local net at all. BUT I need to get a SLIP going and do not see that it is included here (unless I'm missing something). I have seen and read the "NET-2-FAQ" but was wondering if there was ANY way todo this without all the kernel patching/installing etc. Is there something for 99.9? KA9Q maybe?? What is (was) used in the past before "NET-2"??? ANY help is greatly appreciated! postmaster@hpacv.com ------------------------------ ** 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 ******************************