June 2009 - openSUSE Users (Español) - openSUSE Mailing Lists

[opensuse-es] kde 4.2 se apaga solo
by Ariel 05 Jun '09

05 Jun '09

hola chicos, kde se apaga solo pero antes me tira una notificacion que no alcanzo a leer ya que se apaga muy rapido. no es un problema de temperatura ya que el cpu anda por los 25, el chipset por ahi tambien y el gpu 35-40... ¿hay alguna forma de evitar que se apague automaticamente? -- Para dar de baja la suscripciÃ³n, mande un mensaje a: opensuse-es+unsubscribe(a)opensuse.org Para obtener el resto de direcciones-comando, mande un mensaje a: opensuse-es+help(a)opensuse.org

2 3

[opensuse-es] Ayuda con Konqueror y XML
by Angel 05 Jun '09

05 Jun '09

Hola fuí a entrar con konqueror 3.5.7 (OpenSUSE 10.3) y ¡¡no veo nada de nada!! http://www.cc.uah.es/xml/portada.xml Independientemente de la poco accesibilidad de la página (no tiene ni un enlace alternativo). ¿¿hay alguna manera de verla con este navegador?? Gracias y saludos -- Este correo no tiene dibujos. Las formas extrañas en la pantalla son letras. __________________________________________ Clist UAH a.k.a Angel __________________________________________ Mas vale POJO en mano que STRUTS volando. -- Para dar de baja la suscripciÃ³n, mande un mensaje a: opensuse-es+unsubscribe(a)opensuse.org Para obtener el resto de direcciones-comando, mande un mensaje a: opensuse-es+help(a)opensuse.org

2 4

Fwd: Re: [opensuse-es] ¿Está fallando Yast o es ignorancia mía?
by Gabriel 04 Jun '09

04 Jun '09

> On Wednesday 03 June 2009 18:17:05 Gabriel wrote: > > Buenas tardes, foro. > > > Debes haber tocado las prioridades de los repositorios y el que tiene la > mas actual tiene menos prioridad. He cambiado las prioridades y le he dado al repositorio KDE4 la máxima y me sigue pasando lo mismo. ¿ Alguna idea más? > De todas formas, si miras uno de los paquetes en rojo, en la > pestaña "versiones" deberías ver el que es mas actual. Basta marcarlo y ya > entiende quieres cambiar de versión. No lo entiendo. Ya dije que eran versiones anteriores de Kde 3.1 Saludos y gracias por interesarte por el tema. -- Para dar de baja la suscripciÃ³n, mande un mensaje a: opensuse-es+unsubscribe(a)opensuse.org Para obtener el resto de direcciones-comando, mande un mensaje a: opensuse-es+help(a)opensuse.org

5 10

Fwd: Re: [opensuse-es] Problema con el video
by Shinji Ikari 04 Jun '09

04 Jun '09

