Dropping i386 non-PAE as a supported kernel flavour in Precise Pangolin

classic Classic list List threaded Threaded
38 messages Options
12
Reply | Threaded
Open this post in threaded view
|

Re: Dropping i386 non-PAE as a supported kernel flavour in Precise Pangolin

Martin Pool-3
On 11 November 2011 23:18, John Arbash Meinel <[hidden email]> wrote:

> ...
>
>>> Computers are replaced as frequently as refrigerators by people who don't
>>> care how quickly it loads a page or makes ice: when it stops turning on.
>>
>> Those people are probably not upgrading their refrigerator firmware
>> all that often either.  They may not want a major new OS release.
>> They might install an update/backport of a particular app.
>>
>> There is a group of people who want the latest-and-greatest software
>> on old or small hardware, but they're necessarily the crowd you're
>> describing here.
>
> I think you mean 'not necessarily'.

Yes, it was just a typo.

>  I agree, though I know we dealt with a
> lot of this in our 'bzr python-compatibility' discussions. In that
> particular case it was "we don't want to upgrade the OS, or even the system
> libraries/python version, but we do want to upgrade a given application".
> Which is a different level than "we don't want to upgrade our hardware, but
> we do want to upgrade all of the OS and applications."
>
> Certainly it is a bit different when one upgrade is $$ and the other is
> free.
>
> Still, it seems an open question for how to handle users that want the
> latest-and-greatest X, but don't want the latest-and-greatest Y, even though
> X depends on Y.

Right, that's why I think many of those people are better served by
updating whatever particular apps they care about.  That's why we
provide current-stable and current-beta bzr ppas going back to quite
old OS releases: telling them to upgrade the whole thing won't fly.

Few of those apps are are not going to need or even notice a newer kernel.

Upgrading the kernel and X on old hardware that's already running a
supported OS release is generally a risk with little reward.

m

--
ubuntu-devel mailing list
[hidden email]
Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
Reply | Threaded
Open this post in threaded view
|

Re: Dropping i386 non-PAE as a supported kernel flavour in Precise Pangolin

Dotan Cohen
In reply to this post by Martin Pool-3
On Fri, Nov 11, 2011 at 09:19, Martin Pool <[hidden email]> wrote:
>> Computers are replaced as frequently as refrigerators by people who don't
>> care how quickly it loads a page or makes ice: when it stops turning on.
>
> Those people are probably not upgrading their refrigerator firmware
> all that often either.  They may not want a major new OS release.
> They might install an update/backport of a particular app.
>

I am not aware of replacement refrigerator software. I do know of
people who for a variety of reasons continue to use perfectly
serviceable hardare from the early 2000S. In fact, one library that I
service is still using some ancient machine for their catalog that was
running on Windows 98 until a few months ago. It is now an Ubuntu
machine running wine. I do not remember which version of Ubuntu, but
it runs perfectly fine on that 13-year-old hardware.


> There is a group of people who want the latest-and-greatest software
> on old or small hardware, but they're necessarily the crowd you're
> describing here.
>

I doubt that these people need latest-and-greatest software, but they
do need supported software. That is the argument for keeping the
non-PAE kernel in the LTS release.


--
Dotan Cohen

http://gibberish.co.il
http://what-is-what.com

--
ubuntu-devel mailing list
[hidden email]
Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
Reply | Threaded
Open this post in threaded view
|

Re: Dropping i386 non-PAE as a supported kernel flavour in Precise Pangolin

John Meinel

If the hardware is from 2000+ then it is likely to have PAE support. And running Win 98 just means it wasn't older than that. Win 2000 was a business version, and XP as the next consumer version didn't come out until Oct 2001.

What I saw on Intel's site is that roughly 1999 is when everything had PAE.

So the question is how old is too old, eventually there will be a cutoff, 12 years is pretty long. Plus the time that O is still supported. So close to 15 years total.

John
=:->

On Nov 13, 2011 6:21 PM, "Dotan Cohen" <[hidden email]> wrote:
On Fri, Nov 11, 2011 at 09:19, Martin Pool <[hidden email]> wrote:
>> Computers are replaced as frequently as refrigerators by people who don't
>> care how quickly it loads a page or makes ice: when it stops turning on.
>
> Those people are probably not upgrading their refrigerator firmware
> all that often either.  They may not want a major new OS release.
> They might install an update/backport of a particular app.
>

