Hi!
This will be a bit long, so if you don't have anything better to do, please bear with me.
Since the days of Red Hat Linux 5.0, when I started using Linux, I have followed a ritual with every new release. The ritual consists in looking around for stuff that used to work and is now broken. Fortunately, the server related stuff seems to be immune to obvious regressions, but that cannot be said of desktop related stuff. Some of these regressions are easy to fix (and I sometimes fix them myself) but the fixes have to wait for the next release, where other regressions pop up... This is a never ending cycle.
In the days of Red Hat Linux, the situation was much worse, since the only updates that appeared were security fixes (which are good), bug fix updates were as rare as water in the desert. But today we are no much better.
So, what I'm saying is that there should be a more agressive update policy to Fedora Core, new packages should go into updates-testing and then updates except if there is a good reason not to. Let's have gaim as an example, it is a piece of software with many shortcomings and which gets better with every release. It's also a non intrusive package, and so the new gaim that pops up in updates every couple of weeks is a welcomed update. However, there is a nut package in "development" that fixes some configuration file ownership stuff that stays there, although it has no other change from the version in FC2.
Stuff should never go into "development" unless there is a strong reason, meaning "it breaks other packages", "it requires tons of dependency updates, some of which possibly beaking other packages" or "it changes basic stuff in the distro, like how initialization is done, security is handled". FC2 should have a more evolutionary approach, stuff like mozilla-1.7 should go directly into updates-testing. New FC releases should mean big stuff like SELinux, kernel 2.6 and the likes, meanwhile FC should be as close to development as possible (without that big stuff).
Basically I'm saying that FC should be "development" without the dangerous suff. After all this is a distro for hobbyists which like to be as close to the bleeding-edge as possible, without actually bleeding.
Why do I say this? Because I feel that once a release is out, almost everybody moves its attention onto the next one and forgets about us folks. FC should not be the absolute bleeding edge, but it shouldn't also be RHEL... evolution is needed. This would allow to squash bugs earlier, meaning getting to a stable desktop (as in not crashing or buggy, not feature-frozen) faster.
I'm kind of sick of being between a rock and a hard place, either I use a bleeding-edge distro and spend all my time bleeding or I use a over conservative distro and never get new features... Am I totally clueless?
Well, to be true, the same thing that I say above can be accomplished by turning "updates-testing" into some sort of half-way between FC and "development", more dynamic but not as risky.
Carlos Rodrigues
PS: I was prompted into this because in FC2 smb with GNOME is totally broken (amongst other things), and even if a GNOME 2.6.2 gets out I know that it will never come out, FC3 will bring 2.8 and new stuff will break. It's actually funny (in a bad way) that GNOME gets released as frequently as FC, which means we always get a .0 release and not the following bug fixes... damn!
Carlos,
Could you expand on what you mean by GNOME in FC2 SMB being totally broken? Symptoms, etc.? I'm interested because that is my impression as well. I haven't posted much about that here (avoiding troll branding), but I would like to know what you are encountering. Maybe we can fix some of them together.
Some of the issues I have with GNOME seem to have been there in FC1 as well.
Just curious. Thanks.
Steve Brenneis http://myorb.sourceforge.net
On Mon, 2004-07-26 at 19:58, Carlos Rodrigues wrote:
Hi!
This will be a bit long, so if you don't have anything better to do, please bear with me.
Since the days of Red Hat Linux 5.0, when I started using Linux, I have followed a ritual with every new release. The ritual consists in looking around for stuff that used to work and is now broken. Fortunately, the server related stuff seems to be immune to obvious regressions, but that cannot be said of desktop related stuff. Some of these regressions are easy to fix (and I sometimes fix them myself) but the fixes have to wait for the next release, where other regressions pop up... This is a never ending cycle.
In the days of Red Hat Linux, the situation was much worse, since the only updates that appeared were security fixes (which are good), bug fix updates were as rare as water in the desert. But today we are no much better.
So, what I'm saying is that there should be a more agressive update policy to Fedora Core, new packages should go into updates-testing and then updates except if there is a good reason not to. Let's have gaim as an example, it is a piece of software with many shortcomings and which gets better with every release. It's also a non intrusive package, and so the new gaim that pops up in updates every couple of weeks is a welcomed update. However, there is a nut package in "development" that fixes some configuration file ownership stuff that stays there, although it has no other change from the version in FC2.
Stuff should never go into "development" unless there is a strong reason, meaning "it breaks other packages", "it requires tons of dependency updates, some of which possibly beaking other packages" or "it changes basic stuff in the distro, like how initialization is done, security is handled". FC2 should have a more evolutionary approach, stuff like mozilla-1.7 should go directly into updates-testing. New FC releases should mean big stuff like SELinux, kernel 2.6 and the likes, meanwhile FC should be as close to development as possible (without that big stuff).
Basically I'm saying that FC should be "development" without the dangerous suff. After all this is a distro for hobbyists which like to be as close to the bleeding-edge as possible, without actually bleeding.
Why do I say this? Because I feel that once a release is out, almost everybody moves its attention onto the next one and forgets about us folks. FC should not be the absolute bleeding edge, but it shouldn't also be RHEL... evolution is needed. This would allow to squash bugs earlier, meaning getting to a stable desktop (as in not crashing or buggy, not feature-frozen) faster.
I'm kind of sick of being between a rock and a hard place, either I use a bleeding-edge distro and spend all my time bleeding or I use a over conservative distro and never get new features... Am I totally clueless?
Well, to be true, the same thing that I say above can be accomplished by turning "updates-testing" into some sort of half-way between FC and "development", more dynamic but not as risky.
Carlos Rodrigues
PS: I was prompted into this because in FC2 smb with GNOME is totally broken (amongst other things), and even if a GNOME 2.6.2 gets out I know that it will never come out, FC3 will bring 2.8 and new stuff will break. It's actually funny (in a bad way) that GNOME gets released as frequently as FC, which means we always get a .0 release and not the following bug fixes... damn!
On Mon, Jul 26, 2004 at 08:42:09PM -0400, Steve Brenneis wrote:
Could you expand on what you mean by GNOME in FC2 SMB being totally broken? Symptoms, etc.? I'm interested because that is my impression as well. I haven't posted much about that here (avoiding troll branding), but I would like to know what you are encountering. Maybe we can fix some of them together.
The default firewall blocks responses to SMB queries. In fact, the firewall by default doesn't work for any broadcast or multicast based protocols. If you stop the iptables service or enter custom iptables rules SMB browsing should work fine in FC2 GNOME. See:
Charles R. Anderson wrote:
The default firewall blocks responses to SMB queries. In fact, the firewall by default doesn't work for any broadcast or multicast based protocols. If you stop the iptables service or enter custom iptables rules SMB browsing should work fine in FC2 GNOME. See:
That doesn't work for me, I do not have any firewall rules configured. At home iptables are stopped on my FC2 box, Windows XP has no firewall enabled on my sister's machine and my Red Hat 8.0 gateway/server (which does have a firewall) had no configuration changes (and it worked while my box had FC1 -- which it still has on another partition).
Carlos
Steve Brenneis wrote:
Carlos,
Could you expand on what you mean by GNOME in FC2 SMB being totally broken? Symptoms, etc.? I'm interested because that is my impression as well. I haven't posted much about that here (avoiding troll branding), but I would like to know what you are encountering. Maybe we can fix some of them together.
Some of the issues I have with GNOME seem to have been there in FC1 as well.
Just curious. Thanks.
In FC1 the smb support in nautilus actually worked quite well for me, at least at home (one Windows XP, one FC1 and one Red Hat 8.0). At work it could never browse the network, it always complained about the master browser (but I could access shares by address) which I could never quite debug since the network is filled with w2k, w98, w2k3 and samba shares and my machine is connected to two different networks... (this doesn't speak well for smb support in nautilus, but it was kind of experimental back then anyway...).
In FC2 the network browser shows nothing, and if I use the machine name directly I'm asked for a password even for completely public shares (eg. on the RedHat 8.0 machine). If I'm lucky I can use the share after this, but more often than not nautilus just crashes. The samba tools seem to work fine however.
There are a couple of bugs filed about these problems, both to Red Hat's and GNOME's bugzilla:
https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=122292 http://bugzilla.gnome.org/show_bug.cgi?id=148295 http://bugzilla.gnome.org/show_bug.cgi?id=147204 http://bugzilla.gnome.org/show_bug.cgi?id=129890
Carlos Rodrigues
PS: actually I wasn't quite fair when bringing this problem up in the context of my last post because it isn't fixed upstream yet. However I think is just the kind of problem that gets "FIXED RAWHIDE" instead of "FIXED ERRATA" when upstream does fix it.
I would love to see some of your suggestions implemented. I was thinking the same thing just yesterday. I dont know if it would ease or trouble the developent of the next FC but i like the idea of a distribution that incorporates the newer "addon" packages and stabalizes the core desktop environment (a sane technology testing platform if you will). I thought this was the charter of FC to begin with. Is it simply too time consuming to do this from redhats end (completely understandable if so)? --Michael
On Tue, Jul 27, 2004 at 12:11:25PM -0500, Michael Favia wrote:
I would love to see some of your suggestions implemented. I was thinking the same thing just yesterday. I dont know if it would ease or trouble the developent of the next FC but i like the idea of a distribution that incorporates the newer "addon" packages and stabalizes the core desktop environment (a sane technology testing platform if you will). I thought this was the charter of FC to begin with. Is it simply too time consuming to do this from redhats end (completely understandable if so)?
That's my understanding on where we want to go and I hope we make good progress with this. FC1 has been very solid in my opinion. FC2 has kind of rough corners with the big step to a 2.6 kernel and the starting point to update many user level rpms plus really adding into a solid desktop. Current FC3 looks nice to me, but I might be the wrong person to ask this. (I tend to like all development trees.;-)
For your above comments: I'd wish system-config-packages plus some other tools would be more connected and working better together. I am not sure all that can be cleaned up within FC3 development timeframe. It's a huge area to work on. The new repository support just going into the Fedora development tree are again bits of this.
greetings,
Florian La Roche