Sorry, what?

This is greed, plain and simple. Companies that partner with issuing banks of prepaid cards (whether used as payroll, gifts/bonuses, payment cards for the underbanked paid for in cash, etc) get a cut of the fees paid by the cardholder and merchants where the cards are used (interchange).

I expect it also allows employers to more easily employ people who have a questionably legal worker status, as those workers are likely to accept the prepaid card since getting a proper bank account to cash paychecks may be difficult (I suspect that the Know Your Customer diligence required of the issuing banks of these cards is dubious; opening a proper bank account may screen illegals more effectively). It doesn't help that banking laws requiring performing KYC, but do not at all define what that minimally entails. Because there are no lines of credit being issued, the risk to the bank is effectively zero so long as they successfully screen out people on the terror watch lists.

Poor regulation of the payment card sector is what allows this to continue. Stuff like the Durbin Amendment helped slightly as it capped interchange on debit cards, but of course did nothing to address the "convenience" fees thrown in the mix. A lot of the costs of processing payment cards (i.e., as the merchant), when you dive in, are reasonably justified, but that's not a discussion I can have in a textarea field; however, charges such as cash withdrawal or balance inquiry fees are simply abusive and need to be legally addressed.

Source: I work in the payment card industry, and have in the past integrated with issuing banks to issue debit cards. Not for this sleazy payroll shit though.

Using a JOIN is not a sign of a badly broken application; on the contrary, it generally indicates you have well-normalized data. We've shied away from using them in the past because they're inherently reliant on data scattered across the disk, and until SSDs came around accessing the non-sequential data proved too expensive in many cases.

This exactly the kind of problem that you *should* throw hardware at, because this kind of hardware (storage with near-zero latency) is the right tool for the job. We've just historically performed a lot of software-based workarounds because we were forced to use the wrong tool (storage with relatively high latency; i.e. spinning platters), either because SSDs didn't exist or were prohibitively expensive.

I agree about the reliability concerns, but all forms of long-term storage we have will eventually fail. If you're doing something mission-critical without accounting for that... stop.

The timezone thing is a legitimate concern, but there's virtually no reason to not have ntpd running on your servers anyway. Depending on their level of server (non-)automation, it could conceivably take a non-trivial amount of time to set that up if it wasn't already, especially if there's software logic that doesn't like time running in reverse should it have to sync up in that direction.

Open-source doesn't magically decrease the severity or number of bugs, but it does allow more people to eventually discover them. There's an obvious trade-off here: non-malicious people can find and then report and/or fix the bugs, or malicious people can find and then exploit them. The hope is that there are more contributors than attackers finding bugs and that it ends up being a net positive for stability and security. Neither open nor closed source is the right model 100% of the time for 100% of projects.

There's no hypocrisy here - the source of the patches will be released and all future commits will be made public again. This was a short-term decision weighing practicality and security against the "religion" of OSS. It's the difference between responsible disclosure and letting the software maintainers find out about the same exploit because you blogged about it, so attackers find out at the same time. They could have one or two people developing the patch in a local branch and simply not push anything upstream until it's done and tested and have the same effect, this is just an easier approach.

People looking to exploit vulnerabilities on widely-installed software (databases, programming languages, frameworks, etc.) keep an eye on commit logs to do precisely this. Those patches and commits call attention to themselves; postgres is right to ensure that a patch is available at the same time it indicates the attack vector. In fact, they'd probably be wise to make sure major binary repos have a patched copy even before making the changed source available so that sysadmins have a week to do an update from yum/apt-get/$pkgmgr

The only difference between this and patch tuesday is that you know what goes into this fix after the fact. If you see 'critical security update' in your mailing lists, it becomes a race between you updating your system and attackers figuring out how to exploit the old version; them doing so is orders of magnitude more difficult if they don't actually know what's changed.

Is it the FOSS way? No. But I'd happily take a project going closed-source for two weeks if it means my database doesn't get hacked (but then again, I'm dealing with PCI-DSS Level 1 so I kinda have to). Now hopefully people have their databases completely inside the firewall as to minimize the attack vector - assuming it has something to do with an authentication flaw, at least (and not, say, remote code execution due to a bug in parameterized queries). See - I don't know what they're changing, so I don't even know where to start probing.

Yes, but hasn't yield increased significantly since the mid-40s? It looks like 2-3 orders of magnitude based on Wikipedia (https://en.wikipedia.org/wiki/Nuclear_weapon_yield) This may not be true for NK's weaponry, but let's say they succeed in bribing someone that has competent engineers to lend a hand.

Also, what of the radiation fallout?

Please re-read the summary. It says that having the scanner removes the need for enhanced pat-downs. i.e. if they take it away, it will increase the number of pat-downs required.

Which is based on OAuth and has precisely nothing whatsoever to do with third-party cookies.

It does cause problems for other completely legitimate use cases, but this is not one of them.

What? No. A large number of the high-profile celebrity twitter accounts are run by a social media manager, same as on facebook.

You're kidding, right?

People ought to know that the prefixed attributes are in beta and may change. If they ship that to production anyway, they had better be ready to change it if the standard is updated before the prefix is dropped.

Fortunately none of the vendor-specific extensions are anything but minor enhancements, so they can't do any serious damage. It's not like W3C is going to redefine a pixel here.

That was the argument in 2003 when we were first trying to get people to switch to Firefox. While I'm sure that's true in some places (China mostly, from what I last heard on the subject) the days of widespread SAAS are upon us and now even giant mega corps don't have a real problem upgrading.

Even if the updated web apps have ignored the last several years' best practice of feature detection instead of user-agent sniffing, they're unlikely to have serious problems with how close the modern rendering engines have become to each other.

Where the hell are you? My ping to Google is 15ms and I'm less than ten miles away from Mountain View.

I'll take the 0.01% when the alternative is certain death in a metallic fireball.

You were a part of a team with qualities that wasn't in line with FIRST, if that's an accurate description of your experience.

While it's definitely true that there are teams where the mentors do all of the hard work (I've met some, and they tend to be looked down upon by the rest of the community), most of the teams actually have mentors being mentors and let the students run the show. But it's important to have volunteers that will police each other about doing too much - having an actual teacher as a mentor helps immensely here. Out of the at least two hundred teams I've worked with in varying capacities, only two or three were mentor-dominated, and that includes those I met at the world championships.

When I was mentoring a team, we had to often remind each other to back off a bit because as an adult it's really easy to accidentally dominate the process - especially when it's a fun and rewarding one. It's pretty impressive what the students can create when the mentors keep their roles confined to safety police, knowledge-base, and the occasional reality check ("no, you can't add flamethrowers", "cool idea, but it violates the laws of physics", "I like where you're going with that, but we tried something similar five years ago and it ended up being a disaster... go ahead and prototype it but don't get too attached in case it doesn't work out").