Linux-Misc Digest #713, Volume #21 Tue, 7 Sep 99 08:13:08 EDT
Contents:
Re: how to load modules without compiling kernel (Marton Lorand)
Using SPARCPrinter under Linux. Can't recompile Ghostscript because of missing files
([EMAIL PROTECTED])
Problems with "LILO" Please Help (Todd Lenderman)
Re: why not C++? (Nathan Myers)
Re: chat script with ISP menu selection problem (Sitaram Chamarty)
Re: Will this ever change? (Robert Heller)
Re: C vs C++ for Open Source projects (Niels M�ller)
Re: Connection Limit? (Jon Skeet)
Re: XGA w/ OS/2 and Linux on laptop (Csaba Raduly)
Re: .htaccess configuration... (Jon Skeet)
----------------------------------------------------------------------------
From: Marton Lorand <[EMAIL PROTECTED]>
Subject: Re: how to load modules without compiling kernel
Date: Tue, 07 Sep 1999 12:25:54 +0300
Joseph H Zieniewicz wrote:
> I have the cdrom module mcd.o and would like to load the module when
> linux
> boots and would like to load the module without re-compiling the kernel.
>
> Is this possible? What is the procedure if possible?
> Thanks in advance.
>
> jozien
There is a possibility to load modules without recompiling the kernel. I
suppose U have the module compiled.
You can type modprobe mcd.o
Or you can try insmod msc.o
Than to see if you succeded or not try lsmod.
To find more about modprobe or insmod read the manual pages for modprobe
and/or insmod.
Lori
------------------------------
From: [EMAIL PROTECTED]
Crossposted-To: comp.os.linux.hardware,comp.os.linux.setup
Subject: Using SPARCPrinter under Linux. Can't recompile Ghostscript because of
missing files
Date: Mon, 06 Sep 1999 18:48:32 GMT
I downloaded the latest version of GhostScript and am trying to
recompile with support for a SPARCprinter as a device. The problem I
am having is it looks like the SPARCprinter device driver code that is
to be compiled into GhostScript, expects to be compiled under Solaris,
not Linux.
Has anyone interfaced the SPARCprinter to a Linux box and made it
work?? If so, How???
Any and all help would be greatly appreciated.
Thanks in advance,
Andy
------------------------------
From: [EMAIL PROTECTED] (Todd Lenderman)
Subject: Problems with "LILO" Please Help
Date: Tue, 07 Sep 1999 10:04:16 GMT
I am using Caldera Open Linux with Windows 98 on a 13 gig harddrive.
I am try to be able to boot to either operating system. When in Linux
and I try to install LILO I get this error
The following error has occurred
Problems has occured during the LILO installation.
Warning : Device 0x0306 Exceeds 1024 Cylinder Limit
geo_comp_addr : cylinder number is to big (1418 > 1023)
I think Linux is telling me my harddrive is too big.
How do I work around this problem.
Thanks....for your help
Todd
*[EMAIL PROTECTED]*
remove * to send e-mail
------------------------------
From: [EMAIL PROTECTED] (Nathan Myers)
Crossposted-To: comp.os.linux.development.apps,comp.os.linux.development.system
Subject: Re: why not C++?
Date: 7 Sep 1999 03:05:40 -0700
Don Waugaman <[EMAIL PROTECTED]> wrote:
>I might add that a suitable compiler design would be to check for NULL or
>otherwise illegal pointers when they are dereferenced, which would mean
>that incorrect dereferencing happens in the caller code rather than the
>called code, thus moving the effect of the error closer to the site of the
>error.
It's easier than that, and in fact g++ can be persuaded to generate
code to check for 0 when initializing a reference.
--
Nathan Myers
[EMAIL PROTECTED] http://www.cantrip.org/
------------------------------
From: [EMAIL PROTECTED] (Sitaram Chamarty)
Subject: Re: chat script with ISP menu selection problem
Date: 7 Sep 1999 04:58:32 -0700
On Sun, 5 Sep 1999 22:20:54 +1000, Boon Yeo <[EMAIL PROTECTED]>
wrote:
>A puzzle.
>
>With Win95/98, I can established a PPP connection
>without having to make a menu selection. Why couldn't
>Linux made to mimic a Win95/98 connection? As far
>as the ISP is concern, that would be another Win95/98
>PPP request. Then there is no need for the chat script.
Two possibilities. (1) your ISP has started to use something
called "MS-CHAP". I have never used it, but I am sure Linux ppp
can do it - you may have to compile it, though.
Or (2) they're using plain old chap (disabled PAP) but the
"remotename" is coming in wrong. On my ISP, for instance, the
remotename can come in as "ts1", "ts2", or "ts3" (each is
presumably a terminal server, depending on which modem you get).
This makes it necessary for me to put in 3 lines in chap-secrets
instead of 1 line with the server name = "diac".
(Fortunately the moment I discovered this I used PAP, since my ISP
did not disable PAP).
Background: (this is all AFAIK!) when looking for a secret in
chap-secrets, pppd uses the username you gave as "user", but
ignores the "remotename" you gave - instead, it is supposed to use
the name sent by the server. With PAP, however, it uses your
command-line args for both "user" and "remotename".
------------------------------
From: Robert Heller <[EMAIL PROTECTED]>
Subject: Re: Will this ever change?
Date: Mon, 06 Sep 1999 19:33:51 GMT
[EMAIL PROTECTED] (George Vlahoulis),
In a message on 6 Sep 1999 14:25:40 GMT, wrote :
GV> On Sat, 04 Sep 1999 23:43:41 GMT, Rod Smith
GV> wrote:
GV> >[Posted and mailed]
GV> >
GV> >In article <[EMAIL PROTECTED]>,
GV> > "Christopher R. Carlen" <[EMAIL PROTECTED]> writes:
GV> >> I have been using Linux for a few years.
GV> >>
GV> >> I consistently run into this situation: I make a graphic in one
GV> >> program, and I want to use it in another program.
GV> >>
GV> >> In Windows, I copy and paste. Done!
GV> >...
GV> >> But in Linux I must export some format that is compatible with the
GV> >> destination program
GV> >...
GV> >> I can also not understand fonts in Linux.
GV> >...
GV> >> Why can Windows do this so well, and Linux (X Window System) can't?
GV> >
GV> >When "it" refers to cutting and pasting between applications, the cause is
GV> >that Windows has a much better clipboard technology for cutting and
GV> >pasting between applications. This is part of Windows or the X Window
GV> >system, and it's a set of tools that applications are invited to use.
GV> >They generally do in Windows, but as the underlying tools are so crude in
GV> >Linux, it just doesn't get used much, except for text.
GV> >
GV>
GV> Unfortunate but true.
GV>
GV> >> Will it ever change?
GV> >
GV> >Probably, but it'll be slow. Even if some APIs came out tomorrow to
GV> >improve these matters, and even if everybody agrees these were Good
GV> >Things, there's still a huge installed base of programs that would need
GV> >to be changed. Since this is **NOT** a Linux issue per se, but an X
GV> >Window System issue, it's not something that we in the Linux community
GV> >can tackle by ourselves. The likes of Sun Microsystems, IBM, Silicon
GV> >Graphics, and others will all have to get together and agree on the new
GV> >protocols. That said, there may be fixes for particular environments. I
GV> >don't know if this is the case, but as a hypothetical for instance, KDE
GV> >might implement some sort of inter-application clipboard, but that
GV> >wouldn't do non-KDE programs much good.
GV>
GV> I dont think it will be slow. As more apps are created for linux pressure
GV> will be put on the designers of X to improve the clipboard. Linux will
GV> propably drive this change as its/will be the most popular and strongest
GV> unix flavor. When other companies like IBM are rushing to provide support
GV> for linux I dont think they will take too long to think about this. If people
GV> demand it it will be fixed. And as a matter of fact, Xfree which is what
GV> linux uses, doesnt give a **** what IBM says anyhow. Sun and IBM are
GV> following Linux's footsteps at the moment so I dont think they will have
GV> a choise in that either if they'll want to be compatible with linux.
Actually the low-level hooks already exist to support this. The main
problems are:
A) Messing with the clipboard (and the PRIMARY and SECONDARY selections)
is generally a pain under X, using the low-level XLib calls.
B) There is not a 'standard' way of dealing with graphics on the
clipboard, in the sense that applications don't have a consensus as to
what graphics formats to support and how *exactly* to support them.
Motif defines a high-level drag and drop protocol, but Motif is a beast
-- too big, slow, cumbersome, etc. Also Motif is encumbered with
copyright restrictions. (Yes, lesstif is also available as a freeware
clone of Motif.)
It should be easy enough to (conceptually) extract Motif's drag and drop
functionality and create a support library, with a layer that provides
a set of standardized translators and transfer handlers for the basic
set of graphics formats (eg. GIF, TIFF, Jpeg, xbm, xpm, pnm, etc.).
Note: doing this as a library *layered* on top of stabdard X11 calls
would be portable and cross platform -- this is something that would
work both with XFree *and* with the X11 packages distributed with commercial
UNIX's (i.e. Solaris, DU, AIX, etc.).
GV>
GV>
GV> gv
GV>
--
\/
Robert Heller ||InterNet: [EMAIL PROTECTED]
http://vis-www.cs.umass.edu/~heller || [EMAIL PROTECTED]
http://www.deepsoft.com /\FidoNet: 1:321/153
------------------------------
From: [EMAIL PROTECTED] (Niels M�ller)
Crossposted-To: gnu.misc.discuss
Subject: Re: C vs C++ for Open Source projects
Date: 07 Sep 1999 12:29:30 +0200
Summary (for those of you who are not interested in language war
details):
* Staying away from C++, or at least providing a C++-free
interface, is a big plus for at least some people working with free
software, and, I suspect, particularly for hackers who might want to
write glue to use your code from other OO-languages.
* If you use C++ in any project with many developers, you need even
more discipline with about coding standards (likely explicitly
forbidding use of some C++ features) than in a comparable project
using C (or java, python or whatever).
Bart Vanhauwaert <[EMAIL PROTECTED]> writes:
> I can't speak for the commercial world, but it seems with the egcs/gcc
> merger, we have just seen that. Things are settling down and are getting
> less and less rough to get linking. There is now (or will be with gcc
> 3.0) one reference free compiler, which supports nearly everything in
> the language. Work on the a newer and better libstdc++ also hasn't
> halted as far as I know.
Last time I tried gcc's c++ compiler (the egcs version and c++
libraries supplied with cygwin-b20), I got the impression that it
didn't do namespaces as required by the standard. And that it didn't
even attempt to get template instantiation right. The latter part is
probably bug compatible with M$'s C++ compiler. That compiler has a
lot of other bugs (delete on const pointers is disallowed, for
instance).
Things might be getting better, but that is the _current_ state of C++
compilers, as far as I have been able to determine. I would be
surprised if it takes less than two or three years until C++ is
reasonably stable.
> : So you'll have fewer potential hackers if you go with C++, even
> : ignoring the possibility that there are fewer people who know C++ than
> : C (I don't know whether or not the difference is large or relevant).
>
> I don't think it is either relevant (because each project has a certain
> target group. Obviously you are not going to start a kernel project in
> C++, neither are you going to start a desktop environment in C... oeps
> forget that :)) nor is it large. KDE proves the free community has
> enough momentum in C++ programmers.
It seems I was not clear here. I think that the "fewer hackers know
C++" argument may be irrelevant. I think the "a lot of potential
hackers are turned away by C++" is something you should take into
account. In particular if you think it could be useful to have your
code linked into other projects.
> : The next issue is integration with other stuff. People like to embed
> : functionality into their favourite tools and "script languages" (perl,
> : python, guile, pike, etc). In general, I think C++ makes that sort of
> : integration a lot more complicated, for two reasons: (1) The
> : interpreter is usually written in C by people who know and like C, and
> : (2) it may be cumbersome to map the C++ OO-structure of your project
> : onto the OO-framework available within the script language, mainly
> : because C++ contains so much cruft that is mixed up with OO but not
> : needed in other OO languages.
>
> If one can express the interface in plain C, it can be expressed in a
> straightforward enough C++ that will map on the OO framework within the
> script language.
There are two cases: (i) The C++ interface is more or less equivalent
to a plain C interface. That's fine, and it probably implies that a
small subset of C++ is being used (for example, no C++ streams visible
at the interface). On the other hand, if you do things this way,
perhaps there's no reason to use C++ from the start? (ii) The
interface contains a lot of C++ specific cruft, relies on C++ style OO
and memory allocation (more on that below), exceptions, etc. As to
which interface style is more common, I don't know. What is your
experience?
> : I think this point is particularly important for libraries. If you are
> : considering writing a library or toolkit of any kind, and you like to
> : do it in C++, please reconsider. Please provide a decent C interface
> : to the toolkit, for use by people who want to use it from plain C, or
> : use it in their favourite script language. Once you have a decent C
> : interface, you can add C++ wrappers around it to make the C++ lovers
> : happy. In this way, you treat C++ as just another non-C language that
> : some people happen to like.
>
> Or do it the other way around, just as easy (difficult).
No. For starters, you may have to compile the interpreter with a C++
compiler. There are a *lot* of subtle differences between C and C++
that can break a working C program when compiled with a C++ compiler.
You could do it, but it's may enough extra work that it isn't done.
> : 1. Use object oriented C. It's possible to write OO-oriented programs
> : in C, even if it is a little cumbersome. The gtk toolkit is one
> : example, and I think some (or most?) of the Gnome applications
> : follow this model. For a somewhat more extreme example, have a look
> : at my lsh programs (http://www.lysator.liu.se/~nisse/lsh).
>
> Code written that way is _not_ pretty. And has all the same
> disadvantages that you attribute to C++. I don't see how they are
> 'less' as you state.
Well, that depends. There exists examples of object oriented C that is
quite pretty. To my eyes, at least.
The main difference here is not a language issue per se, but a
different approach to OO.
Most OO-oriented languages I have seen use an "object reference" as
the basic data type; pointers are passed around, some type checking
and method lookups are done as needed, and there is some kind of gc
(I include reference counting schemes here) behind the scenes to take
care of deallocation issues.
A typical C++ programs often handles OO very differently; you prefer
copying objects when passing them around rather than sharing pointers,
and a lot of strange things happens behind the scenes (I was somewhat
shocked when I discovered that the realloc-style operation on standard
C++ vectors involves using copy-constructors and destructors on all
objects in the vector). Instance variables that are objects or often
non-pointers, etc.
What I'm trying to say is that the difficulty I see when interfacing
C++ stuff with a language with a more traditional flavour of OO, is
not the C++ language in itself, but the style of OO that often comes
with it.
At least that's my experience.
/Niels
------------------------------
From: [EMAIL PROTECTED] (Jon Skeet)
Subject: Re: Connection Limit?
Date: Tue, 7 Sep 1999 12:17:17 +0100
[EMAIL PROTECTED] wrote:
> I have a pretty serious problem with a dedicated server that I set up. It's
> coming to the point now where the server connections seem to be capped.
> Apache (1.3.9) tops off at 467 simultaneous connections, at which point
> connections on all other ports are refused (smtp, ftp, telnet and ssh are
> the other ones open, middle two tcpd-ed). Connecting to Apache is possible
> with several seconds delay. My question is: Where is the bottleneck here?
> The equipment is fine with a 20 Mbit feed, 450 with 512. OS is vanilla
> Redhat 6.0 (The line providers, who are located many thousands of kilometres
> from me, refused to install anything else). Kernel 2.2.5-15, maxservers
> 1024.
Does /var/log/messages tell you anything? You may want to fiddle around
with the values in /proc/sys - there's documentation in the kernel source
tree. You may find you have to increase various things like maximum file
handles etc...
--
Jon Skeet - [EMAIL PROTECTED]
http://www.pobox.com/~skeet/
------------------------------
From: Csaba Raduly <[EMAIL PROTECTED]>
Crossposted-To: comp.os.os2.misc,alt.comp.hardware,linux.redhat.install
Subject: Re: XGA w/ OS/2 and Linux on laptop
Date: Tue, 07 Sep 1999 11:48:50 +0100
[EMAIL PROTECTED] wrote:
>
> Greetings!
>
> I'm looking for a new laptop. It looks like I'm going back to Sager
> (having somehow blown away my old trusty).
>
> I see some video is designated as XGA.
>
> Does this raise any problems for OS/2 or for Linux?
>
> I note also that a couple run ATI Rage Pro 3D AGP. I have the impression
> this isn't good for OS/2 and for Linux; right or wrong?
>
My computer at work has a 3D Rage IIc video card. The drivers
on the CD were passable, but I couldn't get more than 60 Hz
vertical refresh, which is awful. I finally got some newer drivers
which are capable of 80+ Hz. GRADD may be even better.
The SciTech drivers produced all kinds of wonderful
resolution/refresh combinations (up to 100 Hz :-)
Your card has a similar name, which means that there may be
absolutely nothing in common between them :-) . YMMV.
>From what I've heard ATI are definitely Linux-unfriendly.
Not only they don't make drivers, they won't let others do it :-(
Csaba
--
=====BEGIN GEEK CODE BLOCK=====
Version 3.1
GCS/>GMU d- s:- a30 C++$ UL+ P+>+++ L++ E- W+ N++ o? K? w++>$ O++$ M-
V- PS PE Y PGP- t+ 5 X++ R* tv++ b++ DI+++ D++ G- e+++ h-- r-- !y+
=====END GEEK CODE BLOCK=====
Csaba Raduly, Software Developer (OS/2), Sophos Anti-Virus
mailto:[EMAIL PROTECTED] http://www.sophos.com/
US Support +1 888 SOPHOS 9 UK Support +44 1235 559933
Life is complex, with real and imaginary parts.
------------------------------
From: [EMAIL PROTECTED] (Jon Skeet)
Subject: Re: .htaccess configuration...
Date: Tue, 7 Sep 1999 12:04:46 +0100
[EMAIL PROTECTED] wrote:
> Is the following possible using .htaccess:
>
> When I setup a telnet user, he is redirected to /www/htdocs/username when he
> logs in. But this user can also access other directory's like /www/ or
> /www/htdocs/. Now I want to protect these directories, so the telnet user
> cannot access these dir. I did protect them with .htaccess , but the problem
> is that there are several files in /www/htdocs/ that must be accessable
> using the web...So these files weren't accessable anymore...
>
> Now I want protection against my Telnet users, but the files must be
> accessable using the web.....
.htaccess is only used by the web server - it has nothing to do with what
rights a user has to files when he's logged in. You want to use chmod and
chown to do that - look at the man pages for them.
--
Jon Skeet - [EMAIL PROTECTED]
http://www.pobox.com/~skeet/
------------------------------
** 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: [EMAIL PROTECTED]
You can send mail to the entire list (and comp.os.linux.misc) via:
Internet: [EMAIL PROTECTED]
Linux may be obtained via one of these FTP sites:
ftp.funet.fi pub/Linux
tsx-11.mit.edu pub/linux
sunsite.unc.edu pub/Linux
End of Linux-Misc Digest
******************************
