I just want to say that I really, really, appreciate the information given on this site:
http://qaweb.dev.centos.org/qa/calendar
--On Monday, June 13, 2011 10:23:54 AM -0400 "James B. Byrne" byrnejb@harte-lyne.ca wrote:
I just want to say that I really, really, appreciate the information given on this site:
Indeed. Even though it's not official, having a gut feel for approximate status sure helps. (I'm another one of those who has been delaying deployment of some new systems pending CentOS 6 due to wanting to maximize those systems' useful lifetimes.)
My thanks to the CentOS team for all their hard work.
Devin
On Mon, 13 Jun 2011, Devin Reade wrote:
(I'm another one of those who has been delaying deployment of some new systems pending CentOS 6 due to wanting to maximize those systems' useful lifetimes.)
I was wondering if hardware vendors would see an uptick in sales around the time CentOS 6 becomes generally available...
No. Given the economy people are trying to make systems last as long as possible and this is just 6.0 not 6.1. Smart folks will test 6.0 to see how apps perform/behave and then wait till 6.1. Never go to a major revision.0 unless you are forced.
-----Original Message----- From: centos-bounces@centos.org [mailto:centos-bounces@centos.org] On Behalf Of Paul Heinlein Sent: Monday, June 13, 2011 12:48 PM To: CentOS mailing list Subject: Re: [CentOS] CentOS-6 Status updates
On Mon, 13 Jun 2011, Devin Reade wrote:
(I'm another one of those who has been delaying deployment of some new systems pending CentOS 6 due to wanting to maximize those systems' useful lifetimes.)
I was wondering if hardware vendors would see an uptick in sales around the time CentOS 6 becomes generally available...
-- Paul Heinlein <> heinlein@madboa.com <> http://www.madboa.com/ _______________________________________________ CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
On Mon, 13 Jun 2011, NOYK wrote:
Smart folks will test 6.0 to see how apps perform/behave and then wait till 6.1.
I beg to differ. Smart folks will test 6.0 and deploy it if performance is acceptable.
Never go to a major revision.0 unless you are forced.
Never wait until revision.1 unless there's a good reason. :-)
Guess you have never worked in an organization of any size where you worry about reliability, patches, bug fixes, etc.
.0 releases can tough on your back side even if performance is acceptable and you believe there is a good reason (but your boss may not agree) :)
-----Original Message----- From: centos-bounces@centos.org [mailto:centos-bounces@centos.org] On Behalf Of Paul Heinlein Sent: Monday, June 13, 2011 1:13 PM To: CentOS mailing list Subject: Re: [CentOS] CentOS-6 Status updates
On Mon, 13 Jun 2011, NOYK wrote:
Smart folks will test 6.0 to see how apps perform/behave and then wait till 6.1.
I beg to differ. Smart folks will test 6.0 and deploy it if performance is acceptable.
Never go to a major revision.0 unless you are forced.
Never wait until revision.1 unless there's a good reason. :-)
-- Paul Heinlein <> heinlein@madboa.com <> http://www.madboa.com/ _______________________________________________ CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
Smart folks will test 6.0 to see how apps perform/behave and then wait till 6.1.
I beg to differ. Smart folks will test 6.0 and deploy it if performance
is
acceptable.
Guess you have never worked in an organization of any size where you worry about reliability, patches, bug fixes, etc.
How about acknowledging that each organization's requirements are different, and may well in fact differ depending on the circumstances?
Yes, in a lot of cases there can be problems with *.0 releases (not referring to CentOS in particular here, but software in general). Sometimes circumstances force your hand.
OMO, a good systems architect doesn't live in black-and-white world, but rather knows the influencing factors, has a wide selection of tools, picks the best solution available to the problem at hand, and tries to mitigate his risks.
Devin
On 06/13/2011 10:12 AM, Paul Heinlein wrote:
Never wait until revision.1 unless there's a good reason. :-)
http://rhn.redhat.com/errata/rhel-server-6-errata.html
There are a number of "Important" reasons not to deploy 6.0 for public-facing systems.
On Wed, 15 Jun 2011, Gordon Messmer wrote:
On 06/13/2011 10:12 AM, Paul Heinlein wrote:
Never wait until revision.1 unless there's a good reason. :-)
http://rhn.redhat.com/errata/rhel-server-6-errata.html
There are a number of "Important" reasons not to deploy 6.0 for public-facing systems.
Nine errata marked Critical: * six for firefox and thunderbird (which wouldn't be on public-facing servers, at least in my shop) * one for pango, which wouldn't see much use on a server * one server-side for samba (samba server public facing? hmm.) * one for java -- released one week ago (June 8)
Of the other vulnerabilities, marked Important and lower, it's difficult for me to tell how many also needed to be fixed in CentOS 5.
I'm not trying to serve as apologist for RHEL 6. I'm just saying that there's little room in my world for an abolutist position like "never use a .0 release -- ever."
On 06/15/2011 01:39 PM, Paul Heinlein wrote:
I'm not trying to serve as apologist for RHEL 6. I'm just saying that there's little room in my world for an abolutist position like "never use a .0 release -- ever."
I wouldn't favor such a sentiment either, but as it stands, CentOS 6 will be delivered with known security problems. It won't make sense for most people to deploy until the team catches up with current errata, IMO.
On Wed, 15 Jun 2011, Gordon Messmer wrote:
On 06/15/2011 01:39 PM, Paul Heinlein wrote:
I'm not trying to serve as apologist for RHEL 6. I'm just saying that there's little room in my world for an abolutist position like "never use a .0 release -- ever."
I wouldn't favor such a sentiment either, but as it stands, CentOS 6 will be delivered with known security problems. It won't make sense for most people to deploy until the team catches up with current errata, IMO.
I certainly agree, however, that it's prudent to wait for the known package updates before deploying CentOS 6.
In *this* case, since Red Hat has already released 6.1, it may even be prudent to wait for the CentOS 6.1 release before public deployment.
Maybe Red Hat will continue to obfuscate its infrastructure and increase the burden on teams like CentOS who try to rebuild the distribution from SRPMs. In that case, the release cycle for CentOS 7 or 8 might not be worth the wait. Or, perhaps, things will return to what passed for normalcy in CentOS 3, 4, and 5. Outside of Red Hat, who knows?
On Wed, 15 Jun 2011, Gordon Messmer wrote:
Nothing that Red Hat did has increased the burden on CentOS.
so says the person who has not done it
- the rpm tool changed, adding a non-backward compatible compression scheme. as I blogged about months ago; this has 'flow through' effects as to bootstrapping a new builder
- the anaconda changes, re-design as to install stages, sever deprecation of TUI installs, unfixed graphics driver issues, and install time anaconda 'seeks' across the wire to remote network content introduced addotional complexity to an already ever-changing and at best, spaghetti like pile of Python puke, as I've already noted on this and the -devel mailing list
- the install image size explosion (as has been mentioned here and on -devel) has complicated much, and lengthened the time needed for each test image compose, slowing the testing turn cycle
- the continuing (non-technical reason) segmentation of the upstream product family continues to make ensuring closure, and build self-hosting more laborious. I think I've mentioned it here, but if not, it is so ...
-- Russ herrold
On 16 June 2011 01:20, R P Herrold herrold@owlriver.com wrote:
On Wed, 15 Jun 2011, Gordon Messmer wrote:
Nothing that Red Hat did has increased the burden on CentOS.
so says the person who has not done it
- the rpm tool changed, adding a non-backward compatible
compression scheme. as I blogged about months ago; this has 'flow through' effects as to bootstrapping a new builder
- the anaconda changes, re-design as to install stages, sever
deprecation of TUI installs, unfixed graphics driver issues, and install time anaconda 'seeks' across the wire to remote network content introduced addotional complexity to an already ever-changing and at best, spaghetti like pile of Python puke, as I've already noted on this and the -devel mailing list
Yeah the bugzilla report of the hard crash on initialisation of X during install of the 64bit betas of RHEL6 on my dell e4200 were closed with the status of feature request. At the time i tested with fedora 12 / fedora 13 and the 32 bit beta all of which were fine.
Maybe RHEL7 will be more polished "out the gate"
mike
Paul Heinlein wrote:
In *this* case, since Red Hat has already released 6.1, it may even be prudent to wait for the CentOS 6.1 release before public deployment.
My guess is devs will first work on critical updates and release them before the 6.1 official release. That way 6.0 will still be usable.
Also, it should be possible to compile 6.1 packages on 6.0, or at least on already working build platform, so 6.1 release might be much faster. I would not be surprised that preliminary build of 6.1 packages was already attempted, and that dev already have the list of possible issues not yet solved in 6.0 process.
Ljubomir
So,
to go back to the topic what is the current status for 6.0? Will it happen in June or July?
On Mon, Jun 27, 2011 at 11:25:21AM +0800, Christopher Chan wrote:
I vote "who cares?"
I vote "http://qaweb.dev.centos.org".
John
On Monday, June 27, 2011 11:48 AM, John R. Dennison wrote:
On Mon, Jun 27, 2011 at 11:25:21AM +0800, Christopher Chan wrote:
I vote "who cares?"
I vote "http://qaweb.dev.centos.org".
Too bad that does not seem to be good enough for some.
On 06/13/2011 05:56 PM, NOYK wrote:
No. Given the economy people are trying to make systems last as long as possible and this is just 6.0 not 6.1. Smart folks will test 6.0 to see how apps perform/behave and then wait till 6.1. Never go to a major revision.0 unless you are forced.
hopefully we can get 6.1 out really soon after 6.0, so make sure you do your testing real quick!
- KB
PS: consider not top posting, and trimming your reply. Makes conversation easier and more productive.
on 6/13/2011 9:48 AM Paul Heinlein spake the following:
On Mon, 13 Jun 2011, Devin Reade wrote:
(I'm another one of those who has been delaying deployment of some new systems pending CentOS 6 due to wanting to maximize those systems' useful lifetimes.)
I was wondering if hardware vendors would see an uptick in sales around the time CentOS 6 becomes generally available...
When the build issues are resolved with 6.0, 6.1 will not be as far behind. I'm almost sure that the normal past times of 2 to 3 weeks will work back into the norm. Since it seems that RedHat has accelerated their major version releases, it might be a short reprieve... Not that the CentOS team is slacking, but you can bet that enterprise 7.0 will most likely have new obstacles...
on 6/13/2011 7:23 AM James B. Byrne spake the following:
I just want to say that I really, really, appreciate the information given on this site:
What I appreciate is the lack of fighting and "Is it done yet?" posts that were flowing out before...
On Jun 13, 2011, at 9:10 AM, Scott Silva wrote:
on 6/13/2011 7:23 AM James B. Byrne spake the following:
I just want to say that I really, really, appreciate the information given on this site:
What I appreciate is the lack of fighting and "Is it done yet?" posts that were flowing out before...
---- easier just to give up - I moved my new servers to ubuntu - no more new CentOS installs any more. I'm just going to maintain the CentOS 5 installs at this point.
Craig
On Tuesday, June 14, 2011 12:22 AM, Craig White wrote:
On Jun 13, 2011, at 9:10 AM, Scott Silva wrote:
on 6/13/2011 7:23 AM James B. Byrne spake the following:
I just want to say that I really, really, appreciate the information given on this site:
What I appreciate is the lack of fighting and "Is it done yet?" posts that were flowing out before...
easier just to give up - I moved my new servers to ubuntu - no more new CentOS installs any more. I'm just going to maintain the CentOS 5 installs at this point.
Funny, I am going to move OFF Ubuntu...
On Jun 13, 2011, at 5:10 PM, Christopher Chan wrote:
On Tuesday, June 14, 2011 12:22 AM, Craig White wrote:
On Jun 13, 2011, at 9:10 AM, Scott Silva wrote:
on 6/13/2011 7:23 AM James B. Byrne spake the following:
I just want to say that I really, really, appreciate the information given on this site:
What I appreciate is the lack of fighting and "Is it done yet?" posts that were flowing out before...
easier just to give up - I moved my new servers to ubuntu - no more new CentOS installs any more. I'm just going to maintain the CentOS 5 installs at this point.
Funny, I am going to move OFF Ubuntu...
I just stayed on Centos, no need to move anywhere :)
- aurf
On Tuesday, June 14, 2011 08:46 AM, aurfalien@gmail.com wrote:
On Jun 13, 2011, at 5:10 PM, Christopher Chan wrote:
On Tuesday, June 14, 2011 12:22 AM, Craig White wrote:
On Jun 13, 2011, at 9:10 AM, Scott Silva wrote:
on 6/13/2011 7:23 AM James B. Byrne spake the following:
I just want to say that I really, really, appreciate the information given on this site:
What I appreciate is the lack of fighting and "Is it done yet?" posts that were flowing out before...
easier just to give up - I moved my new servers to ubuntu - no more new CentOS installs any more. I'm just going to maintain the CentOS 5 installs at this point.
Funny, I am going to move OFF Ubuntu...
I just stayed on Centos, no need to move anywhere :)
I did not choose to use Ubuntu...it was the only CD around when the predecessor's RHL 9 NAT/Proxy box went completely kaput. Was testing Hardy for desktop for the school...
On Mon, 2011-06-13 at 09:22 -0700, Craig White wrote:
easier just to give up - I moved my new servers to ubuntu - no more new CentOS installs any more. I'm just going to maintain the CentOS 5 installs at this point.
Holy shit, man! I'd never, by choice, put in an Ubuntu server. Debian, sure (though I'm a Red Hat and Red Hat based guy), but Ubuntu? Forget it!
I hope you find it as stable and reliable as CentOS.
Regards,
Ranbir
On Tue, 2011-06-14 at 06:49 -0400, Kanwar Ranbir Sandhu wrote:
On Mon, 2011-06-13 at 09:22 -0700, Craig White wrote:
easier just to give up - I moved my new servers to ubuntu - no more new CentOS installs any more. I'm just going to maintain the CentOS 5 installs at this point.
Holy shit, man! I'd never, by choice, put in an Ubuntu server. Debian, sure (though I'm a Red Hat and Red Hat based guy), but Ubuntu? Forget it!
I hope you find it as stable and reliable as CentOS.
---- heck it's still Linux and pretty much the same.
Red Hat went far too long between releases and it is clear to me that I can't possibly rely on CentOS for timeliness.
Craig
Craig White wrote:
On Tue, 2011-06-14 at 06:49 -0400, Kanwar Ranbir Sandhu wrote:
On Mon, 2011-06-13 at 09:22 -0700, Craig White wrote:
easier just to give up - I moved my new servers to ubuntu - no more
new CentOS installs any more. I'm just going to maintain the CentOS 5 installs at this point.
Holy shit, man! I'd never, by choice, put in an Ubuntu server. Debian, sure (though I'm a Red Hat and Red Hat based guy), but Ubuntu? Forget it!
I hope you find it as stable and reliable as CentOS.
heck it's still Linux and pretty much the same.
Red Hat went far too long between releases and it is clear to me that I can't possibly rely on CentOS for timeliness.
Timeliness, dunno. Ubuntu (or fedora) for production? NOT IF I HAVE ANY CONTROL!!! Given how many developers write incredibly fragile code, that is utterly dependent upon a very, very special environment, I guarantee that the almost daily updates will break it, or the New Features! will have changed interfaces....
mark
On Tue, Jun 14, 2011 at 9:19 AM, m.roth@5-cent.us wrote:
Craig White wrote:
heck it's still Linux and pretty much the same.
Red Hat went far too long between releases and it is clear to me that I can't possibly rely on CentOS for timeliness.
Timeliness, dunno. Ubuntu (or fedora) for production? NOT IF I HAVE ANY CONTROL!!! Given how many developers write incredibly fragile code, that is utterly dependent upon a very, very special environment, I guarantee that the almost daily updates will break it, or the New Features!
I've been running Ubuntu boxes (in production) at various companies without a hitch - initially with a lot of skepticism. There's also one company where I support twenty Fedora boxes (which is a pain because there isn't an LTS version) but I kicked off that company's use of Linux with RH (not RHEL) 5 and the IT manager doesn't want to move to another distribution.
On 06/14/2011 06:19 AM, m.roth@5-cent.us wrote:
Timeliness, dunno. Ubuntu (or fedora) for production? NOT IF I HAVE ANY CONTROL!!! Given how many developers write incredibly fragile code, that is utterly dependent upon a very, very special environment, I guarantee that the almost daily updates will break it, or the New Features! will have changed interfaces....
The LTS server releases are very good. I use them routinely and they have been quite stable. I currently use them for all new 'base metal' server installations with my CentOS systems in VMs on top of them. Over the next few years I anticipate migrating everything at all levels to them as I get more comfortable with it. My only real complaint is having to learn the way a Debian derived system hangs together vs how a Redhat derived system is put together.
And AppArmor has yet to 'knee-cap' me like SELinux has (repeatedly) by breaking previously stable systems. Where I routinely disable SELinux on CentOS, I have yet to have AppArmor interfere with normal ops - ever. It "just works".
Benjamin Franz wrote:
On 06/14/2011 06:19 AM, m.roth@5-cent.us wrote:
Timeliness, dunno. Ubuntu (or fedora) for production? NOT IF I HAVE ANY CONTROL!!! Given how many developers write incredibly fragile code, that is utterly dependent upon a very, very special environment, I guarantee that the almost daily updates will break it, or the New Features! will have changed interfaces....
<snip>
And AppArmor has yet to 'knee-cap' me like SELinux has (repeatedly) by breaking previously stable systems. Where I routinely disable SELinux on CentOS, I have yet to have AppArmor interfere with normal ops - ever. It "just works".
Ok... do you have in-house developed software? I've got one team that's using ruby on rails, and the other admin has to compile it from source, because they, I mean, just *have* to have the latest version, and another team has a customized version of some software that is either licensed, or open source, don't remember, that's all in java, and then there's the parallel processing programs....
But the first two, esp the first, are *incredibly* fragile, and I've seen that in other places I've worked. Then there was the grief I had on a box that's only used for offline backups on encrytped drives, and going from 10? 11? to 13 was a nightmare, and X wouldn't work until I got rid of gnome, and put KDE on....
I want solid and stable.
mark, http://xkcd.org/705
On 6/14/2011 10:06 AM, m.roth@5-cent.us wrote:
Benjamin Franz wrote:
On 06/14/2011 06:19 AM, m.roth@5-cent.us wrote:
Timeliness, dunno. Ubuntu (or fedora) for production? NOT IF I HAVE ANY CONTROL!!! Given how many developers write incredibly fragile code, that is utterly dependent upon a very, very special environment, I guarantee that the almost daily updates will break it, or the New Features! will have changed interfaces....
<snip> > And AppArmor has yet to 'knee-cap' me like SELinux has (repeatedly) by > breaking previously stable systems. Where I routinely disable SELinux on > CentOS, I have yet to have AppArmor interfere with normal ops - ever. It > "just works".
Ok... do you have in-house developed software? I've got one team that's using ruby on rails, and the other admin has to compile it from source, because they, I mean, just *have* to have the latest version, and another team has a customized version of some software that is either licensed, or open source, don't remember, that's all in java, and then there's the parallel processing programs....
But the first two, esp the first, are *incredibly* fragile, and I've seen that in other places I've worked. Then there was the grief I had on a box that's only used for offline backups on encrytped drives, and going from 10? 11? to 13 was a nightmare, and X wouldn't work until I got rid of gnome, and put KDE on....
I want solid and stable.
I don't get the comparisons. Do you have some specific bad experience with LTS to make this relevant? If you are building stuff from source, the distribution packages are basically irrelevant - and in java the whole OS is mostly irrelevant. Fedora releases are rather clearly alpha/beta versions intending to lead up to RHEL after a lot of bugfix/QA work to stabilize it. But ubuntu isn't like that - they don't push stuff out just to get testing for some later money making release, it is the best they can do in the first place with an emphasis on ease of installation and use. The LTS versions are even designed to do major-rev upgrades over the network - and it has worked on the machines where I've tried it.
On Tuesday, June 14, 2011 11:23 PM, Les Mikesell wrote:
On 6/14/2011 10:06 AM, m.roth@5-cent.us wrote:
Benjamin Franz wrote:
On 06/14/2011 06:19 AM, m.roth@5-cent.us wrote:
Timeliness, dunno. Ubuntu (or fedora) for production? NOT IF I HAVE ANY CONTROL!!! Given how many developers write incredibly fragile code, that is utterly dependent upon a very, very special environment, I guarantee that the almost daily updates will break it, or the New Features! will have changed interfaces....
<snip> > And AppArmor has yet to 'knee-cap' me like SELinux has (repeatedly) by > breaking previously stable systems. Where I routinely disable SELinux on > CentOS, I have yet to have AppArmor interfere with normal ops - ever. It > "just works".
Ok... do you have in-house developed software? I've got one team that's using ruby on rails, and the other admin has to compile it from source, because they, I mean, just *have* to have the latest version, and another team has a customized version of some software that is either licensed, or open source, don't remember, that's all in java, and then there's the parallel processing programs....
But the first two, esp the first, are *incredibly* fragile, and I've seen that in other places I've worked. Then there was the grief I had on a box that's only used for offline backups on encrytped drives, and going from 10? 11? to 13 was a nightmare, and X wouldn't work until I got rid of gnome, and put KDE on....
I want solid and stable.
I don't get the comparisons. Do you have some specific bad experience with LTS to make this relevant? If you are building stuff from source, the distribution packages are basically irrelevant - and in java the whole OS is mostly irrelevant. Fedora releases are rather clearly alpha/beta versions intending to lead up to RHEL after a lot of bugfix/QA work to stabilize it. But ubuntu isn't like that - they don't push stuff out just to get testing for some later money making release,
Okay, so you don't have to pay for LTS but unless I am mistaken, Canonical only offers paid support for LTS releases.
it is the best they can do in the first place with an emphasis on ease of installation and use. The LTS versions are even designed to do major-rev upgrades over the network - and it has worked on the machines where I've tried it.
Non-LTS are virtually the same as Fedora releases; experimental releases. Even some LTS releases get pushed out the door with major bugs in various packages. The only plus is that it is possible to do major-rev upgrades provided that you do not use third-party repos.
Every Ubuntu release has been fraught with the screams of victims who had their dist-upgrade blow up in their face whether LTS or non-LTS release. Okay, I personally have not had major problems, but it sure does not inspire confidence.
Christopher Chan wrote:
On Tuesday, June 14, 2011 11:23 PM, Les Mikesell wrote:
On 6/14/2011 10:06 AM, m.roth@5-cent.us wrote:
Benjamin Franz wrote:
On 06/14/2011 06:19 AM, m.roth@5-cent.us wrote:
<MVNCH>
Non-LTS are virtually the same as Fedora releases; experimental releases. Even some LTS releases get pushed out the door with major bugs in various packages. The only plus is that it is possible to do major-rev upgrades provided that you do not use third-party repos.
Every Ubuntu release has been fraught with the screams of victims who had their dist-upgrade blow up in their face whether LTS or non-LTS release. Okay, I personally have not had major problems, but it sure does not inspire confidence.
Odd you should mention it - a friend on a techie mailing list just tried to set up dual-boot XP w/ ubuntu, and had all *kinds* of grief, dunno if she just restored XP. Wouldn't recognize her USB keyboard, didn't get the graphics card and monitor right (which does surprise me), and she had fun trying to find in which submenu the X settings were (applications, not system!).
mark
On 6/14/2011 10:48 AM, m.roth@5-cent.us wrote:
Non-LTS are virtually the same as Fedora releases; experimental releases. Even some LTS releases get pushed out the door with major bugs in various packages. The only plus is that it is possible to do major-rev upgrades provided that you do not use third-party repos.
Every Ubuntu release has been fraught with the screams of victims who had their dist-upgrade blow up in their face whether LTS or non-LTS release. Okay, I personally have not had major problems, but it sure does not inspire confidence.
Odd you should mention it - a friend on a techie mailing list just tried to set up dual-boot XP w/ ubuntu, and had all *kinds* of grief, dunno if she just restored XP. Wouldn't recognize her USB keyboard, didn't get the graphics card and monitor right (which does surprise me), and she had fun trying to find in which submenu the X settings were (applications, not system!).
I suppose there is hardware that nothing but pre-installed windows will recognize.... But I happen to have a dual-boot XP/Ubuntu laptop where I can run the ubuntu session either natively or under VMware player and it just pops up a dialog asking if I want to run in low-res or reconfigure X (which it does automatically) when I switch between the modes and it sees different hardware. And it detects a USB keyboard just fine, whether hot plugged or present at boot time. So, I don't think your friend's experience is typical and it certainly doesn't match mine. By the way, my install was originally a 9.x LTS, upgraded to a 10.x over the network while running under vmware and I installed it in the first place because Centos didn't include a driver for the wifi and ubuntu 'just worked'.
On Tue, Jun 14, 2011 at 11:37 AM, Les Mikesell lesmikesell@gmail.com wrote:
By the way, my install was originally a 9.x LTS, upgraded to a 10.x over the network while running under vmware and I installed it in the first place because Centos didn't include a driver for the wifi and ubuntu 'just worked'.
Opposite of my experience. All functions on my Dell work with CentOS, including "sleep," etc. Linux Mint can't replicate that -- if I close the lid, for example, I have to reboot. I haven't been able to find a fix for this. But I think it depends on your hardware.
On 6/14/2011 5:00 PM, Ron Blizzard wrote:
On Tue, Jun 14, 2011 at 11:37 AM, Les Mikeselllesmikesell@gmail.com wrote:
By the way, my install was originally a 9.x LTS, upgraded to a 10.x over the network while running under vmware and I installed it in the first place because Centos didn't include a driver for the wifi and ubuntu 'just worked'.
Opposite of my experience. All functions on my Dell work with CentOS,
Do you have something other than an intel wifi chip? At least at the time I installed, CentOS did not include the firmware. I might have been able to fix that, but I also had trouble with WPA2 password setting in another scenario and ubunutu seemed much more adept about managing connections. Maybe CentOS has gotten better with current updates.
On Tue, Jun 14, 2011 at 5:24 PM, Les Mikesell lesmikesell@gmail.com wrote:
Do you have something other than an intel wifi chip?
No, not any more. I had a Broadcom card, but an older laptop we gave away needed a WiFi card, so I invested $12 into an Intel card on eBay and installed the Broadcom card in the "old" laptop (it worked fine under Windows). I got the Broadcom working with FWCutter under CentOS, but its speed was all over the place. The thing I've never been able to get working in Linux Mint, is the hibernation. If I close the lid, it locks, unless I "hibernate" it first. But the main thing I don't like about Ubuntu/Mint is that each upgrade is an "adventure." Of course, CentOS 6 won't work on my laptop (no PAE) but I've still got CentOS 5.x for that. We'll see what issues it has on desktop. I'm hoping that installing the proprietary Nvidia drivers won't be the hassle they are under Linux Mint. Nouveau is getting better, but it's still not good enough.
Ron Blizzard wrote:
On Tue, Jun 14, 2011 at 5:24 PM, Les Mikesell lesmikesell@gmail.com wrote:
Do you have something other than an intel wifi chip?
No, not any more. I had a Broadcom card, but an older laptop we gave away needed a WiFi card, so I invested $12 into an Intel card on eBay and installed the Broadcom card in the "old" laptop (it worked fine under Windows). I got the Broadcom working with FWCutter under CentOS, but its speed was all over the place. The thing I've never been able to get working in Linux Mint, is the hibernation. If I close the lid, it locks, unless I "hibernate" it first. But the main thing I don't like about Ubuntu/Mint is that each upgrade is an "adventure." Of course, CentOS 6 won't work on my laptop (no PAE) but I've still got CentOS 5.x for that. We'll see what issues it has on desktop. I'm hoping that installing the proprietary Nvidia drivers won't be the hassle they are under Linux Mint. Nouveau is getting better, but it's still not good enough.
Since Pentium Pro, only old 400 MHz-bus versions of the Pentium M lack PAE support. I have 3-4 years MSI VR-601 that works flawlessly on RHEL 6 Beta. I had to play with grub boot line (nomodeset) for better Intel graphics, and when I pull out power he hibernates, but it's working exceptionally well.
Ljubomir
On Wed, Jun 15, 2011 at 2:09 AM, Ljubomir Ljubojevic office@plnet.rs wrote:
Since Pentium Pro, only old 400 MHz-bus versions of the Pentium M lack PAE support.
This laptop is a Latitude D400, which I think were made in 2005. It definitely doesn't have PAE support. I discovered that when I tried to test Red Hat beta 6 on it. It's okay though, it probably won't last much longer than CentOS 5 support anyhow. It'll work out fine.
I'm hoping CentOS doesn't fight me when I try to load the proprietary nVidia driver on the desktop. The only way I could do it in Linux Mint was to blacklist Nouveau in the Grub boot menu. And Mint/Ubuntu don't have an easy way to boot into the command line (when you just want to do it for maintenance, like installing a video driver).
Ron Blizzard wrote:
On Wed, Jun 15, 2011 at 2:09 AM, Ljubomir Ljubojevic office@plnet.rs wrote:
Since Pentium Pro, only old 400 MHz-bus versions of the Pentium M lack PAE support.
This laptop is a Latitude D400, which I think were made in 2005. It definitely doesn't have PAE support. I discovered that when I tried to test Red Hat beta 6 on it. It's okay though, it probably won't last much longer than CentOS 5 support anyhow. It'll work out fine.
I'm hoping CentOS doesn't fight me when I try to load the proprietary nVidia driver on the desktop. The only way I could do it in Linux Mint was to blacklist Nouveau in the Grub boot menu. And Mint/Ubuntu don't have an easy way to boot into the command line (when you just want to do it for maintenance, like installing a video driver).
ElRepo has kernel modules already compiled: http://elrepo.org/tiki/kmod-nvidia so I guess it should be OK. Playing around with recompiling nVidia drivers was a real pain in a ....
Ljubomir
On Wed, Jun 15, 2011 at 5:09 AM, Ljubomir Ljubojevic office@plnet.rs wrote:
ElRepo has kernel modules already compiled: http://elrepo.org/tiki/kmod-nvidia so I guess it should be OK. Playing around with recompiling nVidia drivers was a real pain in a ....
Bookmarked. Thanks.
On Wed, Jun 15, 2011 at 5:58 AM, Ron Blizzard rb4centos@gmail.com wrote:
Mint/Ubuntu don't have an easy way to boot into the command line.
To boot into "everything but X", you can append "text" to the kernel (grub1) or linux (grub2) line in the grub configuration.
On Wed, Jun 15, 2011 at 2:37 PM, Tom H tomh0665@gmail.com wrote:
On Wed, Jun 15, 2011 at 5:58 AM, Ron Blizzard rb4centos@gmail.com wrote:
Mint/Ubuntu don't have an easy way to boot into the command line.
To boot into "everything but X", you can append "text" to the kernel (grub1) or linux (grub2) line in the grub configuration.
Okay, thanks. Good to know. I forget what "kludging" process I had to go through to get Mint to boot into text, I think I disabled the X server somehow. But even when I got to text mode, the Nouveau driver had loaded, which is why I eventually had to blacklist it before installing the proprietary nVidia driver.
Ron Blizzard wrote:
On Wed, Jun 15, 2011 at 2:37 PM, Tom H tomh0665@gmail.com wrote:
On Wed, Jun 15, 2011 at 5:58 AM, Ron Blizzard rb4centos@gmail.com wrote:
Mint/Ubuntu don't have an easy way to boot into the command line.
To boot into "everything but X", you can append "text" to the kernel (grub1) or linux (grub2) line in the grub configuration.
Okay, thanks. Good to know. I forget what "kludging" process I had to go through to get Mint to boot into text, I think I disabled the X server somehow. But even when I got to text mode, the Nouveau driver had loaded, which is why I eventually had to blacklist it before installing the proprietary nVidia driver.
Or edit /etc/inittab to boot to runlevel 3, or just init 3 from the command line (which you can reach via <ctrl><alt>-f1) or I think you can append 3 to the kernel line....
mark
On Jun 15, 2011, at 1:47 PM, m.roth@5-cent.us wrote:
Ron Blizzard wrote:
On Wed, Jun 15, 2011 at 2:37 PM, Tom H tomh0665@gmail.com wrote:
On Wed, Jun 15, 2011 at 5:58 AM, Ron Blizzard rb4centos@gmail.com wrote:
Mint/Ubuntu don't have an easy way to boot into the command line.
To boot into "everything but X", you can append "text" to the kernel (grub1) or linux (grub2) line in the grub configuration.
Okay, thanks. Good to know. I forget what "kludging" process I had to go through to get Mint to boot into text, I think I disabled the X server somehow. But even when I got to text mode, the Nouveau driver had loaded, which is why I eventually had to blacklist it before installing the proprietary nVidia driver.
Or edit /etc/inittab to boot to runlevel 3, or just init 3 from the command line (which you can reach via <ctrl><alt>-f1) or I think you can append 3 to the kernel line....
---- those days will be over soon as even fedora has now switched to upstart
CentOS 7 (based on upstream 7) will be a vastly different beast
Craig
On 06/15/2011 03:08 PM, Craig White wrote:
those days will be over soon as even fedora has now switched to upstart
Upstart would still honor the setting in /etc/inittab.
Fedora, however, is now using systemd. It's an even more different beast than you are familiar with: http://0pointer.de/blog/projects/systemd.html
On Wed, Jun 15, 2011 at 6:08 PM, Craig White craig.white@ttiltd.com wrote:
those days will be over soon as even fedora has now switched to upstart
CentOS 7 (based on upstream 7) will be a vastly different beast
CentOS 7 will most probably have systemd not upstart.
On Wed, Jun 15, 2011 at 3:47 PM, m.roth@5-cent.us wrote:
Ron Blizzard wrote:
Okay, thanks. Good to know. I forget what "kludging" process I had to go through to get Mint to boot into text, I think I disabled the X server somehow. But even when I got to text mode, the Nouveau driver had loaded, which is why I eventually had to blacklist it before installing the proprietary nVidia driver.
Or edit /etc/inittab to boot to runlevel 3, or just init 3 from the command line (which you can reach via <ctrl><alt>-f1) or I think you can append 3 to the kernel line....
That was the first thing I tried (coming from the CentOS world). I don't think there is any such thing as "runlevel 3" in Ubuntu/Mint. They use a different model. But the "text" entry did the job -- glad to know that (thanks). (I wonder why no one on the Ubuntu/Mint forums pointed me to that.) As for <cntr>-<alt>-f1, that gets me to the CLI, but, by that point, the Xorg has already been loaded. So it didn't help with installing the proprietary nVidia driver. As a matter of fact, even when I got it to log into non-graphics mode (doing whatever it was that I did), the Nouveau driver was still loaded -- which is why it had to be blacklisted in Grub.
On Wed, Jun 15, 2011 at 4:47 PM, m.roth@5-cent.us wrote:
Or edit /etc/inittab to boot to runlevel 3, or just init 3 from the command line (which you can reach via <ctrl><alt>-f1) or I think you can append 3 to the kernel line...
That doesn't work on Debian/Ubuntu because runlevels 2-5 are the same.
On Thu, Jun 16, 2011 at 07:17:38AM -0400, Tom H wrote:
On Wed, Jun 15, 2011 at 4:47 PM, m.roth@5-cent.us wrote:
Or edit /etc/inittab to boot to runlevel 3, or just init 3 from the command line (which you can reach via <ctrl><alt>-f1) or I think you can append 3 to the kernel line...
That doesn't work on Debian/Ubuntu because runlevels 2-5 are the same.
I remember in Debian it was update-rc.d -f xdm remove
I would guess something similar (gdm?) remove would work.
Scott Robbins wrote:
On Thu, Jun 16, 2011 at 07:17:38AM -0400, Tom H wrote:
On Wed, Jun 15, 2011 at 4:47 PM, m.roth@5-cent.us wrote:
Or edit /etc/inittab to boot to runlevel 3, or just init 3 from the command line (which you can reach via <ctrl><alt>-f1) or I think you can append 3 to the kernel line...
That doesn't work on Debian/Ubuntu because runlevels 2-5 are the same.
?!?!?! 2 isn't much used, except as a set of steps. But 3 and 5 are the same in Debian/Ubuntu? That's not like *any* other version of *Nix. <snip> mark
On Thu, Jun 16, 2011 at 02:15:28PM +0100, m.roth@5-cent.us wrote:
Scott Robbins wrote:
On Thu, Jun 16, 2011 at 07:17:38AM -0400, Tom H wrote:
On Wed, Jun 15, 2011 at 4:47 PM, m.roth@5-cent.us wrote:
Or edit /etc/inittab to boot to runlevel 3, or just init 3 from the command line (which you can reach via <ctrl><alt>-f1) or I think you can append 3 to the kernel line...
That doesn't work on Debian/Ubuntu because runlevels 2-5 are the same.
?!?!?! 2 isn't much used, except as a set of steps. But 3 and 5 are the same in Debian/Ubuntu? That's not like *any* other version of *Nix.
<snip> mark
Debian's configuration (at least wrt 3 and 5 being aliases for the same runlevel) is very similar to Slackware and Gentoo. The number and use of runlevels, traditionally, have not been defined (although the LSB has tried to address this) and different conventions have been used in various distributions (and, move widely, unices) - the use of 7 runlevels out of a possible 10 also appears to be more convention than any hard-and-fast rule. That said the convention used by CentOS does appear to be the most common (and closest to the LSB's definition) in use by Linux distros today.
On System V and Solaris runlevel 5 is halt so you might get a nasty surprise if you were expecting X11!
Laurence
Laurence Hurst wrote:
On Thu, Jun 16, 2011 at 02:15:28PM +0100, m.roth@5-cent.us wrote:
Scott Robbins wrote:
On Thu, Jun 16, 2011 at 07:17:38AM -0400, Tom H wrote:
On Wed, Jun 15, 2011 at 4:47 PM, m.roth@5-cent.us wrote:
Or edit /etc/inittab to boot to runlevel 3, or just init 3 from the command line (which you can reach via <ctrl><alt>-f1) or I think you can append 3 to the kernel line...
That doesn't work on Debian/Ubuntu because runlevels 2-5 are the
same.
?!?!?! 2 isn't much used, except as a set of steps. But 3 and 5 are the same in Debian/Ubuntu? That's not like *any* other version of *Nix.
<snip>
Debian's configuration (at least wrt 3 and 5 being aliases for the same runlevel) is very similar to Slackware and Gentoo. The number and use of
Haven't used slackware since, um, '95 or so.
runlevels, traditionally, have not been defined (although the LSB has
In Linux? I mean, runlevel 3 was multi-user text mode as far back as Sun OS - I can remember putting things into 3, because X would while () { crash respawn }
tried to address this) and different conventions have been used in various distributions (and, move widely, unices) - the use of 7 runlevels out of a possible 10 also appears to be more convention than any hard-and-fast rule. That said the convention used by CentOS does appear to be the most common (and closest to the LSB's definition) in use by Linux distros today.
On System V and Solaris runlevel 5 is halt so you might get a nasty surprise if you were expecting X11!
<g>
mark
On 6/16/2011 10:43 AM, m.roth@5-cent.us wrote:
runlevels, traditionally, have not been defined (although the LSB has
In Linux? I mean, runlevel 3 was multi-user text mode as far back as Sun OS - I can remember putting things into 3, because X would while () { crash respawn }
Originally runlevel 2 was multiuser, 3 was multiuser with networking and network daemons. Without serial terminals, that wouldn't make a lot of sense...
On System V and Solaris runlevel 5 is halt so you might get a nasty surprise if you were expecting X11!
I think adding 5 for X was a Linux kludge. And in the original sysV design, I believe each runlevel was executed in sequence up and down. That is, everything started in runlevel 1 and 2 started on the way to 3 and could be sequenced properly that way instead of jumping directly to 3 or 5 and having to have everything specified to start there.
On 06/16/2011 12:41 PM, Les Mikesell wrote:
On 6/16/2011 10:43 AM, m.roth@5-cent.us wrote:
runlevels, traditionally, have not been defined (although the LSB has
In Linux? I mean, runlevel 3 was multi-user text mode as far back as Sun OS - I can remember putting things into 3, because X would while () { crash respawn }
Originally runlevel 2 was multiuser, 3 was multiuser with networking and network daemons. Without serial terminals, that wouldn't make a lot of sense...
On System V and Solaris runlevel 5 is halt so you might get a nasty surprise if you were expecting X11!
I think adding 5 for X was a Linux kludge. And in the original sysV design, I believe each runlevel was executed in sequence up and down. That is, everything started in runlevel 1 and 2 started on the way to 3 and could be sequenced properly that way instead of jumping directly to 3 or 5 and having to have everything specified to start there.
No. I worked with both SCO and ISC linux in the late 80's and early 90's and run level 5 was used for X. In fact I think it was used also in DGUX for X.
On 06/16/2011 12:58 PM, Steve Clark wrote:
On 06/16/2011 12:41 PM, Les Mikesell wrote:
On 6/16/2011 10:43 AM,m.roth@5-cent.us wrote:
runlevels, traditionally, have not been defined (although the LSB has
In Linux? I mean, runlevel 3 was multi-user text mode as far back as Sun OS - I can remember putting things into 3, because X would while () { crash respawn }
Originally runlevel 2 was multiuser, 3 was multiuser with networking and network daemons. Without serial terminals, that wouldn't make a lot of sense...
On System V and Solaris runlevel 5 is halt so you might get a nasty surprise if you were expecting X11!
I think adding 5 for X was a Linux kludge. And in the original sysV design, I believe each runlevel was executed in sequence up and down. That is, everything started in runlevel 1 and 2 started on the way to 3 and could be sequenced properly that way instead of jumping directly to 3 or 5 and having to have everything specified to start there.
No. I worked with both SCO and ISC linux in the late 80's and early 90's and run level 5 was used for X. In fact I think it was used also in DGUX for X.
Oops meant to say SCO UNIX and ISC UNIX not linux.
No. I worked with both SCO and ISC linux in the late 80's and early 90's and run level 5 was used for X. In fact I think it was used also in DGUX for X.
I don't know about ISC UNIX (aka Interactive UNIX) but SCO did not use run level 5 for X. I cut my teeth on System V UNIX including SCO UNIX 3.2 and seeing X in runlevel 5 these days still feels wrong to me all these years later, though I have to come realize how convenient it is.
On Wed, Jun 15, 2011 at 3:48 PM, Ron Blizzard rb4centos@gmail.com wrote:
On Wed, Jun 15, 2011 at 2:37 PM, Tom H tomh0665@gmail.com wrote:
On Wed, Jun 15, 2011 at 5:58 AM, Ron Blizzard rb4centos@gmail.com wrote:
Mint/Ubuntu don't have an easy way to boot into the command line.
To boot into "everything but X", you can append "text" to the kernel (grub1) or linux (grub2) line in the grub configuration.
Okay, thanks. Good to know. I forget what "kludging" process I had to go through to get Mint to boot into text, I think I disabled the X server somehow. But even when I got to text mode, the Nouveau driver had loaded, which is why I eventually had to blacklist it before installing the proprietary nVidia driver.
You're welcome. That's KMS for you; your consoles no longer are "pure text." CentOS 6 might be like that too given that F13 was (I can't remember whether F12 was).
On Wednesday, June 15, 2011 12:37 AM, Les Mikesell wrote: By
the way, my install was originally a 9.x LTS, upgraded to a 10.x over the network while running under vmware and I installed it in the first place because Centos didn't include a driver for the wifi and ubuntu 'just worked'.
There is no 9.x LTS and it is good you did not get bitten but the grub/grub2 switch.
On Tue, Jun 14, 2011 at 10:48 AM, m.roth@5-cent.us wrote:
Odd you should mention it - a friend on a techie mailing list just tried to set up dual-boot XP w/ ubuntu, and had all *kinds* of grief, dunno if she just restored XP. Wouldn't recognize her USB keyboard, didn't get the graphics card and monitor right (which does surprise me), and she had fun trying to find in which submenu the X settings were (applications, not system!).
My brother called this weekend. He's a Windows programmer who has recently started experimenting with Linux. Ubuntu, specifically. He upgraded and then his ATI video card quit working correctly. He finally found the solution, but he searched all day (I was no help to him). I have one partition set up with Linux Mint 10 (because my Dad uses Linux Mint and I want to be able to support him over the phone). Every time I boot up, Nautilus and Gnome-Panel don't come up. (I have to go to a terminal and type "pkill nautilus" and "pkill gnome-panel" to get them to work.) So, although Mint is "pretty" and uses modern packages, it's not rock solid like CentOS. Of course desktops are different than servers and I can only speak from personal (limited) experience.
On 6/14/2011 4:54 PM, Ron Blizzard wrote:
On Tue, Jun 14, 2011 at 10:48 AM,m.roth@5-cent.us wrote:
Odd you should mention it - a friend on a techie mailing list just tried to set up dual-boot XP w/ ubuntu, and had all *kinds* of grief, dunno if she just restored XP. Wouldn't recognize her USB keyboard, didn't get the graphics card and monitor right (which does surprise me), and she had fun trying to find in which submenu the X settings were (applications, not system!).
My brother called this weekend. He's a Windows programmer who has recently started experimenting with Linux. Ubuntu, specifically. He upgraded and then his ATI video card quit working correctly. He finally found the solution, but he searched all day (I was no help to him). I have one partition set up with Linux Mint 10 (because my Dad uses Linux Mint and I want to be able to support him over the phone). Every time I boot up, Nautilus and Gnome-Panel don't come up. (I have to go to a terminal and type "pkill nautilus" and "pkill gnome-panel" to get them to work.) So, although Mint is "pretty" and uses modern packages, it's not rock solid like CentOS. Of course desktops are different than servers and I can only speak from personal (limited) experience.
How much modern hardware do you have running with CentOS in GUI mode? I think these are just generic Linux issues. The last round of servers we got (in a different office) wouldn't even show the CentOS installer screen well enough to fill in the network setup info. This was an IBM 3550 M3 with some sort of Matrox video on board. I'd expect that to be a fairly mainstream server box.
And by the way - if you need to run something yourself just to be able to support someone else you can usually do it under vmware player, virtualbox, etc. It's easier than fighting with real hardware and shutting down whatever else you were doing to use it.
On Tue, Jun 14, 2011 at 5:15 PM, Les Mikesell lesmikesell@gmail.com wrote:
And by the way - if you need to run something yourself just to be able to support someone else you can usually do it under vmware player, virtualbox, etc. It's easier than fighting with real hardware and shutting down whatever else you were doing to use it.
I can, but it's too slow on my "trailing edge" hardware. It's easier to just reboot and not put up with a sluggish VirtualBox machine -- though I do (very rarely) run Win 2K in VirtualBox. Since it has a small footprint it works well there -- and I pull its virtual network plug so it can't go malware hunting.
On Tue, Jun 14, 2011 at 5:54 PM, Ron Blizzard rb4centos@gmail.com wrote:
On Tue, Jun 14, 2011 at 10:48 AM, m.roth@5-cent.us wrote:
Odd you should mention it - a friend on a techie mailing list just tried to set up dual-boot XP w/ ubuntu, and had all *kinds* of grief, dunno if she just restored XP. Wouldn't recognize her USB keyboard, didn't get the graphics card and monitor right (which does surprise me), and she had fun trying to find in which submenu the X settings were (applications, not system!).
My brother called this weekend. He's a Windows programmer who has recently started experimenting with Linux. Ubuntu, specifically. He upgraded and then his ATI video card quit working correctly. He finally found the solution, but he searched all day (I was no help to him). I have one partition set up with Linux Mint 10 (because my Dad uses Linux Mint and I want to be able to support him over the phone). Every time I boot up, Nautilus and Gnome-Panel don't come up. (I have to go to a terminal and type "pkill nautilus" and "pkill gnome-panel" to get them to work.) So, although Mint is "pretty" and uses modern packages, it's not rock solid like CentOS.
I wouldn't generalize based on your experience because Mint hasn't become a very popular distribution by being broken. Same goes for Ubuntu.
On Wednesday, June 15, 2011 08:59 AM, Tom H wrote:
On Tue, Jun 14, 2011 at 5:54 PM, Ron Blizzardrb4centos@gmail.com wrote:
On Tue, Jun 14, 2011 at 10:48 AM,m.roth@5-cent.us wrote:
Odd you should mention it - a friend on a techie mailing list just tried to set up dual-boot XP w/ ubuntu, and had all *kinds* of grief, dunno if she just restored XP. Wouldn't recognize her USB keyboard, didn't get the graphics card and monitor right (which does surprise me), and she had fun trying to find in which submenu the X settings were (applications, not system!).
My brother called this weekend. He's a Windows programmer who has recently started experimenting with Linux. Ubuntu, specifically. He upgraded and then his ATI video card quit working correctly. He finally found the solution, but he searched all day (I was no help to him). I have one partition set up with Linux Mint 10 (because my Dad uses Linux Mint and I want to be able to support him over the phone). Every time I boot up, Nautilus and Gnome-Panel don't come up. (I have to go to a terminal and type "pkill nautilus" and "pkill gnome-panel" to get them to work.) So, although Mint is "pretty" and uses modern packages, it's not rock solid like CentOS.
I wouldn't generalize based on your experience because Mint hasn't become a very popular distribution by being broken. Same goes for Ubuntu.
Yeah, I wondered how it managed to become popular with broken NetworkManager back in the 7.x releases and other goodness like pulseaudio.
Serves me right for recommending something I had not myself tried. Blooming embarrassing having to talk colleague's son through the steps necessary to bring up eth0 and then stick stuff in /etc/resolv.conf.
But hey, it's just trading one set of issues with another anyway. No more compiling Nvidia/ATI binary blob kernel modules was a plus.
In any case, an LTS release for a server is a joke. How many PPA's have you added for your servers?
On 6/14/11 8:29 PM, Christopher Chan wrote:
In any case, an LTS release for a server is a joke. How many PPA's have you added for your servers?
For what? Most of the stuff that you have to use 3rd party repos to get on CentOS is in the stock ubuntu repositories in usably recent versions.
Les Mikesell wrote:
Most of the stuff that you have to use 3rd party repos to get on CentOS is in the stock ubuntu repositories in usably recent versions.
I've found 99% of the things I need on a CentOS (which I only use on home servers) is in the epel repository if it is not in the CentOS repository.
Am I alone in regarding epel as more or less a part of CentOS? Does it have a rival in this role?
What do you need that is not in CentOS + epel?
Surprisingly, all 4 server machines I have seem to support CentOS, or RHEL which I take is the same for this purpose. None of them mention any other kind of Linux. I was surprised to find that the HP MicroServer only supports CentOS/RHEL or WHS, which I've never seen in use.
Timothy Murphy wrote:
Am I alone in regarding epel as more or less a part of CentOS? Does it have a rival in this role?
you may not be alone, but you're still wrong: epel is not part of centos at all. It's just another third party repo. There are others including some reputable and widely used: http://wiki.centos.org/AdditionalResources/Repositories
On 6/15/2011 6:54 AM, Nicolas Thierry-Mieg wrote:
Timothy Murphy wrote:
Am I alone in regarding epel as more or less a part of CentOS? Does it have a rival in this role?
you may not be alone, but you're still wrong: epel is not part of centos at all. It's just another third party repo. There are others including some reputable and widely used: http://wiki.centos.org/AdditionalResources/Repositories
It is the distribution and repository policies that make the third party repos both necessary and problematic.
Start with the upstream distro policy of not including things that aren't source-redistributable or have potential patent issues in the US, so many people are forced elsewhere for usable video drivers and media players. EPEL also follows these policies (being maintained by the same company...) and also has a policy of not overwriting upstream packages (where upstream is RH, not including centos extras/plus...). So EPEL is generally safe as the only 3rd party addition, but it also won't have what you need.
Then there is the usually-followed policy of not updating packages to new versions within the life of the distro. So, for example, subversion stayed at the ancient 1.4.x release shipped with 5.0 well beyond the time the subversion team said to stop using it and update. Rpmforge is the place to go for that sort of thing. Until recently they had everything in one repo and many of the packages were newer than the stock set, making it both useful and dangerous in terms of creating dependency conflicts. It has recently been split into 3 repos so you have more control over replacing stock packages or not (do a 'yum update rpmforge-release' if you have it enabled, then look at the repo entries). But, there is no coordination among the 3rd parties or the main distro. So, if you had updated subversion and viewvc from rpmforge to get code that the developers would still recommend using, and you also had epel enabled, at some point your viewvc package would flip to an update from epel with an incompatible configuration. Then when upstream saw the error of its ways and finally went to a 1.6.x subversion in the base 5.6 release, your update might flip there, with a bunch of unresolved dependencies left over from the running rpmforge package. Fun stuff. For something even weirder, look at what you would have had to do to keep a working and up to date java on a RH-style machine across the life of the 5.x distribution.
On Tue, Jun 14, 2011 at 7:59 PM, Tom H tomh0665@gmail.com wrote:
I wouldn't generalize based on your experience because Mint hasn't become a very popular distribution by being broken. Same goes for Ubuntu.
I don't have to generalize, I go to the forums and see all the issues -- often the same issues I'm having when I upgrade. What's frustrating about it is that, usually, there are no solutions. You often get the same advice I used to get when running Windows... "upgrade your hardware." I often wonder if these Ubuntu issues are why Linux hasn't been more widely adopted on the Desktop. A lot of people come to Linux via Ubuntu. If an upgrade kills the video driver -- or the sound quits working -- or it doesn't even boot anymore, then their impression of Ubuntu (which many equate with "Linux") is not going to be too good. Ubuntu is cutting edge, kind of like Fedora. I don't use Fedora because I prefer stability over cutting edge features. I choose CentOS over Ubuntu/Mint for the same reason I chose it over Fedora several years ago.
Ron Blizzard wrote:
On Tue, Jun 14, 2011 at 7:59 PM, Tom H tomh0665@gmail.com wrote:
I wouldn't generalize based on your experience because Mint hasn't become a very popular distribution by being broken. Same goes for Ubuntu.
I don't have to generalize, I go to the forums and see all the issues -- often the same issues I'm having when I upgrade. What's frustrating about it is that, usually, there are no solutions. You often get the same advice I used to get when running Windows... "upgrade your hardware." I often wonder if these Ubuntu issues are why Linux hasn't been more widely adopted on the Desktop. A lot of people come to Linux via Ubuntu. If an upgrade kills the video driver -- or the sound quits working -- or it doesn't even boot anymore, then their impression of Ubuntu (which many equate with "Linux") is not going to be too good. Ubuntu is cutting edge, kind of like Fedora. I don't use Fedora because I prefer stability over cutting edge features. I choose CentOS over Ubuntu/Mint for the same reason I chose it over Fedora several years ago.
+10000
On Tue, Jun 14, 2011 at 10:25 PM, Ron Blizzard rb4centos@gmail.com wrote:
On Tue, Jun 14, 2011 at 7:59 PM, Tom H tomh0665@gmail.com wrote:
I wouldn't generalize based on your experience because Mint hasn't become a very popular distribution by being broken. Same goes for Ubuntu.
I don't have to generalize, I go to the forums and see all the issues -- often the same issues I'm having when I upgrade. What's frustrating about it is that, usually, there are no solutions. You often get the same advice I used to get when running Windows... "upgrade your hardware." I often wonder if these Ubuntu issues are why Linux hasn't been more widely adopted on the Desktop. A lot of people come to Linux via Ubuntu. If an upgrade kills the video driver -- or the sound quits working -- or it doesn't even boot anymore, then their impression of Ubuntu (which many equate with "Linux") is not going to be too good. Ubuntu is cutting edge, kind of like Fedora. I don't use Fedora because I prefer stability over cutting edge features. I choose CentOS over Ubuntu/Mint for the same reason I chose it over Fedora several years ago.
I didn't mean to imply that I didn't think that you've encountered problems or that others don't encounter problems (I'm active on and off in ubuntu-users so I see many of the problems that people have) but Ubuntu and Mint wouldn't have become as popular as they have if the majority had problems installing/updating/upgrading. People (including me) prefer cutting-edge installs. I once saw a statistic about Debian that claimed that the majority of Debianites run sid, the permanent beta, unstable edition.
Les Mikesell wrote:
On 6/14/2011 10:06 AM, m.roth@5-cent.us wrote:
Benjamin Franz wrote:
On 06/14/2011 06:19 AM, m.roth@5-cent.us wrote:
Timeliness, dunno. Ubuntu (or fedora) for production? NOT IF I HAVE ANY CONTROL!!! Given how many developers write incredibly fragile code, that is utterly dependent upon a very, very special environment, I guarantee that the almost daily updates will break it, or the New Features! will have changed interfaces....
<snip> > And AppArmor has yet to 'knee-cap' me like SELinux has (repeatedly) by > breaking previously stable systems. Where I routinely disable SELinux > on CentOS, I have yet to have AppArmor interfere with normal ops - ever. > It "just works".
Ok... do you have in-house developed software? I've got one team that's
<snip>
10? 11? to 13 was a nightmare, and X wouldn't work until I got rid of gnome, and put KDE on....
I want solid and stable.
I don't get the comparisons. Do you have some specific bad experience
I guess you don't. Let's start out this way, by defining my use of the word "fragile": this is where software is utterly dependent upon the runtime environment, and on the versions of the executables and libraries they use, and where a sub-release may carry a change in it that breaks the damn thing, because they're using some experimental function (sorry, "method"), or their stuff worked only because some error checking wasn't enabled, and the data and code fell through and worked, and the new version caught it and died.
with LTS to make this relevant? If you are building stuff from source, the distribution packages are basically irrelevant - and in java the whole OS is mostly irrelevant. Fedora releases are rather clearly
Nope - the O/S and all the packages with it *are* the environment that I refer to.
alpha/beta versions intending to lead up to RHEL after a lot of
Yeah, but some people appear to think (or at least that was what I got from the post of the guy I was replying to) that fedora is good enough for production.
bugfix/QA work to stabilize it. But ubuntu isn't like that - they don't push stuff out just to get testing for some later money making release, it is the best they can do in the first place with an emphasis on ease of installation and use. The LTS versions are even designed to do major-rev upgrades over the network - and it has worked on the machines where I've tried it.
Ok, I *only* heard of the desktop emphasis, and that's what I see on my netbook remix. I have not heard of LTS before, or that it was intended for servers. Still, if it has updates as frequently as my netbook does, that would make me nervous about a production environment.
I'll stick with CentOS...oh, that's right, I should only make comments like that on a CentOS list....
mark
On 06/14/2011 08:41 AM, m.roth@5-cent.us wrote:
Yeah, but some people appear to think (or at least that was what I got from the post of the guy I was replying to) that fedora is good enough for production.
*blink*
Absolutely not. I was talking about Ubuntu Server LTS. I don't use Fedora for *anything*. I gave up on it back around FC5.
Ubuntu Server LTS is *very* suitable for production use.
Jerry Franz wrote:
On 06/14/2011 08:41 AM, m.roth@5-cent.us wrote:
Yeah, but some people appear to think (or at least that was what I got from the post of the guy I was replying to) that fedora is good enough for production.
*blink*
Absolutely not. I was talking about Ubuntu Server LTS. I don't use Fedora for *anything*. I gave up on it back around FC5.
Ok, I sit corrected.
Ubuntu Server LTS is *very* suitable for production use.
I'll take your word for it.
mark
On Tue, 2011-06-14 at 08:52 -0700, Jerry Franz wrote:
On 06/14/2011 08:41 AM, m.roth@5-cent.us wrote:
Yeah, but some people appear to think (or at least that was what I got from the post of the guy I was replying to) that fedora is good enough for production.
*blink*
Absolutely not. I was talking about Ubuntu Server LTS. I don't use Fedora for *anything*. I gave up on it back around FC5.
Ubuntu Server LTS is *very* suitable for production use.
---- Like RHEL/CentOS, Ubuntu LTS is absolutely appropriate for server use. In fact, it's sort of refreshing to set up a new server that isn't overloaded with bloat from the very start. Setting up a new VMWare image w/ Ubuntu Server takes at most 10 minutes whereas doing the same w/ CentOS 5 takes almost an hour (easier just to clone my base install copy kept for just that purpose).
I actually use Fedora for my Desktop. It dual boots to Ubuntu but I don't often use it. The only reason that I ever saw people using Fedora for production was because the RHEL/CentOS software packages were so completely out-of-date.
Craig
On Jun 15, 2011, at 4:50 AM, Craig White wrote:
On Tue, 2011-06-14 at 08:52 -0700, Jerry Franz wrote:
Like RHEL/CentOS, Ubuntu LTS is absolutely appropriate for server use. In fact, it's sort of refreshing to set up a new server that isn't overloaded with bloat from the very start. Setting up a new VMWare image w/ Ubuntu Server takes at most 10 minutes whereas doing the same w/ CentOS 5 takes almost an hour (easier just to clone my base install copy kept for just that purpose).
I actually use Fedora for my Desktop. It dual boots to Ubuntu but I don't often use it. The only reason that I ever saw people using Fedora for production was because the RHEL/CentOS software packages were so completely out-of-date.
Craig
-- This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean.
5 hours? What are you choosing when installing CentOS? I use just the Base and it installs in 10 mins on ESXi.
Tommy Craddock
Craig White wrote:
I actually use Fedora for my Desktop. It dual boots to Ubuntu but I don't often use it. The only reason that I ever saw people using Fedora for production was because the RHEL/CentOS software packages were so completely out-of-date.
Time from CentOS 5.0 to 6.0 was marked with popularity explosion of Linux. Many people converted from Windows, and a lot of developers join in the Linux ranks, and hugely increased number of users ant bug reporters helped immensely. Win XP was released 9-10 years ago and some people still prefer it over Win 7.
I would even compare rise of the Linux users with rise of the usefulness of the PC computers in general.
In June 2000, middle to high end PC where powered by 600-800 MHz CPU's with 256-512MB of RAM. It was barely able to run newer DivX movies, or shell we say that DivX encoders were tuned to allow us to be able to watch them. Win XP was bloated an very slow for any cheaper PC.
In 2004, when CentOS 4.0 was released, high end CPU was around Athlon 64 3000+. Cheap PC's were still arround Athlon 2000+ / Sempron 2500+. Memory in cheper PC's was still ~256-512MB with 256MB taken for Win XP Pro it self.
In 2007, when CentOS 5.0 was released, High end CPU's were around Athlon II X2 and Core 2 Duo 3.00GHz. Cheap PC's started to have 64-bit CPU's and 512MB-1GB of memmory. Fedora reached version 7 and Ununtu reached 7.04 Feisty Fawn. People started to get interest in pretty mature Desktop Linuxes.
It is the end of 2006 and begining of 2007 that Ubuntu became a hit among Linux noobs and that is the time when things heated up and many projects started to develop much faster. But RHEL 5.0 was already in the works, and freezing of the packages meant just that.
Today, RHEL 6.0 can easily be used for any desktop (with third repos) and it's stability will do wanders for much more mature view of the Linux Desktop by newcomers or struggling noobs having to deal with thousands of bugs. In April 2009, Ubuntu had 20,000 new bugs, and 48,000 bug open with 41,000 bugs unassigned. Fedora is not much better. So CentOS 6.x will provide modern but stable environment for years to come. I do not see that Linux software will in next 3-4 years evolve so much compeering to last 3-4 years.
Ljubomir
On Tue, 2011-06-14 at 08:52 -0700, Jerry Franz wrote:
On 06/14/2011 08:41 AM, m.roth@5-cent.us wrote:
Yeah, but some people appear to think (or at least that was what I got from the post of the guy I was replying to) that fedora is good enough
for
production.
*blink*
Absolutely not. I was talking about Ubuntu Server LTS. I don't use Fedora for *anything*. I gave up on it back around FC5.
Ubuntu Server LTS is *very* suitable for production use.
Like RHEL/CentOS, Ubuntu LTS is absolutely appropriate for server use. In fact, it's sort of refreshing to set up a new server that isn't overloaded with bloat from the very start. Setting up a new VMWare image w/ Ubuntu Server takes at most 10 minutes whereas doing the same w/ CentOS 5 takes almost an hour (easier just to clone my base install copy kept for just that purpose).
I actually use Fedora for my Desktop. It dual boots to Ubuntu but I don't often use it. The only reason that I ever saw people using Fedora for production was because the RHEL/CentOS software packages were so completely out-of-date.
Your mail to the cyrus-imapd list today shows that not all software on RHEL/CentOS is "so completely out-of-date" compared to Ubuntu server LTS (and we are talking about CentOS 5!). It really depends what you need, sometimes RHEL/CentOS is ancient, sometimes it's Ubuntu.
Simon
On Jun 15, 2011, at 3:16 AM, Simon Matter wrote:
On Tue, 2011-06-14 at 08:52 -0700, Jerry Franz wrote:
On 06/14/2011 08:41 AM, m.roth@5-cent.us wrote:
Yeah, but some people appear to think (or at least that was what I got from the post of the guy I was replying to) that fedora is good enough
for
production.
*blink*
Absolutely not. I was talking about Ubuntu Server LTS. I don't use Fedora for *anything*. I gave up on it back around FC5.
Ubuntu Server LTS is *very* suitable for production use.
Like RHEL/CentOS, Ubuntu LTS is absolutely appropriate for server use. In fact, it's sort of refreshing to set up a new server that isn't overloaded with bloat from the very start. Setting up a new VMWare image w/ Ubuntu Server takes at most 10 minutes whereas doing the same w/ CentOS 5 takes almost an hour (easier just to clone my base install copy kept for just that purpose).
I actually use Fedora for my Desktop. It dual boots to Ubuntu but I don't often use it. The only reason that I ever saw people using Fedora for production was because the RHEL/CentOS software packages were so completely out-of-date.
Your mail to the cyrus-imapd list today shows that not all software on RHEL/CentOS is "so completely out-of-date" compared to Ubuntu server LTS (and we are talking about CentOS 5!). It really depends what you need, sometimes RHEL/CentOS is ancient, sometimes it's Ubuntu.
---- indeed but apparently Debian has just recently released 2.4.x - apparently after I went looking. It wasn't that 2.4.x wasn't available for Ubuntu/Debian, it was just when I enabled the oneiric repo, it was going to replace way too much. I am sure I could have built cyrus-imapd from source but I was trying to stay with packages.
;-)
Craig
On Wed, Jun 15, 2011 at 4:50 AM, Craig White craigwhite@azapple.com wrote:
Like RHEL/CentOS, Ubuntu LTS is absolutely appropriate for server use. In fact, it's sort of refreshing to set up a new server that isn't overloaded with bloat from the very start. Setting up a new VMWare image w/ Ubuntu Server takes at most 10 minutes whereas doing the same w/ CentOS 5 takes almost an hour (easier just to clone my base install copy kept for just that purpose).
I actually use Fedora for my Desktop. It dual boots to Ubuntu but I don't often use it. The only reason that I ever saw people using Fedora for production was because the RHEL/CentOS software packages were so completely out-of-date.
Both CentOS and Ubuntu server installs take as long for me. Are you comparing similar levels of install?!
(I think that your reply about Fedora is about a post where two people are shocked that I'm supporting Fedora in production. In that particular company, it's just a loyalty and familiarity issue, although I'm sure that if I migrated to CentOS, for example, the DBA'd wine about versions and what have you. Also, I've found server installs of the latest versions of Fedora and Ubuntu stable; it's when you add X and a DE that you can end up with issues.)
On Jun 15, 2011, at 12:33 PM, Tom H wrote:
On Wed, Jun 15, 2011 at 4:50 AM, Craig White craigwhite@azapple.com wrote:
Like RHEL/CentOS, Ubuntu LTS is absolutely appropriate for server use. In fact, it's sort of refreshing to set up a new server that isn't overloaded with bloat from the very start. Setting up a new VMWare image w/ Ubuntu Server takes at most 10 minutes whereas doing the same w/ CentOS 5 takes almost an hour (easier just to clone my base install copy kept for just that purpose).
I actually use Fedora for my Desktop. It dual boots to Ubuntu but I don't often use it. The only reason that I ever saw people using Fedora for production was because the RHEL/CentOS software packages were so completely out-of-date.
Both CentOS and Ubuntu server installs take as long for me. Are you comparing similar levels of install?!
---- I am generally interested in a basic install. On this Macintosh, VMWare Fusion, installing 64 bit Ubuntu-server-amd64 it's about 10 minutes. Installing 64 bit CentOS 5.6 x86_64 took about an hour. I didn't time anything but I remember clearly. Of course the install from Ubuntu was a single CD iso and CentOS was a DVD iso and the bandwidth at my office is extremely good.
A similar install is difficult since Ubuntu will have to indicate that you want to install even openssh-server and CentOS (noting that many of the decisions emanate from upstream) by default puts on a full GUI and you have to knowingly trim down the packages to attempt to minimize the installation.
Craig
On Wed, Jun 15, 2011 at 03:04:59PM -0700, Craig White wrote:
I am generally interested in a basic install. On this Macintosh, VMWare Fusion, installing 64 bit Ubuntu-server-amd64 it's about 10 minutes. Installing 64 bit CentOS 5.6 x86_64 took about an hour. I didn't time anything but I remember clearly. Of course the install from Ubuntu was a single CD iso and CentOS was a DVD iso and the bandwidth at my office is extremely good.
DVD vs CD is irrelevant.
I do not in any way believe your claims of an hour-long install process, even if done manually by walking through anaconda screen by screen.
If you are going to make these claims, please provide verifiable and empirical data to support your claims; "but I remember clearly" does not constitute such.
A similar install is difficult since Ubuntu will have to indicate that you want to install even openssh-server and CentOS (noting that many of the decisions emanate from upstream) by default puts on a full GUI and you have to knowingly trim down the packages to attempt to minimize the installation.
A similar environment is completely trivial to set up; use kickstart and trim down to what you want, including what services to have started at boot time or not. kickstart can be set to use a -nobase options which will limit, by default, the packages being installed to only those in the @core group and those marked "mandatory" in the comps.xml catalog.
I can do a minimal install in ~5 minutes under Xen or bare metal using kickstart, including the time to provision the Xen instance. I've no reason to believe that VMware would be significantly slower. By this way, this is on years-old hardware, single core cpus.
John
On 6/15/2011 5:26 PM, John R. Dennison wrote:
On Wed, Jun 15, 2011 at 03:04:59PM -0700, Craig White wrote:
I am generally interested in a basic install. On this Macintosh, VMWare Fusion, installing 64 bit Ubuntu-server-amd64 it's about 10 minutes. Installing 64 bit CentOS 5.6 x86_64 took about an hour. I didn't time anything but I remember clearly. Of course the install from Ubuntu was a single CD iso and CentOS was a DVD iso and the bandwidth at my office is extremely good.
DVD vs CD is irrelevant.
I do not in any way believe your claims of an hour-long install process, even if done manually by walking through anaconda screen by screen.
I've seen vmware disk emulation -> LVM -> partitions run very, very slowly. Didn't diagnose it beyond thinking "if it hurts, don't do it", though. And I don't remember if it was a sparse disk or not, but it probably was. Could have been an issue in the way the growing drive space is allocated on the physical side.
On Wed, Jun 15, 2011 at 05:46:20PM -0500, Les Mikesell wrote:
I've seen vmware disk emulation -> LVM -> partitions run very, very slowly. Didn't diagnose it beyond thinking "if it hurts, don't do it", though. And I don't remember if it was a sparse disk or not, but it probably was. Could have been an issue in the way the growing drive space is allocated on the physical side.
Trainwreck and should not be done in production environments; if this is indeed the cause of "1-hour" installs alternatives should be found as that is simply too pathetic for mere words.
John
On 6/15/2011 5:56 PM, John R. Dennison wrote:
On Wed, Jun 15, 2011 at 05:46:20PM -0500, Les Mikesell wrote:
I've seen vmware disk emulation -> LVM -> partitions run very, very slowly. Didn't diagnose it beyond thinking "if it hurts, don't do it", though. And I don't remember if it was a sparse disk or not, but it probably was. Could have been an issue in the way the growing drive space is allocated on the physical side.
Trainwreck and should not be done in production environments; if this is indeed the cause of "1-hour" installs alternatives should be found as that is simply too pathetic for mere words.
Agreed, but testing something on vmware is a likely first step toward production and bad performance on the first look can warp your opinions. I've mostly avoided LVM since seeing that (and, I think, early problems with duplicate volume names when moving disks around) but it could easily have been the physical seek pattern created when the space was allocated on use in the underlying file.
On Wed, Jun 15, 2011 at 06:15:26PM -0500, Les Mikesell wrote:
Agreed, but testing something on vmware is a likely first step toward production and bad performance on the first look can warp your opinions.
And blaming the OS being installed or the installer itself in such circumstances is less than logical; the first thing to investigate is the virtual environment being used.
John
On 6/15/11 7:08 PM, John R. Dennison wrote:
On Wed, Jun 15, 2011 at 06:15:26PM -0500, Les Mikesell wrote:
Agreed, but testing something on vmware is a likely first step toward production and bad performance on the first look can warp your opinions.
And blaming the OS being installed or the installer itself in such circumstances is less than logical; the first thing to investigate is the virtual environment being used.
I'm not sure I'd go that far when using a different installer (or avoiding LVM) in the same environment gives vastly better results. Even if some quirk of the low level environment really turns out to be responsible its not necessarily the logical thing to check first.
On Wed, Jun 15, 2011 at 08:44:38PM -0500, Les Mikesell wrote:
I'm not sure I'd go that far when using a different installer (or avoiding LVM) in the same environment gives vastly better results. Even if some quirk of the low level environment really turns out to be responsible its not necessarily the logical thing to check first.
I've not seen numbers proving the alleged performance differences.
But you can blame whatever you want. CentOS, on sane configurations of hardware / VM environments does _not_ take an hour to install off of CD/DVD.
John
-- Teachers open the door. You enter by yourself.
-- Chinese Proverb
On 06/15/2011 03:46 PM, Les Mikesell wrote:
I've seen vmware disk emulation -> LVM -> partitions run very, very slowly. Didn't diagnose it beyond thinking "if it hurts, don't do it", though. And I don't remember if it was a sparse disk or not, but it probably was. Could have been an issue in the way the growing drive space is allocated on the physical side.
Any disk layout that doesn't align filesystem blocks with actual disk blocks is going to perform very badly.
On Wed, Jun 15, 2011 at 04:08:11PM -0700, Gordon Messmer wrote:
Any disk layout that doesn't align filesystem blocks with actual disk blocks is going to perform very badly.
I will agree this is possible in real-world environments, yes. I also will say that this is an issue of the admin not fully understanding the environment being used.
John
On Wed, Jun 15, 2011 at 5:26 PM, John R. Dennison jrd@gerdesas.com wrote:
I do not in any way believe your claims of an hour-long install process, even if done manually by walking through anaconda screen by screen.
I've had a couple network installs take a long time (Desktop installs not Servers) but that was because the mirror I chose at random was really slow.
On Wed, Jun 15, 2011 at 06:10:15PM -0500, Ron Blizzard wrote:
I've had a couple network installs take a long time (Desktop installs not Servers) but that was because the mirror I chose at random was really slow.
That's possible, yes; but not germane here as the post stated that he was using DVD and CD media.
John
On Wed, Jun 15, 2011 at 6:04 PM, Craig White craig.white@ttiltd.com wrote:
On Jun 15, 2011, at 12:33 PM, Tom H wrote:
On Wed, Jun 15, 2011 at 4:50 AM, Craig White craigwhite@azapple.com wrote:
Like RHEL/CentOS, Ubuntu LTS is absolutely appropriate for server use. In fact, it's sort of refreshing to set up a new server that isn't overloaded with bloat from the very start. Setting up a new VMWare image w/ Ubuntu Server takes at most 10 minutes whereas doing the same w/ CentOS 5 takes almost an hour (easier just to clone my base install copy kept for just that purpose).
I actually use Fedora for my Desktop. It dual boots to Ubuntu but I don't often use it. The only reason that I ever saw people using Fedora for production was because the RHEL/CentOS software packages were so completely out-of-date.
Both CentOS and Ubuntu server installs take as long for me. Are you comparing similar levels of install?!
I am generally interested in a basic install. On this Macintosh, VMWare Fusion, installing 64 bit Ubuntu-server-amd64 it's about 10 minutes. Installing 64 bit CentOS 5.6 x86_64 took about an hour. I didn't time anything but I remember clearly. Of course the install from Ubuntu was a single CD iso and CentOS was a DVD iso and the bandwidth at my office is extremely good.
A similar install is difficult since Ubuntu will have to indicate that you want to install even openssh-server and CentOS (noting that many of the decisions emanate from upstream) by default puts on a full GUI and you have to knowingly trim down the packages to attempt to minimize the installation.
I don't really understand what you're doing but Ubuntu server and CentOS with a GUI are certainly not the same installs. For me the Ubuntu equivalent of a kickstart "@base" install and a CentOS kickstart "@base" install take pretty much the same time.
On 6/14/2011 10:41 AM, m.roth@5-cent.us wrote:
Ok... do you have in-house developed software? I've got one team that's
<snip> >> 10? 11? to 13 was a nightmare, and X wouldn't work until I got rid of >> gnome, and put KDE on.... >> >> I want solid and stable. > > I don't get the comparisons. Do you have some specific bad experience
I guess you don't.
I didn't mean I don't understand the problem you describe. I just don't understand why you blame anyone but the developers in your scenario.
Let's start out this way, by defining my use of the word "fragile": this is where software is utterly dependent upon the runtime environment, and on the versions of the executables and libraries they use, and where a sub-release may carry a change in it that breaks the damn thing, because they're using some experimental function (sorry, "method"), or their stuff worked only because some error checking wasn't enabled, and the data and code fell through and worked, and the new version caught it and died.
Yes, developers can and do write bad code. Providing them an environment where it mostly just happens to work most of the the time is one approach to dealing with it - but it probably won't play out well in the long run when the the environment has to change for security or hardware support reasons.
Nope - the O/S and all the packages with it *are* the environment that I refer to.
How many of them actually affect a java app (which if done right will be equally at home across linux/mac/windows)? And you couldn't seriously have considered using a CentOS packaged java at all until very recently, so I don't understand thinking that CentOS would have been a solution for this.
alpha/beta versions intending to lead up to RHEL after a lot of
Yeah, but some people appear to think (or at least that was what I got from the post of the guy I was replying to) that fedora is good enough for production.
Nobody thinks that for long - or with large numbers of machines.
Ok, I *only* heard of the desktop emphasis, and that's what I see on my netbook remix. I have not heard of LTS before, or that it was intended for servers. Still, if it has updates as frequently as my netbook does, that would make me nervous about a production environment.
I'll stick with CentOS...oh, that's right, I should only make comments like that on a CentOS list....
OK, but what was that about things like ruby and java? (Java being more or less OK now...). If you don't use/need software from this decade, then maybe it isn't a big issue for you either way.
Les Mikesell wrote:
On 6/14/2011 10:41 AM, m.roth@5-cent.us wrote:
Ok... do you have in-house developed software? I've got one team that's
<snip> >> 10? 11? to 13 was a nightmare, and X wouldn't work until I got rid of >> gnome, and put KDE on.... >> >> I want solid and stable. > > I don't get the comparisons. Do you have some specific bad experience
I guess you don't.
I didn't mean I don't understand the problem you describe. I just don't understand why you blame anyone but the developers in your scenario.
I'm an admin. I'm a contractor. I have *ZERO* control over what they write, or in what languages. I am *required* to make sure that the environment, that is under my control, doesn't break what they're doing. That leads back to "I want a solid, stable platform". <snip>
Nope - the O/S and all the packages with it *are* the environment that I refer to.
How many of them actually affect a java app (which if done right will be equally at home across linux/mac/windows)? And you couldn't seriously have considered using a CentOS packaged java at all until very recently, so I don't understand thinking that CentOS would have been a solution for this.
Um, sorry, mostly word is to use openjdk. We have one or two projects that have managed to force using Sun Java, though. <snip>
I'll stick with CentOS...oh, that's right, I should only make comments like that on a CentOS list....
OK, but what was that about things like ruby and java? (Java being more or less OK now...). If you don't use/need software from this decade, then maybe it isn't a big issue for you either way.
"This decade"? Oh, come *on* Mike, be real. Just because the languages they use are changing continually doesn't mean that a *language* compiler or interpreter a couple-three years old shouldn't work.
mark "ought to get back to coding some C (k&r)"
On 6/14/2011 12:19 PM, m.roth@5-cent.us wrote:
I'm an admin. I'm a contractor.
Oh - OK. Then you aren't expected to care about the long term consequences.
OK, but what was that about things like ruby and java? (Java being more or less OK now...). If you don't use/need software from this decade, then maybe it isn't a big issue for you either way.
"This decade"? Oh, come *on* Mike, be real. Just because the languages they use are changing continually doesn't mean that a *language* compiler or interpreter a couple-three years old shouldn't work.
The flip side of that is that you are ignoring thousands (millions?) of man-hours of development work in improvements that could be yours for free.
Les Mikesell wrote:
On 6/14/2011 12:19 PM, m.roth@5-cent.us wrote:
I'm an admin. I'm a contractor.
Oh - OK. Then you aren't expected to care about the long term consequences.
Yes, I bloody well am. I work for a federal contractor, and as long as they have the multi-year contract, and my boss likes me, I have the job.
And even if I didn't, as a professional, it friggin' DOES matter to me.
OK, but what was that about things like ruby and java? (Java being more or less OK now...). If you don't use/need software from this decade, then maybe it isn't a big issue for you either way.
"This decade"? Oh, come *on* Mike, be real. Just because the languages they use are changing continually doesn't mean that a *language* compiler or interpreter a couple-three years old shouldn't work.
The flip side of that is that you are ignoring thousands (millions?) of man-hours of development work in improvements that could be yours for free.
They're not *my* work. I don't get the chance to code any more. And yes, improvements... where a language changes year to year? It used to be that it took *years* to get a major change through (say, K&R to ANSI). Now they come along as frequently as updates to, um, fedora. If it were up to me, I wouldn't *touch* some of that stuff till it soaked for a year or two.
Oddly enough, I just read this book review on slashdot, which mentioned something I'd never heard of: the Software Craftsmanship Movement. Seems to be advocating things, some of which I've bitched and moaned about how things sould be done for decades.
mark mark
On Tue, Jun 14, 2011 at 11:41 AM, m.roth@5-cent.us wrote:
Yeah, but some people appear to think (or at least that was what I got from the post of the guy I was replying to) that fedora is good enough for production.
That was me. Using fedora isn't my choice but it's been running fine for the purposes of the company where it's installed for years.
On Tue, 2011-06-14 at 11:06 -0400, m.roth@5-cent.us wrote:
Benjamin Franz wrote:
On 06/14/2011 06:19 AM, m.roth@5-cent.us wrote:
Timeliness, dunno. Ubuntu (or fedora) for production? NOT IF I HAVE ANY CONTROL!!! Given how many developers write incredibly fragile code, that is utterly dependent upon a very, very special environment, I guarantee that the almost daily updates will break it, or the New Features! will have changed interfaces....
<snip> > And AppArmor has yet to 'knee-cap' me like SELinux has (repeatedly) by > breaking previously stable systems. Where I routinely disable SELinux on > CentOS, I have yet to have AppArmor interfere with normal ops - ever. It > "just works".
Ok... do you have in-house developed software? I've got one team that's using ruby on rails, and the other admin has to compile it from source, because they, I mean, just *have* to have the latest version, and another team has a customized version of some software that is either licensed, or open source, don't remember, that's all in java, and then there's the parallel processing programs....
But the first two, esp the first, are *incredibly* fragile, and I've seen that in other places I've worked. Then there was the grief I had on a box that's only used for offline backups on encrytped drives, and going from 10? 11? to 13 was a nightmare, and X wouldn't work until I got rid of gnome, and put KDE on....
I want solid and stable.
---- company I work for is 100% 'in-house developed software' - Ruby on Rails in fact. Switching each box over to Ubuntu - no problems.
X on a server? Solid and stable?
Craig
On Tue, 2011-06-14 at 09:19 -0400, m.roth@5-cent.us wrote:
Craig White wrote:
On Tue, 2011-06-14 at 06:49 -0400, Kanwar Ranbir Sandhu wrote:
On Mon, 2011-06-13 at 09:22 -0700, Craig White wrote:
easier just to give up - I moved my new servers to ubuntu - no more
new CentOS installs any more. I'm just going to maintain the CentOS 5 installs at this point.
Holy shit, man! I'd never, by choice, put in an Ubuntu server. Debian, sure (though I'm a Red Hat and Red Hat based guy), but Ubuntu? Forget it!
I hope you find it as stable and reliable as CentOS.
heck it's still Linux and pretty much the same.
Red Hat went far too long between releases and it is clear to me that I can't possibly rely on CentOS for timeliness.
Timeliness, dunno. Ubuntu (or fedora) for production? NOT IF I HAVE ANY CONTROL!!! Given how many developers write incredibly fragile code, that is utterly dependent upon a very, very special environment, I guarantee that the almost daily updates will break it, or the New Features! will have changed interfaces....
---- Actually the company I work for has been switching from CentOS to Ubuntu - no problems.
The company I worked for last year was switching from CentOS to Ubuntu - no problems.
I don't know the attrition rate but it has been 100% in the companies I have worked for the past 2 years.
I think that some people just get their thinking locked into a specific notion and won't let go.
Craig
heck it's still Linux and pretty much the same.
There's a lot more than just a kernel to break a system.
Red Hat went far too long between releases and it is clear to me that I can't possibly rely on CentOS for timeliness.
Maybe I'm just in a different kind of environment, but why do you *need* more frequent releases? I still run some servers on EL 4 and will only migrate them when they approach End-of-Life status. They work and are up unless I bring them down. Security patches are still being pushed out for them. Sounds like you're looking for a desktop linux - probably best to use Fedora/Ubuntu?
Josh
On Tuesday, June 14, 2011 11:26 PM, Trutwin, Joshua wrote:
heck it's still Linux and pretty much the same.
There's a lot more than just a kernel to break a system.
Red Hat went far too long between releases and it is clear to me that I can't possibly rely on CentOS for timeliness.
Maybe I'm just in a different kind of environment, but why do you *need* more frequent releases? I still run some servers on EL 4 and will only migrate them when they approach End-of-Life status. They work and are up unless I bring them down. Security patches are still being pushed out for them. Sounds like you're looking for a desktop linux - probably best to use Fedora/Ubuntu?
/me hazards a guess...php?
On 13 June 2011 23:53, James B. Byrne byrnejb@harte-lyne.ca wrote:
I just want to say that I really, really, appreciate the information given on this site:
It seems every time I look at that site the dates have changed, last time I looked the external mirrors where to start syncing yesterday. the 13th
Mark Bradbury wrote:
On 13 June 2011 23:53, James B. Byrne <byrnejb@harte-lyne.ca mailto:byrnejb@harte-lyne.ca> wrote:
I just want to say that I really, really, appreciate the information given on this site: http://qaweb.dev.centos.org/qa/calendarIt seems every time I look at that site the dates have changed, last time I looked the external mirrors where to start syncing yesterday. the 13th
yes cool isn't it, that webpage is updated! actually that's what makes it useful. besides, read the title text on that page again: "QA dates are tentative dates for internal planning only. These are not official release dates, but only a guide for the QA team. All target dates are subject to change."
yes cool isn't it, that webpage is updated! actually that's what makes it useful. besides, read the title text on that page again: "QA dates are tentative dates for internal planning only. These are not official release dates, but only a guide for the QA team. All target dates are subject to change."
Which makes it pretty useless.
Mark Bradbury wrote:
yes cool isn't it, that webpage is updated! actually that's what makes it useful. besides, read the title text on that page again: "QA dates are tentative dates for internal planning only. These are not official release dates, but only a guide for the QA team. All target dates are subject to change."Which makes it pretty useless.
Not quite. Those are at least "not before this date". And those are goals set for upcoming period. If issues are found between now and then, then schedule has to be moved. They are not Microsoft to release unfinished product.
But I do think that some kind of announcement that target date might/will not be met should be posted 1-2 days prior to that date. That would make speculations at lowest minimum possible.
Ljubomir
On Mon, June 27, 2011 02:26, Ljubomir Ljubojevic wrote:
Not quite. Those are at least "not before this date". And those are goals set for upcoming period. If issues are found between now and then, then schedule has to be moved. They are not Microsoft to release unfinished product.
But I do think that some kind of announcement that target date might/will not be met should be posted 1-2 days prior to that date. That would make speculations at lowest minimum possible.
I would rather just have an updated list of the packages that have not yet cleared QA provided as a supplement to the current calendar updates. I do not wish to request an ever increasing amount of detail, but it would be nice to see the progress achieved as the QA outstanding list gets shorter and shorter over time.
On 14/06/2011 05:07, Mark Bradbury wrote:
On 13 June 2011 23:53, James B. Byrnebyrnejb@harte-lyne.ca wrote:
I just want to say that I really, really, appreciate the information given on this site:
It seems every time I look at that site the dates have changed, last time I looked the external mirrors where to start syncing yesterday. the 13th
CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
Then 21st, now 24th. Scientific Linux doesn't seem to have these problems. That's why I switched. Don't get it.
gvim
gvim wrote:
Then 21st, now 24th. Scientific Linux doesn't seem to have these problems. That's why I switched. Don't get it.
What 24th are you talking about?
QA site has 16th as pushing to internal mirrors. I was informed that all rpm's are OK, they are just fixing few distro/ISO bugs.
There is a possibility that all rpm's will be pushed to internal mirrors before the 16th, and that only ISO's will have to be pushed once QA team says everything is in order. I hope this will be the case.
It would be nice if even external mirrors are pre-populated and hidden until ISO's are distributed and public announcement is made.
Ljubomir
On 15/06/2011 14:53, Karanbir Singh wrote:
erm, I havent deleted anything. Are you confusing accounts somewhere
Sorry, it was not your Twitter account but one belonging to "cybernautape"
http://twitter.com/#!/CentOS6/status/79206786703433728
gvim
On 06/15/2011 02:59 PM, gvim wrote:
On 15/06/2011 14:53, Karanbir Singh wrote:
erm, I havent deleted anything. Are you confusing accounts somewhere
Sorry, it was not your Twitter account but one belonging to "cybernautape"
I dont know who that is - they are definitely not anyone involved with the CentOS devel or QA process.
- KB
On 15/06/2011 14:53, Karanbir Singh wrote:
erm, I havent deleted anything. Are you confusing accounts somewhere ?
This was the original entry I saw:
http://twitter.com/#!/CentOS6/
gvim
gvim wrote:
On 15/06/2011 14:53, Karanbir Singh wrote:
erm, I havent deleted anything. Are you confusing accounts somewhere ?
This was the original entry I saw:
http://twitter.com/#!/CentOS6/
gvim
I assume that that person made an typo. There was announcement that it will be released on Jun 13th. If he wanted to be safe, he was thinking of writing Jun 14th, but wrote 24th instead. Not sure, but it looks that way, since release date was never even close to 24th.
Karanbir, are there any show-stoppers so far that would move release date?
Ljubomir
On Tue, Jun 14, 2011 at 10:23:38PM +0100, gvim wrote:
Then 21st, now 24th. Scientific Linux doesn't seem to have these problems. That's why I switched. Don't get it.
But yet you felt the need to comment. Bravo.
You realize that SL has people PAID to work on the distro, right? As in their primary job responsibility when releases are pending. You realize that the QA Web calendar are estimates and not hard dates, right?
John
On Tue, 2011-06-14 at 13:37 +0930, Mark Bradbury wrote:
On 13 June 2011 23:53, James B. Byrne byrnejb@harte-lyne.ca wrote:
I just want to say that I really, really, appreciate the information given on this site: http://qaweb.dev.centos.org/qa/calendarIt seems every time I look at that site the dates have changed, last time I looked the external mirrors where to start syncing yesterday. the 13th
---- what's the difference? It's already obsoleted by the .1 release.
Craig
Craig White wrote:
On Tue, 2011-06-14 at 13:37 +0930, Mark Bradbury wrote:
On 13 June 2011 23:53, James B. Byrne byrnejb@harte-lyne.ca wrote:
I just want to say that I really, really, appreciate the information given on this site: http://qaweb.dev.centos.org/qa/calendarIt seems every time I look at that site the dates have changed, last time I looked the external mirrors where to start syncing yesterday. the 13th
what's the difference? It's already obsoleted by the .1 release.
Craig
I am going to start conversion process (5.x to 6.x) as soon as possible. By the time CentOS 6.1 comes out, all I will have to do is upgrade.
Ljubomir
-
aurfalien＠gmail.com -
Benjamin Franz -
Christopher Chan -
Craig White -
Craig White -
Devin Reade -
Geoff Galitz -
Gordon Messmer -
gvim -
James B. Byrne -
Jerry Franz
-
John R. Dennison -
Kanwar Ranbir Sandhu -
Karanbir Singh -
Laurence Hurst -
Les Mikesell -
Ljubomir Ljubojevic -
m.roth＠5-cent.us -
Mark Bradbury -
Michael Simpson -
Nicolas Thierry-Mieg -
NOYK -
Paul Heinlein -
R P Herrold -
robert mena -
Ron Blizzard -
Scott Robbins -
Scott Silva -
Simon Matter -
Steve Clark -
Timothy Murphy -
Tom H -
Tommy E Craddock Jr -
Trutwin, Joshua