Link to Original Source
Link to Original Source
make sure you include a neutral to all of your wall switch boxes
This is actually required by electrical code now (NEC 2011, 404.2(C)), specifically because of these smarter switches, and even many of the non-communicating switches/dimmers/timers on the market that have LED indicators and such.
That would beat how long it took them to discontinue selling SageTV by "a few years".
Bruce Schneier had a good write-up on this in 2007:
Problems with Dual_EC_DRBG were first described in early 2006. The math is complicated, but the general point is that the random numbers it produces have a small bias.
This is how it works: There are a bunch of constants -- fixed numbers -- in the standard used to define the algorithm's elliptic curve. These constants are listed in Appendix A of the NIST publication, but nowhere is it explained where they came from.
What Shumow and Ferguson showed is that these numbers have a relationship with a second, secret set of numbers that can act as a kind of skeleton key. If you know the secret numbers, you can predict the output of the random-number generator after collecting just 32 bytes of its output. To put that in real terms, you only need to monitor one TLS internet encryption connection in order to crack the security of that protocol. If you know the secret numbers, you can completely break any instantiation of Dual_EC_DRBG.
The researchers don't know what the secret numbers are. But because of the way the algorithm works, the person who produced the constants might know; he had the mathematical opportunity to produce the constants and the secret numbers in tandem.
Of course, we have no way of knowing whether the NSA knows the secret numbers that break Dual_EC-DRBG. We have no way of knowing whether an NSA employee working on his own came up with the constants -- and has the secret numbers. We don't know if someone from NIST, or someone in the ANSI working group, has them. Maybe nobody does.
We don't know where the constants came from in the first place. We only know that whoever came up with them could have the key to this backdoor. And we know there's no way for NIST -- or anyone else -- to prove otherwise.
This is scary stuff indeed.
Why do you have *restrictions* on using IE9? If your sites/app are built correctly (using standards), then your users should be able to freely upgrade and even use other browsers. If the people that build your sites/apps are not supporting the current versions of browsers, or are doing things that are against standards and only work in IE9, then they're idiots. Or the person preventing testing of anything other than IE9 is an idiot.
It's fine for you you have a requirement of IE9+ support, but ignoring current versions is dumb. You're just recreating the mess of IE6-only apps that the world-at-large is only just getting over. Did you not learn the lesson?
It's slightly more expensive to support more versions today, but it's anywhere from much more expensive to complete-rewrite expensive when you have no choice a few years from now.
It definitely doesn't help that the JRE installer tries to also install the Ask toolbar. Seriously? Even Microsoft doesn't try to install Bing with the
How am I supposed to take a platform seriously if the fundamental piece that has to be installed by all developers AND users to use it is doing the same sneaky things that half the crappy freeware on the internet is doing?
Just how much revenue does Oracle make from Ask anyway?
On this note.. I'd like to thank the administrators from from I was in high school for going through this. Their (ultimately unsuccessful) attempts at blocking everything gave me one heck of an awesome crash course in TCP/IP, DNS, firewalls, VPNs, and reverse proxies, etc
I think the author's tirade against wikis is that many people use a wiki as a magical tool that allows them to forego writing documentation in the hopes it will suddenly appear, written by users that want to write documentation. This obviously isn't what typically happens.
However, I think wikis can be (and often are) a great format for documentation. The author(s) of the software should still be the primary and/or only contributors, but even so good wiki software serves to lower the barrier to writing documentation: creating/editing as simple as clicking edit, and you instantly see the results. You can link between pages, reducing duplication. Some software forces a hierarchy of pages, leading you to create things in a logical, structured way (of course, you can lead a horse to water...).
The key to this of course is that the person/people writing the software must write the bulk of the documentation (eg, like you would without the wiki as well). Don't allow random edits, or at least subject edits to a review process.If your project is big and successful, just as it lowers the barrier for you to write docs it may encourage others to contribute -- but don't rely on this.
Think of the wiki more like a publishing platform or format; not like a way to absolve yourself of the responsibility to write documentation.
From the code:
// Also, generate a random number, which we append to the URL, to make it appear as if a complex
Coder: "Here's the census web application."
PHB: "Great. But wait..I can just type in these other names and download them really easily! People will hack us and we'll be out possibly a COUPLE THOUSAND DOLLARS! "
Coder: "It is Creative Commons data, so of course we added no protection. Changing that now will be a massive rewrite and take months."
PHB: "So let's add some random numbers to the end so it looks really complex and people can't guess how to get in."
Coder: "But they still will eventually see the links because they do actually have to download it, so this is not really doing anything."
PHB: "Psh, no one is smart enough to figure that out. I read about this GUID things and they're really hard to guess. It will work. This is your job today."
Coder "..Ok, fine. I'll do it exactly the way you asked."
Many, many years ago when I got my first domain, I set up *@domain.com to forward to me. And about 5 minutes and several spams/garbage from the owner of the domain before me later, I turned it off.
However, I did end up making a subdomain and forwarding everything (*@sub.mydomain.com), and I've been using it exclusively for signing up to sites ever since (I've probably been using it for ~13 years). I can think of about two occasions where I have actually got spam to any of the addresses I used, both were from shady companies that turned on a 'share my address' setting without prompting (or it was so buried that I missed it, I usually spot those). I've never gotten any dictionary-style spam attacks to the subdomain or mail to an address I didn't explicitly use.
You've obviously never been involved in hiring developers.
There are a *lot* of bad developers out there. So many it's sickening. Bad developers that have resumes that look like they can do stuff. They may even call themselves senior. They've worked on a team that has successfully produced a product (or at least at a company that has).
One of the memorable interviews I did with was via a referral, and it worked out that I went straight to an in-person interview (skipping my usual weeding-out process). This person had a decent CV. They worked on a project designing a military helicopter training simulator, which basically involved wiring a game (written by another team) up to a 4-person helicopter mock-up that included pieces of real equipment (radios, navigation, etc) so the actual equipment displayed and could interact with the game. I've always had a personal fascination with interfacing real-world hardware with software (and have done lots of industrial control integration), so I had a ton of questions.
Well, despite trying for ~15 minutes, I could not figure out what this person actually had specifically accomplished. The team had successfully built this thing from what I could tell, but this person could not explain to me what *they* actually did. I asked in many different ways, including very bluntly like "What was some piece of functionality/code you wrote yourself?" and the person "could not remember" (they worked there for over a year, and had left less than a year prior). The most technical thing they could say about the integration was that it "involved UDP".. Seriously.
I've been using Chrome for well over a year, and have had this discussion many times. Yes, Chrome uses more ram. But I can close a bunch of tabs, and it frees it up. Firefox, every time I try it and despite that it's memory management is "getting better", still eventually uses several GB of ram and requires that I completely exit and restart before it's freed.
My browser is one of the first things I start up when I turn on my PC, and generally stays open until my PC has to reboot for some reason (which may be anywhere from a week to a month). This is really only possible now because I use Chrome.
If your pushing code the production once a day, you have no QA cycle whatsoever.
That's not necessarily true. You can push code up once a day, where QA takes it a day (or whatever) later, and then it goes to staging and then goes to production. The code being pushed out today may have been in QA for the past two days, and actually written 3 days ago.
At the place I work at now, we're doing two week cycles like this. Once development is done, the code is pushed to QA, who then spends up to a couple weeks on it. If it passes, it can go out, but in the meantime, dev is working on new stuff. This works for any cycle duration, and even a per-issue basis, which is how >= daily updates (should) work.
Of course, there are places where there is no QA, and developers are pushing stuff to production immediately after writing it, and then spending the next couple days rushing fixes for all the bugs they just introduced into production. And then fixes for the bugs in those fixes... And the cycle ends when someone either wises up and realizes it's not sustainable, or all your developers burn out and leave and/or all your customers get sick of constant breaking and leave.
I'm offended by your suggestion that I or someone I know might ever say something mean in public and should be arrested. I demand you be arrested!