[Hilo Oficial] Arch Linux

No te hubiese sido mucho mas simple con un chroot?

gente, ¿os pasa que desde la ultima actualización de kernel no va el audio ni el touchpad?

ElChabaldelPc escribió:gente, ¿os pasa que desde la ultima actualización de kernel no va el audio ni el touchpad?

No, ambas cosas me van perfectamente.

me han dejado de funcionar recuerdo haber instalado wine, haber luego actualizado el equipo (se actualizo bash, mono, el kernel firmware, las kernel headers y el kernel en si) y haber reiniciado
y despues de eso, no tengo audio y la touchpad se desconecta (mientras inicio sesion en gdm va, luego nada) pero no tengo ningun mensaje de error

yo desde que salio el kernel 2.6.33.* lo tengo bloqueado, ya que me daba problemas con el audio.

Cconcretamente mi portatil siempre se ha llevado fatal con el audio y siempre me sacaba audio por los altavoces y por los cascos, luego yo me hice un script para que solo me sacase audio o por los altavoces o por los cascos, pero a partir de la version del kernet 2.6.33.* siempre que le doy a mute, me hace un reset del audio y despues de desmutearlo me vuelve a sacar el audio por los dos sitios.

Prueba a volver a instalar el anterior kernel, seguramente lo tendras aun en la cache de pacman /var/cache/pacman/pkg/, sino los tuvieras yo tengo guardados la 2.6.32.10-1 y la 2.6.33.2-1 sabor 64b

nu_kru escribió:Prueba a volver a instalar el anterior kernel, seguramente lo tendras aun en la cache de pacman /var/cache/pacman/pkg/, sino los tuvieras yo tengo guardados la 2.6.32.10-1 y la 2.6.33.2-1 sabor 64b

lastima, los necesito de 32 la ultima que me fue bien fue la 2.6.33.3

el otro dia instale arch en el ordenador de mi padre, nose muy bien porque, ya que creo que me va a ser imposible moverle del xp, xdd.

Mirando la cache de pacman, tengo el kernel y el firmware  de la 2.6.33.3, eso si, los headers no.

En cuanto pueda lo subo a megaupload y te pongo el link

ElChabaldelPc escribió:

nu_kru escribió:Prueba a volver a instalar el anterior kernel, seguramente lo tendras aun en la cache de pacman /var/cache/pacman/pkg/, sino los tuvieras yo tengo guardados la 2.6.32.10-1 y la 2.6.33.2-1 sabor 64b

lastima, los necesito de 32 la ultima que me fue bien fue la 2.6.33.3

downgrading? Arch Rollback Machine

jorchube escribió:
downgrading? Arch Rollback Machine

bua.. nome sabia esta pagina, me la apunto, .. y yo subiendo el paquete a megaupload, jaja.. http://www.megaupload.com/?d=4LCJWTAT

gracias chicos, pero me temo que sigue sin funcionar

Lectura interesante para los que usamos Arch

http://www.phoronix.com/scan.php?page=a ... ster&num=1

Interesante test. Habría que hacer más comparativas en distintas configuraciones de hardware para llegar a más conclusiones, porque creo que más de uno (me incluyo) dirá que su experiencia no es así y que notan más rápido a uno u otro.
Además, me cuesta comprender que ambos sistemas sean prácticamente iguales cuando Ubuntu lleva más servicios activados por defecto. ¿Significaría esto que si se desactivaran esos servicios, podría ponerse por delante de Arch?

Xr529 escribió:Interesante test. Habría que hacer más comparativas en distintas configuraciones de hardware para llegar a más conclusiones, porque creo que más de uno (me incluyo) dirá que su experiencia no es así y que notan más rápido a uno u otro.
Además, me cuesta comprender que ambos sistemas sean prácticamente iguales cuando Ubuntu lleva más servicios activados por defecto. ¿Significaría esto que si se desactivaran esos servicios, podría ponerse por delante de Arch?

A veces nos olvidamos de que todas las distribuciones tienen la misma base y usan los mismos paquetes, si se hace un test de velocidad de un programa determinado lo lógico es que a igualdad de hardware, versiones de programas y sistema de ficheros el rendimiento sea muy similar sea cual sea la distribución.

