Arch-Stuff es un sitio web que sigue la línea de páginas como GimpStuff, KDE-Look, GNOME-Look y XFCE-Look entre otras. Encontrarás muchas cosas para Archlinux como fondos de escritorio, capturas de pantallas, temas, decoraciones de ventana, KDM y GDM splash, fuentes, íconos, logos, etc, etc. Es una página muy completa y lo mejor de todo es que está pensada para darle más belleza a nuestra distribución favorita .

Clic para agrandar

¡Saludos!

El Proyecto Chakra es un proyecto de software libre creado por un grupo de gente que le gusta Archlinux y KDE.

Chakra es un rápido, amigable y extremadamente poderoso live CD y/o distrolet (versión personalizada de una distro^[1]) basado en el galardonado KDE (K Desktop Environment, Entorno de Escritorio K en español) y en una de las distribuciones GNU/Linux para experimentados: Archlinux.

Actualmente está en fase alfa, cuenta con un instalador gráfico, configuración automática de hardware y por supuesto algunas herramientas más y extras.

Sólo pruébalo si te gusta y dinos (¿eso se escribe junto o separado? ) lo que piensas.

Tomado y traducido desde The Chakra project

Como much@s sabrán El proyecto Chakra desarrolló KDEmod, un conjunto de paquetes de KDE modular, ajustado y optimizado para Archlinux. KDEmod viene con un montón de adiciones y cosas extra y además provee paquetes de KDE3 y KDE4 en sus repositorios. Chequéalo aquí.^[2]

Ten en cuenta que no es necesario instalar Chakra para probar KDEmod, se puede hacer eso directamente en tu Archlinux. Mira aquí para más información.

He leído por ahí (en otros blogs) a personas diciendo que desde que en los repositorios oficiales de Archlinux existen los paquetes cortados de KDE ya no es necesario instalar KDEmod, puesto que, de acuerdo a lo que ellos piensan (lo que se evidencia por lo que dicen) KDEmod sólo servía y era útil por la posibilidad de instalar aplicaciones de KDE en paquetes unitarios y no en meta paquetes. Pues bien, yo les digo a esas personas que  están muy equivocadas. KDEmod, recordemos, está optimizado para Archlinux, no así los paquetes que están en los repositorios de Arch. Además hay otro punto demasiado importante, y que tal vez es el más trascendental de todos, desde mi manera de ver las cosas: KDEmod, en sus repositorios, provee unos paquetes llamados debug, los cuales no están contenidos en los repositorios de Arch y que contienen información de depuración de errores de las diferentes aplicaciones o paquetes de KDE. Cualquier persona que haya reportado caídas (crashes) de programas en bugs.kde.org sabe de lo que hablo. En este mismo sentido, recuerda que una de las formas de ayudar al software libre es reportando errores, por lo que, si usas Archlinux, te invito a probar KDEmod, instalar cada paquete con su respectivo paquete debug (si existe) y también a instalar KBugBuster un programa que te ayudará a reportar errores de KDE en forma fácil y sencilla.

Aquí puedes leer más acerca de cómo crear reportes de caídas útiles en KDE.

Finalmente decir que Chakra al igual que KahelOS es una excelente alternativa para usuarios noveles que por “miedo” o falta de conocimientos no se atreven a instalar Archlinux en sus máquinas.

Como dice más arriba, Chakra provee un instalador totalmente gráfico y herramientas de configuración del sistema propias, muy intuitivas y muy fáciles de usar. Además no piensen que por estar en su fase alfa es inestable, nada de eso, al parecer se encuentra en esa etapa porque los desarrolladores son muy comprometidos con el proyecto y quieren crear más aplicaciones que le hagan la vida aún más fácil al usuario final, además, por supuesto, de mejorar las herramientas propias ya existentes.

Aquí les dejo algunas capturas de Chakra:

Imagen tomada de (2). Clic para agrandar

Imagen tomada de (2). Clic para agrandar

¡Saludos!

^[1]Archlinux Fácil !!!: Proyecto Chakra

^[2](2)The Chakra Project

Aca dejo para el resto del mundo la configuracion que le di a mi nueva Vostro 1320. Me hubiera venido bien tener esta data a mano, pero tampoco fue tan dificil. La wiki de Archlinux tiene un articulo para la maquina. Lamentablemente, a la hora de escribir esto, no habia informacion para los componentes de la mia (justo!:/ ). Asique dejo esto como complemento, algun valiente se animara a completar la info de la wiki.

Especificaciones del equipo
Intel® Core™ 2 Duo T6670 (2.20GHz, 2MB L2 Cache, 800MHz FSB)
13.3 inch UltraSharp™ WXGA LCD Display w/TrueLife™
4GB Shared Dual Channel DDR2 SDRAM at 800MHz, 2 DIMM
8X DVD+/-RW with double-layer DVD+/-R write capability, Roxio and Cyberlink PowerDVD™ DX 8.1 R
Deep Cherry Red with Intel® Intg Graphics Media Accelerator 4500M HD
250GB 5400RPM SATA Hard Drive
Dell Wireless™ 1397 802.11b/g Mini Card
Integrated 1.3MP Webcam and Digital Mic with webcam

