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.
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.
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.
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.
I've become known for advocating its use.
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.
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 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.