Solução simples.: Empresas ricas como IBM, HP, Red Hat ou Novell deveriam alugar ***um*** comodo em algum lugar do mundo.
Empregar umas 10 pessoas pra usar o Linux por algum tempo.
Depois desse período perguntar a elas o que acharam fácil e o que acharam difícil de usar no Linux.
Respeitar as opiniões... inclusive quando reclamarem que não entendem a necessidade de digitar linhas de comando para fazer coisas que uma ou duas clicadas de mouse fariam do mesmo jeito.
O desktop estará prontinho pras massas!!!

OSDL-Linux: A OSDL não trabalha com outros kernels livres?
Estilo Micro-Kernel e os magníficos EXOKERNELS? (mais pro final desse slide-show mostra que um exokernel em estado alpha, escrito em C, apenas um rascunho de um exokernel, detona o OpenBSD e o FreeBSD juntos no desempenho!!! Magnífico!!!)

PS: Exokernel sem libOS não é quase nada... Mas eu acredito nos futuros Exokernels, acredito que essa é a única esperança destronar Torvalds e o monopólio do Linux no Software Livre!

Temos que acabar com o monopólio da Microsoft no mercado mas não podemos permitir que o Kernel Linux tome o monopólio no Software Livre!
___________________________________
/"\
\ / Campanha da Fita ASCII - CONTRA HTML E-Mail, vCards e formatos proprietários.
X
/ \

-={([FREE PATENTS])}=-

OSDL tem foco no Linux: A missão do OSDL está expressa aqui. Começa assim: "OSDL Mission: To be the recognized center of gravity for Linux; the central body dedicated to accelerating the use of Linux for enterprise computing"

Sei, sei, o Linux quer o monopólio do SL: Ok, OSDL quer que o Linux tome o monopólio do Software Livre...

- "Solaris Open Source for x86 is a joke";
- "GNU/HURD Microkernel is dead";

O finlandês arrogante, orgulhoso e metido não vai gostar quando falarem que Linux é coisa do passado, que o projeto está morto ou simplesmente o Linux virou piada!

GNU/HURD não está morto, apenas AINDA NÃO CHEGOU A HORA dos micro-kernels!

Eu estou aqui pelo Software Livre, não pelo linux...
A moda agora é linux, lógico! A moda agora é "Acabar com a Micro$oft, custe o que custar! E deve ser com o Linux!!!

Os Micro-Kernels e os Exo-kernels vão evoluir sim! Não vai ser o finlandês arrogante que vai impedí-los! Pro cara falar que o Hurd está "morto", só pode estar com muito medo de perder o monopólio!

Open Source Development Lab (OSDL): Pelo nome deveria apoiar qualquer kernel Open Source, porém o primeiro ítem do FAQ é:

"What is OSDL?

The Open Source Development Lab (OSDL) is a non-profit resource lab for open source developers that provides equipment and infrastructure to large-scale Linux enabling technology projects to support enterprise and telecom applications."

Portanto uma organização dedicada especificamente a evolução do Linux, porém como o futuro a Deus pertence, não temos como saber como será o mundo quando o modelo de software proprietário for considerado tópico de história da computação da disciplina informática básica nos cursos universitáios.

PS: Nem quando e se isso realmente vai acontecer.

André Simões -- alsimoes arroba gmail com

"Nem toda propriedade é um roubo. Porém, a propriedade é um roubo quando exclui os não-proprietários do processo de desenvovimento social." -- Manuel Castells

"O melhor do Brasil é o brasileiro"

A iniciativa Linux /home...: Respeitar as opiniões... inclusive quando reclamarem que não entendem a necessidade de digitar linhas de comando para fazer coisas que uma ou duas clicadas de mouse fariam do mesmo jeito. -- Estou de pleno acordo! Tanto que estou reformulando meu trabalho para aproximá-lo mais destes conceitos. &;-D

O desktop estará prontinho pras massas!!! -- "prontinho" acredito não ser o termo certo. Mas posso dizer seguramente que está "quase pronto" (só falta alguns pequenos ajustes)! &;-D

Companheiros,

Antes de iniciar meus estudos (curso atualmente o 5o. Periodo de S. Info.), também um usuário de PC doméstico e SEI muito bem as dificuldades que passei - e que vi outros companheiros passarem - e, no que depender de mim, estarei sempre disponível para ajudar. O que falta no desktop? É recursos, facilidades e amigabilidade? O KDE/Gnome dão um espetáculo à parte em cada novo release. Aplicações? Ah, são tantas! Suporte à periféricos? Salvo casos especiais, vamos muito bem! Jogos? Talvez... mas chegaremos lá.

Na minha opinião o que falta para o Tux/SL chegar aos Desktop não é maturidade, e sim esforços de nós - a comunidade - para facilitar aos iniciados nesta empreitada. Acreditem: muitos têm curiosidade em conhecer o sistema, mas devido à mitos, lendas e outros elementos (poderia, mas não vou citá-los aqui para evitar extender desnecessáriamente e nem criar atritos), eles ficam desestimulados. E o que pude fazer para auxiliar foi criar uma forte literatura e um site com objetivos pré-definidos. O livro - intitulado "Guia do Linux Doméstico" - já está num bom patamar de desenvolvimento (em breve liberarei a 2a. edição), mas o site (sei que é pobrezinho) ainda nem é a sobram do que desejaria que fosse. Mas pelo menos dei o pontapé inicial (visitem o site), e espero que minhas idéias inspirem os demais companheiros da comunidade. Felizmente tenho recebido ajuda - poucas, mas preponderantes. Como diz o velho ditado, "uma andorinha só não faz verão"...

Enfim, se alguém desejar criar um projeto ou trabalho deste nível, estou à disposição para ajudar, se isto estiver ao meu alcance.

Att., Ednei Pacheco,
http://www.linuxhome.eti.br/

O futuro a gente faz no presente: "o futuro a Deus pertence"

O futuro a gente faz no presente.
(...)

Vontade não basta: Ednei,

Se vontade bastasse... mas falta muuito pro Linux Desktop ainda. Só a questão da instalação no linux, já faz com que usuários domésticos e empresas arranquem os cabelos. (Instalação de softwares de terceiros e não que vem com a distro)

Eu tive vários exemplos. Instalei Linux pra alguns amigos ou dei a dica pra eles instalarem. Qdo querem um software, indico o site e muitas vezes não há pacotes pra distro deles. Sinto muito, eles preferem voltar pro Windows a ter de aprender a compilar. Certo eles. Eles são usuários, e precisam do computador pra outros fins. Nâo querem perder tempo com isso. Olhe o usuário como um consumidor (estamos vendendo a idéia pra eles...). Eles compram o que é fácil e funciona. O Linux funciona, só precisa ser fácil.

Quando o Linux estiver fácil, ele se vende sozinho, e muita gente vai usar e não vai largar. Ser fácil e muito diferente de ser ruim. Imagine um usuário de empresa ou doméstico sem problemas com vírus, com um sistema estável que contenha as app q ele precisa e ainda fácil de manter/instalar? É o pulo do gato. Eu fico berrando aqui a vários anos dizendo que quando o Linux estiver mais padronizado, ninguém segura.

Essas empresas grandes abraçando a idéia, junto do OSDL ou quem mais quer que seja, vai dar caminho pras esaas coisas q estão faltando. Já era tempo de alguém cuidar disso como cuida da parte servidor.

Ainda sobre instalação, pra empresas construtoras de software, manter N instaladores é realmente um parto. Minha empresa se inclui nesse exemplo. Qdo conseguir passar meus app em Delphi pra Mono, pode ter certeza que vou preferir um instalador universal.

Dá uma lida no PDF q vc vai encontrar muita coisa interesante e muito bem justificada que precisa ser melhorada.

Abraço.

Suporte a periféricos: genérico demais, específico de menos: Suporte à periféricos? Salvo casos especiais, vamos muito bem!

Hum, eu discordo. Na minha experiência e na experiência que vejo com amigos, o suporte a periféricos é um dos maiores empecilhos para o GNU/Linux doméstico. Tanto no quesito winmodems (que são ainda muito difíceis de pôr pra funcionar) quanto no suporte incompleto que os drivers apresentam: de que adianta a webcam funcionar pelo sistema PTP se não consegue funcionar no modo "filme" com a resolução máxima? De que adianta o lindo mouse wireless óptico de 12 botões funcionar só com 3 botões e a rodinha - e ainda por cima não mostrar o nível de bateria como no Windows? De que adianta aquela placa de som funcionar legalzinha no modo OSS estéreo - mas não funcionar bem no seu sistema Dolby 5.1 para tocar os filmes com som tridimensional? E às vezes até é possível fazer o mouse funcionar com os 12 botões ou a placa de som funcionar com som 5.1 - mas é preciso achar HOWTOs pelo google, ler inglês, ter uma certa canseira. Pode ser no final gratificante para um usuário fuçador, mas é um estorvo e tanto para um usuário doméstico comum.

Não estou querendo só reclamar, já até tentei fazer um pouco minha parte - NFSwap - mas o problema é que a metodologia open-source de "coçar o comichão" se preocupa muito em fazer funcionar, mas depois que já funciona meia-boca, o comichão atrai poucos coçadores. Resultado: as funcionalidades estendidas são muito menos implementadas que no Windows e normalmente não são integradas no sistema nem configuradas pelas ferramentas da distribuição.

Precisamos de mais desenvolvedores com idéias empolgantes para fazer sua nforce2 ou mouse de 12 botões ou qualquer coisa assim funcionar totalmente no sistema. E ser configurada automaticamente. Um dos passos pra isso - mas não o único - é conseguir mais apoio dos fabricantes de hardware, exigindo drivers GPL e aplicativos configuradores/monitoradores para os hardwares.

--
Ainda em estágio altamente experimental e pré-alpha: http://linuxfud.ath.cx
LinuxFUD, mostrando as mentiras da mídia contra o software livre!

Agree: Só pra constar... concordo PLENAMENTE com o Patola. Boa nova? Isso tá coberto no proposto pela OSDL.

Palavrinhas mágicas: "padronização" não cola.: Eu fico berrando aqui a vários anos dizendo que quando o Linux estiver mais padronizado, ninguém segura.

Eu não concordo com isso, Paulo. A tal da "padronização". O que você quer dizer com padronização? As distribuições já são bem padronizadas. O meu gnome 2.8 funciona igualzinho no Debian e no Conectiva. Nesse sentido, é padronizado. O KDE no entanto é diferente do Gnome. Tudo bem, iniciativas como o freedesktop.org "padronizam" coisas como o desktop tray e o cut-and-paste entre as aplicações, mas... não adianta: são desktops diferentes, com metas e filosofias diferentes. Não vão ficar iguais - nem muito parecidos. Não serão uniformizados, não adianta: a metodologia de código aberto é CONTRA isso. Uniformize o filesystem pelo Linux Standard Base e surgirá um Gobolinux, com um filesystem radicalmente diferente. Uniformize o desktop e surgirão mil desktops diferentes. Uniformize os menus e alguém surgirá com uma disposição diferente e inovadora. Sabe por quê? Porque padronização é antônimo de duas características do código aberto: inovação e escolha. Essas duas características sempre existirão porque não existe autoridade central em se tratando de software livre.

Portanto, acostume-se: a padronização da qual você parece falar nunca existirá. O que não quer dizer que um governo ou uma empresa não possa padronizar o seu desktop em, digamos, Gnome (ou KDE ou qualquer outra coisa) -- pode e DEVE, essas instituições precisam disso. O usuário doméstico em geral não, prefere dar "personalidade" ao seu micro (embora não perca tanto tempo nisso quanto o nerd inveterado).

Precisamos pôr a coisa em perspectiva. Eu já disse uma vez e repito sempre: o caminho para o sucesso não é o GNU/Linux fazer tudo igualzinho ao Windows. É fazer as coisas do seu jeito, mas, claro, aproveitando as idéias boas que já foram implementadas, na medida do possível. E a padronização, mesmo que seja considerada uma idéia boa, NÃO é possível.
--
Ainda em estágio altamente experimental e pré-alpha: http://linuxfud.ath.cx
LinuxFUD, mostrando as mentiras da mídia contra o software livre!

Sabemos muito bem de quem é: Sabemos muito bem de quem é a culpa dos periféricos não funcionarem com todas as maravilhas no Linux, placas de som, aceleradoras 3D, modems, captura, webcams, etc. Se as empresas disponibilizarem as especificações de software que dão acesso a todas as suas funcionalidades, aí sim, teremos a tão esperada e sonhada compatibilidade total, e isso só acontecerá se as fabricantes de hardware parem de querer vender Windows.

Sabem quando isso vai acontecer?

Eu também não :P

_____________________________
Carlos Wagner - São Luís / MA

Aberto e inovador, mas padronizado: O Linux, como qquer sistema é padronizado, e em mais coisas que possamos imaginar. O fstab, é um padrão, assim como várias características que fazem alguém dizer q um sistema é um Linux, ou um BSD e assim por diante.

Gostaria que mais coisas fossem incluídas nesse padrão, no coração do Linux. Isso não quer dizer que exista a necessidade de segui-lo. Quem quiser, que mude, que faça melhor. Na verdade, talvez a palavra certa não seja padrão, pois parece algo restritivo, e sim "convenção", como forma de boa prática.

Algumas coisas que gostaria de ver incluídas no Linux:

