On Tue, Aug 4, 2015 at 11:14 PM, Josh Boyer <jwboyer@xxxxxxxxxxxxxxxxx> wrote: > On Tue, Aug 4, 2015 at 5:08 PM, drago01 <drago01@xxxxxxxxx> wrote: >> On Tue, Aug 4, 2015 at 10:49 PM, Josh Boyer <jwboyer@xxxxxxxxxxxxxxxxx> wrote: >>> On Tue, Aug 4, 2015 at 4:45 PM, Paul W. Frields <stickster@xxxxxxxxx> 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@xxxxxxxxxxxxxxxxx> 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. -- desktop mailing list desktop@xxxxxxxxxxxxxxxxxxxxxxx https://admin.fedoraproject.org/mailman/listinfo/desktop
