Menéame: comentarios [2128439]

#143 Gestión de ficheros en Linux para dummies

--122466-- — Sun, 30 Mar 2014 14:46:26 +0000

[Usuario deshabilitado]

» autor: --122466--

#142 Gestión de ficheros en Linux para dummies

Observer — Sun, 30 Mar 2014 14:05:07 +0000

#141
Nivelazo... llamado comúnmente level.
Me parece genial que alguien cree un manual de instrucciones para novatos, pero no hace falta dirigirse a ellos utilizando un estilo literario para retrasados. Creo yo.

Y no te critico por señalarlo, me reí un buen rato por tu comentario.

» autor: Observer

#141 Gestión de ficheros en Linux para dummies

--122466-- — Sun, 30 Mar 2014 14:02:13 +0000

[Usuario deshabilitado]

» autor: --122466--

#140 Gestión de ficheros en Linux para dummies

Observer — Sun, 30 Mar 2014 13:58:59 +0000

#139 si nos ponemos quisquillosos...
Que vamos, que aunque no está mal perfecto no es. Tiene unas cuantas cosas mejorables.

» autor: Observer

#139 Gestión de ficheros en Linux para dummies

--122466-- — Sun, 30 Mar 2014 13:56:06 +0000

[Usuario deshabilitado]

» autor: --122466--

#138 Gestión de ficheros en Linux para dummies

Observer — Sat, 29 Mar 2014 23:23:14 +0000

#56 Hombre, si nos ponemos quisquillosos...

Los tipos de ficheros
Creo que si incluimos en ficheros especiales todos los que no ha mencionado(enlaces simbólicos, tuberías y sockets) almenos los enlaces los debería haber mencionado.
Personalmente mas que "ordinary files" diría "regular files".

La nomenclatura de los ficheros
-En realidad no es gnu/linux quien limita la longitud del nombre de fichero, es el sistema de ficheros que utilices. Mayormente suelen ser de 255 pero algunos permiten nombres mas largos(Reiser4: 3976bytes) o mas cortos.
-La codificación utf8 pueden ocupar entre uno y cuatro bytes, por lo tanto un nombre puede quedar reducido a 63 caracteres(62 de 4 bytes y uno de un byte) en el peor de los casos. Esto podría desconcertar bastante a un novato.
-Algo que es útil conocer, algunos comandos admiten una opción "--" ignorando todo lo posterior que comience por "-", así puedes indicarle algo que comience por "-" sin que se queje de no reconocerlo la opción.

La jerarquía de ficheros
Le faltan algunos como /sys y /run(antes /var/run)
/proc: contiene cosas como los directorios de cada proceso que se está ejecutando en la maquina. Muchas de las cosas que estaban en proc ahora están en /sys
/sbin: mount está en /bin y es el que necesitarías para montar /usr (siempre que no necesites modprobe :P).
Podría haber basado la explicación en es.wikipedia.org/wiki/Filesystem_Hierarchy_Standard aunque la mayor parte de las distribuciones no siguen ese estándar.

» autor: Observer

#137 Gestión de ficheros en Linux para dummies

Observer — Sat, 29 Mar 2014 21:30:59 +0000

#103 Un binario lo puedes pasar en un fichero de texto, incluso pegarlo en un editor de texto que tienes abierto en la consola por ssh y guardarlo en la maquina remota.

Tan simple como codificarlo en base64 y luego decodificar el fichero en el equipo remoto.

Si no quieres que se suban binarios por seguridad al equipo remoto mejor montar el home, /tmp y /var/tmp sin permisos de ejecución y si con eso aún no te sientes seguro AppArmor, SELinux, TOMOYO, Yama, etc...

» autor: Observer

#136 Gestión de ficheros en Linux para dummies

--122466-- — Tue, 25 Mar 2014 21:33:58 +0000

[Usuario deshabilitado]

» autor: --122466--

#135 Gestión de ficheros en Linux para dummies

dotromas — Fri, 21 Mar 2014 15:51:45 +0000

#134 Ilustrame y me dices los editores mas usados por Administradores Profesionales UNIX/LInux incluso en Servidores sin interfaz grafica (para editar ficheros del sistema o escribir scripts). Me extrañaría que no esten Vim/Vi/Emacs entre los mas usados.

-"Basta con un editor cómodo en tu estación de trabajo que tienes delante y una conexión SSH al servidor que tienes administrar. Novecientas veces te lo he explicado ya, y sigues sin entender que ningún servidor se administra localmente."

Claro. Un administrador nunca edita ni programa en la maquina local, y tampoco edita en remoto.

- Sobre que no quitan Vi por motivos de "nostalgia" dejame que lo dude. Una cosa es que no lo quiten, y otra es que no añadan por defecto mas editores potentes y que incluso te lo exijan como temario para Certificarte de UNIX/linux. Digo yo que sera algo mas que "nostalgia".

-Vim puede dividirte la pantalla en muchas ventanas tanto vertical como horizontalmente sin tmux ni screen. Te recuerdo que Vim viene por defecto como el "Vi" de muchos Linux porque es compatible totalmente (pero con mas añadidos).

www.youtube.com/watch?v=sHGiC6Fp800 (un pequeño enlace por si no te lo crees). Prueba eso con otro editor tipo Eclipse o parecido y me dices el consumo de recursos que tiene.

- Sobre las herramientas de los 70 y tal, viene a que tu dices que no tienen nada que ver la forma de trabajar de los primeros UNIX a como se trabaja hoy dia con UNIX. Yo te digo que evidentemente se ha evolucionado, pero muchas cosas se hacen practicamente igual (sobre todo en modo texto y trabajo con comandos/scripts).

- C. Lenguaje mas usado sin tener en cuenta ni C++ ni objetive-c ni nada. El C de toda la vida: www.tiobe.com/index.php/content/paperinfo/tpci/index.html
Si, el que sirve para programar a bajo nivel (eso que tu dices que ya no se hace: programación de drivers, programación de sistemas y hardware, etc...).

- Aquí te paso una discusión para que veas las grandisimas diferencias que existen entre las primeras versiones de C y un Ansi-C mas actual: stackoverflow.com/questions/22500/what-are-the-major-differences-betwe
Vamos, es que alguien que sepa C seguro que no entiende las primeras versiones de C porque son "superdiferentes" en todo. Evidentemente han añadido cosas como ya te he comentado anteriormente, pero que me digas que no tienen nada que ver...

- Cobol? De eso no hay empleo!!!:
www.indeed.com/q-Cobol-jobs.html
www.dice.com/job/results/us/cobol?p=wk
www.careerbuilder.com/Jobs/Keyword/Cobol/
www.opcionempleo.com/empleo-cobol.html
www.infojobs.net/ofertas-trabajo/cobol
www.tecnoempleo.es/busqueda-empleo.php?te=Cobol
... te pongo mas? Bah, eso ya ni se usa.

- Sobre Intellij: has leido lo que te puse? No has visto que hay versión gratuita? Toma por si acaso: www.jetbrains.com/idea/download/

- ¿por que te pediran tanto saber Vi en todas las certificaciones UNIX?
accelitacademy.com/index.php/2012-11-28-05-45-44/acssa
www.amazon.com/Certified-System-Administrator-HP-UX-Administrators/dp/
pinakinetworks.com/redhat/
.... no lo entiendo. Que poco profesionales.

- De fortran no hemos hablado, porque es un lenguaje mucho mas antiguo que C y es normal que hayan cambiado mas cosas (añadidos). Posiblemente el C del 2050 sera mucho mas diferente del C de los 70/80 también.

- Sobre Lisp, se ve que no te has leido bien los enlaces que te puse. Los actuales lenguajes siguen cogiendo cosas que Lisp tenia inventadas hace milenios e incluso estan intentando ser mas "funcionales" o permitir ese tipo de programación. Mirate bien de nuevo esos enlaces y luego hablamos. Solo te doy una pista de una caracteristica que tenia Lisp desde el principio y ahora es una moda en muchos lenguajes: "lambda".

De todas formas no hay lenguajes que puedan programarse a si mismos y otro monton de paranoias que si permite Lisp incluso en tiempo de ejecución (bueno Ensamblador si), en parte gracias a esas expresiones/sintaxis con "esos parentesis" que tu criticabas.

» autor: dotromas

#134 Gestión de ficheros en Linux para dummies

--122466-- — Thu, 20 Mar 2014 20:05:56 +0000

[Usuario deshabilitado]

» autor: --122466--

#133 Gestión de ficheros en Linux para dummies

dotromas — Thu, 20 Mar 2014 13:12:38 +0000

#132 Viendo que eres un analfabeto informatico que se las da de "Profesional" y "Guru" (que no eres mas que un bocazas), te voy a dar tu enesima lección con enlaces y pruebas de tus meteduras de pata:

- Primero de todo: De Vim, noooo! si aquí no hemos hablado de Vim! Pero es que me da igual, porque los motivos por los que criticas a Vi también los tienes en Vim.

- Siguiendo con Vi/Vim: Todo el mundo sabe que los administradores profesionales escriben sus scripts de shell y editan sus ficheros de configuración con Eclipse o Intellij por lo menos. Es lo mas rapido y eficiente. Ademas siempre estan disponibles y claro, como no existen servidores donde no tengan instalado las X, pues con mas motivo para tener esos editores tan livianos. Vi, eso no lo usa nadie (y vim tampoco), sobretodo "profesionales" como tu. Yo es que no se como no lo han quitado ya de todos los Unix por defecto (y hasta de los temarios de las Certificaciones). ¡La gente esta loca! Miles de locos...

- Hablamos también de Vim que es un editor muy similar en todo a Vi y que viene por defecto en muchos sistemas Linux. Sobre lo de dividir la pantalla para editar 2 ficheros al mismo tiempo es algo que Vim hace de 1000 maneras. Ademas tienes Tmux o Screen para ayudar a Vi.

- De la arquitectura de Unix y programación de bajo nivel mejor no hablamos porque me parece que no tienes ni idea.

- Las herramientas cutres de los 70's estas usandolas cada vez que programas un script de shell, usas comandos por consola como grep, find, etc... y cambias permisos de usuarios en un UNIX. Si, esas cutres herramientas que nadie usa como una shell.

- Chato, el que no se entera eres tu. Para empezar C no va en ninguna dirección hacia la programación orientada a objetos. C es el lenguaje mas usado actualmente (si, por encima de Java o a iguales dependiendo del año que miremos las estadisticas). Aunque no lo creas todavia se programan muchas cosas a bajo nivel. Por cierto, ¿me quieres exponer el gran cambio de paradigma y de uso del lenguaje que ha tenido C entre las versiones primeras y el C99 por ejemplo? Lo mismo es un nuevo lenguaje y todo. en.wikipedia.org/wiki/C_programming_language

