Slashdot Mirror

1. The signature of the .bar registry, as signed by the central registry.
2. The public key of the foo.bar owner, as signed by the .bar registry.
3. The signature by the foo.bar owner of each chunk the foo.bar domain description.

PS: Thanks, Mr Z, I was going to propose just the same thing as you did, and am glad I'm not the only (or first) one to think about it.

-- Faré @ TUNES.org

I (Basile S.) do agree with the poster. I do not claim that closed source is better. We all know it is worse (all things being equal). What is needed is more than OpenSource: it is reflexive systems. See www.tunes.org for more. Informally and in brief, a reflexive system knows about itself and can enhance, reason, prove, and check itself (or parts of it). I am convinced that reflexive system are the next step. They will supersede open source systems. (Actually, complete open source systems -such as a fully open, source form, Linux distributions- are already reflexive in an ill and poorly defined way, and perhaps some old Smalltalk or Lisp machines also where reflexive) (Proof-carrying code, a la Peter Lee, are also somehow partly reflexive). The difficult part is doing a full reflexive system. This mostly means start from scratch. Regards

-- Faré @ TUNES.org

-- Faré @ TUNES.org

-- Faré @ TUNES.org

<insert your favorite assassination victim here>

Is that some suggestion as to a way to assassinate said victim? Being inserted into a slashdot comment must be a painful death indeed!

-- Faré @ TUNES.org

I could be totally misunderstanding what the goal of the protocol is.

Indeed you are, and your criticism is puny.

1. Your corporatist argumentum ad auctoritatem is most despicable. If anywhere, it should have been put at the end, with a much softer tone.
2. The ploy is not at all about secret-sharing, it's all about free publication. It is so that anyone can publish information without any of the individual participating servers being possibly held guilty.
3. The whole concept of "purely" random data is irrelevant hogwash. What counts is practically random data. White noise from your the kernel/soundcard/whatever, obfuscated by whatever cryptographic means of the day, is more than enough in practice.
4. The choice of pads can be automated according to any cold-minded (i.e. not you) cryptographer's criteria, if needed.
5. Alice doesn't have to claim she's the author. When she publishes a list of IDs, it is up to the police to prove that she is the original perpetrator, not just someone who repeats information given by someone else. Unless you make publishing of IDs a forbidden thing in itself. Welcome to the next DeCSS-like "everybody copies the list of IDs" contest!
6. The ploy indeed can be usefully combined with other ploys; David Madore makes no claim that it is a complete specification for a publication system. You will still need trust into the servers so as to keep no date information, you will still need crypto when communicating with servers if you fear sniffers and men-in-the-middle, etc.

Apart from the classical problems of client-server communication privacy (with classical solutions), and of trust in the servers (with classical lack of solutions), and can see a big difficulty in Madore's ploy: the challenge will be so that pads be reused a bit, but not too much. They must be reused a bit, so that no one can claim a particular pad as being culprit in a particular message; but they must not be reused too much, so as not to weaken the innocence of other pads in a message. Finally, it seems to me that servers should maintain some meta information, although (obviously) not publication date, but rather divulgation date (the date the message has first been observed in an ID list), so that one can avoid relying on pads all of which have been used, which would compromise the last message as "guilty". David Madore proved that you can sometimes prove pads "innocent", which allows to invoke the principle of presumption of innocence for pads. The danger is that proving too many pads innocent might result in finding the remaining ones guilty.

Ideally, no single pad (and thus no single pad publisher) can ever be held "guilty for sure" of holding any "forbidden" information. Maybe this ideal can be practically approximated; maybe it cannot. In either case, I'd be most interested in a proof, rather than in fallacious whining.

Disclaimer: I know David Madore personally, and although he's not a cryptographic academics, he is neither a crook nor a naive guy, and usually has interesting things to say; even when he is mistaken, it is most interesting to figure out how and why.

-- Faré @ TUNES.org

I am entertaining the idea of making a little FORTH compiler that would be also some sort of OS.

