**** BEGIN LOGGING AT Fri Mar 01 02:59:57 2019 Mar 01 13:04:46 RP: Should I wait for Ross to point at a testcase I can borrow for ensuring the no-busybox stuff continues to work, or just post the first go-round at packagegroup-core-base-utils now? Mar 01 15:51:48 people still think busybox is the only gpl code they are using ? Mar 01 15:52:36 * kergoth chuckles Mar 01 15:53:09 i was interested to see the suckless folks created a *very* minimal util-linux alternative. Mar 01 15:54:27 no idea if it's any good, of course Mar 01 15:54:28 https://git.suckless.org/ubase/file/README.html Mar 01 15:55:07 I'm not a huge fan of busybox myself.. I always thought there HAD to be a better way.. Mar 01 15:55:32 'way back when', I worked with someone to construction a loadable module approach (dl-open .so).. worked fine, but we never finished it.. Mar 01 15:55:49 yeah, there are a number of better alternatives to a monolithic binary Mar 01 15:56:02 static individual binaries, dlopen, even just a shared library for the common code.. Mar 01 15:56:08 * kergoth shrugs Mar 01 15:56:32 ya.. forked dl-open the binary you wanted.. and ran.. took a lot less memory (per process), but turns out it wasn't able to share memory as well as busybox.. I suspect prelink or something could assist in better COW usage.. Mar 01 15:56:57 * kergoth nods Mar 01 15:57:36 nowadays for most use cases we aren't as resource constrained anymore anyway.. something like alpine could be a viable option for a lot of use cases Mar 01 15:57:46 the executor was basically, "get $0, if arg0 is executor name, use arg1... go to /usr/lib/.../ and look for name.so, if it existed dl-open it and move to app_main.... Mar 01 15:57:56 worked surprisingly well actually... Mar 01 15:58:11 huh, sounds simple enough. even simpler than i was expecting Mar 01 15:58:39 and the name.so could of course have it's own so dependencies for shared libraries.. since a lot of GNU utilities share common cores.. etc.. Mar 01 15:59:05 at the time (18 years ago) it shrunk the size of the static bits that got linked into every executable a lot, and did simplify a few things.. Mar 01 15:59:25 but we never finished working on it beyond some reference examples.. Mar 01 15:59:31 ah, right, the usual executable overhead.. i was wondering what the value add was Mar 01 15:59:32 (I doubt I even have the code anymore) Mar 01 16:00:08 that overhead was a lot more back then, then it is now.. (based on device footprint and such) Mar 01 16:00:14 * kergoth nods Mar 01 16:00:30 musl seems to produce a lot lighter binaries too Mar 01 16:01:08 kergoth: better than monolithic binary, because you can dynamically install any number of "plugins" instead of customizing busybox defconfig once? or do you see other disadvantages to busybox approach? Mar 01 16:01:39 JaMa that was the idea of what we were prototyping 'back then'.. none of this defconfig crap.. better control over what was installed on the system Mar 01 16:01:45 (from a binary standpoint) Mar 01 16:04:44 ok, I'm not so much concerned about this, because e.g. for TV where people usually don't use package feed to install extra utilities, you adjust the defconfig just once and occassional extra utility can be installed from proper tools Mar 01 16:05:31 I'm not big fan of busybox, just because I'm too used to features of standard utils and then almost always hit some sad limitation of busybox equivalent Mar 01 16:06:51 just like dd status=progress today, writting small script running in android recovery, wanted to see progress, cannot easily install pv to recovery image and busybox's dd doesn't support status (yet) Mar 01 16:07:22 and even if they add it later I won't update the script to use it (for compatibility with older recovery with older busybox) Mar 01 16:09:41 ya, what prompted the project 'way back when', was lack of what we felt were standard features, as well as the defconfig thing.. but that being said.. we were looking at BSD utilities as the foundation work, since they seemed to be more compact -- but again, only proceeded to proof of concept stage, it worked and we never pursued it.. Mar 01 16:10:39 Tartarus: see meta/lib/oeqa/selftest/cases, write a test case that sets PNBLACKLIST[busybox]="blacklisted" and then builds an image with that packagegroup in. Mar 01 16:10:56 with the resources available today, we should just get rid of busybox/toybox from default OE images :) Mar 01 16:11:06 rburton: builds, or deps one? Mar 01 16:12:10 Tartarus: builds, ideally. though arguably its all deps, so a --dry-run build should be sufficient Mar 01 16:12:18 ok Mar 01 16:14:21 rburton: imagefeatures.py OK for adding to for this? Mar 01 16:14:28 Tartarus: perfect Mar 01 16:14:52 nd I see I can do bitbake('--dry-run core-image-sato') Mar 01 16:14:53 So, OK Mar 01 16:15:03 Headsdown on $customer stuff again, thanks! Mar 01 16:33:59 JaMa what I see the main need for a 'small' busybox like system isn't busybox -- but it's license based for initramfs based systems.. Mar 01 16:34:43 People are looking for a small, non-GPL solution for various devices to setup security infrastructures, prior to switching into a standard (or otherwise) runtime/container environment Mar 01 16:35:20 non-GPL (BSD utilities for instance) so they can embed keys or key obfuscation components without having to rely on a TPM of some sort.. Mar 01 16:35:37 (not sure how valid some of that is beyond discussions.. but it could be an interesting project) Mar 01 16:35:57 but then this small initramfs might get responsible for flashing partitions and dd status=progress might be useful again :) Mar 01 16:36:13 ya, factory reset and such Mar 01 16:36:34 which is why the security aspects (even obfuscation) are a concern Mar 01 16:37:00 with A/B partitions we use much more flash space, than what would we loose by using proper tools ini initramfs Mar 01 16:37:24 and on most devies I'm not concerned with RAM as well Mar 01 16:37:27 but initramfs requires a certain amount of ram to be used during execution.. thats still the main concern I've seen.. Mar 01 16:38:05 128/256/512 MB of ram in a lot of devices still and with an initramfs you really don't want to take more then 50% of it before you stop doing whatever it is, and pivot to a real filesystem Mar 01 16:38:13 if it's good enough to run webengine in the end, then it's beefy enough to load few more megs with initramfs Mar 01 16:39:21 agreed Mar 01 16:39:58 I'm not looking for anything in the 1-2 MB range.. but in the (total filesystem) range of 32-64MB... Mar 01 16:40:09 very possible to do today, but still difficult at times... Mar 01 16:41:51 I do like the idea of musl, and BSD utilities for that kind of thing.. but not sure that alone will be useful.. glibc is bigger, but supporting two different libcs at once brings it's own complications.. Mar 01 16:42:25 yeah, I'm just saying that OE is now also used also for devices with 32-64GB range, so both use-cases should be supported equaly Mar 01 16:42:32 ya Mar 01 16:42:49 not to include busybox everywhere, because there is Embedded in the tool name :) Mar 01 16:43:33 I should try to recreate the dl-open approach at some point and see if it really does save any appreciable space anymore.. (storage or run-time) Mar 01 16:44:10 runtime is the one that I have no idea of.. if multiple dl-opens can share via COW it would be helpful.. but I don't know the kernel, and loader like that anymore **** BEGIN LOGGING AT Fri Mar 01 17:27:35 2019 Mar 01 18:05:53 Tartarus: I think rburton covered it. I'd be happy to see patches, a new image we add to the autobuilder might also be an option Mar 01 21:40:11 RP: OK, thanks Mar 01 21:40:42 OK, 4 min for the --dry-run test, lets see how long just -g takes instead Mar 01 21:40:49 since that too will catch breakage Mar 01 21:41:12 (sorry, 3min above, 5s with just -g, gonna keep it with -g) Mar 01 21:42:17 Lets see if --parse-only also catches Mar 01 21:44:23 nope, gotta be -g or more **** ENDING LOGGING AT Sat Mar 02 02:59:57 2019