quinta-feira, 29 de novembro de 2007

Pidgin 2.3.0

Saiu a nova versão do Pidgin.

Para saber o que mudou veja o Changelog aqui.

Assim que os arquivos .deb estiverem disponíveis no GetDeb eu posto um comentário.

UPDATE (30/11): Baixe os pacotes .deb aqui. ATENÇÃO: remova a versão atual antes de instalar a nova.

Normalizando arquivos mp3 no Linux

Um dos problemas com mp3 é que às vezes queremos fazer um CD ou mesmo colocar vários arquivos em um player e eles tem volumes diferentes, o que é bastante desagradável, pois nos obriga a ficar ajustando o mesmo constantemente.

Para resolver isso, podemos normalizar os arquivos. Mas o que é normalizar os arquivos ? Basicamente é uma forma de deixar os arquivos todos em um volume similar, evitando a necessidade de estar toda hora ajustando o volume na hora de escutá-los.

Para realizar essa tarefa, existe no Linux um software chamado normalize-audio.

Com o normalize-audio é possível pegar vários arquivos e normalizá-los todos de uma só vez.

Como fazer ?

Vou explicar da forma mais básica, mas se você quiser saber mais leia o manual do software, pois ele tem vários outros recursos. Entre na pasta onde estão os arquivos que você quer normalizar e rode o comando:
normalize-audio -a -v *

Com esse comando, todos arquivos serão normalizados na amplitude padrão, o que já é bem interessante.

O normalize-audio na realidade seta um volume relativo de ajuste nas tags ID3 dos mp3, que depois é lido pelos players. Por padrão ele trabalha com a ID3v2.4. Infelizmente muitos players ainda não lêem esse formato, o que pode fazer que o ajuste não funcione. Se for seu caso, existe um parâmetro chamado --id3-compat que pode resolver a questão. É preciso testar para ver qual vai atender a demanda do player.

Tirando essa questão (que será resolvida conforme os players forem se adequando aos padrões), o normalize-audio é uma ferramenta prática e simples que vai tornar muito mais agrádavel escutar seus arquivos mp3, seja no computador ou seja em seu player.

UPDATE (30/11): A saber: o normalize-audio é a ferramenta de normalização usada pelo K3B.

segunda-feira, 26 de novembro de 2007

Compartilhando o Ubuntu

Alguns dias atrás a Vanessa Nunes da Zero Hora estava precisando de uns CDs do Ubuntu para instalar e testar pois ela queria escrever sobre o mesmo.

Pois bem, mandei os CDs pra ela e ela postou no seu blog. Parece que vai também escrever sobre o Ubuntu para o caderno ZH Digital. Talvez até já o tenha feito, mas isso eu não sei.

Bom, continuando: na sexta passada recebi meus CDs do Ubuntu Gutsy 7.10 e postei sobre isso. Hoje encaminhei pra ela o link do post e ela me disse que os CDs que eu mandei pra ela tinham passado pelas mãos de vários colegas no maior espírito de colaboração. Ela me passou inclusive um link de um post de outro blog lá (Infosfera) do ClicRBS que havia também tratado do assunto.

Show de bola né ?

PS: se eu soubesse que iam fotografar o CD eu tinha caprichado na letra. ;-)

Favoritos 2007 - Br-Linux.org

Já está no ar a votação dos Favoritos 2007 do Br-Linux.org.

Como todo ano, chegou a hora de votar e dar sua opinião sobre os melhores na área de Software Livre e Open Source.

Eu já votei!. Não perca tempo e vote já você também.

sexta-feira, 23 de novembro de 2007

Slides da palestra da Propus no VoIPCenter 2007

Alguns dias atrás postei sobre uma palestra de um case da Propus que seria apresentada no VoIPCenter 2007.

Pois bem, complementando aquele post, hoje o nosso diretor, Marlon Dutra, liberou os slides da mesma.

Se você tiver interesse e quiser saber mais, baixe os mesmos aqui.

