Home of the Squeezebox™ & Transporter® network music players.
Page 2 of 2 FirstFirst 12
Results 11 to 18 of 18
  1. #11
    jvromans@squirrel.nl
    Guest

    How my BBC Sounds Plugin briefly broke LMS. Acautionary tale!

    On Tue, 27 Apr 2021 16:50:59 +0000, pputzer wrote:

    > LMS on Synology is dead for all practical purposes. (Long live Docker!)


    Well, given that many Synology models that were running LMS cannot support
    Docker I don't think this is reason for chearing...

    -- Johan

  2. #12
    jvromans@squirrel.nl
    Guest

    How my BBC Sounds Plugin briefly broke LMS. Acautionary tale!

    On Tue, 27 Apr 2021 20:13:54 +0000, philippe_44 wrote:

    > I agree that using
    > the stock Perl woudl often be better but at the same time, there is no
    > army of testers for LMS that can verify every permutation and
    > combination of Perl version and OS, so we are really on thin air here.


    Yes. Partly.

    Every change that is made to LMS can potentially cause breakage on some
    weird combination of hardware and software but that doesn't withhold us
    from continuing active development.

    But let's get real. The downloads on the official site are for
    Debian/Ubuntu, Windows and MacOS. There are kits for RPM based systems and
    a source tar. Users that go the way of the source tar may be expected to
    know what they are doing. The other users may expect an out of the box
    functional install.

    However, most importantly, users should NOT expect to run a bleeding edge
    LMS on an ancient/obsolete platform.

    Officially (supported) Debian systems are Stretch and Buster. Stretch comes
    with perl 5.24 and Buster comes with 5.28. So it is reasonable to drop
    everything older than 5.24.

    All perl modules currently privately included in LMS should be examined and
    replaced by current CPAN versions if necessary, but preferrably use the
    distro packages instead. (See my other mail.)

    Assume LMS 10 would be a breaking new version. If the current 8.x do not
    automatically update I do not foresee big problems.

    -- Johan


  3. #13
    Senior Member
    Join Date
    Feb 2007
    Posts
    142
    Quote Originally Posted by philippe_44 View Post
    I agree that using the stock Perl woudl often be better but at the same time, there is no army of testers for LMS that can verify every permutation and combination of Perl version and OS, so we are really on thin air here.
    Thorough automated testing would seem to be the solution, but writing those tests would be unglamorous work for which it could be difficult to find volunteers.

  4. #14
    Senior Member
    Join Date
    Feb 2007
    Posts
    142
    Quote Originally Posted by jvromans@squirrel.nl View Post
    If LMS would fit nicely in the ecosystem I think many relevant Linux distros
    will include LMS by default, making it much easier for people to start
    using LMS.
    The other sticking point for including LMS in Linux distributions is the firmware for hardware players, which is not permitted to be redistributed. That said, it hasn't updated for a long time, so maybe dropping it from the packages wouldn't be much of an issue.

  5. #15
    jvromans@squirrel.nl
    Guest

    How my BBC Sounds Plugin briefly broke LMS. Acautionary tale!

    On Wed, 28 Apr 2021 12:16:23 +0000, mavit
    <mavit.a0tf7z (AT) no-mx (DOT) forums.slimdevices.com> wrote:

    > The other sticking point for including LMS in Linux distributions is the
    > firmware for hardware players, which is not permitted to be
    > redistributed. That said, it hasn't updated for a long time, so maybe
    > dropping it from the packages wouldn't be much of an issue.


    The firmware can always be put in a separate package, or downloaded on
    demand. Fedora has special repositories for non-free software.

    Reading the paragraph about the firmware:

    > Squeezebox firmare may not be redistributed under any circumstances. It
    > is(c) Slim Devices, and additonally contains code which is (c) Ubicom.
    > Ubicom's code is licenced to us only for direct distribution in binary
    > form. You may use the firmware only on hardware manufactured by Slim
    > Devices.


    There is a lot of firmware licenced similarly in the Fedora distribution
    (e.g. firmware for WiFi devices). So I don't think this should be a
    blocking problem.

    -- Johan

  6. #16
    Babelfish's Best Boy mherger's Avatar
    Join Date
    Apr 2005
    Location
    Switzerland
    Posts
    20,569

    How my BBC Sounds Plugin briefly broke LMS. Acautionary tale!

    I would absolutely agree that platform support is becoming a bit long in
    the tooth. Not only for the many combinations of OS/CPU/Perl versions.
    But eg. for Windows and macOS, too!

    - Windows: we're using ActiveState Perl Development Kit's (PDK) PerlApp
    and siblings, based on ActivePerl 5.14. ActiveState recommends to NOT
    use the PDK any more. They actually suggest applications should be run
    using Docker. Which IMHO isn't an option for us on Windows (yet).

    - macOS has long stuck with Perl 5.18. Only in Mojave they installed
    5.28. On Big Sur we have 5.30 in addition to the previous two. With
    Apple's switch to the M1 CPU we're additionally facing the fact that we
    don't have the platform support yet. I tried to build dependencies for
    5.30 on M1 but failed (so far).

    - macOS and Windows come with some additional tools, like a tray bar, or
    the preference pane. In particular the macOS PrefPane is in dire need of
    some love: I'm still running builds in a MacOS 10.5(!) VM using the old
    XCode from back then, because newer version wouldn't compile any more...

    - Linux: much discussed dependency hell.

    So there's much more work than I can handle. And as long as things run...

    > Officially (supported) Debian systems are Stretch and Buster. Stretch comes
    > with perl 5.24 and Buster comes with 5.28. So it is reasonable to drop
    > everything older than 5.24.


    It's not that easy. Some platforms aren't as well supported as the Pi,
    and updates come in slower. Even NAS vendors tend to update slowly.
    People keep their NAS around for years. Yes, we can drop them, and I'm
    trying to get people to use a Pi instead. But for many this still is
    "too techy". I'm looking forward to seeing PolyVection's offering.

    Anyway: the good news is that nothing stops you and/or other community
    members from coming up with new build scripts, or package definitions or
    whatever they're called, to create a lean .deb package fully relying on
    external dependencies. It looks as if somebody had done it for NixOS
    (see https://github.com/Logitech/slimserver/issues/138).

    I'd be happy to provide such a "clean" .deb package in addition to
    today's offerings - it could replace the old builds in the longer term.
    But I can't handle it. If you want LMS to change the way you're so vocal
    about, then you'll have to get your hands dirty. As of today there are
    only a few contributors to LMS itself, and they concentrate on core
    functionality.

    > Assume LMS 10 would be a breaking new version. If the current 8.x do not
    > automatically update I do not foresee big problems.


    FWIW: it's very unlikely there will ever be a LMS 10. As with Windows 9,
    that number has been burnt in other ways. The "UE Media Library",
    supporting the UE Smart Radio, internally used that version number. But
    then, maybe by the time we get to v10 UEML is history, and nothing is
    left from it. By the current pace of major updates it won't happen in
    this decade anyway :-D

  7. #17
    Babelfish's Best Boy mherger's Avatar
    Join Date
    Apr 2005
    Location
    Switzerland
    Posts
    20,569

    How my BBC Sounds Plugin briefly broke LMS. Acautionary tale!

    >> The other sticking point for including LMS in Linux distributions is the
    >> firmware for hardware players, which is not permitted to be
    >> redistributed. That said, it hasn't updated for a long time, so maybe
    >> dropping it from the packages wouldn't be much of an issue.

    >
    > The firmware can always be put in a separate package, or downloaded on
    > demand. Fedora has special repositories for non-free software.


    Unless I'm wrong it actually would be downloaded on demand if needed.
    But as mavit said: considering how old these are, it's hard to imagine
    anybody still got a device which hasn't been updated yet!

    I should put removal of the firmwares on my todo list.

  8. #18
    jvromans@squirrel.nl
    Guest

    How my BBC Sounds Plugin briefly broke LMS. Acautionary tale!

    On Wed, 28 Apr 2021 12:06:27 +0000, mavit wrote:

    > Thorough automated testing would seem to be the solution, but writing
    > those tests would be unglamorous work for which it could be difficult to
    > find volunteers.


    This may sound surprising, but I think using stock perl and current CPAN
    modules will LESSEN the chances of something breaking. Many software
    products rely on perl and CPAN and you may consider these thouroughly
    tested.

    Also, currently there is little testing but running LMS by the developers
    themselves.

    -- Johan

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •