jacobvosmaer

Normal clones can reuse delta-compressed data the server stored on disk. Shallow clones impose a negative constraint: do not transfer data outside the requested commit depth. Pre-computed delta chains than contain unrequested data become unusable and the server must do delta compression on the fly to satsify the shallow clone.

The article does not talk about security problems. It's about whether your daemon works correctly.

1. Depending on the environment, process supervision can break if there is an unexpected process sitting between the supervisor and the supervisee. The article describes how the switch to PAM forced the introduction of an in-the-middle process responsible for closing the PAM session. The old su used exec, which avoids an in-the-middle process.

2. Su uses the shell of the target user, and will outright not work if the target user has a "nologin" shell.

The article goes on to mention correct workarounds for this like daemontools setuidguid, Runit chpst or just rolling your own exec wrapper.

I'm not sure. Intuitively I would think "phase angle" means "offset into the sine wave lookup table".

If you step through the lookup table with constant size steps, you would get a sine wave. If the steps are not constant size then you get a distorted sine wave. The "rate of change of the phase angle" would then be the step size.

Only original DX7's, or also the DX7ii?

Opening up the DX7ii (and other synths from the same time) is a pain compared to the nice hinge construction you get on the original DX7.

>not necessarily much safer than void*

You can cast void* to anything you want. With interface{} you get a type check, either through an assertion or a panic. That is a big difference in safety.

I think "everything is a file" also means: everything is addressable by a file path. Per-process namespaces are part of what makes this possible.

In a way it's similar to HTTP REST, which is also organized by file paths, except instead of the HTTP verbs GET, POST etc. you get open, read, write as your verbs.

A side channel is then just a directory entry.

Ubuntu 18.04 (Linux 4.15) in xhyve works fine for me. I tried to get 20.04 set up a while ago but I gave up because its installer kept flaking out on me, something about the disk if I remember correctly.

I wonder how this compares to xhyve, which I use on Intel Mac. It's nice to see something like it for ARM.

It appears xhyve is built on Hypervisor.framework while vftool is built on Virtualization.framework. Is that the main difference? What does that mean?

>The biggest issue with ractor support as it stands today would really be getting ALL the libraries any given app uses to support the ractor design.

I wonder if this will create a chicken-egg situation. Without significant Ractor adoption it will be hard to get libraries to adapt. Without essential pieces like Puma supporting (and benefiting from) Ractor there is less reason to for apps to use Ractor.

I am reminded of the difficulties faced by Rubinius, which if I understand correctly, was hampered by too many MRI-compatible libraries not working to get people to switch.

I think the issue is about having to cross a module boundary, which is really about monorepo vs multirepo. You have much more freedom to make breaking changes when you don't need to cross a (repo/module) boundary.

I think the Go module system encourages you to avoid adding unnecessary boundaries. As someone else pointed out already, one of the problems is that you don't find out that boundaries are bad until you hit v2, and then you discover that you have this chunk of technical debt (unnecessary repo boundaries that slow down development) that you didn't know about.