Conversation

Notices

1. Embed this notice
   anna (navi@social.vlhl.dev)'s status on Friday, 25-Oct-2024 03:38:40 JST anna
   i want out of the gnu boat now
   
   RE: https://mastodon.social/users/hannesm/statuses/113362629408431192
   • Embed this notice
     Haelwenn /элвэн/ :triskell: (lanodan@queer.hacktivis.me)'s status on Friday, 25-Oct-2024 03:38:39 JST Haelwenn /элвэн/ :triskell:

     in reply to
     @navi Well libarchive's bsdtar is a thing, although I've been wondering about forking heirloom for things like an auditable tar that's still maintained.
   • Embed this notice
     Haelwenn /элвэн/ :triskell: (lanodan@queer.hacktivis.me)'s status on Friday, 25-Oct-2024 03:42:06 JST Haelwenn /элвэн/ :triskell:

     in reply to

     • Haelwenn /элвэн/ :triskell:
     @navi But well for me that's something for after I've replaced coreutils with utils-std.
     
     And well heirloom tar works well enough for bootstrap-initrd.
   • Embed this notice
     anna (navi@social.vlhl.dev)'s status on Friday, 25-Oct-2024 04:01:21 JST anna

     in reply to

     • kimapr
     @kimapr how will it know which parts will be used before loading it into memory and executing main though?
     Haelwenn /элвэн/ :triskell: likes this.
   • Embed this notice
     kimapr (kimapr@ublog.kimapr.net)'s status on Friday, 25-Oct-2024 04:01:23 JST kimapr

     in reply to

     • Kanako the Gay :neocat_flag_lesbian:
     @navi @kanako "bigger binary takes longer to load into memory" i think might not even be true (at least on modern MMU-having systems) because it doesn't need to be loaded in its entirety, just the parts that are actually used. aside from linux itself LMDB uses this to just "load" an entire database in ram which is quick and doesn't actually take any ram from other processes as it's entirely disk cache. memory mapped io is cool ..
   • Embed this notice
     anna (navi@social.vlhl.dev)'s status on Friday, 25-Oct-2024 04:01:24 JST anna

     in reply to

     • Kanako the Gay :neocat_flag_lesbian:
     • kimapr
     @kimapr @kanako not enough to matter
     
     if i had to come up with a reason "bigger binary takes longer to load into memory" but it's also not enough to matter
     
     and i just don't like the concept of one overloaded binary doing 50 different things based on argv0
   • Embed this notice
     kimapr (kimapr@ublog.kimapr.net)'s status on Friday, 25-Oct-2024 04:01:25 JST kimapr

     in reply to

     • Kanako the Gay :neocat_flag_lesbian:
     @navi @kanako why not? it's more compact that way.
   • Embed this notice
     anna (navi@social.vlhl.dev)'s status on Friday, 25-Oct-2024 04:01:26 JST anna

     in reply to

     • Kanako the Gay :neocat_flag_lesbian:
     @kanako i also* don't want a single binary that provides everything though...
   • Embed this notice
     Kanako the Gay :neocat_flag_lesbian: (kanako@the.gayest.dev)'s status on Friday, 25-Oct-2024 04:01:27 JST Kanako the Gay :neocat_flag_lesbian:

     in reply to

     @navi@social.vlhl.dev busybox :3

   • Embed this notice
     Haelwenn /элвэн/ :triskell: (lanodan@queer.hacktivis.me)'s status on Friday, 25-Oct-2024 04:09:41 JST Haelwenn /элвэн/ :triskell:

     in reply to

     • Kanako the Gay :neocat_flag_lesbian:
     • kimapr
     @navi @kanako @kimapr In fact in terms of memory usage busybox is kind of weird, the most trivial of commands like uname(1) dynamically allocates memory.
     And that's without even considering statically allocated memory.
   • Embed this notice
     Haelwenn /элвэн/ :triskell: (lanodan@queer.hacktivis.me)'s status on Friday, 25-Oct-2024 04:46:43 JST Haelwenn /элвэн/ :triskell:

     in reply to

     • kimapr
     @navi @kimapr Well given dynamic linking typically does symbol resolution at call-time rather than load-time it's probably fine in comparison.
   • Embed this notice
     anna (navi@social.vlhl.dev)'s status on Friday, 25-Oct-2024 04:46:44 JST anna

     in reply to

     • kimapr
     @kimapr it could introduce stutters when first loading a function
     
     but not enough to matter (as is most points brought in this thread tbh)
   • Embed this notice
     anna (navi@social.vlhl.dev)'s status on Friday, 25-Oct-2024 04:46:45 JST anna

     in reply to

     • kimapr
     @kimapr that's actually smart
   • Embed this notice
     kimapr (kimapr@ublog.kimapr.net)'s status on Friday, 25-Oct-2024 04:46:47 JST kimapr

     in reply to
     @navi The data in ELF segments, be it functions, constants or whatever else
     
     the kernel would just read all the elf headers then sets up a memory map accordingly, without actually reading or loading any of data mapped. When time comes and it starts executing, any memory access of things that aren't loaded yet cause a page fault and it just loads them
   • Embed this notice
     anna (navi@social.vlhl.dev)'s status on Friday, 25-Oct-2024 04:46:48 JST anna

     in reply to

     • kimapr
     @kimapr load what? functions?
   • Embed this notice
     kimapr (kimapr@ublog.kimapr.net)'s status on Friday, 25-Oct-2024 04:46:50 JST kimapr

     in reply to
     @navi It would just load them as soon as they're needed? Then it all just stays in disk cache until the system runs out of memroy and needs to drop some of it