Follow Slashdot stories on Twitter


Forgot your password?
Intel Businesses Debian Linux Business Red Hat Software Software Linux

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.
This discussion has been archived. No new comments can be posted.

Intel Switches From Ubuntu To Fedora For Mobile Linux

Comments Filter:
  • Oh, the fools... (Score:4, Informative)

    by A beautiful mind ( 821714 ) on Thursday July 24, 2008 @04:24PM (#24324951)

    citing a desire to use RPM package management

    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.

    • by tolan-b ( 230077 )

      Are you a packager?

      What are your opinions on deb's handling of patches against the upstream source?

      • I'm not a maintainer of any package in debian, however I did help package a few times.

        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)

          by Anonymous Coward

          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.

          • I was referring to LowNMU []. Not quite unrelated I would think.

            Besides, the user's experience is what matters on a system, not the developer's.
      • I made some PPAs, you get an original source archive and a patch with your changes, this permits redistribution of practically anything at all redistributable, in theory (unless the license explicitly prohibits making someone a binary or something.) It seems like a nice system to me. My understanding is that this is no different from the handling of any other package...
        • by tolan-b ( 230077 )

          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

          • 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)

      by Locutus ( 9039 )

      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.


      • by LWATCDR ( 28044 )

        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.

        • 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

      • yum (Score:4, Informative)

        by thule ( 9041 ) on Thursday July 24, 2008 @04:43PM (#24325287) Homepage

        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)

          by walshy007 ( 906710 )

          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

        • We are talking about desktop usage here. Proprietary codecs, drivers, and legally restricted multimedia are par for the course.

          • by thule ( 9041 )

            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:Oh, the fools... (Score:5, Interesting)

        by MSG ( 12810 ) on Thursday July 24, 2008 @05:10PM (#24325695)

        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.

        • by Locutus ( 9039 )

          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

      • by donaldm ( 919619 )
        I rarely get issues using "yum" unless I download a package from a site that does not play fair. Basically I only enable my generic repo's and turn off all others. I only enable a repo such as "Livna" when I want specific packages. Enabling all repos is just asking for trouble.

        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:Oh, the fools... (Score:5, Interesting)

      by MSG ( 12810 ) on Thursday July 24, 2008 @05:05PM (#24325629)

      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.

      • by Cyberax ( 705495 )

        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.

        • by MSG ( 12810 )

          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.

      • by judd ( 3212 )

        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

        That's pretty neat. Something DOES know which package contains what I want.

      • Re: (Score:3, Informative)

        by interiot ( 50685 )

        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 []

        • by kwalker ( 1383 )

          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.

        • by MSG ( 12810 )

          Thanks, I'll try to remember that.

          Still seems like it's easier with 'yum', though.

      • Re: (Score:3, Informative)

        by ArsonSmith ( 13997 )

        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.

      • by ivan256 ( 17499 )

        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)

      by DrYak ( 748999 ) on Thursday July 24, 2008 @06:08PM (#24326505) Homepage

      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)

        by calc ( 1463 )

        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.

  • RPM vs DEB (Score:3, Insightful)

    by AllIGotWasThisNick ( 1309495 ) on Thursday July 24, 2008 @04:24PM (#24324961)
    Is that not like switching to a different brand of cola? What kind of lame reason to switch distros is that?
    • Ok ok. So now that I've RTFA... what kind of lame reason to switch distros is that? Does Fedora *really* have that many unique packages that aren't in the other distros? Could this not be fixed with a simple Python script to scrape the license data?
      • 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.

        • The format does, of course. That's why this whole thing is ridiculous. Good tip about queryformat :D
          • Someone pointed me to deb [] 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

            • by calc ( 1463 )

              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.

              • by thule ( 9041 )

                It prints whatever the packager typed into the .spec file. So you could get something like this:

                $ rpm -q --queryformat "%{NAME}:\t%{LICENSE}\n"

       LGPLv2 and LGPLv2+ and MPLv1.1 and BSD

  • by xaositects ( 786749 ) * <(moc.stcetisoax) (ta) (soax)> on Thursday July 24, 2008 @04:28PM (#24325021) Homepage
    I hope Intel has a good rehab program in mind to tackle the dependency hell...
    • FUD abound (Score:2, Informative)

      by Junta ( 36770 )

      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

      • by mandolin ( 7248 )

        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.

        • by JayAEU ( 33022 )

          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.

  • by pushing-robot ( 1037830 ) on Thursday July 24, 2008 @04:49PM (#24325391)

    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...)

  • by thule ( 9041 ) on Thursday July 24, 2008 @06:20PM (#24326633) Homepage

    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)

      by Anonymous Coward

      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.

    • Since one good turn deserves another: "License" seems to be missing from dpkg-query [] and the deb [] file format.

      So, this won't work:

      dpkg-query --showformat='${Package}\t${License}\n' -W *

    • by ivan256 ( 17499 )

      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 /usr/share/doc/.*/MPL 2>&1 1>/dev/null && echo $1; done;

      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

  • Is this to do with LSB requiring that RPM be available?

  • by kwalker ( 1383 ) on Thursday July 24, 2008 @07:04PM (#24327229) Journal

    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.

    • by ivan256 ( 17499 )

      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

  • 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

Loose bits sink chips.