Chegaram os CDs do Ubuntu/Kubuntu 7.10

É isso aí.

Chegaram meus CDs do Ubuntu e do Kubuntu 7.10 (35 dias após o lançamento).




E você já pediu os seus? Ainda não ? Pois não perca tempo e peça já:

Ubuntu
Kubuntu

Visualizador de logs de auditoria para Openfire

O "leitor" do blog, Celso Andrade, encontrou um visualizador para logs de auditoria do Openfire.

É uma pena que o software é somente para Windows. Mas se esse é seu caso, baixe o mesmo aqui.

PS: Eu não testei o software, mas o Carlos me disse que "basta executar ele e mandar abrir o XML que tem no servidor, na hora mostra o histórico de conversas".

PS2: Celso, desculpe o meu erro no teu nome. Ainda bem que hoje já é sexta, porque isso mostra que a mente já está muito cansada. ;-)

UPDATE 14/05/08: Esqueça os demais visualizadores de logs e leia mais sobre o Monitoring Service.

Restore - Onde encontrar os fontes.

Tempos atrás publiquei um post em meu blog falando sobre ferramentas de backup onde comentei sobre o RESTORE, e falei que o que me incomodava a respeito desse projeto era que eu não havia encontrado os fontes para download.

Pois bem: hoje recebi um e-mail do Presidente/CTO da Holonix onde ele me esclarecia os locais para download dos fontes, que são:

http://trac.holonyx.com/svn/restore/
http://sourceforge.net/svn/?group_id=198657
http://rubyforge.org/scm/?group_id=4561

Segue abaixo o e-mail na íntegra:

Saw a mention on your blog about RESTORE, we do indeed supply FULL sources for RESTORE, mirrored in at least three public locations.

http://trac.holonyx.com/svn/restore/
http://sourceforge.net/svn/?group_id=198657
http://rubyforge.org/scm/?group_id=4561

Also, there have been huge changes lately, I don't have the VM or Live CD done yet but .deb packages are always available at

http://distro.ruffdogs.com/restore/

Thanks so much for your attention to this project.

--
Garret Acott
President/CTO
Holonyx, Inc
970.232.2050

Ficam aqui minhas desculpas sobre a informação equivocada.

Assim que sobrar um tempo irei testar a última versão dessa ferramenta e postarei sobre isso aqui no blog.

quinta-feira, 22 de novembro de 2007

Usando o pdnsd para fazer cache local de DNS

O pdns é uma ferramenta desenvolvida para fazer cache local de DNS em seu desktop/servidor.

Mas por que motivo cachear o DNS ?
O cache local de DNS permite uma maior velocidade de navegação (principalmente em conexões lentas) pois evita que sempre que seja preciso resolver um nome seja necessário consultar um servidor DNS externo.
Além disso também garante uma maior disponibilidade de resolução de nomes no caso do servidor DNS externo apresentar problemas, o que evita que você, por exemplo, não possa navegar (obviamente o pdnsd só resolverá os endereços já cacheados, mas isso com certeza já ajuda muito).

Configurando
O pdns usa o arquivo de configuração /etc/pdnsd.conf.
Nesse arquivo é preciso informar os servidores DNS externos (podem ser um ou mais) onde o pdnsd irá conectar para resolver o nome que não está ainda cacheado e também como o pdnsd irá trabalhar (TTLs, diretórios de armazenamento, entre outras coisas).

Segue como exemplo uma configuração básica do pdnsd usando o DNS do Terra como exemplo (200.176.2.10):

// $Id: pdnsd.conf.in,v 1.4 2000/11/11 20:32:58 thomas Exp $

global {
perm_cache=512; # Tamanho maximo do cache em disco (em Kb)
cache_dir="/var/cache/pdnsd"; # Local do armazenamento do cache
max_ttl=604800; # TTL (Time to Live) em segundos. 1 semana
run_as="pdnsd";
paranoid=off; # Se for on, consulta sempre o DNS externo
# caso contrario usa o cache
status_ctl=on;
}


