¿Es posible "hackear" una MacBook para poder instalar macOS Mojave?

Sé que puedes hackear un iPhone, pero ¿hay alguna manera de "hackear" una Macbook? Tengo un modelo de finales de 2010 que se actualizó, por lo que tiene RAM, espacio en el disco duro, etc. y funciona maravillosamente, pero realmente me gustaría instalarle Mojave. Puedo descargar el archivo de desarrollador, pero luego iTunes Store para Mac me dijo que no es compatible con este modelo.

En primer lugar, si un iPhone no es compatible con una versión de iOS, no hay forma de instalar esa versión de iOS en ese iPhone.
Existe una rica comunidad que se especializa en instalar versiones no compatibles (más nuevas) de macOS en hardware antiguo. A menudo requiere piratear el propio instalador. Eso no es algo que generalmente hacemos aquí.
En primer lugar, ¡bienvenido a Ask Different! :) ¡Espero que encuentres en este sitio un recurso valioso! Si no le molesta que lo diga, aunque entiendo su deseo de instalar macOS Mojave, actualmente es un producto beta. Si tiene una MacBook que funciona maravillosamente y depende de ella a diario, realmente no quiere correr el riesgo en esta etapa. Como mencionó @SteveChambers, hay una comunidad rica que se especializa en este tipo de cosas, por lo que si se puede hacer, habrá una solución alternativa (o "truco") disponible en algún momento, pero recomendaría esperar incluso eso. para ser probado.
Sé que a veces puede ser difícil dejarlo ir, pero tal vez sea hora de pasar a una Mac más nueva :) Apple considera que la MacBook 2010 es "obsoleta".

Respuestas (5)

macOS Mojave requiere compatibilidad con Metal . Se justifica que Apple impida la instalación en modelos más antiguos porque, literalmente, no tienen la capacidad de renderizar la GUI .


Editar : un voto positivo reciente me ha recordado esta respuesta. Estoy agregando esta sección para decir que la imposibilidad de ejecutar Mojave no es del todo el caso. Mojave todavía tiene renderizado de software para el modo de recuperación. La respuesta de AnyOS'll Do no es del todo incorrecta, a pesar de que la mayor parte de la respuesta es supuesta.

Esta respuesta se vincula a una herramienta que ya existe (que me ha llamado la atención antes, aunque no pensé mucho en ella) para permitir la instalación de Mojave en Mac no compatibles. El único inconveniente es que la aceleración de hardware se desactivará, ya que se eliminó la aceleración de hardware para las GPU antiguas.

"Eso es hasta que un genio en github decide crear un envoltorio opengl que interrumpe las llamadas de metal. Mi opinión es que Apple está haciendo para forzar actualizaciones de hardware y propagar #MeTooGFXLibrary. Literalmente SÍ tienen la capacidad de mostrar el modo "oscuro" en cualquier cosa que elijan, después de todo, tienen el código fuente. Otra opinión es que eliminar el soporte de opengl/cl no tiene nada que ver con el rendimiento, la estabilidad o el esfuerzo de ingeniería, sino puramente con las ganancias. La codicia pura y simple explica*"

