[HN Gopher] Show HN: TinyClock - a tiny true 5-arch universal Ma...
___________________________________________________________________
Show HN: TinyClock - a tiny true 5-arch universal Mac OS X single-
binary GUI app
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.
Author : zeymejbdv
Score : 120 points
Date : 2022-09-07 17:25 UTC (5 hours ago)
(HTM) web link (tycho.sytes.net)
(TXT) w3m dump (tycho.sytes.net)
| tomcam wrote:
| 144K altogther. Delightful achievement! Most app icons are bigger
| than that nowadays.
| [deleted]
| donatj wrote:
| 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
| theg5prank wrote:
| 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.
| mikestew wrote:
| Same on 2019 Intel iMac running Monterey.
| dwighttk wrote:
| Huh... didn't realize OS X made it to Apple Silicon
| projektfu wrote:
| It's a Mac OS X program that runs on post-X macOS.
| donatj wrote:
| 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 wrote:
| 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...
| [deleted]
| johndoe0815 wrote:
| 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 wrote:
| 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 wrote:
| The Super Duper Universal Binary
|
| http://tenfourfox.blogspot.com/2020/06/the-super-duper-
| unive...
|
| Previous Hacker News discussion
|
| https://news.ycombinator.com/item?id=23754052
| [deleted]
| smilespray wrote:
| I want System 6 support for my SE/30 from 1989.
| ranger_danger wrote:
| Check out Retro68, I still write classic mac apps using this
| toolchain.
| tambourine_man wrote:
| >Launches faster, than Safari.
|
| As it should, since one is a clock, the other a web browser.
|
| Interesting stuff. Cross platform development is inspiring.
| mrozbarry wrote:
| I agree that a clock should absolutely open faster than a
| browser, but it would be good to know what this metric actually
| represents. I don't know much about this style of universal
| binaries, so I don't know if the binary being "true 5-arch
| universal binaries" is the focus of the application start time
| metric.
| kenferry wrote:
| Support for different architectures doesn't impact start time
| much. The code for the different archs is in different chunks
| of the file.
|
| Linking more libraries slows down launch due to
| initialization that happens to get the libraries ready to
| use. Besides that it's mostly what the app itself is doing on
| startup.
|
| So yes, beating Safari for a tiny app is... a good thing, but
| not very impressive.
| [deleted]
| WesolyKubeczek wrote:
| Safari "getting snappier" with every OS update is a running gag
| in at least the MacRumors community. Or has been for quite a
| while. Maybe it's retired now, much like the old gold "but will
| it run Crysis?" one.
|
| By now, Safari should be so snappy it opens your pages and have
| their document tree ready two seconds _before_ you think of
| doing it.
| creativenolo wrote:
| > 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 wrote:
| As it should, but not a given now that it's common for apps to
| bundle a whole browser as a runtime.
| ChrisMarshallNY wrote:
| 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 wrote:
| 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.
| dwighttk wrote:
| Can't remember the last time I thought about app launch speed
| outside of network access issues.
| Hamuko wrote:
| 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
| ralphc wrote:
| 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.
| digb wrote:
| What does 5-arch mean? Single Google yielded nothing (which may
| be more of a comment on Google's quality as of late)
| grishka wrote:
| 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 wrote:
| 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.)
| Applejinx wrote:
| It's a very impressive accomplishment. I support retro mac
| ppc/32/64, Windows 32 and 64, Linux on Intel and on Raspberry
| Pi, and signed mac Intel and Apple Silicon, for every (audio
| DSP, generic interface, mac AU and VST2.4) plugin I make.
| https://www.airwindows.com/
|
| But I do it with lots of different available downloads, not as
| a single binary. That's what I find impressive about this.
| Somebody's running that XCode mod where you can bring in all
| the libraries from all the previous versions back to the dawn
| of time. I'm not even going to pretend to try to keep something
| like that working: I do my retro builds (and original design)
| on an antique machine dedicated to the purpose, and the modern
| stuff on a modern laptop dedicated to staying current.
| olddustytrail wrote:
| It's not a common term. They're saying the exact same code will
| run successfully on 5 different CPU types (architectures).
|
| I'm reminded of the Feynman "why" video. The other answers are
| technically more accurate than mine, and even mine assumes you
| understand the concept of CPU types. It's difficult to pitch
| answers at the right level.
| skissane wrote:
| Imagine you translate a book into 5 different languages. Then
| bind the five translations into a single volume. At the
| front, you put a brief table of contents listing the page
| number at which each translation begins. Each reader opens
| the book, checks the table of contents, then jumps to the
| page containing the translation in their language. All
| readers are reading the same book, but each reads the
| translation in their language. Unless you don't know any of
| those five languages, in which case the book is unreadable
| for you.
|
| Technically more accurate and complete than your answer, but
| an analogy I expect most non-technical people could
| understand.
| [deleted]
| geraldcombs wrote:
| Mach-O[1], the executable file format used by macOS and iOS
| (and other NeXTSTEP descendants) supports stuffing code
| segments for multiple architectures in the same file, aka "fat
| binaries"[2]. This is a fat binary that supports 5
| architectures.
|
| [1]https://en.wikipedia.org/wiki/Mach-O
|
| [2]https://en.wikipedia.org/wiki/Fat_binary
| NegativeLatency wrote:
| 32/64 bit, PowerPC/x86/AppleSilicon
| Karellen wrote:
| Specifically, I'm guessing PPC-32, PPC-64, x86-32, x86-64 and
| ASi-64.
| sjtgraham wrote:
| *AArch64
| donatj wrote:
| > To obtain the full source tree do:
|
| > bzr clone 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]
| cglong wrote:
| 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 wrote:
| 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 wrote:
| 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 wrote:
| 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-14.1
|
| See also 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 wrote:
| 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.
| easrng wrote:
| You can git clone normal GitHub URLs without the .git at
| the end too.
| notamy wrote:
| Honestly, the most surprising thing to me was that people still
| use bzr. It looks like Canonical abandoned it back in 2016 [0].
| It seems like it was suceeded by breezy [1], at least.
|
| [0] https://en.wikipedia.org/wiki/GNU_Bazaar
|
| [2] https://github.com/breezy-team/breezy
| uticus wrote:
| The only (somewhat) newer code I've seen hosted is for
| Anduril (nerdy firmware for nerdy flashlights).
|
| https://news.ycombinator.com/item?id=25514288
|
| https://bazaar.launchpad.net/~toykeeper/flashlight-
| firmware/...
|
| https://ivanthinking.net/tags/anduril-ui/
|
| https://zeroair.org/2019/10/14/lumintop-fw1a-flashlight-
| revi...
|
| [edit] added HN link
| soxocx wrote:
| Same URL, different port. The website is at 80(http) or
| 443(https). Bzr seems to run on 4155.
| PainfullyNormal wrote:
| I successfully cloned the repo using breezy. Did I get punked?
| It's empty. > bzr log
| ------------------------------------------------------------
| revno: 1 committer: TinyClock
| <TinyClock@tycho.sytes.net> branch nick: TinyClock
| timestamp: Wed 2022-09-07 20:18:32 +0300 message:
| initial commit
| [deleted]
| fabrixxm wrote:
| > bzr clone https://tycho.sytes.net/TinyClock/ > cd
| TinyClock > bzr checkout > ls
| controller.h LICENSE Makefile view.h controller.m
| main.m README.md view.m
| PainfullyNormal wrote:
| Ah! thank you.
| projektfu wrote:
| The website is openbsd httpd serving the repository.
|
| https://tycho.sytes.net/TinyClock/README.md
|
| The Makefile creates index.html from README.md (and also
| TinyClock.dmg)
___________________________________________________________________
(page generated 2022-09-07 23:00 UTC)