I love playing with my mirrorless camera and lenses, but I'm becoming more and more convinced that it's a risky proposition "investing" in a bunch of expensive camera gear (which traditionally holds it's value better than most gadgets) when computational methods will soon evaporate the advantages of bigger sensors / faster glass.
You might look at youtube red, which is included with the google music streaming service. Will let you download videos to your mobile device for offline viewing. Combined with your youtube "to watch" list, it works pretty well. Unfortunately doesn't support an "add on desktop -> auto download mobile" workflow.
You're misreading. Everyone they hire is intended to be a leader, and being right is one of the qualities they care about in employees. Not "management is usually right, so trust them".
This happened to a lot of people in the Valley after the dot com bust. They exercised their options, triggering a tax liability, and then the shares tanked, leaving them with no money to pay off the liability. They could only deduct $3000/year. Lots of people were in a lot of trouble, but I remember hearing that finally the IRS made a change so that this wouldn't affect you anymore.
You should be able to deduct the loss, but I'm not sure how that plays with the tax owed, since the loss is a capital loss and you're paying tax on an object of specific value (not a capital gain). It might not simply cancel out.
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.
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.
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.
To add: The number of changes tends to be very small, as reported in the paper. We are talking 100-300 LOC even for applications that are 100 KLOC. And these changes are robust in the sense that once you retrofit to include them, you rarely need to make further changes of that sort -- new versions will just work.
