Proposal for the future of the NSLU2-Linux project
- 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)
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.