- MIME types independentes, definidos pelo sistema e não pelo window manager usado
- Um padrão de instalação, upgrade e desinstalação para softwares de terceiros não mantidos pela distribuição. A empresa faz um instalador, e ele roda em qquer distro. E isso não impede q a distro tenha a SUA forma secundária de instalar um software melhor. Mas o básico tá lá. Instalador gráfico ou console pra usuário leigo, com Next, Next, Finish. Fez isso, tá no menu, nos dirs certos e sem dificuldades.
- Integração entre Widgets. Mais coisas deveriam ser definidas a nível do X, ou seja lá qual for o servidor gráfico "padrão" do Linux (Não impede que tenha outro). Caixas de diálogo, seletores de fontes, salvar e ler arquivos, selecionar e configurar impressoras e devices. Tudo isso respeitando o tema usado pelo usuário, mas com uma cara igual.
- Servidor gráfico integrado no kernel qdo distro desktop.
- Suporte a Thin-client applications melhorado no servidor X. Hj se consegue executar um software numa máquina e mandar a saída pra outro servidor X, mas a configuração disso é um saco. Trocando: Ter um tipo de citrix metaframe embutido no Linux.
- Reconhecimento de hardware, USB hotplug, etc, melhorados no kernel pra atender aos periféricos usados por usuários domésticos e corporativos.
- Melhorar (e muito) o boot time qdo foco for desktop.
- Permitir instalações de softwares, plugins, certificados a nível do usuário, sem requisitar senha de root, e que valem apenas para aquele usuário. Firefox/Thunderbird já fazem isso. Uns amigos instalaram assim, pq nem sabem o que é "root".
- Definição de um protocolo de comunicação entre aplicações, local ou remotamente. Algo baseado em CORBA, ou talvez o tal DBUS do freedesktop. Não estamos falando de QT, GTK, e sim de um esquema Linux de comunicar applicação.
- Permitir que configurações do desktop residam em servidor, ou mesmo que local, possam ser administradas e geridas através de ROLES.
- Criação de imagens de instalação a partir de configuração definida por perfil de usuário.
- Permissão de alteração de características do desktop de acordo com ROLE de usuário. É a tentativa do Kiosk KDE, mas a proposta é que seja independente do manager usado.
- etc, etc, etc

Esse "padrão" que estou te falando, faz com que os fabricantes de hardware possam fazer drivers pra LINUX e não pra distro X ou Y.

Essas melhorias na API do servidor gráfico, que devem estar integradas ao kernel (qdo desktop), fazem com que o desenvolvimento de app use uma API básica para as operações gráficas do desktop, e não chamadas diretas à QT ou GTK, etc. Se desta chamada pra frente, vai direcionar pra QT, GTK, outra história, mas o "Core" do desenvolvimento pra GUI em Linux esta definido, em forma de chamadas abstratas a classes/funções pré-definidas.

Essa camada básica, com características básicas (q já existem hj pra servidor), é como criar classes em OOP: As básicas definem a característica mínima, e dali pra frente, cada um viaja como quiser.

Java não é fechado por definir suas características e classes básicas, nem muito menos impede que se façam classes do zero. Mesmo pro Linux: Quer usar o padrão desktop definido pela OSDL, XYZ, LSB? Vc vai seguir essas convenções, vai usar essas APIs, etc, etc, mas se não quiser, use o seu e ganhe o mercado e os usuários com o seu argumento. Garanto q vc vai demorar mais pra prograra tudo... hehe...

Pra hambientes coporativos, se não houver essa padronização, não vai haver força pra redesenvolver solução pra múltiplas distros. O cara quer continuar podendo mudar de forncedor ou focar outra distro linux, sem ter que treinar usuários novamente.

Bom, já me extendi demais... acho q deu pra captar a idéia... (espero)

> - MIME types independentes,: > - MIME types independentes, definidos pelo sistema e não pelo window manager usado

Não pode ser o '/etc/mailcap' (global) ou '~/.mailcap' (local)? O mailcap define a ação (programa a ser executado) para um determinado tipo MIME (/etc/mime.types).

> Um padrão de instalação, upgrade e desinstalação para softwares de terceiros não mantidos pela distribuição.

Talvez o Smart Package Manager possa vir a ser uma realidade e unificar os diversos formatos de pacotes. Em tempo, qualquer software compilado estaticamente pode rodar facilmente em diversas distribuições GNU/Linux, contudo, perde-se em espaço e tempo ao não compartilhar bibliotecas.

> Essas melhorias na API do servidor gráfico, que devem estar integradas ao kernel (qdo desktop), fazem com que o desenvolvimento de app use uma API básica para as operações gráficas do desktop, e não chamadas diretas à QT ou GTK, etc.

É preciso tomar com muita cautela esta integração do servidor gráfico com o núcleo do sistema, para não se perder modularidade e levantar problemas outros (inchaço, estabilidade, segurança, etc.). Lembre-se que existem diversas utilizações do GNU/Linux que não visam a interface gráfica, como clusters, algumas espécies de servidores, etc.

Atualmente existe uma API básica, a API da Xlib. Sendo básica, executa operações triviais, como "desenhar uma linha" ou "desenhar um retângulo". Os toolkits vêm com o propósito de criar camadas que oferecem os componentes gráficos, widgets e etc., comumente sobre a Xlib. Outros, como o Cairo, Glitz, etc., fornecem uma camada intermediária no intuito de fornecer descrições vetoriais, em vez das chamadas "cruas" da Xlib.

--
FLTK fltk.org (Fast Light C++ GUI Toolkit)

Será mesmo?: Uma empresa investe milhões para criar um novo produto, tem que licenciar tecnologias de terceiros, etc. Se liberar as especificações, corre o risco de ter um concorrente com um produto semelhante, sem ter investido na pesquisa inicial, e ainda ganhar seu mercado. E mesmo que as especificações fossem todas abertas, que garantia há de que os periféricos funcionariam tão bem quanto no sistema proprietário?
O maior empecilho ao suporte a hardware é a falta de compatibilidade binária no linux. Não adianta reclamar, fabricantes não gostam de disponibiliar informações e preferem o "método tradicional".
Compatibilidade binária é extremamente importante em um ambiente desktop/corporativo. Nessa área, softwares proprietários levam larga vantangem. O único sistema operacional aberto que levará essa vantagem é o OpenSolaris e, se a SUN fizer as coisas direito, poderá ser o primeiro SO livre a ganhar a preferência do usuário e de fabricantes de hardware. Além disso, produzir software para um sistema que não muda toda hora é bem mais fácil e barato.

Já existem muitas alternativ: Já existem muitas alternativas pra muitas coisas, inclusive no doc do OSDL eles sugerem a utulização de pacotes já existentes como proposta padrão a ser melhorada.
...
A idéia do smart é boa, mas não vejo o smart como sendo a camada de apresentação pro usuário e sim de resolução de dependências. O que o usuário deve ver é uma tela que o guie na instalação, logo após ter baixado o sw de algum site, executando do disco, instalado remoto etc. O Smart, resolveria as dependências sem que o usuário soubesse q o smart existe. A interface gráfica ou console seria padronizada.
...
Se têm uma coisa que a galera do Unix sabe fazer é modular as coisas. Não acho q a inclusão de um módulo gráfico e outros ligados à desktop possam prejudicar. Como outros módulos do kernel, é ligar/desligar.
...
Realmente existem muitos APIs/Toolkkits pra parte gráfica, mas não existe um "Core" default pra Desktop além do X outras libs a escolha do freguês. A definição de uma API gráfica alto nível para o Linux facilitaria muito o desenvolvimento de aplicações. As API e toolkits poderiam ficar por trás, fazendo o trabalho sujo... hehe.

O exemplo do filesystem é bom pra comparar: Podemos usar vários filesystems em Linux, mas as demais aplicações, APIs não se preocupam com o file system específico e sim em chamar funções/metodos padronizados de tratamento de arquivos. O mesmo deveria acontecer pra GUI. O que existe hj no X é muito baixo nível ainda. E o QT, GTK e demais, pulam uma etapa, e as vezes chamam o X e as vezes definem seu próprio padrão, por não existir no X. MIME é um exemplo disso.

Na minha opinião as partes q mais precisam de trabalho são a instalação simplificada de softwares e suporte a hardware.

Mais uma vez: leiam o PDF. Difícil não concordar com a proposta deles.

Compatibilidade binária X drivers de código fechado: Embora a compatibilidade binária seja em si algo positivo e importante, não compartilho da opinião de que o desenvolvimento do kernel (ou do sistema gráfico, ou de qualquer componente livre) deva ser movido por um interesse em facilitar a integração de componentes de código fechado.

Não acho que alguém deva tentar intencionalmente bloquear este tipo de de acesso ou que ele seja errado em princípio, mas também não acho que facilitar a vida de desenvolvedores de software proprietário que buscam integração sem abrir código deva estar muito no alto da lista de prioridades dos desenvolvedores livres - por mais que estes desenvolvedores proprietários justifiquem sua alegada impossibilidade de abrir seu código por razões de mercado.

O exemplo mencionado (hardware que não faz o que queremos por uma restrição do software, que não podemos resolver porque o fabricante tem interesse em manter secreto o software ou a especificação) é bastante próximo do fato que motivou Richard Stallman a iniciar o projeto GNU e a Free Software Foundation - mas no caso dele o problema era com o software de uma impressora, e não com um winmodem.

É lamentável que os fabricantes continuem com esta política de tratar o funcionamento de seus produtos como um segredo industrial, mesmo que prejudique potenciais usuários, e creio que ainda estejamos longe de uma solução definitiva para isto.

Mas não acho que a integração de drivers fechados ao kernel seja algo positivo, e nem que seja a melhor solução técnica - ainda que possa ser a única ao alcance dos desenvolvedores de software livre. De minha parte, não compro produtos com estas características, e fico feliz a cada vez que algum fabricante resolve o problema. E aguardo o momento em que o mercado de usuários de software livre seja grande o suficiente para motivar os demais fabricantes, sem que o software tenha que tornar-se menos livre para isso.

Tirou as palavras da minha bo: Tirou as palavras da minha boca... &;-D

Bem, o sistema está evoluindo constantemente. O que o KDE/Gnome fazem hoje, mal imaginávamos à 4 anos atrás... Lembram-se da questão da falta de aplicatios +/- neste período. Acredito que acontecerá o mesmo com o sistema nos próximos tempos sobre estas questões.

Enfim, as limitações do Tux existem, mas isso não nos impede de nos mover já para auxiliar na disseminação.

Att., Ednei Pacheco.

> A idéia do smart é boa, m: > A idéia do smart é boa, mas não vejo o smart como sendo a camada de apresentação pro usuário e sim de resolução de dependências.

Resolver dependências é fundamental para uma boa utilização de pacotes de terceiros, do contrário terão que fugir para a ligação estática, que pode ser vantajoso para pequenos projetos, mas geralmente não o é para projetos maiores.

Com o Smartpm (ou soluções afins) implementado, bastaria o desenvolvedor de software empacotar em apenas um formato que, teoricamente, outras distribuições utilizando formatos distintos poderiam usufruir transparentemente do conteúdo do pacote, como se fosse nativo.

A questão do "Next, next e finish" depende apenas da criação de interfaces gráficas/frontends à la Synaptic --apesar de achar mais direto um único 'apt-get install pacote'.

> Se têm uma coisa que a galera do Unix sabe fazer é modular as coisas. Não acho q a inclusão de um módulo gráfico e outros ligados à desktop possam prejudicar. Como outros módulos do kernel, é ligar/desligar.

A inclusão de módulos desse porte no núcleo certamente traria um grande impacto, de imediato uns 40MB (.bz2) a mais de código-fonte. o_O --tirando por base o tamanho do fonte do X.Org 6.8.2. Isto talvez seja o de "menos", é preciso lembrar que é interessante a convivência de projetos alternativos ao X(.org), como o WeirdX ou Y Windows. Sou daqueles que defende a diversidade como componente fundamental da evolução. Eu ficaria muito triste se um dia "resolvessem" que o GNOME (ou KDE) fosse o desktop padrão do GNU/Linux.

> Na minha opinião as partes q mais precisam de trabalho são a instalação simplificada de softwares e suporte a hardware

O suporte a hardware depende mais dos fabricantes do que propriamente dito da comunidade. Não digo nem na implementação do driver em si, mas apenas o fornecimento das especificações. Hoje o MS Windows tem a fama de ser hardware-friendly simplesmente porque é popular e os fabricantes visam este mercado, dando-se ao trabalho de desenvolver o driver.

Por outro lado, em uma visão mais atenta, o suporte ao hardware no Linux (e sistemas livres) é *melhor* do que o do MS Windows. No Linux você tem a "garantia" de que um hardware antigo, "obsoleto", se não é suportado pela versão corrente do kernel, poderá ser facilmente portado, fazendo algumas modificações no código-fonte de uma versão anterior do driver. E no MS Windows XP, o que aconteceu com aqueles hardwares projetados para o MS Windows 9x cujas companhias por algum motivo não dão mais suporte ao driver? O que acontecerá no lançamento do MS Longhorn?

Posso dizer que a curto prazo os drivers fornecidos ao MS Windows (assumindo como binários) são bons, contudo, perecem. A médio e longo prazo, os drivers abertos (geralmente desenvolvidos pela comunidade e em sistemas livres), viram o jogo.

--
FLTK fltk.org (Fast Light C++ GUI Toolkit)

Linux no Desktop: Grande Paulo, vamos lá...

Só a questão da instalação no linux, já faz com que usuários domésticos e empresas arranquem os cabelos. (Instalação de softwares de terceiros e não que vem com a distro) -- Bem, aí a causa do problema não é o sistema operacional, e sim dos desenvolvedores dos aplicativos. Mas não deixo de concordar.

Qdo querem um software, indico o site e muitas vezes não há pacotes pra distro deles. Sinto muito, eles preferem voltar pro Windows a ter de aprender a compilar. Certo eles. Eles são usuários, e precisam do computador pra outros fins. Nâo querem perder tempo com isso. -- Eles querem encontrar pacotes prontos para serem instalados? Por que não utilizam o Debian ou alguma outra distro com grande repositório? Será que não irão encontrar seus programinhas preferidos em 15.000? Além do mais, se eles não querem aprender à compilar, "I'm sorry"... então que aprendam à se proteger de vírus e spywares, craquear e etc! &;-D

