PDA

View Full Version : "EMPTY" when browsing



Patrick Dixon
2005-04-04, 01:21
I don't actually think the majority here are 'negative' (but I do think Phillip Kerman made some very good points).

Personally I'm very happy to test and help get the bugs out in the interests of making a better product, but I'm never quite sure if my unfamiliarily with Perl, Java and Linux is a help or a hinderance in that process! (I do figure that if I have a problem with a Windows version, then probably the 'average' user will too - so that's got to be useful). I also understand (from personal experience) the problems of software and hardware product development, and the pressures on small companies in a competitive marketplace.

A couple of things do worry me though, and they are probably a result of my unfamilirity with Perl and the open-source community. I wonder whether the choice of Perl is now causing many of the 'resource hogging' problems that seem to be at the root of many of the complaints. As the size and complexity of the code has increased, is the overhead of an interpreted language just too much? The other thing that worries me is the structure and documentation of the code itself. I know (again from personal experience) that when the pressure's on, dotting 'i's and crossing 't's is the first thing to go, and (to me) Perl looks very terse and unstuctured anyway. That can't make it easy to develop and maintain.

Forgive me if I'm speaking out of turn, but I do appreciate the effort that's being put in, and I hope I am helping rather than hindering that effort.

Patrick

-----Original Message-----
From: discuss-bounces (AT) lists (DOT) slimdevices.com
[mailto:discuss-bounces (AT) lists (DOT) slimdevices.com]On Behalf Of kdf
Sent: 04 April 2005 08:10
To: Slim Devices Discussion
Subject: [slim] "EMPTY" when browsing


Quoting Michael Bowyer <mbowyer (AT) mac (DOT) com>:

> >Please try the latest nightly - either 6.0.1 or 6.1 - this should be fixed
> there.
> >
> >-D
>
>
> I've patiently waited weeks for the new version 6. Not even a week after its
> release and we're back to 'try the latest nightly'. Excellent!
>



so don't use it. go back and join the crowd who refuse to test. your other
option is to wait months until someone else with a more constructive frame of
mind takes the time to test and it gets fixed.

Personally, I've become sickened by the negative attitudes here.

-kdf

Steven Moore
2005-04-04, 08:06
On 4 Apr 2005, at 9:21 am, Patrick Dixon wrote:

> I don't actually think the majority here are 'negative' (but I do
> think Phillip Kerman made some very good points).
>
> Personally I'm very happy to test and help get the bugs out in the
> interests of making a better product, but I'm never quite sure if my
> unfamiliarily with Perl, Java and Linux is a help or a hinderance in
> that process! (I do figure that if I have a problem with a Windows
> version, then probably the 'average' user will too - so that's got to
> be useful). I also understand (from personal experience) the problems
> of software and hardware product development, and the pressures on
> small companies in a competitive marketplace.
>
> A couple of things do worry me though, and they are probably a result
> of my unfamilirity with Perl and the open-source community. I wonder
> whether the choice of Perl is now causing many of the 'resource
> hogging' problems that seem to be at the root of many of the
> complaints. As the size and complexity of the code has increased, is
> the overhead of an interpreted language just too much? The other
> thing that worries me is the structure and

Now this may be a stupid question so feel free to shout at me.
If Perl is an interpreted language is there anyway that it the server
software could be compiled for each platform for increased performance?

Steven Moore

> documentation of the code itself. I know (again from personal
> experience) that when the pressure's on, dotting 'i's and crossing
> 't's is the first thing to go, and (to me) Perl looks very terse and
> unstuctured anyway. That can't make it easy to develop and maintain.
>
> Forgive me if I'm speaking out of turn, but I do appreciate the effort
> that's being put in, and I hope I am helping rather than hindering
> that effort.
>
> Patrick
>
> -----Original Message-----
> From: discuss-bounces (AT) lists (DOT) slimdevices.com
> [mailto:discuss-bounces (AT) lists (DOT) slimdevices.com]On Behalf Of kdf
> Sent: 04 April 2005 08:10
> To: Slim Devices Discussion
> Subject: [slim] "EMPTY" when browsing
>
>
> Quoting Michael Bowyer <mbowyer (AT) mac (DOT) com>:
>
>>> Please try the latest nightly - either 6.0.1 or 6.1 - this should be
>>> fixed
>> there.
>>>
>>> -D
>>
>>
>> I've patiently waited weeks for the new version 6. Not even a week
>> after its
>> release and we're back to 'try the latest nightly'. Excellent!
>>
>
>
>
> so don't use it. go back and join the crowd who refuse to test.
> your other
> option is to wait months until someone else with a more constructive
> frame of
> mind takes the time to test and it gets fixed.
>
> Personally, I've become sickened by the negative attitudes here.
>
> -kdf
>

