gildot

Topo
Sobre
FAQ
Tópicos
Autores
Preferências
Artigos
Sondagens
Propor artigo


8/3
gildicas
9/30
jobs
10/9
perguntas
10/25
press

 
Too cool for secure code
Contribuído por vd em 28-03-03 10:22
do departamento de-bater-com-a-cabeça-na-parede-antes-de-escrever
News CrLf escreve "Segundo este artigo no security focus o pessoal devia deixar de programar em C/C++ e virar-se para linguagens de mais alto nível para reduzir o número de vulnerabilidades no software. Segundo o autor os benefícios de performance de programar em C já não se justificam: "Until Unix and Linux programmers get over their macho love for low-level programming languages, the security holes will continue to flow freely.".

Podia começar já aqui um projecto para reimplementar, por exemplo, todo o KDE em Java ou melhor ainda, o Apache em Prolog (seguido de um tiro na cabeça...). "

Licenciados em Portugal para quê? | Depois de Extremadura ... agora a Andalucia  >

 

gildot Login
Login:

Password:

Referências
  • Linux
  • CrLf
  • artigo
  • Mais acerca News
  • Também por vd
  • Esta discussão foi arquivada. Não se pode acrescentar nenhum comentário.
    Re: Tool Cool (Pontos:3, Interessante)
    por Strange em 28-03-03 11:20 GMT (#1)
    (Utilizador Info) http://strange.nsk.no-ip.org/
    " Podia começar já aqui um projecto para reimplementar, por exemplo, todo o KDE em Java ou melhor ainda, o Apache em Prolog (seguido de um tiro na cabeça...)."

    Hehe, mas teria a sua piada, como o httpd em postscript

    De qualquer modo, o tipo nao e' muito coerente. Primeiro porque despreza as linguagens de baixo nivel e as pessoas que as usam para aplicacoes com performance nao critica, e depois ja' se lembra de falar em problemas de seguranca em aplicacoes feitas em PHP ou Perl. E depois em que ha' ferramentas para tornar a programacao em linguagens de baixo nivel mais seguro...

    Segundo, porque afirma que a analogia com pilotos de caca e' falaciosa, mas usa outra com pilotos de aviacao comercial.

    Terceiro, ignora que programacao segura baseia-se em metodos e procedimentos, nao em linguagens.

    Quarto, de que ha' varios projectos codificados em linguagens de baixo nivel com seguranca, por enquanto, inviolada.

    hugs
    Strange

    Re: Tool Cool (Pontos:1)
    por kaser em 28-03-03 13:25 GMT (#7)
    (Utilizador Info) http://kaser.nsk.yi.org
    Lol para o servidor de http em postscript!
    Fixe estão os comentarios que o tipo recebeu! site
    como por exemplo:
    "Yeah. This is *very cool* nonsense :-)"
    "That is a way cool hack. Thanks for giving me a smile!"
    Hugs,
    Kaser
    Off Topic (Pontos:2)
    por Branc0 em 28-03-03 14:25 GMT (#9)
    (Utilizador Info) http://www.syners.org
    Pilotos de "caca" ? Acho que os pilotos que ele se refere são bastante bons ;)


    "Se vi mais além do que outro, é porque estava nos ombros de gigantes."
    Sir Isaac Newton

    Re:Off Topic (Pontos:2)
    por Strange em 03-04-03 0:49 GMT (#37)
    (Utilizador Info) http://strange.nsk.no-ip.org/
    Erm... *coff*... nao encontrei o "ç"... :)

    hugs
    Strange

    Re: Tool Cool (Pontos:2)
    por Cyclops em 29-03-03 10:42 GMT (#28)
    (Utilizador Info) http://www.1407.org
    5. A maioria dos bugs de segurança com código C vem de o pessoal só ler a parte da sintaxe da função na man page, raramente a DESCRIPTION e quase nunca a parte do Return value :)
    Re: (Pontos:1)
    por Pirlas em 28-03-03 11:32 GMT (#2)
    (Utilizador Info) http://edgar.santarem.org
    Nao querendo fazer parecer isto deja vu... mas e se falassemos do windows? Esse ja nao tem problemas? Se calhar os programadores da micro$oft ja nao tem "macho" love. Enfim. Em regra geral ele ate tem razao. A acomodacao de algumas pessoas em relacao a linguagens da asas a erros sistematicamente cometidos, mas, o uso de outras linguagens como base para alguns projectos. Enfim... Como alguem referiu atras... Pode-se sempre tentar fazer um httpd em Prolog.
    Edgar Durao (Pirlas)
    largar o C? (Pontos:1)
    por Uranus em 28-03-03 12:04 GMT (#3)
    (Utilizador Info) http://urt.clanhosted.com
    pah, eu gosto muito do C... e não é "macho" love até porque quando quero fazer uma coisita rapida ate vou ao delphi/visual basic/kylix/.

    A cena eh k no linux o suporte (pelo menos grafico) não é grande coisa (à excepcao do kylix que continuo a preferir C pra qualquer projecto que exige mais atencao), talvez devido ao facto de não existir um desktop "unico" e toda a gente querer comecar um novo

    /me hopes that mono gains popularity
    Humm... (Pontos:2)
    por leitao em 28-03-03 12:10 GMT (#4)
    (Utilizador Info) http://scaletrix.com/nuno/
    Podia começar já aqui um projecto para reimplementar, por exemplo, todo o KDE em Java ou melhor ainda, o Apache em Prolog (seguido de um tiro na cabeça...).

    Acho que nao percebes o ponto do artigo. Se leres (e pensares) a comparacao feita entre os "fighter pilots" e os "airline pilots" no artigo poderas (talvez) compreender o que se esta' a tentar dizer.


    "Arguing on the Internet is like running in the Special Olympics -- Even if you win you're still retarded."

    Re:Humm... (Pontos:2)
    por cgd em 28-03-03 12:19 GMT (#5)
    (Utilizador Info)

    O problema é que o artigo está-se a dirigir aos fighter pilots -- os gajos que fazem o kde, gnome, linux ... -- e não aos pilotos de aviação comercial, que são a maior parte dos bacanos que desenvolvem software em empresas. Esses já desenvolvem muito pouco mesmo em C (esse pouco está relacionado com legacy code).


    -- carlos

    Re:Humm... (Pontos:2)
    por leitao em 28-03-03 14:16 GMT (#8)
    (Utilizador Info) http://scaletrix.com/nuno/
    O problema é que o artigo está-se a dirigir aos fighter pilots -- os gajos que fazem o kde, gnome, linux ... -- e não aos pilotos de aviação comercial, que são a maior parte dos bacanos que desenvolvem software em empresas. Esses já desenvolvem muito pouco mesmo em C (esse pouco está relacionado com legacy code).

    Continuas a nao perceber. Hint: qual e' a prioridade numero 1 para um piloto comercial ?


    "Arguing on the Internet is like running in the Special Olympics -- Even if you win you're still retarded."

    Re:Humm... (Pontos:2)
    por cgd em 28-03-03 14:38 GMT (#11)
    (Utilizador Info)

    Eu acho que tu é que não percebeste. Qual é a prioridade número 1 de quem desenvolve os sistemas que eu referi (ou que foram referidos nos artigos)?


    -- carlos

    Re:Humm... (Pontos:1)
    por Pink em 28-03-03 13:21 GMT (#6)
    (Utilizador Info) http://www.PinksWorld.8m.com
    Acho que nao percebes o ponto do artigo.

    yup. O sarcasmo ao falar em Java e Prolog demostra justamente isto.

    Existem sistemas operacionais inteiros escritos em outras linguagens que não o C, como o Oberon. Soube até de um S.O. feito 100% em pascal (se achar o link posto depois).

    Fanatismos e ignorância à parte, qualquer um que escolha C ou C++ para escrever um aplicativo grande está procurando problemas. Dar manutenção nestes programas é um inferno, e a falta de colaboração do compilador (que é quase tão permissivo no controle de tipos de dados quanto um montador Assembler) não ajuda. Humanos cometem erros às pencas.

    Use a ferramenta certa para o trabalho certo. Existem vida inteligente além do C/C++ - e me parece que o inverso nem sempre é verdadeiro...

    E se for para desenvolver em C, que pelo menos aprendam e usem ObjectiveC, pombas.

    []s,
    Pink@Manaus.Amazon.Brazil.America.Earth.SolarSystem.OrionArm.MilkyWay.Universe

    Re:Humm... (Pontos:2)
    por CrLf em 28-03-03 15:02 GMT (#14)
    (Utilizador Info) http://crodrigues.webhop.net
    Existem sistemas operacionais inteiros escritos em outras linguagens que não o C, como o Oberon. Soube até de um S.O. feito 100% em pascal (se achar o link posto depois).

    O meu sarcasmo não indicava que não era possível, apenas que não é lá grande ideia. Exemplos académicos não contam, porque são isso mesmo, académicos.

    Use a ferramenta certa para o trabalho certo. Existem vida inteligente além do C/C++ - e me parece que o inverso nem sempre é verdadeiro...

    E o C/C++ é em muitos casos a ferramenta certa, dependendo também em parte das qualidades do programador. E além disso se reparares há por aí muitas ferramenta escritas em Python (por exemplo) e também não são imunes aos mesmos erros de que o tipo fala no artigo.

    -- Carlos Rodrigues
    Re:Humm... (Pontos:1)
    por Pink em 28-03-03 15:57 GMT (#17)
    (Utilizador Info) http://www.PinksWorld.8m.com
    Exemplos académicos não contam, porque são isso mesmo, académicos.

    Exemplos acadêmicos não contam?

    Alguém por aí já ouviu falar de um negócio acadêmico/militar chamado Internet? Unix? K&R C?


    []s,
    Pink@Manaus.Amazon.Brazil.America.Earth.SolarSystem.OrionArm.MilkyWay.Universe

    Re:Humm... (Pontos:2)
    por CrLf em 28-03-03 22:52 GMT (#25)
    (Utilizador Info) http://crodrigues.webhop.net
    Alguém por aí já ouviu falar de um negócio acadêmico/militar chamado Internet?

    Dizes bem, militar. Mas também poderia dizer que ainda é um projecto do tempo em que nas universidades se fazia investigação que tinha a ver com a vida real.

    Unix? K&R C?

    Da Universidade AT&T.

    Não estou com isto a dizer que os projectos académicos não sirvam para nada, apenas que os seus propósitos são diferentes, logo não contam quando se está a falar de software para usar na vida real.

    -- Carlos Rodrigues
    Re:Humm... (Pontos:1)
    por Pink em 31-03-03 16:19 GMT (#34)
    (Utilizador Info) http://www.PinksWorld.8m.com
    Dizes bem, militar.

    Não entendes o que eu digo. Eu disse Acadêmico/Militar, não apenas Acadêmico, não apenas Militar.

    Mas também poderia dizer que ainda é um projecto do tempo em que nas universidades se fazia investigação que tinha a ver com a vida real.

    Sorry, pal... Mas acho que vc não conhece muito da História da Internet. Em 1960, uma rede mundial de pacotes era vista como utopia, como algo impraticável. As Universidades americanas levaram décadas para viabilizar a idéia.

    Como o MULTICS. Só que os conceitos do MULTICS foram parcialmente implementado pela AT&T, sob o nome UNIX. Que por sinal, com o passar das décadas, foi acrescido justamente das funcionalidades do MULTICS que a AT&T, na época, considerava inimplementáveis (motivo pelo qual ela resolveu investir no UNIX).

    Da Universidade AT&T.

    Unix foi construído à partir do conhecimento adquirido pela AT&T durante os tempo em que ela participou do esforço de concepção do MULTICS. O C foi inventado porque precisavam de uma linguagem de baixo nível, mas que permitisse alguma portabilidade.

    IMHO, iste tem tudo à ver com a discussão, porque C/C++ acabou sendo usado para escrever aplicações que seriam melhor construídas em uma linguagem de maior nível.

    Não estou [...] a dizer que os projectos académicos não sirvam para nada, apenas [...] não contam quando se está a falar de software para usar na vida real.

    Pois a vida real de hoje foi a utopia do passado. O que se faz nas Unvirsidades hoje será a vida real de amanhã.

    Não é porque vc não sabe aplicar o que se pesquisa nas Universidades que elas hão de não ter utilidade na "vida real". O Google nasceu numa universidade, num projeto de pesquisa de Data Mining (IIRC).

    []s,
    Pink@Manaus.Amazon.Brazil.America.Earth.SolarSystem.OrionArm.MilkyWay.Universe

    Re:Humm... (Pontos:2)
    por CrLf em 01-04-03 2:57 GMT (#36)
    (Utilizador Info) http://crodrigues.webhop.net
    Vou repetir:
    "Não estou com isto a dizer que os projectos académicos não sirvam para nada, apenas que os seus propósitos são diferentes, logo não contam quando se está a falar de software para usar na vida real."

    Hoje em dia os projectos académicos estão menos virados para produzir soluções. Os seus objectivos são mais investigação pela investigação e depois ver o que se aproveita dali.

    Mas quanto aos teus exemplos importa frisar que eram desafios técnicos difíceis para a altura, coisa que não acontece com o desenvolvimento de SOs em linguagens alternativas. É diferente tentar obter algo difícil de alcançar e perder tempo a reinventar a roda quadrada sem trazer nada de novo(*).

    (*) antes de achares que me estou a contradizer, volta ao inicio do meu comentário.

    -- Carlos Rodrigues
    CPU power... (Pontos:4, Interessante)
    por cgd em 28-03-03 14:34 GMT (#10)
    (Utilizador Info)

    Algo profundamente irritante que se ouve e lê vezes sem conta, é algo do estilo: "como as máquinas cada vez são mais rápidas, têm mais memória, mais espaço em disco, então... podemos fazer software mais lento, usar mais memória, ocupar mais espaço etc...".

    Além de isto não ser verdade (quem trabalha para empresas com necessidades reais de software para sustentação de negócio -- facturação, por exemplo-- sabe que a performance é *sempre* uma área crítica, e que por vezes a escolha das tecnologias baseia-se em factores de desempenho!) é quase um misto entre regressão da teoria da evolução e tragédia dos comuns: a evolução dos outros resolve os nossos problemas. Se todos pensassem da mesma maneira, ninguem fazia nada, ou alternativamente, fazia-as sempre da mesma maneira, nunca evoluindo, porque o produto A que o fulano B fez ontem vai melhorar o meu produto C. No limite era a estagnação. Cruel... e perigoso!

    No artigo original é defendido o mesmo: os CPU são rápidos para termos que programar em C. Podemos usar coisinhas mais lentas, sistemas pesados que oferecem um pouco mais (apenas um pouco mais) de segurança, porque as máquinas resolvem os nossos problemas. A nossa incapacidade e preguiça é curada pelos outros. Se hoje for lento, amanhã já não o será.

    Isto é uma grande falácia: a lei de moore originalmente dizia que o número de transistores por chip duplicaria em cada ano (tb aqui existem uma série de má concepções, urban-myths, whatever). Mais tarde Moore corrigiu para dois anos (a densidade duplicaria cada a dois anos). Na mesma altura em que fez essa correcção, outra pessoa da intel disse que isso teria um efeito de duplicação de performance dos CPUs a cada 18 meses. Entretanto é a esta afirmação a que se chama "Moore's Law", embora o próprio admita que não é dele. Na verdade, a performance dos CPUs tem estado a duplicar a cada 20 meses.

    Só que o volume de dados/informação a processar (i.e. informática!) cresce muito mais rápido. Em 1998 estimava-se que os conteúdos na internet cresciam duas vezes a cada 50 dias. Ora os algoritmos de processamento de dados são, nos melhores casos, lineares e na maior parte dos casos quadráticos ou exponenciais. Isso significa que para continuar a manter o passo temos que empregar melhores algoritmos e usar melhores técnicas/tecnologias (processamento paralelo, clustering, grid computing, ...). Ou seja, não podemos descurar nem a performance, nem a "bondade" dos sistemas só com a desculpa de que as máquinas de amanhã nos vão resolver o problema. Se alguem quiser fazer, digamos, um software para data mining em java, porque é mais seguro/fácil/[insert your hype here] e as máquinas vão acelerar isto, é bom que se preocupe simultaneamente em tornar a tarefa facilmente escalavel para várias máquinas, por exemplo.


    -- carlos

    Re:CPU power... (Pontos:0, Gozão)
    por leitao em 28-03-03 14:57 GMT (#13)
    (Utilizador Info) http://scaletrix.com/nuno/
    Além de isto não ser verdade (quem trabalha para empresas com necessidades reais de software para sustentação de negócio -- facturação, por exemplo-- sabe que a performance é *sempre* uma área crítica, e que por vezes a escolha das tecnologias baseia-se em factores de desempenho!)

    Sim, alias os sistemas de billing da AMDOCS, Geneva, etc sao todos escritos em Assembler!!

    tks, tsk, tsk...


    "Arguing on the Internet is like running in the Special Olympics -- Even if you win you're still retarded."

    Re:CPU power... (Pontos:2)
    por cgd em 28-03-03 15:09 GMT (#15)
    (Utilizador Info)

    Há gajos que gostam realmente de embirrar. Isto: «[..]software [...] em java [...] é bom que se preocupe simultaneamente em tornar a tarefa facilmente escalavel para várias máquinas, por exemplo», passou-te ao lado?

    Nunca trabalhei com nenhum do soft que mencionas. Sei que o AMDOCS era usado na OniWay e é em java. Mas o processamento dos CDRs, por exemplo, está integrado na plataforma, em java?


    -- carlos

    Re:CPU power... (Pontos:1, Despropositado)
    por leitao em 28-03-03 15:26 GMT (#16)
    (Utilizador Info) http://scaletrix.com/nuno/
    Nunca trabalhei com nenhum do soft que mencionas.

    Se nunca trabalhaste com ferramentas de facturacao -- entao o que te leva a dizer que a performance e' assim tao critica como dizes ?

    A performance e', sem duvida, um factor -- mas o que convem referir e' que para a maioria das aplicacoes de negocio, a escalabilidade raramente e' atingida atraves de software optimizado para ser performante, mas sim atirando mais hardware ao problema. Qualquer um que tenha trabalhado em projectos de billing sabe isto.


    "Arguing on the Internet is like running in the Special Olympics -- Even if you win you're still retarded."

    Re:CPU power... (Pontos:3, Esclarecedor)
    por cgd em 28-03-03 16:03 GMT (#18)
    (Utilizador Info)

    Nunca trabalhei com nenhum do software que mencionaste. Não sabes ler pá?! Já trabalhei com outros sistemas de billing (eu era o responsável técnico de billing na teleweb). Continuo a acompanhar a área, embora de forma não directa.

    atirando mais hardware ao problema

    Errado! Qualquer pessoa sabe que isso não resolve o problema. Apenas o disfarça. Resolveria-o se o software fosse escalável, o que nem sempre acontece (a maior parte dos casos?). Assim sendo, é uma questão de crescimento de CPU power vs volume de dados. O volume de dados ganha. As empresas têm uma margem para manobrar: é que o hardware que dispõe não representa o topo de capacidade de processamento. Vão atirando hardware para cima até o poderem fazer. Quando deixa de ser possivel/comportavel preocupam-se ou em fazer tunning das aplicações, ou em comprar outras novas (que teoricamente resolvam o problema de performance). Acredita que da experiencia que eu tenho, a palavra "performance" é recorrente praticamente em todas as áreas técnicas (desde networking, sistemas, às diversas áreas de aplicações), especialmente em empresas com grande volume de dados (muitos clientes ou muitas transacções).

    Exemplos: um software mauzinho que corria em maquinas sun, esgotou o limite de memoria fisico da maquina (6GB). Maquinas novas? Nao! As novas (ultrasparcIII) precisavam solaris8+. A aplicação só corria em solaris 5.6... Ciclos de facturação que demoravam ~8h a ser corridos, com tunning de SQL passaram a ~1h. Sistemas de middleware que deviam interligar todos os sistemas de software de empresas, mas por razoes de performance, os diversos sistemas acabam por ir às bases de dados uns dos outros(!) -- onde é que se mete o hw aqui? Fases de pos-processamento de CDRs escritas em linguagens fáceis para o efeito (perl por exemplo) reescritas em C porque eram demasiado lentos e ocupavam muita memória. Tudo isto são exemplos reais que afectam a vida das empresas e não se resolvem despejando simplesmente hardware para cima. Quanto mais sistemas interligados existirem, menos efeito têm as máquinas adicionais (porque o sistema A faz feed ao B, por exemplo).


    -- carlos

    Re:CPU power... (Pontos:2)
    por leitao em 28-03-03 17:56 GMT (#20)
    (Utilizador Info) http://scaletrix.com/nuno/
    Errado! Qualquer pessoa sabe que isso não resolve o problema. Apenas o disfarça. Resolveria-o se o software fosse escalável, o que nem sempre acontece (a maior parte dos casos?). Assim sendo, é uma questão de crescimento de CPU power vs volume de dados. O volume de dados ganha.

    O que e' escalibilidade para ti ? Dando-te um exemplo: Apache 1.x, e' um servidor muito capaz, mas nao escala muito bem. Como e' que resolves o problema ? Distribuis Apache num cluster web. Isto significa que o software nao e' escalavel ? Nao, significa que nao e' escalavel verticalmente (na mesma maquina), mas e' escalavel horizontalmente (em ambientes distribuidos). Neste caso resolves o caso atirando mais hardware ao problema.

    Muito do software corporativo escala horizontalmente e nao necessariamente verticalmente -- pela simples razao de ser a forma mais simples de atingir escalibilidade, percebes ?

    Acredita que da experiencia que eu tenho, a palavra "performance" é recorrente praticamente em todas as áreas técnicas (desde networking, sistemas, às diversas áreas de aplicações), especialmente em empresas com grande volume de dados (muitos clientes ou muitas transacções).

    A tua experiencia e' diferente da minha: na minha experiencia a palavra chave e': escalibilidade -- e' por exemplo a razao porque a Zeus nunca conseguiu destronar os concorrentes (Apache, IIS e Netscape) -- porque embora o servidor da Zeus seja altamente escalavel verticalmente, a diferenca de custo em relacao ao Apache nao justifica o factor de escalibilidade horizontal. O mesmo acontece em outras aplicacoes corporativas: Geneva, SAP, etc -- o que realmente interessa nao e' se uma maquina consegue atingir o throughput necessario, mas sim se em geral a plataforma consegue escalar (horizontalmente) de uma forma que consiga acompanhar o crescimento do volume de dados.

    Quanto mais sistemas interligados existirem, menos efeito têm as máquinas adicionais (porque o sistema A faz feed ao B, por exemplo)

    Um caso que e' o contrario: porque e' que as maiores (e melhores) instalacoes de Oracle que andam por ai sao as distribuidas usando o Oracle Paralel Server ? Porque a Oracle sabe que para um volume de dados cada vez mais a escalibilidade horizontal e' muito mais importante do que a vertical. E como e' auto-evidente, quando podes escalar horizontalmente nao interessa se demora +5ns a processar uma transaccao.


    "Arguing on the Internet is like running in the Special Olympics -- Even if you win you're still retarded."

    Re:CPU power... (Pontos:2)
    por cgd em 28-03-03 18:53 GMT (#23)
    (Utilizador Info)

    Finalmente (à terceira) conseguiste deixar de desconversar e dizer algo interessante (estou a falar a sério) -- só não percebo porque é que teimaste sempre em escrever escalibilidade :-)

    Obviamente que concordo com tudo o que disseste, mas repara que isso foi o que eu disse logo no primeiro comentário, i.e., o software ou é eficiente ou escalável (no sentido horizontal que definiste): «Isso significa que para continuar a manter o passo temos que empregar melhores algoritmos e usar melhores técnicas/tecnologias (processamento paralelo, clustering, grid computing, ...)». Parece que é isto tudo que eu disse, certo?

    tua experiencia e' diferente da minha: na minha experiencia a palavra chave e': escalibilidade

    Erro! Se leres melhor os meus comentários, vais ver que ressalvei sempre a escalabilidade. Agora, não sejamos tacanhos: não podes paralelizar todas as tarefas que andam por aí. Se há coisas que estão "mesmo a pedir" -- a maior parte das network based applications (serviços tcp por exemplo) -- existem outras que não o são facilmente, ou que não o justificam -- fazer crunching de dados, por exemplo, um enorme ficheiro do qual deves produzir um report.

    Nestes últimos casos, quem criar uma aplicação pesada, numa linguagem "fácil" e esperar que máquinas mais rápidas lhe vão resolvendo o problema está a cometer um grave erro, poque o ficheiro há-de crescer mais depressa.

    O ideal é desenvolver uma aplicação eficiente que use bons algoritmos de processamento de dados. Agora boas implementações existem em muitas linguagens, ver este exemplo para gerar indices invertidos em java. Mas as palavras chaves aqui são implementações eficientes. Quem fica à espera que os outros lhe resolvam os problema lixa-se!


    -- carlos

    Re:CPU power... (Pontos:2)
    por cgd em 28-03-03 19:11 GMT (#24)
    (Utilizador Info)

    Atenção que os casos que eu descrevi são casos que eu conheço / conheci. Em muitos deles a minha participação até era do lado de sistemas/máquinas (o caso do solaris) outros nem me dizem respeito.

    Quanto à tua divisão programação/sistemas, não é bem assim. O problema em muitos dos casos residiu nas **implementações**. No caso de solaris, a app comeu a memória por erro de implementação e não por necessidade.

    Quanto ao "mal escrito em perl": este foi um caso que tive conhecimento, nunca vi as implementações, mas pensa em como representas um estrutura em C e como o fazes em perl, na diferença de memória que usas num caso e noutro e no tempo de execução. Depois pensa em criar grandes listas de estruturas de estruturas...

    Quanto aos sistemas interligados, claro que são dependentes. É isso que significa a interligação: as coisas tornam-se dependentemente entre si porque estão ligadas entre si. O problema de performance aqui resulta do "elo mais fraco". A adição de máquinas nestes casos equivale grossamente à adição de processadores numa máquina (uma dual-processor não é duas vezes mais rápida que uma single-processor). Não estava a falar de ir à mesma source de dados. Esses casos curiosamente são os mais fáceis de resolver em interligação de sistemas: o grafo das dependencias é mais simples-- tentas melhorar a performance do feeder, paralelizando, mais interfaces de network, ...


    -- carlos

    Re:CPU power... (Pontos:2)
    por leitao em 28-03-03 17:58 GMT (#22)
    (Utilizador Info) http://scaletrix.com/nuno/
    Ja' agora, a AMDOCS nao e' um produto, e' uma empresa.


    "Arguing on the Internet is like running in the Special Olympics -- Even if you win you're still retarded."

    Re:CPU power... (Pontos:1)
    por lucipher em 29-03-03 10:29 GMT (#27)
    (Utilizador Info) http://www.google.com
    Não tem muito a ver, mas ja tinha lido algo muito identico ao que disseste acima, passo a citar:

    "everyone has heard the arguement that there is no point in spending days optimizing code because the speed of computers is increasing. it seems a bit ironic to me that brilliant phd's spend years researching smaller die techniques and improving processor performance so that users can run poorly designed software. the truth of this is computers are being made faster so that people can do more not run the next revision of crapware. i encourage any and all developers to at least read knuth's art of computer programming and get some basic idea of how to design software." in uberhax0r



    --
    He that seeketh findeth; and to him that knocketh it shall be opened.
    C/C++ (Pontos:2, Interessante)
    por moonrider em 29-03-03 10:20 GMT (#26)
    (Utilizador Info)
    Deixar de programar em C/C++ não vai resolver qualquer problema de segurança com aplicações ! Aprender a programar tendo a segurança em consideração, talvez sim.
    Não faz sentido que se perca performance numa aplicação apenas porque hoje em dia temos mais capacidade de processamento ( para certos sistemas a performance nunca é demais ), tal como não faz sentido abandonarmos a linguagem C porque poucos programadores pensam em segurança quando estão a desenvolver a aplicação.
    Ou se sabe programar, ou não. A linguagem C continua a ser perfeita para multiplas finalidades, certos programadores talvez não.
    Re:C/C++ (Pontos:2)
    por CrLf em 29-03-03 14:30 GMT (#29)
    (Utilizador Info) http://crodrigues.webhop.net
    se perca performance numa aplicação apenas porque hoje em dia temos mais capacidade de processamento

    Coisa que se diz desde sempre, já ouvia dizer isso dos 286 e dos 386. Faz lembrar "nunca ninguém vai precisar de mais de 640Kb de RAM".

    -- Carlos Rodrigues
    Re:C/C++ (Pontos:1)
    por moonrider em 29-03-03 15:29 GMT (#30)
    (Utilizador Info)
    Faz lembrar "nunca ninguém vai precisar de mais de 640Kb de RAM".

    Que falta de capacidade de interpretação !... Lê bem e vais reparar que eu estou a dizer exactamente o contrário, que não se deve desperdiçar processamento apenas porque se acha que se tem muito.
    Re:C/C++ (Pontos:2)
    por CrLf em 29-03-03 15:57 GMT (#31)
    (Utilizador Info) http://crodrigues.webhop.net
    Que falta de capacidade de interpretação ! Lê bem e vais reparar que eu estou a dizer [...] que não se deve desperdiçar processamento apenas porque se acha que se tem muito.

    Errm... eu estava a concordar!

    -- Carlos Rodrigues
    Prioridades (Pontos:2)
    por joaobranco em 01-04-03 0:46 GMT (#35)
    (Utilizador Info)
    Pois eu discordo (moderadamente).

    Não sou a favor de desperdiçar capacidade de processamento, mas sou de certeza a favor de trocar eficiência em tempo ou espaço por outra qualquer caracteristica que possa ser mais útil nesse momento e nesse projecto.

    Não é tão idiota assim não se preocupar demasiado com o tempo de processamento do computador porque se sabe que os computadores vão fazer a acção no tempo suficiente, se com esta acção se optimizar a utilização de qualquer outro recurso (por exemplo a capacidade de produção de programas da equipa de programação, ou a reutilizabilidade do código). E isso pode passar por usar ferramentas ou componentes que "gastam mais ciclos de CPU ou espaço em disco que os estritamente necessários para efectuar a tarefa".

    O que é mau é o desperdício, ou seja deixar de usar a capacidade e não ganhar nada com isso. Se se ganha alguma coisa, é uma escolha, que pode vir a ser verificada como correcta ou incorrecta de acordo com os factos efectivos em cima da mesa, mas que não se pode à partida classificar logo como errada.

    Cumps, JB

    Re:LMFAO (Pontos:0, Interessante)
    por Anonimo Cobarde em 28-03-03 16:03 GMT (#19)
    <quote>ROTFL.. o apache em prolog nao pq o code do apache é um nojo.</quote>

    apache_1.3.27$ find . -name "*.[ch]" | xargs --replace=% cat % | wc -l
    112746

    Humm, vamos la' ver algum codigo teu, entao... De preferencia algum projecto com cerca de 113 mil linhas.

    Pois e', code talks, bullshit walks. Alem de que nao te tenho visto, ultimamente (ou alguma vez, sequer), a oferecer ajuda 'a Apache Foundation, para melhorar o tal "nojo" de codigo, visto que programas tao melhor que os outros... Interessante, no minimo.
    Re:o mundo não é só cinza (Pontos:2)
    por CrLf em 30-03-03 23:08 GMT (#33)
    (Utilizador Info) http://crodrigues.webhop.net
    E quando a performance realmente _conta_, não venham falar de GCC.

    Também és daqueles que pensa que o gcc não gera código lá muito eficiente? Lamento informar-te que isso não é verdade.

    Ja nem falo da diferença de performance de C versus C++...

    Não há praticamente nenhuma.

    Ainda não percebi o que os evangelistas do C/C++ vêm de tão especial na linguagem.

    Quanto ao C, é o que ela não tem de tão especial.

    -- Carlos Rodrigues

     

     

    [ Topo | FAQ | Editores | Contacto ]