Information that is not independently verifiable does not belong in an encyclopedia.
True, but the problem is how Wikipedia defines "verifiability". In most cases I have encountered it was used in the "it was printed on paper" sense, it didn't matter if the source was trustworthy, a press release or any other incorrect crap, as long as it was paper. Other Wikis, Blogs or Forums that might have easily verifiable knowledge of certain subjects aren't accepted as source. The PSP Homebrew article for example is pretty worthless blubber for that reason, mainstream press just doesn't like to talk about homebrew.
The issues isn't that ideas are worthless, but that its really hard to pick the good ideas out of all the crap that is out there. So people prefer to stick with ideas that somebody else has already proven in his product instead of trying something original themselves. A bad idea that is broken in known ways is just easier to work with then something completly original where you have no idea how it will impact the game.
Simply moving the post-its from the monitor to a locked desk drawer would do a lot to decrease the security risk of writing them down.
Or better yet, store it in your wallet. A place that is save enough for your money, credit cards and car keys should be save enough for a bunch of passwords. One could of course go one step further and get rid of passwords altogether and use a secure authentication device instead, with USB being commonplace everywhere that shouldn't be to hard to just use a USB device that does the authentication and encryption in a secure and easy to use manner.
The core problem isn't that users chose insecure passwords, thats just human nature, the core problem is simply that hardware and software developers haven't build systems that work well enough with this "flaw" of human nature.
Or how about a three axis mouse (i.e. X, Y and rotation)? Todays mice already have optical detectors in there, shouldn't be that hard to add detection of rotation to the detection of translation. I think the high end Wacom tablet can detection rotation of the Wacom mouse, but I haven't seen a regular optical mouse that can do it.
Enemy stomping shouldn't be much harder then just normal jumping from platform to platform, as both are a simple matter of pathfinding and pathfinding happens to be well enough understood problem, at least when it comes to simple tilebased worlds. It gets a little trickier then static platforms, as the enemies move around, but not that much harder, as they behave completly predictable.
The source code for a work means the preferred form of the work for making modifications to it. For an executable work, complete source code means all the source code for all modules it contains, plus any associated interface definition files, plus the scripts used to control compilation and installation of the executable.
I don't quite see how that allows to keep part of the build process secret as is the case with the AppleApp store. Now of course a lawyer might see that different, but arguing that this is totally compatible with the spirit of the GPL is just ridiculous. The GPL is there to allow modification and that of course includes the ability to actually compile the source back into a working executable.
There are plenty of people in the world who don't travel more then 160 miles on a regular basis. Sticking a gas engine in there would be stupid, as it would add a lot of weight and complexity that isn't needed. And of course lots of families buy two cars already anyway, so why not have one be pure electric one?
The GPL is a license that was build to preserve freedom as defined here. An application on the iPhone is a direct violation of freedom 2:
* The freedom to redistribute copies so you can help your neighbor (freedom 2).
You might blame the GPL for not being more clear on that (fixed in GPLv3), but the conflict between a locked down device like the iPhone and Free Software is very real.
If you choose to provide source through a written offer, then anybody who requests the source from you is entitled to receive it.
You have to give everybody the source code, not just those to which you distribute it, because those that receive the binaries have the right to distribute copies of the binaries along with copies of your written offer and you have to comply with that offer even when they didn't receive it directly from you.
That, along with most other talk about selling Free Software assumes that the user has the right to copy and resell it themselves, thus limiting the cost pretty much to the cost of distribution, thanks to basic economics. To quote from the very text:
With free software, users don't have to pay the distribution fee in order to use the software. They can copy the program from a friend who has a copy, or with the help of a friend who has network access.
That very assumption is broken with the AppStore, as you can't just by pass it and copy apps around freely.
So, selling Free Software isn't a problem, selling Free Software on a DRM locked device on the other side violates its spirit quite a bit.
Have you ever looked at the GPL? Before it starts with the "Terms and Conditions", it has a little section called "Preamble" that gives you a nice intro about its "spirit". In the GPLv3 you can read there:
Some devices are designed to deny users access to install or run modified versions of the software inside them, although the manufacturer can do so. This is fundamentally incompatible with the aim of protecting users' freedom to change the software.
Can you link binary made from GPL'd code dynamically to non-GPL'd library?
Only when the dynamic library is part of the operating system, when its some external third party thing you aren't allowed to do that. But its one of the less clear things about the GPL, so a court might rule different then the folks at the FSF would like.
Perhaps you can point at the specific clause that declares paying $99/yr or whatever to get your binaries signed for distribution is a violation?
The source code for a work means the preferred form of the work for making modifications to it. For an executable work, complete source code means all the source code for all modules it contains, plus any associated interface definition files, plus the scripts used to control compilation and installation of the executable. However, as a special exception, the source code distributed need not include anything that is normally distributed (in either source or binary form) with the major components (compiler, kernel, and so on) of the operating system on which the executable runs, unless that component itself accompanies the executable.
With a lot of lawyers thrown at the problem you could probably interpret that as forbidding distribution of signed binaries, as the scripts used for signing aren't provided. But well, its not exactly clear cut and we got GPLv3 to avoid those unclear situations in the first place.
They are, but the trouble already starts with Apple, the iPhone and the AppStore. Free Software on DRM'ed devices is always a troublesome thing, it might be ok by the license, but its certainly not in the spirit to give the users freedoms which are worth little or nothing because they can't exercise them. The guys that do the porting and charging are simply stuck between a rock and a hard place. There just isn't a proper way to release Free Software on a DRM'ed device, there is just the bad way with which you can get away with.
The simple fact that the GPLv3 tries to close this very loophole should be enough indication that it certainly wasn't an intended feature of the GPLv2.
Head out to Fry's and check out the shelves of Linux distributions and OpenOffice packages available for sale even though they are free to download.
You can take that copy of OpenOffice and install it on as many computers as you like, can you do the same with an application you downloaded from the AppStore?
Not quite, current estimates put it at 13.5-14 billion years. That of course still leaves plenty of time for civilizations to life and die. If there is a flinch of reality in all that singularity talk then even a civilization which wouldn't die, would be unlikely to make contact, as the time in which meaningful contact between us and a alien race could be possible is pretty much just a few 100 years. After that a alien civilization would be post singularity and beyond what we can comprehend and everything before that pretty much too, as we would be still living in the darkage. It is also likely that real colonization would never be attempted pre-singularity, as it would be to expensive and unlikely to succeeded. Much easier to send a spaceship full of robots, then a bunch of biologic beings, especially when the travel time might end up being hundreds or thousands of years.
It takes roughly 5 million polygons to fully render a human in full detail, and even the best GPU on the PC side of things isn't close to that.
You don't need to render 5 million polygons to get the same look as with 5 million polygons, if you throw normal mapping and geometry shader into the mix you can do it with a few thousand and thats quite doable with current day GPUs. Where things however fall apart is in behavior and animation, even 5 million polygons just gives you a a Realdoll, not an believable rendering of a human being. You can cheat your way out with motion capture and get something good looking, but that doesn't work to well in interactive gaming environments.
While more CPU and GPU power is of course still needed for more realistic scenarios, its not that we could solve the problem of creating them by just throwing more computing power at it, a lot of stuff that is needed to get a realistic looking and behaving humans is still pretty much a matter of research.
Let's also remember that people desire the "limited" Wii far more than the 360.
Thats because the Wii is pretty alone in its market, while the 360 has the PS3 as competition. If you look at the numbers you see that there are ~52mil Wiis out, while ~55mil PS3+Xbox360, so hardcore gaming isn't exactly dieing, its every bit as successful as casual gaming.
And in terms of creativity I really would look at the Wii. Sure, the controller was innovative, but the games? Most are just cheaply made cash-cows and even the good ones are just sequels that more often then not wouldn't even need the Wiimote (Mario, MarioKart, SmashBros, Zelda).
But the gaming industry seems to be hitting a technological wall, in that graphics are about as good as they need to be to look shiny and realistic.
While graphics themselves look pretty damn good these days, their animation, behavior and physics more often then not are completly abysmal. The real world isn't build out of styrofoam and card board boxes, but video game worlds seem to be, as that seems to be the best current generation physics engines are able to do. So there is still quite a lot of stuff left that we can solve by throwing more computing power at the problem.
The problem with stagnation seems to be more an issue with marketing then with hardware, most games are still clones, sequels or prequels to last years games, because those are known quantities that sell, not because you can't do anything original with all that computing power.
Re:Decent text editor still not included right?
on
Emacs Hits Version 23
·
· Score: 1
As said, Emacs hasn't been a pure text editor for ages and for things like mail or news reading it really couldn't hurt to have a proper treeview instead of ASCII art. Same is true for directory view's and many many other things. Even the info reader could benefit a good bit when it could do some more advanced markup and rendering instead the simplistic text stuff it does now.
Re:Decent text editor still not included right?
on
Emacs Hits Version 23
·
· Score: 1
It's a frikken text editor for God's sake.
It's not and never was. It's more a kind of Lisp-OS/application-platform, not really all that different from say Java or Firefox. The one big downside that Emacs has compared to the rest is that its old and was created in a time when GUIs where a thing of the future, so everything is build around text and its GUI support is rather abysmal. Emacs also lacks plenty of advanced programming features (multi-threading, etc.), so its a bit clunky and unresponsive at times. But for all its faults, its flexibility, extensibility and self-documentation is pretty awesome, especially considering when the project was started.
All that said, Emacs is certainly showing its age and I would love to see an Emacs-like tool recreated from scratch, as a lot of the ideas and features that make Emacs so great are still missing from more modern toolkits/environments.
Information that is not independently verifiable does not belong in an encyclopedia.
True, but the problem is how Wikipedia defines "verifiability". In most cases I have encountered it was used in the "it was printed on paper" sense, it didn't matter if the source was trustworthy, a press release or any other incorrect crap, as long as it was paper. Other Wikis, Blogs or Forums that might have easily verifiable knowledge of certain subjects aren't accepted as source. The PSP Homebrew article for example is pretty worthless blubber for that reason, mainstream press just doesn't like to talk about homebrew.
The issues isn't that ideas are worthless, but that its really hard to pick the good ideas out of all the crap that is out there. So people prefer to stick with ideas that somebody else has already proven in his product instead of trying something original themselves. A bad idea that is broken in known ways is just easier to work with then something completly original where you have no idea how it will impact the game.
Simply moving the post-its from the monitor to a locked desk drawer would do a lot to decrease the security risk of writing them down.
Or better yet, store it in your wallet. A place that is save enough for your money, credit cards and car keys should be save enough for a bunch of passwords. One could of course go one step further and get rid of passwords altogether and use a secure authentication device instead, with USB being commonplace everywhere that shouldn't be to hard to just use a USB device that does the authentication and encryption in a secure and easy to use manner.
The core problem isn't that users chose insecure passwords, thats just human nature, the core problem is simply that hardware and software developers haven't build systems that work well enough with this "flaw" of human nature.
Or how about a three axis mouse (i.e. X, Y and rotation)? Todays mice already have optical detectors in there, shouldn't be that hard to add detection of rotation to the detection of translation. I think the high end Wacom tablet can detection rotation of the Wacom mouse, but I haven't seen a regular optical mouse that can do it.
Enemy stomping shouldn't be much harder then just normal jumping from platform to platform, as both are a simple matter of pathfinding and pathfinding happens to be well enough understood problem, at least when it comes to simple tilebased worlds. It gets a little trickier then static platforms, as the enemies move around, but not that much harder, as they behave completly predictable.
The GPL defines source code as:
I don't quite see how that allows to keep part of the build process secret as is the case with the AppleApp store. Now of course a lawyer might see that different, but arguing that this is totally compatible with the spirit of the GPL is just ridiculous. The GPL is there to allow modification and that of course includes the ability to actually compile the source back into a working executable.
There are plenty of people in the world who don't travel more then 160 miles on a regular basis. Sticking a gas engine in there would be stupid, as it would add a lot of weight and complexity that isn't needed. And of course lots of families buy two cars already anyway, so why not have one be pure electric one?
What stops people from distributing copies of the source code?
What good is source code when you can't compile and run it? How do you help your neighbor when the binary you have is completely useless for him?
Free Software is about freedom, the DRM on the iPhone is there to prevent people from exercising the freedom that the GPL gives them.
The GPL is a license that was build to preserve freedom as defined here. An application on the iPhone is a direct violation of freedom 2:
You might blame the GPL for not being more clear on that (fixed in GPLv3), but the conflict between a locked down device like the iPhone and Free Software is very real.
No, it doesn't - read it again.
Have you actually read that? Quote:
You have to give everybody the source code, not just those to which you distribute it, because those that receive the binaries have the right to distribute copies of the binaries along with copies of your written offer and you have to comply with that offer even when they didn't receive it directly from you.
That, along with most other talk about selling Free Software assumes that the user has the right to copy and resell it themselves, thus limiting the cost pretty much to the cost of distribution, thanks to basic economics. To quote from the very text:
That very assumption is broken with the AppStore, as you can't just by pass it and copy apps around freely.
So, selling Free Software isn't a problem, selling Free Software on a DRM locked device on the other side violates its spirit quite a bit.
Have you ever looked at the GPL? Before it starts with the "Terms and Conditions", it has a little section called "Preamble" that gives you a nice intro about its "spirit". In the GPLv3 you can read there:
Can you link binary made from GPL'd code dynamically to non-GPL'd library?
Only when the dynamic library is part of the operating system, when its some external third party thing you aren't allowed to do that. But its one of the less clear things about the GPL, so a court might rule different then the folks at the FSF would like.
Perhaps you can point at the specific clause that declares paying $99/yr or whatever to get your binaries signed for distribution is a violation?
With a lot of lawyers thrown at the problem you could probably interpret that as forbidding distribution of signed binaries, as the scripts used for signing aren't provided. But well, its not exactly clear cut and we got GPLv3 to avoid those unclear situations in the first place.
IMHO, Ethics isn't the issue here.
They are, but the trouble already starts with Apple, the iPhone and the AppStore. Free Software on DRM'ed devices is always a troublesome thing, it might be ok by the license, but its certainly not in the spirit to give the users freedoms which are worth little or nothing because they can't exercise them. The guys that do the porting and charging are simply stuck between a rock and a hard place. There just isn't a proper way to release Free Software on a DRM'ed device, there is just the bad way with which you can get away with.
The simple fact that the GPLv3 tries to close this very loophole should be enough indication that it certainly wasn't an intended feature of the GPLv2.
The problem isn't the price, but that the iPhone is a restricted platform.
Head out to Fry's and check out the shelves of Linux distributions and OpenOffice packages available for sale even though they are free to download.
You can take that copy of OpenOffice and install it on as many computers as you like, can you do the same with an application you downloaded from the AppStore?
You have no obligation to a third party
The GPL FAQ sees that a little different:
http://www.gnu.org/licenses/gpl-faq.html#WhatDoesWrittenOfferValid
The universe is ~115 billion years old.
Not quite, current estimates put it at 13.5-14 billion years. That of course still leaves plenty of time for civilizations to life and die. If there is a flinch of reality in all that singularity talk then even a civilization which wouldn't die, would be unlikely to make contact, as the time in which meaningful contact between us and a alien race could be possible is pretty much just a few 100 years. After that a alien civilization would be post singularity and beyond what we can comprehend and everything before that pretty much too, as we would be still living in the darkage. It is also likely that real colonization would never be attempted pre-singularity, as it would be to expensive and unlikely to succeeded. Much easier to send a spaceship full of robots, then a bunch of biologic beings, especially when the travel time might end up being hundreds or thousands of years.
It takes roughly 5 million polygons to fully render a human in full detail, and even the best GPU on the PC side of things isn't close to that.
You don't need to render 5 million polygons to get the same look as with 5 million polygons, if you throw normal mapping and geometry shader into the mix you can do it with a few thousand and thats quite doable with current day GPUs. Where things however fall apart is in behavior and animation, even 5 million polygons just gives you a a Realdoll, not an believable rendering of a human being. You can cheat your way out with motion capture and get something good looking, but that doesn't work to well in interactive gaming environments.
While more CPU and GPU power is of course still needed for more realistic scenarios, its not that we could solve the problem of creating them by just throwing more computing power at it, a lot of stuff that is needed to get a realistic looking and behaving humans is still pretty much a matter of research.
Let's also remember that people desire the "limited" Wii far more than the 360.
Thats because the Wii is pretty alone in its market, while the 360 has the PS3 as competition. If you look at the numbers you see that there are ~52mil Wiis out, while ~55mil PS3+Xbox360, so hardcore gaming isn't exactly dieing, its every bit as successful as casual gaming.
And in terms of creativity I really would look at the Wii. Sure, the controller was innovative, but the games? Most are just cheaply made cash-cows and even the good ones are just sequels that more often then not wouldn't even need the Wiimote (Mario, MarioKart, SmashBros, Zelda).
But the gaming industry seems to be hitting a technological wall, in that graphics are about as good as they need to be to look shiny and realistic.
While graphics themselves look pretty damn good these days, their animation, behavior and physics more often then not are completly abysmal. The real world isn't build out of styrofoam and card board boxes, but video game worlds seem to be, as that seems to be the best current generation physics engines are able to do. So there is still quite a lot of stuff left that we can solve by throwing more computing power at the problem.
The problem with stagnation seems to be more an issue with marketing then with hardware, most games are still clones, sequels or prequels to last years games, because those are known quantities that sell, not because you can't do anything original with all that computing power.
As said, Emacs hasn't been a pure text editor for ages and for things like mail or news reading it really couldn't hurt to have a proper treeview instead of ASCII art. Same is true for directory view's and many many other things. Even the info reader could benefit a good bit when it could do some more advanced markup and rendering instead the simplistic text stuff it does now.
M-x longlines-mode
It's a frikken text editor for God's sake.
It's not and never was. It's more a kind of Lisp-OS/application-platform, not really all that different from say Java or Firefox. The one big downside that Emacs has compared to the rest is that its old and was created in a time when GUIs where a thing of the future, so everything is build around text and its GUI support is rather abysmal. Emacs also lacks plenty of advanced programming features (multi-threading, etc.), so its a bit clunky and unresponsive at times. But for all its faults, its flexibility, extensibility and self-documentation is pretty awesome, especially considering when the project was started.
All that said, Emacs is certainly showing its age and I would love to see an Emacs-like tool recreated from scratch, as a lot of the ideas and features that make Emacs so great are still missing from more modern toolkits/environments.