Hacker News Reader

Comment by chwahoo | Hacker News Reader

This was work done as part of my phd thesis. You can take the code and samples that are here https://github.com/kitsune-dsu and play with them. However, I wouldn't consider what has been released ready for production use. The papers were the main product of this research and are your best resource if you're interested: http://www.cs.umd.edu/~hayden/papers/kitsune-draft.pdf

I moved on (graduated!) from the project in 2012 and the code that has been released is pretty much where I left it at that time. An undergrad collaborator was doing neat work on updating Tor, so that code continued to evolve a bit after I left.

I think there may still be folks at UMD working in some ways with Kitsune, but I'm not up on the details.

View on HN

I was thinking using this to update our graphics software, but then I realized I need to backup GPU states (textures, for example) and recover them before and after the update.

lots of the servers are now using gpus for deep learning, may be adding gpu support to the framework is a good feature.

If such states are preserved while the process that used them is still running then there is nothing to do: They will still be available to the updated program.

I was thinking about memory mapped resources, like memory mapped io. and resource references.

maybe you are right, there might be no problem. I need to read the paper to understand better.

Yes, memory mappings should be preserved, so I can't immediately think why it wouldn't work.

Thanks for the very interesting article. One thing I didn't find very clear from the paper was the rationale of using a framework/kitsune/all that wrapper code vs just implementing the feature natively. In other words, what is the upside of using kitsune to make e.g. redis live-upgradable vs just implementing it in redis proper [I believe that e.g. redis already uses a fork model for writing the data to disk/getting a snapshot of the data]? Is it much simpler when I am using kitsune? Do I really not have to reason about what happens when the binary upgrades? Or is this mostly useful for retro-fitting the feature to software that wasn't designed with the usecase in mind?

Kitsune provides useful abstractions for modifying your program for runtime updating and tools for automating state transformation between versions of your program.

It would be entirely reasonable to implement DSU all within an app's own codebase, particularly until there's a production-ready library/tool-set. The downside would be that you'd probably end up re-implementing a lot of what Kitsune provides.

For our purposes (evaluating Kitsune-style updating on a variety of server programs), it made sense that we'd want to have a common toolset that we applied to all of the programs.

Reply on news.ycombinator.com