Yo te dije que evidentemente se han incorporado mejoras en las nuevas revisiones, pero el lenguaje sigue siendo practicamente igual (paradigma imperativo, palabras clave basicas, instrucciones de control, ...). Hombre pues claro que se le han añadido cosas, no te jode.

- Evidentemente de lenguajes de programación sabes bien poquito. Lisp: lenguaje muy antiguo que tiene caracteristicas que nadie esta copiando como por ejemplo las expresiones lambda. Tampoco tiene recolector de basura desde hace decadas, ni implemento recursividad, ni macros, ni era el primer lenguaje multiparadigma (cosa de moda actualmente), etc.
Te paso un par de enlaces para que aprendas un poco y luego no me digas mentiras:
paulgraham.es/ensayos/lo-que-hizo-diferente-a-lisp.html
paulgraham.es/ensayos/las-raices-de-lisp.html

Como veras, Lisp tiene aún hoy día caracteristicas con las que sueñan otros lenguajes y que quizás el unico lenguaje que puede implementarlas es Ensamblador.

De Lisp han cogido muchas caracteristicas los actuales lenguajes de moda (java, python, ruby, etc). Es mas, incluso tienes nuevos lenguajes tipo Lisp: CLOJURE.

Informate un poquito antes de hablar. El paradigma funcional esta cada vez usandose mas en programación e incluso los lenguajes que no son funcionales intentan meter caracteristicas que les permitan programar (aunque de forma limitada) siguiendo la programación funcional.

- ¿Que te he dicho yo de Cobol? Pues esto: "Hay tienes Cobol que sigue haciendo muy bien su trabajo y no merece la pena ser sustituido por otros lenguajes." ¿Es mentira? Mirate las ofertas de trabajo para programadores Cobol y mirate las estadisticas de la cantidad de sitios que siguen usando sus programas Cobol de hace años. Y no van a cambiar porque Cobol hace muy bien lo que hace, aunque tengan que parchear el codigo mil veces. Cobol esta desfasado, pero se sigue usando porque es muy bueno en lo que hace, no solo porque sea caro programar de nuevo los sistemas en otros lenguajes (que también es otro motivo, pero no el unico).

- Si a ti te gusta estar aprendiendo un nuevo editor cada poco tiempo, pues haya tu. Yo prefiero conocer uno bien y despues si es necesario pues usar otro que sea imprescindible o me lo exijan para mi trabajo (pero conocer uno en el que puedo hacer de todo para mi es fundamental. En mi caso Emacs, pero podria decirte tambien Vim).

- Me sigues comparando Vi con Notepad. No hay color, al igual que no se puede comparar Nano con Vi, porque aunque nano sea mas sencillo, Vi es mas potente en la edición de textos.

- No sabia yo que para hablar de software había que pagarlo. ¿Sabes tu si yo he comprado o no Intellij? Además te recuerdo que tiene una versión demo e incluso una versión gratuita (aunque limitada en caracteristicas).

En resumen, que hayan incorporado mas caracteristicas a herramientas o lenguajes, no significa que hoy día no sigamos usando muchas herramientas/lenguajes de hace muchos años e incluso de manera muy similar (lenguajes como C, Fortran, ensamblador, Lisp, consolas de texto UNIX, editores "arcaicos" como Vi/Emacs, etc...).

» autor: dotromas

#132 Gestión de ficheros en Linux para dummies

--122466-- — Mon, 17 Mar 2014 21:18:40 +0000

[Usuario deshabilitado]

» autor: --122466--

#131 Gestión de ficheros en Linux para dummies

dotromas — Mon, 17 Mar 2014 18:57:28 +0000

#130 No he confundido nada. Te he puesto un simil que al parecer no has entendido muy bien. Evidentemente Vim no es igual que el Vi original de los 70. Del mismo modo, los sistemas Unix actuales han evolucionado de las primeras versiones. Te dije que no "han cambiado demasiado" y sobretodo en su forma de administrarlos o usarlos (quitemos el entorno X de momento). Solo tienes que estudiar como eran las primeras shells, los permisos, la estructura interna del nucleo (arquitectura) que existian en las versiones de finales de los 70 y primeros 80.

Sobre el lenguaje C, pues mas de lo mismo. ¿Crees que ha cambiado mucho en su sintaxis, en sus palabras reservadas, en su paradigma de programación? Entonces es que no sabes nada de C. ¿has leido la primera versión del libro de Kernighan y Ritchie? ¿hay mucha diferencia con el C actual? Evidentemente el estandar ha ido evolucionando con nuevas revisiones o versiones incorporando nuevas caracteristicas, pero de eso a que me digas mentiroso por decierte que no han evolucionado tanto...

Y me comparas las consolas. Las consolas si es visible que han evolucionado muchisimo en todos los aspectos (graficos, sonido, lenguajes de programación usados, sistemas operativos, interfaces, juego en red, etc etc etc). Si programas en C de las primeras versiones no varia mucho de como lo programas con las versiones de hoy día.

Si usas algún Unix en consola o shell actual, es muy similar en muchos comandos, en salida por pantalla de información, en permisos de usuarios, en que todo o casi todo es representado con ficheros, en que los comandos o programas pueden redireccionar sus entradas/salidas, etc...

Creo que podriamos ver un paralelismo de evolución igual al que existe entre el Vi original y el Vim actual. Ha evolucionado, pero siguen pareciendo similares a simple vista.

Sobre lo que dices de agarrarse a las tecnologias actuales no lo comparto al 100% contigo, es mas, ni tu lo haces al 100% seguramente. Las tecnologias actuales son como las modas, por ejemplo para administracion de sistemas hoy tienes Puppet que esta muy bien (antes se usaban otros), pero quien te dice a ti que en 2 años no tienes otro que lo sustituye, y luego otro y otro y otro.... Sin embargo si sabes lo rudimentario y las bases (si, eso de los 70 y 80 sobre administración UNIX y programación de shell scripts), seguramente podrás hacer muchas cosas sin necesidad de esas herramientas de ultima moda que no siempre son necesarias y a su vez entenderas o estaras mas preparado para adaptarte a otras que vengan nuevas. En los editores de texto (no IDE's solamente), tu puedes estar usando alguno que ahora este de moda o lleve usandose pocos años y luego sale otro y te ves obligado a dejar de usar ese por "estar a lo ultimo". En IDE's, teniamos Eclipse o Netbeans para Java (entre otros lenguajes) y luego aparece Intellij-IDEA que es la caña para Java. Ahora en pocos años y despues de estar muy agusto y acostumbrado a Intellij te viene otro que dice mejorarlo, pues vuelta a empezar (keystrokes, menus-opciones, posibilidades nuevas, etc...). O eso o usar 100 editores distintos (uno para ficheros scripts, otro para C++, otro para Java, otro para Latex, otro para ....). Teniendo cosas como Emacs o Vim o incluso Sublime Text que puede ser un coñazo de aprender, pero que los puedes usar para todo en conjunto con otras herramientas y no tendras que aprender un IDE nuevo para cada tarea o "el IDE de moda". Ademas que tampoco vas a usar un Eclipse para editar cualquier configuración o un script shell (y tampoco vas a usar un Notepad o un Nano que son bastante limitados como editores).

A lo que vamos es que lo "viejo" no tiene porque ser malo o "no profesional". Hay tienes C que sigue siendo un lenguaje muy muy usado en muchos ambitos. Hay tienes Cobol que sigue haciendo muy bien su trabajo y no merece la pena ser sustituido por otros lenguajes. Hay tienes Lisp del que ahora muchos lenguajes quieren copiar o copian caracteristicas.

Y mira si los sistemas tipo UNIX que todavía tienen a Vi como editor por defecto

» autor: dotromas

#130 Gestión de ficheros en Linux para dummies

--122466-- — Mon, 17 Mar 2014 15:58:00 +0000

[Usuario deshabilitado]

» autor: --122466--

#129 Gestión de ficheros en Linux para dummies

dotromas — Mon, 17 Mar 2014 12:35:35 +0000

#128 Por esas mismas (y mucho mas en entornos "profesionales"), nadie usaria sistemas UNIX. Nadie usaria consolas de texto ni scripts. Nadie usaria el lenguaje C. Todo eso es de los 70 y no ha cambiado demasiado.

Y según tu, ¿que es necesario para ser "profesional" y avanzar en el ambito de la Administración de Sistemas?

» autor: dotromas

#128 Gestión de ficheros en Linux para dummies

--122466-- — Mon, 17 Mar 2014 11:16:18 +0000

[Usuario deshabilitado]

» autor: --122466--

#127 Gestión de ficheros en Linux para dummies

dotromas — Sat, 15 Mar 2014 12:47:08 +0000

#126 Ya paso de discutir mas. Te paso enlaces.

es.wikipedia.org/wiki/Nodo_sin_disco

www.youtube.com/watch?v=pCiVCiku3cM

www.youtube.com/watch?v=lQNFfhC4QI8

www.youtube.com/watch?v=_galFWwSDt0

www.youtube.com/watch?v=FcpQ7koECgk&list=PLV0pP05crphdU21Wa3hP3O2R

Te podria poner muchos mas que demuestran que Vim es bastante potente cuando se sabe usar.

» autor: dotromas

#126 Gestión de ficheros en Linux para dummies

--122466-- — Fri, 14 Mar 2014 16:45:23 +0000

[Usuario deshabilitado]

» autor: --122466--

#125 Gestión de ficheros en Linux para dummies

--122466-- — Fri, 14 Mar 2014 16:31:22 +0000

[Usuario deshabilitado]

» autor: --122466--

#124 Gestión de ficheros en Linux para dummies

dotromas — Fri, 14 Mar 2014 10:25:25 +0000

#123 claro! Los documentos Rfc nunca han especificado protocolos reales y usables hoy dia!
Vi y vim tienen combinaciones de teclas que en otros editores suponen muchas pulsaciones.

Si, debe ser que nunca he usado un terminal X en red conectado a un servidor Solaris.

El grupo de 2000 y pico frikis que te puse son todos analfabetos al lado de un gurú de la programación y sysadmin como tú.

Nada más que decir. Alguién tan prepotente, mentiroso y liante como tú es mejor darte la razón como a los locos, no vaya a ser que te pongas malo y todo. Ah! También pitoniso porque sabes que han estudiado y que trabaja todo el mundo que no coincide en tus gustos (como todos los frikis que usan vim o vi).

» autor: dotromas

#123 Gestión de ficheros en Linux para dummies

--122466-- — Wed, 12 Mar 2014 21:42:19 +0000

[Usuario deshabilitado]

» autor: --122466--

#122 Gestión de ficheros en Linux para dummies

dotromas — Wed, 12 Mar 2014 17:32:08 +0000

#121 Mira, ya es que me aburres y me haces perder el tiempo. No sabes ni lo que es un protocolo. Según tu, en la capa de aplicación no existen protocolos, no? Has mirado la arquitectura del protocolo SSH? buff, dejalo...

Sobre los comandos, siempre has supuesto que nos conectamos al remoto para administrarlo (podría ser para otras cosas). Acaso sabes lo que son las llamadas al sistema? Como se programa un editor? Según tu, un editor usa directamente el comando "cat" y "cp", jajajaja. Acaso yo no puedo usar programas sin tener que usar "cat" o "cp"? has visto las limitaciones de rbash?

Lo del hardware dejalo, esta visto que no tienes imaginación.

Sobre la latencia editando en remoto, si, va igual de bien un editor que otro que te permite con combinaciones de pocas teclas hacer tareas que necesitarias muchisimas combinaciones en otros editores. Según tu un editor como Vi/vim se vería afectado por la latencia del mismo modo que otro mas "bonito y facil" y se editaría igual de rapido (o lento). Jeje tendre que probar de nuevo.

Ya se que esos terminales se usan en una red interna, pero es una red, no? Y como estas editando los ficheros que hay en el servidor? ahhhhh!!! Vaya, un ejemplo de edición remota que no puedes grabar en local para editar porque pueden no disponer de dispositivos de almacenamiento.

Yo he dicho que Linkedin sea todo profesionalidad? Te he puesto un enlace de un grupo de mas de 2000 usuarios de Linkedin que usan y contribuyen a Vim. Has leido los curriculums de algunos de esos "frikis"??? Pues eso, que Vim solo lo usan los frikis sin estudios y sin puta idea de Informatica. Es que tu debes ser el unico que ha estudiado Informatica y que tiene la suficiente "caché" para poder decir quien es friki (según tu todos menos tu) y quien es profesional (tu solo). Seguro que eres tan hipocrita de criticar Linkedin y tener tu propia cuenta para fines profesionales.

Y me pones 4 enlaces de gilipolleces de Linkedin. Es como si yo te digo que todo el que tiene un Blog es gilipollas porque hay blogs que hablan de tonterías. Esa es la lógica que me usas para todo.

Menudo Troll estas hecho. Quieres dar lecciones "maestro" y no llegas a "bedel".

» autor: dotromas

#121 Gestión de ficheros en Linux para dummies

--122466-- — Wed, 12 Mar 2014 14:57:43 +0000

[Usuario deshabilitado]

» autor: --122466--

#120 Gestión de ficheros en Linux para dummies

dotromas — Tue, 11 Mar 2014 23:28:46 +0000

#119 Es que disfrutas dandole la vuelta a la tortilla y liando al personal. Menudo Troll estas hecho.

Voy a enumerar los parrafos para no liarte mucho:

1) SSH. De tu comentario anterior: "SSH no es ningún protocolo, borrico, deja de decir estupideces y demostrar que no tienes ni puta idea de nada.".

