| Esta discussão foi arquivada. Não se pode acrescentar nenhum comentário. | | | ...o facto de já se poderem descarregar modulos mesmo que ainda esteja a ser usados .. Também gosto do novo Qconfig (make xconfig) e futuramente existirá uma versão homologa para gtk . Segundo me parece (pelo que li), a nivel do desktop não se irão notar grandes melhorias .. até pelo contrário.
|
| | | | | | Estou a correr o 2.4.19 com o preemptive patch. Nota-se uma melhoria significativa na resposta do sistema, tanto a nivel de gestao de discos (operacoes massivas no disco nao prendem o rato e a gravacao de CDs 'on-the-fly' teve ~40% de aumento de performance nas minhas maos) como a nivel do X, que passou a ser mais suave em quase todas as operacoes.
Claro esta, esta suavidade so leva a um sistema com maior usabilidade, regra geral nao se traduz num aumento de performance bruta.
--- "Esta voz!?!..." Cpt Francis Blake -- S.O.S. Meteoros |
| | | | Tb estava a correr-lo antes de o disco ter dado o pifo de vez... (IBM DTLA....)
Em relação ao unload dos modulos acho que uma das coisas que mais me chateia neste momento no linux é isso principalmente com os modulos que tenho usado como é o caso dos que fornecem suporte ao DVB que ainda não estão a 100% e que de vez enquando la se lembram de ficar empenados la na coisa. Mas notasse realmente um melhoramento bastante bom com o preemptive a correr.
|
| | | | | ...o facto de já se poderem descarregar modulos mesmo que ainda esteja a ser usados .. Como e' que o kernel descarrega um modulo que esta' a ser usado ? Se for por outro modulo podes fazer um unload recursivo baseado nas dependencias, mas se o kernel monolitico precisar da funcionalidade de um modulo nao estou a ver como e' que se consegue descarregar...
"Monogamy is for guys that can't get pussy." --Steve-O.
|
| | | | nao estou a ver como e' que se consegue descarregar...
À força :-) A ideia é resolver aquelas situações em que os modulos NÃO estão em uso, mas o kernel está convencidíssimo que sim. (já me aconteceu algumas vezes). Claro que, a partir do momento em que a funcionalidade existe, o administrador precisa de ter um bocadinho de cérebro, senão começamos a ter situações do género:
root - rmmod --force eth0
Ethernet - "Olá? Oláaaaaaaa? Sistema operativo, estás aí? Sou eu, a placa de rede! Tenho uns pacotes para ti!"
Linux - "Ei! Onde é que se meteu aquela gaja? Tou à espera do resto do DivX!"
Ethernet - "Buah! Ele não me liga!" *ppppffffttttt* *burn*
Linux - "Bah, não estou aqui a fazer nada, vou-me embora *beep!* *crash*
|
| | | | | À força :-) A ideia é resolver aquelas situações em que os modulos NÃO estão em uso, mas o kernel está convencidíssimo que sim. (já me aconteceu algumas vezes). Hummm... nesse caso acho que faria mais sentido melhorar o sistema de dependencias do kernel do que forcar a coisa... just my 2 cents... ;-) PS: o Solaris por exemplo e' perfeito neste aspecto. Nunca vi um kernel modular que nao carregasse/descarregasse modulos na perfeicao e sem "apodrecer" o kernel.
"Monogamy is for guys that can't get pussy." --Steve-O.
|
| | | | Desculpem lá qualquer coisinha... Mas foda-se! O gajo fala na implementação de modularidade e vocês respondem com aplicações de userland? Que raios tem uma merda a ver com a outra?
Se querem deitar abaixo, tentem usar argumentos minimamente inteligentes; Estes 2 últimos comentários são um desperdício de tempo e bits.
|
| | | | No aspecto da dependência de módulos, pelos vistos, é.
Jazzy |
| | | | código SMP, threading, MM, escalabilidade em sistemas de grande porte(16/32 cpus e sup) .... enfim.. em muitas coisas .. está muito à frente.. no doubt!
Miguel F. M. de Sousa Filipe
handle: m3thos
email: mmsf@rnl.ist.utl.pt
More Human than Human.
|
| | | | | Lamento discordar, mas o 2.5.x traz grandes melhorias para maquinas pessoais/pcs normais. E', alias, a unica versao ate' agora que procurou acrescentar facilidades visadas a uma melhor utilizacao por parte de um utilizador normal. Ora vejamos: - preemptive kernel + scheduler O(1) + melhorias na memoria virtual: menor delay, os processos nao ficam muito tempo sem correr, etc, o que ajuda em jogos, som, trabalho normal num ambiente grafico.
- swsusp: software suspend, equivalente a hibernacao. Em vez de deixar o pc ligado com os trinta terminais, 15 browsers e 3 muas, porque nao suspender?
- alsa: possibilidade de usar todos os canais de som, uso simultaneo por varios programas (OSS dependia do driver), etc.
- Alteracao dinamica da velocidade do processador: poupanca de bateria em andamento ou velocidade maxima (em portateis)
- ACPI: controle das accoes a realizar pelos varios "botoes", varios niveis de reducao de consumo.
- Input: juncao de teclado ps2, rato serie, rato ps2, rato usb, teclado usb, etc, numa unica interface.
(Muitas destas alteracoes estao disponiveis independentemente para o 2.4.x por meio de patches, mas "patchar" o kernel com varios patches por vezes incompativeis, configura-lo e instala-lo nao e' algo que um utilizador comum goste de fazer.)
hugs
Strange |
| | | | | | E uma das coisas que já faltava há muito: o suporte a gravadores de CDs IDE, sem se ter de recorrer ao truque do ide-scsi (emulação de um gravador de CDs SCSI)...
--
sena@smux.net
http://sena.u.smux.net/ |
| | | | Lembro-me de ter lido que o Linus criou um patch para o kernel para isso mesmo.
On Tue, Oct 15 2002, Linus Torvalds wrote:
A huge merging frenzy for the feature freeze, although I also spent a few
days getting rid of the need for ide-scsi.c and the SCSI layer to burn
CD-ROM's with the IDE driver (it still needs an update to cdrecord, I sent
those off to the maintainer).
Faltava o patch para o cdrecord. Este ja foi criado para a versão 1.1a37 e chama-se linus-cdr.diff
|
| | | | Tudo o que dizes e' de facto verdade. No entanto, a bottom line e' que apesar de se registarem essas melhorias para o desktop, os desenvolvimentos mais significativos (de peso) sao noutro campo. Segundo Andrew Morton, kernel hacking guru...
Most significant gains can be expected at the high end such as large machines, large numbers of threads, large disks, large amounts of memory etc. [...] For the uniprocessors and small servers, there will be significant gains in some corner cases. And some losses. [...] Generally, 2.6 should be "nicer to use" on the desktop. But not appreciably faster.
Estas observacoes sao especialmente fiaveis, na minha opiniao, uma vez que o Andrew Morton fez grande parte do desenvolvimento da VM para o novo kernel. Quem tenha acompanhado as discussoes na linux-kernel mailing list tera' decerto notado que o focus era precisamente nas chamadas high-end machines e quao bem o kernel se comportava com high loads.
|
| | | | | "Estas observacoes sao especialmente fiaveis, na minha opiniao, uma vez que o Andrew Morton fez grande parte do desenvolvimento da VM para o novo kernel." Não duvido. A série 2.5.x traz notoriamente vantagens para servidores. Mas nota que ele diz: "2.6 should be "nicer to use" on the desktop. But not appreciably faster.". E "nicer" *é* o principal no desktop.
hugs
Strange |
| | | | | Ironically, when software is free, it takes away the motivation of the people to develop software because they will not be able to make a living from it. Quando se paga pelo software a solucao e muito mais pratica. Compra-se a 300 escudos mais portes na net ou saca-se, se houver por ai. Ou achas que toda a gente que usa o 3D Studio Max pagou os 700 contos que eles pedem (acho que e este o preço da versao 5). Alem disso, nada impede que se use Open-Source e se desenvolva software para sistemas baseados em closed-source. Uma coisa e o Mexico ou a China trocarem os seus sistemas de sistemas bem pagos para sistemas gratuitos outra e impedir que se produza algo pelo qual se pague. Alem disso, mesmo para linux se pode produzir software pelo qual seja preciso pagar. Nada impede que a China queira mudar de Windows para Linux (ou outras opcoes) por receios de seguranca. Um sistema closed-source nao lhe permite saber o que se passa nos bastidores e vindo da America e sempre de duvidar, quando a China e um (potencial) perigo para os States. No entanto, quanto a software pago vindo de dentro da China ou de outra parte do mundo, eles la terao de decidir. For Mexico to compete with Mercedes-Benz or Toyota would be extremely difficult. It would require a tremendous amount of experience and money for Mexico to set up a large, advanced automobile manufacturing industry. Quanto ao Mexico competir com a Mercedes ou a Toyota, aconselho quem quer que seja que se for iniciar num negocio a comecar por pensar nos limites que lhe sao impostos quer por dinheiro, quer por tempo, quer por tendencias de mercado. O primeiro modelo de cada marca tambem nao foi concerteza sucesso mundial... Alem disso, se o Mexico comecasse a produzir automoveis, mesmo que menos seguros, potentes etc, mas muito mais baratos, no Mexico, teria um mercado de clientes muito grande (em 1990 ja a Cidade do Mexico tinha 14 milhoes de habitantes, salvo erro). O pais em si tem gente suficiente para, em caso de um bom modelo se poder rentabiliza-lo. E obvio que teriam depois de investir e avancar para o mercado internacional, mas nao e assim com tudo? Vejamos o caso da Seat. Nao sei quantos anos tem, mas e espanhola e certamente quando foi criada nao competia (e hoje compete?) com a Mercedes. No entanto, eles andam ai. O investimento tambem teve de ser apreciavel para a producao dos modelos que tem. By comparison, it is very easy for Mexico to start a software development industry. All they need to do is purchase some computers and software development tools. E quem compra? A administracao do banco central europeu? O Governo chines? Um organismo qualquer autraliano? Primeiro precisavam de dar provas, os mexicanos, de que valiam alguma coisa ou nao? Ou toda a gente gasta dinheiro a comprar material desnecessario e de ma qualidade (antes que falem no windows, e quase sempre pirateado...)? A india provavelmente desenvolveu programadores e so depois conseguiu o resultado monetario. E como em tudo. Primeiro investe-se na formacao, qualquer que ela seja e mais tarde, nao necessariamente nessa tarde, o resultado vem. Espero com isto ter mostrado que o kernel 2.4 e melhor (ou pior...) que o 2.5 :)
|
| |
|
