Android

2010-04-10 14:51

Conswguí la imagen de testing de Android 2.0 de http://android-x86.org. Probé la "estable" 1.6 "stable" pero... era horrible, la mitad de las teclas o opciones de menú hacían que se colgara, reiniciara o se prendiera fuego.

Entonces... ¿cómo va? ¡Lento, pero con potencial!

Lo malo:

Arranca rápido... pero mi Arch Linux arranca más rápido.
Es leeeeento, podés ver cada letra individaual cuando escribís en el coso de búsqueda. Leí que es temporal. Ojalá!
Estoy con una experiencia limitada en aplicaciones porque los "android stores" libres no están tan provistos como el "android marketplace" oficial (¿y porqué corno no puedo bajar apps gratis de ahí????)

Veo agujeros obvios en el panorama de aplicaciones que supongo están bien cubiertos en el marketplace (como, ¿hay un reemplazo para RadioTray?)

¿No hay editor de texto?

¿No hay un procesador de texto semi-decente? ¿Ni siquiera uno que genere HTML?
El web browser es patético. Tal vez esté bien para un teléfono, pero ¿para un sistema "real"? Es horrible. Te da la versión móbil de todos los sitios (obvio) y muchos no te dejan pasar a la "real" (hasta google con el Google Reader), y por supuesto, no hay flash.
El cliente de correo es terrible. No podés no hacer top-posting!!!! "In-Reply-To" está roto!
Las opciones de WiFi están demasiado escondidas. Deberían poderse sacar del icono de wifi.

Lo bueno:

Se apaga muy rápido.
Algunas apps están buenas, especialmente el Aldiko book reader es buenísimo (y puedo compartir los ePub con el fbReader del lado de arch.
El cliemte SSH tiene buenas ideas.
Me gusta mucho el enfoque de "todas tus cosas están en el SD". Hago exactamente lo mismo en Linux. De hecho tengo exactamente la misma organización en los dos sistemas operativos.
La pantalla home con el cajón deslizante de aplicaciones: lindo
La barra de notificaciones "agarrable": muy lindo
Lo de "apretá la tecla menú para ver el menú"? Genio ;-)
Lo de "todo fullscreen todo el tiempo"? Funciona en esta pantalla.
La instalación de aplicaciones es un problema solucionado.
Sé que voy a tener Qt nativo y no puedo esperar!

Todavía no estoy convenciso, Arch es mucho más rápido por ahora, y hace muchas más cosas pero...

Me encargué una pantalla táctil para tener la experiencia como se supone que hay que tenerla.
Lo uso mucho para leer de noche en la cama (Recién terminé Makers, léanlo, está bueno!).
Lo estoy usando para leer correo de vez en cuando (me niego a responder con esa porquería)
Es un despertador bastabte bueno, así que ahora es mi sistema operativo de mesa de luz.

Voy a escribir otro reporte una vez que tenga la pantalla táctil y/o una versión nueva (y ojalá que más rápida).

Empaquetar es DIFÍCIL

2010-02-11 14:00

O ni siquiera eso, quiero que la gente tenga la oportunidad de usarlo.

Eso significa que quiero que funcione en Windows (y tal vez en OSX algún día, si alguien me da una mano). Lo que significa que tengo que hacer una versión para Windows.

hagamos una comparación rápida desde el punto de vista del usuario y del desarrollador.

El usuario, en Linux

Esto es en Arch Linux, que es lo que yo uso, en otras variantes es más o menos lo mismo una vez que Marave sea mas conocido.

yaourt -S marave-svn --noconfirm

Eso obtiene el código de SVN (por ahora es lo mejor, más adelante empaquetaré releases), todas las dependencias, y lo instala. Tarda unos 15 segundos en mi notebook.

Después de eso, tenés un Marave funcionando.

En caso de que no esté en tu distro, tenés que instalar PyQt (que seguro si está) y correr:

easy_install marave

El usuario, en windows

Vas a http://marave.googlecode.com, click en "Marave-0.5.win32.exe" (No lo busques, todavía no está) bajás un programa de 10MB. Eso es un programa de 10MB porque windows no cree en paquetes y en dependencias. En Linux un paquete de Marave sería 1MB (casi todo imágenes), y sería datos, no ejecutable.

Por supuesto hoy en día un browser no te ejecuta un programa que bajaste, asi que... hagamos una galería!

Sí, guardar.

Doble click para abrir.

Sí, estoy de acuerdo.

