3. If you have important data that if not written to the hard drive will cause catastrophic failure, then you use the part of the API that forces that write.
You completly missed the point. The new data isn't important, it could be lost and nobody would care. The troublesome part is that you lose the old data too. If you would lose the last 5 minutes of changes in your KDE config that would be a non-issue, what however happens is that you not just lose the last few changes, but your complete config, it ends up as 0 byte files, which is a state that the filesystem never had.
fflush() has nothing to do with fsync(), all that fflush() does is flushing the user space file buffer to the kernel, it does nothing to move the data from the kernel to the actual drive.
First off, what we're talking about here is dealing with computer _crashes_, not standard operations.
Unclean shutdowns are a normal operation of a desktop computer, even Wii, PS3 and Xbox360 crash on a regular basis these days. You can be pretty free from crashes on a server that runs a very limited set of simple applications, but not on a desktop computer that runs the lastest 3D drivers and games. The computer doesn't even need to really crash, its enough when a game in fullscreen becomes unresponsive or the battery runs out of power. If a filesystem can't deal with that in a sane manner, its broken and has no place on a desktop system.
My experience with XFS (Ubuntu 8.10, default kernel, wire cache disabled) was the polar opposite, I lost files on almost every single crash, I consider the filesystem completly unusable for desktop use were flanky OpenGL drivers are rather common. Never lost files on crash with any other filesystem, except those very early versions of reiserfs back then years ago, but those issues got fixed and loss was the rare exception, not common occurrence as with XFS.
Quite true, its not just that they cheat a bit in there doing, its also that the overall structure of the game cheats, a lot. Most of the times for examples enemies and friendly character will not shoot at each other, they will stand there and shoot, but never actually hit anything, unless you go there and shoot a bit of yourself and trigger a script that will make your friends move forward. In most FPS you can just walk away from the fight, admire the scenery and neither friend nor foe will ever came to chase you down, they will happily wait with making war till you are back. Another huge annoyances are respawning enemies that just pop up out of thin air till you trigger some script to stop them.
Storytelling, from the sublime elegance of System Shock 2's logbooks to MGS4's split-screen-cut-scene absurdities, has advanced tremendously
For one thing, System Shock 1 is a a 15 years old. For another, storytelling really hasn't advanced much at all, for most part it has taken many steps back. Sure, MGS4 has insanely long and pretty cutscenes, but those things are cutscenes, not gameplay. The disconnect between story and actual gameplay is still as bad as it was a decade ago, if not worse, since dynamic scenarios such as seen in XCom:Ufo or EF2000 have pretty much disappeared and replaced by much more linear structure in most games. And of course the whole adventure game genre mostly disappeared, meaning storytelling has been replaced by linear narrative with little or no player influence and of course the whole humour got lost on the way, since you can't really do a Monkey Island FPS.
Now given, not all is bad, Mass Effect did some interesting things, Fahrenheit made some interesting leaps in interactive storytelling and Heavy Rain will surely bring something new to the table as well and we had Ico and SotC. But in the end there is a reason why people often refer to Planscape Tourment or The Longest Journey when it comes to storytelling in games, those games did what they did extremely well and nobody has yet managed to cram that much good story into a current day 3D game. The simplicity that those games had and the freedom they offered the writer, seems to have been lost in todays high-tech games.
The Wiimote is rather troublesome for FPS, since they have yet to figure out a proper way to actually turn your character. The whole 'move cursor to edge of screen' is really awkward and makes both turning and aiming troublesome. Even as straight lightgun replament it isn't good, because it lacks proper line of sight aiming, which is why you get a cursor in all games.
The internet was very well alive back then, its after all where I got most of my N64 infos from. There also was Quake. Online on console wasn't yet practical, but a few exotic devices existed for SNES and Genesis that made use of one form of online or another (Satellaview, Sega Meganet). On the Amiga you had modem support in a few games.
which made playing in anything but ideal conditions nigh impossible
Well, back then you had the choice, either go GameGear or Lynx and get color and backlight or go GameBoy and get a decent battery life.
When it comes to games not much has really changed, sure graphics got prettier and the whole multiplayer stuff, but that are more of incremental improvements then completly new concepts. Even the whole 'user created content' thing isn't all that new, I used to build levels for Boulder Dash on the C64 and then later for Doom.
As impressive the progress in hardware is, the progress in software is much slower and is mostly just a slow refinement of existing concepts instep of something truly new.
Unix systems have sane defaults, that usually represent some form of DENY ALL.
That's only really true for your single-user desktop installation, as soon as you want to build up a network of dozens or hundreds of computers you are pretty much on your own again, since then you have to figure out how you want to share directories, user accounts and all that stuff, which isn't solved with a simple "apt-get install...". A simple tasks such as sharing directories already becomes complicated, since NFS for example is pretty insecure by default, and there are plenty of more things that can go wrong when trying to manage a larger network.
But, its growth is linear to the number of primitives
Is that much of a problem when the hardware gets faster at exponential rates?
The whole problem I have with all this raytracing buzz is that so far, it hasn't produced even a single game or realistic tech demo (no, Quake4 with shiny spheres added doesn't cut it).
Todays games haven't been plain rasterizers for a long time, thanks to shaders and all the post processing they allow, yet when raytracing and rasterization is compared always the most basic form of the algorithms is compared and not what is used in the real world. If raytracing wants to look better then todays games it has to offer a lot more then just what plain raytracing does, since while hard shadows and reflections might be nifty, they are ultimativly rather useless, since they either can be faked easily or are already out of date (Crysis has realtime ambient occlusion, soft shadows, etc.). Now raytracing can certainly do more then that, but when you throw all the other stuff in the simple 'raytracing can do more polygons then rasterization' just isn't really a proper measurement anymore.
The Linux kernal and other big projects prove that large, complex projects can be accomplished under the FOSS model.
Not really, if you look around in the Free Software world you have a handful of large large Free Software projects that work good and can compete with commercial ones. The trouble is that its a tiny handful, the commercial game industry on the other side had to produces hundreds of high quality games in the same time to keep gamers busy. A good kernel can last you for decades, a good game on the other side lasts for a few month and then people want something new.
Given the right leadership and drive, I would really like to see an MMO spring up around an unlicenced universe
There is Worldforge, which has been around for a decade and yet to produce anything that is actually playable. The stop from proof of concept to actual game is a very tricky one and well, leadership is of course also an issue, Worldforge Uclient was already quite close to something like Ultima Online many years ago, but then things got ruined by some conflict between developers.
Where are games that break the moulds the way XCom, Syndicate, System Shock and Bioforge did?
The trouble is that its close to impossible to do anything original in Free Software, since when you go original, how do you convince your co-developers? Instead of working on an unproven idea, most people prefer to work on something which they know they will like. Which is why most successful FOSS games, or heck, most FOSS software projects in general, are clones of well known commercial titles. The reason why Linux got successful is because it was not original, people knew it was a Unix clone and they liked Unix, so they joined. Original stuff on the other side, like Hurd, has a much much harder time to get any traction.
Another problem of FOSS gaming is that its hard to keep the vision stable and consistent over time, developers join and leave all the time, so even if all their individual work might be good or even great, the end result can often be a completly disconnected mess.
In the end I don't expect FOSS gaming to make any large jumps any time soon, on the positive side however a large part of the FOSS gaming comes from actually developing them, so I recommend that anybody who wants to see things move forward, just joins one of the already existing projects.
Did that fix ever make it into Ubuntu? Since XFS on my Ubuntu 8.10 box trashed files on each and every single crash, completly unusable for desktop use.
But the documentation says, as sad as i am, that it is impossible to write a program in ANSI C which can determine at any point during it's runtime whether a specific file was written to the disk.
So we should all just happily accept it that the filesystem shreds our files? I don't think so, I'd chose a filesystem that doesn't produce this behaviour.
because someone decided that it is "reasonable" to fsync them at funny places.
The implement a "I am ok with file shredding" flag as mount option or whatever. A filesystem should be save by default, not tuned for max performance at the cost of file safety.
Not to implement something not specified is *not* a bug.
Its not a bug, its a feature... yeah, we used that to ridicule Microsoft. There is nothing in POSIX that says you *have to* shred the users file, older filesystems like ext3 or reiserfs did not have those problems. If ext4 now has them, its ext4 faults and nobody else. Pointing to the spec isn't an excuse for creating an broken filesystem, since in the real world its important that it works, not that its 'ok' by some funky interpretation of the spec.
should it be an fsync or an fdatasync?
I don't care, give me an implementation that works properly with ANSI-C and I am happy, everything else I consider broken.
But the documentation says, as sad as i am, that it is impossible to write a program in ANSI C which can determine at any point during it's runtime whether a specific file was written to the disk.
But that's not the fault of the ANSI-C standard, it is the fault of the implementation, since it would be perfectly free to do an fsync() on a fclose() and thus work as expected.
besides that new FS should be taken with care if you dont need them.
The troublesome part with this whole mess is that, so far, it is not considered a bug.
Another big thing in games are sound effects and music.
Music is pretty easy compared to the rest, since there are tons of musicians around that produce music under Creative Commons licenses, its quite easy to get those hop onto an Open Source project or just recycle their work if it fits. Sound effects on the other side are pretty hard, because that isn't exactly something people do just for the fun of it, you don't find sound effects community on the net like you find graphic artists and music communities. High quality sound effects also have the disadvantage that you might need expensive stuff to produce them, hard to capture the sound of a Ferrari or an AK-47 when you don't have one around. Last not least, sound effects are also extremely confusing in terms of license, you will find tons of "free" ones on the net or on CD collections, but pretty much never anything that is suitable for an Open Source project.
How would using the sync option differ from every program being implemented correctly and using fsync()? Wouldn't both of them just result in 'dog-slow'?
There are two problems here, the first one is that fsync() is a POSIX function, some people however try to write ANSI-C or ISO-C++ code, neither of those languages has fsync(). So this means that portable C/C++ code will behave incorrectly on Ext4, same is likely true for many other languages. That is something completly unacceptable. The other problem here is that hiding behind the standard is just stupid, just because the standard doesn't forbid the worst possible outcome, doesn't mean its ok to just allow it. From a good implementation I expect that it handles the those edgecases of a standard sanely and not just starts destroying data.
Now I haven't tried Ext4, so no idea how bad the problem is there, but I tried XFS and that was completly unusable, after almost every crash I lost files, gconf, rhythmbox, Wine config and plenty more ended up with a size of 0. That is not sane behavior, thats completly ridiculous insane shit.
*No* modern, desktop-usable file systems today guarantee new files to be there if the power goes out
They might not guarantee it 100%, but some at least are still pretty good as keeping your files save, while other are completly unusable piles of garbage, unfit for desktop use. Little anecdote, I never lost a single file due to crash on reiserfs or ext3 in a decade, yet after I switched to XFS I lost files on the *first* day and after almost every crash after that (mostly gconf files and Wine registry got nullified). Completely unusable.
Unlike a server, desktop systems have the tendency to run unstable graphics driver or being laptops that run out of battery. So crashes are quite common on desktop systems and something a file system has to deal with, not just ignore and delete the users files.
If you think punishment of any form is not a deterrent
He isn't saying that punishment has no effect, he says that harsher punishment has no effect. People might reason about getting captured by police, but they don't reason about getting 5 instead of 3 years in jail when commiting their act. If you want to stop future crime you have to fix the underlying causes in society, which of course most of the time isn't that simple or easy.
A lot of good science fiction does this. Authors are entitled to expect the reader (or player) to do some imaginative legwork.
The problem I had with Halo is that I could never shake the feeling that there was much more interesting stuff going on somewhere else then the stuff I was forced to play. The story around Master Chief did never really do anything that was very interesting and the whole flood thing was just annoying and out of place, I guess thats what you get when you player as the indestructible hero instead of a human being. Now at least with Halo you later got comics and books and stuff, so there actually is more going on, to bad that none of that ever made it into the games.
Half Life on the other side has the G-Men, which sadly just feels like a walking deus ex machina with legs. You never get a satisfying conclusion or backstory or anything. You play a clueless character who saves the earth by accident and nothing ever feels like an accomplishment, because you just stumble around in the world shooting dudes. Half the story of Half Life 2 is just transporter malfunction and then having to manually walk the way by foot, not exactly great storytelling.
That said, when it comes to video games I don't think overtelling a story is a problem, I think quite the opposite is true, most games these days try to avoid explain anything. Thanks to the first person view you are quite often limited to exactly that which you see through the main characters eyes, which sadly just isn't much. So instead of story, you simply get a few sad piece and pretty graphics thrown at you, maybe with a little dialog thrown in to connect things. Its kind of ridiculous when one looks back, the first 10 minutes of story and dialog in Monkey Island have more variety and interesting stuff going on then most todays games manage to cram into 10 hours.
Re:Tried the demo, felt like I had a frontal lobot
on
Review: Halo Wars
·
· Score: 1
I'm guessing that 'most' households with a game system have a USB keyboard and mouse laying around somewhere.
But most don't have a table around that they can put those on to play comfortably. There is also the issue that implementing a mouse/keyboard interface costs time and money, since now you have two interfaces to worry about. In the end its however simply the issue of "because Microsoft said so", thats what you get with a closed game platform, what you gain in standardization and ease of use, you lose in flexibility. Sony on the PS3 allows keyboard and mouse, but still, very few games make use of it (Unreal3 is the only one I can think of).
The real problem however starts long before keyboard and mouse. Why do an RTS game in the first place? Why clone something that was developed for different hardware and different input devices and that hasn't changed in 15 years, why not do something original instead that fits the hardware you have at hand. Full Spectrum Warrior for example was a great real-time tactics game that played great with a controller, merge that with some of the depths of XCom:UFO, throw in a bunch of new ideas and you could have a kick ass game that would be quite different from almost anything out there today.
Game developers have sadly started to think way to much in genres, instead of thinking about what would be the best gameplay to fit the story and settings, they take a predefined and done to death genre and paint it with a new theme.
Excel is certainly not your average programming language, but it can be used for programming. There are even some that have used it to write a 3D renderer in it.
Yep, thats not so far away from what I have in mind with my inputdrv app and for most part such a thing would be quite doable. There are however a few practical problems, one important one is that I don't think there is currently a clean way to reassign joystick ids, so if you plug in another joysticks or load a virtual driver for the remapping it will always be/dev/input/js2, while the game is using just js1, other then messing around with mv/ln/rm I don't know any way to actually get the device in the right place. Its not a unsolvable problem, but the workarounds are all rather ugly.
Another issue is the loading of the configurable driver must happen before the game itself, since each game needs its own configuration and because you can't change the configuration after the game is loaded. Their might be ways to accomplish this, but I haven' really looked into it. A little wrapper script done by the user would of course fix the problem, but again, that would be more a workaround then a solution.
Last problem of course is that you need to collect lots of data, you need to know what games make use of what buttons and such. Currently games do not announce those in any way, so one would have to collect them manually. On the joystick side its easier, since via USB/HID you can already get a good enough idea of what a joystick looks like, you would just need to cleanup for exotic cases.
The input issue aside there is of course other basic gaming stuff that is wrong, fullscreen switching for example is handled pretty differently in many applications, not only is the key different (F11, Alt-Enter, Ctrl-f,...), but also the behavior of fullscreen itself is different. Wine for example allows you to freely move the fullscreen window around and switch workspaces, while many games grab your mouse and keyboard input completly and don't allow you to switch to a different workspace.
Slashdot Mirror
3. If you have important data that if not written to the hard drive will cause catastrophic failure, then you use the part of the API that forces that write.
You completly missed the point. The new data isn't important, it could be lost and nobody would care. The troublesome part is that you lose the old data too. If you would lose the last 5 minutes of changes in your KDE config that would be a non-issue, what however happens is that you not just lose the last few changes, but your complete config, it ends up as 0 byte files, which is a state that the filesystem never had.
fflush() has nothing to do with fsync(), all that fflush() does is flushing the user space file buffer to the kernel, it does nothing to move the data from the kernel to the actual drive.
First off, what we're talking about here is dealing with computer _crashes_, not standard operations.
Unclean shutdowns are a normal operation of a desktop computer, even Wii, PS3 and Xbox360 crash on a regular basis these days. You can be pretty free from crashes on a server that runs a very limited set of simple applications, but not on a desktop computer that runs the lastest 3D drivers and games. The computer doesn't even need to really crash, its enough when a game in fullscreen becomes unresponsive or the battery runs out of power. If a filesystem can't deal with that in a sane manner, its broken and has no place on a desktop system.
Of course, the things at fault are really the buggy applications.
Neither ANSI-C nor ISO-C++ provide any way to "fix" an application, fsync() isn't part of either language.
What the hell is up with that?
That has been the Unix way of doing things for a few decades.
My experience with XFS (Ubuntu 8.10, default kernel, wire cache disabled) was the polar opposite, I lost files on almost every single crash, I consider the filesystem completly unusable for desktop use were flanky OpenGL drivers are rather common. Never lost files on crash with any other filesystem, except those very early versions of reiserfs back then years ago, but those issues got fixed and loss was the rare exception, not common occurrence as with XFS.
Quite true, its not just that they cheat a bit in there doing, its also that the overall structure of the game cheats, a lot. Most of the times for examples enemies and friendly character will not shoot at each other, they will stand there and shoot, but never actually hit anything, unless you go there and shoot a bit of yourself and trigger a script that will make your friends move forward. In most FPS you can just walk away from the fight, admire the scenery and neither friend nor foe will ever came to chase you down, they will happily wait with making war till you are back. Another huge annoyances are respawning enemies that just pop up out of thin air till you trigger some script to stop them.
Storytelling, from the sublime elegance of System Shock 2's logbooks to MGS4's split-screen-cut-scene absurdities, has advanced tremendously
For one thing, System Shock 1 is a a 15 years old. For another, storytelling really hasn't advanced much at all, for most part it has taken many steps back. Sure, MGS4 has insanely long and pretty cutscenes, but those things are cutscenes, not gameplay. The disconnect between story and actual gameplay is still as bad as it was a decade ago, if not worse, since dynamic scenarios such as seen in XCom:Ufo or EF2000 have pretty much disappeared and replaced by much more linear structure in most games. And of course the whole adventure game genre mostly disappeared, meaning storytelling has been replaced by linear narrative with little or no player influence and of course the whole humour got lost on the way, since you can't really do a Monkey Island FPS.
Now given, not all is bad, Mass Effect did some interesting things, Fahrenheit made some interesting leaps in interactive storytelling and Heavy Rain will surely bring something new to the table as well and we had Ico and SotC. But in the end there is a reason why people often refer to Planscape Tourment or The Longest Journey when it comes to storytelling in games, those games did what they did extremely well and nobody has yet managed to cram that much good story into a current day 3D game. The simplicity that those games had and the freedom they offered the writer, seems to have been lost in todays high-tech games.
Let me introduce you to the Wii Zapper.
The Wiimote is rather troublesome for FPS, since they have yet to figure out a proper way to actually turn your character. The whole 'move cursor to edge of screen' is really awkward and makes both turning and aiming troublesome. Even as straight lightgun replament it isn't good, because it lacks proper line of sight aiming, which is why you get a cursor in all games.
There was no internet.
The internet was very well alive back then, its after all where I got most of my N64 infos from. There also was Quake. Online on console wasn't yet practical, but a few exotic devices existed for SNES and Genesis that made use of one form of online or another (Satellaview, Sega Meganet). On the Amiga you had modem support in a few games.
which made playing in anything but ideal conditions nigh impossible
Well, back then you had the choice, either go GameGear or Lynx and get color and backlight or go GameBoy and get a decent battery life.
When it comes to games not much has really changed, sure graphics got prettier and the whole multiplayer stuff, but that are more of incremental improvements then completly new concepts. Even the whole 'user created content' thing isn't all that new, I used to build levels for Boulder Dash on the C64 and then later for Doom.
As impressive the progress in hardware is, the progress in software is much slower and is mostly just a slow refinement of existing concepts instep of something truly new.
Unix systems have sane defaults, that usually represent some form of DENY ALL.
That's only really true for your single-user desktop installation, as soon as you want to build up a network of dozens or hundreds of computers you are pretty much on your own again, since then you have to figure out how you want to share directories, user accounts and all that stuff, which isn't solved with a simple "apt-get install ...". A simple tasks such as sharing directories already becomes complicated, since NFS for example is pretty insecure by default, and there are plenty of more things that can go wrong when trying to manage a larger network.
But, its growth is linear to the number of primitives
Is that much of a problem when the hardware gets faster at exponential rates?
The whole problem I have with all this raytracing buzz is that so far, it hasn't produced even a single game or realistic tech demo (no, Quake4 with shiny spheres added doesn't cut it).
Todays games haven't been plain rasterizers for a long time, thanks to shaders and all the post processing they allow, yet when raytracing and rasterization is compared always the most basic form of the algorithms is compared and not what is used in the real world. If raytracing wants to look better then todays games it has to offer a lot more then just what plain raytracing does, since while hard shadows and reflections might be nifty, they are ultimativly rather useless, since they either can be faked easily or are already out of date (Crysis has realtime ambient occlusion, soft shadows, etc.). Now raytracing can certainly do more then that, but when you throw all the other stuff in the simple 'raytracing can do more polygons then rasterization' just isn't really a proper measurement anymore.
The Linux kernal and other big projects prove that large, complex projects can be accomplished under the FOSS model.
Not really, if you look around in the Free Software world you have a handful of large large Free Software projects that work good and can compete with commercial ones. The trouble is that its a tiny handful, the commercial game industry on the other side had to produces hundreds of high quality games in the same time to keep gamers busy. A good kernel can last you for decades, a good game on the other side lasts for a few month and then people want something new.
Given the right leadership and drive, I would really like to see an MMO spring up around an unlicenced universe
There is Worldforge, which has been around for a decade and yet to produce anything that is actually playable. The stop from proof of concept to actual game is a very tricky one and well, leadership is of course also an issue, Worldforge Uclient was already quite close to something like Ultima Online many years ago, but then things got ruined by some conflict between developers.
Where are games that break the moulds the way XCom, Syndicate, System Shock and Bioforge did?
The trouble is that its close to impossible to do anything original in Free Software, since when you go original, how do you convince your co-developers? Instead of working on an unproven idea, most people prefer to work on something which they know they will like. Which is why most successful FOSS games, or heck, most FOSS software projects in general, are clones of well known commercial titles. The reason why Linux got successful is because it was not original, people knew it was a Unix clone and they liked Unix, so they joined. Original stuff on the other side, like Hurd, has a much much harder time to get any traction.
Another problem of FOSS gaming is that its hard to keep the vision stable and consistent over time, developers join and leave all the time, so even if all their individual work might be good or even great, the end result can often be a completly disconnected mess.
In the end I don't expect FOSS gaming to make any large jumps any time soon, on the positive side however a large part of the FOSS gaming comes from actually developing them, so I recommend that anybody who wants to see things move forward, just joins one of the already existing projects.
Did that fix ever make it into Ubuntu? Since XFS on my Ubuntu 8.10 box trashed files on each and every single crash, completly unusable for desktop use.
But the documentation says, as sad as i am, that it is impossible to write a program in ANSI C which can determine at any point during it's runtime whether a specific file was written to the disk.
So we should all just happily accept it that the filesystem shreds our files? I don't think so, I'd chose a filesystem that doesn't produce this behaviour.
because someone decided that it is "reasonable" to fsync them at funny places.
The implement a "I am ok with file shredding" flag as mount option or whatever. A filesystem should be save by default, not tuned for max performance at the cost of file safety.
Not to implement something not specified is *not* a bug.
Its not a bug, its a feature... yeah, we used that to ridicule Microsoft. There is nothing in POSIX that says you *have to* shred the users file, older filesystems like ext3 or reiserfs did not have those problems. If ext4 now has them, its ext4 faults and nobody else. Pointing to the spec isn't an excuse for creating an broken filesystem, since in the real world its important that it works, not that its 'ok' by some funky interpretation of the spec.
should it be an fsync or an fdatasync?
I don't care, give me an implementation that works properly with ANSI-C and I am happy, everything else I consider broken.
But the documentation says, as sad as i am, that it is impossible to write a program in ANSI C which can determine at any point during it's runtime whether a specific file was written to the disk.
But that's not the fault of the ANSI-C standard, it is the fault of the implementation, since it would be perfectly free to do an fsync() on a fclose() and thus work as expected.
besides that new FS should be taken with care if you dont need them.
The troublesome part with this whole mess is that, so far, it is not considered a bug.
Another big thing in games are sound effects and music.
Music is pretty easy compared to the rest, since there are tons of musicians around that produce music under Creative Commons licenses, its quite easy to get those hop onto an Open Source project or just recycle their work if it fits. Sound effects on the other side are pretty hard, because that isn't exactly something people do just for the fun of it, you don't find sound effects community on the net like you find graphic artists and music communities. High quality sound effects also have the disadvantage that you might need expensive stuff to produce them, hard to capture the sound of a Ferrari or an AK-47 when you don't have one around. Last not least, sound effects are also extremely confusing in terms of license, you will find tons of "free" ones on the net or on CD collections, but pretty much never anything that is suitable for an Open Source project.
How would using the sync option differ from every program being implemented correctly and using fsync()? Wouldn't both of them just result in 'dog-slow'?
There are two problems here, the first one is that fsync() is a POSIX function, some people however try to write ANSI-C or ISO-C++ code, neither of those languages has fsync(). So this means that portable C/C++ code will behave incorrectly on Ext4, same is likely true for many other languages. That is something completly unacceptable. The other problem here is that hiding behind the standard is just stupid, just because the standard doesn't forbid the worst possible outcome, doesn't mean its ok to just allow it. From a good implementation I expect that it handles the those edgecases of a standard sanely and not just starts destroying data.
Now I haven't tried Ext4, so no idea how bad the problem is there, but I tried XFS and that was completly unusable, after almost every crash I lost files, gconf, rhythmbox, Wine config and plenty more ended up with a size of 0. That is not sane behavior, thats completly ridiculous insane shit.
What about C99 (FILE, fopen, fclose, ...) or ISO-C++ (std::ofstream)?
*No* modern, desktop-usable file systems today guarantee new files to be there if the power goes out
They might not guarantee it 100%, but some at least are still pretty good as keeping your files save, while other are completly unusable piles of garbage, unfit for desktop use. Little anecdote, I never lost a single file due to crash on reiserfs or ext3 in a decade, yet after I switched to XFS I lost files on the *first* day and after almost every crash after that (mostly gconf files and Wine registry got nullified). Completely unusable.
Unlike a server, desktop systems have the tendency to run unstable graphics driver or being laptops that run out of battery. So crashes are quite common on desktop systems and something a file system has to deal with, not just ignore and delete the users files.
If you think punishment of any form is not a deterrent
He isn't saying that punishment has no effect, he says that harsher punishment has no effect. People might reason about getting captured by police, but they don't reason about getting 5 instead of 3 years in jail when commiting their act. If you want to stop future crime you have to fix the underlying causes in society, which of course most of the time isn't that simple or easy.
A lot of good science fiction does this. Authors are entitled to expect the reader (or player) to do some imaginative legwork.
The problem I had with Halo is that I could never shake the feeling that there was much more interesting stuff going on somewhere else then the stuff I was forced to play. The story around Master Chief did never really do anything that was very interesting and the whole flood thing was just annoying and out of place, I guess thats what you get when you player as the indestructible hero instead of a human being. Now at least with Halo you later got comics and books and stuff, so there actually is more going on, to bad that none of that ever made it into the games.
Half Life on the other side has the G-Men, which sadly just feels like a walking deus ex machina with legs. You never get a satisfying conclusion or backstory or anything. You play a clueless character who saves the earth by accident and nothing ever feels like an accomplishment, because you just stumble around in the world shooting dudes. Half the story of Half Life 2 is just transporter malfunction and then having to manually walk the way by foot, not exactly great storytelling.
That said, when it comes to video games I don't think overtelling a story is a problem, I think quite the opposite is true, most games these days try to avoid explain anything. Thanks to the first person view you are quite often limited to exactly that which you see through the main characters eyes, which sadly just isn't much. So instead of story, you simply get a few sad piece and pretty graphics thrown at you, maybe with a little dialog thrown in to connect things. Its kind of ridiculous when one looks back, the first 10 minutes of story and dialog in Monkey Island have more variety and interesting stuff going on then most todays games manage to cram into 10 hours.
I'm guessing that 'most' households with a game system have a USB keyboard and mouse laying around somewhere.
But most don't have a table around that they can put those on to play comfortably. There is also the issue that implementing a mouse/keyboard interface costs time and money, since now you have two interfaces to worry about. In the end its however simply the issue of "because Microsoft said so", thats what you get with a closed game platform, what you gain in standardization and ease of use, you lose in flexibility. Sony on the PS3 allows keyboard and mouse, but still, very few games make use of it (Unreal3 is the only one I can think of).
The real problem however starts long before keyboard and mouse. Why do an RTS game in the first place? Why clone something that was developed for different hardware and different input devices and that hasn't changed in 15 years, why not do something original instead that fits the hardware you have at hand. Full Spectrum Warrior for example was a great real-time tactics game that played great with a controller, merge that with some of the depths of XCom:UFO, throw in a bunch of new ideas and you could have a kick ass game that would be quite different from almost anything out there today.
Game developers have sadly started to think way to much in genres, instead of thinking about what would be the best gameplay to fit the story and settings, they take a predefined and done to death genre and paint it with a new theme.
Excel is certainly not your average programming language, but it can be used for programming. There are even some that have used it to write a 3D renderer in it.
Yep, thats not so far away from what I have in mind with my inputdrv app and for most part such a thing would be quite doable. There are however a few practical problems, one important one is that I don't think there is currently a clean way to reassign joystick ids, so if you plug in another joysticks or load a virtual driver for the remapping it will always be /dev/input/js2, while the game is using just js1, other then messing around with mv/ln/rm I don't know any way to actually get the device in the right place. Its not a unsolvable problem, but the workarounds are all rather ugly.
Another issue is the loading of the configurable driver must happen before the game itself, since each game needs its own configuration and because you can't change the configuration after the game is loaded. Their might be ways to accomplish this, but I haven' really looked into it. A little wrapper script done by the user would of course fix the problem, but again, that would be more a workaround then a solution.
Last problem of course is that you need to collect lots of data, you need to know what games make use of what buttons and such. Currently games do not announce those in any way, so one would have to collect them manually. On the joystick side its easier, since via USB/HID you can already get a good enough idea of what a joystick looks like, you would just need to cleanup for exotic cases.
The input issue aside there is of course other basic gaming stuff that is wrong, fullscreen switching for example is handled pretty differently in many applications, not only is the key different (F11, Alt-Enter, Ctrl-f, ...), but also the behavior of fullscreen itself is different. Wine for example allows you to freely move the fullscreen window around and switch workspaces, while many games grab your mouse and keyboard input completly and don't allow you to switch to a different workspace.
I just noticed that freedesktop.org actually has a mailing list for gaming related issues probably time to move things there.