I agree with your comments. Txs.
I am about to learn about the NSLU2 first hand while working on my
soon to be Internet web server. I am most impressed by what the
Unslug team has built: it's advanced and so well organized.
The Unslug team had a plan and was able to develop an open
architecture to implement it. That way all individual developer's
efforts were added up towards one build release unlike us with the
Linsktation who are working in parallel on our local file system.
This is why our individual efforts hardly add up. That why also the
NSLU2 Unslug has momentum and the Linkstation does not.
It seems to me that Buffalo is not taking enough advantage of the
GNU open architecture the way the unslug went. Buffalo Japan must
still be afraid of losing platform control. A hand full of
developers in Japan got payed at the begining to port a Linux distro
and customize a UI. After that Buffalo stressed a wider product base
with larger disks.
Thanks for taking apart the firmware upgrade process. It is
interesting to see what is happening behind the scene. I believe we
have less chalenge than the NSLU because we have a fixed IDE disk
with all the code where the NSLU2 has to first copy the Flash to RAM
and run from RAM or from a USB disk if available.
I am looking forward to get my feet wet in the NSLU2 enviroment. The
NSLU2 package update is **really*slick**.
We could develop our update architecture around a cgi script and the
untaring of an archive in the LS tree.
If we set the target path out of the way (/mnt/bin/) and create
simlinks we will only need to refresh the links after a Buff
--- In LinkStation_General@yahoogroups.com
, Tim Lewis <spurp@c...>
> Hey Frenchy,
> Let me start off by saying that I think we mostly agree.
> The bug fixes, at this point, have to be our top priority.
> This is definitely what we need to concentrate on, and was
> the reason I put it at the top of my list.
> Once we've established that base, I think we should move on
> and create a release that gives end-users a consistent
> platform that allows them to easily add features without
> having to compile it themselves. From reading the list,
> it is evident that many people want to add the same features
> to their LS. Providing a consistant environment would allow
> us to more easily diagnose problems.
> The UNSLUNG people have already done this for the NSLU2.
> If an end-user wants to install an iTunes server on their
> NSLU2 they just type:
> $ ipkg install mt-daapd
> It's that simple. This is a *lot* better than what you have
> to do even with a Kuro box.
> Frenchy wrote:
> > My comments online. Basicaly we can keep the scope down to
> > manageable and realistic.
> I think what I mentioned may be realistic. Hey, if the NSLU2
> group can do it WITHOUT a manufacturer sanctioned development
> system, I think we can definitely do it with one. :)
> The best part about this is that they've already blazed the
> trail, so we can use them as a model.
> At the very least, though I think we need to split this
> group into "general", and "development", groups so that people who
> have general questions about the box won't be really confused when
> they read a bug-fix discussion.
> > No big new killer apps features (Kuro style) only bug fixes - I
> > developers hate bug-fixing. They would rather express their
> > creativity with fresh code.
> I'm not too thrilled about creating killer apps either. What I
> want to do is augment the standard functionality. The killer apps
> can be made by the guys with the Kuro. I just want a fileserver
> that doesn't suck, and maybe a better UI.
> (I actually enjoy debugging, BTW. I spent two years practically
> chained to profiling software looking for memory leaks.)
> > Bug fixes require a minimum of efforts as opposition to building
> > endless list of new features.
> LOL! You'd be surprised... ;)
> > Making LS work right with the
> > essentials set's us apart from the KURO project: a great Linux
> > developper sandbox (Free developers juice for Buffalo Inc, that
> > being cheap).
> That's the thing about the Kuro - it IS just a development
> environement. It really isn't designed to be user friendly, and
> if you read the Kuro group, it's obvious that the support just
> isn't there.
> One thing that could set us apart from all that is making it
> easy for the end user to add new features.
> > Another thing that sets us appart from Kuro is the Buffalo
> > It ends if you disassemble the box to recover a dead brick.
> That's why I want to find a way to fix it without opening the box.
> I don't think that an end user should have to open their
> to use our fixes, and the fixes definitely shouldn't brick their
> > The first step to get Telnet back is to downgrade to 1.45, then
> > fix.
> True. It would be nice to provide this in 1.46, though.
> > Someone out there must have a work around to get in the archive.
> I haven't had time for it yet. I've been looking through the
> initrd. Anyone else?
> > Can't we just stay at the file system level? Once in Unix we can
> > patch and move files then reboot.
> Yes, certainly. I don't think that there's any modifications that
> we can't do right on the box. I was just trying to figure out a
> to make the installation easy to do in one swell foop.
> To that end, I have a packet trace of a firmware installation.
> > I am not familiar with ppc_uart port but I gather that is what
> > turn the LS into a brick if the flash upgrade fails (I have had
> > twice already)
> Yes, it's the controlling program for the box. I don't think
> is sure about exactly everything it does (other than Buffalo).
> > This is out of my league, unknown... Now if we get down to the
> > kernel I am sure we up our chances for brick encounters but
> > Linux services should be mostly safe.
> Mine too. However, there's a lot of people in the NSLU2 group who
> can do this. Maybe they would be willing to mod an LS.
> > Where is the NSLU2 group hosted?
> You can find all the information you want at: http://www.nslu2-
> - Tim