server {
ip="200.176.2.10"; # IP do Server DNS externo
timeout=30;
interval=30;
uptest=ping;
ping_timeout=50;
purge_cache=off;
}


source {
ttl=86400; # TTL do /etc/hosts (padrão 1 dia)
owner="localhost.";
file="/etc/hosts";
}
É preciso também alterar o /etc/resolv.conf de forma que o nameserver seja o localhost, deixando nele somente a seguinte linha:

nameserver 127.0.0.1

Atenção: Se você usa DHCP é normal que o resolv.conf seja reescrito sempre que o IP for "adquirido". Nesse caso, será sempre necessário alterar o arquivo após o computador "pegar" o IP.

E como funciona exatamente ?
Ao consultar o endereço, o pdnsd primeiro tenta localizar o endereço no cache. Se o endereço existir, ele vai verificar o TTL do mesmo. Caso o TTL não tenha ainda expirado, o IP cacheado será usado.
Caso o TTL tenha expirado ou o endereço não exista em cache, o pdnsd então irá procurar o endereço solicitado nos servidores DNS externos configurados.


Para quem quer uma navegação mais dinâmica, seja por pouca banda ou mesmo só para otimizar um pouco a velocidade, o pdnsd é uma opção interessante e de simples instalação, tanto para servidores quanto para desktops.

quarta-feira, 21 de novembro de 2007

KDE 4 RC1 - Pacotes disponíveis para Kubuntu 7.10

Saiu hoje o KDE 4 Release Candidate 1. Leia o anúncio oficial aqui.

Se você quiser testar o mesmo no Kubuntu 7.10 veja aqui como fazer.

E boa sorte para quem tentar :-)

PS: quem instalar, depois por favor poste seus comentários.

terça-feira, 20 de novembro de 2007

Usando impressoras fiscais Bematech no Linux via USB

Quem compra algum modelo de impressora fiscal Bematech que vem com USB (ex: MP3000) e tenta usar no Linux já deve ter percebido que não consegue fazer o software dela funcionar, apesar da mesma ser reconhecida normalmente pelo SO.

Pois é: realmente a aplicação fornecida pelo fabricante (bematech.out) não funciona se a impressora for ligada via USB no Linux.

O problema se dá pela seguinte razão: a impressora ao ser plugada no Linux via USB emula uma porta paralela e o software fornecido só trabalha com portas seriais.
Ao plugar a mesma num Ubuntu é criado automaticamente um /dev/usblp0. Configurando o software da impressora para mapear a porta usando esse device, ao tentarmos rodar o mesmo ele informa que houve problema com a porta serial. Foi percebido após alguns debugs que o software usa ioctl (que só funciona com portas seriais), e isso acaba causando o erro.

Em contato com o suporte da fabricante, a informação é de que realmente a impressora não funciona no Linux se plugada na porta USB, mas existe um projeto para desenvolver um software compatível que não tem ainda nem previsão de início, quanto mais de release.

E por enquanto o jeito mesmo é usar a boa e velha porta serial...

PS: se você desenvolver um software para isso, por favor depois poste aqui o link para os sources. ;-)

Firefox 3 - Beta 1 disponível para download.

Está disponível para download o Beta 1 do Firefox 3.
Agora de "maneira oficial", já que aparentemente o mesmo havia vazado na semana anterior.

Para mais informações e links para download, clique aqui.

sábado, 17 de novembro de 2007

Ubuntu lança atualização "bugada" do Samba

Quem usa o Samba com Ubuntu Dapper (6.06) e atualizou os pacotes ontem deve ter passado por uma surpresa bem desagradável.

A atualização liberada (3.0.22-1ubuntu3.4) estava bugada e a autenticação no domínio usando máquinas Windows parou de funcionar.

Logo após ao meio-dia (horário de Brasília) os pacotes foram removidos, mas aí já era pra muita gente.