Cuando se dice que Arch es rápido es simplemente por que va menos cargado de cosas innecesarias, lo que hace que el ordenador se note más ligero en general, si se configura a fondo Ubuntu y se elimina todo lo sobrante quedará igual de ligero que Arch, y si a éste se le carga quedaría como Ubuntu o peor, aunque para eso habría que hacerlo a propósito, ya que no creo que nadie se ponga a instalar paquetes y añadir cosas al kernel que sabe que no necesita.

Que comparen la actualización de los repositorios, de un paquete, de todo el sistema... Estuve en Ubuntu un par de días y apt y aptitude me desesperaban en comparación con pacman.

Ok Baek, en eso estamos de acuerdo, pero mi pregunta no va por "configurándolos igual". En el test que ha realizado Phoronix, entiendo que se les ha comparado realizando instalaciones por defecto de ambos sistemas, por lo que Ubuntu llevará consigo una mayor cantidad de servicios que Arch no tiene ni instalados, de modo que repito la pregunta: Si con instalaciones por defecto funciona igual, ¿funcionaría mejor Ubuntu si lo configuramos igual que un Arch por defecto?

Xr529 escribió:Ok Baek, en eso estamos de acuerdo, pero mi pregunta no va por "configurándolos igual". En el test que ha realizado Phoronix, entiendo que se les ha comparado realizando instalaciones por defecto de ambos sistemas, por lo que Ubuntu llevará consigo una mayor cantidad de servicios que Arch no tiene ni instalados, de modo que repito la pregunta: Si con instalaciones por defecto funciona igual, ¿funcionaría mejor Ubuntu si lo configuramos igual que un Arch por defecto?

No me has entendido (o yo me he explicado como el culo )

Phoronix ha hecho test comparando el rendimiento de unos programas en particular, no la carga del sistema en general, y en ese tipo de test lo normal es que no haya grandes diferencias entre distribuciones, el hardware es el mismo, la versión del programa la misma y el sistema de ficheros el mismo.

No es el primer test ultradiscutible y ultrarelativo que se ve en Phoronix...

Baek escribió:Phoronix ha hecho test comparando el rendimiento de unos programas en particular, no la carga del sistema en general, y en ese tipo de test lo normal es que no haya grandes diferencias entre distribuciones, el hardware es el mismo, la versión del programa la misma y el sistema de ficheros el mismo.

Ok, ok, ahora sí me ha quedado claro. Compréndeme, estamos a viernes, son días de cansancio acumulado

como han decidido que partes de gnome y que servicios y daemons que puede (o no) necesitar gnome o el sistema han instalado en arch?

porque una "instalacion basica, o por defecto de arch" eso no es xD

pero bueno, que va a ser que Baek se ha explicado bien.

amuchamu escribió:Estuve en Ubuntu un par de días y apt y aptitude me desesperaban en comparación con pacman.

Cada vez que toco un Ubuntu pienso lo mismo. Cuando era usuario de Debian, Aptitude me parecía una maravilla. Pero es lento, desordenado y no te enteras de la mitad. Pacman en ese aspecto es una maravilla.

Baek escribió:

Xr529 escribió:Ok Baek, en eso estamos de acuerdo, pero mi pregunta no va por "configurándolos igual". En el test que ha realizado Phoronix, entiendo que se les ha comparado realizando instalaciones por defecto de ambos sistemas, por lo que Ubuntu llevará consigo una mayor cantidad de servicios que Arch no tiene ni instalados, de modo que repito la pregunta: Si con instalaciones por defecto funciona igual, ¿funcionaría mejor Ubuntu si lo configuramos igual que un Arch por defecto?

No me has entendido (o yo me he explicado como el culo )

Phoronix ha hecho test comparando el rendimiento de unos programas en particular, no la carga del sistema en general, y en ese tipo de test lo normal es que no haya grandes diferencias entre distribuciones, el hardware es el mismo, la versión del programa la misma y el sistema de ficheros el mismo.

Si os fijais comparan las distros de 64 bits, es decir, compilaciones iguales, es logico que apenas haya diferencias. Habria que ver las version de 32 bits de ambas distros.

Donato escribió:

Baek escribió:

Xr529 escribió:Ok Baek, en eso estamos de acuerdo, pero mi pregunta no va por "configurándolos igual". En el test que ha realizado Phoronix, entiendo que se les ha comparado realizando instalaciones por defecto de ambos sistemas, por lo que Ubuntu llevará consigo una mayor cantidad de servicios que Arch no tiene ni instalados, de modo que repito la pregunta: Si con instalaciones por defecto funciona igual, ¿funcionaría mejor Ubuntu si lo configuramos igual que un Arch por defecto?

