Ajaxman

Cuando estaba checando ajax por primera vez haa aquellos tiempos, vi que para checar que la pagina se había recibido con éxito, se esperaba un código 200, me imagine que había mas entonces decidí buscar todos los códigos posibles. Al mismo tiempo supe que estos son códigos que nos devuelven los servidores, lo tome de la wikipedia, espero que les sirvan, Ojo, pueden usarlas con ajax, para hacer funciones mas vistosas.

• 1xx Mensajes

N°

-

100

111

Conexión rechazada

• 2xx Operación exitosa

N°	Descripción
200	OK
201-203	Información no oficial
204	Sin Contenido
205	Contenido para recargar
206	Contenido parcial

• 3xx Redirección hacia otro URL

N°	Descripción
300	Múltiples posibilidades
301	Mudado permanentemente
303	Vea otros
304	No modificado
305	Utilice un proxy
307	Redirección temporal

• 4xx Error por parte del cliente

Seguir leyendo

El Archivo /etc/apt/sources.list
Como parte de su funcionamiento, APT utiliza un archivo que enlista las “fuentes” en donde se encuentran los paquetes. Este archivo es: /etc/apt/sources.list.

El contenido de este archivo, normalmente sigue este formato:
[source:java]
deb http://host/debian distribución sección1 sección2 sección3
deb-src http://host/debian distribución sección1 sección2 sección3
[/source]

Por supuesto que los renglones arriba mencionados son ficticios y no deberán ser usados. La primera palabra en cada línea, deb o deb-src, indican el tipo del archivo: ya sea que contenga paquetes binarios (deb), esto es, los paquetes pre-compilados que normalmente se usan, o los paquetes fuente (deb-src), que son los códigos originales, más el archivo de control de Debian (.dsc) y el diff.gz que contienen los cambios necesarios para “debianizar” el programa.

Generalmente se encuentra lo siguiente por defecto en el archivo sources.list asi es como esta le mio:
[source:java]
# See sources.list(5) for more information, especialy
# Remember that you can only use http, ftp or file URIs
# CDROMs are managed through the apt-cdrom tool.

deb ftp://ftp.es.debian.org/debian/ etch main non-free contrib
deb-src ftp://ftp.es.debian.org/debian/ etch main non-free contrib
deb http://security.debian.org/ etch/updates main non-free contrib

# Uncomment if you want the apt-get source function to work
#deb-src http://http.us.debian.org/debian stable main contrib non-free
#deb-src http://non-us.debian.org/debian-non-US stable/non-US main contrib non-free

[/source]
Éstas son las líneas necesarias para una instalación básica de Debian. La primer línea deb apunta al archivo en el servidor oficial, la segunda línea apunta hacia el archivo del servidor non-US y la tercera línea apunta hacia el archivo del servidor de actualizaciones de seguridad.

