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

Proposal for the future of the NSLU2-Linux project

Expand Messages
  • Rod Whitby
    ... OK, there s been a fair amount of discussion on the list since I sent this last year (three or four days ago), and I think we re ready to put forward a
    Message 1 of 37 , Jan 2, 2006
      On Fri, 30 Dec 2005 17:06:41 +1030, I said:
      > We find ourselves at a juncture where the project's core team needs to decide where it is going to focus its developer resources going forward.
      > Then we have the whole OpenSlug/DebianSlug/OpenDebianSlug/LeSlug/LeDebianSlug melting pot. This is the bit which we need to clean up and focus.
      > This email is long enough already, so please read and digest this, and I will follow up with another email giving a set of options for the future of NSLU2-Linux ...

      OK, there's been a fair amount of discussion on the list since I sent
      this last year (three or four days ago), and I think we're ready to put
      forward a proposal (and a subsequent question that arises from that

      Like I said in the initial message, Unslung will continue as long as
      there are Unslung firmware developers to keep pushing it forward, and
      mwester and marceln (and hopefully some other alpha testers) are pushing
      this forward again. You should expect a 6.x binary beta release as soon
      as we have 20 alpha testers. Josh Parsons will continue to drive the
      Optware/NSLU2 package feed and the numerous package developers who
      contribute to that package repository.

      UcSlugC's future remains in the hands of John Bowler, and the rest of
      the "SlugOS" variants all benefit from the work he (and others) have
      done to generalize our common SlugOS source base, and make it versatile
      enough to support different endianness, instruction sets, and C
      libraries. Without this work, LeSlug would have taken much longer to
      achieve. So I suspect it will continue to flourish under his guidance.

      As for the rest, it seems that there is interest in both an
      OpenEmbedded-based distribution, and a Debian-based distribution.

      As for the OpenEmbedded-based distribution, I think we should continue
      to release OpenSlug binary images, and continue to populate the openslug
      feed with big-endian, glibc-based packages from the OpenEmbedded package
      metadata repository. It remains up to the developers interested in
      OpenSlug to continue building, testing, and adding existing and new
      OpenEmbedded packages to openslug-packages.bb so that they end up in the

      As for the Debian-based distribution, the consensus of opinion stated on
      the list so far seems to be to use the existing little-endian arm Debian
      package repository (now that the little-endian IXP ethernet module
      problem has been solved). So we will release a "DebianSlug" binary
      image (which will be a renaming of "LeSlug" as it stands today, and
      which will continue to share it's kernel configuration with OpenSlug -
      we will converge the kernel configurations of OpenSlug and DebianSlug to
      make sure we have a single kernel configuration which meets the needs of
      both distributions). Initially, we will distribute instructions on how
      to debootstrap a Debian sarge or sid rootfs from a DebianSlug
      installation. The long-term goal is to have the NSLU2 be fully
      supported by the Debian distribution, including the NSLU2 becoming part
      of the ixp4xx Debian kernel package and enabling the use of a
      debian-installer image to boot a new NSLU2 directly into the
      debian-installer for a more user-friendly installation path. Note that
      since such an image must include the Intel IXP modules, we will need to
      distribute those images in the same way that we currently distribute
      Unslung and OpenSlug images (i.e. such images cannot be part of Debian
      itself until Intel releases support for IXP ethernet under a license
      that is compatible with Debian). We will also need to do the same with
      kernel module packages for the Intel IXP modules. I expect we will use
      the debonaras.org domain for this purpose (as part of it's charter of
      supporting Debian on consumer devices with large storage capabilities).

      Anyone who wants to continue using the OpenSlug binary image to
      debootstrap the "OpenDebianSlug" big-endian arm set of packages will
      continue to be able to do so (as long as those developers driving the
      Debian armeb port continue to do so), but it will not be an official
      nslu2-linux.org distribution (i.e. we won't be putting in the effort to
      produce a Debian big-endian arm kernel, or an armeb Debian-installer

      So there will be three binary images (and corresponding package feeds):
      Unslung, OpenSlug and DebianSlug. The DebianSlug image will begin as an
      OpenEmbedded-based kernel and rootfs (which can be used to debootstrap
      Debian onto an external disk), but will migrate to being a
      Debian-installer based kernel and rootfs as soon as those items are
      developed and become part of Debian proper.

      The subsequent question then becomes one of what support nslu2-linux
      should continue to provide for the Debian armeb (big-endian arm)

      As you know, Lennert and Derek have compiled 90% of the sarge packages
      (using mainly their own personal machines), and nslu2-linux has been
      providing two slugs (including hard disks, hosting, network bandwidth
      and technical support from ka6sox) as build machines for building the
      sid (unstable) Debian armeb packages. Just recently, [g2] (who runs
      http://www.giantshoulderinc.com/ ) has offered a 533MHz Loft board with
      128MB of RAM as a replacement for one of the slugs to enable large C++
      packages to be built without incurring massive swapping. If we can find
      someone else to donate similar hardware, we would be interested in
      swapping out the other slug too (to increase the efficiency of the
      Debian armeb build infrastructure).

      Since the consensus on the list seems to be that people want to re-use
      the existing little-endian Debian arm packages, then nslu2-linux may
      well cease to have a reason (other than goodwill to fellow developers
      who have contributed greatly to the project) to continue supporting the
      Debian armeb port. In particular, we need to answer the question of
      whether any existing or future nslu2-linux donations should be spent on
      buying hardware for the Debian armeb port, or whether it should be spent
      on other directly-related nslu2-linux.org and debonaras.org things (like
      providing hardware to little-endian arm Debian Developers, or buying and
      developing for other NAS boxes like the Iomega NAS 100d). This question
      needs to have some sensitivity attached to it, because the developers
      who continue to have a reason for driving the Debian armeb port have had
      (and continue to have) a significant contribution to nslu2-linux

      Anyway, that's my proposal for the future of the project. It's not set
      in stone yet, so please comment on it here on the nslu2-linux mailing
      list if you strongly agree or disagree.

      There have been other suggestions about how to improve the useability of
      the firmware distributions, and possibly putting together sets of
      packages for particular applications. The core team of firmware
      developers has always been of the mind to concentrate on the basic
      firmware platform, and allow our numerous package developers to produce
      such package sets, as they are independent of the base firmware images,
      and can be developed and improved outside of the firmware release
      cycles. These other ideas are very important, but can be handled
      separately from the question of which basic firmware images will be
      released and supported with package feeds.

      -- Rod (NSLU2 Project Lead)
    • Adrian Day
      John, ... It s definitely not a kernel crash. It just kills the current ssh session. I m at work now but will attempt to delve a little deeper into this when I
      Message 37 of 37 , Jan 31, 2006

        On 1/31/06, John Bowler <jbowler@...> wrote:
        > From: Adrian Day
        > >Running 'ls -lR /' will lock a ssh session.
        > Well, can you still ping the slug? (I.e. does it still
        > respond to ping?)
        > I've never managed to lock a system (i.e. a hard kernel lock
        > or a crash) by doing that, or the pretty much identical
        > command "find /", and I do it quite a lot (it's a quick and
        > easy way of getting CPU load).
        > What gets locked exactly? Assuming the ping doesn't respond,
        > does the power button work? What if you run a shell script to
        > toggle the disk 1 led on/off:
        > while true; do echo -n 100 >/sys/class/leds/disk-1/brightness; sleep 1; echo -n 0 >/sys/class/leds/disk-1/brightness; sleep 1; done
        > Does that keep going? (Running in another ssh session). What
        > happens when the LED is being made to flash from the kernel:
        > echo timer >/sys/class/leds/disk-1/trigger
        > echo 1000 >/sys/class/leds/disk-1/frequency
        > Does it lock up then? (That would indicate a kernel crash).

        It's definitely not a kernel crash. It just kills the current ssh
        session. I'm at work now but will attempt to delve a little deeper
        into this when I get home. I'm not alone - Jean Fabrice has
        experienced similar problems - I'd posted something about this a week
        or so back.

        Like I said, I'll spend some time looking into this in more detail.
        It's the least I can do compared to the considerable effort you and
        others have put into the slug.

      Your message has been successfully submitted and would be delivered to recipients shortly.