Meego “nasce” ainda em março
O pessoal do Zumo também tem alguns comentários interessantes a respeito.
Trecho do iG Tecnologia:
Em meados de fevereiro Intel e Nokia anunciaram a criação do Meego, uma fusão entre o Maemo 5, o sistema operacional baseado em Linux usado pela Nokia em seu smartphone/tablet N900 e o Moblin, uma distribuição Linux otimizada para netbooks originalmente desenvolvida pela Intel. Embora muitos dos detalhes do projeto ainda não estejam definidos, os primeiros resultados já serão visíveis à comunidade de desenvolvedores no final deste mês.
Em um post no blog oficial do projeto, Valtteri Halla, membro do Technical Steering Group (comitê que determina as decisões técnicas), menciona que um dos objetivos é abrir um repositório de código “até o fim deste mês”. Isto não significa o lançamento de uma primeira versão do sistema, mas é um “ponto de partida” para que o desenvolvimento possa de fato ser iniciado.
Algumas tecnologias base para o sistema (Qt, RPM, GStreamer, DBUS) já foram selecionadas, mas muito do restante está em aberto. (via tecnologia.ig.com.br)
@brlinuxblog
Feed RSS
A mudança é grande, o GTK sai e entra o QT, o DEB sai e entra o RPM!
Eu vejo com bons olhos essas mudanças, tanto no empacotamento, pura e simplesmente por que sou mais acostumado com RPM (Mandriva) e o QT faz maravilhas muito lindas aos olhos!
QT = Fruto da Nokia
RPM = Fruto do padrão LSB
Também vejo esta mudança com bons olhos.
E quando ele sair, teremos que aprender Meegoxês?
Vai sair tao rapido assim? Isto é pressa da Nokia para competir com iPhone e Android, tomara que não saia muito cáca nesta versao rapida.
O Maemo (Meego), não é pra concorrer com o iPhone, o concorrente do iPhone OS e Android é o Symbian, o Meego é algo muito maior que esses anteriores.
Maior besteira trocar DEB por RPM!!!
Empacotamento, estrutua DEB é muito superior ao RPM !!!
para mim o projeto começa errado!!!
Os caras estudam, trabalham com isso, e aparece um joao qualquer falando que eles estão fazendo errado, sem nem saber os motivos.
Se eles escolheram RPM, eles devem ter os motivos deles.
Que meeigo!
“Empacotamento, estrutua DEB é muito superior ao RPM !!!”
Acho que você está uns 10 anos atrasado. hehehehe
Não vejo porque não ser rápido a fusão do sistema dos “meeguxos”, já que os dois são baseados em Linux e tem uma estrutura comum.
Mas pra março vai começar o repositório, não significa que ela estará pronta.
Ainda tenho vontade de aprender as diferenças entre RPM e DEB, mas sem nem ter conseguido um documento especificando os dois padrões fica difícil. Se alguém puder me ajudar com o link eu ficaria grato.
E trocar GTK+ por Qt foi uma boa decisão, apesar de que eu sei que Qt não é perfeito, usando inclusive linguagem próxima, mas diferente de C++ (pré-processador moc), é o melhor atualmente (ainda tento aprender a esotérica “linguagem” gobject).
@VinIPSmaker:
http://rpm.org/wiki/Docs
Com relação ao formato do .deb (é basicamente um arquivo .ar (ar xv descompacta) com alguns arquivos de controle dentro).
Já um rpm é um cpio (seja lá o que for isso :-))
Assim como alguns .exe são .cab, tanto que vc pode usar um cabextract neles.
Olha, eu participei das discussões nas listas do Meego e Maemo sobre RPM vs DEB (duraram semanas) e passei a compreender melhor por que a escolha do RPM (embora ainda preferisse que fosse DEB). É mais do que o framework de instalação, é todo o sistema de construção de pacotes, dependências e distribuição, e o que será usado, o OpenSuse Build System (OBS), embora construa tanto rpms quanto debs, tem ferramentas que só servem para RPM.
Tinha um endereço que eu li que explicava isso bem… Mas não achei.
E o Meego vs. o Android, como fica?
Android é legal, mas o Google não tem mostrado muito entusiasmo em se conformar ao software livre, foram expulsos do kernel no 2.6.33 por não sincronizar suas modificações e também permitem celulares com um Android travado com as partições criptograficamente assinadas (como os da Motorola) — o que a meu ver elimina muitas das vantagens de usar um sistema operacional de código aberto.
Outra desvantagem é o Android não ser baseado nas coisas que temos em um desktop GNU/Linux – X, QT, GTK+… Você perde logo de começo praticamente todas as aplicações que seriam úteis no celular.
Além disso, o fato de o kernel ser bastante modificado (cada aplicação que é aberta assume um uid novo, por exemplo) torna mesmo algumas aplicações texto difíceis de funcionar.
Outra coisa que eu vejo com reservas é o Dalvik, sua máquina virtual Java, não por não gostar de Java, mas por ela não se mostrar muito eficiente e também por ser um pouco fora da especificação da Sun. Além disso, me parece intrinsecamente errado aplicações pro celular terem que ser programadas especificamente nessa linguagem…
Em todos esses pontos o Meego ganha de longe (e o N900 já tratava). Pra trazer, digamos, abiword pro Meego ou mesmo pro Maemo 5 (N900), basta recompilar pra ARM com pouquíssimas modificações e no Meego, com o OBS, isso provavelmente será ainda mais fácil. Tenho abiword, gnumeric, keepassx, mplayer, kchmviewer, fbreader, gvim, evince compilados e rodando no meu N900 sem problemas.
No Maemo, pra bloquear ligações, você se liga a uma notificação dbus e faz uma chamada dbus para cancelar quando o número confere com uma lista. Se você quiser ver o status da bateria, você usa hal-device ebm. Para ver os sinais do acelerômetro, você pode usar o dbus ou ler pelo /proc. Para remapear as teclas você usa o setxkbmap. É seguramente o Linux familiar que conhecemos em toda parte, com todas as partes de sua infra-estrutura. Até o sistema de inicialização do N900 é o agora familiar upstart do Ubuntu (só o diretório é diferente – /etc/event.d ao invés de /etc/init). Para audio se usa o pulseaudio. Muito provavelmente o Meego vai seguir todas essas receitas.
Muita discussão ainda rola nas listas do Meego. Seria bom ter mais brasileiros por lá… :)
Alguém podia agora dizer onde encontro as especificações do formato DEB?
Eu quero ter uma opinião.
>>> Empacotamento, estrutua DEB é muito superior ao RPM !!!
Até o dia que seu database DEB der pau, e vc vai SUAR pra dar um rebuild onde com o RPM vc consegue refazer a database sem maiores complicações(2 comandos na verdade)
;)
E outra, o padrão LSB é RPM com o APT-TOOLS.
RPM faz parte da padronização LSB. Além disso, muita gente confunde deb com apt e aí acha que o deb é superior por causa do apt.
Os problemas com dependências no rpm já não existem há séculos porque todas as distribuições que usam rpm já criaram ferramentas similares ao apt e aptitude, como o yum, urpmi, smart, etc.
Outra idéia falsa é que um pacote deb só por ser deb pode ser instalado em QUALQUER distribuição que use deb e o rpm não e acreditam que isso é uma prova de suposta superioridade do deb. Na verdade, o deb é unicamente usado no debian e seus derivados. Como por muito tempo as distribuições derivadas do debian eram basicamente remasterizações que usavam repositórios testing ou unstable do debian, a chance de um pacote deb funcionar era maior do que, p.ex,, um rpm do opensuse funcionar no fedora ou no mandriva, que são distribuições também derivadas, mas que fizeram o fork há muitos anos e que mantêm repositórios de pacotes isolados e bem diferentes.
Uma comparação do formato deb com o rpm está aqui
http://debian-br.sourceforge.net/txt/alien.html
Não sei se está atualizada.
metadata accessible by standard tools – Rpm – NO >.<
rpm -qial nome_do_pacote
..desatualizada e imparcial
Acredito que a escolha do padrão RPM foi puramente comercial!!!
Sugiro a todos que efetuem uma comparação e depois tirem suas próprias conclusões!!!
Mas POR FAVOR DEIXEM DE LADO o fanboy RPM !!!
Ironmaniaco,
O fato da comparação estar no site do debian-br e pelo jeto ter sido feita pelo pessoal do programa alien, não pode ser considerada imparcial.
Mas rpm é sim a escolha de muitas distribuições comerciais e por isso mesmo faz parte do LSB. Não vejo nada de mal nisso. Na realidade, acho que a escolha do rpm ou do deb hoje em dia é muito mais questão de estratégia do que técnica. Ninguém me mostrou nenhuma capacidade realmente importante e vital que o deb tem que o rpm não tenha e vice-versa.
Vejam
http://en.wikipedia.org/wiki/RPM_Package_Manager
“RPM also has a few advantages over some other package managers:
* It is the GNU/Linux (LSB) standard format.
* It is popular: the typical rpm repository (the place where the packages are made available publicly) contains thousands of free applications.
* RPM packages can be cryptographically verified with GPG and MD5
* Original source archive(s) (e.g. .tar.gz, .tar.bz2) are included in SRPMs, making verification easier (for security-critical packages like OpenSSH it is possible to check with md5sum that the sources were not modified).
* PatchRPMs and DeltaRPMs, the RPM equivalent of a patch file, can incrementally update RPM-installed software without needing the original package.
RPM has been criticized for a lack of consistency in package names and content which can make automatic dependency handling difficult. However, this is not a problem inherent in the RPM format, but rather because of differing packaging guidelines among major Linux distributions that use RPM in packaging such as Fedora, openSUSE, and Mandriva Linux. When using packages that are from a particular distribution (say Red Hat Linux) or built for a particular distribution (for example Freshrpms for Fedora),[2] tools such as yum, urpmi or zypper can perform automatic dependency checking.
Circular dependencies between mutually dependent RPMs cannot be installed with rpm unless the user is aware that he needs to specify both on the rpm installer’s parameter list first. This leads to what is known as ‘dependency hell’, particularly for packages with many dependencies, each of which has its own large set of dependencies, and so on. For this reason, wrappers around the rpm tool have been created to help ameliorate the problem. High level tools like yum, urpmi and zypper are examples of such wrappers. These are similar to wrappers like apt-get and smart in Debian.”
Ou seja, o fato de um rpm de uma distribuição não funcionar na outra não tem nada a ver com o fato de ser rpm, mas ao fato de serem distribuições bem diferentes entre si. Mudar para deb não resolveria esse problema.
E o fato de ter que resolver dependências manualmente na instalação manual de rpms é besteira porque para isso existem as ferramentas como yum, urpmi e zypper, assim como existem o apt, smart, aptitude no debian e derivadas.