In other words, perfectly ordinary behavior in the proprietary world.
I spend 90% of my time at work fighting monsters like that (another juicy example: a proprietary and broken pseudo-clones of yum born from an intern's summer project 4-5 years ago).
Side note: VMware ESX was a Linux based OS (yes, vmlinuz loaded vmware via kernel modules, not the other way around as VMware likes to tell people, you can see this if you watch ESX boot).
This is a persistent and incorrect story. The proprietary esx kernel takes over from the initial linux boot. The esx kernel schedules running VMs, not the linux kernel.
That may or may not be true, but it doesn't affect that the Linux kernel module interface is a really bad place to put your valuable, proprietary, until ESXi not-ported-elsewhere IP.
I think their claim is that once the vmware modules load, they insert themselves under the Linux kernel (so Linux then acts like a dom0, similar to how Xen uses it). In that case, it would be in concept the same as one Linux kernel booting, and kexec'ing a second kernel.
This isn't surprising to me, coming from VMWare. Try using an API for any of their software projects. They break the principle of least surprise far too often.
I don't know, poor documentation? the toolchain check works for me on Fedora 20. I think it was a silly reason to stop reading the article so early at the mention of "yum"
I didn't read the article, I read the press release yesterday. I read "needs rpm/yum" meaning I am not interested, meaning no point for me to keep reading.
I don't like RPM or Yum. In my experience with using it, it has usually done more harm than good. What other companies use is up to them, but it isn't suitable for me. Argumentum ad populum is a fallacy.
RPM is really a great packaging system. It has a lot of features that DEB's do not, for example you can roll back yum/RPM transaction's if you like (yum history undo ${id}). Another example is to get a list of the last packages that were installed "rpm -qa --last". DEB's seem to prefer to write things to files instead, so they'll write to /var/lib/dpkg/info/*
One place where I think that DEB's win, is in building a new package. It was pretty easy for me to make a DEB than an RPM, and the fact that I had a hard time finding which RPM macros did function XXYY.
I think the reason why many don't like fedora/centos is the fact that packages aren't easily accessible, because Ubuntu will enable the universe repo by default whereas fedora/centos you would have to install that on your own.
I have had many issues with RPM and YUM breaking a system, something that hasn't happened to me deb-based systems. I find rolling custom packages and running an in-house deb repo and mirror to be easy and very reliable. There are quite a few things I don't like about CentOS/Fedora/RH are laid out. Yes, some of these are simply personal preferences, and some of these are based on technical requirements.
Live and let live - if it works for you, that's great, I don't have an issue with that. Unfortunately, it seems people have an issue with me not adhering to their own world view - pity HN is going that way.
I do genuinely appreciate your offer for help, many thanks :)
No, people are downvoting you because your first comment was about dismissing the article outright when you got to rpm+yum.
You haven't made any useful comments regarding the article, just continuing on about how you have personally had non-specific problems with yum and rpm.
Perhaps you "just did it wrong", and that's the core problem. I know when I'm not familiar with something and I sit down at it for the first time, I make mistakes too... but you shouldn't blame the system for your error.
If you are just using yum or dnf, you simply won't break your system.
So you've never had to edit a broken maintainer script under /var/lib/dpkg/info/* from bad post/pre install / removal bits? I've used both extensively on somewhere around 30k machines over my career and have to say I see rpm make a mess impossible to fix with just rpm 0 times. I most definitely can not say the same for Debian / Ubuntu systems. I think yum wins in that it has real plugins, not quasi plugins. There is a sort of debdelta-upgrade command, where as yum deltarpm is part of yum natively (you don't have to know about it to use it). The same can be said for the fastest mirror plugin, where yum will ping several mirrors and choose the fastest one for you. I can go on and on, but the moral of the story is that in 2015, from a technical standpoint, yum simply beats apt-get.
Bonus points that you have things like rpm -V and rpm -qf (which dpkg -S don't really replicate much at all).
Sure, ad populum is a fallacy when you are arguing a point, but when you are trying to decide on a toolchain to use, why wouldn't you go with the one that most of your customers use? You might like another toolchain better (and I happen to agree with you about rpm), but that doesn't necessarily mean it is objectively better.
I didn't argue about it objectively being better, I argued that it isn't suitable for _me_ - given the downvotes though, It appears that I am stupid and don't understand my own use-cases, and the general population on HN knows much better what I need.
I downvoted you not because of your disagreement, though I think you're wrong, but because of your peculiar insistence on self-martyrdom. It doesn't improve your argument and leads only to meta-complaint threads that generally don't go anywhere.
(i did not downvote you) This was my interpretation of your comment, my apologies if it is incorrect:
"I don't like YUM and RPM, and others shouldn't use popularity as a reason to use something"
Which I agree with. However, in this case, I think that if, in fact, RPM is popular among VMWare's customers, choosing that toolchain in order to make their new product more attractive to their existing customers is totally valid.
> I don't like RPM or Yum. In my experience with using it, it has usually done more harm than good.
How is:
yum install <package> -y
And worse than:
apt-get update && apt-get install <package>
A lot of people like to say RPM's are horrible, and maybe they are right... but if you use the package manager, what does it matter to you how the packages were made? It just works...
I can't think of a single example where something blew up simply because it was an RPM.
As a side-note -- the other comments are right, RPM is use an awful lot more in business because most businesses are running some flavor of RHEL/CentOS. If it were really that bad, then it would have been changed by now.
As a guy who has been packaging software for both, and who has been using Debian daily for years, RPM SPEC files are a hell of a lot easier to understand than the Debian packaging system (on the other hand, they're not really machine-readable or easy to generate automatically, so you have to choose your headache).
Yes, but when choosing tech it can be a good dimension of analysis if paired with other variables. Popular tools that are maintained if not bug-free can have a better understood bug-portfolio than a more elegant-but-still less used ones.
Choosing the devil one knows over the one one don't know and all that.
This stat is skewed by the default instance on things like EC2 being Ubuntu or Debian (should note that EC2 is built on RHEL/CentOS). There's an awful lot of people's blogs and one-off websites running on Ubuntu or Debian, sure. Those aren't really "business" use cases.
Also that stat is only measuring "websites". As far as my company goes, the vast majority of our servers are not internet facing, I'm sure this is similar elsewhere.
