<?xml version="1.0" encoding="utf-8" standalone="yes"?>
<rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom">
  <channel>
    <title>Arm64 on anitabyte</title>
    <link>/tags/arm64/</link>
    <description>Recent content in Arm64 on anitabyte</description>
    <generator>Hugo</generator>
    <language>en</language>
    <lastBuildDate>Fri, 22 Sep 2023 12:36:37 +0100</lastBuildDate>
    <atom:link href="/tags/arm64/index.xml" rel="self" type="application/rss+xml" />
    <item>
      <title>Pi Any Means Necessary #2: Software availability</title>
      <link>/posts/pi_any_means_necessary_2/</link>
      <pubDate>Fri, 22 Sep 2023 12:36:37 +0100</pubDate>
      <guid>/posts/pi_any_means_necessary_2/</guid>
      <description>&lt;p&gt;I&amp;rsquo;ve taken for granted in the past that if I&amp;rsquo;m on a Raspberry Pi, I&amp;rsquo;m going to have an easy time of getting software for ARM: it&amp;rsquo;s all-but the default platform for which ARM software is built, given the prevalence of the board in the marketplace. This isn&amp;rsquo;t - for now, at least - so true if you&amp;rsquo;re on a 64-bit OS. In spite of the Pi having a 64-bit processor since the Pi 3, the software ecosystem hasn&amp;rsquo;t quite caught up to that. This isn&amp;rsquo;t an issue for things distributed by Debian - all of that ends up in the core repositories and is only an &lt;code&gt;apt install&lt;/code&gt; away - but for things distributed in the likes of AppImages or Flatpaks, this poses more of a problem.&lt;/p&gt;</description>
    </item>
  </channel>
</rss>
