### but I think that statement not true due to multitudes of incompatible library versions and such
LSB is specfically for binary compatibilty, everything else would make little sense, since for most part its a standard for commercial vendors, less for the free software guys, which I think is one of the reasons why its adopted rather slowly. I have actually *never* seen a single LSB-conforming RPM in the wild, only once I know are examples on the LSB webpage itself.
But the sentence you where refering to is still incorrect, LSB doesn't mean that when you compile an app that it will magically run on another LSB system, LSB only means that you can run a LSB conforming binary, it says nothing (or little?!) about compiling stuff. To compile LSB binaries there is lsbdev, which is a collection of library stubs (kind of a mini-distri) against which you can compile, everything not provided by them you have to include in your binary.
### The best we can hope is that LSB compliance will guaratee source level compatibility
Source level compatibility is already a pretty much solved problem, heck, if you use portable libraries you can even more or less out of the box compile many stuff on Win32 or MacOSX. Sure, source compile is not always that beatifull, ie. pkg-config hacks instead of MacOSX-like '-framework', but it still works rather well.
Most of that sounds 'Deja vu', MarioKart, Metroid, Zelda, Sonic, Viewtifull Joe, Animal Crossing, etc. all games I have already played on other consoles numerous times. Might some of that be good games? Sure, but I really miss something thats new. Waiting for the same games over and over again, just with new graphics and new levels gets kind of boring over the years. AnotherCode so far is the only game I found which looks interesting to me.
### they could capture some console market and then facilitate for the same apps to be released on Linux
Just because something has written 'Linux' on it doesn't mean it will be compatible with something else that has 'Linux' written on it too. If any console developer ever creates a Linux based console, I am pretty sure that it will be rather incompatile to any Linux you can run on the PC. Sure you might find Emacs and Firefox ported to the console-linux, but console-games will never run on your PC linux, custom drivers, custom hardware, different CPU architecture, copy protected disc format and the like will make sure that a PC won't make much use of the games.
Just look at Linux for the PS2, first of it didn't had any games being based on it, ok it wasn't build for it, and secondly it was so tight locked that you couldn't even access the memory cards of your PS2. With WindowsCE on the Dreamcast its the same, its kind of there, but many games bypass it and no Dreamcast game ever was playable on your PC Windows.
The 'flop' part is that the DS still lacks games, especially games that make some decent use of the second screen. In the US this is quite a bit worse since the DS has there been out for ages without any games worth to talk about coming out, while in Europe its just a month out of the doors, making it kind of forgivable that there is no other decente game beside Mario64DS. The current Minigames are all fine and nice, but I doubt that I will be much interested in them in a few weeks/month when the first 'look cool new little feature' feeling has worn off. Even on the release list I couldn't find much interesting stuff at all, sure a new MarioKart would be nice and a new AdvanceWars might be fun as well, but been there done that.
About compatibilty of a new GBA with the DS, I kind of doubt it. The DS is simply a rather uniq device which makes compatibilty hard. Sure a new GBA might have a touchscreen, which I would actually like, but for sure it will not be the same size and resolution as the other screen, streching/blackborders like with Gameboy games on GBA is of course still possible. But then Nintendo has made it rather clear that DS is not a 'Gameboy', but some third kind of console, making it kind of hard to guess what their next step will be, they could either just dump the DS like the VirtualBoy and continue with GBA2, 'adopt' the DS into the Gameboy familay and let GBA2 follow its way or turn the DS into some kind of PDA widget with good game support and thus indeed hardening the 'third kind' thing. Compatibilty to the Gamecube might also be doable with a GBA2, but we will see what will come.
### but how many multi-disc Gamecube games have there been?
All the three ResidentEvils have been multi-disc and MetalGear is multi-disc too. Since those are among the few bigger third-party titles out there for Gamecube it clearly shows that those mini-discs are not enough for everybody. Sure, Nintendo games never used more then one disc, but third partys seem to have quite a bit more throuble to keeping there data small. I can live with them not using DVDs, after all DVD players far superior to what a PS2 can provide are cheap, but having a medium large enough to not requiring disc changes would be quite nice. Same can be said about the memory cards, which are also quite tiny, especially when compared to 256mb or even 512mb flash cards which I can get at basically the same price these days.
Something I have been wishing for for a long time is a stable Kernel ABI and/or API, so that all those drivers could be seperated out into seperate downloads instead of just one sumo-download with everything. I really don't see much good in having everything stuffed into a single source tarball, it only causes to you to download a whole bunch of stuff you will never ever use and also leads to careless changes to the kernel internals, which constantly break stuff that is distributed outside the kernel. Beside from that a stable ABI/API would make it quite a bit easier for hardware vendors to actually supply drivers. Yes, there is a risk that those would be closed ones, but many are already today and I for one would prefer a closed source drivers which I could use with some random kernel version over one that only runs with some very specific kernel version of some very specific distribution or even worse, no driver at all.
### I think the DS will fall in the latter category; its "innovative" features don't impress consumers as much as the PSP's, and game designers may or may not come up with any actually interesting uses for them.
I think the major fault of the DS is not that it has a second screen, but that the second screen is the same size as the other one, which makes it very attractive to a bunch of minigames, but rather wasted for normal games in the long run. What they should have done is making the second screen a little bit smaller while making the primary screen quite a bit larger. After all if you would have a foldable handheld with a larger screen the space between the controll-pad and the buttons would be unused anyway, so sticking a mini-screen there would do no harm. Beside from that I think that the second screen actually adds quite a bit to gameplay, since it basically allows mode-less gameplay, where you don't have to constantly switch around between inventory/map and the game, but where you are in-game 100% of the time.
If you are running in a multiuser environment with possibly untrustworthy or inexperienced users then yep, not having them all have root privileges is a hell of a lot saver. It protects the users privacy, avoids other people deleting each others data be it by intendion or accident or whatever.
In a home environment with just one user, who also happens to maintain the machine its however a whole differnt thing. All valuable data there is stored in $HOME anyway, so gaining root helps nothing to destroy valuable data, neither helps it with preventing spying of credit card info and such. Last not least switching from the user who maintains the machine to root is also rather trivial for some evil programm, either wait till 'sudo' is unlocked or install a trojan 'su' binary in the path or just listen to the X11 key events, sooner or later everybody will end up typing his password in on a self maintained machine. There are still a few things left like accidently 'dd'ing the harddisk with zeros or such, which are more or less prevented by not running at root, but then if you are dd'ing around you are probally running at root anyway. It might also help in making it impossible to accidently delete other partions like the window one. But there is really not much for which not running as root protects you on a single-user machine, the benefit is far more in that it clearly seperates the users data and the application data, so that programms don't end up storing user data in 'C:/Program Files/SomeApp/' like many do under windows, but in that they are forced to store in $HOME.
So should one run as non-root? Yep, last not least because a bunch of programms simply refuse to run as root, which would be quite annoying. But one shouldn't really have any illusions that one gains any kind of real advance in security in a single-user environment.
### The fact that some "idiots" complain about the quality of free software doesn't prevent in any way for other developers to produce good creative stuff.
The problem are not idiots complaining, but the lack of developers. The idiots are just giving you the last punch to even kill the last remaining spark of motivation.
### Is it really that hard to find someone with an original new idea for a game?
No, but its extremly hard to find developers when you have an original idee and that is really not that suprising. When you clone a game, everybody in the team instantly knows what the goal is, most of the developers know the game to develop more or less in and out. There are forums, newsgroups and such for the game to clone that you can use to find new developers. In the long run you can even switch maintainer and the programmers without much a problem, since everybody knows what the goal is. Now with an original idea this all falls apart, first of knowbody knows your idea, so you have a hard time finding people interested in it in the first place, but then you also have a very hard time to explain the idea to them. You can also not just swap out developers, since every newcome will have to be introduced to the idea again. If the gamedesigner drops out you can basically close the shop, since nobody will be left knowing exactly what the goal was. Last not least it all happens over the internet, which makes explaining stuff even more difficult then in a person to person meeting. In the end you can't even be sure that your idea actually works, stuff that might sound cool on paper might suck as game. So even if you get all those talents you need, you might still fail.
All this is not special for games, applications are as well much easier cloned than created from an original idea, KDE, Gnome and such are all just clones of Windows and a bit MacOSX, they are improved here and there, but the concept are pretty seldomly touching new ground and if they ever do they only to it in very small steps.
### Isin't this a horrible, horrible thing for professional graphic designers (if it holds to be true)?
Depends, when the graphic designer simply used a GPLed tool like Gimp he doesn't have to GPL his work, if he on the other side used a GPLed image from some clipart gallery, then yep, he would have to release the PSD/XCF file for the image. Would that be horrible? For the graphics designer maybe, but that might actually be exactly what the creator of the GPLed clipart intented, after all he spend time creating it, so why shouldn't the other share alike?
The throuble here however is that with images you might end up combining a lot of stuff, some might be GPL, some CC, some some royality free which is only allowed to use, but not to redistribute in source form. So the resulting work simply can't be licensed as GPL, since it includes copyrighted work which he might have no right to relicense.
Creative Common licenses address that to some extend, but they are incompatible with the GPL, which can cause throuble when you need to link your images into the binary, which is quite common for small applications or games, especially under windows.
Dual licensing is currently the best way to solve this, but its not really all that beatifull. Sadly the FSF hasn't done much at all to handle this situation a bit better and the GFDL is again far to special purpose to be usefull for other works of art (beside from it being more or less non-free of course).
### Why don't they just have people use ELinks / Lynx?
Because thats client side, if you are really low on bandwidth you want to filter the junk out before you have downloaded it, not afterwards. Lynx of course already kills of the biggest junk by not downloading images, but there is still a whole bunch of useless information left in the html that you can filter out to reduce the size quite a bit.
Absolutly, the Bitkeeper license kind of made it unavoidable in the long run.
### Is Linus angry with Tridge because it actually shows up his previous bad decision and the only way for him to save face is to badger Tridge?
I guess he is simply angry because Tridge made him lose his tool. It doesn't matter if Tridge was right or wrong, he simply caused the loss of Bitkeeper. If Tridge wouldn't have done it, somebody else would have sooner or later.
### Is McVoy behaving like a spoilt kid and taking his ball home because somebody didn't want to play his game?
Yes.
But still Linus decision to use Bitkeeper might have been right, even with all the turbulance, as he said they got two or three years of productive development out of this and now they are simply back at square one, where they started. Bitkeeper showed them how good SCM works, that it works and that its better than a bunch of scripts that Linus used before Bitkeeper.
It after all never was 'Linus gets rid of popular free software SCM and moves to Bitkeeper', but it was 'bunch of Linus personal scripts vs Bitkeeper', there never was and still isn't a Bitkeeper replacement available in the free software world. If the whole Bitkeeper throuble has shown something its that CVS isn't the holy grail and the free software world is better of replacing it with something more capable better sooner than later. Sadly the free software world simply needs a kick in the butt from time to time to move forward.
Good to know that Enterprise might have another chance of survival, but on the other side ST:ENT never was that great, it had a bunch of nice episodes, but far to many bad and boring ones, same was already true for Voyager and especially the last TNG movie was just awfull. So unless Enterprise gets significantly better I am really not so sure if bad StarTrek is really better than no StarTrek. Especially the comparism with Star Trek: Hidden Frontier makes ST:ENT and ST:VOY look bad. Hidden Frontier is a fan made series, just a green screen, a bit computer graphics with great 3d models and some make-up, yet they manage to pull off episodes that, while technically limited, are more interesting to watch then most of the average episodes of ST:ENT or Voyager. Which kind of tells about a lot about the official StarTrek stuff that made it to the TV in the last years.
Why drop Discovery into the ocean? Even the Buran shuttle had automatic landing capabilities quite a long while back, has the Space Shuttle still not caught up?
### In the real world, you can't assume the person already has Subversion installed on their system...
$ apt-get install subversion
or whatever your distro use. If you run windows you can find precompiled stuff at the subversion site.
### But I guess the real complexity of CVS and SVN isn't in the commands themselves. It's in the lack of quality documentation.
$ svn help
or if you need more: http://svnbook.red-bean.com/
Subversion has really a great interface, its basically the same as CVS, but with a lot of little annoyances removed, which make it quite easy to get.
### But if you are a complete newcomer to all of it, the documentation is nearly impossible to digest.
Well, sure. You shouldn't expect to read a book on version control and instantly get everything if you lack basic Unix knowledge, a beginners book on Shell and Unix or Linux in general might be more helpfull, but the basic add/remove/status/diff/commit stuff is really a matter of minutes to get, its really not much different then uploading a file via FTP.
The few line example I presented in the other comment really is ALL you need to get started and working and the commands in there are really all you will ever need in the first few months or even years of usage. If you use tortoisesvn you get all that even nicly integrated into the Windows explorer.
I am not saying that docu is 100% perfect, but I really see little reason to complain. If people don't even get a handfull of commands, how do you expect them to create software?
If all fails there is still #svn at irc.freenode.net and the mailinglist which will might help to clear up the remaining problems.
### But in my experience they're awfully difficult and complicated to set up and maintain, particularly CVS
Hm, not sure what you are talking about, in the case of SVN its:
$ svnadmin create myrepo $ svn co file://.../myrepo/ yourcheckout $ cd yourcheckout $ svn add your_file.txt $ svn commit -m "I commited a file"
and you are already up and running and getting your work done, CVS isn't much different. Access to the repo can happen via network by using ssh, again for both SVN and CVS. Setting up a commit mailing list again is also just a matter of inserting the right email address into some template file and renaming it.
So I really see nothing complicated in setting the thing up, especially if you have something like sf.net, berlios.de or the like that do already the most of the work for you. Sure CVS has some pitfalls, like not handling renamings to well, but those are either not to hard to workaround in most cases and secondly fixed by SVN. There are also some pitfalls with getting the file permissions and ownerships right for SVN, but those are easily fixed by a look in the quite good manual.
So overall I don't see how it could get much more simpler then that. Some additional graphical tools to handle merging and conflicts for sure would be nice and having support for distributed repositories would be great as well, but for most projects you can get your job done very confortably without those. Beside from that, those would be additional feature that would be nice to have and basically unrelated to the 'ease of administration' aspect.
Could anybody give some more details about this one:
a) Corruption. BK is a complicated system, there are >10,000 replicas of the BK database holding Linux floating around. If a problem starts moving through those there is no way to fix them all by hand. This happened once before, a user tweaked the ChangeSet file, and it costs $35,000 plus a custom release to fix it.
I really don't get how a single ChangeSet file could wreak havoc to all those repositories out there.
### Am I the only person that thinks the new Battlestar Galactica is by far the worst sci fi program in history?
Maybe you are the only one. For all its faults Battlestar Galactica was quite fun to watch for the first few episodes, not best scifi ever, but definitvly one of the better ones around. I agree that it got more boring and weird from episode to episode, so I mostly lost interest at end of season1, it all was just to much Cyclon playing mindgames and not much else. However compared to some other stuff its still reasonably good and far from being 'worst ever', its however neither 'best ever'. It simply started out far more interesting then it ended. We will see if they can make it interesting again in the second season, but I am sceptical as to how far they can stretch the 'run from cyclon' part out, especially since Battlestar Galactica already has a heapload of Cyclons on board...
### But even multiple computers performing a verify isn't _truly_ a verification.
But Joe Math Prof saying: "Yep, I verified it and its correct" is? I mean sure you shouldn't do a proof with a single programm on a single architecture, but whats the difference between multiple independed developed programms on multiple different architectures and a bunch of math guys verifing the proof? Both can be wrong at times, thats why you do the proof with a lot of intepended persons/computers to be reasonably sure that it is correct.
Why? I mean you don't prove that the human verifing the proof is 'correct' either. And well, I for one think that humans make quite a lot more random errors then computers. So I don't see why you have to proof the computer, but not the human.
One should of course ensure that the programm is correct and all as good as possible, but I don't see much difference between a proof verified by a bunch of independently written computer programms and a proof verified by a bunch of humans.
Get a big fat vacuum cleaner and cleanup the area where you want to build your house on the moon. After all there is no wind on the moon, so once the dust is cleaned up, it won't come back so quickly. If you drive of course around with some moon vehicle you might still have a bunch of dust issues left, but then maybe you can build roads up there.
I see nothing wrong with targeting everybody, actually I would consider it quite wrong to target somebody specific and leave out the rest. Software for Linux stays software for Linux, if I use Emacs at home or at a data center makes zero difference to the software itself. Sure the distro itself should provide some default package selections for different uses, but the software itself and the packages for it can stay 100% the same, no matter who uses them.
Aehm, no that doesn't produce a real one-pixel width circle either, just something that is somewhat close to a circle, but actually not even round. Beside that its a few orders of magnitudes harder to use then a simple circle tool which you will find in mainy other paint programms.
Slashdot Mirror
### but I think that statement not true due to multitudes of incompatible library versions and such
LSB is specfically for binary compatibilty, everything else would make little sense, since for most part its a standard for commercial vendors, less for the free software guys, which I think is one of the reasons why its adopted rather slowly. I have actually *never* seen a single LSB-conforming RPM in the wild, only once I know are examples on the LSB webpage itself.
But the sentence you where refering to is still incorrect, LSB doesn't mean that when you compile an app that it will magically run on another LSB system, LSB only means that you can run a LSB conforming binary, it says nothing (or little?!) about compiling stuff. To compile LSB binaries there is lsbdev, which is a collection of library stubs (kind of a mini-distri) against which you can compile, everything not provided by them you have to include in your binary.
### The best we can hope is that LSB compliance will guaratee source level compatibility
Source level compatibility is already a pretty much solved problem, heck, if you use portable libraries you can even more or less out of the box compile many stuff on Win32 or MacOSX. Sure, source compile is not always that beatifull, ie. pkg-config hacks instead of MacOSX-like '-framework', but it still works rather well.
### None of these sounds interesting?
Most of that sounds 'Deja vu', MarioKart, Metroid, Zelda, Sonic, Viewtifull Joe, Animal Crossing, etc. all games I have already played on other consoles numerous times. Might some of that be good games? Sure, but I really miss something thats new. Waiting for the same games over and over again, just with new graphics and new levels gets kind of boring over the years. AnotherCode so far is the only game I found which looks interesting to me.
### they could capture some console market and then facilitate for the same apps to be released on Linux
Just because something has written 'Linux' on it doesn't mean it will be compatible with something else that has 'Linux' written on it too. If any console developer ever creates a Linux based console, I am pretty sure that it will be rather incompatile to any Linux you can run on the PC. Sure you might find Emacs and Firefox ported to the console-linux, but console-games will never run on your PC linux, custom drivers, custom hardware, different CPU architecture, copy protected disc format and the like will make sure that a PC won't make much use of the games.
Just look at Linux for the PS2, first of it didn't had any games being based on it, ok it wasn't build for it, and secondly it was so tight locked that you couldn't even access the memory cards of your PS2. With WindowsCE on the Dreamcast its the same, its kind of there, but many games bypass it and no Dreamcast game ever was playable on your PC Windows.
### I wonder how you are defining "flop".
The 'flop' part is that the DS still lacks games, especially games that make some decent use of the second screen. In the US this is quite a bit worse since the DS has there been out for ages without any games worth to talk about coming out, while in Europe its just a month out of the doors, making it kind of forgivable that there is no other decente game beside Mario64DS. The current Minigames are all fine and nice, but I doubt that I will be much interested in them in a few weeks/month when the first 'look cool new little feature' feeling has worn off. Even on the release list I couldn't find much interesting stuff at all, sure a new MarioKart would be nice and a new AdvanceWars might be fun as well, but been there done that.
About compatibilty of a new GBA with the DS, I kind of doubt it. The DS is simply a rather uniq device which makes compatibilty hard. Sure a new GBA might have a touchscreen, which I would actually like, but for sure it will not be the same size and resolution as the other screen, streching/blackborders like with Gameboy games on GBA is of course still possible. But then Nintendo has made it rather clear that DS is not a 'Gameboy', but some third kind of console, making it kind of hard to guess what their next step will be, they could either just dump the DS like the VirtualBoy and continue with GBA2, 'adopt' the DS into the Gameboy familay and let GBA2 follow its way or turn the DS into some kind of PDA widget with good game support and thus indeed hardening the 'third kind' thing. Compatibilty to the Gamecube might also be doable with a GBA2, but we will see what will come.
### but how many multi-disc Gamecube games have there been?
All the three ResidentEvils have been multi-disc and MetalGear is multi-disc too. Since those are among the few bigger third-party titles out there for Gamecube it clearly shows that those mini-discs are not enough for everybody. Sure, Nintendo games never used more then one disc, but third partys seem to have quite a bit more throuble to keeping there data small. I can live with them not using DVDs, after all DVD players far superior to what a PS2 can provide are cheap, but having a medium large enough to not requiring disc changes would be quite nice. Same can be said about the memory cards, which are also quite tiny, especially when compared to 256mb or even 512mb flash cards which I can get at basically the same price these days.
Something I have been wishing for for a long time is a stable Kernel ABI and/or API, so that all those drivers could be seperated out into seperate downloads instead of just one sumo-download with everything. I really don't see much good in having everything stuffed into a single source tarball, it only causes to you to download a whole bunch of stuff you will never ever use and also leads to careless changes to the kernel internals, which constantly break stuff that is distributed outside the kernel. Beside from that a stable ABI/API would make it quite a bit easier for hardware vendors to actually supply drivers. Yes, there is a risk that those would be closed ones, but many are already today and I for one would prefer a closed source drivers which I could use with some random kernel version over one that only runs with some very specific kernel version of some very specific distribution or even worse, no driver at all.
I think the major fault of the DS is not that it has a second screen, but that the second screen is the same size as the other one, which makes it very attractive to a bunch of minigames, but rather wasted for normal games in the long run. What they should have done is making the second screen a little bit smaller while making the primary screen quite a bit larger. After all if you would have a foldable handheld with a larger screen the space between the controll-pad and the buttons would be unused anyway, so sticking a mini-screen there would do no harm. Beside from that I think that the second screen actually adds quite a bit to gameplay, since it basically allows mode-less gameplay, where you don't have to constantly switch around between inventory/map and the game, but where you are in-game 100% of the time.
If you are running in a multiuser environment with possibly untrustworthy or inexperienced users then yep, not having them all have root privileges is a hell of a lot saver. It protects the users privacy, avoids other people deleting each others data be it by intendion or accident or whatever.
In a home environment with just one user, who also happens to maintain the machine its however a whole differnt thing. All valuable data there is stored in $HOME anyway, so gaining root helps nothing to destroy valuable data, neither helps it with preventing spying of credit card info and such. Last not least switching from the user who maintains the machine to root is also rather trivial for some evil programm, either wait till 'sudo' is unlocked or install a trojan 'su' binary in the path or just listen to the X11 key events, sooner or later everybody will end up typing his password in on a self maintained machine. There are still a few things left like accidently 'dd'ing the harddisk with zeros or such, which are more or less prevented by not running at root, but then if you are dd'ing around you are probally running at root anyway. It might also help in making it impossible to accidently delete other partions like the window one. But there is really not much for which not running as root protects you on a single-user machine, the benefit is far more in that it clearly seperates the users data and the application data, so that programms don't end up storing user data in 'C:/Program Files/SomeApp/' like many do under windows, but in that they are forced to store in $HOME.
So should one run as non-root? Yep, last not least because a bunch of programms simply refuse to run as root, which would be quite annoying. But one shouldn't really have any illusions that one gains any kind of real advance in security in a single-user environment.
### How long have most of these games been around? Why aren't they getting talked about more?
Most of them have been around for at least a year, some of them more, some less. If you never heard of them before, you should probally visit:
* http://www.happypenguin.org/
Which has those and a lot more.
### The fact that some "idiots" complain about the quality of free software doesn't prevent in any way for other developers to produce good creative stuff.
The problem are not idiots complaining, but the lack of developers. The idiots are just giving you the last punch to even kill the last remaining spark of motivation.
### Is it really that hard to find someone with an original new idea for a game?
No, but its extremly hard to find developers when you have an original idee and that is really not that suprising. When you clone a game, everybody in the team instantly knows what the goal is, most of the developers know the game to develop more or less in and out. There are forums, newsgroups and such for the game to clone that you can use to find new developers. In the long run you can even switch maintainer and the programmers without much a problem, since everybody knows what the goal is.
Now with an original idea this all falls apart, first of knowbody knows your idea, so you have a hard time finding people interested in it in the first place, but then you also have a very hard time to explain the idea to them. You can also not just swap out developers, since every newcome will have to be introduced to the idea again. If the gamedesigner drops out you can basically close the shop, since nobody will be left knowing exactly what the goal was. Last not least it all happens over the internet, which makes explaining stuff even more difficult then in a person to person meeting. In the end you can't even be sure that your idea actually works, stuff that might sound cool on paper might suck as game. So even if you get all those talents you need, you might still fail.
All this is not special for games, applications are as well much easier cloned than created from an original idea, KDE, Gnome and such are all just clones of Windows and a bit MacOSX, they are improved here and there, but the concept are pretty seldomly touching new ground and if they ever do they only to it in very small steps.
### Isin't this a horrible, horrible thing for professional graphic designers (if it holds to be true)?
Depends, when the graphic designer simply used a GPLed tool like Gimp he doesn't have to GPL his work, if he on the other side used a GPLed image from some clipart gallery, then yep, he would have to release the PSD/XCF file for the image. Would that be horrible? For the graphics designer maybe, but that might actually be exactly what the creator of the GPLed clipart intented, after all he spend time creating it, so why shouldn't the other share alike?
The throuble here however is that with images you might end up combining a lot of stuff, some might be GPL, some CC, some some royality free which is only allowed to use, but not to redistribute in source form. So the resulting work simply can't be licensed as GPL, since it includes copyrighted work which he might have no right to relicense.
Creative Common licenses address that to some extend, but they are incompatible with the GPL, which can cause throuble when you need to link your images into the binary, which is quite common for small applications or games, especially under windows.
Dual licensing is currently the best way to solve this, but its not really all that beatifull. Sadly the FSF hasn't done much at all to handle this situation a bit better and the GFDL is again far to special purpose to be usefull for other works of art (beside from it being more or less non-free of course).
### Why don't they just have people use ELinks / Lynx?
Because thats client side, if you are really low on bandwidth you want to filter the junk out before you have downloaded it, not afterwards. Lynx of course already kills of the biggest junk by not downloading images, but there is still a whole bunch of useless information left in the html that you can filter out to reduce the size quite a bit.
### Could this situation been forseen?
Absolutly, the Bitkeeper license kind of made it unavoidable in the long run.
### Is Linus angry with Tridge because it actually shows up his previous bad decision and the only way for him to save face is to badger Tridge?
I guess he is simply angry because Tridge made him lose his tool. It doesn't matter if Tridge was right or wrong, he simply caused the loss of Bitkeeper. If Tridge wouldn't have done it, somebody else would have sooner or later.
### Is McVoy behaving like a spoilt kid and taking his ball home because somebody didn't want to play his game?
Yes.
But still Linus decision to use Bitkeeper might have been right, even with all the turbulance, as he said they got two or three years of productive development out of this and now they are simply back at square one, where they started. Bitkeeper showed them how good SCM works, that it works and that its better than a bunch of scripts that Linus used before Bitkeeper.
It after all never was 'Linus gets rid of popular free software SCM and moves to Bitkeeper', but it was 'bunch of Linus personal scripts vs Bitkeeper', there never was and still isn't a Bitkeeper replacement available in the free software world. If the whole Bitkeeper throuble has shown something its that CVS isn't the holy grail and the free software world is better of replacing it with something more capable better sooner than later. Sadly the free software world simply needs a kick in the butt from time to time to move forward.
Good to know that Enterprise might have another chance of survival, but on the other side ST:ENT never was that great, it had a bunch of nice episodes, but far to many bad and boring ones, same was already true for Voyager and especially the last TNG movie was just awfull. So unless Enterprise gets significantly better I am really not so sure if bad StarTrek is really better than no StarTrek. Especially the comparism with Star Trek: Hidden Frontier makes ST:ENT and ST:VOY look bad. Hidden Frontier is a fan made series, just a green screen, a bit computer graphics with great 3d models and some make-up, yet they manage to pull off episodes that, while technically limited, are more interesting to watch then most of the average episodes of ST:ENT or Voyager. Which kind of tells about a lot about the official StarTrek stuff that made it to the TV in the last years.
Why drop Discovery into the ocean? Even the Buran shuttle had automatic landing capabilities quite a long while back, has the Space Shuttle still not caught up?
### In the real world, you can't assume the person already has Subversion installed on their system...
$ apt-get install subversion
or whatever your distro use. If you run windows you can find precompiled stuff at the subversion site.
### But I guess the real complexity of CVS and SVN isn't in the commands themselves. It's in the lack of quality documentation.
$ svn help
or if you need more: http://svnbook.red-bean.com/
Subversion has really a great interface, its basically the same as CVS, but with a lot of little annoyances removed, which make it quite easy to get.
### But if you are a complete newcomer to all of it, the documentation is nearly impossible to digest.
Well, sure. You shouldn't expect to read a book on version control and instantly get everything if you lack basic Unix knowledge, a beginners book on Shell and Unix or Linux in general might be more helpfull, but the basic add/remove/status/diff/commit stuff is really a matter of minutes to get, its really not much different then uploading a file via FTP.
The few line example I presented in the other comment really is ALL you need to get started and working and the commands in there are really all you will ever need in the first few months or even years of usage. If you use tortoisesvn you get all that even nicly integrated into the Windows explorer.
I am not saying that docu is 100% perfect, but I really see little reason to complain. If people don't even get a handfull of commands, how do you expect them to create software?
If all fails there is still #svn at irc.freenode.net and the mailinglist which will might help to clear up the remaining problems.
### But in my experience they're awfully difficult and complicated to set up and maintain, particularly CVS
Hm, not sure what you are talking about, in the case of SVN its:
$ svnadmin create myrepo
$ svn co file://.../myrepo/ yourcheckout
$ cd yourcheckout
$ svn add your_file.txt
$ svn commit -m "I commited a file"
and you are already up and running and getting your work done, CVS isn't much different. Access to the repo can happen via network by using ssh, again for both SVN and CVS. Setting up a commit mailing list again is also just a matter of inserting the right email address into some template file and renaming it.
So I really see nothing complicated in setting the thing up, especially if you have something like sf.net, berlios.de or the like that do already the most of the work for you. Sure CVS has some pitfalls, like not handling renamings to well, but those are either not to hard to workaround in most cases and secondly fixed by SVN. There are also some pitfalls with getting the file permissions and ownerships right for SVN, but those are easily fixed by a look in the quite good manual.
So overall I don't see how it could get much more simpler then that. Some additional graphical tools to handle merging and conflicts for sure would be nice and having support for distributed repositories would be great as well, but for most projects you can get your job done very confortably without those. Beside from that, those would be additional feature that would be nice to have and basically unrelated to the 'ease of administration' aspect.
a) Corruption. BK is a complicated system, there are >10,000 replicas of the BK database holding Linux floating around. If a problem starts moving through those there is no way to fix them all by hand. This happened once before, a user tweaked the ChangeSet file, and it costs $35,000 plus a custom release to fix it.
I really don't get how a single ChangeSet file could wreak havoc to all those repositories out there.
### Am I the only person that thinks the new Battlestar Galactica is by far the worst sci fi program in history?
Maybe you are the only one. For all its faults Battlestar Galactica was quite fun to watch for the first few episodes, not best scifi ever, but definitvly one of the better ones around. I agree that it got more boring and weird from episode to episode, so I mostly lost interest at end of season1, it all was just to much Cyclon playing mindgames and not much else. However compared to some other stuff its still reasonably good and far from being 'worst ever', its however neither 'best ever'. It simply started out far more interesting then it ended. We will see if they can make it interesting again in the second season, but I am sceptical as to how far they can stretch the 'run from cyclon' part out, especially since Battlestar Galactica already has a heapload of Cyclons on board...
### But even multiple computers performing a verify isn't _truly_ a verification.
But Joe Math Prof saying: "Yep, I verified it and its correct" is? I mean sure you shouldn't do a proof with a single programm on a single architecture, but whats the difference between multiple independed developed programms on multiple different architectures and a bunch of math guys verifing the proof? Both can be wrong at times, thats why you do the proof with a lot of intepended persons/computers to be reasonably sure that it is correct.
Why? I mean you don't prove that the human verifing the proof is 'correct' either. And well, I for one think that humans make quite a lot more random errors then computers. So I don't see why you have to proof the computer, but not the human.
One should of course ensure that the programm is correct and all as good as possible, but I don't see much difference between a proof verified by a bunch of independently written computer programms and a proof verified by a bunch of humans.
### What do you ppl think?
Get a big fat vacuum cleaner and cleanup the area where you want to build your house on the moon. After all there is no wind on the moon, so once the dust is cleaned up, it won't come back so quickly. If you drive of course around with some moon vehicle you might still have a bunch of dust issues left, but then maybe you can build roads up there.
I see nothing wrong with targeting everybody, actually I would consider it quite wrong to target somebody specific and leave out the rest. Software for Linux stays software for Linux, if I use Emacs at home or at a data center makes zero difference to the software itself. Sure the distro itself should provide some default package selections for different uses, but the software itself and the packages for it can stay 100% the same, no matter who uses them.
Aehm, no that doesn't produce a real one-pixel width circle either, just something that is somewhat close to a circle, but actually not even round. Beside that its a few orders of magnitudes harder to use then a simple circle tool which you will find in mainy other paint programms.