15 ms·

Show HN: TinyClock – a tiny true 5-arch universal Mac OS X single-binary GUI app

192 points by zeymejbdv 4y ago

1. Single universal binary, that can be natively executed on every hardware platform Mac OS X was made for (32/64 bit, PowerPC/x86/AppleSilicon). 2. Minimalistic gadget-style design. If launched as a tool, there is no menubar, no dock icon, no nothing, just the clock window. 3. Support for hidpi and dark mode for environments, that have them. 4. Window title bar for moving the window with a mouse, and a handle to resize it (latter for OS versions, that have it). 5. Can be easily ported to GNUStep and thus other OSes (sources under GPLv3). 6. Simple Makefile build system.

deleted 4y ago
[deleted]
johndoe0815 4y ago
Would it be possible to create a true universal binary that also runs on NeXT/Openstep on 68k, SPARC, PA-RISC and x86 as well as Rhapsody on PPC and x86?
- zeymejbdv 4y ago
  This requires some investigation. Technically, I believe it is possible if the following 2 conditions are met: 1. The Mach-O executable format was not changed between all those OS versions (likely). 2. It is possible to gather sub-binaries for one CPU type but different OS types (less likely). And SDK's and compillers (in emulator or on hardware) are required to try.
  - atommclain 4y ago
    The Super Duper Universal Binary http://tenfourfox.blogspot.com/2020/06/the-super-duper-universal-binary.html http://tenfourfox.blogspot.com/2020/06/the-super-duper-unive... Previous Hacker News discussion https://news.ycombinator.com/item?id=23754052 https://news.ycombinator.com/item?id=23754052
    - tomcam 4y ago
      > Apple already documents that you could have a five-way binary But enough about my private life. You're making us blush
  - saagarjha 4y ago
    1 is true, 2 is not.
  - deleted 4y ago
    [deleted]
  - johndoe0815 4y ago
    I had a closer look at the earliest available NeXTstep version (0.8) running in the previous emulator - I still need to refurbish the MO drive in my Cube to run it natively (I have a 68030 CPU board)... C and ObjC compilers (though the objc.exe (!) provided seems to be a source-to-source compiler) are included in the image available on winworldpc and I can compile the included demo source code. It seems that this early version is significantly different from later NeXTstep (3.3) and OpenStep versions. For example, it does not use app bundles. System apps installed in the /Apps folder, such as Terminal, are simple Mach-O executable m68k binaries. If we wanted to target such an early NeXTstep, in addition, the source code of TinyClock would have to be changed significantly. One problem is that early versions of AppKit used "NX" instead of "NS" prefixes. More difficult is that a number of classes used by TinyClock seem to be unimplemented - not even NSString (resp. NXString) seems to be available. More complex classes such as NSCalendarDate or NSBezierPath also seem to be a later addition (unless the 0.8 install image is missing some header files, the earliest documentation I could find was on 1.0). So it seems that a completely universal binary is out of the question, unfortunately.
- deleted 4y ago
  [deleted]
cglong 4y ago
OT, but as someone who's never used Bazaar, how does this work? bzr clone https://tycho.sytes.net/TinyClock/ EDIT: To clarify, I'm curious since this is the same URL I'm opening in my browser.
- dflock 4y ago
  Same as `git clone <repo>` - it downloads a local copy of the repo into a folder called ./TinyClock, which it will create if it doesn't exist.
  - unwind 4y ago
    One (IMO reasonable) objection/confusion might be that the the repo URL is the exact same as the web page, i.e. the actual posted article. When coming from git/Mercurial/subversion etc as I do, it is at least mildly weird that the Bazaar repo address is the same as the address of a web document. The two objects are not (at least in my world) the same, so why should they share URIs? Edit: deduped.
    - Karellen 4y ago
      Because sending different content based on the content-type the user-agent asks for, e.g. with the "Accept:" header, has explicitly been part of the HTTP spec since version 1.1 in 1997? https://datatracker.ietf.org/doc/html/rfc2068#section-12 https://datatracker.ietf.org/doc/html/rfc2068#section-12 https://datatracker.ietf.org/doc/html/rfc2068#section-14.1 https://datatracker.ietf.org/doc/html/rfc2068#section-14.1 See also https://developer.mozilla.org/en-US/docs/Web/HTTP/Content_negotiation https://developer.mozilla.org/en-US/docs/Web/HTTP/Content_ne... (FWIW - I don't know if that's how `bzr` does this, but it might, and the concept is 25 years old now.) Edit: s/different content/different representations of the same resource/
      - unwind 4y ago
        True of course, didn't think about that. I'm not a web developer. :) Still think it's weird and kind of against my feeling for the spirit of a URI, but that's just me. Thanks.
