Linux proporciona apoyo a diferentes lenguajes de programación y soporte excepcional para C, C + + y Java. Además, de ser libre de costo, también nos da la libertad de modificar, compartir y extender el IDE y otras herramientas! Así que si usted está interesado en la programación en Linux, aquí tenemos 21 libros gratuitos que pueden resultar útiles
Veo libros de hace muchos años, como 2002-2005 o anteriores. Por ejemplo, un libro Java de 2004 es muy antiguo.
Por ejemeplo, hay uno para hacer juegos de 2001, usando DSL, la libreria ha cambiado totalmente. Uno de seguridad de 2003, complemente inutil. Entorno KDE 2.0 año 2002, inutil. Lo mismo para Gnome en 1999, absolutamente inutil.
De los 21 quizas se salvan 2 o 3.
#14:
#1 Estos libros no parecen para "aprender a programar" sino para aquellos que ya saben programar y quieren aprender a hacerlo para Linux.
Si no tienes ningún conocimiento de programación te sugiero que empieces por Python o algo similar y en apenas un par de meses ya podrás dar el salto a aprender algún lenguaje de los "grandes" como Java o C (que requieren aprender muchas más normas y, dado que no exigen una buena organización, pueden ser muy caóticos para los principiantes).
Para practicar te recomiendo Project Euler, que es una web en la que los usuarios resuelven problemas matemáticos utilizando sus habilidades informáticas. Diría que los primeros 40 problemas son accesibles (no fáciles) para todo el mundo que tenga unas nociones básicas de programación en algún lenguaje.
Por último, existen cursos de programación en distintos lenguajes en sitios como Coursera o edX que empiezan casi desde cero y disponen de unos foros fantásticos para aprender junto a otras personas en tu mismo nivel... casi siempre en inglés, eso sí.
Al principio no compres ningún libro. YouTube y la red bastan, sobran y hasta son más efectivos para ir aprendiendo.
#7 Totalmente de acuerdo. Por lo menos nos olvidamos un poco de lo podrido que está el mundo.
Veo libros de hace muchos años, como 2002-2005 o anteriores. Por ejemplo, un libro Java de 2004 es muy antiguo.
Por ejemeplo, hay uno para hacer juegos de 2001, usando DSL, la libreria ha cambiado totalmente. Uno de seguridad de 2003, complemente inutil. Entorno KDE 2.0 año 2002, inutil. Lo mismo para Gnome en 1999, absolutamente inutil.
#21 Completamente de acuerdo. Sobre el de Gnome hay un par de capítulos que se salvan donde explican la librería glib (todavía en vigor) y las técnicas de programación orientada a objetos en C.
#1 Estos libros no parecen para "aprender a programar" sino para aquellos que ya saben programar y quieren aprender a hacerlo para Linux.
Si no tienes ningún conocimiento de programación te sugiero que empieces por Python o algo similar y en apenas un par de meses ya podrás dar el salto a aprender algún lenguaje de los "grandes" como Java o C (que requieren aprender muchas más normas y, dado que no exigen una buena organización, pueden ser muy caóticos para los principiantes).
Para practicar te recomiendo Project Euler, que es una web en la que los usuarios resuelven problemas matemáticos utilizando sus habilidades informáticas. Diría que los primeros 40 problemas son accesibles (no fáciles) para todo el mundo que tenga unas nociones básicas de programación en algún lenguaje.
Por último, existen cursos de programación en distintos lenguajes en sitios como Coursera o edX que empiezan casi desde cero y disponen de unos foros fantásticos para aprender junto a otras personas en tu mismo nivel... casi siempre en inglés, eso sí.
Al principio no compres ningún libro. YouTube y la red bastan, sobran y hasta son más efectivos para ir aprendiendo.
#7 Totalmente de acuerdo. Por lo menos nos olvidamos un poco de lo podrido que está el mundo.
#14 buenas, empecé a programar el año pasado haciendo un curso de Coursera sobre Python, y después otro de edX (este era bastante más jodido) de programación científica. Ahora uso bastante Python y sus librerías numpy, scipy y matplotlib, y me dan buenos resultados.
En tu comentario parece que Python es una especia de transición para usar luego uno de "los grandes". Por qué recomiendas aprender a usar uno de los otros lenguajes "grandes"?
Me apunto lo del project Euler,gracias!
#35 No no, Python no es una transición. Tiene valor por sí mismo, pero su uso está más extendido para poner a prueba rápidamente un algoritmo o alguna idea que se te haya ocurrido. Casi se podría decir que se usa para hacer scripts: leo datos, genero resultados a partir de ellos y el programa finaliza.
Se puede hacer de todo. Por ejemplo, se puede programar un navegador de internet en Python (creo que hay varios), pero lo normal sería programarlo en un lenguaje que permita generar unos archivos ejecutables (o binarios, en Linux) que funcionen sin necesidad de un intérprete.
Lo que está claro es que Python es muy fácil de aprender, en una semana puedes centrarte en entender las abstracciones de la programación orientada a objetos, mientras que con otros lenguajes te ves frenado por lo complicado de la gramática.
Por cierto, yo estoy haciendo este año los dos cursos que comentas (si el de Coursera es sobre programación interactiva). Aprendí Python hace un par de años, pero como sólo soy un aficionado todavía me queda mucho por descubrir.
#28 Me hace gracia que me lo expliques, como si yo nunca hubiese aprendido nada. Discrepo con tu método basándome en mi empirismo sobre haber aprendido a tocar la guitarra, a manejar Linux, a mecanografiar, a hablar inglés, etc, etc. Se aprende antes si primero lees o te lo explican y luego pruebas:
#34 El problema de poner "leer, pensar, preguntar" en primer lugar, es que hay personas que se conforman con "leer, pensar, preguntar"... y se olvidan del resto. Luego cuando llega la hora de hacer las cosas, de repente resulta que no han probado, ni errado, ni corregido sus errores, y se estampan a lo bestia.
Te lo explico porque tal vez no hayas conocido personas así, pero yo sí.
#37 Pero eso es una excepción, no la regla. En informática hay una norma universal muy aceptada que supongo que sabes: Unos minutos de leer el manual te ahorrarán horas de prueba y error.
#38 Esa norma es correcta en ambos casos, se empiece donde se empiece en el ciclo.
La diferencia está en que si empiezas por la prueba:
- Es posible que directamente no cometas ningún error, y te ahorras el resto del ciclo. Profit!
- Si cometes un error, sabes exactamente qué necesitas obtener de lo que vayas a leer/pensar/preguntar.
En cambio si empiezas por leer/pensar/preguntar:
- Lo estarás haciendo a ciegas, sin saber cuál es el error que necesitas solucionar, sin poder decidir qué parte de la lectura/idea/respuesta es relevante para el problema que vayas a tener (que todavía no has tenido), o cuál de las soluciones que encuentres -para distintos errores- va a ser la que necesites.
- Lo peor: no tendrás claro en qué momento dejar de leer/pensar/preguntar, y pasar a la prueba.
Personalmente, prefiero empezar por hacer una prueba (de forma controlada), cometer un error, y seguir el ciclo a partir de ahí.
#39 Pero eso no es siempre posible. Alguien que no haya visto una terminal en su vida, ni tenga experiencia con la informática no tendrá ni la más remota idea de qué es lo que puede hacer con ella. Necesitará informarse primero de qué es lo que hace, cuál es su forma de funcionar, qué instrucciones admite, y así podrá empezar a probar.
La mejor forma de aprender Linux, es usarlo. Y trastear. Y cagarla.
Una vez..
y otra vez...
y otra vez..
hasta que dejes de cagarla, o aprendas a no cagarla. Y hasta que funcione lo que se quiere hacer.
Y todo eso es un proceso que lleva y requiere años y horas y horas y horas. No se enseña en ningún libro (aunque la documentación no es tóxica, está claro).
#26 Una cosa es "no leer", otra diferente es "no probar y errar".
Si no haces pruebas y la cagas (léase: práctica), nunca sabrás para qué cojones sirve lo que estás leyendo... y no podrás extraer de ello las partes que te sirvan para evitar errar a la próxima.
El proceso correcto de aprendizaje es:
10 Probar
20 Errar
30 Leer / Pensar / Preguntar
50 GOTO 10
¿Donde está Understanding the Linux Kernel? Yo siempre lo he calificado como "El libro". Y es completamente útil para después empezar a programar device drivers.
Una pregunta que no tiene mucho que ver con el hilo, pero es que con mi navegador no puedo poner notas.
Estoy intentado instalar en un Sony Vaio nuevecito varias distros de Linux (OpenSuse, Kubuntu, Lubuntu, Mint, Elementary) y me fallan TODAS por lo mismo: error al final de la instalación, al intentar crear el GRUB. Al principio pensé que era fallo de creación del pen (instalo desde USB), pero grabé un par de CDs y me ocurrió lo mismo instalando desde disco.
El portátil tiene disco SSD, y el proceso de instalación no me reconoce que ya hay un windows instalado. Si le dejo al proceso hacer la instalación automática, me jode la partición windows y en lugar de crearme las tres particiones normales me crea como cinco o seis con nombres muy raros. Creo que el GParted se está haciendo un lío con mi SSD por alguna razón.
Tenéis alguna idea? O mejor aún, conocéis algún sitio que ofrezcan ayuda Linux en vivo, para poder preguntar con el cacharro delante? Algo así como IRC?
#18 y #19 el UEFI fue lo primero que quité, el disco duro arranca en legacy; y aún así el GParted me hace cosas muy raras con las particiones: crea cinco en lugar de tres, con nombres raros estilo dev/mount/jahdkjhaksjhkjhas
#15 Se llama BIOS UEFI, y por eso da problemas. Mirate algún manual de como instalar Linux con BIOS UEFI, y si no, en la misma BIOS del Vaio hay una opción de cambiar de UEFI a Legacy (vamos, la de toda la vida)
#15O mejor aún, conocéis algún sitio que ofrezcan ayuda Linux en vivo, para poder preguntar con el cacharro delante? Algo así como IRC?
Si te manejas con el inglés, te diría que probases en el IRC de freenode, donde hay muchos canales casi siempre con bastantes usuarios (como #linux o #ubuntu) y es probable que alguno te pueda echar un cable. http://freenode.net/
Comentarios
Existen recursos on-line que son mejores.
Veo libros de hace muchos años, como 2002-2005 o anteriores. Por ejemplo, un libro Java de 2004 es muy antiguo.
Por ejemeplo, hay uno para hacer juegos de 2001, usando DSL, la libreria ha cambiado totalmente. Uno de seguridad de 2003, complemente inutil. Entorno KDE 2.0 año 2002, inutil. Lo mismo para Gnome en 1999, absolutamente inutil.
De los 21 quizas se salvan 2 o 3.
#21 Completamente de acuerdo. Sobre el de Gnome hay un par de capítulos que se salvan donde explican la librería glib (todavía en vigor) y las técnicas de programación orientada a objetos en C.
Programación con GTK y KDE, año 1999/2000.
Yo me estaba plantteando aprender a programar, así que me viene de lujo este enlace.
Gracias.
#1 Estos libros no parecen para "aprender a programar" sino para aquellos que ya saben programar y quieren aprender a hacerlo para Linux.
Si no tienes ningún conocimiento de programación te sugiero que empieces por Python o algo similar y en apenas un par de meses ya podrás dar el salto a aprender algún lenguaje de los "grandes" como Java o C (que requieren aprender muchas más normas y, dado que no exigen una buena organización, pueden ser muy caóticos para los principiantes).
Para practicar te recomiendo Project Euler, que es una web en la que los usuarios resuelven problemas matemáticos utilizando sus habilidades informáticas. Diría que los primeros 40 problemas son accesibles (no fáciles) para todo el mundo que tenga unas nociones básicas de programación en algún lenguaje.
Por último, existen cursos de programación en distintos lenguajes en sitios como Coursera o edX que empiezan casi desde cero y disponen de unos foros fantásticos para aprender junto a otras personas en tu mismo nivel... casi siempre en inglés, eso sí.
Al principio no compres ningún libro. YouTube y la red bastan, sobran y hasta son más efectivos para ir aprendiendo.
#7 Totalmente de acuerdo. Por lo menos nos olvidamos un poco de lo podrido que está el mundo.
#14 buenas, empecé a programar el año pasado haciendo un curso de Coursera sobre Python, y después otro de edX (este era bastante más jodido) de programación científica. Ahora uso bastante Python y sus librerías numpy, scipy y matplotlib, y me dan buenos resultados.
En tu comentario parece que Python es una especia de transición para usar luego uno de "los grandes". Por qué recomiendas aprender a usar uno de los otros lenguajes "grandes"?
Me apunto lo del project Euler,gracias!
#35 No no, Python no es una transición. Tiene valor por sí mismo, pero su uso está más extendido para poner a prueba rápidamente un algoritmo o alguna idea que se te haya ocurrido. Casi se podría decir que se usa para hacer scripts: leo datos, genero resultados a partir de ellos y el programa finaliza.
Se puede hacer de todo. Por ejemplo, se puede programar un navegador de internet en Python (creo que hay varios), pero lo normal sería programarlo en un lenguaje que permita generar unos archivos ejecutables (o binarios, en Linux) que funcionen sin necesidad de un intérprete.
Lo que está claro es que Python es muy fácil de aprender, en una semana puedes centrarte en entender las abstracciones de la programación orientada a objetos, mientras que con otros lenguajes te ves frenado por lo complicado de la gramática.
Por cierto, yo estoy haciendo este año los dos cursos que comentas (si el de Coursera es sobre programación interactiva). Aprendí Python hace un par de años, pero como sólo soy un aficionado todavía me queda mucho por descubrir.
Lo importante es aprender.
Yo me lo he guardado en favoritos. Siempre que busco estos manuales encuentro basura. Estos tienen buena pinta
Llevaba tiempo buscando algo asi.
Gracias infinitas y con mucho amor
¿21?
Faltan el 7 y el 11.
¡Que me devuelvan el dinero!
#28 Me hace gracia que me lo expliques, como si yo nunca hubiese aprendido nada. Discrepo con tu método basándome en mi empirismo sobre haber aprendido a tocar la guitarra, a manejar Linux, a mecanografiar, a hablar inglés, etc, etc. Se aprende antes si primero lees o te lo explican y luego pruebas:
10 leer, pensar, preguntar
20 probar
30 errar
40 goto 10
#34 El problema de poner "leer, pensar, preguntar" en primer lugar, es que hay personas que se conforman con "leer, pensar, preguntar"... y se olvidan del resto. Luego cuando llega la hora de hacer las cosas, de repente resulta que no han probado, ni errado, ni corregido sus errores, y se estampan a lo bestia.
Te lo explico porque tal vez no hayas conocido personas así, pero yo sí.
#37 Pero eso es una excepción, no la regla. En informática hay una norma universal muy aceptada que supongo que sabes: Unos minutos de leer el manual te ahorrarán horas de prueba y error.
#38 Esa norma es correcta en ambos casos, se empiece donde se empiece en el ciclo.
La diferencia está en que si empiezas por la prueba:
- Es posible que directamente no cometas ningún error, y te ahorras el resto del ciclo. Profit!
- Si cometes un error, sabes exactamente qué necesitas obtener de lo que vayas a leer/pensar/preguntar.
En cambio si empiezas por leer/pensar/preguntar:
- Lo estarás haciendo a ciegas, sin saber cuál es el error que necesitas solucionar, sin poder decidir qué parte de la lectura/idea/respuesta es relevante para el problema que vayas a tener (que todavía no has tenido), o cuál de las soluciones que encuentres -para distintos errores- va a ser la que necesites.
- Lo peor: no tendrás claro en qué momento dejar de leer/pensar/preguntar, y pasar a la prueba.
Personalmente, prefiero empezar por hacer una prueba (de forma controlada), cometer un error, y seguir el ciclo a partir de ahí.
#39 Pero eso no es siempre posible. Alguien que no haya visto una terminal en su vida, ni tenga experiencia con la informática no tendrá ni la más remota idea de qué es lo que puede hacer con ella. Necesitará informarse primero de qué es lo que hace, cuál es su forma de funcionar, qué instrucciones admite, y así podrá empezar a probar.
Aquí http://resrc.io/list/10/list-of-free-programming-books/ hay un monton más, no son exclusivos de linux pero también hay de esté. En OpenLibra tamibén hay un monton más.
¿Solo 21?
Por favor, permítanme enseñarles un tesoro: http://resrc.io/list/10/list-of-free-programming-books/
Y su repositorio en GitHub: https://github.com/vhf/free-programming-books
Editado: Acabo de ver a #23, llego tarde.
Algunos meneos han nacido para estar en
Discoveryportada. Éste es uno de ellos.Cuando he leido costo gratis pensaba en otra cosa
Tenía que haber muchos más envíos de este tipo a Menéame.
La mejor forma de aprender Linux, es usarlo. Y trastear. Y cagarla.
Una vez..
y otra vez...
y otra vez..
hasta que dejes de cagarla, o aprendas a no cagarla. Y hasta que funcione lo que se quiere hacer.
Y todo eso es un proceso que lleva y requiere años y horas y horas y horas. No se enseña en ningún libro (aunque la documentación no es tóxica, está claro).
#11 Unas horas de prueba y error te ahorran unos minutos de leerte el manual .
#20 En cristiano: que eso de probar y errar es una cagada como una casa en la línea de aprendizaje.
#26 Una cosa es "no leer", otra diferente es "no probar y errar".
Si no haces pruebas y la cagas (léase: práctica), nunca sabrás para qué cojones sirve lo que estás leyendo... y no podrás extraer de ello las partes que te sirvan para evitar errar a la próxima.
El proceso correcto de aprendizaje es:
10 Probar
20 Errar
30 Leer / Pensar / Preguntar
50 GOTO 10
¿Donde está Understanding the Linux Kernel? Yo siempre lo he calificado como "El libro". Y es completamente útil para después empezar a programar device drivers.
Algunos demasiado antiguos, pero varios son muy interesantes y útiles.
Pues sí. Nunca viene mal tenerlos a mano.
Yo programo en Lazarus (IDE de freepascal)... y ya está...
Si quiero que eso que programo en Linux, funcione en Windows... solo tengo que coger el proyecto y compilarlo en un Windows... (asi de facil)
Si quiero pasarme a android/raspberry... lo compilo en ARM y ya está...
Ya no hay excusa, al que no le gusta el linux es porque no quiere mejorarlo y adaptarlo a lo que quiere.
A portada en menos de 3 minutos!!
Habrá que leerlo bien en cuanto haya tiempo
Una pregunta que no tiene mucho que ver con el hilo, pero es que con mi navegador no puedo poner notas.
Estoy intentado instalar en un Sony Vaio nuevecito varias distros de Linux (OpenSuse, Kubuntu, Lubuntu, Mint, Elementary) y me fallan TODAS por lo mismo: error al final de la instalación, al intentar crear el GRUB. Al principio pensé que era fallo de creación del pen (instalo desde USB), pero grabé un par de CDs y me ocurrió lo mismo instalando desde disco.
El portátil tiene disco SSD, y el proceso de instalación no me reconoce que ya hay un windows instalado. Si le dejo al proceso hacer la instalación automática, me jode la partición windows y en lugar de crearme las tres particiones normales me crea como cinco o seis con nombres muy raros. Creo que el GParted se está haciendo un lío con mi SSD por alguna razón.
Tenéis alguna idea? O mejor aún, conocéis algún sitio que ofrezcan ayuda Linux en vivo, para poder preguntar con el cacharro delante? Algo así como IRC?
Nota a #15: No es que quiera todas esas distros instaladas A LA VEZ; que me he expresado mal: he ido probando varias y ninguna funciona.
#15 A que te vino con Window 8 instalado? Si es así será su famoso gestor de arranque Secure Boot. Busca busca que te vas a divertir
#18 y #19 el UEFI fue lo primero que quité, el disco duro arranca en legacy; y aún así el GParted me hace cosas muy raras con las particiones: crea cinco en lugar de tres, con nombres raros estilo dev/mount/jahdkjhaksjhkjhas
#22 Gracias, lo apunto.
#15 Se llama BIOS UEFI, y por eso da problemas. Mirate algún manual de como instalar Linux con BIOS UEFI, y si no, en la misma BIOS del Vaio hay una opción de cambiar de UEFI a Legacy (vamos, la de toda la vida)
#15 O mejor aún, conocéis algún sitio que ofrezcan ayuda Linux en vivo, para poder preguntar con el cacharro delante? Algo así como IRC?
Si te manejas con el inglés, te diría que probases en el IRC de freenode, donde hay muchos canales casi siempre con bastantes usuarios (como #linux o #ubuntu) y es probable que alguno te pueda echar un cable. http://freenode.net/
#15 pues usa google
http://www.linux-on-laptops.com/sony.html
Y suerte, y casi seguro que debes quitar el secure boot en las bios para que se instale.
Muy bueno la verdad, muchas gracias por el aporte
Aunque no es tan importante, añadiría el libro sobre "Gambas", 'el VB de Linux'.
Sois raros