[Fedora-users-br] Atualizar o FC10 i386 com x86_64

Marcio Carneiro viabsb em gmail.com
Domingo Abril 5 19:25:12 UTC 2009


2009/4/4 Hugo Cisneiros (Eitch) <hugo em devin.com.br>

> 2009/4/4 Marcio Carneiro <viabsb em 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.
>
> Você falou que não existe uma distribuição e sim um gerenciador de
> 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.

>
> --
> []'s
> Hugo
> www.devin.com.br
>
> --
> Fedora-users-br mailing list
> Fedora-users-br em redhat.com
> https://www.redhat.com/mailman/listinfo/fedora-users-br
>



-- 
EquipeLinux em EquipeLinux.com
EquipeLinux em Skype.com
-------------- Prxima Parte ----------
Um anexo em HTML foi limpo...
URL: http://lists.fedoraproject.org/pipermail/br-users/attachments/20090405/a4241f5a/attachment.html 


Mais detalhes sobre a lista de discusso br-users