Date: Mon, 27 Nov 1995 17:16:48 +0100 (MET) From: grog@lemis.de (Greg Lehey) To: msmith@atrad.adelaide.edu.au (Michael Smith) Cc: hackers@freebsd.org (FreeBSD Hackers) Subject: Re: Where is the documentation for ibcs2? Message-ID: <199511271616.RAA05014@allegro.lemis.de> In-Reply-To: <199511271041.KAA04477@genesis.atrad.adelaide.edu.au> from "Michael Smith" at Nov 27, 95 10:41:38 am
next in thread | previous in thread | raw e-mail | index | archive | help
Michael Smith writes: > > Greg Lehey stands accused of saying: > >>>> How do I know how to enable the emulation? >>> >>> At install time, when it asks you about it. >> >> I didn't want it then. I want it now. How do I know how to enable >> the emulation? > > Well. Let's establish some grounds for this bickering. Are you a competent > user, with an ability to learn for yourself, and perhaps a little background > with Unix? > > If No, then exit here, go to your nearest Klone retailer with your > computer, and get them to install W95 on it. And go away. > > If Yes, then open your mind, and try putting a constructive lean on your > criticism. Before saying things like that, it's a good idea to read and understand what I'm saying. I don't think you did. First, I consider myself somewhat more than a competent user, even if in this particular case I'm putting the position of a slightly less than competent user. But you don't understand why. >>>> How do I run the program? Just start it by name? >>> >>> Yes. >> >> Aha. Where can I read that? > > "which ibcs2" is something that immediately comes to mind. > For those that have spent a little time with the system, "locate ibcs2" > tells you a lot more. That won't tell you how to run vi. The point Terry was making was that you *don't* need to mention ibcs2. And all that which and locate will tell you is where files are, not what they do. BTW, 'which' is broken. It doesn't pay any attention to the PATH environment variable, so it can't tell you which one you'll run, just the one it thinks most likeley. This can be *very* confusing for a newbie. >>>> Do I need to say "ibcs2 vi", or will it be enough just to write "vi"? >>> >>> Do I need to type "run foo" or just "foo"? >> >> I don't know. What's foo? > > In context, an executable. What kind of executable? A shell script, a FreeBSD binary executable, a Linux executable, a BSD/OS executable, a NetBSD executable, an ibcs2 COFF executable, or something else? That's a serious question. If you don't know what it is, you can't (in a general case) tell how to execute it. > Being childish doesn't help - see "No" above. Missing the point doesn't help either. >>>> I tried vi with the SCO version and got: >>>> >>>> === root@freebie (/dev/ttyp0) /allegro/usr/sco/usr/bin 16 -> ./vi >>>> Abort trap >>> >>> It apparently won't run. >> >> Why not? > > Because "abort trap". Followed by mail to hackers@freebsd.org with some > salient details (which SCO vi, etc etc), and possibly a response with > some helpful advice. Or at least an improvement in your understanding of the > problem. The correct thing to do here would be to follow it up, of course. Which raises another question: how do you debug a COFF program? With a COFF debugger? With a kernel debugger? I think I'm getting there. At the time when I wrote this, I genuinely didn't know whether this abort trap was the result of starting the program wrongly, or whether it was a bug (which I am perfectly capable of following up myself). > I'd guess, in context, that it's looking for shared libraries, and not having > much luck. What does "file vi" have to say? === root@freebie (/dev/ttyp0) /allegro/usr/sco/usr/bin 7 -> file vi vi: sticky 80386 COFF executable I think that this is probably a shlib problem too. Of course, a more obvious error message wouldn't do any harm. >>> You are now typing things at random. >> >> People tend to do that if they can't find the documentation. > > This is akin to "people eat things at random because they don't know what > they are". Go to "No" above, and make an appointment with your local > casualty ward. Uh-uh. If you don't know which of the two possibilities works, you'll try both, too. You didn't shout at me for typing in ./vi. Why not? I didn't try it at random--I tried vi first, and when that didn't work, I tried the alternative, because I thought it might work. According to your logic, I shouldn't have tried either. >> /usr/src/sys/i386/ibcs2, but it doesn't have a Makefile. There's a >> directory /usr/src/lkm/ibcs2, but the program there does nothing more >> than load an lkm. Anyway, what do you think Joe would say? > > He would say "what's the number for tech support"? And any one of us > that have iBCS2 stuff working would have an answer for him im minutes. I asked my original question several days ago, and got few replies, but none which really answered my question. So far, the cause of my complaint is Terry's claim "There isn't one. There doesn't need to be one.", which is blatant nonsense. >>> And let me tell you, a simple (or even a complex) man page will sure >>> as hell not cover it, especially without doing what Linux did and >>> supplying our own IBCS2 shared libraries, etc. >> >> Why not? Because of a dislike of man pages on the part of the person >> who should be writing them? > > How about "what do you expect for what you paid for it"? or "do you want > to be a part of the solution, or an unrelated problem"? Are you saying that writing free software is a justification for doing it badly? I don't think that's the tenor of this group. >> As I said, speak for yourself. If I release software, I document it. > > That's nice. Writing manual pages for an experimental moving target comes > under the heading of "makework", as far as I can see. No. A certain level of documentation helps you keep track of where you are. Admittedly, they won't be as polished, and as I said at the end of my last message, being experimental *is* an excuse for less-than-adequate documentatioon. It's not an excuse for claiming that no documentation is necessary, or that "you gets what you pays for". *That*'s what I'm bitching about, not the lack of documentation per se. >> Now here's the first statement with which I can agree. Fine, except >> that I didn't know that (it didn't say that in the man page). Still, >> a minimum of documentation would help even at this stage. So, what >> remains to be done? > > 8) I think that counts as a "Yes". First thing to do is to talk to > Steven Wallace, current keeper of the iBCS2 code, about his current > stage of development. Then, I'd hit the mailing list archives for > -hackers and -current (at least) and pull out everything relevant to > iBCS2, and see whether there's enough material for a FAQ addition, so > that people who're in your situation can get past the initial stumbling > blocks. Maybe I should remind you of where I'm coming from. I'm not really very interested in running the thing myself, but I'm writing a book on installing FreeBSD, and I'm trying to explain this from Joe Schmoe's viewpoint. So yes, I *do* intend to document the stuff. Again, I'm not bitching about the quality of the stuff, nor particularly about the missing documentation. I'm bitching about the attitude "don't need docs". > Then, if you're in the enviable position of having access to useful SCO > binaries, installing and testing them, and possibly commenting on the > installation process would be handy, and muchly appreciated. Enviable? You've obviously never worked much with SCO stuff :-) Yes, I do have some COFF stuff which I could try out, and I probably will. I don't understand the question of installation. If you can run COFF binaries, you should be able to run the installation programs too. Or am I missing something? > Steven is swallace@freebsd.org. The code in -current is _significantly_ > better than the code in -stable, but obviously still not there. Oh well, I'll keep trying. A couple of questions: Greg
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199511271616.RAA05014>