There is some truth in what you are saying. And for the most ugly POSIX functions, glibc does even provide "GNU extentions"; alternative functions which are a little less ugly.
However, I can't see how it would harm any standard when some of these functions just wouldn't crash "as would be expected", but instead just did their job "against all odds". I don't think preventing crashes would be a violation of standards:-)
A good example are these funcs that crash upon NULL input. They wouldn't crash if they used NULL as a signal like "hey, there's no value here".
Or at least I expect glibc to fail safely instead of accessing memory it shouldn't. That would make stuff much more secure AFAIK. And you wouldn't always need a debugger to tell where the crash was.
The only reason I could think of for not doing these checks, is speed, but concerning string functions, it might pay to trade speed for security.
I have to admit I never gave any of the *BSD's a serious try, although I do realize how most of their culture works and how this culture differs from Linux (which it does a lot: note how Theo didn't even *understand* there could be different versions of system utitities such as tar available for one system -- or did he fake that?:-).
But I have been compiling against the GNU C library a lot, and I loathe it for the most part. Examples? Examples.
- from man strcpy:
If the destination string of a strcpy() is not large enough (that is, if the programmer was stupid/lazy, and failed to check the size before copying) then anything might happen. Overflowing fixed length strings is a favourite cracker technique.
- from man strcat:
The strcat() function appends the src string to the dest string overwriting the `\0' character at the end of dest, and then adds a terminating `\0' character. The strings may not overlap, and the dest string must have enough space for the result.
Yes, I especially loathe the string functions. If you feed them too small buffers, or NULL pointers, glibc just plain old crashes. In my not so humble opinion, it is glibc's _responsability_ as a C library to be flexible enough to allocate that stupid little buffer itself, or at least not to crash with segmentation violences! If I do the same things with GTK+'s glib, my program fails with a nice message, like "assert string != NULL failed" -- but even more often, it just allocates that stupid little buffer!
Now before you're going to say "look, if you want someone to keep your hand, go play with Java, not with C", please realize that all this could just simply _work_ in C with a few checks, and that not a single line of code would need auditing for these "vulnerability" anymore, if only this check had been made in glibc! That's the use of programming libraries, right? Not having to do soemthing again and again, so that you work with well-known interfaces and do not run the risk of making much mistakes.
You know, even Richard Stallman, author of this particular C library, agrees with me upon this point:
- from info libc
It's fairly common for beginning C programmers to "reinvent the wheel" by duplicating this functionality in their own code, but it pays to become familiar with the library functions and to make use of them, since this offers benefits in maintenance, efficiency, and portability.
Now the only sad thing from this quote is that it actually comes from the part "Strings and Array Utilities" of info libc, about which _I_ would like to say "It's fairly common for beginning C programmers to become familiar with the library functions and make use of them, but it pays to duplicate this functionality in your own code" -- if you catch my drift;-)
Which makes me wonder how secure OpenBSD (and *BSD) is at the libc level, that is, how flexible and careful does it work with its input.
[Hmm and while I'm at it, is char++ endian-independent? Just wondering:-)]
In the past, you had to do so much manual stuff with WINE, that it took some skills to use it optimally. In theory, it could do everything I read it can do now, but it took some work: editing mime/ file types (or launching Windows programs from the CLI, like I mostly did), WINE config files, pointing to a Windows root, compiling WINE by hand, etc.
Now you can do all this within a few simple installation steps, find your Windows apps in your GNOME menu and simply launch them.
I think it is a great advantage and will drastically improve the acceptation of WINE (and as a result, Linux, of course). One might argue this isn't a substantial improvement to WINE, e.g. it might crash just as much as the current snapshot. I would argue that this is the coolest improvement as of yet!
I have exactly the same experiences as you have. Especially in my beginning years on Linux, I really wondered how it is that one can "contribute". Even though all this code is available and around, something keeps you from working on it, and you think it's lack of practical experience -- but how do you get pratical experience then?
For one thing, I think I didn't get much experience because I am a theoreticus; I love learning about algorithms etc., but when push comes to pull, I haven't written that much code as of yet.
I have been working with Linux for at least three years before I passed the "Hello, World!" phase, but meanwhile I learned everything from assembly boot block to GNOME programming, and as a result I can now say "Hello, World!" in a lot of languages;-)
It is only the last few months that I realize that I've read about every book in the school library and about every doc on UNIX programming, that I say to myself: "Stop doing theory. Act!" And now I am, actually, amazed at what I can. A few web sites I help on, needed a few scripts. I wrote one, and I found another on the web and enhanced it. I never before did Perl, but thanks to my basis, I learned it really quickly. Now, I've got myself a few toy projects in GNOME. Again, I never really coded in GNOME, and some parts aren't that intensely documented. But being eager to find things out, I made myself some test programs for a few GNOME libraries, and thanks to the clean-ness of my code, I had very little trouble combining them into one bigger program for my toy projects. Lots of more ideas are in my head.
So here's my advice: go out and play with the code! Give yourself a (small) task and then "just do it." Don't think it's hard: read docs, ask questions, and show yer code. It works, even though it may take time to get used to it.
Well, I am a little bit too young to have melancholies about the Gopher protocol (at least, I didn't have Internet access at the time when it was popular). But that makes me even more curious. So now I'm browsing around a little through these gopher:// links.
At one moment, I wanted to check something out on Slashdot again. Slashdot on Netscape. Slashdot in HTML. HTML with tables and pictures. Tables and pictures with Netscape. Pictures through my dialup connection...
Please, can't we have a Gopher interface to Slashdot?
Well, at least, the guy from the article said Gopher "can do". And I already discovered that Gopher can show HTML (but only where necessary please, otherwise it would just be re-inventing HTTP) and do forms stuff. Some thinking has to be done, however, in how to represent the user comments. Any ideas?
At first Whalen believed he had uncovered an original Poe text, even though a number of features, such as the heavy use of alliteration, were unlike Poe.
Heh, given that information, the title of this article isn't really accurate;-) Still, nice title, though!
It's... It's...
Whoa, yield brother! This isn't copyleft at all!
on
No Love For Darwin?
·
· Score: 1
OK, so you're obliged to give back your modifications to Apple. This doesn't make this stuff copylefted! Copylefted has got the underlying idea that code has got no owner. So-called "strong" copyleft adds "should stay Free" restrictions to this.
As this code never was anything near Free, it is far from copylefted. It's available under a restricted source code license, that's all.
It's... It's...
Re:(Yeah, well..) Darwin != Free, GNUStep is
on
No Love For Darwin?
·
· Score: 2
Well, the question wazzZ (this should read like an accent on "was"): why is Darwin not considered interesting?
And there I am, the FIRST in this whole Linux zealot community forum that simply clarifies: "because it's not Open Source".
Now that you all got nice Free click-and-drool GUI systems you suddenly have completely forgotten about the ideals that got you there in the first place. While *I* think that now that you actually _can_ point and drool with Linux, people would become more reluctant to demand true Freedom.
You wrote: The political rationalle behind "free" software doesn't really enter into Apple's reasons for releasing Darwin, so don't look for one, or even complain about Darwin not being free enough to satisfy you.
And earlier on, you wrote: And it's been what, 5-10 years, that work on GNUStep has been going on? How far along is it? Can it do any of the things which separate Mac OS X from NextStep? Will it ever?
To which I can only respond: The business rationale behind "finished" software doesn't really enter into GNU's reasons for releasing GNUStep, so don't look for one, or even complain about GNUStep not being finished enough to satisfy you. Never ever complain about Free Software, it's written without wanting anything from you in return. Just use it, or don't.
And I'll complain about propietary software whenever I want, thank you very much. Especially when it's misleadingly disguised as Open Source.
BTW, I can't remember to have shown you a photo of myself. You'd have noticed that my head is actually rather blocky, not anything like pointy at all, if I had. But your pointy head didn't see my cynicism when I talked about the Amazon licensing stuff, nooo. You'd rather ask about the age of the GNUStep project. Don't you know that that is generally considered not very polite, asking about someones age? And besides, it doesn't matter anything, too. The code base is there. You can use it and enhance it at wish. Err... I wasn't stuttering when I said that the first time around, now was I?
The Hurd has got lots of advantages over "common" kernels. There is some thingy which allows you to... Oh well. I have explained this once before here, go read for yourself instead, on the Debian GNU/ Hurd page. These pages are where the action is today. The GNU Hurd page is only some static placeholder page. Granted, traffic on the major Hurd development list isn't like linux-kernel, but there sure is work going on there.
I have to agree with some more FSF-cynic people here that the HURD indeed does resemble any other "My Own Featureful Kernel" kind of project, and if this one wasn't supported by the most influential Free Software Foundation, it would have been bleeding to death years ago. I mean, the historical mails from Linux Torvalds, wherein he announces the Linux kernel, are already cynical about the release date of the HURD (first he says "within a few months or so", in later mails he starts with "end of this year, age, millenium"-like suggestions). That reminds me a little bit of Paul stating in the Bible that "the End of the World is Nigh" -- words which are 2000 years old now. If it ("it" being the End of the World, or the HURD, or even both at once - whee:-) wasn't anywhere near "Nigh" way back then, then why should we expect it now?
Then again, one never knows what comes of a Free project. It may lay slumbering for years, then maybe development is suddenly picked up by an interested group o' people (like Debian).
Oh, and I'm interested, too. I recently tried it. After a night of downloading and installation (which is a smooth, automated process that only requires you to run a few scripts and mount a device as/gnu) that went quite OK, I rebooted with a GRUBbed floppy and found that the kernel hung. Shoot. After some discussion on the mailing list, they found that it was probably my ISA ne2000 card that hung the system.
(At this point, a cynic would say two things: first: "an ne2000 card is about the first thing one would have supported", and second: "one of the advantages of a microkernel should be that its modular design would allow for the system not to hang when one driver fails", right?
I wasn't interested in being cynical, I never really am with Free Software. If it's crap, don't complain -- just don't use it, or make it better. You got it for free, and, unlike promotional material, the givers don't want anything from you in return.)
The folks from the HURD came up with a few solutions. Some of them involved fooling around in the sources and stuff and didn't seem proven solutions. Another option was to plug the ISA card out. While I'm not very fond of fooling around with hardware, I decided to do the last thing.
There went the HURD, passing the network card detection part as if it were a simple bend in the road, but then it suddenly crashed into a problem as if it were a trailer that was parked just around that bend. This time I got a real kernel error, not just a message-less halt. The idea behind this crash was that the HURD found way too little main memory on my system.
So I posted a new message to hurd-help, stating "problem solved, long live the problem", but this one didn't seem to get very much response. (The other message, AFAIK, resulted in some modifications in the network card detection stuff, but as you might know, it's very hard to autodetect an ISA ne2000 card, so I don't expect to see a really "smooth solution" unless, as with Linux, the "kickstart system" doesn't require all hardware to be detected and stuff.)
So for now, no, I haven't used HURD. Might check again later, but I don't want to disappoint myself for now, as I don't think that my current problems are now suddenly all solved. Even if the HURD will never come near stable, there's one thing that's good about it, and that's competition. Cool features and concepts can only inspire us all to make software better, just like Linux "inspired" Microsoft to do better, and GNOME and KDE inspire each other. And the HURD does have cool concepts (and probably features as well;-).
It's... It's...
(Yeah, well..) Darwin != Free, GNUStep is
on
No Love For Darwin?
·
· Score: 3
Darwin is covered by the Apple Public Source License, to which the Free Software Foundation has dedicated a whole page, and that's not because they like it. The OSI had been very mistaking in calling this stuff "Open Source". Remember that such an Apple license can be retracted any time you have a patent conflict with Apple.
And, let's figure, who doesn't?
Wasn't apple that company that bought rights to the one-click shopping "patent" from Amazon.com, and showed they were even proud of that? (Actually this is a rhetorical question, never bother replying "yes, they were".) So if you own anything of a Website with a shopping interface which is just a little bit too easy, you can't use Darwin. Sucks, right?
So I don't give for MacOS X, and I think that anyone who codes for MacOS X in his spare time isn't helping out anybody but Apple. Apple owns this code. No-one (and then again, everyone) owns Free Software.
If you think that the MacOS concepts are cool, you'd be glad to hear that they are modeled after the open OpenStep standard. And if you want to work on a Free OpenStep implementation, go work on GNUStep.
Yes, there are differences with MacOS X (and NextStep):
Binary incompatibility (due to compiler issues and to undocumented resource file formats in the OpenStep specification)
Works on top of the X Window System instead of its own graphics thingies
Follows the NextStep look & feel
Not Out Of Beta Yet (doh, the only NS implementation that
is
Out Of Beta is Out Of Print as well;-)
However, this particular implementation is Free so you can modify it any way you want, keep your modifications private when you only use it yourself, and there is no single instance that can demand strange things for you. Making GNUStep appear like MacOS X might even be considered a doable task (though I don't intend to say it's simple), though walking away from X must be much harder. And anyone can help getting this stuff Out Of Beta.
So if you want to develop a Free MacOS X, GNUStep is a really good place to start from. I simply hope that by the time MacOS X is released, the headlines will look like "GNUStep: a better MacOS X than MacOS X":-)
People just get interested, that's all. They want to know if they can toy with this cool thingy without screwing up their harddrives forever. Seems reasonable to me;-) Because not many people have a good answer, the question is asked again and again.
I simply think that, as it is still in beta, and the folks from Plex86 didn't make any official beta-releases, it should not be considered stable for *anyone* who cares about that. I have the impression that the Plex86 guys know perfectly well when it's safe to make a first beta-release, and I guess that by that time they will have a more thorough statement on the stability. It's just too early for them to care about end-users.
Dehmm... the above paragraph represents *my impressions* of the project, and these aren't based on proper references, OK? Still, I think it's reasonable to ask "hey, can we try this out safely yet?"
> Has anyone tried writing a complete virtual
> processor/virtual peripheral system that performs
> dynamic binary translation between instruction
> sets?
Doink... You've just reinvented Java (or Smalltalk), including the pre-compiler (this is called a Jitter, a Just-In-Time Compiler). And take a look at Transmeta's Crusoe (OK, I read you did this already), and to the new Amiga (which is to become a mix between Java and the Crusoe).
Good thinking, but these days it's just hard to invent something that is *really* new;-)
It's already opted how you can make "completely" secured virtual servers with this, use the advantages of Solaris together with those of Linux, etc. Another great use should be Linux advertising: now you could run "Linux for Windows" without even having to leave Windows, or run your favorite games in Linux.
Everyone is entitled the right to have his own projects, whether they're useful or not. Actually I think that every project *does* "make the current OSes better", because every project is the "killer app" for yet another group of people, no matter how select.
So the attractive thing about Linux is not that it has one "killer app", but that it has "for everyone his own killer app", a.k.a. choice and variety. You can't get that better.
I thought it was always not done to critisize Open Source developments. Netscape gave you the opportunity to compete with them, if they are not good enough for you. They even GPL this baby right now.
So, if you don't like it, GO FORK. Otherwise, stop complaining about this project. That's how simple things have been in Open Source projects, so why is this one different?
OK, there is some sense in showing your dislike. People need to get a little slap in their face sometimes. You can file a bug for that. But if you just plain old complain, and start threatening "I'll go back to Microsoft, I really will", I must say that I can only have a good laugh about that:-)
I don't understand why people feel uncomfortable with this. Indeed, as is said in another reply already, even Linus Torvalds doesn't like the idea that the GPL can be dynamically altered.
The current GPL clearly states that any newer versions will be in the same spirit, but that it may simply solve some problems with the current version, or make some vague sections more clear. Now, that's what we need! If someone detects a Great Big Hole in the GPL, the statement "or any newer version" is the only way how this can be plugged: by issuing a better version!
Even if Microsoft buys the Free Software Foundation (why hasn't this happened yet, anyway), then they're still obliged to keep the GPL in the same spirit as it is as of today.
I don't know how legally clear a line like "in the same spirit" is, however. But hey, maybe GPL v3 will be a little more clear about this;-)
OK, this is only a Slashdot post. I don't dare to post it to rms@gnu.org (or whatever his email adress is) because I guess mr. Stallman is a kind of a busy guy, and I don't want to concern him with this if it's not his choice to be concerned with it.
But what I'd really like to hear, is how many/. folks agree with this opinion, or disagree. (Patches are welcome, too;-) If this turns out to be a more or less important point, we might send it to mr. Stallman after all.
Anyway, here goes.
------8<------
Dear mr. Stallman,
It has occured to me that you are trying hard to make clear to the GNU/ Linux community, as well as the outside world, what "Free Software" is, and why it is good. You do this by writing so-called "Free Software" yourself, as well as propagating the use of the terms "Free Software" and "GNU/ Linux".
I won't discuss the use of the latter term in detail here; it would be an interesting, but not so important discussion about whether the term "GNU/ Linux" is accurate enough to describe any currently running distribution - but above all, the use of this term is a good advertisement for the FSF, and as such, it can only do good.
But I strongly disagree with the widespread use of the former term, the term that you seem wish to be used, more than any other term: "Free Software". I think it does _not_ serve as an advertisement for the FSF case, at all. Allow me to explain why.
You have noticed that "Free Software" easily gets confused with "Open Source Software" by the public, and you try to get rid of that confusion by stressing upon the strict use of the term "Free Software" when referring to GNU licensed software. However, I think that the main reason why people don't use the term "Free Software" too often, and rather fall back to the (more general) term "Open Source", is because the term "Free Software" is extremely confusing to outsiders. It gets confused with "free as in beer" and "freeware" way too easily.
Some people try to clear things up by saying "libre", "liberated", etc. instead. But because there isn't a clear party propagating the use of these words, they are not used by a significant lot of people. So the undecisive amongst the purists still fall back to "Open Source" *by lack of a better term*.
I support this fallback completely. Allow me to illustrate why I think that using the term "Free Software" does more harm than it can do good:
- Newcomers to GNU/ Linux are often also newcomers to the world of (freely available) source code. They can't interpret the term "F.S." correctly, because of a complete lack of context. Lots of folks can't understand what "software" and "freedom" could possibly have in common. They have never seen a line of code in their life. Sow how to make clear to these people that they have the freedom of getting, modifying and redistributing the so-called "source code"? Saying that the software is "free" just doesn't do that trick; saying it's "Open Source" does, but you don't like this term because it is often used in a more general context.
- Most people don't have your degree of software idealism. I imagine that when you use the term "Free", you mean "Free as in speech" in 90% of the cases. However, for most other people, "Free" most often means "free as in beer" - it's just inherent to our commercial society. So this word turns out to be more confusing for most common people, than you might imagine. It might inspire them to go shopping, but it doesn't really inspire them to change the world for the better, as I believe is your wish.
- As a result of both points, when I explain to someone that "I solely use Free Software", he might respond with "Cool. Well, I got my copy of Internet Explorer as a free download, too."
Well, I am not claiming to tell you something new here. But if you care about people using the correct terms (and, as a result, get inspired by your idealism) as much as you do, it is *really* important to use a less obfuscating term. If you continue to use the term "Free Software", I think you'll be making your mission unnecessarily hard.
But if you manage to come up with a much more descriptive term, I think that the word will spread like it has never done before. I understand that it's very hard to change such a thing right here, right now, but I think that it is not yet too late, and, as I explained, I think it would really serve your mission, while the current term does more harm than it does good. Additionally, you are the right person in the right place to do this. (Yup, I think your influence in the GNU/ Linux world is bigger than you think -- it's only because of the term that you don't see references to the FSF that much nowadays;-)
(I personally like to use the term "copylefted": it's funny, it's used by the FSF already, and it's very descriptive too - it makes clear that the software is public property, and that the copyright owners do not place restrictions on it, except that no-one else can place these restrictions. However, I don't want to make a real proposal for better a term at this stage, so it should only be interpreted as an example.)
Well, here in Holland, there's only one kinda frequent M$ advertisement. It is on radio and TV, and all it does is...
...remind you that you have to pay for Windows!
Yes, I am serious. All the commercial says is "if you install software on multiple machines, you must not forget to pay up multiple licenses". It's presented as if this is a general rule for software, but the images in the TV commercial make clear that this is a Microsoft commercial.
Actually, some folks on http://www.nl.linux.org/ seem to have complained to the Commision of Advertisements about this. Just for the record, I guess.
It doesn't really irritate me that it is suggested that you have to pay licenses for all software. What does irritate me is that this seems to be all the advertisement M$ needs. I never managed to get rich of saying "hey, you, give me loads of money, and don't complain about it", so why should they.
It's... It's...
because it's only available as unstable on i386 ye
on
HURD For 'Big Iron'?
·
· Score: 5
The Hurd rocks, but it's not "rock solid". And not yet ported to anything else but i386, according to what I've heard. I had troubles installing it; first my ne2000 card gave troubles, then something as yet unidentified went wrong.
Added to this, it's a microkernel system. Big Iron doesn't need microkernels. They're a little bit slower by nature, but you get the advance of a small, configurable "mostly user-space" kernel. That's pretty cool for palmtops and everyday PC's but not Big Iron, I'd say. That's why QNX doesn't run on mainframes.
If Linux can't do the "big iron" thing, I think BSD would be a more serious alternative for now. NetBSD runs on almost every platform, so its kernel should be portable. And I hear rumours that BSD can do some things that Linux can't as of yet. (And vice versa, of course; that's not the issue. The issue is, maybe BSD will just be able to do the trick.)
GNU's Not Unix: this sentence is more important than you may think.
The HURD microkernel can be set up to listen to POSIX if you wish, but it can also listen to other stories. So here's a possibility to move away from ugly ol' POSIX in a decent manner, without having to completely abandon the ship like e.g. BeOS does, providing only POSIX as a portability layer.
The HURD microkernel allows you to mount filesystems in a "new, radical" way which takes away the requirement of seperate "/usr" dirs, etc. (The mounted fs will be mapped on top of the current one, IIRC.) The HURD microkernel allows for user space device drivers and kernel modules, which I think can in the end make the "UNIX experience" a lot less harder.
So I think that when it's finished, the HURD will be there for the common people and will supply more ease of use and programming freedom than Linux or BSD do now, because it's very flexible and can be set up very friendly towards the user (in my imagination, anyway). It will slowly move to liberate us from the less nice UNIX inheritance, as well.
But I simply do not think that Big Iron is a target of the HURD.
But I'm not very afraid about Linux loosing Big Iron. All we need is an open source kernel (isn't Caldera opening UnixWare?) for it. I don't care if it's a fork, has a different name or implementation. That's what standards are good for. All the tools and gears are here already, so it would be "easy" for e.g. Debian to make a Big Iron port, just as they did a Hurd and FreeBSD port once.
When talking about what came first: the chicken or the egg, GCC is definitely the egg and GNU is the chicken. (See also the picture on gcc.gnu.org.)
Without GCC, there wouldn't be much Free Software around. Even non-GNUish Open Source projects (most namely BSD) use GCC. Even interpreted languages use GCC, as their interpreter is often compiled:-) , etc.
GNU software with a >= 1.0 version number is usually well-thought-of and extremely reliable. To name a simple instance, I think that for the most UNIX utilities, the GNU versions just work better than e.g. Solaris or BSD versions. GNU tar's -z option rocks, as does the option parse system of e.g. ls , so that you can write ls foo -l as well. Bash is also an example of a solid piece of GNU software.
You'd think that these FSF "rock solid" GNU folks would be more careful about the "egg" of their project, GCC. But what do I hear here? Buggy "stable" releases, binary incompatibilities between minor releases which are only resolved by incompatible fixes for a new major release... It's kind of a mess.
I've also got the impression that with glibc the same issues arise, but I might be wrong.
How can we have closed source vendors run to open source systems when things are like this?
Of course there is a single website for GNOME. Of course there is a single person managing the Linux kernel. Of course there is only _one_ Nautilus app.
But if I want to add something to GNOME, I write what _I_ want and offer it to the community. GNOME may or may not accept it into its core, but that's valid: GNOME is the "market visitor", picking out what it likes. If I have a patch for the Linux kernel, I offer it at the mailing list. Linux visits the "marketplace" and picks out the good stuff.
I've seen people "playing marketplace" with their GNOME stuff. A good instance is Galeon; it is not accepted at the GNOME core, but it is very popular amongst individual "visitors". I've seen people offering their stuff at linux-kernel; some of their stuff is accepted, some of their stuff is rejected by Linus but remains a seperate patch. I've seen someone offering to write Samba support for GNOME-VFS, at which the Nautilus folks responded: "that would be great". I've seen distro's choose between package formats. Etc., etc.
Now, if this isn't a marketplace...
Of course there are project managers, but all they really do is "shop". And everyone is free to offer their goods. Never, ever, does a project manager tell somebody what to do in the Open Source world; instead, they only say "I'd like to have this, if there's someone who implements it, I'd be grateful". If there's no-one implementing it, it's not going to be there.
Go look at some Open Source projects' FAQ's, you'll often find these two:
Q.: When will it be finished?
A.: Depends on your input:-)
Q.: Will there be feature X?
A.: No-one is working on it, but you are welcome to do it.
'nuff said, right? A project is nothing more than a "market visitor", that says what it needs and where it should go. The "market people" then can make their offers.
Well, the U.S. of A. is known to have a picky government... I think that you should simply become (or -- claim that you are) a civilian of a country that doesn't care about what you're doing, and where the folks that should become angry from your software don't live. Just like they do with code with US export restrictions.
The simple way to get an idea of the difference is this:
- Linux does fully preemptive multitasking, which means that CPU time is shared by multiple processes, that each process gets his part, and that if some process waits (e.g. for I/O), his "part" will be used to run other processes in. So all in all, this is a fine "time-sharing system".
- The kernel however, doesn't do this internally (yet!). If you do a kernel call, e.g. write to a device, the kernel call is the _only_ thing that runs at that moment. If it has to wait for something, it just _waits_. Only after the call has returned, Linux starts looking at the scheduling system again.
A fully preemptive kernel means (anyway in this context), that it is also preemptive internally, so if kernel code has to wait for something, other tasks can be performed. As you might understand, a fully preemptive kernel must be _very_ sophisticated. I'm glad we're gonna get it (well, if Linus permits it, anyway;-), and hats off for the developers!
Slashdot Mirror
There is some truth in what you are saying. And for the most ugly POSIX functions, glibc does even provide "GNU extentions"; alternative functions which are a little less ugly.
:-)
However, I can't see how it would harm any standard when some of these functions just wouldn't crash "as would be expected", but instead just did their job "against all odds". I don't think preventing crashes would be a violation of standards
A good example are these funcs that crash upon NULL input. They wouldn't crash if they used NULL as a signal like "hey, there's no value here".
Or at least I expect glibc to fail safely instead of accessing memory it shouldn't. That would make stuff much more secure AFAIK. And you wouldn't always need a debugger to tell where the crash was.
The only reason I could think of for not doing these checks, is speed, but concerning string functions, it might pay to trade speed for security.
It's... It's...
I have to admit I never gave any of the *BSD's a serious try, although I do realize how most of their culture works and how this culture differs from Linux (which it does a lot: note how Theo didn't even *understand* there could be different versions of system utitities such as tar available for one system -- or did he fake that? :-).
;-)
:-)]
But I have been compiling against the GNU C library a lot, and I loathe it for the most part. Examples? Examples.
- from man strcpy:
If the destination string of a strcpy() is not large enough (that is, if the programmer was stupid/lazy, and failed to check the size before copying) then anything might happen. Overflowing fixed length strings is a favourite cracker technique.
- from man strcat:
The strcat() function appends the src string to the dest string overwriting the `\0' character at the end of dest, and then adds a terminating `\0' character. The strings may not overlap, and the dest string must have enough space for the result.
Yes, I especially loathe the string functions. If you feed them too small buffers, or NULL pointers, glibc just plain old crashes. In my not so humble opinion, it is glibc's _responsability_ as a C library to be flexible enough to allocate that stupid little buffer itself, or at least not to crash with segmentation violences! If I do the same things with GTK+'s glib, my program fails with a nice message, like "assert string != NULL failed" -- but even more often, it just allocates that stupid little buffer!
Now before you're going to say "look, if you want someone to keep your hand, go play with Java, not with C", please realize that all this could just simply _work_ in C with a few checks, and that not a single line of code would need auditing for these "vulnerability" anymore, if only this check had been made in glibc! That's the use of programming libraries, right? Not having to do soemthing again and again, so that you work with well-known interfaces and do not run the risk of making much mistakes.
You know, even Richard Stallman, author of this particular C library, agrees with me upon this point:
- from info libc
It's fairly common for beginning C programmers to "reinvent the wheel" by duplicating this functionality in their own code, but it pays to become familiar with the library functions and to make use of them, since this offers benefits in maintenance, efficiency, and portability.
Now the only sad thing from this quote is that it actually comes from the part "Strings and Array Utilities" of info libc, about which _I_ would like to say "It's fairly common for beginning C programmers to become familiar with the library functions and make use of them, but it pays to duplicate this functionality in your own code" -- if you catch my drift
Which makes me wonder how secure OpenBSD (and *BSD) is at the libc level, that is, how flexible and careful does it work with its input.
[Hmm and while I'm at it, is char++ endian-independent? Just wondering
It's... It's...
Wow!
In the past, you had to do so much manual stuff with WINE, that it took some skills to use it optimally. In theory, it could do everything I read it can do now, but it took some work: editing mime/ file types (or launching Windows programs from the CLI, like I mostly did), WINE config files, pointing to a Windows root, compiling WINE by hand, etc.
Now you can do all this within a few simple installation steps, find your Windows apps in your GNOME menu and simply launch them.
I think it is a great advantage and will drastically improve the acceptation of WINE (and as a result, Linux, of course). One might argue this isn't a substantial improvement to WINE, e.g. it might crash just as much as the current snapshot. I would argue that this is the coolest improvement as of yet!
It's... It's...
I have exactly the same experiences as you have. Especially in my beginning years on Linux, I really wondered how it is that one can "contribute". Even though all this code is available and around, something keeps you from working on it, and you think it's lack of practical experience -- but how do you get pratical experience then?
;-)
For one thing, I think I didn't get much experience because I am a theoreticus; I love learning about algorithms etc., but when push comes to pull, I haven't written that much code as of yet.
I have been working with Linux for at least three years before I passed the "Hello, World!" phase, but meanwhile I learned everything from assembly boot block to GNOME programming, and as a result I can now say "Hello, World!" in a lot of languages
It is only the last few months that I realize that I've read about every book in the school library and about every doc on UNIX programming, that I say to myself: "Stop doing theory. Act!" And now I am, actually, amazed at what I can. A few web sites I help on, needed a few scripts. I wrote one, and I found another on the web and enhanced it. I never before did Perl, but thanks to my basis, I learned it really quickly. Now, I've got myself a few toy projects in GNOME. Again, I never really coded in GNOME, and some parts aren't that intensely documented. But being eager to find things out, I made myself some test programs for a few GNOME libraries, and thanks to the clean-ness of my code, I had very little trouble combining them into one bigger program for my toy projects. Lots of more ideas are in my head.
So here's my advice: go out and play with the code! Give yourself a (small) task and then "just do it." Don't think it's hard: read docs, ask questions, and show yer code. It works, even though it may take time to get used to it.
It's... It's...
Well, I am a little bit too young to have melancholies about the Gopher protocol (at least, I didn't have Internet access at the time when it was popular). But that makes me even more curious. So now I'm browsing around a little through these gopher:// links.
At one moment, I wanted to check something out on Slashdot again. Slashdot on Netscape. Slashdot in HTML. HTML with tables and pictures. Tables and pictures with Netscape. Pictures through my dialup connection...
Please, can't we have a Gopher interface to Slashdot?
Well, at least, the guy from the article said Gopher "can do". And I already discovered that Gopher can show HTML (but only where necessary please, otherwise it would just be re-inventing HTTP) and do forms stuff. Some thinking has to be done, however, in how to represent the user comments. Any ideas?
It's... It's...
See my comments on Debianplanet:
m l
:-)
Deeehhh.... December issue?
Here's a link to this article from Slashdot, posted on 1 November:
http://slashdot.org/articles/00/11/01/1326225.sht
I thought I knew this article already
It's... It's...
At first Whalen believed he had uncovered an original Poe text, even though a number of features, such as the heavy use of alliteration, were unlike Poe.
Heh, given that information, the title of this article isn't really accurate ;-) Still, nice title, though!
It's... It's...
OK, so you're obliged to give back your modifications to Apple. This doesn't make this stuff copylefted! Copylefted has got the underlying idea that code has got no owner. So-called "strong" copyleft adds "should stay Free" restrictions to this.
As this code never was anything near Free, it is far from copylefted. It's available under a restricted source code license, that's all.
It's... It's...
And there I am, the FIRST in this whole Linux zealot community forum that simply clarifies: "because it's not Open Source".
Now that you all got nice Free click-and-drool GUI systems you suddenly have completely forgotten about the ideals that got you there in the first place. While *I* think that now that you actually _can_ point and drool with Linux, people would become more reluctant to demand true Freedom.
You wrote:
The political rationalle behind "free" software doesn't really enter into Apple's reasons for releasing Darwin, so don't look for one, or even complain about Darwin not being free enough to satisfy you.
And earlier on, you wrote:
And it's been what, 5-10 years, that work on GNUStep has been going on? How far along is it? Can it do any of the things which separate Mac OS X from NextStep? Will it ever?
To which I can only respond:
The business rationale behind "finished" software doesn't really enter into GNU's reasons for releasing GNUStep, so don't look for one, or even complain about GNUStep not being finished enough to satisfy you. Never ever complain about Free Software, it's written without wanting anything from you in return. Just use it, or don't.
And I'll complain about propietary software whenever I want, thank you very much. Especially when it's misleadingly disguised as Open Source.
BTW, I can't remember to have shown you a photo of myself. You'd have noticed that my head is actually rather blocky, not anything like pointy at all, if I had. But your pointy head didn't see my cynicism when I talked about the Amazon licensing stuff, nooo. You'd rather ask about the age of the GNUStep project. Don't you know that that is generally considered not very polite, asking about someones age? And besides, it doesn't matter anything, too. The code base is there. You can use it and enhance it at wish. Err... I wasn't stuttering when I said that the first time around, now was I?
It's... It's...
I am sure I wrote Linus Torvalds there, not Linux Torvalds! But it's right there, the "x"...
;-)
I hate it when people make that mistake, yet appearently, I do it myself as well. Writing "Linux" has become a habit like writing your own name...
Another reason to step to the HURD; you can't confuse it with the name of its initiator
It's... It's...
I have to agree with some more FSF-cynic people here that the HURD indeed does resemble any other "My Own Featureful Kernel" kind of project, and if this one wasn't supported by the most influential Free Software Foundation, it would have been bleeding to death years ago. I mean, the historical mails from Linux Torvalds, wherein he announces the Linux kernel, are already cynical about the release date of the HURD (first he says "within a few months or so", in later mails he starts with "end of this year, age, millenium"-like suggestions). That reminds me a little bit of Paul stating in the Bible that "the End of the World is Nigh" -- words which are 2000 years old now. If it ("it" being the End of the World, or the HURD, or even both at once - whee :-) wasn't anywhere near "Nigh" way back then, then why should we expect it now?
Then again, one never knows what comes of a Free project. It may lay slumbering for years, then maybe development is suddenly picked up by an interested group o' people (like Debian).
Oh, and I'm interested, too. I recently tried it. After a night of downloading and installation (which is a smooth, automated process that only requires you to run a few scripts and mount a device as /gnu) that went quite OK, I rebooted with a GRUBbed floppy and found that the kernel hung. Shoot. After some discussion on the mailing list, they found that it was probably my ISA ne2000 card that hung the system.
(At this point, a cynic would say two things: first: "an ne2000 card is about the first thing one would have supported", and second: "one of the advantages of a microkernel should be that its modular design would allow for the system not to hang when one driver fails", right? I wasn't interested in being cynical, I never really am with Free Software. If it's crap, don't complain -- just don't use it, or make it better. You got it for free, and, unlike promotional material, the givers don't want anything from you in return.)
The folks from the HURD came up with a few solutions. Some of them involved fooling around in the sources and stuff and didn't seem proven solutions. Another option was to plug the ISA card out. While I'm not very fond of fooling around with hardware, I decided to do the last thing.
There went the HURD, passing the network card detection part as if it were a simple bend in the road, but then it suddenly crashed into a problem as if it were a trailer that was parked just around that bend. This time I got a real kernel error, not just a message-less halt. The idea behind this crash was that the HURD found way too little main memory on my system.
So I posted a new message to hurd-help, stating "problem solved, long live the problem", but this one didn't seem to get very much response. (The other message, AFAIK, resulted in some modifications in the network card detection stuff, but as you might know, it's very hard to autodetect an ISA ne2000 card, so I don't expect to see a really "smooth solution" unless, as with Linux, the "kickstart system" doesn't require all hardware to be detected and stuff.)
So for now, no, I haven't used HURD. Might check again later, but I don't want to disappoint myself for now, as I don't think that my current problems are now suddenly all solved. Even if the HURD will never come near stable, there's one thing that's good about it, and that's competition. Cool features and concepts can only inspire us all to make software better, just like Linux "inspired" Microsoft to do better, and GNOME and KDE inspire each other. And the HURD does have cool concepts (and probably features as well ;-).
It's... It's...
And, let's figure, who doesn't?
Wasn't apple that company that bought rights to the one-click shopping "patent" from Amazon.com, and showed they were even proud of that? (Actually this is a rhetorical question, never bother replying "yes, they were".) So if you own anything of a Website with a shopping interface which is just a little bit too easy, you can't use Darwin. Sucks, right?
So I don't give for MacOS X, and I think that anyone who codes for MacOS X in his spare time isn't helping out anybody but Apple. Apple owns this code. No-one (and then again, everyone) owns Free Software.
If you think that the MacOS concepts are cool, you'd be glad to hear that they are modeled after the open OpenStep standard. And if you want to work on a Free OpenStep implementation, go work on GNUStep.
Yes, there are differences with MacOS X (and NextStep):
- Binary incompatibility (due to compiler issues and to undocumented resource file formats in the OpenStep specification)
- Works on top of the X Window System instead of its own graphics thingies
- Follows the NextStep look & feel
- Not Out Of Beta Yet (doh, the only NS implementation that
;-)
However, this particular implementation is Free so you can modify it any way you want, keep your modifications private when you only use it yourself, and there is no single instance that can demand strange things for you. Making GNUStep appear like MacOS X might even be considered a doable task (though I don't intend to say it's simple), though walking away from X must be much harder. And anyone can help getting this stuff Out Of Beta.- is
Out Of Beta is Out Of Print as wellSo if you want to develop a Free MacOS X, GNUStep is a really good place to start from. I simply hope that by the time MacOS X is released, the headlines will look like "GNUStep: a better MacOS X than MacOS X" :-)
It's... It's...
People just get interested, that's all. They want to know if they can toy with this cool thingy without screwing up their harddrives forever. Seems reasonable to me ;-) Because not many people have a good answer, the question is asked again and again.
I simply think that, as it is still in beta, and the folks from Plex86 didn't make any official beta-releases, it should not be considered stable for *anyone* who cares about that. I have the impression that the Plex86 guys know perfectly well when it's safe to make a first beta-release, and I guess that by that time they will have a more thorough statement on the stability. It's just too early for them to care about end-users.
Dehmm... the above paragraph represents *my impressions* of the project, and these aren't based on proper references, OK? Still, I think it's reasonable to ask "hey, can we try this out safely yet?"
Greets!
It's... It's...
> Has anyone tried writing a complete virtual
;-)
> processor/virtual peripheral system that performs
> dynamic binary translation between instruction
> sets?
Doink... You've just reinvented Java (or Smalltalk), including the pre-compiler (this is called a Jitter, a Just-In-Time Compiler). And take a look at Transmeta's Crusoe (OK, I read you did this already), and to the new Amiga (which is to become a mix between Java and the Crusoe).
Good thinking, but these days it's just hard to invent something that is *really* new
It's... It's...
"If you don't like it, don't use it."
It's already opted how you can make "completely" secured virtual servers with this, use the advantages of Solaris together with those of Linux, etc. Another great use should be Linux advertising: now you could run "Linux for Windows" without even having to leave Windows, or run your favorite games in Linux.
Everyone is entitled the right to have his own projects, whether they're useful or not. Actually I think that every project *does* "make the current OSes better", because every project is the "killer app" for yet another group of people, no matter how select.
So the attractive thing about Linux is not that it has one "killer app", but that it has "for everyone his own killer app", a.k.a. choice and variety. You can't get that better.
It's... It's...
So, if you don't like it, GO FORK. Otherwise, stop complaining about this project. That's how simple things have been in Open Source projects, so why is this one different?
OK, there is some sense in showing your dislike. People need to get a little slap in their face sometimes. You can file a bug for that. But if you just plain old complain, and start threatening "I'll go back to Microsoft, I really will", I must say that I can only have a good laugh about that :-)
Weenies.
It's... It's...
I don't understand why people feel uncomfortable with this. Indeed, as is said in another reply already, even Linus Torvalds doesn't like the idea that the GPL can be dynamically altered.
;-)
The current GPL clearly states that any newer versions will be in the same spirit, but that it may simply solve some problems with the current version, or make some vague sections more clear. Now, that's what we need! If someone detects a Great Big Hole in the GPL, the statement "or any newer version" is the only way how this can be plugged: by issuing a better version!
Even if Microsoft buys the Free Software Foundation (why hasn't this happened yet, anyway), then they're still obliged to keep the GPL in the same spirit as it is as of today.
I don't know how legally clear a line like "in the same spirit" is, however. But hey, maybe GPL v3 will be a little more clear about this
It's... It's...
OK, this is only a Slashdot post. I don't dare to post it to rms@gnu.org (or whatever his email adress is) because I guess mr. Stallman is a kind of a busy guy, and I don't want to concern him with this if it's not his choice to be concerned with it.
/. folks agree with this opinion, or disagree. (Patches are welcome, too ;-) If this turns out to be a more or less important point, we might send it to mr. Stallman after all.
;-)
But what I'd really like to hear, is how many
Anyway, here goes.
------8<------
Dear mr. Stallman,
It has occured to me that you are trying hard to make clear to the GNU/ Linux community, as well as the outside world, what "Free Software" is, and why it is good. You do this by writing so-called "Free Software" yourself, as well as propagating the use of the terms "Free Software" and "GNU/ Linux".
I won't discuss the use of the latter term in detail here; it would be an interesting, but not so important discussion about whether the term "GNU/ Linux" is accurate enough to describe any currently running distribution - but above all, the use of this term is a good advertisement for the FSF, and as such, it can only do good.
But I strongly disagree with the widespread use of the former term, the term that you seem wish to be used, more than any other term: "Free Software". I think it does _not_ serve as an advertisement for the FSF case, at all. Allow me to explain why.
You have noticed that "Free Software" easily gets confused with "Open Source Software" by the public, and you try to get rid of that confusion by stressing upon the strict use of the term "Free Software" when referring to GNU licensed software. However, I think that the main reason why people don't use the term "Free Software" too often, and rather fall back to the (more general) term "Open Source", is because the term "Free Software" is extremely confusing to outsiders. It gets confused with "free as in beer" and "freeware" way too easily.
Some people try to clear things up by saying "libre", "liberated", etc. instead. But because there isn't a clear party propagating the use of these words, they are not used by a significant lot of people. So the undecisive amongst the purists still fall back to "Open Source" *by lack of a better term*.
I support this fallback completely. Allow me to illustrate why I think that using the term "Free Software" does more harm than it can do good:
- Newcomers to GNU/ Linux are often also newcomers to the world of (freely available) source code. They can't interpret the term "F.S." correctly, because of a complete lack of context. Lots of folks can't understand what "software" and "freedom" could possibly have in common. They have never seen a line of code in their life. Sow how to make clear to these people that they have the freedom of getting, modifying and redistributing the so-called "source code"? Saying that the software is "free" just doesn't do that trick; saying it's "Open Source" does, but you don't like this term because it is often used in a more general context.
- Most people don't have your degree of software idealism. I imagine that when you use the term "Free", you mean "Free as in speech" in 90% of the cases. However, for most other people, "Free" most often means "free as in beer" - it's just inherent to our commercial society. So this word turns out to be more confusing for most common people, than you might imagine. It might inspire them to go shopping, but it doesn't really inspire them to change the world for the better, as I believe is your wish.
- As a result of both points, when I explain to someone that "I solely use Free Software", he might respond with "Cool. Well, I got my copy of Internet Explorer as a free download, too."
Well, I am not claiming to tell you something new here. But if you care about people using the correct terms (and, as a result, get inspired by your idealism) as much as you do, it is *really* important to use a less obfuscating term. If you continue to use the term "Free Software", I think you'll be making your mission unnecessarily hard.
But if you manage to come up with a much more descriptive term, I think that the word will spread like it has never done before. I understand that it's very hard to change such a thing right here, right now, but I think that it is not yet too late, and, as I explained, I think it would really serve your mission, while the current term does more harm than it does good. Additionally, you are the right person in the right place to do this. (Yup, I think your influence in the GNU/ Linux world is bigger than you think -- it's only because of the term that you don't see references to the FSF that much nowadays
(I personally like to use the term "copylefted": it's funny, it's used by the FSF already, and it's very descriptive too - it makes clear that the software is public property, and that the copyright owners do not place restrictions on it, except that no-one else can place these restrictions. However, I don't want to make a real proposal for better a term at this stage, so it should only be interpreted as an example.)
Sincerely,
Stefan Rieken <StefanRieken@SoftHome.net>
------8<------
It's... It's...
see http://www.kmfms.com/ .
:-)
Good luck with it
It's... It's...
Well, here in Holland, there's only one kinda frequent M$ advertisement. It is on radio and TV, and all it does is...
...remind you that you have to pay for Windows!
Yes, I am serious. All the commercial says is "if you install software on multiple machines, you must not forget to pay up multiple licenses". It's presented as if this is a general rule for software, but the images in the TV commercial make clear that this is a Microsoft commercial.
Actually, some folks on http://www.nl.linux.org/ seem to have complained to the Commision of Advertisements about this. Just for the record, I guess.
It doesn't really irritate me that it is suggested that you have to pay licenses for all software. What does irritate me is that this seems to be all the advertisement M$ needs. I never managed to get rich of saying "hey, you, give me loads of money, and don't complain about it", so why should they.
It's... It's...
The Hurd rocks, but it's not "rock solid". And not yet ported to anything else but i386, according to what I've heard. I had troubles installing it; first my ne2000 card gave troubles, then something as yet unidentified went wrong.
Added to this, it's a microkernel system. Big Iron doesn't need microkernels. They're a little bit slower by nature, but you get the advance of a small, configurable "mostly user-space" kernel. That's pretty cool for palmtops and everyday PC's but not Big Iron, I'd say. That's why QNX doesn't run on mainframes.
If Linux can't do the "big iron" thing, I think BSD would be a more serious alternative for now. NetBSD runs on almost every platform, so its kernel should be portable. And I hear rumours that BSD can do some things that Linux can't as of yet. (And vice versa, of course; that's not the issue. The issue is, maybe BSD will just be able to do the trick.)
GNU's Not Unix: this sentence is more important than you may think.
The HURD microkernel can be set up to listen to POSIX if you wish, but it can also listen to other stories. So here's a possibility to move away from ugly ol' POSIX in a decent manner, without having to completely abandon the ship like e.g. BeOS does, providing only POSIX as a portability layer.
The HURD microkernel allows you to mount filesystems in a "new, radical" way which takes away the requirement of seperate "/usr" dirs, etc. (The mounted fs will be mapped on top of the current one, IIRC.) The HURD microkernel allows for user space device drivers and kernel modules, which I think can in the end make the "UNIX experience" a lot less harder.
So I think that when it's finished, the HURD will be there for the common people and will supply more ease of use and programming freedom than Linux or BSD do now, because it's very flexible and can be set up very friendly towards the user (in my imagination, anyway). It will slowly move to liberate us from the less nice UNIX inheritance, as well.
But I simply do not think that Big Iron is a target of the HURD.
But I'm not very afraid about Linux loosing Big Iron. All we need is an open source kernel (isn't Caldera opening UnixWare?) for it. I don't care if it's a fork, has a different name or implementation. That's what standards are good for. All the tools and gears are here already, so it would be "easy" for e.g. Debian to make a Big Iron port, just as they did a Hurd and FreeBSD port once.
It's... It's...
When talking about what came first: the chicken or the egg, GCC is definitely the egg and GNU is the chicken. (See also the picture on gcc.gnu.org .)
:-) , etc.
Without GCC, there wouldn't be much Free Software around. Even non-GNUish Open Source projects (most namely BSD) use GCC. Even interpreted languages use GCC, as their interpreter is often compiled
GNU software with a >= 1.0 version number is usually well-thought-of and extremely reliable. To name a simple instance, I think that for the most UNIX utilities, the GNU versions just work better than e.g. Solaris or BSD versions. GNU tar's -z option rocks, as does the option parse system of e.g. ls , so that you can write ls foo -l as well. Bash is also an example of a solid piece of GNU software.
You'd think that these FSF "rock solid" GNU folks would be more careful about the "egg" of their project, GCC. But what do I hear here? Buggy "stable" releases, binary incompatibilities between minor releases which are only resolved by incompatible fixes for a new major release... It's kind of a mess.
I've also got the impression that with glibc the same issues arise, but I might be wrong.
How can we have closed source vendors run to open source systems when things are like this?
It's... It's...
Of course there is a single website for GNOME. Of course there is a single person managing the Linux kernel. Of course there is only _one_ Nautilus app.
:-)
But if I want to add something to GNOME, I write what _I_ want and offer it to the community. GNOME may or may not accept it into its core, but that's valid: GNOME is the "market visitor", picking out what it likes. If I have a patch for the Linux kernel, I offer it at the mailing list. Linux visits the "marketplace" and picks out the good stuff.
I've seen people "playing marketplace" with their GNOME stuff. A good instance is Galeon; it is not accepted at the GNOME core, but it is very popular amongst individual "visitors". I've seen people offering their stuff at linux-kernel; some of their stuff is accepted, some of their stuff is rejected by Linus but remains a seperate patch. I've seen someone offering to write Samba support for GNOME-VFS, at which the Nautilus folks responded: "that would be great". I've seen distro's choose between package formats. Etc., etc.
Now, if this isn't a marketplace...
Of course there are project managers, but all they really do is "shop". And everyone is free to offer their goods. Never, ever, does a project manager tell somebody what to do in the Open Source world; instead, they only say "I'd like to have this, if there's someone who implements it, I'd be grateful". If there's no-one implementing it, it's not going to be there.
Go look at some Open Source projects' FAQ's, you'll often find these two:
Q.: When will it be finished?
A.: Depends on your input
Q.: Will there be feature X?
A.: No-one is working on it, but you are welcome to do it.
'nuff said, right? A project is nothing more than a "market visitor", that says what it needs and where it should go. The "market people" then can make their offers.
It's... It's...
Well, the U.S. of A. is known to have a picky government... I think that you should simply become (or -- claim that you are) a civilian of a country that doesn't care about what you're doing, and where the folks that should become angry from your software don't live. Just like they do with code with US export restrictions.
It's... It's...
The simple way to get an idea of the difference is this:
;-), and hats off for the developers!
- Linux does fully preemptive multitasking, which means that CPU time is shared by multiple processes, that each process gets his part, and that if some process waits (e.g. for I/O), his "part" will be used to run other processes in. So all in all, this is a fine "time-sharing system".
- The kernel however, doesn't do this internally (yet!). If you do a kernel call, e.g. write to a device, the kernel call is the _only_ thing that runs at that moment. If it has to wait for something, it just _waits_. Only after the call has returned, Linux starts looking at the scheduling system again.
A fully preemptive kernel means (anyway in this context), that it is also preemptive internally, so if kernel code has to wait for something, other tasks can be performed. As you might understand, a fully preemptive kernel must be _very_ sophisticated. I'm glad we're gonna get it (well, if Linus permits it, anyway
It's... It's...