Las dos últimas líneas están deshabilitadas (con un “#” al inicio), así que apt-get las ignora. Éstas son las líneas de deb-src, esto es, apuntan hacia los paquetes fuente de Debian. Si frecuentemente descarga paquetes fuente para probar o recompilar, habilítelas (borrando el “#” al inicio de la línea).

El archivo /etc/apt/sources.list puede contener varios tipos de líneas. APT sabe como interpretar líneas del tipo http, ftp, file (archivos locales, p.e., un directorio que contiene un CD-ROM) y ssh, según mis conocimientos.

No olvide ejecutar el comando apt-get update después de modificar el archivo /etc/apt/sources.list. Debe hacer esto para permitir a APT obtener la lista de paquetes de las fuentes que especificó.

Cómo utilizar APT localmente
Algunas veces se pueden llegar a tener muchos paquetes .deb, los cuales le gustaría instalar utilizando APT para que las dependencias fueran resueltas automáticamente.

Para hacer esto, cree un directorio y coloque los .debs que quiera señalar en el. Por ejemplo:

# mkdir /root/debs
Seguir leyendo

Hay mucha informacion en internet pero no siempre esta a la mano, como uno quisiera por ello, tratare de ir recopilando (ademas de lo que voy haciendo) algunos temas interesantes en la web, para postearlos en el blog, bueno empecemos con la herramienta APT.

Introduccion

En el principio existían los .tar.gz. Los usuarios tenían que compilar cada programa que quisieran usar en su sistema GNU/Linux. Cuando Debian fue creado, fue imperante que el sistema incluyera un programa que se encargara de manejar la paquetería instalada en la computadora. Este programa se llamó dpkg. Así fue como nació el primer “paquete” en el mundo GNU/Linux, aún antes de que Red Hat decidiera crear su propio programa “rpm”.

Rápidamente llegó un nuevo dilema a las mentes de los creadores de GNU/Linux. Ellos necesitaban un modo fácil, rápido y eficiente de instalar programas, que manejara automáticamente las dependencias y se hiciera cargo de la configuración mientras se actualizan. Nuevamente Debian fue pionero y creó el APT, Herramienta Avanzada de Empaquetamiento (Advanced Packaging Tool), este programa ha sido adaptado por Conectiva para usarse con rpm y ha sido adoptado por otras distribuciones.

Este manual no cubre el apt-rpm, tal como se denomina a la adaptación de Conectiva del APT, y tal vez algunos “parches” para este documento aparecerán en algún tiempo.

Este capítulo está basado en la siguiente distribución de Debian Sarge y Etch.
Nota: Todo sera probado en Debian Etch
Nota 2:si hay alguna diferencia con Debian Etch, se las comentare a su debido tiempo
Fuente | http://www.debian.org/doc/manuals/apt-howto/ch1.es.html

Despues de haber actualizado el blog, ahora les tengo un muy buen video que me encotre en ajaxian.

Se trata de una platica de Douglas Crockford, con GooglersLos que trabajan en Google, esto fue en la reciente The ajax Experience el 20 de septiembre del 2007, en donde Douglas Crockford expone uno problemas de seguridad con los Mashpus, especialmente con Google Gears.

El video esta en inlges sin embargo no creo que cueste mucho entenderlo, ademas esta en Google Video, digamos que se ve bastante claro.

Bueno aqui esta le video.

Como nota curiosa noten que Douglas tiene la playera de Google, y si no me equivoco Douglas trabaja en Yahoo, como dicen por ahi ¿Que cosas no?..

Visto en | Gears and the Mashup Problem

Si no pudieron ver el blog por un rato fue porque porfin lo actualice a wordpress 2.3, subi los plugins y cheque que funcionara correctamente el tema.

Todo hubiera sido muy facil, de no ser porque wordpress no me dejo exportar los post, en pocas palabras no pude exportar nada.

Asi que tuve que eliminar el blog por completo y hacerlo de nuevo, estuvo pesado pero ya casi termino, por eso si en el listado de categorias no ven muchos post, es porque estoy …mmm digamos categorizandolo organizando en categorias.

Les invito a se suscriban por feeds al blog o via E-mail, para saber todo lo referente a este blog.

Saludos del Ajaxman……….

nota: Ya me voy a dormir ya son como las 2 am hora de mexico y tengo sueño…..mañana termino de actualizar

Via Eliax, veo esta imagen que esta excelente, se trata de un diagrama donde se lista la estructura de los directorios y archivos principales en linux.

Una muy buena opcion para los que apenas estan iniciando en linux, y recuerden usen Debian.

Visto en | La estructura de fichero de Linux en un vistazo

Ahora veremos como se procesara xul por parte de Mozilla ….

Cómo se procesa XUL

En Mozilla, XUL se procesa en forma similar al procesamiento de HTML y otros tipos de contenido. Cuando el usuario escribe la URL de una página HTML en el campo de dirección del navegador, éste busca el sitio web y descarga su contenido. El motor de presentación de Mozilla toma el contenido en el formato HTML y lo transforma en un árbol de documento. Este árbol se convierte en un conjunto de objetos que pueden mostrarse en la pantalla. Los estilos CSS, imágenes y otras tecnologías son usados para controlar la presentación. El procesamiento de XUL es muy similar.

De hecho, en Mozilla, todos los tipos de documento, sin importar si son HTML, XUL o aún SVG son procesados por el mismo código. Esto significa que las mismas propiedades CSS pueden usarse para definir el estilo tanto del HTML como de XUL, y muchas de las características pueden compartirse entre ambos. Sin embargo, hay características que son específicas del HTML como son los formularios, y otras que son específicas de XUL como son los overlays (revestimientos). Ya que XUL y HTML se procesan de la misma forma, se pueden cargar desde el sistema de archivos local del usuario, desde una página web, desde una extensión del navegador o desde una aplicación XULRunner.

El contenido de fuentes remotas, como por ejemplo: http://localhost/~username/, sin importar si es HTML, XUL o cualquier otro tipo de documento, está limitado en la clase de operaciones que pueden realizar, por razones de seguridad. Por este motivo, Mozilla proporciona un método para instalar contenido en forma local y registrar los archivos instalados para que formen parte del sistema chrome. Esto permite usar una URL especial llamada la URL chrome://. Al acceder a un archivo usando la URL chrome, éstos reciben privilegios para acceder a archivos locales, preferencias, marcadores de página y ejecutar otras operaciones privilegiadas. Obviamente, las páginas web no obtienen estos privilegios, a menos que estén firmadas con un certificado digital y el usuario dé el permiso para ejecutar estas operaciones.

Este registro en el paquete chrome es la forma en la que las extensiones de Firefox pueden añadir características al navegador. Las extensiones son pequeños paquetes con archivos XUL, Javascript, hojas de estilo e imágenes empaquetados en un sólo archivo. Este archivo puede crearse usando una utilidad ZIP. Cuando el usuario descarga la extensión, ésta es instalada en su máquina. La extensión se ensambla en el navegador usando una característica especial de XUL llamada overlay (revestimiento), la cual permite que se combinen el XUL de la extensión y el XUL del navegador. Para el usuario, puede parecer que la extensión ha modificado al navegador, pero en realidad el código está separado y la extensión se puede desinstalar fácilmente.
Seguir leyendo