Slashdot Mirror

Maybe but look at this bug.

I have no previous knowledge of this guy however he looks like an emotional asshole who should be on daily wtf, not maintaining an important piece of software.

That's quite a read, you have to go out of your way to get multiple people writing comments like this one:

"Wow, you are a bastard. I hope you die alone. :D"

How do people with an attitude like Drepper's become maintainers of crucial projects? He seems obviously unsuitable (whether he has superb technical skills or not).

From TFA: 1 2 3 4

From TFA: 1 2 3 4

From TFA: 1 2 3 4

From TFA: 1 2 3 4

I know! For the record, he was talking about the problems of the patch in aquatic environments. "It's working fine everywhere but this carp architectures."

I'm not surprised that the project's been forked after reading this bug. Not only was he wrong, but he was adamantly wrong. It was only when his employer (RedHat) stepped in that it looks like they solved the issue.

The problem isn't GLIBC. The only problem is this idiot Ulrich Drepper. He demonstrates time and again that he is incompetent and has no business being in a position that is forced to interact with other people. This Ulrich Drepper character has the nerve to say stuff in bug report discussions like this such as:

• Stop reopening bugs. Search the web if you want an explanation, I don't have
  anything handy and certainly have no interest in writing it up.
• Strange, I never saw your name on my paycheck. Since if that's not the case you
  cannot order me around.
• Stop reopening the bug. If you want explanations pay somebody.
• Dammit, stop opening the bug. It is obvious that you know *NOTHING* about the
  issue at hand. Otherwise you would have noticed that this code has been
  entirely rewritten in the current code. It uses a very different implementation
  which allows to handle this situation differently.
• Stop reopening the bug. And this is also no discussion forum. Go somewhere else.
• Stop commenting.
• Idiot. There is no bug. Don't reopen.
• Fine. Whatever. I'll revert it, assholes.

And this is from a single bug report alone. Why exactly does GNU tolerate such a thoughtless idiot in such a fundamental position in such an important project? Moreover, this idiot Ulrich Drepper even shuns support important architectures such as ARM apparently due to nothing more than whims. How can this be?

GNU is supposed to be a project for it's users by it's users. You don't go far if you rely on antisocial morons to handle PR stuff.

Because uClibc has(had) inferior threading and performance. And it is(was) missing the GNU extensions that many popular FOSS projects depend on.
There is also newlib and dietlibc. In many ways I find newlib to be better than uClibc, although I still tend to use uClibc for projects because it's good enough and we already use it.

I'm looking around a bit, and this LWN article on utrace [lwn.net] doesn't make it clear to me what actual functionality exists today.

Ahh, the SystemtapdtraceComparison answered my question: systemtap can do nothing.

Systemtap lacks the following features dtrace has:

• trace user-space stack backtraces
• statically inserted probe points, user side
• trace Java programs
• trace Java stack backtraces
• statically inserted probe points, Java
• trace script language programs (specifically Ruby, JavaScript, Perl, Python, PHP, APL, Bourne shell, ksh, zsh, Tcl)

DTrace has had most of these features since at least 2005, and SystemTap still doesn't have them in 2009. People who say SystemTap is equivalent to DTrace are just disconnected from reality.

Before the Linux kernel came along, the GNU project had existed almost a decade - he surely used a computer then in order to write (or help write) the first versions of GCC, emacs, and a host of other essential free software programs. Now he doesn't have to, so he won't go back, and I'm sure he jumped onto a free kernel as quickly as it became remotely practical to use.

For certain definitions of "jumped onto"...

The glibc situation is even more frightening if one realizes the story
behind it. When I started porting glibc 1.09 to Linux (which
eventually became glibc 2.0) Stallman threatened me and tried to force
me to contribute rather to the work on the Hurd. Work on Linux would
be counter-productive to the Free Software course. Then came, what
would be called embrace-and-extend if performed by the Evil of the
North-West, and his claim for everything which lead to Linux's
success.

