#18 ¿A quién han metido en la cárcel por meter papeles en cajas de plástico?
#23 Aqui tenemos el argumento de un nazionalista
Aquí en #23 tenemos un ejemplo de la mierda en la que se ha convertido Menéame, faltas de respecto sin ninguna razón más que el desacuerdo, y encima con votos positivos.
Y pensar que el otro día en los comentarios aquí Martin Varsavsky: "Los dueños de 
meneame creemos que está mucho más a la izquierda de lo que representa el público español. Pero eso es fácil de arreglar..."
#95 Lo que tú digas, suarezcastellvi_64e939b2.
#18 Joder, la demagogia como la gastáis...
#30 es terrible, esos papeles aunque tenían valor cero CASI ROMPEN A ESPAÑA 😭 😭 😭
#31 Que excusas mas baratas, por dios.
#62 Hombre, esa es tener una visión muy vaga e imprecisa de un conflicto tan complejo
#18 No han condenado a nadie por meter papeles en cajas de plástico, por lo que tampoco hay amnistiados por estos hechos. Lo que hay son condenas e investigaciones por terrorismo, desobediencia, alta traición, etc...y esto se ha amnistiado
#84 Ya, pero es que este comentario queda un poco fuera de lugar cuando los propios fiscales tienen visiones discordantes, en el Congreso de los Diputados hay votaciones con resultados bastante parejos, y hasta el fiscal del Tribunal Supremo consideró un día que en lo relativo a Puigdemont había terrorismo, y a los días, cuando habló con el fiscal general, ya no pensaba igual... fíjate que curioso...pero si, quedémonos con que los hechos son los hechos, buen resumen de todo esto
#123 Claro que si guapi, si es que mira que es fácil sentar catedra delante del ordenador, ¿o acaso has estado tú en la instrucción judicial y en cada una de las sesiones del juicio celebrado?
No han habido delitos inventados, han habido condenas y amnistía...es decir, por si no lo logras entender, existen resoluciones judiciales, dictadas a lo largo de un procedimiento judicial, en los que se condena a una serie de personas. Y luego, se ha aprobado una Ley en la que se borran esos delitos. Pero no han habido invenciones...otra cosa es que no estés de acuerdo
#42 Condenar no se pero vaya vergüenza y ridículo internacional que hacemos. Vivo en el extranjero y diversas personas de mi entorno me preguntaron si es ilegal hacer referéndums en España, o que como estaba la cosa en mi país 
Entre unos y otros se ha dado una imagen medieval del país.
#103 De casa de tu madre te puedes largar al cumplir los 18.
#103 Tu madre no te secuestra a la fuerza y te obliga a darle todo lo que ganas para gastárselo en tus hermanos holgazanes y comprarse bolsos, mientras tu vas en bici vieja al curro y duermes bajo la esclalera.
#18 ¿A quién han metido en la cárcel por meter papeles en cajas de plástico?
#23 Aqui tenemos el argumento de un nazionalista
Aquí en #23 tenemos un ejemplo de la mierda en la que se ha convertido Menéame, faltas de respecto sin ninguna razón más que el desacuerdo, y encima con votos positivos.
Y pensar que el otro día en los comentarios aquí Martin Varsavsky: "Los dueños de meneame creemos que está mucho más a la izquierda de lo que representa el público español. Pero eso es fácil de arreglar..."
#95 Lo que tú digas, suarezcastellvi_64e939b2.
#18 leyendo comentarios como este entiendo cada vez más el auge de la ultraderecha
#84 Ya, pero es que este comentario queda un poco fuera de lugar cuando los propios fiscales tienen visiones discordantes, en el Congreso de los Diputados hay votaciones con resultados bastante parejos, y hasta el fiscal del Tribunal Supremo consideró un día que en lo relativo a Puigdemont había terrorismo, y a los días, cuando habló con el fiscal general, ya no pensaba igual... fíjate que curioso...pero si, quedémonos con que los hechos son los hechos, buen resumen de todo esto
#10 Que consideres "trabajar" lo que hacen los usuarios de este portal ya me todo lo que necesito saber de ti.
#130 En qué segundo exactamente?
#13 Ese inserto ("[de la pandemia]") la verdad es que no veo de dónde se infiere del vídeo, y lo he visto varias veces seguidas para intentar entender de donde sale. No se puede deducir de manera clara que quiera decir "de la pandemia" por lo que parece un añadido apresurado, erróneo e incluso malintencionado.
Es más, Torra dice "queremos ser independentistas" y no "queremos ser independientes". Es un matiz pequeño, pero un matiz al fin y al cabo. Y seguramente intencionado también.
Que Torra sea un inepto no justifica que un diario de tirada nacional tergiverse y se invente las cosas de esta manera, que luego llega la gente y se lo come con patatas porque verse el vídeo como que no, eh, que da pereza.
#28 El target principal de este tipo de monitores son estudios y salas de post-producción, que están hartos de tirar stands a la basura porque el estándar es colgar los monitores en monturas VESA. Por lo tanto, algo de sentido en vender el stand aparte sí hay (no entro en lo caro que es, sólo matizo eso de "nadie habría dicho nada").
#33 Toda la razón en eso. De hecho creo que aunque estas maneras funcionales existan, no deberían ser excusa para no entender cómo funcionan "por dentro". Pero una vez entendidas bien, ayudan a escoger mejor la herramienta correcta para cada caso. No siempre se puede aplicar map, filter o reduce pero, cuando se puede, se agradece.
De hecho recuerdo haber aprendido sobre estas cosas en pseudocódigo en la carrera (inmersión, plegado/desplegado, de recursivo a iterativo y viceversa, etc) y en su día no verle la utilidad. Sin embargo a día de hoy soy fan 
#34 Yo si se las vi siempre. De hecho me molestaba como la gente se quejaba y sin embargo te dotan de herramientas cojonudas, de las que incluso tu puedes crear híbridos o cosas nuevas usando o mejorando esas técnicas.
Pero vamos, es la típica función a la que llegas cuando tienes un tiempo en un lenguaje. Es de nivel especialización. Y si, es un ejemplo de magia en un lenguaje. Al menos lo que yo llamo magia. La solución de javascript no me gusta, a mi. No me gusta que las variables sobrevivan a las funciones... es muy confuso, a menos que el ámbito esté muy claro, y si ese ámbito existe, déjalo bien claro. Las clases hacen eso, y aún asi, fuera de la clase no salen. Las cosas "bien recogidas" parea poder seguirles la pista.
Pero si la gente del mundillo de javascript, consideráis a reduce una buena implementación, forma parte de la cultura del lenguaje, te adaptas. Es bueno pq marca un patrón reconocible por todos.
#29 La reducción es un proceso iterativo. En cada paso, tienes un valor, que es total, y que empieza por el valor inicial (en este caso 0), y tienes otro valor, que es current, y que empieza por ser array[0]. En el primer paso, ejecutas la función pasada como parámetro de la función (en el ejemplo: total + current), y obtienes un valor de retorno. Ese valor de retorno pasa a ser el valor total para el siguiente paso, y current será valor[1]. Así sucesivamente hasta que no queden más índices en el array, y total pasará a ser el valor de retorno de la llamada a reduce.
Esto que he explicado, es siempre así, sean cuales sean los parámetros pasados a reduce. Por lo tanto, el funcionamiento de reduce no depende del contexto, sino de los parámetros, como cualquier otra función. Sigue sin ser magia.
#33 Toda la razón en eso. De hecho creo que aunque estas maneras funcionales existan, no deberían ser excusa para no entender cómo funcionan "por dentro". Pero una vez entendidas bien, ayudan a escoger mejor la herramienta correcta para cada caso. No siempre se puede aplicar map, filter o reduce pero, cuando se puede, se agradece.
De hecho recuerdo haber aprendido sobre estas cosas en pseudocódigo en la carrera (inmersión, plegado/desplegado, de recursivo a iterativo y viceversa, etc) y en su día no verle la utilidad. Sin embargo a día de hoy soy fan
#34 Yo si se las vi siempre. De hecho me molestaba como la gente se quejaba y sin embargo te dotan de herramientas cojonudas, de las que incluso tu puedes crear híbridos o cosas nuevas usando o mejorando esas técnicas.
Pero vamos, es la típica función a la que llegas cuando tienes un tiempo en un lenguaje. Es de nivel especialización. Y si, es un ejemplo de magia en un lenguaje. Al menos lo que yo llamo magia. La solución de javascript no me gusta, a mi. No me gusta que las variables sobrevivan a las funciones... es muy confuso, a menos que el ámbito esté muy claro, y si ese ámbito existe, déjalo bien claro. Las clases hacen eso, y aún asi, fuera de la clase no salen. Las cosas "bien recogidas" parea poder seguirles la pista.
Pero si la gente del mundillo de javascript, consideráis a reduce una buena implementación, forma parte de la cultura del lenguaje, te adaptas. Es bueno pq marca un patrón reconocible por todos.
#28 Respecto a =>, yo estaba como tú, no sabía lo que significaba porque yo hace tiempo que no hago nada con Javascript, y hoy he visto por el ejemplo del artículo que así es como se especifica un lambda (una función anónima) en ES7. Pero no me ha costado nada entender qué hace esa línea de código porque he visto reduce ya en muchos lenguajes (como reduce o como foldLeft): Java, Scala, Python, Ruby, Haskell, LISP, Clojure y el funcionamiento es siempre el mismo, y el contexto poco tiene que ver. De hecho, no tiene nada que ver porque la forma de utilizarlo es siempre la misma: secuencia, función, valor inicial. Así que no, sigue sin ser magia según tu definición.
Entiendo lo que dices, pero como otros comentan por aquí, lo atribuyo a la falta de hábito con la programación funcional. Personalmente, después de haber hecho muchísima programación imperativa, muchísima OOP y bastante programación funcional, por poco que me cueste entender un bucle for, siempre me será más sencillo entender un reduce. ¿Cuántas variables se definen antes del bucle que vayan a afectar al bucle? ¿Qué variables cambian dentro del bucle? ¿Para qué van a servir esas variables y que resultado, o resultados va a generar el bucle? Todo eso es necesario procesarlo mentalmente para entender el código. Sin embargo, con reduce tienes una secuencia, una función y un valor inicial, nada más.
Prueba a ver con esta explicación en Javascript, a ver si se entiende mejor de lo que me explico (que ya veo que es mal): https://www.airpair.com/javascript/javascript-array-reduce
Que quede claro que en ningún caso esté diciendo yo que 1 línea siempre sea mejor que 7. Lo que digo es que, con conocimientos básicos de programación funcional, es más legible el reduce que el bucle for. Igual que es más legible un bucle for que un "bucle" en assembler hecho a base de escrituras en registros y saltos condicionales.
#30 Ok, es que al tema de que una variable sobreviva a una función, solo le veía utilidad para simular la POO en javascript. Sospecho que total, sobrevive con su valor de una llamada a otra de la función por cada elemento, y current es sobreescrito en cada llamada.
Supongo que tiene utilidad pq al ver el reduce() los que le dais más caña al javascript ya sabéis lo que se intenta hacer. Me has medio convencido, oka. Tiene valor semántico.
#25 reduce está lejos de ser magia. Es simplemente una reducción de una secuencia de valores a un solo valor de resultado, aplicando la misma función al par de valores [resultado parcial, siguiente valor] en cada paso.
Por lo tanto, array.reduce((total, current) => total + current, 0) lo que hará será:
((((0 + 1) + 2) + 3) ... + n)
Vamos, lo mismo que hace el bucle for pero sin tener que preocuparse de tener que inspeccionar el código para encontrar qué variables se definen, qué variables se usan y cómo. Las reglas de la programación imperativa como las que rigen los bucles pueden parecer simples, pero pueden provocar un código innecesariamente complejo muy fácilmente.
#26 Esa flecha de que lenguaje es? la de =>... me estuve leyendo por ejemplo, en java, y necesitas un artículo bastante largo para entender lo que hace, de tal forma, que días después de habérmelo leído, ya no lo recuerdo, y soy incapaz de aplicar su versión más potente. Un sólo símbolo implicaba demasiadas cosas a la vez según el contexto.
Si te especializas en un lenguaje, cojonudo, pero si estas todo el día con varios... es un coñazo que sean tan complicados. Todo se puede simplificar con una función.
Yo podría sustituir tu código de arriba, por un bucle for supuestamente complicado, aún así corto y testado, y ponerle un nombre descriptivo. PERO eso son gustos, nada más. Sigo leyéndote y no entiendo nada. Quizás es que desconozco ese lenguage, pero bueno, me leeré el artículo para entender, después de un montón de explicaciones, la maravillosa ventaja de ahorrarte 7 lineas de código.
Esas cosas se las dejo al algoritmo, que si puede ser complejo, pq muchas veces no queda otra. O a la estrutura de datos, el modelo, pero el lenguaje... a mi me gusta poder "traducir" lo más rápido posible. Pero decidir que es una verdadera ventaja es una cuestión de gustos.
Si me justificas la reutilización, cojonudo. Si me justificas la eficacia, cojonudo. Pero cambiar 7 lineas de un código que entiende casi cualquiera que venga de casi cualquier lenguaje, por unas lineas que tengo que empollarme a ver que están haciendo (magia: unos pocos caracteres implican muchísimas cosas y encima cambian según el contexto), no se si es buen negocio.
#28 Respecto a =>, yo estaba como tú, no sabía lo que significaba porque yo hace tiempo que no hago nada con Javascript, y hoy he visto por el ejemplo del artículo que así es como se especifica un lambda (una función anónima) en ES7. Pero no me ha costado nada entender qué hace esa línea de código porque he visto reduce ya en muchos lenguajes (como reduce o como foldLeft): Java, Scala, Python, Ruby, Haskell, LISP, Clojure y el funcionamiento es siempre el mismo, y el contexto poco tiene que ver. De hecho, no tiene nada que ver porque la forma de utilizarlo es siempre la misma: secuencia, función, valor inicial. Así que no, sigue sin ser magia según tu definición.
Entiendo lo que dices, pero como otros comentan por aquí, lo atribuyo a la falta de hábito con la programación funcional. Personalmente, después de haber hecho muchísima programación imperativa, muchísima OOP y bastante programación funcional, por poco que me cueste entender un bucle for, siempre me será más sencillo entender un reduce. ¿Cuántas variables se definen antes del bucle que vayan a afectar al bucle? ¿Qué variables cambian dentro del bucle? ¿Para qué van a servir esas variables y que resultado, o resultados va a generar el bucle? Todo eso es necesario procesarlo mentalmente para entender el código. Sin embargo, con reduce tienes una secuencia, una función y un valor inicial, nada más.
Prueba a ver con esta explicación en Javascript, a ver si se entiende mejor de lo que me explico (que ya veo que es mal): https://www.airpair.com/javascript/javascript-array-reduce
Que quede claro que en ningún caso esté diciendo yo que 1 línea siempre sea mejor que 7. Lo que digo es que, con conocimientos básicos de programación funcional, es más legible el reduce que el bucle for. Igual que es más legible un bucle for que un "bucle" en assembler hecho a base de escrituras en registros y saltos condicionales.
#30 Ok, es que al tema de que una variable sobreviva a una función, solo le veía utilidad para simular la POO en javascript. Sospecho que total, sobrevive con su valor de una llamada a otra de la función por cada elemento, y current es sobreescrito en cada llamada.
Supongo que tiene utilidad pq al ver el reduce() los que le dais más caña al javascript ya sabéis lo que se intenta hacer. Me has medio convencido, oka. Tiene valor semántico.
#26 Es que sigo leyendo y con la documentación delante, me cuesta VER como maneja total y current... como si la función la defines tú, como reduce sabe que "current" es el componente del array... y eso que llevo un rato mirándolo.
El ejemplo de antes lo pillé enseguida, pero para entender el nuevo en su totalidad el código, pq hay "magia", sigo sin pillarlo, tengo que seguir navegando en más y más documentación, si es que lo pillo con suerte.
La propia función reduce se comporta de maneras diferentes según el contexto de la llamada, tienes que leerte bien la documentación para saber que hace en cada caso... ESO ES MAGIA. La primera versión es mucho más simple. si lo que quieres es ahorrarte las variables de recorrido, cojonudo, los iteradores llevan inventados décadas.
#29 La reducción es un proceso iterativo. En cada paso, tienes un valor, que es total, y que empieza por el valor inicial (en este caso 0), y tienes otro valor, que es current, y que empieza por ser array[0]. En el primer paso, ejecutas la función pasada como parámetro de la función (en el ejemplo: total + current), y obtienes un valor de retorno. Ese valor de retorno pasa a ser el valor total para el siguiente paso, y current será valor[1]. Así sucesivamente hasta que no queden más índices en el array, y total pasará a ser el valor de retorno de la llamada a reduce.
Esto que he explicado, es siempre así, sean cuales sean los parámetros pasados a reduce. Por lo tanto, el funcionamiento de reduce no depende del contexto, sino de los parámetros, como cualquier otra función. Sigue sin ser magia.
#33 Toda la razón en eso. De hecho creo que aunque estas maneras funcionales existan, no deberían ser excusa para no entender cómo funcionan "por dentro". Pero una vez entendidas bien, ayudan a escoger mejor la herramienta correcta para cada caso. No siempre se puede aplicar map, filter o reduce pero, cuando se puede, se agradece.
De hecho recuerdo haber aprendido sobre estas cosas en pseudocódigo en la carrera (inmersión, plegado/desplegado, de recursivo a iterativo y viceversa, etc) y en su día no verle la utilidad. Sin embargo a día de hoy soy fan
#34 Yo si se las vi siempre. De hecho me molestaba como la gente se quejaba y sin embargo te dotan de herramientas cojonudas, de las que incluso tu puedes crear híbridos o cosas nuevas usando o mejorando esas técnicas.
Pero vamos, es la típica función a la que llegas cuando tienes un tiempo en un lenguaje. Es de nivel especialización. Y si, es un ejemplo de magia en un lenguaje. Al menos lo que yo llamo magia. La solución de javascript no me gusta, a mi. No me gusta que las variables sobrevivan a las funciones... es muy confuso, a menos que el ámbito esté muy claro, y si ese ámbito existe, déjalo bien claro. Las clases hacen eso, y aún asi, fuera de la clase no salen. Las cosas "bien recogidas" parea poder seguirles la pista.
Pero si la gente del mundillo de javascript, consideráis a reduce una buena implementación, forma parte de la cultura del lenguaje, te adaptas. Es bueno pq marca un patrón reconocible por todos.
#3 El for no es más legible porque para poder entender lo que hace, tienes que rastrear qué variables hay y cómo están mutando. La semántica del reduce está muy clara (es un fold-left típico) y por lo tanto con sólo ver qué es un reduce y cómo se actualiza el valor con cada item de la lista se ve enseguida lo que hace la línea de código.
Y sí, el reduce esconde un bucle (no siempre, también podría ser una recursión con TCO en otros lenguajes) pero el for también esconde otras cosas, como por ejemplo saltos en base a condiciones (en el intérprete, en bytecode o en assembler). Que una instrucción sea de un nivel más alto no es algo malo per se, mientras la semántica de la instrucción sea clara, ¿qué problema hay? Es mejor y más legible un for que escrituras de registros y saltos, pero del mismo modo es más legible un reduce que un for.
#1 Como dice #2, es más legible lo primero. Más que nada porque te has “comido” la indentación que tenía, y eso es hacer un poco de trampa.
#3 Creo que quizás te refieres a que es más entendible el bucle for, que es a lo que estamos acostumbrados (como dice el artículo). Pero con dos líneas de código, es más legible lo primero que lo segundo con siete. Creo que #4 te lo ha explicado muy bien.
#13 Creo que quizás te refieres a que es más entendible el bucle for
O vaya, que no sabes que significa legible... entiendo....
#16 Por eso he dicho “creo que igual te refieres…”. Lo de la comprensión lectora debe ir por barrios. Ni te cuento la ortografía.
#17 Veo que no entiendes que significa legible...
Legible no es "2 lineas en lugar de 7", legible es que venga un tio que no tiene ni idea de que hace el codigo y vea que hace de un vistazo.
Legible = entendible y no por ti, nada mas.
#18 Te lo voy a volver a repetir, que veo que andas un poco lentito: “creo que igual te refieres a…”, porque yo estaba especulando; yo ya no estaba hablando de si era legible o no, estaba yendo por otro camino. Pero tú a lo tuyo, campeón.
#1 Es más legible lo primero.
#2 Eso creo que es discutible. Personalmente, aunque más largo, veo más legible el for.
Por otro lado y como comentan en el propio artículo. Lo único que se está haciendo es ocultar el for, porque internamente la función array.reduce lo utilizará. El usar una función por supuesto lleva implícito un mayor coste de proceso.
#3 El for no es más legible porque para poder entender lo que hace, tienes que rastrear qué variables hay y cómo están mutando. La semántica del reduce está muy clara (es un fold-left típico) y por lo tanto con sólo ver qué es un reduce y cómo se actualiza el valor con cada item de la lista se ve enseguida lo que hace la línea de código.
Y sí, el reduce esconde un bucle (no siempre, también podría ser una recursión con TCO en otros lenguajes) pero el for también esconde otras cosas, como por ejemplo saltos en base a condiciones (en el intérprete, en bytecode o en assembler). Que una instrucción sea de un nivel más alto no es algo malo per se, mientras la semántica de la instrucción sea clara, ¿qué problema hay? Es mejor y más legible un for que escrituras de registros y saltos, pero del mismo modo es más legible un reduce que un for.
#1 Como dice #2, es más legible lo primero. Más que nada porque te has “comido” la indentación que tenía, y eso es hacer un poco de trampa.
#3 Creo que quizás te refieres a que es más entendible el bucle for, que es a lo que estamos acostumbrados (como dice el artículo). Pero con dos líneas de código, es más legible lo primero que lo segundo con siete. Creo que #4 te lo ha explicado muy bien.
#13 Creo que quizás te refieres a que es más entendible el bucle for
O vaya, que no sabes que significa legible... entiendo....
#16 Por eso he dicho “creo que igual te refieres…”. Lo de la comprensión lectora debe ir por barrios. Ni te cuento la ortografía.
#17 Veo que no entiendes que significa legible...
Legible no es "2 lineas en lugar de 7", legible es que venga un tio que no tiene ni idea de que hace el codigo y vea que hace de un vistazo.
Legible = entendible y no por ti, nada mas.
#18 Te lo voy a volver a repetir, que veo que andas un poco lentito: “creo que igual te refieres a…”, porque yo estaba especulando; yo ya no estaba hablando de si era legible o no, estaba yendo por otro camino. Pero tú a lo tuyo, campeón.
#6 He de reconocerte que no he mirado mucho el tema de programación declarativa. Y seguramente tengas razón porque yo personalmente me he quedado unos segundos pensando que hace el reduce y como lo utiliza, cuando el trozo con el for lo he identificado casi de inmediato.
De todas formas, todavía me quedaría la duda del coste de proceso, aunque para arrays no muy grandes seguramente sea despreciable.
#6 con un bucle for, SIEMPRE tienes que pararte a mirar lo que hace, porque no hay dos iguales.
De hecho corres el riesgo de "no ver" algún fallo, como incrementar el contador en un bucle inverso, o usar una variable errónea como índice...
Usando construcciones funcionales necesitarás un proceso de adaptación (aprender qué narices es un reduce, o un foldRight, o un flatMap, o...) pero después lo entenderás todo más rápido porque un reduce siempre es un reduce
#23 mientras programes para ti mismo, solo tu leas tu código y tus operaciones de bucle sean simples.
No entiendo el sentido, también te puedes equivocar usando el reduce, para que quieres reducir tanto las lineas de código? tampoco va a ser un cambio radical, van a ser bastante pocas, puedo entender tu gusto, pero no puedes comprender que no es lo mas habitual y es de conocimiento reducido?
#3 Lo de que usar una función lleva más coste de proceso no es del todo cierto. Podría ser, pero también podría ser que no gracias a que ciertos lenguajes pueden hacer bastante trabajo en tiempo de compilación y no de ejecución, así que el tiempo de ejecución real se vería bastante reducido. Pero, evidentemente, habría que probar en cada caso.
#27 No has refutado lo que dice #21. Un axioma es, por definición (y supongo que a eso se refiere con "en última instancia"), un punto de partida del sistema lógico, no una proposición que se pueda someter a demostración.
https://www.quora.com/Can-axioms-be-proven-in-mathematics
#187 250 comentarios y el tuyo es el único que se centra en el fondo del asunto y da en el clavo. El mercado de Apple no son los gamers, sino los profesionales. Y a éstos dales una FirePro (o una Titan, pero sería discutible) antes que una 970, una 980 o una 290x.
#86 estadista.
(De estado).
1. com. Persona que describe la población, riqueza y civilización de un pueblo, provincia o nación.
2. com. Persona con gran saber y experiencia en los asuntos del Estado.
estadístico, ca.
1. adj. Perteneciente o relativo a la estadística.
2. m. y f. Persona que profesa la estadística.
#186 cierto, se me ha escapado por escribir desde el movil. Pero desde luego un estadístico y un Big Data Engineer no son lo mismo.
No es seguro que haya sido un ataque a iCloud, podría haber sido perfectamente una colección privada de un hacker:
No tengo mucho aprecio a Apple y su "icloud" pero no me creo que ningun hacker con dos dedos de frente se tire horas en icloud eligiendo las fotos desnudas de esas tias, me inclino mas a pensar lo que comenta #99.
No creo que un servicio minimamente seguro como se supone icloud almacene las imagenes sin cifrar.
#75 Así que tu teoría es que alguien hizo una "copia de seguridad" (valiente forma de llamar a "robar fotos privadas")... del teléfono de no una ni dos famosas sino de decenas de famosas ¿es esa tu teoría? ¿y quién se supone que es esa persona que lo hizo? ¿el amigo informático de las famosas? Madre mía, qué cosas hay que leer.
#6 #104
Yo la verdad es que no tengo ni idea de como se ha hecho ni de si todas las fotos son verdaderas pero sí se que ningún sistema es 100% seguro...
Tampoco es que me considere superexperto en seguridad pero unas nociones sí que tengo.
Supongamos que se guarden cifradas (que en principio puede parecer lo correcto), en ese caso si la clave de ese cifrado estuviese únicamente en el móvil entonces la nube no tendría sentido ya que uno de los lemas de la nube es guardar las cosas en la red para poder usarlas desde otros dispositivos (ej: si se te pierde el móvil, si te compras otro, poder usarlo también en iPad... o compartirlas con otras aplicaciones o usuarios). En otras palabras, si alguien pierde el móvil habrá perdido con él todas sus fotos que se suponían a buen recaudo en la nube... así que esa no puede ser la forma correcta (es muy segura sí, pero no aceptable para la nube).
Alguien puede pensar: la clave puede que no se guarde en el móvil, ni en la propia "nube" sino que sea el password que supuestamente sólo sabe el usuario. Pero esto tiene varias pegas también... si el usuario cambia su clave (por ejemplo, si la olvida, que en usuarios normales suele ser más común que cambiarla por ser meticuloso) eso implicaría descifrar toooodos los ficheros de ese usuario y volverlos a cifrar con la nueva clave... ¡¡¡pero no se podrían descifrar si el usuario olvidó la clave!!! Y otra pega: en sistemas como Dropbox o Drive que permiten compartir carpetas con otros usuarios no valdría este sistema ya que los otros usuarios que accedan no saben su clave personal, así que este otro sistema no funcionaría, a menos que cada vez que se comparta algo se decodifiquen todos y cada uno de los ficheros compartidos. Y esto implicaría que hay ficheros que no son cifrados (o cuya clave de cifrado está centralizada, en Apple, o Dropbox o Google ... que viene a ser casi lo mismo que no cifrarlos, si un "hacker" o empleado con acceso a esa Base de Datos consigue esa clave ya está descifrado todo). Como pega añadida, esto de usar una clave que elija el usuario (y que supuestamente sólo sabe él) en lugar de una aleatoria que se almacene en algún sitio (móvil no puede ser, servidor/"nube" podría ser pero quien tenga acceso a ese servidor tendría todas las claves y seguramente accesibles con nombres: que quiero "Lawrence" busco la clave de Lawrence y zas la tengo)... como decía, usar la clave que elija el usuario tiene otra pega añadida: que los usuarios eligen claves malas, es decir, se delega una parte importante en los usuarios que no son expertos en seguridad. Así que con un ataque de diccionario o probando claves populares (123456, etc) tendrías acceso a muchas cosas cifradas.
RESUMEN: no es posible tenerlo todo... si tenemos un sistema como la nube es complicado que sea 100% seguro: o bien confiamos la seguridad a los empleados (de Apple, Google... lo cual implica acceso a NSA y demás) o bien a los usuarios. Y cada elección tiene unas implicaciones: tanto en posibles fallos de seguridad como en carga que los sistemas que los haría más lentos y/o más caros. Apuesto a que la mayoría de sistemas de ficheros de la nube son sin cifrar, al menos algunos de esos ficheros, especialmente los que se comparten. Ejemplo práctico: Jennifer Lawrence se hace unas fotos en tetas, pero se supone que no se las hace para ella misma para ponerse cachonda mirando su cuerpo, que lo tendrá muy visto todos los días, se supone que esa foto se la enviará a un amigo o dos... desde el momento que otra persona puede ver esa imagen ya la imagen habrá sido descifrada. Pensemos en formas de enviarla: una de ellas es dar permiso a un usuario para acceder a un fichero o carpeta de la nube... pero ese fichero no podrá estar cifrado con el password de Lawrence ya que si no la otra persona no podría verlo así que o bien la nube lo tiene descifrado para que cuando el otro acceda pueda verlo... o bien lo cifra con la clave del destinatario, pero esto último es imposible ya que la clave del destinatario sólo puede saberla el destinatario y en caso de tener Apple dicha clave un empleado de Apple podría verlo.
MI CONCLUSIÓN: de las opciones planteadas parece ser que la habitual en estos casos (ficheros en la nube) es delegar en empleados (que no da problema si el usuario olvida la clave, etc)... así que basta un empleado que tenga acceso a eso para romper la seguridad.
Vamos, que cifrado puede haber (probablemente lo haya hasta cierto punto) pero a mi modo de ver no puede ser superseguro como el que usas al conectarte a tu banco... por las razones que dije.
#117 #99
Lo de la teoría de la "colección privada de un hacker" sólo es desviar el asunto... ¿cómo consiguió ese hacker (que puede ser otro distinto al que lo ha publicado) esa colección privada de más de 300 fotos supuestamente todas de famosas y en su gran mayoría bastante comprometidas? ¿contrató a un ejército de hackers? (lo dudo, por varios motivos) Si no los contrató ¿se trata de un club gigante de hackers para hacer delitos? También lo dudo, entre otras cosas se trataría de una organización criminal, que sería más grave, pero no sólo eso sino que al meter en el asunto a muchas personas tienes que estar seguro de que ninguno de ellos te va a denunciar. Recordemos que en el caso de Scarlett Johannson le cayeron 10 años de cárcel, me parece raro que un supuesto hacker, experto en seguridad caiga en ese error de depender de tantas personas para un asunto ilegal. Bueno, alguien puede pensar que esa organización criminal se podría hacer de forma que los integrantes sean anónimos... No se, me parece como poco rebuscado y siendo todos anónimos mayor razón aún para desconfiar de que uno lo pueda comunicar a las autoridades alertando a las víctimas objetivo de los ataques.
De lo dicho en la parte de arriba se deduciría que más que "colección privada de un hacker" sería en todo caso más bien una "colección privada de un empleado"... y, quizá, en un descuido de ese empleado, otra persona (hacker o no) accedió a esa colección y la publicó.
#6 #172
Yo me inclinaría por algo mucho más fácil. Ha conseguido de alguna forma las direcciones email de N famosas y ha hecho un ataque de phishing por email suplantando la web de apple.
Y las que han picado son las que salen en la lista de las filtraciones.
O también se me ocurre que sea el programador de alguna aplicación de moda de las que te piden acceso a la galería...
Ojo, por si no ha quedado claro es mi opinión personal.
#99 Un trabajador de la empresa?
No debería poder.
#99 ¿Hacker? Más bien oficinista de la NSA.
http://www.huffingtonpost.com/2014/07/17/nsa-nude-photos_n_5597472.html
#2 Tampoco nos pasemos, mucha gente en Internet y en algún medio habló de la pérdida de Dennis Ritchie. Sin embargo, del que nada se leyó fue de John McCarthy que murió dos semanas más tarde, y aquello sí que dio bastante lástima ya que a nivel de relevancia (influencia a largo plazo) estuvo al nivel de Ritchie o incluso por encima. A Dios rogando y con el mazo dando.
#10 Sí. Fue un poco carambola todo.
Como siempre, en este país vamos por modas. Más que Canon (5DMII, 7D, etc.) o la GH1 la revolución de verdad ha sido la Panasonic Lumix GH2. Véase como ejemplo la segunda película del director de Primer, Upstream Color, hecha íntegramente con ella: http://www.eoshd.com/content/10309/gh2-shot-sci-fi-upstream-color-breaks-300000-mark-at-the-us-box-office
Lo realmente interesante fue que desde el momento en que se logró hackear su firmware, surgió todo una scene de cómo hacer que las modificaciones del firmware fueran cada vez mejor (un poco al estilo open source) hasta exprimirla al máximo: http://www.personal-view.com/talks/categories/hacks
Hasta tal punto que en alguna entrevista con gente de Panasonic, ellos mismos reconocen que el hecho de que exista gente que modificando el software lleve su hardware a sus límites es algo positivo: http://www.eoshd.com/content/6810/panasonic-talk-gh2-hack-committed-to-video-on-gh3
Gracias a los japos, algún día la realidad superará a la ficcion...
#10 WTF????
#50 #51 Pues yo aquí veo una sección de virus: http://en.wikipedia.org/wiki/Linux_malware
#5 Es la tercera en todo caso, y las otras dos son más que decentes. Además eso de "hacer esperar" no es una regla en los Oscars para nada, véase como contraejemplo a Behn Zeitlin que está recién salido del horno como quien dice.
#1 tu sabras tus valores morales, peró no es lo mismo agredir y pegar hostias que meter papeles en cajas de plastico.