Re: [Fedora-users-br] Evolução do Linux

[Heitor Moraes]

Nem me dei o trabalho de ter a thread toda, mas ai vai minha
experiência com Mac.

Originalmente o MacOS era um sistema simples e leve.
Não havia preocupação com segurança, e a grande diferença entre ele e
o Windows, é que o Mac já nasceu gráfico, não herdando abstrações do
terminal de texto.

O OSX, cujo coração é um BSD, era capaz de rodar, quando sobre
PowerPC, uma versão do MacOS clássico.
Isso permitiu rodar aplicações antigas durante anos, depois a Apple
matou o suporte ao MacOS clássico.

Esse novo Mac, baseado em Unix, tem 10 anos. O OSX cresceu e ficou
bonitão, mas por baixo roda Apache, SAMBA, OpenSSH.
Tudo que a Apple faz é montar um SO com uma Gui própria e com uma base
sólida fortemente modificada de um SO pré-existente.

Essa base sólida é bastante segura, mas para permitir as customizações
de configuração e interface feitas pelo usuário, o MacOSX acaba não
sendo assim tão sólido.

Tudo lembra muito o uso do sudo no Ubuntu, e o comportamento do Ubuntu
com relação ao Debian.
Mas de fato, a chance de provocar um rombo com um shell script enviado
como anexo, no OSX, é bem grande, tamanho o número de usuários com
permissão de administrador e sessões do sudo abertas.

Acredito que a fraqueza nas permissões e o uso demasiado do sudo sejam
as maiores fraquezas do OSX.
Os buracos do Safari vão acabar sumindo com a criação dessas sandboxes
nos browsers modernos, mas esse modelo administrativo falho e
permissivo está viciando usuários que poderiam desde já aprender a
cuidar do computador, como cuidam do carro ou da casa.