No me has entendido (o yo me he explicado como el culo )

Phoronix ha hecho test comparando el rendimiento de unos programas en particular, no la carga del sistema en general, y en ese tipo de test lo normal es que no haya grandes diferencias entre distribuciones, el hardware es el mismo, la versión del programa la misma y el sistema de ficheros el mismo.

Si os fijais comparan las distros de 64 bits, es decir, compilaciones iguales, es logico que apenas haya diferencias. Habria que ver las version de 32 bits de ambas distros.

Eso iba a comentar yo ahora. Supongo que si tienes un ordenador "nuevo" y potente, la ventaja que tiene usar 686 frente a 386 desaparece al usar x86_64.

recupere el touchpad... desisntalando wine debe ser el bug mas extraño jamas encontrado

pero ahora me he qdado sin poder manejar los netasq desde linux =/

ElChabaldelPc escribió:recupere el touchpad... desisntalando wine debe ser el bug mas extraño jamas encontrado

Pues sí que es raro, no sabía que tuvieran algo que ver xD.

PD: para mi el cambio de ubuntu a arch linux fué brutal, también es verdad que pasé en la versión 7 u 8 y parece ser que con las nuevas han mejorado pero la diferencia era apreciable en todos los sentidos (incluso en estabilidad, que no es el punto fuerte de arch).


Saludos

Buenas!

Mucho tiempo sin postear por EOL! De modo que saludos.

Actualmente uso un equipo un pelín antiguo (pasa de los nueve añitos). El micro es un AMD-K7 a 750MHz, con 512MB de RAM y como gráfica una NVIDIA Geforce 3 Ti200 (AGP). ArchLinux lleva instalado en ese equipo algún tiempo, y me funciona de maravilla, aunque hasta ahora, para el entorno gráfico he usado el controlador no-privativo ('nv').

Ahora me veo en la necesidad de usar aceleración para OpenGL (la tarjeta lo soporta sin problemas) y el rendimiento de los controladores privativos es infinitamente superior (por mi experiencia con otras distribuciones). Pero no consigo que funcione, y el caso es que juraría que no hago nada mal. He probado prácticamente todo lo que se me ha ocurrido: los controladores mantenidos para pacman (nvidia-96xx), compilar directamente los módulos del kernel descargando desde la web de Nvidia, trastear de cien maneras distintas con las opciones en el archivo xorg.conf, ...

El resultado es siempre idéntico: la pantalla se queda en negro y de ahí no se mueve. El log (/var/log/xorg.0.log) no indica ningún problema o errores, pero no hay "tutía". La tarjeta se reconoce perfectamente en el sistema (lspci). En fin, que ya ando un poco desesperao y a punto de arrojar la toalla y seguir como hasta ahora, con el driver de siempre, con "aceleración" de pena (35fps en glxgears! ).

Si alguien tiene alguna sugerencia... lo agradezco.

Un saludo!

Deschamps escribió:...

cuando dices "el driver de siempre", te refieres al "nv"?
Si es asi, has provado el nouveau?

Tenemos un nuevo look en la web... aunque no para todos los apartados...

JanKusanagi escribió:

Deschamps escribió:...

cuando dices "el driver de siempre", te refieres al "nv"?
Si es asi, has provado el nouveau?

Sí, me refiero a 'nv'.

'nouveau' no me lo había planteado siquiera, porque no tengo ninguna referencia de su estabilidad (según las descripciones no parece que su desarrollo haya llegado aún a beta, siquiera), y en cuanto al rendimiento, al menos por lo que se ve en el cuadro de características (el wiki de ArchLinux), está aún bastante en cueros. Para la familia NV20 (la que corresponde a mi gráfica) no tiene implementado siquiera soporte para primitivas o texturas en el apartado 3D.

¿Tienes alguna experiencia (o sabes de alguna de primera mano) con este controlador?

Gracias por tu respuesta.

Slurp escribió:Tenemos un nuevo look en la web... aunque no para todos los apartados...

Precioso. Me encanta todo de Arch.

Por cierto, Deschamps, ahora noveau es el driver por defecto en ubuntu para tarjetas nvidia, a si que muy mal no creo que esté.

Deschamps escribió:¿Tienes alguna experiencia (o sabes de alguna de primera mano) con este controlador?

