Hacker News Reader

Comment by candiddevmike | Hacker News Reader

Red Hat made a gamble and it may turn out to be a miscalculation. By buying CentOS and leaving it be, they had tighter control over it's release cycle (how fast patches and newer versions were made available etc) as well as metrics on who was using it. Additionally, all of the CentOS users were still "in the Red Hat family" and at least kept the door open for future conversions/sales. They threw that all away now, they don't have any control over these forks and have wasted a lot of goodwill on short term profit.

Red Hat should've gone with the Ubuntu model instead and maybe even change to usage based pricing instead of a yearly subscription too, IMO.

View on HN

> Additionally, all of the CentOS users were still "in the Red Hat family" and at least kept the door open for future conversions/sales.

How? When Ubuntu tried advertising Ubuntu Pro via apt-get, everyone was outraged, and rightly so. How else could Red Hat talk to a CentOS user to convince them to pay up?

By providing value beyond just support. Ubuntu does this via Landscape, Red Hat is still trying to figure this out with Insights and the obtuse licensing for Satellite IMO. Packaging software has a high level of effort but really low value in customers eyes due to how many Linux variants are out there (again, IMO), so putting that behind a paywall these days is dumb. Containers exasperate this problem as most folks don't care if RHEL ships with PostgreSQL, they'll just run the Debian-based container.

For support, folks need enterprise support contracts. Maybe not everyone, maybe not every system, but folks that need it will pay whatever for it, it's the cost of doing business. Charge accordingly.

> the obtuse licensing for Satellite

Out of curiosity, which aspect of the subscription terms do you find obtuse? Simply put, any system managed by Satellite needs to have a Smart Management subscription. You can get these individually, or bundled with a RHEL purchase as the add-on. For consumers of the public cloud marketplace RHEL images, they include the client-side aspect of Smart Management (no Satellite infra, but you can request this) so you don't need extra subscriptions to cover those.

Ah, if only they’d thought of that. The longtime successful and solidly profitable (~$500 million a year) Red Hat corporation should copy the business model of Canonical, which makes 1% as much profit. Do you charge by the hour for this kind of advice?

Another mistake Red Hat has made over a long is having a "talk to the hand" attitude about doing anything differently.

As an example of the pathology, there is a long standing bug in GTK that causes the positions of things to be off by few pixels if you are running an X server like xming in multiwindow mode. It doesn't sound like much but it can make it impossible to click on menu items for menus at the top of a window.

The people involved at Red Hat would say in no uncertain words that they couldn't care less if it worked when you were running a multiwindow X server on Windows -- out of nothing but pure hate for Microsoft and people who use a Microsoft OS.

The supported use case is GNOME on Wayland. Everybody else can go suck eggs.

Nobody takes the linux desktop seriously anyways

Only because you do not consider ChromeOS and Andoid to be Linux.

Also, if some country/university thinks out loud about ditching Windoze for Linus desktops they get a huge discount -- so MS takes it serious.

> Nobody takes the linux desktop seriously anyways

I expect you are using OSX (or what ever it is called nowadays), which is a more polished desktop product, and usable by devs.

If you are on windows: you do not take Linux desktop serious enough. If you are on a Linux desktop: you forgot to count yourself. :)

I've used a Linux desktop for years, back in the KDE 3.x days (2005 something) where everything worked well. Then KDE 4 came, GTK 3 and Gnome and that's when I left because it was just unusable and went to Windows.

ChromeOS and Android are nice but are not desktop user interfaces.

I do have a Macbook Pro but only use it for testing purposes. It works well but I only use it for running Safari so can't really say how it works for a power user.

XFCE has been working well since inception, and Mate was working well during that time too. On windows, when win 8 came out, you either got left in the dust or had to endure it. On linux, when groups fuck up their thing like that you have the liberty to switch at very little cost.

The desktop bit is indeed a little unstable on Linux for some features. My experience as well. Especially with monitors, plugging/unplugging and window placement.

The underlying OS and command line world is sooo much more stable than Windows.

I agree KDE3 was the most stable Linux experience (I'm with a few small adventures still a KDE user).

Disclosure: I work for Red Hat

Expecting devs who work primarily on Linux to install a completely different OS and spent a few hours configuring it in a particular way, to work on an issue which is neither relevant to their own interests as FOSS devs, nor relevant to their employer, doesn't seem entirely reasonable.

If someone came along and fixed the bug, submitted a PR, did all the legwork and then it was still left to languish anyway then you would have a reasonable complaint. Could you provide a bit more context?

Fortunately for Red Hat, all of the makers of "cross platform UI" platforms are in a race to the bottom and that is why we are stuck with Electron apps that are all (30+x) MB in size and depend entirely on engineering work from Google.

How is that more context?

Are you saying there is a fix for this bug and someone at Red Hat has rejected the fix? Please link to that if so and I'll see if I can help.

Btrfs is a particularly sore point for Red Hat.

In Fedora, it is growing more pervasive by the day.

In RHEL, any implementation absolutely will not be supported, full stop.

I don't think that's the case. The underlying issue is that while Btrfs is growing in popularity across the Linux space, Red Hat just hasn't attempted to staff for supporting Btrfs in RHEL. No staff to support it to the level they wish to offer technologies in RHEL means no Btrfs in RHEL.

I would hazard to say that is probably because they haven't experienced any requests for the filesystem from their customer base. If customers started specifically asking for it, I think that would change.

I had a sales call with them recently to swap Oracle Linux out for RHEL.

I mentioned that I was using btrfs loopback mounts, and they confirmed that these are explicitly unsupported.

Even when running the UEK (i.e. for ksplice), this is not allowed, and they must be removed in a support event if they have any impact at all.

You expected Red Hat to staff up an entire team of filesystem experts to support your loopback mounting case?

Maybe just the ones working for Fedora?

Reply on news.ycombinator.com