OSNews: http://www.osnews.com/story/21388/Fedora_11_Preview_Release_Announced
Exploring the Future of Computingen-usCopyright 2001-2015, David Adamsadam+nospam@osnews.comTue, 31 Mar 2015 22:52:14 GMThttp://www.osnews.com/images/osnews.gifOSNews.comhttp://www.osnews.com
Comment by Tuishimihttp://www.osnews.com/thread?360873
http://www.osnews.com/thread?360873Windows cross-compiler, that is interesting. It all sounds very good. I wonder when Python 3 will come rolling into the game?

Also, Thunderbird 3, does it now have canonical plug-in support? I didn't think it did.

Otherwise sounds great!Wed, 29 Apr 2009 01:21:00 GMTdonotreply@osnews.com (Tuishimi)CommentsBeen waiting...http://www.osnews.com/thread?360878
http://www.osnews.com/thread?360878I've been waiting for Fedora's latest release; version 11, for some time. It's been awhile since I used Fedora and I'm ready to give the upcoming Fedora 11 a serious look. I've been burned recently by Debian Sid (Debian being my longtime favorite distribution.) The recently released Ubuntu 9.04 has also been disappointing, containing a few serious bugs that prevent me from using it day to day. Otherwise, it's a very good OS from my few weeks using it to date. I like cutting edge, but I also like a degree of spit and polish. I think the new Fedora 11 might just deliver.Wed, 29 Apr 2009 01:57:00 GMTdonotreply@osnews.com (cmost)CommentsRE: Comment by Tuishimihttp://www.osnews.com/thread?360879
http://www.osnews.com/thread?360879For more information on the Windows Cross Compiler effort, refer

Thunderbird 3 does have plug-in support and a number of major plugins have been ported already.Edited 2009-04-29 02:13 UTCWed, 29 Apr 2009 02:10:00 GMTdonotreply@osnews.com (Rahul)CommentsRE: Comment by Tuishimihttp://www.osnews.com/thread?360880
http://www.osnews.com/thread?360880

Windows cross-compiler, that is interesting. It all sounds very good. I wonder when Python 3 will come rolling into the game?

Also, Thunderbird 3, does it now have canonical plug-in support? I didn't think it did.

Otherwise sounds great!

Python3 should be in Fedora12 from what iv'e heardWed, 29 Apr 2009 02:10:00 GMTdonotreply@osnews.com (Sabz)CommentsRE[2]: Comment by Tuishimihttp://www.osnews.com/thread?360881
http://www.osnews.com/thread?360881That will be good.Wed, 29 Apr 2009 02:39:00 GMTdonotreply@osnews.com (Tuishimi)CommentsRE: Been waiting...http://www.osnews.com/thread?360882
http://www.osnews.com/thread?360882How, if I may ask, where you burned by Debian? It is usually only released after a long period of testing and is frequently behind other distros when it comes to major software versions.Wed, 29 Apr 2009 02:40:00 GMTdonotreply@osnews.com (Tuishimi)CommentsRE[2]: Comment by Tuishimihttp://www.osnews.com/thread?360883
http://www.osnews.com/thread?360883Python 3 will likely garner support over time... as for T-bird, yeah I know it supports plug-ins, but I thought not many plug-ins supported IT yet.

Back to Python (but not really)... I expect Perl scripts will have to go through some "regeneration" once Perl 6 finally reaches a stable state (with at least one accepted interpreter fully implementing the specification).