Source

The famous GNU/Linux thing is only the tip of the iceberg. When the whole Linux thing started he was heavily opposed to it because it distracts people from Hurd. And then there was this nice story with the glibc (start reading at "And now for some not so nice things")

Honestly, people give him far too much credit. He may have done some amazing things and inspired a lot of people, but on the other side when you consider what he sais he just seems like a little version of Mao or Lenin without power and opportunity. They all thought their way is the best for the people. And given the state their country was in they truly helped and freed them in the beginning. But in the end their version of freedom is just another version of slavery.

What's a Mz? Mertz?

Anyway, where's the love for machine code? What do you think your assembler was written in? (Actually, your assembler was likely written in C ;)

Which can also be used for Linux apps.

To be fair, that's not a way to use the same toolchain on Linux... There's SystemTap for something similar, though.

I don't know enough about either tool -- that was jut a minute or so of Googling -- but I would guess that SystemTap is far from "archaic". It would be closer to "bleeding edge" -- but it's also been a few years, so maybe not.

for the morbidly curious, there's even a pthreads library for windows. LGPLed

http://sourceware.org/pthreads-win32/

What about eCos?
http://ecos.sourceware.org/

wireless IP cameras are already here

I've even used Wifi cameras connected to 54GL APs with tomato setup as AP+WDS , so only 1 cat6 from 1 AP back to the main switch.

these cameras are running embedded linux at the moment , streaming D1 MPEG4 - will be switching to eCos http://ecos.sourceware.org/about.html soon.

won't be long before the cameras will all be connected to each other with WDS ( Wireless Distribution System ) with STP ( spanning Tree Protocol ) to stop broadcast storms.

MS-DOS is relatively fast to boot, but the BIOS part eats up a lot of time during the boot phase. But the disadvantage of MS-DOS is that it's a bit old now. A monolithic Linux kernel may do the trick, since it's in itself relatively fast to boot. The parts that cost time are the startup of various services, but it is possible to optimize those to do a tree-branched start instead of a sequential processing. This can be achieved using the command 'make' normally used in software development.

But of course - there are other operating systems that may be even better suited for the task. Like eCos.

It's both. The kernel is responsible for setting up the execution environment, and in the past it used a fixed 32 pages for the arguments. 32 pages on an ordinary PC is 128KiB, which is the old limit. The new limit is that any one argument can be up to 32 pages, and all the arguments taken together can be 0x7FFFFFFF bytes, which is ~2GiB.

Here's the diff: http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commitdiff;h=b6a2fea39318e43fee84fa7b0b90d68bed92d2ba;hp=bdf4c48af20a3b0f01671799ace345e3d49576da

After that, it was up to libc people to fix the globbing routines. Ulrich Drepper, taking some time off from his full-time job of being an asshole on mailing lists, managed to work this into glibc 2.8:

http://sourceware.org/ml/libc-alpha/2008-04/msg00050.html

Granted; its not aimed at the "desktop market" and as such won't have those fancy screens with a big "scan now" button. I can see that this will put some people off. But for all of us who don't care for those fancy pancy features and focus at functionality I'd suggest looking at ClamAV for Windows.

I've been using this on my computer at work for some time now and I have to say that it is a lot less irritating than most other products. There is one caveat; be sure to grab the PThreads DLL since ClamAV depends on it.

That is hardly a conceptual problem of the language C++, but more one of the toolchain and/or ABI, and can be improved on by rewriting the old GNU linker in C++ :). And maybe someday the GNU binutils will gain incremental linking.

More critical is that the grammar of C++ is undecidable.

JFFS2 is developed specifically for embedded devices, but I think that is because at its time of development the expectation was that only embedded devices would use flash media for primary storage.

