3 ms·
This has got to be the most complicated packaging system ever invented. And I thought .deb was complicated. Just in order to use Omaha, you need: - A non-Expr
by kijin 13y ago
This has got to be the most complicated packaging system ever invented. And I thought .deb was complicated.
Just in order to use Omaha, you need:
- A non-Express (i.e. paid) version of Visual Studio
- Python
- Scons
- Set a bunch of environment variables, because who needs configuration files?
- kevingadd 13y agoOnly works with Python 2.4, too. Gross.
- rectangletangle 13y agoWhat's preventing it from running on more modern versions of Python, like 2.7?
- biggerfisch 13y agoI've noticed this kind of thing with lots of Google products actually - they're often written for downright ancient versions of python and can be a nightmare to get working with modern pythons. Any clue as why this is?
- rbanffy 13y ago> Any clue as why this is? Lack of clues is always a possible explanation. Some people also want to make sure their software runs on RHEL 5.
- sillysaurus3 13y agoThat's not complicated for Windows dev. Windows devs are used to a bunch of configuration, because they grew up with it. Besides, those steps are easy to follow, and can be done quickly. Setting environment variables is as easy as writing a .cmd file that sets them for you. Most devs have Python installed. Installing Scons is easy. A paid version of VS can be easily pirated if you don't feel like paying for it. This isn't by accident: MS would rather you be writing Windows software than non-Windows software. And if you're writing software to sell, then a license isn't costly: https://www.google.com/shopping/product/7152061321388788226 https://www.google.com/shopping/product/7152061321388788226
- stingraycharles 13y agoI understand what you're saying, but it simply is not an excuse. The whole point of this tool is to make installing and updating packages easier, but at the same time they have one of the most complicated installation instructions for a standalone software package ever. That is something that makes me wonder how much they really care about simplifying the workflow of installing and updating packages.
- sillysaurus3 13y agoHm. There's a Stack Overflow link elsewhere in the thread... In it, someone reported they were able to set up Omaha and have it continue to work for over a year without needing to touch it once. That's pretty solid. http://stackoverflow.com/questions/3711435/what-is-the-experience-with-google-omaha-their-auto-update-engine-for-chrome http://stackoverflow.com/questions/3711435/what-is-the-exper... Are you sure a day or two of work in exchange for over a year of solid deployment isn't a good exchange? If it isn't, then which alternative would you recommend in order to get similar efficiency?
- kijin 13y agoNot sure who downvoted your GGP comment, you did have a valid point. Nonetheless, I think there's hardly ever a justification for asking other people to perform "a day or two" of work to set up something, even in exchange for years of solid deployment. A day or two, multiplied by thousands of Windows developers, adds up to several man-years of entirely avoidable work. Entirely avoidable, because it's Google's job, not ours, to package up this Omaha thingy into a neat binary with a neat API that any project can easily use. It's not too difficult to ship a single binary (or collection of binaries) that will work out of the box on every Windows Vista/7/8 PC, with the only dependencies being the Win32 API, vcredist, and perhaps a recent version of .NET Framework. Wrap it all up in an .msi and you're good to go. No need to tell a C# developer, for example, to meddle with Visual C++ or Python. If the Omaha devs can spend a few weeks to make the setup process as simple as that, now that would have a real chance of adoption.
- 13y ago
- voltagex_ 13y agoMaybe https://github.com/vslavik/winsparkle https://github.com/vslavik/winsparkle instead?