El mes pasado se anunció una nueva versión para la distribución de Elementary OS, Juno. De él conocía su apariencia, tiene su propio escritorio llamado «Pantheon», que esta basado en GNOME.
No conozco la apariencia del sistema operativo de MacOs, pero dicen que Elementary es muy similar. La verdad me parece muy bonita, no he necesitado cambiar nada de sitio, aunque ya me di cuenta de que, en caso de querer cambiarlo, no podría. Las opciones de personalización son mucho más limitadas que en Cinnamon o Plasma.
Por el momento he usado Elementary para trabajar en Godot y producir algunos vídeos. Al principio pensé que sólo pasaría unos días en esta distro y después volvería a Linux Mint, pero me he quedado más tiempo del previsto y estoy bien aquí. Les voy a dejar algunos puntos sobre esta distribución, así deciden si probarla o dejarla de lado:
Tienda de aplicaciones
Quizás esto es muy básico, pero una de las principales razones por las que decidí probar Elementary es su tienda de aplicaciones, y no por separarme de la terminal, sino para publicar en ella.
En el sitio web de Elementary OS se invita a los programadores a desarrollar aplicaciones para su tienda y ganar algo de dinero, ya que en esa tienda puedes ajustar un precio por tu Software sin dejar de ser libre. Y aunque puedes ajustar el precio de «0$», me parece que más de una persona puede preferir pagar por el precio que propongamos, este modelo no se encuentra en otras tiendas de Software como la de Ubuntu o Linux Mint.
Por otro lado, la documentación de Elementary para desarrollar aplicaciones en su sistema es muy completa. La he estado siguiendo y es fascinante. Han realizado un gran trabajo para traer desarrolladores a su distribución.
Atajos de teclado
Esto lo descubrí usando la distribución. Si presionas la tecla de «Windows» se abrirá un panel con todos los comandos disponibles. Lo mejor es el Shift+Imprimir, ese me permite seleccionar el área de mi monitor donde quiera tomar una captura de pantalla. Me ahorra mucho tiempo.
Contra: en algunos comando relacionados con el cambio de aplicaciones, me parece que es el: Windows+Espacio, se congela la pantalla. Tiene un bug, así que tuve que dejar de usarlo. Es un bug detectado en la versión anterior de Elementary OS, pero parece que sigue sin solucionar… en caso de que lo sufras, trata de usar el comando Alt+Tab, así cambias de aplicación y probablemente se descongele la pantalla.
Producción de vídeos
Después de instalar SimpleScreenRecorder tuve problemas con el audio. Al parecer, tienes que entrar en la configuración de dispositivos de entrada y indicar un volumen de entrada para el micrófono… lastima que ya había perdido dos vídeos.
Por último para este campo, debo mencionar que la producción de vídeos de KdenLive tarda el doble que en Linux Mint y el tripe que Canaima GNU/Linux.
Godot Engine
Al principio Elementary no reconoce el ejecutable de Godot, así que lo tuve que ejecutar desde la terminal. Para mi sorpresa, sólo tenía que actualizar la distribución. Al principio viene muy cruda, no funciona la tienda y tampoco estos archivos ejecutables, pero después de actualizar todo vuelve a la normalidad y podemos programar nuestros jueguitos.
Conclusión
Hasta donde he usado Elementary OS voy bien. Descargué de la tienda un programa llamado Notes-Up muy bueno desarrollado por un mejicano.
Y ahora no sé que más añadir. Si te gusta personalizar tu sistema operativo mejor que no uses Elementary, aunque claro, tampoco he probado desinstalar el Pantheon y poner Plasma, que debe ser una opción.
Si eres un aficionado a la programación, te recomiendo pasar por aquí y experimentar con el desarrollo de Software que nos propone esta distribución. Si tienes una duda, no olvides dejarla en los comentarios.
La semana pasada se publicó UltraSpaceShips RPG. Un juego de naves que nos ofrece mecánicas originales y diferentes modalidades. Su principal desarrollador, Matías Muñoz Espinoza, instructor en Youtube y Udemy, se animó a compartir un poco de su experiencia como programador y desarrollador de vídeojuegos.
Entrevista con Matías
Presentación:
Mi nombre completo es Matías Valentín Muñoz Espinoza y estos últimos años me he dedicado en su mayor parte al desarrollo de videojuegos. Tengo un canal de youtube (FuryCode) y formo parte de un equipo (FuryGames), en FuryGames inicialmente era yo solo, pero ahora somos más y vamos avanzando.
1. ¿Cuándo iniciaste FuryCode y FuryGames?
FuryCode empezó primero, fue el 9 de noviembre del 2012 (Fue el primer video del canal), empece con algo de desarrollo web (no tenía mucho conocimiento, pero aprendía mientras hacía los videos) el primer curso fue de Sass y Compass, Sass es un preprocesador de CSS y Compas es un framework. Para no hablar mucho de esto digamos que Sass es un lenguaje encima del CSS que se traduce (transpila) a CSS, creo que actualmente se usa bastante y es recomendable su uso.
Y FuryGames fue después, fue mas o menos en mayo del 2016. Y FuryGames a tenido muchos intentos de ser un grupo estable de desarrollo, en cuanto a personas, pero es algo que cuesta bastante. Sobre todo si no tienes dinero que ofrecer y puedes ofrecer solo un porcentaje de participación en los desarrollos, normalmente ofrecía un porcentaje equitativo. Sin muchas reglas y con muchos ánimos. Pero después con el tiempo uno se va dando cuenta que esto de tener grupos de desarrollo es un tema muy complejo, de mucha motivación, etc.
2. ¿Por qué elegiste Godot Engine?
No me considero extremista del Open Source, pero es algo que me gusta bastante. También soy usuario de Linux, tanto que, no tengo Windows ni lo he tocado desde hace mucho tiempo, de hecho me confundo un poco en Windows. Como Godot es un proyecto Open Source y a la vez Software Libre, es algo que me gusta mucho, funciona muy bien con Linux y es algo que se estaba esperando. Hace tiempo no habían engines (con editor) que funcionaran en Linux, o por lo menos no eran tan maduros como Godot Engine.
Godot al principio fue mera curiosidad, antes use un tiempo LibGDX, que es un framework. Y me di cuenta que Godot Engine agiliza mucho el trabajo, en LibGDX me tomaba siglos un par de cosas que se podían hacer en poco tiempo en Godot Engine. Aunque es verdad que hay gente que quiere hacer todo en código, yo les digo a esas personas que no es necesario hacer todo en código, hay trabajo muy tedioso y repetitivo que sea hace en un framework, la idea de los engine es disminuir ese trabajo tedioso y repetitivo. Y ¿Códear?, al final terminas codeando más del 70% en Godot Engine, osea usando un Engine no te deshaces de codear sino que del trabajo repetitivo.
3. ¿Cómo surgió la idea de Spaceship Shooter?
Al principio fue por experimentar mecánicas distintas, se me ocurrió eso de que las naves enemigas y las balas tengan gravedad en una jam. Era una Jam de pocas personas que creamos con unos amigos de Discord. Un saludo para ellos…
Bueno en esa Jam se creó el primer prototipo, que fue en una semana. El juego esta en itch.io como Ultra Spaceship Shooter.
Después de eso trate de hacer el mismo juego pero ponerle cosas RPG, solo algunos elementos RPG, “No iba a ser la gran cosa decía yo” y al final termine desarrollando un plugin para facilitar la lógica de los juegos RPG.
El segundo juego (Spaceship Shooter RPG Deluxe) no lo hice solo, me ayudaron en muchas cosas, sobre todo con la parte gráfica. También programación, un chico que luego desapareció.
4. ¿Cuesta formar un equipo de desarrollo?
En realidad formar un equipo no es difícil, lo que cuesta en realidad es mantener el equipo y cumplir objetivos. Para eso hay que tratar de ser lo mas organizado posible, y no desistir. Claro que puedes tomarte un tiempo de descanso, pero, también después hay que volver.
No soy para nada una persona exitosa, pero tengo algo experiencia en equipos remotos. Por mera práctica. Y lo que recomendaría para un equipo remoto, sería:
1) Un líder que ponga las tareas y que nunca se canse, y motive al equipo. Resuelva conflictos mas que provocarlos.
2) Cuando hayan conflictos tratar de que el grupo no se disuelva.
3) Usar herramientas de gestión de proyectos, como podría ser HackNPlan.
4) No ser tóxico, las cosas siempre se puede decir de buenas palabras.
5) Avanzar a pesar de que no todos pueden dar el mismo tiempo de trabajo.
6) Usar GIT.
7) Usar Google Drive o/y Dropbox.
8) Hablar las cosas antes de que sucedan
5. ¿Cuánto tiempo costó desarrollar SpaceShip?
La verdad que costó bastante tiempo. Estaba tratando de desarrollar la idea y tuve algunos problemas con el proyecto por usar versiones de Software inestable (La alpha de Godot 3.1).
Aunque el proyecto en equipo empezó el 30/05/2018 y salió la primera versión en el 31/10/2018 evidentemente hubieron muchos tiempos de descanso y de poca participación, también hubo un mes que me tome para hacer el curso de GDScript en Godot Engine.
6. ¿Cuál fue la mecánica más difícil de programar?
Bueno personalmente me enredé un poco en el tema de los ítems, la tienda y esas cosas. No sabía bien como almacenar los items en disco, recuperarlos, etc. Por eso aislé el problema y lo hice un plugin, liberando el código a toda la comunidad.
Pero no hay nada que no se pueda resolver con un papel y lápiz, y esto aunque parezca una práctica no tan importante, es vital. De hecho hay una frase que dice “Resuelve el problema, luego escribe el código”. No digo que siempre haya que cumplirlo, pero cuando uno se ve complicado, es bueno hacerlo.
7. ¿Tienes otros proyectos?
Sí, claro, tengo varios proyectos en Itch.io y en Google Play. Actualmente estoy participando en la jam de GithubGameOFF con un juego de monstruos.
8. ¿Qué tal es la experiencia publicando en Google Play?
La verdad, es difícil, en Google Play hay mucha competencia. Cada día salen más y más aplicaciones. Si uno no tiene los medios para el marketing lo único que queda es tratar de hacer un buen producto y que guste. Y esto no es para nada fácil.
La verdad el tráfico orgánico es lo que mas me ha dado resultado hasta el momento, aunque aún así todavía no hay buenos resultados.
Bueno, no quiero deprimiros con Google Play pero el tema es que hay que seguir y tarde o temprano se cosecha lo que se siembra. Hay gente que le va muy bien con los juegos en Google Play, pero me imagino que solo pocos, muy pocos, les ha ido bien a la primera.
9. ¿Cómo te va publicando en Itch.io?
¡Mal! ¿No es suficiente con preguntar lo de Google Play?. Por ahora Itch.io lo veo como portafolio, pero no es malo. Siempre hay gente que le va bien en esas cosas, pero es algo complicado. También tiene opciones muy interesantes como Jams y devlogs.
10. ¿Continuarás usando Godot Engine para futuros proyectos?
Por su puesto, es un engine que cada vez me gusta más y cada vez me da mejores resultados.
11. ¿Es rentable el desarrollo de tus proyectos?
Por ahora no… Pero en el desarrollo de videojuegos hay que pensar a largo plazo.
12. ¿Recomendarías algo a los nuevos desarrolladores que usen Godot u otro Engine?
Claro, como pudieron ver no soy la persona mas exitosa del mundo, pero si he aprendido varias cosas.
1) Si eres nuevo no hagas proyectos grandes, lo normal es que tengas una mala experiencia con ellos y los dejes abandonados. Es mucho mas motivador terminar cosas pequeñas que muy probablemente no terminar algo muy grande. Puedes ir aumentando de a poco y de paso hacerte portafolio.
2) El desarrollo de videojuegos es golpearse contra la pared varias veces, donde la pared es la realidad. Es un tema en el cuál hay que aprender mucho de varias cosas, para lograr buenos resultados. Mucha práctica. No le hagas asco a las demás áreas. Si eres bueno programando no le hagas asco a la música o al arte o al marketing. Con esto me refiero a que sepas un poco de todo, esto te servirá mucho. Si haces el peor pixel art del mundo, por lo menos es -tú- pixel art y eso se valora mucho.
3) Usa Git o un sistema de control de versiones: Esto te ayudará a no perder el proyecto y a recuperar cosas que “perdiste”.
4) Usa un administrador de proyectos: HackNPlan o Trello, estan muy bien, pero se organizado. Esto aumenta mucho la productividad. Aumentar la productividad es también un tema de engañar a tu cerebro. Aprende de los demás: Ve videos, escucha mas que hablar, hay gente que le va bien que tiene mucho que decir y hay gente que no le va tan bien que también tiene mucho que decir.
5) Filtra bien las críticas: Hay críticas que son sólo para hacer daño y hay críticas que son constructivas. Por lo general las críticas que son dañinas son sólo eso, dañinas, no muestran cosas positivas de tu juego. No pierdas el tiempo con ellas. Siempre hay algo positivo. Por muy malo que sea tu juego siempre se puede rescatar algo. Las criticas constructivas tienen el componente “ayuda” y se nota. Normalmente te dicen me gusta esto, pero no me gusta esto. Son objetivas.
6) Termina los proyectos: No soy el indicado para decirlo, pero es algo que se tiene que aprender. Cuando empieces un proyecto, tiene que ser algo que te motive. Motivación vas a necesitar para terminar el proyecto.
7) Planifica tu proyecto, es algo que he aprendido a porrazos. Si lees esto, avisado estas, no comentas estos errores. Has un GDD (Game Doument Design).
Con esto terminamos esta sesión de preguntas. Muchas gracias Matías por estos consejos. Puedes visitar sus redes sociales con los siguientes enlaces:
Cuando eres desarrollador de Software tienes una idea clara: conseguir algo con un producto. Por un lado tenemos la posibilidad de vender una copia del trabajo acompañado con una licencia que restrinja la distribución y/o modificación del mismo. Pero por otro podemos vender una copia y permitir que ese comprador modifique y distribuya una versión de tu trabajo libremente.
Este último se puede ver mal desde un punto de vista estratégico: cabe la posibilidad de que cualquier persona con un cambio insignificante, pueda vender más copias que tú mismo. Pero no es del todo correcto, hay licencias que te respaldan al momento de vender Software Libre. Por lo tanto, nos reducimos a una pregunta: ¿Cómo se gana más dinero? Puede que el Software privativo te otorgue más beneficio, pero la verdadera pregunta: ¿Necesitas, de verdad, mucho dinero?
Suponiendo que el producto que desarrolles es malo, no se venderá bien y las pocas personas que lo adquieran se verán frenadas para modificarlo en caso de que detengas su desarrollo por el fracaso. No me parece bueno desde ningún punto de vista.
Suponiendo que tu producto es bueno, venderás bien como Software Libre y aunque se hagan versiones modificadas de tu trabajo, representas al «padre», la persona responsable que puede responder a cualquier problema relacionado con ese producto. Por lo tanto, los compradores te darán prioridad aunque tengan versiones modificadas para escoger. (A menos que tengas 0% elocuencia).
Tenemos una conclusión sencilla: de las dos formas podrás comer. Teniendo en cuenta que harás un buen trabajo. Sólo te toca elegir: en un lado puedes privar a tus compradores de la libertad y por el otro formar algo más grande: una comunidad junto a tu proyecto, una comunidad de desarrolladores que se interesan por enriquecer de funciones tu producto. Yo creo que se pueden sacrificar unas miseras monedas ¿No?.
Ahora enumeraré formas para obtención de ingresos desarrollando Software Libre que he encontrado en grandes proyectos.
Formas para obtener ingresos desarrollando Software Libre
1) Plataformas de micro-mecenazgo
Hoy en día esta cobrando fuerza que los proyectos relacionados con Software Libre ofrezcan recompensas por ayudarlos con una cantidad de dinero cada mes. De esta forma podemos ofrecer algo mejor según la cantidad de apoyo que recibamos de nuestros usuarios. Todo gestionado desde una plataforma como Patreon.
Linux Mint y su PatreonGodot es un claro ejemplo, con su Patreon y otros métodos
2) Vendiendo el Software
Ser Software Libre no quiere decir que sea gratuito. Puedes vender la copia de tu programa, sólo debes permitirle a las personas la libertad de ver el código fuente, modificarlo y distribuirlo si así lo desean. Pero puedes venderla, y siempre serás el referente, el padre.
Aseprite tiene su código fuente en GitHub y puedes compilarlo…
3) Ofreciendo soporte técnico
Si una empresa se anima a probar tu Software pero no sabe como hacerlo o necesita ayuda para algo específico, les puedes cobrar por guiarlos.
MySQL lo hizo en su inicio
4) Manuales, cursos, tutoría
Ligado quizás con el soporte, puedes desarrollar manuales y cursos audiovisuales únicos que las personas puedan adquirir.
5) Donaciones
Para esto no hace falta que coloque ejemplos: todo proyecto de Software Libre tiene su Paypal y cuenta de Bitcoin abierta para que pongan una moneda. Sólo debes encontrar la forma de hacerle saber a tus usuarios que necesitas comer, si tu proyecto es bueno, no dudarán en ayudarte.
Espero que esta información sea suficiente para ustedes. He omitido muchos proyectos, como WordPress.org, Mozila o Cannonical, que ganan dinero desarrollando software libre y, de paso, gratuito para todos.
Cuando distribuyes productos de software esperas obtener algo. Quizás dinero, pero también respeto. Producir requiere nuestro recurso más valioso: el tiempo. Necesitamos tiempo para formarnos sobre un tema y tiempo para aplicar nuestros conocimientos. Por desgracia, para producir necesitamos mantenernos con vida, metiendo en el juego nuevas variables que debemos satisfacer.
Queremos trabajar, pero primero necesitamos comer… en algún
momento socializar y también descansar. Sin contar con que somos
humanos y que unas tres variables desencadenan un sinfín de
“necesidades”. Durante siglos hemos vivido para trabajar y
formar nuestras familias. Trabajamos para alguien que consiguió
tanto dinero como para pagarnos por nuestro tiempo y ganar lo
suficiente como para pagarle a otras personas como nosotros.
Voy a plantear un punto de vista que considero popular: En la
informática y alguna que otra área, empezamos como trabajadores
encargados de hacer realidad la idea de alguien superior, lo hacemos
por un sueldo justo que tenga relación con nuestro tiempo (invertido
por aprender y producir). Si somos buenos desarrollaremos nuevas
capacidades y escalaremos en otras posiciones dentro de la empresa,
mejorando nuestro sueldo. ¿Para qué mejorar nuestro suelo? Cuando
ya tengamos la comida de nuestra familia garantizada, podremos
invertir en viajes, electrodomésticos y cualquier otra cosa. En
algunos casos la simple razón de tener dinero es suficiente.
Seguimos por aquí: cuando una persona pasa de ser trabajador a
administrar trabajadores, entra en una nueva etapa. Deja de invertir
su tiempo en la perspectiva de su propia supervivencia, ahora
necesita que su empresa siga adelante y reporte beneficios. Tengamos
en cuenta que estas personas son sometidas a nuevos catálogos en los
mercados, disponen de un dinero que les permite comprar productos
mejores, ayudando así a su productividad y relación con “nuevos
semejantes”. Se considera importante nuestra “imagen”. Por
ende, estas personas con dinero, tomarán los nuevos catálogos y
destacaran del resto. Si eres jefe no puedes permitirte un traje
sucio, el teléfono anticuado o la casa oscura. Para beneficio de
todos, o la mitad del mundo, el ser humano tiende a mejorar su forma
de vida. Cada mes tenemos tecnologías innovadoras, al menos, nuevas
en apariencia.
Saquemos conclusión de esta perspectiva: nos formamos como
trabajadores y si emprendemos, si demostramos valor, tendremos la
recompensa. Subiremos por la escalera a lo largo de nuestros días y
le garantizaremos buena vida a nuestra familia. Eso esta muy bien.
Todos queremos tener una vida garantizada: dedicar el tiempo justo al
trabajo y vivir bien. ¿Con un sistema así cómo encontramos el
entretenimiento? Si ignoramos que algunas personas recurren a las
drogas, la prostitución o las chatarras tecnológicas, obtendremos
un sacrificio mayor por el trabajo: nos marcaremos retos para escalar
en nuestros puestos. Algunos necesitarán destacar fuera, sin la
posibilidad de ser eclipsados por la empresa de su jefe. Ahí tenemos
al emprendedor. Él creará algo único y le pondrá un precio
razonable porque se merece la paga monetaria.
En esos tres párrafos describo escuetamente una idea. Una perspectiva que, me parece, siguen muchas personas. Ahora vamos con la zurda. Supongamos algo radical: no piensas en dinero, lo usas para sobrevivir pero lo que te satisface es hacer tu trabajo (mal pagado o no) por el impacto positivo en la sociedad/comunidad de la que formas parte. Esto puede pasar perfectamente desde mi otra perspectiva, me refiero a tener buen sueldo y también estar feliz con el impacto, la diferencia es que sin la afición de acumular dinero por destacar nuestra “imagen”, dejamos de necesitar dinero para algo más que sobrevivir y ser útiles en la vida. El interés de estar encima de alguien por resaltar tu posición desaparece, no ves entretenimiento en ser superior sobre las personas de tu entorno, sino en cumplir unicamente con tu deber y vivir por ello.
Si no te importa el dinero, es
probable que no te obligues a mantener un estilo de vida lujoso y lo
inviertas directamente en el desarrollo de tu trabajo y la
prosperidad de la comunidad. Desde
las dos perspectivas el humano busca entretenimiento: en la derecha
quieres destacar en la sociedad por los logros que has conseguido
como persona, y da la casualidad que la mayoría de los logros
propuestos por la sociedad están relacionados con el mercado y el
consumo. A la izquierda nos entretenemos unicamente con la producción
y el goce de lo resultado con toda la comunidad, no se goza
unicamente con las personas de “nuestro nivel social”.
Todavía soy un joven con ideas locas que no se ha enfrentado con el
“mundo laboral” como para doblegarse a él o “entrar en razón”
y cambiar mi forma de pensar. Con esfuerzo haré lo posible por no
caer tan bajo. Yo quiero trabajar, me gusta trabajar.
Voy a poner otro caso: en la derecha, cuando ya fuimos trabajadores
mucho tiempo, vemos la necesidad de ser jefes por codiciar sus horas
libres, dejar de trabajar y optar por esos entretenimientos
propuestos en la sociedad. Para ser sincero, todavía no conozco
personas relacionadas con el Software Libre que siendo jefes,
subjefes, encargados, supervisores… detengan su trabajo o anhelen
tiempo libre, el entretenimiento esta en su trabajo, y tienen la
libertad de trabajar en lo que sea, además de desarrollar una
sentido de responsabilidad distinta e infinitamente más eficiente.
Ahora voy a responder a una pregunta: ¿Por qué regalas tu trabajo?.
Cuando caí en el mundo de GNU/Linux me encontré con decenas de
personas que se sacrifican todos los días por producir. No están
obligadas a “regalar su trabajo”, pero en el ambiente del
Software Libre la pasión por sembrar y disfrutar de la cosecha junto
a otras personas es algo más fuerte que unas miseras monedas. Estas
personas que trabajan por todos tienen un alto sentido de
responsabilidad: saben lo que tienen que hacer y están satisfechos
con cumplir su deber. Yo regalo mi trabajo porque prefiero que las
personas jóvenes y sin empleo aprendan de mis pasos, ¿a cuántas
personas pobres o en cualquier lado del mundo donde conseguir dólares
o una simple computadora es un sacrificio, les niegas tu código? Las
gracias de cada día me llenan el cuerpo más que la droga que pueda
adquirir con dinero.
Sería genial que cambiando las raíces, un gobierno nos mantuviera
vivos sin necesidad de que tengamos que pedir donaciones para
entretenernos con el trabajo de nuestro “tiempo libre”. Es un
argumento clásico contra el comunismo: “produce vagos que se
mantienen con el gobierno”, pero no debería ser así. Básicamente
el problema es querer meter comunismo cuando la sociedad tiene los
conceptos capitalistas del entretenimiento. Si viviéramos como en
una comunidad de Software Libre donde todos conocemos nuestra
responsabilidad y la trabajamos con nuestro ritmo sin chistar, sería
perfecto. Cada quién trabaja lo que puede y gana lo que necesita. Y nada más.
El escritorio Cinnamon de Linux Mint es precioso. Consumiendo menos recursos que GNOME y manteniendo una buena apariencia como Plasma. Por defecto no contamos con un «dock», en Plasma podemos construirlo con el mismo panel, pero en Cinnamon vamos a instalarlo desde la terminal.
Instalación del dock «Plank»
Abrimos la terminal y copiamos el siguiente comando:
sudo apt-get install plank
Preferencias de Plank
Para configurar nuestro nuevo dock, abrimos la terminal y escribimos:
plack --preferences
Se nos abrirá una ventana como esta:
Ahora pueden cambiar lo que necesiten. Después, cierran la ventana.
Espero que este dock para Linux Mint sea de su agrado, si necesitan ayuda con los comandos de Plank, escriban en la terminal lo siguiente:
A muchos usuarios de sistemas tipo Unix nos parece que la interfaz de linea de comandos es una maravilla a la hora de manejar un sistema. Todos hemos trabajado con bash por ser el más estandarizado pero no es el único, como es el cazo de fish.
Sobre fish
Fish es una shell «exótica» puesto que tiene muchas diferencias contra las más comunes. Busca ser rápida, amigable, personalizable y con muchas facilidades.
Uso básico
Si queremos probar fish debemos teclear fish en la terminal. Por otro lado si nos ha gustado y queremos establecerla como la shell por defecto usamos chsh -s /usr/bin/fish $USER e introducimos nuestra contraseña.
Lo que notamos al inicio de usar fish es el resaltado de colores que da a los comandos para separar visualmente las partes de este y facilitar su lectura y/o escritura.
La predicción de comandos es algo que destaca en fish, mostrándolos en gris y siguiendo prediciendo según vayamos escribiendo el comando. Para esto toma en cuanta el directorio en que estemos, los comandos recientes, los más frecuentes, etc.
Para autocompletar el comando debemos presionar la tela de flecha que apunta a la derecha.
Tambien podemos usar el autocompletado estilo bash que es de poco a poco usando la tecla tab.
Si son varias las posibilidades nos enlistara las posibles secuencias siguientes y podremos cambiar entre ellas usando la tecla tab y seleccionando una con enter.
En este modo podremos comenzar a teclear para hacer una búsqueda entre las posibilidades, se selecciona usando enter.
fish nos proporciona facilidades para escribir comandos de una manera simple. Por ejemplo en lugar de hacer cd Descargas/, podremos usar simplemente Descargas/
Personalizacion
Tendremos una interfaz web para personalizar el prompt a la cual se accede ejecutando fish_config. En la seccion color podemos indicar algun esquema de colores de nuestra preferencia.
En la sección prompt tendremos algunos para cambiar el que trae por defecto.
Los prompts nos añaden muchas funciones más, no solo mostrar datos de la maquina y el directorio. Se integra con git para mostrar cambios si tenemos un repositorio, la rama, versión…
Sin duda fish es una herramienta excelente para el uso de la linea de comandos.
Para los vídeo tutoriales que estoy produciendo me hace falta una herramienta decaptura de pantalla que sea fácil de instalar, con eso me refiero a que se debe encontrar en los repositorios de la distribución GNU/Linux que esté usando.
Hasta hace unas semanas fue suficiente para mi usar la herramienta de Vokoscreen, pero me presentó problemas para detectar mi micrófono por alguna razón que desconozco. Me hablaron de Simple Screen Recorder .
Hoy en día no tengo problemas con este software y les puedo contar mis conclusiones comparando con Vokoscreen, además de hacer mención del comando para instalar SimpleScrenRecorder desde la terminal :p .
Instalar SimpleScreenRecorder
Si eres usuario de Debian/Ubuntu/Linux Mint, entonces puedes poner en la terminal lo siguiente: (Copia el comando y en la terminal presiona Control+Shift+V)
sudo apt-get install simplescreenrecorder
Ventajas de SimpleScreenRecorder
Cuando abramos por primera vez el programa (y durante todos los inicios ), nos encontraremos con la pantalla de bienvenida:
Antes de empezar a grabar la pantalla debemos pasar por tres secciones de configuración diferentes. Para evitar tener que cambiar la configuración cuando quieras grabar otro tipo de vídeo, como por ejemplo GamePlays, puedes guardar diferentes perfiles con tu configuración. Sólo tienes que hacer clic en el botón de «New Profile» y hacer cambios. Cuando quieras trabajar con otra configuración seleccionas el perfil correspondiente.
En la segunda sección ya tienes que decidir cosas importantes como el formato de vídeo que se guardará con finalizar la grabación. Por defecto esta el formato .mkv, Matrosca, muy bueno para reducir el tamaño. Al igual que en la primera sección, aquí puedes hacer tus propios perfiles de configuración.
También debes asignar la ruta para guardar la grabación, este paso es más cómodo que en vokoscreen ya que te ponen la opción de frente y no tienes que buscarla en las diferentes opciones.
Por último tenemos la sección de grabación. Cunado la inicies (y esto es lo mejor) se mostrará información sobre el tiempo de la grabación y el tamaño que tiene tu archivo en el segundo actual. Sólo queda hacer clic en «guardar grabación» cuando todo este listo y volver a empezar, esta vez con los perfiles configurados.
Un poco sobre SimpleScreenRecorder
Publicada oficialmente en 2012 por Maater Baert, SimpleScreenRecorder se distribuye en la plataforma de GitHub con la licencia libre de GPL. El programa usa la tecnología Qt para su interfaz de usuario (Qt… el preferido de KDE) y libav o ffmpeg como codificador de vídeo y audio.
Generalmente encontramos todos los programas que necesitamos en los repositorios de una distribución. Podemos instalarlos fácilmente con «sudo apt-get install programa», pero si de repente estamos en otra distribución es probable que no podamos instalar el mismo programa desde la terminal.
Mi caso es que en Canaima pude instalar Aseprite desde la terminal, sin necesidad de compilarlo y tardar ese rato resolviendo errores con cmake. En Linux Mint, que llevo un par de semanas probando, Aseprite no esta en los repositorios, tengo que compilarlo…
Después de tener los errores de compilación, busqué una forma de «pasar» el programa de Aseprite instalado en Canaima, a un paquete .deb instalable en otros sistemas de Debian. Sigue el artículo para que aprendas a hacerlo.
Programa necesario
Para instalar el paquete que necesitamos, que se llama dpkg-repack, vamos a abrir la terminal y copiamos lo siguiente:
sudo apt-get install dpkg-repack
Para hacer un paquete del programa que tengamos instalado en el sistema escribimos lo siguiente (todo en la terminal :p):
sudo dpkg-repack PAQUETE
# Yo hice: sudo dpkg-repack aseprite
Ya estamos listos. En la carpeta de «home» ya tendrán su paquete creado 🙂
Ya que conocemos la historia de la Open Source Initiative, veamos a la Free Software Foundation, mejor conocida como FSF.
El inicio de la Free Software Foundation (FSF)
Para conocer la historia de dicha fundación, tenemos que situarnos en el trabajo de Richard Stallman en 1971 con el Laboratorio de Inteligencia Artificial de MIT.
Ese año, Stallman se unió a una comunidad de hackers que compartía software, en ese tiempo no existía la etiqueta de «software libre», pero hacían algo semejante: si un estudiante necesitaba aprender sobre un programa, se le mostraba el código, si necesitaban un programa se facilitaba una copia, etc.
Esta comunidad se desintegró con el tiempo. A comienzos de los años ochenta muchos miembros fueron contratados por otras empresas y los restantes no pudieron continuar.
Un par de años después, en el Laboratorio de Stallman, estaba la necesidad de mejorar los equipos en cuando a hardware y software, para eso se optó por usar licencias privativas donde a los trabajadores se les impedía compartir los programas que se desarrollaran o usaran en el trabajo.
Todo estaba muy claro: «para usar esta computadora debes prometer que no compartirás ninguna copia del sistema o del software». Además de eso, los usuarios no tendrían acceso al código fuente del software que estaban adquiriendo, las modificaciones eran faltas graves y eran propias de «piratas».
Stallman tenía un conflicto moral en su trabajo. Para él no es ético privar al prójimo del software y colaborar para el desarrollo de software privativo no era una opción. A raíz de esto, Stallman decidió trabajar en un nuevo sistema operativo que sea libre y permita que sus usuarios compartan y modifiquen todo el software que les venga en gana, hoy conocemos este sistema como GNU.
Durante el desarrollo de GNU, Stallman usó otros programas libres y los adaptó a su sistema operativo. Ya en 1984 renunció a su trabajo en el Laboratorio de MIT y se dedicó al desarrollo de software para GNU. ¿Cómo sobrevivió? Pues con el paso del tiempo muchas personas se interesaron por el proyecto y los programas que Stallman estaba desarrollando. Específicamente el editor Emmacs fue «popular» entre programadores y Stallman decidió cobrar por enviar una copia del mismo para las personas que no tenían conexión a internet, las que tenían podían descargar gratuitamente el programa.
En 1985 ya eran muchas personas las que se involucraban con el desarrollo de GNU, así que decidieron una nueva estrategia para conseguir fondos: fundar la Free Software Foundation. Una organización sin ánimo de lucro que se dedique al desarrollo del Software Libre y haga valer las licencias para el mismo.
La principal fuente de ingresos para la FSF fue la venta de CDs con software libre y distribuciones completas de GNU, además de manuales detallados para aprender a usar sus programas. Hoy se mantiene con donaciones y una tienda de productos en su sitio web.
Según la FSF, para que un proyecto sea considerado3 Software Libre, necesita tener las cuatro libertades básicas:
Libertad 0. Libertad de ejecutar el programa como desees.
Libertad 1. Libertad de estudiar el código fuente del programa y realizar los cambios que desee el programador.
Libertad 2. Libertad de ayudar a tu programa. Crear copias exactas del programa y distribuirlas bien gratuitamente o con la libertad de vender tu desarrollo. Estas dos opciones están permitidas por la comunidad.
Libertad 3. Libertad para contribuir a tu Comunidad. Hacer copias de tus versiones modificadas y distribuirlas entre los demás.
Si analizamos artículos y escritos de Richard Stallman, veremos que se basa en lo ético y la moral para definir sus acciones. Hacen Software Libre porque no es correcto privar a otro usuario del conocimiento, así de sencillo.
Es común que una persona confunda al Software de Código Abierto con el Software Libre, es una diferencia sutil. Dos caminos que prácticamente llegan al mismo lugar.
En este artículo vamos a repasar la historia de la Open Source Initiative (OSI) para que conozcan su punto de vista sobre el Software. El próximo jueves escribiré un artículo con la historia de la Free Software Foundation (FSF) y sacaremos las diferencias del Software Libre y el Software de Código abierto u Open Source.
Open Source Initiative – OSI
Fundada conjuntamente por Eric Raymond y Bruce Perens en 1998, la OSI inicia con la misión de defender el uso de código abierto en los Estados Unidos, motivados por todo el movimiento que generó el kernel Linux al ser liberado y reconocido en todo el mundo, sumando, además, la liberación del navegador Netscape.
Inmediatamente se contó con el apoyo de grandes figuras en la informática, personas como: Linus Torvalds y los representantes de Perl, Python y Apache le dieron el visto bueno a la iniciativa.
La etiqueta de «código abierto» se creó en una conferencia celebrada el 3 de febrero de 1998 en Palo Alto, California. La junta estaba creciendo debido al impacto de la liberación del navegador Netscape, mucha gente vio la oportunidad de educar y trabajar para un futuro de desarrollo abierto.
Los miembros de dicha conferencia creían que las razones pragmáticas por las que Netscape liberó su código eran valiosas para interactuar con nuevos usuarios y desarrolladores, ofreciendo la perfección del software trabajando junto a una comunidad que se comprometa unicamente al desarrollo del programa.
Su punto de vista se centra en el desarrollo del software y los beneficios que, como usuario o desarrollador, puedes obtener liberando el código y trabajando libremente con otras personas. Para ellos resulta importante resaltar que el Open Source hace referencia a la eficiencia durante el desarrollo de software, por eso decidieron diferenciarse del termino «Software Libre», ya que este tiene un punto de vista más «filosófico» y «político».
La OSI fue concebida como una organización educativa y de defensa general con respecto al Open Source. En enero de 1999 participaron en una petición para que el gobierno de los Estados Unidos se pasara al código abierto.
Para que un programa sea considerado Open Source, debe cumplir con las siguientes normas (las he copiado exactas, omitiendo su justificación):
Redistribución gratuita: La licencia no debe restringir a ninguna parte de vender o regalar el software como un componente de una distribución agregada de software que contiene programas de varias fuentes diferentes. La licencia no requerirá un canon u otra tarifa por tal venta.
Código fuente: El programa debe incluir el código fuente. Cuando alguna forma de producto no se distribuye con el código fuente, debe haber un medio bien publicitado para obtener el código fuente por un costo de reproducción no superior a lo razonable, preferiblemente descargando a través de Internet sin cargo. El código fuente debe ser la forma preferida en que un programador modificará el programa. Código fuente deliberadamente ofuscado no está permitido. No se permiten formularios intermedios, como la salida de un preprocesador o un traductor.
Trabajos derivados: La licencia debe permitir modificaciones y trabajos derivados, y debe permitir que se distribuyan bajo los mismos términos que la licencia del software original.
Integridad del código fuente del autor: La licencia puede restringir la distribución del código fuente en forma modificada solo si la licencia permite la distribución de «archivos de parche» con el código fuente con el fin de modificar el programa en tiempo de compilación. La licencia debe permitir explícitamente la distribución de software creado a partir de código fuente modificado. La licencia puede requerir trabajos derivados para llevar un nombre o número de versión diferente del software original.
No discriminación contra personas o grupos: La licencia no debe discriminar a ninguna persona o grupo de personas.
No discriminación contra campos de esfuerzo: La licencia no debe restringir a nadie el uso del programa en un campo específico de esfuerzo. Por ejemplo, puede no restringir el uso del programa en un negocio, o ser utilizado para investigación genética.
Distribución de la licencia: Los derechos adjuntos al programa deben aplicarse a todos aquellos a los que se redistribuye el programa sin la necesidad de la ejecución de una licencia adicional por esas partes.
La licencia no debe ser específica de un producto: Los derechos adjuntos al programa no deben depender de que el programa sea parte de una distribución de software en particular. Si el programa se extrae de esa distribución y se usa o distribuye dentro de los términos de la licencia del programa, todas las partes a quienes se redistribuye el programa deben tener los mismos derechos que los otorgados junto con la distribución de software original.
La licencia no debe restringir otro software: La licencia no debe imponer restricciones sobre otro software que se distribuye junto con el software licenciado. Por ejemplo, la licencia no debe insistir en que todos los demás programas distribuidos en el mismo medio deben ser software de código abierto.
La licencia debe ser neutra desde el punto de vista tecnológico: Ninguna disposición de la licencia puede basarse en ninguna tecnología individual o estilo de interfaz.
A diferencia de las normas básicas en las que se basa la FSF (hablaré de ellas el jueves), el Open Source busca un orden para el Software de código abierto, así evitan conflictos y son claros con sus licencias. El próximo jueves sacamos conclusiones 😉 .