A solução encontrada naquele momento foi fazer o downgrade pra versão anterior (3.0.22-1ubuntu3.3) para que tudo voltasse a funcionar.

Consultei hoje e já percebi que saiu uma nova versão (3.0.22-1ubuntu3.5), mas ainda não tive como testar. Segunda eu vejo.

Se alguém já testou, poste seus comentários.

Espero que o pessoal do Ubuntu tenha mais cuidado com essas coisas. Já é a segunda vez em pouco mais de 1 ano que eles lançam pacotes problemáticos.

Boa sorte para nós. :-)

UPDATE (19/11) : Segue a URL do bug.

sexta-feira, 16 de novembro de 2007

Ainda sobre rsync (agora com Ubuntu)

Em um post anterior, falei sobre haverem restrições do uso do rsync no Ubuntu.

Resolvi fazer um post espefíco sobre o assunto, para ajudar quem como eu passou por problemas assim.

As restrições resumem-se basicamente a três fatores principalmente:

1) Filesystems temporários
2) Uso de UUIDs ao invés de devices
3) Interfaces persistentes (vínculo entre mac address da placa e nome da interface)

Normalmente, no caso de uma sincronia de servidores temos 2 maneiras distintas de fazê-lo:

A) Podemos sincronizar o servidor em cima de um HD vazio, mas já particionado.
B) Podemos sincronizar o servidor em cima de um base system previamente instalado.

Maneira A
A maneira A é a mais "complicada" delas pois é preciso ter cuidado com os 3 fatores listados acima. Vamos por partes:

Fator 1:
O fator 1 é o que necessita de maior cuidado pois está ligado a forma de boot do Ubuntu (o fator 2 também tem relação com o boot, mas conseguimos bootar o servidor usando um init=/bin/bash, por exemplo). Para que o Ubuntu possa bootar é necessário que exista no filesystem root ( /) um diretório /var/run e um diretório /var/lock.
Essas pastas são necessárias antes que o /var seja montado (se ele for uma partição separada). Caso esses diretórios não existam o Ubuntu não irá bootar.

Solução: Ao criar a partição / (que normalmente é uma partição à parte, pois o /var normalmente é outra partição), crie os diretórios /var/run e /var/lock para garantir que seu Ubuntu suba.
ATENÇÃO: nunca efetuei diretamente a operação dessa maneira. Estou relatando o que é necessário para o sistema bootar, baseado em pesquisas e comentários encontrados pela rede (normalmente uso a segunda forma de sincronia para garantir o pleno funcionamento - com o base system pré instalado. Demora mais, mas é mais seguro :-) ). Se você optar sincronizar direto no HD vazio criando os diretórios, depois relate sua experiência, por favor.

Fator 2: O Ubuntu, ao invés de trabalhar com devices no /etc/fstab e no /boot/grub/menu.lst, trabalha já há algumas versões com UUIDs (não vou entrar no mérito de vantagens e desvantagens, muito menos dispor sobre o porque da mudança). Se esse formato não for alterado para o formato "antigo" (arquivos de dispositivos - /dev/sda1 ou /dev/hda1, por exemplo), ao tentar bootar o novo servidor, o sistema não irá subir pois não encontrará as partições.

Solução: Após sincronizar todo o servidor, antes de rebootar o mesmo, retorne seus arquivos /etc/fstab e /boot/grub/menu.lst para o formato convencional de device (no fstab, o nome do device está inclusive comentando na linha anterior). Sincronizando dessa forma, seu novo servidor não irá ter problemas no boot. Dica: no root do menu.lst coloque o device onde está o /.

Fator 3: O Ubuntu (7.10) guarda as interfaces de rede e seus respectivos nomes (nada mais do que um vínculo do mac address da placa de rede com o nome "ethX") no arquivo /etc/udev/rules.d/70-persistent-net.rules (O Debian Etch usa o arquivo /etc/udev/rules.d/z25_persistent-net.rules de forma similar). Ao trazer esse arquivo do servidor antigo o servidor novo pode por exemplo então passar a reconhecer a sua eth0 como eth1 (pois a eth0 já vai estar associada ao mac da placa do servidor antigo).

