<farkuhar>
a better name for the forked branch would be "remove_libbsd_dependency". It looks like they copied the needed functions straight from libbsd, for distros that don't want to have libbsd in a core install.
groovy2shoes has quit [Remote host closed the connection]
<braewoods_>
jaeger, does it matter? the average x86 system it will boot into has 4+ gigabytes today.
<braewoods_>
especially since 64 bit is the typical now
<jaeger>
Most of the time, probably not. But it's messy and wasteful, I feel.
<braewoods_>
are you already using squashfs or similar?
<jaeger>
It did use squashfs in the past, currently just an xz-compressed tarball.
<braewoods_>
there's an argument involving duplication of files between the packages and boot environment.
<jaeger>
There's probably a lot that could be made more minimal
<braewoods_>
Honestly if that's your goal, you may want to investigate the typical method used by most distributions today. They use a read-only base system to copy from and overlay the live CD changes over that.
<braewoods_>
This reduces bloat due to duplication of data.
<braewoods_>
but would require you to reinvent how you do install
<braewoods_>
-s
<jaeger>
At the moment I don't have a specific goal in mind, and it doesn't have to be perfect immediately. Just starting to think about it
<braewoods_>
maintaining a file list of each package as a text file might work so you know which files to copy.
<jaeger>
Part of the reason for the big tmpfs was to allow sshd to be used for installation as well as allow for unmounting the ISO after boot (which admittedly is an unusual need for an install ISO when you could just use some other live ISO instead)
<braewoods_>
jaeger, there's use cases for being able to remove the boot media but it's usually niche cases where ports are at a premium
<jaeger>
The former could still be easily accomplished with some smaller targeted tmpfs, the latter I'm not sure is worth preserving
<jaeger>
There's always a use case... the question is just if it's prevalent enough to be worth supporting
<braewoods_>
i've found it helpful for installing to an x86 tablet for example
<jaeger>
In order to free up the USB port in that case?
<braewoods_>
yes.
<braewoods_>
for like a keyboard
<braewoods_>
it's pretty rare outside of a few cases though.
<jaeger>
Convenient but not a blocker
<braewoods_>
but that's the only time it really makes a difference that I know of
<braewoods_>
you'd be surprised. the devices i was working with needed a custom ISO just for me to be able to do a ubuntu install of all things
<jaeger>
I wonder how many installs actually require something from the linux-firmware package
<braewoods_>
uefi 32 was a stupid trend.
<jaeger>
Yeah, it was... fortunately not super common
<braewoods_>
it was stupid having to use uefi32 to boot a 64 bit kernel
<braewoods_>
lol
<braewoods_>
booting to ram allowed me to use the usb port for ethernet or so to connect over ssh
<braewoods_>
which then gave me a much easier way to get stuff done
groovy2shoes has joined #crux-devel
mbarbar has quit [Quit: ZNC 1.7.2+deb3 - https://znc.in]