blink VS XQuartz

> Consider offering APE for x64 but then still producing ARM binaries the old fashioned way.

The recent version of cosmopolitan generates ARM binaries for Linux and MacOS (https://github.com/jart/cosmopolitan#arm; mode aarch64). There is also blink that provides the x86-64 emulation layer for (APE and other) binaries on a variety of platforms (https://github.com/jart/blink).

Would love a second pair of eyes on the powerpc64le JIT, since it partially works but hangs on some tests. https://github.com/jart/blink/issues/17

I've never used it, but https://github.com/jart/blink is pretty much that. It's tiny and:

> We regularly test that Blink is able run x86-64-linux binaries on the following platforms:

> Linux (x86, ARM, RISC-V, MIPS, PowerPC, s390x)

> macOS (x86, ARM)

> FreeBSD

> OpenBSD

> Cygwin

I wonder if blink could be used as a lightweight sandbox. Looking at PR46[0], it seems sandboxing is not one of the current features, but it would be cool to have a way to run arbitrary code (e.g: Python) in a sandboxed environment. Even cooler if you could limit the amount of memory/CPU used.

[0]: https://github.com/jart/blink/pull/46#pullrequestreview-1264...

https://github.com/jart/blink/issues/8 Porting to webassembly

brew install --cask xquartz

Or install from the project homepage [1]. Then just launch the X11 app. Note that it does require the application to be built for Mac - it’s not an emulator, just an implementation of the X11 APIs.

[1] https://www.xquartz.org/

I’ve recently spent some time working with terminal emulators in raw mode on macOS. While I chose to handle key events using escape codes, and found it seriously difficult (even gave up) to process the shift modifier key. However, I came across xquartz [1], which seems to do similar things as mentioned in the article. Would detecting shift key state have been trivial using such a library?

[1] https://github.com/XQuartz/XQuartz

The contents are rendered through gtk/cairo which not only goes through https://www.xquartz.org/ but also doesn't use GPU rendering (it was experimental 3 years ago, maybe better now). The main issue seems to be that neither Inkscape nor gtk people have much low level Darwin experts or time available to invest in debugging the whole rendering stack. See for example https://gitlab.com/inkscape/inkscape/-/issues/1614 and all the other referenced issues for all the gory details.

I live in a mezzanine studio using a M1 macbook for a workstation (writing/editing) and my old laptop with openbsd as a local server. I play music from that obsd server upstairs, which thus fills the whole room down to my desktop through the plugged-in speakers. My hosted library plays fine with mpd and ncmpcpp, and I just figured out it's not so difficult to use mpv to play streamed youtube videos, since firefox in XQuartz streaming from xenocara is way too slow anyhow.

There is an alternative: I ended up using Xquartz to give me an X11 environment and then running StumpWM as my tiling window manager. I used this for all my productive stuff, running full screen in MacOS, then a quick keypress got me back to the Mac environment.

I also used Xquartz. Emacs was better for me though because capturing text output and documenting what I captured was so much easier than X-window.

Link

I used a Mac for router software testing for over 20 years. I ran a shell on my mac either through Emacs (on occasion) or X-quartz with terminal connections to a dozen or more routers, linux and or Windows systems. In all that time, I opened the terminal on my mac maybe 5 times.