xorg.conf

Section "ServerLayout"
Identifier "X.org Configured"
Screen 0 "Screen0" 0 0
InputDevice "Mouse0" "CorePointer"
InputDevice "Keyboard0" "CoreKeyboard"
EndSection

Section "Screen"
Identifier "Screen0"
Device "Card0"
Monitor "Monitor0"
SubSection "Display"
Viewport 0 0
Depth 1
EndSubSection
SubSection "Display"
Viewport 0 0
Depth 4
EndSubSection
SubSection "Display"
Viewport 0 0
Depth 8
EndSubSection
SubSection "Display"
Viewport 0 0
Depth 15
EndSubSection
SubSection "Display"
Viewport 0 0
Depth 16
EndSubSection
SubSection "Display"
Viewport 0 0
Depth 24
EndSubSection
EndSection


Placa de red
La placa anduvo derecho, haciendo modprobe ne2k-pci, igual que en mi maquina de escritorio.

Wireless setup (wifi)
Sobre este tema la wiki de arch tiene un muy buen articulo.
Se puede instalar un paquete desde AUR supuestamente. Yo segui las instrucciones del proveedor, y salio andando derechito

[root@delta]~-> lspci | grep BCM43
0e:00.0 Network controller: Broadcom Corporation BCM4312 802.11b/g (rev 01)


despues para levantar la interfaz hice


iwconfig eth0 essid MiRed key miClave



dhcpcd eth0


rc.conf (puede actualizarse)

#
# /etc/rc.conf - Main Configuration for Arch Linux
#

# -----------------------------------------------------------------------
# DAEMONS
# -----------------------------------------------------------------------
#
# Daemons to start at boot-up (in this order)
# - prefix a daemon with a ! to disable it
# - prefix a daemon with a @ to start it up in the background
#
DAEMONS=(syslog-ng network netfs crond dbus hal alsa gdm)


Webcam

[root@delta]~-> lsusb | grep Webcam
Bus 002 Device 002: ID 0c45:63e0 Microdia Sonix Integrated Webcam

No se que hice, creo que anduvo de una. Bajen el cheese con el pacman y prueben.
Eso si, habia que setear bien los permisos
# gpasswd -a video
# chmod 666 /dev/video0


KahelOS está basado en una distribución GNU/Linux simple. Está concebido para ser una distribución GNU/Linux que va evolucionando.

Está principalmente pensado para proveer lo mejor de ambos mundos para el usuario final de GNU/Linux.

Imagina el beneficio de la optimización, la robustez, la velocidad y ligereza, y el modelo de liberación continuo que sólo los expertos y gurus de GNU/Linux pueden desarrollar y la utilidad de combinar amistad con el usuario (GUI), que nuevos y moderados profesionales de GNU/Linux buscan para ser fácilmente productivos y tomar ventaja de lo que la tecnología del Código Abierto y la colaboración pueden brindar y hacer.

KahelOS en ambas ediciones, Servidor y Escritorio, puede legalmente proveerte de aplicaciones personales y empresariales que necesites.

La filosofía de KahelOS es Abierto para el Cambio.

Tomado y traducido de KahelOS

Como dice el título de la entrada esta distribución está basada en Archlinux y además usa el entorno de escritorio GNOME. Viene en un live CD gráfico, desde donde se puede instalar el sistema operativo a tu máquina.

KahelOS Posee la velocidad y simplicidad que ofrece Arch, pero a la vez la facilidad que no posee dicha distribución. Es una buena opción a probar si no te atreves a instalar Archlinux porque piensas que se te hará muy complicado o porque eres nuev@ en GNU/Linux.

Imagen tomada de (1). Clic para agrandar

Imagen tomada de (2). Clic para agrandar

¡Saludos!

(1)Seamos Realistas: KahelOs: Archlinux para escritorios y servidores

(2)Viva linux!: Kahel OS y Chakra Alpha 3

Llevo mucho sin escribir porque, como dije, tenía la necesidad de crear algo nuevo y creedme que lo he intentado.

Las cosas no son fáciles y es de entender que un proyecto como el que propuse sea algo difícil de llevar a cabo. No se trata de que sea una tortura, yo creo que se trata deque hagamos una web entre amigos/compañeros de fatigas.

Unamos nuestros esfuerzos, no?

Los motivos? ya los sabeis pero como es la última oportunidad que le voy a dar al proyecto pues los vuelvo a explicar:

- Los post duplicados: este un motivo para mi principal y es que en todas las webs que leo sobre Archlinux o lo que sea, me encuentro las mismas noticias.

- El trabajo es voluntario y gratificante: Es cierto que los que escriben lo hacen voluntariamente pero, queramos o no, hemos adquiridos un cuerdo tácito en el que nos comprometemos a continuar escribiendo para que alguien se beneficie de los datos que aportamos.

Aseguro, en mi caso, que nada es más gratificante que recibir un comentario a un escrito.

- Devolver a la comunidad: sigo pensando que en los años que llevo en esto (y podría sumar los que llevo con la informática en general) siempre he ido consumiendo lo que la Gran Comunidad de Internet me ha aportado pero rara vez he contribuido.

