I'm looking at http://www.winehq.org/history which I assume you're hopefully going to agree, is likely a reliable source.
It's very incomplete. Part of the story is how the WineX developers and such promised that they would contribute work on DX to Wine, which is discussed in detail on the mailing lists. This lead to a huge amount of developer stagnation in the area as everyone was just waiting on the "patches" that would bring all this new functionality.
Years pass and it ends up becoming obvious that the WineX/cedega developers had no intention of keeping their promise despite their continuous reassurances, thus causing a huge amount of stagnation in development in Wine's development in the Direct X area, during this time a lot of the developers felt that this was a catalyst that should push the licensing changes to prevent something like this (and other events noted in Wine's history) from ever happening again, where it took them more years to get where they are today which, in many ways, is still lacking compared to Cedega who had a large head start due to deceiving the WineHQ people who are still playing catch up.
A lot of these events are not documented on the website and other places except in discussions on the WineHQ mailing lists as it doesn't help very much with a 'professional' image of Wine by ranting on about all the booboos Wine had.
Had Wine been licensed the way it is today, quite a few negative incidents could have been avoided and Wine would have been better off today.
I've tried searching for mailing list entries, but there doesn't seem to be a lot of stuff out there, at least that Google is showing up.
It's all there, I just don't want to spend a few hours looking through the archives, but I'm sure there are those on Slashdot that do 'obsess' enough over this to do so.
First: He naturally has copyright on his fix. Not on your code. And that is true regardless of the license. He has the same copyright if the product is GPL licensed.
You're avoiding the fact that he can set a license that prevents people from using it without purchasing a license to that specific guy's software and using it with that guy's release.
Second: Why can none of my users fix the bug? What makes the other person so special?
Checkout why Wine moved from BSD to GPL.
Third: I still have the code. Why can't I expand and improve that?
See what happened above.
- A serious bug is discovered in your service application which is distributed under GPL.
- Somebody makes a fix AND COPYRIGHTS THAT FIX.
- You can't import import the fix to YOUR version because they guy isn't releasing the source. He is not forced to because he doesn't distribute the code. He just makes loads of money by offering a better service than your product.
In terms of non-GPL licensed code for you to use, the BSDs are free for the taking, and with the BSD license, you get to decide how much of your modifications (if any) you release. Their code quality is nearly always better than Linux anywayz.
BSD cannot be trusted to be completely 'free' as the person above claims. I have come across numerous BSD licensed sourcecode that has the following clause:
3. All advertising materials mentioning features or use of this software
must display the following acknowledgement:
This product includes software developed by Insert company/person/organisation here
I will also add that this clause is incompatible with GPL.
Re:Why I'm dropping endorsement/etc of Lulu
on
Lulu Introduces DRM
·
· Score: 1
In the case of Lulu the blog article was clearly encouraging authors to put DRM on their content, making false (but common) claims that DRM would reduce infringement.
Where is the evidence for this?
I mean, I can think of example where things like "x3: reunion" piracy was reduced to barely anything as the only way people could get it to work was to use virtualization disc software and physically disconnect all their optical drives to get it start thanks to DRM. However, when Egosoft removed the DRM (like they do on all their products after a year), there was a huge increase in piracy usage of the software and spread quickly throughout pirate sites. The DRM was not fracked. "x3: terran conflict" came out and while there was images of the disc, the DRM was never cracked and pirates couldn't get it to run until Egosoft removed the DRM.
I can also think of examples where DRM failed quite miserably, such as with EA and their "Spore" to a great extent, but amusingly enough. It did stop average joe who did get the game legitimately from copying it and giving it to a friend still. I disagree with your belief that DRM would not reduce some infringements.
Note: Philosophically, I am against DRM but I'm not going to make up lies to push my philosophy.
Note: Most large CDNs are setup to use anycast, from Akamai to Google - although Akamai makes use of also DNS geolocation in certain instances.
And you'd be completely, utterly wrong.
...
I've seen anycast resulting some mind-numblingly stupid site selection choices, usually due to a local ISP's BGP policy - and when I say "stupid" I mean "all users of ISP X in New York City getting sent to a mirror in Sydney, Australia instead of the site downtown".
So, a configuration error from one ISP makes it completely, utterly wrong for every single person everywhere and these sort of errors are less likely to occur with DNS geolocation which work based on the resolver's geo ip location (note that international ISPs like Roadrunner, Virgin, AOL have the same DNS entries with transparent caching setups at various points) rather than what is most of the time, correctly configured network peering?
For what it's worth, most people are playing Borderlands online now using GameRanger for exactly this reason, because it eliminates all these problems. Gearbox has unofficially recommended it as a solution as well.
Nobody I play with even heard of gameranger. So, we tried it. Guess what - It didn't help the Borderland's online mode work.
including multiple complete versions of the Emacs.el and.elc files and so forth
It's not that hard to do file links, honest.
This isn't such a PITA if you're compiling everything from source because you have to compile it on all those multiple platforms anyhow, but if you're talking about commercial software (gasp! The horror!) you're talking about multiple times the administrative overhead to keep the software up-to-date and functional.
Yes, in which case I prefer seperate, segregated paths for each architecture because you end up with one platform having adobe flash and the other having Gnash, or you'll need a extremely custom setup to get an 32bit-only application working correctly in a 64bit environment (and by custom, I don't mean just installing the 32bit libraries, but stupid issues with things like running into stuff that wants m86_old() and requires modifications all across the system to get working - I have ran into this) etc.
you're talking about multiple times the administrative overhead to keep the software up-to-date and functional.
Running two "sudo apt-get install" processes simultaneously is not hard, linking various configuration paths between the 32bit and 64bit setups is dead simple.
Now, dealing with a system where both 32bit and 64bit binaries are one and you need to make special customizing for one is going to be more difficult and annoying.
we're not talking about a huge gain with fat binaries but it does solve a real problem and it's sad that it was rejected as simply "not invented here" by people who have no (zero) clue of real-life IT, as vs. having a reasoned discussion of advantages and disadvantages.
I'm sure it has it's uses, but in my opinion, it produces more work with networked installations.
Except if you want to let 64-bit machines run natively but still support 32-bit machines... then you have to maintain two separate file shares. FatELF would have let you keep it all synchronized on one share.
I can't really think of an issue with two separate fileshares. For the most part everything is identical in setup and commands, running the command "sudo apt-get install" is the same for both and I can set certain architecture specific settings when needed.
But, let's consider your idea. So what happens when I need to add support for 128bit x86 or arm etc? I have to replace every single binary? Some proprietary ones may not even exist in that architecture at all and in which case I need to set it up to work with other things. Like using Gnash instead of Adobe Flash (which conflict with each other when installed together).
As a sysadmin, I find it a lot easier to maintain separate paths in a network fileshare for different architectures due to architecture specific issues, software requirements etc. Using FAT binaries would complicate the issue immensely for me as not every single piece of software, library is going to be available for every architecture. Some software is even written in such a way that it makes it extremely difficult to port over to other architectures (see the issues the Linux developers had getting 64bit working for the majority of applications and libraries initially) - so this is to be expected.
Sometimes I think that user forums and developer forums should be one and the same---that developers should be forced to see the user flame wards---that by exposing them to this without the option to get rid of it, they will be inspired to actually write software that is easier to configure and use.
I'm reminded of the time I looked in a mailing list archive for developers and saw a user who joined and got very mad about the nightly build messages, tonnes of debugging code on the list. For about a month, he kept asking people to remove him from the list with "please remove me!!!!", constantly replying to every thread to remove him. Nobody replied to him ever. I think the devs marked his message as spam locally on their systems and never saw him again.
Slashdot Mirror
That's because they don't ban accounts, just the hardware for modifications.
No they aren't. They made a contract, the consumer agreed to the contract. The consumer violated it and got banned.
It is the correct way to do things. If you don't like it, don't buy it. Simple.
Then don't buy it.
I already did drop a few paragraphs on this else where on this article.
No.
It's very incomplete. Part of the story is how the WineX developers and such promised that they would contribute work on DX to Wine, which is discussed in detail on the mailing lists. This lead to a huge amount of developer stagnation in the area as everyone was just waiting on the "patches" that would bring all this new functionality.
Years pass and it ends up becoming obvious that the WineX/cedega developers had no intention of keeping their promise despite their continuous reassurances, thus causing a huge amount of stagnation in development in Wine's development in the Direct X area, during this time a lot of the developers felt that this was a catalyst that should push the licensing changes to prevent something like this (and other events noted in Wine's history) from ever happening again, where it took them more years to get where they are today which, in many ways, is still lacking compared to Cedega who had a large head start due to deceiving the WineHQ people who are still playing catch up.
A lot of these events are not documented on the website and other places except in discussions on the WineHQ mailing lists as it doesn't help very much with a 'professional' image of Wine by ranting on about all the booboos Wine had.
Had Wine been licensed the way it is today, quite a few negative incidents could have been avoided and Wine would have been better off today.
It's all there, I just don't want to spend a few hours looking through the archives, but I'm sure there are those on Slashdot that do 'obsess' enough over this to do so.
It was a lot more than that. You have failed to do your research. I suggest looking at the Wine mailing list archives.
Nope. Try a more reliable source like the Wine mailing lists.
Fix: Confused BSD with MIT above. Wine also uses LGPL for various components.
Note: I am not the grandfather poster.
You're avoiding the fact that he can set a license that prevents people from using it without purchasing a license to that specific guy's software and using it with that guy's release.
Checkout why Wine moved from BSD to GPL.
See what happened above.
Should have licensed that under AGPL then, no?
Note: I am not the grandfather poster.
Compared to some of Microsoft's Microsoft Shared Source Initiative licenses which enforce that the software remain non-commercial and opensource?
Sorry, I don't buy it.
BSD cannot be trusted to be completely 'free' as the person above claims. I have come across numerous BSD licensed sourcecode that has the following clause:
I will also add that this clause is incompatible with GPL.
Where is the evidence for this?
I mean, I can think of example where things like "x3: reunion" piracy was reduced to barely anything as the only way people could get it to work was to use virtualization disc software and physically disconnect all their optical drives to get it start thanks to DRM. However, when Egosoft removed the DRM (like they do on all their products after a year), there was a huge increase in piracy usage of the software and spread quickly throughout pirate sites. The DRM was not fracked. "x3: terran conflict" came out and while there was images of the disc, the DRM was never cracked and pirates couldn't get it to run until Egosoft removed the DRM.
I can also think of examples where DRM failed quite miserably, such as with EA and their "Spore" to a great extent, but amusingly enough. It did stop average joe who did get the game legitimately from copying it and giving it to a friend still. I disagree with your belief that DRM would not reduce some infringements.
Note: Philosophically, I am against DRM but I'm not going to make up lies to push my philosophy.
Which cannot legally apply to me, where I live either.
Yes!
For one, Google is using it right now to serve HTTP content to a lot of providers out there.
Also, even smaller non-commercial entities like the IRC network Dalnet are using anycast in a TCP based setup.
Note: Most large CDNs are setup to use anycast, from Akamai to Google - although Akamai makes use of also DNS geolocation in certain instances.
...
So, a configuration error from one ISP makes it completely, utterly wrong for every single person everywhere and these sort of errors are less likely to occur with DNS geolocation which work based on the resolver's geo ip location (note that international ISPs like Roadrunner, Virgin, AOL have the same DNS entries with transparent caching setups at various points) rather than what is most of the time, correctly configured network peering?
You're funny, can I subscribe to your newsletter?
*shakes fist* Damn you spell checker! Made me look like a 'tard.
Usually free by most IXPs, provided you have a link to them, but also datacenter providers can usually forward on requests to do this too.
No idea, I've never had others handle my hardware in these situations.
For the anycast, it isn't.
Nope.
Uh... The whole point of anycast is that you have multiple datecenters in various locations around the world.
I suspect anycast would be a better method, honestly.
It's completely legal where I live to disassemble and reverse engineer software, could be for the author too.
Yes.
I don't think you would win however.
Nobody I play with even heard of gameranger. So, we tried it. Guess what - It didn't help the Borderland's online mode work.
There was a real choice of FOSS toolkits back then?
It's not that hard to do file links, honest.
Yes, in which case I prefer seperate, segregated paths for each architecture because you end up with one platform having adobe flash and the other having Gnash, or you'll need a extremely custom setup to get an 32bit-only application working correctly in a 64bit environment (and by custom, I don't mean just installing the 32bit libraries, but stupid issues with things like running into stuff that wants m86_old() and requires modifications all across the system to get working - I have ran into this) etc.
Running two "sudo apt-get install" processes simultaneously is not hard, linking various configuration paths between the 32bit and 64bit setups is dead simple.
Now, dealing with a system where both 32bit and 64bit binaries are one and you need to make special customizing for one is going to be more difficult and annoying.
I'm sure it has it's uses, but in my opinion, it produces more work with networked installations.
I can't really think of an issue with two separate fileshares. For the most part everything is identical in setup and commands, running the command "sudo apt-get install" is the same for both and I can set certain architecture specific settings when needed.
But, let's consider your idea. So what happens when I need to add support for 128bit x86 or arm etc? I have to replace every single binary? Some proprietary ones may not even exist in that architecture at all and in which case I need to set it up to work with other things. Like using Gnash instead of Adobe Flash (which conflict with each other when installed together).
As a sysadmin, I find it a lot easier to maintain separate paths in a network fileshare for different architectures due to architecture specific issues, software requirements etc. Using FAT binaries would complicate the issue immensely for me as not every single piece of software, library is going to be available for every architecture. Some software is even written in such a way that it makes it extremely difficult to port over to other architectures (see the issues the Linux developers had getting 64bit working for the majority of applications and libraries initially) - so this is to be expected.
I'm reminded of the time I looked in a mailing list archive for developers and saw a user who joined and got very mad about the nightly build messages, tonnes of debugging code on the list. For about a month, he kept asking people to remove him from the list with "please remove me!!!!", constantly replying to every thread to remove him. Nobody replied to him ever. I think the devs marked his message as spam locally on their systems and never saw him again.