El día Debian,
Se realizará el día '''Domingo 16 de Agosto''' de 2015 en el r00thouse.

== Actividades ==
=== Charlas ===
Las charlas serán en la "Sala Audiovisual" de la Carrera de Informática de la UMSA, de 9:00 AM a 14:00 PM.
La Carrera de Informática de la UMSA se encuentra en el Monoblock de la UMSA, Av. Villazón N° 1995, Plaza del Bicentenario - Zona Central.
Y la "Sala Audiovisual" está en el segundo piso del edificio de la Carrera de Informática, dentro del Monoblock de la UMSA.

Las charlas que se darán son:

* 09:30 - Por qué el Debian Day? Presentación (Gino)
* 10:00 - Debian (Esteban Lima)
* 10:30 - GPG (Armin Mesa)
* 11:00 - r00tHouse-mesh (Sergio Guillen)
* 11:30 - Embebidos Linux (Javier Zelada)
* 12:00 - La mentira de internet.org (Rodrigo García)

=== Install fest de Debian ===
Se invitará a los que desean instalarse al r00tHouse durante la tarde.

=== GPG Key party ===
Armin lo hará durante su charla.

=== Torta Debian ===
Se comprara en la una pasteleria cercana con fondos del Hacklab y llevara el logo Debian.

=== Copiation previa al evento ===
Se pondrá en el FTP de la MESH y en el PirateBox todos los libros libres que tenemos.

=== Venta de Souvenirs ===
Existirán botones, libritos, stickers y DVD's de Debian.

=== Afiches ===

== Por Hacer ==
* Quemar DVD's
** 5 DVD's quemará cada uno.
** Rodry y jhtan en el CEI el viernes.
** Ale en el CEI el jueves en la mañana.
* Imprimir los DVD's
** Armin imprimirá todo viernes en la noche.
** Debemos pasarle los DVD's hasta antes del viernes en la tarde!.. :|
* Hacer los libritos
** Rodri intentará (posiblemente).
* Hacer stickers
** Don Sergey comprará el papel.
** Buscará a jhtan el viernes para imprimir en el CEFAC.
* Coordinar la venta el sábado
** Todos.
* Colgar el banner de Debian
** Ale y jhtan el jueves.
* Llevar el PirateBox
** Dx lo traerá el sábado

2015-01-14T06:41:38Z

Jhtan:

Git (escencial)

2015-01-14T06:39:25Z

Jhtan:

En este artículo se muestra el manejo básico del sistema de versionamiento de código git, también algunos tips para aprovechar sus funcionalidades.

== Sistema de versionamiento ==

Un sistema de control de versionamiento de código (VCS en inglés) es un sistema que permite mantener versiones de un trabajo que se desarrolla, por ejemplo al escribir código a medida que se avanza en un programa puede darse el caso de necesitar que los archivos vuelvan a un estado anterior al actual. Los sitemas de versionamiento de código son las herramientas indicadas para ello, así si hemos hecho cambios problemáticos en nuestro código podemos cambiar el código a una versión anterior que no tenía problemas (o al menos no tantos ;) ).

Los sistemas de versionamiento no se limitan a código, sirven también para cualquier archivo.

Existen los CVCS (sistemas de versionamiento centralizado tales como '''svn''') y los DVCS (sistemas de control de versionamiento distribuido como git y bazaar), sólo veremos git por lo que los CVCS no se abarcarán en este artículo.

= Empezar a usar git =

== Requerimientos ==

Una pc con git instalado y una shell para introducir comandos, si no se tiene instalado git hay que instalarlo en un sistema basado en Debian bastaría con

<source lang="bash">apt-get install git</source>

== Como trabaja git ==

Lo primero es entender como git considera los cambios en los archivos.

=== Snapshots y no cambios en los archivos ===

Git hace "snapshots" en los archivos (es como tomar imágenes de un archivo para ver como luce), a medida que se va haciendo commits git hace snapshots de los archivos considerados y almacena una referencia a ese snapshot. Pero al hacer un nuevo commit git sólo almacena los snapshots que han cambiado.

Un ejemplo claro de esto es cuando uno inicia git, se hará un snapshot incial de por ejemplo un arhcivo. Luego se modifica ese archivo por ejemplo borrando una letra y luego volverla a escribir en el mismo lugar y luego guardar el archivo, para el sistema operativo u otros sistemas de versionamiento el archivo cambió pero en realidad el archivo luce exactamente igual.

Para git este archivo no cambió en lo absoluto y por eso al hacer de nuevo un snapshot git no registrará ningún cambió en el archivo por que los snapshots de ambos lucen iguales.

En cambio si el archivo cambió en al menos una letra los snapshots lucirán distintos y para git este cambio debe ser tomado en cuenta.

'''Es virtualmente imposible que git no note un cambio en los archivos''' bajo el principio mencionado arriba. Esto por que git usa algoritmos de checksum en este caso ''sha-1 hash''

=== Tres estados ===

Git hace que los archivos estén en uno de tres estados y estos son:

==== Modificado ====

El archivo has sido modificado ero no ha sido marcado para el siguiente commit.

==== Marcado para commit (staged) ====

Es cuando un archivo modificado ha sido marcado para que en el siguiente commit se tome un snapshot de este y se almacene en la base de datos del commit hecho. Cuando un archivo modificado ha sido marcado para ir en el siguiente commit se dice que ese archivo esta en el archivo conocido como '''índice'''o'''''staging area.

==== Comiteado (commited) ====

Significa que el archivo esta apropiadamente almacenado en la base de datos correspondiente al commit hecho. Esto sucede sólo con los archivos tomados en cuenta y luego se hace el uso de <code>git commit</code>

=== trabajo local ===

La gran ventaja de git es que no necesita conexion a internet para trabajar con el, por lo que la mayoría de los trabajaos lo hacemos en nuestra pc y en privado. Eso no significa que no se pueda trabajar colaborativamente mediante git, ya está diseñado para eso. Entonces git es una buena opción para trabajar proyectos en conjunto con otras personas a través de internet pero se puede usar git para trabajar individualmente y es una gran herramienta de versionamiento.

== Setup ==

Necesitamos hacer algunos ajustes si es la primera vez que usamos git en nuestra pc. Git guarda las '''configuraciones globales''' en la carpeta personal de cada usuario en; <code>~/.gitconfig </code>. Git también permite tener '''configuraciones locales''' es decir configuraciones distintas a las globales por repositorio donde el archivo se encuentra en el directorio principal del repositorio y dentro la carpeta .git entonces; <code>.git/config</code>

=== Indentificarse ===

Para identificar al autor de cada commit git necesita que se coloque una dirección de correo electrónico y el nombre, a continuación haremos una configuración global para el usuario acutal:

<source lang="bash">
git config --global user.name "Nombre del usuario"
git config --global user.email "correo@algo.com"
</source>

Este nombre de usuario correo electrónico aparecerán en cada commit que se haga y sirven para contactar al autor del commit.

Para hacer las configuraciones locales basta <code>git config --local</code> usando las mismas opciones que en global. Para esto la shell debe estar en el directorio del repositorio git en el que se quiere hacer los cambios y estas configuraciones locales se superpondrán a las configuraciones globales.

=== Editor por defecto ===

Adicionalmente se puede configurar el editor usado por defecto para escribir los mensajes al hacer los commits, por ejemplo para que el editor sea 'gedit'.

<source lang="bash">git config --global core.editor gedit</source>

== Crear repositorio git ==

Si queremos hacer que git colabore con el versionamiento de cualquier trabajo aquí simples pasos:

#Abrir una shell (terminal o consola)
#Dirigir la shell al direcotrio principal donde se encuentra el trabajo (cd hasta estar en el directorio donde esta nuestro trabajo)
#Una vez en el direcotorio principal escribir en la shell:

<source lang="bash">
git init
</source>

Se creará un repostorio git inicial, luego se puede ver que se ha creado una carpeta con el nombre <code>.git</code> que es donde se guarda el repositorio git.

== Añadir archivos al seguimiento ==

Una vez se ha creado el repositorio git ya se pueden marcar archivos para se comiteados el comando para esto es <code>git add</code>. Por ejemplo para agregar al índice un archivo llamado <code>README</code> se hace con:

<source lang="bash">git add README</source>

Ahora para agregar al índice todos los archivos que terminen en .c

<source lang="bash">git add *.c</source>

git soporta expresiones regulares por lo que se pueden usar los identificadores *, [], (), ? y otros.

== Ver seguimiento ==

El comando <code>git status</code> es el indicado

Hay que notar que los archivos añadidos con git add ahora están marcados para ser parte del siguiente commit y si su contenido cambia git lo notará y podremos visualizarlo con:

<source lang="bash">git status</source>

Ahora veamos un ejemplo donde se tiene un proyecto con tres archivos <code>main.c README libs.h</code>, supongamos que hemos ejecutado: <source lang="bash">git add *</source> Por lo que se han marcado todos los archivos y subcarpetas dentro de este directorio. Ahora al hacer <code>git status</code> aparece:

<source lang="bash">
Cambios para hacer commit:
(use «git rm --cached <archivo>...« para eliminar stage)

new file: README
new file: libs.h
new file: main.c
</source>

Esto nos muestra que se han agregado ciertos archivos para el siguiente commit. Ahora supongamos que hemos modificado el archivo <code>main.c</code> y hemos creado otro llamado <code>func1.c</code>, al hacer <code>git status</code> aparece:

<source lang="bash">
En la rama master

Commit inicial

Cambios para hacer commit:
(use «git rm --cached <archivo>...« para eliminar stage)

new file: README
new file: libs.h
new file: main.c

Cambios no preparados para el commit:
(use «git add <archivo>...» para actualizar lo que se ejecutará)
(use «git checkout -- <archivo>...« para descartar cambios en le directorio de trabajo)

modificado: main.c

Archivos sin seguimiento:
(use «git add <archivo>...» para incluir lo que se ha de ejecutar)

func1.c
</source>

El archivo <code>main.c</code> aparece como modificado y git nos sugiere que agreguemos <code>func1.c</code> usando <code>git add</code>.

Si ejecutamos nuevamente <code>git add * </code> todos los arhcivos serán marcados para ser parte del siguiente commit pero podemos marcar los archivos que necesitemos y usar <code>git status</code> para ver la lista de los archivos con seguimiento.

== Quitar archivos del seguimiento ==

Es natural cometer errores al agregar archivos al índice, por ejemplo siguiendo el ejemplo anterior se desea quitar el archivo <code>README</code> así no se tomará en cuenta al hacer el siguiente commit. Afortunadamente podemos hacerlo con: <source lang="bash">
git rm --cached README
</source> Que quitará del seguimiento al archivo README, noten que la opción --cached se usa y es para indicar que '''se quite del seguimiento solamente'', con el siguiente ejemplo se puede apreciar esto.

----

Veamos un caso particular con el ejemplo anterior, se ha añadido por error un archivo <code>img.png</code> y al hacer git status aparece:

<source lang="bash">
Cambios para hacer commit:
(use «git rm --cached <archivo>...« para eliminar stage)

new file: func1.c
new file: img.png
new file: libs.h
new file: main.c

Archivos sin seguimiento:
(use «git add <archivo>...» para incluir lo que se ha de ejecutar)

README

</source>

Si hacemos <source lang="bash">
git rm *.png
</source>

Se desmarcarán los .png que estén actualmente en el seguimiento pero esto nos devolverá un error con: <source lang="bash">
error: the following file has changes staged in the index:
img.png
(use --cached to keep the file, or -f to force removal)
</source> Que nos dice que <code>img.png</code> se encuentra marcado y que usemos la opción <code>--cached</code> para quitarlo del índice de seguimiento o la opción <code>-f</code>. '''Si se usa <code>-f</code> git forzará la eliminación del índice y del disco duro.''' Por lo que realmente eliminaremos el archivo. Por eso la opción <code>--cached</code> elimina solamente del índice de seguimiento y protege el archivo original.

Ahora supongamos que hemos eliminado el archivo <code>func1.c</code> nosotros mismos al hacer git status aparecerá:
<pre>deleted: func1.c
</pre>
Que dice que se ha eliminado del disco ese archivo, para quitarlo del seguimiento podemos usar <source lang="bash">
git rm func1.c
</source> Que desmarcará el archivo eliminado y no entrará en el siguiente commit. Ahora al hacer <code>git status</code> ese archivo no aparecerá más por que ha sido eliminado del disco y también del seguimiento.

=== El archivo .gitignore ===

== Hacer un commit ==

Una vez tenemos marcados todos los archivos que se necesiten se puede hacer un commit que es tomar snapshots de todos los archivos marcados y guardarlos en la base de datos del repositorio git, entonces basta con:

<source lang="bash">
git commit
</source>

