Well, on the bright side your frustration is a worthy price to pay for the community to hear from someone who actually works on the project and knows what's happening from the inside.
But you really don't need to provide maximum PGO optimization of a binary to to achieve acceptable performance. Only an idiot would be benchmarking the 32-bit windows executables instead of the 64-bit WinVista/Win7 systems nowadays, and no matter how much you optimize, any system that actually requires 32 bit windows is probably old enough that the users are going to gripe about it being slow no matter what you do.
It's called an "obsolete platform", and it's time to start gracefully retiring it from the forefront of the build schedules and project priorities.
Sounds like Microsoft took a step backwards with the newer versions of their compilers. When there were still 16-bit windows systems around, you just set a compiler option to produce Win/16 code instead of default Win/32 code under NT 3.5.
But I can't say I'm really surprised -- Microsoft would really rather the world stop running 32-bit Windows entirely. I was shocked that they did a 32 bit release of 7 at all, as the OS is enough of a pig that it won't run acceptably on any CPU old enough to require the 32 bit instruction set instead of AMD64 extensions.
And I'm afraid that I really don't think it's worth the effort and worry of this freakish optimization engine to support the WinXP/WinVista 32-bit user base. Their machines are old enough that they'll blame the old clunker for performance problems, and rightly so.
Who says you have to use Microsoft build tools to produce a Win32 executable? As far as I know, Intel still produces the tightest, fastest code for the 32-bit and 64-bit windows APIs, and there are others as well.
Excuse me, the "updating the entire Windows build farm"?
Why in God's name would you need more than one computer to be automatically doing the nightly build even if it has to be running the same OS family as the target platform?
Let's see, build farm, build farm... Linux/RPM, Linux/DEB, Win7/64, Win/32, maybe a BSD, HP-UX, AIX, and Solaris box thrown in for giggles. I count 8 build servers, not a "farm".
I've always been surprised that this much safer molten-salt thorium technology has never been widely deployed, given how long it's been since it was successfully tested and proven to work.
Why do we continue to deploy uranium based systems when we already know there's a serious shortage of easily mined uranium in the world, with some projections of reactors becoming cost prohibitive in under 20 years due to shortages of uranium fuel?
We won't run out of uranium any time soon, but it's not going to be a profitable or safe fuel choice for much longer at all, and I don't see the sense to investing billions in power plants of any kind if you can't expect at least a 50 year run for the investment.
Blame the do-gooder liberals who've invoked their Charter rights in Canada to have legislation against social "evils" like prostitution pulled from the lawbooks.
Blame the do-gooder conservatives who've ignored the Charter rights to impose legislation against anything they consider morally reprehensible, regardless of the individual's guaranteed rights.
Blame the paedophile leeches in society who pay for the drug-addicted child prostitute's services.
But don't blame the beat cops who have their hands tied by society and have to see it happening every day.
It sounds like a build-tool chain problem, not an issue with the eventual binary produced for Firefox.
Why not just run the 64-bit tools on a 64-bit platform and have them output 32-bit code, the same as can be done by virtually any cross-platform compiler system. I can't imagine worrying about the fact that I can't run the builds on an outdated 32-bit OS as long as I can produce the binaries for such platforms.
I shudder to think what it would have been like to develop for some of the military communications systems I worked on for my first job if we had to run the compilers on that pathetically slow mil-spec Sperry AN-UYK system (magnetic core memory -- talk about slowing down the CPU! But it's radiation hard!) We only tested on the Sperry -- all builds and editing were done on a VAX.
In modern terms, could you imagine having to run your editors and compilers on an iDevice instead of OS/X?
See my earlier post about the Canadian Long Gun Registry database deletion.
For a much smaller database that's only cross-linked by government and law-enforcement systems, it's currently expected to take FIVE YEARS to really delete the data because of the number of archived databases that have to be restored, updated to clear the references, and re-archived. Plus the cascading effect of having to potentially update systems that reference the first level of external system references. And it only keeps spreading.
At least the government doesn't have an extensive and growing set of peer and partner external systems that would also have to be updated.
The best one can hope is that once a post is flagged as deleted, Facebook will no longer return the content data for that post to any requests for it regardless of the source, effectively nulling out all those external references with 404 errors.
I agree, it should be your choice. However, I'm one who really, really likes the idea of keeping an edit history for posts if one so chooses.
And I can understand why Facebook doesn't actually delete the data, but just flags it as hidden/deleted -- it's a real bear to update and nullify all the object id references to a post in such a mammoth system. There are links all over the place from people whose "feed" pages may reference your post. There are forwards and reposts of your post which create a commented link to your post -- does your right to delete your post mean you have the right to delete the posts of people who've commented on it?
Given that some of the content links could be in archived databases instead of mainline storage or cache, updating them could be virtually impossible.
Canada is facing the same issue with it's Long Gun Registry being shut down by Harper's Conservative government -- the data is cross-linked throughout government and law enforcement system, with over a decade of archived databases referencing the LGR databases. Truly deleting the data requires restoring the archived external databases, updating their contents to remove the references, exporting the database for an updated backup, and archiving it for storage.
Now there's the cascade effect -- any references to the archive disks now have to be updated to reference the new archive database content instead of the original.
They're currently expecting it to take over FIVE YEARS to purge that one database, and it's pitifully small compared to Facebook or Google.
Never mind the potential legal issues of external and archive systems that are mandated to be write-only by government legislation, and which have to be retained for 7-10 years in many cases.
Realistically, a versioning system or flagging content as deleted instead of purging it is the only option available for large systems that maintain historical data of any significant size.
Those are some very nice performance numbers the Facebook team achieved. Kudos. Time well invested.
One of these days I need to write a compiler for my own stuff. Re-interpreting strings a few thousand times is the next big optimization opportunity I have for my core library. Eliminating that re-parsing should garner a nice performance improvement, though I envision compiling to a set of runtime objects rather than actual bytecode or native Java source. Faster than p-Code or a non-JIT JVM, but not as fast as it could be if I went crazy optimizing things.
Care to cite even one customer of the Microsoft portfolio paying for the FAT patent? Because any vendor who pays a patent royalty for that particular patent is not defending against patent abuse, and automatically loses their right to use or distribute GPL or LGPL software. Even v2 of the licenses was very clear on this point -- you must pay to have a patent overturned if you want to use and deploy software based on the GPL family of licenses.
The one case where the patents in question were exposed to the public made no mention of the FAT patent being part of the Android patent portfolio that Microsoft is using to earn money from Android. Even Microsoft isn't about to piss off their patent customer base by "accidentally" including that patent and killing the customer's right to use Android at all.
I don't think you grasp the app store and DRM subtleties.
Because you cannot replace even an LGPL library at will with a DRM-encombered platform, the changes VLC has made do not deal with the Apple incompatibilities. They merely elevate the VLC library from a product-specific library to a shared vendor-neutral source library that anyone can use in their own media players.
Certainly VLC video player itself is still restricted from iOS deployment by the GPL covering the main product itself.
Blame Apple. The GPL beat their iOS devices to market by almost two decades, and has served the software industry as a whole rather well. While you're at it, blame Apple for blocking Java deployment to iOS devices, and for trying to abandon Java support for OS/X devices.
Apple wants a walled garden for their users. Good for them. They've locked me out, and I could care less. It just means their users will never see anything better than a web form interface, and that not for at least another year or two, while any Java/GPL compatible platform will have support in a few more weeks. I will not subject my software to the anti-freedom clauses of the Apple kool-aid company.
Software as a service. Data as a service. Maintenance as a service. Updates as a service.
Only the unimaginative can't come up with a way to make money while releasing their core code under the GPLv3. In fact, the GPLv3 makes it easier to leverage software for profit than most commercial software licenses, because it addicts the user to community to a steady update stream, something that rarely happens with.x commercial product releases.
The key is to think in terms of software and service leasing instead of product sales of a package. You're right -- you can't make significant money with GPL software if your goal is to sell a canned package.
And only someone as ill informed as you would not recognize the benefits of being able to modify code before it executes in a breakpoint debugger, and to have that modified code execute without having to rebuild and restart the debugger.
In place code editing is a Godsend regardless of whether you're getting it with Eclipse/Java or VStudio/C#/C++.
The issue is not OS/X development and deployment, but the conflict between DRM-enabled iOS applications and [L]GPLv3 license requirements that anyone be able to deploy an updated version of such software without having to obtain or pay for a DRM encryption key. As long as signing keys can't be published with the software source, you can't do a build for a DRM-encumbered platform, and are not allowed to deploy GPL-based software to such platforms at all.
Despite the bleating of those who might miss out on open source applications for iOS devices as a result, this requirement is something [L]GPL developers make a conscious decision to require for their software. If you want to blame someone, blame the owners of the DRM walled gardens on the market. They're the ones who won't allow unsigned code that would enable [L]GPL software use on those platforms.
Another point some people don't understand are the clauses of v3 of the licenses. They added language to make it explicitly illegal to "wrap" [L]GPL code in the fashion someone suggested I do for an Eclipse GUI component of my software. There is no way to hide the fact that you're relying on GPL code any more. If you do so, you have to publish the code as long as the product is being accessed directly or indirectly by customers, clients, business partners, or anyone else outside an organization -- and that includes contractors.
If the GPLv3 had not had those restrictions to prevent people from stealing my customer base by enhancing the GPL code but not sharing the enhancements, I would not have released my work as open source at all.
At least now I'll know why AdBlock Plus appares to "break" on it's next update, and how to fix it so it stops ALL ads again.
I know the websites make money from eyeball revenue, but I spend way too many hours of my day on the 'net to spend it inundated by advertising. Were I spending a few minutes or an hour surfing the way the general public does, I wouldn't bother blocking ads at all. But I am constantly on documentation sites and such, and even they blare the media message 24x7.
It's too distracting when you're supposed to be working. Would any company tolerate their background music provider suddenly shilling products instead of setting a work-conducive mood? How about some ads embedded in your Powerpoint presentations and company paperwork?
That's the level that "internet advertising" interferes with my ability to work if I don't use AdBlock Plus.
I'd add Azureus Vuze to that list. While it is nagware, it's also the richest content management platform I've seen on Linux or Windows systems. The Windows implementation is a bit more feature rich and responsive, but the Linux version is more stable.
Sometimes adding kitchen sink features like a video player to a download tool just add bloat and inconvenience. The Windows build of Vuze is like that -- it used to launch whatever video player you had configured under the Azureus brand. Now "Vuze" insists on launching it's own bloatware instead. Yet this was the only "new" feature added when they rebranded Azureus to Vuze that I could see -- a step backwards in providing a standard but customizable platform interface my opinion.
I dislike every product that tries to override or ignore my choice of preferred application for dealing with content of any kind.
Quite the contradiction, isn't it? I say it's the best UI I've seen for content management, and at the same time backhand them for content presentation. Still, it's true -- they've done a great job except for that one insanely annoying "feature".
If the default behaviour is to claim infringement over every non-infringing work you've published to YouTube, then I'd have to say the detection system is fraudulently broken and arbitrarily taking the side of big media.
A police officer who wrote jaywalking tickets to everyone on the street, assuming that they must have crossed from the other side illegally, would rapidly be subject to lawsuits from an outraged public and stripped of their badge. It sounds like YouTube's software does just that.
The fact that you can defend yourself against that abusive bastard's harassment in the court of the system interface does not excuse them from failing to properly train their "software officer" on the disadvantages of harassing people for not breaking the law.
All any DRM-enabled platform has to do to solve the GPLv3 incompatability is to allow their users to install non-DRM applications within the framework. With C#/.Net or Java this is achieved by deplying unsigned DLLs, EXEs, and Jars. Where Apple falls down on GPLv3 compatibility is in mandating that you must sign the code.
I didn't see the Microsoft article clarifying their position on unsigned code distribution and installation for Windows 8. The fact that they want to allow FOSS doesn't mean that they haven't stepped in the same DRM puddle as Apple.
And you can download, compile, and distribute the source code for any non-DRM platform you choose. The GPL does not ban DRM, it merely requires that you provide all the pieces needed to build and run the software on a DRM-enabled platform, including any necessary signature keys.
However, I could see Apple not wanting those signature keys being made public. If they do that, they are not legally allowed to provide a distribution channel for GPLv3 software at all.
Personally it's no skin off my nose -- my application code is for servers, not handheld toys and video players. And even if that weren't the case, there'd be Apple's bigotry against Java in the way to start with.
Too bad, so sad, I'll never provide an iDevice interface beyond a web form. Apple made that choice, not me.
Interesting. I didn't even realize Eclipse had C++ support. But I must admit, they'd have to bring their Java development A-game features to C++ to be able to compete with Visual Studio for developing in C++. My big beef with VS is the underlying libraries which provide an insultingly bare bones implementation of ANSI and POSIX API standards rather than genuinely providing the functionality under Windows.
Let's face it -- Microsoft does not want you coding to portable standards -- they want you locking in to the Windows APIs that do implement the functionality they've crippled out of the standards-based versions.
The *AA engage in bullying, theft, "hollywood accounting", and false claims of ownership or copyright violation to generate revenue.
My God. They're greedy. Apparently the writer of this article was the last innocent who didn't realize that.
The question is not whether they're greedy pilfering thieves laying false claims, but what can be done through the courts to sue the bastards for their attempts to steal public domain content and claim it as their own. I want to see the *AA paying the government who paid for the public domain content to collect copyright violation damages at least as high as what these bastards come after individuals for.
Slashdot Mirror
Microsoft doesn't offer a 64-bit compiler that cross-compiles to 32-bit. Fine, I can accept that. But there are other compilers one could use:
http://software.intel.com/en-us/articles/intel-compilers/ is still reputed to produce the tightest, fastest WinXX executables available.
http://www.embarcadero.com/products/cbuilder (formerly Borland C++)
The venerable http://gcc.gnu.org/
http://www.ghs.com/products/optimizingC++EC++Compilers.html (though it looks like GHC might no longer target Windows at all)
Well, on the bright side your frustration is a worthy price to pay for the community to hear from someone who actually works on the project and knows what's happening from the inside.
But you really don't need to provide maximum PGO optimization of a binary to to achieve acceptable performance. Only an idiot would be benchmarking the 32-bit windows executables instead of the 64-bit WinVista/Win7 systems nowadays, and no matter how much you optimize, any system that actually requires 32 bit windows is probably old enough that the users are going to gripe about it being slow no matter what you do.
It's called an "obsolete platform", and it's time to start gracefully retiring it from the forefront of the build schedules and project priorities.
Sounds like Microsoft took a step backwards with the newer versions of their compilers. When there were still 16-bit windows systems around, you just set a compiler option to produce Win/16 code instead of default Win/32 code under NT 3.5.
But I can't say I'm really surprised -- Microsoft would really rather the world stop running 32-bit Windows entirely. I was shocked that they did a 32 bit release of 7 at all, as the OS is enough of a pig that it won't run acceptably on any CPU old enough to require the 32 bit instruction set instead of AMD64 extensions.
And I'm afraid that I really don't think it's worth the effort and worry of this freakish optimization engine to support the WinXP/WinVista 32-bit user base. Their machines are old enough that they'll blame the old clunker for performance problems, and rightly so.
Who says you have to use Microsoft build tools to produce a Win32 executable? As far as I know, Intel still produces the tightest, fastest code for the 32-bit and 64-bit windows APIs, and there are others as well.
Excuse me, the "updating the entire Windows build farm"?
Why in God's name would you need more than one computer to be automatically doing the nightly build even if it has to be running the same OS family as the target platform?
Let's see, build farm, build farm... Linux/RPM, Linux/DEB, Win7/64, Win/32, maybe a BSD, HP-UX, AIX, and Solaris box thrown in for giggles. I count 8 build servers, not a "farm".
I've always been surprised that this much safer molten-salt thorium technology has never been widely deployed, given how long it's been since it was successfully tested and proven to work.
Why do we continue to deploy uranium based systems when we already know there's a serious shortage of easily mined uranium in the world, with some projections of reactors becoming cost prohibitive in under 20 years due to shortages of uranium fuel?
We won't run out of uranium any time soon, but it's not going to be a profitable or safe fuel choice for much longer at all, and I don't see the sense to investing billions in power plants of any kind if you can't expect at least a 50 year run for the investment.
Blame the do-gooder liberals who've invoked their Charter rights in Canada to have legislation against social "evils" like prostitution pulled from the lawbooks.
Blame the do-gooder conservatives who've ignored the Charter rights to impose legislation against anything they consider morally reprehensible, regardless of the individual's guaranteed rights.
Blame the paedophile leeches in society who pay for the drug-addicted child prostitute's services.
But don't blame the beat cops who have their hands tied by society and have to see it happening every day.
It sounds like a build-tool chain problem, not an issue with the eventual binary produced for Firefox.
Why not just run the 64-bit tools on a 64-bit platform and have them output 32-bit code, the same as can be done by virtually any cross-platform compiler system. I can't imagine worrying about the fact that I can't run the builds on an outdated 32-bit OS as long as I can produce the binaries for such platforms.
I shudder to think what it would have been like to develop for some of the military communications systems I worked on for my first job if we had to run the compilers on that pathetically slow mil-spec Sperry AN-UYK system (magnetic core memory -- talk about slowing down the CPU! But it's radiation hard!) We only tested on the Sperry -- all builds and editing were done on a VAX.
In modern terms, could you imagine having to run your editors and compilers on an iDevice instead of OS/X?
See my earlier post about the Canadian Long Gun Registry database deletion.
For a much smaller database that's only cross-linked by government and law-enforcement systems, it's currently expected to take FIVE YEARS to really delete the data because of the number of archived databases that have to be restored, updated to clear the references, and re-archived. Plus the cascading effect of having to potentially update systems that reference the first level of external system references. And it only keeps spreading.
At least the government doesn't have an extensive and growing set of peer and partner external systems that would also have to be updated.
The best one can hope is that once a post is flagged as deleted, Facebook will no longer return the content data for that post to any requests for it regardless of the source, effectively nulling out all those external references with 404 errors.
I agree, it should be your choice. However, I'm one who really, really likes the idea of keeping an edit history for posts if one so chooses.
And I can understand why Facebook doesn't actually delete the data, but just flags it as hidden/deleted -- it's a real bear to update and nullify all the object id references to a post in such a mammoth system. There are links all over the place from people whose "feed" pages may reference your post. There are forwards and reposts of your post which create a commented link to your post -- does your right to delete your post mean you have the right to delete the posts of people who've commented on it?
Given that some of the content links could be in archived databases instead of mainline storage or cache, updating them could be virtually impossible.
Canada is facing the same issue with it's Long Gun Registry being shut down by Harper's Conservative government -- the data is cross-linked throughout government and law enforcement system, with over a decade of archived databases referencing the LGR databases. Truly deleting the data requires restoring the archived external databases, updating their contents to remove the references, exporting the database for an updated backup, and archiving it for storage.
Now there's the cascade effect -- any references to the archive disks now have to be updated to reference the new archive database content instead of the original.
They're currently expecting it to take over FIVE YEARS to purge that one database, and it's pitifully small compared to Facebook or Google.
Never mind the potential legal issues of external and archive systems that are mandated to be write-only by government legislation, and which have to be retained for 7-10 years in many cases.
Realistically, a versioning system or flagging content as deleted instead of purging it is the only option available for large systems that maintain historical data of any significant size.
Those are some very nice performance numbers the Facebook team achieved. Kudos. Time well invested.
One of these days I need to write a compiler for my own stuff. Re-interpreting strings a few thousand times is the next big optimization opportunity I have for my core library. Eliminating that re-parsing should garner a nice performance improvement, though I envision compiling to a set of runtime objects rather than actual bytecode or native Java source. Faster than p-Code or a non-JIT JVM, but not as fast as it could be if I went crazy optimizing things.
Care to cite even one customer of the Microsoft portfolio paying for the FAT patent? Because any vendor who pays a patent royalty for that particular patent is not defending against patent abuse, and automatically loses their right to use or distribute GPL or LGPL software. Even v2 of the licenses was very clear on this point -- you must pay to have a patent overturned if you want to use and deploy software based on the GPL family of licenses.
The one case where the patents in question were exposed to the public made no mention of the FAT patent being part of the Android patent portfolio that Microsoft is using to earn money from Android. Even Microsoft isn't about to piss off their patent customer base by "accidentally" including that patent and killing the customer's right to use Android at all.
I don't think you grasp the app store and DRM subtleties.
Because you cannot replace even an LGPL library at will with a DRM-encombered platform, the changes VLC has made do not deal with the Apple incompatibilities. They merely elevate the VLC library from a product-specific library to a shared vendor-neutral source library that anyone can use in their own media players.
Certainly VLC video player itself is still restricted from iOS deployment by the GPL covering the main product itself.
Blame Apple. The GPL beat their iOS devices to market by almost two decades, and has served the software industry as a whole rather well. While you're at it, blame Apple for blocking Java deployment to iOS devices, and for trying to abandon Java support for OS/X devices.
Apple wants a walled garden for their users. Good for them. They've locked me out, and I could care less. It just means their users will never see anything better than a web form interface, and that not for at least another year or two, while any Java/GPL compatible platform will have support in a few more weeks. I will not subject my software to the anti-freedom clauses of the Apple kool-aid company.
Software as a service. Data as a service. Maintenance as a service. Updates as a service.
Only the unimaginative can't come up with a way to make money while releasing their core code under the GPLv3. In fact, the GPLv3 makes it easier to leverage software for profit than most commercial software licenses, because it addicts the user to community to a steady update stream, something that rarely happens with .x commercial product releases.
The key is to think in terms of software and service leasing instead of product sales of a package. You're right -- you can't make significant money with GPL software if your goal is to sell a canned package.
And only someone as ill informed as you would not recognize the benefits of being able to modify code before it executes in a breakpoint debugger, and to have that modified code execute without having to rebuild and restart the debugger.
In place code editing is a Godsend regardless of whether you're getting it with Eclipse/Java or VStudio/C#/C++.
The issue is not OS/X development and deployment, but the conflict between DRM-enabled iOS applications and [L]GPLv3 license requirements that anyone be able to deploy an updated version of such software without having to obtain or pay for a DRM encryption key. As long as signing keys can't be published with the software source, you can't do a build for a DRM-encumbered platform, and are not allowed to deploy GPL-based software to such platforms at all.
Despite the bleating of those who might miss out on open source applications for iOS devices as a result, this requirement is something [L]GPL developers make a conscious decision to require for their software. If you want to blame someone, blame the owners of the DRM walled gardens on the market. They're the ones who won't allow unsigned code that would enable [L]GPL software use on those platforms.
Another point some people don't understand are the clauses of v3 of the licenses. They added language to make it explicitly illegal to "wrap" [L]GPL code in the fashion someone suggested I do for an Eclipse GUI component of my software. There is no way to hide the fact that you're relying on GPL code any more. If you do so, you have to publish the code as long as the product is being accessed directly or indirectly by customers, clients, business partners, or anyone else outside an organization -- and that includes contractors.
If the GPLv3 had not had those restrictions to prevent people from stealing my customer base by enhancing the GPL code but not sharing the enhancements, I would not have released my work as open source at all.
Funny. I could swear the summary was about Windows 8 and it's App Store, not Microsoft's general attitude on open source.
At least now I'll know why AdBlock Plus appares to "break" on it's next update, and how to fix it so it stops ALL ads again.
I know the websites make money from eyeball revenue, but I spend way too many hours of my day on the 'net to spend it inundated by advertising. Were I spending a few minutes or an hour surfing the way the general public does, I wouldn't bother blocking ads at all. But I am constantly on documentation sites and such, and even they blare the media message 24x7.
It's too distracting when you're supposed to be working. Would any company tolerate their background music provider suddenly shilling products instead of setting a work-conducive mood? How about some ads embedded in your Powerpoint presentations and company paperwork?
That's the level that "internet advertising" interferes with my ability to work if I don't use AdBlock Plus.
I'd add Azureus Vuze to that list. While it is nagware, it's also the richest content management platform I've seen on Linux or Windows systems. The Windows implementation is a bit more feature rich and responsive, but the Linux version is more stable.
Sometimes adding kitchen sink features like a video player to a download tool just add bloat and inconvenience. The Windows build of Vuze is like that -- it used to launch whatever video player you had configured under the Azureus brand. Now "Vuze" insists on launching it's own bloatware instead. Yet this was the only "new" feature added when they rebranded Azureus to Vuze that I could see -- a step backwards in providing a standard but customizable platform interface my opinion.
I dislike every product that tries to override or ignore my choice of preferred application for dealing with content of any kind.
Quite the contradiction, isn't it? I say it's the best UI I've seen for content management, and at the same time backhand them for content presentation. Still, it's true -- they've done a great job except for that one insanely annoying "feature".
If the default behaviour is to claim infringement over every non-infringing work you've published to YouTube, then I'd have to say the detection system is fraudulently broken and arbitrarily taking the side of big media.
A police officer who wrote jaywalking tickets to everyone on the street, assuming that they must have crossed from the other side illegally, would rapidly be subject to lawsuits from an outraged public and stripped of their badge. It sounds like YouTube's software does just that.
The fact that you can defend yourself against that abusive bastard's harassment in the court of the system interface does not excuse them from failing to properly train their "software officer" on the disadvantages of harassing people for not breaking the law.
If you thing open source philosophy and the GPL are against generating revenue, you need to extract your cranium from your rectal output port.
All any DRM-enabled platform has to do to solve the GPLv3 incompatability is to allow their users to install non-DRM applications within the framework. With C#/.Net or Java this is achieved by deplying unsigned DLLs, EXEs, and Jars. Where Apple falls down on GPLv3 compatibility is in mandating that you must sign the code.
I didn't see the Microsoft article clarifying their position on unsigned code distribution and installation for Windows 8. The fact that they want to allow FOSS doesn't mean that they haven't stepped in the same DRM puddle as Apple.
And you can download, compile, and distribute the source code for any non-DRM platform you choose. The GPL does not ban DRM, it merely requires that you provide all the pieces needed to build and run the software on a DRM-enabled platform, including any necessary signature keys.
However, I could see Apple not wanting those signature keys being made public. If they do that, they are not legally allowed to provide a distribution channel for GPLv3 software at all.
Personally it's no skin off my nose -- my application code is for servers, not handheld toys and video players. And even if that weren't the case, there'd be Apple's bigotry against Java in the way to start with.
Too bad, so sad, I'll never provide an iDevice interface beyond a web form. Apple made that choice, not me.
Interesting. I didn't even realize Eclipse had C++ support. But I must admit, they'd have to bring their Java development A-game features to C++ to be able to compete with Visual Studio for developing in C++. My big beef with VS is the underlying libraries which provide an insultingly bare bones implementation of ANSI and POSIX API standards rather than genuinely providing the functionality under Windows.
Let's face it -- Microsoft does not want you coding to portable standards -- they want you locking in to the Windows APIs that do implement the functionality they've crippled out of the standards-based versions.
The *AA engage in bullying, theft, "hollywood accounting", and false claims of ownership or copyright violation to generate revenue.
My God. They're greedy. Apparently the writer of this article was the last innocent who didn't realize that.
The question is not whether they're greedy pilfering thieves laying false claims, but what can be done through the courts to sue the bastards for their attempts to steal public domain content and claim it as their own. I want to see the *AA paying the government who paid for the public domain content to collect copyright violation damages at least as high as what these bastards come after individuals for.