Ir para o conteúdo
  • Revista PROGRAMAR: Já está disponível a edição #60 da revista programar. Faz já o download aqui!

cybervitor

Vantagens e Desvantagens de um S.O. Gráfico?

Mensagens Recomendadas

cybervitor

Boas, estou a fazer um trabalho sobre Ambientes grafico, e precisso de saber quais a principais vantagens de um SO grafico, o problema é que não tenho expriencia quase nenhuma com SO's em linha de comando, logo não sei o que é melhor ou pior.

Obrigado

Partilhar esta mensagem


Ligação para a mensagem
Partilhar noutros sites
M6

Não se pode dizer que um seja melhor ou pior do que o outro.

Têm é características distintas que servem de forma, melhor ou pior, certos propósitos.

Por exemplo, num SO puramente gráfico a optimização de tarefas através de scripts é, tipicamente, impossível, em especial quando o resultado de um comando é usado como informação de input do comando seguinte.

Este era um problema grave e real que o Windows tinha até há umas versões atrás, onde automatizar algumas operações era algo impossível.

Por outro lado a utilização de um SO não gráfico não permite uma visualização de informação de forma tão confortável e por vezes rica. Um exemplo um preview do conteúdo de um ficheiro, por exemplo quando seleccionamos ou passamos com o rato por cima, é uma funcionalidade que não acontece numa interface de linha de comando. Ou algo mais simples, podermos fazer scrool vertical e horizontal para consultarmos mais informação, e. g. quando estás a ver o conteúdo de um directório.


10 REM Generation 48K!
20 INPUT "URL:", A$
30 IF A$(1 TO 4) = "HTTP" THEN PRINT "400 Bad Request": GOTO 50
40 PRINT "404 Not Found"
50 PRINT "./M6 @ Portugal a Programar."

 

Partilhar esta mensagem


Ligação para a mensagem
Partilhar noutros sites
apocsantos

    Eu pessoalmente prefiro usar linha de comandos. Questões de habitos. Mas tenho de concordar com o M6, o Ambiente Grafico dá outro conforto para tarefas "rotineiras", e parece ser mais eficiente no uso em desktop, também pelas facilidades que a GUI permite. Não deves imaginar o "trabalhão" que era formatar um texto em Display Write 4, ou outros do genero.

    Agora no que diz respeito a servidores a interface grafica parece "um peixe meio fora de agua". Todos ou quase todos os administradores de sistemas gostam de usar os seus scripts, usar a sua forma de fazer as tarefas, etc... muitas vezes os parametros de um script são o outuput de outro script.

    Em suma não existe melhor nem pior, existe "mais ou menos" adequado a cada tarefa.

Cordiais cumprimentos


"A paciência é uma das coisas que se aprendeu na era do 48k" O respeito é como a escrita de código, uma vez perdido, dificilmente se retoma o habito"

Partilhar esta mensagem


Ligação para a mensagem
Partilhar noutros sites
IceBrain

Actualmente há muito poucos SOs, principalmente para PC, que não ofereçam um ambiente gráfico, por isso um "SO não gráfico" é algo raro. Até porque nos SOs actuais o ambiente gráfico já não corre no Kernel, e sim em userland. Aliás, em Linux até já é possível correr um ambiente gráfico a partir de uma conta normal, sem permissões de root.

Por outro lado a utilização de um Ambiente gráfico não impede o uso de scripts e programas "textuais", visto que há quase sempre emuladores de terminais (cmd.exe no Windows, dezenas em Linux, Terminal em MacOSX, etc).

Eu por exemplo raramente "saio" do ambiente gráfico, e no entanto dos oito programas que estou a correr, só o Firefox corre fora de um emulador de terminal.

Acho que a única distinção que se pode fazer é mesmo entre programas com e sem GUI.


❝The idea that I can be presented with a problem, set out to logically solve it with the tools at hand, and wind up with a program that could not be legally used because someone else followed the same logical steps some years ago and filed for a patent on it is horrifying.❞- John Carmack on software patents

A list  of command line apps

Partilhar esta mensagem


Ligação para a mensagem
Partilhar noutros sites
IRX773

