[GTER] freeRouter

Wed Dec 30 17:47:01 -02 2015

Saudações,

Fiquei acompanhando a thread e me pergunto por que investe tanto em 
linguagem de alto nivel sendo que o trabalho pesado ainda continua sendo 
feito por linguagens de baixo nivel ou intermediarias ( C e C++ ).
Não seria mais produtivo e com um maior retorno em nivel de qualidade e 
velocidade de execução se o mercado adota-se uma unica linguagem que 
realmente não seja mais um emaranhado de rotinas pré compiladas 
subjacentemente por outra linguagem ( java para mim é um monte de rotina 
escrita em C++ e C que usa uma sintaxe propria para chamar elas ).

Colocando lenha na fogueira apenas, o assunto da thread é muito 
interessante !!

Att.

On 30/12/15 15:46, Diogo Montagner wrote:
> Veja inline.
>
> On Wednesday, 30 December 2015, Douglas Fischer <fischerdouglas at gmail.com>
> wrote:
>
>> Em 30 de dezembro de 2015 03:10, Diogo Montagner <
>> diogo.montagner at gmail.com>
>> escreveu:
>>
>>> Ao escolher Java, automaticamente voce tem uma pancada de ferramentas
>> para
>>> desenvolvimento e testes. Se voce empreender conceitos de DevOps e
>>> Continuos Delivery no codigo, o Java eh a escolha mais correta no quesito
>>> qualidade.
>>>
>> Não discordo!
>>
>> Maaaaaassss
>> Agora uma coisa que NÃO COLA nesse caso é o papo de:
>>   "Escolhendo Java você vai ter uma gama
>>    quase infinita de bibliotecas e plugins
>>    já desenvolvios, blábláblá!!"
>> Que arquiteto de código vai embarcar um código no seu projeto se fazer uma
>> revisão completa?
>> Revisar e colocar nos padrões toma tanto ou mais tempo que escrever do
>> zero.
>> E a segurança? E o padrão? (desde o básico com a indetação, nomeclatura de
>> variáveis, até endereçamento de biliotecas)
>
> Dmontagner> eu tb discordo neste ponto. Mas eu ainda assim suporto a
> reutilizacao de codigos existente.
>
>
>> Simples:
>> "Qual o projeto mais impecável em qualidade de código no mundo hoje?"
>> Com TODA a certeza openbsd(e filhos) estará entre os 3 primeiros da lista.
>> Quando eles internalizaram um código sem revisar e reestruturar ele
>> TODINHO?
>>
>>
>> E apenas a título de complementação de referências, acho o Ruby e seus
>> trilho muito mais elegante no que tange ao continuous deployment.
>>
>   Elegancia eh uma coisa. Assim como outro membro da lista comentou, existem
> outras linguagens que possuem essas ferramentas, mas em ainda acredito
> quando o ambiente eh Java, estas ferramentas estao um passo a frente das
> demais.
>
> Disclaimer: Java nao estah na minha lista de linguagens preferida. Mas nao
> vou iniciar a discussao de linguagens pq eh uma discussao sem fim.
>
>> Eu ainda prefiro o Java do que escrever codigo de roteamento e
>>> encaminhamento de pacotes em HW generico do que usar a GPU para isto.
>>>
>> Man, nesse ponto eu tenho que discordar!
>> CINCO MIL THREADS!
>>
>> Os parques telefônicos do mundo inteiro continuam sendo escritos e
>> reescritos desde 50 anos atrás na base do Earlang da Ericson por um(dois)
>> motivo(s): FUNCIONAM, e ESCALAM.
>>
>> Paralelismo alí não é "EXTRA" é requisito de campo.
>
> De uma olhada na linguagem Scala. Ela tem tudo pra substituir o java em um
> futuro nao muito distante.
>
>
>> Ficou pequeno?
>> Espeta a placa do lado(a quente se o hardware permitir) e PAU!
>>
>>
> Eu concordo com este item.
>
>
>>> Em geral, o control plane de un roteador pode ser facilmente escrito em
>>> Java sem grandes implicacoes na performance. Por outro lado, o fowarding
>>> plane, ainda que em HW generico, precisa ter um acesso mais direto ao HW
>>> para se obter performances melhores.
>>>
>>> Se a questao eh apenas escala no control-plane, no momento que a
>>> arquitetura passa a ser distribuida e/ou baseada em micro-servicos, a
>>> questao do Java eh apenas um pequeno e insignificante detalhe, IMO.
>>>
>> Se você olhar para o Control-Plane enxergando apenas o de uma caixa, você
>> está "quase" certo...
>> Quase porque ainda tem os pontos de gargalo(aqueles aonde os Middlewares
>> entram)
>
>
>> Mas se você olhar para o Control-Plane em Pensar em um OpenFlow com 200-300
>> dispositivos.
>> Aí a coisa muda de figura...
>>
>>
>> Vamos fazer uma coisa:
>> - É fato que um fullrouting Single Homed, quando sumarizado, teria apenas
>> algo em torno de 10-12 rotas...
>> - É também fato que o numero de rotas é fator decisivo em QUALQUER
>> plataforma de encaminhamento, seja com FastPath/CEF/etc ou não...
>>     (Lembra dos 8Gbps numa CCR usando rota default?)
>> - Então me ache um hardware, que não seja essa linha GPU ou XeonPhi, que
>> consiga fazer a reduzida de Karnout da Internet IPv4 em tempo praticável e
>> aí eu entrego as bets.
>
> Broadcom - eh um HW generico mas desenvolvido para aplicacoes no ambiente
> de forwarding de pacotes, i.e., redes.
>
>
>> - Ou então, coloque o Java/Python/Pearl/Ruby/etc para lidar com essa CINCO
>> MIL THREADS que eu mesmo derrubo as casinhas e entrego as bets...
>>
>>
> Espere um pouco mais e voce vai ver isto acontecer. Eu tenho a impressao
> que Scala sera um game changer cedo ou tarde. E eu acredito tb que a
> arquitetura baseada em micro servicos eh o jeito de escalonar no futuro.
>
> Uma nota final: alta escala em um ponto unico eh uma faca de dois
> gumes. Quanto mais alto o edificio, maior eh o estrago qdo ele cai e maior
> eh o tempo pra reerguer ele. No final, voce precisa analisar aonde que o se
> negocio se encaixa, pois eh uma questao de tradeoff.
>
>
>> P.S: No flames please...
>> Brincando e falando sério ao mesmo tempo, a conversa fica descontraída e
>> produtiva.
>>
>>
>>> []s
>>>
>>> On Wednesday, 30 December 2015, Douglas Fischer <
>> fischerdouglas at gmail.com>
>>> wrote:
>>>
>>>> <piadoca_com-fundo-de-verdade>
>>>>     Os únicos modinhas-devs que eu
>>>>     respeito são os que usam Elixir.
>>>>     #VeinNiMinUatizápi
>>>>
>>>>     Ainda assim, tal qual o C# e o C++
>>>>     em relação ao C, Elixir é uma
>>>>     abordagem afeminada do Erlang.
>>>> <piadoca_com-fundo-de-verdade>
>>>>
>>>> Flames > /dev/null
>>>>
>>>>
>>>>
>>>> Brincadeiras a parte, e voltando falando do FreeRouter...
>>>> Sou obrigado a reconhecer que o código deles parece realmente
>>>> organizado(como o Rubens falou).
>>>>     Pessoalmente o lance do "tudo em VRF" me pareceu bastante elegante.
>>>>
>>>> Mas mesmo dentro dessa organização vê-se a perna-curta que é a mentira
>> do
>>>> JVM fazendo jus...
>>>> Os famosos "middlewares" colocados aonde o bicho pega de verdade.
>>>>
>>>>
>>>> Eu ainda gostaria de ver um conjuntão de pacotes de Routing todo feito
>> em
>>>> alguma linguagem Shared-Nothing.
>>>>   - Imagine isso rodando em ambientes MultiCore (61 cores XeonPhi ou
>> então
>>>> 5mil cores da Tesla)
>>>>   - Imagine isso para rodar um Controller de OpenFlow
>>>>     em processamento distribuído com 10-12 nós.
>>>>   - E para não dizer que não falei dos nanicos... Imagine isso rodando
>> num
>>>> Raspeberry?
>>>>
>>>> Em 29 de dezembro de 2015 21:22, Elizandro Pacheco [ Pacheco Tecnologia
>>> ] <
>>>> elizandro at pachecotecnologia.net <javascript:;>> escreveu:
>>>>
>>>>> Ou em python! :P
>>>>>
>>>>>
>>>>> Elizandro Pacheco
>>>>>
>>>>>> Em 29 de dez de 2015, à(s) 15:12, Rubens Kuhl <rubensk at gmail.com
>>>> <javascript:;>>
>>>>> escreveu:
>>>>>> 2015-12-29 14:40 GMT-02:00 Fernando Frediani <fhfrediani at gmail.com
>>>> <javascript:;>>:
>>>>>>> Meu caro Rubens. Infelizmente eu não posso falar sobre Java com o
>>>> mesmo
>>>>>>> entusiasmo que você.
>>>>>>>
>>>>>> Eu também por default torço o nariz para coisas escritas em Java,
>> por
>>>>>> exemplo os NMS da ManageEngine... mas eu já vi um sistema complexo
>>> em C
>>>>> que
>>>>>> atendia milhões de usuários (não é força de expressão, eram milhões
>>>>> mesmo)
>>>>>> ser substituído por um escrito em Java e vi que as dificuldades de
>>>>> scaling
>>>>>> tem como ser endereçadas. O que se fez foi criar um conjunto de
>>> classes
>>>>>> muito sólido e rápido - usando o melhor expertise da equipe - que
>>>> depois
>>>>>> eram reutilizadas por gente não tem experiente mas que não tinha
>>> muito
>>>>> como
>>>>>> errar ao seguir um modelo já pornto.
>>>>>>
>>>>>>
>>>>>>> Se há preocupação com a qualidade do código eu me perguntou por
>> qual
>>>>> razão
>>>>>>> foram escolher justo Java então.
>>>>>>>
>>>>>> Eu não sei o motivo do autor do freeRouter, mas posso te comentar o
>>>>> motivo
>>>>>> da escolha do caso que vivi acima: longevidade. O que se vê em
>>>> linguagens
>>>>>> de programação é que a cada ano existe a linguagem do momento, que
>>>> depois
>>>>>> perde momentum e é substituída por outras... então se você imagina
>> o
>>>>>> cenário em que daqui a 10 anos alguém precise der manutenção num
>>>> código,
>>>>>> ele leva a soluções que não sejam nem as melhores nem muito ruins,
>>> mas
>>>>> que
>>>>>> sejam algo médio que ainda existirá.
>>>>>>
>>>>>>
>>>>>>> feitas em Java ou algo similar. Mas olhando o todo e por default
>> eu
>>>> não
>>>>>>> vejo Java com tanto entusiasmo assim aonde quer que ele exista.
>>>>>>>
>>>>>>>
>>>>>> Cuidado que a interface do Gmail é Java, então ela pode se magoar e
>>>> fazer
>>>>>> seu e-mail passar a dar problemas... ;-)
>>>>>>
>>>>>>
>>>>>>> Sobre o software em questão parece interessante e com um leque de
>>>>>>> funcionalidades que até mesmo outras opções free ou pagas não
>>> possuem.
>>>>>>> Também gostei da simplicidade que provavelmente vem da filosofia
>>>>> K.I.S.S e
>>>>>>> que é sempre muito bem vinda.
>>>>>>>
>>>>>> Você pode reescrever o projeto dele em Go se preferir...
>>>>>>
>>>>>>
>>>>>> Rubens
>>>>>> --
>>>>>> gter list    https://eng.registro.br/mailman/listinfo/gter
>>>>> --
>>>>> gter list    https://eng.registro.br/mailman/listinfo/gter
>>>>>
>>>>
>>>>
>>>> --
>>>> Douglas Fernando Fischer
>>>> Engº de Controle e Automação
>>>> --
>>>> gter list    https://eng.registro.br/mailman/listinfo/gter
>>>
>>>
>>> --
>>> ./diogo -montagner
>>> JNCIE-SP 0x41A
>>> --
>>> gter list    https://eng.registro.br/mailman/listinfo/gter
>>>
>>
>>
>> --
>> Douglas Fernando Fischer
>> Engº de Controle e Automação
>> --
>> gter list    https://eng.registro.br/mailman/listinfo/gter
>
>

-- 
##################################################
:UNI><BSD:
Paulo Henrique
UnixBSD Tecnologia
Segurança em Tecnologia da Informação
Fone: (21) 96713-5042
Site: https://www.unixbsd.com.br
##################################################