2009/4/5 Leonardo Pinto (Gmail) <leonardoprc em gmail.com>:
> Antes de julgamos as questões alheias é preciso examinar o ponto de vista
> das pessoas, de cada um. As vezes achamos insano um pensamento pelo simples
> fato do conceito prévio (do vulgar - preconceito). A máxima do índio que
> avistou as caravelas, realmente descreve muito bem as situações de TODOS
> aqui. Percebo que o exposto pelo companheiro Marcio Carneiro tem muito em
> comum com os meus expostos. Porém antes de julgar que o Linux tem um
> conceito errado/diferente (olha o preconceito novamente aí), é preciso
> entender os motivos que o leva a essa concepção. Depois de compreender, fica
> até mais sensato criar sugestões e mais inovações.
>
> Pontos em comum: Constatei que essas inconformações com o Linux vem se
> generalizando (prova é o Gobo). De fato o Linux é concebido muito mais para
> servidores do que para estações, e ótimo no que faz e na forma que faz com
> servidores. Apesar das estações ficarem muito mais seguras com o conceito de
> servidor, afinal toda estação é um servidor em potencial. Mas para ser
> estação inegavelmente precisa ter acessibilidade e praticidade de uma
> estação de trabalho. Percebí e constatei então que tudo que Eu vinha
> idealizando de novo num Linux ENCONTREI JÁ PRONTO no Mac!!! A proposta Gobo
> é bem parecida com o Mac, e olha que ele nem fez questão de esconder suas
> raízes Unix/BSD. O que ele fez: Deixou o Kernel, árvore de diretório e seus
> binários como parte Núcleo do SO, e a parte GUI do usuário que quer mover,
> remover como quiser e bem entender deixou em /Applicattions. Foi simples
> assim!!! Claro que tem outras facilidades e modificações a mais...
>
> Foi genial a sacada da Apple. E acredito que mesmo com essas pequenas e
> notórias modificações o MacOSX Server não deixou de ser um Unix e conter
> nele toda segurança intrínseca. Pelo simples fato de ter ficado mais
> acessível ao usuário final. Por isso que os leigos sempre acham que o Linux
> é feito de programa-dores para programa-dores...
>
> O Linux precisa mesmo se encontrar. Ou separar o joio do trigo, ou atender
> bem suas segmentações de usuário.
>
> Pessoal, são boas referências!!! O MacOSX é um meio termo e é a prova viva
> de que não precisa nem ser um Rwindows e nem ser um Linux, para ser um
> Sistema Operativo que verdadeiramente agrade e atenda gregos e troianos. Um
> Unix muito mais acessível e muito porém bem seguro. (HAY QUE ENDURECER, PERO
> SIN PERDER LA TERNURA JAMÁS!) :-P  ;-) 8-)
>
>
>
> PS: Antiga trhead Re: [Fedora-users-br] Atualizar o FC10 i386 com x86_64 e
> Re: [Fedora-users-br] Sobre o KDE 4.x
>
> --
> Leonardo Pinto
> leonardoprc#gmail dot com
>
> Marcio Carneiro escreveu:
>
> RUINDOUS
>
> Falar em polimorfismo no ruindous é uma inconsistência dimensional:
> aquilo roda em um sistema operacional por disco, em 16 bits, faz
> multi-tarefas compartilhadas (pelo tempo de idle) e não tem nada
> orientado a objetos.
> Aliás, uma linguagem orientada a objetos ser executada num SO
> procedimental é puro desperdício de energia.
> Nada no programa fala com o SO e não tem nada no SO à disposição da
> linguagem.
>
> KDE x KDE
>
> Em minha opinião, o KDE3 é o KDE e o KDE4 é outra criatura.
> Não existe evolução em programas e SSOO: existe alteração.
> Veja-se a árvore de diretórios do UNIX, que é irracional, e nunca mudou.
> Mando, aqui, meus mais sinceros votos de congratulações ao pessoal do
> GoboLinux, pela coragem de mudar, e pela qualidade de melhorar.
> Estou de ôlho na distro e espero que nunca se torne uma distro.
> Sugiro que façam duas edições: uma com a árvore do UNIX e com as
> receitas, e outra, SEM a árvore do UNIX, o que será um fator de
> segurança adicional.
> Sugiro, também, que êles usem uma edição do Fedora, abram, usem as
> receitas em tudo e liberem para o Gobo.
>
> OS SISTEMAS DE GERENCIAMENTO DE PACOTES
>
> O Linux é um kernel, as distros são o que os Gerenciadores de Pacotes
> permitem.
> Não tem nada no UNIX ou no Linux Orientado a Usuário.
> Evoluir é tornar-se orientado a usuários e a objetos, ou seja,
> escrever o kernel com OCAMLDUCE ou ObjectiveC, e isto não vai ser
> feito pelo simples fato que os codificadores dos Linuxes estão em um
> corrida pela última "feature" e esquecem que não existe absolutamente
> nenhuma vantagem significativa em usar o KDE 1 ou 4, pelo simples fato
> que nenhuma necessidade dos então usuários do KDE1 evoluiu para
> qualquer outra coisa, para que êles criassem o KDE4, para "atender" ao
> usuário.
> Concordo, estou usando o gnome por não desejar me submeter ao que os
> codificadores "pensam" que é a "evolução" do KDE, e por enquanto tenho
> o KDE instalado por algumas boas idéias, como o konqueror, knotes (vou
> mudar para um wiki - TWiki).
> São bem poucas as características do KDE não-disponíveis no gnome para
> eu escolher o KDE, uma escolha, aliás, que já havia feito e estou
> mudando.
>
> QUEM SABE UM UNIX É MELHOR DO QUE UM alike?
>
> Para falar a verdade, estou considerando seriamente o OpenBSD com
> gnome, pois o Linux se tornou sinônimo de Sistema de Gerenciamento de
> Pacotes, que é o que realmente funciona (e mal) numa distribuição, que
> se resume, ao final, ao que o Sistema de Gerenciamento de Pacotes faz.
> Se você apaga uma biblioteca necessária para o SO, você não consegue
> mais recuperar o que saiu e não consegue atualizar o SO, pois êle
> reclama de duplicidade ou simplesmente não deixa você instalar um SO
> igual, tem de atualizar para uma versão maior, do FC9 para o FC10, por
> exemplo.
> Se eu disser que evoluir é "isto" e um codificador do KDE disser é
> "aquilo", não há a menor diferença: não há nenhuma evolução em nenhuma
> das assertivas.
> O codificador não fêz o KDE que EU quero e não vai fazer. Podemos,
> como usuários, concordar em muito com o que os codificadores do KDE
> fazem (ou do gnome), mas não significa que êles me atenderam e
> signfica que me entenderam.
> Se êles tivessem a humildade de componentizar o KDE e o GNOME, de modo
> a que uma característica nova não interfira no conjunto, então
> estariam pensando nos usuários, do contrário, estão pensando nêles
> próprios, em como são grandes codificadores e em como os usuários são
> reacionários e contra-revolucionários, ou seja, o KDE é marxista ou
> católico ou evangélico ou ....whatever... e os usuários são o
> demônio....
> O fato do gnome andar devagar é o seu grande mérito. Tem tempo de
> respeitar os usuários e não nos põem a correr atrás das "features",
> inúteis como as bugigangas a que se refere o De Masi quando critica o
> consumismo de produtos inúteis que agregam estresse e desperdiçam a
> energia humana em produzi-las.
> Quanto às futilidades, tudo que não tem uso para um usuário É uma
> futilidade e não deveria estar ali para atrapalhar, o que reforça
> minha visão de que um SO e seus ambientes gráficos devem ser
> componentizados de forma a permitir tirar o que se quiser tirar sem
> comprometer o SO.
>
> PORQUE NÃO UM KERNEL e UM SO?
>
> Na minha opinião, deveria haver uma árvore de diretórios somente para
> o kernel (do root) e outra para os usuários (o /home), onde o usuários
> poderia instalar QUALQUER programa SEM interferir com os programas
> necessários ao kernel.
> Assim, haveria um python para o kernel e OUTRO para o usuários, de
> modo que se um usuários retirasse um dos programas que são (hoje)
> necessários ao SO, não perderia nada, pois os que o SO realmente usa
> estariam protegidos na árvore do kernel.
> Dêste modo, o kernel seria o kernel propriamente dito MAIS tudo o mais
> necessário para gerar, editar compilar e instalar o kernel, em um só
> pacote e à parte do restante do SO.
> Mas isto é o que um usuário quer, e nenhum codificador liga a mínima
> para mim ou para o que eu quero.
> Não tem muita diferença entre o Linux (as distros) e o ruindous, pois
> nenhum é Orientado a Usuário, e sou um usuário.
> ... por enquanto....
>
>
>
> Marcio Carneiro escreveu:
>
> 2009/4/3 Hugo Cisneiros (Eitch) <hugo em devin.com.br>
>>
>> 2009/4/3 Marcio Carneiro <viabsb em gmail.com>:
>> > O problema são os tais "macêtes".
>> > Você tem um passo-a-passo para fazer a instalação do flash, java,
>> > mplayer,
>> > vlc e outras bugigangas no CentOS 5 e Fedora 10. por exemplo?
>>
>> Tem vários por aí na Internet.
>
> Obrigado.
>>
>>
>> > 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.
>>
>>
>> > 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.
>>
>> > 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.
>>
>>
>> > 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.
>>
>>
>> > 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.
>
> "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."
>>
>>  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á.
>>
>>
>> > 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.
>
>>
>>
>> > 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?
>>
>>
>> > 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.
>
>>
>>
>> > 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?
>
>>
>>
>> > 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?
>>
>>
>> É 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.
>
> 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".
>
> 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).
>>
>> 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.
>
> 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.
>
>
> Hugo Cisneiros (Eitch) escreveu:
>
> Meu deus, que viagem, novamente... :P
>
> --
> Fedora-users-br mailing list
> Fedora-users-br em redhat.com
> https://www.redhat.com/mailman/listinfo/fedora-users-br
>
>