El que no tiene ni puta idea eres tu. SSH usa un protocolo de igual nombre, ergo SSH es un protocolo. Te dejo un enlace a la Wikipedia para que te culturices un poco (es en Ingles, si no sabes ingles ya te paso otro enlace para que lo entiendas mejor): en.wikipedia.org/wiki/Secure_Shell

Con solo la primera linea de la definición es suficiente para darte cuenta de que no tienes ni puñetera idea (generalizo como a ti te gusta...).

Como veo que eres tu el que no tiene idea de redes ni de protocolos, aquí te dejo un enlace al RFC de SSH para que te lo estudies que falta te hace: tools.ietf.org/html/rfc4253

Jeje, luego soy yo el que dice burradas...

Por cierto, ¿quien ha dicho de capar los "programas que leen ficheros"? Sabes leer? Sabes lo que es un editor? Conoces las limitaciones de rbash? Sabes lo que es borrar "scp"? Sabes lo que es limitar "ciertos comandos"?

2) Los discos duros con protección de escritura por hardware. Si tu crees que por telepatia se puede oprimir un boton fisico para activar o desactivar la protección de esos discos, pues yo que tu patentaba el sistema...
Si no eres capaz de verle utilidad a un sistema de protección de solo lectura (por hardware) siempre que no se necesite hacer algun tipo de actualización o modificación en las particiones que están en ese disco, es que tienes poca idea de lo que es un rootkit a nivel de aplicación, o incluso un troyano o una puerta trasera. Y no me vale que montas las particiones en solo lectura y todo eso... Hay una diferencia grande de protección.

3) La latencia. Si tu crees que es lo mismo de rapido editar en remoto con Vi/Vim, que con otros editores mas sobrecargados pues haya tu. Es lo mismo de rapido que yo pulse 4 combinaciones de teclas en Vi/Vim que me hacen 18 cosas que con otros editores me puedo esperar que refresquen pantallas o ventanas, que muevan el cursor lentamente o borren trozos de texto lentamente. Si crees que los problemas de latencia se verán igual y afectaran a tu edición remota de la misma manera con Vi/Vim que con otros editores instalados en el servidor remoto, pues te invito de nuevo a que lo pruebes para ver que editor te resulta mas rapido para modificar un fichero remoto.

Y sobre lo de que nadie edita en remoto es falso. Quitando el supuesto que ya te puse sobre que alguien limitara ssh para transferir ficheros, ¿como coño editas ficheros remotos por medio de "terminales dumb" conectados a un servidor? No me vale RAM ni otros recursos limitados o inexistentes.

4) Sobre que Vi/Vim no lo usan los profesionales. Ya te he puesto ejemplos de libros, videos, chats, etc. Hoy te dejo un enlace que he buscado para que te leas a lo que se dedican los miembros del grupo/foro y me digas si son 4 frikis (empieza por el creador del grupo mirando su perfil). Esta es una de las cientos de paginas que podría buscarte pero que ya paso:

www.linkedin.com/groups/Vim-154653 (... anda!!! 4 frikis que no son ni profesionales se dedican a usar y comentar sus frikadas en Linkedin. Seguro que se estan pajeando en sus dormitorios!!!).

Los otros editores que te puse, te los puse como ejemplo de editores que copian muchas cosas de Vi/Vim/Emacs y son también muy usados actualmente (combinaciones de teclas, extensibilidad, minimalismo y poco consumo de recursos, etc). Ejemplo SublimeText.

» autor: dotromas

#119 Gestión de ficheros en Linux para dummies

--122466-- — Tue, 11 Mar 2014 16:20:14 +0000

[Usuario deshabilitado]

» autor: --122466--

#118 Gestión de ficheros en Linux para dummies

dotromas — Mon, 10 Mar 2014 20:37:33 +0000

#117 Y soy yo el que no tiene ni puta idea!!! VAmos vamos. Vamos por partes.

Segun tu, solo pueden tener acceso remoto los administradores. No pueden acceder otro tipo de usuarios para realizar otro tipo de tareas que no sean precisamente la transferencia de ficheros. No se puede entrar para realizar un script o un programa que necesite mucha potencia de calculo y sea mas rapido ejecutarlo en ese ordenador. No se puede entrar para dejar ejecutandose o compilando unos programas. No se puede entrar para editar ficheros de directorios permitidos, etc etc etc. Que pocas ideas tienes, no?

Mi segundo parrafo va sobre como tu te negaste a admitir que se podia limitar o prohibir la transferencia de ficheros con ssh por el simple hecho de tener instalado ssh (y de usar su maravilloso protocolo). Pues te invito a que hagas unas pruebas para ver si te lo permite.

El ejemplo que he puesto de los discos duros con proteccion fisica no estaba diciendo de que sea para uso en remoto (aunque /home /var etc puedan tener permisos de escritura y asi poder hacer ciertas cosas, no solo administrar). El ejemplo por si no has leido bien, es para un administrador en local (quien coño va a apagar el sistema en remoto y va a darle al boton de proteccion de los discos duros por telepatia...). Además, veo que no tienes ni puta idea del ejemplo que te he comentado sobre los discos duros. /proc, jeje. ¿Quien coño hace una particion para /proc que no esta en disco? Se protege el directorio "/" que estara en una particion (al igual que se puede tener otra para /usr /boot tambien protegidas, y solo dejar /home /var /tmp con acceso de escritura). Pruebalo hombre, te invito a que lo pruebes. Lo mismo te llevas una sorpresa y arranca y todo. Si no tienes acceso a discos duros con proteccion hardware, puedes pillarte un pendrive USB de esos que tenian boton de proteccion para escritura y te instalas hay tu sistema con varias particiones y luego lo proteges. Anda, ya has aprendido hoy algo nuevo que te puede ser muy util. Lo mismo te sorprende que haya sitios donde hacen cosas parecidas... /proc dices, jeje. Sabes lo que es /proc, lo que contiene y donde se almacena???

Sobre la latencia, la edicion en remoto y todo eso, vengo diciendotelo hace tiempo. Que no entiendas bien las cosas no es culpa mia. Lo que pasa es que cuesta dar la razón, verdad?

Si tu sigue a lo tuyo. Que Vi/Vim no lo usa ningun profesional de la programación o de la administración de sistemas. Otro dia con mas tiempo te busco unos cuantos y a ver que me dices. Y Emacs también es para 4 frikis y no lo usa nadie, verdad? Te pongo ahora a Emacs porque es un editor superantiguo, muy friki, muy extenso y complejo, y con combinaciones de teclas muy dificultosas (cosas que también comparte con Vi/Vim). Y si nos vamos a la actualidad, Sublime TExt es para 4 frikis tambien, Textmate otro por el estilo, y así un largo etc, de editores que son bastante parecidos a la forma de editar de (vi/vim o emacs).

» autor: dotromas

#117 Gestión de ficheros en Linux para dummies

--122466-- — Mon, 10 Mar 2014 18:41:46 +0000

[Usuario deshabilitado]

» autor: --122466--

#116 Gestión de ficheros en Linux para dummies

dotromas — Mon, 10 Mar 2014 17:28:02 +0000

#115 Para empezar, eso te gustaria a ti, que no tuviese ni papa de Unix/Linux. Esta claro que lo unico que sabes hacer es insultar para rebatir mis argumentos. Es el unico recurso que usas. Se te ve muy profesional si, miedo me daría tener un empleado como tu.

Como eres cortito de memoria, aquí te pongo literalmente lo que me dices en unos comentarios mas atrás para defender tu postura de que teniendo acceso ssh no se puede limitar la transferencia de ficheros: "¿No entiendes que lo que dices es una gilipollez ignorante? No limitas una mierda borrando el binario SCP ni puedes limitar su funcionalidad de ninguna manera, entérate ya.".

Limitar un sistema para que no se puedan transferir ficheros no creo que sea una limitación tan grande como tu la pintas. Se pueden hacer muchas cosas con un sistema en el que no se permite la transferencia de ficheros. Parece mentira que entiendas tanto. Yo puedo tener acceso ssh a un servidor de una empresa para gestionar o editar mil cosas sin tener que transferir ningun fichero.

Visto esta que no sabes entender los ejemplos que te pongo. Lo de los discos duros con protección hardware para escritura no tiene nada que ver con lo del ssh. Lo he puesto como ejemplo de hacer una misma función de diferentes formas y de algo que tampoco es habitual verlo en servidores (al igual que el ejemplo del ssh y scp), pero que puede ser muy útil de cara a proteger la seguridad de un sistema (ya que ni siquiera el superusuario podría por ejemplo sobreescribir ningún fichero de las particiones protegidas por hardware. Por supuesto no todas: /var /home /tmp no estarían con esa protección), y solo en el caso de actualizaciones se podría iniciar con los discos permitiendo escritura con el switch hardware. No se si podrás entenderlo...

Jeje, tu mismo has explicado en tus 2 ultimos parrafos lo que llevo diciendote desde hace no se cuanto. "SI EDITAS REMOTAMENTE...", tan dificil es de entender. Y si editas remotamente y existen problemas de latencia, va igual de bien (o mal) un Vi/Vim que otro editor mas sobrecargado (como el ejemplo que te he puesto con los juegos)???? Ahhhh, menos mal que ya vas entendiendo. Y para colmo me dices de editar en local (cosa que claro que va mejor que si es en remoto), pero que igualmente te vuelvo a repetir el supuesto de un servidor donde no se te permite la transferencia de ficheros y solo puedes conectarte y editar remotamente ya sean scripts u otros ficheros (si, ya me has repetido que no es lo habitual).

Sobre Vi/Vim, tienes libros de Vi/Vim varios de la editorial O'reilly, tienes programadores metidos en el desarrollo de Vim y sus plugins, tienes multitud de editores que copian o simulan su comportamiento o keystrokes, tienes cientos de videos sobre su funcionamiento/ejemplos/charlas, tienes blogs/news/chats, etc etc etc. ¿De verdad crees que un editor de mierda y solo para 4 frikis tendría tanta gente detras y tantos recursos tratando sobre este?

» autor: dotromas

#115 Gestión de ficheros en Linux para dummies

--122466-- — Mon, 10 Mar 2014 15:44:46 +0000

[Usuario deshabilitado]

» autor: --122466--

#114 Gestión de ficheros en Linux para dummies

dotromas — Mon, 10 Mar 2014 13:22:00 +0000

#113 Pero que cerrado de mollera eres! Como se ve que ademas de ser administrador del Datacenter de Google eres también su CEO, ya mismo te tengo que pedir permiso hasta para hablar.

Yo te he puesto un supuesto de un servidor donde se quiere limitar la transferencia de ficheros y solo permitir algunas operaciones locales (como editar algunos ficheros/scripts). Me da igual que se limite con permisos, con ssh o con lo que sea. Tu me has dicho que no se podia limitar y yo te he puesto ejemplos de que si se puede limitar ssh para las transferencias de ficheros. No te estoy poniendo supuestos de ciencia ficción (aunque se que no es lo habitual).

Es lo mismo que yo puedo limitar el acceso a mis particiones que pueden ser para / /usr /boot ..., con protección contra escritura por medio del sistema operativo o también podría usar discos con proteccion contra escritura por hardware mediante un switch, y se que tampoco todo el mundo lo usa.

Que no sea lo habitual no quiere decir que no pueda existir algún caso o varios. Te pasa lo mismo con Vi/Vim. Te niegas a reconocer que son usados por muchos profesionales de la administración o de la programación.

Te voy a poner otro ejemplo sobre la latencia para ver si lo entiendes mejor:
Según tu, existiendo problemas de latencia para una determinada conexión, van igual de bien (o de mal), jugar a un juego de red como Call of Duty (por ejemplo), que jugar a otro como por ejemplo el hundir la flota en red. Yo pienso que un juego como Call of Duty se vera mucho mas afectado por los problemas de latencia de la conexion, ya que tiene que enviar mas información de un extremo al otro y de forma mas frecuente.

No soy una "eminencia" como tu, pero creo que es de logica y sentido comun que un editor como Vi/Vim transfiere mucha menos información que otros editores mas sofisticados/sobrecargados.

Y por ultimo, te vuelvo a decir que el sentirte que eres una "eminencia" no te hace saberlo todo de un tema. En ningun momento te he dicho que sea lo mejor o lo mas practico tener un servidor con estas caracteristicas o que usar Vi/Vim sea lo mejor del mundo (te vuelvo a repetir por enesima vez que no suelo usar Vi/Vim y prefiero otros), pero no soy tan prepotente como tu de negar la realidad y decir que ningun profesional usa Vi/Vim. Tampoco miento y digo que no hay manera de limitar ssh para enviar ficheros (con todo su "santo" protocolo).

» autor: dotromas

#113 Gestión de ficheros en Linux para dummies

--122466-- — Mon, 10 Mar 2014 11:33:17 +0000

[Usuario deshabilitado]

» autor: --122466--

#112 Gestión de ficheros en Linux para dummies

ann_pe — Thu, 06 Mar 2014 13:23:52 +0000

#43 Se pueden hacer bastantes cosas con shell scripting, por ejemplo zomg usa zsh, con bash+zenity también hay un montón de programitas.

packages.debian.org/wheezy/zomg

» autor: ann_pe

#111 Gestión de ficheros en Linux para dummies

dotromas — Wed, 05 Mar 2014 02:04:43 +0000

#110 Pues ya me gustaría ver como coño pasas con cp por ssh tus ficheros si en el server tienes instalado rbash y te limitan los comandos a usar en ssh con authorized_keys.

Sobre la latencia, digo yo que si usas un editor mas sobrecargado que tenga que enviar mas información hasta tu ordenador local afectara mas los problemas de latencia que puedan existir que si usas un editor que transmite muy poca información.

Sigues negando que Vi/Vim lo usen profesionales (nunca he dicho que sea lo mas usado ni que sea usado por muchisimos, pero si es usado por profesionales), lo dicho, tienes información de sobra en Internet y libros enteros dedicados a Vim/Vi (por algo sera). Cuantos libros conoces del Notepad???

Ningun Unix tiene Vim, pero si muchos Linux por defecto (ya te lo he dicho anteriormente). Si, en las certificaciones de Microsoft para administrador te meten el "Notepad" igual que en las de Unix/linux meten Vi, verdad?

Por ultimo nunca he dicho que lo mejor sea usar Vim/vi para todo o que todos los administradores lo usen o cosas así. Solo he defendido que son editores que estan en todos los Unix/LInux, que son potentes, que ocupan y consumen muy poco y que sirven para programar o para administrar un sistema. Te he puesto ejemplos sobre servidores muy limitados, te he puesto ejemplos de uso en terminales tontos, VPN's lentas, etc, donde tienen ventaja sobre otros editores mas sobrecargados (sitios donde no puedes obtener una copia en local y donde afecta el ancho de banda, los posibles problemas de latencia, etc).

Que tu te dediques a la administracion de sistemas no quiere decir que los que no nos dediquemos seamos unos ignorantes que no tenemos ni puta idea de UNIX/linux ni de administración de sistemas. Habra cosas que no sepamos, al igual que habra muchas que tu no tendras ni puta idea. Algo he estudiado y algo he trabajado con estos temas (claro que según tu se es ignorante en estos temas si no se conocen las entrañas y protocolo de ssh o si se usa Vi/Vim).

» autor: dotromas

#110 Gestión de ficheros en Linux para dummies

--122466-- — Tue, 04 Mar 2014 23:55:02 +0000

[Usuario deshabilitado]

» autor: --122466--

#109 Gestión de ficheros en Linux para dummies

Rik_Rides — Tue, 04 Mar 2014 12:29:27 +0000

si, es bastante parecido #3

» autor: Rik_Rides

#108 Gestión de ficheros en Linux para dummies

dotromas — Tue, 04 Mar 2014 11:37:22 +0000

#107 Ignorante demustras ser tu cuando dices que el ancho de banda no es un recurso. Yo no me dedico a la administracion de sistemas (no quiere decir que nunca haya ejercido esa función), pero eso no te hace a ti tampoco ser "el sysadmin de Google DataCenter" o poco menos. Te he hablado de un supuesto donde en algún servidor se puede desear tener acceso a una shell remota via ssh pero sin permitir transmitir ficheros. También te he dicho anteriormente que si se puede usar un pipe para transmitir un fichero de texto (con cat por ejemplo), pero desconocia si se puede redireccionar un binario de otra manera que no sea usando scp,sftp, sshfs o similares. Tu que eres un experto en ssh me dices que puedes usar "cp", vale, pues lo desconocia que pudiese transferir ficheros binarios de esa forma. Visto que aún sigues sin leer bien, te pongo textualmente el momento en que te hablaba mucho mas atras sobre "limitar permisos" ademas de borrar "scp": en el comentario #94 "...y tambien podria estar limitado el uso de scp en el servidor remoto simplemente no existiendo el ejecutable scp o usando algunos permisos que lo restrinjan...". Así que el que inventa eres tu.

No soy tan tonto para pensar que esto que planteo es algo habitual, estamos hablando de supuestos casos.

De todas formas la discusión gira en que tu te niegas a admitir que haya profesionales actualmente que usan vi/vim para programar, y ya te puse ejemplos de programadores profesionales que usan vi/vim e incluso dan charlas sobre ello. Te podría aburrir poniendote ejemplos y enlaces, pero no me apetece.

Y finalmente, veo que te niegas a admitir que usar vi/vim son utiles si te conectas a un servidor y tienes que editar ficheros/scripts en este y no puedes en local (sabiendo que es un editor potente y ligero, que no tendrás tantos problemas de latencia como con otros editores mas sobrecargados como Emacs y tampoco sera tan limitado como un nano). Todo esto suponiendo que no puedes descargar esos ficheros a tu ordenador local de ninguna forma o que sea mas lento el que cada vez que grabas una modificacion para probar tu programa/script tengas que esperar a "scp" (o incluso podriamos poner el ejemplo de usar terminales tontas donde te conectas al servidor para editar o programar y donde no podras grabar en tu terminal local y tendras que tener en cuenta los problemas de red).

p.d. Como ya te dije en otros comentarios, yo no suelo usar Vi/Vim, nunca he dicho que sea el mejor editor e incluso te he dicho que prefiero Emacs, pero eso no me hace ser un tarugo como tu y decir rotundamente que vi/vim son una mierda y que no son usados por profesionales hoy día en programacion o administración de sistemas. Supongo que los programadores que hacen Vim tienen que ser unos ignorantes y gilipollas en comparación a ti, porque mira que seguir desarrollando y mejorando un software que no sirve y que no usa nadie (al igual que cuando Google contrato al responsable de Vim). Quizas todo el mundo UNIX este equivocado en tener todavía Vi/Vim instalado por defecto como unico editor en sus instalaciones basicas (deberias proponerles tu algo a la gente de Linux, Solaris, BSD, etc...). También deberías hablar con toda la gente que prepara las certificaciones para que quiten del temario a Vi y que pongan otro editor para administrar los sistemas basicos.

» autor: dotromas

#107 Gestión de ficheros en Linux para dummies

--122466-- — Tue, 04 Mar 2014 10:23:00 +0000

[Usuario deshabilitado]

» autor: --122466--

#106 Gestión de ficheros en Linux para dummies

--153590-- — Tue, 04 Mar 2014 07:30:38 +0000

#99 Vuelvo a repetir una vez más, siempre será más fácil escribir una línea y pulsar enter. Además, sin pagar licencias. Porque tú la pagarás, claro.

» autor: --153590--

#105 Gestión de ficheros en Linux para dummies

dotromas — Mon, 03 Mar 2014 20:12:42 +0000

#104 Como te gusta descalificar! Como veo que eres tu el "limitado" y que no sabes leer ni comprender, te "ilustro" un poco.

Por si no lo sabes (y visto que no sabes leer/comprender bien), ¿cuando te he dicho yo que scp no venga con ssh? Te he dicho que se puede borrar el binario (¿sabes lo que es un fichero binario?) scp del sistema (dejando el sistema sin tu querido 'scp'). Si has leido bien (cosa que dudo), te he puesto que solo usando ssh (sin 'scp' porque se borre del sistema) se puede pasar ficheros de texto mediante pipes (usando cat por ejemplo), pero ficheros binarios yo no los he podido pasar sin usar 'scp' o 'ftp' o 'sshfs' o algo que se te ocurra (solo ssh sin scp). Te lo puse como ejemplo de un servidor donde quieran prohibir la transferencia de ficheros binarios, que pueden ser grandes y limitar el ancho de banda (algo que según tu no son recursos).

Lo de la latencia (si sabes leer) te lo puse por si usabas otros editores mas sofisticados que Vi/Vim para editar en remoto (es de cajón que editando en local no te afecta la latencia).

Te he hablado varias veces de Vi/Vim. Para empezar yo uso solo Linux y normalmente te viene Vim como editor por defecto. Pero me da igual, los 2 son muy similares (principal diferencia es que Vim es extensible), pero te vuelvo a decir que su forma de trabajar y su interfaz es practicamente identica (escritores modales). De todas maneras me da igual, el editor Vi se sigue usando por muchos programadores profesionales de Unix y se ha usado para crear programas durante muchos por muchos profesionales del mundo UNIX. Pero si a mi me sugerian hacer practicas de Sistemas Operativos con Vi (y no solo scripts-shells, sino programacion con semaforos, hebras y procesos).

Los enlaces que te he puesto son los primeros que he visto de Vim. Tienes articulos, videos, foros, grupos de noticias, chats, etc, para hartarte de ver ejemplos de uso profesional y actual sobre este editor (Vi/Vim). Pero tu a lo tuyo...

Si tu lo dices..., seguramente nunca he abierto un libro en toda la carrera (lastima que no hubiese ereaders hace unos años).

» autor: dotromas

#104 Gestión de ficheros en Linux para dummies

--122466-- — Mon, 03 Mar 2014 19:24:11 +0000

[Usuario deshabilitado]

» autor: --122466--

#103 Gestión de ficheros en Linux para dummies

dotromas — Mon, 03 Mar 2014 17:39:18 +0000

#97 Te vuelvo a decir que alguien puede querer tener en un servidor basico un acceso ssh, pero no permitir 'scp' para evitar descargar ficheros binarios por ejemplo (de texto se podrian bajar sin scp con un pipe y cat/ssh).

El ancho de banda es un recurso limitado (aunque solo sea por un tiempo, pero es un recurso). Si no es así tendré que tirar algún que otro libro de la carrera o lo mismo eso lo han modificado actualmente. También tendras que tener en cuenta la latencia (suponiendo que uses otro editor mas sofisticado para editar en remoto, no?). No siempre se dispondrá de una ancho de banda y latencia del copón (puede que tengas que conectarte con una lenta VPN o vete tu a saber).

Yo te he hablado de Vi/Vim (Vim viene por defecto en muchos Linux por ejemplo como equivalente o sustituto de Vi). Se diferencian principalmente en que Vim es extensible y no me vas a convencer de que los profesionales no usan Vi/Vim para programar (ya sean shell-scripts, paginas web u otras aplicaciones mas sofisticadas). Que a ti te guste hacer scripts en Visual studio o Eclipse despues de bajartelos con "scp" y luego volver a copiarlos al servidor, no quiere decir que no haya profesionales que sean mas eficientes y productivos simplemente creando el script en remoto con un editor que es potente (aunque sea dificil de manejar al principio).

Lo dicho, que no haya muchos profesionales que siguen usando Vi/Vim es falso.
Buscando solo un poquito sobre programadores con conferencia incluida que usan Vi/Vim en youtube por ejemplo (y actualmente):

www.youtube.com/watch?v=SkdrYWhh-8s
www.youtube.com/watch?v=YhqsjUUHj6g
www.youtube.com/watch?v=p6K4iIMlouI

Y podriamos buscar muchisimos mas enlaces.
Yo prefiero Emacs, pero no puedo decir que no haya profesionales que usen Vi/Vim y tampoco que no sean buenos esos editores (Claro Vim mejor que Vi, pero son muy parecidos por lo menos en el interfaz y en su manejo).

» autor: dotromas

#102 Gestión de ficheros en Linux para dummies

--414833-- — Mon, 03 Mar 2014 17:29:15 +0000

#100 Tu pagas tu cuota mensual de photoshop? Seguro que no. Qué facil es hablar siendo un pirata.

» autor: --414833--

#101 Gestión de ficheros en Linux para dummies

Mister_Lala — Mon, 03 Mar 2014 17:16:32 +0000

#19 Chaval, yo me crié en los tiempos del ms-dos 5.0, cuando la competencia de microsoft era el dr-dos. Me vas a enseñar tú a mí lo que es una línea de comandos. Que teníamos que comprimir con el ARJ, por favor...

» autor: Mister_Lala

#100 Gestión de ficheros en Linux para dummies

Mister_Lala — Mon, 03 Mar 2014 17:14:16 +0000

#25 ¿En linux tenéis photoshop?

» autor: Mister_Lala

#99 Gestión de ficheros en Linux para dummies

Mister_Lala — Mon, 03 Mar 2014 17:13:36 +0000

#25 Muy fácil: ordenas por tamaño, y dejas caer las que tengan más de 1 Mb sobre una acción de photoshop que haga el resize.

» autor: Mister_Lala

#98 Gestión de ficheros en Linux para dummies

Mister_Lala — Mon, 03 Mar 2014 17:08:55 +0000

#95 ¿Por qué los usuarios de linux os lo tomáis tan a pecho? Ni que lo hubieseis parido vosotros...

» autor: Mister_Lala

#97 Gestión de ficheros en Linux para dummies

--122466-- — Mon, 03 Mar 2014 16:24:50 +0000

[Usuario deshabilitado]

» autor: --122466--

#96 Gestión de ficheros en Linux para dummies

dotromas — Mon, 03 Mar 2014 15:23:17 +0000

#95 Jeje, y luego dicen que Linux es dificil! he visto errores y fallos en Windows tan cripticos y con soluciones tan rebuscadas que no las sabe ni el primo de Billy Puertas.

» autor: dotromas

#95 Gestión de ficheros en Linux para dummies

neuralgya — Mon, 03 Mar 2014 15:13:21 +0000

#4 Lo más gracioso es que vosotros que os reís, acabáis haciendo un ejecutar->cmd->ipconfig /all para ver las IP de vuestro Windows, por que ir a verla en el "centro de redes y de recursos compartidos" son 10 clicks de ratón.

Y más gracioso todavía, es que para solucionar los problemas chungos de los Windows, haya que acabar usando su mierda de consola. Hoy me ha tocado este. support.microsoft.com/kb/975484/es.

» autor: neuralgya

#94 Gestión de ficheros en Linux para dummies

dotromas — Mon, 03 Mar 2014 13:28:30 +0000

#88 Hombre pues lo mismo no es usar scp que ssh y editar el fichero en remoto. Gasto de recursos y tambien podria estar limitado el uso de scp en el servidor remoto simplemente no existiendo el ejecutable scp o usando algunos permisos que lo restrinjan o cosas así (con SELinux u otras movidas).

Lo de que no hay programadores que usen Vim o Emacs es totalmente falso. Hay muchisimos. Solo tienes que ver la gente implicada en los 2 proyectos o la cantidad de plugins o extensiones que tienen disponibles y siguen sacando.
Si la gente no programara con ellos, para que sacarian extensiones para tantos lenguajes de programación y utiles para facilitar la programacion? ¿por que serian tan extensibles?

También puedes mirar los foros/chats/blogs que existen sobre ellos (o videos de youtube por ejemplo).

» autor: dotromas

#93 Gestión de ficheros en Linux para dummies

--153590-- — Mon, 03 Mar 2014 12:56:11 +0000

#92 Los informáticos es que somos así, preferimos molestarnos una sola vez para que las siguientes trabaje nuestro ordenador, en lugar de nosotros. Así, mientras el ordenador trabaja podemos irnos a tomar un café.

