<?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>Posts on Douglas Santos</title><link>https://blog.batcode.io/tags/posts/</link><description>Recent content in Posts on Douglas Santos</description><generator>Hugo -- 0.166.0</generator><language>pt-BR</language><lastBuildDate>Wed, 09 Sep 2026 00:00:00 +0000</lastBuildDate><atom:link href="https://blog.batcode.io/tags/posts/index.xml" rel="self" type="application/rss+xml"/><item><title>Bluetooth fantasma no Linux: como o btusb trava o MediaTek MT6639 tentando carregar um firmware que não existe.</title><link>https://blog.batcode.io/posts/mt6639-bluetooth-loop-de-reset/</link><pubDate>Wed, 09 Sep 2026 00:00:00 +0000</pubDate><guid>https://blog.batcode.io/posts/mt6639-bluetooth-loop-de-reset/</guid><description>Meu Bluetooth nunca funcionou nesta placa e eu tinha certeza de que era firmware faltando. Era — mas o que quebrava o hardware de verdade era o driver tentando resolver isso pra sempre. Aqui está a investigação inteira, do falso negativo no dmesg até uma corrida de 174 milissegundos no boot.</description><content:encoded><![CDATA[<p>Comprei uma ASUS ProArt X870E-Creator WiFi e o Wi-Fi funcionou de primeira. O Bluetooth, não. Nunca apareceu adaptador nenhum, e o pior: o dispositivo simplesmente não estava no <code>lsusb</code>. Nem travado, nem com erro — ausente.</p>
<p>Minha primeira hipótese foi a mais óbvia, e estava certa pela metade: o firmware de Bluetooth desse chip não vem no <code>linux-firmware</code>. O que eu não imaginava é que o firmware faltando não é o que quebra o hardware. O que quebra é o que o driver faz a respeito disso.</p>
<p>Neste artigo vou reconstruir a investigação inteira, incluindo os dois momentos em que eu conclui a coisa errada com confiança total. Acho que essas partes são mais úteis que a solução.</p>
<table>
	<thead>
			<tr>
					<th></th>
					<th></th>
			</tr>
	</thead>
	<tbody>
			<tr>
					<td>Placa-mãe</td>
					<td>ASUS ProArt X870E-Creator WiFi rev 2</td>
			</tr>
			<tr>
					<td>BIOS</td>
					<td>2402</td>
			</tr>
			<tr>
					<td>Sistema</td>
					<td>Bazzite (Fedora 44 Atomic)</td>
			</tr>
			<tr>
					<td>Kernel</td>
					<td>7.2.3-ogc3.1.fc44.x86_64</td>
			</tr>
			<tr>
					<td>Bluetooth</td>
					<td>MediaTek MT6639, USB <code>0489:e13a</code></td>
			</tr>
			<tr>
					<td>Wi-Fi</td>
					<td>MediaTek MT7927, PCIe <code>14c3:7927</code></td>
			</tr>
	</tbody>