Olhe o usuário como um consumidor (estamos vendendo a idéia pra eles...). Eles compram o que é fácil e funciona. O Linux funciona, só precisa ser fácil. -- Já discuti sobre isto com muita gente. Uma coisa é ser fácil; outra coisa é ser mastigado. Se eles preferem algo "mastigado", porque não uma distribuição que prima por oferecer automatização de processos? Soube uma vez que uma pessoa conhecida da comunidade foi realizar a instalação de um SuSe e ela disse que só faltou a distro adivinhar sua música preferida e tocar automaticamente... No Debian, o apt-get instala tudo! Quer mais fácil que isso? &;-D

Eu fico berrando aqui a vários anos dizendo que quando o Linux estiver mais padronizado, ninguém segura. -- Concordo com o Patola sobre a questão da padronização. Ela é praticamente impossível, pois vai de contra a flexibilidade que rege sistema. Em contrapartida, porquê não estudamos melhores técnicas e procedimentos para ensinarmos a administrar o sistema, e assim atenuar as diferenças entre as distros? Estou esforçando-me para fazer isso em meus trabalhos - chamo isso de "Cultura Linux Moderna". Confesso que os resultados não estão sendo lá aquelas maravilhas, mas estou tirando um bom aprendizado. &;-D

Essas empresas grandes abraçando a idéia, junto do OSDL ou quem mais quer que seja, vai dar caminho pras esaas coisas q estão faltando. -- Pra ser sincero, acho que estamos tendo muita coisa boa. Empresas de grande porte apoiando (Red Hat, Novell, IBM, Sun, Linspire, etc. - até o Governo!), ambientes gráficos poderosos (KDE e Gnome), excelentes aplicações (OpenOffice.org, Firefox, Evolution, MPlayer, K3B, Konqueror, Nautilus, etc.), excelente flexibilidade com distros que automatização os processos (Kurumim, SuSe, Mandrake, etc.). APENAS ACHO que está faltando iniciativas de sites e documentações com enfoque exclusivo para usuários domésticos. Conhecem alguma?

Ainda sobre instalação, pra empresas construtoras de software, manter N instaladores é realmente um parto. Minha empresa se inclui nesse exemplo. Qdo conseguir passar meus app em Delphi pra Mono, pode ter certeza que vou preferir um instalador universal. -- A LSB não define padrões para isso? o RPM não é universal? A maioria das distros não o suportam? Não existem conversores (Alien)?

Dá uma lida no PDF q vc vai encontrar muita coisa interessante e muito bem justificada que precisa ser melhorada. -- Beleza! E valeu pela dica! &;-D

Reforçando, apenas acho que a nossa comunidade deveria se mexer mais. Uma das melhores coisas que surgiram foi o Kurumim. Pelo menos para apresentar e disseminar, ele me ajudou MUITO. Faltam mais iniciativas deste nível, porém que deveriam se concentrar em sites de apoio, fóruns e documentações. O resto vem com o tempo.

Att., Ednei Pacheco.

Por outro lado, em uma visão: Por outro lado, em uma visão mais atenta, o suporte ao hardware no Linux (e sistemas livres) é *melhor* do que o do MS Windows. No Linux você tem a "garantia" de que um hardware antigo, "obsoleto", se não é suportado pela versão corrente do kernel, poderá ser facilmente portado, fazendo algumas modificações no código-fonte de uma versão anterior do driver. E no MS Windows XP, o que aconteceu com aqueles hardwares projetados para o MS Windows 9x cujas companhias por algum motivo não dão mais suporte ao driver? O que acontecerá no lançamento do MS Longhorn? -- Falou TUDO! Tenho uma HP DeskJet 710C que utiliza os drivers nativos do WinXP. Essa merda não dá flexibilidade de configuração e muito menos imprime em frente-e-verso. Um porre...

Att., Ednei Pacheco.

Uma maneria a medio prazo, se: Uma maneria a medio prazo, seria lançando uma campanha pareciada ao spreadfirefox.com, assim como webmasters estão começando a desenvolver paginas para o Firefox ao IE, com a popularização tb do Linux, os desenvolvedores de hardware se preocupariam em lançar drives oficiais.

Mas isto não aconteceria antes de uma facilidade maior de uso do linux ou um instalador padrão.

_________________
Quer se livrar do provedor do speedy?

Veja no meu site.

Concordo, em parte...: Porém, como usuário doméstico sofri um bocado para encontrar "drivers" pros componentes de hardware quando usava o sistema da MS, somente recentemente (creio que no XP) é que eles 'nos' copiaram incluindo uma grande quantidade de drivers para periféricos no sistema. Já com muitas distribuições Linux, apesar da alardeada (e mentirosa) dificuldade de instalação, não precisei ficar desesperadamente procurando aqueles drivers na internet ou tentanto lembrar onde enfiei aquele CD da impressora ou da webcam que usei uma vez na vida quando comprei e não lembro onde guardei depois da segunda mudança...

Agora o XP reconhece a maioria (não todos) dos hardwares periféricos e também aqueles que estão dentro do gabinete, tem tela de login que parece (pros usuários da MS) uma grande novidade.

A Microsoft não é boba, me lembro em 95 quando o pessoal da Apple usava um tipo de adesivo que dizia WIN95=MAC89. Quer dizer, o que eles percebem que é bom, copiam mesmo na cara dura. E essa vantagem de monopolizar os produtores de hardware (com seus respectivos drivers) já não é a mesma que eu conheci em 98 (praticamente absoluta). Estamos longe do paraíso mas é isso, temos que "encher o saco", exigir "suporte" aos produtos de hardware que adquirimos, deixar os revendedores loucos (como costumo fazer aqui com os fornecedores), exigir que o hardware funcione ou acionar o PROCOM que eles tem pavor porque os manuais não estão em português, os disquetes ou CDs tampouco ou seja, totalmente fora das especificações do Código de Defesa do Consumidor, então eles acabam te dando outra placa que seja compatível (ou mais compatível), etc.

É assim, um jogo de forças que se dá em diversos níveis, estou usando um exemplo local, mas vejamos o que acontece a nível dos governos, vejamos o que foi noticiado hoje da ameaça do tio Bill se não me engano à Dinamarca, de demitir 11000 programadores ou leva-los aos EUA. Já o Lula recusou-se a sentar-se com ele. Como eu disse, jogo de forças...

Opiniões diferentes...: Ednei,

Salve a divergência de opiniões! Mas sinceramente não concordo que dependa só da comunidade ou dos pobres do usuários se interessarem mais.

Faaalta bastante coisa sim pra facilitar a vida do usuário. KDE, GNome, OOo, etc estão realmente muito bons, mas coloca um usuário leigo na frente de Mac e Windows: ele usa e se vira mais do que em linux. Ou seja: falta alguma coisa. Essa história do usuário ter que aprender alguma coisa... O cara quer fazer o trabalho dele. Ler documentação? Até parece q o mundo gira em torno de computadores...

Se o Linux estivesse tãao pronto pra desktop, então pq não é tão largamente usado em desktop como em servidores? Pq só pessoal com um nível razoável tá usando Linux e não o usuário doméstico macacão? O mercado ensina... e a situação é essa. Temos que melhorar.

De qquer forma, respeito sua opinião, e o movimento da comunidade ajuda, mas não resolve. Falta estrutura "desktop".

Abraço.

Compatibilidade binária X drivers de código fechado: Augusto,
O problema de compatibilidade binária no linux vai além dos drivers de periféricos. Lido no dia-a-dia com linux e sotware livre. Em algumas áreas, para onde se voltam a grande maioria dos investimentos, como servidores, o hardware específico funciona perfeitamente em linux. Fabricantes como IBM, HP e Dell garantem a compatibilidade de seus sistemas com determinadas versões corporativas.
Por outro lado, no desktop, onde a quantidade de hardware é gigantesca, as coisas se complicam. Veja o caso da Nvidia. Há dois drivers. Entendo o ponto de vista do fabricante, como também entendo o ponto de vista da comunidade. Entretanto, um diretor de TI, e mesmo o usuário doméstico mediano, não está interessado em questões filosóficas. O que se quer é a solução para determinado problema e não um novo problema. Atualize o kernel de uma estação de trabalho rodando linux, com uma placa de vídeo Nvidia e você terá problemas no próximo boot, se não atualizar os drivers de vídeo antes da próxima inicialização gráfica. Imagine o custo de 40 minutos de um engenheiro de uma grande exploradora de petróleo que ficou parado por causa de uma atualização de kernel que levou seu sistema a parar de funcionar, pois o driver exige a versão x.y.z.1.2.3.5 do kernel e na atualização está com a versão x.y.z.1.2.3.5a.

No campo das aplicações a coisa não é muito diferente. No meu trabalho lido com grandes empresas e nenhuma delas se arrisca com desktop linux por causa dessas questões. Já tive problemas sérios com sistemas proprietários que funcionavam muito bem no Red Hat Enterprise 2.1 e, quando foram migrados para o 3, simplesmente não funcionaram. Pegue um software que rode no Solaris 8 e instale no Solaris 10 e ele funciona. No linux, se funcionava com o kernel 2.6.7, boa sorte com o 2.6.8. Quem lida com o mercado corporativo sabe muito bem qual é o peso da responsabilidade de um CIO na hora de se decidir por essa ou aquela solução e isso acaba retardando um avanço maior do SO em diversos segmentos.

Com relação a comprar periféricos e equipamentos que não funcionem com linux, eu também não compro. Winmodem tem muito tempo que não uso. Entretanto, convenhamos, isso acaba limitando nossas opções, tanto em termos de quantidade de hardware disponível quanto em qualidade dos mesmos.

Mas um adendo:: Sobre softwares: O que defendo é um fabricante de softwares fazer um instalador universal, pro usuário não ter q procurar o pacote da sua distro e pra q o fabricante não tenha q manter N pacotes.

Faz um teste: Pega um amigo seu leigo, acostuma com Windows ou Mac e instala um Linux pra ele. Escolhe a ditro. A cheia de pacotes, a q é fácil, como vc falou, e vamos ver qtos dias ele dura... C tá vendo pela sua ótica, que deve ser a de quem sabe se virar com computadores. Talvez vc seja até um desenvolvedor, como eu...

Eu já fiz o teste... explode tanto... o cara faz tanta merda. O CD não ejeta, a música não toca, o arquivo não grava. Tudo justificado. O linux nbão fez nada de errado, mas o que importa é: pro usuário, ele não conseguiu fazer... Faz o teste...

Não entendi muito bem, mas i: Não entendi muito bem, mas isso seria uma espécie de concorrente da FreeDesktop?

Som no Linux: Som é um dos grandes problemas do Linux no Desktop. O ALSA está bem estabelecido no nível de device-driver, com suporte "quase" total às placas e chips do mercado. Mesmo assim, muitas aplicações ainda requerem o velho OSS, caindo na emulação OSS do ALSA.

E na hora de fazer software-mixing, isto é, permitir o compartilhamento da placa de som? É ARTS, ESD, SDL, emulação OSS do ARTS, emulação OSS do ESD...

Recentemente eu apanhei bastante para rodar o Skype junto com o ARTS. Como eu uso drivers ALSA, a opção padrão de driver do ARTS era, logicamente, ALSA. E daí não funcionava o full-duplex, o ARTS nem carregava. Depois de muita frustração, arrisquei configurar o ARTS para usar o driver OSS (emulado do ALSA) e daí funcionou, mas a que preço...

E agora que habilitei o ARTS, metade dos programas que uso (inclusive o Skype) precisam ser carregados através do artsdsp. E se um dia eu quiser remover o ARTS, precisarei editar os atalhos para remover a chamada do artsdsp. Tente explicar isso a um usuário leigo.

Outra coisa: geralmente é necessário informar para cada programa qual método de acesso ao sistema de som ele tem que usar. O XMMS tem umas 4-5 opções (ALSA, ARTS, etc); o MPlayer em nem me lembro. Parece os tempos do DOS em que cada jogo tinha que ser configurado, de novo, para reconhecer a placa de som (e de vídeo, mas não é o caso aqui).

Imagino que um caminho seria padronizar as aplicações em cima do ALSA. Ao se usar o API dele (não a emulação OSS), o software mixing é possível. Adeus OSS/ARTS/ESD/etcetera, e as aplicações de console rodariam em paz com as do KDE ou Gnome, sem bloqueios de dispositivo.

Suportar aplicações legadas (no nosso exemplo o OSS) é uma fonte de problemas. Que diga a MS com o Windows, que tem que fazer das tripas coração pra rodar, digamos, o X-Wing para DOS.

No mundo do software fechado não existe outra opção pois as fontes dos programas de terceiros não estão disponíveis. Mas no mundo SL sempre dá pra pegar as fontes, limpar o passado e manter o programa compatível com as novas tecnologias.

Abraços a todos.

Correção: "Faz um teste: Pega um amigo seu leigo, acostumaDO com Windows ou Mac e instala um..."

Exagerei: Corrigindo segundo acabo de ver aqui mesmo no BR-LINUX são 800 e não 11.000 programadores, lí a notícia ontem pela manhã no avião e não lembrava precisamente. Acho que foi o efeito da cerveja na pressurização da cabine ;-)

Tá aí...: Tá aí um dos exemplos ruins das deficiências do Linux pra desktop. Isso acontece na parte servidor?? Nada. Pq estamos mais preparados em servidor e não em desktop.

Agora imaginem o exemplo do nosso colega FatTux nas mãos de um usuário doméstico leigo? Ele desiste e ainda fala mal do sistema.

E não adianta essa conversa de que a culpa é dele. A CULPA È NOSSA!! O linux precisa melhorar essas coisas, e iniciativas como as do freedesktop e agora OSDL, são o começo da mudança.

Que nojo.: "- Servidor gráfico integrado no kernel qdo distro desktop."

