Re: [nslu2-linux] Proposal for the future of the NSLU2-Linux project
> please comment on it here on the nslu2-linux mailing listThanks to Rod and everyone else for all their hard work; the current
state of the project is very impressive. Here are some thoughts; I hope
they are of some interest. My Slug currently runs BE Debian with the
Concerning endianness, it's really a case of "whatever is easiest in the
longer term", though if the future is LE it will mean some short-term
pain for me. Hopefully someone else will go through the transition
first and post some nice instructions on the Wiki. I'm sure that
Lennart and the others realised that their work could turn out to be a
cul de sac if the LE ethernet drivers were fixed, as they have been.
On the OpenEmbedded vs. Debian thing, I'm running Debian because I can
and all my other machines run it; I don't think that dpkg and apt are
fantastic, but I'm familiar with them, and my brain only has capacity
for a limited number of obscure command line flags and file formats
A minimal Debian system includes more than a minimal OE system, and this
matters for people with limited space. My Slug has a 512Mbyte flash
disk and uses less than half of it. If UcSlugC is for systems with
on-board flash only and Debian runs in 256MBytes, the only systems that
need to run OE are those with 128 MByte or smaller flash drives; these
people could just spend another £2 on a slightly larger drive and run
Some people have commented on the fact that Debian has lots of packages
that won't run on a slug because they're too large. I don't think we
need to worry about this much, as long as they don't break the build
systems too badly. But it does raise the general question of a "one
size fits all" binary distribution. For example, gcc has a "-Os" option
to optimise for code size rather than for speed. This could make a
significant difference on the Slug, however much disk you have, because
there is only one quite small level of cache. With more control over
packages we could use things like -Os, yet with Debian we get the "one
size fits all" -O2 or whatever they've chosen. I'm not sure what to do
about this; maybe Gentoo has the answer, though I personally know next
to nothing about how that distribution works.
Somewhat related to that is the question of native vs. cross-compiling.
In general Debian needs native compilation, although tricks like the
distcc setup desribed on the Wiki mean that native compilation may
actually farm off some of the work to a cross-compiler on a faster
machine (do the Debian build machines actually do this?). As I
understand it, OE can cross-compile all of its packages. This must be
considered an advantage.
There are some Debian people who are working on these issues; see
emdebian.org. Their approach seems to be to build something that is
separate from Debian (i.e. different binary packages) with compilation
options etc. suitable for embedded system, using uclibc I think, with a
separate package Makefile (replacing debian/rules) for
cross-compilation. This is described as "work in progress" and doesn't
seem to be anything like as complete as OE.
Having said all that it is clear that the current systems do all work,
and personally I've moved on from getting the basic system running to
actually using it to do things. A Slug that runs Linux is not an end in
itself, but rather a means to an end. I think we should let the actual
applications guide us, so I'll finish by describing some of the things
that I am using, or am planning to use, my Slug for.
One of my professional interests is power efficiency, and I've decided
that my next PC is going to be a low-power unit with no moving parts.
Maybe even solar-powered in the summer. So I'm trying to work out what
is needed to turn something like a Slug into a useable personal computer
- after all, the Slug has a higher spec than the machine I was using
until 2001, and I still do basically the same sorts of tasks. Cheaper
flash disks, less bloated software [Mozilla! Gnome!], more RAM and a
way to connect a monitor are the main requirements.
My father recently downgraded from a real camera to a digital camera. I
say downgraded because the photos he takes are now locked away in his
computer where they will stay until he next suffers a disk crash and
will then be lost forever. If my mother wants to show her friends their
holiday photos she can no longer just show them the photos, she has to
go out to the shed in the garden where he keeps his computer and follow
a page of instructions that he's written down for how to start it up.
What they need is a wireless digital photo frame. Or preferably about
three of them, one of them connected to the TV. A Slug would make a
great always-on server for them, uploading from cameras, publishing to a
web site, and backing up. Perhaps it could also be the controller for
the photo frame, though again video out is a missing link.
At present my Slug's main role is as a print server, and I built a small
LCD display so that I can monitor the print queue. The Slug is ideal
for this sort of thing, but is somewhat hampered by the user-interface
(or rather the lack of it). Perhaps we should be exploring what can be
achieved with a buzzer, a couple of LEDs and one button: has anyone
tried speech synthesis on the Slug buzzer? ("OUT OF PAPER" = bzzzt bz
As a final aside, I wonder if now would be a good time for some
reorganisation of the mailing lists. It seems to me that the current
division into three lists is not on well-defined lines that actually
correspond to different classes of people. How about unslug / OE /
debian, and/or kernel / base-dstribution / apps?
OK, that's quite long enough! I await feedback.
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.