Readit News logoReadit News
jacobvosmaer commented on My Ed(1) Toolbox   aartaka.me/my-ed.html... · Posted by u/mooreds
jacobvosmaer · 6 months ago
I like ed but I prefer 'sam -d' (the terminal mode of Sam). It has a nice looping construct 'x' and you can open multiple files and do batch edits (with 'X').

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/

jacobvosmaer commented on Casio VZ-1 Algorithms   blog.jacobvosmaer.nl/0029... · Posted by u/todsacerdoti
boffinAudio · 2 years ago
Disclaimer: I make electronic musical instruments and audio gear, some of which you may have right in front of you right now, and have a strong opinion on the subject based on decades of interacting with engineers, designers, and most importantly of all: end users.

>Casio made such a confusing mess of things with the always-on exciters, the exciter conduits and the wave shapers whose frequencies can be edited in the UI but not in the engine. It is almost a case study in what goes wrong when you lie to the user about what goes on inside the machine. Lying is a harsh word to use but when "disable" does not mean disable then I don't know what else to call that.

Other manufacturers such as Yamaha are guilty of the same kind of interface obfuscation - they have a wonderful engine, but a terrible user interface, and their development teams never get the budget they need to make the user interface problem as viable as it needs to be. You can see this in many of their products - one of the most infamous being the FS1R, which has unaccessible yet amazing features if you can pry under the hood and play with them.

Too often, the UI is bolted on at the end of the project and not considered important - or, indeed, used to cover up failings of the underlying engine architecture. Another fantastic example was the Hartmann Neuron, which was an extraordinarily powerful synthesizer engine with an interface designed by one of the industry's worst violators of user intelligence, simply to 'cover up' how the algorithm worked - because, in the designers words, "musicians don't care how it works, they just want to play". This is why the machines don't sell, people: you insult the user intelligence when you just throw knobs and menus at the problem and call it a day.

And this statement is used throughout the industry to justify half-assed, lame attempts at UI. Most of the synthesizers on the market today have UI's which are very little more than a washing machine interface, applied to sound.

A big part of the problem is that the UI is considered a section of the entire BOM where savings can be made - a cheap LCD interface instead of an OLED, "should suffice, since musicians don't care about how things are generated, they just want to play".

There are companies out there that recognize this issue with the market, such as 1010music and others. However, it is still a major problem - too often, menu diving is considered the "only way" to represent all of the parameters, without doing something truly innovative, such as actually investing in a ground-breaking interface paradigm. And, those that attempt such paradigm leaps, are too often managed into the ground by managers, whose lives as failed rock stars precludes any sensibilities that would allow them to shave margins sufficient to the task of boosting the parts budget.

It is a long-term problem. The VZ1, from 1988, is but one example of many, many products in this market segment with absolutely dreadful user interfaces. The market is ripe for a truly innovative design team to come along and fix it - just as long as they stay away from the mind-melting idiocy of the management class which currently rules the musical instrument industry.

jacobvosmaer · 2 years ago
> Other manufacturers such as Yamaha are guilty of the same kind of interface obfuscation

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

jacobvosmaer commented on Mk: A Successor to Make (1987) [pdf]   doc.cat-v.org/bell_labs/m... · Posted by u/SllX
vmsp · 3 years ago
For those curious, Mk is available in Plan 9 from User Space

https://9fans.github.io/plan9port/

jacobvosmaer · 3 years ago
I tried plan9port's mk for a moment out of curiosity. I quickly ran into an annoying usability problem: it compares file mtimes with second accuracy.

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.

jacobvosmaer commented on Don't abuse su for dropping user privileges (2015)   jdebp.uk/FGA/dont-abuse-s... · Posted by u/aargh_aargh
RjQoLCOSwiIKfpm · 3 years ago
The article seems quite unclear about potential consequences of using su this way.

I typically use su to run some program in its own user account to ensure:

- it has its own homedir and doesn't fill mine with garbage.

- there is some level of isolation from the rest of the system for security, a basic "jail". I'm not trying to protect against targeted attacks from extremely competent threat actors here, but rather trying to stick software into its own user account so it can only access that account, with isolation of the same level as if I had manually logged in to a secondary account.

Can such programs break out of their "jail" when using su?

Or is the author of the article just angry for other reasons?

jacobvosmaer · 3 years ago
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.

jacobvosmaer commented on Yamaha DX7 Technical Analysis   ajxs.me/blog/Yamaha_DX7_T... · Posted by u/jacquesm
rcxdude · 4 years ago
"rate of change of the phase angle" is just a convoluted way of saying 'frequency'
jacobvosmaer · 4 years ago
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.

