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

SlugOS 5.0 enters development

Expand Messages
  • Mike (mwester)
    We ve just checked in the first bits in the development process for SlugOS 5.0. This release will be an interesting release for SlugOS, as it promises some
    Message 1 of 4 , Aug 22 7:30 AM
      We've just checked in the first bits in the development process for
      SlugOS 5.0.

      This release will be an interesting release for SlugOS, as it promises
      some major changes, with some significant new functionality and updates
      -- and along with that comes a bit of disruption as we work to make
      everything "play nicely" together.

      For those who are building their own SlugOS images, we'll certainly be
      making an effort to keep the latest development version buildable, and
      we welcome and encourage your feedback -- please let us know what's
      working for you and what's not.

      Goals:

      The goals for the 5.x release, when it finally does get to a release
      point, are to grow SlugOS to better fill the role it has in the set of
      firmwares available for the NSLU2 and similar devices.

      More specifically, OpenWRT does an excellent job for the "small" device
      configurations. Debian/ARM images have proven to be a very viable and
      useful solution for the "big" device configuration. And while the
      Linksys firmware is getting a bit old, Unslung remains a very viable
      firmware image for users who simply need to "break open" and extend the
      stock Linksys firmware. SlugOS fills the void between OpenWRT,
      Debian/ARM, and Unslung/Linksys, and provides an image that is current,
      will boot entirely from internal flash, and is tuned for small-devices.

      Some of the specific goals for the 5.x release were earlier stated by
      Rod Whitby:

      1) EABI (both BE and LE)
      2) opkg (replacement for ipkg, but without gpg
      signing due to size)

      In addition to those goals, we plan to explore the following areas:

      3) Busybox improvements - we will be adding many more of the busybox
      versions of standard Linux commands, and enabling many more options and
      features for the busybox versions -- this will permit us to replace some
      of the full versions of utilities in the base flash, freeing up space
      for other features.

      4) /dev improvements - managing USB storage devices (where the same
      device can end up as /dev/sda on one boot, and as /dev/sdb on the next
      boto, for example), is problematic. The current solution using udev
      needs to be improved so that we can more gracefully handle some of the
      interesting situations SlugOS users have come up with in the past!

      5) Recovery features - something similar to the Unslung "bootdisk"
      concept will be added; allowing the use of external devices to diagnose
      or communicate with a SlugOS system. While lower on the list, it would
      also be nice to have netconsole support built-in, as it is on Unslung.

      6) Kernel - this sort of goes without saying, but we will be upgrading
      to whatever kernel is stable at the time of the release.

      7) Boot infrastructure - SlugOS users have spoken, we need to do a
      better job in this release to make booting from NFS work
      "out-of-the-box". If the /dev improvements work out, it would be
      desirable to have the low-level support to permit one to "turnup" to a
      RAID device -- this may or may not be practical. The networking
      utilities on the core image will also be expanded.

      Current Status:

      The first step on this effort has been taken, but this is a lengthy
      effort. At present, we've migrated to opkg, and are working on the
      busybox enhancements.

      We'll be emailing out updates from time-to-time, but please don't wait
      for updates to test. If you have the ability to build your own SlugOS
      image, we encourage you to follow along and contribute in any way you
      can -- test results, bug reports, or even patches and suggestions are
      all very welcome.


      Thanks from the entire SlugOS development team!
    • jl.050877@gmail.com
      ... That sentence is ambiguous enough to inspire hope. For clarification, are there any similar devices that SlugOS supports now or plans to support? If
      Message 2 of 4 , Aug 22 12:41 PM
        On Fri, Aug 22, 2008 at 09:30:05AM -0500, Mike (mwester) wrote:
        > The goals for the 5.x release, when it finally does get to a release
        > point, are to grow SlugOS to better fill the role it has in the set of
        > firmwares available for the NSLU2 and similar devices.

        That sentence is ambiguous enough to inspire hope. For
        clarification, are there any 'similar devices' that SlugOS supports
        now or plans to support?

        If not, are you aware of any projects to fill the gap between
        WRT firmwares and Debian for hardwares that are not discontinued?

        John
      • Fernando Carolo
        ... Are there any other changes related to package maintenance, apart from the move from ipkg to opkg? I am asking this because right now we have two package
        Message 3 of 4 , Aug 28 8:29 AM
          On Fri, Aug 22, 2008 at 11:30 AM, Mike (mwester) <mwester@...> wrote:
          >
          > Some of the specific goals for the 5.x release were earlier stated by
          > Rod Whitby:
          >
          > 1) EABI (both BE and LE)
          > 2) opkg (replacement for ipkg, but without gpg
          > signing due to size)
          >

          Are there any other changes related to package maintenance, apart from
          the move from ipkg to opkg? I am asking this because right now we have
          two package feeds for SlugOS/BE, the standard one, with packages from
          OpenEmbedded, and the Optware feed. I believe the Optware feed works
          quite like a good hack, letting us have packages that are either not
          available from OE or missing some important options (think about cups
          from OE, that is compiled without http support and does not let you
          share printers easily for Windows machines), but at the expense of
          having two package managers living in parallel universes inside my
          slug.

          Can we do anything to improve this situation for the 5.x release, or
          am I way off the mark?

          Regards,

          --
          Fernando Carolo
          "Ignore the noise. Make some signal" -- Nathan Torkington
        • Mike (mwester)
          ... The optware feed is considered a feature. There is absolutely no intention to deprecate the use of that feed; in fact it is probable that the content of
          Message 4 of 4 , Aug 28 8:41 AM
            Fernando Carolo wrote:
            > On Fri, Aug 22, 2008 at 11:30 AM, Mike (mwester) <mwester@...> wrote:
            >> Some of the specific goals for the 5.x release were earlier stated by
            >> Rod Whitby:
            >>
            >> 1) EABI (both BE and LE)
            >> 2) opkg (replacement for ipkg, but without gpg
            >> signing due to size)
            >>
            >
            > Are there any other changes related to package maintenance, apart from
            > the move from ipkg to opkg? I am asking this because right now we have
            > two package feeds for SlugOS/BE, the standard one, with packages from
            > OpenEmbedded, and the Optware feed. I believe the Optware feed works
            > quite like a good hack, letting us have packages that are either not
            > available from OE or missing some important options (think about cups
            > from OE, that is compiled without http support and does not let you
            > share printers easily for Windows machines), but at the expense of
            > having two package managers living in parallel universes inside my
            > slug.
            >
            > Can we do anything to improve this situation for the 5.x release, or
            > am I way off the mark?

            The optware feed is considered a feature.

            There is absolutely no intention to deprecate the use of that feed; in
            fact it is probable that the content of the native SlugOS feeds will end
            up being limited to SlugOS-specific packages only (i.e. kernel modules,
            kernel-specific packages and similar core packages, and perhaps a small
            set of packages that benefit from, or require, SlugOS-specific treatment).

            We may be able to pre-package some of the optware feed setup so that it
            becomes auto-magical, and maybe feels more "built-in" to set up. But
            flash space is at a premium, so I'd prefer that we do that with a
            package in the standard SlugOS feeds instead of part of the flash image.

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