He mirado valoración de películas, música o libros, he solucionado mis problemas con el ordenador o la lavadora, hasta he encontrado consejos de toda índole pero rara vez he puesto un comentario dando las gracias, felicitando por el aporte, corrigiendo si había algún error o simlemente opinando sobre una película y… la verdad… me siento mal.

A veces cuesta hasta dar las gracias... pfff!

Creo que la gran mayoría hemos sido como yo en algún momento y, algunos han encontrado el camino de devolver el favor, pero yo, estoy en ello.

Este proyecto nace con la idea de contribuir a la comunidad de Linux en general, pero también de tecnología. No quiero cerrarme a nada, sólamente quiero crear un proyecto conjunto, con amigos y compañeros, con gente con ganas y compromiso. Está claro que todos tenemos cosas que hacer y que organizar algo así lleva mucho tiempo y es difícil pero, como me ha enseñado la programación (y el socio con el que la hice!), no hay cosas difíciles, hay más de una cosa junta. Sólo hay que desgranar, “divide y vencerás” que decía otro.

Lo que propongo:

El nombre ahora no recuerdo a quien se le ocurrió (puede ser xabz(?)) pero es un poco lo que quiero transmitir. entiendeatux. Ese es nuestro problema y al que podemos poner solución.

Propongo crear una web: www.entiendeatux.es como un clon de www.muycomputer.com pero con la salvedad de los temas que queremos tratar.

Y luego crear subdominios con los siguientes “blogs” administrados por parejas o más dependiendo de las secciones y siempre teniendo en cuenta que los problemas/soluciones/tutoriales iguales entre las distribuciones deberían ir a su subdominio p.ej. instalaciones.entiendeatux.es  pues siempre se instalan los mismos paquetes pero con la diferente manera según cada distribución (apt-get, pacman, yum, etc…).

Será que no teemos cosas de que escribir? Y no sólo de Linux vive el hombre tecnología, música de linuxeros (creo que es bastante diferente a la mayoría), artwork, telefonía, competencia, reflexiones… mil temas…

Incluso me atreví a hacer un diseño “mock up” de la web a ver si daba ánimos aunque luego parece o, a lo mejor, se quede en nada. Lo pondré por si a alguien le interesa

No se si le gustará a alguien pero lo hice con ganas y... bueno, eso es todo!

No sé, a lo mejor es demasiado aunque una de las ventajas que creo que ya he dicho es que si lohacemos entre varios y luego lo mntenemos entre varios, nos podemos cubrir cuando alguien no puede/quiere escribir.

Sueño de un lunático? Puede ser pero creo que a matkiber… le hubiera gustado conseguirlo, igual que a mí, pero necesitamos más gente, más recursos, más compromiso y más ganas.

Algún valiente se atreve? XD

Alguien se atreve?

P.D.= Si no lo consigo esta vez… vuelvo al blog y seguiré como hasta ahora… no os librareis de mí tan fácilmente muaaaahahahahaha!

Неожиданно пров что-то накуралесил у себя с DHCP.
Винда починилась при помощи магии, а именно запуском в безопасном режиме с поддержкой сети. После перезагрузки всё встало на свои места.
С Archlinux проблема решалась перезапуском сетевого демона и последующим ручным поднятием впн для доступа в интернет, но в век автоматизации такой метод дозагрузки не подходит. Решил методом добавление в /etc/rc.local перед строкой запуска VPN запуск dhcpcd.
Как результат вроде как нормальная загрузка сети.
Побочный эффект: увеличение времени загрузки системы т.к. на этапе загрузки network долго висит в состоянии busy, а после ещё dhcpcd получает адреса.
В общем, продолжаем копать…

Ya terminé la segunda parte del screencast de ArchLinux. En la primera parte habíamos visto como instalar un sistema base. En esta segunda parte se deja el sistema preparado para instalar un entorno gráfico como puede ser Gnome (Parte 3) o KDE (parte 4).

• Actualizar el sistema
• Añadir usuarios
• Configurar “sudo”
• Instalar y configurar “ALSA”
• Instalar y configurar “Xorg”
• Instalar los drivers para las tarjetas gráficas ATI y NVIDIA

+ Screencast ArchLinux | Parte 1

Vimeo | Screencast Instalación ArchLinux (Parte 2)

Youtube | Screencast Instalación ArchLinux (Parte 2) (HQ)

Descarga | Screencast-Parte-2.avi (1024×576) (121 MB) (Es necesario tener una cuenta de Vimeo)

• Qué hacer después de instalar Fedora 12 Constantine | Post-Instalación

• Fedora ya no es el mismo de antes… ¿será cierto?

• Paquetón de repositorios para ArchLinux

• Programando con Go (El lenguaje de Programacion de Google)

• Linux, en el 90% de los supercomputadores

Aunque usando Recordmydestkop podemos obtener muy buenos resultados, leyendo en el foro de ArchLinux encontré un script muy interesante que permite realizar screencast en formato “lossless”, es decir sin perdida de calidad, usando el códec x264. El script es muy sencillo de utilizar. Tiene las siguientes opciones que debemos tener en cuenta a la hora de realizar la captura.

