Twenty seconds seems an eternity to wait. Especially for something as trivial as looking up a phone number, or someone's address.
I mean, you can do this in two to four seconds if you just had a regular address book. Every handheld designer knows this, and their power up times are minimal. Even my vernerable Newton powered up in about a second (and that's 1990's tech).
If desktops are going to be competitive in this computing niche, the boot times (and hibernation times) really need improvement. I'm not sure access to email is the key, but I imagine it's an akward step towards addressing the problem.
Being a BIOS minimalist, I'd hope they speed up the OS boot/restore times before this becomes the next fad. But when have we successfully pressured MS to speed up it's OS?
Some (like LinuxBIOS) have boot times under a second from cold start to mounting / (root).
Each comes with their own strenghts (and weaknesses). The trick will be to get everyone to adopt a better BIOS than the one pre-installed on their computer. Messing around with BIOS isn't as easy as messing around with a new web browser, so don't expect mass adoption any time soon.
When citizens are simply passing info along to authorities, then they are probably doing a civic duty.
However, when groups band together to promote their particula agenda, they'll often do their best to defame, embarrass, harass, and punish their transgressors. This is done without any due process because they don't have guidlines imposed upon them. If you try to defend yourself against this kind of defamation, it cements the group's belief that they got it right (or why would you be so upset?)
To borrow from a passage at http://web.mit.edu/gtmarx/www/candcomentary.html "Let me next turn to five areas that I hope future research can address. These are 1) a possible increase in individually aggressive and passive anticrime actions; (2) the privatization of government services; (3) t he spread of access and location control strategies and the changing nature of public-private space; (4) racial and ethnic conflict; and (5) a society of informers."
None of which are terribly appealing, but likely should groups of people take this "vigilante policing" too far.
It's unfair to assume that everyone can solve all of their problems without some sort of assistance. The process of moving from "newbie" to "seasoned" is one of mostly learning where to look and which mistakes to never make.
Along the way you'll gain insight into software operation, networking, and a whole lot more. But expecting people to just edit files directly assumes a lot. They need to find a text editor (not the more familiar word processor), be able to use it, and undestand both the domain of the problem and the config file syntax.
This can all be learned, buy when it's not cost effective, why bother?
Computers are not just for the trained, they are being thrust upon the unwashed masses too. Expecting my stepfather (and avid linux fan) to learn about/etc/sysconfig files would be unrealistic, as he's much more valueable as a CPA. Nor does he expect me to understand the subtlies (and yes, they do exist) of tax law.
Yes, he has fixed his own problems, but often he'll just invite me over to save him the six or eight hours of tinkering time compared to my five minutes. That leaves him with eight extra billable hours. God bless CPAs, they have a good idea about cost/benefit ratios, return on investment, and they insist on paying (something) for everything, even if it's family.
Newbies are not idiots, they are often just people who don't find value in learning about a craft that we care dearly about. Thank goodness, or we'd all be punduits without even a choir to preach to (or employ us).
Apache supports the inclusion of files into it's (normally) one config file format. This means that you can use the Include directive to move a portion of the config file into another file on the file system.
These other files can have different permissions, and if ACL is your cup of tea, you can set it up and enjoy. Or you can use the standard user/group/other UNIX permission set as you like. How you slice and dice the file is up to you.
But who would really do this anyway? Apache is a server, and you don't take a server and distribute the configuration between a group of people, each that can only touch these bits, but not those. You give the power to the administrator of the machine (or the server).
With a fragmented server configuration you run the risk of someone setting thier own slice of control to some nonsense which stops or cripples the operation of the entire server. With the apache http server, those who need to tweak their own hosting permissions can do so without fancy ACLs and a fragmented config file system. That's what.htaccess is all about.
Mabye there's a time and place where your argument will be much stronger, but Apache's HTTP server isn't the best example for proving your point.
Plan 9 (the OS, not the movie) really turned everything into a (very glorified) file system. It was interesting, but after using it, there seem to be limits as to what is comfortably put into a configuration file system, and what is better off in a plain vanilla config file.
NewtonOS took a completely different approach, it didn't have a file system per se, rather it had a underlying database. Configuration issues did not disappear, but they were much easier (my opinion) to handle. Some found it inconvienent to have documents be entries in a database, but that may have been a side effect of it's novelty.
Perhaps the real problem is that file systems (in general) make lousy databases? Look at the clunky implementation of the registry "find" function, and you'll see that an elegant solution is begging to be found.
Sendmail's config file has documentation. It may be long and unfriendly, but it is possible to understand it.
Most of these "issues" wouldn't even exist if the documentation was clear, concise, and available. Then we would be saying:
Of course it should be 13, 13 means "load last file upon launching".
Whether it's Autodesk's fault for not including some sort of documentation, or MS's fault for not requiring descriptive strings for elements in the registry is up for debate. The prevailing opinion that the MS registry sucks (as it exists today) is hardly every questioned.
For so many companies (including Microsoft) to be using the MS registry so badly, I'd shudder to think that best pratices concerning the registry are being followed (or even published).
The windows registry sucks because it's a bad implementation of a good idea.
Not all people like the idea of a database to hold you're configuration information, but data is data, and if you hold it in a database or a flat file the end result is the same.
The "suckiness" of the windows registry comes from how badly they implemented the thing, and the incredible lack of accessible documentation in it's early release. Somehow you're supposed to know that
HKEY_LOCAL_MACHINE -> SOFTWARE ->Autodesk ->
AutoCAD -> R14.0 -> ACAD-12:409 ->
Applications -> AecBase -> LOADCTRLS is supposed to be set to 0x0000000d (13) (as opposed to say 5)
Add to that a bad heirarchial organization where you often find directory trees that are confusing in their similarity, and thousands (or so it seems) of entries which are similar but not identical. For example, both "system" and "System" are in the registry multiple times. Sometimes chaning a "system" to a "System" breaks things, other times it does not.
Finally you have my favorites, directories with nearly no meaning at all (at least none that can be discerned) such as:
HKEY_CLASSES_ROOT ->.$A (and it's kin)
You have to look at the contents of these beauties to try to figure out what it is they are describing.
The registry idea isn't bad. Some may not like it, but others do. But certainly, the Windows Registry totally sucks (as in, my will to live).
I can't speak about YaST, because it's just now available and it takes time to adopt such things, but I can tell you the answer could be a resounding YES.
Compare the situation with RedHat's installer Anaconda. Anaconda has been open for quite some time now, and by being open my company (and a large number of others) have been able to build custom "in-house" distros for the automated installation of systems.
In our case, it's as simple as deciding if it's going to be a desktop, network monitoring server, vanilla RedHat box, proxy/firewall, or Tomcat server, and then booting the system off a floppy to perform the install (or re-install).
This would not be feasible without Anaconda being open; however, the reason it's not adopted more often is because it takes time to wade through the numerous little problems to figure out why it's not working in your case (and honestly, not that many people need this kind of functionality).
I'd say that YaST is great for the average user, not just the newbie. Diehard system admins usually won't use an all-in-one gui anyway, but when they do, they expect a lot more from it than is expected by the average user.
My only gripe with YaST was once I ran into a nasty corner case. YaST had the options (and yes, there are times when there's no gui for the bit you want to twiddle) but they didn't work as advertised. As a result I had to partially configure my software by hand and partially via YaST. It was horrible, and took more than 10 times the effort of doing the whole thing by hand in the first place.
I strongly advocate (and I'm sure others do too) that should you use a GUI config tool, use it consistently and exclusively. Most GUI tools are mature enough to handle all the common setup and admin needs for the average user. Some people feel that using a GUI is slightly more risky since there may be a day when the GUI doesn't go where you need to, but in my experience that rarely happens these days.
Note that there is always an exception, and in this case it is RedHat/Fedora. Their config architecture of a database oriented back end which parses the config files and monitors for manual updates (via timestamps) and a GUI front end that connects via network interface isn't exactly lightweight, but at least it's a system that is designed to handle both methods of updating. And no, I'm not referring to their older RedHat configure-everything-with-this-one-app tool, may it rest in peace (forever).
Remember that the consumers are not the only people who "lost" in the dissapperance of Loki. Loki's investors were also harmed, and although they will have better luck getting water from a stone, they feel that even a dollar from Loki's residual property should be made, it should go to them. The footed the bill for Loki's downfall, and they should reap any (even a miserable) profit.
Morally it is less decided, but legally you are still depriving Loki's investors of money they lay claim to. But these guys won't want to loose another dollar in ressurecting Loki, they are holding out for a (phantom) company to realize what they have is valueable (and buy it off of them for millions).
The main reason this hasn't happened yet is probably because what they have isn't nearly worth what they want. In other words, they're dreaming.
I certainly agree with your assessment, there are safety lockouts, and they should prevent the death of line crews.
However, you fail to address the problems that sometimes happen with electrical distribution, and these problems are what kills (with a little help from the software).
It's rare, but sometimes the line crew locks out the wrong piece of equipment. Experienced crews will do this when they get careless, and new crews sometimes do this if they have poor training. Then the software (or actually the operator in the control room) is the last chance to save the crew's life. Hopefully they've (via software) attached an informational tag to indicate that the crew is working on the line and the equipment shouldn't be activiated.
Of course that's assuming that all of the wiring was verified correct, the configuration information in the RTU is identical to the wiring, the configuration database in the control center is identical to that of the RTUs in the system, and the display elements have been mapped to the eqipment they mean to represent. It's a huge effort to verify that there are no misconfigurations anywhere in the system, and the standards and controls in place do an incredible job of guranteeing exact operation.
In the end, the system can still fail (although it's extremely rare), but will only fail when two or (usually) more related mistakes are made back to back. And yes, it is taken a lot more seriously, even the programming is taken much more seriously. For example, my company will provide (at no cost) bug fixes over the lifetime of the product with a turnaround time often measured in days.
Language professors and designers have long understood the need to present extensible yet constrictive environments which allow enough flexibility to get the job done, yet prevent the programmers from shooting themselves in the foot.
The hard part is coming up with one that's easily readable, maintainable, fast, flexible, portable, reusable, and safe. Of course, all of those adjectives have different meanings in the eyes of their beholders.
I think it was the Intel inside marketing campaign that really did the trick.
Nobody knows if Intel is better, but they don't want a computer that "lacks" Intel inside. They simply guess that if it's inside, it's better than not having it inside.
It is brilliant. It can't be copied or AMD looks like a "me too!" player. It can't be contested because it's just vauge enough to not claim that the machine is any better for having Intel inside, but implies that anything else is somehow inferior.
Most debates about distributions don't amount to much anyway, so they are handled quite nicely. You're doing the right thing by trying out a few different ones, but you can save some time by avoiding any of the ones that sound too "exotic".
Using one distribution versus another won't have a day or night impact on your use of Linux until you get into the portions where the various flavors differ. On excellent example of this is in administration. The average user usually does very little administration, but it often becomes more important over time, and Linux is no exception. Learning one distrobution's administration often will leave you in the dark about another's. If you dig deep enough it often will become the same, but when you dig that deep, you're probably not using your distrobutions administration packages anymore anyway.
When in doubt, remember that the larger and more active distrobutions often have more people in your exact situation who may advertise thier soultion to a similiar problem on the internet.
Starcraft, Warcraft, etc. are in the same genre. If she dosen't like the genre she won't like any of them.
Pick something that she might like, and then stand back and let her enjoy it. Mine really cleans up when we play Scrabble, and she's a regular at the yahoo word related games, "Text Twist", etc.
If you want prior art, look at the history of the male / female chess leagues. The creation of sparate leagues actually increased the sexisim debates. Soon the women's league was know for it's weaker players who were often derived the opportunity to play against their stronger male counterparts. It got so bad that (arguably) the best women players made it a point to play in the conventionally men's tournaments. Some were even as bold as to say it was impossible to improve unless they played against stronger opponents.
Video games, like chess, fail to use a sex's sexual characteristics to give one sex a distinct advantage over the other. Separate leagues aren't necessary, and if there's an all female team, that should be a choice of comaraderie and not adminstration.
Wow, how many web nanny programs will filter this post?
Mabye KDE will be the killer app, and I'd be glad to see it happen.
But sometimes I wonder if the killer app is still alive and well. Often the killer apps of the past were the programs that added functionality which was not present prior to their introduction or not popularized until one app broke critical mass.
I can't recall a killer app that provided the same (or even slightly better) functionality as a popular pre-existing one. Mabye it's because it's late and I'm tired, or mabye the answer is so oboviously painful I can't see it.
Feel free to point out the ones that shined who didn't create their niches.
One of the best and most unappreciated features of KDE is it's inherit troll value.
I'm sorry to post such a blatantly inflammatory gripe, and please don't reply to it in kind. Just be aware that the whole KDE vs. Gnome conversation is quickly degrading to the same sort of drivel that existed in the vi vs. emacs, gui vs. cli, X vs. Y debates.
Both KDE and Gnome are reasonably good programming environments (meaning I can program in both without requiring corrective surgery or extreme pain) and they both do a good job of managing, unifying, homogenizing, and (whatever) of the desktop.
If they come from two licensing lineages, so be it. I'm not worried about the environment / license you are going to choose, I'm going to choose the one I feel most comfortable with and has licensing (at cost or otherwise) that allows me to use it as I need. I'll assume you will do the same.
Less "better than Gnome!" or "worse than Gnome!" and more "it's really great that it has cleaned up feature X" please.
I apologize for such a rant, thank you for putting up with it.
Having a cousin that just came back from the Iraq conflict sans use of an arm, I'd say your statement is in poor taste.
It's easy to believe that nothing happens in these far off, remote conflicts, but in reality there are real people going over there doing things that likely could get them killed (even if the enemy is not present)
I can vouch that while over in the Desert Storm conflict, the news back home seemed really strange to me (standing in the arena). Truth is, it's mostly wrong, or exaggerated, or fabricated, or seen from a point of view that is more concerned with ratings than reality. Read the news from several different sources (as unrealted as possible) and you'll start to get an idea of what's happening.
Slashdot Mirror
Twenty seconds seems an eternity to wait. Especially for something as trivial as looking up a phone number, or someone's address.
I mean, you can do this in two to four seconds if you just had a regular address book. Every handheld designer knows this, and their power up times are minimal. Even my vernerable Newton powered up in about a second (and that's 1990's tech).
If desktops are going to be competitive in this computing niche, the boot times (and hibernation times) really need improvement. I'm not sure access to email is the key, but I imagine it's an akward step towards addressing the problem.
Being a BIOS minimalist, I'd hope they speed up the OS boot/restore times before this becomes the next fad. But when have we successfully pressured MS to speed up it's OS?
Try already exists.
Look at:
LinuxBIOS: http://www.linuxbios.org/index.html
OpenBIOS: http://www.openbios.info/
FreeBIOS: http://freebios.sourceforge.net/
GBIOS: http://www.agelectronics.co.uk/gbios/
Some (like LinuxBIOS) have boot times under a second from cold start to mounting / (root).
Each comes with their own strenghts (and weaknesses). The trick will be to get everyone to adopt a better BIOS than the one pre-installed on their computer. Messing around with BIOS isn't as easy as messing around with a new web browser, so don't expect mass adoption any time soon.
When citizens are simply passing info along to authorities, then they are probably doing a civic duty.
However, when groups band together to promote their particula agenda, they'll often do their best to defame, embarrass, harass, and punish their transgressors. This is done without any due process because they don't have guidlines imposed upon them. If you try to defend yourself against this kind of defamation, it cements the group's belief that they got it right (or why would you be so upset?)
To borrow from a passage at http://web.mit.edu/gtmarx/www/candcomentary.html
"Let me next turn to five areas that I hope future research can address. These are
1) a possible increase in individually aggressive and passive anticrime actions;
(2) the privatization of government services;
(3) t he spread of access and location control strategies and the changing nature of public-private space;
(4) racial and ethnic conflict; and
(5) a society of informers."
None of which are terribly appealing, but likely should groups of people take this "vigilante policing" too far.
Yes, but they have no banannas today.
It's unfair to assume that everyone can solve all of their problems without some sort of assistance. The process of moving from "newbie" to "seasoned" is one of mostly learning where to look and which mistakes to never make.
/etc/sysconfig files would be unrealistic, as he's much more valueable as a CPA. Nor does he expect me to understand the subtlies (and yes, they do exist) of tax law.
Along the way you'll gain insight into software operation, networking, and a whole lot more. But expecting people to just edit files directly assumes a lot. They need to find a text editor (not the more familiar word processor), be able to use it, and undestand both the domain of the problem and the config file syntax.
This can all be learned, buy when it's not cost effective, why bother?
Computers are not just for the trained, they are being thrust upon the unwashed masses too. Expecting my stepfather (and avid linux fan) to learn about
Yes, he has fixed his own problems, but often he'll just invite me over to save him the six or eight hours of tinkering time compared to my five minutes. That leaves him with eight extra billable hours. God bless CPAs, they have a good idea about cost/benefit ratios, return on investment, and they insist on paying (something) for everything, even if it's family.
Newbies are not idiots, they are often just people who don't find value in learning about a craft that we care dearly about. Thank goodness, or we'd all be punduits without even a choir to preach to (or employ us).
Apache supports the inclusion of files into it's (normally) one config file format. This means that you can use the Include directive to move a portion of the config file into another file on the file system.
.htaccess is all about.
These other files can have different permissions, and if ACL is your cup of tea, you can set it up and enjoy. Or you can use the standard user/group/other UNIX permission set as you like. How you slice and dice the file is up to you.
But who would really do this anyway? Apache is a server, and you don't take a server and distribute the configuration between a group of people, each that can only touch these bits, but not those. You give the power to the administrator of the machine (or the server).
With a fragmented server configuration you run the risk of someone setting thier own slice of control to some nonsense which stops or cripples the operation of the entire server. With the apache http server, those who need to tweak their own hosting permissions can do so without fancy ACLs and a fragmented config file system. That's what
Mabye there's a time and place where your argument will be much stronger, but Apache's HTTP server isn't the best example for proving your point.
Plan 9 (the OS, not the movie) really turned everything into a (very glorified) file system. It was interesting, but after using it, there seem to be limits as to what is comfortably put into a configuration file system, and what is better off in a plain vanilla config file.
NewtonOS took a completely different approach, it didn't have a file system per se, rather it had a underlying database. Configuration issues did not disappear, but they were much easier (my opinion) to handle. Some found it inconvienent to have documents be entries in a database, but that may have been a side effect of it's novelty.
Perhaps the real problem is that file systems (in general) make lousy databases? Look at the clunky implementation of the registry "find" function, and you'll see that an elegant solution is begging to be found.
Sendmail's config file has documentation. It may be long and unfriendly, but it is possible to understand it.
Most of these "issues" wouldn't even exist if the documentation was clear, concise, and available. Then we would be saying:
Of course it should be 13, 13 means "load last file upon launching".
Whether it's Autodesk's fault for not including some sort of documentation, or MS's fault for not requiring descriptive strings for elements in the registry is up for debate. The prevailing opinion that the MS registry sucks (as it exists today) is hardly every questioned.
For so many companies (including Microsoft) to be using the MS registry so badly, I'd shudder to think that best pratices concerning the registry are being followed (or even published).
The windows registry sucks because it's a bad implementation of a good idea.
.$A
Not all people like the idea of a database to hold you're configuration information, but data is data, and if you hold it in a database or a flat file the end result is the same.
The "suckiness" of the windows registry comes from how badly they implemented the thing, and the incredible lack of accessible documentation in it's early release. Somehow you're supposed to know that
HKEY_LOCAL_MACHINE -> SOFTWARE ->Autodesk ->
AutoCAD -> R14.0 -> ACAD-12:409 ->
Applications -> AecBase -> LOADCTRLS
is supposed to be set to 0x0000000d (13)
(as opposed to say 5)
Add to that a bad heirarchial organization where you often find directory trees that are confusing in their similarity, and thousands (or so it seems) of entries which are similar but not identical. For example, both "system" and "System" are in the registry multiple times. Sometimes chaning a "system" to a "System" breaks things, other times it does not.
Finally you have my favorites, directories with nearly no meaning at all (at least none that can be discerned) such as:
HKEY_CLASSES_ROOT ->
(and it's kin)
You have to look at the contents of these beauties to try to figure out what it is they are describing.
The registry idea isn't bad. Some may not like it, but others do. But certainly, the Windows Registry totally sucks (as in, my will to live).
I can't speak about YaST, because it's just now available and it takes time to adopt such things, but I can tell you the answer could be a resounding YES.
Compare the situation with RedHat's installer Anaconda. Anaconda has been open for quite some time now, and by being open my company (and a large number of others) have been able to build custom "in-house" distros for the automated installation of systems.
In our case, it's as simple as deciding if it's going to be a desktop, network monitoring server, vanilla RedHat box, proxy/firewall, or Tomcat server, and then booting the system off a floppy to perform the install (or re-install).
This would not be feasible without Anaconda being open; however, the reason it's not adopted more often is because it takes time to wade through the numerous little problems to figure out why it's not working in your case (and honestly, not that many people need this kind of functionality).
I'd say that YaST is great for the average user, not just the newbie. Diehard system admins usually won't use an all-in-one gui anyway, but when they do, they expect a lot more from it than is expected by the average user.
My only gripe with YaST was once I ran into a nasty corner case. YaST had the options (and yes, there are times when there's no gui for the bit you want to twiddle) but they didn't work as advertised. As a result I had to partially configure my software by hand and partially via YaST. It was horrible, and took more than 10 times the effort of doing the whole thing by hand in the first place.
I strongly advocate (and I'm sure others do too) that should you use a GUI config tool, use it consistently and exclusively. Most GUI tools are mature enough to handle all the common setup and admin needs for the average user. Some people feel that using a GUI is slightly more risky since there may be a day when the GUI doesn't go where you need to, but in my experience that rarely happens these days.
Note that there is always an exception, and in this case it is RedHat/Fedora. Their config architecture of a database oriented back end which parses the config files and monitors for manual updates (via timestamps) and a GUI front end that connects via network interface isn't exactly lightweight, but at least it's a system that is designed to handle both methods of updating. And no, I'm not referring to their older RedHat configure-everything-with-this-one-app tool, may it rest in peace (forever).
Too good to pass up...
Redmond city limits?
Sorry for the upset, but no it isn't legal.
Remember that the consumers are not the only people who "lost" in the dissapperance of Loki. Loki's investors were also harmed, and although they will have better luck getting water from a stone, they feel that even a dollar from Loki's residual property should be made, it should go to them. The footed the bill for Loki's downfall, and they should reap any (even a miserable) profit.
Morally it is less decided, but legally you are still depriving Loki's investors of money they lay claim to. But these guys won't want to loose another dollar in ressurecting Loki, they are holding out for a (phantom) company to realize what they have is valueable (and buy it off of them for millions).
The main reason this hasn't happened yet is probably because what they have isn't nearly worth what they want. In other words, they're dreaming.
I certainly agree with your assessment, there are safety lockouts, and they should prevent the death of line crews. However, you fail to address the problems that sometimes happen with electrical distribution, and these problems are what kills (with a little help from the software). It's rare, but sometimes the line crew locks out the wrong piece of equipment. Experienced crews will do this when they get careless, and new crews sometimes do this if they have poor training. Then the software (or actually the operator in the control room) is the last chance to save the crew's life. Hopefully they've (via software) attached an informational tag to indicate that the crew is working on the line and the equipment shouldn't be activiated. Of course that's assuming that all of the wiring was verified correct, the configuration information in the RTU is identical to the wiring, the configuration database in the control center is identical to that of the RTUs in the system, and the display elements have been mapped to the eqipment they mean to represent. It's a huge effort to verify that there are no misconfigurations anywhere in the system, and the standards and controls in place do an incredible job of guranteeing exact operation. In the end, the system can still fail (although it's extremely rare), but will only fail when two or (usually) more related mistakes are made back to back. And yes, it is taken a lot more seriously, even the programming is taken much more seriously. For example, my company will provide (at no cost) bug fixes over the lifetime of the product with a turnaround time often measured in days.
I agree, and remember this:
The American economy is expanding at a rate lower than that of the American work force.
So yes, there are more jobs this year, but there's also even more people fighting for them.
I can't agree more.
Language professors and designers have long understood the need to present extensible yet constrictive environments which allow enough flexibility to get the job done, yet prevent the programmers from shooting themselves in the foot.
The hard part is coming up with one that's easily readable, maintainable, fast, flexible, portable, reusable, and safe. Of course, all of those adjectives have different meanings in the eyes of their beholders.
I think it was the Intel inside marketing campaign that really did the trick.
Nobody knows if Intel is better, but they don't want a computer that "lacks" Intel inside. They simply guess that if it's inside, it's better than not having it inside.
It is brilliant. It can't be copied or AMD looks like a "me too!" player. It can't be contested because it's just vauge enough to not claim that the machine is any better for having Intel inside, but implies that anything else is somehow inferior.
Especially if the buffer is their banking account.
Most debates about distributions don't amount to much anyway, so they are handled quite nicely. You're doing the right thing by trying out a few different ones, but you can save some time by avoiding any of the ones that sound too "exotic".
Using one distribution versus another won't have a day or night impact on your use of Linux until you get into the portions where the various flavors differ. On excellent example of this is in administration. The average user usually does very little administration, but it often becomes more important over time, and Linux is no exception. Learning one distrobution's administration often will leave you in the dark about another's. If you dig deep enough it often will become the same, but when you dig that deep, you're probably not using your distrobutions administration packages anymore anyway.
When in doubt, remember that the larger and more active distrobutions often have more people in your exact situation who may advertise thier soultion to a similiar problem on the internet.
Drat! Now I need two more generic variables!!!
Starcraft, Warcraft, etc. are in the same genre. If she dosen't like the genre she won't like any of them.
Pick something that she might like, and then stand back and let her enjoy it. Mine really cleans up when we play Scrabble, and she's a regular at the yahoo word related games, "Text Twist", etc.
Longevity is very important in video games considering most shooters leave me with a half-life of 2.5 minutes.
I agree wholeheartedly.
If you want prior art, look at the history of the male / female chess leagues. The creation of sparate leagues actually increased the sexisim debates. Soon the women's league was know for it's weaker players who were often derived the opportunity to play against their stronger male counterparts. It got so bad that (arguably) the best women players made it a point to play in the conventionally men's tournaments. Some were even as bold as to say it was impossible to improve unless they played against stronger opponents.
Video games, like chess, fail to use a sex's sexual characteristics to give one sex a distinct advantage over the other. Separate leagues aren't necessary, and if there's an all female team, that should be a choice of comaraderie and not adminstration.
Wow, how many web nanny programs will filter this post?
Mabye KDE will be the killer app, and I'd be glad to see it happen.
But sometimes I wonder if the killer app is still alive and well. Often the killer apps of the past were the programs that added functionality which was not present prior to their introduction or not popularized until one app broke critical mass.
I can't recall a killer app that provided the same (or even slightly better) functionality as a popular pre-existing one. Mabye it's because it's late and I'm tired, or mabye the answer is so oboviously painful I can't see it.
Feel free to point out the ones that shined who didn't create their niches.
One of the best and most unappreciated features of KDE is it's inherit troll value.
I'm sorry to post such a blatantly inflammatory gripe, and please don't reply to it in kind. Just be aware that the whole KDE vs. Gnome conversation is quickly degrading to the same sort of drivel that existed in the vi vs. emacs, gui vs. cli, X vs. Y debates.
Both KDE and Gnome are reasonably good programming environments (meaning I can program in both without requiring corrective surgery or extreme pain) and they both do a good job of managing, unifying, homogenizing, and (whatever) of the desktop.
If they come from two licensing lineages, so be it. I'm not worried about the environment / license you are going to choose, I'm going to choose the one I feel most comfortable with and has licensing (at cost or otherwise) that allows me to use it as I need. I'll assume you will do the same.
Less "better than Gnome!" or "worse than Gnome!" and more "it's really great that it has cleaned up feature X" please.
I apologize for such a rant, thank you for putting up with it.
Having a cousin that just came back from the Iraq conflict sans use of an arm, I'd say your statement is in poor taste.
It's easy to believe that nothing happens in these far off, remote conflicts, but in reality there are real people going over there doing things that likely could get them killed (even if the enemy is not present)
I can vouch that while over in the Desert Storm conflict, the news back home seemed really strange to me (standing in the arena). Truth is, it's mostly wrong, or exaggerated, or fabricated, or seen from a point of view that is more concerned with ratings than reality. Read the news from several different sources (as unrealted as possible) and you'll start to get an idea of what's happening.
Good luck, you'll need it.