Ao longo da evolução dos micros PCs, existiram vários limites de capacidade dos HDs, causados por limitações nos endereços usados pelos BIOS e limitações por parte dos drivers e sistemas operacionais. Instalar um HD IDE de grande capacidade em um micro antigo pode ser bastante frustrante, com o BIOS da placa reconhecendo apenas os primeiros 504 MB ou os primeiros 7.88 GB do HD e o sistema operacional se recusando a carregar depois de instalado.
Estas limitações surgiram devido à falta de visão por parte dos projetistas que desenvolveram o padrão IDE e as instruções INT 13h do BIOS, as responsáveis pelo acesso ao HD. Elas foram originalmente desenvolvidas para serem usadas pelo PC AT (baseado no 286), mas acabaram sendo perpetuadas até os dias de hoje. Naquela época, HDs com mais de 504 MB pareciam uma realidade muito distante.
Ao formatar o HD, ele é dividido em clusters, que são a menor parcela do disco endereçada pelo sistema de arquivos. Cada cluster pode ter de 512 bytes a 32 KB, de acordo com o sistema de arquivos e as opções usadas durante a formatação.
Entretanto, num nível mais baixo, os setores do HD precisam ser endereçados diretamente. Cada setor possui apenas 512 bytes, de forma que é necessária uma grande quantidade de endereços para endereçá-los individualmente.
O padrão IDE reserva 16 bits para o endereçamento dos cilindros (65,536 combinações), 4 bits para o endereçamento das cabeças de leitura (16 combinações) e 8 bits para os setores dentro de cada cilindro (256 combinações), o que permite endereçar um total de 256 milhões de setores. Como cada setor tem sempre 512 bytes, teríamos, a princípio, suporte a HDs de até 128 GB.
Entretanto, o BIOS possui outras limitações para o acesso a discos (serviço chamado de INT 13h), reservando 10 bits para o endereçamento dos cilindros (1,024 combinações), 8 bits para as cabeças de leitura (256) e apenas 6 bits para os setores (63 combinações, pois o endereço 0 é reservado), o que permite endereçar 1.61 milhões de setores e consequentemente discos de até 7.88 GB. Essa configuração é apenas lógica, o modo como o BIOS enxerga o disco rígido, não tem necessariamente relação com a organização real do HD. A placa lógica de um HD de 504 MB pode dizer que tem 16 cabeças leitura e 63 setores por cilindro de forma a utilizar todos os endereços disponibilizados pelo BIOS, mas internamente endereçar os setores de forma diferente. Na prática não faz muita diferença, desde que cada setor receba uma identificação única.
Como é preciso usar tanto a interface IDE quanto as instruções INT 13h do BIOS, acabamos por juntar os dois conjuntos de limitações. O padrão IDE reserva 16 bits para o endereçamento dos cilindros, porém o BIOS só utiliza 10. O BIOS por sua vez reserva 8 bits para o endereçamento das cabeças de leitura, porém só pode utilizar 4 por limitações da interface. A capacidade de endereçamento então acaba sendo nivelada por baixo, combinando as limitações de ambos os padrões, permitindo endereçar discos de no máximo 504 MB, limite para a maioria dos micros 486 ou inferiores. Este método de endereçamento é chamado de Normal ou CHS (cilindro, cabeça de leitura e setor). Esta limitação com relação a HDs de 504 MB foi derrubada com o surgimento do padrão LBA.
Estas limitações surgiram devido à falta de visão por parte dos projetistas que desenvolveram o padrão IDE e as instruções INT 13h do BIOS, as responsáveis pelo acesso ao HD. Elas foram originalmente desenvolvidas para serem usadas pelo PC AT (baseado no 286), mas acabaram sendo perpetuadas até os dias de hoje. Naquela época, HDs com mais de 504 MB pareciam uma realidade muito distante.
Ao formatar o HD, ele é dividido em clusters, que são a menor parcela do disco endereçada pelo sistema de arquivos. Cada cluster pode ter de 512 bytes a 32 KB, de acordo com o sistema de arquivos e as opções usadas durante a formatação.
Entretanto, num nível mais baixo, os setores do HD precisam ser endereçados diretamente. Cada setor possui apenas 512 bytes, de forma que é necessária uma grande quantidade de endereços para endereçá-los individualmente.
O padrão IDE reserva 16 bits para o endereçamento dos cilindros (65,536 combinações), 4 bits para o endereçamento das cabeças de leitura (16 combinações) e 8 bits para os setores dentro de cada cilindro (256 combinações), o que permite endereçar um total de 256 milhões de setores. Como cada setor tem sempre 512 bytes, teríamos, a princípio, suporte a HDs de até 128 GB.
Entretanto, o BIOS possui outras limitações para o acesso a discos (serviço chamado de INT 13h), reservando 10 bits para o endereçamento dos cilindros (1,024 combinações), 8 bits para as cabeças de leitura (256) e apenas 6 bits para os setores (63 combinações, pois o endereço 0 é reservado), o que permite endereçar 1.61 milhões de setores e consequentemente discos de até 7.88 GB. Essa configuração é apenas lógica, o modo como o BIOS enxerga o disco rígido, não tem necessariamente relação com a organização real do HD. A placa lógica de um HD de 504 MB pode dizer que tem 16 cabeças leitura e 63 setores por cilindro de forma a utilizar todos os endereços disponibilizados pelo BIOS, mas internamente endereçar os setores de forma diferente. Na prática não faz muita diferença, desde que cada setor receba uma identificação única.
Como é preciso usar tanto a interface IDE quanto as instruções INT 13h do BIOS, acabamos por juntar os dois conjuntos de limitações. O padrão IDE reserva 16 bits para o endereçamento dos cilindros, porém o BIOS só utiliza 10. O BIOS por sua vez reserva 8 bits para o endereçamento das cabeças de leitura, porém só pode utilizar 4 por limitações da interface. A capacidade de endereçamento então acaba sendo nivelada por baixo, combinando as limitações de ambos os padrões, permitindo endereçar discos de no máximo 504 MB, limite para a maioria dos micros 486 ou inferiores. Este método de endereçamento é chamado de Normal ou CHS (cilindro, cabeça de leitura e setor). Esta limitação com relação a HDs de 504 MB foi derrubada com o surgimento do padrão LBA.
Lei de Moore
Termos técnicos
A "profecia" feita por Gordon Moore, um dos fundadores da Intel, feita durante a década de 70 de que a partir dali a potência dos processadores dobraria a cada 18 meses. A lei de Moore sobreviveu durante mais de duas décadas e ainda não parece ter prazo de validade definido.
Muitos acreditam que os processadores possam continuar dobrando de potência a cada 18 meses, ou até em menos tempo pelos próximos 50 ou 80 anos. Apesar do ciclo evolutivo dos transistores estar próximo do fim, eles ainda devem continuar evoluindo por pelo menos mais uma década, até os limites das técnicas de 0.02 mícron, onde cada gate terá o equivalente a apenas um átomo de ouro de largura. Atualmente estamos migrando dos 0.18 para os 0.13 mícrons, ainda restam pelo menos mais 5 gerações pela frente, as barreiras de 0.10, 0.07, 0.05, 0.03 e 0.02 mícron. Depois disso, ainda restará aos fabricantes otimizar suas arquiteturas e adicionar mais transístores. Esgotadas as possibilidades dos transístores, ainda restam os chips óticos, os nanotubos, os processadores quânticos e o que mais poderá surgir pela frente. A evolução dos computadores não deverá parar tão cedo.
Muitos acreditam que os processadores possam continuar dobrando de potência a cada 18 meses, ou até em menos tempo pelos próximos 50 ou 80 anos. Apesar do ciclo evolutivo dos transistores estar próximo do fim, eles ainda devem continuar evoluindo por pelo menos mais uma década, até os limites das técnicas de 0.02 mícron, onde cada gate terá o equivalente a apenas um átomo de ouro de largura. Atualmente estamos migrando dos 0.18 para os 0.13 mícrons, ainda restam pelo menos mais 5 gerações pela frente, as barreiras de 0.10, 0.07, 0.05, 0.03 e 0.02 mícron. Depois disso, ainda restará aos fabricantes otimizar suas arquiteturas e adicionar mais transístores. Esgotadas as possibilidades dos transístores, ainda restam os chips óticos, os nanotubos, os processadores quânticos e o que mais poderá surgir pela frente. A evolução dos computadores não deverá parar tão cedo.
Lei de Murphy
Termos técnicos
Segundo esta lei "infalível", se algo puder dar errado, pode ter certeza que algum dia realmente dará. O seu HD vai pifar, um vírus vai apagar o BIOS da placa mãe, sua fonte vai explodir, vai acabar a luz dois segundos antes de você salvar uma apresentação que ficou a tarde toda fazendo e o CD onde você tinha gravado um backup de tudo vai explodir dentro do drive :-).
A história oficial conta que Murpy era um pesquisador, que durante a década de 40, fez uma experiência que consistia em monitorar as funções vitais de um paciente usando 80 eletrodos colados em pontos estratégicos do corpo. O tal Murpy conseguiu dar a sorte de colar todos os eletrodos nos lugares errados e a experiência resultou num fracasso completo. Inconformado, ele professou a "lei", que continua em voga por tempo indefinido.
A história oficial conta que Murpy era um pesquisador, que durante a década de 40, fez uma experiência que consistia em monitorar as funções vitais de um paciente usando 80 eletrodos colados em pontos estratégicos do corpo. O tal Murpy conseguiu dar a sorte de colar todos os eletrodos nos lugares errados e a experiência resultou num fracasso completo. Inconformado, ele professou a "lei", que continua em voga por tempo indefinido.
LGPL
Termos técnicos
Library GPL. Esta é uma variação da licença GPL que permite o desenvolvimento de programas de código aberto que contenham módulos proprietários.
Na GPL "tradicional" todo o código do programa é aberto, isso atende bem à maioria dos projetos colaborativos. O problema é que muitas empresas possuem segredos a guardar, o que as impede de simplesmente abrir totalmente o código de seus programas.
A LGPL funciona melhor nestes casos, pois permite que você desenvolva programas "semi abertos" onde parte do código do programa está disponível e o restante das funções é proporcionada por alguns binários que não possuem seu código aberto, estes binários linkados no programa no momento da compilação, de uma forma análoga às DLL's do Windows.
Imagine que você tenha uma empresa que desenvolve um processador de textos no estilo do Word. Depois de algumas noites sem dormir você desenvolve um módulo revolucionário que é capaz de abrir e salvar qualquer tipo de arquivo do Office sem falhas. Isso sem dúvida é um grande diferencial para o seu produto e por isso você resolve não abrir o código fonte, afinal você desenvolveu o software sozinho e pode decidir o que fazer com ele.
A LGPL funcionaria bem no seu caso, pois você poderia abrir o código do seu editor de textos para que outras pessoas possam contribuir com melhorias e correções, mas manter proprietário o módulo que lê arquivos do Office, o grande diferencial que faria as pessoas comprarem o editor ao invés de simplesmente instalar a partir do código fonte.
Na GPL "tradicional" todo o código do programa é aberto, isso atende bem à maioria dos projetos colaborativos. O problema é que muitas empresas possuem segredos a guardar, o que as impede de simplesmente abrir totalmente o código de seus programas.
A LGPL funciona melhor nestes casos, pois permite que você desenvolva programas "semi abertos" onde parte do código do programa está disponível e o restante das funções é proporcionada por alguns binários que não possuem seu código aberto, estes binários linkados no programa no momento da compilação, de uma forma análoga às DLL's do Windows.
Imagine que você tenha uma empresa que desenvolve um processador de textos no estilo do Word. Depois de algumas noites sem dormir você desenvolve um módulo revolucionário que é capaz de abrir e salvar qualquer tipo de arquivo do Office sem falhas. Isso sem dúvida é um grande diferencial para o seu produto e por isso você resolve não abrir o código fonte, afinal você desenvolveu o software sozinho e pode decidir o que fazer com ele.
A LGPL funcionaria bem no seu caso, pois você poderia abrir o código do seu editor de textos para que outras pessoas possam contribuir com melhorias e correções, mas manter proprietário o módulo que lê arquivos do Office, o grande diferencial que faria as pessoas comprarem o editor ao invés de simplesmente instalar a partir do código fonte.
Sem comentários:
Enviar um comentário