• -o Aquí escogeremos el nombre del archivo de vídeo, la ruta donde guardarlo y el contenedor a usar. Podemos escoger entre mp4, mkv y avi. Por ejemplo, -o test.mp4
• -p Permite seleccionar el perfil para codificar el vídeo. Podemos ver todas las opciones en /usr/share/ffmpeg. Por defecto utiliza “lossless_slow”
• -c Aquí escogemos el códec. Por defecto utiliza “x264″ pero también podéis usar Theora, por ejemplo.
• -i Si añadimos este parámetro antes de comenzar a capturar nos preguntará por la ventana que queremos grabar. Muy útil, por ejemplo si sólo nos interesa grabar la terminal o una aplicación en concreto.
• -r En este parámetro se especifican los FPS del vídeo. Por defecto viene configurado en 15, yo lo suelo cambiar a 25.
• -f Si añadimos este parámetro al ejecutar el script realizará una captura a pantalla completa.

Un ejemplo sería el siguiente:

./lossless_screencast.sh -o ~/screencast.mp4 -i -r 25

En este caso utilizaría en contenedor “mp4″, utilizando el códec “x264″ (por defecto) a 25 FPS, y añadiría el parámetro -i para seleccionar la ventana que quiero grabar.

Descarga | x264 Lossless Screencast Script

Fuente | ArchLinux Forums

Se acaba de liberar una nueva versión de Banshee, la 1.5.2. Se trata de una versión centrada en la corrección de bugs, aunque no por ello libre de nuevas funciones, como por ejemplo, la herramienta para importar del iTunes, mejoras en la edición de los tags y soporte para nuevos dispositivos.

Fedora

su -c ‘yum update banshee’

ArchLinux

sudo pacman -Syu

Ubuntu

Agregáis este repositorio de Launchpad y posteriormente actualizáis

sudo aptitude update banshee

Descarga | Banshee 1.5.2

Ho trovato questo interessante script sul Forum Internazionale per far si che anche con openbox venga visualizzata una bella notifica OSD al cambio del livello del volume.. l’ho interfacciata con la rotellina volume del mio portatile tramite xbindkeys e funziona egregiamente.. ecco un piccolo screen

Potete dunque capire qual’è il mio setup attuale, dopo aver mollato GNOME ed essere ufficialmente diventato a livello di DE, un utente senza fissa dimora ^^

De seguro cuando vas a reinstalar tu sistema, por el motivo que sea, te da una “lata” enorme tener que volver a ingresar en la terminal cada uno de los paquetes que necesitas y que seguramente tenías instalados en tu Archlinux antes de reinstalar. Pues bien, el siguiente comando, crea un registro o una lista con todos los paquetes instalados, mediante pacman, en tu sistema:

$ sudo pacman -Qe > paquetes_instalados.txt

Luego, para instalar todos los paquetes contenidos en la lista generada, corre el siguiente comando:

$ sudo for x in $(cat paquetes_instalados.txt); do pacman -S $x; done

Con eso de seguro te ahorrarás mucho trabajo al momento de hacer la instalación nueva de Archlinux.

Lo que es yo, prefiero ir haciéndolo todo paso a paso, para que todo quede lo mejor posible, pues si bien es cierto que puede resultar ser un buen método, el mostrado en esta entrada, no me confío mucho de las automatizaciones.

Saludos y ojalá a alguien le sirva.

Fuente | Tux Training: Create a List of all installed packages on Arch Linux

Si eres de los jugones y que más encima te gustan las consolas de Nintendo, de seguro conoces VisualBoyAdvance un emulador para GBA que se encuentra disponible para GNU/Linux entre otros. Como sabrás VBA está abandonado hace un buen tiempo, es por ello, que nace VBA-M, con el objetivo de mejorar VisualBoyAdvance^[1] y retomar la emulación de la GBA en nuestros computadores.

El proyecto aún está en pañales (y la verdad, desde septiembre de 2009, no lo han actualizado mucho), sin embargo, se supone, ofrece una mejor emulación de roms de GBA en comparación a VBA puesto que está basado en ese último y ya se le han agregado varias modificaciones.

Si quieres probar VBA-M puedes descargar un SVN build desde la página oficial de descargas empaquetado para debian (.deb) o distros derivadas. Aún no se ha lanzado alguna versión del emulador, es por ello, que sólo están disponibles a fecha de hoy (20 de Noviembre de 2009) dichos SVN build.

Sin embargo, te recomiendo instalar la versión SVN y actualizarla cuando se informe en la página de VBA-M en SourceForge, que una nueva revisión ha sido lanzada. Puedes encontrar más información al respecto aquí.

Si usas Archlinux, estás de suerte, porque existe en el AUR un PKGBUILD para instalar la versión SVN del programa. Si usas yaourt no es más trabajo que:

$ yaourt -S vba-m-gtk-svn

Recuerda que para actualizar la aplicación a una nueva revisión, sólo debes generar y luego instalar el paquete .pkg.tar.gz correspondiente, con el mismo comando antes usado.

Página de VBA-M en SourceForge

Sitio web oficial de VBA-M