jacobvosmaer commented on Yamaha DX7 Technical Analysis   ajxs.me/blog/Yamaha_DX7_T... · Posted by u/jacquesm
jacquesm · 4 years ago
I repair them to keep them in play, impossible to get some of the parts so I tend to use one that is too far gone to repair a number (usually three or so) of others and then I still end up with some more spares that might come in handy later.

They are incredibly durable, one that I got had been in a fire but it still worked, even though more than half of the keyboard had been burned off. The mainboard went on to repair one that was otherwise good but had a fried CPU. Another one I got had been owned by a touring musician, who apparently didn't know about flight cases :) There wasn't a lick of paint on the outer case. I got it for free because it wouldn't turn on any more. Turned out that the voltage selector had somehow been moved in transport and got stuck between the two settings, leaving it disconnected. That was the fastest fix ever, there simply wasn't anything wrong with it. (And good thing that voltage selector had not been pushed a tiny little bit further because then it would have been end-of-story for sure).

So, I have a pretty large collection of spares, looms, main boards, display boards, keys (they do break, especially as the plastic ages it can get more brittle, more so in synths that have been in the sun), switches, PSUs and so on. Every now and then I put an ad out to get people to sell me their broken ones or to help them out and then a new batch of working DX-7's goes back into the world. It's never going to make me a dime, especially not when counting the time but it feels pretty good to keep these oldies alive, and to see how happy musicians are when their baby works again.

jacobvosmaer · 4 years ago
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.

jacobvosmaer commented on Generics enabled by default in Go tip   go-review.googlesource.co... · Posted by u/dcu
xh-dude · 5 years ago
Parametric polymorphism is a better fit for container types IMHO. There are some interesting notes here…

In Go prior to generics, interface{} is an escape hatch less frequently needed but not necessarily much safer than void*. Post generics, interface{} is suddenly more useful and will be aliased by ‘any’.

The way the std lib heap works in Go, an implementation doesn’t have to mention interface{}. Using the Go std lib solution is about satisfying a few interfaces, defining some methods for sorting and swapping over the element type. The use of interface{} is internal.

Go’s generics solution is going to have type constraints, which I think will be very familiar to some and probably new to others … So, the Go generics PQ should still require some constraints on elements, not ’any’thing will work. I’ve really enjoyed constraints in languages and it’s not quite natural in C++/Java, but Go’s interfaces already do some ‘constraint’ work conceptually and can be used as constraints in Go’s generics syntax. I’m interested to see how this plays out.

jacobvosmaer · 5 years ago
>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.

jacobvosmaer commented on Plan 9 from Bell Labs in Cyberspace   bell-labs.com/institute/b... · Posted by u/__d
MyrtleTook · 5 years ago
I don't understand how the "everything is a file" could apply for everything in practice. For example, Linux has ioctl(), which in practice are like a side channel. Granted, Linux doesn't apply this API philosophy too thoroughly.

I guess the "everything is a file" might have multiple meanings. For example:

(1) Everything is represented by a (file) descriptor

(2) Same as (1) and the descriptor has a file-like API (think read(), seek(), write(), etc.)

(3) Everything is an "byte addressable blob of bytes"

Meaning (1) is OK. But it doesn't tell nothing about the API the (file) descriptor itself would use. It could be a fixed set (like meaning (2)), or be variable depending on something else (like the (file) descriptor type).

Meaning (2) looks like too restrictive and inefficient to me and is the one I really have trouble accepting as a general OS primitive.

Meaning (3) surely can't be used for everything in practice, right? It's just to generic like "every computer architecture can be emulated by a universal turing machine." And it also seems too inefficient. But it could be very useful if the blob of bytes had an API like (2) or any other, including having an API depending of the "file type".

Is option (3) that folks are meaning when talking about "everything is/should be a file"?

EDIT: formatted the meaning list correctly.

jacobvosmaer · 5 years ago
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.

jacobvosmaer commented on Vftool runs Linux virtual machines in macOS Big Sur   github.com/evansm7/vftool... · Posted by u/syrusakbary
jacobvosmaer · 5 years ago
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.
jacobvosmaer · 5 years ago
Thanks to another commenter I found https://github.com/evansm7/vftool/issues/2#issuecomment-7354... which is exactly what I needed for Ubuntu 20.04: the idea to use cloud images which bypasses the silly installer.
jacobvosmaer commented on Vftool runs Linux virtual machines in macOS Big Sur   github.com/evansm7/vftool... · Posted by u/syrusakbary
wiredfool · 5 years ago
I’m using xhyve as well, but I’m having trouble getting it to boot newer kernels. 4.4 era works, (16.04) but 18.04 and 20.04 have various failures. I note that docker is built on xhyve and doesn’t seem to have this issue. So it’s not fundamental, but the fix hasn’t made it back to thx mostly abandoned xhyve.
jacobvosmaer · 5 years ago
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.

u/jacobvosmaer

KarmaCake day73July 1, 2013View Original