Reenviando. Carlos A. ---------- Forwarded Message ---------- Subject: Re: [opensuse-es] Problema con el video Date: Tuesday 02 June 2009 From: Manuel González López <ingmanuel(a)gmail.com> To: Shinji Ikari <darkwildkat(a)gmail.com> Ya realise lo que me sugirieron y me dio como resultado lo siguiente: lap-manuel:/home/manuel # grep -i accel /var/log/Xorg.0.log (==) intel(0): Using EXA for acceleration (II) Composite (RENDER acceleration) El día 28 de mayo de 2009 17:26, Shinji Ikari <darkwildkat(a)gmail.com> escribió: > On Wednesday 27 May 2009 15:32:51 Manuel González López wrote: >> Hola compañeros, tengo un problema con opensuse 11.1 que instale en mi >> lap hp elitebook 6930p, el problema consistes en que siempre desde que >> lo instale hace que funsione muy lento el modo grafico cuando arranca, >> mi partalla se congela y despues de un rato funsiona bien, o cuando >> cierro mi sesion se freesea la pantalla y luego regresa, mi lap tiene >> una salida para extender el excritorio, esta funsiona pero al momento >> de extender el escritorio a otro monitor tarda un monton el modo >> grafico de mi lap y ya despues de un rato que se destraba pues ya >> tengo el escritorio extendido, sera que configure algo mal o me falta >> hacer algo, por favor compañeros si alguien tiene la respuesta >> diganme, gracias y saludos a todos >> >> -- >> Ing. Manuel González López >> Cel. 9991513399 >> Oficina 9118690 ext 28060 > > Supondremos que es esta, pues no leemos mentes ni tenemos bolas de > cristal (la de los brujos). > <http://h10010.www1.hp.com/wwpc/us/en/sm/WF06b/321957-321957-64295-3740645-3… > EliteBook 6930p Notebook PC&lang=en&cc=us> > > El problema salta a la vista tarjeta gráfica Intel. Aunque aquí no mencionan > el problema: http://www.linlap.com/wiki/hp+elitebook+6930p > > -- > Carlos A. > > > > -- > Para dar de baja la suscripciÃ³n, mande un mensaje a: > opensuse-es+unsubscribe(a)opensuse.org > Para obtener el resto de direcciones-comando, mande > un mensaje a: > opensuse-es+help(a)opensuse.org > > -- Ing. Manuel González López Cel. 9991513399 Oficina 9118690 ext 28060 ------------------------------------------------------- -- Carlos A. -- Para dar de baja la suscripción, mande un mensaje a: opensuse-es+unsubscribe(a)opensuse.org Para obtener el resto de direcciones-comando, mande un mensaje a: opensuse-es+help(a)opensuse.org

4 11

[opensuse-es] Problemas con icedtea en firefox
by jose Cifuentes Riquelme 04 Jun '09

04 Jun '09

Estimad@s Colister@s Les escribo para contarles que tengo en Firefox instalado el plugin Icedtea (que viene por defecto) y el plugin de java de sun, con el plugin Icedtea funcionaba bastante bien hasta que tuve que abrir algunos applets con contenido matemático, lamentablemente el Icedtea no me los muestra correctamente. Lo que necesito decirle a Firefox es que cuando se encuentre con un applet de java lo abra con el plugin de sun, no encuentro esa opción. Otra alternativa que había pensado era desinstalar Icedtea tampoco se como hacerlo. Esperando que me puedan dar una mano me despido con un cordial saludo Atentamente José Cifuentes -- Para dar de baja la suscripciÃ³n, mande un mensaje a: opensuse-es+unsubscribe(a)opensuse.org Para obtener el resto de direcciones-comando, mande un mensaje a: opensuse-es+help(a)opensuse.org

3 2

Re: Re: [opensuse-es] Problema con el video
by Camaleón 04 Jun '09

04 Jun '09

El 2009-06-04 a las 12:33 -0500, Manuel González López escribió: > hola a todos, mi tarjeta es una intel Vale, pero envía los mensajes a la lista porque si no, no te vemos y nos enredamos en discusiones teosóficas... :-P Saludos, -- Camaleón -- Para dar de baja la suscripción, mande un mensaje a: opensuse-es+unsubscribe(a)opensuse.org Para obtener el resto de direcciones-comando, mande un mensaje a: opensuse-es+help(a)opensuse.org

1 0

Re: [opensuse-es] cambiar imagen de inicio de sesion cuado usas ltsp
by jose maria 04 Jun '09

04 Jun '09

El Martes, 2 de Junio de 2009, Manuel González López escribió: > Hola a todos, hay alguna forma de cambiar la imagen de inicio de > sesión cuando se usa ltsp en opensuse 11.1 > * el tema de de kdm (si usas kdm como gestor) , la cambias en el panel de control de kde, administracion del sistema y en modo administrador) , y la pantalla anunciadora por usuario en en panel de control, seccion aspecto y temas, pantalla anunciadora, vamos que lts usa la configuracion X del sistema, a no ser que hayas hecho algo por tu cuenta.

1 0

[opensuse-es] [OT] Tiras cómicas de programación
by Camaleón 03 Jun '09

03 Jun '09

