3 ms·
I will not stop repeating this: the fact that we can have multiple "brands" of the same software, possibly forked from each other, is both the strength and weak
by friendzis 11y ago
I will not stop repeating this: the fact that we can have multiple "brands" of the same software, possibly forked from each other, is both the strength and weakness of open source and we just cannot cover our eyes and pretend only mod_php exists. Open source is a community first. Quoting the same eevee:
> If two features exist, someday, someone will find a reason to use them together.
I strongly believe that if you find a valid reason to use one specific brand of software, this has to be both clearly documented and explained.
From my own experience, Ruby apps tend to be written with rather hard dependencies and are actually hell to deploy if any of the components you have preinstalled (be that process supervisor, message/job queue, web server) differ from recommended ones. Last time I needed to deploy a Rails app, I've gone down the route "bring up a new vm, secure it and deploy on that" and that was a breeze in comparison with attempts to integrate with already installed software.
- dikaiosune 11y agoRails may be a mess, but it's popular and finding a way to control the deployment is in ways a more sensible reaction than attempting to fix open source fragmentation. It's definitely a tragedy of the commons issue, but I can't blame a single team for wanting to make their product work for their users.
- nitrogen 11y agoUsing rvm makes running multiple Rails apps on one machine way easier. I only do this for development, though; for production, it's VMs or containers.
- friendzis 11y agoMy experiences (could be outdated, last time I've tried RVM was at least a year ago) are that setting up a VM is much less painful than convincing different applications to load the same environment. Your mileage may vary
- quaunaut 11y agoI won't disagree that it could be better- but doesn't this ring of pie in the sky thinking? If you're the only person who is using a thing, and you want it supported- you'll probably have to do it yourself. Now, if there are simply two features, that if used together, fail for whatever reason? That's clearly a user pitfall, and should be fixed. But to endlessly try to support the Nth scenario is unsustainable. Edit: Also, taking a look at what the author was(here: https://github.com/discourse/discourse/blob/master/docs/INSTALL-cloud.md https://github.com/discourse/discourse/blob/master/docs/INST...), no wonder they want to use a system like Docker- it's an incredibly complex, full-featured setup. This isn't one-purpose software, this is a monolithic solution, that if you want to modify, you've gotta dedicate real time and effort toward. This means that if you don't want to use defaults, you'll be constantly getting further and further away from the master project, which makes updating and maintenance so much more difficult. In which case- aren't you already signing up for the long haul, here?
- friendzis 11y agoWe have already learnt that tightly coupling components inside of application is a huge code-smell/design issue. Why is it suddenly different for multiple applications?