I know you can hack an iPhone, but is there a way to "hack" a Macbook? I have a late 2010 model that has been upgraded so it has the RAM, hard drive space etc... and it works beautifully, but I would really like to put Mojave on it. I am able to download the developer file, but then I got told by the iTunes Store for Mac that it is not compatible with this model.
macOS Mojave requires Metal support. Apple is justified to prevent installation on older models because they literally do not have the capability to render the GUI.
Edit: A recent upvote has reminded me about this answer. I'm appending this section to say that an inability to run Mojave is not entirely the case. Mojave still has software rendering for Recovery Mode. AnyOS'll Do's answer is not entirely wrong, despite most of the answer being assumptive.
This answer links to a tool already in existence (that has been brought to my attention before, although I didn't think much of it) to enable installation of Mojave on unsupported Macs. The only catch is that hardware acceleration will be disabled, since hardware acceleration for old GPUs has been dropped.
"That is until some genius on github decides to create an opengl wrapper that interrupts metal calls. My opinion is Apples doing to force hardware upgrades and propagate #MeTooGFXLibrary. They literally DO have the capability to render "dark" mode on anything they choose, they have the source code after all. Another opinion is dropping opengl/cl support has nothing to do with performance or stability or engineering effort and purely about is profit. Pure and simple greed explains*"
What you wrote here is a decent synopsis with the information you been reading by others in general as it's trendy and popular to hate everything Apple does without gathering any real research/evidence. You are missing very important details that dismiss almost everything you claimed as it was formulated by a collection of misinformation from people parroting unfounded conclusions based off of other parroters.
The older Macbook's are too old: This is actually completely correct, Apple has rewritten most/all of the GUI, The Quartz 3D Compositor and CoreAnimation in Metal (Basically the whole desktop is now accelerated by Metal and this will only grow in time). Currently older Macbooks with the Intel iGPU don't support the Metal API as they can't even use all the basic Metal API calls in release V1.0. Currently High Sierra does ship with both the old OpenGL Quartz compositor and the new Metal V2 Compositors. You can instantly see what kind of mess they would be in if they kept both 3D API's around (incompatibilities across all the new advanced features, further upkeep of all the Frameworks that now have to be written twice for each API = Equals more bugs, greater power draw and less stability by means of hardware variation compliance).
Metal to OpenGL wrapper: First of all these components of OSX are not open source so this would never get anywhere and 2nd this is a terrible idea as you're taking an API that directly communicates to the GPU with custom written functions, then would be no possible way a high level API like OpenGL could pass that info directly onto the GPU (that's not how these older API's function). Also since no one is relying on OpenGL anymore it's going to fizzle and rot since Khronos works on the Vulkan API now, they are never going to advance OpenGL anymore, hence it's a bad decision to stay on that API.
"MeTooGFXLibrary" If you researched these low level API's you would find out that Apple's Metal API came around before Vulkan and D3D12. So in this instance "MeTooGFXLibrary" camp would refer to both Vulkan and M$ D3D12 for playing "The Me too" card by following and copying Apple's new direction in 3D tech*. (In fact, Apple had the Metal API completed and released in devices to the public 1 whole year before Vulkan was even announced. By the time Vulkan was ready to release and be used in games, Apple had already rewrote most of the graphics layers in OSX with Metal acceleration being used in OSX Sierra.
*This blurb focused on the Personal Computer low level API race, in reality it was Sony with their "LibGCM" low level API, included in the PS3 dev kits which had almost all game developers shocked at how much more control, freedom and performance it delivered which made most everything else useless. This event here kick started the movement of this type of API to the Desktop world.
"DO have the capability to render "dark" mode on anything" Yep they certainly can, but this is not the main feature or the motivator.
"dropping opengl/cl support has nothing to do with performance or stability or engineering effort and purely about is profit." By now I hope anyone reading this has comprehended that I already demonstrated multiple times on how dropping OpenGL will, without a doubt increase performance by a very large margin across all graphical frameworks, and at the very least hold onto their current stability profile.
Beyond the scope of this response to list the entire list of components that rely on Metal, Most people have came to a realization on just how big the upkeep of an API is and just how many other OS Frameworks rely on it to function. It's hooked into most everything you're interacting with, from drawing 2D animations, Anti-Aliasing fonts, drawing transparencies, accelerating video rendering, applying video effects, rendering shapes and layers, heavy mathematical calculations, video compression, allowing your web browser to accelerate rendering it's own canvas...
it's basically everywhere and to keep and use the weak performing/obsolete OpenGL around and manage a massive separate code base for an OpenGL equivalent of everything your OS is accelerating with no support for any of the advanced acceleration additions the keep getting added on the Metal side of things.
No user would rather weak performance and less features, then find out that most 3rd party programs they love and use start to refuse to include OpenGL acceleration due to economics, people stuck on that old hardware will have difficulty just getting around the internet and loading up google maps by that point...
Although I believe these decision were motivated by greed/dev lock-in:
Apple's depreciation of OpenCL and reluctance to adopt the Vulkan API.
There's a utility created by somebody called "dosdude1" that downloads a copy of Mojave's installer from apple (Sierra and HSierra versions available), burns the image to a usb and applies patches into it so that it's bootable on unsupported Macs. any Mac with a penryn CPU is compatible (SSE4.1). since yours is 2010 MacBook therefore it can run Mojave just fine. make sure that you properly read his documentation before attempting to do anything so that you don't waste time being in a cycle of confusion. As for metal rendering. if your Mac does not support metal (clearly). OpenGL still exists in Mojave and you can still use it to render everything through drivers that were possibly copied over from a High Sierra installation: https://www.youtube.com/watch?v=5uyYVCiYFuE
Mojave 10.14(still in beta): http://dosdude1.com/mojave/
H Sierra 10.13.6 (recommended, works fine on my 2009 MacBook): http://dosdude1.com/highsierra/
Sierra 10.12.6 : http://dosdude1.com/sierrapatch.html/
Parallels does exactly what I want. So I created a minimum host and now run everything in parallels vm. SSD makes it quick and the calls from metal to OPENGL! are performed by parallels directly. So it can be done and runs absolutely smooth with large gaming support.
literally do not have the capability to render the GUI
"That is until some genius on github decides to create an opengl wrapper that interrupts metal calls. My opinion is Apples doing to force hardware upgrades and propagate #MeTooGFXLibrary. They literally DO have the capability to render "dark" mode on anything they choose, they have the source code after all. Another opinion is dropping opengl/cl support has nothing to do with performance or stability or engineering effort and purely about is profit. Pure and simple greed explains this decision."
I wrote the above at the time in disgust of the perpetual movement to deprecate hardware in this day and age that still has plenty of life left in it. I hope you can appreciate that ageing is a natural part of life, we don't deprecate that, do we?
It may then come as no surprise to some that a person like me could be passionate enough to care about not just my hardware, but the hardware of others. It's what I do, I am good at it. Also, the environment is really the biggest factor here if we must go down the rabbit hole.
Apple are the leaders of where I considered the direction of the operating system to go moving into the future. I am back peddling on this. I am an avid traveller of OS's and, if I were to hate on anything, then it would be the abominations that are Windows 8 through 10.
This need for all operating systems to look samey same (I am looking at you ubuntu) is just off-putting. As for my personal opinion piece above? Pure anecdotal, I own a MBP2011 and can not afford a new one at this time, so there's that. I am turning away from Apple once support for high sierra drops and will go the route of a *nix flavour of the month I wish to try. Staying at the forefront is always the best option for me, rather than to stagnate on an os on this device. I have been burnt by Apples ios 32bit to 64bit deprecation which removed +70% of my "paid"(i.e. not freemium crap) gaming library, because I am the sucker who likes to own things and stay updated, can't go back when one adopts too early.
To answer you about trends? I make my own, thank you. I am smart enough and ugly enough to not be herded by your mentality on such matters. I admit I jumped the gun, but I have a passionate reason to, anecdotally. My opinion may coincide with others, but I am sure the devs of MAME and WINE were under fire from all hurdle turtles jumping up and down all donkey kong like when they were trying to stand on the shoulders of the platforms they were opening up for others at the very beginning. So, yeah, I think your absurdity of running higher cpu/gpu cycles is a challenge to get around, not a spike in the ride to die from.