chug

Health insurance companies do actually care, unfortunately. They're incentivized to embrace higher prices since they have to spend at least 80% of premiums on payouts. If you have a fixed margin, well, you have to increase premiums to increase profit, so higher prices means more profit.

That's a good point. I definitely have too much of a US-centric view on this as I'm not very familiar with the project and was assuming at least a few of the major people involved are living in the US or a country friendly enough with the US that the RIAA has major reach. Russia is a member of a few major international copyright agreements, but I have no idea how that will play out practically speaking. I'm not sure to what extent various member countries actually cooperate. Maybe the RIAA will just give up after they get GitHub and GitLab and any other major platforms with a US presence to stop hosting it if the main people are in a country that's enough of a speed bump for them.

My guess is that RIAA will pursue it until they either win legally or exhaust and frighten everyone away from it and it becomes a much less powerful tool. It's not like DMCA notices are their only option after all (and I'm not sure the DMCA notice sent to GitHub is really even a DMCA notice anyway). I would imagine they're either already in the process of or are ramping up to also go after the individuals involved as maintainers and (major) contributors. I think that could actually be a really interesting legal case to see if something like youtube-dl is found to be something more like a VCR or more like Napster, but I don't know if RIAA would ever take the chance of letting that happen on the chance that they lose. I think the more typical strategy for them would be to start sending everyone they can track down the real identity of scary letters and maybe drag a few into court and settle so the rest run away.

I personally wouldn't touch contributing to youtube-dl right now with a 10 foot pole, but I'm also a bit on the paranoid side :).