Languages evolve. Distributions like Fedora are "cutting edge" in many ways - why stop at the languages of the supporting scripts?Wed, 29 Apr 2009 02:45:00 GMTdonotreply@osnews.com (Tuishimi)CommentsRE[3]: Comment by Tuishimihttp://www.osnews.com/thread?360884
http://www.osnews.com/thread?360884Because practically nothing works with Python 3 yet and also because parallel building two different versions of Python plus hundreds of different modules is not a easy task at all.Wed, 29 Apr 2009 02:52:00 GMTdonotreply@osnews.com (Rahul)CommentsComment by Lazarushttp://www.osnews.com/thread?360885
http://www.osnews.com/thread?360885It doesn't seem to play well with the latest VirtualBox. By that I mean it doesn't boot for me.Wed, 29 Apr 2009 03:06:00 GMTdonotreply@osnews.com (Lazarus)CommentsRE: Comment by Lazarushttp://www.osnews.com/thread?360886
http://www.osnews.com/thread?360886Try the Live CD directly.Wed, 29 Apr 2009 03:23:00 GMTdonotreply@osnews.com (Rahul)CommentsRE[4]: Comment by Tuishimihttp://www.osnews.com/thread?360908
http://www.osnews.com/thread?360908Sorry, I'm trolling. It comes naturally sometimes. Wed, 29 Apr 2009 09:12:00 GMTdonotreply@osnews.com (Tuishimi)Commentsupgradeshttp://www.osnews.com/thread?360913
http://www.osnews.com/thread?360913i wish fedora was that kind of distros that you can upgrade day by day (not per release).
Maybe i wish they ditched RPM as well, but I suppose they mainly fixed it by now

the packages are of an excellent quality, regularly above all other distros. I support our own distro here, and while being debian based, when something goes wrong, patches always come from fedora/redhat. these guys almost always have things right.Wed, 29 Apr 2009 10:04:00 GMTdonotreply@osnews.com (_xmv)CommentsRE: upgradeshttp://www.osnews.com/thread?361003
http://www.osnews.com/thread?361003Fedora is like that. I have a F9 and a F10 both are upgraded with the same program versions... Kde 4.2.2 for instantThu, 30 Apr 2009 07:12:00 GMTdonotreply@osnews.com (aunzim)CommentsRE: upgradeshttp://www.osnews.com/thread?361039
http://www.osnews.com/thread?361039A. Fedora is release based. Actually, come to think about it, unless you're using Gentoo, everything is release based. (Debian Sid doesn't count).
B. Fedora anaconda installer could always be used to upgrade previous versions, you just need to start it somehow. (CD/DVD kit, Network boot, etc).
However, during the development phase of Fedora 10, a new tool was introduced - preupgrade, which automates the process of version upgrades. I've upgraded a large number of F8 and F9 installations to F10 and it more-or-less worked out of the box.
C. What's wrong with RPM? Granted, back in the RedHat 5-9 days, the lack of a network front-end (such as yum/apt/etc) made life pretty difficult. Never the less I fail to see how RPM is any worse than DEB. (Actually having created both RPM and DEB packages I must admit that I prefer RPM).

C. What's wrong with RPM? Granted, back in the RedHat 5-9 days, the lack of a network front-end (such as yum/apt/etc) made life pretty difficult. Never the less I fail to see how RPM is any worse than DEB.

FWIW, Up2date was introduced by Red Hat during the old 7.x series. (Was it 7.0?) and was backported to 6.2.

From a user's standpoint, it is not so much any particular technical features of debs that set deb-based distros apart. It is the availability of a mind boggling breadth of packages, organized into just a few centralized, well known, and well defined repositories which generally don't conflict with each other. (More packages, better organized than in the yum world.) Apt (as distinct from dpkg) is also, in the real world, much faster than yum, both in handling all the metadata, and in doing the actual downloads. I believe it can parallelize downloads from multiple servers.

Also, yum's memory requirements are insane. I have about a 60 user XDMCP server maxed out at 12GB of memory. Performance is find during the day, with 60 Gnome desktops running. No complaints about performance.

But I don't dare run 'yum install some_package' during the day. Because it causes such a swap storm that I know I will immediately get a call from the general manager saying that everyone is locked up. (Edit: I feel like I should add that I'm *really* not making this up.) It's one of the (many) reasons that I'm migrating the machine to a different distro next month.

