It's the ISBN of Edward Snowden's book "Permanent Record: A Memoir of a Reluctant Whistleblower". The numbers in the poster differ because it's the ISBN of the Swedish translated copy of the book.
Unrelated to his book, but anyone else find Ed's last name mildly amusing?
English is not my first language so when we say "Snowden", unless we really try to do an American English accent, it can sometimes sound like "Snowedii-n".
His last name means:
> English: habitational name from any of the many minor places called from hills where the snow lay long (Old English snāw ‘snow’ + dūn ‘hill’). [0]
"To be snowed in": when you can't exit the property/house because of fallen snow. Keep that same thought but remove the snow element (still "stuck") and replace property with country.
Now take "Snowden", but make the E longer and make it sound more like an I.
Edward Snowed-in. One could say that he is snowed in, in another country.
Similary, another NSA leakers name: Reality Winner.
Not poking fun at their names, just pointing out the irony because of the situation they are/was in.
> a change in the indentation used in our bundle files (4 spaces -> 2 spaces)
I find it interesting that one of the reasons given for the reduction in package size is due to such a simple indentation change from 4 spaces to 2 spaces.
Not interesting that 2 bytes are less than 4 bytes, rather, TypeScript is a large project and it would be interesting to know how much size was saved from this one specific change? Seems like a trivial change, so why not do it sooner? And assuming readability isn't required in the bundle output why not bundle with no indentation at all and put everything on a single line, would this not be even smaller again?
TS has some unique restrictions due to downstream patching of our package; my PR description briefly talks about this as something we can try to improve in the future. Minification absolutely would save a lot more size out of our package, but I was not willing to change that in this PR.
They aren't debating it. And I don't think why you'd think setters and getters are not worth debating. There are significant downsides to them (e.g. they make Dart's sound nullable support more annoying).
I replaced my companies Google reCAPTCHA validation with Turnstile and so far the implementation experience has been fine. Not so different from the Google implementation and no major issues I have come across thus far.
In terms of how it actually performs, it’s only been deployed in staging and a limited user preview version of the site so far, so it’s yet to experience much of the bad traffic or edge cases that might hit the production site.
As a child my cat would favour drinking water from our chlorinated pool rather than her water bowl. Interesting to read another anecdote about cats and chlorine. They say curiosity killed the cat, but maybe I’ll take the gamble and see if I can find an answer as to why!
The third field of the triplet is for the operating system identifier [1] which can be expressed as two fields in the form of `<sys>-<abi>` [2] as well as just `<sys>`, when applicable. The LLVM docs also refer to the second part of the operating system identifier as the "environment type" [3].
Examples of allowed operating system identifiers could be `freebsd`, `linux-gnu` or `linux-android`. So, while it seems like four components, the last two seem to get combined to refer to a single "operating system identifier".
I'm no expert here, so corrections welcome, I was just curious from your comment and thought I'd share what I had found.
I think we can get the best of both worlds by hiding lock files by default and always showing any actual code file diffs. Performance may be a factor for very large diffs, but this would actually be my preference to how the default behaviour would work as I agree with you and the parent post.
I prefer to run Ubuntu machines and at least in terms of provisioning a new secure server I built an Ansible playbook I called 'ANU' (as in A New Ubuntu). I'd expand to other distros, but then I'd have to change the name!
It is based on the DevSec OS/SSH hardening playbooks, but I lean closer towards ease-of-use over security where I think it makes sense. For example, I disable forced password rotation and I keep the default umask value of '022' instead of the more secure '027'.
When I come across something the upstream playbooks change that "gets in my way", I will disable it if the security trade off makes sense for me. I'm not running highly sensitive systems, so these trade-offs make sense for me, and maybe they will for you as well!
In terms of ongoing security upkeep, I run the usual `apt update && apt dist-upgrade` when I can, but I’ll be keeping my eye on this thread for additional advice.
Yes, to both Vue and Nuxt via Open Collective. I use both tools so I like to give back to ensure work continues. I also like the idea of backing the 2nd horse in the race, so to speak, to keep competition active. A lot of backing and money is already behind React and its ecosystem, so putting my money towards Vue development feels like a win for me as well as potentially keeping the other frameworks and tools innovative.