The problem with this is that DMCA isn't the only option the RIAA has by a long shot. The DMCA is a tool to get a platform to stop hosting content the rights holder believes is infringing. There's nothing stopping the RIAA from sending a DMCA notice and suing all the contributors. In other words, the project doesn't just need to be hosted in a country that is outside the reach of the US legal system, but the maintainers and contributors as individuals need to also be outside the reach of the US legal system. In fact, I'd be shocked if RIAA doesn't go after the maintainers and major contributors individually if they haven't already (I haven't been following this very closely).

Interestingly, the DMCA notice RIAA sent GitHub isn't a typical DMCA notice either. It seems to be more of a cease and desist along the lines of "we noticed this repo is a tool used to infringe on our rights -- sure would be a shame if you were to get caught up in the legal shitstorm that's about to happen, thanks!"

If it truly is a national security concern and not politics, this should be the obvious conclusion. How do we know some Facebook employee isn't siphoning data to the CCP right now? How do we know the US won't someday abuse the data Facebook/Google/whoever are collecting? The data is either weaponizable or it's not, and if it is weaponizable (and I believe it is), this needs to be a much larger discussion than TikTok and WeChat.

Looks interesting! You mentioned in the docs that it would be simpler once abstractions develop and that made me realize it's similar to facebook/dataloader, just used across requests instead of batching up all of the queries per request. It's also of course a generalized form of it that represents batching a parametrized method more so than just batching retrievals by some kind of unique key. It may be able to serve as something to lift API ideas from though. Like some kind of BatchedTask that has an execute() method that takes an array of args then batches those into an array of array of args for the underlying batched implementation.

https://github.com/facebook/dataloader/blob/master/README.md

I came across this last night (http://dtrace.org/blogs/bmc/2018/09/28/the-relative-performa...) and went down the rabbit hole of Rust and its BTreeSet (http://cglab.ca/~abeinges/blah/rust-btree-case/). They came to a very similar conclusion. It all makes me wonder if there's low hanging fruit in a lot of languages/libraries to simply swap out red black trees for B-trees (though I'm guessing the higher constant time cost of B-trees would make it necessary to swap between tree implementations for a truly general case).

This implies women aren't capable of earning success in any way other than trading sexual favors. Also, there's a huge difference in hookup culture and casual flings vs being in a predatory relationship with a huge power imbalance.

The "ghosting" and filming comments are very odd by the way. Do you mean women are always ghosted after sex? And that men are worried random Tinder hookups are going to record them? This whole thing reads like women are evil, scheming, worthless manipulators eager to use sex against men and that high powered man pressuring them into sex is somehow a favor since it gives them an opportunity to play out those schemes.

The title on this seems pretty misleading.

This is really a guide on how to use the escapeshellarg when you should use escapeshellcmd (or the opposite). Of course, the API of system() is pretty awful, so there is an issue here in the form of "wow, PHP makes this really easy to mess up," but there's no actual exploit in either function mentioned. Just exploits in code people write using them. I guess the LANG one is arguably an actual exploit though, though that gets into arguing semantics.

Edit: there's also an example that is missing quotes around an argument. Again, something very easy to mess up, but that's what you get when you have a function that is basically like typing a line into the shell.

It doesn't have built in support for it since it's just using dnsmasq under the hood, but you can install something like dnscrypt-proxy and then configure pi-hole (i.e. dnsmasq) to use it as its upstream DNS server.

I'm not quite sure you can just hand wave away the harmfulness. It's very possible that a lot of people would feel highly violated by it. It basically takes away your control over your modesty and to an extent even the autonomy of your body. Yes, the videos are fake, but that doesn't change that the entire premise is for people to imagine it's real.

I'm much less decided about the legality side of this, but I think the from the moral side, this is pretty hard to defend. Obviously this is taking things a bit to the extreme, but where exactly do you draw the line from a utilitarian perspective? Is a gang rape morally permissible if the perpetrators enjoy it enough to outweigh the victim's suffering? Why should people ever be (morally) allowed to derive their pleasure from another's suffering?

It's more like running valet parking and leaving other people's cars unlocked. Yeah, you should update your process so that your drivers lock the cars, but oh man, that's kind of hard. What if we just tell people their cars are locked up nice and safe and ignore anyone who says otherwise? That's much easier.

I think this response is pretty awful, but I do understand it. This website was probably either made by contractors who are long gone or an internal team who are too incompetent to fix it. Getting either of those parties to address the problem in a timely manner is a huge hassle (that could potentially cost lots of money). Ignoring the problem is easy and free. There's also likely the fear of "oh god, what have we done, and what kind of liability did this open us up to?" that is hard to stomach. It's incredibly stupid, but people usually are when they're both panicked and got caught doing something bad.

It's not officially part of the Pi Hole project, but I've been using https://hub.docker.com/r/diginc/pi-hole/ for about six months on a Raspberry Pi (though they support other platforms) and had no issues. They also​ keep up to date with new releases within a day or two usually.

The only company I've worked at with an ESPP required you to hold the stock for 1 year before selling--not in the sense of tax incentives unfortunately, but you literally cannot sell before 1 year. I didn't realize there were ESPPs where you sell immediately. In that case, woo free money!

It's important to remember that this is putting all of your eggs in one basket to a certain extent though.

Your income, your 401k match, and your ESPP are all tied to your employer, so as long as things are good, ESPPs can be a great way to make easy money, but if things take a stark downturn, you can find yourself with ESPP you lost money on, a slouching 401k, and no job. The chances of that happening are fairly low, but still something that makes me a little uncomfortable about ESPPs.

Obviously your advice to max our 401k/IRA contributions first should mitigate a lot of this, but I think it's important to mention the risk too since there's a certain temptation for younger engineers who think it sounds like easy money and don't realize the full implications of it.

I think at most it's an exaggerated premise, not false. There's tons of evidence that it does exist, though there is much debate over what exactly the percentage of the gap is. It's hard to find "the gap doesn't exist at all" evidence outside of certain think tanks or opinion pieces.

One aspect is that arbitration agreements almost always block class action lawsuits which can be hugely advantageous to a company. If a group of people have their rights or contacts violated, each must now pursue it individually, at potentially high personal expense in a system the company has more control over. Class action lawsuits are far from flawed, but they can be a terrifying prospect to companies. With arbitration, they now get to fight N people one on one instead of a talented team of big time lawyers indirectly representing all wronged parties (and keeping all the money usually, but it still punishes the company, and you can at least still bring your own suit).

Exactly! In fact, that's embarrassingly concise given my rambling. The only major thing missed is that the hash input has to contain something that the attack doesn't know in addition to the message. Or in other words, the private key is usually also involved in the hashing. If you ever want to get into details, the MAC [1] and HMAC [2] wiki pages go into depth.

[1] https://en.wikipedia.org/wiki/Message_authentication_code [2] https://en.wikipedia.org/wiki/Hash-based_message_authenticat...

Authentication in this context means baking in a way to verify that what you receive is something you encypted and has not been altered. Or, in other words, it lets you know that the data hasn't been tampered with.

As a practical example, imagine using encrypted cookies for a session store (like Rails can do), but imagine that they're not authenticated. It's possible that with clever manipulation of the encrypted cookie, I can alter the cookie such that it still decrypts into the structure ecorcyed, but with different data. For example, maybe I change the initialization vector a bit in a clever way and that makes the userId stored in the cookie change.

For a more detailed explanation and hypotherical, I thought [1] was a great article. It uses PHP for the examples, but it's mostly the theory that's of interest.

Of note, things are actually worse in Magento's case than this hypotherical since you can, as an attacker, get Magneto to use some pretty bad crypto when decrypting your message even if they used something decent when encrypting their payload (remember: since it's unauthenticated, what they give you and what you give back are not necessarily the same).

[1] https://paragonie.com/blog/2015/05/using-encryption-and-auth...

> Callbacks, promises, generators are all there to essentially make async code sync

I think they actually do quite the opposite: they keep async code async. JavaScript doesn't really have a (non-terrible) way to make async code sync.

Note that I'm assuming that by "being able to use return values of my methods without sweating," you mean "get the thing I want out of the return type somehow." Or, in other words, things like getting a value out of a Future. The problem with that approach is that it blocks the calling thread, so what happens if you have 50 connections? Or 200? Or 10,000?

The same reason I like that JavaScript and JavaScript libraries try very hard to keep things asynchronous is the same reason highly concurrent software tends to be event based rather than thread based: it's simply more efficient.

I think it can be a challenge to keep mental track of state in JavaScript due to the nature of async stuff, but it can also be liberating in a way once you figure out the right way to pack away your state for whatever problem your working on. It makes it easy to break things into small components and reason about pieces instead of the whole while maintaining decent efficiency compared to having tons of threads around.

There's also of course the incredible niceness of JavaScript being single threaded in that typical multithreading concerns are not a problem. If you want to update a variable in some callback, you just do it. You don't have to worry about locking or atomicity, etc. I can't tell you how many times I've ended up with a mess of Java code in which I'm not actually sure if it's correct or not. That's likely my fault, but still something I enjoy getting to not think about when doing JS.

In short, I suppose it just comes down to different preferences. I often find myself working on concurrency in Java and wishing that it were more like JavaScript :). Interesting, the JavaScript approach can be pretty easily recreated in Java (and sometimes a very useful tool), but the Java approach is much harder to do in JS, at least with Node.