2009/4/4 Hugo Cisneiros (Eitch)
<hugo@devin.com.br>
2009/4/4 Marcio Carneiro <viabsb@gmail.com>:
>> > E quanto aos programas compilados em i386 que não aceitam rodar em uma
>> > arquitetura 64?
>>
>> Só conheço o Flash e o *plugin* do Java pro Firefox.
>
> Creio ter lido que o flash para 64 já está disponível.
Alfa, não conta tanto assim. Mas é uma ótima notícia de que virá.
>> > Quanto tempo teremos de esperar para os programas serem compilados em
>> > 64? E
>> > a compatibilidade?
>>
>> Faz vários anos que as distribuições Linux vem com *todos* os pacotes
>> compilados para x86_64. Só no escritório tem 8 servidores rodando
>> CentOS totalmente x86_64 e umas 10 estações com Ubuntu x86_64 também.
>
> Minha dúvida começou quando instalei o FC10 i386 e depois vi que estava
> errado, pois pensei que o disco era 64 e instalei assim mesmo. Minha
> pergunta inicial era se é possível fazer a atualização com o 64 ou se tenho
> de formatar o disco novamente.
E...? Na sua pergunta, me pareceu que você estava perguntando sobre
quanto tempo deveríamos esperar pelos programas já serem compilados
para 64-bits, sendo que eu respondi que eles já o são, faz anos, com
algumas excessões que eu também disse.
>> > Tenho, sempre, muitos problemas com bibliotecas.
>> > Nêste momento estou com problemas com o FC10, que perdeu alguma
>> > biblioteca
>> > em python, provavelmente, e não consigo acessar o log in no kde.
>> > Com o tal do plasma e a completa mudança no KDE, não existe mais o KDE,
>> > temos o KDE3 e uma criatura completamente nova, que deveria ter vida
>> > própria
>> > mas não acabar com o KDE.
>>
>> Nisso eu concordo, mas essa criatura nova está evoluindo e um dia
>> ficará boa ;-) Se não ficar, a concorrência come.
>
> Pode ser, mas não é a corrida pela mais nova distro ou KDE que importa para
> o usuário, é o que existe funcionar e ser estável. É certo que você poderá
> dizer que qualquer coisa que será feita SERÁ estável, mas é justamente aí
> que está o problema, NUNCA haverá uma distro estável, pois estará SEMPRE no
> futuro.
> Tem de haver um ponto no meio em que uma distro SEJA estável e não haja
> comprometimento com os próximos avanços, por isto me referi ao KDE4 como uma
> nova criatura. Talvez uma distro devêsse ter os dois KDE.
Eu nunca vou dizer que qualquer coisa será totalmente estável. Eu quis
dizer que o KDE4 (IMO) ainda está muito "xulo" e tem muito o que
melhorar pra chegar aos pés do 3.5. Mas essa discussão já é velha e
desafasada: eu já sei que o KDE4 vai ficar legal lá pelo 4.4.
Em contrapartida ao que você disse, tem algumas distros bem estáveis
sim. Ou você acha que um monte de super-computadores e milhares de
servidores rodam distribuições Linux sendo instáveis? Paramos pra
pensar: será que algumas dessas coisas 'instáveis' não são culpa de
BIOS?
Não vou nem falar do Fedora aqui porque a proposta da distribuição não
tem como prioridade ser estável, e sim ter mais funcionalidades e tudo
ser "cutting-edge". O KDE seguiu a mesma direção (aliás, acho que ele
sempre foi assim), só mudando quando sua "minor version" fica mais
distante (por isso eu disse lá pelo 4.4).
>> > Com a facilidade com que os RedHat alike perdem bibliotecas
>> > indispensáveis
>> > ao SO e, depois, para re-instalar, impedem a instalação, alegando que um
>> > programa já existe e não pode ser re-escrito, ou que uma biblioteca é
>> > necessária mas não está disponível e você tem de formatar o HD
>> > novamente,
>> > parece-me que a solução em *nix é, mesmo, um Unix, como o OpenBSD, por
>> > exemplo.
>>
>> Sinceramente não sei o que você faz pra acontecer essas coisas... Eu
>> nunca vejo bibliotecas se perderem assim do nada, com "facilidade". O
>> que eu vejo são pessoas instalando as coisas "natoralmente" e
>> quebrando o sistema inteiro. Aí não tem sistema que aguente :P
>
> Realmente não lembro do programa, pode ter sido um MM como o mplayer ou vlc.
> Pedia uma lib que não podia ser instalada porque conflitava com outra
> existente. Quando removi esta, foi algo da dependência que afetava o SO. E o
> glibc foi corrompido, ou removido dentro da tal dependência.
>
> Para instalar o galeon é necessário o mozilla e outras dependências, pode
> ter sido tentando instalar o galeon.
Ou seja, não culpe a distribuição por algo que você fez de errado. Se
você tentou fazer isso no Fedora, pode ter certeza que utilizou um
repositório de terceiro e não o da distribuição. Depois imagino que
forçou a remoção da biblioteca de modo errôneo e começou a afetar o
SO. Como eu disse: não tem sistema a prova de usuário: só se o sistema
não deixasse o usuário fazer quase nada.
Que nem eu há muito tempo atrás, fui fazer uma atualização de glibc na
distribuição e acabei com tudo. Tive que reinstalar.
>> > Na realidade, NÃO EXISTE uma distribuição Linux, o que existe é um
>> > sistema
>> > de gerenciamento de pacotes com um nome de distribuição.
>>
>> Acho que você deve estar confundindo o termo "distribuição"... Leitura
>> recomendada:
>>
>>
http://www.devin.com.br/intro_linux/
>> Parte "Distribuições"
>
> Não creio que tenha feito a confusão. Li o referido e não tem desacôrdo com
> o que escrevi.
> Disse da distribuição DEPENDER de um sistema de gerenciamento de pacotes e o
> usuário ter problemas em instalar programas fora do gerenciador de pacotes.
> O sistema de gerenciamento de pacotes é muito bom para admistrar a
> distribuição mas não o Linux que o usuário instala.
pacotes. Falar isso é ignorar todo o trabalho que a distribuição tem
de pegar os programas e montá-los de forma legal, colocar um
instalador pra facilitar a vida do usuário, fornecer atualizações,
personalizações, kernels para situações especiais, e inclusive colocar
um gerenciador de pacotes para facilitar todas essas tarefas tanto
para os desenvolvedores, quanto para os usuários.
Falar que uma distribuição é apenas um gerenciador de pacotes é dose.
E instalar pacotes fora do padrão da distribuição é um problema de
qualquer outro sistema. Os gerenciadores de pacotes foram criados para
evitar a "bagunça" que se faz quando se instala sem indexar os
arquivos que foram espalhados: com o tempo eles vão acumulando no
sistema e você nem sabe onde estão e o que fazem, isso gera um "bloat"
no sistema com o tempo. É assim no Linux, é assim no Windows (muito
mais, porque eles não tem controle sobre as milhões de aplicações que
têm de ser instaladas separadas e cada fabricante instala do jeito que
lhe for mais conveniente), é assim com qualquer outro sistema.
Mesmo que você siga o conceito de colocar todos os programas linkados
estaticamente, sempre vai haver um ponto de falha provavel, por
exemplo, você pode instalar uma própria glibc mais nova e quebrar
qualquer chamada de sistema que esses programas utilizam. Ou, tenta
instalar um driver do Windows 98 no Windows XP, sei lá.
> "Para usar todas as ferramentas, ele teve que construí-las especificadamente
> para o seu kernel e uní-las para apresentar ao usuário uma interface para o
> uso do computador. Enquanto o kernel trabalhava com o hardware, as
> ferramentas trabalhavam servindo como ponte entre o usuário e o kernel."
Exatamente ;-)
>> Isto vem de encontro ao que eu escrevi. O conjunto de programas que cria
>> e instala o kernel poderia (eu penso que sim) estar no pacote do kernel, em
>> separado aos pacotes que são usados pelo usuário. A liguagem python é
>> NECESSÁRIA ao kernel e se um usuário remove a linguagem, perde, por exemplo,
>> o yum. Se houvesse um python somente para o kernel e outro instalado para o
>> usuário, não haveria o risco.
>
> Não entendi a parte do "E assim, existiria uma biblioteca C para CADA
> PROGRAMA do sistema. Então cada comando/chamada iria carregar na memória e o
> sistema iria explodir :P", pois a referência poderia ser com uma ligação
> dinâmica ao binário, e não ao binário que será necessário ao kernel.
> É o recurso que o GoboLinux usa, todos os programas binários instalados na
> árvore do Gobo têm uma ligação dinâmica para a árvore original do UNIX, mas
> não estão lá.
É isso que eu quis dizer quando eu pensei que você não sabia muito bem
o que tava falando. Sinto lhe informar, mas o GoboLinux não faz nenhum
milagre não. O que o GoboLinux faz (e que é interessante mesmo) é
re-organizar onde ficam as localizações dos arquivos dos programas e
bibliotecas instaladas no sistema. Isso não elimina de forma alguma as
dependências entre eles. Os programas não são todos linkados
estaticamente. Se você remover algumas coisas, as outras vão pifar.
Sobre a biblioteca C, o que quero dizer é que todo comando/programa
usa essa biblioteca para alocar memória por exemplo. Ela faz a
interface com o kernel. Se você removê-la ou atualizá-la sem cuidado e
sem prestar atenção em todas as aplicações do sistema, você pode
quebrar esse sistema. Felizmente a gente não passa por isso porque as
distribuições cuidam dessa parte mais complicada pros usuários.
Quando se tem um gerenciador de pacotes, não importa a localização dos
arquivos, eles estão sempre indexados e podem ser
removidos/atualizados de forma correta sem deixar resquícios. Por isso
eu sempre achei essa localização de arquivos muito irrelevante.
>> > Creio que o GoboLinux é a salvação do Linux.
>>
>> LOL :-)
>
> Tento esclarecer.
> Não cria uma dependência de um sistema de gerenciamento de pacotes e
> simplifica a inclusão e remoção de programas no SO.
> Você poderá qualquer pacote de fontes e instalar no diretório de programas.
Você pode fazer isso em qualquer distribuição. Sério, sabia que você
pode instalar vários Pythons na mesma máquina? Basta, na hora de
compilar, dizer pra ele instalar numa árvore de diretórios diferente.
Ah, e é isso que o GoboLinux faz. Isso não impede de você fazer
também.
Inclusive, isso me faz lembrar que o próprio Debian faz isso: ele tem
algumas versões múltiplas, o exemplo mais recente que vi foi que você
pode instalar, via gerenciador de pacotes, o php4 e o php5.
>> > Mas vai demorar até uma edição completa com as receitas necessárias à
>> > conversão facilitada.
>> >
>> > Creio que o pessoal do GoboLinux deveria partir para a radicalização,
>> > ELIMINAR a árvore de diretório do *nix e RE-ESCREVER de acôrdo com a
>> > proposta do Gobo.
>>
>> E assim quebrar milhares de programas que são feitos para funcionar de
>> uma forma e ir contra milhares de programadores e padrões do mundo
>> inteiro. Não é a melhor opção.
>>
>> > Penso que o SO deveria ter uma árvore de diretórios EXCLUSIVAMENTE para
>> > o
>> > kernel, onde estariam o fonte do kernel e de TODOS os programas
>> > necessários
>> > para compilação e instalação do kernel.
>>
>> LOL :-)
>
> Por quê o lol?
> Ou você não entendeu?
O LOL foi porque a idéia é muito sem noção (IMO), e por isso eu ri. É
como dizer para o mundo que agora todos os servidores de DNS da
Internet, cada um deles deve ter TODAS as informações sobre todos os
hosts do mundo. Quando você fala um exemplo ou outro, até que não
ficaria tão ruim, assim como se a Internet tivesse 100 domínios. Agora
imagine quando se fala de belos milhões de programas.
Se formos seguir esse padrão que você disse, todo programa deveria ter
suas bibliotecas e dependências todas linkadas estaticamente. Isso, em
sistemas modernos é impraticável, a não ser que você queira perder
espaço e memória exorbitantes. Significaria que cada um dos comandos:
ls, cd, ln, grep, mkdir, rmdir, rm, ping, ifconfig e todos estes mais
simples teriam que ter dentro da sua compilação todas suas
dependências:
madoka:~$ ldd /bin/ls
linux-gate.so.1 => (0xb7f40000)
librt.so.1 => /lib/i686/cmov/librt.so.1 (0xb7f1f000)
libselinux.so.1 => /lib/libselinux.so.1 (0xb7f06000)
libacl.so.1 => /lib/libacl.so.1 (0xb7efe000)
libc.so.6 => /lib/i686/cmov/libc.so.6 (0xb7da3000)
libpthread.so.0 => /lib/i686/cmov/libpthread.so.0 (0xb7d8a000)
/lib/ld-linux.so.2 (0xb7f41000)
libdl.so.2 => /lib/i686/cmov/libdl.so.2 (0xb7d86000)
libattr.so.1 => /lib/libattr.so.1 (0xb7d81000)
Multiplique agora todas essas bibliotecas por milhares de comandos e
milhões de programas por aí. Não seria muito legal né? E quando fosse
atualizar uma dessas bibliotecas? Teria que atualizar centenas ou
milhares de compilações!
O que eu acho que você tá pegando errado é que você só está
considerando a localização dos programas. Onde ficam seus arquivos.
Mas não é só isso que existe por trás de um funcionamento de um
sistema operacional. Tem muita coisa por trás, acho melhor você dar
uma pesquisada nisso (já enfatizei alguns pontos).
>> > Assim, haveria um python e um perl DENTRO do diretório do kernel e
>> > OUTROS
>> > dois para o usuário, assim, não haveria risco de eliminar um programa ou
>> > biblioteca necessários ao kernel quando um usuário ou o próprio root
>> > apagasse alguma coisa.
>>
>> E assim, existiria uma biblioteca C para CADA PROGRAMA do sistema.
>> Então cada comando/chamada iria carregar na memória e o sistema iria
>> explodir :P
>>
>> Não jogue fora todas as vantagens de programas dinamicamente linkados...
>
> Então você não entendeu.
> Não se trata disto, exatamente por validar isto é que sugiro que os
> programas necessários ao kernel devem estar fora da ação do usuário, que
> poderá instalar e remover qualquer programa sem afetar os que são
> necessários ao kernel.
> O kernel fica protegido na memória mas não no HD.
Eu quero ter a liberdade de atualizar meu kernel quando quiser. Não
quero que ele fique fora de minha ação não. Sobre isso, você tem que
reclamar das distribuições que fazem as dependências de pacotes
errôneamente. E acredite, pra algo ter dependência de kernel nas
distribuições atuais, ele tem que *realmente* depender do kernel. Se
um programa tem relação com o kernel diretamente, ou o programa está
errado ou então tinha que ser ligado mesmo, não tem segredo!
Mas pra esclarecer isso, você teria que realmente me dizer exemplos concretos.
A única coisa que eu acho uma grande desvantagem do kernel Linux é a
dependência de módulos do kernel ligados a versão/compilação
específica de uma versão de kernel. Mas esse é outro assunto.
>> > Considero uma grande BURRICE esta COMPLETA dependência do kernel da
>> > árvore
>> > de diretórios do usuário.
>>
>> Ahnnnn???
>
> Posso ter me expressado mal: a dependência do kernel de linguagens e
> programas que estão disponíveis ao usuário para remover.
> Melhorou?
As distribuições definem algo como base do sistema por uma razão: são
aplicações-chave que não devem ser nunca removidos pelo usuário. Eles
tem a liberdade de fazer isso se quiserem (mais uma vez, eu prezo por
essa liberdade), mas se eles fizerem está errado! Aí é culpa do
usuário!
Olha as dependências de um kernel antigo do Fedora 8:
$ rpm -qR kernel-2.6.26.3-14.fc8
rpmlib(VersionedDependencies) <= 3.0.3-1
fileutils
module-init-tools
initscripts >= 8.11.1-1
mkinitrd >= 6.0.9-7
/bin/sh
/bin/sh
rpmlib(PayloadFilesHavePrefix) <= 4.0-1
rpmlib(CompressedFileNames) <= 3.0.4-1
Sinceramente, se o usuário não tiver essas coisas aí, é porque ele não
tem nada mesmo.
Ou seja, a distribuição limita-se ao gerenciador de pacotes.
Você não tem a liberdade de agir fora do que o gerenciador faz, pois o risco de criar uma incompatibilidade com os arquivos instalados pelo gerenciador é grande e você pode perder tudo, como você disse que aconteceu com você (o mesmo comigo, era o que eu tentava dizer e foi exatamente com o glibc).
Eu não disse que uma distribuição é apenas um gerenciador de pacotes, digo que se limita ao limite dêle.
Quanto às ligações dinâmicas, creio que não entendi, ou o que você disse ou o que é uma ligação dinâmica.
Eu vi o seguinte: instalar um programa num diretório independente de ligações dinâmicas e criar as ligações dinâmicas necessárias para a execução do programa nos diretórios de binários e bibliotecas, OU, colocar os caminhos da instalação nova no caminho do SO.
É isto que entendo como "independência" do gerenciador de pacotes, ou seja, uma biblioteca instalada a partir dos fontes de um programa e compilado fora do gerenciador não vai criar uma dependência que afete o SO ou os programas instalados pelo gerenciador quando aquêle for eliminado.
E é isto que eu não vejo acontecer com os gerenciadores de pacotes e por isto reduzi tudo ao mesmo denominador comum: o que um SO não faz fora do gerenciador o torna limitado ao gerenciador, que, afinal, é o que importa.
NÃO se trata de "colocar todos os programas linkados estaticamente", nunca disse isto, ou me expressei mal.
Quanto ao GoboLinux, os programas não são todos ligados dinamicamente, as ligações dinâmicas é que são criadas nos diretórios onde estão os binários do SO.
Os programas do GoboLinux ficam num diretório de Programas e para apagar um programa você simplesmente elimina o diretório. Vão sobrar as ligações dinâmicas nos diretórios dos binários e das bibliotecas, o que facilita a manutenção num sistema Gobo, pois tudo que fôr ligação dinâmica ausente poderá ser apagada pois pertenciam a programas que foram apagados.
Isto será assim até a mudança final da árvore de diretórios, física, o que mudará a árvore do unix completamente.
Não vejo nenhuma idéia louca, o que vejo é que você entendeu mal o que eu disse, ou eu me expressei mal, pelo que me desculpo.
Quanto à independência entre os programas no GoboLinux, sim, isto muda tudo, porque você pode eliminar um programa sem se preocupar com qualquer dependência.
Sim, eu sei que você pode instalar vários programas iguais. A questão não é esta. É que você NÃO pode instalar dois pythons com um gerenciador de pacotes (RPM) porque êle assume que você está instalando o MESMO que êle já conhece e é INDISPENSÁVEL ao SO, no caso do python, por causa do yum, por exemplo, se êle for não-relocável.
E poucos são relocáveis, problema que o GoboLinux resolve com a não-dependência de ligações dinâmicas.
Quanto às compilações dinâmicas serem vantajosas em relação à compilação estática, prefiro a redundância de arquivos e a segurança de poder tirar qualquer coisa a qualquer hora do que ter um pesadelo de manutenção e depender de um gerenciador de pacotes, que VAI falhar.
Pacotes de programas que contêm TUDO são mais seguros, o espaço em disco é cada vez mais barato, como a memória, e o problema passa a ser de desempenho do processador e otimização do código.
Um celeron com linux pode ser melhor do que com ruindous, ou entre dois linux, um compilado para i386 e outro para i586. Do ponto de vista do pacote estático, é indiferente.
"Se formos seguir esse padrão que você disse, todo programa deveria ter suas bibliotecas e dependências todas linkadas estaticamente. Isso, em sistemas modernos é impraticável, a não ser que você queira perder espaço e memória exorbitantes. Significaria que cada um dos comandos: ls, cd, ln, grep, mkdir, rmdir, rm, ping, ifconfig e todos estes mais simples teriam que ter dentro da sua compilação todas suas dependências": sim, porquê não, se espaço e memória não são mais problemas técnicos ou de custo e se o tempo do analista, do programador ou do usuário é que é caro?
E não necessariamente TODOS os programas seriam estaticamente ligados. O problema aqui seria saber em cada programa o quê do SO estaria duplicado para criar aquela compilação dinâmica, mas ainda creio que é mais barato duplicar do que usar o tempo do programador, do analista e, principalmente, do usuário.
Aqui, parece-me, discordamos.
>> > Fica o pedido de socorro para instalar os tais macêtes.
>> >
>> > Com relação ao kernel, minha sugestão é partir para a compilação do
>> > kernel
>> > com o OCAML DUCE.
>>
>> LOL :-)
>
> Nem mesmo uma razão para não fazer ou você não conhece a linguagem?
Não conheço, não posso opiniar. Eu ri porque você está sugerindo criar
um sistema operacional do zero. "Talk is cheap, show me the code".
Não disse isto, mas me sôa meio atrasado.
Johen Kennedy, em 1962, desafiou o povo Estadunidense a levar um homem à Lua, pousar e trazê-lo de volta em segurança antes do fim da década.
É um exemplo de Projeto perfeito.
E êles fizeram.
Só para citar alguém que falava inglês.
Então, fazer uma porcaria de um sistema operacional do zero deveria ser uma OPORTUNIDADE, e pelo visto, você não está á altura do desafio.
Creio que CADA faculdade de TI do .br DEVERIA entrar na corrida pelo SO.br!.
E creio que o SO deveria ser escrito em OCAMLDUCE com C ou assembler no que fôsse necessário.
Ainda mais, a linguagem não importa na maioria das vezes, o que
importa é o programador e seu design de código. Pode ser a linguagem
Se a linguagem não importa porquê você acha que fizeram C para criar o UNIX?
Porquê não foi escrito em BASIC?
Porquê a SUN criou o java para aquecer torradeiras à distância e não usou o pascal para fazer isto?
mais perfeita, um programador ruim pode fazer besteira do mesmo jeito.
Falar que ficaria muito melhor utilizando linguagem X é desconsiderar
todas essas variáveis.
>> É sério, reli meu e-mail e ficou com um tom muito sarcástico... Dei
>> até a entender que sou chato. Mas é, eu sou chato mesmo! :P
>>
>> Sinceramente, você tem umas coisas muito loucas na cabeça, por favor
>> reveja seus conceitos, tem muita coisa que você diz aí que nem parece
>> que sabe do que tá falando :(
>
> Quando o índio que viu a primeira caravela disse aos demais o que via também
> foi chamado de louco e via coisas que ninguém via: e era verdade.
>
> Se você não vê algo que alguém disse que viu não diga que êle é louco, isto
> é rude, mal-educado.
Interpreta-se como quer.
Isto é autoritário.
Eu ainda acho suas idéias loucas. Você pode
não ser louco (e nunca disse isso), mas pra mim tem idéias loucas e
Hein?
equivocadas. Ao invés de achar isso rude e mal-educado, instigue-se,
use a cabeça e prove-me que suas idéias não são loucas! Senão como
você vai convencer o resto do mundo?
Você precisa estudar um pouco mais o idioma falado por aqui.
Sujeito, objeto direto, estas coisas.
Pessoas sadias NÃO têm idéias loucas, loucos as têm.
Eu não tenho de provar nada para você nem para ninguém, não estou aqui para isto.
Estou debatendo um assunto que me interessa, e com você porque já demonstrou ter conhecimento. Mas isto não te dá direitos extras.
Eu não acho nada, sou um cara sem sorte, se não faço ou não compro pronto, fico sem.
Não se desculpe, desculpe-se, não tenho de ser instigado, pois estou, justamente, instigando, e você não aceitou muito bem..... partiu para a loucura ... mandou mudar conceitos ... e se parece que estou dizendo algo que não sei o que é, não te pareceu que poderia ser justamente por isto que estou nesta lista?
> Quando você me manda rever meus conceitos é autoritário e prepotente, aliás,
> "feature" dos unixers, no geral, algo como "se eu fiz, faça, não me enche".
Eu seria autoritário se dissesse "mude seus conceitos". Quando eu falo
"reveja seus conceitos", quero dizer pra você rever mesmo: pensar no
que você tá falando ao invés de continuar falando. E essa "feature" aí
que você disse não é dos unixers, é de qualquer programador idiota. A
grande "feature" do código-aberto é quando a gente faz qualquer coisa,
libera o código e todos podem criticar, opinar e ajudar/atrapalhar.
> Customo dizer que o Unix e o Linux não são Orientados a Usuários tal como
> não são Orientados a Objetos, o que reduz o usuário a objeto sem interêsse.
> Não vejo muita vantagem em usar uma linguagem orientada a objetos em um SO
> procedimental (se é esta a palavra).
O mundo é grande e existem diversos tipos de usuários. O Linux é
orientado para usuários SIM, só não todos.
Então não é!
Se você dissesse que o
Linux não é orientado a usuário "final", eu concordo até certa parte.
Não existem dois tipos de usuários, não existe o "usuário final".
Ou você codifica ou usa o código.
Você é um programador, quando não está fazendo o programa, está "usando" o computador, o que faz de você um "usuário final".
Se você diz que Linux não é orientado a usuário "gamer", eu concordo
100%. Mas tudo isso é relativo não?
Se ISTO é relativo, porquê não AQUILO?
Linux é orientado para os usuários corporativos e para os servidores,
Não existem usuários corporativos, existem um ambiente corporativo.
Os usuários corporativos são os mesmos que qualquer outro usuário, êle usa.
Servidores não são usuários, são máquinas.
Servidores têm usuários.
O Linux NÃO é orientado a usuários, não pensa nos usuários e não é feito para os usuários, é um esfôrço coletivo e vê apenas os usuários que são capazes de participar do esfôrço.
Você quer tapar o sol com uma peneira.
Estamos envidando um esfôrço nôvo, para fazer o Linux ser tolerado pelo usuário "final", que é o comercial, o usuário que compra um produto de TI, enfim, um usuário que não participa da construção do Linux.
mas isso também está mudando: se chama crescimento/expansão.
Infelizmente nosso crescimento nessa área é uma porcaria :)
Concordo.
Você já notou que praticamente nenhuma universidade têm um savane, um GForge um ou um sourceproject?
Parece que a academia não liga a mínima para o mundo da produção de TI.
O mesmo com as SUCESU, não ligam para os usuários, não são focados nos usuários, não investem nos usuários.
As universidades usam o google para fazer pesquisa internamente, nem se dignaram a instalar um glimpse ou um htdig para criar o serviço dentro de casa.
Imagine a quantidade de alunos de TI que poderiam estudar êstes ambientes e não podem fazer porque as instituições investem na inteligência estrangeira e marginalizam a nossa.
Você não se sente um pouco "menos" explorado do que poderia ser, dado o conhecimento que já tem?
>>
>> Eu concordo sobre a parte dos "macetes", mas veja que isso não é
>> problema do Linux. Isso é problema dos fabricantes dos programas
>> proprietários. Esses macetes aí geralmente têm de ser feitos com
>> programas que não fazem parceria com a distribuição, como o Flash e/ou
>> Java. Tenha certeza de que se o mercado de usuários Linux fosse 90%,
>> esses macetes *nunca* iriam ser precisos, pois os fabricantes iam
>> correr atrás.
>>
>> Acredite, nos outros sistemas como Windows e Mac também é assim. A
>> diferença é que eles são o foco principal. Agora vai tentar instalar
>> coisas de Linux em outros sistemas, é mais fácil?
>
> Esclareceu, concordo.
E a única vantagem que a gente tem disso daí é que não existem vírus
eficientes e bem difundidos pra Linux :P
> Obirgado pelos esclarecimentos.
> Não vou recomendar nada a você, não tenho esta postura, lido com a sua. Se
> você não concordar com algo que escrevo, é livre para discordar, e dizer.
> Também é livre para não dizer, mas não tem a liberdade que se deu.
\o/
Saudações.
--