Hmmm, bueno.

Bárbaro...

Genial!

Ahora este Marave puede funcionar o no pero eso es para más adelante...

El desarrollador, en Linux

Primero, este es el mayor problema un "empaquetador" puede tener en Linux:

Como Marave es una aplicación nueva, y la desarrollo en Arch Linux que es medio cutting edge, usa features que sólo están en versiones nuevas de PyQt. De hecho no funciona con PyQt < 4.6, que no está en algunas distros "lentas" o en un Ubuntu que no es el último.

Solución? Bueno, podría ignorarlo, pero que tanto, vamos a arreglarlo!

Graias a PyInstaller ni siquiera es tan difícil, este es el archivo spec:

a = Analysis([os.path.join(HOMEPATH,'support/_mountzlib.py'), os.path.join(HOMEPATH,'support/useUnicode.py'), 'marave/main.py'],
            pathex=['/home/ralsina/trunk/trunk'])

pyz = PYZ(a.pure)
exe = EXE(pyz,
        a.scripts,
        exclude_binaries=1,
        name=os.path.join('build/pyi.linux2/main', 'marave.exe'),
        debug=False,
        strip=False,
        upx=True,
        console=0 )

coll = COLLECT( exe,
            a.binaries,
            [('radios.txt','marave/radios.txt','DATA')],
            Tree('marave/icons','icons'),
            Tree('marave/backgrounds','backgrounds'),
            Tree('marave/clicks','clicks'),
            Tree('marave/stylesheets','stylesheets'),
            Tree('marave/themes','themes'),
            a.zipfiles,
            a.datas,
            strip=False,
            upx=True,
            name=os.path.join('dist', 'marave'))

Usando esto, PyInstaller produce una linda carpeta llena de todo lo que Marave necesita para funcionar en cualquier Linux.

Por otro lado, si se puede contar con que haya un PyQt reciente disponible, también es fácil. Éste es el archivo de configuración para un paquete similar en Arch Linux (todavía no hice uno para Marave). Para otros Linux es más o menos lo mismo, y normalmente alguien te lo hace:

# Contributor: Roberto Alsina <ralsina@kde.org>
pkgname=python-rst2pdf
pkgver=0.12.1
pkgrel=4
pkgdesc="Create PDFs from simple text markup, no LaTeX required."
arch=('i686' 'x86_64')
url="http://rst2pdf.googlecode.com"
license=('custom')
depends=('python' 'setuptools' 'docutils' 'pygments' 'python-reportlab' 'python-simplejson' 'pil')
source=(http://rst2pdf.googlecode.com/files/rst2pdf-$pkgver.tar.gz LICENSE.txt)
optdepends=('uniconvertor: vector images support'
            'python-svglib: SVG support'
            'python-wordaxe: hyphenation'
            'pythonmagick: PDF images support')
build() {
cd $startdir/src/rst2pdf-$pkgver
python setup.py install --root=$startdir/pkg || return 1
install -D ../LICENSE.txt $startdir/pkg/usr/share/licenses/python-rst2pdf/COPYING
install -D doc/rst2pdf.1 $startdir/pkg/usr/share/man/man1/rst2pdf.1
}
md5sums=('ea6beda9a46f34ba42c4c94d48cc607a'
        '416f8046c66b9476cdbacda69a673afe')

Y eso es todo lo que hay que saber del proceso de empaquetar tu aplicación para Linux, es fácil de hacer, y la mayor parte del tiempo, fácil de hacer bien.

Ahora, la sección final...

Windows para el desarrollador

¿Primero, te acordás de eso de depender de la versión de sistema de Qt? Olvídalo, no hay versión de sistema. Tampoco hay Python, así que no importa. Y nadie los va a instalar para tu aplicación, así que tenemos que meter todo nosotros, o nada.

Pero lo bueno es que PyInstaller funciona para Windows! Entonces, usando el mismo spec funciona, no?

Bueno, hay dos problemas...

Problema 1: El instalador

Los usuarios de Windows no van a abrir un zip y conectar el binario con el menú de inicio ni nada parecido, así que hay que hacer un instalador.

Esto es lo que hice para NSIS, un creador de instaladores gratuito:

;--------------------------------
;Include Modern UI

!include "MUI2.nsh"

;--------------------------------
;General

;Name and file
Name "Marave"
OutFile "Marave-0.5.win32.exe"

;Default installation folder
InstallDir "$LOCALAPPDATA\Marave"

;Get installation folder from registry if available
InstallDirRegKey HKCU "Software\Marave" ""

;Request application privileges for Windows Vista
RequestExecutionLevel user

;--------------------------------
;Interface Settings

!define MUI_ABORTWARNING

;--------------------------------
;Pages

!insertmacro MUI_PAGE_LICENSE "LICENSE"
!insertmacro MUI_PAGE_DIRECTORY
!insertmacro MUI_PAGE_INSTFILES

!insertmacro MUI_UNPAGE_CONFIRM
!insertmacro MUI_UNPAGE_INSTFILES

;--------------------------------
;Languages

!insertmacro MUI_LANGUAGE "English"

;--------------------------------
;Installer Sections

Section "Install"

SetOutPath "$INSTDIR"
File /r "dist\marave"


;Store installation folder
WriteRegStr HKCU "Software\Marave" "" $INSTDIR

;Create uninstaller
WriteUninstaller "$INSTDIR\Uninstall.exe"

;Create shortcuts
CreateDirectory $SMPROGRAMS\Marave
CreateShortCut "$SMPROGRAMS\Marave\Marave.lnk" "$INSTDIR\marave\marave.exe" ; use defaults for parameters, icon, etc.
CreateShortCut "$SMPROGRAMS\Marave\Uninstall Marave.lnk" "$INSTDIR\Uninstall.exe" ; use defaults for parameters, icon, etc.

SectionEnd


;--------------------------------
;Uninstaller Section

Section "Uninstall"

Delete "$INSTDIR\Uninstall.exe"
RMDir /r "$INSTDIR"

DeleteRegKey /ifempty HKCU "Software\Marave"

SectionEnd

Es comparable al esfuerzo de hacer un arhivo de empaquetado, excepto que cada vez que lo querés probar... lo instalás. No hay manera (que yo vea) de saber qué hay adentro del instalador excepto correrlo.

Cuando las cosas fallan, no hay mensajes de error, por lo menos no del tipo que es útil para un desarrollador, el que necesita saber que salió mal.

Después de que termina, tal vez no funcione porque...

Problema 2: bibliotecas de sistema. Ja!

Los binarios de Python 2.6 están compilados con Visual Studio. Eso quiere decir que necesitan el Visual Studio Runtime, específicamente MSVCR90.DLL. Ésta contiene cosas que en Linux serían considerado parte de la libc (linuxero: imaginate aplicaciones que dependen de una libc específica... ¡no es fácil!)

En Linux eso es parte del sistema. Más aún, si lo necesitas, lo redistribuís. En Windows... es diferente.

Es parte del "Visual C++ redistributables"
Instalarlo no es garantía de que ande (sí, lo probé)
La licencia de esos 'redistributables' dice que no lo podés hacer disponible para descarga.

Me han dicho que incluírlo en tu instalador es legal, pero a mí me parece que eso es hacerlo disponible para descarga!

¿Qué se hace cuando necesitás una biblioteca, no la podés distribuir y el usuario no la va a instalar?

Bueno, por algo no hay binarios de Marave para Windows todavía ;-) Por supuesto si alguien lo puede resolver, me encantaría!

Trucos de KDE #2: usando escritorios remotos con avahi, krfb y krdc

2009-10-20 21:31

Utilizaremos lo siguiente:

Avahi, una implementación de zeroconf que nos ayuda a encontrar las computadoras sin pensar en números IP, archivos host, DNS, etc.
krfb, el KDE Remote Frame Buffer. Es un programa para compartir tu escritorio por red.
krdc, el KDE Remote Desktop Client, un cliente de VNC y RDP que es lo que uno usa para ver un escritorio compartido via krfb.

Seguramente los usuarios de otros sistemas operativos o entornos de escritorio van a decir que lo pueden hacer igual de fácil. En ese caso, son libres de hacer sus propios videos ;-)

Hay que recordar que acceder a escritorios remotos por internet es un problema completamente distinto, y esta solución no está pensada para ese caso.

Como siempre, el video se grabó usando qt-recordmydesktop. Hay una edición menor usando mencoder.

La computadora usada es la vieja Asus eee PC 701 4G, así que pueden ver que no es exactamente que esto requiere mucho hardware. He encontrado que la pantalla pequeña de la eee es muy buena para esta clase de demo a pantalla completa porque no es tan grande que se pierdan las partes importantes.

Más o menos el 80% de todo lo malo de los usuarios Linux en un comentario

