Linux-Development-Sys Digest #919, Volume #6 Thu, 1 Jul 99 06:14:39 EDT
Contents:
A New File System Install ("Ilhoon,Shin")
Re: Postgresql Success rate ("Jason B. Johnson")
creating a universal loadable kernel module ([EMAIL PROTECTED])
Re: Filesize larger than 2 GB on Intel machines an Linux 2.0.36 (Christopher B.
Browne)
Shared libs in Linux-Request for clarification (Howard Mann)
Re: A New File System Install (Christopher B. Browne)
Re: Remote login problems in custom RedHat env... (Bryan)
C++ templates: More than Turing Complete? (Christopher B. Browne)
Re: TAO: the ultimate OS (Peter Samuelson)
Re: Why not C++ ("Thomas Steffen")
Re: Shared libs in Linux-Request for clarification (Markus Pietrek)
Re: WHAT ARE THESE TERMS SUPPOSE TO MEAN (Peter Samuelson)
Re: C++ templates: More than Turing Complete? (Nathan Myers)
Re: Why not C++ (Stephan Houben)
Re: Why not C++ (Stephan Houben)
vt100 documentation and parsing ("Jean-Christophe Dhellemmes")
----------------------------------------------------------------------------
From: "Ilhoon,Shin" <[EMAIL PROTECTED]>
Subject: A New File System Install
Date: Thu, 1 Jul 1999 20:37:21 +0900
Our project team are willing to develop a new file system in LINUX.
So, we must know how to install the developed file system into linux.
For example, if we have the developed source files and object files, then,
what should we do next?
if someone knows how to install a new file system,
please answer to me..
very thanks..
jeje
------------------------------
Date: Wed, 30 Jun 1999 22:36:46 -0500
From: "Jason B. Johnson" <[EMAIL PROTECTED]>
Crossposted-To: ahn.tech.linux,alt.os.linux,comp.os.linux.development.apps
Subject: Re: Postgresql Success rate
"Alexander F. Hartner" wrote:
> Has anybody experienced serious problems using Postgresql 6.4 with Java
> (JDBC) on a medium size network. Is Datacorruption a problem. From what I
> have experienced in the short time that I have been using Postgresql it is
> the best thing since sliced bread, but people seem unsure to use it.
>
> Thanks
> Alex
It seems pretty cool. I don't use it because I use serial fields alot, and
having to define a function to do that just doesn't "feel" right to me.
Later,
Jason
------------------------------
From: [EMAIL PROTECTED]
Subject: creating a universal loadable kernel module
Date: Thu, 01 Jul 1999 03:35:38 GMT
Hello everybody !
Does anybody know if there is a possibility to compile a kernel module
in a way so that I can load it under a non-smp / smp machine with kernel
symbol versioning on /off ?
Sent via Deja.com http://www.deja.com/
Share what you know. Learn what you don't.
------------------------------
From: [EMAIL PROTECTED] (Christopher B. Browne)
Crossposted-To: comp.os.linux.misc,comp.os.linux.setup
Subject: Re: Filesize larger than 2 GB on Intel machines an Linux 2.0.36
Date: 1 Jul 1999 03:42:49 GMT
Reply-To: [EMAIL PROTECTED]
On Wed, 30 Jun 1999 18:50:05 -0700, Patrick Letovsky
<[EMAIL PROTECTED]> posted:
>Christopher Browne wrote:
>>
>> ext2 is quite capable of handling *filesystem* sizes considerably larger
>> than 2GB. (2TB rings a bell.)
>
>I read your page about the 32 bits architecture limitation, actually
>your page is very well documented for all kernel features.
>In my case, it is just for being able to create a tar file > 2gb, so if
>the only thing to do is to recompile tar under the 2.2.x with the latest
>GNU C compiler, that is not that big of a deal.
>But I still miss information about this patch itself, it can be in beta
>or alpha, I want to give it a try. I mount a RAID5 disk array on
>/dev/sda3, there, I only have backup files from other systems, and one
>of this file needs to be > 2Gb. I hope the patch doesn't involved to
>re-mkfs the partition.
>
>Any information on this unobtainable patch will be very appreciate.
The *killer* part isn't a kernel patch; it's the (probably nonexistent
at this point) GLIBC patch that is needed to support big files.
SAS Institute did a summit on this, and some of the "big name" UNIX
vendors do have API extensions to allow 64 bit file accessors on 32
bit platforms.
Note that this is anything but transparent; you really have to pick for
LIBC to either be 32-bit-oriented, or 64-bit-oriented, and *NOT BOTH
AT ONCE.*
The result of *that* is that if you want to have tar/cat/dd/...
support 64 bit access, you need to modify them as well as LIBC to use
the 64 bit API.
LIBC5 *definitely* doesn't support "big files," and I don't *think*
that GLIBC2 provides both APIs (e.g. - small&large file accessors) yet.
Net result:
Patches must be to *ALL* of:
a) Kernel,
b) LIBC,
c) Applications.
I'm certain that c) hasn't been done, which puts you Out Of Luck.
See: <http://www.sas.com/standards/large.file/x_open.20Mar96.html>
for more details on the API changes.
I do not know where the patch is.
--
Those who do not understand Unix are condemned to reinvent it, poorly.
-- Henry Spencer <http://www.hex.net/~cbbrowne/lsf.html>
[EMAIL PROTECTED] - "What have you contributed to free software today?..."
------------------------------
From: Howard Mann <[EMAIL PROTECTED]>
Crossposted-To: comp.os.linux.development.apps
Subject: Shared libs in Linux-Request for clarification
Date: 1 Jul 1999 05:30:48 GMT
Hi All,
I use Red Hat 5.0 and KDE 1.1.1. An attempt to install
a RPM package of "kexpress" failed with the following:
# rpm -Uvh kexpress-0.8.0-0.i386.rpm
failed dependencies:
libgdbm.so.1 is needed by kexpress-0.8.0-0
libpng.so.2 is needed by kexpress-0.8.0-0
libstdc++.so.2.9 is needed by kexpress-0.8.0-0
Using "locate" I have the following:
/usr/lib/libgdbm.so.2
/usr/lib/libgdbm.so.2.0.0
/usr/lib/libpng.so.0
/usr/lib/libpng.so.0.96
/usr/i486-linux-libc5/lib/libstdc++.so.27
/usr/i486-linux-libc5/lib/libstdc++.so.27.1.4
/usr/lib/libstdc++.a
/usr/lib/libstdc++.so
/usr/lib/libstdc++.so.2.7.2
/usr/lib/libstdc++.so.2.7.2.8
/usr/lib/libstdc++.so.2.8
/usr/lib/libstdc++.so.2.8.0
These are my questions:
1. Why do I have so many versions of these libs ?
Are any obviously superfluous ?
What are the essential differences between them?
How and why are new versions continuously developed ?
2. If I obtain the new versions I apparently need, will
I run into conflicts with those currently installed?
Will a "forced" installation cause other programs I have
to become non-functional ?
3. If I install them with RPM packages, what command should I use ?
4. What other general considerations should I be aware of ?
As a non-programmer, I would appreciate a clarification concerning
the development and use of shared libs in Linux. I find this area
pretty confusing :-(
Thanks a lot .
Howard Mann.
================== Posted via SearchLinux ==================
http://www.searchlinux.com
------------------------------
From: [EMAIL PROTECTED] (Christopher B. Browne)
Subject: Re: A New File System Install
Reply-To: [EMAIL PROTECTED]
Date: Thu, 01 Jul 1999 05:57:32 GMT
On Thu, 1 Jul 1999 20:37:21 +0900, Ilhoon,Shin <[EMAIL PROTECTED]> posted:
>Our project team are willing to develop a new file system in LINUX.
>
>So, we must know how to install the developed file system into linux.
>For example, if we have the developed source files and object files, then,
>what should we do next?
The sources for ext2 and several other FSes are included with the source
tree, which means that represents a half-decent example of this.
Perhaps better still would be to look at Reiserfs, which is presently
handled via kernel patches, which should resemble what you're doing.
<http://devlinux.com/namesys/>
--
Those who do not understand Unix are condemned to reinvent it, poorly.
-- Henry Spencer <http://www.hex.net/~cbbrowne/lsf.html>
[EMAIL PROTECTED] - "What have you contributed to free software today?..."
------------------------------
Date: Wed, 30 Jun 1999 16:42:58 +0000
From: Bryan <[EMAIL PROTECTED]>
Crossposted-To: comp.os.linux.misc,comp.os.linux.networking,comp.os.linux.security
Subject: Re: Remote login problems in custom RedHat env...
Jon Skeet wrote:
>
> [EMAIL PROTECTED] wrote:
>
> > I have an unusual problem with telnet, rlogin, ftp and any other
> > program which requires logging in remotely. The system specs are: 400Mhz
> > Pentium Pro, 256MB RAM, onboard Intel etherexpress pro 10/100Mbs network
> > card, 2 serial ports, running a custom Red Hat 5.2 kernel. Four kernel
> > header files were modified to allow for a 3072 process limit ( fs.h,
> > limits.h, posix_types.h, /usr/include/gnu/types.h ). The machine will
> > boot and run fine for about 10 minutes then any form of remote log in
> > (even rcp and rsh) will hang after it successfully connects to the
> > system just before it gives you the opportunity to provide your login
> > name and/or password. On telnet you can even see the "Connected to
> > <host>" message. Any connection made before this problem occurs is fine
> > and has full capabilities. I can get out of the box using any method I
> > choose (telnet, ftp, etc). The oddest thing about this problem is that
> > all other inetd services are unaffected. They continue to respond to
> > request on their respective ports without fail. A tcpdump on the machine
> > will show telnet, rlogin, etc ... activity. They send their initial acks
> > and replies but don't complete their initialization procedures.
>
> Is it feasible that the problem is in reverse host lookup? I know telnetd
> checks that the host that is telnetting to it is valid before going ahead
> with the connection; it's possible that rcp does the same. If so,
> possibly your DNS is going wrong...
>
I agree; it could be reverse DNS or no DNS at all.
Another idea: Network card burps...
How much activity is there once the system is up? I had a Netgear
10/100 card in my box with one of the original DEC tulip chips (they've
since created their own proprietary set due to DEC's discontinuation of
the 21something series), and it would come up with some overrun problems
at high NFS loads. I finally swapped it with a newer one I had bought
for a Windows box, and the old card works fine in the Windows box, and
the new one works beautifully in the Linux box (gotta love 100Mbps).
(Probably some inconsistencies with the tulip driver and that older
chipset..)
.
Which kernel version are you using? You can use the 2.2.x kernel series
on Redhat 5.2. A custom RedHat 5.2 kernel sounds like you used th
2.0.36 kernel that came with it.
2.2.5 runs really stable on three of my 5.2 machines. I'm suggesting a
kernel and network card driver upgrade because even if you turn off
networking, like you said you're doing, the card may still be on the
fritz, and there may be a compatibility issue with the EtherExpress
Pro. (Is that intel or 3com? 3com's drivers were semi-broken in
2.0.36...)
> --
> Jon Skeet - [EMAIL PROTECTED]
> http://www.pobox.com/~skeet/
-- Bryan Scott
-- CTR Online Systems Administration
(remove the NOSPAM. for email)
------------------------------
From: [EMAIL PROTECTED] (Christopher B. Browne)
Crossposted-To: comp.os.linux.development.apps,comp.os.linux.networking
Subject: C++ templates: More than Turing Complete?
Reply-To: [EMAIL PROTECTED]
Date: Thu, 01 Jul 1999 05:57:31 GMT
On Thu, 01 Jul 1999 12:32:15 +1200, Bruce Hoult
<[EMAIL PROTECTED]> posted:
>In article <7lcref$8tn$[EMAIL PROTECTED]>, [EMAIL PROTECTED]
>(Nathan Myers) wrote:
>> They allow construction of
>> libraries that cannot be constructed in any other language.
>
>That's an *extremely* strong statement.
>
>Can you provide an example? I'd like to take a wack at it in another language
I tend to agree. This has the feeling of being a hyperbolic statement
to claim an advantage likely to be true only if "any other language" is
defined as being "any language in the set {C, Pascal}."
--
Those who do not understand Unix are condemned to reinvent it, poorly.
-- Henry Spencer <http://www.hex.net/~cbbrowne/lsf.html>
[EMAIL PROTECTED] - "What have you contributed to free software today?..."
------------------------------
From: [EMAIL PROTECTED] (Peter Samuelson)
Crossposted-To: alt.os.linux,comp.os.linux.advocacy,comp.os.misc,comp.unix.advocacy
Subject: Re: TAO: the ultimate OS
Date: 1 Jul 1999 01:38:51 -0500
Reply-To: Peter Samuelson <[EMAIL PROTECTED]>
[Vladimir Z. Nuri <[EMAIL PROTECTED]>]
> > I already see signs the essay is influencing ppl.. like I say the
> > initial object is to spread memes.
[void <[EMAIL PROTECTED]>]
> An initial object! I see you're finally willing to start defining a
> class hierarchy. ;-)
ROTFL. Thanks for the biggest laugh of the day.
(OK, so today has been relatively humorless, as days go, but still
... that was a good one.)
--
Peter Samuelson
<sampo.creighton.edu!psamuels>
------------------------------
From: "Thomas Steffen" <[EMAIL PROTECTED]>
Crossposted-To: comp.os.linux.development.apps,comp.os.linux.networking
Subject: Re: Why not C++
Date: 01 Jul 1999 09:10:27 +0200
Johan Kullstam <[EMAIL PROTECTED]> writes:
> some would say static typing is a burden.
they have to be ignorants. types are one of the most important
software engineering aspects (and this is not my private opinion).
would you drive a car where you don't know whether the brakes work, or
exist at all? no. but you would run a program where you don't know
that the types are compatible, yes?
static (or compile time) typing has two key advantaged:
a) type checking at compile time (and checking should be done as early
as possible. of course design time would be better...)
b) speed. knowing the type means optimisation is possible, maybe even
the dispatch is possible to infer.
if you don't like this, you can use interfaces and RTTI, which gives
you all the flexibility there is, while still doing some type checks
at compile time.
--
linux, linuctis - f, das beste Betriebssystem ;-)
------------------------------
From: Markus Pietrek <[EMAIL PROTECTED]>
Crossposted-To: comp.os.linux.development.apps
Subject: Re: Shared libs in Linux-Request for clarification
Date: Thu, 01 Jul 1999 06:51:24 +0000
Howard Mann wrote:
> /usr/lib/libstdc++.a
> /usr/lib/libstdc++.so
> /usr/lib/libstdc++.so.2.7.2
> /usr/lib/libstdc++.so.2.7.2.8
> /usr/lib/libstdc++.so.2.8
> /usr/lib/libstdc++.so.2.8.0
>
> These are my questions:
>
> 1. Why do I have so many versions of these libs ?
> Are any obviously superfluous ?
> What are the essential differences between them?
> How and why are new versions continuously developed ?
/usr/lib/libstdc++.so is a symlink to /usr/lib/libstdc++.so.2.7.2 is a symlink
to /usr/lib/libstdc++.so.2.7.2.8
So you can easily upgrade minor versions of the libraries and don't have to
recompile them. And you don't have to change your Makefiles.
/usr/lib/libstdc++.a is the library for static linking.
>
> 2. If I obtain the new versions I apparently need, will
> I run into conflicts with those currently installed?
you can install libstdc++.so.2.9, but check that no symlink from libstdc++.so to
libstdc++.so.2.9 is created.
If the minor number is changing (from 2.7.2 to 2.7.3), you can remove the older
lib (they are only bugfixed). But if the version number is changing from 2.7 to
2.8, you have two incompatible libraries, so you must recompile the programs to
use 2.8.
--
Markus Pietrek
------------------------------
From: [EMAIL PROTECTED] (Peter Samuelson)
Subject: Re: WHAT ARE THESE TERMS SUPPOSE TO MEAN
Date: 1 Jul 1999 02:54:38 -0500
Reply-To: Peter Samuelson <[EMAIL PROTECTED]>
[Christopher Boyd <[EMAIL PROTECTED]>]
> BTW, 'jiffies' is an unsigned long, meaning it'll wrap in about 1.3
> years on a 32bit machine :-)
Hmmm, I guess I never thought of this before, but ...
Perhaps this explains why only the Alpha arch uses a higher clock rate
by default. For years it was the only arch where jiffies was more than
32 bits, so the faster wraparound wouldn't be a problem.
Recall that it was only quite recently -- very late in the 2.1 devel
cycle -- that Alan (and others?) set out to chase down the jiffies
wraparound problems. (Reminds me somewhat of a y2k effort: it doesn't
matter a bit now, but it's only a matter of time before someone's
jiffies will wrap around....)
Now that jiffies wraparound has hopefully been nailed, it's much safer
to re-#define HZ. ALTHOUGH I bet there are still lingering bugs with
drivers that say `foo' while meaning `(foo*100)/HZ' or `(foo*HZ)/100'.
(Some Alpha owners are understandably a little touchy about this sort
of discrimination....)
--
Peter Samuelson
<sampo.creighton.edu!psamuels>
------------------------------
From: [EMAIL PROTECTED] (Nathan Myers)
Crossposted-To: comp.os.linux.development.apps,comp.os.linux.networking
Subject: Re: C++ templates: More than Turing Complete?
Date: 1 Jul 1999 01:57:18 -0700
Christopher B. Browne <[EMAIL PROTECTED]> wrote:
><[EMAIL PROTECTED]> posted:
>>(Nathan Myers) wrote:
>>> [C++ templates] allow construction of
>>> libraries that cannot be constructed in any other language.
>>
>>That's an *extremely* strong statement.
>
>I tend to agree. This has the feeling of being a hyperbolic statement
>to claim an advantage likely to be true only if "any other language" is
>defined as being "any language in the set {C, Pascal}."
The convention in some communities is to ignore performance
and engineering rigor. Certainly anything can be achieved in
assembly language (or in T-code, if you like) that can be achieved
with a C++ _program_, given infinite time and coding effort.
Given the constraints of a sensible _library_ interface and
equivalent-to-machine-code performance, C++ achieves what
other languages haven't, yet.
Of course some other languages will achieve parity, someday, but
only those designed by people who fully understand the strengths of
standard C++. Maybe such a language will even succeed in avoiding
its weaknesses.
--
Nathan Myers
[EMAIL PROTECTED] http://www.cantrip.org/
------------------------------
From: Stephan Houben <[EMAIL PROTECTED]>
Crossposted-To: comp.os.linux.development.apps,comp.os.linux.networking
Subject: Re: Why not C++
Date: 01 Jul 1999 11:41:10 +0200
[EMAIL PROTECTED] (Greg Comeau) writes:
> In article <[EMAIL PROTECTED]> Stephan Houben <[EMAIL PROTECTED]>
>writes:
> >Templates in C++ solve a problem that simply doesn't exist in most other modern
> >programming languages. The fact that it exists in C++ is due to the fact that C++
> >is based on C.
[apparently insufficient example snipped]
> >IMHO, C++'s templates are a useful hack to repair a basic flaw in C's type system.
> >However, there are certainly much more elegant solutions.
>
> I don't follow. I simply don't follow. First you say stuff like
> that templates in C++ solve a problem that doesn't exist in other
> languages, and then go on to show generic capabilities of other
> languages. That's contradictory.
>
No it's not. (It is! Is not! Is! ... ;-) )
Let me try to rephrase this again. I see two different things:
1. The capability to create a function that will operate in a
similar way on arguments.
This capability is often called `generosity'.
2. The way this capability is available in C++, i.e. through templates.
Generosity is very important. However, in a language like Haskell
generosity is "built in" into the type system in a very regular
way. In C++, it is tacked on to the existing C type system.
This means that a template in C++ is something "special":
1. you have to indicate it with the word `template'
2. you have to make its definition available via header files everywhere
it is used (OK, there are other tricks, and some compilers have a
"template repository", but you can't really rely on that if you
want to remain portable)
3. you cannot make a generic variable type: something like:
template <class X>
static X x;
is not possible.
4. Every "instance" of a template behaves as if it was a separate
object, instead of being the same object applied to different types.
So for these reasons, I think that C++ templates are indeed a "kludge".
> It's no secret that I'm very much into C++. However, I ALWAYS
> want to learn more about how other langs do stuff.
Then stop posting here and take a look at *real* generosity
in a language like Haskell or ML.
If you did this, then you would realize that "templates" are only
the shadow on the wall of a much more powerful and elegant system,
namely an ML-style type system.
> But I keep
> seeing posts like above, which attack C++ and then don't clearly
> show alteratives. Come on, I'm all psyched up for something hard core.
Well, if a three line program doesn't convince you, I can sympathise with that,
but sorry I'm not going to copy the whole Haskell tutorial here verbatim.
Go get it yourself at http://www.haskell.org .
Greetings,
Stephan
------------------------------
From: Stephan Houben <[EMAIL PROTECTED]>
Crossposted-To: comp.os.linux.development.apps,comp.os.linux.networking
Subject: Re: Why not C++
Date: 01 Jul 1999 11:44:36 +0200
[EMAIL PROTECTED] (Mike McDonald) writes:
> In article <7ldsrt$cb2$[EMAIL PROTECTED]>,
> [EMAIL PROTECTED] (Nathan Myers) writes:
> > Stephan Houben <[EMAIL PROTECTED]> wrote:
>
> >>Templates in C++ solve a problem that simply doesn't exist in most
> >>other modern programming languages. The fact that it exists in C++ is
> >>due to the fact that C++ is based on C.
> >
> > False. They solve a problem that exists because C++ offers static
> > typing, a feature of profound importance for rigorous engineering.
> >
>
> FUD!!
I wanted to say it myself, but you'be beaten me to it...
Haskell and ML are *completely statically type-checked*.
(Unlike C++ templates, which are only marginally checked when
parsed, and only fully checked when finally instantiated.)
The fact that the compiler can derive all those tedious type declarations
for you only eliminates one further source of human error.
Greetings,
Stephan
------------------------------
From: "Jean-Christophe Dhellemmes" <[EMAIL PROTECTED]>
Crossposted-To: comp.os.linux.networking
Subject: vt100 documentation and parsing
Date: Thu, 1 Jul 1999 10:17:57 +0200
I am trying to write a program that needs to parse vt100/ansi terminal
escape sequences. Any pointer to the full vt100/ANSI escape sequences
technical documention and/or any parsing source code would be greatly
appreciated.
Thanks in advance.
Jean-Christophe Dhellemmes
SISRO, SA (www.sisro.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: [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
******************************
