[Toybox] [PATCH] macOS: target 10.15.

[enh]

On Fri, Jun 3, 2022 at 9:27 AM Rob Landley <rob at landley.net> wrote:

> On 6/2/22 19:41, enh wrote:
> > Oh, yeah, I think *especially* for macOS where pretty much everyone is
> always on
> > the latest version anyway, unless your Mac equivalent of the seven year
> rule is
> > "support the oldest macOS release that still gets security backports",
> there's
> > no reason to do this. It's pretty rare they add anything significant
> anyway.
>
> If you think the mac AOSP prebuilts should require the latest macos
> version to
> run, that's your call. I don't really have a MacOS policy because I'm not
> familiar enough with MacOS: they actively exclude any developer who
> doesn't pay
> to play. (And sadly Darwin died in 2006, although I'll blog about that
> rather
> than blathering here.)
>

sorry, i seem to have confused everyone here...

note that [unless we check in the "our official min is
$lowest_version_supported_by_apple" patch] anyone who builds toybox will
get a version that targets their builder's os version. so AOSP is actually
getting whatever it's running on, and someone with a 10.4 machine from 2005
would get 10.4. that was always true and hasn't changed.

what we've done [so far] is say "our CI is now testing the latest release
that github supports at any given time" [which, modulo a month or so, is
Apple's current release]. so our "even if we're not paying much attention,
github will tell us if we've screwed up" bar is set at "current". which i
think was all we were ever trying to do with github CI anyway --- "is it
broke?". (google's security policies also mean i can't really test on
anything older than "current" [modulo a month or so, like github].)

the change is that we used to _also_ ask github CI to test "oldest
still-supported macOS release". i still don't think we've ever heard from a
user who needs that, and i don't remember ever breaking one but not the
other [all the breakages i can remember have been solid "linux-isms" that
wouldn't work on any macOS release], so i don't think anything's changed in
practice.

i can upload a change that brings back 10.15 but installs gnu coreutils in
the docker image so we can still build ToT toybox. (because this time it
wasn't a source breakage, it was a build script breakage.) but -- until an
actual macOS < current user says "this affects me" -- i'm assuming we're
just burning carbon and helping no-one.


> The three macos use cases I have at the moment are "test on github", "ship
> AOSP
> prebuilt", and "random mac developer wants to use toybox", which all have
> slightly different requirements.
>

not really --- AOSP will always be "current [module a month or so]", but we
can make github match whatever "random mac developer"s tell us they need...
i'm just assuming until we hear otherwise that they're all running the
latest. (and, like i say, i'm usually the one holding the shitty end of the
stick when there are macOS libc changes, and i don't remember anything
interesting since clock_gettime(), so i think the _practical_ difference
right now [between the supported versions at least] is basically zero
anyway.)


> There was a tentative fourth use case: back before Apple switched from
> bash to
> zsh I thought they might eventually show an interest in a finished toysh,
> but
> they did bash->zsh the same way Ubuntu went bash->dash and Canonical
> showed a
> surprisingly adamant refusal to ever admit a mistake. So my previous
> "might"
> went from ~20% chance to like 5% tops. (And their "we don't understand what
> vfork was for" move abandons the embedded space too.)
>

don't forget "ps requires root" :-) i struggled to believe that one in
2005, let alone 2022!

*~$ *sw_vers

ProductName: macOS

ProductVersion: 12.4

BuildVersion: 21F79

*~$ *ls -l `which ps`

-rwsr-xr-x  1 root  wheel  203504 May  9 14:30 /bin/ps


> Rob
>
> P.S. The nommu stuff is about realtime response with long battery life:
> digital
> wristwatches could run for 5 years off the same battery because the chip
> inside
> was clocked at something like 32khz, not megahertz let along gigahertz.
> Sure die
> size shrinks help power/performance ratio but it's not linear (transistor
> leakage current etc get _worse_ at nanoscale), plus a 5nm chip produces
> microwatt signals that need a 45nm interface chip to translate them so it
> can
> talk to the outside world (and not get destroyed by the power surge when
> somebody opens the door and moves the air in the room), and for actual
> direct
> I/O (sensors doing analog/digital conversion or driving a small motor) you
> often
> want more like a 250 nanometer chip. So the "die shrinks will solve all
> this for
> us"... isn't true. Plus a 250 nanometer mask is what, $15k? The kind of
> thing
> you can amortize over a 30k unit production run no problem. A 5 nanometer
> mask
> isn't gonna cost less than $10 million any time soon, you've gotta make a
> LOT of
> the same chip for that to make economic sense. (The sky130 fab Google
> partnered
> with is actually a bit exotic, that's a "mixed signal" process doing a
> different
> resolution on each layer of the design, which makes routing extra-fun. Jeff
> Dionne is trying to do a j-core chip through that which can track GPS
> signals in
> a battery powered device, but it turns out their toolchain doesn't
> actually work
> and the first couple rounds of chips that went through the fab were all
> duds. He
> thinks he's fixed up most of it...)
>
> P.P.S. Here's a 2015 presentation about running nommu Linux on a chip with
> 256k
> of SRAM and no DRAM.
>
> https://elinux.org/images/9/90/Linux_for_Microcontrollers-_From_Marginal_to_Mainstream.pdf
> It's a pity the Linux Foundation accidentally deleted that year's ELC
> videos off
> of youtube, his talk was nice too. Anyway, the trick is trimming kernel
> data
> structures, XIP ROMFS so your binaries only need their .data and .bss
> segments
> in RAM, and nommu not wasting memory on page tables. No DRAM means no DRAM
> controller spending power on refresh cycles...
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.landley.net/pipermail/toybox-landley.net/attachments/20220603/c92536c2/attachment-0001.htm>