I also don't like to see it doing poorly, for two reasons, one is that it is a fairly creative, different alternative, and the other is that I'm for more market variety rather than less. My opinion is that most people have entirely missed the reasons for its failure so far to capture much market share. It isn't because they are "too late to the party," that means nothing. Apple was too late to the party when the iPhone showed up. Google was too late to the party, Altavista, Yahoo, Lycos and others already had that market covered. Innovation can and regularly does disrupt markets, and I think the belief that one has to be first to market is mistaken. I think there are two primary reasons: 1) It is called "Windows Phone". That was a stupid decision. "Windows" doesn't have the same appeal as "Apple" as a brand. It says, "boring business product," or at best, "thing I use all the time but don't pay much attention to because it sits in the background." Why would you name a device after Microsoft Windows if you want it to have any appeal in the sort of market that the iPhone is in? Apple didn't call theirs the "OS X Phone", and the largest platform isn't called "Google Phone". They recognized the need for appealing branding that was independent to some degree from their main, existing products, even though their existing products have way more sex appeal, and way more likelihood to get press coverage depicting them attractively, than Microsoft Windows. 2) This one is more obvious, but for a reason that not everyone is aware of: lack of apps. I have a Windows phone, and I'm constantly unable to do things that I used to do all the time on my Android phone, or that my wife does on her iPhone. Everyone knows there is a certain hesitance on the part of developers to jump on board a platform when they don't know yet how many users will be there...and yet there is also a love among developers of being ahead of their competitors on the newest, latest, greatest platform, so there is a bit of counterbalance as well. What everyone doesn't realize is that Windows Phone 8 placed serious restrictions on what applications were even capable of doing, making WP versions of many Android / iOS apps completely impossible. For example, I used to use KeePassDroid constantly. There is no Windows Phone equivalent. By which, I mean, there is no app I can install to open my KeePass databases without having to grant that application permissions that a password manager shouldn't have. How can I trust one of my most secure task

I had these people in a quite extended conversation one time, out of curiosity following all their instructions ("10,000 items in the event viewer?! Oh no! Those are all viruses that have infected your system!") until they got to the point where I was to download an executable from their web site and run it, at which point I refused to go any further and then engaged the caller and two of his supervisors in an extended discussion about the ethics of what they were doing and offering the question whether they might personally prefer doing something better with their lives than preying on people who don't know anything about their computers. They were by that point denying that they had started the call by claiming to be Microsoft, and I was actually quite surprised at how long they were willing to talk with me once it became clear I actually knew what I was looking at and that I wasn't going to do whatever it was they wanted (which seemed to me most likely to be "purchase a useless 'security' product from them," although maybe it was something more malicious). I could only imagine that they were willing to talk so long because they wanted to avoid me reporting them to someone, but I'm not really sure, maybe the employees there are so clueless that they actually don't know they are being employed to scam people. Chrome didn't come up on that call, though. Maybe they've now moved beyond a simple exe file to a Chrome extension or something, since that might set off alarm bells for fewer people.

Passwords shouldn't be rememberable at all. The policies that are ridiculous are mainly the ones that set a maximum length. Go take a look at http://www.keepass.info/[^] and let your life become far easier. Easier than remembering, and also easier than a text file, thanks to search, auto-type, and the ability to sit in your system tray until called upon with a key combination. Just remember one password, then store, search, and auto-type the rest, along with notes, URL's, usernames, and other data in safe, encrypted form. Bonus tip: also a handy place to store other life data that you occasionally need to look up (vehicle VIN, tax ID, spouse social security number, insurance policy numbers, etc.). Bonus tip #2: use random gibberish as the answers to those web site "security questions", which are rarely very secure since they usually involve very easily obtained information about you, and store your gibberish answers in the password manager as well.

It was pointlessly pedantic, yes, but slightly less so than you're thinking. (And semantics is concerned with meaning, so arguing over semantics is not by any means automatically something to be dismissive of, given that the meaning is often the whole point.) Granted it is a somewhat silly objection, but why is it a little less silly than you're thinking? Because your original claim is kind of oddly put together. The original statement you made (loosely) takes the form of a logical argument that's actually based on interpreting "brain is a muscle" in a fairly literal fashion, and falls apart into meaninglessness if you do not. Here's what you said: "The brain is a muscle. And like any other muscle, it can be overworked and destroyed." So you are essentially making this logical argument: 1. The brain is a muscle. 2. Muscles can be overworked and destroyed. 3. Therefore, the brain, being a muscle, can be overworked and destroyed. In other words, whatever you meant to say, you didn't actually say "The brain is kind of like a muscle in that it can be overworked and destroyed." Instead you implied that the brain's capability for overwork and destruction actually comes from its being a muscle. This in turn implies either a mistaken understanding of the biology involved, or, if the original premise is meant to be symbolic, it is a case of the logical fallacy known as "argument from analogy" ("X is like Y in one respect, and therefore it is like Y in some other respect as well."). (Unless the only similarity referred to in the first claim is nothing more than its capacity for overwork and destruction, in which case you basically said "The brain can be overworked and destroyed. And like anything else that can be overworked and destroyed, it can be overworked and destroyed.") How's that for pedantic overanalysis? :)

