> we did that because we knew we could not ask the maintainers of Linux for permission, or they would be on the lookout for the hypocrite patches.
This bit just reads like "sorry you're upset".
I would have expected something along the lines of "sorry, we should have asked the maintainers and we understand why it was wrong not to", instead of "sorry, we didn't ask the maintainers, but this is why we didn't".
Yup. It's arguable whether TOTP secrets stored in Google Authenticator are a true "something you have" factor, but this came at a tradeoff because not everybody wants to pay for a RSA token generator and carry that around. Assuming the Android system is secure (big assumption, bear with me here), this is closer to a "something you have" factor because its difficult, if not impossible for users to retrieve the secrets from the GA app.
I would caution against this approach. This fundamentally changes the 2FA from a "something you have" to "something you know", which is the type of factor your password is. If you do want 2FA functionality on the command line, look into Yubikeys with their ykman CLI tool. (https://support.yubico.com/support/solutions/articles/150000...) You're able to store a TOTP secret on the Yubikey itself (maintaining it as a "something you have" factor), as well as optionally requiring the yubikey be touched before the TOTP is emitted.
This sounds a lot like Throttle (https://throttlehq.com/). How are they getting around the deliverability issues? If they forward mail along, don't large ISPs like Gmail ultimately attribute any spam that comes along to their outbound IPs?
I moved away from Throttle for this very reason, because getting mail deliverability right is incredibly finnicky. Ended up moving to Fastmail and using their catchall. Fastmail solved the deliverability problem for me (since they host the catchall domain), as well as permitting me to send out from any of my wildcard aliases (thus allowing me to reply in situations where I still want to keep my real address hidden).
That's actually not true. I believe with the latest generation of Nvidia cards (10 series) they made rendering multiple similar viewpoints dirt cheap by tweaking the hardware and the rendering pipeline.
From the arstechnica review on the 1060: "GPU Boost 3.0, Fast Sync, HDR, VR Works Audio, Ansel, and preemption make a return too , as well as the ability to render multiple viewpoints in a single render-pass."
From my limited understanding, VR is difficult because of the tolerances required. For regular gaming, slight frame drops were annoying, but didn't break the experience. Thus, it was reasonable to ship a game that was able to hit 60fps 99% of the time, and just write off the remaining 1% of the time. For VR, not only do we need to hit at least 75fps, the tolerance for frame drops is much much lower (a stutter while you're watching a monitor is annoying, the same stutter in VR could make you lose your balance). To aim to hit 75fps and guarantee that you'll hit that 99.9%, 99.99%, or 99.999% of the time is where the difficulty lies. I'm sure most of the HN audience has experience with just how difficult it is to tack on an additional 9.
I disagree. I had tried out Atom for a little bit (after the v1 general release) and more than once I lost my entire workspace. Either through a computer crash, Atom crash, or something else. Maybe I didn't configure something right, maybe I didn't. Quite frankly I don't care, I think that always properly persisting all unsaved work should be a default. Sublime always persisted all of my workspaces and open tabs perfectly. Everytime where I would lose unsaved data, Sublime would prompt me. After losing my stuff like twice in Atom, I switched back. The new features and everything are great, but I prefer not losing my random unsaved code snippets.
I've had an experience where they claimed a cable modem I had purchased from Amazon was their own (from the MAC address on the label). I had to call in several times because I had loaned the modem out to a friend and they refused to activate it because it was an "unreturned rental modem". They're not even able to keep track of their own inventory, I would hardly count on them keeping track of MACs of all modems for the purposes of data caps.
I believe these are requirements, that each of the separate teams working on these projects have to use wholly different suppliers to also minimize the chance that the same external factors negatively influence the system.
An interesting thing I realized on Android while doing some development was that if you install a custom root cert, Android actually persists a notification that says something along the lines of "other people may be able to intercept your communication".
Noticed this while I was installing the MITM cert for CharlesProxy.
I used to be of the mind that the service provider should let me choose whatever password since it was after all, my password and my account.
The place I'm working for right now used to have no password policy for the end users. We also had a feature that allowed them to link their Twitter accounts so that they could automatically share content out to their networks.
Eventually what had happened was that people blamed us for their Twitter accounts getting "hacked". What actually happened was that they set a dumb password (like "password") on their account with our service, authorized us to post to Twitter on their behalf, and now when someone hacked their account with us they could now post to the victim's Twitter account.
We started taking plenty of heat for this, so eventually we decided to impose a password policy (a sane one, at that) and this problem eventually went away. The users of our service aren't particularly tech savvy, so blaming them for their shoddy practices wouldn't have done us any good. It might have made sense to try to fight this if we were a company like Okta, that sells security as a service, but we don't so we had to make the decision to enforce password requirements to just stop the all the bad reviews in the app store and social media hate we were getting.
Disappointed that they did nothing to probe the onboard MCUs to see if they could get it to leak anything, and just dismissed that with "we expect it to get high marks there." This seems an awfully low quality report from an infosec company. I was hoping to see an audit of the controllers onboard to see if (and if so, how much effort) they can extract onboard secrets, because after all that's the whole purpose of this device, to act as a secrets repository.
I'm actually surprised that there's no policy on conflict of interest for these universities. It's one thing to be charging through the nose tuition, that's just further exacerbated by these professors that wring students for personal gain.
Writing your own book is fine, but manipulating these books EA style (where you buy a game that comes with a one time use multiplayer key, neutering your ability to sell it afterwards) on the thinly veiled "improvements" is just downright shady. I commented about this on the other math book to pdf submission, but I had a professor did just this. He basically shuffled chapters around and renumbered problems, making the previous year's book worthless because the problems he assigned are numbered out of the new book, and he refused to provide any mapping of new problem sets to old problem sets. I had mentioned this to the department heads and none of them really cared at all about this practice.
I had encountered this in the lower div general education courses at my university. The most egregious one was the professor who required us to get the current edition of the textbook (since he would be assigning problems out of the new book, which was just a shuffled version of the previous version) that he wrote himself. Fitting that it was an economics course.
Once I got into the CS courses, most if not all of my professors just provided PDFs of either their own material or some open source textbook they were contributing to.
This is important. With unlimited PTO, you no longer accrue PTO hours per pay period. Those unused PTO hours are legally required to be paid out at your usual rate when you leave, regardless of reason. I'm actually surprised that this isn't mentioned in the article at all.
Uber wasn't explicitly mentioned, but it just sounds like the TLC is overly trigger happy in seizing cars, presumably because of the uptake in services like Lyft and Uber who in the TLC's eyes are skirting around the law.
Personally its not the slowness that I mind so much. I spent a week in Japan and was never bothered by their train system times and whatnot.
The thing that really grinds my gears about BART is that every freaking time in their time table is +/- 5 minutes. I can't plan any sort of schedule around it to save my life, and thus I personally feel that I waste a ton of time waiting around for the next train. I never felt that in Japan. Every transfer and connection was exactly on time and there were plenty of trains where I was never sitting around waiting 20 minutes because I just missed the BART.
The cheapest rate is 38c/kWh, the most expensive is 62c/kWh..