4 ms·

Zulip is quite amazing and I really like the product, however I somewhat dislike that the installer is a complete machine take over with many hard-coded paths.

Zulip is quite amazing and I really like the product, however I somewhat dislike that the installer is a complete machine take over with many hard-coded paths. Supporting only Ubuntu releases is one thing, but the code base actively fights installing it on anything else but the supported distributions (ubuntu). At which point, why even have a installer, just ship an image. Since Zulip has so many moving components, I would love to see it be installed with something like Nix. Doing so would allow it to be installed in a consistent way across many different OSes, and decouple your reliance on software provided by the OS. It would also make upgrades seamless. You can install nix on any single linux distribution, not just nixos, and since your installer already hard requires running as root, you can install nix and then install zulip in nix.

tabbott 7y ago
We've supported Debian in production since 2018, and we're close to supporting RHEL as well. And even if we only supported Ubuntu, there's a lot of benefit to providing an installer that works on every Ubuntu LTS release; most larger organizations have additional monitoring/security/backups/etc. software they want to run on every system they manage, and to make their own decisions about when to move their organization to newer major OS releases. You can also use our Docker image if you want that, but a lot of organizations don't :). I wouldn't say the installer is actually a complete machine takeover; we're pretty cautious about using the system versions of dependencies shipped by the OS vendor. But we do __document__ that you should treat it as one, mainly for support reasons. The support experience that we currently provide is that where possible we respond to, investigate, and debug all reports of issues installing Zulip, with the goal of making it Just Work (this includes working to give nice error messages for common user errors). Before we added those warnings in our documentation, we got tons of reports from users who were trying to do things like install Zulip in a shared hosting environment with other software that doesn't expect to share its database (etc.) with something else, and where they don't have root access. Also, investigation often determined the system in question had low RAM/disk resource limits from the shared hosting environment that meant running Zulip on that system wasn't going to work in any case. At one time, that sort of shared hosting setup accounted for the majority of reports from folks having issues installing Zulip. Investigating those reports was a huge waste of time for our development community. We solved that problem by making our documentation recommend installing Zulip on a dedicated system. This also provides a lot of benefit in terms of our being able to do things like tune the configuration for postgres and memcached to allocate resources in an appropriate way for a Zulip installation with the system's RAM allocation. There is occasionally discussion in the community of adjusting our approach here, but given how easy it is to get a VM or container these days, we're currently happy with guiding users to the dedicated VM/container path that we can guarantee works ~100% of the time and provide a great installation experience.

tabbott 7y ago

We've supported Debian in production since 2018, and we're close to supporting RHEL as well. And even if we only supported Ubuntu, there's a lot of benefit to providing an installer that works on every Ubuntu LTS release; most larger organizations have additional monitoring/security/backups/etc. software they want to run on every system they manage, and to make their own decisions about when to move their organization to newer major OS releases. You can also use our Docker image if you want that, but a lot of organizations don't :). I wouldn't say the installer is actually a complete machine takeover; we're pretty cautious about using the system versions of dependencies shipped by the OS vendor. But we do __document__ that you should treat it as one, mainly for support reasons. The support experience that we currently provide is that where possible we respond to, investigate, and debug all reports of issues installing Zulip, with the goal of making it Just Work (this includes working to give nice error messages for common user errors). Before we added those warnings in our documentation, we got tons of reports from users who were trying to do things like install Zulip in a shared hosting environment with other software that doesn't expect to share its database (etc.) with something else, and where they don't have root access. Also, investigation often determined the system in question had low RAM/disk resource limits from the shared hosting environment that meant running Zulip on that system wasn't going to work in any case. At one time, that sort of shared hosting setup accounted for the majority of reports from folks having issues installing Zulip. Investigating those reports was a huge waste of time for our development community. We solved that problem by making our documentation recommend installing Zulip on a dedicated system. This also provides a lot of benefit in terms of our being able to do things like tune the configuration for postgres and memcached to allocate resources in an appropriate way for a Zulip installation with the system's RAM allocation. There is occasionally discussion in the community of adjusting our approach here, but given how easy it is to get a VM or container these days, we're currently happy with guiding users to the dedicated VM/container path that we can guarantee works ~100% of the time and provide a great installation experience.