rpm and deb may be theoretically equivalent as formats. But in the real world, the differences are readily apparent.Edited 2009-04-30 15:53 UTCThu, 30 Apr 2009 15:46:00 GMTdonotreply@osnews.com (sbergman27)CommentsRE[3]: upgradeshttp://www.osnews.com/thread?361215
http://www.osnews.com/thread?361215

From a user's standpoint, it is not so much any particular technical features of debs that set deb-based distros apart. It is the availability of a mind boggling breadth of packages, organized into just a few centralized, well known, and well defined repositories which generally don't conflict with each other. (More packages, better organized than in the yum world.)

A. As long as you keep yourself to well organized repositories, such the Fedora (default) and RPMFusion (biggest 3'rd part repository in the Fedora world), the number of conflicts should be more-or-less the same as Debian.
B. With these two repositories (Fedora, RPMFusion), Fedora has ~17000 packages [1]. While somewhat less than Debian, Fedora's packages tend to be newer.

Apt (as distinct from dpkg) is also, in the real world, much faster than yum, both in handling all the metadata, and in doing the actual downloads. I believe it can parallelize downloads from multiple servers.

Sorry, but this claim should taken behind the shed and shot.
In my experience apt is no faster than, say, Fedora 9 or 10. (Even w/o presto)
From a -clean- state, with 4 repositories (Fedora, fedora-updates, RPMFusion, kde-*), it takes me between 1:30 to 2:20 to get a clean copy of -all- the repositories and conduct a full search. [2]. (I ran the test 3 times. Slowest run displayed; Fastest run took ~1:28)
While apt support for multiple downloads is major plus, Fedora (at least here) has better repositories which usually max-out my net connection (both @home and @work), so parallel download doesn't really change anything. On the other hand, Fedora's mirror and repository management is far better than Debian's.
Never the less, could you please post comparable results from a Debian machine?

Also, yum's memory requirements are insane. I have about a 60 user XDMCP server maxed out at 12GB of memory. Performance is find during the day, with 60 Gnome desktops running. No complaints about performance.
But I don't dare run 'yum install some_package' during the day. Because it causes such a swap storm that I know I will immediately get a call from the general manager saying that everyone is locked up. (Edit: I feel like I should add that I'm *really* not making this up.) It's one of the (many) reasons that I'm migrating the machine to a different distro next month.

First, I wouldn't use Fedora for an XDMP server to begin with. Being bleeding edge, Fedora should not be used for a production sever. (Especially given the 13 month support cycle)
Second, people tend to forget that being bleeding edge, Fedora releases a -lot- of updates on a daily basis. At least in part, Yum's memory consumption depends on the number of packages being installed / updated.
Could you please compare apt memory consumption to Yum, when you try and install 100 packages?

rpm and deb may be theoretically equivalent as formats. But in the real world, the differences are readily apparent.

Sorry, but this claim should taken behind the shed and shot. In my experience apt is no faster than, say, Fedora 9 or 10. (Even w/o presto) From a -clean- state, with 4 repositories (Fedora, fedora-updates, RPMFusion, kde-*), it takes me between 1:30 to 2:20 to get a clean copy of -all- the repositories and conduct a full search. [2]. (I ran the test 3 times. Slowest run displayed; Fastest run took ~1:28)

Well, I just ran the same test, from a -clean- slate, with apt on Ubuntu Jaunty and measured an average of 14.5 seconds on 3 runs. (Range: 13.8s - 15.0s) The total number of packages was 26701. The servers are noticeably slower right now due to the recent release of 9.04. But with apt, I'm still seeing 6 to 8 times the performance than you are seeing with yum. The fact that you seem to consider 1:28 to 2:20 good is amazing to me. (Although your numbers are about what I would have guessed for Yum.) I suppose people come to accept what they are used to. Yum *is* a lot better than it used to be.