Windows? Não, obrigado.

Problemas...: O grande problema de falta de suporte a alguns dispositivos no Linux são os fabricantes, e não a comunidade de SL. A nvidia, por exemplo, é um cocô. Uma empresa nojenta, que só lança drivers meio-abertos, ou seja, fechados. E o pior de tudo, é que quando os drivers de vídeo são lançados, não funcionam. E para piorar, os desenvolvedores são umas amebas: tentam resolver os problemas da porcaria dos drivers deles lançando patches para o kernel do Linux (coitado do kernel, que não tem culpa nenhuma...).

Enquanto as empresas de hardware forem tão competentes como a nvidia é, a situação vai continuar a mesma.

Enquanto temos mil pessoas reclamando que a placa XYZ não funciona no Linux, existem uns dois ou três doando uma boa parte do seu tempo trabalhando duro para fazer a porcaria da placa XYZ funcionar no Linux. Sem receber nada, e muitas vezes sem apoio nenhum da empresa fabricante ou de outras pessoas.

Fico realmente triste quando vejo pessoas reclamando da falta de suporte a alguns dispositivos no Linux, como se os desenvolvedores do kernel ou do X.Org tivessem a obrigação de fazer tudo funcionar. O Linux não é uma corporação, que garante que tudo vai funcionar. Somos uma comunidade. Quando alguém quer que algo funcione, essa pessoa mesmo vai atrás, e faz a coisa acontecer. Percebo que no Brasil acontece um fenômeno estranho: Há muita gente falando e pouca gente fazendo. Há muita gente querendo o software livre, se interessando, vendo que pode se beneficiar dele, porém desanimando quando percebe que participar da comunidade de SL envolve receber, mas também dar.

É só analisar: quantos que estão nessa discussão, sugerindo idéias e reclamando de projetos, realmente contribuem ou contribuíram com algo para o Software Livre? Poucos, imagino eu.

Abrir os drivers ou aceitar as restrições: Eu concordo que o gerente de TI pode não estar interessado em questões filosóficas, e ele deve procurar uma solução que o atenda - no seu exemplo, uma possibilidade é a adoção de uma distribuição de Linux certificada pelo fornecedor das aplicações que ele usa. E neste caso, ele não deveria mesmo fazer atualizações/recompilações que não fossem também certificadas, sem antes verificar os efeitos.

Estou de pleno acordo quanto à importância de estabilidade das interfaces - APIs e ABIs. Mas este caso que você descreveu é uma situação em que o usuário pode estar querendo o melhor de 2 mundos: ele quer recompilar o kernel a partir do código fonte, e ao mesmo tempo não quer perder minutos. E esta perda de minutos, no caso que você descreveu, ocorre justamente porque o driver é só binário, sem fontes, e tem requisitos específicos que o usuário optou por ignorar.

Não acho que este tipo de situação seja um argumento forte a favor da estabilidade e padronização das interfaces. Há muitos argumentos fortes a favor disso (incluindo a questão das aplicações que você levantou), mas a situação descrita parece ser mais uma razão forte para advogar em prol da abertura do código do driver, ou para que os usuários que optam por utilizá-lo (e eu não tenho nenhum problema quanto a isto, aliás) saibam que têm que ficar restritos às especificações e restrições que o fornecedor do driver estabeleceu, assim como ocorre com a maioria dos softwares, especialmente os proprietários...

E não tenho dúvida de que esta situação limita nossas escolhas. Já deixei de considerar a compra de vários hardwares devido a esta ausência de suporte. E já usei drivers proprietários em conjunto com software livre várias vezes, quando precisei. Mas não acho que estimular e facilitar a adoção de drivers proprietários deve ser a solução principal ou a política adotada.

Esta discussão não é nova, já em 1995 Linus Torvalds se manifestava a respeito (dizendo que não apreciava drivers não-GPL mas achava que não deveriam ser impedidos). Tem outro artigo interessante sobre isso, e uma frase que sintetiza a situação típica dos drivers não-GPL incluídos em um kernel livre, em franco desenvolvimento e com suas interfaces ainda não estabilizadas consta no Linux Hardware Compatibility HOWTO e é de autoria de Linus Torvalds: "Eu aceito módulos binary-only, mas quero que as pessoas saibam que a expectativa é de que rodem _apenas_ na versão do kernel para a qual foram compilados." O que não impede que determinados desenvolvedores de drivers proprietários tentem usar subterfúgios - justamente para tentar evitar que as pessoas saibam...

No que concerne os drivers da: No que concerne os drivers das placas de vídeo, o Open Graphics Project, que visa construir uma placa de vídeo (comparável tecnicamente às nvidia e ATI) totalmente aberta e documentada, pode ser uma grande esperança para esta área que julgo mais crítica/carente para os sitemas livres. Segundo discussões recentes[1,2], o projeto tem avançado de forma animadora, e há previsão para que no meio deste ano um protótipo da placa seja construído.

--
FLTK fltk.org (Fast Light C++ GUI Toolkit)

Bom, o que esperamos do Linux: Bom, o que esperamos do Linux???

Queremos ele uma caixinha preta onde só 'nerds' conseguem faze-lo útil, ou facilitado a nível de Windows para as massas?

A verdade é uma só: UM USU

Concordo: Concordo

Patola, nao é bem assim...: Patola, hardwares exóticos vão ser um problema, não há dúvida. Porém, eles tambem são um estorvo no Windows. E os winmodems com drivers para win95 que não funcionaram nas versoes superiores de windows ? Aquelas winprinters, scanners que não são mais suportados ?

Mesmo com os hardwares exóticos, o interessante é que no windows as soluções para os diversos problemas estão sempre no mesmo lugar, ou seja, voce vai no painel de sistema e lista o que o seu computador [nao]reconheceu e ali voce acrescenta e remove qualquer hardware.

Um problema similar para ambos os problemas : Um hardware que não tem driver nem para windows 98 e nem para linux, vejamos :

No windows, com um arquivo .inf voce acrescenta/atualiza um driver. O que ? não tem .inf então vai no site do desenvolvedor e veja se há o driver em questão, o que! não tem ? então esqueçe, não será possivel sua instalacao.

No Linux, voce vai "googlear", ler howto, e vai se "penar" e gastar horas-a-fio até chegar a conclusão que não há solução.

Falta ao Linux uma opção similar ao windows, infelizmente não temos uma painel de controle onde mesmo hardwares problematicos devao ser diagnosticados. Se o negócio é impressora e o servidor é o cups as coisas são de um jeito, se é monitor a coisa é de outro jeito, se é mouse de 12 botoes (vai faltar dedos para tantos botoes) é outro e assim por diante.

A flexibilidade do Linux as vezes me parece um empecilho para o gerenciamento de perifericos. Uma empresa como a 3com (poderia ser qualquer outra) poderia desenvolver um driver para o seu novo winmodem, mas a questão é : Como será feita a instalacao desse driver para um usuario domestico ?

Iniciativa conjunta entre as distros de tornarem a instalacao de drivers de forma mais modular e com um centro de controle integrado e igual entre elas seria o grande bam-bam-bam. A redhat e a suse já estao chegando perto, mas mesmo que uma delas alcance o 100% ainda será ruim porque será apenas uma e as outras distros vao continuar por caminhos diferentes e tornar o caminho do win-usuario turtuoso.

MultiMedia: Essas padronizações já foram pensadas pela FreeDesktop, a idéia era que todos passasem a usar o Jack, para mixar os audios, no lugar de usar esd, arts, ou diretamente o alsa ou oss, isso facilitaria muito as coisas, não é algo complicado, eh soh as pessoas seguirem os padrões da FreeDesktop, que pretende somente tornar os desktops compatíveis, que me agradam muito mais do que esse novo, que quer padronizar tudo.

Destkop Corporativo: A discussão está tendenciosamente fugindo do escopo da notícia. O projeto da OSDL tem como foco o usuário corporativo e não doméstico, que na maioria dos casos, não é necessário configurar uma placa de som com quinquilhões de canais ou uma placa de vídeo 3D de última geração. Tecnologias como essas podem ser necessárias em empresas que atuam em segmentos como a computação gráfica, mas o propósito da OSDL são outros tipos de usuários Linux.

Quem é da comunidade e está sempre atenta as notícias, inclusive as deste site, tem visto sucesso em vários projetos que envolvem a adoção do Linux no ambiente corporativo, mas também alguns fracassos. O projeto da OSDL quer colaborar para reduzir estes fracassos.

Quanto ao desktop doméstico, o único ponto de concordância é que o Linux não está realmente preparado para este ambiente. Projetos semelhantes a este da OSDL, atentendo especificamente a estes usuários, devem aparecer para reunir estas idéias e opiniões, acumular estatísticas, discutir os pontos fracos e, consequentemente, colaborar com o desenvolvimento, adoção e criação de soluções.

Grande e honrado Paulo, : Grande e honrado Paulo,

Salve a divergência de opiniões! -- Taí algo que concordo plenamente com você! &;-D

Mas sinceramente não concordo que dependa só da comunidade ou dos pobres do usuários se interessarem mais. -- Bem, me desculpe se por acaso expressei-me mal; o que quis dizer é muitos já fizeram sua parte; mas ainda acho que a comunidade fez pouco no que concerne em sites especializados e documentações. Quando entramos um site especializado em GNU/Linux, vemos um mundo de informações que são desenvolvidas para usuários aficcionados e profissionais. O usuário doméstico ao visitá-los, não encontra um ambiente propício para que ele se sinta à vontade. O mesmo se dá com as documentações, que são escritas de "superusuário para superusuário". É neste sentido que estou tentando fazer alguma coisa e abrir o olho.

Falta bastante coisa sim pra facilitar a vida do usuário. KDE, GNome, OOo, etc estão realmente muito bons, mas coloca um usuário leigo na frente de Mac e Windows: ele usa e se vira mais do que em linux. Ou seja: falta alguma coisa. -- Concordo em parte e lhe faço uma pergunta: por que um usuário leigo sabe se virar no Windows? Simples: porque já o viram! Faça uma (outra) experiência: pegue uma pessoa que NUNCA teve contato com um PC. Instale, configure e ajuste da melhor forma possível o GNU/Linux e a aplicações essenciais nesta máquina, lhe dê instruções gerais de uso e deixe-o usar por uns 3 meses. Depois desinstale tudo, instale o Windows com todas as aplicações tradicionais e tire suas conclusões. Já fiz isso com meu pai e meus irmãos, e os resultados foram muito interessantes.

Essa história do usuário ter que aprender alguma coisa... O cara quer fazer o trabalho dele. Ler documentação? Até parece q o mundo gira em torno de computadores... -- Éh, tem razão. O sistema e as aplicações necessitam de algumas mudanças para atingir o seu raciocínio. Por outro lado, independente do sistema em uso, existe a necessidade de manutenção do mesmo, e tenho certeza de que você já foi chamado por um colega-leigo para resolver "o problema que o Windows tá dando...". Pense nisso.

Se o Linux estivesse tãao pronto pra desktop, então pq não é tão largamente usado em desktop como em servidores? Pq só pessoal com um nível razoável tá usando Linux e não o usuário doméstico macacão? O mercado ensina... e a situação é essa. Temos que melhorar. -- São públicos distintos que requerem métodos distintos (por isto reforço a necessidade de sites e documentações voltadas para estes públicos). Quanto ao sistema, não têm melhorado? Você se lembra como era o sistema há uns 4/5 anos atrás? Infelizmente as pessoas vivenciam muito o presente e esquecem do futuro. Deste tempo pra cá, o KDE e o Gnome já atingiram um alto grau de maturidade, ao passo que o Windows praticamente estabilizou. Já existem aplicativos de tudo quanto é tipo (e até concorrendo entre si). O suporte à periféricos avançou muito, apesar de necessitar ainda de melhorias - nem sequer tínhamos aceleração gráfica 3D! Faça uma previsão: imagine como será o sistema daqui à uns 2 ou 3 anos? Enquanto esse tempo não chega, vamos preparando o terreno... &;-D

De qquer forma, respeito sua opinião (...) -- Taí outro elemento importante. Em muitos aspectos discordo de você, mas acredite: vou IMPRIMIR suas considerações (e a dos demais companheiros), estudá-las ATENCIOSAMENTE e reformular meus conceitos (se necessário), pois assim acredito que iremos nos aperfeiçar para atingirmos nossa meta (disseminação do sistema & SL). E espero que a comunidade faça o mesmo, pois acredito que assim só temos à ganhar. Valeu! &;-D

(...) e o movimento da comunidade ajuda, mas não resolve. Falta estrutura "desktop". -- Coloquei algumas considerações particulares neste artigo e espero que este material ajude a refletirmos em nossas condutas sobre esta questão. Quando digo que falta apoio na comunidade, é algo (que acredito ser) neste sentido em que ela deveria se concentrar. Bem, pelo menos cumpri o objetivo de dar à luz esta questão. &;-D

Algumas dicas:

1. esqueçam o usuário leigo. Concentrem-se naqueles medianos e avançados (pelo menos inicialmente). Mais à frente teremos melhores condições para trabalharmos com os leigos.
2. Reflitam na questão "Cultura Linux Moderna".

Abraço. -- Igualmente! &:-D

Att., Ednei Pacheco.

Se têm uma coisa que a galer: Se têm uma coisa que a galera do Unix sabe fazer é modular as coisas. Não acho q a inclusão de um módulo gráfico e outros ligados à desktop possam prejudicar. Como outros módulos do kernel, é ligar/desligar.

Não existe só o Linux. É bom lembrar que com algo assim, a portabilidade fica seriamente comprometida para outros sistemas operacionais/kernels (*BSDs, OpenSolaris, Tropix, Atheos, etc.).

Quanto mais se puder separar a camada de apresentação do kernel, melhor.