Well that looks fun. A quick search shows people having this issue on Windows 7 as well, though, and it has something to do with file associations; restoring the defaults seems to fix it. (Now can one restore the defaults without wiping out any associations you've added while installing applications? Hope so.)

Ugh. I don't know what software this is, but as far as I can tell, the way they design hospital software is to take the biggest, worst, most horrifying Microsoft Access application you've ever encountered, the sort that happens when someone who wasn't a programmer discovered Access and built a giant, awful system on it and kept at it for a decade, and then model your new medical records application on that.

I looked for this for some time a while back and concluded: 1) There isn't a good solution for free; 2) There isn't really a great solution at all; and 3) The whole PST file concept (like every other mailbox format that uses a single, gargantuan file) is faulty. One file per email, a directory full of those files instead of a PST file, would solve the entire problem by allowing simple, generic file synchronization to work perfectly as email synchronization. Contacts, appointments, and tasks could be done the same way. Too bad no truly good email clients exist, either, leaving Outlook + Taglocity the most decent inadequate solution out there, so I'm still stuck with PST files for the time being.

You're actually disagreeing with the inverse of what I said. You're right, understanding a concept doesn't necessarily mean one knows the details as they work in practice, but not understanding a concept definitely means one doesn't know the details as they work in practice. If you can't even explain the idea of MVVM, there's no point in asking you to show it in practice. You also can get some feel for whether the person has truly applied these concepts by their answers. Do the answers sound like recited, memorized dictionary definitions? Do they sound like a vague conceptual awareness? Does the person seem to have familiarity with the messiness that one encounters when taking pure-sounding ideas and putting them into practice? But there's more to it than that. There are plenty of developers who can slap together things that work, more or less. There are a zillion programmers who have tons of technical knowledge at the detail level, without having any real conception of the higher, more abstract levels. I encounter their code all the time, and it has no forethought, no theory or philosophy, and no maintainability. Where they use patterns or concepts, they invoke them like magical incantations, rather than with understanding. An interview process should definitely look for this weakness. I'd rather have a person who thinks well and has never used the tool, language, or even specific programming patterns in question than one who cranks out cargo cult code based on a copy-and-paste-level understanding of MVVM or whatever. The best way to examine this involves a variety of things going on in the interview process, and I agree it involves talking through actual problems and exploring their thought processes, but that is a part of asking about theory, it isn't a replacement for it.

I'm not sure I agree with the wording of the objection. Theoretical questions are not only fine, they are a good idea. A candidate who has no concept of computer science theory or the abstract concepts involved in software development will produce code that has no governing or organizing principles behind it, and who will make decisions with no awareness of why one choice is better than another. I don't think it is "theoretical" that is objectionable. It is keyword and buzzword-based interviewing, and arbitrary arcane fact-based interviewing, that is the problem. A lot of technical interviews with non-technical or semi-technical people, or with technical people who haven't thought about what is an effective method of interviewing, go down a sheet asking things like "How many years experience do you have with REST?" "How many years experience do you have with ASP.NET custom controls?" "What is the third option on the file menu in Visual Studio?" This kind of interviewing makes me far less interested in the job, not only because it means the management may not be the greatest, but because everyone they've already hired went through the same, ineffective interview filter and therefore the team I'd be working with is unlikely to be inspiring. But I've had occasion to ask people about theory, say, to explain the basic ideas that make up object-oriented programming, and it can sometimes very quickly take someone who looks good on paper and discover the reality. You have to do that kind of thing in order to get a sense of whether the person understands what the acronyms he has pasted onto his resume actually mean...because there are as many candidates out there who are nothing more than a collection of buzzwords and keywords as there are hiring managers who are the same.

It is trivial for networks to not allow the phones onto the network, yes, but that's only part of the question. You mention deleting data, which is the rest of the issue. The existence of a mere network identifier doesn't make it possible to actually delete anything or prevent the phone from booting up, reading data, using WiFi, and so on, it only works to keep the phone from working as a phone.

