molf

This seems super light on details and I had to dig to find more information. We don't use Gitlab, but we do use Ruby, so I was worried we might be impacted.

This is the best overview I found: https://lilting.ch/en/articles/gitlab-cve-2026-110264-org-mo...

The bottom line: this is an issue in Ruby's regex engine, which was fixed in April and backported recently. [1]

Everyone running applications where attacker-controlled input might find its way (unescaped) into Ruby regexes is vulnerable to remote code execution.

[1]: https://github.com/ruby/ruby/pull/16801

> HOAs don't make neighbors co-owners of your own property, do they?

Home-owner associations in Europe are frequently set up for apartment buildings, in which case, yes, the roof, foundation, hallways, stairwells, main piping, electricity, etc are all legally co-owned. Primary purpose of HOAs is to save for & plan long-term maintenance on the entire building.

HOAs for neighbourhoods, or blocks with single-family homes or terraced houses are pretty rare in Europe.

No it's not useful, no you don't know what you're doing, and no it is not 'proper'.

But you're learning.

Maybe just accept that not everyone starts from fundamental theory, and there are lots of people who start learning by fooling around.

> unless you'd call cargo-cult chaining magic numpy incantations you've taken from Karpathy's tutorials "exploring"

That's what I would call exploring.

I too started exploring programming as a teen by cargo culting. Fooling around and getting results is what made it fun. Understanding came later.

Why would you tell people that the correct order is to build foundational knowledge before exploring a subject? For some (many?) people, a 'proper' understanding develops _after_ the exploration.

> What about the riders who are on the receiving end of fraudulent drivers in the best case, abusive or dangerous drivers in the worst case? It is possible to go to far in trying to protect workers for things that impact paying customers.

Not saying they shouldn't be banned. But a human should look into it. Seems reasonable?

So according to the regulator Uber automatically suspended driver accounts that were flagged in decision of fraud or due to low ratings. They also failed to inform drivers about the automated decision making.

Here is the statement from the Dutch data protection authority:

   Uber made fully automated decisions regarding drivers. In cases of suspected fraud or excessively low customer ratings, driver accounts were automatically temporarily deactivated or, in the case of persistently low ratings, permanently deactivated. As a result, their income from Uber ceased during the deactivation period.
 
   Uber thereby violated the ban on fully automated decision-making under the General Data Protection Regulation (GDPR). The AP also found that Uber failed to adequately inform drivers about the automated decision-making. Uber has since ceased the violations.

Reference to the law that was broken (GDPR): [2][3]

   Article 22.1: The data subject shall have the right not to be subject to a decision based solely on automated processing, including profiling, which produces legal effects concerning him or her or similarly significantly affects him or her.

   Article 13.2f: In addition to the information referred to in paragraph 1, the controller shall, at the time when personal data are obtained, provide the data subject with the following further information necessary to ensure fair and transparent processing: [...] the existence of automated decision-making, including profiling, referred to in Article 22(1) and (4) and, at least in those cases, meaningful information about the logic involved, as well as the significance and the envisaged consequences of such processing for the data subject.

[1]: https://www.autoriteitpersoonsgegevens.nl/actueel/uber-krijg...

[2]: https://gdpr-info.eu/art-22-gdpr/

I agree.

But wouldn't you want a human to be involved in this process?

Let's say you run a legitimate SaaS company, and a cloud provider suspends your account due to an allegation of fraud. Wouldn't you prefer a human is involved?

To me that seems pretty reasonable when people's livelihood is at stake.

That's irrelevant.

   The data subject shall have the right not to be subject to a decision based solely on automated processing, including profiling, which produces legal effects concerning him or her or similarly significantly affects him or her.

Nowhere in article 22 [1] does it restrict the scope to employees.

If Uber processes data, and makes decisions based on that data in a purely automated way that significantly affects people, it is not allowed. That's all there is to it.

[1]: https://gdpr-info.eu/art-22-gdpr/

But it's not enterprise SaaS, is it? It's just a time tracking and invoicing tool. And it's not the only SaaS they will need?

Companies with 25 employees generally don't have money to pay a dozen SaaS vendors $2k each every month.

Maybe certain niche products that are critical to the business might be worth that much. But a time tracking & invoicing tool? Definitely not. Source: am actively moving away from Harvest due to this ridiculous price hike.

I don't think the point is that PostgreSQL is great for everything. But you may get by with a single piece of infrastructure instead of 7.

In most of the applications we build or maintain we use PostgreSQL + cloud storage. That's it. And it works very well, also for: storing JSON, full text search, as a queue, as a vector database. Other software may be better at providing those features, but I'm extremely happy we only need to understand & manage PostgreSQL.

They're called Antilopen in Dutch too, so I think most people would just associate it with the animal?

I believe such organisations tend to do such things very intentionally :-)

About ESO [1]

> We are an intergovernmental organisation established in 1962 supported by 16 Member States (Austria, Belgium, Czechia, Denmark, Finland, France, Germany, Ireland, Italy, the Netherlands, Poland, Portugal, Spain, Sweden, Switzerland and the United Kingdom), our host country Chile and strategic partners.