--
Ainda em estágio altamente experimental e pré-alpha: http://linuxfud.ath.cx
LinuxFUD, mostrando as mentiras da mídia contra o software livre!

Aí é outra coisa: Ex. Quero colocar o Nicotine aqui no micro, mas pelo visto tenho que instalar o Python e o GTK e o pyGTK. No Windows instalaria o o SoulSeek em quatro cliques.

Desculpa, mas você misturou duas coisas diferentes. Falou da facilidade e aí foi pras dependências... o Windows também tem dependências.

Você poderia ter no GNU/Linux a mesma gambiarra que no Windows: uma versão estática do software (com todas as bibliotecas compiladas junto, fazendo um binário inchadíssimo) ou ainda ele vir com todas as coisas de que depende.

ISSO É MUITO PIOR. É muito mais fácil ter um sistema de pacotes que faça tudo automaticamente. Quer o programa? apt-get install nicotine, ou ainda up2date nicotine, ou ainda emerge nicotine... Muito melhor, mais amigável e indolor, sem conseqüências nefastas. Só que vem de uma cultura diferente, e muitos usuários Windows se negam a aprender qualquer coisa que seja diferente do que já aprenderam.
--
Ainda em estágio altamente experimental e pré-alpha: http://linuxfud.ath.cx
LinuxFUD, mostrando as mentiras da mídia contra o software livre!

ISSO É MUITO PIOR. É muito: ISSO É MUITO PIOR. É muito mais fácil ter um sistema de pacotes que faça tudo automaticamente. Quer o programa? apt-get install nicotine, ou ainda up2date nicotine, ou ainda emerge nicotine... Muito melhor, mais amigável e indolor, sem conseqüências nefastas. Só que vem de uma cultura diferente, e muitos usuários Windows se negam a aprender qualquer coisa que seja diferente do que já aprenderam. -- Concordo e reforço:

1. Não é culpa nossa eles não querer aprender;


2. Pra quem não quer aprender, não há nada à fazer.

Att., Ednei Pacheco.

Pelo visto, ainda vai continu: Pelo visto, ainda vai continuar... &;-D

Att., Ednei Pacheco.

E o LSB: Bah, que mão na roda seria deixar de "penar" atrás de soluções que ainda não existem (e que não temos capacidade técnica para cria-las). Concordo plenamente contigo neste sentido, mas não seria a adoção do LSB (parece que a Novell/Suse já o fez) um caminho para aproveiar mais efetivamente estas experiências da SuSE e RH no sentido que tu colocas?

Mundos diferentes: Acho que vivemos em mundos diferentes, onde alguns acham que esta tudo bem, outros que vai melhorar no futuro, e outros acham que ta muito difícil.

Como li em comentários anteriores em 95 o Linus Torvalds ja se deparava com estes problemas e com sua prepotência falava que não precisava de drives binários (fechados) e hoje 10 anos depois ainda estamos discutindo isso sem ter resolvido a questão, quem sabe mais 10 anos isso se resolva.

Outros comentários falam que a padronização não é possível no software livre, e acham que empresas devem fazer instaladores para 200 distribuições diferentes. Isso nunca vai ocorrer porque as empresas vão ter que ter vários profissionais especializados em cada distribuição ou desktop para poder comercializar seu produto, seja software ou algum drivers.

Outros acham que os fabricantes devem abrir as especificações dos seus produtos (drivers), que toda a sua pesquisa, seu desenvolvimento, seu investimento devem ser disponibilizados para a concorrência. Vivemos num mundo real, isso não existe.

Na minha opinião é simples, juntar forças, fazer um padrão e seguir o mesmo, é contra o software livre, pode até ser mais é um mau necessário. Não venham me falar que ja existe um padrão a ser seguido, porque se existisse, não teríamos esta confusão de diretórios, configurações, dependências, de pacotes para esta ou aquela distribuição e assim vai. A API então nem se fala isso não existe, faça do seu jeito, ou vai pela tua preferência os usuários depois dão um jeito de rodar a tua aplicação.

Instalar no linux é mais fácil que no windows? Quem fala isso acho que nunca usou a instalação do windows, mesmo sem nunca ter usado vai ter problemas em instalar um programa que tem como dependência alguma biblioteca usada por outro programa, um deles provavelmente vai dar problema.

Todos aqui sabem os problemas, alguns tentam justifica-los, o que esta errado. Com esta mentalidade nunca teremos um desktop linux para usuários normais.

Pode não ser relevante, mas: Pode não ser relevante, mas uma professora sempre disse que documentação deve ser escrita para que idiotas entendam.

Se for o caso, vamos tratar usuários leigos como leigos mesmo, que entendamos que eles sequer saibam o que estão fazendo sentados na frente do computador.

_____________________________
Carlos Wagner - São Luís / MA

Concordo com ambos porém...: Porém se queremos avançar (e para solucionar "n" dos problemas que aqui estão relatados) temos que ir no sentido de ampliar SIGNIFICATIVAMENTE a base de usuários, sequer apenas do Linux, mas não Windows. Então se eles se negam a aprender, já há alternativas na "língua que eles falam", no lugar de u2date nicotine, eles clicam no íconezinho lá no cantinho e vão seguindo os passinhos em quatro cliques. a Mesma coisa no outro exemplo, se não querem abrir um terminal para digitar apt-get install nicotine, vão lá no synaptic ou nesta nova solução criada pelo povo lá da conectiva e clixam no quadradinho do software e... voala, o sistema se encarrega do resto. Creio que já temos a faca e o queijo. Quero dizer que vale a pena não deixar pra lá as resistências dos usuários Win que se negam a aprender qualquer coisa diferente, porque tenho tido muitíssimas experiências de convencimento com esse povo que tem se tornado simpático ao Linux após algumas demonstrações.
Com uma imensa base de usuários o poder de "negociação" se torna outro, é o que temos visto nos últimos anos.

Adoção do LSB: A maior parte das distribuições mais difundidas já suporta o LSB - ou por default ou por meio de pacotes opcionais (mas oficiais). O padrão LSB 2.0 é suportado por empresas como a AMD, Conectiva, Dell, HP, IBM, Intel, Mandrakesoft, Novell, Red Flag, Red Hat e Turbolinux.

Não foi isso que ele disse:

"Como li em comentários anteriores em 95 o Linus Torvalds ja se deparava com estes problemas e com sua prepotência falava que não precisava de drives binários (fechados)"

Pelo contrário, o Linus Torvalds disse em 1995 que não apreciava drivers binários (fechados), mas que as pessoas deveriam ter o direito de criá-los se quisessem. E ainda hoje elas têm esse direito, e ainda hoje esta "solução" mantém as conseqüências inerentes à sua condição de software proprietário e fechado dependente de um software aberto em evolução.

Instruções para leigos: CWagner,

É +/- por aí... &;-D

Att., Ednei Pacheco.

eu gosto assim ...: Eu gosto assim do linux bagunçado mesmo, lógico que alguns padrões deveriam ser adotados, como no caso do som, ou é Arts, ALSA , sei lá.. mas escolher um.

Mas a diversidade de distribuições é boa para a comunidade, empresarialmente acho que o Linux vai acabar cheio de frescuras, como querem fazer com Lycoris, Lindows (nem sei o nome novo) e a própria Novell (Eu acho a novell um Boi disfarçado de GNU)

Padrões são para núcleos ou kernel (como queiram) o resto acho que está perfeito. Quem gosta de fescura usa o KDE ou Gnome, quem gosta de sofrer usa o bash$

É só questão de ler o man que em no máximo 30 dias tu pega a coisa de jeito.

Famelix!: É isso aí, Alexandre.

Quer ver uma coisa que me chateia profundamente? Uma pessoa ou grupo cria um trabalho sob seu ponto de vista e, pelos demais não compartilharem, o criticam de forma bastante desestimuladora. Um bom exemplo: a distro Famelix. Tudo bem que muitos não concordam com a iniciativa, mas ao invés de estimularem o evento (já que o objetivo vem de encontro aos nossos interesses), criticam duramente! O fato da distro ter a cara do Windows XP foi o ponto alto destas discussões. Se ELES fizeram dessa forma, provavelmente H

A diversidade não torna o Linux mais seguro?: Fazendo uma analogia, não sei se transmite bem o que quero dizer (alguém que for engenheiro florestal pode explicar melhor): numa floresta, uma praga que ataca determinada espécie (compare com um vírus de computador) dificilmente se alastrará facilmente, devido haver muitas espécies diferentes de árvores, e mesmo que ela se dissemine, isto será dificultado, porque as da mesma espécie não estarão próximas uma da outra. Embora, claro, seja importante que haja padronização, as diferentes maneiras e soluções implementadas acabam tornando o Linux menos vulnerável (o que todos sabemos), se analisarmos a questão globalmente. Não sei se me fiz entender.

Flexibilidade!: Bem, a flexibilidade do sistema chegou à tal ponto que hoje podemos criar distribuições que rodam em CDs, que reconhecem e instalam tudo, que requerem intervenção direta, que exige muita ou pouca carga do sistema, e por aí vai, certo? Então porquê não utilizamos esta flexibilidade de forma mais inteligente? A OSLD diz que quer criar dois padrões distintos, não é? Então?

Resumindo: usuários X utilizam distros construídas para propósitos X, Y para Y, Z para Z, W para R (ops! &;-D). É uma questão de saber avaliar.

Att., Ednei Pacheco.

Modus Operandi: Software Livre.: Ainda o Alessandro não "pescando" como funciona o mundo do Software Livre...

Outros comentários falam que a padronização não é possível no software livre, e acham que empresas devem fazer instaladores para 200 distribuições diferentes. Isso nunca vai ocorrer porque as empresas vão ter que ter vários profissionais especializados em cada distribuição ou desktop para poder comercializar seu produto, seja software ou algum drivers.

Se for um produto livre, basta deixar que a comunidade mesmo faz pacotes. Se não for, basta usar um "checkinstall" da vida - que faz com que pacotes pra qualquer distribuição não sejam nada difíceis de fazer. Assim como existe o installshield e outras soluções pra Windows, existem também pra GNU/Linux várias soluções: autopackage, smart, etc.

Outros acham que os fabricantes devem abrir as especificações dos seus produtos (drivers), que toda a sua pesquisa, seu desenvolvimento, seu investimento devem ser disponibilizados para a concorrência. Vivemos num mundo real, isso não existe.

Fale isso para o Stallman. Foi por um driver de impressora que ele começou todo a idéia de software livre... ;) Sério. Isso é uma das coisas mais básicas: falar que abrir as especificações é algo irreal revela, em minha opinião, pouquíssima visão de mercado e oportunidades. Como diz o Lawrence Lessig no seu livro "The Future of Ideas", para certas coisas transformar seu copyright em "commons" é a melhor coisa para se fazer. Foi assim que a arquitetura IBM-PC dominou o mundo - por ser aberta.

Na minha opinião é simples, juntar forças, fazer um padrão e seguir o mesmo, é contra o software livre, pode até ser mais é um mau necessário.

Alessandro, tente enxergar o mundo do software livre como uma comunidade, não uma empresa ou uma pequena quantidade delas. Como é que você vai convencer tanta gente a seguir uma única direção? Não é possível. Simplesmente não dá. Há muitas vozes discordantes antes mesmo que você venha com o seu "padrão", seja ele qual for. Faz parte da ecologia, digamos assim, do software livre. Não adianta teimar nessa parte - como eu disse, é melhor trilhar outro caminho.

não teríamos esta confusão de diretórios, configurações, dependências, de pacotes para esta ou aquela distribuição e assim vai.

Na verdade não é uma confusão, está tudo devidamente documentado. Pergunte pros mantenedores do Debian, por exemplo. Ou pra galera do Linux Standard Base. Mas não esquecendo: como não há uma única empresa/comunidade, há distribuições diferentes do Debian e até arranjos de sistemas de arquivos diferentes do LSB, como o do Gobolinux. Travar num modo único seria impedir a inovação e a escolha.

A API então nem se fala isso não existe, faça do seu jeito, ou vai pela tua preferência os usuários depois dão um jeito de rodar a tua aplicação.

Não entendi essa parte. Do que exatamente está falando? De qual API?

Instalar no linux é mais fácil que no windows? Quem fala isso acho que nunca usou a instalação do windows, mesmo sem nunca ter usado vai ter problemas em instalar um programa que tem como dependência alguma biblioteca usada por outro programa, um deles provavelmente vai dar problema.

Comparemos bananas com bananas, não com laranjas ou pêras. Não estou falando de ./configure; make; make install. Estou falando de instalar pelo apt-get (ou synaptic, a interface gráfica), ou pelo Mandrake Update, ou por qualquer utilitário que resolva as dependências automaticamente. É muito mais fácil que no Windows: põe uma cadeia de procure, ache o programa (ou vá pelas categorias), clique nele e - tchum! É só o tempo de baixar e instalar cada pacote. Para produtos comerciais é um pouco mais difícil, realmente (como os drivers, eles têm suas idiossincrasias com a interação com a parte livre), mas não insolúvel, como bem o dizem as soluções que eu citei mais acima.

Todos aqui sabem os problemas, alguns tentam justifica-los, o que esta errado. Com esta mentalidade nunca teremos um desktop linux para usuários normais.

O problema é que o seu padrão de "certo" é o Windows e tudo o que difere dele você acha errado, inclusive o modus operandi intrínseco (e inextrincável) do software livre. Já te ocorreu que pode ser você que não se adaptou?
--
Ainda em estágio altamente experimental e pré-alpha: http://linuxfud.ath.cx
LinuxFUD, mostrando as mentiras da mídia contra o software livre!

Livre X gratuíto: O primeiro ponto interessante é que os fabricantes de equipamentos "pagam" para conhecer as especificações daquele sistema fechado, enquanto as especificações do Linux estão disponíveis livremente.