Al hacerlo se abrirá el editor especificado como por defecto para que escribamos un mensaje que describa los cambios hechos al trabajo en el commit actual. Las líneas que contengan #en el mensaje serán ignoradas. Al terminar de escribir el mensaje, guardarlo y salir del editor que se abrió el commit estará hecho. Podemos ver los distintos commits que se han hecho en el trabajo usando: <source lang="bash"> git log</source> Este un ejemplo del mensaje que muestra con <code>git log</code>.

<source lang="bash">
commit 6b3603354b48f5ef3f5b69f2140c8b66caabd8dc
Author: Juan Perez <juan@algo.com>
Date: Tue Jan 13 15:07:38 2015 -0400

Commit inicial

Este es el mensaje que aparecerá y nos muestra los cambios que se han hecho.
Es buena idea describir los cambios de manera concisa para tener una buena referncia
de los cambios realizados en este commit.
</source>

Se abre una pantalla de la que se puede salir con q y no muestra:

*<code>commit 6b3603354b48f5ef3f5b69f2140c8b66caabd8dc</code> - donde 6b3603354b48f5ef3f5b69f2140c8b66caabd8dc es la cadena que identifica al commit, esta cadena es única por commit y no hay riesgo de que se confunda con otro. A partir de ahora para referirnos a ese commit en particular se usará esa cadena.

*<code>Author: Juan Perez <juan@algo.com></code> muestra el autor y email de la persona que realizó el commit.

*<code>Date: Tue Jan 13 15:07:38 2015 -0400</code> La fecha y hora del commit.

> Luego se muestra el mensaje que se escribió indicando los cambios que representa el commit.

> Por cada commit se mostrará la misma estructura que la anterior y una vez hecho un commit los archivos incluídos en este están dentro el repositorio de versiones de git, esto quiere decir que son como puntos de retorno para deshacer cambios en los archivos. Por eso es buena idea hacer commits cada que se hagan cambios significativos o se desee hacer un respaldo de los cambios realizados desde un commit a otro.

=== Reparar commit ===

== Ver diferencias ==

== Deshacer cambios (volver a un estado anterior) ==

== Trabajando en ramas ==

Las ramas ("branches" en inglés) sirven para poder crear un repositorio paralelo al que estemos usando y poder trabajar en él sin necesidad de afectar al original.

Por ejemplo, digamos que creamos un "branch" llamado "bugFixing" (reparación de bugs) a partir de "master" (la rama principal), esto para que una parte del equipo siga creando nuevas características en el branch "master" y para que otra parte del equipo trabaje en la reparación de "bugs" en la rama "bugFixing". Al final de este proceso ambas ramas deben mezclarse ("merge") y volver a ser una sola.

[[File:GitBranches.png|center|GitBranches.png]]

=== Ver todas las ramas ===

<source lang="bash">$ git branch</source>

=== Cambiar a una rama ===

<source lang="bash">$ git checkout <nombre_de_la_rama></source>

=== Crear una rama en tu entorno local ===

<source lang="bash">$ git branch <nombre_de_la_rama></source>

=== Subir la rama al servidor ===

<source lang="bash">$ git push origin <nombre_de_la_rama></source>

=== Eliminar la rama de tu entorno local ===

<source lang="bash">$ git branch -D <nombre_de_la_rama></source>

=== Eliminar la rama en el servidor ===

<source lang="bash">$ git push origin --delete <nombre_de_la_rama></source>

== Clonar repositorio git ==

== Trabajo colaborativo ==

== Referencias ==

*[http://www.git-scm.com/book/en/v2 http://www.git-scm.com/book/en/v2]

= Tips =

Git (escencial)

2015-01-14T06:38:44Z

Jhtan:

En este artículo se muestra el manejo básico del sistema de versionamiento de código git, también algunos tips para aprovechar sus funcionalidades.

== Sistema de versionamiento ==

Un sistema de control de versionamiento de código (VCS en inglés) es un sistema que permite mantener versiones de un trabajo que se desarrolla, por ejemplo al escribir código a medida que se avanza en un programa puede darse el caso de necesitar que los archivos vuelvan a un estado anterior al actual. Los sitemas de versionamiento de código son las herramientas indicadas para ello, así si hemos hecho cambios problemáticos en nuestro código podemos cambiar el código a una versión anterior que no tenía problemas (o al menos no tantos ;) ).

Los sistemas de versionamiento no se limitan a código, sirven también para cualquier archivo.

Existen los CVCS (sistemas de versionamiento centralizado tales como '''svn''') y los DVCS (sistemas de control de versionamiento distribuido como git y bazaar), sólo veremos git por lo que los CVCS no se abarcarán en este artículo.

= Empezar a usar git =

== Requerimientos ==

Una pc con git instalado y una shell para introducir comandos, si no se tiene instalado git hay que instalarlo en un sistema basado en Debian bastaría con

<source lang="bash">apt-get install git</source>

== Como trabaja git ==

Lo primero es entender como git considera los cambios en los archivos.

=== Snapshots y no cambios en los archivos ===

Git hace "snapshots" en los archivos (es como tomar imágenes de un archivo para ver como luce), a medida que se va haciendo commits git hace snapshots de los archivos considerados y almacena una referencia a ese snapshot. Pero al hacer un nuevo commit git sólo almacena los snapshots que han cambiado.

Un ejemplo claro de esto es cuando uno inicia git, se hará un snapshot incial de por ejemplo un arhcivo. Luego se modifica ese archivo por ejemplo borrando una letra y luego volverla a escribir en el mismo lugar y luego guardar el archivo, para el sistema operativo u otros sistemas de versionamiento el archivo cambió pero en realidad el archivo luce exactamente igual.

Para git este archivo no cambió en lo absoluto y por eso al hacer de nuevo un snapshot git no registrará ningún cambió en el archivo por que los snapshots de ambos lucen iguales.

En cambio si el archivo cambió en al menos una letra los snapshots lucirán distintos y para git este cambio debe ser tomado en cuenta.

'''Es virtualmente imposible que git no note un cambio en los archivos''' bajo el principio mencionado arriba. Esto por que git usa algoritmos de checksum en este caso ''sha-1 hash''

=== Tres estados ===

Git hace que los archivos estén en uno de tres estados y estos son:

==== Modificado ====

El archivo has sido modificado ero no ha sido marcado para el siguiente commit.

==== Marcado para commit (staged) ====

Es cuando un archivo modificado ha sido marcado para que en el siguiente commit se tome un snapshot de este y se almacene en la base de datos del commit hecho. Cuando un archivo modificado ha sido marcado para ir en el siguiente commit se dice que ese archivo esta en el archivo conocido como '''índice'''o'''''staging area.

==== Comiteado (commited) ====

Significa que el archivo esta apropiadamente almacenado en la base de datos correspondiente al commit hecho. Esto sucede sólo con los archivos tomados en cuenta y luego se hace el uso de <code>git commit</code>

=== trabajo local ===

La gran ventaja de git es que no necesita conexion a internet para trabajar con el, por lo que la mayoría de los trabajaos lo hacemos en nuestra pc y en privado. Eso no significa que no se pueda trabajar colaborativamente mediante git, ya está diseñado para eso. Entonces git es una buena opción para trabajar proyectos en conjunto con otras personas a través de internet pero se puede usar git para trabajar individualmente y es una gran herramienta de versionamiento.

== Setup ==

Necesitamos hacer algunos ajustes si es la primera vez que usamos git en nuestra pc. Git guarda las '''configuraciones globales''' en la carpeta personal de cada usuario en; <code>~/.gitconfig </code>. Git también permite tener '''configuraciones locales''' es decir configuraciones distintas a las globales por repositorio donde el archivo se encuentra en el directorio principal del repositorio y dentro la carpeta .git entonces; <code>.git/config</code>

=== Indentificarse ===

Para identificar al autor de cada commit git necesita que se coloque una dirección de correo electrónico y el nombre, a continuación haremos una configuración global para el usuario acutal:

<source lang="bash">
git config --global user.name "Nombre del usuario"
git config --global user.email "correo@algo.com"
</source>

Este nombre de usuario correo electrónico aparecerán en cada commit que se haga y sirven para contactar al autor del commit.

Para hacer las configuraciones locales basta <code>git config --local</code> usando las mismas opciones que en global. Para esto la shell debe estar en el directorio del repositorio git en el que se quiere hacer los cambios y estas configuraciones locales se superpondrán a las configuraciones globales.

=== Editor por defecto ===

Adicionalmente se puede configurar el editor usado por defecto para escribir los mensajes al hacer los commits, por ejemplo para que el editor sea 'gedit'.

<source lang="bash">git config --global core.editor gedit</source>

== Crear repositorio git ==

Si queremos hacer que git colabore con el versionamiento de cualquier trabajo aquí simples pasos:

#Abrir una shell (terminal o consola)
#Dirigir la shell al direcotrio principal donde se encuentra el trabajo (cd hasta estar en el directorio donde esta nuestro trabajo)
#Una vez en el direcotorio principal escribir en la shell:

<source lang="bash">
git init
</source>

Se creará un repostorio git inicial, luego se puede ver que se ha creado una carpeta con el nombre <code>.git</code> que es donde se guarda el repositorio git.

== Añadir archivos al seguimiento ==

Una vez se ha creado el repositorio git ya se pueden marcar archivos para se comiteados el comando para esto es <code>git add</code>. Por ejemplo para agregar al índice un archivo llamado <code>README</code> se hace con:

<source lang="bash">git add README</source>

Ahora para agregar al índice todos los archivos que terminen en .c

<source lang="bash">git add *.c</source>

git soporta expresiones regulares por lo que se pueden usar los identificadores *, [], (), ? y otros.

== Ver seguimiento ==

El comando <code>git status</code> es el indicado

Hay que notar que los archivos añadidos con git add ahora están marcados para ser parte del siguiente commit y si su contenido cambia git lo notará y podremos visualizarlo con:

<source lang="bash">git status</source>

Ahora veamos un ejemplo donde se tiene un proyecto con tres archivos <code>main.c README libs.h</code>, supongamos que hemos ejecutado: <source lang="bash">git add *</source> Por lo que se han marcado todos los archivos y subcarpetas dentro de este directorio. Ahora al hacer <code>git status</code> aparece:

<source lang="bash">
Cambios para hacer commit:
(use «git rm --cached <archivo>...« para eliminar stage)

new file: README
new file: libs.h
new file: main.c
</source>

Esto nos muestra que se han agregado ciertos archivos para el siguiente commit. Ahora supongamos que hemos modificado el archivo <code>main.c</code> y hemos creado otro llamado <code>func1.c</code>, al hacer <code>git status</code> aparece:

<source lang="bash">
En la rama master

Commit inicial

Cambios para hacer commit:
(use «git rm --cached <archivo>...« para eliminar stage)

new file: README
new file: libs.h
new file: main.c

Cambios no preparados para el commit:
(use «git add <archivo>...» para actualizar lo que se ejecutará)
(use «git checkout -- <archivo>...« para descartar cambios en le directorio de trabajo)

modificado: main.c

Archivos sin seguimiento:
(use «git add <archivo>...» para incluir lo que se ha de ejecutar)

func1.c
</source>

El archivo <code>main.c</code> aparece como modificado y git nos sugiere que agreguemos <code>func1.c</code> usando <code>git add</code>.

Si ejecutamos nuevamente <code>git add * </code> todos los arhcivos serán marcados para ser parte del siguiente commit pero podemos marcar los archivos que necesitemos y usar <code>git status</code> para ver la lista de los archivos con seguimiento.

== Quitar archivos del seguimiento ==

Es natural cometer errores al agregar archivos al índice, por ejemplo siguiendo el ejemplo anterior se desea quitar el archivo <code>README</code> así no se tomará en cuenta al hacer el siguiente commit. Afortunadamente podemos hacerlo con: <source lang="bash">
git rm --cached README
</source> Que quitará del seguimiento al archivo README, noten que la opción --cached se usa y es para indicar que '''se quite del seguimiento solamente'', con el siguiente ejemplo se puede apreciar esto.

----

Veamos un caso particular con el ejemplo anterior, se ha añadido por error un archivo <code>img.png</code> y al hacer git status aparece:

<source lang="bash">
Cambios para hacer commit:
(use «git rm --cached <archivo>...« para eliminar stage)

new file: func1.c
new file: img.png
new file: libs.h
new file: main.c

Archivos sin seguimiento:
(use «git add <archivo>...» para incluir lo que se ha de ejecutar)

README

</source>

Si hacemos <source lang="bash">
git rm *.png
</source>

