Slashdot Mirror
Online Patching Systems?
Master_Flash asks: "My company is preparing to distribute an online Windows application that will change over time (don't they all?). We been evaluating online patch systems. There are a number of commercial
applications out there. Some look good: RTPatch from PocketSoft, ASTA Binary Patcher, and Necromancer's FlashUpdate. Has anyone had a positive experience with these or other applications? One other idea we had was to use CVS as a patching system. While CVS isn't technically a binary patch it does a great job at checking on which files need to be updated. Most of the files we have are small and change infrequently, so CVS could work. Opinions and guidance are welcome."
CVS is overly bandwidth and cpu-intensive both client-side and server side. I believe that there are various forks of it which are more efficent.
But, I digress. CVS was not designed for this. Rsync was designed almost percisely for something like this. It only transferres the parts of the file which have been modified, and compresses it as well.
But, why not simply use installshield or a similar tool like all other windows developers and just release periodic updates (which fits the model for windows software, which, IMO is quite diferent than the linux model (make many releases and many patches, while windows and MAC lean twoard making a few periodic releases, only patching where there is a severe flaw).
I'm not saying that one model is any better, i'm just saying that you need to keep consistancy.
-- If you try to fail and succeed, which have you done? - Uli's moose
I'm not erally sure if it's helpful or not as I haven't read much of it, but I'll post a quote out of it
The government installation at which I work will soon deploy Patchlink, mainly for security updates. However, since it hasn't happened yet, I can't offer you any feedback. There are links to some ROI studies on their website.
I hold it, that a little rebellion, now and then, is a good thing. -- Thomas Jefferson
My company is preparing to distribute an online Windows application that will change over time (don't they all?).
First question is; What is an online Windows application? Is this a web application or a Windows application? Or is it some totally new type of application?
The second thing is that, while bugs are inevitable and patches will almost certainly be a fact of life, are you sure that this appication is really as ready and as thoroughly tested as it could be? Or is this another rush to market job that is already a week overdue? If the application isn't really ready, wouldn't it be better to concentrate on improvements and bugfixes rather than patch managers and pushing it onto the poor unsuspecting users.
For windows env I would use MSI technology. MSP can be used to deply patches. Wise has lot of good easy to use applications designed for deployment of MSIs and MSPs.
Consensus is good, but informed dictatorship is better
If it's online, wouldn't java webstart do the trick? :D
Anyway another obvious way is for the server to push updates to the client when the admin approves it (like Domino/notes does).
Or have a central ressource and the client checks for updates (like Azureus).
Basically the best way is making it easy on bandwith, for admins and for users - the domino/notes approach does this (set up on server, approve, client gets notify to update - a few tricks are pushed to the client, client restarts and voila new version).
Anyway, the 'thing' you are building will dictate what kind of system you should use. Just don't expect a corporate admin to go around 200 machines on foot because you made some kind of lame updater which only works with admin privs, because they simply wont, instead they'll push for "the better version from company Y".
it's cryptic, confusing, and apparently making a stab in the dark at witty and insightful! it's everything slashdot has been aspiring for over the years!
(p.s. -- huh? does this make as much sense to everyone else, or am I just a nitwit?)
So are any other platforms viable alternatives?
Mac has less than 2% of the market.
Linux has less than 3% of the market.
If you somehow feel that anybody could sell a commercial product on those platforms - and make a profit, do tell. Otherwise, shut the fuck up. For non-critical systems, people don't want to change the platform that they work on. You want to sell to the largest possible market. And right now that means Windows.
Windows is everywhere, hence Windows applications run everywhere. It is the de-facto choice for commercial application development and deployment.
And let's not get into the problems of deployment and prerequisites on Linux machines. Available libraries, kernel version, staticly linked or not, version of Glibc - not to mention the general hatred of the commercial software world means that (in my experiences) a Linux zealot would rather pirate any commercial software that makes it to their platform rather than pay for it.
Just because Uncle Bob has never heard of a firewall and his Windows 98 box is beyond repair - does not mean that Windows isn't a viable platform. I use Windows 2000 daily. By using some basic common sense, staying away from Outlook, installing a hardware firewall - the last virus I had was for DOS - more than 10 years ago.
I wouldn't run a Linux machine without a hardware firewall. I also wouldn't run unnecessary services. The same rules apply to Windows. And makes them equally secure.
Just do it the best way history has shown how: send out "Critical Windows Update Patch" emails...
I've used it before, it works really well.
It can be a little slow to generate the patches (I found that having 2 physical hard disks helped, 1 for input and 1 for output) but the resultant patch is quite optimized.
The tools are perhaps a little old feeling, with scripts and command line compilation tools, but on the whole the product works really well.
Forgive me-- if the audience for your application is strictly home users, then disregard everything I say below. If, however, your audience includes corporate LAN's, listen the fuck up.
I shudder every time I hear an app. manufacturer talking about their "innovative" online patch delivery systems. Frequently, "innovative" online patch delivery systems cover up for shitty software QA.
I am a network administsrator. I have to keep PC's, servers, and the applications running therein working properly. I have a lab. I test patches in that lab. I make sure that things continue to work. I don't want you to patch your fucking app without going thru me.
It's a 'doze application. Package the application as an MSI. Expect that it will be deployed with IntelliMirror. Issue MSP's when you need to patch the application. Problem solved.
The Attitude Adjuster, I hate me, you can too.
rsync.samba.org
I made a very simple live update system way back. It involved having all the latest files on a network share. Quite simply, every time the application was launched it would check that share for any files newer than its own and copy them over (thanks to a 30kbyte stub loader). Result: anyone who used my software was assured to have the latest version, and as a bonus if they were using it and it crashed, chances are they'd get a fix when they tried to reload it :)
:) Damned easy to code too.
I later used a variation on that scheme that involved a cron job on the server, checking regularly for new commits to the shared folder. It would then calculate windowed hashes of each file and the client update app would simply compare the server's hashes with its own (cached) hashes. This enabled me to minimize download times since it would only download the chunks that had been changed (in the case of large data heaps). It's not foolproof since I didn't do any insert/delete logic (add 1 byte to the beginning of the file and the rest is immediately invalidated)... but it was simple enough to justify the occasional forethought when releasing updates. It's like a castrated embedded version of rsync
Considering the hell I've been thorugh with RTPatch and its ever-flaky software, it would be well worth writing my own smart binary diff (with proper shuffling detection and compression). These things really aren't that complicated to implement and the advantage of rolling your own is that you can include extra logic tailored for your application (or for that particular client).
-Billco, Fnarg.com
We use InstallShield at the company I work for. Just build your initial installation as an MSI (Windows Installer) package and either release subsequent MSI's to either install or upgrade or release a MSP which will patch the software that is already installed. You can try to figure out a "better" way, but really, Windows Installer is what pretty much every Windows user is used to.
1. Marimba Castanet (I know, I love to hate them, too) has a technology that provides auto-updates to files on a box, and can even be scripted to stop and restart the process. I have used this and while it is expensive, somewhat complex internally, and a bit slow, it does work, and is highly scalable to 10,000+ boxes quite easily.
2. Rsync (a very common open-source Samba project) will synchronize files across a network, sending only the file differences, handling file deletion if so requested, etc. Very, Very good product, widely used. Set this up with any *nix (Linux, Solaris, etc.). Or, for Windows, configure Cygwin to run cron as a service, and have a rsync run as a crontab entry.
If you need to reboot, have the synchronizer write a "DoRebootNow.txt" file with the box's name in it. The service watches the file and looks for its own box name, and if found, does a reboot and does a cgi post to a cgi that removes the boxname from that file.
Cumbersome in parts, either of these systems can work for you very reliably and effectively. I would estimate both jobs at between 1 and 2 weeks of labor, including writing the scripting or learning about Castanet. That depends of course on testing requirements, method of deployment to clients, etc. Some large installations could take a person-month just to install all the clients on the boxes!
Also, I've heard of SMS, but I don't know much about it. Sorry...
-- KevinJRice
Unitarian Church: Freethinkers Congregate!
Port blocking is RAMPANT now.
It *has* to work over either port 80 or 443, or it is a non-viable option. Period.
I'd go with xdelta or rsync, compiled/configured for port 443, and a good web frontend.
Before I part with'em: two pennies weigh ~4.996+/-0.014g, have a zinc core, and the face of Lincoln. You can keep 'em.
I hope I'm not breaking my NDA.
For the MMORPG Horizons, we first looked at RTPatch, then we looked at RSYNC. We actually implemented both in dev, and went through most of beta with RTPatch. We eventually wrote our own, and I would recommend the same to you.
Artifact's was pretty simple, no binary patching of files, just straight overwrites. Checks by file date first, then checksum if there are problems with the dates. I no longer work for Artifact Entertainment, Inc.
You also may want to put more research into the MSI's. Be sure to check out msi2xml on sf.net.
Intelligence is a matter of opinion.