About

"The program should, in some way, expand the concept of what computer paint programs are, as well as what mark making can be."

Recent posts

Omar Rizwan @omar

neither macOS nor Linux feels much like "Unix" when you do non-1970s stuff (graphics, webcam, low-overhead profiling, introspection, some networking, IPC and weird MMU stuff, low-overhead polling/IO/subscriptions)

but Linux at least tries with /proc and /dev/videoX and new file descriptors like userfaultfd and pidfd and so on (and fork(2) still kinda works). macOS really makes no attempt to be Unix-like in comparison https://social.omar.website/@omar/statuses/01HWGZM1ACNS48HEQMFBCW0VAY

Open thread

Omar Rizwan @omar

hmmmm https://gist.github.com/bellbind/6954679

Open thread

Omar Rizwan @omar

the late nineteenth and early twentieth centuries. Bagels existed in America for decades as a purely
ethnic phenomenon, virtually unknown to society at large. (Though today this seems almost impossible
to believe, as late as 1957 the writer of a New York Times news story felt obliged to inform the paper's
readers that "A bagel is a kind of hard roll with a hole in the center.")

Open thread

Omar Rizwan @omar

execvpe

Open thread

Omar Rizwan @omar

Odd

Notice that what is relevant is the exact path string passed to dlopen. So if you use "./foo.so" and "././foo.so" (or "../foosymlink.so" where foosymlink.so is a symlink to foo.so) the dlopen-ed handles are different, and in some cases weird behavior of the two instances of that shared library might happen.

Open thread

Omar Rizwan @omar

Inpatient Press is an independent publisher based in New York that champions work which extends the imaginative plane. Suffice to say, *we publish what others do not.*

Open thread

Omar Rizwan @omar

"Pi My Life Up"

Open thread

Omar Rizwan @omar

install package -> hack on package

I think I have run into 2+ different issues where the Linux sampling profiler `perf` literally does not work out of the box and I have to clone the kernel source code and compile it myself

i feel like packages just don't work a lot of the time when I try them and I end up having to unzip and compile them myself & even patch the source code, so it's very annoying when there's too steep a slope between 'install package' and 'hack on package'

Open thread

Omar Rizwan @omar

"Please remember that the kernel is for running userspace" https://lwn.net/Articles/803421/

screenshot of first 2 sections of linked LWN article "We've been through a lot of tracing tools and frameworks both for generating/annotating traceable data and for collecting/processing it. uprobes, ftrace, dtrace-for-linux, SystemTap, linux-perf and perf_events, LTTng, and more. They're inter-related and not a simple generational series of changes. But one pattern seems to have persisted pretty strongly: nothing works very well with "real world" production userspace deployments initially, yet earlier generations of tools tend to be abandoned. If you go to use one tool you're told it's obsolete, you should use the new one instead, but that one doesn't actually work on any of the systems widely deployed in production and won't for a long time yet. When it does, it probably doesn't support external debuginfo (like every system has had for 10+ years) for another year or two after that, because really, who debugs packaged binaries on production systems?"

Open thread

Omar Rizwan @omar

finally learning about `perf probe` -- https://bristot.me/using-perf-probe-to-measure-execution-time-of-user-space-code-on-linux/ -- think I want to add a hook to scripting language so I can inject probes at script level. might just JIT & call a stub C function with unique name and then probe that

Open thread