Otro sitio web, al parecer oficial pero en desuso

Saludos.

^[1]SourceForge: VBA-M

Arch Linux

written by Ilya Ilembitov

Original article is in the Arch Forum in “Topics going nowhere” section. Obviously Arch mods felt the need to trash this article as this subject is often brought up there and do not end receiving very useful replies. I thought it was a good read and asked “ilembitov“ if I could post his article here. So here is what he said , his exact words:

Hi, all. Reading a lot of Linux forums (not only this one) I can see the major problems of all Arch users: Arch Linux is bleeding edge, but it also has the unpredictable updates. Which is why you can see posts like “I haven’t updated my system in a while, today I ran the update routine, and basically, nothing works”. Which is not to mention less dramatic, but more frequent complaints like “I updated the package foo and I got myself into troubles”. Besides, I believe that the introduction of the LTS kernel is actually a good sign that there are also users who need Arch to be stable.

Ok, I started thinking about what should a user do, so that things like that wouldn’t happen. Here is my short howto.

1. Basically, as soon as you have freshly installed your Arch system and all the desired apps, copy the list of installed packages to the IgnorePkg section of /etc/pacman.conf
This way, when a new package comes out, it won’t be automatically updated.
2. If some package doesn’t work for you as expected (and you know that it’s due to an upstream bug or maintainer’s mistake), delete it from that section and update it until the problem gets solved – then get it back to IgnorePkg
3. You should only make transition to a next major release of anything when it makes sense. Say, the new version of the kernel has a better support for your hardware, or runs faster. Or a program you use gets a new feature and you do need that feature. If there are no changes for you, why bother? But even when you do need to upgrade, do not update the package as soon as it leaves /testing! There is also another reason to upgrade a package – when it’s required (as a dependency) to upgrade a package you need.
4. A package in Arch repos has the upstream version as well as the internal version that comes from maintainers. So, after the package has hit the repos, you better wait until the internal version goes higher: that means, people have bumped into problems with upgrading it (even though it’s not /testing already), maintainers have fixed it, you are less likely to get surprises. Even better if you also wait until some bugfix releases to appear upstream as well.
5. As soon as you make the transition and get to the state when everything goes okay, get the package back to IgnorePkg and work. Until next major update you need! (then roll back to the step 3).

I guess, that sounds reasonable. But why does one have to do that? Here is the thing.

As far as I understand, this is how the major update of the package gets to Arch:
1. It hits the /testing
2. People who actually use testing (and the maintainer, if he has chosen to support this package in the repos because he actually uses it on a regular basis and needs it to work) upgrade, bump into troubles. Troubles from upstream, but also troubles due to a maintainer’s mistake. People write bug reports. It it’s the maintainer’s fault, he fixes that. People try that again, write bug reports, etc.
3. The cycle in number 2. goes on until there are no bug reports for some time. Then the package goes to /extra or /core
4. People who do not use /testing, update to this new version. They bump into troubles, write bug reports and so on and so on.

So basically, it may sound reasonable. But still one actually can’t just upgrade without worry while using the current (non /testing) repos. So, there must be a problem. Which is?..

It’s obvious. Arch is already a bleeding edge distro. So, who is going to use the testing repo of the bleeding edge distro? I’m afraid, not many. A lot less than people who don’t. That means, that there is less probability someone would notice a bug while the package is in /testing. Or, possibly, there could also be no one to do that! So, /testing doesn’t do the job it’s expected to do, or just doesn’t solve the problem completely.

This is why problems happen. My post was caused by a discussion on a Russian Linux-related forum: a user has complained that (among other troubles) after an upgrade to GNOME 2.28 he got issues with Nautilus. And he was asking for an advice, whether or not he should switch to Debian testing. In the neighbor thread Debian Testing users were discussing the following: why the hell didn’t the Debian maintainers update Nautilus to 2.28 in testing while the other GNOME packages were upgraded? I’m sure I don’t need to point out the irony here.

OK, one could get a foil cap and apply my solution to the problem. Which is basically: wait until other users bump into troubles, those will get sorted out – then you make an upgrade. This is time-consuming, but also more flexible. Perhaps, this is the part of the Arch way. Like, Slackware users don’t want somebody else to define dependencies for them, so Arch users don’t want somebody to do Q&A for them, thus restricting their freedom.

So, we don’t need to change anything and everybody just gets along? Not really. Let’s just imagine everybody applies my approach. And it’s pretty reasonable, isn’t it? If you aren’t getting any benefit from an upgrade – why bother? If you do need to upgrade – why risk, those who feel like experimenting or just aren’t wise enough will do the dirty job. The point is, that when everybody applies this approach, there are no “risk takers” or “unreasonable ones”. And this is where the whole thing gets stuck. OK, actually I don’t really believe all Archers are going to do that. But I guess this is a good illustration why current model isn’t perfect.

There is a reason why it works in Debian unstable->testing chain (which basically lives like a rolling release system when there is a lot of time until the next stable Debian release). Because Debian userbase is large. There are lots of people who use testing and sid. There are other distros that are based on testing and sid (not to mention Ubuntu – there is also Sidux, for example). Arch just doesn’t have that. And so, it doesn’t work out for him.

