On Mon, 30 Jun 2003 18:17:57 +0200
Karsten Merker <[EMAIL PROTECTED]> wrote:
> > I think ports to other kernels are generally worthwhile in and of
> > themselves, simply for cleaning up the codebase and getting rid of
> > unportable stuff.
> >
> > It's just plain old healthy is all. The previous c
On Sun, Jun 29, 2003 at 02:13:48PM -0400, Nathan Hawkins wrote:
> On Thu, Jun 26, 2003 at 04:24:23PM -0400, Matt Zimmerman wrote:
> > On Thu, Jun 26, 2003 at 09:44:30AM +0200, Christoph Hellwig wrote:
> >
> > > On Wed, Jun 25, 2003 at 02:04:54PM -0500, Gunnar Wolf wrote:
> > > > ports - NetBSD giv
On Sat, 28 Jun 2003 15:53:56 -0600
Joel Baker <[EMAIL PROTECTED]> wrote:
> > No it doesn't. I've yet to even hear of an architecture that NetBSD runs
> > on but which Linux doesn't. They just have a different definition of
> > "architecture" than us. (ie: our "hppa" may be three or four arches to
>
On Thu, Jun 26, 2003 at 04:24:23PM -0400, Matt Zimmerman wrote:
> On Thu, Jun 26, 2003 at 09:44:30AM +0200, Christoph Hellwig wrote:
>
> > On Wed, Jun 25, 2003 at 02:04:54PM -0500, Gunnar Wolf wrote:
> > > ports - NetBSD gives us the potential to bring Debian to _many_ new
> > > platforms.
> >
>
On Thu, Jun 26, 2003 at 09:04:55AM -0400, David B Harris wrote:
> No it doesn't. I've yet to even hear of an architecture that NetBSD runs
> on but which Linux doesn't.
pc532
> They just have a different definition of
> "architecture" than us. (ie: our "hppa" may be three or four arches to
> the
Christoph Hellwig wrote:
>On Wed, Jun 25, 2003 at 02:04:54PM -0500, Gunnar Wolf wrote:
>> ports - NetBSD gives us the potential to bring Debian to _many_ new
>> platforms.
>
>It's not that many actually. The only CPU that NetBSD claims to support
>but Linux doesn't is the pc532. Also the (umerge
On Thu, Jun 26, 2003 at 09:04:55AM -0400, David B Harris wrote:
> On Wed, 25 Jun 2003 14:04:54 -0500
> Gunnar Wolf <[EMAIL PROTECTED]> wrote:
> > And not only 80386 needs this - There is the Sparc64 port which would
> > also benefit from this (http://www.debian.org/ports/sparc/#64bit). If we
> > ha
On Thu, Jun 26, 2003 at 09:04:55AM -0400, David B Harris wrote:
> On Wed, 25 Jun 2003 14:04:54 -0500
> Gunnar Wolf <[EMAIL PROTECTED]> wrote:
> > And not only 80386 needs this - There is the Sparc64 port which would
> > also benefit from this (http://www.debian.org/ports/sparc/#64bit). If we
> > ha
Hi,
On Thu, Jun 26, 2003 at 09:04:55AM -0400, David B Harris wrote:
> On Wed, 25 Jun 2003 14:04:54 -0500
> Gunnar Wolf <[EMAIL PROTECTED]> wrote:
> > And not only 80386 needs this - There is the Sparc64 port which would
> > also benefit from this (http://www.debian.org/ports/sparc/#64bit). If we
On Thu, Jun 26, 2003 at 08:29:41PM -0500, Adam Heath wrote:
> On Thu, 26 Jun 2003, Michael Banck wrote:
>
> > Also, please note that at least half of the dpkg-maintainers don't read
> > -devel, you probably want to post this to -dpkg. Incidently, there is a
> > proposal and patch by Gerhard Tonn f
On Fri, Jun 27, 2003 at 02:08:46PM -0400, Nathanael Nerode wrote:
> >* what opcodes need to be emulated?
>
> >* all 386->486 opcodes (there's just a few of them, right?)
> This is the correct answer. :-) Then all programs can be compiled with
> gcc --arch=i486 --tune=i686 (which should probab
On Thu, 26 Jun 2003, "Martin v. Löwis" wrote:
> Marcelo E. Magallon wrote:
> > The patch has been already written: http://lwn.net/Articles/8634/ I'm
> > sure theere's a better link, but that's the best I could extract out of
> > google without resorting to bribery :-)
>
> This patch is insuff
>* what opcodes need to be emulated?
>* all 386->486 opcodes (there's just a few of them, right?)
This is the correct answer. :-) Then all programs can be compiled with
gcc --arch=i486 --tune=i686 (which should probably be mandated as the
standard, in fact).
>* do you need SMP on 80386? Is
On Thu, 26 Jun 2003, Michael Banck wrote:
> Also, please note that at least half of the dpkg-maintainers don't read
> -devel, you probably want to post this to -dpkg. Incidently, there is a
> proposal and patch by Gerhard Tonn for handling lib64 under
> discussion[2].
Well, considering there are
Marcelo E. Magallon wrote:
The patch has been already written: http://lwn.net/Articles/8634/ I'm
sure theere's a better link, but that's the best I could extract out of
google without resorting to bribery :-)
This patch is insufficient. It does not implement xaddl.
Regards,
Martin
On Thu, Jun 26, 2003 at 09:44:30AM +0200, Christoph Hellwig wrote:
> On Wed, Jun 25, 2003 at 02:04:54PM -0500, Gunnar Wolf wrote:
> > ports - NetBSD gives us the potential to bring Debian to _many_ new
> > platforms.
>
> It's not that many actually. The only CPU that NetBSD claims to support
>
On Thu, Jun 26, 2003 at 11:40:21AM +0200, Andreas Barth wrote:
> * Michael Banck ([EMAIL PROTECTED]) [030626 08:20]:
> > On Wed, Jun 25, 2003 at 06:50:54PM +0200, Andreas Barth wrote:
> > > What does oppose us to make subarchitectures quite more easy than now?
> > > (That would also be useful for t
On Wed, 25 Jun 2003 14:04:54 -0500
Gunnar Wolf <[EMAIL PROTECTED]> wrote:
> And not only 80386 needs this - There is the Sparc64 port which would
> also benefit from this (http://www.debian.org/ports/sparc/#64bit). If we
> had support for subarchtectures, not only would the ix86 mess be able to
> b
* Michael Banck ([EMAIL PROTECTED]) [030626 08:20]:
> On Wed, Jun 25, 2003 at 06:50:54PM +0200, Andreas Barth wrote:
> > What does oppose us to make subarchitectures quite more easy than now?
> > (That would also be useful for the AMD Opteron and the like that could
> > use normal i386-code, but ca
On Wed, Jun 25, 2003 at 02:04:54PM -0500, Gunnar Wolf wrote:
> ports - NetBSD gives us the potential to bring Debian to _many_ new
> platforms.
It's not that many actually. The only CPU that NetBSD claims to support
but Linux doesn't is the pc532. Also the (umerged) Linux VAX and arm26
aren't r
Morning ..
On Wed, Jun 25, 2003 at 02:04:54PM -0500, Gunnar Wolf wrote:
>And not only 80386 needs this - There is the Sparc64 port which would
>also benefit from this (http://www.debian.org/ports/sparc/#64bit). If we
>had support for subarchtectures, not only would the ix86 mess be able to
>be sp
On Wed, Jun 25, 2003 at 12:35:53PM -0400, Colin Walters wrote:
> I'm surprised that pthreads apparently doesn't use it.
nptl doesn't support i386 anymore because of that.
On Wed, Jun 25, 2003 at 01:26:38PM +0900, GOTO Masanori wrote:
> Performance improvement is _not_ my primary intention.At least it needs to
> support libc6-686:
>
> - LinuxThreads floating stack support. It's ready for i686 and later.
>
> - NPTL/TLS support. NPTL currently supports i486 an
Colin Watson dijo [Wed, Jun 25, 2003 at 11:05:56AM +0100]:
> > We should foist the job of supporting i386 onto some specialized Debian
> > port for it.
>
> The problem is that we really don't have sensible support for
> subarchitectures at all. This makes the job of creating such a
> specialized p
On Wed, Jun 25, 2003 at 06:50:54PM +0200, Andreas Barth wrote:
> What does oppose us to make subarchitectures quite more easy than now?
> (That would also be useful for the AMD Opteron and the like that could
> use normal i386-code, but can profit from optimized code.)
Nothing opposes it, we're ju
* Colin Watson ([EMAIL PROTECTED]) [030625 12:35]:
> The problem is that we really don't have sensible support for
> subarchitectures at all. This makes the job of creating such a
> specialized port much greater than just "I have some hardware and need
> to make a small tweak to support it"; you ne
On Wed, 2003-06-25 at 06:05, Colin Watson wrote:
> I disagree. Unlike 286, we've got the kernel, the libc, and *almost*
> everything else. The only thing missing is part of the C++ ABI, which as
> described can be handled by a small kernel patch (at least this has been
> claimed and nobody has imm
On Wed, Jun 25, 2003 at 08:51:12PM +1000, Herbert Xu wrote:
> It certainly is feasible. In fact, such a patch has been in existence
> for at least a year.
Cool.
> I have no problems with integrating such a patch. I will look at it
> right now.
Excellent. Thanks!
--
G. Branden Robinson
On Wed, Jun 25, 2003 at 01:42:04PM +0200, Adam Borowski wrote:
> As the person who originally submitted this idea, I'm probably the
> one who is morally obliged to write it, even though:
The patch has been already written: http://lwn.net/Articles/8634/ I'm
sure theere's a better link, but t
On Wednesday 25 June 2003 12:00, Marcelo E. Magallon wrote:
> On Wed, Jun 25, 2003 at 09:57:57AM +0100, David Goodenough wrote:
> > and remember that many embedded processors still use 486 and 586
> > based chips, and some 386. Lossing 386 might be acceptable in the
> > embedded market (many 38
On Wed, Jun 25, 2003 at 02:52:31AM -0500, Branden Robinson wrote:
> The drawbacks:
> * Someone actually has to write this kernel patch.
http://miaif.lip6.fr/~tarreau/linux-patches/486emulation/
On Wed, 25 Jun 2003, Branden Robinson wrote:
> > Hmm... I'm not sure about this as the last time I used assembler was
> > in the times of real mode DOS, but there is a yet another option:
> > we can patch the kernel so when an invalid opcode occurs, whatever
> > instruction was at CS:EIP gets emu
On Wed, Jun 25, 2003 at 09:57:57AM +0100, David Goodenough wrote:
> and remember that many embedded processors still use 486 and 586
> based chips, and some 386. Lossing 386 might be acceptable in the
> embedded market (many 386 based systems have too little memory to run
> Debian) but loosin
Branden Robinson <[EMAIL PROTECTED]> wrote:
>
> If this indeed feasible, then this is the solution that appeals most to
> me personally.
It certainly is feasible. In fact, such a patch has been in existence
for at least a year.
> Also, Herbert Xu, the 80386 kernel-flavor maintainer, would have
Hi,
On Wed, Jun 25, 2003 at 01:07:12PM +0200, Tollef Fog Heen wrote:
> * Colin Walters
>
> | On Wed, 2003-06-25 at 03:52, Branden Robinson wrote:
> |
> | > I believe it would be a mistake to kill off support for the 80386 chip.
> |
> | Well, we're limited by what we can sanely support. After
* Colin Walters
| On Wed, 2003-06-25 at 03:52, Branden Robinson wrote:
|
| > I believe it would be a mistake to kill off support for the 80386 chip.
|
| Well, we're limited by what we can sanely support. After all, we don't
| support running Debian on a 286. The 386 is really in the same clas
On Wed, Jun 25, 2003 at 04:55:56AM -0400, Colin Walters wrote:
> On Wed, 2003-06-25 at 03:52, Branden Robinson wrote:
> > I believe it would be a mistake to kill off support for the 80386 chip.
>
> Well, we're limited by what we can sanely support. After all, we don't
> support running Debian on
On Wednesday 25 June 2003 08:40, Branden Robinson wrote:
> On Wed, Jun 25, 2003 at 07:47:42AM +0200, Tollef Fog Heen wrote:
> > * GOTO Masanori
> >
> > | - NPTL/TLS support. NPTL currently supports i486 and later because
> > | pthread_spin_trylock uses cmpxchgl instruction (well, it's not
>
On Wed, 2003-06-25 at 03:52, Branden Robinson wrote:
> I believe it would be a mistake to kill off support for the 80386 chip.
Well, we're limited by what we can sanely support. After all, we don't
support running Debian on a 286. The 386 is really in the same class
nowadays, in my opinion anyw
On Fri, Jun 20, 2003 at 09:51:07AM +0200, Matthias Klose wrote:
> The solution I would favour would be:
>
> - drop the i386 support
>
> - keep the i386 architecture name
>
> - let dpkg-architecture output the new configuration string
> (i.e. i486-linux)
>
> - if anybody wants to start the min
On Wed, Jun 25, 2003 at 07:47:42AM +0200, Tollef Fog Heen wrote:
> * GOTO Masanori
>
> | - NPTL/TLS support. NPTL currently supports i486 and later because
> | pthread_spin_trylock uses cmpxchgl instruction (well, it's not
> | difficult to support i386, but imagine pthread on i386 with
* GOTO Masanori
| - NPTL/TLS support. NPTL currently supports i486 and later because
| pthread_spin_trylock uses cmpxchgl instruction (well, it's not
| difficult to support i386, but imagine pthread on i386 with the
| max clock (I recall it was 20MHz?) speed and memory...)
33MHz,
At Tue, 24 Jun 2003 11:32:17 -0400,
Matt Zimmerman wrote:
>
> On Tue, Jun 24, 2003 at 01:47:55PM +0900, GOTO Masanori wrote:
>
> > At 21 Jun 2003 00:27:18 +0200,
> > Mathieu Roy wrote:
> > > RedHat provide glibc for i386, i586 and i686. Why doesn't Debian
> > > provide several packages for i*86 w
On Tue, Jun 24, 2003 at 01:47:55PM +0900, GOTO Masanori wrote:
> At 21 Jun 2003 00:27:18 +0200,
> Mathieu Roy wrote:
> > RedHat provide glibc for i386, i586 and i686. Why doesn't Debian
> > provide several packages for i*86 when the package can be optimized a
> > lot depending on the CPU type?
>
Hi Arnd Bergmann,
> On Tuesday 24 June 2003 02:00, Adam Heath wrote:
>> On Tue, 24 Jun 2003, "Martin v. Löwis" wrote:
>> > In g++ 3.2, this code was distributed as "i386", and nobody noticed
>> > that it doesn't work on i386 for quite some time. In gcc 3.3, an
>> > implementation is provided that
At 21 Jun 2003 00:27:18 +0200,
Mathieu Roy wrote:
> RedHat provide glibc for i386, i586 and i686. Why doesn't Debian
> provide several packages for i*86 when the package can be optimized a
> lot depending on the CPU type?
We're planning. i686 optimized binary does not work on my machine, so
it's
At Sat, 21 Jun 2003 12:11:36 +0200,
Erwan MAS wrote:
> Please keep , a i386 or i586 architecture , for the via C3 processor .
> i686 architecture is not compatible with C3 .
>
> This processor is very used in the Via EPIA motherboard :
>
> See :
> http://www.viavpsd.com/product/epia_mini_itx_spe
"Martin v. L?wis" <[EMAIL PROTECTED]> wrote:
> __asm__ __volatile__ ("lock; xaddl %0,%2"
> : "=r" (__result)
> : "0" (__val), "m" (*__mem)
> : "memory");
> In particular, the lock prefix is not available on i386. Since this
On Mon, Jun 23, 2003 at 07:00:21PM -0500, Adam Heath wrote:
> On Tue, 24 Jun 2003, "Martin v. Löwis" wrote:
> >
> > static inline _Atomic_word
> > __attribute__ ((__unused__))
> > __exchange_and_add (volatile _Atomic_word *__mem, int __val)
> > {
> >register _Atomic_word __result;
> >__asm_
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On Tuesday 24 June 2003 02:00, Adam Heath wrote:
> On Tue, 24 Jun 2003, "Martin v. Löwis" wrote:
> > In g++ 3.2, this code was distributed as "i386", and nobody noticed that
> > it doesn't work on i386 for quite some time. In gcc 3.3, an
> > implementa
On Tue, 24 Jun 2003, "Martin v. Löwis" wrote:
> John Goerzen wrote:
>
> > Nobody has even explained WHY we have this issue. The summary posted on the
> > bug report just said that there is a problem with atomicity.h, not what the
> > problem is or why it exists.
>
> Just look at the file for your
John Goerzen wrote:
Nobody has even explained WHY we have this issue. The summary posted on the
bug report just said that there is a problem with atomicity.h, not what the
problem is or why it exists.
Just look at the file for yourself. It is easy enough to see: it uses
inline assembly that is on
On Mon, Jun 23, 2003 at 01:54:43PM -0500, Adam Majer wrote:
> On Mon, Jun 23, 2003 at 12:41:48PM -0500, John Goerzen wrote:
> > On Mon, Jun 23, 2003 at 08:00:07PM +1000, Herbert Xu wrote:
> > > John Goerzen <[EMAIL PROTECTED]> wrote:
> > > Talk is cheap. If you can come up with a solution to the C
On Monday 23 June 2003 19:41, John Goerzen wrote:
> On Mon, Jun 23, 2003 at 08:00:07PM +1000, Herbert Xu wrote:
> > John Goerzen <[EMAIL PROTECTED]> wrote:
> > Talk is cheap. If you can come up with a solution to the C++ problem
> > that ignited this debate then i386 would be safe.
>
> Nobody has
On Mon, Jun 23, 2003 at 12:41:48PM -0500, John Goerzen wrote:
> On Mon, Jun 23, 2003 at 08:00:07PM +1000, Herbert Xu wrote:
> > John Goerzen <[EMAIL PROTECTED]> wrote:
> > Talk is cheap. If you can come up with a solution to the C++ problem that
> > ignited this debate then i386 would be safe.
>
On Mon, Jun 23, 2003 at 08:00:07PM +1000, Herbert Xu wrote:
> John Goerzen <[EMAIL PROTECTED]> wrote:
> Talk is cheap. If you can come up with a solution to the C++ problem that
> ignited this debate then i386 would be safe.
Nobody has even explained WHY we have this issue. The summary posted on
John Goerzen <[EMAIL PROTECTED]> wrote:
>
> This is a disturbing trend. You can't claim that Debian is usable on a
> machine if it requires another machine or Internet access to work basically.
>
> And no, there are not necessarily other machines reachable with scp, since
> some of these machine
On Sun, Jun 22, 2003 at 09:52:17AM +0200, Adam Borowski wrote:
> On Sat, 21 Jun 2003, John Goerzen wrote:
> > On Fri, Jun 20, 2003 at 03:28:02PM +0200, Adam Borowski wrote:
> > > Note that my idea was about patching the kernel that so the newer opcodes
> > > would be emulated in software. Everyth
On Sun, Jun 22, 2003 at 09:52:17AM +0200, Adam Borowski wrote:
> On Sat, 21 Jun 2003, John Goerzen wrote:
> > On Fri, Jun 20, 2003 at 03:28:02PM +0200, Adam Borowski wrote:
> > > Note that my idea was about patching the kernel that so the newer opcodes
> > > would be emulated in software. Everyth
On Sun, Jun 22, 2003 at 11:24:57AM +0200, "Martin v. Löwis" wrote:
> John Goerzen wrote:
>
> >As I say this, I'm sure people can say the same about i486 and even i386
> >machines. Why exactly do we need to remove this support?
>
> Read the bug report with the number you put in your Subject.
Whi
On Sun, Jun 22, 2003 at 12:06:16PM +0200, Andreas Barth wrote:
> * "Martin v. Löwis" ([EMAIL PROTECTED]) [030622 11:50]:
> > problem here (C++ ABI compatibility with other Linux distributions). The
> > discussion is now about *how* to fix this bug:
> > 1. just bump minimum supported i386-family pr
On Sun, 2003-06-22 at 00:48, Adam Majer wrote:
> I once read somewhere that you should _never_ compile in 486
> optimizations for use in processors other than the 486. Apparently
> since 486 optimized code is padded a lot with NOPs.
>
> Apparently you are much better off on a Pentium or Athlon w
On Sun, Jun 22, 2003 at 02:46:12PM +0100, Andrew Suffield wrote:
> > Apparently you are much better off on a Pentium or Athlon with
> > i386 optimized code than i486 optimized one.
> I vaguely recall something similar about the i586.
FWIK, almost everything that can be done in two ways on ix86, li
On Sat, Jun 21, 2003 at 11:48:26PM -0500, Adam Majer wrote:
> Sebastian Kapfer wrote:
> >I'd drop the sub-pentiums (i.e. 386 and 486) entirely. Not that my vote
> >would count...
> >
>
> I once read somewhere that you should _never_ compile in 486
> optimizations for use in processors other than
Andreas Barth wrote:
> * "Martin v. Löwis" ([EMAIL PROTECTED]) [030622 11:50]:
>
>>problem here (C++ ABI compatibility with other Linux distributions). The
>>discussion is now about *how* to fix this bug:
>>1. just bump minimum supported i386-family processor to i486
>
> 1a. like 1, but just for
* "Martin v. Löwis" ([EMAIL PROTECTED]) [030622 11:50]:
> problem here (C++ ABI compatibility with other Linux distributions). The
> discussion is now about *how* to fix this bug:
> 1. just bump minimum supported i386-family processor to i486
1a. like 1, but just for c++-packages.
> 2. like 1, but
Hi all,
I feel this whole discussion is somehow going into the wrong direction. What
does it matter now whether we drop support for i386 and i486 (and possibly
more), or just i386? Sooner or later we'll have the same problem (of changing
the arch support being so difficult) again, if not with
John Goerzen wrote:
While we're at it, I fail to see the logic of removing support for i386
while we still support m68k.
Because there is a bug that only applies to i386 (see the subject). I
wish everybody would focus on fixing this specific bug. There may be
many good or bad things that can be s
John Goerzen wrote:
As I say this, I'm sure people can say the same about i486 and even i386
machines. Why exactly do we need to remove this support?
Read the bug report with the number you put in your Subject.
Regards,
Martin
On Sat, Jun 21, 2003 at 12:37:21PM -0500, John Goerzen wrote:
> On Fri, Jun 20, 2003 at 09:11:41PM +0200, Cyrille Chepelov wrote:
> > Hmmm. Until all of glibc, the kernel and gcc deprecate and discard support
> > for 386 and 486, I'd love if I could keep my home edgge router running the
> > way it
On Sat, 21 Jun 2003, John Goerzen wrote:
> On Fri, Jun 20, 2003 at 03:28:02PM +0200, Adam Borowski wrote:
> > Note that my idea was about patching the kernel that so the newer opcodes
> > would be emulated in software. Everything would still work even on a 386,
> > just slower -- and the speed d
Sebastian Kapfer wrote:
I'd drop the sub-pentiums (i.e. 386 and 486) entirely. Not that my vote
would count...
I once read somewhere that you should _never_ compile in 486
optimizations for use in processors other than the 486. Apparently
since 486 optimized code is padded a lot with NOPs.
Appare
On Fri, Jun 20, 2003 at 03:28:02PM +0200, Adam Borowski wrote:
> On Fri, 20 Jun 2003, Stephen Stafford wrote:
> > On Fri, Jun 20, 2003 at 02:25:52PM +0200, Adam Borowski wrote:
> > > What about perusing the INT 6 idea, and going all the way up to i686?
> > While I support the removal of 386 support
On Fri, Jun 20, 2003 at 02:25:52PM +0200, Adam Borowski wrote:
> What about perusing the INT 6 idea, and going all the way up to i686?
> As i686 is already like ten(?) years old, I would say 99.9% [1] machines
> that run sarge are 686 and higher -- thus, moving to i686-specific
> optimizations wo
On Fri, Jun 20, 2003 at 09:11:41PM +0200, Cyrille Chepelov wrote:
> Hmmm. Until all of glibc, the kernel and gcc deprecate and discard support
> for 386 and 486, I'd love if I could keep my home edgge router running the
> way it is thank you very much (and I'm happy with the great job the Security
Sven Luther <[EMAIL PROTECTED]> wrote:
[...]
> Come on, we already support 11 or so arches officially, and a bunch of
> other unofficially, surelly this would not be so expensive for us.
IMHO it's better to be coherent with the ARCH name. If i386 arch is no
more supported, let's go to the ne
On Sat, Jun 21, 2003 at 02:13:03PM +0200, Allan Sandfeld Jensen wrote:
> server, and it's pleanty fast. But more specialized libraries for i686 would
> be a welcomed thing, both the scheduling and additional instructions can give
> _significant_ speed-ups for many applications.
Prove it or lose
On Friday 20 June 2003 15:40, Josip Rodin wrote:
> On Fri, Jun 20, 2003 at 02:25:52PM +0200, Adam Borowski wrote:
> > As i686 is already like ten(?) years old,
>
> I was intrigued by this statement and went to look it up.
>
> CPU: Released:
> -
> 80386 1985
On Fri, Jun 20, 2003 at 09:51:07AM +0200, Matthias Klose wrote:
| Package: general
| Severity: serious
| Tags: sarge, sid
|
| [please don't reassign to any gcc/libstdc++ package]
|
| Nathanel's summary:
| http://lists.debian.org/debian-devel/2003/debian-devel-200304/msg02112.html
|
| A list of p
Aaron Lehmann <[EMAIL PROTECTED]> wrote:
> On Sat, Jun 21, 2003 at 03:06:17AM +0200, Sam Hocevar wrote:
>>> Really? Seems wrong to me.
>>Indeed. MMX and PPro are orthogonal features.
> Wasn't there "Pentium MMX" in between? I have at least one computer
> with one of those processors.
They a
On Sat, Jun 21, 2003 at 03:06:17AM +0200, Sam Hocevar wrote:
> > Really? Seems wrong to me.
>
>Indeed. MMX and PPro are orthogonal features.
Wasn't there "Pentium MMX" in between? I have at least one computer
with one of those processors.
On Fri, Jun 20, 2003 at 09:51:07AM +0200, Matthias Klose wrote:
> Package: general
> Severity: serious
> Tags: sarge, sid
>
> [please don't reassign to any gcc/libstdc++ package]
>
> Nathanel's summary:
> http://lists.debian.org/debian-devel/2003/debian-devel-200304/msg02112.html
>
> A list of p
On Fri, Jun 20, 2003, Sebastian Kapfer wrote:
> > Also P MMX seems meaningless to me. MMX was, I think, introduced in
> > Pentium Pro (which is still a i586 according to uname)
>
> Really? Seems wrong to me.
Indeed. MMX and PPro are orthogonal features.
--
Sam.
Le ven 20/06/2003 à 15:39, Mathieu Roy a écrit :
> Skipping 386 for 486 seems acceptable because nowadays, a distro
> requires more HD space and RAM than it's possible to add with usual
> 386 motherboards, but dropping all Pentiums until Pentium II
> generation seems completely foolish. I hope I mi
On Fri, 20 Jun 2003 23:40:13 +0200, Cyrille Chepelov wrote:
>> I'd drop the sub-pentiums (i.e. 386 and 486) entirely. Not that my vote
>> would count...
>
> Hmmm. Until all of glibc, the kernel and gcc deprecate and discard
> support for 386 and 486,
One of them is enough to be a showstopper.
>
We run lot of P100 and P233 with hostap to provide internet access to
our customers with 2.4Ghz wi-fi. And some customers have P200,233MMX as
firewalls/mail servers/proxy.
I think 386 boxes are really slow ... and the admins of that boxes
have faster boxes to build specific packages.. but maybe
n
Cyrille Chepelov <[EMAIL PROTECTED]> a tapoté :
> Le Fri, Jun 20, 2003, à 07:15:45PM +0200, Sebastian Kapfer a écrit:
>
> > > but dropping all Pentiums until Pentium II generation
> > > seems completely foolish. I hope I misunderstood your message.
> >
> > I'd drop the sub-pentiums (i.e. 386 and
Le Fri, Jun 20, 2003, à 07:15:45PM +0200, Sebastian Kapfer a écrit:
> > but dropping all Pentiums until Pentium II generation
> > seems completely foolish. I hope I misunderstood your message.
>
> I'd drop the sub-pentiums (i.e. 386 and 486) entirely. Not that my vote
> would count...
Hmmm. Un
On Fri, 2003-06-20 at 13:15, Sebastian Kapfer wrote:
> I'd drop the sub-pentiums (i.e. 386 and 486) entirely. Not that my vote
> would count...
Making the cut at the Pentium as opposed to i486 would have some
benefits; the Pentium introduced some new instructions such as cmpxchg8b
that are actual
On Fri, Jun 20, 2003 at 01:58:08PM -0500, Adam Heath wrote:
> On Fri, 20 Jun 2003, Matt Zimmerman wrote:
> > They will if they want security updates for their firewall.
>
> You mean debian provided security updates. Users can always upgrade and
> compile software themselves.
Judging by the volu
On Fri, 20 Jun 2003, Matt Zimmerman wrote:
> On Fri, Jun 20, 2003 at 03:26:08PM +0200, Giacomo A. Catenazzi wrote:
>
> > >1918space and are masqueraded to the outside internet by a firewall/gateway
> > >running Debian on a 486 or low end pentium. I believe this to be a fairly
> > >significant pro
On Fri, 20 Jun 2003 17:20:13 +0200, Mathieu Roy wrote:
> If so, are you kidding? The Pentium classic (i586) was still available
> in 1997.
It is still available even today. Not sure where to get a mainboard for
this beast, but just a week ago I saw it on a price list.
> I know a lot of person wh
On Fri, Jun 20, 2003 at 03:26:08PM +0200, Giacomo A. Catenazzi wrote:
> >1918space and are masqueraded to the outside internet by a firewall/gateway
> >running Debian on a 486 or low end pentium. I believe this to be a fairly
> >significant proportion of our userbase and I'd oppose any move to
>
* Stephen Stafford ([EMAIL PROTECTED]) [030620 15:35]:
> Judging from my random contacts with users, it's a fairly usual setup to see
> a network of higher (500Mhz+) end hardware machines which sit on a LAN in
> 1918space and are masqueraded to the outside internet by a firewall/gateway
> running D
Stephen Stafford <[EMAIL PROTECTED]> writes:
> I'm not fully convinced that moving up to full 686 optimisation has that
> many benefits under all but the highest loads anyway (in userspace at least,
> we already have processor specific kernels). Do you have a link to
> a URL with studies/analysis
On Fri, Jun 20, 2003 at 02:25:52PM +0200, Adam Borowski wrote:
> As i686 is already like ten(?) years old,
I was intrigued by this statement and went to look it up.
CPU:Released:
-
80386 1985
80486 1989
Pentium 1993
Pentium Pro 1
Adam Borowski <[EMAIL PROTECTED]> a tapoté :
> > In any case we need to make clear if we allow 486 optimisation that
> > are not i386 compatible or not.
> What about perusing the INT 6 idea, and going all the way up to i686?
> As i686 is already like ten(?) years old, I would say 99.9% [1] machine
On Fri, Jun 20, 2003 at 03:28:02PM +0200, Adam Borowski wrote:
> On Fri, 20 Jun 2003, Stephen Stafford wrote:
> > On Fri, Jun 20, 2003 at 02:25:52PM +0200, Adam Borowski wrote:
> > > What about perusing the INT 6 idea, and going all the way up to i686?
> > While I support the removal of 386 support
On Fri, Jun 20, 2003 at 02:25:52PM +0200, Adam Borowski wrote:
> I would say 99.9% [1] machines that run sarge are 686 and higher --
Please provide real data that backs this assertion up.
> moving to i686-specific optimizations would be good for the vast
> majority of users
Please provide
On Fri, Jun 20, 2003 at 03:26:08PM +0200, Giacomo A. Catenazzi wrote:
>
> Stephen Stafford wrote:
>
> >While I support the removal of 386 support, I absolutely and strenuously
> >object to going to 686. 686 isn't all that old at all (1997 IIRC), and I
> >use a nunber of 4/586 machines still (I h
1 - 100 of 108 matches
Mail list logo
