[Ansol-socios] Re: [ANSOL-geral] Android passa windows como OS mais usado para usar a web...

[Marcos Marado]

Boas,


On Apr 5, 2017 02:04, "André Esteves" <aife  netvisao.pt> wrote:



On 05-04-2017 01:26, Marcos Marado wrote:
> Boas,
>
> On Tue, Apr 4, 2017 at 10:50 AM, André Esteves <aife  netvisao.pt> wrote:
>> Foi preciso embrulhar o Linux num rebuçado para que as massas o
>> engolissem...
>>
>> Infelizmente isto só fez com que os blobs binários se multiplicassem.. :(
> Verdade seja dita, o Android não tem culpa alguma que os blobs
> binários se multiplicassem: a situação não era melhor (era até pior)
> noutros telefones, com outros sistemas operativos.

Mas o número de blobs no kernel não aumentou depois do aparecimento do
Android?


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).

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.

Em resumo:
* 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;
* 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).

>> Um dos candidatos mais importantes para reverse engineering pela FSF é o
>> BCM4334 que manda e desmanda nos telemóveis..
>>
>> https://libreplanet.org/wiki/Group:Hardware/ReverseEngineering
> Reverse Engineering do BCM4334 iria ter algum impacto, em particular
> para o replicant, mas não é grande solução a longo termo: continuas a
> não ter um chipset com software livre que possas simplsmente comprar e
> usar para fazer o teu telemóvel (ou seja, não há quem o possa fazer).
>
> Bem mais interessante (IMHO) é algo como isto:
> https://www.indiegogo.com/projects/free-software-cellular-baseband#/
> Ou seja, desenvolver uma baseband 100% com software livre para um
> chipset que podes à vontade comprar, sem NDAs e licenciamentos.
>
> Claro que, mesmo aí, estamos a falar de um chipset "velho", e não
> estás a comprá-lo directamente ao fabricante.
> A "long term solution" será um SoC em Open Hardware, algo como o
> http://www.lowrisc.org/ .
>
OU ter um processador com Fpga's abertos. Aí o hardware passa todo a ser
software...


Sim, no fundo chamaria isso open hardware à mesma ;-)

Creio que muitos dos problemas nos drivers são o de lidar com as
idiosincracias dos dispositivos suportados. Creio que, por exemplo, 82%
do código do OpenBSD é só drivers de ethernet e TCP/IP.
Existem implementações de gigabit ethernet no OpenCores que são de
altíssima qualidade...

1abraço livre,

André


_______________________________________________
Ansol-socios mailing list
Ansol-socios  listas.ansol.org
http://listas.ansol.org/mailman/listinfo/ansol-socios
-------------- próxima parte ----------
Um anexo em HTML foi limpo...
URL: http://listas.ansol.org/pipermail/ansol-geral/attachments/20170405/6da21f56/attachment.htm