Hola, Para pasar un buen rato :-) 25 Best Programmer WebComic Strips http://slashweb.org/programming/25-best-programmer-webcomic-strips.html Me quedo con la #2, la #8 y la #20 X-) Saludos, -- Camaleón -- Para dar de baja la suscripción, mande un mensaje a: opensuse-es+unsubscribe(a)opensuse.org Para obtener el resto de direcciones-comando, mande un mensaje a: opensuse-es+help(a)opensuse.org

4 3

[opensuse-es] [OT] Se viene un nuevo FS con el kernel 2.6.30: NILFS
by Juan Erbes 03 Jun '09

03 Jun '09

Salió en Linux Magazine, les pego el texto en ingles para los que no puedan acceder, pero segun parece, su mejor perfomance está en los almacenamientos de estado sólido SSD:: http://www.linux-mag.com/cache/7345/1.html NILFS: A File System to Make SSDs Scream The 2.6.30 kernel is chock full of next-gen file systems. One such example is NILFS, a new log-structured file system that dramatically improves write performance It’s difficult to write storage articles at this time and not focus on the upcoming 2.6.30 kernel. Why? This kernel is loaded with a number of new file systems — some of which we’ve already covered, like ext4 and btrfs. Another of the hot new file systems that is in 2.6.30 is NILFS. This file system is definitely one that you should be testing. NILFS2 (New Implementation of a Log-Structured File System Version 2) is a very promising new log-structured file system that has continuous snapshots and versioning of the entire file system. This means that you can recover files that were deleted or unintentionally modified as well as perform backups at any time from a snapshot without a performance penalty normally associated with creating snapshots. In addition, there is evidence that NILFS has extremely good performance on SSD drives. Log-Structured File System? Log-Structured File Systems are a bit different than other file systems with both good points and bad points. Rather than write to a tree structure such as a b-tree or an h-tree, either with or without a journal, a log-structured file system writes all data and metadata sequentially in a continuous stream that is called a log (actually it is a circular log). The concept was developed by John Ousterhout of TCL fame and Fred Douglis. The motivation behind log-structured file systems is that typical file systems lay out data based on spatial locality for rotating media (hard drives). But rotating media tends to have slow seek times limiting write performance. In addition, it was presumed that most IO would become write dominated (this observation is supported by a study that was summarized in a recent article). So a log-structured file system takes a new approach and treats the file system as a circular log and writes sequentially to the “head” of the log (the beginning) never over writing the existing log. This means that seeks are kept to a minimum because everything is sequential, improving write performance. A log-structured file system, because of its design, makes it very easy to create snapshots (in NILFS they are called checkpoints) of both the data and metadata. NILFS can then mount these checkpoints (or snapshots) along side the primary NILFS file system. From these checkpoints, you can recover erased files (if the checkpoint has a date and time prior to when the file was erased) or you can use it for backups or even disaster recovery images. Another benefit of log-structured file systems is that recovering from a crash is easier than the more typical tree based file systems (e.g. ext2, ext3, etc.). After a log-structured file system crashes, when it is remounted it can reconstruct its state from the last consistent point in the log. It starts at the head of the circular log and backs up until the file system is consistent. This point should be very close to the head so little if any data or metadata will be lost. This process is extremely fast regardless of the size of the file system. This bears repeating - a log-structured file system recovers from a crash extremely fast and the amount of time is independent of the size of the file system. In contrast, other file systems have to replay their journal and possibly even walk their data structures to make sure the file system is consistent (i.e. run “fsck”). Everyone who has run fsck on a very large file system knows how much time it can take. One problematic aspect of log-structured file systems is that they need to include a fairly sophisticated capability of “garbage collection” to reclaim free space. Free space needs to be reclaimed from the tail of the log, primarily the old check points, so that the file system doesn’t become full when the head of the log wraps around to the tail. There are many techniques for reclaiming space, one is covered in the Wikipedia article about log-structured file systems. The garbage collection process reclaims space from the check points (snap shots) otherwise the file system would fill far too quickly. A Log Structured File System for Linux - NILFS The Nippon Telephone and Telegraph (NTT) CyberSpace Laboratories has been developing NILFS (also referred to as NILFS2 since it is the version 2 of the file system) for Linux. It is released under the GPL 2.0 license and is included in the 2.6.30 kernel. It spent a great deal of time in the -mm kernels and under went much testing since it’s initial announcement. One of the most noticeable features of NILFS is that it can “continuously and automatically save instantaneous states of the file system without interrupting service”. NILFS refers to these as checkpoints. In contrast, other file systems such as ZFS, can provide snapshots but they have to suspend operation to perform the snapshot operation. NILFS doesn’t have to do this. The snapshots (checkpoints) are part of the file system design itself. One of the really cool features of NILFS is that these checkpoints can actually be mounted along side the primary file system. This has many, many uses, one of which is to mount a checkpoint to recover files that were unintentionally erased. In addition to being able to recover recently erased files and extremely fast crash recovery times, there are a number of other features of NILFS that are very attractive: * The file size and inode numbers are stored as 64-bit fields * File sizes of up to 8 EiB (Exbibyte - approximately an Exabyte) * Block sizes that are smaller than a page size (i.e. 1KB-2KB). This can potentially make NILFS much faster for small files than other file systems. * File and inode blocks use a B-tree (the use of B-trees in a log-structured file system stems from the implementation which use something called segments) * NILFS uses 32-bit checksums (CRC32) on data and metadata for integrity assurance * Correctly ordered data and meta-data writes * Redundant superblock * Read-ahead for meta data files as well as data files (helps read performance) * Continuous check pointing which can be used for snapshots. These can be used for backups or they can even be used for recovering files. Checkpoints and Snapshots One of the features that users can really enjoy with NILFS is the ability to recover erased or modified files. NILFS creates a checkpoint “every few seconds or per synchronous write basis (unless there is no change).” (from the kernel documentation). Then the user can select a checkpoint and convert it into a snapshot. These snapshots are preserved until they are converted back into checkpoints. Checkpoints are not preserved for the life of the file system and after a period of time the garbage collection process will recover the space in the checkpoint. This means that users can’t recover files from a long time in the past. But there is no limit to the number of snapshots that can be created - at least until the file system volume becomes full. There are many uses for the snapshots including recovery of erased or modified files or they can be used by administrators for backups. There are a few user-space commands that help with check points and snapshots. From the NILFS web site is an explanation of the process and is paraphrased here. The first step is to list the check points using the lscp command. $ lscp CNO DATE TIME MODE SKT NBLKINC ICNT 1 2008-05-08 14:45:49 cp - 11 3 2 2008-05-08 14:50:22 cp - 200523 81 3 2008-05-08 20:40:34 cp - 136 61 4 2008-05-08 20:41:20 cp - 187666 1604 5 2008-05-08 20:41:42 cp - 51 1634 6 2008-05-08 20:42:00 cp - 37 1653 7 2008-05-08 20:42:42 cp - 272146 2116 8 2008-05-08 20:43:13 cp - 264649 2117 9 2008-05-08 20:43:44 cp - 285848 2117 10 2008-05-08 20:44:16 cp - 139876 7357 Notice that the output of lscp lists the date and time of the check points. Under the column labeled “MODE” is either a “cp”, that stands for “check point”, or “ss” that stands for “snap shot.” If a user does not want to wait for a check point and wants to create one immediately, the mkcp command could be used. In general you need to tell mkcp the device containing a NILFS file system otherwise it searches /proc/mounts for NILFS file systems. To take a check point and create a snap shot, one uses the mkcp command again. In this case, one uses the command mkcp -s to create the snapshot from an existing checkpoint. You can also use the chcp command that changes a check point into a snap shot or vice versa. Again, from the NILFS website is an example of creating a snapshot. $ sudo chcp ss 2 $ lscp CNO DATE TIME MODE SKT NBLKINC ICNT 1 2008-05-08 14:45:49 cp - 11 3 2 2008-05-08 14:50:22 ss - 200523 81 3 2008-05-08 20:40:34 cp - 136 61 4 2008-05-08 20:41:20 cp - 187666 1604 5 2008-05-08 20:41:42 cp - 51 1634 6 2008-05-08 20:42:00 cp - 37 1653 7 2008-05-08 20:42:42 cp - 272146 2116 8 2008-05-08 20:43:13 cp - 264649 2117 9 2008-05-08 20:43:44 cp - 285848 2117 10 2008-05-08 20:44:16 cp - 139876 7357 11 2008-05-08 21:05:23 cp - 10 7357 Notice that the chcp command changes the second check point into a snap shot. This is indicated under the “MODE” column where the second check point is listed as “ss” or snap shot. Now that the check point is a snap shot, it won’t be deleted during the garbage collection. However, you can remove the snap shot by using the rmcp command. NILFS implements garbage collection in a unique way. It uses a user-space daemon to perform the garbage collection. This daemon is activated when the file system is mounted via the “mount” command. This also means that garbage collection can be activated at any time (if the file system is mounted). Don’t forget that NILFS will delete check points after a certain period of time unless the check point is converted to a snap shot. The amount of time when the check point is held before being deleted is controlled by parameters in the /etc/nilfs_cleanerd.conf file. You can adjust the garbage collection (GC) parameters in the file and restart the GC daemon so that the new parameter values are used (or unmouning and remounting the file system). You must have root access or at least sudo ability to mount a snap shot. Also recall that snap shots are mounted as read-only. From the NILFS web site example, one can mount the snapshot previously created (it was created from the second check point) # mount -t nilfs2 -r -o cp=2 /dev/sdb1 /nilfs-cp # df -t nilfs2 Filesystem 1K-blocks Used Available Use% Mounted on /dev/sdb1 71679996 3203068 64888832 5% /nilfs /dev/sdb1 71679996 3203068 64888832 5% /nilfs-cp # mount -t nilfs2 /dev/sdb1 on /nilfs type nilfs2 (rw,gcpid=13296) /dev/sdb1 on /nilfs-cp type nilfs2 (ro,cp=2) The snap shot is mounted on /nilfs-cp in a read-only mode (ro). Depending upon the options and permissions on the /nilfs-cp mount point, users could copy files from the snap shot. Alternatively, the root user could restore the file(s)s for the user. Also, the snap shot could be easily used for creating back-ups. An administrator could also use the snap shot for creating a disaster recovery image of the file system. Just as a reminder the mounted snap shot, while being a NILFS file system, is mounted read-only so check points of the snapshot are not created. After you are finished with the snap shot don’t forget to unmount it and either delete the snap shot or convert it back to a check point and allow garbage collection to recover the space. Speed, Glorious Speed Recall that one reason log-structured file systems were developed was to increase write performance (assuming the read performance would be dominated by caching effects). And who doesn’t like increased write performance? One of the earliest reviews of NILFS was in 2007 by Chris Samuel. He did a very comprehensive review of Emerging File Systems(how prescient was that review?). He did a very nice review of a number of file systems including NILFS including running benchmarks. The performance was good for such a young file system but even at that time it had the best performance by far for Sequential Deletes. It was even better than ZFS/OpenSolaris for most tests performed. In Feb. 2008, there was a presentation by Dongjun Shin from Samsung as part of the Linux Storage & File System Workshop 2008 (LSF ‘08). He benchmarked NILFS, Btrfs, Ext2, Ext3, Ext4, ReiserFS, and XFS when running on an SSD device. Granted that the testing is a little old, but the results are very, very exciting. The benchmark, Postmark, simulates an email server. Two groups of files sizes were tested, (1) 9 - 15KB (S), and (2) 0.1 - 3MB (L). For each group, two tests were run with a small number of files (S), and a larger number of files (L). Figure 1 and 2 below are the test results. Figure 1: Postmark Results for Small File Size Figure 1: Postmark Results for Small File Size Figure 2: Postmark Results for Large File Size Figure 2: Postmark Results for Large File Size Notice that in both cases, the performance of NILFS exceeds that of other file systems. For small files NILFS was about 25-38% faster than the nearest competitor (btrfs). For large files NILFS was about 15-25% faster than the nearest competitor (reiserfs and/or ext4). It is pretty amazing to see such a boost in performance from a change in file system, but it does show you that the coupling of file system design with hardware, in this case SSD’s, can produce a big boost in performance. But “There Ain’t No Such Thing As A Free Lunch” TANSTAAFL. There are some current issues with NILFS and SSD’s. There was a recent posting to the NILFS mailing list about using NILFS as the root drive for a Linux system. It was pointed out that the root file system produces a great deal of traffic. Coupled with this is the fact that NILFS file system activity can be reasonably write heavy and you have the potential for quickly wearing out SSD drives (remember that NAND chips which make up SSD’s have a limited number of rewrites). But the developers of NILFS are aware of this and a better garbage collection (GC) algorithm is under investigation. There was also a question on the Linux kernel mailing list about the effect of age on the performance (i.e. would the performance of NILFS still remain far above others on the Postmark test after it was used for a few months?). The answer is that the developers don’t believe the performance suffers after it is used for a period of time, but there isn’t any data to back up that claim at the present time. However, virtually all files systems suffer degrading performance with age. NILFS - It’s Definitely Worth Testing NILFS has a great deal going for it in many regards. It is a modern file system in almost every respect (OK, no built-in RAID, but that can be worked around). The log-structured design of NILFS means that its write performance should be very, very good and there is evidence of this from the performance report that benchmarked Postmark. Additionally, the fact that NILFS continuously creates checkpoints that can be used to create snapshots, is of great benefit. These checkpoints can be used to recover erased or modified user files. They can also be used for backups or creating disaster recover images of data. More over, creating these checkpoints or snapshots do not result in decreased performance as they do for file systems such as ZFS. NILFS holds great promise for Linux. There are many scenarios where it would work extremely well. In particular it works very well for user directories or work directories. In the HPC world it would work extremely well for high-speed storage that are dominated by write performance. Coupling the performance boosts with the snapshot features make NILFS a potential system administrators dream file system. It is well worth trying NILFS on your system. -- Para dar de baja la suscripciÃ³n, mande un mensaje a: opensuse-es+unsubscribe(a)opensuse.org Para obtener el resto de direcciones-comando, mande un mensaje a: opensuse-es+help(a)opensuse.org

