What Fedora makes sucking for me - or why I am NOT Fedora

[Pavel Shevchuk]

I agree to most of the letter, especially python daemons stuff and
plymouth, but do you know any better OS/distro? I've tried many and
fedora is one of the best things around, unless you want to spend all
your spare time maintaining custom LFS system.

On Tue, Dec 9, 2008 at 2:25 AM, Robert Scheck <robert at fedoraproject.org> wrote:
> Good evening everybody,
>
> I've unluckily several points and issues, I'm trying to get solved for even
> for a longer time now (depending on the point on my list), but nobody in
> and around the Fedora Project seems or don't want to care about that. I am
> also annoyed, that I have to write such an e-mail, but the following really
> is, what Fedora makes sucking for me.
>
> Ah, and now first of all to the guys who will surely answer "use Ubuntu",
> "choose another distribution", "you're sucking as well" or similar: Go, run
> and die in a fire - immediately! I know, that this e-mail will make me the
> bogeyman for many of you, but that hopefully and luckily moves out Thorsten
> for a short time of his usual position while taking the seat myself... ;-)
>
> Well, we had the intrusion into the servers of the Fedora Project. That is
> now nearly 4 months ago. I remember to the words of our dear Fedora Project
> leader, who made us believing with the sentence "We will continue to keep
> the Fedora community notified of any updates." - but nothing happend after
> that. We all are still waiting for final report about the intrusion into
> the servers of the Fedora Project! Yes, we can: Open Source, but unluckily
> no Open Communication! Even the communication during the intrusion time was
> worse, e-mails to the Infrastructure team and to our Fedora Project leader
> got not really answered (or just when reasking and bugging) when asking for
> the issue and details even when it was mostly clear, that we're no longer
> really men about ourself - the intrusion.
>
> Our German translation is only quantitative, not qualitative. And the worse
> thing is, the team leader of the German translation team finds the current
> position and its current status okay. That's wrong and never should happen.
> If a German person is not able to understand the context of a translated
> sentence, the phrase should not be commited. Many people are even not re-
> reading the tsentence whether it has any meaning after the translation. But
> our team leader says, quantitative translation is okay. Ugly grammar and
> spelling issues are another thing; seems too much to re-read or to use a
> spellchecker before commiting - our teamleader says, that everything must
> fast go to upstream...great! I now know lots of German speaking people (in
> their mother tongue), which use Fedora only in English - including myself -
> to avoid the must of reading that horrible German. Surely, we can fix that,
> but if always people are working against, that does not help. Unluckily,
> language translations don't make it that often into Fedora updates during
> the lifetime of a Fedora release. So mostly, a broken translation is kept
> there for the whole release. But it's okay to be only quantitative and not
> qualitative, our team leader of the German translation project prays.
>
> Oh, we've the Live CD for a long time now. Did anybody use that medium on a
> slower, older computer? Surely not. Otherwise you would have noticed, that
> the Live CD is very slow there. The USB stick/variant may be fast, but the
> CD which we're now promoting at our download page better and more that the
> installation DVD, is IMHO not a good store sign as it is just slow. It even
> has not a localisation - folks, not the whole world is speaking english,
> just there is America on the worldmap! I know people from fairs, which are
> really frusted by their first try with a Live CD as it was just English.
> Yes, we maybe can create a spin, but these ones, we cannot offer on the FTP
> and HTTP mirrors, because Fedora is already too big. On the other hand, the
> issue of a non-US keyboard layout when trying to generate a localized
> version of the Live medium is still not fixed. There were some tries to
> solve that on LinuxTag 2008, but as far as I know, afterwards nobody again
> cared about and it went down. Remembering, that promoting our so cool Live
> CDs does not help in areas where the Internet is slow and old, I'm doing
> hereby, too. I don't want to remember, that the Fedora 8 Live media even
> killed crypted swap partitions...really a nice feature. By the way, does it
> do that still?
>
> Yeah, Anaconda got a bigger rewrite for Fedora 10 and took care of the old
> and often claimed issue, that the user needs to know the URL of a mirror in
> order to install Fedora via netinstall. But now, the screen got completely
> ripped out or is (if it really still exists, which I don't believe) too
> good hidden somewhere. Instead of that, somebody - that must have been an
> American - made the "repo=" option for the command line prompt if somebody
> wants to specify a local mirror. Urgs! At that point, no non-US keyboard
> layout is loaded! I now have to type something like "repoßhttpö--my.local-
> mirror-fedora-something-" or so on my non-US keyboard. Folks, the worldmap
> not only has American people with a US keyboard layout out there, even if
> some people think so. Even the "repo=xxx" is worse documented, but yes, who
> cares? Just me as it seems somehow...
>
> In order to support the RPM Fusion (former Livna) project, I tried to
> install the mirrormanager serverlist on a RHEL 4 with python 2.3 and having
> suexec in httpd enabled - and poorly failed. Mirrormanager is worse up to
> not documented at all and only focussed to RHEL 5+. So for a not really
> mirrormanager specific person it is nearly impossible to run mirrormanager
> serverlist in a secured/hardend environment out of the box without taking
> much action. Luckily I got support for several python 2.3 specific issues
> by a mirror admin and by the webteam leader - unluckily not so much help by
> the developer of mirrormanager who caused the stuff...I'm still getting a
> zombie process after a request by the *.wsgi which is surely no feature.
>
> Pushing packages into Fedora still takes ages in form of days or weeks. And
> this unluckily and especially also for security updates. The reason for
> this seems to be Bodhi, as the updates are usually happening very fast on
> EPEL which hasn't Bodhi. For EPEL it normally just takes hours, for Fedora
> mostly multiple days up to a week. I know, what I'm talking about here, I
> am co-maintaining phpMyAdmin which has more holes that a swiss cheese; the
> EPEL people know very well, what I'm talking about, too. I also had a lot
> of other security updates for other packages during 2008 and EPEL is always
> faster there, why Fedora is so slow? There must be a real reason, why we do
> not get rid of this for a long time now...and I would like to see this same
> good or even well in Fedora as in EPEL - or do we have to kill bodhi first?
>
> Hmmm, the "Merge Reviews" that somewhere have been declared as blockers
> for Fedora 7 (!) are still not done. It AFAIK was said somewhen, that not
> reviewed packages are getting removed from Fedora. This did not happen for
> anything, yet. The "Merge Reviews" are sometimes also blocked by Red Hat
> employees for very base/core packages by just refusing the Fedora Packaging
> guidelines, because it's the packager of the package. This can't be case!
> The Red Hat people have to follow the Fedora packaging guidelines and rules
> same as the Fedora folks - without any exception! If you would like to know
> which packages and people I'm talking about, have a look to Bugzilla and
> search for the bug reports I'm watching via Cc - there are lots of examples
> out there...without wanting to blame somebody special here on the list. But
> this has to be solved, the reviews need to be done, and the Red Hat people
> sitting on some base/core packages, must follow the Fedora rules same and
> without any refusing as they currently do. BTW, why is nobody controlling
> the success of the "Merge Reviews"? Shouldn't somebody watch this and tell
> us all the progress inside of e.g. the weekly Fedora newsletter or so?
>
> Oh, did I mention, that RPM 4.6, our dear big change in RPM at Fedora for
> years now is still buggy and so? When reading the article about a review of
> Fedora 10 by pro-linux.de (http://www.pro-linux.de/berichte/fedora10.html),
> I had to notice, that our dear rpm.org developers still did not get rid of
> the "hanging rpm" now must be solved by killing the RPM processes, removing
> the /var/lib/rpm/__* and rebuilding the rpmdb. Putting the (now cheap) oil
> into the fire would be a solution: rpm5.org solved the above mentioned very
> annoying issue already years ago. But yes I know, some yum developing and
> supporting individuals don't like the rpm5.org project by other individuals
> even not honoring their work, but even not backporting the fixes, developed
> there to solve old problems. I don't know of any "feature" in rpm.org, that
> is not already in rpm5.org; why do we put double efforts with so much delay
> in rpm.org when rpm5.org already has done the work? And before I know hear
> some derogatives about rpm5.org people: You're always getting the echo for
> what you did, but unluckily you often do not always remember to what you
> did or say before - and that AFAIK applies to all rpm5.org people related
> personal issues. And if we are now RPM; are there advantages of having some
> kinds of an APT API?
>
> PackageKit, another broken software which is in a pre-bleeding edge state I
> would say. PackageKit is resizing windows during installation or updating
> of packages; it's resizing and thus hopping the window if I e.g. select a
> package or if I click around inside of the application. That's something,
> which proves, that there is no usability for end users yet. That's IMHO
> more worse than alpha - but we're shipping it with releases, yay. And the
> related GNOME tray utility is also slow and usually is behind the current
> action...that's packagekitd, yes? One of these utilities also often blocks
> the usage of yum with saying, that another application currently holds the
> lock. Why are we locking something when not performing a writing action on
> the RPM database? That seems to be mis-engineered very well. Independent of
> that, PackageKit is somehow slow, has issues that it doesn't understand
> always where it is or whether an action is already completed. Oh and it
> kills my Firefox nicely during package updating, well-well done. Some more
> experiences about the broken-ness are mentioned in the review of Fedora 10
> on pro-linux.de (http://www.pro-linux.de/berichte/fedora10.html). Why do we
> ship such software? Only because we're bleeding edge and want to beat the
> guys of Ubuntu?
>
> When talking about PackageKit, DBUS is another issue. The recent DBUS pkg
> update broke PackageKit stuff - thanks to our cool QA. And clever as we
> are, we did not revoke the update and we also did not push a fixed package
> really immediately out after to solve this. I know, that many of the
> desktop people actually love DBUS, but it is horrible stuff, which can
> break down much things with lacking QA like in this case. Did you desktop
> people ever think about, that DBUS is not the perfect choice for a server
> system and Fedora is some kind of preview of RHEL? Yes, Fedora is not the
> playground of Red Hat, but on the other hand, Fedora is - why else is Red
> Hat putting efforts into Fedora if they wouldn't benefit? I really can only
> hope here, that Red Hat removes much of the DBUS breakage and dumbness for
> the next RHEL release and that less DBUS linked packages are making it into
> there...
>
> And as we're cool, we need a daemon for everything: packagekitd, dbusd, hal
> daemon, mcstransd, setroubleshootd, yum-updatesd - yay. And nearly every of
> this daemons is written in the memory consuming python and has nice memory
> leaks or other breakdown bugs. mcstransd is still slower for me (even after
> the speedup somebody of the SELinux guys did) as previous implementation
> without the daemon. But yes, we need daemons; restorecond would now be just
> another example. I think, there's much more which can be solved without a
> daemon and at least without memory-wasting worse written python. I'm aware,
> that python is the Red Hat internal defacto default and that scripting is
> much more faster rather coding low-level C. But lets waste ressources as
> e.g. kerneloops daemon does which always consumes a bit of CPU and thus not
> increases the consuming of energy in a positive way. But hey, let's create
> another daemon to monitor where we're wasting and leaking memory...
>
> Plymouth is nice - sometimes. Why did we put so much effort into that? It
> does not work with many graphic cards and it doesn't make things really
> faster for me. You also forgot to put a message somewhere, that hitting ESC
> can abort that thing and showing the regular messages instead. But this is
> what is "usability" called, when putting such an information not onto the
> screen. Maybe plymouth is faster as previous stuff, possible. But compared
> with the work of Arjan van de Ven, Linux developer at Intel and author of
> PowerTOP, it's still slow. He's booting up an Asus EeePC within 5 seconds;
> with plymouth it anyway takes a multiple of that for me. But yes, plymouth
> looks nice to end users and we like to waste time for that.
>
> When already being on booting: Does somebody remember to the Ubuntu stuff
> we really needed some releases ago? I'm talking about upstart, the event
> driven/based init system we've been hot to. And now? We're using the compat
> mode and that's it. Everything else uses just the same compatibility mode
> and AFAIK nothing in Fedora uses the "advantages" of upstart. But yes, we
> are bleeding edge with that. Did it make sense? No. But we wanted it. Okay.
> Why the hell did we need a event driven/based init system so much, if we
> still are not using any features of it and replacing the old init skeleton
> by the new things? I thought, we're bleeding edge? Looks like we only need
> to have the latest sharp razor, but we're never using it for cutting. Is
> upstream of upstart still alive? And is there any forward development some
> where in the world?
>
> Fedora EMEA e.V. also seems to be a mostly dead tree. Of course we have
> founded the association as legal vehicle. But it would be nice to see where
> my money, my membership fee, the 128 Euro per year are spent to. I now
> could assume, that the money is just collected and nothing happens or some
> guys of the board are buying and eating ice cream with, but I really hope
> that's not true. Fedora EMEA e.V. really needs to communicate a bit more to
> its members what they're doing and how the money is handled. Organisation
> is lacking much transparency and about their activities. AFAIK, a mailing
> list for the members of Fedora EMEA e.V. was created, I think it never was
> used yet. 128 Euro per year is IMHO too much for the current level of what
> seems to happen with the money. And for that money I could support the Free
> Software Foundation Europe (FSFE) with multiple membership fees per year.
> And sorry, just one cool bathrobe isn't a good reason for spending 128 Euro
> away per year. Without enough transparency and communication, it's like
> throwing the money out of the window of my room.
>
> If you're reading this, you've hopefully read all I wrote above. The main
> issue is, that all of the issues are known (if you try to tell me something
> else you're either blind and deaf-mute or you don't care about Fedora that
> much) - to their leader/owner and to others inside of the Fedora Project.
> But nobody really follows, is having a look to these issues and problems or
> even takes care of it...why? I think, this should be the job of the Fedora
> Project leader, shouldn't it? I don't want to blame neither Paul nor Max in
> this e-mail, I think everybody of us needs to be more sensitive to issues
> around the Fedora Project and needs to take more care before developing or
> forking something. And things exist, we don't need to re-invent always the
> wheel just because it's cool and bleeding edge. More work to get patches to
> upstream and so would avoid some of the pseudo-forks on Fedora Hosted as
> well. We definately need Open Communication, not only Open Source. But as
> it seems, even Fedora Talk didn't help that until now. So maybe the "f" of
> Free spech got lost somewhere in the latest slogan redesign?
>
> Oh...I'm really sorry now, that I used the phrase "bleeding edge" together
> with "Fedora" and that I called "Fedora" as "bleeding edge". I already got
> dispraised multiple times by individuals (eg. as part of the Fedora website
> team), that I think, Fedora is bleeding edge. If you've really read all of
> my irony, frustration, comments and suggestions above, you should have to
> agree with me, that Fedora is "bleeding edge". Fedora is far away from
> stable, it's a sharp razor with many edges where somebody can be easily cut
> with - and that's why we mostly like it.
>
> My points above are what Fedora makes sucking for me - or why I am NOT
> Fedora! At least I'm thinking that. Maybe you're thinking about my e-mail
> before replying. I would also like to hear comments (even private ones) by
> the affected parts of the Fedora Project. Thanks for taking the time.
>
>
> Greetings,
>  Robert
>
> --
> fedora-devel-list mailing list
> fedora-devel-list at redhat.com
> https://www.redhat.com/mailman/listinfo/fedora-devel-list
>



-- 
http://scwlab.com