A resposta é modularidade e simplificação de manutenção, pois se as configurações forem divididas em arquivos (que no caso são sessões) será muito mais simples e direto manter uma boa configuração sem afetar outros módulos de forma drastica.

Isso foi usado tanto no apache2 quanto na troca do inittab e realmente funcionam e tornam o processo de configuração muito mais simples e independente, tanto para ser alterado manualmente (já que você só esta trabalhando em apenas uma área da apliação e não em todas ao mesmo tempo) quanto para ser alterado via automatizadores (como o Yast2 por exemplo), neste caso esse tipo de sistema evita um monte de dores de cabeça futuras, claro que para se acostumar a principio é complicado, já que você vai procurar por aquelo que já conhece e não encontra e dessa forma se vem a resistencia a novos modelos tecnológicos.

A mesma coisa aconteceu com a orientação a objetos, interface gráfica, mouse, monitor, internet, voip e entre tantos outros, o papo é sempre o mesmo, já que muitas vezes os envolvidos não entendem da tenologia ou do conceito e vantagens no que resulta concerteza na discurção interminável de “pra quê isso?” sem ouvir o quem está explicando.

Espero que esse conceito der certo assim como deu com o conceito do apache2 para simplificar a manutenção e reduzir o excesso de dore de cabeça causado pela perda do único arquivo.

@tenchi

Pelo que me consta o Unix não veio com a idéia de ser simples, mas de ser multiplataforma, multiusuário, seguro e ser modular, por essa razão se existia sempre o uso de arquivos de configuração editaveis.

No caso de tudo em um só lugar nem sempre quer dizer seguro ou simples, já que quem tem acesso a este arquivo está com todo um sistema em suas mãos, no caso fez merda vai ter um baita trabalho para concertar, mas no caso de várias áreas divididas em arquivos distintos, caso faça merda em um arquivo só vai precisar concertar aquele arquivo, além de que esse processo poderá ser automatizado de forma mais segura, pois muitas vezes é sabido que em arquivos de configuração geralmente se faz a mesma coisa com pequenas alterações, que acabam demandando tempo sem necessidade, já modularizando é possível para o desenvolvedor ou administrador automatizar melhor a manutenção de forma mais dedicada ou criando scripts ou criando programas, neste caso o processo fica mais seguro e mais simples.

Geralmente quem usa Slackware é muito conservador, até mesmo o pessoal critica o GRUB pelo LILO sem saber das vantagens do GRUB, só porque o LILO veio antes, independente do valor tecnológico do mesmo, eu também fui usuário do Slackware e gostei muito do sistema, mas aquele conservadorismo todo começou a me deixar muito distante das novas tecnologias promissoras, me dando a impressão que estou vivendo na idade média quando dizer que a Terra é redonda é acusado de bruxaria e deveria ser queimado na fogueira.

Até o Subversion que veio para substituir o CVS foi criticado sem ver as vantagens que este tinha em relação ao CVS, até Linus diz que CVS é um torrador de cerebro e concordo com, pois o Subversion realmente torna o controle de versão mais agradável e mais simples, com menos dores de cabeça, a configuração do CVS é de podre de complicada além de sempre dar muita bronca, nem suporte a binário o CVS possui e o sistema é todo feito por scripts, ai veio o pessoal do BSD e criou o Subversion com apenas um único objetivo substituir o CVS ai vem a resistencia e diz o Subversion é uma merda sem saber do que está falando, peraí pessoal, para mim isso não é nem administrador de sistemas e nem programador ou é um usuário comum ou é um DBA.

NOTA DE CURIOSIDADE: Sabiam que a impressa foi criada na época da Idade Média, contudo seu criador nunca havia divulgado por medo de ser queimado na fogueira.

Assim penso que não é muito difícil para o X saber quais as características da maioria dos monitores hoje (até aqueles que tem o selo “compatível com windows 3.11,95,98,Me,200,XP,Vista…” :-)).

Mas a questão é: default significa “quando tudo mais falhar”, e muitas vezes queremos mais que o default. É aí que entram os ajustes manuais que automágica alguma resolve. É como comparar algo feito numa linha de produção com algo que você teve o maior trabalho para fazer manualmente, único. Tá, exagerei na comparação :-)

Como eu disse n vejo problema nenhum em facilitar as coisas, mas como alguns aqui ja disseram o lance n é facilitar e sim manter a opção. Imagine vc com um hardware q o programa n detecta certas caracteristicas q vc quer e aí vc vai no arquivinho depois de ler a documentação e descobre q n tem mais… É de deixar qualquer um louco. Claro q é bom as coisas funcionando altomaticamente, mas e se n funcionar? Como vc faz? Cade a outra opção.

O q eu n entendo é q isso ja se faz hj. A maioria das dristros detectam o hardware legal e ja deixam bem configurado, mas aí q vem a sacada: se vc tiver alguma coisa a mais q queira fazer tem como. Mas e se o xorg.conf sumir vai ficar como? Vai mudar pra xorg2.conf? Aí n muda nada… a vai mudar de lugar? Tb n muda nada. N vai ser dividido… sim, mas na pratica tb n muda muito. Só complica. A n ele realmente vai desaparecer. Aí me desulpem, mas é exatamente o q n se deve fazer.

(…) O tempo se encarregou de gerar o esquecimento e um dia, seguindo esse novo modelo, o xorg.conf também deverá ser esquecido.

Exatamente esse o problema -> todo mundo aceita passivamente o que lhe é imposto sem reclamar e no final se esquecem e acham tudo normal. Infelizmente.

MAS EU SOU DA RESISTÊNCIA E NÃO ME ENTREGO JAMAIS!

E VIVA A FILOSOFIA KISS :-D

Como foi dito, o “medo” não é que que surja uma nova forma de configuração do X (quanto mais possibilidades, melhor, afinal não estamos no Windows), mas sim que acabem com as “formas clássicas” de fazer as coisas.

O Unix originalmente era feito para ser simples, tudo guardado em arquivos textos e de fácil manipulação. O Linux ainda se utiliza muito disto. Novas formas não devem implicar no fim das formas antigas.

Ah, e integrar o X com o HAL é excelente. Assim, na melhor das hipóteses, cada coisa faz o que tem q fazer: o HAL cuida do hardware e o X de “exibir pixels na tela”. Mas há quem não goste do HAL (ou do consolekit, aquela coisa que até hoje não sei para que serve), pois muitos destes daemons ocupam muita memória e processamento, coisa complicada em máquinas antigas.