On Sat, Dec 14, 2013 at 6:04 PM, Reindl Harald h.reindl@thelounge.net wrote:
so stay on RHEL6/CentOS6 until this old hardware dies where is the problem?
Google Chrome, etc.
http://en.wikipedia.org/wiki/Red_Hat_Enterprise_Linux http://en.wikipedia.org/wiki/Red_Hat_Enterprise_Linux#Life-cycle_dates
*who* is forcing you to RHEL7?
Nobody wants old desktop apps.
Le 15/12/2013 05:55, Les Mikesell a écrit :
On Sat, Dec 14, 2013 at 6:04 PM, Reindl Harald h.reindl@thelounge.net wrote:
so stay on RHEL6/CentOS6 until this old hardware dies where is the problem?
Google Chrome, etc.
http://en.wikipedia.org/wiki/Red_Hat_Enterprise_Linux http://en.wikipedia.org/wiki/Red_Hat_Enterprise_Linux#Life-cycle_dates
*who* is forcing you to RHEL7?
Nobody wants old desktop apps.
In this case, use Fedora. Since the release of windows 8 and 2012 (and even before) and UEFI, all new hardware are 64 bit capable, and even ARM will release a 64 bit version. Remember that in RHEL, 'E' is for Enterprise (and in CentOS, 'ent' means the same). That is, stability and maintennace on the long term are more important than recent desktop apps.
Alain
On Sun, Dec 15, 2013 at 2:18 AM, Alain Péan alain.pean@lpn.cnrs.fr wrote:
so stay on RHEL6/CentOS6 until this old hardware dies where is the problem?
Google Chrome, etc.
http://en.wikipedia.org/wiki/Red_Hat_Enterprise_Linux http://en.wikipedia.org/wiki/Red_Hat_Enterprise_Linux#Life-cycle_dates
*who* is forcing you to RHEL7?
Nobody wants old desktop apps.
In this case, use Fedora. Since the release of windows 8 and 2012 (and even before) and UEFI, all new hardware are 64 bit capable, and even ARM will release a 64 bit version. Remember that in RHEL, 'E' is for Enterprise (and in CentOS, 'ent' means the same). That is, stability and maintennace on the long term are more important than recent desktop apps.
In the environments where LTSP is used (schools, etc.) there would typically be a reasonably current server where you want stability and low maintenance and it PXE-boots the clients (thus no maintenance...). There is also typically not a systems expert on site since one of the reasons to use it in education is to keep costs down. Keeping Fedora running would be i nightmare. Ubuntu might be tolerable, though. Or perhaps it can be altered to boot a different system on the clients like DRBL.
On 12/15/2013 10:29 AM, Les Mikesell wrote:
On Sun, Dec 15, 2013 at 2:18 AM, Alain Péan alain.pean@lpn.cnrs.fr wrote:
so stay on RHEL6/CentOS6 until this old hardware dies where is the problem?
Google Chrome, etc.
http://en.wikipedia.org/wiki/Red_Hat_Enterprise_Linux http://en.wikipedia.org/wiki/Red_Hat_Enterprise_Linux#Life-cycle_dates
*who* is forcing you to RHEL7?
Nobody wants old desktop apps.
In this case, use Fedora. Since the release of windows 8 and 2012 (and even before) and UEFI, all new hardware are 64 bit capable, and even ARM will release a 64 bit version. Remember that in RHEL, 'E' is for Enterprise (and in CentOS, 'ent' means the same). That is, stability and maintennace on the long term are more important than recent desktop apps.
In the environments where LTSP is used (schools, etc.) there would typically be a reasonably current server where you want stability and low maintenance and it PXE-boots the clients (thus no maintenance...). There is also typically not a systems expert on site since one of the reasons to use it in education is to keep costs down. Keeping Fedora running would be i nightmare. Ubuntu might be tolerable, though. Or perhaps it can be altered to boot a different system on the clients like DRBL.
Well, then convince Red Hat to build it :D
IF (and only if) it works to build i686, we (CentOS) might try to do it. However, it will not initially be a priority.
On 12/14/2013 8:55 PM, Les Mikesell wrote:
Nobody wants old desktop apps.
new apps tend to have heavier memory and performance requirements.
we don't run 16 bit stuff anymore either, and 16 bit computers, like intel 286, are LONG obsolete, outside of the low end embedded market.
On 12/15/2013 09:40 PM, John R Pierce wrote:
On 12/14/2013 8:55 PM, Les Mikesell wrote:
Nobody wants old desktop apps.
new apps tend to have heavier memory and performance requirements.
we don't run 16 bit stuff anymore either, and 16 bit computers, like intel 286, are LONG obsolete, outside of the low end embedded market.
That's a bit different, Linux never had 16 bit support, but is still perfectly usable on a 32 bit arch. I understand RedHat dropping 32 bit support for this release, the needs of RedHat customers are different to those of CentOS users, when you fork out a few grand for a server license it's not such a big deal to get a new server to go with it.
That said, it may not be very difficult to build the sources for i386, and I personally don't see any reason why CentOS can't or shouldn't. The 32 bit arch will be in a separate repo to the 64 bit, so won't interfere with upstream compatibility, and CentOS likely already has the infra in place to do a 32 bit build from prior versions. Since Fedora still fully supports 32 bit, right up to rawhide it's reasonable to assume that the RedHat sources should build to 32 bit without too much fuss.
Peter
How much GB RAM RHEL 7 64bit support ?
Công Nghệ VPS - LEVU BIS Co., Ltd Website : <a href="http://congnghevps.net">http://congnghevps.net</a> Email : info@congnghevps.net Phone : 055.3.842.159 Yahoo : levubis XEN VPS, Cloud VPS, Dedicated Server, Game Server
Date: Sun, 15 Dec 2013 22:21:27 +1300 From: peter@pajamian.dhs.org To: centos@centos.org Subject: Re: [CentOS] RHEL 7 Beta is now public
On 12/15/2013 09:40 PM, John R Pierce wrote:
On 12/14/2013 8:55 PM, Les Mikesell wrote:
Nobody wants old desktop apps.
new apps tend to have heavier memory and performance requirements.
we don't run 16 bit stuff anymore either, and 16 bit computers, like intel 286, are LONG obsolete, outside of the low end embedded market.
That's a bit different, Linux never had 16 bit support, but is still perfectly usable on a 32 bit arch. I understand RedHat dropping 32 bit support for this release, the needs of RedHat customers are different to those of CentOS users, when you fork out a few grand for a server license it's not such a big deal to get a new server to go with it.
That said, it may not be very difficult to build the sources for i386, and I personally don't see any reason why CentOS can't or shouldn't. The 32 bit arch will be in a separate repo to the 64 bit, so won't interfere with upstream compatibility, and CentOS likely already has the infra in place to do a 32 bit build from prior versions. Since Fedora still fully supports 32 bit, right up to rawhide it's reasonable to assume that the RedHat sources should build to 32 bit without too much fuss.
Peter
CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
On 12/15/2013 1:21 AM, Peter wrote:
the needs of RedHat customers are different to those of CentOS users
CentOS *IS* RHEL rebuilt without branding and offered without support contracts. So saying the needs of the user differ is specious.
On Sun, Dec 15, 2013 at 11:47 AM, John R Pierce pierce@hogranch.com wrote:
On 12/15/2013 1:21 AM, Peter wrote:
the needs of RedHat customers are different to those of CentOS users
CentOS *IS* RHEL rebuilt without branding and offered without support contracts. So saying the needs of the user differ is specious.
It does make sense in the context of being able to build a 32-bit version from RHEL sources, though.
On 12/15/2013 10:27 AM, Les Mikesell wrote:
It does make sense in the context of being able to build a 32-bit version from RHEL sources, though.
which is completely untested....
anyways, doesn't EL7 use XFS now by default? XFS is completely UNsupported with a 32bit kernel as the stack is too small.
On Sun, Dec 15, 2013 at 10:35:31AM -0800, John R Pierce wrote:
anyways, doesn't EL7 use XFS now by default? XFS is completely UNsupported with a 32bit kernel as the stack is too small.
ext2/3/4 are all still available which are perfectly content with i686/32bit.
John
On Sun, Dec 15, 2013 at 10:35:31AM -0800, John R Pierce wrote:
On 12/15/2013 10:27 AM, Les Mikesell wrote:
It does make sense in the context of being able to build a 32-bit version from RHEL sources, though.
which is completely untested....
anyways, doesn't EL7 use XFS now by default? XFS is completely UNsupported with a 32bit kernel as the stack is too small.
To answer just part of the question, yes, it's using XFS by default. If you choose standard partition during installation and make no other changes, you will have an XFS partition.
On 12/15/2013 11:42 AM, Scott Robbins wrote:
To answer just part of the question, yes, it's using XFS by default. If you choose standard partition during installation and make no other changes, you will have an XFS partition.
so a custom 32 bit build, the installer probably should be modified to use EXT3 or 4 instead (in 32bits I'd be inclined to stick with 3), requiring yet more testing and debugging.
On Sun, Dec 15, 2013 at 11:59:36AM -0800, John R Pierce wrote:
so a custom 32 bit build, the installer probably should be modified to use EXT3 or 4 instead (in 32bits I'd be inclined to stick with 3), requiring yet more testing and debugging.
Which should be a trivial QA test.
Why the reservations with ext4 on a 32bit platform?
John
On 2013-12-15, John R Pierce pierce@hogranch.com wrote:
On 12/15/2013 1:21 AM, Peter wrote:
the needs of RedHat customers are different to those of CentOS users
CentOS *IS* RHEL rebuilt without branding and offered without support contracts. So saying the needs of the user differ is specious.
I disagree. The people RH may be targetting for purchasing RHEL7 may very well be different from the people hoping to use CentOS 7. If not enough paying RHEL customers complain about this issue, they're not likely to change their policy; upset CentOS users probably won't bother upstream enough.
--keith
On 12/15/2013 10:23 PM, Keith Keller wrote:
CentOS *IS* RHEL rebuilt without branding and offered without support contracts. So saying the needs of the user differ is specious.
I disagree. The people RH may be targetting for purchasing RHEL7 may very well be different from the people hoping to use CentOS 7. If not enough paying RHEL customers complain about this issue, they're not likely to change their policy; upset CentOS users probably won't bother upstream enough.
therefore, if enough people sign up to help and do the work, we can make the resources available within the project to facilitate this. the people doing the work in centos for the distro base do not have the bandwidth to add this additional task - so its going to need people to stay up and offer to do the work. I'm happy and very willing to help bootstrap the process.
Also worth keeping in mind is that this would be a 'derevative' of the core CentOS Linux and it wont just be CentOS Linux 7/i686. That gives us a few easy wins : we dont need to port the entire package set, and we can selectively make changes to things like the installer ( to work around the xfs issue, however looking at the code briefly, we dont / wont have the xfs issue anyway, the installer is smart enough to work around on i686 ).
There would also be implications on how we do the release work, but the main issue at hand, that needs to be solved before we even consider this as a group : who's stepping up to do the work involved. Off the top of my head, this is going to need a team of 5 to 8 people doing stuff 'in odd hours' or a couple of people working on this as their primary focus.
- KB
-
Alain Péan -
John R Pierce -
John R. Dennison -
Johnny Hughes -
Karanbir Singh -
Keith Keller -
Les Mikesell -
LEVU BIS -
Peter -
Scott Robbins