hartez
You've misunderstood his sentence. He's not saying that we should prefer fixing things locally to fixing things globally. He's asking why we should believe that the tech elite can improve life on a global scale when they can't even improve it on a local scale.
And Windows allows side-by-side installs of 64- and 32-bit versions of the same software; so installers should be aware of 'C:\Program Files (x86)' and 'C:\Program Files'; the first is for 32-bit programs on 64-bit machines.
FWIW, we have a friend who sells mw equipment, and he refuses to go through them for safety reasons. So even if I weren't opting out for moral reasons, I wouldn't go through them.
* I'm sure glad no terrorists are smart enough to do this.
Does anyone know why Apple doesn't offer this? Are they just worried it will somehow cause customer confusion?
I'm not saying that obfuscating the first 12 digits on a receipt solves the problem; just that it's a very minor adjustment that makes things more difficult for the attacker. But some organizations are still failing at even these most rudimentary steps.
Just a few years ago I looked at my receipt from a local Dairy Queen and it had all but the last four digits printed on it. I complained to the guy behind the counter, who didn't see the problem.
I assume most new POS systems nowadays don't even have the option to print anything but the last four, but there are still some out there in the wild which do. Which is why I still shred all my receipts.
It's not that bad. Adding a new AD user is a built-in command. From the docs:
New-ADUser GlenJohn -OtherAttributes @{title="director";mail="[email protected]"}
I'm not a UNIX admin; maybe the adduser command is easier. But managing AD stuff in PS is pretty easy (especially if you have to do it in bulk).
You know who goes to the doctor a lot? Centegenarians.
The Windows SDK no longer ships with a complete command-line build environment. The Windows SDK now requires a compiler and build environment to be installed separately.
Below that they also list a dozen tools and a bunch of documentation and samples that they also no longer include in the SDK. My guess is that they're just trimming down their SDK downloads. Their SDK has been getting more and more bloated over the years with utilities and samples and stuff that most devs don't need.Completely dropping their command line tools doesn't make sense for anyone who runs build servers; it doesn't make sense for their Powershell tools; and it really doesn't make sense when you consider their recent moves in Open Source. My guess is that the command line tools will be separate downloads from the basic SDK and you'll still be able to write C# code in Notepad++ if you like. The basic SDK will be targeting people writing Metro apps (which they want to encourage by default), but they aren't going to just drop everything else. This is a company that lives and breathes backward compatibility, after all.
It's just a case of poor messaging by Microsoft. Remember last year when everyone thought that all Windows 8 apps were going to be Javascript/HTML 5?
Which is generally what you want to have happen. Failing fast is a good thing. If your code does anything other than "stop executing" after encountering an exceptional situation, it should be very something carefully considered and well-thought-out. With checked exceptions, the "I'm in a hurry to get this working" version of the code often ends up looking a lot like:
try {...}
catch(ExceptionType ex){ //TODO figure out what to do here }
... keep going ...
The danger is what happens in that "... keep going ..." section - the code is working under faulty assumptions and that can lead to a lot of non-obvious but horrific bugs. In the unchecked "I'm in a hurry" version, the program simply crashes at that point.So I think the C# design choice leads to the least pain under bad conditions. I'd rather have a fragile application than one just robust enough to write bad data to my database.
That said, it's not perfect. Any sufficiently lazy/stupid programmer can write the equivalent of "On Error Resume Next" in any language.
I think that to myself about at least one HN article/comment every day :)
That might be the crux of your problem (and the problems a lot of other companies are having with hiring). This is just my totally biased outside perspective, but it's easy to get remote work right now. Why in the world would I ever want to move to California?
I'm seeing this become an issue a lot with companies that need good development talent but just don't understand that it might not be something they can find locally. Good developers can (at least right now) live wherever they want in the country and make plenty of money. Apologies to anyone living in, say, Wichita, but why would I move there* if I didn't have to? By forcing your development teams to be local, you're limiting your talent pool or you're picking up C-grade developers from other places who are desperate for a job.
* The barbecue -is- pretty darn good
http://mobile.businessweek.com/news/2012-02-24/nextgen-faa-c...
or
http://www.usatoday.com/tech/products/services/2010-10-21-fb...
"The IRS could trivially set up a website" - no, you or I could trivially set up a website. The IRS can't trivially do anything.
Just don't break the build at 4:59. That's all I ask.
This problem has, generally speaking, been addressed. You're just not using tools that address it. Which is not to say that there isn't room for improvement, or gaps in this toolchain (e.g., I can't think of a tool for bills/invoices off the top of my head, though I bet one exists). And addressing it by creating a solution for your specific combination of problems is certainly admirable.
But it's not email that's broken; if anything is broken, it's the endpoints (both the source and the destination). Saying email is broken is like saying the | operator in Unix is broken.
div#repo_details { opacity:0.3 !important; } ul.with-details-box { opacity:0.3 !important;}
to make those fade a bit and draw you eye toward the menu bars below them. You could event apply it your specific repo urls, so you could customize it depending on what you're working on.
Again, only a temporary hack, but better than nothing until a better universal design can be agreed upon and implemented.
Stylish: https://addons.mozilla.org/en-US/firefox/addon/stylish/
For getting simple data up on a web page it was fantastic. But for more complex stuff it got wickedly complicated to maintain at an exponential rate. XSLT just didn't scale (and/or we just weren't good enough at it to make it scale).
I've worked in places where it was an issue. And it's a very difficult one to address. "Please be quieter" is much more socially acceptable than "Please use deodorant".