No, pero creo recordar que jorchube (que ronda por aqui habitualmente, y usa Arch) lo estubo trasteando. Eso si, no con una grafica tan antigua
Te lo comentaba mas que nada porque tengo mis dudas del buen funcionamiento de un driver privativo viejisimo con un Xorg moderno. Que si, que Nouveau sera Alpha, pero aun asi...
Y vamos, leer articulos esta muy bien, pero solo sabras que tal te va... probandolo

EDIT: Ahora que lo dice alex90, creo que Mandriva 2010.1 (Spring) usa Nouveau tambien por defecto (al menos en la edicion 100% Free software), asi que por algo sera xD
Pero claro, lo dicho, dudo que mucha gente (usuarios y desarrolladores) testee con hardware como el tuyo.

[...] solo sabras que tal te va... probandolo [...]

Pues "from lost to the river", entonces
Le daré un tiento y comentaré qué tal.

Gracias a ambos.

he oido jorchube?

yo he probado nouveau en una gforcego 7600

es completamente fiable / estable, e incluso puede "dibujar movidas 3D" (glxgears, blender, neverball...) aunque los fps eran 5 veces menos que con el driver privativo.

en su web oficial tienes esto:

http://nouveau.freedesktop.org/wiki/FeatureMatrix

que es basicamente el estado del driver para todas las familias de graficas.

como ves, 2D esta totalmente hecho, asi como dualhead con xrandr, suspension, KMS (el unico modo de usar el driver, aviso), y 3D como ves y te comento, lo tienen avanzadillo.

por cierto que la propia nvidia dice que pasemos de nv, que antes de eso usemos vesa.... pero antes de usar vesa, por supuesto, usa nouveau

tengo un problemilla. no me actualiza los paquetes

he vsto que tengo paquetes desactualizados que aunque le pase el comando -Syu o limpie la caché - aun me sigue marcando como que estan en la ultima version.

pero si los updateo a mano si que updatean

alguno le ha pasado lo mismo? como se soluciona sin tener que reinstalar todo? (para no tener que volver a configurar de nuevo todo :S)

saludos

sL1pKn07 escribió:tengo un problemilla. no me actualiza los paquetes

he vsto que tengo paquetes desactualizados que aunque le pase el comando -Syu o limpie la caché - aun me sigue marcando como que estan en la ultima version.

pero si los updateo a mano si que updatean

alguno le ha pasado lo mismo? como se soluciona sin tener que reinstalar todo? (para no tener que volver a configurar de nuevo todo :S)

saludos

que significa updatear a mano? te los bajas a mano e instalas con -U?

quiza el mirror que usas tarda en sincronizar... prueba con otro mirror.

por otro lado, en lugar de -Syu, prueba -Syyu, asi fuerzas el refresco de la base de datos.

a updatear a mano me refiero a "yaourt -S nombredelpaquete". si pongo "yaourt nombredelpaquete" me sale en rojo y se ve claramente que indica que hay una version superior

pero si hago un yaourt -Syu dice que está todo "up of date"

me di cuenta de esto por que trasteando con el ultra me salian actualizaciones mientras en el sobremesa me decia que nanai. (x264, ffmpeg, xterm por poner un ejemplo)

y en los dos tengo los mismos mirrors (mir)

EDIT: nada. con "-Syyu" tampoco me salen las actualizaciones. existe alguna manera de rehacer la lista de paquetes instalados?

ejemplo caundo pongo a ver un paquete que no está actualizado (guiandome por el del portatil)
y cuando intento actualizar todo por "Syu"

