Hello Producers "Longevity of Support" is an attractive drawcard for CentOS if it means the exact opposite of Fedora's "short support cycle" that does not provide updating of infrastructural libraries for very long, libraries which newer versions of applications (like Firefox, Thunderbird, Opera etc) depend on and which wont install unless the libraries are also newer versions? But is that what it means -- ie that those infrastructural libraries (libpango, libcairo etc) are continuously updateable to fairly recent versions? If so, the problem is in reconciling that meaning with the reputation of CentOS to only support older versions of applications (eg Firefox-1.5, Thunderbird-1.0 etc). It does reconcile, of course, if the implications are merely that the CentOS user must compile and install the later versions of such applications from source, rather than having the luxury of pre-packaged binaries. It doesn't reconcile if there is some other critical reason why newer such applications just wont install. But which? I ask here because the profusion of vague mission statements and 'target-enduser-profile' claims that litter the internet re '*nix distros' seldom actually address those real issues. And hopefully someone can enlighten. My complex production & developement desktop takes months to fully port to a new OS (or OS-version), so OS updates to get library updates (ala Fedora philosophy) becomes increasingly untenable. Then there is a further question, I'm afraid. Since CentOS also does specifically target the profile of a so-called 'enterprise/server-user' what does that actually entail. Does it mean concrete security strictures which bolt down non-'root' users or does it merely mean the availability of SELinux (but which can be turned OFF)? For instance, (with SELinux OFF), can a user still: (a) su root via Kterm anytime? (b) Access services-admin anytime via Menu+Pam to control printers, modems, daemons etc? (c) compile (d) have 6 to 8 desktops running (e) call up 'konquerorsu.desktop' (root-konqueror with embedded root-Kterm) (f) have normal cron scheduling .......................................................... maybe more, but that's a start. Thanks for listening. Sean
On Fri, 17 Dec 2010, Sean wrote:> To: centos at centos.org > From: Sean <soso at orcon.net.nz> > Subject: [CentOS] two cents or not two cents > > Hello Producers > > "Longevity of Support" is an attractive drawcard for CentOS if it means > the exact opposite of Fedora's "short support cycle" that does not > provide updating of infrastructural libraries for very long, libraries > which newer versions of applications (like Firefox, Thunderbird, Opera > etc) depend on and which wont install unless the libraries are also > newer versions? But is that what it means -- ie that those > infrastructural libraries (libpango, libcairo etc) are continuously > updateable to fairly recent versions? > > If so, the problem is in reconciling that meaning with the reputation of > CentOS to only support older versions of applications (eg Firefox-1.5, > Thunderbird-1.0 etc). It does reconcile, of course, if the implications > are merely that the CentOS user must compile and install the later > versions of such applications from source, rather than having the luxury > of pre-packaged binaries. It doesn't reconcile if there is some other > critical reason why newer such applications just wont install. But which? > > I ask here because the profusion of vague mission statements and > 'target-enduser-profile' claims that litter the internet re '*nix > distros' seldom actually address those real issues. And hopefully > someone can enlighten. My complex production & developement desktop > takes months to fully port to a new OS (or OS-version), so OS updates to > get library updates (ala Fedora philosophy) becomes increasingly untenable.You might be interested in giving my ALI scripts a whirl on a spare machine (even an old laptop) to start with, so you get used to how they work. I wrote these especially to deal with doing a fresh linux installation. karsites.net/centos/anyuser/auto-linux-installer.php I can set up the services I want running in under 10 seconds. Beats sitting there doing it manually for 3 days! The general idea is that you modify the installer scripts to work with a particular system - just do it one time. Then you can replay the scripts as often as you want, to re-install your system. Please let the list know if they help with your installation/update woes. BTW. Some applications such as Firefox need to be updated to their latest versions, otherwise websites will not work with an older version. I had these issues with running an old version of FF on Fedora 8. I went from F8 to F12 using my ALI scripts without any problems. Kind Regards, Keith Roberts -- In theory, theory and practice are the same; in practice they are not. This email was sent from my laptop with Centos 5.5
I'm sorry (I know don't feed the trolls), but recently there have been quite a few remarks resembling this. Also, I'm beginning to believe the remark made earlier by ???, which roughly stated "Each time a new release is due, the flame wars erupt". Just what part of "CentOS is a Mirror or Redhat OS" do you miss? Now please, return to the rpm building and raid/lvm discussions, as I find them very interesting and educational. michael...> -----Original Message----- > From: centos-bounces at centos.org [mailto:centos-bounces at centos.org]On > Behalf Of Sean > Sent: Thursday, December 16, 2010 2:46 PM > To: centos at centos.org > Subject: [CentOS] two cents or not two cents > > > Hello Producers > > "Longevity of Support" is an attractive drawcard for CentOS if it means > the exact opposite of Fedora's "short support cycle" that does not > provide updating of infrastructural libraries for very long, libraries > which newer versions of applications (like Firefox, Thunderbird, Opera > etc) depend on and which wont install unless the libraries are also > newer versions? But is that what it means -- ie that those > infrastructural libraries (libpango, libcairo etc) are continuously > updateable to fairly recent versions? > > If so, the problem is in reconciling that meaning with the reputation of > CentOS to only support older versions of applications (eg Firefox-1.5, > Thunderbird-1.0 etc). It does reconcile, of course, if the implications > are merely that the CentOS user must compile and install the later > versions of such applications from source, rather than having the luxury > of pre-packaged binaries. It doesn't reconcile if there is some other > critical reason why newer such applications just wont install. But which? > > I ask here because the profusion of vague mission statements and > 'target-enduser-profile' claims that litter the internet re '*nix > distros' seldom actually address those real issues. And hopefully > someone can enlighten. My complex production & developement desktop > takes months to fully port to a new OS (or OS-version), so OS updates to > get library updates (ala Fedora philosophy) becomes increasingly untenable. > > Then there is a further question, I'm afraid. Since CentOS also does > specifically target the profile of a so-called 'enterprise/server-user' > what does that actually entail. Does it mean concrete security > strictures which bolt down non-'root' users or does it merely mean the > availability of SELinux (but which can be turned OFF)? For instance, > (with SELinux OFF), can a user still: > (a) su root via Kterm anytime? > (b) Access services-admin anytime via Menu+Pam to control printers, > modems, daemons etc? > (c) compile > (d) have 6 to 8 desktops running > (e) call up 'konquerorsu.desktop' (root-konqueror with embedded root-Kterm) > (f) have normal cron scheduling > .......................................................... maybe more, > but that's a start. > > Thanks for listening. > > Sean > > > > _______________________________________________ > CentOS mailing list > CentOS at centos.org > lists.centos.org/mailman/listinfo/centos >
On Thursday, December 16, 2010 11:45:36 pm Sean wrote:> Hello Producers > > "Longevity of Support" is an attractive drawcard for CentOS if it means > the exact opposite of Fedora's "short support cycle" that does not > provide updating of infrastructural libraries for very long, libraries > which newer versions of applications (like Firefox, Thunderbird, Opera > etc) depend on and which wont install unless the libraries are also > newer versions? But is that what it means -- ie that those > infrastructural libraries (libpango, libcairo etc) are continuously > updateable to fairly recent versions?Longevity (things continue to work without breakage for a long time): This kind of implies "don't keep stuff continously updated to recent versions" don't you think? Support (help if it breaks, security updates etc.): Is often realised by fixing bugs in the shipped versions and/or backporting fixes.> If so, the problem is in reconciling that meaning with the reputation of > CentOS to only support older versions of applications (eg Firefox-1.5, > Thunderbird-1.0 etc)."yum list firefox" on CentOS-5 as of right now: ... firefox.x86_64 3.6.13-2.el5.centos updates> It does reconcile, of course, if the implications > are merely that the CentOS user must compile and install the later > versions of such applications from source, rather than having the luxury > of pre-packaged binaries. It doesn't reconcile if there is some other > critical reason why newer such applications just wont install. But which?It's very hard to get both "I want to run the latest softwares" and "I want it to be stable for many years". When you run something like, for example, CentOS-5 you get stability (this means things to change completely from last month) and a long life (you can run it with updates enabled for many years). What you _don't_ get is the latest upstream version of libfoobar that would allow you to build or install application-whatever. ...> Then there is a further question, I'm afraid. Since CentOS also does > specifically target the profile of a so-called 'enterprise/server-user' > what does that actually entail.It means pretty much what I've outlined above.> Does it mean concrete security > strictures which bolt down non-'root' users or does it merely mean the > availability of SELinux (but which can be turned OFF)? For instance,Enterprise vs. non-enterprise linux has very little to do with default security behaviour. It has more to do with lifetime, support and what kind of 3rd party software and hardware it's been tested and qualified with. /Peter> (with SELinux OFF), can a user still: > (a) su root via Kterm anytime? > (b) Access services-admin anytime via Menu+Pam to control printers, > modems, daemons etc? > (c) compile > (d) have 6 to 8 desktops running > (e) call up 'konquerorsu.desktop' (root-konqueror with embedded root-Kterm) > (f) have normal cron scheduling > .......................................................... maybe more,-------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 198 bytes Desc: This is a digitally signed message part. URL: <lists.centos.org/pipermail/centos/attachments/20101217/68e289ad/attachment-0002.sig>
On Thursday, December 16, 2010 05:45:36 pm Sean wrote:> If so, the problem is in reconciling that meaning with the reputation of > CentOS to only support older versions of applications (eg Firefox-1.5, > Thunderbird-1.0 etc).Where do people get this? On one of my up to date CentOS 5 VM's: [root at zoneminder1 ~]# cat /etc/redhat-release CentOS release 5.5 (Final) [root at zoneminder1 ~]# rpm -qi firefox Name : firefox Relocations: (not relocatable) Version : 3.6.13 Vendor: CentOS [snip] [root at zoneminder1 ~]# yum list thunderbird Available Packages thunderbird.x86_64 2.0.0.24-13.el5.centos updates [root at zoneminder1 ~]# On one of my CentOS 4 boxes, fully up to date: [root at pachyderm ~]# cat /etc/redhat-release CentOS release 4.8 (Final) [root at pachyderm ~]# yum list firefox Available Packages firefox.i386 3.6.13-3.el4.centos update [root at pachyderm ~]# yum list thunderbird Available Packages thunderbird.i386 1.5.0.12-34.el4.centos update [root at pachyderm ~]# Hmmm, how about CentOS 3 (of course, I have DAG enabled on that box, so it shows up): [root at campus root]# cat /etc/redhat-release CentOS release 3.9 (Final) [root at campus root]# yum list firefox [snip] Looking in Available Packages: Name Arch Version Repo -------------------------------------------------------------------------------- firefox i386 0.8-3.1.el3.dag dag And thunderbird isn't available. Not surprised at the age, though, as that's Fedora Core 1 timeframes for C3. So on the currently supported CentOS releases, 4 and 5, Firefox 3.6.13, Firefox 3.6.13 is available. So where does this FUD of 'FF 1.5 only' come from?
On 12/17/10 8:18 AM, Peter Kjellstr?m wrote:> > Longevity (things continue to work without breakage for a long time): > This kind of implies "don't keep stuff continously updated to recent > versions" don't you think?It could work that way if the upstream developers of the thousands of included projects understood the need for backwards compatibility to keep things working. They don't. -- Les Mikesell lesmikesell at gmail.com
On Friday, December 17, 2010 10:55:58 am Les Mikesell wrote:> On 12/17/10 8:18 AM, Peter Kjellstr?m wrote: > > > > Longevity (things continue to work without breakage for a long time): > > This kind of implies "don't keep stuff continously updated to recent > > versions" don't you think? > > It could work that way if the upstream developers of the thousands of included > projects understood the need for backwards compatibility to keep things working. > They don't.In some cases the breakage is intentional. In others, components become unmaintained, or worse. Case in point: way back in KDE 1.x or 2.x days I made up some documents in KWord that included some embedded diagrams using a component included in that old KDE but not in newer KDE. Result? While KWord opens the files ok, there are no longer any embedded diagrams. So I actually keep a really old Linux dist (Mandrake 5.3, or maybe Red Hat 6.2; can't remember at the moment, been too long) around just in case I need to open one of those files; none of the export choices in KWord of that day include the ability to export the diagrams, and I just haven't had time to convert the diagrams (it's been a long time since I needed one of those anyway, long enough that I forget the name of the component....argh....).