alice wrote on Wed, Feb 01, 2023 at 07:22:14AM +0100:
> > Just looking at the s6 suite (s6, s6-rc, execline, skalibs,
> > s6-linux-init) I'm looking at a 3MB increase (because I won't be able to
> > get rid of openrc for compatibility with user scripts it'll have to live
> > in compat hooks...) ; being able to shave ~700KB of that would be
> > very interesting for me (number from linking all .c together with a
> > dummy main wrapper, down 148KB)
> > (s6-* dozen of binaries being another similar target and would shave a
> > bit more as well, build systems being similar I was hoping it could go
> > next if this had been well received)
>
> out of (somewhat off-topic) curiosity, what is the layout here?
> the general answer to such a case generally is:
> "sure, it's 3MB. but it's a well-implemented well-oiled well-used 3MB, and the
> 'business software' is hundreds of times that", but maybe this is something
> special?
>
> given the (below) talk of inexperienced users, it makes me wonder if everything
> is in this 100mb, or if it's only a reserved rootfs for you while the rest if
> customer-used.
Exactly, we have a double-copy rootfs that we try to keep as small as
possible and update atomically; then the rest of the eMMC/SD card is
left for user containers in a separate partition.
(I actually lied a bit here because the container runtime itself depends
on podman, which is a huge go binary that in itself doubles the rootfs
size ; and we cut some slack space that made the alpine 3.17 update
possible, but I'm definitely counting each MB at this point, it's
getting difficult to just install a debug kernel now...
I don't want to waste anyone's time, which is why I offered to do it,
but reviews still take time and as said previously I won't push
further.
I'd suggest "there's more information here", but it's all in Japanese:
https://armadillo.atmark-techno.com/guide/armadillo-base-os
You'd probably learn more from the rootfs[1] and update scripts[2]
directly:
[1] (rootfs content binary, 57MB)
https://armadillo.atmark-techno.com/files/downloads/armadillo-iot-g4/baseos/baseos-x2-3.17.1-at.2.tar.zst
[2] (rootfs and image builder)
https://armadillo.atmark-techno.com/files/downloads/armadillo-iot-g4/tool/build-rootfs-v3.17-at.2.tar.gz
[3]
https://github.com/atmark-techno/mkswu/
There's probably plenty to improve and I never got any external
feedback, so feel free to break everything and ask if you have time, I'd
be curious if you can make sense of it without the japanese docs)
> > > You're not the only one who is uncomfortable with it, but it's really a
> > > perception thing. There has never been a problem caused by it. Shells
> > > don't get confused. External tools don't get confused. On this aspect,
> > > Unix is a lot more correct and resilient than you give it credit for. :)
> >
> > Shells and external tools would definitely be fine, they're not looking
> > there in the first place.
> > I think you're underestimating what users who haven't used a unix before
> > can do though; I can already picture some rummaging in /bin and
> > wondering why posix-cd "doesn't work" or something... We get impressive
> > questions sometimes.
>
> i definitely feel for you there (in regards to inexperienced user questions),
> but i'd say that generally very low level (relatively) systems integration
> software is not the place where "inexperienced user support" is in-scope. the
> easiest answer is that if somebody runs into such a scenario, they'll just have
> to learn the answer to the question, not have an "answer" pre-implemented for
> them via a workaround (such as this one) that removes it.
>
> that is to say, resolving this (question-)case specifically would not be a
> benefit for execline itself.
Right, this is also completely off topic, I probably shouldn't have
started digging this hole :)
I'm not arguing for removing the installed tools here, just saying I
will likely get some questions about it once we make the switch.
Nothing that cannot be dealt with, but I am a greedy dev so I started
asking for too much.
--
Dominique Martinet | Asmadeus
Received on Wed Feb 01 2023 - 07:49:42 CET