Linux-Development-Sys Digest #563, Volume #6 Thu, 1 Apr 99 22:14:29 EST
Contents:
Re: Idea: Make a seperate "i686" tree for Redhat Linux 6.0 (Matthias Warkus)
Re: Programming tools for Linux/Unix: Editor, IDE, Frontend to GCC. (Nix)
do I need all libfoo.so.2.0.x , libfoo.so.2.1 (mack)
Re: Neal Stephenson does the car metaphor (Christopher Browne)
Re: Idea: Make a seperate "i686" tree for Redhat Linux 6.0 (Johan Kullstam)
Re: how are contributions to the linux development coordinated (David T. Blake)
Re: kernel-upgrade (David T. Blake)
how to use gettimeofday() ("lea")
Re: Programming tools for Linux/Unix: Editor, IDE, Frontend to GCC. (Klaus Schilling)
Re: Proposal: "Linux 2000 Platform" (Alexander Viro)
Re: Idea: Make a seperate "i686" tree for Redhat Linux 6.0 (wizard)
Re: clone() or PThreads ??? ("G. Sumner Hayes")
how are contributions to the linux development coordinated
([EMAIL PROTECTED])
Re: Kernel 2.3 when? (Frank Sweetser)
Re: [ANN] CodeWarrior for Red Hat Linux (Glen Turner)
----------------------------------------------------------------------------
From: [EMAIL PROTECTED] (Matthias Warkus)
Crossposted-To:
comp.os.linux.misc,linux.redhat.misc,alt.linux,alt.os.linux,comp.os.linux.hardware
Subject: Re: Idea: Make a seperate "i686" tree for Redhat Linux 6.0
Date: Thu, 1 Apr 1999 14:16:49 +0200
Reply-To: [EMAIL PROTECTED]
It was the Wed, 31 Mar 1999 19:22:09 +1200...
..and 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.
Of course they add value. The fact that all the diverse stuff is
working together smoothly is added value already. NB they throw in
stuff like a package management system, a bunch of configuration
utilities etc. etc. - in my book, this is added value.
mawa
--
When you look at yourself in an aberrational mirror, you see your real
self, looking back at the twisted you.
-- Dr. (?) Bob Miller, "The Aberrational View of the Universe",
Twisted Science, Heat, National Public Radio
------------------------------
From: Nix <$}xin{[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: 01 Apr 1999 23:24:29 +0100
[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.
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]
[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 :(
--
`The purpose of a windowing system is to put some amusing
fluff around your one almighty emacs window.' -- Mark on gnu.emacs.help
------------------------------
From: mack <[EMAIL PROTECTED]>
Subject: do I need all libfoo.so.2.0.x , libfoo.so.2.1
Date: Wed, 31 Mar 1999 21:55:27 +0000
my /lib directory has groups of files like
-rwxr-xr-x 1 root root 12859 Oct 7 1997 libBrokenLocale-2.0.5.so*
-rwxr-xr-x 1 root root 45080 Jan 10 18:30 libBrokenLocale-2.0.7.so*
-rwxr-xr-x 1 root root 22090 Jan 2 11:18
libBrokenLocale-2.0.108.so*
-rwxr-xr-x 1 root root 22090 Jan 6 08:55
libBrokenLocale-2.0.109.so*
-rwxr-xr-x 1 root root 21922 Feb 27 01:55 libBrokenLocale-2.1.so*
lrwxrwxrwx 1 root root 22 Feb 27 02:06 libBrokenLocale.so.1 ->
libBrokenLocale-2.1.so*
now I'm at 2.1, do I need all these files?
thanks
Joe
--
Joseph Mack, NA3T, FM05lw EME(B,D)
AZ_PROJ map server at http://www.wm7d.net/azproj.shtml
mailto:[EMAIL PROTECTED]
------------------------------
From: [EMAIL PROTECTED] (Christopher Browne)
Crossposted-To: comp.sys.next.advocacy
Subject: Re: Neal Stephenson does the car metaphor
Reply-To: [EMAIL PROTECTED]
Date: Fri, 02 Apr 1999 01:43:30 GMT
On Wed, 31 Mar 1999 18:04:49 -0600, Michael Peck
<[EMAIL PROTECTED]> wrote:
>Eric Remy wrote:
>> You could, but then nobody would use the neat features since you'd have to
>> write programs specifically to use them, and since 99% of the people out
>> there wouldn't use PeckFS the enhancements would be pointless.
>
>Ah...if it's not a standard, it's not useful...
This issue came up very recently on the mailing list for ReiserFS, an
up-and-coming filesystem being built for Linux. (With the eventual
goal of making it usable elsewhere.)
(Reiserfs is fairly interesting; see the home page at
<http://idiom.com/~beverly/reiserfs.html>...)
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.
The argument is pretty good; in order for something to be other than
"toy" functionality, it needs to be deployable in wider contexts than
"on an experimental kernel with experimental patches with a denial of
network access."
A "K001 application" that only works on a local filesystem on a Linux
box where the kernel has been patched to include the new FS code is
decidedly *not* going to get widely adopted.
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.
>> See the problems right now getting Linux a decent click+drool interface.
>> You've got the KDE folks warring with the GNOME folks, both writing
>> software that won't run under the other, etc.
>
>People writing more software...an obvious problem...
Note that the above statement is also FALSE. KDE and GNOME software can
all run quite happily at the same time atop X.
They may not be able to do Drag-n'Drool yet, but certainly have *intent*
for that aspect of interoperability.
>> In part, quite true. It's also why Unix has never taken over the world: it
>> 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.
>
>Yes, this is a popular speculation, probably because it's currently
>popular to take shots at Linux. Interesting that this fragmentation is
>almost universally considered to be detrimental. I'm not sure quite sure
>why, unless it's the same reasoning that puts Windows NT on the desktop
>where another system clearly belongs.
It's an interesting speculation of dubious likelihood of *realistically*
continuing in the long term.
The various distributions use largely the *same codebases.*
- The same Linux kernel development stream.
- The same GCC/EGCS development stream.
- The same LIBC development stream.
- The same LPD implementation stream.
- The same Apache implementation stream.
- The same XFree86 implementation.
- Many use the same RPM (package manager) software.
And the list can go on interminably.
They may be at varying version numbers (visit various flaming over
GLIBC), but those *aren't* fundamentally distribution distinctives. A
year from now, most Linux distributions will be using newer versions
than they are now, and while they may be somewhat out of sync, they'll
be working with the same sets of versions of the various software.
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).
>> Careful now. VMS died due to bad marketing decisions, not technical
>> problems.
>
>That's the whole point. Lots of Unixes have died for precisely the same
>reasons. Somehow, Unix is flourishing despite the failures.
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.
>> You don't want to argue that popularity somehow is a measure of
>> excellence, or you should be bowing to the altar of BillG, not RMS
>> and Linus.
>
>It has nothing to do with popularity, fundamentally. Please, I'm making
>a much higher argument; don't bring this back down to those stupid
>comp.sys.mac.advocacy flamewars.
>
>> People who believe this should have to play Pictionary some time. Getting
>> graphics right is much harder than getting text right. (And of course, you
>> need to decide which is best for the task anyway. A text-based CAD program
>> would suck. I still prefer Alpha or Emacs for writing HTML.)
>
>Actually, it's funny you should say so; it turns out that having a CLI
>in a CAD program is quite useful. Of course, it does not replace the
>GUI. Both are appropriate.
You need the CLI to do things that are best described symbolically; the
GUI is best for things that are best described visually.
There has been a whole lot of research into "visual programming;" most
programs are still written in textual languages like C, COBOL, Pascal,
or Lisp. (Or the various more recent variations thereof.)
>> Actually, I'd argue the problem is similar. Look at the number of root
>> exploits for a typical Unix. Most are there since we've added endless cool
>> tools and servers to Unix- they aren't due to fundemental problems in the
>> kernel, but poorly debugged or poorly implemented programs.
>
>Yes, but as you say the kernel is very secure, and that's my point. As
>Windows moves graphics drivers into the kernel, Linux keeps such things
>separate. The latest example to come to my attention is the /dev/3dfx
>device driver issue. It allows Glide-based software to run without root
>permissions or as setuid-root, but makes it easy to crash the entire
>system by feeding bad data to the card. None of the principals involved
>have suggested moving the device driver into the main kernel source
>tree, since it would be ridiculous. Yet this is par for the course on
>Windows.
>
>> Unix grows and adopts new technology quickly, even if that technology could
>> be very dangerous..
>>
>> This is true of just about all OSs. VMS was certainly vulnerable to a
>> number of trojan horse programs, and it was a marvel of security and
>> stability compared to most Unices. I suspect that people could do the same
>> to AS/400s and VM machines, if anyone really cared enough to hack them :^)
>
>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
requires system administrators that *understand security.* That leaves
the naive home user of Windows 98 completely out in the cold.
Unfortunately, a "default install" of Red Hat Linux done by a user that
has no comprehension of security will only be moderately more secure,
and that really only because the kernel/user space separation prevents
*some* exploits.
For a system to be secure requires three things:
a) A system that *can* be secured. Hacked-into-GUI-hood variations on
MS-DOS need not apply; Windows 9x doesn't qualify. UNIX-like systems
do; NT *may,* so long as you don't add extra "kernel level" stuff, which
is problematic.
b) An competent administrator that *really understands security.* I may
have a copy of (O'Reilly) Computer Security Basics next to me, and have
done *some* security work, but figure that I really just know enough to
be able to understand, and not to actually secure a system.
c) The time for the competent administrator to maintain the secureness
of the securable system.
All *three* things are necessary; if *any* are lacking, then security is
lost.
--
"Windows 98 Roast Specialty Blend coffee beans - just like ordinary
gourmet coffee except that processing is rushed to leave in the insect
larvae. Also sold under the ``Chock Full o' Bugs'' brand name..."
[EMAIL PROTECTED] <http://www.hex.net/~cbbrowne/security.html>
------------------------------
Crossposted-To:
comp.os.linux.misc,linux.redhat.misc,alt.linux,alt.os.linux,comp.os.linux.hardware
Subject: Re: Idea: Make a seperate "i686" tree for Redhat Linux 6.0
From: Johan Kullstam <[EMAIL PROTECTED]>
Date: 01 Apr 1999 20:36:45 -0500
Enkidu <[EMAIL PROTECTED]> writes:
> Bill Anderson wrote:
> >
> > The developers at RH *do* produce code. They *do* do more than
> > just collect Linux apps into one.
> > Various things they do have been pointed out here in this thread.
> > Among them are sysadmin apps, and the install process, as well
> > as RPM itsself.
> > To ignore these facts, and claim they do nothing other than
> > collect stuff, is to appear foolish.
> >
> Are you suggesting that the Redhat sysadmin apps, install process
> etc are *essential* to run Linux?
no such claim is or has been made. why do you bring it up?
> If so you are wrong. All they do is tie you in to doing it the
> Redhat way!
wrong again. does using perl prevent you from using awk? does emacs
keep you from enjoying vi? i thought not. now go away.
--
J o h a n K u l l s t a m
[[EMAIL PROTECTED]]
Don't Fear the Penguin!
------------------------------
From: [EMAIL PROTECTED] (David T. Blake)
Subject: Re: how are contributions to the linux development coordinated
Date: 01 Apr 1999 17:34:27 -0800
[EMAIL PROTECTED] writes:
>Hi all
>
>
>I find the idea behind linux' success is very appealing: everyone
>who'd like to contribute to the development of linux can. But thinking
>of that, I ask myself: how is this coordinated...
See
http://www.linuxhq.com/
Basically, if you have something to add, post a patch.
If it is worthwhile, it can get adopted.
--
Dave Blake
[EMAIL PROTECTED]
------------------------------
From: [EMAIL PROTECTED] (David T. Blake)
Subject: Re: kernel-upgrade
Date: 01 Apr 1999 17:35:53 -0800
Svein K Svendsen <[EMAIL PROTECTED]> writes:
>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.
See
/etc/rc.d/rc.sysinit for this issue on RH systems.
Personally, I've always liked /lib/modules/`uname -r`
better
--
Dave Blake
[EMAIL PROTECTED]
------------------------------
From: "lea" <[EMAIL PROTECTED]>
Subject: how to use gettimeofday()
Date: Thu, 01 Apr 1999 22:18:38 GMT
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?
------------------------------
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.
From: Klaus Schilling <[EMAIL PROTECTED]>
Date: 02 Apr 1999 02:54:46 +0200
Nix <$}xin{[email protected]> writes:
> "Paul F. Dietz" <[EMAIL PROTECTED]> writes:
>
> > Nix wrote:
> >
> > > Plus, instead of learning Yet Another One-Off Macro Language, you learn
> > > lisp, which is about as not-one-off as you can get, in addition to being
> > > wonderfully elegant.
> >
> > You learn a bastardized form of lisp. Emacs lisp is
> > very nonstandard.
>
> True; but it's still a Lisp. The fundamentals remain the same across
> Common Lisp, elisp, MacLisp and Scheme, do they not? (Pedantically this
> is not true, especially in Scheme - proper tail-recursion - but you know
> what I mean.)
Scheme requires PTR. Some CL implementations provide it too, though not
required hence not portably reliable.
>
> And one of the nice things about lisps is that you cna translate other
> things into them easily in realtime. (Guess what's happening with elisp?
> ;) )
>
> > I want emacs on top of Common Lisp. I suppose
There is an editor written in Common Lisp (CMUCL) which is called
Hemlock and provides a big deal of Emacs' facilities.
> > I'll have to settle for emacs on scheme, when
Again, there's an editor called edwin, using MIT Scheme.
> > that's available.
>
> Fairly soon, if you believe http://www.gnu.org/. I'm looking forward to
> that, too.
>
> (It's a pity I won't be able to use, er, eCLOS though ;) I wonder if the
There is now OO support for Emacs Lisp available, but yet much restricted,
such as no multiple inheritance. In Lisp, there's not as much use for MI
as in C++, due to the late binding of lisp, but it still constricts a bit.
> CLOS can be faked in Scheme?...)
There are TinyCLOS and Meroon, who all provide Object systems for Scheme
with generic functions and a sort of Meta Object Protocol. (Subset of CLOS
functionality)
Guile-scheme will soon get goops which does similar things, but with some
code base written in C for sake of speed.
Klaus Schilling
------------------------------
From: [EMAIL PROTECTED] (Alexander Viro)
Crossposted-To: alt.os.linux,comp.os.linux.advocacy,comp.os.linux.misc
Subject: Re: Proposal: "Linux 2000 Platform"
Date: 1 Apr 1999 21:34:22 -0500
In article <[EMAIL PROTECTED]>,
Jeremy Crabtree <[EMAIL PROTECTED]> wrote:
>Kendall Bennett allegedly wrote:
[snip Kendall's marketspeak]
>>Linux 2000 Workstation
>>----------------------
>>Base components:
>> . Standard locations for all configuration files!
>Such as? For the most part they live in /etc .
>> . Glibc based
>> . RPM for package manager
>I suggest dpkg instead, it's a bit more, shall we say, 'advanced'.
Seconded, with possible ports integration.
>(I use Slackware, and I don't use ANY package managers ;)
>> . GNU make, C/C++ compiler and development libraries
>Well, DUH! ;)
>> . 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.
>>Optional components:
>> . Web browser (Netscape or Mozilla variation?)
Or lynx, or any other browser. What's the difference for 3-rd party
applications?
>> . Need more suggestions here!
>>Linux 2000 Server
>>-----------------
>>Base components:
>> . Standard locations for all configuration files!
>See above.
>> . Glibc based
>> . RPM for package manager
>See above.
>> . GNU make, C/C++ compiler and development libraries
>Again DUH! ;)
>> . XFree86 installed to /usr/X11R6/lib (or /usr/X11)
On *SERVER*???
>See above.
>
>> . Ftp, telnet servers
>> . Apache web server
>Naturally.
Depends on the kind of server. No need to install ftpd
(which one, BTW?) on a webserver, etc.
>> . Web browser (Netscape or Mozilla variation?)
>
>On a server, this goes in the optional category.
On a server it goes into the bitbucket. CD goes into the microwave.
Proud users are invited to make a call in case if they want to buy a nice
bridge in NY.
--
"You're one of those condescending Unix computer users!"
"Here's a nickel, kid. Get yourself a better computer" - Dilbert.
------------------------------
From: wizard <[EMAIL PROTECTED]>
Crossposted-To:
comp.os.linux.misc,linux.redhat.misc,alt.linux,alt.os.linux,comp.os.linux.hardware
Subject: Re: Idea: Make a seperate "i686" tree for Redhat Linux 6.0
Date: Thu, 01 Apr 1999 20:44:24 -0500
Reply-To: [EMAIL PROTECTED]
Matthias Warkus wrote:
> It was the Wed, 31 Mar 1999 19:22:09 +1200...
> ..and 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.
>
> Of course they add value. The fact that all the diverse stuff is
> working together smoothly is added value already. NB they throw in
> stuff like a package management system, a bunch of configuration
> utilities etc. etc. - in my book, this is added value.
>
> mawa
> --
> When you look at yourself in an aberrational mirror, you see your real
> self, looking back at the twisted you.
> -- Dr. (?) Bob Miller, "The Aberrational View of the Universe",
> Twisted Science, Heat, National Public Radio
On top of adding value the strengthen the Linux code base by setting
things like RPM free. The other key item that everyone overlooks is
the large amount of effort the people at RedHat, Suse and others put into
driver development. If that does add value I don't know what does.
The simple fact is that the RedHat Cd gets a lot of people involved in
Linux that might not otherwise. This is truely a good thing.
Dave
------------------------------
From: "G. Sumner Hayes" <[EMAIL PROTECTED]>
Subject: Re: clone() or PThreads ???
Date: Thu, 01 Apr 1999 20:54:28 -0500
Udo Giacomozzi wrote:
>
> Hmm. I thought I can pass pointers between processes. Is there no
> function to mark a pointer accessible to other processes?
Yes, it's called shared memory. ;)
> Re realtime: I do not neet hard realtime (RTLinux) as I need the ALSA
> drivers. With realtime I mean the process should be able to do <10 ms
> I/O latency.
You can't guarantee that 100% without hard realtime. You can make it
very probable by running with soft realtime (regular linux SCHED_FIFO
or SCHED_RR priviledges).
> The child should do more or less this:
>
> loop
> read from sound device (blocking call)
> process sound data
> write to sound device (blocking call)
> end loop
>
[SNIP]
> I see. I would need to use shared memory but I have no idea how I
> could create my classes in this shared memory. And if I share all the
> memory I have problems with the RTL...
In C speak, allocate your shared memory region, create a (mystruct *)
pointer into the region, and call your initializing function on the
pointer. I don't speak FreePascal, unfortunately, but the principle is
the same.
> >The best solution would be to get a reentrant run-time and just use
> >threads. Is there any way you can do that? Do you have the source
> >code for the runtime?
>
> Yes, I have the source code. I am discuting with the FPC (FreePascal,
> http://www.brain.uni-freiburg.de/~klaus/fpc/ ) developers if we can
> make the RTL reentrant. I really hope it's possible.
That is the best approach, but if you can't do that then it seems like
shared memory ought to be good enough for your pseudo-realtime needs.
Good luck,
Sumner
------------------------------
From: [EMAIL PROTECTED]
Subject: how are contributions to the linux development coordinated
Date: Thu, 01 Apr 1999 22:39:45 GMT
Hi all
I find the idea behind linux' success is very appealing: everyone
who'd like to contribute to the development of linux can. But thinking
of that, I ask myself: how is this coordinated. Say, for example, I'd
like to change a line in a kernel's source file, because I think this
would be more efficient. How would I do that? Do I have to register
with some organisation, or with Linus?
Or, for another one, if I decided
to write a module or something, how would I be sure nobody else
is working on the same thing at the same time. If I knew that, I should
actually get in touch with him/her and do the development together.
Is there some faq on these issues or something to clarify this?
Thanks
Rene
============= Posted via Deja News, The Discussion Network ============
http://www.dejanews.com/ Search, Read, Discuss, or Start Your Own
------------------------------
From: Frank Sweetser <[EMAIL PROTECTED]>
Subject: Re: Kernel 2.3 when?
Date: 01 Apr 1999 21:38:23 -0500
[EMAIL PROTECTED] writes:
> Subject says all. When is 2.3 going to be out?
>
> There needs to be a development branch for development to take place.
>
> 2.2 came out on January 25, 1999. It's now over 2 months later.
>
> 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!
FWIW, the lm_sensors stuff is already there, the pIII works fine (like all
other Intel chips, it basically presents itself as just a reallyreally fast
386), and work on raw devices, ACL's, and 32bit uid/gid/devs has already
been underway for awhile.
--
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
I had a linguistics professor who said that it's man's ability to use
language that makes him the dominant species on the planet. That may
be. But I think there's one other thing that separates us from animals. We
aren't afraid of vacuum cleaners. --Jeff Stilson
------------------------------
Date: Thu, 01 Apr 1999 10:28:25 +0930
From: Glen Turner <[EMAIL PROTECTED]>
Crossposted-To: comp.unix.programmer
Subject: Re: [ANN] CodeWarrior for Red Hat Linux
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.
--
Glen Turner Network Specialist
Tel: (08) 8303 3936 Information Technology Services
Fax: (08) 8303 4400 The University of Adelaide 5005
Email: [EMAIL PROTECTED] South Australia
------------------------------
** 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
******************************
