In Germany you have 14 days in which you can return anything you bought online. In addition to that any offering that didn't make it obvious that you have to pay for it is void to begin with, having a 'please pay us 98 EUR' somewhere hidden deep in the fine print isn't a valid contract.
No, your app is not a derivative work of the library.
Your app *is* a derivate work of the library, at least when you distribute binaries and are using C or C++. The reason why the GPL works the way it does for libraries is because how C works. In C using a library starts with "#include ", that statement doesn't just say that you are going use the library as in some dynamic languages, but it copies parts of the library straight into your source code. In some cases of course not much is copied or none at all, while in other cases the whole thing is copied (C++ template based stuff). If this wouldn't happen the GPL really could do very little against using it in a proprietary app. Even the FSF itself argues that you can't or at least shouldn't be able to copyright a pure API, which is one of the reasons why using a GPL tool via exec() is perfectly fine.
If the GPL has one big flaw its really the weirdness that it based around C-like, instead of having a more meaningful way to being applied to all software.
The flightsim EF2000 was kind of like that. You had a complete dynamic war running, on each round you selected a mission you want to fly and then flow your mission. If you died, you died, no retry, the plane and pilot lost. But since there where plenty of other planes and pilots you could continue the war for quite a while. Of course when you messed up to bad and to many planes and airfields have been lost, the war was lost and game over. What made the thing really interesting was that the whole dynamic campaign was running all the time, so whenever you flew a mission you always had lots of other activity going on that had nothing to do with your mission. To bad that almost 15 years only a tiny few games have followed into those footsteps.
The game also had a sequel which did a different take on the topic, instead of being able to select your mission each round, the game gave you five pilots between which you could switch at any time, if any of them got shot down and ejected they could get captured or end up in a hospital, so it took a while till they where back into action. If they died, they where dead permanently. The game was pretty flawed in many other aspects, but it was quite an interesting way to handle the whole dieing in a flightsim.
Except of course that making copy&paste hard is doing the exact inverse of that philosophy, since it makes refactoring code hard, you no longer can move code around, slap a function name on top and be sure it will work afterwards, in Python you have to be extremely careful not to break any whitespace or the code might break in very non-obvious ways.
The problem with whitespace is that it breaks code. Take a snipped of code copy it and paste it into a different indention level. In a block oriented language the code will continue to work exactly as intended and at no point will the code be invalid. In Python on the other side the code breaks as soon as you paste and you have to move that broken code back into usable form manually. Now a proper editor can help with that, but it won't stop Python code from temporarily break.
Thats Python is extremely lax with the whitespace of course just makes this problem worse.
And of course that isn't just theoretical, one of the worst coding experience I had in any language ever was refactoring a piece of Python code, since the old way to work of just copying stuff around, adding function names to it and then hitting auto-indent completly broke and I ended up constantly fixing white space and being extremely careful with my copy&paste, since the code constantly broke after every second operation.
Can someone tell me why it was changed to print()? Philosophical reason or pragmatic?
One reason for the change is simply that a language should be consistent and with print() it becomes that, since it turns print() into a usual function. The old print statement on the other side was pure magic, stuff build into the syntax of the language that is different from any normal function for no good reason. And that kind of magic is something you want to reduce to a minimum, since its ugly and just makes your language look weird.
On a more practical point of view, you can now write:
a = print a("Hello World")
Which you couldn't before, since as said, print used to be magic.
You are answering the easy question, while skipping the interesting one. There is no doubt that video games don't have a direct link to violence, if they would it would show up in the statistic. This has been know for a long long time by everyone who isn't a lunatic 'think of the children'-type politician.
However that doesn't mean video games don't have some effect and it would be much more interesting to dive into that area.
For example what about indirect violence, like say for example the acceptance of the war in Irak? Video games are notoriously bad at displaying a realistic environments, instead they portrait an idealistic ones. There is just you and the bad guy, no civilians, quite often you can't even have friendly fire incidence, because the game doesn't allow them. Does this fact changes the way people view war? Does it make war be associated with something positive, i.e. fun, instead of with something negative?
Now that is of course just one example and it might not even be a good one, since military propaganda and bad news reporting likely to far more harm in that area then video games. But I would find it much more interesting to analyze the effects video games have in a broader sense then just that single tired direct "video games lead to violence" thing.
The main advantage of git over subversion for such uses is that git doesn't require a seperate repository, the repository sits right there in the.git/ directory in your projects directory. Doesn't sound like much, but its great convenience factor, since all you have to do to start using git is type 'git init' and you are done, you don't need to create a repository, you don't need to important your existing files and most importantly you can leave your working directory as is. With SVN this same process can get quite annoying, since you basically have to delete your working direcotry and replace it with a SVN checkout and then verify that all your files actually made it into the repository. With git its a single command and you don't have to think about anything, so its much easier and you can just version control any directory you like.
Problem two *is* a problem with git, it has nothing to do with how you organize a project, since you can never guess what a user might want. Simple example: I would like to look at the latest version of a file in the linux kernel, with git I have to download the whole beast when all I want is a single file, which is neither pretty nor fast.
DVCS is in concept always better then centralized VCS, since it offers all the same features plus a lot more. However there are things that git handles pretty badly. Binary files are such a thing, you really wouldn't want to keep large binary files in git, since git forces you to download all the history of them, unlike SVN which allows you to only download the latest version. Another thing missing from git is a way to checkout just a single directory or file, when I am just interested in the latest version of a single kernel module its kind of annoying being forced to download the whole kernel source tree.
- no of partial cloning, so a big history means lots of stuff to download, this is especially bad when it comes to binary files - no way to download just a single file or directory, a user always has to clone the whole repository
There are several documented ways to run Linux apps in Sugar.
There are ways to run Linux applications by *bypassing* Sugar, there currently are no ways to run them properly from within Sugar itself or to interact with them properly, since Sugar doesn't support a classic file system. Sugar is a desktop environment that does everything it can to make it hard to run normal applications.
Its good to hear that they are trying to fix that now, but its again a case of "to little, to late", this is something that should have been thought of right from the start. The whole goal to have everything as a proper Sugar app was nice, but just unrealistic. Even those apps that are 'proper' Sugar apps, are quite frequently just wrapped classic Linux applications, that bypass a lot of what Sugar does (eToys, Squeak, etc.).
Oh, and of course the mess works the other way around too, running Sugar applications in a normal Linux system isn't exactly pretty either.
And Hamas won't stop A before Israel stops B. Guess what, thats the circle of violence and B is part of the problem, not of the solution, its that simple.
What you forget is that a casual game is much cheaper to produce and might easily sell more. A hardcore game isn't very attractive target, when the target audience is in a completly different direction. Also most hardcore developers like to push boundaries, with the Wii it would be quite a step back on the technical side.
You should test Metroid Prime for Wii. It clearly shows that FPS games are possible for Wii.
For me Metroid Prime 3 on the Wii showed the exact opposite. It near impossible to hit anything in that game if you don't use lock-on. The whole concept of having aiming and character rotation on the same control feels pretty broken and lock-on is the only thing that makes that game playable. Now that doesn't mean an FPS is completly impossible, it would be interesting to see a game would work where the Wiimote is used for aiming exclusivly and rotation is done by the analogstick. But as is the Wiimote is far far away from being a decent FPS control.
Fight the ground that terrorists grow? What the fuck is that supposed to mean?
Not killing civilians. The whole issue is that Hamas has the sympathy of the people because of what Israel does, if Israel would oppress and kill Palestina people on a regular basis Hamas would have very little ground to stand on. You seem to have a problem understanding that in a cycle of violence there isn't a single guilty party, the action of party A are directly caused by party B and vice a versa. If you retaliate after every problem you can continue that cycle for a long long time.
The civilian death rate has been less then 25% to date.
They have killed around five times more civilians with their "cleanup" then Hamas killed with their rockets. Thats not low, thats sky high. And thats not even considering that not every middle aged man that got killed is a Hamas terrorist and that it isn't ok to kill Hamas terrorist without trial.
If you want to do something, they could have installed some Phalanx anti-missile units.
I fully agree that the OLPC is a nice piece of hardware, but how in the hell can one 'give it a chance' when it never ever entered the market place? In the USA you only could buy it time limited for double the price, which was already pretty bad, but in Europe you never ever could buy an OLPC. The by far biggest failure of OLPC is that they never actually sold those things properly. Hard to win if you are not even part of the race. And all this it didn't exactly create trust in the project, since well, if its so great, why don't they actually sell it to first world countries?
If you use multiple browser or computers you just copy the key around. If you use a public terminal you would likely use a fallback mechanism, such as a webservice that handles the keys for you, which would give you something similar to OpenId or just register additional username/password stuff for the webpages you visit via public terminals. In a perfect world of course you would have a cryptographic device on your keychain that you then insert into the USB port that handles the encryption for you without the key ever leaving that device.
or would you trust each and every website NOT to be written by a PHP-Noob storing your password in a plaintext file?
I use random passwords, no harm done when stuff is stored in plaintext, but yes, thats not an ideal solution either, I am not claiming that username/password is good, just that OpenId really isn't any better. The point is simply that I don't want a third party involved, there simply is no need for it, public key cryptography offers the tools to implemented such a system without giving a third party access to all the webpages you use.
What are you going to do if I attemp to break in your house and kill you family?
Following your argumentation I should bomb the house of the criminal, kill 10 of his neighbors that had nothing to do with this and call it self defense. Oh, and the criminal isn't even breaking into your house murdering your family, he his throwing rocks over your high fence.
As said, police work and negotiations are the answer, not killing more civilians. The goal should be to break out of this cycle of violence, not to do everything to repeat it. And yeah, that might mean to just suck it up when some terror attack happens, because what you want to fight is the ground on which terrorists grow.
OpenId doesn't force you to have all eggs in one basket, you could still have multiple OpenIds if you like. What OpenId however does is putting all the eggs into somebody else basket. OpenId requires that you bring in a third party between you and the webpage you want to login, which is stupid. With username/password and password reminder mails you have a similar problem, in that you must trust your mail provider, but its harder to automate.
Anyway, a scheme that wants to fix username/password should be one that is more secure and easier to use then what we already have, not less secure and harder to understand, OpenId however fails at both.
The only way I could see OpenId to be useful is if it would get integrated into the webbrowser, so that your webbrowser becomes the OpenId provider without the user doing any extra work.
Slashdot Mirror
If you would be up front about it, you wouldn't have any customers, since they would just go the the original page which you of coursed linked to.
In Germany you have 14 days in which you can return anything you bought online. In addition to that any offering that didn't make it obvious that you have to pay for it is void to begin with, having a 'please pay us 98 EUR' somewhere hidden deep in the fine print isn't a valid contract.
No, your app is not a derivative work of the library.
Your app *is* a derivate work of the library, at least when you distribute binaries and are using C or C++. The reason why the GPL works the way it does for libraries is because how C works. In C using a library starts with "#include ", that statement doesn't just say that you are going use the library as in some dynamic languages, but it copies parts of the library straight into your source code. In some cases of course not much is copied or none at all, while in other cases the whole thing is copied (C++ template based stuff). If this wouldn't happen the GPL really could do very little against using it in a proprietary app. Even the FSF itself argues that you can't or at least shouldn't be able to copyright a pure API, which is one of the reasons why using a GPL tool via exec() is perfectly fine.
If the GPL has one big flaw its really the weirdness that it based around C-like, instead of having a more meaningful way to being applied to all software.
They are pretty useful items to have if you live out in the country and need them to protect livestock or yourself if you live in bear country.
Very true, but in large parts of the civilized world 'dangerous wildlife' is something you look at in the zoo, not something you meet in the wild.
Plus target shooting of course.
Why would you need a real deadly gun for that? A pointer laser and a blank would give you quite the same sporting experience with much less dangers.
The flightsim EF2000 was kind of like that. You had a complete dynamic war running, on each round you selected a mission you want to fly and then flow your mission. If you died, you died, no retry, the plane and pilot lost. But since there where plenty of other planes and pilots you could continue the war for quite a while. Of course when you messed up to bad and to many planes and airfields have been lost, the war was lost and game over. What made the thing really interesting was that the whole dynamic campaign was running all the time, so whenever you flew a mission you always had lots of other activity going on that had nothing to do with your mission. To bad that almost 15 years only a tiny few games have followed into those footsteps.
The game also had a sequel which did a different take on the topic, instead of being able to select your mission each round, the game gave you five pilots between which you could switch at any time, if any of them got shot down and ejected they could get captured or end up in a hospital, so it took a while till they where back into action. If they died, they where dead permanently. The game was pretty flawed in many other aspects, but it was quite an interesting way to handle the whole dieing in a flightsim.
Except of course that making copy&paste hard is doing the exact inverse of that philosophy, since it makes refactoring code hard, you no longer can move code around, slap a function name on top and be sure it will work afterwards, in Python you have to be extremely careful not to break any whitespace or the code might break in very non-obvious ways.
The problem with whitespace is that it breaks code. Take a snipped of code copy it and paste it into a different indention level. In a block oriented language the code will continue to work exactly as intended and at no point will the code be invalid. In Python on the other side the code breaks as soon as you paste and you have to move that broken code back into usable form manually. Now a proper editor can help with that, but it won't stop Python code from temporarily break.
Thats Python is extremely lax with the whitespace of course just makes this problem worse.
And of course that isn't just theoretical, one of the worst coding experience I had in any language ever was refactoring a piece of Python code, since the old way to work of just copying stuff around, adding function names to it and then hitting auto-indent completly broke and I ended up constantly fixing white space and being extremely careful with my copy&paste, since the code constantly broke after every second operation.
Can someone tell me why it was changed to print()? Philosophical reason or pragmatic?
One reason for the change is simply that a language should be consistent and with print() it becomes that, since it turns print() into a usual function. The old print statement on the other side was pure magic, stuff build into the syntax of the language that is different from any normal function for no good reason. And that kind of magic is something you want to reduce to a minimum, since its ugly and just makes your language look weird.
On a more practical point of view, you can now write:
a = print
a("Hello World")
Which you couldn't before, since as said, print used to be magic.
You are answering the easy question, while skipping the interesting one. There is no doubt that video games don't have a direct link to violence, if they would it would show up in the statistic. This has been know for a long long time by everyone who isn't a lunatic 'think of the children'-type politician.
However that doesn't mean video games don't have some effect and it would be much more interesting to dive into that area.
For example what about indirect violence, like say for example the acceptance of the war in Irak? Video games are notoriously bad at displaying a realistic environments, instead they portrait an idealistic ones. There is just you and the bad guy, no civilians, quite often you can't even have friendly fire incidence, because the game doesn't allow them. Does this fact changes the way people view war? Does it make war be associated with something positive, i.e. fun, instead of with something negative?
Now that is of course just one example and it might not even be a good one, since military propaganda and bad news reporting likely to far more harm in that area then video games. But I would find it much more interesting to analyze the effects video games have in a broader sense then just that single tired direct "video games lead to violence" thing.
The main advantage of git over subversion for such uses is that git doesn't require a seperate repository, the repository sits right there in the .git/ directory in your projects directory. Doesn't sound like much, but its great convenience factor, since all you have to do to start using git is type 'git init' and you are done, you don't need to create a repository, you don't need to important your existing files and most importantly you can leave your working directory as is. With SVN this same process can get quite annoying, since you basically have to delete your working direcotry and replace it with a SVN checkout and then verify that all your files actually made it into the repository. With git its a single command and you don't have to think about anything, so its much easier and you can just version control any directory you like.
Problem two *is* a problem with git, it has nothing to do with how you organize a project, since you can never guess what a user might want. Simple example: I would like to look at the latest version of a file in the linux kernel, with git I have to download the whole beast when all I want is a single file, which is neither pretty nor fast.
DVCS is in concept always better then centralized VCS, since it offers all the same features plus a lot more. However there are things that git handles pretty badly. Binary files are such a thing, you really wouldn't want to keep large binary files in git, since git forces you to download all the history of them, unlike SVN which allows you to only download the latest version. Another thing missing from git is a way to checkout just a single directory or file, when I am just interested in the latest version of a single kernel module its kind of annoying being forced to download the whole kernel source tree.
Some things git is bad at:
- no of partial cloning, so a big history means lots of stuff to download, this is especially bad when it comes to binary files
- no way to download just a single file or directory, a user always has to clone the whole repository
There are several documented ways to run Linux apps in Sugar.
There are ways to run Linux applications by *bypassing* Sugar, there currently are no ways to run them properly from within Sugar itself or to interact with them properly, since Sugar doesn't support a classic file system. Sugar is a desktop environment that does everything it can to make it hard to run normal applications.
Its good to hear that they are trying to fix that now, but its again a case of "to little, to late", this is something that should have been thought of right from the start. The whole goal to have everything as a proper Sugar app was nice, but just unrealistic. Even those apps that are 'proper' Sugar apps, are quite frequently just wrapped classic Linux applications, that bypass a lot of what Sugar does (eToys, Squeak, etc.).
Oh, and of course the mess works the other way around too, running Sugar applications in a normal Linux system isn't exactly pretty either.
Israel won't stop B until Hamas stop's A.
And Hamas won't stop A before Israel stops B. Guess what, thats the circle of violence and B is part of the problem, not of the solution, its that simple.
What you forget is that a casual game is much cheaper to produce and might easily sell more. A hardcore game isn't very attractive target, when the target audience is in a completly different direction. Also most hardcore developers like to push boundaries, with the Wii it would be quite a step back on the technical side.
You should test Metroid Prime for Wii. It clearly shows that FPS games are possible for Wii.
For me Metroid Prime 3 on the Wii showed the exact opposite. It near impossible to hit anything in that game if you don't use lock-on. The whole concept of having aiming and character rotation on the same control feels pretty broken and lock-on is the only thing that makes that game playable. Now that doesn't mean an FPS is completly impossible, it would be interesting to see a game would work where the Wiimote is used for aiming exclusivly and rotation is done by the analogstick. But as is the Wiimote is far far away from being a decent FPS control.
Fight the ground that terrorists grow? What the fuck is that supposed to mean?
Not killing civilians. The whole issue is that Hamas has the sympathy of the people because of what Israel does, if Israel would oppress and kill Palestina people on a regular basis Hamas would have very little ground to stand on. You seem to have a problem understanding that in a cycle of violence there isn't a single guilty party, the action of party A are directly caused by party B and vice a versa. If you retaliate after every problem you can continue that cycle for a long long time.
The civilian death rate has been less then 25% to date.
They have killed around five times more civilians with their "cleanup" then Hamas killed with their rockets. Thats not low, thats sky high. And thats not even considering that not every middle aged man that got killed is a Hamas terrorist and that it isn't ok to kill Hamas terrorist without trial.
If you want to do something, they could have installed some Phalanx anti-missile units.
Correct me if I am wrong, but didn't the standard came *after* the HDD manufactures used to abuse the 1000/1024 for their benefit?
I fully agree that the OLPC is a nice piece of hardware, but how in the hell can one 'give it a chance' when it never ever entered the market place? In the USA you only could buy it time limited for double the price, which was already pretty bad, but in Europe you never ever could buy an OLPC. The by far biggest failure of OLPC is that they never actually sold those things properly. Hard to win if you are not even part of the race. And all this it didn't exactly create trust in the project, since well, if its so great, why don't they actually sell it to first world countries?
If you use multiple browser or computers you just copy the key around. If you use a public terminal you would likely use a fallback mechanism, such as a webservice that handles the keys for you, which would give you something similar to OpenId or just register additional username/password stuff for the webpages you visit via public terminals. In a perfect world of course you would have a cryptographic device on your keychain that you then insert into the USB port that handles the encryption for you without the key ever leaving that device.
or would you trust each and every website NOT to be written by a PHP-Noob storing your password in a plaintext file?
I use random passwords, no harm done when stuff is stored in plaintext, but yes, thats not an ideal solution either, I am not claiming that username/password is good, just that OpenId really isn't any better. The point is simply that I don't want a third party involved, there simply is no need for it, public key cryptography offers the tools to implemented such a system without giving a third party access to all the webpages you use.
What are you going to do if I attemp to break in your house and kill you family?
Following your argumentation I should bomb the house of the criminal, kill 10 of his neighbors that had nothing to do with this and call it self defense. Oh, and the criminal isn't even breaking into your house murdering your family, he his throwing rocks over your high fence.
As said, police work and negotiations are the answer, not killing more civilians. The goal should be to break out of this cycle of violence, not to do everything to repeat it. And yeah, that might mean to just suck it up when some terror attack happens, because what you want to fight is the ground on which terrorists grow.
OpenId doesn't force you to have all eggs in one basket, you could still have multiple OpenIds if you like. What OpenId however does is putting all the eggs into somebody else basket. OpenId requires that you bring in a third party between you and the webpage you want to login, which is stupid. With username/password and password reminder mails you have a similar problem, in that you must trust your mail provider, but its harder to automate.
Anyway, a scheme that wants to fix username/password should be one that is more secure and easier to use then what we already have, not less secure and harder to understand, OpenId however fails at both.
The only way I could see OpenId to be useful is if it would get integrated into the webbrowser, so that your webbrowser becomes the OpenId provider without the user doing any extra work.
SSH basically already does what I would like to see used in webpages, doesn't seem to be much of an inconvenience there, quite the opposite actually.