It's been a while since I've looked into how it works, but I'm speculating that it attempts to spread out write operations over the entire disk by giving file fragments fairly dynamic addresses. I believe it also has an ECC scheme and uses a reserved storage area for marking bad blocks. Since the SSD almost definitely does the last two in its controller hardware, JFFS2 would be a good option if you can make use of its distributed write operations only.

http://ecos.sourceware.org/assign.html

has the form that eCos (open source RTOS) has been using to assign copyright. Maybe this will give you some ideas.

It occasionally decides that one of the other machines has dropped off the LAN even though all other machines can see it and connect to it. When that happens, the only recourse is a reboot.

I found a bug like that once in eCos. Sometimes the embedded system would see other machines on the net, sometimes not. Turned out it was a bug where they had some union for sockaddr* structures in the driver and the space they were allocating for the structure wasn't the max size of all the union's parts, so the ARP table got corrupted. No ARP table entry for a machine, no way to talk to that machine. Apparently, it wasn't a problem if you used DHCP, but since our Linux Priesthood declared that /etc/hosts must be used ("a DHCP server would just be another thing that can break"), so nobody else ever caught it. (It was fun writing an /etc/hosts equivalent function, since eCos doesn't assume a filesystem, but I digress.)

You could fire up wireshark and see if your iCandy machine is sending out ARP packets asking for the machine it claims has disappeared. That's what nailed it down for me.

Of course, since eCos was open source, I had it fixed with the help of some forum posters inside of a week. No problems since. Wonder how that would work out with closed-source stuff, like VxWorks or uC/OS-II. Oh, yeah, they'll charge me $50k or so to get the source so I can fix it myself, or they'll make me send a complete set of test hardware and source code to them for them to look at, and they'll find it in a couple months, and the bug fix will be in the next version six months to a year after that. Can't say I miss those days.

It seems there are compiled versions of Eclipse, maybe that will help with some of the bloat.
http://sourceware.org/eclipse/

However I do find the autocomplete features quickly grind to a halt whilst using APIs with large numbers of methods such as jogl.

I hope Ecipse gets better and better because it really is an excellent IDE, and at the moment the only thing holding it back is the performance issue.

Or perhaps the syscall() function?

Tell me what objdump -x `which $kdeapp` | grep NEEDED returns at your system. It should only return direct deps, not the whole list.

eCos is an open source, royalty-free, real-time operating system intended for embedded applications. The highly configurable nature of eCos allows the operating system to be customised to precise application requirements, delivering the best possible run-time performance and an optimised hardware resource footprint.

• eCOS http://ecos.sourceware.org/
• RTEMS http://www.rtems.com/
• FreeRTOS http://www.freertos.org/

Is eCos Linux?

As eCos originated from Red Hat, probably most famous for its distribution of the Linux Operating System, it has become a common misconception that eCos is Linux or in some way based on Linux. However eCos is a completely separate product, with a separate source base. eCos does have an EL/IX level 1 compatibility layer though, allowing it to be compatible with many of the Linux APIs.

I researched flash file systems for a project at work, and they all incorporate wear levelling. I ended up designing my own, since we needed a flat, numbered, record-oriented file system, something JFFS2 (for example) couldn't meet.

Many devices (digital cameras, MP3 players, etc.) use FAT, more-or-less unmodified. This limits them to a few million erase/write cycles on important sectors, but I don't think the average digital camera will last that long.

A flash-based hard drive will have different requirements. I'd be interested in seeing how they handle them, but not $549-interested.

...laura

Ahem.

From http://sourceware.org/ml/libc-announce/2001/msg000 00.html

tallman recently tried what I would call a hostile takeover of the
glibc development. He tried to conspire behind my back and persuade
the other main developers to take control so that in the end he is in
control and can dictate whatever pleases him. This attempt failed but
he kept on pressuring people everywhere and it got really ugly. In
the end I agreed to the creation of a so-called "steering committee"
(SC). The SC is different from the SC in projects like gcc in that it
does not make decisions. On this front nothing changed. The only
difference is that Stallman now has no right to complain anymore since
the SC he wanted acknowledged the status quo. I hope he will now shut
up forever.