» autor: --153590--

#92 Gestión de ficheros en Linux para dummies

zULu — Mon, 03 Mar 2014 12:52:29 +0000

#91 Claro, lo que pasa es que muchos se ofuscan intentando saber qué escribir en esa línea

» autor: zULu

#91 Gestión de ficheros en Linux para dummies

--153590-- — Mon, 03 Mar 2014 12:14:57 +0000

#90 Ni lo dudo ni lo dudé en ningún momento. Lo que decía y mantengo es que siempre será más fácil escribir una línea y pulsar enter.

» autor: --153590--

#90 Gestión de ficheros en Linux para dummies

zULu — Mon, 03 Mar 2014 12:10:18 +0000

#80 #79 Yo hablaba de windows, lo he hecho varias veces usando XNView, tiene una utilidad estupenda (o tenía, hace años que no lo uso), para hacer justamente eso
Soy prolinux y command line, soy mucho más de teclado que de ratón, pero reitero, que hay mil utilidades para hacer resize con ratón

» autor: zULu

#89 Gestión de ficheros en Linux para dummies

ASMoises — Mon, 03 Mar 2014 11:55:25 +0000

#51 Claro, pero yo lo que quería era mantener Windows+Linux igual que tenía en el otro

» autor: ASMoises

#88 Gestión de ficheros en Linux para dummies

--122466-- — Mon, 03 Mar 2014 11:53:09 +0000

[Usuario deshabilitado]

» autor: --122466--

#87 Gestión de ficheros en Linux para dummies

--414804-- — Mon, 03 Mar 2014 09:40:37 +0000

Noticia sobre Linux, EXCLUSIVAMENTE sobre Linux; y termináis, como siempre y sin venir a cuento, mentando a Windows. Tenéis que hacéroslo mirar, Linuxeros.

» autor: --414804--

#86 Gestión de ficheros en Linux para dummies

Thae — Mon, 03 Mar 2014 09:19:19 +0000

Ya funciona la web

» autor: Thae

#85 Gestión de ficheros en Linux para dummies

Thae — Mon, 03 Mar 2014 08:54:35 +0000

Me puesto en contacto con el dueño y me a dicho que los duelos del hosting le an jodido, creo que esta mirando otros hostings.. pero de esto ultimo no estoy seguro.
Efecto meneame

» autor: Thae

#84 Gestión de ficheros en Linux para dummies

dotromas — Mon, 03 Mar 2014 08:02:55 +0000

#82 creo que no aparecen tampoco /sys y /srv

» autor: dotromas

#83 Gestión de ficheros en Linux para dummies

pirado04 — Mon, 03 Mar 2014 07:39:29 +0000

#47 GRACIAS! Ya lo pude ver.

» autor: pirado04

#82 Gestión de ficheros en Linux para dummies

listuam — Mon, 03 Mar 2014 07:19:25 +0000

#50 the /run directory
Fedora 15 has a /run directory for storing runtime data. /run is now a tmpfs, and /var/run is bind mounted to it. /var/lock is bind mounted to /run/lock. Applications can use /run the same way as /var/run. Several programs including udev, dracut, mdadm, mount and initscripts used hidden directories under /dev for runtime data during early bootup before /var is mounted. However /dev/ is supposed to be used for only device nodes and there is consensus between major distributions to shift to using /run instead. Fedora 15 is leading this change. Details including the benefits are explained here.lists.fedoraproject.org/pipermail/devel/2011-March/150031.html
This change is compliant with the Filesystem Hierarchy Standard, which allows distributions to create new directories in the root hierarchy as long as there is careful consideration of the consequences. Co-author of the latest FHS specification has expressed support for this change. Lennart Poettering has filed a request to update the FHS standard to include this change as well.

» autor: listuam

#81 Gestión de ficheros en Linux para dummies

Aokromes — Mon, 03 Mar 2014 05:58:25 +0000

#61 no fue Windows 2012, fue Windows 2008.

» autor: Aokromes

#80 Gestión de ficheros en Linux para dummies

--153590-- — Mon, 03 Mar 2014 05:30:20 +0000

#74 De hecho vamos a nombrar a Linux y a OSX, porque el ejemplo es extensible a ellos. ¿Cómo huevos vas a redimensionar todas las imagenes de más de 1Mb repartidas a lo largo y ancho de tu disco duro a 1024x768 a base de clicks en Linux? Podrían tildarte de majadero si lo intentases.

» autor: --153590--

#79 Gestión de ficheros en Linux para dummies

--153590-- — Mon, 03 Mar 2014 05:23:34 +0000

#74 Si tienes una compleja estructura de directorios y los archivos son cientos de miles, ¿de verdad podrías realizarlo a base de clicks en un tiempo razonable? Cuidado, no estoy metiendome con Windows, estoy metiendome con lo que no es la linea de comandos. El ejemplo que puse nombro precísamente a Windows. En Windows con robocopy se realiza con una línea y pulsar enter. Con clicks te llevaría décadas.

Ah, que te refieres al otro ejemplo. Pues bien, ¿cómo harías en Windows con clicks, que en un directorio que contiene más de 1000 fotografías en formato JPG se redimensionasen sólo las que ocupan más de 1Mb a 1024x768? Y volvemos a lo mismo, imaginad un directorio que contiene muchos subdirectorios. Osea, las fotos están repartidas por muchos directorios, no sólo uno.

Y no, no me estoy metiendo con Windows, ¿qué somos críos?, me estoy metiendo con los que piensan que en 2014 una línea de comandos está fuera de lugar.

» autor: --153590--

#78 Gestión de ficheros en Linux para dummies

dotromas — Mon, 03 Mar 2014 02:01:04 +0000

#76 Y si tienes que instalar un sistema con los justo, que vas a meter "Visual Studio"? Y si tienes que conectarte en remoto por ssh a un sistema Unix para administrarlo y que no han instalado servidor X que usas para editar o por lo menos que editor sabes seguro que allí estara instalado???

Estamos de acuerdo que Vi es limitado (aunque mucho mas potente que otros editores que vienen por defecto con la mayoria de sistemas operativos). Pero por ejemplo Vim se sigue usando mucho mucho para programar tambien. Digo yo que por algo sera no? Aunque a mi me gusta mas Emacs, pero Vim sigue siendo bueno para muchas cosas. Vas a negar tambien que existe ahora una moda de crear editores imitando a Vim/Emacs como por ejemplo Sublime Text o LightTable editor??? por que sera???

» autor: dotromas

#77 Gestión de ficheros en Linux para dummies

--125581-- — Mon, 03 Mar 2014 01:46:09 +0000

#76 "Vengo con vi aprendido posiblemente desde antes de que nacieras, no te preocupes"

A no ser que usases UNIX en el 85, lo dudo

"Pero pudiendo elegir, no voy a trabajar con mierdas habiendo herramientas mucho mejores y mucho más productivas. "

Oye, pues enhorabuena, pero no todos los entornos tienen esa apertura a la hora de configuración e instalación de añadidos. Y no, no hablamos para programar si no para administrar.

» autor: --125581--

#76 Gestión de ficheros en Linux para dummies

--122466-- — Mon, 03 Mar 2014 01:43:36 +0000

[Usuario deshabilitado]

» autor: --122466--

#75 Gestión de ficheros en Linux para dummies

dotromas — Mon, 03 Mar 2014 01:29:00 +0000

#73 Esa es la principal ventaja de vi, que esta en todos sitios (tipo Unix). Es muy ligerito y es productivo cuando le pillas las combinaciones de teclas y tal.

» autor: dotromas

#74 Gestión de ficheros en Linux para dummies

zULu — Mon, 03 Mar 2014 01:21:45 +0000

#25 Mal ejemplo, en windows puede hacerse sin comandos. Y eso que me encanta usar shell, pero este...mal ejemplo!!

» autor: zULu

#73 Gestión de ficheros en Linux para dummies

--125581-- — Mon, 03 Mar 2014 01:03:05 +0000

#72 En admon de sistemas Linux te lo piden, no van a meter herramientas en el servidor por la cara.

Tienes vi, la versión reducida, no vim.

» autor: --125581--

#72 Gestión de ficheros en Linux para dummies

dotromas — Mon, 03 Mar 2014 01:02:32 +0000

#70 Aunque parezca que no, mucha gente usa actualmente Vi/Vim para programar o editar ficheros (en entornos Windows no creo).

» autor: dotromas

#71 Gestión de ficheros en Linux para dummies

--125581-- — Mon, 03 Mar 2014 00:59:00 +0000

#70 "Espero no encontrarme jamás con un sistema mantenido por ti. Menudo "pofesioná", incapaz de ver más allá de tu jefe y hacer lo que debes. "

Si tu jefe sabe más que tú y te pide que no instales nada encima y uses VI, te jodes. Y fin.

Sobre todo en según que entornos no te dejarán usar vim. Ni nada mejor. Si lo pides puede que te lo acepten, pero lo normal es... si sabes Linux/BSD vente con vi aprendido de casa para editar la configuración del servidor, en el cual no se mete nada nuevo.

» autor: --125581--

#70 Gestión de ficheros en Linux para dummies

--122466-- — Mon, 03 Mar 2014 00:41:21 +0000

[Usuario deshabilitado]

» autor: --122466--

#69 Gestión de ficheros en Linux para dummies

picholeiro — Mon, 03 Mar 2014 00:22:53 +0000

#68 Por eso soy un usuario firme del software libre, intentado utilizar lo maximo posible . otra cosa es cuando no tenga mas obligación que utilizar windows

» autor: picholeiro

#68 Gestión de ficheros en Linux para dummies

dotromas — Mon, 03 Mar 2014 00:19:02 +0000

#65 Pero ya quisiera tener la estructura y jerarquia de ficheros/directorios que tiene UNIX. Y si encima le sumas la cagada del Registro Windows ya apaga y vamonos.

» autor: dotromas

#67 Gestión de ficheros en Linux para dummies

noises — Mon, 03 Mar 2014 00:16:41 +0000

#0 Efecto Meneame? "Este alojamiento está suspendido. Si usted es el dueño y piensa que es un error póngase en contacto con soporte DNsystem."

» autor: noises

#66 Gestión de ficheros en Linux para dummies

--125581-- — Mon, 03 Mar 2014 00:16:26 +0000

#62 "Pues lo mismo ha sucedido desde siempre con la basura de "shell" de línea de comandos que trae, cualquiera que necesite usar la línea de comandos usa uno mejor. "

