Novo kit de desenvolvimento permitirá mais drivers de impressoras independentes de distribuição
A Linux Foundation publicou um novo kit de desenvolvimento de drivers para impressoras, projetado para facilitar aos produtores de impressoras o desenvolvimento de drivers que rodem em qualquer distribuição de Linux que atenda aos padrões definidos no LSB. O projeto OpenPrinting criou este kit como um passo a mais para prover melhor suporte a impressoras no Linux.
Uma nova API web também é parte do kit de desenvolvimento, para conexão à base de dados de impressoras do OpenPrinting, facilitando localizar e instalar o driver correto para uma impressora, caso a distribuição não o inclua.
Saiba mais (heise.de).
Uma nova API web também é parte do kit de desenvolvimento, para conexão à base de dados de impressoras do OpenPrinting, facilitando localizar e instalar o driver correto para uma impressora, caso a distribuição não o inclua.
Saiba mais (heise.de).
(postado por Augusto Campos)
Comentários dos leitores
Comentário de nome
20/06/07 16:54
Jura?: Cara, não há um critério homogêneo que diga que 100% das bibliotecas seguem o mesmo ciclo de desenvolvimento, mas a maioria mantém a compatibilidade no z+1. Certamente a maioria daquelas mais comuns que você vai precisar usam mantêm. Cita aí um exemplo, só para eu ter que me calar. Não vale procurar por MFC no Linux :)
Comentário de emanuelsan
20/06/07 22:32 - usuário registrado #5843
Compatibilidades: Caro MarcosAlex, eu tenho opinião, bem diversa.
É claro que é uma impressão, que foi até reforçada ontem, quando precisei instalar um programa aqui no trabalho.
Mas antes de explicar, faço uma pequena correção. A compatibilidade deve ser cobrada da versão mais nova e não em cima da versão mais antiga. Assim vc deveria cobrar que a tal x.y.(z+1) seja compatível com a x.y.z e não o contrário.
Agora veja o meu exemplo de compatibilidade de uma biblioteca na versão (x+1).y.z.
O programa que eu queria vinha num arquivo RPM, era um cliente Citrix, desenvolvido pela própria, meu computador está rodando o Fedora 7. O comando rpm reclamava da inexistência da biblioteca libXm.so.3.
Seguindo uma dica, que achei na internet, instalei o pacote openmotif que vêm no Fedora 5 e que possui o arquivo libXm.so.4.0.0 (e o link libXm.so.4), depois fiz um link para este arquivo usando o nome libXm.so.3. Então instalei o programa (com --nodeps), e ele funcionou. Repliquei a experiência com mais 2 colegas que precisavam desse programa e o estão usando continuamente.
Conclusão: cada caso é um caso, os caras que desenvolveram a libXm souberam preservar a compatibilidade da 4.0.0 com a 3.0.0, o que não quer dizer que outros projetos sejam tão felizes assim , mas acredito que de uma versão x.y.z para uma x.y.(z+1) não haja diferenças em termos de API e esperemos que os desenvolvedores sigam essa convenção, mas lembre-se que isso não é uma lei da física.
É claro que é uma impressão, que foi até reforçada ontem, quando precisei instalar um programa aqui no trabalho.
Mas antes de explicar, faço uma pequena correção. A compatibilidade deve ser cobrada da versão mais nova e não em cima da versão mais antiga. Assim vc deveria cobrar que a tal x.y.(z+1) seja compatível com a x.y.z e não o contrário.
Agora veja o meu exemplo de compatibilidade de uma biblioteca na versão (x+1).y.z.
O programa que eu queria vinha num arquivo RPM, era um cliente Citrix, desenvolvido pela própria, meu computador está rodando o Fedora 7. O comando rpm reclamava da inexistência da biblioteca libXm.so.3.
Seguindo uma dica, que achei na internet, instalei o pacote openmotif que vêm no Fedora 5 e que possui o arquivo libXm.so.4.0.0 (e o link libXm.so.4), depois fiz um link para este arquivo usando o nome libXm.so.3. Então instalei o programa (com --nodeps), e ele funcionou. Repliquei a experiência com mais 2 colegas que precisavam desse programa e o estão usando continuamente.
Conclusão: cada caso é um caso, os caras que desenvolveram a libXm souberam preservar a compatibilidade da 4.0.0 com a 3.0.0, o que não quer dizer que outros projetos sejam tão felizes assim , mas acredito que de uma versão x.y.z para uma x.y.(z+1) não haja diferenças em termos de API e esperemos que os desenvolvedores sigam essa convenção, mas lembre-se que isso não é uma lei da física.
Comentário de Manoel Pinho
22/06/07 19:34 - usuário registrado #8
Cups: Pois é, o cups virou o padrão no MacOS X e no linux, suplantando o velho sistema lpd dos Unices. Tenho certeza que não vai demorar muito para todos os Unices que ainda usam o lpd também adotem o cups.
Só o windows que continua com a aberração de usar um sistema de impressão incompatível com todo mundo e permitir aberrações como impressoras GDI, quase sempre as mais baratas e portanto populares, que são uma bomba para usar com linux.
Se a M$ quisesse realmente interoperabilidade poderia adotar o cups também, mas todos sabemos que ela não quer interoperabilidade mesmo.
Só o windows que continua com a aberração de usar um sistema de impressão incompatível com todo mundo e permitir aberrações como impressoras GDI, quase sempre as mais baratas e portanto populares, que são uma bomba para usar com linux.
Se a M$ quisesse realmente interoperabilidade poderia adotar o cups também, mas todos sabemos que ela não quer interoperabilidade mesmo.
Agora, uma coisa que sempre me atrapalhou quando desenvolvo algo pra Linux, é que a versão x.y.z de uma biblioteca, nem sempre é compatível com a x.y.z+1. Várias bibliotecas livres tem essa característica, e isso é complicado para o desenvolvedor, já que cada distro pode vir com uma versão diferente pré instalada, e o pacote precisa verificar dependências.
Haskell developer