<?xml version="1.0" encoding="utf-8" standalone="yes"?><rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom" xmlns:content="http://purl.org/rss/1.0/modules/content/"><channel><title>Virtualization on katzir.xyz</title><link>https://katzir.xyz/tags/virtualization/</link><description>Recent content in Virtualization on katzir.xyz</description><generator>Hugo</generator><language>en</language><lastBuildDate>Sun, 12 Jul 2026 15:47:42 -0400</lastBuildDate><atom:link href="https://katzir.xyz/tags/virtualization/index.xml" rel="self" type="application/rss+xml"/><item><title>Keeping Old Software Alive</title><link>https://katzir.xyz/posts/keeping-old-software-alive/</link><pubDate>Sun, 12 Jul 2026 15:47:42 -0400</pubDate><guid>https://katzir.xyz/posts/keeping-old-software-alive/</guid><description>&lt;p&gt;Recently I set up Azure Virtual Desktop on Windows LTSC to support a small set of older applications we still need from time to time. It was the kind of project that looks, at first glance, like a straightforward compatibility exercise, but in practice it turned into a useful reminder of how much institutional computing is really about continuity.&lt;/p&gt;
&lt;p&gt;The problem was familiar enough. We have a few applications that are still needed for specific workflows, but which do not fit neatly into the present-day desktop environment. They are not important enough to justify a full modernization project, but they are also not obsolete enough to disappear. They occupy that awkward middle ground familiar to anyone who works in higher-ed IT: software that is technically legacy, operationally necessary, and politically difficult to retire.&lt;/p&gt;</description></item></channel></rss>