Cinnamon 2.0 deverá abandonar o Gnome

[Luis Cardoso]

Explica-me lá, porque raio temos Sistemas 32 e 64 bit! Depois lê novamente o texto que escrevi acima!

Só mais uma informação, eu já programei para processadores mistos, i.e., 8/16 bit e 16/32 bit. Fica sabendo que não precisei de fazer algo em 8, 16 ou 32 em separado. No 8/16 bit e no 16/32, fiz uso das duas propriedades dependo do que queria e da precisão do cálculo pretendido. Aliás, quando estava a trabalhar com o processador de 8/16 bit, cheguei a ter um programa a interagir com duas memórias, uma de 8 bit e outra de 16 bit no seu barramento!

Agora esclarece-me porque temos de ter pacotes de 32 e de 64 bit? Simplifica para quem afinal?

[Luis Cardoso]

Aliás, um aparte. O meu portátil recebeu à pouco tempo o Debian, já experimentei os dois Kernel presentes na versão 32 bit. Também já percebi o porquê do meu portátil se queixar no Ubuntu, trata-se de uma questão de drivers. Porquê? Porque quando uso o Kernel 486 (sem PAE), o PC porta-se lindamente, pouco se ouve a ventoinha, parecendo até um computador novinho. Mas quando vou para o Kernel 686 (com PAE), esquece... Mal o ligo, a ventoinha ouve-se logo, fica um pouco mais lento nos gráficos (não tanto como no Ubuntu, mas o suficiente para dar com o problema). Ora, como eu não tenho mais de 2GB de RAM (quanto mais 4GB), para quê usar o Kernel PAE, que parece introduzir problemas nos drivers, se não preciso de usar a função PAE? Aliás, segundo li, foi este mesmo motivo que atrasou a adopção do Kernel PAE.

[Claudio Novais]

Sobre a pergunta do primeiro post, eu explico com uma pergunta: estás a afirmar que devemos comprar computadores de 64bits e usar software que use instruções apenas de sistemas de 8bits para ficar compatível?

Sobre a questão do segundo post, lá está, queres um kernel otimizado ao teu computador. De preferência um kernel que não contenha drivers da ATI porque não precisas, e de preferência com drivers para o teu disco pois ele tem alguns pormenores interessantes. Tudo bem. Mas explica lá como queres que isto seja possível? 50.000 ISOs por distribuição? Um sistema de deteção de hardware aquando da instalação para compilar o kernel e que provavelmente terá uma probabilidade de falsos positivos na ordem das dezenas (percentagem)?

[Luis Cardoso]

Sobre a pergunta do primeiro post, eu explico com uma pergunta: estás a afirmar que devemos comprar computadores de 64bits e usar software que use instruções apenas de sistemas de 8bits para ficar compatível?

No Windows, ainda usam funções de 16 bit por isso não te admires muito. Se tiveres a necessidade de realizar cálculos de 8 bit, porque não? Faz-me um cálculo de 1+1=2 (bastava apenas 2 bits para este cálculo).

Sobre a questão do segundo post, lá está, queres um kernel otimizado ao teu computador. De preferência um kernel que não contenha drivers da ATI porque não precisas, e de preferência com drivers para o teu disco pois ele tem alguns pormenores interessantes. Tudo bem. Mas explica lá como queres que isto seja possível? 50.000 ISOs por distribuição? Um sistema de deteção de hardware aquando da instalação para compilar o kernel e que provavelmente terá uma probabilidade de falsos positivos na ordem das dezenas (percentagem)?

Estás a perceber tudo bem mal! Eu não quero 50.000 ISOs, quero apenas 1. Actualmente temos para 32 bit, 32 bit (com PAE), 64 bit, ARM, etc, etc... Quando ao ser feita como deve ser, deveria ter apenas 1 ISO.

Custava muito, fazerem:

• Kernel-common → componente responsável por chamar/aceder a cada um dos módulos consoante a sua necessidade:
  
  • 16 bit function list library;
  • 32 bit function list library;
  • 64 bit function list library;
  • 128 bit function list library;
  • 512 bit function list library;
  • ARM extra function list library;
  • ...

Então quem é que quer 50.000 ISOs e quem quer apenas 1?

[Claudio Novais]

A questão das ISOs era relativa aos drivers, algo que já tinhas referido, nomeadamente o facto de não fazer uso de todo o potencial do teu disco.

Sobre o exemplo do Windows, ele é tudo menos um exemplo de qualidade de desenvolvimento. Não estou a criticar no sentido de ele ser fraco ou vulnerável, estou a criticar no sentido de que o Windows tem muitas "engenharias" ao contrário do Linux ter excelentes algoritmos amplamente estudados. Mas avante com isso porque aqui estamos de acordo certamente

Quanto à solução, nunca pensei nisso. No entanto, vendo dessa maneira, temos o exemplo do MBR que atualmente funciona com 8 bits (acho que é este valor, não fui confirmar), o que obrigava os computadores atuais a usarem tais instruções. Um dos motivos do UEFI (e atenção que o UEFI era mais do que preciso; não confundir com secure boot da microsoft) ter nascido é precisamente esse, ter um arranque que use instruções com maior barramento para tornar mais eficaz.

Vendo dessa maneira não sei o que é isso das libs, mas sugeres ter libs replicadas? Significa que em vez de um programa ocupar 1MB passa a ocupar por exemplo 4MB (16, 32, 64, ARM)!?

[Luis Cardoso]

Quanto à solução, nunca pensei nisso. No entanto, vendo dessa maneira, temos o exemplo do MBR que atualmente funciona com 8 bits (acho que é este valor, não fui confirmar), o que obrigava os computadores atuais a usarem tais instruções. Um dos motivos do UEFI (e atenção que o UEFI era mais do que preciso; não confundir com secure boot da microsoft) ter nascido é precisamente esse, ter um arranque que use instruções com maior barramento para tornar mais eficaz.

Vendo dessa maneira não sei o que é isso das libs, mas sugeres ter libs replicadas? Significa que em vez de um programa ocupar 1MB passa a ocupar por exemplo 4MB (16, 32, 64, ARM)!?

O EFI (antepassado do UEFI, o qual apenas fora adoptado pela Apple) tinha como objectivo ajudar a poupar no tamanho do Kernel, criando uma camada total de abstracção do hardware face ao SO. Ora, isto para além de poupar na preocupação em lidar com o hardware, por parte de quem concebe software, aumentava a segurança do utilizador, porque se o SO instalado, fosse infectado, este não afectaria o hardware e nem conseguiria saber que tipo de hardware o utilizador teria. Ou seja, com o EFI não interessava se tinhas CPU de 16, 32, 64 ou 128 bit, se tinhas gráfica AMD ou Nvidia, porque desde que comunicasse com o EFI, o SO iria funcionar sem problemas. Aliás, a M$ foi esperta neste sentido, ou onde pensam que foram conseguir aquela rapidez no seu W8?

Relativamente às libs, refiro-me às libs com as funcionalidades separadas, dependendo do tamanho da palavra. Quanto a duplicadas... Vê-se mesmo que ainda não lidaste com processadores mistos (num nível mais baixo)... Se queres usar o CPU com um comando em 32 bit tens um código, para o mesmo comando em 64 bit, tens outro. É mais fácil percorreres as funções se tiveres as libs separadas e organizadas, do que teres tudo no mesmo programa, disperso. Por algum motivo o Sr. Linus disse que o Kernel estava a ficar gordinho. Existe o problema da desorganização, obrigando a saltos consecutivos em vez de leituras de código mais linear!

[Claudio Novais]

