Even one process freeing memory does return it to the OS. If it didn't, what would be the point of freeing memory in the first place? Some things may want to wait to free memory to try to prevent memory fragmentation, but as soon as a program calls free, the memory goes back to the OS. (If you use a custom allocator, this may or may not be true for your allocator's free function, but the C standard library free function absolutely returns the memory to the OS.) In fact, a memory leak is when a program fails to return memory it's allocated but will never use again to the OS.
It might be a good idea to research how memory management works; you seem to have a completely incorrect understanding of it. Surely a process's memory usage can go down as well as up, otherwise you'd have to restart your computer, or at least the majority of the programs running, constantly.
Steam is completely free. If you mean re-buy the games you had on Steam, you shouldn't have to, as long as you either remember your account name and password, or still have access to the e-mail address you used for your account.
That would be nice, but Python unfortunately doesn't do that. As I posted above, you could still do the same from Python, though. You could check sys.version_info to see if it's the desired version, and if not use Python's built-in Windows registry library to find the right version.
Sidenote: if you wanted it to work with Python 2 and 3 without using 2to3, use this: (sorry, it doesn't want to indent properly, so you'll need to add indentation as needed)
try: import _winreg as winreg except: import winreg
You can then get the install path for the version of Python you want (winreg.QueryValue(winreg.HKEY_LOCAL_MACHINE, 'SOFTWARE\\Python\\PythonCore\\2.7\\InstallPath'), replacing 2.7 with whatever version you want), and run it with your script (sys.argv[0]) as the argument.
That depends. Is there an automated tool to create and deploy such EXE wrappers yet?
Not that I'm aware of, probably because it's about five lines of C#. It would also be doable fairly easily from Python as well, but it seems kludgy to make a Python script to find the proper Python runtime then call it on another Python script. Read HKLM\SOFTWARE\Python\PythonCore\$MAJOR.$MINOR\InstallPath (or HKLM\SOFTWARE\Wow6432Node\Python\PythonCore\$MAJOR.$MINOR\InstallPath on 64-bit Windows if you want 32-bit Python), if the key doesn't exist then display an error (preferably with a link to download the proper version), otherwise run $InstallPath\python.exe $SCRIPT.py.
That being said, again, most Python programs will ship with their own Python runtime (with py2exe or similar) if they depend on a specific version like that. Additionally, if you have users with enough smarts to be able to figure out installing Python on their own and don't expect them to change the installation location (or this script is just for yourself), you can obviously use a one-liner BAT file, but I wouldn't expect to see that outside of closed deployments.
I'll agree it's not as simple as it is on Linux distros (although some use python27, and some use python2.7, for instance), but it's certainly not difficult.
And harder when your program relies on third-party libraries that have not yet been ported to 3.
This I fully agree with, and is unfortunately true. However, most libraries on PyPI have been ported to Py3k these days (at least ones with ongoing development). A list of PyPI packages that haven't been ported to Py3k yet can be found here. You could (most likely) easily run 2to3 on other libraries yourself, and fix whatever minor problems arise. It would be harder in libraries with C extensions, but it's almost always trivial for pure Python libraries.
some Python environments (such as Windows) can't easily have multiple versions installed side-by-side
The Python installers on Windows install to (by default) C:\Python$MAJOR$MINOR (Python 2.7 installs to C:\Python27, Python 3.2 installs to C:\Python32). For scripts that require a certain version of Python, you may have to open it with the proper version yourself, because (obviously).py files can only be associated with one program at a time. But for scripts made to be run by end-users, (assuming they don't ship their own Python runtime in the first place) a simple EXE wrapper can use the right interpreter.
What part of this isn't easy?
Also, many developers make things compatible with both, which is made much easier with 2to3. Quite a few setup.py scripts use 2to3 automatically even, to be compatible with both using the normal python setup.py install.
While I agree that it'd be hard to justify paying that much for a small developer, it's irrelevant as, just as I figured they probably did, Sony included some sort of way to run the things you make with the PSS on PlayStation certified Android phones. Unity does the exact same thing (provided you pay for the Android license); they ship their own runtime for Android so you don't also have to pay for Mono for Android. I don't know the details (I have the SDK installed but I don't have any PlayStation certified phones to test on), but you don't need to buy Mono for Android to run PSS stuff on PS Android phones.
That being said, when I said "Nothing's stopping anyone from running Mono stuff on Android.", I was referring to technological limitations. To make an Android app and release it on Google Play, you also have to pay a $25 USD registration fee, and you'll rip your hair out trying to do it without a real device to test on, so also whatever cost that is.
There already is Mono for Android. If Sony didn't want people to pay for Mono for Android (understandable as it starts at $399 USD), they could fairly easily just make it themselves. Nothing's stopping anyone from running Mono stuff on Android.
A server-side Lua interface is planned for Minecraft, but it's not actually out yet, and even after it comes out, nothing will be client-side. See here. Everything now is done in Java, usually with Bukkit on the server and Spout on the client.
I was talking about games without extra DRM tacked on. I figured that was implied, because games that require an Internet connection have a big fat warning on their Store page, so people should know what they're getting into there.
Yes, some games on Steam use GfWL. They also warn you on the Store page that it has it. "3rd-party DRM: Games for Windows Live" Of course, GfWL also lets you play single-player games offline, as well. I think it's fair to make you be online to play a game online.
That's true. But they have been getting much better with labeling external DRM on a game's store page these days. Anyone concerned about non-Steam DRM should check there first before buying a game. In the case of always-connected DRM, there's even a big fat orange warning above the "Buy Me!" box, I'd assume from lots of complaints.
The memory leak won't forever, nor until it gets killed by a user or the phone is rebooted. When a device runs out of memory, Android finds the task that won't disrupt the user if killed (those games in the backgrounds are the perfect example), and has been idle the longest, and then kills it. Just because the memory on a device is 80% full doesn't mean Android hasn't done its job. It's gotten MUCH better at managing memory since Donut. So if you have to kill the app from Settings (which is what I'm assuming you're talking about) or reboot your phone, I'd suggest you try not doing that, and let Android handle it for you.
Also, side note: just because an app comes back exactly the way it was doesn't mean it wasn't killed. Android apps are supposed to (but most games don't, sadly) save state when they are about to be killed, and restore it when they are run again.
You can't do that with the iPhone or (last I heard) a Blackberry.
No, just no. BlackBerries have always been able to install apps from any source. Hell, they work with most J2ME apps also. BlackBerry App World only came out in 2009. Kinda hard to limit apps to an app store when one doesn't exist, no?
Apple didn't develop Growl. The only thing they do is (now) distribute it over the Mac App Store. And that wasn't their choice per se, the Growl developers posted it there.
I'd be surprised if FCC doesn't start to crack on Google's monopoly tactics soon.
I'd be surprised if the FCC considered using HTTPS a monopolistic practice. I'd be even more surprised if the FCC told Google "Encryption is good for security, but you can't use it, because it stops Referrer headers from being sent. Your users will just have to go without crypto."
The FSF not being objective doesn't automatically mean they're wrong. They may be fanatics, but they're fanatics with lawyers. And in this case, they have common sense too.
I never brought up DRM. That would be relevant if we were talking about GPLv3 (with its anti-tivoization clause), but we're not.
Saying "non-commercial" is not a right, it's a restriction. They say "You may", but earlier in the ToS clearly states "you shall use Products in compliance with the applicable usage rules established by Apple and its principals ('Usage Rules')" So yes, the ToS does include restrictions.
The FSF doesn't care about how many people use GPL software; they care if it turns proprietary. But that's entirely irrelevant. The simple fact of the matter is that the GPL and App Store ToS are mutually exclusive.
If Apple has changed the ToS in a meaningful way (that removes all further restrictions), please do let me know, and I apologize in advance if that's the case. I don't have an iPhone/iDevice, so I'm going from what I've found around the 'nets.
For those of us using Google Apps, there's still no way to use Google+ without registering for a Gmail address. For me, this is a non-starter. Considering many people use Google Apps for email and other Google services on a personal domain, one could assume some of Google's biggest fans use Google Apps. It really doesn't make sense that Google still shuts them out of Google+, considering how hard they're pushing it.
Once they get Google Apps accounts working on Google+, I'll happily try it out (and probably stick with it from what I've heard). But until then, I'm not going to make a Gmail account just for Google+.
My apologies. As I've said, I haven't touched the iOS development platform in a while.
Please re-read my comment, and not pluck out random bits without context. I said "may be a prohibitively high learning curve for people trying to port a FLOSS program over". Yes, it's a superset of C. That being said, how easy do you really think it is to port a C++ (or $FAVORITE_LANG) program to Obj-C? Never mind the wildly different syntaxes for working with classes and objects, but the whole responder methodology is vastly different as well. And let's not forget about the lack of the C++ STL and C++ Standard Library. I'm willing to bet you'll never see "cin" or "cout" (for oversimplified examples) in Obj-C.
Obj-C isn't necessarily hard to learn on its own, but porting from anything but C (since you'd only have to add on syntax, not change things around, but it also compiles as Obj-C as well) isn't fun. I never blamed the language for this, as my context indicates.
Does Apple not add any restrictions on what you can do with apps you buy from the App Store? Yes, they absolutely do.
The GPL doesn't allow you to add any restrictions past what it specifies, so it's fairly clear that you can't distribute GPL'd binaries on the App Store. See http://mailman.videolan.org/pipermail/vlc-devel/2010-November/077486.html for the FSF's official position. It does not matter if you charge or not, there are conflicts in the ToS even for free apps. For example, "(i) You may download and sync a Product for personal, noncommercial use on any device You own or control." Again, the GPL doesn't allow further restrictions to be placed, and that is a pretty big restriction. Ergo, you have to either ignore the GPL (which is fine if you wrote all of the GPL'd code), or you can't distribute the app.
On OS X sure, because they're already having a hard time competing with... everything else. The only reason developers (a fairly large OS X market) continue to use it is because they can freely run lots of FLOSS (Homebrew and MacPorts help a lot here).
On iOS it's another story entirely. I wouldn't call it "extreme censorship", but they do reject FLOSS apps for no other discernible reason (granted, not all, but it appears to be arbitrary). Also, now that you MUST use Obj-C and nothing else, that may be a prohibitively high learning curve for people trying to port a FLOSS program over. Of course, if it's C, it shouldn't be hard, but anything else would need a full port (since X to Obj-C compilers are also forbidden). Almost the whole ToS of the developer kit is against FLOSS.
If you're right, then I apologize. The FSF states that they must provide source (with no other options mentioned, including ceasing distribution), but I wouldn't put it past them to exaggerate the truth (or omit relevant facts) to "further the cause of freedom."
Slashdot Mirror
Even one process freeing memory does return it to the OS. If it didn't, what would be the point of freeing memory in the first place? Some things may want to wait to free memory to try to prevent memory fragmentation, but as soon as a program calls free, the memory goes back to the OS. (If you use a custom allocator, this may or may not be true for your allocator's free function, but the C standard library free function absolutely returns the memory to the OS.) In fact, a memory leak is when a program fails to return memory it's allocated but will never use again to the OS.
It might be a good idea to research how memory management works; you seem to have a completely incorrect understanding of it. Surely a process's memory usage can go down as well as up, otherwise you'd have to restart your computer, or at least the majority of the programs running, constantly.
http://emscripten.org/
Steam is completely free. If you mean re-buy the games you had on Steam, you shouldn't have to, as long as you either remember your account name and password, or still have access to the e-mail address you used for your account.
Sidenote: if you wanted it to work with Python 2 and 3 without using 2to3, use this: (sorry, it doesn't want to indent properly, so you'll need to add indentation as needed)
You can then get the install path for the version of Python you want (winreg.QueryValue(winreg.HKEY_LOCAL_MACHINE, 'SOFTWARE\\Python\\PythonCore\\2.7\\InstallPath'), replacing 2.7 with whatever version you want), and run it with your script (sys.argv[0]) as the argument.
Not that I'm aware of, probably because it's about five lines of C#. It would also be doable fairly easily from Python as well, but it seems kludgy to make a Python script to find the proper Python runtime then call it on another Python script. Read HKLM\SOFTWARE\Python\PythonCore\$MAJOR.$MINOR\InstallPath (or HKLM\SOFTWARE\Wow6432Node\Python\PythonCore\$MAJOR.$MINOR\InstallPath on 64-bit Windows if you want 32-bit Python), if the key doesn't exist then display an error (preferably with a link to download the proper version), otherwise run $InstallPath\python.exe $SCRIPT.py.
That being said, again, most Python programs will ship with their own Python runtime (with py2exe or similar) if they depend on a specific version like that. Additionally, if you have users with enough smarts to be able to figure out installing Python on their own and don't expect them to change the installation location (or this script is just for yourself), you can obviously use a one-liner BAT file, but I wouldn't expect to see that outside of closed deployments.
I'll agree it's not as simple as it is on Linux distros (although some use python27, and some use python2.7, for instance), but it's certainly not difficult.
This I fully agree with, and is unfortunately true. However, most libraries on PyPI have been ported to Py3k these days (at least ones with ongoing development). A list of PyPI packages that haven't been ported to Py3k yet can be found here. You could (most likely) easily run 2to3 on other libraries yourself, and fix whatever minor problems arise. It would be harder in libraries with C extensions, but it's almost always trivial for pure Python libraries.
The Python installers on Windows install to (by default) C:\Python$MAJOR$MINOR (Python 2.7 installs to C:\Python27, Python 3.2 installs to C:\Python32). For scripts that require a certain version of Python, you may have to open it with the proper version yourself, because (obviously) .py files can only be associated with one program at a time. But for scripts made to be run by end-users, (assuming they don't ship their own Python runtime in the first place) a simple EXE wrapper can use the right interpreter.
What part of this isn't easy?
Also, many developers make things compatible with both, which is made much easier with 2to3. Quite a few setup.py scripts use 2to3 automatically even, to be compatible with both using the normal python setup.py install.
It's a quote.
While I agree that it'd be hard to justify paying that much for a small developer, it's irrelevant as, just as I figured they probably did, Sony included some sort of way to run the things you make with the PSS on PlayStation certified Android phones. Unity does the exact same thing (provided you pay for the Android license); they ship their own runtime for Android so you don't also have to pay for Mono for Android. I don't know the details (I have the SDK installed but I don't have any PlayStation certified phones to test on), but you don't need to buy Mono for Android to run PSS stuff on PS Android phones.
That being said, when I said "Nothing's stopping anyone from running Mono stuff on Android.", I was referring to technological limitations. To make an Android app and release it on Google Play, you also have to pay a $25 USD registration fee, and you'll rip your hair out trying to do it without a real device to test on, so also whatever cost that is.
There already is Mono for Android. If Sony didn't want people to pay for Mono for Android (understandable as it starts at $399 USD), they could fairly easily just make it themselves. Nothing's stopping anyone from running Mono stuff on Android.
A server-side Lua interface is planned for Minecraft, but it's not actually out yet, and even after it comes out, nothing will be client-side. See here. Everything now is done in Java, usually with Bukkit on the server and Spout on the client.
I was talking about games without extra DRM tacked on. I figured that was implied, because games that require an Internet connection have a big fat warning on their Store page, so people should know what they're getting into there.
Yes, some games on Steam use GfWL. They also warn you on the Store page that it has it. "3rd-party DRM: Games for Windows Live" Of course, GfWL also lets you play single-player games offline, as well. I think it's fair to make you be online to play a game online.
That's true. But they have been getting much better with labeling external DRM on a game's store page these days. Anyone concerned about non-Steam DRM should check there first before buying a game. In the case of always-connected DRM, there's even a big fat orange warning above the "Buy Me!" box, I'd assume from lots of complaints.
Steam has an offline mode. As long as you've played the game once online, Steam > Go Offline... will let you play without an Internet connection.
You've always needed a Wallet (or Checkout, before) account to pay the $25 registration fee. This also won't affect free apps in any way.
The memory leak won't forever, nor until it gets killed by a user or the phone is rebooted. When a device runs out of memory, Android finds the task that won't disrupt the user if killed (those games in the backgrounds are the perfect example), and has been idle the longest, and then kills it. Just because the memory on a device is 80% full doesn't mean Android hasn't done its job. It's gotten MUCH better at managing memory since Donut. So if you have to kill the app from Settings (which is what I'm assuming you're talking about) or reboot your phone, I'd suggest you try not doing that, and let Android handle it for you.
Also, side note: just because an app comes back exactly the way it was doesn't mean it wasn't killed. Android apps are supposed to (but most games don't, sadly) save state when they are about to be killed, and restore it when they are run again.
You can't do that with the iPhone or (last I heard) a Blackberry.
No, just no. BlackBerries have always been able to install apps from any source. Hell, they work with most J2ME apps also. BlackBerry App World only came out in 2009. Kinda hard to limit apps to an app store when one doesn't exist, no?
Apple didn't develop Growl. The only thing they do is (now) distribute it over the Mac App Store. And that wasn't their choice per se, the Growl developers posted it there.
I'd be surprised if FCC doesn't start to crack on Google's monopoly tactics soon.
I'd be surprised if the FCC considered using HTTPS a monopolistic practice. I'd be even more surprised if the FCC told Google "Encryption is good for security, but you can't use it, because it stops Referrer headers from being sent. Your users will just have to go without crypto."
The FSF not being objective doesn't automatically mean they're wrong. They may be fanatics, but they're fanatics with lawyers. And in this case, they have common sense too.
I never brought up DRM. That would be relevant if we were talking about GPLv3 (with its anti-tivoization clause), but we're not.
Saying "non-commercial" is not a right, it's a restriction. They say "You may", but earlier in the ToS clearly states "you shall use Products in compliance with the applicable usage rules established by Apple and its principals ('Usage Rules')" So yes, the ToS does include restrictions.
The FSF doesn't care about how many people use GPL software; they care if it turns proprietary. But that's entirely irrelevant. The simple fact of the matter is that the GPL and App Store ToS are mutually exclusive.
If Apple has changed the ToS in a meaningful way (that removes all further restrictions), please do let me know, and I apologize in advance if that's the case. I don't have an iPhone/iDevice, so I'm going from what I've found around the 'nets.
For those of us using Google Apps, there's still no way to use Google+ without registering for a Gmail address. For me, this is a non-starter. Considering many people use Google Apps for email and other Google services on a personal domain, one could assume some of Google's biggest fans use Google Apps. It really doesn't make sense that Google still shuts them out of Google+, considering how hard they're pushing it.
Once they get Google Apps accounts working on Google+, I'll happily try it out (and probably stick with it from what I've heard). But until then, I'm not going to make a Gmail account just for Google+.
My apologies. As I've said, I haven't touched the iOS development platform in a while.
Please re-read my comment, and not pluck out random bits without context. I said "may be a prohibitively high learning curve for people trying to port a FLOSS program over". Yes, it's a superset of C. That being said, how easy do you really think it is to port a C++ (or $FAVORITE_LANG) program to Obj-C? Never mind the wildly different syntaxes for working with classes and objects, but the whole responder methodology is vastly different as well. And let's not forget about the lack of the C++ STL and C++ Standard Library. I'm willing to bet you'll never see "cin" or "cout" (for oversimplified examples) in Obj-C.
Obj-C isn't necessarily hard to learn on its own, but porting from anything but C (since you'd only have to add on syntax, not change things around, but it also compiles as Obj-C as well) isn't fun. I never blamed the language for this, as my context indicates.
Does Apple not add any restrictions on what you can do with apps you buy from the App Store? Yes, they absolutely do.
The GPL doesn't allow you to add any restrictions past what it specifies, so it's fairly clear that you can't distribute GPL'd binaries on the App Store. See http://mailman.videolan.org/pipermail/vlc-devel/2010-November/077486.html for the FSF's official position. It does not matter if you charge or not, there are conflicts in the ToS even for free apps. For example, "(i) You may download and sync a Product for personal, noncommercial use on any device You own or control." Again, the GPL doesn't allow further restrictions to be placed, and that is a pretty big restriction. Ergo, you have to either ignore the GPL (which is fine if you wrote all of the GPL'd code), or you can't distribute the app.
On OS X sure, because they're already having a hard time competing with... everything else. The only reason developers (a fairly large OS X market) continue to use it is because they can freely run lots of FLOSS (Homebrew and MacPorts help a lot here). On iOS it's another story entirely. I wouldn't call it "extreme censorship", but they do reject FLOSS apps for no other discernible reason (granted, not all, but it appears to be arbitrary). Also, now that you MUST use Obj-C and nothing else, that may be a prohibitively high learning curve for people trying to port a FLOSS program over. Of course, if it's C, it shouldn't be hard, but anything else would need a full port (since X to Obj-C compilers are also forbidden). Almost the whole ToS of the developer kit is against FLOSS.
If you're right, then I apologize. The FSF states that they must provide source (with no other options mentioned, including ceasing distribution), but I wouldn't put it past them to exaggerate the truth (or omit relevant facts) to "further the cause of freedom."