and, let's not forget, removing the BSD license is the one thing that the license forbids -- grants you those very rights that the GPL takes away.
The BSD license can only grant rights to those portions of the file that the BSD author actually holds copyright to. If I make substantial additions to the code, then those additions fall under my copyright, and people need to comply with both your and my license if they want to distribute the code.
If you want your license to apply to additions to the code you don't hold copyright to, then you need a different license, namely one that explicitly requires new code to be put under the same license as the original code. The BSD license doesn't do that but, oddly enough, the GPL and LGPL do.
Of course you can't assert copyright either over the code.
Correct. But you can assert copyright over your derivative work, add your own copyright notice, and add your own restrictions.
The consequence of this is that you can take a piece of BSD-licensed code and make your derivative of it GPL-only once you have made any significant changes to it. You can do that because the BSD license isn't "viral" and doesn't impose any conditions on derivative works. That's the whole point of the BSD license after all.
I think that if anyone relicenced any of my OS code under their own, more restrictive (to pluck an example out of the air: GPL rather than BSD) licence, I would be incensed.
Well, then don't release it under the BSD license; the whole point of the BSD license is for people to be able to have freedom in how they relicense the code. Linux developers happen to choose to relicense it under the GPL. Technically, they shouldn't remove the BSD copyright and license, but in practice, that makes little practical difference since you're still bound by the terms of the GPL.
Only the original code remains licensed under the BSD license. The new code is licensed under the GPL, which means that you can redistribute the entire file only if you meet the conditions of both the BSD and the GPL license.
parts were BSD-ONLY and could not have the BSD license removed from them.
This is correct. However, it doesn't affect what you can do with the code: the GPL restrictions still apply to any additions, and hence to the file in its entirety (unless the changes are so minor that they don't get a separate copyright, in which case it doesn't matter anyway).
It's also highly ironic that the "Software Freedom Law Center" is fighting to restrict freedom and prevent the BSD projects from using this code.
The BSD project won't comply with the additional restrictions imposed by the GPL, so the BSD project can't use the code.
If it has to do with paths, it's in os.path. If it has to do with the OS in general, it's in OS. If it has to do with strings it's in string, and with regular expressions in re. What's so hard?
Except that that's not true. The natural thing would be for os.path.exists to be in os, not os.path, because it's an OS call, not a function that operates on paths. And why is sys.argv in sys when the argument vector is a pretty universal concept and a generic operating system service? And why is Python exception handling in sys? Or sys.exit? And why is sys.getfilesystemencoding in sys, when it is a function whose purpose is to provide a non-system-specific way of finding out system specific information?
The definitions in the Python documentation of what the modules are for are simply not helpful for deciding where to look for functions. After many years of using Python, I still feel that the functions in the libraries are often simply in the wrong modules, something I don't experience in any other language. Furthermore, whether you notice or not, it's simply a fact that beginners do have problems with this.
No, the name of the object is "stdin" because that's what UNIX and C programmers know it as. If Python renames the object to [framfeesl], then that decreases its usability.
The problem here is that you are insisting on thinking of these tools by the wrong names
No, the problem is that Python is referring to well-known objects by new, made-up names for no particularly good reason.
Unlike Usenet, there's no reliability that any of the content will be available in the current models.
I'm not sure what you're trying to say. If you're trying to say that P2P+caching is less reliable than USENET, I think you're wrong. P2P+caching is far more reliable than USENET because it does not require defined "upstream" sites, and because the only consequence of cache or node failures is a slowdown.
Guido, always the pragmatist, and having just watched Reservoir Dogs, retorted that anyone who wants a modular language should get his head examined.
So why does Python scatter its standard libraries across half a dozen packages? Probably one of the biggest problems beginners have with Python is that they can never remember whether something is in os, os.path, sys, string, re, or whether it's maybe just a method on an object, or maybe it changed in some recent release. And you can't just safely import everything from those packages either.
Guido is right that Bruce's comments are mostly not core language issues.
But that's also the problem the Python language is fine the way it is; it doesn't need any major overhaul. Before hacking away on P3K, Guido should concentrate on getting things like the UI, the standard libraries, and package management straightened out. Community contributions won't fix those; in fact, community contributions are the source of many of the problems of Python because often, there are multiple, mutually incompatible libraries and tools trying to do the same thing and stepping on each other.
Guido is doing what is fun (hacking the language) instead of what is needed (straightening out the libraries), and that's not the best choice for Python overall.
In other words, they aren't reinventing multicast poorly, they're reinventing USENET... and also poorly.
They are kind of doing what USENET is doing, but they are doing it better because, unlike USENET, caching P2P traffic requires no central management and adapts to available resources.
If cached P2P didn't naturally emerge as the distribution of choice, someone would have to invent it. It's the right thing to do.
The reason people aren't using multicast is because it doesn't work: ISPs don't support it reliably, and even if it did, it's poorly designed and doesn't address the same needs as P2P.
A better solution is for ISPs to cache P2P traffic, and that's what they are doing. That prevents the same packet from traversing the same link over and over again, without the limitations and design problems of multicast.
The first question to ask is: could Apple even handle having a larger share of the market? They'd need to expand their range of hardware, they'd need to expand support staff, they'd need add a boatload of new APIs and functionality to their OS, and on and on. Outside of Apple, there would need to be a huge infrastructure of consultants, supports staff, technical authors, and other people supporting Apple hardware and software.
And that isn't even taking into account technical issues and missing functionality in their software platform. Having a nice looking desktop user interface and being able to talk a good talk on UNIX compatibility isn't the same as having a software platform that people can use in a corporate environment.
Overall, despite all the bluster, I don't think Apple is even aiming for Microsoft's market. Apple is happy to skim off the high margin, low volume market. Right now, they can afford to say "your wallet is too small", or "we don't do that" and send customers away. If they want to compete with Microsoft, they need to meet the needs of the vast majority of users--corporate, home, and engineering--and they need to do so on price, performance, functionality, features, and compatibility, and they don't. They aren't even trying or even making the investment (Apple's R&D investment is comparatively small).
Hoping that Apple can take over the market quickly because Microsoft stumbled with Vista is wishful thinking--taking market share away from Microsoft is a slow, steady process. Apple makes it particularly hard on themselves because they have created a bottleneck by being the single hardware vendor that runs their software, and by not giving an inch on compatibility with Windows.
In other words, to paraphrase Ballmer, Microsoft could submit a ham and cheese sandwich for ratifcation, and it would be approved.
That sounds like a much better standard than OOXML, and it's much easier to implement for everybody. And if Microsoft tries to sneak bits of a 10 year old ham and cheese sandwich in there, like they did with OOXML, people will know the second they bite into it.
Photoshop is what people expect and it's what most books are written for, so that's what the Gimp should aim form primarily. Only in cases where there is a really good reason to deviate from Photoshop should the Gimp deviate.
I should say that I don't have much respect for Photoshop; I don't like the UI, and I still remember it as a toy application compared to those it replaced. Nevertheless, good or bad, like Microsoft Office, it's the de-facto standard and we'll have to live with it for the time being.
Any ideas on what causes it? I just strongly wonder if it's the same principle of trying to fight the software.
I'm using iTunes on a Mac Mini with an iPod. I'm not "fighting" it. Just about the only thing I have ever done with it is stick CDs into it to have it convert them. Lots of people seem to have the same problem, which is why there are so many tools trying to fix it.
It's not merely the applications. There are certainly some individual applications that are getting there. It's the overal system integration, the seamlessness of the OS itself (counting the windowing system as part, since any user will consider it as such), its management tools- and, more importantly, the lack of a *need* for management tools.
Oh, please spare me the sales pitch. I use a Mac daily, and it is neither "seamless" nor maintenance free, even for just running iTunes, E-mail, and web browsing.
But it's got a long way to go- and frankly, I think any of those talented programmers who looked at it objectively would agree.
Talented programmers have opinions on all sorts of things, mostly things they aren't qualified to say anything about--like user interfaces.
I'd love to see actual usability studies comparing OS X usability to that of other systems; unfortunately, I haven't been able to find any. If you know of any, please share them.
I miss the old days when the rest of you guys would get pissed off and go write your own software. Now too many people start crying as soon as somebody makes a change and stops one of your toys from working. Back in the day most of the posters in here expected their shit to not work with Linux until they figured out how to make it work with Linux. Now you're all just a bunch of crybabies!
People have done all that: they have reverse engineered everything about the iPod, created front-end applications, etc. The problem is that Apple is now breaking all that through cryptographic means. No amount of work can circumvent a correctly implemented cryptosystem.
Spectacular stock price increases are not necessarily an indication of success; in fact, they may be an indication that a company is mortgaging the future by placing short term success ahead of long term stability.
No laptop I have ever owned has gotten sleep/hibernate quite right. Even MacBooks have problems with it.
While some laptops are just broken, there are many laptops (from low end to high end) that sleep/hibernate just fine with Linux with no hacks required. In fact, quite a few laptops these days "just work" with Linux. Best thing is just boot a live distro on the machine you want to buy and try it out.
I think much of it is a control issue. Techies tend to be control freaks
I don't feel a need to control my music player when it works. Unfortunately, iTunes doesn't work. Most annoyingly, it duplicates data, but it has other data management issues as well. Don't believe me? Look around at the hundreds of AppleScripts people have written trying to fix broken behavior in iTunes.
iTunes looks great, but it doesn't scale well for anything much beyond listening to shuffled list of pop songs.
Why do you want your music files organized a certain way? The point of iTunes and such software is that you shouldn't need to care how it's organized- you should be able to focus on the task you *actually* want to accomplish: 1) Find specific music. 2) Play said music. 3) Put a subset of your music on an mp3 player. 4) Burn cds of subsets of your music.
Yes, unfortunately iTunes sucks at that. For example, sooner or later, it ends up duplicating songs. And duplicating more songs. And duplicating yet more songs. All of a sudden, when I listen to a CD I have to listen to the same song three times.
That's one of the things that has really pushed me away from Linux and toward MacOS X for everyday usage over the past years- the focus on actually getting something done rather than worrying about the stuff that I have to do first in order to subsequently get something done.
Linux and MacOS are no different in this regard. In fact, for every one of those Mac apps you like, there is a very similar Linux app--and then some.
...that Apple did it because they were stupid, not malicious.
Apple isn't stupid. You can bet that this move was carefully considered and motivated by the bottom line. I agree that they probably aren't concerned that much with locking out Linux users, but you can bet that they are concerned about free tools that access the contest of the device.
I don't know about that. Yes, there were web crawlers way back in the day. But you have to admit, Microsoft helped bring computing to the masses.
No, it didn't. There were probably a dozen actually decent operating systems and user interfaces around before Microsoft Windows. Microsoft cut lots of corners and engaged in unfair competition and killed them all. The result was that Microsoft delayed bringing modern computing to the masses for probably at least a decade. And the industry is still suffering from many of the bad choices that they made.
If you have hundreds of developers, you can afford to pick cumbersome development tools and languages and organize your code badly, and still eventually release (albeit with bugs). Like Linus does.
If you have a couple of developers, obviously, developing a million line C kernel is out of the question. If an alternative kernel is supposed to make it, its developers have to be smarter, use better tools, etc.
But the reason so few people do kernel development at all is because it's boring infrastructure; who cares what's in the kernel as long as it moves the bits from disk to memory and then to the network.
You might want to re-phrase "they are producing" [...] but my confidence level in choosing.Net for non-Windows isn't exactly helped by being pointed to their project today.
You're missing the point. The point is not whether DotGNU is a good or successful project (it's largely been eclipsed by Mono), the point is that the GNU project doesn't seem to see any problem with making an open source implementation of C# or related technologies.
Slashdot Mirror
and, let's not forget, removing the BSD license is the one thing that the license forbids -- grants you those very rights that the GPL takes away.
The BSD license can only grant rights to those portions of the file that the BSD author actually holds copyright to. If I make substantial additions to the code, then those additions fall under my copyright, and people need to comply with both your and my license if they want to distribute the code.
If you want your license to apply to additions to the code you don't hold copyright to, then you need a different license, namely one that explicitly requires new code to be put under the same license as the original code. The BSD license doesn't do that but, oddly enough, the GPL and LGPL do.
Of course you can't assert copyright either over the code.
Correct. But you can assert copyright over your derivative work, add your own copyright notice, and add your own restrictions.
The consequence of this is that you can take a piece of BSD-licensed code and make your derivative of it GPL-only once you have made any significant changes to it. You can do that because the BSD license isn't "viral" and doesn't impose any conditions on derivative works. That's the whole point of the BSD license after all.
I think that if anyone relicenced any of my OS code under their own, more restrictive (to pluck an example out of the air: GPL rather than BSD) licence, I would be incensed.
Well, then don't release it under the BSD license; the whole point of the BSD license is for people to be able to have freedom in how they relicense the code. Linux developers happen to choose to relicense it under the GPL. Technically, they shouldn't remove the BSD copyright and license, but in practice, that makes little practical difference since you're still bound by the terms of the GPL.
The code remains licensed under the BSD license.
Only the original code remains licensed under the BSD license. The new code is licensed under the GPL, which means that you can redistribute the entire file only if you meet the conditions of both the BSD and the GPL license.
parts were BSD-ONLY and could not have the BSD license removed from them.
This is correct. However, it doesn't affect what you can do with the code: the GPL restrictions still apply to any additions, and hence to the file in its entirety (unless the changes are so minor that they don't get a separate copyright, in which case it doesn't matter anyway).
It's also highly ironic that the "Software Freedom Law Center" is fighting to restrict freedom and prevent the BSD projects from using this code.
The BSD project won't comply with the additional restrictions imposed by the GPL, so the BSD project can't use the code.
If it has to do with paths, it's in os.path. If it has to do with the OS in general, it's in OS. If it has to do with strings it's in string, and with regular expressions in re. What's so hard?
Except that that's not true. The natural thing would be for os.path.exists to be in os, not os.path, because it's an OS call, not a function that operates on paths. And why is sys.argv in sys when the argument vector is a pretty universal concept and a generic operating system service? And why is Python exception handling in sys? Or sys.exit? And why is sys.getfilesystemencoding in sys, when it is a function whose purpose is to provide a non-system-specific way of finding out system specific information?
The definitions in the Python documentation of what the modules are for are simply not helpful for deciding where to look for functions. After many years of using Python, I still feel that the functions in the libraries are often simply in the wrong modules, something I don't experience in any other language. Furthermore, whether you notice or not, it's simply a fact that beginners do have problems with this.
The name of this object is [framfeesl]
No, the name of the object is "stdin" because that's what UNIX and C programmers know it as. If Python renames the object to [framfeesl], then that decreases its usability.
The problem here is that you are insisting on thinking of these tools by the wrong names
No, the problem is that Python is referring to well-known objects by new, made-up names for no particularly good reason.
Unlike Usenet, there's no reliability that any of the content will be available in the current models.
I'm not sure what you're trying to say. If you're trying to say that P2P+caching is less reliable than USENET, I think you're wrong. P2P+caching is far more reliable than USENET because it does not require defined "upstream" sites, and because the only consequence of cache or node failures is a slowdown.
Guido, always the pragmatist, and having just watched Reservoir Dogs, retorted that anyone who wants a modular language should get his head examined.
So why does Python scatter its standard libraries across half a dozen packages? Probably one of the biggest problems beginners have with Python is that they can never remember whether something is in os, os.path, sys, string, re, or whether it's maybe just a method on an object, or maybe it changed in some recent release. And you can't just safely import everything from those packages either.
Guido is right that Bruce's comments are mostly not core language issues.
But that's also the problem the Python language is fine the way it is; it doesn't need any major overhaul. Before hacking away on P3K, Guido should concentrate on getting things like the UI, the standard libraries, and package management straightened out. Community contributions won't fix those; in fact, community contributions are the source of many of the problems of Python because often, there are multiple, mutually incompatible libraries and tools trying to do the same thing and stepping on each other.
Guido is doing what is fun (hacking the language) instead of what is needed (straightening out the libraries), and that's not the best choice for Python overall.
In other words, they aren't reinventing multicast poorly, they're reinventing USENET... and also poorly.
They are kind of doing what USENET is doing, but they are doing it better because, unlike USENET, caching P2P traffic requires no central management and adapts to available resources.
If cached P2P didn't naturally emerge as the distribution of choice, someone would have to invent it. It's the right thing to do.
Microsoft invents Democracy Player and Joost, only a few years after they have been invented!
The reason people aren't using multicast is because it doesn't work: ISPs don't support it reliably, and even if it did, it's poorly designed and doesn't address the same needs as P2P.
A better solution is for ISPs to cache P2P traffic, and that's what they are doing. That prevents the same packet from traversing the same link over and over again, without the limitations and design problems of multicast.
The first question to ask is: could Apple even handle having a larger share of the market? They'd need to expand their range of hardware, they'd need to expand support staff, they'd need add a boatload of new APIs and functionality to their OS, and on and on. Outside of Apple, there would need to be a huge infrastructure of consultants, supports staff, technical authors, and other people supporting Apple hardware and software.
And that isn't even taking into account technical issues and missing functionality in their software platform. Having a nice looking desktop user interface and being able to talk a good talk on UNIX compatibility isn't the same as having a software platform that people can use in a corporate environment.
Overall, despite all the bluster, I don't think Apple is even aiming for Microsoft's market. Apple is happy to skim off the high margin, low volume market. Right now, they can afford to say "your wallet is too small", or "we don't do that" and send customers away. If they want to compete with Microsoft, they need to meet the needs of the vast majority of users--corporate, home, and engineering--and they need to do so on price, performance, functionality, features, and compatibility, and they don't. They aren't even trying or even making the investment (Apple's R&D investment is comparatively small).
Hoping that Apple can take over the market quickly because Microsoft stumbled with Vista is wishful thinking--taking market share away from Microsoft is a slow, steady process. Apple makes it particularly hard on themselves because they have created a bottleneck by being the single hardware vendor that runs their software, and by not giving an inch on compatibility with Windows.
In other words, to paraphrase Ballmer, Microsoft could submit a ham and cheese sandwich for ratifcation, and it would be approved.
That sounds like a much better standard than OOXML, and it's much easier to implement for everybody. And if Microsoft tries to sneak bits of a 10 year old ham and cheese sandwich in there, like they did with OOXML, people will know the second they bite into it.
Photoshop is what people expect and it's what most books are written for, so that's what the Gimp should aim form primarily. Only in cases where there is a really good reason to deviate from Photoshop should the Gimp deviate.
I should say that I don't have much respect for Photoshop; I don't like the UI, and I still remember it as a toy application compared to those it replaced. Nevertheless, good or bad, like Microsoft Office, it's the de-facto standard and we'll have to live with it for the time being.
Any ideas on what causes it? I just strongly wonder if it's the same principle of trying to fight the software.
I'm using iTunes on a Mac Mini with an iPod. I'm not "fighting" it. Just about the only thing I have ever done with it is stick CDs into it to have it convert them. Lots of people seem to have the same problem, which is why there are so many tools trying to fix it.
It's not merely the applications. There are certainly some individual applications that are getting there. It's the overal system integration, the seamlessness of the OS itself (counting the windowing system as part, since any user will consider it as such), its management tools- and, more importantly, the lack of a *need* for management tools.
Oh, please spare me the sales pitch. I use a Mac daily, and it is neither "seamless" nor maintenance free, even for just running iTunes, E-mail, and web browsing.
But it's got a long way to go- and frankly, I think any of those talented programmers who looked at it objectively would agree.
Talented programmers have opinions on all sorts of things, mostly things they aren't qualified to say anything about--like user interfaces.
I'd love to see actual usability studies comparing OS X usability to that of other systems; unfortunately, I haven't been able to find any. If you know of any, please share them.
I miss the old days when the rest of you guys would get pissed off and go write your own software. Now too many people start crying as soon as somebody makes a change and stops one of your toys from working. Back in the day most of the posters in here expected their shit to not work with Linux until they figured out how to make it work with Linux. Now you're all just a bunch of crybabies!
People have done all that: they have reverse engineered everything about the iPod, created front-end applications, etc. The problem is that Apple is now breaking all that through cryptographic means. No amount of work can circumvent a correctly implemented cryptosystem.
Spectacular stock price increases are not necessarily an indication of success; in fact, they may be an indication that a company is mortgaging the future by placing short term success ahead of long term stability.
No laptop I have ever owned has gotten sleep/hibernate quite right. Even MacBooks have problems with it.
While some laptops are just broken, there are many laptops (from low end to high end) that sleep/hibernate just fine with Linux with no hacks required. In fact, quite a few laptops these days "just work" with Linux. Best thing is just boot a live distro on the machine you want to buy and try it out.
I think much of it is a control issue. Techies tend to be control freaks
I don't feel a need to control my music player when it works. Unfortunately, iTunes doesn't work. Most annoyingly, it duplicates data, but it has other data management issues as well. Don't believe me? Look around at the hundreds of AppleScripts people have written trying to fix broken behavior in iTunes.
iTunes looks great, but it doesn't scale well for anything much beyond listening to shuffled list of pop songs.
Why do you want your music files organized a certain way? The point of iTunes and such software is that you shouldn't need to care how it's organized- you should be able to focus on the task you *actually* want to accomplish: 1) Find specific music. 2) Play said music. 3) Put a subset of your music on an mp3 player. 4) Burn cds of subsets of your music.
Yes, unfortunately iTunes sucks at that. For example, sooner or later, it ends up duplicating songs. And duplicating more songs. And duplicating yet more songs. All of a sudden, when I listen to a CD I have to listen to the same song three times.
That's one of the things that has really pushed me away from Linux and toward MacOS X for everyday usage over the past years- the focus on actually getting something done rather than worrying about the stuff that I have to do first in order to subsequently get something done.
Linux and MacOS are no different in this regard. In fact, for every one of those Mac apps you like, there is a very similar Linux app--and then some.
...that Apple did it because they were stupid, not malicious.
Apple isn't stupid. You can bet that this move was carefully considered and motivated by the bottom line. I agree that they probably aren't concerned that much with locking out Linux users, but you can bet that they are concerned about free tools that access the contest of the device.
I don't know about that. Yes, there were web crawlers way back in the day. But you have to admit, Microsoft helped bring computing to the masses.
No, it didn't. There were probably a dozen actually decent operating systems and user interfaces around before Microsoft Windows. Microsoft cut lots of corners and engaged in unfair competition and killed them all. The result was that Microsoft delayed bringing modern computing to the masses for probably at least a decade. And the industry is still suffering from many of the bad choices that they made.
If you have hundreds of developers, you can afford to pick cumbersome development tools and languages and organize your code badly, and still eventually release (albeit with bugs). Like Linus does.
If you have a couple of developers, obviously, developing a million line C kernel is out of the question. If an alternative kernel is supposed to make it, its developers have to be smarter, use better tools, etc.
But the reason so few people do kernel development at all is because it's boring infrastructure; who cares what's in the kernel as long as it moves the bits from disk to memory and then to the network.
You might want to re-phrase "they are producing" [...] but my confidence level in choosing .Net for non-Windows isn't exactly helped by being pointed to their project today.
You're missing the point. The point is not whether DotGNU is a good or successful project (it's largely been eclipsed by Mono), the point is that the GNU project doesn't seem to see any problem with making an open source implementation of C# or related technologies.