CentOS mailing list,
Thank you all for answering my questions and being so supportive over the last few months as I was running CentOS on my home machine.
I have switched over to Ubuntu, and I will be devoting my learning efforts to that distribution from this point on. However, while I'm sure a new distribution will have the inevitable learning curve, a lot of the tips and tricks I learned here will definitely help me get a head start.
Because a "good bye and thank you" message on it's own would not carry new information, I wanted to just offer an observation of mine which might help this list in communicating with future newbies who don't quite grasp CentOS objectives, as I did.
It seems to me there is a division between a developer's focus on how things work, and a newbie's focus on results. Taking my recent situation with finding an MP3 player, I would look at PlayerA, and PlayerB, which both ran on CentOS. One had a great interface, and the other had a good tag editor. But I hoped to find a player that had both features together. Then I look on the web and discover PlayerC, which seems like it might carry both the features I want. I download it, but it doesn't work. I come to the list and ask why, and I'm advised that CentOS is an enterprise level distribution, and not meant for running cutting edge applications. So I'm confused. After all, PlayerC doesn't do anything that PlayerA and PlayerB don't already do on CentOS, it just happens to do them together. How, I wonder, am I doing anything "cutting edge", or that would threaten the stability of CentOS? It took me a while to realize that I was thinking about the results - playing MP3s, for example. But when developers were speaking about "cutting edge", they were speaking about the fact that the makers of the player were using exotic techniques which were incompatible with CentOS. Those techniques are opaque to me, so the miscommunication continued. So my parting advice is to suggest that the next time a newbie can't grasp why CentOS doesn't do what other distributions do, or why some applications don't work even though they are only doing something that other working applications do, that you explain the difference between results and methods. Had I seen that difference earlier, I might not have struggled with CentOS so long. It's clearly not the distribution for me. That's my suggestion, for whatever it's worth. I hope it can help with future newbies, as I would guess that I won't be the last to try CentOS.
Good luck with making CentOS a preeminent enterprise class solution. It's a great distribution, and deserves its due of appreciation.
All the best.
Dave
( Unsubscribing after this message )
Dave Gutteridge wrote:
[snip]
Heh. After a month (or more) of handholding and triggering some of the hairiest catfights on the list in ages, he switches distros....to start it all over again....so he can get his mp3 player app to work. 8-)
I dunno, it just gave me a good chuckle as I sit here draining my basement after the deluge we got in the northeast this last week. (though only a minor inconvenience compared to what happened to people down south)
Cheers,
On 10/16/05, Chris Mauritz chrism@imntv.com wrote:
Dave Gutteridge wrote:
[snip]
Heh. After a month (or more) of handholding and triggering some of the hairiest catfights on the list in ages, he switches distros....to start it all over again....so he can get his mp3 player app to work. 8-)
I dunno, it just gave me a good chuckle as I sit here draining my basement after the deluge we got in the northeast this last week. (though only a minor inconvenience compared to what happened to people down south)
Yeah. Almost as wordy as the other "dearly departed one." The essence of his post(s) is one sentence: CentOS is not the best choice for [bleed|lead]ing edge desktop software.
I, too, have a parallel effort with Ubuntu underway. It has its own purpose and a loyal following.
-- Collins Richey Debugging is twice as hard as writing the code ... If you write the code as cleverly as possible, you are, by definition, not smart enough to debug it. -Brian Kernighan
On Sun, 2005-10-16 at 11:53, Collins Richey wrote:
Yeah. Almost as wordy as the other "dearly departed one."
At least it wasn't 'thanks for all the fish...'.
The essence of his post(s) is one sentence: CentOS is not the best choice for [bleed|lead]ing edge desktop software.
There is quite a lot of traffic both here and on the fedora list about this exact topic. A bit of archive browsing could have saved some trouble. However, in fedora's bleeding edge quest it doesn't guarantee smooth upgrades from one (frequent) release to the next or even that it will work on the same hardware and their list is full of examples where such things break.
I, too, have a parallel effort with Ubuntu underway. It has its own purpose and a loyal following.
Ubuntu hasn't been through a "hard" upgrade yet - like the Linux 2.4 ->2.6 change that older distros have done. It will be interesting to see if they can manage system-level stability while still staying current with applications.
On 10/16/05, Les Mikesell lesmikesell@gmail.com wrote:
On Sun, 2005-10-16 at 11:53, Collins Richey wrote:
Ubuntu hasn't been through a "hard" upgrade yet - like the Linux 2.4 ->2.6 change that older distros have done. It will be interesting to see if they can manage system-level stability while still staying current with applications.
That's a good point. My experience with the Kubuntu 5.04 -> 5.10 upgrade was pretty strange, if not hard, and not something a newbie could have dealt with. The upgrade seemed to come in several chunks (!!!) over a few days. One chunk totally destroyed X requiring a boot to safe mode to get the final chunk.
Ah well, to stray back ON TOPIC, CentOS is a little more stable than that, although it appears that our friends running ATI cards, as always, have a little bit of pain with the 4.1 -> 4.2 upgrade.
-- Collins Richey Debugging is twice as hard as writing the code ... If you write the code as cleverly as possible, you are, by definition, not smart enough to debug it. -Brian Kernighan
Collins Richey wrote:
Ah well, to stray back ON TOPIC, CentOS is a little more stable than that, although it appears that our friends running ATI cards, as always, have a little bit of pain with the 4.1 -> 4.2 upgrade.
I don't think it's an ATI issue. I'm having troubles with vnc, on a machine with an nVidia card (not that the card matters one whit in vnc).
Ben
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On Sun, Oct 16, 2005 at 01:02:15PM -0500, Les Mikesell wrote:
I, too, have a parallel effort with Ubuntu underway. It has its own purpose and a loyal following.
Ubuntu hasn't been through a "hard" upgrade yet - like the Linux 2.4 ->2.6 change that older distros have done. It will be interesting to see if they can manage system-level stability while still staying current with applications.
Oh, a "hard" kernel upgrade should not be that much of a challenge. I want to see them going through a major GLIBC upgrade, like when we went from glibc 2.1 to 2.2. Or, even going back a bit more, when we went from libc5 to glibc. Now THAT was fun :)
[]s
- -- Rodrigo Barbosa rodrigob@suespammers.org "Quid quid Latine dictum sit, altum viditur" "Be excellent to each other ..." - Bill & Ted (Wyld Stallyns)
On Sun, 2005-10-16 at 17:48, Rodrigo Barbosa wrote:
Ubuntu hasn't been through a "hard" upgrade yet - like the Linux 2.4 ->2.6 change that older distros have done. It will be interesting to see if they can manage system-level stability while still staying current with applications.
Oh, a "hard" kernel upgrade should not be that much of a challenge.
Judging from the fedora lists, people do find it to be a real problem when their previously working disk or RAID controller no longer has drivers after an upgrade...
} Chris wrote: } Heh. After a month (or more) of handholding and triggering some of the } hairiest catfights on the list in ages, he switches distros....to start } it all over again....so he can get his mp3 player app to work. 8-)
greetings,
i kind of got a chuckle too. only because i watched this from the get go as well.
ive been watching the follow ups as well and decided to use Chris's post as a jump in.
one thing, unless my eyes totally deceived me, Dave was respectful. I appreciated that quite a bit.
i mostly expected him to stay with CentOS as initially his biggest concern was being able to switch back and forth between English and Japanese wasn't it?
so, it is somewhat humorous that someone would bail on CentOS, (imho) the best and most stable Linux distro, over a multimedia app situation.
Wisdom cries out that we should learn from and apply the lesson(s) from this situation.
i do not know it all, nor do i have time to keep up with everything "linux", yet having used linux since 1993, what i see needed is a section on the www.centos.org website for "new to linux people" that will adequately describe and deal with the initial questions and some professional CentOS salesmanship that is needed to attract and retain people to this cause.
i would entitle it "for the new user" or same with "considering CentOS?" or whatever is right and works.
maybe a "who, what, where, why, when, how much" kinda thing. make some specific trial and error recommendations. get some testimony from new people that have stayed with CentOS after migrations from M$ or other operating systems.
teach ways to migrate that make it less frightening and/or painful in the short and the long run.
i recommend identical parallel machines, yet most people cannot afford that. so, teach installing a second hard drive and/or a multi boot scenmario or whatever needs to be done.
ask to get people involved that use CentOS as a desktop and go for it!!
comments anyone?????
anyways, thanks to everyone that puts in the time for this distro.
- rh
-- Robert Hanson - Abba Communications Computer & Internet Services www.abbacomm.net
On Mon, 2005-10-17 at 00:47 +0900, Dave Gutteridge wrote:
CentOS mailing list,
Thank you all for answering my questions and being so supportive over the last few months as I was running CentOS on my home machine.
I have switched over to Ubuntu, and I will be devoting my learning efforts to that distribution from this point on. However, while I'm sure a new distribution will have the inevitable learning curve, a lot of the tips and tricks I learned here will definitely help me get a head start.
Because a "good bye and thank you" message on it's own would not carry new information, I wanted to just offer an observation of mine which might help this list in communicating with future newbies who don't quite grasp CentOS objectives, as I did.
It seems to me there is a division between a developer's focus on how things work, and a newbie's focus on results. Taking my recent situation with finding an MP3 player, I would look at PlayerA, and PlayerB, which both ran on CentOS. One had a great interface, and the other had a good tag editor. But I hoped to find a player that had both features together. Then I look on the web and discover PlayerC, which seems like it might carry both the features I want. I download it, but it doesn't work. I come to the list and ask why, and I'm advised that CentOS is an enterprise level distribution, and not meant for running cutting edge applications. So I'm confused. After all, PlayerC doesn't do anything that PlayerA and PlayerB don't already do on CentOS, it just happens to do them together. How, I wonder, am I doing anything "cutting edge", or that would threaten the stability of CentOS? It took me a while to realize that I was thinking about the results - playing MP3s, for example. But when developers were speaking about "cutting edge", they were speaking about the fact that the makers of the player were using exotic techniques which were incompatible with CentOS. Those techniques are opaque to me, so the miscommunication continued. So my parting advice is to suggest that the next time a newbie can't grasp why CentOS doesn't do what other distributions do, or why some applications don't work even though they are only doing something that other working applications do, that you explain the difference between results and methods. Had I seen that difference earlier, I might not have struggled with CentOS so long. It's clearly not the distribution for me. That's my suggestion, for whatever it's worth. I hope it can help with future newbies, as I would guess that I won't be the last to try CentOS.
Good luck with making CentOS a preeminent enterprise class solution. It's a great distribution, and deserves its due of appreciation.
All the best.
---- It is incredible that you could learn so much and yet learn so little.
No distribution is all things to all people. As hard as any of them try, there's always a delicate balance between stable and the 'unstable' which tends to have the software and hardware features that you want.
Unfortunately for you, you started with Fedora Core 4 which was extremely experimental with gcc-4 and thereby living up to its promise to push the edge of development when Fedora Core 3 would have given you a stable end user interface with the application suites whereas CentOS prefers the stable and thus doesn't have the diverse end user applications. Fedora Core 4 is working pretty well now.
Ubuntu is a nice distribution but that isn't all things either as you will soon discover and I expect that I will see you again on the Fedora list before too long but who knows.
I know that I told you my recommendation was to have a server distro like CentOS on one system to keep your files, email and stuff and your desktop on another box so that you could wipe it, test another distro and not lose anything as that would give you the best of both worlds - stability and continuity with a desktop capable of using newer software and technology.
As you gain more experience with Linux, you will come to recognize that Linux is not stagnant but an ever growing, ever changing product and that stable means things that have been working long enough now to give you less than you want on your desktop but you shouldn't have to fool around with it and unstable means you gotta fool around with it to get what you want on your desktop.
As for your 'observation' - I'm quite certain that you were given the right story all along, you just didn't know which voices to listen to.
Craig
Dave Gutteridge wrote:
Then I look on the web and discover PlayerC, which seems like it might carry both the features I want. I download it, but it doesn't work. I come to the list and ask why, and I'm advised that CentOS is an enterprise level distribution, and not meant for running cutting edge applications. So I'm confused. After all, PlayerC doesn't do anything that PlayerA and PlayerB don't already do on CentOS, it just happens to do them together. How, I wonder, am I doing anything "cutting edge", or that would threaten the stability of CentOS?
Centos/RHEL is released once every 18 months and is focused on having a (relatively) small set of well tested, stable packages that are mainly aimed at servers and basic desktop functions like web and email. Makes perfect sense that they don't have the latest and greatest mp3 player package.
It took me a while to realize that I was thinking about the results - playing MP3s, for example. But when developers were speaking about "cutting edge", they were speaking about the fact that the makers of the player were using exotic techniques which were incompatible with CentOS. Those techniques are opaque to me, so the miscommunication continued.
There's probably no 'exotic techniques' going on, just that Centos is not trying to keep up with the latest release of every package out there, just stable releases of a number of important packages. Centos can play mp3's as well as Ubuntu can, but if you want lots more available packages that are newer then Ubuntu is probably the way to go.
Tim Edwards wrote:
Dave Gutteridge wrote:
Then I look on the web and discover PlayerC, which seems like itmight carry both the features I want. I download it, but it doesn't work. I come to the list and ask why, and I'm advised that CentOS is an enterprise level distribution, and not meant for running cutting edge applications. So I'm confused. After all, PlayerC doesn't do anything that PlayerA and PlayerB don't already do on CentOS, it just happens to do them together. How, I wonder, am I doing anything "cutting edge", or that would threaten the stability of CentOS?
Centos/RHEL is released once every 18 months and is focused on having a (relatively) small set of well tested, stable packages that are mainly aimed at servers and basic desktop functions like web and email. Makes perfect sense that they don't have the latest and greatest mp3 player package.
And _that_ is exactly why I love this distro and why its on all my servers and workstations.
On Sunday 16 October 2005 11:47, Dave Gutteridge wrote:
It seems to me there is a division between a developer's focus on how things work, and a newbie's focus on results.
Nobody yet in the thread has touched the real issue. The real issue has been ridiculed, however; 'Luser couldn't get MP3's to play. Poor Luser...' So, what is the real issue? Users just want it to work. They don't necessarily share developer's knack for arcana like GTK version numbers and version skew prevention. They DON'T EVEN WANT TO KNOW in some cases.
Why do people use CentOS? To get work done, perhaps? If a newbie is a hobbyist of sorts, and wants to try out 'that linux thing' and all they've known is Windows, then the idea that "one 'brand' of Linux won't run programs that another 'brand' of Linux will" is totally alien, and the whole library dependency issue is completely foreign, and the newbie justifiably believes they shouldn't have to worry about such things. The newbie just asked around, and got some recommendations: 'Yeah, man, Gentoo is so cool.' or 'Man, you've got to try Ubuntu.' Or they read a Linux Journal Readers Choice survey, and find CentOS at number two on the list, and want to try it out. They DO NOT KNOW, NOR DO THEY CARE, that it is an 'Enterprise' linux. They just care that a lot of other people liked it, and it's popular.
Sure, CentOS is a so-called 'Enterprise' Linux. But what exactly does that mean? Well, it certainly doesn't mean stability (and let me make it clear that I know it's primarily an upstream North Carolina company's problems). It certainly doesn't mean things don't change. It doesn't get you a system that is less likely to break during a minor update. Nope, none of that. Nor does it get you a primarily 'server' operating system. The 'Enterprise' linux distributions are great general-purpose operating systems.
Sure, I understand why Player C won't work with Player A and Player B will. I even understand why the makers of Player C might be using the versions of packages they are using. (hey, anybody remember the mplayer vendetta against gcc 2.96?)
Fact is, Linux in its current state, thanks to the wonderful supportive mailing lists (for all distributions, not just this one) is not suited for newbies. Newbies be warned: you will be ridiculed for just wanting the system to work. (yes, a sizable dose of sarcasm to be found there...)
Suggestion to list members (including myself): if a newbie asks a rank newbie question, and you don't have the patience to answer it from a newbie's perspective, then either hit delete or just shut up. RTFM is not an acceptable answer, unless you answer the question, then provide a polite pointer to the place in the manual (that they might not even know how to find) that answers that question.
As an example, I wrote up several caveats for the RPM distribution of the PostgreSQL RPMs, placed, helpfully I thought, in /usr/share/doc/postgresql-x.y.z-r/README.rpm-dist (named that way, instead of README.rpm, so that RealAudio or RPM itself wasn't started when people browsed to it with their file manager of choice, or with their web browser).
Guess what? Out of fifty newbies who asked questions that were answered in the README, only one had the foggiest idea that the file even existed. And that person was simply too lazy to read it. Of those people, about forty, when their question was answered and a pointer to the file was given, were very happy the file existed; two even wrote me a note that they wished they had known it existed, because then they wouldn't have bothered me.
But the most aggravating answers from the 'knowledgable' users were either 'throw out the RPM, you really want to learn how to build from source' or full of misinformation (on behavior that was FULLY documented). When I would correct that sort of misinformation (my favorite was the people who needed TCP/IP connections to the postmaster; the old way was to add a -i to the postmaster invocation, and the new way involved editing a configuration file: the number of people who advocated EDITING THE INITSCRIPT and adding -i was startling, showing their ignorance to the fact that the initscript can get blown away in an RPM update at whim, but that the config file wasn't ever overwritten), the misinformers would become very offended that I had changed the Way We Do Things (I didn't; upstream did) and that I had the gall to correct their Obviously Better Information (yeah, I just maintain the packages, what do I know?). The next was the whole logging issue (the postgresql initscript redirects stdout to /dev/null for a reason) that, again, was documented. The next was 'I upgraded the RPM with rpm -U and now my database won't start! Why?' which, unfortunately, had to be answered with 'complain upstream; they don't support that kind of upgrade.' That got me a lot of grief, for something I didn't do.
No, Linux isn't for newbies, and ninety percent of the time it's not the distribution's fault.
On Mon, 2005-10-17 at 10:43 -0400, Lamar Owen wrote:
On Sunday 16 October 2005 11:47, Dave Gutteridge wrote:
It seems to me there is a division between a developer's focus on how things work, and a newbie's focus on results.
Nobody yet in the thread has touched the real issue. The real issue has been ridiculed, however; 'Luser couldn't get MP3's to play. Poor Luser...' So, what is the real issue? Users just want it to work. They don't necessarily share developer's knack for arcana like GTK version numbers and version skew prevention. They DON'T EVEN WANT TO KNOW in some cases.
Why do people use CentOS? To get work done, perhaps? If a newbie is a hobbyist of sorts, and wants to try out 'that linux thing' and all they've known is Windows, then the idea that "one 'brand' of Linux won't run programs that another 'brand' of Linux will" is totally alien, and the whole library dependency issue is completely foreign, and the newbie justifiably believes they shouldn't have to worry about such things. The newbie just asked around, and got some recommendations: 'Yeah, man, Gentoo is so cool.' or 'Man, you've got to try Ubuntu.' Or they read a Linux Journal Readers Choice survey, and find CentOS at number two on the list, and want to try it out. They DO NOT KNOW, NOR DO THEY CARE, that it is an 'Enterprise' linux. They just care that a lot of other people liked it, and it's popular.
Sure, CentOS is a so-called 'Enterprise' Linux. But what exactly does that mean? Well, it certainly doesn't mean stability (and let me make it clear that I know it's primarily an upstream North Carolina company's problems). It certainly doesn't mean things don't change. It doesn't get you a system that is less likely to break during a minor update. Nope, none of that. Nor does it get you a primarily 'server' operating system. The 'Enterprise' linux distributions are great general-purpose operating systems.
Sure, I understand why Player C won't work with Player A and Player B will. I even understand why the makers of Player C might be using the versions of packages they are using. (hey, anybody remember the mplayer vendetta against gcc 2.96?)
Fact is, Linux in its current state, thanks to the wonderful supportive mailing lists (for all distributions, not just this one) is not suited for newbies. Newbies be warned: you will be ridiculed for just wanting the system to work. (yes, a sizable dose of sarcasm to be found there...)
Suggestion to list members (including myself): if a newbie asks a rank newbie question, and you don't have the patience to answer it from a newbie's perspective, then either hit delete or just shut up. RTFM is not an acceptable answer, unless you answer the question, then provide a polite pointer to the place in the manual (that they might not even know how to find) that answers that question.
As an example, I wrote up several caveats for the RPM distribution of the PostgreSQL RPMs, placed, helpfully I thought, in /usr/share/doc/postgresql-x.y.z-r/README.rpm-dist (named that way, instead of README.rpm, so that RealAudio or RPM itself wasn't started when people browsed to it with their file manager of choice, or with their web browser).
Guess what? Out of fifty newbies who asked questions that were answered in the README, only one had the foggiest idea that the file even existed. And that person was simply too lazy to read it. Of those people, about forty, when their question was answered and a pointer to the file was given, were very happy the file existed; two even wrote me a note that they wished they had known it existed, because then they wouldn't have bothered me.
But the most aggravating answers from the 'knowledgable' users were either 'throw out the RPM, you really want to learn how to build from source' or full of misinformation (on behavior that was FULLY documented). When I would correct that sort of misinformation (my favorite was the people who needed TCP/IP connections to the postmaster; the old way was to add a -i to the postmaster invocation, and the new way involved editing a configuration file: the number of people who advocated EDITING THE INITSCRIPT and adding -i was startling, showing their ignorance to the fact that the initscript can get blown away in an RPM update at whim, but that the config file wasn't ever overwritten), the misinformers would become very offended that I had changed the Way We Do Things (I didn't; upstream did) and that I had the gall to correct their Obviously Better Information (yeah, I just maintain the packages, what do I know?). The next was the whole logging issue (the postgresql initscript redirects stdout to /dev/null for a reason) that, again, was documented. The next was 'I upgraded the RPM with rpm -U and now my database won't start! Why?' which, unfortunately, had to be answered with 'complain upstream; they don't support that kind of upgrade.' That got me a lot of grief, for something I didn't do.
No, Linux isn't for newbies, and ninety percent of the time it's not the distribution's fault.
---- I suppose you needed to vent and vent you did. Being one that is guilty of not reading installation notes myself, I'm not too likely to jump on other people's cases for doing the same - especially when it's easy enough to answer the question if they ask.
As for the OP - he had no problem playing mp3 files, he managed to do that in several programs but none of the programs did exactly what he wanted and he wanted to keep trying different user interfaces to playing local files - which became a problem once he exhausted the low hanging fruit of xmms and amarok - see his post because he knew that there were other programs out there that weren't prepackaged for the Enterprise Linux.
The guy bounced because he originally started with Fedora Core 4 which was very new and not very finished when it originally released and on the Fedora list he claimed to want something more finished, more stable which is why he was pointed to CentOS. He wants more stable yet more adaptable - whether Ubuntu does that for him, only he will be able to say.
Now - when you turn to what is apparently your biggest peeve - differing advice from different people - that's what you get from open source support lists - I mean, we can't all wait for Alexander Dalloz to give us the likely best and most correct answer. Part of the art of using Linux is learning to solve your problems, where to get the information and how to use the information that you get - which sometimes includes bad advice. IIRC, he was told to use sixth field of an fstab entry on his vfat formatted partition with a '2' which clobbered it - ya takes your chances and bad advice as well as useless advice is always possible from this or any other list.
I don't think we need to endless wring our hands on this subject.
Craig
On Monday 17 October 2005 12:07, Craig White wrote:
Now - when you turn to what is apparently your biggest peeve - differing advice from different people - that's what you get from open source support lists - I mean, we can't all wait for Alexander Dalloz to give us the likely best and most correct answer.
Not exactly my point, but close. What I got aggravated about was something that Ill call the 'I got Slashdot first post' syndrome. It seemed that some people raced to see who could be first the 'answer' the question when they didn't really know the answer and got angry when corrected to current behavior. And they would do it more than once, even after being corrected more than once.
Part of the art of using Linux is learning to solve your problems, where to get the information and how to use the information that you get - which sometimes includes bad advice.
Sure, of course. No advice (including mine) is suitable for all possible situations. However, the newbie does need more of a response than 'RTFM!' to get them going.
IIRC, he was told to use sixth field of an fstab entry on his vfat formatted partition with a '2' which clobbered it - ya takes your chances and bad advice as well as useless advice is always possible from this or any other list.
And that points to my argument: if you aren't sure you're giving good advice, don't give it. I think some people try to give advice (maybe even exhaustive advice) as an ego trip; saw plenty of that in my five years as PostgreSQL RPM maintainer.
I don't think we need to endless wring our hands on this subject.
Nah, what needs to be done is less talk, not more. But I will say to those who have already replied to me in private that agree with my assessment, thank you!
On Mon, 2005-10-17 at 09:43, Lamar Owen wrote:
Fact is, Linux in its current state, thanks to the wonderful supportive mailing lists (for all distributions, not just this one) is not suited for newbies. Newbies be warned: you will be ridiculed for just wanting the system to work. (yes, a sizable dose of sarcasm to be found there...)
I think that says more about the state of current distributions than the users, and the fact that they are correct in seeking new ones.
... showing their ignorance to the fact that the initscript can get blown away in an RPM update at whim, but that the config file wasn't ever overwritten...
Isn't it always up to the whim of the RPM builder what gets blown away and what is preserved? Did you just mean that the config file hasn't been changed recently?
No, Linux isn't for newbies, and ninety percent of the time it's not the distribution's fault.
What is it that could be explained that couldn't be scripted?
On Monday 17 October 2005 12:49, Les Mikesell wrote:
On Mon, 2005-10-17 at 09:43, Lamar Owen wrote:
... showing their ignorance to the fact that the initscript can get blown away in an RPM update at whim, but that the config file wasn't ever overwritten...
Isn't it always up to the whim of the RPM builder what gets blown away and what is preserved? Did you just mean that the config file hasn't been changed recently?
No, sorry, I didn't fully explain the postgresql.conf situation. The postgresql.conf is generated from a template during initdb, and is thus created along with your database when you initdb. It is not managed directly by the spec's %files list. Likewise with pg_hba.conf, and any other configuration found in $PGDATA (/var/lib/pgsql/data by default).
Thus, unless the packager (at the time me) does something drastic (like, rm -f /var/lig/pgsql/data/postgresql.conf ; cp some-new-template-for-conf /var/lib/pgsql/data/postgresql.conf or adds specific files to %files for the -server subpackage) then the $PGDATA/postgresql.conf is pretty much guaranteed safe from overwrite by the RPM installation. There are whims, and then there are stupid tricks.
No, Linux isn't for newbies, and ninety percent of the time it's not the distribution's fault.
What is it that could be explained that couldn't be scripted?
More than you might realize given the constraints of the RPM system. Otherwise, very little, but you do have to write and debug the scripts. And the script interpreter, regardless of language, takes things far more literally than even the rankest newbie following an explanation.
But to directly answer the question you posed, in the context of the PostgreSQL upgrade procedure, there are external limitations that cannot be scripted for various reasons, most of which are outside the control of the scripts that run during %pre, %post, %preun, and %postun. The biggest problem is that PostgreSQL databases contain a vast amount of version-specific metadata, specifically they can contain compiled C functions that are version-dependent, and they contain the default type handler functions for the whole database (PostgreSQL is extraordinarily customizable and extensible, and in fact the default types, operators, and functions are implemented just exactly as if they were user customizations, inside the database itself. This is what initdb does, in fact: it loads a default set of customizations using a standalone backend and template files).
The second biggest problem is that these scripts (%pre and kin) cannot tell if they are running in an anaconda chroot or from yum or from a manual rpm commandline. If they are running in an anaconda chroot, 'Danger Will Robinson!' : they had better not try to start a backend process, because the anaconda chroot with busybox is NOT a suitable place to start a backend (to dump the database in preparation for upgrade, something that would have to be done in a %pre, and of course you run into serious disk space calculation issues).
Third, RPM scriplets are forbidden (especially inside anaconda, or during a yum update or similar) from sending to stdout or gathering data from stdin, preventing the scriptlet from asking questions and receiving answers. And the user may never see the output your carefully thought out initscript wrote to stdout.
I know what the short-term solution is, but have not had the time or the need to implement it. And that is the capability of having multiple versions of the backend available at any given time. Debian's maintainers are working on a system along those lines, but they have run into snags too.
It is far easier to explain "dump, upgrade, initdb, restore" than to write a script to do some really hairy data manipulation that can: 1.) Understand the binary data format; 2.) Has knowledge of all possible old versions with binary mappings from old version default type handlers and new version handlers, with the appropriate OID's necessary for mapping; 3.) Knows how to take an object code function and translate to the new version object code function for all possible versions, keeping the same OID; 4.) Can do all of the above without overflowing disk, or at least handles disk space exhausted in a sane manner; 5.) Oh, and has no possibility of database corruption.
That's just the overview.
Now, explain to a newbie why they can't just stick the disk in and upgrade; you'll likely get a blank stare. This is, IMO, one reason why Red Hat no longer officially supports upgrades, and only allows 'upgradeany' at your own risk.
Or to put it very bluntly: being newbie-friendly is hard work for a developer, but even harder work for support staff or mailing list participants. There are no easy answers for ease of use. Although my initial impressions of Ubuntu are pretty positive.
Personally, I have nearly a decade of experience with Red Hat-like systems; too much intellectual equity to jump ship. One might say I'm somewhat vested in RPM-based setups at this point.
On Mon, 2005-10-17 at 12:40, Lamar Owen wrote:
What is it that could be explained that couldn't be scripted?
More than you might realize given the constraints of the RPM system.
Yes, the decision to disallow user interaction during RPM installs is probably the worst thing ever to happen to Linux. There are things where defaults aren't ever going to be right. But, you can always work around it by making the interactive part happen later.
Otherwise, very little, but you do have to write and debug the scripts. And the script interpreter, regardless of language, takes things far more literally than even the rankest newbie following an explanation.
But it will complain a lot less...
I know what the short-term solution is, but have not had the time or the need to implement it. And that is the capability of having multiple versions of the backend available at any given time.
Yes, this is where the 'do the interactive portion later' hits a snag. There are things that have to be done before you blow away the code needed to do the first steps.
It is far easier to explain "dump, upgrade, initdb, restore" than to write a script to do some really hairy data manipulation that can:
The script only has to be done once by a person that understands the issues. The explanation has to be done once per user - and they are likely to get it wrong.
Or to put it very bluntly: being newbie-friendly is hard work for a developer, but even harder work for support staff or mailing list participants.
The more that is done right on the development/packager/installer side the less support is needed.
There are no easy answers for ease of use. Although my initial impressions of Ubuntu are pretty positive.
Personally, I have nearly a decade of experience with Red Hat-like systems; too much intellectual equity to jump ship. One might say I'm somewhat vested in RPM-based setups at this point.
If you have to understand anything about a package manager, then it isn't doing it's job - unless you mean building the packages.
On Monday 17 October 2005 14:06, Les Mikesell wrote:
On Mon, 2005-10-17 at 12:40, Lamar Owen wrote:
What is it that could be explained that couldn't be scripted?
More than you might realize given the constraints of the RPM system.
Yes, the decision to disallow user interaction during RPM installs is probably the worst thing ever to happen to Linux. There are things where defaults aren't ever going to be right. But, you can always work around it by making the interactive part happen later.
Unless the interactive part is asking you to dump a database for which you no longer have a backend capable of reading the data. I tried to work around that, but it was not a robust solution.
Unfortunately, there have been version transitions in PostgreSQL where the new version of pg_dump was needed to back up the older database, meaning you had one version of postgresql (for the clients) and another version of postgresql-server (for the backend). Doing this during an OS upgrade is impossible thanks to the environment under which an OS upgrade is performed. The workaround saved off a copy of the binaries necessary to do the dump; however, the RPM dependencies for those executables were not guaranteed to stick around, and it was horribly fragile, depending upon version delta.
And the script interpreter, regardless of language, takes things far more literally than even the rankest newbie following an explanation.
But it will complain a lot less...
Well, that depends upon language, and how pedantic you have set warning levels... :-) At least the complaints will be readable, and somewhat meaningful.
Yes, this is where the 'do the interactive portion later' hits a snag. There are things that have to be done before you blow away the code needed to do the first steps.
Yes, precisely the problem.
It is far easier to explain "dump, upgrade, initdb, restore" than to write a script to do some really hairy data manipulation that can:
The script only has to be done once by a person that understands the issues. The explanation has to be done once per user - and they are likely to get it wrong.
Assuming the issues don't change version to version. Guess what; the issues do change between versions. Sometimes they change dramatically, as in the actual binary format. Sometimes the whole tree changes with a complete makeover of file names and such. Sometimes it's small metadata changes.
The problem becomes one of manpower. There is only one person I believe to be capable of capable of writing such a migration tool, and that is Tom Lane. And he is swamped.
Or to put it very bluntly: being newbie-friendly is hard work for a developer, but even harder work for support staff or mailing list participants.
The more that is done right on the development/packager/installer side the less support is needed.
Agreed in principle. But in the case of the OP, the issue became one of 'why can't I use $third-party-package' anyway? And this is, IMO, one of the greatest weaknesses (yet at the same time the greatest strength) of open source development, and that is the wide disparity of the class of developers and the decentralized nature of development. Take Cinelerra, for instance. For a while that beast shipped its own base libraries and built them along with the application, because the developer needed very particular versions of everything. On the other hand, take CrossOver Office, which leverages the Loki Installer very nicely. But even then the support issues are thick.
If you have to understand anything about a package manager, then it isn't doing it's job - unless you mean building the packages.
Well, the Red Hat-ish distributions have their own quirks that aren't related to choice of package manager. Having cross-packaged PostgreSQL for as varied a lot as SuSE, Caldera OpenServer (when that was the name), Red Hat, Mandrake, and TurboLinux, I can say from experience that RPM isn't the problem when it comes to distribution portability. Each one has unique quirks, version combinations, and macro sets. (Yes, spoken from a packager point of view).
This is simultaneously a strength and a weakness, as already mentioned.
But one of the reasons I use CentOS is at least the potential capability of running the same distribution on every machine I have, including the SPARC's and the Alpha.
Lamar Owen wrote:
No, Linux isn't for newbies, and ninety percent of the time it's not the distribution's fault.
Nor is Windows for that matter.
I've known people who have only used MacOS pull their hair out when they first used Windows. And more recently, I have _also_ seen people who have only run Linux pull their hair out when they've first used Windows.
The daughter of a friend in our LUG had only used Linux and went off to college and her first experiences with Windows, it's very to hear what is not "intuitive" on the "other flip of the coin."
CASE-IN-POINT: UNIX does not work like Windows, never will
Furthermore, one of these days people will recognize that an Enteprise Linux distribution is a trailing edge, stablity-focused, ISV certifying solution.
Much like trying to run Windows NT 4.0 or 2000 Server for any Windows XP multimedia titles as a non-privileged user (let alone on XP itself). And for those of us around NT in the early-to-mid '90s, _any_ Windows 95 application on Windows NT 3.51 or 4.0 (let alone most didn't even work when you were logged in as "administrator").
I've also just learned to ignore the Fedora Core and/v. Red Hat Enterprise Linux comments, as well as the retro-actively rewritten history of how "wonderful" and "supported" Red Hat Linux was prior (especially when peopel forget all the complaints about GLibC 2.0 in RHL5.0, GCC 2.96 in RHL7, the "Blue Curve" theme, etc..., etc..., etc...).
And let's remember to make things about "choice of technologies," not "marketing" choice. If I want "marketing" choice, I'll run commercial software based on better marketing. I don't like seeing it in the Linux world, because it drops into the "you must be stupid if you don't like brand X, it does this better" attitudes let alone the "brand Y doesn't do A" even when it's the same, damn thing, right down to the version and project.
Let people be with what works for them. But at the same time, don't try to assert what something doesn't do. That's a major part of the problem.
Les Mikesell lesmikesell@gmail.com wrote:
If you have to understand anything about a package manager, then it isn't doing it's job - unless you mean building the packages.
Dependency checking, by its very nature, is "bothersome." And packages that rely on each other are also "bothersome."
If we want to solve these issues, we need to: - Package everything as executables - Package everything required in those executables - Not allow more than 1 version to co-exist
This is Windows. And if you load all of Microsoft's products that are equivalent to what comes in a 4GiB Linux distro, it weighs well over 40+GiB, with dozens of redundant copies of libraries and other issues -- let alone multiple versions won't work.
And some of Microsoft's own products won't even work if loaded on the same server -- let alone once you start talking ISV products in addition. Talking about inter-product issues, these are things that make me "happy to be bothered" by package management. ;->
Craig White wrote:
I don't think we need to endless wring our hands on this subject.
Mega-dittos there.
On Mon, 2005-10-17 at 14:45, Bryan J. Smith wrote:
Les Mikesell lesmikesell@gmail.com wrote:
If you have to understand anything about a package manager, then it isn't doing it's job - unless you mean building the packages.
Dependency checking, by its very nature, is "bothersome." And packages that rely on each other are also "bothersome."
If we want to solve these issues, we need to:
- Package everything as executables
- Package everything required in those executables
- Not allow more than 1 version to co-exist
Or version them in ways that do allow them to co-exist. Hopefully somewhat short of requiring virtual machines to isolate them. But other than the kernel, RPM doesn't seem real happy about installing them, and the kernel by nature only allows one copy to be used at once.
-
Benjamin J. Weiss -
Bryan J. Smith -
Chris Mauritz -
Collins Richey -
Craig White -
Dave Gutteridge -
Lamar Owen -
Les Mikesell -
Mark Weaver -
Robert -
Rodrigo Barbosa -
Tim Edwards