So for you, free speech only covers people within earshot...
Why did Egypt drop off the internet a few weeks ago?
Technology changes how rights are expressed over time.
Internet access is the modern equivalent of a free press.
Current protests are organized on facebook & twitter.
Capitalism works really well when you only use other peoples capital, eh? by that logic,
the government wants people to own homes, so
please pay for my house. Ill take care of it,
ensure that it is well maintained, and perhaps improve it over time. Its mine after all. and If I flip it in a year, that profits mine, ok?
Thanks for the help!
You want me to pay you to build something, so that you can own it and run it for your sole benefit, and not let or help anyone else get the same help building their business that you got for yours (cause its already built, right?)
If Im going to pay for it, you can be certain that I want some benefit out of it. I dont see why you should own it. Why not I just hire you or one of ten other people to build it for me, and I keep ownership. And I hire you or somebody else to maintain it, for say, a few years at a time, so that you dont get too comfortable. If you manage it well, then you keep the contract forever, if not, someone else takes over. yeah that would be my preference, as in exactly the way city sewers and roads and highways are usually done. National labs such as Sandia and Oak ridge are done that way too.
Now folks might sweet talk us, and say that they will own the asset for us, and guarantee us certain levels and/or qualities of service. The private sector is thrilled to get an investment and own the asset, in exchange for some conditions. Those conditions are what end up as regulations, they are the cost for getting the investment, there has to be a payback for the taxpayer providing capital for particular private sector people. But youre saying you want the capital with no strings, no regulation. Nice idea, thanks, I will keep it in mind.
I fail to see why giving you capital and a literally eternal monopoly with no strings attached maximimizes the value for my tax dollars.
If there really can be a healthy market with lots of competition (selling cars & trucks), the government should keep the heck away. If its a natural monopoly, like roads, sewage, etc... yeah, I think government ownership makes the most sense. If it isnt government owned, but the private sector comes begging for capital, then youre damn right its going to be regulated. If youre not happy with that, go find an investor/bank to help you out.
The telcos did not build the infrastructure in the vast majority of cases. In most cases, telephone companies were started as local companies, co-operatives usually, because private enterprise thought it was a crappy, complicated, and risky business and would not invest in building last mile infrastructure.
So local companies, with all sorts of incentives and tax breaks, built last mile infrastructure. Once the risk was reduced, and it became a rental income game, big telco bought out the local companies, and inherited all the perks. These networks have been taxpayer subsidized forever, and these companies have done little or nothing to contribute.
Bell, for example, doesn't actually do much of anything. All the line maintenance is contracted out anyways. The essentially act as general contractors. Risk, innovation, etc... are alien. It's all about milking clients for all they are worth, while maintaining the poorest infrastructure they can get away with.
Any new provider would ought to have access to the same advantages as Bell did, but the fundamental economic problem is that bandwidth is like roads. The most efficient number of roads between two points is 1. Competition by duplicating infrastructure is fundamentally inefficient, and is the fundamental barrier to competing with incumbents.
I would be a lot happier if bandwidth were a municipal service, like water, and it came to a local CO where various ISP's could install their PoPs and maybe local termination. Optionally, the city could
even negotiate with wholesale ISP's for bandwidth, or just stay out of it and only work on the last mile.
What is important is that the last mile stuff would be neutral, and guided by citizen interests (ie. ever more bandwidth) and not conflictual corporate ones (Bell as ISP and phone company, and Cable operator.)
See these guys? talking over terabit limits? far cry from 20 G's.
At the very least, there should be laws against "convergence" which clearly puts Cable companies in a conflict of interest when dealing with NetFlix, and other network based streaming services. A pure play ISP would be thrilled, converged cable/content providers are deeply conflicted.
the coward is using a French keyboard... the gesture would have to be culturally sensitive. For Paris, mime (yes Mime!) rolling down the car window and cocking your head outside to yell insults...
DSL? Canada has lots of third party providers. I've been using one for at least ten years.
some obvious ones: www.cia.com, www.acanac.com, www.teksavvy.com
there are dozens of others.
Are you sure you can't use them?
You state, with nothing to back up your assertion, that linux popularity (as a standin for GPL) is because of network effect. When I point out that 9 of the top 10 downloads on sf.net are GPL, and none of them are linux, you ignore it.
freebsd libc isn't nearly as popular as glibc, GPL Bourne Again Shell is far more popular than BSD shells, apache is often fronted by GPL Squid. And do let me know what BSD licensed desktop environment do you prefer...
There is no level of evidence which you will tolerate.
Regardless of a developers motivation, the only practical effect is accurately characterized.
In that case, it's the same effect of the GPL as well.
companies, given the choice, will always retain their IP
Many companies contribute code to BSD-licensed projects, and even more fund them to continue their work. In short, you're utterly wrong about the practical effect.
IBM widely publicised their billion dollar investment in Linux in 2001 alone ( http://news.cnet.com/2100-1001-249750.html ) Oracle has their own distro, and is funding btrfs. HP has made installating their printers under linux easier than on windows. The biggest contributors to linux kernel in order are: individuals 18%, Red Hat 12%, Intel with 8%, IBM and Novell with 6% each, and Oracle 3%.
The scale of corporate contribution to Linux is many orders of magnitude than anything in the BSD world. (http://apcmag.com/linux-now-75-corporate.htm)
BSD's aren't unified because the license sets up incentives for forking and keeping changes proprietary.
The various BSDs are all BSD licensed, yet they remain non-unified. Repeating your blanket assertion won't make it any more true the second time around.
If you're not going to attempt to reconcile reality with your assertions, everyone should ignore all assertions you make.
see above for evidence of the greater size of corporate contributions to GPL kernel vs. BSD system. Now you argue that any disparity of any kind results from network effect. I will point out that Linux has no shortage of court cases in it's history. have a look at sf.net where the overwhelming majority of projects use GPL or LGPL.
The top ten downloads from sf.net? 8 GPL, 1 LGPL, 1 a mix (portable apps.)
Nonsense. He can go back and re-license all of his stuff at any time. The GPL is not binding to him. He binds everyone else with it. Sure, with the GPL, you're giving up your freedom in exchange for someone else's code. It may be a reasonable trade, but it's NOT freedom.
The problem with your analysis, is that it assumes a single copyright holder. The proper way to use GPL, as is done in the linux kernel, is for all contributors to retain copyright on their contributions. In that scenario, as soon as the original author changes the license, he has to revert his code to the state it was before he accepted any contributions... So he is in the same position as anyone else. Anyone can take their marbles (and no one else's) and go home.
The security comes from the fact that in any GPL project that becomes sufficiently important, there will be distributed copyright holders, and it becomes impossible to make it non-free. That is why everyone, including the original author, has the same freedom. They can only withdraw with what they themselves have contributed.
Your assertion that Linux is more popular BECAUSE IT IS GPL'ed is utterly laughable. Any number of very liberally-licensed s
Apple stuff came from BSD, and they share so much that to any user, OS-X appears to be BSD. The history is that CMU people took the code and forked it, and the NeXt people made it proprietary and so kept it diverging for a number of years, until it was opensourced by Apple. It has remained parallel ever since.
It is an excellent example of BSD causing fragmentation to the point where you claim that it isn't BSD anymore.
If Apple stuff isn't BSD because of the kernel, then I guess Debian is?
BSD folks are talking about the most freedom for an individual work. In that sense BSD is freer than GPL.
GPL proponents are referring to the aggregate of the code being released. In that sense, GPL gives more people more access to more free code... so it is freer than BSD.
and yeah, glibc was a slip... but only partially, because Rosen argues that in spite of FSF remonstrations, there is no legal difference between gpl and lgpl.
I agree that the lack of clarity is a problem.
otoh, it isn't dangerous for anyone working with free software. It is only a problem for those who want to leverage free software in a proprietary way.
-- LGPL and GPL are the same, the distinction is not legally meaningful.
-- linking does not constitute creating a derivative work, the license will not "infect" programs which merely use a given library.
and can add that there are many proprietary applications for Linux using the glibc stack, and I have yet to hear of anyone attempting to enforce the GPL for mere use of a library.
which GPL FAQ? The FSF makes this claim, but it could be construed as propaganda on their part. Rosen, who is or was general counsel for opensource.org disagrees.
Much like a click wrap license, what the FAQ says matters less than the interpretation resulting from a court test. The FSF's spin makes use of a library equivalent to making a derived work. Rosen says this is unreasonable and will not stand up to a legal test. The GPL wikipedia page shows the various opinions.
GPL is a way to force your ideology on others - whether it's a "good" ideology or not is open to discussion.
BSD is a way to not force your ideology on others.
Which one allows more freedoms is pretty obvious.
That's true. GPL's purpose is to get more code out there, and it doesn't care if you agree or not. While BSD may provide more freedoms for the code provided, GPL provides more free code.
The GPL wants to FORCE you to provide any changes YOU made, to others.
I would argue that it's worse than that, because it's not only changes to the original code. Even if you link your code against a GPLed library you must provide your own code. I fail to see how writing a speech recognition system that uses readline somehow makes the speech engine "changes to readline", but maybe I'm just an idiot.
In this case, FSF are idiots. I'm with Larry Rosen...
According to an article in the Linux Journal, Lawrence Rosen (IP law specialist, and OSI general counsel) argues that the method of linking is mostly irrelevant to the question about whether a piece of software is a derivative work; more important is the question about whether the software was intended to interface with client software and/or libraries[41]. He states, "The primary indication of whether a new program is a derivative work is whether the source code of the original program was used [in a copy-paste sense], modified, translated or otherwise changed in any way to create the new program. If not, then I would argue that it is not a derivative work,"[41] and lists numerous other points regarding intent, bundling, and linkage mechanism. He further argues on his firm's website[42] that such "market-based" factors are more important than the linking technique.
the above is from the GPL entry on wikipedia, but he said as much in his Open Source Licensing book.
The purpose of BSD is to get code out there and perhaps make a reputation for the developer.
I expect a lot of BSD developers will step in here and call you an idiot for assuming you know what their motives are...
Regardless of a developers motivation, the only practical effect is accurately characterized.
BSD gives others freedom to make code closed and provide no freedom to downstream users. with BSD license, the freedom extends to only a depth of 1.
Except EVERYONE can go back to the original (free) code, and do with it whatever they want. You're right that it doesn't push the developer's personal agenda on everyone who wants to redistribute it, but that's not freedom, it's a different type of proprietary.
yes everyone can go back to the original, and companies, given the choice, will always retain their IP, especially if they do not think other companies will contribute theirs. Game theory tells us that, it is a lot like prisoners dilemma. The GPL makes it economically sane for a private company to contribute because they know any other company using it will have to contribute too. BSD is a recipe for poverty of contributions.
GPL tries very hard to ensure that downstream users enjoy the same freedom as those who obtain the code directly
Proprietary software does the same thing...
An important effect of this is that anyone who works on GPL code tends to make it available,
Right. You are REQUIRED to contribute your changes to the public. Using your own metric: the freedom extends to only a depth of 0.
and it has the potential to make it back into the mainstream. The mainsteam can therefore integrate and grow stronger, and accumulate improvements, where in BSD the tendency is to fragment forever. There is no incentive to contribute back to the main stream. Hence the diaspora of bsd's in contrast with the relative unity of GPL licensed software.
Now this is just stupid. The BSDs are all open source, under a single license. The fact that they aren't all unified isn't because somebody close-up the source code. It's the LSB that keeps one distro of Linux to another, largely compatible, NOT the GPL.
BSD's aren't unified because the license sets up incentives for forking and keeping changes proprietary. As for the effect of LSB, for example it specified the standard packaging format to be.rpm... ever used debian, ubuntu, arch, or gentoo?
GPL only limits freedom to the extent necessary to prevent others from removing freedoms for yet other licensees.
No, if it wanted to do that, it would simply require the original source code be provided. The GPL wants to FORCE you to provide any changes YOU made, to others.
The original author shared all his code with you, He does insist that you provide the same freedom to him and anyone else with the modifications you choose to distribute. He gives you exactly the same freedoms he has. GPL removes the incentive to keep private code.
More code is made available with more freedoms to more people for more purposes with the GPL.
Are you suggesting it's somehow easier to get the source code for (eg.) GNU tar than it is for BSD tar? I fail to see how that's even possible.
Have a look at any article analyzing contributions to the linux kernel. Many, many companies are now contributing. More code is being created. More people are getting access to more code because the GPL incentivizes reciprocity from individuals and companies.
only 3 BSD's. ok what about this list of derivatives from freebsd alone:
http://www.freebsdnews.net/systems/
which mentions:OS X, MidnightBSD, DragonflyBSD, PC-BSD, Tomahawk Desktop, Monowall, pfsens, freeNAS, hamfreesbie, trueBSD, RoFreeSBIE, GhostBSD, TinyBSD, nanoBSD, Evoke... which are afaict bsd distros...
Openbsd proudly lists their commercial spin-offs:
http://www.openbsd.org/products.html, RTMX, syscall, Genua, vantronix, Fox-IT, LegatoCRM, MyRestaurant, are essentially derivative distros of openbsd. How many of those companies contribute back to the kernel?
I will stop there.
there are three different kernels and userlands between major BSD families. Where BSD's share userlands, it is likely because they use large GPL code bases like gnome or KDE. You do not see regular exchanges of code among the BSD's and Mac OS-X for example. Do you see patches coming in from NetAPP? no?
The filers use NetApp's proprietary operating system called Data ONTAP which includes code borrowed from Berkeley Net/2 BSD Unix and other operating systems.[7] D
http://en.wikipedia.org/wiki/NetApp
The point is that there is a great deal of usage of BSD, but they are very often parallel, independent forks, and do little to make the OS family, as a whole, mature.
In contrast, There is a single linux kernel. Distros take snapshots at different times, but patches invariably make their way back to the main tree, so it is fundamentally shared. In contrast, Each BSD has their own kernel, and exchange of drivers and features is a laborious affair involving porting the program. All the linuxes get their drivers from basically the same tree (albeit often different versions.) The same goes for the userland, where substantially the same packages are used.
While there are occasional competing implementations, there aren't several kernels and basic libs being developed in parallel for the heck of it. There are not private companies taking the whole OS, extending it for their particular use, and then selling the result without contributing the extensions back to the main tree. (hello, netapp, apple, MS (tcp stack), and many other documented cases.)
GPL is about being greedy in your freedom, wanting companies and people that have the freedom to build businesses on the software have to help build the ecosystem and foundation for those who come after to do the same.
The purpose of BSD is to get code out there and perhaps make a reputation for the developer. The freedom afforded is ephemeral since BSD gives others freedom to make code closed and provide no freedom to downstream users. with BSD license, the freedom extends to only a depth of 1. Any downstream developers have the ability to close the source and license only binaries downstream, end of freedoms.
GPL tries very hard to ensure that downstream users enjoy the same freedom as those who obtain the code directly.
so the freedeom is self-replicating and goes on to those who receive code through intermediaries. There is an accrual of codes with inheritence that is inherent. Far more people have far more freedom when a GPL license is used.
An important effect of this is that anyone who works on GPL code tends to make it available, and it has the potential to make it back into the mainstream. The mainsteam can therefore integrate and grow stronger, and accumulate improvements, where in BSD the tendency is to fragment forever. There is no incentive to contribute back to the main stream. Hence the diaspora of bsd's in contrast with the relative unity of GPL licensed software.
GPL only limits freedom to the extent necessary to prevent others from removing freedoms for yet other licensees.
More code is made available with more freedoms to more people for more purposes with the GPL.
With the BDFL on staff, and speed up projects like unladen swallow, and support from a vendor like okia who want python/qt to be their one true development environment. Maybe now is the time to shift over...
Besides, having the ability to intervene at the interface between a process and the kernel, and hence be able to totally control the I/O behavior of a process, is something that, in my opinion, should be present in a modern OS. Think of all the possibilities for debugging, sandboxing, install-software, automatic dependency checking by build-tools, etc.
None of the functions you describe need to be in the kernel to be effective. For debugging, shims are fine, for sandboxing, you can use any of a variety of vm's, for install software, there are tools like fakeroot (again using libc shim.) used extensively in debian packaging.
I think that, a decade ago, static binaries made some sense. But they don't anymore for anything
but a few corner cases. In general, the arguments against static linking (binary size, memory footprint, security updates, and the current prevalence of repositories with dependency management) are now far stronger than any of the old arguments for them (essentially application developers not knowing if a particular library was present on the target... dependency management.)
There really is no excuse any more, so the libc shims works well, so there is no need to use the kernel to accomplish what you are asking. And the general rule is that anything that can be done in user space, should be done there...
if all you are doing is using strace to figure out where the program is writing, then a libc shim is probably a better idea than strace. you pre-load the shim, it tells you where the child process is writing, with no extra process, and full "recursion" support.
http://www.jayconrod.com/cgi/view_post.py?23
no, it doesn't work with statically built binaries... I think static binaries are stupid and should die. but as someone else mentioned, the only way around such things is kernel support for the function desired.
you don't want to set the priority on the network interface, any more than you want to set priority on access to/dev/sda. In both cases, it is meaningless. For network, you need to have the choice to do it by the remote ip&port combo, or the local one. It does not matter whether it is interpreted or not, they will all get to libc eventually.
For example, I would make DNS requests very high priority. I would have something like *.dns, assigned very high priority, and ptp stuff relatively low, which would help optimize browser responsiveness. If I have some data at a particular web site that is important to me, I could increase priority of i/o to that web site, versus ordinary i/o.
Someone would have to implement this to see if it actually makes any difference in real life. Typically, I find that an idea that is simple enough that isn't already done, probably has something wrong with it;-)
why is it per process/program? I suspect the real problem is that individual files should be prioritized, not processes.
kernel eventually maybe. demo in user space first
Nice is done in libc, at least the interface to handing the nice setting to the scheduler is.
This is just an added setting into the kernel's process scheduler. You'll find that a lot of people argue a lot about how to do scheduling right. The nice setting is just one constant that it inserted into an algorithm that has to exist anyways.
For I/O, traditionally there has never really been a "scheduler". The whole idea was to use the device to it's maximum capability all the time. Devices are controlled by single drivers, and the idea of preferring some blocks over others doesn't exist.
So there is no kernel level thing to hook into. You would have to add new stuff... in many places, because network and block devices don't share much below libc level.
Nowadays, there are bits and pieces such as laptop drive spinup preventers and such that perhaps do perform a bit of prioritization (stopping the spin up of drives by using cache a bit more aggresively.) But I've never seen a general mechanism.
I'm not convinced that one that worked by process is necessarily the best approach. My hunch is that it makes more sense to set a priority as a file attribute, and set i/o priorities based on what file is being accessed.
For example, A low priority job trying to write a log message might monopolize the system log for a long time because it is low priority. It makes more sense for i/o to the log to be high priority, but i/o to an application data file that is exclusively accessed by a user app be lower priority. there are a lot more cases of exclusive access locks with i/o scheduling vs. process scheduling... the benefits for i/o scheduling in the kernel probably are not that clear.
It would probably make a better case for it if someone implemented the libc case (eg. taking trickle and extending it to deal with block i/o as well, and and extending it to be system-wide, instead of per process.) to build a prototype i/o scheduler. This would give some real-world use cases. After it was thoroughly beaten upon, then folks could look at what bits of it makes sense to fold it into the kernel proper, and what is just fine in user space. fun project!
Slashdot Mirror
So for you, free speech only covers people within earshot... Why did Egypt drop off the internet a few weeks ago? Technology changes how rights are expressed over time. Internet access is the modern equivalent of a free press. Current protests are organized on facebook & twitter.
You want me to pay you to build something, so that you can own it and run it for your sole benefit, and not let or help anyone else get the same help building their business that you got for yours (cause its already built, right?)
If Im going to pay for it, you can be certain that I want some benefit out of it. I dont see why you should own it. Why not I just hire you or one of ten other people to build it for me, and I keep ownership. And I hire you or somebody else to maintain it, for say, a few years at a time, so that you dont get too comfortable. If you manage it well, then you keep the contract forever, if not, someone else takes over. yeah that would be my preference, as in exactly the way city sewers and roads and highways are usually done. National labs such as Sandia and Oak ridge are done that way too.
Now folks might sweet talk us, and say that they will own the asset for us, and guarantee us certain levels and/or qualities of service. The private sector is thrilled to get an investment and own the asset, in exchange for some conditions. Those conditions are what end up as regulations, they are the cost for getting the investment, there has to be a payback for the taxpayer providing capital for particular private sector people. But youre saying you want the capital with no strings, no regulation. Nice idea, thanks, I will keep it in mind.
I fail to see why giving you capital and a literally eternal monopoly with no strings attached maximimizes the value for my tax dollars.
If there really can be a healthy market with lots of competition (selling cars & trucks), the government should keep the heck away. If its a natural monopoly, like roads, sewage, etc... yeah, I think government ownership makes the most sense. If it isnt government owned, but the private sector comes begging for capital, then youre damn right its going to be regulated. If youre not happy with that, go find an investor/bank to help you out.
I didn't mention regulations. Do you pay taxes?
So local companies, with all sorts of incentives and tax breaks, built last mile infrastructure. Once the risk was reduced, and it became a rental income game, big telco bought out the local companies, and inherited all the perks. These networks have been taxpayer subsidized forever, and these companies have done little or nothing to contribute.
example: http://www.alts.net/ns1625/telephone.html
Bell, for example, doesn't actually do much of anything. All the line maintenance is contracted out anyways. The essentially act as general contractors. Risk, innovation, etc... are alien. It's all about milking clients for all they are worth, while maintaining the poorest infrastructure they can get away with.
Any new provider would ought to have access to the same advantages as Bell did, but the fundamental economic problem is that bandwidth is like roads. The most efficient number of roads between two points is 1. Competition by duplicating infrastructure is fundamentally inefficient, and is the fundamental barrier to competing with incumbents.
I would be a lot happier if bandwidth were a municipal service, like water, and it came to a local CO where various ISP's could install their PoPs and maybe local termination. Optionally, the city could even negotiate with wholesale ISP's for bandwidth, or just stay out of it and only work on the last mile. What is important is that the last mile stuff would be neutral, and guided by citizen interests (ie. ever more bandwidth) and not conflictual corporate ones (Bell as ISP and phone company, and Cable operator.)
http://www.muninetworks.org/content/lafayette-offers-100mbps-residential-tier-and-ruminations-bandwidth-caps
See these guys? talking over terabit limits? far cry from 20 G's.
At the very least, there should be laws against "convergence" which clearly puts Cable companies in a conflict of interest when dealing with NetFlix, and other network based streaming services. A pure play ISP would be thrilled, converged cable/content providers are deeply conflicted.
http://en.wikipedia.org/wiki/Moore's_law
the coward is using a French keyboard... the gesture would have to be culturally sensitive. For Paris, mime (yes Mime!) rolling down the car window and cocking your head outside to yell insults...
DSL? Canada has lots of third party providers. I've been using one for at least ten years. some obvious ones: www.cia.com, www.acanac.com, www.teksavvy.com there are dozens of others. Are you sure you can't use them?
freebsd libc isn't nearly as popular as glibc, GPL Bourne Again Shell is far more popular than BSD shells, apache is often fronted by GPL Squid. And do let me know what BSD licensed desktop environment do you prefer...
There is no level of evidence which you will tolerate.
In that case, it's the same effect of the GPL as well.
Many companies contribute code to BSD-licensed projects, and even more fund them to continue their work. In short, you're utterly wrong about the practical effect.
IBM widely publicised their billion dollar investment in Linux in 2001 alone ( http://news.cnet.com/2100-1001-249750.html ) Oracle has their own distro, and is funding btrfs. HP has made installating their printers under linux easier than on windows. The biggest contributors to linux kernel in order are: individuals 18%, Red Hat 12%, Intel with 8%, IBM and Novell with 6% each, and Oracle 3%. The scale of corporate contribution to Linux is many orders of magnitude than anything in the BSD world. (http://apcmag.com/linux-now-75-corporate.htm)
The various BSDs are all BSD licensed, yet they remain non-unified. Repeating your blanket assertion won't make it any more true the second time around.
If you're not going to attempt to reconcile reality with your assertions, everyone should ignore all assertions you make.
see above for evidence of the greater size of corporate contributions to GPL kernel vs. BSD system. Now you argue that any disparity of any kind results from network effect. I will point out that Linux has no shortage of court cases in it's history. have a look at sf.net where the overwhelming majority of projects use GPL or LGPL. The top ten downloads from sf.net? 8 GPL, 1 LGPL, 1 a mix (portable apps.)
http://sourceforge.net/top/toplist.php?type=downloads_week
As for the effect of LSB, for example it specified the standard packaging format to be .rpm... ever used debian, ubuntu, arch, or gentoo?
Yes, though it's no their preferred format, they ALL include utilities for handling RPMs.
It's the native format and normal idioms that we are talking about here. By your logic, BSD is linux because you can install RPM's on it: http://onlamp.com/pub/a/bsd/2006/01/12/Big_Scary_Daemons.html?page=1
Nonsense. He can go back and re-license all of his stuff at any time. The GPL is not binding to him. He binds everyone else with it. Sure, with the GPL, you're giving up your freedom in exchange for someone else's code. It may be a reasonable trade, but it's NOT freedom.
The problem with your analysis, is that it assumes a single copyright holder. The proper way to use GPL, as is done in the linux kernel, is for all contributors to retain copyright on their contributions. In that scenario, as soon as the original author changes the license, he has to revert his code to the state it was before he accepted any contributions... So he is in the same position as anyone else. Anyone can take their marbles (and no one else's) and go home.
The security comes from the fact that in any GPL project that becomes sufficiently important, there will be distributed copyright holders, and it becomes impossible to make it non-free. That is why everyone, including the original author, has the same freedom. They can only withdraw with what they themselves have contributed.
Your assertion that Linux is more popular BECAUSE IT IS GPL'ed is utterly laughable. Any number of very liberally-licensed s
If Apple stuff isn't BSD because of the kernel, then I guess Debian is?
http://wiki.debian.org/Debian_GNU/kFreeBSD_why
GPL proponents are referring to the aggregate of the code being released. In that sense, GPL gives more people more access to more free code... so it is freer than BSD.
and yeah, glibc was a slip... but only partially, because Rosen argues that in spite of FSF remonstrations, there is no legal difference between gpl and lgpl.
I can point you at Rosen's position, here: http://www.rosenlaw.com/lj19.htm which states that:
-- LGPL and GPL are the same, the distinction is not legally meaningful.
-- linking does not constitute creating a derivative work, the license will not "infect" programs which merely use a given library.
and can add that there are many proprietary applications for Linux using the glibc stack, and I have yet to hear of anyone attempting to enforce the GPL for mere use of a library.
Using your classification scheme, there are two main linux distros after all these years: Debian (and it's progeny), Redhat (and it's progeny.)
Much like a click wrap license, what the FAQ says matters less than the interpretation resulting from a court test. The FSF's spin makes use of a library equivalent to making a derived work. Rosen says this is unreasonable and will not stand up to a legal test. The GPL wikipedia page shows the various opinions.
Well said.
GPL is a way to force your ideology on others - whether it's a "good" ideology or not is open to discussion. BSD is a way to not force your ideology on others.
Which one allows more freedoms is pretty obvious.
That's true. GPL's purpose is to get more code out there, and it doesn't care if you agree or not. While BSD may provide more freedoms for the code provided, GPL provides more free code.
The GPL wants to FORCE you to provide any changes YOU made, to others.
I would argue that it's worse than that, because it's not only changes to the original code. Even if you link your code against a GPLed library you must provide your own code. I fail to see how writing a speech recognition system that uses readline somehow makes the speech engine "changes to readline", but maybe I'm just an idiot.
In this case, FSF are idiots. I'm with Larry Rosen...
According to an article in the Linux Journal, Lawrence Rosen (IP law specialist, and OSI general counsel) argues that the method of linking is mostly irrelevant to the question about whether a piece of software is a derivative work; more important is the question about whether the software was intended to interface with client software and/or libraries[41]. He states, "The primary indication of whether a new program is a derivative work is whether the source code of the original program was used [in a copy-paste sense], modified, translated or otherwise changed in any way to create the new program. If not, then I would argue that it is not a derivative work,"[41] and lists numerous other points regarding intent, bundling, and linkage mechanism. He further argues on his firm's website[42] that such "market-based" factors are more important than the linking technique.
the above is from the GPL entry on wikipedia, but he said as much in his Open Source Licensing book.
I expect a lot of BSD developers will step in here and call you an idiot for assuming you know what their motives are...
Regardless of a developers motivation, the only practical effect is accurately characterized.
Except EVERYONE can go back to the original (free) code, and do with it whatever they want. You're right that it doesn't push the developer's personal agenda on everyone who wants to redistribute it, but that's not freedom, it's a different type of proprietary.
yes everyone can go back to the original, and companies, given the choice, will always retain their IP, especially if they do not think other companies will contribute theirs. Game theory tells us that, it is a lot like prisoners dilemma. The GPL makes it economically sane for a private company to contribute because they know any other company using it will have to contribute too. BSD is a recipe for poverty of contributions.
Proprietary software does the same thing...
Right. You are REQUIRED to contribute your changes to the public. Using your own metric: the freedom extends to only a depth of 0.
Now this is just stupid. The BSDs are all open source, under a single license. The fact that they aren't all unified isn't because somebody close-up the source code. It's the LSB that keeps one distro of Linux to another, largely compatible, NOT the GPL.
BSD's aren't unified because the license sets up incentives for forking and keeping changes proprietary. As for the effect of LSB, for example it specified the standard packaging format to be .rpm... ever used debian, ubuntu, arch, or gentoo?
No, if it wanted to do that, it would simply require the original source code be provided. The GPL wants to FORCE you to provide any changes YOU made, to others.
The original author shared all his code with you, He does insist that you provide the same freedom to him and anyone else with the modifications you choose to distribute. He gives you exactly the same freedoms he has. GPL removes the incentive to keep private code.
Are you suggesting it's somehow easier to get the source code for (eg.) GNU tar than it is for BSD tar? I fail to see how that's even possible.
Have a look at any article analyzing contributions to the linux kernel. Many, many companies are now contributing. More code is being created. More people are getting access to more code because the GPL incentivizes reciprocity from individuals and companies.
Openbsd proudly lists their commercial spin-offs: http://www.openbsd.org/products.html, RTMX, syscall, Genua, vantronix, Fox-IT, LegatoCRM, MyRestaurant, are essentially derivative distros of openbsd. How many of those companies contribute back to the kernel?
I will stop there.
there are three different kernels and userlands between major BSD families. Where BSD's share userlands, it is likely because they use large GPL code bases like gnome or KDE. You do not see regular exchanges of code among the BSD's and Mac OS-X for example. Do you see patches coming in from NetAPP? no? The filers use NetApp's proprietary operating system called Data ONTAP which includes code borrowed from Berkeley Net/2 BSD Unix and other operating systems.[7] D http://en.wikipedia.org/wiki/NetApp
The point is that there is a great deal of usage of BSD, but they are very often parallel, independent forks, and do little to make the OS family, as a whole, mature.
In contrast, There is a single linux kernel. Distros take snapshots at different times, but patches invariably make their way back to the main tree, so it is fundamentally shared. In contrast, Each BSD has their own kernel, and exchange of drivers and features is a laborious affair involving porting the program. All the linuxes get their drivers from basically the same tree (albeit often different versions.) The same goes for the userland, where substantially the same packages are used.
While there are occasional competing implementations, there aren't several kernels and basic libs being developed in parallel for the heck of it. There are not private companies taking the whole OS, extending it for their particular use, and then selling the result without contributing the extensions back to the main tree. (hello, netapp, apple, MS (tcp stack), and many other documented cases.)
GPL is about being greedy in your freedom, wanting companies and people that have the freedom to build businesses on the software have to help build the ecosystem and foundation for those who come after to do the same.
GPL tries very hard to ensure that downstream users enjoy the same freedom as those who obtain the code directly. so the freedeom is self-replicating and goes on to those who receive code through intermediaries. There is an accrual of codes with inheritence that is inherent. Far more people have far more freedom when a GPL license is used.
An important effect of this is that anyone who works on GPL code tends to make it available, and it has the potential to make it back into the mainstream. The mainsteam can therefore integrate and grow stronger, and accumulate improvements, where in BSD the tendency is to fragment forever. There is no incentive to contribute back to the main stream. Hence the diaspora of bsd's in contrast with the relative unity of GPL licensed software.
GPL only limits freedom to the extent necessary to prevent others from removing freedoms for yet other licensees.
More code is made available with more freedoms to more people for more purposes with the GPL.
With the BDFL on staff, and speed up projects like unladen swallow, and support from a vendor like okia who want python/qt to be their one true development environment. Maybe now is the time to shift over ...
Mr. Shuttleworth maniacally rubbing his hands together... All your stability are belong to us!
Besides, having the ability to intervene at the interface between a process and the kernel, and hence be able to totally control the I/O behavior of a process, is something that, in my opinion, should be present in a modern OS. Think of all the possibilities for debugging, sandboxing, install-software, automatic dependency checking by build-tools, etc.
None of the functions you describe need to be in the kernel to be effective. For debugging, shims are fine, for sandboxing, you can use any of a variety of vm's, for install software, there are tools like fakeroot (again using libc shim.) used extensively in debian packaging. I think that, a decade ago, static binaries made some sense. But they don't anymore for anything but a few corner cases. In general, the arguments against static linking (binary size, memory footprint, security updates, and the current prevalence of repositories with dependency management) are now far stronger than any of the old arguments for them (essentially application developers not knowing if a particular library was present on the target... dependency management.)
There really is no excuse any more, so the libc shims works well, so there is no need to use the kernel to accomplish what you are asking. And the general rule is that anything that can be done in user space, should be done there...
if all you are doing is using strace to figure out where the program is writing, then a libc shim is probably a better idea than strace. you pre-load the shim, it tells you where the child process is writing, with no extra process, and full "recursion" support. http://www.jayconrod.com/cgi/view_post.py?23 no, it doesn't work with statically built binaries... I think static binaries are stupid and should die. but as someone else mentioned, the only way around such things is kernel support for the function desired.
For example, I would make DNS requests very high priority. I would have something like *.dns, assigned very high priority, and ptp stuff relatively low, which would help optimize browser responsiveness. If I have some data at a particular web site that is important to me, I could increase priority of i/o to that web site, versus ordinary i/o.
Someone would have to implement this to see if it actually makes any difference in real life. Typically, I find that an idea that is simple enough that isn't already done, probably has something wrong with it ;-)
why is it per process/program? I suspect the real problem is that individual files should be prioritized, not processes. kernel eventually maybe. demo in user space first
Nice is done in libc, at least the interface to handing the nice setting to the scheduler is. This is just an added setting into the kernel's process scheduler. You'll find that a lot of people argue a lot about how to do scheduling right. The nice setting is just one constant that it inserted into an algorithm that has to exist anyways.
For I/O, traditionally there has never really been a "scheduler". The whole idea was to use the device to it's maximum capability all the time. Devices are controlled by single drivers, and the idea of preferring some blocks over others doesn't exist. So there is no kernel level thing to hook into. You would have to add new stuff... in many places, because network and block devices don't share much below libc level.
Nowadays, there are bits and pieces such as laptop drive spinup preventers and such that perhaps do perform a bit of prioritization (stopping the spin up of drives by using cache a bit more aggresively.) But I've never seen a general mechanism.
I'm not convinced that one that worked by process is necessarily the best approach. My hunch is that it makes more sense to set a priority as a file attribute, and set i/o priorities based on what file is being accessed.
For example, A low priority job trying to write a log message might monopolize the system log for a long time because it is low priority. It makes more sense for i/o to the log to be high priority, but i/o to an application data file that is exclusively accessed by a user app be lower priority. there are a lot more cases of exclusive access locks with i/o scheduling vs. process scheduling... the benefits for i/o scheduling in the kernel probably are not that clear.
It would probably make a better case for it if someone implemented the libc case (eg. taking trickle and extending it to deal with block i/o as well, and and extending it to be system-wide, instead of per process.) to build a prototype i/o scheduler. This would give some real-world use cases. After it was thoroughly beaten upon, then folks could look at what bits of it makes sense to fold it into the kernel proper, and what is just fine in user space. fun project!