sábado, 30 de janeiro de 2016
sexta-feira, 29 de janeiro de 2016
Linux e Windows NT -- Uma comparação de desempenho
Fonte http://www.dicas-l.com.br/
Alguns tempos atrás resolvi realizar uma comparação entre sistemas Linux e Windows NT. Fiz apenas uma comparação do desempenho da transferência de arquivos com o programa FTP. Não pude utilizar equipamentos idênticos, mas optei por uma configuração igualmente polêmica. Um ultrapassado 486 contra um Pentium 200 MMX.
A máquina rodando Linux é um 486DX/66, com 32 MB de memória, fabricado em 1993. O sistema operacional é o Conectiva Linux, versão do kernel 2.0.38. O MTU da interface ethernet do Linux é de 1500 bytes.
A estação NT é um Pentium 200/MMX, com 64 MB de memória, fabricado em 1998. O sistema operacional desta máquina é Windows NT server versão 4.0.
Realizei cinco transferências, usando FTP, em cada máquina, de um arquivo de 19MB de tamanho. Todas as duas máquinas estão conectadas na mesma subrede, uma ethernet a 10Mbits/s. As transferências foram intercaladas. Primeiro o Linux, depois NT e assim sucessivamente. Nenhuma das duas máquinas estava rodando processos que pudessem interferir no seu desempenho.
Em todas as transferências o Linux ganhou. Considerando-se que as duas máquinas são brutalmente diferentes em termos de performance, dá para se notar que a implementação TCP/IP do Linux é consideravelmente melhor do que a do Windows NT server no tocante ao aspecto analisado, a saber, transferência de arquivos usando FTP.
Abaixo incluo as linhas de resultados das transferências nos dois sistemas. A média de tempo do Linux foi de 23,4 segundos, e a média da taxa de transferência foi de 816 kbytes/segundo. No NT a média de tempo foi de 29,51 segundos e a taxa de transferência foi de 664,60 kbytes/segundo. O Linux obteve um resultado 28% melhor no tempo de transferência em relação ao NT.
Linux
1. 19529038 bytes received in 22.3 secs (8.5e+02 Kbytes/sec)
2. 19529038 bytes received in 22.6 secs (8.4e+02 Kbytes/sec)
3. 19529038 bytes received in 26.4 secs (7.2e+02 Kbytes/sec)
4. 19529038 bytes received in 23 secs (8.3e+02 Kbytes/sec)
5. 19529038 bytes received in 22.7 secs (8.4e+02 Kbytes/sec)
Windows NT
1. 19529038 bytes received in 30,7 secs (649,39 kbytes/sec)
2. 19529038 bytes received in 29,20 secs (668,76 kbytes/sec)
3. 19529038 bytes received in 29,06 secs (671,98 kbytes/sec)
4. 19529038 bytes received in 28,96 secs (674,30 kbytes/sec)
5. 19529038 bytes received in 29,65 secs (658,59 kbytes/sec)
No teste acima, o Windows NT levou uma grande vantagem por estar instalado em uma máquina mais moderna e com discos mais rápidos. Desta forma a taxa de transferência foi afetada pelo tempo de gravação em disco, consideravelmente maior no micro mais obsoleto no tocante a hardware, o 486. Para eliminar esta disparidade, realizei uma outra medição, desta vez sem realizar a gravação em disco.
O arquivo transferido foi gravado no Linux em /dev/null, que na verdade é um buraco negro do Unix, ou seja, nada é gravado. O dispositivo equivalente no Windows NT é ``nul''. O tempo de transferência não sofre o impacto do I/O e podemos ter uma boa idéia de quanto tempo efetivamente foi gasto apenas no trânsito dos dados via rede.
Nesta outra medição utilizei o comando wget. No NT a sintaxe do comando foi:
wget -O null [1]ftp://ftp.unicamp.br/pub/dicas-l.zip
No Linux a sintaxe do comando foi:
wget -O /dev/null [2]ftp://ftp.unicamp.br/pub/dicas-l.zip
Os dados obtidos neste teste estão incluídos abaixo. Foram feitas dez medições em cada sistema.
WindowsNT
12:45:25 (631.78 KB/s) - `nul' saved [2587767]
12:46:22 (631.78 KB/s) - `nul' saved [2587767]
12:46:22 (631.78 KB/s) - `nul' saved [2587767]
12:46:47 (631.78 KB/s) - `nul' saved [2587767]
12:47:05 (631.78 KB/s) - `nul' saved [2587767]
12:47:20 (631.78 KB/s) - `nul' saved [2587767]
12:47:34 (505.42 KB/s) - `nul' saved [2587767]
12:51:17 (631.78 KB/s) - `nul' saved [2587767]
12:51:49 (631.78 KB/s) - `nul' saved [2587767]
12:52:24 (631.78 KB/s) - `nul' saved [2587767]
Linux
09:45:29 (711.26 KB/s) - `/dev/null' recebido [2587767]
09:45:48 (751.00 KB/s) - `/dev/null' recebido [2587767]
09:46:10 (719.98 KB/s) - `/dev/null' recebido [2587767]
09:46:22 (779.25 KB/s) - `/dev/null' recebido [2587767]
09:46:34 (736.12 KB/s) - `/dev/null' recebido [2587767]
09:46:45 (724.31 KB/s) - `/dev/null' recebido [2587767]
09:46:56 (720.59 KB/s) - `/dev/null' recebido [2587767]
09:47:07 (706.69 KB/s) - `/dev/null' recebido [2587767]
09:47:18 (684.30 KB/s) - `/dev/null' recebido [2587767]
09:47:35 (661.90 KB/s) - `/dev/null' recebido [2587767]
Na média, a máquina Linux teve uma performance em 15% superior. Este valor é claro não é o correto para uma avaliação de desempenho visto a enorme diferença entre os dois equipamentos. Mas já dá para ter uma idéia do enorme poder do Linux, que é de graça.
Alguns tempos atrás resolvi realizar uma comparação entre sistemas Linux e Windows NT. Fiz apenas uma comparação do desempenho da transferência de arquivos com o programa FTP. Não pude utilizar equipamentos idênticos, mas optei por uma configuração igualmente polêmica. Um ultrapassado 486 contra um Pentium 200 MMX.
A máquina rodando Linux é um 486DX/66, com 32 MB de memória, fabricado em 1993. O sistema operacional é o Conectiva Linux, versão do kernel 2.0.38. O MTU da interface ethernet do Linux é de 1500 bytes.
A estação NT é um Pentium 200/MMX, com 64 MB de memória, fabricado em 1998. O sistema operacional desta máquina é Windows NT server versão 4.0.
Realizei cinco transferências, usando FTP, em cada máquina, de um arquivo de 19MB de tamanho. Todas as duas máquinas estão conectadas na mesma subrede, uma ethernet a 10Mbits/s. As transferências foram intercaladas. Primeiro o Linux, depois NT e assim sucessivamente. Nenhuma das duas máquinas estava rodando processos que pudessem interferir no seu desempenho.
Em todas as transferências o Linux ganhou. Considerando-se que as duas máquinas são brutalmente diferentes em termos de performance, dá para se notar que a implementação TCP/IP do Linux é consideravelmente melhor do que a do Windows NT server no tocante ao aspecto analisado, a saber, transferência de arquivos usando FTP.
Abaixo incluo as linhas de resultados das transferências nos dois sistemas. A média de tempo do Linux foi de 23,4 segundos, e a média da taxa de transferência foi de 816 kbytes/segundo. No NT a média de tempo foi de 29,51 segundos e a taxa de transferência foi de 664,60 kbytes/segundo. O Linux obteve um resultado 28% melhor no tempo de transferência em relação ao NT.
Linux
1. 19529038 bytes received in 22.3 secs (8.5e+02 Kbytes/sec)
2. 19529038 bytes received in 22.6 secs (8.4e+02 Kbytes/sec)
3. 19529038 bytes received in 26.4 secs (7.2e+02 Kbytes/sec)
4. 19529038 bytes received in 23 secs (8.3e+02 Kbytes/sec)
5. 19529038 bytes received in 22.7 secs (8.4e+02 Kbytes/sec)
Windows NT
1. 19529038 bytes received in 30,7 secs (649,39 kbytes/sec)
2. 19529038 bytes received in 29,20 secs (668,76 kbytes/sec)
3. 19529038 bytes received in 29,06 secs (671,98 kbytes/sec)
4. 19529038 bytes received in 28,96 secs (674,30 kbytes/sec)
5. 19529038 bytes received in 29,65 secs (658,59 kbytes/sec)
No teste acima, o Windows NT levou uma grande vantagem por estar instalado em uma máquina mais moderna e com discos mais rápidos. Desta forma a taxa de transferência foi afetada pelo tempo de gravação em disco, consideravelmente maior no micro mais obsoleto no tocante a hardware, o 486. Para eliminar esta disparidade, realizei uma outra medição, desta vez sem realizar a gravação em disco.
O arquivo transferido foi gravado no Linux em /dev/null, que na verdade é um buraco negro do Unix, ou seja, nada é gravado. O dispositivo equivalente no Windows NT é ``nul''. O tempo de transferência não sofre o impacto do I/O e podemos ter uma boa idéia de quanto tempo efetivamente foi gasto apenas no trânsito dos dados via rede.
Nesta outra medição utilizei o comando wget. No NT a sintaxe do comando foi:
wget -O null [1]ftp://ftp.unicamp.br/pub/dicas-l.zip
No Linux a sintaxe do comando foi:
wget -O /dev/null [2]ftp://ftp.unicamp.br/pub/dicas-l.zip
Os dados obtidos neste teste estão incluídos abaixo. Foram feitas dez medições em cada sistema.
WindowsNT
12:45:25 (631.78 KB/s) - `nul' saved [2587767]
12:46:22 (631.78 KB/s) - `nul' saved [2587767]
12:46:22 (631.78 KB/s) - `nul' saved [2587767]
12:46:47 (631.78 KB/s) - `nul' saved [2587767]
12:47:05 (631.78 KB/s) - `nul' saved [2587767]
12:47:20 (631.78 KB/s) - `nul' saved [2587767]
12:47:34 (505.42 KB/s) - `nul' saved [2587767]
12:51:17 (631.78 KB/s) - `nul' saved [2587767]
12:51:49 (631.78 KB/s) - `nul' saved [2587767]
12:52:24 (631.78 KB/s) - `nul' saved [2587767]
Linux
09:45:29 (711.26 KB/s) - `/dev/null' recebido [2587767]
09:45:48 (751.00 KB/s) - `/dev/null' recebido [2587767]
09:46:10 (719.98 KB/s) - `/dev/null' recebido [2587767]
09:46:22 (779.25 KB/s) - `/dev/null' recebido [2587767]
09:46:34 (736.12 KB/s) - `/dev/null' recebido [2587767]
09:46:45 (724.31 KB/s) - `/dev/null' recebido [2587767]
09:46:56 (720.59 KB/s) - `/dev/null' recebido [2587767]
09:47:07 (706.69 KB/s) - `/dev/null' recebido [2587767]
09:47:18 (684.30 KB/s) - `/dev/null' recebido [2587767]
09:47:35 (661.90 KB/s) - `/dev/null' recebido [2587767]
Na média, a máquina Linux teve uma performance em 15% superior. Este valor é claro não é o correto para uma avaliação de desempenho visto a enorme diferença entre os dois equipamentos. Mas já dá para ter uma idéia do enorme poder do Linux, que é de graça.
quarta-feira, 27 de janeiro de 2016
Como desmontar sistemas de arquivos em uso
Colaboração: Rubens Queiroz de Almeida
Para desmontar sistemas de arquivos em uso, a melhor opção é combinar a saída do programa lsof com o comando kill. É claro que você vai avisar seus usuários antes para que eles possam encerrar suas tarefas com antecedência.
O comando lsof, ou List Open Files, indica todos os processos que estão acessando determinado arquivo ou filesystem. Veja um exemplo da saída deste programa:
% lsof /home
COMMAND PID USER FD TYPE DEVICE SIZE/OFF INODE NAME
lsof 19958 queiroz cwd VDIR 10, 8 5120 1024 /home (/d)
ksh 26800 queiroz cwd VDIR 10, 8 5120 1024 /home (/d)
ksh 26800 queiroz 63u VREG 10, 8 2384 1060 /home (/d)
lsof 28152 queiroz cwd VDIR 10, 8 5120 1024 /home (/d)
A segunda coluna indica a identificação do processo, o que nos interessa mais diretamente. Vejamos então o script:
#!/bin/sh
for pid in ""lsof /home | grep -v COMMAND | awk '{print $2}'""
do
kill -9 $pid
done
umount /home
O umount tem que ser dado imediatamente após o falecimento dos processos que estão acessando o filesystem em questão para evitar que novos processos sejam criados, novamente impedindo o umount.
O pacote lsof pode ser encontrado no servidor de ftp anônimo da Unicamp em http://ftp.unicamp.br/pub/unix-tools/lsof.
Para desmontar sistemas de arquivos em uso, a melhor opção é combinar a saída do programa lsof com o comando kill. É claro que você vai avisar seus usuários antes para que eles possam encerrar suas tarefas com antecedência.
O comando lsof, ou List Open Files, indica todos os processos que estão acessando determinado arquivo ou filesystem. Veja um exemplo da saída deste programa:
% lsof /home
COMMAND PID USER FD TYPE DEVICE SIZE/OFF INODE NAME
lsof 19958 queiroz cwd VDIR 10, 8 5120 1024 /home (/d)
ksh 26800 queiroz cwd VDIR 10, 8 5120 1024 /home (/d)
ksh 26800 queiroz 63u VREG 10, 8 2384 1060 /home (/d)
lsof 28152 queiroz cwd VDIR 10, 8 5120 1024 /home (/d)
A segunda coluna indica a identificação do processo, o que nos interessa mais diretamente. Vejamos então o script:
#!/bin/sh
for pid in ""lsof /home | grep -v COMMAND | awk '{print $2}'""
do
kill -9 $pid
done
umount /home
O umount tem que ser dado imediatamente após o falecimento dos processos que estão acessando o filesystem em questão para evitar que novos processos sejam criados, novamente impedindo o umount.
O pacote lsof pode ser encontrado no servidor de ftp anônimo da Unicamp em http://ftp.unicamp.br/pub/unix-tools/lsof.
Atualização do Firmware IOS em Switches Cisco Catalyst
Fonte: http://labcisco.blogspot.com.br/
Blog do Prof Samuel Henrique Bucke Brito | Redes de Computadores e Telecomunicações
Atualização do Firmware IOS em Switches Cisco Catalyst
Olá Pessoal.
Em algum momento pode ser importante atualizar o firmware de um roteador ou switch da Cisco para carregá-lo com uma imagem mais recente do IOS, seja para manter os equipamentos da infraestrutura sempre com o firmware mais recente recomendado pela Cisco ou mesmo para o fim específico de correção de algum bug que esteja limitando a operação de alguma feature importante da caixa. Este artigo irá ajudar o leitor no processo de atualização do firmware de um Switch Cisco Catalyst 3560, lembrando que os mesmos passos servem como referência para atualizar outros modelos de switches e roteadores.
Etapa 1) Baixar a Nova Versão do Firmware
Antes de iniciar o processo de atualização do firmware é conveniente verificar a versão atual do IOS existente na memória flash switch, tarefa simples de ser realizada através dos comandos "show version" e "dir flash:". Na saída abaixo é possível observar que temos um Switch Catalyst WS-C3560-24PS (modelo) com a versão 12.2(37)SE1 do IOS.
Switch# show version
(...) Saída Omitida
Switch Ports Model SW Version SW Image
------ ----- ----- ---------- ----------
* 1 26 WS-C3560-24PS 12.2(37)SE1 C3560-IPSERVICESK
Switch# dir flash:
Directory of flash:/
3 -rw- 8662192 <no date> c3560-ipservicesk9-mz.122-37.SE1.bin
2 -rw- 28282 <no date> sigdef-category.xml
1 -rw- 227537 <no date> sigdef-default.xml
4 -rw- 1096 <no date> vlan.dat
64016384 bytes total (55097277 bytes free)
A última versão disponível e sugerida pela Cisco para esse modelo específico de switch é a 12.2(55)SE10, lançada em fev/2015. Nesse caso específico, iremos então baixar o arquivo "c3560-ipservicesk9-mz.122-55.SE10.bin". Através do site da Cisco, especificamente na opção Suporte|Downloads, é possível baixar a última versão de firmaware sugerida para o modelo específico do(s) switch(es) em produção. Ao baixar o firmware (extensão .bin) é importante anotar o resultado do hash MD5 fornecido nas informações do download. Depois que copiarmos a última versão do IOS no switch, seja através da rede ou mesmo localmente, realizaremos um procedimento de veriricação do hash MD5 para garantir que o arquivo não está corrompido e, somente então, seguiremos com a atualização do firmware.
Obs.: Fique atento que cada modelo específico de switch terá diferentes versões do IOS e é importante ser cauteloso ao baixar as versões corretas antes de seguir com o procedimento de atualização do firmware.
Etapa Opcional) Remover a Antiga Imagem do IOS
Embora essa etapa não seja obrigatória, é comum a memória flash não ter muito espaço em equipamentos antigos. Nesse exemplo específico nossa memória flash tem espaço suficiente para armazenar a nova imagem que possui apenas 12.16MB, já que do total de 64MB estão livres 55MB. Mesmo assim, há situações em que é conveniente liberar algum espaço da flash antes de armazenar a última versão do firmware, procedimento que pode ser realizado com o comando "delete":
Switch# delete flash:/c3560-ipservicesk9-mz.122-37.SE1.bin
Switch# dir flash:
Directory of flash:/
2 -rw- 28282 <no date> sigdef-category.xml
1 -rw- 227537 <no date> sigdef-default.xml
4 -rw- 1096 <no date> vlan.dat
64016384 bytes total (63759469 bytes free)
Obs.: CUIDADO ao realizar esse procedimento de remoção da imagem do firmware em uso, uma vez que o switch ficará inutilizado em caso de boot inesperado. Na próxima etapa iremos copiar a nova versão do firmaware na flash e atualizar a informação do caminho de boot para que o switch possa ser reinicializável novamente. Nesse exato momento estamos com uma "caixa fria" em nossas mãos! :-o É sempre mais seguro manter na flash ambas as versões em uso e a nova do IOS até que o procedimento de atualização do firmware esteja concluído, embora nem sempre seja possível...
Epata 2) Copiar o Firmware IOS no Switch e Atualizar o Caminho de Boot
Um método prático de copiar o novo firmware no switch é através de um servidor TFTP que pode ser instalado em alguma máquina administrativa que esteja operando como um repositório de firmwares na rede ou até mesmo temporariamente no próprio notebook do administrador. Caso o leitor não conheça o serviço TFTP, recomendo a leitura do artigo abaixo em que explico como utilizar TFTP para transferir arquivos de configuração para switches/routers, já que a transferência de binários segue a mesma lógica.
Link: Backup de Configurações do IOS em Servidor TFTP no Linux
Switch# copy tftp: flash:
>Address or name of remote host? <Endereço IP do Servidor TFTP>
>source filename? c3560-ipservicesk9-mz.122-55.SE10.bin
>Destination filename? c3560-ipservicesk9-mz.122-55.SE10.bin
Para verificar se o firmware foi devidamente copiado:
Switch# dir flash:
Directory of flash:/
3 -rw- 12749374 <no date> c3560-ipservicesk9-mz.122-55.SE10.bin
2 -rw- 28282 <no date> sigdef-category.xml
1 -rw- 227537 <no date> sigdef-default.xml
4 -rw- 1096 <no date> vlan.dat
64016384 bytes total (51010095 bytes free)
Agora chegou a hora de verificar se o firmware não foi corrompido durante o download da página da Cisco ou mesmo durante o processo de transferência para o switch. Realizaremos um procedimento de veriricação do hash MD5 para garantir que o arquivo não está corrompido, sendo que a sequência numérica resultante deve ser igual àquela informada na página da Cisco:
Switch# verify /md5 flash:/c3560-ipservicesk9-mz.122-55.SE10.bin
(...)
verify /md5 (flash:c3560-ipservicesk9-mz.122-55.SE10.bin) = dcdc5647204459ac65cef367c2cd84fb
A etapa mais IMPORTANTE é informar o caminho da nova imagem do firmware:
Switch(config)# boot system switch all flash:/c3560-ipservicesk9-mz.122-55.SE10.bin
Por fim, basta salvar as configurações e reinicializar nosso switch que agora é "bootável"!
Assim temos uma "caixa quente" novamente! :-)
Switch# write mem
Switch# reload
Depois de reinicializado o switch podemos verificar o novo firmware em execução:
Switch# show version
(...) Saída Omitida
Switch Ports Model SW Version SW Image
------ ----- ----- ---------- ----------
* 1 26 WS-C3560-24PS 12.2(55)SE10 C3560-IPSERVICESK
É isso, tenham cuidado com os testes! ;-)
Samuel.
Este artigo apresenta algumas estratégias para aprender a falar em inglês.
Conversação em inglês
Por Rubens Queiroz de Almeida
Fonte dicas-l.com.br
Para toda situação, existe o ideal e o possível. O ideal é ter diversas horas de aula por semana, com um professor(a) que seja culto(a), inteligente, que fale e, mais importante, deixe você falar.
Esta situação ideal é bem difícil de se conseguir. Talvez você não tenha este tempo todo. Se tiver o tempo, talvez não tenha o dinheiro para pagar pelas aulas de alguém tão qualificado, que ministre aulas agradáveis e produtivas. O problema é que muita gente, por não poder ter a situação ideal, acaba desistindo e não faz nada.
Mas não precisamos ser tão radicais. Dá para ter ótimos resultados com estratégias alternativas, ao alcance de qualquer pessoa. Mas antes de passar para as estratégias, eu vou falar um pouco do que deve ser evitado a todo custo.
O primeiro, corra de professores que te corrigem o tempo inteiro. O aprendizado de qualquer coisa passa por quatro etapas: 1) falar errado sem saber que está errado; 2) falar errado e saber que está errado logo depois que falou; 3) falar certo, mas não com as melhores palavras; 4) falar certo, com as palavras certas. O ideal é começar pela etapa 4, mas a má notícia é que ninguém chega na etapa 4 sem passar pelas etapas 1, 2 e 3.
Em segundo lugar, se a aula é de conversação, fuja de professores que falam o tempo todo e não deixam espaço para mais ninguém. Você só vai aprender a falar falando (falar errado também conta). Eu até abro uma exceção para este tipo de professores, se eles ou elas forem fascinantes, inteligentes e tiverem muita coisa para contar. Eu já tive um professor assim e é fascinante ouvir quem tem algo a dizer. Mas em geral isto não dá certo...
Vamos então começar pela etapa 1. Se voce erra e não sabe que errou, nesta fase de seu aprendizado você não precisa de um professor o tempo inteiro. Você pode conversar com alguém tão principiante quanto você. Nesta fase, você precisa apenas falar, o mais que puder, sem parar, e sem ter ninguém para ficar te corrigindo e impedindo o fluxo de suas idéias. Se o seu parceiro também não sabe nada, você não vai ter vergonha de falar, certo?
O ideal seria você ter, em paralelo, aulas com um professor. Nos primeiros níveis, uma hora ou duas por semana, já são suficientes. Esta uma ou duas horas, você pode complementar conversando com um amigo que tenha conhecimento equivalente ao seu. Conversar com alguém que sabe muito mais do que você pode ser desencorajador, pois você via ficar se cobrando o mesmo nível de conhecimento. Se você não conseguir ninguém para praticar, também vale falar sozinho. Mas não deixe os outros te verem pois pode complicar a sua vida :-) Enfim, falar, falar, falar, sem mêdo de errar e sem mêdo de ser feliz!
Mas falar não é uma habilidade que se desenvolve independentemente. Falar errado é uma parte importante do processo e você vai se corrigir, gradualmente, expondo-se ao inglês falado corretamente. Isto se consegue através de livros, das séries de televisão, revistas em quadrinhos, etc. O material deve ser de sua escolha e você deve gostar muito dele. Gradualmente você irá incorporando à sua fala as frases e situações com as quais teve contato a partir destes meios alternativos.
Este processo de desenvolvimento da fala se dá em paralelo com o desenvolvimento das habilidades de leitura e audição. A leitura é fácil de se desenvolver e você pode carregar os livros para onde quiser e aproveitar as janelinhas de tempo que se abrem durante o seu dia. Para desenvolver a audição podemos contar com os aparelhos de áudio portáteis, onde você pode gravar o material que quer ouvir.
Fica até difícil definir o que deve ser feito primeiro. O processo de desenvolvimento da habilidade de falar em um idioma estrangeiro é complexo para se entender, mas simples de se desenvolver, desde que abandonemos os nossos preconceitos e compreendamos o seu processo. Você vai passar por uma fase em que vai achar que não está progredindo, que quanto mais estuda menos aprende, e por aí vai. Mas se você buscar associar este estudo a coisas que lhe dão prazer, você vai chegar lá.
Para encerrar, um video do Youtube sensacional, que resume tudo o que eu disse neste texto. Enjoy! :-)
Por Rubens Queiroz de Almeida
Fonte dicas-l.com.br
Para toda situação, existe o ideal e o possível. O ideal é ter diversas horas de aula por semana, com um professor(a) que seja culto(a), inteligente, que fale e, mais importante, deixe você falar.
Esta situação ideal é bem difícil de se conseguir. Talvez você não tenha este tempo todo. Se tiver o tempo, talvez não tenha o dinheiro para pagar pelas aulas de alguém tão qualificado, que ministre aulas agradáveis e produtivas. O problema é que muita gente, por não poder ter a situação ideal, acaba desistindo e não faz nada.
Mas não precisamos ser tão radicais. Dá para ter ótimos resultados com estratégias alternativas, ao alcance de qualquer pessoa. Mas antes de passar para as estratégias, eu vou falar um pouco do que deve ser evitado a todo custo.
O primeiro, corra de professores que te corrigem o tempo inteiro. O aprendizado de qualquer coisa passa por quatro etapas: 1) falar errado sem saber que está errado; 2) falar errado e saber que está errado logo depois que falou; 3) falar certo, mas não com as melhores palavras; 4) falar certo, com as palavras certas. O ideal é começar pela etapa 4, mas a má notícia é que ninguém chega na etapa 4 sem passar pelas etapas 1, 2 e 3.
Em segundo lugar, se a aula é de conversação, fuja de professores que falam o tempo todo e não deixam espaço para mais ninguém. Você só vai aprender a falar falando (falar errado também conta). Eu até abro uma exceção para este tipo de professores, se eles ou elas forem fascinantes, inteligentes e tiverem muita coisa para contar. Eu já tive um professor assim e é fascinante ouvir quem tem algo a dizer. Mas em geral isto não dá certo...
Vamos então começar pela etapa 1. Se voce erra e não sabe que errou, nesta fase de seu aprendizado você não precisa de um professor o tempo inteiro. Você pode conversar com alguém tão principiante quanto você. Nesta fase, você precisa apenas falar, o mais que puder, sem parar, e sem ter ninguém para ficar te corrigindo e impedindo o fluxo de suas idéias. Se o seu parceiro também não sabe nada, você não vai ter vergonha de falar, certo?
O ideal seria você ter, em paralelo, aulas com um professor. Nos primeiros níveis, uma hora ou duas por semana, já são suficientes. Esta uma ou duas horas, você pode complementar conversando com um amigo que tenha conhecimento equivalente ao seu. Conversar com alguém que sabe muito mais do que você pode ser desencorajador, pois você via ficar se cobrando o mesmo nível de conhecimento. Se você não conseguir ninguém para praticar, também vale falar sozinho. Mas não deixe os outros te verem pois pode complicar a sua vida :-) Enfim, falar, falar, falar, sem mêdo de errar e sem mêdo de ser feliz!
Mas falar não é uma habilidade que se desenvolve independentemente. Falar errado é uma parte importante do processo e você vai se corrigir, gradualmente, expondo-se ao inglês falado corretamente. Isto se consegue através de livros, das séries de televisão, revistas em quadrinhos, etc. O material deve ser de sua escolha e você deve gostar muito dele. Gradualmente você irá incorporando à sua fala as frases e situações com as quais teve contato a partir destes meios alternativos.
Este processo de desenvolvimento da fala se dá em paralelo com o desenvolvimento das habilidades de leitura e audição. A leitura é fácil de se desenvolver e você pode carregar os livros para onde quiser e aproveitar as janelinhas de tempo que se abrem durante o seu dia. Para desenvolver a audição podemos contar com os aparelhos de áudio portáteis, onde você pode gravar o material que quer ouvir.
Fica até difícil definir o que deve ser feito primeiro. O processo de desenvolvimento da habilidade de falar em um idioma estrangeiro é complexo para se entender, mas simples de se desenvolver, desde que abandonemos os nossos preconceitos e compreendamos o seu processo. Você vai passar por uma fase em que vai achar que não está progredindo, que quanto mais estuda menos aprende, e por aí vai. Mas se você buscar associar este estudo a coisas que lhe dão prazer, você vai chegar lá.
Para encerrar, um video do Youtube sensacional, que resume tudo o que eu disse neste texto. Enjoy! :-)
Vulnerabilidade e segurança no Linux
Este artigo tem a proposta de levantar a discussão sobre as vulnerabilidades do sistema operacional Linux. Mesmo sabendo-se que o Linux é o sistema operacional mais seguro que existe, fica o ALERTA: O Linux pode ser tão vulnerável quanto um Windows. Esta leitura é indicada principalmente para quem está iniciando. Espero que seja bastante produtiva.
Por: Dornelles Vissotto Junior
fonte https://www.vivaolinux.com.br
AS MAIORES VULNERABILIDADES DO LINUX
Para os adeptos de plantão, este artigo não é para gerar polêmica não, mas para servir de ALERTA!
Muito falamos a respeito da segurança do Sistema Operacional Linux, mas bem sabemos que o Linux também têm suas vulnerabilidades. Quais? As da Microsoft parece que todo linuxer sabe "decor", mas e as vulnerabilidades do próprio sistema operacional?
Pois é. Aqui vai o alerta. Um dia escutei a frase: "O Sistema Operacional mais seguro é aquele que você mais domina.", e tive que concordar plenamente. Pesquisando então sobre as vulnerabilidades do Linux, esperando encontrar pouca coisa, achei muita gente relatando seus problemas. Até que encontrei no site da SANS (http://www.sans.org/top20) uma pesquisa realizada pela própria SANS junto ao FBI e pude esclarecer esta minha dúvida. A pesquisa aborda as 20 maiores vulnerabilidades encontradas, 10 para servidores Windows e 10 para servidores Unix.
Abaixo estão listadas as 10 maiores vulnerabilidades do Sistema Operacional Linux/Unix, traduzido de Outubro de 2003 e que são válidas ainda hoje:
BIND - O BIND é o principal serviço de ataque dos hackers. A maioria dos bugs já foram resolvidos mas a maioria das pessoas mantém as versões mais antigas por uma questão de funcionalidade e por não disporem de tempo para a migração.
RPC - O RPC é um serviço para a chamadas de procedimentos que serão executados remotamente. É extremamente importante para a funcionalidade da rede interna pois é utilizado para distribuição de carga, processamento distribuído, cliente/servidor, etc. O NFS, que é um dos compartilhamentos de rede mais conhecidos e utilizados, usa diretamente o RPC.
Apache - Sem dúvidas nenhuma é um Web Server bem mais robusto que o IIS, mas não deixa de estar exposto à internet. Vários ataques a sistemas operacionais NIX ocorrem pelo Apache, principalmente para servidores com execução de scripts e permissões de acesso à programas.
Contas de usuários. Esta vulnerabilidade ocorre principalmente sobre contas com senhas fracas ou nulas. Parece ridículo, mas tem pessoas que conseguem invadir sistemas descobrindo senhas pelo método da tentativa e erro, e, geralmente, as senhas são as mais óbvias possíveis. Não é o sistema que é "hackeado" mas a conta do usuário. Uma vez tendo acesso ao sistema, o "hacker" pode se tornar bastante incômodo.
Serviço de transferência em ASCII. FTP e e-mail são os programas diretamente relacionados a estes serviços. Tudo que passar por eles e for texto puro, não encriptado (o que ocorre na maioria das instalações), o conteúdo pode ser capturado. Basta alguma informação ou senha secreta para que a porta esteja aberta.
Sendmail. É, talvez, o pior serviço de e-mail do NIX, em comparação com os seus próprios concorrentes. Tende a ser lento e problemático. Mas é o mais utilizado, porque é extremamente operacional. É possível colocá-lo para funcionar rapidamente. Por isto é a maior fonte de furos existente na comunidade. Se puder, substitua.
SNMP. Uma excelente ferramenta administrativa, principalmente para grandes corporações. Mas por ser um projeto baseado na comunicação com a rede, está sujeito à vulnerabilidades. O serviço é ativado por default no sistema Linux, o que causa o esquecimento por parte dos usuários.
SSH. É a solução ideal para acesso remoto seguro, abolindo de vez o Telnet. No entanto, pode se tornar totalmente ineficaz se não for administrado corretamente. Escolha o nível de segurança mais desejado, lembrando que ele é diretamente proporcional ao trabalho para configurá-lo. E não esqueça de proteger chaves privadas dos usuários!
Compartilhamento de arquivos. Ocorre principalmente com NIS/NFS e Samba mal configurados. Podem comprometer a segurança abrindo brechas para ataques externos.
SSL's. Embora sejam extremamente eficazes para criar conexões seguras entre cliente/servidor, os SSL's permitem o acesso ao servidor por parte do cliente. Pode se tornar uma porta para o acesso de "hackers"
Depois desta lavada de vulnerabilidades, deixarei alguns comentários. A vulnerabilidade não está necessariamente relacionada ao uso destes serviços, mas está muito relacionada à má configuração dos mesmos.
NÃO CONFIE DEMAIS NA SUA SEGURANÇA. A desconfiança é o melhor aliado de um bom administrador.
Por: Dornelles Vissotto Junior
fonte https://www.vivaolinux.com.br
AS MAIORES VULNERABILIDADES DO LINUX
Para os adeptos de plantão, este artigo não é para gerar polêmica não, mas para servir de ALERTA!
Muito falamos a respeito da segurança do Sistema Operacional Linux, mas bem sabemos que o Linux também têm suas vulnerabilidades. Quais? As da Microsoft parece que todo linuxer sabe "decor", mas e as vulnerabilidades do próprio sistema operacional?
Pois é. Aqui vai o alerta. Um dia escutei a frase: "O Sistema Operacional mais seguro é aquele que você mais domina.", e tive que concordar plenamente. Pesquisando então sobre as vulnerabilidades do Linux, esperando encontrar pouca coisa, achei muita gente relatando seus problemas. Até que encontrei no site da SANS (http://www.sans.org/top20) uma pesquisa realizada pela própria SANS junto ao FBI e pude esclarecer esta minha dúvida. A pesquisa aborda as 20 maiores vulnerabilidades encontradas, 10 para servidores Windows e 10 para servidores Unix.
Abaixo estão listadas as 10 maiores vulnerabilidades do Sistema Operacional Linux/Unix, traduzido de Outubro de 2003 e que são válidas ainda hoje:
BIND - O BIND é o principal serviço de ataque dos hackers. A maioria dos bugs já foram resolvidos mas a maioria das pessoas mantém as versões mais antigas por uma questão de funcionalidade e por não disporem de tempo para a migração.
RPC - O RPC é um serviço para a chamadas de procedimentos que serão executados remotamente. É extremamente importante para a funcionalidade da rede interna pois é utilizado para distribuição de carga, processamento distribuído, cliente/servidor, etc. O NFS, que é um dos compartilhamentos de rede mais conhecidos e utilizados, usa diretamente o RPC.
Apache - Sem dúvidas nenhuma é um Web Server bem mais robusto que o IIS, mas não deixa de estar exposto à internet. Vários ataques a sistemas operacionais NIX ocorrem pelo Apache, principalmente para servidores com execução de scripts e permissões de acesso à programas.
Contas de usuários. Esta vulnerabilidade ocorre principalmente sobre contas com senhas fracas ou nulas. Parece ridículo, mas tem pessoas que conseguem invadir sistemas descobrindo senhas pelo método da tentativa e erro, e, geralmente, as senhas são as mais óbvias possíveis. Não é o sistema que é "hackeado" mas a conta do usuário. Uma vez tendo acesso ao sistema, o "hacker" pode se tornar bastante incômodo.
Serviço de transferência em ASCII. FTP e e-mail são os programas diretamente relacionados a estes serviços. Tudo que passar por eles e for texto puro, não encriptado (o que ocorre na maioria das instalações), o conteúdo pode ser capturado. Basta alguma informação ou senha secreta para que a porta esteja aberta.
Sendmail. É, talvez, o pior serviço de e-mail do NIX, em comparação com os seus próprios concorrentes. Tende a ser lento e problemático. Mas é o mais utilizado, porque é extremamente operacional. É possível colocá-lo para funcionar rapidamente. Por isto é a maior fonte de furos existente na comunidade. Se puder, substitua.
SNMP. Uma excelente ferramenta administrativa, principalmente para grandes corporações. Mas por ser um projeto baseado na comunicação com a rede, está sujeito à vulnerabilidades. O serviço é ativado por default no sistema Linux, o que causa o esquecimento por parte dos usuários.
SSH. É a solução ideal para acesso remoto seguro, abolindo de vez o Telnet. No entanto, pode se tornar totalmente ineficaz se não for administrado corretamente. Escolha o nível de segurança mais desejado, lembrando que ele é diretamente proporcional ao trabalho para configurá-lo. E não esqueça de proteger chaves privadas dos usuários!
Compartilhamento de arquivos. Ocorre principalmente com NIS/NFS e Samba mal configurados. Podem comprometer a segurança abrindo brechas para ataques externos.
SSL's. Embora sejam extremamente eficazes para criar conexões seguras entre cliente/servidor, os SSL's permitem o acesso ao servidor por parte do cliente. Pode se tornar uma porta para o acesso de "hackers"
Depois desta lavada de vulnerabilidades, deixarei alguns comentários. A vulnerabilidade não está necessariamente relacionada ao uso destes serviços, mas está muito relacionada à má configuração dos mesmos.
NÃO CONFIE DEMAIS NA SUA SEGURANÇA. A desconfiança é o melhor aliado de um bom administrador.
terça-feira, 26 de janeiro de 2016
WhatsApp volta atrás e permite desativar confirmação de leitura no chat
Fonte https://tecnoblog.net
Por Thássius Veloso
Durou uma semana – se tanto – a modificação no WhatsApp para revelar se os seus amigos leram as mensagens que você mandou. A empresa já prepara uma atualização que dará ao usuário a oportunidade de ajustar a privacidade para dizer se quer enviar os avisos de que o chat foi lido.
Assim como acontece com a informação de “Última vez visto”, na qual aparece o horário em que você ficou online, o usuário que decidir não revelar se leu as mensagens ficará sem saber se os contatos leram aquilo que ele próprio mandou. Dá pra chamar isso de “política de reciprocidade” do WhatsApp: o mesmo nível de privacidade que você aplica a si mesmo torna-se o padrão para os seus amigos.
A atualização com a nova opção de privacidade está disponível no site oficial do aplicativo. É preciso baixar o arquivo .apk da versão 2.11.44. Em seguida, vá em: Configurações → Informações da conta → Privacidade. É necessário desmarcar a caixa de seleção dos Read receipts (Recibos de leitura?).
Assinar:
Postagens (Atom)