I am not aware of replacement refrigerator software. I do know of
people who for a variety of reasons continue to use perfectly
serviceable hardare from the early 2000S. In fact, one library that I
service is still using some ancient machine for their catalog that was
running on Windows 98 until a few months ago. It is now an Ubuntu
machine running wine. I do not remember which version of Ubuntu, but
it runs perfectly fine on that 13-year-old hardware.


> There is a group of people who want the latest-and-greatest software
> on old or small hardware, but they're necessarily the crowd you're
> describing here.
>

I doubt that these people need latest-and-greatest software, but they
do need supported software. That is the argument for keeping the
non-PAE kernel in the LTS release.


--
Dotan Cohen

http://gibberish.co.il
http://what-is-what.com

--
ubuntu-devel mailing list
[hidden email]
Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel

--
ubuntu-devel mailing list
[hidden email]
Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
Reply | Threaded
Open this post in threaded view
|

Re: Dropping i386 non-PAE as a supported kernel flavour in Precise Pangolin

Jonathan Carter (highvoltage)
In reply to this post by Tim Gardner-2
Hi Tim

On 11-11-09 04:43 PM, Tim Gardner wrote:

> Per discussion at UDS the kernel team is proposing to drop the non-PAE
> i386 flavour. The upgrade path for non-PAE users will be the PAE kernel.
> Those CPUs that do not have i686 and PAE support will be orphaned. To
> the best of my knowledge, these include Intel CPUs prior to Pentium II,
> 400Mhz Pentium M, VIA C3, and Geode LX. As far as I know, there are no
> laptop or desktop class CPUs being produced that do not meet these
> minimum requirements.
>
> Before I do something that is difficult to revert, I would like to hear
> from the development community why we should continue to maintain a
> kernel flavour that is (in my opinion) getting increasingly low
> utilization. It is my feeling that an extremely high percentage of users
> of the non-PAE kernel have a CPU that is PAE capable.

This will really suck for many people who use those non-PAE capable CPUs
in thin clients, which would otherwise work more or less ok on 12.04. In
my dayjob we have several thousands of them out there, they're old
machines but they work well enough for the clients not to replace them yet.

> If there is sufficient community demand (and support), I would be
> willing to sponsor the first non-PAE kernel upload to Universe.

How does that work? Would there need to be a completely separate source
package for the non-PAE version so that it could go into universe? Would
a kernel in universe have the same security update requirements as the
kernel packages in main?

-Jonathan

--
ubuntu-devel mailing list
[hidden email]
Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
Reply | Threaded
Open this post in threaded view
|

Re: Dropping i386 non-PAE as a supported kernel flavour in Precise Pangolin

Dotan Cohen
In reply to this post by John Meinel
On Sun, Nov 13, 2011 at 19:58, John Meinel <[hidden email]> wrote:

> If the hardware is from 2000+ then it is likely to have PAE support. And
> running Win 98 just means it wasn't older than that. Win 2000 was a business
> version, and XP as the next consumer version didn't come out until Oct 2001.
>
> What I saw on Intel's site is that roughly 1999 is when everything had PAE.
>
> So the question is how old is too old, eventually there will be a cutoff, 12
> years is pretty long. Plus the time that O is still supported. So close to
> 15 years total.
>
> John

Thanks, John. The next time I am in that library I will check exactly
what hardware is in there, and which Ubuntu it is running. I think
that the point was made, though: Ubuntu is
often/sometimes/occasionally used to breathe new life into working
hardware. Please do not take that benefit away.

--
Dotan Cohen

http://gibberish.co.il
http://what-is-what.com

--
ubuntu-devel mailing list
[hidden email]
Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
Reply | Threaded
Open this post in threaded view
|

Re: Dropping i386 non-PAE as a supported kernel flavour in Precise Pangolin

Daniel Chen-2


On Nov 13, 2011 6:03 PM, "Dotan Cohen" <[hidden email]> wrote:
> that the point was made, though: Ubuntu is
> often/sometimes/occasionally used to breathe new life into working
> hardware. Please do not take that benefit away.