Se desmarcarán los .png que estén actualmente en el seguimiento pero esto nos devolverá un error con: <source lang="bash">
error: the following file has changes staged in the index:
img.png
(use --cached to keep the file, or -f to force removal)
</source> Que nos dice que <code>img.png</code> se encuentra marcado y que usemos la opción <code>--cached</code> para quitarlo del índice de seguimiento o la opción <code>-f</code>. '''Si se usa <code>-f</code> git forzará la eliminación del índice y del disco duro.''' Por lo que realmente eliminaremos el archivo. Por eso la opción <code>--cached</code> elimina solamente del índice de seguimiento y protege el archivo original.

Ahora supongamos que hemos eliminado el archivo <code>func1.c</code> nosotros mismos al hacer git status aparecerá:
<pre>deleted: func1.c
</pre>
Que dice que se ha eliminado del disco ese archivo, para quitarlo del seguimiento podemos usar <source lang="bash">
git rm func1.c
</source> Que desmarcará el archivo eliminado y no entrará en el siguiente commit. Ahora al hacer <code>git status</code> ese archivo no aparecerá más por que ha sido eliminado del disco y también del seguimiento.

=== El archivo .gitignore ===

== Hacer un commit ==

Una vez tenemos marcados todos los archivos que se necesiten se puede hacer un commit que es tomar snapshots de todos los archivos marcados y guardarlos en la base de datos del repositorio git, entonces basta con:

<source lang="bash">
git commit
</source>

Al hacerlo se abrirá el editor especificado como por defecto para que escribamos un mensaje que describa los cambios hechos al trabajo en el commit actual. Las líneas que contengan #en el mensaje serán ignoradas. Al terminar de escribir el mensaje, guardarlo y salir del editor que se abrió el commit estará hecho. Podemos ver los distintos commits que se han hecho en el trabajo usando: <source lang="bash"> git log</source> Este un ejemplo del mensaje que muestra con <code>git log</code>.

<source lang="bash">
commit 6b3603354b48f5ef3f5b69f2140c8b66caabd8dc
Author: Juan Perez <juan@algo.com>
Date: Tue Jan 13 15:07:38 2015 -0400

Commit inicial

Este es el mensaje que aparecerá y nos muestra los cambios que se han hecho.
Es buena idea describir los cambios de manera concisa para tener una buena referncia
de los cambios realizados en este commit.
</source>

Se abre una pantalla de la que se puede salir con q y no muestra:

*<code>commit 6b3603354b48f5ef3f5b69f2140c8b66caabd8dc</code> - donde 6b3603354b48f5ef3f5b69f2140c8b66caabd8dc es la cadena que identifica al commit, esta cadena es única por commit y no hay riesgo de que se confunda con otro. A partir de ahora para referirnos a ese commit en particular se usará esa cadena.

*<code>Author: Juan Perez <juan@algo.com></code> muestra el autor y email de la persona que realizó el commit.

*<code>Date: Tue Jan 13 15:07:38 2015 -0400</code> La fecha y hora del commit.

> Luego se muestra el mensaje que se escribió indicando los cambios que representa el commit.

> Por cada commit se mostrará la misma estructura que la anterior y una vez hecho un commit los archivos incluídos en este están dentro el repositorio de versiones de git, esto quiere decir que son como puntos de retorno para deshacer cambios en los archivos. Por eso es buena idea hacer commits cada que se hagan cambios significativos o se desee hacer un respaldo de los cambios realizados desde un commit a otro.

=== Reparar commit ===

== Ver diferencias ==

== Deshacer cambios (volver a un estado anterior) ==

== Trabajando en ramas ==

Las ramas ("branches" en inglés) sirven para poder crear un repositorio paralelo al que estemos usando y poder trabajar en él sin necesidad de afectar al original.

Por ejemplo, digamos que creamos un "branch" llamado "bugFixing" (reparación de bugs) a partir de "master" (la rama principal), esto para que una parte del equipo siga creando nuevas características en el branch "master" y para que otra parte del equipo trabaje en la reparación de "bugs" en la rama "bugFixing". Al final de este proceso ambas ramas deben mezclarse ("merge") y volver a ser una sola.

[[File:GitBranches.png|center|GitBranches.png]]

=== Ver todas las ramas ===

<source lang="bash">$ git branch</source>

=== Cambiar a una rama ===

<source lang="bash">$ git checkout <nombre_de_la_rama></source>

=== Crear una rama en tu entorno local ===

<source lang="bash">$ git branch <nombre_de_la_rama></source>

=== Subir la rama al servidor ===

<source lang="bash">$ git push origin <nombre_de_la_rama></source>

=== Eliminar la rama de tu entorno local ===

<source lang="bash">$ git branch -D <nombre_de_la_rama></source>

=== Eliminar la rama en el servidor ===

<source lang="bash">$ git push origin --delete <nombre_de_la_rama></source>

== Clonar repositorio git ==

== Trabajo colaborativo ==

== Referencias ==

*[http://www.git-scm.com/book/en/v2 http://www.git-scm.com/book/en/v2]

== Tips ==

Git (escencial)

2015-01-14T06:35:22Z

Jhtan:

En este artículo se muestra el manejo básico del sistema de versionamiento de código git, también algunos tips para aprovechar sus funcionalidades.

== Sistema de versionamiento ==

Un sistema de control de versionamiento de código (VCS en inglés) es un sistema que permite mantener versiones de un trabajo que se desarrolla, por ejemplo al escribir código a medida que se avanza en un programa puede darse el caso de necesitar que los archivos vuelvan a un estado anterior al actual. Los sitemas de versionamiento de código son las herramientas indicadas para ello, así si hemos hecho cambios problemáticos en nuestro código podemos cambiar el código a una versión anterior que no tenía problemas (o al menos no tantos ;) ).

Los sistemas de versionamiento no se limitan a código, sirven también para cualquier archivo.

Existen los CVCS (sistemas de versionamiento centralizado tales como '''svn''') y los DVCS (sistemas de control de versionamiento distribuido como git y bazaar), sólo veremos git por lo que los CVCS no se abarcarán en este artículo.

= Empezar a usar git =

== Requerimientos ==

Una pc con git instalado y una shell para introducir comandos, si no se tiene instalado git hay que instalarlo en un sistema basado en Debian bastaría con

<source lang="bash">apt-get install git</source>

== Como trabaja git ==

Lo primero es entender como git considera los cambios en los archivos.

=== Snapshots y no cambios en los archivos ===

Git hace "snapshots" en los archivos (es como tomar imágenes de un archivo para ver como luce), a medida que se va haciendo commits git hace snapshots de los archivos considerados y almacena una referencia a ese snapshot. Pero al hacer un nuevo commit git sólo almacena los snapshots que han cambiado.

Un ejemplo claro de esto es cuando uno inicia git, se hará un snapshot incial de por ejemplo un arhcivo. Luego se modifica ese archivo por ejemplo borrando una letra y luego volverla a escribir en el mismo lugar y luego guardar el archivo, para el sistema operativo u otros sistemas de versionamiento el archivo cambió pero en realidad el archivo luce exactamente igual.

Para git este archivo no cambió en lo absoluto y por eso al hacer de nuevo un snapshot git no registrará ningún cambió en el archivo por que los snapshots de ambos lucen iguales.

En cambio si el archivo cambió en al menos una letra los snapshots lucirán distintos y para git este cambio debe ser tomado en cuenta.

'''Es virtualmente imposible que git no note un cambio en los archivos''' bajo el principio mencionado arriba. Esto por que git usa algoritmos de checksum en este caso ''sha-1 hash''

=== Tres estados ===

Git hace que los archivos estén en uno de tres estados y estos son:

==== Modificado ====

El archivo has sido modificado ero no ha sido marcado para el siguiente commit.

==== Marcado para commit (staged) ====

Es cuando un archivo modificado ha sido marcado para que en el siguiente commit se tome un snapshot de este y se almacene en la base de datos del commit hecho. Cuando un archivo modificado ha sido marcado para ir en el siguiente commit se dice que ese archivo esta en el archivo conocido como '''índice'''o'''''staging area.

==== Comiteado (commited) ====

Significa que el archivo esta apropiadamente almacenado en la base de datos correspondiente al commit hecho. Esto sucede sólo con los archivos tomados en cuenta y luego se hace el uso de <code>git commit</code>

=== trabajo local ===

La gran ventaja de git es que no necesita conexion a internet para trabajar con el, por lo que la mayoría de los trabajaos lo hacemos en nuestra pc y en privado. Eso no significa que no se pueda trabajar colaborativamente mediante git, ya está diseñado para eso. Entonces git es una buena opción para trabajar proyectos en conjunto con otras personas a través de internet pero se puede usar git para trabajar individualmente y es una gran herramienta de versionamiento.

== Setup ==

Necesitamos hacer algunos ajustes si es la primera vez que usamos git en nuestra pc. Git guarda las '''configuraciones globales''' en la carpeta personal de cada usuario en; <code>~/.gitconfig </code>. Git también permite tener '''configuraciones locales''' es decir configuraciones distintas a las globales por repositorio donde el archivo se encuentra en el directorio principal del repositorio y dentro la carpeta .git entonces; <code>.git/config</code>

=== Indentificarse ===

Para identificar al autor de cada commit git necesita que se coloque una dirección de correo electrónico y el nombre, a continuación haremos una configuración global para el usuario acutal:

<source lang="bash">
git config --global user.name "Nombre del usuario"
git config --global user.email "correo@algo.com"
</source>

Este nombre de usuario correo electrónico aparecerán en cada commit que se haga y sirven para contactar al autor del commit.

Para hacer las configuraciones locales basta <code>git config --local</code> usando las mismas opciones que en global. Para esto la shell debe estar en el directorio del repositorio git en el que se quiere hacer los cambios y estas configuraciones locales se superpondrán a las configuraciones globales.

=== Editor por defecto ===

Adicionalmente se puede configurar el editor usado por defecto para escribir los mensajes al hacer los commits, por ejemplo para que el editor sea 'gedit'.

<source lang="bash">git config --global core.editor gedit</source>

== Crear repositorio git ==

Si queremos hacer que git colabore con el versionamiento de cualquier trabajo aquí simples pasos:

#Abrir una shell (terminal o consola)
#Dirigir la shell al direcotrio principal donde se encuentra el trabajo (cd hasta estar en el directorio donde esta nuestro trabajo)
#Una vez en el direcotorio principal escribir en la shell:

<source lang="bash">
git init
</source>

Se creará un repostorio git inicial, luego se puede ver que se ha creado una carpeta con el nombre <code>.git</code> que es donde se guarda el repositorio git.

== Añadir archivos al seguimiento ==

Una vez se ha creado el repositorio git ya se pueden marcar archivos para se comiteados el comando para esto es <code>git add</code>. Por ejemplo para agregar al índice un archivo llamado <code>README</code> se hace con:

<source lang="bash">git add README</source>

Ahora para agregar al índice todos los archivos que terminen en .c

<source lang="bash">git add *.c</source>

git soporta expresiones regulares por lo que se pueden usar los identificadores *, [], (), ? y otros.

== Ver seguimiento ==

El comando <code>git status</code> es el indicado

Hay que notar que los archivos añadidos con git add ahora están marcados para ser parte del siguiente commit y si su contenido cambia git lo notará y podremos visualizarlo con:

<source lang="bash">git status</source>

Ahora veamos un ejemplo donde se tiene un proyecto con tres archivos <code>main.c README libs.h</code>, supongamos que hemos ejecutado: <source lang="bash">git add *</source> Por lo que se han marcado todos los archivos y subcarpetas dentro de este directorio. Ahora al hacer <code>git status</code> aparece:

<source lang="bash">
Cambios para hacer commit:
(use «git rm --cached <archivo>...« para eliminar stage)

new file: README
new file: libs.h
new file: main.c
</source>

Esto nos muestra que se han agregado ciertos archivos para el siguiente commit. Ahora supongamos que hemos modificado el archivo <code>main.c</code> y hemos creado otro llamado <code>func1.c</code>, al hacer <code>git status</code> aparece:

<source lang="bash">
En la rama master

Commit inicial

Cambios para hacer commit:
(use «git rm --cached <archivo>...« para eliminar stage)

new file: README
new file: libs.h
new file: main.c

Cambios no preparados para el commit:
(use «git add <archivo>...» para actualizar lo que se ejecutará)
(use «git checkout -- <archivo>...« para descartar cambios en le directorio de trabajo)

modificado: main.c

Archivos sin seguimiento:
(use «git add <archivo>...» para incluir lo que se ha de ejecutar)

func1.c
</source>

El archivo <code>main.c</code> aparece como modificado y git nos sugiere que agreguemos <code>func1.c</code> usando <code>git add</code>.

Si ejecutamos nuevamente <code>git add * </code> todos los arhcivos serán marcados para ser parte del siguiente commit pero podemos marcar los archivos que necesitemos y usar <code>git status</code> para ver la lista de los archivos con seguimiento.

== Quitar archivos del seguimiento ==

Es natural cometer errores al agregar archivos al índice, por ejemplo siguiendo el ejemplo anterior se desea quitar el archivo <code>README</code> así no se tomará en cuenta al hacer el siguiente commit. Afortunadamente podemos hacerlo con: <source lang="bash">
git rm --cached README
</source> Que quitará del seguimiento al archivo README, noten que la opción --cached se usa y es para indicar que '''se quite del seguimiento solamente'', con el siguiente ejemplo se puede apreciar esto.

