The goal of INVESTING is to earn money from your investment. Microsoft is a rock solid investment.
I dispute this on two levels:
Despite your nice list of good things going for the stock, Microsoft isn't a solid investement, due to their enormous sale of put options in MSFT. It can not take a downward swing without totally falling apart. Sort of a house of cards.
Ethics is a part of investing. For most people, there are reasons for not investing in the mob that go beyond the risk involved.
Ethics work good when purchasing products, etc... But when planning out your retirement, I'd think that the goal would be to invest your money in companies with a proven track record, etc.
Where does the "but" come from? Yes, that should be the goal - but it should not be the only goal. There are always secondary goals - would you kill somebody so their stock would get free so you could buy it? If not - where did you get that 'but' from?
Eivind, who does not exactly love hypocrites who don't even take the time to learn how their investments work.
I think this is due to Kerberos being much more cumbersome than ssh to set up, but Americans not having a choice - RSA is still patented there, so to use SSH you need a commerical license. This will change on september 29th.
It is questionable that what @Home claims is the problem is actually the problem. Even if it were, scanning for proxy servers would be the wrong solution.
In my opion: No, scanning isn't the wrong solution. What is wrong here is that @Home only disallow Usenet if they find an open proxy. They should disallow everything. An open proxy is an attack point against the entire Internet, and I've seen proxies running at @Home being abused for D.o.S'es against other parts of the net already.
If you are going to go for something like this, I think newpcm of FreeBSD probably is more deserving than ALSA - there was a point where I thought ALSA would make Linux beat FreeBSD, but if this post matches reality, then newpcm (which was behind) has pulled ahead - it has already effectively replaced OSS/Lite (aka VoxWare) in FreeBSD, and I expect VoxWare to be cut away any day now. I got no protests from users when I chopped off large parts of it due to version conflicts causing compilation warnings.
IMHO there's nothing moral about aiding and abetting organizations who have ripped off their customers and all but eliminated progress in my profession. Where does "refuse to help others do what you don't want them to" fit into your worldview? I give them source, they give me nothing - how can that ever be fair?
You are assuming that they don't give back any changes. From my experience, this is generally false. Companies have employees that are human, and many of the companies that base things on open source software employ open source advocates.
Changes will, in most cases, come back. Just not all of them, and perhaps not at all if what is being done is creating a new Unix clone. But this isn't common; what is common is to use the code for various types of embedded systems.
This applies somewhat to users and to an extreme with developers. As a user, a question revealing that you don't know UNIX, not just *BSD, is enough to have you shouted out the door.
Can you back this up with references to actual incidents, as opposed to rumours? It do not match my impression at all, with the exception of #freebsd on efnet, which is an has always been a cesspool (from what I hear, #unix and #linux are very similar.)
As a developer, unless you're a 20 year BSD veteran, suggest an idea or ask where you can begin to help and you should be prepared to be stomped on. Hard and repeatedly. Largely by many of the project principals.
This is not true. It match the rumours I hear from the the Linux community, but they do not match the reality I've experienced.
I entered the FreeBSD community without having much Unix experience; I'd run Linux for a few months (on a machine somebody else set up for me), and had had a login on a couple of other machines (SGIs and Suns). I was welcomed as a mailing list participant without having done any hacking on Unix itself, and as a short time Unix user. I got commit privileges after having been active on the lists for a couple of months, continously feeling them as friendly and welcoming of suggestions.
I am now regarded as one of the 'project principals' (to use your term); I have never seen anybody being flamed for asking where to help. If I ever see a developer flame somebody for that, that developer will need to defend his commit privileges. I do not consider that kind of behaviour acceptable, and neither does (as far as I can tell) the community as a whole.
When it comes to ideas, I agree that there can sometimes come a backlash. This is usually in the form of 'Show me the patches' when somebody is suggesting someting that is a lot of work, but we do have people in the community that will pounce rather hard on proposals that are bad, and where the person proposing it could have found that out by spending a small amount of time.
Review some of Matt Dillon's contributions to FreeBSD in the mailing lists. He's repeatedly helped to pull large portions of FreeBSD up to and even past their Linux equivalents.
LOL! Matt has contributed a lot, sure, but he's not "pulled things beyond their Linux equivalents" - the things he has been working on has always been further ahead in FreeBSD than in Linux. They are some of our strongest pieces.
Then consider the rationale behind the community's treatment of him.
The treatment has mainly been to not accept that he should, on his own authority, refuse to accept advice from the rest of the community, and that he would not keep direct write access to the source tree (commit privileges) unless he learned to work with the community.
Would you want to have somebody that was contiually at war with Linus write to the Linux source tree, in opposition to what Linus said was OK? One that also fought with the rest of the Linux users? I suspect not - and the FreeBSD core team felt they could not accept that situation, either.
Note: I cooperate with Matt on FreeBSD development, and consider him a brilliant programmer. I also think that he should have commit privileges (which he has now). However, I don't think he has been mistreated - he has been behaving in a way that brought him repeatedly into conflicts with people, and that had to be handled.
Unfortunately, history shows that without a license requirement the return of code doesn't happen.
This is not true. The return of code does happen - just not always. However, we do get a lot of returned code, and we get a lot of returned code from places that wouldn't have used our codebase if it had been under the GPL.
For one thing, the world would never know if GPL'd code were used in closed source. For another, who's to say that it wasn't an algorithm that got lifted? When the source is open, anybody can look and copy the approach. That's the kind of thing that gets you thrown in jail. You see, if you don't practise a cleanroom approach, it's still a derivative work. The GPL still applies.
YANAL[1]. And it is obvious. (Disclaimer: IANAL, either.)
In USL vs Berkeley, USL tried to claim this. It didn't hold water.
This is apart from the question of whether the GPL is enforcable at all; for most cases, I think it probably isn't. And the Linux users should be happy for this; an enforced (L)GPL would block large amounts of what is considered standard parts of all Linux distributions (glibc, parts of the kernel, etc). Most of the violations I've found are due to GPLers thinking they can slap the GPL over the BSD-derived licenses; they can't. Not even over the two-clause variant. (If you don't believe me, read the GPL. Carefully. If you're not good at tracking state in your head, create a matrix showing how the GPL and the BSD license interact, for each of the different software states that the GPL talks about.)
It is interesting (and hopefully relevant) to note that the notion of 'reverse time' is also necessary for what is in my opinion the most elegant and easy to use interpretation of quantum mechanics: Kramer's Transactional Interpretation of Quantum Mechanics.
This interpretation does not need observers (as in the standard Copenhagen interpretation), and thus do not suffer from the problem of needing infinite observers (in order to collapse the observer, you need an observer, who need an observer, who...).
The only concession it makes is that some particles (moving at the speed of light, and thus not experiencing time) need to move backwards in time. This is, in my opinion, a nice tradeoff.
First: You need to define what you want out of your cluster - what kind of applications it is going to run, what sort of environment you want for them, how large a cluster you want to build, whether you want to do 'free cycle stealing', and whether you want high availability. A 'cluster' is much to vague a term for it to be possible to give much advice based on just that, or even further references.
Second: SCI is orthogonal to the other two technologies - it is a special hardware network technology (Scalable Coherent Interface), originally made to support distributed shared memory. You may be thinking of the software Dolphin Interconnect Solutions provide with their SCI solutions, but as far as I know, that doesn't directly enter into the same space, either. Their web pages does certainly not indicate that it does, and my discussions with (one of?) their Linux developer(s) implied that it contained somewhat more (lock managers etc), but not in the same space. A technology that compete with SCI, though proprietary, is Myrinet. This has a longer history than SCI, and has been less plagued with problems than SCI (though SCI is supposedly quite stable now).
Third: There are a bunch of other technologies (some cross-platform, some single-platform) that compete in making it easy to build clusters. MOSIX and Beowulf are just two of them. If you give more details of what you want to achieve, I'll dig out references from my collection (made to support the development of FreeBSD-specific clustering improvements, so some types of references may be lacking, but I'll probably be able to come with at least some points to start for any wanted cluster workload.)
I still think that any code I write belongs to me. So I get to say what people can do with it. The GPL sets forth rules that protect my minimal interests: you can play with it, you can poke at it, you can change it, but no thanks, you cannot take the rights away from others that I just gave you.
Please don't think with your emotions.
No rights are taken away; instead, more possibilities are constructed. If somebody redistribute in a form with more restrictions, then people get the option of using the free version, or using the version with more restrictions (and most likely more features, as why would they otherwise put up with more restrictions?)
The result of your restrictions (the GPL) is
The programmers that get a copy of your software get fewer options
The end user get fewer options, due to the programmers
Your codebase most likely sees less use. You've just cut off all chances that proprietary developers will use your codebase and give back some of their changes. (There are both decent people among proprietary programmers, and there are a bunch of cases where it is of pure self-interest for a proprietary developer to give back changes).
You have drastically reduced your chance of "raising the bar" for proprietary developers, by setting a standard they have to be better than, as everybody could use your code if it was freely licensed.
The world sees a bunch of wasted time as people are forced to re-implement things instead of using free code.
You feel good 'cause your paranoia has been sated.
You may increase the mindshare of open source by stopping competition from commercial software, but most likely not.
You force the world towards a point where the entire cost of a software development project has to be carried by the initial user(s), before they even get to see the software.
There are your results. Do they seem worthwhile?
Personally, I feel better knowing I do as much as possible for bringing the world forward than I do from feeding my own paranoia. I don't like the thought of a world were the cost of development either go from the spare time of the developers or the pocket of the first user. Where everybody is forced to fit into the same mold, and don't even get to vote with their dollars (unless said dollars are enough to buy the entire country).
But then again, I don't use the GPL, so I don't have to worry about being the one to inflict this situation on people.
I'd call that ingratitude. And what's wrong with putting in writing that you expect a little bit of gratitude?
You are assuming a model of the world were programmers do as much programming whether they earn money from it or not. This is simply not true. You are also assuming that this is an all-or-nothing proposition. This is also not true. When I did commercial products based on a proprietary version of FreeBSD, we gave ~90% of our changes back. The last 10% was part of what paid for having those 90% developed, and were not of general interest (e.g, disabling conflicting hardware protection because we had more specific control over our hardware than FreeBSD generally does, and tuning a number of system constants to boost performance very specifically for our application while cutting performance for interactive use).
Note that there were legitimate business reasons for us to give away those of our changes we did give away:
We didn't have to re-intergrate them to use them in a new version of the OS. For changes we did for purely utilitarian reasons (and those were most of them), it is less work to have somebody else keep them integrated than re-intergrate them yourself.
We got community goodwill. This made it easier for us to influence which direction the free project went.
We kept our employees happy. I (for one) would have been screaming and shouting if I wasn't allowed to give back changes for which we didn't earn significant amounts by not giving them back.
We probably would have given them away on purely based on that being the right thing to do, but as it were, we found other good reasons, too.
I've been trying to decide whether to load FreeBSD onto a dual 266 but a lot of what I've read says that the 2.2.x kernel is better for SMP.
It all depends on your workload. The FreeBSD VM system is probably still superior to the Linux one (though Linux has seen a lot of improvements), which in many cases will make FreeBSD run faster than Linux, with or without SMP. For compilation benchmarks on an SMP system (and those may or may not be relevant for your workload), FreeBSD beat Linux easily in the last benchmark I saw.
For a threaded CPU-bound program, I would expect Linux to beat FreeBSD (though I've not tested the case). There are some scheduler changes that have just gone into FreeBSD-current (if I read my commit logs right) that should avoid cache trashing; this should give a clear speedup. We've also recently been looking at other SMP-related improvements (but none have entered the tree for a long time).
Not quite... while you are correct about the download issue, source must be available to anyone for whom binaries are available, in the same medium. I.E., if binaries are *publicly* available on CDs, source must also be *publicly* available on CDs- not just to those who pay for binaries, but also to others in the general public.
I cannot find anything in the GPL that makes it possible for me to conclude this. If you stick to your claim: Could you please provide some references? The ending paragraph of section 3 could possibly be misremembered as having that effect, but a careful reading show it as an alternative to the options in 3a/3b/3c. That's as close to finding justification as I've been able to come.
If binaries are only available to your co-workers or people within your corporation, then you need only make source available within your corporation. But - and this is a sticking point - you need to allow the people in your corporation to re-distribute the source all they want. Even bring it with them to their new employer, your competitor. Not useful for anything where you do any significant investment in the code for competitive advantage. Which is the drawback of the GPL - it stops business users from doing most of the thingsthat require an investment (and subsequent payback) with your source base, making all the 'protection' it gives you meaningless.
I boot freeBSD 3.1 and Linux 2.2.* and NT 4.0 on my SMP box and theres basically no difference between freeBSD and Linux except Linux has faster disk performance (on my hardware)
You are most likely not running the comparisons in a fair setup. The default setup of the filesystem on Linux is to gamble with the users' data (metadata is trashed on uncontrolled reboot); the default setup on FreeBSD is to not gamble with data. If you want to compare the FS speed of Linux and FreeBSD, the following comparisons are (reasonably) fair:
Linux default mode (async) vs FreeBSD in async mode
Linux default mode (async) vs FreeBSD with soft updates (in this comparison Linux is unsafe and FreeBSD safe)
Linux sync mode vs FreeBSD sync mode
The best mode for FreeBSD is usually soft updates mode; this is not the default mode due to licensing restrictions (the license the soft updates code is available under is about as restrictive as the GPL, which is much more restrictive than FreeBSD consider OK).
As for the TCP/IP stack of Linux being faster: This does not surprise me; I expect it to at the very least be faster for anything that can be micro-benchmarked, and probably as fast as the BSD stack under real world load, too. Dave S Miller has done a very good job. If we (*BSD) have an advantage for real world load, I expect it due to that not being as easy to measure, so we may have an advantage due to actually having run under real world load for a long while).
As for SMP: In my opinion, neither FreeBSD nor Linux is really up to snuff. Attempting to judge between them is really pointless.
There are people out there (MOSIX, NeXT) who don't really want to give out source, but will if they have to. So I suppose it's an evaluation of how many of those we have vs. how many will give out derived works even when they don't have to.
It is also an evaluation over how many derived works will be created, and what benefit that will lead to. I know that I have done quite a bit of FreeBSD code on paid time due to products we would never have made if FreeBSD had been under the GPL. Approx 80% of the mods I did to FreeBSD to support our product has been contributed back; the rest are either not cleaned up enough (so I won't contribute it back due to being ashamed of the state of the code, stylewise), or it is special performance tweaks for just our situation, with no value for anybody except people that would want to create a competing product.
When it comes to both MOSIX and NeXT: Both of these are examples of people that has misunderstood what they could and could not do, and has done work on GPLed codebases only due to misunderstanding. Do we really want our source of software to be people that have been fooled?
Choose a license based on your goals. Be really, really careful about evaluating how the license will bring those goals about, taking care to remember that coorporations are extremely license sensitive, and will not work on badly (from the view of them making money) licensed codebases.
Example: If you goal is to destroy the market for properitary software, use the GPL. If you goal is something else (like my goal, maximizing the amount of good open source software), choose a license that aligns with that.
From my analysis, the GPL is directly counter-productive to my goal - it is, however, effective for what seems to be Stallman's goals - forcing all software to be free software. (See especially the end of the manifesto).
A common fallacy is to believe that "all software is free software" is equivalent to "maximize the amont of free software" - it is not.
Personally, I usually choose to use a BSD-style license, in order to optimize the amount of use my sourcebase gets. If somebody use my code in a properitary product - great! They're working on the code, and are likely to send back bug-fixes and enhancements - and if they don't, I'm no worse off than I would be if they didn't use the code.
Besides, usage of free code is much more common in small, innovative comapnies than in the large juggernauts (who can usually just cross-license code anyway). Effectively, I help the innovative part of the commercial segment, kicking the juggernauts in the balls - which doesn't exactly detract from the experience:-)
Step out of that box. Quit promoing Linux as the be-all and end-all. Promo NetBSD as *the most appropriate solution* to server needs. Promo BeOS as *the most appropriate solution* to multimedia needs. And so on.
NetBSD may some day become the most appropriate solution; it isn't yet. Chuck Cranor has done a very good job on UVM, but it *is not finished*. Of the free Unices, the only one that has a virtual memory system that is state of the art as of today is FreeBSD. NetBSD and OpenBSD will probably get there; I doubt Linux will (due to the very strong defensive reactions Linus' has towards some aspects of the Linux code.) In some ways, I hope I'm wrong - it is a pity if that many people will be left with an inferior VM system:-(
That's for serving 6-8 GB/day as typical HTTP requests from a web server, NOT AN FTP SERVER. The load placed on a machine or set of machines in these two roles is very different.
I've got 4 Linux machines with dual 300 MHz PIIs and half a gig of RAM each using round robin DNS to handle a very busy web site, and it doesn't serve anywhere near 1000 gigs a day, yet it needs hardware that is much more powerfull than cdrom.com, precisely because web serving is a much harder thing than FTP serving.
You are assuming FreeBSD and Linux have identical load handling patterns - they don't. It is not inherently harder to server static HTML pages than FTP files, and if used a special light-weight HTTP server (ftp.cdrom.com use a special light weight FTP server) then I do not think it would unfeasible to serve similar amounts of HTTP data.
In order to make ftp.cdrom.com capable of transferring that much data, however, sendfile() was needed. The FreeBSD sendfile API is, if I've understood correctly, different from the Linux one, in order to be able to support HTTP. If you'd want to serve web data competitively from a Linux machine, I think you would want to implement a similar API for Linux.
You'd probably also need to do a number of mods to the Linux VM system if you want similar performance to FreeBSD; however, I can't state that conclusively, as it is a long time since I've seen any benchmarks between the two.
I'm already using squid to block banner ads _because_ if I'm not looking for ads. I suppose this'd be OK if I were searching for exactly what was being advertised, but I have a feeling the ads will be marginally relevant.
So you are a thief (stealing 2 to 5 cents worth of content for every page you visit), and you're complaining because you can't steal more, and will actually have to be part of the set of people that pay for the sites you visit.
Ooh, you have my sympathy. Poor you.
Eivind, who doesn't run any advertising-based sites, but understand how the revenue-model works.
The only reason that the GPL is so successful is that it ensures freedoms, and the one restriction is enforceable (if someone decides to add new restrictions, then someone can always hunt down the original author, theoretically).
The reason the GPL is successfull is that somebody has managed to convince people that it serves some purpose beyond killing commercial software. There are very, very few circumstances where it can do this. A useful excercise is to try to work out the exact conditions that will result in more free software due to the GPLedness of software. The clue here is to remember that people do not do development of source bases irrespective of the licenses the source bases are under, and that a company will only do something if it is good for the bottom line (or it has charitable employees).
You miss the point. Katz is distributing the "binary" (the hardcopy version), without giving away the source.
[...]
Until Katz practices what he preaches, I think he should generally be regarded as a poser.
Katz is giving away some of what he writes - an obvious example is the articles he writes for Slashdot. I don't know of anybody that gives away everything they write under a license that would qualify as 'Open Source' - even Stallman only allows redistribution of unchanged articles.
You're talking of the GPL, and thus looks like a Linux person - Linus is working on properitary intellectual property right now. In my book, that doesn't make him a poser - I hope it doesn't in yours, either.
However, given the choice between Linux and *BSD, I'll pick Linux any day of the week. Better hardware support and a better license.
"Better hardware support" is no longer true, as far as I can tell.
"Better license" is a question of viewpoint - either you want a restrictive license like the GPL because you want to kill the commercial software market, or you think that providing people with the software that fit their needs is a good thing, and thus don't want the GPL.
Of course, you could also start the paranoid game about the evil companies using your nice code and being able to do more profitable work that way than by doing quite different programming due to not having the same starting point - but we all know that which license a codebase is under influences who works on it, so it is obvious to most of us that this is just propaganda. We're also aware that talking of 'making code proprietary' just is a play of words used by GPL-zealots to try to convert those that don't really consider supplying people with what they need as evil. (Code cannot be 'made properitary' after being released under an open source license, unless all copies are lost - it is already available. Changes can be properitary to the people that make them, though - and IMO it is quite natural that they should own their own changes - it is their effort that create the changes, after all.)
Actually, as of right now, I believe we're better than Linux at least for bleeding-edge network cards. I don't know of much hardware that Linux support and FreeBSD doesn't support at the moment (the Mylex SCSI cards are the only gaping lack - there are people working on closing it); if there are specific questions, I can probably answer them.
Slashdot Mirror
I dispute this on two levels:
Ethics work good when purchasing products, etc... But when planning out your retirement, I'd think that the goal would be to invest your money in companies with a proven track record, etc.
Where does the "but" come from? Yes, that should be the goal - but it should not be the only goal. There are always secondary goals - would you kill somebody so their stock would get free so you could buy it? If not - where did you get that 'but' from?
Eivind, who does not exactly love hypocrites who don't even take the time to learn how their investments work.
Eivind.
In my opion: No, scanning isn't the wrong solution. What is wrong here is that @Home only disallow Usenet if they find an open proxy. They should disallow everything. An open proxy is an attack point against the entire Internet, and I've seen proxies running at @Home being abused for D.o.S'es against other parts of the net already.
Eivind.
Eivind.
Ethics.
Eivind.
P.S. If you think of protesting this, please be sure you know how the MSFT economy and the attention economy works.
Anonymous coward said:Could you give some precise references so we can add this to the demythification list, please?
To give just a few examples:
This is just a short list off the top of my head. There are a lot of other cases.
Eivind.
You are assuming that they don't give back any changes. From my experience, this is generally false. Companies have employees that are human, and many of the companies that base things on open source software employ open source advocates.
Changes will, in most cases, come back. Just not all of them, and perhaps not at all if what is being done is creating a new Unix clone. But this isn't common; what is common is to use the code for various types of embedded systems.
Eivind.
Can you back this up with references to actual incidents, as opposed to rumours? It do not match my impression at all, with the exception of #freebsd on efnet, which is an has always been a cesspool (from what I hear, #unix and #linux are very similar.)
As a developer, unless you're a 20 year BSD veteran, suggest an idea or ask where you can begin to help and you should be prepared to be stomped on. Hard and repeatedly. Largely by many of the project principals.
This is not true. It match the rumours I hear from the the Linux community, but they do not match the reality I've experienced.
I entered the FreeBSD community without having much Unix experience; I'd run Linux for a few months (on a machine somebody else set up for me), and had had a login on a couple of other machines (SGIs and Suns). I was welcomed as a mailing list participant without having done any hacking on Unix itself, and as a short time Unix user. I got commit privileges after having been active on the lists for a couple of months, continously feeling them as friendly and welcoming of suggestions.
I am now regarded as one of the 'project principals' (to use your term); I have never seen anybody being flamed for asking where to help. If I ever see a developer flame somebody for that, that developer will need to defend his commit privileges. I do not consider that kind of behaviour acceptable, and neither does (as far as I can tell) the community as a whole.
When it comes to ideas, I agree that there can sometimes come a backlash. This is usually in the form of 'Show me the patches' when somebody is suggesting someting that is a lot of work, but we do have people in the community that will pounce rather hard on proposals that are bad, and where the person proposing it could have found that out by spending a small amount of time.
Review some of Matt Dillon's contributions to FreeBSD in the mailing lists. He's repeatedly helped to pull large portions of FreeBSD up to and even past their Linux equivalents.
LOL! Matt has contributed a lot, sure, but he's not "pulled things beyond their Linux equivalents" - the things he has been working on has always been further ahead in FreeBSD than in Linux. They are some of our strongest pieces.
Then consider the rationale behind the community's treatment of him.
The treatment has mainly been to not accept that he should, on his own authority, refuse to accept advice from the rest of the community, and that he would not keep direct write access to the source tree (commit privileges) unless he learned to work with the community.
Would you want to have somebody that was contiually at war with Linus write to the Linux source tree, in opposition to what Linus said was OK? One that also fought with the rest of the Linux users? I suspect not - and the FreeBSD core team felt they could not accept that situation, either.
Note: I cooperate with Matt on FreeBSD development, and consider him a brilliant programmer. I also think that he should have commit privileges (which he has now). However, I don't think he has been mistreated - he has been behaving in a way that brought him repeatedly into conflicts with people, and that had to be handled.
Eivind.
This is not true. The return of code does happen - just not always. However, we do get a lot of returned code, and we get a lot of returned code from places that wouldn't have used our codebase if it had been under the GPL.
Eivind.
YANAL[1]. And it is obvious. (Disclaimer: IANAL, either.)
In USL vs Berkeley, USL tried to claim this. It didn't hold water.
This is apart from the question of whether the GPL is enforcable at all; for most cases, I think it probably isn't. And the Linux users should be happy for this; an enforced (L)GPL would block large amounts of what is considered standard parts of all Linux distributions (glibc, parts of the kernel, etc). Most of the violations I've found are due to GPLers thinking they can slap the GPL over the BSD-derived licenses; they can't. Not even over the two-clause variant. (If you don't believe me, read the GPL. Carefully. If you're not good at tracking state in your head, create a matrix showing how the GPL and the BSD license interact, for each of the different software states that the GPL talks about.)
[1] You Are Not A Lawyer.
Eivind.
This interpretation does not need observers (as in the standard Copenhagen interpretation), and thus do not suffer from the problem of needing infinite observers (in order to collapse the observer, you need an observer, who need an observer, who ...).
The only concession it makes is that some particles (moving at the speed of light, and thus not experiencing time) need to move backwards in time. This is, in my opinion, a nice tradeoff.
Eivind.
Second: SCI is orthogonal to the other two technologies - it is a special hardware network technology (Scalable Coherent Interface), originally made to support distributed shared memory. You may be thinking of the software Dolphin Interconnect Solutions provide with their SCI solutions, but as far as I know, that doesn't directly enter into the same space, either. Their web pages does certainly not indicate that it does, and my discussions with (one of?) their Linux developer(s) implied that it contained somewhat more (lock managers etc), but not in the same space. A technology that compete with SCI, though proprietary, is Myrinet. This has a longer history than SCI, and has been less plagued with problems than SCI (though SCI is supposedly quite stable now).
Third: There are a bunch of other technologies (some cross-platform, some single-platform) that compete in making it easy to build clusters. MOSIX and Beowulf are just two of them. If you give more details of what you want to achieve, I'll dig out references from my collection (made to support the development of FreeBSD-specific clustering improvements, so some types of references may be lacking, but I'll probably be able to come with at least some points to start for any wanted cluster workload.)
Eivind.
Please don't think with your emotions.
No rights are taken away; instead, more possibilities are constructed. If somebody redistribute in a form with more restrictions, then people get the option of using the free version, or using the version with more restrictions (and most likely more features, as why would they otherwise put up with more restrictions?)
The result of your restrictions (the GPL) is
There are your results. Do they seem worthwhile?
Personally, I feel better knowing I do as much as possible for bringing the world forward than I do from feeding my own paranoia. I don't like the thought of a world were the cost of development either go from the spare time of the developers or the pocket of the first user. Where everybody is forced to fit into the same mold, and don't even get to vote with their dollars (unless said dollars are enough to buy the entire country).
But then again, I don't use the GPL, so I don't have to worry about being the one to inflict this situation on people.
I'd call that ingratitude. And what's wrong with putting in writing that you expect a little bit of gratitude?
You are assuming a model of the world were programmers do as much programming whether they earn money from it or not. This is simply not true. You are also assuming that this is an all-or-nothing proposition. This is also not true. When I did commercial products based on a proprietary version of FreeBSD, we gave ~90% of our changes back. The last 10% was part of what paid for having those 90% developed, and were not of general interest (e.g, disabling conflicting hardware protection because we had more specific control over our hardware than FreeBSD generally does, and tuning a number of system constants to boost performance very specifically for our application while cutting performance for interactive use).
Note that there were legitimate business reasons for us to give away those of our changes we did give away:
We probably would have given them away on purely based on that being the right thing to do, but as it were, we found other good reasons, too.
Eivind.
It all depends on your workload. The FreeBSD VM system is probably still superior to the Linux one (though Linux has seen a lot of improvements), which in many cases will make FreeBSD run faster than Linux, with or without SMP. For compilation benchmarks on an SMP system (and those may or may not be relevant for your workload), FreeBSD beat Linux easily in the last benchmark I saw.
For a threaded CPU-bound program, I would expect Linux to beat FreeBSD (though I've not tested the case). There are some scheduler changes that have just gone into FreeBSD-current (if I read my commit logs right) that should avoid cache trashing; this should give a clear speedup. We've also recently been looking at other SMP-related improvements (but none have entered the tree for a long time).
Eivind.
I cannot find anything in the GPL that makes it possible for me to conclude this. If you stick to your claim: Could you please provide some references? The ending paragraph of section 3 could possibly be misremembered as having that effect, but a careful reading show it as an alternative to the options in 3a/3b/3c. That's as close to finding justification as I've been able to come.
If binaries are only available to your co-workers or people within your corporation, then you need only make source available within your corporation. But - and this is a sticking point - you need to allow the people in your corporation to re-distribute the source all they want. Even bring it with them to their new employer, your competitor. Not useful for anything where you do any significant investment in the code for competitive advantage. Which is the drawback of the GPL - it stops business users from doing most of the thingsthat require an investment (and subsequent payback) with your source base, making all the 'protection' it gives you meaningless.
Eivind.
You are most likely not running the comparisons in a fair setup. The default setup of the filesystem on Linux is to gamble with the users' data (metadata is trashed on uncontrolled reboot); the default setup on FreeBSD is to not gamble with data. If you want to compare the FS speed of Linux and FreeBSD, the following comparisons are (reasonably) fair:
- Linux default mode (async) vs FreeBSD in async mode
- Linux default mode (async) vs FreeBSD with soft updates (in this comparison Linux is unsafe and FreeBSD safe)
- Linux sync mode vs FreeBSD sync mode
The best mode for FreeBSD is usually soft updates mode; this is not the default mode due to licensing restrictions (the license the soft updates code is available under is about as restrictive as the GPL, which is much more restrictive than FreeBSD consider OK).As for the TCP/IP stack of Linux being faster: This does not surprise me; I expect it to at the very least be faster for anything that can be micro-benchmarked, and probably as fast as the BSD stack under real world load, too. Dave S Miller has done a very good job. If we (*BSD) have an advantage for real world load, I expect it due to that not being as easy to measure, so we may have an advantage due to actually having run under real world load for a long while).
As for SMP: In my opinion, neither FreeBSD nor Linux is really up to snuff. Attempting to judge between them is really pointless.
Eivind.
It is also an evaluation over how many derived works will be created, and what benefit that will lead to. I know that I have done quite a bit of FreeBSD code on paid time due to products we would never have made if FreeBSD had been under the GPL. Approx 80% of the mods I did to FreeBSD to support our product has been contributed back; the rest are either not cleaned up enough (so I won't contribute it back due to being ashamed of the state of the code, stylewise), or it is special performance tweaks for just our situation, with no value for anybody except people that would want to create a competing product.
When it comes to both MOSIX and NeXT: Both of these are examples of people that has misunderstood what they could and could not do, and has done work on GPLed codebases only due to misunderstanding. Do we really want our source of software to be people that have been fooled?
Eivind.
Example: If you goal is to destroy the market for properitary software, use the GPL. If you goal is something else (like my goal, maximizing the amount of good open source software), choose a license that aligns with that.
From my analysis, the GPL is directly counter-productive to my goal - it is, however, effective for what seems to be Stallman's goals - forcing all software to be free software. (See especially the end of the manifesto).
A common fallacy is to believe that "all software is free software" is equivalent to "maximize the amont of free software" - it is not.
Personally, I usually choose to use a BSD-style license, in order to optimize the amount of use my sourcebase gets. If somebody use my code in a properitary product - great! They're working on the code, and are likely to send back bug-fixes and enhancements - and if they don't, I'm no worse off than I would be if they didn't use the code.
Besides, usage of free code is much more common in small, innovative comapnies than in the large juggernauts (who can usually just cross-license code anyway). Effectively, I help the innovative part of the commercial segment, kicking the juggernauts in the balls - which doesn't exactly detract from the experience :-)
Eivind.
NetBSD may some day become the most appropriate solution; it isn't yet. Chuck Cranor has done a very good job on UVM, but it *is not finished*. Of the free Unices, the only one that has a virtual memory system that is state of the art as of today is FreeBSD. NetBSD and OpenBSD will probably get there; I doubt Linux will (due to the very strong defensive reactions Linus' has towards some aspects of the Linux code.) In some ways, I hope I'm wrong - it is a pity if that many people will be left with an inferior VM system :-(
Eivind.
I've got 4 Linux machines with dual 300 MHz PIIs and half a gig of RAM each using round robin DNS to handle a very busy web site, and it doesn't serve anywhere near 1000 gigs a day, yet it needs hardware that is much more powerfull than cdrom.com, precisely because web serving is a much harder thing than FTP serving.
You are assuming FreeBSD and Linux have identical load handling patterns - they don't. It is not inherently harder to server static HTML pages than FTP files, and if used a special light-weight HTTP server (ftp.cdrom.com use a special light weight FTP server) then I do not think it would unfeasible to serve similar amounts of HTTP data.
In order to make ftp.cdrom.com capable of transferring that much data, however, sendfile() was needed. The FreeBSD sendfile API is, if I've understood correctly, different from the Linux one, in order to be able to support HTTP. If you'd want to serve web data competitively from a Linux machine, I think you would want to implement a similar API for Linux.
You'd probably also need to do a number of mods to the Linux VM system if you want similar performance to FreeBSD; however, I can't state that conclusively, as it is a long time since I've seen any benchmarks between the two.
Eivind.
So you are a thief (stealing 2 to 5 cents worth of content for every page you visit), and you're complaining because you can't steal more, and will actually have to be part of the set of people that pay for the sites you visit.
Ooh, you have my sympathy. Poor you.
Eivind, who doesn't run any advertising-based sites, but understand how the revenue-model works.
The reason the GPL is successfull is that somebody has managed to convince people that it serves some purpose beyond killing commercial software. There are very, very few circumstances where it can do this. A useful excercise is to try to work out the exact conditions that will result in more free software due to the GPLedness of software. The clue here is to remember that people do not do development of source bases irrespective of the licenses the source bases are under, and that a company will only do something if it is good for the bottom line (or it has charitable employees).
Eivind.
[...]
Until Katz practices what he preaches, I think he should generally be regarded as a poser.
Katz is giving away some of what he writes - an obvious example is the articles he writes for Slashdot. I don't know of anybody that gives away everything they write under a license that would qualify as 'Open Source' - even Stallman only allows redistribution of unchanged articles.
You're talking of the GPL, and thus looks like a Linux person - Linus is working on properitary intellectual property right now. In my book, that doesn't make him a poser - I hope it doesn't in yours, either.
Eivind.
"Better hardware support" is no longer true, as far as I can tell.
"Better license" is a question of viewpoint - either you want a restrictive license like the GPL because you want to kill the commercial software market, or you think that providing people with the software that fit their needs is a good thing, and thus don't want the GPL.
Of course, you could also start the paranoid game about the evil companies using your nice code and being able to do more profitable work that way than by doing quite different programming due to not having the same starting point - but we all know that which license a codebase is under influences who works on it, so it is obvious to most of us that this is just propaganda. We're also aware that talking of 'making code proprietary' just is a play of words used by GPL-zealots to try to convert those that don't really consider supplying people with what they need as evil. (Code cannot be 'made properitary' after being released under an open source license, unless all copies are lost - it is already available. Changes can be properitary to the people that make them, though - and IMO it is quite natural that they should own their own changes - it is their effort that create the changes, after all.)
Eivind.
Actually, as of right now, I believe we're better than Linux at least for bleeding-edge network cards. I don't know of much hardware that Linux support and FreeBSD doesn't support at the moment (the Mylex SCSI cards are the only gaping lack - there are people working on closing it); if there are specific questions, I can probably answer them.
Eivind.