10:52 a.m.
Jon, Brendan,
In yesterday's FESCo meeting I told you I'd make a list of specific issues
I have with the current proposal for ARM as a primary archictecture. There
are some places where I think the current proposal fails to deal with some
necessary aspects of becoming a primary architecture, and some places where
I don't think the approach is quite right. So without further ado:
1) mechanisms need to be in place to get package maintainers access to fix
arm-specific bugs in their packages
2) excludearch is not an option. This is fundamentally contrary to being
a primary arch. In fact this is one of the defining characteristics of
a secondary arch.
3) arm must be integrated to the formal release criteria
4) when milestones occur, arm needs to be just as testible as other
primary architectures
5) installation methods must be in place. I'm not saying it has to be
using the same model as x86, but when we get to beta, if it can't be
installed, it can't meet similar release criteria to existing or prior
primary arches. Where possible, we should be using anaconda for
installation, though I'd be open to looking at using it to build installed
images for machines with severe resource constraints.
6) supported platforms must be fully integrated into building and
installation. If you need a special build procedure to make this happen
for kernel, we need to have rel-eng signing off saying they've approved
of whatever method that is, and QE signing off that they think it'll
result in a something they can claim is tested enough to release as a
primary arch.
7) it can't be a serious maintenance burdon due to build related issues.
We need a couple of groups to sign off that builds are fast enough, not
just on a "full distro rebuild" (throughput) level, but also on a
"doesn't destroy my workflow due to waiting on it" (latency) level.
Obviously any feedback you guys have on this is welcome.
--
Peter
Old MacDonald had an agricultural real-estate tax abatement.
01234567890123456789012345678901234567890123456789012345678901234567890123456789
10:54 a.m.
On Tue, Mar 20, 2012 at 10:52 AM, Peter Jones <pjones(a)redhat.com> wrote:
Jon, Brendan,
In yesterday's FESCo meeting I told you I'd make a list of specific issues
I have with the current proposal for ARM as a primary archictecture. There
are some places where I think the current proposal fails to deal with some
necessary aspects of becoming a primary architecture, and some places where
I don't think the approach is quite right. So without further ado:
Excellent, can you add this to the ticket?
1) mechanisms need to be in place to get package maintainers access
to fix
arm-specific bugs in their packages
2) excludearch is not an option. This is fundamentally contrary to being
a primary arch. In fact this is one of the defining characteristics of
a secondary arch.
3) arm must be integrated to the formal release criteria
4) when milestones occur, arm needs to be just as testible as other
primary architectures
5) installation methods must be in place. I'm not saying it has to be
using the same model as x86, but when we get to beta, if it can't be
installed, it can't meet similar release criteria to existing or prior
primary arches. Where possible, we should be using anaconda for
installation, though I'd be open to looking at using it to build installed
images for machines with severe resource constraints.
6) supported platforms must be fully integrated into building and
installation. If you need a special build procedure to make this happen
for kernel, we need to have rel-eng signing off saying they've approved
of whatever method that is, and QE signing off that they think it'll
result in a something they can claim is tested enough to release as a
primary arch.
7) it can't be a serious maintenance burdon due to build related issues.
We need a couple of groups to sign off that builds are fast enough, not
just on a "full distro rebuild" (throughput) level, but also on a
"doesn't destroy my workflow due to waiting on it" (latency) level.
Obviously any feedback you guys have on this is welcome.
--
Peter
Old MacDonald had an agricultural real-estate tax abatement.
01234567890123456789012345678901234567890123456789012345678901234567890123456789
--
devel mailing list
devel(a)lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
--
in your fear, seek only peace
in your fear, seek only love
-d. bowie
11:09 a.m.
On 03/20/2012 11:52 AM, Peter Jones wrote:
In yesterday's FESCo meeting I told you I'd make a list of
specific issues
I have with the current proposal for ARM as a primary archictecture. There
are some places where I think the current proposal fails to deal with some
necessary aspects of becoming a primary architecture, and some places where
I don't think the approach is quite right. So without further ado:
Thanks for sending this. We were planning to start (and still are) a
separate and broader thread once we've had time to circle back with a
few folks in other groups for one-on-one feedback.
Jon.
11:26 a.m.
On Tue, Mar 20, 2012 at 12:09:22PM -0400, Jon Masters wrote:
On 03/20/2012 11:52 AM, Peter Jones wrote:
> In yesterday's FESCo meeting I told you I'd make a list of specific issues
> I have with the current proposal for ARM as a primary archictecture. There
> are some places where I think the current proposal fails to deal with some
> necessary aspects of becoming a primary architecture, and some places where
> I don't think the approach is quite right. So without further ado:
Thanks for sending this. We were planning to start (and still are) a
separate and broader thread once we've had time to circle back with a
few folks in other groups for one-on-one feedback.
Is the plan for that to happen before next week's fesco meeting? If not
we'll probably want to just defer it until we've made sure everyone's
given feedback. I'd also like to see as much of the conversation take
place in public as possible in order to make sure we can pick up the
reasoning behind any decisions.
Thanks,
--
Matthew Garrett | mjg59(a)srcf.ucam.org
11:30 a.m.
Hi again,
I want to thank you, and everyone else in FESCo for talking with us
yesterday, and for looking over the proposal. Bear in mind, it's a work
in progress. We intend to have broader conversations over the coming
months and F18 is an optimistic goal. Nonetheless, I feel it is
achievable (we've done many more disruptive things!) but we have also
many points along the way at which we can back out, and remain SA.
To address a few of these points...at least, I'll try :) First, just to
repeat, we took the proposal to FESCo yesterday in the spirit of "early
and often", not in the spirit of "final deliverable". Therefore, while
it is true we've not yet reached out to everyone for input, that is
because it is still a work in progress for us. We'll iterate based on
feedback, and based upon yesterday and reaching out to other groups.
On 03/20/2012 11:52 AM, Peter Jones wrote:
1) mechanisms need to be in place to get package maintainers access
to fix
arm-specific bugs in their packages
So we have a tracker bug at the moment. Is that sufficient? If so, we
obviously should make sure that it is included in the proposal docs that
we have this in place and are using it.
2) excludearch is not an option. This is fundamentally contrary to
being
a primary arch. In fact this is one of the defining characteristics of
a secondary arch.
Let's think about this some. ARM (32-bit) doesn't do Intel-style
microcode, MCE, or many other things that x86 does. I don't think that
means we should build packages that are x86-specific for ARM systems. We
generally believe that we're starting from a point of good momentum, but
there are some packages that won't ever be appropriate for ARM, and
there are others where the FTBFS has been longstanding, or there are
other (IMO valid) reasons why it might initially be Exclude. That
doesn't mean that there would be many such cases. Nonetheless, I think
it would be unreasonable to set the entry bar so high that there can be
no things left to fix. That basically retains the x86 monopoly.
3) arm must be integrated to the formal release criteria
Agreed. We'll need to figure that out.
4) when milestones occur, arm needs to be just as testible as other
primary architectures
So we have a new hire (hi Paul) who is looking at autoqa, and we're
going to pull together as much as we can here. It would help me to know
(and we're reaching out to QE separately - per my other mail) what you
would consider "testable" to mean, in terms of what you'd want to see.
5) installation methods must be in place. I'm not saying it has
to be
using the same model as x86, but when we get to beta, if it can't be
installed, it can't meet similar release criteria to existing or prior
primary arches. Where possible, we should be using anaconda for
installation, though I'd be open to looking at using it to build installed
images for machines with severe resource constraints.
So we feel it more appropriate to use image creation tools at this
point, for the 32-bit systems that we have in mind. There will be
servers this year, but not yet, and they represent a small part of the
overall value of ARM to Fedora. When you have systems that cost more
than an order of magnitude less than their x86 brethren, that does mean
there are some implementation differences. For one thing, the reason
most of these boards are inexpensive is that they've done away with
dedicated flash on-board for U-Boot, etc. Instead, the SoC (chip)
contains enough minimal logic to load everything it needs for further
initialization from an SD (typically) card. The normal model that has
been established is that cards are provisioned separately and inserted
into a board. Think of these as appliances, kinda. There are ARM
netbooks, but they are rare. We'll get to Anaconda for some of the
bigger stuff later, but for now, that seems less important than ensuring
that we use standard Fedora tools to make the images.
6) supported platforms must be fully integrated into building and
installation. If you need a special build procedure to make this happen
for kernel, we need to have rel-eng signing off saying they've approved
of whatever method that is, and QE signing off that they think it'll
result in a something they can claim is tested enough to release as a
primary arch.
Fine. I think we got onto a tangent yesterday with the kernel. It's one
part of the overall system. It's an important part, but it's just a
part. What we are proposing is that we target a limited number of ARM
kernel "variants" (subpackages) during a typical build - perhaps even
only versatile - because this allows us to return a built kernel more
quickly than building many variants. I had planned to take this to the
kernel team, but let me just add a few points since it's raised here:
1). There are too many 32-bit ARM kernels. We know this. Work is going
on in Linaro to address that. We will constrain ourselves to a small set
of supportable targets and allow contributors to handle support for more
exotic boards that few people have an interest in, much as anyone could
build a non-PC x86 system and do some kind of non-Fedora for it. A large
amount of "behind the scenes" work is currently ongoing to ensure that
the same 32-bit mistakes do not happen with 64-bit.
2). There is no intention to use anything other than the official kernel
package. The SPEC file can be modified (as it has) to build subpackages
for different ARM targets. My suggestion was that by default we limit
this to a small number, and we retain logic so that it is possible
(through macros, koji flags, whatever) to build a kernel that targets
more ARM platforms in some cases. We will discuss that separately with
the kernel team, as I have said.
3). Kernel build time on our embedded targets is not great compared with
x86. However, the ARM server hardware we will use in PA will have many
times as much cache, memory, etc. and we believe will build the kernel
much more quickly. For workflow, it is my opinion that folks care that
ARM not stall issuing new builds or extracting others from the pipeline.
For example, if you submit a kernel build and it includes x86 and arm
subbuilds, the x86 subbuild won't stall waiting for arm, it will
complete. The only thumb twiddling is waiting for the arm kernel to
complete, which will be a bit longer, but we're also planning to have so
many builder nodes that you won't be blocking for arm builds to begin.
As I said, we'll discuss this with the kernel team.
7) it can't be a serious maintenance burdon due to build related
issues.
We need a couple of groups to sign off that builds are fast enough, not
just on a "full distro rebuild" (throughput) level, but also on a
"doesn't destroy my workflow due to waiting on it" (latency) level.
Sure. Absolutely is a concern for us, as you can see from my other
comments above about the kernel, for example, but not just that.
Thanks,
Jon.
11:35 a.m.
On Tue, Mar 20, 2012 at 11:30 AM, Jon Masters <jcm(a)redhat.com> wrote:
Hi again,
I want to thank you, and everyone else in FESCo for talking with us
yesterday, and for looking over the proposal. Bear in mind, it's a work
in progress. We intend to have broader conversations over the coming
months and F18 is an optimistic goal. Nonetheless, I feel it is
achievable (we've done many more disruptive things!) but we have also
many points along the way at which we can back out, and remain SA.
To address a few of these points...at least, I'll try :) First, just to
repeat, we took the proposal to FESCo yesterday in the spirit of "early
and often", not in the spirit of "final deliverable". Therefore, while
it is true we've not yet reached out to everyone for input, that is
because it is still a work in progress for us. We'll iterate based on
feedback, and based upon yesterday and reaching out to other groups.
On 03/20/2012 11:52 AM, Peter Jones wrote:
> 1) mechanisms need to be in place to get package maintainers access to fix
> arm-specific bugs in their packages
So we have a tracker bug at the moment. Is that sufficient? If so, we
obviously should make sure that it is included in the proposal docs that
we have this in place and are using it.
What is the tracker bug? I'd like to take a peek.
> 2) excludearch is not an option. This is fundamentally contrary
to being
> a primary arch. In fact this is one of the defining characteristics of
> a secondary arch.
Let's think about this some. ARM (32-bit) doesn't do Intel-style
microcode, MCE, or many other things that x86 does. I don't think that
means we should build packages that are x86-specific for ARM systems. We
generally believe that we're starting from a point of good momentum, but
there are some packages that won't ever be appropriate for ARM, and
there are others where the FTBFS has been longstanding, or there are
other (IMO valid) reasons why it might initially be Exclude. That
doesn't mean that there would be many such cases. Nonetheless, I think
it would be unreasonable to set the entry bar so high that there can be
no things left to fix. That basically retains the x86 monopoly.
> 3) arm must be integrated to the formal release criteria
Agreed. We'll need to figure that out.
> 4) when milestones occur, arm needs to be just as testible as other
> primary architectures
So we have a new hire (hi Paul) who is looking at autoqa, and we're
going to pull together as much as we can here. It would help me to know
(and we're reaching out to QE separately - per my other mail) what you
would consider "testable" to mean, in terms of what you'd want to see.
> 5) installation methods must be in place. I'm not saying it has to be
> using the same model as x86, but when we get to beta, if it can't be
> installed, it can't meet similar release criteria to existing or prior
> primary arches. Where possible, we should be using anaconda for
> installation, though I'd be open to looking at using it to build installed
> images for machines with severe resource constraints.
So we feel it more appropriate to use image creation tools at this
point, for the 32-bit systems that we have in mind. There will be
servers this year, but not yet, and they represent a small part of the
overall value of ARM to Fedora. When you have systems that cost more
than an order of magnitude less than their x86 brethren, that does mean
there are some implementation differences. For one thing, the reason
most of these boards are inexpensive is that they've done away with
dedicated flash on-board for U-Boot, etc. Instead, the SoC (chip)
contains enough minimal logic to load everything it needs for further
initialization from an SD (typically) card. The normal model that has
been established is that cards are provisioned separately and inserted
into a board. Think of these as appliances, kinda. There are ARM
netbooks, but they are rare. We'll get to Anaconda for some of the
bigger stuff later, but for now, that seems less important than ensuring
that we use standard Fedora tools to make the images.
> 6) supported platforms must be fully integrated into building and
> installation. If you need a special build procedure to make this happen
> for kernel, we need to have rel-eng signing off saying they've approved
> of whatever method that is, and QE signing off that they think it'll
> result in a something they can claim is tested enough to release as a
> primary arch.
Fine. I think we got onto a tangent yesterday with the kernel. It's one
part of the overall system. It's an important part, but it's just a
part. What we are proposing is that we target a limited number of ARM
kernel "variants" (subpackages) during a typical build - perhaps even
only versatile - because this allows us to return a built kernel more
quickly than building many variants. I had planned to take this to the
kernel team, but let me just add a few points since it's raised here:
1). There are too many 32-bit ARM kernels. We know this. Work is going
on in Linaro to address that. We will constrain ourselves to a small set
of supportable targets and allow contributors to handle support for more
exotic boards that few people have an interest in, much as anyone could
build a non-PC x86 system and do some kind of non-Fedora for it. A large
amount of "behind the scenes" work is currently ongoing to ensure that
the same 32-bit mistakes do not happen with 64-bit.
2). There is no intention to use anything other than the official kernel
package. The SPEC file can be modified (as it has) to build subpackages
for different ARM targets. My suggestion was that by default we limit
this to a small number, and we retain logic so that it is possible
(through macros, koji flags, whatever) to build a kernel that targets
more ARM platforms in some cases. We will discuss that separately with
the kernel team, as I have said.
3). Kernel build time on our embedded targets is not great compared with
x86. However, the ARM server hardware we will use in PA will have many
times as much cache, memory, etc. and we believe will build the kernel
much more quickly. For workflow, it is my opinion that folks care that
ARM not stall issuing new builds or extracting others from the pipeline.
For example, if you submit a kernel build and it includes x86 and arm
subbuilds, the x86 subbuild won't stall waiting for arm, it will
complete. The only thumb twiddling is waiting for the arm kernel to
complete, which will be a bit longer, but we're also planning to have so
many builder nodes that you won't be blocking for arm builds to begin.
As I said, we'll discuss this with the kernel team.
> 7) it can't be a serious maintenance burdon due to build related issues.
> We need a couple of groups to sign off that builds are fast enough, not
> just on a "full distro rebuild" (throughput) level, but also on a
> "doesn't destroy my workflow due to waiting on it" (latency)
level.
Sure. Absolutely is a concern for us, as you can see from my other
comments above about the kernel, for example, but not just that.
Thanks,
Jon.
--
devel mailing list
devel(a)lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
--
in your fear, seek only peace
in your fear, seek only love
-d. bowie
12:39 p.m.
On 03/20/2012 12:30 PM, Jon Masters wrote:
Hi again,
I want to thank you, and everyone else in FESCo for talking with us
yesterday, and for looking over the proposal. Bear in mind, it's a work
in progress. We intend to have broader conversations over the coming
months and F18 is an optimistic goal. Nonetheless, I feel it is
achievable (we've done many more disruptive things!) but we have also
many points along the way at which we can back out, and remain SA.
To address a few of these points...at least, I'll try :) First, just to
repeat, we took the proposal to FESCo yesterday in the spirit of "early
and often", not in the spirit of "final deliverable". Therefore, while
it is true we've not yet reached out to everyone for input, that is
because it is still a work in progress for us. We'll iterate based on
feedback, and based upon yesterday and reaching out to other groups.
On 03/20/2012 11:52 AM, Peter Jones wrote:
> 1) mechanisms need to be in place to get package maintainers access to fix
> arm-specific bugs in their packages
So we have a tracker bug at the moment. Is that sufficient? If so, we
obviously should make sure that it is included in the proposal docs that
we have this in place and are using it.
No, that's not sufficient. The plan can't be "if you have a bug that only
shows up on arm, you file a bug and help you out." Part of what being a
primary architecture means is enabling package maintainers to do the
maintenance on their package. That's why, for example, secondary arch
maintainers have wide commit approval, but there's no such concept for
primary architectures.
> 2) excludearch is not an option. This is fundamentally contrary
to being
> a primary arch. In fact this is one of the defining characteristics of
> a secondary arch.
Let's think about this some. ARM (32-bit) doesn't do Intel-style
microcode, MCE, or many other things that x86 does. I don't think that
means we should build packages that are x86-specific for ARM systems.
The proposal didn't suggest this, and that wasn't what I was referring to
either. The specific phrasing you guys used was "Any packages that fail to
build on ARM are marked with excludearch by a proven packager." This is
not okay. Packages that are truly x86 specific - and I'm not talking about
incidental build failures due to bugs - should already have ExclusiveArch
tags in them limiting them to that architecture.
We generally believe that we're starting from a point of good
momentum, but there are some packages that won't ever be appropriate
for ARM, and there are others where the FTBFS has been longstanding,
or there are other (IMO valid) reasons why it might initially be
Exclude.
And again, we're not talking about packages that are wholly inappropriate.
That doesn't mean that there would be many such cases.
Nonetheless,
I think it would be unreasonable to set the entry bar so high that
there can be no things left to fix. That basically retains the x86
monopoly.
I don't mean to be saying there can't be outstanding bugs, but that's not
what you're saying either. Adding ExclusiveArch to packages which are meant
to eventually work is a form of papering over the problems. It's one thing
to have outstanding issues; it's another thing to introduce non-fixes into
packages for those issues.
> 3) arm must be integrated to the formal release criteria
Agreed. We'll need to figure that out.
> 4) when milestones occur, arm needs to be just as testible as other
> primary architectures
So we have a new hire (hi Paul) who is looking at autoqa, and we're
going to pull together as much as we can here. It would help me to know
(and we're reaching out to QE separately - per my other mail) what you
would consider "testable" to mean, in terms of what you'd want to see.
I'd largely defer to adamw for specific criteria regarding testing, both
in terms of criteria we're testing for (i.e. #3) and in terms of establishing
appropriate testing procedures for the platform. I've largely listed those
because there's not really any indication in the proposal as it stands
that this is well-considered at this point in time. There's a brief section
on how to test, but it appears to be largely pro-forma.
> 5) installation methods must be in place. I'm not saying it
has to be
> using the same model as x86, but when we get to beta, if it can't be
> installed, it can't meet similar release criteria to existing or prior
> primary arches. Where possible, we should be using anaconda for
> installation, though I'd be open to looking at using it to build
> installed images for machines with severe resource constraints.
So we feel it more appropriate to use image creation tools at this
point, for the 32-bit systems that we have in mind.
I don't disagree, and I think I made that pretty clear in all those
caveats you've generously quoted. I've heard that you've been talking to
bcl about this. I encourage you to continue on that route.
--
Peter
9:36 p.m.
On Tue, 2012-03-20 at 13:39 -0400, Peter Jones wrote:
>> 4) when milestones occur, arm needs to be just as testible
as other
>> primary architectures
>
> So we have a new hire (hi Paul) who is looking at autoqa, and we're
> going to pull together as much as we can here. It would help me to know
> (and we're reaching out to QE separately - per my other mail) what you
> would consider "testable" to mean, in terms of what you'd want to
see.
I'd largely defer to adamw for specific criteria regarding testing, both
in terms of criteria we're testing for (i.e. #3) and in terms of establishing
appropriate testing procedures for the platform. I've largely listed those
because there's not really any indication in the proposal as it stands
that this is well-considered at this point in time. There's a brief section
on how to test, but it appears to be largely pro-forma.
>> 5) installation methods must be in place. I'm not saying it has to be
>> using the same model as x86, but when we get to beta, if it can't be
>> installed, it can't meet similar release criteria to existing or prior
>> primary arches. Where possible, we should be using anaconda for
>> installation, though I'd be open to looking at using it to build
>> installed images for machines with severe resource constraints.
>
> So we feel it more appropriate to use image creation tools at this
> point, for the 32-bit systems that we have in mind.
So, my take on this is that if we're to do release validation for ARM,
at a stage where there is no anaconda-for-ARM and our official ARM
deployment method is 'download the image file for your hardware and
flash it' (or however the image file gets written exactly), then we're
going to wind up with release criteria and validation tests for ARM
which look very different from what we have for x86.
I suppose the picture that forms in my mind is that I'd expect
generation of the images to be fully scripted and automated, and for
validation to essentially consist of testing that the generated images
in fact work on each of the 'supported' platforms.
So what I'd expect to be happening is we'd have a list of supported ARM
devices, and we'd want QA to have access to at least one of each of
those devices. Then 'validation testing' for ARM would consist of just
throwing the images at the devices and seeing what stuck.
Desktop validation would be broadly the same as x86, if desktop is
something we'd actually be expecting to work on ARM. I rather would
expect that to be the case, if we were calling it a primary
architecture. By the same token, though, I would rather expect it to
track very closely with x86, as it's all relatively high level code that
ought to behave the same way on both, give or take graphics drivers.
I suppose I'd expect it to be something less of a heroic undertaking
than x86 validation testing, so long as we have this model of a
relatively small set of images for deployment to a relatively small set
of relatively non-customizable bits of hardware. Almost all the
difficulty and complexity in x86 validation comes from the fact that we
definitely don't have that.
--
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Twitter: AdamW_Fedora | identi.ca: adamwfedora
http://www.happyassassin.net
7:23 a.m.
On Wed, Mar 21, 2012 at 2:36 AM, Adam Williamson <awilliam(a)redhat.com> wrote:
On Tue, 2012-03-20 at 13:39 -0400, Peter Jones wrote:
> >> 4) when milestones occur, arm needs to be just as testible as other
> >> primary architectures
> >
> > So we have a new hire (hi Paul) who is looking at autoqa, and we're
> > going to pull together as much as we can here. It would help me to know
> > (and we're reaching out to QE separately - per my other mail) what you
> > would consider "testable" to mean, in terms of what you'd want to
see.
>
> I'd largely defer to adamw for specific criteria regarding testing, both
> in terms of criteria we're testing for (i.e. #3) and in terms of establishing
> appropriate testing procedures for the platform. I've largely listed those
> because there's not really any indication in the proposal as it stands
> that this is well-considered at this point in time. There's a brief section
> on how to test, but it appears to be largely pro-forma.
>
> >> 5) installation methods must be in place. I'm not saying it has to be
> >> using the same model as x86, but when we get to beta, if it can't be
> >> installed, it can't meet similar release criteria to existing or
prior
> >> primary arches. Where possible, we should be using anaconda for
> >> installation, though I'd be open to looking at using it to build
> >> installed images for machines with severe resource constraints.
> >
> > So we feel it more appropriate to use image creation tools at this
> > point, for the 32-bit systems that we have in mind.
So, my take on this is that if we're to do release validation for ARM,
at a stage where there is no anaconda-for-ARM and our official ARM
deployment method is 'download the image file for your hardware and
flash it' (or however the image file gets written exactly), then we're
going to wind up with release criteria and validation tests for ARM
which look very different from what we have for x86.
I suppose the picture that forms in my mind is that I'd expect
generation of the images to be fully scripted and automated, and for
validation to essentially consist of testing that the generated images
in fact work on each of the 'supported' platforms.
Absolutely agree. I think initially it will likely be a number of
images (similar to spins gnome/kde/xfce/minimal) and then a tool like
livecd-creator where you can do "livecd-creator --ARM
--device=pandaboard image-name-xfce.img /dev/sdb" and it will take the
img and ensure it has all the relevant bits in place for a particular
device.
So what I'd expect to be happening is we'd have a list of
supported ARM
devices, and we'd want QA to have access to at least one of each of
those devices. Then 'validation testing' for ARM would consist of just
throwing the images at the devices and seeing what stuck.
That's my understanding too.
Desktop validation would be broadly the same as x86, if desktop is
something we'd actually be expecting to work on ARM. I rather would
expect that to be the case, if we were calling it a primary
architecture. By the same token, though, I would rather expect it to
track very closely with x86, as it's all relatively high level code that
ought to behave the same way on both, give or take graphics drivers.
Yes, and we're already pretty much there in terms of packages. In
terms of graphics there's some movement here for 2D through a number
of devices getting kms drivers into the kernel that should work with
the basic xorg-x11-drv-modesetting driver. 3D is a work in progress,
but then you don't have to look too far back into the x86 history to
see that it's only really got to a decent state on x86 in recent
times.
I suppose I'd expect it to be something less of a heroic
undertaking
than x86 validation testing, so long as we have this model of a
relatively small set of images for deployment to a relatively small set
of relatively non-customizable bits of hardware. Almost all the
difficulty and complexity in x86 validation comes from the fact that we
definitely don't have that.
Yes, I agree. In the initial phase we were looking at supporting the
development boards so this is basically a small number of devices
(TrimSlice, PanadaBoard, BeagleBoard, Origen, Snowball and Freescale)
that have completely open stacks including unaccelerated graphics.
There's others that currently have issues regarding that such as the
Raspberry Pi which while could be used for testing obviously have
binary bits that make it not quite perfect yet.
Peter
8:13 p.m.
Peter Robinson wrote:
Yes, I agree. In the initial phase we were looking at supporting the
development boards so this is basically a small number of devices
(TrimSlice, PanadaBoard, BeagleBoard, Origen, Snowball and Freescale)
that have completely open stacks including unaccelerated graphics.
There's others that currently have issues regarding that such as the
Raspberry Pi which while could be used for testing obviously have
binary bits that make it not quite perfect yet.
Supporting any images containing binary drivers in the sense that Fedora
release QA of any sort would be done on those images is totally
unacceptable.
Kevin Kofler
2:34 p.m.
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
On Tue, 20 Mar 2012 19:36:00 -0700
Adam Williamson <awilliam(a)redhat.com> wrote:
On Tue, 2012-03-20 at 13:39 -0400, Peter Jones wrote:
> >> 4) when milestones occur, arm needs to be just as testible as
> >> other primary architectures
> >
> > So we have a new hire (hi Paul) who is looking at autoqa, and
> > we're going to pull together as much as we can here. It would
> > help me to know (and we're reaching out to QE separately - per my
> > other mail) what you would consider "testable" to mean, in terms
> > of what you'd want to see.
>
> I'd largely defer to adamw for specific criteria regarding testing,
> both in terms of criteria we're testing for (i.e. #3) and in terms
> of establishing appropriate testing procedures for the platform.
> I've largely listed those because there's not really any indication
> in the proposal as it stands that this is well-considered at this
> point in time. There's a brief section on how to test, but it
> appears to be largely pro-forma.
>
> >> 5) installation methods must be in place. I'm not saying it has
> >> to be using the same model as x86, but when we get to beta, if
> >> it can't be installed, it can't meet similar release criteria to
> >> existing or prior primary arches. Where possible, we should be
> >> using anaconda for installation, though I'd be open to looking
> >> at using it to build installed images for machines with severe
> >> resource constraints.
> >
> > So we feel it more appropriate to use image creation tools at this
> > point, for the 32-bit systems that we have in mind.
So, my take on this is that if we're to do release validation for ARM,
at a stage where there is no anaconda-for-ARM and our official ARM
deployment method is 'download the image file for your hardware and
flash it' (or however the image file gets written exactly), then we're
going to wind up with release criteria and validation tests for ARM
which look very different from what we have for x86.
I suppose the picture that forms in my mind is that I'd expect
generation of the images to be fully scripted and automated, and for
validation to essentially consist of testing that the generated images
in fact work on each of the 'supported' platforms.
for fedora 18 im planning to move to media-creator, which uses anaconda
to make ec2 and live images. arm images will basically be the same
type of thing as ec2 images, a raw disk that can be installed onto a
sdcard and booted. For arm to be a primary arch this has to work, and
has to be supported inside of koji, the same as we do today for x86
lives and ec2 images. there is a small set of the the initial targeted
hardware that could use a traditional anaconda install. most of it can
not. those devices that can can also make use of a live sdcard. so i
see that as priority 1 for working. with priority 2 being supporting
installs using anaconda and kickstarts. I do not see us making any type
of isos for arm.
Dennis
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.18 (GNU/Linux)
iEYEARECAAYFAk9qLUMACgkQkSxm47BaWfc4IgCgvlREMiv5Y5ftJC/LR/3OHc8A
ax8AnjNrUK4Xl68GD//VECUiH+c1LtNy
=CkjD
-----END PGP SIGNATURE-----
12:44 p.m.
Jon Masters wrote:
On 03/20/2012 11:52 AM, Peter Jones wrote:
> 7) it can't be a serious maintenance burdon due to build related issues.
>We need a couple of groups to sign off that builds are fast enough, not
>just on a "full distro rebuild" (throughput) level, but also on a
>"doesn't destroy my workflow due to waiting on it" (latency) level.
Sure. Absolutely is a concern for us, as you can see from my other
comments above about the kernel, for example, but not just that.
Sorry, but I don't think this is fixable any time soon. Come back when (if
ever) you have hardware which has comparable speed to x86.
Kevin Kofler
12:49 p.m.
On Tue, Mar 20, 2012 at 06:44:43PM +0100, Kevin Kofler wrote:
Jon Masters wrote:
> Sure. Absolutely is a concern for us, as you can see from my other
> comments above about the kernel, for example, but not just that.
Sorry, but I don't think this is fixable any time soon. Come back when (if
ever) you have hardware which has comparable speed to x86.
I think your point's been pretty clearly made now. It doesn't further
the conversation to repeat it in reply to every message in the thread.
--
Matthew Garrett | mjg59(a)srcf.ucam.org
4:39 a.m.
On 03/20/2012 05:44 PM, Kevin Kofler wrote:
Jon Masters wrote:
> > On 03/20/2012 11:52 AM, Peter Jones wrote:
>> >> 7) it can't be a serious maintenance burdon due to build related
issues.
>> >>We need a couple of groups to sign off that builds are fast enough, not
>> >>just on a "full distro rebuild" (throughput) level, but also on
a
>> >>"doesn't destroy my workflow due to waiting on it"
(latency) level.
> >
> > Sure. Absolutely is a concern for us, as you can see from my other
> > comments above about the kernel, for example, but not just that.
Sorry, but I don't think this is fixable any time soon. Come back when (if
ever) you have hardware which has comparable speed to x86.
I'm trying to figure out what this means. Do you mean that any
primary architecture must be as fast as x86 is today, or that it must
be as fast as its contemporary version of the x86? So, if the x86 got
faster but ARM didn't, then ARM would be dropped?
The way I see the CPU market developing over the next few years is
that the x86 will continue to be the speed demon if you measure MIPS
per core, but other competitors, especially ARM, will focus on cores
per die. If we stick religiously to "comparable speed to x86"
(whatever that means) Fedora can never be a primary arch for anything
other than x86. Even if we have builders with dozens or even hundreds
of cores.
This is wrong, in my view. If we have a great many parallel
processors waiting for work, times waiting for build won't be so
great. The future does not look like ever-increasing MIPS per
core, but ever-increasing parallelism. If Fedora is the OS of
the future, we'd better start to embrace that.
Andrew.
8:38 p.m.
Andrew Haley wrote:
I'm trying to figure out what this means. Do you mean that any
primary architecture must be as fast as x86 is today, or that it must
be as fast as its contemporary version of the x86? So, if the x86 got
faster but ARM didn't, then ARM would be dropped?
Good question. I think the answer depends on how much faster the future x86
CPUs will be compared to today's x86 CPUs (and also compared to the future
ARM CPUs).
The way I see the CPU market developing over the next few years is
that the x86 will continue to be the speed demon if you measure MIPS
per core, but other competitors, especially ARM, will focus on cores
per die. If we stick religiously to "comparable speed to x86"
(whatever that means) Fedora can never be a primary arch for anything
other than x86. Even if we have builders with dozens or even hundreds
of cores.
This is wrong, in my view. If we have a great many parallel
processors waiting for work, times waiting for build won't be so
great. The future does not look like ever-increasing MIPS per
core, but ever-increasing parallelism. If Fedora is the OS of
the future, we'd better start to embrace that.
First of all, one thing you have to realize is that many workloads are
inherently NOT parallelizable. And even workloads which parallelize fairly
well normally have serial portions and/or a nontrivial critical path. Thus,
MIPS per core will always be an important metric, even though the CPU
manufacturers are trying to explain that away because physical limitations
are making it harder and harder for them to make improvements there.
Now of course, parallel computing IS going to be more and more important in
the future. (Programmers are already throwing away a lot of current CPUs'
performance in that area, with most of today's CPUs being multi-core and
many applications still being single-threaded or de-facto single-threaded
(one main thread plus helper threads which are almost always blocking).) But
I don't see this as an ARM-exclusive domain. x86 CPUs are also increasing
the number of cores more and more. I'm not convinced ARM can win the
performance war (in the long run) based on parallelism alone (even in the
ideal case of linear speedup, which is rather unlikely in practical
applications).
And finally, for our build speed issue, the practical consideration will be
whether the parallelism will actually speed our builds up. Right now our
builds are either serial or have portions parallelized with "make -j", which
assumes a single multi-CPU computer (but the "multi-core" ARM setups
actually present themselves as a multi-computer cluster, which is not
supported by "make -j", not as a multi-CPU computer), so the parallelism
does little to the latency of an individual build (though of course it does
help the overall throughput).
IMHO, if even in the future only x86 will fit the speed criteria to be a
primary architecture for Fedora, then so be it. I do not see a need for any
other primary architecture(s). Why do we absolutely have to support an
architecture with inferior practical performance as a primary architecture?
(Note that I talk about PRACTICAL performance here: While the ARM
architecture may or may not theoretically allow faster CPUs than the x86
architecture, this is of no use if no such CPUs are actually available.)
Kevin Kofler
8:59 p.m.
Kevin Kofler <kevin.kofler(a)chello.at> writes:
IMHO, if even in the future only x86 will fit the speed criteria to
be a
primary architecture for Fedora, then so be it. I do not see a need for any
other primary architecture(s). Why do we absolutely have to support an
architecture with inferior practical performance as a primary architecture?
To put it as succinctly as possible: monocultures are bad. Focusing on
just one arch is dangerous; you end up with non-portable code, and
non-portable code is more often than not inferior on more measures than
just the fact that it only works on one arch. But even if that's the
only thing wrong with the code, you're still boxing yourself in if you
don't strive to make it portable. Do you really think that x86 will
be the most desirable architecture forever? Things change fast in this
business, and that arch is weighted down by enough bad ancient decisions
that I think it's eventually going to lose out.
I thought it was a serious error to drop PPC from primary-arch status.
But now that we've done that, putting in another one should be a high
priority wish-list item. I'm as concerned as anyone about whether we
can (in the near future) get ARM builders that are fast enough to make
it *practical* for ARM to be a PA. But I think denying that we need
non-Intel PAs is just fundamentally wrongheaded.
regards, tom lane
10:06 p.m.
Tom Lane wrote:
To put it as succinctly as possible: monocultures are bad.
That's what secondary architectures are for.
Do you really think that x86 will be the most desirable architecture
forever? Things change fast in this business, and that arch is weighted
down by enough bad ancient decisions that I think it's eventually going to
lose out.
That's when it will become the time to promote the secondary architecture
that eventually wins out to primary (and to start working on a plan to phase
out x86 and demote it to secondary as we did with PPC). Not now. We don't
even know whether ARM will be the architecture that eventually wins out yet!
I thought it was a serious error to drop PPC from primary-arch
status.
I think it was one of the best decisions Fedora ever made. I'm glad I don't
have to deal with slow PPC builders anymore, nor to fix build errors for
such an obsolescent architecture. PPC stopped being relevant the day Apple
switched to x86. The GNU/Linux on PS3 efforts managed to delay its death by
a couple years, but in hindsight that kind of platform is really what
secondary architectures are for! (It's not even a computer.) I think PPC had
actually been primary for way too long, the demotion to secondary was long
overdue when it was finally implemented.
But now that we've done that, putting in another one should be a
high
priority wish-list item.
I strongly disagree on that point. Non-x86 primary architectures are a major
pain that really needs to be avoided. Doing it just for the sake of having a
non-x86 primary architecture is just completely wrong! I really don't miss
the fights I had with ppc/ppc64 as a primary architecture (it was a royal
PITA for KDE packaging, some KDE module or dependency kept breaking due to
platform-specific toolchain bugs or limitations (ever heard of the infamous
PPC TOC? There's not much you can do when autogenerated SWIG bindings exceed
the PPC64 TOC size, and minimal-toc doesn't help when it's all in one
translation unit), and most of our builds were glacially slow due to PPC)
and am most definitely NOT looking forward to seeing this again.
I'm as concerned as anyone about whether we can (in the near
future) get
ARM builders that are fast enough to make it *practical* for ARM to be a
PA.
Me too! (At least one thing we agree on. ;-) )
But I think denying that we need non-Intel PAs is just fundamentally
wrongheaded.
And I couldn't disagree more (for the reasons explained above).
Kevin Kofler
10:37 p.m.
Kevin Kofler <kevin.kofler(a)chello.at> writes:
Tom Lane wrote:
> I thought it was a serious error to drop PPC from primary-arch status.
I think it was one of the best decisions Fedora ever made. I'm
glad I don't
have to deal with slow PPC builders anymore, nor to fix build errors for
such an obsolescent architecture. PPC stopped being relevant the day Apple
switched to x86.
That opinion is flat out ridiculous. Or maybe it makes sense if you
think consumer desktops are the be-all and end-all; but they are not.
(If you do think that Apple's decisions are an important factor here,
why are you so much not on board with pushing ARM? Apple's certainly
doing their darndest to make ARM a mainstream arch.)
> But now that we've done that, putting in another one should
be a high
> priority wish-list item.
I strongly disagree on that point. Non-x86 primary architectures are
a major
pain that really needs to be avoided.
And that opinion is simply wrong. You have provided no justification
for allowing Fedora to get boxed in on a single architecture, which is
the inevitable end result of the thinking you espouse. Pointing at
individual deficiencies of individual arches is not a justification;
especially not in view of all the problems x86 itself has got. The
Linux community has slowly worked around x86's limitations, the same
could happen for any other arch. The only reason this doesn't happen is
people trying to justify not putting in the work by rationalizing that
"that architecture is obsolete" or "Intel is the top of the heap today,
so I don't need to bother thinking about anything else". Or in other
words: you sir are not part of the solution, you are part of the
problem.
I'm not saying that I think ARM is the ideal other primary arch, but
it seems to have more momentum than most of the other choices. We
should be looking for ways to make it a PA, or make something else
a PA. We should not be looking for excuses for monoculturalism.
If we settle for that, we'll have only ourselves to blame when we
become irrelevant, not too many years down the road.
regards, tom lane
1:31 a.m.
Tom Lane wrote:
That opinion is flat out ridiculous. Or maybe it makes sense if you
think consumer desktops are the be-all and end-all; but they are not.
Consumer desktops and notebooks. The things we normally call "computers".
Those have always been and should remain our primary target.
(If you do think that Apple's decisions are an important factor
here,
why are you so much not on board with pushing ARM? Apple's certainly
doing their darndest to make ARM a mainstream arch.)
Apple's PPC machines were computers. Apple's ARM machines are not. One big
reason being that Apple is doing everything they can to prevent you from
installing a non-Apple operating system (such as Fedora) on them.
And that opinion is simply wrong. You have provided no justification
I did. The justification is that there is, at this time, only one
architecture seriously relevant for computers (defined as "desktops or
laptops/notebooks").
for allowing Fedora to get boxed in on a single architecture, which
is
the inevitable end result of the thinking you espouse.
It is not. Supporting more architectures (and having working ports to fall
back on when the need should arise) is what secondary architectures are for.
Pointing at individual deficiencies of individual arches is not a
justification; especially not in view of all the problems x86 itself has
got. The Linux community has slowly worked around x86's limitations, the
same could happen for any other arch.
Wow, you seem to really hate x86. But please accept the fact that, no matter
how much you hate x86, it is THE relevant architecture right now.
The only reason this doesn't happen is people trying to justify
not
putting in the work by rationalizing that "that architecture is obsolete"
In most cases, it is.
or "Intel is the top of the heap today, so I don't need to
bother thinking
about anything else".
I'd rephrase that as "That architecture is not mature yet.", i.e. the
opposite problem compared to "That architecture is obsolete."
It will be time to consider ARM for primary architecture status when it will
be a serious contender in the computer (as defined previously) market.
Or in other words: you sir are not part of the solution, you are part
of
the problem.
I still see no problem.
I'm not saying that I think ARM is the ideal other primary arch,
but
it seems to have more momentum than most of the other choices. We
should be looking for ways to make it a PA, or make something else
a PA. We should not be looking for excuses for monoculturalism.
They're not "excuses", they're valid reasons to not waste valuable
developer
time on niche architectures. Let the people who care about those
architectures work on them (which is how the secondary architecture system
works)!
If we settle for that, we'll have only ourselves to blame when
we
become irrelevant, not too many years down the road.
Nonsense. As long as we have healthy secondary architectures, we can promote
them to primary when it really makes sense, i.e. when/if the x86 apocalypse
happens. (By the way, don't count on it happening at all. The end of x86 has
been proclaimed so many times, yet each of the prophecies has been proven
wrong so far. Not even the move to 64-bit and Intel putting its weight
behind a non-x86 64-bit architecture were able to kill x86. What was killed
instead was the Itanium, dubbed "Itanic" by many. Don't be too quick to
write off x86!) There is no need whatsoever to make the move to primary now.
Who knows what architecture (if any) will replace x86 in the end, it might
not be ARM at all!
Kevin Kofler
8:11 a.m.
On 03/22/2012 02:31 AM, Kevin Kofler wrote:
Tom Lane wrote:
> That opinion is flat out ridiculous. Or maybe it makes sense if you
> think consumer desktops are the be-all and end-all; but they are not.
Consumer desktops and notebooks. The things we normally call "computers".
Those have always been and should remain our primary target.
Check out the numbers from The Economist:
http://media.economist.com/sites/default/files/imagecache/full-width/2011...
The number of desktops has been flat for last 7 years. The growth in the
smartphone/tablet area dwarfs 'what we normally call computers'.
The whole article is at http://www.economist.com/node/21531109
Wow, you seem to really hate x86. But please accept the fact that, no
matter
how much you hate x86, it is THE relevant architecture right now.
ARM claims an installed base of 25 billion CPUS, and current deployment
rate of 6 billion new CPUs per year. Granted, a large fraction of that
are microcontrollers (single purpose, no virtual memory etc), but still,
the total number of x86 machines is about 500 million.
Nonsense. As long as we have healthy secondary architectures, we can
promote
them to primary when it really makes sense, i.e. when/if the x86 apocalypse
happens. (By the way, don't count on it happening at all. The end of x86 has
been proclaimed so many times, yet each of the prophecies has been proven
wrong so far. Not even the move to 64-bit and Intel putting its weight
behind a non-x86 64-bit architecture were able to kill x86. What was killed
instead was the Itanium, dubbed "Itanic" by many. Don't be too quick to
write off x86!) There is no need whatsoever to make the move to primary now.
I had an interesting discussion with VIA---asked them why don't they
compete with Intel's inexpensive Atom platforms. They weren't interested
in the low end; they claimed that there's plenty of demand for
traditional 'few hundred bucks' price point. I think they are wrong
about how sustainable that demand is---ARM has low-end CPUs for >1$ (ST,
NXP, TI), and the OS-capable ones for under 10$.
Now, does it mean that we need to rush the ARM primary architecture? Of
course not--as others have said, one gets the job because one can do the
job, but we need to figure out the details of how to get there:
- toolchain/build environment speed
- better and/or standard installation mechanism
- QA techniques
9:04 a.m.
Le Jeu 22 mars 2012 14:11, Przemek Klosowski a écrit :
On 03/22/2012 02:31 AM, Kevin Kofler wrote:
> Tom Lane wrote:
>> That opinion is flat out ridiculous. Or maybe it makes sense if you
>> think consumer desktops are the be-all and end-all; but they are not.
>
> Consumer desktops and notebooks. The things we normally call "computers".
> Those have always been and should remain our primary target.
>
Check out the numbers from The Economist:
http://media.economist.com/sites/default/files/imagecache/full-width/2011...
The number of desktops has been flat for last 7 years. The growth in the
smartphone/tablet area dwarfs 'what we normally call computers'.
Apples and oranges. You could print the same stats a few years ago about cars
vs scooters/bicycles
Guess what all the Chinese/Indian bicycle riders started to buy as soon as
they had the means to…
All those numbers show is that the developing countries are actually
developing (surprise!), and that they transition from nothing to cheapest
solution possible. That does not mean they'll stick to this stage forever.
--
Nicolas Mailhot
9:12 a.m.
On Thu, Mar 22, 2012 at 4:04 PM, Nicolas Mailhot <
nicolas.mailhot(a)laposte.net> wrote:
Le Jeu 22 mars 2012 14:11, Przemek Klosowski a écrit :
> On 03/22/2012 02:31 AM, Kevin Kofler wrote:
>> Tom Lane wrote:
>>> That opinion is flat out ridiculous. Or maybe it makes sense if you
>>> think consumer desktops are the be-all and end-all; but they are not.
>>
>> Consumer desktops and notebooks. The things we normally call
"computers".
>> Those have always been and should remain our primary target.
>>
> Check out the numbers from The Economist:
>
http://media.economist.com/sites/default/files/imagecache/full-width/2011...
>
> The number of desktops has been flat for last 7 years. The growth in the
> smartphone/tablet area dwarfs 'what we normally call computers'.
Apples and oranges. You could print the same stats a few years ago about
cars
vs scooters/bicycles
Guess what all the Chinese/Indian bicycle riders started to buy as soon as
they had the means to…
All those numbers show is that the developing countries are actually
developing (surprise!), and that they transition from nothing to cheapest
solution possible. That does not mean they'll stick to this stage forever.
So you guess that they'll move on to desktop computers as long they have
the means, and we should not bother investing resources to this
intermediate phase. Even if it last for years.
Despite the fact that this is pretty wild guess, I don't think that Fedora
should only care about what's happening on the developed countries and
ignore the rest of the world.
Bottom line, it seems apples and apples to me. Naming it oranges just to
ignore it, doesn't qualify as an argument.
2:35 p.m.
On Thu, 2012-03-22 at 16:12 +0200, Nikos Roussos wrote:
Despite the fact that this is pretty wild guess, I don't think that
Fedora should only care about what's happening on the developed
countries and ignore the rest of the world.
I don't think this is necessarily a developed-vs-developing thing. I did
a talk on this at FSOSS 2011, suggesting that we're heading towards
three physical tiers:
(A) Content-consuming platforms - tablets/MIDs/smartphones. Almost all
of these are taking a tablet-like form factor (counting most smartphones
as 'tiny tablets'). These are great for consuming content - reading,
surfing, watching, playing - but they are awful for creating content --
they don't have the horsepower, storage I/O, screen real estate, or
long-use-comfortable UI devices for writing long documents, editing
video, or composing multitrack sound. Most of these devices run ARM for
low energy consumption, small size, and low cost, and many run some kind
of a Linux system (even if Android).
(B) Content-creation platforms - desktop/laptop. These devices aren't
going away anytime soon, because there are a lot of people who create
content or capture information -- students, bookkeepers, bloggers, video
creators, developers, documentation writers, animators, graphics
artists, engineers, secretaries, and so forth. A lot of the Fedora
community falls into one or more of these categories, so any
navel-gazing sample we take will be skewed toward this category. To be
frank, Intel x86, proprietary operating systems (Windows and Mac OS/X),
and proprietary apps still reign in this space. However, most creators
consume a lot more than they create, so we will increasingly find that
people who have devices in this category also have a device in category
(A). This category is waning as many people realize that they are almost
entirely content consumers and re-equip themselves with devices in
category (A).
(C) The Cloud - whether private cloud or public cloud, the backend lives
here, and this connects the content creators to the content consumers.
Space, heat, and power costs and scaling issues are driving cloud
operators to look for new solutions. ARM is looking like a pretty good
option but has not yet been proven in this space. Projects that have a
legacy component often use proprietary software here, but the majority
of new cloud projects use open source for a significant part of the
stack.
So of the three categories, two are on the rise, and one is on the
decline. The ones on the rise are categories where ARM competes well and
open source software thrives. If we want to remain relevant as a
community and project, we need to adapt and move our focus to these
emerging/rising categories -- hence the focus on Fedora ARM.
-Chris
9:12 a.m.
On Thu, 2012-03-22 at 15:04 +0100, Nicolas Mailhot wrote:
Le Jeu 22 mars 2012 14:11, Przemek Klosowski a écrit :
> On 03/22/2012 02:31 AM, Kevin Kofler wrote:
>> Tom Lane wrote:
>>> That opinion is flat out ridiculous. Or maybe it makes sense if you
>>> think consumer desktops are the be-all and end-all; but they are not.
>>
>> Consumer desktops and notebooks. The things we normally call
"computers".
>> Those have always been and should remain our primary target.
>>
> Check out the numbers from The Economist:
>
http://media.economist.com/sites/default/files/imagecache/full-width/2011...
>
> The number of desktops has been flat for last 7 years. The growth in the
> smartphone/tablet area dwarfs 'what we normally call computers'.
Apples and oranges. You could print the same stats a few years ago about cars
vs scooters/bicycles
Guess what all the Chinese/Indian bicycle riders started to buy as soon as
they had the means to…
All those numbers show is that the developing countries are actually
developing (surprise!), and that they transition from nothing to cheapest
solution possible. That does not mean they'll stick to this stage forever.
And even if they sticked to this stage it still would not mean that the
market for full featured computers would somehow disappear. We are still
talking only about relative number changes. In absolute numbers the full
featured computers are still rising.
--
Tomas Mraz
No matter how far down the wrong road you've gone, turn back.
Turkish proverb
12:53 p.m.
On Mar 22, 2012, at 8:04 AM, Nicolas Mailhot wrote:
>
Apples and oranges. You could print the same stats a few years ago about cars
vs scooters/bicycles
Guess what all the Chinese/Indian bicycle riders started to buy as soon as
they had the means to…
They did not, are not. Especially in congested cities. Most New Yorkers in Manhattan can
afford cars. They don't have them. There's other infrastructure that works better,
and they don't need to individually own it.
You're making assumptions that people really want desktop machines, it's just a
matter of affording it. You're applying your own preferences to a huge market, which
doesn't have your requirements, but does have its own. Desktops have from day 1 been
*irritating* to most users. They were not embraced in the home. They were never loved.
They came into the home via work, hobbyists, kids for school work, and then entertainment
(music, pictures, video) and became useful.
Mobile and tablets are immediately useful. It took almost no time for the market to grow
up once a certain company released a product. And people love these things. Normal every
day non-geeks cry if they get broken or lost.
All those numbers show is that the developing countries are actually
developing (surprise!), and that they transition from nothing to cheapest
solution possible. That does not mean they'll stick to this stage forever.
It's like arguing they will build landlines, because they're more reliable and
have better call quality. And cell phones are just a stage that they won't be in
forever.
Wrong argument.
Chris
1:38 p.m.
On Thu, 2012-03-22 at 09:11 -0400, Przemek Klosowski wrote:
On 03/22/2012 02:31 AM, Kevin Kofler wrote:
> Tom Lane wrote:
>> That opinion is flat out ridiculous. Or maybe it makes sense if you
>> think consumer desktops are the be-all and end-all; but they are not.
>
> Consumer desktops and notebooks. The things we normally call "computers".
> Those have always been and should remain our primary target.
>
Check out the numbers from The Economist:
http://media.economist.com/sites/default/files/imagecache/full-width/2011...
The number of desktops has been flat for last 7 years. The growth in the
smartphone/tablet area dwarfs 'what we normally call computers'.
Note that all the numbers where smartphones/tablets 'dwarf what we
normally call computers' are, in fact, projections. In the numbers which
actually exist, tablets/smartphones have only just caught up with
computers.
--
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Twitter: AdamW_Fedora | identi.ca: adamwfedora
http://www.happyassassin.net
3:13 p.m.
On 03/22/2012 02:38 PM, Adam Williamson wrote:
On Thu, 2012-03-22 at 09:11 -0400, Przemek Klosowski wrote:
> On 03/22/2012 02:31 AM, Kevin Kofler wrote:
>> Tom Lane wrote:
>>> That opinion is flat out ridiculous. Or maybe it makes sense if you
>>> think consumer desktops are the be-all and end-all; but they are not.
>>
>> Consumer desktops and notebooks. The things we normally call
"computers".
>> Those have always been and should remain our primary target.
>>
> Check out the numbers from The Economist:
>
http://media.economist.com/sites/default/files/imagecache/full-width/2011...
>
> The number of desktops has been flat for last 7 years. The growth in the
> smartphone/tablet area dwarfs 'what we normally call computers'.
Note that all the numbers where smartphones/tablets 'dwarf what we
normally call computers' are, in fact, projections. In the numbers which
actually exist, tablets/smartphones have only just caught up with
computers.
Fair enough, but the trends are well established, and the data are for
_shipments_ so the actual deployed numbers are compounded (flat
shipments translate to steady growth, linear or faster shipment growth
means quadratic or maybe even exponential growth).
Of course predictions are tricky, especially when they concern the
future :) but I believe those here will bear out. I see more future
needs, and more need for improvement, in the mobile areas. Looking close
to home, I note that we bought more mobile gear than traditional
computers in last two years.
3:30 p.m.
On Thu, 2012-03-22 at 16:13 -0400, Przemek Klosowski wrote:
Of course predictions are tricky, especially when they concern the
future :)
I am curious as to what _other_ types of prediction you think exist. =)
--
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Twitter: AdamW_Fedora | identi.ca: adamwfedora
http://www.happyassassin.net
9:42 p.m.
Przemek Klosowski wrote:
Fair enough, but the trends are well established, and the data are
for
shipments so the actual deployed numbers are compounded (flat
shipments translate to steady growth, linear or faster shipment growth
means quadratic or maybe even exponential growth).
Quite the opposite, shipments are related to the first (discrete) derivative
of active deployments, which will necessarily amplify the effects: if the
number of shipments decreases, that just means that growth in deployments is
slowing down, not that the number of deployments decreases.
But another thing you must not forget is that you cannot make direct
deductions from the number of shipments to the number of deployments,
because there's also the number of decommissionings (i.e. the device breaks,
gets thrown away etc.). The derivative of the number of deployments is in
fact the number of shipments minus the number of decommissionings.
I suspect that cell phones are simply replaced more often than computers
right now, because smart phones have been improving much faster than
computers lately (but that trend might be already reaching its limits now).
For computers, Moore's law (on the number of transistors) just doesn't have
as user-visible effects (clock speeds!) as it used to. But despite all this,
computers are still the more powerful devices.
Kevin Kofler
9:33 a.m.
On 03/22/2012 10:42 PM, Kevin Kofler wrote:
Przemek Klosowski wrote:
> Fair enough, but the trends are well established, and the data are
> for shipments so the actual deployed numbers are compounded (flat
> shipments translate to steady growth, linear or faster shipment
> growth means quadratic or maybe even exponential growth).
Quite the opposite, shipments are related to the first (discrete)
derivative of active deployments, which will necessarily amplify the
effects: if the number of shipments decreases, that just means that
growth in deployments is slowing down, not that the number of
deployments decreases.
I think we're saying the same thing here; the point is that compounding
amplifies even small trends.
A computer is often a per-household device. A cellphone is per
person, or even multiple devices per person (e.g. multiple phones
with different contracts, or a phone and a tablet, etc.). So the
total number is necessarily going to be larger without there being
more users.
Of course, but numbers are numbers; we just have to pay attention to
lighter, mobile formfactors. It is the same reasoning as in the desktop
vs. server dilemma 15 years ago: you could say that 'servers are
per-company devices', so Linux has been concentrating on the desktops,
where the numbers were---while still paying attention to servers. As we
know it's a good idea to optimize for both desktop and server; they
aren't contradictory.
As I wrote responding to Nicolas, the GUI interaction concepts from
mobiles are relevant to all platforms, and it is appropriate to think
ahead and seek a model that serves both. Microsoft also seems to follow
this direction, and implements it, however awkwardly, in Windows 8.
7:14 p.m.
Przemek Klosowski wrote:
Of course, but numbers are numbers; we just have to pay attention to
lighter, mobile formfactors. It is the same reasoning as in the desktop
vs. server dilemma 15 years ago: you could say that 'servers are
per-company devices', so Linux has been concentrating on the desktops,
where the numbers were---while still paying attention to servers. As we
know it's a good idea to optimize for both desktop and server; they
aren't contradictory.
Actually, GNU/Linux has been focusing on servers for years, and still does.
Look at what the main target for RHEL is. Or why Debian's release cycle is
built around the "stable" release. Fedora has a strong desktop focus because
it's pace of innovation is scaring server owners away (and yet, even in
Fedora, there's a Server SIG), but GNU/Linux in general is primarily a
server operating system!
Kevin Kofler
9:57 a.m.
On 03/23/2012 05:59 AM, Nicolas Mailhot wrote:
And yes smartphones are booming, but they're not booming because
they
are a good desktop substitute, they're booming because they are a
good dumbphone substitute (and before that digital cameras replaced
chemical cameras, and mp3 readers replaced walkmans, and I'm sure if
someone had counted the chips in them it would have made an
impressive established trend dwarfing the number of computers of that
era)
Let's not forget why we're talking about this. The point was made to put
more effort in developing ARM Fedora because of the increasing
importance of that platform. I believe that is a correct assessment in a
broad sense, even if the details are arguable. In my mind, it's as much
about the architecture as about the supported set of hardware features
and modes of user interaction.
I am not claiming that tablets are the ultimate platform that will
replace everything else. Rather, I think that the direct manipulation
GUIs that originated on the mobile devices are a good idea on all
platforms, and I prefer that a mature desktop system like Fedora evolves
to include it, rather than trying to add functionality to mobile
platform. I don't want Android on whatever I use at my desk in few years.
Don't get me wrong---I love my droid but it is sometimes a frustrating
relationship. A lot of tools that I am used to on the desktop are
missing---some for good reason (limitations of small screen, awkward
keyboard) but sometimes it's just not there because the dev environment
is too different and there's no port.
4:59 a.m.
Le Jeu 22 mars 2012 21:13, Przemek Klosowski a écrit :
Fair enough, but the trends are well established,
Like the netbook trends were well established?
In the last years there has been a clear struggle between users that want
cheaper computing and hardware manufacturers that want either to up-sell them
(Apple, ultrabooks), or if they can't, sell cheaper secondary devices
carefully neutered ('tailored') so they don't compete with full-power
computing devices.
I've lost the count of the new 'revolutionary' form factors that were
promised
hegemony by journalists and that flopped after promising starts when either
the consumers realised they were being short-selled devices with limited
capabilities, or were quietly killed by the industry when they threatened to
replace more expensive offerings.
And yes smartphones are booming, but they're not booming because they are a
good desktop substitute, they're booming because they are a good dumbphone
substitute (and before that digital cameras replaced chemical cameras, and mp3
readers replaced walkmans, and I'm sure if someone had counted the chips in
them it would have made an impressive established trend dwarfing the number of
computers of that era)
And tablets (as general-computing devices, not as e-ink book readers) are an
unknown. The only people not realising this are affluent professionals who can
afford to participate in the latest fad and whose budget is barely dented by
experimenting with the latest gadget. (the same people swore laptops would
extinguish desktops – last I've seen desktops were still there ; and a laptop
with a docking station, a separate screen/keyboard/mouse/printer, that barely
moves from the docking station table, is just a desktop with a new central
unit design)
The general population worries more about cost-effectiveness. The tablet costs
are there but what of its effectiveness? An average user may spend most of its
time consuming, but with e-trade, e-administration, e-taxes he needs a
computing device too nowadays. Anything that can not handle those tasks is not
a desktop substitute it's a separate entertainment device, that will need
budgeting in addition to the computer.
And I'm not saying they won't find some place in the computing landscape, just
that a lot of this is hype fuelled by new entrants that desperately need some
VC funding. They have a vested interest in papering over the costs of
rewriting from scratch existing software catalogues, and obscuring the fact
that to be successful, a new platform must find a way to run most of this
software legacy (and doing so morph into something very close to the thing
it's supposed to deprecate).
--
Nicolas Mailhot
9:59 p.m.
Przemek Klosowski wrote:
The number of desktops has been flat for last 7 years.
So first of all, as you pointed out yourself, this is not "the number of
desktop", but the number of NEW desktops shipped.
The numbers have been "flat" in that the growth in shipments has slowed
down. But they're still growing! This confirms that computers are just not
going away any time soon. Even after all these years, there's still
increasing demand for computers, the market is not saturated yet.
As for why there are (assuming the projections they made for 2011 and 2012
are actually accurate – we need more recent data!) more smartphones being
sold than computers, there are several very plausible explanations for that:
* A computer is often a per-household device. A cellphone is per person, or
even multiple devices per person (e.g. multiple phones with different
contracts, or a phone and a tablet, etc.). So the total number is
necessarily going to be larger without there being more users.
* The mobile devices are in their fastest technological growth phase right
now, so they're simply replaced more often than computers, which translates
into more shipments. There are also other incentives for frequent
replacement, such as contract+smartphone bundle offers.
* There are many people who don't have a smartphone yet, whereas the market
for computers is already significantly saturated. That doesn't imply that
the people who are now obtaining a smartphone are discarding their computer.
Overall, the graphic shows a very selective set of statistics to make a
specific point (the same you're trying to make) and it's not clear at all
that it's making the big picture. (For example, their "devices in use"
timeline gives data for computers in 1993 and 2008, but their 2020
projection is only given for mobile devices and not for computers. Plus, if
the projection is made only based on the current trend for shipments,
ignoring both market saturation and decommissioned devices, it's very
unlikely to be accurate.)
And another important factor to consider is that not all those mobile
devices are suitable to run Fedora on, either due to inherent hardware
limitations or due to artificial digital restrictions (DRM).
Kevin Kofler
9:34 p.m.
On Thu, 2012-03-22 at 02:38 +0100, Kevin Kofler wrote:
And finally, for our build speed issue, the practical consideration
will be
whether the parallelism will actually speed our builds up. Right now our
builds are either serial or have portions parallelized with "make -j", which
assumes a single multi-CPU computer (but the "multi-core" ARM setups
actually present themselves as a multi-computer cluster, which is not
supported by "make -j", not as a multi-CPU computer), so the parallelism
does little to the latency of an individual build (though of course it does
help the overall throughput).
Actually, there's both: ARM scales to multiple cores per CPU (dual-core
and quad-core are common, and very high core counts are on the horizon),
and vendors are preparing many-CPU boxes (e.g., HP Redstone, with 288
quad core (+1 management core) systems in 4U).
-Chris
9:50 p.m.
Chris Tyler wrote:
On Thu, 2012-03-22 at 02:38 +0100, Kevin Kofler wrote:
> And finally, for our build speed issue, the practical consideration will
> be whether the parallelism will actually speed our builds up. Right now
> our builds are either serial or have portions parallelized with "make
> -j", which assumes a single multi-CPU computer (but the "multi-core"
ARM
> setups actually present themselves as a multi-computer cluster, which is
> not supported by "make -j", not as a multi-CPU computer), so the
> parallelism does little to the latency of an individual build (though of
> course it does help the overall throughput).
Actually, there's both: ARM scales to multiple cores per CPU (dual-core
and quad-core are common, and very high core counts are on the horizon),
and vendors are preparing many-CPU boxes (e.g., HP Redstone, with 288
quad core (+1 management core) systems in 4U).
But there are x86 CPUs with more than 4 cores, and multi-CPU SMP systems
which still present themselves as one (multi-CPU/core) computer. IIRC, our
x86 Koji builders have 16 cores per machine (might be even more by now, not
sure).
Kevin Kofler
10:05 p.m.
On 03/21/2012 07:50 PM, Kevin Kofler wrote:
But there are x86 CPUs with more than 4 cores, and multi-CPU SMP
systems
which still present themselves as one (multi-CPU/core) computer. IIRC, our
x86 Koji builders have 16 cores per machine (might be even more by now, not
sure).
Hypothetically speaking, if presented with an ARM system that builds
packages, on average, 3x faster than x86, will you advocate that x86 be
dropped to secondary and ARM be PA exclusively? Sure it's hypothetical,
but if that one variable changes, how does your position change?
--
Brendan Conoboy / Red Hat, Inc. / blc(a)redhat.com
10:23 p.m.
Brendan Conoboy wrote:
Hypothetically speaking, if presented with an ARM system that builds
packages, on average, 3x faster than x86, will you advocate that x86 be
dropped to secondary and ARM be PA exclusively?
Not if most computers (which to me means desktops, notebooks, maybe
netbooks, but most definitely not smartphones) are still x86.
We didn't make Cray or S/390 our primary architecture either, in the days
where the fastest supercomputers weren't x86 clusters yet. ;-)
If we really do get to a point where x86 is dead and everything is ARM (and
hopefully by then we'll also have ARM builders at least as fast as the x86
ones!), that will be the point where I will indeed advocate that x86 be
dropped to secondary and ARM be the exclusive primary arch (even though it'd
hurt my personal usage because I'm not the type who replaces his computer
every year). But right now we're very far from that.
Sure it's hypothetical, but if that one variable changes, how
does your
position change?
Well, of course, in that case, ARM being added as an additional primary
architecture would be at least acceptable. (It doesn't affect the question
of whether it'd be USEFUL though. See also the previous paragraphs.)
Kevin Kofler
5:56 a.m.
On Thu, Mar 22, 2012 at 3:23 AM, Kevin Kofler <kevin.kofler(a)chello.at> wrote:
Brendan Conoboy wrote:
> Hypothetically speaking, if presented with an ARM system that builds
> packages, on average, 3x faster than x86, will you advocate that x86 be
> dropped to secondary and ARM be PA exclusively?
Not if most computers (which to me means desktops, notebooks, maybe
netbooks, but most definitely not smartphones) are still x86.
We didn't make Cray or S/390 our primary architecture either, in the days
where the fastest supercomputers weren't x86 clusters yet. ;-)
No, but then speed of building isn't the only criteria of becoming a
primary arch. Ultimately we're asking FESCo to define the criteria so
we can assess whether we meet them and wish to progress to a primary
arch. We're (being ARM SIG, FESCo and pretty much everyone else) well
and truly aware the only thing you care about is build speed, and I
can understand that, I would care too if I had to build QT on a
regular basis.
If we really do get to a point where x86 is dead and everything is
ARM (and
hopefully by then we'll also have ARM builders at least as fast as the x86
ones!), that will be the point where I will indeed advocate that x86 be
dropped to secondary and ARM be the exclusive primary arch (even though it'd
hurt my personal usage because I'm not the type who replaces his computer
every year). But right now we're very far from that.
But it's not just about computers, I'm very surprised that being the
KDE advocate you are that you don't want to run your hard work on the
KDE based Spark/Vivaldi tablet.
> Sure it's hypothetical, but if that one variable changes, how
does your
> position change?
Well, of course, in that case, ARM being added as an additional primary
architecture would be at least acceptable. (It doesn't affect the question
of whether it'd be USEFUL though. See also the previous paragraphs.)
We already know that it's going to be useful, that's ultimately why
we're requesting it. Ultimately whether it is useful to you
particularly is a moot point as you are not the Fedora project as a
whole and hence the whole Fedora project doesn't revolve around you.
ARM's possible promotion to primary arch isn't about you, or even the
ARM SIG, it's a question of whether it's useful to the Fedora project
as a whole. I personally believe it is, as do numerous other people
people, groups, and other organisations, hence the reason a number of
us have put in a considerable amount of work to make it usable. The
same could be said about the KDE project within Fedora, you find it
useful, I've never used it and hence it is useless to me but that
doesn't mean I try and have it removed from the project because I am
just one person and not the project and there are a number of people
that have put a considerable amount of time into the KDE sub project.
I don't really see the ARM request to be any different. I could the
same argument about KDE in terms of the number of desktops that you
are using about ARM and the number of architectures.
Peter
10:03 p.m.
Peter Robinson wrote:
But it's not just about computers, I'm very surprised that
being the
KDE advocate you are that you don't want to run your hard work on the
KDE based Spark/Vivaldi tablet.
I'm not saying devices like the Vivaldi shouldn't be a target. I'm saying
they shouldn't be a PRIMARY target. Those targets is what secondary
architectures are for.
I don't really see the ARM request to be any different. I could
the
same argument about KDE in terms of the number of desktops that you
are using about ARM and the number of architectures.
LOL! KDE Plasma Desktop is THE MOST POPULAR desktop environment for
GNU/Linux.
http://www.linuxquestions.org/questions/2011-linuxquestions-org-members-c...
Fedora's current default (GNOME 3) is only number 3 (after KDE Plasma and
Xfce).
Kevin Kofler
12:21 p.m.
On 3/22/12 8:03 PM, Kevin Kofler wrote:
http://www.linuxquestions.org/questions/2011-linuxquestions-org-members-c...
Fedora's current default (GNOME 3) is only number 3 (after KDE Plasma and
Xfce).
Speaking of "a very selective set of statistics to make a
specific point (the same you're trying to make)"
--
Help me fight child abuse: http://tinyurl.com/jlkcourage
- jlk
5:44 a.m.
On Thu, Mar 22, 2012 at 2:50 AM, Kevin Kofler <kevin.kofler(a)chello.at> wrote:
Chris Tyler wrote:
> On Thu, 2012-03-22 at 02:38 +0100, Kevin Kofler wrote:
>> And finally, for our build speed issue, the practical consideration will
>> be whether the parallelism will actually speed our builds up. Right now
>> our builds are either serial or have portions parallelized with "make
>> -j", which assumes a single multi-CPU computer (but the
"multi-core" ARM
>> setups actually present themselves as a multi-computer cluster, which is
>> not supported by "make -j", not as a multi-CPU computer), so the
>> parallelism does little to the latency of an individual build (though of
>> course it does help the overall throughput).
>
> Actually, there's both: ARM scales to multiple cores per CPU (dual-core
> and quad-core are common, and very high core counts are on the horizon),
> and vendors are preparing many-CPU boxes (e.g., HP Redstone, with 288
> quad core (+1 management core) systems in 4U).
But there are x86 CPUs with more than 4 cores, and multi-CPU SMP systems
which still present themselves as one (multi-CPU/core) computer. IIRC, our
x86 Koji builders have 16 cores per machine (might be even more by now, not
sure).
But as you said yourself in an earlier thread a lot of compilation
isn't massively parallel so massive amount of cores for building isn't
necessarily as much a win as pure GHz. On that front the current A15
gen which is arriving now easily does the 2.5 - 3 ghz that the intel
platforms do (yes, I know they go to 3.6 but they're not regularly
used primarily due to heat) and most of the recent wins on Intel
architecture has been for media related things through various SSE
versions and other offload functions for things like crypto all of
which aren't massively used in standard compilation and all of which
have similar functionality on ARM platforms.
Peter
10:07 p.m.
Peter Robinson wrote:
But as you said yourself in an earlier thread a lot of compilation
isn't massively parallel so massive amount of cores for building isn't
necessarily as much a win as pure GHz. On that front the current A15
gen which is arriving now easily does the 2.5 - 3 ghz that the intel
platforms do (yes, I know they go to 3.6 but they're not regularly
used primarily due to heat) and most of the recent wins on Intel
architecture has been for media related things through various SSE
versions and other offload functions for things like crypto all of
which aren't massively used in standard compilation and all of which
have similar functionality on ARM platforms.
Speed is not GHz alone, but:
clock frequency (GHz)
/ cycles per instruction (a)
/ instructions needed to do the job (b)
ARM being a RISC architecture, it does great on (a), but not so great on
(b), and without knowing the exact factors, comparing GHz to GHz is
comparing apples to oranges.
Kevin Kofler
4:02 a.m.
On 03/22/2012 01:38 AM, Kevin Kofler wrote:
(but the "multi-core" ARM setups actually present
themselves as a
multi-computer cluster, which is not supported by "make -j", not as
a multi-CPU computer)
FWIW, I'm pretty sure this is not the case for the ARM computers
on the way now: they are multi-core multi-threaded.
Andrew.
6:26 a.m.
On Thu, Mar 22, 2012 at 9:02 AM, Andrew Haley <aph(a)redhat.com> wrote:
On 03/22/2012 01:38 AM, Kevin Kofler wrote:
> (but the "multi-core" ARM setups actually present themselves as a
> multi-computer cluster, which is not supported by "make -j", not as
> a multi-CPU computer)
FWIW, I'm pretty sure this is not the case for the ARM computers
on the way now: they are multi-core multi-threaded.
That is correct, I presume he's referring to the big.LITTLE
architecture which runs 8 cores, 4 low power low speed, 4 high power
high speed. At the moment for the initial implementation they are
suspending / resuming to switch between the pair but in the future
they plan to be able to run all 8 at once.
Peter
10:09 p.m.
Peter Robinson wrote:
That is correct, I presume he's referring to the big.LITTLE
architecture which runs 8 cores, 4 low power low speed, 4 high power
high speed. At the moment for the initial implementation they are
suspending / resuming to switch between the pair but in the future
they plan to be able to run all 8 at once.
I was actually referring to the "288-core" clusters which were mentioned at
several points in the thread, always with the caveat that you can't just use
"make -j 288" on them.
Kevin Kofler
7:18 p.m.
DJ Delorie wrote:
> always with the caveat that you can't just use "make -j
288" on them.
Why not? Multi-CPU machines is very old technology.
Ask the people who designed those machines.
(My guess: memory and bus bandwidth. There's a limit to how many cores you
can put on a shared-memory, shared-devices machine.)
Kevin Kofler
6:27 p.m.
On 03/23/2012 08:18 PM, Kevin Kofler wrote:
DJ Delorie wrote:
>> always with the caveat that you can't just use "make -j 288" on
them.
>
> Why not? Multi-CPU machines is very old technology.
Ask the people who designed those machines.
(My guess: memory and bus bandwidth. There's a limit to how many cores you
can put on a shared-memory, shared-devices machine.)
This is true. In the case of Cortex-A9 there are limits to how many
fully coherent cores exist within a given CPU "cluster" (on-chip). There
are also limits to coherency domains that generally mean you can't do
multi-socket coherency on practical 32-bit implementations. In the case
of 64-bit, one of the vendors at least has publicly announced an
intention to support fully coherent multi-socket domains. But in the
interim, we're going to have typically 4 core systems, and many of them.
Jon.
1:10 p.m.
On 3/20/12 9:30 AM, Jon Masters wrote:
Hi again,
I want to thank you, and everyone else in FESCo for talking with us
yesterday, and for looking over the proposal. Bear in mind, it's a work
in progress. We intend to have broader conversations over the coming
months and F18 is an optimistic goal. Nonetheless, I feel it is
achievable (we've done many more disruptive things!) but we have also
many points along the way at which we can back out, and remain SA.
To address a few of these points...at least, I'll try :) First, just to
repeat, we took the proposal to FESCo yesterday in the spirit of "early
and often", not in the spirit of "final deliverable". Therefore, while
it is true we've not yet reached out to everyone for input, that is
because it is still a work in progress for us. We'll iterate based on
feedback, and based upon yesterday and reaching out to other groups.
On 03/20/2012 11:52 AM, Peter Jones wrote:
> 1) mechanisms need to be in place to get package maintainers access to fix
> arm-specific bugs in their packages
So we have a tracker bug at the moment. Is that sufficient? If so, we
obviously should make sure that it is included in the proposal docs that
we have this in place and are using it.
A tracker bug is certainly not sufficient. It would be for a SA, but
not PA. Typically our users have a PA at their disposal, or failing
that have ready access to a shared PA provided by the Fedora Project
that they can log into and do their testing.
Without ARM systems available for all the releases our maintainers have
to support this is a non-starter. I will also note that having to
resort to using a remote system because the arch isn't generally locally
at a maintainer's disposal /is/ going to introduce a delay in getting
bugs resolved and builds out the door. If the arch was ubiquitous in a
way that lent itself to easy debugging and use that'd be a different
matter, but I just don't see it as being there right now.
> 2) excludearch is not an option. This is fundamentally contrary to being
> a primary arch. In fact this is one of the defining characteristics of
> a secondary arch.
Let's think about this some. ARM (32-bit) doesn't do Intel-style
microcode, MCE, or many other things that x86 does. I don't think that
means we should build packages that are x86-specific for ARM systems. We
generally believe that we're starting from a point of good momentum, but
there are some packages that won't ever be appropriate for ARM, and
there are others where the FTBFS has been longstanding, or there are
other (IMO valid) reasons why it might initially be Exclude. That
doesn't mean that there would be many such cases. Nonetheless, I think
it would be unreasonable to set the entry bar so high that there can be
no things left to fix. That basically retains the x86 monopoly.
Perhaps Peter can clarify or soften this requirement a bit. EXCLUDEARCH
as a default action when a build fails on ARM is certainly not an
option. What would help your situation is generating a few lists of
packages. One list would be packages that you feel just don't make
sense on ARM. Another list would be the FTBFS you mention. These lists
can be debated and decided upon /before/ the migration to PA and the
ExcludeArches can be in place before the switch is pulled.
Once the switch is pulled, that's when excludearch is unacceptable
without FESCo or such involvement, just like it is with the other
primary arches. That's really a price of entry.
> 3) arm must be integrated to the formal release criteria
Agreed. We'll need to figure that out.
> 4) when milestones occur, arm needs to be just as testible as other
> primary architectures
So we have a new hire (hi Paul) who is looking at autoqa, and we're
going to pull together as much as we can here. It would help me to know
(and we're reaching out to QE separately - per my other mail) what you
would consider "testable" to mean, in terms of what you'd want to see.
I think what is meant here is that we have to be able to get the arm
version of the rpms installed onto an appropriate host and be able to
easily run the programs to ensure that things are working as expected,
more than just "It built, SHIP IT".
Take a look at the release criteria we have currently have in place for
alpha/beta/final. ARM will need to follow it or have something
extremely similar. Granted the release criteria mostly involves the
installation process, but it does include installs from live media.
Installs /to/ a SD device and then booting said install to validate it
could fit in there.
--
Jesse Keating
Fedora -- Freedom² is a feature!
7:12 a.m.
On Tue, Mar 20, 2012 at 6:10 PM, Jesse Keating <jkeating(a)redhat.com> wrote:
On 3/20/12 9:30 AM, Jon Masters wrote:
>
> Hi again,
>
> I want to thank you, and everyone else in FESCo for talking with us
> yesterday, and for looking over the proposal. Bear in mind, it's a work
> in progress. We intend to have broader conversations over the coming
> months and F18 is an optimistic goal. Nonetheless, I feel it is
> achievable (we've done many more disruptive things!) but we have also
> many points along the way at which we can back out, and remain SA.
>
> To address a few of these points...at least, I'll try :) First, just to
> repeat, we took the proposal to FESCo yesterday in the spirit of "early
> and often", not in the spirit of "final deliverable". Therefore,
while
> it is true we've not yet reached out to everyone for input, that is
> because it is still a work in progress for us. We'll iterate based on
> feedback, and based upon yesterday and reaching out to other groups.
>
> On 03/20/2012 11:52 AM, Peter Jones wrote:
>
>> 1) mechanisms need to be in place to get package maintainers access to
>> fix
>> arm-specific bugs in their packages
>
>
> So we have a tracker bug at the moment. Is that sufficient? If so, we
> obviously should make sure that it is included in the proposal docs that
> we have this in place and are using it.
A tracker bug is certainly not sufficient. It would be for a SA, but not
PA. Typically our users have a PA at their disposal, or failing that have
ready access to a shared PA provided by the Fedora Project that they can log
into and do their testing.
How was this handled in the case of PPC? My understanding is that due
to legal reasons the Fedora Project never officially provided access
to PPC machines. There were a number of machines that users could get
access to that were provided by individuals but these were never
officially provided by the Fedora project.
Without ARM systems available for all the releases our maintainers
have to
support this is a non-starter. I will also note that having to resort to
using a remote system because the arch isn't generally locally at a
maintainer's disposal /is/ going to introduce a delay in getting bugs
resolved and builds out the door. If the arch was ubiquitous in a way that
lent itself to easy debugging and use that'd be a different matter, but I
just don't see it as being there right now.
There's a number of cheap hardware becoming available such as the
Raspberry Pi as well as development boards that are available for
either purchase or people can apply to be part of a developer program
to get either discount or free hardware. How was this supported with
PPC? The PPC hardware was a lot more expensive (either Apple devices
or IBM) than the readily available ARM devices. We can also put a
means escalation in place too for those that don't want to purchase or
can't get ready access to HW for testing.
>> 2) excludearch is not an option. This is fundamentally
contrary to being
>> a primary arch. In fact this is one of the defining characteristics
>> of
>> a secondary arch.
>
>
> Let's think about this some. ARM (32-bit) doesn't do Intel-style
> microcode, MCE, or many other things that x86 does. I don't think that
> means we should build packages that are x86-specific for ARM systems. We
> generally believe that we're starting from a point of good momentum, but
> there are some packages that won't ever be appropriate for ARM, and
> there are others where the FTBFS has been longstanding, or there are
> other (IMO valid) reasons why it might initially be Exclude. That
> doesn't mean that there would be many such cases. Nonetheless, I think
> it would be unreasonable to set the entry bar so high that there can be
> no things left to fix. That basically retains the x86 monopoly.
Perhaps Peter can clarify or soften this requirement a bit. EXCLUDEARCH as
a default action when a build fails on ARM is certainly not an option. What
would help your situation is generating a few lists of packages. One list
would be packages that you feel just don't make sense on ARM. Another list
would be the FTBFS you mention. These lists can be debated and decided upon
/before/ the migration to PA and the ExcludeArches can be in place before
the switch is pulled.
There's a couple of different categories here.
1) x86 only hardware. There's things like dmidecode, cpuid, various
ACPI, numa, EFI and other HW specific things like intel GPU drivers
where it just doesn't make sense to build on ARM, just like it didn't
make sense to build the various PPC utils etc on x86. In some cases it
might be a short term exclusion as it's expected that the support will
come to ARM, EFI is the classic case here. Others like intel GPUs
never will.
2) packages that have x86 dependent code. spice comes into this
category and I've discovered a few others. This would need work from
someone, either the Fedora maintainer or upstream.
3) Packages that aren't supported with ARM upstream. In most cases
they're fairly old releases. Most of the ones in this category had
their last releases back in the early 2000s. There's no reason they
can't be built but they would need some attention, I don't see an
issue here as in most of these cases Fedora is already carrying a
series of patches for things like compiling on gcc 4.x anyway, it's
just a matter of time and most of these we're fixing as we go.
Ultimately as the person that has done 98% of the builds and lead the
building of rawhide the vast majority of the packages where we've
added ExcludeArch are where they are x86 or PPC only for a reason, in
fact in a lot of cases I've removed excludes (icedtea-web and a number
of other packages) to ensure we run on ARM. Where it's FTBFS on ARM
there's been bug reports and dialog with maintainers to get the issues
fixed. Most maintainers have actively assisted with this, some have
stated they don't care, in those cases we generally go and fix the
issues ourselves. In quite a few of the cases with build issues it's
actually people doing weird shit in spec files that cause the problem.
Once the switch is pulled, that's when excludearch is
unacceptable without
FESCo or such involvement, just like it is with the other primary arches.
That's really a price of entry.
The ARM SIG has never seen excludearch as a fix to a non HW issue so
we have no problems with that. It some what amuses me actually that
there seems to be an expectation that we've been "fixing" things by
using excludearch. This is not, and never has been, the case. This is
a price we've been well and truly aware of from the start and it's
something that I as the lead pushing the builds have never seen
excludearch as a solution.
>> 3) arm must be integrated to the formal release criteria
>
>
> Agreed. We'll need to figure that out.
>
>> 4) when milestones occur, arm needs to be just as testible as other
>> primary architectures
>
>
> So we have a new hire (hi Paul) who is looking at autoqa, and we're
> going to pull together as much as we can here. It would help me to know
> (and we're reaching out to QE separately - per my other mail) what you
> would consider "testable" to mean, in terms of what you'd want to see.
I think what is meant here is that we have to be able to get the arm version
of the rpms installed onto an appropriate host and be able to easily run the
programs to ensure that things are working as expected, more than just "It
built, SHIP IT".
Absolutely! QA have already started to put together a proposal, in
fact around FUDCon NA timeframe and long before this proposal for
adding it as a primary arch. It's my opinion that building the
packages is the small and easy part of the process.
https://fedorahosted.org/fedora-qa/ticket/277
Take a look at the release criteria we have currently have in place
for
alpha/beta/final. ARM will need to follow it or have something extremely
similar. Granted the release criteria mostly involves the installation
process, but it does include installs from live media. Installs /to/ a SD
device and then booting said install to validate it could fit in there.
Exactly and it's what we wish to do. Ultimately there is a lot of
work to be done on installers and install process. We were planning on
breaking this down into essentially 3 phases:
1) livecd-creator style command line tool to create a SD card or
similar from a livecd style image, setup the bootlaoder so you can
plug a card into a device and have it boot to the desired interface.
2) liveusb-creator style GUI to make the above much easier
3) Full anaconda support, we started talking with the anaconda team
about this as far back as FUDCon Milan. They have a lot of awesome
ideas surrounding the means of supporting installing these devices but
ultimately like everything else it needs to get done. Hence the
reasons we were looking at doing it in a phased approach.
Peter
7:33 a.m.
On Wed, Mar 21, 2012 at 12:12:25PM +0000, Peter Robinson wrote:
How was this handled in the case of PPC? My understanding is that
due
to legal reasons the Fedora Project never officially provided access
to PPC machines. There were a number of machines that users could get
access to that were provided by individuals but these were never
officially provided by the Fedora project.
It was very unsatisfactory. I had an account on David Woodhouse's
PPC64 machine -- I think it was a PS3 -- but there was no root access
so I couldn't install packages or test anything that needed root.
There's a number of cheap hardware becoming available such as
the
Raspberry Pi as well as development boards that are available for
either purchase or people can apply to be part of a developer program
to get either discount or free hardware. How was this supported with
PPC? The PPC hardware was a lot more expensive (either Apple devices
or IBM) than the readily available ARM devices.
PPC hardware was expensive. Even the Playstation 3 was an order of
magnitude more expensive than the upcoming ARM hardware. Of course,
as of *right now*, ARM hardware is also expensive (£250 for a minimal
server). We are still waiting to see if Raspberry Pi really becomes
mass-produced and available to all for cheap as chips.
Rich.
--
Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones
Read my programming blog: http://rwmj.wordpress.com
Fedora now supports 80 OCaml packages (the OPEN alternative to F#)
http://cocan.org/getting_started_with_ocaml_on_red_hat_and_fedora
8:07 a.m.
On Wed, Mar 21, 2012 at 8:33 AM, Richard W.M. Jones <rjones(a)redhat.com> wrote:
On Wed, Mar 21, 2012 at 12:12:25PM +0000, Peter Robinson wrote:
> How was this handled in the case of PPC? My understanding is that due
> to legal reasons the Fedora Project never officially provided access
> to PPC machines. There were a number of machines that users could get
> access to that were provided by individuals but these were never
> officially provided by the Fedora project.
It was very unsatisfactory. I had an account on David Woodhouse's
PPC64 machine -- I think it was a PS3 -- but there was no root access
so I couldn't install packages or test anything that needed root.
David's machines were usually Apple G5s. If he gave you access to a PS3,
he must have disliked you at that particular moment. Those were some of
the worst machines I have ever worked with because of their hardware
limitations.
josh
8:04 a.m.
On Wed, Mar 21, 2012 at 8:12 AM, Peter Robinson <pbrobinson(a)gmail.com> wrote:
>>> 1) mechanisms need to be in place to get package
maintainers access to
>>> fix
>>> arm-specific bugs in their packages
>>
>>
>> So we have a tracker bug at the moment. Is that sufficient? If so, we
>> obviously should make sure that it is included in the proposal docs that
>> we have this in place and are using it.
>
>
> A tracker bug is certainly not sufficient. It would be for a SA, but not
> PA. Typically our users have a PA at their disposal, or failing that have
> ready access to a shared PA provided by the Fedora Project that they can log
> into and do their testing.
How was this handled in the case of PPC? My understanding is that due
to legal reasons the Fedora Project never officially provided access
to PPC machines. There were a number of machines that users could get
access to that were provided by individuals but these were never
officially provided by the Fedora project.
That is correct.
> Without ARM systems available for all the releases our
maintainers have to
> support this is a non-starter. I will also note that having to resort to
> using a remote system because the arch isn't generally locally at a
> maintainer's disposal /is/ going to introduce a delay in getting bugs
> resolved and builds out the door. If the arch was ubiquitous in a way that
> lent itself to easy debugging and use that'd be a different matter, but I
> just don't see it as being there right now.
There's a number of cheap hardware becoming available such as the
Raspberry Pi as well as development boards that are available for
either purchase or people can apply to be part of a developer program
to get either discount or free hardware. How was this supported with
PPC? The PPC hardware was a lot more expensive (either Apple devices
or IBM) than the readily available ARM devices. We can also put a
means escalation in place too for those that don't want to purchase or
can't get ready access to HW for testing.
I think you're really asking the wrong question, or maybe taking the wrong
approach. There are a number of reasons PPC was _demoted_ to a secondary
arch, and this is one of them. Asking how it was done while PPC was a PA
is just spinning your wheels. It doesn't matter.
>>> 2) excludearch is not an option. This is fundamentally
contrary to being
>>> a primary arch. In fact this is one of the defining characteristics
>>> of
>>> a secondary arch.
>>
>>
>> Let's think about this some. ARM (32-bit) doesn't do Intel-style
>> microcode, MCE, or many other things that x86 does. I don't think that
>> means we should build packages that are x86-specific for ARM systems. We
>> generally believe that we're starting from a point of good momentum, but
>> there are some packages that won't ever be appropriate for ARM, and
>> there are others where the FTBFS has been longstanding, or there are
>> other (IMO valid) reasons why it might initially be Exclude. That
>> doesn't mean that there would be many such cases. Nonetheless, I think
>> it would be unreasonable to set the entry bar so high that there can be
>> no things left to fix. That basically retains the x86 monopoly.
>
>
> Perhaps Peter can clarify or soften this requirement a bit. EXCLUDEARCH as
> a default action when a build fails on ARM is certainly not an option. What
> would help your situation is generating a few lists of packages. One list
> would be packages that you feel just don't make sense on ARM. Another list
> would be the FTBFS you mention. These lists can be debated and decided upon
> /before/ the migration to PA and the ExcludeArches can be in place before
> the switch is pulled.
There's a couple of different categories here.
1) x86 only hardware. There's things like dmidecode, cpuid, various
ACPI, numa, EFI and other HW specific things like intel GPU drivers
where it just doesn't make sense to build on ARM, just like it didn't
make sense to build the various PPC utils etc on x86. In some cases it
might be a short term exclusion as it's expected that the support will
come to ARM, EFI is the classic case here. Others like intel GPUs
never will.
Yes. All good.
2) packages that have x86 dependent code. spice comes into this
category and I've discovered a few others. This would need work from
someone, either the Fedora maintainer or upstream.
Er... I think you forgot "or the Fedora ARM team". Seriously, if you are
counting on getting the Fedora package maintainer to fix something like
that, you are going to be disappointed. You cannot force them to fix it
and ExcludeArch is often the resolution until the arch team comes along
and fixes it.
Ultimately as the person that has done 98% of the builds and lead
the
building of rawhide the vast majority of the packages where we've
added ExcludeArch are where they are x86 or PPC only for a reason, in
fact in a lot of cases I've removed excludes (icedtea-web and a number
of other packages) to ensure we run on ARM. Where it's FTBFS on ARM
there's been bug reports and dialog with maintainers to get the issues
fixed. Most maintainers have actively assisted with this, some have
stated they don't care, in those cases we generally go and fix the
issues ourselves. In quite a few of the cases with build issues it's
actually people doing weird shit in spec files that cause the problem.
This is exactly what I meant above. You've done great work, but what you
describe is simply going to continue whether ARM is primary or secondary.
I just don't want people to think the effort you've put in thus far is
somehow going to magically decrease if ARM is promoted.
josh
8:56 a.m.
On Wed, Mar 21, 2012 at 1:04 PM, Josh Boyer <jwboyer(a)gmail.com> wrote:
On Wed, Mar 21, 2012 at 8:12 AM, Peter Robinson
<pbrobinson(a)gmail.com> wrote:
>>>> 1) mechanisms need to be in place to get package maintainers access to
>>>> fix
>>>> arm-specific bugs in their packages
>>>
>>>
>>> So we have a tracker bug at the moment. Is that sufficient? If so, we
>>> obviously should make sure that it is included in the proposal docs that
>>> we have this in place and are using it.
>>
>>
>> A tracker bug is certainly not sufficient. It would be for a SA, but not
>> PA. Typically our users have a PA at their disposal, or failing that have
>> ready access to a shared PA provided by the Fedora Project that they can log
>> into and do their testing.
>
> How was this handled in the case of PPC? My understanding is that due
> to legal reasons the Fedora Project never officially provided access
> to PPC machines. There were a number of machines that users could get
> access to that were provided by individuals but these were never
> officially provided by the Fedora project.
That is correct.
>> Without ARM systems available for all the releases our maintainers have to
>> support this is a non-starter. I will also note that having to resort to
>> using a remote system because the arch isn't generally locally at a
>> maintainer's disposal /is/ going to introduce a delay in getting bugs
>> resolved and builds out the door. If the arch was ubiquitous in a way that
>> lent itself to easy debugging and use that'd be a different matter, but I
>> just don't see it as being there right now.
>
> There's a number of cheap hardware becoming available such as the
> Raspberry Pi as well as development boards that are available for
> either purchase or people can apply to be part of a developer program
> to get either discount or free hardware. How was this supported with
> PPC? The PPC hardware was a lot more expensive (either Apple devices
> or IBM) than the readily available ARM devices. We can also put a
> means escalation in place too for those that don't want to purchase or
> can't get ready access to HW for testing.
I think you're really asking the wrong question, or maybe taking the wrong
approach. There are a number of reasons PPC was _demoted_ to a secondary
arch, and this is one of them. Asking how it was done while PPC was a PA
is just spinning your wheels. It doesn't matter.
No, I was using it as a point and it's certainly not the approach I'm taking.
>>>> 2) excludearch is not an option. This is
fundamentally contrary to being
>>>> a primary arch. In fact this is one of the defining characteristics
>>>> of
>>>> a secondary arch.
>>>
>>>
>>> Let's think about this some. ARM (32-bit) doesn't do Intel-style
>>> microcode, MCE, or many other things that x86 does. I don't think that
>>> means we should build packages that are x86-specific for ARM systems. We
>>> generally believe that we're starting from a point of good momentum, but
>>> there are some packages that won't ever be appropriate for ARM, and
>>> there are others where the FTBFS has been longstanding, or there are
>>> other (IMO valid) reasons why it might initially be Exclude. That
>>> doesn't mean that there would be many such cases. Nonetheless, I think
>>> it would be unreasonable to set the entry bar so high that there can be
>>> no things left to fix. That basically retains the x86 monopoly.
>>
>>
>> Perhaps Peter can clarify or soften this requirement a bit. EXCLUDEARCH as
>> a default action when a build fails on ARM is certainly not an option. What
>> would help your situation is generating a few lists of packages. One list
>> would be packages that you feel just don't make sense on ARM. Another list
>> would be the FTBFS you mention. These lists can be debated and decided upon
>> /before/ the migration to PA and the ExcludeArches can be in place before
>> the switch is pulled.
>
> There's a couple of different categories here.
>
> 1) x86 only hardware. There's things like dmidecode, cpuid, various
> ACPI, numa, EFI and other HW specific things like intel GPU drivers
> where it just doesn't make sense to build on ARM, just like it didn't
> make sense to build the various PPC utils etc on x86. In some cases it
> might be a short term exclusion as it's expected that the support will
> come to ARM, EFI is the classic case here. Others like intel GPUs
> never will.
Yes. All good.
> 2) packages that have x86 dependent code. spice comes into this
> category and I've discovered a few others. This would need work from
> someone, either the Fedora maintainer or upstream.
Er... I think you forgot "or the Fedora ARM team". Seriously, if you are
counting on getting the Fedora package maintainer to fix something like
that, you are going to be disappointed. You cannot force them to fix it
and ExcludeArch is often the resolution until the arch team comes along
and fixes it.
Nope, not forgotten, the "Fedora ARM team" component was a given, but
ultimately there has to be some form of involvement from both levels
of maintainers because otherwise everytime a patch doesn't rebase
they'll just comment it out and move on, I'm fully aware of the
requirements of the ARM team..... just look at my name though out all
build reports for this year to see that.
> Ultimately as the person that has done 98% of the builds and lead
the
> building of rawhide the vast majority of the packages where we've
> added ExcludeArch are where they are x86 or PPC only for a reason, in
> fact in a lot of cases I've removed excludes (icedtea-web and a number
> of other packages) to ensure we run on ARM. Where it's FTBFS on ARM
> there's been bug reports and dialog with maintainers to get the issues
> fixed. Most maintainers have actively assisted with this, some have
> stated they don't care, in those cases we generally go and fix the
> issues ourselves. In quite a few of the cases with build issues it's
> actually people doing weird shit in spec files that cause the problem.
This is exactly what I meant above. You've done great work, but what you
describe is simply going to continue whether ARM is primary or secondary.
I just don't want people to think the effort you've put in thus far is
somehow going to magically decrease if ARM is promoted.
Nope, we're not that naive but my point is that we're not just asking
for it to be promoted to Primary Arch because we'd like to pat ourself
on the back for all our efforts, we believe (and if you look at the
hype in the industry in general) that ARM is going to be a large part
of the market moving forward and we believe that ARM being well
supported in Fedora is represented in part of our core values of the
project. Ultimately it will mean a lot of lower cost hardware being
available for users all over the world and for them to be able to run
Fedora easily on those devices I believe would be an awesome thing.
And yes, while it's certainly possible for it to happen as a secondary
arch there's a whole lot of issues surrounding that like the
expectation that a few people fix every problem and there's a little
QA effort when people can be bothered and various developers will fix
things when they can be bothered and it ultimately makes people think
"no one in Fedora cares about ARM I'll just go an run some other
distro where they do care and it is supported".
I'm fully aware that Primary Arch isn't the perfect panacea and that
once we're there the ARM team can't go and sit of the beach and do
nothing but it does spread the load, automate a lot of things because
it's part of core infra and processes and it then allows the ARM team
to concentrate on fixing corner case packages, working with various
components of the project, optimising the way things are done for ARM,
working with upstreams for HW etc and generally making ARM even better
rather than constantly chasing our tail trying to keep up with basic
things as building packages, running infrastructure, composing the
repos, dealing with branching and tags and targets in koji and all
those other things. Those advantages of being a primary arch can't be
under valued.
Peter
8:49 p.m.
Peter Robinson wrote:
How was this handled in the case of PPC? My understanding is that
due
to legal reasons the Fedora Project never officially provided access
to PPC machines. There were a number of machines that users could get
access to that were provided by individuals but these were never
officially provided by the Fedora project.
Very few people actually used those machines anyway. We just used
ExcludeArch: ppc ppc64 when stuff didn't build, and I expect the exact same
thing to happen for ARM.
Kevin Kofler
6:31 p.m.
Peter Jones wrote:
In yesterday's FESCo meeting I told you I'd make a list of
specific issues
I have with the current proposal for ARM as a primary archictecture. There
are some places where I think the current proposal fails to deal with some
necessary aspects of becoming a primary architecture, and some places
where I don't think the approach is quite right.
How about: "support for the main hardware features on commonly-used hardware
is Free Software, and included in the upstream software (kernel, X.Org X11,
CUPS, SANE etc.) where appropriate"? Right now, this is clearly NOT the case
for OpenGL on ARM, so by promoting ARM, we'd promote proprietary (graphics)
driver use.
Kevin Kofler
7:24 p.m.
On Tue, Mar 20, 2012 at 7:31 PM, Kevin Kofler <kevin.kofler(a)chello.at> wrote:
Peter Jones wrote:
> In yesterday's FESCo meeting I told you I'd make a list of specific issues
> I have with the current proposal for ARM as a primary archictecture. There
> are some places where I think the current proposal fails to deal with some
> necessary aspects of becoming a primary architecture, and some places
> where I don't think the approach is quite right.
How about: "support for the main hardware features on commonly-used hardware
is Free Software, and included in the upstream software (kernel, X.Org X11,
CUPS, SANE etc.) where appropriate"? Right now, this is clearly NOT the case
for OpenGL on ARM, so by promoting ARM, we'd promote proprietary (graphics)
driver use.
I think that's going slightly too far. We certainly wouldn't suggest to our
users that they install a proprietary driver on any of the Fedora project
websites or wikis. It's probably more accurate to classify your concern as
ARM graphics being unsupported or at best crippled.
josh
7:26 a.m.
On Tue, Mar 20, 2012 at 11:31 PM, Kevin Kofler <kevin.kofler(a)chello.at> wrote:
Peter Jones wrote:
> In yesterday's FESCo meeting I told you I'd make a list of specific issues
> I have with the current proposal for ARM as a primary archictecture. There
> are some places where I think the current proposal fails to deal with some
> necessary aspects of becoming a primary architecture, and some places
> where I don't think the approach is quite right.
How about: "support for the main hardware features on commonly-used hardware
is Free Software, and included in the upstream software (kernel, X.Org X11,
CUPS, SANE etc.) where appropriate"? Right now, this is clearly NOT the case
for OpenGL on ARM, so by promoting ARM, we'd promote proprietary (graphics)
driver use.
No, we've never said that ever! But then there are a lot of desktops
that run just fine without OpenGL. 3D really wasn't in a great state
even in x86 until Fedora 15 with a lot of drivers only doing it
partially or not at all, even now there's only really 3 well supported
sets of HW that are well supported with 3D in Fedora... ie Intel,
AMD/ATI and nVidia and even those aren't perfect yet. I don't see how
full OpenGL support should be an argument because there's still really
on a subset of x86 hardware that currently supports it.
Peter
7:32 a.m.
On Wed, Mar 21, 2012 at 1:26 PM, Peter Robinson <pbrobinson(a)gmail.com> wrote:
On Tue, Mar 20, 2012 at 11:31 PM, Kevin Kofler
<kevin.kofler(a)chello.at> wrote:
> Peter Jones wrote:
>> In yesterday's FESCo meeting I told you I'd make a list of specific
issues
>> I have with the current proposal for ARM as a primary archictecture. There
>> are some places where I think the current proposal fails to deal with some
>> necessary aspects of becoming a primary architecture, and some places
>> where I don't think the approach is quite right.
>
> How about: "support for the main hardware features on commonly-used hardware
> is Free Software, and included in the upstream software (kernel, X.Org X11,
> CUPS, SANE etc.) where appropriate"? Right now, this is clearly NOT the case
> for OpenGL on ARM, so by promoting ARM, we'd promote proprietary (graphics)
> driver use.
No, we've never said that ever! But then there are a lot of desktops
that run just fine without OpenGL.
Even though I disagree with Kevin that we should block on "does not
have 3D drivers" .. OpenGL is imo
even more important on ARM (non server systems) then on x86.
A tablet or smartphone without hardware accelerated rendering is just
useless (slow, short battery life).
But this should get better over time as more general purpose
distributions try to run on such devices.
9:24 a.m.
On Wed, 2012-03-21 at 13:32 +0100, drago01 wrote:
Even though I disagree with Kevin that we should block on "does
not
have 3D drivers" .. OpenGL is imo
even more important on ARM (non server systems) then on x86.
A tablet or smartphone without hardware accelerated rendering is just
useless (slow, short battery life).
But this should get better over time as more general purpose
distributions try to run on such devices.
ITYM "as more people finally get around to reverse-engineering the
hardware". Honestly distributions have very little impact here. They
just increase demand.
The only thing that gets drivers written is writing the damn driver. If
you think this is an important thing to have, Mesa would love to have
your contribution.
- ajax
9:32 a.m.
On Wed, Mar 21, 2012 at 3:24 PM, Adam Jackson <ajax(a)redhat.com> wrote:
On Wed, 2012-03-21 at 13:32 +0100, drago01 wrote:
> Even though I disagree with Kevin that we should block on "does not
> have 3D drivers" .. OpenGL is imo
> even more important on ARM (non server systems) then on x86.
>
> A tablet or smartphone without hardware accelerated rendering is just
> useless (slow, short battery life).
> But this should get better over time as more general purpose
> distributions try to run on such devices.
ITYM "as more people finally get around to reverse-engineering the
hardware". Honestly distributions have very little impact here. They
just increase demand.
Which is what I meant by that. There is basically zero demand right now.
The only devices that ship currently pretty much all run android which
has drivers (and does not care about open vs. closed).
9:34 a.m.
On Wed, Mar 21, 2012 at 2:24 PM, Adam Jackson <ajax(a)redhat.com> wrote:
On Wed, 2012-03-21 at 13:32 +0100, drago01 wrote:
> Even though I disagree with Kevin that we should block on "does not
> have 3D drivers" .. OpenGL is imo
> even more important on ARM (non server systems) then on x86.
>
> A tablet or smartphone without hardware accelerated rendering is just
> useless (slow, short battery life).
> But this should get better over time as more general purpose
> distributions try to run on such devices.
ITYM "as more people finally get around to reverse-engineering the
hardware". Honestly distributions have very little impact here. They
just increase demand.
The only thing that gets drivers written is writing the damn driver. If
you think this is an important thing to have, Mesa would love to have
your contribution.
I'm hoping soon we can add the MALI chipset with the lima driver
effort [1] into this list, it's been reverse engineered and it's a
good target as it's the ARM developed GPU that is a check box option
for those that don't want to make their own so is relatively wide
spread. Marvell might even come to the party through it's involvement
with OLPC. A lot of the others I'm not sure of, I don't hold up much
hope for any derived from the SGX stuff as even with intel and the
gma* ones there's not been a lot of movement with an open source 3D
driver, but ultimately the company that owns the IP has no incentive
as they're selling their cores for iOS devices hand over fist. Since
the beginning of the year there has been at least some positive
movement in this regard, even if in some cases it's only an open KMS
kernel driver to do some form of 2D.
Peter
[1] http://limadriver.org/
9:23 a.m.
On Wed, 2012-03-21 at 12:26 +0000, Peter Robinson wrote:
No, we've never said that ever! But then there are a lot of
desktops
that run just fine without OpenGL. 3D really wasn't in a great state
even in x86 until Fedora 15 with a lot of drivers only doing it
partially or not at all, even now there's only really 3 well supported
sets of HW that are well supported with 3D in Fedora... ie Intel,
AMD/ATI and nVidia and even those aren't perfect yet. I don't see how
full OpenGL support should be an argument because there's still really
on a subset of x86 hardware that currently supports it.
Not to be overly picky, but "only three" is a bit misleading. When you
look at how the driver support actually breaks down in terms of
generational similarity, you get something more like:
- Intel gen2 (8xx)
- Intel gen3 (915, 945, G33, Atom)
- Intel gen4 (Core and Core 2)
- Intel gen5+ (Core i3 and up)
- Radeon R100-R200
- Radeon R300-R500
- Radeon R600-R700
- Radeon R800+
- NVIDIA pre-NV30
- NVIDIA NV30-NV40
- NVIDIA NV50
- NVIDIA NVC0+
Even if you're going by the more strict criteria of "good enough to run
gnome-shell" you only cut out four of those (should only be three, tbh).
And if we're going by _that_ metric, the list of other x86 hardware in
the world where we could have drivers but don't yet is, as far as I
know:
- VIA Chrome9
- Matrox P- and M-series
Which, in terms of market share, are sort of the two-dollar-bills of the
world.
So it's a little like saying "we only support x86 chips from Intel, AMD,
and VIA". Okay, yeah, maybe that's fair, but those are actually all
there is to care about.
- ajax
9:28 a.m.
On Wed, Mar 21, 2012 at 2:23 PM, Adam Jackson <ajax(a)redhat.com> wrote:
On Wed, 2012-03-21 at 12:26 +0000, Peter Robinson wrote:
> No, we've never said that ever! But then there are a lot of desktops
> that run just fine without OpenGL. 3D really wasn't in a great state
> even in x86 until Fedora 15 with a lot of drivers only doing it
> partially or not at all, even now there's only really 3 well supported
> sets of HW that are well supported with 3D in Fedora... ie Intel,
> AMD/ATI and nVidia and even those aren't perfect yet. I don't see how
> full OpenGL support should be an argument because there's still really
> on a subset of x86 hardware that currently supports it.
Not to be overly picky, but "only three" is a bit misleading. When you
look at how the driver support actually breaks down in terms of
generational similarity, you get something more like:
- Intel gen2 (8xx)
- Intel gen3 (915, 945, G33, Atom)
- Intel gen4 (Core and Core 2)
- Intel gen5+ (Core i3 and up)
- Radeon R100-R200
- Radeon R300-R500
- Radeon R600-R700
- Radeon R800+
- NVIDIA pre-NV30
- NVIDIA NV30-NV40
- NVIDIA NV50
- NVIDIA NVC0+
Even if you're going by the more strict criteria of "good enough to run
gnome-shell" you only cut out four of those (should only be three, tbh).
And if we're going by _that_ metric, the list of other x86 hardware in
the world where we could have drivers but don't yet is, as far as I
know:
- VIA Chrome9
- Matrox P- and M-series
Which, in terms of market share, are sort of the two-dollar-bills of the
world.
So it's a little like saying "we only support x86 chips from Intel, AMD,
and VIA". Okay, yeah, maybe that's fair, but those are actually all
there is to care about.
What about all the other xorg-x11-drv* video cards, admittedly they're
generally considered legacy but there are a lot that don't do 3D at
all there.
Peter
9:31 a.m.
On Wed, Mar 21, 2012 at 02:28:10PM +0000, Peter Robinson wrote:
What about all the other xorg-x11-drv* video cards, admittedly
they're
generally considered legacy but there are a lot that don't do 3D at
all there.
Of the hardware still produced, they're either things Adam listed as
unsupported, don't have 3D engines or they're powervr.
--
Matthew Garrett | mjg59(a)srcf.ucam.org
9:35 a.m.
On Wed, Mar 21, 2012 at 2:31 PM, Matthew Garrett <mjg59(a)srcf.ucam.org> wrote:
On Wed, Mar 21, 2012 at 02:28:10PM +0000, Peter Robinson wrote:
> What about all the other xorg-x11-drv* video cards, admittedly they're
> generally considered legacy but there are a lot that don't do 3D at
> all there.
Of the hardware still produced, they're either things Adam listed as
unsupported, don't have 3D engines or they're powervr.
That's my point, I don't believe that working 3D should be a blocker
to primary arch because like mainline it will likely come with both
time and demand.
Peter
9:38 a.m.
Peter Robinson (pbrobinson(a)gmail.com) said:
That's my point, I don't believe that working 3D should be a
blocker
to primary arch because like mainline it will likely come with both
time and demand.
Is llvmpipe not 'working'? (Admittedly, on low-power CPUs like ARM, it might
be more of a burden.)
Bill
9:40 a.m.
On Wed, Mar 21, 2012 at 3:38 PM, Bill Nottingham <notting(a)redhat.com> wrote:
Peter Robinson (pbrobinson(a)gmail.com) said:
> That's my point, I don't believe that working 3D should be a blocker
> to primary arch because like mainline it will likely come with both
> time and demand.
Is llvmpipe not 'working'? (Admittedly, on low-power CPUs like ARM, it might
be more of a burden.)
It is rather pointless on devices that really on low power footprint.
They need the GPU to work to be useful.
9:49 a.m.
On Wed, 2012-03-21 at 10:38 -0400, Bill Nottingham wrote:
Peter Robinson (pbrobinson(a)gmail.com) said:
> That's my point, I don't believe that working 3D should be a blocker
> to primary arch because like mainline it will likely come with both
> time and demand.
Is llvmpipe not 'working'? (Admittedly, on low-power CPUs like ARM, it might
be more of a burden.)
llvmpipe should work on arm - I've not tried - but I suspect it needs a
modest amount of surgery to perform adequately. Much of its performance
on x86 comes from swizzling the pixel layout around internally so it
nicely matches up with SSE2's register layout, which probably isn't
quite what arm gives you to work with.
Oh, yeah, and software floating point would be brutal. Nobody is
surprised.
The ARM GPUs are pretty simple though. The nice thing about not
pretending to implement full GL is you don't have to implement all the
garbage parts of GL. And you're really going to be much happier with an
RE'd driver than with llvmpipe. Like I say, mesa-dev@ is -> that way.
- ajax
10:26 a.m.
On Wed, Mar 21, 2012 at 2:49 PM, Adam Jackson <ajax(a)redhat.com> wrote:
On Wed, 2012-03-21 at 10:38 -0400, Bill Nottingham wrote:
> Peter Robinson (pbrobinson(a)gmail.com) said:
> > That's my point, I don't believe that working 3D should be a blocker
> > to primary arch because like mainline it will likely come with both
> > time and demand.
>
> Is llvmpipe not 'working'? (Admittedly, on low-power CPUs like ARM, it might
> be more of a burden.)
llvmpipe should work on arm - I've not tried - but I suspect it needs a
modest amount of surgery to perform adequately. Much of its performance
on x86 comes from swizzling the pixel layout around internally so it
nicely matches up with SSE2's register layout, which probably isn't
quite what arm gives you to work with.
I think it could be made to work but it would need optimisation for
NEON (one of ARM's equiv of SSE) but that wouldn't work on all devices
but it would certainly be a good start but obviously needs someone in
the know to implement it.
Peter
9:43 a.m.
On Wed, 2012-03-21 at 14:31 +0000, Matthew Garrett wrote:
On Wed, Mar 21, 2012 at 02:28:10PM +0000, Peter Robinson wrote:
> What about all the other xorg-x11-drv* video cards, admittedly they're
> generally considered legacy but there are a lot that don't do 3D at
> all there.
Of the hardware still produced, they're either things Adam listed as
unsupported, don't have 3D engines or they're powervr.
Oh, yeah, fair, I totally forgot to bitch about Poulsbo there. Insert
standard bitching about Poulsbo here.
Of hardware not currently in production - where, again, we're talking
about whether a 3D driver could usefully be written to enable
gnome-shell on the hardware - it's still a remarkably short list. Via
did some DX8 parts, XGI before they went out of business, possibly a few
SiS parts before they did the same.
I should emphasize that I don't think hardware 3D needs to be a blocker
for a primary arch either. My beef was just with the phrasing that
implied that "only 3" GPUs was somehow inadequate.
- ajax
10:24 a.m.
On Wed, Mar 21, 2012 at 2:43 PM, Adam Jackson <ajax(a)redhat.com> wrote:
On Wed, 2012-03-21 at 14:31 +0000, Matthew Garrett wrote:
> On Wed, Mar 21, 2012 at 02:28:10PM +0000, Peter Robinson wrote:
>
> > What about all the other xorg-x11-drv* video cards, admittedly they're
> > generally considered legacy but there are a lot that don't do 3D at
> > all there.
>
> Of the hardware still produced, they're either things Adam listed as
> unsupported, don't have 3D engines or they're powervr.
Oh, yeah, fair, I totally forgot to bitch about Poulsbo there. Insert
standard bitching about Poulsbo here.
Of hardware not currently in production - where, again, we're talking
about whether a 3D driver could usefully be written to enable
gnome-shell on the hardware - it's still a remarkably short list. Via
did some DX8 parts, XGI before they went out of business, possibly a few
SiS parts before they did the same.
Yea, I've even heard recent rumours of Via releasing their 3D specs
for an actual real open driver!
I should emphasize that I don't think hardware 3D needs to be a
blocker
for a primary arch either. My beef was just with the phrasing that
implied that "only 3" GPUs was somehow inadequate.
Sorry, by "only 3" I meant 3 core GPU platforms ie ATI / Intel / nVidia.
Peter
10:56 a.m.
On Wed, 2012-03-21 at 14:28 +0000, Peter Robinson wrote:
> So it's a little like saying "we only support x86 chips
from Intel, AMD,
> and VIA". Okay, yeah, maybe that's fair, but those are actually all
> there is to care about.
What about all the other xorg-x11-drv* video cards, admittedly they're
generally considered legacy but there are a lot that don't do 3D at
all there.
Their existence, at this point, is pretty much theoretical. :)
Years of data - Smolt, Smolt-type tools, Phoronix surveys, general
(non-Linux) industry surveys - agree very strongly that somewhere
between 95% and 99% of x86 systems (I'd pin it at the high end of that
range, myself) are using Intel, AMD, or NVIDIA graphics. Those really
are all it's honestly worth caring about on x86.
--
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Twitter: AdamW_Fedora | identi.ca: adamwfedora
http://www.happyassassin.net
9:52 a.m.
Peter Jones (pjones(a)redhat.com) said:
In yesterday's FESCo meeting I told you I'd make a list of
specific issues
I have with the current proposal for ARM as a primary archictecture. There
are some places where I think the current proposal fails to deal with some
necessary aspects of becoming a primary architecture, and some places where
I don't think the approach is quite right. So without further ado:
1) mechanisms need to be in place to get package maintainers access to fix
arm-specific bugs in their packages
2) excludearch is not an option. This is fundamentally contrary to being
a primary arch. In fact this is one of the defining characteristics of
a secondary arch.
3) arm must be integrated to the formal release criteria
4) when milestones occur, arm needs to be just as testible as other
primary architectures
5) installation methods must be in place. I'm not saying it has to be
using the same model as x86, but when we get to beta, if it can't be
installed, it can't meet similar release criteria to existing or prior
primary arches. Where possible, we should be using anaconda for
installation, though I'd be open to looking at using it to build installed
images for machines with severe resource constraints.
6) supported platforms must be fully integrated into building and
installation. If you need a special build procedure to make this happen
for kernel, we need to have rel-eng signing off saying they've approved
of whatever method that is, and QE signing off that they think it'll
result in a something they can claim is tested enough to release as a
primary arch.
7) it can't be a serious maintenance burdon due to build related issues.
We need a couple of groups to sign off that builds are fast enough, not
just on a "full distro rebuild" (throughput) level, but also on a
"doesn't destroy my workflow due to waiting on it" (latency) level.
So, the thing I'm seeing over and over in the discussion (well, aside from
Kevin), is these list of requirements that must be in place. However, none
of these requirements require being a primary arch to do.
In essence, if ARM is a primary arch in practice, then it should be able to
become one in designation. Stating at an organization level "ARM is a
primary arch pending on meeting criteria A, B, and C" seems backwards. We
should continue on threads like this figuring out what makes a primary arch
viable, and then table the discussion of whether ARM should be primary until
it meets these viability standards.
Bill
10:37 a.m.
On Wed, Mar 21, 2012 at 2:52 PM, Bill Nottingham <notting(a)redhat.com> wrote:
Peter Jones (pjones(a)redhat.com) said:
> In yesterday's FESCo meeting I told you I'd make a list of specific issues
> I have with the current proposal for ARM as a primary archictecture. There
> are some places where I think the current proposal fails to deal with some
> necessary aspects of becoming a primary architecture, and some places where
> I don't think the approach is quite right. So without further ado:
>
> 1) mechanisms need to be in place to get package maintainers access to fix
> arm-specific bugs in their packages
> 2) excludearch is not an option. This is fundamentally contrary to being
> a primary arch. In fact this is one of the defining characteristics of
> a secondary arch.
> 3) arm must be integrated to the formal release criteria
> 4) when milestones occur, arm needs to be just as testible as other
> primary architectures
> 5) installation methods must be in place. I'm not saying it has to be
> using the same model as x86, but when we get to beta, if it can't be
> installed, it can't meet similar release criteria to existing or prior
> primary arches. Where possible, we should be using anaconda for
> installation, though I'd be open to looking at using it to build installed
> images for machines with severe resource constraints.
> 6) supported platforms must be fully integrated into building and
> installation. If you need a special build procedure to make this happen
> for kernel, we need to have rel-eng signing off saying they've approved
> of whatever method that is, and QE signing off that they think it'll
> result in a something they can claim is tested enough to release as a
> primary arch.
> 7) it can't be a serious maintenance burdon due to build related issues.
> We need a couple of groups to sign off that builds are fast enough, not
> just on a "full distro rebuild" (throughput) level, but also on a
> "doesn't destroy my workflow due to waiting on it" (latency) level.
So, the thing I'm seeing over and over in the discussion (well, aside from
Kevin), is these list of requirements that must be in place. However, none
of these requirements require being a primary arch to do.
In essence, if ARM is a primary arch in practice, then it should be able to
become one in designation. Stating at an organization level "ARM is a
primary arch pending on meeting criteria A, B, and C" seems backwards. We
should continue on threads like this figuring out what makes a primary arch
viable, and then table the discussion of whether ARM should be primary until
it meets these viability standards.
Exactly! Ultimately what we need is FESCo to document what are the
requirements of being promoted to a primary architecture and then it's
the ARM SIGs job of ensuring they adhere to the requirements, provide
viable workable alternatives that are acceptable to FESCo, or provide
proof that the requirement will be met within an agreed time frame.
Ultimately the ARM SIG knew there would be issues and discussions,
ultimately there has never really been an architecture promoted to
primary in the current project guidelines since core/extras were
merged so there's no criteria for promotion and it was always
envisioned that the creation of generic promotion criteria would be
part of the requirements of the eventual promotion of ARM.
Peter
9 p.m.
Peter Robinson wrote:
Exactly! Ultimately what we need is FESCo to document what are the
requirements of being promoted to a primary architecture and then it's
the ARM SIGs job of ensuring they adhere to the requirements, provide
viable workable alternatives that are acceptable to FESCo, or provide
proof that the requirement will be met within an agreed time frame.
ARM should most definitely NOT be approved as a primary architecture before
all the requirements are actually met!
We have seen what happened when the EU took Greece's word on the promise
that they'd eventually meet the Maastricht criteria. Let's not do the same
mistake in Fedora!
Kevin Kofler
9:54 p.m.
On 03/21/2012 07:00 PM, Kevin Kofler wrote:
ARM should most definitely NOT be approved as a primary architecture
before
all the requirements are actually met!
The dynamics of "when" are very much open to discussion, not to mention
"what" that will mean. We need a path to get from secondary to primary.
Whether it's designated "primary" at the end of that path or somewhere
in the middle is irrelevant- it's about getting ARM handled the Primary
Way (TM) during the journey.
We have seen what happened when the EU took Greece's word on the
promise
that they'd eventually meet the Maastricht criteria. Let's not do the same
mistake in Fedora!
What?
--
Brendan Conoboy / Red Hat, Inc. / blc(a)redhat.com
10:13 p.m.
Brendan Conoboy wrote:
On 03/21/2012 07:00 PM, Kevin Kofler wrote:
> We have seen what happened when the EU took Greece's word on the promise
> that they'd eventually meet the Maastricht criteria. Let's not do the
> same mistake in Fedora!
What?
The Maastricht criteria are the requirements countries had to fulfill to get
accepted into the Eurozone (i.e. to use the Euro as their currency). Greece
was accepted into the Eurozone without fulfilling those criteria because
they promised they'd fix the problems later. (FWIW, they also "adjusted" the
stats to fit the criteria in more than one place and the EU failed to detect
the cheating.) This is the main reason why we have the Euro crisis now.
(Sorry for the European politics intermission, but I just had to explain the
analogy. :-) )
Kevin Kofler
10:14 p.m.
On 03/21/2012 08:13 PM, Kevin Kofler wrote:
The Maastricht criteria are the requirements countries had to fulfill
to get
accepted into the Eurozone (i.e. to use the Euro as their currency). Greece
was accepted into the Eurozone without fulfilling those criteria because
they promised they'd fix the problems later. (FWIW, they also "adjusted"
the
stats to fit the criteria in more than one place and the EU failed to detect
the cheating.) This is the main reason why we have the Euro crisis now.
(Sorry for the European politics intermission, but I just had to explain the
analogy. :-) )
I know what's happening in Greece. I don't know why you're bringing it
up here.
--
Brendan Conoboy / Red Hat, Inc. / blc(a)redhat.com
10:28 p.m.
Brendan Conoboy wrote:
I know what's happening in Greece. I don't know why
you're bringing it
up here.
I'm bringing it up here as an example (by analogy) of what happens when you
let a country (an architecture) such as Greece (ARM) enter the Eurozone (the
primary Fedora architectures) without fulfilling the required criteria (at
the time of the approval, not at some promised later point).
Kevin Kofler
10:52 p.m.
On 03/21/2012 08:28 PM, Kevin Kofler wrote:
I'm bringing it up here as an example (by analogy) of what
happens when you
let a country (an architecture) such as Greece (ARM) enter the Eurozone (the
primary Fedora architectures) without fulfilling the required criteria (at
the time of the approval, not at some promised later point).
Your analogy was easy to understand, but why you wrote it was not. It's
inappropriate and I can't imagine what good you think will come of
having made it. Whatever your politics are they might not be shared by
others taking part in this discussion and it's easy to see room for
somebody taking offense at your analogy, Let's act like we're all on
the same side. We are, after all, all working on Fedora.
--
Brendan Conoboy / Red Hat, Inc. / blc(a)redhat.com
2:16 a.m.
On Mar 21, 2012, at 9:13 PM, Kevin Kofler wrote:
Brendan Conoboy wrote:
> On 03/21/2012 07:00 PM, Kevin Kofler wrote:
>> We have seen what happened when the EU took Greece's word on the promise
>> that they'd eventually meet the Maastricht criteria. Let's not do the
>> same mistake in Fedora!
>
> What?
The Maastricht criteria are ....
[SNIP]
Pretty sure "What?" is code for "What?! What?! What?! No, just please
stop!"
For me it's code for "WTF is wrong with you?"
If you really thought the question was serious, you should have just supplied a lmgtfy.com
link. Like this:
http://bit.ly/GFJqwV
On Mar 22, 2012, at 12:31 AM, Kevin Kofler wrote:
Consumer desktops and notebooks. The things we normally call "computers".
Those have always been and should remain our primary target.
You are invited to wake up, stand aside, or get run over. Your "computers" are
about to become typewriters. It will not be a decade longer.
http://www.engadget.com/2012/02/03/canalys-more-smartphones-than-pcs-ship...
Apple's PPC machines were computers. Apple's ARM machines are
not. One big
reason being that Apple is doing everything they can to prevent you from
installing a non-Apple operating system (such as Fedora) on them.
Using your logic, NASA's computers to send man to the moon weren't computers
because they were a closed platform. I think we can all think of computers that could only
run one operating system and no other in the past and present and future. And maybe I have
a belligerent, and misinformed, house plant that will agree with your logic. Nope, never
mind, they all disagree.
It will be time to consider ARM for primary architecture status when
it will
be a serious contender in the computer (as defined previously) market.
Hmm more smartphones than PC's, but it's not to be taken serious because of
emotion based arguments and wishful thinking, and iceberg ahead type rationalizations.
Most consumers already consider the frigging phones more important, and use them more than
a desktop or laptop computer. What is very soon to be niche is apparently your market that
depend on merely high(er) performance computing, not mobility. You are completely
discounting size, in favor of speed. And the market resoundingly is saying speed matters,
but not as much as size.
You have fun rearranging the deck chairs while all of this transpires. Take a moment to
consider how you'll benefit from others' preparations while your contribution will
have been a lot of mostly useless whinging. At least try to make it more entertaining.
Chris Murphy
2:23 a.m.
On Thu, Mar 22, 2012 at 8:16 AM, Chris Murphy <lists(a)colorremedies.com> wrote:
our "computers" are about to become typewriters. It will
not be a decade longer.
http://www.engadget.com/2012/02/03/canalys-more-smartphones-than-pcs-ship...
While I agree that we will see more smartphones and tablets in the
future the people that actually replace there traditional computers
with tablets or even smartphones are near zero.
Sells do not really tell the whole story as many people simply don't
have a need to buy new laptops/desktops because what they have is
"good enough" so they spend there money on other gadgets.
2:57 a.m.
On Mar 22, 2012, at 1:23 AM, drago01 wrote:
On Thu, Mar 22, 2012 at 8:16 AM, Chris Murphy
<lists(a)colorremedies.com> wrote:
> our "computers" are about to become typewriters. It will not be a decade
longer.
>
>
http://www.engadget.com/2012/02/03/canalys-more-smartphones-than-pcs-ship...
While I agree that we will see more smartphones and tablets in the
future the people that actually replace there traditional computers
with tablets or even smartphones are near zero.
You're assuming they had a computer to begin with. The data is noisy but there's a
significant minority who do not have computers, now buying a smart phone. This will grow.
They may never end up with a desktop. Even Apple has disconnected a requirement for having
a desktop. My parents are candidates for replacing their laptop with just an iPad. Maybe
1/4 of the friends I have use a desktop/laptop once a week or less. And increasingly less
often. Their phone? Can't live without it. It's already a primary device.
Sells do not really tell the whole story as many people simply
don't
have a need to buy new laptops/desktops because what they have is
"good enough" so they spend there money on other gadgets.
Mobile devices are replaced more frequently than desktops, which could also skew the data
toward mobile. But Apple didn't become the biggest company in the world by market
capitalization, eclipsing Microsoft and even Exxon-Mobile, by selling desktops and
laptops. It's iOS. (And the iMonostore.)
Desktop computers are used overwhelmingly for email and web browsing. It's total
overkill. The desktop computer is a super computer that no consumer really needs. It's
a dying market. It's now servers and mobile. The transitional element will be
laptops/ultrabooks (netbooks obviously are dead) which will keep desktop operating systems
and x86 around as a significant minority, but not for long.
Thunderbolt on an ARM tablet to connect a larger display, bluetooth keyboard, and internet
access and the overwhelming majority can do what they need to do. The economies of scale
of desktops, even in business, is dropping rapidly. For home users, it has already
happened a while ago. They don't need a desktop. They probably don't need a laptop
either.
Chris Murphy
3:10 a.m.
On Thu, Mar 22, 2012 at 8:57 AM, Chris Murphy <lists(a)colorremedies.com> wrote:
On Mar 22, 2012, at 1:23 AM, drago01 wrote:
> On Thu, Mar 22, 2012 at 8:16 AM, Chris Murphy <lists(a)colorremedies.com> wrote:
>> our "computers" are about to become typewriters. It will not be a
decade longer.
>>
>>
http://www.engadget.com/2012/02/03/canalys-more-smartphones-than-pcs-ship...
>
> While I agree that we will see more smartphones and tablets in the
> future the people that actually replace there traditional computers
> with tablets or even smartphones are near zero.
You're assuming they had a computer to begin with.
I was talking about this people. People that had no access to
computers to begin with are of course a different story.
The data is noisy but there's a significant minority who do not
have computers, now buying a smart phone. This will grow. They may never end up with a
desktop. Even Apple has disconnected a requirement for having a desktop. My parents are
candidates for replacing their laptop with just an iPad. Maybe 1/4 of the friends I have
use a desktop/laptop once a week or less.
Interesting. People I know just using them (tablets) as "toys" to play
some causal games, surf the net & read mails. They go back to there
laptops / desktops to do anything beyond that.
And increasingly less often. Their phone? Can't live without it.
It's already a primary device.
Well people couldn't live without "dumbphones" either so this is
natural progress.
> Sells do not really tell the whole story as many people simply don't
> have a need to buy new laptops/desktops because what they have is
> "good enough" so they spend there money on other gadgets.
Mobile devices are replaced more frequently than desktops, which could also skew the data
toward mobile. But Apple didn't become the biggest company in the world by market
capitalization, eclipsing Microsoft and even Exxon-Mobile, by selling desktops and
laptops. It's iOS. (And the iMonostore.)
"I agree that we will see more smartphones and tablets in the future"
... yes no doubt that market still has a potential to grow. I just do
not believe that a significant amount of people will throw there
desktops/laptops away and use tablets / smartphones instead.
Desktop computers are used overwhelmingly for email and web browsing.
It's total overkill. The desktop computer is a super computer that no consumer really
needs. It's a dying market. It's now servers and mobile. The transitional element
will be laptops/ultrabooks (netbooks obviously are dead) which will keep desktop operating
systems and x86 around as a significant minority, but not for long.
Tablets are 99% consumption only devices. Your are missing the
"production market" ... people do use computers to do work, write the
apps that the tablet/smartphone people enjoy etc.
So no there is still a marked beyond the consumption only devices
(tablets) and the data centers (servers). The world is not black and
white.
Thunderbolt on an ARM tablet to connect a larger display, bluetooth
keyboard, and internet access and the overwhelming majority can do what they need to do.
Which is a lot more work then simply open the laptop and start working.
The economies of scale of desktops, even in business, is dropping
rapidly.
Not seeing this happening. Switching to tabelts is just unproductive
(it does make sense for some uses though).
For home users, it has already happened a while ago. They don't
need a desktop. They probably don't need a laptop either.
When home user == "only consumes content" then yes but that is not
necessarily the only use of computers / laptops at home either.
3:57 a.m.
On Mar 22, 2012, at 2:10 AM, drago01 wrote:
>
Interesting. People I know just using them (tablets) as "toys" to play
some causal games, surf the net & read mails. They go back to there
laptops / desktops to do anything beyond that.
Most people don't. It's important to understand most of us on this list aren't
most people.
Toys?
FAA Approves IPad for Flight Navigation
http://www.tabletedia.com/news/2820.html
Here's a quote from a doctor: "Even if you’re not at home, you can quickly pick
up your phone, view the EKG, and take care of patients remotely."
http://www.imedicalapps.com/2011/12/apple-top-iphone-ipad-medical-apps-2011/
This is doing 2 minute google searches...
People read books on mobile devices. Computers? Ick. I'm not reading a book on a
computer. It's unpleasant. I can't read on a mobile device because I need a
browser with an average of 34 tabs. Most people lack my lunacy.
> And increasingly less often. Their phone? Can't live without it. It's already
a primary device.
Well people couldn't live without "dumbphones" either so this is
natural progress.
They could. They had desktops or laptops. Most people would replace their phone in a day
if it broke or were lost. A home computer? Weekend. Maybe next weekend.
"I agree that we will see more smartphones and tablets in the
future"
... yes no doubt that market still has a potential to grow. I just do
not believe that a significant amount of people will throw there
desktops/laptops away and use tablets / smartphones instead.
Most people will. There will be no advantage to a desktop or laptop. So far, speed is all
that's really come up. That's going to be a non-issue in a hurry. There's
BILLIONS of dollars pouring into mobile and tablet right now. It's what people want.
Tablets are 99% consumption only devices. Your are missing the
"production market" ... people do use computers to do work, write the
apps that the tablet/smartphone people enjoy etc.
Developer market? Image editing and video editing stations? Small markets. Enough to
maintain x86? Yeah sure, for a while. But as a majority?
Mobile market isn't just syphoning users from the consumer desktop market, it's
growing the market.
So no there is still a marked beyond the consumption only devices
(tablets) and the data centers (servers). The world is not black and
white.
It is a shrinking market.
> Thunderbolt on an ARM tablet to connect a larger display, bluetooth keyboard, and
internet access and the overwhelming majority can do what they need to do.
Which is a lot more work then simply open the laptop and start working.
Consumers are complicated.
> For home users, it has already happened a while ago. They
don't need a desktop. They probably don't need a laptop either.
When home user == "only consumes content" then yes but that is not
necessarily the only use of computers / laptops at home either.
It's the majority case. Email, web browser, books, Netflix, and it's a baby
sitter. It's like candy multiplied by TV for kids. Way more interesting for them than
desktop computers or laptops.
Chris Murphy
4:16 a.m.
On Thu, Mar 22, 2012 at 9:57 AM, Chris Murphy <lists(a)colorremedies.com> wrote:
On Mar 22, 2012, at 2:10 AM, drago01 wrote:
>>
> Interesting. People I know just using them (tablets) as "toys" to play
> some causal games, surf the net & read mails. They go back to there
> laptops / desktops to do anything beyond that.
Most people don't. It's important to understand most of us on this list
aren't most people.
I didn't claim thatI just countered your "my parents example" ...
basically this kind of "evidence" is moot ... we need more data to
judge that.
Toys?
I said the people I was talking about used them as toys. (Please read
what I wrote and don't try to refute stuff that isn't even written
there).
FAA Approves IPad for Flight Navigation
http://www.tabletedia.com/news/2820.html
Here's a quote from a doctor: "Even if you’re not at home, you can quickly pick
up your phone, view the EKG, and take care of patients remotely."
http://www.imedicalapps.com/2011/12/apple-top-iphone-ipad-medical-apps-2011/
This is doing 2 minute google searches...
Again see the enterprise part "(it does make sense for some uses
though)." ... those are those uses. I am not saying tablets are
useless. I am just saying those are *different* devices.
You don't replace a plane with a car either.
People read books on mobile devices. Computers? Ick. I'm not
reading a book on a computer. It's unpleasant. I can't read on a mobile device
because I need a browser with an average of 34 tabs. Most people lack my lunacy.
Well I'd prefer a real boot or an ereader over a computer or tablet.
>
>> And increasingly less often. Their phone? Can't live without it. It's
already a primary device.
>
> Well people couldn't live without "dumbphones" either so this is
> natural progress.
They could. They had desktops or laptops. Most people would replace their phone in a day
if it broke or were lost. A home computer? Weekend. Maybe next weekend.
Most people that buy smartphones today *do* have laptops / desktoüs.
> "I agree that we will see more smartphones and tablets in
the future"
> ... yes no doubt that market still has a potential to grow. I just do
> not believe that a significant amount of people will throw there
> desktops/laptops away and use tablets / smartphones instead.
Most people will. There will be no advantage to a desktop or laptop. So far, speed is all
that's really come up. That's going to be a non-issue in a hurry. There's
BILLIONS of dollars pouring into mobile and tablet right now. It's what people want.
Actually speed isn't an advantage see the (now dead) netbook hype. For
most people current speed is "good enough" (hence no need to go buy a
new computer every year).
>
> Tablets are 99% consumption only devices. Your are missing the
> "production market" ... people do use computers to do work, write the
> apps that the tablet/smartphone people enjoy etc.
Developer market? Image editing and video editing stations? Small markets. Enough to
maintain x86? Yeah sure, for a while. But as a majority?
Office, DTP and probably others or in short "content creation".
Mobile market isn't just syphoning users from the consumer
desktop market, it's growing the market.
> So no there is still a marked beyond the consumption only devices
> (tablets) and the data centers (servers). The world is not black and
> white.
It is a shrinking market.
it is a saturated marked.
>
>> Thunderbolt on an ARM tablet to connect a larger display, bluetooth keyboard, and
internet access and the overwhelming majority can do what they need to do.
>
> Which is a lot more work then simply open the laptop and start working.
Consumers are complicated.
...
>> For home users, it has already happened a while ago. They
don't need a desktop. They probably don't need a laptop either.
>
> When home user == "only consumes content" then yes but that is not
> necessarily the only use of computers / laptops at home either.
It's the majority case. Email, web browser, books, Netflix, and it's a baby
sitter. It's like candy multiplied by TV for kids. Way more interesting for them than
desktop computers or laptops.
5:17 a.m.
On Thu, Mar 22, 2012 at 2:46 PM, drago01 <drago01(a)gmail.com> wrote:
On Thu, Mar 22, 2012 at 9:57 AM, Chris Murphy
<lists(a)colorremedies.com> wrote:
>
>
> On Mar 22, 2012, at 2:10 AM, drago01 wrote:
>>>
>> Interesting. People I know just using them (tablets) as "toys" to play
>> some causal games, surf the net & read mails. They go back to there
>> laptops / desktops to do anything beyond that.
>
> Most people don't. It's important to understand most of us on this list
aren't most people.
I didn't claim thatI just countered your "my parents example" ...
basically this kind of "evidence" is moot ... we need more data to
judge that.
> Toys?
I said the people I was talking about used them as toys. (Please read
what I wrote and don't try to refute stuff that isn't even written
there).
> FAA Approves IPad for Flight Navigation
> http://www.tabletedia.com/news/2820.html
>
> Here's a quote from a doctor: "Even if you’re not at home, you can quickly
pick up your phone, view the EKG, and take care of patients remotely."
> http://www.imedicalapps.com/2011/12/apple-top-iphone-ipad-medical-apps-2011/
>
> This is doing 2 minute google searches...
Again see the enterprise part "(it does make sense for some uses
though)." ... those are those uses. I am not saying tablets are
useless. I am just saying those are *different* devices.
You don't replace a plane with a car either.
> People read books on mobile devices. Computers? Ick. I'm not reading a book on a
computer. It's unpleasant. I can't read on a mobile device because I need a
browser with an average of 34 tabs. Most people lack my lunacy.
Well I'd prefer a real boot or an ereader over a computer or tablet.
>
>>
>>> And increasingly less often. Their phone? Can't live without it. It's
already a primary device.
>>
>> Well people couldn't live without "dumbphones" either so this is
>> natural progress.
>
> They could. They had desktops or laptops. Most people would replace their phone in a
day if it broke or were lost. A home computer? Weekend. Maybe next weekend.
>
Most people that buy smartphones today *do* have laptops / desktoüs.
>> "I agree that we will see more smartphones and tablets in the future"
>> ... yes no doubt that market still has a potential to grow. I just do
>> not believe that a significant amount of people will throw there
>> desktops/laptops away and use tablets / smartphones instead.
>
> Most people will. There will be no advantage to a desktop or laptop. So far, speed is
all that's really come up. That's going to be a non-issue in a hurry. There's
BILLIONS of dollars pouring into mobile and tablet right now. It's what people want.
Actually speed isn't an advantage see the (now dead) netbook hype. For
most people current speed is "good enough" (hence no need to go buy a
new computer every year).
>>
>> Tablets are 99% consumption only devices. Your are missing the
>> "production market" ... people do use computers to do work, write the
>> apps that the tablet/smartphone people enjoy etc.
>
> Developer market? Image editing and video editing stations? Small markets. Enough to
maintain x86? Yeah sure, for a while. But as a majority?
Office, DTP and probably others or in short "content creation".
> Mobile market isn't just syphoning users from the consumer desktop market,
it's growing the market.
>
>
>> So no there is still a marked beyond the consumption only devices
>> (tablets) and the data centers (servers). The world is not black and
>> white.
>
> It is a shrinking market.
it is a saturated marked.
>>
>>> Thunderbolt on an ARM tablet to connect a larger display, bluetooth keyboard,
and internet access and the overwhelming majority can do what they need to do.
>>
>> Which is a lot more work then simply open the laptop and start working.
>
> Consumers are complicated.
...
>>> For home users, it has already happened a while ago. They don't need a
desktop. They probably don't need a laptop either.
>>
>> When home user == "only consumes content" then yes but that is not
>> necessarily the only use of computers / laptops at home either.
>
> It's the majority case. Email, web browser, books, Netflix, and it's a baby
sitter. It's like candy multiplied by TV for kids. Way more interesting for them than
desktop computers or laptops.
>
--
devel mailing list
devel(a)lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
I see that this discussion has gone from ARM as a primary architecture
for Fedora to a general Tablets vs PC market discussion. IMHO, While
there is no doubt that the tablet/mobile market is growing rapidly,
The desktop and laptops are there to stay.
Considering ARM as a primary architecture for Fedora is not a bad
idea. But Sorry, why is this proposed? Do you intend to run Fedora on
your smartphones or tablets?
I think that making ARM as a primary architecture for Fedora is a lot
of work, I have no idea of the resources available in terms of
developers, machines (in case of native builds),testers etc.
And what will Fedora have achieved after putting in so much work? A
few users (read geeks) who will be willing to install Fedora on their
android tablets or ipads? Are there any ARM boards out in the market
that are waiting to get Fedora installed on them?
Where is the hardware? Do you see signs of ARM boards coming in the
near future (next 1 year or so) on which users can install operating
systems of their choice? If the answer is yes, I would recommend
considering ARM as a primary architecture for Fedora.
If the answer is no, I think it is probably too early to consider ARM
as a primary architecture for Fedora.
Best Regards,
Elison
6:01 a.m.
On 03/22/2012 10:17 AM, elison.niven(a)gmail.com wrote:
And what will Fedora have achieved after putting in so much work? A
few users (read geeks) who will be willing to install Fedora on their
android tablets or ipads? Are there any ARM boards out in the market
that are waiting to get Fedora installed on them?
Where is the hardware? Do you see signs of ARM boards coming in the
near future (next 1 year or so) on which users can install operating
systems of their choice?
I wonder where you've been. See Raspberry Pi and Trimslice for a
couple of recent ones.
Andrew.
1:13 p.m.
On Thu, Mar 22, 2012 at 7:01 AM, Andrew Haley <aph(a)redhat.com> wrote:
> Where is the hardware? Do you see signs of ARM boards coming in
the
> near future (next 1 year or so) on which users can install operating
> systems of their choice?
I wonder where you've been. See Raspberry Pi and Trimslice for a
couple of recent ones.
And kids in Uruguay and Nicaragua will soon start their school year
equipped with XO-1.75 units running an OS based on Fedora-14 ARM.
Battery life is wicked on these units.
cheers,
martin
--
martin.langhoff(a)gmail.com
martin(a)laptop.org -- Software Architect - OLPC
- ask interesting questions
- don't get distracted with shiny stuff - working code first
- http://wiki.laptop.org/go/User:Martinlanghoff
6:26 a.m.
I see that this discussion has gone from ARM as a primary
architecture
for Fedora to a general Tablets vs PC market discussion. IMHO, While
there is no doubt that the tablet/mobile market is growing rapidly,
The desktop and laptops are there to stay.
Considering ARM as a primary architecture for Fedora is not a bad
idea. But Sorry, why is this proposed? Do you intend to run Fedora on
your smartphones or tablets?
It's got nothing to do with smart phones and tablets. We don't intend
on supporting Fedora on smart phones (not to say a third party group
can't though), we're reviewing tablets and it will certainly be
possible to run it on tablets, the level of support out of the box is
undecided. The thing it does have to do with it ARM
netbooks/laptops/smarttops as well as dev boards and servers. There's
100s of ARM devices out there that aren't tablets or smartphones.
I think that making ARM as a primary architecture for Fedora is a
lot
of work, I have no idea of the resources available in terms of
developers, machines (in case of native builds),testers etc.
Don't you think that the ARM SIG that has been working on ARM on
Fedora for close to 2 years might be aware of this?
And what will Fedora have achieved after putting in so much work? A
few users (read geeks) who will be willing to install Fedora on their
android tablets or ipads? Are there any ARM boards out in the market
that are waiting to get Fedora installed on them?
Yes, there's lots of devices. HP/Calxeda servers [1], Dell has
announced intention to do ARM servers[2], the XO 1.75 [3] and XO-3 [4]
devices, the Spark Tablet [5] and around a dozen different smartbooks,
nettops, development boards to name but a few.
Where is the hardware? Do you see signs of ARM boards coming in the
near future (next 1 year or so) on which users can install operating
systems of their choice? If the answer is yes, I would recommend
considering ARM as a primary architecture for Fedora.
If the answer is no, I think it is probably too early to consider ARM
as a primary architecture for Fedora.
The answer is already yes, and is going to increase substantially in
the coming months/year.
Peter
[1]
http://www.computerworld.com/s/article/9221370/Calxeda_s_chip_boosts_ARM_...
[2]
http://www.engadget.com/2012/02/21/dell-wants-in-on-arm-server-field-says...
[3] http://wiki.laptop.org/go/XO-1.75
[4] http://wiki.laptop.org/go/XO-3
[5] http://www.linuxfordevices.com/c/a/News/Spark-tablet-announced/?kc=rss
6:30 a.m.
On Thu, Mar 22, 2012 at 4:56 PM, Peter Robinson <pbrobinson(a)gmail.com> wrote:
> I see that this discussion has gone from ARM as a primary
architecture
> for Fedora to a general Tablets vs PC market discussion. IMHO, While
> there is no doubt that the tablet/mobile market is growing rapidly,
> The desktop and laptops are there to stay.
>
> Considering ARM as a primary architecture for Fedora is not a bad
> idea. But Sorry, why is this proposed? Do you intend to run Fedora on
> your smartphones or tablets?
It's got nothing to do with smart phones and tablets. We don't intend
on supporting Fedora on smart phones (not to say a third party group
can't though), we're reviewing tablets and it will certainly be
possible to run it on tablets, the level of support out of the box is
undecided. The thing it does have to do with it ARM
netbooks/laptops/smarttops as well as dev boards and servers. There's
100s of ARM devices out there that aren't tablets or smartphones.
> I think that making ARM as a primary architecture for Fedora is a lot
> of work, I have no idea of the resources available in terms of
> developers, machines (in case of native builds),testers etc.
Don't you think that the ARM SIG that has been working on ARM on
Fedora for close to 2 years might be aware of this?
> And what will Fedora have achieved after putting in so much work? A
> few users (read geeks) who will be willing to install Fedora on their
> android tablets or ipads? Are there any ARM boards out in the market
> that are waiting to get Fedora installed on them?
Yes, there's lots of devices. HP/Calxeda servers [1], Dell has
announced intention to do ARM servers[2], the XO 1.75 [3] and XO-3 [4]
devices, the Spark Tablet [5] and around a dozen different smartbooks,
nettops, development boards to name but a few.
> Where is the hardware? Do you see signs of ARM boards coming in the
> near future (next 1 year or so) on which users can install operating
> systems of their choice? If the answer is yes, I would recommend
> considering ARM as a primary architecture for Fedora.
> If the answer is no, I think it is probably too early to consider ARM
> as a primary architecture for Fedora.
The answer is already yes, and is going to increase substantially in
the coming months/year.
Peter
[1]
http://www.computerworld.com/s/article/9221370/Calxeda_s_chip_boosts_ARM_...
[2]
http://www.engadget.com/2012/02/21/dell-wants-in-on-arm-server-field-says...
[3] http://wiki.laptop.org/go/XO-1.75
[4] http://wiki.laptop.org/go/XO-3
[5] http://www.linuxfordevices.com/c/a/News/Spark-tablet-announced/?kc=rss
Accepted. Thank you for taking the trouble to clarify.
Best Regards,
Elison Niven
9:28 a.m.
On Thu, Mar 22, 2012 at 12:26 PM, Peter Robinson <pbrobinson(a)gmail.com> wrote:
> I see that this discussion has gone from ARM as a primary
architecture
> for Fedora to a general Tablets vs PC market discussion. IMHO, While
> there is no doubt that the tablet/mobile market is growing rapidly,
> The desktop and laptops are there to stay.
>
> Considering ARM as a primary architecture for Fedora is not a bad
> idea. But Sorry, why is this proposed? Do you intend to run Fedora on
> your smartphones or tablets?
It's got nothing to do with smart phones and tablets. We don't intend
on supporting Fedora on smart phones (not to say a third party group
can't though), we're reviewing tablets and it will certainly be
possible to run it on tablets, the level of support out of the box is
undecided.
Well this is harder then you think as most tablets don't allow you to
change the OS (easily) while others don't allow you to change it at
all.
The only ones where this is possible right now are actually x86 based
tablets. Even Windows 8 wont help here as MS mandates that the
devices are locked with secure boot without having an option to disable it.
10:08 a.m.
On Thu, Mar 22, 2012 at 2:28 PM, drago01 <drago01(a)gmail.com> wrote:
On Thu, Mar 22, 2012 at 12:26 PM, Peter Robinson
<pbrobinson(a)gmail.com> wrote:
>> I see that this discussion has gone from ARM as a primary architecture
>> for Fedora to a general Tablets vs PC market discussion. IMHO, While
>> there is no doubt that the tablet/mobile market is growing rapidly,
>> The desktop and laptops are there to stay.
>>
>> Considering ARM as a primary architecture for Fedora is not a bad
>> idea. But Sorry, why is this proposed? Do you intend to run Fedora on
>> your smartphones or tablets?
>
> It's got nothing to do with smart phones and tablets. We don't intend
> on supporting Fedora on smart phones (not to say a third party group
> can't though), we're reviewing tablets and it will certainly be
> possible to run it on tablets, the level of support out of the box is
> undecided.
Well this is harder then you think as most tablets don't allow you to
change the OS (easily) while others don't allow you to change it at
all.
It's not harder than I think, I've been working on Fedora ARM and I
know exactly the level of hardness and a number of the possible issues
involved so I would actually appreciate if you would do some of your
own research, I've been looking into and dealing with tablet options
for running Fedora for quite some time.
The only ones where this is possible right now are actually x86
based
tablets. Even Windows 8 wont help here as MS mandates that the
devices are locked with secure boot without having an option to disable it.
No that is definitely not the case that it is x86 only, for tablets
that are BIOS locked, yes, it's a non starter, but there are many ARM
tablets that are BIOS unlocked and will, in time, be able to run
Fedora just fine. For starters the OLPC XO-3 tablet will run Fedora on
ARM out of the box, it's relatively easy to get Linux running on the
Asus Transformer [1] as well as a number of other Tegra based tablets
and then there's the Spark tablet that will run KDE's Plasma tablet
interface out of the box using Mer, but there's won't be too much work
to make that Fedora.
So it is possible, it would be even possible right now for the
determined hacker, but with time we'll make this easier for the
general end user to install it onto various tablets but in the
beginning we're aiming for the servers and the dev
boards/nettops/smart books as they are readily available and easily
supportable.
Peter
[1] http://gizmodo.com/5874133/olpc-xo-30-hands-on-the-100-wonder-tablet
[2]
http://www.xda-developers.com/android/almost-perfect-native-ubuntu-on-asu...
[3] http://www.linuxfordevices.com/c/a/News/Spark-tablet-announced/
10:21 p.m.
Peter Robinson wrote:
On Thu, Mar 22, 2012 at 2:28 PM, drago01 <drago01(a)gmail.com>
wrote:
> The only ones where this is possible right now are actually x86 based
> tablets. Even Windows 8 wont help here as MS mandates that the
> devices are locked with secure boot without having an option to disable
> it.
No that is definitely not the case that it is x86 only,
Quite the opposite: M$ rules for "secure" boot are:
* on x86 (or "non-ARM" in their wording) devices, it MUST be possible for
users to disable "secure" boot,
* on ARM devices, it MUST NOT be possible for users to disable "secure"
boot,
i.e. all ARM devices shipping Window$ will have restricted boot forced on
with no option to disable it.
Kevin Kofler
10:50 p.m.
Hi Kevin,
Thanks for your message.
On 03/22/2012 11:21 PM, Kevin Kofler wrote:
Peter Robinson wrote:
> On Thu, Mar 22, 2012 at 2:28 PM, drago01 <drago01(a)gmail.com> wrote:
>> The only ones where this is possible right now are actually x86 based
>> tablets. Even Windows 8 wont help here as MS mandates that the
>> devices are locked with secure boot without having an option to disable
>> it.
>
> No that is definitely not the case that it is x86 only,
Quite the opposite: M$ rules for "secure" boot are:
* on x86 (or "non-ARM" in their wording) devices, it MUST be possible for
users to disable "secure" boot,
* on ARM devices, it MUST NOT be possible for users to disable "secure"
boot,
i.e. all ARM devices shipping Window$ will have restricted boot forced on
with no option to disable it.
To an extent, Kevin is perhaps right here. There is a version of the
Microsoft Logo requirements that implies that logo-conforming devices
cannot be shipped with Custom Mode enabled. I know Matthew, and many
others, are suitably involved in advocating for different positions.
That's all I'm going to say here without legal counsel. But let's put
this in context. There will always be locked-down devices that are
designed to make it difficult to run alternative Operating Systems,
there have been before Fedora ARM, and there will be afterward :)
We haven't been seriously discussing the idea of running Fedora on
cellphones - and I'm certainly not proposing that now! - but I would
note that nobody has said how terrible it is that Fedora ARM will not
run on iPhone without hacking, cracking, jailbreaking, rooting, or
whatever terms you like. A vertically integrated tablet shipped with
Windows 8 is the same thing - it's designed end-to-end as a single
embedded product. There are many other tablets out there not shipping
with Windows 8 today, and there will be many more in the future. Some of
those Windows 8 tablets will eventually run non-Windows OSes because it
is inevitable that someone, somewhere will find a way to do that.
So while I'll defend Kevin's comment here as valid input, let me say
that I would like to issue a call for civility, Kevin. Please, engage us
in a reasonable, serious conversation, or don't. I haven't replied to
your other messages because they are filled with vitriol. I suspect many
other people similarly ignore you (and perversely, I suspect you assist
in our cause of becoming a Primary Architecture by being so extremely
vocal in your unreasonable opposition of the concept). Anyway, I am very
willing to discuss with you, but only if you will agree to please
consider having that discussion in a civil manner.
Jon.
3:47 a.m.
On Mar 23, 2012 3:22 AM, "Kevin Kofler" <kevin.kofler(a)chello.at> wrote:
Peter Robinson wrote:
> On Thu, Mar 22, 2012 at 2:28 PM, drago01 <drago01(a)gmail.com> wrote:
>> The only ones where this is possible right now are actually x86 based
>> tablets. Even Windows 8 wont help here as MS mandates that the
>> devices are locked with secure boot without having an option to disable
>> it.
>
> No that is definitely not the case that it is x86 only,
Quite the opposite: M$ rules for "secure" boot are:
* on x86 (or "non-ARM" in their wording) devices, it MUST be possible for
users to disable "secure" boot,
* on ARM devices, it MUST NOT be possible for users to disable "secure"
boot,
i.e. all ARM devices shipping Window$ will have restricted boot forced on
with no option to disable it.
And at the moment there are exactly 0 devices shipping windows 8 on arm.
There are no such rules for other oses such as Android, those are the
devices I was referring to, I did say above that BIOS locked are a non
starter already!
Kevin Kofler
--
devel mailing list
devel(a)lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
11:58 a.m.
Where is the hardware?
-- development boards --
BeagleBoard
PandaBoard (dual-core 1GHz, 1GB)
PandaBoard ES (dual-core 1.2GHz, 1GB)
You can buy the above at digikey, they've been shipping for a while.
They come with Ubuntu Desktop, just add keyboard, mouse, and monitor.
Raspberry Pi - slower, but just add keyboard, mouse, and monitor. I
hear they got 200,000 order requests, far exceeding their first
manufacturing run. These run Fedora desktop.
-- desktop/server --
Trimslice (dual-core 1GHz, 1GB, internal SATA) - dual display, comes
with Ubuntu desktop, just add keyboard, mouse, monitor(s). I have one
of these as a public web/git server, and a second for a desktop build
machine (my two run Fedora, of course). These have been available for
a while now.
I hear OLPC just shipped 60,000 ARM laptops to their first customer.
These run Fedora Desktop. I have one of these on my desk.
AC100 laptop (toshiba) - I don't know the tech details, but some of us
have Fedora on these.
Also the sheeva/guru/pogo/dreamplug "home servers"
-- near future --
HP Project Moonshot - hundreds of multi-core multi-gb Calxeda
server-grade arm processors in a 4U rack.
We (the Fedora/ARM project) also have some quad-core 4GB server-grade
prototypes in-house, these will be generally available soon.
6:26 a.m.
>> Well people couldn't live without "dumbphones"
either so this is
>> natural progress.
>
> They could. They had desktops or laptops. Most people would replace their phone in a
day if it broke or were lost. A home computer? Weekend. Maybe next weekend.
>
Most people that buy smartphones today *do* have laptops / desktoüs.
Actually that is not the case, it might be the case in the western
developed world, but in the developing world in places like China,
India and Africa in most cases the first an only device that a user
has is a smart phone or tablet due to the fact it's low power, runs
off batteries and has wireless connectivity, I think you'll find the
sale of these style of devices in those places out flanks everything
else, they are selling 100s of millions of them.
Peter
12:54 p.m.
On 03/22/2012 04:26 AM, Peter Robinson wrote:
Actually that is not the case, it might be the case in the western
developed world, but in the developing world in places like China,
India and Africa in most cases the first an only device that a user
has is a smart phone or tablet due to the fact it's low power, runs
off batteries and has wireless connectivity, I think you'll find the
sale of these style of devices in those places out flanks everything
else, they are selling 100s of millions of them.
Indeed- it's even true in the US. I don't actually have a desktop- I
have a laptop with a docking station- 2 monitors, quad core i7, 12GB of
RAM. The next generation of this device will either be faster, smaller,
a tablet, or cost less- possibly all 4. This won't stop until mobile
phones and/or tables are dockable desktop computers. The high end will
be servers that double as power-user desktops. There is literally no
reason for anything in-between.
--
Brendan Conoboy / Red Hat, Inc. / blc(a)redhat.com
12:40 p.m.
On Mar 22, 2012, at 3:16 AM, drago01 wrote:
I said the people I was talking about used them as toys. (Please read
what I wrote and don't try to refute stuff that isn't even written
there).
Don't get in a huff over things I haven't said either. Most people are also very
entertained by these toys.
Again see the enterprise part "(it does make sense for some uses
though)." ... those are those uses. I am not saying tablets are
useless. I am just saying those are *different* devices.
You don't replace a plane with a car either.
That's improper logic. The iPad is replacing 15 pounds of Jeppessen charts. Paper.
They are going directly from paper to tablets. No laptop in between. As an (inactive)
pilot, I fully expect professional pilots to migrate strictly to tablets on the road, and
maybe intermittently use a desktop/laptop as a transitional device. That is already
underway.
Well I'd prefer a real boot or an ereader over a computer or tablet.
My dad is 82. My sister bought him a Kindle for his birthday middle of last year. He uses
it more than the laptop, more than real books. The transition took maybe a couple of
months.
Most people that buy smartphones today *do* have laptops / desktoüs.
In the whole world? You're sure about that? I'm not.
Actually speed isn't an advantage see the (now dead) netbook
hype. For
most people current speed is "good enough" (hence no need to go buy a
new computer every year).
I see this as 2-4 years for the consumer desktop upgrade market's meaningful
existence. 4-6 years for laptops. People use them less and less already, and will upgrade
them less frequently. And at the point where what they want to do on mobile no longer
requires them to go to laptop? Why have one?
Office, DTP and probably others or in short "content creation".
My customers are desktop publishing. It's a small market. And yes, they will continue
to buy more powerful machines longer than the rest of the market. But look at where Adobe
is emphasizing new development. Cloud applications. For content creators.
One of my largest customers has done more training and modernization for content creators
recently than in years, primarily driven by ebook. That demand is not ebook on laptop,
it's ebook on mobile devices.
>> So no there is still a marked beyond the consumption only
devices
>> (tablets) and the data centers (servers). The world is not black and
>> white.
>
> It is a shrinking market.
it is a saturated marked.
Yeah, it's a popping bubble.
Chris Murphy
1:15 p.m.
On Thu, Mar 22, 2012 at 6:40 PM, Chris Murphy <lists(a)colorremedies.com> wrote:
On Mar 22, 2012, at 3:16 AM, drago01 wrote:
>
> I said the people I was talking about used them as toys. (Please read
> what I wrote and don't try to refute stuff that isn't even written
> there).
Don't get in a huff over things I haven't said either.
Didn't do that (intentionally).
Most people are also very entertained by these toys.
Which is fine ...
>
> Again see the enterprise part "(it does make sense for some uses
> though)." ... those are those uses. I am not saying tablets are
> useless. I am just saying those are *different* devices.
> You don't replace a plane with a car either.
That's improper logic. The iPad is replacing 15 pounds of Jeppessen charts. Paper.
They are going directly from paper to tablets. No laptop in between.
Last time I checked a "paper" isn't a laptop / pc so replacing a paper
with tablets (which can be the better choice depending on the use
case) does not mean "people are replacing there pcs with tablets".
As an (inactive) pilot, I fully expect professional pilots to migrate
strictly to tablets on the road, and maybe intermittently use a desktop/laptop as a
transitional device. That is already underway.
Because it makes sense there. Again I didn't say that tablets are
entirely useless. I just said "tablets are a new type of device not
desktop/laptop replacements".
>
> Well I'd prefer a real boot or an ereader over a computer or tablet.
My dad is 82. My sister bought him a Kindle for his birthday middle of last year. He uses
it more than the laptop, more than real books. The transition took maybe a couple of
months.
A kindle (unless you mean the kindle fire tablet) is an ereader which
aligns exactly with what I have said.
>
> Most people that buy smartphones today *do* have laptops / desktoüs.
In the whole world? You're sure about that? I'm not.
It might not be the case in some regions but overall yes.
> Actually speed isn't an advantage see the (now dead) netbook hype. For
> most people current speed is "good enough" (hence no need to go buy a
> new computer every year).
I see this as 2-4 years for the consumer desktop upgrade market's meaningful
existence. 4-6 years for laptops. People use them less and less already, and will upgrade
them less frequently. And at the point where what they want to do on mobile no longer
requires them to go to laptop? Why have one?
Again creating content. Anything that requires more then typing a few sentences.
>
> Office, DTP and probably others or in short "content creation".
My customers are desktop publishing. It's a small market.
Yes but it is just one of the "content creating" markets.
And yes, they will continue to buy more powerful machines longer than
the rest of the market. But look at where Adobe is emphasizing new development. Cloud
applications. For content creators.
One of my largest customers has done more training and modernization for content creators
recently than in years, primarily driven by ebook. That demand is not ebook on laptop,
it's ebook on mobile devices.
Again reading is content consumption which makes sense on ereaders
(and maybe tablets to an extent) but actually writing the books? No.
My point is if you are only consuming content you might be fine with
just a tablet but as soon as you want to create content it is no
longer fine.
Each tool has its uses.
3:08 p.m.
On Mar 22, 2012, at 12:15 PM, drago01 wrote:
Last time I checked a "paper" isn't a laptop / pc so
replacing a paper
with tablets (which can be the better choice depending on the use
case) does not mean "people are replacing there pcs with tablets".
Both jump from PC dependency, and skipping it altogether are occurring simultaneously.
Because it makes sense there. Again I didn't say that tablets
are
entirely useless. I just said "tablets are a new type of device not
desktop/laptop replacements".
They are a new type of device. They are increasingly desktop/laptop replacements.
A kindle (unless you mean the kindle fire tablet) is an ereader
which
aligns exactly with what I have said.
I think you overestimate the need/dependency people have for desktop/laptop computers.
>> Most people that buy smartphones today *do* have laptops /
desktoüs.
>
> In the whole world? You're sure about that? I'm not.
It might not be the case in some regions but overall yes.
Speculation. Since you took the rope and claim most people who buy smart phones do have
laptops, you're invited to provide a reference.
Are you aware that the number of middle class Chinese equals the entire U.S. population?
That it's predicted to be ~700 million by 2020? Have you tried using two-byte
languages on computers with a keyboard? It sucks.
> I see this as 2-4 years for the consumer desktop upgrade
market's meaningful existence. 4-6 years for laptops. People use them less and less
already, and will upgrade them less frequently. And at the point where what they want to
do on mobile no longer requires them to go to laptop? Why have one?
Again creating content. Anything that requires more then typing a few sentences.
iPads have had wireless keyboard for some time. This whole email can be done just as
quickly on an iPad as a desktop computer. I don't have a nice 24" screen, only
because iPads don't yet have Thunderbolt. They will.
>> Office, DTP and probably others or in short "content
creation".
>
> My customers are desktop publishing. It's a small market.
Yes but it is just one of the "content creating" markets.
All of content creation is a small marke next to consumer markets. It's always been
this way.
Again reading is content consumption which makes sense on ereaders
(and maybe tablets to an extent) but actually writing the books? No.
My point is if you are only consuming content you might be fine with
just a tablet but as soon as you want to create content it is no
longer fine.
Each tool has its uses.
The overwhelming bulk of the market is consumption. Not creation. And the growth is in the
former, not the latter.
Chris Murphy
3:21 p.m.
On Thu, Mar 22, 2012 at 9:08 PM, Chris Murphy <lists(a)colorremedies.com> wrote:
[...]
> A kindle (unless you mean the kindle fire tablet) is an ereader which
> aligns exactly with what I have said.
I think you overestimate the need/dependency people have for desktop/laptop computers.
You underestimate it ;)
Lets look at the windows market ... everyone and his dog has MS Office
and thus who can't afford it do pirate it.
This kind of does not fit in the "consumers just use facebook and
gmail" ... type of thinking.
>>> Most people that buy smartphones today *do* have laptops / desktoüs.
>>
>> In the whole world? You're sure about that? I'm not.
>
> It might not be the case in some regions but overall yes.
Speculation. Since you took the rope and claim most people who buy smart phones do have
laptops, you're invited to provide a reference.
Unfortunately I am not aware of any such studies ... the opposite
can't be proven either. I have yet to met a person that 1) does not
own any kind of PC but does own a smartphone ...
Might be different in some areas of the world but I doubt those are
the majority.
Are you aware that the number of middle class Chinese equals the
entire U.S. population? That it's predicted to be ~700 million by 2020? Have you tried
using two-byte languages on computers with a keyboard? It sucks.
It does not matter if you want to write something longer then a mail,
unless dictating text works reliably you have to use a (real)
keyboard.
Speaking of the US ... do you know that outside of the US there isn't
that huge "post pc" hype going on?
>> I see this as 2-4 years for the consumer desktop upgrade market's meaningful
existence. 4-6 years for laptops. People use them less and less already, and will upgrade
them less frequently. And at the point where what they want to do on mobile no longer
requires them to go to laptop? Why have one?
>
> Again creating content. Anything that requires more then typing a few sentences.
iPads have had wireless keyboard for some time. This whole email can be done just as
quickly on an iPad as a desktop computer. I don't have a nice 24" screen, only
because iPads don't yet have Thunderbolt. They will.
Sure you can but this is uncomfortable ... the devices in question
(tablets) are simply not suited for this kind of usage.
>>> Office, DTP and probably others or in short "content creation".
>>
>> My customers are desktop publishing. It's a small market.
>
> Yes but it is just one of the "content creating" markets.
All of content creation is a small marke next to consumer markets. It's always been
this way.
You are still claiming that consumers as in "home users" aren't
interested in creating content ... citation?
> Again reading is content consumption which makes sense on
ereaders
> (and maybe tablets to an extent) but actually writing the books? No.
>
> My point is if you are only consuming content you might be fine with
> just a tablet but as soon as you want to create content it is no
> longer fine.
> Each tool has its uses.
The overwhelming bulk of the market is consumption. Not creation. And the growth is in
the former, not the latter.
They are tied together. More consumers == more demand for content ==
bigger creation marked.
3:23 p.m.
On Thu, 2012-03-22 at 14:08 -0600, Chris Murphy wrote:
The overwhelming bulk of the market is consumption. Not creation.
And
the growth is in the former, not the latter.
I would still like you to consider the question of whether this holds
for the Fedora case, though. Is Fedora as a project in fact suitable -
either in current implementation, or in terms of our self-definition and
long term goals - for this whole 'market' you are identifying as a
single entity? Are we in fact truly interested in producing code for
these content consumption devices? Is that what we're doing?
--
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Twitter: AdamW_Fedora | identi.ca: adamwfedora
http://www.happyassassin.net
3:32 p.m.
Adam Williamson wrote:
I would still like you to consider the question of whether this
holds
for the Fedora case, though. Is Fedora as a project in fact suitable -
either in current implementation, or in terms of our self-definition and
long term goals - for this whole 'market' you are identifying as a
single entity? Are we in fact truly interested in producing code for
these content consumption devices? Is that what we're doing?
The only way to measure this accurately, like anything else in Fedora,
is by the number of contributors. I will be looking to contribute to the
ARM project in some way in hope that I can one day replace my aging N900
phone with newer, faster hardware and a real GNU/Linux image.
Red Hat needs to get into the phone/tablet business: Red Hat Enterprise
Mobile!
3:38 p.m.
On Thu, 2012-03-22 at 15:32 -0500, Michael Cronenworth wrote:
Adam Williamson wrote:
> I would still like you to consider the question of whether this holds
> for the Fedora case, though. Is Fedora as a project in fact suitable -
> either in current implementation, or in terms of our self-definition and
> long term goals - for this whole 'market' you are identifying as a
> single entity? Are we in fact truly interested in producing code for
> these content consumption devices? Is that what we're doing?
The only way to measure this accurately, like anything else in Fedora,
is by the number of contributors. I will be looking to contribute to the
ARM project in some way in hope that I can one day replace my aging N900
phone with newer, faster hardware and a real GNU/Linux image.
Red Hat needs to get into the phone/tablet business: Red Hat Enterprise
Mobile!
It doesn't seem like a huge over-reach to assume that any RH interest in
ARM is more on the server side than a raging desire to take on Android
and the iPad :) (Note: I don't have any sekrit inside info on this. It
seems like a reasonable guess, though.)
--
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Twitter: AdamW_Fedora | identi.ca: adamwfedora
http://www.happyassassin.net
3:46 p.m.
Adam Williamson wrote:
It doesn't seem like a huge over-reach to assume that any RH
interest in
ARM is more on the server side than a raging desire to take on Android
and the iPad:) (Note: I don't have any sekrit inside info on this. It
seems like a reasonable guess, though.)
Yes, I realize the server target over mobile, but if Nokia, a company
larger than Red Hat, could do it why can't Red Hat? :)
4:01 p.m.
On Thu, 2012-03-22 at 15:46 -0500, Michael Cronenworth wrote:
Adam Williamson wrote:
> It doesn't seem like a huge over-reach to assume that any RH interest in
> ARM is more on the server side than a raging desire to take on Android
> and the iPad:) (Note: I don't have any sekrit inside info on this. It
> seems like a reasonable guess, though.)
Yes, I realize the server target over mobile, but if Nokia, a company
larger than Red Hat, could do it why can't Red Hat? :)
Take on, yes. Win...not so much...
--
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Twitter: AdamW_Fedora | identi.ca: adamwfedora
http://www.happyassassin.net
3:40 a.m.
On Mar 22, 2012 8:47 PM, "Michael Cronenworth" <mike(a)cchtml.com> wrote:
Adam Williamson wrote:
>
> It doesn't seem like a huge over-reach to assume that any RH interest in
> ARM is more on the server side than a raging desire to take on Android
> and the iPad:) (Note: I don't have any sekrit inside info on this. It
> seems like a reasonable guess, though.)
Yes, I realize the server target over mobile, but if Nokia, a company
larger than
Red Hat, could do it why can't Red Hat? :)
Define "do it " as MeeGo is dead and they had to cosy up to Microsoft to
survive, not sure I'd even wish that on canonical!
--
devel mailing list
devel(a)lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
3:56 a.m.
----- Original Message -----
Define "do it " as MeeGo is dead and they had to cosy up to
Microsoft
to survive, not sure I'd even wish that on canonical!
In reality, Nokia never started working on MeeGo ;-)
Once we're sooo off-topic (and tablets and cell phones) became the topic,
I think ARM as primary arch is not everything. We are talking about
usually very constrained (memory, cpu, flash - I know, it's changing)
devices now. You don't need full blown distribution and Fedora is one. We
usually took x86 world as a reason, why we want very well integrated
distro over core platform based approach. And it's a place where meta-
distributions like MeeGo (no community based Mer Project) excels. As
Qt 5 is approaching, I took a look on theirs SPEC files - even for
already modular Qt 5 they are aiming even more granularity and it's
true for every other part of Mer system. Yeh, they are not distribution,
they are just core for other projects to build own one. But still - it's
going to be very hard for us to compete on ARM field with them (when
targeting tablets/mobile world).
Jaroslav
3:38 a.m.
On Mar 22, 2012 8:32 PM, "Michael Cronenworth" <mike(a)cchtml.com> wrote:
Adam Williamson wrote:
>
> I would still like you to consider the question of whether this holds
> for the Fedora case, though. Is Fedora as a project in fact suitable -
> either in current implementation, or in terms of our self-definition and
> long term goals - for this whole 'market' you are identifying as a
> single entity? Are we in fact truly interested in producing code for
> these content consumption devices? Is that what we're doing?
The only way to measure this accurately, like anything else in Fedora, is
by the
number of contributors. I will be looking to contribute to the ARM
project in some way in hope that I can one day replace my aging N900 phone
with newer, faster hardware and a real GNU/Linux image.
Red Hat needs to get into the phone/tablet business: Red Hat Enterprise
Mobile!
I see that very unlikely IMO, you just have to look at the struggle for 3rd
place in the market, it's basically already killed MeeGo / maemo, webos ans
likely blackberry.
Peter
--
devel mailing list
devel(a)lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
4 p.m.
On 03/22/2012 01:23 PM, Adam Williamson wrote:
I would still like you to consider the question of whether this
holds
for the Fedora case, though. Is Fedora as a project in fact suitable -
either in current implementation, or in terms of our self-definition and
long term goals - for this whole 'market' you are identifying as a
single entity? Are we in fact truly interested in producing code for
these content consumption devices? Is that what we're doing?
#include <outofscope.h>
Fedora is not currently suitable for mobile devices. The majority of
end users want content consumption, not content creation, devices. The
fact that computers up to this point have been general purpose enough to
be both is why we're all here having this conversation. I'm not saying
Fedora is going to save the world, but it can certainly save itself by
making sure that future content-consumption devices can also be used for
content creation. It's the hardware that the majority of all future
developers-in-potential are going to own.
--
Brendan Conoboy / Red Hat, Inc. / blc(a)redhat.com
5 p.m.
On Mar 22, 2012, at 2:23 PM, Adam Williamson wrote:
On Thu, 2012-03-22 at 14:08 -0600, Chris Murphy wrote:
> The overwhelming bulk of the market is consumption. Not creation. And
> the growth is in the former, not the latter.
I would still like you to consider the question of whether this holds
for the Fedora case, though. Is Fedora as a project in fact suitable -
either in current implementation, or in terms of our self-definition and
long term goals - for this whole 'market' you are identifying as a
single entity? Are we in fact truly interested in producing code for
these content consumption devices? Is that what we're doing?
I'm not well versed on what Fedora is interested in, other than the broad relationship
with Red Hat that most anyone paying attention can realize the mutual benefits.
But RHEL and Fedora are not strictly server, developer, research oriented. Business,
government, educational desktops and even to some degree regular Joe User, are target
markets. Perhaps Joe User is incidental. I don't know what any of these percentages
are to either Red Hat or Fedora, but it's unlikely this sub-market (non-server,
non-developer, non-research and non-geek) is going to behave radically differently with
respect to computer form factor than the larger non-Linux computer market. These
businesses, governments, schools, regular users, are looking for innovation in any case.
Is Red Hat / Fedora interested in those sub-markets? I think they are. If so, the growth
area is where those sub-markets are headed and that's definitely not desktop. Laptop
is still a growth area for a bit longer. But clearly the biggest growth non-server,
non-developer, non-geek sub-market slice is also not desktop, nor laptop.
Chris Murphy
12:57 p.m.
drago01 (drago01(a)gmail.com) said:
> The data is noisy but there's a significant minority who do
not have computers, now buying a smart phone. This will grow. They may never end up with a
desktop. Even Apple has disconnected a requirement for having a desktop. My parents are
candidates for replacing their laptop with just an iPad. Maybe 1/4 of the friends I have
use a desktop/laptop once a week or less.
Interesting. People I know just using them (tablets) as "toys" to play
some causal games, surf the net & read mails. They go back to there
laptops / desktops to do anything beyond that.
In my experience, that's way more about the interface than anything else.
Take for example a middle schooler - mine uses a laptop. Not because it
runs a desktop OS, not because it runs Fedora, but mainly just because
who on earth wants to write a 5 page essay with an on-screen keyboard.
There's really no reason a tablet device with an attachable keyboard
wouldn't work for her, and the next device she gets might *be* that; the
reason it's a laptop is because it's what we had lying around. (Hooray
for hand me downs!)
Sure, I use a laptop for web browsing because it fits my "open 40 tabs to
read later and then sequentially go through them" model of working better,
but I don't pretend to think that that's a normal mode that people will
move to more of.
Bill
1:20 p.m.
On Thu, Mar 22, 2012 at 6:57 PM, Bill Nottingham <notting(a)redhat.com> wrote:
drago01 (drago01(a)gmail.com) said:
> > The data is noisy but there's a significant minority who do not have
computers, now buying a smart phone. This will grow. They may never end up with a desktop.
Even Apple has disconnected a requirement for having a desktop. My parents are candidates
for replacing their laptop with just an iPad. Maybe 1/4 of the friends I have use a
desktop/laptop once a week or less.
>
> Interesting. People I know just using them (tablets) as "toys" to play
> some causal games, surf the net & read mails. They go back to there
> laptops / desktops to do anything beyond that.
In my experience, that's way more about the interface than anything else.
Take for example a middle schooler - mine uses a laptop. Not because it
runs a desktop OS, not because it runs Fedora, but mainly just because
who on earth wants to write a 5 page essay with an on-screen keyboard.
Which is exactly what I am trying to say as soon as you want to create
content you want a "real device". (keyboard! & interface)
In fact the point of a tablet is the interface which suits specific
use cases very well.
There's really no reason a tablet device with an attachable
keyboard
wouldn't work for her, and the next device she gets might *be* that; the
reason it's a laptop is because it's what we had lying around. (Hooray
for hand me downs!)
Be prepared for complaints then ;)
1:27 p.m.
On Thu, Mar 22, 2012 at 2:20 PM, drago01 <drago01(a)gmail.com> wrote:
Which is exactly what I am trying to say as soon as you want to
create
content you want a "real device". (keyboard! & interface)
Folks! In this mailing list I'd expect people to know: an arch is an
arch is an arch.
Some ARM CPUs will control your fridge, others will be the core SoC in
your laptop, some others in your servers, others in a tablet or ebook
reader.
Form factor != arch.
XO-1.75 is a clamshell laptop, sporting an ARM cpu. 60K units shipping
just to Uy - http://blog.laptop.org/2012/03/16/uruguay-is-first-country-to-get-xo-1-75/
- F14-ARM.
m
--
martin.langhoff(a)gmail.com
martin(a)laptop.org -- Software Architect - OLPC
- ask interesting questions
- don't get distracted with shiny stuff - working code first
- http://wiki.laptop.org/go/User:Martinlanghoff
1:29 p.m.
On Thu, Mar 22, 2012 at 7:27 PM, Martin Langhoff
<martin.langhoff(a)gmail.com> wrote:
On Thu, Mar 22, 2012 at 2:20 PM, drago01 <drago01(a)gmail.com>
wrote:
> Which is exactly what I am trying to say as soon as you want to create
> content you want a "real device". (keyboard! & interface)
Folks! In this mailing list I'd expect people to know: an arch is an
arch is an arch.
Some ARM CPUs will control your fridge, others will be the core SoC in
your laptop, some others in your servers, others in a tablet or ebook
reader.
Form factor != arch.
Oh really? I am shocked ...
No idea why you are addressing this at me ... I was just replying to
the "tablets are taking over the world" posts.
1:38 p.m.
drago01 (drago01(a)gmail.com) said:
> In my experience, that's way more about the interface than
anything else.
>
> Take for example a middle schooler - mine uses a laptop. Not because it
> runs a desktop OS, not because it runs Fedora, but mainly just because
> who on earth wants to write a 5 page essay with an on-screen keyboard.
Which is exactly what I am trying to say as soon as you want to create
content you want a "real device". (keyboard! & interface)
In fact the point of a tablet is the interface which suits specific
use cases very well.
The theoretical 'you' doesn't want a real device, though - they just want a
peripheral to attach to their tablet. (See also: webtop)
Bill
1:32 p.m.
On Thu, 2012-03-22 at 01:57 -0600, Chris Murphy wrote:
Desktop computers are used overwhelmingly for email and web
browsing.
It's total overkill. The desktop computer is a super computer that no
consumer really needs. It's a dying market.
I think you may be, to some extent, over-stating your case here, Chris.
It's a compelling case but not as cut-and-dried as all that, I don't
think.
The mitigating factors are:
a) the desktop market could be considered unlikely to literally _die_.
What may happen instead is it could become much more of a niche - in
fact, very similar to what it was in the 1980s and early 1990s. There
could always be a small amount of people who actually need or want a
desktop computer, and these people could be rather close to the
self-same ones they were in the 1980s and 1990s: people whose use cases
intrinsically depend on large screens, keyboards, and significant whacks
of power.
b) Fedora has never done very well at targeting the kinds of people who
are now using tablets instead of desktop computers. We've actually
always been much stronger among the kinds of people described in a), and
we are to a large extent a project geared towards accommodating the
kinds of people described in a) (let's not kid ourselves, here).
I'm just saying that broad sweeping generalizations about The Market are
well and good, but it's probably a good idea before deploying them to
stop and think about whether they're exactly applicable to the Fedora
project, or if maybe they could use a little modification first.
--
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Twitter: AdamW_Fedora | identi.ca: adamwfedora
http://www.happyassassin.net
3:55 p.m.
On Mar 22, 2012, at 12:32 PM, Adam Williamson wrote:
The mitigating factors are:
a) the desktop market could be considered unlikely to literally _die_.
What may happen instead is it could become much more of a niche - in
fact, very similar to what it was in the 1980s and early 1990s. There
could always be a small amount of people who actually need or want a
desktop computer, and these people could be rather close to the
self-same ones they were in the 1980s and 1990s: people whose use cases
intrinsically depend on large screens, keyboards, and significant whacks
of power.
I use Photoshop, Lightroom, work on multi-gigabyte image files, as do my customers. I
intrinsically depend on a large screen, a keyboard, and occasional whacks of power. I
haven't owned a desktop computer in 6 years.
The desktop form factor will die eventually, although the "desktop user" need
will remain. Whether the need will be met with more powerful tablets and shared resources,
or more efficient form factors that aren't so ugly, power hungry, and space
inefficient - or a combination. We'll have to see. It depends on how much and how fast
that market shrinks, but it will shrink.
I get along just fine without a literal desktop computer, have for 6 years with just
laptops/ I will eventually ditch the laptop also. Just a matter of time. I do own an old
smart phone. I do not own a tablet or pad.
And I'm not unique.
I'm just saying that broad sweeping generalizations about The Market are
well and good, but it's probably a good idea before deploying them to
stop and think about whether they're exactly applicable to the Fedora
project, or if maybe they could use a little modification first.
People's needs, expectations evolve. Even developers, content creators, and geeks.
Surviving projects will survive because they adapt to people's needs. Neither the
market, nor its ideas, will adapt to Fedora.
Chris Murphy
4:04 p.m.
On Thu, 2012-03-22 at 14:55 -0600, Chris Murphy wrote:
On Mar 22, 2012, at 12:32 PM, Adam Williamson wrote:
>
> The mitigating factors are:
>
> a) the desktop market could be considered unlikely to literally _die_.
> What may happen instead is it could become much more of a niche - in
> fact, very similar to what it was in the 1980s and early 1990s. There
> could always be a small amount of people who actually need or want a
> desktop computer, and these people could be rather close to the
> self-same ones they were in the 1980s and 1990s: people whose use cases
> intrinsically depend on large screens, keyboards, and significant whacks
> of power.
I use Photoshop, Lightroom, work on multi-gigabyte image files, as do
my customers. I intrinsically depend on a large screen, a keyboard,
and occasional whacks of power. I haven't owned a desktop computer in
6 years.
The desktop form factor will die eventually, although the "desktop
user" need will remain. Whether the need will be met with more
powerful tablets and shared resources, or more efficient form factors
that aren't so ugly, power hungry, and space inefficient - or a
combination. We'll have to see. It depends on how much and how fast
that market shrinks, but it will shrink.
I get along just fine without a literal desktop computer, have for 6
years with just laptops/ I will eventually ditch the laptop also. Just
a matter of time. I do own an old smart phone. I do not own a tablet
or pad.
And I'm not unique.
Anecdotal data is great, but it's just anecdotal. I tried using a laptop
and no desktop for a year and switched _back_ to a desktop, I found the
faff involved in switching between the two setups too much of a pain.
I'm sure I'm not unique either. =)
I think the form factor vs. arch point is of course important here. The
question of to what extent ARM has the future market for 'devices that
fulfill content creation with powerful systems and chunky peripherals'
sewn up, though, doesn't seem quite as settled as the future market for
tablets and smartphones.
>
> I'm just saying that broad sweeping generalizations about The Market are
> well and good, but it's probably a good idea before deploying them to
> stop and think about whether they're exactly applicable to the Fedora
> project, or if maybe they could use a little modification first.
People's needs, expectations evolve. Even developers, content
creators, and geeks. Surviving projects will survive because they
adapt to people's needs. Neither the market, nor its ideas, will adapt
to Fedora.
I don't believe anything I said above implies any such belief. In fact,
I'm having difficulty seeing how what you wrote is in any way a response
to what I wrote...
--
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Twitter: AdamW_Fedora | identi.ca: adamwfedora
http://www.happyassassin.net
5 p.m.
On Mar 22, 2012, at 3:04 PM, Adam Williamson wrote:
On Thu, 2012-03-22 at 14:55 -0600, Chris Murphy wrote:
> On Mar 22, 2012, at 12:32 PM, Adam Williamson wrote:
>>
>> The mitigating factors are:
>>
>> a) the desktop market could be considered unlikely to literally _die_.
>> What may happen instead is it could become much more of a niche - in
>> fact, very similar to what it was in the 1980s and early 1990s. There
>> could always be a small amount of people who actually need or want a
>> desktop computer, and these people could be rather close to the
>> self-same ones they were in the 1980s and 1990s: people whose use cases
>> intrinsically depend on large screens, keyboards, and significant whacks
>> of power.
>
> I use Photoshop, Lightroom, work on multi-gigabyte image files, as do
> my customers. I intrinsically depend on a large screen, a keyboard,
> and occasional whacks of power. I haven't owned a desktop computer in
> 6 years.
>
> The desktop form factor will die eventually, although the "desktop
> user" need will remain. Whether the need will be met with more
> powerful tablets and shared resources, or more efficient form factors
> that aren't so ugly, power hungry, and space inefficient - or a
> combination. We'll have to see. It depends on how much and how fast
> that market shrinks, but it will shrink.
>
> I get along just fine without a literal desktop computer, have for 6
> years with just laptops/ I will eventually ditch the laptop also. Just
> a matter of time. I do own an old smart phone. I do not own a tablet
> or pad.
>
> And I'm not unique.
Anecdotal data is great, but it's just anecdotal.
I am merely refusing the premise that those who "intrinsically depend on large
screens, keyboards, and significant whacks" need a desktop. Or that it's a recent
phenomenon. And I'm intimating that there is no good reason the trend will end at the
laptop.
Chris Murphy
7:17 p.m.
On 03/22/2012 05:04 PM, Adam Williamson wrote:
I tried using a
laptop and no desktop for a year and switched _back_ to a desktop, I
found the faff involved in switching between the two setups too much
of a pain. I'm sure I'm not unique either. =)
Me too.
Oops. I bet I'm not supposed to send mails like this.
--
Garry Williams
10:46 p.m.
Adam Williamson wrote:
Anecdotal data is great, but it's just anecdotal. I tried using a
laptop
and no desktop for a year and switched back to a desktop, I found the
faff involved in switching between the two setups too much of a pain.
I'm sure I'm not unique either. =)
My desktop is actually older and slower than my notebook. Yet I use the
desktop whenever I'm at home. The form factor is just more convenient.
Similarly, I don't want to replace my 13.3" notebook with a 7-10" tablet or
netbook, even if the performance were the same. 13.3" fits nicely in my
backpack, which fits my needs for mobility.
Kevin Kofler
11:53 p.m.
On Mar 22, 2012, at 9:46 PM, Kevin Kofler wrote:
Adam Williamson wrote:
> Anecdotal data is great, but it's just anecdotal. I tried using a laptop
> and no desktop for a year and switched back to a desktop, I found the
> faff involved in switching between the two setups too much of a pain.
> I'm sure I'm not unique either. =)
My desktop is actually older and slower than my notebook. Yet I use the
desktop whenever I'm at home. The form factor is just more convenient.
Similarly, I don't want to replace my 13.3" notebook with a 7-10" tablet or
netbook, even if the performance were the same. 13.3" fits nicely in my
backpack, which fits my needs for mobility.
I don't understand this.
Form factor is more convenient, how? Exactly?
Chris Murphy
midnight
On Thu, Mar 22, 2012 at 9:46 PM, Kevin Kofler <kevin.kofler(a)chello.at> wrote:
Similarly, I don't want to replace my 13.3" notebook with a
7-10" tablet or
netbook, even if the performance were the same. 13.3" fits nicely in my
backpack, which fits my needs for mobility.
I think this conversation has gone wildly off-topic. I personally
don't care whether your or anyone else prefers a desktop or a notebook
or a tablet or whether it's analogous to the economy of a certain
European country. What I do care about, however, is making sure the
Fedora ARM team has an objective road map for making ARM a primary
arch. May I kindly suggest that we try to stick to the topic at hand,
a move the personal preference discussions to another thread?
--
Jared Smith
2:47 p.m.
On Fri, 23 Mar 2012 04:46:23 +0100
Kevin Kofler <kevin.kofler(a)chello.at> wrote:
My desktop is actually older and slower than my notebook. Yet I use
the
desktop whenever I'm at home. The form factor is just more convenient.
That's just what you personally prefer. I quit using desktops back
in 2001, because laptop form factor "is just more convenient" for me.
Let's not mistake personal perceptions for the whole picture.
-- Pete
12:46 p.m.
On 03/22/2012 12:23 AM, drago01 wrote:
While I agree that we will see more smartphones and tablets in the
future the people that actually replace there traditional computers
with tablets or even smartphones are near zero.
Sells do not really tell the whole story as many people simply don't
have a need to buy new laptops/desktops because what they have is
"good enough" so they spend there money on other gadgets.
I don't believe phones and tablets are going to completely usurp desktop
computers, but if Fedora doesn't offer a path for people whose primary
"computer" is a cell phone or tablet, we lose out on the next generation
of developers and end users. That's a sure way to irrelevance.
Then again, all this is beside the point: We're targeting ARM servers in
the proposal. The groundwork we lay with ARM servers will also lead to
Fedora's ability to support mobile devices including ARM laptops,
tablets, and phones. But it's a much longer journey to run Fedora on a
phone than it's going to be to run it on a server.
--
Brendan Conoboy / Red Hat, Inc. / blc(a)redhat.com
11:03 p.m.
On Thu, 2012-03-22 at 03:00 +0100, Kevin Kofler wrote:
Peter Robinson wrote:
> Exactly! Ultimately what we need is FESCo to document what are the
> requirements of being promoted to a primary architecture and then it's
> the ARM SIGs job of ensuring they adhere to the requirements, provide
> viable workable alternatives that are acceptable to FESCo, or provide
> proof that the requirement will be met within an agreed time frame.
ARM should most definitely NOT be approved as a primary architecture before
all the requirements are actually met!
We have seen what happened when the EU took Greece's word on the promise
that they'd eventually meet the Maastricht criteria. Let's not do the same
mistake in Fedora!
You heard it here first, folks: the next economic crisis will be caused
by ARM as a primary arch.
:rolleyes:
--
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Twitter: AdamW_Fedora | identi.ca: adamwfedora
http://www.happyassassin.net
4:06 a.m.
On 03/22/2012 02:00 AM, Kevin Kofler wrote:
Peter Robinson wrote:
> > Exactly! Ultimately what we need is FESCo to document what are the
> > requirements of being promoted to a primary architecture and then it's
> > the ARM SIGs job of ensuring they adhere to the requirements, provide
> > viable workable alternatives that are acceptable to FESCo, or provide
> > proof that the requirement will be met within an agreed time frame.
ARM should most definitely NOT be approved as a primary architecture
before
all the requirements are actually met!
Hold on, these requirements are something you just made up to suit
your argument.
Andrew.
12:39 p.m.
On Tue, 20 Mar 2012 11:52:29 -0400
Peter Jones <pjones(a)redhat.com> wrote:
6) supported platforms must be fully integrated into building and
installation.
Apropos that, what are the supported platforms right now?
From what I know about the Fedora on ARM, they use a rather scary
looking pile of development boards with very poor I/O.
I'd like to know if you can make a suggestion like "if you want to
hack on Fedora on ARM, buy Dell XXX or Archos YYY", and then we're
all more or less on the same page for next 2 years at least.
Or it doesn't work like that in the ARM world?
-- Pete
1:01 p.m.
From what I know about the Fedora on ARM,
Please check your "what you know" against the current situtation, it's
very easy to let obsolete impressions carry forth, but they're no
longer applicable.
they use a rather scary looking pile of development boards with very
poor I/O.
Buy a trimslice and run it with iSCSI. It's a very clean package, and
I can get 80 MB/sec to my file server's disks. That is neither
"scary" nor "poor I/O".
http://www.delorie.com/arm/trimslice/iscsi.html
3 p.m.
Glad it works for you, but I need a real system, like a Netwinder.
So buy a trimslice and use the internal SSD or sata disk. The
trimslice has everything the netwinder has (and more), and uses half
the power.
http://trimslice.com/web/
7:24 p.m.
DJ Delorie wrote:
So buy a trimslice and use the internal SSD or sata disk. The
trimslice has everything the netwinder has (and more), and uses half
the power.
http://trimslice.com/web/
"Trim-Slice is the first desktop computer powered by NVIDIA Tegra 2."
i.e., by buying a Trimslice, you give money to The Enemy!
Kevin Kofler
2:47 a.m.
On Sat, 2012-03-24 at 05:30 +0100, Kevin Kofler wrote:
DJ Delorie wrote:
> What a horrible thing to say about a company that's put a lot of
> effort into supporting their products on Free Software platforms!
I think the Nouveau developers have a different story to tell you there.
You might consider that nouveau has support (basic modesetting, but
support) for NVIDIA's new GPU on release day. And then think about
exactly how that's possible, for a minute. Then re-consider whether you
want to put words into the nouveau developers' mouths...
--
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Twitter: AdamW_Fedora | identi.ca: adamwfedora
http://www.happyassassin.net
7:42 p.m.
On 23 March 2012 18:24, Kevin Kofler <kevin.kofler(a)chello.at> wrote:
DJ Delorie wrote:
> So buy a trimslice and use the internal SSD or sata disk. The
> trimslice has everything the netwinder has (and more), and uses half
> the power.
>
> http://trimslice.com/web/
"Trim-Slice is the first desktop computer powered by NVIDIA Tegra 2."
i.e., by buying a Trimslice, you give money to The Enemy!
Kevin Kofler
Kevin,
this is my only reply to your emails. Your emails have become highly
disruptive, annoying and are turning off more people than helping them
see your point of view. Please slow down as it is only making you more
people ignore you all the time than listen.
--
Stephen J Smoogen.
"The core skill of innovators is error recovery, not failure avoidance."
Randy Nelson, President of Pixar University.
"Years ago my mother used to say to me,... Elwood, you must be oh
so smart or oh so pleasant. Well, for years I was smart. I
recommend pleasant. You may quote me." —James Stewart as Elwood P. Dowd
7:44 p.m.
On Sat, Mar 24, 2012 at 12:24 AM, Kevin Kofler <kevin.kofler(a)chello.at> wrote:
DJ Delorie wrote:
> So buy a trimslice and use the internal SSD or sata disk. The
> trimslice has everything the netwinder has (and more), and uses half
> the power.
>
> http://trimslice.com/web/
"Trim-Slice is the first desktop computer powered by NVIDIA Tegra 2."
i.e., by buying a Trimslice, you give money to The Enemy!
Oh Kevin please.... if that is the best you can do to argue your
point against ARM would please just not say anything. It's completely
unnecessary, completely off topic and doesn't do anything to help your
cause. After all they've just joined the linux foundation [1] so
apparently they're not the Enemy any more.
[1] http://www.tomshardware.com/news/nvidia-linux-gpu-fluendo-lineo,14936.html
3:50 p.m.
On Fri, Mar 23, 2012 at 3:50 PM, Pete Zaitcev <zaitcev(a)redhat.com> wrote:
> Buy a trimslice and run it with iSCSI.
This is not good enough for me to become involved with Fedora on ARM.
Glad it works for you, but I need a real system, like a Netwinder.
Whatever floats your boat! ARM SoCs are available in every popular form factor.
This whole thread about desktops vs tablets vs laptops has been highly
entertaining... now I know what every developer personally favours and
hates, as well as many of their immediate families. This a matter
which has kept many of us awake for long nights.
It unfortunately shed no light on the ARM topic, because, well,
there's ARM SoCs in all those form factors.
cheers,
martin "just kidding" langhoff
--
martin.langhoff(a)gmail.com
martin(a)laptop.org -- Software Architect - OLPC
- ask interesting questions
- don't get distracted with shiny stuff - working code first
- http://wiki.laptop.org/go/User:Martinlanghoff
5:02 p.m.
On Fri, Mar 23, 2012 at 04:50:38PM -0400, Martin Langhoff wrote:
On Fri, Mar 23, 2012 at 3:50 PM, Pete Zaitcev
<zaitcev(a)redhat.com> wrote:
>> Buy a trimslice and run it with iSCSI.
>
> This is not good enough for me to become involved with Fedora on ARM.
> Glad it works for you, but I need a real system, like a Netwinder.
Whatever floats your boat! ARM SoCs are available in every popular form factor.
This whole thread about desktops vs tablets vs laptops has been highly
entertaining... now I know what every developer personally favours and
hates, as well as many of their immediate families. This a matter
which has kept many of us awake for long nights.
It unfortunately shed no light on the ARM topic, because, well,
there's ARM SoCs in all those form factors.
Except the x86-64 high performance single threaded class :-)
Rich.
--
Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones
virt-top is 'top' for virtual machines. Tiny program with many
powerful monitoring features, net stats, disk stats, logging, etc.
http://et.redhat.com/~rjones/virt-top
6:09 p.m.
On Fri, 23 Mar 2012 22:02:37 +0000
"Richard W.M. Jones" <rjones(a)redhat.com> wrote:
> It unfortunately shed no light on the ARM topic, because, well,
> there's ARM SoCs in all those form factors.
Except the x86-64 high performance single threaded class :-)
Rich, check this out -
http://summit.openstack.org/sessions/view/40
-- P
5:05 p.m.
On Fri, Mar 23, 2012 at 7:50 PM, Pete Zaitcev <zaitcev(a)redhat.com> wrote:
On Thu, 22 Mar 2012 14:01:27 -0400
DJ Delorie <dj(a)redhat.com> wrote:
> Buy a trimslice and run it with iSCSI.
This is not good enough for me to become involved with Fedora on ARM.
Glad it works for you, but I need a real system, like a Netwinder.
Trimslice has options of SSD or HDD as well so it would be no less of
a real machine like a netwinder.
http://trimslice.com/web/models
Peter
6:12 p.m.
On Fri, 23 Mar 2012 22:05:39 +0000
Peter Robinson <pbrobinson(a)gmail.com> wrote:
Trimslice has options of SSD or HDD as well so it would be no less
of
a real machine like a netwinder.
http://trimslice.com/web/models
So I see, thanks. DJ's original suggestion was too forceful in insisting
on iSCSI. I also received a word from colleague in town that he's going
to tinker with Trimslice Pro.
-- Pete
6:17 p.m.
On Fri, Mar 23, 2012 at 11:12 PM, Pete Zaitcev <zaitcev(a)redhat.com> wrote:
On Fri, 23 Mar 2012 22:05:39 +0000
Peter Robinson <pbrobinson(a)gmail.com> wrote:
> Trimslice has options of SSD or HDD as well so it would be no less of
> a real machine like a netwinder.
>
> http://trimslice.com/web/models
So I see, thanks. DJ's original suggestion was too forceful in insisting
on iSCSI. I also received a word from colleague in town that he's going
to tinker with Trimslice Pro.
Yep, it's not just x86 users that are stuck in their weird and
wonderful ways :-D
Pete
6:18 p.m.
So I see, thanks. DJ's original suggestion was too forceful in
insisting
on iSCSI.
Sorry, I'm a big fan of iSCSI on trimslices. The SATA interface is on
USB but the gigE isn't, so network (iscsi) is about 3x faster than a
local disk, if you have a big raid server on the other end.
I have two trimslices; one has an internal 250 GB sata disk (it's a
public web/git server running F15) and the other is diskless iSCSI for
faster builds.
9:09 a.m.
On 03/23/2012 11:18 PM, DJ Delorie wrote:
Sorry, I'm a big fan of iSCSI on trimslices. The SATA interface
is on
USB but the gigE isn't, so network (iscsi) is about 3x faster than a
local disk, if you have a big raid server on the other end.
I'd love to know how to do this. I've never used iSCSI.
Andrew.
9:10 a.m.
On 03/26/2012 03:09 PM, Andrew Haley wrote:
I'd love to know how to do this. I've never used iSCSI.
Sorry, I missed http://www.delorie.com/arm/trimslice/iscsi.html
Andrew.
6:28 p.m.
DJ Delorie<dj(a)redhat.com> wrote:
Buy a trimslice and run it with iSCSI.
Pete Zaitcev wrote:
This is not good enough for me to become involved with Fedora on
ARM.
Glad it works for you, but I need a real system, like a Netwinder.
You did see that there's a "Trimslice H" model that can accomodate a
2.5" HD or SSD, right?
Or is there something else missing the Netwinder had that the Trimslice
is missing?
3:41 a.m.
Hi,
> they use a rather scary looking pile of development boards with
very
> poor I/O.
Buy a trimslice and run it with iSCSI. It's a very clean package, and
I can get 80 MB/sec to my file server's disks. That is neither
"scary" nor "poor I/O".
http://www.delorie.com/arm/trimslice/iscsi.html
Running the thing on iscsi is a good idea, given that local storage is
linked up via usb while gb ethernet is hooked up via pcie.
Any particular reason why you boot the thing via tftp? I'd expect just
having /boot on the sd card (which you need for boot anyway) is easier,
especially when it comes to kernel updates.
cheers,
Gerd
4 a.m.
On Mon, Mar 26, 2012 at 9:41 AM, Gerd Hoffmann <kraxel(a)redhat.com> wrote:
Hi,
>> they use a rather scary looking pile of development boards with very
>> poor I/O.
>
> Buy a trimslice and run it with iSCSI. It's a very clean package, and
> I can get 80 MB/sec to my file server's disks. That is neither
> "scary" nor "poor I/O".
>
> http://www.delorie.com/arm/trimslice/iscsi.html
Running the thing on iscsi is a good idea, given that local storage is
linked up via usb while gb ethernet is hooked up via pcie.
Any particular reason why you boot the thing via tftp? I'd expect just
having /boot on the sd card (which you need for boot anyway) is easier,
especially when it comes to kernel updates.
Everything needed to boot goes into the initrd now days so you don't
even need the SD card.
Peter
5:26 a.m.
On 03/26/12 11:00, Peter Robinson wrote:
On Mon, Mar 26, 2012 at 9:41 AM, Gerd Hoffmann
<kraxel(a)redhat.com> wrote:
> Hi,
>
>>> they use a rather scary looking pile of development boards with very
>>> poor I/O.
>>
>> Buy a trimslice and run it with iSCSI. It's a very clean package, and
>> I can get 80 MB/sec to my file server's disks. That is neither
>> "scary" nor "poor I/O".
>>
>> http://www.delorie.com/arm/trimslice/iscsi.html
>
> Running the thing on iscsi is a good idea, given that local storage is
> linked up via usb while gb ethernet is hooked up via pcie.
>
> Any particular reason why you boot the thing via tftp? I'd expect just
> having /boot on the sd card (which you need for boot anyway) is easier,
> especially when it comes to kernel updates.
Everything needed to boot goes into the initrd now days so you don't
even need the SD card.
Check the URL above. The setup described there uses a sdcard with a
u-boot script, which kicks off the tftp boot.
I don't see the point in using tftp, you can place kernel+initrd
directly at the sdcard if you have one anyway.
Another possible way would be to boot directly from iscsi like you can
do on x86 with an sanboot-enabled iPXE rom. I have no idea whenever
u-boot can handle that though.
cheers,
Gerd
7 a.m.
On Mon, Mar 26, 2012 at 12:26:47PM +0200, Gerd Hoffmann wrote:
Another possible way would be to boot directly from iscsi like you
can
do on x86 with an sanboot-enabled iPXE rom. I have no idea whenever
u-boot can handle that though.
No. The U-boot supplied on the Trim-Slice is very simplistic in the
way it boots: It looks for a compiled script called "boot.scr" in four
possible local storage locations. The script can then boot over the
network, but you've got to have the script in a local location in the
first place.
http://www.trimslice.com/wiki/index.php/Trim-Slice_U-Boot
[You could also patch U-boot. It's apparently stored in some
on-motherboard serial flash memory.]
Which leads me to a rant about ARM. Grrrr RANT!! I didn't think I'd
ever love the BIOS, but compared to the alternatives (UEFI and a
million different ARM bootloaders) it's simple and effective.
Rich.
--
Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones
Read my programming blog: http://rwmj.wordpress.com
Fedora now supports 80 OCaml packages (the OPEN alternative to F#)
http://cocan.org/getting_started_with_ocaml_on_red_hat_and_fedora
12:37 p.m.
Which leads me to a rant about ARM. Grrrr RANT!! I didn't
think
I'd ever love the BIOS, but compared to the alternatives (UEFI and a
million different ARM bootloaders) it's simple and effective.
This is getting way off-topic, but... most linux-capable ARM chips
support a BIOS in the "pc" sense. Vendors choose not to do it that
way.
2:24 p.m.
On Mon, Mar 26, 2012 at 01:37:39PM -0400, DJ Delorie wrote:
> Which leads me to a rant about ARM. Grrrr RANT!! I didn't think
> I'd ever love the BIOS, but compared to the alternatives (UEFI and a
> million different ARM bootloaders) it's simple and effective.
This is getting way off-topic, but... most linux-capable ARM chips
support a BIOS in the "pc" sense. Vendors choose not to do it that
way.
Given that the "pc" sense of BIOS includes having arguments returned in
x86 registers, I really don't think that's true.
--
Matthew Garrett | mjg59(a)srcf.ucam.org
2:32 p.m.
Given that the "pc" sense of BIOS includes having arguments
returned in
x86 registers, I really don't think that's true.
ARM has registers too...
My point is, the ARM chips *do* support an on-board flash bootloader,
and there's no reason why that bootloader couldn't export a standard
ABI that uses interrupts and register passing, and boot off a standard
attached disk...
... but that's not what the vendors do.
4:10 p.m.
On Mon, Mar 26, 2012 at 03:32:15PM -0400, DJ Delorie wrote:
> Given that the "pc" sense of BIOS includes having arguments returned in
> x86 registers, I really don't think that's true.
ARM has registers too...
My point is, the ARM chips *do* support an on-board flash bootloader,
and there's no reason why that bootloader couldn't export a standard
ABI that uses interrupts and register passing, and boot off a standard
attached disk...
I think you misunderstood Richard. ARM hardware is moving towards
adopting UEFI as the standard firmware interface, which is BIOS-like in
the sense that you're describing. Richard was explicitly talking about
BIOS-as-in-x86-asm-and-int-calls being preferable to UEFI. There's no
real way ARM could implement the latter.
--
Matthew Garrett | mjg59(a)srcf.ucam.org
6:23 p.m.
On 03/26/2012 08:00 AM, Richard W.M. Jones wrote:
Which leads me to a rant about ARM. Grrrr RANT!! I didn't think
I'd
ever love the BIOS, but compared to the alternatives (UEFI and a
million different ARM bootloaders) it's simple and effective.
There is some truth to that. Nobody is going to stand up and say that
the 32-bit ARM "zoo" (as I have called it on a number of occasions) is a
situation today. This is a case where strong leadership and aggressive
standardization is required in order to have *one* platform. That work
is ongoing at the moment, and in the interim, we live with slightly more
pain than would be ideal. But therein lies the fun ;)
In the future, ARM systems will transition increasingly to UEFI. Many
ARM server systems will likely eventually boot with ACPI as well. They
will smell like low-energy alternatives to PC servers over time, and in
another decade or two something more exciting than UEFI will replace
UEFI and folks will mail about how things were better with UEFI!
Jon.
7:28 p.m.
On Mar 28, 2012, at 5:23 PM, Jon Masters wrote:
They
will smell like low-energy alternatives to PC servers over time, and in
another decade or two something more exciting than UEFI will replace
UEFI and folks will mail about how things were better with UEFI!
Well, it's not often I momentarily consider blowing my brains out. That did it
though.
Chris Murphy
8 p.m.
On Wed, 2012-03-28 at 18:28 -0600, Chris Murphy wrote:
On Mar 28, 2012, at 5:23 PM, Jon Masters wrote:
> They
> will smell like low-energy alternatives to PC servers over time, and in
> another decade or two something more exciting than UEFI will replace
> UEFI and folks will mail about how things were better with UEFI!
Well, it's not often I momentarily consider blowing my brains out. That did it
though.
The Fedora QA and anaconda teams are deeply familiar with such feelings,
and prescribe gin.
--
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Twitter: AdamW_Fedora | identi.ca: adamwfedora
http://www.happyassassin.net
8:13 p.m.
On Wed, Mar 28, 2012 at 07:23:48PM -0400, Jon Masters wrote:
In the future, ARM systems will transition increasingly to UEFI.
Many
ARM server systems will likely eventually boot with ACPI as well. They
will smell like low-energy alternatives to PC servers over time, and in
another decade or two something more exciting than UEFI will replace
UEFI and folks will mail about how things were better with UEFI!
Oh no. Nobody's seriously considering UEFI ARM platforms without ACPI,
are they?
--
Matthew Garrett | mjg59(a)srcf.ucam.org
8:20 p.m.
On 28 March 2012 19:13, Matthew Garrett <mjg59(a)srcf.ucam.org> wrote:
On Wed, Mar 28, 2012 at 07:23:48PM -0400, Jon Masters wrote:
> In the future, ARM systems will transition increasingly to UEFI. Many
> ARM server systems will likely eventually boot with ACPI as well. They
> will smell like low-energy alternatives to PC servers over time, and in
> another decade or two something more exciting than UEFI will replace
> UEFI and folks will mail about how things were better with UEFI!
Oh no. Nobody's seriously considering UEFI ARM platforms without ACPI,
are they?
Somewhere in Northumberland in secret bunker deep below the surface....
Developer 1: What can we do to break this Matthew?
Developer 2: I don't know we tried BIOS settings, we tried ACPI and we
tried UEFI. This man is unbreakable.
Developer 3: Have we tried ARM UEFI without ACPI?
{fade out to cackling evil laughter.. as it is revealed that Developer
3 is Alan Cox}
--
Stephen J Smoogen.
"The core skill of innovators is error recovery, not failure avoidance."
Randy Nelson, President of Pixar University.
"Years ago my mother used to say to me,... Elwood, you must be oh
so smart or oh so pleasant. Well, for years I was smart. I
recommend pleasant. You may quote me." —James Stewart as Elwood P. Dowd
9:27 p.m.
On 03/28/2012 06:13 PM, Matthew Garrett wrote:
On Wed, Mar 28, 2012 at 07:23:48PM -0400, Jon Masters wrote:
> In the future, ARM systems will transition increasingly to UEFI. Many
> ARM server systems will likely eventually boot with ACPI as well. They
> will smell like low-energy alternatives to PC servers over time, and in
> another decade or two something more exciting than UEFI will replace
> UEFI and folks will mail about how things were better with UEFI!
Oh no. Nobody's seriously considering UEFI ARM platforms without ACPI,
are they?
Wait, I thought there was some kind of "flattened device tree" or
something that the ARM folks thought would let them avoid ACPI. Did that
not pan out? Maybe MS put the kibosh on it?
-- Andy
9:42 p.m.
On 03/28/2012 07:27 PM, Andy Grover wrote:
Wait, I thought there was some kind of "flattened device
tree" or
something that the ARM folks thought would let them avoid ACPI. Did that
not pan out? Maybe MS put the kibosh on it?
In the long run you're likely to see FDT for mobile devices and UEFI for
servers. Jon's prognostications are regarding the long view (years).
--
Brendan Conoboy / Red Hat, Inc. / blc(a)redhat.com
10 p.m.
On Wed, Mar 28, 2012 at 07:42:59PM -0700, Brendan Conoboy wrote:
On 03/28/2012 07:27 PM, Andy Grover wrote:
>Wait, I thought there was some kind of "flattened device tree" or
>something that the ARM folks thought would let them avoid ACPI. Did that
>not pan out? Maybe MS put the kibosh on it?
In the long run you're likely to see FDT for mobile devices and UEFI
for servers. Jon's prognostications are regarding the long view
(years).
In the short term you're going to be seeing UEFI/ACPI for any hardware
that's intended to run Windows, so I suspect that's going to spread
fairly quickly unless vendors want to produce multiple firmware
implementations for otherwise similar hardware.
--
Matthew Garrett | mjg59(a)srcf.ucam.org
9:57 p.m.
On Wed, Mar 28, 2012 at 07:27:13PM -0700, Andy Grover wrote:
On 03/28/2012 06:13 PM, Matthew Garrett wrote:
> Oh no. Nobody's seriously considering UEFI ARM platforms without ACPI,
> are they?
Wait, I thought there was some kind of "flattened device tree" or
something that the ARM folks thought would let them avoid ACPI. Did that
not pan out? Maybe MS put the kibosh on it?
I'd been under the impression that flattened device tree was a migratory
path before systems adopted UEFI/ACPI. UEFI doesn't have its own device
tree and so relies on the platform to provide one - in theory that could
be something that looks like the Linux device tree spec, but there's no
description of how to express that in UEFI at present.
--
Matthew Garrett | mjg59(a)srcf.ucam.org
12:28 p.m.
Any particular reason why you boot the thing via tftp? I'd
expect
just having /boot on the sd card (which you need for boot anyway) is
easier, especially when it comes to kernel updates.
I wanted the minimum on the sdcard (it just has the tftboot script)
because our build farm only has one local person, and he's not always
there. With everything on the server, we can swap everything out,
power cycle it, and be done.
Remember, the iscsi volumes can be mounted on your regular desktop if
needed, to "fix" the image before booting the trimslice.
Plus, my way can use ancient tiny sdcards without worrying about space
or performance.
4412
days inactive
4421
days old
170 comments
37 participants
participants (37)
-
Adam Jackson -
Adam Williamson -
Andrew Haley -
Andy Grover -
Bill Nottingham -
Brendan Conoboy -
Chris Murphy -
Chris Tyler -
Dennis Gilmore -
DJ Delorie -
drago01 -
elison.niven＠gmail.com -
Eric Smith -
Garry Williams -
Gerd Hoffmann -
Jared K. Smith -
Jaroslav Reznik -
Jesse Keating -
Jesse Keating -
Jon Ciesla -
Jon Masters -
Josh Boyer -
Kevin Kofler -
Martin Langhoff -
Matthew Garrett -
Matthew Garrett -
Michael Cronenworth -
Nicolas Mailhot -
Nikos Roussos -
Pete Zaitcev -
Peter Jones -
Peter Robinson -
Przemek Klosowski -
Richard W.M. Jones -
Stephen John Smoogen -
Tom Lane -
Tomas Mraz