Yes! I still need ISA support for an ne2000 card.
On Wednesday, June 13, 2001, at 06:23 PM, Rafael Diniz wrote:
>> No. There are still plenty of unique ISA cards around.
> How about all the isa ne2000 around the world?
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel"
Claudio Martins <[EMAIL PROTECTED]> said:
[...]
> Anyone with a <486 probably shudders at the space and time requirements
> of compiling modern kernels..
... which they do on their newer machine anyway, as the i386 in the closet
is a router that sports no compiler.
> The older boxes don't
Alan Cox wrote:
> > Would it make sense to create some sort of 'make config' script that
> > determines what you want in your kernel and then downloads only those
> > components? After all, with the constant release of new hardware, isn't a
> > 50MB kernel release not too far away? 100MB?
>
>
Alan Cox wrote:
Would it make sense to create some sort of 'make config' script that
determines what you want in your kernel and then downloads only those
components? After all, with the constant release of new hardware, isn't a
50MB kernel release not too far away? 100MB?
This should
Claudio Martins [EMAIL PROTECTED] said:
[...]
Anyone with a 486 probably shudders at the space and time requirements
of compiling modern kernels..
... which they do on their newer machine anyway, as the i386 in the closet
is a router that sports no compiler.
The older boxes don't support
Yes! I still need ISA support for an ne2000 card.
On Wednesday, June 13, 2001, at 06:23 PM, Rafael Diniz wrote:
No. There are still plenty of unique ISA cards around.
How about all the isa ne2000 around the world?
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
This seems to be drifting into that old argument(s) of a forked kernel..
And of course here I am adding to the flotsams..and threadsomes
2.5 for Pentium Plus generation.
<2.4 For older hardware..
Ducking the inevitable flames, I think for the most part, there might be
justification for some
On Wed, 13 Jun 2001, Colonel wrote:
>>I really think doing a clean up is worthwhile. Maybe while looking for stuff
>
>You left out all the old non-IDE CDROM drives.
And also UP systems. I've got 2 SMP boxes here now. Why not
remove support for any system with less than 2 processors? ;o)
On Wed, 13 Jun 2001, Daniel wrote:
>i386, i486
>The Pentium processor has been around since 1995. Support for these older
>processors should go so we can focus on optimizations for the pentium and
>better processors.
[SNIP]
Boy, if this isn't a troll, I don't know what is. Obviously
someone
On Thursday 14 June 2001 08:14, David Luyer wrote:
> Well, I'm actually looking at the 2nd idea I mentioned in my e-mail -- a
> very small "kernel package" which has a config script, a list of config
> options and the files they depend on and an appropriately tagged CVS tree
> which can then be
Daniel Phillips writes:
> On Thursday 14 June 2001 10:34, Alexander Viro wrote:
> > On Thu, 14 Jun 2001, Daniel Phillips wrote:
> > > This sounds a lot like apt-get, doesn't it?
> >
> > Folks, RTFFAQ, please. URL is attached to the end of each posting.
>
> The FAQ blesses the idea of people
"Linux
kernel" <[EMAIL PROTECTED]>
Cc: "Jaswinder Singh" <[EMAIL PROTECTED]>
Sent: Thursday, June 14, 2001 7:01 AM
Subject: Re: obsolete code must die
> - Received message begins Here -
>
> >
> > Cleanup is a nic
On Thursday 14 June 2001 10:34, Alexander Viro wrote:
> On Thu, 14 Jun 2001, Daniel Phillips wrote:
> > This sounds a lot like apt-get, doesn't it?
>
> Folks, RTFFAQ, please. URL is attached to the end of each posting.
The FAQ blesses the idea of people setting up incremental download services,
On Wed, Jun 13, 2001 at 08:44:11PM -0400, Daniel wrote:
>
> ISA bus, MCA bus, EISA bus
> PCI is the defacto standard. Get rid of CONFIG_BLK_DEV_ISAPNP,
> CONFIG_ISAPNP, etc
>
> ISA, MCA, EISA device drivers
> If support for the buses is gone, there's no point in supporting devices for
> these
;Daniel" <[EMAIL PROTECTED]>
> To: "Linux kernel" <[EMAIL PROTECTED]>
> Sent: Wednesday, June 13, 2001 5:44 PM
> Subject: obsolete code must die
>
>
> > Anyone concerned about the current size of the kernel source code? I am,
> and
> > I propose to
On Thursday 14 June 2001 12:22, Heusden, Folkert van wrote:
> Yeah, and while you're at it: make it closed source and ask big time $$
> for every single line of update.
> If your stupid idea will be followed, a lot of african people will not
> be happy. (me neither. proud owner of a 486 (at
(I wrote)
> > This might actually make sense - a kernel composed of multiple versioned
> > segments. A tool which works out dependencies of the options being selected,
> > downloads the required parts if the latest versions of those parts are not
> > already downloaded, and then builds the
David Luyer <[EMAIL PROTECTED]> said:
[...]
> This might actually make sense - a kernel composed of multiple versioned
> segments. A tool which works out dependencies of the options being selected,
> downloads the required parts if the latest versions of those parts are not
> already
> On Wed, 13 Jun 2001, Daniel wrote:
> > MFM/RLL/XT/ESDI hard drive support
> > Does anyone still *have* an RLL drive that works? At the very least get rid
RLL ? Curently no. But I have a dosen of working ST225 with a dosen of ST11M
MFM controllers. Some of them ar\e still in use, mainly for
]]
Sent: donderdag 14 juni 2001 2:44
To: Linux kernel
Subject: obsolete code must die
Anyone concerned about the current size of the kernel source code? I am, and
I propose to start cleaning house on the x86 platform. I mean it's all very
well and good to keep adding features, but stuff needs to go
In article <01a401c0f46b$20b932e0$480e6c42@almlba4sy7xn6x> you write:
> -- Getting rid of old code can help simplify the kernel. This means less
> chance of bugs.
Actually, what you suggest is simply getting rid of users. It would
sure simplify things greatly.
Are you nihilist ?
On Thu, 14 Jun 2001, Alan Cox wrote:
> > Would it make sense to create some sort of 'make config' script that
> > determines what you want in your kernel and then downloads only those
> > components? After all, with the constant release of new hardware, isn't a
> > 50MB kernel release not too
- Original Message -
From: "Alan Cox" <[EMAIL PROTECTED]>
Subject: Re: obsolete code must die
> > Would it make sense to create some sort of 'make config' script that
> > determines what you want in your kernel and then downloads only those
> > compon
On Wed, 13 Jun 2001, Daniel wrote:
> So without further ado here're the features I want to get rid of:
>
> i386, i486
> The Pentium processor has been around since 1995. Support for these older
> processors should go so we can focus on optimizations for the pentium and
> better processors.
On Wed, Jun 13, 2001 at 07:22:38PM -0700, Alan Olsen wrote:
> > i386, i486
> > The Pentium processor has been around since 1995. Support for these older
> > processors should go so we can focus on optimizations for the pentium and
> > better processors.
> You are in a part of the world that can
On Thursday 14 June 2001 04:00, David Luyer wrote:
> > Would it make sense to create some sort of 'make config' script that
> > determines what you want in your kernel and then downloads only those
> > components? After all, with the constant release of new hardware, isn't a
> > 50MB kernel
>
> i386, i486
> The Pentium processor has been around since 1995. Support for these older
> processors should go so we can focus on optimizations for the pentium and
> better processors.
a lot of people use linux on old machine in networking environmens as
routers/firewalls.
>
> math-emu
>
Okay, I didn't realize how much opposition there would be to this,
thanks for all the input. If you'd like to add anything to this, please
email me personally -- the mailing list has probably seen enough traffic
regarding this issue. :-)
Thanks
Daniel
-
To unsubscribe from this list: send
On Wed, Jun 13, 2001 at 08:44:11PM -0400, Daniel wrote:
> Anyone concerned about the current size of the kernel source code? I am, and
> I propose to start cleaning house on the x86 platform. I mean it's all very
> well and good to keep adding features, but stuff needs to go if kernel
>
On Wed, Jun 13, 2001 at 08:44:11PM -0400, Daniel wrote:
Anyone concerned about the current size of the kernel source code? I am, and
I propose to start cleaning house on the x86 platform. I mean it's all very
well and good to keep adding features, but stuff needs to go if kernel
development
Okay, I didn't realize how much opposition there would be to this,
thanks for all the input. If you'd like to add anything to this, please
email me personally -- the mailing list has probably seen enough traffic
regarding this issue. :-)
Thanks
Daniel
-
To unsubscribe from this list: send
i386, i486
The Pentium processor has been around since 1995. Support for these older
processors should go so we can focus on optimizations for the pentium and
better processors.
a lot of people use linux on old machine in networking environmens as
routers/firewalls.
math-emu
If
On Thursday 14 June 2001 04:00, David Luyer wrote:
Would it make sense to create some sort of 'make config' script that
determines what you want in your kernel and then downloads only those
components? After all, with the constant release of new hardware, isn't a
50MB kernel release not
On Wed, Jun 13, 2001 at 07:22:38PM -0700, Alan Olsen wrote:
i386, i486
The Pentium processor has been around since 1995. Support for these older
processors should go so we can focus on optimizations for the pentium and
better processors.
You are in a part of the world that can afford
On Wed, 13 Jun 2001, Daniel wrote:
So without further ado here're the features I want to get rid of:
i386, i486
The Pentium processor has been around since 1995. Support for these older
processors should go so we can focus on optimizations for the pentium and
better processors.
Please, I
In article 01a401c0f46b$20b932e0$480e6c42@almlba4sy7xn6x you write:
-- Getting rid of old code can help simplify the kernel. This means less
chance of bugs.
Actually, what you suggest is simply getting rid of users. It would
sure simplify things greatly.
Are you nihilist ?
--Thomas
]]
Sent: donderdag 14 juni 2001 2:44
To: Linux kernel
Subject: obsolete code must die
Anyone concerned about the current size of the kernel source code? I am, and
I propose to start cleaning house on the x86 platform. I mean it's all very
well and good to keep adding features, but stuff needs to go
On Wed, 13 Jun 2001, Daniel wrote:
MFM/RLL/XT/ESDI hard drive support
Does anyone still *have* an RLL drive that works? At the very least get rid
RLL ? Curently no. But I have a dosen of working ST225 with a dosen of ST11M
MFM controllers. Some of them ar\e still in use, mainly for booting
David Luyer [EMAIL PROTECTED] said:
[...]
This might actually make sense - a kernel composed of multiple versioned
segments. A tool which works out dependencies of the options being selected,
downloads the required parts if the latest versions of those parts are not
already downloaded, and
(I wrote)
This might actually make sense - a kernel composed of multiple versioned
segments. A tool which works out dependencies of the options being selected,
downloads the required parts if the latest versions of those parts are not
already downloaded, and then builds the kernel (or
On Thursday 14 June 2001 12:22, Heusden, Folkert van wrote:
Yeah, and while you're at it: make it closed source and ask big time $$
for every single line of update.
If your stupid idea will be followed, a lot of african people will not
be happy. (me neither. proud owner of a 486 (at home))
[EMAIL PROTECTED]
Sent: Wednesday, June 13, 2001 5:44 PM
Subject: obsolete code must die
Anyone concerned about the current size of the kernel source code? I am,
and
I propose to start cleaning house on the x86 platform. I mean it's all
very
well and good to keep adding features, but stuff
On Wed, Jun 13, 2001 at 08:44:11PM -0400, Daniel wrote:
ISA bus, MCA bus, EISA bus
PCI is the defacto standard. Get rid of CONFIG_BLK_DEV_ISAPNP,
CONFIG_ISAPNP, etc
ISA, MCA, EISA device drivers
If support for the buses is gone, there's no point in supporting devices for
these buses.
On Thursday 14 June 2001 10:34, Alexander Viro wrote:
On Thu, 14 Jun 2001, Daniel Phillips wrote:
This sounds a lot like apt-get, doesn't it?
Folks, RTFFAQ, please. URL is attached to the end of each posting.
The FAQ blesses the idea of people setting up incremental download services,
Singh [EMAIL PROTECTED]
Sent: Thursday, June 14, 2001 7:01 AM
Subject: Re: obsolete code must die
- Received message begins Here -
Cleanup is a nice idea , but Linux should support old hardware and
should
not affect them in any way.
Jaswinder.
I agree - and added my
On Thursday 14 June 2001 08:14, David Luyer wrote:
Well, I'm actually looking at the 2nd idea I mentioned in my e-mail -- a
very small kernel package which has a config script, a list of config
options and the files they depend on and an appropriately tagged CVS tree
which can then be used
Daniel Phillips writes:
On Thursday 14 June 2001 10:34, Alexander Viro wrote:
On Thu, 14 Jun 2001, Daniel Phillips wrote:
This sounds a lot like apt-get, doesn't it?
Folks, RTFFAQ, please. URL is attached to the end of each posting.
The FAQ blesses the idea of people setting up
On Wed, 13 Jun 2001, Daniel wrote:
i386, i486
The Pentium processor has been around since 1995. Support for these older
processors should go so we can focus on optimizations for the pentium and
better processors.
[SNIP]
Boy, if this isn't a troll, I don't know what is. Obviously
someone
On Wed, 13 Jun 2001, Colonel wrote:
I really think doing a clean up is worthwhile. Maybe while looking for stuff
You left out all the old non-IDE CDROM drives.
And also UP systems. I've got 2 SMP boxes here now. Why not
remove support for any system with less than 2 processors? ;o)
I'll
This seems to be drifting into that old argument(s) of a forked kernel..
And of course here I am adding to the flotsams..and threadsomes
2.5 for Pentium Plus generation.
2.4 For older hardware..
Ducking the inevitable flames, I think for the most part, there might be
justification for some
- Original Message -
From: Alan Cox [EMAIL PROTECTED]
Subject: Re: obsolete code must die
Would it make sense to create some sort of 'make config' script that
determines what you want in your kernel and then downloads only those
components? After all, with the constant release
On Thu, 14 Jun 2001, Alan Cox wrote:
Would it make sense to create some sort of 'make config' script that
determines what you want in your kernel and then downloads only those
components? After all, with the constant release of new hardware, isn't a
50MB kernel release not too far away?
On Wed, 13 Jun 2001, Stephen Satchell wrote:
> At 12:24 AM 6/14/01 -0300, Rik van Riel wrote:
> >Everything you propose to get rid of are DRIVERS. They
> >do NOT complicate the core kernel, do NOT introduce bugs
> >in the core kernel and have absolutely NOTHING to do with
> >how simple or
At 12:24 AM 6/14/01 -0300, Rik van Riel wrote:
>Everything you propose to get rid of are DRIVERS. They
>do NOT complicate the core kernel, do NOT introduce bugs
>in the core kernel and have absolutely NOTHING to do with
>how simple or maintainable the core kernel is.
Not quite. There were two
Em Wed, Jun 13, 2001 at 09:55:54PM -0400, Horst von Brand escreveu:
> "Daniel" <[EMAIL PROTECTED]> said:
> > I really think doing a clean up is worthwhile. Maybe while looking for stuff
> > to clean up we'll even be able to better comment the existing code. Any
> > other features people would
"Daniel" <[EMAIL PROTECTED]> said:
[...]
> So without further ado here're the features I want to get rid of:
>
> i386, i486
> The Pentium processor has been around since 1995. Support for these older
> processors should go so we can focus on optimizations for the pentium and
> better
On Wed, 13 Jun 2001, Daniel wrote:
OK, after my earlier troll posting, lets go over Daniel's
reasons point by point. Well actually, all of these points
fit in one argument.
> -- Getting rid of old code can help simplify the kernel. This means
> less chance of bugs.
> -- Simplifying the kernel
i have a corvus 20meg drive and a xebec 10meg that both still spin up. those
are from mid to late 80s. i have seagate hawks from '94 that still work, but
quantums from the same period are all dead. the difference is that newer
drives have much tighter tolerances and are much more sensitive to
>
> Or as a simpler design, something like;
>
> * a copy of the kernel maintained in a CVS tree
> * kernel download would pull down:
> * the build script
> * a file containing the list of filenames depended on by
> each config option
> * build script builds the
> I agree that removing support for any hardware is a bad idea but I question
> the idea of putting it all in one monolithic download (tar file). If we're
> considering the concern for less developed nations with older hardware,
> imagine how you would like to download the whole kernel with an
Daniel wrote:
>
> Anyone concerned about the current size of the kernel source code? I am, and
> I propose to start cleaning house on the x86 platform. I mean it's all very
> well and good to keep adding features, but stuff needs to go if kernel
> development is to move forward. Before listing
On Wed, 13 Jun 2001, Daniel wrote:
> -- Getting rid of old code can help simplify the kernel. This means less
> chance of bugs.
> -- Simplifying the kernel means that it will be easier for newbies to
> understand and perhaps contribute.
> -- a simpler, cleaner kernel will also be of more use in
> -Original Message-
> From: [EMAIL PROTECTED]
> [mailto:[EMAIL PROTECTED]]On Behalf Of Colonel
> Sent: Thursday, June 14, 2001 10:32 AM
> To: [EMAIL PROTECTED]
> Subject: Re: obsolete code must die
>
>
> In list.kernel, you wrote:
>
> >i think we are a
Obsolete code must die. Hardware support must live on.
> > ISA, MCA, EISA device drivers
> > If support for the buses is gone, there's no point in supporting devices for
> > these buses.
>
> I am not certain if tis is a good idea, for the reason given above.
In list.kernel, you wrote:
>i think we are all missing the ball here: i am happy when i see driver
>support for a piece of hardware that i have _NEVER_ heard of and at most
>_ONE_ person uses it. why? it means more stuff works in linux. we
>dont need to defend how many people use hardware X.
Hi
>-- a simpler, cleaner kernel will also be of more use in an academic
>environment.
>i386, i486
>The Pentium processor has been around since 1995. Support for these older
>processors should go so we can focus on optimizations for the pentium and
>better processors.
>ISA bus, MCA bus, EISA
> >i386, i486
> >The Pentium processor has been around since 1995. Support for these older
>
> No. Both of my cheap on-site systems for occasional access are 486s.
> Why would I spend money for a system that is hardly ever used?
I have 386's that I still use.
> >ISA bus, MCA bus, EISA bus
>
On Wed, 13 Jun 2001, Daniel wrote:
> math-emu
> If support for i386 and i486 is going away, then so should math emulation.
> Every intel processor since the 486DX has an FPU unit built in. In fact
> shouldn't FPU support be a userspace responsibility anyway?
hmm... what about processors like
On 13 Jun 2001 19:22:38 -0700, Alan Olsen wrote:
> On Wed, 13 Jun 2001, Daniel wrote:
>
> > ISA bus, MCA bus, EISA bus
> > PCI is the defacto standard. Get rid of CONFIG_BLK_DEV_ISAPNP,
> > CONFIG_ISAPNP, etc
>
> This I strongly disagree with.
>
> There are alot of ISA cards still in use. (I
Yo Daniel!
On Wed, 13 Jun 2001, Daniel Dickman wrote:
> What I'd like to know is this -- will support for the i386, say, ever go
> away? What if the hardware is no longer in existence/used by anyone? will
> support stay in the kernel?
There is an aweful lot of embedded Linux using 386 and 486
On Wed, 13 Jun 2001, Daniel wrote:
I agree that some clean up is needed. (The size of the kernel is getting
HUGE. Back in the old days, we didn't have kernels larger than a few
hundred kbytes. That is because we had to type in the kernel source from
source written on papyrus.)
> So without
On Thursday 14 June 2001 01:44, Daniel wrote:
> -- If someone really needs support for this junk, they will always have the
> option of using the 2.0.x, 2.2.x or 2.4.x series.
>
You mean you want 2.5+ series to just stop supporting all older hardware?
> So without further ado here're the
, 2001 20:44 PM
> To: Linux kernel
> Subject: obsolete code must die
>
>
> Anyone concerned about the current size of the kernel source
> code? I am, and
> I propose to start cleaning house on the x86 platform. I mean
> it's all very
> well and good to keep adding fe
On Wed, 13 Jun 2001, Daniel Dickman wrote:
> Thanks for your email. I am aware of the "traditions" of the
> Linux kernel, and this is really why I wanted to start a
> discussion going about this.
OK, so you almost certainly ARE a troll:
1) proposing to remove support for hardware many of us
In list.kernel, you wrote:
>
>Anyone concerned about the current size of the kernel source code? I am, and
No. Since you are up to date with the latest in everything, I cannot
see why you would be concerned about a few megabytes in your gigabyte
drives.
>i386, i486
>The Pentium processor has
have been
clearer about this.
Daniel
- Original Message -
From: "Andrew Pimlott" <[EMAIL PROTECTED]>
To: "Daniel" <[EMAIL PROTECTED]>
Sent: Wednesday, June 13, 2001 8:47 PM
Subject: Re: obsolete code must die
> Do you realize how violently your sug
Daniel wrote:
>
> Anyone concerned about the current size of the kernel source code? I am, and
> I propose to start cleaning house on the x86 platform. I mean it's all very
> well and good to keep adding features, but stuff needs to go if kernel
> development is to move forward. Before listing
Cleanup is a nice idea , but Linux should support old hardware and should
not affect them in any way.
Jaswinder.
- Original Message -
From: "Daniel" <[EMAIL PROTECTED]>
To: "Linux kernel" <[EMAIL PROTECTED]>
Sent: Wednesday, June 13, 2001 5:44 PM
On Wed, 13 Jun 2001, Daniel wrote:
> So without further ado here're the features I want to get rid of:
>
> i386, i486
> math-emu
> ISA bus, MCA bus, EISA bus
> ISA, MCA, EISA device drivers
> parallel/serial/game ports
++
| Please, |
|don't feed |
|
Anyone concerned about the current size of the kernel source code? I am, and
I propose to start cleaning house on the x86 platform. I mean it's all very
well and good to keep adding features, but stuff needs to go if kernel
development is to move forward. Before listing the gunk I want to get rid
Anyone concerned about the current size of the kernel source code? I am, and
I propose to start cleaning house on the x86 platform. I mean it's all very
well and good to keep adding features, but stuff needs to go if kernel
development is to move forward. Before listing the gunk I want to get rid
Cleanup is a nice idea , but Linux should support old hardware and should
not affect them in any way.
Jaswinder.
- Original Message -
From: Daniel [EMAIL PROTECTED]
To: Linux kernel [EMAIL PROTECTED]
Sent: Wednesday, June 13, 2001 5:44 PM
Subject: obsolete code must die
Anyone
Daniel wrote:
Anyone concerned about the current size of the kernel source code? I am, and
I propose to start cleaning house on the x86 platform. I mean it's all very
well and good to keep adding features, but stuff needs to go if kernel
development is to move forward. Before listing the
about this.
Daniel
- Original Message -
From: Andrew Pimlott [EMAIL PROTECTED]
To: Daniel [EMAIL PROTECTED]
Sent: Wednesday, June 13, 2001 8:47 PM
Subject: Re: obsolete code must die
Do you realize how violently your suggestions conflict with the
goals, practices, and traditions
In list.kernel, you wrote:
Anyone concerned about the current size of the kernel source code? I am, and
No. Since you are up to date with the latest in everything, I cannot
see why you would be concerned about a few megabytes in your gigabyte
drives.
i386, i486
The Pentium processor has been
On Wed, 13 Jun 2001, Daniel Dickman wrote:
Thanks for your email. I am aware of the traditions of the
Linux kernel, and this is really why I wanted to start a
discussion going about this.
OK, so you almost certainly ARE a troll:
1) proposing to remove support for hardware many of us use
To: Linux kernel
Subject: obsolete code must die
Anyone concerned about the current size of the kernel source
code? I am, and
I propose to start cleaning house on the x86 platform. I mean
it's all very
well and good to keep adding features, but stuff needs to go if kernel
development
On Wed, 13 Jun 2001, Daniel wrote:
I agree that some clean up is needed. (The size of the kernel is getting
HUGE. Back in the old days, we didn't have kernels larger than a few
hundred kbytes. That is because we had to type in the kernel source from
source written on papyrus.)
So without
On Thursday 14 June 2001 01:44, Daniel wrote:
-- If someone really needs support for this junk, they will always have the
option of using the 2.0.x, 2.2.x or 2.4.x series.
You mean you want 2.5+ series to just stop supporting all older hardware?
So without further ado here're the
Yo Daniel!
On Wed, 13 Jun 2001, Daniel Dickman wrote:
What I'd like to know is this -- will support for the i386, say, ever go
away? What if the hardware is no longer in existence/used by anyone? will
support stay in the kernel?
There is an aweful lot of embedded Linux using 386 and 486
On 13 Jun 2001 19:22:38 -0700, Alan Olsen wrote:
On Wed, 13 Jun 2001, Daniel wrote:
snip
ISA bus, MCA bus, EISA bus
PCI is the defacto standard. Get rid of CONFIG_BLK_DEV_ISAPNP,
CONFIG_ISAPNP, etc
This I strongly disagree with.
There are alot of ISA cards still in use. (I have a
i386, i486
The Pentium processor has been around since 1995. Support for these older
No. Both of my cheap on-site systems for occasional access are 486s.
Why would I spend money for a system that is hardly ever used?
I have 386's that I still use.
ISA bus, MCA bus, EISA bus
PCI is the
On Wed, 13 Jun 2001, Daniel wrote:
math-emu
If support for i386 and i486 is going away, then so should math emulation.
Every intel processor since the 486DX has an FPU unit built in. In fact
shouldn't FPU support be a userspace responsibility anyway?
hmm... what about processors like cris?
Hi
-- a simpler, cleaner kernel will also be of more use in an academic
environment.
i386, i486
The Pentium processor has been around since 1995. Support for these older
processors should go so we can focus on optimizations for the pentium and
better processors.
ISA bus, MCA bus, EISA bus
PCI
In list.kernel, you wrote:
i think we are all missing the ball here: i am happy when i see driver
support for a piece of hardware that i have _NEVER_ heard of and at most
_ONE_ person uses it. why? it means more stuff works in linux. we
dont need to defend how many people use hardware X. if
Obsolete code must die. Hardware support must live on.
ISA, MCA, EISA device drivers
If support for the buses is gone, there's no point in supporting devices for
these buses.
I am not certain if tis is a good idea, for the reason given above. (Not
certain about MCA and EISA though
-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED]]On Behalf Of Colonel
Sent: Thursday, June 14, 2001 10:32 AM
To: [EMAIL PROTECTED]
Subject: Re: obsolete code must die
In list.kernel, you wrote:
i think we are all missing the ball here: i am happy when i see
On Wed, 13 Jun 2001, Daniel wrote:
-- Getting rid of old code can help simplify the kernel. This means less
chance of bugs.
-- Simplifying the kernel means that it will be easier for newbies to
understand and perhaps contribute.
-- a simpler, cleaner kernel will also be of more use in an
Daniel wrote:
Anyone concerned about the current size of the kernel source code? I am, and
I propose to start cleaning house on the x86 platform. I mean it's all very
well and good to keep adding features, but stuff needs to go if kernel
development is to move forward. Before listing the
I agree that removing support for any hardware is a bad idea but I question
the idea of putting it all in one monolithic download (tar file). If we're
considering the concern for less developed nations with older hardware,
imagine how you would like to download the whole kernel with an old
1 - 100 of 107 matches
Mail list logo
