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?
In my experience RH is -very- forthcoming when it comes to client support.
SRPMS (source RPMs) include a -lot- of meta data; same goes for pre-built RPMs.Quote:
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.
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)
I'm not sure you ever used RHEL in large and/or mission critical deployments.Quote:
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'd like to see user-friendly multiseat. (I'm not a RHEL customer though :D)
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:
- Program Manager
- Software validation specialist
- Information Security Engineer
- Administrative Assistant / Secretary
- IT Professional
- Web Developer
- Financial Analyst
- 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.
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?
... The answer is apparently "Yes". :(
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.
Provide support for system level virtualization (like openvz with full tcp stack virtualization). Solaris Zones are absolutely amazing and indispensable for me.