Solução: Apague o arquivo /etc/udev/rules.d/70-persistent-net.rules. Com isso ele será recriado corretamente no próximo boot. Ou ainda, não sincronize o mesmo, colocando-o na lista de exclusão do rsyncd.conf.
ATENÇÃO: do Ubuntu 6.06 ao Ubuntu 7.04 e no Debian Sarge o nome do arquivo é /etc/iftab.


Maneira B
A maneira B é mais simples, pois será necessário lidar somente com os fatores 2 e 3 já explicados acima.

Acredito que com essas dicas, os problemas de usar o rsync com o Ubuntu sejam todos solucionados.

Pelo menos até o lançamento da versão 8.04 ;-)

quarta-feira, 14 de novembro de 2007

Openfire - Nova atualização do Sip Phone Plugin

Após relatar no fórum da Ignite Realtime sobre o problema que estava tendo com esse plugin, o usuário barata7 (Thiago), desenvolvedor do mesmo corrigiu o bug e postou nova versão (1.0.2) solucionando o problema de teste de contas SIP.

Ainda assim continuo com problemas, mas agora ele mudou, pois recebo um timeout quando efetuo os testes.

Já reportei o caso, e vamos ver o que acontece agora. :-)

terça-feira, 13 de novembro de 2007

Openfire - atualizado o plugin Sip Phone

Saiu a versão 1.0.1 do plugin Sip Phone.

Como única novidade, a correção de um bug que gerava incompatibilidade com o PostgreSQL e possivelmente outros DBs também (eles não citam quais).

Apesar da atualização, eu ainda continuo "lutando" com o mesmo para fazê-lo funcionar com o nosso servidor Asterisk.

Assim que resolver o problema irei postar tudo sobre esse plugin aqui.

Sincronizando computadores com rsync

Às vezes é necessário sincronizar dados entre servidores ou até mesmo copiar um servidor inteiro para outro hardware. Uma aplicação fantástica para essas tarefas é o rsync.

O rsync é uma ferramenta open source que permite a transferência de arquivos de forma incremental. Além disso, ela pode também ser usada para sincronia entre micros, partições e diretórios.

Nesse post, vou supor que seja necessário sincronizar um servidor inteiro para outro. Vou também supor que o kernel do Linux não seja compilado especificamente para o hardware, ou se for o caso, que os dois hardwares sejam idênticos. Também estou supondo que o particionamento dos discos seja igual, ou que ao menos existam as mesmas partições vinculadas aos mesmos devices (os tamanhos dos particionamentos podem ser diferentes (assim como os tipos de sistemas de arquivos), mas se obviamente o seu particionamento destino for menor que o origem os dados poderão não caber).

A melhor forma de uso do rsync para esse tipo de tarefa, do meu ponto de vista, é como cliente/servidor.

Configurando o servidor (origem dos dados)
No caso de seu micro origem ser um Debian (ou Ubuntu), será necessário antes de mais nada permitir que o daemon do rsync possa ser iniciado. Para isso deve-se alterar a opção RSYNC_ENABLE de false para true no arquivo /etc/default/rsync.

Depois é preciso configurar o arquivo /etc/rsyncd.conf.

Para ficar bem genérico, pode-se deixar o mesmo da seguinte forma:

[root]
path=/
uid=0
gid=0
read only=true
exclude=/etc/network/interfaces /etc/hostname

Esse configuração lhe dá acesso a todo o sistema de arquivos, com permissão somente de escrita.
Na linha exclude você deverá setar os arquivos e/ou diretórios que não devem ser sincronizados (separe os mesmos por espaço).

Depois disso já é possível iniciar o daemon.

ATENÇÃO: não aconselho manter o daemon ativo dessa forma, por questões óbvias de segurança (que não serão tratadas nesse post). Use o mesmo e desabilite-o logo em seguida.

