The real question here is what is better for the internet? 20 good to excellent pages per year viewable in any browser out there or 50 pages with more layout than content and only good for IE?
First Question the article should have asked: Do the MMO operators want to add permadeath?
Answer: No. Otherwise they would already have it.
So we should just stop adding new features to games because they are not already added?
And I think you are right for commercial games but that doesn't mean a free game (doesn't have to get the largest possible userbase) couldn't pull perma-death off to create a totally new and different MMORPG.
Perhaps you would have to let the character act automatically. That way neither lag nor view-blocking windows would prevent fighting back. Perhaps settings to let the character run away
automatically from monsters too strong to fight would be a good idea too.
It sounds like you misinterpreting perma-death as something that will be introduced to current game systems while most other posters want to change the rest of the game too to compensate for perma-death.
Optimizing too early is seen as a mistake because you will most likely optimize where optimization has almost no effect. When you optimize later you can use a profiler to get hard facts about the location of the performance problems and get much better results.
Then I need to flip over to a shell prompt, login again, and kill the X server.
I could probably explain this to a newbie ten times faster over a telephone than "simple" things in Windows, like finding the Start Menu on a Taskbar the user accidently moved to the side or top of the screen or hid (which I don't know at that point; and yes that has happened more than one time).
WSH sucks because you have to learn a whole new interface (the scripting interface) to your normal apps. With Linux/Unix you use the same interface when scripting that is used when using the commandline apps directly.
Contrary to most other programs emacs has good reason to look/feel different. Instead of following the current trend emacs basically feels the same for the last 2-3 decades and across all platforms. If they would follow the current trend on every platfrom you would have not one but lots of editors and userbases. The userbase would also be much smaller since people don't want their editor to change every few years just to follow a (in terms of emacs lifetime) relatively short fashion.
Sorry about your experiences with Captive NTFS. I believe they package is/was unmaintained for a long time and uses a framework (LUFS) abandonded by its writers which might be the reason for your problems with it. Last time I checked it also had memory leaks.
I can't however agree with you on the "documentation disagrees with code" and the "nice with eyecandy on top of it, not so nice below" issues. I use exclusively config files (directly) to configure my apps and the system and those are mostly well documented and the documentation is accurate. They are also quite easy to use because of their linear nature. Most problems I had with Linux were in fact with the configuration frontends most newbie distros tend to use. That might be related to them following the development of the program they should configure which means they have to re-act when implementing new features. That is always more difficult than acting, what the original programmers do. Documentation lacking accuracy might suffer from the same problem. If you take e.g. Suse-Documentation it is at least 1 step more than necessary from the original programmer. That will multiply errors and delay documentation of the newer versions. Chances are good the documentation writer is not using the program him/herself. If someone then translates/localizes this documentation you are even further away from the authorative source.
You might have a point about consistent (multiple things are usually less consistent than one thing) but my Linux Windowmanager is rock stable. I can even recover from app crashs 99% of the time. Most app crashs of DirectX or other fullscreen apps render Windows useless.
There is no "in-house" for Linux. It is Open Source and is developed by people around the world. Every discussion about it that is relevant to more than a hand full of people must be public because you would never get a date and time where everyone is available.
Real "hand compilation" is probably only done by compiler developers. Everyone else who wants to create Assembler manually creates it directly without a higher programming language implementation.
Slashdot Mirror
Then perhaps someone should add some sort of "Never show this window again for this plugin" option to that window.
The real question here is what is better for the internet? 20 good to excellent pages per year viewable in any browser out there or 50 pages with more layout than content and only good for IE?
And I think you are right for commercial games but that doesn't mean a free game (doesn't have to get the largest possible userbase) couldn't pull perma-death off to create a totally new and different MMORPG.
Perhaps you would have to let the character act automatically. That way neither lag nor view-blocking windows would prevent fighting back. Perhaps settings to let the character run away automatically from monsters too strong to fight would be a good idea too.
It sounds like you misinterpreting perma-death as something that will be introduced to current game systems while most other posters want to change the rest of the game too to compensate for perma-death.
Optimizing too early is seen as a mistake because you will most likely optimize where optimization has almost no effect. When you optimize later you can use a profiler to get hard facts about the location of the performance problems and get much better results.
I don't think a Laptop with a polar bear sitting on it is able to steal much bandwidth.
Compression is most likely the same independent from the medium used.
Might be related to those people not being the same people.
What exactly do you do at a "not particularly large site" that generates 16 TB of changes every day? Definitely not the typical office usage.
MSFT discovered Raid 1?
It is not part of the USA but it is part of Oceania
WSH sucks because you have to learn a whole new interface (the scripting interface) to your normal apps. With Linux/Unix you use the same interface when scripting that is used when using the commandline apps directly.
Actually for most of us it is just games because one game can not be substituted for a similar game (which works quite well for apps).
Contrary to most other programs emacs has good reason to look/feel different. Instead of following the current trend emacs basically feels the same for the last 2-3 decades and across all platforms. If they would follow the current trend on every platfrom you would have not one but lots of editors and userbases. The userbase would also be much smaller since people don't want their editor to change every few years just to follow a (in terms of emacs lifetime) relatively short fashion.
Sorry about your experiences with Captive NTFS. I believe they package is/was unmaintained for a long time and uses a framework (LUFS) abandonded by its writers which might be the reason for your problems with it. Last time I checked it also had memory leaks.
I can't however agree with you on the "documentation disagrees with code" and the "nice with eyecandy on top of it, not so nice below" issues. I use exclusively config files (directly) to configure my apps and the system and those are mostly well documented and the documentation is accurate. They are also quite easy to use because of their linear nature. Most problems I had with Linux were in fact with the configuration frontends most newbie distros tend to use. That might be related to them following the development of the program they should configure which means they have to re-act when implementing new features. That is always more difficult than acting, what the original programmers do. Documentation lacking accuracy might suffer from the same problem. If you take e.g. Suse-Documentation it is at least 1 step more than necessary from the original programmer. That will multiply errors and delay documentation of the newer versions. Chances are good the documentation writer is not using the program him/herself. If someone then translates/localizes this documentation you are even further away from the authorative source.
You might have a point about consistent (multiple things are usually less consistent than one thing) but my Linux Windowmanager is rock stable. I can even recover from app crashs 99% of the time. Most app crashs of DirectX or other fullscreen apps render Windows useless.
There is no "in-house" for Linux. It is Open Source and is developed by people around the world. Every discussion about it that is relevant to more than a hand full of people must be public because you would never get a date and time where everyone is available.
Don't forget to use an un-journaled filesystem, otherwise you might have problems achieving the desired data corruption on UPS-powerdown.
Real "hand compilation" is probably only done by compiler developers. Everyone else who wants to create Assembler manually creates it directly without a higher programming language implementation.
and:
c. That they have the same bugs/security holes they had when you packaged your app
That (ratings via google) wouldn't be a bad idea for regular websites either.
TV content isn't quality based either.