No. Por mucho que llores, en una empresa no te dejarán usar Cygwin o MSYS a la primera

Y mira que a mí me gustaría para trabajar en un entorno conocido frente a cmd.exe o psh donde todo tiene una sintaxis ultralarga y poco eficiente , pero...

» autor: --125581--

#65 Gestión de ficheros en Linux para dummies

picholeiro — Mon, 03 Mar 2014 00:14:38 +0000

#61 Que windowsa se quiere parecer mas a unix lo tengo por descontato ya lo vi ciando salio el vista que ya incorporaban una carpeta llamada boot y también la separación de las respectivas carpetas el a raíz , como la de user

» autor: picholeiro

#64 Gestión de ficheros en Linux para dummies

--125581-- — Mon, 03 Mar 2014 00:13:44 +0000

#62 Vamos a ver, los estándares son los estándares.

En una empresa, el producto que te ofrecen de serie todos los UNIX es vi, por mucho que vim sea la hostia o emacs sea la gloria reencarnada.

La utilidad estandard para crear scripts en MS era cmd.exe y ahora powershell, todos los demás productos eran "foráneos" y por lo tanto no aplicables a un entorno homogéneo y estandarizado.

Es como si para el LPI de Linux te piden ZSH en vez de Bash. Que sí, que ZSH es la caña, pero como no viene de serie, no te lo vas a encontrar ahí fuera.

Por eso te exigen conocimientos de vi y no nano. No te van a dejar instalar la primera herramienta que encuentren.

» autor: --125581--

#63 Gestión de ficheros en Linux para dummies

Sandevil — Mon, 03 Mar 2014 00:11:35 +0000

#54 Personalmente, la mayor diferencia que suelo encontrar, es que windows se preocupa mas por los asistentes que por los programas en si.
Hasta el punto de limitar los programas a lo que los asistentes permitan, aunque sea contraproducente.

» autor: Sandevil

#62 Gestión de ficheros en Linux para dummies

--122466-- — Mon, 03 Mar 2014 00:10:39 +0000

[Usuario deshabilitado]

» autor: --122466--

#61 Gestión de ficheros en Linux para dummies

dotromas — Mon, 03 Mar 2014 00:04:07 +0000

#57 Microsoft en su version Server principalmente cada vez quiere ser mas "Unix" o copia sus ideas: Una shell mas buena que cmd.exe -> powershell, posibilidad de arranque del sistema sin entorno grafico (creo que a partir de la version Windows Server 2012), sistema de ficheros ReFS copiando muchas cosas de ZFS, etc etc etc...

Pero para copiar lo mas importante necesitan crear Windows desde 0.

» autor: dotromas

#60 Gestión de ficheros en Linux para dummies

picholeiro — Sun, 02 Mar 2014 23:55:32 +0000

#58 Yo puse reinventa ya que no pueden adactar lo que ya tiene sino poner uno

» autor: picholeiro

#59 Gestión de ficheros en Linux para dummies

--125581-- — Sun, 02 Mar 2014 23:46:36 +0000

#58 Leñe, y si meto ZSH seguro que da mil vueltas al KSH que uso, y ya con Ipython ni te digo. Pero lo importante es lo que viene por defecto.

cmd.exe vs Bash. Es que no hay color.

» autor: --125581--

#58 Gestión de ficheros en Linux para dummies

--122466-- — Sun, 02 Mar 2014 23:45:18 +0000

[Usuario deshabilitado]

» autor: --122466--

#57 Gestión de ficheros en Linux para dummies

picholeiro — Sun, 02 Mar 2014 23:36:18 +0000

#4 Por eso Microsoft se reinventa con el es.wikipedia.org/wiki/Windows_PowerShell cuando es el siatema de ventanas que se puede hacer todo que reinventa una cosas que la tenian

» autor: picholeiro

#56 Gestión de ficheros en Linux para dummies

--122466-- — Sun, 02 Mar 2014 23:32:46 +0000

[Usuario deshabilitado]

» autor: --122466--

#55 Gestión de ficheros en Linux para dummies

eqas — Sun, 02 Mar 2014 23:11:13 +0000

#51 Yo lo hago así!!! Muy bien!!!

» autor: eqas

#54 Gestión de ficheros en Linux para dummies

xuco — Sun, 02 Mar 2014 23:04:41 +0000

Llevo una semana en un curso de Solaris. Vengo del mundo de mocosoft y tengo que reconocer que ha sido una semana muuuyyyy larga.

Pero todos los conceptos comentados en el artículo ya están más o menos asimilados y debo decir que cada vez me va gustando más Linux/Unix.

Lo único malo es que ahora soy consciente de cual largo va a ser el camino hasta que me pueda considerar un "experto". Tantos años administrando guidows y de que poquito vale aquí esa experiencia. Que pena....

» autor: xuco

#53 Gestión de ficheros en Linux para dummies

cossier — Sun, 02 Mar 2014 22:54:32 +0000

#48 #52 A lo mejor es el efecto meneame !!

» autor: cossier

#52 Gestión de ficheros en Linux para dummies

juan01ky — Sun, 02 Mar 2014 22:46:28 +0000

Por cierto una pena que la página este suspendida.

» autor: juan01ky

#51 Gestión de ficheros en Linux para dummies

juan01ky — Sun, 02 Mar 2014 22:45:12 +0000

#49 Una idea.
Si me pasa a mi, que me pasará cuando compre otro portátil.
Es un poco drástico pero es lo que haré.
Saca el disco duro, pones otro distinto y procedes a la instalación de lo que quieras.
Si te arrepientes, cambias el disco otra vez.
Con esto puedes probar con linux.
Saludos

» autor: juan01ky

#50 Gestión de ficheros en Linux para dummies

kyle — Sun, 02 Mar 2014 22:42:34 +0000

#10 y load ""

» autor: kyle

#49 Gestión de ficheros en Linux para dummies

ASMoises — Sun, 02 Mar 2014 22:35:32 +0000

Cada vez que sale alguna noticia de Linux últimamente me da muchísima rabia, porque tengo portátil nuevo con el maldito Windows 8, y no me atrevo a instalar ninguna distro, y ahora ya me había acostumbrado a Linux.

Uno de los principales motivos es que no sé si será posible reinstalar y activar Windows desde la partición de recuperación si está desactivado todo el tema del SecureBoot, y por Internet no he encontrado nada.

A modo de offtopic, alguien puede ayudarme?

» autor: ASMoises

#48 Gestión de ficheros en Linux para dummies

cossier — Sun, 02 Mar 2014 22:27:21 +0000

Ahora mismo la página está suspendida !!

» autor: cossier

#47 Gestión de ficheros en Linux para dummies

siverio — Sun, 02 Mar 2014 22:05:10 +0000

#0 #1 #16 #18 #24 #29 Versión de la página en caché de Google mientras está caída:
webcache.googleusercontent.com/search?q=cache:http://ovtoaster.com/ges

» autor: siverio

#46 Gestión de ficheros en Linux para dummies

cnicolas — Sun, 02 Mar 2014 21:58:40 +0000

#2 En realidad los sistemas Apple derivan de los sistemas tipo BSD como por ejemplo Freebsd, son bastante parecidos a Linux pero no exactamente iguales al 100%.

» autor: cnicolas

#45 Gestión de ficheros en Linux para dummies

Venturi_Debian — Sun, 02 Mar 2014 21:43:19 +0000

A ver, el terminal no es para novatos, más bien para intermedio-avanzado, para novatos se quedan en un ls y cd y mkdir rm y poco más... Los comentarios de terminal en 2014, sinceramente espero que sigan hasta el 200000 por lo menos... O en su lugar, decirle comandos por voz o pensamiento en esa época, pero seguirá siendo en esencia una comunicación más directa que mover con el ratón. Es cuestión de semántica.

» autor: Venturi_Debian

#44 Gestión de ficheros en Linux para dummies

snd — Sun, 02 Mar 2014 21:39:32 +0000

#5 Pues yo no veo el porqué debería desaparecer. Hay muchísimas cosas que se hacen mas rápido que con un interfaz gráfico, y si hablamos de las opciones avanzadas entonces ya...

Que se pudiera usar un linux sin necesidad de consola ya es otra cosa, y ya existe (cualquier ubuntu no hace falta tocar para nada la consola)

» autor: snd

#43 Gestión de ficheros en Linux para dummies

--153590-- — Sun, 02 Mar 2014 21:26:43 +0000

#41 Un script es un guión, un programa es más complejo que un simple guión.

» autor: --153590--

#42 Gestión de ficheros en Linux para dummies

--125581-- — Sun, 02 Mar 2014 21:26:25 +0000

#41

#!/bin/sh
##meta el comando introducido anteriormente
...
###fin

¿Programar? Llámalo automatizar, pues meter una función simple en Bash se hace en segundos.

Te cabe hasta en .bashrc

» autor: --125581--

#41 Gestión de ficheros en Linux para dummies

--406162-- — Sun, 02 Mar 2014 21:24:31 +0000

#40 para mi un script no deja de ser un programa, interpretado, pero un programa.

» autor: --406162--

#40 Gestión de ficheros en Linux para dummies

--125581-- — Sun, 02 Mar 2014 21:22:51 +0000

#37 "para eso creo un pequeño programa y lo guardo para otras veces."

Tardas 3 horas en hacer ese programa. La cual tardo yo 3 minutos y encima, oh, milagro, puedo guardarlo en un fichero de script por lotes como en 1960

O con ttyrec puedes grabar la entrada/salida de la terminal y reproducirla como un "video" ascii . Perfecto para tutoriales, partidas de nethack y demás.

» autor: --125581--

#39 Gestión de ficheros en Linux para dummies

--153590-- — Sun, 02 Mar 2014 21:20:13 +0000

#38 man find, man convert.

Edito: Además, hay situaciones como la que comenté en #30 que es difícil encontrar alguna forma de hacerlo en un tiempo razonable. En Windows escribes robocopy C:Origen C:Destino *.doc y estaría solucionado el problema. Hazlo a base de clicks.

Me quita las contrabarras nuevamente.

» autor: --153590--

#38 Gestión de ficheros en Linux para dummies

--406162-- — Sun, 02 Mar 2014 21:17:53 +0000

#36 normal que se te olviden cosas, otra prueba más de que es engorroso y sobre todo para un usuario normal.

» autor: --406162--

#37 Gestión de ficheros en Linux para dummies

--406162-- — Sun, 02 Mar 2014 21:16:48 +0000

