PDA

View Full Version : Out of curiosity



Todd Fields
2005-03-10, 13:37
--- Nic Wardle <nic (AT) nwardle (DOT) freeserve.co.uk> wrote:

> Was interested to see some had tried the latest Server (Ver
> 6.x) with the Roku with some success...

I'm no techie but I would guess as long as SlimServer is
designed to remain backwards compatible with Slim Devices'
legacy products (SLIMP3 and SB1) then I would think Roku users
should never have a problem using SlimServer. They just may not
be able to use all of its features. Again, that is my own
uneducated observation.



__________________________________
Do you Yahoo!?
Make Yahoo! your home page
http://www.yahoo.com/r/hs

Joshua Uziel
2005-03-10, 13:50
* Mike Hartley <mhartley (AT) comsolusa (DOT) com> [050310 12:41]:
> I know that this comment will not be supported by some, but here-in
> lies a very important reason for NOT open sourcing the firmware, IMHO.

There's no reason why the firmware source has to be released under a
currently available license like the GPL or BSD. Let's say in
hypothetical-land Slim has the rights to release the source for the SB2
firmware... they could license it in such a way that restricts usage to
personal use and, for example, requires royalties for products sold
using any of the code. That could provide an additional revenue stream
for Slim should *cough*Roku*cough* decide to use Slim's firmware.

(This coming from a decade-long Linux geek that would like to see
everything be GPL but acknowledges that the GPL isn't for everyone and
everything...)

Mike Hartley
2005-03-10, 13:57
I know that this comment will not be supported by some, but here-in lies a
very important reason for NOT open sourcing the firmware, IMHO.

Mike
----- Original Message -----
From: "Todd Fields" <jtfields91 (AT) yahoo (DOT) com>
To: "Slim Devices Discussion" <discuss (AT) lists (DOT) slimdevices.com>
Sent: Thursday, March 10, 2005 3:37 PM
Subject: [slim] Out of curiosity


>
> --- Nic Wardle <nic (AT) nwardle (DOT) freeserve.co.uk> wrote:
>
> > Was interested to see some had tried the latest Server (Ver
> > 6.x) with the Roku with some success...
>
> I'm no techie but I would guess as long as SlimServer is
> designed to remain backwards compatible with Slim Devices'
> legacy products (SLIMP3 and SB1) then I would think Roku users
> should never have a problem using SlimServer. They just may not
> be able to use all of its features. Again, that is my own
> uneducated observation.
>
>
>
> __________________________________
> Do you Yahoo!?
> Make Yahoo! your home page
> http://www.yahoo.com/r/hs
>

Joshua Uziel
2005-03-10, 14:26
* Mike Hartley <mhartley (AT) comsolusa (DOT) com> [050310 13:10]:
> And you are right that SLIM **could** choose to license and make money
> from it. But there may also be things that fall more under the "trade
> secrets/methods" category that can be problematic to license. You can
> attempt to protect them through NDA, but once they are known by others
> ideas and methods can be difficult to control. And your only real
> weapon is litigation, which is a crap shoot and gets expensive
> quickly, especially in the intelectual property arena. Take a look at
> Groklaw and read up on SCO vs The World if you haven't already. A
> protracted trade secrets suit could bankrupt a company like SLIM
> before they even got to the first day in court.

Oh, I'm well-aware of SCO and a whole bunch of other open source related
cases over the years. :) Sure, this is a conceivable outcome. To be
honest, while I'd prefer to be able to play with the firmware for the
SB2 and add stuff like native ogg support, the fact that it requires a
totally expensive toolchain suite ($25k was it?) kinda shoots it in the
head. I'm happy enough with the source for the server anyways.

Mike Hartley
2005-03-10, 14:26
Joshua,
I'm no Linux geek, but am a big fan of open source and in an ideal world I
would love to have everything GPL'd too. But, we aint there yet. :-). Too
many people look at it as "Free as in Beer" rather than "Free as in speech".

And you are right that SLIM **could** choose to license and make money from
it. But there may also be things that fall more under the "trade
secrets/methods" category that can be problematic to license. You can
attempt to protect them through NDA, but once they are known by others ideas
and methods can be difficult to control. And your only real weapon is
litigation, which is a crap shoot and gets expensive quickly, especially in
the intelectual property arena. Take a look at Groklaw and read up on SCO
vs The World if you haven't already. A protracted trade secrets suit could
bankrupt a company like SLIM before they even got to the first day in court.

