bennofs

Other dep managers could at least tell you about the conflict. Maybe that's what vgo needs, a way to specify a conflict bound so that any downstream user is notified if the depgraph has conflicts (ofc conflict bounds would only apply after del resolution as simple checks otherwise it wouldn't be MVS)?

The equavilent in the unix world is gnome keyring (or any other Secret Service spec implementation) unlocked by a PAM module on login.

Pinning does not solve this. You still need a solver to generate new pin versions or update the pinned versions. Or do you manually pin/update each of the dependencies (including transitive ones)?

The thing that worries me about this line of thinking is that as far as I know, we don't know much about why SAT solvers tend to work well in practice. So if I ever happen to hit a problem that the solver cannot solve, all we can say is "well bad luck". If the algorithm fails, I won't have any way to know why. This strikes me as a bad situation to be in.

Many of the "dynamically typed language" features can be had in statically typed languages as well: there are statically typed languages that have REPls for example. Your point about having higher productivity in the beginning and then retrofitting types after that still stands though.

I understand your point and I as an Emacs user I also considered moving to something less "heavy" quite a few times. But I am not convinced that something like you describe is actually possible to build and at the same time be less massive than existing interfaces.

As a question to think about, what features does Emacs provide that are unused? I think most Emacs users end up using quite a lot of the features, so why do you think it will be possible to create something more lightweight?

Don't get me wrong, I want this to exist. But, it is important to look at existing solutions first. For example, isn't the X11or Wayland spec an implementation of "terminal mark 2"? A window manager is the shell. Perhaps we are just missing the right kind of utilities to make this environment as effectively as a terminal shell?

Another point to consider: are the frameworks massive by themselves? I would argue that the bloat comes mostly from having multiple frameworks. If all apps used the same version of electron then you could have a single electron runtime and then it could be more efficient. Same if all apps agreed on a single Qt or GTK version, or any other framework. If in fact redundancy between multiple frameworks is the problem, then another, new standard will not solve this.

In the end, I want to believe that there's something better, and if you have any examples or arguments to convince me I am eager to hear them.

The counter argument to that is if it causes user anger, then maybe it should not be enabled at all.

Also, I am not sure about it adding no security without verified boot - a machine rebooting is something that can be noticed.

With green threads, I think you can have async io but with threads. When your current thread is making an async call, suspend the green thread (cheap) and yield back to the event loop. Threads are woken up when their async call finishes. This avoids the overhead of real OS threads per connection.

Welcome to open source maintainership

Are you using stock magit? I think a few of the GitHub integration plugins for example have performance issues, so it may not be Magit's fault but some of the other extension you're using.

What's the problem with matrix plus bridges? I am uniformed, so don't take this question to imply there are no problems

I am a Nix user, but one advantage that Bazel has is that it can do more fine-grained incremental rebuilding (nix as commonly used can only do per-project rebuilds). Also while there is some overlap, Nix usually relies on language-specific package managers to perform the actual building, whereas bazel handles that itself. Nix is more of a packaging tool, whereas bazel is a build tool.

yes, I am also experiencing this. But this is not unexpected: if you take this spectre PoC: https://github.com/crozone/SpectrePoC/blob/master/spectre.c then all that is doing is reading data from the same process. With spectre variant 1, it is the code that is vulnerable (in this case, an unmasked bounds check). As the compiler does not do any mitigations for this, it is the software that has to protect against it (that's one reason why browsers for example needed mitigations, along with everything else running untrusted code). This variant is only a problem if you're trying to run untrusted code though... so you could say that the PoC itself has a security vulnerability, no wonder that still works (an OS does not prevent you from running vulnerable programs - there could be hardining techniques that can make it harder or impossible to exploit that vulernerability though.)

