Uh, what? You experience a Doppler effect with the train because the train is moving relative to you. For one stationary person yelling at another stationary person, there's no Doppler effect.
In the case of Linux, while the Kernel is under the GPL there is an explicit exception to allow programs which require it to operate to not be GPL'd... This exception isn't necessary, actually. Linus included it to head off any possible confusion about the relation between userspace applications and the kernel. Even without that exception, userspace code still would not fall under the GPL. They're clearly not derived works of the Linux kernel.
except..uh..that is what happened here. Stallman has come out many times and said that you are given more freedoms with "free software" True -- he has said that users do get more freedoms with free software than with proprietary software.
(not that the software itself was free) False -- this is something he says over and over. The software itself being free is one of Stallman's most basic tenets. The fact that users (and in some ways, developers) gain benefits from the software's freedom is something he also pushes because a) it really is pretty cool to be given permission to modify and redistribute other people's work, and b) no one would give a damn about software freedom for its own sake if there wasn't anything in it for people, too.
I was merely stating my opinion on the subject, and because it differs from the slashdot groupthink..it was marked as flamebait. No, it was marked flamebait because it was factually incorrect and ended with a smug "well I must be smarter than you" tone. Personally, if I had mod points and weren't posting in this article, I probably would have gone for Overrated rather than Flamebait, but whatever.
I think it's hilarious how I was told I didn't know the definition of the word free and given a link. I copied and pasted EXACT definitions from that link..and I was marked as flamebait. Definition #3 or #4 could apply here. As the parent stated, we're talking about freedom for the *software*, not for users or developers. Users and developers can derive a benefit from the freedom the *software* has, but they're not the intended recipient of this freedom.
Does GPL software enjoy political independence from outside domination? Yeah, I'd say so. "Not subject to the control or domination of another" sounds pretty accurate for GPLed software, though the "personal" bit sounds a little silly, probably just because the dictionary naturally defines 'free' in terms of people for those senses.
That wouldn't work. The GPL requires that you provide build instructions, and everything required to build a binary functionally identical to the one you're distributing. The only exception is that you don't have to provide build requirements that are commonly found in the wild or easy to obtain. That is, you can say "you need a copy of gcc that can cross-compile standard MIPS executables" and not provide the toolchain in your source release. See, for example (from GPLv2):
The source code for a work means the preferred form of the work for making modifications to it. For an executable work, complete source code means all the source code for all modules it contains, plus any associated interface definition files, plus the scripts used to control compilation and installation of the executable. However, as a special exception, the source code distributed need not include anything that is normally distributed (in either source or binary form) with the major components (compiler, kernel, and so on) of the operating system on which the executable runs, unless that component itself accompanies the executable. One could also interpret that to mean that your "\m" plan violates the "preferred form of the work for making modifications to it" line since your "\m" syntax is effectively "binary code" embedded in source.
I think from the customer ISP's perspective it's more about where the data is coming from. In the "old" model, a client downloads a video (for example) directly from the content provider. On the client end, they generate 700MB (again, for example) of downstream traffic. The content provider generates that same 700MB of traffic for their ISP, upstream this time. The content provider presumably is paying through the nose for bandwidth (at least compared to the client), and is probably metered such that they pay for what they use.
In the BitTorrent model, the client still generates that same 700MB of downstream traffic, but now they generate a certain amount of upstream traffic as well, sometimes as much or as more than the downstream traffic.
The client's ISP isn't used to all this extra traffic. The fact that the content provider now has lower bandwidth bills is irrelevant to the consumer ISP. The fact that BitTorrent is technically overall more efficient than a direct download is also irrelevant to the consumer ISP. From the consumer ISP's point of view, they have a *lot* more traffic flowing over their network. That's the so-called problem they're seeing. Personally I think they should just suck it up and upgrade their networks so they're actually providing what they advertise, but the money for these upgrades doesn't just grow on trees.
It depends. If Trolltech formerly owned the copyright on all parts of Qt -- that is, if non-Trolltech contributors to Qt were required to assign copyright to Trolltech before their submissions were accepted -- then Nokia would be perfectly within their rights to close-source Qt under whatever license they want.
Of course, they can't retroactively close versions that are already released under the GPL. A Free fork would have to start from the last GPL release.
The movie version of what the "legend" refers to is completely unlike the original novel. In the novel, "legend" refers to Neville being a legendary bogeyman of sorts, kidnapping people in the night in order to do tests and experiment on them. So in the spirit of the original work, the analogy/joke fits.
Enough with disinformation. Electricity is the most efficient way of delivering energy. And we already have it. Where? How do I "fill up" my electric car in the garage of my apartment complex? How do people who live in places where there's only street parking recharge their car? Where do I plug in when I take a road trip and my battery runs down on the way? How do I recharge while I'm at work? Or while I'm shopping at the mall?
We have electricity, sure, but we don't have the infrastructure to get it to our cars in the majority of situations where we might need it. Not everyone lives in a house with a garage where they can park their car and plug it in overnight. And even people who do might need to plug in elsewhere, but can't.
So you'd suggest we immediately replace all of our existing infrastructure with something completely incompatible, and require that everyone replace all their vehicles at the same time? Right, like that'll work. The rest of us live in the real world, where manageable, incremental improvements rule the day.
Finding a fix for 5% of the problem is a bit of a waste at this point. In the software world we call that premature optimisation. I'm not saying it's not worth trying to find a replacement for oils in chemicals, but if we can solve 95% of the problem instead of 5%, that leaves quite a lot more time to solve the 5%.
It's funny how USA centric slashdot is. Not really. I think it's pretty expected and unsurprising.
I have to agree that on the USA biofuel production would have an impact on food price. Almost [all] of your land is used. You're kidding, right?
Yes, and in Shanghai -- one of the more developed cities in China -- you can easily eat on less than US$3 per day as a white foreigner (I was there; I've done it). And that's eating out at restaurants. I imagine that number is lower in less developed areas of China, and if you cook at home, it's even lower. So you can't really make a direct comparison.
I'm not saying China doesn't have its problems with poverty, but please don't act as if the cost of living is exactly the same there as it is in the US.
Certainly, that goes without saying. But you can work on pretty much anything except graphics in a VM, and it often makes a lot of sense to do so. Hell, there are even large device-independent portions to X's graphics subsystems, and you can work on *those* from inside a VM.
Well, there have been attempts to develop other windowing systems, but they've all failed to generate enough interest. X works, and it works well. Sure, it has its deficiencies, but many of those can be fixed or worked around through its extension mechanism. I often see so many people who don't really understand X claim it sucks... it gets a bit tiring.
The Linux kernel for example, is completely without competing forks that I know of, yet seems to be making good strides. Actually, the Linux kernel has loads of forks, but the difference is that most of them are *cooperative* forks, not competitive. Most distro vendors have their own fork of the kernel, and there are plenty of forks for specialised hardware and so forth. Often code from the distro forks make it back into the mainline kernel. The forks for specialised hardware sometimes don't really go anywhere, but if the hardware is popular enough, sometimes the code will come back as a new arch or subarch of the mainline kernel.
Sure, it's not all roses and puppies, but the Linux kernel seems to have a very healthy forking community, probably unlike any other OSS project (I'd be interested in hearing about other examples, though, if they exist).
I'm not sure if something like that is really feasible for a project like X.org.
Re:Anything else out there?
on
The State of X.Org
·
· Score: 2, Insightful
Yes, but depending on what you're working on (say, input handling), it's certainly possible to lock yourself out of even changing ttys. If you're working on graphics drivers, it's pretty easy to hard-lock your machine. Of course, if it's not hard-locked, you can probably grab another machine, ssh over, and kill your separate X instance, but if you can do that, then you might as well just develop using both machines, one as the dev machine, and one as the guinea pig. If you're working on parts of X that are device-independent, it makes a lot of sense to do your testing in a VM.
Why is this flamebait? It's absolutely true, and something worth thinking about. A from-scratch rewrite (redesign?) would be a foolish move, not only in all the various bugs and quirks that have been found over the years, but also in the fact -- yes, fact -- that graphics on Linux would effectively stall progress-wise for several years while we're all waiting for the rewrite to become usable.
That's assuming anyone would actually do anything as crazy as abandon the current X.org codebase. Having funny file names and messy macros all over the place aren't reasons for a rewrite. This sort of thing needs to be refactored and re-abstracted over many many months, slowly, bit by bit at a time.
(As to number of updates, I'd rather have Apple's way of doing it over Microsoft's - I don't understand waiting for long periods until you get a large enough mass of updates to make a giant "Service Pack" for the system. Quicker, more directed upgrades at reasonable intervals suit me fine.) I thought MS released patches once a month...
Yet, isn't. In the real world, people do not magically know what they have to do. They do things when asked to do them. Another reason for Mozilla to put on the big boy pants and improve their administration of their project. The Mozilla Corp/Foundation is made up of people. People just like us. I don't know about you, but in my professional life, sometimes I do forget to do something that someone has asked me to do. And sometimes someone else forgets to do something that I've asked them to do. It just happens.
After you noticed you weren't acknowledged as a contributor, did you say "hey, we're missing from the credits; here's a patch to fix that"? If not, what are you complaining about? I don't care if you think you shouldn't have to do this. An oversight happened, and if you don't even point it out, how can you expect anyone to know about it? Perhaps you should put on your "big boy pants" and learn how to communicate with people in the real world.
Also, as roca pointed out above, the parts of your patch that were accepted made only 25% of the original patch redundant, not 80% as you claimed. Why should we take you seriously if you're going to grossly exaggerate the facts?
It's a big project, and their priorities may not necessarily match with yours. If the feature you submitted was a "nice to have" feature but not something on the roadmap (or even was on the roadmap but not a "must have" feature), it's no surprise it wasn't given 100% attention, especially considering it looks like it was within a few months of feature freeze when the bug was opened.
I'm sorry you don't think your experience was that great, but it looks like you also did nothing to try to resolve the issues you had, and failed to take into account the fact that the people working with you also had other things on their plates.
Sorry, but I just don't buy it. Your morals and ethics aren't necessarily everyone's, though I'm sure there's a lot of common ground.
Back to the actual point... Icahn may be a greedy bastard, but who's to say Yahoo's board *doesn't* need to be shaken up? Seems like Yang has been acting unilaterally without the support of his shareholders. Whether or not you or I -- or, to an extent, Jerry Yang -- think a merger with Microsoft would be good or bad for the company isn't particularly relevant. If the majority of the shareholders do, they have the legal standing to change things to make it happen (assuming MS is still interested).
Slashdot Mirror
Yes, but this lawsuit is specifically about hourly employees.
... the best brains in the field of physics...
Or perhaps the best branes...
Uh, what? You experience a Doppler effect with the train because the train is moving relative to you. For one stationary person yelling at another stationary person, there's no Doppler effect.
Does GPL software enjoy political independence from outside domination? Yeah, I'd say so. "Not subject to the control or domination of another" sounds pretty accurate for GPLed software, though the "personal" bit sounds a little silly, probably just because the dictionary naturally defines 'free' in terms of people for those senses.
I think from the customer ISP's perspective it's more about where the data is coming from. In the "old" model, a client downloads a video (for example) directly from the content provider. On the client end, they generate 700MB (again, for example) of downstream traffic. The content provider generates that same 700MB of traffic for their ISP, upstream this time. The content provider presumably is paying through the nose for bandwidth (at least compared to the client), and is probably metered such that they pay for what they use.
In the BitTorrent model, the client still generates that same 700MB of downstream traffic, but now they generate a certain amount of upstream traffic as well, sometimes as much or as more than the downstream traffic.
The client's ISP isn't used to all this extra traffic. The fact that the content provider now has lower bandwidth bills is irrelevant to the consumer ISP. The fact that BitTorrent is technically overall more efficient than a direct download is also irrelevant to the consumer ISP. From the consumer ISP's point of view, they have a *lot* more traffic flowing over their network. That's the so-called problem they're seeing. Personally I think they should just suck it up and upgrade their networks so they're actually providing what they advertise, but the money for these upgrades doesn't just grow on trees.
It depends. If Trolltech formerly owned the copyright on all parts of Qt -- that is, if non-Trolltech contributors to Qt were required to assign copyright to Trolltech before their submissions were accepted -- then Nokia would be perfectly within their rights to close-source Qt under whatever license they want.
Of course, they can't retroactively close versions that are already released under the GPL. A Free fork would have to start from the last GPL release.
The movie version of what the "legend" refers to is completely unlike the original novel. In the novel, "legend" refers to Neville being a legendary bogeyman of sorts, kidnapping people in the night in order to do tests and experiment on them. So in the spirit of the original work, the analogy/joke fits.
SwiftFuel is made from ethanol *products*. There is no ethanol in SwiftFuel. Not sure how that changes its efficiency, though.
We have electricity, sure, but we don't have the infrastructure to get it to our cars in the majority of situations where we might need it. Not everyone lives in a house with a garage where they can park their car and plug it in overnight. And even people who do might need to plug in elsewhere, but can't.
So you'd suggest we immediately replace all of our existing infrastructure with something completely incompatible, and require that everyone replace all their vehicles at the same time? Right, like that'll work. The rest of us live in the real world, where manageable, incremental improvements rule the day.
Finding a fix for 5% of the problem is a bit of a waste at this point. In the software world we call that premature optimisation. I'm not saying it's not worth trying to find a replacement for oils in chemicals, but if we can solve 95% of the problem instead of 5%, that leaves quite a lot more time to solve the 5%.
Yes, and in Shanghai -- one of the more developed cities in China -- you can easily eat on less than US$3 per day as a white foreigner (I was there; I've done it). And that's eating out at restaurants. I imagine that number is lower in less developed areas of China, and if you cook at home, it's even lower. So you can't really make a direct comparison.
I'm not saying China doesn't have its problems with poverty, but please don't act as if the cost of living is exactly the same there as it is in the US.
Certainly, that goes without saying. But you can work on pretty much anything except graphics in a VM, and it often makes a lot of sense to do so. Hell, there are even large device-independent portions to X's graphics subsystems, and you can work on *those* from inside a VM.
Well, there have been attempts to develop other windowing systems, but they've all failed to generate enough interest. X works, and it works well. Sure, it has its deficiencies, but many of those can be fixed or worked around through its extension mechanism. I often see so many people who don't really understand X claim it sucks... it gets a bit tiring.
Sure, it's not all roses and puppies, but the Linux kernel seems to have a very healthy forking community, probably unlike any other OSS project (I'd be interested in hearing about other examples, though, if they exist).
I'm not sure if something like that is really feasible for a project like X.org.
Yes, but depending on what you're working on (say, input handling), it's certainly possible to lock yourself out of even changing ttys. If you're working on graphics drivers, it's pretty easy to hard-lock your machine. Of course, if it's not hard-locked, you can probably grab another machine, ssh over, and kill your separate X instance, but if you can do that, then you might as well just develop using both machines, one as the dev machine, and one as the guinea pig. If you're working on parts of X that are device-independent, it makes a lot of sense to do your testing in a VM.
You're presupposing that X.org is sinking. I don't see that.
Why is this flamebait? It's absolutely true, and something worth thinking about. A from-scratch rewrite (redesign?) would be a foolish move, not only in all the various bugs and quirks that have been found over the years, but also in the fact -- yes, fact -- that graphics on Linux would effectively stall progress-wise for several years while we're all waiting for the rewrite to become usable.
That's assuming anyone would actually do anything as crazy as abandon the current X.org codebase. Having funny file names and messy macros all over the place aren't reasons for a rewrite. This sort of thing needs to be refactored and re-abstracted over many many months, slowly, bit by bit at a time.
After you noticed you weren't acknowledged as a contributor, did you say "hey, we're missing from the credits; here's a patch to fix that"? If not, what are you complaining about? I don't care if you think you shouldn't have to do this. An oversight happened, and if you don't even point it out, how can you expect anyone to know about it? Perhaps you should put on your "big boy pants" and learn how to communicate with people in the real world.
Also, as roca pointed out above, the parts of your patch that were accepted made only 25% of the original patch redundant, not 80% as you claimed. Why should we take you seriously if you're going to grossly exaggerate the facts?
It's a big project, and their priorities may not necessarily match with yours. If the feature you submitted was a "nice to have" feature but not something on the roadmap (or even was on the roadmap but not a "must have" feature), it's no surprise it wasn't given 100% attention, especially considering it looks like it was within a few months of feature freeze when the bug was opened.
I'm sorry you don't think your experience was that great, but it looks like you also did nothing to try to resolve the issues you had, and failed to take into account the fact that the people working with you also had other things on their plates.
I'd like to see you try ^_~.
Sorry, but I just don't buy it. Your morals and ethics aren't necessarily everyone's, though I'm sure there's a lot of common ground.
Back to the actual point... Icahn may be a greedy bastard, but who's to say Yahoo's board *doesn't* need to be shaken up? Seems like Yang has been acting unilaterally without the support of his shareholders. Whether or not you or I -- or, to an extent, Jerry Yang -- think a merger with Microsoft would be good or bad for the company isn't particularly relevant. If the majority of the shareholders do, they have the legal standing to change things to make it happen (assuming MS is still interested).