Red Hat Enterprise Linux 7 Ideas Are Needed

[allquixotic]

He's not at Red Hat anymore. He's now at Goldman Sachs.

Wow. That would certainly appear to be true according to his LinkedIn profile. At first I thought you were joking! A freedom-loving old Linux hand wouldn't jump ship and sell out to the guys who are running our country into the ground, would they?

Would they?

... The answer is apparently "Yes".

[mattst88]

Keep Ulrich Drepper away from the public.

He's not at Red Hat anymore. He's now at Goldman Sachs.

[allquixotic]

Didn't the Red Hat CEO say recently that the desktop was almost dead?

Clearly they believe that, since they're helping turn Gnome into a tablet UI.

If they really believe that the desktop is almost dead, they've got their collective heads up their asses. That's nonsense.

Desktops are a unique form factor for dealing with large quantities of complicated data efficiently. Mobility and touch screens buy you absolutely nothing when dealing with complexity. In fact, the UI paradigms of platforms like Android don't map well at all to complicated forms, Excel spreadsheets and other large data sets.

Perhaps desktops are becoming less popular as an entertainment platform, but the enterprise desktop will be with us for many, many, many more years. I don't think the next 20 years even will see us using devices similar to iPads as our primary work "computer" for jobs like:

• Accountant
• Program Manager
• Software validation specialist
• Programmer
• Information Security Engineer
• Administrative Assistant / Secretary
• IT Professional
• Web Developer
• Financial Analyst
• Actuary
• Business Development Analyst
• Quality Assurance Specialist
• and on and on...

The paradigm for day-to-day operations in jobs like these consists of using Microsoft Word, Microsoft Excel, an email client, and a plethora of web applications in tandem to create, consume and modify large quantities of formatted data. You just can't tap on a screen fast enough to do something like that with an iPad-like device.

So these markets won't go away. And the demand for these types of jobs is increasing, especially since the three-letter organizations in the U.S. keep spending more money on expensive projects that need a lot of people with this type of work.

The thing of it is, MS Word and Excel are no longer unique. Lotus Symphony is a proprietary alternative, and OpenOffice an open source alternative, that almost perfectly interact with Word and Excel documents, and only minimal training is required to migrate from MS Office to OpenOffice or Lotus Symphony, both of which run natively on Linux. The migration story is very tractable there.

And web applications? If they use Java, JavaScript or any standard HTML/CSS features, they'll run perfectly well in Firefox or Chrome on Linux. Again, fantastic migration story. If they use ActiveX you're kind of in a ditch, but those old dinosaurs are being phased out, even by organizations that are still stalwartly Windows, because they're so error-prone and slow. You have Wine Internet Explorer for that, though, if you absolutely need 1-2 years of additional life out of an ActiveX-based Internet application.

With Samba4 supporting Windows Domains, it's very plausible to think that a RHEL7 release would have a robust, attractive, featureful desktop with a drop-in replacement for MS Office, a drop-in replacement for MS Outlook (Evolution groupware + Windows domain support), and native support for all the web apps you need. And you don't have to worry about users enjoying high performance with Flash training videos and the like, given that almost any business-class craptop is going to have some Intel IGP or Nvidia NV80 chipset that's well-supported by i965c or nouveau. As long as semi-recent, well-tested builds of the graphics stack are shipped in RHEL, we're good on that front.

Seriously, there are millions of enterprise desktops out there whose function cannot be outmoded without reducing productivity substantially. The keyboard, mouse, office suite, groupware, web browser combination comprises the whole software stack used by at least 30 - 50% of the white collar workforce in the US. If Red Hat doesn't want those Windows licenses to become RHEL licenses, shame on them. Especially when you consider that corporations are willing to pay lots of money for licensing, and they are already earmarking significant funds toward Windows licenses or subscriptions, it's not hard to see how Red Hat could very easily undercut them without saying "here, have this software for free! (many corporations mistrust "free").

Maybe RHEL earnestly tried to get inroads into the enterprise desktop in the past, and largely failed, so now they are cynical and feeling defeated like they don't want to keep trying. But I think that they should keep trying, and their persistence will pay off sooner rather than later. IT professionals themselves love Linux because of its security and ease of administration; it's largely the perception that support for legacy applications won't be there that is hindering adoption of RHEL on the enterprise desktop.

But as a worker who lives in this environment 8 hours a day, I can confidently say that I am seeing all those old Win32 apps being migrated to web apps at an alarming pace. Some of them use Java, sure, but it appears to be "pure Java" that runs cross-platform on a Sun VM, and maybe OpenJDK if you're lucky. The "cloud factor" isn't even relevant, here: good old, traditional, in-house dedi servers running web apps are more than sufficient to break the Windows addiction, because web apps run just fine over here on Linux, TYVM. So I'm happy to see that change is happening that will provide an open door for RHEL to waltz right in and set up shop.

Now it's up to Red Hat to seize the opportunity. Will they?

[marwi509]

I'd like to see user-friendly multiseat. (I'm not a RHEL customer though )

[gilboa]

I think you misunderstood why I listed that item. I have spoken to people that make decisions on what software their organizations use and most of them find that the software that they need is often missing from the official repositories. They then need to compile software from tarballs; doing that is a pain and introduces security vulnerabilities because the software is virtually never patched. I could care less about whether or not RHEL has any packages in their repositories, but the organizations I know using Windows do care. They don't want to compile software outside the package manager. It makes them responsible for dependency resolution and patches; both of those are things that they loathe doing. It also defeats the purpose of having a package manager because the security fix situation becomes the situation they have on Windows.