I think SLIM is making a sound business judgement to hold some of it's most
valuable tech very close to the vest. It might slow down development and
turn off some, but I think it will insure they are around for a while
longer.

Mike

----- Original Message -----
From: "Joshua Uziel" <uzi (AT) uzix (DOT) org>
To: "Slim Devices Discussion" <discuss (AT) lists (DOT) slimdevices.com>
Sent: Thursday, March 10, 2005 3:50 PM
Subject: [slim] Out of curiosity


> * Mike Hartley <mhartley (AT) comsolusa (DOT) com> [050310 12:41]:
> > I know that this comment will not be supported by some, but here-in
> > lies a very important reason for NOT open sourcing the firmware, IMHO.
>
> There's no reason why the firmware source has to be released under a
> currently available license like the GPL or BSD. Let's say in
> hypothetical-land Slim has the rights to release the source for the SB2
> firmware... they could license it in such a way that restricts usage to
> personal use and, for example, requires royalties for products sold
> using any of the code. That could provide an additional revenue stream
> for Slim should *cough*Roku*cough* decide to use Slim's firmware.
>
> (This coming from a decade-long Linux geek that would like to see
> everything be GPL but acknowledges that the GPL isn't for everyone and
> everything...)
>

Mike Hartley
2005-03-10, 14:47
Yikes....25K? That's some mighty expensive beer. ;-)
----- Original Message -----
From: "Joshua Uziel" <uzi (AT) uzix (DOT) org>
To: "Slim Devices Discussion" <discuss (AT) lists (DOT) slimdevices.com>
Sent: Thursday, March 10, 2005 4:26 PM
Subject: [slim] Out of curiosity


> * Mike Hartley <mhartley (AT) comsolusa (DOT) com> [050310 13:10]:
> > And you are right that SLIM **could** choose to license and make money
> > from it. But there may also be things that fall more under the "trade
> > secrets/methods" category that can be problematic to license. You can
> > attempt to protect them through NDA, but once they are known by others
> > ideas and methods can be difficult to control. And your only real
> > weapon is litigation, which is a crap shoot and gets expensive
> > quickly, especially in the intelectual property arena. Take a look at
> > Groklaw and read up on SCO vs The World if you haven't already. A
> > protracted trade secrets suit could bankrupt a company like SLIM
> > before they even got to the first day in court.
>
> Oh, I'm well-aware of SCO and a whole bunch of other open source related
> cases over the years. :) Sure, this is a conceivable outcome. To be
> honest, while I'd prefer to be able to play with the firmware for the
> SB2 and add stuff like native ogg support, the fact that it requires a
> totally expensive toolchain suite ($25k was it?) kinda shoots it in the
> head. I'm happy enough with the source for the server anyways.
>
>

Joshua Uziel
2005-03-10, 14:57
* Mike Hartley <mhartley (AT) comsolusa (DOT) com> [050310 13:31]:
> Yikes....25K? That's some mighty expensive beer. ;-)

Oops, my bad... it's $30k as stated by Sean Adams earlier today in the
thread titled "Open firmware for SB2?"... see:

http://forums.slimdevices.com/gforum.cgi?post=35296#35296

If there were a GNU toolchain for it, then I'd be a little more tempted.
:)

seanadams
2005-03-10, 15:33
On Mar 10, 2005, at 1:57 PM, Joshua Uziel wrote:

> * Mike Hartley <mhartley (AT) comsolusa (DOT) com> [050310 13:31]:
>> Yikes....25K? That's some mighty expensive beer. ;-)
>
> Oops, my bad... it's $30k as stated by Sean Adams earlier today in the
> thread titled "Open firmware for SB2?"... see:
>
> http://forums.slimdevices.com/gforum.cgi?post=35296#35296
>
> If there were a GNU toolchain for it, then I'd be a little more
> tempted.
> :)

If you are interested in the ip3k processor please check out these
links:

http://www.ubicom.com (the manufacturer)

http://www.silicondust.com/ubicom/forum (forum operated by Nick
Kelsey, a former ubicom employee. He is trying to negotiate a scenario
where smaller customers could get cheaper/free access to tools and OS)

http://www.seanadams.com/ip3k/cpu_module (some information about the
processor module we designed, which is used in Squeezebox2)

The ip3k is a brand new processor architecture, and Squeezebox2 will be
one of the first products to ship with it.

The base toolchain is GCC and I believe all the current support for
ip3023 is in the main fsf branch.

