Hi I read this about Google’s choice of ubuntu (deb) over fedora/opensuse(rpm). Could someone explain this to me or provide a link
Bushnell (Google - desktop linux management lead) was asked why Ubuntu instead of say Fedora or openSUSE? He replied, “We chose Debian because packages and apt [Debian’s basic software package programs] are light-years ahead of RPM (Red Hat and SUSE’s default package management system.]”
Does that mean that RPM’s are outdated and Red Hat and SUSE and still hanging onto it because they are established enterprise versions and it would be risky to change?
Its possible though I know that Debian only just recently added multi-arch support which was in SUSE for as long as I have used it. Also features like delta updates are already in practical use. An expert in both could probably explain better.
I think as an end user I am leaning toward liking RPM better.
On Fri, 31 Aug 2012 03:16:03 +0000, melvinjose wrote:
>> Bushnell (Google - desktop linux management lead) was asked why Ubuntu
>> instead of say ‘Fedora’ (http://fedoraproject.org/) or ‘openSUSE’
>> (http://www.opensuse.org/en)? He replied, “We chose ‘Debian’
>> (http://www.debian.org/) because packages and apt [Debian’s basic
>> software package programs] are light-years ahead of RPM (Red Hat and
>> SUSE’s default package management system.]”
>
> Does that mean that RPM’s are outdated and RedHat and SUSE and still
> hanging onto it because they are established enterprise versions and it
> would be risky to change?
No, it means that someone had an opinion different than the opinions of
people at RedHat and SUSE.
On 08/30/2012 09:49 PM, Jim Henderson wrote:
> On Fri, 31 Aug 2012 03:16:03 +0000, melvinjose wrote:
>
>>> Bushnell (Google - desktop linux management lead) was asked why
>>> Ubuntu instead of say ‘Fedora’ (http://fedoraproject.org/) or
>>> ‘openSUSE’ (http://www.opensuse.org/en)? He replied, “We chose
>>> ‘Debian’ (http://www.debian.org/) because packages and apt
>>> [Debian’s basic software package programs] are light-years ahead
>>> of RPM (Red Hat and SUSE’s default package management system.]”
>>
>> Does that mean that RPM’s are outdated and RedHat and SUSE and
>> still hanging onto it because they are established enterprise
>> versions and it would be risky to change?
>
> No, it means that someone had an opinion different than the opinions
> of people at RedHat and SUSE.
Quick test of inflammatory remark validity:
Anything concrete? No
All they say is “lightyears ahead”, but without anything else (no
citation, so who knows)? Since neither are likely to be located
anywhere but within our own solar system, which itself is nowhere near
even one lightyear across, this is not a fact (and even if somebody did
shoot the code of one or another into space at the speed of light, that
wouldn’t really contribute to its greatness or not… just its physical
proliferation potential).
In other words… who cares? Does it meet your needs? Good enough.
For an intense technical discussion, bring intense technical
question/comments, not fud.
Good luck.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.19 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://www.enigmail.net/
On 08/31/2012 10:39 AM, dd@home.dk wrote:
> On 08/31/2012 05:49 AM, Jim Henderson wrote:
>
>> No, it means that someone had an opinion different than the opinions of
>> people at RedHat and SUSE.
>
> +1, exactly…quoting one person’s opinion is like (hmmmmmm) quoting one
> person’s opinion…
>
> has nothing to do with facts…
Agreed. I have one machine that does not use openSUSE - it is a PowerPPC running
Mint 9, which is Debian-based. From the viewpoint of an experienced user, I see
no real difference, particularly for installing updates and new packages.
The only real difference in Mint, and Debian in general, is that it is
impossible to build and install a new kernel without building the .deb and
installing it. The simple ‘make && sudo make install_modules install’ that I use
for openSUSE fails. The deb-building script takes at least twice as long, and
that is significant on a slow processor even though I build only the kernel
parts that I need. Fortunately, I only use that box to test new kernels, and for
testing drivers for compatibility with big-endian processors. Once the kernel is
built and installed, it is possible to modify a module and update it without
rebuilding the deb. Otherwise, debugging endian issues would take forever.
I would suspect that the number of (pre-) packaged programs for .deb is a more significant factor. I’m sure they didn’t choose Ubuntu because it was brown or purple
Chrome OS (now Cr OS) now is based upon openSUSE and is running the Cinnamon DE which pretty well means as well that Google has conceeded that the laptop cloudterminal was a bad idea, and also means that the Chromebooks can now actually be successful.
Yeah… I wasn’t aware there was a non-Google Chrome OS so oops… although imo people shouldn’t name things where the addition of a word changes which one you’re referring to in a nonobvious manner. I mean at face value it’s hard to know the difference between Google Chrome OS, and Chrome OS Linux if you weren’t even aware these were two different things.
Larry Finger wrote:
> On 08/31/2012 10:39 AM, dd@home.dk wrote:
>> On 08/31/2012 05:49 AM, Jim Henderson wrote:
>>
>>> No, it means that someone had an opinion different than the opinions of
>>> people at RedHat and SUSE.
>>
>> +1, exactly…quoting one person’s opinion is like (hmmmmmm) quoting one
>> person’s opinion…
>>
>> has nothing to do with facts…
>
> Agreed. I have one machine that does not use openSUSE - it is a PowerPPC
> running Mint 9, which is Debian-based. From the viewpoint of an
> experienced user, I see no real difference, particularly for installing
> updates and new packages.
I have two non-opensuse machines One runs ubuntu and gave me a
nightmare upgrading from 10.04 to 12.04. There were one or more bugs in
the upgrade tool which broke dependencies. But it seemed to be pretty
much pecking out random incantations to find one that would mend the
dependencies. So independent of the RPM vs deb question, I would say
that zypp is ‘lightyears’ better than the tools ubuntu has for
dependency analysis.
The other machine is a Scientific Linux VM maintained by somebody else,
so I find that very easy to administer
The dependency issue, would be more the distro mantainers fault then the choice of package format, but i know very well what you mean, you really mean how apt handles the process compared to zypp.
I can’t agree with you more. Personally i think zypper (equal with pacman) is the best automated package tool out there. Apt for some reason is famed with being the king, but it makes no sense to me.
To me, it’s not so much if it’s deb or rpm, but the tools that handle them, and taking automation out of the process quickly, the two tools are dpkg and rpm.
In my mind, rpm is superior for one reason.
dpkg -r --ignoredepends=foo1 package1.deb
rpm -e --nodeps package1.rpm
These commands do the same thing, top one for a deb distribution and bottom one to a rpm distribution.
So what’s the issue then if they do the same thing?
Next time you use apt, bam, it won’t do anything until you agree to let it fix the ‘missing’ dependency first. This is my biggest issue with deb based distros, and i hate it so much.
automated package tools based on rpm, such as zypper or yum will not encounter this issue, and zypper will even give you the option to ignore a dependency sometimes if it finds a dependency conflict; apt would just come up with a ridiculous list of **** like djh-novell mentioned.
Why would you want to ignore a dependency? Because sometimes it’s just desired under unusual situations. I hate compiling software under Debian because of this issue.
And that’s why i think rpm based distros are superior to deb based distros, because i think rpm is a better package manager than dpkg.
Yes, apt (or apt-get) can not handle such issues very well. It generates only one solution and if the user does not agree with it he has to intervene by himself. On the other hand aptitude can generate such multiple solutions and asks the user which one to apply. The first solution from aptitude is the one that apt generates. If the user does not agree it starts his own dependency resolution. Aptitude can also ignore dependencies.
And aptitude is what is recommended to be used on debian and not apt-get
(which is older).
One always has to compare the newer openSUSE tools (zypper) to newer
Debian tools (aptitude), newer is relative, both are years old of course.
Comparing to the older apt instead of aptitude for Debian would mean,
compare it to let’s say to the older smart instead of zypper for
openSUSE to make the comparison fair.
–
PC: oS 12.2 x86_64 | i7-2600@3.40GHz | 16GB | KDE 4.8.5 | GeForce GT 420
ThinkPad E320: oS 12.2 x86_64 | i3@2.30GHz | 8GB | KDE 4.9.2 | HD 3000
eCAFE 800: oS 12.2 i586 | AMD Geode LX 800@500MHz | 512MB | KDE 3.5.10
Oh, that is a kind of religious in the world of Debian. I remember that some developers of sidux/aptosid doesn’t support anyone who has used aptitude once at their system and started a flame war against it (for reasons that are long past). One can use both, apt-get and aptitude, but if you run into some dependancy trouble aptitude is more helpful, imho.
Am 07.10.2012 17:46, schrieb zerum:
>
> I remember that some developers of sidux/aptosid doesn’t support
> anyone who has used aptitude once at their system and started a flame
> war against it (for reasons that are long past).
Well sidux/aptosid is not plain old Debian in a strict sense but more
derivatives.
But I understand what you mean, I have seen similar discussions on
debian forums.
> One can use both, apt-get and aptitude, but if you run into some
> dependancy trouble aptitude is more helpful, imho.
>
No doubt that you can use both, when I sit at a debian system I only use
aptitude, but others have different preferences. If you look at the
aptitude text gui you can also compare it somehow to yast’s software
management with its ncurses interface instead of zypper, which shows
there is no one to one comparison possible.
My point was more about what to compare to what, but comparing tools
across distros is anyway often enough comparing apples and oranges since
the tools have not absolutely exactly the same use cases.
–
PC: oS 12.2 x86_64 | i7-2600@3.40GHz | 16GB | KDE 4.8.5 | GeForce GT 420
ThinkPad E320: oS 12.2 x86_64 | i3@2.30GHz | 8GB | KDE 4.9.2 | HD 3000
eCAFE 800: oS 12.2 i586 | AMD Geode LX 800@500MHz | 512MB | KDE 3.5.10
