Linux-Development-Sys Digest #564, Volume #6 Fri, 2 Apr 99 01:14:58 EST
Contents:
Compiling 2.2.4, error in kernel/acct.c (Bernd Strieder)
kernel-upgrade (Svein K Svendsen)
No Spam!!! 4672 ([EMAIL PROTECTED])
Re: how to use gettimeofday() ("G. Sumner Hayes")
Re: Neal Stephenson does the car metaphor (Christopher B. Browne)
Re: Programming tools for Linux/Unix: Editor, IDE, Frontend to GCC. (Dan Mercer)
Re: Proposal: "Linux 2000 Platform" (Christopher B. Browne)
Re: Idea: Make a seperate "i686" tree for Redhat Linux 6.0 (Christopher Browne)
Re: Programming tools for Linux/Unix: Editor, IDE, Frontend to GCC. ("Wesley W.
Garland")
Re: Proposal: "Linux 2000 Platform" (Christopher Browne)
Re: Kernel 2.3 when? (Christopher B. Browne)
Re: [ANN] CodeWarrior for Red Hat Linux (Kendall Bennett)
Re: 4 Gb memory? (Robert Krawitz)
Re: clone() or PThreads ??? ("G. Sumner Hayes")
----------------------------------------------------------------------------
From: Bernd Strieder <[EMAIL PROTECTED]>
Subject: Compiling 2.2.4, error in kernel/acct.c
Date: Thu, 25 Mar 1999 19:08:21 +0100
Hi,
compiling 2.2.4 there is a stop at:
gcc -D__KERNEL__ -I/usr/src/linux/include -Wall -Wstrict-prototypes -O2
-fomit-frame-pointer -pipe -fno-strength-reduce -m486 -malign-loops=3D2
-malign-jumps=3D2 -malign-functions=3D2 -DCPU=3D586 -c -o acct.o acct.c=
acct.c: In function `sys_acct':
acct.c:197: too few arguments to function `filp_close'
acct.c:203: too few arguments to function `filp_close'
make[2]: *** [acct.o] Error 1
make[2]: Leaving directory `/usr/src/linux-2.2.4/kernel'
make[1]: *** [first_rule] Error 2
make[1]: Leaving directory `/usr/src/linux-2.2.4/kernel'
make: *** [_dir_kernel] Error 2
forelle278:/usr/src/linux # =
My Linux is SuSE 6.0, unmodified, Kernel 2.2.2 running for some weeks
without
problems.
I=B4ll give a try without system accounting activated, hope it works then=
=2E
Bye,
Bernd
------------------------------
From: Svein K Svendsen <[EMAIL PROTECTED]>
Subject: kernel-upgrade
Date: Fri, 02 Apr 1999 01:29:55 +0200
When upgrading my rh5.2 with a new kernel I can't find a way to
create a new
module-info-new_kernel file. Everything seems to work as long as I
remove
the "preferred" pointer in /lib/modules/ , and don't make a new one .
Can anybody please help me out.
Svein S,
------------------------------
From: [EMAIL PROTECTED]
Crossposted-To:
comp.os.linux.advocacy,comp.os.linux.development,comp.os.linux.development.apps
Subject: No Spam!!! 4672
Date: 2 Apr 1999 01:55:54 GMT
At Last! A Truly Moderated Safe Email list!
Get your message out to thousands without spamming! Lucrative two tier reseller option.
http://dalesafe.com/index.cgi/AK1433
lchcivdjeolzomnvlyutinsizufgmxsobxsrsxwywwdhczmbjm
------------------------------
From: "G. Sumner Hayes" <[EMAIL PROTECTED]>
Subject: Re: how to use gettimeofday()
Date: Thu, 01 Apr 1999 21:17:21 -0500
lea wrote:
>
> I'm having trouble with a uni assignment, I need to use gettimeofday()
> and add the seconds field from the timeval struct into a file. The
> call to gettimeofday seems to work, no compiler errors, but when I try
> to access the tv_sec field the compiler says that I am trying to
> access member 'tv_sec' in something that is not a structure or union.
> Can anyone out there help me?
You didn't post any code, so it's hard to help.
I'd expect that the problem is that you're trying to access member
'tv_sec' in something that is not a structure or union -- most likely
a pointer to a struct timeval. Try dereferencing before trying to
take a member. (ie -> instead of .)
Luck,
Sumner
------------------------------
From: [EMAIL PROTECTED] (Christopher B. Browne)
Crossposted-To: comp.sys.next.advocacy
Subject: Re: Neal Stephenson does the car metaphor
Reply-To: [EMAIL PROTECTED]
Date: Fri, 02 Apr 1999 04:28:45 GMT
On 1 Apr 1999 21:21:26 -0500, Alexander Viro <[EMAIL PROTECTED]> posted:
>In article <6hVM2.5240$[EMAIL PROTECTED]>,
>Christopher Browne <[EMAIL PROTECTED]> wrote:
>>The initial point of it is to build a FS using balanced trees, which
>>should provide improved performance for small files and for various
>>sorts of directory accesses.
>>
>>Proposals came over the wire to build something into it like unto the
>>upcoming NT "multiple resource forks in a file" thing. (*Manifestly*
>>not an NT innovation; somewhat more like the OS/2 Extended Attributes.)
>>
>>Controversy immediately arose for much the reasons suggested; the most
>>useful *concrete* comment was that people often mount filesystems using
>>NFS, which means that any functionality that can't be expressed "over
>>NFS" will get lost/ignored.
>
>... and not the first time. BTW, you've messed the history part - Genera
>had equivalents of forks/files-as-objects *waaaay* before OS/2.
I'm sure there are other examples; I'm citing OS/2 as an example
people may be more likely to be familiar with. I *think* it was more
widely deployed than Genera, right?
>As for the only concrete argument - I'ld beg to differ. There is tar, for
>example. There is a lot of other applications that will be very unhappy
>over that.
Looking back at the email from Stephen Tweedie and Hans Reiser, NFS is
what Stephen Tweedie first cited as example, and spent the most bits
on. He did mention cp/tar/ls, but spent a more bits talking about
NFS.
>>Arguments that UNIX "ought" to offer additional functionality relating
>>to filesystems pretty forcibly requires that there be some way of doing
>>this across networks, which means that changing APIs to the point to
>>which NFS isn't enough until something demonstrably better is
>>*deployable* (e.g. - CODA or AFS-like schemes) is just not going to
>>happen.
>
>Not to mention the fact that neither CODA nor AFS support the thing...
[Chris waves his hands wildly, assuming that *some* networked
filesystem access protocol would have to be constructed to support
exporting the added functionality... Sans protocol, it's a mite
difficult to make the functionality widely usable...]
>[snip]
>>>> In part, quite true. It's also why Unix has never taken over the world: it
> Since when did we go insane and decided to "take over the world"?
>>>> spends its time fragmented between 50 different versions, all almost, but
>>>> not quite, compatible. It's happening to Linux as we speak: I suspect it
>>>> won't be long before we see distro-specific programs.
>
>Lusers are everywhere. Wait until hordes of "I've read VB for dummies
>and now I'm a programmer" wankers will "port" their turdl^Wproducts. The
>you'll definitely see it.
There's some; the fact that all the distributions are using basically
the same sets of underlying software that are being upgraded by the
same development teams diminishes the ongoing importance of the
problem.
After all, there's not a "Red Hat Perl," or a "Caldera GCC," or a
"SuSE GLIBC." They may pick particular versions for a release, but
they're largely using software produced outside the purview of the
distribution maker.
Effectively, if the app breaks moving between Red Hat 5.2 and SuSE
6.0, it's reasonably likely that it will also break moving from Red
Hat 5.2 to Red Hat 6.1.
I don't want to understate the issue, but the extreme positions of "No
problem at all!" and "Linux is about to fragment!" are both not overly
tenable.
GNOME is probably a decent test of the issue; it involves a whole
*pile* of interconnected components, and is, at present, a *PAIN* to
get installed and working due to the manifold interdependancies.
(*How* many libraries is that?@!%!)
If they can get BABOON (GNOME's "compound document" scheme) to run on
Caldera, Red Hat, Debian, SuSE, Solaris, and AIX, then I suggest that
the issue of distribution-specificness may be considered overrated.
It doesn't exist yet, so this is a future prediction...
>>The only place where persistent fragmentation *may* *ARGUABLY* be
>>happening is with the "system administration" tools, where Red Hat is
>>sponsoring one project (Linuxconf), and Caldera another (COAS).
>
>... and in the area of *real* package management (real == behind the UI;
>place completely ignored by most of wank^advocates).
Despite my comments earlier, I'd argue that there's *really* only two
associated with Linux that anybody is doing anything about, RPM and
DPKG. It's really not clear that much that is fundamental is
happening with RPM, despite there being *some* traffic on
linux.redhat.rpm...
>[snip]
>>There's not One True Linux Distribution, which means that if an asteroid
>>strikes North Carolina, thus destroying Red Hat Software, or Microsoft
>>decides to vaporize Provo, Utah so as to eliminate Novell *and* Caldera
>>in one fell swoop, or if Godzilla eats the city in Japan where
>>TurboLinux development takes place, none of these events forcibly
>>demolish Linux development.
>
>Erm... I suspect that the first variant would have much more
>interesting consequences ;-/
>
>[big snip]
>>>This wasn't supposed to be a discussion of security, but rather a
>>>discussion of priorities and values. I'm not really a security expert...
>>
>>Security is starting to become more of an issue as it becomes easier and
>>easier to establish connections between computers.
>>
>>The unfortunate problem is that building secure systems presently
> ^^^^^^^^^^^
> intrinsically
>>requires system administrators that *understand security.* That leaves
>>the naive home user of Windows 98 completely out in the cold.
Good call.
It is quite fair to say "building secure systems intrinsically
requires administrators who truly understand how to build secure
systems."
This needs to include an understanding of how to pick things like OS
platforms, because a secure system requires constructing it out of
sufficiently robust components.
--
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] (Dan Mercer)
Crossposted-To:
comp.os.linux.advocacy,comp.os.linux.development.apps,comp.os.linux.help,comp.unix.programmer
Subject: Re: Programming tools for Linux/Unix: Editor, IDE, Frontend to GCC.
Date: 2 Apr 1999 00:07:39 GMT
In article <[EMAIL PROTECTED]>,
Nix <$}xin{[email protected]> writes:
> [EMAIL PROTECTED] (Dan Mercer) writes:
>
>> and nedit has a very sane macro language, recordable macros, and
>
> I'm sorry, but compare that to Lisp; one a complete, general-purpose
> language with a consistent semantics, rigorous mathematical backing,
> carefully formalised language definition[1], elegant syntax[3] and a longer
> pedigree than any other computer language save FORTRAN; and the other
> language a single-editor nonportable special-purpose extension language.
>
Elegant? I've never heard it called that before. The question is,
why should I have to learn Lisp to get the most out of my editor?
With nedit, you can point and click your way to most macros -
you only need the macro language if you want to take it one step
further. And it's simple enough to learn in an hour. I just want
to edit, for gosh sakes, not run email, read news, or any of the
10,000 other things emacs is built for. I don't want to have to
remember that much stuff - remember, I have a real job. I've
known some emacs users who spend as much time playing with it as
they do editing - that's a real performance issue. But I'm not
going to argue with you about your choice - you probably have a lot
of mental investment in it. I don't argue with anyones editing
choices. The learning curve for vi is steep, for emacs even
steeper. The learning curve for nedit is gentle, but it's a
very powerful editor nonetheless. People should look at all 3
and decide for themselves. I use vi and nedit pretty interchangeably.
About 60% of my editing is actual typing, which I doo very slowly.
The other 40% is either grabbing a template (one keystroke), calling
up manfiles (one keystroke), or copying and pasting. And that's
where nedit really shines, with block moves and copies, the
ability to swap two data items, etc.
> I know which wins in *my* book. This cannot be defined as an advantage
> on the part of nedit. No matter how good a special-purpose langauge is,
> it is almost beyond the bounds of possibility that it is as good as
> lisp.[2]
It doesn't have to be. It only has to be good enough to get the
job done, which nedit does.
--
Dan Mercer
[EMAIL PROTECTED]
>
> [1] when Scheme takes over from elisp, that is
>
> [2] god, I'm starting to sound like Klaus. I'll calm down, honest ;)
>
> [3] if not *easily readable* syntax, see my earlier post :(
>
Opinions expressed herein are my own and may not represent those of my employer.
------------------------------
From: [EMAIL PROTECTED] (Christopher B. Browne)
Crossposted-To: alt.os.linux,comp.os.linux.advocacy,comp.os.linux.misc
Subject: Re: Proposal: "Linux 2000 Platform"
Reply-To: [EMAIL PROTECTED]
Date: Fri, 02 Apr 1999 04:28:46 GMT
On 1 Apr 1999 21:34:22 -0500, Alexander Viro <[EMAIL PROTECTED]>
posted:
>In article <[EMAIL PROTECTED]>,
>>I suggest dpkg instead, it's a bit more, shall we say, 'advanced'.
>
>Seconded, with possible ports integration.
Unfortunately, the flaming of Red Hat by those of the Slackware
Religion acts as an anodyne, distracting people from the possibility
that there might be ideas out there that are better than either
system's approach.
The fixation on RPM, with occasional vague mention of dpkg, betrays a
generally vast ignorance of the various packaging methods that in use.
Almost certainly Ports and the Debian tools represent something closer
to the "state of the art" than does RPM.
Anyone for stow? Depot? NSBD?
Note that RPM would be a whole lot more usable if there was something
functionally equivalent to Debian's APT and dselect tools...
>>(I use Slackware, and I don't use ANY package managers ;)
>
>>> . GNU make, C/C++ compiler and development libraries
>
>>Well, DUH! ;)
I disagree, slightly. POSIX make is a more unambiguously requirable
option.
>>> . XFree86 installed to /usr/X11R6/lib (or /usr/X11)
>
>Optional. Install libs if you are so inclined, but server and
>applications do not belong to required part.
>
>>Or both, thanks to the wonders of sym-links.
>
> Exactly.
Absolutely.
>>>Optional components:
>>> . Web browser (Netscape or Mozilla variation?)
>
>Or lynx, or any other browser. What's the difference for 3-rd party
>applications?
If trying to establish a standard, shouldn't the product picked be
require to conform to some standards? :-).
--
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] (Christopher Browne)
Crossposted-To: comp.os.linux.misc,linux.redhat.misc
Subject: Re: Idea: Make a seperate "i686" tree for Redhat Linux 6.0
Reply-To: [EMAIL PROTECTED]
Date: Fri, 02 Apr 1999 04:29:53 GMT
On Wed, 31 Mar 1999 19:22:09 +1200, Enkidu <[EMAIL PROTECTED]> wrote:
>Johan Kullstam wrote:
>> Enkidu <[EMAIL PROTECTED]> writes:
>> > Bloatware. I suppose you'd go for it if someone were to meet you
>> > at the door of the supermarket, sent you round to the exit, and
>> > insisted that you take a trolley, packed the way that *they*
>> > decide is best.
>>
>> no one makes you install these things.
>>
>No indeed, but lots of people do. Lots of people also install
>Microsoft products too.
>
>All RedHat does is pull together a consistent set of stuff so that
>people don't have to do it themselves. That's good. But to suggest
>that they actually add value apart from that is rubbish.
Obviously so.
<sarcasm> The code that they wrote that is included with their
distribution as well as others is obviously rubbish. </sarcasm>
>> there is a pristine source in the source rpm along with
>> redhat's patches which are distinct diff files. you can still
>> apply your own patches. you can remove the redhat patches.
>>
>Indeed you can, unless you are prepared to take the risk of losing
>some feature in the process! You could, of course, look at the
>diffs, look at your patch (which you may have got elsewhere), and
>try to figure out what will fit and what you want and what will
>really happen. Great fun, I'm sure.
<sarcasm>
Doubtless it's much more difficult than the alternatives:
a) Try to decompile binary packages where *no* source code for the
patches is available,
or
b) Check out a pristine copy of sources, put it into RCS/CVS, take a
"non-pristine" copy, do a mass diff, and, remarkably, get as the
primary result, a patch file that is likely to be isomorphic to the
patch file that comes with the RPM .src.rpm file.
</sarcasm>
>> yes there are. no one makes you use redhat. if you do not
>> care for redhat, do not use it. redhat does have actual
>> problems. i challenge you to find them and not just make up
>> random lies.
>>
>I'm sorry that I am nor a follower of the One True Red Hat
>religion. I challenge you to point out where I lied. For what it
>is worth, I've not had any problem with my copy of Redhat. It's
>pretty neat so long as you don't mind being led by the nose.
The only religiousity that I tend to see tends to be expressed by those
that consider Red Hat to be an expression of Infidel Use of Linux.
Funny, that.
--
"Instant coffee is like pouring hot water over the cremated remains of a
good friend."
[EMAIL PROTECTED] <http://www.hex.net/~cbbrowne/lsf.html>
------------------------------
From: "Wesley W. Garland" <[EMAIL PROTECTED]>
Crossposted-To:
comp.os.linux.advocacy,comp.os.linux.development.apps,comp.os.linux.help,comp.unix.programmer
Subject: Re: Programming tools for Linux/Unix: Editor, IDE, Frontend to GCC.
Date: Wed, 31 Mar 1999 22:28:37 -0500
Amy
Amy Bellows wrote in message <[EMAIL PROTECTED]>...
>Does anyone (but me) use Pico?
Sure, lots of fresh-out-of-university kids. If they work here,
though, they either use our customized XEmacs voluntarily, or
are thoroughly beaten, and asked what editor they'd like to
use again.
(Isn't recursion wonderful?)
Cheers,
Wes
--
Wesley W. Garland���������������� | Email: [EMAIL PROTECTED]���
Director, Product Development���� | Pager: [EMAIL PROTECTED]
PageMail, Inc.������������������� |
Kingston, ON Canada�������������� | Voice: (888) 247 6246
------------------------------
From: [EMAIL PROTECTED] (Christopher Browne)
Crossposted-To: comp.os.linux.advocacy,comp.os.linux.misc
Subject: Re: Proposal: "Linux 2000 Platform"
Reply-To: [EMAIL PROTECTED]
Date: Fri, 02 Apr 1999 01:43:24 GMT
Before making any substantive remarks, it is important to preface with
an *IMPORTANT* remark.
It is, generally speaking, potentially a *REALLY DUMB IDEA* to announce
a new project on April Fools Day.
Now that I've got that off my chest...
a) Lose the name.
- "Linux 95" was released about 7 months before Windows 95, so we've
successfully pulled that prank already.
- The start of the millennium is 2001, so something "millenial"
shouldn't involve 2000; "2000" is a number that has been reserved for
advertising of snake-oil-like products for many years now.
b) Normative, not descriptive.
When you say "standard locations for configuration files," that
represents a normative rule that can be unambiguously evaluated, not
unlike FHS.
The other "stuff" represents something more like: "I want to create a
new distribution, and here's the feature set!"
Give us things that can be evaluated as correct/incorrect; for the
purposes of commercial vendors, that *is* what they need to have.
They *need* to have environmental assertions that can be validated as
right or wrong.
c) Solve the *actual* problem at hand.
There have been *piles* of attempts to try to establish things like
"SEUL," "Project Independence," and the like, where people have decided
that they just *had* to start from scratch and create a Brand New
Distribution to solve all the world's problems.
The problem here that needs to be solved is *NOT* a "we need a new
distribution" problem.
It is a "Quality Assurance," "we need to make sure the distributions
that exist are done right" problem.
To that end, the *right* answer is to build some tools to help validate
distributions against LSB, which is the most appropriate test that I'm
aware of with respect to a distribution.
<ftp://ftp.xopen.org/pub/lsb/test/>
<http://www.opengroup.org/testing/lsb-fhs/>
are sites documenting what "test suite" information exists at this
point for LSB.
It doesn't much matter fundamentally whether validation is done using
code written in C, Guile, TCL, Perl, or, for that matter, cfengine.
An *appropriate* thing to do is to build some test suite support code to
measure the degree of compliance/noncompliance of distributions with
whatever standards prove useful to verify.
It would be *entirely* sensible for this to include some things like: -
Taking a sample binary generated on one distribution, and making sure
that it works correctly on another.
- Adding in tests that exercise reported bugs. This can provide the
ability to do regression testing to ensure that future versions of
software don't re-break things that get fixed.
- *Certainly* add in some tests to exercise how well library integration
is working. If a new EGCS/GLIBC combination breaks everything, we'd
want to know that, right?
The problem that vendors are having is that it's a lot of work to
*verify* that software will work on multiple distributions.
Give them a useful testing framework, and pass distributions through
such a framework, and this can provide useful bug reports so that we
don't get "bozo" releases of distributions that Just Plain Don't Work.
But we don't need a new "Linux 2000" distribution to do this.
--
"You're one of those condescending Unix computer users!"
"Here's a nickel, kid. Get yourself a real computer" - Dilbert.
[EMAIL PROTECTED] <http://www.hex.net/~cbbrowne/linux.html>
------------------------------
From: [EMAIL PROTECTED] (Christopher B. Browne)
Subject: Re: Kernel 2.3 when?
Reply-To: [EMAIL PROTECTED]
Date: Fri, 02 Apr 1999 04:28:48 GMT
On Thu, 01 Apr 1999 21:09:05 -0500, G. Sumner Hayes
<[EMAIL PROTECTED]> posted:
>[EMAIL PROTECTED] wrote:
>> Subject says all. When is 2.3 going to be out?
>
>As soon as the developers don't spend all their time bug-hunting in
>2.2.x. It's still not completely stabilized yet (though I'm pleased
>at how much smoother the 2.2 series has been than the 2.0 series was).
>
>I expect Linus will get bored with 2.2.x soon enough and things will
>progress onward. It may be a couple more months, but probably not
>more than that.
Hopefully so.
>Remember, 2.0.x was up to about 2.0.20 before 2.1.0 forked off -- we're
>not even to 2.2.10 yet!
Hmmm. What was the timing like? Are we producing 2.2.x's faster than
we did 2.0.x's?
>> I keep hearing that there are supposed to be a lot of new and some old
>> 3rd party things to enter the kernel: hardware monitoring (from
>> lm_sensors2), 32 bit devices, uids, and gids, Pentium 3 support, raw
>> devices, and ext2fs undeletion and ACLs. And much more!
>
>Most of these ought to make it, but ext2fs undeletion is doubtful.
>ACLs are questionable but much more likely. (ext2fs undeletion will
>probably never exist; the bits were reserved, but in retrospect it's
>a problem better dealt with in userspace and Ted T'so has said as much
>on linux-kernel).
It seems likely to me that there is more likely to be an "ext3fs" than
there is an "augmented ext2fs."
By doing that, this allows:
--> Better regression testing where you can have both unmodified
ext2fs and "new stuff" running simultaneously;
--> Easier identification of whether or not you've *really* got the
new functionality;
--> The ability to have "safe" partitions using the current "stable"
functionality, and "experimental" partitions with K001 New Stuff.
>Capabilities, stable RAID, and journalling are the killer features for
>2.3.x, IMO.
I think we're going to see more than just one new filesystem; reiserfs
is now tracking kernel revisions, and seems to install pretty stably
(I've got my news "spool" running on it) on 2.2.x versions.
I think it would be a *super* thing for different groups to try some
different FS approaches, hopefully solidifying a few improvements to
VFS, and then having several "X-File Systems" that shake out into some
smaller number of *truly* improved FSes that may be attuned to
different purposes.
The other "killer feature" that I hope for is for EGCS to stabilize
(e.g. - to become the new GCC), and for C9X functionality to thereupon
provide us "portable" 64 bit values.
64 bit values buys us:
- Bigger-than-2GB files ("ext64fs," maybehaps?)
- Big dates (--> no more 2038 problem)
- Univerally-available 64 bit ints
--
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] (Kendall Bennett)
Crossposted-To: comp.unix.programmer
Subject: Re: [ANN] CodeWarrior for Red Hat Linux
Date: Wed, 31 Mar 1999 20:14:02 -0800
In article <[EMAIL PROTECTED]>,
[EMAIL PROTECTED] says...
> Bill Anderson wrote:
>
> > The LSB will not be dealing with package management. It focuses on
> > minimum included tools and libraries, as well as a certain directory
> > structure (last I saw).
>
> Oh great, so people producing COTS software still have to
> pick and choose between distributions. We'll still
> end up with a box that says "WP for RedHat Linux 5.2 i386"
> rather than "WP for Linux LSB 1.0 systems on processors
> of the Intel 386 architeture".
>
> I don't care what mechanism is used for package management,
> just as long as their is one distribution format, one
> install command, etc, etc.
I agree entirely with this. It appears that the Debian folks don't like
RPM and use their own package manager, and the Red Hat folks only want to
use RPM. I personally don't like RPM much (complicated to figure out for
the first time user), but if it is all hidden behind a nice GUI driven
installation program it doesn't really matter which one is used provided
all packages use the same one!
--
+----------------------------------------------------------------------+
| SciTech Software - Building Truly Plug'n'Play Software! |
+----------------------------------------------------------------------+
| Kendall Bennett | To reply via email, remove nospam from |
| Director of Engineering | the reply to email address. Do NOT send |
| SciTech Software, Inc. | unsolicited commercial email! |
| 505 Wall Street | ftp : ftp.scitechsoft.com |
| Chico, CA 95928, USA | www : http://www.scitechsoft.com |
+----------------------------------------------------------------------+
------------------------------
From: Robert Krawitz <[EMAIL PROTECTED]>
Subject: Re: 4 Gb memory?
Date: 31 Mar 1999 09:45:44 -0500
Stefan Monnier <[EMAIL PROTECTED]>
writes:
> >>>>> "Jakob" == Jakob Sigurdsson <[EMAIL PROTECTED]> writes:
> > My employer is considering buying a Linux Box with 4 Gb memory, we
> > are thinking of a Quad pentuim (Xeon) setup.
> > What is the max memory in linux?
>
> More than 2GB on a x86 is impractical. You can probably support upto 3GB on
> Linux but that reduces the max process size to 1GB. For 4GB,
> you want to look into Alpha or Sparc64.
This is only necessarily the case if you want all of RAM to be mapped
into virtual address space at all times. If one can live without
that, there's no reason for this to be true.
I think that for some reason there's still a limit of 1 or 2 GB on how
much RAM Linux can use on the Alpha, but I don't know the details.
--
Robert Krawitz <[EMAIL PROTECTED]> http://www.tiac.net/users/rlk/
Tall Clubs International -- http://www.tall.org/ or 1-888-IM-TALL-2
Member of the League for Programming Freedom -- mail [EMAIL PROTECTED]
"Linux doesn't dictate how I work, I dictate how Linux works."
--Eric Crampton
------------------------------
From: "G. Sumner Hayes" <[EMAIL PROTECTED]>
Subject: Re: clone() or PThreads ???
Date: Thu, 01 Apr 1999 20:55:58 -0500
Thomas Rink wrote:
>
> "G. Sumner Hayes" <[EMAIL PROTECTED]> writes:
>
> > 1. You cannot current lock shared memory into RAM on Linux.
>
> Really? This is from `man shmctl' (Kernel 2.0.36):
>
> In addition, the super-user can prevent or allow swapping
> of a shared memory segment with the following cmds: (Linux
> only)
>
> SHM_LOCK prevents swapping of a shared memory segment.
[SNIP]
>
> Or isn't this implemented yet?
According to what I was told (by Andi Kleen, kernel hacker) on this
group last week, it's not implemented yet. :(
(I need it for security purposes, not real-time, but the principle's
the same).
--Sumner
------------------------------
** 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
******************************
