| 00:54.03 | Crofton | Gtk-Message: 21:20:16.707: Failed to load module "pk-gtk-module" |
| 00:54.03 | Crofton | Gtk-Message: 21:20:16.708: Failed to load module "canberra-gtk-module" |
| 00:54.11 | Crofton | this ring a beel with anyone? |
| 03:05.57 | *** join/#oe armpit (~armpit@2601:202:4180:c33:95a2:d4bf:38a3:22d3) |
| 03:41.30 | *** join/#oe bluelightning_ (~paul@pdpc/supporter/professional/bluelightning) |
| 04:21.26 | *** join/#oe bluelightning_ (~paul@pdpc/supporter/professional/bluelightning) |
| 04:37.13 | *** join/#oe bluelightning_ (~paul@pdpc/supporter/professional/bluelightning) |
| 04:54.07 | *** join/#oe NU-Slacker (~NU-Slacke@24.13.72.71) |
| 05:56.40 | *** join/#oe rob_w (~bob@unaffiliated/rob-w/x-1112029) |
| 06:09.33 | *** join/#oe AndersD (~AndersD@194-237-220-218.customer.telia.com) |
| 06:15.01 | *** join/#oe AndersD (~AndersD@194.237.220.218) |
| 06:44.28 | *** join/#oe ao2 (~ao2@host9-28-dynamic.51-82-r.retail.telecomitalia.it) |
| 07:38.41 | *** join/#oe tprrt (~tprrt@217.114.201.133) |
| 07:52.28 | *** join/#oe yegorich (~yegorich@mail.visionsystems.de) |
| 08:00.41 | *** join/#oe lusus (~lusus@62.91.23.180) |
| 08:11.09 | *** join/#oe cpriouzeau (~cpriouzea@164.129.115.76) |
| 08:18.29 | *** join/#oe Bunio_FH (~bunio@81-18-201-214.static.chello.pl) |
| 09:52.41 | *** join/#oe florian (~florian_k@Maemo/community/contributor/florian) |
| 10:13.07 | *** join/#oe rburton (~rburton@35.106.2.81.in-addr.arpa) |
| 10:20.22 | *** join/#oe awe001 (~awe00@unaffiliated/awe00) |
| 10:31.07 | *** join/#oe bluelightning_ (~paul@pdpc/supporter/professional/bluelightning) |
| 11:24.06 | *** join/#oe berton (~berton@177.194.204.148) |
| 12:25.14 | *** join/#oe ldnunes (~ldnunes_@177.194.204.148) |
| 12:56.46 | *** join/#oe tnovotny (~tnovotny@176.74.132.138) |
| 13:04.46 | Tartarus | 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? |
| 13:46.16 | *** join/#oe florian_kc (~florian_k@Maemo/community/contributor/florian) |
| 13:56.44 | *** join/#oe andre_d (~user@77.107.218.170) |
| 14:26.14 | *** join/#oe andre_d (~user@77.107.218.170) |
| 15:01.19 | *** join/#oe andre_d (~user@77.107.218.170) |
| 15:35.15 | *** join/#oe tnovotny (~tnovotny@176.74.132.138) |
| 15:51.48 | khem | people still think busybox is the only gpl code they are using ? |
| 15:52.36 | kergoth | chuckles |
| 15:52.55 | *** join/#oe stephano (~stephano@134.134.139.76) |
| 15:53.09 | kergoth | i was interested to see the suckless folks created a *very* minimal util-linux alternative. |
| 15:54.26 | kergoth | no idea if it's any good, of course |
| 15:54.27 | kergoth | https://git.suckless.org/ubase/file/README.html |
| 15:55.07 | fray | I'm not a huge fan of busybox myself.. I always thought there HAD to be a better way.. |
| 15:55.32 | fray | 'way back when', I worked with someone to construction a loadable module approach (dl-open .so).. worked fine, but we never finished it.. |
| 15:55.49 | kergoth | yeah, there are a number of better alternatives to a monolithic binary |
| 15:56.02 | kergoth | static individual binaries, dlopen, even just a shared library for the common code.. |
| 15:56.08 | kergoth | shrugs |
| 15:56.32 | fray | 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.. |
| 15:56.57 | kergoth | nods |
| 15:57.36 | kergoth | 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 |
| 15:57.46 | fray | 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.... |
| 15:57.56 | fray | worked surprisingly well actually... |
| 15:58.11 | kergoth | huh, sounds simple enough. even simpler than i was expecting |
| 15:58.39 | fray | 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.. |
| 15:59.05 | fray | 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.. |
| 15:59.25 | fray | but we never finished working on it beyond some reference examples.. |
| 15:59.30 | kergoth | ah, right, the usual executable overhead.. i was wondering what the value add was |
| 15:59.32 | fray | (I doubt I even have the code anymore) |
| 16:00.08 | fray | that overhead was a lot more back then, then it is now.. (based on device footprint and such) |
| 16:00.14 | kergoth | nods |
| 16:00.30 | kergoth | musl seems to produce a lot lighter binaries too |
| 16:01.07 | JaMa | 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? |
| 16:01.38 | fray | 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 |
| 16:01.45 | fray | (from a binary standpoint) |
| 16:04.44 | JaMa | 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 |
| 16:05.31 | JaMa | 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 |
| 16:06.51 | JaMa | 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) |
| 16:07.22 | JaMa | and even if they add it later I won't update the script to use it (for compatibility with older recovery with older busybox) |
| 16:09.41 | fray | 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.. |
| 16:10.39 | rburton | 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. |
| 16:10.56 | JaMa | with the resources available today, we should just get rid of busybox/toybox from default OE images :) |
| 16:11.06 | Tartarus | rburton: builds, or deps one? |
| 16:12.10 | rburton | Tartarus: builds, ideally. though arguably its all deps, so a --dry-run build should be sufficient |
| 16:12.17 | Tartarus | ok |
| 16:12.34 | *** join/#oe andre_d (~user@77.107.218.170) |
| 16:14.20 | Tartarus | rburton: imagefeatures.py OK for adding to for this? |
| 16:14.28 | rburton | Tartarus: perfect |
| 16:14.52 | Tartarus | nd I see I can do bitbake('--dry-run core-image-sato') |
| 16:14.53 | Tartarus | So, OK |
| 16:15.03 | Tartarus | Headsdown on $customer stuff again, thanks! |
| 16:33.59 | fray | 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.. |
| 16:34.43 | fray | 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 |
| 16:35.20 | fray | 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.. |
| 16:35.37 | fray | (not sure how valid some of that is beyond discussions.. but it could be an interesting project) |
| 16:35.57 | JaMa | but then this small initramfs might get responsible for flashing partitions and dd status=progress might be useful again :) |
| 16:36.13 | fray | ya, factory reset and such |
| 16:36.34 | fray | which is why the security aspects (even obfuscation) are a concern |
| 16:37.00 | JaMa | with A/B partitions we use much more flash space, than what would we loose by using proper tools ini initramfs |
| 16:37.24 | JaMa | and on most devies I'm not concerned with RAM as well |
| 16:37.27 | fray | but initramfs requires a certain amount of ram to be used during execution.. thats still the main concern I've seen.. |
| 16:38.05 | fray | 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 |
| 16:38.12 | JaMa | if it's good enough to run webengine in the end, then it's beefy enough to load few more megs with initramfs |
| 16:39.21 | JaMa | agreed |
| 16:39.58 | fray | I'm not looking for anything in the 1-2 MB range.. but in the (total filesystem) range of 32-64MB... |
| 16:40.09 | fray | very possible to do today, but still difficult at times... |
| 16:41.51 | fray | 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.. |
| 16:42.25 | JaMa | 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 |
| 16:42.32 | fray | ya |
| 16:42.49 | JaMa | not to include busybox everywhere, because there is Embedded in the tool name :) |
| 16:43.33 | fray | 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) |
| 16:44.10 | fray | 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 |
| 16:56.32 | *** join/#oe tnovotny (~tnovotny@176.74.132.138) |
| 17:03.10 | *** join/#oe vmeson (~rmacleod@138.229.221.104) |
| 17:21.51 | *** join/#oe dv_ (~dv@62-178-50-190.cable.dynamic.surfer.at) |
| 17:27.35 | *** join/#oe nslu2-log (~nslu2-log@23.141.224.193) |
| 18:05.53 | RP | 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 |
| 19:33.53 | *** join/#oe florian_kc (~florian_k@Maemo/community/contributor/florian) |
| 19:43.39 | *** join/#oe awe001 (~awe00@unaffiliated/awe00) |
| 20:13.36 | *** join/#oe dqx (~dqx@unaffiliated/dqx) |
| 20:52.28 | *** join/#oe bluelightning (~paul@pdpc/supporter/professional/bluelightning) |
| 20:58.54 | *** join/#oe ao2 (~ao2@host9-28-dynamic.51-82-r.retail.telecomitalia.it) |
| 21:12.56 | *** join/#oe dqx (~dqx@unaffiliated/dqx) |
| 21:40.11 | Tartarus | RP: OK, thanks |
| 21:40.42 | Tartarus | OK, 4 min for the --dry-run test, lets see how long just -g takes instead |
| 21:40.49 | Tartarus | since that too will catch breakage |
| 21:41.12 | Tartarus | (sorry, 3min above, 5s with just -g, gonna keep it with -g) |
| 21:42.17 | Tartarus | Lets see if --parse-only also catches |
| 21:44.23 | Tartarus | nope, gotta be -g or more |
| 22:44.25 | *** join/#oe flynn378__ (sid63564@gateway/web/irccloud.com/x-ftdlzsxhpfzneian) |
| 22:44.30 | *** join/#oe roxell_ (sid330443@gateway/web/irccloud.com/x-irgbtarkhhwhmkas) |
| 22:45.14 | *** join/#oe basic`_ (sid141140@linuxfoundation/basic) |
| 22:45.54 | *** join/#oe Tartarus_ (sid72705@gateway/web/irccloud.com/x-hmfycrixhltpvczj) |
| 22:54.18 | *** join/#oe m4t (~matt@2604:180:0:5d2::bad:beef) |
| 22:59.19 | *** join/#oe tbr (dm8tbr@mail.bfst.de) |
| 23:15.06 | *** join/#oe khem (~khem@unaffiliated/khem) |
| 23:41.16 | *** join/#oe georgem_home (uid210681@gateway/web/irccloud.com/x-jkyaxkdpmryzebrb) |
| 23:49.47 | *** join/#oe florian_kc (~florian_k@Maemo/community/contributor/florian) |