Next meeting is Wednesday, 2015-Aug-05 at 1400 UTC / 10:00am US-Eastern.
* What are the next steps for Atomic Workstation?
I've kept the agenda short because there wasn't time for this item last meeting, and I think it will easily consume the hour. (The password policy can and should be sorted out on list at this point.) However, if there are urgent additions please feel free to respond with a suggestion!
On 07/31/2015 10:38 PM, Paul W. Frields wrote:
Next meeting is Wednesday, 2015-Aug-05 at 1400 UTC / 10:00am US-Eastern.
- What are the next steps for Atomic Workstation?
I've kept the agenda short because there wasn't time for this item last meeting, and I think it will easily consume the hour. (The password policy can and should be sorted out on list at this point.) However, if there are urgent additions please feel free to respond with a suggestion!
There's a new "Validity of i686 as a release blocker" thread on fedora-devel where the kernel team is saying that they are no longer interested in supporting i686: https://lists.fedoraproject.org/pipermail/devel/2015-August/213118.html
We should make up a position whether we want to continue with the i686 version of the Workstation product. I can see two outcomes depending on which way this goes; one would be that we ask the kernel team to continue supporting i686, and the other one is that we stop shipping the i686 Workstation images.
I don't think anything in between (we ship unsupported images) makes sense.
I am personally of the mind that it's time to let i686 go. Perhaps not for F23, but F24 for sure.
On Tue, Aug 4, 2015 at 10:13 AM, Kalev Lember kalevlember@gmail.com wrote:
On 07/31/2015 10:38 PM, Paul W. Frields wrote:
Next meeting is Wednesday, 2015-Aug-05 at 1400 UTC / 10:00am US-Eastern.
- What are the next steps for Atomic Workstation?
I've kept the agenda short because there wasn't time for this item last meeting, and I think it will easily consume the hour. (The password policy can and should be sorted out on list at this point.) However, if there are urgent additions please feel free to respond with a suggestion!
There's a new "Validity of i686 as a release blocker" thread on fedora-devel where the kernel team is saying that they are no longer interested in supporting i686: https://lists.fedoraproject.org/pipermail/devel/2015-August/213118.html
2 things.
1) The kernel team said they are no longer interested in i686 back in February, not today.
2) The thread from today is started by me and reflects only my opinion, not that of the entire kernel team. While I suspect they have similar thoughts, I would not be so bold as to speak for them on this topic.
We should make up a position whether we want to continue with the i686 version of the Workstation product. I can see two outcomes depending on which way this goes; one would be that we ask the kernel team to continue supporting i686, and the other one is that we stop shipping the i686 Workstation images.
i686 won't be a priority for the kernel team going forward. Particularly not with the other items we are looking at tackling. You can ask, but we will likely have to politely decline.
Support is a strange word here, which is why I chose priority. We currently build i686. We even test it in our autotest harness. We simply don't prioritize i686 bugs or issues at all. Our time is better spent elsewhere.
I don't think anything in between (we ship unsupported images) makes sense.
I am personally of the mind that it's time to let i686 go. Perhaps not for F23, but F24 for sure.
I would personally agree with F24.
josh
----- Original Message ----- <snip>
I don't think anything in between (we ship unsupported images) makes sense.
I am personally of the mind that it's time to let i686 go. Perhaps not for F23, but F24 for sure.
I would personally agree with F24.
I'm fine with letting i686 go as soon as we have EFI_MIXED support working in the kernel/grub so that we can use x86-64 on 32-bit UEFI tablets, like all the BayTrail tablets.
On Tue, Aug 04, 2015 at 10:35:59AM -0400, Bastien Nocera wrote:
I'm fine with letting i686 go as soon as we have EFI_MIXED support working in the kernel/grub so that we can use x86-64 on 32-bit UEFI tablets, like all the BayTrail tablets.
Are these an important target for Workstation, or is it best to leave that to Remixes like Fedlet? https://www.happyassassin.net/fedlet-a-fedora-remix-for-bay-trail-tablets/
----- Original Message -----
On Tue, Aug 04, 2015 at 10:35:59AM -0400, Bastien Nocera wrote:
I'm fine with letting i686 go as soon as we have EFI_MIXED support working in the kernel/grub so that we can use x86-64 on 32-bit UEFI tablets, like all the BayTrail tablets.
Are these an important target for Workstation, or is it best to leave that to Remixes like Fedlet? https://www.happyassassin.net/fedlet-a-fedora-remix-for-bay-trail-tablets/
It's important for workstation, because: - we can deploy the same applications we do on workstation - they're an inexpensive way to get touchscreens, and sensors in the hands of our users and developers - Fedlet can't support Secure Boot
On Tue, 2015-08-04 at 10:35 -0400, Bastien Nocera wrote:
I'm fine with letting i686 go as soon as we have EFI_MIXED support working in the kernel/grub so that we can use x86-64 on 32-bit UEFI tablets, like all the BayTrail tablets.
This seems fine to me, but I wonder, what are the download numbers of our x86_64 image vs. the i686 image? I am presuming that the numbers for i686 are dramatically smaller than the numbers for x86_64.
(snip)
There's a new "Validity of i686 as a release blocker" thread on fedora-devel where the kernel team is saying that they are no longer interested in supporting i686: https://lists.fedoraproject.org/pipermail/devel/2015-August/213118.ht ml
We should make up a position whether we want to continue with the i686 version of the Workstation product. I can see two outcomes depending on which way this goes; one would be that we ask the kernel team to continue supporting i686, and the other one is that we stop shipping the i686 Workstation images.
I don't think anything in between (we ship unsupported images) makes sense.
I am personally of the mind that it's time to let i686 go. Perhaps not for F23, but F24 for sure.
Here is my personal user experience, based on an edge (although perhaps not extreme) case:
I own an Acer Aspire One (32bit, 1.6 GHz single core with 2 gigs ram and 160gig hard drive) which I *had* wanted to have gone on living with Fedora as long as the hardware didn't die, such as a hard drive spin out, a thermal event, or physical damage due to dropping or the like; nothing of the sort has yet occurred and the physical hardware still works.
It worked great until and including F17; I skipped F18. It worked acceptably and, depending on the use case, even occasionally well under F19, although I could tell that I was pushing the limits. YouTube and other videos could be difficult to watch (read choppy). I skipped F20.
I installed F21 Workstation last January on the Acer, and while I had to fight a bit to install it, it finally worked. However, it was obvious that the hardware was inadequate for the task. Routine tasks were often sluggish at best, load times were slow, and the machine would hang as though (to me) there were a kernel panic, often enough lasting for several minutes, sometimes into 10 and 20 minutes, or until I did a reboot. This would occur sometimes after hours of use or sometimes after a fresh boot. I knew that the single user console was easily accessible and of course the command line was still lightning fast (ie. the desktop was too top heavy, but command line no doubt still usable) but as a desktop it was becoming unusable.
I bought a new laptop in June, and installed F22. The Acer currently has CentOS 6 on it, the last release to have a 32bit image, and it's based on F12-F13, which worked rather well on the Acer.
So for the desktop, be it the workstation or some of the other spins ... I'd have to say that there would have to be a compelling business case to continue supporting it; some of the traditional laptop and desktop hardware use cases are starting to age out, based on my limited personal experience.
As for the other products and spins, I don't really know enough other than to say that I have the impression that 32bit linux on the command line no doubt is still good and would work well enough as a headless server, such as a light-duty home server or vanity server.
And here's another perspective: RHEL 7 doesn't have a 32 bit image. While Fedora tries to reach a certain greater market which RHEL from now on appears to not be interested in (and rightly so), I personally agree that Fedora is arguably at a tipping point.
Thank you
On Tue, Aug 04, 2015 at 10:57:49AM -0400, Bastien Nocera wrote:
Are these an important target for Workstation, or is it best to leave that to Remixes like Fedlet? https://www.happyassassin.net/fedlet-a-fedora-remix-for-bay-trail-tablets/
It's important for workstation, because:
- we can deploy the same applications we do on workstation
Can you expand on that point?
- they're an inexpensive way to get touchscreens, and sensors in the hands of our users and developers
Moderately useful, but is it a priority _over_ everything else here?
- Fedlet can't support Secure Boot
I think it can; it's just more of a pain. Someone would need to pay $99, once. And if Fedlet used the stock Fedora kernel, it would just work, right?
On Tue, Aug 04, 2015 at 10:05:02AM -0500, Michael Catanzaro wrote:
This seems fine to me, but I wonder, what are the download numbers of our x86_64 image vs. the i686 image? I am presuming that the numbers for i686 are dramatically smaller than the numbers for x86_64.
I've asked the infrastructure team for these numbers for F22.
----- Original Message -----
On Tue, Aug 04, 2015 at 10:57:49AM -0400, Bastien Nocera wrote:
Are these an important target for Workstation, or is it best to leave that to Remixes like Fedlet? https://www.happyassassin.net/fedlet-a-fedora-remix-for-bay-trail-tablets/
It's important for workstation, because:
- we can deploy the same applications we do on workstation
Can you expand on that point?
It's a useful form factor to create kiosk type applications, at least, and because it's a SoC, it's a sign of things to come, in terms of hardware, for the whole of the x86 platform: - MMC/SDIO connected devices - GPIO connected devices - MIPI webcams
- they're an inexpensive way to get touchscreens, and sensors in the hands of our users and developers
Moderately useful, but is it a priority _over_ everything else here?
We need touchscreen support because that's where laptops are heading. We need sensor support, because we want to be able to use those sensors to make power savings, and make the devices more useful in general.
- Fedlet can't support Secure Boot
I think it can; it's just more of a pain. Someone would need to pay $99, once. And if Fedlet used the stock Fedora kernel, it would just work, right?
No, because the 32-bit bootloader isn't signed, because we don't support booting a 32-bit OS with a 32-bit UEFI. If we had EFI mixed support, we'd sign the 32-bit shim and grub and boot the 64-bit kernel (already signed).
So, I wish we could prioritise getting EFI mixed support working, so that the only 2 packages we need to ship as i686 packages are grub and shim.
On Tue, Aug 04, 2015 at 11:35:40AM -0400, Bastien Nocera wrote:
It's important for workstation, because:
- we can deploy the same applications we do on workstation
Can you expand on that point?
It's a useful form factor to create kiosk type applications, at least, and
I don't see kiosks as a target in https://fedoraproject.org/wiki/Workstation/Workstation_PRD#Target_Audience (nor do I think it should be).
because it's a SoC, it's a sign of things to come, in terms of hardware, for the whole of the x86 platform:
- MMC/SDIO connected devices
- GPIO connected devices
- MIPI webcams
But surely these 32-bit tablets aren't the only good place where these things can be worked on?
- they're an inexpensive way to get touchscreens, and sensors in the hands of our users and developers
Moderately useful, but is it a priority _over_ everything else here?
We need touchscreen support because that's where laptops are heading. We need sensor support, because we want to be able to use those sensors to make power savings, and make the devices more useful in general.
I don't disagree. But I'm not at all convinced that this is really the best way to get it. To put it another way, it may *appear* to be an inexpensive way, but there are significant _other_ costs (hence this whole thread).
- Fedlet can't support Secure Boot
I think it can; it's just more of a pain. Someone would need to pay $99, once. And if Fedlet used the stock Fedora kernel, it would just work, right?
No, because the 32-bit bootloader isn't signed, because we don't support booting a 32-bit OS with a 32-bit UEFI. If we had EFI mixed support, we'd sign the 32-bit shim and grub and boot the 64-bit kernel (already signed).
So, I wish we could prioritise getting EFI mixed support working, so that the only 2 packages we need to ship as i686 packages are grub and shim.
^ Example expense. Why prioritize that over other things, when we can just get different devel hardware instead?
On Tue, Aug 4, 2015 at 11:53 AM, Matthew Miller mattdm@fedoraproject.org wrote:
On Tue, Aug 04, 2015 at 11:35:40AM -0400, Bastien Nocera wrote:
It's important for workstation, because:
- we can deploy the same applications we do on workstation
Can you expand on that point?
It's a useful form factor to create kiosk type applications, at least, and
I don't see kiosks as a target in https://fedoraproject.org/wiki/Workstation/Workstation_PRD#Target_Audience (nor do I think it should be).
because it's a SoC, it's a sign of things to come, in terms of hardware, for the whole of the x86 platform:
- MMC/SDIO connected devices
- GPIO connected devices
- MIPI webcams
But surely these 32-bit tablets aren't the only good place where these things can be worked on?
To clarify, Bastien is talking about tablets that have 64-bit CPUs and 64-bit kernels, but 32-bit UEFI firmware. Not i686 tablets. Which is actually pretty terrible in its own right, but still distinct from a 32-bit tablet.
josh
On Tue, Aug 04, 2015 at 11:55:56AM -0400, Josh Boyer wrote:
But surely these 32-bit tablets aren't the only good place where these things can be worked on?
To clarify, Bastien is talking about tablets that have 64-bit CPUs and 64-bit kernels, but 32-bit UEFI firmware. Not i686 tablets. Which is actually pretty terrible in its own right, but still distinct from a 32-bit tablet.
Ah, okay, thanks. How does *that* fit in with kernel team's plans?
On Tue, Aug 4, 2015 at 12:28 PM, Matthew Miller mattdm@fedoraproject.org wrote:
On Tue, Aug 04, 2015 at 11:55:56AM -0400, Josh Boyer wrote:
But surely these 32-bit tablets aren't the only good place where these things can be worked on?
To clarify, Bastien is talking about tablets that have 64-bit CPUs and 64-bit kernels, but 32-bit UEFI firmware. Not i686 tablets. Which is actually pretty terrible in its own right, but still distinct from a 32-bit tablet.
Ah, okay, thanks. How does *that* fit in with kernel team's plans?
It mostly doesn't impact us. We already enable EFI_MIXED in the kernel. The remaining work is in shim and grub afaik.
(Barring bugs and such of course.)
josh
On Tue, Aug 04, 2015 at 12:58:20PM -0400, Josh Boyer wrote:
On Tue, Aug 4, 2015 at 12:28 PM, Matthew Miller mattdm@fedoraproject.org wrote:
On Tue, Aug 04, 2015 at 11:55:56AM -0400, Josh Boyer wrote:
But surely these 32-bit tablets aren't the only good place where these things can be worked on?
To clarify, Bastien is talking about tablets that have 64-bit CPUs and 64-bit kernels, but 32-bit UEFI firmware. Not i686 tablets. Which is actually pretty terrible in its own right, but still distinct from a 32-bit tablet.
Ah, okay, thanks. How does *that* fit in with kernel team's plans?
It mostly doesn't impact us. We already enable EFI_MIXED in the kernel. The remaining work is in shim and grub afaik.
(Barring bugs and such of course.)
So AIUI so far, there's no reason from the Workstation POV an i686 tree/distro is strictly needed. I'm assuming no one is proposing doing away with i686 userspace packages. (We would certainly care about that, for example because of prepackaged 32-bit software.)
* Bastien, are you going to talk to grub/shim maintainer(s)? (I think pjones works on both of these.)
* Is there any other input we need/want to provide from Workstation WG?
On Fri, Jul 31, 2015 at 04:38:34PM -0400, Paul W. Frields wrote:
Next meeting is Wednesday, 2015-Aug-05 at 1400 UTC / 10:00am US-Eastern.
- What are the next steps for Atomic Workstation?
I've kept the agenda short because there wasn't time for this item last meeting, and I think it will easily consume the hour. (The password policy can and should be sorted out on list at this point.) However, if there are urgent additions please feel free to respond with a suggestion!
Also, I'll need to leave the meeting no more than 10 minutes before the hour. If someone wants to take over the responsibility of closing the meeting (using the #endmeeting command) at that point, great. If not, we'll just treat :50 as a hard stop.
On Tue, Aug 4, 2015 at 4:45 PM, Paul W. Frields stickster@gmail.com wrote:
On Tue, Aug 04, 2015 at 12:58:20PM -0400, Josh Boyer wrote:
On Tue, Aug 4, 2015 at 12:28 PM, Matthew Miller mattdm@fedoraproject.org wrote:
On Tue, Aug 04, 2015 at 11:55:56AM -0400, Josh Boyer wrote:
But surely these 32-bit tablets aren't the only good place where these things can be worked on?
To clarify, Bastien is talking about tablets that have 64-bit CPUs and 64-bit kernels, but 32-bit UEFI firmware. Not i686 tablets. Which is actually pretty terrible in its own right, but still distinct from a 32-bit tablet.
Ah, okay, thanks. How does *that* fit in with kernel team's plans?
It mostly doesn't impact us. We already enable EFI_MIXED in the kernel. The remaining work is in shim and grub afaik.
(Barring bugs and such of course.)
So AIUI so far, there's no reason from the Workstation POV an i686 tree/distro is strictly needed. I'm assuming no one is proposing doing away with i686 userspace packages. (We would certainly care
Not presently. Though full secondary arch status would imply that (or we'd have to redefine what secondary arch meant if we wanted to cover multilib like RHEL).
about that, for example because of prepackaged 32-bit software.)
Yes... but probably less so than you think. Fedora doesn't exactly have a strong ISV presence and maybe this docker/container thing could help there anyway.
- Bastien, are you going to talk to grub/shim maintainer(s)? (I think pjones works on both of these.)
I believe he has, a number of times.
josh
On Tue, Aug 4, 2015 at 10:49 PM, Josh Boyer jwboyer@fedoraproject.org wrote:
On Tue, Aug 4, 2015 at 4:45 PM, Paul W. Frields stickster@gmail.com wrote:
On Tue, Aug 04, 2015 at 12:58:20PM -0400, Josh Boyer wrote:
On Tue, Aug 4, 2015 at 12:28 PM, Matthew Miller mattdm@fedoraproject.org wrote:
On Tue, Aug 04, 2015 at 11:55:56AM -0400, Josh Boyer wrote:
But surely these 32-bit tablets aren't the only good place where these things can be worked on?
To clarify, Bastien is talking about tablets that have 64-bit CPUs and 64-bit kernels, but 32-bit UEFI firmware. Not i686 tablets. Which is actually pretty terrible in its own right, but still distinct from a 32-bit tablet.
Ah, okay, thanks. How does *that* fit in with kernel team's plans?
It mostly doesn't impact us. We already enable EFI_MIXED in the kernel. The remaining work is in shim and grub afaik.
(Barring bugs and such of course.)
So AIUI so far, there's no reason from the Workstation POV an i686 tree/distro is strictly needed. I'm assuming no one is proposing doing away with i686 userspace packages. (We would certainly care
Not presently. Though full secondary arch status would imply that (or we'd have to redefine what secondary arch meant if we wanted to cover multilib like RHEL).
about that, for example because of prepackaged 32-bit software.)
Yes... but probably less so than you think. Fedora doesn't exactly have a strong ISV presence and maybe this docker/container thing could help there anyway.
Well that's the reason why "i686 as secondary arch" is a bad idea. Not creating i686 media (and kernel) I could agree with but no i686 packages at all? Not really it would break a lot of third party (pre compiled apps) out there (skype, some steam games, ... ).
On Tue, Aug 4, 2015 at 5:08 PM, drago01 drago01@gmail.com wrote:
On Tue, Aug 4, 2015 at 10:49 PM, Josh Boyer jwboyer@fedoraproject.org wrote:
On Tue, Aug 4, 2015 at 4:45 PM, Paul W. Frields stickster@gmail.com wrote:
On Tue, Aug 04, 2015 at 12:58:20PM -0400, Josh Boyer wrote:
On Tue, Aug 4, 2015 at 12:28 PM, Matthew Miller mattdm@fedoraproject.org wrote:
On Tue, Aug 04, 2015 at 11:55:56AM -0400, Josh Boyer wrote:
> But surely these 32-bit tablets aren't the only good place where these > things can be worked on? To clarify, Bastien is talking about tablets that have 64-bit CPUs and 64-bit kernels, but 32-bit UEFI firmware. Not i686 tablets. Which is actually pretty terrible in its own right, but still distinct from a 32-bit tablet.
Ah, okay, thanks. How does *that* fit in with kernel team's plans?
It mostly doesn't impact us. We already enable EFI_MIXED in the kernel. The remaining work is in shim and grub afaik.
(Barring bugs and such of course.)
So AIUI so far, there's no reason from the Workstation POV an i686 tree/distro is strictly needed. I'm assuming no one is proposing doing away with i686 userspace packages. (We would certainly care
Not presently. Though full secondary arch status would imply that (or we'd have to redefine what secondary arch meant if we wanted to cover multilib like RHEL).
about that, for example because of prepackaged 32-bit software.)
Yes... but probably less so than you think. Fedora doesn't exactly have a strong ISV presence and maybe this docker/container thing could help there anyway.
Well that's the reason why "i686 as secondary arch" is a bad idea.
Partly why I didn't propose that.
Not creating i686 media (and kernel) I could agree with but no i686 packages at all? Not really it would break a lot of third party (pre compiled apps) out there (skype, some steam games, ... ).
It _could_ break those, yes. However, I was suggesting that containers could possibly avoid that breakage. Particularly since it would be nice to deliver such things in containers for sandboxing anyway. This has the notable downside of bundling, but I don't see how xdg-apps or Docker or any other container technology gets around that anyway. Over time, I suspect those applications will likely move to 64-bit as well.
At any rate, we're mostly agreeing here.
josh
On Tue, Aug 4, 2015 at 11:14 PM, Josh Boyer jwboyer@fedoraproject.org wrote:
On Tue, Aug 4, 2015 at 5:08 PM, drago01 drago01@gmail.com wrote:
On Tue, Aug 4, 2015 at 10:49 PM, Josh Boyer jwboyer@fedoraproject.org wrote:
On Tue, Aug 4, 2015 at 4:45 PM, Paul W. Frields stickster@gmail.com wrote:
On Tue, Aug 04, 2015 at 12:58:20PM -0400, Josh Boyer wrote:
On Tue, Aug 4, 2015 at 12:28 PM, Matthew Miller mattdm@fedoraproject.org wrote:
On Tue, Aug 04, 2015 at 11:55:56AM -0400, Josh Boyer wrote: > > But surely these 32-bit tablets aren't the only good place where these > > things can be worked on? > To clarify, Bastien is talking about tablets that have 64-bit CPUs and > 64-bit kernels, but 32-bit UEFI firmware. Not i686 tablets. Which is > actually pretty terrible in its own right, but still distinct from a > 32-bit tablet.
Ah, okay, thanks. How does *that* fit in with kernel team's plans?
It mostly doesn't impact us. We already enable EFI_MIXED in the kernel. The remaining work is in shim and grub afaik.
(Barring bugs and such of course.)
So AIUI so far, there's no reason from the Workstation POV an i686 tree/distro is strictly needed. I'm assuming no one is proposing doing away with i686 userspace packages. (We would certainly care
Not presently. Though full secondary arch status would imply that (or we'd have to redefine what secondary arch meant if we wanted to cover multilib like RHEL).
about that, for example because of prepackaged 32-bit software.)
Yes... but probably less so than you think. Fedora doesn't exactly have a strong ISV presence and maybe this docker/container thing could help there anyway.
Well that's the reason why "i686 as secondary arch" is a bad idea.
Partly why I didn't propose that.
Not creating i686 media (and kernel) I could agree with but no i686 packages at all? Not really it would break a lot of third party (pre compiled apps) out there (skype, some steam games, ... ).
It _could_ break those, yes. However, I was suggesting that containers could possibly avoid that breakage. Particularly since it would be nice to deliver such things in containers for sandboxing anyway. This has the notable downside of bundling, but I don't see how xdg-apps or Docker or any other container technology gets around that anyway.
Well yes but we have to wait for containers to be more widespread for application deployment before moving in that direction. Debian based distros where using chroots and other hacks before to make them work and moved to multi arch (something like our multi lib) to solve it. Would be kind of awkward if we move in the different direction i.e make things harder while they make things easier ;)
Over time, I suspect those applications will likely move to 64-bit as well.
Same as above timing is the key .. once apps move to 64 bit (heck even flash did) this issue goes away. But I am afraid this process will take way longer then F24.
At any rate, we're mostly agreeing here.
OK fair enough.
On Tue, Aug 04, 2015 at 11:13:58AM -0400, Matthew Miller wrote:
On Tue, Aug 04, 2015 at 10:05:02AM -0500, Michael Catanzaro wrote:
This seems fine to me, but I wonder, what are the download numbers of our x86_64 image vs. the i686 image? I am presuming that the numbers for i686 are dramatically smaller than the numbers for x86_64.
I've asked the infrastructure team for these numbers for F22.
More later, but: drastically decreased from previous releases as a percentage. Six years ago, x86_64 was 25% and i686 was 75%. Three years ago, more like 60/40 — in 64-bit's favor. Now, 80% or more so 64 bit.
desktop@lists.fedoraproject.org