2009-06-21 05:35

No puedo responder ahí porque:

Hay que loguearse.
No encuentro adonde pedir una cuenta.
Tiene freaking google ads popups

Entonces respondo acá porque:

Es mi blog y hago lo que se me canta.

Acá está el comentario de hussam con mi respuesta (que lo admito, es un rant) en inglés porque no pienso traducir a otro, a ver si no le hago justicia a su pavada:

I've been using ArchLinux as my only distribution/operating system since early 2006. It is really a good distribution but lately there have been a lot of really bad choices which I call bad compromises:

1. Too many ArchLinux users think gnome/kde are bloat and instead install some half developed window manager and some terminal emulator and call it a "minimalist" desktop.

Why is that any of your business? And what "compromise" is there?

2. Optional dependencies are the worst idea ever. If a package is linked against libsomething.so then libsomething should be a dependency not an optional dependency. Making libsomething an optional dependency just because "minimalist" users don't want to install dependencies is plain stupid.

That's not what optional dependencies are for. For example, consider the example I mentioned, rst2pdf. It can use pythonmagick. It can also not use it. You will lose one small feature that AFAIK only one person ever used. If you need that feature, the manual tells you what to do: install pythonmagick.

Maybe there should be a pacman option "install optdepends" which turns optional dependencies into regular ones. That would make you happy and keep others happy too.

3. Bad leadership. Aaron is fantastic guy but I know at least two ArchLinux developers who can do a much better job.

That's just stupid and mean.

4. Too many ArchLinux users now like badly automation scripts like yaourt or whatever it is called.

Parse error. And then again: yaourt is great. You don't like it? Act as if it doesn't exist and be happy. You seem to have a big problem ignoring people who disagree with you. That's a really, really serious personal flaw. I suggest you grow up.

5. Too many noobs who do dumb things like people adding their users to hal, disk and dbus groups.

Sure, they should add themselves to optical and storage. So what? It's a simple problem and it has a simple solution.

Then again, the adduser scripts probably should do that for regular user accounts. After all, who wants to create a regular user that can't use removable storage? And if said use case exists, that should be doable by removing the user, and not viceversa!

On the other hand, I don't give a damn, because I can fix it trivially.

The main reason why I don't think I will switch to another distribution soon is that creating Archlinux packages from scratch is very easy and the initscript system is really fantastic.

All in all, ArchLinux is a really strong distribution now and it's constantly growing.

I expect you, like most elitist poseurs, will run away when you feel Arch is too popular and accessible to "too many noobs" or some similar nonsense.

Which, like the title says, is why you are a big part of what's wrong with Linux users.

Por qué sigo usando Arch Linux

2009-06-20 13:06

Quería probar rst2pdf contra reportlab de SVN, wordaxe de SVN y docutils de SVN, y quería que fuera fácil.

Solución: Los empaqueté en AUR!

Ahora, cada vez que quiero probar rst2pdf contra wordaxe de trunk SVN, hago un yaourt -S python-wordaxe-svn y para volver a wordaxe estable hago yaourt -S python-wordaxe.

El paquete SVN siempre es trunk actualizado sin modificaciones, y puedo ir y volver en unos 45 segundos, sin romper paquetes del sistema.

También puedo mantener mis paquetes SVN instalados al día con un yaourt -Su --devel cada tanto.

Como lo hubiera hecho usando Debian o algo basado en RPM? Supongo que por atrás del sistema de paquetes (que odio hacerlo) o haciendo un repo privado (que es triste) o con un repo público (que es trabajo!).

La verdad si uno programa, no se me ocurre una distro que te haga la vida más fácil que Arch. Casi todo está ahí (12K paquetes en unsupported!) y si no está son 5 minutos para meterlo en AUR y ayudar a la comunidad.

Suponé que estás haciendo una aplicación KDE. En la mayoría de las distros tenés que instalarte tu propia copia de kdelibs de los fuentes para tener la última versión y asegurarte que no está arruinada por parches específicos de la distro.

En arch? Emparchar está mal visto. No tener la última versión está mal visto. Así que es más o menos el ambiente ideal para desarrollar con KDE, GNOME, PyQt o lo que sea.

Si mi tiempo no estuviera ocupao un 150% intentaría ser desarrollador Arch, o por lo menos un TU (Trusted User).

Capaz la próxima reencarnación :-)

Ralsina.Me — El sitio web de Roberto Alsina

Publicaciones sobre arch linux