Given the points in this discussion, I think that it's reasonable to propose that a non-PAE kernel remain supported for 12.04 LTS. At some point the maintenance burden on the Canonical kernel team far outweighs the common use case of current minus three years of computing hardware.

Cheers,
-Dan


--
ubuntu-devel mailing list
[hidden email]
Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
Reply | Threaded
Open this post in threaded view
|

Re: Dropping i386 non-PAE as a supported kernel flavour in Precise Pangolin

Forest Bond
In reply to this post by John Meinel
Hi John,

On Fri, Nov 11, 2011 at 03:44:15PM +0100, John Arbash Meinel wrote:

> PAE was first added in Pentium Pro in 1995. So your servers have to
> be ~16 years old to not support it.
>
> So yes "a decade old" is still new enough, 2 decades old is not.
> Looking here:
>   http://en.wikipedia.org/wiki/Physical_Address_Extension
>
> I'm trying to correlate that with:
>   http://www.intel.com/pressroom/kits/quickrefyr.htm
>
> And it looks like there is a 400MHz processor introduced around
> 1999. So you're still looking at 1 decade being new enough, but
> slightly more than that not.
I think some non-Intel CPUs made in the last 10 years would be affected.  AMD
Geode and VIA C3 come to mind.  I think that the replacements for these products
do support PAE.

Unfortunately, I'm short on both details and time.  Maybe someone else can
provide more information.

Thanks,
Forest
--
Forest Bond
http://www.alittletooquiet.net
http://www.rapidrollout.com

--
ubuntu-devel mailing list
[hidden email]
Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel

