Ubuntu continues to rule the cloud
zdnet.com
zdnet.com
Given that one of Canonical's main projects is it's own desktop system that works the same on desktop and mobile, that statement just simply isn't true.
If I get to choose I'll run arch linux, but inside vmware it's ubuntu hands down.
Have you tried the latest versions of Fedora? The only thing I needed to do on Fedora was install video codecs and flash, which weren't automatically installed as they are in Ubuntu.
However, if you are using it as a server of sorts, you really shouldn't use either of those distros. Use CentOS or RHEL, or something purpose built for a long term stable server. Yes I"m aware of Ubuntu and Fedora server editions -- but both distros are focused on being jacks-of-all-trades instead of purpose built as a server only.
Clearly, saying Ubuntu works best on VMWare is a fallacy. Any Triple-A distro will work fine with minimal fuss.
I'm so glad you avoided doing that.
But I'll bite.
From your several posts, it's become clear you are running an Ubuntu guest as a desktop on top of VMWare. It seems rather silly to pay for a full VMware license to just run some desktops, not to mention hypervisors like VMware and Xen really aren't great at doing just desktop guests.
You make claims that Ubuntu works better "hands down" on VMware than any other distro - which is absurd. It's far more likely you either haven't tried, or did something wrong. The things you point to that are "better" on Ubuntu are virtually (or literally) the same things on other distros, or have zero bearing of whatever distro the guest is (pause and resume are features of the hypervisor, not your distro).
In any event, everything I previously said still holds true. If you need a server, use a server-focused distro.
> If I get to choose I'll run arch linux, but inside vmware it's ubuntu hands down.
What I mean is the distro I reach for first is Arch Linux unless it has to run in vmware, then the choice for me is Ubuntu, hands down.
I was making no comment about it being the best vmware distro "hands down". The entire post was just a quick note that I choose to run Ubuntu for reasons other than the environment reasons cited by the poster I was responding to.
Having said that, this will be the last time I respond to you. You've obviously got some strange personal stake in what I consider to be a good linux distro and I have better things to do than argue with you about it.
You are saying around 60% of sysadmins using Amazon instances are wrong. The odds are not in your favour :)
Yet, 100% of EC2 is built with RHEL/CentOS + Xen.[1][2]
Ubuntu was the default VM when they launched EC2, so most users naturally just used the default. But even in Amazon's eyes, when doing "serious" server work, reach for a purpose-built server distro -- not a jack-of-all-trades.
[1] http://www.zdnet.com/article/amazon-ec2-cloud-is-made-up-of-...
[2] http://bleikertz.com/blog/amazon_ec2_underlying_architecture...
There is added UI customisation on top, but that's irrelevant to it working better or not as a VMware guest.
But to answer your question, I've found desktop performance to be better in Ubuntu for the same specs, many distro's don't play well with pause/unpause (it can cause time skew that messes with things like https certs), and things of that nature. Then of course there's the "easy install", although a few other distro's feature it as well.
Nothing that doesn't have fixes, but as someone who is more interested in getting the work done than tinkering with the linux install, I just go with Ubuntu.
However open-vm-tools are getting better and better every day. In the past I had lots of trouble with them and up to Fedora 18 you mostly needed to rely on the vmware native tooling. arch had the same. Currently the only thing which open-vm-tools is missing is the 'unity'-mode. However on Arch you need to rely on AUR to get the filesystem driver and the network driver, which is really aweful on Fedora you can't install these in a easy way aswell. Only ubuntu has it which is mainly caused since open-vm-tools-dkms is not 'free'.
It's not a big thing, but I was already established with vmware so I decided it wasn't worth the effort to work around it.
I've also read that vmware is more performant than virtualbox both in general and in terms of hardware accelerated gpu. All 3 of those just pushed me to staying with vmware.
However, I will say, I vastly preferred the UI for virtualbox. I've seen internet fights about it, but for me, virtualbox most definitely has the better UI.
Not anymore. You can just launch the box without any GUI with one command line:
All of the command line parameters are documented, but there are no complete examples of a typical setup. Not too many people bother with it either, so examples online in blog posts are only semi-useful.
I wound up setting one up on a different machine then working through the various commands required to get my config to match my example.
I've become known for advocating its use.
That's what docker used for a long time (until, in my humble opinion, they decided they needed to differentiate and un-tie themselves)
Source: https://linuxcontainers.org/ (page footer)
Not because I don't take your argument at face value, but because I'm interested to know what exactly they consider flaky.
""" Thanks to libcontainer, Docker out of the box can now manipulate namespaces, control groups, capabilities, apparmor profiles, network interfaces and firewalling rules – all in a consistent and predictable way, and without depending on LXC or any other userland package. This drastically reduces the number of moving parts, and insulates Docker from the side-effects introduced across versions and distributions of LXC. In fact, libcontainer delivered such a boost to stability that we decided to make it the default. """
In fact it doesn't point out any problems with LXC at all except a general hand-wavy statement about stability (which sounds a lot like NIH-justification).
I was looking for actual problems - since I've never encountered any with LXC/Docker, I'd be interested.
The only arguments I've ever heard regarding this all boiled own to NIH syndrome.
Until recently Docker was far more interested in being an open implementation of a closed standard rather than an open (or closed) implementation of an open standard.
Docker was/is trying to be the only linux container, and creating their own non-standard container library was just one component of that strategy.
Protip: Since I am gaming/gamedeving, I need video drivers to work, and on the MBP you HAVE to boot/install from BIOS mode and not UEFI mode if you want things to work well. Also, that whole experience of trying every distro known to man on the MBP made me hate apples weird u/EFI setup, and UEFI in general.
/gimme bios back!
Yes, please do hate Apple's garbage EFI implementation, maybe someday they'll actually get the hint and release UEFI compliant firmware. I use UEFI daily on four different systems in my house (Lenovo W540, Surface Pro, XPS 13 (2014), custom-build desktop) with no issues, but god help you if you try to boot anything but OS X on a Mac without using BIOS Emulation.
Not a huge deal since I can always keep booting 4.0.4, but I do hope they figure out what is going on, and fix it.
This is exactly why people were screaming at Red Hat back when they decided to kill their (then) consumer offering, and later when they started actively eschewing talk about desktop Linux. Everybody knew that developers drive adoption of server OS's and that once developers started moving away from Red Hat derived distros on the desktop that they would eventually start moving away server-side as well. But I guess the higher-ups at RH either didn't believe, or didn't care.
Personally I still use Fedora as my personal desktop OS and mostly run CentOS, Fedora or Amazon Linux on servers. I never saw the appeal in Ubuntu. From what I recall, their main claim to fame had always been "we pre-ship all the proprietary audio/video codecs that RH won't ship" and the supposed superiority of apt over yum.
I use Ubuntu on the desktop on my work provided laptop and it works well enough, but I don't see any particular advantage over Fedora. And I prefer yum (now dnf) to apt, so I doubt I'll switch anytime soon. Still, if RH cares about this sort of thing, they really should start embracing "Linux on the desktop" again.
Sure, there are plenty of differences, but these are mostly the equivalent of vim vs emacs - if you're good enough you can make either work. They're mostly just matters of personal preference.
Though many users don't have the benefit of your level of experience. And, there should always be room for new users benefiting from Linux. So Ubuntu's tended to focus on being a Linux that works "by default" on the desktop and make sensible choices for developing in the Cloud.
The distros certainly have a lot in common, but each has its quirks and idioms, and once you learn them, it's annoying to have to bother learning another. Like, once I've memorized how to do a lot of things with RPM and Yum, it becomes "friction" to suggest that I learn to do the same things with apt.
I don't have any problem with Ubuntu, and I think it's fine for new users. I stick with Fedora really for two reasons:
1. The aforementioned familiarity.
and
2. They are more ideologically committed to software freedom, in terms of not shipping things like mp3 support, where you have patent encumbrance issues. I have been trying to gradually shift my life to a place where I don't need that stuff at all, or where I do, I use OSS / free software to interact with it. I mean, I'm pragmatic enough to use VLC to watch DVD's, but I don't go out of my way to use any content that isn't in a free format, etc.
If I were Amazon (and if I really cared which OS my customers used), I would rebrand Amazon Linux. Having the company name in the title just screams "vendor lock-in" to management.
So if I need to throw up a server right now that I'm reasonably sure will be supported for the ~5 year lifetime of the image and I don't have funding and a Red Hat sales rep already set up for licensing new instals, then an Ubuntu LTS is really the best option available.
Not anymore, CentOS is fully backed by Red Hat now.
That's also seen in the Microsoft ecosystem. Server 2012 R2 is very similar to Windows 8.1, right down to the UI. Every major release since 2003/XP has been a joined pair of Server and Desktop OSes, with only minor differences between them, such as a few DLLs and background/foreground prioritization.
You can literally build an MVP by adding the IIS feature to your desktop OS and grabbing the demo of SQL Server, and run it from there too. Of course, you'll want to scale them onto separate servers once you get any kind of load, but you can prove that your code works from a single desktop.
Windows 10/Server 2016 is almost a break in the above pattern. But they are close enough time-wise that I'm sure they use mostly the same binaries again.
When I received them I was pleased, everything worked.. well, not everything, but it sorta worked! I had a desktop environment and a command line and I felt a small sense of accomplishment because I'd navigated the strange menu's safely before anakonda or full-framebuffer installers... Because of the peer pressure I learned about how to do my bits, and I carried on.
Later in the year I found fedora, and Blue is a nicer colour than brown (I was young and fickle) but it was less user friendly, so I committed to learn that and get off the "Noob Friendly" Ubuntu OS.
Many years later I got a small laptop for my mother, at this stage in my life I was "awoken" and I knew the power a machine could hold if it ran linux, so I put ubuntu on it- She's not the most technically apt lady in the world but was able to do most things with ease, and I put that down to having a "Good UX outside microsoft" (since most people who learn the microsoft way are generally committed to a mindset and anything outside of that is pushed away).
A few issues with Flash, some performance hiccups on some websites that seemed to try and avoid supporting linux in strange ways (that I take for granted I know how to bypass) and eventually the machine gave up the ghost.
I bought a new machine and put ubuntu on it (13.10 I think) and she was somewhat less than pleased, the UX had changed, she didn't know what was available anymore, nothing was organised in a way she understood.. and so I installed mint, she's now happy.
So I'll say this for Ubuntu, they put linux in the hands of people who we should really be targetting, it allowed me access to linux acting as a base plate and later acting as a full blown system for someone who was not interested at all in computers. And they pushed a trend for that, so we should all be thankful.
At this point in my life I'd been involved in a half dozen large companies and used linux on enormous scale.
I moved to a company that was using ubuntu LTS (10.04) (old at the time) in production, it was heavily invested and I expected that wouldn't change as Developers were very hesitant to change to debian (which is too old/doesn't make things easy enough) or centos/RHEL which suffers the same issues and has the added benefit of having SELinux (which I'm an advocate of understanding rather than disabling).
I go through my daily security advisories and a local privilege escalation means all our virtual machines and virtual machine hosts are affected, luckily it's patched as 10.04 is still supported so I apt-get update;apt-get upgrade and send out an email saying the server will be down for 30 minutes while it receives patches.
I was wrong, it was down for 6 hours.
unfortunately someone upsteam caused that particular kernel update to rebuild all initramfs' on the machine, and had also named lvm2 to lvm, so now my drives wouldn't mount.
On any kernel version/initramfs version..
Normally you can drop to shell load the module, mount the drives and continue startup, but unfortunately that stopped a lot of things from loading such as the bonding we had in place on the nics.
obviously I didn't know why it broke at the time and was attempting to get help from #ubuntu on freenode. the response was:
"Sometimes it's better not to know why it broke"
that server was smoothly running CentOS that same day, and I managed to get all the Ubuntu VM's back up and working.. and changing apt-get with a shell script which simply echoes "don't do that".
So in my opinion support and enterprise is where it falls down.
On the "support and enterprise" not being ready. The only comment I'd make is that what you tested was the community of users support e.g. on IRC.
In Open source there's fundamentally a trade-off between "money for time, or time for money". In a production enterprise environment where it's urgent to always be available getting professional support makes sense. Then, when you have an issue, rather than the uncertainty of a community channel you can get hold of professional support from the experts in the software.
That's true of any of the major distributions and a lot of other important OSS software used in production.
Note: I have a bias on this point since I set-up Canonical's professional support and consulting organisation.
but with names of FOSS distro's like "Beefy Miracle" you can understand why. :P
Perhaps you've realized the unintended "pun" in the "apt" word :) (hint: apt-get)
We are in fact leaving them by the end of 2014, er the end of 2015, er some time in 2016. (It turns out disentangling years of encrusted dependencies is complicated.)
But in practice, Ubuntu is a perfectly good version of Debian for our purposes, so we'll probably stick with it. The devs also like it on their desktops so feel happier targeting the same thing on the server.
> Unix is used by 67.1% of all the websites.
> Linux is used by 35.9% of all the websites.
See also: http://w3techs.com/technologies/details/os-unix/all/all
Edit: poking around the site a bit more, I notice that they count Darwin under UNIX but OS X is a separate top-level category alongside Windows and UNIX (albeit one with less than 0.1% share). WTF are they doing? This makes no sense.
Ubuntu focuses on AppArmor instead.
Exactly. For you. This isn't a con of the actual system.
Seriously though, I've found that most things from the suckless guys are pretty great. st is a perfect terminal; surf would be perfect if it had an ad blocker.
In order to be able to perform URL-level blocking without a proxy; and in order to be able to perform context-sensitive blocking and CSS blocking at all.
A paid RHEL subscription will even give you security updates for point releases, in case your needs preclude from upgrading even to backwards compatible versions (e.g. You can use RHEL 6.4 even now, instead of 6.6 or 7.0)
More people know Ubuntu and is why they use it.
When we made our first major Linux deployment this year there's no way I would have picked anything but RHEL/CentOS, we have critical services running on these systems that will be in use for a long time, and playing the upgrade dance in 5 years even (shorter than it sounds) is not an appealing thought.
Given your companies pattern of doing its first deployment of Linux this year, and needing a very long support cycle - I think it's fair to say that you're looking for the equivalent of a traditional UNIX. Slow moving, with lots of stability and strong guarantees on backward compatibility. Red Hat and SUSE focus on that type of "enterprise computing" - they've grown on doing 'UNIX replacement'.
Ubuntu is aimed more at the (as you put it) "hip start-up scene" or at least the area in the technical spectrum that is about new technologies, concepts such as continuous deployment and cloud computing.
The funny thing is most enterprises have a bit of both those types of computing. Some slow-moving "eggs in one basket" services, but also the need for fast-moving innovative areas. So there's room for more than just one sort of distribution.
I recently had to move a bunch of Ruby 1.8 applications (where it didn't make financial sense to upgrade them) to new servers. They wouldn't even run on Ubuntu 10.04, where as CentOS 5.5 is still receiving security updates.
You can get supported ruby 1.9.3 on RHEL6 or CentOS6 https://www.softwarecollections.org/en/scls/rhscl/ruby193/ or https://wiki.centos.org/AdditionalResources/Repositories/SCL
Unless they are unwilling to upgrade their rails and using the ruby version as an excuse :) Best of luck to you!
From the ruby193 SCL page you linked to:
"Community Project: Maintained by upstream communities of developers. The software is cared for, but the developers make no commitments to update the repositories in a timely manner."
But if you have a redhat subscription they are fully supported. I should have pointed that out in my first comment though, thanks for bringing it up :)
"All Red Hat Software Collections components are fully supported under Red Hat Enterprise Linux subscription terms of service. Components are functionally complete and intended for production use. " [0]
[0] <https://access.redhat.com/products/Red_Hat_Enterprise_Linux/...
The apps were upgraded where possible but most of them had dependencies that would only run on Ruby 1.8 and have long since been abandoned. We considered rewriting them, but they are only used internally and are most likely going to be shutdown in the next year or so. At least the OS doesn't have any known security issues and is now properly behind a firewall, so that's something.
One of the issues with Ruby 1.8 is that it only compiles against OpenSSL 0.9.x. To compile it from scratch means you need to downgrade that (and a few other deps), which is about as painful as you can imagine. CentOS 5.5 still comes with that and is supported until 2017, where as you would need Ubuntu 8 or lower. I was thinking of creating a LTS version of Ruby 1.8 (a la Rails LTS), but I don't think the need is really there. Businesses who are running Ruby 1.8 have either weighed the risks or simply don't care :/
edit: SCL's aren't supported by RedHat
"All Red Hat Software Collections components are fully supported under Red Hat Enterprise Linux subscription terms of service. Components are functionally complete and intended for production use. " [0]
[0] <https://access.redhat.com/products/Red_Hat_Enterprise_Linux/...
But, we're talking about enterprise here, no young hip startups. Enterprise wants stability over everything else, young hip startups want the new shiny.
There are huge amount of Java 1.3, 1.4, and 1.5 applications still running in Enterprise all around the world with zero issues. Most of the time it doesn't make financial sense to re-build or spend time debugging an upgrade just to have the latest runtime.
"If it ain't broke, don't fix it".
As an aside, J2EE is quite good and very prevalent in enterprise, JBoss, GlassFish, Tomcat, etc...
http://serverfault.com/questions/243343/headless-ubuntu-serv...
The fix is in 12.04-proposed, but was never released, never applied to 14.04 and 15.04 last time I checked. Which is quite ridiculous, IMHO. (Can't find the Launchpad entry right now)
In addition, I think this behavior is not ideal for desktop users either, because (1) spurious errors can also happen in desktop and in that case waiting a few seconds is better than waiting indefinitely, and (2) it is not uncommon to use Wake-on-LAN nowadays.
But I'm not sure this problem is unique to Ubuntu, as Ubuntu shares much of its codebase with Debian. Does anybody know this is also problematic in other distributions?
Ubuntu shares a lot with debian, but grub configuration is one thing that Ubuntu appear to be doing on their own.
https://bugs.launchpad.net/ubuntu/+source/grub2/+bug/1443735
The problem was found (and a fix committed to proposed) in june 2012, but only applied (in -updates) in july 2015. I find that weird, to say the least.
In my experience, Debian's security team responds to new CVEs faster than Ubuntu's, but this is purely subjective.
As .service files become normal in the RHEL & Fedora/Debian world, and 14.04 LTS long life cycle runs, upstart is going to look increasingly out of date.
They might be a solid choice in the future but as of yet I haven't seen ANY reason to use anything else but Debian or CentOS.
And cloud deployments will abandon Ubuntu for something smaller soon enough.
Sure you can buy RHEL, SUSE and some other commercial releases but it costs money, other things like Debian Stable are very new initiatives and only provide support between stable releases 6-18 months.
Ubuntu guarantees security updates for the OS and common components like Apache other's don't.
If you are an organization that's very important especially if you need to comply with various regulations e.g. PCI-DSS.
Ubuntu is also one of only few distro's that is supported across all Cloud providers, it was the 1st distro to be supported on Azure and many of the smaller cloud providers start with Ubuntu or use Ubuntu as the core of their in-house linux guest.
Amazon's AMI might have been able to topple Ubuntu with their Amazon Linux but as it is not available for download and you cannot run it outside of AWS it will never reach any true leadership position, if you can't have it in house for development you will choose something else and the 1st rule of dev op's is deploy what you develop on....
In a few years CoreOS might get a big enough market share but currently CoreOS is too complicated and it locks you into using containers which is an overkill for most cloud deployments these days unless you are huge enterprise. If you are running a small web portal on a 1-5 servers Docker and other containers will just get in the way.
For me, it was the OS I was used to. And, as I've had to deploy a few CentOS and OES servers as well, I much prefer how Ubuntu/Debian configures things.
Apache, PHP, networking, cron, etc. All much easier to configure and harden on Ubuntu than on CentOS. Only thing I've found CentOS does better is starting and stopping iptables, and that's solved with a quick apt-get install iptables-persistent.
Most of this opinion comes from writing Ansible roles that work on both Debian and RedHat systems. Ubuntu was always easy to get right. CentOS always had some weird thing that required an annoying amount of work to work around. (Like it doesn't run Postfix smtpd in a chroot while Ubuntu does. Meaning I had to have different Postfix settings in master.cf on CentOS than I do on Debian.)
My first Linux was Redhat 5.1 (not RHEL), but I ended up switching to Debian Slink and OpenBSD for whatever reason. Since then I just personally find Redhat based distros a bit wierd or clunky (based on lack of familiarity), and prefer to stick with the Debian/Ubuntu side of the fence.
Reason to prefer Ubuntu LTS over Debian Stable: fixed 5yr support period instead of a variable period.
Reason to prefer Debian Stable over Ubuntu LTS: all packages in repo are in the same security patching regime. With Ubuntu you have to be a bit careful using packages from Universe or Metaverse.
Though they do have some form of LTS. [0] I do find it odd that the Debian Security team doesn't manage it.
Part of my RedHat dislike is unfamiliarity. But when I sit down and think about why I prefer how Ubuntu does something vs. how CentOS does something, I usually find Ubuntu methods make more sense.
For example, how the default apache mods are enabled. Ubuntu has the mods-enabled directory. CentOS has the LoadModule lines and mod config in httpd.conf. So to disable an unneeded module, you have to find the LoadModule lines, remove them, and the find all the various default config that is now broken. In Ubuntu, you just remove the symlinks in mods-enabled.
Originally (from memory) Debian stable was only supported until the next stable release which could be anywhere from 18-36 months later (release timeframes seem more consistent these days).
Then they started supporting an oldstable (the previous stable release) for an extra 1yr timeframe.
Debian LTS is a newer initiative, but it doesn't quite have the same security service level as say Debian Stable. Not all patches make it to LTS, and those that do arrive noticeably later. Debian is trying to find ways to improve this though.
But there are tons of developers out there that use ubunut. They have a great opportunity to create a complete IDE to cloud platform much like visual studio and azure, but with open source tools and a great linux system.
Or when I see Debian, I know that the system or person actually is serious, is likely to have a good operations and sysadmin mindset and will probably Just Work™.
Or when I see Gentoo, I see a kindred, albeit younger, soul.
When I see 'FROM ubuntu' in a Dockerfile, my heart sinks: it's likely written in JavaScript or Ruby; it likely Greenspuns heavily. For just about any server load, vanilla Debian is going to be a superior choice: better-engineered, smaller and lighter-weight. As far as I can see, there is almost never a good reason to use Ubuntu; it's just that in the eyes of so many folks it is Linux.
Oh well, at least it's not OS X.
No, that's Slackware.
Ubuntu was the second Linux distribution I put my hands on back in 2008, after giving Fedora a try and being frustrated - it was a system administration internship at my university, every server on the campus ran Fedora and our "CTO" (and also my boss) was a heavy Fedora user. Ubuntu was so much more welcoming for a person coming from Windows.
When I began doing some serious job in the cloud (~2010) it was on AWS and apart from Amazon's own AMIs, Ubuntu was the defacto standard - I even remember reading that it was the most used distribution on AWS back then (don't know the numbers nowadays).
I've never felt that I was using something under engineered, bloated or big. It simply worked very well, had fairly updated packages and a 5 years support that has always made sense to the tasks and jobs I've dealt with.
I like to think that despite some questionable choices, Canonical has always had a honest marketing approach with the Ubuntu brand, partnerships, embracing the cloud (juju), etc. When Vagrant came out, Hashicorp had the Ubuntu based box and now canonical maintains its own trusty box. It just always seemed to be present on every corner of my career so far, and it never let me down.
Please note that I'm not saying that Debian is not a superior choice, I just think it is unfair to look at Ubuntu with disdain and bring JavaScript and Ruby developers, as if the languages or its developers shared the characteristics you've brought. I simply never had a reason to move away from Ubuntu or try Debian.
For me it was RedHat, then Fedora, then Ubuntu, then Mint, then Debian.
> I just think it is unfair to look at Ubuntu with disdain and bring JavaScript and Ruby developers
The thing is, Ubuntu is kind of the Blub of distros: folks fond of it it can see where it's better, but not where it's worse.
As for server-side JavaScript and Ruby: I maintain that they are smells in any system. JavaScript is a mistake whose popularity relies on an historical accident. Ruby's a neat little language, but every single system I've used which utilises Ruby has been broken.
Yes, Debian will pretty much just work, but back before 7.x it would also be a pain to support a number of applications (we mostly rolled our own builds of "modern" runtimes and libraries we had to use, with predictable lag times and dead ends). Ubuntu takes all of that pain away and has relatively new stuff, even on LTS (sometimes through backports, but hey... nobody's perfect).
I also left RedHat because of the way the distro evolved, but never jumped to CentOS because at that time yum was slower than molasses, and I'd much rather use a Debian derivative anyway.
It's almost definitely better to install stuff in /usr/local or in install-specific locations under /opt than to use either unstable or Ubuntu in production.
> Ubuntu takes all of that pain away
Yeah, but it replaces it with its own pain. The days I bid farewell to Unity and GNOME were so happy…
I'll totally agree with you on Debian vs Ubuntu, but on Redhat vs Debian... We can agree to disagree. Here is a paste of an email I wrote up to some coworkers on the subject:
======================================================
RPM starts off with the concept of pristine sources. It is vehemently rejected that a maintainer of a rpm package use a non-upstream tarball or change _anything_ without a patch that is in version control. This is not the case with dpkgs
RPM
===
• Stores ownership, permissions, and checksums in the rpmdb. This allows for tools like [1] which are entirely impossible to re-create a dpkg equivalent. There is no equivalent of the insanely handy “rpm –V” in dpkg.
• The checksum is part of building a rpm package. The “debsums” functionality is not actually required for all packages. In fact, until Ubuntu got their act together and started fixing a LOT of stuff, many debian packages, didn’t have their checksums in the db.
• Changes are atomic. They use the bdb transactions and rollback. Either something was installed (via CPIO) or it was not. Debian package manager uses flat text-files! Those flat text files live under /var/lib/dpkg [Figure 1 below]. There are about 3-4 of these files per package, and they often times corrupt, resulting in impossible to uninstall packages. This simply doesn’t exist with rpms.
• The Debian package format lacked multiarch support until Jan 31, 2012[2]. Up until this version, installing a 32 bit deb on a 64 bit operating system involved creating a full system 32 bit chroot (I shit you not!), with hundreds of megabytes of silliness. Rpm has had multiarch basically since the majority of Fedora compiled with 64 bit compilers (around early 2005).
Package creation o RPM packages have 1 command, rpmbuild, for creating a binary or source rpm. You have a single file ${package_name}.spec, and the source tarball. That is all you need for a rpm. If you want to build the package in a “clean room” chroot, you can use mock, which runs as non-root
o For creating a deb package, you have dpkg-source, dpkg-buildpackage, dch, etc. For debs: Do you use debhelper or do you use cdbs? What version of debhelper, what version of cdbs? Which is deprecated and which is the “preferred” way? You have to edit the control file, the rules file, the package list file, the changelog has to have the perfect format or all hell breaks loose, etc. If you don’t put the exact same info in the control file and the package.dsc, woe be unto you! Once you’ve got that all done, you have to create a “debian source package”. Don’t get me started on that stupidity, seriously, it is worse than this entire thread.
• Multiple utilities. There is rpm. Then there is dpkg, dselect, dpkg-query, dpkg-reconfigure, dpkg-deb. dpkg-<TAB><TAB> results in 35 results on my test Ubuntu box and almost 30 for deb<TAB><TAB> mostly debconf stuff and almost 70 for dh_* for debhelper grossness. There are a couple of helpers like rpmquery (shortcut for rpm -q), or rpmverify (which is a shortcut for rpm –V), but they are symlinks back to rpm for convenience. One utility, one man page, less ambiguity.
• Templating. A rpm spec file is simply a shell script with some substitutions. Debian packages are all built using some extremely customized autotools and autotools like macros, each with conflicting versions and competing implementations (try to figure out if you’re supposed to use cdbs[3] or debhelper[4]). Both debhelper and cdbs exist because it is so impossibly hard to build debian packages by hand without some serious pain. There are macros for rpm spec files, but not even remotely the same complexity or necessity.
• With dpkg, it is possible to get into states which are impossible to resolve with the cli utilities (even dpkg –-configure –a). This always results in having to manually edit the pre/post hacky script under /var/lib/dpkg and is serious voodoo black magic that only experts should ever do. The problem is that it isn’t uncommon. If the pre/post scripts do ever fail bad enough to where you can’t fully remove a package, you can do rpm –e –-noscripts. Debian packages have this “rc” state where they are partially installed / uninstalled, but not fully either. Then you have to purge them using dpkg –-purge, and that is assuming that you’ve successfully hacked up the scripts that read the plain text files under /var/lib/dpkg. The entire design is unbelievably fragile. They make it a bit less fragile by writing an ENORMOUS debian packaging policy[5] to try to get people to work around silly limitations in the software via policy. This is against one of the fundamental design choices of rpm, which is that package installs should be atomic. It is either installed, or not installed. There is no “I’m half installed” status for rpm packages.
Hopefully this is a reasonable technical defense of rpm’s superiority over dpkg. What blows my mind is that Ian Murdoch made Debian after Redhat Linux existed but before YellowDog wrote yum. He had time to study the internals of RPM and design something superior. Instead, he NIH and invented something that on most levels to this day is still technically inferior. The yum vs apt debian isn’t near as lopsided where old apt > old yum, but new yum is unbelievably > than new apt. That is for another day, and only if you’re interested.
[1] http://www.digitalprognosis.com/opensource/scripts/restorepe...
[2] https://lwn.net/Articles/485349/
[3] http://build-common.alioth.debian.org/cdbs-doc.html#id250485...
However, it is supported in a very new release of rpm:
http://www.rpm.org/wiki/Releases/4.12.0#Generalbugfixesanden...
""" New --recommends, --suggests, --supplements and --enhances query aliases for querying weak dependencies """
So it is coming along :)
This is in Fedora 21, so should be in RHEL 8.
> RPM starts off with the concept of pristine sources. It is vehemently rejected that a maintainer of a rpm package use a non-upstream tarball or change _anything_ without a patch that is in version control.
dpkg is exactly the same. A "source package" consists of a .dsc file, which is metadata, an .orig.tar.gz file, which is the pristine upstream source, and a .debian.tar.gz, which is extracted to a 'debian/' directory after the pristine archive is unpacked. Within the debian directory is the build system, including local patches, which live under debian/patches.
> Changes are atomic. They use the bdb transactions and rollback. Either something was installed (via CPIO) or it was not. Debian package manager uses flat text-files! Those flat text files live under /var/lib/dpkg [Figure 1 below]. There are about 3-4 of these files per package, and they often times corrupt, resulting in impossible to uninstall packages. This simply doesn’t exist with rpms.
I have seen the RPM database become corrupted several times over the years, including if I tried to install an RPM while low on disk space! I have never seen the same with the dpkg database. And dpkg is no less "atomic"; dpkg keeps track of a package's state, and if interrupted a new instance will clean up or resume whatever the old instance was doing.
> • The Debian package format lacked multiarch support until Jan 31, 2012[2]. Up until this version, installing a 32 bit deb on a 64 bit operating system involved creating a full system 32 bit chroot (I shit you not!), with hundreds of megabytes of silliness. Rpm has had multiarch basically since the majority of Fedora compiled with 64 bit compilers (around early 2005).
This is not a valid comparison. Multiarch in RPM means something completely different to what it means in dpkg. dpkg's multiarch system is much more powerful and complete.
> With dpkg, it is possible to get into states which are impossible to resolve with the cli utilities (even dpkg –-configure –a). This always results in having to manually edit the pre/post hacky script under /var/lib/dpkg and is serious voodoo black magic that only experts should ever do. The problem is that it isn’t uncommon. If the pre/post scripts do ever fail bad enough to where you can’t fully remove a package, you can do rpm –e –-noscripts.
This is 6 of one, half-a-dozen of the other. In the RPM world you end up without the cleanup from the script ever taking place, and so the package ends up leaving traces of whatever throughout your system.
I've never thought of editing the maintainer scripts under /var/lib/dpkg/info as "serious voodoo". They are simple shell scripts, written to dispatch off of argv in the machinism specified by Policy. Errors in good quality packages are rare and trivial to fix.
> Debian packages have this “rc” state where they are partially installed / uninstalled, but not fully either. Then you have to purge them using dpkg –-purge, and that is assuming that you’ve successfully hacked up the scripts that read the plain text files under /var/lib/dpkg.
This is a good feature of dpkg. It allows packages to be removed without their conffiles or other important data (e.g., your PostgreSQL databases) being removed along with them, unless the admin takes the manual action to purge the package.
> The entire design is unbelievably fragile. They make it a bit less fragile by writing an ENORMOUS debian packaging policy[5] to try to get people to work around silly limitations in the software via policy. This is against one of the fundamental design choices of rpm, which is that package installs should be atomic. It is either installed, or not installed. There is no “I’m half installed” status for rpm packages.
So then, what state is a package in if RPM is interrupted while unpacking files? dpkg puts the package into 'half-installed' state, from where you can run a new instance to continue the installation or remove the package.
As for CDBS or debhelper, the vast majority of packages in the archive use debhelper, and debhelper use is increasing over time. Developer documentation tells you to use debhelper. The rest of the complaints about the build process I really don't understand, but perhaps I have just been building packages for too long. I'll take 'dpkg -i foo.deb' over 'rpm -ivh', oh wait, I meant '-Uvh' any day. :p
Furthermore, < 350 binary packages out of ~50000 lack an md5sums file according to https://lintian.debian.org/tags/no-md5sums-control-file.html.
Sorry, I don't think that characterisation is entirely fair. First, the issues that were resolved was making wording clearer because the FSF was concerned that it was confusing. There was no fundamental changes to principles of the policy so there should be no implication that Canonical was somehow falling foul of GPL licensing. For clarity, as the post you linked to shows the FSF would like more done.
Second, the comparison to RedHat is completely unfair because the two companies follow fundamentally different strategies. Ubuntu has a single code-base, RedHat has a commercial and a free code-base. This means Ubuntu has a single IP policy to deal with both commercial and free usage. Whereas you sign a standard commercial subscription agreement, or a different agreement if you use RHEL in other ways. For clarity, I'm not besmirching either approach, I'm explaining the context of difference [0].
Thanks for adding that they were fixed.
I think you were generally trying to support this point:
"I suspect quite a few Redhat employees will take strong offense to your comments on them not caring about Free Software"
Which I fundamentally agree with you on. I've met lots of current and ex-RH people and they all care about Free Software.
This is more broadly true. Generally, people don't put their careers in areas they don't care about. I've almost never met anyone in any of the commercial Open Source companies that doesn't care about Free Software. There might be lots of opinions and arguments, but everyone is trying to do the right thing.
[0] As a disclosure I should point out that I was responsible for Canonical's IP policy until March of this year