A person from a government told a person at Meta to block it, and that person did (probably by telling yet more people to do it).

But since asm.js is just (a subset of) javascript, I assumed I could just pass ArrayBuffers around.

With wasm, I could pass a Uint8Array out of it. If I wanted to pass it in, I had to call malloc from the javascript side to allocate in the wasm heap. But since I already had an arraybuffer (from a file upload), that meant an extra copy.

But wasm is too isolated from javascript. From my limited use of it, I was considering trying to compile to asmjs instead.

But I wasn't sure that emscripten still fully supported it.

You can't call most web apis from wasm.

But more important for what i was trying to do, you can't zero copy buffers from js to wasm.

Everything is a trade off. The isolation is a good thing, but also a bad thing.

Could someone explain it?

If you have a lot of new stuff to build, and if you're not currently losing money, why start a new initiative with a layoff?

Thanks op for reminding us of the privacy issues with our browsers. The EFF and others already told us, but the issues remain. Lets hope you're hear to stay and fight for our privacy alongside us.

You can observe the symbol. You can observe 42 of some object, 42 sheep for example.

You can observe a pie chart, or an actual pie, with 42% of it missing.

You can observe a plank of wood that is 42 inches or centimeters long.

But you can't observe 42 itself.

It is not like a hill on a map, where there is a symbol, and there's an actual hill.

It is an adjective and not a noun. It's not real unless it is describing something else.

My point being that regular finite numbers are not real either. So what's wrong with infinity? Or the square root of 2, or pi?

By that I mean, the basics reuse the way we faked formatting to do real formatting. The input is (usually) perfectly readable on its own.

Even if you don't know (or remember) how to author a markdown file, you can probably still read it just fine. The tables still look like tables. The paragraphs are just paragraphs.

I do still have to look up how to do stuff in markdown sometimes. And that's fine. Your active vocabulary is always smaller than your passive one.

So the way I judge this is by how readable the input is.

I'm not sure how well they succeeded at that. A lot of what they show doesn't really add to or take away from that.

But I didn't see any examples of them formatting math. I only rarely use LaTex. And when I do, it's not because I need a "paged" mode or need to include an author. It's because I need to format something markdown can't do, and that's usually a math equation.

So I am curious how that ends up looking.

It answers a lot of the questions I see being asked in this thread.

The bigger the company is, the more power they have typically.

If you want to make more money or get better benefits or otherwise negotiate a better contract, you need more leverage.

Unionizing is one way to gain more negotiation power by negotiating together with your co-workers instead of individually.

It also makes it easier to address cross cutting concerns like safety and fairness.

Different projects have different policies, and I don't know what SDLs is.

But they already have a lot of ports, so I trust they know what they're getting themselves into.

What changed to enable and popularized these bad business practices?

I'm glad it was resolved quickly for WireGuard, but I'm concerned the results won't generalize.

Also, thanks for WireGuard!

Is it though?

When I read the tutorial: https://docs.conan.io/2/tutorial/consuming_packages/build_si...

It says to hand write a `CMakeLists.txt` file. This is before it has me create a `conanfile.txt` even.

I have the same complaint about vcpkg.

It seems like it takes: `(conan | vcpkg) + (cmake | autotools) + (ninja | make)` to do the basics what cargo does.

It's similar, but designed for an existing ecosystem. Cargo is designed for `cargo`, obviously.

But `pyproject.toml` is designed for the existing tools to all eventually adopt. (As well as new tools, of course.)

Not sure how big your plans are.

My thoughts would be to start as a cmake generator but to eventually replace it. Maybe optionally.

And to integrate suppoet for existing package managers like vcpkg.

At the same time, I'd want to remain modular enough that's it's not all or nothing. I also don't like locking.

But right now package management and build system are decoupled completely. And they are not like that in other ecosystems.

For example, Cmake can use vcpkg to install a package but then I still have to write more cmake to actually find and use it.