Well, I remember the monetary pain of buying textbooks, and I know a lot of kids in college today. To them, the costs of textbooks are anything but chump change.
There is indeed value there, but of course the costs for this sort of work, amortized over many copies, it comparatively tiny. And I would point to the work of places like the California Open Source Textbook Project and Flat World for examples of how very good the content can be even though produced by "alternative methods".
Like prefect42 notes, the actual reviewing that filters our the cranks and such is *also* done by the academic community, usually at no charge to the publishers.
It has amazed me how long the current academic publishing regime has lasted. This dystopian fantasy by the publishers is the logical extension of a broken business model, where the publishers provide essentially zero value yet charge enormous fees. GA Tech should use this moment as a clean break point, and demand that all campus materials be either in the public domain or be available under Creative Commons license. Award tenure based only on publications which are under CC license.
Universities need to remember that they are the folks that generate *all* the content that publishers want to use against them. They can stop giving it away to these guys any time they like. In this era of global networking, there is essentially no added value in distribution, warehousing, and organizing papers into journals. Publishers need to be reminded of this fact.
Actually, to be quite clear, the "Travelling Salesman" problem is one of traversing an arbitrary graph, which can indeed include information representing non-straight distances and preferred edges where the "good lunch places" can be found. It's a very general optimization problem, and has been effectively solved for practial use for a number of years, using the "simulated annealing" method.
You may be missing my point, though. He notes, quite clearly, that both dates appear amonst the edits on the history page. He intends to convince us that the writing process introduces errors, and does so quite convincingly if one does not analyze his own article for inconsistencies. He suggests that the 1755 date is used without comment, yet then goes to on to tell us that the original and controversial date appears quite clearly in the edit history. He happily ignores this fact, and thus fails to go on and reach the obvious conclusion. Brittanica doesn't show edit histories, and as a result any mistakes they make are more likely to stay hidden from the reader. One may believe that the Brittanica quality control processes are infallible, but it is hardly probable.
So I mostly agree with your amended timeline, except for step 3. This is where McHenry was factually incorrect. More precisely, he incorrectly assumes that the article is the only information being supplied, and this misses the fact that Wikipedia is providing a valuable source of information that Brittanica does not. Of course, if your business model is to be authoritative, then airing the dirty laundry is not terribly helpful in providing that aura of infallibility.
Wikipedia is strong precisely because it shows us all this trail of information, and gives us insight into the messy process from which summarized knowledge arises. Brittanica's business model prevents it from being strong in this way, and the author demonstrates a mind set of his own that I think is quite revealing.
I'd have to disagree. The author didn't get it. He might have, he had all of the facts in front of him, and indeed mentions some of them in the article. Yet he fails to draw the correct conclusion.
1. The author chose an article from the Wikipedia. 2. The author notes an internal inconsistency 3. The author checks through the edits, which are visible to the public. 4. The author now knows that some controversy exists about the dates, and can do further research to resolve it.
Do you see? Unlike a Brittanica article, the author can see who's been editing it. More importantly, he is given a cross reference of the other edits and changes that user has made, and can judge for himself how credible this person is, and whether they have a clear agenda or bias. At the very least, the reader has no false sense of authority.
There's little faith involved here, instead there's a system for judging credibility and an audit trail. These sorts of systems have worked well in academic settings for a very long time, and indeed are a key part of the internal quality control checks for dictionaries and encyclopedias.
His closing comment, that one cannot tell who has used the facilities beforehand, shows that in fact the author does not get it at all. Precisely the contrary, Wikipedia's strength comes from the fact that one can find out not only who has used the facilities before you, but what they did there. He saw this, yet did not understand its value.
A wonderfully constructed argument, based in incomplete facts, is not a compelling argument. One could wish that a Brittanica veteran had taken the time to do a bit more research on his topic before committing it to writing. Deliciously ironic, don't you think? A sense of false authority is the most dangerous thing an encyclopedia can give, and Wikipedia manages to avoid that almost completely. Yet here we have an authoritative figure making a very basic mistake in research.
Well, it's been about 7 years since I worked there, but my guess would be no. Not that they have any serious objection to other OSs for the hardware, but they have an OS and it serves them fairly well.
I'd really prefer they move away from Mach and towards Linux as a kernel, but there are some fairly serious changes to their graphics system that would need to be made in order to have a decent performance level atop Linux. They depend pretty heavily on Mach IPC constructs and have optimized the crap out of that path to make the OS X window server work.
Yes, we had all of these discussions. But as you doubtless know, it was not acutally possible to switch the processor between big endian and little endian mode quickly enough to run both kinds of apps in separate processes at anything like decent speeds The kernel was going to have to run either big endian or little endian, and one class of apps was going to suffer hugely on performance. That meant one thing, given that we already had a huge base of big-endian compiled apps we needed to run at close to full speed. We were going to have to shift the endianness of the NT kernel and all the apps to get decent speed.
Remember, I said practical. It was clearly possible, but business-wise it made next to no sense given the technological constraints we had to work with.
No, I'm not kidding, nor was it a brain-fart. The problem with BS detectors in the presence of too little information is that they sometimes lead you astray in a big way.
There's a lot more to getting an OS ported than just porting the kernel and a few system apps. Just because you can recompile for a platform doesn't make it commercially viable. The work to try to reorganize code so that it could run at competitive speeds on PowerPC looked pretty terrible to us. NT was terribly tied to PC architectures. It ran on other instruction sets, but they never ever caught on in a big way, remember? Ever imagine there might be a reason?
The work to try to integrate it with existing PowerPC Mac applications looked even worse. The issues with simple things like screen sharing, and keeping multiple screens going, and so on, looked prety grim to us. The graphics models of the two platforms are quite different. And there's that horrible tendency in NT to run a graphics subsystem at the core of their kernel, which looked like a real bear to keep running on Mac hardware in anything like a stable fashion.
And for all of this work, we would have gotten maybe a few dozen Windows developers to recompile and support it on our new platform, if we were lucky. We were looking at huge porting effort, and ongoing maintenance problems, for very little upside indeed.
Re:Well, there was another choice.
on
NeXTSTEP To Mac OS X
·
· Score: 5, Insightful
Well, Hank, I was the guy who wrote the report at Apple that recommended we buy NeXT. It was a simple choice, really, between Be and NeXTStep. NeXT had a much more complete offering, with actual commercial developers who had written really good stuff for it. Even better, it had had a number of releases, and had a mature system for handling version upgrades. Be, as many people will recall, tended to need an application recompile for every new version, and there way no obvious simple way to solve the problem. NeXT had a mature and battle tested kernel, and a real BSD layer, neither of which could really be said of Be at the time.
We considered a lot of other OSes. We looked at NT, but it looked like it would never be practical to port to a big-endian processor. We looked at Solaris, and it was a serious contender. There was no decent UI layer, though, by the standards we used to judge such things. Remember that things like KDE and GNOME were quite young and immature at the time.
Getting back Steve was a plus for the company, but wasn't a part of our deliberations as technical folks. NeXT Looked like the best technical choice, really. Linux was simply too young in 1996 to be a serious cnsideration, even though Apple had an internal mkLinux project.
Who knows what it might have been today, given a new shot at choosing. But back then, there was nothing that stood up to NeXT given the constraints of Apple's business.
As one of the original designers of AppleScript, I feel compelled to mention that the syntax issue is a complete red herring. The language was originally designed to have replaceable syntax, and it could switch, in real time, between dialects with radically different syntax. The same routine would display in different language localizations, or different syntax forms, depending on user preference.
Apple had a Japanese dialect and a C-like dialect built during the development phase. These were never tested enough to release, primarily because of a management decision to shift a lot of the team over to work on OpenDoc after AppleScript's first release.
However, that said, it can be terribly frustrating to figure out the syntax of the current system. This is because a number of language extensions have been built through a mechanism known as OSAX extensions, over the years. The language elements which come from applications work pretty well, because there's a block structure which wraps them into easily detectable blocks. OSAXen, though, tend to interact globally with the syntax of everything, and a lot of the OSAXen have really gnarly syntax that causes all sorts of unforeseen interactions. Unfortunately, the core language was missing some important features, and OSAXen were the easy way to add some of that back, so it got completely out of hand rather early on.
The original team never imagined that the current syntax would be the only one. Quite the contrary, we viewed it as a syntax that HyperCard users would find familiar, but many other folks would find rather verbose.
This is funnier than you might think. Back when I worked at Apple, we had various names for the various APIs in Mac OS X. There was this big block diagram, you see, with colored boxes. The Classic mode was the Blue Box, for instance, and Cocoa was called Yellow Box. Carbon was known as Green Box (halfway between blue and yellow), and Red Box was our proposed name for a Windows emulation environment. Wow, great minds...
Well, I did a lot of the OpenDoc design work, and yes we did file some patents. They were mostly about UI issues, particularly how the composition & layout model and event handling was done.
The spec mentioned above was the official stuff. Looking back from a vantage of ten years or so, there are a lot of things I would change, but the basic design is still sound.
Actually, my current favorite in the space of such things is KParts, which does a lot of the same sorts of things OpenDoc was meant to do.
We have 4 weeks of 10,000 face captures a day. That's 280,000 face captures. This test generated 1000 false positives, and caught any of 250 people about 50% of the time passing through. That makes the system correct about 278,500 times out of 280,000 samples, according to my count (500 false negatives and 1000 false positives).
This is a failure? Is Could any human being you know do as well? Even close? And how does 99.5% correct translate to "less effective than a coin toss".
Honestly, this was pretty pitiful argument by the ACLU. I hate face recognition on unreasonable search grounds, like most people I know. However, this kind of argument doesn't help their cause! Anyone who can do a bit of arithmetic (and I think we can count on the systems designers to supply it to any decision makers who can't do math for themselves) can see for themselves that this looks pretty damn successful.
The interesting part of this, to me, is the use of the term 'potentially viral software' directly in the license terms. Thus, during litigation, the term would be bandied about in evidence, and during testimony, and so on.
Back when I did debate in school, we called this 'setting the terms of the debate', because terminology has a huge impact on how the judges think about the issue.
It's not very subtle, in this case, but it will have an impact. A useful response is to hold such terminology up to scrutiny as an object of ridicule. For instance, referring to.NET as a 'potentially viral software platform' in a license because it would be a nice way to propagate virii would be good. It muddies the opponent's attempt to set the tone of discourse, and at the same time makes a pointed comment about the traditional MS tactic of using their control of de-facto standards to 'virally' force other developers to support their initiatives.
The important thing, of course, is to do it right away before the this 'potentially viral' thing gets into common use as a term.
I can give you _my_ opinion. I was doing commercial work in Smalltalk back in 1982, at Xerox. It was heavenly! Great development tools, a really easy to program GUI, and a powerful language with extensive libraries.
Smalltalk's biggest problem, though, was "the wall" that the language put up between itself and the operating environment. Whenever you had to interact with something outside of Smalltalk, it was extremely painful. I think it eventually killed the language as a serious contender.
The "wall" wasn't there because the language designers were silly, by the way. It was a response to the fact that in the 70s when a lot of the Smalltalk thinking was being done, different OSes were really, really different. Smalltalk was portable because of "the wall", which was a big win. Today, the various OSes are much more similar, and the choice doesn't look as great.
By the way, Squeak, the successor to Smalltalk, looks very good. It still has "the wall" though, which is why I don't spend more time with it.
Where have you been hiding? Python has gotten pretty interesting, especially the nifty stuff you can do with Zope and Numeric Python. As for a CPAN equivalent, you may want to check out the Vaults of Parnassus at http://www.vex.net/parnassus/
For a language that hasn't taken off, there's a lot of stuff to be enjoyed (over 900 goodies at VoP last time I checked). Nifty net stuff, interesting numerics, GUI systems, sound and graphics libraries, and so on. Not to shabby.
I used to hack a lot more in Perl, but it got to the point where I do anything more than a few hundred lines in Python instead. It's just a lot easier to get it working and keep it working in Python.
This strikes me as a bit odd. One of Freenet's core ideas is a total lack of centralized control, even of centralized bottlenecks where opponents can monitor traffic. Taking donations, however, seems to be deliberately creating just such a target. It's like painting a big 'Ground Zero' sign out in the desert somewhere and hoping to attract missiles. I can just see the dialog now:
Oppressor #1 [Pointy haired boss amongst the oppressors]: Look! We've finally found those dastardly pirate lovers home base. Let's strike a blow against child pornographers, music pirates, and vicious terrorists everywhere! Fire the missiles!
Oppressor #2 [a uniformed flunky, who presses the button labeled 'Attack Lawyer']: Missiles away, sir. Tracking... tracking... direct hit sir, they're sucking their funding dry. Operation complete sir.
Oppressor #1: Heh. That'll show them.
Oppressor #1 [yells]: All your donations are belong to us!
Oppressor #1 [to #2]: Let's go tell the secret masters at RIAA about our victory. [They leave.]
[Meanwhile, our heros are snickering up their sleeves while they paint a big sign labelled 'Freenet Pyrate and Pedophile HQ' in big red letters on the side of Oppressor #1's house...]
I love the new shell plugin idea. Konqueror has been top-notch stuff, and adding the ability to conveniently execute shell programs and capture them to a terminal just rocks.
I've been using the embedded terminal feature to do this in KDE 2, and having a way to do it without needing to pop open a shell in advance is just nifty. I bit of configuration lets me set up development directories that are extremely convenient to use.
I've been hearing this fiction that KDE is not for serious Unix users, but this is just bull IMHO. Konqueror is easily the most productive programming environment I've ever worked with.
It would be even better if the Pippy folks made sure it runs on embedded Linux and the BSDs as well. Of course, I'd also like to see the Python folks spend a bit of time making the Pippy subset a part of their thinking. Call it "Factored Python" or some such.
This strikes me as a really useful path for Python as a whole to pursue. I really like Python's general runtime model, and an extremely lightweight version would be valuable for all sorts of things.
Slashdot Mirror
Well, I remember the monetary pain of buying textbooks, and I know a lot of kids in college today. To them, the costs of textbooks are anything but chump change.
There is indeed value there, but of course the costs for this sort of work, amortized over many copies, it comparatively tiny. And I would point to the work of places like the California Open Source Textbook Project and Flat World for examples of how very good the content can be even though produced by "alternative methods".
Like prefect42 notes, the actual reviewing that filters our the cranks and such is *also* done by the academic community, usually at no charge to the publishers.
You're quite correct, of course. I've interacted a lot with GA Tech folks over the years, and it just popped out of my fingers. Sorry, GSU!
It has amazed me how long the current academic publishing regime has lasted. This dystopian fantasy by the publishers is the logical extension of a broken business model, where the publishers provide essentially zero value yet charge enormous fees. GA Tech should use this moment as a clean break point, and demand that all campus materials be either in the public domain or be available under Creative Commons license. Award tenure based only on publications which are under CC license.
Universities need to remember that they are the folks that generate *all* the content that publishers want to use against them. They can stop giving it away to these guys any time they like. In this era of global networking, there is essentially no added value in distribution, warehousing, and organizing papers into journals. Publishers need to be reminded of this fact.
Actually, to be quite clear, the "Travelling Salesman" problem is one of traversing an arbitrary graph, which can indeed include information representing non-straight distances and preferred edges where the "good lunch places" can be found. It's a very general optimization problem, and has been effectively solved for practial use for a number of years, using the "simulated annealing" method.
You may be missing my point, though. He notes, quite clearly, that both dates appear amonst the edits on the history page. He intends to convince us that the writing process introduces errors, and does so quite convincingly if one does not analyze his own article for inconsistencies. He suggests that the 1755 date is used without comment, yet then goes to on to tell us that the original and controversial date appears quite clearly in the edit history. He happily ignores this fact, and thus fails to go on and reach the obvious conclusion. Brittanica doesn't show edit histories, and as a result any mistakes they make are more likely to stay hidden from the reader. One may believe that the Brittanica quality control processes are infallible, but it is hardly probable.
So I mostly agree with your amended timeline, except for step 3. This is where McHenry was factually incorrect. More precisely, he incorrectly assumes that the article is the only information being supplied, and this misses the fact that Wikipedia is providing a valuable source of information that Brittanica does not. Of course, if your business model is to be authoritative, then airing the dirty laundry is not terribly helpful in providing that aura of infallibility.
Wikipedia is strong precisely because it shows us all this trail of information, and gives us insight into the messy process from which summarized knowledge arises. Brittanica's business model prevents it from being strong in this way, and the author demonstrates a mind set of his own that I think is quite revealing.
I'd have to disagree. The author didn't get it. He might have, he had all of the facts in front of him, and indeed mentions some of them in the article. Yet he fails to draw the correct conclusion.
1. The author chose an article from the Wikipedia.
2. The author notes an internal inconsistency
3. The author checks through the edits, which are visible to the public.
4. The author now knows that some controversy exists about the dates, and can do further research to resolve it.
Do you see? Unlike a Brittanica article, the author can see who's been editing it. More importantly, he is given a cross reference of the other edits and changes that user has made, and can judge for himself how credible this person is, and whether they have a clear agenda or bias. At the very least, the reader has no false sense of authority.
There's little faith involved here, instead there's a system for judging credibility and an audit trail. These sorts of systems have worked well in academic settings for a very long time, and indeed are a key part of the internal quality control checks for dictionaries and encyclopedias.
His closing comment, that one cannot tell who has used the facilities beforehand, shows that in fact the author does not get it at all. Precisely the contrary, Wikipedia's strength comes from the fact that one can find out not only who has used the facilities before you, but what they did there. He saw this, yet did not understand its value.
A wonderfully constructed argument, based in incomplete facts, is not a compelling argument. One could wish that a Brittanica veteran had taken the time to do a bit more research on his topic before committing it to writing. Deliciously ironic, don't you think? A sense of false authority is the most dangerous thing an encyclopedia can give, and Wikipedia manages to avoid that almost completely. Yet here we have an authoritative figure making a very basic mistake in research.
Well, it's been about 7 years since I worked there, but my guess would be no. Not that they have any serious objection to other OSs for the hardware, but they have an OS and it serves them fairly well.
I'd really prefer they move away from Mach and towards Linux as a kernel, but there are some fairly serious changes to their graphics system that would need to be made in order to have a decent performance level atop Linux. They depend pretty heavily on Mach IPC constructs and have optimized the crap out of that path to make the OS X window server work.
Yes, we had all of these discussions. But as you doubtless know, it was not acutally possible to switch the processor between big endian and little endian mode quickly enough to run both kinds of apps in separate processes at anything like decent speeds The kernel was going to have to run either big endian or little endian, and one class of apps was going to suffer hugely on performance. That meant one thing, given that we already had a huge base of big-endian compiled apps we needed to run at close to full speed. We were going to have to shift the endianness of the NT kernel and all the apps to get decent speed.
Remember, I said practical. It was clearly possible, but business-wise it made next to no sense given the technological constraints we had to work with.
No, I'm not kidding, nor was it a brain-fart. The problem with BS detectors in the presence of too little information is that they sometimes lead you astray in a big way.
There's a lot more to getting an OS ported than just porting the kernel and a few system apps. Just because you can recompile for a platform doesn't make it commercially viable. The work to try to reorganize code so that it could run at competitive speeds on PowerPC looked pretty terrible to us. NT was terribly tied to PC architectures. It ran on other instruction sets, but they never ever caught on in a big way, remember? Ever imagine there might be a reason?
The work to try to integrate it with existing PowerPC Mac applications looked even worse. The issues with simple things like screen sharing, and keeping multiple screens going, and so on, looked prety grim to us. The graphics models of the two platforms are quite different. And there's that horrible tendency in NT to run a graphics subsystem at the core of their kernel, which looked like a real bear to keep running on Mac hardware in anything like a stable fashion.
And for all of this work, we would have gotten maybe a few dozen Windows developers to recompile and support it on our new platform, if we were lucky. We were looking at huge porting effort, and ongoing maintenance problems, for very little upside indeed.
Well, Hank, I was the guy who wrote the report at Apple that recommended we buy NeXT. It was a simple choice, really, between Be and NeXTStep. NeXT had a much more complete offering, with actual commercial developers who had written really good stuff for it. Even better, it had had a number of releases, and had a mature system for handling version upgrades. Be, as many people will recall, tended to need an application recompile for every new version, and there way no obvious simple way to solve the problem. NeXT had a mature and battle tested kernel, and a real BSD layer, neither of which could really be said of Be at the time.
We considered a lot of other OSes. We looked at NT, but it looked like it would never be practical to port to a big-endian processor. We looked at Solaris, and it was a serious contender. There was no decent UI layer, though, by the standards we used to judge such things. Remember that things like KDE and GNOME were quite young and immature at the time.
Getting back Steve was a plus for the company, but wasn't a part of our deliberations as technical folks. NeXT Looked like the best technical choice, really. Linux was simply too young in 1996 to be a serious cnsideration, even though Apple had an internal mkLinux project.
Who knows what it might have been today, given a new shot at choosing. But back then, there was nothing that stood up to NeXT given the constraints of Apple's business.
"Beware of bugs in the above code. I have only proven it correct, not tested it."
I answer: "Clearly, I am a masochist."
As one of the original designers of AppleScript, I feel compelled to mention that the syntax issue is a complete red herring. The language was originally designed to have replaceable syntax, and it could switch, in real time, between dialects with radically different syntax. The same routine would display in different language localizations, or different syntax forms, depending on user preference.
Apple had a Japanese dialect and a C-like dialect built during the development phase. These were never tested enough to release, primarily because of a management decision to shift a lot of the team over to work on OpenDoc after AppleScript's first release.
However, that said, it can be terribly frustrating to figure out the syntax of the current system. This is because a number of language extensions have been built through a mechanism known as OSAX extensions, over the years. The language elements which come from applications work pretty well, because there's a block structure which wraps them into easily detectable blocks. OSAXen, though, tend to interact globally with the syntax of everything, and a lot of the OSAXen have really gnarly syntax that causes all sorts of unforeseen interactions. Unfortunately, the core language was missing some important features, and OSAXen were the easy way to add some of that back, so it got completely out of hand rather early on.
The original team never imagined that the current syntax would be the only one. Quite the contrary, we viewed it as a syntax that HyperCard users would find familiar, but many other folks would find rather verbose.
This is funnier than you might think. Back when I worked at Apple, we had various names for the various APIs in Mac OS X. There was this big block diagram, you see, with colored boxes. The Classic mode was the Blue Box, for instance, and Cocoa was called Yellow Box. Carbon was known as Green Box (halfway between blue and yellow), and Red Box was our proposed name for a Windows emulation environment. Wow, great minds...
Well, I did a lot of the OpenDoc design work, and yes we did file some patents. They were mostly about UI issues, particularly how the composition & layout model and event handling was done.
The spec mentioned above was the official stuff. Looking back from a vantage of ten years or so, there are a lot of things I would change, but the basic design is still sound.
Actually, my current favorite in the space of such things is KParts, which does a lot of the same sorts of things OpenDoc was meant to do.
Hmmm. Lets see...
We have 4 weeks of 10,000 face captures a day. That's 280,000 face captures. This test generated 1000 false positives, and caught any of 250 people about 50% of the time passing through. That makes the system correct about 278,500 times out of 280,000 samples, according to my count (500 false negatives and 1000 false positives).
This is a failure? Is Could any human being you know do as well? Even close? And how does 99.5% correct translate to "less effective than a coin toss".
Honestly, this was pretty pitiful argument by the ACLU. I hate face recognition on unreasonable search grounds, like most people I know. However, this kind of argument doesn't help their cause! Anyone who can do a bit of arithmetic (and I think we can count on the systems designers to supply it to any decision makers who can't do math for themselves) can see for themselves that this looks pretty damn successful.
Seems to me that a watermark is a form of steganography. I wonder if these techniques would work for watermark detection?
The interesting part of this, to me, is the use of the term 'potentially viral software' directly in the license terms. Thus, during litigation, the term would be bandied about in evidence, and during testimony, and so on.
.NET as a 'potentially viral software platform' in a license because it would be a nice way to propagate virii would be good. It muddies the opponent's attempt to set the tone of discourse, and at the same time makes a pointed comment about the traditional MS tactic of using their control of de-facto standards to 'virally' force other developers to support their initiatives.
Back when I did debate in school, we called this 'setting the terms of the debate', because terminology has a huge impact on how the judges think about the issue.
It's not very subtle, in this case, but it will have an impact. A useful response is to hold such terminology up to scrutiny as an object of ridicule. For instance, referring to
The important thing, of course, is to do it right away before the this 'potentially viral' thing gets into common use as a term.
I can give you _my_ opinion. I was doing commercial work in Smalltalk back in 1982, at Xerox. It was heavenly! Great development tools, a really easy to program GUI, and a powerful language with extensive libraries.
Smalltalk's biggest problem, though, was "the wall" that the language put up between itself and the operating environment. Whenever you had to interact with something outside of Smalltalk, it was extremely painful. I think it eventually killed the language as a serious contender.
The "wall" wasn't there because the language designers were silly, by the way. It was a response to the fact that in the 70s when a lot of the Smalltalk thinking was being done, different OSes were really, really different. Smalltalk was portable because of "the wall", which was a big win. Today, the various OSes are much more similar, and the choice doesn't look as great.
By the way, Squeak, the successor to Smalltalk, looks very good. It still has "the wall" though, which is why I don't spend more time with it.
Kurt
Where have you been hiding? Python has gotten pretty interesting, especially the nifty stuff you can do with Zope and Numeric Python. As for a CPAN equivalent, you may want to check out the Vaults of Parnassus at http://www.vex.net/parnassus/
For a language that hasn't taken off, there's a lot of stuff to be enjoyed (over 900 goodies at VoP last time I checked). Nifty net stuff, interesting numerics, GUI systems, sound and graphics libraries, and so on. Not to shabby.
I used to hack a lot more in Perl, but it got to the point where I do anything more than a few hundred lines in Python instead. It's just a lot easier to get it working and keep it working in Python.
This strikes me as a bit odd. One of Freenet's core ideas is a total lack of centralized control, even of centralized bottlenecks where opponents can monitor traffic. Taking donations, however, seems to be deliberately creating just such a target. It's like painting a big 'Ground Zero' sign out in the desert somewhere and hoping to attract missiles. I can just see the dialog now:
Oppressor #1 [Pointy haired boss amongst the oppressors]: Look! We've finally found those dastardly pirate lovers home base. Let's strike a blow against child pornographers, music pirates, and vicious terrorists everywhere! Fire the missiles!
Oppressor #2 [a uniformed flunky, who presses the button labeled 'Attack Lawyer']: Missiles away, sir. Tracking... tracking... direct hit sir, they're sucking their funding dry. Operation complete sir.
Oppressor #1: Heh. That'll show them.
Oppressor #1 [yells]: All your donations are belong to us!
Oppressor #1 [to #2]: Let's go tell the secret masters at RIAA about our victory. [They leave.]
[Meanwhile, our heros are snickering up their sleeves while they paint a big sign labelled 'Freenet Pyrate and Pedophile HQ' in big red letters on the side of Oppressor #1's house...]
I love the new shell plugin idea. Konqueror has been top-notch stuff, and adding the ability to conveniently execute shell programs and capture them to a terminal just rocks.
I've been using the embedded terminal feature to do this in KDE 2, and having a way to do it without needing to pop open a shell in advance is just nifty. I bit of configuration lets me set up development directories that are extremely convenient to use.
I've been hearing this fiction that KDE is not for serious Unix users, but this is just bull IMHO. Konqueror is easily the most productive programming environment I've ever worked with.
It would be even better if the Pippy folks made sure it runs on embedded Linux and the BSDs as well. Of course, I'd also like to see the Python folks spend a bit of time making the Pippy subset a part of their thinking. Call it "Factored Python" or some such.
This strikes me as a really useful path for Python as a whole to pursue. I really like Python's general runtime model, and an extremely lightweight version would be valuable for all sorts of things.