Slashdot Mirror

My guess is that the parent is trying to point out that Linux has filesystems like JFFS2, which try to prevent wear of sectors: http://sourceware.org/jffs2/jffs2-html/

Most flash cards (SmartMemory etc..) and USB thumb drives are nand based.

NTFS would be an obvious choice for microsoft to go with since it support removable media and journalling.
You wouldn't want to use standard journalling on a flash drive. IIRC for each write cycle at least 3 write actions are required: log in the journal that a write will be done (has to be synced to the disk), do the write, log in the journal that the write action ended successful. With flash, where you can only erase block-wise, this is not a good idea - for one its very slow, and on the other hand, the flash supports only so many write cycles. For journalling, special handling is needed as implemented e.g. in jffs2.

Heh, you severly underestimate Red Hat's contribution to the community:) Read this for a truncated list of contributions they've made. Some other products they've purchased and released include GFS, Cygwin, and eCos. They also contribute more code to the kernel than any other entity and in large part maintain and extend glib and GCC (they have a few people on the GCC board and contribute huge amounts of code, in fact many of the newest features in GCC 4.0.x you can thank Red Hat for). Here is another list, but that list is only for projects hosted from that site, so its not complete either, but suffice it to say that Red Hat does a staggering amount for the community, its kind of a shame when people bash them.
Regards,
Steve

Heh, you severly underestimate Red Hat's contribution to the community:) Read this for a truncated list of contributions they've made. Some other products they've purchased and released include GFS, Cygwin, and eCos. They also contribute more code to the kernel than any other entity and in large part maintain and extend glib and GCC (they have a few people on the GCC board and contribute huge amounts of code, in fact many of the newest features in GCC 4.0.x you can thank Red Hat for). Here is another list, but that list is only for projects hosted from that site, so its not complete either, but suffice it to say that Red Hat does a staggering amount for the community, its kind of a shame when people bash them.
Regards,
Steve

For one: I keep hearing people say that redhat contributes "Millions" to the open source community. Where?

And is it significant compared to the return they get on it?

Are they only doing it because it benifits them?

I know they pay the salaries of several people who are "RedHat employees", but really just kernel hack, but Millions?

Really?

For two: They DIDN'T EVEN WRITE THEIR DAMN SOFTWARE.

For one: I keep hearing people say that redhat contributes "Millions" to the open source community. Where?

And is it significant compared to the return they get on it?

Are they only doing it because it benifits them?

I know they pay the salaries of several people who are "RedHat employees", but really just kernel hack, but Millions?

Really?

For two: They DIDN'T EVEN WRITE THEIR DAMN SOFTWARE.

For one: I keep hearing people say that redhat contributes "Millions" to the open source community. Where?

And is it significant compared to the return they get on it?

Are they only doing it because it benifits them?

I know they pay the salaries of several people who are "RedHat employees", but really just kernel hack, but Millions?

Really?

For two: They DIDN'T EVEN WRITE THEIR DAMN SOFTWARE.

For one: I keep hearing people say that redhat contributes "Millions" to the open source community. Where?

And is it significant compared to the return they get on it?

Are they only doing it because it benifits them?

I know they pay the salaries of several people who are "RedHat employees", but really just kernel hack, but Millions?

Really?

For two: They DIDN'T EVEN WRITE THEIR DAMN SOFTWARE.

Aparently you need to stop reading the media and do a bit deeper research into what systemtap is and how unstable it is. You can start with Active Bug, non guru mode. That bug affects non-guru mode, which is supposed to be safe to use in production. Nothing like that ever happens in dtrace. Why you may ask? Because its developed to be safe in Production use at the expense of giving up some features. For a more indepth comparison of systemtap and its problems check out the links mentioned in my blog's SystemTap Links. Systemtap vs. dtrace the debate continues is a good place to start.

Of course, systemtap is still in its infancy, perhaps after a couple re-writes that seem standard in major components in the Linux Kernel, they can make it stable. But today its, not and any where near stable. There for your statement of "Linux has SystemTap, which goes above and beyond what DTrace is capable of. It is still in heavy development by Red Hat (Intel and IBM also helped start up the effort), and it's already quite a product." Is complete rubish. Of course one would have to think about. If its still under heavy development, also shows just how far from ready it is.

Of course, the truth really is that DTrace is far more feature rich than systemtap is, or will be for a long time. Systemtap biggest stumbling block is "guru mode" that allows the user to disable any protection that systemtap engineers have added. Systemtap's language is lacking in some basic concepts, like variable types like struct and typeset, making guru mode necessary for far too many scripts, and in-escapable when userland probes are created. Along with the other problems documented in my blogs.

You may try and dismiss me as a troll, but nothing could be farther from the truth. I'm stating the facts, I have also contributed to the Systemtap product, and commented on code changes. But I refuse to sit quietly as people try and pass Systemtap off as stable or better than DTrace. Dtrace is stable, and Enterprise Production ready and more full featured than Systemtap, even though they have left out features, that have to be worked around by the programmer.

A) All of those OSes are macro.

B) Linux has SystemTap, which goes above and beyond what DTrace is capable of. It is still in heavy development by Red Hat (Intel and IBM also helped start up the effort), and it's already quite a product.

Your post was one big troll, why do you find it amusing to spread random misinformation?

Regards,
Steve

Companies like Red Hat are packagers, not necessarily creators.

All of these projects are hosted on the Red Hat Sourceware site, Red Hat provides infrastructure support. Some of the projects are developed by Red Hat engineers, as official Red Hat projects. Many of them are maintained by Red Hat engineers on their own time, with the work on these projects done mostly by volunteers on the net.

"It would be nice if the various linux filesystem drivers could have a mount option that spread out writes"

Flash drives already do load leveling in hardware; they are after all, usually used with FAT.

