Hi Guys,
Thanks Manuel for stepping up and offering to help with the i586 work. I know that we had already done some work on this a long time back, Daniel doing most of the heavy lifting at the time.
Afaik, Daniel has been busy with RealLife [tm] issues, so I am not sure if he wants to stay as the centos-devel as point man for this project. If not, I will step in and get involved.
He did, however, ask a very important question - is there enough traction in the i586 world today to even consider the i586 port worthwhile ? Since most major platforms really are i686 ? I'd still like to see some answers to that question!
I do have some old i586 stuff ( things that came out from a LaCie 1U storage box Via C3, 500Mhz ) and a AMD K6-2 550Mhz Compaq Laptop from years gone by. Both of these can be made available if people want something central to test on / test with. Beyond that, we can make some builder threads available and if required a dedicated project on projects.centos.org with svn / trac and issue tracking.
On Sat, Apr 5, 2008 at 1:43 PM, Karanbir Singh mail-lists@karan.org wrote:
Thanks Manuel for stepping up and offering to help with the i586 work. I know that we had already done some work on this a long time back, Daniel doing most of the heavy lifting at the time.
Afaik, Daniel has been busy with RealLife [tm] issues, so I am not sure if he wants to stay as the centos-devel as point man for this project. If not, I will step in and get involved.
I currently don't have the time to lead such effort. But, I am willing to look into the Anaconda issues, provided that there is enough interest in a i586 or i686 sans cmov "port".
He did, however, ask a very important question - is there enough traction in the i586 world today to even consider the i586 port worthwhile ? Since most major platforms really are i686 ? I'd still like to see some answers to that question!
FWIW: as far as I recall, we only tested the previous changes on i686 without cmov (VIA and an altered version of qemu). i586 may be even a step further. Two other considerations:
1. Current VIA CPUs do support cmov. 2. Most i586 machines will probably have little memory, and are better served by CentOS-4.
So, IMHO someone needs to make a good case. Three users are probably not really interesting, if someone is developing a (embedded) device that happens to run a i586-class CPU on CentOS, it gets interesting. So, speak up :). (Of course, this only reflects my views on i586 support!)
-- Daniel
Daniel de Kok wrote:
On Sat, Apr 5, 2008 at 1:43 PM, Karanbir Singh mail-lists@karan.org wrote:
Thanks Manuel for stepping up and offering to help with the i586 work. I know that we had already done some work on this a long time back, Daniel doing most of the heavy lifting at the time.
Afaik, Daniel has been busy with RealLife [tm] issues, so I am not sure if he wants to stay as the centos-devel as point man for this project. If not, I will step in and get involved.
I currently don't have the time to lead such effort. But, I am willing to look into the Anaconda issues, provided that there is enough interest in a i586 or i686 sans cmov "port".
He did, however, ask a very important question - is there enough traction in the i586 world today to even consider the i586 port worthwhile ? Since most major platforms really are i686 ? I'd still like to see some answers to that question!
FWIW: as far as I recall, we only tested the previous changes on i686 without cmov (VIA and an altered version of qemu). i586 may be even a step further. Two other considerations:
- Current VIA CPUs do support cmov.
- Most i586 machines will probably have little memory, and are better
served by CentOS-4.
So, IMHO someone needs to make a good case. Three users are probably not really interesting, if someone is developing a (embedded) device that happens to run a i586-class CPU on CentOS, it gets interesting. So, speak up :). (Of course, this only reflects my views on i586 support!)
I fully agree with this ... CentOS-5 has very large memory requirements to do anything useful (at least 256mb .. probably need more to do anything GUI).
I do understand that there are some devices out there that do not support i686 ... but there are also risc chips and ARM and Cell and (well, you get the picture).
Even most of the VIA chips (newer models) run with i686.
So, unless there is a large demand that I don't see (and more on the horizon, not less) then I don't see a need for developing this.
I could be wrong, so if someone knows something I don't then please speak up :D
Thanks, Johnny Hughes
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
Karanbir Singh wrote:
| He did, however, ask a very important question - is there enough | traction in the i586 world today to even consider the i586 port | worthwhile ? Since most major platforms really are i686 ? I'd still like | to see some answers to that question! | | I do have some old i586 stuff ( things that came out from a LaCie 1U | storage box Via C3, 500Mhz ) and a AMD K6-2 550Mhz Compaq Laptop from | years gone by. Both of these can be made available if people want | something central to test on / test with. Beyond that, we can make some | builder threads available and if required a dedicated project on | projects.centos.org with svn / trac and issue tracking.
What real life samples are there of hardware that need i586 support? Is it just older hardware or is there newer hardware that would benefit from i586 support? Do other restrictions apply? Memory constraints, disk limitations, specific installation requirements, .....?
Hugo.
- -- hvdkooij@vanderkooij.org http://hugo.vanderkooij.org/ PGP/GPG? Use: http://hugo.vanderkooij.org/0x58F19981.asc
A: Yes. >Q: Are you sure? >>A: Because it reverses the logical flow of conversation. >>>Q: Why is top posting frowned upon?
Bored? Click on http://spamornot.org/ and rate those images.
Hugo van der Kooij wrote:
| He did, however, ask a very important question - is there enough | traction in the i586 world today to even consider the i586 port | worthwhile ? Since most major platforms really are i686 ? I'd still like | to see some answers to that question!
What real life samples are there of hardware that need i586 support? Is it just older hardware or is there newer hardware that would benefit from i586 support? Do other restrictions apply? Memory constraints, disk
All good questions, and I'd like to hear some answers to that just as much as you do.
Karanbir Singh wrote:
Hugo van der Kooij wrote:
| He did, however, ask a very important question - is there enough | traction in the i586 world today to even consider the i586 port | worthwhile ? Since most major platforms really are i686 ? I'd still like | to see some answers to that question!
What real life samples are there of hardware that need i586 support? Is it just older hardware or is there newer hardware that would benefit from i586 support? Do other restrictions apply? Memory constraints, disk
All good questions, and I'd like to hear some answers to that just as much as you do.
Equally relevant is whether 5.x is a necessity on such hardware. If I had any left I'd probably prefer to run the more lightweight 2.4 kernel in CentOS 3.x at least until the end of its supported life.
Les Mikesell wrote:
Equally relevant is whether 5.x is a necessity on such hardware. If I had any left I'd probably prefer to run the more lightweight 2.4 kernel in CentOS 3.x at least until the end of its supported life.
That is true, essentially what Johnny said as well in his email earlier in this thread.
The extra memory requirements for the yum based installer itself have made it hard to use anything except nfs installs on machines with < 256 megs of ram.
What real life samples are there of hardware that need i586 support? Is it just older hardware or is there newer hardware that would benefit from i586 support? Do other restrictions apply? Memory constraints, disk limitations, specific installation requirements, .....?
Hugo.
I think it is "newer" hardware also. Newer, as defined by still currently being actively sold (Geode).
The problem is that the information we require to make a decision is very hard to come by. No processor manufacture AFAIAW states "this is an i586/i686 class processor" the simply place the CPU on the market and let the community deal with it. Further to this the community then interprets information incorrectly, as in case with the CMOV instruction and the via EPIA board.
"The GNU compiler people have assumed that all 686's implement cmov's, so code compiled for the i686 architecture may not execute on the C3. Code generated by GCC does not check for these optional features as the intel documentation says you should"
http://radagast.bglug.ca/epia/epia_howto/x1099.html
Also some of Intel's own chips suffer from a problem with PAE instruction that certain distro's run into.
http://en.wikipedia.org/wiki/Pentium_M#Dothan
but this is probably failing away from the issue of i586 to more issues with current i686.
I believe that there are now only 3 manufactures producing x86 chips, Intel, AMD and VIA.
Via chips up to and including the Ezra core have the CMOV issues. AMD Geode chips appear to be i586, some ultra portable/ low power laptop appear to be using this chip (OLPC among others) Intel is still selling i586 class ships for embedded.
There is no reason why most of these can't have decent RAM and or hard disks these are current and not recently out of production of which there may still be a still significant amount.
Overall not everyone can run i686 for whatever reason. The fact remains IMO that there is still a fair amount of need for an i586 image regardless of it it's for fall back issues or run natively I also believe that this isn't catered for by Centos 4 with support that run's out in ~4 years.
Manuel
On 07/04/2008, Manuel Tuthill Manuel@nebula-it.co.uk wrote:
Overall not everyone can run i686 for whatever reason. The fact remains IMO that there is still a fair amount of need for an i586 image regardless of it it's for fall back issues or run natively I also believe that this isn't catered for by Centos 4 with support that run's out in ~4 years.
But surely we should not forget the basic essential of the CentOS Project - it's equivalence to Upstream's EL. If Upstream support an i586 in their EL 5 then, yes, CentOS should.
Manuel has put forward a valid argument for CentOS 5 i586 support but it should not be at the detriment of the CentOS Project's core ethos. Perhaps i586 support could be provided as an offshoot (which, given time, will become a dead-end). Support which Manuel, and like minded persons, could provide (under the watchful eye of one of the core developers) perhaps?
Alan.
Hi Alan,
Alan Bartlett wrote:
Overall not everyone can run i686 for whatever reason. The fact remains IMO that there is still a fair amount of need for an i586 image regardless of it it's for fall back issues or run natively I also believe that this isn't catered for by Centos 4 with support that run's out in ~4 years.But surely we should not forget the basic essential of the CentOS Project - it's equivalence to Upstream's EL. If Upstream support an i586 in their EL 5 then, yes, CentOS should.
I very strongly disagree with that statement. We do lots of things that upstream dont - and there is no reason why we cant expand on that. After all CentOS is not driven by a commercial end game ( as upstream is ), were doing things here that we want to, as a community.
Also, there was no i586 support in EL4, there is in CentOS-4. Iirc, EL3/CentOS3 have the same relationship.
Besides you just completely marginalised the work done for things like the LiveCD, ServerCD's, the entire Plus and Extra repos etc.
As the core distribution - sure, the plan is to stick as close to upstream as is possible, legal and acceptable. However, the centos community is just that - a community of people. If there are things that people want to take up, nothing stops them from doing that. The very last argument in the stack should be 'because upstream does not do this, so we wont either'.
Perhaps i586 support could be provided as an offshoot (which, given time, will become a dead-end). Support which Manuel, and like minded persons, could provide (under the watchful eye of one of the core developers) perhaps?
i586 support on CentOS5 was always meant to be an 'alternative' install mechanism.
Karanbir Singh wrote:
Hi Alan,
Alan Bartlett wrote:
Overall not everyone can run i686 for whatever reason. The fact remains IMO that there is still a fair amount of need for an i586 image regardless of it it's for fall back issues or run natively I also believe that thisisn't catered for by Centos 4 with support that run's out in ~4 years.
But surely we should not forget the basic essential of the CentOS Project - it's equivalence to Upstream's EL. If Upstream support an i586 in their EL 5 then, yes, CentOS should.
I very strongly disagree with that statement. We do lots of things that upstream dont - and there is no reason why we cant expand on that. After all CentOS is not driven by a commercial end game ( as upstream is ), were doing things here that we want to, as a community.
Actually ... I don't personally see it as that at all. We still want to minimize changes and i think Alan's comments are correct.
Also, there was no i586 support in EL4, there is in CentOS-4. Iirc, EL3/CentOS3 have the same relationship.
Right, and we may do it, however if we do it, it will be because there is a growing market and it has no impact on the i686 distro.
And the act of modifying anaconda in that way DOES go against what CentOS main goal is (a perfect rebuild of sources).
That doesn't mean we won't do it ... it just means we need a very good reason to do it :D
Besides you just completely marginalised the work done for things like the LiveCD, ServerCD's, the entire Plus and Extra repos etc.
I also did not read it like that. All those things are NOT changing anything in the main distro, but are adding on to it.
As the core distribution - sure, the plan is to stick as close to upstream as is possible, legal and acceptable. However, the centos community is just that - a community of people. If there are things that people want to take up, nothing stops them from doing that. The very last argument in the stack should be 'because upstream does not do this, so we wont either'.
But that might be the argument. For example, we are probably not going to add Gnome 2.22 into centos-5 for precisely that reason :D
Perhaps i586 support could be provided as an offshoot (which, given time, will become a dead-end). Support which Manuel, and like minded persons, could provide (under the watchful eye of one of the core developers) perhaps?
i586 support on CentOS5 was always meant to be an 'alternative' install mechanism.
Right ... so all in all, I though Alan's comments were positive and not negative.
Either way though, the real issue is that we might provide i586 support as an addon feature if it looks like i586 is required for new projects .. but the support may be broken at times since upstream does not ensure their source compiles with that "--target i586" switch.
Johnny Hughes wrote:
But surely we should not forget the basic essential of the CentOS Project - it's equivalence to Upstream's EL. If Upstream support an i586 in their EL 5 then, yes, CentOS should.
I very strongly disagree with that statement. We do lots of things that upstream dont - and there is no reason why we cant expand on that. After all CentOS is not driven by a commercial end game ( as upstream is ), were doing things here that we want to, as a community.
Actually ... I don't personally see it as that at all. We still want to minimize changes and i think Alan's comments are correct.
So should we then stop doing all the other things we do now ?
Right, and we may do it, however if we do it, it will be because there is a growing market and it has no impact on the i686 distro.
If someone wants to step up and say he has a use for something, that does not impact another other community and works off the source base we are already working with, thats reason enough for me.
And the act of modifying anaconda in that way DOES go against what CentOS main goal is (a perfect rebuild of sources).
I disagree. I dont see any mention of i586 being rolled into the main distro, so what would lead you to assume that ? I already cleared that in my last email about i586 being an alternative installed. I already plan on creating one for CentOSPlus and atleast one more for the added drivers one with 5.2 release.
Creating an additional install set isnt that much of work, and if it adds value and makes the distro usable for larger number of people, I see no harm in doing that.
Besides you just completely marginalised the work done for things like the LiveCD, ServerCD's, the entire Plus and Extra repos etc.
I also did not read it like that. All those things are NOT changing anything in the main distro, but are adding on to it.
thats also not true. There is plenty of stuff in the livecd that changes the way the main distro works, there is also plenty of stuff in the Plus repo that is a direct patch ( with no version change ) on packages in the distro, including the Kernel.
But that might be the argument. For example, we are probably not going to add Gnome 2.22 into centos-5 for precisely that reason :D
I have zero problem if someone steps up to say that they would like to build gnome-2.22 for CentOS5 and host it as a sub-repo for the users who want it. I am not going to do it myself, and am quite sure about that :D
i586 support on CentOS5 was always meant to be an 'alternative' install mechanism.
Right ... so all in all, I though Alan's comments were positive and not negative.
perhaps, but he missed the whole point. Which is why the clarification from me.
Either way though, the real issue is that we might provide i586 support as an addon feature if it looks like i586 is required for new projects .. but the support may be broken at times since upstream does not ensure their source compiles with that "--target i586" switch.
Which is why it wont be a part of the main distro, and why there would be a need for someone to manage / maintain that tree. There is very little that actually builds as --target 686 anyway, most of the packages are built with --target 386. however, someone still needs to verify that it works on i586.
We do know that the stock the distro builds from, installs and works fine on i586 ( Fedora support everything, including selinux and home grown patches on i586 )
And the act of modifying anaconda in that way DOES go against what CentOS main goal is (a perfect rebuild of sources).
Forgive my naiveté but didn't you have to do this for C3/C4?
That doesn't mean we won't do it ... it just means we need a very good reason to do it :D
Can you elaborate on what you would require a good reason to be, I've demonstrated that the AMD geode in the form the OLPC program means that there will hundreds of thousands of machine that could benefit. If you believe them there would be Billions in use!
Manuel
Manuel Tuthill wrote:
Can you elaborate on what you would require a good reason to be, I've demonstrated that the AMD geode in the form the OLPC program means that there will hundreds of thousands of machine that could benefit. If you believe them there would be Billions in use!
Do you actually have an OLPC to test again ?
Do we have Dennis on this list ?
on 4-7-2008 8:36 AM Manuel Tuthill spake the following:
And the act of modifying anaconda in that way DOES go against what CentOS main goal is (a perfect rebuild of sources).
Forgive my naivet� but didn't you have to do this for C3/C4?
That doesn't mean we won't do it ... it just means we need a very good reason to do it :D
Can you elaborate on what you would require a good reason to be, I've demonstrated that the AMD geode in the form the OLPC program means that there will hundreds of thousands of machine that could benefit. If you believe them there would be Billions in use!
Manuel
But is an Enterprise distro really the right fit for something like the OLPC project? Or the embedded market?
I see something like Ubuntu or Debian being a better fit for the low end machines. Enterprise distros are better suited to corporate type use. Thousands of machines for wordprocessing and spreadsheets, with e-mail and a browser. OLPC will want full multimedia support that RHEL and CentOS don't provide by default.
And a larger userbase of low end machines will only increase bandwidth costs with little chance of monetary contributions to help there. Sure there would be a larger contribution in future developers, but most will gravitate to a paying job first. Although CentOS is a free OS, I wouldn't say that it is a philanthropic endeavor with unlimited resources. The developers day jobs are what put "food on the table".
You can't be all things to all people, or you will just alienate them all.
Do you actually have an OLPC to test again ?
No mentioning the OLPC was more in building my case for i586 support.
OLPC will want full multimedia support that RHEL and CentOS don't provide by default.
You obviously haven't seen the specs ;) not going to be doing much game playing on that monochrome screen.
You can't be all things to all people, or you will just alienate them all.
And I guess that this is probably the key point. If being purely a legal copy of the upstream vendor is all centos is and wants to be then the answer should probably be no. despite the precedents set with Centos 3/4. If it's more than that then the answer should probably be yes with clauses. (Like you'll need to do the development yourself as the core developers are busy with more important things).
I'm already trying to use Centos outside of the Enterprise solutions it was designed for by using it for a HTPC, Why? Because the very same reason that makes it good for enterprises makes it good for me, long term stability, support and ease of use among others. Of course I could go and use another distribution but I use Centos for Work and don't particularly want to learn the nuances of several different distributions.
On Mon, 2008-04-07 at 17:57 +0100, Manuel Tuthill wrote:
OLPC will want full multimedia support that RHEL and CentOS don't provide by default.
You obviously haven't seen the specs ;) not going to be doing much game playing on that monochrome screen.
But you had. Sorry, I couldn't resist -- the screen is not monochrome.
But you had. Sorry, I couldn't resist -- the screen is not monochrome.
http://laptop.org/laptop/hardware/specs.shtml
"Monochrome display: High-resolution, reflective sunlight-readable monochrome mode;"
Regardless I don't want to become exclusively about the OLPC more over what should and shouldn't be included/supported in the grand scheme of things. The OLPC was more in reference to i586 being obsolete.
Thinking hard about it, shouldn't it be the OS manufacture that ensures that their product supports a wide a range of hardware as possible?
Leave applications developers to support the OS and OS to support the hardware. Of course HW manufactures are a rule unto themselves and cause all sorts of issues like the CMOV and PAE issue, and this is only the CPU which is one of the more stable bit's of hardware.
On Mon, 2008-04-07 at 18:27 +0100, Manuel Tuthill wrote:
But you had. Sorry, I couldn't resist -- the screen is not monochrome.
http://laptop.org/laptop/hardware/specs.shtml
"Monochrome display: High-resolution, reflective sunlight-readable monochrome mode;"
You have read the whole line, right? :o)
You have read the whole line, right? :o)
No I stopped reading as soon as I had enough information to prove someone else on the internet wrong and therefore myself right and more superior.
Now I'm just hopping that someone else don't come back and prove that the Geode LX is i686, I did say very early on that it's very hard to tell and I don't have one to test.
on 4-7-2008 10:39 AM Manuel Tuthill spake the following:
You have read the whole line, right? :o)
No I stopped reading as soon as I had enough information to prove someone else on the internet wrong and therefore myself right and more superior.
Now I'm just hopping that someone else don't come back and prove that the Geode LX is i686, I did say very early on that it's very hard to tell and I don't have one to test.
It looks like the Geode is i586 but with cmov functionality.
It strikes me as odd that AMD would build a 586 processor with cmov instructions, but also build a 686 class without that instruction set. Makes me wonder if it was an engineering snafu that was too costly to fix for the quantity they expected to sell.
It looks like the Geode is i586 but with cmov functionality.
It strikes me as odd that AMD would build a 586 processor with cmov instructions, but also build a 686 class without that instruction set. Makes me wonder if it was an engineering snafu that was too costly to fix for the quantity they expected to sell.
Wow, that seems very odd. cmov was only part of the i686 instruction set so this still wouldn't work with a native i686 distribution right?
BTW it was VIA not AMD who made the "engineering snafu" on the VIA C3 class chips. Rather than being a "snafu" they interpreted the IA32 specifications a little to literary, the CMOV is an optional instruction, but as fair as I understand if it's optional it shouldn't be used at all (since there is no guarantee that it will be available to all i686 cpu's) but since every other i686 class cpu had the instruction when they were doing GCC it got left.
The GCC devs are not happy with you for pointing this out, they kindly point you to the C3 tag for building reasons, when you explain this doesn't help as really it's the vendors who should be building correctly and not blindly for i686 they said well i686 means Pentiumpro and everyone can go jump. (Personally I'm just waiting for an embedded Pentiumpro to come out that excludes the CMOV and is perfectly valid)
It still affects the C3 as fair as I can tell, they are still being sold but they have been superseded by the C7.
on 4-7-2008 11:06 AM Manuel Tuthill spake the following:
It looks like the Geode is i586 but with cmov functionality.
It strikes me as odd that AMD would build a 586 processor with cmov instructions, but also build a 686 class without that instruction set. Makes me wonder if it was an engineering snafu that was too costly to fix for the quantity they expected to sell.
Wow, that seems very odd. cmov was only part of the i686 instruction set so this still wouldn't work with a native i686 distribution right?
BTW it was VIA not AMD who made the "engineering snafu" on the VIA C3 class chips. Rather than being a "snafu" they interpreted the IA32 specifications a little to literary, the CMOV is an optional instruction, but as fair as I understand if it's optional it shouldn't be used at all (since there is no guarantee that it will be available to all i686 cpu's) but since every other i686 class cpu had the instruction when they were doing GCC it got left.
I totally forgot the timeline. VIA did make these chips long before the AMD buyout.
on 4-7-2008 4:48 PM Scott Silva spake the following:
on 4-7-2008 11:06 AM Manuel Tuthill spake the following:
It looks like the Geode is i586 but with cmov functionality.
It strikes me as odd that AMD would build a 586 processor with cmov instructions, but also build a 686 class without that instruction set. Makes me wonder if it was an engineering snafu that was too costly to fix for the quantity they expected to sell.
Wow, that seems very odd. cmov was only part of the i686 instruction set so this still wouldn't work with a native i686 distribution right?
BTW it was VIA not AMD who made the "engineering snafu" on the VIA C3 class chips. Rather than being a "snafu" they interpreted the IA32 specifications a little to literary, the CMOV is an optional instruction, but as fair as I understand if it's optional it shouldn't be used at all (since there is no guarantee that it will be available to all i686 cpu's) but since every other i686 class cpu had the instruction when they were doing GCC it got left.
I totally forgot the timeline. VIA did make these chips long before the AMD buyout.
Sorry for this obvious bull. Long late day, and no sleep. What was I thinking? VIA is not ATI. ATI was bought by AMD. Too many three letter companies and not enough coffee!! ;-P
Scott Silva wrote:
on 4-7-2008 10:39 AM Manuel Tuthill spake the following:
You have read the whole line, right? :o)
No I stopped reading as soon as I had enough information to prove someone else on the internet wrong and therefore myself right and more superior. Now I'm just hopping that someone else don't come back and prove that the Geode LX is i686, I did say very early on that it's very hard to tell and I don't have one to test.
It looks like the Geode is i586 but with cmov functionality.
It strikes me as odd that AMD would build a 586 processor with cmov instructions, but also build a 686 class without that instruction set. Makes me wonder if it was an engineering snafu that was too costly to fix for the quantity they expected to sell.
As I recall AMD bought the Geode product line from someone else: http://www.linuxdevices.com/products/PD6094486551.html
on 4-7-2008 10:27 AM Manuel Tuthill spake the following:
But you had. Sorry, I couldn't resist -- the screen is not monochrome.
http://laptop.org/laptop/hardware/specs.shtml
"Monochrome display: High-resolution, reflective sunlight-readable monochrome mode;"
You cut out the part that didn't agree with your view;
Monochrome display: High-resolution, reflective sunlight-readable monochrome mode; Color display: Standard-resolution, Quincunx-sampled, transmissive color mode;
on 4-7-2008 9:57 AM Manuel Tuthill spake the following:
Do you actually have an OLPC to test again ?
No mentioning the OLPC was more in building my case for i586 support.
OLPC will want full multimedia support that RHEL and CentOS don't provide by default.
You obviously haven't seen the specs ;) not going to be doing much game playing on that monochrome screen.
Multimedia as in video or flash, not video gaming.
Scott Silva wrote:
on 4-7-2008 9:57 AM Manuel Tuthill spake the following:
Do you actually have an OLPC to test again ?
No mentioning the OLPC was more in building my case for i586 support.
OLPC will want full multimedia support that RHEL and CentOS don't provide by default.
You obviously haven't seen the specs ;) not going to be doing much game playing on that monochrome screen.
Multimedia as in video or flash, not video gaming.
Doesn't flash all come from the same place regardless of the distro?
on 4-7-2008 10:18 AM Les Mikesell spake the following:
Scott Silva wrote:
on 4-7-2008 9:57 AM Manuel Tuthill spake the following:
Do you actually have an OLPC to test again ?
No mentioning the OLPC was more in building my case for i586 support.
OLPC will want full multimedia support that RHEL and CentOS don't provide by default.
You obviously haven't seen the specs ;) not going to be doing much game playing on that monochrome screen.
Multimedia as in video or flash, not video gaming.
Doesn't flash all come from the same place regardless of the distro?
Yes, but the flash player doesn't come with CentOS, you have to look elsewhere.
Manuel Tuthill wrote:
Yes, but the flash player doesn't come with CentOS, you have to look elsewhere.
I'd still hazard a guess that a fair chunk of centos business machines still have a flash player installed.
That's one of the reasons I usually install from the k12ltsp respin even on machines where I don't care about booting thin terminals. It has push-button installs for flash, webmin, the ms core fonts, etc. - and some other nice additions while retaining all of the base Centos goodness.
On Mon, Apr 7, 2008 at 6:57 PM, Manuel Tuthill Manuel@nebula-it.co.uk wrote:
Do you actually have an OLPC to test again ?
No mentioning the OLPC was more in building my case for i586 support.
I don't think that is much of a case yet, since I see little change getting CentOS on them. First of all, because they require very fine tuning wrt. system requirements and power management. Secondly, I don't think kids will replace the preinstalled Fedora-ish installation with CentOS. You need someone higher up the chain to do that.
The XO-1 has 1 GB flash memory, 256MB RAM, and a tiny screen resolution. It's hard to squeeze a useful system into that, without also providing and maintaining an interface like Sugar.
-- Daniel
On Mon, Apr 7, 2008 at 7:10 PM, Daniel de Kok me@danieldk.org wrote:
I don't think that is much of a case yet, since I see little change
s/change/chance/
Manuel Tuthill wrote:
I'm already trying to use Centos outside of the Enterprise solutions it was designed for by using it for a HTPC, Why? Because the very same reason that makes it good for enterprises makes it good for me, long term stability, support and ease of use among others.
That doesn't really prevent having some current applications running on top of your stable OS and libraries, but you'll probably have to compile them yourself.
Of course I could go and use another distribution but I use Centos for Work and don't particularly want to learn the nuances of several different distributions.
Yes, it would be nice if some of the more popular apps were built in current versions for older RHEL/Centos releases. I'd probably still be running Centos 3.x on several older machines if it was easy to add a current thunderbird/firefox/OOo, and a couple of other things. These machines aren't so old as to make it impossible to run 5.x but I can't see any real improvement either.
Scott Silva wrote:
But is an Enterprise distro really the right fit for something like the OLPC project? Or the embedded market?
yes, its the perfect fit.
I see something like Ubuntu or Debian being a better fit for the low end machines.>
No, you dont want to redo a port every 6 months for the embedded markets. The whole point is fire-and-forget capability for those sort of roles.
Enterprise distros are better suited to corporate type use.
Which is mostly the same as what people in the embedded markets use.
You can't be all things to all people, or you will just alienate them all.
how about people who want to help themselves ?
Karanbir Singh wrote:
Scott Silva wrote:
But is an Enterprise distro really the right fit for something like the OLPC project? Or the embedded market?
yes, its the perfect fit.
Did you read the specs? http://laptop.org/laptop/hardware/specs.shtml
CentOS5 in 256 Mbytes? 1 Gbyte "disk?"
(I don't think the instruction set is quite as advertised there, see the datasheet it links to).
I see something like Ubuntu or Debian being a better fit for the low end machines.>
No, you dont want to redo a port every 6 months for the embedded markets. The whole point is fire-and-forget capability for those sort of roles.
http://laptop.org/en/laptop/software/specs.shtml
John Summerfield wrote:
yes, its the perfect fit.
Did you read the specs? http://laptop.org/laptop/hardware/specs.shtml
very briefly
CentOS5 in 256 Mbytes? 1 Gbyte "disk?"
It *can* be done, will need a few mod's to the package set though. And some of the dep tree's in CentOS for stuff like X are quite long. Something might need to be done about those as well.
The default install is going to struggle with that quite a bit. Specially the disk size.
Hi guys,
So to summarize this thread and in a attemp to make some progess, this is what I see as the conclusions and the next step(s) :
- The devs have no problems with the basic idea of providing i586 support for CentOS 5. - The devs currently do not have the time/resources/... to do pursue this themselves. - So we are looking for (a) volunteer(s) that are willing to make this happen, but with guidance and support from a developer. - Daniel already did work on this, so we do not have to start from scratch. Daniel is willing to provides to the people willing to work in this (Daniel, this is how I understood it ?). - The result of all the work will no be put in the base OS but probably be put inside the context of CentOSPlus and will have a alternative install method (details to be discussed).
So, as far is I see it what we need now is a (couple of) volunteer(s) that are willing to invest some time in this and then we can go ahead with it. So, any takers ?
Regards, Tim
Tim Verhoeven wrote:
Hi guys,
So to summarize this thread and in a attemp to make some progess, this is what I see as the conclusions and the next step(s) :
- The devs have no problems with the basic idea of providing i586
support for CentOS 5.
- The devs currently do not have the time/resources/... to do pursue
this themselves.
- So we are looking for (a) volunteer(s) that are willing to make this
happen, but with guidance and support from a developer.
- Daniel already did work on this, so we do not have to start from
scratch. Daniel is willing to provides to the people willing to work in this (Daniel, this is how I understood it ?).
- The result of all the work will no be put in the base OS but
probably be put inside the context of CentOSPlus and will have a alternative install method (details to be discussed).
So, as far is I see it what we need now is a (couple of) volunteer(s) that are willing to invest some time in this and then we can go ahead with it. So, any takers ?
Regards, Tim
A moment of silence after the storm...
-- Patrice
on 4-9-2008 1:28 PM Patrice Guay spake the following:
Tim Verhoeven wrote:
Hi guys,
So to summarize this thread and in a attemp to make some progess, this is what I see as the conclusions and the next step(s) :
- The devs have no problems with the basic idea of providing i586
support for CentOS 5.
- The devs currently do not have the time/resources/... to do pursue
this themselves.
- So we are looking for (a) volunteer(s) that are willing to make this
happen, but with guidance and support from a developer.
- Daniel already did work on this, so we do not have to start from
scratch. Daniel is willing to provides to the people willing to work in this (Daniel, this is how I understood it ?).
- The result of all the work will no be put in the base OS but
probably be put inside the context of CentOSPlus and will have a alternative install method (details to be discussed).
So, as far is I see it what we need now is a (couple of) volunteer(s) that are willing to invest some time in this and then we can go ahead with it. So, any takers ?
Regards, Tim
A moment of silence after the storm...
Bueller ... Bueller ...
So, as far is I see it what we need now is a (couple of) volunteer(s) that are willing to invest some time in this and then we can go ahead with it. So, any takers ?
I said way back that I would do some development, I am however not a developer, I have spoken to Karanbir off list and he agreed that although he was busy he would try and give me a little guidance. I know Daniel did do some work and I'll probably contact him to find out the state of play.
Manuel
On 07/04/2008, Johnny Hughes johnny@centos.org wrote:
Actually ... I don't personally see it as that at all. We still want to minimize changes and i think Alan's comments are correct.
Right, and we may do it, however if we do it, it will be because there is a growing market and it has no impact on the i686 distro.
And the act of modifying anaconda in that way DOES go against what CentOS main goal is (a perfect rebuild of sources).
That doesn't mean we won't do it ... it just means we need a very good reason to do it :D
I also did not read it like that. All those things are NOT changing anything in the main distro, but are adding on to it.
But that might be the argument. For example, we are probably not going to add Gnome 2.22 into centos-5 for precisely that reason :D
Right ... so all in all, I though Alan's comments were positive and not negative.
Either way though, the real issue is that we might provide i586 support as an addon feature if it looks like i586 is required for new projects .. but the support may be broken at times since upstream does not ensure their source compiles with that "--target i586" switch.
Thanks for seeing it as I wrote it, Johnny. I read Karanbir's reply once, then twice, then scratched my head, then read it a third time. At that point I had to get up from my monitor and go do something - anything that could be done on "auto-pilot" - elsewhere.
What I wrote was (a) to give support to Manuel's proposal for C5 support on the i586 (b) but to minimise the ever-increasing pressure on the core developers.
I do what very little I am able to do, for and in the spirit of the CentOS Community. Until such time as it is made clear to me that I am not wanted, I will continue in that fashion. I've lived for over half a century and have a broad back.
Perhaps Karanbir is just having a bad day and is feeling particularly "spiky".
Alan.
Alan Bartlett wrote:
What I wrote was (a) to give support to Manuel's proposal for C5 support on the i586 (b) but to minimise the ever-increasing pressure on the core developers.
If you read the entire thread, people have offered to actually do the work. Daniel did everything that would have been required almost a year back, but we lost two things at the time (a) a machine to test this on, pretty much everything we found worked with the i686 built distro and (b) a userbase that wanted i586. At the time there was one person who was looking to deploy a few thousand ltsp clients based around i586 cpu's. He decided it was easier for him to just move to i686 clients.
I do what very little I am able to do, for and in the spirit of the CentOS Community. Until such time as it is made clear to me that I am not wanted, I will continue in that fashion. I've lived for over half a century and have a broad back.
And I am sure that your efforts are appreciated.
Perhaps Karanbir is just having a bad day and is feeling particularly "spiky".
I am having a fine day, thanks. The only thing I took issue against was your wide sweeping statement that we dont want or do anything beyond what is in upstream. Some of us work quite hard, and do a lot of things beyond what we need personally and what comes down the pipeline from upstream - so my response will stay the same to anyone who says otherwise. Irrespective of what sort of a day I am having.
On Mon, Apr 7, 2008 at 8:59 AM, Karanbir Singh mail-lists@karan.org wrote:
Alan Bartlett wrote:
I do what very little I am able to do, for and in the spirit of the CentOS
Community. Until such time as it is made clear to me that I am not wanted, I will continue in that fashion. I've lived for over half a century and have a broad back.
And I am sure that your efforts are appreciated.
I am 100% aware that I am off-topic, so I apologize in advance. But I could not help saying something here. Yes, Alan's efforts must be appreciated especially because he has been helping in the Forum area (among other things) to a great extent. Compared to the mailing lists which are blessed by essentially ALL CentOS developers, CentOS forums are not getting any attention by the core developers except for occasional posts. Lack of time, of course, is the reason which is understandable. However, I really hope that the time/efforts get distributed between the two venues offered to CentOS users. [/OT]
Akemi
On 07/04/2008, Karanbir Singh mail-lists@karan.org wrote:
The only thing I took issue against was your wide sweeping statement that we dont want or do anything beyond what is in upstream.
Sorry KB, if that is how you interpreted my words. No "wide sweeping statement" of that kind was either intended or, afair, written.
Some of us work quite hard, and do a lot of things beyond what we need
personally and what comes down the pipeline from upstream - so my response will stay the same to anyone who says otherwise.
So now, from what you have just written, I could say that you are implying that other core developers don't "work quite hard". However, I do not believe that implication. The English language is a very powerful tool.
Alan.
Alan Bartlett wrote:
Some of us work quite hard, and do a lot of things beyond what we need personally and what comes down the pipeline from upstream - so my response will stay the same to anyone who says otherwise.So now, from what you have just written, I could say that you are implying that other core developers don't "work quite hard". However, I do not believe that implication. The English language is a very powerful tool.
you would, however, be right. Not all centos devlopers work on extending the distro or even on the Distro.
-
Akemi Yagi -
Alan Bartlett -
Daniel de Kok -
Hugo van der Kooij -
John Summerfield -
Johnny Hughes -
Karanbir Singh -
Les Mikesell -
Lubomir Kundrak -
Manuel Tuthill -
Patrice Guay -
R P Herrold -
Scott Silva -
Tim Verhoeven