Intel Switches From Ubuntu To Fedora For Mobile Linux 165
An anonymous reader writes "According to a report on heise, Intel is switching from using Ubuntu to the Fedora Project for the second version of the Intel supported Mobile & Internet Linux Project Moblin, citing a desire to use RPM package management." So far, of the various subnotebooks I've been glancing at over shoulders at OSCON, though, most of the ones with an easily identified operating system seem to be running Ubuntu.
Oh, the fools... (Score:4, Informative)
There might be valid reasons to pick Fedora instead of Debian based systems, but package management is not one of them. Debian's package management is absolutely superior compared to everything else that I know about out there.
Re: (Score:2)
Are you a packager?
What are your opinions on deb's handling of patches against the upstream source?
Re: (Score:2)
I didn't run into any issue with debian-local changes so far. Why, is there a problem with the way dpkg is doing it?
Re: (Score:3, Funny)
I'm not a maintainer of any package in debian, But I did stay at a Holiday Inn Express last night.
There, fixed that for you.
Re: (Score:2)
Besides, the user's experience is what matters on a system, not the developer's.
Re: (Score:2)
Re: (Score:2)
I'm not a packager either but my understanding is that deb packages only allow you to store a single patch in the source archive, meaning you have to merge all your patches together into one big lump rather than having a full set of per-issue patches, making it much more difficult to remove a specific local patch.
I'm not saying that's a reason by itself, I'm just saying that the user experience of using a particular package system isn't the only variable in choosing a packaging system.
As a user I personally
Re: (Score:2)
I'm not a packager either but my understanding is that deb packages only allow you to store a single patch in the source archive, meaning you have to merge all your patches together into one big lump rather than having a full set of per-issue patches, making it much more difficult to remove a specific local patch.
This is not an inherent limitation of the system. You can in fact manually apply patches before build. These patches can be unpacked into the directory (effectively) by the changes patch, then you can apply them from the rules file.
The rules file is just a Makefile which is executed in order. So if you want to run some patches you just put them into one of the early stages, before you run configure or whatever. Issue the commands to apply the patches in order (you can get as crafty as one normally gets with
Re: (Score:3, Interesting)
I'll 2nd that. Way too many times to see Fedora, RHEL, and CentOS users posting about problems as a result of packaging issues. And didn't some big Linux fan make a switch away from RedHat because of RPM issues?
Redhat does currently have a more profitable enterprise so maybe the reason has more to do with RedHat corporate and/or employee backing.
IMO, the customers are going to pay for this as a result since Ubuntu is more consumer oriented and has a good history with their application package management.
LoB
Re: (Score:2)
I have had debs blow up on me as well.
RPMs can work very well as can Debs. I have used both and frankly it really depends on the people running the repository and if you need to install odd stuff.
Re: (Score:2)
True enough, the repositories are the real difference, not the package formats themselves. That said, the vendor repositories for any RPM based distro are not extensive enough for most purposes and while there are extensive third party repositories they are not nearly as well maintained.
This simply is not true with Ubuntu or Debian. The repositories are extensive enough that in the rare instance you encounter something that is not in one of the standard repositories you are probably better off choosing an a
Re: (Score:2)
packages in Redhat repos seem to cause a lot of problems while there seem to be far fewer issues with packages in Ubuntu repos
huh? Are you saying that individuals bollixed some packaging or that there's a problem with the Redhat repos?
From what I've seen, it must be very rare for somebody to report an issue at Redhat's bugzilla and for it to not get fixed. The RPMForge guys are also astonishingly fast.
Re: (Score:2)
what I was referring to was Redhat repository based packages
OK, what I was trying to get at was whether it was packaging errors or infrastructure problems. Sounds like packaging errors. I've only ever had to file one bug about this myself, but I must say that one was handled in a day or two.
Re: (Score:2, Insightful)
I call shenanigans, fedora user since fedora 3 without issue. Not to say there would never be an issue, there always can be with anything, But frequently the problem is between the chair and keyboard.
issues you speak of that do occur are most likely due to third party repo's, which almost everyone using fedora uses because of some small things that fedora doesn't include (proprietary codecs, patent encumbered codecs, adobe flash, emulators, etc)
Re: (Score:2)
yes, particularly everyone using linux as a desktop will need those same 3rd party repos.
All of those things are included in the standard Ubuntu repos, either in restricted or the universe, multiverse, and partner repos. I have never seen a conflict using them. Seriously, if you are stuck in RPM land, come over to the other side.
Really though, I don't think it has anything to do with RPM so much as excellent repo and packaging work.
yum (Score:4, Informative)
Ever since yum became part of the standard Redhat distro, I have had almost zero trouble with rpm packages. With the repository aware wrapper on top of rpm, dependencies are resolved automatically, just like apt. With the main repository getting larger and larger, there is less reason to use 3rd party repositories that could lend to dependency issues. The main reason to use a 3rd party repository is to add support for proprietary codecs and drivers.
There is even talk of removing the rpm command entirely so that all package management goes through yum.
Re: (Score:2, Insightful)
removing the rpm command would be stupid, while I agree package management through yum is the way, rpm is very handy
example, want to find out info on a certain package,
rpm -q -i *packagename*
looking for files installed by the package?
rpm -q --filesbypkg *package*
etc etc
Re: (Score:2)
We are talking about desktop usage here. Proprietary codecs, drivers, and legally restricted multimedia are par for the course.
Re: (Score:2)
For my servers, I keep local mirrors of Centos and Fedora. My local DNS redirects yum to a local mirror. It is about 12G for Fedora 9 with updates. Centos is much smaller since I don't sync the extra packages.
Re: (Score:2)
Well, apparently you haven't really used YUM on any real servers .. it's a pain in the ass compared to the ease and speed of apt-get.
Well I have, on Enterprise class blades and servers and "yum" works very well. I have even a yum for RHEL4-U1 and when you have a controlled repository (CentOS and Redhat) it makes multi site management of hundreds of machines very easy especially when you have deal with panicky Management and application people who could be anywhere in the world. A normal yum update takes anything from a few minutes to about 20 minutes (RHEL4-U1 to RHEL4-U6) and you don't have to stop the applications. Of course a new kern
yum and sqlite (Score:2)
I thought they moved most, if not all, that info to sqlite.
Re:Oh, the fools... (Score:5, Interesting)
And didn't some big Linux fan make a switch away from RedHat because of RPM issues?
That was ESR. He forced rpm to remove a package, even though rpm warned him that other packages needed it in order to function. Surprise of surprises, his system stopped working just like he was told that it would.
It was in no way rpm's fault that his system broke. ESR thought he knew better than rpm, and he was wrong.
Re: (Score:2)
yes, ESR but after a quick search, it looks like he got to the point you mentioned after a repository based package update failed and he spent 4 hours trying to get a working system back.
so it may not be rpm's fault, it is those behind the Redhat repository and how they put together the rpm's in their repos.
This follows what I've seen from a bunch of RH based admins as recent as this year. I don't know if it is just desktop based stuff or a mix of server and desktop but their management of their repositorie
Re: (Score:3, Informative)
https://www.redhat.com/archives/fedora-devel-list/2007-February/msg01082.html [redhat.com]
Eric was never forthcoming about what he did to break the system, which is no surprise because it was clearly an idiot thing to do.
If he had a problem with a repository, it's because he was trying to use a repository that wasn't compatible with Fedora. libcom_err was and is part of e2fsprogs-libs.
Absent any better proof than is available, I'll maintain that rpm is not at fault, and neither is Red Hat or Fedora. Eric was doing som
Re: (Score:2)
Everyone loves Eric Raymond [geekz.co.uk]
Classic.
Re: (Score:2)
Even if you get a conflict with a package the easiest way to manage this is note down the package name and remove it using yum although you have to be careful since it may want to remove a lot of dependent packages that you really w
Re: (Score:2)
Defended patent encumbered things like lame (mp3 encoder) go into multiverse. Of course pretty much everything is patented to some extent (no exaggeration in the USA) so really all a distribution can do is to remove patent encumbered software that companies are actually actively suing others over. Which as I understand it isn't the case at least for mp3 playback.
Ubuntu wants to stick to a single CD for distribution to make it easier to distribute in places where broadband is unavailable (many parts of the w
Re: (Score:2)
It would take probably 4-5 DVDs to contain all of Ubuntu.
Re: (Score:2)
I would never go back to the insanity of Fedora. Especially not for a desktop. I don't especially care which UI I am using, that is true.
I'm the kind of guy who likes having the knowledge and capability to tweak anything he feels the urge to but who doesn't actually want to have to tweak everything for it to be functional. Installing packages isn't exactly a chore on Ubuntu, so it really doesn't matter if one or 50 need installed, it still only takes 5mins. But the defaults and configuration of almost any p
Re:Oh, the fools... (Score:5, Interesting)
I've used both, and for what little it's worth, I disagree.
For one thing, with yum I don't need to know what package name I want to install. I can "yum install certtool", and it will determine that certtool is provided by gnutls-utils and install that package. IIRC, apt-get can't do that.
I can also ask yum to install a package that's in the local filesystem, along with whatever it requires. apt-get can't do that, either.
Half of the docs that I've seen indicate that debs should be built by hand, and then the results should be packaged. I don't know what the deal is there, but rpm has always used the "spec" file to build and package software, which is a more repeatable process. Deb has "rules" now. If they were always there, I'd like to be corrected on that point. The fact that there is documentation for other processes suggests to me that the deb build process has been much worse than rpm's.
Beyond all of that, Fedora is building some really nice tools on top of rpm for automated rebuilds and packaging. Basically, all of the tools that they use to manage the distribution are open source, which makes it much easier for someone else (like Intel) to build a distribution based on Fedora's tools.
I know that Ubuntu attracts a lot of users, but I can definitely see why developers would prefer to use Fedora's tools as a base.
Re: (Score:2)
Apt has a concept of virtual packages which are implemented by several different packages. That way I can easily switch between free or non-free JVM, for example.
Re: (Score:2)
rpm packages can do that, too, by "providing" a capability. The most common example I can think of is sendmail, which provides "server(smtp)", which any other package can require. Postfix also provides "server(smtp)", as does Courier.
Re: (Score:2)
On Ubuntu Heron:
stephenj@lords:~$ banshee
The program 'banshee' is currently not installed. You can install it by typing:
sudo apt-get install banshee
bash: banshee: command not found
stephenj@lords:~$
That's pretty neat. Something DOES know which package contains what I want.
Re: (Score:3, Informative)
it will determine that certtool is provided by gnutls-utils and install that package. IIRC, apt-get can't do that.
apt-file search path/to/myfile [debuntu.org]
Re: (Score:2)
Unless for some reason apt thinks the file is in another directory than it is in your path. I can't tell yout the number of times I've had apt/dpkg barf while trying to find the package that owns a particular file.
Re: (Score:2)
Thanks, I'll try to remember that.
Still seems like it's easier with 'yum', though.
Re: (Score:3, Informative)
Depends, auto-apt will actually suggest the package to install just by typeing in the command, or you can configure it to search and install the package you need to run that command the first time you try to run it.
Re: (Score:2)
The build process for debs has been the same for ages. Stand in the directory that contains debian/control, run dpkg-buildpackage (-b if you just want binary packages), done. There are many ways to build a package, but it's not because it has been an ever changing process... Just because some people prefer to roll their own. One of the projects I work on uses a maven plugin to build packages. There is no reason you couldn't build the package by hand too.
The tools you describe have all existed for Debian for
*NOT* exactly (Score:5, Insightful)
Debian's package management is absolutely superior compared to everything else that I know about out there.
Debian's package management *IS* the best.
But this has *nothing* to do with the DEB format.
Debian's package management rocks because :
- "apt-get" & friends are very well designed to track dependencies (compared to Slackware's TGZ system, for example, which does no tracking by design).
- Huge efforts from the community have gone into building the official repositories in a coherent manner. Thus every package has a clear and non ambigous dependence on other packages (I've seen minor distros where the distro's original package have broken dependencies because the actual needed package got renamed, but the packages needing them didn't get updated)
- Debian is a huge honking distribution with a crazy amount of packages. Most of the time, you only need to get packages from the default repositories, which where well designed as said before.
- As the repositories are well designed and coherent : it's easy to target for 3rd party package maintainers, and produce packages whose dependencies relate nicely to the rest.
- DEB is mostly only used by Debian. Other distro using DEB are usually variants of Debian (for example: Knoppix is basically Debian-installed-on-an-image and Ubuntu is a very close derivative of Debian), they are not unrelated distro. Thus if a user picks up a .DEB somewhere, chances are high that the package will work, because it was designed for debian to begin with.
Whereas RPM are used by pretty much everyone else - sometime by distro that have nothing in common (RedHat is mainly used in RedHat derivatives, but openSUSE for example has some Slackware in it's ancestry - thank fully they have also participated in important efforts such as UnitedLinux and LSB to make the distro compatible with others). A Fedora user may pick a RPM from a random site on the intertubes thinking it will work, but, surprise, it was designed for a distro with a different layout or organisations.
- apt-get & friends are fast (openSUSE has nice depencencies solving systems in YaST, and has good quality 3rd party repositories like Packman - but all this is bloody slow compared to apt-get)
So in short, Debian package management is good because of the software handling it and even more because of the quality of the repositories.
The exact same could be imagined with RPMs.
Re: (Score:3, Informative)
Most of the reason Debian is so good is due to their very strict policy and review of packages before being allowed into the repository. apt-get is just icing on the cake.
Re: (Score:2)
dpkg -i --force-nodep --force-all?
I don't understand most of your complaints; I shipped a deb package that brought and applied its own source patches.
Re: (Score:2)
Re: (Score:3, Informative)
The base rpm command can tell you what package a file belongs to, what a package provides, what it requires, _even when it is not installed_. Not one Debian command can do that. Several, separately, but not one.
dpkg does all of that:
what package a file belongs to
dpkg -S (filename)
what a package provides
dpkg -L (packagename)
if you mean what files it provides otherwise package provides are seen via
dpkg -p (packagename)
what it requires
dpkg -p (packagename)
_even when it is not installed_
dpkg -l (packagename)
--
a
Re: (Score:2)
Re: (Score:2)
Its not recommended but can be done via:
dpkg -i --force-downgrade
RPM vs DEB (Score:3, Insightful)
Re: (Score:2)
rpm -qa --queryformat "%{NAME}\t%{LICENSE}\n" (Score:2)
Python? Maybe they Intel wanted to use a query like the above to get a listing of each package with the license information. I had no idea the .deb did not support this feature.
Re: (Score:2)
rpm -qp --queryformat "%{NAME}\t%{LICENSE}\n" *rpm (Score:2)
Someone pointed me to deb [wlug.org.nz] file format, and it does appear the file format does not support a license key/value pair.
BTW, to query a file instead of the rpm database it would be:
rpm -qp --queryformat "%{NAME}\t%{LICENSE}\n" *rpm
Re: (Score:2)
What does it spit out when a package has multiple licenses depending on the binary inside that package. I seem to recall some KDE sources (at least in the past) having multiple licenses on different bits of code in the same source tarball.
Re: (Score:2)
It prints whatever the packager typed into the .spec file. So you could get something like this:
$ rpm -q --queryformat "%{NAME}:\t%{LICENSE}\n" openoffice.org-math
openoffice.org-math: LGPLv2 and LGPLv2+ and MPLv1.1 and BSD
Dependencies (Score:5, Funny)
FUD abound (Score:2, Informative)
Now, I'll preface this with a disclaimer that I avoid Fedora generally. I got reminded of why during a recent attempt to use it and follow it, it really punishes the users with inconsistant updates even after release.
That said, RPM dependencies are no more convoluted than deb dependencies. The difference is that originally, RH distros had only the rpm command and debian out of the gate recognized the need for both dpkg *and* apt. RPM distributions each have at least one repository management strategy now
Re: (Score:2)
debian out of the gate recognized the need for both dpkg *and* apt
Not exactly "out of the gate". debian shipped in 1993. apt shipped in debian-stable in 1999. Before apt, there was dselect. From the little I've seen of dselect, it ... was pretty bad. In fact that's probably why apt was so good, they were overcompensating.
Re: (Score:2)
Well, I don't know. Although I'm aware that there are more modern tools like aptitude, synaptic et al, I still use dselect on Debian and Ubuntu systems today.
Agreed, it doesn't win any design prizes, but it certainly works really well and predictably, which is what I'm looking for when working on systems a few hundred kilmeters away.
Well... Um... (Score:5, Funny)
I keep turning this over in my head, and keep coming back to the same scenario:
Steve Ballmer, in the Throne Room of his secret volcano lair: You begin to understand the true nature of my diabolic plan: If we cannot make Windows better, we will make Linux WORSE!
Anonymous Intel lackeys: Yes, master!
Steve Ballmer: Now go! Take these Fedora DVDs and install them on every Linux computer you find! Soon the foolish rebels will be BEGGING for Vista!
Steve Ballmer rips a bolted-down chair from the floor and holds it above his head, cackling devilishly, while his lieutenants and lackeys scramble for the exits.
==
(...with apologies to all three happy Fedora users...)
rpm -qa --queryformat "%{NAME}\t%{LICENSE}\n" (Score:5, Informative)
I *think* what Intel wants is this command:
rpm -qa --queryformat "%{NAME}\t%{LICENSE}\n"
I didn't know that .deb didn't support this. Can anyone provide a similar dpkg command?
Re: (Score:3, Informative)
There really isn't one. Most Debian packages come from main and are FOSS, so the licensing isn't a big deal. The package does contain /usr/share/doc/$package/COPYRIGHT by policy but that leaves the human grepping around. It would be trivial enough for the dpkg folk to add it but it has not been an issue up to now.
Re: (Score:2)
So, this won't work:
dpkg-query --showformat='${Package}\t${License}\n' -W *
Re: (Score:2)
Deb supports that. Apt doesn't.
The license is stored in the package, but it is not stored in the cached list of packages. You can do something like:
for i in *.deb; do dpkg -c $i | grep
To get a list of all packages licensed under the MPL..... But you'd need to have all the packages you wanted to check on hand, and usually all you have is the 'packages' file.
On the other hand, the packages are conveniently separated into 'main' (compli
Linux Standard Base (Score:2)
Is this to do with LSB requiring that RPM be available?
It's not JUST RPM they're after (Score:4, Insightful)
I wasn't sure why Intel would choose Fedora over Ubuntu either until I remembered the maintainer tools that Fedora has been working on.
It's not just RPM that Intel is after. Fedora has made a concerted effort over the last three or four releases to provide all the tools a group would need to make their own customized Fedora-derivative distro. I can't remember the software names off the top of my head, but groups like Fedora Unity use them to create more updated "spins" of Fedora releases.
So all Intel has to do now is build their own repository manager server and they can have automated testing, building, and packaging of any packages they want, up to and including the entire distro.
Re: (Score:2)
Search for 'custom debian distribution' in the debian wiki. Tools like this have existed to build custom Debians for years.
I've got exactly the setup you describe for the custom debian the company I currently work for ships with their product.
If you install the 'cdd-common' package, you get the base tools for building and maintaining your own custom debian distribution. Additionally, you'll find the 'debianEdu' and 'emdebian' wrappers that give you partial custom distributions if you don't want to start com
Mandriva has a superior RPM implementation (Score:2, Informative)
Fedora's RPM system is an absolute disorganized nightmare when it comes to RPM. Now Mandriva has done a few things right. They are disciplined about how they setup RPMs so you don't get dependancy Hell. Also. urpmi has far superior package deployment options when compared to yum.
For example. urpmi can do parallel installations of Authorized packages using SSH, and Kerberos simultaniously. Yum cannot. You have to setup your own mirror. urpmi can use LDAP to standardize the synthesis or hdlist. Yum cannot.
I r
Re:Intellectual property issue (Score:5, Insightful)
Except that deb packages (by policy) do include that info.
Re: (Score:2)
That's not what TFA says, guess I should not have read it. Apparently, the DEB package files used by Debian and Ubuntu don't have this information available. I don't use either, so I wouldn't know. Can someone double-check on an Ubuntu system?
Re: (Score:3, Interesting)
Re:Intellectual property issue (Score:5, Informative)
The package metadata does not contain the license beyond whether it's considered free or non-free, however every package is required to include usr/share/doc/[packagename]/copyright with the text of the license.
Re: (Score:2)
You could probably make a bash script to add that data to the metadeta, and convert the whole repo with it. But, of course, intel doesn't use bash - it's not a compiled language.
You are right Intel doesn't use Bash but all Linux distributions do.
Re: (Score:2)
for f in $(rpm -qa) ; do I=$(rpm -qi $f|grep License) ; echo $I $f | cut -d" " -f4- ; done
Your get something like the following:
License: GPL acl-2.2.47-1.fc9.x86_64
License: GPLv3+ and GPLv2+ with exceptions libgfortran-4.3.0-8.x86_64
License: LGPL libthai-0.1.9-4.fc9.x86_64
License: MIT libXext-1.0.4-1.fc9.x86_64
You can be a little more creative and find out how many different licenses and number off (quite a few) are on the system or what ever you
Re: (Score:2)
Re: (Score:3, Interesting)
Perhaps they will take the opportunity to FIX RPM's inefficient use on SSD's?
--jeffk++
Re: (Score:2)
When you run "rpm -qi package_name" then you can see what the License is for the package as well as the Signature and a host of other information. Another feature (there a
Re: (Score:2)
Wrong reason (Score:3, Informative)
Re: (Score:2)
Re: (Score:2)
Then why doesn't Fedora fix that? It seems like an obvious flaw, since my Ubuntu box automatically alerts me to any updates available, whether I last ran apt-get update a month ago or two minutes ago.
Fedora has had that for quite some time. I use Fedora 9 now but I have been getting update alerts since Fedora 6 although you can turn it off. Of course you could always check every day or week or whenever you felt like it with "yum update" (I never allow auto updates) since I like to see the size of the download and what packages I am getting for the update. You need to be root to actually do updates hence the reason why I don't allow auto updates and I may want to do the actual update at a time outside my
Re: (Score:2)
Actually it has nothing to do with RPM vs Deb. It's apt vs yum. Install apt-rpm in Fedora and see how fast you can install stuff (Actually, it has to do with yum updating the package lists every run vs apt just doing it with apt-get update).
I find that yum works very well on Fedora, CentOS and Redhat and it is very fast. In a nutshell the way yum works and I assume apt-get works in a similar way, is to query the target repo for its latest application database (normally in lite mySQL) and compare against the client machines database of what is available on the repo and installed on the clinet to see if anything need to be updated. If there is a requirement to update a particular package, that package plus any required dependencies is selected f
Re: (Score:3, Interesting)
KDE support in Fedora may be better as well, I haven't looked at it in a while so I'm not sure. KDE is stagnant as hell in Ubuntu/Kubuntu land for now (no LTS support for KDE in 8.04, etc.), due to all the churn with the very beta-like and some would say ill-planned KDE 4.0 release.
Re: (Score:2)
The only reason I could think of switching to Fedora from Ubuntu is if you had a nVidia 8200 motherboard. The Fedora Core 9 kernel version (2.6.25) supports it, and the one in Ubuntu 8.04 (2.6.24) does not.
You only have generic support for Nvidia cards so you should use the repo "Livna" which provides much better drivers. Whenever I get a new kernel I enable the "Livna" repo to actually do the update since you have to go to "Livna' anyway to get the drivers. Less hassels and only one reboot for the new kernel with the new Nvidia drivers to work properly. Total down time 5 minutes.
KDE support in Fedora may be better as well, I haven't looked at it in a while so I'm not sure. KDE is stagnant as hell in Ubuntu/Kubuntu land for now (no LTS support for KDE in 8.04, etc.), due to all the churn with the very beta-like and some would say ill-planned KDE 4.0 release.
If you put on Fedora 9, KDE 4.0 is IMHO annoying (I switched to Gnome) so you are best off sticking with Fedora 8 which has KDE 3.5
Re: (Score:2)
Disclaimer: Fedora package maintainer.
Re:Problems... (Score:4, Informative)
Re: (Score:2)
Re: (Score:3)
I have to disagree here. I use RHEL5 on my office desktop, Fedora 8 for the server in my garage, a recent Ubuntu release on an old beater laptop, and used to run Sparc Debian (Sarge) on a variety of old Sun gear. I would say this gives me a fairly good understanding of the differences. Here's my unsolicited opinions
Re: (Score:2)
s/facts/opinions/
HTH. HAND.
Re: (Score:2)
With Ubuntu, you get a more friendly/usable Debian. Ubuntu is pretty much to Debian as Fedora is to RHEL when it comes to new/unpolished features/kernel/software. Granted both Debian and Ubuntu are available for 0$ but that doesn't change the fact that Ubuntu is more usable because the distribution is more flexible. (Blah blah opensource, blah blah centrino drivers, blah blah licensing, blah blah xorg, blah hardware support).
I've used Debian and Redhat before I started using Ubuntu and I totally appreciate
Re:Problems... (Score:4, Insightful)
Fedora by design isn't a *real* distro. It is a testing ground for RHEL. Now, Fedora is usable, and nice and all. But Ubuntu is a *real* distro, you don't have to pay for the "full" version. With Ubuntu, you get Debian cleaned up. With Fedora you get all the bits and pieces that make up RHEL in a developer-oriented way.
You just like Debian is the testing ground for Ubuntu? It would in fact be much more precise to describe Fedora as a testing ground for Ubuntu too, since the technology pioneered there drips back into Ubuntu. Ubuntu is probably a nice distro, but it is not known for its technological contributions to Linux, unlike e.g. Red Hat or Novell who pays a lot of software engineers to improve or develop core Linux software, that e.g. distroes like Ubuntu can use.
Intel needs to give people a real distro, not a "trial" version of RHEL.
There you go again. Fedora is a real distro and a fine one too, a good mixture of the most modern software and maturity. Please state what kind of software Fedora lacks to become a "real" distro.
I have using Linux for many years, and one thing I don't get about distro fan-boys like you is why you need to bad-mouth other distros than you favorite-distro-of-the-month, especially when you are unable to back it up with technical arguments.
And by the way, RPM (at least the "true" RPM versions) seem to be outdated and DEB in most ways is superior. (Note: Not trying to start a flame war, but merely stating facts)
That are some really impressive technical arguments you gave there - not! I wonder if you actually know what DEB or RPM is? Please give an actual example why rpm is outdated to dpkg? Well, you can't. Try to read 'man rpm' one day to get a overview of what you are talking about.
Re:Problems... (Score:4, Insightful)
DEB in most ways is superior. (Note: Not trying to start a flame war, but merely stating facts)
If you want to state the "facts", try detailing something that the dpkg tools do, which rpm tools do not. Otherwise, you're just flaming.
Re: (Score:2)
So, let's say I have a debain based set up a full year out of date. It doesn't have firefox 3, which I want. I don't have the latest versions of GTK, and associated libs etc. The terminal window is open, what's the process look like? Go!
Easy:
$ sudo apt-get upgrade firefox
Hard:
$ sudo synaptic --dist-upgrade-mode
Is this a trap?
Re: (Score:3, Informative)
--dist-upgrade-mode is for upgrading to the next release of your distro, such as for ff2->ff3 (via eg ubuntu gutsy->intrepid).
You're right that "upgrade" only upgrades to the latest version available for your distro. Some distros offer multiple independent versions within one distro (eg) both Python2.5 and Python2.4. In that case:
$ sudo apt-get install firefox3
I still can't see this as any reason to switch from one package manager to another. :(
Re: (Score:2)
Bonus question - is the Debian based answer going to be any easier than "yum update firefox"? (That's exactly the command I used to upgrade an old CentOS 5 box I had to FF3)
I've built literally thousands of packages. RPM is just fine. Some distributions and some repos are fucked (which is just as true for dpkg) but the package format is just fine.
Re:7yrs with Linux and dead set on DEB (Score:4, Insightful)
Funny, from a desktop perspective I went Slackware -> Red Hat -> Fedora -> Ubuntu -> CentOS because HOLY CRAP an Ubuntu upgrade totally hosed my system and ended up with some thoroughly fucked dependency issues. :) And from a server perspective I went from Solaris -> Debian -> CentOS because the idiots at Debian release a 3.0 with a known broken PHP package and then proceeded to leave it broken for six months. /counterrant
Re: (Score:2)
Re: (Score:2)
Why bother with anything else?
*sigh* I cut my teeth on Slackware back in the day and remember it fondly... in much the way a marine remembers boot camp fondly I would imagine...
Configuring Slackware was a hobby unto itelf... while Ubuntu is almost install and forget.
Re: (Score:2)
Is 5.2 any better? I don't have a day to kill to try it...
We use CentOS where I work, and did find one interesting glitch in the upgrade to 5.2. We were using Xen hosts bridged onto the network, and found that the CentOS 5.2 upgrade *insists* on installing libvirt and starting up its own DHCP server, thereby breaking DHCP on the Xen hosts. Not that it wasn't trivial to fix, just annoying that a yum upgrade of a bunch of Xen Dom0 servers ended up temporarily taking down a bunch of VMs. Other than that, the upgrade was relatively painless.
From a bad experience or tw
Re: (Score:2)
They solve it by having nearly every FOSS application packaged (well over 25K packages) according to strict policy and package review. So its not really an issue of package format really as of actually caring about doing it right to begin with.
Re: (Score:2)
Any people driven away by "stupid bickering" are users we don't need.
Re: (Score:2)
Grow up. Sit down with all the people involved. Pick one or create a new one which has all the best parts of all the others. I don't know why/how and I don't care."
Then we just need to decide which religion is best and we can all go home.
Re: (Score:2)
Stupid bickering amongst "which packaging system is better" is a sure way to keep people away from your OS.
Sort of reminds me of the vi verses emacs flamewars of the 1980's. Of course we all know edlin is better uncle Bill told us so ;-)