<div dir="ltr"><div dir="ltr"><br></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Fri, Jun 3, 2022 at 9:27 AM Rob Landley <<a href="mailto:rob@landley.net">rob@landley.net</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">On 6/2/22 19:41, enh wrote:<br>
> Oh, yeah, I think *especially* for macOS where pretty much everyone is always on<br>
> the latest version anyway, unless your Mac equivalent of the seven year rule is<br>
> "support the oldest macOS release that still gets security backports", there's<br>
> no reason to do this. It's pretty rare they add anything significant anyway. <br>
<br>
If you think the mac AOSP prebuilts should require the latest macos version to<br>
run, that's your call. I don't really have a MacOS policy because I'm not<br>
familiar enough with MacOS: they actively exclude any developer who doesn't pay<br>
to play. (And sadly Darwin died in 2006, although I'll blog about that rather<br>
than blathering here.)<br></blockquote><div><br></div><div>sorry, i seem to have confused everyone here...</div><div><br></div><div>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.</div><div><br></div><div>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].)</div><div><br></div><div>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.</div><div><br></div><div>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.</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
The three macos use cases I have at the moment are "test on github", "ship AOSP<br>
prebuilt", and "random mac developer wants to use toybox", which all have<br>
slightly different requirements.<br></blockquote><div><br></div><div>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.)</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
There was a tentative fourth use case: back before Apple switched from bash to<br>
zsh I thought they might eventually show an interest in a finished toysh, but<br>
they did bash->zsh the same way Ubuntu went bash->dash and Canonical showed a<br>
surprisingly adamant refusal to ever admit a mistake. So my previous "might"<br>
went from ~20% chance to like 5% tops. (And their "we don't understand what<br>
vfork was for" move abandons the embedded space too.)<br></blockquote><div><br></div><div>don't forget "ps requires root" :-) i struggled to believe that one in 2005, let alone 2022!</div><div><br></div><div>





<p class="gmail-p1" style="margin:0px;font-variant-numeric:normal;font-variant-east-asian:normal;font-stretch:normal;font-size:14px;line-height:normal;font-family:Menlo;color:rgb(0,0,0)"><span class="gmail-s1" style="font-variant-ligatures:no-common-ligatures;color:rgb(170,171,37)"><b>~$ </b></span><span class="gmail-s2" style="font-variant-ligatures:no-common-ligatures">sw_vers<span class="gmail-Apple-converted-space"> </span></span></p>
<p class="gmail-p1" style="margin:0px;font-variant-numeric:normal;font-variant-east-asian:normal;font-stretch:normal;font-size:14px;line-height:normal;font-family:Menlo;color:rgb(0,0,0)"><span class="gmail-s2" style="font-variant-ligatures:no-common-ligatures">ProductName:<span class="gmail-Apple-tab-span" style="white-space:pre">      </span>macOS</span></p>
<p class="gmail-p1" style="margin:0px;font-variant-numeric:normal;font-variant-east-asian:normal;font-stretch:normal;font-size:14px;line-height:normal;font-family:Menlo;color:rgb(0,0,0)"><span class="gmail-s2" style="font-variant-ligatures:no-common-ligatures">ProductVersion:<span class="gmail-Apple-tab-span" style="white-space:pre">   </span>12.4</span></p>
<p class="gmail-p1" style="margin:0px;font-variant-numeric:normal;font-variant-east-asian:normal;font-stretch:normal;font-size:14px;line-height:normal;font-family:Menlo;color:rgb(0,0,0)"><span class="gmail-s2" style="font-variant-ligatures:no-common-ligatures">BuildVersion:<span class="gmail-Apple-tab-span" style="white-space:pre">     </span>21F79</span></p></div><div>





<p class="gmail-p1" style="margin:0px;font-variant-numeric:normal;font-variant-east-asian:normal;font-stretch:normal;font-size:14px;line-height:normal;font-family:Menlo;color:rgb(0,0,0)"><span class="gmail-s1" style="font-variant-ligatures:no-common-ligatures;color:rgb(170,171,37)"><b>~$ </b></span><span class="gmail-s2" style="font-variant-ligatures:no-common-ligatures">ls -l `which ps`</span></p>
<p class="gmail-p1" style="margin:0px;font-variant-numeric:normal;font-variant-east-asian:normal;font-stretch:normal;font-size:14px;line-height:normal;font-family:Menlo;color:rgb(0,0,0)"><span class="gmail-s2" style="font-variant-ligatures:no-common-ligatures">-rwsr-xr-x<span class="gmail-Apple-converted-space">  </span>1 root<span class="gmail-Apple-converted-space">  </span>wheel<span class="gmail-Apple-converted-space">  </span>203504 May<span class="gmail-Apple-converted-space">  </span>9 14:30 /bin/ps</span></p></div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
Rob<br>
<br>
P.S. The nommu stuff is about realtime response with long battery life: digital<br>
wristwatches could run for 5 years off the same battery because the chip inside<br>
was clocked at something like 32khz, not megahertz let along gigahertz. Sure die<br>
size shrinks help power/performance ratio but it's not linear (transistor<br>
leakage current etc get _worse_ at nanoscale), plus a 5nm chip produces<br>
microwatt signals that need a 45nm interface chip to translate them so it can<br>
talk to the outside world (and not get destroyed by the power surge when<br>
somebody opens the door and moves the air in the room), and for actual direct<br>
I/O (sensors doing analog/digital conversion or driving a small motor) you often<br>
want more like a 250 nanometer chip. So the "die shrinks will solve all this for<br>
us"... isn't true. Plus a 250 nanometer mask is what, $15k? The kind of thing<br>
you can amortize over a 30k unit production run no problem. A 5 nanometer mask<br>
isn't gonna cost less than $10 million any time soon, you've gotta make a LOT of<br>
the same chip for that to make economic sense. (The sky130 fab Google partnered<br>
with is actually a bit exotic, that's a "mixed signal" process doing a different<br>
resolution on each layer of the design, which makes routing extra-fun. Jeff<br>
Dionne is trying to do a j-core chip through that which can track GPS signals in<br>
a battery powered device, but it turns out their toolchain doesn't actually work<br>
and the first couple rounds of chips that went through the fab were all duds. He<br>
thinks he's fixed up most of it...)<br>
<br>
P.P.S. Here's a 2015 presentation about running nommu Linux on a chip with 256k<br>
of SRAM and no DRAM.<br>
<a href="https://elinux.org/images/9/90/Linux_for_Microcontrollers-_From_Marginal_to_Mainstream.pdf" rel="noreferrer" target="_blank">https://elinux.org/images/9/90/Linux_for_Microcontrollers-_From_Marginal_to_Mainstream.pdf</a><br>
It's a pity the Linux Foundation accidentally deleted that year's ELC videos off<br>
of youtube, his talk was nice too. Anyway, the trick is trimming kernel data<br>
structures, XIP ROMFS so your binaries only need their .data and .bss segments<br>
in RAM, and nommu not wasting memory on page tables. No DRAM means no DRAM<br>
controller spending power on refresh cycles...<br>
</blockquote></div></div>