signature.asc (205 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Dropping i386 non-PAE as a supported kernel flavour in Precise Pangolin

Jamie Strandboge-3
In reply to this post by Tim Gardner-2
On Wed, 2011-11-09 at 14:43 -0700, Tim Gardner wrote:
> Per discussion at UDS the kernel team is proposing to drop the non-PAE
> i386 flavour. The upgrade path for non-PAE users will be the PAE kernel.
> Those CPUs that do not have i686 and PAE support will be orphaned. To
> the best of my knowledge, these include Intel CPUs prior to Pentium II,
> 400Mhz Pentium M, VIA C3, and Geode LX. As far as I know, there are no
> laptop or desktop class CPUs being produced that do not meet these
> minimum requirements.

The Geode LX AFAIK is certainly still in use. I know when I was looking
to buy an embedded system earlier this year, I came across quite a few
of these in new systems.

What about simply demoting the binary packages for this flavor, but
still build it? We wouldn't have to explicitly test it for SRUs/security
updates or deal with it with LTS backorts, but it would presumably still
be in ok shape since we would be actively testing the i686 pae kernel.
It could also provide a (albeit manual) fallback for people where the
pae kernel doesn't work on their system.

--
Jamie Strandboge             | http://www.canonical.com

--
ubuntu-devel mailing list
[hidden email]
Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel

signature.asc (853 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Dropping i386 non-PAE as a supported kernel flavour in Precise Pangolin

Forest Bond
Hi,

On Mon, Nov 14, 2011 at 12:24:22PM -0600, Jamie Strandboge wrote:

> On Wed, 2011-11-09 at 14:43 -0700, Tim Gardner wrote:
> > Per discussion at UDS the kernel team is proposing to drop the non-PAE
> > i386 flavour. The upgrade path for non-PAE users will be the PAE kernel.
> > Those CPUs that do not have i686 and PAE support will be orphaned. To
> > the best of my knowledge, these include Intel CPUs prior to Pentium II,
> > 400Mhz Pentium M, VIA C3, and Geode LX. As far as I know, there are no
> > laptop or desktop class CPUs being produced that do not meet these
> > minimum requirements.
>
> The Geode LX AFAIK is certainly still in use. I know when I was looking
> to buy an embedded system earlier this year, I came across quite a few
> of these in new systems.
>
> What about simply demoting the binary packages for this flavor, but
> still build it? We wouldn't have to explicitly test it for SRUs/security
> updates or deal with it with LTS backorts, but it would presumably still
> be in ok shape since we would be actively testing the i686 pae kernel.
> It could also provide a (albeit manual) fallback for people where the
> pae kernel doesn't work on their system.
I would really appreciate this approach.  I think these CPUs are primarily used
in thin clients, appliances, embedded, etc.  I suspect having the kernel
available in the repos is sufficient in most of those cases.

Thanks,
Forest
--
Forest Bond
http://www.alittletooquiet.net
http://www.rapidrollout.com

--
ubuntu-devel mailing list
[hidden email]
Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel

signature.asc (205 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Dropping i386 non-PAE as a supported kernel flavour in Precise Pangolin

Steve Langasek-6
In reply to this post by Tim Gardner-2
Hi Tim,

On Wed, Nov 09, 2011 at 02:43:28PM -0700, Tim Gardner wrote:
> Per discussion at UDS the kernel team is proposing to drop the
> non-PAE i386 flavour. The upgrade path for non-PAE users will be the
> PAE kernel. Those CPUs that do not have i686 and PAE support will be
> orphaned. To the best of my knowledge, these include Intel CPUs
> prior to Pentium II, 400Mhz Pentium M, VIA C3, and Geode LX. As far
> as I know, there are no laptop or desktop class CPUs being produced
> that do not meet these minimum requirements.

> Before I do something that is difficult to revert, I would like to
> hear from the development community why we should continue to
> maintain a kernel flavour that is (in my opinion) getting
> increasingly low utilization. It is my feeling that an extremely
> high percentage of users of the non-PAE kernel have a CPU that is
> PAE capable.

> If there is sufficient community demand (and support), I would be
> willing to sponsor the first non-PAE kernel upload to Universe.

As I mentioned to you at UDS, I think this is the wrong way to go about
keeping the non-PAE kernel.  *IF* we are going to keep it, it's much more
efficient to build this as an additional, universe-only flavor from the main
source package.  Yes, this would occasionally mean additional work on the
part of the kernel team to keep the config up to date; but the alternative
is that a lot more work would have to be done to manually keep the non-PAE
kernel flavor in sync (syncing git trees, uploading multiple source
packages, archive processing of separate uploads for security updates).

If we're going to do this, let's please do it the right way, from a single
source package that only needs to be updated once.

If continuing to build this from the linux package is a significant
maintenance burden for the kernel team, that's certainly a factor to
consider in deciding whether to drop the package; but I don't understand how
that should be as the delta between the pae and non-pae packages should be
minimal, stable, and require no ongoing manual effort.  If maintaining this
flavor is actively consuming kernel team time, that seems like a fixable
bug.


I certainly agree that we should be delivering PAE to i386 users by default
these days, and I think it's fine to not provide support for installing on
non-PAE systems (which is implied by putting the non-PAE kernel to universe
and making PAE the default kernel in the installer images).  And I certainly
would not expect anyone to spend time supporting a PAE flavor for LTS
backported kernels, given that the purpose of LTS backports is enablement of
*new* hardware.  But unless people are just plain mistaken about what
hardware supports PAE or not, I think this thread is evidence that non-PAE
hardware is still relevant over the 12.04 support timeframe to a number of
our users and we should consider continuing this flavor for 12.04.

--
Steve Langasek                   Give me a lever long enough and a Free OS
Debian Developer                   to set it on, and I can move the world.
Ubuntu Developer                                    http://www.debian.org/
[hidden email]                                     [hidden email]

--
ubuntu-devel mailing list
[hidden email]
Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel

signature.asc (845 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Dropping i386 non-PAE as a supported kernel flavour in Precise Pangolin

Martin Pitt-4
In reply to this post by Jamie Strandboge-3
Jamie Strandboge [2011-11-14 12:24 -0600]:
> What about simply demoting the binary packages for this flavor, but
> still build it? We wouldn't have to explicitly test it for SRUs/security
> updates or deal with it with LTS backorts, but it would presumably still
> be in ok shape since we would be actively testing the i686 pae kernel.

I know that there is not much of an SRU policy left for the kernel,
but that doesn't work. If we expect people to run this kernel, we
can't just break it underneath them and render their systems broken.
We at least need to check that it still boots on a small number of
machines.

That approach would work better if the PAE kernel would be a separate
source package and thus _not_ get the thousands of changes that get
thrown into main kernel in stable updates. But I guess that wouldn't
make maintenance any easier?

Martin
--
Martin Pitt                        | http://www.piware.de
Ubuntu Developer (www.ubuntu.com)  | Debian Developer  (www.debian.org)

--
ubuntu-devel mailing list
[hidden email]
Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel

signature.asc (853 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Dropping i386 non-PAE as a supported kernel flavour in Precise Pangolin

Jamie Strandboge-3
On Tue, 2011-11-15 at 06:53 +0100, Martin Pitt wrote:

> Jamie Strandboge [2011-11-14 12:24 -0600]:
> > What about simply demoting the binary packages for this flavor, but
> > still build it? We wouldn't have to explicitly test it for SRUs/security
> > updates or deal with it with LTS backorts, but it would presumably still
> > be in ok shape since we would be actively testing the i686 pae kernel.
>
> I know that there is not much of an SRU policy left for the kernel,
> but that doesn't work. If we expect people to run this kernel, we
> can't just break it underneath them and render their systems broken.
> We at least need to check that it still boots on a small number of
> machines.
>
> That approach would work better if the PAE kernel would be a separate
> source package and thus _not_ get the thousands of changes that get
> thrown into main kernel in stable updates. But I guess that wouldn't
> make maintenance any easier?
I am in strong agreement with Steve Langasek on this one (which should
be evident since he and I proposed the same thing ;). I think it would
be sufficient to smoke test the kernel to see if it boots. This is way
better for users than putting the non-PAE source in universe-- it would
almost certainly rarely get updated.

--
Jamie Strandboge             | http://www.canonical.com

--
ubuntu-devel mailing list
[hidden email]
Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel

signature.asc (853 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Dropping i386 non-PAE as a supported kernel flavour in Precise Pangolin

Mario Limonciello-2


On Nov 15, 2011 3:44 PM, "Jamie Strandboge" <[hidden email]> wrote:
>
> On Tue, 2011-11-15 at 06:53 +0100, Martin Pitt wrote:
> > Jamie Strandboge [2011-11-14 12:24 -0600]:
> > > What about simply demoting the binary packages for this flavor, but
> > > still build it? We wouldn't have to explicitly test it for SRUs/security
> > > updates or deal with it with LTS backorts, but it would presumably still
> > > be in ok shape since we would be actively testing the i686 pae kernel.
> >
> > I know that there is not much of an SRU policy left for the kernel,
> > but that doesn't work. If we expect people to run this kernel, we
> > can't just break it underneath them and render their systems broken.
> > We at least need to check that it still boots on a small number of
> > machines.
> >
> > That approach would work better if the PAE kernel would be a separate
> > source package and thus _not_ get the thousands of changes that get
> > thrown into main kernel in stable updates. But I guess that wouldn't
> > make maintenance any easier?
>
> I am in strong agreement with Steve Langasek on this one (which should
> be evident since he and I proposed the same thing ;). I think it would
> be sufficient to smoke test the kernel to see if it boots. This is way
> better for users than putting the non-PAE source in universe-- it would
> almost certainly rarely get updated.
>
> --
> Jamie Strandboge             | http://www.canonical.com
>
> --
> ubuntu-devel mailing list
> [hidden email]
> Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
>

Would it maybe be sufficient to add some build dependencies on a virtualization solution and then make sure the kernel loads and what not after the build finishes?


--
ubuntu-devel mailing list
[hidden email]
Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
Reply | Threaded
Open this post in threaded view
|

Re: Dropping i386 non-PAE as a supported kernel flavour in Precise Pangolin

Reinhard Tartler-4
On Di, Nov 15, 2011 at 23:43:15 (CET), Mario Limonciello wrote:

[...]

>
> Would it maybe be sufficient to add some build dependencies on a
> virtualization solution and then make sure the kernel loads and what not
> after the build finishes?

-> https://launchpad.net/autopkgtest
-> http://alioth.debian.org/projects/autopkgtest

It even got some traction again, this time in Debian:

http://lists.debian.org/debian-devel/2011/07/msg00821.html
http://dep.debian.net/deps/dep8/

Cheers,
Reinhard
--
Gruesse/greetings,
Reinhard Tartler, KeyID 945348A4

--
ubuntu-devel mailing list
[hidden email]
Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
Reply | Threaded
Open this post in threaded view
|

Re: Dropping i386 non-PAE as a supported kernel flavour in Precise Pangolin

Tim Gardner-2
In reply to this post by Tim Gardner-2
On 11/09/2011 02:43 PM, Tim Gardner wrote:

> Per discussion at UDS the kernel team is proposing to drop the non-PAE
> i386 flavour. The upgrade path for non-PAE users will be the PAE kernel.
> Those CPUs that do not have i686 and PAE support will be orphaned. To
> the best of my knowledge, these include Intel CPUs prior to Pentium II,
> 400Mhz Pentium M, VIA C3, and Geode LX. As far as I know, there are no
> laptop or desktop class CPUs being produced that do not meet these
> minimum requirements.
>
> Before I do something that is difficult to revert, I would like to hear
> from the development community why we should continue to maintain a
> kernel flavour that is (in my opinion) getting increasingly low
> utilization. It is my feeling that an extremely high percentage of users
> of the non-PAE kernel have a CPU that is PAE capable.
>
> If there is sufficient community demand (and support), I would be
> willing to sponsor the first non-PAE kernel upload to Universe.
>
> https://wiki.ubuntu.com/KernelTeam/Specs/PreciseKernelConfigReview
>
> We'll be conducting a similar survey for powerpc.
>
> rtg
>
> P.S. For those of you that are totally confused by this email, PAE
> (Physical Address Extension) was an addition to 32 bit x86 CPUs that
> allowed them to address more then 4GB physical memory.
>
> http://en.wikipedia.org/wiki/Physical_Address_Extension

Thank you to everyone who responded to this thread.

To summarize, no compelling hard evidence has been presented to change
my original decision. I am opposed to supporting non-PAE CPUs for
another 5 years.

Colin King has developed power and performance profiling data that
indicate the differences between PAE and non-PAE are negligible. I've
also discussed this with OEM regarding possible future LTSP projects and
have concluded it will have no detrimental impact.

Every flavour maintained by the kernel team has an incremental impact,
especially when it comes to test builds and the full packaging cycle.
Every flavour must also be tracked by meta packages. Every flavour has
its unique class of bugs; non-pae has a ginormous and ugly NX emulation
patch that has consumed substantial maintenance resources in the past,
not to mention all of the bugs complaining about memory holes and the
4Gb limit.

The kernel team has limited resources. Obviously I want to apply what
resources we have to the problems that affect the most important
platforms. Furthermore, I anticipate new ARM flavours in the coming
months which will take up any slack afforded by the loss of non-PAE.

It is my recommendation that folks running PAE incapable CPUs stay on
Lucid (10.04), a release for which they'll still receive more then 3
years of official support.

If you feel passionately that I've made an incorrect decision, then I
suggest contacting the Ubuntu technical board.

https://wiki.ubuntu.com/TechnicalBoard

rtg
--
Tim Gardner [hidden email]

--
ubuntu-devel mailing list
[hidden email]
Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
Reply | Threaded
Open this post in threaded view
|

Re: Dropping i386 non-PAE as a supported kernel flavour in Precise Pangolin

Mackenzie Morgan-3
On Mon, Nov 28, 2011 at 11:40 AM, Tim Gardner <[hidden email]> wrote:
> It is my recommendation that folks running PAE incapable CPUs stay on Lucid
> (10.04), a release for which they'll still receive more then 3 years of
> official support.

No longer matters for the 5 year old computer in my family (switching
back to Windows), but...

wouldn't that be one more year (-ish) of official support? The desktop
is only supported 3 years.

--
Mackenzie Morgan

--
ubuntu-devel mailing list
[hidden email]
Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
Reply | Threaded
Open this post in threaded view
|

Re: Dropping i386 non-PAE as a supported kernel flavour in Precise Pangolin

Kees Cook-5
In reply to this post by Tim Gardner-2
On Mon, Nov 28, 2011 at 09:40:53AM -0700, Tim Gardner wrote:
> non-pae has a ginormous and ugly NX emulation patch

This is about dropping non-PAE support, not dropping non-NX support. The NX
emulation patch must remain in the kernel since a large number of systems
have PAE but not NX.

You can see this in the table here:
https://wiki.ubuntu.com/Security/Features#nx
Dropping non-PAE just eliminates the top line in that table. NX-emu will
still be needed.

> that has consumed substantial maintenance resources in the past,

I'm also curious about this claim, as you've expressed to me in the past
that carrying it has been surprisingly trivial. In fact, since I'm the one
maintaining it these days, it's actually going to require 0 resources from
Canonical. ;)

http://git.kernel.org/?p=linux/kernel/git/kees/linux.git;a=shortlog;h=refs/heads/nx-emu

> The kernel team has limited resources. Obviously I want to apply
> what resources we have to the problems that affect the most
> important platforms. Furthermore, I anticipate new ARM flavours in
> the coming months which will take up any slack afforded by the loss
> of non-PAE.

I'm curious why pushing non-PAE to universe and leaving it in the main
linux source package is a burden? Then people using non-PAE get automatic
security updates without any hassle on anyone's part. This is what the
Ubuntu Security Team manager wants:
https://lists.ubuntu.com/archives/ubuntu-devel/2011-November/034457.html
as well as the Ubuntu Platform Team manager wants:
https://lists.ubuntu.com/archives/ubuntu-devel/2011-November/034463.html

I'm not convinced there's enough evidence to say that dropping it from the
main linux source package will actually save any time at all.

-Kees

--
Kees Cook

--
ubuntu-devel mailing list
[hidden email]
Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
Reply | Threaded
Open this post in threaded view
|

Re: Dropping i386 non-PAE as a supported kernel flavour in Precise Pangolin

Tim Gardner-2
On 11/28/2011 11:44 AM, Kees Cook wrote:

> On Mon, Nov 28, 2011 at 09:40:53AM -0700, Tim Gardner wrote:
>> non-pae has a ginormous and ugly NX emulation patch
>
> This is about dropping non-PAE support, not dropping non-NX support. The NX
> emulation patch must remain in the kernel since a large number of systems
> have PAE but not NX.
>
> You can see this in the table here:
> https://wiki.ubuntu.com/Security/Features#nx
> Dropping non-PAE just eliminates the top line in that table. NX-emu will
> still be needed.
>

I guess you are correct. I naively assumed that execute-disable was
introduced with PAE in the Pentium Pro series. However, it did not
appear in Intel CPUs until Pentium 4 (approx Q1 2005). AMD had it from
the beginning in the Athlon series.

>> that has consumed substantial maintenance resources in the past,
>
> I'm also curious about this claim, as you've expressed to me in the past
> that carrying it has been surprisingly trivial. In fact, since I'm the one
> maintaining it these days, it's actually going to require 0 resources from
> Canonical. ;)
>
> http://git.kernel.org/?p=linux/kernel/git/kees/linux.git;a=shortlog;h=refs/heads/nx-emu
>

I did say "in the past". I remember encountering several issues with the
early implementation, as well as maintenance hassles while 32 and 64 bit
arch support was converging. I would characterize the NX emulation patch
as deeply intrusive, arguably one of the more complex patches against
the core of Linux that we carry.

Its a moot point given the model gap between PAE and NX introduction.

>> The kernel team has limited resources. Obviously I want to apply
>> what resources we have to the problems that affect the most
>> important platforms. Furthermore, I anticipate new ARM flavours in
>> the coming months which will take up any slack afforded by the loss
>> of non-PAE.
>
> I'm curious why pushing non-PAE to universe and leaving it in the main
> linux source package is a burden? Then people using non-PAE get automatic
> security updates without any hassle on anyone's part. This is what the
> Ubuntu Security Team manager wants:
> https://lists.ubuntu.com/archives/ubuntu-devel/2011-November/034457.html
> as well as the Ubuntu Platform Team manager wants:
> https://lists.ubuntu.com/archives/ubuntu-devel/2011-November/034463.html
>
> I'm not convinced there's enough evidence to say that dropping it from the
> main linux source package will actually save any time at all.
>

Dropping this flavour saves 5 minutes per build on a 4-way 80 thread
server, which for some of the team can add up to quite a bit of time
over the course of a day. Its one less variant that needs to be tested
in Q/A, and its one less flavour we have to mess with in our meta and
LBM packages.

rtg
--
Tim Gardner [hidden email]

--
ubuntu-devel mailing list
[hidden email]
Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
12