The morale of this is that people will hopefully realize what a
control freak and raging manic Stallman is. Don't trust him. As soon
as something isn't in line with his view he'll stab you in the back.
*NEVER* voluntarily put a project you work on under the GNU umbrella
since this means in Stallman's opinion that he has the right to make
decisions for the project.

The glibc situation is even more frightening if one realizes the story
behind it. When I started porting glibc 1.09 to Linux (which
eventually became glibc 2.0) Stallman threatened me and tried to force
me to contribute rather to the work on the Hurd. Work on Linux would
be counter-productive to the Free Software course. Then came, what
would be called embrace-and-extend if performed by the Evil of the
North-West, and his claim for everything which lead to Linux's
success.

Which brings us to the second point. One change the SC forced to
happen against my will was to use LGPL 2.1 instead of LGPL 2. The
argument was that the poor lawyers cannot see that LGPL 2 is
sufficient. Guess who were the driving forces behind this.

The most remarkable thing is that Stallman was all for this despite
the clear motivation of commercialization. The reason: he finally got
the provocative changes he made to the license through. In case you
forgot or haven't heard, here's an excerpt:

[...] For example, permission to use the GNU C Library in non-free
programs enables many more people to use the whole GNU operating
system, as well as its variant, the GNU/Linux operating system.

This $&%$& demands everything to be labeled in a way which credits him
and he does not stop before making completely wrong statements like
"its variant". I find this completely unacceptable and can assure
everybody that I consider none of the code I contributed to glibc
(which is quite a lot) to be as part of the GNU project and so a major
part of what Stallman claims credit for is simply going away.

This part has a morale, too, and it is almost the same: don't trust
this person. Read the licenses carefully and rip out parts which give
Stallman any possibility to influence your future. Phrases like

[...] GNU Lesser General Public License as published by the Free
Software Foundation; either version 2.1 of the License, or (at your
option) any later version.

just invites him to screw you when it pleases him. Rip out the "any
later version" part and make your own decisions when to use a
different license since otherwise he can potentially do you or your
work harm.