My point is not about switching to traditional release cycle (I don’t think anyone would seriously consider it). Arch is partially fine because it doesn’t have releases. But there is also another thing. Arch has lots of things other distros don’t have. Pacman, ABS, AUR, configuration being done via the /etc/rc.conf, etc. What if a user wants to have all these and not have troubles with upgrades? Does he have to stick with the paranoid IgnorePkg approach to get a stable and predictable system?

Of course, we can’t just develop a universal solution against maintainers’ mistakes or upstream bugs. People do mistakes (I really didn’t mean to offend the maintainers here), and apps can’t be bug-free. But we should develop a system to detect those issues before they get to the end user machine. Perhaps, we should track the statistics of previous troubles caused by the package and consider it to define the time the package should spend in /testing after the last solved bug report before it gets out if no show-stoppers occur. Okay, may be that will do Arch less bleeding edge, but it will also cause more people to try installing versions from testing (and, consequently, lessen the time needed for it to get to /extra or /core). Perhaps, the package should also automatically roll back to the previous stable version if the recent upgrade was reported to have a serious issue (with the upgrade getting back to /testing). There is /var/cache for that, but this still could make upgrades more reliable.

Sorry for this pretty wordy article. But I do believe that the issue is pretty important. Perhaps, I don’t have the right picture (for example, may be the testing repo is more complicated than that). I would like those heroes who managed to get through this sea of words  to share some ideas.

And Arch Mods and Users then emphasized on the fact how important it is for Arch being a community driven distro to depend on it’s users to run the [testing] repository and file bug reports. My question: Who gets to enjoy the stable product then? Clearly, Arch is not about stability. Bleeding edge and stability can never go hand in hand. Atleast Arch devs are not hiding this fact and stating it bluntly, but yes there are some people who go to other forums *cough ubuntuforum cough* and whine about Arch being unstable and it broke their system.

B [Arch forum Mod] wrote:

I like how users feel like a victim when this thing (a community-driven distro) only thrives when both users and devs alike provide input and feedback. And most Arch users only complain ‘OMFG ITS BORKEN’ when it actually breaks, but never a) run testing or b) report bugs. Maybe you’ll see them saying ‘oooh distro X has shiny  new feature Y. When is it in Arch!?88′.

Then what do you expect?

Even Ubuntu users seem to be more active on that front. Seriously. Also, if you can’t fix what breaks during upgrades, then Arch is not for you. Period. Either you got what it takes or you don’t. I see a *lot* of people here that seem to be running Arch for a while yet don’t have a clue of the very basics. There are distros that cater to that kind of public.

Later part of ilembitov’s reply:

Actually many people here have probably gotten the wrong idea of why I described the IgnorePkg approach. It’s all about rethorics – I guess that it’s good that many people have found this technique bad in some way. Basically, I believe, this was the ultimate summary of all advices that people give somebody when he says that Arch is too unstable for him, yet he likes being bleeding edge. In such discussions people usually either mention the /var/cache/ approach for rolling back or the IgnorePkg thing (which are actually equivalent). I have just thought of an ultimate solution on this basis. It just takes the whole thing to an extreme. And actually, such a solution roughly imitates what maintainers in larger, non-rolling distros do: this is pretty much the way Debian (or Ubuntu) people make their stable release (or stable + backports repo, for that matter). And my point was to (while still taking things to an extreme) show why this thing is by design wrong – the same way all actually popular approaches taking the similar direction are wrong. And certainly I did not recommend this HowTo. I believe this solution to actually solve the problem of one user completely yet creating a lot more problems in the long run for Arch Linux. Moreover, I have tried hard to show that currently, a rolling release-based distro pretty much involves techniques that are common in different projects – and thus, inappropriate.

So my point was – we should redesign the process (and this is why I wanted to provoke a brainstorm sort of thing). People who started protecting maintainers have a clear misconcept of what I was talking about. I did not intend to blame the maintainers. That’s unethical and anyways, it doesn’t relate to the topic. I believe that, ArchLinux, being a non-mainstream distro will always have less maintainers and less users (thus, less bug reports) than needed. The thing is, how to redesign the process so that the lack of resources will be less noticeable. Design the fail-proof mechanisms in the process when things have already gotten nasty – and design the mechanisms and procedures so that things will be less nasty. That may involve encouraging the use of /testing (I was actually surprised by somebody mentioning that basically it’s a bad idea to use /testing only partially. I always thought I would be fine to install an app from testing provided I have satisfied all the dependencies with required versions. And this is also a problem.) That may involve redefining the policy that the maintainers should follow when the packages that got out of /testing have revealed show-stoppers. This is what I was talking about.

Oh, and more thing. People who believe that Arch is okay to have these kind of issues and that users should be ready to deal with them or just leave – they actually mistake an advanced user-oriented product for low-quality and poorly-designed product. It’s about enjoying the flexibility and other virtues of Arch and not enjoying its flaws because you are proud you “have survived”. After all, software, even being fun, still has one major point – it should work.

All I gotta say is that, brace yourself for any package breakage and system instability if you use Arch and don’t complain about it. Don’t feel like a victim, you have been warned! It’s not a bug, it’s a feature.

