Two screens aren't much usefull for gaming. Sure there might be this or that nice idea that will provide nice new gameplay, but for the majority of games the second screen will just display the map or some other not much usefull information that could easily made available via the pause screen menu. Just one large screen would certainly be more usefull for most games.
The only thing that makes the second screen interesting is the touchscreen ability, however I doubt that it will be that much usefull for most games.
Last not least, the second screen looks like a waste, both screens are the same size, so the upper half of the DS just looks extremly empty, would have made much more sense to just make the second screen smaller, since for sure most games will use it only for secondary information, not for game critical stuff.
Aehm, well, how many Marios got rereleased for the GBA was it 4 or 5? And how many of them were new ones? Something around zero, rest was ports of SNES or even NES games. How about a Zelda? Well, again a SNES port. Ok, we got two new Metroids, but those were rather similar to Super Metroid, not necessarily a bad thing, however overall there hasn't been all that orginial ideas of Nintendo in the GBA area, just far to many rereleases of titels that already got rereleased in the times of the SNES (ie. MarioAllStars).
In general I agree that Nintendo is good for original ideas, but on the GBA they really havn't done much, 'Mario&Luigi Superstar Saga' would one of the few original ones that comes to mind and even that is 'just' a successor of MarioRPG.
Looking at the Nintendo DS the first few titles I have seen where a patched up Mario64, a MarioKart and MetroidPrime version, overall not all that original. Sure I hope that Nintendo will provide some cool stuff, but I fear that the whole DualScreen thing will just end up as a useless gadget that hardly any game will make much use off, as it happened with quite a few Nintendo gadgets before (GBPrinter, GBA link, 64DD, SNES Mouse).
Wondering if its easier to send humans to mars or just build a better robot. Its not like we had the space ship ready to send the humans to mars tomorrow, so there is still a lot of progress to be made when it comes to AI and robot development.
Afterall there are also things that robots can do that human can't, imagine sending hundreds of tiny and yeap robots all across the planet instead of just a bunch on humans on a single place, who of them will collect more valueable data? Or sending a large drill (to get some samples from deep down) instead of the whole life support needed for humans to Mars.
Last not least, there is also the money question, so far we only have send relativly cheap (at least compared to the cost of a human mission) robots to mars, how much better or more robots could we build when the money for a human mission would go instead to a robot one?
Not saying that human space flight is worthless, but when it comes to deep space explorations, we are probally not ready to do that in a cost effective manner.
1) There is Photoshop Elements which costs far less than the full version, not sure however how that exactly compares to Gimp. There are also other alternatives like CorelPhotoPaint, PaintShopPro, etc. which come either for 'free' (ie. you get them with your PC) or cost little money.
2) Lack of better brushes is my personal Nb.1 complain about Gimp, it really matters, especially when you have a graphic tablet (which often come with Photoshop and/or Painter). And its not even that there hasn't been tries to improve Gimps brush handling, see http://www.levien.com/gimp/wetdream.html However none of it seems to have found its way into the current Gimp, so Gimp2.0 still feels pretty much exactly like a Gimp1.0, which is kind of sad, given that between both releases there is half a decade of development time.
3) Most likly the user interface does cause FAR more throuble for Windows users than for Linux ones, which come with multiple workspaces at default, while Windows doesn't. Beside that the Windows version of Gimp has been rather unstable for quite a while, not sure how much better the current one is.
While yep, Gimp might be and good enough for Joe home user, most Windows people have access to better or equal alternatives. And well, on the Linux side you don't have much choice anyway, either you use Gimp or you DualBoot into Windows. Its just like with many free software projects, they might be good enough for almost everybody, but they simply aren't a lot better, which doesn't make it worth to switch.
Gimp never was a LISP library, far from it. Gimp used from the start SIOD, which isn't a Lisp, not even a Scheme, its some broken non-standard kind of Lisp dialect which is a major pain to work with (almost undebugable, error messages that don't tell you more then 'something went wrong', etc.). Beside that Gimp, isn't even much coupled with SIOD, it just comes with it at default, because SIOD source was small enough to get included into the Gimp one, so it didn't add a extra dependency. Gimp functions are exported via the PDB, which doesn't depend on a specific language. And that said, the SIOD bindings are pretty much the worst of all, in SIOD every function returns a list, no matter if its just a single value or multiple, which is extremly unnatural and forces you to flood the whole source with car's for no reason, which are easy to miss and extremly time consuming to debug of cause.
Beside that, the PDB itself is extremly limited, all you can do is call plug-ins and give them parameters, you can't create real GUIs with the PDB, you can't add buttons or now windows to the GimpUI, you can't create new tools for Gimp. The PDB doesn't even map to the GimpUI, often there are cases where the GimpUI provides some functionality, but the PDB doesn't, so you have to manually recode functionality that gimp already provides, because the PDB doesn't give you access to it. Which I think is also one of the major reasons why there still isn't a macro recorder.
Gimp is really NOT 'very friendly' far from it, a CorelPhotopaint from 1996 actual blows Gimp pretty much away in almost every aspect (scripting, macrorecording, GUI).
The only thing that Gimp is actually good at, is the number of Plug-Ins it provides, but beside that there is really not much talk worthy in Gimp and especially not 'simple hacking', when you can't even configure the buttons in the toolbox.
1. If developers have no time to waste, they should simply ignore them, instead of starting flamewars or simply honestly state that they lack the time to implement this or that feature. Beside that, many people who are 'whining' are often criticising important failures of a project, sure they may have not used the perfectly gentle right words, but that doesn't make them less right.
2. He is arguing from a practical point of view, not from a theoretical. For most people going under the hood of Open Source software is as realistic as climbing the Mount Everest, sure they could do it, but they neigher have the knowledge or the time to actually do it.
3. Again he is talking from a practical point of view, not a theoretical one. Sure you can sell Open Source software, but how many people are actually doing it, especially if you leave the 'just boundle up a bunch of OSS written by other people' aka distros people? Actually very very few compared to the ones writing them. And even of those who make a bit of money with it, how many make actually enough money to make a living from it?
4. Well, people are often overestimating the quality of a OSS product, but well, that happens more out of the fan boy camp, than out of the developer camp. Just count how many times you have heard that Gimp is a Photoshop killer, while in reality its far far behind Photoshop.
5. Well, maybe no myth there, it just states that 'scratch an itch' doesn't really lead to any software that end-users are interested in.
6. More choice is NOT always good. Are you happy that there are so many fileformats and everything is incompatible with each other? Wouldn't a bit less choice and more standards actually be a good thing? How about one good and polished configuration tool for linux that works, instead of dozens of hacks from the distro makers that all more or less don't work?
A bit choice isn't bad, sure, but in the linux world it quite often turns out that instead of one working tool, you get half a dozens of unfinished not much working once. Just having 'More' isn't better, quality of the software itself matters.
7. Far from it, it states pretty well how Open Source looks from a practical point of view, not from a theoretical one.
The problem with Ok/Cancel as it is on Windows is that it is inconsistent with itself. Why is "Ok" or "Yes" on the right, but "Next" on the left? Both do almost exactly the same. In Gnome it goes just like this "Most common button is always bottom/right", its very consistent and once you used it for a few days it will feel much more natural then Ok/Cancel in the other way around.
Last not least Gnome also tries in almost all places to get away from the whole Ok/Cancel/Yes/No in the first place. If I have a save dialog I see Cancel/Save, no 'Ok' button there. Which helps even more to get dialogs more clear and straight forward.
The button order issue is one where Gnome people did the right decision in my view, but as somebody else already mentioned, for every such fundamental change they do, they should provide an easy to find option to switch back. As it stands now, one has to adopt to new dialogs, button orders, disapearing config options and stuff with every release, which can get extremly annoying.
The command-line + GUI part however won't work much good for anything more then rather trivial stuff. Command-line tools are just far to inflexible for this, making it hard, slow or even impossible to get correct data out of them (ps auxw output is outdated already as it gets printed, find... | xargs... won't work for filenames with newlines in them, many utils output 'ascii art' (statusbars and such) stuff that one has to filter away or even interpret, etc.).
Sure for some of these things there are workarounds or even fixes, but in general the simple nature of command line tools makes them a rather bad choice as the basis for a GUI where one would need automatic updating of the displayed info as soon as it changed and such.
IMHO a more correct way to solve this would be to seperate all functionality out into a library and consider the command line tool to be just what it is, another user interface to the libraries functionality, just like the GUI. That way pretty much all problems could be solved while still providing both GUI and console tools, while neither of them would be limited by the other. However for this to work, people would need to cleanly seperate the functionality and that always involves some more work than just crunching a UI directly into the 'functionality'. There also seems to be some kind of philosophical difference between GUI and console people, both of them almost completly ignore the other in their design, leading to quite a huge gap between GUI and console tools, instead of a smooth translation as it should be.
KDE already has some support for calling its functions from command line, so there is hope, however pretty much all command line tools for daily use still lack a GUI counterpart or visa verse.
A whole lot of problems that GNU/Linux has today, and basically, always had, can't be solved at the UI level alone, the problems need to be solved at a lower level, namely for example the kernel itself.
Just take 'mounting' as example, no matter of UI goodieness will make the process of mounting floppies or CD-Roms intuitive, easy and problem free. People will always end up with jammed cd-drives, due to locking, floppies that get ejected before the write is finished and stuff like that as long as they need to mount their drives.
At the kernel level however the whole process of mounting can be made drastically easier with things like supermount or mtools (not kernel level, more kernel-circumvention level), the whole problem of mounting things almost automatically fades away. However supermount still hasn't made it into the standard kernel and so many people are still stuck with the process of mounting and inferior GUI workarounds that try to more or less automatically mount stuff, but more often just end up throwing cryptic error messages at the user.
Another case would be application installment. With for example MacOSX installing a application can be as easy as a drag&drop, on Linux however systems people have to learn what RPM, DPKG, tar.gz, what their distri is and other stuff like that, there are dozens of ways to handle software installations. No GUI in the world can burn this down to the easy of use of drag&drop installations. Here a standard for cross-distri, relocatable software packages is needed.
There are a whole lot more of these issues where the problem of the UI is a direct consequence of problems at lower levels. Doing a serious improvement of the 'Linux-UI' would require joint forces on pretty much all levels, from kernel, filesystem hierachie to KDE and Gnome. It would also mean to just throw some things out of the window such as the current filesystem standard or at least hide it pretty well in the GUI as Apple does.
JPEG never looks 'perfect', it however might look good enough depending on what you are trying to do.
Just run select-by-color on a JPEG image in Gimp and you will see how the color bleed into each other at the edges, even at maximum quality. For display purpose alone it isn't much of a problem, if you however want to cut a sprite out of a JPEG with colorkeying the results will be completly useless, even with a maximum quality JPEG.
The problem with Debian stable is that the label is wrong. With stable people expect the software to be stable, but Debian stable doesn't gurantee that, Debian stable only gurantee that the software dependencies themself are stable, which of course is nice, but it really doesn't buy you much.
I already quite often had cases where software in 'Debian stable', was either a lot more buggy or even completly unusable[1] compared to 'unstable'. Upstream after all also makes progress and fixes bugs, yet, due to Debians policies, none of these bugfixes ever went into 'stable', since stable basically means "don't touch" and only change something for security reason.
I really don't know a single person that runs stable as it is, I know a few that use stable + tons of backports and self compiled software, but if people run it that way they lose the automatic security updates for the pieces of software that they compiled themself or got from other sources. Also package dependencies can be quite broken with unofficial backports, since the quality of them can vary quite a lot.
Debian really needs to adopt to reality and should focus more on how people are actually using it. Its completly worthless to get all thousands of packages 'stable' when half of them are still bleeding edge and will be outdated in a few weeks or month. Pretty much all people are using backports of KDE and Gnome, then Debian should adopt to that. Debian should focus on getting only an important core of software 'stable' (kernel, glibc and friends), other stuff like KDE and Gnome shouldn't be directly part of stable, but instead released seperatly, thus both the core-stable and the KDE/Gnome stuff could be updated much more frequencly and at the same time giving a much more stable complete system as we have today with all the inoffical backports and patchworks.
[1] old Sane version didn't supported a scanner or even segfaulted, but a current Sane would work perfectly, driver for gfx card only available for newer XFree86s, mailloss due to bug in ssmtp, old kernel wouldn't have driver for some network card, etc.
3D interfaces will never get much popular in the mainstream, they are simply to compilcated and to inefficent and especially not needed for day to day work. Writing a text or painting a picture are simple 2d jobs. Sure modeling a 3d model requires at least some short of way to navigating through 3d and so do many games, but these are special cases and not something Joe User needs for his day to day work, so the desktop environment itself will most likly stay 2d.
What we however will most likly see in the future are zooming interfaces, something like Apples Expose which is still 2d, but it provides a way to 'step back' to get a better overview of what is going on. So icons of a document could get thumbnails to which you just 'zoom-in' to be able to edit them, instead of opening and saving them. However this will still be 'flat' 2d.
Thats pretty much how kkrieger (http://www.theprodukkt.com/) works, ie. store the operations used to generate the mesh, instead of storing the mesh, that way they can store quite a bunch of stuff in a tiny 96kb executable. However this aproach doesn't work on a large scale, since you can't take a mesh and decompose it into the operation that where used to generate it, you have to create the meshes from scratch with exactly those operations that the 'composer' supports. So its fun for the demo-scene, but doesn't have too much use for real world.
### The Blender community seems to know this, but it is still unclear what they may or may not do about it...;-/
Blenders interface already has improved a whole lot after it went OpenSource. Its now already a lot better then before, sure still not perfect, but the progress is pretty good.
And anyway, the interface itself has never been much of a problem for myself, sure not really intuitive, but once you have worked through a few tutorials, it shouldn't be much of an issue and it gives actually a nice workflow. A far bigger problem for me always was the lack of more advanced modeling features (you can only do so much with extrude), ie. stuff like Wings3d it has, boolean operations and such, luckily Blender is also improving in that direction quite a bit.
Correct me if I am wrong, but isn't Theora the first OpenSource and non-'Patent-poisned' Codec that we have that is also (at least more or less) up to todays standard? Xvid and so are all fine and nice, but rather useless if I am not allowed to use them due to patents.
Instead he should be directed to a convenient administration tool (swat/webmin)
While I don't disagree with this advice, its however a big part of the problem. The issue is that there are lots of config-tools out there for various task and with various completness, usefullness and correctness. Official docs for a project seldomly cover these third party config-wrapper tools, neither do the HowTos or google-groups and so if anything goes wrong the newbie is pretty much completly screwed. Almost no config-tool does proper reading and writing of the config file itself, instead they often do their own thing and just rewritte the config file completly, so reading docs and tweaking a config file directly will quite often end up in the original configfile getting overwritten or in the config tool bailing out.
What linux needs is a consistend way to do configuration and exactly one usefull tool for each job, not half a dozen incomplete ones. A standard config file syntax would help here a whole lot already. And instead of distris patching up stuff on their side, it would be good to see some join effort on fixing these inconsistencies.
its something you're likely to change once. For that reason, its in gconf.
Isn't that the whole point of all options found in the preferences dialog? I mean, I start an app for the first time, begin to use it, go to preferences tweak some things to suit my needs and basically never ever visit preferences dialog again. Everything that I use on a daily basis belongs into the menu itself, not in the preferences dialog, yet Nautilus managed to place the 'show hidden files' there.
Anyway, gconf is the worst idea that the Gnome people ever had. I don't have a problem with having extremly obscure and dangerous functionality that pretty much no user is ever going to touch into GConf, but fact is that Gnome hiddes a whole lot of options that are pretty common in other application deep down in GConf and doesn't even provide the user with any way to get there (advanced button in the preferences dialog or such). Gnome seems to go the road of making it easier for the completly clueless newbie, while making it a whole lot harder for the casual computer user.
The main point of a spatial interface that he fails to emphasize (but mentions briefly in passing) is that every time you open a window everything is exactly as you left it.
And thats exactly the point why it doesn't scale well. With deep directery structures or unknown directory trees (say a CD-Rom) the position where stuff opens becomes random. It doesn't matter if its in the same spot as the user left it, if the user can't remember how he left the folder a month ago. The user will in that case get a bunch of randomly opening windows and be confused quite a bit.
How often do you need to copy files and end up scrolling the tree pane up and down,
clicking through directory trees,
Seldomly, most of the time I use the file browser to browse my file system, after all I have already saved the file in the right location in the first place, so there is little need to copy it around afterwards.
or even try opening two explorer windows at once and resize all over to copy?
A second browser window is exactly a single-clickaway in most filemanagers, at worst its a item in the context menu. I really don't see how this should be worse than the dozens of windows that clutter the desktop when having deep hierachies.
Honestly *try* it for a while. Don't like it? Switch it off. Done.
The only real fix is to switch away from Nautilus completly, browser mode alone won't help much, since the browser mode is pretty underfeatured as well (not even a button to show hidden files). Beside that Gnome people managed to hidde the 'switch off' switch deep down in GConf.
I am personally very happy with Rox, its also far from feature rich, but at least the basic navigation feels right.
When I want to open a folder, I don't want to open every folder before it in the tree
You can middle-click, the old window will disappear and the new one will appear somewhere on the screen.
How do I quickly go back to the parent
The thing in the lower/left that doesn't look like a button/menu, but just like a status bar text, is actually a clickable drop down menu and will bring you to any parent.
I want to get to the one called "testnumber5384.c". I start typing the filename, expecting the file manager to know what I want and automatically jump to the files fitting my typing.
Works fine if you make sure that the window has focus and you type fast enough (no longer than 1sec between characters).
And of course, where the heck are the hidden files in the file chooser??? Forget opening any config files in gedit (not that you would).
They have hidden the option in the preferences dialog, only takes you 4 clicks... but be happy that they havn't yet moved it into Registry^WGConf
That said, I am not saying that having these features makes spatial mode any more usefull, most of the features are so well hidden that almost no user will ever find them or even when, many features aren't much usefull or implemented far worse than in other browser. I for one use bash and rox most of the time, far more pleasant usability experience than spatial mode.
With a low file count and flat directory structures it is quite pleasant to use, ie. on the Amiga I didn't had any problems with it, but well, back then I stored all my files on a floppy disk and seldomly had more then 100 files to work with.
Today however I have something like half a million files floating around on my harddisk and spartial is pretty much useless for browsing that.
The problem with spatial mode is that it is maybe a little bit better on very low file counts, while it performce a whole lot worse (ie. unuseable) on large directory hierachies. Browse mode however works fine on low file counts as well as on large directory hierachies.
Could you explain me how spatial and meta-categories mix? Isn't the main reason for spatial that a window becomes a folder and a folder a window from the users point of view? Don't this mapping break completly appart as soon as I have meta categories and different views on my data? Would meta categories be pretty much like todays browser, ie. have some search field, type stuff in it, get results, with shortcut/links to previous searches/categories (aka bookmarks)?
Slashdot Mirror
Two screens aren't much usefull for gaming. Sure there might be this or that nice idea that will provide nice new gameplay, but for the majority of games the second screen will just display the map or some other not much usefull information that could easily made available via the pause screen menu. Just one large screen would certainly be more usefull for most games.
The only thing that makes the second screen interesting is the touchscreen ability, however I doubt that it will be that much usefull for most games.
Last not least, the second screen looks like a waste, both screens are the same size, so the upper half of the DS just looks extremly empty, would have made much more sense to just make the second screen smaller, since for sure most games will use it only for secondary information, not for game critical stuff.
Aehm, well, how many Marios got rereleased for the GBA was it 4 or 5? And how many of them were new ones? Something around zero, rest was ports of SNES or even NES games. How about a Zelda? Well, again a SNES port. Ok, we got two new Metroids, but those were rather similar to Super Metroid, not necessarily a bad thing, however overall there hasn't been all that orginial ideas of Nintendo in the GBA area, just far to many rereleases of titels that already got rereleased in the times of the SNES (ie. MarioAllStars).
In general I agree that Nintendo is good for original ideas, but on the GBA they really havn't done much, 'Mario&Luigi Superstar Saga' would one of the few original ones that comes to mind and even that is 'just' a successor of MarioRPG.
Looking at the Nintendo DS the first few titles I have seen where a patched up Mario64, a MarioKart and MetroidPrime version, overall not all that original. Sure I hope that Nintendo will provide some cool stuff, but I fear that the whole DualScreen thing will just end up as a useless gadget that hardly any game will make much use off, as it happened with quite a few Nintendo gadgets before (GBPrinter, GBA link, 64DD, SNES Mouse).
Wondering if its easier to send humans to mars or just build a better robot. Its not like we had the space ship ready to send the humans to mars tomorrow, so there is still a lot of progress to be made when it comes to AI and robot development.
Afterall there are also things that robots can do that human can't, imagine sending hundreds of tiny and yeap robots all across the planet instead of just a bunch on humans on a single place, who of them will collect more valueable data? Or sending a large drill (to get some samples from deep down) instead of the whole life support needed for humans to Mars.
Last not least, there is also the money question, so far we only have send relativly cheap (at least compared to the cost of a human mission) robots to mars, how much better or more robots could we build when the money for a human mission would go instead to a robot one?
Not saying that human space flight is worthless, but when it comes to deep space explorations, we are probally not ready to do that in a cost effective manner.
1) There is Photoshop Elements which costs far less than the full version, not sure however how that exactly compares to Gimp. There are also other alternatives like CorelPhotoPaint, PaintShopPro, etc. which come either for 'free' (ie. you get them with your PC) or cost little money.
2) Lack of better brushes is my personal Nb.1 complain about Gimp, it really matters, especially when you have a graphic tablet (which often come with Photoshop and/or Painter). And its not even that there hasn't been tries to improve Gimps brush handling, see http://www.levien.com/gimp/wetdream.html However none of it seems to have found its way into the current Gimp, so Gimp2.0 still feels pretty much exactly like a Gimp1.0, which is kind of sad, given that between both releases there is half a decade of development time.
3) Most likly the user interface does cause FAR more throuble for Windows users than for Linux ones, which come with multiple workspaces at default, while Windows doesn't. Beside that the Windows version of Gimp has been rather unstable for quite a while, not sure how much better the current one is.
While yep, Gimp might be and good enough for Joe home user, most Windows people have access to better or equal alternatives. And well, on the Linux side you don't have much choice anyway, either you use Gimp or you DualBoot into Windows. Its just like with many free software projects, they might be good enough for almost everybody, but they simply aren't a lot better, which doesn't make it worth to switch.
Sure it 'allows' you to look under the hood, he doesn't argue against that, he argues that pretty much nobody is actually doing it, thats all.
The myth isn't that you are 'allowed to go under the hood', the myth is that its actually something that a serious number of people do.
Gimp never was a LISP library, far from it. Gimp used from the start SIOD, which isn't a Lisp, not even a Scheme, its some broken non-standard kind of Lisp dialect which is a major pain to work with (almost undebugable, error messages that don't tell you more then 'something went wrong', etc.). Beside that Gimp, isn't even much coupled with SIOD, it just comes with it at default, because SIOD source was small enough to get included into the Gimp one, so it didn't add a extra dependency. Gimp functions are exported via the PDB, which doesn't depend on a specific language. And that said, the SIOD bindings are pretty much the worst of all, in SIOD every function returns a list, no matter if its just a single value or multiple, which is extremly unnatural and forces you to flood the whole source with car's for no reason, which are easy to miss and extremly time consuming to debug of cause.
Beside that, the PDB itself is extremly limited, all you can do is call plug-ins and give them parameters, you can't create real GUIs with the PDB, you can't add buttons or now windows to the GimpUI, you can't create new tools for Gimp. The PDB doesn't even map to the GimpUI, often there are cases where the GimpUI provides some functionality, but the PDB doesn't, so you have to manually recode functionality that gimp already provides, because the PDB doesn't give you access to it. Which I think is also one of the major reasons why there still isn't a macro recorder.
Gimp is really NOT 'very friendly' far from it, a CorelPhotopaint from 1996 actual blows Gimp pretty much away in almost every aspect (scripting, macrorecording, GUI).
The only thing that Gimp is actually good at, is the number of Plug-Ins it provides, but beside that there is really not much talk worthy in Gimp and especially not 'simple hacking', when you can't even configure the buttons in the toolbox.
1. If developers have no time to waste, they should simply ignore them, instead of starting flamewars or simply honestly state that they lack the time to implement this or that feature. Beside that, many people who are 'whining' are often criticising important failures of a project, sure they may have not used the perfectly gentle right words, but that doesn't make them less right.
2. He is arguing from a practical point of view, not from a theoretical. For most people going under the hood of Open Source software is as realistic as climbing the Mount Everest, sure they could do it, but they neigher have the knowledge or the time to actually do it.
3. Again he is talking from a practical point of view, not a theoretical one. Sure you can sell Open Source software, but how many people are actually doing it, especially if you leave the 'just boundle up a bunch of OSS written by other people' aka distros people? Actually very very few compared to the ones writing them. And even of those who make a bit of money with it, how many make actually enough money to make a living from it?
4. Well, people are often overestimating the quality of a OSS product, but well, that happens more out of the fan boy camp, than out of the developer camp. Just count how many times you have heard that Gimp is a Photoshop killer, while in reality its far far behind Photoshop.
5. Well, maybe no myth there, it just states that 'scratch an itch' doesn't really lead to any software that end-users are interested in.
6. More choice is NOT always good. Are you happy that there are so many fileformats and everything is incompatible with each other? Wouldn't a bit less choice and more standards actually be a good thing? How about one good and polished configuration tool for linux that works, instead of dozens of hacks from the distro makers that all more or less don't work?
A bit choice isn't bad, sure, but in the linux world it quite often turns out that instead of one working tool, you get half a dozens of unfinished not much working once. Just having 'More' isn't better, quality of the software itself matters.
7. Far from it, it states pretty well how Open Source looks from a practical point of view, not from a theoretical one.
The problem with Ok/Cancel as it is on Windows is that it is inconsistent with itself. Why is "Ok" or "Yes" on the right, but "Next" on the left? Both do almost exactly the same. In Gnome it goes just like this "Most common button is always bottom/right", its very consistent and once you used it for a few days it will feel much more natural then Ok/Cancel in the other way around.
Last not least Gnome also tries in almost all places to get away from the whole Ok/Cancel/Yes/No in the first place. If I have a save dialog I see Cancel/Save, no 'Ok' button there. Which helps even more to get dialogs more clear and straight forward.
The button order issue is one where Gnome people did the right decision in my view, but as somebody else already mentioned, for every such fundamental change they do, they should provide an easy to find option to switch back. As it stands now, one has to adopt to new dialogs, button orders, disapearing config options and stuff with every release, which can get extremly annoying.
The command-line + GUI part however won't work much good for anything more then rather trivial stuff. Command-line tools are just far to inflexible for this, making it hard, slow or even impossible to get correct data out of them (ps auxw output is outdated already as it gets printed, find ... | xargs ... won't work for filenames with newlines in them, many utils output 'ascii art' (statusbars and such) stuff that one has to filter away or even interpret, etc.).
Sure for some of these things there are workarounds or even fixes, but in general the simple nature of command line tools makes them a rather bad choice as the basis for a GUI where one would need automatic updating of the displayed info as soon as it changed and such.
IMHO a more correct way to solve this would be to seperate all functionality out into a library and consider the command line tool to be just what it is, another user interface to the libraries functionality, just like the GUI. That way pretty much all problems could be solved while still providing both GUI and console tools, while neither of them would be limited by the other. However for this to work, people would need to cleanly seperate the functionality and that always involves some more work than just crunching a UI directly into the 'functionality'. There also seems to be some kind of philosophical difference between GUI and console people, both of them almost completly ignore the other in their design, leading to quite a huge gap between GUI and console tools, instead of a smooth translation as it should be.
KDE already has some support for calling its functions from command line, so there is hope, however pretty much all command line tools for daily use still lack a GUI counterpart or visa verse.
A whole lot of problems that GNU/Linux has today, and basically, always had, can't be solved at the UI level alone, the problems need to be solved at a lower level, namely for example the kernel itself.
Just take 'mounting' as example, no matter of UI goodieness will make the process of mounting floppies or CD-Roms intuitive, easy and problem free. People will always end up with jammed cd-drives, due to locking, floppies that get ejected before the write is finished and stuff like that as long as they need to mount their drives.
At the kernel level however the whole process of mounting can be made drastically easier with things like supermount or mtools (not kernel level, more kernel-circumvention level), the whole problem of mounting things almost automatically fades away. However supermount still hasn't made it into the standard kernel and so many people are still stuck with the process of mounting and inferior GUI workarounds that try to more or less automatically mount stuff, but more often just end up throwing cryptic error messages at the user.
Another case would be application installment. With for example MacOSX installing a application can be as easy as a drag&drop, on Linux however systems people have to learn what RPM, DPKG, tar.gz, what their distri is and other stuff like that, there are dozens of ways to handle software installations. No GUI in the world can burn this down to the easy of use of drag&drop installations. Here a standard for cross-distri, relocatable software packages is needed.
There are a whole lot more of these issues where the problem of the UI is a direct consequence of problems at lower levels. Doing a serious improvement of the 'Linux-UI' would require joint forces on pretty much all levels, from kernel, filesystem hierachie to KDE and Gnome. It would also mean to just throw some things out of the window such as the current filesystem standard or at least hide it pretty well in the GUI as Apple does.
Correct me if am wrong, but that looks like just the language spec, not the whole Orange Book (page count in pdf 106, page count in Orange Book 608).
JPEG never looks 'perfect', it however might look good enough depending on what you are trying to do. Just run select-by-color on a JPEG image in Gimp and you will see how the color bleed into each other at the edges, even at maximum quality. For display purpose alone it isn't much of a problem, if you however want to cut a sprite out of a JPEG with colorkeying the results will be completly useless, even with a maximum quality JPEG.
How do you go after ISPs if spamming is still perfectly legal?
The problem with Debian stable is that the label is wrong. With stable people expect the software to be stable, but Debian stable doesn't gurantee that, Debian stable only gurantee that the software dependencies themself are stable, which of course is nice, but it really doesn't buy you much.
I already quite often had cases where software in 'Debian stable', was either a lot more buggy or even completly unusable[1] compared to 'unstable'. Upstream after all also makes progress and fixes bugs, yet, due to Debians policies, none of these bugfixes ever went into 'stable', since stable basically means "don't touch" and only change something for security reason.
I really don't know a single person that runs stable as it is, I know a few that use stable + tons of backports and self compiled software, but if people run it that way they lose the automatic security updates for the pieces of software that they compiled themself or got from other sources. Also package dependencies can be quite broken with unofficial backports, since the quality of them can vary quite a lot.
Debian really needs to adopt to reality and should focus more on how people are actually using it. Its completly worthless to get all thousands of packages 'stable' when half of them are still bleeding edge and will be outdated in a few weeks or month. Pretty much all people are using backports of KDE and Gnome, then Debian should adopt to that. Debian should focus on getting only an important core of software 'stable' (kernel, glibc and friends), other stuff like KDE and Gnome shouldn't be directly part of stable, but instead released seperatly, thus both the core-stable and the KDE/Gnome stuff could be updated much more frequencly and at the same time giving a much more stable complete system as we have today with all the inoffical backports and patchworks.
[1] old Sane version didn't supported a scanner or even segfaulted, but a current Sane would work perfectly, driver for gfx card only available for newer XFree86s, mailloss due to bug in ssmtp, old kernel wouldn't have driver for some network card, etc.
What we however will most likly see in the future are zooming interfaces, something like Apples Expose which is still 2d, but it provides a way to 'step back' to get a better overview of what is going on. So icons of a document could get thumbnails to which you just 'zoom-in' to be able to edit them, instead of opening and saving them. However this will still be 'flat' 2d.
Thats pretty much how kkrieger (http://www.theprodukkt.com/) works, ie. store the operations used to generate the mesh, instead of storing the mesh, that way they can store quite a bunch of stuff in a tiny 96kb executable. However this aproach doesn't work on a large scale, since you can't take a mesh and decompose it into the operation that where used to generate it, you have to create the meshes from scratch with exactly those operations that the 'composer' supports. So its fun for the demo-scene, but doesn't have too much use for real world.
### The Blender community seems to know this, but it is still unclear what they may or may not do about it... ;-/
Blenders interface already has improved a whole lot after it went OpenSource. Its now already a lot better then before, sure still not perfect, but the progress is pretty good.
And anyway, the interface itself has never been much of a problem for myself, sure not really intuitive, but once you have worked through a few tutorials, it shouldn't be much of an issue and it gives actually a nice workflow. A far bigger problem for me always was the lack of more advanced modeling features (you can only do so much with extrude), ie. stuff like Wings3d it has, boolean operations and such, luckily Blender is also improving in that direction quite a bit.
Correct me if I am wrong, but isn't Theora the first OpenSource and non-'Patent-poisned' Codec that we have that is also (at least more or less) up to todays standard? Xvid and so are all fine and nice, but rather useless if I am not allowed to use them due to patents.
What linux needs is a consistend way to do configuration and exactly one usefull tool for each job, not half a dozen incomplete ones. A standard config file syntax would help here a whole lot already. And instead of distris patching up stuff on their side, it would be good to see some join effort on fixing these inconsistencies.
Anyway, gconf is the worst idea that the Gnome people ever had. I don't have a problem with having extremly obscure and dangerous functionality that pretty much no user is ever going to touch into GConf, but fact is that Gnome hiddes a whole lot of options that are pretty common in other application deep down in GConf and doesn't even provide the user with any way to get there (advanced button in the preferences dialog or such). Gnome seems to go the road of making it easier for the completly clueless newbie, while making it a whole lot harder for the casual computer user.
If povray is open source then why does Debian have it in the non-free category?
I am personally very happy with Rox, its also far from feature rich, but at least the basic navigation feels right.
That said, I am not saying that having these features makes spatial mode any more usefull, most of the features are so well hidden that almost no user will ever find them or even when, many features aren't much usefull or implemented far worse than in other browser. I for one use bash and rox most of the time, far more pleasant usability experience than spatial mode.
With a low file count and flat directory structures it is quite pleasant to use, ie. on the Amiga I didn't had any problems with it, but well, back then I stored all my files on a floppy disk and seldomly had more then 100 files to work with.
Today however I have something like half a million files floating around on my harddisk and spartial is pretty much useless for browsing that.
The problem with spatial mode is that it is maybe a little bit better on very low file counts, while it performce a whole lot worse (ie. unuseable) on large directory hierachies. Browse mode however works fine on low file counts as well as on large directory hierachies.
Could you explain me how spatial and meta-categories mix? Isn't the main reason for spatial that a window becomes a folder and a folder a window from the users point of view? Don't this mapping break completly appart as soon as I have meta categories and different views on my data? Would meta categories be pretty much like todays browser, ie. have some search field, type stuff in it, get results, with shortcut/links to previous searches/categories (aka bookmarks)?