Its not a fake, its just that they had just something like half a day to finally test it (had to get it done in time for a demo-party), so it won't work on all computers and nicer will run with all kinds of graphic cards.
All of the geometry and textures in the game are created by combining and deforming very simple objects (cubes, sphears). So instead of saving all the mesh data, they just save the operations they used to generate the mesh data, which requires a lot less data. So for example instead of saving each vertex of some part of an enemy, they just save 'take a cube, stretch by 5, shear by 10'. Same with textures, 'take a circle, blur by 50%, add text "bla" add 50, 50', etc., so instead of saving a hires texture which can consume multiple megabytes, they just save the operation used to generate it, which can bit into a few bytes.
The major difference between Windows and Linux is that in Windows stuff works at default, while in Linux its broken by default.
Sure throubleshooting, ie. getting from a broken way to a non-broken one, is way easier in Linux when you get proper error messages and have a 'strace' at hand thats helps you look under the hood.However in Windows pretty much everything can be done with a click, I don't need to care what the chip on my soundcard is called and how the module for that chip is called, if I should use Alsa, OSS or whatever, I just insert the CD, click myself through a few non-brainer menus (license, registry form, etc.) and reboot and the soundcard will just work. Thats how pretty much everything in Windows can be installed and configure, I don't have to think and I don't really have much to know, I can click around and get stuff to work with pretty much no knowledge at all.
Sure there are some Linux distros around that for the basic installation do something similar and provide a half working system, but thats only the basic installation. Soon people will want to add another soundcard, change their graphiccard or just install some nifty software utility that they found on the net. So what now? Now the people either have to wait until there distro catches up to the new hardware and software, pretty much inacceptable, since this can take ages sometimes, depending on the distro of course or they have to do their installation manually, ie. configure && make, make install and/or configure a custom kernel, patch it in the worst case and stuff like that. Alone the fact that the people have to know that their isn't a single-click installation ala Windows in the Linux world is enough to keep Linux of from the mainstream. I mean just look at some forums filled with newbies, they got hell a lot confused by all these gazzilion ways to install software under linux, rpm, deb, compile from source, static binaries, click-through installiers, etc.
And all this has nothing todo with 'learning the OS' or whatever. One can't learn the Linux way of doing stuff, since there simply isn't a single way to do stuff in Linux, there are gazillion different ways to do stuff and they even change every second year. After all people switch distros, new soundarchitectures arrive, an ATI graphic card has to be installed quite different from an Nvidia or a Matrox one, etc. In Windows however it pretty much boils down to just clicking stuff, with my rosty Win98 knowledge I can configure an WindowsXP box without ever having used WinXP ever before. Same goes even with MacOSX, I didn't have any problems in MacOSX with configuring basically stuff, pretty much a no brainer. Yet, while using Linux as my main OS for something like 6 years I still fear touching another distro or another piece of hardware, since it always ends up that I have to learn a shitload of new stuff before I can even get the basic features to work, and no, this isn't usefull knowledge, since it gets outdated often even quicker then I learned it, so its just a waste of time.
I second that, Linux has after all made quite a lot of good progress in quite a few areas, however in the distribution independend software installation it still the same has five years ago.
Just look at Knoppix for example, which provide an reasonably good configured system in no-time, just insert CD and boot, the code is there to do all the autodection, but it helps me nothing for the distribution I use for daily use, Debian in my case. Knoppix can make my soundcard work in a second, in Debian it still can take multiple hours and howto reading. There is simply no way to easily move a feature from one distro to another, I simply can't use Knoppix "detect the soundcard" stuff easily on my Debian box. Same goes with software, have a SuSE at work that provides some software, yet, there is no easy way to install the same software on my Debian box without starting completly from scratch (ie. compile from source or whatever). Neither can I simply insert a Knoppix CD into my CD-Rom and use it from my running Debian without some non really user-friendly vodoo (chroot-tricks and such).
All this boils that pretty much all the problems you get with Linux are already solved in some Distro out there, the problem is that no Distro solves all problems at once, so distro switching doesn't help, you always end up with a distro where you have to handle some stuff in a manual and timeconsuming way, that another distro already provides a perfectly userfriendly solution for.
So what Linux really needs are either less Distros or a way to make software easily available for all Distros at once, nothing sucks more than having a compiled binary that simply doesn't work on your favorite distribution. LSB might help here, but I havn't really seen any LSB packages in the wild...
all these thingies look *exactly* the same as in Windows, sure the background color or stuff might be different, but they way icons that don't fit into the window are handled, and the layout of the buttons in konqueror is pretty much exactly the same as in Windows, the behaviour is pretty much just copied. And this isn't a case where KDE copied something good, this stuff already sucked majorly in Windows, its sucks the same way in KDE, which makes me wonder why they copied it in the first place.
Yep, I think this is one of the areas where most GUI apps do it wrong. After all command line is great because you can do insanly complex stuff without cluttering up the interface much at all, after all the features aren't visible unless you tab-completed your way to the right command. Command-line also has the advantage that it is almost mode-less, you don't need to worry where you focus currently is when typing in stuff, it will always and up in the command-line, as oposed to most GUIs where you always have to click on this little input-box before being able to type stuff. Sadly there are only few GUI apps that use command-line like features. Emacs being one of them that gets this right[1], 'M-x' and you have a command-line ready for use, 'M-x apropos' and you can search for all functions, 'C-h f' and you can read documentation for each of the functions. More then one time I wished I had something as easy to use as this in Gimp, far too much time I have wasted by browsing through menus for plug-ins knowing exactly what I want, just not knowing the precise name and especially not the position in the menu. With the PDB it should be relativly easy to add a feature, but it hasn't happened yet.
[1] Emacs also gets a lot of other things wrong, but thats a different story
I second that, even so its not a much of an Gnome issue, but more a general Linux issue, ie. there is no standard way to ship binary packages on Linux that don't depend on a specific distribution. So if your distribution doesn't provide the newest and fluffiest stuff it always ends up being a big pain to get things up and running. LSB might help here in the far future, but so far I havn't met a single LSB binary in the wild.
Anyway, back to Gnome. For Gnome there exist Garnome:
* http://www.gnome.org/~jdub/garnome/
It isn't a 'double-click' install, but its basically as close as you can get on todays Linux systems to that, ie. it builds from source, but gets the dependencies automatically.
There is Ada95 which should come pretty close to your requirements, its pretty much like C, just with a whole lot safety added.
But you are right most of the new languages really don't touch the areas where C is successfully today. I think one of the major problems, at least in the Unix world, is that pretty much every library is written in C, so if another language should take over, you would have either to rewrite all libraries out there or at least create bindings to your new language and since that is a major overtaking it won't happen anytime soon.
If anything many functional programs are simpler because they directly map to the mathematics of the algorithm given... especially for recursive algorithms!
I have to agree on that, for mathematical and recursive stuff functional languages are great, but how many of this mathematical stuff is really required these days for 'Joey Programmer'? As soon as it gets complicated there is most often a C-Library around that already solves the dirty work (lists, arrays, hash-maps, etc.). Sure there is still a lot of stuff around that can't be simply solved via yet-another library, but isn't quite a lot of code today mainly wiring userinterfaces together (think VisualBasic programmers), ie. rather boring imperative stuff? For me thats the biggest stopping block for functional languages, sure I have seen a lot of nice quick-sort and similar algorithms in functional languages, but I haven't seen much whole programms around written in a functional language, which lets the functional languages often look rather academic.
I have used Gimp on Linux now for multiple years on a more or less daily basis and I am still not comfortable with the multiple windows. Sure they work more or less and using a seperate workspace/desktop helps keeping track too, but it still just an ugly hack, necessary due to the lack of proper[1] MDI. The reason is simply that Gimp has no way to communicate detailed enough with the window manager on how the windows should be handled, where they should get placed and such, so it happens far to often that windows gets placed suboptimal and need to be manually be moved around.
With a proper MDI where the application manages the windows, and not some window manager, that knows more or less nothing about the app, the app can much more fine graded tune how windows are handled, what is attached too what, what should be stay on top of what else, what is grouped together, etc. See the dockables in Gimp2 for example, everybody likes them, but they are nothing else then the beginning of moving controll of the windows from the window manager to the app. With dockables you can attach stuff to each other an already remove a bit of the clutter. What is missing is simply a way to attach the toolbox to the image windows and attach image windows to each other, add that and you already pretty much have what people want. In additon to simply connecting them a way to split the image view ala Emacs 'C-x 2' might be good too. People could still rip they GUI into pieces if they want of course, just like with the dockables we already have today, but they could also that Gimp managing the windows, instead of making that a users task.
If app-managed MDI work in Mozilla, Emacs, Konqueror, why shouldn't it work in Gimp?
[1] With proper MDI I meant MDI where the app manages the windows, which doesn't require ugly Window-in-Window stuff, just a way the app can keep the windows together.
Well, if you just warn people that there is a danger of executing email attachments, while at the same time neither removing the ability to execute them and not even making it obvious that the user is executing evil code, instead of just opening a harmless attachement (as in jpg/png, etc.), you shouldn't be suprised if they still execute it. Its the mail programm creators that are stupid in not fixing these problems, not the users, which just want to get their work done.
Beside that, don't forget that the lastest worms stuff actually does come in pretty stealthy outfit (ie mailerdeamon bounce mails and such) and don't forget either that just knowing that mail attachments might be evil, doesn't stop you from still ecidently clicking on one of them some day.
The user community wasn't given a wake-up call, not now and not when the last ten worms made a round trip, elsewhere people already wouldn't still open such things.
Secondly, assuming the users are stupid, is just stupid. Users are not stupid, sure some might be more or less clueless, but if the OS/Mailprogramm makes it easier to execute such a worm then to actually delete the mail its no wonder that so many people actually execute it, its the programm thats broken, not the user. Make it hard to execute such a thing on a computer, warn the user on what he is doing or even better run stuff from untrusted sources in a sandbox/chroot-like environment where it can't harm anybody and soon you will have a much harder time getting such widespread causes of such a 'user-executed-worm'.
It just happens far to often in our society that we blame the user, instead of the environment in which they work. After all the user is just a tiny piece in a large dynamic system and blaming this tiny piece alone just can't be right.
There is nothing wrong with support other architecture, but the point at which it gets annoying is when the other far less widespread architekture are holding back progress on the x86 architechture. After all, by far most people run x86, so thats where stuff should be get working first.
I think the KDE problems have already been dropped years ago. What they need to drop to get to the desktop is:
1) there installer, it simply requires far too much manual tweaking to get from a first install to a useable system, other distro are far better here. If Knoppix takes a minute to boot and be useable and Debian multiple hours up to days, something is seriously wrong.
2) there 'stable' concept, it just doesn't make sense to have all stuff crunched into one gigantic package and call it 'stable'. Stability isn't a gloabl issue, but very often a per package one, ie a new KDE or Gimp can often be way more stable than the stuff that you find in a Debian stable, but it will never get included in there, since stable dosn't get any updates at all beside security fixes. This often leads to having packages in stable that are far less stable than what you can get from unstable. 'stable' should mean having a stable system, not being stuck with the same programm versions for multiple years.
I don't think anybody wants to force you into using MDI, it would just be a very nice option, since doesn't of floating windows can get quite tricky to handle.
Anyway, I think neither the current state nor plain old MDI interfaces would be a really good solution, since as already mentioned in the bug report, MDI with Window-in-Window is replicating WindowManager funktionality, which it really shouldn't and which as all kind of drawbacks on itself. On the other side the current WindowManager are not really useable to handle such a large number of windows effectivly, the normal window-controlls (resize, maximive, iconize) simply don't make all that much sense for a 'Layers Dialog' or something like that. I think what is needed would be quite a bit better interaction between toolkit and windowmanager, allowing the toolkit to give much more detailed hints about what type of window it is displaying, allowing additional buttons in the window border and such. So that one for example could take all tool-dialogs and group them with a single click or arrange them in fixed positions instead of having them floating around like a normal window.
One interesting hack-way to proof-of-concept stuff like this might be to make a custom gimp-window-manager, launch it together with Gimp in an Xnest, which in turn would give a MDI-style interface. If well done, people might not even notice what exactly is happening.
Yes, the fork is unfortunate, but as far as I know a merge will not happen in the near future. The reason for that is simply that Gimp2 is in huge parts a rewrite of Gimp1, lots of code cleanup and such. But since Cinepine is forked from the Gimp1 code base, there is not much left that Cinepaint and Gimp2 really share, sure they still look similar, but under the hood a lot of stuff has changed. So its probally already to late to merge again, to much has changed since the fork.
Rox has something like that, the whole filemanagment is basically based on drag&drop, to load a file you drag it on the application, to save it, you drag an icon given by the application to your filemanager. Its pretty neat, but to make this one really work well all apps would need to follow that paradigma and looking at the whole mix of software out there I don't think that will happen in the near future, which is kind of a shame.
Because Gtk+ file selector has sucked from day one and in something like 5 years they haven't managed to fix this pretty damn obious thingy. Good to see some progress on that one now.
RAID is a good solution for not so reliable harddisks, but it is not a replacement for backup. After all RAID only protects against harddisk failure, not against the user doing 'rm *' in the wrong folder, thats what you want backup for.
With two harddisks I would probally not set them up in a RAID, but having them run side by side, mirrored via an rsync based software, such as rdiff-backup, that would give the advantage of having incremental diffs and allowing to recover from an 'rm *'. Sure one has to make sure that it isn't mounted the whole time or else it could get wiped out too just too easily.
Looking at Xouvert and XServer there are quite a few people interested in maintaining and continuing XFree86. As far as I can see it the whole old structure of XFree86 and the Core-Team was one of the main issues holding the progress back, making it extremly difficult to get code merged into the core tree and such. Sure it will take a while until the dust has cleaned up, but a big clean-sweat is really needed for XFree86, its IMHO one of the main issue that hold GNU/Linux as a whole back from moving onto the cassual users desktop.
It will probally take a decade to get rid of people claiming that FreeCraft got shutdown by Blizzard, it is simply not right. FreeCraft did not get shutdown by Blizzard.
Yes, Blizzard sent a letter to the FreeCraft developers asking them for a name change and a few other things, which seem to be mostly a result of Blizzard lawyers not understanding what FreeCraft really is and never ever looking at it. Thats it, the next day the FreeCraft developers deleted the project from sourceforge.net without any further communications with Blizzard or any try to rename the project and move it. Blizzard did not request such drastic measures. It was the lone decission from the two active FreeCraft maintainers at that point, nothing more. Since both of the developers started a new project a few weeks after this, my guess would be that it was mostly the lack of interest in FreeCraft to keep the project alive, since they havn't even tried it. Anyway, in the meantime some former contributors picked up the remains of FreeCraft, organised a CVS-repo tarball and renamed the project. It is now well alive again under the name Stratagus and there are even some projects making use of the engine, without simply trying to clone Warcraft2.
Yeah, ifconfig could use a good save-/load-config option, but that's pretty easy to build with Perl using both ifconfig and netstat.
Thats exactly the reason why this probally will never get fixed. It is relativly easy to add, it doesn't require rocket-science to work, anybody with a little knowledge could do it in theory, however to really provide a benefit to the user one would need to fix it in dozens and hundreds of tools and keep it consistent. If a dozen of people 'fix' it differently in a dozen apps, it provides nearly no benefit. And it gets worse, with GNU and X11 we already have conflicting standards on how to do stuff (--long-option vs. -long-option), there is no way to get stuff like that into upstream anytime soon. Sure as it is today it kind of works, but far to many I fought with the tools more than with the job that they should solve. If writing a mouse-driver is easy than configuring the mouse, than something is already broken and this one isn't as far fetched as it sounds.
What Linux needs is consistency in its user interfaces and common standards among distributions on how things can get done. Documentation is good to have, but its even better to not needing it in the first place.
Currently its often a whole mess of incompatible and incomplete config-file-wrappers, that are only needed because core tools are not able to do the job right. Why there need to be half a dozen X11 config tools? Because the problem isn't fixed at the root, but workarounded at the distro level. Why can I setup my network via ifconfig, but need to write a config file (with completly different syntax) to get my network setup ready at boot. Why can't ifconfig not simply dump the config themself to a file or read from it? This is not an issue of commandline vs. gui, just wrappering a bunch of buttons around the already broken framework one level below won't help much at all.
Unix started of nicly, but Linux today really feels as development has stopped quite some years ago, all the stuff that happens today is mostly just 'wrapperisnm' and that is the root of all confusion.
At least in theory less Options is good. After all when it works right at Default, why change it to a wrong less good working state?
The Problem with Gnome2 is that a lot of stuff is wrong at default and while Gnome1.4 provided an option to correct that incorrect default value, Gnome2 simply removed the option instead of fixing the behaviour (panel being above fullscreen windows [mplayer, blender, etc.] for example). Anyway its getting better, but there is still a long way to get back the Gnome1.4 usabilty. After all user testing is an important issue and Gnome2 really doesn't look like they ever tested it much against user, but instead blindly followed the HIG in far too many points. Optimizing to much for the newbie is another problem, everybody starts out as a newbie, but after all, I am a newbie just for a few days or a month, but after that I have to live with that app for the rest of my live.
With todays processors I don't care all that much about CPU time, but much more about my time. If a good window manager (sawfish here) can save me time and improve my workflow, a bit of wasted CPU and RAM is well worth it, after all that CPU is idling half of the time anyway, so why should I care?
Slashdot Mirror
Its not a fake, its just that they had just something like half a day to finally test it (had to get it done in time for a demo-party), so it won't work on all computers and nicer will run with all kinds of graphic cards.
All of the geometry and textures in the game are created by combining and deforming very simple objects (cubes, sphears). So instead of saving all the mesh data, they just save the operations they used to generate the mesh data, which requires a lot less data. So for example instead of saving each vertex of some part of an enemy, they just save 'take a cube, stretch by 5, shear by 10'. Same with textures, 'take a circle, blur by 50%, add text "bla" add 50, 50', etc., so instead of saving a hires texture which can consume multiple megabytes, they just save the operation used to generate it, which can bit into a few bytes.
The major difference between Windows and Linux is that in Windows stuff works at default, while in Linux its broken by default.
Sure throubleshooting, ie. getting from a broken way to a non-broken one, is way easier in Linux when you get proper error messages and have a 'strace' at hand thats helps you look under the hood.However in Windows pretty much everything can be done with a click, I don't need to care what the chip on my soundcard is called and how the module for that chip is called, if I should use Alsa, OSS or whatever, I just insert the CD, click myself through a few non-brainer menus (license, registry form, etc.) and reboot and the soundcard will just work. Thats how pretty much everything in Windows can be installed and configure, I don't have to think and I don't really have much to know, I can click around and get stuff to work with pretty much no knowledge at all.
Sure there are some Linux distros around that for the basic installation do something similar and provide a half working system, but thats only the basic installation. Soon people will want to add another soundcard, change their graphiccard or just install some nifty software utility that they found on the net. So what now? Now the people either have to wait until there distro catches up to the new hardware and software, pretty much inacceptable, since this can take ages sometimes, depending on the distro of course or they have to do their installation manually, ie. configure && make, make install and/or configure a custom kernel, patch it in the worst case and stuff like that. Alone the fact that the people have to know that their isn't a single-click installation ala Windows in the Linux world is enough to keep Linux of from the mainstream. I mean just look at some forums filled with newbies, they got hell a lot confused by all these gazzilion ways to install software under linux, rpm, deb, compile from source, static binaries, click-through installiers, etc.
And all this has nothing todo with 'learning the OS' or whatever. One can't learn the Linux way of doing stuff, since there simply isn't a single way to do stuff in Linux, there are gazillion different ways to do stuff and they even change every second year. After all people switch distros, new soundarchitectures arrive, an ATI graphic card has to be installed quite different from an Nvidia or a Matrox one, etc. In Windows however it pretty much boils down to just clicking stuff, with my rosty Win98 knowledge I can configure an WindowsXP box without ever having used WinXP ever before. Same goes even with MacOSX, I didn't have any problems in MacOSX with configuring basically stuff, pretty much a no brainer. Yet, while using Linux as my main OS for something like 6 years I still fear touching another distro or another piece of hardware, since it always ends up that I have to learn a shitload of new stuff before I can even get the basic features to work, and no, this isn't usefull knowledge, since it gets outdated often even quicker then I learned it, so its just a waste of time.
I second that, Linux has after all made quite a lot of good progress in quite a few areas, however in the distribution independend software installation it still the same has five years ago.
Just look at Knoppix for example, which provide an reasonably good configured system in no-time, just insert CD and boot, the code is there to do all the autodection, but it helps me nothing for the distribution I use for daily use, Debian in my case. Knoppix can make my soundcard work in a second, in Debian it still can take multiple hours and howto reading. There is simply no way to easily move a feature from one distro to another, I simply can't use Knoppix "detect the soundcard" stuff easily on my Debian box. Same goes with software, have a SuSE at work that provides some software, yet, there is no easy way to install the same software on my Debian box without starting completly from scratch (ie. compile from source or whatever). Neither can I simply insert a Knoppix CD into my CD-Rom and use it from my running Debian without some non really user-friendly vodoo (chroot-tricks and such).
All this boils that pretty much all the problems you get with Linux are already solved in some Distro out there, the problem is that no Distro solves all problems at once, so distro switching doesn't help, you always end up with a distro where you have to handle some stuff in a manual and timeconsuming way, that another distro already provides a perfectly userfriendly solution for.
So what Linux really needs are either less Distros or a way to make software easily available for all Distros at once, nothing sucks more than having a compiled binary that simply doesn't work on your favorite distribution. LSB might help here, but I havn't really seen any LSB packages in the wild...
http://pingus.seul.org/~grumbel/tmp/kdesucks/kdecl oningwindows.png a steofspace.png a steofspace2.png
http://pingus.seul.org/~grumbel/tmp/kdesucks/kdew
http://pingus.seul.org/~grumbel/tmp/kdesucks/kdew
all these thingies look *exactly* the same as in Windows, sure the background color or stuff might be different, but they way icons that don't fit into the window are handled, and the layout of the buttons in konqueror is pretty much exactly the same as in Windows, the behaviour is pretty much just copied. And this isn't a case where KDE copied something good, this stuff already sucked majorly in Windows, its sucks the same way in KDE, which makes me wonder why they copied it in the first place.
Yep, I think this is one of the areas where most GUI apps do it wrong. After all command line is great because you can do insanly complex stuff without cluttering up the interface much at all, after all the features aren't visible unless you tab-completed your way to the right command. Command-line also has the advantage that it is almost mode-less, you don't need to worry where you focus currently is when typing in stuff, it will always and up in the command-line, as oposed to most GUIs where you always have to click on this little input-box before being able to type stuff. Sadly there are only few GUI apps that use command-line like features. Emacs being one of them that gets this right[1], 'M-x' and you have a command-line ready for use, 'M-x apropos' and you can search for all functions, 'C-h f' and you can read documentation for each of the functions. More then one time I wished I had something as easy to use as this in Gimp, far too much time I have wasted by browsing through menus for plug-ins knowing exactly what I want, just not knowing the precise name and especially not the position in the menu. With the PDB it should be relativly easy to add a feature, but it hasn't happened yet.
[1] Emacs also gets a lot of other things wrong, but thats a different story
I second that, even so its not a much of an Gnome issue, but more a general Linux issue, ie. there is no standard way to ship binary packages on Linux that don't depend on a specific distribution. So if your distribution doesn't provide the newest and fluffiest stuff it always ends up being a big pain to get things up and running. LSB might help here in the far future, but so far I havn't met a single LSB binary in the wild.
Anyway, back to Gnome. For Gnome there exist Garnome:
* http://www.gnome.org/~jdub/garnome/
It isn't a 'double-click' install, but its basically as close as you can get on todays Linux systems to that, ie. it builds from source, but gets the dependencies automatically.
There is Ada95 which should come pretty close to your requirements, its pretty much like C, just with a whole lot safety added.
But you are right most of the new languages really don't touch the areas where C is successfully today. I think one of the major problems, at least in the Unix world, is that pretty much every library is written in C, so if another language should take over, you would have either to rewrite all libraries out there or at least create bindings to your new language and since that is a major overtaking it won't happen anytime soon.
I have used Gimp on Linux now for multiple years on a more or less daily basis and I am still not comfortable with the multiple windows. Sure they work more or less and using a seperate workspace/desktop helps keeping track too, but it still just an ugly hack, necessary due to the lack of proper[1] MDI. The reason is simply that Gimp has no way to communicate detailed enough with the window manager on how the windows should be handled, where they should get placed and such, so it happens far to often that windows gets placed suboptimal and need to be manually be moved around.
With a proper MDI where the application manages the windows, and not some window manager, that knows more or less nothing about the app, the app can much more fine graded tune how windows are handled, what is attached too what, what should be stay on top of what else, what is grouped together, etc. See the dockables in Gimp2 for example, everybody likes them, but they are nothing else then the beginning of moving controll of the windows from the window manager to the app. With dockables you can attach stuff to each other an already remove a bit of the clutter. What is missing is simply a way to attach the toolbox to the image windows and attach image windows to each other, add that and you already pretty much have what people want. In additon to simply connecting them a way to split the image view ala Emacs 'C-x 2' might be good too. People could still rip they GUI into pieces if they want of course, just like with the dockables we already have today, but they could also that Gimp managing the windows, instead of making that a users task.
If app-managed MDI work in Mozilla, Emacs, Konqueror, why shouldn't it work in Gimp?
[1] With proper MDI I meant MDI where the app manages the windows, which doesn't require ugly Window-in-Window stuff, just a way the app can keep the windows together.
Well, if you just warn people that there is a danger of executing email attachments, while at the same time neither removing the ability to execute them and not even making it obvious that the user is executing evil code, instead of just opening a harmless attachement (as in jpg/png, etc.), you shouldn't be suprised if they still execute it. Its the mail programm creators that are stupid in not fixing these problems, not the users, which just want to get their work done. Beside that, don't forget that the lastest worms stuff actually does come in pretty stealthy outfit (ie mailerdeamon bounce mails and such) and don't forget either that just knowing that mail attachments might be evil, doesn't stop you from still ecidently clicking on one of them some day.
The user community wasn't given a wake-up call, not now and not when the last ten worms made a round trip, elsewhere people already wouldn't still open such things. Secondly, assuming the users are stupid, is just stupid. Users are not stupid, sure some might be more or less clueless, but if the OS/Mailprogramm makes it easier to execute such a worm then to actually delete the mail its no wonder that so many people actually execute it, its the programm thats broken, not the user. Make it hard to execute such a thing on a computer, warn the user on what he is doing or even better run stuff from untrusted sources in a sandbox/chroot-like environment where it can't harm anybody and soon you will have a much harder time getting such widespread causes of such a 'user-executed-worm'. It just happens far to often in our society that we blame the user, instead of the environment in which they work. After all the user is just a tiny piece in a large dynamic system and blaming this tiny piece alone just can't be right.
There is nothing wrong with support other architecture, but the point at which it gets annoying is when the other far less widespread architekture are holding back progress on the x86 architechture. After all, by far most people run x86, so thats where stuff should be get working first.
I think the KDE problems have already been dropped years ago. What they need to drop to get to the desktop is:
1) there installer, it simply requires far too much manual tweaking to get from a first install to a useable system, other distro are far better here. If Knoppix takes a minute to boot and be useable and Debian multiple hours up to days, something is seriously wrong.
2) there 'stable' concept, it just doesn't make sense to have all stuff crunched into one gigantic package and call it 'stable'. Stability isn't a gloabl issue, but very often a per package one, ie a new KDE or Gimp can often be way more stable than the stuff that you find in a Debian stable, but it will never get included in there, since stable dosn't get any updates at all beside security fixes. This often leads to having packages in stable that are far less stable than what you can get from unstable. 'stable' should mean having a stable system, not being stuck with the same programm versions for multiple years.
I don't think anybody wants to force you into using MDI, it would just be a very nice option, since doesn't of floating windows can get quite tricky to handle.
Anyway, I think neither the current state nor plain old MDI interfaces would be a really good solution, since as already mentioned in the bug report, MDI with Window-in-Window is replicating WindowManager funktionality, which it really shouldn't and which as all kind of drawbacks on itself. On the other side the current WindowManager are not really useable to handle such a large number of windows effectivly, the normal window-controlls (resize, maximive, iconize) simply don't make all that much sense for a 'Layers Dialog' or something like that. I think what is needed would be quite a bit better interaction between toolkit and windowmanager, allowing the toolkit to give much more detailed hints about what type of window it is displaying, allowing additional buttons in the window border and such. So that one for example could take all tool-dialogs and group them with a single click or arrange them in fixed positions instead of having them floating around like a normal window.
One interesting hack-way to proof-of-concept stuff like this might be to make a custom gimp-window-manager, launch it together with Gimp in an Xnest, which in turn would give a MDI-style interface. If well done, people might not even notice what exactly is happening.
Yes, the fork is unfortunate, but as far as I know a merge will not happen in the near future. The reason for that is simply that Gimp2 is in huge parts a rewrite of Gimp1, lots of code cleanup and such. But since Cinepine is forked from the Gimp1 code base, there is not much left that Cinepaint and Gimp2 really share, sure they still look similar, but under the hood a lot of stuff has changed. So its probally already to late to merge again, to much has changed since the fork.
Rox has something like that, the whole filemanagment is basically based on drag&drop, to load a file you drag it on the application, to save it, you drag an icon given by the application to your filemanager. Its pretty neat, but to make this one really work well all apps would need to follow that paradigma and looking at the whole mix of software out there I don't think that will happen in the near future, which is kind of a shame.
Because Gtk+ file selector has sucked from day one and in something like 5 years they haven't managed to fix this pretty damn obious thingy. Good to see some progress on that one now.
With two harddisks I would probally not set them up in a RAID, but having them run side by side, mirrored via an rsync based software, such as rdiff-backup, that would give the advantage of having incremental diffs and allowing to recover from an 'rm *'. Sure one has to make sure that it isn't mounted the whole time or else it could get wiped out too just too easily.
Looking at Xouvert and XServer there are quite a few people interested in maintaining and continuing XFree86. As far as I can see it the whole old structure of XFree86 and the Core-Team was one of the main issues holding the progress back, making it extremly difficult to get code merged into the core tree and such. Sure it will take a while until the dust has cleaned up, but a big clean-sweat is really needed for XFree86, its IMHO one of the main issue that hold GNU/Linux as a whole back from moving onto the cassual users desktop.
Yes, Blizzard sent a letter to the FreeCraft developers asking them for a name change and a few other things, which seem to be mostly a result of Blizzard lawyers not understanding what FreeCraft really is and never ever looking at it. Thats it, the next day the FreeCraft developers deleted the project from sourceforge.net without any further communications with Blizzard or any try to rename the project and move it. Blizzard did not request such drastic measures. It was the lone decission from the two active FreeCraft maintainers at that point, nothing more. Since both of the developers started a new project a few weeks after this, my guess would be that it was mostly the lack of interest in FreeCraft to keep the project alive, since they havn't even tried it. Anyway, in the meantime some former contributors picked up the remains of FreeCraft, organised a CVS-repo tarball and renamed the project. It is now well alive again under the name Stratagus and there are even some projects making use of the engine, without simply trying to clone Warcraft2.
What Linux needs is consistency in its user interfaces and common standards among distributions on how things can get done. Documentation is good to have, but its even better to not needing it in the first place.
Currently its often a whole mess of incompatible and incomplete config-file-wrappers, that are only needed because core tools are not able to do the job right. Why there need to be half a dozen X11 config tools? Because the problem isn't fixed at the root, but workarounded at the distro level. Why can I setup my network via ifconfig, but need to write a config file (with completly different syntax) to get my network setup ready at boot. Why can't ifconfig not simply dump the config themself to a file or read from it? This is not an issue of commandline vs. gui, just wrappering a bunch of buttons around the already broken framework one level below won't help much at all.
Unix started of nicly, but Linux today really feels as development has stopped quite some years ago, all the stuff that happens today is mostly just 'wrapperisnm' and that is the root of all confusion.
The Problem with Gnome2 is that a lot of stuff is wrong at default and while Gnome1.4 provided an option to correct that incorrect default value, Gnome2 simply removed the option instead of fixing the behaviour (panel being above fullscreen windows [mplayer, blender, etc.] for example). Anyway its getting better, but there is still a long way to get back the Gnome1.4 usabilty. After all user testing is an important issue and Gnome2 really doesn't look like they ever tested it much against user, but instead blindly followed the HIG in far too many points.
Optimizing to much for the newbie is another problem, everybody starts out as a newbie, but after all, I am a newbie just for a few days or a month, but after that I have to live with that app for the rest of my live.
With todays processors I don't care all that much about CPU time, but much more about my time. If a good window manager (sawfish here) can save me time and improve my workflow, a bit of wasted CPU and RAM is well worth it, after all that CPU is idling half of the time anyway, so why should I care?