Eu sou mais novo e comecei mais tarde nestas andanças mas pessoalmente detesto coisas muito bonitas e a mecherem-me muito. Muita multimédia num pc para alem de lhe comer recursos (dependendo da GUI que se usa) há sempre tarefas que por muito que se tente usar uma GUI tem de se usar sempre a linha de comandos.

Pessoalmente comecei em GUI's e sou da "geração GUI" pois já não apanhei os SO's em modo texto mas adoro a linha de comandos e prefiro usa-la a usar uma GUI. É claro que há coisas que por muito que seja possível (embora limitado) fazer-se na linha de comandos como um browser em modo de texto é mais simples e muito melhor usar uma GUI.

Por exemplo em Ubuntu instalar aplicações e pacotes atravéz de uma GUI, na minha opinião, é uma grande treta.

Mas isto são opiniões pessoais, embora também ache que um admin de servidores e de sistemas prefere a linha de comandos.

Partilhar esta mensagem


Ligação para a mensagem
Partilhar noutros sites
falco
Não deves imaginar o "trabalhão" que era formatar um texto em Display Write 4, ou outros do genero.

Nunca utilizei esse processador de texto, mas esse caso particular não faz com que processar texto em terminais de texto seja mais difícil e trabalhoso... Isso depende muito da ferramenta que utilizares e do conhecimento e experiência que tiveres a utilizar as ferramentas.

Os GUI fazem (se forem bem desenhados) é com que a curva de aprendizagem na aprendizagem de tarefas possa ser menor. E que o desempenho de pequenas tarefas não repetitivas seja mais rápido para os que não têm experiência, ou muita experiência na utilização de computadores. Contudo alguém com experiência de utilização de ferramentas de modo de texto, pode com as ferramentas adequadas ser muito mais produtivo com essas ferramentas do que com ferramentas gráficas. Para além disso há sempre tarefas em que a diferença entre utilizar um tipo de interface, ou o outro não tem diferenças significativas na produtividade e ainda os casos em que as ferramentas de modo de texto são mais produtivas (na maior parte dos casos estas estão associadas a tarefas de maior complexidade técnica).

Até porque nos SOs actuais o ambiente gráfico já não corre no Kernel, e sim em userland.

Isso é algo que não acontece à muito tempo em sistemas operativos de propósito geral.

Aliás, em Linux até já é possível correr um ambiente gráfico a partir de uma conta normal, sem permissões de root.

Dito dessa forma a pessoas que não estejam a par da questão e que tenham menos conhecimentos técnicos, podem eventualmente pensar que em GNU/Linux (nunca no kernel Linux), só era possível utilizar o ambiente gráfico com a conta de root, ou com outra com as mesmas permissões. Por isso aqui fica o esclarecimento suplementar para os menos informados apesar de ter sido utilizado o verbo correcto ("correr"):

Não é, nem nunca foi o caso do GNU/Linux que o ambiente gráfico só pudesse ser utilizado pelo utilizador root. E faço notar a diferença, que o Icebrain expressou mas sem vincar, entre o utilizador que utiliza o ambiente gráfico e o que corre o servidor X. No caso do X ele corria e ainda corre em quase todos os casos com a conta de root, mas o X não é todo o ambiente gráfico. O ambiente gráfico ainda tem muitas outras coisas como por exemplo o window manager, que corre sempre com as permissões da conta do utilizador humano do ambiente gráfico e muitas outras aplicações que por vezes suplementam o window manager, muitas vezes ao ponto de criar um ambiente de desktop como o gnome e kde.

Por exemplo em Ubuntu instalar aplicações e pacotes atravéz de uma GUI, na minha opinião, é uma grande treta.

Discordo totalmente desse exemplo. O Synaptic e o Install and Remove Applications, são extremamente fáceis e práticos de utilizar, para além de que graças ao gdebi, instalar o um pacote que já esteja no sistema de ficheiros poder ser feito chamando o gdebi (dois clicks em cima do pacote) e o gdebi instala o pacote resolvendo dependências (recorre aos repositórios do APT). Não existe nada melhor que isto em termos de instalação de software em ambientes gráficos.

Quanto a vantagens e desvantagens, depende muito do propósito de cada instalação, por exemplo, na minha opinião não faz sentido um servidor ter ambiente gráfico, pois é mais carga e mais código (e por isso mais bugs e mais software para ser gerido no servidor), já num desktop, acho que não faz sentido haver desktop sem ambiente gráfico, mesmo que também se usem terminais se forem necessários, ou se forem preferidos para alguma coisa.