Parece que o custo não é o fator determinante para as decisões dos fabricantes de hardware. Deve ser outra coisa então!

Aí vem o segundo ponto interessante: mesmo que a maioria de nós não goste muito, os drives fechados seriam (são e serão) aceitos com muita naturalidade entre os usuários comuns - afinal eles não se importam muito mesmo se sua plataforma de informação é livre ou não - e os fabricantes não precisariam (temer) liberar as especificações de seus equipamentos.

Parece, aqui, é que a velha confusão na língua inglesa entre livre e grátis continua atrapalhando muito o desenvolvimento do desktop Linux.

Evandro Guglielmeli

Um dia eu aprendo...: Patola quem sabe um dia...

Quanto a instalação de programas só falei que no windows é mais fácil, não quero que o linux siga o mesmo caminho, até porque são sistemas distintos. As ferramentas de instalação ainda estão amadurecendo, fazem 90% do trabalho, mais ainda se confundem em dependências, gerando problemas para os usuários.

Quanto a abrir as especificações, só visando algum lucro, é assim que as empresas pensam, é o caso da IBM-PC que te tornou um padrão mundial. Não existem empresas sem fins lucrativos, tudo tem um porque.

Estranho a comunidade segue alguns padrões e outros não, acho que tem gente no meio desta "comunidade" que tem interesse em emperrar o linux no desktop.

Quanto a API me referi ao windows, ja foi discutido aqui que o linux tem o QT, o GTK, ... que seguem padrões próprios.

Só quero dizer que sou a favor da padronização, unir forças para ter um desktop padrão no que se refere a parte gráfica, juntando o X com o QT, com GTK, e principalmente um painel de controle, sim como no windows para gerenciar os dispositivos do hardware.

O resto cada distribuição faz o que achar melhor, usar tal gerenciador de janelas, com tal estilo, com painel ou sem painel, com icone ou sem icone, isso não importa, o importante é o coração do sistema gráfico ter um padrão. Com isso os desenvolvedores não se preocupariam com as distribuições e sim com o produto, e o usuário comum vai conseguir instalar o programa sem maiores dificuldades.

Tenho a impressão que todos trabalham para si, querendo ser os melhores e não como uma comunidade. Acho que é só impressão.

> Quanto a API me referi ao w: > Quanto a API me referi ao windows, ja foi discutido aqui que o linux tem o QT, o GTK, ... que seguem padrões próprios.

Só quero dizer que sou a favor da padronização, unir forças para ter um desktop padrão no que se refere a parte gráfica, juntando o X com o QT, com GTK, e principalmente um painel de controle, sim como no windows para gerenciar os dispositivos do hardware.

Isso não funciona e, felizmente, não é necessário. Qualquer API que não seja básica e direta (como a da XLib) tende a não agradar a maioria dos desenvolvedores e, portanto, fadado ao fracasso. Tudo o que especifique e amarre coisas além de comandos para desenhar tende a não dar certo.

Não há como estipular um padrão de widgets no GNU/Linux, fixar uma linguagem de programação, ou especificar um jeitão à la Qt ou GTK+. Imagine todos "obrigados" a escrever em Qt, com uma API inchada e não estritramente C++ (pré processadores próprios, abuso de macros e MOC's)? Ou então, estipular que todos devem escrever suas aplicações gráficas em C, via GTK+?!?

--
FLTK fltk.org (Fast Light C++ GUI Toolkit)

Gerenciadores de pacotes só gerenciam o caos, não o eliminam.: Patola,
Pense na seguinte situação. Você está no meio da selva Amazônica, com acesso precário à internet, via satélite e precisa de determinado programa (pode ser na sua casa, com acesso discado e um gerenciador de downloads). Muito bem, você baixa o tal do programa, usando um gerenciador de downloads e, ao tentar instalar, descobre que ele precisa de 10 dependências diferentes. Usar um gerenciador de pacotes não facilitaria em muito a vida. Além disso, você teria que ter repositórios disponíveis para sua distro, etc, etc. Isso não é solucionar o caos, é estimulá-lo para depois dizer que você tem uma excelente ferramenta que gerencia com eficiência o caos do caos.
Acho que a solução seria o SO ter um conjunto básico de componentes e os produtores de software utilizarem aqueles componentes. O que fugir àquilo, que venha compilado estaticamente. Assim é no MacOS X e ninguém reclama. Nesse caso, para o consumidor final, o software proprietário leva vantagem. Mesmo os softwares livres que dão trabalho pra serem instalados em um linux, são extremamente simples de serem instalados em softwares proprietários. Tente instalar/atualizar o Mono no linux e no Windows ou MacOS X e veja a diferença. A mesma coisa acontece com outros milhares de softwares.

Lendas: "- Servidor gráfico integrado no kernel qdo distro desktop."

Pelo amor de Deus, isso não ! Foi isso que estragou os windows baseados no NT. Pode-se fazer sim aluns tipos de módulos para acesso direto a hardware, etc, como já é feito mas colocar o X.org no kernel linux seria horrível.


"- Suporte a Thin-client applications melhorado no servidor X. Hj se consegue executar um software numa máquina e mandar a saída pra outro servidor X, mas a configuração disso é um saco. Trocando: Ter um tipo de citrix metaframe embutido no Linux."


Eu uso somente um ssh -X e o display já é exportado automaticamente.


"- Reconhecimento de hardware, USB hotplug, etc, melhorados no kernel pra atender aos periféricos usados por usuários domésticos e corporativos."

Isso já está sendo feito. Veja a iniciativa de uma HAL que começa a parecer em algumas distribuições. Infelizmente depende muito mais da boa vontade dos fabricantes de hardware.

Eu sou otimista nesse sentido e acho que com o crescimento rápido do linux no desktop vai chegar um momento em que os fabricantes serão pressionados a pensar em fazer drivers para linux, assim como aconteceu com as placas de vídeo Nvidia e ATI.


"- Melhorar (e muito) o boot time qdo foco for desktop."

Em máquinas boas o linux já é mais rápido do que um Windows XP como desktop. Num Pentium 4 3GHz HT com 512MB RAM e hd de 7200 rpm do trabalho levo MENOS tempo para dar boot no linux (runlevel gráfico, com gdm) do que o XP na mesma máquina. E a configuração das máquinas novas de hoje não são diferentes disso. Logicamente não deixo 500 daemons rodando na máquina e configuro o hdparm para ligar o acesso DMA do hd.

Empacotamento alternativo: Joerlei, hoje já é possível criar aplicações que dependam apenas dos recursos incluídos na especificação da LSB, e aí eles não precisarão de providências para satisfação de dependências nas diversas distribuições que já atendem ao padrão. E acho que não é inviável compilar programas que incluam estaticamente apenas o que for extra-LSB, e dinamicamente com os componentes da LSB. Isto vai gerar binários bem mais inchados, naturalmente, mas é uma opção. O Opera é um exemplo de aplicativo recente para Linux que inclui esta possibilidade de empacotamento.

Acredito que não tenha surgido o interesse de ninguém para construir, manter e suportar um conjunto de pacotes com este tipo de especificação. Quem sabe você não reune mais alguns interessados e cria o projeto pioneiro de reempacotamento de aplicativos desta forma? Aí seria possível fazer um comparativo.

Falando como usuário, entretanto, eu prefiro aplicativos que usem a variedade de recursos existentes (seja o Qt, GTK, centenas de módulos do Perl, ou o que for) e tenham pacotes de instalação simplificada, preparados especificamente para a distribuição que eu for usar. Especialmente quando as dependências são preparadas considerando as versões dos pacotes fornecidas em conjunto com a distribuição, ou quando as dependências adicionais estão facilmente disponíveis nas mesmas condições mencionadas acima.

Não acho que ninguém tenha obrigação de me fornecer pacotes nestas condições, e estou preparado para instalar pacotes obtidos de outras formas, mas quando há escolha (ou possibilidade de esperar), é o que prefiro. Mas se você for construir pacotes como os que você descreveu, eu gostaria de testá-los.

Dependência será problema eterno: Acho que a solução seria o SO ter um conjunto básico de componentes e os produtores de software utilizarem aqueles componentes. O que fugir àquilo, que venha compilado estaticamente.

Não é bem assim, Joerlei. Enquanto você tiver "reuso de código", dependências serão SEMPRE um problema a ser resolvido. O "caos" sempre existirá - e sempre precisaremos de ferramentas para gerenciá-lo. Essa coisa de querer que tudo seja compilado estaticamente (exceto por algumas bibliotecas-base) seria suicídio - o uso de memória dos programas aumentaria demais. Pode até ser semi-vantajoso pra usuário bem iniciante que utiliza 2, 3 programas abertos ao mesmo tempo e tem memória, mas e pra quem já o utiliza profissional e domesticamente e abre um buzilhão de programas ao mesmo tempo em que roda servidores de diversas coisas? Não dá pé.

Assim é no MacOS X e ninguém reclama.

Mas a gente tem que se situar: estamos no mundo do software livre, onde o reuso é MUITO maior que no mundo do software proprietário. Fora as bibliotecas básicas (e quem decide quais serão essas bibliotecas? Mais um problema pra gerenciar. Entra a glib? O GTK+? A QT? A KDElibs?), é difícil softwares proprietários X, Y e Z utilizarem a mesma biblioteca. Já no mundo do software livre eu tipicamente vou ter o software P, Q e W utilizando a biblioteca não-básica Y, o A, B e C utilizando a Z e o K, L e M utilizando a W e a X... fica inviável querer fazer esses programas todos virarem imensas e pesadas bolas de bibliotecas estáticas. O disco rígido cairia no chão de tanto peso.

Deixe eu tentar colocar o pé no chão só pra você ver como é: quais dessas bibliotecas você deixaria como estáticas, quais não?

libreadline-common
libreadline-ruby1.8
libreadline-java
libglade2-0
libxvidcore2
libgtkhtml3-0
libgtkxmhtml1
libwxgtk2.4
libtiff4
liborbit2
libbz2-1.0
libdb4.2
libpcre3

Só alguns exemplos pra você pensar. Coloquei bibliotecas que são usadas por zilhões de programas diferentes - e medianamente comuns. Isso porque nem entrei nas bibliotecas do KDE, que têm mais integração ainda e mais decisões a fazer (rotula qt como "básica" e kdelibs não ou coloca as duas?).

Sinceramente, acho que você está pensando que as dependências um dia deixarão de existir. Eu perderia as esperanças. =) Como eu já disse aqui, acho que o negócio é aprender a lidar com as idiossincrasias do software livre, não tentar fingir que se podem eliminá-las.

E os gerenciadores de dependência são perfeitos pra lidar com eles. Na situação que você falou, o melhor seria utilizar seu programa para esse fim, não um gerenciador de download. Seja synaptic, emerge, yum, up2date ou urpmi... Aliás, se você já tiver as bibliotecas corretas já instaladas, pense bem, o download do programa sairá até menor, pois ele estará compilado dinamicamente!

--
Ainda em estágio altamente experimental e pré-alpha: http://linuxfud.ath.cx
LinuxFUD, mostrando as mentiras da mídia contra o software livre!

Empacotamento alternativo: Augusto, eu também não acho que alguém tenha a obrigação de fornecer pacotes nessas condições, a não ser quando estou pagando por determinado produto/solução. Entretanto, acho que muita coisa seria simplificada se os fornecedores de soluções (entre estes, as próprias distribuições) suportassem uma forma comum de empacotamento, que elimine ou minimize o problema. Trabalho com o mercado corporativo e essa é uma das barreiras para maior adoção do linux como plataforma desktop nesse segmento. Infelizmente as distribuições não dão muita importância a isso. Lembro muito bem o resultado de minha sugestão a uma conhecida distribuição, que apoiasse e suportasse o autopackage. Aliás, o autopackage pode vir a ser a solução para esse problema. Testo o mesmo há um bom tempo e o progresso é animador. Se houvesse maior apoio, com certeza já estaria bem mais maduro e funcional.

Dependência será problema eterno?: Patola,
Acredito que muita coisa ainda mudará. Com o avanço do linux no mundo corporativo e grandes empresas assumindo determinados projetos, a tendência é, pelo menos os fornecedores comerciais, oferecerem sistemas que facilitem a vida do usuário/administrador. Muita coisa ainda tem que evoluir. Pegue o caso do rpm, por exemplo, que encrenca com nome de bibliotecas. Há pouco tempo fui instalar uma aplicação comercial que custa alguns milhares de dólares, certificada para a plataforma (RHEL 3) e a dita aplicação se recusava a instalar porque o sistema operacional tinha sido atualizado e a biblioteca x.y.z.12.3 agora se chamava x.y.z.12.4. Use o apt pra atualizar a distribuição, por exemplo, e ele remove aquela aplicação. Parafraseando o grande filósofo cearense Falcão, isso é de lascar. Quero ver como o OpenSolaris se sairá nessa área, uma vez que não haverá dezenas de versões incompatíveis entre si e é um sistema mais maduro (além de o suporte ser mais barato do que de versões corporativas do linux).

Eu acho que será...: Pense assim: o caso da dependência que mudou de versão menor aí não muda o fato que o programa precisava da biblioteca, certo? (Afinal, ISSO que é a dependência) E - acredito eu - nem vai mudar. Talvez uma aplicação grande, digamos, um Oracle, que praticamente monopoliza qualquer máquina, seja compilada estaticamente pra facilitar a instalação (já que ocupa buzilhões de bytes mesmo), mas será uma exceção e não a regra.

O problema da dependência aí é um problema de gerenciamento correto, a aplicação deveria instalar com a versão x.y.z.12.4. Resolvedores mais inteligentes como o smart já estão cuidando isso (e isso, suponho, também é bem resolvido pelo apt - só acho que no empacotamento disso aí alguém colocou versionamento estrito demais).

--
Ainda em estágio altamente experimental e pré-alpha: http://linuxfud.ath.cx
LinuxFUD, mostrando as mentiras da mídia contra o software livre!

