I don't see much of a killer app either, but I don't think one is really needed. The second screen can nicly be used for regular games, map, status values, inventories and similar things can be drawn to it and thus save some space on the other screen for gameplay. If the touchscreen is useable enough with just the fingers it might also provide a nice additional number of buttons, no need to pause the gameplay, just punch something in the inventory screen. Last not least the touchscreen provides a mouse-like interface, which could be quite usefull for some types of games.
Revolutionary or ground breaking? Probally not, but I would say its a welcome addition.
The problem with permanent death is that it would make exploring a really non-fun thing to do. How exactly would you make good decisions if you don't know what to expect? You would need to be force to constantly restart from zero just to figure out how stuff works or you would have to be extremly carefull with each and every step you make. Doesn't really sound fun, most people would probally drop such a game quite quick. After all permanent death is now already extinct from single player games for that exact reason, you always have a reset point not to far away. Death should of course punish and hurd a little bit, but making it permanent, providing a sudden death to the players gaming experience will really not lead to much good.
That said, I consider permanent death worth a try, but a game using it would really need to be completly different from todays MMORPGs, ie. something would need to be there in place to make permanent death not the end of the players game run, but part of the game (get converted to a ghost, hunt and posses other characters or whatever).
### The issue of Linux not running as cleanly after all the files are whiped out vs. Windows still able to run isn't much a means of stability.
Actually it kind of is, but probally more a usability issue then a stability. Device files under Linux are still a major pain, permissions get wrong, my USB device filenames keep changing on each boot (graphictablet on/dev/input/event2 or/dev/input/event3? roll a dice...), creating devices got extremly hard (ie. for those drivers who don't have the hooks in place to create them like nvidia ones) since the advent of devfs/udev, since everything you mknod goes 'bye,bye' on next reboot and the naming is quite confusing (is now/dev/hda standard or will I be stuck with the unreadable/dev/ide/bus/target/yadada/whatever/...), tracking down having a device files that are incorrectly named (ie. hda is really hdb) and there are a bunch of other issues. Last not least all of this is also kind of different from distri to distri, so if you change you have to relearn all your workarounds.
I not saying that device filenames are bad by any means, just that their current implementation is still quite problematic and throublesome.
There is also our our good old friend 'deltree' on MS-DOS which would get closer to 'rm -rf'. However 'rm -rf' and 'format c:' are kind of the standard 'answers' to screw things up completly, so its fair to compare them even so they don't do exactly the same.
While 1'600 sounds like a pretty huge number, the closing and the fines itself doesn't sound so much special if it is really true that they let children play adult games. After all in germany similar things[1] have happened and I am sure that if young children would use internet cafe to watch porn the US authorities wouldn't be much pleased either.
That only works if the XF86Config already contains all the right Modelines with the right refresh rate and with the right settings (otherwise the alignment might be completly of). Changing the default startup resolution might also get tricky that way.
The real throuble is really that there doesn't seem to be a real interface to interact with XF86Config, meaning for anything that is wrong in that file you are back to 'vi XF86Config' style of fixing stuff, no GUI. Some distros provide things like Sax to make things easier, but they are non standard and thus not integraded into Gnome or KDE. Its also no fun to newly figure out how to do things once you switch distros, not so much a problem if you always use the same, but it makes 'help your neighbour' a whole lot more difficult if he uses another distri.
Last not least, none of the automatic configurators for XF86Config did a good job for me, they provide a reasonablly default, but for refresh rate or additional input devices (graphic tablet) I always needed to go back to manually edit the config file.
### If you want a Stable server OS, install Debian Stable.
The problem with this is that 'Debian stable' is called so, not because it is stable as in 'never crash', but only stable in the 'never change' category. If a new upstream version fixed a bunch of bugs, Debian stable will never see them unless they are security related, same with new hardware drivers and such.
While having a stable OS that never changed beside security updates is of course not the worst thing for a server, the times that pass between Debian stable releases are often that long that you can't really use the system unless you do a lot of manually complitation and backporting. Sometimes its worth the effort, but often its not. Debian really needs to change its release cycle to something that happens more often and more regularly, and not just randomly 'when its done', else it will sooner or later obsolete itself as more and more users are switching to testing (which has a serious lack of security updates).
In germany credits cards are far less widespread, so for a lot of people 'pay only via credit card' is equal to 'not available'. Paypal on the other side can be used in combination with a normal bank account, no need for a credit card, and makes international bank transfer pretty easy, especially for smaller amounts of money. When it comes to micropayment, Paypal is really the only one that gets close.
### UNIX can be made increasingly more secure by adding layers of protection that don't exist in UNIX, if the default protection isn't good enough.
Well, looking at the more or less recent, gnu.org, savannah, debian, ruby and gentoo server break-ins lets me kind of doubt that. If they can't get it right, how should the regular Joe User get it right?
I am not saying that Windows is more secure or the like, since that what you seems to be arguing against, I am just saying that both of them are extremly insecure and that a few weeks or month of having them unpatched is equally good to a root shell without a password. If now Unix is a little bit less insecure than Windows doesn't really matter all that much in the larger picture.
### which means that it's MUCH harder to get in and MUCH harder to do anything once you are in.
No, it does not make anything harder, wait a few weeks/months for the next remote exploid, compile programm, run programm and welcome to your new root shell, click&play at its best. You won't ever notice anything of all the barriers, since Unix provides you a nice way to sidestep them all (ie. the root account). If you think remote-root exploids don't happen often enough, just combine a local-root with a remote-user exploid, voila, you have a self-build local-root.
Does security really matter? I mean neither Windows nor Linux are secure, we see new ways to exploid them every few weeks or even days, be it some obscure attacks via manipulated pdf files or some remote root exploids via ssh or whatever. If people don't patch their system regularly they are lost no matter which one they use. So I see little point in comparing them on a my system "has more remote holes than yours" basis, especially when the breakins are more the result of popularity of the OS/app then anything else.
The real question should not be which system is more secure, since neither are, the question should more focus on which system is easier to maintain and mak upgrades and patches easy to install. If a system fails at that, no matter how few exploids it has, one unpatched is enough to get you into a hell of a lot of throuble.
Another question would be, what are the real alternatives and what will the future bring? I mean just patching C-bufferoverflow into all enternity is really not something on which I would build 'security', neither is the OpenBSD way of 'no features, no bugs' a real solution, since people will end up using 'features' and thus get bugs.
All performance issues asside, but I don't think that such a card, even if fully open sourced could really work better than the a regular nVidia one with closed sourced drivers, which is really extremly easy to install compared to a lot of Open Source stuff out there. After all I went for a Geforce card instead of a ATI 9200 (for which the specs are available to the DRI developers) because of exactly this issue. I don't care to much about OpenSource if that still makes it a hell to get it working.
That said, I don't think the advantage for other architectures would be that huge, ie. in Macs one doesn't have much of a choice for a graphic card, but simply gets what is inside and who in their right mind would replace some ATI 9700 or whatever against a slower, probally not by MacOSX supported 'OpenSource' graphic card?
Overall, yes, having a graphic card with fully OpenSource drivers would be nice to have, however nvidias Linux support so far is great and I don't think that an inverior OpenSource card would really help all that much. Its probally easy to just ask ATI or nVidia how much money they want to open the specs and then just start a little 'call for donations', however even then people would need to develop an open source driver themself, which will probally never get better then the default ones supplied by the manufactors.
Blenders UI takes a bit time to get used to it and has some quirks, but so do basically all other 3d applications. Having a look at some of the video tutorials at:
There is basically no reason to not use C++ these days, sure ABI compatibilty can be worse than C's and there are a few other minor compability issues, but hardly any of them matter for game programming. So pick a good C++ book (ie. Acceleraled C++) and learn the language, there is really no reason to avoid it, especially when the alternative is plain C.
About the GUI, I would recomment to write your own. Games after all often need some special properties (zoomability, transparency, pie-menus, WiW) that some normal GUI can't match or only if you write almost all of your widgets yourself. Writing your own GUI will save you the time to workaround the limitations of some premade GUI, especially since the benefits of a premade GUI toolkit won't be of much use for a game (no need for uniform look and such).
Last not least, if you really want to go C and a premade GUI toolkit, you could go for GTK+ and GtkGLArea (or however that OpenGL widget is called) and then just run your game in the GL widget which is surrounded by normal GTK+ GUI elements. Sure it won't look as pretty as native OpenGL stuff, but it might be the easiest alternative, see FreeCiv for example which does this (well, beside it doesn't use OpenGL).
The difference is however in the implementation, not in the language itself. In Haskell the compiler can figure out the types, even if I don't give him any hint, in Python the interpreter can't, however not so much because of the difference in language but simply because it doesn't even try to. Sure, there are lots of situations (eval() and friends) which make it impossible to give a 'right' answer about the type of an object, however those are relativly few in most code and could be easily be flagged 'away' if the language would provide support for that.
### The only way for a lint program to even start to compare is if you annotated the program with notes, which reduces readability more than using a strongly-typed language would.
The annotation could actually be pretty small, ie. only annotate the cases where its not the obviouse and derive the rest by the way the code is written. Haskell for example can detect which type a function has based on type inference, one can still manually specify the type, but for most stuff its simply not needed. Variables for example could simply 'locked' to the first type they get assigned to, everything else could then be reported as error/waring depending on the settings, ie. a = 5; str = "10" + a; => error. Sure, this doesn't work always, but for most of the code it should already be a great help.
### The implication above that type checking automatically produces better software is false.
Type-checking does of course not produce better software, there are just to many other issues that can go wrong. It however frees you from a very common programming error or at least moves it from run-time to compile-time, which can save you a whole lot of bug hunting, especially when a part of the code isn't used all that often.
I find for example refactoring in static typed languages a few orders of magnitude easier then in dynamic typed ones. In the static I just refactor the code, compile and fix the places where the compiler shows an error, pretty simple. In a dynamic however I change the code and then have to do bug hunting, guess work and grep'ing around to find the places where the code will now run into a type error, no static type checking that will help me.
And well, I don't get the hype of dynamic typing anyway, yes, there are a few places where its nice, ie. being able to return a False or Nil instead of an Integer to indicate an error, however thats already all good I can say about dynamic types. Stuff like arrays of ints vs. arrays of string and the like are solved by generics in static languages already pretty well, so thats not much of a plus for dynamic typed languages.
About making the code harder to read, it depends. Sometimes it can be quite helpfull to actually know what types a function expects instead of just hoping that the docu is accurat enough or existing at all.
Last not least, dynamic typing can be usefull in some situations and not specifing the types can also save a bit of typing, however not providing any static typing at all is something that I consider quite a big mistake since it just moves to many errors into run-time, where they really do not belong. And yes, in a perfect world a bunch of unit-checking might catch all my dynamic-type checking bugs, however we don't life in a perfect one and I still kind of prefer to let the compiler do the work then being force to write additional code.
While DeusEx was certainly a very good game, it is really not all that perfect. The open ended game play in the end boiled down to being able to chose between three different end sequenzes, didn't matter what you did the last 30h of gameplay, the end sequence you got only depended on the last 5min (endsequences itself also kind of sucked, but thats another story), kind of a disapointment after all those hours of gameplay.
The open gameplay also was not that open, if you stand infront of a door you in general had three ways to get by, a) find keycode, often laying around somewhere in a rather stupid email message b) crack door with multitool c) crawl through air shaft; while it was fun for the first few hours, it kind of repeated over and over through the game, a bit more varity would have helped.
There where also a bunch of story relevant situation where you simply had to do what the story writer meant you to do, while this might sometimes be necessary, its often hell of a lot confusing for the player, ie. I must let myself get caputured to continue, since I can't win the fight, but how should I know that upfront? Cost me quite a few save/loads to find out that getting caputured was the right way to go. Such elements must really be integrated kind of more smooth into an open ended game or they kind of spoil all the 'I can do what I like'-feeling quite a lot, since one thinks in these situations more about "What did the gamedesigner meant me to do?" instead of "What would I do?".
Anyway, DeusEx was still a great game and some more like it wouldn't really couldn't hurt. My favorite of all the 'open gameplay' games is however still Operation Flashpoint.
Has far as I know thats mainly because Pro Evolution Soccer lacks decent network support, which no matter how good it is as a game by itself, makes it pretty much unusable for any kind of eSports and internet gaming.
The problem is not 20sec vs 1min, but 20sec vs. almost instantanious. Of course this is not a problem when I plan to work for a few hours on the PC, then it its a non-issue. Its however a big problem for all those times where I do not plan to work on the PC for hours, but where I just want to quickly look up something on the net or such. Such an action itself might take only a minute, so 20sec boot + 20sec shutdown becomes a long time compared to the action itself and often enough its to long to even bother to start the PC at all.
Last not least 20sec is not the boottime, it might be the time till the GUI is first visible, until all application are started and fully working can take a hell of a lot longer.
I am sorry to crush peoples dreams, but this won't ever become an alternative for the regular Joe User on the desktop, no matter on how fast its boots or how good it looks.
People don't base their choice of the OS on the things it 'can do', but on the things it 'can't do'. And no matter how great the OS as performing all the tasks it does, if there are only a small handfull of critical tasks left which it can't do it simply won't be a useable alternative for the masses.
Linux by itself, even after all the hype and development, is still far far away from being a general purpose alternative to Windows, no games, pretty weird driver installment (ATI, kernel modules vs XFree drivers, etc.), no 100% Windows compability, lack of commercial applications, etc. This are all issues that Linux can't really fix by itself, sure driver installation could be made more streight forward, people can continue to improve Wine, but until the point where commercial companies at least try to run their software under Linux and approve it as 'Linux compatible', all these today maybe 90% working solution will just result in lots of users frustration and making Linux a non-alternative.
And I really don't see any reason to believe that Syllable would perform any better, especially if it doesn't have a smooth integration of X11, Linux-compatible closed-source binary drivers (NVidia/ATI) or Windows compability, let alone things such as a reasonably marked share.
Is it still worth the development time? Maybe, after all people are doing it for fun and it can also demonstrate things which are relativly easy todo if you start from scratch, but pretty hard if you would want to add them ontop of Linux, thus it might be able to give a bit 'direction and inspriation' for Linux development. But after all, unless that thing is at the very least 100% Linux and/or Windows compatible, I really don't expect myself or any serious number of people using this OS in the next 10 years.
Depends, for god-mode and just looking at the graphics a FX5200 + 1Ghz is enough, as long as no enemies are on the screen it also runs quite well or at least not much worse then the original Doom did on a 386er. Sure, as soon as monsters apear and the action starts the fps will drop down and the game will be almost unplayable, god-mode will help here.
So yes, a FX5200 isn't enough to play the game, but its enough to look at the graphics and walk around a bit.
Not really, far far away from 'perfect' actually. The Ctrl-L hack is really horrible, the window is to small, it easily loses focus, its slow as hell compared to the former dialog, it doesn't provide a view into the current directory, etc. Ctrl-L hack is really not something that should have ever entered into a production release.
The dialog also suffers from the lack of different views onto the files, in Gimp and Co. it would be nice to have a nautilus like thumbnail-preview, in other situations a small-icon view would be better then detail view. There doesn't seem to be a way to rename files either.
That said, if you are just 'mousing around', its better then the former one, but far from perfect, I would prefer the Windows one (for mousing) or the old Gnome one (for keyboarding) any day.
Deleteing the $HOME is of course unacceptable and should be punishable by law without much problems. Just because I stole your bike, doesn't mean that you are allowed to burn down my house, both things are a crime and the first doesn't justify the second.
The issue would be quite a bit trickier if instead of doing something obviously illegal the software would instead do something less obvious like trying to find the address, name or other personal information about the computer user who used the cracked serial and mail it to the author of the software so that he in turn could inform the police.
Slashdot Mirror
I don't see much of a killer app either, but I don't think one is really needed. The second screen can nicly be used for regular games, map, status values, inventories and similar things can be drawn to it and thus save some space on the other screen for gameplay. If the touchscreen is useable enough with just the fingers it might also provide a nice additional number of buttons, no need to pause the gameplay, just punch something in the inventory screen. Last not least the touchscreen provides a mouse-like interface, which could be quite usefull for some types of games.
Revolutionary or ground breaking? Probally not, but I would say its a welcome addition.
The problem with permanent death is that it would make exploring a really non-fun thing to do. How exactly would you make good decisions if you don't know what to expect? You would need to be force to constantly restart from zero just to figure out how stuff works or you would have to be extremly carefull with each and every step you make. Doesn't really sound fun, most people would probally drop such a game quite quick. After all permanent death is now already extinct from single player games for that exact reason, you always have a reset point not to far away. Death should of course punish and hurd a little bit, but making it permanent, providing a sudden death to the players gaming experience will really not lead to much good.
That said, I consider permanent death worth a try, but a game using it would really need to be completly different from todays MMORPGs, ie. something would need to be there in place to make permanent death not the end of the players game run, but part of the game (get converted to a ghost, hunt and posses other characters or whatever).
### The issue of Linux not running as cleanly after all the files are whiped out vs. Windows still able to run isn't much a means of stability.
/dev/input/event2 or /dev/input/event3? roll a dice...), creating devices got extremly hard (ie. for those drivers who don't have the hooks in place to create them like nvidia ones) since the advent of devfs/udev, since everything you mknod goes 'bye,bye' on next reboot and the naming is quite confusing (is now /dev/hda standard or will I be stuck with the unreadable /dev/ide/bus/target/yadada/whatever/...), tracking down having a device files that are incorrectly named (ie. hda is really hdb) and there are a bunch of other issues. Last not least all of this is also kind of different from distri to distri, so if you change you have to relearn all your workarounds.
Actually it kind of is, but probally more a usability issue then a stability. Device files under Linux are still a major pain, permissions get wrong, my USB device filenames keep changing on each boot (graphictablet on
I not saying that device filenames are bad by any means, just that their current implementation is still quite problematic and throublesome.
There is also our our good old friend 'deltree' on MS-DOS which would get closer to 'rm -rf'. However 'rm -rf' and 'format c:' are kind of the standard 'answers' to screw things up completly, so its fair to compare them even so they don't do exactly the same.
While 1'600 sounds like a pretty huge number, the closing and the fines itself doesn't sound so much special if it is really true that they let children play adult games. After all in germany similar things[1] have happened and I am sure that if young children would use internet cafe to watch porn the US authorities wouldn't be much pleased either.
[1] http://www.heise.de/newsticker/meldung/33234
That only works if the XF86Config already contains all the right Modelines with the right refresh rate and with the right settings (otherwise the alignment might be completly of). Changing the default startup resolution might also get tricky that way.
The real throuble is really that there doesn't seem to be a real interface to interact with XF86Config, meaning for anything that is wrong in that file you are back to 'vi XF86Config' style of fixing stuff, no GUI. Some distros provide things like Sax to make things easier, but they are non standard and thus not integraded into Gnome or KDE. Its also no fun to newly figure out how to do things once you switch distros, not so much a problem if you always use the same, but it makes 'help your neighbour' a whole lot more difficult if he uses another distri.
Last not least, none of the automatic configurators for XF86Config did a good job for me, they provide a reasonablly default, but for refresh rate or additional input devices (graphic tablet) I always needed to go back to manually edit the config file.
At least they are better than nethacks graphics =;)
### If you want a Stable server OS, install Debian Stable.
The problem with this is that 'Debian stable' is called so, not because it is stable as in 'never crash', but only stable in the 'never change' category. If a new upstream version fixed a bunch of bugs, Debian stable will never see them unless they are security related, same with new hardware drivers and such.
While having a stable OS that never changed beside security updates is of course not the worst thing for a server, the times that pass between Debian stable releases are often that long that you can't really use the system unless you do a lot of manually complitation and backporting. Sometimes its worth the effort, but often its not. Debian really needs to change its release cycle to something that happens more often and more regularly, and not just randomly 'when its done', else it will sooner or later obsolete itself as more and more users are switching to testing (which has a serious lack of security updates).
In germany credits cards are far less widespread, so for a lot of people 'pay only via credit card' is equal to 'not available'. Paypal on the other side can be used in combination with a normal bank account, no need for a credit card, and makes international bank transfer pretty easy, especially for smaller amounts of money. When it comes to micropayment, Paypal is really the only one that gets close.
### UNIX can be made increasingly more secure by adding layers of protection that don't exist in UNIX, if the default protection isn't good enough.
Well, looking at the more or less recent, gnu.org, savannah, debian, ruby and gentoo server break-ins lets me kind of doubt that. If they can't get it right, how should the regular Joe User get it right?
I am not saying that Windows is more secure or the like, since that what you seems to be arguing against, I am just saying that both of them are extremly insecure and that a few weeks or month of having them unpatched is equally good to a root shell without a password. If now Unix is a little bit less insecure than Windows doesn't really matter all that much in the larger picture.
### which means that it's MUCH harder to get in and MUCH harder to do anything once you are in.
No, it does not make anything harder, wait a few weeks/months for the next remote exploid, compile programm, run programm and welcome to your new root shell, click&play at its best. You won't ever notice anything of all the barriers, since Unix provides you a nice way to sidestep them all (ie. the root account). If you think remote-root exploids don't happen often enough, just combine a local-root with a remote-user exploid, voila, you have a self-build local-root.
Does security really matter? I mean neither Windows nor Linux are secure, we see new ways to exploid them every few weeks or even days, be it some obscure attacks via manipulated pdf files or some remote root exploids via ssh or whatever. If people don't patch their system regularly they are lost no matter which one they use. So I see little point in comparing them on a my system "has more remote holes than yours" basis, especially when the breakins are more the result of popularity of the OS/app then anything else.
The real question should not be which system is more secure, since neither are, the question should more focus on which system is easier to maintain and mak upgrades and patches easy to install. If a system fails at that, no matter how few exploids it has, one unpatched is enough to get you into a hell of a lot of throuble.
Another question would be, what are the real alternatives and what will the future bring? I mean just patching C-bufferoverflow into all enternity is really not something on which I would build 'security', neither is the OpenBSD way of 'no features, no bugs' a real solution, since people will end up using 'features' and thus get bugs.
All performance issues asside, but I don't think that such a card, even if fully open sourced could really work better than the a regular nVidia one with closed sourced drivers, which is really extremly easy to install compared to a lot of Open Source stuff out there. After all I went for a Geforce card instead of a ATI 9200 (for which the specs are available to the DRI developers) because of exactly this issue. I don't care to much about OpenSource if that still makes it a hell to get it working.
That said, I don't think the advantage for other architectures would be that huge, ie. in Macs one doesn't have much of a choice for a graphic card, but simply gets what is inside and who in their right mind would replace some ATI 9700 or whatever against a slower, probally not by MacOSX supported 'OpenSource' graphic card?
Overall, yes, having a graphic card with fully OpenSource drivers would be nice to have, however nvidias Linux support so far is great and I don't think that an inverior OpenSource card would really help all that much. Its probally easy to just ask ATI or nVidia how much money they want to open the specs and then just start a little 'call for donations', however even then people would need to develop an open source driver themself, which will probally never get better then the default ones supplied by the manufactors.
http://www.futurex-graphics.com/Blender/Video/
should provide a good help to get an understanding on how blenders ui works.
There is basically no reason to not use C++ these days, sure ABI compatibilty can be worse than C's and there are a few other minor compability issues, but hardly any of them matter for game programming. So pick a good C++ book (ie. Acceleraled C++) and learn the language, there is really no reason to avoid it, especially when the alternative is plain C.
About the GUI, I would recomment to write your own. Games after all often need some special properties (zoomability, transparency, pie-menus, WiW) that some normal GUI can't match or only if you write almost all of your widgets yourself. Writing your own GUI will save you the time to workaround the limitations of some premade GUI, especially since the benefits of a premade GUI toolkit won't be of much use for a game (no need for uniform look and such).
Last not least, if you really want to go C and a premade GUI toolkit, you could go for GTK+ and GtkGLArea (or however that OpenGL widget is called) and then just run your game in the GL widget which is surrounded by normal GTK+ GUI elements. Sure it won't look as pretty as native OpenGL stuff, but it might be the easiest alternative, see FreeCiv for example which does this (well, beside it doesn't use OpenGL).
The difference is however in the implementation, not in the language itself. In Haskell the compiler can figure out the types, even if I don't give him any hint, in Python the interpreter can't, however not so much because of the difference in language but simply because it doesn't even try to. Sure, there are lots of situations (eval() and friends) which make it impossible to give a 'right' answer about the type of an object, however those are relativly few in most code and could be easily be flagged 'away' if the language would provide support for that.
### The only way for a lint program to even start to compare is if you annotated the program with notes, which reduces readability more than using a strongly-typed language would.
The annotation could actually be pretty small, ie. only annotate the cases where its not the obviouse and derive the rest by the way the code is written. Haskell for example can detect which type a function has based on type inference, one can still manually specify the type, but for most stuff its simply not needed. Variables for example could simply 'locked' to the first type they get assigned to, everything else could then be reported as error/waring depending on the settings, ie. a = 5; str = "10" + a; => error. Sure, this doesn't work always, but for most of the code it should already be a great help.
### The implication above that type checking automatically produces better software is false.
Type-checking does of course not produce better software, there are just to many other issues that can go wrong. It however frees you from a very common programming error or at least moves it from run-time to compile-time, which can save you a whole lot of bug hunting, especially when a part of the code isn't used all that often.
I find for example refactoring in static typed languages a few orders of magnitude easier then in dynamic typed ones. In the static I just refactor the code, compile and fix the places where the compiler shows an error, pretty simple. In a dynamic however I change the code and then have to do bug hunting, guess work and grep'ing around to find the places where the code will now run into a type error, no static type checking that will help me.
And well, I don't get the hype of dynamic typing anyway, yes, there are a few places where its nice, ie. being able to return a False or Nil instead of an Integer to indicate an error, however thats already all good I can say about dynamic types. Stuff like arrays of ints vs. arrays of string and the like are solved by generics in static languages already pretty well, so thats not much of a plus for dynamic typed languages.
About making the code harder to read, it depends. Sometimes it can be quite helpfull to actually know what types a function expects instead of just hoping that the docu is accurat enough or existing at all.
Last not least, dynamic typing can be usefull in some situations and not specifing the types can also save a bit of typing, however not providing any static typing at all is something that I consider quite a big mistake since it just moves to many errors into run-time, where they really do not belong. And yes, in a perfect world a bunch of unit-checking might catch all my dynamic-type checking bugs, however we don't life in a perfect one and I still kind of prefer to let the compiler do the work then being force to write additional code.
While DeusEx was certainly a very good game, it is really not all that perfect. The open ended game play in the end boiled down to being able to chose between three different end sequenzes, didn't matter what you did the last 30h of gameplay, the end sequence you got only depended on the last 5min (endsequences itself also kind of sucked, but thats another story), kind of a disapointment after all those hours of gameplay.
The open gameplay also was not that open, if you stand infront of a door you in general had three ways to get by, a) find keycode, often laying around somewhere in a rather stupid email message b) crack door with multitool c) crawl through air shaft; while it was fun for the first few hours, it kind of repeated over and over through the game, a bit more varity would have helped.
There where also a bunch of story relevant situation where you simply had to do what the story writer meant you to do, while this might sometimes be necessary, its often hell of a lot confusing for the player, ie. I must let myself get caputured to continue, since I can't win the fight, but how should I know that upfront? Cost me quite a few save/loads to find out that getting caputured was the right way to go. Such elements must really be integrated kind of more smooth into an open ended game or they kind of spoil all the 'I can do what I like'-feeling quite a lot, since one thinks in these situations more about "What did the gamedesigner meant me to do?" instead of "What would I do?".
Anyway, DeusEx was still a great game and some more like it wouldn't really couldn't hurt. My favorite of all the 'open gameplay' games is however still Operation Flashpoint.
Has far as I know thats mainly because Pro Evolution Soccer lacks decent network support, which no matter how good it is as a game by itself, makes it pretty much unusable for any kind of eSports and internet gaming.
The problem is not 20sec vs 1min, but 20sec vs. almost instantanious. Of course this is not a problem when I plan to work for a few hours on the PC, then it its a non-issue.
Its however a big problem for all those times where I do not plan to work on the PC for hours, but where I just want to quickly look up something on the net or such. Such an action itself might take only a minute, so 20sec boot + 20sec shutdown becomes a long time compared to the action itself and often enough its to long to even bother to start the PC at all.
Last not least 20sec is not the boottime, it might be the time till the GUI is first visible, until all application are started and fully working can take a hell of a lot longer.
I am sorry to crush peoples dreams, but this won't ever become an alternative for the regular Joe User on the desktop, no matter on how fast its boots or how good it looks.
People don't base their choice of the OS on the things it 'can do', but on the things it 'can't do'. And no matter how great the OS as performing all the tasks it does, if there are only a small handfull of critical tasks left which it can't do it simply won't be a useable alternative for the masses.
Linux by itself, even after all the hype and development, is still far far away from being a general purpose alternative to Windows, no games, pretty weird driver installment (ATI, kernel modules vs XFree drivers, etc.), no 100% Windows compability, lack of commercial applications, etc.
This are all issues that Linux can't really fix by itself, sure driver installation could be made more streight forward, people can continue to improve Wine, but until the point where commercial companies at least try to run their software under Linux and approve it as 'Linux compatible', all these today maybe 90% working solution will just result in lots of users frustration and making Linux a non-alternative.
And I really don't see any reason to believe that Syllable would perform any better, especially if it doesn't have a smooth integration of X11, Linux-compatible closed-source binary drivers (NVidia/ATI) or Windows compability, let alone things such as a reasonably marked share.
Is it still worth the development time? Maybe, after all people are doing it for fun and it can also demonstrate things which are relativly easy todo if you start from scratch, but pretty hard if you would want to add them ontop of Linux, thus it might be able to give a bit 'direction and inspriation' for Linux development. But after all, unless that thing is at the very least 100% Linux and/or Windows compatible, I really don't expect myself or any serious number of people using this OS in the next 10 years.
Depends, for god-mode and just looking at the graphics a FX5200 + 1Ghz is enough, as long as no enemies are on the screen it also runs quite well or at least not much worse then the original Doom did on a 386er. Sure, as soon as monsters apear and the action starts the fps will drop down and the game will be almost unplayable, god-mode will help here.
So yes, a FX5200 isn't enough to play the game, but its enough to look at the graphics and walk around a bit.
### Actualy, it's perfect.
Not really, far far away from 'perfect' actually. The Ctrl-L hack is really horrible, the window is to small, it easily loses focus, its slow as hell compared to the former dialog, it doesn't provide a view into the current directory, etc. Ctrl-L hack is really not something that should have ever entered into a production release.
The dialog also suffers from the lack of different views onto the files, in Gimp and Co. it would be nice to have a nautilus like thumbnail-preview, in other situations a small-icon view would be better then detail view. There doesn't seem to be a way to rename files either.
That said, if you are just 'mousing around', its better then the former one, but far from perfect, I would prefer the Windows one (for mousing) or the old Gnome one (for keyboarding) any day.
Deleteing the $HOME is of course unacceptable and should be punishable by law without much problems. Just because I stole your bike, doesn't mean that you are allowed to burn down my house, both things are a crime and the first doesn't justify the second.
The issue would be quite a bit trickier if instead of doing something obviously illegal the software would instead do something less obvious like trying to find the address, name or other personal information about the computer user who used the cracked serial and mail it to the author of the software so that he in turn could inform the police.