Partilhar esta mensagem


Ligação para a mensagem
Partilhar noutros sites
apocsantos

    O Display Wirte 4 até era jeitozinho para a epoca. Eu trabalhei muito com ele, tive formação nele e dei formação dele. Sincaremente quando apareceu o Works para Windows 3.1 foi uma quase "dadiva" para quem utilizava o DW4.

    Não estou muito a par de processadores de texto em modo de texto porque utilizei maioritáriamente 2, o Works, e o DW4. Entre um e outro "que viesse quem quizesse escolher". Ambos tinham os seus pontos fracos e fortes.

    No modo geral sempre fui entusiasta das linhas de comandos, estou habituado à linha de comandos, consigo fazer o mesmo trabalho que posso fazer numa GUI em menos de metade do tempo em linha de comandos.

    Ainda assim cada um tem as suas vantagens e desvantagens dependendo da utilização a dar.

Cordiais cumprimentos


"A paciência é uma das coisas que se aprendeu na era do 48k" O respeito é como a escrita de código, uma vez perdido, dificilmente se retoma o habito"

Partilhar esta mensagem


Ligação para a mensagem
Partilhar noutros sites
cybervitor

Muito Obrigado a todos, acho que já tenho material suficiente para o trabalho, e até aprendi alguma coisa, pois como o IRX773, tambem sou da geração GUI, não tinha muitas noções sobre os SO de texto.

Cumprimentos

Partilhar esta mensagem


Ligação para a mensagem
Partilhar noutros sites
IceBrain
Isso é algo que não acontece à muito tempo em sistemas operativos de propósito geral.

Bem, em Linux foi sempre o que aconteceu, segundo sei. Pelo menos o XFree86 já seguia esse modelo, e depois o Xorg seguiu-o; que eu saiba nunca houve um ambiente gráfico integrado no kernel.

E mesmo o Mac acho que já é separado desde o Mac OS X, que já faz oito anos em 2010.

O único que se mantinha "no passado" era o Windows, mas segundo li no Vista isso foi bastante alterado.

Dito dessa forma a pessoas que não estejam a par da questão e que tenham menos conhecimentos técnicos, podem eventualmente pensar que em GNU/Linux (nunca no kernel Linux), só era possível utilizar o ambiente gráfico com a conta de root, ou com outra com as mesmas permissões. Por isso aqui fica o esclarecimento suplementar para os menos informados apesar de ter sido utilizado o verbo correcto ("correr"):

Não é, nem nunca foi o caso do GNU/Linux que o ambiente gráfico só pudesse ser utilizado pelo utilizador root. E faço notar a diferença, que o Icebrain expressou mas sem vincar, entre o utilizador que utiliza o ambiente gráfico e o que corre o servidor X. No caso do X ele corria e ainda corre em quase todos os casos com a conta de root, mas o X não é todo o ambiente gráfico. O ambiente gráfico ainda tem muitas outras coisas como por exemplo o window manager, que corre sempre com as permissões da conta do utilizador humano do ambiente gráfico e muitas outras aplicações que por vezes suplementam o window manager, muitas vezes ao ponto de criar um ambiente de desktop como o gnome e kde.

Exacto, obrigado por teres esclarecido, às vezes assumo de mais ;)


❝The idea that I can be presented with a problem, set out to logically solve it with the tools at hand, and wind up with a program that could not be legally used because someone else followed the same logical steps some years ago and filed for a patent on it is horrifying.❞- John Carmack on software patents

A list  of command line apps

Partilhar esta mensagem


Ligação para a mensagem
Partilhar noutros sites

Crie uma conta ou ligue-se para comentar

Só membros podem comentar

Criar nova conta

Registe para ter uma conta na nossa comunidade. É fácil!

Registar nova conta

Entra

Já tem conta? Inicie sessão aqui.

Entrar Agora

×

Aviso Sobre Cookies

Ao usar este site você aceita os nossos Termos de Uso e Política de Privacidade. Este site usa cookies para disponibilizar funcionalidades personalizadas. Para mais informações visite esta página.