OCLP reintroduces past libraries and Kexts (drivers in Windows parlance KLMs in Linux parlance) into new versions of MacOS. Being that Tahoe/MacOS26 will be the last intel mac, it means that OCLP will not be able to put MacOS 27 onto intel Macs.

Well, thanks to OCPL, at least most intel macs will be supported (on MacOS 26) until fall 2028.

I need to plan accordingly for my Mini late 2018 and Air early 2015

I really hope that, when Apple discontinues the M1 architecture, OCPL can pick up where they left off, and bring new life to those macs with an ARM version of OCLP

you know, the bust that preceded the Intyernet bubble bust of mid 2001

Fixed carriers overinvested in fibre backbone deployments, meanwhile, mobile operators overpaid for 3G spectrum, leaving them with a massive financial burden AND little money to buy telecom kit, which in turn brought down the telecom kit providers...

I lost a great job opportunity because of that...

Anywho... the Datacenter boom, be it for Cloud, AI, or CryptoMining is looking A LOT like that...

A Hyperscaler/datacenter burst is nigh, repent.

?? Hopefully yes

Only downside is that AMD will be collateral damage for this initiative, as many an AMD platform has asymetrical ports. See, for example Framework's AMD 13" and 16"Laptops.

Thank you for chivarlous answer.

If your customer is able and Willing to stay on N-1 or N-2

OR

If they are able and willing to use OCLP

a 2018 MacMini is still a perfectly cromulent machine. Specially the 6 core one.

One has to distinguish between the Linux Kernel, the Linux collective, and specific Linux distros. A 2013 NUC will run RHEL 10 no problem, but earlier NUCs will not, as they Lack the necesary AMD64 V3 instruction set.
https://en.wikipedia.org/wiki/...

Meanwhile NUCs containing processors as late as Broadwell or Zen4 will not work as soon and RHEL decides that they will go to AMD64-V4. Yes, ther will be other distros still supporting AMD64-V3, as right now there are distros supporting AMD64-V2 and older. But the more time progresses, the more obscure those distros will be.

the adequate comparision is not between MacOS (and windows) and the linux Kernel, or between MacOS (and windows) and the linux collective, is between MacOS (and windows) and the more Known and Supported Linux DISTROS (Ubuntu, RHEL & Suse, et al)

If you wanted to throw shade at Linux, you should have talked about DISTROS dropping HW support, instead of the Linux Kernel dropping support. No one is crying for dropped i486 support.

While the linux kernel still support the OG pentium and the i686, Many relevant distros (ubuntu, RH, Suse) dropped 32 bit OS support althogether*, Ditto for Win11.

Meanwhile, RedHat 10 requires AMD64 V3 (meaning 6th gen compared to Win11's 8th gen), V1 and V2, will not run at all....
https://en.wikipedia.org/wiki/...

Having said that, I still think that Linux is more forgiving on old hardware than either Windows or MacOS (but no one tops NetBSD, for what is worth)

* unlike apple, 32 bit APPs still work, even if the OS can not be installed on a 32 bit only machine.

Apple issues security patches only for versions N, N-1 and N-2, but they only guarantee ALL HOLES will be patched in version N. For N-1 and N-2 they reserve the right to decide wich holes will be patched and which ones will not be patched...

From a puerly security standpoint, one is better of on Version N than on version N-1 or N-2.

Let me use myself as an example. My two machines are a MacMini 2018 6 core, and a 2015 Air 13". Due to a desire of UI consistency, both are on version N (the Air via OCPL). This is more secure overall, but less stable for the 13"Air.

As soon as the 2018 goes out of support, I'll stay on Sequioia (i.e. N-1) until even OCLP can not support N-1, so I drop to N2. And then, and only then, change HW.

PS: I Bootcamp to play, with a GTX1070 on a Sonnet box, not ideal, but workable for the time being. Will move from Vanilla Win10 to either Server 2022 or server 2019. A new build will come if/when the current HW goes completely out of support

Thank you OCPL.

I perfectly understand you (and your wife). In a proffesional setting, using OCPL may not be allowed, for certification or liability reasons...

I hope the Dell you guys got is Win11 compatible, and also hope that can be brought to Win12 when the time comes (my guess is a couple of years).

I plan on going back to Windows/Linux, I as Want both RAM and SSD to be upgradeable, and upgradeable with parts from multiple vendors. If, from now to the Time OCPL stops supporting supported MacOS versions on my current HW (MacMini 2018 6 core + 2015 13"Air) apple offers machines with that, I may stay.

I guess apple WANTS to drop support for all intel macs, but I think the legislation of some jurisdiction prenet them to do it. If you read the fine print of most apple support, warranties and legalese, they carve special provisions for California, Turkey, and one or two more... Which is... odd?... to say the least...

So, probably, if this rumour is 100% correct, we have to thank the remianing supported Macs to those jusrisdictions. This also will allow the OCPL crowd to keep the gravvy train rolling for a few more years.

Thank you very, very much for your aid.

This will be hard blow, but hey, it had to come one way or another.

Even though I am certain that OCPL will wring a few more years of updates, I'll remain on sequoia for one year, then on N-1, and in lockstep with my 2015 13" Air , as it is the sweet spot between UI consistency and Security.

Up until now both machines were/are on N.

Qualcomm has been going at it for years in modem Land. Infineon tried to get those 5G modems of the ground, couln's, solt to intel, Intel could'nt either, intel sold to apple.

Apple finaly gets the 5G modems of the ground, they underperform? Of course! Do apple modems have to be the very best? Of course not!

As long as in a few iterations the modems become good enough, will be goos enough for apple...

No, you cannot re-license BSD code as GPL code without express permission from the author.
However, some BSD licenses are compatible with the GPL.

Actually you can. You can fork a BSD project, using a different name, and then close the source, or re-license the code under another license.

The only thing is, if the BSD in question had some attribution clauses, you have to respect those. That's how, a long time ago, Microsoft was able to put the BSD IPv4 Netcode into close source Windows.

Ditto with MIT, apache and ISC

I love FreeBSD, I started using it in 1995, one full year before Linux.

Forget about desktop and small servers use. Both for xBSD and Linux, big server and Embedded is where is at. Desktop/Laptops belongs to Windows and MacOS, and Cellphones belong to iOS and Android...

Well, guess what, HW support for Linux is bigger than for xBSD.

In emebeded, every single SoC maker will make drivers for every single SoC component for Linux, for xBSD, well, not so much, some of them will, some of them will not, which makes more onerous for companies the process of choosing both SoCs and ancillary components if they want to use xBSD.

Meanwhile, in Big Server Land, while the architectures are well supported, the drivers for ancillare components, well, not so much. AI cards, HPC cards, 400Gbps Eth, RAID cards.... some do ship xBSD drivers, some do not.

Unless you are spinning VMs (and paravirtualized ones at that), you will have trouble making xBSD play nice with big iron.

And to top it of, unlike with linux, where companies like RedHat, Suse and Cannonical (and oracle and Huawei and...) offer pro-grade support, there are no such backers for xBSD, yes, there are small players, but nothing with enough traction....

Companies big and small would love to use xBSD, because of the license, not to close the source per se, but rather, to avoid all the drama if/whensomeone in the chain forget to publish the sources, so...

Why the do not do it? Lack of support.

IIRC, they will start posting binaries when the Beta arrives.