(la dependencia es del modulo de vbha del cdemu

si actualizo el paquete por "-S" lo hace sin problemas

Yaourt no es el gestor de paquetes de Arch. Pacman lo es. Entiendo que yaourt pueda ser mas cómodo para paquetería de AUR (aunque yo prefiero usar ABS a pelo) , pero de ahí a usarlo como gestor de paquetes predeterminado...Lo veo un poco arriesgado.

De hecho, yaourt no está mantenido en los repos de Arch.

Siempre he tenido una duda con yaourt y los paquetes de AUR. ¿Como se actualizan? ¿O cuando sale una versión nueva has de reinstalar la aplicación con yaourt?

Endher escribió:Siempre he tenido una duda con yaourt y los paquetes de AUR. ¿Como se actualizan? ¿O cuando sale una versión nueva has de reinstalar la aplicación con yaourt?

http://archlinux.fr/yaourt-en

mas informacion en el man

pero basicamente tienes sus propios comandos para actualizar y hace distincion en si te bajas el paquete o lo sacas de un cvs/svn/mercurial

       yaourt -Syu --aur
upgrade system + packages from AUR

yaourt -Sybu --aur
upgrade by building PKGBUILD + packages from AUR

yaourt -Syu --devel
upgrade all cvs/svn/mercurial packages

A ver, lo que parece que tienes es un problema de dependencias.

Tienes activo testing, por la razón que sea. Tienes instalada una versión de libdrm más nueva que la de extra pero más vieja que la de testing. Probablemente algún paquete necesite una versión igual a la que tienes, no posterior, y por eso no te deja actualizar, de ahí el "no se pudieron satisfacer las dependencias".

Para saber qué paquetes puedes actualizar: pacman -Qu

Haz un pacman -Sy libdrm, si no lo puede actualizar te dirá cuál es el problema.

Por cierto, nunca había visto tantos repositorios activos, todo el mundo que conozco tiene sólo core, extra y community, y algún loco con testing.

nu_kru escribió:

Endher escribió:Siempre he tenido una duda con yaourt y los paquetes de AUR. ¿Como se actualizan? ¿O cuando sale una versión nueva has de reinstalar la aplicación con yaourt?

http://archlinux.fr/yaourt-en

mas informacion en el man

pero basicamente tienes sus propios comandos para actualizar y hace distincion en si te bajas el paquete o lo sacas de un cvs/svn/mercurial

       yaourt -Syu --aur
upgrade system + packages from AUR

yaourt -Sybu --aur
upgrade by building PKGBUILD + packages from AUR

yaourt -Syu --devel
upgrade all cvs/svn/mercurial packages

Gracias ^^ no tenía ni idea :$

Mirad lo que he encontrado: http://www.muylinux.com/2010/05/27/chak ... bo-el-amor es una mala noticia :S

Endher escribió:Mirad lo que he encontrado: http://www.muylinux.com/2010/05/27/chak ... bo-el-amor es una mala noticia :S

Que mala noticia, desde la muerte del líder del proyecto Jan Mette habían estado algo inconsistentes, pero no me imaginaba esto ni modo tendremos que pasarnos al KDE de los repositorios oficiales

amuchamu escribió:[...] Por cierto, nunca había visto tantos repositorios activos, todo el mundo que conozco tiene sólo core, extra y community, y algún loco con testing [...]

Eso mismo iba a comentar yo... Qué cantidad de bases de datos! Eso debe de liar un berenjenal de versiones del cáguensen. Con lo feliz que voy yo con core, extra y community

jorchube escribió:[...] en su web oficial tienes esto:http://nouveau.freedesktop.org/wiki/FeatureMatrix
que es basicamente el estado del driver para todas las familias de graficas.

Sí. Ya lo estuve mirando, aunque en el wiki de ArchLinux. De todo modos, para la familia NV20 está aún poco avanzada la implementación del 3D. Pero menos da una piedra

[...] KMS (el unico modo de usar el driver, aviso) [...]

Estoy en ello, pero no acaba de chutar. Y sin embargo parece que no hice nada mal. Por ejemplo:



Arroja:



Ya eliminé además las entradas a "vga=" de /boot/grub/menu.lst, pero sospecho que no he conseguido limpiar bien los restos de la instalación del driver propietario de nvidia (no el paquete, sino el descargado de la web de Nvidia), porque al editar xorg.conf para añadir Driver="nouveau" y levantar gdm... se queda el equipo pilladísimo, hasta el punto de que no he sido capaz de recuperar la consola, i.e. un hard-reset a saco para reiniciar y deshacer.

En fin. Seguiré trapicheando a ver hasta donde puedo llegar.

[...] por cierto que la propia nvidia dice que pasemos de nv, que antes de eso usemos vesa.... pero antes de usar vesa, por supuesto, usa nouveau

¿Y por qué? Vamos, que obviando el tema de la aceleración OpenGL, a mi 'nv' no me ha dado mal resultado, teniendo en cuenta que el equipo es de cuando VGA era en blanco y negro. Ahora mismo, además, es el único modo que tengo de mostrar un entorno gráfico (aunque ya no hay manera de usar el módulo glx, cagüen).

Un saludo!

Deschamps escribió:

amuchamu escribió:[...] Por cierto, nunca había visto tantos repositorios activos, todo el mundo que conozco tiene sólo core, extra y community, y algún loco con testing [...]

Eso mismo iba a comentar yo... Qué cantidad de bases de datos! Eso debe de liar un berenjenal de versiones del cáguensen. Con lo feliz que voy yo con core, extra y community

no te creas. [archfox] lo he eliminado por que era solo y exclusivamente de grubGFX... y como ya no lo uso... pos fuera
y archlinuxfr está todo desfasado. asi que no hay ningún problema de que se solapen versiones. la única que puede dar problemas es la de testing/testing-community.... pero nada que no se pueda arreglar tocando un poquito de aquí y de allá y montar tus propios paquetes (controlados en todo momento eh..) como me pasó con el modulo vhba del cdemu de [extra] xd

por lo demás ya está arreglado (en parte, esperemos que no vuelva a ocurrir) el problema. con "-Qu" para listar los paquetes desfasados e instalarlos a mano con "-S" ya tengo resuelto el problema de momento. dentro de medio año volveré a mirar xd


tanto miedo os da testing?¿ tán poco os fiáis de los montadores de paquetes?

Deschamps escribió:

amuchamu escribió:[...] Por cierto, nunca había visto tantos repositorios activos, todo el mundo que conozco tiene sólo core, extra y community, y algún loco con testing [...]

Eso mismo iba a comentar yo... Qué cantidad de bases de datos! Eso debe de liar un berenjenal de versiones del cáguensen. Con lo feliz que voy yo con core, extra y community

jorchube escribió:[...] en su web oficial tienes esto:http://nouveau.freedesktop.org/wiki/FeatureMatrix
que es basicamente el estado del driver para todas las familias de graficas.

Sí. Ya lo estuve mirando, aunque en el wiki de ArchLinux. De todo modos, para la familia NV20 está aún poco avanzada la implementación del 3D. Pero menos da una piedra

[...] KMS (el unico modo de usar el driver, aviso) [...]

Estoy en ello, pero no acaba de chutar. Y sin embargo parece que no hice nada mal. Por ejemplo:

dmesg | grep nouveau

Arroja:

nouveau 0000:01:00.0: PCI INT A -> Link[LNKA] -> GSI 12 (level, low) -> IRQ 12
[drm] nouveau 0000:01:00.0: Detected an NV20 generation card (0x020100a5)
[drm] nouveau 0000:01:00.0: Attempting to load BIOS image from PROM
[drm] nouveau 0000:01:00.0: ... appears to be valid
[drm] nouveau 0000:01:00.0: BMP BIOS found
[drm] nouveau 0000:01:00.0: BMP version 5.20
[drm] nouveau 0000:01:00.0: Bios version 03.20.00.26
[drm] nouveau 0000:01:00.0: Found Display Configuration Block version 1.4
[drm] nouveau 0000:01:00.0: No useful information in BIOS output table; adding all possible outputs
[drm] nouveau 0000:01:00.0: Probing TV encoders on I2C bus: 1
[drm] nouveau 0000:01:00.0: No TV encoders found.
[drm] nouveau 0000:01:00.0: Parsing VBIOS init table 0 at offset 0xACC4
[drm] nouveau 0000:01:00.0: Parsing VBIOS init table 1 at offset 0xB3E4
[drm] nouveau 0000:01:00.0: Parsing VBIOS init table 2 at offset 0xACDF
[drm] nouveau 0000:01:00.0: Parsing VBIOS init table 3 at offset 0xB38B
[drm] nouveau 0000:01:00.0: Parsing VBIOS init table 4 at offset 0xAD63
[drm] nouveau 0000:01:00.0: Parsing VBIOS init table 5 at offset 0xAE76
[drm] nouveau 0000:01:00.0: Parsing VBIOS init table 6 at offset 0xAD8C
[drm] nouveau 0000:01:00.0: Parsing VBIOS init table 7 at offset 0xAE11
[drm] nouveau 0000:01:00.0: 128 MiB VRAM
nouveau 0000:01:00.0: putting AGP V2 device into 4x mode
[drm] nouveau 0000:01:00.0: 64 MiB GART (aperture)
[drm] nouveau 0000:01:00.0: Allocating FIFO number 0
[drm] nouveau 0000:01:00.0: PFIFO_DMA_PUSHER - Ch 0
[drm] nouveau 0000:01:00.0: nouveau_channel_alloc: initialised FIFO 0
[drm] nouveau 0000:01:00.0: Saving VGA fonts
[drm] nouveau 0000:01:00.0: Detected a VGA connector
[drm] nouveau 0000:01:00.0: Setting dpms mode 3 on vga encoder (output 0)
[drm] nouveau 0000:01:00.0: allocated 1024x768 fb: 0x45000, bo dee3a400
[drm] nouveau 0000:01:00.0: Setting dpms mode 0 on vga encoder (output 0)
[drm] nouveau 0000:01:00.0: Output VGA-1 is running on CRTC 0 using output @
[drm] nouveau 0000:01:00.0: GPU lockup - switching to software fbcon
fb0: nouveaufb frame buffer device
[drm] Initialized nouveau 0.0.16 20090420 for 0000:01:00.0 on minor 0


Ya eliminé además las entradas a "vga=" de /boot/grub/menu.lst, pero sospecho que no he conseguido limpiar bien los restos de la instalación del driver propietario de nvidia (no el paquete, sino el descargado de la web de Nvidia), porque al editar xorg.conf para añadir Driver="nouveau" y levantar gdm... se queda el equipo pilladísimo, hasta el punto de que no he sido capaz de recuperar la consola, i.e. un hard-reset a saco para reiniciar y deshacer.

En fin. Seguiré trapicheando a ver hasta donde puedo llegar.

[...] por cierto que la propia nvidia dice que pasemos de nv, que antes de eso usemos vesa.... pero antes de usar vesa, por supuesto, usa nouveau

¿Y por qué? Vamos, que obviando el tema de la aceleración OpenGL, a mi 'nv' no me ha dado mal resultado, teniendo en cuenta que el equipo es de cuando VGA era en blanco y negro. Ahora mismo, además, es el único modo que tengo de mostrar un entorno gráfico (aunque ya no hay manera de usar el módulo glx, cagüen).

Un saludo!

te recuerdo que el driver de nvidia (la parte nvidia-utils, segun los repos) provee su propio libgl, que deberias reinstalar desde los repos para estar seguro.

Cory escribió:

Endher escribió:Mirad lo que he encontrado: http://www.muylinux.com/2010/05/27/chak ... bo-el-amor es una mala noticia :S

Que mala noticia, desde la muerte del líder del proyecto Jan Mette habían estado algo inconsistentes, pero no me imaginaba esto ni modo tendremos que pasarnos al KDE de los repositorios oficiales

Sinceramente, creo que se flipan un poco, quieren crear un SO completo con base Linux+KDE, según dicen, similar al estilo OSX, no sé cuanta gente compone el equipo de Chakra, pero me parece que el objetivo es demasiado ambicioso y tiene grandes posibilidades de morir antes de nacer.

Baek escribió:

Cory escribió:

Endher escribió:Mirad lo que he encontrado: http://www.muylinux.com/2010/05/27/chak ... bo-el-amor es una mala noticia :S

Que mala noticia, desde la muerte del líder del proyecto Jan Mette habían estado algo inconsistentes, pero no me imaginaba esto ni modo tendremos que pasarnos al KDE de los repositorios oficiales

Sinceramente, creo que se flipan un poco, quieren crear un SO completo con base Linux+KDE, según dicen, similar al estilo OSX, no sé cuanta gente compone el equipo de Chakra, pero me parece que el objetivo es demasiado ambicioso y tiene grandes posibilidades de morir antes de nacer.

Completamente de acuerdo. Si ya se notaba que el proyecto chakra se estaba quedando grande con la poca frecuencia de actualicaciones de su LiveCD, ahoraesto va a ser el nuevo HURD, un proyecto imposible y sin fin.

Pues si les sale bien aquí tienen a un interesado, la verdad. Aunque nunca he probado kdemod.

Slurp escribió:Pues si les sale bien aquí tienen a un interesado, la verdad. Aunque nunca he probado kdemod.

No hay mucho que probar, es KDE modulado y con un par de programas propios añadidos, nada más.

Los que usamos kdemod tendremos que pasarnos a kde? Porque me vuelvo loco sólo de pensar la de problemas que me va a dar.

sL1pKn07 escribió:tanto miedo os da testing?¿ tán poco os fiáis de los montadores de paquetes?

Pues si xD. Si con core, extra y comunity ya hay problemas de vez en cuando, con testing es como tirar una moneda al aire cada vez que haces -Syu