</table>
<h2 id="o-sintoma-um-adaptador-que-não-existe">O sintoma: um adaptador que não existe</h2>
<p>Nenhum adaptador. O <code>bluetoothctl show</code> trava sem imprimir nada, porque o <code>bluetoothd</code> fica esperando um controlador que nunca vai aparecer. E o <code>dmesg</code> não tinha absolutamente nenhuma mensagem do subsistema Bluetooth — nem sucesso, nem falha de firmware, nem erro de USB. Silêncio total.</p>
<p>Silêncio total é um resultado estranho. Se o firmware faltasse, eu deveria ver o driver reclamando. Se o dispositivo estivesse com defeito, eu deveria ver o USB reclamando. Não ver nada significa que o kernel nem tentou.</p>
<h2 id="o-falso-negativo-que-me-custou-uma-rodada-inteira">O falso negativo que me custou uma rodada inteira</h2>
<p>Aqui está o primeiro erro, e ele é constrangedor de tão simples.</p>
<div class="highlight"><pre tabindex="0" class="chroma"><code class="language-bash" data-lang="bash"><span class="line"><span class="cl">dmesg <span class="p">|</span> grep -iE <span class="s1">&#39;btusb|bluetooth: hci&#39;</span>
</span></span></code></pre></div><p>Isso voltava vazio. Eu li &ldquo;vazio&rdquo; como &ldquo;não há mensagens de Bluetooth&rdquo;. Errado. O que estava acontecendo é que o <code>kernel.dmesg_restrict=1</code> faz o <code>dmesg</code> sem root retornar <strong>zero linhas de qualquer tipo</strong>. Não havia mensagem nenhuma pra filtrar — de Bluetooth, de USB, de nada.</p>
<div class="highlight"><pre tabindex="0" class="chroma"><code class="language-bash" data-lang="bash"><span class="line"><span class="cl">$ dmesg <span class="p">|</span> wc -l
</span></span><span class="line"><span class="cl"><span class="m">0</span>
</span></span><span class="line"><span class="cl">$ sysctl -n kernel.dmesg_restrict
</span></span><span class="line"><span class="cl"><span class="m">1</span>
</span></span></code></pre></div><p>Um <code>grep</code> vazio em cima de uma entrada vazia parece exatamente igual a um <code>grep</code> vazio em cima de mil linhas. A lição prática: use <code>journalctl -k</code>, que funciona sem sudo e te dá o log de verdade.</p>
<div class="highlight"><pre tabindex="0" class="chroma"><code class="language-bash" data-lang="bash"><span class="line"><span class="cl">$ journalctl -k -b <span class="m">0</span> --no-pager <span class="p">|</span> wc -l
</span></span><span class="line"><span class="cl"><span class="m">1893</span>
</span></span></code></pre></div><p>Mil oitocentas e noventa e três linhas que eu vinha ignorando. E dentro delas estava tudo.</p>
<h2 id="o-dispositivo-não-sumiu--ele-travou">O dispositivo não sumiu — ele travou</h2>
<p>Com o log de verdade em mãos, o quadro mudou completamente. O dispositivo <strong>está</strong> lá, na porta <code>1-6</code>, vizinha do controlador de LED da placa. Ele é detectado eletricamente. Ele simplesmente não responde a nada.</p>
<pre tabindex="0"><code>usb 1-6: new high-speed USB device number 4 using xhci_hcd
usb 1-6: device descriptor read/64, error -110
usb 1-6: device descriptor read/64, error -110
usb 1-6: new high-speed USB device number 5 using xhci_hcd
usb 1-6: device descriptor read/64, error -110
usb 1-6: device descriptor read/64, error -110
usb usb1-port6: attempt power cycle
usb 1-6: new high-speed USB device number 6 using xhci_hcd
usb 1-6: Device not responding to setup address.
usb 1-6: device not accepting address 6, error -71
usb 1-6: new high-speed USB device number 7 using xhci_hcd
usb 1-6: Device not responding to setup address.
usb 1-6: device not accepting address 7, error -71
usb usb1-port6: unable to enumerate USB device
</code></pre><p>Traduzindo: <code>-110</code> é timeout, <code>-71</code> é erro de protocolo. O hub vê que tem alguma coisa plugada, tenta ler o descritor do dispositivo, não recebe resposta, corta e religa a energia da porta, tenta de novo, desiste. Quatro tentativas, sessenta e três segundos, nada.</p>
<p>Isso também explica por que o <code>btusb</code> não estava carregado, e por que isso <strong>não</strong> era o problema. O udev carrega o módulo quando aparece um modalias que casa com ele. Como nada enumerou, não existe modalias, então o módulo não carrega. Carregar na mão funciona sem erro nenhum e não cria dispositivo HCI algum:</p>
<div class="highlight"><pre tabindex="0" class="chroma"><code class="language-bash" data-lang="bash"><span class="line"><span class="cl">$ sudo modprobe btusb <span class="o">&amp;&amp;</span> ls /sys/class/bluetooth/
</span></span><span class="line"><span class="cl"><span class="c1"># (vazio)</span>
</span></span></code></pre></div><p>A pilha de software está impecável. O hardware é que não aparece.</p>
<h2 id="a-causa-o-btusb-tenta-pra-sempre">A causa: o btusb tenta pra sempre</h2>
<p>O journal do Bazzite guarda os boots anteriores, e é aí que a coisa fica interessante. Varri todos os boots registrados procurando pelo dispositivo, e em dois deles ele <strong>funcionou</strong> — enumerou normalmente. Fui olhar o que tinha acontecido:</p>
<pre tabindex="0"><code>[    3.068951] usb 1-6: New USB device found, idVendor=0489, idProduct=e13a
[    3.069092] usb 1-6: Product: Wireless_Device
[    8.221018] usbcore: registered new interface driver btusb
[    8.233139] Bluetooth: hci0: Failed to load firmware file (-2)
[    8.233145] Bluetooth: hci0: Failed to set up firmware (-2)
[    8.564037] usb 1-6: reset high-speed USB device number 4 using xhci_hcd
[    8.817354] Bluetooth: hci0: Failed to load firmware file (-2)
[    9.147127] usb 1-6: reset high-speed USB device number 4 using xhci_hcd
[    9.402354] Bluetooth: hci0: Failed to load firmware file (-2)
[    9.727020] usb 1-6: reset high-speed USB device number 4 using xhci_hcd
</code></pre><p>Achou o padrão? O firmware falha com <code>-2</code> (ENOENT, arquivo não encontrado), e o <code>btusb</code> <strong>reseta o dispositivo por USB e tenta de novo</strong>. Aí falha de novo, reseta de novo, tenta de novo. A cada 0,58 segundos. Sem backoff, sem limite de tentativas, sem desistir nunca.</p>
<p>Naquele boot isso rodou por 13 minutos até eu desligar a máquina. Foram 1335 resets.</p>
<p>E é isso que trava o chip. A cadeia inteira é assim:</p>
<ol>
<li>Partida a frio limpa: o controlador enumera normalmente, uns 3 segundos depois do boot.</li>
<li>O <code>btusb</code> faz bind aos ~8 segundos, cria o <code>hci0</code>, pede o firmware.</li>
<li>O arquivo não existe. Retorna <code>-2</code>.</li>
<li><strong>O <code>btusb</code> reseta o dispositivo e tenta de novo. E de novo. Indefinidamente.</strong></li>
<li>Depois de algumas centenas de resets, o firmware do controlador trava.</li>
<li>A partir daí, a porta detecta o dispositivo mas ele não responde mais nada.</li>
<li>Isso <strong>sobrevive a reboots</strong>, porque o trilho de energia de standby mantém o chip alimentado.</li>
</ol>
<p>O ponto 7 é o que torna isso cruel. Você reinicia, não resolve. Reinstala o sistema, não resolve. O chip continua travado porque nunca foi desenergizado de verdade.</p>
<h2 id="as-contas-batem">As contas batem</h2>
<p>O que me convenceu de que essa era mesmo a causa, e não uma coincidência, foi contar. Se o loop de reset é consequência da falha de firmware, os dois números têm que ser idênticos:</p>
<table>
	<thead>
			<tr>
					<th>Boot</th>
					<th style="text-align: right">Resets da porta 1-6</th>
					<th style="text-align: right">Falhas de firmware</th>
			</tr>
	</thead>
	<tbody>
			<tr>
					<td>-8</td>
					<td style="text-align: right">398</td>
					<td style="text-align: right">398</td>
			</tr>
			<tr>
					<td>-1</td>
					<td style="text-align: right">1335</td>
					<td style="text-align: right">1335</td>
			</tr>
	</tbody>
</table>
<p>Batem exatamente. Um reset para cada falha, nos dois boots.</p>
<p>E o padrão de reincidência entre boots conta o resto da história:</p>
<table>
	<thead>
			<tr>
					<th>Boot</th>
					<th>Porta 1-6</th>
					<th>Leitura</th>
			</tr>
	</thead>
	<tbody>
			<tr>
					<td>-8</td>
					<td>enumerou</td>
					<td>partida limpa, 398 resets, trava</td>
			</tr>
			<tr>
					<td>-7 a -3</td>
					<td>sem eventos</td>
					<td><strong>cinco boots mortos</strong>, consequência do -8</td>
			</tr>
			<tr>
					<td>-2</td>
					<td>falha na enumeração</td>
					<td>travado</td>
			</tr>
			<tr>
					<td>-1</td>
					<td>enumerou</td>
					<td>destravado por corte de energia, 1335 resets, trava de novo</td>
			</tr>
			<tr>
					<td>0</td>
					<td>falha na enumeração</td>
					<td>travado</td>
			</tr>
	</tbody>
</table>
<p>Dois ciclos completos. Toda vez que eu destravava o chip cortando energia, ele voltava, entrava no loop, e travava de novo. Eu estava reproduzindo o problema sem saber.</p>
<p>Para destravar, o caminho é cortar a energia de verdade: habilitar <strong>ErP em S4+S5</strong> na BIOS e usar <code>poweroff</code> (não <code>reboot</code>, que nunca corta o standby), ou tirar da tomada por uns 10 segundos.</p>
<h2 id="ah-e-o-boot-lento-era-o-mesmo-bug">Ah, e o boot lento era o mesmo bug</h2>
<p>Eu tinha uma segunda queixa que achava não ter relação: o boot estava demorando quase dois minutos. Tinha.</p>
<p>O <code>systemd-udev-settle.service</code> fica na <strong>raiz da cadeia crítica</strong> do boot — tudo espera por ele. E as retentativas de enumeração na porta 1-6 mantêm o udev ocupado:</p>
<table>
	<thead>
			<tr>
					<th>Estado da porta 1-6</th>
					<th>Boots</th>
					<th style="text-align: right">udev-settle</th>
			</tr>
	</thead>
	<tbody>
			<tr>
					<td>dispositivo ausente</td>
					<td>-7 a -3</td>
					<td style="text-align: right">8,6 – 9,7 s</td>
			</tr>
			<tr>
					<td>dispositivo travado</td>
					<td>-2, 0</td>
					<td style="text-align: right"><strong>67,8 s</strong></td>
			</tr>
	</tbody>
