To my knowledge, the minute a developer distributes their software under the GPL, they become a distributer, and must either provide the source code or cease licensing their software under the GPL.
The GPL is a copyright license. It only has any power at all because without the license the GPL provides, distribution would be a violation of copyright law. Since the copyright holder is not constrained by copyright law, the GPL text is utterly irrelevant to them.
I've never used it but Oracle is either one hell of a database, or one hell of a brand for people to put up with tactics like that. That shouldn't even be legal.
Oracle is an amazingly powerful brand and managers think that "scalability" is something you buy rather than an engineering problem for programmers and system architects to solve. That's really the whole story. Given what servers cost and the actual performance differences between different database software given appropriately written client software, purchasing Oracle licenses is largely inexcusable unless you have existing Oracle dependent software and no time to switch databases and re-address scaling related design questions.
I think you have a misconception of what libraries do. In general, we aren't necessarily archiving information for the future.
Just because you don't archive all (or even most) of the stuff you have doesn't mean that the ability to archive isn't directly valuable to you. Further, I'm 100% sure that you would archive *everything* if you had the space to do so. Electronic storage of books and articles means that you naturally do have the space to store everything - DRM just prevents you from of taking advantage of that fact.
With all due respect to the parent poster and to Mr. Stallman, my job is not to take a stand on DRM.
As a librarian, it absolutely is your ethical/professional responsibility to evaluate the social implications of DRM technology and potentially take a stand on the issue. DRM acceptance has the potential to define the level of access to human knowledge people have. DRM use today has a direct impact on the extent to which libraries can archive information for the future.
The model for libraries has always been that the library actually controls a copy of the book / CD / tape and can lend it to anyone at any time. DRM-encumbered files give the publisher complete control - with a default of "deny access". That default is utterly incompatible with the mission of a public library.
The reason for a patent is to get the invention into the public thus encouraging progress. Just sitting on a patent, and waiting until someone else comes up with the same thing independently, doesn't do that. All it does is steals the hard work others put into making and producing the item. It's not part of the law but I believe that there should be a tyme limit on how long a produce is released for sale before the patent in invalidated.
You seem to misunderstand the effects that patents have in the real world and why large corporations lobby for them. Patent laws were initially introduced based on precisely the reasoning you describe - but patents haven't actually done that or been supported with that intention by any major political players in living memory.
Patents have the effect of allowing a market participant to prevent competition or to extort money. That's it. Large players prefer the former (and lobby for patents because of it), because small players can't make much use of it. Small players enjoy the latter.
As for why "patent trolls" can be "legitimate" small players, consider the following situation: A small research lab invents stuff, patents it, and licenses it to other companies to productize. This is the absolute best case of the patent system, and the company looks *exactly* like a patent troll except they have a sales department in addition to their legal department.
You use "patent troll" different than I do. To me a patent troll is something that gets a patent on something but then sits on patent and waits until someone releases a product with the patent in it. No one who gets a patent then tries to manufacture for sale a product with the patent is a troll.
No. We both seem to agree on the definition of "patent troll". The only thing that I'm pointing out is that sometimes a patent troll really is a reasonably small-time inventor who legitimately invented something and patented it, then rationally decided that the only way to make money on his invention was to wait for a big company to use it (and carefully not release any products of his own to be counter-sued over).
From the perspective of actually wanting to see technological progress (which works best given the use and combination of all human knowledge), patent trolling is horribly counterproductive. Coincidentally, it's also really bad from the perspective of a large corporation that uses patent licensing to enforce a small oligopoly. But, from the perspective of patents as "intellectual property" where the inventor "owns" the invention and deserves to get paid for its use, patent trolling is not only good but the only valid technique for small inventors.
Patent trolls aren't really the problem. A patent troll is one of two things: Lawyers abusing the broken patent system (a symptom of the larger problem) or a legitimate little guy who invented something (in which case this is the system working as it is supposedly intended to work).
Here's the thing: The only time a small inventor can ever make money on a patent is by acting as a patent troll. If the small inventor actually tries to sell a product, they'll get bullied out of existence by counter-suits from the larger players. Therefore, any plan that hurts patent trolls is simply making the patent system even less beneficial than it is now.
PPC and Sparc workstations are not commodity devices... If you buy such a device from IBM/Sun, then the respective vendor will have made sure it comes with a compatible video card.
False. PPC and Sparc are both reasonably open architectures sold by numerous companies. Any company who wants to can buy Sparc or PPC in a compeditive market (much more compeditive than the market for Intel chips) and build whatever they want; some even make workstations.
I guess you're right. The workstations themselves aren't common enough to be considered commodity devices - but the chips are. And AMD doesn't sell graphics chips to end users, they sell them to device makers. If they want to sell them as commodity graphics chips then they will be expected to work with commodity processors - like PPC, Sparc, and (to some extent) ARM.
Like I said, you're using a very non-standard definition of "mainstream." Mainstream, for computers, means basically "stuff you can buy at places like Best Buy or Fry's." Now do you get it?
That's more "mainstream from your perspective as user of home desktop computers". I'm talking about "mainstream in the computer industry", where home desktops are just one niche (a small one compared to embedded ARM systems, and a low-margin one compared to graphics workstations).
Yes, it does, because it's for the exact same reason -- economics. It's too costly, in time/money, to train developers in a drastically different language. The days of difficult but powerful languages and other technologies (like CORBA, COM, prolly others) achieving mainstream status are over. That's why C++ is being replaced with Java and C#. Anything hard is undesirable by PHB's. As is anything drastically different.
You are right on reasonably short time scales (a year or two) at a single organization. On longer time scales, new languages do get used and new programming teams are hired / trained to use them. Consider the adoption of C#. A couple years ago, there were zero C# developers in the world - today, it's mandated by many PHB's.
Sure, more drastically different languages take longer to be adopted. Consider how the adoption of OO programming languages occured in the late 80's and 90's. First, hybrid languages like C++ were created. Then, once C++ had already been adopted, we got stuff like Java. Today, OO is mainstream. I fully expect that any uptake of functional programming will occur the same way - with transitional languages and years of advance warning.
I think suv4x4 is basically right, we're stuck with the C syntax, OOP, and any advancements such as in the area of more concurrency will only catch on big if it is handled automatically for the developer, by the runtime.
This will be interesting to watch. It looks to me like we'll get to 32 cores in a high end workstation (and 8 - 16 in a moderate desktop) before anyone seriously questions buying more cores any more than they already question buying faster hardware in general and that programmers are going to be suffering with locks and threads for a long time. If something significantly better comes along in the form of a new language, people may adopt it - the business case for saving programmer time and using existing hardware better is damn good. Erlang isn't that language for various reasons, but some sort of Erlang/Ruby or Erlang/Java hybrid might be.
I hate to break it to you, but you're using a very non-standard definition of "mainstream."
You'd think that, but it gets a bit less clear when you consider things like the 3D workstation market and the semi-embedded market. How "mainstream" are Sparc workstations among the potential customers of FireGL cards? How about PPC workstations? How common are ARM processors? What are the chances that someone will want to combine a commodity ARM processor with an AMD graphics card?
That last bit is sort of important. AMD makes a business of selling commodity hardware components. Their customers are companies building their own products, who expect to be able to use AMD hardware with other commodity hardware.
There are companies still out there stuck with COBOL. The same effect with massively increased power will become apparent for C/Java/C#/PHP/Python and what not code in 10-20 years. We're stuck with it.
It's natural that software maintenance will never be in new languages. That doesn't prevent new projects, or even new components in existing projects, from being written in those new languages. One thing that's happened that's very interesting is systems like.NET being designed to support the easy intermingling of different languages in the same application. That will allow projects to migrate to new languages more easily, and for niche languages to be used for specific modules where they are appropriate. Sure, PHBs will continue to try to force every project to be written in one (usually inappropriate) language, but even today we see major apps written in Python & C++ or C# & VB.NET or C++ & JavaScript.
Obviously you "modify on the fly" your test server first, and then once you've tested it (as usual), you "modify on the fly" your production server. I fail to see the problem here.
Atoms. They're used for some things I might use constants for in another language, I think. I'll have to get back to you with some code examples.
Why does it matter if you use the same atom for different things in different places? Would namespaces for atoms even make sense? This seems like a case where you're thinking of them as "replacing constants" rather than "being atoms".
All in all, no wonder the language isn't popular. We're way way past drastic differences in the languages we'll use. We're stuck with C/Java like syntax, OOP and anything new regarding concurrency will be rolled up on top of it, versus replace it.
Assuming that Java/C# are the last word in programming language behavior is simply foolish. Sure, they're popular today. Sure, people will still be using them in 30 years (in the same way that people are still using Cobol today). But they'll get replaced just like every "best" language before them.
But unlike constants those single-assignment vars can't be optimized at compile time, and still can't replace normal variables.
Have you ever actually written a program in a functional language? If not, I suggest you do. The design patterns involved are extremely elegant and frequently useful even in procedural programming languages.
I believe concurrency will in the end be most implemented via RAM transactions, which proves a simple and effective model for handling race conditions, while retaining the look of the separate procedures as imperative sequential code as we know it today.
Transactional memory is neat, but I haven't seen a model for it described that actually makes concurrent programming straightforward for the programmer. Erlang style message passing, on the other hand, has been actually working in production for a very long time.
Business isn't about morals, justice or freedom - it's about making money. Typing `f**k` instead of `fuck` is just a business decision.
Although I agree with some of your premise, you appear to be applying a simplified heuristic to your decision making that is known to result in severely self-harming decisions in reasonably common edge cases. You can't ignore ethical considerations in business decisions because they are a criteria that customers use to evaluate your offerings.
Slashdot is a perfect example of a case where the benefits of supporting freedom of speech are likely to exceed the potential benefits of self-censorship. I personally have a much higher opinion of Slashdot due to their ongoing policy of supporting information freedom than I would otherwise - over hundreds of thousands of users, that ends up translating into page views (which are ad impressions, which are dollars).
No, it means you're prepared to compromise to make a profit. It's just the cost of doing business.
The social implications don't change based on how a given policy-maker looks at the question. An environment where businesses censor things like news stories and web discussions out of fear of bad publicity is socially harmful. The "compromise to make a profit" thing is simply a detail of the mechanism that is causing that self-censorship to occur.
If you disguise those sorts of words it makes it more likely that you can read slashdot from places like schools and libraries around the world. It also means that radio stations, magazines and other websites which are aimed at a `family` audience are more likely to provide links to Slashdot.
It also means that you're self-censoring out of fear. That's a really bad deal.
With anybody else I'd apply the "Never attribute to malice that which can be adequately explained by incompetence" axiom, but with Microsoft I'm not so sure.
Sufficiently advanced malice is indistinguishable from incompetence.
There's a big difference between personally sharing some music and making a business out of copyright infringement. Copyright was initially an industrial regulation - applying to physical products on a shelf in a store or warehouse. I'd be perfectly willing to support that sort of law, assuming a reasonable copyright term. On the other hand, trying to apply the same law to private individuals acting non-commercially is absurd.
I'm not the only one who holds this position. As you can see in the following videos, both Eben Moglen (of the Free Software movement) and Rick Falkvinge (of the Swedish Pirate Party) hold somewhat similar views. Rick even covers the "free software with less copyright" question.
Everyone with any interest in this topic should seriously watch both of these videos from beginning to end. The speakers present their positions reasonably clearly, which should serve to advance the overall discussion beyond the over-asked basic questions.
How does any non-Linux person give credibility when they see "GIMP". Makes me think of Pulp Fiction: "Bring out the Gimp!" Part of Feisty Fawn's default installation.
The menu item is "GIMP Image Editor". All caps indicates an acronym. I doubt anyone even gives it a second thought.
Try this: Go to http://www.ubuntu.com/ and find a reference to "Feisty Fawn" in the marketing material for the release version (rather than the old dev documents in the Wiki). There may be a slip or two, but I couldn't find one in a couple minutes of looking. Generally the development code names are only used for development.
ACPI power management doesn't work. This is a particularly bad problem for laptops. My laptop would shut down as soon as Gnome started, because it believed the battery was dead, when it really wasn't. Hibernation has never worked on any machine I've tried it on. Sleep typically doesn't work. To be fair, this may not be the fault of the linux/ubuntu developers; apparently a lot of hardware manufacturers refuse to supply enough information to allow kernel developers to know what hardware registers need to be restored when waking from sleep or hibernation.
Power management works fine on supported hardware. Finding laptops that were fully supported used to be hard, so this was a valid complaint, but now that even Dell sells fully supported laptops this is simply user error just like any other "unsupported hardware" complaint.
Second, I expect any quality OS to work out of the box. I don't believe that is an unreasonable expectation. Perhaps Ubuntu simply isn't polished enough yet.
Any quality OS does work out of the box. When you buy it the normal way - pre-installed on a machine. Installing operating systems by hand on hardware that may or may not be supported always has been, and always will be, a hobbyist adventure.
None of my hardware is exotic by any stretch of the imagination, yet the GUI installer wouldn't even load.
It doesn't matter if your hardware is "exotic". All that matters is if your hardware is supported. If it had been, it would have worked. Since it wasn't, it didn't. All your test showed is that there is at least one piece of hardware that Feisty doesn't support, and you happen to own it.
If you seriously want to try out Ubuntu, I'd suggest picking up a machine with the OS pre-installed. That's how people normally get operating systems, so that seems like the only valid way to evaluate a new one. Dell sells Ubuntu boxes starting at like $350, so it wouldn't require some massive investment or anything.
Slashdot Mirror
The GPL is a copyright license. It only has any power at all because without the license the GPL provides, distribution would be a violation of copyright law. Since the copyright holder is not constrained by copyright law, the GPL text is utterly irrelevant to them.
Oracle is an amazingly powerful brand and managers think that "scalability" is something you buy rather than an engineering problem for programmers and system architects to solve. That's really the whole story. Given what servers cost and the actual performance differences between different database software given appropriately written client software, purchasing Oracle licenses is largely inexcusable unless you have existing Oracle dependent software and no time to switch databases and re-address scaling related design questions.
Just because you don't archive all (or even most) of the stuff you have doesn't mean that the ability to archive isn't directly valuable to you. Further, I'm 100% sure that you would archive *everything* if you had the space to do so. Electronic storage of books and articles means that you naturally do have the space to store everything - DRM just prevents you from of taking advantage of that fact.
As a librarian, it absolutely is your ethical/professional responsibility to evaluate the social implications of DRM technology and potentially take a stand on the issue. DRM acceptance has the potential to define the level of access to human knowledge people have. DRM use today has a direct impact on the extent to which libraries can archive information for the future.
The model for libraries has always been that the library actually controls a copy of the book / CD / tape and can lend it to anyone at any time. DRM-encumbered files give the publisher complete control - with a default of "deny access". That default is utterly incompatible with the mission of a public library.
You seem to misunderstand the effects that patents have in the real world and why large corporations lobby for them. Patent laws were initially introduced based on precisely the reasoning you describe - but patents haven't actually done that or been supported with that intention by any major political players in living memory.
Patents have the effect of allowing a market participant to prevent competition or to extort money. That's it. Large players prefer the former (and lobby for patents because of it), because small players can't make much use of it. Small players enjoy the latter.
As for why "patent trolls" can be "legitimate" small players, consider the following situation: A small research lab invents stuff, patents it, and licenses it to other companies to productize. This is the absolute best case of the patent system, and the company looks *exactly* like a patent troll except they have a sales department in addition to their legal department.
No. We both seem to agree on the definition of "patent troll". The only thing that I'm pointing out is that sometimes a patent troll really is a reasonably small-time inventor who legitimately invented something and patented it, then rationally decided that the only way to make money on his invention was to wait for a big company to use it (and carefully not release any products of his own to be counter-sued over).
From the perspective of actually wanting to see technological progress (which works best given the use and combination of all human knowledge), patent trolling is horribly counterproductive. Coincidentally, it's also really bad from the perspective of a large corporation that uses patent licensing to enforce a small oligopoly. But, from the perspective of patents as "intellectual property" where the inventor "owns" the invention and deserves to get paid for its use, patent trolling is not only good but the only valid technique for small inventors.
Patent trolls aren't really the problem. A patent troll is one of two things: Lawyers abusing the broken patent system (a symptom of the larger problem) or a legitimate little guy who invented something (in which case this is the system working as it is supposedly intended to work).
Here's the thing: The only time a small inventor can ever make money on a patent is by acting as a patent troll. If the small inventor actually tries to sell a product, they'll get bullied out of existence by counter-suits from the larger players. Therefore, any plan that hurts patent trolls is simply making the patent system even less beneficial than it is now.
False. PPC and Sparc are both reasonably open architectures sold by numerous companies. Any company who wants to can buy Sparc or PPC in a compeditive market (much more compeditive than the market for Intel chips) and build whatever they want; some even make workstations.
I guess you're right. The workstations themselves aren't common enough to be considered commodity devices - but the chips are. And AMD doesn't sell graphics chips to end users, they sell them to device makers. If they want to sell them as commodity graphics chips then they will be expected to work with commodity processors - like PPC, Sparc, and (to some extent) ARM.
That's more "mainstream from your perspective as user of home desktop computers". I'm talking about "mainstream in the computer industry", where home desktops are just one niche (a small one compared to embedded ARM systems, and a low-margin one compared to graphics workstations).
You are right on reasonably short time scales (a year or two) at a single organization. On longer time scales, new languages do get used and new programming teams are hired / trained to use them. Consider the adoption of C#. A couple years ago, there were zero C# developers in the world - today, it's mandated by many PHB's.
Sure, more drastically different languages take longer to be adopted. Consider how the adoption of OO programming languages occured in the late 80's and 90's. First, hybrid languages like C++ were created. Then, once C++ had already been adopted, we got stuff like Java. Today, OO is mainstream. I fully expect that any uptake of functional programming will occur the same way - with transitional languages and years of advance warning.
This will be interesting to watch. It looks to me like we'll get to 32 cores in a high end workstation (and 8 - 16 in a moderate desktop) before anyone seriously questions buying more cores any more than they already question buying faster hardware in general and that programmers are going to be suffering with locks and threads for a long time. If something significantly better comes along in the form of a new language, people may adopt it - the business case for saving programmer time and using existing hardware better is damn good. Erlang isn't that language for various reasons, but some sort of Erlang/Ruby or Erlang/Java hybrid might be.
You'd think that, but it gets a bit less clear when you consider things like the 3D workstation market and the semi-embedded market. How "mainstream" are Sparc workstations among the potential customers of FireGL cards? How about PPC workstations? How common are ARM processors? What are the chances that someone will want to combine a commodity ARM processor with an AMD graphics card?
That last bit is sort of important. AMD makes a business of selling commodity hardware components. Their customers are companies building their own products, who expect to be able to use AMD hardware with other commodity hardware.
It's natural that software maintenance will never be in new languages. That doesn't prevent new projects, or even new components in existing projects, from being written in those new languages. One thing that's happened that's very interesting is systems like .NET being designed to support the easy intermingling of different languages in the same application. That will allow projects to migrate to new languages more easily, and for niche languages to be used for specific modules where they are appropriate. Sure, PHBs will continue to try to force every project to be written in one (usually inappropriate) language, but even today we see major apps written in Python & C++ or C# & VB.NET or C++ & JavaScript.
Obviously you "modify on the fly" your test server first, and then once you've tested it (as usual), you "modify on the fly" your production server. I fail to see the problem here.
Why does it matter if you use the same atom for different things in different places? Would namespaces for atoms even make sense? This seems like a case where you're thinking of them as "replacing constants" rather than "being atoms".
Assuming that Java/C# are the last word in programming language behavior is simply foolish. Sure, they're popular today. Sure, people will still be using them in 30 years (in the same way that people are still using Cobol today). But they'll get replaced just like every "best" language before them.
Have you ever actually written a program in a functional language? If not, I suggest you do. The design patterns involved are extremely elegant and frequently useful even in procedural programming languages.
Transactional memory is neat, but I haven't seen a model for it described that actually makes concurrent programming straightforward for the programmer. Erlang style message passing, on the other hand, has been actually working in production for a very long time.
Although I agree with some of your premise, you appear to be applying a simplified heuristic to your decision making that is known to result in severely self-harming decisions in reasonably common edge cases. You can't ignore ethical considerations in business decisions because they are a criteria that customers use to evaluate your offerings.
Slashdot is a perfect example of a case where the benefits of supporting freedom of speech are likely to exceed the potential benefits of self-censorship. I personally have a much higher opinion of Slashdot due to their ongoing policy of supporting information freedom than I would otherwise - over hundreds of thousands of users, that ends up translating into page views (which are ad impressions, which are dollars).
The social implications don't change based on how a given policy-maker looks at the question. An environment where businesses censor things like news stories and web discussions out of fear of bad publicity is socially harmful. The "compromise to make a profit" thing is simply a detail of the mechanism that is causing that self-censorship to occur.
It also means that you're self-censoring out of fear. That's a really bad deal.
Sufficiently advanced malice is indistinguishable from incompetence.
There's a big difference between personally sharing some music and making a business out of copyright infringement. Copyright was initially an industrial regulation - applying to physical products on a shelf in a store or warehouse. I'd be perfectly willing to support that sort of law, assuming a reasonable copyright term. On the other hand, trying to apply the same law to private individuals acting non-commercially is absurd.
I'm not the only one who holds this position. As you can see in the following videos, both Eben Moglen (of the Free Software movement) and Rick Falkvinge (of the Swedish Pirate Party) hold somewhat similar views. Rick even covers the "free software with less copyright" question.
Everyone with any interest in this topic should seriously watch both of these videos from beginning to end. The speakers present their positions reasonably clearly, which should serve to advance the overall discussion beyond the over-asked basic questions.
The menu item is "GIMP Image Editor". All caps indicates an acronym. I doubt anyone even gives it a second thought.
Try this: Go to http://www.ubuntu.com/ and find a reference to "Feisty Fawn" in the marketing material for the release version (rather than the old dev documents in the Wiki). There may be a slip or two, but I couldn't find one in a couple minutes of looking. Generally the development code names are only used for development.
What's wrong with "Hardy Heron"? I mean... I guess someone might exist who doesn't know what a Heron is, but...
Power management works fine on supported hardware. Finding laptops that were fully supported used to be hard, so this was a valid complaint, but now that even Dell sells fully supported laptops this is simply user error just like any other "unsupported hardware" complaint.
Any quality OS does work out of the box. When you buy it the normal way - pre-installed on a machine. Installing operating systems by hand on hardware that may or may not be supported always has been, and always will be, a hobbyist adventure.
It doesn't matter if your hardware is "exotic". All that matters is if your hardware is supported. If it had been, it would have worked. Since it wasn't, it didn't. All your test showed is that there is at least one piece of hardware that Feisty doesn't support, and you happen to own it.
If you seriously want to try out Ubuntu, I'd suggest picking up a machine with the OS pre-installed. That's how people normally get operating systems, so that seems like the only valid way to evaluate a new one. Dell sells Ubuntu boxes starting at like $350, so it wouldn't require some massive investment or anything.