91 karma · joined July 1, 2013
There is a Go port of Sam, which is easy to install:
go install 9fans.net/go/cmd/sam@latest
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.
As zegerjan wrote, Gitaly is a Go/Ruby hybrid.
The main Go process doesn't use libgit2 (for now) because we didn't want to have to deal with cgo. We already know how to deal with C extensions in Ruby, and we have a lot of existing Ruby application code that uses libgit2, so we still use it there. And that code works fine so I don't see us removing it.
In practice, sometimes spawning a Git process is faster than using libgit2, so why then not do that. Also for parts of our workload (handling Git push/pull operations), spawning a one-off process (git-upload-pack) is the most boring / tried-and-true approach.
I agree it's not very prominent. (GitLab Inc. developer)
The way GitLab is organized (pre-Gitaly) makes it very hard to do things like that. Roughly speaking, when handling a push, it is a coordinated dance between GitLab components to make sure it all goes in, but none of these components has full control over the push from start to finish. One of the reasons we are creating Gitaly is to create a 'place' (namely Gitaly) where we _can_ exercise such control.
The other big reason for building it is not having to use Git repos on NFS.
(Gitaly maintainer)
Wrapping text: I used fmt all the time. But you can't pipe text straight through fmt, so I ended up doing this a lot:
3w |fmt>fmt # create a file called fmd in cwd
3r fmt
3d
Which is OK if you have just one line to wrap. If there are newlines in the text you're wrapping, you have to remember the line numbers of the unwrapped text (or use ka, kb) to delete them.
Inserting text in the middle of a line. Either use s// (which is annoying if your inserted text has a lot of slashes) or split the line, add an in between line with the new text, and join.
s/split text/split text\ # <- backslack escapes newline
Then use a or i to insert a line. Then join three lines with j. It gets old after a while.
And then there was my false hope that I learned a universal editor that was everywhere. Except GNU ed is not BSD ed is not OpenBSD ed is not Solaris ed.
Anyhoo, would be fun to read how someone who stuck with it (unlike myself) uses ed.
And then it turned out that a lot of the platforms people run the scripts on, they had to install ed explicitly! Ha. Sorry, Arch/Debian/Fedora/Centos/OpenSUSE users.
If you don't believe me, look how many times 'ed' is installed on this page. :) https://gitlab.com/gitlab-org/gitlab-development-kit/blob/ma...
doas: syntax error at line 1
The word 'persist' does not occur in 'man doas.conf', so maybe this feature is so new it is not in OpenBSD 6.0? Watch out before you try it out yourself.
https://github.com/git/git/blob/56f37fda511e1615dc6df86c68f3...
The question is then: how badly do people want this and how many admins out there are willing to poke an extra hole in their firewall just for this protocol.