Open firmware for SB2?

[Patrick Dixon]

IMHO, the two biggest threats to Slim Devices' competitive advantage are:

* Product design - most 'normal' people think the Roku styling is better.
* Simple software installation - most 'normal' people can't (or can't be
bothered) to spend hours reconfiguring their computer to get an application
running - if it doesn't work reliably straight from the tin, they'll just
send it back and move on.

The second produces a major dilemma - the opensource community is
notoriously geeky and seems to just love wading though reams of poorly
documented or undoccumented source code to re-configure it for some strange
combination of a Linux installation. But if the company concentrates on
supporting and making the software work seamlessly with Windows and iUnix,
it will probably alienate the geeks.

I wonder what will happen when Bill Gates tries to buy Slim Devices.

-----Original Message-----
From: discuss-bounces (AT) lists (DOT) slimdevices.com
[mailto:discuss-bounces (AT) lists (DOT) slimdevices.com]On Behalf Of Sean Adams
Sent: 12 March 2005 07:56
To: Slim Devices Discussion
Subject: [slim] Open firmware for SB2?




> Let SLIM hold the familty jewels so they can get a return on the
> investment they have made.
>

Holding.....

Holding....

uh...

[Phil Karn]

Patrick Dixon wrote:
> IMHO, the two biggest threats to Slim Devices' competitive advantage are:
>
> * Product design - most 'normal' people think the Roku styling is better.

Maybe. Personally, I think basic functionality and reliability are far
more important. Then again, my Squeezeboxes are all black.

> * Simple software installation - most 'normal' people can't (or can't be
> bothered) to spend hours reconfiguring their computer to get an application
> running - if it doesn't work reliably straight from the tin, they'll just
> send it back and move on.

Absolutely!

> The second produces a major dilemma - the opensource community is
> notoriously geeky and seems to just love wading though reams of poorly
> documented or undoccumented source code to re-configure it for some strange
> combination of a Linux installation. But if the company concentrates on
> supporting and making the software work seamlessly with Windows and iUnix,
> it will probably alienate the geeks.

I don't think that's really a big dilemma. These sorts of "sponsored
open source" projects work best when the volunteers work on the features
that personally interest them, and the commercial sponsor acts as the
project "glue" -- merging patches, conducting regression testing, and
managing the release cycle. I can't see how any geek could oppose the
mere existence of a stable Windows version (though that's arguably a
contradiction in terms) so long as the code he's interested in remains
open and hackable.

What I *do* find discouraging is the distressing unreliability of even
the 5.4 version of the server software. I shouldn't have to install the
version du jour just to get a fix for a bug that keeps crashing my
server in routine usage.

There ought to be two code bases: a relatively stable, no-frills version
with an emphasis on robustness, and an experimental version with all the
latest gimmicks. As new features prove themselves and become stable,
they can be backported to the stable version. This is hardly a novel
concept; it's worked very well for Linux.

Most of the volunteers would probably prefer to play with the
experimental release, while the people at Slim Devices would maintain
the stable version. After all, their product is pretty much useless
without a server to drive it.

--Phil

[Michael Peters]

On Sun, 13 Mar 2005 08:53:35 -0000, Patrick Dixon
<patrickdixon (AT) btinternet (DOT) com> wrote:
> "it's worked very well for Linux."
>
> Really? As someone struggling to get FC3 configured, googling for
> information produces many more people with Linux problems than there are
> solutions out there.

Linux runs beautifully for me, though it isn't completely without issues.
OTOH I have been using Linux for quite some time, so it's way of doing
things has become native to me, making it easier for me to use than
Windows or Mac OS X (I am an Apple fan, btw - but Apple made newer
versions of OS X difficult to use on my hardware, so I haven't used a
recent version of OS X in some time)

>
> BTW anyone care to help with my problem getting Slimserver 5.4.0 to start up
> correctly?

In fc3 for me it was as simple as installing the rpm.
I did notice that in the rpm spec file they did something I really
dislike - they turned off the autoreqprov (common with perl) without
then specifying what specifically IS required. It may be a dependency
issue that you are having.

To fulfill dependencies, I personally only use stuff packaged by rpm -
and I'm picky about my repositories - I only use fedora,
fedora-extras, rpm.livna.org, and (for java) jpackage.org.

If something I want isn't in one of those repositories - then I build
my own rpm, with few exceptions (realplayer, slimserver are only two I
can think of).

One thing I am planning on doing when my SB2 arrives is taking the
slimserver 6 src.rpm and cleaning up the spec file so that it meats
the Fedora Extras packaging guidelines (and specifying the
dependencies), and then submit it to rpm.livna.org - so that for
Fedora users, installing it will be painless. Unfortunately it will
have to go into rpm.livna.org because the mp3 dependency (and faad2
dependency) can only be filled by packages with patent distribution
issues, hence rpm.livna.org

I wish I knew what was giving you issues with slimserver.
Some thought - disable SELinux
Get the src.rpm - comment out the disabling of autoreqprov - build the
rpm, and do a test install to see what (if any) dependencies rpm
complains about.

Oh - as an FYI - the place where I see the most useful help for Fedora is

http://www.linuxquestions.org/

in the Fedora forum.


--
http://mpeters.us/

[Dan Sully]

* Michael Peters shaped the electrons to say...

>One thing I am planning on doing when my SB2 arrives is taking the
>slimserver 6 src.rpm and cleaning up the spec file so that it meats
>the Fedora Extras packaging guidelines (and specifying the
>dependencies), and then submit it to rpm.livna.org - so that for
>Fedora users, installing it will be painless. Unfortunately it will
>have to go into rpm.livna.org because the mp3 dependency (and faad2
>dependency) can only be filled by packages with patent distribution
>issues, hence rpm.livna.org

