[GTER] Combinação mais estavel para usar Quagga: CentOS ou Ubunto?

Evandro Nunes evandronunes12 at gmail.com
Sun Jan 18 12:53:58 -02 2015


2015-01-18 12:45 GMT-02:00 Evandro Nunes <evandronunes12 at gmail.com>:

> 2015-01-17 1:14 GMT-02:00 Lista <lista.gter at gmail.com>:
>
>> A questão é aquilo o que não deu certo pra um deu para o outro. Na lista
>> temos vários case de sucesso com linux e bsd passando tráfego na casa dos
>> giga.(vide histórico da lista do Provedor Bogus).
>> Enfim o melhor S.O e combinação é aquela que vc tem mais skills.  Então se
>> vc tem habilidade para tunar kernel do linux, escolha o hardware certo e
>>>> sem medo e o mesmo vale para o bsd.
>> O que mais vale nessa situação é a sua habilidade ou da equipe no que
>> estão
>> mais acostumado na resolução rápida.
>>
>
> desculpe mas de novo tenho que discordar.
> na década de 90 os donos de provedores usava windows nt pra concentrador,
> tacacs, e até router.
> depois foram pra linux, uma mudança completa e radical.
> pois bem, é um processo darwinista natural, evoluir, então está na hora de
> irem pra freebsd.
> e pode ser por padrão, pode ser de cara. não precisa ter que sofrer. nem é
> algo radical como windows->linux foi.
>
> essa conversa de "o melhor é o que você mais domina" nunca foi bem vista
> por mim.
> isso é muito típico da natureza humana, se manter na zona de conforto.
> resistência a mudanças.
>
> acho que toda empresa e profissional sério, tem que se manter em constante
> evolução e reciclagem.
> se todos ficassem na zona de conforto pra sempre ainda estaríamos usando
> windows nt.
>
> toda vez que você ouvir alguém dizer "o melhor é o que você mais domina"
> deveria no mínimo pensar consigo mesmo "será?" (mesmo que um pensamento
> silencioso).
>
> freebsd e linux não são a mesma coisa.
> não são equivalentes.
> não é slackware vs debian vs centos vs ubuntu que muda a userland e o
> resto é igual.
> eles não tem a mesma performance.
> eles não tem as mesmas decisões de gerencia de CPU, memória, etc.
>
> portanto não se enganem com esse papo de "hoje em dia da na mesma, tem a
> mesma performance" ou "o melhor é o que você mais domina". pode não ser.
> pode ter algo melhor que talvez você nem venha a precisar, mas se o dia
> chegar é bom ter esse skill.
>
> tem muita gente que "domina" mikrotik.
> isso não faz o mikrotik uma melhor opção pra bgp que VyOS por exemplo.
> e olha que estou comparando linux-based com linux-based.
> que dirá linux -> freebsd.
>
> é por causa da maldita zona de conforto que o mundo não anda...
>
> - IPv6 nem é mais late adoption, a sirene ta soando, a luz vermelha
> piscando, os registrars se negando a liberar novos CIDR pq não tem mais e
> só agora o mundo começa se mexer...
> - S-BGP ninguém implementa. mas adoram se enganar e por md5 e se achar
> "seguro o bastante".
> - DNSSEC então nem se fala. ninguém tenta resolver os problemas que ainda
> existem. e mesmo quem adota DNSSEC não adota em casa fazendo suas próprias
> configurações e se dando ao trabalho de aprender rodar 2 comandos a mais
> por zona e cuidar da chave. veja estatísticas, se não fosse a louvável
> iniciativa do Registro.BR de fornecer DNS com DNSSEC as estatísticas de
> adoção do DNSSEC no Brasil seriam ridículas... pq o povão não sai da zona
> de conforto
> - SCTP/IP está ai ha anos, com performance equivalente a TCP/IP e muito
> mais funcionalidades, vantagens e flexibilidade. no entanto tudo que há de
> novo ainda é exclusivamente TCP/IP ou UDP/IP. como se só existissem esses 2
> protocolos de transportes no mundo. ou se eles fossem os melhores opções
> pra qualquer cenário.
> - SMTP ta ai, inseguro, ineficiente... ja inventaram QMTP, IM2K e tantas
> outras propostas melhores. algumas delas que potencialmente acabariam com
> SPAM no mundo ja que os e-mails não "chegam" mais, eles são "fetched" após
> notificação de recebimento. você sabe exatamente qual o servidor e se for
> spam fica fácil bloquear sem estar bloqueando um forged/spoofed.
>


ainda me lembrei do HTTP/2 que o rubens recentemente abordou em uma thread.
o HTTP/2 só tem benefícios em relação ao HTTP/1.1. onde não tem benefícios
(webservice, métodos DELETE, UPDATE, etc) não tem qualquer
malefício/retrocesso.
no entanto a maior crítica é... "é um protocolo binário" ou pior... "é um
padrão feito pelo google".
fala sério argumentos ridículos e imprecisos.
hello zona de conforto?




>
> e claro ter mais bsd no mundo, ao menos na infra-estrutura pq no usuário
> final, convenhamos basta ler os headers de e-mails aqui no GTER mesmo e
> vemos cada vez mais OS X e iPhone kkk ou seja é ridículo mas tem mais BSD
> na mão de usuários finais que na infra-estrutura de provedores e empresas.
>
> e estou citando só alguns exemplos bobos que me vem a mente, sem grande
> esforço...
> o mundo tem condições de ser melhor no lower protocol, no upper protocol,
> nos principais serviços de estrutra da internet, nos protocolos de
> transporte...
>
> no entanto estamos enraizados na década de 80/90 graças a maldita zona de
> conforto.
> sinceramente, é triste.
>
> por mim, passou da hora de por fim nessa idéia de "o melhor é o que
> funciona" ou "o melhor é o que você domina". porque como eu disse...
> "será?". em 90% dos casos, não é...
>
> roteamento bgp com budget hardware e opensource é só mais 1 exemplo.
>
> como disse o Uesley Correa, "tudo que é bom... pode melhorar.".
> esse deveria ser o pensamento mesmo quando mikrotik, linux ou windowsNT te
> atendem.
>
> você (você no caso é sujeito indefinido, não estou falando pra ninguém em
> especial), empresário de sucesso com seus 30K reais de salário mensal... ta
> bom, 30 mil por mês te atende? paga suas contas? te da um bom padrão de
> vida? que tal 50K? que tal 60K por mês padrão executivo top? ou seja 30K é
> bom mas da pra melhorar...
>
> porque com a adoção de tecnologia na sua empresa, a lógica é diferente do
> seu bolso?
>
> Em sábado, 17 de janeiro de 2015, Rubens Kuhl <rubensk at gmail.com>
>> escreveu:
>> >>
>> >> ou seja comportamento exatamente oposto do que o lucas teve.
>> >> eu também sempre notei o bird mais rápido e mais eficiente em termos de
>> >> cpu.
>> >> sem reclamação nesse sentido.
>> >>
>> >>
>> > O BIRD tem uma característica curiosa de ser um scheduler de suas
>> próprias
>> > multi-tarefas... algo como faziam as aplicações em SOs não-preemptivos
>> como
>> > o MacOS Classic. Então mesmo ele se apegando a um core específico, ele
>> não
>> > fica pendurado fazendo uma tarefa se essa tarefa não estiver andando.
>>
>
> exatamente.
> uma boa arquitetura pode dispensar o paralelismo, preempção ou o flood de
> threads indiscriminadas sendo criadas no sistema, gerando excesso de
> paralelismo, troca de contexto, entropia e prejudicando a eficiência geral
> do sistema.
>



More information about the gter mailing list