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

Re: [nslu2-linux] Proposal for the future of the NSLU2-Linux project

Expand Messages
  • Phil Endecott
    ... Thanks 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
    Message 1 of 37 , Jan 2, 2006
      > please comment on it here on the nslu2-linux mailing list

      Thanks 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
      OpenSlug kernel.

      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
      (bitbake! Monotone!).

      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
      Debian.

      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
      bzz-bzr.)


      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.

      --Phil.
    • 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
        John,

        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.

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