En los foros de Archlinux-es me encontré un tip que sugería un usuario a otro, el cual consistía en optimizar los repositorios que tenemos en nuestro mirrorlist. Anduve investigando y resulta ser un sencillísimo proceso.

Habrá que hacer uso del paquete llamado rankmirrors que viene incluido en el sistema base de Archlinux.

Antes de iniciar es importante descomentar todos los repositorios que tenemos en el archivo /etc/pacman.d/mirrorlist

Movernos al directorio:
# cd /etc/pacman.d/

Reespaldar:
# cp mirrorlist mirrorlist.asdf

# rankmirrors -v -n 5 mirrorlist.asdf > mirrorlist

Con el parámetro -v (verbose) le estamos especificando que haga un análisis mas “profundo”.
-n X enumera los mejores 5 repositorios de la lista que tenemos en el archivo.

Y listo!

Con un pacman -Syu podemos comprobar lo EFICIENTE que puede ser. Por lo general siempre que actualizaba o quería instalar un paquete pesado me conectaba con ethernet y descargaba a ~100 K/s, ahora puedo descargar a ~400 K/s en wifi!!!1

Pacman… es el pedo.

Aunque últimamente no suelo jugar mucho, no está mal, de vez en cuando, jugar una o dos partidas. Y si es en Linux mejor. Antes solía jugar al OpenArena, hasta que probé Nexuiz. Un juego de acción en primera persona, futurista y muy similar al OpenArena o al Quake. Yo creo que tiene los mejores gráficos de todos los juegos que hay para linux. Además es libre, multiplataforma y es un proyecto activo con regulares actualizaciones, la maś reciente el 29 de septiembre. Tiene una comunidad bastante grande, por lo que si eres de los que prefiere jugar online siempre encontrarás partidas a las que unirte.

Si usas linux y además eres un gran jugón, Nexuiz te va a encantar.

Fedora

Para instalarlo en Fedora abrimos una terminal y escribimos el siguiente comando.

yum install nexuiz

ArchLinux

En ArchLinux, también está en los repositorios oficiales, asi que abrimos una terminal y usamos pacman.

pacman -Sy nexuiz

Recuerda que para poder jugar necesitas tener aceleración 3D, por lo que en la mayoría de los casos deberás instalar el driver privado para tu tarjeta gráfica.

+ Web de Nexuiz

Quienes usamos algún Linux que compila y distribuye por si mismos binarios de Firefox (no oficiales) como Archlinux, usamos Firefox con diferente nombre, en este caso Shiretoko, un simple tecnisismo

Usando wordpress, me encontré con la necesidad de instalar Gears en mi Shiretoko de Archlinux, el problema era que el script que detectaba si el browser era compatible no lo notaba y no me permitía instalarlo, para solocionarlo, abrí una nueva pestaña y busqué “shiretoko”.

La solución fue modificar el valor “Shiretoko/3.5.4″ de la clave general.useragent.extra.firefox por el valor “Firefox/3.5.4″ y luego, refrescando la página de instalación de Gears, fue posible la instalación.

Navegando por ahí, me encontré en el blog de Arcalinux, un post donde citaba un comando para que mostrara una lista de los paquetes imas pesados instalados con el gestor de paquetes de Debian. Entonces me acordé de una aplicación que conocí hace unos meses, la cual te genera de manera gráfica (o no) los paquetes que tenemos instalados pero con el gestor de paquetes Pacman, el mejor a mi gusto hasta ahora.
Dicha aplicación se encarga de enlazar por medio de hilos las dependencias entre los diversos paquetes, o no.

Podemos instalarlo en Archlinux desde [AUR] con yaourt -Sy pacgraph

Aquí dejo mi resultado:

(click)

En la ayuda de pacgraph podemos ver algunas de las opciones como lo son: mostrar el resultado en texto en consola, personalizar colores, tamaño, compresión, etcétera…

pacgraph --help

Et oui, c’est maintenant possible de s’affranchir totalement d’itunes !!
Il faut par contre avoir jailbreaker l’iphone ou l’itouch (voir billet précédent)

Les étapes à suivre pour la préparation de tout le bazar :

1) Installer ifuse depuis AUR (qui installera en dépendance usbmuxd, libplist, libiphone) yaourt ifuse

2) Créer un utilisateur “usbmux” sur le systeme et qui a acces aux périphériques de stockage (ceci est nécessaire pour usbmuxd)

3) Installer Gtkpod, qui permet de gérer les musiques de l’ipod yaourt gtkpod

4) Créer le répertoire pour monter le système de fichier de l’ipod sudo mkdir /media/ipod

5) On branche en USB le petit ipod puis dans une console : sudo ifuse /media/ipod --root

6) sudo kate /media/ipod/System/Library/Lockdown/Checkpoint.xml : on édite le fichier et on recherche “DBVersion”, a la ligne du dessous, on remplace <integer>4</integer> par <integer>2</integer>. On sauvegarde puis on ferme kate.

7) On démonte l’ipod du système : sudo umount ifuse

