orangea

- Doesn't allow installing multiple versions of packages at the same time

- In practice, requires being installed to /usr/local

- Hard to uninstall in practice, leaves files scattered behind

On the other hand, the F key has a bump on it on every keyboard I've recently come into contact with, which could provide an anchor.

I suppose with ESDF you have the two keys Q and W where otherwise only tab would be.

You could also just find a way to rebind caps lock, which would accomplish more or less the same thing.

> Another bought a laptop by taking out a stablecoin loan on a DeFi platform when no bank would lend to him.

Could someone explain this to me — I thought that loans on cryptocurrency platforms had to be collateralized by cryptocurrency? How could someone buy a house with a crypto loan if they didn’t already have enough to buy one in the first place?

That is almost certainly possible with github actions.

IMO symbolic math is Mathematica's strength and I wouldn't recommend it unless you are using it for that.

> If you use open source you are accepting the license that says that there is no liability.

The article directly contradicts this:

> What if an open source project is used directly by consumers, and causes them harm? The public policy is clear: they must be compensated. Does it matter if they signed a license or didn’t pay someone? Their business is bankrupt, their files are in a hacker’s hands, or their own customers are suing them. Someone should be strictly liable.

- Truly open source, presumably without the caveats that VS Code has such as a few "features" (extensions) being closed source and the extension marketplace being closed to de-microsofted builds

- Designed from the beginning to support an extension API with a richness comparable to VS Code's (unlike Sublime, Jetbrains etc)

- Presumably aiming to put performance as a higher priority than is usual

In the "on top of WASM" case, I imagine that the advantage of Python and JS will be exactly the same as the "not on top of WASM case". Namely, mainly development convenience at the cost of performance.

Here is a specific example, again using Python, of how a programming language not designed for WASM might not be ideal: suppose you are writing a Python script which is to be compiled to WASM and needs to import a function. How do you specify that in the script? There could be some Python function like `wasm_import("my_function", "u32", ["u32"])`, which allows the programmer to specify a function to be imported... and the problem with that is that in Python everything normally happens at runtime, but the compiler which is turning your script into a .wasm file needs to know in advance what functions you are going to import. So you face a dilemma: either you mess with the fundamental assumption of Python that everything happens at runtime, or you add new syntax which allows specifying metadata, or you use magic comments, or do some other hacky thing.

This might seem strange to those who are used to today's dominant WASM paradigm, where the programmer usually controls both the VM and the .wasm program — such as website developers who create a .wasm file and then also write the Javascript to load it into the browser. But one of the most exciting things about WASM, to me, is the potential for domain-specific execution environments in which the code which loads and executes the WASM is written much earlier and by a different entity than whoever writes the WASM.

When I see "powered by WebAssembly", I take it as a sign that the language is going to be designed around WebAssembly's VM interface rather than the implicit standard of the C memory model and POSIX-like API which basically all popular programming languages are designed for. Even languages like Python have the concepts of stdin/stdout/stderr, a filesystem, threads, and a single globally accessible heap baked into their design. It would take a lot of work to amend Python's design to be able to easily use features that are somewhat unique to WebAssembly like the various things a .wasm file can import or export. As it stands, languages like Python can be run on WASM, but they use inelegant hacks in order to be able to replicate the execution environment features that their interpreters require such as malloc, and usually it is assumed that the target will be WASI. A language that is designed for WASM from the ground up would make it so that WASM can be used to its fullest potential as a lightweight execution environment that makes extremely minimal assumptions about what interfaces are going to be provided to the program.

In common usage of the terms, "reference counting" and "garbage collection" are completely different.

If you got hit by one of these then you wouldn't feel anything. The energy is about 50 joules, or about 1/2 of the heat that a human body produces in a second.

Note that such a baseball with the same energy as this particle would still have much more momentum than the particle. So getting hit by the particle wouldn't "leave a bruise".

That doesn't mean getting hit by this particle would feel like a punch, since what you feel when you get punched is a transfer of momentum rather than a transfer of energy.

Mac doesn't have seccomp so no. The functionality could be implemented but it would have to use a completely different mechanism.

IMO the solution is to give users the tools to run apps in a sandbox without forcing them to or making it the default. If an operating system like macos were to ship with a user-friendly UI to change what a given app has access to, then even relatively non-technical users might decide to e.g. turn off WhatsApp's access to various things if they happen to read a news article about the app's data collection.

In addition if an OS provides a way for sandbox settings of apps to be changed, then something like "ublock origin for the OS" could be created, where someone maintains a list of what capabilities should be granted to various apps, and users can just install something once and forget about it to harden their system.

Most users trust most of the apps installed on their computer, but might have a few things that they are suspicious of — such as things they have to install for school or work. Providing a way for users to restrict the capabilities of specific apps when they feel like they need it could be valuable.

Linux already effectively has this because it has stuff like user namespaces and better support for controlling other processes using ptrace than other OSes. This enables users to use things like proot and bubblewrap to apply sandboxing when needed.

So does macos: https://developer.apple.com/library/archive/releasenotes/Int...

The rule isn't really about lisp, it's about the kinds of functions and structures you find in the standard library of a typical programming language, such as strings and arrays and file IO and so on. Rust already has those things so your argument doesn't really apply.

I think the picture isn't supposed to imply she's going to shoot herself, she's just holding a gun and she doesn't care that she's doing it in an unsafe way because she's an actor and it's a prop gun.

> What I ended up doing was making some scripts to install empty universal Erlang servers on all the Planet lab machines (pretty much like the code in this article) - then I set up a gossip algorithm to flood the network with become messages. Then I had an empty network that in a few seconds would become anything I wanted it to do.

But you already had an empty network that in a few seconds would become anything you wanted it to, that's how you installed empty universal Erlang servers on all the computers.

I'm not sure if VS Codium has profiles like that, but Nix can be used to create them. There is support for configuring an installation of VS Code in the Nix language and using it as a package.

If your site becomes a spectacle/popular/viral, which I don't think it will, people will submit false data. I don't see how you can possibly deal with that.

I'm all for alternatives to HTTP but they really aren't related to this. If you want your site to not be affected by WEI then just don't use the WEI API. And something like WEI could be implemented just as well over those protocols as it is over HTTP. It is just a completely unrelated concept.

> "Keep in mind that after the amount becomes very small, it is likely that the body will dispose of it all at once rather than halving the amount forever."

I don't think that's how it works...

VS Code certainly can be configured to have a keyboard shortcut to switch to a terminal and another shortcut to switch back and/or close the terminal. In fact probably every popular editor with a built-in terminal can do that.

You have to be logged in to github for it to work.

Also see https://devpod.sh/ which has had quite a lot of exposure on HN recently.

It's true that the sandboxing aspect of vscode.dev and codespaces is a major part of their appeal. It's unfortunate that operating systems were designed with more or less of a "if malicious code is running on your computer, you are already screwed" paradigm, and that part of the reason that running web apps in browsers is such a popular mode of operation is that they don't follow that philosophy.