If you have a hot water heater in your home or apartment, then you have a repository with several gallons of water. It's more important to have drinking water than hot showers...
Critical systems have always been paranoid about not forcing in anything like "fly by wire." It has only just recently entered in on some of the very fanciest of military aircraft.
By the way, since the US government has been issuing extra currency due to peoples' paranoia, this increases the basic money supply, M0, which may result in there being some extra inflation between now and February 2000. Enjoy.
Haven't people already pledged to hold the Y2K Paranoia Pledge that was discussed a day or two ago?
Oh yes, ever since RHAT incorporated, they have started requiring Alan Cox to wear ties, shave beard, wear pinstriped suits, and you don't want to hear the new dietary restrictions...
It is billed as a "mini-server," and it wouldn't be of great benefit to Cobalt to change that much.
I wouldn't mind having one to use as a little network server; the killer questions, from my perspective, are thus:
Can I add more RAM?
What software "expansion" options are there?
Can I run something like Debian on it? Or am I basically restricted to hacking on (and making cruftier) what Cobalt provides?
Note that Egghead/On-Sale have been auctioning 'em off for around $500 lately, which is rather more interesting than $1500...
Re:And the point of this being...?
on
V2 OS
·
· Score: 2
If they had fun doing it, that certainly has merit.
It's possible that the upcoming Transmeta Crusoe product may allow deployment of IA-32 on palmtops.
That's reaching a bit, of course...
If they find some interesting OS structures / abstractions, this may be useful to future implementations even if "V2" turns out to be pretty useless in and of itself.
I seldom buy DDJ on the newsstand, but almost did as a result of this article; it is most definitely a useful way of looking at the analysis of security.
The basic "tool of thought" here is that of the decision tree, which is one of the essential tools provided to us by Von Neumann in the establishment of Game Theory.
This "establishment of decision trees" can be extremely useful in organizing processes when there are a whole lot of approaches to choose from, and when you need to pick the most feasible ways of "attacking" problems.
If some good security checklists can fall out of this, that will be a useful thing...
Head back to Cap'n Crunch; there was, in the early days of the Apple ][, the idea of creating a super powerful modem that would be programmable.
By being programmable, it was inherently able to do the sorts of nefarious things that one would do with a "Blue Box" or any of the other Phone Freaking equipment.
At the time, Apple concluded that deploying a more freakworthy variation on what had just gotten Draper imprisoned would be a very bad idea.
That, of course, was a goodly dozen years ago. Time has passed, and the average computer with sound card contains 50 times as much DSP hardware as "scared off" Apple.
In effect, the modern PC can be programmed to be a phreaking monster.
Back to DVDs... If they deploy software on PCs that allows reading DVDs, and do not use some form of tamper-resistant hardware-based strong crypto, then the general purpose hardware along with general purpose software represents a potent force to completely crack anything the music folk try to use to prevent unlicensed dissemination of music.
Furthermore, even with strong crypto, of the DVD happens to be readable by a DVD drive, then copies can be made, even if the music can't be played on one's PC.
It is evident that the industry moguls are entirely clueless in this...
The "new thing," SOAP, the XML-RPC thing, is quite clearly not going to be quite enough.
It'll not be scalable enough.
For instance, there will need to be a "compression extension" because XML is verbose, thus making messages large.
It'll not be robust enough.
Thus requiring an extension so that messaging can be managed by MTS and/or MSMQ, or WTCTNY (Whatever They Call Them Next Year).
It'll not integrate well enough with whatever tools they're using next year.
None of the technologies are inherently a problem:
SOAP doesn't seem to be massively worse than XML-RPC although it's probably not as good as Casbah's LDO system.
MTS is probably not as good as Encina or Tuxedo, but is doubtless better than the nonexistent TP monitors not being deployed in departmental/workgroup systems
MSMQ may not be as good as Tuxedo, or as open as Isect, and is merely derivative of IBM MQSeries, but doesn't seem to be too bad, again being better than the asynchronous messaging systems nonexistent in non-big-iron systems
The implementations may be run-of-the-mill and derivative, but they're based on pretty good ideas, which is why it's been pretty easy for MSFT to market them.
What is a massive problem is that what gets deployed next year is liable to be massively incompatible with what is available this year.
In a sense, the only hope for developers that use the stuff is if there is some sort of "mass disconnect" where MSFT gets split into MSFT-1, MSFT-2, MSFT-3,... and this results in the tools deployed having an extra year to stay vaguely stable...
But, if someone develops an alternative that exists on a wide range of platforms, enables the productivity that X enables, and runs something as nice as Enlightenment (not to mention WindowMaker/FVWM/etc.), and something as minimal as twm, then you might find me using it as well.
Indeed. There are a host of relatively-failed graphical systems:
MGR, which had a dramatically anti-commercial license
Sun NeWS, which was too proprietary when X was less so
Smalltalk GUIs, that work iff you're using the same Smalltalk implementation
NeXtStep/OPENSTEP, which are no longer deployable because Adobe is reluctant to license the necessary DPS layer (which would also cause problems with Sun NeWS)
Berlin, BeOS, NanoGUI, and such, all may be interesting options, but until they exist on a wide range of platforms, provide the flexibility of X, and actually have substantial bodies of code that will run on 'em, they can't realistically be considered as more than wishful alternatives.
The issues coming over the ReiserFS mailing list are that the base format ( e.g. handling of things like the superblock) are being changed, and it is reasonably likely that the FS running today on 2.2.13 will not be readable by the version of ReiserFS that will is deployed next month on 2.3.x.
There is not yet agreement as to what the upgrade path should be like.
The point is that what's available a month from now will likely not "play well" with what is available right now. That's necessary in the development of a better filesystem; it is certainly not good for the deployment of this, at least not just yet.
The nice thing about Berlin is that they have sought to use some substantively new bits of infrastructure, like CORBA and OpenGL, whilst "stealing" ideas from the (essentially failed) next-generation GUI, Fresco. (Fresco probably should have been pegged as the X GUI rather than Motif, to peg its chronology...)
The problem is that Berlin utterly throws away compatibility with the huge bodies of works currently running using Motif, TK, GTK, Qt, Xt, and FLTK (to name the likely "top" GUI libraries used on X).
As a result of discarding compatibility, Berlin is pretty useless until ALL your favorite software is rewritten to use Berlin. Some emulation may be possible, but this is nontrivial, and it'll literally take years for this to be robust enough for production use.
It's not clear that TOG and XFree86 are "getting along;" what is evident is that the X committee has decided that they need to "get along" with XFree86.
It is entirely possible the people at Sun, IBM, HP, Compaq, (and possibly others) decided that as they're supporting Linux from other perspectives, that the needed to tell TOG that it needs to as well.
Convincing signs of a TOG "change of heart" would include things like:
Defining UNIX 1999 or UNIX 2000 in such a way that Linux systems could become branded as UNIX, rather than their current comments
Releasing Motif/CDE in Open Source form.
Shameless Plug: People should help Sponsor XFree86. My local Linux Users Group, NTLUG, is in the process of soliciting that members help sponsor several free software project organizations, including XFree86.
It's not clear why all the activities are going on surrounding the WTO summit; some of it doubtless relates to more purely political concerns, but I suspect that of those that get arrested/"rubberized," there is likely to be some tendancy towards what this article would consider "Ludditism."
Obviously you need to have a secure path between your web browser and the proxy, as the proxy is going to store private data, so on your own computer is the answer to that, of course.
As for the Spamazon thing; consider:
There is some art to choosing passwords. Choosing badly is a bad idea.
Happily, these days there are tools that are reasonably good at storing things you can't possibly remember. I pick formally random passwords, and cut/paste between a semi-secure application and the web browser.
The extent of the exposure to exploit at Spamazon is somewhat limited.
If you make interesting changes, such as to address, you are required to enter the credit card number.
They don't report back the credit card number.
They tend to send you email messages concerning impending orders.
This all adds up to there being pretty limited room for dramatic, not-readily-cancelled, harvestable credit exploits.
Is that to say that they are provably providing a real secure system? No. But it's not more insecure than you giving a waiter/waitress your credit card to charge a restaurant bill.
For more secure, take a look at American Express' Blue, which requires that for online sales, you have the credit card handy, and actually have it interact with one's PC. Win32-only, at this point...
I find it somewhat appalling that this is still an issue.
SSL management should get pushed out to an SSL proxy, so that there would be common support for SSL for all browsers, whether they natively "do SSL" or not.
What did you expect? Hurd was intended as a free UNIX clone, just like linux. It is just a kernel, there shouldn't be any differences above the kernel in the user space.
If there are no differences above kernel level, then there is little point to bothering with Hurd. Might as well just improve Linux a bit.
The point is twofold:
Many things about Hurd will be much the same as Linux. It has GLIBC, and anything that runs atop GLIBC on Linux should, by and large run on Hurd.
Things may not be there yet, but that's certainly the intent.
The result of this is much as you suggest, that there don't have to be a lot of differences visible in user space. Applications that run on Linux should also be able to run on Hurd.
On the other hand, Hurd uses a microkernel, has some kernel structures that are different from Linux, and allows building things that are hard/impossible on Linux.
The notion of filesystem translators, for instance, is something that Linux doesn't do.
As time goes by, if there is any merit to Hurd, the use of Hurd facilities such as translators should result in systems based on Hurd diverging from the way Linux looks.
Conclusion: Both Linux and Hurd offer many things that are similar, such as:
Multiple users
Multiple tasks
Hierarchical filesystems
GLIBC
...
which will result in them looking pretty similar in a lot of ways.
The similarities at present comes from trying to get the stuff that works on Linux to work on Hurd.
Eventually, if Hurd "goes well," the differences will emerge...
I've asked RHAT folk about why they don't consider something like Postfix, SMAIL, or the likes. I'm using Postfix, and found it a remarkably easy install.
The problem with a transition is that there's a considerable body of anti-spam code that has been specifically written for Sendmail but not for the other mailers.
RHAT adopted some of the antispam code, and has promoted it to the body of users of Red Hat Linux.
Unfortunately for the notion of moving to a newer MTA, there is both:
A forcible necessity to continue supporting sites that want to use Sendmail;
A necessity to support the same antispam functionality they have already been supporting;
The cost of supporting two MTA's at the same time.
IBM's economy is larger than that of just about any of the Third World nations.
It might not be vastly worthwhile for them to support both, but even should this be a $100M mistake, that's not going to bankrupt them. And I don't think this would be a $100M mistake...
Certainly it'll be possible to access things via TCP/IP; the problem is that this may not be terribly efficient.
The mainframe model is that I/O is made really fast by using blocking to a massive degree. Interrupts == evil; blocking == good.
The UNIX model is more oriented towards streaming; this can be mapped onto blocks, but if the blocks are real tiny, this gets real inefficient.
This is already somewhat true on a UNIX when running applications across the network; a single keystroke may initiate a couple of packets of network traffic, thereby having a single byte update result in a couple hundred bytes having to cross the net. UNIX suffers somewhat when hit by interrupt-driven programs; MVS suffers a whole lot more.
The OS/390 hardware has been tuned to do block-oriented I/O, whether we consider disk drives, printers, or terminal controllers.
This may be a neat hack; I am quite unconvinced that it will lead to a commercially viable product, and in order for it to be of any importance, it has to be commercially viable.
Countervailing consideration; if some of the following components were provided some "deep hooks" to the kernel, they could both be coded to "bare iron," and thus be fast, and harness the "blockiness" of the hardware, but also allow integration work to take place in the Linux environment:
MQSeries is an asynchronous messaging system that is used to build queue-oriented client/server systems; it is "blocky," and thus is a good fit...
DB/2 has been tuned to run pretty directly on the bare iron, and does a lot of "mass" reads/writes, again "pretty blocky."
Linux could provide a way of gluing these things to (say) a web server, and providing an easy front end to customize, whilst letting the respective components take advantage of the hardware's strengths.
A web server is also likely to represent something that can run pretty effectively on MVS.
Considerable improvements have gone into the "back end," apt-get ; while there has been some experimentation with gnome-apt and console-apt, there doesn't seem to yet be anything that unambiguously improves on dselect in terms of functionality.
With the things that have been learned from those attempts, is there likely to be some sort of dselect-ng?
Buckminster Fuller, in his book Critical Path, describes a town design where they were essentially going to put a dome over a city. The result would be that houses would not need roofs, and people would be able to essentially see across the whole town.
The size was going to be limited, not only because creating a really big dome would be prohibitive, but also because it could only work as the creation of a fairly small community.
It almost happened, but the degree of design compromise that was getting forced in by political "hacks" made it all fall through.
Computer technology is somewhat frightening in terms of just how many levels of scaling it involves.
In the BBS days, you were limited to connecting to BBSes in the local community, as LD charges to go further made anything more extensive impractical.
The Internet immediately "scales" to handling ludicrously large numbers of interconnected users. If you've got the name of:
A person's email address
A Usenet newsgroup
A web site
You have random access to that location, and little reason to have any concern about whether this be in the same city, state, country, or even continent.
Last night, I got an email message from someone in New Zealand complaining that some of my web pages were mislinked/missing. This was because I was, at that very moment, in the process of installing updates, after having just nuked the existing copies. Apparently there's not a time to do maintenance that's not "prime time" somewhere.
In the old days, Star Trek fans would have to get together in person, which limited connections to occasional "conventions" and local community meetings. With Usenet, this provides the ability for everyone to post on the same newsgroup, and with tens of thousands of fans, this results in daunting quantities of traffic.
That heads us now towards the problem... BBSes limited community sizes to the size and diversity of the people in the local community. Usenet and the Web expand this to allow literally hundreds of thousands of participants in each of a multitude of fora. Unfortunately, you can't usefully have hundreds of thousands of participants in any kind of forum. A Slashdot thread with a mere 200 messages is effectively unreadable.
The result is that only those that are, in some manner, "Extreme," wind up being prime participants. A Star Trek newsgroup will have a small set of experts (such as one might be "expert" on such) that participate usefully, and those that are less expert will either:
Be intimidated out of participating as they feel inadequate to really contribute, or
Not care that they're inadequate, and bluster through to produce whatever they wish, which leads down the road to Inane Flame Wars.
That doesn't have to be Star Trek; it can apply equally well to any other topic with many "somewhat interested parties."
This is almost exactly the same idea as how single people have a hard time connecting personally/socially in large cities even though there may be vast quantities of other singles. The vast quantity of other people is off-putting.
And the same is true of apartment hunting. Some years ago, I moved to Toronto, and started apartment hunting by acquiring copies of the local newspaper. The thousands of apartment listings were less useful than having mere dozens, as the sizable lists had too much "chaff" to plough through. I wound up using word-of-mouth, via a friend-of-a-friend, to locate a place.
Having a virtually infinite number of links is thus as bad as having no links, if you have no good way of choosing from the infinite quantities.
The main time that money is greatly needed is before the software is available. You need to build up a development team before there is software available.
Thus, for people to bounce in $10 here and there after the software is available is effectively the wrong time for this to happen.
There may be some nice people that will contribute $10 after the fact, but it is more appropriate, to my mind, to use things like CoSource, or the Free Software Bazaar, pledging payment before the fact, so that the funds are contributed towards commissioning production of free software works.
FSB, CoSource, and SourceXchange are all taking somewhat different approaches to this...
To be a dull, pragmatic reply to what was meant to be a humorous post, I'm sure this is because minors (in the US...hmmm...) can't agree to contracts such as license agreements.
I wrote:
This is also true in Canada, and is likely true in many other jurisdictions.
It's quite a dilemna; if they include components that have licensing agreements that require some degree of consent on the part of the user, they require an "adult's" consent.
It is particularly a problem for software that requires something like unto the "dastardly" MSFT EULA; it is less of an issue with Free Software, but even there, there is some need to be able to enforce the terms of GPL, XFree86 License, and other such licenses, and that can certainly be problematic for the young'uns.
A more pointed question, that isn't directly relevant to this particular situation:
Can a minor consent to release code under the GPL when they may not be legally able to establish contracts?
The fact that we might like the answer to be yes does not necessarily make it so...
Slashdot Mirror
Oh yes, ever since RHAT incorporated, they have started requiring Alan Cox to wear ties, shave beard, wear pinstriped suits, and you don't want to hear the new dietary restrictions...
I wouldn't mind having one to use as a little network server; the killer questions, from my perspective, are thus:
Can I run something like Debian on it? Or am I basically restricted to hacking on (and making cruftier) what Cobalt provides?
Note that Egghead/On-Sale have been auctioning 'em off for around $500 lately, which is rather more interesting than $1500...
That's reaching a bit, of course...
The basic "tool of thought" here is that of the decision tree, which is one of the essential tools provided to us by Von Neumann in the establishment of Game Theory.
This "establishment of decision trees" can be extremely useful in organizing processes when there are a whole lot of approaches to choose from, and when you need to pick the most feasible ways of "attacking" problems.
If some good security checklists can fall out of this, that will be a useful thing...
By being programmable, it was inherently able to do the sorts of nefarious things that one would do with a "Blue Box" or any of the other Phone Freaking equipment.
At the time, Apple concluded that deploying a more freakworthy variation on what had just gotten Draper imprisoned would be a very bad idea.
That, of course, was a goodly dozen years ago. Time has passed, and the average computer with sound card contains 50 times as much DSP hardware as "scared off" Apple.
In effect, the modern PC can be programmed to be a phreaking monster.
Back to DVDs... If they deploy software on PCs that allows reading DVDs, and do not use some form of tamper-resistant hardware-based strong crypto, then the general purpose hardware along with general purpose software represents a potent force to completely crack anything the music folk try to use to prevent unlicensed dissemination of music.
Furthermore, even with strong crypto, of the DVD happens to be readable by a DVD drive, then copies can be made, even if the music can't be played on one's PC.
It is evident that the industry moguls are entirely clueless in this...
For instance, there will need to be a "compression extension" because XML is verbose, thus making messages large.
Thus requiring an extension so that messaging can be managed by MTS and/or MSMQ, or WTCTNY (Whatever They Call Them Next Year).
None of the technologies are inherently a problem:
The implementations may be run-of-the-mill and derivative, but they're based on pretty good ideas, which is why it's been pretty easy for MSFT to market them.
What is a massive problem is that what gets deployed next year is liable to be massively incompatible with what is available this year.
In a sense, the only hope for developers that use the stuff is if there is some sort of "mass disconnect" where MSFT gets split into MSFT-1, MSFT-2, MSFT-3, ... and this results in the tools deployed having an extra year to stay vaguely stable...
Berlin, BeOS, NanoGUI, and such, all may be interesting options, but until they exist on a wide range of platforms, provide the flexibility of X, and actually have substantial bodies of code that will run on 'em, they can't realistically be considered as more than wishful alternatives.
There is not yet agreement as to what the upgrade path should be like.
The point is that what's available a month from now will likely not "play well" with what is available right now. That's necessary in the development of a better filesystem; it is certainly not good for the deployment of this, at least not just yet.
I would tend to think it highly questionable to include a filesystem before it has even entered the experimental kernel series.
Reiserfs may be close to being ready for that, but it's not quite ready for general deployment...
The problem is that Berlin utterly throws away compatibility with the huge bodies of works currently running using Motif, TK, GTK, Qt, Xt, and FLTK (to name the likely "top" GUI libraries used on X).
As a result of discarding compatibility, Berlin is pretty useless until ALL your favorite software is rewritten to use Berlin. Some emulation may be possible, but this is nontrivial, and it'll literally take years for this to be robust enough for production use.
It is entirely possible the people at Sun, IBM, HP, Compaq, (and possibly others) decided that as they're supporting Linux from other perspectives, that the needed to tell TOG that it needs to as well.
Convincing signs of a TOG "change of heart" would include things like:
Shameless Plug: People should help Sponsor XFree86. My local Linux Users Group, NTLUG, is in the process of soliciting that members help sponsor several free software project organizations, including XFree86.
It's not clear why all the activities are going on surrounding the WTO summit; some of it doubtless relates to more purely political concerns, but I suspect that of those that get arrested/"rubberized," there is likely to be some tendancy towards what this article would consider "Ludditism."
As for the Spamazon thing; consider:
- There is some art to choosing passwords. Choosing badly is a bad idea.
- The extent of the exposure to exploit at Spamazon is somewhat limited.
- If you make interesting changes, such as to address, you are required to enter the credit card number.
- They don't report back the credit card number.
- They tend to send you email messages concerning impending orders.
Is that to say that they are provably providing a real secure system? No. But it's not more insecure than you giving a waiter/waitress your credit card to charge a restaurant bill.Happily, these days there are tools that are reasonably good at storing things you can't possibly remember. I pick formally random passwords, and cut/paste between a semi-secure application and the web browser.
This all adds up to there being pretty limited room for dramatic, not-readily-cancelled, harvestable credit exploits.
For more secure, take a look at American Express' Blue, which requires that for online sales, you have the credit card handy, and actually have it interact with one's PC. Win32-only, at this point...
SSL management should get pushed out to an SSL proxy, so that there would be common support for SSL for all browsers, whether they natively "do SSL" or not.
The point here is that by doing a proxy right, once, this eliminates the need to tightly integrate crypto into all of the web browsers.
John Markovich is a photographer based in Minneapolis, MN...
If there are no differences above kernel level, then there is little point to bothering with Hurd. Might as well just improve Linux a bit.
The point is twofold:
Things may not be there yet, but that's certainly the intent.
The result of this is much as you suggest, that there don't have to be a lot of differences visible in user space. Applications that run on Linux should also be able to run on Hurd.
The notion of filesystem translators, for instance, is something that Linux doesn't do.
As time goes by, if there is any merit to Hurd, the use of Hurd facilities such as translators should result in systems based on Hurd diverging from the way Linux looks.
Conclusion: Both Linux and Hurd offer many things that are similar, such as:
- Multiple users
- Multiple tasks
- Hierarchical filesystems
- GLIBC
...
which will result in them looking pretty similar in a lot of ways.The similarities at present comes from trying to get the stuff that works on Linux to work on Hurd.
Eventually, if Hurd "goes well," the differences will emerge...
The problem with a transition is that there's a considerable body of anti-spam code that has been specifically written for Sendmail but not for the other mailers.
RHAT adopted some of the antispam code, and has promoted it to the body of users of Red Hat Linux.
Unfortunately for the notion of moving to a newer MTA, there is both:
It might not be vastly worthwhile for them to support both, but even should this be a $100M mistake, that's not going to bankrupt them. And I don't think this would be a $100M mistake...
The mainframe model is that I/O is made really fast by using blocking to a massive degree. Interrupts == evil; blocking == good.
The UNIX model is more oriented towards streaming; this can be mapped onto blocks, but if the blocks are real tiny, this gets real inefficient.
This is already somewhat true on a UNIX when running applications across the network; a single keystroke may initiate a couple of packets of network traffic, thereby having a single byte update result in a couple hundred bytes having to cross the net. UNIX suffers somewhat when hit by interrupt-driven programs; MVS suffers a whole lot more.
The OS/390 hardware has been tuned to do block-oriented I/O, whether we consider disk drives, printers, or terminal controllers.
This may be a neat hack; I am quite unconvinced that it will lead to a commercially viable product, and in order for it to be of any importance, it has to be commercially viable.
Countervailing consideration; if some of the following components were provided some "deep hooks" to the kernel, they could both be coded to "bare iron," and thus be fast, and harness the "blockiness" of the hardware, but also allow integration work to take place in the Linux environment:
Linux could provide a way of gluing these things to (say) a web server, and providing an easy front end to customize, whilst letting the respective components take advantage of the hardware's strengths.
A web server is also likely to represent something that can run pretty effectively on MVS.
With the things that have been learned from those attempts, is there likely to be some sort of dselect-ng ?
The size was going to be limited, not only because creating a really big dome would be prohibitive, but also because it could only work as the creation of a fairly small community.
It almost happened, but the degree of design compromise that was getting forced in by political "hacks" made it all fall through.
Computer technology is somewhat frightening in terms of just how many levels of scaling it involves.
The Internet immediately "scales" to handling ludicrously large numbers of interconnected users. If you've got the name of:
- A person's email address
- A Usenet newsgroup
- A web site
You have random access to that location, and little reason to have any concern about whether this be in the same city, state, country, or even continent.Last night, I got an email message from someone in New Zealand complaining that some of my web pages were mislinked/missing. This was because I was, at that very moment, in the process of installing updates, after having just nuked the existing copies. Apparently there's not a time to do maintenance that's not "prime time" somewhere.
In the old days, Star Trek fans would have to get together in person, which limited connections to occasional "conventions" and local community meetings. With Usenet, this provides the ability for everyone to post on the same newsgroup, and with tens of thousands of fans, this results in daunting quantities of traffic.
That heads us now towards the problem... BBSes limited community sizes to the size and diversity of the people in the local community. Usenet and the Web expand this to allow literally hundreds of thousands of participants in each of a multitude of fora. Unfortunately, you can't usefully have hundreds of thousands of participants in any kind of forum. A Slashdot thread with a mere 200 messages is effectively unreadable.
The result is that only those that are, in some manner, "Extreme," wind up being prime participants. A Star Trek newsgroup will have a small set of experts (such as one might be "expert" on such) that participate usefully, and those that are less expert will either:
That doesn't have to be Star Trek; it can apply equally well to any other topic with many "somewhat interested parties."
This is almost exactly the same idea as how single people have a hard time connecting personally/socially in large cities even though there may be vast quantities of other singles. The vast quantity of other people is off-putting.
And the same is true of apartment hunting. Some years ago, I moved to Toronto, and started apartment hunting by acquiring copies of the local newspaper. The thousands of apartment listings were less useful than having mere dozens, as the sizable lists had too much "chaff" to plough through. I wound up using word-of-mouth, via a friend-of-a-friend, to locate a place.
Having a virtually infinite number of links is thus as bad as having no links, if you have no good way of choosing from the infinite quantities.
Thus, for people to bounce in $10 here and there after the software is available is effectively the wrong time for this to happen.
There may be some nice people that will contribute $10 after the fact, but it is more appropriate, to my mind, to use things like CoSource, or the Free Software Bazaar, pledging payment before the fact, so that the funds are contributed towards commissioning production of free software works.
FSB, CoSource, and SourceXchange are all taking somewhat different approaches to this...
In particular, the comment Watch out, it's not for the youngins!!! began discussion on this very matter.
My response was thus, and I'll repeat it...
In response to
I wrote:
This is also true in Canada, and is likely true in many other jurisdictions.
It's quite a dilemna; if they include components that have licensing agreements that require some degree of consent on the part of the user, they require an "adult's" consent.
It is particularly a problem for software that requires something like unto the "dastardly" MSFT EULA; it is less of an issue with Free Software, but even there, there is some need to be able to enforce the terms of GPL, XFree86 License, and other such licenses, and that can certainly be problematic for the young'uns.
A more pointed question, that isn't directly relevant to this particular situation:
Can a minor consent to release code under the GPL when they may not be legally able to establish contracts?
The fact that we might like the answer to be yes does not necessarily make it so...