reaperhulk

They experimented with it but ultimately decided to focus on perf with their existing ruby codebase.

https://github.com/Homebrew/brew/issues/7755#issuecomment-51...

Discussed 3 months ago as well: https://news.ycombinator.com/item?id=46949642

Maybe for our tenth anniversary we should update the codebase and finish some features we haven’t touched in a decade…

We launched Feb 2, 2016 so almost a decade since then! Of course, we ran it for just ourselves a bit longer so it’s been slightly over a decade at this point.

The shark line is a quote from Futurama in an episode where an 80s corporate raider takes over Planet Express.

DF already has a vibrant Patreon community so they’re not starting from scratch on funding themselves. I’m excited to see what they can do going forward.

Previously discussed here: https://news.ycombinator.com/item?id=38851337

Thanks for posting! I had forgotten just how long a road this was, but I'm very pleased that the requirements we talked about years ago have been met. :)

That's not to say this is done! There's a set of features we still want to add and we'd like to gain some confidence in the APIs as structured before we mark them as stabilized.

The article states it's the French version of the Mars wikipedia entry and the repository has a link to the file he used in the readme: https://raw.githubusercontent.com/lemire/unicode_lipsum/main...

This is an account linked to a gmail address with no other comments on the tracker. Is there any evidence this is/was a Google employee and not just a random troll in the issue tracker?

Occasionally that “similar sound” proclivity leads them down confusing paths: witness stage manager and center stage, which many people seem to struggle with separating!

Do you have a source for this claim? As far as I’m aware Azure racks mac minis and has no special license, but I’d be fascinated to be wrong.

GT Advanced Technologies (https://www.sec.gov/news/press-release/2019-66 SEC went after them in 2019)

That may not entirely be true, at least as recently as a few years ago. https://www.economie.gouv.fr/dgccrf/plan-controle-2016-des-h...

You can avoid this by building cryptography as a docker stage and then just extract the wheel as part of your docker build process. Alternately if you install rust, build cryptography, and uninstall rust all in one layer then you can also avoid this issue.

(I'm one of the cryptography authors)

We did not roll back our dependency, no, although our current release (3.4.x) allows you to disable Rust compilation via an environment variable specifically so we could understand where in the ecosystem challenges would occur. Our next release (now 35.0 based partially on feedback from the community around our unusual versioning) will hard depend on it for all X509 ASN.1 parsing. During the months since we did our first rust release, however, the `musllinux` specification and implementation has been finished so we expect to be able to ship binary wheels for Alpine very shortly. I am actually working on that today, with the only remaining blocker being an update to warehouse to allow wheel upload.

Without addressing any other points you’re making, NCMEC wrote the email to Apple that contained the “screeching minority” phrase. It was not something Apple wrote.

They may be working on other things but they also trumpet harmony as their own. Ars Technica wrote an article about how original it actually is: https://arstechnica.com/gadgets/2021/02/harmonyos-hands-on-h...

Many of the problems people appear to be having with pyenv on M1 are related to it pulling include paths for homebrew that include homebrew libffi, but not passing the library path. For cases like cffi this results in header/library mismatch and you get runtime dynamic linker errors.

Other replies here appear to assume basic compilation issues, but the issues I've seen on various GitHub projects are mostly related to these more insidious C toolchain challenges. They're not M1-specific, but they are manifesting on M1 machines.

Apple has allowed content blockers in safari on iOS for several years.

A good example of how rapidly a CRL can grow in size is Apple's WWDRCA CRL. Current size: 224MB despite only containing revocations back to Feb 2020. http://developer.apple.com/certificationauthority/wwdrca.crl

Attestation has allowed a website to lock to a specific vendor for 5+ years.

In my experience it is exceedingly difficult to meaningfully accelerate the timelines on publishing an S-1. There are too many lawyers, financial audits, investor roadshow schedules, et cetera. This is likely pure coincidence.

Making more things accessible via memory safe languages allows people to more easily transition to those memory safe languages even if they have dependencies that are not themselves memory safe. Boiling the ocean is impractical and memory safety is not all or nothing, so we're interested in encouraging people to find ways to migrate larger and larger pieces.

That said, we will consider level of effort as a component of our judging process when determining eligibility and bounty size.

PCSX4 is a fake, see: https://www.pcgamer.com/ps4-emulator-pc/

This is Google and Mozilla aligning with Apple's earlier announcement (https://support.apple.com/en-us/HT211025).

The CABF has talked about doing this before, most recently in SC22 (https://cabforum.org/2019/09/10/ballot-sc22-reduce-certifica...). In that case all browsers supported it, but it wasn't passed by the CA side.

Thanks for the context. Unfortunate that this silent failure is present in 20.04 with no fix so far.

Ubuntu 20.04's mdadm package doesn't appear to have a crontab entry for scrubbing actually (while 18.04 does). It does have e2scrub_all, but does that serve the same purpose?

The goal is to promote automation and continue lowering certificate lifetimes as operations get better. This ultimately will allow for lifetimes short enough to be useful.

As for the other browsers, Google originally proposed SC22 (https://cabforum.org/pipermail/servercert-wg/2019-August/000...) last year and all the browsers voted for it. CAs voted it down at the time but there were rumblings via various back channels that several major CAs actually wanted the ballot to pass but for political reasons could not publicly support it.

So while Apple is acting “unilaterally” here, there is universal support among browser makers and tepid support from CAs. You should expect Google and Mozilla to follow suit in the next 6-12 months.

Firefox is not vulnerable, but (non-updated) Chrome actually is (until they replace the platform TLS verifier, which is happening soon).