You can only read memory that is mapped in the address space of vulnerable processes with Spectre. Usually, that is only memory from the current process and maybe a small bit of shared memory (and code segments of shared libraries, but those don't contain any interesting secrets). So while you can read memory from other processes, those processes need to be vulnerable and you cannot read memory from processes that applied mitigation.

I haven't tried it, but I would be very surprised if it yielded good results for go code. Go assembly, from what I've seen, looks very different from the assembly produced by a C compiler. In particular, the calling convention will be different and everything involving strings or other non-integer types will be completely different.

This looks really nice, but I think it will be hard to scale for larger binaries that contain significant amount of non-trivial algorithms (and not just copy-pasted stackoverflow answers). But this could still be useful the decompile individual functions / groups of functions.

One good application for this might be targets where there are no good existing decompilers for, such as some of the microconroller instruction sets. As long as you have a compiler for it (which you probably have if the architecture is used) this technique works. Also, code for microcontrollers is often unoptimized which should make the assembly prodiuced by the compiler more deterministic.

Docker is a nice runtime, but you cannot reproduce the build of a docker container. What if you want to make a small change to the image? You need to rebuild it, but if it's years later, the versions of packages in the ubuntu repository may have changed and a lot of other things (if you're not careful, tarballs downloaded during the building of the image may have disappeared/changed/...). While you can try to avoid these through careful scripting and pinning things, this is what Nix makes really easy: just pin your nixpkgs version, and you can almost guarrante that you'll get the exact same build years later and you can still change parts of it if you need to.

> I don't think that there are any theoretical concerns about the ability to write a correct borrow checker, just practical issues with the current implementation not correctly handling certain cases.

Is it really that trivial? When looking through https://github.com/rust-lang/rust/blob/master/src/librustc_b..., it is not at all clear that these rules cover everything to me. There are some complex side conditions, isn't it easy to miss something there?

Does this prove that the current borrowck rules are sufficient to catch all possible mistakes? For example, does it catch stuff like https://github.com/rust-lang/rust/issues/31287 or https://github.com/rust-lang/rust/issues/38899?

Note that only non-exported functions can be called directly. If you call a exported function, it has to go through the GOT to support redirection (LD_PRELOAD). There's a flag to disable that.

Wouldn't simply caching DNS SRV[1] records do that?

1: https://en.wikipedia.org/wiki/SRV_record

Yes, meltdown only works if the kernel is in the same address space. Also, the kernel maps the whole physical memory as part of its address space somewhere (kernel phyiscal map), so if you can read kernel memory, you can read all phyiscal memory.

And you are right, KPTI is a full fix for Meltdown (but not Spectre).

The problem is that it bypasses sandboxes and isolation features... normally, JavaScript running in a VM in a sandbox in your browser cannot read all of your memory. With meltdown, that could be possible. Although for that scenario, you need to combine Meltdown with Spectre variant 1, allowing you to read arbitrary kernel memory from JavaScript in a browser.

I don't get this. Is caddy so hard to build from source that you'd pay 10$ for a binary? The source code is ASL licensed so allows commercial use.

If you combine index masking with a branch that should still be Ok. For example, if you do `if(idx > arrayLength) return undefined else array[idx & mask]` then the CPU can only predict "return undefined" or "array[idx & mask]", none of which can cause any harm.

> non-turing-complete language like HTML

I would be careful about that: It wouldn't suprise me if HTML with CSS (at least with all the new things like animations) is turing complete (it probably is).

Why does a spam system delete packages that have already been in use for quite some time? I could understand if it blocked some newly updated ones, but it seems like it has deleted already existing packages that also were used by other packages?

Most package managers I know support Turing complete install hooks. How would a package manager detect what parts of those require/are safe to run with root?

Yes, but to do that, your code needs to use the same branch predictor as the victim code. If the branch prediction buffer is per-core and not shared among multiple cores, then that means you have to run on hte same core as the kernel. If the kernel always runs on a different core, you cannot do anything.

I like it, at least from the little that I read about it. The name describes the core of what it is: differentiate programs, in order to figure out how changes the the program affect the output and using that for optimization purposes. Do we really need to invent obscure, new names for everything just so that it sounds catchy?