Who isn't? :)

Seriously, you'll probably want to check out the Tunes project, which aims at a reflective computing system, integrating a language and OS. They focus more on applicative languages, though.

There's also the Retro project for a FORTH OS, by Tom Novelli. It's been thrice-rewritten, so he must have at least learned something from it! :)

And no, reading the Linux kernel source is not a particularly good idea, I'd say. It's implemented in that nasty traditional mix of assembly and C. It'll have you thinking in C, which will then give you trouble when you go program in FORTH. (I know I hate mixing up the two.) Better to check out some of the traditional OS textbooks and reference implementations... as well as whatever code there is in Retro right now...

I am entertaining the idea of making a little FORTH compiler that would be also some sort of OS.

Who isn't? :)

Seriously, you'll probably want to check out the Tunes project, which aims at a reflective computing system, integrating a language and OS. They focus more on applicative languages, though.

There's also the Retro project for a FORTH OS, by Tom Novelli. It's been thrice-rewritten, so he must have at least learned something from it! :)

And no, reading the Linux kernel source is not a particularly good idea, I'd say. It's implemented in that nasty traditional mix of assembly and C. It'll have you thinking in C, which will then give you trouble when you go program in FORTH. (I know I hate mixing up the two.) Better to check out some of the traditional OS textbooks and reference implementations... as well as whatever code there is in Retro right now...

Again, I must go in my usual rant: is there any reason why we insist in still writing operating systems in low-level programming languages like C (or C++, which I insist on considering as a low-level language)? It may be that low-level languages are better suited for writing the low-level stuff like the bootstrap code and the immediate hardware drivers (but even then, I don't see why a high-level language couldn't be extended with the appropriate functions to do the task), but some things in modern operating systems are definitely archaic.

