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@xxxxxxxxxxxxxxxxx> 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@xxxxxxxxxx > https://www.redhat.com/mailman/listinfo/fedora-devel-list > -- http://scwlab.com -- fedora-devel-list mailing list fedora-devel-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/fedora-devel-list
