zfec is much, much faster than par2: http://allmydata.org/trac/zfec
Tahoe-LAFS uses zfec, encryption, integrity checking based on SHA-256, digital signatures based on RSA, and peer-to-peer networking to take a bunch of hard disks and make them into a single virtual hard disk which is extremely robust: http://allmydata.org/trac/tahoe
Thanks for the kind words about Tahoe. I'm one of the architects. We have indeed done a lot of work on security in Tahoe, and the contributors to Tahoe do collectively have a lot of expertise in security engineering.
However, we know that security is awfully hard, and there's nothing like open peer review to shake out the subtle problems.
That's why we are running the "Hack Tahoe!" contest. If you can find a security hole that we overlooked, then you'll receive acclaim, a customized t-shirt with your exploit printed on the front, and a picture of your smiling face on our Hall of Fame.
Mojo Nation was conceived by Jim McCoy and Doug Barnes in the 90's. At the end of the 90's they hired hackers and lawyers and started implementing.
Their company, Evil Geniuses For A Better Tomorrow, Inc., opened the source code for the basic Mojo Nation node (called a "Mojo Nation Broker") under the LGPL.
During the long economic winter of 2001, Evil Geniuses ran short of money and laid off the hackers (the lawyers had already served their purpose and were gone).
One of the hackers, me, Zooko, and a bunch of open source hackers from around the world who had never been Evil Geniuses employees, forked the LGPL code base and produced Mnet.
Now there is a new commercial company, HiveCache. HiveCache has been founded by Jim McCoy.
BTW, if you try to use Mnet, be prepared for it not to work. Actually the CVS version works a lot better than the old packaged versions. We would really appreciate some people compiling and testing the CVS version (it is very easy to do, at least on Unix).
It would be really good if someone would compile the win32 build. We do have one hacker who builds on win32, but we need more.
bugzilla vs. debian bug tracking vs. sourceforge
on
Mozilla's 100,000th Bug
·
· Score: 3, Interesting
Is bugzilla better than debian bug tracking? Which is the best bug tracking system?
Personally, I refuse to use SourceForge's bug tracking system because it requires that I fiddle with a mouse and click on little HTML widgets and then wait for a few seconds while the form is submitted to see if it worked. I have better things to do with my time than waste it trying to use HTML and HTTP as a user interface.
I really love debian's bug tracking system, and the `reportbug' package, which allows me to do all my bug reporting with good old e-mail, from the command line, as God intended.
P.S. Despite my fears of massive slashdot flamage, there has actually been pretty much no flames, except for one from a certain unnamed Linux world journalist. Maybe the community is growing up! After all, Linux itself is 10 years old, so the first generation of Linux hackers are now in their late 20's at least.
Hi folks. The License Quick Ref is definitely a work in progress. I am no lawyer and there are a lot of question marks and probably a lot of inaccuracies or other bugs.
Please e-mail <zooko@zooko.com> with suggestions for improvement. Thanks!
If you send me flames, I may elect to post them to my web log.:-)
I have put all of my system packages on "hold"
, so they do not get changed at all. Then if I want something new and improved, like galeon, I just hit `+' in dselect to select galeon, and it shows me a list of packages which I would have to upgrade if I want galeon. I inspect it and decide whether to unhold them or not. Easy.
See InfoAnarchy.org for a discussion of CryptoBox. It isn't clear what exactly it is trying to accomplish and the cryptography doesn't seem very thoroughly worked out.
Zero Knowledge has failed on engineering grounds (efficiency, compatibility, etc. etc.) and on grounds of marketing, business, user interface, etc., but their cryptography was always real strong cryptography from the beginning. They employed many of the best cryptographers and crypto hackers of the world (including Ian Goldberg, Stefan Brands, Adam Back, Adam Shostack...), and they tried to design a system that would strongly protect users even in the face of a very sophisticated, expensive attack such as could be launched by a government or by organized crime.
CryptoBox does not have the same cryptographic pedigree. On the other hand, there is a project still in the design stages called "Free Haven" that is staffed by experienced crypto hackers. (No, I'm not a part of that project, although I would consider joining it in the future...).
Kids are going to see and hear scary things, confusing things, dangerous things, whether they use the Internet or not. The important thing is (a) that they feel that they can talk to you, and (b) that you feel that you can talk to them.
You can probably make kids feel like they can talk to you by listening to them, even when they want to talk about boring or ridiculous things. Probably telling them that "You can talk to me." doesn't really work. In fact, if you have to say that it probably isn't true. See also part (b).
b: You have to be willing to talk to your kids honestly. This means being willing to talk about stuff that you would normally avoid talking about to anyone, because it disgusts you or scares you, or because you feel guilty about it or whatever. That's hard, but very important.
Just to re-iterate: trying to prevent your kids from seeing and hearing objectionable or problematic things is a lose. First of all, it won't work, even if you throw all of the computers out of your house. But more importantly, trying to do that is a crutch to lean on instead of doing something that you need to do anyway: talk, and listen, to your children.
I'd like to know what legal problem the LGPL poses. I'm not aware of any, and as my project Mojo Nation is released under the LGPL, I would be concerned if there were any.
Oh -- well I suppose the LGPL does prohibit you from altering the code and releasing your variation without contributing the changes back to the open source project. I could see a lawyer considering that to be a big problem.
David Chaum invented blindable digital credentials in the 80's and 90's for precisely the reason that McNealy is talking about here -- so that you can do things like let the movie theatre know that you like scifi flicks and you are 3 blocks away without letting the movie theatre know who you are.
The idea that McNealy is pushing, that you can give out information about yourself in little bits, and make the recipients promise not to share it, is stupid, as should be obvious to anyone who knows about previous attempts to prohibit the free exchange of information.
If mega-corps can't prevent average users from trading information against their wishes, then how well do you think that average users will fare trying to prevent mega-corps from trading information against their wishes? Or, for that matter, other average users. There are already profitable small businesses whose sole job is to collect and organize and sell information about normal users.
The "give us your information and we promise not to mis-use it" model is just idiotic at the technological level. (That is.NET's laughable "privacy model", too.) However, there is a technological alternative: Chaumian digital credentials.
Regards,
Zooko
Re:Mojo Nation vs. Swarmcast (vs. Freenet, vs...)
on
Swarmcast GPLed
·
· Score: 2
Hm -- it is my impression that data is more persistent in MN due to the IDA splitting and heterogenous block-buying policies (i.e. some block servers rarely buy new blocks at all), plus MN's random-block-dropping policy.
In any case it is a goal of Mojo Nation that the data be persistent, whereas if I understand correctly, Freenet doesn't make persistence a goal. I hope I haven't incorrectly labelled Freenet's goals here.
Technically, data falls out of Freenet and Mojo Nation in the same way -- due to no servers wanting a copy -- but Mojo Nation contains an essential element which hopefully makes it possible maintain persistent blocks even when you are the only one who cares enough to maintain them: exchangeable network karma in the form of Mojo Tokens.
As the cypherpunks who investigated Ross Anderson's Eternity Service in the 1990's concluded, you can't have persistent data unless you have some way to motivate other people to hold on to copies that they personally are not interested in. Hopefully Mojo Tokens provide that motivation -- by holding on to blocks that they personally have no interest in (and very likely that they can't decrypt anyway), they earn network karma which they can use to store and retrieve data which they are interested in.
If I understand correctly, based on some comments by Ian Clarke, Freenet is happy with blocks that only a few people care about being dropped in favor of blocks that more people care about. That is a good design in many ways, but I hope that exchangeable Mojo Tokens will make it so that blocks are retained as long as anyone on the network wants those blocks to be retained, instead of as long as the servers who currently hold them want them to be retained.
Slashdot is a terrible medium for a real conversation, so I'll post this to the p2p hackers list...
Regards,
Zooko
Mojo Nation vs. Swarmcast (vs. Freenet, vs...)
on
Swarmcast GPLed
·
· Score: 2
It isn't true that Mojo Nation is "not focussed on performance". I'm one of the Mojo Nation hackers, and we care about performance. It is true, however, that Mojo Nation is pretty complex, providing both data transfer (using a "swarm" like technique), and data storage, and a queriable search engine. The end result is something like a distributed, non-deletable World Wide Web. (Sort of like Freenet plus persistent data, or the earlier concept of Ross Anderson's "Eternity Service".)
Performance isn't that great on Mojo Nation right now, but it is good enough, in my experience, for daily use.
I'm pretty excited about the Swarmcast open source release, both because I think Swarmcast is a cool app in itself, and because I can now start taking ideas and code from Swarmcast to put into Mojo Nation, and vice versa.
In the long run, both Mojo Nation and Swarmcast will improve because of this sharing, as will other related open source projects like Freenet and Free Haven.
Regards,
Zooko
P.S. I've been talking with Justin Chapweske, the Swarmcast, lead, on irc.openprojects.net, and he's already pointed out a potential bug that we need to avoid in future versions of the Evil Geniuses Transport Protocol...
A possible strategy for making a profitable business based on open source software development would be to write an application, release it to the public under an open source license (e.g. the GPL), and then sell to other companies the right to use the application without the GPL's restrictions.
But what happens when other people, not associated with your company, start contributing bugfixes or improvements to the open source version? Can you sell your customers the right to use these patches in a way that violates the GPL, or are the patches effectively copyrighted by their respective authors and transferred to you under the GPL?
What if you were to keep the open source and the proprietary versions separate and you only sell licenses to use the proprietary version -- does this mean you cannot ever implement a bugfix in the proprietary version that someone has committed to the public version?
Nice one, Orasis! Hopefully someone will be quick enough to mirror the next release on Mojo Nation as well.
I'm looking forward to the imminent open-sourcing of Swarmcast. I think that the emergent ("p2p") networks are maturing enough that we will start trying to link them together soon. Perhaps the second O'Reilly p2p conference will spark some work in that direction...
He should have used Gregory Chaitin's Omega number to generate the challenge file.
Actually I really don't understand Chaitin's work well enough to know if that would have saved him the $5000, but at least he (and the challenger) would have learned something about algorithmic complexity theory.
Please take a deep breath and go in for one last go-around with the FSF lawyers. Pretty please?
As far as I could tell, the remaining issues are just "legalese exhaustion" on your part rather than actual conflicting goals. Maybe you could deputize a legalese wrangler to finish negotiations for you, or you could take a month-long break in which you never think a single thought about licenses, and then you go back and finish the negotiations.
This is really important to me, although I am not a GPL fanatic, because if it remains the case that the licenses are (allegedly) incompatible, then there will be lots and lots of people who will refuse to combine GPL code with Python, and that would really suck.
For example, I want to package up my open source application Python, Mojo Nation to be included in Debian. This would be a way to reach hundreds of thousands (? maybe fewer. Anyone know how many Debian users there are out there?) of highly clueful users and hackers who would otherwise never install Mojo Nation. The Mojo Nation code source code itself is under the LGPL, and some of the open source libraries that it uses are other under free licenses. Would this cause a legal conflict that would force the debian people to keep it off of their servers? I don't know (since it is LGPL instead of GPL), but I would feel so much better if the Python license were officially GPL compatible.
Fascinating, but I want the next generation platform to evolve, not out of Sun, Microsoft, IBM, HP, Exodus, etc., but out of Mojo Nation, E, Chord, FreeNet, etc.
Open source projects, with ambitious goals for self-healing, self-organizing networks, tolerant of diversity, resistant to any conceivable attack, and free from the manipulations that mega corps inevitably introduce in their unceasing quest to gain monopoly power.
For research on programming languages and cryptography (two of my favourite areas of research), citeseer.com has all you need. It is a really beautiful system that allows you to traverse the graph of which papers reference which others, for example.
It does other kinds of papers in addition to those two areas that I mentioned, but I can't vouch for the usefulness of those areas.
cygwin rocks. If your boss forces you to develop on Windows NT, just install cygwin and suddenly it is a Unix development environment! Beautiful.
Likewise, if you are developing a GPL-compatible application and you want it to run on Windows as well as on Unix, just compile it with cygwin and ship it! (If it is not GPL-compatible, then you have to buy a license from Cygnus. An interesting business model.)
Cygwin is very mature. I was using it 18 months ago for full-time development environment on Windows NT 4.
Regards,
Zooko
This sounds like concurrent functional programming
on
Clockless Computing?
·
· Score: 2
This sounds like the kinds of problems that the concurrent functional programming people love. See Erlang or perhaps some concurrent variation of Haskell like Eden.
Regards,
Zooko
PKI makes the problem worse; the solution is easy
on
Making PKI Work
·
· Score: 2
In 90% of the applications (especially the kinds of applications that slashdotters are interested in), having a full-scale public key infrastructure and having every public key signed by a signing key would be more susceptible to attack than doing simple unauthenticated public key exchange between peers.
That's because the cost of mounting a man-in-the-middle attack on a specific public key (think of e.g. someone mounting a man-in-the-middle attack against your ssh pubkey when you ssh in to another box), greatly exceeds the payoff. There are cheaper ways to get access to your other box, starting with known exploits, followed by social engineering. Finally, physical access to your box is probably cheaper and safer for the attacker than a man-in-the-middle attack on an unauthenticated public key exchange.
Now look at the other option: what's the cost/payoff matrix for mounting an attack that steals some keys high up in the PKI hierarchy? The cost is whatever it takes to get the keys (history shows[1] that social engineering, being yourself an employee of the organization, or taking advantage of some thoughtless mistake on the part of an employee, seems like the best starting point) and the payoff is huge. You basically get carte blanche on the whole network which trust this particular PKI.
Now I am aware that there are other PKI topologies that are less hierarchical, but basically the most cost-effective solution that gives you the amount of security you need for the amount of effort that you can afford is simple straightforward unauthenticated public key exchange. The universal assumption that the only "truly secure" system is a full-scale PKI is a massive mistake perpetuated by idealistic mathematicians ignorant of the facts on the ground, and greedy PKI execs who dream of being able to extract a tax on every transaction, because they control the root keys.
There are several cheap and easy tricks you can add to unauthenticated PK exchange to make it even more expensive and dangerous for an attacker to interfere, which I would be happy to explain if anyone asks...
I got really excited when I read that book. I gave my copy to Mark S. Miller, hoping it would excite him in the same way.
The author is thinking about changing the world through public policy initiatives, education of officials, and so forth. I'm thinking of changing the world by giving disenfranchised entrepeneurs powerful tools to link them together and to turn their resources into capital
Slashdot Mirror
zfec is much, much faster than par2: http://allmydata.org/trac/zfec
Tahoe-LAFS uses zfec, encryption, integrity checking based on SHA-256, digital signatures based on RSA, and peer-to-peer networking to take a bunch of hard disks and make them into a single virtual hard disk which is extremely robust: http://allmydata.org/trac/tahoe
Thanks for the kind words about Tahoe. I'm one of the architects. We have indeed done a lot of work on security in Tahoe, and the contributors to Tahoe do collectively have a lot of expertise in security engineering.
However, we know that security is awfully hard, and there's nothing like open peer review to shake out the subtle problems.
That's why we are running the "Hack Tahoe!" contest. If you can find a security hole that we overlooked, then you'll receive acclaim, a customized t-shirt with your exploit printed on the front, and a picture of your smiling face on our Hall of Fame.
http://hacktahoe.org
Mojo Nation was conceived by Jim McCoy and Doug Barnes in the 90's. At the end of the 90's they hired hackers and lawyers and started implementing.
Their company, Evil Geniuses For A Better Tomorrow, Inc., opened the source code for the basic Mojo Nation node (called a "Mojo Nation Broker") under the LGPL.
During the long economic winter of 2001, Evil Geniuses ran short of money and laid off the hackers (the lawyers had already served their purpose and were gone).
One of the hackers, me, Zooko, and a bunch of open source hackers from around the world who had never been Evil Geniuses employees, forked the LGPL code base and produced Mnet.
Now there is a new commercial company, HiveCache. HiveCache has been founded by Jim McCoy.
BTW, if you try to use Mnet, be prepared for it not to work. Actually the CVS version works a lot better than the old packaged versions. We would really appreciate some people compiling and testing the CVS version (it is very easy to do, at least on Unix).
It would be really good if someone would compile the win32 build. We do have one hacker who builds on win32, but we need more.
Is bugzilla better than debian bug tracking? Which is the best bug tracking system?
Personally, I refuse to use SourceForge's bug tracking system because it requires that I fiddle with a mouse and click on little HTML widgets and then wait for a few seconds while the form is submitted to see if it worked. I have better things to do with my time than waste it trying to use HTML and HTTP as a user interface.
I really love debian's bug tracking system, and the `reportbug' package, which allows me to do all my bug reporting with good old e-mail, from the command line, as God intended.
Regards,
Zooko
You can always investigate the CVS logs and the CREDITS file (warning: shameless plug for my own open source/free software project).
Regards,
Zooko
Hacker, Evil Geniuses For A Better Tomorrow
Check this out:
Peter Lowe has written an interactive version of the License Quick Ref which shows you the table in a way that reflects your own biases. Ha!
http://yoyo.org/~pgl/lqr/
Regards,
Zooko
P.S. Despite my fears of massive slashdot flamage, there has actually been pretty much no flames, except for one from a certain unnamed Linux world journalist. Maybe the community is growing up! After all, Linux itself is 10 years old, so the first generation of Linux hackers are now in their late 20's at least.
Hi folks. The License Quick Ref is definitely a work in progress. I am no lawyer and there are a lot of question marks and probably a lot of inaccuracies or other bugs.
Please e-mail <zooko@zooko.com> with suggestions for improvement. Thanks!
If you send me flames, I may elect to post them to my web log. :-)
http://zooko.com/.
Regards,
Zooko
There's a broken link on their site. Try this:
http://www.kohan.net/main/press/linux_demo.htm
This looks like my kind of game!
Zooko
I have put all of my system packages on "hold" , so they do not get changed at all. Then if I want something new and improved, like galeon, I just hit `+' in dselect to select galeon, and it shows me a list of packages which I would have to upgrade if I want galeon. I inspect it and decide whether to unhold them or not. Easy.
Regard,
Zooko
See InfoAnarchy.org for a discussion of CryptoBox. It isn't clear what exactly it is trying to accomplish and the cryptography doesn't seem very thoroughly worked out.
Zero Knowledge has failed on engineering grounds (efficiency, compatibility, etc. etc.) and on grounds of marketing, business, user interface, etc., but their cryptography was always real strong cryptography from the beginning. They employed many of the best cryptographers and crypto hackers of the world (including Ian Goldberg, Stefan Brands, Adam Back, Adam Shostack...), and they tried to design a system that would strongly protect users even in the face of a very sophisticated, expensive attack such as could be launched by a government or by organized crime.
CryptoBox does not have the same cryptographic pedigree. On the other hand, there is a project still in the design stages called "Free Haven" that is staffed by experienced crypto hackers. (No, I'm not a part of that project, although I would consider joining it in the future...).
Regards,
Zooko
Kids are going to see and hear scary things, confusing things, dangerous things, whether they use the Internet or not. The important thing is (a) that they feel that they can talk to you, and (b) that you feel that you can talk to them.
You can probably make kids feel like they can talk to you by listening to them, even when they want to talk about boring or ridiculous things. Probably telling them that "You can talk to me." doesn't really work. In fact, if you have to say that it probably isn't true. See also part (b).
b: You have to be willing to talk to your kids honestly. This means being willing to talk about stuff that you would normally avoid talking about to anyone, because it disgusts you or scares you, or because you feel guilty about it or whatever. That's hard, but very important.
Just to re-iterate: trying to prevent your kids from seeing and hearing objectionable or problematic things is a lose. First of all, it won't work, even if you throw all of the computers out of your house. But more importantly, trying to do that is a crutch to lean on instead of doing something that you need to do anyway: talk, and listen, to your children.
Regards,
Zooko
I'd like to know what legal problem the LGPL poses. I'm not aware of any, and as my project Mojo Nation is released under the LGPL, I would be concerned if there were any.
Oh -- well I suppose the LGPL does prohibit you from altering the code and releasing your variation without contributing the changes back to the open source project. I could see a lawyer considering that to be a big problem.
Regards,
Zooko
David Chaum invented blindable digital credentials in the 80's and 90's for precisely the reason that McNealy is talking about here -- so that you can do things like let the movie theatre know that you like scifi flicks and you are 3 blocks away without letting the movie theatre know who you are.
The idea that McNealy is pushing, that you can give out information about yourself in little bits, and make the recipients promise not to share it, is stupid, as should be obvious to anyone who knows about previous attempts to prohibit the free exchange of information.
If mega-corps can't prevent average users from trading information against their wishes, then how well do you think that average users will fare trying to prevent mega-corps from trading information against their wishes? Or, for that matter, other average users. There are already profitable small businesses whose sole job is to collect and organize and sell information about normal users.
The "give us your information and we promise not to mis-use it" model is just idiotic at the technological level. (That is .NET's laughable "privacy model", too.) However, there is a technological alternative: Chaumian digital credentials.
Regards,
Zooko
Hm -- it is my impression that data is more persistent in MN due to the IDA splitting and heterogenous block-buying policies (i.e. some block servers rarely buy new blocks at all), plus MN's random-block-dropping policy.
In any case it is a goal of Mojo Nation that the data be persistent, whereas if I understand correctly, Freenet doesn't make persistence a goal. I hope I haven't incorrectly labelled Freenet's goals here.
Technically, data falls out of Freenet and Mojo Nation in the same way -- due to no servers wanting a copy -- but Mojo Nation contains an essential element which hopefully makes it possible maintain persistent blocks even when you are the only one who cares enough to maintain them: exchangeable network karma in the form of Mojo Tokens.
As the cypherpunks who investigated Ross Anderson's Eternity Service in the 1990's concluded, you can't have persistent data unless you have some way to motivate other people to hold on to copies that they personally are not interested in. Hopefully Mojo Tokens provide that motivation -- by holding on to blocks that they personally have no interest in (and very likely that they can't decrypt anyway), they earn network karma which they can use to store and retrieve data which they are interested in.
If I understand correctly, based on some comments by Ian Clarke, Freenet is happy with blocks that only a few people care about being dropped in favor of blocks that more people care about. That is a good design in many ways, but I hope that exchangeable Mojo Tokens will make it so that blocks are retained as long as anyone on the network wants those blocks to be retained, instead of as long as the servers who currently hold them want them to be retained.
Slashdot is a terrible medium for a real conversation, so I'll post this to the p2p hackers list...
Regards,
Zooko
It isn't true that Mojo Nation is "not focussed on performance". I'm one of the Mojo Nation hackers, and we care about performance. It is true, however, that Mojo Nation is pretty complex, providing both data transfer (using a "swarm" like technique), and data storage, and a queriable search engine. The end result is something like a distributed, non-deletable World Wide Web. (Sort of like Freenet plus persistent data, or the earlier concept of Ross Anderson's "Eternity Service".)
Performance isn't that great on Mojo Nation right now, but it is good enough, in my experience, for daily use.
I'm pretty excited about the Swarmcast open source release, both because I think Swarmcast is a cool app in itself, and because I can now start taking ideas and code from Swarmcast to put into Mojo Nation, and vice versa.
In the long run, both Mojo Nation and Swarmcast will improve because of this sharing, as will other related open source projects like Freenet and Free Haven.
Regards,
Zooko
P.S. I've been talking with Justin Chapweske, the Swarmcast, lead, on irc.openprojects.net, and he's already pointed out a potential bug that we need to avoid in future versions of the Evil Geniuses Transport Protocol...
A possible strategy for making a profitable business based on open source software development would be to write an application, release it to the public under an open source license (e.g. the GPL), and then sell to other companies the right to use the application without the GPL's restrictions.
But what happens when other people, not associated with your company, start contributing bugfixes or improvements to the open source version? Can you sell your customers the right to use these patches in a way that violates the GPL, or are the patches effectively copyrighted by their respective authors and transferred to you under the GPL?
What if you were to keep the open source and the proprietary versions separate and you only sell licenses to use the proprietary version -- does this mean you cannot ever implement a bugfix in the proprietary version that someone has committed to the public version?
Zooko
Coool.
Nice one, Orasis! Hopefully someone will be quick enough to mirror the next release on Mojo Nation as well.
I'm looking forward to the imminent open-sourcing of Swarmcast. I think that the emergent ("p2p") networks are maturing enough that we will start trying to link them together soon. Perhaps the second O'Reilly p2p conference will spark some work in that direction...
Regards,
Zooko
He should have used Gregory Chaitin's Omega number to generate the challenge file.
Actually I really don't understand Chaitin's work well enough to know if that would have saved him the $5000, but at least he (and the challenger) would have learned something about algorithmic complexity theory.
Zooko
Guido:
Please take a deep breath and go in for one last go-around with the FSF lawyers. Pretty please?
As far as I could tell, the remaining issues are just "legalese exhaustion" on your part rather than actual conflicting goals. Maybe you could deputize a legalese wrangler to finish negotiations for you, or you could take a month-long break in which you never think a single thought about licenses, and then you go back and finish the negotiations.
This is really important to me, although I am not a GPL fanatic, because if it remains the case that the licenses are (allegedly) incompatible, then there will be lots and lots of people who will refuse to combine GPL code with Python, and that would really suck.
For example, I want to package up my open source application Python, Mojo Nation to be included in Debian. This would be a way to reach hundreds of thousands (? maybe fewer. Anyone know how many Debian users there are out there?) of highly clueful users and hackers who would otherwise never install Mojo Nation. The Mojo Nation code source code itself is under the LGPL, and some of the open source libraries that it uses are other under free licenses. Would this cause a legal conflict that would force the debian people to keep it off of their servers? I don't know (since it is LGPL instead of GPL), but I would feel so much better if the Python license were officially GPL compatible.
Regards,
Zooko
Fascinating, but I want the next generation platform to evolve, not out of Sun, Microsoft, IBM, HP, Exodus, etc., but out of Mojo Nation, E, Chord, FreeNet, etc.
Open source projects, with ambitious goals for self-healing, self-organizing networks, tolerant of diversity, resistant to any conceivable attack, and free from the manipulations that mega corps inevitably introduce in their unceasing quest to gain monopoly power.
For research on programming languages and cryptography (two of my favourite areas of research), citeseer.com has all you need. It is a really beautiful system that allows you to traverse the graph of which papers reference which others, for example.
It does other kinds of papers in addition to those two areas that I mentioned, but I can't vouch for the usefulness of those areas.
Zooko
cygwin rocks. If your boss forces you to develop on Windows NT, just install cygwin and suddenly it is a Unix development environment! Beautiful.
Likewise, if you are developing a GPL-compatible application and you want it to run on Windows as well as on Unix, just compile it with cygwin and ship it! (If it is not GPL-compatible, then you have to buy a license from Cygnus. An interesting business model.)
Cygwin is very mature. I was using it 18 months ago for full-time development environment on Windows NT 4.
Regards,
Zooko
This sounds like the kinds of problems that the concurrent functional programming people love. See Erlang or perhaps some concurrent variation of Haskell like Eden.
Regards,
Zooko
In 90% of the applications (especially the kinds of applications that slashdotters are interested in), having a full-scale public key infrastructure and having every public key signed by a signing key would be more susceptible to attack than doing simple unauthenticated public key exchange between peers.
That's because the cost of mounting a man-in-the-middle attack on a specific public key (think of e.g. someone mounting a man-in-the-middle attack against your ssh pubkey when you ssh in to another box), greatly exceeds the payoff. There are cheaper ways to get access to your other box, starting with known exploits, followed by social engineering. Finally, physical access to your box is probably cheaper and safer for the attacker than a man-in-the-middle attack on an unauthenticated public key exchange.
Now look at the other option: what's the cost/payoff matrix for mounting an attack that steals some keys high up in the PKI hierarchy? The cost is whatever it takes to get the keys (history shows[1] that social engineering, being yourself an employee of the organization, or taking advantage of some thoughtless mistake on the part of an employee, seems like the best starting point) and the payoff is huge. You basically get carte blanche on the whole network which trust this particular PKI.
Now I am aware that there are other PKI topologies that are less hierarchical, but basically the most cost-effective solution that gives you the amount of security you need for the amount of effort that you can afford is simple straightforward unauthenticated public key exchange. The universal assumption that the only "truly secure" system is a full-scale PKI is a massive mistake perpetuated by idealistic mathematicians ignorant of the facts on the ground, and greedy PKI execs who dream of being able to extract a tax on every transaction, because they control the root keys.
There are several cheap and easy tricks you can add to unauthenticated PK exchange to make it even more expensive and dangerous for an attacker to interfere, which I would be happy to explain if anyone asks...
Regards,
Zooko
[1] "Why Cryptosystems Fail." Ross Anderson. http://www.cl.cam.ac.uk/users/rja14/wcf.html
I got really excited when I read that book. I gave my copy to Mark S. Miller, hoping it would excite him in the same way.
The author is thinking about changing the world through public policy initiatives, education of officials, and so forth. I'm thinking of changing the world by giving disenfranchised entrepeneurs powerful tools to link them together and to turn their resources into capital
Regards,
Zooko