tambourine_man 4y ago
>Launches faster, than Safari. As it should, since one is a clock, the other a web browser. Interesting stuff. Cross platform development is inspiring.
- creativenolo 4y ago
  > As it should, since one is a clock, the other a web browser Yeah. Surely a better statistic to be had.here. System preferences?
- naniwaduni 4y ago
  As it should, but not a given now that it's common for apps to bundle a whole browser as a runtime.
  - ChrisMarshallNY 4y ago
    Not mine. I write native. I do tend to release apps in UIKit, so I don't quite achieve Buzzword Bingo, but I have always been a fan of native apps, and have watched the various efforts to avoid native, with the kind of sick fascination usually reserved for train wrecks.
    - klabb3 4y ago
      Do you rewrite your apps for other platforms? I don't think anyone avoids native, it's just that cross platform is a much more important goal for many.
      - ChrisMarshallNY 4y ago
        No. I don't write apps for other platforms. I am quite aware that it is not the ideal "business posture," but that's how I roll. I've been writing for Apple platforms, pretty much exclusively, since 1986.
- dwighttk 4y ago
  Can’t remember the last time I thought about app launch speed outside of network access issues.
digb 4y ago
What does 5-arch mean? Single Google yielded nothing (which may be more of a comment on Google's quality as of late)
- NegativeLatency 4y ago
  32/64 bit, PowerPC/x86/AppleSilicon
  - Karellen 4y ago
    Specifically, I'm guessing PPC-32, PPC-64, x86-32, x86-64 and ASi-64.
    - sjtgraham 4y ago
      *AArch64
- deleted 4y ago
  [deleted]
- grishka 4y ago
  This binary is so universal that `file` utility gets confused about it. $ file /Volumes/TinyClock/TinyClock.app/Contents/MacOS/TinyClock /Volumes/TinyClock/TinyClock.app/Contents/MacOS/TinyClock: Mach-O universal binary with 3 architectures: [i386:Mach-O executable i386 - Mach-O executable i386] [ppc:Mach-O executable ppc - Mach-O executable ppc] [arm64:Mach-O 64-bit executable arm64Mach-O 64-bit executable arm64] /Volumes/TinyClock/TinyClock.app/Contents/MacOS/TinyClock (for architecture i386): Mach-O executable i386 /Volumes/TinyClock/TinyClock.app/Contents/MacOS/TinyClock (for architecture ppc): Mach-O executable ppc /Volumes/TinyClock/TinyClock.app/Contents/MacOS/TinyClock (for architecture arm64): Mach-O 64-bit executable arm64
  - JonathonW 4y ago
    It's not confused; as noted in Known Bugs: > Unlike done in previous project, netop Tiger SDKs (used to build several intermediate binaries) don’t contain 64-bit AppKit versions, and thus ppc64 and x86_64 binaries are excluded from the binary release. The binary release is only three-architecture; it does not run on current Intel MacOS since it's missing an x86_64 segment. (You get a "this app needs to be updated" dialog if you try.)
tomcam 4y ago
144K altogther. Delightful achievement! Most app icons are bigger than that nowadays.
dwighttk 4y ago
Huh… didn’t realize OS X made it to Apple Silicon
- donatj 4y ago
  Hairsplitting. We all know there was nothing major in macOS 11 justifying it not being an X-os anymore. They just got tired of the naming scheme.
- hundchenkatze 4y ago
  Yep, since 2020 [0]. Or are you being pedantic about OS X vs macOS? [0] https://en.wikipedia.org/wiki/Apple_M1#Products_that_use_the_Apple_M1_series https://en.wikipedia.org/wiki/Apple_M1#Products_that_use_the...
- projektfu 4y ago
  It's a Mac OS X program that runs on post-X macOS.
smilespray 4y ago
I want System 6 support for my SE/30 from 1989.
- ranger_danger 4y ago
  Check out Retro68, I still write classic mac apps using this toolchain.
donatj 4y ago
> To obtain the full source tree do: > bzr clone https://tycho.sytes.net/TinyClock/ https://tycho.sytes.net/TinyClock/ I am surprised to find git not having built in support for cloning Bazaar repos. Almost as surprised as I am at finding a Bazaar repo in the wild.
- deleted 4y ago
  [deleted]
donatj 4y ago
Curiously it doesn't seem to run on my Intel Macbook running Big Sur - the icon is crossed out and I get > “TinyClock.app” needs to be updated. > The developer of this app needs to update it to work with this version of macOS. Contact the developer for more information. https://jdon.at/Uff03u https://jdon.at/Uff03u
- mikestew 4y ago
  Same on 2019 Intel iMac running Monterey.
- theg5prank 4y ago
  It only has i386, ppc, and arm64 slices. So, an Intel Mac running recent macOS won't be able to launch it as it does not have an x86_64 slice (32-bit x86 execution having been removed). Whether an app containing code for 3 architectures qualifies as "true 5-arch universal" is in the eye of the beholder I guess.
  - glhaynes 4y ago
    Interesting! I wonder why they didn't include x86_64. Doesn't seem likely to be problematic since it supports PPC64 and ARM64. Edit: answered my own question by reading the actual page — "Unlike done in previous project, netop Tiger SDKs (used to build several intermediate binaries) don’t contain 64-bit AppKit versions, and thus ppc64 and x86_64 binaries are excluded from the binary release."
  - Pulcinella 4y ago
    Seems like it’s literally not “5-arch” then. 32 bit PPC, 64 bit PPC, 32 bit X86, 64 bit ARM.
    - theg5prank 4y ago
      It actually doesn’t have ppc64 either. Just 3 slices.
  - zeymejbdv 4y ago
Hamuko 4y ago
A much more impressive universal macOS application in my mind is the X Lossless Decoder (XLD), which you can run natively on PowerPC (32), Intel (32/64) and ARM (64). Not only is it a great app if you need to rip CDs or transcode audio, but the fact that it still runs on every Mac architecture is rather impressive. https://tmkk.undo.jp/xld/index_e.html https://tmkk.undo.jp/xld/index_e.html
ralphc 4y ago
I happened to have my 12" PowerBook G4 out, I just installed Sorbet Leopard* on it. I downloaded TinyClock and it's working on it. *Sorbet Leopard is a modern update of Leopard, incorporating speedups from Tiger and the unreleased PPC Snow Leopard.
deleted 4y ago
[deleted]
0xbadcafebee 4y ago
If we had a Busybox for every platform, and you compiled your app for every platform, you could bundle it all as one compressed shell script. Not as cool as one binary that works everywhere, but much simpler. #!/usr/bin/env sh set -eu FILE="${OS:-$(uname -s)}/${ARCH:-$(uname -p)}/${MACH:-$(uname -m)}/exe" unzip -d "${TMPDIR:-/tmp}" -X -b -o "$0" "$FILE" [ $? -gt 1 ] || exec "${TMPDIR:-/tmp}/$FILE" echo "$0: Error: could not execute '$FILE'" ; exit 126 ######################################################## # After here the Zip file is concatenated into the file
- deleted 4y ago
  [deleted]
ranger_danger 4y ago
Doesn't work on 10.0: https://0x0.st/ofjW.png https://0x0.st/ofjW.png Not only does the binary not load, but the dmg itself won't extract, it just opens to a blank Disk Copy window no matter what you try to do. IMO CarbonLib is more impressive as you can target MacOS 8.1-9 as well as X (up until x86 support was dropped).
userbinator 4y ago
For a bit of comparison, Windows 2.03's (analog!) clock: CLOCK EXE 8960 9-04-87 11:11a ...will run on Windows 2.0 up to Windows 10 x86.
- anthk 4y ago
  OClock and "aclock" statically built can be run under older kernels up to today's distros. Oh, and it will run and render over the network with paleolitic Unixen thanks to X :).
  - frozenport 4y ago
    Yeah but doing a static build is probably hard because you need a static build against x?
    - monocasa 4y ago
      X's IPC is very stable (which is half the point of X); the instance on shared libraries has more to do with it being a memory hog on the kinds of systems that existed the first couple decades of it's life.
      - anthk 4y ago
        This. If you rum SIMH to emulate a Vax (and some other Unix), most Unix programs requiring X can be perfectly forwarded to use the host's X server. Or some Xephyr server.
        projektfu 4y ago
        I used to bring up openvms running Motif on a vax through xfree86.
    - anthk 4y ago
      X works seamlessly, it's a client/server arch. Even if you run emulators, by exporting $DISPLAY to your host (and by running xhost +$EMULATOR_IP) you can run, for example, tools for older Unixen. Except for SGI, but I am not that sure.
mlo06481 4y ago
Nice, thanks for sharing.

192 points by zeymejbdv 4y ago

deleted 4y ago

[deleted]

johndoe0815 4y ago

Would it be possible to create a true universal binary that also runs on NeXT/Openstep on 68k, SPARC, PA-RISC and x86 as well as Rhapsody on PPC and x86?

zeymejbdv 4y ago
This requires some investigation. Technically, I believe it is possible if the following 2 conditions are met: 1. The Mach-O executable format was not changed between all those OS versions (likely). 2. It is possible to gather sub-binaries for one CPU type but different OS types (less likely). And SDK's and compillers (in emulator or on hardware) are required to try.
- atommclain 4y ago
  The Super Duper Universal Binary http://tenfourfox.blogspot.com/2020/06/the-super-duper-universal-binary.html http://tenfourfox.blogspot.com/2020/06/the-super-duper-unive... Previous Hacker News discussion https://news.ycombinator.com/item?id=23754052 https://news.ycombinator.com/item?id=23754052
  - tomcam 4y ago
    > Apple already documents that you could have a five-way binary But enough about my private life. You're making us blush
- saagarjha 4y ago
  1 is true, 2 is not.
- deleted 4y ago
  [deleted]
- johndoe0815 4y ago
  I had a closer look at the earliest available NeXTstep version (0.8) running in the previous emulator - I still need to refurbish the MO drive in my Cube to run it natively (I have a 68030 CPU board)... C and ObjC compilers (though the objc.exe (!) provided seems to be a source-to-source compiler) are included in the image available on winworldpc and I can compile the included demo source code. It seems that this early version is significantly different from later NeXTstep (3.3) and OpenStep versions. For example, it does not use app bundles. System apps installed in the /Apps folder, such as Terminal, are simple Mach-O executable m68k binaries. If we wanted to target such an early NeXTstep, in addition, the source code of TinyClock would have to be changed significantly. One problem is that early versions of AppKit used "NX" instead of "NS" prefixes. More difficult is that a number of classes used by TinyClock seem to be unimplemented - not even NSString (resp. NXString) seems to be available. More complex classes such as NSCalendarDate or NSBezierPath also seem to be a later addition (unless the 0.8 install image is missing some header files, the earliest documentation I could find was on 1.0). So it seems that a completely universal binary is out of the question, unfortunately.
deleted 4y ago
[deleted]

cglong 4y ago

OT, but as someone who's never used Bazaar, how does this work? bzr clone https://tycho.sytes.net/TinyClock/ EDIT: To clarify, I'm curious since this is the same URL I'm opening in my browser.

dflock 4y ago
Same as `git clone <repo>` - it downloads a local copy of the repo into a folder called ./TinyClock, which it will create if it doesn't exist.
- unwind 4y ago
  One (IMO reasonable) objection/confusion might be that the the repo URL is the exact same as the web page, i.e. the actual posted article. When coming from git/Mercurial/subversion etc as I do, it is at least mildly weird that the Bazaar repo address is the same as the address of a web document. The two objects are not (at least in my world) the same, so why should they share URIs? Edit: deduped.
  - Karellen 4y ago
    Because sending different content based on the content-type the user-agent asks for, e.g. with the "Accept:" header, has explicitly been part of the HTTP spec since version 1.1 in 1997? https://datatracker.ietf.org/doc/html/rfc2068#section-12 https://datatracker.ietf.org/doc/html/rfc2068#section-12 https://datatracker.ietf.org/doc/html/rfc2068#section-14.1 https://datatracker.ietf.org/doc/html/rfc2068#section-14.1 See also https://developer.mozilla.org/en-US/docs/Web/HTTP/Content_negotiation https://developer.mozilla.org/en-US/docs/Web/HTTP/Content_ne... (FWIW - I don't know if that's how `bzr` does this, but it might, and the concept is 25 years old now.) Edit: s/different content/different representations of the same resource/
    - unwind 4y ago
      True of course, didn't think about that. I'm not a web developer. :) Still think it's weird and kind of against my feeling for the spirit of a URI, but that's just me. Thanks.

