2. Frequently unstable software. I appreciate that the dev team works so hard, but they just don't have the resources they need for proper testing. (and aren't long on the charisma necessary to recruit new testers... at one point, I was kind of trying to volunteer as a tester, and got chased off.) 3. The website says 'use the the stable build, the nightlies are dangerous', when in actual fact, that's exactly backwards. The devs think that 'stable' means 'code that isn't changing' -- whether or not it actually works. They left up a completely broken release for about two weeks. When I complained, I was told it was 'stable' code, and thus shouldn't be changed. It didn't work -- it couldn't work -- but it was 'stable', so they didn't fix it for ages. Anyone downloading the software in that window (I think this was the first release of 6.3.0) simply would not have a working server. From my perspective, that's a customer relations disaster. If it's broken and you can't fix it immediately, pull it and put the old one up. Most folks think of 'stable' code as an implied promise that the program will work. Knowingly putting them through pain and frustration is extremely bad customer service.
I agree with these points.
4. Perl. The existing server is written in Perl, and it's slow. It's fine on a big machine -- I run it on a dual core Linux server, and it's very quick -- but it's sluggish on small boxes. That means you can't easily put out an NSLU3 with the server built right in. (The NSLU2 does run SlimServer, but it's very slow. 6.5 may be better, but 6.2.X was glacial.) That said, however, there is a huge pile of work in that code, and it's not something that should lightly be abandoned. The CUE/FLAC logic was particularly hard to work out, judging from the number of odd little buglets I've seen over the years.
This would be correct if the NSLU2 was an advertised build target -- you're essentially complaining that you bought a Jaguar V12 and had a lot of trouble fitting it into your Chevy Sprint :) More to the point, Perl's problems for that platform are caused by it's being a high-level, cross-platform language, and any other high-level, cross-platform language you'd care to rewrite in will have the same problems. The cost of doing cross-platform C is pretty high, so then cross-platform goes out the window, along with a very large portion of the customers. A lot of people complain about Perl without any foundation for doing so, which alienates the developers, causing the attitude you complain about, and obscures any real issues which Perl may or may not have. As the development platform for Slimserver, the only problem I can really see with Perl is its history: a lot of people learned Perl as their first language, blamed all their mistakes on it, and moved on to something else while badmouthing Perl to the skies. ... -- "I spent all me tin with the ladies drinking gin, So across the Western ocean I must wander" -- traditional _______________________________________________ discuss mailing list [email protected] http://lists.slimdevices.com/lists/listinfo/discuss
