Linux-Development-Sys Digest #755, Volume #6 Sun, 30 May 99 05:14:00 EDT
Contents:
Re: Terabite Plus Filesystems ("Stefan Monnier "
<[EMAIL PROTECTED]>)
glibc 2.0 and 2.1 problems (Trever Adams)
Solaris binary compatibility? (Gerald Gutierrez)
Re: Terabite Plus Filesystems (Thomas H Jones II)
Re: Terabite Plus Filesystems (Christopher B. Browne)
Re: Solaris binary compatibility? (Frank Sweetser)
Re: SMC etherpowerII problem in RH6 ([EMAIL PROTECTED])
device driver in Kernel 2.2.9 (=?iso-8859-1?Q?=B1=E8=C7=FC=BC=AE?=)
Re: Terabite Plus Filesystems ("Gene Heskett")
Configuration Manager for Linux ([EMAIL PROTECTED])
Re: Canon Printer Users...Please Read (John Forkosh)
lifting limit of four md devices ind 2.2.x kernels? (Marc Mutz)
----------------------------------------------------------------------------
From: "Stefan Monnier <[EMAIL PROTECTED]>"
<[EMAIL PROTECTED]>
Crossposted-To:
comp.os.ms-windows.nt.admin.misc,comp.sys.sun.admin,comp.sys.hp.misc,comp.os.linux.hardware
Subject: Re: Terabite Plus Filesystems
Date: 29 May 1999 19:05:07 -0400
>>>>> "David" == David T Blake <[EMAIL PROTECTED]> writes:
> PCs with *x86 architecture have about 1/3 the computing power
> of an alpha at the same clock speed. That is the penalty for
> keeping legacy chip architecture around.
You lost here all credibility.
Stefan
------------------------------
From: Trever Adams <[EMAIL PROTECTED]>
Crossposted-To: comp.os.linux.development.apps
Subject: glibc 2.0 and 2.1 problems
Date: Sat, 29 May 1999 17:26:29 -0600
Ok, I really hate to ask this, but I cannot find the answer I read a few
days before the question using deja.com. Please help me out.
I have a stronghold webserver. It no longer comes with FastCGI support,
so I have to recompile it. It works fine before I do. After I do, it
go into an infinite loop of segfaults. I can see this with ltrace. If
I ltrace or strace it from start, it won't do it, it just shuts down and
exits cleanly (but won't really run).
I have narrowed it down to two possibilities. I am running RedHat 6.0.
They claim it is for 5.2/6.0. It does indeed run on both. I suspect it
will compile right on 5.2.
Those possibilities are: egcs problems with apache/stronghold, and
library problems.
I know Apache and Linux kernel tend not to like egcs. This I thought
was largely fixed for kernel and completely for Apache.
Stronghold has one or two statically compiled objects/libraries you
compile in. One is libssl. This is what seems to be crashing, because
if I remove the .key file for the domain, it stops crashing,
unfortunately this is NOT a solution. I am wondering if something about
it doesn't like glibc 2.1 or egcs.
I have been in contact with C2.net. It seems they want me to go away. I
am about ready to help them get a bad name (by speaking truth about my
experience with them, which hasn't been good and involves some false
advertising besides that listed here), if I can solve this myself since
they did say it was compatible with RedHat 6.0 and I am supposed to be
getting tech support for the lifetime of the product.
I need to know, how can I use the compat libs to compile just stronghold
and make it use them, while leaving everything else as is. Using
RedHat5.2 is not entirely an option, in fact it would take A LOT more
work to make it be. So, this needs to work on RedHat 6.0.
If anyone has an idea how to do this cleanly, please email me. I need
to get this worked out soon.
Thank you,
Trever
------------------------------
Subject: Solaris binary compatibility?
From: Gerald Gutierrez <[EMAIL PROTECTED]>
Date: 29 May 1999 16:43:54 -0700
Hi.
I understand Sun is changing Solaris for Linux binary compatibility
but not the other way around. Are there any projects underway to
allow user-level Solaris/X86 binaries to execute unchanged on Linux?
------------------------------
From: Thomas H Jones II <[EMAIL PROTECTED]>
Crossposted-To:
comp.os.ms-windows.nt.admin.misc,comp.sys.sun.admin,comp.sys.hp.misc,comp.os.linux.hardware
Subject: Re: Terabite Plus Filesystems
Date: 28 May 1999 13:09:56 -0400
Reply-To: Thomas H Jones II <[EMAIL PROTECTED]>
In article <[EMAIL PROTECTED]>,
Bob Hoekstra <[EMAIL PROTECTED]> did thusly spew forth:
>Interesting project! What you don't say is how many files you have per
>directory. This is particularly important for NT.
actually, this is relevant to most types of network served filesystems
and their directories
>I feel that if your data is important and you want a file server that comes
>up and stays up, you should discount NT immediately. I have heard some
>horror stories about NT with very large directories -- as a test, try
>creating 100,000 small files in a single directory and pointing Windows
>Exploder at it. You will find that you can go and have a cup of coffee and a
>cigarette while the screen updates! This sort of activity affects the
>performance of the server as a whole.
not -exactly- a telling test. do the same thing using a unix browser
against a remote filesystem. it still takes a while for it to display.
>While I am a fan of Linux, but I would think twice about this sort of task
>for it. This leaves (IMHO) only HPUX and Solaris from your list. My personal
>preference is for Solaris, but I don't think that's critical and I cannot
>really justify it.
linux might be fine with a smallish filesystem, but if you take it too
large and ever have to fsck it... go get dinner and a movie. as to HP-UX,
dont even consider using it for NFS. relative to Sun and SGI (or even a
NetApp), it's a horrible performer.
>Furthermore, I would resist using intel-based hardware. PCs are just not
>built to the same standard as most of the "real" Unix boxes from Sun, HP,
>IBM, SGI, etc.
problem really isnt the hardware but the software running on it. solaris
x86, linux and BSD boxes ive had the pleasure to work on have been pretty
reliable. throw a M$ OS on them, and that's when they got crashy.
>Lastly, consider if a 64 bit hardware/OS combination may benefit. UltraSPARC
>+ Solaris 7 is one option here, but so is DEC Unix (or whatever Compaq is
>calling it now) on an Alpha box.
as a fileserver, the 64 bitness isnt really going to help, except with
allowing for large filesystems (isnt the figure for XFS something like 9M
TB? at least according to the "SGI to Open Source XFS" article on ZDNET).
What really buys you something on a server is the number of network file
service requests/sec. it can service, how big the filesystem can grow, and
whether the filesystem has good failure recovery (underlying RAID and
journalled filesystems).
-tom
--
"You can only be -so- accurate with a claw-hammer." --me
------------------------------
From: [EMAIL PROTECTED] (Christopher B. Browne)
Crossposted-To: comp.os.linux.alpha,comp.os.linux.hardware
Subject: Re: Terabite Plus Filesystems
Reply-To: [EMAIL PROTECTED]
Date: Sun, 30 May 1999 01:00:27 GMT
On 29 May 1999 19:05:07 -0400, "Stefan Monnier
<[EMAIL PROTECTED]> posted:
>>>>>> "David" == David T Blake <[EMAIL PROTECTED]> writes:
>> PCs with *x86 architecture have about 1/3 the computing power
>> of an alpha at the same clock speed. That is the penalty for
>> keeping legacy chip architecture around.
>
>You lost here all credibility.
Indeed. My Alpha/166 system is absolutely *not* the equal of a 400MHz
IA-32.
It is instead roughly the equal to a P75/P90, thus suggesting a rather
different ratio, such as that PC's with IA-32 architectures have
approximately twice the computing power of an Alpha-based system of the same
clock speed.
I would not, however, promote *that* position either, as it is not a
reasonable characterization of either Alpha or IA-32.
A fairer claim would be that for FP-intensive operations, Alpha systems are
comparatively a *lot* faster than IA-32 systems of similar price.
It is not clear which processor has advantage when working with highly I/O
intensive operations; that is liable to be dominated by:
a) The speed of the disk system, and
b) The rate at which DMA can move data back and forth between memory and the
devices.
In that circumstance, Alpha won't have a substantial advantage.
In applications involving hefty amounts of integer calculations that can fit
into 32 bits, IA-32 appears to be a more economical answer.
When 64 bit values start to represent important factors in applications,
Alpha will doubtless look better in that it can do things in one instruction
that likely take 4 or more on IA-32.
Those are the sorts of factors that *should* be used to assess which
architecture will be preferable; the blanket assessment that
"AXP = IA-32 * 3" just makes the proponent look ignorant.
--
Those who do not understand Unix are condemned to reinvent it, poorly.
-- Henry Spencer <http://www.hex.net/~cbbrowne/alpha.html>
[EMAIL PROTECTED] - "What have you contributed to free software today?..."
------------------------------
From: Frank Sweetser <[EMAIL PROTECTED]>
Subject: Re: Solaris binary compatibility?
Date: 29 May 1999 20:17:56 -0400
Gerald Gutierrez <[EMAIL PROTECTED]> writes:
> Hi.
>
> I understand Sun is changing Solaris for Linux binary compatibility
> but not the other way around. Are there any projects underway to
> allow user-level Solaris/X86 binaries to execute unchanged on Linux?
don't know about on x86, but it's been able to do that on sparc hardware
practically since day 1 - the only catch is you need to copy the libraries
(and possibly dynamic loader - don't recall) over to run dynamically links
apps.
--
Frank Sweetser rasmusin at wpi.edu fsweetser at blee.net | PGP key available
paramount.ind.wpi.edu RedHat 5.2 kernel 2.2.5 i586 | at public servers
"All language designers are arrogant. Goes with the territory..."
(By Larry Wall)
------------------------------
From: [EMAIL PROTECTED]
Crossposted-To: comp.os.linux.networking
Subject: Re: SMC etherpowerII problem in RH6
Date: Sun, 30 May 1999 00:42:32 GMT
My problem seems solved ; it wasnt the EPIC driver after all, got sth
wrong with routing ....
My card is SMC9432TX, i dont know about your card exactly but maybe you
dont have to use Tulip drivers but EPIC100 driver. You gave it a try yet
?
> I have a SMC Etherpower (SMC8432BT) that works fine under RH 5.2 but
> doesn't work under RH 6.0. The link light on the hub comes on as soon
as
> the "tulip" module is loaded then goes off as soon as the startup
scripts
> try to "ifup eth0" the device. I re-compiled the kernel to have the
> absolute minimum amount of drivers (modules or otherwise) which
usually
> solves my problems but it didn't help in this case. I'm using a HP
> Pavilion 6370Z (Pentium II 350MHz) with ATI Rage Pro video board and
96MB
> of memory. I would be interested in knowing what type of system you
are
> using. Some people don't seem to have any problems but others, like
> myself, can't get the ethernet interface up at all.
>
> Thanks,
>
> Phil
>
>
Sent via Deja.com http://www.deja.com/
Share what you know. Learn what you don't.
------------------------------
From: =?iso-8859-1?Q?=B1=E8=C7=FC=BC=AE?= <[EMAIL PROTECTED]>
Subject: device driver in Kernel 2.2.9
Date: Sun, 30 May 1999 03:58:05 GMT
I make a device driver in kernel 2.0.36 . But after I install kernel
2.2.9,
it is not loaded to kernel!! error message is followed:
% insmod fsex.o
fsex.o: unresolved symbol vremap
fsex.o: unresolved symbol memcpy_tofs
fsex.o: unresolved symbol memcpy_fromfs
So, I change memcpy_xxfs to copy_xxx_user, but same...
% insmod fsex.o
fsex.o: unresolved symbol vremap
fsex.o: unresolved symbol copy_to_user
fsex.o: unresolved symbol copy_from_user
What is changed about PCI in kernel 2.2.9?
------------------------------
Date: 29 May 99 22:25:10 -0500
From: "Gene Heskett" <[EMAIL PROTECTED]>
Subject: Re: Terabite Plus Filesystems
Crossposted-To:
comp.os.ms-windows.nt.admin.misc,comp.sys.sun.admin,comp.sys.hp.misc,comp.os.linux.hardware
Gene Heskett sends Greetings to David T.;
DTB> "Al in Seattle" <[EMAIL PROTECTED]> writes:
>>I don't see where money is an issue in his original mail.
DTB> I believe the statement was that he wanted to stick with
DTB> *x86 architecture for cost purposes.
>>Other than the fact that you folks all use Unix based systems that
>>are recommending Unix based system, what technical reason are you
>>siting for not using an NT based system?
DTB> We regularly find 2-3 times the sys admin manpower required
DTB> for NT boxes compared to UNIX boxes in the same setting. And
DTB> I've had more than enough experience with the blue screen of
DTB> death. There are a number of core problems with NTs usability.
DTB> Such as,
How about the zeroth entry? Should it not be that you can't make it run
an application, any application, on the un-attended but rebooted due to
a power failure or ??
There apparently *must* be someone with enough knowledge to at least log
in before the son-of-a-bitch will run the application you bought it to
run. NT, and M$, apparently has no idea that there may be an important
app that really should run as long as its powered up. Call Redmond and
bitch, but be prepared to pay thru the nose while they listen to you
bitch, and then reply "its not designed to do that".
That entry AFAIC, comes at the top of the bitch-list about NT. Why?
Because its an everyday problem to me.
DTB> 1) Want to put in a new video card - reboot about 10 times.
DTB> 2) Video server built in to the kernel
DTB> 3) Want to extend functionality - send a check for $10k to
DTB> Redmond
DTB> 4) Want to program - send another check to Redmond - one
DTB> for each language
DTB> 5) Having problems with the OS - too bad. Call Redmond and
DTB> pay out the nose while you wait on hold, and then talk to
DTB> someone who knows horribly less than you about the OS.
DTB> 6) Remote administration
DTB> 7) Lack of a respectable scripting language for administration
DTB> purposes
>>Some of the quotes:
>>"I feel that if your data is important and you want a file server
>>that comes up and stays up, you should discount NT immediately. I
>>have heard some horror stories about NT with very large directories "
>>no basis in fact here.
>>"PCs are just not built to the same standard as most of the "real"
>>Unix boxes from Sun, HP, IBM, SGI, etc. The one exception that comes
>>to mind would be the Sequent range." pure bs. It simply depends on
>>what you are willing to spend.
DTB> PCs with *x86 architecture have about 1/3 the computing power
DTB> of an alpha at the same clock speed. That is the penalty for
DTB> keeping legacy chip architecture around.
>>Compaq and others have totally capable boxes if you want to spend the
>>same kind of money that the Unix crowd delivers.
DTB> I understand the Compaq XP-2000 is a quite capable box. If you
DTB> don't have the $$ for that you can try the DS-10 from Compaq for
DTB> about $3500 + $1200 or so for Tru64Unix (or linux for free).
DTB> --
DTB> Dave Blake
DTB> [EMAIL PROTECTED]
Cheers, Gene
--
Gene Heskett, CET, UHK |Amiga A2k Zeus040 50 megs fast/2 megs chip
Ch. Eng. @ WDTV-5 |A2091,GuruRom,1g Seagate,CDROM,Multiface III
<[EMAIL PROTECTED]> or |Buddha + 4 gig WDC drive, 525 meg tape
<[EMAIL PROTECTED]>|Stylus Pro, EnPrint, Picasso-II, 17" vga
RC5-Moo! 22kkeys/sec isn't much, but it all helps
--
------------------------------
From: [EMAIL PROTECTED]
Subject: Configuration Manager for Linux
Date: 30 May 1999 04:40:36 GMT
For quite a while, I've been thinking of making a (or working on an
existing) configuration manager for Linux. I.e., it would/could set up
hardware, network connections, users+passwords, etc.
I know that a number of such systems exist, however I've been disappointed
by the offerings. I.e., poor interfaces, poor handling of version
checking (a configuration manager, upon invoking an external tool, such as
ifconfig, should first check if it is using a particular version), poor
help systems, poor modularity, poor hardware management, etc.)
For a while, I thought of extending COAS (http://www.coas.org), however
there were a number of things I thought should be changed (the interface
is poor, it doesn't work over networks, the help system stinks, etc.)
What I had in mind was a tool, or set of tools, that did configuration
management "the Right Way(tm)". It would allow users to perform common
tasks with ease (that's the whole point, right?), however it would be sure
to inform the user on what was happening (perhaps having an option to view
what commands were being made (ifconfig, route, insmod, etc)) as well as
any errors that occurred.
In terms of architecture, I was thinking of using a combination of C (or
C++), XML (using libxml, which is only 130k in size), and Perl. The core
stuff would be done in C (anything that doesn't do actual configuration
routines), the "modules" would be written in Perl, as Perl is well-known,
has excellent string management tools, and is available on most Linux
setups, and specific data sets would be written in XML, such as the
definition of a piece of hardware.
The system would also try not to be specific to any one package. For
example, if a user changed the information about their video card, the
configuration system would update info for X, SVGAlib, GGI, etc. This
same idea of modularity could also be applied to user management, where if
a user changed their password, the sysadmin could optionally chose to have
the passwords updated in /etc/passwd, /etc/smbpasswd, or whatever system
is available.
Thoughts? Comments? Flames?
--
David Ludwig | "The Linux philosophy is laugh in the face of
davidl<at>wpi.edu | danger. Oops. Wrong One. 'Do it yourself.'
http://www.wpi.edu/~davidl | That's it." - Linus Torvalds
------------------------------
From: [EMAIL PROTECTED] (John Forkosh)
Subject: Re: Canon Printer Users...Please Read
Date: 30 May 1999 02:26:35 -0400
Deborah K ([EMAIL PROTECTED]) wrote:
: To all,
: I wrote canon about a driver for my printer that would work with Linux
: and here is there reply!
snip
: > Dear Deborah,
: > Thank you for your inquiry.
: > Canon does not currently support the Linux operating system. There are
: currently no plans for future Linux operating system driver development for
: this model.
If you can generate postscript output from your application,
or somehow convert its output to postscript, then the ghostscript
package may provide sufficient support for you. It can convert
postscript to hundreds of printer language formats. I don't know
whether your Canon is one of those hundreds, but if it is then
you should be okay.
John ([EMAIL PROTECTED])
------------------------------
Date: Sun, 30 May 1999 10:24:05 +0200
From: Marc Mutz <[EMAIL PROTECTED]>
Subject: lifting limit of four md devices ind 2.2.x kernels?
HI out there!
Is it a trivial task to do the above (e.g. changing constant definition
in source file) or is it more involved?
Any hints?
Thanks,
Marc
------------------------------
** 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.development.system) 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-Development-System Digest
******************************
