Loading ...
Sorry, an error occurred while loading the content.

Re: [nslu2-linux] slugosbe-5.4-alpha-nslu2.bin rootfs size issue

Expand Messages
  • Mike Westerhof
    ... Maybe, but there were sound reasons for going with openssh; those reasons haven t changed. There s some trimming that can be done to the latest openssh
    Message 1 of 2 , May 9, 2010
    • 0 Attachment
      Steve wrote:
      > I see that openssl is part of the build and it appears to be using about 1.5M of the fs. Seems like a good place to save space by returning to dropbear.
      >
      Maybe, but there were sound reasons for going with openssh; those
      reasons haven't changed. There's some trimming that can be done to the
      latest openssh packages; last time I looked, someone in OE had done
      something that ended up dropping numerous useless PAM libraries in the
      filesystem, for example.
      > I also noticed that the current busybox (1.16.1) now supports many of the utilities that are being done by the *.util-linux-ng package. There might be a net savings there though I don't know if the busybox versions will work as expected in slugos. Just a thought.
      >

      That's the most promising area. Somebody decided to "fix" libuuid
      handling, and as a result the SlugOS alpha images for the past month
      have been way over-bloated. Some simple dependency issues might fix a
      lot of this, but it might be better in the long term to see how much
      more of busybox we might be able to use.

      The problem has always been that the busybox mount utility, along with a
      few others, have both missed some critical features we need, and had
      some critical bugs that we can't afford

      > I also see that raid support and utilities are part of the build. Certainly a low priority for me.
      >

      But critical to those who use that facility. This was added so that you
      can turnup to a mirrored device, the use case being the situation where
      someone wishes to use a flash memory USB devices in a heavy "write"
      environment. In that case, mirroring two USB flash devices will be
      advantageous when the inevitable failure of one of the USB devices happens.

      If necessary, we could create different initial SlugOS images tuned to
      different uses, but that seems wrong when compared to simply investing
      the time to sort out the bogus dependencies that got added into OE while
      we weren't looking. (Actually, I found the commit; figuring out how to
      "undo" it in a socially-acceptable manner is another issue.)
      > Hope this helps,
      > Steve
      >

      It helps immensely - Thanks for taking the time to test all this!

      -Mike (mwester)
    Your message has been successfully submitted and would be delivered to recipients shortly.