This is merely a suggestion for future releases.
IDEA:
- Distribute two packages for all platforms, one for source installs, one for binaries. One package would then contain Windows, Mac OS, and Linux binaries.
The combined distribution simplifies the downloads, and updates can be distributed on more sites, even as a binary on usenet for instance: SABnzbd.0.9876.5-BINARY.zip and SABnzbd.0.9876.5-SOURCE.zip
PROBLEMS:
- Text encoding may vary on platforms.
solution: use only UTF-8 and/or make sure that all files are properly (en)coded and saved.
- Total size will increase.
solution: not an actual problem, users of this program have sufficient bandwidth in general.
- Sourceforge won't allow it.
solution: the combination packages may be distributed separately in a different location.
ULTIMATELY:
- Distribute via NNTP, or add a direct download link in the web interface when a new version is available (...url/download-latest/) which will always give the user the most recent stable version for all platforms, based on the build (bin or source).
- SABnzbd.0.9876.5-BINARY
|
|_ -- WINDOWS
|_ -- MAC OS X - 10.5
|_ -- MAC OS X 10.6 + newer
|_ -- LINUX RedHat
|_ -- LINUX Ubuntu + Debian
- SABnzbd.0.9876.5-SOURCE
|
|_ -- WINDOWS (includes Python 2.9)
|_ -- MAC OS X - 10.5 (includes Python 2.4)
|_ -- MAC OS X 10.6 + newer (includes Python 2.9)
|_ -- LINUX + UNIX + BSD (includes Python 2.7)
DISTRIBUTION: Packaging and locations
Re: DISTRIBUTION: Packaging and locations
Thanks for the suggestions, but I do see a few issues.
I see no reason to combine packages.
Why would people download an oversized ZIP file and then unpack it?
Beside, we don't generate binaries for Linux. There are several people already making those.
I never come across combined distribution files for other software.
I don't understand your remark about text encoding.
Distribution over NNTP.
Be my guest
There is one catch though. Except for the OSX DMG, none of the packages are signed.
Signing Windows binaries is a rather expensive business.
I personally wouldn't ever install Windows software downloaded from Usenet.
We will be looking at auto-update at some time, although it's a complicated business
being very platform-specific and for good reasons most platforms need manual intervention.
I see no reason to combine packages.
Why would people download an oversized ZIP file and then unpack it?
Beside, we don't generate binaries for Linux. There are several people already making those.
I never come across combined distribution files for other software.
I don't understand your remark about text encoding.
Distribution over NNTP.
Be my guest
There is one catch though. Except for the OSX DMG, none of the packages are signed.
Signing Windows binaries is a rather expensive business.
I personally wouldn't ever install Windows software downloaded from Usenet.
We will be looking at auto-update at some time, although it's a complicated business
being very platform-specific and for good reasons most platforms need manual intervention.
Re: DISTRIBUTION: Packaging and locations
The actual file wouldn't be too big for most users, I think, but for Mac users it used to be common practice to do that, but then again, I am "oldtimer" when it comes to Mac OS software.shypike wrote:Thanks for the suggestions, but I do see a few issues.
I see no reason to combine packages.
Why would people download an oversized ZIP file and then unpack it?
One reason for the idea is that I use multiple systems (and have been for the last 10 years), so it would actually be just for my convenienceshypike wrote:Beside, we don't generate binaries for Linux. There are several people already making those.
I never come across combined distribution files for other software.
File encoding can cause problems in Python when using par example a French OS to create the original files. Just a single malformed or wrongly encoded character can cause a script to fail, or even worse: cause a compilation to bomb. It is rare, but I used to work for a Belgian company where most of the developers were French speaking.shypike wrote:I don't understand your remark about text encoding.
Good point. Version signing could also be built into SABnzbd, to check the integrity of the software itself upon execution, something usually done by anti-virus and anti-piracy software to protect from unwanted modifications. It is slow though.shypike wrote:Distribution over NNTP.
Be my guest
There is one catch though. Except for the OSX DMG, none of the packages are signed.
Signing Windows binaries is a rather expensive business.
I personally wouldn't ever install Windows software downloaded from Usenet.
The only response I can give here, and would most definitely instantly solve the request and all problems: Windows should be *nix based, just like all other modern computer platforms (including mobile phones, etc.)shypike wrote:We will be looking at auto-update at some time, although it's a complicated business
being very platform-specific and for good reasons most platforms need manual intervention.
Re: DISTRIBUTION: Packaging and locations
Norbertus wrote: One reason for the idea is that I use multiple systems (and have been for the last 10 years), so it would actually be just for my convenience
SABnzbd has no problem with Western-European languages, it supports ISO-8859-1.Norbertus wrote: File encoding can cause problems in Python when using par example a French OS to create the original files. Just a single malformed or wrongly encoded character can cause a script to fail, or even worse: cause a compilation to bomb. It is rare, but I used to work for a Belgian company where most of the developers were French speaking.
0.8.0 will be fully Unicode.
From our point of view (as far as distribution is concerned): Linux is a PITA.Norbertus wrote: The only response I can give here, and would most definitely instantly solve the request and all problems: Windows should be *nix based, just like all other modern computer platforms (including mobile phones, etc.)
There is so much diversity that distributing binaries is out of the question.
We're dependent on third-party packagers and the reality is that SABnzbd is distributed
through the official channels, but it's always way behind (like most non-mainstream packages).
You need a unofficial channel (like JCFP's excellent one) to keep up.
We prefer Windows and OSX, which gives us complete control over the content and
the possibility to distribute a single installer (Win) and DMG (OSX) for a wide range of OS versions.
It's not that I dislike Linux, I use Ubuntu a lot, but distribution is just too bothersome.
Re: DISTRIBUTION: Packaging and locations
Interesting... I'm starting to think that the various flavours of *nix are mainly hindered by the lack of a standard availability of Python 2.7, which forces various packages to be modified to work properly. I wonder how many 'native' executables are used in SABnzbd to overcome various problems that would be solved automatically if Python 2.7 were readily (and properly) installed.
It's the bread that is flawed in this case it seems, not the cheese.
It's the bread that is flawed in this case it seems, not the cheese.
Re: DISTRIBUTION: Packaging and locations
SABnzbd should work on Python 2.5, 2.6 and 2.7.
A problem is that various (sub-)versions of Python have various and different problems.
Even on Windows this is an issue.
We were forced to go back to Python 2.5 after complaints that SABnzbd on Python 2.7
was not stable in the long run. Likely cause: a failing garbage collector in 2.7
The quality of SABnzbd is so much dependent on the quality of the Python implementation it runs on.
More so, than when it would have been written in a truly compiled language.
A problem is that various (sub-)versions of Python have various and different problems.
Even on Windows this is an issue.
We were forced to go back to Python 2.5 after complaints that SABnzbd on Python 2.7
was not stable in the long run. Likely cause: a failing garbage collector in 2.7
The quality of SABnzbd is so much dependent on the quality of the Python implementation it runs on.
More so, than when it would have been written in a truly compiled language.