#23
Esa tipa ha fundado su propio partido catalanista/xenófobo asi que no metas a todos en el mismo saco.
"El nacionalismo español, como nacionalismo que es, es supremacista y racista. Solo hay que ver el discurso de sus lideres, desde los ideólogos hace mas de un siglo hasta los lideres politicos de las ultimas décadas"

#23 No como el espanyol?

#23 Tiene que ser jodido eso de no poder olerse los propios pedos.

#43 Esto no es Reiki. En unos años esta tecnología estará en todas partes, cuanto mejor español hablé mejor.

Dentro de unos años tendrás que hablarle a uno de estos para consultar temas de la administración, o lo que dice #44, y vas a querer que sea preciso a la hora de hablar y de entender.

Otra cosa es que pase lo que comenta #42, que haya un mal gasto.

#54 no, el Reiki era de otro partido de izquierda ya convenientemente para algunos desaparecido. Estos son los de la neurona.

#58 Sólo tu te entiendes.

#59 NO todos entendemo perfectamente lo que dice #42

Lo que no entienden son los que miran para otro lado , o los que se aprovechan de la situacion

#137 Revisa tu comentario, qué te estás descalificando a ti mismo.

#60 Tienes razón, perdona. En todo momento me estaba refiriendo a un mac de 2015, no de los nuevos con M1. Imagino que Davinci Resolve irá como un tiro con el M1.

#58 no, con un Mac de late 2015 con un intel core i7

#59 Pues eso. Que en referencia a lo que decías en #30, la mejora de M1 con respecto a CPUs anteriores en edición de vídeo no sólo es un tema de FCPX sino que se aplica a otras aplicaciones no desarrolladas por Apple.

#60 Tienes razón, perdona. En todo momento me estaba refiriendo a un mac de 2015, no de los nuevos con M1. Imagino que Davinci Resolve irá como un tiro con el M1.

#37 yo no he tenido una buena experiencia editando con Davinci Resolve. Para tema color y toque final sí, pero a trancas y barrancas. Al menos en un Mac que normalmente se usa para desarrollar apps móviles y web con IDE’s pesados (basados en Java)

#55 Con un M1?

Yo con el M1 he podido editar y hacer corrección de color (incluyendo reducción de ruido) en 4k con reproducción en tiempo real. Con ningún otro Mac lo había podido hacer.

#58 no, con un Mac de late 2015 con un intel core i7

#59 Pues eso. Que en referencia a lo que decías en #30, la mejora de M1 con respecto a CPUs anteriores en edición de vídeo no sólo es un tema de FCPX sino que se aplica a otras aplicaciones no desarrolladas por Apple.

#60 Tienes razón, perdona. En todo momento me estaba refiriendo a un mac de 2015, no de los nuevos con M1. Imagino que Davinci Resolve irá como un tiro con el M1.

#46 Las CPU que fabrica Apple deben pagar licencias a ARM, que por así decirlo es la "dueña" de la arquitectura. No creo que esta compra les afecte mucho, excepto que quizás Nvidia pase a tener una mejor posición a la hora de venderles GPUs para sus Mac. Hay que recordar que al menos en portátiles van a pasar a utilizar CPUs ARM y ahora mismo están utilizando GPUs de AMD.

#53 Apple (y otras como Intel) tiene con ARM lo que se llama una licencia perpetua de arquitectura, lo que le permite tener acceso al set de instrucciones. El diseño de Apple Silicon se basa en el set de instrucciones y no en el diseño de ARM, por lo tanto decir que "van a pasar a utilizar CPUs ARM" es impreciso: van a pasar a utilizar sus propias CPUs. Que ahora mismo estén utilizando GPUs de AMD es irrelevante porque con toda probabilidad las GPUs de los nuevos Mac no van a ser Nvidia, AMD o ARM sino que van a ser parte del mismo SoC, igual que en el iPad o el iPhone.

#46 Aunque en temas de GPU, al que hace referencia #24, Apple seguro no depende para nada de GPU dado que las diseñan internamente. Samsung sigue usando Mali, que son los diseños de ARM en sus procesadores: https://www.samsung.com/semiconductor/minisite/exynos/products/all-processors/ . Qualcomn con sus diseños de GPU Adreno están como Apple.

Pero de todas formas, Samsung y Qualcomn siguen usando bastante diseños de ARM en sus procesadores. Y Apple, que probablemente sea el que más costumiza las cosas, sigue usando el juego de instrucciones diseñado por ARM en sus procesadores. Hay bastante propiedad intelectual que todas estas compañías están pagando a ARM, que sigue siendo válida bajo los contratos actuales. Pero modificaciones futuras puede que signifique para Apple diseñar desde cero un sistema de instrucciones de procesador con compiladores asociados, etc... no algo que no puedan hacer, un coste extra. Eso sin entrar en diferentes batallas legales donde unos y otros intenten ver cuan de diferente son sus nuevos diseños con instrucciones nuevas con respecto a los antiguos para considerar que no deben seguir pagando propiedad intelectual a Nvidia.

#111 habla de la pandemia, se entiende perfectamente.

#130 En qué segundo exactamente?

#32 bueno sí. Hagan lo que hagan alguien se hubiera quejado. Si mañana hicieran móviles a 100 euros también se quejaría alguien

#37 Si, ese sería el precio de la caja y el cargador...

#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.

#31 No si la reducción se entiende perfecto, el "concepto", pero pillar "cómo" lo está haciendo el lenguaje es más complicado.

#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.

#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 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.

#31 No si la reducción se entiende perfecto, el "concepto", pero pillar "cómo" lo está haciendo el lenguaje es más complicado.

#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.

#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....

#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.

#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.

#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....

#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.

#1 #3 Yo entiendo que es más legible si has estudiado algún lenguaje de programación declarativa. Si no lo has hecho, no estás acostumbrado a esa sintaxis, con lo que te tienes que parar a ver que demonios está haciendo el código, cosa que no te pasa con un "bucle for de toda la vida"

#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?

#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 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

#10 Sí. Fue un poco carambola todo.