----

Veamos un caso particular con el ejemplo anterior, se ha añadido por error un archivo <code>img.png</code> y al hacer git status aparece:

<source lang="bash">
Cambios para hacer commit:
(use «git rm --cached <archivo>...« para eliminar stage)

new file: func1.c
new file: img.png
new file: libs.h
new file: main.c

Archivos sin seguimiento:
(use «git add <archivo>...» para incluir lo que se ha de ejecutar)

README

</source>

Si hacemos <source lang="bash">
git rm *.png
</source>

Se desmarcarán los .png que estén actualmente en el seguimiento pero esto nos devolverá un error con: <source lang="bash">
error: the following file has changes staged in the index:
img.png
(use --cached to keep the file, or -f to force removal)
</source> Que nos dice que <code>img.png</code> se encuentra marcado y que usemos la opción <code>--cached</code> para quitarlo del índice de seguimiento o la opción <code>-f</code>. '''Si se usa <code>-f</code> git forzará la eliminación del índice y del disco duro.''' Por lo que realmente eliminaremos el archivo. Por eso la opción <code>--cached</code> elimina solamente del índice de seguimiento y protege el archivo original.

Ahora supongamos que hemos eliminado el archivo <code>func1.c</code> nosotros mismos al hacer git status aparecerá:
<pre>deleted: func1.c
</pre>
Que dice que se ha eliminado del disco ese archivo, para quitarlo del seguimiento podemos usar <source lang="bash">
git rm func1.c
</source> Que desmarcará el archivo eliminado y no entrará en el siguiente commit. Ahora al hacer <code>git status</code> ese archivo no aparecerá más por que ha sido eliminado del disco y también del seguimiento.

=== El archivo .gitignore ===

== Hacer un commit ==

Una vez tenemos marcados todos los archivos que se necesiten se puede hacer un commit que es tomar snapshots de todos los archivos marcados y guardarlos en la base de datos del repositorio git, entonces basta con:

<source lang="bash">
git commit
</source>

Al hacerlo se abrirá el editor especificado como por defecto para que escribamos un mensaje que describa los cambios hechos al trabajo en el commit actual. Las líneas que contengan #en el mensaje serán ignoradas. Al terminar de escribir el mensaje, guardarlo y salir del editor que se abrió el commit estará hecho. Podemos ver los distintos commits que se han hecho en el trabajo usando: <source lang="bash"> git log</source> Este un ejemplo del mensaje que muestra con <code>git log</code>.

<source lang="bash">
commit 6b3603354b48f5ef3f5b69f2140c8b66caabd8dc
Author: Juan Perez <juan@algo.com>
Date: Tue Jan 13 15:07:38 2015 -0400

Commit inicial

Este es el mensaje que aparecerá y nos muestra los cambios que se han hecho.
Es buena idea describir los cambios de manera concisa para tener una buena referncia
de los cambios realizados en este commit.
</source>

Se abre una pantalla de la que se puede salir con q y no muestra:

*<code>commit 6b3603354b48f5ef3f5b69f2140c8b66caabd8dc</code> - donde 6b3603354b48f5ef3f5b69f2140c8b66caabd8dc es la cadena que identifica al commit, esta cadena es única por commit y no hay riesgo de que se confunda con otro. A partir de ahora para referirnos a ese commit en particular se usará esa cadena.

*<code>Author: Juan Perez <juan@algo.com></code> muestra el autor y email de la persona que realizó el commit.

*<code>Date: Tue Jan 13 15:07:38 2015 -0400</code> La fecha y hora del commit.

> Luego se muestra el mensaje que se escribió indicando los cambios que representa el commit.

> Por cada commit se mostrará la misma estructura que la anterior y una vez hecho un commit los archivos incluídos en este están dentro el repositorio de versiones de git, esto quiere decir que son como puntos de retorno para deshacer cambios en los archivos. Por eso es buena idea hacer commits cada que se hagan cambios significativos o se desee hacer un respaldo de los cambios realizados desde un commit a otro.

=== Reparar commit ===

== Ver diferencias ==

== Deshacer cambios (volver a un estado anterior) ==

== Trabajando en ramas ==

Las ramas ("branches" en inglés) sirven para poder crear un repositorio paralelo al que estemos usando y poder trabajar en él sin necesidad de afectar al original.

Por ejemplo, digamos que creamos un "branch" llamado "bugFixing" (reparación de bugs) a partir de "master" (la rama principal), esto para que una parte del equipo siga creando nuevas características en el branch "master" y para que otra parte del equipo trabaje en la reparación de "bugs" en la rama "bugFixing". Al final de este proceso ambas ramas deben mezclarse ("merge") y volver a ser una sola.

[[File:GitBranches.png|center|GitBranches.png]]

=== Ver todas las ramas ===

<source lang="bash">$ git branch</source>

=== Cambiar a una rama ===

<source lang="bash">$ git checkout <nombre_de_la_rama></source>

=== Crear una rama en tu entorno local ===

<source lang="bash">$ git branch <nombre_de_la_rama></source>

=== Subir la rama al servidor ===

<source lang="bash">$ git push origin <nombre_de_la_rama></source>

=== Eliminar la rama de tu entorno local ===

<source lang="bash">$ git branch -D <nombre_de_la_rama></source>

=== Eliminar la rama en el servidor ===

<source lang="bash">$ git push origin --delete <nombre_de_la_rama></source>

== Clonar repositorio git ==

== Trabajo colaborativo ==

== Referencias ==

*[http://www.git-scm.com/book/en/v2 http://www.git-scm.com/book/en/v2]

Git (escencial)

2015-01-14T06:33:22Z

Jhtan:

En este artículo se muestra el manejo básico del sistema de versionamiento de código git, también algunos tips para aprovechar sus funcionalidades.

== Sistema de versionamiento ==

Un sistema de control de versionamiento de código (VCS en inglés) es un sistema que permite mantener versiones de un trabajo que se desarrolla, por ejemplo al escribir código a medida que se avanza en un programa puede darse el caso de necesitar que los archivos vuelvan a un estado anterior al actual. Los sitemas de versionamiento de código son las herramientas indicadas para ello, así si hemos hecho cambios problemáticos en nuestro código podemos cambiar el código a una versión anterior que no tenía problemas (o al menos no tantos ;) ).

Los sistemas de versionamiento no se limitan a código, sirven también para cualquier archivo.

Existen los CVCS (sistemas de versionamiento centralizado tales como '''svn''') y los DVCS (sistemas de control de versionamiento distribuido como git y bazaar), sólo veremos git por lo que los CVCS no se abarcarán en este artículo.

= Empezar a usar git =

== Requerimientos ==

Una pc con git instalado y una shell para introducir comandos, si no se tiene instalado git hay que instalarlo en un sistema basado en Debian bastaría con

<source lang="bash">apt-get install git</source>

== Como trabaja git ==

Lo primero es entender como git considera los cambios en los archivos.

=== Snapshots y no cambios en los archivos ===

Git hace "snapshots" en los archivos (es como tomar imágenes de un archivo para ver como luce), a medida que se va haciendo commits git hace snapshots de los archivos considerados y almacena una referencia a ese snapshot. Pero al hacer un nuevo commit git sólo almacena los snapshots que han cambiado.

Un ejemplo claro de esto es cuando uno inicia git, se hará un snapshot incial de por ejemplo un arhcivo. Luego se modifica ese archivo por ejemplo borrando una letra y luego volverla a escribir en el mismo lugar y luego guardar el archivo, para el sistema operativo u otros sistemas de versionamiento el archivo cambió pero en realidad el archivo luce exactamente igual.

Para git este archivo no cambió en lo absoluto y por eso al hacer de nuevo un snapshot git no registrará ningún cambió en el archivo por que los snapshots de ambos lucen iguales.

En cambio si el archivo cambió en al menos una letra los snapshots lucirán distintos y para git este cambio debe ser tomado en cuenta.

'''Es virtualmente imposible que git no note un cambio en los archivos''' bajo el principio mencionado arriba. Esto por que git usa algoritmos de checksum en este caso ''sha-1 hash''

=== Tres estados ===

Git hace que los archivos estén en uno de tres estados y estos son:

==== Modificado ====

El archivo has sido modificado ero no ha sido marcado para el siguiente commit.

==== Marcado para commit (staged) ====

Es cuando un archivo modificado ha sido marcado para que en el siguiente commit se tome un snapshot de este y se almacene en la base de datos del commit hecho. Cuando un archivo modificado ha sido marcado para ir en el siguiente commit se dice que ese archivo esta en el archivo conocido como '''índice'''o'''''staging area.

==== Comiteado (commited) ====

Significa que el archivo esta apropiadamente almacenado en la base de datos correspondiente al commit hecho. Esto sucede sólo con los archivos tomados en cuenta y luego se hace el uso de <code>git commit</code>

=== trabajo local ===

La gran ventaja de git es que no necesita conexion a internet para trabajar con el, por lo que la mayoría de los trabajaos lo hacemos en nuestra pc y en privado. Eso no significa que no se pueda trabajar colaborativamente mediante git, ya está diseñado para eso. Entonces git es una buena opción para trabajar proyectos en conjunto con otras personas a través de internet pero se puede usar git para trabajar individualmente y es una gran herramienta de versionamiento.

== Setup ==

Necesitamos hacer algunos ajustes si es la primera vez que usamos git en nuestra pc. Git guarda las '''configuraciones globales''' en la carpeta personal de cada usuario en; <code>~/.gitconfig </code>. Git también permite tener '''configuraciones locales''' es decir configuraciones distintas a las globales por repositorio donde el archivo se encuentra en el directorio principal del repositorio y dentro la carpeta .git entonces; <code>.git/config</code>

=== Indentificarse ===

Para identificar al autor de cada commit git necesita que se coloque una dirección de correo electrónico y el nombre, a continuación haremos una configuración global para el usuario acutal:

<source lang="bash">
git config --global user.name "Nombre del usuario"
git config --global user.email "correo@algo.com"
</source>

Este nombre de usuario correo electrónico aparecerán en cada commit que se haga y sirven para contactar al autor del commit.

Para hacer las configuraciones locales basta <code>git config --local</code> usando las mismas opciones que en global. Para esto la shell debe estar en el directorio del repositorio git en el que se quiere hacer los cambios y estas configuraciones locales se superpondrán a las configuraciones globales.

=== Editor por defecto ===

Adicionalmente se puede configurar el editor usado por defecto para escribir los mensajes al hacer los commits, por ejemplo para que el editor sea 'gedit'.

<source lang="bash">git config --global core.editor gedit</source>

== Crear repositorio git ==

Si queremos hacer que git colabore con el versionamiento de cualquier trabajo aquí simples pasos:

#Abrir una shell (terminal o consola)
#Dirigir la shell al direcotrio principal donde se encuentra el trabajo (cd hasta estar en el directorio donde esta nuestro trabajo)
#Una vez en el direcotorio principal escribir en la shell:

<source lang="bash">
git init
</source>

Se creará un repostorio git inicial, luego se puede ver que se ha creado una carpeta con el nombre <code>.git</code> que es donde se guarda el repositorio git.

== Añadir archivos al seguimiento ==

Una vez se ha creado el repositorio git ya se pueden marcar archivos para se comiteados el comando para esto es <code>git add</code>. Por ejemplo para agregar al índice un archivo llamado <code>README</code> se hace con:

<source lang="bash">git add README</source>

Ahora para agregar al índice todos los archivos que terminen en .c

<source lang="bash">git add *.c</source>

git soporta expresiones regulares por lo que se pueden usar los identificadores *, [], (), ? y otros.

== Ver seguimiento ==

El comando <code>git status</code> es el indicado

Hay que notar que los archivos añadidos con git add ahora están marcados para ser parte del siguiente commit y si su contenido cambia git lo notará y podremos visualizarlo con:

<source lang="bash">git status</source>

Ahora veamos un ejemplo donde se tiene un proyecto con tres archivos <code>main.c README libs.h</code>, supongamos que hemos ejecutado: <source lang="bash">git add *</source> Por lo que se han marcado todos los archivos y subcarpetas dentro de este directorio. Ahora al hacer <code>git status</code> aparece:

<source lang="bash">
Cambios para hacer commit:
(use «git rm --cached <archivo>...« para eliminar stage)

new file: README
new file: libs.h
new file: main.c
</source>

Esto nos muestra que se han agregado ciertos archivos para el siguiente commit. Ahora supongamos que hemos modificado el archivo <code>main.c</code> y hemos creado otro llamado <code>func1.c</code>, al hacer <code>git status</code> aparece:

<source lang="bash">
En la rama master

Commit inicial

Cambios para hacer commit:
(use «git rm --cached <archivo>...« para eliminar stage)

new file: README
new file: libs.h
new file: main.c

Cambios no preparados para el commit:
(use «git add <archivo>...» para actualizar lo que se ejecutará)
(use «git checkout -- <archivo>...« para descartar cambios en le directorio de trabajo)

modificado: main.c

Archivos sin seguimiento:
(use «git add <archivo>...» para incluir lo que se ha de ejecutar)

func1.c
</source>

El archivo <code>main.c</code> aparece como modificado y git nos sugiere que agreguemos <code>func1.c</code> usando <code>git add</code>.

Si ejecutamos nuevamente <code>git add * </code> todos los arhcivos serán marcados para ser parte del siguiente commit pero podemos marcar los archivos que necesitemos y usar <code>git status</code> para ver la lista de los archivos con seguimiento.

== Quitar archivos del seguimiento ==

Es natural cometer errores al agregar archivos al índice, por ejemplo siguiendo el ejemplo anterior se desea quitar el archivo <code>README</code> así no se tomará en cuenta al hacer el siguiente commit. Afortunadamente podemos hacerlo con: <source lang="bash">
git rm --cached README
</source> Que quitará del seguimiento al archivo README, noten que la opción --cached se usa y es para indicar que '''se quite del seguimiento solamente'', con el siguiente ejemplo se puede apreciar esto.

