Hi all,
I'm seriously considering switching distro's after the AIGLX and target audience discussion. I cannot believe how arrogant most of the replies are, saying that if user install any third party software that then that thirdparty software is their problem.
I also find this very hypocrite because normally when any chance breaking thirdparty software is proposed for inclusion into the current release people start screaming loudly. Like for example any suggestions to introduce an update to Extras with an soname chance. But since the thirdparty software breaking in this case is non OSS and since some very LOUD people happen to dislike the thirdparty software breaking in this case, they are all of of a sudden in favor of breaking thirdparty software during a what is supposed to be stable release?
I'm just totally stunned by the arrogance in this discussion, the I'm holier then thou stance. And most of all the total disregards to the many end users who happen to rely on the thirdparty software in case.
I'm seriously starting to think that Fedora is not the distro for me to be working on and switching to Ubuntu (by lack of a better alternative), now some of the arrogant screamers may say fine, we won't miss you but before saying so I would first take a look at owners.list in FE cvs and than think again.
This is not meant as some kinda blackmail to stop the Xorg 7.1 update, to be honest at this point I don't care about the 7.1 update anymore. And as I said when I started the target audience discussion this was never about the 7.1 update. Its about the principle of not knowingly having a yum update during a stable release breaks peoples systems, especially not with a smile on your face and saying behind those end users backs that will teach them not to use binary crap. Because that _IS_ what is happening here. Sure there are many advancements in xorg 7.1 and I'm not suggesting to leave it out FC-6 even if the binary drivers aren't available at FC-6 launch time, but breaking stuff with TOTAL disregard to a large group of end users, during a stable's release lifetime is IMHO unacceptable. And what worries me is not this single instance of breaking, its the attitude behind it and the ease with which we (you?) step over the all of a sudden minor problem of seriously hurting a significant group of end users.
Regards,
Hans
This is not meant as some kinda blackmail to stop the Xorg 7.1 update, to be honest at this point I don't care about the 7.1 update anymore. And as I said when I started the target audience discussion this was never about the 7.1 update. Its about the principle of not knowingly having a yum update during a stable release breaks peoples systems, especially not with a smile on your face and saying behind those end users backs that will teach them not to use binary crap. Because that _IS_ what is happening here. Sure there are many advancements in xorg 7.1 and I'm not suggesting to leave it out FC-6 even if the binary drivers aren't available at FC-6 launch time, but breaking stuff with TOTAL disregard to a large group of end users, during a stable's release lifetime is IMHO unacceptable. And what worries me is not this single instance of breaking, its the attitude behind it and the ease with which we (you?) step over the all of a sudden minor problem of seriously hurting a significant group of end users.
How we move to new versions is a very difficult topic. I though we get way more pushback when we started updating e.g. mysql to newest upstream versions within FC-updates and really did bigger jumps there. But I think overall the majority also liked getting newest versions if not too many regressions were added. It does seem to work for mysql right now.
With graphics drivers we really need to get moving and improve the number of supported cards. I am not too familiar with the xorg devel community, but my impression was that hacking on drivers is not the easiest thing todo. So yes, I also don't like seeing regressions getting introduced, but on the other hand if Fedora is a vehicle to get more testing back for xorg and hopefully also contribute to grow the xorg devel community to move on, that would be a really good goal for Fedora Core.
I'd see the binary driver items only as secondary discussion point, but know how things get really political then. Main point is on how to grow xorg stability and number of supported cards.
regards,
Florian La Roche
On Fri, 2006-07-28 at 09:25 +0200, Florian La Roche wrote:
This is not meant as some kinda blackmail to stop the Xorg 7.1 update, to be honest at this point I don't care about the 7.1 update anymore. And as I said when I started the target audience discussion this was never about the 7.1 update. Its about the principle of not knowingly having a yum update during a stable release breaks peoples systems, especially not with a smile on your face and saying behind those end users backs that will teach them not to use binary crap. Because that _IS_ what is happening here. Sure there are many advancements in xorg 7.1 and I'm not suggesting to leave it out FC-6 even if the binary drivers aren't available at FC-6 launch time, but breaking stuff with TOTAL disregard to a large group of end users, during a stable's release lifetime is IMHO unacceptable. And what worries me is not this single instance of breaking, its the attitude behind it and the ease with which we (you?) step over the all of a sudden minor problem of seriously hurting a significant group of end users.
ACK.
How we move to new versions is a very difficult topic. I though we get way more pushback when we started updating e.g. mysql to newest upstream versions within FC-updates and really did bigger jumps there. But I think overall the majority also liked getting newest versions if not too many regressions were added. It does seem to work for mysql right now.
With graphics drivers we really need to get moving and improve the number of supported cards. I am not too familiar with the xorg devel community, but my impression was that hacking on drivers is not the easiest thing todo. So yes, I also don't like seeing regressions getting introduced, but on the other hand if Fedora is a vehicle to get more testing back for xorg and hopefully also contribute to grow the xorg devel community to move on, that would be a really good goal for Fedora Core.
Well, to me, the main point is Fedora leadership, Fedora management and strategic decisions, and their interaction with the community rsp. lack of thereof.
At least I sense political and ideological interests (ab-) using Fedora as a vehicle for their selfish interests and positions. That said, you can't separate technical and political issue as far as Fedora is concerned. To me, this current issue is nothing but a religious crusade, which can will cause many collateral casualties amongst users and is not unlikely to be harmful to the distro.
I'd see the binary driver items only as secondary discussion point, but know how things get really political then. Main point is on how to grow xorg stability and number of supported cards.
The binary/proprietary driver issue is a old as Linux. Nowadays it's ATI and Nvidia, in the early days it had been others. IMO, there has not been any substantial progress on this matter ever since linux exists. So far, only in very rare occasions previous such "driver crusades" had been successful to a measurable extend, but ... the times have changed, the Linux hype is over ...
Ralf
Ralf Corsepius rc040203@freenet.de wrote:
[...]
The binary/proprietary driver issue is a old as Linux. Nowadays it's ATI and Nvidia, in the early days it had been others.
Which ended opening up or being reverse engineered.
IMO, there has notbeen any substantial progress on this matter ever since linux exists.
In flaming, no. In actual device support, quite a bit.
So far, only in very rare occasions previous such "driver crusades" had been successful to a measurable extend, but ...
It is rather hard to know how much success this crusade has enjoyed. There is no way of telling how many providers opened up the specs because of getting flamed by users, and how many would have done so anyway.
the times have changed,the Linux hype is over ...
It is just starting making a spash on the desktop, i.e., the place where graphics (and WiFi) make a difference...
On Friday 28 July 2006 08:12, Hans de Goede wrote:
Hi all,
[...]
This is not meant as some kinda blackmail to stop the Xorg 7.1 update, to be honest at this point I don't care about the 7.1 update anymore. And as I said when I started the target audience discussion this was never about the 7.1 update. Its about the principle of not knowingly having a yum update during a stable release breaks peoples systems, especially not with a smile on your face and saying behind those end users backs that will teach them not to use binary crap. Because that _IS_ what is happening here. Sure there are many advancements in xorg 7.1 and I'm not suggesting to leave it out FC-6 even if the binary drivers aren't available at FC-6 launch time, but breaking stuff with TOTAL disregard to a large group of end users, during a stable's release lifetime is IMHO unacceptable. And what worries me is not this single instance of breaking, its the attitude behind it and the ease with which we (you?) step over the all of a sudden minor problem of seriously hurting a significant group of end users.
Hans note that what you say about a group of users can be said the same way about the complementary set.
In technical terms, people who install third party modules (should) know what they are doing. Either they install them directly, and in this case know how to avoid the updates, or they use a repository who provides these packages and it can be worked to solve the problem as well.
In philosophical terms to whitheld the release of any package because of the (in)actions of a third party seems to me a bad precedent.
Regards,
Hans
Jose' Matos wrote:
On Friday 28 July 2006 08:12, Hans de Goede wrote:
Hi all,
[...]
This is not meant as some kinda blackmail to stop the Xorg 7.1 update, to be honest at this point I don't care about the 7.1 update anymore. And as I said when I started the target audience discussion this was never about the 7.1 update. Its about the principle of not knowingly having a yum update during a stable release breaks peoples systems, especially not with a smile on your face and saying behind those end users backs that will teach them not to use binary crap. Because that _IS_ what is happening here. Sure there are many advancements in xorg 7.1 and I'm not suggesting to leave it out FC-6 even if the binary drivers aren't available at FC-6 launch time, but breaking stuff with TOTAL disregard to a large group of end users, during a stable's release lifetime is IMHO unacceptable. And what worries me is not this single instance of breaking, its the attitude behind it and the ease with which we (you?) step over the all of a sudden minor problem of seriously hurting a significant group of end users.
Hans note that what you say about a group of users can be said the same way about the complementary set.
In technical terms, people who install third party modules (should) know what they are doing. Either they install them directly, and in this case know how to avoid the updates, or they use a repository who provides these packages and it can be worked to solve the problem as well.
In philosophical terms to whitheld the release of any package because of the (in)actions of a third party seems to me a bad precedent.
I keep hearing this argument, that the packages for the involved drivers can be made to conflict with the update. Which in essence will deprive all but the most technical of our users from security updates. So this is a moot argument. ? Deprive all but the most technical of our users from security updates is almost as bad as completly breaking their system.
Yes completly breaking for a non technicall user an X server refusing to start is almost impossible to fix.
Regards,
Hans
On Fri, 28 Jul 2006 10:02:41 +0200 Hans de Goede j.w.r.degoede@hhs.nl wrote:
I keep hearing this argument, that the packages for the involved drivers can be made to conflict with the update. Which in essence will deprive all but the most technical of our users from security updates. So this is a moot argument. ? Deprive all but the most technical of our users from security updates is almost as bad as completly breaking their system.
They would only be without security updates until a new binary driver is available that would work with the core update. This seems more fair than forcing all the other users to wait for the upgrade until such a driver is available.
Yes completly breaking for a non technicall user an X server refusing to start is almost impossible to fix.
Agreed, but with proper packaging of the binary drivers that shouldn't happen.
Sean
On Friday 28 July 2006 09:02, Hans de Goede wrote:
I keep hearing this argument, that the packages for the involved drivers can be made to conflict with the update. Which in essence will deprive all but the most technical of our users from security updates. So this is a moot argument. ? Deprive all but the most technical of our users from security updates is almost as bad as completly breaking their system.
As you know that has been discussed before and it should be possible to write a yum plug-in to avoid this. This could be done as an extension in the said packages.
Technically this is feasible. Why it as not been done before? Because there was not enough motivation to do it.
Yes completly breaking for a non technicall user an X server refusing to start is almost impossible to fix.
I am not saying that this is a good thing, note. This is evil. Not to upgrade a package because some entity had months in advance to fix something, and did nothing is evil as well.
Now, which evil is worse?
Regards,
Hans
I keep hearing this argument, that the packages for the involved drivers can be made to conflict with the update. Which in essence will deprive all but the most technical of our users from security updates. So this is a moot argument. ? Deprive all but the most technical of our users from security updates is almost as bad as completly breaking their system.
the sad thing is that if you use those drivers you probably don't need a security update; since I assume most people don't compile out the "give me more privileges" ioctl and other things in that..
And really you make all this sound like the end of the world. But it's quite simple: Once there is a distro using 7.1, nvidia will rush to release what they apparently already have. Until there is such a distro, they won't. So the time frame in which an X sploit could be found and in which a nvidia user then would be vulnerable is quite limited, probably no more than 2 or 3 weeks to my estimate. Are these 2 or 3 weeks really such a high price that it's worth denying a lot of other people a better working X for? (yes VESA sucks hard if you compare it to an accelerated driver)
Le vendredi 28 juillet 2006 à 10:02 +0200, Hans de Goede a écrit :
I keep hearing this argument, that the packages for the involved drivers can be made to conflict with the update. Which in essence will deprive all but the most technical of our users from security updates. So this is a moot argument. ?
No, this is an argument for fixing yum so it can do partial repo updates and not block on the first problem/conflict, and yum is FLOSS so it's within Fedora mission, so work on getting yum fixed. (again, useful feedback why do you insist on focusing on an issue no one but NVidia can fix?)
However to cut this thread short : unlike most technical posters you think closed drivers could be supported with a reasonable amount of work without hurting the rest of the system. So let's make a deal - maintain the NVidia drivers in that-other-repo for six months, and if you make it to the end without thinking as everyone else it's a total waste of time and energy, we'll talk again.
Nicolas Mailhot wrote:
Le vendredi 28 juillet 2006 à 10:02 +0200, Hans de Goede a écrit :
I keep hearing this argument, that the packages for the involved drivers can be made to conflict with the update. Which in essence will deprive all but the most technical of our users from security updates. So this is a moot argument. ?
No, this is an argument for fixing yum so it can do partial repo updates and not block on the first problem/conflict, and yum is FLOSS so it's within Fedora mission, so work on getting yum fixed. (again, useful feedback why do you insist on focusing on an issue no one but NVidia can fix?)
Good point, agreed.
However to cut this thread short : unlike most technical posters you think closed drivers could be supported with a reasonable amount of work without hurting the rest of the system. So let's make a deal - maintain the NVidia drivers in that-other-repo for six months, and if you make it to the end without thinking as everyone else it's a total waste of time and energy, we'll talk again.
Hmm,
Clever trick. This is the first post in this thread that has put a smile on my face :) Nope sorry I'm very much in favor of opensource myself and have no wish to support / put effort in binary crap. I keep saying people are not hearing what I'm trying to say, so let me try again: I don't say we should support it, but deliberately braking it is another story!
Now if the update would get hold back untill that other repo has packages in place which work around this (putting conflicts in the relevant packages and an exclude for the xorg server in yum.conf should do the trick) then we are getting somewhere.
My big problem is the attitude that the breaking is somebody elses problem entirely and the total refusal to think with that other repo instead of just rampaging forward, breaking many systems and creating a lot of bad PR in the process.
Regards,
Hans
On Fri, July 28, 2006 5:52 am, Hans de Goede said:
Clever trick. This is the first post in this thread that has put a smile on my face :) Nope sorry I'm very much in favor of opensource myself and have no wish to support / put effort in binary crap. I keep saying people are not hearing what I'm trying to say, so let me try again: I don't say we should support it, but deliberately braking it is another story!
Then you haven't heard many of the responses either. There is no need for breakage if the 3rd party repos manage things properly.
Now if the update would get hold back untill that other repo has packages in place which work around this (putting conflicts in the relevant packages and an exclude for the xorg server in yum.conf should do the trick) then we are getting somewhere.
Again, this would put the release schedule of Fedora software in the hands of a proprietary vendor. This just can't be the way to go.
My big problem is the attitude that the breaking is somebody elses problem entirely and the total refusal to think with that other repo instead of just rampaging forward, breaking many systems and creating a lot of bad PR in the process.
But by and large that isn't the attitude at all. The attitude is that the 3rd party repos should do the work to make sure that their users expierence is acceptable. They have all the tools they need to ensure this. Putting the onus on Fedora developers is just backwards.
Sean
On Fri, Jul 28, 2006 at 10:02:41AM +0200, Hans de Goede wrote:
I keep hearing this argument, that the packages for the involved drivers can be made to conflict with the update. Which in essence will deprive all but the most technical of our users from security updates. So this is a moot argument. ? Deprive all but the most technical of our users from security updates is almost as bad as completly breaking their system.
So you do deprive everyone of needed X fixes, or let a few people suffer until Nvidia update their driver and someone repackages it.
Which one ?
On Fri, 28 Jul 2006, Alan Cox wrote:
On Fri, Jul 28, 2006 at 10:02:41AM +0200, Hans de Goede wrote:
I keep hearing this argument, that the packages for the involved drivers can be made to conflict with the update. Which in essence will deprive all but the most technical of our users from security updates. So this is a moot argument. ? Deprive all but the most technical of our users from security updates is almost as bad as completly breaking their system.
So you do deprive everyone of needed X fixes, or let a few people suffer until Nvidia update their driver and someone repackages it.
Which one ?
Updating to 7.1 will also prod them into actually releasing the new set of drivers.
Sorry to butt in here. I have spent a lot of time using Debian and a litte using FC. In Debian stable means stable. You don't screw around with the distribution to make it look cool(er) or even to add capabilities. It's a promise to the community that you can use this without fear of finding an update breaks things. In the Debian distro, if you want newer things, you use testing. I realize that FC tries to move new relases of, say, KDE, gnome, and xorg into their stable distribution more quickly, so stability is less sachrosanct. At the same time, the Debian community may be even less sympathetic to third party binary complaints. However, I think that the disregard of third-party codes is actually short-sighted. As Linux becomes more widely accepted, it will encounter more third-party codes. More users will get the attention of commercial software vendors so that there will be more available. Only if linux would like to remain a hobbyist's OS would it ignore this problem. I'm not claiming that there is an easy solution. One of the great advantages of linux, that it is not monolithic, is also one of its greatest obstacles when dealing with commercial vendors. I don't know how the governing bodies of various distro's will choose to deal with this, but arrogance would be a poor choice.
My $0.02
Art Edwards
On Fri, Jul 28, 2006, 08:40:35AM +0100, Jose' Matos wrote:
On Friday 28 July 2006 08:12, Hans de Goede wrote:
Hi all,
[...]
This is not meant as some kinda blackmail to stop the Xorg 7.1 update, to be honest at this point I don't care about the 7.1 update anymore. And as I said when I started the target audience discussion this was never about the 7.1 update. Its about the principle of not knowingly having a yum update during a stable release breaks peoples systems, especially not with a smile on your face and saying behind those end users backs that will teach them not to use binary crap. Because that _IS_ what is happening here. Sure there are many advancements in xorg 7.1 and I'm not suggesting to leave it out FC-6 even if the binary drivers aren't available at FC-6 launch time, but breaking stuff with TOTAL disregard to a large group of end users, during a stable's release lifetime is IMHO unacceptable. And what worries me is not this single instance of breaking, its the attitude behind it and the ease with which we (you?) step over the all of a sudden minor problem of seriously hurting a significant group of end users.
Hans note that what you say about a group of users can be said the same way about the complementary set.
In technical terms, people who install third party modules (should) know what they are doing. Either they install them directly, and in this case know how to avoid the updates, or they use a repository who provides these packages and it can be worked to solve the problem as well.
In philosophical terms to whitheld the release of any package because of the (in)actions of a third party seems to me a bad precedent.
Regards,
Hans
-- José Abílio
-- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
edwardsa wrote:
Sorry to butt in here. I have spent a lot of time using Debian and a litte using FC. In Debian stable means stable. You don't screw around with the distribution to make it look cool(er) or even to add capabilities. It's a promise to the community that you can use this without fear of finding an update breaks things. In the Debian distro, if you want newer things, you use testing. I realize that FC tries to move new relases of, say, KDE, gnome, and xorg into their stable distribution more quickly, so stability is less sachrosanct. At the same time, the Debian community may be even less sympathetic to third party binary complaints. However, I think that the disregard of third-party codes is actually short-sighted. As Linux becomes more widely accepted, it will encounter more third-party codes. More users will get the attention of commercial software vendors so that there will be more available. Only if linux would like to remain a hobbyist's OS would it ignore this problem. I'm not claiming that there is an easy solution. One of the great advantages of linux, that it is not monolithic, is also one of its greatest obstacles when dealing with commercial vendors. I don't know how the governing bodies of various distro's will choose to deal with this, but arrogance would be a poor choice.
Fedora is a free, open source, rapidly moving distribution. If you need ABI stability - there ae other distros that may serve your need better?
This is by choice!
/Thomas
On Fri, 28 Jul 2006 09:12:52 +0200 Hans de Goede j.w.r.degoede@hhs.nl wrote:
I'm seriously considering switching distro's after the AIGLX and target audience discussion. I cannot believe how arrogant most of the replies are, saying that if user install any third party software that then that thirdparty software is their problem.
That hasn't been the only response. There have been suggestions about how those providing support for third party software could manage the software they supply to improve the situation. The main point is that Fedora should not be held hostage by the whims of these outside providers.
[snip]
I'm just totally stunned by the arrogance in this discussion, the I'm holier then thou stance. And most of all the total disregards to the many end users who happen to rely on the thirdparty software in case.
There isn't a total disregard for many end users, rather a regard for those who will benefit from this upgrade. It has been made pretty clear that those using binary driver need not suffer if their systems are properly configured. If their systems _aren't_ properly configured to deal with a kernel update or X update from core, then this seems like a very useful conversation to have now so that there is time to get those systems into shape beforehand.
[snip]
This is not meant as some kinda blackmail to stop the Xorg 7.1 update, to be honest at this point I don't care about the 7.1 update anymore. And as I said when I started the target audience discussion this was never about the 7.1 update. Its about the principle of not knowingly having a yum update during a stable release breaks peoples systems, especially not with a smile on your face and saying behind those end users backs that will teach them not to use binary crap. Because that _IS_ what is happening here. Sure there are many advancements in xorg 7.1 and I'm not suggesting to leave it out FC-6 even if the binary drivers aren't available at FC-6 launch time, but breaking stuff with TOTAL disregard to a large group of end users, during a stable's release lifetime is IMHO unacceptable. And what worries me is not this single instance of breaking, its the attitude behind it and the ease with which we (you?) step over the all of a sudden minor problem of seriously hurting a significant group of end users.
This update should _not_ hurt a significant group of end users. If the binary drivers are supplied and supported properly nobody should be hurt by this upgrade. And it definitely will help a significant group of users. Let's not deprive those users who would benefit from this upgrade without a very good reason.
Those that really care about this issue could take the time now to help the users they care about. Updating instructions and howtos for users so they know how to deal with an upgrade to X (or the kernel). Talking with 3rd party repos to make sure that the rpms they provide are designed to protect their users from problems they might experience when the core X or kernel is updated. Letting users on the mailing lists know about an upcoming X upgrade. I'm sure there are other things that could be done as well.
Sean
Sean wrote:
On Fri, 28 Jul 2006 09:12:52 +0200 Hans de Goede j.w.r.degoede@hhs.nl wrote:
I'm seriously considering switching distro's after the AIGLX and target audience discussion. I cannot believe how arrogant most of the replies are, saying that if user install any third party software that then that thirdparty software is their problem.
That hasn't been the only response. There have been suggestions about how those providing support for third party software could manage the software they supply to improve the situation. The main point is that Fedora should not be held hostage by the whims of these outside providers.
I keep hearing this argument, that the packages for the involved drivers can be made to conflict with the update. Which in essence will deprive all but the most technical of our users from security updates. So this is a moot argument. ? Deprive all but the most technical of our users from security updates is almost as bad as completly breaking their system.
Yes completly breaking for a non technicall user an X server refusing to start is almost impossible to fix.
[snip]
I'm just totally stunned by the arrogance in this discussion, the I'm holier then thou stance. And most of all the total disregards to the many end users who happen to rely on the thirdparty software in case.
There isn't a total disregard for many end users, rather a regard for those who will benefit from this upgrade. It has been made pretty clear that those using binary driver need not suffer if their systems are properly configured. If their systems _aren't_ properly configured to deal with a kernel update or X update from core, then this seems like a very useful conversation to have now so that there is time to get those systems into shape beforehand.
They will suffer, see above. Not all our users are yum wizzards.
[snip]
This is not meant as some kinda blackmail to stop the Xorg 7.1 update, to be honest at this point I don't care about the 7.1 update anymore. And as I said when I started the target audience discussion this was never about the 7.1 update. Its about the principle of not knowingly having a yum update during a stable release breaks peoples systems, especially not with a smile on your face and saying behind those end users backs that will teach them not to use binary crap. Because that _IS_ what is happening here. Sure there are many advancements in xorg 7.1 and I'm not suggesting to leave it out FC-6 even if the binary drivers aren't available at FC-6 launch time, but breaking stuff with TOTAL disregard to a large group of end users, during a stable's release lifetime is IMHO unacceptable. And what worries me is not this single instance of breaking, its the attitude behind it and the ease with which we (you?) step over the all of a sudden minor problem of seriously hurting a significant group of end users.
This update should _not_ hurt a significant group of end users. If the binary drivers are supplied and supported properly nobody should be hurt by this upgrade. And it definitely will help a significant group of users. Let's not deprive those users who would benefit from this upgrade without a very good reason.
You keep saying it won't hurt them if that other repo makes their drivers conflict. They will hurt from frustating error messages they don't understand and from lack of security updates see above.
Those that really care about this issue could take the time now to help the users they care about. Updating instructions and howtos for users so they know how to deal with an upgrade to X (or the kernel). Talking with 3rd party repos to make sure that the rpms they provide are designed to protect their users from problems they might experience when the core X or kernel is updated. Letting users on the mailing lists know about an upcoming X upgrade. I'm sure there are other things that could be done as well.
Why should those that care tell the user how to work around a problem being created by people who appereantly don't care? And here we have the real problem, the real problem is not this update this is just an example the real problem is many Fedora developers seem to be so arrogant that they don't care about their endusers. Thank you I guess that is what frustates me the not caring, now can we please start discussing that which IMHO is the real issue and stop discussing the example.
Regards,
Hans
On Fri, 28 Jul 2006 10:13:30 +0200 Hans de Goede j.w.r.degoede@hhs.nl wrote:
I keep hearing this argument, that the packages for the involved drivers can be made to conflict with the update. Which in essence will deprive all but the most technical of our users from security updates. So this is a moot argument. ? Deprive all but the most technical of our users from security updates is almost as bad as completly breaking their system.
No, it is not a moot argument. The security updates will only be unavailable to those users until a new binary-driver is released. Hopefully the creation of a large userbase wanting such an updated driver will motivate the providers to create one. But it's the users of those drivers that should pay the price, not all the open source users.
They will suffer, see above. Not all our users are yum wizzards.
No yum wizardry needed at all if properly managed by the 3rd party repos.
You keep saying it won't hurt them if that other repo makes their drivers conflict. They will hurt from frustating error messages they don't understand and from lack of security updates see above.
Well, I don't know about the conflicts error message, but i'm pretty sure that with enough education users could be taught to understand what it means. Also, there is another option of the binary rpm installing an excludes for the X update so that those users would never even be offered it. I'm sure there are other ways to handle this issue that would make the user experience a little less frustrating. But again, lets not ignore the frustration of users who can't use FC5 fully because support for their cards is much better in 7.1.
Why should those that care tell the user how to work around a problem being created by people who appereantly don't care? And here we have the real problem, the real problem is not this update this is just an example the real problem is many Fedora developers seem to be so arrogant that they don't care about their endusers. Thank you I guess that is what frustates me the not caring, now can we please start discussing that which IMHO is the real issue and stop discussing the example.
Where you see arrogance and a lack of caring I see a difference of opinion and of priorities.
Sean
On 7/28/06, Sean seanlkml@sympatico.ca wrote:
They will suffer, see above. Not all our users are yum wizzards.
No yum wizardry needed at all if properly managed by the 3rd party repos.
There would still be a large number of people who installed nvidia drivers without using rpms, or people who have rpms for it installed but don't get any updates (so they wouldn't receive an update with a Conflicts). We're not talking about a breakage in a small application (where the user could still look online for help), we're talking about a breakage that will leave all but the most competent users unable to fix it from the console.
As for people saying 'Just use an excludes', this argument is not really helpful, as many others have pointed out that we're worried about the people who don't know what the update has in store (and you can hardly blame people for not knowing what the update will do, since yum provides zero information about what the updates contain.)
I presume that most people with FC5 installed would already have working video drivers (or it wouldn't have installed, or would have tried another distribution/OS to find one that works). I'm sure that X.org 7.1 provides some nice updates, but I think the number of people it will actually provide a noticeable improvement to is small (please correct me if I'm wrong).
I don't think proprietry/open-source has anything to do with this. If a large number of users had installed an open source extension from outside Fedora to X that meant this update will stop X from working, what would be done then? Of course it's only hypothetical, and unlikely, but I think it shows that the decision should not be made on the basis of whether or not the conflicting driver is open source.
Personally, I would do the following: - If X.org 7.1 is easy to get working for FC5, then provide a special repo for it and post it on the lists and places like Fedora News and Fedora Forum. Hopefully those people who would benefit from the update will find out about it. - If X.org 7.1 would take some work to get working in FC5, instead use that developer time to improve FC6 so we can all in enjoy it along with X.org 7.1 in early October.
Either way, I don't see Fedora being held back by not pushing the updates for FC5.
n0dalus.
n0dalus <n0dalus+redhat <at> gmail.com> writes:
I don't think proprietry/open-source has anything to do with this. If a large number of users had installed an open source extension from outside Fedora to X that meant this update will stop X from working, what would be done then?
A Fedora user would submit a patch and it would work again. Most likely, this would already have been done by a Rawhide user. Maybe there would even be a package in Extras, ready to be built as soon as the X.Org upgrade goes in. This is really a problem due to unavailability of source code.
Kevin Kofler
On Sat, 29 Jul 2006 00:51:09 +0930 n0dalus n0dalus+redhat@gmail.com wrote:
There would still be a large number of people who installed nvidia drivers without using rpms, or people who have rpms for it installed but don't get any updates (so they wouldn't receive an update with a Conflicts). We're not talking about a breakage in a small application (where the user could still look online for help), we're talking about a breakage that will leave all but the most competent users unable to fix it from the console.
Then people who care about these users should be getting the message out with instructions for them on how to prepare for the coming update. Fedora should not be held hostage because these people were given less than complete advice on installing binary packages. Hopefully this will mean that in the future people who give advice on how to install binary drivers will include _all_ the steps necessary to prevent this problem as well.
Anyone (or any howto, documentation, etc) who helps a naive user install binary drivers without also preparing them (or their systems) to deal with updates to core isn't doing anyone a favor. This situation has to change, and it's not Fedora Core that should pay the price for this community failing.
As for people saying 'Just use an excludes', this argument is not really helpful, as many others have pointed out that we're worried about the people who don't know what the update has in store (and you can hardly blame people for not knowing what the update will do, since yum provides zero information about what the updates contain.)
You _can_ blame the people who helped these people install the binary driver in the first place. The fact that updates (kernel etc) are coming that will be a problem should not be a shock to anyone.
Any documentation howto's etc, should have anticipated this problem and prepared these less competent users machines for this situation. The fact that this wasn't done should not cause Fedora to be handcuffed.
I presume that most people with FC5 installed would already have working video drivers (or it wouldn't have installed, or would have tried another distribution/OS to find one that works). I'm sure that X.org 7.1 provides some nice updates, but I think the number of people it will actually provide a noticeable improvement to is small (please correct me if I'm wrong).
I don't know the numbers. But there will be a significant number of people that have a better support from this new version of X. Enough to justify releasing it even over the complaints of binary-driver users.
I don't think proprietry/open-source has anything to do with this. If a large number of users had installed an open source extension from outside Fedora to X that meant this update will stop X from working, what would be done then? Of course it's only hypothetical, and unlikely, but I think it shows that the decision should not be made on the basis of whether or not the conflicting driver is open source.
It does matter though because Fedora is an open source distribution meant to showcase and support open source software. Those that taint their systems with binary-only drivers take on the responsibility of keeping their systems working. Such systems should not handcuff Fedora from releasing improved open source software to all the users that _don't_ use binary-only drivers. If that ever happens, we've really lost.
Personally, I would do the following:
- If X.org 7.1 is easy to get working for FC5, then provide a special
repo for it and post it on the lists and places like Fedora News and Fedora Forum. Hopefully those people who would benefit from the update will find out about it.
- If X.org 7.1 would take some work to get working in FC5, instead use
that developer time to improve FC6 so we can all in enjoy it along with X.org 7.1 in early October.
If this were a one time thing then maybe you'd have a case. But this will be the same story over and over again whenever a kernel or X update needs to be pushed. Even in FC6, FC7 etc.. No, this needs to be viewed in the longer term, and Fedora just should not be handcuffed because of these users.
Personally, I would do whatever is best for the open source users and let the binary-only users do whatever is necessary to cope. Hopefully, any pain they feel will be mitigated by those users that care enough to prepare them now before the update or (unfortunately) after the update. And all howto's and 3rd party repos should be updated quickly so that this scenario doesn't repeat when the next kernel or X update happens.
Either way, I don't see Fedora being held back by not pushing the updates for FC5.
This isn't just about this one update. It's about all kernel and X (and other?) updates in the future as well.
Sean
Hans de Goede wrote:
Why should those that care tell the user how to work around a problem being created by people who appereantly don't care? And here we have the real problem, the real problem is not this update this is just an example the real problem is many Fedora developers seem to be so arrogant that they don't care about their endusers. Thank you I guess that is what frustates me the not caring, now can we please start discussing that which IMHO is the real issue and stop discussing the example.
FWIW and even though it's probably not the best example in the world. Large proprietary corporations sometimes update stuff even though it means that a few thousand+ users will end up with a broken system. Our friends in Redmond are but one example. And those guys aren't even that biased towards technical improvement vs user friendliness.
The point is that Fedora has a dedicated mission to provide a completely free OS. Because of this and a number of other things, we cannot wait for binary-only, non-free driver vendors to catch up all the time. This has been said several times before. If we actually chose to wait for Nvidia/ATI (as an example), what other stuff do we need to wait for next? Perhaps a security problem in the kernel breaks certain binary-only network drivers? perhaps a bug release of glibc has the possibility of causing instabilities in a proprietary database engine? It's just not possible to predict, prevent and/or regard all of the problems that MAY arise because of unsupported stuff - That's why it's unsupported in the first place. And there are certainly no reason why such unsupported components should prolong the adaption of improved components for the rest of the userbase.
I'm firmly of the belief that Fedora should NOT wait for anything like this. Problems like these are best regarded by the 3rd party repos like livna or atrpms. However, I can understand the unfortunate problem for users who depend on the binary drivers too. My thought is that if an update causing problems for a non-free, binary-only driver is not acceptable (it's acceptable for me and the proprietary drivers I have to deal with on certain Fedora machines), then they should probably choose a different platform for those systems (I have lots of RHEL systems too because of support issues with proprietary stuff too). There are several free and non-free projects that will be more ABI stable than Fedora (And there are free RHEL-like distros to choose from as well). But a lot of us LIKE this characteristic about Fedora. Actually all the catering to binary and non-free stuff are some of the things that keep me away from other distros for certain types of machines. I suspect a few other Fedora users feel the same way about this.
Again - It has absolutely nothing to do with deliberately breaking stuff for anyone. I don't think most of the replies in this discussion has been mean or arrogant. But some updates will benefit a lot of users who have NOT chosen to rely on a binary-only driver that the Fedora community or any other open community have no possible way to support and so this is the way it essentially has to be.
If anything in the above sounds arrogant in any way, it's unintended.
/Thomas
On Friday 28 July 2006 11:37, Thomas M Steenholdt wrote:
I'm firmly of the belief that Fedora should NOT wait for anything like this. Problems like these are best regarded by the 3rd party repos like livna or atrpms. However, I can understand the unfortunate problem for users who depend on the binary drivers too. My thought is that if an update causing problems for a non-free, binary-only driver is not acceptable (it's acceptable for me and the proprietary drivers I have to deal with on certain Fedora machines), then they should probably choose a different platform for those systems (I have lots of RHEL systems too because of support issues with proprietary stuff too). There are several free and non-free projects that will be more ABI stable than Fedora (And there are free RHEL-like distros to choose from as well). But a lot of us LIKE this characteristic about Fedora. Actually all the catering to binary and non-free stuff are some of the things that keep me away from other distros for certain types of machines. I suspect a few other Fedora users feel the same way about this.
(Maybe we should have discussed of that in the thread "Fedora's intended target audience?". So I have at least changed the subject.)
Since Fedora Core 1 has been published, several French public research institutes have decided to switch to FC. For example: - the ENS ("École Normale Supérieure") of Paris, has switched from a non uniform park of FreeBSD/Redhat/Solaris machines to an almost full exclusive park of FC machines, - the Inria ("Institut National de Recherche en Informatique et en Automatique") of Sophia Antipolis has switched from a home-maintained Redhat-6.1 (with a huge /usr/local on NFS) to Fedora Core.
In both cases, the reasons were: - easier security updates, - easier way to maintain a system up-to-date (but not bleeding-edge, in which case they would probably have switched to a Debian-testing), - free (as in "free beer"): these institutes could not decide to buy RHEL, which would be to much cost for the whole park of machines. The budgets in public institutes are decreasing each year.
At the ENS, it is 258 machines, and at the Inria it is 689 machines.
These ABI breakage we are talking about (soname clashes, kernel changes, x.org ABI) are a pain in the ass of the system administrators, for several reasons: 1/ Every computer science projects, in these institutes, are developping software with Fedora as the developping platform. Some of them are even developping free software. Here is a list of free software packages developed at Inria, for example: http://pauillac.inria.fr/cdrom/prog/unix/eng.htm Some of them are packaged by Fedora, but some others are not yet ready for inclusion in a linux distribution. Each time a library changes its soname in Fedora, and no compat-* package is published instead, then some tools developed locally need to be recompiled, if possible, or the old version of the library has to be installed in /usr/local/. 2/ Some binary kernel of X11 drivers are needed, because the researchers of these institutes do no always check the support status before buying a new laptop, for example. Or because some research projects have a real need of 3D acceleration (when dealing with surface meshes with millions of triangles). The kernel issue is handled by the administrators: they use their own home-made and patched kernel. But the X11 problem would really be a problem. The administrators recommend to researchers to "yum update" their Fedora regularly. If you decide to push x.org-7.1 is FC-5, the next yum update will lead to X11 servers not run at all!
In one hand, it seems normal that a FC major release (FC-6) breaks ABI compatibility. One the other hand, administrators and researchers expect Fedora Core not to be "broken" by daily updates.
I understand those who answer "Fedora will not be broken". Yes, that's true. But the ABI will be broken for third party software, even if they are under GPL! And the X11 servers of a big part of the Inria will crash with next daily update.
It would be nice that those ABI incompatibilities are avoided during the life time of a major release of FC+FE. If people wants bleeding edge software, they can use FC+FE-devel, or special third part repo that will backport some of the FC-devel software to FC-5.
If FC is "broken" too often, from *the user perspective*, some users will just switch to another distro, and I do not think it will be good for Fedora.
As regards the institutes I told about above, if some ABI breakage occur too often in the life time of a major release of FC+FE, I know that the administrators will switch to something else. I hope that we will avoid that.
On Friday 28 July 2006 11:29, Laurent Rineau wrote:
Since Fedora Core 1 has been published, several French public research institutes have decided to switch to FC. For example: - the ENS ("École Normale Supérieure") of Paris, has switched from a non uniform park of FreeBSD/Redhat/Solaris machines to an almost full exclusive park of FC machines, - the Inria ("Institut National de Recherche en Informatique et en Automatique") of Sophia Antipolis has switched from a home-maintained Redhat-6.1 (with a huge /usr/local on NFS) to Fedora Core.
Ew. Why in gods name would you base 'mission critical' systems on Fedora? Easier security updates? What? In fedora its more often than not the latest upstream version to fix a flaw, not a backport. Life span is very quick, systems will become unmaintained in just a few years time.
Those firms would have been much better off using a (free) enterprise minded distribution. Backported fixes, low churn, 5+ years of maintenance, etc...
Frankly these really aren't the target users of Fedora, and they probably should move to another distribution. Fedora doesn't need world dominance, we don't need every user. Trying to cater to them all is the path to insanity.
Jesse Keating <jkeating <at> redhat.com> writes:
Those firms would have been much better off using a (free) enterprise minded distribution. Backported fixes, low churn, 5+ years of maintenance, etc...
Scientific Linux for example. This has been put together by CERN and Fermilab, and is used in several research institutions. And it's a rebuild of RHEL's SRPMs, just like CentOS (which is also an option).
Kevin Kofler
On Fri, 28 Jul 2006, Kevin Kofler wrote:
Jesse Keating <jkeating <at> redhat.com> writes:
Those firms would have been much better off using a (free) enterprise minded distribution. Backported fixes, low churn, 5+ years of maintenance, etc...
Scientific Linux for example. This has been put together by CERN and Fermilab, and is used in several research institutions. And it's a rebuild of RHEL's SRPMs, just like CentOS (which is also an option).
As someone who helps choose a distribution for science work, it's very hard. Fedora moves so fast and updates so often that you cannot base anything stable on it, and the admin spends his life running around fixing things. I assume the only target audience for Fedora are hobbyists.
RHEL/CentOS/SciLinux move so slowly (particularly now that RH have slowed down the major release rate) that you end up with an ancient kernel that does not support the USB stuff scientists want or latest chipsets, an X.org which doesn't support the only graphics card you can buy (without nonfree drivers), and an archaic Python which doesn't run the software you want.
Such is life (any distribution suggestions welcome :-) (SL at work, Fedora at home)... I think this post is offtopic enough now.
Jeremy
Le vendredi 28 juillet 2006 à 11:39 -0400, Jesse Keating a écrit :
Ew. Why in gods name would you base 'mission critical' systems on Fedora? Easier security updates? What? In fedora its more often than not the latest upstream version to fix a flaw, not a backport. Life span is very quick, systems will become unmaintained in just a few years time.
Those firms would have been much better off using a (free) enterprise minded distribution. Backported fixes, low churn, 5+ years of maintenance, etc...
It's not firms it's public IT research institutes and high-level math universities (google INRIA or ENS)
Of course they don't do research on 5-years-old systems
Of course they want to spend their research money on lab experiments, not sparcstations or RHEL WS
Of course they want something their students can run in their room.
This being said, they can certainly afford a local Fedora mirror with a sysadmin which filters updates and blocks xorg 7.1 if they have labs with nvidia systems.
On Friday 28 July 2006 12:27, Nicolas Mailhot wrote:
Of course they want to spend their research money on lab experiments, not sparcstations or RHEL WS
Of course they want something their students can run in their room.
Enterprise themed distributions need not cost money. Surely you understand that and know of the options out there...
Le vendredi 28 juillet 2006 à 12:30 -0400, Jesse Keating a écrit :
On Friday 28 July 2006 12:27, Nicolas Mailhot wrote:
Of course they want to spend their research money on lab experiments, not sparcstations or RHEL WS
Of course they want something their students can run in their room.
Enterprise themed distributions need not cost money. Surely you understand that and know of the options out there...
Which is why I totally understand they run Fedora. Sorry.
They've been in the game long enough to know they don't have the volume effects of multinationals, and the fat discount a vendor will give them today may vanish a few years later.
Also entreprise distros are a very bad fit for research (entreprise research or education sector research). The users population can't stand them.
(and lastly given the central role these institutes play in the French IT sector, and that most of past and present French FLOSS contributors passed through them, if I were a Red Hat marketing guy I'd be ordering a truck of champaign bottles after learning they run Fedora. Not a reason to postpone the Xorg 7.1 push, but certainly a reason to listen to what they say)
On Friday 28 July 2006 19:48, Nicolas Mailhot wrote:
(and lastly given the central role these institutes play in the French IT sector, and that most of past and present French FLOSS contributors passed through them, if I were a Red Hat marketing guy I'd be ordering a truck of champaign bottles after learning they run Fedora. Not a reason to postpone the Xorg 7.1 push, but certainly a reason to listen to what they say)
Well... I am certainly not the best guy to represent the French IT research institutes. I am only a Phd student at the Inria of Sophia Antipolis, formerly a student at the ENS of Paris.
I will try to make Inria's sysadmin read at least that thread, so that they can participate.
fre, 28 07 2006 kl. 11:39 -0400, skrev Jesse Keating:
Ew. Why in gods name would you base 'mission critical' systems on Fedora? Easier security updates? What? In fedora its more often than not the latest upstream version to fix a flaw, not a backport. Life span is very quick, systems will become unmaintained in just a few years time.
Those firms would have been much better off using a (free) enterprise minded distribution. Backported fixes, low churn, 5+ years of maintenance, etc...
Frankly these really aren't the target users of Fedora, and they probably should move to another distribution. Fedora doesn't need world dominance, we don't need every user. Trying to cater to them all is the path to insanity.
Whenever I hear the words mission critical something inside my brain tells me that unless this is a small server I can afford to fix issue on myself (time is money), I should buy support from Red Hat. If you can't afford that to ensure your mission critical data then it's probably not all that critical anyways or your time isn't valuable.
Regardless we have offering for all levels, Fedora if you want high churn, the lastest and greatest while retaining good stability. CentOS for the cheap enterprise level deployment without the need for support and RHEL if you really want a complete enterprise system (OS and services).
The beauty of Fedora is that it's a very good distribution to adjust to different needs, it forms the basis of anything from the really high end RHEL type distributions, down to ressource constrained deployments like OLPC. We do need world domination but we get it through versatility.
- David Nielsen
Laurent Rineau laurent.rineau__fedora_extras@normalesup.org writes:
At the ENS, it is 258 machines, and at the Inria it is 689 machines.
And you tell us they have no central distribution points for updates and for custom packages, and have no single sysadmin able to, at the very least, exclude or include whatever is needed for successful operation of a particular binary driver?
Of course I don't know if they have NVidia-based cards running NVidia drivers. Chances are they don't play Doom.
I can believe it might be a problem for part of home users (gamers?) but a research institute is way too much for me.
OTOH, I wonder how many people on this list would have a problem themselves. Especially if livna/etc. provided "conflicting" driver package(s).
On Fri, 28 Jul 2006, Krzysztof Halasa wrote:
Laurent Rineau laurent.rineau__fedora_extras@normalesup.org writes:
At the ENS, it is 258 machines, and at the Inria it is 689 machines.
And you tell us they have no central distribution points for updates and for custom packages, and have no single sysadmin able to, at the very least, exclude or include whatever is needed for successful operation of a particular binary driver?
A number of people here use the Livna packages for nVIDIA. I always just build the driver myself. (One of the first things I do is set the default run level to 3 when I install Fedora.)
Of course I don't know if they have NVidia-based cards running NVidia drivers. Chances are they don't play Doom.
That is not the only reason to install the driver. For nVIDIA, if you want to use the second screen or s-video output jacks, you have to use the commercial driver. You also need it if you switch back and forth from X to console. (Otherwise you get a corrupted screen when you leave X.)
I can believe it might be a problem for part of home users (gamers?) but a research institute is way too much for me.
Unless you run on a laptop and have to give presentations.
OTOH, I wonder how many people on this list would have a problem themselves. Especially if livna/etc. provided "conflicting" driver package(s).
The problem with nVIDIA and X 7.1 is not a crash, it is screen corruption.
I am coming to the opinion that we need to update anyways, if nothing else to prod the vendors into supporting code that has been out since May. The attitude is that they won't support it until a bunch of people use it. If we say we won't use it until it is supported then we reach a deadlock condition that will not be resolved until the vendor or the distro are rebooted.
alan alan@clueserver.org writes:
A number of people here use the Livna packages for nVIDIA. I always just build the driver myself. (One of the first things I do is set the default run level to 3 when I install Fedora.)
But for a sysadmin at an institute both rpm and non-rpm drivers are not at problem - (s)he can disable the update (in this case, X.org update) at the central mirror (or whatever it's there).
Unless you run on a laptop and have to give presentations.
I just made sure it doesn't have NVidia chip :-)
On Friday 28 July 2006 18:58, Krzysztof Halasa wrote:
Laurent Rineau laurent.rineau__fedora_extras@normalesup.org writes:
At the ENS, it is 258 machines, and at the Inria it is 689 machines.
And you tell us they have no central distribution points for updates and for custom packages, and have no single sysadmin able to, at the very least, exclude or include whatever is needed for successful operation of a particular binary driver?
Actually, the ENS only has a proxy, but the Inria has as Fedora Core+Extras mirror server, in which they could blacklist some packages at need.
Of course I don't know if they have NVidia-based cards running NVidia drivers. Chances are they don't play Doom.
We do not play doom, but in my team at Inria we work with surfacic or volumic meshes with millions of triangles or tetrahedra.
I can believe it might be a problem for part of home users (gamers?) but a research institute is way too much for me.
The more the work will be difficult for sysadmin to maintain usable systems for researchers, the more they will thing about switching to something else (actually, I agree that Fedora may not have been the best choice, for them).
OTOH, I wonder how many people on this list would have a problem themselves. Especially if livna/etc. provided "conflicting" driver package(s).
On my machine (nvidia drivers installed by hand), the upgrade would lead to a crashing X11 server. Actually, I am not the kind of user who could be disappointed by that problem.
Laurent Rineau laurent.rineau__fedora_extras@normalesup.org writes:
Actually, the ENS only has a proxy,
A caching proxy perhaps? Isn't it possible to disable the X update there?
We do not play doom, but in my team at Inria we work with surfacic or volumic meshes with millions of triangles or tetrahedra.
Ok :-)
On Friday 28 July 2006 19:55, Krzysztof Halasa wrote:
Laurent Rineau laurent.rineau__fedora_extras@normalesup.org writes:
Actually, the ENS only has a proxy,
A caching proxy perhaps? Isn't it possible to disable the X update there?
Yes, a caching proxy. Actually, the ENS of Paris has no intranet (all machines have public IPs). The only purpose of that proxy is its cache feature. I should have told that.
I duno if it is easy to configure such a caching proxy to block some updates. Actually, the ENS sysadmins should switch to a fedora mirror, anyway. I know that they already have one, not used.
Dnia 28-07-2006, pią o godzinie 10:13 +0200, Hans de Goede napisał(a):
I keep hearing this argument, that the packages for the involved drivers can be made to conflict with the update. Which in essence will deprive all but the most technical of our users from security updates.
This is, once again, the yum bugs coming back.
Seth thinks yum shouldn't be able to downgrade packages (if you install newer Y and encounter a regression, you can't go back to the previous version, except for the kernel, where you can have many versions installed).
Seth thinks yum shouldn't be able to update all packages it can when there are a few with broken dependencies (if an update to Y is available, but conflits with Z... packages A...W won't be updated).
(where package Y can be Xorg 7.1 we're talking about)
Seth thinks introducing 2-3 weeks long lag (this number is not imaginary, that's a real mirror lag) of security updates, during which I download tens of megabytes of xml data (from 20 and 19 days ago, back and forth), is little cost (!) comparing to one temporary file on my own machine (less than 1 KiB) and simple checking if timestamp > timestamp (not to mention centralized server with only repo data, always up to date).
He doesn't get my English, probably nobody else does, I don't write in Python and maybe that's why yum still stinks ;) But let me say this again: yum stinks. You look convinced that yum is everything the user can get and if it works the way it works, it's everyone else responsible to not do anything that yum can't handle gracefully.
Wrong! First of all, yum and its front ends (pup) can be changed to hold upgrading Xorg 7.1 (and only Xorg 7.1) when there are explicit conflicts. Secondly, the default configuration of yum in FC5 is holding security updates for as long as two weeks (I promise you it's true, although my record was 8 days, running "yum update" two times a day).
I said it before and I say it again: I'm convinced that NVIDIA has newer driver almost ready (they had time and they officially stated they're working on it few months ago) and can take us by surprise releasing it anytime they need. I'm brave and say: NVIDIA can release appropriate binary driver faster than yum can download security updates with its default configuration :)
So in my opinion, it is yum to be blamed, not Xorg packager, Fedora Project Board or anyone else making decisions, because we could do everything to everyone (!) if only yum was a little bit friendlier.
In other words, we're all arguing about a thing that shouldn't even be arguable.
I would miss you Hans, please don't go! :)
Lam
I think that people using Binary Drivers have the knowledge to modify xorg.conf and change nvidia to nv if their systems break before xorg update. Xorg must to be updated like another pieces of Fedora. This can't be the exception. Think in kernel and you have the answer. IMHO this will help to improve the time of Nvidia and ATI to release drivers for Xorg 7.1
----- Original Message ---- From: Leszek Matok Lam@Lam.pl To: Development discussions related to Fedora Core fedora-devel-list@redhat.com Sent: Friday, July 28, 2006 7:17:21 AM Subject: Re: Leaving?
Dnia 28-07-2006, pią o godzinie 10:13 +0200, Hans de Goede napisał(a):
I keep hearing this argument, that the packages for the involved drivers can be made to conflict with the update. Which in essence will deprive all but the most technical of our users from security updates.
This is, once again, the yum bugs coming back.
Seth thinks yum shouldn't be able to downgrade packages (if you install newer Y and encounter a regression, you can't go back to the previous version, except for the kernel, where you can have many versions installed).
Seth thinks yum shouldn't be able to update all packages it can when there are a few with broken dependencies (if an update to Y is available, but conflits with Z... packages A...W won't be updated).
(where package Y can be Xorg 7.1 we're talking about)
Seth thinks introducing 2-3 weeks long lag (this number is not imaginary, that's a real mirror lag) of security updates, during which I download tens of megabytes of xml data (from 20 and 19 days ago, back and forth), is little cost (!) comparing to one temporary file on my own machine (less than 1 KiB) and simple checking if timestamp > timestamp (not to mention centralized server with only repo data, always up to date).
He doesn't get my English, probably nobody else does, I don't write in Python and maybe that's why yum still stinks ;) But let me say this again: yum stinks. You look convinced that yum is everything the user can get and if it works the way it works, it's everyone else responsible to not do anything that yum can't handle gracefully.
Wrong! First of all, yum and its front ends (pup) can be changed to hold upgrading Xorg 7.1 (and only Xorg 7.1) when there are explicit conflicts. Secondly, the default configuration of yum in FC5 is holding security updates for as long as two weeks (I promise you it's true, although my record was 8 days, running "yum update" two times a day).
I said it before and I say it again: I'm convinced that NVIDIA has newer driver almost ready (they had time and they officially stated they're working on it few months ago) and can take us by surprise releasing it anytime they need. I'm brave and say: NVIDIA can release appropriate binary driver faster than yum can download security updates with its default configuration :)
So in my opinion, it is yum to be blamed, not Xorg packager, Fedora Project Board or anyone else making decisions, because we could do everything to everyone (!) if only yum was a little bit friendlier.
In other words, we're all arguing about a thing that shouldn't even be arguable.
I would miss you Hans, please don't go! :)
Lam
Hi,
I think that people using Binary Drivers have the knowledge to modify xorg.conf and change nvidia to nv if their systems break before xorg update.
They don't and that's the point. To say that they have that knowledge is wrong. Some may; to assume that all who use binary drives will know what to do is wrong.
If the Noblets is using FC6 and install the binary ATI or nVidia driver so little Jimmy can play UT2004 or Doom3 or <insert another game which needs 3D acceleration>, they know the driver will work for the current set up. Not the current kernel, but the current set up. There is a big difference.
They download the xorg updates with a new kernel and bang, desktop gone. Not even a safemode to boot to. They start fretting and go back over to the darkside "where at least I can go in as Admin, safe mode boot and download/install the latest nVidia driver and get things going again - none of this low level arsing about".
A big warning needs to appear on yum/yumex/pup/RHN when something is going to stop a binary only driver from working which will automatically disable downloading the bit which breaks the driver if the user doesn't want it.
Xorg must to be updated like another pieces of Fedora. This can't be the exception. Think in kernel and you have the answer. IMHO this will help to improve the time of Nvidia and ATI to release drivers for Xorg 7.1
And how long was it before nVidia released a driver which understood how xorg was set up as opposed to how x11r6 was set?
No. Things have to move forward. If we have the failsafe in place that stops the breakage, then users are protected should they need to be.
TTFN
Paul
On Fri, Jul 28, 2006 at 03:51:07PM +0100, PFJ wrote:
A big warning needs to appear on yum/yumex/pup/RHN when something is going to stop a binary only driver from working which will automatically disable downloading the bit which breaks the driver if the user doesn't want it.
Providing the Nvidia drivers correctly specify what they are compatible with yum will handle it. If the Nvidia drivers forgot to specify a requires or conflicts line they won't. If the user dumped the drivers on there without using package management as many do then the info doesn't even exist.
Alan
On Fri, Jul 28, 2006 at 15:51:07 +0100, PFJ paul@all-the-johnsons.co.uk wrote:
They download the xorg updates with a new kernel and bang, desktop gone. Not even a safemode to boot to. They start fretting and go back over to the darkside "where at least I can go in as Admin, safe mode boot and download/install the latest nVidia driver and get things going again - none of this low level arsing about".
Are you claiming there isn't a safe mode or that they don't know to how to boot into run level 3?
Hi,
They download the xorg updates with a new kernel and bang, desktop gone. Not even a safemode to boot to. They start fretting and go back over to the darkside "where at least I can go in as Admin, safe mode boot and download/install the latest nVidia driver and get things going again - none of this low level arsing about".
Are you claiming there isn't a safe mode or that they don't know to how to boot into run level 3?
If they've installed say the ATI or nVidia drivers and are normal users (read most people), it is quite likely that they won't even know what a run level is let alone know how to use it.
TTFN
Paul
Dnia 28-07-2006, pią o godzinie 21:29 +0100, Paul napisał(a):
Are you claiming there isn't a safe mode or that they don't know to how to boot into run level 3?
If they've installed say the ATI or nVidia drivers and are normal users (read most people), it is quite likely that they won't even know what a run level is let alone know how to use it.
This is FUD. If nvidia driver breaks, you have to press Enter 3 times when gdm can't start X and voila - it's autoconfiguring with the driver shipped by Fedora, goes graphical and asks you for resolutions and stuff. I understand you want 3D, me too, but please you two, don't make people believe they have to type in some voodoo spells in the console to get X working, as they don't.
Lam
Hi,
If they've installed say the ATI or nVidia drivers and are normal users (read most people), it is quite likely that they won't even know what a run level is let alone know how to use it.
This is FUD.
No it's not. Put yourself in the shoes of Joe Average
If nvidia driver breaks, you have to press Enter 3 times when gdm can't start X and voila - it's autoconfiguring with the driver shipped by Fedora, goes graphical and asks you for resolutions and stuff.
Doesn't. When you install the nVidia driver, it alters the xorg file which FC doesn't fix when you go through the set up.
You also have the added "what the hell is all of this" factor - when faced with choosing modes, colour depths and the such, quite a lot of people will panic.
Look, we (on this list) can get out of many a sticky situation just because we've been using Linux for that long and have decided to get out hands dirty and mucked around with the internals. Many won't. I know my other half hasn't and she's been using Linux at home since RH 7.3. Stuff "just works" and she's happy. She (and my kids) are not allowed on my rawhide box because while I can always get it to work (give or take), it can do weird things.
I understand you want 3D, me too, but please you two, don't make people believe they have to type in some voodoo spells in the console to get X working, as they don't.
True, they have to understand though what is going on. Think about it. You're used to the normal gdm login when you're met with some non-GUI interface you've never seen before, being asked questions you possibly don't understand (how many people know the max resolution and colour depth of their monitor, especially as there are that many generics out there?) and at the end, X may or may not start.
I'm not saying users are thick. They're not - they've had the brains and sense to come and play on Linux, but expecting them to be able fix things with a command line interface? My son has never seen a command line interface (uses W2K at school, FC5 here), neither has my mother (uses XP). I wouldn't expect either to be able to get an X server running again.
TTFN
Paul
Dnia 28-07-2006, pią o godzinie 22:01 +0100, Paul napisał(a):
Doesn't. When you install the nVidia driver, it alters the xorg file which FC doesn't fix when you go through the set up.
I went through this yesterday - I replaced my GeForce 4 card with Voodoo 3 without removing nvidia packages (livna ones, altering xorg.conf on every boot). All went smooth except for the one thing livna's nvidia-glx breaks tdfx DRI on every reboot (like you say), but I have 2D working perfectly (and I won't expect Doom 3 to run on Voodoo 3 anyhow).
Oh, and I had to restore my ModeLine, which is a hack aiming to break the monitor and no Joe Average does this anyhow.
Maybe switching from nvidia to nv instead of tdfx gives people more problems, I don't know for sure, but it's not highly probable to me.
You also have the added "what the hell is all of this" factor - when faced with choosing modes, colour depths and the such, quite a lot of people will panic.
It's "thousands of colours", "millions of colours", which is better than scaring the user with "16bpp", "24bpp" :)
I know it's still tough choice, but simply accepting the default still gives you graphical environment. It's not that bad. Windows goes to 800x600 when it breaks, too. The grand-parent message was talking about absolute lack of fail safe mode and going to runlevel 3, which really isn't necessary, or wasn't when I tried yesterday.
Lam
Hi,
Doesn't. When you install the nVidia driver, it alters the xorg file which FC doesn't fix when you go through the set up.
I went through this yesterday - I replaced my GeForce 4 card with Voodoo 3 without removing nvidia packages (livna ones, altering xorg.conf on every boot). All went smooth except for the one thing livna's nvidia-glx breaks tdfx DRI on every reboot (like you say), but I have 2D working perfectly (and I won't expect Doom 3 to run on Voodoo 3 anyhow).
Hello. My name is Dev Ilsadvokate. I know of the fedora update things, but what on Earth is a livna? I just used the ones from the nVidia website.
Now, why isn't my system working after the latest update?
Now do you see the problem?
TTFN
Paul
On Fri, 28 Jul 2006 22:34:52 +0100 Paul paul@all-the-johnsons.co.uk wrote:
Hello. My name is Dev Ilsadvokate. I know of the fedora update things, but what on Earth is a livna? I just used the ones from the nVidia website.
Now, why isn't my system working after the latest update?
Now do you see the problem?
Yes. The nVidia website.
It should be fixed if they care about their users.
Sean
On 7/28/06, Paul paul@all-the-johnsons.co.uk wrote:
Hello. My name is Dev Ilsadvokate. I know of the fedora update things, but what on Earth is a livna? I just used the ones from the nVidia website.
Now, why isn't my system working after the latest update?
Now do you see the problem?
Hello, My name is Beating De SameDeadHoss. I went and installed a SupaDupaKernelDriver-0.0.1a.rpm from www.supadupakerneldrivers.com and now that I have ran yum update, my machine no longer boots, because the sneaky bastards have upgraded my kernel.
How is this different from the stupid nvidia driver crap? Why is this even an issue? Since when do we care about randomly installed unsupported software? It's always been breaking and it will continue breaking, because that's just how things are with 3rd party stuff. It's not any different on any other OS. Almost every windows update breaks some pre-installed software, and the same is true for Mac.
This conversation is utterly pointless.
Leszek Matok <Lam <at> Lam.pl> writes: [list of yum's shortcomings]
He doesn't get my English, probably nobody else does, I don't write in Python and maybe that's why yum still stinks ;) But let me say this again: yum stinks.
And there's even a solution for that: yum install apt (really the only thing yum is good for ;-) ).</rant>
Kevin Kofler
Dnia 28-07-2006, pią o godzinie 16:21 +0000, Kevin Kofler napisał(a):
And there's even a solution for that: yum install apt (really the only thing yum is good for ;-) ).</rant>
And what do you think I did? :) But there still are problems, one is the default SELinux label, https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=198617 and the other is the double free when you hit ^C (I think it's been there since the beginning), it spits more error messages than yum! Apt is not holy, you know :)
Lam
On Friday 28 July 2006 04:13, Hans de Goede wrote:
I keep hearing this argument, that the packages for the involved drivers can be made to conflict with the update. Which in essence will deprive all but the most technical of our users from security updates. So this is a moot argument. ? Deprive all but the most technical of our users from security updates is almost as bad as completly breaking their system.
So you'd rather we hold the update for EVERYBODY so that EVERYBODY gets denied the update? yeah, that's progress...
On Friday 28 July 2006 16:16, Jesse Keating wrote:
On Friday 28 July 2006 04:13, Hans de Goede wrote:
I keep hearing this argument, that the packages for the involved drivers can be made to conflict with the update. Which in essence will deprive all but the most technical of our users from security updates. So this is a moot argument. ? Deprive all but the most technical of our users from security updates is almost as bad as completly breaking their system.
So you'd rather we hold the update for EVERYBODY so that EVERYBODY gets denied the update? yeah, that's progress...
If I extend your idea, FC-5 should exactly the same as FC-devel. A major release of FC should avoid breaking things. The ABI-breaking updates should be reserved for FC-devel and next major release (in that case FC-6).
On Friday 28 July 2006 11:21, Laurent Rineau wrote:
If I extend your idea, FC-5 should exactly the same as FC-devel. A major release of FC should avoid breaking things. The ABI-breaking updates should be reserved for FC-devel and next major release (in that case FC-6).
Only the internal X abi is breaking, nothing that USES X breaks. Please try again.
Jesse Keating wrote:
On Friday 28 July 2006 11:21, Laurent Rineau wrote:
If I extend your idea, FC-5 should exactly the same as FC-devel. A major release of FC should avoid breaking things. The ABI-breaking updates should be reserved for FC-devel and next major release (in that case FC-6).
Only the internal X abi is breaking, nothing that USES X breaks. Please try again.
Its an open, published api and was designed as such there is nothing internal about it, you try again.
Regards,
Hans
On 7/29/06, Jesse Keating jkeating@redhat.com wrote:
On Friday 28 July 2006 11:21, Laurent Rineau wrote:
If I extend your idea, FC-5 should exactly the same as FC-devel. A major release of FC should avoid breaking things. The ABI-breaking updates should be reserved for FC-devel and next major release (in that case FC-6).
Only the internal X abi is breaking, nothing that USES X breaks. Please try again.
Correct me if I'm wrong, but isn't most of this discussion about something which currently uses X breaking? Just because it uses the internal ABI doesn't really mean anything.
n0dalus.
On Friday 28 July 2006 11:31, n0dalus wrote:
Correct me if I'm wrong, but isn't most of this discussion about something which currently uses X breaking? Just because it uses the internal ABI doesn't really mean anything.
Yes, the thread is about binary 3rd party modules which are outside the X tree. Which frankly, I could give a give a rip about. We break the ABI all the time with kernel updates. Users have to get the new module. This is only slightly different in that there isn't a new module yet for them. Too bad, that's an Nvidia problem, not our problem.
On Fri, 2006-07-28 at 11:34 -0400, Jesse Keating wrote:
On Friday 28 July 2006 11:31, n0dalus wrote:
Correct me if I'm wrong, but isn't most of this discussion about something which currently uses X breaking? Just because it uses the internal ABI doesn't really mean anything.
Yes, the thread is about binary 3rd party modules which are outside the X tree. Which frankly, I could give a give a rip about. We break the ABI all the time with kernel updates. Users have to get the new module. This is only slightly different in that there isn't a new module yet for them. Too bad, that's an Nvidia problem, not our problem.
I wonder why ppl are making such a big deal out of this driver thing. Dave Airlie wrote a working ATI driver for their newest cards http://airlied.livejournal.com/31180.html?view=56012#t56012 the only tiny problem is that the register names and bit positions are so super secret that ATI will not even talk to Dave about allowing him to release his driver. So instead of wasting our energy here fighting each other maybe we should put the same amount of effort in pointing out to the world that not only does ATI refuse to write a working Linux driver, they even go as far as actively prevent others from writing drivers for them (how stupid can you be to refuse someone to work for you for free!). BTW we are not talking here about open sourcing the driver ATI wrote, we are talking about a list of register names!
So binary drivers are not a Fedora problem, this is plain and simple a problem of a company that does not want you (a Linux user) to be their customer. I may hope that AMD does want us as a customer, I already had to buy a Intel based laptop so that I at least have a open source Xorg driver for that.
- Erwin
PS: This also is valid for nVidea, but the open source driver for nVideo cards is even worse than the ATI ones. And also for Matrox, they ones were the love of every Linux user, until they decided that Open Source was bad, and now they are gone.
Ok. How we can provide a warning before Xorg Update to binary drivers users? Dependencies will reach? Or need to have something new?
----- Original Message ---- From: n0dalus n0dalus+redhat@gmail.com To: Development discussions related to Fedora Core fedora-devel-list@redhat.com Sent: Friday, July 28, 2006 12:31:12 PM Subject: Re: Leaving?
On 7/29/06, Jesse Keating jkeating@redhat.com wrote:
On Friday 28 July 2006 11:21, Laurent Rineau wrote:
If I extend your idea, FC-5 should exactly the same as FC-devel. A major release of FC should avoid breaking things. The ABI-breaking updates should be reserved for FC-devel and next major release (in that case FC-6).
Only the internal X abi is breaking, nothing that USES X breaks. Please try again.
Correct me if I'm wrong, but isn't most of this discussion about something which currently uses X breaking? Just because it uses the internal ABI doesn't really mean anything.
n0dalus.
On Friday 28 July 2006 17:26, Jesse Keating wrote:
On Friday 28 July 2006 11:21, Laurent Rineau wrote:
If I extend your idea, FC-5 should exactly the same as FC-devel. A major release of FC should avoid breaking things. The ABI-breaking updates should be reserved for FC-devel and next major release (in that case FC-6).
Only the internal X abi is breaking, nothing that USES X breaks. Please try again.
I was thinking about third-party modules for x.org-7.x. I see your point.
Please read my new mail "Fedora target audience, what about the research area? (was Re: Leaving?)", in the same thread. I have tried to explain the problem from some "institutional" users.
The same problem occurs with the kernel: ABI changes are usually internal to the kernel+libc. But there are third-party kernel modules, again.
In the mail I quote above, I try to explain why the ABI of shared library should be preserved during the life time of a major release of Fedora, as much as possible.
Laurent Rineau wrote:
On Friday 28 July 2006 17:26, Jesse Keating wrote:
Only the internal X abi is breaking, nothing that USES X breaks. Please try again.
I was thinking about third-party modules for x.org-7.x. I see your point.
Most of those are already in core that can be, for the same reason that all the kernel drivers are in core that can be: the user experience is better if you get drivers for everything straight from install time. We made sure linuxwacom and synaptics were ABI-compatible when we went to 7.1 even though they're not part of Xorg proper.
If you know of any external X drivers we've missed that should be in core, please file bugs. I know we've skipped a couple for lack of Fedora platform support (newport and impact for the SGI MIPS machines, the various Sun drivers for sparc) but there may be others.
If the thought of your closed driver breaking in 7.1 (and inevitably in the future too) has you worried, perhaps you should be communicating your concerns about closed source to the provider of that driver.
As a practical matter, getting 7.1 into FC5 is a bit of a hostile move. I'd _much_ prefer to see the bling repo expanded to just include all of 7.1. But I'm not particularly pleased that I have to compromise for the sake of broken drivers.
- ajax
Laurent Rineau laurent.rineau__fedora_extras@normalesup.org writes:
On Friday 28 July 2006 16:16, Jesse Keating wrote:
On Friday 28 July 2006 04:13, Hans de Goede wrote:
I keep hearing this argument, that the packages for the involved drivers can be made to conflict with the update. Which in essence will deprive all but the most technical of our users from security updates. So this is a moot argument. ? Deprive all but the most technical of our users from security updates is almost as bad as completly breaking their system.
So you'd rather we hold the update for EVERYBODY so that EVERYBODY gets denied the update? yeah, that's progress...
If I extend your idea, FC-5 should exactly the same as FC-devel. A major release of FC should avoid breaking things. The ABI-breaking updates should be reserved for FC-devel and next major release (in that case FC-6).
I agree that it shouldn't break things but only those the developers have control of.
Anyway, since X is of very importance for people, I think Fedora should bend the rules for the moment. I can imagine how much disruption it will cause for beginners to inadvertently update to xorg 7.1 and have X crashes.
Doing major update for release products is the very advantage Fedora has over other distributions. I hope it continues to do so.
On Friday 28 July 2006 18:19, Leon wrote:
Doing major update for release products is the very advantage Fedora has over other distributions. I hope it continues to do so.
I agree. That's also why I chose Fedora.
But I would be nice if those major upgrade do not break thing as important as X11 (tainted-)servers.
Yesterday I came to work to discover John Williams music blaring from the cubicle next door. I pushed the door open and saw a Superman screensaver running on a Windows machine with spinning "S"es from the various incarnations of the Kryptonian hero. Turned out my officemate had left his headphones unplugged, so the rest of us got a free concert.
Last night I had a number of long running jobs on my mac mini, and I got to thinking of what a pain it was to understand the status of the machine. I was processing mail, washing dishes and doing other domestic tasks while checking in on the status of the process of copying files from a DVD-ROM to an NAS storage unit over the wireless internet connection, a process that takes about an hour.
It was annoying as hell that the progress indicator was this tiny little box that easily got lost in all the other windows that were open.
It got me thinking... We're starting to see that the WIMP interface was a step backwards in many ways, and we're moving towards more task-oriented interfaces.
Why can't we make a screensaver that's useful? The idea is to make a screensaver that works like the dashboard in Mac OS X... Something task-oriented that lets you get an immediate sense of what your machine is up to. (Just walk up to the computer and you can see at a glance)
The big thing you'd need for this is some kind of hook into the progress bar mechanisms that would let the screensaver display progress bars for running applications: this could be a big selling point for Gnome and KDE apps if they had their progress bars implemented into this. (Doing this in general would be tough... How would you get progress information out of Azureus? Such a scheme would need to be supplemented with a "top"-like display, network traffic monitoring, maybe even something like lsof, to be able to say something about applications that aren't smart about reporting status...
Paul A. Houle Digital Library Programmer/Analyst Library Systems Olin Library 503 (607) 539-7490
Hi Hans,
I'm seriously considering switching distro's after the AIGLX and target audience discussion. I cannot believe how arrogant most of the replies are, saying that if user install any third party software that then that thirdparty software is their problem.
I'm not siding with anyone here and have kept quiet for most of the AIGLX discussion, but I feel I must speak here.
When I was much wetter behind the ears, I used to use the nVidia binary driver. It would annoy the hell out of the other half as everytime I did a kernel upgrade, bang went X, though she didn't mind being able to play the 3D games.
Due to only running rawhide, I use the xorg driver, the other half uses an Intel card machine so 3D is still okay without any brain dead binary only driver.
What is my point? When I used to go onto various forums and explain the problem, replies came mainly in as "what do you expect? if you use a binary only driver things break as it will rely on a very specific set of code - you thick or something?"; in other words, if you use something which is binary only, on your own head be it. I found that sort of response (as a newbie) as much good as a chocolate toaster!
I also find this very hypocrite because normally when any chance breaking thirdparty software is proposed for inclusion into the current release people start screaming loudly. Like for example any suggestions to introduce an update to Extras with an soname chance. But since the thirdparty software breaking in this case is non OSS and since some very LOUD people happen to dislike the thirdparty software breaking in this case, they are all of of a sudden in favor of breaking thirdparty software during a what is supposed to be stable release?
People like stable systems. They should be using FC-5 and not the developmental versions. We know the risks when we install. If they want to be really dumb, they should be pointed in the direction of Debian (and I refer here to the speed at which they release stable versions).
I have always seen FC and FC-rawhide as a testing bed which moves Linux forward at sometimes a breakneck speed which is why it's now such a major threat to the closed software community. If a change needs to be made (as was the case moving to xorg.7) which breaks the likes of the nVidia drivers in either core or extras, that's a problem for nVidia - not for us. If users don't like it, so what.
I'm just totally stunned by the arrogance in this discussion, the I'm holier then thou stance. And most of all the total disregards to the many end users who happen to rely on the thirdparty software in case.
Again - depends on the third party software. I'm not bothered on video drivers, but some apps need compat-c++ libs. Some people (and I know this is the case as my sister uses some) use software so long in the tooth that they can *only* run something around RH8. A point has to be decided on after which you cannot justifiably offer support. I think that this is where a lot of the derision is.
I'm seriously starting to think that Fedora is not the distro for me to be working on and switching to Ubuntu (by lack of a better alternative), now some of the arrogant screamers may say fine, we won't miss you but before saying so I would first take a look at owners.list in FE cvs and than think again.
Please. No. We want you and need you here.
This is not meant as some kinda blackmail to stop the Xorg 7.1 update, to be honest at this point I don't care about the 7.1 update anymore. And as I said when I started the target audience discussion this was never about the 7.1 update. Its about the principle of not knowingly having a yum update during a stable release breaks peoples systems, especially not with a smile on your face and saying behind those end users backs that will teach them not to use binary crap. Because that _IS_ what is happening here. Sure there are many advancements in xorg 7.1 and I'm not suggesting to leave it out FC-6 even if the binary drivers aren't available at FC-6 launch time, but breaking stuff with TOTAL disregard to a large group of end users, during a stable's release lifetime is IMHO unacceptable.
You can always WARN people that the update is likely to break binary drivers and if they're unsure, just don't apply the xorg updates (it can be made to be one of the "protected" parts so yum doesn't update it).
And what worries me is not this single instance of breaking, its the attitude behind it and the ease with which we (you?) step over the all of a sudden minor problem of seriously hurting a significant group of end users.
All I can say is remember FC1 and 3 and how much they broke. Remember the problems with RH9 (especially if you were on <=8 at the time).
I agree Hans. We can't break things willy-nilly. Then again, we can't take the attitude that we don't release because it breaks a binary only driver.
Perhaps the key is closer working with the likes of ATI and nVidia so they can get the correct drivers out in time (nVidia were really bad when we moved to xorg).
TTFN
Paul
Hans de Goede j.w.r.degoede@hhs.nl writes:
Hi all,
I'm seriously considering switching distro's after the AIGLX and target audience discussion. I cannot believe how arrogant most of the replies are, saying that if user install any third party software that then that thirdparty software is their problem.
If you look at the update of xorg 7.1 as an option for you to upgrade when nVidia is ready while you can be happy with xorg 7.0 meanwhile. No other distros provide this flexibility. I have been using Ubuntu for half a year before moving to FC5. In Ubuntu you will stay with no major updates and I don't think this is good for desktop users.
On Fri, Jul 28, 2006 at 09:12:52AM +0200, Hans de Goede wrote:
Hi all,
I'm seriously considering switching distro's after the AIGLX and target audience discussion. I cannot believe how arrogant most of the replies are, saying that if user install any third party software that then that thirdparty software is their problem.
I also find this very hypocrite because normally when any chance breaking thirdparty software is proposed for inclusion into the current release people start screaming loudly. Like for example any suggestions to introduce an update to Extras with an soname chance. But since the thirdparty software breaking in this case is non OSS and since some very LOUD people happen to dislike the thirdparty software breaking in this case, they are all of of a sudden in favor of breaking thirdparty software during a what is supposed to be stable release?
The release *is* stable when it works with all of the software distributed. 3rd party drivers are not distributed, but it is at least known that there may be problems and an admin or user can take appropriate steps. That said it probably would be helpful to make sure end-users are aware of issues like that.
Fedora *is* designed as a testbed, but that is not *all* of Fedora. There is no reason you cannot still use older fedora releases for your users (thanks FedoraLegacy!). Yes its great to get the bleeding edge tools, but sometimes its necessary to be conservative and continue on an older release until issues that concern you are addressed in a newer release. To me this is part of the fun of using Fedora. We are all trying to see what works, what doesn't, submit bug, keep the community moving. Its also nice to know that the legacy project keeps us safe if we cannot immediately upgrade. There *are* choices within Fedora. Its good that you are keeping track of what works and does not, and you can remain on FC3/4 until you feel comfortable and can move. Others blaze ahead and run stuff right out of the development tree. that kinda illustrates part of the fedora audience.
w
On Fri, 28 Jul 2006 09:12:52 +0200, Hans de Goede j.w.r.degoede@hhs.nl wrote:
I'm seriously considering switching distro's after the AIGLX and target audience discussion. I cannot believe how arrogant most of the replies are, saying that if user install any third party software that then that thirdparty software is their problem.
What does this drama have to do with fedora-DEVEL-list? This seems like a topic better suited for your LiveJournal.
Also, blackmail will get you nowhere. Firstly, people do not like being blackmailed. If they cave to your demands, it creates an incentive for you to throw tantrums again. Eventually, once your demands really cross the line, you'll be denied and then you'll have to leave. So, once you start on that path, it's only a matter of time. And secondly, your weight is just not sufficient to cause any damage should your bluff be called. If Togami, Zeuten, or Katz threatened to collect their toys and exit the sandbox, then someone might possibly notice. De Goede or Zaitcev doing the same is hardly a front page material. It's just laughable.
-- Pete
Hi Hans, before you decide to leave, I think you should filter the lists of replies so you only see what Nicolas Mailhot has said. He sums up what Fedora is and how a distribution by and for open-source developers can be enhanced for end-users with cool reasoning.
As to the rest of the arguments, it really boils down to this: there are many end users of Fedora products. Some want to try the latest and greatest without having to roll their own distribution, others want to run a commodity operating system that is free, and still others have been talked into it because they're timesharing the computer with someone else that's more gung-ho about open source. These are all audiences of Fedora but none of them are the target audience.
Fedora is a project whose goal is to make a product: The very best open source operating system that money can't buy.
Since it is the "very best" naturally everyone is a potential satisfied user of the OS. However, we have never defined (or limited) our distribution by the users we are trying to satisfy, rather we are striving to create something that exemplifies the state of the art in open source. Something that (since we contribute our changes into the upstream projects) pushes the state of the art one step beyond where it was before.
Inherent in defining Fedora as an "open source operating system" is the idea of evolutionary growth. Unlike other software methodologies (Commercial games come to mind where you buy Warcraft, Warcraft II, and Warcraft the Last Battle[Before the Sequel]) open source sees products grow and change in capability and character over time. Evolutionary growth requires two things: coding and usage (analogous to mutation and survival of the fittest). When a change such as the Xorg release comes up, someone has already done most of the coding. We can do some more if there are out of tree open source drivers that need updating. Then we have to release it into the distribution so it can be run over by tons of users who can enjoy the new drivers and find bugs that need to be ironed out. Releasing Xorg for FC5 is philosophically and technically important to Fedora because it helps to improve the _quality_ of _open-source_.
Does it hurt end-user's perception of open-source and Fedora? Read on.
For end-users committed to or satisfied by the open source solutions, evolutionary change means a gradual ramping up of capabilities. Xorg supported my video card only through VESA when FC5 released. I have an accelerated 2D driver now and hope to have accelerated 3D once 7.1 hits the shelves. All this progress without having to change distros (including Core releases) or break my system! For people in like situations, the perception of open source is of gathering momentum and the fruiting of its potential.
For end-users who need to run proprietary software, the road can be harder. Some pieces of software continue to run through upgrade after upgrade with no changes. Those programs which require a kernel module or X.org driver have a rougher time as they have to access the internal ABI of these in order to function. An upgrade that changes something internally can cause these modules to fail and there's nothing we can do about it -- only the owner of the proprietary code can fix the issue. A good vendor must adopt the methodology of the upstream project they're targetting. ATI, Nvidia, and others follow the development of Windows in order to make sure their drivers run when the next version of Windows comes out. Until they follow the development of X.org in the same fashion, accepting and anticipating the inevitability of X.org upgrades, they are going to leave users dangling when a distro upgrades.
Is all lost? If you still want to run Fedora Core on machines where you have to run proprietary drivers so you can stay with familiar tools, keep contributing to a project that respects your work (and for at least some of us, your thoughts as well), and have a choice of running the latest and greatest open source on some machines and somewhat more stable code on others, I think you should consider running something that has been moved into maintenence mode. Fedora Legacy works to maintain the security of its releases without upgrading for features. If you keep the machines where this is an issue on a Fedora Legacy release that just trails the non-maintenance Fedora Core releases you can still get new software on ~6 month intervals (rather than the glacial pace of Debian stable) while enjoying a much more stable platform for running proprietary drivers.
If this works well, you can start a project to inform end-users of this three tiered approach: Rawhide to develop the OS. The latest Fedora Core for those who want to run the latest software on a stable operating system, and slightly older Fedora Cores maintained by Fedora Legacy for those who just want things to continue working with occasional security enhancements.
-Toshio
An interesting editorial on this topic, that might sum up some of the feelings that some people have been feeling:
http://www.freesoftwaremagazine.com/articles/editorial_13
Slashdot discussion on this: http://linux.slashdot.org/article.pl?sid=06/08/02/0238233 Digg discussion: http://digg.com/linux_unix/Why_Red_Hat_will_go_bust_because_of_Ubuntu
All of this isn't necessarily to be taken as gospel, however it does illustrate well the point some of 'us' have been trying to make .. lets not forget about the users! :-)
-- Chris Chabot
On Wed, 02 Aug 2006 18:10:04 +0200 Chris Chabot chabotc@xs4all.nl wrote:
An interesting editorial on this topic, that might sum up some of the feelings that some people have been feeling:
http://www.freesoftwaremagazine.com/articles/editorial_13
Slashdot discussion on this: http://linux.slashdot.org/article.pl?sid=06/08/02/0238233 Digg discussion: http://digg.com/linux_unix/Why_Red_Hat_will_go_bust_because_of_Ubuntu
All of this isn't necessarily to be taken as gospel, however it does illustrate well the point some of 'us' have been trying to make .. lets not forget about the users! :-)
Agreed, let us not forget about the open source users. Let's not let the people who want to use binary-only proprietary extension spoil the distribution for those that don't. On top of which, the first article you cite seems to indicate that the niche you're worried about is already nicely filled by Ubuntu. There doesn't seem to be much reason for Fedora to become just another Ubuntu.
Sean
Chris Chabot chabotc@xs4all.nl wrote:
An interesting editorial on this topic, that might sum up some of the feelings that some people have been feeling:
That editorial, without further context, has net negative information content.
You can basically sum it up as "Ubuntu RuleZ! Red Hat Sux0rs!"; it's a pure Appeal to Emotion, which I guess is why you say it relates to "the feelings that some people have been feeling." You might as well quote song lyrics or a poem.
If there are specific, technical, differences between Fedora Core and Ubuntu where there is an argument that the Ubuntu way is preferable according to some set of criteria, then please bring those issues up (that's not a snide comment, I would really like to know).
To avoid confusing the issue, and allow each point to be evaluated on its merits, I would suggest posting one thread for each distinct topic.
Note that if the difference in question cannot be resolved with a patch, then its discussion probably belongs on a different list.
On Fri, 2006-08-04 at 10:50 +0200, Terje Bless wrote:
Chris Chabot chabotc@xs4all.nl wrote:
That editorial, without further context, has net negative information content.
You can basically sum it up as "Ubuntu RuleZ! Red Hat Sux0rs!"; it's a pure Appeal to Emotion, which I guess is why you say it relates to "the feelings that some people have been feeling." You might as well quote song lyrics or a poem.
It's about winning hearts and minds though. Articles like that one convey no useful information whatsoever - but it's an editorial so it's going to have a bias behind it - except perhaps for the fact that there are a lot of people who are very excited about Ubuntu. I'll bet a lot of those same people were very excited about Red Hat Linux back in the day.
I used to use Ubuntu and Debian a lot more before I worked at Red Hat. Yes, they're good distros, but Fedora is a damn fine piece of work too and powered by a lot of very committed people. The problem is that we could do with a few others to get zealoty and enthusiastic about Fedora Core in the same way that they (recently) get so jumpy about Ubuntu. We shouldn't ignore articles like that because they have a tendency to help perpetuate various silly arguments next time someone writes a story.
It's not always plain sailing with Ubuntu either. It took 1.5 days to install and configure Dapper on my Powerbook[0] so that I could use it as a desktop machine. Suspend didn't work because they'd patched their kernel with some broken patches, Bluetooth took ages to get working right, I had to manually configure the power management, lots of desktop annoyances out of the box, etc. By contrast, Fedora Core did actually install cleanly before I upgraded it to Rawhide. Yes it had things I fiddled with, but the experience was much better /in this case/.
We all use the same upstream sources (plus a few patches) and everyone is trying to reduce the numbers of patches that need to be applied, so it stands to reason that as upstream evolves, so too will both Fedora and Ubuntu. Yes, we'll have differences and annoyances in both but people will still write articles like the above in any case. We need to help convince them that Fedora is a great Linux distribution too so that they start to criticize it for technical reasons, not ideological ones.
Jon.
[0] I mailed Mark and several others about it and I am sure the points have been addressed by now in Eft. I'll take a look when I get time.
Jon Masters wrote:
By contrast, Fedora Core did actually install cleanly before I upgraded it to Rawhide. Yes it had things I fiddled with, but the experience was much better /in this case/.
IMHO opinion, its these things you and I, and probably all we fiddle with in which a huge improvements can be made. We should post a list of all our little tweaks somewhere (wiki?), and then extract tweaks which will be benefitial to not only the person doing the tweak but to a wider audience and then integrate the tweak into FE (and hopefully also upstream).
Regards,
Hans
On Fri, Aug 04, 2006 at 02:15:02PM +0200, Hans de Goede wrote:
Jon Masters wrote:
By contrast, Fedora Core did actually install cleanly before I upgraded it to Rawhide. Yes it had things I fiddled with, but the experience was much better /in this case/.
IMHO opinion, its these things you and I, and probably all we fiddle with in which a huge improvements can be made. We should post a list of all our little tweaks somewhere (wiki?), and then extract tweaks which will be benefitial to not only the person doing the tweak but to a wider audience and then integrate the tweak into FE (and hopefully also upstream).
Regards,
Hans
A very good point. IMO
-
Adam Jackson -
Alan -
Alan Cox -
Arjan van de Ven -
Bruno Wolff III -
Chris Chabot -
David Nielsen -
edwardsa -
Erwin Rol -
Florian La Roche -
Hans de Goede -
Horst H. von Brand -
Jeremy Sanders -
Jesse Keating -
Jon Masters -
José Abílio Matos -
Kevin Kofler -
Konstantin Ryabitsev -
Krzysztof Halasa -
Laurent Rineau -
Leo -
Leszek Matok -
n0dalus -
Nicolas Mailhot -
Otto Rey -
Paul A Houle -
Paul F. Johnson -
Pete Zaitcev -
Ralf Corsepius -
Sean -
Terje Bless -
Thomas M Steenholdt -
Toshio Kuratomi -
Vikram Goyal -
Wesley Harrell