Aehm, yep, of course creating good models or textures involves some talent and work, but it does not involve any need for coordinated development and thats exactlly why it would work perfectly as "Open Source" (or better Creative Commons). A good library of textures and models could be created over a long period of time without to much problems and it would help Open Source game development in general a lot, since one wouldn't need to start out from a blank sheet of paper, but could start with a room full of inventory and would just need to tweak the parts that need tweaking to fit the game.
Sure you need tools and artists who are willing to work for free, but looking around I see lots and lots of artists who work for free and do it just for the love and fun of it, nothing stops them in the long term to add some Creative Commons license to their work and give it away for others to reuse.
I second that, getting anything about the game design communicated is quite difficult, Wiki's help a lot and so does IRC, but its still extremly difficult to get an idea across the internet, especially if its not something that has already been done a dozens of times. Mailinglists are, at least for me, rather useless to get any of the details communicated, they work however reasonablly well for an overall roadmap, but discussions about details always end up in week long flamewars, since nobody really understands what the other mean.
After all I think thats one of the reasons why cloning or at least 'heavy inspriation' of older commercial titles works reasonablly well, since with them you can always just point at the commercial title and say "Do it like them" and people have a fair chance to know what you are talking about.
Artwork is as much reusable as code, sometimes completly, sometimes with modifications, sometimes not at all. If I want to write a spreadsheet the Apache source code won't help me much, if I however want to modify Apache it will help me a lot, same is very true for games, if I just want to write a series of new levels for my favorite game it will of course help a lot if I have a library of textures and 3d models available for reuse.
I don't think that point is true, after all artwork is not that much different from code. Sure if you want it all 100% original, you might need to generate huge parts from scratch, but you don't need that in most cases. Commercial games have used sounds from sound-collection cds for quite a while, textures can also often get reused without to much problem, a brick wall stays a brick wall, grass stays grass, clouds are clouds, no matter of the type of game. A model of the golden gate bridge could be usefull for quite a few games. Sure for some games you want a specific style and you need to create huge parts from scratch, but for many games, especially those that mimik the real-world more or less having a library of available 3d models and textures at hand helps a lot.
Its basically the same with code, I can not just pick some random piece of code and magically reuse it in my app, in most cases the code reuse is limited to some pretty small parts. The only larger areas where code reuse takes place are libraries which are specificly designed for reuse.
How is that gender bias? Maybe it is simply true? Man and women are not equal and never will, remember the little birth thing and the children, man on the other side went hunt some animal a few thousand years ago. Just because we know have a society that makes them equal from the 'rights' point of view doesn't necesarry mean that they ever will behave equally, you can't wipe out a few million years of evolution with some hundred years of equal rights.
I am not saying that we shouldn't remove gender bias where it is truely there, just that we shouldn't automatically assume that there is a gender bias just because the distribution between man and women is not exactly 50/50.
The function keys might already be used by the application, thats why its not really save to try to use them for something else, howevere the multimedia keys that comes with most new keyboards are pretty freely configurable, probally not via the Windows software that comes with them, but I didn't have much problems getting all the extras keys on my Microsoft Natural to work in Linux. Its really just a matter of having the right configuration, no need for 'special' Linux keyboards.
I have a 120gb drive and only around 20gb real data, maybe 10gb for the OS itself, add a another 30gb random junk to that and I still have 60gb of my HD virtually completly unused. Even if tempfiles are not handled special it will take basically forever before my filesystem fills up, its really a non-issue these days.
Beside that, I am taking about an 'intelligent' trashcan, not these "Your trashcan is full, please empty manually" ones. If the HD fills up, the trashcan should of course free itself and overwrite old stuff, possibly with custom threshold and such, no problem there, since in most cases you will find the error you did that lead to file loss relativly quickly anyway.
### Even the MSDOS undelete only worked provided that you didn't overwrite the data with something else (if I recall correctly).
Yes, it did and its undelete weren't much powerfull or anything, but it was there and it worked already quite fine on old 386er with lausy 200mb harddrives, hardware improved quite a bit since then, undelete features however didn't for no obvious reason.
### In the end I think we would be better served by a smarter 'rm' and a better GUI trash can (not the cheap hack the KDE team came up with).
Such stuff will NEVER be enough, I don't actually 'rm' my files, in most cases I overwrite them with 'convert', via piping or whatever. And thats exactly the reason why I want undelete at filesystem level, since the filesystem can track all these without problems, something implemented at the GUI level however can only ever track a very small fraction of excidental deletes or overwrites, if at all.
The hardware to handle a versioned filesystem without problems has at least existed for a decade, its really just the software that still hasn't improved, neither on Linux nor on Windows or MacOS.
In addition to that I would recomment to have a look at PartImage, it basically does a similar job to 'dd', but it is 'filesystem-aware', thus it is able to save only the used blocks of the disk and not forced to everything. Especially with todays 120gb drives the saving can be quite huge.
One of the things I still miss most under Linux are a proper trashcan/undelete (at filesystem level, not at GUI level that doesn't help on the shell) or even better a full blown 'undo' operation on the filesystem. Even MSDOS provided a very basic undelete operation and I can't really believe that we are still without it on Linux.
Does ReiserFSv4 provide stuff like that? Or in case it don't, are the 'Plugins' that it supports powerfull enough for that and are there maybe already plugins awailable that add an undelete/undo? Better yet would of course be a fullblown versioned filesystem, how about that, is that doable with ReiserFSv4 plugins?
And how do the plugins relate to for example GNU Hurds translators or LUFS? Do they act at a similar level, or are they completly different?
The important difference is that Windows works 'by default', ie. there is one more or less clear way how to accomplish a task (new piece of hardware? insert driver disk or go to Controllcenter->Hardware, install software? click setup.exe). So I only have to look out for the manual if something goes wrong.
With Linux stuff however doesn't work 'by default', worse there isn't even an obvious way how to start doing something. New piece of hardware? What to do? Look at the manpage? Won't help, look at the KDE Help? Won't help either. Browse under/lib/modules/? No luck there either, since module name often has absolutly nothing in common with the piece of hardware I bought. If its a piece of input device, even finding the right module won't help, since XF86Config might need adjustment. Found some software on the net and want to install it? Doubleclicking it isn't doing anything, man pages leave you rather clueless and once you have figured out what rpm and tar.gz are you still run into dependency-hell.
In short there simply isn't one way of doing things in Linux, there are dozens, often incompatible ways of doing things (use the nice wrapper script or edit config by hand?), the existance of dozen different distros make it even worse, since Howtos often just give you one way of doing it, which might of course be completly false for your distro (tweak XF86Config by hand and Sax might get quite unhappy or something like that, manually insert modules while your distro provides some auto-detection magic for that, etc.).
Has long as Linux doesn't provide one way that works by default and is reachable via the GUI, it will have some serious problems on the desktop. However currently its still a huge mess of config files, wrapper scripts that often break more then they fix and similar things.
Just one of the things that Linux does completly wrong is for example is the driver and device handling, modules and device files (with udev/devfs) are simply non-persistent, reboot and you lost them. This might seem like a minor issue, but if a user not only has to find out how to make things work, but in addition to that how to make them persistent, its a huge additional step, that might already drive him away from Linux. I found it quite enlightning when I set up my network card under GNU/Hurd and it "just worked" after the reboot, since Hurd keeps track of the translators one sets up in the filesystem.
While the computer is of course more complex as a microwave, it also already comes with everything needed to help and guide the user. A microwave doesn't have a html-browser, a wizard tool, a 1024x768 full color display and similar stuff that can guide the user and display help exactly when and where its needed, that why a microwave needs a seperate manual.
The only form of a seperate manual that a good OS should really need is one that guides the user through the very first steps of the installation and one that explains the very basics of the OS (double click to start, right click for context menu). After that point the OS itself should guide the user, not a seperate manual.
No, its not the solution, its part of the problem. As long as Linux users need a manual, Linux is simply not ready for the desktop. Sure having a manual as an addition to an already userfriendly desktop system would be good, but a manual doesn't solve problems, it only gives users a way step-by-step guide to work around them.
Most of the HowTos out there just shows this quite clearly, instead of teaching the user anything of value, they just provide a more or less step-by-step guide to work around the problem. Sure, some of them additionally try to teach the inner working of the piece of software that the user is trying to get working, but in almost all cases this is what I call 'worthless' knowledge, ie. the knowledge is in most part only useable for exactly a single piece of software and only for a specific version. Use another distro, a new version of a piece of software or a new kernel and almost all "Howto-knowledge" instantly gets compltetly worthless and you can just hope that the howto got updated in the meantime to give you yet anoter step-by-step guide.
If Linux should get ready for grandma's desktop, it might be a worthy thing to go through all HowTos and Newbie-Guides and to actually fix the problems in the software itself, instead of trying to work around them in documentation.
The day when almost all HowTos got obsolete, thats the day where Linux is ready for the desktop. We are however not even close to that.
Installing is something you do exactly once, yes it should be as easy as possible and Debians install isn't. However I prefer to let the user get over a small hurdle first (Debian install can be mastered almost with just pressing 'return') and then have a 'smooth walk' (via apt-get and Co.), then to do it the other way around and make the install look easy, but than make every upgrade or change to the system a major pain. Just to often I have seen newbies getting a Linux system installed easily, but then being completly confused once they went to install stuff like the NVidia drivers, stuff they found on the net or when they just wanted to upgrade a piece of software. In Debian and Gentoo I can solve these newbie problems with a single line, in most other distros with a much smaller number of packages I can't.
Lets face it, GNU/Linux isn't end user ready by any means. It might work on moms desktop if the son is doing the adminstration, but its not going to work if 'mom' is doing everything alone. And as long as a beginners guide contains a 'shell intro' it probally never will be. Giving them a Debian install is thus only a honest way of what they have to expect from the rest of GNU/Linux.
And the locks alone without the laws would have have solved the problem of burglary? I kind of doubt that...
The law alone will of course not make the spam magically go completly away, but it will make sure that sending spam gets a pretty risky business, instead of a completly risk free one, so people might think twice before sending out a million spam mails. Sure this won't stop people from other countries, however reducing spam from the USA would be a pretty good start.
The GPL doesn't prevent forking, it just makes sure that code can be merged back and forth between the forks at all times, so that stuff like the WineX vs Wine scenario can never happen with the GPL.
Easy, they didn't. Stuff like trees, grass and landscape can be generated with fractals and macros of course, but when it comes to humans, special textures or other kinds of objects that you can't easily express via scripting they fall back to textures taken from photos, 3d modeles, modeled in 3dmax, Poser or wherever and other stuff outside of Povray. Povray is than of course used to link anything back together and render the final image, but Povray is by no means the only application that played a role in creating the final image.
That said, there are of course also a lot amazing images that are 100% done in Povray, but as said, that is than more done with fractals and stuff, than 'modeled'.
Shadow passwords aren't a hashing mechanism, all they do is store the hashes in a file that the users can't read. Just Unix permissiosn, pretty trivial after all.
About crypt() vs MD5, I don't think that they make much different when it comes to cracking actual passwords, all MD5 does is allow you to use longer passwords, it doesn't enforce it by any means. If your password is in a dictonary, no matter what hashing algo you use, I can brute force it in a few seconds.
The only advantage a good hashing algorithm provides is that it ensures that you can't from a given hash calculate back the original password by other means than brute force. Brute force, however, will always work, no matter what algorithm you use. The only way to make a more secure password, is to use a better password, a better hash algo won't help a damn.
Depends heavily on who the actuall work does. If the programming is in large part fundet by Novell then I think its just fair that they get the copyright to make a little money with proprietary software, thats at least how Ghostscript works as far as I know.
When on the other side the community drives the projects and then some third party who might have in the ancient past be involved in the project gets all the copyright, than that would of course be fundamentally wrong and it would be time to no longer assign copyright to them.
Anyway, I think the biggest problem with the copyright assignment is the actually assignment itself, not the cause of it. Since the assignment itself makes it difficult for one-time contributors to actually contribute anything that is something more than a mimial patch, since that would involve paperwork, which can get quite complicated with different countries and differnt laws. As far as I remember that has at least for some GNU projects keep people from actually working more active on a project.
No, since the BSD license would give everybody the right to do whatever they want with the code, I doubt that is what Novell wants that.
As it stands now, only Novell can do what they want with the code, as they get the copyright, and everybody outside of Novell 'just' gets the GPLed version and can't thus reuse the code in a proprietary product as Novell can.
No, not really, it gets deeper than that. Far to often I had situations where I knew that a perfectly 100% working Linux driver for a piece of hardware exists, yet getting the hardware to work could still easily take multiple hours or even days, due to the extremly complicated and time-consuming process involved to install the drivers.
Sure if you are lucky you just 'modprobe' and are done, but if that doesn't work you are pretty much alone in the woods and that happens actually rather frequenly with hardware that isn't two years old. First you have to find out why the hardware doesn't work (just me doing something wrong or is it a driver bug?), which requires google and lots of mailinglist reading, then you have to find out how to get the correct driver, then you have to install that driver, which involves a completly non-standard procedure, which so far changed with pretty much every kernel and piece of hardware that I had in hand. Sometimes I just have to./configure && make, but more often I have to download a full kernel source tree, patch that, configure and compile that, not so fun if I have to switch from a custom distro kernel to the plain upstream one. Sometimes it gets worse and I have to actually had to recompile XFree86, which involved a nice 50mb download of source, rather painfull for non DSL users. Let alone that even if the driver, kernel and XFree86 version all match, you still have to actually configure the driver (editing XF86Config and that kind of fun).
Hardware installation under Linux still results in counterless hours of pain, not because the hardware manufactures didn't provide drivers, but because Linux completly lacks any kind of standard on how to handle software outside of that what the distribution provides.
Doom3 looks pretty impressive overall, gameplay might be a bit to much run&shoot, but after all its meant to be a Doom, not a DeusEx, so I guess that is ok for those people who like that kind of games.
However one thing that really didn't impresse me was the representation of the player. It is again, like in far too many FPS before, just a flying pair of airms, no feet, no body. If you climb ladder he doesn't even use his arms. I mean how lame is that? 'Bugs' like that where tolerable in the early days of FPS, but with Doom3 being pretty much the technically most advance game of its genre its kind of sad that they havn't tried to make the player something more than just this flying body-less camera.
Actually, its not so much the kernel panic that replaces the BSOD on Linux, but the XFree86-freeze, which happens quite often when it comes to anything that is either fullscreen, OpenGL or does grab the mouse (the old 4.7 Netscape did that quite often and got stuck then). Sometimes you can kill the app from remote and get your X11 back, but far to often its a "bye,bye" and requires a X restart or reboot. Linux itself pretty much still runs without problem, but that doesn't help you much if your whole graphical interface doesn't move any more. And about switching to console, that is either not reachable (cause XFree eating the key presses) or unusable due to messed up graphic memory/mode.
From a users point of view I would say that Linux together with XFree86 is quite a bit worse than a WindowsXP when it comes to rendering the computer unuseable. Sure the kernel is still running, but what is that worth, if all my X11 applications have to be restarted? I just hope that sooner or later X11 proxies or a way for X11 clients to reconnect to the server become common so that one can restart XFree86 without losing all the running applications. That still wouldn't solve all problems with XFree86, but at least quite a lot.
Some graphical version of the good old magic sysreq might also be nice, ie. one that could restart XFree86, switch the graphic mode back to something sane and stuff like that, instead of just sync and reboot.
PS: Yeah, I know AllowDeactiveGrabs and AllowClosedownGrabs, but they don't help all that often, beside that hardly any user will know about them.
Gnome is designed with the 'newuser' in mind, but not the "switch-away-from-Windows" kind of newuser, but the "hasn't ever seen a Computer" before kind newuser. Sure this is a bit far away from reality, since the number of users that start with Linux as their first OS will be quite small. However I for one like that direction, since it focuses on doing things right and not on doing it wrong just because this other OS does it too.
Free Software doesn't really has much to sell, so I think this is a route that is worth to take. Some people might not like it at a first sigh, but I for one strongly prefer a slick and well designed overall user interface, then one that is build out of hacks and uglyness and is just the way it is for historic reasons. If people want something that looks and feels more like Windows, they already have KDE, so Gnome taking a different route can just be good for inovation and the overall end result.
About Spatial Nautilus, yes, for the first time computer user I think it is better. I for one loved the spatial interface on the Amiga and I like that that Gnome goes in the same direction. Even for the avarage user spatial might actually be better after a little period to get used to it. The failure is that there is no easy way to get rid of spatial Nautilus, after all for browsing anything but well organized flat home directories its rather useless.
The thing however where Gnome fails in large, isn't the basic idea, but the overall implementation. Good design means that the thing gets as simple as possible, but not simpler. Gnome for one however as a history of removing valuable configuration options and hidding them deep down in GConf, thus making simplifing things over the edge. Removing a not so much used config option, might be good for simplification and provide a little benefit for the computer-unknown user, but if it ends up in the normal users browsing for hours through GConf to get their configurations back up and running, Gnome people have really done something fundamentally wrong.
There is also a overall lack of focus on the average or advanced Linux user, after all most of them have at least some basic knowledge of the command line, so integrating that sanly into Gnome should be at a high priority. How come then that stuff like Nautilus when started from the console always goes to the Home directory, instead of the current one? Or that if I drag and drop a file into Gnome-Term I get an unescaped string, instead of a quoted one? How come that they removed/mutilated the Tab-completion of the GtkFileDialog, which was the one thing that the otherwise sucky FileDialog did extremly right and much better then the rest.
Overall Gnome people have done a lot of things right, but an equal amount of things extremly wrong. It will be interesting to see how things developed, after all one can hardly ignore the fact that there have been mistakes, if the Gnome people would start to finally listen to complains of long time Gnome users, we might end up with a extremly nice, powerfull and yet very simple desktop environment, if they however continue to ignore the advanced users Gnome will just end of as the DE for grandmas and nobody else who has used computers for a few years will make much use of it.
Slashdot Mirror
Aehm, yep, of course creating good models or textures involves some talent and work, but it does not involve any need for coordinated development and thats exactlly why it would work perfectly as "Open Source" (or better Creative Commons). A good library of textures and models could be created over a long period of time without to much problems and it would help Open Source game development in general a lot, since one wouldn't need to start out from a blank sheet of paper, but could start with a room full of inventory and would just need to tweak the parts that need tweaking to fit the game.
Sure you need tools and artists who are willing to work for free, but looking around I see lots and lots of artists who work for free and do it just for the love and fun of it, nothing stops them in the long term to add some Creative Commons license to their work and give it away for others to reuse.
I second that, getting anything about the game design communicated is quite difficult, Wiki's help a lot and so does IRC, but its still extremly difficult to get an idea across the internet, especially if its not something that has already been done a dozens of times. Mailinglists are, at least for me, rather useless to get any of the details communicated, they work however reasonablly well for an overall roadmap, but discussions about details always end up in week long flamewars, since nobody really understands what the other mean.
After all I think thats one of the reasons why cloning or at least 'heavy inspriation' of older commercial titles works reasonablly well, since with them you can always just point at the commercial title and say "Do it like them" and people have a fair chance to know what you are talking about.
Artwork is as much reusable as code, sometimes completly, sometimes with modifications, sometimes not at all. If I want to write a spreadsheet the Apache source code won't help me much, if I however want to modify Apache it will help me a lot, same is very true for games, if I just want to write a series of new levels for my favorite game it will of course help a lot if I have a library of textures and 3d models available for reuse.
I don't think that point is true, after all artwork is not that much different from code. Sure if you want it all 100% original, you might need to generate huge parts from scratch, but you don't need that in most cases. Commercial games have used sounds from sound-collection cds for quite a while, textures can also often get reused without to much problem, a brick wall stays a brick wall, grass stays grass, clouds are clouds, no matter of the type of game. A model of the golden gate bridge could be usefull for quite a few games. Sure for some games you want a specific style and you need to create huge parts from scratch, but for many games, especially those that mimik the real-world more or less having a library of available 3d models and textures at hand helps a lot.
Its basically the same with code, I can not just pick some random piece of code and magically reuse it in my app, in most cases the code reuse is limited to some pretty small parts. The only larger areas where code reuse takes place are libraries which are specificly designed for reuse.
How is that gender bias? Maybe it is simply true? Man and women are not equal and never will, remember the little birth thing and the children, man on the other side went hunt some animal a few thousand years ago. Just because we know have a society that makes them equal from the 'rights' point of view doesn't necesarry mean that they ever will behave equally, you can't wipe out a few million years of evolution with some hundred years of equal rights.
I am not saying that we shouldn't remove gender bias where it is truely there, just that we shouldn't automatically assume that there is a gender bias just because the distribution between man and women is not exactly 50/50.
The function keys might already be used by the application, thats why its not really save to try to use them for something else, howevere the multimedia keys that comes with most new keyboards are pretty freely configurable, probally not via the Windows software that comes with them, but I didn't have much problems getting all the extras keys on my Microsoft Natural to work in Linux. Its really just a matter of having the right configuration, no need for 'special' Linux keyboards.
I have a 120gb drive and only around 20gb real data, maybe 10gb for the OS itself, add a another 30gb random junk to that and I still have 60gb of my HD virtually completly unused. Even if tempfiles are not handled special it will take basically forever before my filesystem fills up, its really a non-issue these days.
Beside that, I am taking about an 'intelligent' trashcan, not these "Your trashcan is full, please empty manually" ones. If the HD fills up, the trashcan should of course free itself and overwrite old stuff, possibly with custom threshold and such, no problem there, since in most cases you will find the error you did that lead to file loss relativly quickly anyway.
### Even the MSDOS undelete only worked provided that you didn't overwrite the data with something else (if I recall correctly).
Yes, it did and its undelete weren't much powerfull or anything, but it was there and it worked already quite fine on old 386er with lausy 200mb harddrives, hardware improved quite a bit since then, undelete features however didn't for no obvious reason.
### In the end I think we would be better served by a smarter 'rm' and a better GUI trash can (not the cheap hack the KDE team came up with).
Such stuff will NEVER be enough, I don't actually 'rm' my files, in most cases I overwrite them with 'convert', via piping or whatever. And thats exactly the reason why I want undelete at filesystem level, since the filesystem can track all these without problems, something implemented at the GUI level however can only ever track a very small fraction of excidental deletes or overwrites, if at all.
The hardware to handle a versioned filesystem without problems has at least existed for a decade, its really just the software that still hasn't improved, neither on Linux nor on Windows or MacOS.
In addition to that I would recomment to have a look at PartImage, it basically does a similar job to 'dd', but it is 'filesystem-aware', thus it is able to save only the used blocks of the disk and not forced to everything. Especially with todays 120gb drives the saving can be quite huge.
One of the things I still miss most under Linux are a proper trashcan/undelete (at filesystem level, not at GUI level that doesn't help on the shell) or even better a full blown 'undo' operation on the filesystem. Even MSDOS provided a very basic undelete operation and I can't really believe that we are still without it on Linux.
Does ReiserFSv4 provide stuff like that? Or in case it don't, are the 'Plugins' that it supports
powerfull enough for that and are there maybe already plugins awailable that add an undelete/undo? Better yet would of course be a fullblown versioned filesystem, how about that, is that doable with ReiserFSv4 plugins?
And how do the plugins relate to for example GNU Hurds translators or LUFS? Do they act at a similar level, or are they completly different?
The important difference is that Windows works 'by default', ie. there is one more or less clear way how to accomplish a task (new piece of hardware? insert driver disk or go to Controllcenter->Hardware, install software? click setup.exe). So I only have to look out for the manual if something goes wrong.
/lib/modules/? No luck there either, since module name often has absolutly nothing in common with the piece of hardware I bought. If its a piece of input device, even finding the right module won't help, since XF86Config might need adjustment. Found some software on the net and want to install it? Doubleclicking it isn't doing anything, man pages leave you rather clueless and once you have figured out what rpm and tar.gz are you still run into dependency-hell.
With Linux stuff however doesn't work 'by default', worse there isn't even an obvious way how to start doing something. New piece of hardware? What to do? Look at the manpage? Won't help, look at the KDE Help? Won't help either. Browse under
In short there simply isn't one way of doing things in Linux, there are dozens, often incompatible ways of doing things (use the nice wrapper script or edit config by hand?), the existance of dozen different distros make it even worse, since Howtos often just give you one way of doing it, which might of course be completly false for your distro (tweak XF86Config by hand and Sax might get quite unhappy or something like that, manually insert modules while your distro provides some auto-detection magic for that, etc.).
Has long as Linux doesn't provide one way that works by default and is reachable via the GUI, it will have some serious problems on the desktop. However currently its still a huge mess of config files, wrapper scripts that often break more then they fix and similar things.
Just one of the things that Linux does completly wrong is for example is the driver and device handling, modules and device files (with udev/devfs) are simply non-persistent, reboot and you lost them. This might seem like a minor issue, but if a user not only has to find out how to make things work, but in addition to that how to make them persistent, its a huge additional step, that might already drive him away from Linux. I found it quite enlightning when I set up my network card under GNU/Hurd and it "just worked" after the reboot, since Hurd keeps track of the translators one sets up in the filesystem.
The JPL has one, and its zoomable to: http://wmt.jpl.nasa.gov/
While the computer is of course more complex as a microwave, it also already comes with everything needed to help and guide the user. A microwave doesn't have a html-browser, a wizard tool, a 1024x768 full color display and similar stuff that can guide the user and display help exactly when and where its needed, that why a microwave needs a seperate manual.
The only form of a seperate manual that a good OS should really need is one that guides the user through the very first steps of the installation and one that explains the very basics of the OS (double click to start, right click for context menu). After that point the OS itself should guide the user, not a seperate manual.
No, its not the solution, its part of the problem. As long as Linux users need a manual, Linux is simply not ready for the desktop. Sure having a manual as an addition to an already userfriendly desktop system would be good, but a manual doesn't solve problems, it only gives users a way step-by-step guide to work around them.
Most of the HowTos out there just shows this quite clearly, instead of teaching the user anything of value, they just provide a more or less step-by-step guide to work around the problem. Sure, some of them additionally try to teach the inner working of the piece of software that the user is trying to get working, but in almost all cases this is what I call 'worthless' knowledge, ie. the knowledge is in most part only useable for exactly a single piece of software and only for a specific version. Use another distro, a new version of a piece of software or a new kernel and almost all "Howto-knowledge" instantly gets compltetly worthless and you can just hope that the howto got updated in the meantime to give you yet anoter step-by-step guide.
If Linux should get ready for grandma's desktop, it might be a worthy thing to go through all HowTos and Newbie-Guides and to actually fix the problems in the software itself, instead of trying to work around them in documentation.
The day when almost all HowTos got obsolete, thats the day where Linux is ready for the desktop. We are however not even close to that.
Installing is something you do exactly once, yes it should be as easy as possible and Debians install isn't. However I prefer to let the user get over a small hurdle first (Debian install can be mastered almost with just pressing 'return') and then have a 'smooth walk' (via apt-get and Co.), then to do it the other way around and make the install look easy, but than make every upgrade or change to the system a major pain. Just to often I have seen newbies getting a Linux system installed easily, but then being completly confused once they went to install stuff like the NVidia drivers, stuff they found on the net or when they just wanted to upgrade a piece of software. In Debian and Gentoo I can solve these newbie problems with a single line, in most other distros with a much smaller number of packages I can't.
Lets face it, GNU/Linux isn't end user ready by any means. It might work on moms desktop if the son is doing the adminstration, but its not going to work if 'mom' is doing everything alone. And as long as a beginners guide contains a 'shell intro' it probally never will be. Giving them a Debian install is thus only a honest way of what they have to expect from the rest of GNU/Linux.
And the locks alone without the laws would have have solved the problem of burglary? I kind of doubt that...
The law alone will of course not make the spam magically go completly away, but it will make sure that sending spam gets a pretty risky business, instead of a completly risk free one, so people might think twice before sending out a million spam mails. Sure this won't stop people from other countries, however reducing spam from the USA would be a pretty good start.
The GPL doesn't prevent forking, it just makes sure that code can be merged back and forth between the forks at all times, so that stuff like the WineX vs Wine scenario can never happen with the GPL.
That said, there are of course also a lot amazing images that are 100% done in Povray, but as said, that is than more done with fractals and stuff, than 'modeled'.
As an example see the Making of 'The wet bird'
Shadow passwords aren't a hashing mechanism, all they do is store the hashes in a file that the users can't read. Just Unix permissiosn, pretty trivial after all.
About crypt() vs MD5, I don't think that they make much different when it comes to cracking actual passwords, all MD5 does is allow you to use longer passwords, it doesn't enforce it by any means. If your password is in a dictonary, no matter what hashing algo you use, I can brute force it in a few seconds.
The only advantage a good hashing algorithm provides is that it ensures that you can't from a given hash calculate back the original password by other means than brute force. Brute force, however, will always work, no matter what algorithm you use. The only way to make a more secure password, is to use a better password, a better hash algo won't help a damn.
Depends heavily on who the actuall work does. If the programming is in large part fundet by Novell then I think its just fair that they get the copyright to make a little money with proprietary software, thats at least how Ghostscript works as far as I know.
When on the other side the community drives the projects and then some third party who might have in the ancient past be involved in the project gets all the copyright, than that would of course be fundamentally wrong and it would be time to no longer assign copyright to them.
Anyway, I think the biggest problem with the copyright assignment is the actually assignment itself, not the cause of it. Since the assignment itself makes it difficult for one-time contributors to actually contribute anything that is something more than a mimial patch, since that would involve paperwork, which can get quite complicated with different countries and differnt laws. As far as I remember that has at least for some GNU projects keep people from actually working more active on a project.
No, since the BSD license would give everybody the right to do whatever they want with the code, I doubt that is what Novell wants that.
As it stands now, only Novell can do what they want with the code, as they get the copyright, and everybody outside of Novell 'just' gets the GPLed version and can't thus reuse the code in a proprietary product as Novell can.
Doom ===;)
No, not really, it gets deeper than that. Far to often I had situations where I knew that a perfectly 100% working Linux driver for a piece of hardware exists, yet getting the hardware to work could still easily take multiple hours or even days, due to the extremly complicated and time-consuming process involved to install the drivers.
./configure && make, but more often I have to download a full kernel source tree, patch that, configure and compile that, not so fun if I have to switch from a custom distro kernel to the plain upstream one. Sometimes it gets worse and I have to actually had to recompile XFree86, which involved a nice 50mb download of source, rather painfull for non DSL users. Let alone that even if the driver, kernel and XFree86 version all match, you still have to actually configure the driver (editing XF86Config and that kind of fun).
Sure if you are lucky you just 'modprobe' and are done, but if that doesn't work you are pretty much alone in the woods and that happens actually rather frequenly with hardware that isn't two years old. First you have to find out why the hardware doesn't work (just me doing something wrong or is it a driver bug?), which requires google and lots of mailinglist reading, then you have to find out how to get the correct driver, then you have to install that driver, which involves a completly non-standard procedure, which so far changed with pretty much every kernel and piece of hardware that I had in hand. Sometimes I just have to
Hardware installation under Linux still results in counterless hours of pain, not because the hardware manufactures didn't provide drivers, but because Linux completly lacks any kind of standard on how to handle software outside of that what the distribution provides.
Doom3 looks pretty impressive overall, gameplay might be a bit to much run&shoot, but after all its meant to be a Doom, not a DeusEx, so I guess that is ok for those people who like that kind of games.
However one thing that really didn't impresse me was the representation of the player. It is again, like in far too many FPS before, just a flying pair of airms, no feet, no body. If you climb ladder he doesn't even use his arms. I mean how lame is that? 'Bugs' like that where tolerable in the early days of FPS, but with Doom3 being pretty much the technically most advance game of its genre its kind of sad that they havn't tried to make the player something more than just this flying body-less camera.
Actually, its not so much the kernel panic that replaces the BSOD on Linux, but the XFree86-freeze, which happens quite often when it comes to anything that is either fullscreen, OpenGL or does grab the mouse (the old 4.7 Netscape did that quite often and got stuck then). Sometimes you can kill the app from remote and get your X11 back, but far to often its a "bye,bye" and requires a X restart or reboot. Linux itself pretty much still runs without problem, but that doesn't help you much if your whole graphical interface doesn't move any more. And about switching to console, that is either not reachable (cause XFree eating the key presses) or unusable due to messed up graphic memory/mode.
From a users point of view I would say that Linux together with XFree86 is quite a bit worse than a WindowsXP when it comes to rendering the computer unuseable. Sure the kernel is still running, but what is that worth, if all my X11 applications have to be restarted? I just hope that sooner or later X11 proxies or a way for X11 clients to reconnect to the server become common so that one can restart XFree86 without losing all the running applications. That still wouldn't solve all problems with XFree86, but at least quite a lot.
Some graphical version of the good old magic sysreq might also be nice, ie. one that could restart XFree86, switch the graphic mode back to something sane and stuff like that, instead of just sync and reboot.
PS: Yeah, I know AllowDeactiveGrabs and AllowClosedownGrabs, but they don't help all that often, beside that hardly any user will know about them.
Gnome is designed with the 'newuser' in mind, but not the "switch-away-from-Windows" kind of newuser, but the "hasn't ever seen a Computer" before kind newuser. Sure this is a bit far away from reality, since the number of users that start with Linux as their first OS will be quite small. However I for one like that direction, since it focuses on doing things right and not on doing it wrong just because this other OS does it too.
Free Software doesn't really has much to sell, so I think this is a route that is worth to take. Some people might not like it at a first sigh, but I for one strongly prefer a slick and well designed overall user interface, then one that is build out of hacks and uglyness and is just the way it is for historic reasons. If people want something that looks and feels more like Windows, they already have KDE, so Gnome taking a different route can just be good for inovation and the overall end result.
About Spatial Nautilus, yes, for the first time computer user I think it is better. I for one loved the spatial interface on the Amiga and I like that that Gnome goes in the same direction. Even for the avarage user spatial might actually be better after a little period to get used to it. The failure is that there is no easy way to get rid of spatial Nautilus, after all for browsing anything but well organized flat home directories its rather useless.
The thing however where Gnome fails in large, isn't the basic idea, but the overall implementation. Good design means that the thing gets as simple as possible, but not simpler. Gnome for one however as a history of removing valuable configuration options and hidding them deep down in GConf, thus making simplifing things over the edge. Removing a not so much used config option, might be good for simplification and provide a little benefit for the computer-unknown user, but if it ends up in the normal users browsing for hours through GConf to get their configurations back up and running, Gnome people have really done something fundamentally wrong.
There is also a overall lack of focus on the average or advanced Linux user, after all most of them have at least some basic knowledge of the command line, so integrating that sanly into Gnome should be at a high priority. How come then that stuff like Nautilus when started from the console always goes to the Home directory, instead of the current one? Or that if I drag and drop a file into Gnome-Term I get an unescaped string, instead of a quoted one? How come that they removed/mutilated the Tab-completion of the GtkFileDialog, which was the one thing that the otherwise sucky FileDialog did extremly right and much better then the rest.
Overall Gnome people have done a lot of things right, but an equal amount of things extremly wrong. It will be interesting to see how things developed, after all one can hardly ignore the fact that there have been mistakes, if the Gnome people would start to finally listen to complains of long time Gnome users, we might end up with a extremly nice, powerfull and yet very simple desktop environment, if they however continue to ignore the advanced users Gnome will just end of as the DE for grandmas and nobody else who has used computers for a few years will make much use of it.