Pessoal,
Essa dica me ajudou muito quando tive que fazer uma migração, de uma distro para outra:
Após fazer o backup do /HOME, pensei: E os programas instalados?
A solução é simples:
O "dpkg -l" mostra todos os pacotes instalados no sistema, então se eu soltar um
dpkg -l > pacotes.txt
vai me criar um arquivo de texto, com todos os pacotes instalados.
Se esse arquivo estiver na instalação nova, vai bastar um
cat pacotes.txt | sudo awk '{system("apt-get install "$2)}'
para instalar todos os pacotes de volta.
P.S. Demora um pouco, mas no final, volta tudo como era antes.
Se alguém tiver uma dica melhor, ou uma maneira de fazer isso com mais facilidade, sinta-se a vontade para comentar.
Abraços!
sexta-feira, agosto 24, 2007
segunda-feira, agosto 06, 2007
Mais um evento: Linuxchix
Pessoal, nos dias 7 e 8 de Setembro, no IESB, acontecerá o "Encontro Nacional Linuxchix Brasil".
Confira a grade do evento.
http://www.linuxchix.org.br/?q=node/118
A inscrição sai por R$ 15,00 (isso mesmo, você leu certo... só quinze reais) que dão direito a assistir todas as palestras e mini-cursos. Não há lista ou inscrições especiais para os cursos, portanto, chegue cedo para garantir seu lugar!! Kit e lanche estão inclusos na inscrição.
PS. Se alguém achou que os "só 15 reais" foi algum tipo de cinismo ou algo do gênero de minha parte,
saiba que algumas dessas palestras não sairiam por menos de 400 reais, por pessoa... Aproveitem o máximo possível esse evento.
Confira a grade do evento.
http://www.linuxchix.org.br/?q=node/118
A inscrição sai por R$ 15,00 (isso mesmo, você leu certo... só quinze reais) que dão direito a assistir todas as palestras e mini-cursos. Não há lista ou inscrições especiais para os cursos, portanto, chegue cedo para garantir seu lugar!! Kit e lanche estão inclusos na inscrição.
PS. Se alguém achou que os "só 15 reais" foi algum tipo de cinismo ou algo do gênero de minha parte,
saiba que algumas dessas palestras não sairiam por menos de 400 reais, por pessoa... Aproveitem o máximo possível esse evento.
sexta-feira, agosto 03, 2007
Os sete pecados do software livre
Ponto de vista interessante. Não concordo com tudo que está escrito aí, mas vale a pena dar uma lida.
Abraços!
---
Os sete pecados do software livre
Pensaram que íamos ficar só nos elogios ao mundo do open source? Que nada. Como qualquer coisa, o modelo de desenvolvimento de código aberto também tem sua dose de problemas. Veja, a seguir, os mais citados por aqueles que acreditam que software proprietário ainda tem vez:
1 – Custo: pode parecer difícil competir com algo que muitas vezes é grátis, mas é preciso lembrar de que o software livre continua tendo custos de suporte e treinamento – este último freqüentemente mais caro do que no mundo dos programas proprietários, já que a maioria dos profissionais já está acostumada a eles e precisa reaprender uma série de atividades nos programas abertos.
2 – Interface: não estamos falando de beleza, mas de facilidade de uso. Embora existam exceções, muitos programas abertos são construídos de acordo com a lógica dos programadores envolvidos, o que pode não fazer sentido nenhum para o usuário. Em outras palavras, são difíceis para uma pessoa comum usar simplesmente porque não foram feitos para ela, mas para outros programadores.
3 – Documentação: programadores gostam de programar, não de escrever manuais. Sem uma área dedicada ou a obrigação de fazê-la, por que dedicar tempo a produzir ou manter atualizados os guias de seus softwares? Pior: mesmo quando a documentação existe, é escrita para quem já conhece a tecnologia a fundo. Assim como a interface, acaba excluindo o usuário comum.
4 – Restrições contratuais: embora uma das virtudes do software livre seja a possibilidade de qualquer um modificá-lo, quando se compra um pacote open source ou contrata uma empresa para dar suporte a determinado programa, umas das condições do contrato é que você não altere nada no código, para não inviabilizar o suporte. Ou seja: no final, é praticamente um retorno ao modelo fechado.
5 – Estímulo: as associações de produtores de software fechado adoram defender este ponto: sem a possibilidade de proteger seu trabalho intelectual para lucrar com ele, há pouco estímulo para empresas e programadores independentes (exceto no meio acadêmico) dedicarem esforços ao software. Os bilionários da indústria de software nunca teriam chegado lá se tudo o que criaram fosse aberto.
6 – Organização: dizem que a imagem de centenas de programadores espalhados pelo mundo, colaborando espontaneamente com um projeto, não passa de um mito. Os projetos open source bem sucedidos seriam aqueles em que há um pequeno núcleo de pessoas coordenando o projeto, ainda que apoiados por uma comunidade maior. Quando vira anarquia, a evolução do programa se torna lenta ou simplesmente pára.
7 – Abertura: o modelo sem compromissos comerciais permite que se criem novos recursos indefinidamente, muitas vezes em detrimento do aperfeiçoamento do que já existe e sem preocupação com datas de entrega. Em longo prazo isso pode ser bom, mas para quem está esperando um novo release mais estável de um programa, é complicado não ter nem de quem cobrar um cronograma.
Fonte: parte dos pontos abordados aqui foi adaptada de questões levantadas por Michelle Levesque, em Fundamental issues with open source software development.
http://br.tecnologia.yahoo.com/070801/54/1mvim.html
Abraços!
---
Os sete pecados do software livre
Pensaram que íamos ficar só nos elogios ao mundo do open source? Que nada. Como qualquer coisa, o modelo de desenvolvimento de código aberto também tem sua dose de problemas. Veja, a seguir, os mais citados por aqueles que acreditam que software proprietário ainda tem vez:
1 – Custo: pode parecer difícil competir com algo que muitas vezes é grátis, mas é preciso lembrar de que o software livre continua tendo custos de suporte e treinamento – este último freqüentemente mais caro do que no mundo dos programas proprietários, já que a maioria dos profissionais já está acostumada a eles e precisa reaprender uma série de atividades nos programas abertos.
2 – Interface: não estamos falando de beleza, mas de facilidade de uso. Embora existam exceções, muitos programas abertos são construídos de acordo com a lógica dos programadores envolvidos, o que pode não fazer sentido nenhum para o usuário. Em outras palavras, são difíceis para uma pessoa comum usar simplesmente porque não foram feitos para ela, mas para outros programadores.
3 – Documentação: programadores gostam de programar, não de escrever manuais. Sem uma área dedicada ou a obrigação de fazê-la, por que dedicar tempo a produzir ou manter atualizados os guias de seus softwares? Pior: mesmo quando a documentação existe, é escrita para quem já conhece a tecnologia a fundo. Assim como a interface, acaba excluindo o usuário comum.
4 – Restrições contratuais: embora uma das virtudes do software livre seja a possibilidade de qualquer um modificá-lo, quando se compra um pacote open source ou contrata uma empresa para dar suporte a determinado programa, umas das condições do contrato é que você não altere nada no código, para não inviabilizar o suporte. Ou seja: no final, é praticamente um retorno ao modelo fechado.
5 – Estímulo: as associações de produtores de software fechado adoram defender este ponto: sem a possibilidade de proteger seu trabalho intelectual para lucrar com ele, há pouco estímulo para empresas e programadores independentes (exceto no meio acadêmico) dedicarem esforços ao software. Os bilionários da indústria de software nunca teriam chegado lá se tudo o que criaram fosse aberto.
6 – Organização: dizem que a imagem de centenas de programadores espalhados pelo mundo, colaborando espontaneamente com um projeto, não passa de um mito. Os projetos open source bem sucedidos seriam aqueles em que há um pequeno núcleo de pessoas coordenando o projeto, ainda que apoiados por uma comunidade maior. Quando vira anarquia, a evolução do programa se torna lenta ou simplesmente pára.
7 – Abertura: o modelo sem compromissos comerciais permite que se criem novos recursos indefinidamente, muitas vezes em detrimento do aperfeiçoamento do que já existe e sem preocupação com datas de entrega. Em longo prazo isso pode ser bom, mas para quem está esperando um novo release mais estável de um programa, é complicado não ter nem de quem cobrar um cronograma.
Fonte: parte dos pontos abordados aqui foi adaptada de questões levantadas por Michelle Levesque, em Fundamental issues with open source software development.
http://br.tecnologia.yahoo.com/070801/54/1mvim.html
Assinar:
Postagens (Atom)