----

Veamos un caso particular con el ejemplo anterior, se ha añadido por error un archivo <code>img.png</code> y al hacer git status aparece:

<source lang="bash">
Cambios para hacer commit:
(use «git rm --cached <archivo>...« para eliminar stage)

new file: func1.c
new file: img.png
new file: libs.h
new file: main.c

Archivos sin seguimiento:
(use «git add <archivo>...» para incluir lo que se ha de ejecutar)

README

</source>

Si hacemos <source lang="bash">
git rm *.png
</source>

Se desmarcarán los .png que estén actualmente en el seguimiento pero esto nos devolverá un error con: <source lang="bash">
error: the following file has changes staged in the index:
img.png
(use --cached to keep the file, or -f to force removal)
</source> Que nos dice que <code>img.png</code> se encuentra marcado y que usemos la opción <code>--cached</code> para quitarlo del índice de seguimiento o la opción <code>-f</code>. '''Si se usa <code>-f</code> git forzará la eliminación del índice y del disco duro.''' Por lo que realmente eliminaremos el archivo. Por eso la opción <code>--cached</code> elimina solamente del índice de seguimiento y protege el archivo original.

Ahora supongamos que hemos eliminado el archivo <code>func1.c</code> nosotros mismos al hacer git status aparecerá:
<pre>deleted: func1.c
</pre>
Que dice que se ha eliminado del disco ese archivo, para quitarlo del seguimiento podemos usar <source lang="bash">
git rm func1.c
</source> Que desmarcará el archivo eliminado y no entrará en el siguiente commit. Ahora al hacer <code>git status</code> ese archivo no aparecerá más por que ha sido eliminado del disco y también del seguimiento.

=== El archivo .gitignore ===

== Hacer un commit ==

Una vez tenemos marcados todos los archivos que se necesiten se puede hacer un commit que es tomar snapshots de todos los archivos marcados y guardarlos en la base de datos del repositorio git, entonces basta con:

<source lang="bash">
git commit
</source>

Al hacerlo se abrirá el editor especificado como por defecto para que escribamos un mensaje que describa los cambios hechos al trabajo en el commit actual. Las líneas que contengan #en el mensaje serán ignoradas. Al terminar de escribir el mensaje, guardarlo y salir del editor que se abrió el commit estará hecho. Podemos ver los distintos commits que se han hecho en el trabajo usando: <source lang="bash"> git log</source> Este un ejemplo del mensaje que muestra con <code>git log</code>.

<source lang="bash">
commit 6b3603354b48f5ef3f5b69f2140c8b66caabd8dc
Author: Juan Perez <juan@algo.com>
Date: Tue Jan 13 15:07:38 2015 -0400

Commit inicial

Este es el mensaje que aparecerá y nos muestra los cambios que se han hecho.
Es buena idea describir los cambios de manera concisa para tener una buena referncia
de los cambios realizados en este commit.
</source>

Se abre una pantalla de la que se puede salir con q y no muestra:

*<code>commit 6b3603354b48f5ef3f5b69f2140c8b66caabd8dc</code> - donde 6b3603354b48f5ef3f5b69f2140c8b66caabd8dc es la cadena que identifica al commit, esta cadena es única por commit y no hay riesgo de que se confunda con otro. A partir de ahora para referirnos a ese commit en particular se usará esa cadena.

*<code>Author: Juan Perez <juan@algo.com></code> muestra el autor y email de la persona que realizó el commit.

*<code>Date: Tue Jan 13 15:07:38 2015 -0400</code> La fecha y hora del commit.

> Luego se muestra el mensaje que se escribió indicando los cambios que representa el commit.

> Por cada commit se mostrará la misma estructura que la anterior y una vez hecho un commit los archivos incluídos en este están dentro el repositorio de versiones de git, esto quiere decir que son como puntos de retorno para deshacer cambios en los archivos. Por eso es buena idea hacer commits cada que se hagan cambios significativos o se desee hacer un respaldo de los cambios realizados desde un commit a otro.

=== Reparar commit ===

== Ver diferencias ==

== Deshacer cambios (volver a un estado anterior) ==

== Trabajando en ramas ==

Las ramas ("branches" en inglés) sirven para poder crear un repositorio paralelo al que estemos usando y poder trabajar en él sin necesidad de afectar al original.

Por ejemplo, digamos que creamos un "branch" llamado "bugFixing" (reparación de bugs) a partir de "master" (la rama principal), esto para que una parte del equipo siga creando nuevas características en el branch "master" y para que otra parte del equipo trabaje en la reparación de "bugs" en la rama "bugFixing". Al final de este proceso ambas ramas deben mezclarse ("merge") y volver a ser una sola.

[[File:GitBranches.png|center|GitBranches.png]]

=== Ver todas las ramas ===
<source lang="bash">$ git branch</source>

=== Cambiar a una rama ===
<source lang="bash">$ git checkout <nombre_de_la_rama></source>

=== Crear una rama en tu entorno local ===
<source lang="bash">$ git branch <nombre_de_la_rama></source>

=== Subir la rama al servidor ===
<source lang="bash">$ git push origin <nombre_de_la_rama></source>

=== Eliminar la rama de tu entorno local ===
<source lang="bash">$ git branch -D <nombre_de_la_rama></source>

=== Eliminar la rama en el servidor ===
<source lang="bash">$ git push origin --delete <nombre_de_la_rama></source>

== Clonar repositorio git ==

== Trabajo colaborativo ==

== Referencias ==

