2011/1/12 Douglas Campos <[email protected]> > > Não entendi. Qual preconceito? > Era brincadeira :P >
Ah, era engraçado? :P > > Ok, pode me chamar de velho, old-school, o que for. Mas na minha época, > > file-system era algo que tinha alguma coisa a ver com o kernel do sistema > > operacional. Mesmo com o uso cada vez menos incomum de "user space" file > > systems hoje, sempre há um gancho no kernel. Por exemplo, sou um feliz > > usuário de sshfs [1], mas ele precisa que o fuse [2] faça o gancho dentro > do > > kernel do Linux. > > uso o fuse também, mas já sofri bastante com infra restritiva (que não > deixava você colocar nada no kernel), logo essas coisas "application > level" fazem algum sentido pra desembaraçar o processo de deploy > eu sou de infra, eu faço restrições, principalmente quando o developer quer usar feature X ou Y porque é legal para caramba, sem que haja algo que sequer lembre vagametne uma garantia de que isso não irá prejudicar a estabilidade do sistema, e a responsabilidade de mantê-la (a estabilidade) é minha. > Dei uma lida rápida no começo da documentação do HDFS. Ok, entendi (em > > linahs gerais) o que o cara quis fazer. Eu mudaria o nome de "filesystem" > > para algo como "JVM-based filesystem" ou algo assim, para evitar > > ambiguidades. But hey, that's just me. > > A idéia não é performance, é escalabilidade, então sem problemas > > > Pessoalmente eu não sei se usaria algo em Java (+ pesado) para lidar com > > algo que pode ter requerimentos de performance como I/O de dados. Algo em > > Cuidado com a falácia de que java é pesado, o foco da vm é otimização > adaptiva, e no caso de long-running processes pode até ganhar de muita > aplicação com otimização agressiva (já bati código C compilado com -O4 > usando java). > eu trabalho com java. sorry: java É pesado. não necessariamente em CPU, mas com certeza em memória, e os programadores cabações que acham que o garbage collector é um duende miraculoso que some imediatamente com todos os objetos não utilizados e que memória é infinita, esses não ajudam em nada a mudar essa visão. otimização adaptativa é o foco da jvm da sun^Woracle, não necessariamente de todas as JVMs. por exemplo trabalho com websphere, que é da IBM, e usa a JVM da IBM, que faz Just InTime compiling na hora do load, de tudo, para binário nativo, em memória. A CPU disso depois é uma delícia, mas imagine o custo em memória, e o tempo de startup... > > não faria sentido se não usassem. Eu pensaria em algo feito em C/C++ para > > implementar esse "file system", e que provesse essa funcionalidade > > "genérica" em todas as plataformas onde fosse compilado, mas que pudesse > se > > proveitar de coisas como o FUSE no Linux para ser acessado diretamente > como > > um "real file system" (mesmo que em user-space), sem que isso tenha um > custo > > de performance tão alto. > > Resumindo: a merda é tentar vender como fs, mesmo sendo um fs devia > ser vendido como datastore > my point exactly. estava me faltando essa palavra: "datastore". ou melhor, um "datastore distribuído" ;-) []s, -- Alexei Znamensky [russoz_gmail_com] [russoz.wordpress.com] [ www.flickr.com/photos/alexeiz] «Only love / Can bring the rain / That makes you yearn to the sky»
=begin disclaimer Sao Paulo Perl Mongers: http://sao-paulo.pm.org/ SaoPaulo-pm mailing list: [email protected] L<http://mail.pm.org/mailman/listinfo/saopaulo-pm> =end disclaimer