For the few cases where you need to do it yourself, that's what JFFS2 is for.

The simple reason for that is that otherwise the kernel would be unpredictable. Let's say the error logging function used the string class (which likes to allocate memory behind your back). If the memory allocation function fails and tries to print an error message... you got yourself a kernel crash. This is why the kernel is significantly more difficult to program than, say, a word processor.

Put the strawman away. You don't absolutely have to use all the features C++ gives you if they aren't right for you. Don't use exceptions or run-time typing in an environment where you don't need it, or don't know if it'll work. Personally I never use either because I strongly disagree with the code they generate. If you don't understand that skilled usage of C++ generates exactly the same code that the equivalent C would (except the C++ took less time to type and checked your syntax better), you don't understand the point of C++ whatsoever. It's just a glorified type checking macro expander. And there's no reason to use plain C when you've got that at your disposal.

Now have a look at examples of kernels written in C++. One easy example: Red Hat eCos. Just saying that C++ doesn't do kernels well doesn't remove the fact that people do use it in kernels, it works very well, and there are many examples out there.

" So RedHat has dropped the desktop..."

I don't think they want to drop the coporate desktop. It seems that is where companies like MS made a lot of money. When Linux catches on there, I assume Redhat wants to be the cheaper alternative with a strong brand name.

Still, I suspect the embedded market is growing with healthly profit margins. Redhat has been interested in this market for a while. I think they bought eCos around 1999. It was already open source (they really bought Cygnus which developed eCos).

Surely you would measure the most popular RTOS by the number of developers or projects using the RTOS?

eCos has a uITRON compatabile API as well as a POSIX and native API, so I guess as a superset of ITRON it must be the most popular RTOS.

/me crawls back under a rock

Sorry, forgot the important screenshot:
Screenshot
From the documentation

Sorry, forgot the important screenshot:
Screenshot
From the documentation

I'm not trying to quibble here, for all intents and purposes it might have been Free.

I am not surprised that Red Hat and the FSF made this announcement as if it was their idea, since it was their agreement that eventually made this possible, but it was the eCos maintainers and community that wanted this to happen. The maintainers first negotiated with the FSF to accept public assignments of eCos after considering various alternatives, along with several requests to Red Hat to contribute the copyright to a not-for-profit organisation. You can read the start of the negotiations in the eCos maintainers mailing list here

In reality the eCos project was never discontinued as many incorrect postings suggest. The original developers formed eCosCentric to continue providing commercial support and the community using and supporting eCos continued to grow. The public version was also moved away to a sourceware address as Red Hat which was concentrating on Linux and the Linux Enterprise and moving away from the embedded space. (Red Hat still host the sourceware site which is also home for many other FSF and open source projects -gcc, gdb, gcj, etc - mostly from the Cygnus era.)

Red Hat effectively gave up control of eCos when it laid off the eCos group as the original developers and maintainers continued to work on eCos in the public version. With only 1 internal maintainer left to support existing customers, the public version of eCos soon surpassed the version held entirely by Red Hat. Rather than fork the code base or split copyright/ownership between Red Hat and the maintainers and to protect eCos against the SCO's of this world, the eCos mainatainers and community decided to push for Red Hat to assign ownership of eCos to the FSF. So the right thing for eCos finally happened IMNSHO :-)

I am not surprised that Red Hat and the FSF made this announcement as if it was their idea, since it was their agreement that eventually made this possible, but it was the eCos maintainers and community that wanted this to happen. The maintainers first negotiated with the FSF to accept public assignments of eCos after considering various alternatives, along with several requests to Red Hat to contribute the copyright to a not-for-profit organisation. You can read the start of the negotiations in the eCos maintainers mailing list here

In reality the eCos project was never discontinued as many incorrect postings suggest. The original developers formed eCosCentric to continue providing commercial support and the community using and supporting eCos continued to grow. The public version was also moved away to a sourceware address as Red Hat which was concentrating on Linux and the Linux Enterprise and moving away from the embedded space. (Red Hat still host the sourceware site which is also home for many other FSF and open source projects -gcc, gdb, gcj, etc - mostly from the Cygnus era.)

Red Hat effectively gave up control of eCos when it laid off the eCos group as the original developers and maintainers continued to work on eCos in the public version. With only 1 internal maintainer left to support existing customers, the public version of eCos soon surpassed the version held entirely by Red Hat. Rather than fork the code base or split copyright/ownership between Red Hat and the maintainers and to protect eCos against the SCO's of this world, the eCos mainatainers and community decided to push for Red Hat to assign ownership of eCos to the FSF. So the right thing for eCos finally happened IMNSHO :-)

The same one as there is now.

The linked page begins:

As of May 2002, eCos is released under a modified version of the well known GNU General Public License (GPL). The eCos license is officially recognised as a GPL-compatible Free Software License. An exception clause has been added which limits the circumstances in which the license applies to other code when used in conjunction with eCos. The exception clause is as follows:

As a special exception, if other files instantiate templates or use macros or inline functions from this file, or you compile this file and link it with other works to produce a work based on this file, this file does not by itself cause the resulting work to be covered by the GNU General Public License. However the source code for this file must still be made available in accordance with section (3) of the GNU General Public License.
This exception does not invalidate any other reasons why a work based on this file might be covered by the GNU General Public License.

Um, development has been ongoing, irrespective of Red Hat's loss of interest back at the start of 2002. There just hasn't been any big news since then. See the patch list for example.

The eCos maintainers (of which I'm one) have been pushing for a solution to the copyright issue for quite some time. It's good for everyone that Red Hat have donated eCos to the FSF.

I see on the eCos site a listing of support platforms, but can anyone point me to an actual project/product that used eCos?

Thanks in advance.

---anactofgod---