Agreed. Before the change, I had my text input area sized to be exactly one line of text high, and it would grow by itself if it needed to. The change was a bit annoying for a couple days, but really, I have more important things to worry about.
The general answer is that features and preferences don't have zero cost. They take work to write and test, and work in the future to maintain. Unless you have actually worked on the code base in question, you have no place suggesting how much work it is.
Having said that, some of the Pidgin developers are the most stubborn, inflexible, egotistical OSS developers I've ever had the misfortune to have to deal with. (Not all of them, though; some of them seem to be great people.)
Many times we have to put up with stupid and poorly thought out "features" in OSS software and our only recourse is to "submit a patch". How is that your only recourse? You can also use a proprietary solution that you pay for. When you pay for something, you generally (though not always) get more of a say in how it works.
Lose the sense of entitlement; you're getting this software for free, you know.
And, while I'm not among them, there are many who consider X to be a horrible design failure where windowing systems are concerned.
There's also Kerberos. While it's a great auth solution, MIT's implementation of it is just plain frightening to read... let alone modify. Though I suppose it's been a good 4 years since I've had to work with it.
Depends on who you ask, who you are, what you make of it, and what you want from it. Some people use it because it's free, others because it's better, and still others for ideological reasons.
For example, in the US, you can waive your 5th amendment right of protection from self-incrimination by agreeing to testify in a criminal case in which you are the defendant.
Open a terminal on your Mac and type "locate plist". There are loads of them. Having to edit plist files on a Mac is surely rarer than needing to edit the registry on a Windows box or a conf file on a Linux box, but it happens, sometimes.
Until a Linux desktop is as easy, or easier than it's competitors it will fail to get a decent market share. And that isn't even enough. Otherwise Apple would have much more market share than it does now. They're at, what, around 7% now?
He's only saying that the "intelligent design" crowd tends to feed off so-called "scientific mistakes" and tries to use these mistakes to discredit evolutionary theory. He's warning people against making evolutionary claims for developments in humans that are based on weak or no evidence, because if/when evidence becomes available to refute these wild speculations, "real science" looks bad.
Huh? MacOS X supports IPv6 out of the box. The only (admittedly important) thing that doesn't work is autoconfiguring DNS servers. But most Linux systems and all Windows systems will generally have that same problem as well (the resolver on WinXP isn't even capable of doing IPv6 DNS queries). To be fair, at least with Linux you can set it up yourself; not sure if you can on a Mac.
For me, I'd leave home around 10.30am for a noon flight. I live within 20 minutes of a major airport (and 30 minutes from another major airport). Arrive an hour before the flight, checkin and security takes 20-25 minutes in my experience, get to the gate 5-10 minutes before they start boarding. If security takes a little longer than usual, bonus: I board the plane right as I get to the gate and don't have to wait.
However, I think you miss the point that many people (e.g. OP and myself too) consider the case of linking-against-header to NOT be a derived work. And of course many other people disagree, but this issue has not been decided in court, so neither side can claim a definitive opinion. Ok, gotcha. At least I understand your point of view here, even if I don't agree.
So are you saying that I can write a closed-source program and link it against a GPLed library? I'm only using the header files and using its public interface. That sounds wrong to me and essentially makes LGPL = GPL.
It's a blatant double standard. Either GPL with a linking exception is or is not allowed to call code marked with EXPORT_SYMBOL_GPL. You can't have it both ways. Therefore, any code in the kernel that provides a linking exception---basically almost anything that exports a module interface---should not be allowed to call these functions unless this wrapper is also allowed to call them. Not really. It's similar to the legal concept in DMCA/copyright of "significant non-infringing use." Clearly, the primary purpose of ndiswrapper is to load binary modules. If another part of the kernel or another kernel module is designed to load GPLed modules -- even if it's theoretically possible to load non-GPL modules, then I'd say letting it use GPLONLY symbols is ok. If the author of this hypothetical module wants to be able to use GPLONLY symbols, he should advertise the module license as GPL. If a user then goes and modifies the module to be able to load binary modules, that's not the fault of the author.
Though again it's a matter of licensing -- if a module reports itself as "GPL with linking exception", I'd expect it to be denied access to GPLONLY modules, and I'm pretty sure that's how it works today. ndiswrapper was getting around this by claiming to be GPL in the past; now it looks like there's an explicit check for ndiswrapper in the kernel that will deny it access to GPLONLY symbols, even if it tells the kernel it's just plain old GPL.
What's the last time the retirement age increased? And note that a larger fraction of people are opting for early retirement, though this tends to fluctuate somewhat. Is this really true? Just because the so-called traditional "retirement age" doesn't increase, it doesn't mean people aren't working later in life. I recall reading not too long ago that people were indeed retiring later (yes, I know, "I read somewhere" isn't a particularly credible source, but I can't remember where I read it). Useless personal anecdote: my father is in his early 60s, solid middle class, and is planning to "retire" soon. And by "retire" I mean retire from his current job (because his retirement benefits will start suffering if he stays much longer) and find a new job. He's done the numbers and doesn't think he can live at a level he's happy with for the rest of his life based on his savings, retirement package, etc.
This is true, and if the average family in the U.S. were having more like 6-7 children I agree that it would be hard to say which direction the flow goes. But at barely replacement levels of child-bearing, I'm pretty sure the flow is from young to old. According to this, the population of the US is increasing by about 90% each year (as of last April). How is that "barely replacement"? For every person that dies, we get 1.9 births per year.
If it were the other way around, the standard of living would decrease with time, which is not what happens based on observational data. Good point, though I imagine more factors influence this than simple direction of wealth movement.
True. I'm not suggesting there's any decent way to hedge against complete monetary system collapse. I sure wish I could think of one, though! Well, if you do... ^_~
You're missing my point. The child is a NET POSITIVE economically on society, yet a NET NEGATIVE on the family. The US economy, tax base, etc., benefits from the family having one more kid, but that family and its existing children loses out economically by having one more kid. So of course, the family has to weigh the emotional benefits against the financial costs of the additional child. That decision, across 300 million Americans, produces a non economically optimal rate of population growth. Ok, I'll buy that. But many people in this thread seem to consider the childless as "free riders" on society, which is a characterization I object to. The solution here is to fix the system! Make the decision to have a child less of a net negative, or maybe even a net zero or net positive for a family. Personally I'm not sure a net positive is a good idea. While a family experiences a net economic negative as a result of having a child, presumably they do so because they expect to derive a net positive in other ways (emotional positive, continuing the family name, etc.). I imagine making it a net economic positive to have a child would also only encourage overpopulation.
No, but the problem was not the massive baby boomer population, it was the MUCH SMALLER population spawned from them. Economically, that makes sense, but pragmatically, it's foolish. That kind of population growth isn't sustainable over the long term. We have limited physical space and natural resources, and limited technology to exploit those resources we do have. The solution is to give the finger to those who caused the overpopulation, but that tends to be difficult in practice.
Should the old couple that didn't have kids and therefore had more money to invest, two incomes the entire time, etc., be allowed, in old age, to take the wealth/economic benefit created by the old couple with four kids at appropriate it for themselves? If it really were appropriation as you say, sure, I'd agree with you. But the old couple with four kids didn't create the economic benefit. The four kids did. That it cost the old couple to prepare those four kids to be an economic positive is immaterial to whether or not the childless old couple deserves to be able to live in a larger house because they have more money. Parents continue to have children despite the fact that it is a net negative to them. Most parents appear to be completely fine with the concept that their net negative turns into a net positive for society, but they aren't getting compensated for it (or at least they're fine enough with it to not try harder to change it).
I just don't see how I can be more clear here. If you choose to do something, you'd better be informed as to the *personal* consequences, negative and positive. Whether or not your choice positively or negatively impacts the future economy is utterly irrelevant. If we really do have a birth rate problem (I'm not convinced we do), then sure, increase incentives for raising children. I (as someone who currently is leaning toward never having kids) have no problem with that.
Think of this as subject to normal market forces similar to supply and demand. If a healthy birth rate can be maintained (i.e., enough people are willing to have kids despite the negative) at a certain cost to the parents, then there's nothing wrong with the system. If not, then the cost needs to be reduced until the birth rate is healthy again. It's the same thing as setting a price on material goods: if enough people will pay your high price to keep the profits rolling in, you keep the high price. If you're losing money because people think your prices are too high, you have to lower the price or risk going out of business.
This all sounds terribly cold and clinical, but such is the nature of this discussion. We're trying to value children based on their benefit to the economy, after all!
NDISWrapper is not a derived work of the Linux kernel. That is a gross misuse of the term "derived work". Using headers and linking against something does not make it a derived work. Sure it is. Using Linux's module interface does indeed make it a derived work of the Linux kernel. If that doesn't, then what does?
... and there are numerous cases where open source wrappers have been written as a border between proprietary and GPLed code. To my knowledge, none of those use (or are allowed to use) GPLONLY symbols.
More to the point, you can argue that the GPLONLY limitations were intended to disallow linking by code that is licensed as GPL with a linking exception, but then you would also have to disallow any code within the Linux kernel itself that calls those functions unless those pieces of code are also marked with the GPLONLY restriction. That makes the GPLONLY functions substantially less useful to the point of being nearly worthless. That just... makes no sense. A function marked with EXPORT_SYMBOL_GPL() is intended to only be called by code that is licensed under the GPLv2 (or rather, code that is licensed under a GPLv2-compatible license). The rest of the "code within the Linux kernel itself that calls those functions" are also GPLv2-compatibly-licensed. Where's the problem?
What Linus himself *has* said in the past was that he considers binary modules ok *if* those modules weren't developed specifically for Linux. NDISWrapper is a module that loads binaries specifically developed for Windows, so there you go. And, again, those binary modules that Linus considers to be ok aren't allowed to use GPLONLY symbols.
Excellent point about Stallman, though. His original vision was indeed born out of compatibility frustrations, but it seems to me to be a bit of a stretch to assert that the purpose of today's GPL is to maintain compatibility.
Interestingly, if you look down the thread a bit, the list of problematic GPLONLY symbols pops up. A follow-up states that ndiswrapper already has a workqueue implementation, so those symbols could be safely not used (of course it's better to use shared code than a private copy to do the same thing), and the use of task_nice() and be worked around. The USB stuff is unfortunate, but removing that would (presumably) only make ndiswrapper not support USB wireless dongles. That's certainly a problem for some people, but not for others. The possibility of doing the USB support in userspace is also discussed, but currently there's no way to register a network device from outside the kernel, so that could be difficult.
Thanks for being a part of the problem. How are manufacturers going to understand that the Linux community wants high-quality open source drivers for their products if people don't vote with their wallet?
Slashdot Mirror
Agreed. Before the change, I had my text input area sized to be exactly one line of text high, and it would grow by itself if it needed to. The change was a bit annoying for a couple days, but really, I have more important things to worry about.
The general answer is that features and preferences don't have zero cost. They take work to write and test, and work in the future to maintain. Unless you have actually worked on the code base in question, you have no place suggesting how much work it is.
Having said that, some of the Pidgin developers are the most stubborn, inflexible, egotistical OSS developers I've ever had the misfortune to have to deal with. (Not all of them, though; some of them seem to be great people.)
Lose the sense of entitlement; you're getting this software for free, you know.
I stand corrected. Well done with the Shakespeare... many native English speakers can't understand him ^_~.
And, while I'm not among them, there are many who consider X to be a horrible design failure where windowing systems are concerned.
There's also Kerberos. While it's a great auth solution, MIT's implementation of it is just plain frightening to read... let alone modify. Though I suppose it's been a good 4 years since I've had to work with it.
(Laugh, it's funny!)
[citation needed] 1%? I doubt it's that small. Regardless, the usage reason percentages are pretty irrelevant to the FSF's views or agenda.
Depends on who you ask, who you are, what you make of it, and what you want from it. Some people use it because it's free, others because it's better, and still others for ideological reasons.
For example, in the US, you can waive your 5th amendment right of protection from self-incrimination by agreeing to testify in a criminal case in which you are the defendant.
Open a terminal on your Mac and type "locate plist". There are loads of them. Having to edit plist files on a Mac is surely rarer than needing to edit the registry on a Windows box or a conf file on a Linux box, but it happens, sometimes.
Since when did all people who think they can run servers get so snooty, elitist, and dickish? Oh, right, this is the internet. My bad.
I believe that was covered by the parent's mention of plists. And yes, sometimes they do need editing.
Does it require you to edit values in the registry in any situation?
Right.
WinXP is getting better, but it's not ready.
(Though I do mostly agree with you; Linux, including Ubuntu, is not quite ready for the masses. Just for different reasons.)
He's only saying that the "intelligent design" crowd tends to feed off so-called "scientific mistakes" and tries to use these mistakes to discredit evolutionary theory. He's warning people against making evolutionary claims for developments in humans that are based on weak or no evidence, because if/when evidence becomes available to refute these wild speculations, "real science" looks bad.
Huh? MacOS X supports IPv6 out of the box. The only (admittedly important) thing that doesn't work is autoconfiguring DNS servers. But most Linux systems and all Windows systems will generally have that same problem as well (the resolver on WinXP isn't even capable of doing IPv6 DNS queries). To be fair, at least with Linux you can set it up yourself; not sure if you can on a Mac.
For me, I'd leave home around 10.30am for a noon flight. I live within 20 minutes of a major airport (and 30 minutes from another major airport). Arrive an hour before the flight, checkin and security takes 20-25 minutes in my experience, get to the gate 5-10 minutes before they start boarding. If security takes a little longer than usual, bonus: I board the plane right as I get to the gate and don't have to wait.
So are you saying that I can write a closed-source program and link it against a GPLed library? I'm only using the header files and using its public interface. That sounds wrong to me and essentially makes LGPL = GPL.
Though again it's a matter of licensing -- if a module reports itself as "GPL with linking exception", I'd expect it to be denied access to GPLONLY modules, and I'm pretty sure that's how it works today. ndiswrapper was getting around this by claiming to be GPL in the past; now it looks like there's an explicit check for ndiswrapper in the kernel that will deny it access to GPLONLY symbols, even if it tells the kernel it's just plain old GPL.
I just don't see how I can be more clear here. If you choose to do something, you'd better be informed as to the *personal* consequences, negative and positive. Whether or not your choice positively or negatively impacts the future economy is utterly irrelevant. If we really do have a birth rate problem (I'm not convinced we do), then sure, increase incentives for raising children. I (as someone who currently is leaning toward never having kids) have no problem with that.
Think of this as subject to normal market forces similar to supply and demand. If a healthy birth rate can be maintained (i.e., enough people are willing to have kids despite the negative) at a certain cost to the parents, then there's nothing wrong with the system. If not, then the cost needs to be reduced until the birth rate is healthy again. It's the same thing as setting a price on material goods: if enough people will pay your high price to keep the profits rolling in, you keep the high price. If you're losing money because people think your prices are too high, you have to lower the price or risk going out of business.
This all sounds terribly cold and clinical, but such is the nature of this discussion. We're trying to value children based on their benefit to the economy, after all!
... and there are numerous cases where open source wrappers have been written as a border between proprietary and GPLed code. To my knowledge, none of those use (or are allowed to use) GPLONLY symbols. More to the point, you can argue that the GPLONLY limitations were intended to disallow linking by code that is licensed as GPL with a linking exception, but then you would also have to disallow any code within the Linux kernel itself that calls those functions unless those pieces of code are also marked with the GPLONLY restriction. That makes the GPLONLY functions substantially less useful to the point of being nearly worthless. That just... makes no sense. A function marked with EXPORT_SYMBOL_GPL() is intended to only be called by code that is licensed under the GPLv2 (or rather, code that is licensed under a GPLv2-compatible license). The rest of the "code within the Linux kernel itself that calls those functions" are also GPLv2-compatibly-licensed. Where's the problem? What Linus himself *has* said in the past was that he considers binary modules ok *if* those modules weren't developed specifically for Linux. NDISWrapper is a module that loads binaries specifically developed for Windows, so there you go. And, again, those binary modules that Linus considers to be ok aren't allowed to use GPLONLY symbols. Excellent point about Stallman, though. His original vision was indeed born out of compatibility frustrations, but it seems to me to be a bit of a stretch to assert that the purpose of today's GPL is to maintain compatibility.Interestingly, if you look down the thread a bit, the list of problematic GPLONLY symbols pops up. A follow-up states that ndiswrapper already has a workqueue implementation, so those symbols could be safely not used (of course it's better to use shared code than a private copy to do the same thing), and the use of task_nice() and be worked around. The USB stuff is unfortunate, but removing that would (presumably) only make ndiswrapper not support USB wireless dongles. That's certainly a problem for some people, but not for others. The possibility of doing the USB support in userspace is also discussed, but currently there's no way to register a network device from outside the kernel, so that could be difficult.
Thanks for being a part of the problem. How are manufacturers going to understand that the Linux community wants high-quality open source drivers for their products if people don't vote with their wallet?