Aham: Estranho a comunidade segue alguns padrões e outros não, acho que tem gente no meio desta "comunidade" que tem interesse em emperrar o linux no desktop.

Não acho que tenha interesse em emperrar - acho que tem idéias próprias, diferentes, e força de vontade o suficiente pra implementá-las. Ninguém tem o trabalho de escrever um programa livre pra ferrar o panorama do software livre - pelo menos não planejando isso.

Tenho a impressão que todos trabalham para si, querendo ser os melhores e não como uma comunidade. Acho que é só impressão.

Eu acho que não é impressão. É o "pagamento" do software livre voluntário, uma boa massageada no ego. Desenvolvedores livres são muito orgulhosos, isso pode ter certeza (entre nos canais de IRC deles ou leia as listas de discussão). E a "comunidade" de que às vezes falamos é mais como o Morimoto disse: várias comunidades diferentes, cada uma com seu interesse. Em suma, é uma zona, cada um querendo uma coisa e pensando em si próprio. Você queria o quê? Somos humanos! =D
--
Ainda em estágio altamente experimental e pré-alpha: http://linuxfud.ath.cx
LinuxFUD, mostrando as mentiras da mídia contra o software livre!

É preciso entender que depen: É preciso entender que dependência é sinônimo de modularidade, de reuso --exceto se uma biblioteca for usada desnecessariamente pelo software.

Isto significa que apesar de incluir a necessidade de um gerenciamento de dependências, as vantagens certamente superam, dentre elas estão: mais eficiência em espaço (menos memória usada, menor tamanho em disco) e tempo (usar uma biblioteca compartilhada é mais veloz do que carregá-la do zero), bem como menor consumo de banda.

À medida que as bibliotecas caminham para a estabilidade (como hoje a libc, libstdc++, etc.), mais excitante e proveitoso torna-se o conceito de dependência (reuso).

--
FLTK fltk.org (Fast Light C++ GUI Toolkit)

Patola, esse é o problema: >>...É o "pagamento" do software livre voluntário, uma boa massageada no ego. Desenvolvedores livres são muito orgulhosos, isso pode ter certeza (entre nos canais de IRC deles ou leia as listas de discussão). E a "comunidade" de que às vezes falamos é mais como o Morimoto disse: várias comunidades diferentes, cada uma com seu interesse. Em suma, é uma zona, cada um querendo uma coisa e pensando em si próprio. Você queria o quê? Somos humanos! =D

Enquanto continuar essa "zona", aí sim o linux ficará limitado aos geeks, a "mico"soft continuará seu monopólio e tio Bill mais milionário.

Se padrões não fossem importantes, a Internet não seria o que é hoje e provavelmente ninguem conseguiria ler o que estou escrevendo agora. Imagine se o TCP/IP, HTML etc não fossem padronizados!!!

Pelo que li, nos posts dos colegas que se opõem à padronização, a inovação e liberdade estaria ameaçada. O fato de se conseguir rodar uma determinada aplicação (exemplo hipotético, mas possível) na distro X e não conseguir rodar essa mesma aplicação na distro Y também não é uma privação de liberdade?

SO é NADA sem aplicativos. O Linux (ou qualquer outro SO livre, por que não?) só detonará a hegemonia do rWindows quando a comunidade pensar não só no SO (cacofonia podre :), mas também nos aplicativos com formas padronizadas e unificadas de acesso, porque distro X,Y,Z = LINUX.

Acima de qualquer coisa, respeito a sua opinião e de todos os colegas que postaram. Afinal, a divergência de opiniões é um grande expoente de liberdade.

Abraço.

A questão da padronização: A questão da padronização não é 8 ou 80. Existem níveis e domínios onde a padronização deve ser instaurada. O contexto da comunicação é essencial, é o caso do TCP/IP, HTML e toda a definição do W3C. As entidades básicas são um outro exemplo, como o POSIX, LSB, etc.

Esta é uma questão muito delicada, uma padronização indevida pode ceifar tanto possivelmente melhores alternativas como a liberdade de escolha; por outro lado, a total liberdade pode inibir o crescimento/evolução em uma direção promissora, provocando o caos, uma verdadeira torre de Babel.

Na minha opinião, sempre quando há dúvida (ou polêmica) sobre se deve ou não padronizar, o melhor é manter a liberdade.

--
FLTK fltk.org (Fast Light C++ GUI Toolkit)

Pasmo: "Instalar no linux é mais fácil que no windows? Quem fala isso acho que nunca usou a instalação do windows". Francamente Alessandro, daí tu forçou demais a barra, nem vou entrar nas outras questões, já muito bem debatidas, mas esta tua pérola não desce. Talvez tu nunca tenha instalado um Linux, ou o tenha feito há muitos anos, bota anos nisso, talvez tenha tido a sorte de instalar o Windows sem muitos (ou nenhum) problema (duvideodó), mas fiz ambas as coisas durante muito tempo (atualmente felizmente só instalo o Linux). A diferença começa pelo tempo que tu levas, as 'n' reinicializações NECESS

Eu disse da facilidade do Win: Eu disse da facilidade do Windows e das dependências do Linux. Uso Windows a 5 anos e nunca precisei instalar nenhuma dependência, com exceção do Sandra no Windows 98. Não miturei nada, isto é para exemplificar a facílidade do Windows.

Usuários do Windows se negam a aprender alguma coisa diferente!? EXATAMENTE.

Já teve problema com as tabelas de dependências do apt-get? Eu já. E doeu :).

Isso é verdade. O que temos: Isso é verdade. O que temos que pensar é em padrões de bibliotecas. Não conheço programação, e não sei se é possível, mas se as bibliotecas fossem padrão, as dependências poderiam vir instaladas com a distribuição.

Só uma dúvida: até que ponto um padrão não restringe a sua liberdade?

Blz: Belezza Patolão... então pega um usuário tosco e manda ele fazer tudo isso q vc falou... 6 tão com cabeça de técnico, não de usuário. Linux vai ganhar empresas qdo tiver padrão de instalação e manutenção (já têm com pactos, tô falando de software de 3os pra qquer ditro), e pra usuário doméstico qdo o macaco ver a porra da geladeira linux funcionar do jeito q ele quer. É isso... o resto é defender por égo. Adooooooro o Linux, mas reconheço suas definiências.

PS: Acabei de chegar da balada locão, bebaco, pirulitado. Larga o cumputadô galera e vai tomar um drink!!!

Abraço a todos.

"Este dia não é hoje!": E a "comunidade" de que às vezes falamos é mais como o Morimoto disse: várias comunidades diferentes, cada uma com seu interesse. Em suma, é uma zona, cada um querendo uma coisa e pensando em si próprio. Você queria o quê? Somos humanos! =D -- Fiz esse comentário noutra notícia, mas não custa nada repetir.

Sou fã da trilogia "O Senhor dos Anéis" e uma citação que gostaria de fazer - que considero interessante analizar - é aquela cena em que Aragorn desafia o exército de Sauron em frente aos portões de Mordor para dar à Frodo a chance de destruir o Um Anel. Ao encontrar seus homens receosos, ele diz isto para eles com o objetivo de dar confiança e moral:

"Eu vejo nos seus olhos o mesmo medo que me tirava a coragem, haverá um dia em que a coragem do homem falhará, em que falharemos com nossos amigos traindo-lhes a sua devoção. MAS ESTE DIA NÃO É HOJE. Um dia de lobos, em que espadas cairão e escudos quebrarão e os homens perderão essa terra que lhes pertence. MAS ESTE DIA NÃO É HOJE. Hoje nós lutamos. Lutamos por tudo o que nos é querido, por está terra valiosa que nós temos. Hoje é o dia de glória dos homens!"

http://www.setzergabbiane.blogger.com.br/2004_02_01_archive.html

Será que este comentário não deixa "algo no ar" para a comunidade livre?

Att., Ednei Pacheco.

Calma: Calma Alexandre acho que tu entendeu errado ou eu me expressei mal, estava a me referir a softwares (aplicativos) e não ao Sistema O
peracional que por sinal a instalação no Linux evoluiu muito, até quando é em modo texto como no Debian é muito intuitiva, neste ponto o Linux esta muito bom.

Nos aplicativos (programas) entra o problema das dependências, dos gerenciadores e isto ja esta sendo discutido nos outros comentários, isso torna o Linux para usuários de informática e o Windows para usuários comuns.

Apenas reforçando...: "A instalação e a configuração inicial deve ser feita por quem tem mais experiência com computadores. Isto é consistente com a prática difundida. Como já disse antes, usuários finais que instalam seus próprios sistemas operacionais são uma excessão, não é uma norma, em quase todos os OS sobre o Sol. Conseqüentemente, a instalação e configuração inicial deve ser executada por um "nerd residente", no escritório ou em casa ou por uma pessoa que tenha alguma qualificação para isto." -- "Procedimento Desktop Parte I: Procurando uma nova Distro.", por Eduardo Sánchez G. (Trad. Bruno H. Collovini)

Att., Ednei Pacheco.

Dê tempo ao tempo.: Eu acho que deveríamos dar tempo ao tempo e esperar, a padronização no Desktop irá ocorrer mais cedo ou mais tarde, enquanto isto dizer que há pessoas na comunidade que "estão emperrando a padronização" é leviano pois não há provas e deixa a impressão de que estamos tratando com uma comunidade egoísta e infantil(o que até que me provem ao contrário não é!)
Acho que todos nós queremos puxar a sardinha para o nosso lado quando tratamos de padronização, e isto é normal pois evita que tenhamos muito trabalho, pois se criarmos uma grande comunidade entorno daquilo que usamos fatalmente seremos beneficiados.
Mas como uma comunidade é um conjunto, neste caso de pessoas, temos que nos acostumar ao caráter humano, que como todos nós sabemos é imprevisível e difícl.
O que não podemos nos esquecer é que a caracte?istica que faz um conjunto de pessoas se mobilizar em torno de algo é a liderança(quesito essencial na área administrativa de uma empresa), e neste caso existem líderes e falsos-líderes.
Cabe a cada um que deseja uma padronização adquirir esta qualidade que no caso da comunidade SL é muito importante e a mais difícil de adquirir, pois a comunidade é livres e usa por vezes parâmetros diferentes do comum "capitalista" para seguir alguém.

Assim caminha a humanidade... =): Enquanto continuar essa "zona", aí sim o linux ficará limitado aos geeks, a "mico"soft continuará seu monopólio e tio Bill mais milionário.

Eu não acho. Eu acho que mesmo daqui a 30 anos no futuro a zona continuará. Acho que é uma qualidade intrínseca pela própria natureza humana - não importa quão boa seja uma idéia, vai haver gente discordando e vai haver gente implementando coisas diferentes. Nem que seja somente pra perseguir um interesse mesquinho ou se sentir especial!

E acho apenas que essa qualidade deve ser passada ao povão. O fato de sempre ter escolha pode parecer assustador à primeira vista, mas, oras, é bom.

Se padrões não fossem importantes, a Internet não seria o que é hoje e provavelmente ninguem conseguiria ler o que estou escrevendo agora. Imagine se o TCP/IP, HTML etc não fossem padronizados!!!

Engraçado você falar da Microsoft (a rainha dos protocolos fechados) e então citar protocolos abertos como TCP/IP e HTML. Esses protocolos dominam hoje não porque foram "padronizados", mas porque ganharam ubiqüidade, maioria de uso. Isso é popularização, não padronização. CLARO que havia outros protocolos que o TCP/IP e HTML desbancaram, já de cara me lembro do IPX e o protocolo de menus do gopher.

Pelo que li, nos posts dos colegas que se opõem à padronização, a inovação e liberdade estaria ameaçada.

Não sei aos outros, mas o que eu faço não é exatamente "me opor". É aceitar que é IMPOSS

TCP/IP e HTML: Esta foi forte, "TCP/IP e HTML esses protocolos dominam hoje não porque foram padronizados"

Qual outro motivo então, ja pensou se não fosse padronizado o que seria da internet? Metemos o pau na microsoft que foge do padrão em relação ao IE, e dizemos que o software livre não pode ter um padrão gráfico.

Temos a seguinte situação o que tem um padrão evolui, no próprio software livre temos um ótimo exemplo o Kernel, tem um padrão e mantedores que avaliam o que vai ser implementado ou não, este é o melhor exemplo, porque não segui-lo?

Acho que a resposta para isso: Acho que a resposta para isso é simples... :) Inércia!

Conheço pessoas que tem nível técnico para fazer do computador o que bem entendem, inclusive pessoas que criam software e hardware do nada para sanar suas necessidades especificas mas preferem usar Windows porque simplesmente estão acostumados com ele. Quando eu mostro meus computadono dia a do ares todos usando Linux para tudo eles acham interessantes mas não vem uma necessidade de mudar, ainda mais que a maioria também não pagou nada pelo Windows e outros softwares e como são experientes e tem condições de manter o Windows em ordem (ou pelo menos em um estado satisfatório de operação). Acho que o maior problema é essa "inércia", se isso ocorre com os experientes, que não tem problemas de falta de conhecimento técnico imagina com os usuários domésticos! O cara que mau sabe o que é um arquivo? Acredito que o Linux esta tão pronto para esses usuários quanto o Windows, eles são não vem um motivo para sair do que já estão usando.

Esta foi forte, "TCP/IP e HTM: Esta foi forte, "TCP/IP e HTML esses protocolos dominam hoje não porque foram padronizados"

Mas é mentira? Nenhum comitê determinou que deveria existir uma rede mundial e que o protocolo dela seria obrigatoriamente o TCP/IP. Ao invés disso, vários protocolos de rede surgiram e competiram por espaço, entre eles o TCP/IP, que dominou por ser popular e aberto. A mesma coisa com HTML.