*[http://www.git-scm.com/book/en/v2 http://www.git-scm.com/book/en/v2]

2015-01-07T02:19:38Z

Jhtan: Creando página de usuario para un nuevo usuario.

Manifiesto de un Criptopunk

2014-12-26T04:43:08Z

Jhtan:

Traducido de: [http://www.activism.net/cypherpunk/manifesto.html http://www.activism.net/cypherpunk/manifesto.html]

por [http://en.wikipedia.org/wiki/Eric_Hughes_%28cypherpunk%29 Eric Hughes]

La privacidad es necesaria para una sociedad abierta en la era de la electrónica. La privacidad no significa clandestinidad. Un asunto privado es algo que uno no quiere que todo el mundo sepa, pero un asunto secreto es algo que uno no quiere que nadie sepa. Privacidad es el poder de mostrarse selectivamente al mundo.

Si ambas partes tienen algún tipo de trato, entonces cada una tiene memoria de su interacción. Cada parte puede hablar sobre su propia memoria de esto; ¿Cómo podría alguien prevenir esto? Uno podría pasar las leyes en contra de esta, pero la libertad de expresión, incluso mucho más que la privacidad, es fundamental para una sociedad abierta; buscamos no restringir ningún discurso en absoluto. Si muchas partes hablan juntas en el mismo foro, cada una puede hablar a todas las otras y agregar juntas conocimientos sobre los individuos y las otras partes. El poder de las comunicaciones electrónicas a permitido tal discurso de grupo, y no va a desaparecer simplemente porque se quiere que se haga.

Desde que deseamos la privacidad, debemos asegurar que cada parte en una transacción tiene el conocimiento solo de lo que es directamente necesario para la transacción. Desde que se puede hablar de cualquier información, debemos asegurarnos de revelar lo más mínimo posible. En la mayoría de los casos, la identidad no es relevante. Cuando compro una revista en una tienda y le doy al empleado el dinero en la mano, no hay necesidad de que se sepa quién soy. Cuando yo le pido a mi proveedor de correo electrónico que envíe y reciba mensajes, mi proveedor necesita saber con quién me estoy comunicando o qué estoy diciendo o que están los otros diciéndome a mi; mi proveedor solo necesita saber como hacer llegar el mensaje ahí, y cuánto le debo por eso. Cuando mi identidad es revelada por el mecanismo subyacente de la transacción, no tengo privacidad. No puedo elegir mostrarme; Yo siempre debo mostrarme.

Por lo tanto, la privacidad en una sociedad abierta requiere sistemas de transacciones anónimas. Hasta ahora, el dinero a sido el único sistema primario de este tipo. Un sistema de transacción anónima no es un sistema de transacciones secretas. Un sistema anónimo da el poder a las personas a revelar su identidad cuando lo desean y solo cuando lo desean; esta es la esencia de la privacidad.

La privacidad en una sociedad abierta además requiere de la criptografía. Si yo digo algo, quiero que sea escuchado solo por aquellos a quienes me estoy dirigiendo. Si el contenido de mi discurso está disponible al mundo, no tengo privacidad. Encriptar es mostrar mi deseo por la privacidad, y encriptar debilmente es mostrar mi poco deseo por la privacidad. Por otra parte, revelar la identidad de uno mismo asegurandose que el anonimato por defecto requiere una firma criptográfica.

No podemos permitir que gobiernos, corporaciones, u otras grandes organizaciones sin rostros utilicen nuestra privacidad en su beneficio. Es su ventaja que puedan hablar de nosotros, y debemos esperar que ellos lo harán. Para prevenir sus discursos hay que luchar contra las realidades de la información. La información no solo quiere ser libre, esta anhela ser libre. La información se expande para llenar el espacio disponible en el almacenamiento. La información es mas jóven que el rumor, su primo fuerte; La información es más veloz a pie, tiene mas ojos, sabe mas, y entiende menos que el rumor.

Debemos defender nuestra propia privacidad si esperamos tener alguna. Debemos unirnos y crear sistemas que permitan tomar lugar a transacciones anónimas. La gente ha estado defendiendo su propia privacidad por siglos con susurros, oscuridad, sobres, puertas cerradas, apretones de mano secretos, y mensajeros. Las tecnologías del pasado no permitían una privacidad fuerte, pero las electrónicas lo hacen.

Nosotros los Criptopunks nos dedicamos a construir sistemas anónimos. Estamos defendiendo nuestra privacidad con criptografía, con sistemas de envío de correo anónimo, con firmas digitales, y con dinero electrónico.

Los Criptopunks escribimos código. Sabemos que alguien tiene que escribir software para defender la privacidad, y como no podemos tener privacidad a menos que nosotros mismo lo hagamos, nosotros vamos a escribirla. Publicamos nuestro código para que nuestros compañeros Criptopunks puedan practicar y jugar con el. Nuestro código es libre para su uso, en todo el mundo. No nos importa mucho si no apruebas el software que nosotros escribimos. Sabemos que el software no puede ser destruido y que un sistema disperso no se puede apagar.

Los Criptopunks deploran las regulaciones en criptografía, para el cifrado es fundamental un acto privado. El acto de cifrado, en efecto, elimina la información de la esfera pública. Incluso las leyes contra la criptografía llegan solo hasta los bordes de las naciones y el brazo de su violencia. La criptografía será ineluctablemente expandida por todo el globo, y con los sitemas de transacción anónimos que harán esto posible.

Para que la privacidad sea generalizada, esta debe ser parte de un contrato social. La gente debe unirse y desarrollar esos sistemas por el bien común. La privacidad solo se extiende en la medida que exista la cooperación de la sociedad. Nosotros los Criptopunks respondemos tus preguntas e inquietudes y esperamos que podamos participar con usted para que no nos engañemos a nostros mismos. Sin embargo, no nos alejaremos de nuestro discurso simplemente porque alguien no concuerde con nuestros objetivos.

Los Criptopunks estamos activamente ocupados en hacer de las redes más seguras para la privacidad. Procedamos juntos a buen ritmo.

Adelante.

Eric Hughes <hughes@soda.berkeley.edu>

9 de marzo de 1993

Manifiesto de un Criptopunk

2014-12-26T03:32:16Z

Jhtan: Página creada con «Manifiesto de un Criptopunk Traducido de: [http://www.activism.net/cypherpunk/manifesto.html] por [http://en.wikipedia.org/wiki/Eric_Hughes_%28cypherpunk%29 Eric Hughes ]...»

Manifiesto de un Criptopunk

Traducido de: [http://www.activism.net/cypherpunk/manifesto.html]

por [http://en.wikipedia.org/wiki/Eric_Hughes_%28cypherpunk%29 Eric Hughes ]

La privacidad es necesaria para una sociedad abierta en la era de la electrónica. La privacidad no significa clandestinidad. Un asunto privado es algo que uno no quiere que todo el mundo sepa, pero un asunto secreto es algo que uno no quiere que nadie sepa. Privacidad es el poder de mostrarse selectivamente al mundo.

by Eric Hughes
Privacy is necessary for an open society in the electronic age. Privacy is not secrecy. A private matter is something one doesn't want the whole world to know, but a secret matter is something one doesn't want anybody to know. Privacy is the power to selectively reveal oneself to the world.

If two parties have some sort of dealings, then each has a memory of their interaction. Each party can speak about their own memory of this; how could anyone prevent it? One could pass laws against it, but the freedom of speech, even more than privacy, is fundamental to an open society; we seek not to restrict any speech at all. If many parties speak together in the same forum, each can speak to all the others and aggregate together knowledge about individuals and other parties. The power of electronic communications has enabled such group speech, and it will not go away merely because we might want it to.

Since we desire privacy, we must ensure that each party to a transaction have knowledge only of that which is directly necessary for that transaction. Since any information can be spoken of, we must ensure that we reveal as little as possible. In most cases personal identity is not salient. When I purchase a magazine at a store and hand cash to the clerk, there is no need to know who I am. When I ask my electronic mail provider to send and receive messages, my provider need not know to whom I am speaking or what I am saying or what others are saying to me; my provider only need know how to get the message there and how much I owe them in fees. When my identity is revealed by the underlying mechanism of the transaction, I have no privacy. I cannot here selectively reveal myself; I must always reveal myself.

Therefore, privacy in an open society requires anonymous transaction systems. Until now, cash has been the primary such system. An anonymous transaction system is not a secret transaction system. An anonymous system empowers individuals to reveal their identity when desired and only when desired; this is the essence of privacy.

Privacy in an open society also requires cryptography. If I say something, I want it heard only by those for whom I intend it. If the content of my speech is available to the world, I have no privacy. To encrypt is to indicate the desire for privacy, and to encrypt with weak cryptography is to indicate not too much desire for privacy. Furthermore, to reveal one's identity with assurance when the default is anonymity requires the cryptographic signature.

We cannot expect governments, corporations, or other large, faceless organizations to grant us privacy out of their beneficence. It is to their advantage to speak of us, and we should expect that they will speak. To try to prevent their speech is to fight against the realities of information. Information does not just want to be free, it longs to be free. Information expands to fill the available storage space. Information is Rumor's younger, stronger cousin; Information is fleeter of foot, has more eyes, knows more, and understands less than Rumor.

We must defend our own privacy if we expect to have any. We must come together and create systems which allow anonymous transactions to take place. People have been defending their own privacy for centuries with whispers, darkness, envelopes, closed doors, secret handshakes, and couriers. The technologies of the past did not allow for strong privacy, but electronic technologies do.

We the Cypherpunks are dedicated to building anonymous systems. We are defending our privacy with cryptography, with anonymous mail forwarding systems, with digital signatures, and with electronic money.

Cypherpunks write code. We know that someone has to write software to defend privacy, and since we can't get privacy unless we all do, we're going to write it. We publish our code so that our fellow Cypherpunks may practice and play with it. Our code is free for all to use, worldwide. We don't much care if you don't approve of the software we write. We know that software can't be destroyed and that a widely dispersed system can't be shut down.

Cypherpunks deplore regulations on cryptography, for encryption is fundamentally a private act. The act of encryption, in fact, removes information from the public realm. Even laws against cryptography reach only so far as a nation's border and the arm of its violence. Cryptography will ineluctably spread over the whole globe, and with it the anonymous transactions systems that it makes possible.

For privacy to be widespread it must be part of a social contract. People must come and together deploy these systems for the common good. Privacy only extends so far as the cooperation of one's fellows in society. We the Cypherpunks seek your questions and your concerns and hope we may engage you so that we do not deceive ourselves. We will not, however, be moved out of our course because some may disagree with our goals.

The Cypherpunks are actively engaged in making the networks safer for privacy. Let us proceed together apace.

Onward.

Eric Hughes <hughes@soda.berkeley.edu>

9 March 1993

Página principal

2014-12-26T03:25:18Z

Jhtan:

{| width="1077" border="3" cellpadding="7" cellspacing="3"
|-
! style="background-color: rgb(0, 0, 0); text-align: center" | [[Manifiesto Hacklab|manifiesto@#r00thouse:~#]] 
|}

----

*'''[[Página principal#documentacion|DOCUMENTACIÓN]]'''
*'''[[Página principal#proyectos|PROYECTOS]]'''
*'''[[Página principal#eventos|EVENTOS]]'''

----
<div id="documentacion">'''DOCUMENTACIÓN''' </div>
{| width="785" border="0" cellpadding="10" cellspacing="5"
|-
! style="background-color: rgb(0, 102, 255); border-color: rgb(255, 255, 255)" |
'''Categoría'''

! style="background-color: rgb(0, 102, 255); border-color: rgb(255, 255, 255)" |
'''Descripción'''

|-
! style="background-color: rgb(160, 255, 207); border-color: rgb(221, 221, 218)" | '''[[:Category:Linux|GNU/Linux]]''' 
! style="background-color: rgb(160, 255, 207); border-color: rgb(221, 221, 218)" |
Documentación genérica de distintas herramientas de administración y técnicas de programación en el sistema operativo GNU/Linux.

|-
! style="background-color: rgb(255, 255, 255); border-color: rgb(221, 221, 218)" |
''[[File:Gnu-tux.png|center|100x100px|Separated-gnu-tux.png]]'''''[[Núcleo GNU/Linux|Núcleo GNU/Linux]]'''

| style="background-color: rgb(255, 255, 204); border-color: rgb(221, 221, 218)" | Curso introductorio al uso del sistema operativo libre '''GNU/Linux''' y otras herramientas de software libre.Dirigido a ''estudiantes ''que quieran lograr una migración completa de sistemas con software privativo a un sistema operativo GNU/Linux que es libre.

|-
! style="background-color: rgb(255, 255, 255); border-color: rgb(221, 221, 218)" | [[File:Ioi-medal.png|center|60x60px|Ioi-medal.png]][[Entrenamiento OBI|Entrenamiento OBI]] 
| style="background-color: rgb(204, 255, 255); border-color: rgb(221, 221, 218); text-align: center" |
Entrenamiento de la UMSA para la Olimpiada Boliviana de Informática, y para la Olimpiada Internacional de Informática.

|-
! style="background-color: rgb(255, 235, 233); border-color: rgb(221, 221, 218)" | [[Disco Utilidades 1|Disco utilidades 1]] 
! style="background-color: rgb(255, 235, 233); border-color: rgb(221, 221, 218)" | HACKER DISC es un disco versátil de doble capa 8 Gigas, en el cual están fijados montón de libros en pdf para aficionados y estudiantes de ''informática, sistemas, electrónica, diseño'' y documentación de ''software libre''. 
|-
! [[Arduino|Arduino]] 
! Proyectos realizados con arduino 
|-
! [[Parrillada]] 
! Documentación sobre las parrilladas :9 
|-
! [[Desarrollo de videojuegos|Desarrollo de Videojuegos]] 
! Desarrollo de videojuegos en general 
|-
! [[Manifiesto de un Criptopunk]]
! 
|-
! 
! 
|}
<div id="proyectos">'''PROYECTOS''' </div>
{| border="0" cellpadding="10" cellspacing="4"
|-
! scope="col" style="border-color: rgb(255, 255, 255); background-color: rgb(0, 102, 255)" |
Proyecto

! scope="col" style="border-color: rgb(255, 255, 255); background-color: rgb(0, 102, 255)" |
Descripción

|-
| style="border-color: rgb(255, 255, 255); background-color: rgb(241, 240, 252)" | '''[[Hacklab Website|Hacklab Website]]''' 
| style="border-color: rgb(255, 255, 255); background-color: rgb(241, 240, 252)" | Desarrollo de la página web del r00thouse usando Django 
|-
| style="border-color: rgb(255, 255, 255); background-color: rgb(241, 240, 252)" | '''[[Wardriving|Wardriving]]''' 
| style="border-color: rgb(255, 255, 255); background-color: rgb(241, 240, 252)" | Contar con una base de datos de consulta de las redes wifi de Bolivia 
|-
| style="border-color: rgb(255, 255, 255); background-color: rgb(241, 240, 252)" | '''[[Dead Drops|Dead Drops]]''' 
| style="border-color: rgb(255, 255, 255); background-color: rgb(241, 240, 252)" | Una forma cool, offline, anónima y p2p para compartir información 
|-
| style="border-color: rgb(255, 255, 255); background-color: rgb(241, 240, 252)" | '''[[Hacklab Network|Hacklab Network]]''' 
| style="border-color: rgb(255, 255, 255); background-color: rgb(241, 240, 252)" |
Es la implementación de Diaspora en el r00thouse para la integración de otros hacklabs, hactivistas y comunidades afines al software libre del país.

[http://pod.hacklab.org.bo/ https://pod.hacklab.org.bo/]

|-
| style="border-color: rgb(255, 255, 255); background-color: rgb(241, 240, 252)" | '''Hacklab Wiki''' 
| style="border-color: rgb(255, 255, 255); background-color: rgb(241, 240, 252)" |
Implementación de Mediawiki para la documentación y gestión de actividades en el hacklab.

[http://wiki.hacklab.org.bo/ http://wiki.hacklab.org.bo/]

|-
| style="border-color: rgb(255, 255, 255); background-color: rgb(241, 240, 252)" | [[Red Mesh|Redes Mesh]] 
| style="border-color: rgb(255, 255, 255); background-color: rgb(241, 240, 252)" | implementacion de una red de nodos bajo frecuencias libres. 
|-
| style="border-color: rgb(255, 255, 255); background-color: rgb(241, 240, 252)" | [[Piratebox]] 
| style="border-color: rgb(255, 255, 255); background-color: rgb(241, 240, 252)" | El objetivo de este proyecto es hacer un Piratebox para poder compartir archivos en el Hacklab los días de nuestras reuniones, y además llevarlo a otros lugares como a la Universidad y eventos. 
|-
| style="border-color: rgb(255, 255, 255); background-color: rgb(241, 240, 252)" | '''Creación y animación de un cubo de leds de 8 de lado.''' 
| style="border-color: rgb(255, 255, 255); background-color: rgb(241, 240, 252)" | checkeen esto: [http://www.youtube.com/watch?v=6mXM-oGggrM http://www.youtube.com/watch?v=6mXM-oGggrM] 
|-
| style="border-color: rgb(255, 255, 255); background-color: rgb(241, 240, 252)" | [[Feria del prado|'''PARTICIPACIÓN EN LA FERIA DEL PRADO''']] 
| style="border-color: rgb(255, 255, 255); background-color: rgb(241, 240, 252)" | Tramitar la licencia para obtener un puesto en la tradicional feria paceña de los domingos. Y designar cada domingo a dos personas distintas de forma obligatoria y la participación de los lignuxeros de la comunidad de forma libre. El stand contendra cuadros informativos, cuadros murales, venta de distros, venta de poleras, de stickers, venta de gorras, venta de botones, venta de pingûinos de peluche, en fin... venta de cualquier sourvenir. Además de llevar una laptop para la exposición de algun documental o videotutorial. 
|-
| style="border-color: rgb(255, 255, 255); background-color: rgb(241, 240, 252)" | [[Directorio de proyectos|Directorio de proyectos]] 
| style="border-color: rgb(255, 255, 255); background-color: rgb(241, 240, 252)" | Un mapa con geolocalización de personas que están haciendo "cosas", y descripción sobre qué tipo de "cosas" están haciendo. 
|-
| style="border-color: rgb(255, 255, 255); background-color: rgb(241, 240, 252)" | Nuevo proyecto aqui 
| style="border-color: rgb(255, 255, 255); background-color: rgb(241, 240, 252)" | 
|}
<div id="eventos">'''EVENTOS''' </div>
{| class="cke_show_border" width="739" border="0" cellpadding="10" cellspacing="4"
|-
! scope="col" style="border-color: rgb(255, 255, 255); background-color: rgb(0, 102, 255)" |
Evento

! scope="col" style="border-color: rgb(255, 255, 255); background-color: rgb(0, 102, 255)" |
Descripción

|-
| scope="col" style="border-color: rgb(102, 102, 255); background-color: rgb(255, 204, 51); white-space: nowrap; width: 220px" | Nuevo evento 
| scope="col" style="border-color: rgb(102, 102, 255); background-color: rgb(255, 255, 102); text-align: left" | 
|-
| scope="col" style="border-color: rgb(102, 102, 255); background-color: rgb(255, 204, 51); white-space: nowrap; width: 100px" | [[File:HourOfCode.png|none|100x100px|HourOfCode.png]] '''[[La Hora del Código|La Hora del Código]]'''
| scope="col" style="border-color: rgb(102, 102, 255); background-color: rgb(255, 255, 102); text-align: left" | Organización del evento: La Hora del Código en Bolivia. 
|-
| scope="col" style="border-color: rgb(255, 255, 255); background-color: rgb(204, 204, 204); white-space: nowrap; width: 220px" |
[[Semana del Ñu y el pingüino 2014|'''Semana del Ñu y el pingüino 2014''']]

(del lunes 17 al viernes 21 de noviembre)

| scope="col" style="border-color: rgb(255, 255, 255); background-color: rgb(225, 232, 225); text-align: left" | Una semana entera de charlas, seminarios y concursos de software libre en la Carrera de informática de la UMSA, ven, participa y aporta al software libre y cultura libre. 
|-
| scope="col" style="border-color: rgb(255, 255, 255); background-color: rgb(204, 204, 204); white-space: nowrap; width: 220px" |
[[Ciclo de peliculas de Sci - Fi]]

| scope="col" style="border-color: rgb(255, 255, 255); background-color: rgb(225, 232, 225); text-align: left" |
Exhibir películas de ciencia ficción para debatir y distinguir entre ciencia y ciencia emergente.

|-
| scope="col" style="border-color: rgb(255, 255, 255); background-color: rgb(204, 204, 204); white-space: nowrap; width: 220px" |
[[Encuentro Hacklabs 2014|Encuentro_Hacklabs_2014]]

| scope="col" style="border-color: rgb(255, 255, 255); background-color: rgb(225, 232, 225); text-align: left" | Evento que pretende socializar e intercambiar conociemtos entre Hacklabs Locales 
|}

'''To do list'''

Cosas que hacer cuando estemos de vagos :P

*Impresora 3D.
*Un cuadracóptero.
*Terminar la documentación de [[GPG]].
*Terminar el [[Manifiesto Hacklab]].
*Hacer un [[Manifiesto del Hackmeeting Boliviano]].
*Terminar el totem del Hackmeeting.
*Script para sacar backups de: la wiki, el blog y el diaspora

Usuario discusión:Dagmoreno

2014-12-09T23:36:39Z

Jhtan: Bienvenido!

Usuario:Dagmoreno

2014-12-09T23:36:39Z

Jhtan: Creando página de usuario para un nuevo usuario.

Usuario discusión:Rodrigo

2014-12-09T22:15:58Z

Jhtan: Bienvenido!

Usuario:Rodrigo

2014-12-09T22:15:57Z

Jhtan: Creando página de usuario para un nuevo usuario.

La Hora del Código

2014-12-05T03:39:24Z

Jhtan:

= UMSA 2014 =

La "Hora del código" es un evento para incentivar a chic@s de colegio la programación.

Más información en: [http://code.org/ http://code.org/]

*La fecha del evento en la UMSA es el viernes 12 de diciembre de 10:00 AM  a 4:00 PM
*Los lugares donde se llevará a cabo el evento son:
**Biblioteca de Informática
**Laboratorio de Telemática
*Las personas que apoyarán en el evento son:
**Alison Parisaca
**Rodrigo Castillo
**Carlos Torrez
**Oscar Carvajal
**Jhonatan Castro (mañana)
**...
*Los juegos que utilizaremos en el evento serán:
**...
**...
*Los afiches que tenemos para difución esta semana son:
**...

La Hora del Código

2014-12-05T03:18:41Z

Jhtan: Página creada con «= UMSA 2014 =»

= UMSA 2014 =

Página principal

2014-12-05T03:11:24Z

Jhtan:

{| width="1077" border="3" cellpadding="7" cellspacing="3"
|-
! style="background-color: rgb(0, 0, 0); text-align: center" | [[Manifiesto Hacklab|manifiesto@#r00thouse:~#]] 
|}

----

 '''DOCUMENTACIÓN'''

{| width="785" border="0" cellpadding="10" cellspacing="5"
|-
! style="background-color: rgb(0, 102, 255); border-color: rgb(255, 255, 255)" | '''Categoría''' 
! style="background-color: rgb(0, 102, 255); border-color: rgb(255, 255, 255)" | '''Descripción''' 
|-
! style="background-color: rgb(160, 255, 207); border-color: rgb(221, 221, 218)" | '''[[:Category:Linux|GNU/Linux]]''' 
! style="background-color: rgb(160, 255, 207); border-color: rgb(221, 221, 218)" |
Documentación genérica de distintas herramientas de administración y técnicas de programación en el sistema operativo GNU/Linux.

|-
! style="background-color: rgb(255, 255, 255); border-color: rgb(221, 221, 218)" |
''[[File:Gnu-tux.png|center|100x100px|Separated-gnu-tux.png]]'''''[[Núcleo GNU/Linux|Núcleo GNU/Linux]]'''

| style="background-color: rgb(255, 255, 204); border-color: rgb(221, 221, 218)" | Curso introductorio al uso del sistema operativo libre '''GNU/Linux''' y otras herramientas de software libre.Dirigido a ''estudiantes ''que quieran lograr una migración completa de sistemas con software privativo a un sistema operativo GNU/Linux que es libre.

|-
! style="background-color: rgb(255, 255, 255); border-color: rgb(221, 221, 218)" |
[[File:HourOfCode.png|center|60x60px|HourOfCode.png]] [[La Hora del Código]]

| style="background-color: rgb(255, 255, 204); border-color: rgb(221, 221, 218)" | Organización del evento: La Hora del Código en Bolivia.
|-
! style="background-color: rgb(255, 255, 255); border-color: rgb(221, 221, 218)" | [[File:Ioi-medal.png|center|60x60px|Ioi-medal.png]][[Entrenamiento OBI|Entrenamiento OBI]] 
| style="background-color: rgb(204, 255, 255); border-color: rgb(221, 221, 218); text-align: center" |
Entrenamiento de la UMSA para la Olimpiada Boliviana de Informática, y para la Olimpiada Internacional de Informática.

|-
! style="background-color: rgb(255, 235, 233); border-color: rgb(221, 221, 218)" | [[Disco Utilidades 1|Disco utilidades 1]] 
! style="background-color: rgb(255, 235, 233); border-color: rgb(221, 221, 218)" | HACKER DISC es un disco versátil de doble capa 8 Gigas, en el cual están fijados montón de libros en pdf para aficionados y estudiantes de ''informática, sistemas, electrónica, diseño'' y documentación de ''software libre''. 
|-
! [[Arduino|Arduino]] 
! Proyectos realizados con arduino 
|-
! Ignites 
! [[22/02/14|22/02/14]], [[08/03/14|08/03/14]] 
|}

 '''PROYECTOS'''

{| border="0" cellpadding="10" cellspacing="4"
|-
! scope="col" style="border-color: rgb(255, 255, 255); background-color: rgb(0, 102, 255)" | Proyecto 
! scope="col" style="border-color: rgb(255, 255, 255); background-color: rgb(0, 102, 255)" | Descripción 
|-
| style="border-color: rgb(255, 255, 255); background-color: rgb(241, 240, 252)" | '''[[Hacklab Website|Hacklab Website]]''' 
| style="border-color: rgb(255, 255, 255); background-color: rgb(241, 240, 252)" | Desarrollo de la página web del r00thouse usando Django 
|-
| style="border-color: rgb(255, 255, 255); background-color: rgb(241, 240, 252)" | '''[[Wardriving|Wardriving]]''' 
| style="border-color: rgb(255, 255, 255); background-color: rgb(241, 240, 252)" | Contar con una base de datos de consulta de las redes wifi de Bolivia 
|-
| style="border-color: rgb(255, 255, 255); background-color: rgb(241, 240, 252)" | '''[[Dead Drops|Dead Drops]]''' 
| style="border-color: rgb(255, 255, 255); background-color: rgb(241, 240, 252)" | Una forma cool, offline, anónima y p2p para compartir información 
|-
| style="border-color: rgb(255, 255, 255); background-color: rgb(241, 240, 252)" | '''[[Hacklab Network|Hacklab Network]]''' 
| style="border-color: rgb(255, 255, 255); background-color: rgb(241, 240, 252)" |
Es la implementación de Diaspora en el r00thouse para la integración de otros hacklabs, hactivistas y comunidades afines al software libre del país.

[http://pod.hacklab.org.bo/ https://pod.hacklab.org.bo/]

|-
| style="border-color: rgb(255, 255, 255); background-color: rgb(241, 240, 252)" | '''[[Hacklab Wiki|Hacklab Wiki]]''' 
| style="border-color: rgb(255, 255, 255); background-color: rgb(241, 240, 252)" |
Implementación de Mediawiki para la documentación y gestión de actividades en el hacklab.

[http://wiki.hacklab.org.bo/ http://wiki.hacklab.org.bo/]

|-
| style="border-color: rgb(255, 255, 255); background-color: rgb(241, 240, 252)" | [[Red Mesh|Redes Mesh]] 
| style="border-color: rgb(255, 255, 255); background-color: rgb(241, 240, 252)" | implementacion de una red de nodos bajo frecuencias libres. 
|-
| style="border-color: rgb(255, 255, 255); background-color: rgb(241, 240, 252)" | [[Piratebox]] 
| style="border-color: rgb(255, 255, 255); background-color: rgb(241, 240, 252)" | El objetivo de este proyecto es hacer un Piratebox para poder compartir archivos en el Hacklab los días de nuestras reuniones, y además llevarlo a otros lugares como a la Universidad y eventos. 
|-
| style="border-color: rgb(255, 255, 255); background-color: rgb(241, 240, 252)" | '''Creación y animación de un cubo de leds de 8 de lado.''' 
| style="border-color: rgb(255, 255, 255); background-color: rgb(241, 240, 252)" | checkeen esto: [http://www.youtube.com/watch?v=6mXM-oGggrM http://www.youtube.com/watch?v=6mXM-oGggrM] 
|-
| style="border-color: rgb(255, 255, 255); background-color: rgb(241, 240, 252)" | [[Feria del prado|'''PARTICIPACIÓN EN LA FERIA DEL PRADO''']] 
| style="border-color: rgb(255, 255, 255); background-color: rgb(241, 240, 252)" | Tramitar la licencia para obtener un puesto en la tradicional feria paceña de los domingos. Y designar cada domingo a dos personas distintas de forma obligatoria y la participación de los lignuxeros de la comunidad de forma libre. El stand contendra cuadros informativos, cuadros murales, venta de distros, venta de poleras, de stickers, venta de gorras, venta de botones, venta de pingûinos de peluche, en fin... venta de cualquier sourvenir. Además de llevar una laptop para la exposición de algun documental o videotutorial. 
|}

EVENTOS

{| class="cke_show_border" width="739" border="0" cellpadding="10" cellspacing="4"
|-
! scope="col" style="border-color: rgb(255, 255, 255); background-color: rgb(0, 102, 255)" | Evento 
! scope="col" style="border-color: rgb(255, 255, 255); background-color: rgb(0, 102, 255)" | Descripción 
|-
| scope="col" style="border-color: rgb(102, 102, 255); background-color: rgb(255, 204, 51); white-space: nowrap; width: 220px" | Nuevo evento 
| scope="col" style="border-color: rgb(102, 102, 255); background-color: rgb(255, 255, 102); text-align: left" | 
|-
| scope="col" style="border-color: rgb(255, 255, 255); background-color: rgb(204, 204, 204); white-space: nowrap; width: 220px" |
[[Semana del Ñu y el pingüino 2014|'''Semana del Ñu y el pingüino 2014''']]

(del lunes 17 al viernes 21 de noviembre)

| scope="col" style="border-color: rgb(255, 255, 255); background-color: rgb(225, 232, 225); text-align: left" | Una semana entera de charlas, seminarios y concursos de software libre en la Carrera de informática de la UMSA, ven, participa y aporta al software libre y cultura libre. 
|-
| scope="col" style="border-color: rgb(255, 255, 255); background-color: rgb(204, 204, 204); white-space: nowrap; width: 220px" |
[[Ciclo de peliculas de Sci - Fi]]

| scope="col" style="border-color: rgb(255, 255, 255); background-color: rgb(225, 232, 225); text-align: left" |
Exhibir películas de ciencia ficción para debatir y distinguir entre ciencia y ciencia emergente.

|-
| scope="col" style="border-color: rgb(255, 255, 255); background-color: rgb(204, 204, 204); white-space: nowrap; width: 220px" |
[[Encuentro Hacklabs 2014|Encuentro_Hacklabs_2014]]

| scope="col" style="border-color: rgb(255, 255, 255); background-color: rgb(225, 232, 225); text-align: left" | Evento que pretende socializar e intercambiar conociemtos entre Hacklabs Locales 
|}

  

     

'''To do list'''

Cosas que hacer cuando estemos de vagos :P

*Impresora 3D.
*Un cuadracóptero.
*Terminar la documentación de [[GPG]].
*Terminar el [[Manifiesto Hacklab]].
*Hacer un [[Manifiesto del Hackmeeting Boliviano]].
*Terminar el totem del Hackmeeting.
*Script para sacar backups de: la wiki, el blog y el diaspora

2014-11-30T01:02:37Z

Jhtan:

{| cellpadding="7" cellspacing="3" border="3" width="1077"
|-
! style="background-color: rgb(0, 0, 0); text-align: center" | [[Manifiesto Hacklab|manifiesto@#r00thouse:~#]] 
|}

----

 '''DOCUMENTACIÓN'''

{| cellpadding="10" cellspacing="5" border="0" width="785"
|-
! style="background-color: rgb(0, 102, 255); border-color: rgb(255, 255, 255)" | '''Categoría''' 
! style="background-color: rgb(0, 102, 255); border-color: rgb(255, 255, 255)" | '''Descripción''' 
|-
! style="background-color: rgb(160, 255, 207); border-color: rgb(221, 221, 218)" | '''[[:Category:Linux|GNU/Linux]]''' 
! style="background-color: rgb(160, 255, 207); border-color: rgb(221, 221, 218)" |
Documentación genérica de distintas herramientas de administración y técnicas de programación en el sistema operativo GNU/Linux.

|-
! style="background-color: rgb(255, 255, 255); border-color: rgb(221, 221, 218)" |
''[[File:Gnu-tux.png|center|100x100px|Separated-gnu-tux.png]]'''''[[Núcleo GNU/Linux|Núcleo GNU/Linux]]'''

| style="background-color: rgb(255, 255, 204); border-color: rgb(221, 221, 218)" | Curso introductorio al uso del sistema operativo libre '''GNU/Linux''' y otras herramientas de software libre.Dirigido a ''estudiantes ''que quieran lograr una migración completa de sistemas con software privativo a un sistema operativo GNU/Linux que es libre.

|-
! style="background-color: rgb(255, 255, 255); border-color: rgb(221, 221, 218)" | [[File:Ioi-medal.png|center|60x60px|Ioi-medal.png]][[Entrenamiento OBI|Entrenamiento OBI]] 
| style="background-color: rgb(204, 255, 255); border-color: rgb(221, 221, 218); text-align: center" |
Entrenamiento de la UMSA para la Olimpiada Boliviana de Informática, y para la Olimpiada Internacional de Informática.

|-
! style="background-color: rgb(255, 235, 233); border-color: rgb(221, 221, 218)" | [[Disco Utilidades 1|Disco utilidades 1]] 
! style="background-color: rgb(255, 235, 233); border-color: rgb(221, 221, 218)" | HACKER DISC es un disco versátil de doble capa 8 Gigas, en el cual están fijados montón de libros en pdf para aficionados y estudiantes de ''informática, sistemas, electrónica, diseño'' y documentación de ''software libre''. 
|-
! [[Arduino|Arduino]] 
! Proyectos realizados con arduino 
|-
! Ignites 
! [[22/02/14|22/02/14]], [[08/03/14|08/03/14]] 
|-
! [[Profesores|Profesores]] 
! Clases de capacitación para los profesores 
|}

 '''PROYECTOS'''

{| cellpadding="10" cellspacing="4" border="0"
|-
! scope="col" style="border-color: rgb(255, 255, 255); background-color: rgb(0, 102, 255)" | Proyecto 
! scope="col" style="border-color: rgb(255, 255, 255); background-color: rgb(0, 102, 255)" | Descripción 
|-
| style="border-color: rgb(255, 255, 255); background-color: rgb(241, 240, 252)" | '''[[Hacklab Website|Hacklab Website]]''' 
| style="border-color: rgb(255, 255, 255); background-color: rgb(241, 240, 252)" | Desarrollo de la página web del r00thouse usando Django 
|-
| style="border-color: rgb(255, 255, 255); background-color: rgb(241, 240, 252)" | '''[[Wardriving|Wardriving]]''' 
| style="border-color: rgb(255, 255, 255); background-color: rgb(241, 240, 252)" | Contar con una base de datos de consulta de las redes wifi de Bolivia 
|-
| style="border-color: rgb(255, 255, 255); background-color: rgb(241, 240, 252)" | '''[[Dead Drops|Dead Drops]]''' 
| style="border-color: rgb(255, 255, 255); background-color: rgb(241, 240, 252)" | Una forma cool, offline, anónima y p2p para compartir información 
|-
| style="border-color: rgb(255, 255, 255); background-color: rgb(241, 240, 252)" | '''[[Hacklab Network|Hacklab Network]]''' 
| style="border-color: rgb(255, 255, 255); background-color: rgb(241, 240, 252)" |
Es la implementación de Diaspora en el r00thouse para la integración de otros hacklabs, hactivistas y comunidades afines al software libre del país.

[http://pod.hacklab.org.bo/ https://pod.hacklab.org.bo/]

|-
| style="border-color: rgb(255, 255, 255); background-color: rgb(241, 240, 252)" | '''[[Hacklab Wiki|Hacklab Wiki]]''' 
| style="border-color: rgb(255, 255, 255); background-color: rgb(241, 240, 252)" |
Implementación de Mediawiki para la documentación y gestión de actividades en el hacklab.

[http://wiki.hacklab.org.bo/ http://wiki.hacklab.org.bo/]

|-
| style="border-color: rgb(255, 255, 255); background-color: rgb(241, 240, 252)" | [[Red Mesh|Redes Mesh]] 
| style="border-color: rgb(255, 255, 255); background-color: rgb(241, 240, 252)" | implementacion de una red de nodos bajo frecuencias libres. 
|-
| style="border-color: rgb(255, 255, 255); background-color: rgb(241, 240, 252)" | '''Creación y animación de un cubo de leds de 8 de lado.''' 
| style="border-color: rgb(255, 255, 255); background-color: rgb(241, 240, 252)" | checkeen esto: [http://www.youtube.com/watch?v=6mXM-oGggrM http://www.youtube.com/watch?v=6mXM-oGggrM] 
|-
| style="border-color: rgb(255, 255, 255); background-color: rgb(241, 240, 252)" | [[Feria del prado|'''PARTICIPACIÓN EN LA FERIA DEL PRADO''']] 
| style="border-color: rgb(255, 255, 255); background-color: rgb(241, 240, 252)" | Tramitar la licencia para obtener un puesto en la tradicional feria paceña de los domingos. Y designar cada domingo a dos personas distintas de forma obligatoria y la participación de los lignuxeros de la comunidad de forma libre. El stand contendra cuadros informativos, cuadros murales, venta de distros, venta de poleras, de stickers, venta de gorras, venta de botones, venta de pingûinos de peluche, en fin... venta de cualquier sourvenir. Además de llevar una laptop para la exposición de algun documental o videotutorial. 
|}

EVENTOS

{| class="cke_show_border" cellpadding="10" cellspacing="4" border="0" width="739"
|-
! scope="col" style="border-color: rgb(255, 255, 255); background-color: rgb(0, 102, 255)" | Evento 
! scope="col" style="border-color: rgb(255, 255, 255); background-color: rgb(0, 102, 255)" | Descripción 
|-
| scope="col" style="border-color: rgb(102, 102, 255); background-color: rgb(255, 204, 51); white-space: nowrap; width: 220px" | Nuevo evento 
| scope="col" style="border-color: rgb(102, 102, 255); background-color: rgb(255, 255, 102); text-align: left" | 
|-
| scope="col" style="border-color: rgb(255, 255, 255); background-color: rgb(204, 204, 204); white-space: nowrap; width: 220px" |
[[Semana del Ñu y el pingüino 2014|'''Semana del Ñu y el pingüino 2014''']]

(del lunes 17 al viernes 21 de noviembre)

| scope="col" style="border-color: rgb(255, 255, 255); background-color: rgb(225, 232, 225); text-align: left" | Una semana entera de charlas, seminarios y concursos de software libre en la Carrera de informática de la UMSA, ven, participa y aporta al software libre y cultura libre. 
|-
| scope="col" style="border-color: rgb(255, 255, 255); background-color: rgb(204, 204, 204); white-space: nowrap; width: 220px" |
= [[Ciclo de peliculas de Sci - Fi]] =

| scope="col" style="border-color: rgb(255, 255, 255); background-color: rgb(225, 232, 225); text-align: left" | Exhibir películas de ciencia ficción para debatir y distinguir entre ciencia y ciencia emergente. 
|}

 '''To do list'''

Cosas que hacer cuando estemos de vagos :P

*[[Piratebox]]
*Impresora 3D.
*Un cuadracóptero.
*Terminar la documentación de [[GPG]].
*Terminar el [[Manifiesto Hacklab]].
*Hacer un [[Manifiesto del Hackmeeting Boliviano]].
*Terminar el totem del Hackmeeting.

Ciclo de peliculas de Sci - Fi

2014-11-30T01:00:57Z

Jhtan:

'''OBJETIVO'''

Exhibir películas de ciencia ficción para debatir y distinguir entre ciencia y ciencia emergente.

'''ANTECEDENTES'''

Muchos hacklabs han realizado ciclos de películas antes y han tenido éxito ya que en medio del debate se llega descubrir cosas, se llega a conclusiones y se generan nuevas ideas.

'''MARCO TEORICO'''

Ciencia ficción es la denominación popular con que se conoce a uno de los géneros derivados de la literatura de ficción, junto con la literatura fantástica y la narrativa de terror. Nacida como subgénero literario distinguido en la década de 1920 (aunque hay obras reconocibles muy anteriores) y exportada posteriormente a otros medios, como el cinematográfico, historietístico y televisivo, gozó de un gran auge en la segunda mitad del siglo xxdebido al interés popular acerca del futuro que despertó el espectacular avance tanto científico como tecnológico alcanzado durante todos estos años.

Es un género especulativo que relata acontecimientos posibles desarrollados en un marco puramente imaginario, cuya verosimilitud se fundamenta narrativamente en los campos de las ciencias físicas, naturales y sociales. La acción puede girar en torno a un abanico grande de posibilidades (viajes interestelares, conquista del espacio, consecuencias de una hecatombe terrestre o cósmica, evolución humana a causa de mutaciones, evolución de los robots, realidad virtual, existencia de civilizaciones alienígenas, etc.). Esta acción puede tener lugar en un tiempo pasado, presente o futuro, o, incluso, en tiempos alternativos ajenos a la realidad conocida, y tener por escenario espacios físicos (reales o imaginarios, terrestres o extraterrestres) o el espacio interno de la mente. Los personajes son igualmente diversos: a partir del patrón natural humano, recorre y explota modelos antropomórficos hasta desembocar en la creación de entidades artificiales de forma humana (robot, androide, cíborg) o en criaturas no antropomórficas, dotadas de inteligencia.

'''Películas de Ciencia Ficción'''

Es un género de peliculas que usa ciencia ficcion especulativay fenomenos que no son aceptados por la ciencia oficial. Ha sido usado para enfocar problemas politicos, sociales y hasta éticos y filosóficos de la condición humana.

'''LISTA DE PELICULAS'''

#Lucy
#Trascendence
#Her
#Cocoon
#Interestelar
#Gravedad
#Looper
#Distrito 9
#Soy leyenda
#Matrix
#Under Skin