jacobvosmaer's comments

There is a Go port of Sam, which is easy to install:

go install 9fans.net/go/cmd/sam@latest

http://sam.cat-v.org/

Everybody agrees the FS1R is a confusing mess although there too I think it's not just the interface but it goes deeper down to them not knowing enough themselves about what can be done with the capabilities of the engine.

In defense of Yamaha, if you read that retrospective I linked in the post [1], you do see that they spent years whittling down their engine to arrive at the DX7 and I think it shows. They did not spend that kind of effort on the FS1R nor did Casio on the VZ-1.

[1]: https://web.archive.org/web/20150912075333/http://usa.yamaha...

https://github.com/9fans/plan9port/blob/cc4571fec67407652b03...

With sub-second build times for individual targets, this causes mk to needlessly recompile files because the target may have the same mtime as the prerequisites.

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.

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.

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.

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.

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.

https://developer.apple.com/documentation/hypervisor?languag...

Looks like Virtualization.framework is newer (Big Sur only) and uses Objective C classes rather than C functions.

I know from the xhyve README that it contains code responsible for booting a Linux kernel, which suggests Hypervisor.framework does not take care of that for you. The Virtualization.framework API on the other hand takes a linux kernel + ramdisk as its inputs.

So it sounds like the framework vftool is built on is more high-level than that of xhyve, and like vftool is Linux-only.

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

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 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.

I get it to compile on macOS if I remove the int define but then it segfaults when you run it. I wonder if there is some magic flag to make "main does not return int" a non-fatal error on Clang?

It's fun to read this code but running it is even more fun, you can see the VM code it generates, with source line annotations and all.

You don't need to solder, the connectors are on a user-replaceable daughter board.

Or perhaps it's about avoiding allocations?

Caching proxies for zip downloads sounds nice, but it's more than just "a bit more infrastructure". I think it would be a huge burden to package publishers if each of them has to manage their own dependency zip mirror as a separate piece of infrastructure. You need version control anyway; checking your dependencies into that same version control does not require a new piece of infrastructure.

Coming from Ruby, where rubygems.org is a very painful point of failure, in my eyes the fact that Go dependencies are not a separate download is a big plus.

In fact without a single blessed dependency repository such as rubygems.org, in the Go case you have as many points of failure at build time as there are different code hosting sites in your dependency graph.