Portada
mis comunidades
otras secciones
#12:
#9 tu última frase demuestra que no has administrado nunca un sistema libre.
Ahora bien, esta noticia es un trollazo de mucho cuidado, y ya estoy un pelin harto de estas tonterías.
Primero, durante años he usado sistemas win* y NUNCA he tenido ningún virus, ni troyano, ni problemas de seguridad.
Segundo, durante mas años todavía, he usado y administrado sistemas Linux de todos los sabores y nunca he tenido ningún problema de seguridad.
Tercero, Si no se sabe de administración ni siquiera unas normas de seguridad básicas, no puedes ir por el mundo diciendo que X sistema es mas seguro que otro.
Cuarto, si hablamos de cuelgues, yo he colgado TODOS los operativos que he tenido en mis manos ( es lo que tiene programar a nivel de kernel ).
Quinto, Si te clavan un troyano porque te bajas un .exe, .com, .dat, .lnk . Es porque eres un completo inepto en informática.
Sexto, Si no quieres tener un fallo de seguridad, aprende a ser un usuario de sistemas informáticos.
¿Algún problema?
Ahora bien, esta noticia es un trollazo de mucho cuidado, y ya estoy un pelin harto de estas tonterías.
Primero, durante años he usado sistemas win* y NUNCA he tenido ningún virus, ni troyano, ni problemas de seguridad.
Segundo, durante mas años todavía, he usado y administrado sistemas Linux de todos los sabores y nunca he tenido ningún problema de seguridad.
Tercero, Si no se sabe de administración ni siquiera unas normas de seguridad básicas, no puedes ir por el mundo diciendo que X sistema es mas seguro que otro.
Cuarto, si hablamos de cuelgues, yo he colgado TODOS los operativos que he tenido en mis manos ( es lo que tiene programar a nivel de kernel ).
Quinto, Si te clavan un troyano porque te bajas un .exe, .com, .dat, .lnk . Es porque eres un completo inepto en informática.
Sexto, Si no quieres tener un fallo de seguridad, aprende a ser un usuario de sistemas informáticos.
¿Algún problema?
#10:
#6 >es malo porque da visibilidad a esos bugs
Eso de que te quejas se llama "seguridad por oscuridad" (http://es.wikipedia.org/wiki/Seguridad_por_oscuridad) y está demostrado que ni es seguridad ni es nada.
Eso de que te quejas se llama "seguridad por oscuridad" (http://es.wikipedia.org/wiki/Seguridad_por_oscuridad) y está demostrado que ni es seguridad ni es nada.
#25:
#24 http://kernelnewbies.org/FAQ/WhereDoIBegin
Que te diviertas.
Que te diviertas.
#3:
Aun a riesgo de que me cosan a negativos, la he votado cansina.:P
Comentarios
#9 tu última frase demuestra que no has administrado nunca un sistema libre.
Ahora bien, esta noticia es un trollazo de mucho cuidado, y ya estoy un pelin harto de estas tonterías.
Primero, durante años he usado sistemas win* y NUNCA he tenido ningún virus, ni troyano, ni problemas de seguridad.
Segundo, durante mas años todavía, he usado y administrado sistemas Linux de todos los sabores y nunca he tenido ningún problema de seguridad.
Tercero, Si no se sabe de administración ni siquiera unas normas de seguridad básicas, no puedes ir por el mundo diciendo que X sistema es mas seguro que otro.
Cuarto, si hablamos de cuelgues, yo he colgado TODOS los operativos que he tenido en mis manos ( es lo que tiene programar a nivel de kernel ).
Quinto, Si te clavan un troyano porque te bajas un .exe, .com, .dat, .lnk . Es porque eres un completo inepto en informática.
Sexto, Si no quieres tener un fallo de seguridad, aprende a ser un usuario de sistemas informáticos.
¿Algún problema?
Aun a riesgo de que me cosan a negativos, la he votado cansina.:P
#24 http://kernelnewbies.org/FAQ/WhereDoIBegin
Que te diviertas.
#6 >es malo porque da visibilidad a esos bugs
Eso de que te quejas se llama "seguridad por oscuridad" (http://es.wikipedia.org/wiki/Seguridad_por_oscuridad) y está demostrado que ni es seguridad ni es nada.
he votado como erronea la noticia porque muchos de los puntos parece que los ha puesto un principiante. Linux es un sistema bastante seguro, pero no por las razones que exponen aquí. Transcribo los errores que he encontrado
- 1. Mejores herramientas de gestión: las actualizaciones de Linux afectan a todos los componentes, mientras que en Windows cada aplicación debe ser actualizada y parcheada por separado. –> Hay muchos programas que se han de instalar a mano, porque no vienen en los repositorios. Si por ejemplo actualizas el sistema de base de datos, algunos de estos programas te los podrías cargar
- 3. Diseño modular: Si un componente del sistema está fallando o es vulnerable, es más fácil desactivarlo para que no dé problemas. –> eso si tienes suficientes conocimientos, como en Windows o en cualquier otro sistema.
- 5. Arquitectura Open Source: todos ven el código, de modo que cualquiera puede colaborar para corregir fallos. –> Esto en principio está bien, porque se supone que estas correcciones están en los respositorios al poco tiempo de detectarse y corregirse el bug. Sin embargo influye el hecho de que hay bastante gente que ha tenido conflictos con las actualizaciones y las distintas versiones que se pueden instalar (por ejemplo, por el caso que decía en 1 , que tengas programas no incluidos en los repositorios y que desactives las actualizaciones automáticas para evitar problemas con estos programas)
- 6. Entorno muy diverso: mientras que en Windows el entorno es único y los exploits se extienden fácilmente gracias a que funcionan por ser muy genéricos, las distintas versiones de Linux y de sus aplicaciones hacen más complicado el desarrollo de exploits que tengan un gran potencial. –> Supongo que se referirán a la ubicación de archivos. Esto sería lo mismo que "seguridad por oscuridad", si entre las distintas ramas de distribuciones linux hay diferencias en cuanto a la forma de organizar la jerarquía de ficheros, lo que en realidad hace es dificultar a la persona que tiene que estar gestionando distintas distros linux, porque se vuelve loco para acordarse en qué ruta estaba cada cosa (lo digo por experiencia). Si se refieren a la variedad de programas, windows tiene una gran variedad de programas, que no se encuentran en un repositorio y que, por tanto no son tan fáciles de identificar (imposible controlar todo el software, ya que son muchos los fabricantes y no tienes por qué conocerlos).
#14 La frase a la que me refiero es por la velocidad de resolución de bugs en sistemas libres. Y creo que te he inducido a error. El resto del comentario no iba referido a ti, lo siento.
Sobre mi perfil, si te interesa, también he trabajado en una fabrica haciendo colchones y de guardia de seguridad en unos grandes almacenes. ¿Eso quita merito a mis conocimientos?, Si te interesa, he trabajado 5 años de Sysadmin, y durante esos 5 años también programaba en mis ratos libres. Después he pasado 6 años programando para multinacionales y durante el último año, he creado mi propia empresa de programación, que ya cuenta con 4 trabajadores. Y parte de esos años trabajados han sido para poder pagarme la carrera.
Y por si te interesa, no tengo ningún interés en tu perfil.
#17 no, no pretendía dar un toque de "guru" simplemente era un pre-respuesta a la argumentación tipica del fanboy linuxero, el pantallazo azul.
#20 he cambiado de opinión, paso de responderte.
#22 Creo que #20 no sabe qué es programar a nivel de kernel, no te esfuerces
#9 el problema es que muchos de los que hablan sobre que "Se arreglan los bugs" no han arreglado bugs en su vida. Hay muchos tipos de bugs, los hay desde pequeños como puede ser unos caracteres o una llamada erronea a bugs realmente profundos que pueden tardar años en resolverse totalmente porque requeriria el reescribir medio programa y para los que lo unico que puedes hacer relativamente rapido es hacer un parche cutre que evita que se pueda explotar facilmente.
Los segundos son los peligrosos, pueden pasar desapercibidos por ser aparentemente correctos, pueden estar en una llamada a una funcion que llama a una libreria que a su vez depende de otra libreria que tiene una funcion con un parametro de entrada que puede fallar, o puede ser algo tan gordo como que el diseño de la aplicacion sea ligeramente incorrecto y que por alguna razon siempre escriba algo vital en la misma parte de la memoria y podamos desbordar la memoria y meter ahi nuestro codigo malicioso...
Puede ser algo realmente sutil, dificilmente explotable o incluso el propio fix puede tener problemas... Un problema del open source es que todo el mundo puede escribir un fix, ok, solo los mejores llegaran, pero nada garantiza que sea un fix perfecto... y como en windows nada garantiza que el usuario medio actualice su linux para evitar los agujeros de seguridad.
Un windows perfectamente parcheado no es supervulnerable, un windows sin parchear si lo es, un linux parcheado no es vulnerable, un linux sin parchear lo es. Nada ni nadie te fuerza a parchear, el usuario al final es el mayor riesgo de seguridad para su propio equipo, sea ejecutando programas, tecleando comandos maliciosos o no tomando las precauciones necesarias(como parchear las vulnerabilidades).
El facto S.O. es solo un pequeño factor en la seguridad, alguien con habilidad y prudencia puede pasarse años sin un solo virus en su windows, mientras que alguien que no tiene la mas minima prudencia destrozara su linux en un par horas, bien sea instalando programas de fuentes no fiables o tecleando comandos maliciosos.
Pero linux es perfecto, sus usuarios al tocarlo se tranforman en supergenios de la informatica y siempre hacen las cosas bien, mientras que un usuario windows se transforma en retrasado mental y mete virus solo con encenderlo, ademas se golpea la cabeza con un palo para hacer mas penosa su experiencia...
#4 Soy otra vez Pepotón. Ya veo que me estáis llenando de negativos por decir la pura verdad: el código abierto es bueno y es malo para mantener la seguridad de un sistema. Es bueno porque facilita la depuración de bugs y es malo porque da visibilidad a esos bugs.
Siento ofender, pero me gusta hablar a las claras.
#24 me arrepiento de haber empezado un flame contigo.
Y la próxima vez busca "kernel api" o "v4l kernel api" o "win32 kernel api" o "lo_que_quieras_acceder_a_nivel_de_kernel kernel api"
#11 Si tienes escondidos 10.000 € y solo tú sabes donde están, entonces debes estar vigilándolos minuto a minuto porque si yo adivino donde están y no los vigilas te los mango. Ahora si esos 10.000 € son de 100.000 personas y todos saben donde están por mucho que yo sepa donde están y tu estés tomando unas cañas va a estar jodido evitar a los otras 99.999 personas que pueden estar vigilándolos.
Ahora haz una equivalencia entre código privativo y código abierto.
#12 Evidentemente un mecánico puede joder cualquier coche solo con proponerselo, y eso no implica que de cara al usuario unos sean mucho más fiables que otros. Si pretendías dejar claro que programas a nivel kernel para dar autoridad a tu argumentación, ya lo has hecho, pero es una salida del tiesto en toda regla. Y conste que el artículo me parece superficial e irrelevante, pero esas enumeraciones de experto autorizado sobran bastante. Con el punto 6 sugieres que ningún software tiene problemas de seguridad, que el fallo siempre es de los usuarios? Un usuario no tiene por qué preocuparse de la seguridad de un sistema, eso es tarea del administrador.
es más seguro???Que notición
1. Mejores herramientas de gestión: las actualizaciones de Linux afectan a todos los componentes, mientras que en Windows cada aplicación debe ser actualizada y parcheada por separado.
Es que sólo leyendo eso...
ein?
#6 creo que no entiendes el concepto....
detectas un bug importante y a la hora está arreglado...
en otros S.O. sale un bug y a los 2 meses como pronto se arregla...
Como explotar un bug que en nada estará arreglado...
Hombre colchonero. Creía que ya te habías dado por vencido. Ahora vuelves por aquí para aclararme lo obvio: algunos errores se solucionan muy rápido y otros tardan mucho en ser solucionados. Hay que actualizar nuestro sistema constantemente con las últimas versiones para tenerlo al día. Madre mía.
Para ese viaje no hacía falta alforjas.
Sigo esperando todavía que nos aclares cuáles son esas tremendas funcionalidades con las que amplías las capacidades de un SO. "De echo" (sic), jo, jo, jo ... ya me espero tú respuesta.
#6 El hecho de que sea código abierto permite que haya muchicientas distribuciones, por lo que juankear vulnerabilidades puede llegar a ser trabajar para nada, ya que los bugs explotados por una parte pueden no existir en otra distro. En materia de seguridad, esa es la ventaja del código abierto según lo entiendo yo.
Don't feed the troll.
#18 "Si un programa de código cerrado tiene un problema en su código fuente, únicamente detectarás el problema por ingeniería inversa o mediante el método de ensayo y error. En un programa de código abierto puedes llegar a leer la línea o trozo de código que provoca el problema."
Un desbordamiento de buffer, por ejemplo, tiene muchas formas de ser descubierto y no necesariamente por ingenieria inversa. Con el código fuente es mucho más fácil de detectar, por eso si todo el mundo tiene acceso al código también es mucho más fácil de corregir en menos tiempo, ya se sabe que mil ojos ven más que dos.
Ah, y si tienes algo valioso escondido y no lo vigilas constantemente nunca sabrás si te lo han mangado, que casi es peor que saber que ya no lo tienes y dejar de preocuparte.
Por eso no me gusta Windows. Porque lo usan unos niñatos para jugar y bajarse "pogramas de jaquin" y cuando alguien les piden explicaciones técnicas salen por peteneras, con mas miedo que vergüenza. Madre mía. ( Te gusta esta frase? es lo que se llama demagogia, es exactamente lo mismo que has dicho ).
No, lo que me parece es que tienes un ego desproporcionado creyéndote que lo sabes todo de los sistemas operativos y la programación. Yo no omitía ninguna perspectiva, pero me parece que has omitido el detalle de que el software que está incluido en una distribución está vivo, y eso significa ( porque sé lo vas a tergiversar ) que los programadores siguen trabajando activamente en el, en nuevas versiones y comprobación de errores. Cuando se detecta un error, obviamente puede que se tarde mucho tiempo en solucionar, ya sea por error de diseño o por complejidad. Pero un alto porcentaje de errores están solucionados, parcheados y comprobados en menos de 24h, de echo a veces incluso antes de hacerse publico el bug. Esos paquetes se suben a los repositorios de security-updates y en cuanto conectes el ordenador, o compruebes los repositorios, se actualiza.
La critica a los sistemas windows, es por la burocracia que lleva la solución de cualquier bug, y aunque el error este solucionado en 10minutos, se esperarán al segundo martes de mes para publicarlo.
Toda esta parrafada es para que te quede clarito de que se está hablando aquí, aunque con tu perfil de troll vas a seguir discutiendo e ignorando lo que se están riendo de ti por tus afirmaciones de super-programador.
Y con respecto a mis alusiones personales, creo que con esta respuesta debería quedarte claro a ti ( ya que el resto de personas ya lo han pillado ) el porque no te he respondido. O mejor dicho, por que te respondí y edité el comentario en #22.
#10 Es una forma de seguridad.
Si tengo escondidos 10.000€ en algún lugar de un edificio y no sabes donde están, ni siquiera sabes en que edificio es, entonces hay una seguridad. Llámala por seguridad por oscuridad o llámala discreción para no ser tan cursis y así nos entendemos todos.
Encima he puesto un voto negativo a la noticia. Tratad a Pepotón con cariño para la próxima vez.
¡ Que contentos deben estar en The Inquirer !
le vincularon la "noticia" en todas partes y se armó terrible flame, aquí y allá.
#30 Razón tienes mi amigo. Don't feed the troll
#12 Efectivamente nunca he administrado un sistema libre, ni ganas que tengo de hacerlo, aunque no sé que tiene que ver mi frase en la que expongo la dificultad de resolver los bugs (o errores de programación) con ser un administrador de sistemas Linux.
Parece que tu perfil es más de administrador de sistemas que de programador. Después vienes a decir con tu prosa críptica que has programado a nivel de kernel. ¿Seguro que has programado? ¿O sólo has compilado? ¿Has añadido alguna funcionalidad nueva a tu sistema operativo a costa de muchísimas horas de programación o sólo has instalado/desinstalado módulos?
No sé me gustaría saberlo.
Por eso no me gusta Linux. Os auto-proclamáis gurús de la ingeniería informática del kernel de Linux y cuando alguien os pide explicaciones técnicas, salís por peteneras, con más miedo que vergüenza. Madre mía.
Creo que interpreté mal algunos post de esta conversación. Cuando alguien mencionó que los bugs se arreglaban en 1h no capté que omitía la perspectiva del programador. Tal sujeto estaba hablando desde la perspectiva del administrador. Claro. Ahora cuadra todo. Un bug. Me conecto a internet, me bajo el patch, lo instalo y andando a tomar viento que son las 18:00h y tengo que ir a casa. Jo, jo , jo ...
Vaya forma de menospreciar el trabajo del programador. Un bug puede ser muy penoso de resolver, como ha apuntado un compañero por ahí arriba. Puede implicar una fase de testing muy amplia para delimitar todas sus consecuencias y volver a las tareas de concepción, análisis, diseño, implementación y test de las funcionalidades afectadas para restaurar el funcionamiento correcto del sistema.
Pueden ser semanas, meses o hasta años de trabajo en casos excepcionales.
Ahora me cuadra todo: pongo un patch y listo. JO, jo, jo. En 1h arreglado. Claro que el patch me lo tienen que dar hecho. Y a partir de que esté hecho contamos el tiempo de resolución del bug. Es tan bueno que casi parece un chiste.
La callada por respuesta. Suponía que alguien que tocaba las mismísimas entrañas de un sistema operativo haciendo modificaciones en el núcleo no tendría ningún problema en compartir su experiencia y sabiduría con nosotros.
Quizás lo que hizo fue invocar a una función del sistema para obtener la hora en curso desde un programa del tipo: "Hello World ! Son las 22:38h", o bien compiló y poco más.
Jo, jo, jo ... ya sé que soy muy mal pensado y que me habéis llenado a negativo, pero no sé, creo que tengo olfato para detectar fantasmones.
#16 Que no es eso, hombre que no es eso. Te pongo un ejemplo. Gracias a los detectores de metales se están descubriendo muchos pequeños tesorillos de nuestra guerra civil. Eran sacos de monedas que algunos soldados escondían antes de marchar al frente. Resulta que algunos volvieron y recuperaron sus sacos. Otros murieron y estamos descubriendo ahora estos sacos gracias a los detectores de metales.
Eso de que tienes que vigilar minuto a minuto una cosa escondida es de lo más absurdo que he leído en esta conversación.
Sin un programa de código cerrado tiene un problema en su código fuente, únicamente detectarás el problema por ingeniería inversa o mediante el método de ensayo y error. En un programa de código abierto puedes llegar a leer la línea o trozo de código que provoca el problema.
#26 Ya sé que me están lloviendo los negativos pero me estoy divirtiendo mucho. Veo que no hay forma de avanzar contigo. No quiero que me hables de la existencia de un conjunto de funciones que proporcionan servicios asociados al kernel. Quiero que me expliques las funcionalidades que tú has implementado a nivel de kernel. Las opiniones están divididas.
Claro que entiendo el concepto. Tengo una página web y sólo el 2% de las visitas que recibo son de usuarios Linux. De hecho es el doble de probable encontrar una visita hecha con un Mac que alguien con alguna distribución Linux. Es decir que la inmensa mayoría de los que hablan tan bien de Linux y del Open Sourcer utilizan ... Windows y programas propietarios.
Si soy un hacker y estudio un programa de código abierto, algo que no hace casi nadie, y encuentro un bug, de entrada me lo callo. Después investigo una forma de explotar esa vulnerabilidad, la analizo, la diseño, la implemento, la pruebo y luego ataco.
Eso de que si sale un bug a la hora está arreglado no es creíble. La ingeniería del software no es como hacer un plato de macarrones.
#22 Vengaaaaa, vaaaaaaaaa, no te enfades, hombre. Si sólo quiero saber cuáles son esas maravillas de la ingeniería de programación que has ejecutado "a nivel de kernel". Y no vale la palabra "compilar".
#23 Busco "programar a nivel de kernel" en el google y me salen 5 entradas y 4 de ellas son de un novato pidiendo que le enseñen a "programar a nivel de kernel". Ay, ay, ay que me temo que "programar a nivel de kernel" es compilar. Madre mía.
#25 Lo siento, no te había leído bien y he precipitado el negativo hacia tu post. Ya te lo compensaré. Vamos a ver, según tu link:
"It may seem daunting to be confronted with such a large amount of source code, but bear in mind, that very few kernel hackers understand every area of the kernel tree."
Me gustaría saber que rama del frondoso árbol del kernel es la que programa nuestro amigo el administrador de colchones ... digoooo de sistemas.
#19 No contestas a la pregunta. Si has programado a nivel de kernel, ¿qué funcionalidades nuevas le has añadido al SO? Me gustaría saberlo.
Me has explicado hasta lo tuyo con los colchones y tu experiencia proletaria en almacenes pero no llegas al meollo de la cuestión.
Al final hemos desgraciado esta conversación con los negativos. Lástima porque empezaba a ser divertida.
Bastante de acuerdo. Creo que es algo obvio. Atención al punto 5 porque es un arma de doble filo:
"5. Arquitectura Open Source: todos ven el código, de modo que cualquiera puede colaborar para corregir fallos."
Como todos ven el código, también puede verlo un hacker y explotar alguna vulnerabilidad del sistema o algún bug.