perrotuerto.blog/old/content/html/en/004_backup.html

107 lines
17 KiB
HTML
Raw Blame History

This file contains ambiguous Unicode characters

This file contains Unicode characters that might be confused with other characters. If you think that this is intentional, you can safely ignore this warning. Use the Escape button to reveal them.

<!DOCTYPE html>
<html lang="en">
<head>
<title>Who Backup Whom?</title>
<meta charset="utf-8" />
<meta name="application-name" content="Publishing is Coding: Change My Mind">
<meta name="description" content="Blog about free culture, free software and free publishing.">
<meta name="keywords" content="publishing, blog, book, ebook, methodology, foss, libre-software, format, markdown, html, epub, pdf, mobi, latex, tex, culture, free culture, philosophy">
<meta name="viewport" content="width=device-width, user-scalable=0">
<link rel="shortcut icon" href="../../../icon.png">
<link rel="alternate" type="application/rss+xml" href="https://perrotuerto.blog/feed/" title="Publishing is Coding: Change My Mind">
<link type="text/css" rel="stylesheet" href="../../../css/styles.css">
<link type="text/css" rel="stylesheet" href="../../../css/extra.css">
<script type="application/javascript" src="../../../js/functions.js"></script>
</head>
<body>
<header>
<h1><a href="https://perrotuerto.blog/content/html/en/">Publishing is Coding: Change My Mind</a></h1>
<nav> <p> <a href="../../../content/html/en/_links.html">Links</a> | <a href="../../../content/html/en/_about.html">About</a> | <a href="../../../content/html/en/_contact.html">Contact</a> | <a href="../../../content/html/en/_fork.html">Fork</a> | <a href="../../../content/html/en/_donate.html">Donate</a> </p>
</nav>
</header>
<div id="controllers">
<a onclick="zoom(true)">+</a>
<a onclick="zoom(false)"></a>
<a onclick="mode(this)">N</a>
</div>
<section>
<h1 id="who-backup-whom">Who Backup Whom?</h1>
<blockquote class="published">
<p>Published: 2019/07/04, 11:00</p>
</blockquote>
<p>Among publishers and readers is common to heard about “digital copies.” This implies that ebooks tend to be seen as backups of printed books. How the former became a copy of the original—even tough you first need a digital file in order to print—goes something like this:</p>
<ol>
<li>
<p>Digital files (<span class="smallcap">DF</span>s) with appropriate maintenance could have higher probabilities to last longer that its material peer.</p>
</li>
<li>
<p>Physical files (<span class="smallcap">PF</span>s) are limited due geopolitical issues, like cultural policies updates, or due random events, like environment changes or accidents.</p>
</li>
<li>
<p><i>Therefore</i>, <span class="smallcap">DF</span>s are backups of <span class="smallcap">PF</span>s because <i>in theory</i> its dependence is just technical.</p>
</li>
</ol>
<p>The famous digital copies arise as a right of private copy. What if one day our printed books get ban or burn? Or maybe some rain or coffee spill could fuck our books collection. Who knows, <span class="smallcap">DF</span>s seem more reliable.</p>
<p>But there are a couple suppositions in this argument. (1) The technology behind <span class="smallcap">DF</span>s in one way or the other will always make data flow. Maybe this is because (2) one characteristic—part of its “nature”—of information is that nobody can stop its spread. This could also implies that (3) hackers can always destroy any kind of digital rights management system.</p>
<p>Certainly some dudes are gonna be able to hack the locks but at a high cost: every time each <a href="https://en.wikipedia.org/wiki/Cipher">cipher</a> is revealed, another more complex is on the way—<em>Barlow <a href="https://www.wired.com/1994/03/economy-ideas/">dixit</a></em>. We cannot trust that our digital infrastructure would be designed with the idea of free share in mind… Also, how can we probe information wants to be free without relying in its “nature” or making it some kind of autonomous subject?</p>
<p>Besides those issues, the dynamic between copies and originals creates an hierarchical order. Every <span class="smallcap">DF</span> is in a secondary position because it is a copy. In a world full of things, materiality is and important feature for commons and goods; for several people <span class="smallcap">PF</span>s are gonna be preferred because, well, you can grasp them.</p>
<p>Ebook market shows that the hierarchy is at least shading. For some readers <span class="smallcap">DF</span>s are now in the top of the pyramid. We could say so by the follow argument:</p>
<ol>
<li>
<p><span class="smallcap">DF</span>s are way more flexible and easy to share.</p>
</li>
<li>
<p><span class="smallcap">PF</span>s are very rigid and not easy to access.</p>
</li>
<li>
<p><i>Therefore</i>, <span class="smallcap">DF</span>s are more suitable for use than <span class="smallcap">PF</span>s.</p>
</li>
</ol>
<p>Suddenly, <span class="smallcap">PF</span>s become hard copies that are gonna store data as it was published. Its information is in disposition to be extracted and processed if need it.</p>
<p>Yeah, we also have a couple assumptions here. Again (1) we rely on the stability of our digital infrastructure that it would allow us to have access to <span class="smallcap">DF</span>s no matter how old they are. (2) Reader's priorities are over files use—if not merely consumption—not on its preservation and reproduction (<span class="smallcap">P&#38;R</span>). (3) The argument presume that backups are motionless information, where bookshelves are fridges for later-to-use books.</p>
<p>The optimism about our digital infrastructure is too damn high. Commonly we see it as a technology that give us access to zillions of files and not as a <span class="smallcap">P&#38;R</span> machinery. This could be problematic because some times file formats intended for use aren't the most suitable for <span class="smallcap">P&#38;R</span>. For example, the use of <span class="smallcap">PDF</span>s as some kind of ebook. Giving to much importance to reader's priorities could lead us to a situation where the only way to process data is by extracting it again from hard copies. When we do that we also have another headache: fixes on the content have to be add to the last available hard copy edition. But, can you guess where are all the fixes? Probably not. Maybe we should start to think about backups as some sort of <i>rolling update</i>.</p>
<figure>
<img src="../../../img/p004_i001.jpg" alt="Programando Libreros while she scans books which DFs are not suitable for P&#38;R or are simply nonexistent; can you see how it is not necessary to have a fucking nice scanner?"/>
<figcaption>
Programando Libreros while she scans books which <span class="smallcap">DF</span>s are not suitable for <span class="smallcap">P&#38;R</span> or are simply nonexistent; can you see how it is not necessary to have a fucking nice scanner?
</figcaption>
</figure>
<p>As we imagine—and started to live in—scenarios of highly controlled data transfer, we have to picture a situation where for some reason our electric power is off or running low. In that context all the strengths of <span class="smallcap">DF</span>s become pointless. They may not be accessible. They may not spread. Right now for us is hard to imagine. Generation after generation the storaged <span class="smallcap">DF</span>s in <span class="smallcap">HDD</span>s would be inherit with the hope of being used again. But over time those devices with our cultural heritage would become rare objects without any apparent utility.</p>
<p>The aspects of <span class="smallcap">DF</span>s that made us see the fragility of <span class="smallcap">PF</span>s would disappear in its concealment. Can we still talk about information if it is on a potential stage—we know data is there, but it is inaccessible because we don't have means for view them? Or does information already implies technical resources for its access—i.e. there is not information without a subject with technical skills to extract, process and use the data?</p>
<p>When we usually talk about information we already suppose it is there, but many times it is not accessible. So the idea of potential information could be counterintuitive. If information isn't actual we just consider that it doesn't exist, not that it is on some potential stage.</p>
<p>As our technology is developing we assume that we would always have <i>the possibility</i> of better ways to extract or understand data. Thus, that there are bigger chances to get new kinds of information—and take profit from it. Preservation of data relies between those possibilities, as we usually backup files with the idea that we could need to go back again.</p>
<p>Our world become more complex by new things forthcoming to us, most of the times as new characteristics of things we already know. Preservation policies implies an epistemic optimism and not only a desire to keep alive or incorrupt our heritage. We wouldn't backup data if we don't already believe we could need it in a future where we can still use it.</p>
<p>With this exercise it could be clear a potentially paradox of <span class="smallcap">DF</span>s. More accessibility tends to require more technical infrastructure. This could imply major technical dependence that subordinate accessibility of information to the disposition of technical means. <i>Therefore</i>, we achieve a situation where more accessibility is equal to more technical infrastructure and—as we experience nowadays—dependence.</p>
<p>Open access to knowledge involves at least some minimum technical means. Without that, we can't really talk about accessibility of information. Contemporary open access possibilities are restricted to an already technical dependence because we give a lot of attention in the flexibility that <span class="smallcap">DF</span>s offer us for <i>its use</i>. In a world without electric power, this kind of accessibility becomes narrow and an useless effort.</p>
<figure>
<img src="../../../img/p004_i002.jpg" alt="Programando Libreros and Hacklib while they work on a project intended to P&#38;R old Latin American SciFi books; sometimes a V-shape scanner is required when books are very fragile."/>
<figcaption>
Programando Libreros and Hacklib while they work on a project intended to <span class="smallcap">P&#38;R</span> old Latin American SciFi books; sometimes a V-shape scanner is required when books are very fragile.
</figcaption>
</figure>
<p>So, <i>who backup whom?</i> In our actual world, where geopolitics and technical means restricts flow of data and people at the same time it defends internet access as a human right—some sort of neo-Enlightenment discourse—<span class="smallcap">DF</span>s are lifesavers in a condition where we don't have more ways to move around or scape—not only from border to border, but also on cyberspace: it is becoming a common place the need to sign up and give your identity in order to use web services. Let's not forget that open access of data can be a course of action to improve as community but also a method to perpetuate social conditions.</p>
<p>Not a lot of people are as privilege as us when we talk about access to technical means. Even more concerning, there are hommies with disabilities that made very hard for them to access information albeit they have those means. Isn't it funny that our ideas as file contents can move more “freely” than us—your memes can reach web platform where you are not allow to sign in?</p>
<p>I desire more technological developments for freedom of <span class="smallcap">P&#38;R</span> and not just for use as enjoyment—no matter is for intellectual or consumption purposes. I want us to be free. But sometimes use of data, <span class="smallcap">P&#38;R</span> of information and people mobility freedoms don't get along.</p>
<p>With <span class="smallcap">DF</span>s we achieve more independence in file use because once it is save, it could spread. It doesn't matter we have religious or political barriers; the battle take place mainly in technical grounds. But this doesn't made <span class="smallcap">DF</span>s more autonomous in its <span class="smallcap">P&#38;R</span>. Neither implies we can archive personal or community freedoms. They are objects. <i>They are tools</i> and whoever use them better, whoever owns them, would have more power.</p>
<p>With <span class="smallcap">PF</span>s we can have more <span class="smallcap">P&#38;R</span> freedom. We can do whatever we want with them: extract their data, process it and let it free. But only if we are their owners. Often that is not the case, so <span class="smallcap">PF</span>s tend to have more restricted access for its use. And, again, this doesn't mean we can be free. There is not any cause and effect relationship between what object made possible and how subjects want to be free. They are tools, they are not master or slaves, just means for whoever use them… but for which ends?</p>
<p>We need <span class="smallcap">DF</span>s and <span class="smallcap">PF</span>s as backups and as everyday objects of use. The act of backup is a dynamic category. Backed up files are not inert and they aren't only substrates waiting to be use. Sometimes we are going to use <span class="smallcap">PF</span>s because <span class="smallcap">DF</span>s have been corrupted or its technical infrastructure has been shut down. In other occasions we would use <span class="smallcap">DF</span>s when <span class="smallcap">PF</span>s have been destroyed or restricted.</p>
<figure>
<img src="../../../img/p004_i003.jpg" alt="Due restricted access to PFs, sometimes it is necessary a portable V-shape scanner; this model allows us to handle damaged books while we can also storage it in a backpack."/>
<figcaption>
Due restricted access to <span class="smallcap">PF</span>s, sometimes it is necessary a portable V-shape scanner; this model allows us to handle damaged books while we can also storage it in a backpack.
</figcaption>
</figure>
<p>So the struggle about backups—and all that shit about “freedom” on <span class="smallcap">FOSS</span> communities—it is not only around the “incorporeal” realm of information. Nor on the technical means that made digital data possible. Neither in the laws that transform production into property. We have others battle fronts against the monopoly of the cyberspace—or as Lingel <a href="http://culturedigitally.org/2019/03/the-gentrification-of-the-internet/">says</a>: the gentrification of the internet.</p>
<p>It is not just about software, hardware, privacy, information or laws. It is about us: how we build communities and how technology constitutes us as subjects. <i>We need more theory</i>. But a very diversified one because being on internet it is not the same for an scholar, a publisher, a woman, a kid, a refugee, a non-white, a poor or an old lady. This space it isn't neutral nor homogeneous nor two-dimensional. It has wires, it has servers, it has exploited employees, it has buildings, <i>it has power</i> and it has, well, all that things the “real world” has. Not because you use a device to access means that you can always decide if you are online or not: you are always online as an user as a consumer or as data.</p>
<p><i>Who backup whom?</i> As internet is changing us as printed text did, backed up files aren't storages of data, but <i>the memory of our world</i>. Is it still a good idea to leave the work of <span class="smallcap">P&#38;R</span> to a couple hardware and software companies? Are we now allow to say that the act of backup implies files but something else too?</p>
<script type="text/javascript" src="../../../hashover/comments.php"></script>
</section>
<footer>
<p class="left no-indent">Texts and images are under <a href="../../../content/html/en/_fork.html">Open and Free Publishing License (<span class="smallcap">LEAL</span>)</a>.</p>
<p class="left no-indent">Code is under <a target="_blank" href="https://www.gnu.org/licenses/gpl-faq.en.html"><span class="smallcap">GNU</span> General Public License (<span class="smallcap">GPL</span>v3)</a>.</p>
<p class="left no-indent">Last build of this page: 2020/02/13, 18:39.</p>
<p class="left no-indent"><span class="smallcap"><a target="_blank" href="https://perrotuerto.blog/feed/en/rss.xml">RSS</a></span> | <a href="../../../content/html/en/004_backup.html"><span class="versalita">EN</span></a> | <a href="../../../content/html/es/004_backup.html"><span class="versalita">ES</span></a></p>
</footer>
</body>
</html>