On Sat, Dec 12, 2020, at 13:09, Adrian Bunk wrote:
> 3. Computers that do support MMX and SSE2, but do not support 64bit.
The "Centrino" Pentium-M that you can find on a reasonably lot of still-working
ThinkPads (the T4x series and similar X/R series of the time), for example.
Note that this
Hello. 32-bit Pentium 4 user reading this out of personal interest
throwing in a comment.
If the choice is to primarily support pae or non pae for 32-bit moving
forward, then I suggest non-pae for the reason that everyone can use it.
If you have more than 4GB of memory you probably have a 64-bit
Am Sa, Dez 12, 2020 at 20:27:16 + schrieb Steve McIntyre:
It's still quite new, but we have a package in the archive for this now:
https://tracker.debian.org/pkg/debian-crossgrader
Well, yes, but it is only in unstable.
I tried to install it but apt wanted to replace many packages. Using
On Sat, Dec 12, 2020 at 08:27:16PM +, Steve McIntyre wrote:
> Stephan wrote:
> >Am Sa, Dez 12, 2020 at 18:09:02 +0200 schrieb Adrian Bunk:
> >>4. People who wrongly installed i386 on amd64-capable hardware.
> >
> >Well, some releases ago befor multi-arch I used to install i386 even on
>
On Wed, Dec 16, 2020 at 02:47:22PM -0500, Devops PK Carlisle LLC wrote:
I understand your point about 32 bit being updated forever, and perhaps
it does not need to be. Perhaps the happy medium would be to freeze it
at some point, but leave it available as-is so that legacy software with
32 bit
I understand your point about 32 bit being updated forever, and perhaps
it does not need to be. Perhaps the happy medium would be to freeze it
at some point, but leave it available as-is so that legacy software with
32 bit dependencies can still be installed and run. In other words, no
longer
On Sun, Dec 13, 2020 at 11:40:29AM -0500, Devops PK Carlisle LLC wrote:
Being philosophically opposed to throwing a good machine into a
landfill, I tend to hang on to equipment for a long time. My
play/experimentation and last-ditch backup box is a 10 year old laptop.
I hear that, but at least
On 15.12.20 01:55, Russ Allbery wrote:
> Increasingly most of the people who work on Debian don't have i386
> hardware lying around, particularly i386 hardware that requires an i386
> kernel or that exercises the full range of older boot processes. If you
> do, testing and reporting good bugs
On Mon, Dec 14, 2020 at 05:13:54PM -0500, Calum McConnell wrote:
> Since (AFAIK) there is a substantial speed penalty to installing a non-pae
> kernel on a -pae processor,
The penalty is not using more than 4 Gb of RAM (the only related speed
penalty I know about is using PAE vs not using it).
--
On Mon, Dec 14, 2020 at 11:36 PM Adrian Bunk wrote:
> A bigger worry for i386 would be the availability of microcode updates
This is also a big problem for amd64, since only the newest
generations of Intel processors get BIOS/UEFI and or microcode
updates, so lots of amd64 users (including
Calum McConnell writes:
> A very fair point, and quite equitably put. If I was remotely
> comfortable tweaking kernels, or used a 32 bit machine regularly, I
> would be more comfortable volunteering. As it is, I have only really
> learned to maintain packages in the past few months, and I feel
On Mon, Dec 14, 2020 at 02:54:37PM -0800, Russ Allbery wrote:
>
> The quantity of hardware is useful data, but I think this is also a place
> where it's important to stress the specific problem that Debian has,
> namely that we need people to do the work.
>...
The list of Debian release
On Mon, 2020-12-14 at 14:54 -0800, Russ Allbery wrote:
> Calum McConnell writes:
> > The point I'm making is that i386 processors are still incredibly
> > common, and we shouldn't abandon their users.
>
> Not abandoning users is a powerful motivating force, but it still has to
> succeed in
In practice, whether or not i386 will be dropped as release archticture
in bullseye will likely be decided by whether I will stay the only
committed porter, or whether other people will ASAP send (belatedly)
replies to the proter roll call [1].
This discussion started due to lack of people
Hi,
Quoting Russ Allbery (2020-12-14 23:54:37)
> > The point I'm making is that i386 processors are still incredibly common,
> > and we shouldn't abandon their users.
>
> Not abandoning users is a powerful motivating force, but it still has to
> succeed in motivating people. Debian can't make a
On Mon, Dec 14, 2020 at 01:22:11PM +0100, Ben Hutchings wrote:
> On Sun, 2020-12-13 at 01:53 -0800, Steve Langasek wrote:
> [...]
> > While the ongoing
> > costs of maintaining a full port were a consideration, of equal concern was
> > the fact that we believed we would not be able to provide
Calum McConnell writes:
> As I showed in my (slightly over dramatic, very over-long) email this
> morning, there are more people with i386 kernels than there are total
> users of every other release architecture. Even if you only look at
> non-pae kernels, its still about double the total
On Mon, 2020-12-14 at 10:02 -0800, Russ Allbery wrote:
> One possible intermediate option shy of dropping the i386 architecture
> would be to drop the i386 kernel and instead help all i386 installs
> switch
> to the amd64 kernel while still running i386 binaries. (That said, this
> will
Ben Hutchings writes:
> I agree that kernel security support for i386 is seriously lacking.
> The Spectre mitigations were actually available for both x86
> architectures at the same time, but the initial Meltdown mitigation was
> amd64-specific and was not extended to i386 until Linux 4.19.
On Sun, 2020-12-13 at 01:53 -0800, Steve Langasek wrote:
[...]
> While the ongoing
> costs of maintaining a full port were a consideration, of equal concern was
> the fact that we believed we would not be able to provide security support
> for the architecture as a whole at par with other
Being philosophically opposed to throwing a good machine into a
landfill, I tend to hang on to equipment for a long time. My
play/experimentation and last-ditch backup box is a 10 year old laptop.
During COVID I spent a little time updating and upgrading it and came up
with this:
On Sat, Dec 12, 2020 at 06:09:02PM +0200, Adrian Bunk wrote:
> > Ubuntu have chosen to support the first use-case, and only the first
> > use-case. They longer ship a complete, bootable i386 operating system;
> > instead, they have an i386 second-class-citizen architecture that
> > is sufficient
Hi all,
As someone who runs amd64/i386 multiarch, this statement from Adrian:
> i386 hardware is so numerous and widely spread, that every tiny fraction
> of i386 users might be more users than half of our release architectures
> combined. It is not even clear whether this is just an
Then there was the short netbook boom, but AFAIR some early ones
had 64bit CPUs but 32bit-only firmware.
My memory is that at the height of the boom the dominant processors
were the N270 and N280, which are 32-bit only. By the time 64-bit
netbook processors showed up the boom was on the
On Sat, 12 Dec 2020 at 18:09:02 +0200, Adrian Bunk wrote:
> 3. Computers that do support MMX and SSE2, but do not support 64bit.
Right, that's basically the second use-case I mentioned, but moving the
boundary for what we do and don't support to be more modern. We could
put the boundary anywhere
Stephan wrote:
>Am Sa, Dez 12, 2020 at 18:09:02 +0200 schrieb Adrian Bunk:
>>4. People who wrongly installed i386 on amd64-capable hardware.
>
>Well, some releases ago befor multi-arch I used to install i386 even on
>am64-capable hardware if ram was quite low (=< 8GB) and if the chance
>wasnât
Am Sa, Dez 12, 2020 at 18:09:02 +0200 schrieb Adrian Bunk:
4. People who wrongly installed i386 on amd64-capable hardware.
Well, some releases ago befor multi-arch I used to install i386 even on
am64-capable hardware if ram was quite low (=< 8GB) and if the chance
wasn’t that low that you
On Tue, Dec 08, 2020 at 05:46:26PM +, Simon McVittie wrote:
>...
> I think it's necessary to consider what the purpose of the i386 port is,
> and set expectations and an appropriate baseline based on that.
>
> I see two possible use-cases for i386:
>
> 1. It's a compatibility layer for
28 matches
Mail list logo