Sincronizando o cliente (destino)
Supondo que seu servidor de origem tenha 4 partições ( /, /usr, /var e /home ), você pode rodar 4 comandos rsync no cliente para pegar os dados partição a partição (apesar de ser possível sincronizar direto o / teríamos de separar uma série de pastas que não necessariamente precisam ser sincronizadas. Além disso a opção x garante que o somente a partição selecionada seja trazida sem invadir outros pontos de montagem temporários como /var/run, /var/lock, entre outros ):

rsync -avx --delete ip::root/ /
rsync -avx --delete ip::root/usr/ /usr/
rsync -avx --delete ip::root/var/ /var/
rsync -avx --delete ip::root/home/ /home/

Obviamente você pode adicionar outras partições se for o caso (ou remover também).

Explicando os parâmetros
A opção -a aciona o modo arquivo e é o mesmo que a opção -rlptgoD (recursivo, com cópia de symlinks, preservando permissões, preservando data e hora, preservando grupos, preservando proprietários e preservando arquivos especiais e de devices).
A opção v ativa o mode verboso.
A opção x ativa o backup do filesystem principal, sem entrar recursivamente nos demais.
A opção --delete faz com que os arquivos do destino que não existem na origem sejam apagados, para garantir que os dados sejam os mesmos nos dois lados.
O ip será o do seu servidor de origem (onde foi configurado o rsync servidor).
O root (logo após o ::) é o nome do "compartilhamento" que você setou no servidor.
Logo após o parâmetro "root" vem então o que você quer copiar (se for diretório, sempre é necessário finalizar com o /).
E por final, você deve informar o destino pra onde vão os dados (novamente, se for diretório, finalize com /).

Exemplos explicados
Ex: rsync -avx --delete ip::root/etc/ /tmp/
Irá sincronizar todo o conteúdo da pasta etc dentro da pasta tmp.

Ex: rsync -avx --delete ip::root/etc /tmp/
Irá sincronizar a pasta /etc dentro da pasta tmp (ou seja, existirá um /tmp/etc).

Considerações
Esse procedimento já foi testado com sucesso em servidores Debian até a versão 4.0 (Etch). No Ubuntu o mesmo também pode ser utilizado, mas com restrições, principalmente na sincronização do /, pois a forma de trabalho dos tmpfs do Ubuntu pode gerar problemas na hora de bootar o servidor (estamos estudando no momento uma forma de fazer isso com segurança).

Finalizando
Para finalizar acho que é importante lembrar que essa é apenas uma das possibilidades de uso do rsync, e que a ferramenta merece ser mais explorada pois pode ser usada no dia a dia de qualquer usuário, seja ele um administrador de sistema ou um usuário final.

Para mais informações consulte aqui e aqui.

segunda-feira, 12 de novembro de 2007

Intel lança nova linha de processadores.

Via Zumo.

A Intel lançou ontem sua nova linha de processadores chamada Penryn.

Sua principal novidade é o Core 2 de 45 nm, que reduz em 25% o tamanho do chip em relação a um equivalente de 65nm.

Com isso o custo de produção deve ser reduzido e o custo do processador também deve baratear para o usuário final. Não agora no lançamento, é claro, quando o mesmo está sendo vendido a US$ 999 para lotes de mil peças.

A matéria completa você pode ler aqui.

Leia também sobre os chips de 45nm no site da Intel.

sábado, 10 de novembro de 2007

Mais sobre os eventos comunitários do fisl

Mais um ano que chega ao final e lá estamos nós de novo abrindo as inscrições dos eventos comunitários do fisl. Bom sinal !!! :-)

Já é o quarto ano que cuido dos ECs e pela quarta vez consecutiva teremos mudanças neles (afinal precisamos evitar a rotina não é ?).

Só para recapitular, segue um pequeno histórico dos ECs no fisl, para quem não conhece:

No fisl 6.0, os ECs eram chamados de pré-eventos, pois ocorriam um dia antes da abertura oficial do Fórum. Na época 29 ECs foram realizados, a maioria deles em simples salas de aula da PUCRS, e os mesmos foram um sucesso e contaram com grande público. Tivemos tanta demanda que as sessões foram realizadas do turno da manhã até o turno de noite. E valeu qualquer improviso, até mesmo o Randal Schwartz "transformando o laptop dele em um AP (Access Point)" durante um evento do Perl para prover wireless para todo o resto do pessoal da sala. :-)

No fisl 7.0 houve a mudança pra FIERGS. Espaço novo, formato "novo", um dia a mais de evento (oficial), e a "criação" dos eventos comunitários propriamente ditos, agora fazendo parte da grade oficial. Isso deu um aspecto mais "formal" para os ECs que puderam contar com a mesma estrutura das palestras, pois usavam as mesmas salas. Por outro lado, em função dos mesmos agora fazerem parte da grade, o número máximo de sessões por evento foi reduzido para 3. Nessa edição tivemos 30 ECs realizados.

Chegou então o fisl 8.0 que teve a redução de um dia, e que trouxe como mudança para os ECs basicamente a diminuição do número de espaços na grade, algo inevitável. Ainda assim os mesmos foram um sucesso. Claro que devido a redução da duração do evento, tivemos uma queda nos números, o que fez com que somente 25 ECs fossem realizados nesse ano.

E agora ? O que tem de novo ?

No fisl 9.0, como não poderia deixar de ser diferente, novas mudanças nos Eventos Comunitários estão a caminho. Como os ECs já fazem parte da grade do fisl há 3 edições, acreditamos que devemos tomar algumas medidas que visem melhorar os mesmos e ajudem a aumentar o nível do fisl de uma forma geral. Esperamos que essas mudanças também possam ajudar a aumentar a qualidade dos eventos propostos. São elas:
  • As inscrições deverão ser feitas através do papers: com isso poderemos aprimorar a organização, centralizando as informações e otimizando os processos.
  • Os coordenadores dos ECs deverão tentar encaixar seu EC em 1 sessão. Duas sessões só serão concedidas mediante justificativa que será avaliada pela organização: essa certamente é uma medida que deve desagradar muitos, mas que foi necessária para que possamos aumentar a qualidade do fisl.
  • Os eventos que tiverem uma comunidade e/ou grupo de usuários vinculado terão prioridade de aprovação: já que na realidade esse é o objetivo do eventos comunitários, como o próprio nome já diz, essa medida visa garantir os espaços dos ECs para quem é de direito.
  • Não serão aceitos ECs que tenham o objetivo de divulgar projetos e/ou softwares. Nesses casos, o proponente deverá inscrever sua palestra na trilha que for mais apropriada: essa medida também visa garantir os espaços para as comunidades, já que apresentar um projeto ou software não caracteriza necessariamente um EC. Nesses casos, essa palestra deve ser cadastrada nas trilhas e aguardar a avaliação do Temário.
  • Eventos que não sejam vinculados diretamente a software livre serão reprovados: já que o fórum é sobre software livre, decidimos dar espaço nos ECs especificamente para eventos que tenham relação direta com o tema. Outros tipos de palestras (de cunho filosófico, político ou social por exemplo) deverão ser inscritas na trilha respectiva e irão passar pela avaliação do Temário, já que esse não é o objetivo dos ECs.
  • Um coordenador de EC só poderá coordenar um, e somente um, evento comunitário no fisl 9.0: com isso poderemos dar mais espaço para pessoas diferentes poderem ter seu EC no fisl.
Para mais informações, consulte a chamada completa aqui, ou caso você tenha alguma dúvida, ainda é possível mandar um e-mail.

A maioria das mudanças visa garantir mais espaço efetivamente para os grupos e comunidades, já que os ECs foram criados exatamente com esse intuito: dar espaço para que as comunidade e grupos de SL possam se encontrar, debater e além de tudo ajudar a construir o fisl.