That would be fantastic, Michael. The spec file lives in Subversion:

http://svn.slimdevices.com/trunk/platforms/redhat/

We've actually stopped generated the .src.rpm, as it's rather redundant.

-D
--
They're techno trousers, ex-NASA, fantastic for walkies!

[Victor Brilon]

On Mar 13, 2005, at 11:56 AM, Dan Sully wrote:

> * Michael Peters shaped the electrons to say...
>
>> One thing I am planning on doing when my SB2 arrives is taking the
>> slimserver 6 src.rpm and cleaning up the spec file so that it meats
>> the Fedora Extras packaging guidelines (and specifying the
>> dependencies), and then submit it to rpm.livna.org - so that for
>> Fedora users, installing it will be painless. Unfortunately it will
>> have to go into rpm.livna.org because the mp3 dependency (and faad2
>> dependency) can only be filled by packages with patent distribution
>> issues, hence rpm.livna.org
>
> That would be fantastic, Michael. The spec file lives in Subversion:
>
> http://svn.slimdevices.com/trunk/platforms/redhat/
>
> We've actually stopped generated the .src.rpm, as it's rather
> redundant.
>
Michael, as the guy who originally wrote large chunks of that spec
file, I am glad someone is taking it over. I've moved my home setup to
OS X and I no longer have the incentive to work on the RPM stuff

Victor

[Gerald B. Cox]

I do not run FLAC so I am not familiar with the processor requirements. I do
know that transcoding to WAV is not insignificant; and am skeptical of the
overhead requirements for FLAC. Regardless, the bandwidth requirements for a
FLAC transmission is greater than that of ogg. I have problems now with
dropouts relating to the transcoding into WAV. I would dispute the fact that
"ogg is the least used format out there". Alot of my friends have already
switched to it, and it has quite a positive buzz in the community - as
evidenced by the growing use of ogg in portable devices and streaming
audio. Regarding using FLAC for transcoding, it is "A" solution. I
would dispute that
it is totally acceptable. If one were to extend that logic, there would be no
firmware support for any format other than FLAC in firmware. Obviously, that
is not the case. I think it is great that there is FLAC support in firmware
for SB2, but that wasn't my question. My question, again, relates to the
availability of ogg support in firmware - and if it is possible for that
support to be provisioned in SB2.

> Quoting Jason jason at pagefamily.net

> Transcoding to FLAC requires very little overhead and is lossless, so what
> is the problem? Ogg support would be nice but it's without a doubt the
> least used format out there (even apple lossless seems to have more
> devotees) and slim is providing a totally accepteable solution (transcoding
> to a lossless format).

[Lars Kellogg-Stedman]

> Really? As someone struggling to get FC3 configured,

You're running Fedora. That would be the "unstable, experimental"
version of the code that Phil was talking about. If you want a stable,
supported platform, albeit with fewer features, try one of RedHat's
Enterprise Linux products.

They even offer support contracts.

This is almost exactly the model Phil was proposing for Slimserver -- an
experimental, feature-rich, always on the bleeding edge codebase for
those who like to tinker, and a more stable, more controlled, and
generally less featured version for commercial release and for people
just want basic functionality.

-- Lars

[Jack Coates]

Lars Kellogg-Stedman wrote:
>>Really? As someone struggling to get FC3 configured,
>
>
> You're running Fedora. That would be the "unstable, experimental"
> version of the code that Phil was talking about. If you want a stable,
> supported platform, albeit with fewer features, try one of RedHat's
> Enterprise Linux products.
>
> They even offer support contracts.
>

Or save some money and try out Mandrake or SuSE, there's a reason those
two distros have been swapping the "best desktop distro" reviews back
and forth the last few years. Red Hat is not the only Linux, or even the
best Linux for all purposes.

--
Jack at Monkeynoodle dot Org: It's a Scientific Venture...
Riding the Emergency Third Rail Power Trip since 1996!

[Michael Peters]

On Mon, 14 Mar 2005 18:33:08 +0100, Christian Pernegger
<pernegger (AT) hotmail (DOT) com> wrote:
> >I do know that transcoding to WAV is not insignificant; and am skeptical of
> >the overhead
> >requirements for FLAC. Regardless, the bandwidth requirements for a FLAC
> >transmission is greater
> >than that of ogg.
>
> While this is true, bandwidth / size is not really an issue any more in any
> kind of stationary setup. Harddisk sizes are such that even encoding your
> CDs in a lossless codec is hardly worth the effort anymore - if it weren't
> for tagging support I'm sure some people would just rip to .wav and be done
> with it.

I'm not sure that's true.
If it were not for flac - my archive drive for ripped music would be
overful and I would need two drives.

I still have room for many more albums on that drive because it is compressed.

The other issue is backup - compressed means less media is needed for
backing up your archive.

While it is true that hard drives are getting bigger and cheaper,
storage needs of users are getting bigger as well - especially now
that a lot users are keeping video rips of movies around etc.

Compression lets you keep more of it so you don't run out out space or
have to have several external SCSI/FireWire/USB drives all over the
place.

--
http://mpeters.us/

[Michael Peters]

On Mon, 14 Mar 2005 18:33:08 +0100, Christian Pernegger
<pernegger (AT) hotmail (DOT) com> wrote:

>
> Don't get me wrong, I like .ogg - I just see no point in implementing a
> portable format directly on the squeezebox.

I do.
If it used could use ogg for streaming lossy format, there is a better
chance that it would be accepted in Linux distros on the installation
CD with hackers from the distribution adding cool features (like a
gstreamer client etc.)

--
http://mpeters.us/