</table>
<p>Uns 59 segundos de penalidade, batendo com a janela de 63 segundos das retentativas. Depois que o controlador subiu direito, o boot foi de <strong>1min52s para 41s</strong>. Dois sintomas, um bug só.</p>
<h2 id="onde-colocar-firmware-quando-usr-é-read-only">Onde colocar firmware quando /usr é read-only</h2>
<p>O Bazzite é um sistema imutável: <code>/usr</code> é somente-leitura, então não dá pra simplesmente jogar o arquivo em <code>/usr/lib/firmware</code>. A rota padrão é usar <code>/var/lib/firmware</code> e apontar o kernel pra lá com um parâmetro de boot:</p>
<div class="highlight"><pre tabindex="0" class="chroma"><code class="language-bash" data-lang="bash"><span class="line"><span class="cl">sudo install -Dm644 BT_RAM_CODE_MT6639_2_1_hdr.bin <span class="se">\
</span></span></span><span class="line"><span class="cl">  /var/lib/firmware/mediatek/mt7927/BT_RAM_CODE_MT6639_2_1_hdr.bin
</span></span><span class="line"><span class="cl">
</span></span><span class="line"><span class="cl">sudo rpm-ostree kargs --append<span class="o">=</span>firmware_class.path<span class="o">=</span>/var/lib/firmware
</span></span></code></pre></div><p>Fiz isso, reiniciei, e o Bluetooth funcionou. Fim do artigo, certo?</p>
<p>Não. Fui conferir o log e o firmware <strong>tinha falhado com <code>-2</code> de novo</strong> — e mesmo assim o dispositivo subiu. Isso não fazia sentido nenhum, e a explicação é a parte mais interessante de tudo.</p>
<h2 id="a-corrida-que-eu-ganhei-por-174-milissegundos">A corrida que eu ganhei por 174 milissegundos</h2>
<p>Em sistemas ostree, o <code>/var</code> é um subvolume montado por uma unit do systemd <strong>depois</strong> do switch-root. E o <code>btusb</code> faz probe exatamente dentro dessa janela.</p>
<table>
	<thead>
			<tr>
					<th style="text-align: right">Tempo</th>
					<th>Evento</th>
			</tr>
	</thead>
	<tbody>
			<tr>
					<td style="text-align: right">7,294 s</td>
					<td>switch-root</td>
			</tr>
			<tr>
					<td style="text-align: right">8,677 s</td>
					<td><code>btusb</code> registra o interface driver</td>
			</tr>
			<tr>
					<td style="text-align: right"><strong>8,688 s</strong></td>
					<td><strong>primeira tentativa de firmware falha, <code>-2</code></strong></td>
			</tr>
			<tr>
					<td style="text-align: right">9,021 s</td>
					<td><code>btusb</code> reseta o dispositivo e reagenda</td>
			</tr>
			<tr>
					<td style="text-align: right"><strong>9,235 s</strong></td>
					<td><strong><code>var.mount</code> conclui</strong></td>
			</tr>
			<tr>
					<td style="text-align: right">9,409 s</td>
					<td>o retry <strong>encontra</strong> o firmware</td>
			</tr>
			<tr>
					<td style="text-align: right">28,758 s</td>
					<td><code>Device setup in 19036182 usecs</code></td>
			</tr>
			<tr>
					<td style="text-align: right">28,930 s</td>
					<td><code>AOSP extensions version v1.00</code></td>
			</tr>
	</tbody>
</table>
<p>Ou seja: funcionou pelo motivo errado. A primeira iteração do loop de reset — o mesmo loop que trava o chip — foi justamente o que salvou, porque o <code>/var</code> montou no meio dela. A margem foi de 174 milissegundos.</p>
<p>Isso é sorte reproduzível, não garantia. Se o retry caísse 200 ms mais cedo, o loop começaria e o chip travaria. Ainda por cima, tem um detalhe cruel: existe um <code>/var</code> stub não-vazio embaixo do ponto de montagem no deployment, então a busca falha <strong>em silêncio</strong> em vez de dar erro de diretório ausente.</p>
<h2 id="a-correção-de-verdade">A correção de verdade</h2>
<p>A solução é colocar o firmware num lugar que já esteja legível no switch-root. O <code>/etc</code> serve: ele é um bind mount do próprio subvolume do deployment, montado pelo <code>ostree-prepare-root</code> ainda dentro do initrd. Está disponível aos 7,294 s, mais de um segundo antes do <code>btusb</code> fazer probe.</p>
<div class="highlight"><pre tabindex="0" class="chroma"><code class="language-bash" data-lang="bash"><span class="line"><span class="cl">sudo install -Dm644 BT_RAM_CODE_MT6639_2_1_hdr.bin <span class="se">\
</span></span></span><span class="line"><span class="cl">  /etc/firmware/mediatek/mt7927/BT_RAM_CODE_MT6639_2_1_hdr.bin
</span></span><span class="line"><span class="cl">
</span></span><span class="line"><span class="cl">sudo rpm-ostree kargs <span class="se">\
</span></span></span><span class="line"><span class="cl">  --replace<span class="o">=</span>firmware_class.path<span class="o">=</span>/var/lib/firmware<span class="o">=</span>/etc/firmware
</span></span></code></pre></div><p>Detalhe simpático: o SELinux rotula o arquivo como <code>cpucontrol_conf_t</code>, porque <code>/etc/firmware</code> já é um caminho que a policy conhece (usado para microcode de CPU). E não bloqueia nada — a policy carregada nem define a permissão <code>firmware_load</code>.</p>
<p>Para validar depois do reboot, os dois números têm que dar zero:</p>
<div class="highlight"><pre tabindex="0" class="chroma"><code class="language-bash" data-lang="bash"><span class="line"><span class="cl">journalctl -k -b <span class="m">0</span> <span class="p">|</span> grep -c <span class="s1">&#39;Failed to load firmware file&#39;</span>
</span></span><span class="line"><span class="cl">journalctl -k -b <span class="m">0</span> <span class="p">|</span> grep -c <span class="s1">&#39;reset high-speed USB device&#39;</span>
</span></span></code></pre></div><h2 id="a-armadilha-do-etc-staged--quase-desisti-aqui">A armadilha do /etc staged — quase desisti aqui</h2>
<p>Esse foi o segundo momento em que eu conclui a coisa errada com confiança total, e valeu um susto.</p>
<p>Depois do <code>rpm-ostree kargs</code>, fui conferir o deployment novo antes de reiniciar. O <code>/etc/firmware</code> <strong>não estava lá</strong>. E o deployment é read-only, então nem dava pra colocar na mão.</p>
<p>Isso parecia fatal. Com o parâmetro de boot apontando só pro <code>/etc/firmware</code>, um arquivo ausente significa que a primeira tentativa <strong>e o retry</strong> falham, já que o <code>/var</code> saiu do caminho de busca. Ou seja: pior do que não ter mexido em nada.</p>
<p>Antes de reverter, resolvi comparar as duas árvores de <code>/etc</code>. A do deployment novo estava sem 23 itens que a atual tinha:</p>
<pre tabindex="0"><code>bazzite    cardwire   cni        crypttab   firmware
fstab      group-     gshadow-   hostname   iwd
locale.conf localtime passwd-    sddm.conf.d shadow-
subgid-    subuid-    vconsole.conf
</code></pre><p>Olha o <code>fstab</code> ali no meio.</p>
<p>É isso que resolve a questão. Se a finalização não fizesse o merge do <code>/etc</code>, <strong>nenhum sistema ostree conseguiria bootar depois de um upgrade</strong>, porque ficaria sem <code>fstab</code>. Logo, o <code>/etc</code> de um deployment staged é o <em>pristine</em> do commit novo, e o merge de 3 vias é diferido para o <code>ostree admin finalize-staged</code>, que roda no shutdown.</p>
<p>Ou seja: inspecionar um <code>/etc</code> staged <strong>sempre</strong> vai parecer que suas modificações locais sumiram. É o esperado, não um defeito. Meu arquivo ia ser carregado junto com o <code>fstab</code> e o <code>hostname</code>, e foi.</p>
<p>O que me tirou do buraco não foi conhecimento prévio de ostree, foi procurar uma evidência que decidisse a questão em vez de apostar num palpite.</p>
<h2 id="de-onde-vem-esse-firmware-afinal">De onde vem esse firmware, afinal</h2>
<p>O blob de Bluetooth não está no <code>linux-firmware</code>. O MR !946 foi fechado porque o projeto só aceita blobs submetidos por quem detém os direitos — precisa vir da própria MediaTek. O de Wi-Fi entrou pelo MR !1055, e é exatamente por isso que a metade Wi-Fi do chip funciona de fábrica e a metade Bluetooth não.</p>
<p>Dá pra extrair dos pacotes de driver Windows da ASUS com o <a href="https://github.com/jetm/mediatek-mt7927-dkms">extract_firmware.py</a> do projeto <code>jetm/mediatek-mt7927-dkms</code>. Extraí de dois pacotes diferentes, de forma independente, e os arquivos saem <strong>byte a byte idênticos</strong>:</p>
<table>
	<thead>
			<tr>
					<th>Pacote</th>
					<th>Container</th>
					<th style="text-align: right">Tamanho</th>
			</tr>
	</thead>
	<tbody>
			<tr>
					<td>Bluetooth V1.1147.0.610</td>
					<td><code>mtkbt_v2.dat</code></td>
					<td style="text-align: right">571349 B</td>
			</tr>
			<tr>
					<td>Wi-Fi V5706054</td>
					<td><code>mtkwlan.dat</code></td>
					<td style="text-align: right">571349 B</td>
			</tr>
	</tbody>
