On Fri, Jun 3, 2022 at 9:27 AM Rob Landley <[email protected]> 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... >
_______________________________________________ Toybox mailing list [email protected] http://lists.landley.net/listinfo.cgi/toybox-landley.net
