nightpool

So Ruby Central, by their own admission, agreed to take $$$$$ of funding on the premise that they would "secure RubyGems against supply chain attacks", and then sat on their hands not doing anything about it until a few days before the deadline, when it was too late to seek community consensus or figure out a good transition plan. So they ended up screwing over everybody who was actually doing work on the project in favor of their own funding. And also they apparently used this as an opportunity to consolidate their power in other ways (renaming the github org) for reasons that were unrelated to the self-imposed deadline. How does this make them look better?

That doesn't sound very reasonable at all. Ruby Central, by their own admission, agreed to take $$$$ of funding on the premise that they would "secure RubyGems against supply chain attacks", and then sat on their hands not doing anything about it until a few days before the deadline, when it was too late to seek community consensus or figure out a good transition plan. So they ended up screwing over everybody who was actually doing work on the project. And they apparently used this as an opportunity to consolidate their power in other ways (renaming the github org) for reasons that were unrelated to the self-imposed deadline.

Have you spent time reviewing the security patches for any nontrivial application recently? 90% of them are worthless, the 10% that are actually useful are pretty easy to spot. It's not as big of a deal as people would like to have you think.

How much do you think advertisers would be willing to pay for ads on the side, relative to what they're currently paying? You can see how people wouldn't be willing to pay the same amount for that, right?

The other commenters point out more prosaic problems with CDN architecture, but a more product-focused answer for this is "because users execute Javascript but bots don't". Using client side counting is an easy way to filter out simple automated traffic.

Also, with segmented MP4 streams, the files on the backend won't necessarily be easy to match up 1:1 with videos. How do you count the views if someone watches a video, and then skips back to watch the middle section a few times, and then doesn't finish it? Because that would show up as (1, 1, 4, 3, 0) in your database for the different files involved. Now imagine doing that for ~500 people on a shared IP address for their high school. And now your minimum threshold for view counting is tied to the size of your MP4 chunks, or range requests. And now you've put this view counting logic into the hot path of serving terabytes of data.

From a product perspective, you can see why "A video view is counted the first time the user presses the play button and watches for at least 30 seconds" is a much more desirable definition, both technically and for stakeholders (video creators, advertisers, etc) to understand.

Why can't you leak timestamp data? What timestamp data is sensitive to your system?

Also, why use UUIDs in that case?

Not just a small inconvenience—because there's no human readable way to tell the difference between v4 and v7 IDs, you have to guess and check whether or not the ID your server process is logging is a pre-conversion or post-conversion ID

Cypher in a sibling comment makes a good argument that this was the same logic (patent termination for legitimate, non-licensed patent claims) that got Facebook in trouble: https://news.ycombinator.com/item?id=45199687

(er, surely it's the other way around? the 3-clause one is OSI approved and the 4-clause one is not)

Anyway, I'm not sure this is true. Having a separate software license + secondary patent grant license is very very common in open source projects where patent trolls are common. See e.g. https://aomedia.org/about/legal/

I would just put them in separate files and then you're good to go.

Agree with this—the A/V media system has some of the most active patent trolls around. https://aomedia.org/license/patent-license/

The relevant patent license is the following:

> 1.3. Defensive Termination. If any Licensee, its Affiliates, or its agents initiates patent litigation or files, maintains, or voluntarily participates in a lawsuit against another entity or any person asserting that any Implementation infringes Necessary Claims, any patent licenses granted under this License directly to the Licensee are immediately terminated as of the date of the initiation of action unless 1) that suit was in response to a corresponding suit regarding an Implementation first brought against an initiating entity, or 2) that suit was brought to enforce the terms of this License (including intervention in a third-party action by a Licensee).

Cool. Then keep using Docker Desktop if you want to. That's not the situation most of the people in this thread are talking about though.

The bit about the name seems to be a complete hallucination / tokenization error. The project's docs say: "Forgejo (pronounced /forˈd͡ʒe.jo/ (hear an audio sample)) is inspired by forĝejo, the Esperanto word for forge." I would expect the rest of the AI summary to be similarly unreliable / hallucinated—I compared the test directories for both projects and they both seemed to have about the same amount of activity.