</table>
<pre tabindex="0"><code>sha256  2135f2c4220cfa6e8eb9fdf430517098c13b862a95844bbff0153240a768efa8
caminho mediatek/mt7927/BT_RAM_CODE_MT6639_2_1_hdr.bin
build   20260611041233
</code></pre><p>Duas observações que economizam tempo. O caminho é <code>mediatek/mt7927/</code>, e não <code>mediatek/mt6639/</code> — confirme direto nas strings do módulo com <code>modinfo -F firmware btmtk</code> em vez de deduzir da mensagem de erro, porque essa convenção já mudou entre versões do kernel. E circula por aí um hash <code>669c5c99...</code> com uns 688 KB que não reproduziu aqui em nenhum dos dois pacotes; duas extrações independentes concordando pesam mais que um número solto de comunidade.</p>
<h2 id="o-que-não-fazer--leia-antes-de-replicar">O que não fazer — leia antes de replicar</h2>
<ul>
<li><strong>Não rode <code>modprobe -r btusb</code>.</strong> O firmware do MT6639 trava durante reload de módulo e o dispositivo some do <code>lsusb</code> de forma persistente. Foi assim que essa história começou. Prefira reboot.</li>
<li><strong>Não instale arquivos <code>WIFI_*.bin</code> no caminho de firmware.</strong> O <code>linux-firmware</code> já traz os corretos, comprimidos, em <code>/usr/lib/firmware/mediatek/mt7927/</code>. Uma cópia solta sombra silenciosamente o blob mais novo e quebra o Wi-Fi que hoje funciona. Só o arquivo de Bluetooth deve ser instalado.</li>
<li><strong>Não espere que reboot destrave o controlador.</strong> O trilho de standby mantém ele energizado. Só corte real de energia resolve.</li>
<li><strong>Não deixe o loop rodar depois de ver a falha de firmware.</strong> Cada ciclo de reset arrisca travar o chip de novo e custa mais um corte de energia. Desligue assim que aparecer <code>Failed to load firmware file (-2)</code>.</li>
</ul>
<h2 id="o-que-deveria-mudar-no-kernel">O que deveria mudar no kernel</h2>
<p>Um arquivo de firmware que não existe vai continuar não existindo na próxima tentativa. Retentar o mesmo pedido milhares de vezes não tem como dar certo — e aqui faz mal ativamente, porque empurra o controlador para um estado que sobrevive a reboots e exige intervenção física.</p>
<p>Um limite de tentativas, ou um backoff, ou simplesmente não retentar em <code>-2</code> quando a tentativa anterior falhou pelo mesmo motivo, transformaria isso de um dispositivo travado numa linha de log dizendo que o firmware está faltando. Vou levar isso pra <code>linux-bluetooth</code>.</p>
<h2 id="conclusão">Conclusão</h2>
<p>O que eu tiro dessa investigação não é o comando final, que cabe em duas linhas. São duas outras coisas.</p>
<p>A primeira é que ausência de evidência não é evidência de ausência, e ferramenta silenciosa mente. Um <code>grep</code> vazio me convenceu por um bom tempo de que não havia log, quando na verdade não havia permissão. Vale sempre confirmar que a ferramenta está te devolvendo dados antes de interpretar o silêncio dela.</p>
<p>A segunda é que o segundo susto — o <code>/etc</code> staged aparentemente vazio — se resolveu porque eu procurei uma evidência que decidisse a questão em vez de confiar no que eu achava que o ostree fazia. O <code>fstab</code> naquela lista valia mais que qualquer certeza minha sobre o funcionamento do sistema.</p>
<p>E, no fim, o firmware faltando era mesmo o problema. Só que ele não quebrava nada sozinho: quem quebrava era o driver, tentando resolver com afinco infinito uma coisa que não tinha como ser resolvida daquele jeito.</p>
<p>Se você tem esse chip e caiu aqui procurando por que seu Bluetooth não funciona, espero que este artigo economize os dias que ele me custou. Qualquer dúvida ou correção, é só me chamar.</p>
<p>Até a próxima!</p>
]]></content:encoded></item><item><title>A Liberdade do Valor: Como o Valor-por-Valor pode corrigir a forma como monetizamos a informação.</title><link>https://blog.batcode.io/posts/liberdade-valor/</link><pubDate>Sat, 28 Jun 2025 00:00:00 +0000</pubDate><guid>https://blog.batcode.io/posts/liberdade-valor/</guid><description>welcome to my personal blog</description><content:encoded><![CDATA[<p>Baseado no artigo original The Freedom of Value de Gigi, esta tradução e adaptação seguem os termos disponibilizados em dergigi.com/translations, sob a licença <a href="https://creativecommons.org/licenses/by-sa/4.0/">Creative Commons Attribution-ShareAlike 4.0 International (CC BY-SA 4.0)</a>.</p>
<p>Com a palavra, o autor:</p>
<p>A internet tem um problema. Poucas pessoas sabem que esse problema existe, mas, veja bem, essa é a natureza dos problemas sérios e não óbvios: eles permanecem invisíveis — até que deixam de ser.
O problema da internet é que a informação quer ser livre. E, se algo quer ser livre no sentido de liberdade, com tempo suficiente, também acabará sendo livre no sentido de &ldquo;gratuito&rdquo;.</p>
<p>Deixe-me explicar.</p>
<h2 id="envenenando-o-ar">Envenenando o Ar</h2>
<p>Consumimos uma quantidade incalculável de dados todos os dias. A cada segundo, de cada minuto, bits e bytes percorrem os tubos invisíveis que todos conhecemos e amamos: a internet.
A gente se acostumou com isso — e também se acostumou com o modelo atual de monetização, junto com todos os problemas que ele traz. Raramente paramos para pensar nesse mundo estranho de zeros e uns. O quão incrível ele é, mas ao mesmo tempo tão distante da nossa compreensão. Já mudou completamente nossas vidas — e vai continuar mudando nosso futuro.
Mas de onde vêm esses zeros e uns? O que faz tudo isso funcionar? E, mais importante: quem está pagando por isso?</p>
<p>Esses bits e bytes que viajam pelos nossos cabos de fibra ótica são tão invisíveis quanto o ar que respiramos. Aliás, essa é uma boa metáfora. Enquanto conseguimos respirar sem dificuldade, não precisamos analisar cada molécula que entra nos nossos pulmões.
Do mesmo jeito, enquanto conseguimos criar e consumir conteúdo digital sem muitos problemas, não sentimos a necessidade de questionar tudo o que mantém a economia da atenção funcionando.</p>
<p>Economia da atenção. Que nome apropriado.
Como todos deveríamos saber, o que consumimos na internet não é de graça — estamos pagando caro por isso: com nossa atenção, entre outras coisas.</p>
<h2 id="pagando-com-atenção">Pagando com Atenção</h2>
<p>No mundo acelerado de hoje, para maximizar os lucros, é preciso maximizar a atenção.
Mas é um tipo de atenção peculiar — e superficial.
Não é aquela atenção focada que o pensamento profundo ou uma conversa significativa exigiriam.
Acredito que é justamente por isso — ao menos em parte — que tanta coisa parece quebrada: por que nosso discurso social está tão fragmentado, nossa política tão polarizada, nós tão paralisados — e nossas análises, tão rasas quanto nossos desejos.</p>
<p>A economia da atenção nos dividiu perfeitamente em bolhas de verdades pessoais.
Ironia das ironias: a única “verdade” que realmente importa na economia da atenção é como manter o maior número possível de pessoas, no maior nível possível de indignação, pelo maior tempo possível.
E tudo isso mantendo os participantes sem perceber que estão **presos em uma prisão algorítmica construída pelas próprias escolhas que fizeram.</p>
<h2 id="você-é-o-produto">Você é o Produto</h2>
<p>O ditado “se algo é de graça, é porque você é o produto” nunca é repetido o suficiente.</p>
<p>Por algum motivo, criamos a expectativa de que quase tudo na internet deve ser “gratuito”.
Mas é claro que não existe almoço grátis.
No caso dos serviços online, seus dados são colhidos e vendidos para o maior lance — normalmente, uma empresa de publicidade… ou uma agência governamental. Ou as duas.</p>
<p>Não só todas as grandes empresas de dados espionam você, como também usam padrões obscuros (dark patterns) e práticas antiéticas para extrair até a última gota de informação sobre você.</p>
<p>Não importa se o nome da armadilha é Facebook Pixel, Google Analytics ou qualquer outra coisa — você está sendo rastreado, monitorado e catalogado.
O que você vê, por quanto tempo, em que horários, com que frequência e o que vai ver a seguir… tudo isso é cuidadosamente orquestrado por algoritmos otimizados para gerar lucro — lucro para a plataforma, não para você.</p>
<p>Claro, a ideia vendida é que todo mundo sai ganhando: usuários, criadores, anunciantes e as próprias plataformas.
Mas o “ambiente evolutivo” criado por esse sistema de incentivos acaba favorecendo conteúdo superficial, chamativo e sensacionalista.</p>
<p>Até o momento desta escrita — bloco 716.025 — a expressão máxima desse ambiente é o TikTok, uma verdadeira máquina de dopamina em formato de vídeo, que serve a você o equivalente visual de heroína misturada com crack.
Drogas pesadas para a mente, sob medida para seus gostos mais específicos.
Um aplicativo verdadeiramente amaldiçoado.</p>
<p>Infelizmente, a maioria das plataformas desse tipo não é diferente em essência — apenas em grau.</p>
<h2 id="opinião-permitida">Opinião Permitida</h2>
<p>“Não é tão ruim assim”, dizemos para nós mesmos.
“Olha quanta informação útil!” — exclamamos, enquanto rolamos sem parar nossos feeds, alimentando sem querer a máquina que, em troca, nos alimenta com doses de dopamina.</p>
<p>Mas não se engane:
as empresas por trás disso tudo não estão no negócio de nos oferecer informação útil (ou verdadeira).
Elas estão no negócio de nos enganar para que continuemos alimentando a máquina.</p>
<p>Como poderia ser diferente?
Você é o que rastreia.
Você se torna aquilo para o qual otimiza.
Do ponto de vista da plataforma, isso significa: cliques — não qualidade.
No início, maximizar cliques e tempo de visualização pode até parecer algo inofensivo.
Afinal, é preciso gerar receita para sobreviver.
“É só um anúncio. Qual o problema?”</p>
<p>Infelizmente, os problemas são invisíveis no começo.
Assim como o câncer é invisível para quem acabou de fumar o primeiro cigarro,
ou a cirrose para quem bebeu o primeiro gole,
a censura, o banimento, a polarização e a manipulação da opinião pública também são invisíveis para o usuário-produtor (prosumer) que acabou de ver seu primeiro anúncio num ecossistema fechado.</p>
<p>E provavelmente podemos concordar: já passamos da fase inicial desse jogo.
Hoje, censura é regra, banimento é aplaudido, polarização está em níveis históricos, e a opinião pública é manipulada — manual e algorítmicamente — como nunca antes.</p>
<p>O consenso atual parece ser:
você é burro demais para saber o que é bom pra você.
Sua opinião é absurda demais para ser expressa em público.
E o pior:
essa opinião nem deveria ser sua em primeiro lugar.</p>
<pre><code>“Aqui está o motivo de você estar errado.”
“Aqui está uma fonte que aponta para uma opinião permitida.”
“Aqui estão alguns especialistas que concordam conosco.”
“Nossos algoritmos inteligentes e prestativos já pensaram por você — e eles nunca erram.
Nem os especialistas.”
</code></pre>
<p>Esse é o mundo em que já estamos vivendo.</p>
<p>Você não pode falar livremente.
Você não pode pensar livremente.
Você não pode se expressar livremente.</p>
<p>Sua foto é ofensiva? Então precisa ser removida.
Seu meme chegou perto demais da verdade, ou foi engraçado “demais”? Então você vai pra cadeia do Twitter por uma ou duas semanas.
Você disse algo com que “nós” não concordamos? Então será banido para sempre — mesmo que você seja o presidente em exercício, veja bem.
Você falou a “palavra errada” num vídeo, ou tocou uma música com direitos autorais no fundo? Então vamos cortar sua renda.
Você postou uma foto sem máscara? Então vamos te banir e te denunciar às autoridades.</p>
<p>O simples fato de que tudo isso já não é mais ficção científica distópica
deveria ser motivo de preocupação para todos nós.</p>
<p>Removidos do ciberespaço apenas por querer respirar em liberdade.
Tempos estranhos.</p>
<h2 id="pressão-evolutiva">Pressão Evolutiva</h2>
<p>Como chegamos até aqui?</p>
<p>Se eu tivesse que dar uma resposta curta, seria a seguinte:
saímos de protocolos e passamos a viver em plataformas — e plataformas só são tão boas quanto os incentivos que as movem.</p>
<p>A estrutura de incentivos das plataformas que habitamos funciona como um ambiente evolutivo que determina quem sobrevive.
Tudo que quiser continuar existindo precisa se alinhar a esse ambiente.</p>
<p>Claro, isso não vale só para o mundo digital — é verdade em qualquer área de negócio.
Pegue as revistas impressas, por exemplo.
Por razões profundamente humanas e evolutivas, se sua revista não tiver um belo rosto feminino na capa, ela vai vender menos do que aquelas que têm.
Logo, não vai conseguir “se replicar” e, consequentemente, vai morrer.</p>
<p>Da mesma forma, se seu portal de notícias online não gerar receita suficiente com anúncios, ele também não vai se sustentar — e vai desaparecer.
É por isso que toda revista tem um rosto bonito na capa.
E é por isso que todo site de notícias baseado em anúncios acaba virando clickbait.</p>
<p><img alt="faces" loading="lazy" src="/posts/liberdade-valor/faces.png"></p>
<div align="center">“Um desses rostos não é como os outros.”</div>
<p>Da mesma forma, é por isso que os mecanismos de recomendação baseados em feed acabam se transformando em caça-níqueis para os seus receptores de dopamina.</p>
<p>Quanto mais tempo você ficar colado na tela,
mais anúncios vai ver,
mais receita será gerada para a plataforma.</p>
<p>É também por isso que a maioria dos canais no YouTube vira um festival de vídeos de 7 a 15 minutos, com thumbnails mostrando alguém com a cara de quem acabou de pisar em um LEGO.
Curtos o suficiente pra te convencer a clicar,
longos o suficiente pra te fazer esquecer o que queria assistir em primeiro lugar.</p>
<p>Como ratos pressionando botões em caixas de Skinner hiper personalizadas, somos condicionados em ciclos de vício para maximizar o lucro dos acionistas.</p>
<h2 id="maximizando-lucros">Maximizando Lucros</h2>
<p>Plataformas são empresas, e empresas são incentivadas a maximizar os lucros dos seus acionistas.
Não há nada de errado com o lucro — e também nada de errado com os acionistas.</p>
<p>No entanto, acredito que a revolução da informação em que estamos inseridos dividiu o ambiente evolutivo em dois.
Vamos chamar esses dois ambientes de “amplo” e “estreito”.</p>
<p>Para maximizar lucros por meio de publicidade ampla, é preciso minimizar controvérsias e opiniões extremas.
Ou seja, ao tentar agradar ao denominador comum mais baixo, política e censura entram em cena automaticamente.</p>
<p>Por outro lado, quando os lucros vêm de publicidade segmentada e altamente direcionada, o caminho se inverte: é necessário aumentar ao máximo a controvérsia e as opiniões extremas.
Só de mostrar conteúdos diferentes para grupos diferentes, já se está amplificando a polarização e fragmentação constantemente.</p>
<p><img alt="faces" loading="lazy" src="/posts/liberdade-valor/polarization.png"></p>
<div align="center">Coesão de Massa vs. Divisão Algorítmica.</div>
<p>Pode até parecer que estamos falando de TV a cabo vs. feed algorítmico de notícias,
mas, na prática, são apenas duas estratégias diferentes com o mesmo objetivo:
manter o máximo de pessoas coladas na tela para que vejam o máximo possível de anúncios.</p>
<p>A primeira opção age como um sedativo, a segunda como um estimulante.</p>
<p>É verdade, essa caracterização pode parecer exagerada — mas o problema continua sendo o mesmo:
se não estamos pagando diretamente por algo, estamos pagando por ele de outro jeito. Sempre.</p>
<p>O ponto central é este: plataformas de liberdade de expressão não podem existir. Apenas protocolos de liberdade de expressão podem.</p>
<p>Se alguém pode controlar o que está sendo dito, então alguém vai controlar o que está sendo dito.
Se for possível monitorar, filtrar e censurar conteúdo, então isso será feito — inevitavelmente.</p>
<p>Toda plataforma irá se deparar com esse dilema, não importa quão puras sejam suas intenções.</p>
<p>Mesmo que no início você se posicione como uma “plataforma da liberdade de expressão”,
mais cedo ou mais tarde, será forçado a intervir e censurar.</p>
<p>Afinal, se o Estado pode te esmagar por causa do conteúdo que você hospeda ou transmite…
o Estado vai te esmagar por causa do conteúdo que você hospeda ou transmite.</p>
<h2 id="autocensura">Autocensura</h2>
<p>No entanto, muito antes da censura estatal mostrar sua face horrenda,
o efeito paralisante da autocensura já será sentido.</p>
<p>Se outras pessoas são banidas ou desmonetizadas por expressarem certas opiniões,
a maioria das pessoas vai pensar duas vezes antes de dizer o mesmo.
Conscientemente ou não, vamos aos poucos silenciando a nós mesmos.</p>
<p>E no caso da autocensura, a publicidade também tem seu papel.</p>
<p>Afinal, você não morderia a mão que te alimenta, certo?</p>
<p>No pior dos cenários, anunciantes e executivos vão dizer diretamente o que pode ser dito e o que é proibido.
Eles vão te mostrar quais opiniões estão dentro da “janela de Overton” — e quais estão fora dela.</p>
<p>E mesmo que eles não digam nada,
você vai tentar adivinhar — e ajustar seu discurso por conta própria.</p>
<h2 id="um-problema-e-um-paradoxo">Um Problema e um Paradoxo</h2>
<p>Voltando ao problema original: por que não conseguimos vender informação como se fosse um bem comum?
Por que a abordagem mais simples — colocar o conteúdo atrás de um paywall — costuma dar tão errado?</p>
<p>Acredito que isso acontece por dois motivos, que chamarei de “problema do MTX” e “paradoxo do DRM”.</p>
<h3 id="o-problema-do-mtx">O Problema do MTX</h3>
<p>MTX é a abreviação de &ldquo;transação mental&rdquo;, e se refere ao custo psicológico inevitável envolvido em toda transação, por menor que seja.</p>
<p>Toda vez que você bate num paywall, precisa tomar uma decisão consciente:
“Será que vale a pena pagar por isso?”</p>
<p>Como Nick Szabo argumenta de forma convincente, na maioria dos casos — especialmente quando o valor é muito pequeno — a resposta será não.
E não por uma razão técnica, mas por motivos psicológicos:
o simples esforço mental de julgar se aquela microtransação vale ou não a pena já é cansativo demais.</p>
<p>Se você precisa pensar sobre uma microcompra, a chance de realmente realizá-la cai drasticamente.</p>
<p>É por isso que os modelos de assinatura e tarifa fixa reinam:
você só precisa tomar a decisão uma única vez.</p>
<p>Para as microtransações menores, isso vale até do ponto de vista econômico.
Usando como base um salário de US$ 20 por hora,
pensar por dois segundos se algo “vale 21 satoshis” já te custou mais de 1 centavo de dólar,
ou seja, mais do que o valor da própria microtransação.</p>
<p>É inviável — psicologicamente e economicamente.
Isso, em resumo, é o problema do MTX.</p>
<h3 id="o-paradoxo-do-drm">O Paradoxo do DRM</h3>
<p>Mas esse não é o único problema que afeta a monetização de conteúdo digital.
Como já mencionado, existe também o paradoxo do DRM.</p>
<p>DRM, ou &ldquo;gestão de direitos digitais&rdquo;, é um esforço inútil para impedir que a informação seja copiada.
Deveria ser óbvio que informação não copiável é um contrassenso —
mas, em plena era de NFTs e outras bobagens, é melhor deixar isso claro:</p>
<pre><code>Você não pode criar informação que não possa ser copiada. Ponto.
Como disse Bruce Schneier:
“Tentar tornar arquivos digitais não copiáveis é como tentar fazer com que a água não seja molhada.”
</code></pre>
<p>Por sua própria natureza, se uma informação pode ser lida, ela também pode ser copiada — com fidelidade perfeita.Mas esse não é o único problema que afeta a monetização de conteúdo digital.
Como já mencionado, existe também o paradoxo do DRM.</p>
<p>DRM, ou &ldquo;gestão de direitos digitais&rdquo;, é um esforço inútil para impedir que a informação seja copiada.
Deveria ser óbvio que informação não copiável é um contrassenso —
mas, em plena era de NFTs e outras bobagens, é melhor deixar isso claro:</p>
<pre><code>Você não pode criar informação que não possa ser copiada. Ponto.
Como disse Bruce Schneier:
“Tentar tornar arquivos digitais não copiáveis é como tentar fazer com que a água não seja molhada.”
</code></pre>
<p>Por sua própria natureza, se uma informação pode ser lida, ela também pode ser copiada — com fidelidade perfeita.
Nenhuma manobra técnica ou restrição artificial muda esse fato.</p>
<p>É por isso que filmes, músicas e outros conteúdos digitais sempre acabam disponíveis de graça por aí.
É muito fácil para alguém com acesso a esse conteúdo fazer uma cópia — a custo quase zero — e disponibilizá-lo para outras pessoas.</p>
<p>Logo, com tempo e popularidade suficientes, todo filme, toda música, todo documento acabará acessível ao público gratuitamente.
A natureza da informação não permite outro resultado.</p>
<pre><code>Por isso se diz: “A informação quer ser livre.”
</code></pre>
<p>Nenhuma manobra técnica ou restrição artificial muda esse fato.</p>
<p>É por isso que filmes, músicas e outros conteúdos digitais sempre acabam disponíveis de graça por aí.
É muito fácil para alguém com acesso a esse conteúdo fazer uma cópia — a custo quase zero — e disponibilizá-lo para outras pessoas.</p>
<p>Logo, com tempo e popularidade suficientes, todo filme, toda música, todo documento acabará acessível ao público gratuitamente.
A natureza da informação não permite outro resultado.</p>
<pre><code>Por isso se diz: “A informação quer ser livre.”
</code></pre>
<h3 id="mas-o-paradoxo-do-drm-vai-além--e-é-até-engraçado">Mas o paradoxo do DRM vai além — e é até engraçado.</h3>
<p>Embora tentar criar informação incopiável já seja, por si só, uma contradição, não é disso que se trata o verdadeiro paradoxo do DRM.
Ele é ainda mais irônico — e, de novo, mais psicológico do que técnico:</p>
<pre><code>Conteúdo só continua preso atrás de paywall se for ruim.
Se for bom, alguém vai libertá-lo.
</code></pre>
<p>Todo mundo sabe disso.</p>
<p>Se um artigo realmente vale a pena, alguém que tem acesso vai tirar print e postar nas redes sociais.
Se o filme é bom, ele vai aparecer em sites que têm barcos piratas no logotipo.
Se a música vale a audição, ela vai parar em sites de streaming gratuitos.</p>
<p>Só os artigos ruins, os filmes obscuros e as músicas que doem nos ouvidos continuam presos atrás de um paywall.</p>
<pre><code>Daí o paradoxo: se o conteúdo é bom, será libertado.
Se continua trancado, é porque provavelmente não presta.
</code></pre>
<h3 id="mtx-é-um-problema-mais-grave-do-que-o-drm">MTX é um problema mais grave do que o DRM</h3>
<p>Pessoalmente, acho que o problema do MTX é bem mais sério do que o paradoxo do DRM.
A solução tradicional para o MTX é o modelo de assinatura — tipo Netflix, Spotify, Amazon e por aí vai.</p>
<p>O paradoxo do DRM ainda existe, mas deixa de ser um problema quando o acesso &ldquo;legítimo&rdquo; à informação é conveniente o suficiente.</p>
<p>O custo de oportunidade de baixar, guardar, manter e organizar sua coleção privada de músicas é alto demais para a maioria das pessoas.
A solução mais prática é simplesmente pagar a assinatura do Spotify.</p>
<p>Dito isso, já começamos a ver os problemas embutidos no próprio modelo de assinaturas.</p>
<p>E o quadrinho a seguir ilustra isso muito bem…</p>
<p><img alt="piracy" loading="lazy" src="/posts/liberdade-valor/piracy.webp"></p>
<div align="center">Tirinha feita por /u/Hoppy_Doodle</div>
<p>A proliferação de plataformas de streaming te obriga a assinar Netflix, Amazon Prime, Hulu, Disney Plus, YouTube Premium — e por aí vai.
E isso é só para vídeo sob demanda.
O mesmo zoológico de assinaturas existe para música, livros, jogos, newsletters, posts de blog, etc.</p>
<p>Então, qual é a solução?</p>
<h2 id="aceite-a-natureza-da-informação">Aceite a Natureza da Informação</h2>
<p>A solução começa pela aceitação.
Vender conteúdo digital da forma tradicional, baseada em transações pontuais, não funciona — ou pelo menos não funciona muito bem.
Uma transação envolvendo uma fotografia digital de uma maçã é muito diferente de uma envolvendo uma maçã física.</p>
<p>George Bernard Shaw disse isso da melhor forma:
“Se você tem uma maçã e eu tenho uma maçã e trocamos essas maçãs, cada um de nós continuará tendo uma maçã.
Mas se você tem uma ideia e eu tenho uma ideia e trocamos essas ideias, cada um de nós terá duas ideias.”</p>
<p>Como a informação digital se comporta como uma ideia, não faz sentido torná-la artificialmente escassa.
Isso é verdade não só filosoficamente, mas também tecnicamente.
Computadores são máquinas de copiar. Sempre foram, sempre serão.
A única forma de mover informação de uma máquina para outra é copiando-a.
Isso por si só já deixa clara a futilidade de tratar informação como objetos físicos.</p>
<p>Quando se trata de monetizar informação na web aberta, precisamos alinhar nossa forma de pensar com a natureza da informação.
Como vimos, informação é não escassa, facilmente copiada, facilmente modificada e quer ser livre.</p>
<p>Acredito que o modelo certo de monetização precisa respeitar esses valores e ter propriedades semelhantes.
Ele precisa ser aberto, transparente, extensível e, por último — mas não menos importante — completamente voluntário.</p>
<p>Esse modelo tem um nome: valor por valor.</p>
<h2 id="revitalizando-o-artista-de-rua">Revitalizando o Artista de Rua</h2>
<p>A ideia é simples, mas soa radical:
você oferece seu conteúdo gratuitamente, para todos, sem restrições de acesso.
Se as pessoas gostarem, se elas perceberem valor no que você oferece, você facilita para que elas devolvam valor.</p>
<p>Pode parecer absurdo nos dias de hoje,
mas esse modelo funciona há milhares de anos.
É o modelo dos artistas de rua, o modelo dos músicos de calçada, o modelo da doação voluntária.
No ciberespaço, porém, não enfrentamos as limitações físicas do artista de rua tradicional.
Conteúdo digital escala de maneiras que performances no mundo físico jamais conseguirão.</p>
<p>O modelo valor-por-valor inverte o modelo tradicional de pagamento.
Tradicionalmente, o pagamento precede o desfrute.
Na abordagem valor-por-valor, o pagamento segue o desfrute — de forma voluntária.</p>
<p>Você é livre para ouvir o músico de rua e seguir seu caminho,
mas — e isso a plateia intui naturalmente —
se quiser que a música continue, deve jogar algumas moedas no chapéu.</p>
<p>Uma coisa linda desse modelo é que ele realinha os incentivos.
Você não fica tentando maximizar cliques, tempo de visualização ou qualquer outra métrica infinita.
Você vai querer oferecer valor para sua audiência — e só isso.
E se sua audiência tiver tirado valor disso, uma porcentagem vai retribuir.
Tudo que você precisa fazer é pedir.</p>
<h2 id="uma-alternativa-valiosa">Uma Alternativa Valiosa</h2>
<p>Estamos apenas no começo dessa mudança monumental.
Minha esperança é que o modelo valor-por-valor continue a emergir como uma alternativa viável —
uma alternativa à publicidade, censura, banimento e desmonetização.</p>
<p>O modelo valor-por-valor remove o “eles” da equação.
Eles filtram, censuram, desmonetizam, banem.
Nem importa quem são esses “eles”.
Se um “eles” existir, ele vai encontrar um jeito de estragar tudo.</p>
<p>Valor-por-valor elimina o “eles” e coloca você no comando.
Você é o governante no reino do um, único responsável pelos seus pensamentos e sua fala.
Se quisermos liberdade (e salvação) no ciberespaço, precisamos colocar o indivíduo no controle novamente.
Como sempre, liberdade e independência exigem responsabilidade.</p>
<p>No melhor dos mundos, os criadores são incentivados a fazer apenas uma coisa: criar.
Atendendo só a si mesmos e àqueles interessados em suas criações.
Sem intermediários.
Direto, pessoa a pessoa, valor por valor.</p>
<h2 id="o-que-está-por-vir">O Que Está Por Vir</h2>
<p>É verdade que, hoje, não é tão simples hospedar sua própria infraestrutura.
É intimidante rodar seu próprio nó para receber pagamentos de forma autosoberana.
Mas, além de ficar mais fácil, isso será cada vez mais necessário.</p>
<p>Além de facilitar tudo, precisamos estar atentos ao problema do MTX descrito acima.
Cada passo que reduzir o custo mental das transações no ecossistema valor-por-valor é um passo na direção certa.</p>
<p>A capacidade de valor do <a href="https://podcastindex.org/">Podcasting 2.0</a> é um desses passos.
Ela permite e automatiza pagamentos por minuto, sem nenhuma interação extra do usuário.
Uma vez configurado, sua carteira fará os pagamentos automaticamente.</p>
<p>Acredito que futuras versões dessa ideia poderão ser integradas a todos os tipos de mídia,
seja áudio, vídeo, imagens, texto e por aí vai.
Acredito que estamos perto da versão protocolar do Patreon:
todos os benefícios de zerar os custos mentais de transação,
sem o atrito e a censura inerentes a uma solução baseada em plataforma.</p>
<p>Se isso virá na forma de pagamentos recorrentes <a href="http://bolt12.org/">BOLT12</a> ou algo totalmente diferente ainda é cedo para dizer.
Tenho confiança, no entanto, de que vai chegar — e a seu tempo.</p>
<h2 id="conclusão">Conclusão</h2>
<p>Não só nosso dinheiro fiduciário está quebrado, como também o modelo de monetização da internet está falho.
As plataformas baseadas em publicidade dos dias de hoje otimizam o engajamento por meio da divisão e polarização, usando padrões obscuros e vício planejado.</p>
<p>Não será fácil escapar dos ciclos compulsivos que foram armados para nós,
mas graças à pilha tecnológica autosoberana que está surgindo,
existe uma alternativa viável: o modelo valor-por-valor.</p>
<p>O modelo de monetização do “artista de rua” funcionou por muitos séculos no passado,
e graças ao Bitcoin e à Lightning Network, estou confiante de que funcionará por muitos séculos no futuro.
Estamos quase lá.
Só precisamos descobrir como posicionar o chapéu corretamente no chão e quais são os melhores lugares da cidade para se apresentar, por assim dizer.</p>
<p>Valor-por-valor elimina completamente o paradoxo do DRM e — com o nível certo de automação e configurações sensatas —
também resolverá o problema do MTX.</p>
<p>Se acertarmos isso, poderemos nos libertar do ambiente evolutivo de sobrevivência do mais rico das plataformas,
permitindo que entremos no reino quase imortal dos protocolos.</p>
<p>Há muito a explorar, muitas ferramentas a construir e muitas noções preconcebidas a serem quebradas.
Uma mudança sísmica está acontecendo bem diante dos nossos olhos,
e estou ansioso para surfar essas ondas com todos vocês.
Avante!</p>
]]></content:encoded></item></channel></rss>