However the operating system, which is not just an OS but also software
implementations of the PCI interface, ethernet MAC, 802.11g upper MAC,
etc etc, plus a whole pile of other tools, plus the reference designs,
plus the programming dongle, plus a whole pile of other things are what
you pay for in the dev kit.

But the compiler is GCC, and this does mean that if we could work out a
suitable loader mechanism, it might be possible to break out the
interesting pieces like audio codecs, visualizers, and geekport
drivers. We are also investigating ideas like a forth interpreter,
which would be perfect for making visualizers (assuming FFT and
graphics primitives are taken care of in native code).

Also, this is a hardware multithreaded processor, which means it runs
like 8 separate CPUs all connected to the same memory. Already the DSP
stuff runs in a dedicated hardware thread. It might be possible to
dedicate a "customer thread" for client-side plugins and other hacks.

Anyway we are still really busy with SB2 production right now. Once
we're shipping and everything is humming along, there will be more time
to spend investigating this. Again, as usual no promises on what we'll
do, or if/when we'll do it. Just sharing some info about what might be
possible and what the issues are.

Also yes, of course we have a strategy WRT competitors which will limit
what gets opened up under what license.

Joshua Uziel
2005-03-10, 15:57
* Sean Adams <sadams (AT) slimdevices (DOT) com> [050310 14:33]:
> If you are interested in the ip3k processor please check out these
> links:

Ohhh boy... looks like I have some reading to do. :)

> But the compiler is GCC, and this does mean that if we could work out a
> suitable loader mechanism, it might be possible to break out the
> interesting pieces like audio codecs, visualizers, and geekport
> drivers. We are also investigating ideas like a forth interpreter,
> which would be perfect for making visualizers (assuming FFT and
> graphics primitives are taken care of in native code).

Ahh, interesting. That certainly changes things... maybe I'm jumping
the gun, but I'm already thinking "need to compile a cross-compiler". :)

> Anyway we are still really busy with SB2 production right now. Once
> we're shipping and everything is humming along, there will be more time
> to spend investigating this. Again, as usual no promises on what we'll
> do, or if/when we'll do it. Just sharing some info about what might be
> possible and what the issues are.

Well, as I have no expectations, anything you do towards this would
exceed my expectations. :)

> Also yes, of course we have a strategy WRT competitors which will limit
> what gets opened up under what license.

I'd be scared if you didn't... but it's good to hear. As one of the few
companies out there that "gets it" (and one of the coolest start-ups in
town), here's hopin' you guys have a bright future.

Phil Karn
2005-03-12, 00:10
Joshua Uziel wrote:

> Oh, I'm well-aware of SCO and a whole bunch of other open source related
> cases over the years. :) Sure, this is a conceivable outcome. To be
> honest, while I'd prefer to be able to play with the firmware for the
> SB2 and add stuff like native ogg support, the fact that it requires a
> totally expensive toolchain suite ($25k was it?) kinda shoots it in the
> head. I'm happy enough with the source for the server anyways.

This is about as good an argument as you can make for putting as much as
you can in the server and keeping the client (the Squeezebox) as simple
and generic as possible.

The Squeezebox should focus on a very basic set of hardware functions
and doing them as well as possible. Everything else -- all the bells and
whistles -- belong on the server where you have essentially unlimited
CPU and memory and a powerful, open development environment to do
whatever your heart desires.

I presume Slim Devices chose its name because they felt much the same way.

IMHO, I can think of only two really valid reasons to justify additional
functionality in a device like the Squeezebox.

The first would be features that make it easier for the server to meet
its real-time constraints to prevent buffer exhaustion. The SB1 has a
rather small buffer that empties in less than one second at PCM rates,
and this can be difficult to meet on a general purpose server that's
also doing other things. The SB2 has essentially solved this problem
with a much bigger buffer. If you can't get your server to refill the
SB2's buffer often enough, you've got bigger problems to solve.

The other class of enhancements would alleviate the Squeezebox's
bandwidth requirements on wireless channels. (PCM is already a trivial
load on a 100 Mb/s wired connection. If you still have 10 Mb/s hubs,
upgrade!) The built-in MP3 decoder in the original Squeezebox certainly
helps with this, as does the addition of 802.11g and built-in FLAC
decoding in the SB2 for the purists who insist on a totally lossless
audio path under all conditions.

With these new features to the SB2, I really can't think of anything
else that I *really* can't live without. I think Slim Devices has done
an excellent job with both the SB and SB2, and wouldn't want to see it
sunk with creature feep as has happened to so many other products of its
type.

Phil