Your numbers, while pretty poor, do show another annoying characteristic of yum in the real world. See how *variable* the performance is? Not infrequently, I have to abort and try again. And not on just one machine. This is something I have noticed about yum over time. The Fedora mirror system has lots of dud and unresponsive servers. Timeout and fall back to another server is a routine occurrence.

While apt support for multiple downloads is major plus, Fedora (at least here) has better repositories which usually max-out my net connection (both @home and @work), so parallel download doesn't really change anything.

Really? On the same connection, I typically see a couple hundred KB/s, at best, using yum (yes, with the fastest-mirror plugin) and I regularly see around 1MB/s (or even more) with apt. It's interesting to watch apt "ramp up" as it finds more servers. Yum typically just staggers along, variably.

On the other hand, Fedora's mirror and repository management is far better than Debian's.

I never *worry* or think about mirrors with apt in Ubuntu. They "just work" and work well. I only have to mess with mirror configs with yum and Fedora. Relative repo management finesse, I'm not sure about.

First, I wouldn't use Fedora for an XDMP server to begin with. Being bleeding edge, Fedora should not be used for a production sever. (Especially given the 13 month support cycle)

I agree completely. The way this happened is that we were coming from, and thus were somewhat already committed to, the Red Hat world. Which means Fedora or CentOS. We were using CentOS, and it's a good OS. But by EOL the packages are moldy goo, which is not ideal for an XDMCP server. Some of the Fedora advocates around here convinced me that Fedora would be OK because of the supposedly fantastic testing that packages get as part of the release process. And one can only tell so much from a small pilot evaluation. Boy were they wrong. Boy was I wrong. And boy was the move from CentOS 4 to Fedora 8 embarrassing!

Second, people tend to forget that being bleeding edge, Fedora releases a -lot- of updates on a daily basis. At least in part, Yum's memory consumption depends on the number of packages being installed / updated.

Well, yeah, a gigabyte a month of Fedora updates is a pain.

Could you please compare apt memory consumption to Yum, when you try and install 100 packages?

No. I am not going to install and deinstall 100 packages on either my home desktop or on my customers' servers just to get numbers for you. I will reiterate and clarify that yum can cause swap storms on the XDMCP server in question when installing just *one* package. And I'm not the only one who has noticed. Just google for:

Well, I just ran the same test, from a -clean- slate, with apt on Ubuntu Jaunty and measured an average of 14.5 seconds on 3 runs. (Range: 13.8s - 15.0s) The total number of packages was 26701. The servers are noticeably slower right now due to the recent release of 9.04. But with apt, I'm still seeing 6 to 8 times the performance than you are seeing with yum. The fact that you seem to consider 1:28 to 2:20 good is amazing to me. (Although your numbers are about what I would have guessed for Yum.) I suppose people come to accept what they are used to. Yum *is* a lot better than it used to be.
Your numbers, while pretty poor, do show another annoying characteristic of yum in the real world. See how *variable* the performance is? Not infrequently, I have to abort and try again. And not on just one machine. This is something I have noticed about yum over time.

A. I don't have access to my Debian machine right now, but last time I did:
$ apt-get clean
$ apt-get update
... It took far more than 15 seconds. I assume that I had a lousy mirror.

B. Regarding the 1:30 time. Please note that I'm using the fastest-mirror plugin. Once I cleaned the cache (yum clean all), yum had to:
1. Rebuild the list of the fastest mirrors. (~30seconds)
2. Download the full DB's. (~1m, depends on the type of connection and the selected mirror)

C. If you disable the fastest mirror (or select the mirror by hand, like I do in Debian), you can shave ~30 seconds of this list. [1]