Your thinking makes sense, but the basic problem here is that wires to your house and the right-of-way granted to lay those wires are severely limited resources, and of those two things the latter belongs to the government, not the companies. It is impossible to have true competition between Internet access providers for the same reason it is impossible to have true competition between telephone, electricity, water, or natural gas providers: such competition requires the absurd and impossible scenario where dozens or hundreds of different companies have, say, their own networks of pipes running natural gas through the city, each one with 100% coverage so that you as a homeowner have the option to turn on whichever one you want to buy from. Can't work. The channels are thereby limited to an extremely low number, making delivery of these things a natural monopoly. Economic and political theory in practice has for quite some time recognized not only a right, but a need to regulate naturally monopolistic markets and the companies in them, partly because otherwise the lack of a free market would put consumers at the mercy of the providers, and partly because in such cases the resources that are limited here are considered to belong to the people and their government anyway. The government was the one who granted (for instance) Comcast the right to put their wires on poles or underground across everybody's private and public property (including property of people who aren't even subscribers) in order to get their services to their customers. There's no reason to expect that a license to exclusively use a public right-of-way for profit ought to be free from interference or regulation. In other words, the wires may belong to the provider, but not the property they sit on, or the poles they are attached to, or the roads that get dug up when repairs are needed. Those things are being conditionally given to them, with the implicit recognition that this excludes other companies from using them for the same thing. There is no reasonable expectation that you can use up limited public resources without the public having any say in how you do so. The ideal solution to this would, in theory, be that the so-called "information superhighway" is maintained just like actual superhighways, that is, treated as public infrastructure, built and paid for by the public just like roads are. It's actually even occurred to me that this would, in the United States, be a potentially good fit for the future of the mission of the U.S. Postal

Really? Any serious dev is going to have massive numbers of applications installed, including tools you use a few times a year or less. Some of these tools are renamed occasionally when new versions are released. Example: I still go looking for "Ethereal" half the time I want Wireshark. Do you really want to pause and have to think what the actual name of some auxiliary app that came with your IDE or DBMS is called, or the diagnostics tool that you rarely need? Or, that thing you installed and meant to try out a while back but then got busy and therefore have never even used yet? I have hundreds of applications across several entire domains of computer use on my system, and while 95% of the time I just hit "start" and begin typing, the lack of being able to create a categorized, hierarchical menu system is a substantive loss for being able to find things in that other 5% of the time when navigating would be faster than pausing and extensively scanning one's own brain. What is the point in removing the ability to browse by task? In fact, where this is even more helpful is if the computer has more than one user. Does my wife know the names of all the things I have installed on one of our home computers? No, but she might be able to find something she needs if she can explore the menu. Scanning a flat screen of 200 tiles will just make her eyes glaze over. I actually like Windows 8 in most ways, and most everyone trembling in fear over upgrading from Windows 7 is over-anxious with little good reason. But this is nevertheless a legitimate gripe.

Flash and Silverlight? This goes much further back than that. Java applets were, I think, the first general-purpose solution to the problem that every round of people seems to think we don't need a solution for and then realizes we do, after all.

And what is the " = new List()" doing there, either? Assign it one value, then if it isn't null, which it can't be, immediately assign it another value and discard the first object? Goofy.

It's a pendulum. Client-side vs. server-side has been swinging back and forth for decades, since long before the web, for the same reasons. ("It makes no sense to waste all that ever-cheaper client-side processing power and overwhelm servers," vs. "It is a beast to keep client-side applications up-to-date.") Sometimes it goes both ways at once, like the last few years, where we've seen "everything moving to the web" except simultaneously "everything moving to mobile apps". I don't think we've seen the last of this back-and-forth trend, especially if any decent number of people takes up the reasonable concerns about the implications of mixing "everything I am and do taking place on someone else's servers" with "companies sell my data and governments read it all."

That this setting still exists at all, much less being set by default to on, is one of my big pet peeves about new Windows installations. I always turn it off everywhere I go when I set up Windows for other people. It is a disaster waiting to happen. Why? Well, people have already mentioned confusion occurring with "duplicate" files in the same directory, but there's something much, much worse: users can't tell the difference between CoolPictureIGotInAnEmailOrFromTheWeb.jpg and CoolPictureIGotInAnEmailOrFromTheWeb.exe and this makes for a nice big, fat security risk. We tell people "don't run programs that don't come from trusted places" and then we hide- by default- the easiest way of telling what files are programs. Foolish, and much more dangerous than someone doing a completely reversible MyWordDocument.docx to MyWordDocument.unrecognizableExtension rename.

Yes, TSVN does make things easier. Given that all the commands in the original scenario were issued from inside the right subdirectories (committing from the wrong level in the hierarchy also can have unexpected results if you want to be able to see history or merge things properly, which is probably why your workflow involving completely separate checkouts is to be preferred), my inclination is to agree with you and say the cause of this almost certainly has to do with the fact that the move happened before the file being moved was committed in the first place. A move is equivalent (according to the docs) to a copy and a delete, but if you're deleting something whose addition was never committed in the first place, maybe it somehow winds up skipping the delete, which results in two files being present once you do an update. I would personally tend to think this is actually incorrect behavior, but maybe whoever designed it has a good reason for that. It definitely is something that could very easily surprise users, even long-time users who failed to remember all the actions they took in a single batch prior to committing, so it is easier not to do things this way. As you say, when you do a copy directly from and to the repository, the commit happens implicitly as part of the execution of the command, and then you don't have to worry about it.

No, I think this is still a bit mistaken. When you use "svn cp" you are always creating a "link" in that it doesn't actually duplicate everything and considers the new copy's history to go back and include the original copy's history prior to where they branched apart. If you use the operating system to copy something in the working directory, absolutely, what you're discussing will be the case. You will have simply (as var as SVN knows) just done an "add" to what appears to be some new files. But using "svn cp" creates a copy/branch/tag. And the web page you reference doesn't actually ever back up your claim of their being any difference between pointing the "svn cp" at something local or directly at the repository. In fact, http://svnbook.red-bean.com/en/1.4/svn.branchmerge.using.html#svn.branchmerge.using.create[^] directly says otherwise: "From the repository's point of view, there's really no difference between these two methods." The whole SVN repository structure from root to tip is really just one giant directory tree. That may seem odd, but it is true. You can check out or commit at any level. There are good reasons in practice to check out at the level of a particular branch and also commit at that same level, but you could theoretically have a working copy of the entire repository and use that instead.

I'm not entirely sure what you mean here, but I don't think this works the way you're thinking. In SVN a branch is nothing more than a directory that happens to be a copy of another directory. A working directory is just a checkout of some subset of the entire SVN repository directory tree. You can do that at any level. I always do my checkouts at the individual branch level (or at the trunk level) but that is not because where checkouts are done matters, but rather because where commits are done from does matter, and I don't want to accidentally commit something from the wrong level and mess up my history.

Yes overall: Speed is better, a lot of decent, handy improvements. It is almost worth the cost of upgrading just because the wacko file explorer tree behavior introduced in Vista, whereby expanding a folder results in the folder whose contents you wanted to see jumping down to the bottom of the window (thus hiding exactly what you wanted to see by scrolling it off the screen), has finally been eliminated. Also, multi-monitor support is better (don't seem to need Ultramon anymore), bootup on my new laptop is almost indistinguishable in speed from waking up from sleep, and some other nice features. Task manager is better, some useful keyboard shortcuts for power users. Weaknesses: If you don't get about a half-dozen of those shortcut keys in your head, you'll spend way too much time wandering around because settings and actions are in some cases scattered weirdly. The Metro-style apps aren't all that useful unless you have a tablet, and often they have so few UI cues that you seriously have no idea how to navigate them, and they suffer from the disease introduced by Apple and Android of never wanting to quit, only switch away. You have to alt-F4 them all the time. (Well, if you use them anyway, which I don't all that much, since the whole paradigm is, when used on a normal computer screen, inferior to a windowed one.) The start screen itself is a red herring, everyone is afraid of "oh no, no start menu" but effectively the start screen is just a full-screen start menu, with the one main drawback being that it isn't hierarchical (well, except to a single level of grouping). The ISO mounting is handy but still needs a little tweaking- there's no way to control what drive letter is used. So if, say, you're installing something that comes on a whole set of discs, from ISO images, upon getting the "insert the next disc" prompt you'll unmount, then mount the next one, and only have about a 75% chance of getting the same drive letter and the installer being able to continue properly. Biggest engineering failure I've encountered yet on it: product keys are stored in the BIOS and then can't be seen or touched, which created one really stupid money waster for me. As I typically do, I bought my latest system intending to completely swap out the HD it came with and install Windows from scratch. To do this, I needed installation media, which practically nobody sells anymore with computers, so I separately ordered a Windows 8 Pro OEM disc. Having thus already paid for Windows 8 Pro once, I felt it was silly to pay extra t