In case you are interested why the SC could make this decision I'll
give a bit more background. When this SC idea came up I wanted to
fork glibc (out of Stallman's control) or resign from any work. The
former was not welcome this it was feared to cause fragmentation. I
didn't agree but if nobody would use a fork it's of no use. There
also wasn't muc

"""
First of all on it's own terms the story makes no sense, the anonymous coward starts off by saying it's interesting when people disagree. He then links to two articles which, as he points out, are written by the same person and then asks who is right. He has just pointed out the opinions are both from the same person and he wants to know who is right, this is just moronic.
"""

It's only stupid if you didn't read this part "metaphorically speaking?". Please actually read before you post.

"""
Secondly although I know nothing about PThreads or Win threads I can see that both those articles are largely the same with just the terms PThreads and Win threads switched so in one article he is claiming an advantage for one based on what he has stated as the advantages of the other in his other article.

Why is this on the front page, why was the submission accepted in the first place when it's complete nonsense and the most recent post by the author of both articles was in 2006.
"""

It's about starting a discussion. It doesn't matter that they are basically the same article, nor does it matter that they were written by the same person. These articles are a starting point for us to discuss something, which as it happens, goes on a fair bit around here.

Honestly, is this your first day? Or did you just have a neural misfire?

But, to contribute to the discussion a bit, since when I program I want to have the code as cross-platform as possible, I go with pthreads. They run pretty much everywhere (including windows: http://sourceware.org/pthreads-win32/) whereas win32 threads only run on, *gasp*, windows. But, that's just my opinion.

there is a pthreads implementation build on top if win32. I am not saying it is efficient, but it does the job.

No, you don't need Cygwin for ffmpeg...

If you know how to open a Command Window in Windows (cmd.exe) and can cd (change directory) to a folder, you can use ffmpeg.

There are compiled Win32 ffmpeg binaries here: http://ffdshow.faireal.net/mirror/ffmpeg/

(you'll need this .dll in the same folder as ffmpeg.exe: ftp://sourceware.org/pub/pthreads-win32/dll-latest /lib/pthreadGC2.dll )

A few points, the rest of your post speaks for itself.

As for Linus's opinion, anyone can read it in the linked post. He is against the inclusion in glibc and states that very clearly in that thread, for the reasons I have outlined.

First of all, in your example case you would know the max length of table names, and so you would use that instead of 51 as your buffer size. Second, in a case where truncation matters, you test for it, duh?

Until the next someone uses some sort of valid filler (like a spaces, or something else) to achieve that chopoff. Boom, security breach. Yeah, I should've checked the return value, but what then would I have done? Raised an error? Reallocated? The code would end up being even uglier. And we all know that requiring developers to check return codes all the time instead of just doing the right thing is a bound to lead to bugs. Which is why C++'s new no longer returns a null pointer if the allocation fails.

The real problem is the usage of a fixed buffers in the first place. str*cpy all encourages using fixed buffers, which is why these people oppose them. We can't get rid of strncpy (without violated the C standard), but we can avoid adding more of these functions, which only gives you a false sense of security. You could read that thread I linked, (not just the random post I linked to yesterday)... it is quite informative.Here it is openSSH's code that is being picked apart.

And I most certainly don't want strncpy. Yeah, I made a typo, forgetting to remove the length while I copied and pasted, so shoot me. I'd get a compile error and remove the extra parameter. The purpose of strncpy and friends is to manipulate records in a database in a certain format; using them for string handling in any other case is insane. You know that, I know that, any C programmer worth his salt knows that, why do you keep bringing strncpy up?

I didn't use strdup since it isn't available on all platforms, and because I wanted to illustrate the general concept (keep track of the length, (re)alloc as necessary. If I was doing this for real, I'd use/write a library, where the stringtype would be something like

struct easy_string {
// length of string
size_t length;
union {
char buffer[40];
char* buf_ptr;
};
};

Which could be used with library functions to behave correctly in all circumstances. I am sure such an obvious idea is already implemented in some library, though.

PS: Not being rude? What do you call, and I quote,

I have made no nonsense claims, and even if I had, you have no reason to be rude.

For Linus's stand on the issue, please read a post he made on this issue. In fact, skip the rest of this post and just read that thread, Linus is a much better teacher than I ever will be.

Still reading? ok, you don't need to tell me basics about C or it's standard library.. I know the language quite well. And I happen to agree that including strlcpy and friends with glibc is no great harm, as long as a fat warning is included in it's manpage (as well as all the other str* and even mem* should have) about it's shortcomings. However, you blithely ignore the fact that truncating strings based on length likely covers a bug more effectively than the security problem the buffer overflow is. Yes, you might avoid the easy security problem (buffer overflow) but you might introduce a worse one. Consider the example. I can follow Ulrich

#ifdef BSD_HACK
// Woops! Something like
// DELETE FROM TABLE_THAT_USER_IS_NOT_ALLOWED_TO_ACCESS_USER_VIEW
// might become
// DELETE FROM TABLE_THAT_USER_IS_NOT_ALLOWED_TO_ACCESS
char input[51];
strlcpy(input, getValidatedSqlFromUser(), sizeof input);
#else
#ifdef ULRICH
// Safe, if cumbersome.
const char* sqlFromUser = getValidatedSqlFromUser();
char* input = (char*) MALLOC(strlen(sqlFromUser)+1);
if (!input) { abort();}
strcpy(input, getValidatedSqlFromUser(), sizeof input);
#else
char input[51];
// Woops. Could SEGFAULT (if compiler with stack smashing protection), or overflow bufffer if not (security breach)
strcpy(input, getValidatedSqlFromUser());
#endif
#endif
executesql(input);

Now, given that stack smash protection is pretty much default these days, I'd say the BSD version is the worse security risk, or at least, the one that is hardest to detect. Of course, the design of that program is insane (restricting access in application rather than in the db, e.g.), but I think it illustrates the problem with the strlcpy and friend function pretty clearly.

As for the linuxism... I have had little problem working around them. If you have had trouble with doing that, perhaps I can point out that the source code to each and every non-standard function is available, as well as documentation? Yes, they happen, because like it or not, most people prefer a good function over a portable one, and nothing you or I can do will change this. Nor would I, if I could really. Improving the libraries tend to start at the grassroot level.

Finally, I must declare I am tired of your baseless insults, and will only respond to polite posts from this point on. I can accept shit from great programmers that have illustrated their worthiness, but not from someone who obviously still have a lot to learn.

P.S: Ulrich Drepper's code is incorrect (even if ugly) unlike the code you wrote, at least in the general case. So I think it is taken out of context, as I don't see Drepper making that sort of mistake. The only case strlcpy is valid is if you really want to copy & truncate a string. So if strlcpy was renamed to strcptr(dst,src,n), I think it might be accepted. Though it is a relatively rare usecase, and might be better placed in another library. And once we embarm upon that route, we might as well replace the weak stdlib string library with a safer and better dedicated string library. Like C++ have done with the std::string.

Because Linux is so flexible and modular :-)

In its original form, Linux is basically a server OS like Unix. They've tweaked the scheduler to make it more responsive as Desktop OS. With some modifications, Linux can be a real-time OS. It has been modified to run on 16-bit processors without MMUs, so it can be an embedded OS for tiny systems. It compiles on x86, x86_64, sparc, ppc, alpha, IBM mainframes of every kind, itanium, arm, mips, and even the OpenRISC open-source-design embedded processor.

But there *are* lots of alternative FLOSS systems in use, I think! One alternative that no one ever mentions, for some reason, is eCos. It's a modular RTOS for embedded systems. A lot of routers use it actually, I had an 802.11b router that was based on eCos. If you need real-time, and don't want the overhead of a "full" operating system, eCos seems like a great choice! (I haven't developed with it myself.)

DTrace is not "miles" beyond what linux has today (systemtap), it's inches. IBM and RedHat started implementing that functionality for linux over a year ago, and they're nearly finished (it works today, there's just some features missing).

ZFS is behind what linux has today - bolting a filesystem onto an lvm does not magically generate features that a system with a separate lvm and filesystem did not already have, but it does mean that they haven't managed to get group quotas working yet. Pretty much all of the other features in ZFS were implemented in linux first - although most sysadmins do not bother to deploy them.

Linux development does not happen "in your moms[sic] basement". If you pulled your head out of your kool-aid for long enough you might have noticed that it's mostly happening at IBM and RedHat, who have got more manpower on the problem than Sun's entire employee base, now that IBM have moved their focus from AIX to linux.

For any semi-pro work in this space, You'll have a dedicated development host (read PC) that runs EXACTLY the Linux distro that was supplied for (and together with) the SDK. Time is just to short to dick around and customize for 17 different linux distro's.

Case in point: I recently picked up an ARM5 development kit from Arcom. http://www.arcom.com/entry-level-devkit-linux-vipe r.htm and it came with a Fedora Core 5 DVD and an SDK for core 5. So I slapped the whole thing on an empty PC and was ready to rumble in an hour or two. I didn't even update the core 5 install (behind firewall etc.) in order make certain that the SDK was an exact fit.

That's (unfortunately) how You do it on a linux host. Otherwise You can take Your chances with the hell of CygWin and Windoze.

My point is: Chose one distro, ship it together with Your kit and make absolutely sure that it works 100%.

For what it's worth, I think Linux blows chunks as an embedded RTOS. It's too damn big and the real-time performance just isn't there. Go with http://ecos.sourceware.org/ (free), VxWorks or QNX.

This is Red Hat's list: http://www.redhat.com/opensourcenow/leadership/dev elopment.html
This is Red Hat's contributions according to the Fedora Project (gives more detail about Red Hat's role in projects) http://fedoraproject.org/wiki/RedHatContributions
This is just another list of different projects: http://sourceware.org/projects.html

A lot of people underestimate how much Red Hat does. They have significantly more code in the kernel than any other entity, they are also responsible for a very large part of the GCC development, and most of the recent big improvements in GCC can be attributed to Red Hat. They also do a ton of dev for Gnome and have done wonderful things with GCJ. People give them a lot of shit, but a lot of OSS development would slow down drastically if they were taken out of the equation.
Regards,
Steve

Although it's still in the early stages Red Hat is working on developing a pretty nice debugger http://sourceware.org/frysk/

Here is an article on it. Here project page.

What can dtrace do that systemtap cannot?

The closest linux equivalent is the Systemtap project, which is based on the kprobes low level hooking API. These aren't yet billed as ready for production systems, but they'll get there soon enough. They look quite slick, also.

That said, the WSJ award seems to me to be maybe a little overstated. While Sun fanboys will shout to the heavens (with some justification, even) that DTrace is an amazing tool with absolutely no counterpart in the linux world, the fact remains that DTrace is at best an incrementally amazing tool. System performance tuning is a hard task, requiring smart developers and lots of work. System performance tuning with DTrace is a hard task requiring smart developers and a little less work.

System performance tuning using DTrace and a typical Solaris IT wonk (a population that tends to correlate highly with the fanboys pushing DTrace the hardest) is a recipe for disaster.

If you find someone telling you that DTrace is a must have tool and indispensable to the systems developer, apply salt. But yeah, it's pretty slick.

Dtrace is CDDL so it probably can not be ported to Linux. But systemtap is a good alternative and pretty far along. http://sources.redhat.com/systemtap/wiki/Systemtap DtraceComparison

http://sourceware.org/systemtap/

Overview

SystemTap provides free software (GPL) infrastructure to simplify the gathering of information about the running Linux kernel. This assists diagnosis of a performance or functional problem. SystemTap eliminates the need for the developer to go through the tedious and disruptive instrument, recompile, install, and reboot sequence that may be otherwise required to collect data.

The recent addition of kprobes to the Linux kernel provides the needed support but is not easy to use. SystemTap provides a simple command line interface and scripting language for writing instrumentation for a live running kernel. Over time, we plan to enlarge our script "tapset" library to aid instrumentation reuse and abstraction. We also plan to support probing userspace applications. We are investigating interfacing Systemtap with similar tools such as Frysk, Oprofile and LTT.

http://sourceware.org/systemtap/
http://sourceware.org/frysk/

http://sourceware.org/systemtap/
http://sourceware.org/frysk/

You forgot some of the most important ones, namely they coded and maintain the entire 2.6 linux CPU Scheduler and the 2.6 Virtual Memory Manager. Yes, you can contribute a large part of 2.6's great performance to Red Hat. They also wanted an open source Java implementation so they started GCJ to compile java code natively. Open Source runs all the down from the top to bottom at Red Hat, even one of their VP's is the guy who originally coded the GNU C++ compiler. Here are two non-complete lists of other projects Red Hat either entirely codes and maintains, or contributes large portions of code to, keep in mind that they don't list everything: Sourceware Projects and Red Hat Contributions. This move by Red Hat has been given a bad spin by those reporting it, the Fedora Foundation's expenses and other requirements would have killed off Fedora, if anyone read the e-mail they'd see that as it is all clearly laid out including some numbers. Its good to see not everyone is buying into the sensationalist headlines and /. trolls though.
Regards,
Steve

A lightweight, open-source OS for embedded applications already exists: it's called eCos. Haven't used it myself, but from what I've read, it looks promising. YMMV, etc.