Lo que escribió aquí es una sinopsis decente con la información que ha estado leyendo por otros en general, ya que está de moda y es popular odiar todo lo que hace Apple sin recopilar ninguna investigación o evidencia real. Te estás perdiendo detalles muy importantes que descartan casi todo lo que afirmas, ya que fue formulado por una colección de información errónea de personas que repiten como loros conclusiones infundadas basadas en otros loros.

  1. Los Macbook más antiguos son demasiado antiguos: esto es completamente correcto, Apple ha reescrito la mayor parte o la totalidad de la GUI, The Quartz 3D Compositor y CoreAnimation en Metal (Básicamente, todo el escritorio ahora está acelerado por Metal y esto solo crecerá con el tiempo). Actualmente, las Macbooks más antiguas con Intel iGPU no son compatibles con Metal API, ya que ni siquiera pueden usar todas las llamadas básicas de Metal API en la versión V1.0. Actualmente, High Sierra se envía con el antiguo compositor OpenGL Quartz y los nuevos Compositores Metal V2. Puede ver instantáneamente en qué tipo de lío estarían si mantuvieran ambas API 3D (incompatibilidades en todas las nuevas funciones avanzadas, mayor mantenimiento de todos los marcos que ahora deben escribirse dos veces para cada API = es igual a más errores, mayor consumo de energía y menor estabilidad mediante el cumplimiento de la variación del hardware).

  2. Envoltura de Metal a OpenGL: en primer lugar, estos componentes de OSX no son de código abierto, por lo que esto nunca llegaría a ninguna parte y, en segundo lugar, esta es una idea terrible ya que está tomando una API que se comunica directamente con la GPU con funciones escritas personalizadas, entonces sería no hay forma posible de que una API de alto nivel como OpenGL pueda pasar esa información directamente a la GPU (no es así como funcionan estas API más antiguas). Además, dado que ya nadie confía en OpenGL, se esfumará y se pudrirá ya que Khronos trabaja en la API de Vulkan ahora, nunca más avanzarán en OpenGL, por lo tanto, es una mala decisión permanecer en esa API.

  3. "MeTooGFXLibrary" Si investigaste estas API de bajo nivel, descubrirías que la API Metal de Apple apareció antes que Vulkan y D3D12. Entonces, en este caso, el campo "MeTooGFXLibrary" se referiría tanto a Vulkan como a M$ D3D12 por jugar la carta "The Me too" siguiendo y copiando la nueva dirección de Apple en tecnología 3D*. (De hecho, Apple completó la API de Metal y la lanzó al público en dispositivos 1 año antes de que se anunciara Vulkan. Cuando Vulkan estuvo listo para lanzarse y usarse en juegos, Apple ya había reescrito la mayoría de las capas de gráficos en OSX con aceleración de Metal que se utiliza en OSX Sierra.

*Esta propaganda se centró en la carrera de API de bajo nivel de la computadora personal, en realidad fue Sony con su API de bajo nivel "LibGCM", incluida en los kits de desarrollo de PS3, lo que sorprendió a casi todos los desarrolladores de juegos por cuánto más control, libertad y rendimiento. entregado que hizo casi todo lo demás inútil. Este evento aquí inició el movimiento de este tipo de API al mundo de escritorio.

  1. "SÍ tienen la capacidad de renderizar el modo "oscuro" en cualquier cosa" Sí, ciertamente pueden, pero esta no es la característica principal ni el motivador.

  2. "caer el soporte de opengl/cl no tiene nada que ver con el rendimiento, la estabilidad o el esfuerzo de ingeniería y se trata simplemente de ganancias". A estas alturas, espero que cualquiera que lea esto haya comprendido que ya demostré varias veces cómo la eliminación de OpenGL aumentará, sin duda, el rendimiento en un margen muy grande en todos los marcos gráficos y, al menos, mantendrá su perfil de estabilidad actual.

Más allá del alcance de esta respuesta para enumerar la lista completa de componentes que dependen de Metal, la mayoría de las personas se han dado cuenta de cuán grande es el mantenimiento de una API y cuántos otros OS Frameworks dependen de ella para funcionar. Está conectado a casi todo con lo que está interactuando, desde dibujar animaciones 2D, fuentes Anti-Aliasing, dibujar transparencias, acelerar el renderizado de video, aplicar efectos de video, renderizar formas y capas, cálculos matemáticos pesados, compresión de video, permitiendo que su navegador web acelere renderizando su propio lienzo...

está básicamente en todas partes y para mantener y usar el OpenGL obsoleto/de bajo rendimiento y administrar una base de código separada masiva para un equivalente de OpenGL de todo lo que su sistema operativo está acelerando sin soporte para ninguna de las adiciones de aceleración avanzada que se siguen agregando en el lado de Metal de cosas.

Ningún usuario preferiría un rendimiento débil y menos funciones, luego descubre que la mayoría de los programas de terceros que aman y usan comienzan a negarse a incluir la aceleración de OpenGL debido a la economía, las personas atrapadas en ese hardware antiguo tendrán dificultades para moverse por Internet y cargar google maps en ese punto...

Aunque creo que esta decisión fue motivada por la codicia/bloqueo de desarrolladores:

Desaprobación de OpenCL por parte de Apple y renuencia a adoptar la API de Vulkan.

Una persona llamada "dosdude1" creó una utilidad que descarga una copia del instalador de Mojave de Apple (versiones Sierra y HSierra disponibles), graba la imagen en un dispositivo USB y le aplica parches para que se pueda iniciar en Mac no compatibles. cualquier Mac con una CPU penryn es compatible (SSE4.1). ya que la suya es una MacBook 2010, por lo tanto, puede ejecutar Mojave sin problemas. asegúrese de leer correctamente su documentación antes de intentar hacer algo para no perder el tiempo en un ciclo de confusión. En cuanto al revestimiento de metal. si tu Mac no soporta metal (claro). OpenGL todavía existe en Mojave y aún puede usarlo para renderizar todo a través de controladores que posiblemente se copiaron de una instalación de High Sierra: https://www.youtube.com/watch?v=5uyYVCiYFuE

Catalina 10.15.x: http://dosdude1.com/catalina/

Mojave 10.14.x: http://dosdude1.com/mojave/

H Sierra 10.13.6: http://dosdude1.com/highsierra/

Sierra 10.12.6: http://dosdude1.com/sierrapatch.html/

macOS H Sierra

Hay una comunidad rica y activa en los foros de MacRumors dedicada a este tema. La conversación gira principalmente en torno a la herramienta dosdude1 mencionada anteriormente. foros.macrumors.com/threads/…

Parallels hace exactamente lo que quiero. Así que creé un host mínimo y ahora ejecuto todo en paralelos vm. ¡SSD lo hace rápido y las llamadas de metal a OPENGL! son realizados por paralelos directamente. Por lo tanto, se puede hacer y funciona sin problemas con un gran soporte para juegos.

No estoy convencido de que ejecutar Mojave en una VM en una MacBook 2010 sea una solución viable a la pregunta. Solo tiene 2 núcleos en un Core 2 Duo.

literalmente no tiene la capacidad de renderizar la GUI

"Eso es hasta que un genio en github decide crear un envoltorio opengl que interrumpe las llamadas de metal. Mi opinión es que Apple está haciendo para forzar actualizaciones de hardware y propagar #MeTooGFXLibrary. Literalmente SÍ tienen la capacidad de mostrar el modo "oscuro" en cualquier cosa que elijan, después de todo, tienen el código fuente. Otra opinión es que eliminar el soporte de opengl/cl no tiene nada que ver con el rendimiento, la estabilidad o el esfuerzo de ingeniería, sino puramente con las ganancias. La codicia pura y simple explica esta decisión".

Escribí lo anterior en ese momento disgustado por el movimiento perpetuo para desaprobar el hardware en esta época que todavía tiene mucha vida por delante. Espero que puedas apreciar que el envejecimiento es una parte natural de la vida, no desaprobamos eso, ¿verdad?

Entonces, puede que no sorprenda a algunos que una persona como yo pueda ser lo suficientemente apasionada como para preocuparse no solo por mi hardware, sino también por el hardware de los demás. Es lo que hago, soy bueno en eso. Además, el medio ambiente es realmente el factor más importante aquí si debemos ir por la madriguera del conejo.

Apple son los líderes de donde considero la dirección del sistema operativo para ir avanzando hacia el futuro. Estoy de vuelta vendiendo en esto. Soy un ávido viajero de los sistemas operativos y, si tuviera que odiar algo, serían las abominaciones que son Windows 8 a 10.

Esta necesidad de que todos los sistemas operativos se vean iguales (te estoy mirando ubuntu) es simplemente desagradable. ¿En cuanto a mi artículo de opinión personal anterior? Pura anécdota, tengo un MBP2011 y no puedo permitirme uno nuevo en este momento, así que eso es todo. Me alejaré de Apple una vez que el soporte para high sierra caiga y seguiré la ruta de un * nix sabor del mes que deseo probar. Mantenerme a la vanguardia siempre es la mejor opción para mí, en lugar de estancarme en un sistema operativo en este dispositivo. He sido quemado por Apples ios 32bit a 64bit depreciación que eliminó +70% de mi biblioteca de juegos "pagada" (es decir, no freemium crap), porque soy el imbécil al que le gusta tener cosas y mantenerse actualizado, no puedo volver cuando uno adopta demasiado pronto.

¿Para responderte sobre tendencias? Hago el mío, gracias. Soy lo suficientemente inteligente y lo suficientemente feo como para no dejarme llevar por tu mentalidad en tales asuntos. Admito que me apresuré, pero tengo una razón apasionada para hacerlo, anecdóticamente. Mi opinión puede coincidir con la de otros, pero estoy seguro de que los desarrolladores de MAME y WINE estaban bajo el fuego de todas las tortugas saltando de un lado a otro de Donkey Kong como cuando intentaban subirse a los hombros de las plataformas que abrían para los demás. Al principio. Entonces, sí, creo que tu absurdo de ejecutar ciclos de cpu/gpu más altos es un desafío para sortear, no un pico en el camino para morir.

He editado los insultos fuera de esto. Damos la bienvenida a las críticas y opiniones obtenidas. ¿Alguien puede poner alguna referencia de adiciones de código abierto para respaldar cualquier código de gráficos que se remonte a la Mac original? Claramente, con suficiente dinero, cualquiera puede hacer que el código se ejecute si la velocidad no es un problema. Si es lo suficientemente eficiente como para representar un cuadro por segundo es la verdadera pregunta.
Más importante aún, este es un comentario sobre otra respuesta y no una pregunta. A menos que esto se edite para responder directamente a la pregunta, es posible que deba moverse a una sala de chat o eliminarse. Con el fin de fomentar una mejor respuesta que sea cortésmente crítica, veamos si esto puede reforzarse con algunos ejemplos concretos o citas para que las opiniones aquí puedan evaluarse y votarse.
No hay "genio en github" a partir de ahora. Entiendo que esto es posible, pero ahora mismo nadie lo ha hecho todavía.