Primeiro: por acaso sei. Mas antes disso, sobre o Linus dizer que está gordo, referia-se claro à quantidade de linhas de código, principalmente pelos drivers acopulados. Claro que as arquiteturas são outro problema, ainda mais agora com a inclusão dos ARM também.

Voltando ao assunto, ok, tenho os mesmos códigos, e agora? Vou usar então os códigos "maiores"? Para quê? para usar maior barramento. Mas afinal agora vou incluir variáveis "grandes" ou pequenas conforme a instrução?! Eu parece-me é que tu não tens noção da complexidade que isso causa. Isto é uma autêntica bola de neve.

<ironia>
Agora, claro que para simplificar podemos sempre usar instruções de 8 bits sempre, ah e já agora usar sempre computadores antigos e juntar em paralelo mais processadores como forma de evolução na velocidade, porque o barramento não interessa muito

/ironia

[Luis Cardoso]

Primeiro: por acaso sei. Mas antes disso, sobre o Linus dizer que está gordo, referia-se claro à quantidade de linhas de código, principalmente pelos drivers acopulados. Claro que as arquiteturas são outro problema, ainda mais agora com a inclusão dos ARM também.

Voltando ao assunto, ok, tenho os mesmos códigos, e agora? Vou usar então os códigos "maiores"? Para quê? para usar maior barramento. Mas afinal agora vou incluir variáveis "grandes" ou pequenas conforme a instrução?! Eu parece-me é que tu não tens noção da complexidade que isso causa. Isto é uma autêntica bola de neve.

<ironia>
Agora, claro que para simplificar podemos sempre usar instruções de 8 bits sempre, ah e já agora usar sempre computadores antigos e juntar em paralelo mais processadores como forma de evolução na velocidade, porque o barramento não interessa muito

/ironia

Bolas, ainda és pior que os burros com as palas nos olhos (estes ainda são obrigados a olhar em frente, agora tu não pah)... Quem disse que tem de ser tudo corrido a 8 bit? Nunca ouviste falar em programação dinâmica? Queres que te passe um código em Fortran que eu fiz para controlar várias centrais eléctricas de modo a fornecer sempre a energia exigida de forma dinâmica (por alguma razão se chama programação dinâmica ).

[Claudio Novais]

Mas qual programação dinâmica? Antes de mais, achas que descobriste a pólvora para os sistemas atuais, não achas?

SObre a programação dinâmica, tendo em conta que cada programa é compilado, para ficar num conjunto de instruções executadas diretametne no servidor, onde é que vais pôr coisa dinâmica? Só mesmo criando uma sandbox (as instruções do processador na prática já o são) no SO mesmo abaixo do próprio Kernel, ou seja, terías um kernel sobre outro kernel.

Se estou errado, sê mais objetivo, pois estou curioso com a descoberta que estás a fazer.

[Luis Cardoso]

Mas qual programação dinâmica? Antes de mais, achas que descobriste a pólvora para os sistemas atuais, não achas?

SObre a programação dinâmica, tendo em conta que cada programa é compilado, para ficar num conjunto de instruções executadas diretametne no servidor, onde é que vais pôr coisa dinâmica? Só mesmo criando uma sandbox (as instruções do processador na prática já o são) no SO mesmo abaixo do próprio Kernel, ou seja, terías um kernel sobre outro kernel.

Se estou errado, sê mais objetivo, pois estou curioso com a descoberta que estás a fazer.

A descoberta não é minha, é de quem trabalha com sistemas embutidos... Eu prefiro a topologia KISS, e pelo que vejo, já estou a perceber o porquê dos problemas em torno do UEFI. Os que tratam do hardware e do software andam a debater-se com questões como estas e não se entendem... Acabando por trazer problemas

Eu não me vou alongar mais, senão daqui a nada dou uma aula de micro-processadores... Como encadear comandos, como lidar com as memórias, como gerir os periféricos e como mapeá-los! Depois ainda acabávamos por construir um micro-kernel e cada um ficava com o seu próprio SO... Nah!