#33 ideal para los que usar un ordenador es un fin en si mismo, pero engorroso para los que es solo un medio para conseguir algo

#34 claro, y donde ponemos el límite entre lo que es simplemente usar la linea de comandos o directamente programar? si tengo que escribir una longaniza de tropecientos comandos,parámetros,guiones, parentesis, barras invertidas,símbolos es de todo menos práctico, para eso creo un pequeño programa y lo guardo para otras veces.

» autor: --406162--

#36 Gestión de ficheros en Linux para dummies

--153590-- — Sun, 02 Mar 2014 21:15:19 +0000

Se me olvidó poner en #32 el filtro para sólo imágenes, find /directorio -name "*.jpg" -size +1M etcétera.

» autor: --153590--

#35 Gestión de ficheros en Linux para dummies

eltuert0 — Sun, 02 Mar 2014 21:10:31 +0000

#22 Para los que se encuentren incómodos con la línea de comandos se inventó hace mucho el concepto de "shell visual". Mi favorita es "Midnight Commander". Los que presumen de interfaz gráfica deberían probarlo y de paso enterarse de qué es un sistema virtual de ficheros

» autor: eltuert0

#34 Gestión de ficheros en Linux para dummies

dotromas — Sun, 02 Mar 2014 21:09:35 +0000

#28 y despues me coges y me pasas a blanco y negro solamente las que se hicieron el dia X y que ocupen menos de 1 MB y todas esas me las mandas por email a la direccion Y poniendo en el asunto el nombre de la imagen y un saludo.

Podriamos poner infinitos ejemplos de cosas que se pueden hacer por consola que no se pueden hacer por GUI o seria demasiado lento/ineficiente y dificil.

» autor: dotromas

#33 Gestión de ficheros en Linux para dummies

--153590-- — Sun, 02 Mar 2014 21:09:28 +0000

#32 Se usa find ... find /directorio -size +1M -exec convert {} -resize 1024x768 {}.resized ;

Edito: se come el carácter de contrabarra. No puedo ponerlo entero.

» autor: --153590--

#32 Gestión de ficheros en Linux para dummies

--406162-- — Sun, 02 Mar 2014 21:06:40 +0000

#31 qué linea? y a ver lo fácil que es...

» autor: --406162--

#31 Gestión de ficheros en Linux para dummies

--153590-- — Sun, 02 Mar 2014 21:05:38 +0000

#28 Es más fácil escribir una línea y pulsar [enter]

» autor: --153590--

#30 Gestión de ficheros en Linux para dummies

--153590-- — Sun, 02 Mar 2014 21:04:18 +0000

#23 No hace falta irte a ssh. Piensa en lo siguiente, quieres copiar de un origen que tiene una compleja estructura de directorios con muchos tipos de fichero a un destino, aunque sólo quieres copiar al destino un tipo de fichero, eso sí, manteniendo la estructura de directorios. Pues en Windows con robocopy se hace con facilidad. Y repito lo mismo que en #25, intenta hacer esto a base de clicks.

» autor: --153590--

#29 Gestión de ficheros en Linux para dummies

pirado04 — Sun, 02 Mar 2014 21:03:20 +0000

el enlace no da

» autor: pirado04

#28 Gestión de ficheros en Linux para dummies

--406162-- — Sun, 02 Mar 2014 21:02:38 +0000

#25 light-image-resizer.malavida.com/

» autor: --406162--

#27 Gestión de ficheros en Linux para dummies

safull — Sun, 02 Mar 2014 21:00:27 +0000

#17 En su momento se tradujo como torpes. Al menos la serie de libros ...for dummies se convirtió en ...para torpes.

Un dummie tambien es un muñeco que se utiliza en pruebas de choque, típicamente coches.

» autor: safull

#26 Gestión de ficheros en Linux para dummies

igl00 — Sun, 02 Mar 2014 20:54:36 +0000

#11 bah, menudo traductor. Maniquí es la acepción correcta

» autor: igl00

#25 Gestión de ficheros en Linux para dummies

--153590-- — Sun, 02 Mar 2014 20:53:52 +0000

#4 intenta redimensionar de 1500 fotos, sólo las que superen el megabyte de espacio a 1024x768 usando el ratón.

» autor: --153590--

#24 Gestión de ficheros en Linux para dummies

just_a_guy — Sun, 02 Mar 2014 20:48:40 +0000

Está caída

» autor: just_a_guy

#23 Gestión de ficheros en Linux para dummies

yusavi — Sun, 02 Mar 2014 20:47:30 +0000

Para aquellos que dicen tonterías sobre la línea de comandos sólo diré una cosa: ssh. No hay más preguntas señoría.

» autor: yusavi

#22 Gestión de ficheros en Linux para dummies

--125581-- — Sun, 02 Mar 2014 20:30:35 +0000

#4 ¿Y por qué ha tenido que inventar Microsoft algo como PowerShell? ¿No servía con "Herramientas del sistema y mmc.exe" ?

» autor: --125581--

#21 Gestión de ficheros en Linux para dummies

Koldo_Rodriguez — Sun, 02 Mar 2014 20:15:24 +0000

#4 La linea de comandos fue, es, y sera una herramienta tan potente como sencilla y ligera, sabiendo manejarla se hacen las cosas infinitamente mas rapido, eso si, es una interfaz menos amigable y mas dificil de manejar(es practicamente imposible no odiar el vi de primeras)..

» autor: Koldo_Rodriguez

#20 Gestión de ficheros en Linux para dummies

eliseo_24 — Sun, 02 Mar 2014 20:12:54 +0000

Negativo al canto, que se vayan a insultar a otro lado... y no, esos no son conceptos que todo el mundo debería conocer, sino aquellos que van a usarlo, una proporción mínima de los usuarios de PC.

» autor: eliseo_24

#19 Gestión de ficheros en Linux para dummies

--414833-- — Sun, 02 Mar 2014 20:11:39 +0000

#4 La linea de comandos es lo que diferencia a windows de linux, y de por qué toda la internet usa sobretodo linux como base computacional. Riete de tu propia ignorancia.

» autor: --414833--

#18 Gestión de ficheros en Linux para dummies

--234526-- — Sun, 02 Mar 2014 20:09:16 +0000

No me carga la página...

» autor: --234526--

#17 Gestión de ficheros en Linux para dummies

--417156-- — Sun, 02 Mar 2014 20:03:36 +0000

¿Qué son dummies?

» autor: --417156--

#16 Gestión de ficheros en Linux para dummies

NnSqunZ — Sun, 02 Mar 2014 20:03:36 +0000

No me va el enlace a la noticia.

» autor: NnSqunZ

#15 Gestión de ficheros en Linux para dummies

--86983-- — Sun, 02 Mar 2014 19:58:43 +0000

#14 ¿Quién te ha dicho a ti que yo lo estuviera diciendo en serio?

» autor: --86983--

#14 Gestión de ficheros en Linux para dummies

Paquito_Garcia — Sun, 02 Mar 2014 19:58:10 +0000

#12
#13 Un poquito de sentido del humor, solo pido un poquito de sentido del humor.

» autor: Paquito_Garcia

#13 Gestión de ficheros en Linux para dummies

--86983-- — Sun, 02 Mar 2014 19:56:23 +0000

#11 Porque si te insultan en inglés no te ofendes y das meneo.

» autor: --86983--

#12 Gestión de ficheros en Linux para dummies

NnSqunZ — Sun, 02 Mar 2014 19:55:06 +0000

#11 Tú traduciendo no eres tampoco un hacha precisamente.

» autor: NnSqunZ

#11 Gestión de ficheros en Linux para dummies

Paquito_Garcia — Sun, 02 Mar 2014 19:48:08 +0000

¿Por qué no utilizar la palabra dummies en español? Es decir, subnormales.

» autor: Paquito_Garcia

#10 Gestión de ficheros en Linux para dummies

listuam — Sun, 02 Mar 2014 19:03:36 +0000

falta
/run

» autor: listuam

#9 Gestión de ficheros en Linux para dummies

--357143-- — Sun, 02 Mar 2014 18:45:51 +0000

#4 #5 #6 Hay que leer más..

Hoy en día toda la gestión de ficheros se puede hacer mediante interfaz gráfica, aun así la linea de comandos puede llegar a ser muy potente y productiva, por esto mismo os dejo los comandos básicos que nos van a ayudar con este cometido

» autor: --357143--

#8 Gestión de ficheros en Linux para dummies

--84148-- — Sun, 02 Mar 2014 18:34:52 +0000

[Usuario deshabilitado]

» autor: --84148--

#7 Gestión de ficheros en Linux para dummies

Thae — Sun, 02 Mar 2014 17:56:38 +0000

#6 Bueno.. puede que tengas razon, en cualquier caso mirandolo por encima ( yo ya se de comandos y me saltado esa seccion ) creo que son comandos muy sencillos, cd, mkdir, ls, etc.

» autor: Thae

#6 Gestión de ficheros en Linux para dummies

Mister_Lala — Sun, 02 Mar 2014 17:52:46 +0000

#5 A mí me parece genial que exista, pero chirría un poco en un post para usuarios nóveles.

» autor: Mister_Lala

#5 Gestión de ficheros en Linux para dummies

Thae — Sun, 02 Mar 2014 17:50:20 +0000

#4 jajaja es imposible que en cualquier post sobre linux no se abra debate sobre si la linea de comandos deberia seguir existiendo..

» autor: Thae

#4 Gestión de ficheros en Linux para dummies

Mister_Lala — Sun, 02 Mar 2014 17:44:14 +0000

Me encanta el último apartado ¿Todavía con línea de comandos en el 2014? jijijijijiijiji

» autor: Mister_Lala

#3 Gestión de ficheros en Linux para dummies

--327846-- — Sun, 02 Mar 2014 17:29:03 +0000

#2 Que yo sepa y por lo que tengo visto sólo cambia la Jerarquía de directorios y algunas que otras cosas más, pero en principio todo lo demás es igual.

» autor: --327846--

#2 Gestión de ficheros en Linux para dummies

Thae — Sun, 02 Mar 2014 17:23:40 +0000

Muchisima gente desconoce conceptos tan basicos como esos, alguien sabe si en los sistemas operativos de apple funciona igual? Estos se basan en sistemas Unix pero no se si es igual.

» autor: Thae

#1 Gestión de ficheros en Linux para dummies

jonolulu — Sun, 02 Mar 2014 17:01:19 +0000

Pues me parece un resumen estupendo para alguien que empieza

» autor: jonolulu