Red Hat Enterprise Linux 7 Ideas Are Needed

[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/.../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

[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

[marwi509]

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

[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?

[mattst88]

Keep Ulrich Drepper away from the public.

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

[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]

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".

I sort of figured that he might be helping to orchestrate the next financial meltdown. Time will tell.

[frantaylor]

They then need to compile software from tarballs; doing that is a pain.

It also means that your third-party vendors are not going to offer you support. Many commercial offerings are complex beasties and they rely heavily on many of the libraries and other subsystems provided by RedHat. If you start adding new packages or changing existing ones, there is a very real possibility that you are going to introduce problems in your other installed software.

When you have to call vendor support to report an issue, the first thing they are going to ask you, is: "are you running on a plain-jane vanilla install?" If you can't answer "yes" then be prepared for a response like "well why don't you try to reproduce the bug on a clean system, and then call us back".

If you want to do science experiments with unsupported software, don't do it on a RHEL system. It's pointless. You're just making it difficult for the vendors to support you. The only reason to use RHEL is for the support. Use CentOS or SL or PUIAS or whatever, if you don't need support.

[tehehe]

One thing:
Provide support for system level virtualization (like openvz with full tcp stack virtualization). Solaris Zones are absolutely amazing and indispensable for me.

[liam]

One thing:
Provide support for system level virtualization (like openvz with full tcp stack virtualization). Solaris Zones are absolutely amazing and indispensable for me.

Are you sure they don't support LXC already?