tambourine_man 4y ago

>Launches faster, than Safari. As it should, since one is a clock, the other a web browser. Interesting stuff. Cross platform development is inspiring.

creativenolo 4y ago
> As it should, since one is a clock, the other a web browser Yeah. Surely a better statistic to be had.here. System preferences?
naniwaduni 4y ago
As it should, but not a given now that it's common for apps to bundle a whole browser as a runtime.
- ChrisMarshallNY 4y ago
  Not mine. I write native. I do tend to release apps in UIKit, so I don't quite achieve Buzzword Bingo, but I have always been a fan of native apps, and have watched the various efforts to avoid native, with the kind of sick fascination usually reserved for train wrecks.
  - klabb3 4y ago
    Do you rewrite your apps for other platforms? I don't think anyone avoids native, it's just that cross platform is a much more important goal for many.
    - ChrisMarshallNY 4y ago
      No. I don't write apps for other platforms. I am quite aware that it is not the ideal "business posture," but that's how I roll. I've been writing for Apple platforms, pretty much exclusively, since 1986.
dwighttk 4y ago
Can’t remember the last time I thought about app launch speed outside of network access issues.

digb 4y ago

What does 5-arch mean? Single Google yielded nothing (which may be more of a comment on Google's quality as of late)

NegativeLatency 4y ago
32/64 bit, PowerPC/x86/AppleSilicon
- Karellen 4y ago
  Specifically, I'm guessing PPC-32, PPC-64, x86-32, x86-64 and ASi-64.
  - sjtgraham 4y ago
    *AArch64
deleted 4y ago
[deleted]
grishka 4y ago
This binary is so universal that `file` utility gets confused about it. $ file /Volumes/TinyClock/TinyClock.app/Contents/MacOS/TinyClock /Volumes/TinyClock/TinyClock.app/Contents/MacOS/TinyClock: Mach-O universal binary with 3 architectures: [i386:Mach-O executable i386 - Mach-O executable i386] [ppc:Mach-O executable ppc - Mach-O executable ppc] [arm64:Mach-O 64-bit executable arm64Mach-O 64-bit executable arm64] /Volumes/TinyClock/TinyClock.app/Contents/MacOS/TinyClock (for architecture i386): Mach-O executable i386 /Volumes/TinyClock/TinyClock.app/Contents/MacOS/TinyClock (for architecture ppc): Mach-O executable ppc /Volumes/TinyClock/TinyClock.app/Contents/MacOS/TinyClock (for architecture arm64): Mach-O 64-bit executable arm64
- JonathonW 4y ago
  It's not confused; as noted in Known Bugs: > Unlike done in previous project, netop Tiger SDKs (used to build several intermediate binaries) don’t contain 64-bit AppKit versions, and thus ppc64 and x86_64 binaries are excluded from the binary release. The binary release is only three-architecture; it does not run on current Intel MacOS since it's missing an x86_64 segment. (You get a "this app needs to be updated" dialog if you try.)

tomcam 4y ago

144K altogther. Delightful achievement! Most app icons are bigger than that nowadays.

dwighttk 4y ago

Huh… didn’t realize OS X made it to Apple Silicon

donatj 4y ago
Hairsplitting. We all know there was nothing major in macOS 11 justifying it not being an X-os anymore. They just got tired of the naming scheme.
hundchenkatze 4y ago
Yep, since 2020 [0]. Or are you being pedantic about OS X vs macOS? [0] https://en.wikipedia.org/wiki/Apple_M1#Products_that_use_the_Apple_M1_series https://en.wikipedia.org/wiki/Apple_M1#Products_that_use_the...
projektfu 4y ago
It's a Mac OS X program that runs on post-X macOS.

smilespray 4y ago

I want System 6 support for my SE/30 from 1989.

ranger_danger 4y ago
Check out Retro68, I still write classic mac apps using this toolchain.

donatj 4y ago

> To obtain the full source tree do: > bzr clone https://tycho.sytes.net/TinyClock/ https://tycho.sytes.net/TinyClock/ I am surprised to find git not having built in support for cloning Bazaar repos. Almost as surprised as I am at finding a Bazaar repo in the wild.

deleted 4y ago
[deleted]

donatj 4y ago

Curiously it doesn't seem to run on my Intel Macbook running Big Sur - the icon is crossed out and I get > “TinyClock.app” needs to be updated. > The developer of this app needs to update it to work with this version of macOS. Contact the developer for more information. https://jdon.at/Uff03u https://jdon.at/Uff03u

mikestew 4y ago
Same on 2019 Intel iMac running Monterey.
theg5prank 4y ago
It only has i386, ppc, and arm64 slices. So, an Intel Mac running recent macOS won't be able to launch it as it does not have an x86_64 slice (32-bit x86 execution having been removed). Whether an app containing code for 3 architectures qualifies as "true 5-arch universal" is in the eye of the beholder I guess.
- glhaynes 4y ago
  Interesting! I wonder why they didn't include x86_64. Doesn't seem likely to be problematic since it supports PPC64 and ARM64. Edit: answered my own question by reading the actual page — "Unlike done in previous project, netop Tiger SDKs (used to build several intermediate binaries) don’t contain 64-bit AppKit versions, and thus ppc64 and x86_64 binaries are excluded from the binary release."
- Pulcinella 4y ago
  Seems like it’s literally not “5-arch” then. 32 bit PPC, 64 bit PPC, 32 bit X86, 64 bit ARM.
  - theg5prank 4y ago
    It actually doesn’t have ppc64 either. Just 3 slices.
- zeymejbdv 4y ago

Hamuko 4y ago

A much more impressive universal macOS application in my mind is the X Lossless Decoder (XLD), which you can run natively on PowerPC (32), Intel (32/64) and ARM (64). Not only is it a great app if you need to rip CDs or transcode audio, but the fact that it still runs on every Mac architecture is rather impressive. https://tmkk.undo.jp/xld/index_e.html https://tmkk.undo.jp/xld/index_e.html

ralphc 4y ago

I happened to have my 12" PowerBook G4 out, I just installed Sorbet Leopard* on it. I downloaded TinyClock and it's working on it. *Sorbet Leopard is a modern update of Leopard, incorporating speedups from Tiger and the unreleased PPC Snow Leopard.

deleted 4y ago

[deleted]

0xbadcafebee 4y ago

If we had a Busybox for every platform, and you compiled your app for every platform, you could bundle it all as one compressed shell script. Not as cool as one binary that works everywhere, but much simpler. #!/usr/bin/env sh set -eu FILE="${OS:-$(uname -s)}/${ARCH:-$(uname -p)}/${MACH:-$(uname -m)}/exe" unzip -d "${TMPDIR:-/tmp}" -X -b -o "$0" "$FILE" [ $? -gt 1 ] || exec "${TMPDIR:-/tmp}/$FILE" echo "$0: Error: could not execute '$FILE'" ; exit 126 ######################################################## # After here the Zip file is concatenated into the file

deleted 4y ago
[deleted]

ranger_danger 4y ago

Doesn't work on 10.0: https://0x0.st/ofjW.png https://0x0.st/ofjW.png Not only does the binary not load, but the dmg itself won't extract, it just opens to a blank Disk Copy window no matter what you try to do. IMO CarbonLib is more impressive as you can target MacOS 8.1-9 as well as X (up until x86 support was dropped).

userbinator 4y ago

For a bit of comparison, Windows 2.03's (analog!) clock: CLOCK EXE 8960 9-04-87 11:11a ...will run on Windows 2.0 up to Windows 10 x86.

anthk 4y ago
OClock and "aclock" statically built can be run under older kernels up to today's distros. Oh, and it will run and render over the network with paleolitic Unixen thanks to X :).
- frozenport 4y ago
  Yeah but doing a static build is probably hard because you need a static build against x?
  - monocasa 4y ago
    X's IPC is very stable (which is half the point of X); the instance on shared libraries has more to do with it being a memory hog on the kinds of systems that existed the first couple decades of it's life.
    - anthk 4y ago
      This. If you rum SIMH to emulate a Vax (and some other Unix), most Unix programs requiring X can be perfectly forwarded to use the host's X server. Or some Xephyr server.
      - projektfu 4y ago
        I used to bring up openvms running Motif on a vax through xfree86.
  - anthk 4y ago
    X works seamlessly, it's a client/server arch. Even if you run emulators, by exporting $DISPLAY to your host (and by running xhost +$EMULATOR_IP) you can run, for example, tools for older Unixen. Except for SGI, but I am not that sure.

mlo06481 4y ago

Nice, thanks for sharing.