Since Netflix neither allows anonymous users to fully download Frozen without DRM, nor allows authorized users to upload derivative works that are then redistributed to the public, I think there may be some relevant differences here.
10,248 karma · joined July 16, 2012
If anything I've written on this site seems interesting, or confusing, or you think I'd be interested in something you've written/read, please let me know: hn@justinblank.com.
Nonetheless, given that GitHub exists to facilitate both anonymously pulling the entire history of the repository, and given that any forks would contain the full contents of that repository, it is very natural that GitHub would take the "once public always public" line.
> and I mean commits made to private repositories being public is always a security vulnerability no matter how much github claims it's intended
I specifically said the third use case was different, because it is the one that doesn't involve you explicitly choosing to publish the commits that contain your private information. I did not and would not defend GitHub on that point.
I can sympathize with someone who gets bit by it, as it might not have occurred to them, but it’s part of the model.
The third strikes me as counter-intuitive and hard to reason about.
P.S. If you publish your keys or access tokens for well known services to GitHub and you are prominent enough, they will be found and exploited in minutes. The idea that deleting the repository is a security measure is not really worth taking seriously.
If you need second level precision for scheduling, you probably do, but a u16 will cover a 45 day range with minute level precision.
This will be bad for write performance, but solves the problem of needing to do multiple searches to find the next available slot, and you mentioned that you might not mind sacrificing write performance.
[1] The big brain take behind "necessarily" is that: "no salaries, everything is free" seems cool, "no salaries, a few people hoard all the wealth" seems bad.
Steve Bannon, Trump's chief strategist in 2016, argued that the quantity of Asian CEOs in Silicon Valley undermined "civic society" https://web.archive.org/web/20161117164322/https://www.theve....
There absolutely are a lot of people who want to restrict legal immigration. If you deny that, you're just pretending that you're not helping them out.
> The most recently dismissed claims were fairly important, with one pertaining to infringement under the Digital Millennium Copyright Act (DMCA), section 1202(b), which basically says you shouldn't remove without permission crucial "copyright management" information, such as in this context who wrote the code and the terms of use, as licenses tend to dictate.
> It was argued in the class-action suit that Copilot was stripping that info out when offering code snippets from people's projects, which in their view would break 1202(b).
> The judge disagreed, however, on the grounds that the code suggested by Copilot was not identical enough to the developers' own copyright-protected work, and thus section 1202(b) did not apply. Indeed, last year GitHub was said to have tuned its programming assistant to generate slight variations of ingested training code to prevent its output from being accused of being an exact copy of licensed software.
So (not a lawyer!) this reads like the point about GitHub tuning their model is not a generic defense against any and all claims of copyright infringement, but a response to a specific claim that this violates a provision of the DMCA.
I don't know whether this is a reasonable defense or not, but your intuitions or mine about whether there is a general copyright violation or what's fair are not necessarily relevant to how the judge construes that very specific bit of legal code.
- Quick running tests, detailed assertions —> PBT
- Longer tests, just looking for a crash —> fuzzing.
- In between, who knows?
https://hypothesis.works/articles/what-is-property-based-tes...
I'm a bit of a novice, so it sounds like this is the same explanation you're giving. What is the article leaving out?
It's interesting, but I share the thought that the impact is overstated.
It seems to me that the root issue is that encapsulation becomes our enemy here. We want to be able to call some code and not care about the details of how it is implemented. But reliable cancellation requires some sort of design that lets us know exactly what side-effects code has, control them, and force them to be done in a way that's transactional, while still letting us cancel the operation at the right time. We don't want a black box.
I suspect the two general solutions are: 1) elbow grease: manually inspecting the code that you're calling to understand whether it's safe to cancel and designing a bespoke sandbox: a thread in some cases, a process in others, re-architecting the code you're calling in others... 2) something about algebraic effects or capability systems that I can't speak to because I only have vague ideas how they work and haven't applied them in anger.
InterruptedException is better, but requires something closer to cooperative multi-tasking. If the thread is in a long-running loop that's not doing IO or it swallows the InterruptedException, you won't actually be able to kill the thread.
At work, someone had implemented an interface that let you kill a thread prior to my joining the company, so I found out that the warnings are very real when someone did that and it left the application unable to fetch DB connections.
It's true that there are technical enforcement mechanisms, and corporate policies, but it is false that the former must be called permissions, and the latter must be called authorizations. The policies can easily be called either authorization or permission. It is true that we refer to e.g. Unix file permissions, and a corporate policy is more likely to use "authorization" but this is not a semantic difference--the corporate policy would be correct and binding if it used the word permission.
If a fellow employee asks you "do I have permission to do this?" you must say "no" (or alternately "you're not permitted, even though the computer will not enforce that"). Saying "yes" because there is a technical permission would be a very bad idea.
Though I would just leave those strings out of the WAF.
If you look at the author's /now page, it's very clearly not that: https://sive.rs/now.
That doesn't help you if you're stuck using a library that doesn't perform those optimizations, but it means you need to be careful about importing your assumptions about regex performance from one language to another.
See also: https://github.com/burntSushi/rebar
Also, I’ve learned a lot from your code. A lot of this project was stubbornly banging my head against the problem, but whenever I wanted to see how another engine did things, your library was the one I looked at.
Beyond those factors, there's the matter of just proving out that my testing is good enough, and I haven't missed edge cases.
I have very idly thought about being able to output native code for use in other systems, but realistically, I have enough other ideas to keep my nights and weekends busy for a long time.
On the other hand, if he did realize that this innocuous looking json update would render as CEO of GitHub, I'm not sure I hate it. I think people offering their time to chat with others is great, but I'm not a fan of this type of aggregation. If this makes it look sillier, maybe that's ok?
That said, if you have a system X, it can't prove it's own consistency, but a stronger system Y can prove its consistency (and perhaps some other stronger system can prove Y's consistency. This gives us a chain of systems, each proving the consistency of some weaker system).
That doesn't absolutely prove that the system is consistent--if Y was inconsistent, it could prove X is consistent (and also could prove that X is inconsistent). Nonetheless, it is still valuable. After all, part of our use of Y is the fact that we know of no inconsistency in it. And since formal systems often are subtly inconsistent, "consistent assuming some other system is consistent" is a lot better than "we have no proof whatsoever of consistency".
From the article:
> Even then, the discussion was not quite done; Momjian questioned merging this change so late in the PostgreSQL development cycle. ""My point is that we are designing the user API in the last weeks of the commitfest, which usually ends badly for us"". Fennema-Nio pointed out that the API was essentially unchanged from its initial, September form, and that months had been spent discussing alternatives. Haas said that such a small patch would not improve by being held up for another release cycle: ""I think it has to be right to get this done while we're all thinking about it and the issue is fresh in everybody's mind.""
Kibana is ok (definitely beats grep) when you want to look across a fleet and determine if a specific thing is happening. But when you have a specific symptom that happens on a particular instance, what you want to do is see logs in the order they happened, and Kibana isn't close. Querying and viewing logs are just slow and cumbersome relative to less/grep.