Jump to content

Andropov

Usuarios Activos
  • Posts

    1815
  • Joined

  • Last visited

  • Days Won

    1

Everything posted by Andropov

  1. Me uno a la pregunta. Entiendo que es una situación complicada, así que lo que podamos hacer por echar una mano...
  2. Grand Central Dispatch, la librería de Apple para gestionar tareas multihilo en aplicaciones nativas. Creo que se introdujo en Snow Leopard. Y ahora hay unas cuantas mejoras propuestas para Swift ¿6? también sobre la gestión de tareas asíncronas y multihilo. Supongo que Apple sabe que es posible que no quede otra que mejorar sus CPUs a base de añadir más y más núcleos (porque la mejora del 30% en monocore año tras año es difícil de mantener) y eso requiere que las aplicaciones estén preparadas para trabajar con varios hilos, y las librerías para controlar eso (como GCD) pueden ser una tecnología clave en el futuro. Yo también pensaba eso, pero parece que a Adobe le gusta que sus aplicaciones no tengan un "look & feel" propio del sistema operativo en el que están, sino un "look & feel" de Adobe. Lo cual también lleva a que nunca soporten bien las funciones de cada sistema operativo, sino con chapuzas. Pero parece que a Adobe eso no solo no le molesta sino que es lo que buscan. Anda, pues han hecho un buen análisis. No lo había visto. Sí y no. Es cierto que tiene más hardware dedicado a tareas específicas que otras CPUs, pero en alguna medida eso lo hay en todas las CPUs modernas. E independientemente de eso, las tareas que pasan por los núcleos "normales" del M1 son más rápidos que los de Intel igualmente. La memoria unificada es más util para tareas que usan CPU+GPU a la vez, lo cuál hace que la mejora (la que corresponde a la memoria unificada) se note casi únicamente en aplicaciones profesionales. La otra novedad en la RAM es lo de meterla en el mismo paquete que la CPU, pero si no me equivoco la única ventaja con eso es "únicamente" en latencia al hacer las pistas entre la CPU y la RAM más cortas.
  3. Anda! Hace poco me hizo falta instalar otra versión de gcc con Homebrew para poder compilar un proyecto de GitHub que usaba OpenMP. Supongo que tendría algo que ver con esto. Sobre por qué Apple no incluye OpenMP, ni idea. Supongo que intentan forzar en lo posible que la gente use GCD. Suerte que tienen tus alumnos de que les des instrucciones para macOS también. Durante la carrera a mí me ha tocado hasta tener que configurar Wine sobre la marcha en unas prácticas porque hacía falta un programa para Windows y no habían avisado previamente 🙂 Menos mal que ahora cada vez hay más Macs. Bueno, si la única diferencia significativa de rendimiento que ha encontrado es al exportar vídeo en RAW 8K parece que los 8GB de RAM son un mínimo más que aceptable. Con los SSD cada vez más rápidos tener que usar memoria virtual o leer desde disco cada vez tiene menos impacto en el rendimiento (aunque los SSD siguen siendo mucho más lentos que la RAM). Ojo que la RAM no está en el SoC. Sí que está en el mismo paquete, pero no en el SoC. El límite de 16GB podría ser porque necesitarían aumentar los cachés del procesador para que al utilizar más de 16GB no empeorase el rendimiento o porque físicamente no hay chips de más densidad en el espacio que les ha designado Apple en el paquete. Si te fijas en el teardown de iFixit los chips de memoria tienen un espacio determinado y añadir más RAM probablemente requiera añadir más chips (y no chips de más densidad como probablemente hagan en el paso de 8 -> 16GB) y ocupar más superficie en el paquete (o stackearlos en altura). Sea como fuere no creo que se trate de una decisión de negocio para segmentar el mercado. (Lo de la derecha son los chips de la RAM) Y lo de que la RAM esté compartida con la GPU no es nada nuevo, también pasaba con los Macs con gráficas integradas. Además en los programas que utilizan explícitamente la GPU muchas veces se mantiene una copia de las texturas o buffers que está utilizando la GPU en la RAM así que no tiene por qué ser tanto problema como parece. De hecho tiene sus ventajas, no tienes que estar copiando cosas de la RAM a la VRAM constantemente (aunque lógicamente el ancho de banda empeora). Sobre la potencia que tendrán las futuras GPUs de Apple aún no hay nada seguro. Los núcleos de la GPU que utiliza el M1 parecen tener un rendimiento/vatio bastante bueno, y en una GPU pudes aumentar la potencia "solo" con aumentar los núcleos sin demasiado problema, y la potencia aumenta casi linealmente con el número de núcleos que vas añadiendo. Así que nada impide a Apple hacer GPUs de potencia comparable a la de los MBP de 16" (por ejemplo). Lo que habrá que ver si les parece aceptable el consumo que eso implicaría. En las GPUs no llevan tantísima ventaja en eficiencia como en las CPUs. Está claro que dentro de los Macs no van a montar gráficas de terceros, y la duda que queda es si volverá a haber soporte para eGPUs en los Macs con Apple Silicon. Yo creo que sí, aunque no es precisamente la opinión mayoritaria. El soporte para eGPUs es una cosa que han implementado hace relativamente poco y la transición a Apple Silicon ya tenía que estar en marcha desde hacía tiempo. No le veo mucho sentido a que implementen soporte para eGPUs y al año o dos años lo eliminen de los nuevos Macs. Pero ya veremos.
  4. Sí, en principio es el sistema operativo el que "coloca" los hilos en en núcleo que le parece apropiado. Pero me pareció significativo que una función nativa de swift como concurrentPerform ignore completamente el hyperthreading. En principio, ya que controlan el compilador y el SO, si hubiese alguna ventaja en utilizar el hyperthreading en esos casos lo habrían optimizado ya. Además me da la impresión (aunque no sé lo suficiente como para opinar con rigor) de que con la cantidad de cores actuales el hyperthreading cada vez tiene menos sentido. La ventaja principal era que si un hilo llegaba a un momento de stall y no podía continuar con la ejecución (porque estaba esperando a que llegase algún elemento desde la memoria principal, por ejemplo) otro hilo, sus unidades de ejecución (ALUs y demás) quedasen libres para el hilo que estuviese funcionando con hyperthreading y así aprovecharlas mientras el otro hilo está esperando. Pero claro, hoy en día hay procesadores con 8, 12 y 16 núcleos. Si estás ejecutando tareas diferentes probablemente te "sobren" núcleos que utilizar y no tengas que recurrir a uno lógico, y si estás utilizando todos los núcleos probablemente sea porque estás ejecutando alguna tarea altamente paralelizable y es poco probable que los núcleos lleguen a tener momentos de stall como para aprovechar el hyperthreading. Al ritmo al que van mejorando los procesadores de Apple año a año probablemente sea más rentable cambiarlo en 2 años que aumentarle la RAM y SSD ahora. Pero sí, la verdad es que da cosa comprarse un ordenador con la misma RAM y SSD varios años después... Además que la RAM y SSD de Apple tampoco tienen nada de especial, y es una salvajada lo que piden por ampliarlos. Sobre si merece la pena o no la verdad es que no lo sé. Mira a ver cuánto espacio tienes ocupado en disco en tu Mac actual, y echa cuentas. Y con la RAM lo mismo, mira a ver cómo va la presión de memoria en el monitor de actividad en el que estés usando.
  5. Creo que entonces la motivación era conseguir Out of Order Execution e intentar hacerlo con las instrucciones de longitud variable de x86 era inviable. Irónicamente, y si mal no recuerdo, Intel consiguió tener out of order execution antes que nadie. Y es un buen ejemplo de algo que a priori sería más acorde con la filosofía CISC (hacer más por ciclo de reloj) pero que sin embargo pronto adoptaron también muchas arquitecturas RISC (PowerPC y ARM también lo hacen). Sobre lo último que comentas, yo no estaba seguro de si GeekBench usaba sólo los núcleos de la CPU. Para algunas cosas como los tests de Machine Learning que incluye imaginaba que sí (sólo se puede acceder a la Neural Engine usando la librería de CoreML, y no tendría mucho sentido en un test de procesador), pero en otras cosas no estoy seguro. Yo diría que la descompresión usando AES-XTS sí que está acelerada por hardware (en todas las plataformas). Imagino que si está disponible como una instrucción a la hora de compilarlo GeekBench lo usará (acelerando así cosas como AES) pero si requiere una librería del sistema (como CoreML para el Machine Learning) no. Hola jp, cuánto tiempo 🙂 Pues la verdad es que no tenía ni idea de cómo estaba implementado el tema del hyperthreading en los procesadores Intel. Tanto hablar de núcleos "lógicos" y "físicos" nunca me había parado a pensar en cómo estaría implementado en el hardware. Parece que los núcleos "lógicos" duplican los registros pero comparten las unidades de ejecución con otro núcleo. De todas formas a mí esto del hyperthreading nunca me ha dado buenos resultados. Hace no mucho programé una simulación (usando Python compilado a C con Numba) en la que se generaban 16 hilos por defecto (ya que dependía del número de núcleos que reportase la CPU, que en mi caso es un i9 de 8 núcleos con hyperthreading) y una de las cosas que hizo que la simulación fuese más rápido fue... crear sólo 8 hilos. Resulta que el overhead de tener 16 hilos en vez de 8 no se compensaba siquiera por usar los núcleos lógicos. Con otra simulación me pasó algo parecido. En Swift hay una función, llamada "concurrentPerform()" que básicamente ejecuta el bloque de código que le pases, repartiendo las N iteraciones que le indiques en paralelo entre los núcleos disponibles. Y me di cuenta de que al utilizarla sólo invocaba 8 hilos nuevos, no 16. Supongo que habrá otras cosas que sí utilicen el hyperthreading pero para cosas que sean "number crunching" mi impresión de momento es: meh. Y de hecho Apple no ha implementado nada parecido en sus M1. Ah, es que además imagino que en servidores la potencia por vatio también será importantísima. Curiosamente los dos siguientes utilizan la arquitectura POWER9 de IBM, que vienen del desarrollo del que un día salieron los G5 (usaban la arquitectura POWER4 de IBM). Pero sí, totalmente de acuerdo en que será una revolución en el mundo de la informática. O debería serlo, pero ya veremos. La evolución natural sería que algunos PCs también se pasasen a ARM. Pero claro, en Windows aún siguen para algunas cosas con el lío de los 32 o 64 bits, como para decirles que se deshagan completamente de x86/x64 y utilicen una nueva arquitectura en la que nada es compatible de base. Veremos.
  6. Realmente son cosas que se oían más por aquel entonces (supongo vaya, yo ni había nacido 😂) y que dejaron de tener sentido ya a principios de los 2000. Ars Technica hizo un genial artículo sobre cómo el diseño de procesadores se adentraba en un mundo "Post-RISC" y que el término estaba dejando de tener sentido. El artículo (aún válido hoy en día, y muy interesante) es de 1999. Desde entonces la cosa se ha difuminado aún más y no tiene mucho sentido hablar de RISC vs CISC hoy en día. Además, no en este artículo en concreto pero sí en otros, el mismo autor comenta que CISC es inherentemente más rápido que RISC porque según dice más instrucciones disponibles implica mayor rendimiento y algún otro disparate que indica que no termina de entender de lo que está hablando. Mejor no doy mi opinión sobre lo que me parece que le sigan dejando publicar artículos. Varias de las cosas que dice en el artículo son falsas, como lo que mencionas del hardware específico para decodificar vídeo. Es por ejemplo el motivo de que los MacBook de 2016 en adelante puedan usar Sidecar y los anteriores no (no tenían soporte por hardware para HEVC). Irónicamente lo mismo sucede con el ejemplo que pone en el artículo para explicar esto, que habla del soporte para encriptación AES. Eso también está en los procesadores Intel desde hace mucho. Es el motivo por el cual activar FileVault ahora apenas supone una pérdida de rendimiento mientras que en los tiempos de FileVault 1 sí lo suponía (no había soporte para descifrar AES por hardware). Lo que dice después de que los procesadores de Intel descifran los hashes AES utilizando los núcleos normales es otro disparate. También menciona que una de las ventajas de los M1 frente a Intel es la computación heterogénea (esto sí es cierto) pero luego descarrila y dice que en x86 los núcleos han de ser todos iguales y a la misma frecuencia. Esto tampoco es así, los núcleos de Intel no están todos a la misma frecuencia y en principio nada en la arquitectura x86 les impide montar núcleos de alto y bajo rendimiento como hace Apple (o Qualcomm). De hecho, muy probablemente es lo que acaben haciendo. O lo de decir que el M1 no es el procesador más rápido del mercado en monocore, especialmente de forma tan tajante como lo hace, cuando resulta evidente que sí lo es, aún descontando las tareas que en el M1 están aceleradas y en Intel no... Hay más cosas mal, pero no tiene mucho sentido desgranarlo más. Creo que está claro que en general, por cada cosa que acierta, hay dos en las que patina.
  7. Uf. No es el primer artículo que leo de ese autor. Voy a leerlo, pero como sea como el resto...
  8. En principio no tendrían problemas y parece que es lo que harán. Previsiblemente 2 o 4 núcleos Firestorm más. Leía estos días comentar a un ex-ingeniero de AMD que el patrón de diseño que parece estar siguiendo Apple para sus procesadores es el típico en los SoCs: diseñar núcleos que sean independientes de la latencia a componentes externos del paquete (caché, GPU, controladores de memoria) de forma que al crear un nuevo diseño (por ejemplo, con más núcleos) no tengas que rediseñar los núcleos. La otra opción es afinar uno a uno el diseño de cada núcleo para aprovechar que esté más cerca o más lejos de la caché (con la reducción de latencia que eso conlleva), pero cuesta muchísimo más diseñar nuevos procesadores con el mismo diseño general de los núcleos porque no puedes aprovechar todo el diseño. Lo único que tendrán que hacer al aumentar el número de núcleos es aumentar la caché L2 porque con más núcleos para la misma caché tendrían más cache misses y que tirar de memoria más a menudo (y parece que esta es una de las claves del A14/M1 vs la competencia en ARM). Los Icestorm cores probablemente los mantendrán, imagino que estarán activos cuando el Mac esté en reposo (como hace App Nap ahora) gastando mucha menos batería que despertando a los Firestorm. Y en servidores, el rendimiento por vatio es muy importante, así que en los Mac Mini de gama alta tienen un buen incentivo para mantenerlos también. Me sorprendería mucho que los eliminasen, aunque no creo que ningún Mac acabe montando más de 8 núcleos Icestorm. Por cierto, parece que dado que el M1 tiene ocho canales de RAM LPDRR4X debería poder soportar ya 32GB de RAM sin modificación (aunque no esté disponible en los Macs con M1 que han sacado de momento), así que esa (preocupate, al menos para mí) limitación a 16GB no es tal.
  9. Hombre, pero es que es la CPU del MacBook Pro y el MacBook Air básicos. Que esos llevaban un quad core (ni siquiera 4+4) de Intel en la última actualización (o incluso dual core en el MacBook Air). De hecho 8 núcleos en portátil, salvo en el i9, no hay. Ni siquiera en PC, donde lo típico en la franja de 1500-2500€ es el i7 10750H de 6 núcleos. Y de todas formas los núcleos de Apple son mucho más rápidos, que al final es mejor que tener un montón de núcleos pero poco potentes. Aún así, ya llegarán, que está pendiente el M1X para los MacBook Pro 13" de gama alta y los de 16". De momento los resultados de estos benchmarks han estado exactamente dentro de lo esperado, no tiene pinta de que vayan a aflojar con el M1X.
  10. En la review de Anandtech (la mejor, como de costumbre) salen algunos Ryzen. No sé si los nuevos, porque no estoy al día de todas las novedades, pero sí que son recientes.
  11. El cargador que vende Apple para el iPhone es USB-C de 20W y funciona con el cable que viene en la caja (USB-C a Lightning). Yo no me preocuparía demasiado por lo de la vida de la batería y la potencia del cargador. Hay otras cosas, como la función de cargar la batería hasta el 80% por la noche y solo al 100% en las últimas dos horas antes de despertarte que ayudan más con eso.
  12. De hecho, sigue siendo así. Arreglaron el error con iOS 13.7 pero ante cualquier nuevo fallo pasará lo mismo. De hecho, hace unos días alguien abrió un issue en GitHub diciendo que le había llegado una notificación de exposición alta pero que al entrar en la app todo le salía normal... Totalmente de acuerdo. Ha sido un fracaso absoluto, ya no tiene solución.
  13. Sí, tienes razón, no sé por qué pensaba que eran sólo los generados. Respecto a cuánto se usan, hay alguien que está trackeando el uso de la app en GitHub. Por lo que he visto en Suiza el porcentaje está en torno al 20%.
  14. Según entiendo por la noticia el 1,2% no es el porcenataje de positivos introducidos en la app, sino el porcentaje de positivos a los que se les ha asociado un código. Luego, de ese 1,2% de positivos que sí tienen un código asociado, los usuarios lo meterán (o no) en la app cuando se lo comunique el rastreador, si es que tienen la app instalada.
  15. Un monitor de resolución estándar (1080p o incluso 1440p) no se ve ni parecido a la pantalla del Mac. El MacBook utiliza 4 píxeles por cada píxel que usa el monitor, y con unas dimensiones más reducidas, así que se ve todo mucho más "suave". Lo que estarías buscando para tener un monitor con una pantalla de calidad similar a la de tu Mac (que no es fácil) es uno con una densidad de píxeles (ppi) parecida, IPS (amplio ángulo de visión) y P3 (soporte para más colores que el estándar de color sRGB, aunque esto probablemente sea lo menos importante). Así de memoria (estuve mirando hace poco) tienes o los UltraFine de LG (4K en 24" que equivale a ~186 ppi o 5K en 27" que equivale a ~219 ppi) o el Dell P2415Q (4K en 24", ~186 ppi). Cualquiera de ellos es IPS, pero el Dell no tiene gama de colores P3 (los UltraFine sí). Todos tienen un refresco de 60Hz. El resto de monitores suelen ser 4K en 27", que ya tiene una densidad de píxeles bastante más baja (163 ppi), aunque se seguiría viendo notablemente mejor que tu monitor actual.
  16. Qué raro, yo no estoy suscrito y la podía ver. ¿Quizá haya un límite diario o mensual de artículos que se pueden ver? En resumen, hablan de una "brecha de seguridad" y de que Amazon tenía acceso a los "usuarios" positivos y que los "datos" de los usuarios no estaban protegidos de terceras personas. Realmente lo único que estaba expuesto eran las direcciones IP públicas de las personas que subían un positivo a la aplicación (porque los usuarios que no subían un positivo no conectaban con el servidor nunca). Al contactar con el servidor de DNS para resolver la dirección del servidor al que se suben los positivos alguien en la red local podría monitorear el tráfico y deducir que si has establecido una conexión con el servidor en cuestión es porque estás subiendo un positivo. Además, Amazon (que hostea el servidor) puede ver las IPs que se conectan a él y por el mismo motivo deducir que son IPs de positivos. Pero claro, esto a lo que han llamado "brecha de seguridad" que es solo un análisis de tráfico tiene muchas pegas que luego no explican. Amazon solo ve las IPs públicas, y ahora que en España todos los proveedores están usando CG-NAT, esas IPs están compartidas entre varios usuarios y no podrían identificar a personas individuales. Y aunque no fuese así y hubiese una IP pública por cada router, muchos de ellos se comparten (por ejemplo, en la WiFi de una familia) y no podrían saber cuál de todos ellos ha subido el positivo. Y del análisis local del tráfico, que requeriría a una persona físicamente presente en el rango de tu WiFi y conectado a ella, ya ni hablamos...
  17. Bueno el otro día leí en un (disparatado) artículo de El País que sólo en el 1,2% de los positivos Sanidad generaba un código para introducir en la app de Radar Covid. Así que casi que da igual cómo funcione la app, si las administraciones no la usan... (Lo de disparatado lo decía porque el artículo habla de una supuesta brecha de seguridad en la que se habrían estado filtrando todos los datos de los usuarios, que al final resultaba ser que el host del servidor que usa la app (Amazon) puede ver las direcciones IP de las personas que se conectaban).
  18. Otros años no lo tenía, ¿no? A mí me parece un error ligar la pantalla más grande a una mejor cámara. Sobre todo porque ya estamos hablando de tamaños de pantalla que no son cómodos para todo el mundo.
  19. Una pena que el sensor más grande en la cámara de ~24mm se lo lleve solo el iPhone 12 Pro Max.
  20. Esto es una idea horrenda. Tor sólo sirve para anonimizar tu conexión a internet y no para ofrecerte más seguridad. Cualquier nodo de salida de la red Tor puede inspeccionar todo el tráfico que salga de él. Teóricamente seguirías protegido porque los bancos (y la mayoría de internet, realmente) usan HTTPS, pero es un riesgo innecesario no sé muy bien para qué. Tor es precisamente lo que *nunca* deberías usar para conectarte a tu banco. La última vez que tuve que (digamos) auditar una serie de WiFis las únicas contraseñas vulnerables eran, precisamente, las que habían puesto los propios usuarios. Y un par de redes de hace más de una década que sí que tenían la contraseña del operador. Pero actualmente ningún operador configura las WiFis que instala con contraseñas predecibles o vulnerables.
  21. Sí, suena exactamente a lo que dices. De momento no están respondiendo a los issues ni a las PR desde hace días, así que imagino que ahora mismo no habrá nadie asignado. Creo que el problema es solo en iOS, pero no estoy muy al día en las noticias sobre Android. Lo de que se quede en la fecha de actualización a iOS 13.7 es porque se queda en el último momento en el que funcionó. Y el problema parece ser del gobierno. Otras aplicaciones (SwissCovid) funcionan en iOS 13.7 desde el primer día.
  22. Me sorprende porque en la versión subida a GitHub ya están utilizando DPT3 1.2.1, pero la versión de la AppStore está evidentemente desactualizada. ¿Podría ser problema de Apple? Hasta donde he visto hace una llamada a la API de DPT3 que es la encargada de gestionar todo lo de las Exposure Notifications, que no es directamente accesible por las aplicaciones. Simplemente en el código para recuperar la información devuelta por la API tienen esto (ExpositionUseCase.swift): private func tracingStatusToExpositionInfo(tStatus: TracingState) -> ExpositionInfo? { switch tStatus.trackingState { case .inactive(let error): var errorEI = ExpositionInfo(level: expositionInfoRepository.getExpositionInfo()?.level ?? .healthy) errorEI.error = dp3tTracingErrorToDomain(error) return errorEI default: break } switch tStatus.infectionStatus { case .healthy: var info = ExpositionInfo(level: ExpositionInfo.Level.healthy) info.lastCheck = tStatus.lastSync return info case .infected: return ExpositionInfo(level: ExpositionInfo.Level.infected) case .exposed(days: let days): var info = ExpositionInfo(level: ExpositionInfo.Level.exposed) info.since = days.first?.exposedDate info.lastCheck = tStatus.lastSync return info } } ExpositionInfo es la estructura/clase que tienen definida para almacenar los valores devueltos por la API en una estructura más manejable para la aplicación. En esa estructura tienen varias propiedades, una de ellas llamada "lastCheck". En el primer caso (.inactive) no modifica el valor de lastCheck en el objeto ExpositionInfo recién creado. Como no tiene ningún valor y en el viewcontroller de la pantalla de la exposición hay un valor por defecto hardcodeado ("01.07.2020") si no le dan ningún valor a la propiedad lastCheck del ExpositionInfo recién creado (como sucede en el caso .inactive) aparece en pantalla el valor por defecto, "01.07.2020". ExpositionViewController.swift: func expositionDateWithFormat() -> String { if let date = self.lastCheck { let formatter = DateFormatter() formatter.dateFormat = "dd.MM.YYYY" return formatter.string(from: date) } return "01.07.2020" } Bueno y como veis en el primer fragmento de código, en caso de error y no encontrar el estado de exposición actual lo pone por defecto en modo "exposición baja" ("?? .healthy" en el código). Aquí de acuerdo con borjam, lamentable que por defecto en vez de mostrar que no está funcionando falle "silenciosamente" y diga que todo va bien. En los otros casos (si el tracingState no es .inactive) si os fijáis sí que le dan un valor a la propiedad lastCheck ("info.lastCheck = ..." en el código) y por tanto la fecha sí que aparece bien en el código. Así que se ha juntado el que la aplicación no está funcionando en iOS 13.7 / iOS 14b6 (hace 10 días ya...) con que cuando la app falla muestra lo mismo que cuando está funcionando que cuando no.
  23. La mía sigue en "actualizado 30.08.2020". Por cierto, han subido el código de la aplicación a GitHub (justo hoy): https://github.com/radarcovid EDIT: Viendo el código fuente parece que la fecha 01.07.2020 está hardcodeada en el código y es el valor que devuelve cuando no ha conseguido recuperar la fecha de la última sincronización con la base de datos. Vaya, que no se está sincronizando. EDIT 2: Parece que por defecto en caso de error la app muestra "Exposición baja" (aunque no haya podido determinar si realmente es así) y en ese caso aparece la fecha de 01.07.2020 que está por defecto en el ViewController. En mi opinión, una idea regular eso de que en caso de error la app aparezca como si estuviese funcionando bien y no muestre ningún error (más allá de la fecha mal puesta).
  24. A mí me pasa lo mismo en iOS 14.0 Developer Beta 6. Es más, aunque la tenía activada, al entrar a la aplicación hoy después de varios días ha salido un aviso de que las Exposure Notifications no estaban bien configuradas en ajustes (sí lo estaban). Desactivando y activando el switch deja de quejarse pero la última comprobación sigue apareciendo de hace varios días.
  25. La RAM sí que la puedes cambiar, precisamente con una tapa en la parte de atrás (solo en el de 27”). El resto del rediseño, marcos, ventilación... esperarán al iMac con Apple Silicon
×
×
  • Create New...

Important Information

We have placed cookies on your device to help make this website better. You can adjust your cookie settings, otherwise we'll assume you're okay to continue.