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

Re: [nslu2-linux] newbie questions

Expand Messages
  • Rod Whitby
    ... Welcome to the community. ... OK. I m assuming that you re able to compile these perl modules (which contain C code) on a host platform with no problems.
    Message 1 of 6 , Oct 4, 2008
    • 0 Attachment
      James Fidell wrote:
      > My NSLU2 arrived yesterday and now I'd like to get it installed and
      > usable, but I'm finding the sheer volume of information on the wiki a
      > little overwhelming, so please excuse me if I'm asking the obvious, and
      > feel free to point me at a URL where I can find my answers if necessary.

      Welcome to the community.

      > Firstly, my intention is to use the unit to run some perl daemons
      > reading data off one of the USB ports and transferring it to a server
      > elsewhere. For this I'll probably be needing to compile a few perl
      > modules from C source. I've been a Linux user and sysadmin for about
      > fifteen years, so that side of things is no problem to me.

      OK. I'm assuming that you're able to compile these perl modules (which
      contain C code) on a host platform with no problems. Are they part of
      CPAN or something like that, or are they your own work?

      > SlugOS/LE looks like a good bet for me, but am I correct in my
      > understanding that there is no slugos-native package for 4.8-beta,
      > which I'd need to be able to compile C code and I'd therefore be
      > better off using 3.10-beta even though the firmware download page
      > says that it's now unsupported?
      >
      > If slugos-native does exist for 4.8-beta, where do I find it?

      All the packages that are required to build software on the device are
      in the SlugOS feed. There is not a single slugos-native package, you
      need to install things like binutils, cpp, gcc, etc individually.

      > Would I be better off building the cross-compilation environment on
      > another machine and compiling the code I want on that? In which case,
      > is monotone 0.29 still the recommended version to avoid having to
      > rebuild the databases, or should I go for monotone 0.41?

      Have you looked at Optware running on SlugOS? We regularly
      cross-compile perl modules in Optware, so it should be straight forward
      to add another one if it's part of CPAN, or you can copy the techniques
      there to build your own.

      Note that you don't need monotone for Optware, it's in SVN.

      -- Rod
    • James Fidell
      ... Thank you. ... The ones that need code compiling are in CPAN (eg. Device::SerialPort). ... Ahhh... I see. ... Is that as documented here:
      Message 2 of 6 , Oct 6, 2008
      • 0 Attachment
        Rod Whitby wrote:

        > Welcome to the community.

        Thank you.

        >> Firstly, my intention is to use the unit to run some perl daemons
        >> reading data off one of the USB ports and transferring it to a server
        >> elsewhere. For this I'll probably be needing to compile a few perl
        >> modules from C source. I've been a Linux user and sysadmin for about
        >> fifteen years, so that side of things is no problem to me.
        >
        > OK. I'm assuming that you're able to compile these perl modules (which
        > contain C code) on a host platform with no problems. Are they part of
        > CPAN or something like that, or are they your own work?

        The ones that need code compiling are in CPAN (eg. Device::SerialPort).

        > All the packages that are required to build software on the device are
        > in the SlugOS feed. There is not a single slugos-native package, you
        > need to install things like binutils, cpp, gcc, etc individually.

        Ahhh... I see.

        > Have you looked at Optware running on SlugOS? We regularly
        > cross-compile perl modules in Optware, so it should be straight forward
        > to add another one if it's part of CPAN, or you can copy the techniques
        > there to build your own.

        Is that as documented here:

        http://www.nslu2-linux.org/wiki/Optware/Slugosbe

        ?

        I'd been given the impression that the little-endian releases were more
        stable and so gone down that route, but if the person who told me that
        was mistaken I'll certainly give it a try.

        James
      • mcpiffles
        The docs always seem to be a bit out of date. The optware packages are decent. I used the slugOS/BE 1.5 years or so ago when the LE side support sounded
        Message 3 of 6 , Oct 6, 2008
        • 0 Attachment
          The docs always seem to be a bit out of date.

          The optware packages are decent. I used the slugOS/BE 1.5 years or so
          ago when the LE side support sounded questionable at the time. From
          my reading, LE has greatly improved.

          Did you see the comparison matrix for firmwares? It's handy. Good
          summary and feature comparison.
          http://www.nslu2-linux.org/wiki/FAQ/FirmwareMatrix

          LE has better support for extra software (from DebianSlug) at this
          point, so personally, I'll probably go LE when/if I upgrade again.

          ----

          If you're at all comfortable opening your slug (see the wiki
          instructions for this), and you're not already running at 266 Mhz*,
          de-underclocking the CPU is easy and makes a pretty big difference.

          This is about the simplest hardware hack I've ever made.

          http://www.nslu2-linux.org/wiki/HowTo/OverClockTheSlug

          * Newer slugs may be running at full speed.

          tt

          http://www.nslu2-linux.org/wiki/SlugOS/SlugOSLE
          --- In nslu2-linux@yahoogroups.com, James Fidell <james@...> wrote:
          >
          > Rod Whitby wrote:
          >
          > > Welcome to the community.
          >
          > Thank you.
          >
          > >> Firstly, my intention is to use the unit to run some perl daemons
          > >> reading data off one of the USB ports and transferring it to a server
          > >> elsewhere. For this I'll probably be needing to compile a few perl
          > >> modules from C source. I've been a Linux user and sysadmin for about
          > >> fifteen years, so that side of things is no problem to me.
          > >
          > > OK. I'm assuming that you're able to compile these perl modules
          (which
          > > contain C code) on a host platform with no problems. Are they part of
          > > CPAN or something like that, or are they your own work?
          >
          > The ones that need code compiling are in CPAN (eg. Device::SerialPort).
          >
          > > All the packages that are required to build software on the device are
          > > in the SlugOS feed. There is not a single slugos-native package, you
          > > need to install things like binutils, cpp, gcc, etc individually.
          >
          > Ahhh... I see.
          >
          > > Have you looked at Optware running on SlugOS? We regularly
          > > cross-compile perl modules in Optware, so it should be straight
          forward
          > > to add another one if it's part of CPAN, or you can copy the
          techniques
          > > there to build your own.
          >
          > Is that as documented here:
          >
          > http://www.nslu2-linux.org/wiki/Optware/Slugosbe
          >
          > ?
          >
          > I'd been given the impression that the little-endian releases were more
          > stable and so gone down that route, but if the person who told me that
          > was mistaken I'll certainly give it a try.
          >
          > James
          >
        • Rod Whitby
          ... If you want them to become part of Optware, you can talk to Brian Zhou (you can find his contact details on this list), or become an Optware developer
          Message 4 of 6 , Oct 6, 2008
          • 0 Attachment
            James Fidell wrote:
            > Rod Whitby wrote:
            >> James Fidell wrote:
            >>> Firstly, my intention is to use the unit to run some perl daemons
            >>> reading data off one of the USB ports and transferring it to a server
            >>> elsewhere. For this I'll probably be needing to compile a few perl
            >>> modules from C source. I've been a Linux user and sysadmin for about
            >>> fifteen years, so that side of things is no problem to me.
            >>
            >> OK. I'm assuming that you're able to compile these perl modules (which
            >> contain C code) on a host platform with no problems. Are they part of
            >> CPAN or something like that, or are they your own work?
            >
            > The ones that need code compiling are in CPAN (eg. Device::SerialPort).

            If you want them to become part of Optware, you can talk to Brian Zhou
            (you can find his contact details on this list), or become an Optware
            developer yourself and contribute the recipes for building them (which
            might be as easy as just adding their names to some lists in the Makefiles).

            >> Have you looked at Optware running on SlugOS? We regularly
            >> cross-compile perl modules in Optware, so it should be straight forward
            >> to add another one if it's part of CPAN, or you can copy the techniques
            >> there to build your own.
            >
            > Is that as documented here:
            >
            > http://www.nslu2-linux.org/wiki/Optware/Slugosbe

            Yes. We also support Optware for SlugOS/LE too.

            > I'd been given the impression that the little-endian releases were more
            > stable and so gone down that route, but if the person who told me that
            > was mistaken I'll certainly give it a try.

            For SlugOS, the BE and LE releases are pretty much identical apart from
            the endianness.

            However, some hardware drivers only work in LE or BE (depending on the
            quality of the porting work of the author) due to endianness handling.

            Debian is LE, so that might be where some people get the mistaken idea
            that LE is more stable.

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