The BSD license is best because it's short, simple, clear, unambiguous, and fair. It also has a great track record: The programs which form the infrastructure of the Internet -- including BIND, Apache, X11, and BSD UNIX -- all use it. The availability of the BSD TCP/IP stack under the Berkeley license is largely responsible for the existence of the Internet today. Because virtually anyone can incorporate the code into a product or project, we have tremendous compatibility across a wide range of systems.
The GPL, on the other hand, is long and complex. It includes a political manifesto which is required to be included with every copy. It prevents commercial reuse of the code, which means that it is fundamentally unfair. Anyone can use the program for what he or she wants except the commercial programmer, who is precluded from incorporating it in a product that he or she does not give away. This provision was intended by the GPL's author, Richard Stallman, to reduce the salaries programmers can make for programming and thus hurt their livelihoods. See The GNU Manifesto, where Stallman explicitly states this intent:
"For more than ten years, many of the world's best programmers worked at the Artificial Intelligence Lab for far less money than they could have had anywhere else. They got many kinds of non-monetary rewards: fame and appreciation, for example. And creativity is also fun, a reward in itself.
Then most of them left when offered a chance to do the same interesting work for a lot of money.
What the facts show is that people will program for reasons other than riches; but if given a chance to make a lot of money as well, they will come to expect and demand it. Low-paying organizations do poorly in competition with high-paying ones, but they do not have to do badly if the high-paying ones are banned."
It does not seem to me that a programmer who wants to encourage his colleagues to contribute to a project should adopt a license whose explicit purpose is "ban" them from making a better living than a grad student!
The GPL also deters standardization by preventing commercial and closed-source products from using the same code base as open source products.
In short, the GPL is a poor choice. The time-honored BSD license, or the MIT X license (which is nearly identical), is a much better way to go.
Genes found in nature: 0 years. If there's one thing that should not be patented at all, it's any mechanism that was around before the inventor was born.;-)
Stanford patented the Hartley Transform -- an integral transform that resembles the Fourier transform but does not require complex arithmetic. That patent, which recently expired, was never overturned.
Are there any particular hardware-based optimizations that you had in mind?
Hardware could help with such things as COW (having to keep several layers of information around after a fork is painful and resource-intensive) and page coloring. In fact, one could do much better than the current page coloring algorithms -- which are speculative -- if the hardware gave better information about the caching scheme. Currently, caching is a "black box" to the OS. The associativity, etc. of the cache may even depend on the amount of RAM installed.
In general, anything that allows the software to avoid marking a page invalid to "catch" an access is a big improvement.
This is scary. AOL used to have a "bring your own access" plan which allowed subscribers to pay less if they logged in via their own ISPs. This spared AOL's dial-ins and gave them coverage where they had no local number.
But now that AOL owns CompuServe's dial-up network, and is merging with Time-Warner, their attitude has changed. After all, by forcing the user to log in via their software, they can force users to view advertising. (They recently informed users that their "marketing preferences" -- which eliminate advertising -- expire after one year, letting the ads through again.) And AOL can also regulate content. If they firewall a site on the Net, users have no recourse.
These developments raise red flags about the proposed merger.
On the local scene, a member of our local community network has at least one family that cnanot log on after installing AOL 5.0. We're getting ready to send an all-points bulletin warning members of the danger. (We once encouraged members to join AOL as well if they wanted AOL's exclusive content; we obviously cannot do that anymore.)
We also need to go and help that family, plus any others who run into problems as a result of AOL 5.0. Can anyone provide a succinct technical explanation of what AOL 5.0 is doing when it installs, so that we can get them back online fast?
I think the Berkeley folks learned from their mistakes with early versions of BSD on the VAX. The early VM system was too dependent on the details of the VAX hardware, making it difficult to port that code to other systems.
I'm not saying that the code should be hardware-dependent, but rather that it's ripe for a few hardware assists.
Back in 1984, I joined an online community that -- at least for awhile -- actually worked. It was a small BBS that ran on a heavily souped-up Apple ][ with a 10 MB hard disk (considered to be huge and quite expensive at the time). It had a single dial-up line, and ran at only 300 baud until I modified it to run at 1200. (To do this, I litarally soldered bits of paper clips into the circuitry. The owner of the system was so totally a software geek that he didn't have any other kind of usable wire in the house!)
The name of the BBS was Stuart ][. (The name "Stuart" was chosen, nearly at random, by the author; as far as I know, it has no deeper meaning. The "][" was because it was a second impmentation; "Stuart I", the older one, wasn't tree-structured.) The tree structure was inspired by Dave Winer's outline-structured BBS, which he called LBBS (the "Living BBS").
It was, perhaps, the expense of long distance calls (almost no users were local) and the fact that it could take only one call at a time that kept the population of the system from exploding. (One advantage of this was that it really was possible to keep up with every message.) There was no private e-mail (due, probably, to laziness; the owner said that he had planned to write code for it but never got around to it), so all conversations were out in the open. And the tree-structured nature of the system required a certain amount of abstract thinking to sort out. (You really had to read a tutorial -- not a long one, but it did consist of several screens of material -- to get going.)
The board was, until it fell apart due to some unwise (and, some would say, perfidious) actions on the part of the owner, unlike any other. The level of discourse was light years ahead of what one saw on other systems at the time. Many people who are now rich, famous, or both -- names you'd likely know, at least if you work with computers -- stopped in, often under pseudonyms. (I won't name names, since I'm not sure that all of them want to be identified or want this little bit of history to be dredged up.) My name on the system was "Rogue."
Other BBSes began to copy the system's tree structure. XBBS and Pyrzqxgl, two BBSes in the Santa Cruz, CA area, used a nearly identical interface. Steve Manes' Magpie HQ, in New York, was also a derivative. (This was the BBS on which Rahul Dhesi, Thom Henderson, and Phil Katz debated compression software. Soon after, Thom sued Katz for writing PKARC, a program compatible with Thom's ARC. The lawsuit, in turn, caused the hacker community to shun Thom and his products. Soon after, ARC was a distant memory and PKPAK -- later renamed PKZIP -- was the de facto standard compressor for Microsoft platforms.) The WELL, the famous conferencing system run by The Point Foundation/Whole Earth Catalog people, likewise drew some inspiration from the Stuart ][ community, though it was not a tree-structured system.
Years after Stuart ][ fell apart, former users had such fond memories that they took an old snapshot of the tree-structured database and converted it to a tree of Web pages. It can be viewed at http://www.ccil.org:6502/0.html.
One of the things one notices, when reading this article, is that FreeBSD's VM system -- like many -- is forced to do a great deal in software and assume the "lowest common denominator" as far as hardware is concerned.
The old segmentation hardware in Intel processors embodies some fantastic concepts but is a horrible implementation. Worse still, it was not fixed when the 32-bit i386 came out. So, it sits idle most of the time and does the VM system in FreeBSD no good. What should be there instead?
Methanol isn't super-toxic (NutraSweet releases one molecule of methanol per molecule of aspartame as it's broken down by the body). But it's toxic enough to trigger all kinds of laws -- particulary fire codes and notification laws. (Every laptop and cartridge sold in the state of California will have to have a sticker saying that it contains materials that can cause cancer. Yes, really.) OSHA might be all over it too, because by using the laptop you'd be working with toxic liquids.
Because methanol is volatile, squirting and leaking at high temperatures really could be problems. Maybe just annoying, but not if it got you in the eye.
...it's not. As far as I know, ATAPI drives still don't implement key SCSI features such as tagged command queueing. In fact, most of the time there is no way to tell for sure when a write has been committed from the drive's cache to the media.
With ATAPI and LBA, what we essentially could have is the equivalent of SCSI but over a cheap cable with standard TTL drivers and no fancy termination (the things that make SCSI expensive). We could get nearly the same speeds -- or at least, we could if we were willing to put a single drive on each IDE interface (which certainly isn't out of the question).
Maybe, if it's dropping out of the SCSI business, WD can be persuaded to flesh out its ATAPI command sets so as to keep customers. Wouldn't hurt to ask.
Seriously, the big problem with using a fuel cell is that they get hot. In fact, they do not run at full efficiency until they're hot.
A fuel cell phone (I suppose that's what you'd call a cell phone powered by a fuel cell;-) would generate at least enough heat to make you uncomfortable if it were placed in your vest pocket, and at worst could set your jacket on fire.
Another problem is that alcohol is volatile and poisonous. On a hot day, or if the cartridge were removed before it were fully empty, you could get a shot of methanol in the eye.
I think there are some minor problems to be worked out here.
...imagine how much better the CPU could run if the translation overhead were minimal, or if all of the translation were done in advance.
Wouldn't it be funto develop a virtual processor -- one which never existed in hardware -- that was designed to map particularly well onto the current Crusoe CPUs? (It probably would not map badly to future ones.) It'd also be fun to precompile critical sections so that dynamic translation would not be necessary for those portions of the code -- the equivalent of custom microcode.
What you're seeing, in many of the arrogant messages on Slashdot, are attacks not truly from people but from memes. Memes do not care whether people are hurt as they spread (witness the disatrous events that they've caused throughout human history). Their goal is merely to propagate themselves.
Ironically, a call for courteous discussion and critical thinking is itself a meme that can retard the spread of others. This is especially true when those other memes require the suspension of disbelief or unquestioning acceptance of dogma. To propagate, memes with these characteristics must "defeat," if you will, the memes that attempt to keep the environment pleasant. The Muslim meme which promises salvation as a reward for spreading the faith via the sword is a good example.
Take a step back from a rant, raves, or flame on this site or elsewhere and you'll see not a person trying to hurt a person but a meme trying to spread. Its goal: to defeat contradictory memes, and propagate, at all costs. In this process, civility has often proven to be less important than silencing alternative ideas and quelling skepticism. (That's the reason why religions -- which are themselves complex bundles of memes -- invented the sin or crime of heresy.) The people who are hurt or driven away are, in a very real sense, innocent bystanders caught in the crossfire.
It's clear, from the presentation, that this is a processor targeted at the mobile and embedded markets, not the mainstream desktop or server market. Most of the ideas are those of Dave Ditzel, formerly of Sun, who architected Sparc. Some are also those of Colin Hunter (formerly of Hunter and Ready) who first made a serious effort to do dynamic machine code translation. Not surprisingly, both now work for Transmeta.
Ditzel, since his days in academia, has been a champion of the philosophy that compilers and optimizers can make simple, less capable hardware outdo more powerful hardware. We'll see if this is so. (This approach didn't help Sun; it's unclear if it will help Transmeta.)
The biggest potential problem of the architecture, whose emphasis is on power savings, is choppy performance due to unexpected pauses for code translation and/or "shifting gears" from low power to high-performance modes. I don't know enough about the details yet to evaluate the impact of these issues. If I can actually test a machine with the chip in it I'll be able to say more.
For incorporating OpenSSH (which other projects are now using); for actually auditing the existing code rather than merely adding lots of superfluous new features; for becoming, undisputedly, the world's most secure UNIX-like OS. The project is run on a shoestring and needs the cash, unlike Mozilla (which gets big bucks from AOL) and GNOME (supported by several organizations including the cash-rich FSF). It should be at the top of the ballot.
Since none of the current candidates are particularly interesting, I'd like to nominate the BSD Daemon Girl as a write-in candidate for the "Best Dressed" award. As the picture at http://www.gci-net.com/~u sers/f/fluke/comdex/bsdgirl1.jpg shows, she very much deserves the honor -- certainly more than any candidate on the ballot.
Re:Why not just use BSD license?-why indeed!
on
Hole in GNU GPL?
·
· Score: 1
Would you be pissed off if you wrote a program and then someone took it, under the BSD license, and decided to sell it??? Without giving you any of their 'hard-earned' cash?
Not at all. When I give something away, then I give it away. I don't become spiteful if the recipient does unusually well by my gift.
Also, note that since any code I publish under the BSD license is available to anyone for free, anyone who does make money by using it will have had to add substantial value to it. (Otherwise, people will go for the free version.) So, anyone who does make money using the code has earned it, fair and square.
--Brett Glass
Re:Why not just use BSD license?-why indeed
on
Hole in GNU GPL?
·
· Score: 1
The BSD license benefits everyone. The GPL is designed to help some people but hurt a specific group: commercial programmers. This also harms the general population by hindering or even preventing the development of better commercial products.
In short, there's no contest. The GPL is an instrument of spite; the BSD license is an instrument of freedom.
In the "intense voting" ballot, I noted that OpenBSD was left out of the "most improved project" category (even though it was mentioned several times in the discussion and arguably is. Likewise, Brian Behlendorf was left out of the "unsung heroes" category, Tim O'Reilly out of the "advocate" category, and the BSD Daemon Girl -- definitely among the best dressed and most attractive open source advocates -- out of the "best dressed" category. (None of the nominees in this last category is in any way remarkable -- except for RMS, who might gain votes cast in jest.) I still want to vote for these people. Why aren't they on the ballot?
--Brett Glass
Interesting concept! Let's flesh it out.
on
Hole in GNU GPL?
·
· Score: 1
Suppose I formed a non-profit mutual benefit society called "The Software Sharing Club." The club would be organized as a non-profit corporation -- all perfectly legal and upfront. Anyone could join.
It is indeed possible that, within this club, members could exchange software derived from GPLed software without being required to reveal source.
Now, suppose, as a commercial software vendor, I place in my license for a software package the condition that the user join the "Software Sharing Club" before using the software. I agree to pay the user's membership fee.
This might make it legal to put GPLed code in the product without opening my source. Hmmmm.
Why should anyone believe you on this subject any more than Stallman?
Actually, I'm not asking you to believe me, I'm asking you to believe Stallman himself -- in his more candid moments, rather than when he puts on a false face and preaches "freedom" as a way of advancing his agenda. That's why I've purposely quoted him -- and provided the sources so you can see that I am not quoting him out of context.
I can also draw on accounts from reliable third parties who witnessed the genesis of the GPL. But Richard's own words, written before he began to conceal his agenda or spoken when he feels safe stating his true intentions, are the most persuasive evidence.
You very obviously have a large chip on your shoulder about this,
What you're seeing is not a chip on the shoulder, but rather a warning from someone who has a very good track record when it comes to spotting the long term consequences of current events. Throughout my career, I have spotted important trends and forthcoming problems -- for example, Microsoft's anticompetitive practices and their likely effects -- years earlier than most. But few in public forums have listened. (In the case of Microsoft, I predicted what has now unfolded back in 1989 on CompuServe's COMPLANG forum. I was told that I was alarmist. Then, it all came true.)
and careful quoting of someone can "prove" just about anything.
That's why I cite my sources: so that readers can see for themselves that I'm not quoting out of context.
Most of those whose software is licensed under the GPL have no choice as to the licensing, because they are contributing to a project whose code has been "infected" by the GPL.
I don't understand this claim at all. Most GPLed software I can think of off the top of my head was written more or less from scratch, so this wouldn't really apply. Except for stuff that uses GPLed libraries like readline and libapt, projects are under the GPL because someone thought it was a good idea.
The person who started the project, usually. From then on, there's no choice for anyone else who might want to contribute, as code licensed under a different license will not be accepted.
Richard Stallman, in fact, insists that anyone who contributes to a "GNU" project sign all rights to the code over to the FSF. I find this to be particularly interesting in that Richard would call this behavior on the part of anyone else "hoarding." Ironically, it's hoarding when Richard does it, too: the purpose is to build up an "arsenal" of code to use in his war against commercial programmers and software vendors.
You don't need to know Richard well to see that what he craves is power and control.
Four. And all are specialized, which means that there's good reason for them to exist.
How many forks of the Linux kernel?
There are dozens of incompatible Linux releases. Most use similar kernels (though Red Hat and Caldera both supply special modules of their own), but the distributions are nonetheless much less compatible than the BSDs are with one another. Which shows that the GPL confers not one whit of advantage in this realm.
The GPL doesn't foster fragmentation, it darn near prohibits it.
No, it does not. Linux is already very fragmented. The kernel, a very small percentage of the code, provides only a small amount of somewhat common ground.
Nobody can make a profit, in the long run, selling GPL'd software
Agreed. And this is the nasty part of the GPL: it is intended to prevent programmers from making even a reasonable profit from their hard work. This is well documented historical fact.
A commercial market for GPL code is feasible - Red Hat is proving this *today.*
Red Hat is losing money despite being a market leader. This is a proof of infeasibility, not feasibility.
the point is that if I release code under a non-viral license, someone can take my code, add on to it, and then release it under their own commercial license. They benefit from my work; I and the community at large do not benefit from theirs.
You have already reduced the market value of your work to zero by licensing it under the GPL. That person therefore has not deprived you of any income. To say that he has "taken" something from you is spiteful. You gave a gift, and now you're annoyed because a recipient has benefited "too much" from it? If you're that mean-spirited, you shouldn't have given it.
Well, I guess we'd have to defer to the IRS examiners who review the FSF's submissions every year and qualify them as a 501(c)(3).
Actually, they don't review them thoroughly every year. After about 5 years, reviews are only triggered if the IRS sees an egregious violation of the rules (e.g. excessive unrelated business income). This is as per an examiner I interviewed just yesterday as a result of this discussion.
Developing a large body of software to help the citizen's of the US (and the world) through software reuse is a scientific and an educational endeavor.
According to the examiner, a "scientific" organization must be doing bona fide new research, preferably Federally funded and resulting in articles in respected scientific journals. The FSF does not. Its work consists almost exclusively of REimplementing commercial products so as to undercut for-profit companies. It makes no new scientific discoveries, publishes no articles in refereed journals, and does not allow the fruits of its work to be used by everyone. (Commercial software developers cannot feasibly use GPLed code.)
It likewise does not qualify as an educational institution. According to the IRS examiner to whom I spoke, an educational institution must have a curriculum and classes. In most cases, it must grant some form of credential -- such as diplomas, credit, or degrees. And it should be credentialed or accredited itself. The FSF doesn't qualify.
Certainly, the FSF software has greatly aided education by providing high quality free software for education and research.
The FSF doesn't exist exclusively to serve educational or research institutions and does not limit its benefits to them. So, again, it cannot be considered to be an educational or research institution.
The FSF's Web site also hints at other factors which disqualify it.
I invite you to ask the IRS itself about this rather than taking my word: The FSF does not qualify as a bona fide 501(c)(3).
--Brett Glass
Re:The GPL has much bigger problems than this.
on
Hole in GNU GPL?
·
· Score: 1
And I flatly deny your contention that it's impossible to make "an honest living" out of free software. The coders at Redhat + Cygnus, and the scads of other free software programmers who were let in on the IPOs would certainly differ with you. But I suppose the stocks aren't an honest living in your estimation (in which case I wonder how you think the proprietary programmers are making their livings?).
The paper windfalls enjoyed by those who got in early on the Red Hat and VA Linux IPOs were not "an honest living" -- in fact, it wasn't a wage at all. That money belongs to other people who foolishly bought into the Ponzi scheme which is our current overinflated stock market. And it certainly wasn't payment for work that made money; Red Hat has not made a dime. Due to the GPL, it is actually unlikely to do so. The GPL prevents it from owning what it sells. I therefore predict that Red Hat will never be profitable.
I stand corrected as to the history of the GPL but I still contend that those who use(d) the GPL had to make the concious choice of using the GPL'd code.
Well, of course they did! What I am saying, though, is that they may have made that choice for the wrong reason. Or they may have not had any feasible alternative. (The GPL "locks itself in," soe once it's used in a project, it precludes other options.)
Slashdot Mirror
The GPL, on the other hand, is long and complex. It includes a political manifesto which is required to be included with every copy. It prevents commercial reuse of the code, which means that it is fundamentally unfair. Anyone can use the program for what he or she wants except the commercial programmer, who is precluded from incorporating it in a product that he or she does not give away. This provision was intended by the GPL's author, Richard Stallman, to reduce the salaries programmers can make for programming and thus hurt their livelihoods. See The GNU Manifesto , where Stallman explicitly states this intent:
It does not seem to me that a programmer who wants to encourage his colleagues to contribute to a project should adopt a license whose explicit purpose is "ban" them from making a better living than a grad student!
The GPL also deters standardization by preventing commercial and closed-source products from using the same code base as open source products.
In short, the GPL is a poor choice. The time-honored BSD license, or the MIT X license (which is nearly identical), is a much better way to go.
--Brett Glass
Genes found in nature: 0 years. If there's one thing that should not be patented at all, it's any mechanism that was around before the inventor was born. ;-)
I agree with you about the rest, though. See my article at http://boardwatch.internet.com /mag/99/dec/bwm62.html, which makes a similar point as it discusses the coming expiration of the RSA patent.
--Brett Glass
--Brett
Hardware could help with such things as COW (having to keep several layers of information around after a fork is painful and resource-intensive) and page coloring. In fact, one could do much better than the current page coloring algorithms -- which are speculative -- if the hardware gave better information about the caching scheme. Currently, caching is a "black box" to the OS. The associativity, etc. of the cache may even depend on the amount of RAM installed.
In general, anything that allows the software to avoid marking a page invalid to "catch" an access is a big improvement.
--Brett
But now that AOL owns CompuServe's dial-up network, and is merging with Time-Warner, their attitude has changed. After all, by forcing the user to log in via their software, they can force users to view advertising. (They recently informed users that their "marketing preferences" -- which eliminate advertising -- expire after one year, letting the ads through again.) And AOL can also regulate content. If they firewall a site on the Net, users have no recourse.
These developments raise red flags about the proposed merger.
On the local scene, a member of our local community network has at least one family that cnanot log on after installing AOL 5.0. We're getting ready to send an all-points bulletin warning members of the danger. (We once encouraged members to join AOL as well if they wanted AOL's exclusive content; we obviously cannot do that anymore.)
We also need to go and help that family, plus any others who run into problems as a result of AOL 5.0. Can anyone provide a succinct technical explanation of what AOL 5.0 is doing when it installs, so that we can get them back online fast?
--Brett Glass
I'm not saying that the code should be hardware-dependent, but rather that it's ripe for a few hardware assists.
--Brett
The name of the BBS was Stuart ][. (The name "Stuart" was chosen, nearly at random, by the author; as far as I know, it has no deeper meaning. The "][" was because it was a second impmentation; "Stuart I", the older one, wasn't tree-structured.) The tree structure was inspired by Dave Winer's outline-structured BBS, which he called LBBS (the "Living BBS").
It was, perhaps, the expense of long distance calls (almost no users were local) and the fact that it could take only one call at a time that kept the population of the system from exploding. (One advantage of this was that it really was possible to keep up with every message.) There was no private e-mail (due, probably, to laziness; the owner said that he had planned to write code for it but never got around to it), so all conversations were out in the open. And the tree-structured nature of the system required a certain amount of abstract thinking to sort out. (You really had to read a tutorial -- not a long one, but it did consist of several screens of material -- to get going.)
The board was, until it fell apart due to some unwise (and, some would say, perfidious) actions on the part of the owner, unlike any other. The level of discourse was light years ahead of what one saw on other systems at the time. Many people who are now rich, famous, or both -- names you'd likely know, at least if you work with computers -- stopped in, often under pseudonyms. (I won't name names, since I'm not sure that all of them want to be identified or want this little bit of history to be dredged up.) My name on the system was "Rogue."
Other BBSes began to copy the system's tree structure. XBBS and Pyrzqxgl, two BBSes in the Santa Cruz, CA area, used a nearly identical interface. Steve Manes' Magpie HQ, in New York, was also a derivative. (This was the BBS on which Rahul Dhesi, Thom Henderson, and Phil Katz debated compression software. Soon after, Thom sued Katz for writing PKARC, a program compatible with Thom's ARC. The lawsuit, in turn, caused the hacker community to shun Thom and his products. Soon after, ARC was a distant memory and PKPAK -- later renamed PKZIP -- was the de facto standard compressor for Microsoft platforms.) The WELL, the famous conferencing system run by The Point Foundation/Whole Earth Catalog people, likewise drew some inspiration from the Stuart ][ community, though it was not a tree-structured system.
Years after Stuart ][ fell apart, former users had such fond memories that they took an old snapshot of the tree-structured database and converted it to a tree of Web pages. It can be viewed at http://www.ccil.org:6502/0.html.
--Brett Glass
The old segmentation hardware in Intel processors embodies some fantastic concepts but is a horrible implementation. Worse still, it was not fixed when the 32-bit i386 came out. So, it sits idle most of the time and does the VM system in FreeBSD no good. What should be there instead?
--Brett Glass
Because methanol is volatile, squirting and leaking at high temperatures really could be problems. Maybe just annoying, but not if it got you in the eye.
--Brett Glass
With ATAPI and LBA, what we essentially could have is the equivalent of SCSI but over a cheap cable with standard TTL drivers and no fancy termination (the things that make SCSI expensive). We could get nearly the same speeds -- or at least, we could if we were willing to put a single drive on each IDE interface (which certainly isn't out of the question).
Maybe, if it's dropping out of the SCSI business, WD can be persuaded to flesh out its ATAPI command sets so as to keep customers. Wouldn't hurt to ask.
--Brett Glass
A fuel cell phone (I suppose that's what you'd call a cell phone powered by a fuel cell ;-) would generate at least enough heat to make you uncomfortable if it were placed in your vest pocket, and at worst could set your jacket on fire.
Another problem is that alcohol is volatile and poisonous. On a hot day, or if the cartridge were removed before it were fully empty, you could get a shot of methanol in the eye.
I think there are some minor problems to be worked out here.
--Brett Glass
Wouldn't it be funto develop a virtual processor -- one which never existed in hardware -- that was designed to map particularly well onto the current Crusoe CPUs? (It probably would not map badly to future ones.) It'd also be fun to precompile critical sections so that dynamic translation would not be necessary for those portions of the code -- the equivalent of custom microcode.
How about it, Transmeta?
--Brett Glass
Ironically, a call for courteous discussion and critical thinking is itself a meme that can retard the spread of others. This is especially true when those other memes require the suspension of disbelief or unquestioning acceptance of dogma. To propagate, memes with these characteristics must "defeat," if you will, the memes that attempt to keep the environment pleasant. The Muslim meme which promises salvation as a reward for spreading the faith via the sword is a good example.
Take a step back from a rant, raves, or flame on this site or elsewhere and you'll see not a person trying to hurt a person but a meme trying to spread. Its goal: to defeat contradictory memes, and propagate, at all costs. In this process, civility has often proven to be less important than silencing alternative ideas and quelling skepticism. (That's the reason why religions -- which are themselves complex bundles of memes -- invented the sin or crime of heresy.) The people who are hurt or driven away are, in a very real sense, innocent bystanders caught in the crossfire.
--Brett Glass
Ditzel, since his days in academia, has been a champion of the philosophy that compilers and optimizers can make simple, less capable hardware outdo more powerful hardware. We'll see if this is so. (This approach didn't help Sun; it's unclear if it will help Transmeta.)
The biggest potential problem of the architecture, whose emphasis is on power savings, is choppy performance due to unexpected pauses for code translation and/or "shifting gears" from low power to high-performance modes. I don't know enough about the details yet to evaluate the impact of these issues. If I can actually test a machine with the chip in it I'll be able to say more.
--Brett Glass
--Brett Glass
Since none of the current candidates are particularly interesting, I'd like to nominate the BSD Daemon Girl as a write-in candidate for the "Best Dressed" award. As the picture at http://www.gci-net.com/~u sers/f/fluke/comdex/bsdgirl1.jpg shows, she very much deserves the honor -- certainly more than any candidate on the ballot.
Not at all. When I give something away, then I give it away. I don't become spiteful if the recipient does unusually well by my gift.
Also, note that since any code I publish under the BSD license is available to anyone for free, anyone who does make money by using it will have had to add substantial value to it. (Otherwise, people will go for the free version.) So, anyone who does make money using the code has earned it, fair and square.
--Brett Glass
In short, there's no contest. The GPL is an instrument of spite; the BSD license is an instrument of freedom.
--Brett
--Brett Glass
It is indeed possible that, within this club, members could exchange software derived from GPLed software without being required to reveal source.
Now, suppose, as a commercial software vendor, I place in my license for a software package the condition that the user join the "Software Sharing Club" before using the software. I agree to pay the user's membership fee.
This might make it legal to put GPLed code in the product without opening my source. Hmmmm.
--Brett Glass
Actually, I'm not asking you to believe me, I'm asking you to believe Stallman himself -- in his more candid moments, rather than when he puts on a false face and preaches "freedom" as a way of advancing his agenda. That's why I've purposely quoted him -- and provided the sources so you can see that I am not quoting him out of context.
I can also draw on accounts from reliable third parties who witnessed the genesis of the GPL. But Richard's own words, written before he began to conceal his agenda or spoken when he feels safe stating his true intentions, are the most persuasive evidence.
You very obviously have a large chip on your shoulder about this,
What you're seeing is not a chip on the shoulder, but rather a warning from someone who has a very good track record when it comes to spotting the long term consequences of current events. Throughout my career, I have spotted important trends and forthcoming problems -- for example, Microsoft's anticompetitive practices and their likely effects -- years earlier than most. But few in public forums have listened. (In the case of Microsoft, I predicted what has now unfolded back in 1989 on CompuServe's COMPLANG forum. I was told that I was alarmist. Then, it all came true.)
and careful quoting of someone can "prove" just about anything.
That's why I cite my sources: so that readers can see for themselves that I'm not quoting out of context.
I don't understand this claim at all. Most GPLed software I can think of off the top of my head was written more or less from scratch, so this wouldn't really apply. Except for stuff that uses GPLed libraries like readline and libapt, projects are under the GPL because someone thought it was a good idea.
The person who started the project, usually. From then on, there's no choice for anyone else who might want to contribute, as code licensed under a different license will not be accepted.
Richard Stallman, in fact, insists that anyone who contributes to a "GNU" project sign all rights to the code over to the FSF. I find this to be particularly interesting in that Richard would call this behavior on the part of anyone else "hoarding." Ironically, it's hoarding when Richard does it, too: the purpose is to build up an "arsenal" of code to use in his war against commercial programmers and software vendors.
You don't need to know Richard well to see that what he craves is power and control.
--Brett Glass
Four. And all are specialized, which means that there's good reason for them to exist.
How many forks of the Linux kernel?
There are dozens of incompatible Linux releases. Most use similar kernels (though Red Hat and Caldera both supply special modules of their own), but the distributions are nonetheless much less compatible than the BSDs are with one another. Which shows that the GPL confers not one whit of advantage in this realm.
The GPL doesn't foster fragmentation, it darn near prohibits it.
No, it does not. Linux is already very fragmented. The kernel, a very small percentage of the code, provides only a small amount of somewhat common ground.
Nobody can make a profit, in the long run, selling GPL'd software
Agreed. And this is the nasty part of the GPL: it is intended to prevent programmers from making even a reasonable profit from their hard work. This is well documented historical fact.
A commercial market for GPL code is feasible - Red Hat is proving this *today.*
Red Hat is losing money despite being a market leader. This is a proof of infeasibility, not feasibility.
the point is that if I release code under a non-viral license, someone can take my code, add on to it, and then release it under their own commercial license. They benefit from my work; I and the community at large do not benefit from theirs.
You have already reduced the market value of your work to zero by licensing it under the GPL. That person therefore has not deprived you of any income. To say that he has "taken" something from you is spiteful. You gave a gift, and now you're annoyed because a recipient has benefited "too much" from it? If you're that mean-spirited, you shouldn't have given it.
--Brett Glass
Actually, they don't review them thoroughly every year. After about 5 years, reviews are only triggered if the IRS sees an egregious violation of the rules (e.g. excessive unrelated business income). This is as per an examiner I interviewed just yesterday as a result of this discussion.
Developing a large body of software to help the citizen's of the US (and the world) through software reuse is a scientific and an educational endeavor.
According to the examiner, a "scientific" organization must be doing bona fide new research, preferably Federally funded and resulting in articles in respected scientific journals. The FSF does not. Its work consists almost exclusively of REimplementing commercial products so as to undercut for-profit companies. It makes no new scientific discoveries, publishes no articles in refereed journals, and does not allow the fruits of its work to be used by everyone. (Commercial software developers cannot feasibly use GPLed code.)
It likewise does not qualify as an educational institution. According to the IRS examiner to whom I spoke, an educational institution must have a curriculum and classes. In most cases, it must grant some form of credential -- such as diplomas, credit, or degrees. And it should be credentialed or accredited itself. The FSF doesn't qualify.
Certainly, the FSF software has greatly aided education by providing high quality free software for education and research.
The FSF doesn't exist exclusively to serve educational or research institutions and does not limit its benefits to them. So, again, it cannot be considered to be an educational or research institution.
The FSF's Web site also hints at other factors which disqualify it.
I invite you to ask the IRS itself about this rather than taking my word: The FSF does not qualify as a bona fide 501(c)(3).
--Brett Glass
The paper windfalls enjoyed by those who got in early on the Red Hat and VA Linux IPOs were not "an honest living" -- in fact, it wasn't a wage at all. That money belongs to other people who foolishly bought into the Ponzi scheme which is our current overinflated stock market. And it certainly wasn't payment for work that made money; Red Hat has not made a dime. Due to the GPL, it is actually unlikely to do so. The GPL prevents it from owning what it sells. I therefore predict that Red Hat will never be profitable.
--Brett Glass
Well, of course they did! What I am saying, though, is that they may have made that choice for the wrong reason. Or they may have not had any feasible alternative. (The GPL "locks itself in," soe once it's used in a project, it precludes other options.)
--Brett Glass