Trolltech and KDE have worked out an agreement that I think addresses most issues people have with the QT license. Trolltech has developed a great desktop environment and cross OS development toolkit and commercial licensing has paid for much of it (which in turn allowed Kdevelop to become such an incredible tool for linux/windows/osx GPL development).
Oh, please, spare us the marketing speech. I pointed out that it is incompatible with the Gnome licenses: Gnome libraries are LGPL and Qt is dual-licensed GPL/commercial. It doesn't matter what spin you try to put on that, that's just a legal fact.
If you want to talk about consequences, you can see those in the market: Gnome is a thriving project and is becoming the de-facto standard for commercial UNIX and Linux systems. If Qt had been LGPL from the start, the Gnome project would have never started.
In a few years it won't hurt to have both installed and freedesktop.org will hopefully allow for theme unification.
If we are still running something called "Gnome" and/or "KDE" in a few years, they'll hopefully not be based on bloated, obsolete C or C++ libraries.
What I *AM* arguing is that their figures are dishonest. They are naming a very specific item and advocating an action--on that exact item. They gave a specific _MASS_ of fossil fuels. That the amount of energy available in that mass can be directly attributed to the specific action of manufacturing something as simple as a CRT is what I am questioning.
Governments, economists and corporations make those kinds of attributions again and again. You have presented no argument that there is anything wrong with it.
Also, the argument to use old equipment rather than new betrays the lie. New equipment is more energy efficient.
Not really. LCDs happen to be more energy efficient than CRTs, but that's the exception rather than the rule.
It'll be interesting to read a decent "neutral" KDE 3.2 vs Gnome 2.6 article though!
About as interesting as a "neutral" Britney Spears vs. Paris Hilton article.
something to be encouraged until hopefully one day somehow the libraries can be unified.........
They could have been unified long ago if the Qt license (GPL) didn't prevent it. You see, ultimately, the difference between KDE and Gnome doesn't come down to technology, it comes down to licenses, and the Qt license just doesn't work for many people.
GNOME vs. KDE will perhaps be one of the holy wars of this millennium,
Yes, and like most holy wars, it's about obsolete ideas. Gnome and KDE are both serviceable desktop environments, but let's not kid ourselves: imitating Windows and MacOS should not be the future of computing.
Personally I'll keep Mac OS X on this for the moment, if only to avoid kernel recompiles and incompatibilities arising from that,
Whatever makes you happy, dear. Personally, I dumped Mac OS X because I got tired of the manual upgrades and install hassles; Debian has been much less effort to maintain and has a lot more software available for it. And kernel upgrades just work, with no recompiles, with Debian.
The point is that within the final cost of the item in question, there is not enough to support the claims of the article.
A metric ton of coal costs around US$30 (and will generate around 2500kWh of electricity). 240kg of fossil fuel therefore can cost as little as $7.50 and generate about 600kWh in electricity.
Energy from fossil fuels is cheap--far too cheap to account for its true cost to the world.
Multiply their figures out over even a modest level of production and the results become absurd.
The UN figures are, if anything, conservative estimates. What is really absurd is that supposedly civilized and educated people don't understand the impact they have on the world. If we are going to ruin the planet, let's at least do it with open eyes. The amount of stuff you and I and everybody else in the US really consume is truly staggering.
A filesystem should not be used to hold multiple versions of a file as well as the meta-data associated with it. Less not forgeting the associations of multiple files that become a project. This is the work of a database, hence BerkleyDB.
The UNIX file systems is a database. That's what it is designed to be, that's what it is used as, and that's what it is good at. It has an extensive set of tools for manipulating it and lots of excellent GUIs for dealing with it. Some current UNIX/Linux file system implementations are, in fact, implemented just like database software.
You are just mindlessly repeating what generations of Windows hackers stuck on flaky FAT file systems have told you.
If you are concerned about "repairing" a file (aka db), there are command-line tools for just such an event, but you will probably find that you just won't ever need them. Just my 5000 sheckles.
No, I'm "concerned" about having to use an entirely different set of tools to manipulate data in a DB, about DB performance for blobs, and for a Subversion installation breaking when I upgrade the DB shared library. All of those aren't theoretical problems, they actually happen in practice. And on UNIX, they are completely unnecessary problems and risks.
As I was saying, the Berkeley DB decision may make sense if the Subversion server is supposed to run on Windows or on MacOS. But as far as UNIX and Linux are concerned, it's a no-brainer: this kind of data belongs directly in the file system, not in databases.
That is to say, if you have 5 monitors (I do), that's equal an entire month of your total energy consumption? As a comparison, it takes about 250 kilos of gasonline to drive from Los Angeles to New York City. So, they are positing that it takes as much energy to produce a CRT as to propel 1.5 tons of metal and flesh 2800 miles at 70mph. Not. Bloody. Likely.
Well, and how do you think that CRT got to you? By carrier pigeon? Transportation, heating, etc. are all part of manufacturing.
And their statistic didn't even include the fact that it takes much more plant material to produce that coal in the first place.
It takes 98 tons of plant material (annual output from 40 acres) to make one gallong of gasoline.
Other facts from the same research:
Dukes also calculated that the amount of fossil fuel burned in a single year - 1997 was used in the study - totals 97 million billion pounds of carbon, which is equivalent to more than 400 times "all the plant matter that grows in the world in a year," including vast amounts of microscopic plant life in the oceans.
"Every day, people are using the fossil fuel equivalent of all the plant matter that grows on land and in the oceans over the course of a whole year," he adds.
In another calculation, Dukes determined that "the amount of plants that went into the fossil fuels we burned since the Industrial Revolution began [in 1751] is equal to all the plants grown on Earth over 13,300 years."
But how on earth is the option to spend hundreds of extra dollars on proprietary operating system software and the more-expensive hardware it requires "significantly lower[ing] the barrier to entry?"
Sunk costs: people have already paid for Windows, and they have already invested in training for it. But if you can get these people to move to OSS for some things, maybe you can get them to switch for others as well.
The problem is that putting the stuff into a database creates another dependency on a non-trivial piece of software. That creates all sorts of risks.
On UNIX/Linux systems, the file system is more than sufficient for handling this kind of storage and transactioning, so this dependency and risk is unnecessary.
I suspect Subversion uses a database because it may be intended to run on operating systems with less powerful file systems.
If your model of doctors is that they make mistakes 1/3 of the time (regardless of whether it's a simple diagnosis or complex surgery), you're going to be able to deal with them much more rationally and live longer. Doctors aren't any smarter than programmers or lawyers or politicians or interior designers. If anything, they have less quality control, testing, and supervision in place. And the system they deal with (the human body) is even less well understood than software, the law, politics, or interior design. So, look around at software, the legal system, politics, and interior design and ask yourself: do I want similar kinds of "experts" working on me?
So, when considering medical treatments, think about: does this treatment have the potential of doing me serious harm? Do I absolutely need this treatment? Should I get a second (and third) opinion? Is a 1/3 risk of the kind of mistake that can happen during this treatment/procedure worth the potential benefits?
Also keep in mind that most problems, doctors can't do much about anyway. Our increase in life expectancy actually comes almost exclusively from improvements in public health, not medical care. Which makes it all the more bizarre that we are spending such silly amounts on medical care.
I know, this may come as a surprise to many sysadmins, but you are in the customer service business. Your function in life is to make sure that people can get their work done as efficiently as possible. You may regard marketing and sales as a menage of moronic monkeys, but they bring in the money--you don't. If they ask you for something, even if it sounds stupid to you at first sight, you have to listen patiently, be nice, and figure out the best way in which they can be helped. If their request doesn't make any technical sense to you or can't be implemented, explain to them in the nicest possible way why and try to come up with another solution in cooperation with them.
Furthermore, the client software is quite lightweight and ran well even on Pentium machines. None of that is true for Adobe SVG at least.
Adobe's SVG viewer couldn't reuse existing XML, JavaScript, etc. libraries because they didn't exist when Adobe did it. And then there is the tiny problem that Adobe just seems incapable of producing good software: their PDF viewer is awful, their PDF authoring tools are awful, etc.
In any case, I would expect SVG Tiny and SVG Basic viewers to become fairly standard, and they should be quite lightweight because they don't actually require a lot of code, and what they do require they can reuse from system libraries.
It's their content, but it's our airwaves. They get to use our spectrum for free, so in exchange we should be able to watch TV in a reasonable way (e.g. time-shifting, archiving).
OK, but that arrangement seems obsolete and the deal "free content for free airwaves" just isn't one they seem interested in anymore. They'll take "copy-controlled content for free airwaves" if we give it to them. But we should probably go for a "copy-controlled content on annually leased airwaves" deal.
(The revenue from leasing the airwaves could even go towards public television and pay for free content.)
You can patent substance if it is new invented material
As I was saying: you can now. You didn't use to be able to. Patents used to be on processes, methods, or applications, not on substances.
The reason for the change was exactly (2): manufacturers were crying "foul". But the cure is apparently worse than the disease, since the new rules clearly stifle innovation.
I used to work for a small biotech company which claimed to have key patents for generation and using combinatorial libraries of small drug-like chemicals for pharma research. Everybody is now using the technology, and our company got nothing out of it
That sounds reasonable to me. The idea itself is very old and nobody within the last three decades should have been able to get "key" patents in that area. At best, a company might have gotten a patent on a specific, useful tweak. Your management and your investors should have known, too. Maybe the patent system does work sometimes...
OO has a long history, that is true, but OO in industrial/practical applications goes back further than you might think. People were "using" it in the 80s. OO is not a post-millennial fashion in tools.
In that sense, people have been "using" FP in industry since the 1960's. But OOP only caught on in any real sense in industry in the 1990's, and people are only now getting over the initial enthusiasm.
It took garbage collection nearly 40 years to become widely accepted.
That is not a function of the network effects of GC, but rather a function of the performance of the hardware to make GC appear to be invisible.
No, sorry, but you are buying into the same irrational prejudice that has kept industry from using GC in the first place. Any reasonable GC is, and has for the past 40 years been, no more expensive than your trusty manual C storage allocator. Furthermore, most of the other supposed advantages people ascribe to manual storage managers are myths. Altogether, there has never been a rational reason not to use GC.
Try in 2010. I am not trying to yank your chain, I am just saying that the adoption curve for Java (which has incredible network effects) hasn't stopped growing yet.
I didn't say it was going to happen tomorrow. I think for FP to catch on in industry may take another 20-30 years even. But eventually, it's going to happen in industry because there is no alternative. And smart players can get an early start, in particular since runtimes like CLR actually make a reasonable effort to support it in a multi-paradigm environment.
It's their content, they should be able to control it. I think they are fools if they try to keep people from copying it, since they won't be able to compete with content which will be copyable, but that's their folly and it's going to be their failed business model.
I only see a problem if they force every content provider to actually use that sort of stupidity, or if they try to keep competing content off the hardware that I paid for. I think that is a very serious risk, and one has to guard vigilantly against, because once their businesses start failing, they'll say that it's "unfair" to have to compete with free, or freely redistributable, or low-cost, and all that.
But, so far, the technology doesn't seem to let them do that. That is, if companies or individuals want to provide free content, or copyable content, or whatever, they can do that under that system with no problem.
I think it used to be the case that (for the most part) you couldn't claim a patent on a substance, only on its manufacture and its applications. That seems pretty sensible to me.
Sadly, that principle seems to have eroded away, and there are many patents on substances now that cover all future applications and ways of manufacturing them. Seems to me like that runs against the purpose of the patent system: to encourage useful innovation. I mean, if you can just claim all possible ways of manufacturing a substance and all possible ways of using it by just describing the substance, why would anybody else want to invest in finding better ways of manufacturing it or new applications for it?
In any case, this particular patent should run out in less than a decade, so it probably won't be all that significant.
Scheme is not a functional programming language, it is very much imperative programming language that supports a functional programming style.
Furthermore, Scheme is more like the assembly language of functional programming; "real" functional programming languages have much better facilities (type systems, data types, module systems, type inference, etc.) to support the construction of large software systems.
It took OOP nearly 30 years to catch on for good. It took garbage collection nearly 40 years to become widely accepted.
The industry will come around to functional programming eventually: OOP simply isn't up to the task of building large systems that are also reliable and robust. FP is much better at that. I don't know how many more failed space probes, software disasters, and power outages it will take before people catch on to that fact, but it will happen.
Russia continued to burn up RTGs even after we'd stopped. One satellite actually burned up over Canada. No deaths were ever linked to the incident,
That's just a stupid argument. I'm sorry if you don't understand why that's a stupid argument despite my explanation, but that's your problem.
As for how dangerous Plutonium actually is, that's an entirely different question. As I was saying, it's probably not very dangerous, but that isn't the main issue in deciding whether to use it on space missions. I'm sorry if that also goes over your head, but, again, that's your own intellectual limitation.
Conversion between SWF, XML, and SVG may be useful for limited applications. But SWF just isn't a replacement for SVG.
One serious problem is that the one Flash viewer that actually counts, the one from Macromedia, makes an exceptionally poor vector graphics viewer: among many other things, it lacks the UI for it and it lacks the scaling.
When it comes down to it, SWF is something that appeals to artists and marketers for pushing content on users that users may not even want. Open vector graphics formats like SVG, on the other hand, have real, serious applications for the representation and exchange of graphical content in vector form.
Are you on crack? *Everybody* supports flash, and it was already the defacto before they open sourced their format in 2000
Right now, Flash is Macromedia's player and Macromedia's specification. There are no third party players of any significance. There aren't even a lot of third party authoring tools of any significance.
And Flash succeeded solely because Macromedia wrote authoring tools people liked. That let them get the player into browsers. Technical merit of the format had nothing to do with it.
A documented format is better than an undocumented one, but Flash is still fully controlled by Macromedia. Nobody other than them has any way of changing the standard if they don't want you to.
If SVG attains a native compressor/decompressor pair, if compression in HTTP starts taking on alternate algorithms for alternate tasks, or if we see a binary compiled form of SVG, *then* *and* *only* *then* do I see it as a competitor to Flash, which can make complex UI interactions with high graphic precision in a handful of K.
That's exactly the problem: you cannot implement complex UI interactions in Flash at all--Flash is absolutely pathetic for user interfaces. Furthermore, Flash is not a good vector graphics format--it is far too oriented towards animation and scripting for that. What Flash is good for, and pretty much the only thing it's good for, is little games and animations. Flash is there because marketers want it to be there, not because there is demand on the side of users.
SVG, on the other hand, is an open vector graphics standard. The world needs a new, web-based open vector graphics standard: we need it for nice graphical content on web pages, we need it for maps, for scientific information, and lots of other purposes. Whether SVG is compressed or not doesn't matter; standard text compression works well enough.
I'll be much much more convinced when you see a converter from one to the other, or bidirectional. I wouldn't at all be surprised to see SVG end up as an intermediary language between data and representation.
Flash viewers make poor vector graphics renderers: they have the wrong UI for it and they have the wrong browser interaction for it. They also are poorly integrated into HTML and the DOM. But, yes, you can get converters already if you like. Poor as Flash may be for that purpose, it's probably still better than nothing.
Let's just hope we'll get SVG Tiny and SVG Basic renderers into web browsers soon.
It fails to define the term 'intellectual property rights', so interpretation will vary hugely from country to country when/if the directive becomes law, undermining one of the main objectives of the legislation: harmonising EU law.
OK, good, so when we believe Vivendi Universal is using GPL'ed software in violation of the provisions of the license, I guess that means we can have their corporate hardware and software seized and the homes of their corporate officers searched.
Furthermore, the amount of encrypted (so-called VPN) traffic entering and leaving their site clearly indicates that they must be running a covert file sharing network and using cryptography to share illegally obtained content.
These people are still living in the intellectual dark ages, where they think that they are the only ones who hold copyrights. I think if they started becoming aware what risks they expose their own companies to, they might tread a little more carefully with such proposals.
According to the BSA, 25 per cent of software in use in the UK is illegal. It claims that reducing this to 15 per cent would generate an extra 2.5bn in tax revenues and 40,000 jobs in the IT sector
Imposing an extra 2.5 billion pounds in taxes on revenues, plus an extra 25 billion pounds in costs on businesses, would be a huge minus for the economy, in particular given that a lot of those 25 billion pounds would be leaving Europe. And how is paying more money to the likes of Microsoft or Oracle going to create IT jobs? But, I suppose, those kinds of arguments may make sense to an association aptly named the "B.S. Association".
The solution, of course, is not to pirate commercial software, the solution is to dump it altogether.
I would actually be all for the most draconian enforcement of commercial licenses possible. But I fear that much of this is actually a smokescreen for hassling open source users, because the presumption will likely be that if you didn't pay for a Microsoft license, you must have pirated their software.
Slashdot Mirror
Trolltech and KDE have worked out an agreement that I think addresses most issues people have with the QT license. Trolltech has developed a great desktop environment and cross OS development toolkit and commercial licensing has paid for much of it (which in turn allowed Kdevelop to become such an incredible tool for linux/windows/osx GPL development).
Oh, please, spare us the marketing speech. I pointed out that it is incompatible with the Gnome licenses: Gnome libraries are LGPL and Qt is dual-licensed GPL/commercial. It doesn't matter what spin you try to put on that, that's just a legal fact.
If you want to talk about consequences, you can see those in the market: Gnome is a thriving project and is becoming the de-facto standard for commercial UNIX and Linux systems. If Qt had been LGPL from the start, the Gnome project would have never started.
In a few years it won't hurt to have both installed and freedesktop.org will hopefully allow for theme unification.
If we are still running something called "Gnome" and/or "KDE" in a few years, they'll hopefully not be based on bloated, obsolete C or C++ libraries.
What I *AM* arguing is that their figures are dishonest. They are naming a very specific item and advocating an action--on that exact item. They gave a specific _MASS_ of fossil fuels. That the amount of energy available in that mass can be directly attributed to the specific action of manufacturing something as simple as a CRT is what I am questioning.
Governments, economists and corporations make those kinds of attributions again and again. You have presented no argument that there is anything wrong with it.
Also, the argument to use old equipment rather than new betrays the lie. New equipment is more energy efficient.
Not really. LCDs happen to be more energy efficient than CRTs, but that's the exception rather than the rule.
It'll be interesting to read a decent "neutral" KDE 3.2 vs Gnome 2.6 article though!
About as interesting as a "neutral" Britney Spears vs. Paris Hilton article.
something to be encouraged until hopefully one day somehow the libraries can be unified.........
They could have been unified long ago if the Qt license (GPL) didn't prevent it. You see, ultimately, the difference between KDE and Gnome doesn't come down to technology, it comes down to licenses, and the Qt license just doesn't work for many people.
GNOME vs. KDE will perhaps be one of the holy wars of this millennium,
Yes, and like most holy wars, it's about obsolete ideas. Gnome and KDE are both serviceable desktop environments, but let's not kid ourselves: imitating Windows and MacOS should not be the future of computing.
Personally I'll keep Mac OS X on this for the moment, if only to avoid kernel recompiles and incompatibilities arising from that,
Whatever makes you happy, dear. Personally, I dumped Mac OS X because I got tired of the manual upgrades and install hassles; Debian has been much less effort to maintain and has a lot more software available for it. And kernel upgrades just work, with no recompiles, with Debian.
The point is that within the final cost of the item in question, there is not enough to support the claims of the article.
A metric ton of coal costs around US$30 (and will generate around 2500kWh of electricity). 240kg of fossil fuel therefore can cost as little as $7.50 and generate about 600kWh in electricity.
Energy from fossil fuels is cheap--far too cheap to account for its true cost to the world.
Multiply their figures out over even a modest level of production and the results become absurd.
The UN figures are, if anything, conservative estimates. What is really absurd is that supposedly civilized and educated people don't understand the impact they have on the world. If we are going to ruin the planet, let's at least do it with open eyes. The amount of stuff you and I and everybody else in the US really consume is truly staggering.
A filesystem should not be used to hold multiple versions of a file as well as the meta-data associated with it. Less not forgeting the associations of multiple files that become a project. This is the work of a database, hence BerkleyDB.
The UNIX file systems is a database. That's what it is designed to be, that's what it is used as, and that's what it is good at. It has an extensive set of tools for manipulating it and lots of excellent GUIs for dealing with it. Some current UNIX/Linux file system implementations are, in fact, implemented just like database software.
You are just mindlessly repeating what generations of Windows hackers stuck on flaky FAT file systems have told you.
If you are concerned about "repairing" a file (aka db), there are command-line tools for just such an event, but you will probably find that you just won't ever need them. Just my 5000 sheckles.
No, I'm "concerned" about having to use an entirely different set of tools to manipulate data in a DB, about DB performance for blobs, and for a Subversion installation breaking when I upgrade the DB shared library. All of those aren't theoretical problems, they actually happen in practice. And on UNIX, they are completely unnecessary problems and risks.
As I was saying, the Berkeley DB decision may make sense if the Subversion server is supposed to run on Windows or on MacOS. But as far as UNIX and Linux are concerned, it's a no-brainer: this kind of data belongs directly in the file system, not in databases.
That is to say, if you have 5 monitors (I do), that's equal an entire month of your total energy consumption? As a comparison, it takes about 250 kilos of gasonline to drive from Los Angeles to New York City. So, they are positing that it takes as much energy to produce a CRT as to propel 1.5 tons of metal and flesh 2800 miles at 70mph. Not. Bloody. Likely.
Well, and how do you think that CRT got to you? By carrier pigeon? Transportation, heating, etc. are all part of manufacturing.
And their statistic didn't even include the fact that it takes much more plant material to produce that coal in the first place.
Other facts from the same research:
But how on earth is the option to spend hundreds of extra dollars on proprietary operating system software and the more-expensive hardware it requires "significantly lower[ing] the barrier to entry?"
Sunk costs: people have already paid for Windows, and they have already invested in training for it. But if you can get these people to move to OSS for some things, maybe you can get them to switch for others as well.
The problem is that putting the stuff into a database creates another dependency on a non-trivial piece of software. That creates all sorts of risks.
On UNIX/Linux systems, the file system is more than sufficient for handling this kind of storage and transactioning, so this dependency and risk is unnecessary.
I suspect Subversion uses a database because it may be intended to run on operating systems with less powerful file systems.
If your model of doctors is that they make mistakes 1/3 of the time (regardless of whether it's a simple diagnosis or complex surgery), you're going to be able to deal with them much more rationally and live longer. Doctors aren't any smarter than programmers or lawyers or politicians or interior designers. If anything, they have less quality control, testing, and supervision in place. And the system they deal with (the human body) is even less well understood than software, the law, politics, or interior design. So, look around at software, the legal system, politics, and interior design and ask yourself: do I want similar kinds of "experts" working on me?
So, when considering medical treatments, think about: does this treatment have the potential of doing me serious harm? Do I absolutely need this treatment? Should I get a second (and third) opinion? Is a 1/3 risk of the kind of mistake that can happen during this treatment/procedure worth the potential benefits?
Also keep in mind that most problems, doctors can't do much about anyway. Our increase in life expectancy actually comes almost exclusively from improvements in public health, not medical care. Which makes it all the more bizarre that we are spending such silly amounts on medical care.
I know, this may come as a surprise to many sysadmins, but you are in the customer service business. Your function in life is to make sure that people can get their work done as efficiently as possible. You may regard marketing and sales as a menage of moronic monkeys, but they bring in the money--you don't. If they ask you for something, even if it sounds stupid to you at first sight, you have to listen patiently, be nice, and figure out the best way in which they can be helped. If their request doesn't make any technical sense to you or can't be implemented, explain to them in the nicest possible way why and try to come up with another solution in cooperation with them.
Furthermore, the client software is quite lightweight and ran well even on Pentium machines. None of that is true for Adobe SVG at least.
Adobe's SVG viewer couldn't reuse existing XML, JavaScript, etc. libraries because they didn't exist when Adobe did it. And then there is the tiny problem that Adobe just seems incapable of producing good software: their PDF viewer is awful, their PDF authoring tools are awful, etc.
In any case, I would expect SVG Tiny and SVG Basic viewers to become fairly standard, and they should be quite lightweight because they don't actually require a lot of code, and what they do require they can reuse from system libraries.
It's their content, but it's our airwaves. They get to use our spectrum for free, so in exchange we should be able to watch TV in a reasonable way (e.g. time-shifting, archiving).
OK, but that arrangement seems obsolete and the deal "free content for free airwaves" just isn't one they seem interested in anymore. They'll take "copy-controlled content for free airwaves" if we give it to them. But we should probably go for a "copy-controlled content on annually leased airwaves" deal.
(The revenue from leasing the airwaves could even go towards public television and pay for free content.)
You can patent substance if it is new invented material
As I was saying: you can now. You didn't use to be able to. Patents used to be on processes, methods, or applications, not on substances.
The reason for the change was exactly (2): manufacturers were crying "foul". But the cure is apparently worse than the disease, since the new rules clearly stifle innovation.
I used to work for a small biotech company which claimed to have key patents for generation and using combinatorial libraries of small drug-like chemicals for pharma research. Everybody is now using the technology, and our company got nothing out of it
That sounds reasonable to me. The idea itself is very old and nobody within the last three decades should have been able to get "key" patents in that area. At best, a company might have gotten a patent on a specific, useful tweak. Your management and your investors should have known, too. Maybe the patent system does work sometimes...
In that sense, people have been "using" FP in industry since the 1960's. But OOP only caught on in any real sense in industry in the 1990's, and people are only now getting over the initial enthusiasm.
That is not a function of the network effects of GC, but rather a function of the performance of the hardware to make GC appear to be invisible.
No, sorry, but you are buying into the same irrational prejudice that has kept industry from using GC in the first place. Any reasonable GC is, and has for the past 40 years been, no more expensive than your trusty manual C storage allocator. Furthermore, most of the other supposed advantages people ascribe to manual storage managers are myths. Altogether, there has never been a rational reason not to use GC.
Try in 2010. I am not trying to yank your chain, I am just saying that the adoption curve for Java (which has incredible network effects) hasn't stopped growing yet.
I didn't say it was going to happen tomorrow. I think for FP to catch on in industry may take another 20-30 years even. But eventually, it's going to happen in industry because there is no alternative. And smart players can get an early start, in particular since runtimes like CLR actually make a reasonable effort to support it in a multi-paradigm environment.
It's their content, they should be able to control it. I think they are fools if they try to keep people from copying it, since they won't be able to compete with content which will be copyable, but that's their folly and it's going to be their failed business model.
I only see a problem if they force every content provider to actually use that sort of stupidity, or if they try to keep competing content off the hardware that I paid for. I think that is a very serious risk, and one has to guard vigilantly against, because once their businesses start failing, they'll say that it's "unfair" to have to compete with free, or freely redistributable, or low-cost, and all that.
But, so far, the technology doesn't seem to let them do that. That is, if companies or individuals want to provide free content, or copyable content, or whatever, they can do that under that system with no problem.
I think it used to be the case that (for the most part) you couldn't claim a patent on a substance, only on its manufacture and its applications. That seems pretty sensible to me.
Sadly, that principle seems to have eroded away, and there are many patents on substances now that cover all future applications and ways of manufacturing them. Seems to me like that runs against the purpose of the patent system: to encourage useful innovation. I mean, if you can just claim all possible ways of manufacturing a substance and all possible ways of using it by just describing the substance, why would anybody else want to invest in finding better ways of manufacturing it or new applications for it?
In any case, this particular patent should run out in less than a decade, so it probably won't be all that significant.
Scheme is not a functional programming language, it is very much imperative programming language that supports a functional programming style.
Furthermore, Scheme is more like the assembly language of functional programming; "real" functional programming
languages have much better facilities (type systems, data types,
module systems, type inference, etc.) to support the construction of large software systems.
It took OOP nearly 30 years to catch on for good. It took garbage collection nearly 40 years to become widely accepted.
The industry will come around to functional programming eventually: OOP simply isn't up to the task of building large systems that are also reliable and robust. FP is much better at that. I don't know how many more failed space probes, software disasters, and power outages it will take before people catch on to that fact, but it will happen.
That's just a stupid argument. I'm sorry if you don't understand why that's a stupid argument despite my explanation, but that's your problem.
As for how dangerous Plutonium actually is, that's an entirely different question. As I was saying, it's probably not very dangerous, but that isn't the main issue in deciding whether to use it on space missions. I'm sorry if that also goes over your head, but, again, that's your own intellectual limitation.
Conversion between SWF, XML, and SVG may be useful for limited applications. But SWF just isn't a replacement for SVG.
One serious problem is that the one Flash viewer that actually counts, the one from Macromedia, makes an exceptionally poor vector graphics viewer: among many other things, it lacks the UI for it and it lacks the scaling.
When it comes down to it, SWF is something that appeals to artists and marketers for pushing content on users that users may not even want. Open vector graphics formats like SVG, on the other hand, have real, serious applications for the representation and exchange of graphical content in vector form.
Are you on crack? *Everybody* supports flash, and it was already the defacto before they open sourced their format in 2000
Right now, Flash is Macromedia's player and Macromedia's specification. There are no third party players of any significance. There aren't even a lot of third party authoring tools of any significance.
And Flash succeeded solely because Macromedia wrote authoring tools people liked. That let them get the player into browsers. Technical merit of the format had nothing to do with it.
A documented format is better than an undocumented one, but Flash is still fully controlled by Macromedia. Nobody other than them has any way of changing the standard if they don't want you to.
If SVG attains a native compressor/decompressor pair, if compression in HTTP starts taking on alternate algorithms for alternate tasks, or if we see a binary compiled form of SVG, *then* *and* *only* *then* do I see it as a competitor to Flash, which can make complex UI interactions with high graphic precision in a handful of K.
That's exactly the problem: you cannot implement complex UI interactions in Flash at all--Flash is absolutely pathetic for user interfaces. Furthermore, Flash is not a good vector graphics format--it is far too oriented towards animation and scripting for that. What Flash is good for, and pretty much the only thing it's good for, is little games and animations. Flash is there because marketers want it to be there, not because there is demand on the side of users.
SVG, on the other hand, is an open vector graphics standard. The world needs a new, web-based open vector graphics standard: we need it for nice graphical content on web pages, we need it for maps, for scientific information, and lots of other purposes. Whether SVG is compressed or not doesn't matter; standard text compression works well enough.
I'll be much much more convinced when you see a converter from one to the other, or bidirectional. I wouldn't at all be surprised to see SVG end up as an intermediary language between data and representation.
Flash viewers make poor vector graphics renderers: they have the wrong UI for it and they have the wrong browser interaction for it. They also are poorly integrated into HTML and the DOM. But, yes, you can get converters already if you like. Poor as Flash may be for that purpose, it's probably still better than nothing.
Let's just hope we'll get SVG Tiny and SVG Basic renderers into web browsers soon.
It fails to define the term 'intellectual property rights', so interpretation will vary hugely from country to country when/if the directive becomes law, undermining one of the main objectives of the legislation: harmonising EU law.
OK, good, so when we believe Vivendi Universal is using GPL'ed software in violation of the provisions of the license, I guess that means we can have their corporate hardware and software seized and the homes of their corporate officers searched.
Furthermore, the amount of encrypted (so-called VPN) traffic entering and leaving their site clearly indicates that they must be running a covert file sharing network and using cryptography to share illegally obtained content.
These people are still living in the intellectual dark ages, where they think that they are the only ones who hold copyrights. I think if they started becoming aware what risks they expose their own companies to, they might tread a little more carefully with such proposals.
According to the BSA, 25 per cent of software in use in the UK is illegal. It claims that reducing this to 15 per cent would generate an extra 2.5bn in tax revenues and 40,000 jobs in the IT sector
Imposing an extra 2.5 billion pounds in taxes on revenues, plus an extra 25 billion pounds in costs on businesses, would be a huge minus for the economy, in particular given that a lot of those 25 billion pounds would be leaving Europe. And how is paying more money to the likes of Microsoft or Oracle going to create IT jobs? But, I suppose, those kinds of arguments may make sense to an association aptly named the "B.S. Association".
The solution, of course, is not to pirate commercial software, the solution is to dump it altogether.
I would actually be all for the most draconian enforcement of commercial licenses possible. But I fear that much of this is actually a smokescreen for hassling open source users, because the presumption will likely be that if you didn't pay for a Microsoft license, you must have pirated their software.