And then, like maple syrup, Canada's evil would ooze all over the United States.
Which would then lead to our children pledging allegiance to the maple leaf, pouring mayonnaise over everything, winter 11 months of the year, and having Anne Murray on the radio all day, every day.
Yeah, I know that, but didn't think that what I was saying was coming off unclearly or wrong. If it did to you, then I apologize for the confusion. While I have studied physics throughout high school and college, I don't handle any of this professionally, but have had some exposure to them before, and have had to explain to others before how they even can work in the first place.
Regrettably, I got mod points shortly after I posted, or else I would have avoided commenting to be able to mod up your further clarification.
Perhaps the "pump" part of heat pump completely eluded you, since they do not defy the first law of thermodynamics as you seem to be implying.
Heat pumps work by having a sink source off of which they are pumping the heat from or away from. Most of the ones I know happen to be geothermal, which work because the sink which they are pumping from maintains a constant temperature year long underground. So, during the summer, the heat they can extract from that source would be cooler than the air above ground, but during the winter be hotter. They do this by extracting the heat from the source sink, rather than producing it themselves.
So in that respect, they work much like the fan does within your computer, since the air inside the case is much hotter when running than the air outside of the case. The fan can then displace that heat generated inside rather efficiently by just pushing the hotter air inside the case out, while bringing the cooler air from the room outside in without having to require an equal amount of energy to then power those fans as the equipment running inside of it, thus, like the grandparent, requiring less electric energy to power those fans than what the computer itself uses. If this were not so, then it'd make a lot more sense to completely seal computer cases, as the cooling benefit from the fans wouldn't make up for the amount of dust which they bring into the case during operation.
So the next time you're tempted to call bullshit on a well known physics principle, make sure you double check that you're not making some stupid mistake. Or else you'll end up looking rather foolish again when someone else points out how you don't know what you're talking about.
The same could have been said of Palm Pilots and Blackberries over ten years ago. And yet, here we are. PDAs are dead, and Blackberries are irrelevant. Not because they were terrible ideas, but because technology advanced enough that they became irrelevant, and they adapted to being a complementary device and not a device in which to replace the need for a desktop/laptop.
I also think that stating that the PC is dead is way too much of an overstatement, and see some reflection back to the past. Tablets and phones are good for one thing, and one thing only: consumption of content. Try to do anything outside of that sphere, and it just comes across as a rather clumsy device to use.
And I really have a hard time seeing it ever bridging that gap, since this is a problem inherent with the input system of choice. Much like speech recognition software hasn't replaced the keyboard, touch is not a replacement for the old mouse and keyboard. The problem lies in how by its very nature, touch is less precise of an input method.
That doesn't mean that I'm being a neophyte in regards to touch devices, since they do indeed have their place, but they just aren't the be all end all solution, since unless we're going to go to Minority Report like interfaces to make up for the loss in precision, which, BTW, would be completely impractical for long term use because of the ergonomics involved, then there will continue to be a need for the current input paradigms that we have now.
But that doesn't mean that the desktop won't change because of touch though. Gestures might very well become integrated with the desktop without too many problems, and which for that matter, Opera was a pioneer on this in some respects. However, it's not going to replace the need for finer grained controls. What such an input device would look like though, I dunno. It could be rather much like a trackpad on a laptop, could be integrated into the keyboard for a touch area, or even something else entirely. But whatever it ends up looking like, I'm just not seeing the killer advancement to enriching or supplementing the desktop... yet.
What I think the main problem here is that many who are involved in HCI prefer revolutions to incremental improvement, and then call anyone who doesn't want to jump on their latest bandwagon which doesn't want to go along with their revolution as being technophobic, when their new system that they propose either can't or won't replace all of the use cases that they think that it will.
I get it. Developing for older systems can be boring (although I'm a rather strange one and actually love to be on the incremental edge), and continually delving into unexplored areas is much more exciting. However, computing has never worked that way, with every advancement always being some incrementation and refinement of the older ideas which then builds on the work done by the previous generations of tech, instead of trying to replace it entirely.
So in that respect, I fully expect that touchscreen devices will likely end up being in the same position as your Palm Pilots and Blackberries in 10 years time. They will have failed to live up to the hype being given to them, and they will be relegated to being mostly entertainment devices overall, possibly replacing TVs, gaming devices, eReaders, and so on. Heck, we're actually starting to even see that now.
But they won't be replacing the need for an actual computer, much like Blackberries, iPods, and Palm Pilots didn't supplant them either. The input is just too clumsy to do that, and there's really nothing that technology or software can do to change that. But just because I say that doesn't mean that I then think that the desktop then needs to remain unaffected by it, and that it won't change as well because of it, but that such a change is going to end up being more incremental, rather than revolutionary.
Touch won't kill the need for a mouse, but something else which brings the best of both forms of input just might. And that replacement will then likely be just as inappropriate for use with a tablet as a tablet's interface would be for the desktop, even though it might take a lot of hints from the tablet paradigms.
> And in this day age, the fact that we're still typing to program computers just seems silly. There is no natural law that says computer code has be in the form of ASCII text at some point. Why not visual directly to machine code? I don't see any reason why it can't be done.
But seriously, there's really no technology out there that can really beat text input at the moment for general purpose programming. CLI interfaces, while rather demanding for upfront knowledge, are about as powerful as you can get. Everything else that tries to abstract away from that is going to be taking away some power from the programmer using it.
That doesn't mean that we haven't come a long way in visual editors, from VisualBasic to QT Designer or ALICE, but they're never going to be a replacement for all development. There will always be a need to continue to develop and tweak algorithms as we continue to develop and understand algorithms and their interactions better, and they will need a lower level of interaction in order to do them. The farther you abstract away from the core, the more important it becomes to have good performing code doing all of the intermediate steps, and the less flexibility you're given to tweak how it all works as well.
I know there are a lot of people out there who would like computers to instantly understand what it is that they want them to do, no matter how irrational it may be. However, we're never going to get away from good performing code needing someone behind it who can actually think rationally, logically, and procedurally. But that doesn't mean that we haven't already come a long way to where people can just throw some crap together in a few minutes to do a specific job at hand. Just don't expect that crap to be production quality or really, maintainable, for that matter. You'll still need someone who knows what they're doing for that.
UI is user interface. This can be a CLI (command line interface), GUI, touchscreen, or really whatever sort of way in which you can think to interact with a computer. As such, conflating it to a GUI, a graphical user interface, is narrowing things down too much, since it's much more general by definition. Each different input method is then going to have different things in which it's good for or not good for, and will need to be taken into consideration when designing.
For instance, a CLI is going to almost always be the most powerful input method, although it suffers from low discoverability, since you need to learn some basic commands to interact with it first before you can become too proficient at it. And the best CLIs are going to be ones in which you can infinitely chain commands together and even string them out in its own programming interface, so that you can then set up a batch of jobs together with a few clicks of the keyboard. Heck, I'd even classify voice command interfaces as CLIs as well, like Dragon NaturalSpeaking or even Siri, since while they don't involve keyboards, they have the same strengths and weaknesses as user interfaces (although the voice input could be seen as a fuzzier input method, much like how touchscreens are to GUIs, since you lose a bit of precision in the interaction, due to voice recognition software having to figure out what you intend to say).
While for UX, that stands for user experience, which is a completely different concept entirely. UI only designates how someone interacts with a computer, while UX is more so about whether that interface is optimal for the task at hand, or even whether there's consistency between the user interface interaction. So in essence, the UI designates the what, but the UX is how.
For instance, let's focus on using a touchscreen interface, which is one GUI implementation, and compare it to a mouse input. For starters, a touchscreen is never going to be a precision interaction method, because while you might be able to increase the screen size, you'll never match a mouse without lowering the DPI of the screen drastically, which then makes interaction a bit clumsier. Likewise, a mouse is going to be confined to a single input, while a touchscreen doesn't have to be, but can take in multiple inputs simultaneously, and as such, the mouse will never be able to quite match a touchscreen on this front. As such, while they both do represent graphical user interfaces, they do not share the same user experience, which is part of the reason why you hear complaints from people who don't like having to use one for a desktop, because forcing one UI for both then requires that in order to not completely suck on one input method, it needs to make compromises in the other.
Of course, there are some people who seem to believe that designing for the fuzzier interface while providing ways of doing tasks with single inputs will automatically make it optimal for both (I'm looking at you GNOME 3 and Windows 8), but this is sheer lunacy. Much like a CLI interface is not the most optimal for all cases (e.g. graphical manipulation), despite being the more powerful alternative, a touchscreen is not going to be a replacement for the old tried and true mouse and keyboard, which then allows for you to cram and browse through more information on one screen than a touch interface would, since a touch interface can't handle as much precision as the mouse can, and needs to be fuzzier by default in order to be useful.
So perhaps you might not care about all of this, since it does at least appear like you aren't within the industry since you dismissed all of this as being names for the same things, but at least you've had a brief 101 excerpt of HCI (human computer interaction), and can't claim ignorance to these terms as a defense any more. Because surely you likewise wouldn't say "CPU? GPU? RAM? Why do we need so many names for the same damn thing? It's not like we're using desktops anymore, so what difference does the C or G make."
For instance, I personally am allergic to ordinary boned fish, but don't have a problem with shelled fish. So if I order crab, it's important to me to know that it's actually crab, and not imitation crab, because one will make me sick, and the other won't.
I tend to like Department of Homeland Insecurity. Also sums it up rather well, and isn't a drastic change in its name. It's also a lot better descriptively than the current name.
The most optimal one for years has been the one that Bill Gates devised, which would result in 5/3 N number of flips, but now the best solution is only 1% more optimal than his solution.
And funnily, that's really the only known contribution that Bill Gates has done to the field of computer science, well, and a tad bit of programming in Windows 1.0 and the editions of DOS that came before that. After that, he didn't do anything anymore, or at least acknowledge that he did, since he became more occupied with managing Microsoft than coding.
You know what they say: If you're going to work, make it something which you enjoy. In this case, we have many agents investigating child pornography. Dunno what to think about that.;)
And neither of those facts matters to nonprogrammers. It's much akin to just saying "Oh well if you really care about that, there's some configuration file which you can mess around with where those keys are hidden (and you might just need to guess to find out what those keys happen to be)". If the user already has no clue as to how to program, or isn't able to invest a lot of time to learn an interface which might just be deprecated in a few releases due to a cascade of attention-deficit teenagers, who would much rather remove and replace something with their own new hotness rather than try to find out why something doesn't work, then you're screwed.
It'd be much better to try to both enable the user by providing good low and high level tools, instead of trying to constantly try to remove configuration from the low end tools because you don't like users doing anything more than what you think they should do. That's why I stopped using GNOME; because while I can program, I do get tired of the constant battle against what I like or need for my own workspace, especially since efforts like these decrease my own productivity, not increase them.
It's possible that she might be wanting to watch some seasons which haven't been released on DVD yet, and is basing that judgement on full retail price for previous seasons. Which still equates to a marketing failure.
You do realize that he might not be in the US, right? For instance, in Canada, what he said is applied to all media regardless (for example...). Just because the MPAA/RIAA haven't done something like this in the US doesn't mean that what the parent said doesn't apply elsewhere.
Easy. The key you're given is only valid for the country the plane is over, and you rotate keys on a regular basis without repeating (and get your key on entry to a particular country/block of countries like the EU). That way, only planes which have already been authorized to go over a particular country's airspace can get keys. The keys don't have to be in the public hands, and you could even have a few hour grace period for transitioning keys so that the planes that were still in the air when the key changed aren't immediately flagged as using an illegal encryption key.
To be honest, it's a surprise that they don't actually do something like this. You still would know that there's a plane there when it responds back, but at least you can't get anything from it without knowing the key being used at that particular time (and leaking keys would only be valid for a limited period of time, which would make it so that they could just change what key to use for a particular interval when they know in advance that their list has been compromised).
Uh... wrong. Even if you tab, it won't indent properly when displayed using other spacing patterns. For instance, if you are lining up some statements that run over the line to make the code easier to read (which is a perfectly acceptable style), then different tab indents could screw that up. Using tabbing to just mask for indenting with spaces isn't a real solution to code indenting because of this, since you're still relying on a set tab spacing anyways in order to make your code readable, even if you don't think you are.
Because of this, what you're saying doesn't make a lot of sense to begin with, and it doesn't pay to try to trivialize the whole spacing debate. In any case, indenting with spaces removes ambiguity in how your code should be indented that tabbing introduces. If you seriously don't think that this is an issue, then you should seriously take a closer look at some lines of code which run over a line. If you've never had this problem, then you've never really done any serious programming before, and shouldn't really be commenting on something which you aren't familiar with.
As a programmer, I could really care less how many spaces a tab represents, or if someone uses tabs vs. spaces, but I do want to see consistency in its use within the bundle of code that I have to work on or consult, since having to switch back and forth for code spacing is going to be a huge drain on readability. And, like I stated before, just telling people to use ambiguous tabs over spaces without a tab to space convention already specified within a style document for your project doesn't do much more than to make the person viewing the code guess how many spaces their tabs represent. It may not sound like a big deal to you, but it can be a big headache when you have to continually switch back and forth between different tab spacing defines because different people like you assumed that a tab will look the same for everyone no matter how many spaces are used. Because of this, I would much rather prefer to define how many spaces a tab should represent in the code style documents for languages which have tabs as part of their syntax (like Python), and unambiguous spaces for everything else, so that I don't have to either guess at what sort of spacing the person used, or to read more style documents than I have to (most are designed rather well so that you can infer the style from code you've already seen. I personally would much rather not have to consult a style document unless I reach a case that seems ambiguous to me. That way, I can focus more on coding what I need to, rather than just reading every piece of documentation that comes my way.)
Slashdot Mirror
Florida just wasn't ready for a "Destiny". They should have gone with a "Pam" or "Pamela" first.
And then, like maple syrup, Canada's evil would ooze all over the United States.
Which would then lead to our children pledging allegiance to the maple leaf, pouring mayonnaise over everything, winter 11 months of the year, and having Anne Murray on the radio all day, every day.
Won't somebody think of the children?
Yeah, I know that, but didn't think that what I was saying was coming off unclearly or wrong. If it did to you, then I apologize for the confusion. While I have studied physics throughout high school and college, I don't handle any of this professionally, but have had some exposure to them before, and have had to explain to others before how they even can work in the first place.
Regrettably, I got mod points shortly after I posted, or else I would have avoided commenting to be able to mod up your further clarification.
Perhaps the "pump" part of heat pump completely eluded you, since they do not defy the first law of thermodynamics as you seem to be implying.
Heat pumps work by having a sink source off of which they are pumping the heat from or away from. Most of the ones I know happen to be geothermal, which work because the sink which they are pumping from maintains a constant temperature year long underground. So, during the summer, the heat they can extract from that source would be cooler than the air above ground, but during the winter be hotter. They do this by extracting the heat from the source sink, rather than producing it themselves.
So in that respect, they work much like the fan does within your computer, since the air inside the case is much hotter when running than the air outside of the case. The fan can then displace that heat generated inside rather efficiently by just pushing the hotter air inside the case out, while bringing the cooler air from the room outside in without having to require an equal amount of energy to then power those fans as the equipment running inside of it, thus, like the grandparent, requiring less electric energy to power those fans than what the computer itself uses. If this were not so, then it'd make a lot more sense to completely seal computer cases, as the cooling benefit from the fans wouldn't make up for the amount of dust which they bring into the case during operation.
So the next time you're tempted to call bullshit on a well known physics principle, make sure you double check that you're not making some stupid mistake. Or else you'll end up looking rather foolish again when someone else points out how you don't know what you're talking about.
Mama mia!
Well, if it would have been that, they totally screwed up the release date.
Any true occult console would have set their release date one week earlier. ;)
Am I the only one who misread that as ouija consoles, and thought that the occult were finally getting involved in the video gaming industry directly?
Phishing sites should totally be pushing to get the .con domain. Completely appropriate and descriptive.
Heck, it's even a reasonable typo to make as well (at least on QWERTY).
The same could have been said of Palm Pilots and Blackberries over ten years ago. And yet, here we are. PDAs are dead, and Blackberries are irrelevant. Not because they were terrible ideas, but because technology advanced enough that they became irrelevant, and they adapted to being a complementary device and not a device in which to replace the need for a desktop/laptop.
I also think that stating that the PC is dead is way too much of an overstatement, and see some reflection back to the past. Tablets and phones are good for one thing, and one thing only: consumption of content. Try to do anything outside of that sphere, and it just comes across as a rather clumsy device to use.
And I really have a hard time seeing it ever bridging that gap, since this is a problem inherent with the input system of choice. Much like speech recognition software hasn't replaced the keyboard, touch is not a replacement for the old mouse and keyboard. The problem lies in how by its very nature, touch is less precise of an input method.
That doesn't mean that I'm being a neophyte in regards to touch devices, since they do indeed have their place, but they just aren't the be all end all solution, since unless we're going to go to Minority Report like interfaces to make up for the loss in precision, which, BTW, would be completely impractical for long term use because of the ergonomics involved, then there will continue to be a need for the current input paradigms that we have now.
But that doesn't mean that the desktop won't change because of touch though. Gestures might very well become integrated with the desktop without too many problems, and which for that matter, Opera was a pioneer on this in some respects. However, it's not going to replace the need for finer grained controls. What such an input device would look like though, I dunno. It could be rather much like a trackpad on a laptop, could be integrated into the keyboard for a touch area, or even something else entirely. But whatever it ends up looking like, I'm just not seeing the killer advancement to enriching or supplementing the desktop... yet.
What I think the main problem here is that many who are involved in HCI prefer revolutions to incremental improvement, and then call anyone who doesn't want to jump on their latest bandwagon which doesn't want to go along with their revolution as being technophobic, when their new system that they propose either can't or won't replace all of the use cases that they think that it will.
I get it. Developing for older systems can be boring (although I'm a rather strange one and actually love to be on the incremental edge), and continually delving into unexplored areas is much more exciting. However, computing has never worked that way, with every advancement always being some incrementation and refinement of the older ideas which then builds on the work done by the previous generations of tech, instead of trying to replace it entirely.
So in that respect, I fully expect that touchscreen devices will likely end up being in the same position as your Palm Pilots and Blackberries in 10 years time. They will have failed to live up to the hype being given to them, and they will be relegated to being mostly entertainment devices overall, possibly replacing TVs, gaming devices, eReaders, and so on. Heck, we're actually starting to even see that now.
But they won't be replacing the need for an actual computer, much like Blackberries, iPods, and Palm Pilots didn't supplant them either. The input is just too clumsy to do that, and there's really nothing that technology or software can do to change that. But just because I say that doesn't mean that I then think that the desktop then needs to remain unaffected by it, and that it won't change as well because of it, but that such a change is going to end up being more incremental, rather than revolutionary.
Touch won't kill the need for a mouse, but something else which brings the best of both forms of input just might. And that replacement will then likely be just as inappropriate for use with a tablet as a tablet's interface would be for the desktop, even though it might take a lot of hints from the tablet paradigms.
> And in this day age, the fact that we're still typing to program computers just seems silly. There is no natural law that says computer code has be in the form of ASCII text at some point. Why not visual directly to machine code? I don't see any reason why it can't be done.
You mean like Piet?
But seriously, there's really no technology out there that can really beat text input at the moment for general purpose programming. CLI interfaces, while rather demanding for upfront knowledge, are about as powerful as you can get. Everything else that tries to abstract away from that is going to be taking away some power from the programmer using it.
That doesn't mean that we haven't come a long way in visual editors, from VisualBasic to QT Designer or ALICE, but they're never going to be a replacement for all development. There will always be a need to continue to develop and tweak algorithms as we continue to develop and understand algorithms and their interactions better, and they will need a lower level of interaction in order to do them. The farther you abstract away from the core, the more important it becomes to have good performing code doing all of the intermediate steps, and the less flexibility you're given to tweak how it all works as well.
I know there are a lot of people out there who would like computers to instantly understand what it is that they want them to do, no matter how irrational it may be. However, we're never going to get away from good performing code needing someone behind it who can actually think rationally, logically, and procedurally. But that doesn't mean that we haven't already come a long way to where people can just throw some crap together in a few minutes to do a specific job at hand. Just don't expect that crap to be production quality or really, maintainable, for that matter. You'll still need someone who knows what they're doing for that.
They're not the same thing.
UI is user interface. This can be a CLI (command line interface), GUI, touchscreen, or really whatever sort of way in which you can think to interact with a computer. As such, conflating it to a GUI, a graphical user interface, is narrowing things down too much, since it's much more general by definition. Each different input method is then going to have different things in which it's good for or not good for, and will need to be taken into consideration when designing.
For instance, a CLI is going to almost always be the most powerful input method, although it suffers from low discoverability, since you need to learn some basic commands to interact with it first before you can become too proficient at it. And the best CLIs are going to be ones in which you can infinitely chain commands together and even string them out in its own programming interface, so that you can then set up a batch of jobs together with a few clicks of the keyboard. Heck, I'd even classify voice command interfaces as CLIs as well, like Dragon NaturalSpeaking or even Siri, since while they don't involve keyboards, they have the same strengths and weaknesses as user interfaces (although the voice input could be seen as a fuzzier input method, much like how touchscreens are to GUIs, since you lose a bit of precision in the interaction, due to voice recognition software having to figure out what you intend to say).
While for UX, that stands for user experience, which is a completely different concept entirely. UI only designates how someone interacts with a computer, while UX is more so about whether that interface is optimal for the task at hand, or even whether there's consistency between the user interface interaction. So in essence, the UI designates the what, but the UX is how.
For instance, let's focus on using a touchscreen interface, which is one GUI implementation, and compare it to a mouse input. For starters, a touchscreen is never going to be a precision interaction method, because while you might be able to increase the screen size, you'll never match a mouse without lowering the DPI of the screen drastically, which then makes interaction a bit clumsier. Likewise, a mouse is going to be confined to a single input, while a touchscreen doesn't have to be, but can take in multiple inputs simultaneously, and as such, the mouse will never be able to quite match a touchscreen on this front. As such, while they both do represent graphical user interfaces, they do not share the same user experience, which is part of the reason why you hear complaints from people who don't like having to use one for a desktop, because forcing one UI for both then requires that in order to not completely suck on one input method, it needs to make compromises in the other.
Of course, there are some people who seem to believe that designing for the fuzzier interface while providing ways of doing tasks with single inputs will automatically make it optimal for both (I'm looking at you GNOME 3 and Windows 8), but this is sheer lunacy. Much like a CLI interface is not the most optimal for all cases (e.g. graphical manipulation), despite being the more powerful alternative, a touchscreen is not going to be a replacement for the old tried and true mouse and keyboard, which then allows for you to cram and browse through more information on one screen than a touch interface would, since a touch interface can't handle as much precision as the mouse can, and needs to be fuzzier by default in order to be useful.
So perhaps you might not care about all of this, since it does at least appear like you aren't within the industry since you dismissed all of this as being names for the same things, but at least you've had a brief 101 excerpt of HCI (human computer interaction), and can't claim ignorance to these terms as a defense any more. Because surely you likewise wouldn't say "CPU? GPU? RAM? Why do we need so many names for the same damn thing? It's not like we're using desktops anymore, so what difference does the C or G make."
One word: allergies
For instance, I personally am allergic to ordinary boned fish, but don't have a problem with shelled fish. So if I order crab, it's important to me to know that it's actually crab, and not imitation crab, because one will make me sick, and the other won't.
I tend to like Department of Homeland Insecurity. Also sums it up rather well, and isn't a drastic change in its name. It's also a lot better descriptively than the current name.
The most optimal one for years has been the one that Bill Gates devised, which would result in 5/3 N number of flips, but now the best solution is only 1% more optimal than his solution.
And funnily, that's really the only known contribution that Bill Gates has done to the field of computer science, well, and a tad bit of programming in Windows 1.0 and the editions of DOS that came before that. After that, he didn't do anything anymore, or at least acknowledge that he did, since he became more occupied with managing Microsoft than coding.
It is the Wii 2, in any case.
And, if translated to Japanese, that makes it the Wii Ni. ;)
Compensation indeed.
Einhorn is Finkle, Finkle is Einhorn?
Er, sorry, I mean "Do what you love, and you'll never work a day in your life", which is even more applicable than what I said originally. :P
You know what they say: If you're going to work, make it something which you enjoy. In this case, we have many agents investigating child pornography. Dunno what to think about that. ;)
And neither of those facts matters to nonprogrammers. It's much akin to just saying "Oh well if you really care about that, there's some configuration file which you can mess around with where those keys are hidden (and you might just need to guess to find out what those keys happen to be)". If the user already has no clue as to how to program, or isn't able to invest a lot of time to learn an interface which might just be deprecated in a few releases due to a cascade of attention-deficit teenagers, who would much rather remove and replace something with their own new hotness rather than try to find out why something doesn't work, then you're screwed.
It'd be much better to try to both enable the user by providing good low and high level tools, instead of trying to constantly try to remove configuration from the low end tools because you don't like users doing anything more than what you think they should do. That's why I stopped using GNOME; because while I can program, I do get tired of the constant battle against what I like or need for my own workspace, especially since efforts like these decrease my own productivity, not increase them.
It's possible that she might be wanting to watch some seasons which haven't been released on DVD yet, and is basing that judgement on full retail price for previous seasons. Which still equates to a marketing failure.
Dunno, seems like a tough call. Hello Kitty was able to do quite a bit to Cthulu.
You do realize that he might not be in the US, right? For instance, in Canada, what he said is applied to all media regardless (for example...). Just because the MPAA/RIAA haven't done something like this in the US doesn't mean that what the parent said doesn't apply elsewhere.
Easy. The key you're given is only valid for the country the plane is over, and you rotate keys on a regular basis without repeating (and get your key on entry to a particular country/block of countries like the EU). That way, only planes which have already been authorized to go over a particular country's airspace can get keys. The keys don't have to be in the public hands, and you could even have a few hour grace period for transitioning keys so that the planes that were still in the air when the key changed aren't immediately flagged as using an illegal encryption key.
To be honest, it's a surprise that they don't actually do something like this. You still would know that there's a plane there when it responds back, but at least you can't get anything from it without knowing the key being used at that particular time (and leaking keys would only be valid for a limited period of time, which would make it so that they could just change what key to use for a particular interval when they know in advance that their list has been compromised).
Uh... wrong. Even if you tab, it won't indent properly when displayed using other spacing patterns. For instance, if you are lining up some statements that run over the line to make the code easier to read (which is a perfectly acceptable style), then different tab indents could screw that up. Using tabbing to just mask for indenting with spaces isn't a real solution to code indenting because of this, since you're still relying on a set tab spacing anyways in order to make your code readable, even if you don't think you are.
Because of this, what you're saying doesn't make a lot of sense to begin with, and it doesn't pay to try to trivialize the whole spacing debate. In any case, indenting with spaces removes ambiguity in how your code should be indented that tabbing introduces. If you seriously don't think that this is an issue, then you should seriously take a closer look at some lines of code which run over a line. If you've never had this problem, then you've never really done any serious programming before, and shouldn't really be commenting on something which you aren't familiar with.
As a programmer, I could really care less how many spaces a tab represents, or if someone uses tabs vs. spaces, but I do want to see consistency in its use within the bundle of code that I have to work on or consult, since having to switch back and forth for code spacing is going to be a huge drain on readability. And, like I stated before, just telling people to use ambiguous tabs over spaces without a tab to space convention already specified within a style document for your project doesn't do much more than to make the person viewing the code guess how many spaces their tabs represent. It may not sound like a big deal to you, but it can be a big headache when you have to continually switch back and forth between different tab spacing defines because different people like you assumed that a tab will look the same for everyone no matter how many spaces are used. Because of this, I would much rather prefer to define how many spaces a tab should represent in the code style documents for languages which have tabs as part of their syntax (like Python), and unambiguous spaces for everything else, so that I don't have to either guess at what sort of spacing the person used, or to read more style documents than I have to (most are designed rather well so that you can infer the style from code you've already seen. I personally would much rather not have to consult a style document unless I reach a case that seems ambiguous to me. That way, I can focus more on coding what I need to, rather than just reading every piece of documentation that comes my way.)
So, did Project Natal just become a part of KDE? This is a totally unexpected move from Microsoft. ;)