Já especificamente na parte dos Papers , pecamos por não ter desenvolvido a tempo um formulário específico para os ECs, obrigando os mesmos a usar o formulário padrão (que não tem todos os campos). Dessa forma, pedimos que os proponentes tentem enquadrar todas as informações da melhor forma possível dentro do formulário disponível.

Espero que as mudanças sejam compreendidas e aceitas, pois a intenção da Organização é sempre fazer o fisl melhor do que o do ano anterior. Certamente não podemos agradar a todos, mas de qualquer forma isso faz parte e quando decidimos mudar já tínhamos consciência disso.

É isso aí. Aguardo as inscrições de vocês e os espero no fisl 9.0, agora de volta à PUCRS pra alegria de muita gente (inclusive a minha).

Até lá.

:-)

sexta-feira, 9 de novembro de 2007

Abertas as inscrições para os Eventos Comunitários do fisl9.0

Estão abertas as inscrições.

Não perca tempo e inscreva seu Evento Comunitário .

Para saber mais sobre como fazer a inscrição e sobre as novas mudanças, acesse aqui.

Aguardo vocês. :-)

Ainda sobre o Asterisk IM 1.4.0

Encontrei no site da Ignite Realtime uma thread falando especificamente sobre o problema que estou tendo com este plugin, e parece que mais gente está passando por situações similares desde o lançamento dessa nova versão.

O mais interessante é que depois instalado, a conexão com o servidor Asterisk resolveu ficar ativa (o que não estava acontecendo), mas ainda não testei para verificar se as funções estão funcionando corretamente.

Vamos aguardar pra ver o resultado disso...

quarta-feira, 7 de novembro de 2007

Propus - apresentação de case no VoIPCenter 2007

Marlon Dutra, um dos diretores da Propus (empresa onde trabalho), apresenta hoje um de nossos cases no VoIPCenter & Asterisk On-Line 2007.

A palestra será "Case de sucesso: Guascor Empreendimentos Energéticos".

Resumo: "A empresa Guascor possui cinco grandes escritórios, onde cada um deles recebeu um servidor VoIP. Cada servidor possui um E1 de voz com a rede pública, e todos eles são interligados por MPLS, com QoS (DiffServ). Todas as chamadas entre filiais são feitas internamente, com ramais de 4 dígitos. Chamadas externas sempre são encaminhadas pela rota de menor custo. O case vai mostrar que além da grande adição de tecnologia, houve uma redução forte nos custos de comunicação, justificando todo o investimento e manutenção da plataforma."

Ainda esse ano, no fisl8.0, ele já havia apresentado um outro case de sucesso nosso.

O programa completo do evento, pode ser visto aqui.

Asterisk IM versão 1.4.0

Juntamente com a versão do Openfire 3.4 saiu a nova versão do plugin Asterisk IM.

Pode-se perceber de imediato que na tela de cadastro do vínculo do JID com o ramal SIP aparece um ComboBox com todos os devices disponíveis (que ele lê diretamente do Asterisk), o que pode evitar erros e garantir um cadastro correto.

Mas para quem prefere digitar, ainda existe um text box para agilizar o processo.

O changelog completo pode ser visto aqui.

Bem interessante !

terça-feira, 6 de novembro de 2007

Openfire 3.4.1 disponível

Saiu a versão 3.4.1 do Openfire, que está disponível aqui.

Ainda não instalei a mesma, mas pude ver que ela tem uma série de novas features e bugs fixes.

Entre todos, acho que o mais interessante deles é o recurso de clustering, que vem somente disponível na versão enterprise.

É instalar pra ver...

UPDATE: Ao instalar a versão 3.4.1, o plugin do Asterisk IM foi atualizado para a versão 1.4 e parou de comunicar com o servidor. Logo, resolvi fazer um downgrade para versão 3.3.3 que está mais estável (ao menos nesse caso...)

UPDATE2 (07/11): Instalei a versão 3.4.1 em outra rede que rodava Asterisk 1.2 e o mesmo funcionou perfeitamente...