So Chile has a distinct status, hence the margin...?

[1]: https://www.eso.org/public/about-eso/

Double? Rookie numbers.

We went from $1k to $21k per year.

A few emails later and we have a hefty discount, but we will still move away.

If you’re interested in what a specific piece of code compiles to, it’s worth checking out the online compiler playground [1]

https://playground.react.dev/

It really does work very well in practice. A few things really help:

- Lints [1] that flag code that cannot be (correctly) optimised. Usually this is obscure code that is too smart for its own good. But the compiler leaves it alone and flags it for review, so most things just keep working.

- Lints that flag code that violate the rules of hooks. These rules became more critical to follow: failure to do so may break rendering. But non-compliant code can be easily be excluded from compilation [2], so you do not have to fix everything at once.

- Popular libraries that are not compatible (yet) are flagged and excluded automatically [3].

The compiler is better than manual memoization, because 1) it is hard not to forget memoizations, and 2) the compiler's output memoizes more granularly than manual memoization realistically could.

I have not found performance regressions. Not saying they're not possible; but we haven't encountered them.

We have a very performance-sensitive project that used preact (chosen for performance) via its compatibility layer, that we switched to React + React compiler. Performance is noticeably better than with preact. Whereas previously the React-only version was incredibly slow even with carefully placed memoizations, because they were very hard to get right.

[1]: https://react.dev/learn/react-compiler/installation#eslint-i...

[2]: https://react.dev/learn/react-compiler/incremental-adoption

[3]: https://react.dev/reference/eslint-plugin-react-hooks/lints/...

After bun [1] this is another high-profile project that was ported to Rust by extensively using LLMs.

Very curious to see how these rewrites play out. Is the LLM foundation solid enough to build upon and iterate on? Or does this cause projects to become unmaintainable because no person understands the implementation anymore?

[1]: https://news.ycombinator.com/item?id=48132488

So isn't not changing more sensible than changing to an arbitrary alternative?

The current developers surely are more familiar with the Babel representation than OXC, so why switch?

OXC is not the only consumer, so using the OXC AST wouldn't particularly make sense? I thought it was pretty well explained in the PR:

> Note that the conversion from any AST into our HIR is complex, and we can only maintain one version. Hence we've aligned on using a Babel-like AST as our public API. Another key point is that we don't yet implement our own scope analysis (since the TS version of the compiler relied on Babel's scope analysis), so for now we require that the scope data be serialized. It's a denormalized graph, and some metadata has to be stored to associate nodes with scopes. We're open to feedback about the AST and scope representation - we iterated a bit just to get things to work, but it can be more optimal.

Yes absolutely.

It's brilliant: all useMemo and useCallback can be removed and you get the same runtime performance and then some, at the cost of only a slight increase in code size.

A small downside at the moment is the build time. This change will hopefully help address that because it will no longer depend on babel.

There is no SQL successor: SQL is here to stay.

Applying the Lindy effect [1]: after half a century of SQL we can expect it to survive for at least as long.

Disruption/displacement of SQL is like attempting to replace email. It's not going to happen. At best an alternative technology can carve out a small niche (and there's nothing wrong with that).

[1]: https://en.wikipedia.org/wiki/Lindy_effect

I have no idea; but I presume they don't, given that ZJIT today is still much slower than YJIT? [1]

[1]: https://rubybench.github.io

Were there 1M line diffs in the past, before LLMs? That seems (seemed?) legitimately insane.

Simultaneously a very good example of how Github needs to adapt to the changing software development landscape?

This specific painting was reinterpreted based on specific descriptions of the colours in a letter from the painter.

As far as I'm aware there is no way to know for sure what colours originally looked like, especially if the information is limited. There are so many variables, we can only guess.

Agreed. I absolutely adore the idea of it! But all the brownish colours tell the same story.

For some additional context; many old pigments were not stable at all.

https://www.vangoghstudio.com/what-were-the-original-colors-...

> Most useful async blocks are big enough that the overhead for the error cases disappears.

Is it really though?

In my experience many Rust applications/libraries can be quite heavy on the indirection. One of the points from the article is that contrary to sync Rust, in async Rust each indirection has a runtime cost. Example from the article:

    async fn bar(blah: SomeType) -> OtherType {
       foo(blah).await
    }

I would naively expect the above to be a 'free' indirection, paying only a compile-time cost for the compiler to inline the code. But after reading the article I understand this is not true, and it has a runtime cost as well.

It's not possible to learn anything about other elements when performing binary search, _except_ the only thing there is to learn: if the target is before or after the recently compared element.

If we would guess that there is a bias in the distribution based on recently seen elements, the guess is at least as likely to be wrong as it is to be right. And if we guess incorrectly, in the worst case, the algorithm degrades to a linear scan.

Unless we have prior knowledge. For example: if there is a particular distribution, or if we know we're dealing with integers without any repetition (i.e. each element is strictly greater than the previous one), etc.