D. The time variation was must likely a result of different mirror (selected by fastest mirrror. ISP load variation may lead to a different mirror each time - especially given the fact that I don't have a local Fedora mirror)

E. In 95% of all cases, yum will use the cache. As you notice, yum needsFri, 01 May 2009 16:30:00 GMTdonotreply@osnews.com (gilboa)CommentsRE[6]: upgradeshttp://www.osnews.com/thread?361257
http://www.osnews.com/thread?361257P.S. Up until a year ago, I had Fedora on my 366Mhz, 256MB, 10 y/o laptop, and yum worked just fine. (I stopped using Fedora because I need certain patches to enable DRI on the MACH64, and having to port these [unsupported] patches once every months was rather annoying)
I now use CentOS 5.2.

I don't have access to my Debian machine right now, but last time I did ...It took far more than 15 seconds. I assume that I had a lousy mirror.

That would be extremely rare for Ubuntu. Can't comment authoritatively on Debian.

If you disable the fastest mirror (or select the mirror by hand, like I do in Debian), you can shave ~30 seconds of this list.

1:00 to 1:50 still sucks badly. Again, I just leave my mirror settings at default and have never had a need or desire to fuss with mirror optimizing band-aids on any of my Ubuntu boxes anywhere.

I fail to what yum (as product) as to do with lousy mirrors.

Note my liberal use of the qualifier "in the real world". In my rather extensive experience with both Fedora and Ubuntu, Yum on Fedora is slow and clunky compared to Apt on Ubuntu, which typically shines.

BTW, I have a long history (1997 on) with the Red Hat side of the Linux family, and was skeptical that Apt was as great as people claimed. But the difference has been so striking that I am surprised that people actually bother to argue for Yum.

I see that you're using Fedora 8. As you well know, a -lot- of work has been done to improve yum in each release, and Fedora 10 yum's performance are far better than Fedora 8's.

Well, that's the perennial Yum promise. Like a balanced budget by "Now + 8 years" or the classic old Mozilla chant "The latest nightlies are awesome!". Yum has gradually gotten better, yes. (I used FC1, when all the headers were individual, uncompressed file downloads! How could it get any worse?) But based upon experience, I take the semi-annual claims of huge improvements in yum with a large block of salt.

But yes, my Yum experience is ending with F8. The Fedora upgrades, these days, seem to be nightmarish on a server with a complex configuration, so I skipped 9 and 10 to avoid further embarrassment, and am now fielding security updates manually. And my primary focus, at this point, is upon migrating away from Fedora as quickly as practicable.Fri, 01 May 2009 17:19:00 GMTdonotreply@osnews.com (sbergman27)CommentsRE[7]: upgradeshttp://www.osnews.com/thread?361350
http://www.osnews.com/thread?361350

But the difference has been so striking that I am surprised that people actually bother to argue for Yum.

While I have zero experience with Ubuntu (Its possible that Ubuntu's popularity means it has far more mirrors than Fedora, which in-turn, help apt take the upper hand), most of the problems you see in yum, I see in apt under Debian: Problematic/slow mirrors.
True, apt does have simultaneous download support, but yum offsets this problem by offering better mirror management.

My Debian experience radically differs than your Ubuntu experience. In 4 years, I've seen apt (I'm using -Sid on a number of embedded systems) crash, fail on broken dependencies and get download files at 2KBps. I've seen it all.
So in -my- experience, Debian's apt is no better yum.

A couple of things to consider:
A. Even if Ubuntu's apt is 4 times faster than Fedora 10's yum, IMO, given the pace in which Fedora releases updates, yum is good enough (tm). As the repository cache is routinely being updated in the background, the actual -user- experience is immediate. (I just conducted a search in F10's "Add/remove packages", and got the results immediately)
B. Yum is getter far more development than apt. I have no idea what's the current status of debdelta in Ubuntu, but as far as I know F11 will be the first major distribution to officially offer delta based downloads.

Never the less, I can't (and won't) argue that F10 is a good production server. Nor do I argue that RHEL/CentOS 5.3 is a good desktop solution, as RHEL 6 is greatly overdue.
I am saying that yum, at least in it's Fedora 10 state, is no longer an issue.