Jack Coates
2005-04-04, 08:45
Patrick Dixon wrote:
> A couple of things do worry me though, and they are probably a result of my unfamilirity with Perl and the open-source community. I wonder whether the choice of Perl is now causing many of the 'resource hogging' problems that seem to be at the root of many of the complaints. As the size and complexity of the code has increased, is the overhead of an interpreted language just too much? The other thing that worries me is the structure and documentation of the code itself. I know (again from personal experience) that when the pressure's on, dotting 'i's and crossing 't's is the first thing to go, and (to me) Perl looks very terse and unstuctured anyway. That can't make it easy to develop and maintain.
>

Nah. Remember what incredible overkill today's system is, and remember
that all three target OS's are pretty good at multi-tasking. The CPU/RAM
overhead of interpreted language is absolutely nothing.

One thing to realize is that rewriting the source code, test suite, and
build environment from the ground up in cross-platform code written in a
low-level compiled language is a big project. Like, hire three
engineers, buy a couple of servers and estimate 12-18 months from start
to the present level of stability. You think switching meta-data storage
backends destabilized the system? Ha. Then add in the joy of low-level
memory management and security holes galore because the low-level
compiled language expects the programmer to take care of all that.

Cross-platform interpreted languages are a Good Thing(TM). Perl is a
good thing. More importantly, ditching everything and rebuilding from
scratch is a Bad Thing(TM).

I've worked with and sold much buggier products than this one, lighten
up folks. You're getting what you paid for and a lot more. Bugs are part
of the territory.

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

Jack Coates
2005-04-04, 09:00
Steven Moore wrote:
> ...
> Now this may be a stupid question so feel free to shout at me.
> If Perl is an interpreted language is there anyway that it the server
> software could be compiled for each platform for increased performance?
>
> Steven Moore
>
....

"there are no stupid questions, just a lot of inquisitive idiots" :)
Sorry, couldn't help it. Anyway, no. There are some products out there
that claim to compile Perl, but most are probably doing the same
embedded-interpreter trick that Slim already does in the Win32
executable. Besides, thouse products usually require licensing that is
incompatible with open-sourcing and giving away the server.

It's highly questionable whether performance would even improve... IMHO,
the bottleneck at this point is single-threading, not interpretation. Of
course, if someone around here knows C++ and wants to prove me wrong,
I'm all ears :) This guy
(http://lists.slimdevices.com/archives/developers/2004-September/010419.html)
might have some tips for you.

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

Pat Farrell
2005-04-04, 09:13
On Mon, 2005-04-04 at 16:06 +0100, Steven Moore wrote:
> Now this may be a stupid question so feel free to shout at me.
> If Perl is an interpreted language is there anyway that it the server
> software could be compiled for each platform for increased performance?

any way at all? sure. But it is unlikely to yield the performance
bump you would hope for even if it was easy. It is more
cost effective to just upgrade the computer.

First, being interpreted does not mean "slower than compiled"
as many modern languages are interpreted and then optimized.

Second, you can't optimize performance without looking
at what is slow. The SlimServer doesn't do a lot of
complex calculations, it mostly reads files and pushes
out the bytes. And it deals with generating and displaying
HTML and getting responses from the user. Any time you
go to the disk, main processing performance ceases to
be an issue. Similarly, any time you talk to
the ethernet, main CPU is not the gating factor.
More importantly, any time you talk to
a human, the computer has nothing to do for nearly forever.

Third, a fair amount of the SlimServer performance "issues"
are due to the code's monolithic structure. To solve these,
the code will have to be refactored, which is a bigger
development effort than even the 6.* release. The developers
are talking about this, but it will be big and painful,
probably no sooner than version 7.*

I ran my slimserver 5.* on a P2 500 for several years
without problems. I replaced it with a 2800+ just
because today, the 2800+ is about as cheap and slow
as you can get. With Moore's law, new processors
get cheaper and faster much more easily than
refactoring software.


--
Pat
http://www.pfarrell.com/music/slimserver/slimsoftware.html