El Blog de Marcelo!

Por fin algo muy novedoso bajo el sol!

Estuve leyendo sobre una nueva distro, GoboLinux, que innova en el campo de las distros linux, no implementando ‘un nuevo sistema de paquetes’. Simplemente se replantearon la vieja estructura de directorios Unix que existe en Linux y se propusieron cambiarlo, para que cualquiera («hasta mi vieja») lo entendiera, «a la Mac OSX».

Básicamente tienen un esquema de directorios:

>~]cd /
ls
Programs
Users
System
Files
Mount
Depot

y es compatible hacia atrás con todos los programas, ya que la «vieja» estructura de directorios (/bin, /usr, /var, etc.) están ocultas con un módulo del kernel que ellos mismos desarrollaron, llamado gobohide. Sin embargo, siguen existiendo, y el resto del cuento lo manejan con enlaces simbólicos.

Trabaja con casi todos los sistemas de archivos conocidos, y dispone de un comando para mostrar y ocultar directorios.

Qué lindo sería levantar un Linux y hacer esto:

/] cd /Programs
/Programs] ls
 
AfterStep     E2FSProgs    Htop        NTP          Subversion
ALSA-Driver   Ed           HTTPD       OpenOffice   Sudo
ALSA-Lib      Eject        Hydrogen    OpenSSH      Swfdec
ALSA-OSS      Elinks       IBM-Java2   OpenSSL      Synaptics
ALSA-Utils    Ethereal     ID3Lib      Pango        SysFSUtils
Ardour        Expat        IEEE80211   Patch        Sysklogd
Audacity      File         IMLib2      Perl         TCL
Aumix         Firefox      InetUtils   Pkgconfig    TeTeX
Autoconf      Flac         Intltool    PodXTPro     Texinfo
Automake      Flex         IpodSlave   Popt         TIFF
Bash          Fontconfig   Iptables    PPP          TiMidity++

Me encantaría traducir este artículo y postearlo acá, pero lamentablemente no tengo tiempo.

Qué bueno sería que Ubuntu lo incluyera!!!!

Soñar no cuesta nada. Abrí una nueva feature en el launchpad de ubuntu, acá:

https://blueprints.launchpad.net/distros/ubuntu/+spec/system-directory-approach

Opinen!

Salutes
Marcelo

Parece que un desarrollador de Gnome se puso las pilas y está agregando más «control» y configuración a los benditos themes:

Esperemos que llegue a integrarse a Gnome 2.18 (asumiendo que se va a integrar, 😀 ).

Links:
http://blogs.gnome.org/view/thos/2006/11/20/0
http://blogs.gnome.org/view/thos/2006/10/28/0

Marcelo
PD: Y para mi vieja, que no me está leyendo pero está siempre en mi cuore, FELIZ CUMPLE, MA!

Holas. Ultimamente estuve metiendo mano en un Applet de Java embebido en un Sistema Web, que entre otras cosas, lo que hacía era ejecutar lo siguiente:

import java.applet.Applet;
import netscape.javascript.JSException;
import netscape.javascript.JSObject;
 
public class imprimesecescape01 extends Applet {
  public void paint(Graphics g) {
      // .... código Java haciendo lo que hace el Applet ...
      // Al finalizar:
      try {
          JSObject jsobject = JSObject.getWindow(this);
 
          // windowClose es una función Javascript que
          // está en el HTML que sólo llama a window.close();
          jsobject.call("windowClose", null);
 
      } catch(JSException jsexception) {
          g.drawString("caught JS: " + jsexception, 20, 20);
      }
  }
}

Es decir, este Applet utiliza las clases de LiveConnect del navegador para llamar a la función JavaScript windowClose() residente en el HTML, que a su vez llama a window.close(). Todo para que, una vez que se ejecutó el código del applet, se cierre la ventana.

Esto en IE (previamente el único navegador soportado por el sistema) funciona. Pero en Firefox no. Después de investigar, tenía un problema y un bug en mi applet:

1- Un bug en el applet: El applet no se ejecutaba a menos que el tag APPLET especificara algo mayor a 0 en el width y el height. Encontré este bug, pero aparece como RESOLVED. Al principio, pensé que había una regresión del bug. Revisando y pensando un poquito, el comportamiento que mostraba Firefox estaba bien, mientras que el de IE estaba mal.

Por qué? Simple:
Pregunta: cuándo se ejecuta el método paint()?
Respuesta: cuando hay que dibujar el applet en su área asignada en la página.

Entonces, si el área a dibujar es de 0 pixeles de ancho y 0 de alto, para qué ejecutar el método paint? Justamente, Firefox no debía dibujar nada, entonces no llamaba a paint()… mientras que IE lo ejecutaba igual… grrr..

Al final, fue tanto como mudar el ćodigo de paint() a start() (que se ejecuta únicamente cuando el navegador arranca el applet), y listo el pollo. 😀

2- Un problema: El código que está arriba (el del applet), que llama a windowClose(), colgaba el firefox! Encontré este otro bug (del 2001!), que tiene un workaround:

try {
  JSObject jsobject = JSObject.getWindow(this);
  jsobject.eval("setTimeout(\"windowClose()\",100)");
} catch(JSException jsexception) {
  g.drawString("caught JS: " + jsexception, 20, 20);
}

Si claro, es un hack, pero funciona tanto en Firefox como en Explorer, así que ahora mi applet funciona y el sistema ahora está «portado» a Firefox/Linux también! 😀

«Todo sea por un cacho más de libertad» 😛

Marcelo

Hace unos días me topé con estas capturas de KDE y quiero reproducirlas acá… y sí, estoy ansioso por probarlo… no porque use Windows (hace muuuuucho que no lo uso), sino porque soy de los que creen que para migrar a Linux hay que convencer primero con instalar aplicaciones disponibles en Linux en Windows. Después, cambiar el SO entero que hay «por debajo» es muchísimo menos traumático para el usuario.

Disfruten!

Una huevada que hace tiempo que no sabía qué lo estaba causando (sólo en los Ubuntu), era que el glxgears no me escupía por consola los Frames por Segundo (FPS) que lograba renderizar en 3D. Antes yo podía ver que si tiraba unos 40 o 50 FPS, algo con mi 3D andaba mal… cuando cambiaba de placa de video, veía cúantos FPS tiraba el glxgears y comparaba la diferencia relativa de placas… etc.

Hasta que migré a Ubuntu, donde los FPS nunca aparecen en la consola!!
Siendo hasta una cuestión existencial, busqué y encontré la solución: como parece que a alguien le molestó que el glxgears se utilizara como «benchmark», por defecto se deshabilitó la salida de los benditos FPS (mal hecho en mi opinión).

Por suerte, dejaron una «puerta trasera», una opción de consola. Tipee esto en su consola:

marcelo@marcelo-desktop:~$ glxgears -iacknowledgethatthistoolisnotabenchmark

Y obtenemos esto!

Conclusiones:
1- Lo bueno es que ahora sé a cuánto anda más o menos mi placa con X.org 7.1 + Drivers Nvidia 9xxx sobre Beryl.
2- A QUIEN SE LE PUEDE HABER OCURRIDO SEMEJANTE OPCION???? («yo reconozco que esta herramienta no es un bechmark»??????????)

Y bueh, es lo que hay.
Salutes
Marcelo

Actualización: Mauro me comenta de que el flag ‘-printfps’ debería funcionar y así es, funciona. Así que hay 2 flags para hacer lo mismo, el ‘fácil’ y el ‘geek’. 😛