<div dir="auto">Boas,<div><br><div class="gmail_extra"><br><div class="gmail_quote">On Apr 5, 2017 02:04, "André Esteves" <<a href="mailto:aife@netvisao.pt">aife@netvisao.pt</a>> wrote:<br type="attribution"><blockquote class="quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="quoted-text"><br>
<br>
On 05-04-2017 01:26, Marcos Marado wrote:<br>
> Boas,<br>
><br>
> On Tue, Apr 4, 2017 at 10:50 AM, André Esteves <<a href="mailto:aife@netvisao.pt">aife@netvisao.pt</a>> wrote:<br>
>> Foi preciso embrulhar o Linux num rebuçado para que as massas o<br>
>> engolissem...<br>
>><br>
>> Infelizmente isto só fez com que os blobs binários se multiplicassem.. :(<br>
> Verdade seja dita, o Android não tem culpa alguma que os blobs<br>
> binários se multiplicassem: a situação não era melhor (era até pior)<br>
> noutros telefones, com outros sistemas operativos.<br>
<br>
</div>Mas o número de blobs no kernel não aumentou depois do aparecimento do<br>
Android?</blockquote></div></div></div><div dir="auto"><br></div><div dir="auto">No kernel? Não me parece que haja muito a prática de enfiar lá blobs (pelo menos nos fabricantes que não violam a GPL e publicam o código), ainda que hajam coisas bem feias de ler (como header files que são uma estrutura cheia de valores em hexadecimal, muitas vezes gerado e feito para ser editado por uma ferramenta a que não tens acesso).</div><div dir="auto"><br></div><div dir="auto">Mas vamos mesmo parar ao que me queria referir com o meu comentário anterior: com dispositivos Android tens o kernel (GPL, com suporte específico para aquele hw) e o Android (ainda que não a mesma versão que está a correr no dispositivo). Como não tens a "versão de Android usada pelo vendor" disponível, acabas por ter os tais blobs: alguns que serão para o suporte de algumas HALs (camera, por ex.), e outros para coisas específicas da SoC, e que o fabricante não tem permissão da parte do vendor da SoC para publicar.</div><div dir="auto"><br></div><div dir="auto">Em resumo:</div><div dir="auto">* sem Android (RIM, iOS, dumb phones) não tens nada, com Android tens o kernel e o Android em si, e umas blobs que extraídas permitem que coisas como o LineageOS existam;</div><div dir="auto">* para um fabricante, o maior entrave à não existência de blobs (ie, no cenário "e se a FSF quisesse fazer um telemóvel?") é a SoC usada (o seu fabricante e as suas licenças e restrições).</div><div dir="auto"><br></div><div dir="auto"><div class="gmail_extra"><div class="gmail_quote"><blockquote class="quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="quoted-text">
>> Um dos candidatos mais importantes para reverse engineering pela FSF é o<br>
>> BCM4334 que manda e desmanda nos telemóveis..<br>
>><br>
>> <a href="https://libreplanet.org/wiki/Group:Hardware/ReverseEngineering" rel="noreferrer" target="_blank">https://libreplanet.org/wiki/<wbr>Group:Hardware/<wbr>ReverseEngineering</a><br>
> Reverse Engineering do BCM4334 iria ter algum impacto, em particular<br>
> para o replicant, mas não é grande solução a longo termo: continuas a<br>
> não ter um chipset com software livre que possas simplsmente comprar e<br>
> usar para fazer o teu telemóvel (ou seja, não há quem o possa fazer).<br>
><br>
> Bem mais interessante (IMHO) é algo como isto:<br>
> <a href="https://www.indiegogo.com/projects/free-software-cellular-baseband#/" rel="noreferrer" target="_blank">https://www.indiegogo.com/<wbr>projects/free-software-<wbr>cellular-baseband#/</a><br>
> Ou seja, desenvolver uma baseband 100% com software livre para um<br>
> chipset que podes à vontade comprar, sem NDAs e licenciamentos.<br>
><br>
> Claro que, mesmo aí, estamos a falar de um chipset "velho", e não<br>
> estás a comprá-lo directamente ao fabricante.<br>
> A "long term solution" será um SoC em Open Hardware, algo como o<br>
> <a href="http://www.lowrisc.org/" rel="noreferrer" target="_blank">http://www.lowrisc.org/</a> .<br>
><br>
</div>OU ter um processador com Fpga's abertos. Aí o hardware passa todo a ser<br>
software...<br></blockquote></div></div></div><div dir="auto"><br></div><div dir="auto">Sim, no fundo chamaria isso open hardware à mesma ;-)</div><div dir="auto"><br></div><div dir="auto"><div class="gmail_extra"><div class="gmail_quote"><blockquote class="quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Creio que muitos dos problemas nos drivers são o de lidar com as<br>
idiosincracias dos dispositivos suportados. Creio que, por exemplo, 82%<br>
do código do OpenBSD é só drivers de ethernet e TCP/IP.<br>
Existem implementações de gigabit ethernet no OpenCores que são de<br>
altíssima qualidade...<br>
<br>
1abraço livre,<br>
<br>
André<br>
<br>
<br>______________________________<wbr>_________________<br>
Ansol-socios mailing list<br>
<a href="mailto:Ansol-socios@listas.ansol.org">Ansol-socios@listas.ansol.org</a><br>
<a href="http://listas.ansol.org/mailman/listinfo/ansol-socios" rel="noreferrer" target="_blank">http://listas.ansol.org/<wbr>mailman/listinfo/ansol-socios</a><br>
<br></blockquote></div><br></div></div></div>