You'll have to define dumbing down for me. Do you mean gameplay or more likely, just control changes.
There are basically two problems. One is simply lack of proper controls, a control scheme that works well with a gamepad is a different then one that works well with a mouse and quite frequently it has happened that developers only did a console style controls without adapting it properly to the PC resulting in an awkward experience. Same is of course also true in the other direction, a PC port to console does often not work very well. The issue of controls of course blends into gameplay and balancing as well (mouse aims more exact, so enemy formations that work on console can be boring on PC).
The second issue is one of attention span, console games are designed for shorter attention spans on average, so they tend to be simpler then PC games. This is much less visible today then it was 10 years ago, because we have so many cross platform titles these days and most of the complex PC genres have died out or at least fallen out of mainstream long ago, most prominent examples are the flightsims, but there are also point&click adventures and western RPGs.
A SCM in the most basic sense is for recording past versions of a file and you want that for your data just as you want it for text. Diffing and merging is more difficult with binary, but not impossible, especially when done manually. In the most basic sense you simply want to know if and when a file has changed and that works for binary just fine.
On a more practical level when you have multiple developers you also want to track who modified which file and of course give people access to a shared repository, a SCM does exactly that, a plain file storage would be much more problematic.
I don't see why you'd keep a film project in a SCM
For the same reason you keep source in SCM.
SCMs won't track them very well.
Centralized SCM do quite fine, Git on the other side does rather horrible since it forces you to checkout the complete history of the project, not so much a problem with text files, but a huge issue with binary blobs, which don't diff well and thus don't compress. A 'git clone' can easily get 10 times as large as a 'svn checkout' for a project with lots of binary stuff.
It will take some more time to bridge that gap, but I do see this coming.
I don't. The reason why Mods work is because they are based on already successful and well known things, which for one thing limits your workload a lot, since you already have an engine, level editors, level designs, textures, physics, weapons and items that you can reuse. But even more importantly Mods allow you to share a common goal very easily, you can say "I want to recreate Half Life 1 on Source Engine" and everybody will know what the goal is and many will happily join you. If you are doing it completly FOSS style on the other side you not only have little or none of the tools, but you also have no common goal, hardly anybody is interested in joining your "fully original first person game" because they have no idea what the goals are and you can't explain it to them either, because nobody will bother reading your hundred pages of design document, in case you even bother to write it. So you end up being stuck with no tools and no contributors and in the end no game of course. And that is not even considering that many artist can be pretty troublesome to deal with, since they don't like other people meddling with their work and thus refuse a FOSS license.
/opt is just a random directory and tells you nothing about how you should build your software, how you should package it, how you should resolve dependencies, how to install mime-types and whatever, which is why every third party software invents its own little hacks to get stuff working across distributions.
Second item...pick one desktop. GNOME, KDE...whatever. Just pick one.
The desktop itself isn't really the problem, in fact its good that we have choice there. What you want to keep standardized is the underlying infrastructure, communication between application, copy&paste and all that stuff so that applications can stay compatible and luckily that is already happening. Now what is a little annoying is that there are still two GUI toolkits, which seems rather unnecessary.
Until the community comes together and makes some basic decisions like.tar.gz,.rpm,.deb,.pkg, etc. then how can we possibly expect development houses to even give serious consideration?
The package format is totally unimportant. Making Redhat use.deb or Ubuntu use.rpm would fix absolutely nothing, since the distributions would still be as incompatible to each other as ever. The problem is the underlying dependency tree not the way in which you package the software, said dependency tree is what makes it impossible to install software outside of that tree (i.e. installing Ubuntu7 deb on Ubuntu8 doesn't work, since the dependency tree is a different one).
To fix this issue you would first need to get rid of the dependencies, but to do that you would need a large enough and stable enough core system on which applications could depend instead, but given how Linux development works its not clear if that is ever going to happen or even desirable.
There are however two things I really miss:
* a standard way to ship or even just build third party software that will work across distributions
* a way to install two different versions of the same piece of software
The first problem is somewhat tackled by things like autopackage and LSB, but it still feels more like multiple layers of ducttape instead of a robust solution. The second problem is a direct consequence of stuffing everything into/usr/bin/, which makes it impossible to have two different versions of the same package, a workaround is of course two just build the software yourself to a different --prefix, but it would be nice if distributions had such a feature build in instead of forcing the user to completly bypass anything the distribution provides.
The vast majority of Linux distributions each are trying to achieve something different.
The vast majority of Linux distributions are trying to do exact same thing, namely package third party software in an easy installable way and provide a proper base configuration in addition. Thats really all they do and there is really no good reason why that work should be duplicated dozens of times. Now of course its totally valid to have different lines of a distribution, like one with a default install for servers and one with a default installs for desktop. However none of that requires a new distribution, it just requires a different package list that gets installed by default, nothing more.
Choice is important for the software, not for the framework in which that software is distributed, since different ways to distribute the software just lower the choice you have in actually installing it due to incompatibility between different distribution schemes.
From a plain practical point of view I don't really care about proprietary blob or not, not because the later one wouldn't be nice, but because the problem most often starts much earlier. Just finding compatible hardware is already the biggest problem, since companies tend to label their stuff by weird and useless names, that give you no hint if its Linux compatible or not, because quite often the name stays the same, but the underlying chipsets changes. For a start I would already be very happy if hardware companies would label their devices properly and simply let you know if they are Linux compatible or not, many already are, but often you only find that out after you plug the stuff in.
For the exact details you have to look at the motion blur algorithm used in a specific game. Anyway, the general idea is that you know the motion vectors of all objects in the game, then you take a shader and render all those motion vectors for each pixel into a seperate buffer. Then you render the picture as usual in an unblurred way and then apply a blur effect that takes the motion vectors of each pixel into account. So you can blur different objects by different factors, since you have motion data for every pixel.
Oh, and I have to correct myself, there actually are games that do motion blur by overlapping frames, when I remember correctly that effect was used in some PS1 games such as MetalGear. However today with shaders one has more flexibility and can go the above route.
Games don't do motion blur by just bluring two frames over each other (which would be rather awful), but by recording the velocity vector of a pixel and bluring that pixel with it as post processing effect, i.e. you need only a single frame and a bit more GPU power for the effect. Not all new games do that, but quite a few.
However there are TVs that interpolate inbetween frames, like Sony's 200Hz Motionflow, which takes a regular 25Hz input signal and then calculates the inbetweens to fill it up to 200Hz. There is similar stuff from other companies too.
One however has to be careful with that. In games like Contra or similar games using 3D models instead of sprites can make the collision detection pretty unpredictable and using 3D backdrops in combination with 2D gameplay can often feel very restrictive and unnatural, something that you don't get with classic 2D sprites. Of course much of that trouble can be avoided when handled with care, but I have seen quite a few 2D games with 3D sprites that I would have preferred with 2D sprites instead.
Along the same lines, I'd say that Super Mario 3 was better than the Super Mario for the N64,
I disagree. Not because Mario64 is better, but because *both* are damn good. The thing to realize is simply that 2D isn't 3D and visa verse. You can't really do 3D gameplay in 2D and neiher can you do 2D gameplay in 3D (well, you can, but it will most often feel ugly and restrictive). None of them is better then the other, they are simply very different forms of gameplay, with 2D being much better for clearer graphics and straight forward gameplay, while 3D is better for more complicated exploration orientated stuff.
The annoying thing is that almost all developers see 3D a a 'must have', so you see close to zero 2D games on the big consoles, the DS still gets some, but even there 2D is slowly dieing out for no good reasons, on the PSP its already as good as dead. I just wish that there was more stuff like Braid or Wario Land: Shake It!.
I haven't played Oblivion, but as far as I know the terrain is all heightmap based. I think a large part of the boringness of the terrain is a direct result from that and not so much the procedural nature itself. A heightmap doesn't allow sudden changed in elevation and neither does it allow overhangs, so all the basic terrain looks pretty smooth and uninteresting and also pretty much all the same. Gothic2 is one of the few games I have seen with real 3D terrain, you have overhangs, cliffs, valleys and mountains and stuff without any of the smoothness that you get from a heightmap, which makes the terrain much more interesting and unique. Now Gothic2 isn't procedural from what I know, but it demonstrates nicely the different between a heightmap based terrain and a real 3d terrain.
In the long run I think there isn't much way around procedural content, sooner or later I want a GTA type game where I can enter each and every building and that isn't ever going to happen with completly handcrafted content. Some pieces like a satirical advertisment billboard will still need to be handcrafted of course, but a lot of things are procedural by nature (rust, decay, grows of plants, destruction, etc.) and thus its just natural to simulate them automatically via software instead of using an artist to create them.
You're making the presumption that a hierarchal is the best way to organize data.
My point is that if you want to exchange data with another computer you have quite a problem with the OLPC, because its whole interface is build pretty much ignoring what the rest of the world does, so you don't have much backward compatibility build in and you can also not just install a random Linux application and use it properly with the interface. The good old Terminal is still there and thus you can work around lots of issues, but interoperability with other non-OLPC machines is certainly not the OLPCs strength.
In the end, the person entering the program should be doing this either for charity or to satisfy their curiosity.
And thats exactly the problem, they should be focused on getting the thing into mass production (maybe with a few tweaks to be more fit for western customers) instead of making it a charity-only product and thus keeping the volume down. The whole thing feels like "to little, to late", a year ago the OLPC at $200 would have been a great machine, today at $200 its still a pretty nice one, but at $400 its just to much to be competitive. That said, I am still happy that there finally is a way to get the thing again.
Its the other way around, the Eee is 0.9kg, while the XO-1 is 1.5kg and that is actually quite heavy when you try to hold the thing in ebook mode for longer periods of time.
The LCD in a normal room-lit situation with backlight on isn't really all that pretty, the resolution is ok, but its heavily depended on the viewing angle, which can annoy quite a bit, due to the pixel layout it also has a diagonal grid all over it, which can irritate. In sunlight its a different thing of course, resolution is great and its very readable, not quite ePaper-like, but close enough, the viewing angle problem and the diagonal grid disappear when not backlit.
The OS on the other side isn't really all that great. The basic concepts are overall nice, but its still far from unfinished and feels like an early beta more then a finished product. It also lacks support for almost anything that you would expect from a "normal OS", you don't even have a normal file system unless you go to the Terminal and bypass all the UI. Its also not very fast and the battery life is rather crappy, you get 3 hours out of it and thats it. The hardware does have some interesting power saving features which might help with that a bit in the future, but its still not finished and was disabled by default the last time I checked. The software still isn't quite up to all the cool features that you heard in talks two years ago.
All that said, its still a great little machine, but $400 its quite a bit of money and you can get better hardware for that.
You get one choice that looks like a computer, windows and menus and the like; and you get one choice that looks like nothing you've ever seen,
Have you actually used Sugar? The difference between Sugar and Windows is really no different then between Gnome and Windows or KDE and Windows or any other GUI. Sugar really only has two main differences to a normal GUI: every application is started in fullscreen (just like on lots of PDA, mobile phones, etc.) and you don't have a normal filesystem, instead you get a Journal which really is not much different from Gnomes Beagle or other desktop search applications. Other then that its really just cosmetic, they call their applications Activities, their taskbar is called Frame and instead of text menus you have large icons.
Where Sugar fails isn't in the interface, even if that still has more then a few rough edges, but in backward compatibility. Sugar can run Sugar application and little else. X11 applications will still work, as long as they only need a single window, but there doesn't seems to be a clear way how one would easily integrate them into Sugar.
Believe me, you get used to the parens very quickly.
The problems aren't the parenthesis, the problem is the lack of advanced syntax. Everything in Lisps looks the same, no matter if its a function, a macro, an assignment, a piece of data or whatever. It is impossible to tell what a piece of code does from the structure alone, because everything looks the same. And no, time won't help, I have spend plenty of time with Scheme and the only thing I have learned is that its today just as annoying on day one.
There is a reason why Python, Ruby, etc. are popular and Lisp not so much and that reason is in large part its syntax.
Seriously, if you give yourself the change to wrap your head around it, s-expressions are both elegant and powerful.
Elegant and powerful? Sure. But Readable? No way.
I like S-Expressions as XML replacement a lot, since for representing simple structured data its quite nice. But it just doesn't lead to very readable code when it comes to programming, even after some years toying around with Scheme, I still find "a = 5 + b" a hell of a lot more readable then "(set! a (+ 5 b))". The first paints a visual picture with clear symbols, the other is just token soup, it might be easy to parse for a computer, but very definitvly not for a human. Array access and a lot of other basic stuff is just a total mess in s-expressions.
If the processor is only going to check whether something is zero or not, why enforce that a given number is _precisely_ one or zero?
Because it expresses much more precisely what you intend to do. Having a "bool is_visible()" in a GUI toolkit makes sense, having a "int is_visible()" not so much, which is why everybody ends up doing macro hacks of BOOL, gboolean and whatever. Lack of basic features in a language just leads to lots of hacking around to get those features into the language down the line, its simply annoying.
If the market wanted such games it would demand them and pay for them, you are in an extreme minority IMHO.
Isn't 'The Sims' kind of like the best selling PC game ever and before that wasn't Myst right at the top? SimCity, Roller Coaster Tycoon and a whole bunch of other non-violent games seem to sell pretty and the Wii also still is selling quite nicely. There definitively seems to be a huge demand for non-violent stuff. The only trouble of course is that morphing those games into MMO isn't an easy task and especially not a well tested, since you can't just clone WoW and get good results. But you still get stuff like LittleBigPlanet, which is in large part non-violent and has plenty of cooperative elements and is all online enabled and it seems to be selling quite fine. So 'extreme minority', not so much.
Ppl just say games have gone down hill cos they either don't get new games or they find them too difficult.
Except of course that todays games are far easier then games of the past. Games todays have grown in complexity, not difficulty, no longer is left/right and jump going to do much, now you need at least two analogsticks and a dozen buttons to get anything done. Those people that can handle that have little problems making it through all of todays games and well, those that get irritated by it won't even start playing those games.
Games nowadays let you do or become anything you want!
Well, yeah, as long as you want to be a muscular marine with lots of guns... Games were you solve your problems without the use of guns are extremely rare these days and no, Tetris doesn't count. That of course doesn't mean that there is anything wrong with guns, but a little change of pace would be nice every now and then.
And while at the topic of guns and weapons, one thing I found quite disturbing is that most PS3 games I have played so far involved the execution of unarmed men (GTAIV, CoD4, AssassinsCreed, Uncharted). I don't mind much fighting of an alien invasion, but being forced to do things that I don't like in games starts to get a little annoying.
Slashdot Mirror
You'll have to define dumbing down for me. Do you mean gameplay or more likely, just control changes.
There are basically two problems. One is simply lack of proper controls, a control scheme that works well with a gamepad is a different then one that works well with a mouse and quite frequently it has happened that developers only did a console style controls without adapting it properly to the PC resulting in an awkward experience. Same is of course also true in the other direction, a PC port to console does often not work very well. The issue of controls of course blends into gameplay and balancing as well (mouse aims more exact, so enemy formations that work on console can be boring on PC).
The second issue is one of attention span, console games are designed for shorter attention spans on average, so they tend to be simpler then PC games. This is much less visible today then it was 10 years ago, because we have so many cross platform titles these days and most of the complex PC genres have died out or at least fallen out of mainstream long ago, most prominent examples are the flightsims, but there are also point&click adventures and western RPGs.
A SCM in the most basic sense is for recording past versions of a file and you want that for your data just as you want it for text. Diffing and merging is more difficult with binary, but not impossible, especially when done manually. In the most basic sense you simply want to know if and when a file has changed and that works for binary just fine.
On a more practical level when you have multiple developers you also want to track who modified which file and of course give people access to a shared repository, a SCM does exactly that, a plain file storage would be much more problematic.
I don't see why you'd keep a film project in a SCM
For the same reason you keep source in SCM.
SCMs won't track them very well.
Centralized SCM do quite fine, Git on the other side does rather horrible since it forces you to checkout the complete history of the project, not so much a problem with text files, but a huge issue with binary blobs, which don't diff well and thus don't compress. A 'git clone' can easily get 10 times as large as a 'svn checkout' for a project with lots of binary stuff.
It will take some more time to bridge that gap, but I do see this coming.
I don't. The reason why Mods work is because they are based on already successful and well known things, which for one thing limits your workload a lot, since you already have an engine, level editors, level designs, textures, physics, weapons and items that you can reuse. But even more importantly Mods allow you to share a common goal very easily, you can say "I want to recreate Half Life 1 on Source Engine" and everybody will know what the goal is and many will happily join you. If you are doing it completly FOSS style on the other side you not only have little or none of the tools, but you also have no common goal, hardly anybody is interested in joining your "fully original first person game" because they have no idea what the goals are and you can't explain it to them either, because nobody will bother reading your hundred pages of design document, in case you even bother to write it. So you end up being stuck with no tools and no contributors and in the end no game of course. And that is not even considering that many artist can be pretty troublesome to deal with, since they don't like other people meddling with their work and thus refuse a FOSS license.
/opt is just a random directory and tells you nothing about how you should build your software, how you should package it, how you should resolve dependencies, how to install mime-types and whatever, which is why every third party software invents its own little hacks to get stuff working across distributions.
Second item...pick one desktop. GNOME, KDE...whatever. Just pick one.
The desktop itself isn't really the problem, in fact its good that we have choice there. What you want to keep standardized is the underlying infrastructure, communication between application, copy&paste and all that stuff so that applications can stay compatible and luckily that is already happening. Now what is a little annoying is that there are still two GUI toolkits, which seems rather unnecessary.
Until the community comes together and makes some basic decisions like .tar.gz, .rpm, .deb, .pkg, etc. then how can we possibly expect development houses to even give serious consideration?
The package format is totally unimportant. Making Redhat use .deb or Ubuntu use .rpm would fix absolutely nothing, since the distributions would still be as incompatible to each other as ever. The problem is the underlying dependency tree not the way in which you package the software, said dependency tree is what makes it impossible to install software outside of that tree (i.e. installing Ubuntu7 deb on Ubuntu8 doesn't work, since the dependency tree is a different one).
To fix this issue you would first need to get rid of the dependencies, but to do that you would need a large enough and stable enough core system on which applications could depend instead, but given how Linux development works its not clear if that is ever going to happen or even desirable.
There are however two things I really miss:
* a standard way to ship or even just build third party software that will work across distributions
* a way to install two different versions of the same piece of software
The first problem is somewhat tackled by things like autopackage and LSB, but it still feels more like multiple layers of ducttape instead of a robust solution. The second problem is a direct consequence of stuffing everything into /usr/bin/, which makes it impossible to have two different versions of the same package, a workaround is of course two just build the software yourself to a different --prefix, but it would be nice if distributions had such a feature build in instead of forcing the user to completly bypass anything the distribution provides.
The vast majority of Linux distributions each are trying to achieve something different.
The vast majority of Linux distributions are trying to do exact same thing, namely package third party software in an easy installable way and provide a proper base configuration in addition. Thats really all they do and there is really no good reason why that work should be duplicated dozens of times. Now of course its totally valid to have different lines of a distribution, like one with a default install for servers and one with a default installs for desktop. However none of that requires a new distribution, it just requires a different package list that gets installed by default, nothing more.
Choice is important for the software, not for the framework in which that software is distributed, since different ways to distribute the software just lower the choice you have in actually installing it due to incompatibility between different distribution schemes.
From a plain practical point of view I don't really care about proprietary blob or not, not because the later one wouldn't be nice, but because the problem most often starts much earlier. Just finding compatible hardware is already the biggest problem, since companies tend to label their stuff by weird and useless names, that give you no hint if its Linux compatible or not, because quite often the name stays the same, but the underlying chipsets changes. For a start I would already be very happy if hardware companies would label their devices properly and simply let you know if they are Linux compatible or not, many already are, but often you only find that out after you plug the stuff in.
For the exact details you have to look at the motion blur algorithm used in a specific game. Anyway, the general idea is that you know the motion vectors of all objects in the game, then you take a shader and render all those motion vectors for each pixel into a seperate buffer. Then you render the picture as usual in an unblurred way and then apply a blur effect that takes the motion vectors of each pixel into account. So you can blur different objects by different factors, since you have motion data for every pixel.
Oh, and I have to correct myself, there actually are games that do motion blur by overlapping frames, when I remember correctly that effect was used in some PS1 games such as MetalGear. However today with shaders one has more flexibility and can go the above route.
Games don't do motion blur by just bluring two frames over each other (which would be rather awful), but by recording the velocity vector of a pixel and bluring that pixel with it as post processing effect, i.e. you need only a single frame and a bit more GPU power for the effect. Not all new games do that, but quite a few.
However there are TVs that interpolate inbetween frames, like Sony's 200Hz Motionflow, which takes a regular 25Hz input signal and then calculates the inbetweens to fill it up to 200Hz. There is similar stuff from other companies too.
If you really want something new, $400 will get you a new OLPC on Amazon, they're rugged enough for a 2 year old.
The OLPC is for school children, it is not build for 2 year old.
Incorrect, South Park is for most part 2D vector graphics.
One however has to be careful with that. In games like Contra or similar games using 3D models instead of sprites can make the collision detection pretty unpredictable and using 3D backdrops in combination with 2D gameplay can often feel very restrictive and unnatural, something that you don't get with classic 2D sprites. Of course much of that trouble can be avoided when handled with care, but I have seen quite a few 2D games with 3D sprites that I would have preferred with 2D sprites instead.
Along the same lines, I'd say that Super Mario 3 was better than the Super Mario for the N64,
I disagree. Not because Mario64 is better, but because *both* are damn good. The thing to realize is simply that 2D isn't 3D and visa verse. You can't really do 3D gameplay in 2D and neiher can you do 2D gameplay in 3D (well, you can, but it will most often feel ugly and restrictive). None of them is better then the other, they are simply very different forms of gameplay, with 2D being much better for clearer graphics and straight forward gameplay, while 3D is better for more complicated exploration orientated stuff.
The annoying thing is that almost all developers see 3D a a 'must have', so you see close to zero 2D games on the big consoles, the DS still gets some, but even there 2D is slowly dieing out for no good reasons, on the PSP its already as good as dead. I just wish that there was more stuff like Braid or Wario Land: Shake It!.
I haven't played Oblivion, but as far as I know the terrain is all heightmap based. I think a large part of the boringness of the terrain is a direct result from that and not so much the procedural nature itself. A heightmap doesn't allow sudden changed in elevation and neither does it allow overhangs, so all the basic terrain looks pretty smooth and uninteresting and also pretty much all the same. Gothic2 is one of the few games I have seen with real 3D terrain, you have overhangs, cliffs, valleys and mountains and stuff without any of the smoothness that you get from a heightmap, which makes the terrain much more interesting and unique. Now Gothic2 isn't procedural from what I know, but it demonstrates nicely the different between a heightmap based terrain and a real 3d terrain.
In the long run I think there isn't much way around procedural content, sooner or later I want a GTA type game where I can enter each and every building and that isn't ever going to happen with completly handcrafted content. Some pieces like a satirical advertisment billboard will still need to be handcrafted of course, but a lot of things are procedural by nature (rust, decay, grows of plants, destruction, etc.) and thus its just natural to simulate them automatically via software instead of using an artist to create them.
You're making the presumption that a hierarchal is the best way to organize data.
My point is that if you want to exchange data with another computer you have quite a problem with the OLPC, because its whole interface is build pretty much ignoring what the rest of the world does, so you don't have much backward compatibility build in and you can also not just install a random Linux application and use it properly with the interface. The good old Terminal is still there and thus you can work around lots of issues, but interoperability with other non-OLPC machines is certainly not the OLPCs strength.
In the end, the person entering the program should be doing this either for charity or to satisfy their curiosity.
And thats exactly the problem, they should be focused on getting the thing into mass production (maybe with a few tweaks to be more fit for western customers) instead of making it a charity-only product and thus keeping the volume down. The whole thing feels like "to little, to late", a year ago the OLPC at $200 would have been a great machine, today at $200 its still a pretty nice one, but at $400 its just to much to be competitive. That said, I am still happy that there finally is a way to get the thing again.
It is heavier
Its the other way around, the Eee is 0.9kg, while the XO-1 is 1.5kg and that is actually quite heavy when you try to hold the thing in ebook mode for longer periods of time.
The LCD in a normal room-lit situation with backlight on isn't really all that pretty, the resolution is ok, but its heavily depended on the viewing angle, which can annoy quite a bit, due to the pixel layout it also has a diagonal grid all over it, which can irritate. In sunlight its a different thing of course, resolution is great and its very readable, not quite ePaper-like, but close enough, the viewing angle problem and the diagonal grid disappear when not backlit.
The OS on the other side isn't really all that great. The basic concepts are overall nice, but its still far from unfinished and feels like an early beta more then a finished product. It also lacks support for almost anything that you would expect from a "normal OS", you don't even have a normal file system unless you go to the Terminal and bypass all the UI. Its also not very fast and the battery life is rather crappy, you get 3 hours out of it and thats it. The hardware does have some interesting power saving features which might help with that a bit in the future, but its still not finished and was disabled by default the last time I checked. The software still isn't quite up to all the cool features that you heard in talks two years ago.
All that said, its still a great little machine, but $400 its quite a bit of money and you can get better hardware for that.
You get one choice that looks like a computer, windows and menus and the like; and you get one choice that looks like nothing you've ever seen,
Have you actually used Sugar? The difference between Sugar and Windows is really no different then between Gnome and Windows or KDE and Windows or any other GUI. Sugar really only has two main differences to a normal GUI: every application is started in fullscreen (just like on lots of PDA, mobile phones, etc.) and you don't have a normal filesystem, instead you get a Journal which really is not much different from Gnomes Beagle or other desktop search applications. Other then that its really just cosmetic, they call their applications Activities, their taskbar is called Frame and instead of text menus you have large icons.
Where Sugar fails isn't in the interface, even if that still has more then a few rough edges, but in backward compatibility. Sugar can run Sugar application and little else. X11 applications will still work, as long as they only need a single window, but there doesn't seems to be a clear way how one would easily integrate them into Sugar.
Believe me, you get used to the parens very quickly.
The problems aren't the parenthesis, the problem is the lack of advanced syntax. Everything in Lisps looks the same, no matter if its a function, a macro, an assignment, a piece of data or whatever. It is impossible to tell what a piece of code does from the structure alone, because everything looks the same. And no, time won't help, I have spend plenty of time with Scheme and the only thing I have learned is that its today just as annoying on day one.
There is a reason why Python, Ruby, etc. are popular and Lisp not so much and that reason is in large part its syntax.
Seriously, if you give yourself the change to wrap your head around it, s-expressions are both elegant and powerful.
Elegant and powerful? Sure. But Readable? No way.
I like S-Expressions as XML replacement a lot, since for representing simple structured data its quite nice. But it just doesn't lead to very readable code when it comes to programming, even after some years toying around with Scheme, I still find "a = 5 + b" a hell of a lot more readable then "(set! a (+ 5 b))". The first paints a visual picture with clear symbols, the other is just token soup, it might be easy to parse for a computer, but very definitvly not for a human. Array access and a lot of other basic stuff is just a total mess in s-expressions.
If the processor is only going to check whether something is zero or not, why enforce that a given number is _precisely_ one or zero?
Because it expresses much more precisely what you intend to do. Having a "bool is_visible()" in a GUI toolkit makes sense, having a "int is_visible()" not so much, which is why everybody ends up doing macro hacks of BOOL, gboolean and whatever. Lack of basic features in a language just leads to lots of hacking around to get those features into the language down the line, its simply annoying.
If the market wanted such games it would demand them and pay for them, you are in an extreme minority IMHO.
Isn't 'The Sims' kind of like the best selling PC game ever and before that wasn't Myst right at the top? SimCity, Roller Coaster Tycoon and a whole bunch of other non-violent games seem to sell pretty and the Wii also still is selling quite nicely. There definitively seems to be a huge demand for non-violent stuff. The only trouble of course is that morphing those games into MMO isn't an easy task and especially not a well tested, since you can't just clone WoW and get good results. But you still get stuff like LittleBigPlanet, which is in large part non-violent and has plenty of cooperative elements and is all online enabled and it seems to be selling quite fine. So 'extreme minority', not so much.
Ppl just say games have gone down hill cos they either don't get new games or they find them too difficult.
Except of course that todays games are far easier then games of the past. Games todays have grown in complexity, not difficulty, no longer is left/right and jump going to do much, now you need at least two analogsticks and a dozen buttons to get anything done. Those people that can handle that have little problems making it through all of todays games and well, those that get irritated by it won't even start playing those games.
Games nowadays let you do or become anything you want!
Well, yeah, as long as you want to be a muscular marine with lots of guns... Games were you solve your problems without the use of guns are extremely rare these days and no, Tetris doesn't count. That of course doesn't mean that there is anything wrong with guns, but a little change of pace would be nice every now and then.
And while at the topic of guns and weapons, one thing I found quite disturbing is that most PS3 games I have played so far involved the execution of unarmed men (GTAIV, CoD4, AssassinsCreed, Uncharted). I don't mind much fighting of an alien invasion, but being forced to do things that I don't like in games starts to get a little annoying.