On déconnecte le cable USB et on reboot l’ipod. On y est presque, encore une petite chose à regler pour que gtkpod puisse acceder a la bibliothèque de l’ipod : il faut déterminer le Firewire GUID.

9) On reconnecte en USB l’ipod touch et dans une console : sudo lsusb -v | grep -i iSerial On prend alors la plus longue chaine et on copie les 16 premiers caractères

10) On monte l’ipod avec sudo ifuse /media/ipod (pas de “–root” cette fois ci) et on créer un répertoire sudo mkdir -p /media/ipod/iTunes_Control/Device

11) Pour finir on ajoute une ligne avec notre numéro de série (les 16 premiers chiffres trouvés en 9) ) : sudo kate /media/ipod/iTunes_Control/Device/SysInfo et rajouter Firewire GUID:0xaaaaaaaaaaaaaaaa (remplacer les 16 “a” par le numero de série trouvé en 9)

12) Voilà, maintenant ça devrait être bon, tout est (enfin) prêt ! On démonte l’ipod avec sudo umount ifuse.

Connecter l’ipod et gérer la bibliothèque :

1) Connecter l’ipod avec le cable USB puis sudo ifuse /media/ipod

2) Ouvrir gtkpod et notre ipod apparait avec les musiques à l’intérieur et on peut en rajouter facilement !

3) Lorsque l’on a fini de transférer des musiques, ne pas oublier de faire “enregistrer” pour que la base de donnée de l’ipod soit actualisée. On ferme gtkpod.

4) Dans une console, on démonte l’ipod sudo umount ifuse

Problèmes possibles :

Si en voulant monter l’ipod on a cette erreur :
No device found, is it connected?
If it is make sure that your user has permissions to access the raw usb device.
If you’re still having issues try unplugging the device and reconnecting it.

il est possible que usbmuxd ne se lance pas correctement, dans ce cas ouvrir une autre console puis faire sudo usbmuxd -f

S’il n’y a pas d’erreur qui s’affiche, laisser cette console ouverte et dans l’autre faites sudo ifuse /media/ipod.
Si un message dit que usbmuxd est déjà ouvert, faites un sudo kill -9 ‘PID’ (le ‘PID’ est donné dans le message d’erreur) puis sudo usbmuxd -f

Para instalar Moblin en ArchLinux hay que seguir una serie de pasos porque a diferencia de otros escritorio como KDE o Gnome no se encuentra en los repositorios oficiales. (De momento… ).

Para instalar Moblin nos ayudaremos de Yaourt, asi que si no tienes instalada esta herramienta puede leer aquí cómo hacerlo. Este tutorial está pensado para realizarlo desde una instalación base, así que si ya tienes instalado un escritorio es posible que algunos paquetes ya los tengas en tu sistema.

Antes de nada instalaremos los siguientes paquetes.

yaourt -S git gnome-common intltool mesa

Y ahora ya podemos instalar Moblin.

yaourt -S libccss librest-git jana-git mux-git clutter-git nbtk-git gconnman-git carrick-ng-git dalston-git bickley-git bognor-regis-git hornsey-git mojito-git bisho-git anerley-git gir-repository-git mutter-git mutter-moblin-git moblin-gtk-engine-git moblin-icon-theme-git moblin-menus-git moblin-session-git

Al instalar, nbtk-git y hornsey-git debemos modificar el pkgbuild, y en dependencias, en vez de libccss-git, debemos poner libccss. Además en hornsey-git cambiaremos la dependencia clutter-gst por glutter-gst-git. Si tenemos problemas al compilar mutter-git, modificaremos el pkgbuild, y en la linea:

–with-clutter || return 1

Agreagamos lo siguiente: –without-introspection, de modo que quede así:

–with-clutter –without-introspection || return 1

Nota: Ten en cuenta que arriba son dos barras (-) seguidas, pero el editor las junta automáticamente.

Al compilar moblin-session-git, seguramente aparezca un error de md5sums. Para solucionarlo editamos el pkgbuild comentando (#) esa linea.

Ahora modificamos el archivo de configuración de arranque de Moblin.

sudo nano /etc/xdg/moblin/xinitrc

Y cambiamos Metacity por Mutter en la última línea. Es decir, pasamos de esto:

metacity –sm-disable

A esto:

mutter –sm-disable –mutter-plugins=moblin-netbook

En teoría, si hemos realizado todos estos pasos, Moblin ya debería estar instalado. Ya para terminar (o casi), modificamos el archivo xinitrc para arrancar Moblin durante el inicio.

nano ~/.xinitrc

Y añadimos la siguiente línea:

exec startmoblin

Y comentamos todo lo demás. Por último (ahora sí que sí) añadimos los demonios “pulseaudio” y “conmand” en el archvio rc.conf

sudo nano /etc/rc.conf

Buscamos la línea DAEMONS y los añadimos. Listo! Sólo queda reiniciar y disfrutar de ArchLinux, ahora también, en el Netbook.

Vía | Archxz

Pues ya se puede descargar el diseño de los discos y portadas de Fedora 12. A mi me gusta mucho (más que el de Ubuntu 9.10)

+ Fedora 12 Media Art

Vía | Fedoreando