3 2

[opensuse-es] ¿Está fallando Yast o es ignorancia mía?
by Gabriel 03 Jun '09

03 Jun '09

Buenas tardes, foro. El motivo de mi correo a la lista es el siguiente: uso Opensuse 11.1 con 4.2.88 (KDE 4.2.88 (KDE 4.3 >= 20090527)) "release 127". Aunque tengo varios repositorios más, uno de ellos es de donde actualizo el KDE4, cuya dirección es la URL: http://download.opensuse.org/repositories/KDE:/KDE4:/Factory:/Desktop/openS… Pues bien, desde hace varios días, cuando quiero actualizar con Yast, vengo observando que hay varios paquetes de KDE4 que me salen en rojo, es decir, que son paquetes que tengo más actualizados que los que hay en el repositorio, y son muy pocos los que me salen en azul (los que el repositorio tiene más nuevos que los míos). El caso es que, por casualidad, abrí la dirección URL arriba indicada vi los paquetes de la carpeta i586 y me chocó mucho que hubiera paquetes en esa carpeta de una versión más actual que los paquetes que yo tengo instalados y sin embargo Yast me los da en rojo. Por ejemplo, así a bote pronto veo que tengo instalado en mi Pc el paquete Kde4-dolphin en su versión 4.2.85-85.2 y entre paréntesis me sale la 4.1.3.3.8.9, todo ello en rojo, es decir, tengo una versión más actualizada del paquete Kde4-dolphin que la que hay en los repositorios. Sin embargo, si abro la URL de arriba, me pone en la carpeta i586 que hay en el repositorio la versión kde4- dolphin-4.2.88svn973768-88.3.i586.rpm y sin embargo a mí no me la da Yast como si existiera. Me gustaría que si alguien sabe del tema me saque de mi ignorancia, porque me imagino que debe de ser eso, pero hasta que no me lo expliquen no lo entiendo. Un saludo a todo el mundo desde Huelva. -- Para dar de baja la suscripciÃ³n, mande un mensaje a: opensuse-es+unsubscribe(a)opensuse.org Para obtener el resto de direcciones-comando, mande un mensaje a: opensuse-es+help(a)opensuse.org

2 1