lukesandberg

interesting. we had some reports like this of 'stuck errors' when filesystem caching was still very experimental, or back before we achieved 'stable' status. What version was this on?

We have invested a lot in webpack loaders which unblocked manmy ecosystem plugins. We don't particularly plan on creating a rust plugin API, when we do provide one it will be JS oriented. (well some people are interested in a wasm plugin layer, but we would always support JS first).

I'm not sure i understand your second comment? what got positioned as 'something good'?

it is true that our plugin story is not fully fleshed out. We have good support for webpack loaders and have observed that that solves many (though not all usecases). This of course is one of the reasons we are still supporting webpack

`fs` dependencies like that have caused issues before. the solution is typically something like

``` turbopack: { resolveAlias: { fs: { browser: './empty-module.js' }, }, }, ```

so different configuration but similar to what you would do in webpack.

i am unsure about the other wasm issue you mentioned... is there an issue describing it?

As for webpack, we will keep supporting it until we know there are no compatibility issues blocking people from migrating.

Is it? Isn't the bakery algorithm a demonstration of how to build a lock, not how to coordinate multiple locks?

Which is why the maxim "don't hold locks while calling untrusted code" exists. Holding a lock while invoking a callback is extremely dangerous. Some situations demnd doing this (but not that often), in which case you need to document it like crazy.

This is most likely due to a script screwing up. A lot of these companies retain companies that specialize in filing these requests (see: www.google/com/transparencyreport/removals/copyright/faq/ for some more details.

My limited understanding is that these companies just use google search apis to try to find search results matching keywords. Then they file requests for every matching url. This is how obviously wrong requests show up.

There are also cases where requests appear to be malicious, but there are really no consequences since you (iirc) have to prove bad faith which is next to impossible and since everything is being adjudicated via third parties, there is really no incentive.

It's been a while since i have written c# but wouldn't a closer/fairer comparison have been to use the fluent methods?

e.g. instead of var result = from p in numbers where p < 5 select p;

you could write: var result = numbers.Where(p => p < 5);

the 'from ...' and 'select ..' adds a lot of boilerplate

what would a reasonable criteria be? Should the EFF create criteria that could only be met by criminals?

The main issue with the gag orders that people are concerned about is not that they are fundamentally wrong, but that they are ripe for abuse. Many of these companies are publishing some data about these kinds of orders, so within the limits of the law they are doing everything possible.

> Nearly all the data requests that people are concerned about have been coming with gag orders attached.

citation? most data requests are run of the mill subpoenas (in non-criminal cases), gag orders only apply to a fairly small subset of user data requests.

to do that, wouldn't you have to look at every byte just to detect the runs of 0s, that would mean that you have to pull the whole file through the memory hierarchy of your system (rather than just passing chunks from syscall to syscall) wouldn't that alone slow you down significantly?

how does the stock split affect income? afaict it is purely about governance