Why is it for example that we still maintain the memory/filesystem dichotomy? It is about as absurd as requiring that a programmer have to handle the mainboard-level cache by hand. Why is it that whenever any program wants to save data, it must painstakingly convert it into a binary representation? Why is it that subroutines and programs still have to be distinguished? Why is it so painful to have reflexivity (e.g. for user-mode Linux you have to recompile a whole new kernel, the one already in place is not reflexive / reentrant in that sense)? Why is it that for security measures we rely on hardware control (aka MMU's) rather than formal invariance proofs? Why is it that our processors are so big and bloated and distribution / (asymmetric) multiprocessoring / clustering is so far behind?

For more information about what a high-level operating system might be, I refer to the Hurd (which is high-level, but at the cost of an abstraction inversion, because it is still written in C; notice that the Hurd Really Runs), to Erlang, which deserves to be better known because it's really impressive, and to the all-ambitious Tunes project.

-- Faré @ TUNES.org

Apple understands this, and may therefore be the first to create a Unix-stable, xerox-style operating system.

Bzzzttt. What about Genera, the operating system of ages-old LISP Machines?

-- Faré @ TUNES.org

I know others have said it, but here it is again: diversify. By that, I don't just mean you should go and learn a bunch of similar languages (*cough*C++*cough*Java*cough*Eiffel*cough*). I mean broaden your horizons. Take some time to study things - languages, paradigms, ideas, fields - completely unrelated to your current field.

As for languages - well, ESR says in his page that every good programmer should at least get acquainted with Lisp, Perl, Python and C. I don't disagree (except perhaps WRT C). (If you've been taught Lisp/Scheme improperly and, as a result, now hate it, give it another try, using a more free-form approach, and in a good environment - DrScheme is good, and, besides the regular Windoze, MacOS and Unix releases, there's even a distribution uses OSKit to make it an actual FreeBSD-compatible stand-alone OS!)

Other languages I suggest: Haskell and ML (both functional languages with more "traditional" syntaxes than Lisp; Haskell is a pure functional language), Prolog (another excellent idea with a terrible reputation due to being mis-taught), Smalltalk and Self (both pure object languages; Smalltalk is pretty much the father of modern OO, and Self is its prototype-based - i.e., classless - descendant), APL (yes, APL... it's very remarkable!), and various assembly languages, most notably for the PowerPC and the Alpha.

As for paradigms... well, don't get too attached to them. As you get some experience with various languages, you'll find that paradigms are only "right" as long as they're useful. More specifically, you'll have developed your own sense of the Right Thing in programming, your own view of what programming should be like, and you'll see how the good ideas in each paradigm fit into that. (For example, Brian "water" Rice is doing some very fine work on Slate, a language which, somewhat like BETA, integrates objects, components and functions on a fundamental level.)

Also, never neglect the fundamentals. I'm talking about the theoretical foundations of computational mathematics (*): partial recursive functions, Turing Machines, etc. (Remember - don't be afraid of the math... the math is your friend.)

Finally (and in relation to the former paragraph), sit down at whatever library you find which has a copy of it, and study Knuth's Art of Computer Programming. Despite some pitfalls, it remains one of the fundamental texts in the field.

One last thing: go look at the long-standing Tunes project (here's an explanation for the less enlightened, given that the project's leader has a tendency to verbosity and obscurity when writing). Also interesting is its Languages Review page.

(*) I refuse to use the term "computer science". But that's the subject of another rant entirely...

I know others have said it, but here it is again: diversify. By that, I don't just mean you should go and learn a bunch of similar languages (*cough*C++*cough*Java*cough*Eiffel*cough*). I mean broaden your horizons. Take some time to study things - languages, paradigms, ideas, fields - completely unrelated to your current field.

As for languages - well, ESR says in his page that every good programmer should at least get acquainted with Lisp, Perl, Python and C. I don't disagree (except perhaps WRT C). (If you've been taught Lisp/Scheme improperly and, as a result, now hate it, give it another try, using a more free-form approach, and in a good environment - DrScheme is good, and, besides the regular Windoze, MacOS and Unix releases, there's even a distribution uses OSKit to make it an actual FreeBSD-compatible stand-alone OS!)

Other languages I suggest: Haskell and ML (both functional languages with more "traditional" syntaxes than Lisp; Haskell is a pure functional language), Prolog (another excellent idea with a terrible reputation due to being mis-taught), Smalltalk and Self (both pure object languages; Smalltalk is pretty much the father of modern OO, and Self is its prototype-based - i.e., classless - descendant), APL (yes, APL... it's very remarkable!), and various assembly languages, most notably for the PowerPC and the Alpha.

As for paradigms... well, don't get too attached to them. As you get some experience with various languages, you'll find that paradigms are only "right" as long as they're useful. More specifically, you'll have developed your own sense of the Right Thing in programming, your own view of what programming should be like, and you'll see how the good ideas in each paradigm fit into that. (For example, Brian "water" Rice is doing some very fine work on Slate, a language which, somewhat like BETA, integrates objects, components and functions on a fundamental level.)

Also, never neglect the fundamentals. I'm talking about the theoretical foundations of computational mathematics (*): partial recursive functions, Turing Machines, etc. (Remember - don't be afraid of the math... the math is your friend.)

Finally (and in relation to the former paragraph), sit down at whatever library you find which has a copy of it, and study Knuth's Art of Computer Programming. Despite some pitfalls, it remains one of the fundamental texts in the field.

One last thing: go look at the long-standing Tunes project (here's an explanation for the less enlightened, given that the project's leader has a tendency to verbosity and obscurity when writing). Also interesting is its Languages Review page.

(*) I refuse to use the term "computer science". But that's the subject of another rant entirely...

I know others have said it, but here it is again: diversify. By that, I don't just mean you should go and learn a bunch of similar languages (*cough*C++*cough*Java*cough*Eiffel*cough*). I mean broaden your horizons. Take some time to study things - languages, paradigms, ideas, fields - completely unrelated to your current field.

As for languages - well, ESR says in his page that every good programmer should at least get acquainted with Lisp, Perl, Python and C. I don't disagree (except perhaps WRT C). (If you've been taught Lisp/Scheme improperly and, as a result, now hate it, give it another try, using a more free-form approach, and in a good environment - DrScheme is good, and, besides the regular Windoze, MacOS and Unix releases, there's even a distribution uses OSKit to make it an actual FreeBSD-compatible stand-alone OS!)

Other languages I suggest: Haskell and ML (both functional languages with more "traditional" syntaxes than Lisp; Haskell is a pure functional language), Prolog (another excellent idea with a terrible reputation due to being mis-taught), Smalltalk and Self (both pure object languages; Smalltalk is pretty much the father of modern OO, and Self is its prototype-based - i.e., classless - descendant), APL (yes, APL... it's very remarkable!), and various assembly languages, most notably for the PowerPC and the Alpha.

As for paradigms... well, don't get too attached to them. As you get some experience with various languages, you'll find that paradigms are only "right" as long as they're useful. More specifically, you'll have developed your own sense of the Right Thing in programming, your own view of what programming should be like, and you'll see how the good ideas in each paradigm fit into that. (For example, Brian "water" Rice is doing some very fine work on Slate, a language which, somewhat like BETA, integrates objects, components and functions on a fundamental level.)

Also, never neglect the fundamentals. I'm talking about the theoretical foundations of computational mathematics (*): partial recursive functions, Turing Machines, etc. (Remember - don't be afraid of the math... the math is your friend.)

Finally (and in relation to the former paragraph), sit down at whatever library you find which has a copy of it, and study Knuth's Art of Computer Programming. Despite some pitfalls, it remains one of the fundamental texts in the field.

One last thing: go look at the long-standing Tunes project (here's an explanation for the less enlightened, given that the project's leader has a tendency to verbosity and obscurity when writing). Also interesting is its Languages Review page.

(*) I refuse to use the term "computer science". But that's the subject of another rant entirely...

Government is an invention to oppress people; if you want to talk specifically about government, say "french government", not "France"; if you want to talk about the country, say "France", not "french government". I am french, yet I feel little solidarity with present, past and future french governments; I know for sure than in other countries were governments are even more on the loose than in France, people feel even less solidarity with their governments.

That said, like many french people, I think that the "anti-racist" law is itself a very racist law (apart from being most inappropriate), since it makes a special case for the jews; of course, I can't say it on any french media, least I be censored by this very law.

-- Faré @ TUNES.org

As a side note, I found a text by the same author against patents, but one for copyrights (none on the 'Net in english, AFAIK). Not that I agree with him on the latter point...

-- Faré @ TUNES.org

The great Faré has much talent for inventing abstractions, but very little for seeing the practical. The fact is, he has written as much documentation for Tunes as Linus Torvalds as written code for the Linux kernel, and Faré has written as much code for Tunes as Linux has written documentation for Linux.

Microkernel are one of Faré's pet peeves. He is constantly trolling on the subject. Logically, he's right, as he usually is; but he has this wonderful gift for saying the truest things in the wrongest ways...

The great Faré has much talent for inventing abstractions, but very little for seeing the practical. The fact is, he has written as much documentation for Tunes as Linus Torvalds as written code for the Linux kernel, and Faré has written as much code for Tunes as Linux has written documentation for Linux.

Microkernel are one of Faré's pet peeves. He is constantly trolling on the subject. Logically, he's right, as he usually is; but he has this wonderful gift for saying the truest things in the wrongest ways...

-- Faré @ TUNES.org

-- Faré @ TUNES.org

Even ISPs don't censor at the whim of the first come complainant; they ask for backed arguments, and have someone check the validity of the claim, before they take any action. Why don't universities just disclaim responsibility for the contents of personal pages? In any case, censorship is not something to use lightly, and at the very least, the accused students ought to be able to defend themself before being censored.

-- Faré @ TUNES.org

That said, /. may lose anonymous writership if it publishes AC posts w/o permission, so a preference-defaulted checkbox to allow or disallow republication on other media is a good idea. On the other hand, if people write on such fora, it is in the hope of being read; publication on other media only enhances the public; hence, the default should be to allow republication (with proper authorship acknowledgement, of course), since it only amplifies the displayed goal of the poster.

Anyway, down with intellectual property! Long live acknowledgement of authorship!

-- Faré @ TUNES.org

Error Occurred While Processing Request

Error Diagnostic Information

WaitNamedPipe returned FALSE. Windows NT error number 121 occurred.

Hum. Can we trust such a buggy NT-based service to provide secure spam recycling services?

-- Faré @ TUNES.org

I don't have any voice modem, and don't know if some such modems exist with enough documentation; also, it would require a small recording software to make messages tailored to 800 answer boxes (i.e. wait the right time, emit tone, wait, emit tone, wait, speak). Voice-Synthetizing the messages could also save bandwidth for the client connections.

Just my 2 eurocents worth...

-- Faré @ TUNES.org

When I was in school, the reference for "traditional" OS design was Prof. Andrew Tanenbaum's Modern Operating Systems. It discusses both stand-alone and network operating systems, and touches on everything from processor architecture to capabilities, and discusses many favourite algorithms for memory, process and disk space management. It also includes full-fledged descriptions of two operating systems designed and implemented by Tanenbaum and his horde of grad students: the toy Unix clone Minix, and the microkernel-based Amoeba (affectionately dubbed "the cutting edge in archaic OS design").

Of course, since then, a lot of superior and much more interesting ideas on the subject have shown up. By now, a widely agreed-upon goal in the community is to design and develop a reflective, fine-grained OS with a natural and flexible interface, including complete integration with a very high-level language. In particular, the Tunes project (led by my pal Faré) has set out to do precisely this; however, progress is slow to come, and at least half a dozen side projects for "Tunes--"-like systems have popped up, notably Brian Rice's Arrow and Slate, and Tom Novelli's Forth-based Retro. (All of these are buried somewhere in the Tunes server.)

Tunes' Review Subproject has also managed to accumulate a rather comprehensive list of existing, dead and future OSs, as well as critiques thereof; a previous poster has already posted the link.

-- Faré @ TUNES.org

Microsoft is just the most widespread 800-pound gorilla.

How dare you insult gorillas? They are nice beasts that mean no harm, not ruthless brutes that will attack anyone who stands in their way.

-- Faré @ TUNES.org

• Assuming the publisher is responsible, if there is Microsoft-copyrighted material published on MSN, this is no copyright infringement. Of course, MS may remove it nonetheless if it wishes, since it publishes the pages and is not forced to keep it. But again, this is no copyright infringement.
• Assuming the publisher isn't responsible, then he is not forced to remove even copyrighted material from his site.

This all suggests another copyright fighting tactic: posting lots of copyrighted material on information boards published by copyright-holder...

-- Faré @ TUNES.org

-- Faré @ TUNES.org

...legitimate copyright...

Nice oxymoron.

-- Faré @ TUNES.org

Of course microkernels suck, anyway.

-- Faré @ TUNES.org

Of course microkernels suck, anyway.

-- Faré @ TUNES.org

THANK YOU! I've been saying that for years! (See sig.)

Unfortunately, the average Slashdot user is so infatuated with his Linux(/BSD/HURD) plaything that he won't stop for a moment to consider the horrible horrible flaws which plague the entire Unix family (and relatives, and clones, and anything based on the Unix architecture or on its language of choice, the static, low-level "portable assembly" C). Even more sadly, he will steadfastly hold close to his belief that anyone who doesn't like Unix (or C) must be an evil Microsoftie, and in doing so will pass on the opportunity to learn that there are better things and life than the Beast from New Jersey.

Ah well - I digress. Just take a moment to look at the critique of C/C++ on the site for the Tunes project, if you will... and, as I say below, think twice before moderating the crap out of us both.

-- Faré @ TUNES.org

-- Faré @ TUNES.org

-- Faré @ TUNES.org

Oh, of course, lots of people (the racketeers that make money with patents, and their lackeys), will tell you that all research would stop without patents. As if research had ever waited for patents so as to begin! Yeah, some people even pretended that without a monopoly, there would be no trade between Europe, Asia, and America; but their tea ended in the sea near Boston.

Patents have ALWAYS been a way to STIFFLE, not ENCOURAGE, coopetitive creation. Witness these Quotes from the LPF.

Free Software! Free Information!

-- Faré @ TUNES.org

Oh, of course, lots of people (the racketeers that make money with patents, and their lackeys), will tell you that all research would stop without patents. As if research had ever waited for patents so as to begin! Yeah, some people even pretended that without a monopoly, there would be no trade between Europe, Asia, and America; but their tea ended in the sea near Boston.

Patents have ALWAYS been a way to STIFFLE, not ENCOURAGE, coopetitive creation. Witness these Quotes from the LPF.

Free Software! Free Information!

-- Faré @ TUNES.org

Oh, of course, lots of people (the racketeers that make money with patents, and their lackeys), will tell you that all research would stop without patents. As if research had ever waited for patents so as to begin! Yeah, some people even pretended that without a monopoly, there would be no trade between Europe, Asia, and America; but their tea ended in the sea near Boston.

Patents have ALWAYS been a way to STIFFLE, not ENCOURAGE, coopetitive creation. Witness these Quotes from the LPF.

Free Software! Free Information!

-- Faré @ TUNES.org

You're right to say that no GUI will solve the lack of an appropriate computing paradigm. You're wrong to say that it hasn't been invented yet. It has - look at Squeak, Native Oberon, Self, and many other computing systems (yes, even those that have been traditionally shunned by engineers as "mere research projects"). In particular, look at the Review subproject of Tunes. There's a lot of new stuff out there, and much of it is great. Just because it's not mainstream doesn't mean it's not better. (Just look at Lisp...)

Perhaps the policy of GPL-ing top-secret documents and spy communiqués should be reviewed and revised

Ttttt. Don't confuse Rights and Opportunity. Everyone has the Right to copy, modify and distribute our top secret information. But if we're good, no one will have the opportunity. And if we're not so good and the information does fall into enemy hands, then no amount of weeping about bogus rights will save us.

Of course, if someone does something wrong so as to access the information (such as breaking into our house), then we may legitimately prosecute them for this deed. But we may not prosecute them for having the information itself, or prosecute anyone else who uses it without having taken part in the possible illegitimate activities involved. If we want to secure some information, it is our duty to take appropriate measures; governments shouldn't interfere by granting "intellectual property" priviledges and otherwise asserting various "secrets".

Justice is not concerned with the results of the various transactions but only with whether the transactions themselves are fair. -- F.A. Hayek, "Law, Legislation and Liberty", I.6.j

-- Faré @ TUNES.org

-- Faré @ TUNES.org

First, I do spend five days a week programming in C++. I try to get around actually writing C++ code as much as I can, but what's left of it is still enough to make a grown man weep.

Second, I didn't mean to imply that you were a C++ zealot (like Sweeney is). I meant to imply that you were fooled into believing that C++ is widely used because of technical reasons, which is by and large not the case. Sorry for the misunderstanding.

Third, you use the term "useful" a lot. I'd like to hear your definition of it, if you don't mind.

Fourth, the overhead argument doesn't hold up anymore. Just off the top of my head, Self and Squeak both have excellent optimising compilers that produce code that is, in most cases (and as far as one trusts any benchmarks at all), as fast as the equivalent C code. For all but the most low-level applications, the gain inherent in using real OO languages far exceeds any possible performance drops. (One might say that, for such a low-level application, or one that needed many low-level optimisations, one should just go ahead and write it in C with loads of inlined assembly code. I personally favour FORTH.)

Fifth, I am not a "true OOP zealot". I am, in fact, a FFP zealot, and a member of the TUNES project. We are aiming at an integrated computing system that blurs the line between the "user" and the "developer", with a free-form, reflective, open, extensible and intuitive programming language. However, such a beast still doesn't exist. True OOP, OTOH, does, and it's good - at least far better than what you get from C++.

Sorry, I'm in a hurry to get to dinner, so I'll just use TUNES review: go here and read "Cons" (ironic, eh?). If it's not there, add "no decent object system" (AFAIK).

(Also posted to GameSpy's forum)

I'd like to see Tim explain just how it is that functional languages are confined to the realm of theory, considering the infinity of real-world applications in which they have been used since Lisp's inception in the late 1950's. (You do remember that Lisp is one of the oldest programming languages still in use, don't you?) Even more so when you consider the roots of the thing that Tim touts as one of the next big things: "parametric polymorphism", which is nothing but a (poor) adaptation to the imperative paradigm of a subset of Haskell's type system.

Perhaps this is a matter of taste, but I tend to dislike strawmen, especially when attempted by this kind of engineer, who, for some reason, seem to have a dislike of anyone who even sounds like a computer scientist (the keyword here being "scientist"). Face it, Tim: simply sweeping all which doesn't conform to the New Jersey mindframe under a blanket of "purely theoretical languages that have no use in the real world" won't make it true. The fact is that, as long as we're discussing what programming will be like in the future, functional languages are far beyond the state-of-the-art from New Jersey. (Even other game developers recognize this, as evidenced in a mid-1999 article on Gama Sutra about Haskell and other languages in gaming.)

For a glimpse of the real future of programming (as well as computing in general), I suggest the TUNES project, of which I am a member.

(By the way, Tim would have you believe that C was the very first structured programming language. I laughed especially hard when I read that part of the article.)

The first point is true. Of course, it's bad for them if they don't have a monopoly. But in as much as it's bad for them, it's good for the public. The second point is their right, although it would be a stupid and futile attitude, should the law be fair. The third point is where everything breaks: government using the public force against the public, to "protect" a few crooks.

Hey, Government, if you're looking for people to protect against the public, why not protect me, specifically? I'm ready to give you back 90% of every billion dollar that you'll help me extort from the public...

-- Faré @ TUNES.org

Now (1) statistics doesn't exclude exceptions to the norm; (2) considering the weight of acquired traits in human behavior, genetics only account for an initial trend, that can be amplified or dampened by social pressure; (3) as computer science/gaming is considered more and more "traditional" and "safe", you can expect women to be more and more into this activity, (4) even if you manage to get a fair ratio of women in CS, then, you'll most likely still be able to feel a neat difference between behavior of male and female computer scientists/gamers (for better and for worse).

-- Faré @ TUNES.org

As a colleague of Faré in the Tunes project (shameless plug) and a subscriber to (and occasional participant in) the cybernethics mailing list, I'd like to point a few things out.

First of all, Faré is French and resides in France. So before attacking his integrity, honesty, manhood, morals, intelligence, competence or whatever, ask yourself this question, American-boy: do you have any idea as to how French law applies to this issue? What if it were the case (perhaps not in France, but somewhere else) that this loophole _were_ applicable and an issue under some other country's law?

Also, as other posters have said, Faré is worried about what might happen if a corporation were created with the express purpose of hoarding otherwise GPL'd code. This might be an issue.

Finally, please don't fuck cybernethics up! If you want to join in on the discussion, that's great, but the membership is really soaring, and it'd be very unfortunate to see the list deteriorate, and I'm afraid that this is going to be the case. So try to keep the S/N ratio up.

Anyway, if anyone cares, Faré and I are on IRC right now (#tunes at openprojects.net). If you've got a problem with him (or me!), come over... we've already got the boxing ring set up.

Legally, this is incorrect. In order for the described exploit to work, those wishing to use the proprietary code would have to encorporate, which is not a simple feat.

A vague "organization" would not have the legal standing to use the described exploit. Furthermore, any use of the proprietary code outside of the agrigate could be considered illegal, as it is being used outside the corporation.