Qual outro motivo então, ja pensou se não fosse padronizado o que seria da internet? Metemos o pau na microsoft que foge do padrão em relação ao IE, e dizemos que o software livre não pode ter um padrão gráfico.

Existem vários padrões, essa que é a questão, na medida em que existem várias propostas. Existe o padrão gnome, com bonobo e tudo o mais. O padrão KDE, com dcop e outras coisas. O padrão XFCE, o padrão enlightenment... Isso só pra citar o exemplo dos desktops.

E eu estou dizendo: esses vários padrões existem porque tem gente que gosta de um, gente que gosta do outro e do outro e do outro... E você NÃO vai convencer esses caras a mudarem seu gosto. E enquanto eles estiverem livres para usar ou desenvolver a seu bel prazer, você não pode fazer nada pra obrigá-los.

Temos a seguinte situação o que tem um padrão evolui, no próprio software livre temos um ótimo exemplo o Kernel, tem um padrão e mantedores que avaliam o que vai ser implementado ou não, este é o melhor exemplo, porque não segui-lo?

Ótimo exemplo! Sim, temos o kernel, que implementa o que podemos chamar de um padrão. Não vou nem considerar os vários forks, mas me diga: você ACHA - tem a vã esperança - de que vai convencer o pessoal do *BSD a padronizar pelo kernel do Linux? CLARO que não! Mesmo que você os encha de pancadas, eles têm sua preferência. Você NÃO vai conseguir fazer eles abandonarem o BSD. Vão coexistir vários padrões, independente do que você queira.

A situação, como eu já disse, não é bem que eu não queira que haja um padrão comum usado por todo mundo. É que NÃO D

Tenho que concordar, é como: Tenho que concordar, é como o manual do micro-ondas que diz que você não deve usar o equipamento para secar seu gato. :-D

--
Cesar Gimenes
http://www.alfalyncis.net

TCP/IP e HTML: TCP/IP e HTML só são populares e usados por vários sistemas operacionais por terem um padrão, que foi aceito pela maioria.

Não quero um padrão mundial o que seria monopólio apenas fazer como é feito com o kernel do Linux, um padrão gráfico, e os descontentes vão ter a liberdade de criar outros projetos e o melhor vai se tornar popular para não dizer padrão como foi o TCP/IP e HTML.

O problema que isso não foi feito ainda, estamos esperando a 10 anos... e pelo que vemos vamos ter que esperar até que o alpha do windows se transforme em beta e acabe com os problemas de segurança, tirando um dos trunfos do Linux a segurança. (.NET é bem promissor)

Os BSD são um exemplo, não seguiram o padrão do Linux e quem sabe não vão ser os padrões do futuro.

Só vai se tornar um padrão o que der certo, o resto...

Quem?: Na sua opinião, quais os projetos livres que deveriam abandonar a maneira atual adotada por eles para sua manutenção e adotar a que você propõe? Se você tiver interesse em advogar a questão junto a eles, posso tentar obter os endereços de contato para você.

Eu acredito que a força de um padrão não vem de nenhuma entidade central que o torne oficial, mas sim vem da sua adoção pelo mercado, pelos usuários e pelos desenvolvedores de aplicação e conteúdo. Como o Patola apontou, o TCP/IP não nasceu padrão mundial. Ele tornou-se padrão devido à adoção, e acabou suplantando em seu campo outros padrões que existiam antes (e não necessariamente foram extintos), como decnet e ipx/spx. Quando o HTML surgiu, já existiam outros padrões para representação de hipertexto, também. Quando o HTTP surgiu, havia outros protocolos e serviços com funções similares.

Algumas iniciativas nascidas com o objetivo de se tornarem padrão não deram tão certo - e um exemplo interessante é o modelo de rede em 7 camadas OSI, que foi criado para ser padrão, e academicamente, documentalmente e pedagogicamente serve muito bem, mas nunca chegou a se tornar o padrão do mercado como originalmente se propunha - e o mercado continua adotando variações do modelo pragmático em 4 camadas das origens do TCP/IP, com variações (e até mesmo com interessantes subterfúgios para se adaptar ao modelo de 7 camadas, quando isso foi necessário para vender sistemas para órgãos governamentais dos EUA no passado - além dos mapeamentos de correspondências entre as camadas de protocolos do mundo real e as do modelo OSI, frequentes em livrios, apostilas, aulas de redes e indelevelmente marcadas na memória de muitos estudantes e profissionais).

Outras iniciativas deram certo como padrão, mas são frequentemente ampliadas de formas quer fogem ao padrão, ou forçam uma flexibilização porque as pessoas tem necessidades diferentes. É o caso do código ASCII, por exemplo: a representação de caracteres em 7 bits não deixou espaço para os acentos e caracteres diferenciados de diversos idiomas, abrindo espaço para uma série de outros padrões largamente adotados e incompatíveis entre si (mas padrões, ainda assim)... É o caso de implementações de diversas linguagens para as quais há um padrão: mesmo no mundo proprietário, frequentemente o código-fonte de uma linguagem padronizada (COBOL, C++...) pode ser compilado nas ferramentas de desenvolvimento de um fornecedor, mas não funciona nas de outros. É o caso das múltiplas implementações do HTML, com páginas corretas que são renderizadas de maneira diferente dependendo do navegador, e com uma implementação incompleta do padrão sendo adotada pelo mercado.

Talvez algo de positivo acabe surgindo se um conjunto específico de infra-estruturas de aplicação se solidificar, e a tendência dos desenvolvedores de aplicação para plataformas livres for depender sempre deste conjunto (por exemplo, "todo mundo" desenvolvendo usando sempre Qt, ou só GTK, ou preferindo Tk). Acho até provável que isso aconteça - embora sempre vão existir as exceções, o que é positivo.

Mas acho improvável que aconteça *hoje*, ou na semana que vem. Talvez você esteja esperando há 10 anos por isso, mas o crescimento do Linux no desktop começou há muito menos tempo do que isto, e muito provavelmente as fundações desta infra-estrutura de aplicações que um dia será a mais difundida (e possivelmente vista como padrão por muitos) ainda não estão tão completas como estarão quando forem efetivamente adotadas em uma maneira semelhante à que você prega,

Mas já que você está incomodado por ter de esperar, estou à sua disposição para tentar encontrar os endereços de contato das pessoas pelas quais você está esperando. Indique quem são elas! Quem sabe você não fala com elas, as convence de que estão erradas, as motiva e indica este caminho que você descobriu e tem certeza de que é o correto?

Isso! Tempo!: Eu acho que deveríamos dar tempo ao tempo e esperar, a padronização no Desktop irá ocorrer mais cedo ou mais tarde (...) -- Também acho. Já falei muito sobre a evolução do sistema nestes 5 anos (que o conheço). Problemas que tínhamos há alguns anos (falta de suíte office madura, por exemplo) já não existem, e acredito que em 2/3 anos a situação esteja bem favorável à nossa causa.

dizer que há pessoas na comunidade que "estão emperrando a padronização" é leviano pois não há provas e deixa a impressão de que estamos tratando com uma comunidade egoísta e infantil -- Acredito que leviano não seria um termo correto, mas quem usou os termos egoista e infantil, acertou em cheio. As críticas que são feitos à determinados projetos, o apego à distros e aplicações preferidas, entre outros, ilustram bem esses dois termos. Temos que ter a consciência que a causa é uma só: GNU/Linux & Software Livre.

Se prestarmos atenção, a cada dia têm crescido esforços e tendências do crescimento do GNU/Linux & Software Livre rumo ao Desktop. As iniciativas que antes eram tímidas, hoje são bem mais numerosas. Há uns 3/4 anos atrás quem poderia pensar na existência de distros e literaturas com enfoque exclusivo para o Desktop?

Att., Ednei Pacheco.

Enquanto isto, porquê não v: Enquanto isto, porquê não vamos "preparando o terreno" e ir nos preparando para "os novos tempos"? &;-D

Att., Ednei Pacheco.

Padrão: Pelo teu relato e de outros comentários o Linux esta longe de atingir o Desktop, concordo contigo.

Só vai atingir quando um projeto gráfico conseguir sobressair a outros e atingir a maturidade que as empresas e os usuários esperam, ou seja se tornará um padrão, claro com outros projetos correndo por fora, porque temos a liberdade de fazer isso.

Não sei porque estamos discutindo este assunto, pelo que vejo nos comentários anteriores estamos esperando um projeto crescer e ter a maturidade de se tornar o padrão gráfico, essa é exatamente a minha opinião. O Desktop Linux só vai crescer nas empresas e nas casas dos usuários quando tivermos este padrão gráfico definido.

Agora como desenvolvedor de aplicações comerciais não tenho conhecimento técnico para dizer qual esta certo e qual esta errado, acho que todos tem grandes potenciais, se todos estes esforços fossem unidos com certeza ja não existiria mais o Windows e o Software Livre tomaria conta dos sistemas operacionais, tanto dos Servidores como dos Desktops. Mais como somos humanos, orgulhosos e dificilmente admitimos nossos erros, vai continuar assim, até que alguém ou alguma coisa surja para mudar este panorama.

Talvez você esteja esperando: O Linux pode estar longe de se tornar majoritário no desktop, mas também já não está ausente dele - principalmente quando se trata do desktop corporativo.

Talvez você esteja esperando, mas outros estão fazendo e usando. E o número deles cresce cada vez mais. E eles aproveitam o que está disponível, em toda a sua variedade. Possivelmente isto um dia vá resultar na existência dos padrões que você tanto espera, ou até mesmo na hegemonia do Linux no desktop. Eu não sei, e nem sinto necessidade de ficar esperando por isto.

Eu já convidei você a identificar quem você acha que está errado, para que você possa ir lá e tentar corrigi-los, e você optou por não fazê-lo, e rebateu com esta de que faz parte de um grupo que é orgulhoso e não gosta de admitir erros. Mas se você acha que tem alguém fazendo algo errado, a melhor solução é mesmo ir falar com este alguém e expor sua opinião.

Que outra solução você vê para esta situação que você identifica e faz questão de apontar incessantemente? Me informe, quem sabe possamos te ajudar a implementá-la!

Solução: Quanto a apontar os erros dos projetos em produção hoje, para min é somente a falta de integração e de um padrão, são muitos projetos com o mesmo objetivo o que distribui forças, e cada projeto acaba recriando a roda, todos querem ser o pai da criança. Este problema ja foi muito discutido na comunidade como sendo um dos argumentos de que se é livre, por isso existem esta diversidade de projetos, isso eu acho que aprendi com os comentários aqui do site.

Então este problema que relatei, a comunidade acha que não é, sendo assim vou continuar pesquisando para ver se encontro uma solução para os meus problemas que é fazer um software comercial em Linux, sendo que nenhuma empresa do setor achou a solução ainda, com isso pretendo ajudar na migração de vários pontos de venda para o software livre.

Calma...: Não te preocupes Alessandro, estou calminho, calminho, é apenas a minha maneira de expressar minhas opiniões que causam esta sensação de que estou "nervoso", sei lá. Coisas diferentes ;)))

Faca um teste. : Faca um teste.
Aprende C e vai programar no windows, no mac e no linux/bsd.
Linux eh liberdade, independencia. bibliotecas mil.
Tudo baratinhu, pra qq um, igual em um 386 e em um xeon.

eu instalei uma pah de linux onde eu trabalho, ninguem reclamou, eh a coisa mais facil do mundo. ces tao usando muita droga, nao pode ser.

Nunca vou esquecer o dia que eu estava na casa de um amigo nosso, que tem um monte de equipamento muito loco da/para apple e faz musica eletronica.
O Maçan tava lah olhando o equipamento, mostrou umas musicas dele, ai nosso colega perguntou que placa de som ele usava.
O Maçan respondeu: sys onboard.

Tb nunca esquecerei quando a novell vendia um tal de border manager, que nao deixava os raqueres invadirem a rede, e que com um ip soh todas as pessoas na empresa usavam a internet. O border manager custava uns 5 pau, e eu fazia a mesma coisa com algumas linhas de ipchains.

Software proprietario, bom ou ruim, omite o que interessa.
Ou sempre quando vc tah prester a gozar de alegria pq vai fazer alguma coisa, descobre que vai ter que esperar as lojas abrirem no dia seguinte para pagar pra ir pra segunda fase.

Por isso que eu digo, quer usar windows, azar eh seu.
Quer usar mac, paga e espera updates, drivers e novidades.
Vc sabia que eles travam na "bios" das placas da nvidia para uso somente em mac ? e que as placas sao exatamente iguais soh que bem mais caras ? Vc sabia que mesmo algumas placas permitindo usar dois monitores, eles travam isso na "bios" ou nos drivers ? E varias outras coisas...
Talvez para facilitar a vida da galera do suporte, mas talvez para vc gastar um pouco mais no melhor modelo. Neguinhu fica todo feliz que "raquiou" o macosx e conseguiu novas features. Nova o cacete, eh features que vc sempre teve e te negaram, feature que vc pagou.
Quer usar mac, azar eh seu. Eu uso mac, mas nao espero muito nao, uso no meu notebook, onde eu to poco me lixando se tenho que ficar bootando de tempo em tempo para liberar memoria disperdicada. E assim que alguem de boa vontade da macromedia compilar o plugin do flash pra linux-ppc, eu deixo de usar novamente. Na minha paixao maior, que eh meu micro montado na sta efigenia, sempre de gabinete aberto e que eu uso 99% do meu tempo na frente do computador, tah o linux lah, instalacao de Debian de varios anos. Só dando purge nos pacotes velhos e nunca vendo HD crescer sem motivo.

quando vc tah realmente afim: quando vc tah realmente afim de instalar um hardware no linux, vc consegue. No windows, se o fabricante fechou (vide 3dfx, e zilhoes de empresas que fabricavam placa de som), depois de exaustivas procuras por drivers, soh se usar win95 ou win98 ou comprar driver proprietario.