If a big RHEL clients requires a certain package version and/or unpackaged version he should really contact RHEL and see what can be done.
In my experience RH is -very- forthcoming when it comes to client support.

As for recompilation being possible, it is simple. RedHat can extend both the repository format and their package manager. The repositories would store instructions on how packages are built and what the dependencies are. The package manager needs to understand those instructions to be able to build packages from them. At that point, they can simply tell the package manager to build packages and it will build them. They can then distribute them and others can recompile them as they see fit. If it is never used to improve performance, it would still make for a good hardware sanity test, because compilation will more than likely fail on bad hardware.

SRPMS (source RPMs) include a -lot- of meta data; same goes for pre-built RPMs.
Nothing stops you from you from:
$ yumdownloader package (download source)
$ yum-builddep package (download and install the package dependencies)
$ rpmbuild package --target XXX (rebuild the package using client-defined configuration)

Honestly, I don't see why people wish to deride a suggestion that would increase the number of organizations using RHEL for its intended purpose. From what I have been told by people with whom I have spoken, the current repository situation keeps organizations on Windows and remedying that situation would eliminate a major factor preventing migrations to RHEL. I think it is quite obvious that my wishlist is meant to cover things that make RHEL for large organizations and not the typical end-user. All of the things I listed are things that I think would be useful for large organizations. Even if one item could be beneficial to end-users, that doesn't render it useless for enterprise use.

I'm not sure you ever used RHEL in large and/or mission critical deployments.

- Gilboa

[gilboa]

You probably have never programmed on Linux. The kernel supports gettid(), but gettid() is not available in userland. It is something that makes threaded programming a pain on Linux and it also introduces unnecessary issues when porting software to Linux.

http://www.kernel.org/doc/man-pages/online/pages/man2/gettid.2.html

With that said, I would like to ask that you refrain from making such ignorant comments, or better yet, that you use Windows. Software developers don't have time to deal with this nonsense.

[OT]
I must have completely misunderstood your post / OP, but pthread_self returns the current thread ID.
Beyond that, as far as I can see gettid is exported to usermode (by using syscall(SYS_gettid)).
Did I miss anything?
[/OT]

- Gilboa

[movieman]

What I would really love to see is RHEL being a relevant, up-to-date, aggressive competitor for the enterprise desktop, which is much more prevalent than you think.

Didn't the Red Hat CEO say recently that the desktop was almost dead?

Clearly they believe that, since they're helping turn Gnome into a tablet UI.

[jonnor]

I think you misunderstood why I listed that item. I have spoken to people that make decisions on what software their organizations use and most of them find that the software that they need is often missing from the official repositories. They then need to compile software from tarballs; doing that is a pain and introduces security vulnerabilities because the software is virtually never patched. I could care less about whether or not RHEL has any packages in their repositories, but the organizations I know using Windows do care. They don't want to compile software outside the package manager. It makes them responsible for dependency resolution and patches; both of those are things that they loathe doing. It also defeats the purpose of having a package manager because the security fix situation becomes the situation they have on Windows.

If something is not in the official repositories, you don't "need to compile software from tarballs". Use a third-party and/or community repository. EPEL, http://fedoraproject.org/wiki/EPEL, for instance. EPEL can certainly be improved, and RH would perhaps benefit from putting some (more?) people to work on it, but I don't think trying to have an official repo (as in fully supported) that competes with the likes of say Ubuntu is feasible.

As for recompilation being possible, it is simple. RedHat can extend both the repository format and their package manager. The repositories would store instructions on how packages are built and what the dependencies are. The package manager needs to understand those instructions to be able to build packages from them. At that point, they can simply tell the package manager to build packages and it will build them. They can then distribute them and others can recompile them as they see fit. If it is never used to improve performance, it would still make for a good hardware sanity test, because compilation will more than likely fail on bad hardware.

The repositories and package manager already have this information. See yumdownloader (--source) and rpmbuild.

[tomm3h]

The original poster in this topic is the phoronix news bot, which lacks the ability to grasp fundamental points by definition.

Aren't you hilarious... For clarity, I meant you. In context, you were the original poster that I was replying to.

[elvis]

Things that affect me as a RHEL customer:

1) (Already been mentioned, but I'll expand) a decent Single Sign On implementation. It took ages for FreeIPA to get off the ground, but 2.0 has finally made it into RHEL6.1. Even so, it's still clearly an afterthought for RedHat. A decent, secure, Kerberos based SSO system, simple server configuration, simple client registration/configuration (management of sssd, etc) would all be super. Whether it's done via FreeIPA or Samba4, I don't care. Samba4 needs to be recognised as more than just a Windows DC option, and seen as a potential Linux SSO system as well.

When setting up a Windows domain, Active Directory is a must-have feature. It's a mystery why we're in 2011, and I can still count the number of medium to large enterprises I've seen that have no centralised account control for Linux (and I've worked for quite a few). My last job involved managing 700 RHEL5 servers (mixture of physical and virtual), and talking to RedHat about Enterprise Linux SSO got a pretty poor response.

What's odd about all of it is that tools like RHEV-M and RHN Satellite can all happily authenticate via AD. Yet RedHat don't seem to have any desire to provide an alternative that they'll push/support themselves.

2) A strong focus on an enterprise capable database. RedHat provide a virtualisation layer (RHEV), the OS (RHEL) and fantastic middleware tools (JBoss/JBEAP). What's missing from the picture is better support for a database. Sure, PostGRESQL and MySQL are installable, but again they're just treated as customer problems. A strong focus on PostGRES (RedHat/PostGRES training, and support to the same level as JBoss) would be great.