Forejo is/was a soft fork of Gitea due to some licensing / trademark bruhaha that I think got blown somewhat out of proportion. (And Gitea was famous for using Github instead of dogfooding their own software, which I've always thought was a pretty strange choice). I'm not familiar enough with the development roadmap of both teams to make a good call on whether following the fork is a good idea or not, but I know a lot of projects are just bandwagoning on the fork due to generally frustrating Gitea governance. GitLab is open core and I know a lot of people are frustrated with their UX and with their high resource consumption for self-hosting (although I would expect YJIT probably made a big improvement here). I've only seen maybe one project use Gogs seriously, I don't get the sense that it has the same level of adoption as the other three.

You are replying to the GP.

Surely moving those containers to alpine would be 1000x easier than rewriting everything in wasm though.

GIFs historically were pretty unoptimized from a display perspective (as anyone with a moderately-active Tumblr dashboard could tell you), so I wouldn't be surprised if it was worse.

I think it probably just means that they exhausted the competition time limit without completing the "thinking" portion and getting to the "output" stage.

That is not an issue when using Private Spaces, which have been available since 2015

What about Heroku made Erlang clustering difficult? It's had the same DNS clustering feature that Fly has, and they've had it since 2017: https://devcenter.heroku.com/articles/dyno-dns-service-disco....

Oxford is the world's what? If you believe that then I have a bridge to sell you.

How so? Can you give an example of a municipality that you feel like messed with light timing for "selfish" reasons?

There are hundreds of files on your system that if you could write to them would cause a RCE. For example, `AUTOEXEC.BAT`. While the intermediate step (how do you go from writing a filename without an ^M to writing to an arbitrary file on the target OS?) is also somewhat surprising (and maybe points at some potential deeper fixes within git or potential TOCTOU bugs?), ultimately it's the exact same as several other vulnerabilities in this class from the same author (see the 2024 case-sensitivity bug they linked), so I forgive them for glossing over it.

Language preferences are (in all of the deployments I've seen) legally categorized as functional cookies and not strictly necessary cookies. Same with e.g. dark mode/light mode or other preference toggles

You're correct that the GDPR specifically doesn't require this, but you're incorrect that "the law" doesn't—the 2004 EU ePrivacy Directive requires affirmative consent for all cookies, and it's being enforced much more strictly now in a post-GDPR world

You're correct under the GDPR but incorrect under the older ePrivacy Directive. EU sites need to be compliant with both, and so the cookie banners persist.

Okay, so fuzz the frame rate and latency? That feels very easy to fix.

> Compare tires of today to the ones 20 years ago and the technology and capability is very different, even though they look identical to a casual eye

Can you share more about this? What has changed between tires of 2005 and 2025?

How would that solve the font problem? I feel like that would only make the problem of having unsupported fonts even worse.

The "Mitigation and Service Restoration" phase here is definitely the weakest one in terms of explanation—5 hours for root cause discovery is a rough break, but somewhat understandable given the difficulty in isolating the hosts and debugging the obscure networking failure. But once they found the automated package update responsible, no detail was given at all for why it then took four hours to even consider a hotfix to disable the automatic package updates. Just a complete empty gap

Also, "token used for automatic updates"? So like, some kind of third-party vendor was automatically live-updating system packages on their running dynos??? Who the hell thought that would ever be a good idea? And once you've discovered an issue with it, why would you make that critical path remediation dependent on a third-party who probably doesn't even consider this a critical incident?

Here's a really simple question—once engineers confirmed the outage was major, why did it take 8 hours for someone to think of trying to log into the herokustatus Twitter account? Was there no one assigned to public comms during this incident?

Stop paying them, I guess, and find a different audit firm that's more knowledgeable. Just like anything else—you get the level of competence you pay for. (Although I guess there's probably a "sweet spot" at which you can pay less AND get better first-level auditors if you're not looking at the biggest firms that are going to charge the most money and also have the most churn)