Leaderboard

This project is dedicated to Lucy, my lovely little indoor tiger. IntelLucy is an open source driver for the Intel X500 family of 10 GBit Ethernet controllers. Key Features of the Driver Supports Intel X520, X540, X550 and 82598 Ethernet adapters. Support for multisegment packets relieving the network stack of unnecessary copy operations when assembling packets for transmission. No-copy receive and transmit. Only small packets are copied on reception because creating a copy is more efficient than allocating a new buffer. TCP segmentation offload with IPv4 and IPv6. Support for TCP/IPv4, UDP/IPv4, TCP/IPv6 and UDP/IPv6 checksum offload. Large Receive Offload: TCP/IPv4 packet streams are identified by the NIC and reassembled to large packets for handover to the network stack eliminating the overhead of packet header processing. Supports jumbo frames up to 9000 bytes (strongly recommended for 10 GBit/s operation). Designed to work with High Sierra and above. Supports Wake on LAN tagging. Supports hardware VLAN (untested). Support for Energy Efficient Ethernet (EEE) is planned for future releaes. No need for hardware modifications anymore (used to be required for SmalltreeIntel8259x.kext). Compatible with AppleVTD but also works fine with AppleVTD disabled. The driver is published under GPLv2. Current Status IntelLucy has been successfully tested with Catalina, Monterey, Ventura and Sonoma and is ready for use in production systems starting with version 1.0.0. Thanks to jumbo frame support, performance is much better than com.apple.DriverKit-AppleEthernetIXGBE. VLAN support has been fixed and tested in version 1.0.0 and is fully working now. I can't test Wake on LAN because I don't have an adapter with WoL support. Known Issues Try to avoid media with flow control enabled as it might cause repeated connection drops due to transmitter hangs and serious performance issues. For WoL to work you need 4 things: An adapter which supports WoL (only a few X520 adapters support WoL). A mainboard which supports WoL from an add-in card. WoL must be enabled in the UEFI setup. Proper ACPI tables for MacOS to support wakeup. Installation Use OpenCore to inject the driver: Getting the driver A prebuilt binary is available in the download section: https://www.insanelymac.com/forum/files/file/1061-intellucy/ Source code can be found on GitHub: https://github.com/Mieze/IntelLucy Changelog Version 1.0.0 (2024-04-07): Fixed relaxed ordering of PCIe transactions. Fixed and tested VLAN support. Version 1.0.0d9 (2024-03-27): Improved transmit performance. Version 1.0.0d6 (2024-03-20): Added support for Intel 82598. Version 1.0.0d5 (2024-03-19): First public release. IntelLucy configuration Parameters explained The Info.plist file contains a section with configuration parameters ("Driver Parameters") which will be explained in the following section: enableTSO4: Enables support for TCP segmentation Offload with IPv4. Using TSO4 the NIC receives large TCP/IPv4 packets from the network stack to be split up into smaller packets to be transmitted of the network. TSO4 is a major performance feature and required to achieve TCP transmission rates near wire speed. enableTSO6: Enables support for TCP segmentation Offload with IPv6. enableWakeOnAddr: Currently unused. forceWoL: Currently unused. rxBufferSize4k: Use 4KB receive data buffers instead of 2KB buffers. rxCoalescing: Enabled the use of Receive Side Coalescing which is the receive side counterpart of TSO4. The NIC identifies TCP/IPv4 packets belonging to a TCP stream, coalesces them into large packets (up to 64KB) and hands them over to the network stack reducing header processing overhead. Enabling rxCoalescing enforces the use of 4KB receive buffers. µsPollTime10G: Under heavy load receive and transmit interrupts are disabled and the NIC is polled periodically for packets waiting to be processed. This feature greatly reduces CPU load while operating at full speed. The polling period is given in µs and used when 10G Bit/s link speed is established. µsPollTime2G: Same as µsPollTime10G but for link speed 2.5 Bit/s (X550 only). µsPollTime5G: Same as µsPollTime10G but for link speed 5 Bit/s (X550 only) µsRxItrTime: Interrupt throttling is important to achieve high data rates while keeping CPU load low. This parameter determines the minimum timespan between two receiver interrupts in µs. Values below 10 enable adaptive throttling. µsTxItrTime: Same as µsRxItrTime but for the receiver interrupt.

1st beta ... no drama ...

( OCLP 1.4.3 nightly still works 🙃 )

macOS Sonoma 14.5 (23F5049f) Full Installer http://swcdn.apple.com/content/downloads/08/26/052-63603-A_72I9KV9QUS/flhemtlnjiql8wqx40cz7i2i5tjfqt84ny/InstallAssistant.pkg

Done all ok

macOS Sonoma 14.4.1 ( 23E224 ) Full Installer https://swcdn.apple.com/content/downloads/04/13/052-77516-A_4P7VY083DT/83qy3989rsnylxagdmim3owwjdtc33zfe4/InstallAssistant.pkg

👍

Z690 Hack update went well

macOS Ventura 13.6.6 (22G630) Full Installer https://swcdn.apple.com/content/downloads/39/23/052-64249-A_9F709WX21B/y8u836xffflrewihfvnacmy3p4v8rm3w57/InstallAssistant.pkg

Amd kernel patches are doing their job as usual

No issues here

AMD patches still working

👍

Clover 5158 is out. It was compiled in Sonoma 14.4.1 with gcc13.1 and Python 3.12.1, xcode 15.3

Nobody said the update size. I will

The update was successful. 😎

SBM= Disabled Update ok

I have built the very first kernel. It is fully supported. Patch is included. EDIT: I have used the latest patch and have recreated the kernel. Also included is the BootKernelExtensions.kc file. EDIT2: New version based on Shanee's patch. XNU-14.0.0-AnV_R3.zip

With OC Compiled 1.0.0, its all fine too

@Max.1974 Regarding Clover and security, there are no conceptual blockers. The technical ideas of Clover and OC are not so different and not implementing sound SB support really is just a dev decision. And I son’t think they are going to reconsider. The rest I can only address by a history lesson. In 2013 or so, I started submitting changes to Clover - a bit shoddy at first, but it got better quickly. In 2014, I started RE’ing Apple-proprietary EFI extensions. Some time in 2015 or so, I started proposing integrating some into Clover, starting with the boot hotkeys. I got a response akin “Hack cannot support hotkeys because it’s no Mac” at the time, despite providing RE’d headers and implementations. The same year I started talking to The HermitCrabs Lab, so I decided “well, ok, give it to Ozmosis then”. Contributing to both Clover and Oz, I proposed collaborating more and got meddled up in their beef with Slice, who dropped the same ridiculous comments about Oz then as he does now about OC. There were claims Oz stole a lot of stuff from Clover, but once I got access to the repos much later, I could validate first-hand most rather happened vice-versa. Anyway, Oz kept expanding with my RE results, including the bless support that now makes OC support for macOS installers and such seamless. When Vitaly re-appeared in 2017, we tried to get FV2 working with Clover and were faced with serious technical issues from Clover’s side. Around the same time, Clover v3 got proposed and I - yet again - tried to push for a collaboration. Alas, the project leadership was a mess and nothing ever happened. At the same time yet, HermitCrabs wanted to re-do Ozmosis - basically OC v0. Tired of the technical issues with Clover v2, Vitaly acquired the thing and we started bringing the pieces together. And - yet again - we tried to collaborate, basically suggesting to make this Clover v3. At some point, there were talks that Slice may contribute the GUI to OC. What we got instead were no contributions whatsoever and instead the snarky comments about Oz became snarky comments about OC. So when Clover started leveraging OC libraries in 202x, I - yet again - suggested to collaborate. After all, we know our code best. So I made remarks about stuff like how they used our symbol patcher and I was basically told I’m just here to hate on their efforts. Two weeks later, they hit the very issue I warned them of and applied the fix I told them to ahead of time. So, everyone chiming wisdoms about “but there’s always two parties” and “drop the beef”, sorry that I will not try a fifth(!) time to turn this nonsense into something constructive. I think I got more burnout from Team Clover politics than from all OC work to date.

@D3v1L No, I wouldn't do that, because macOS already has its advantages over Windoof!! You just have to have some time to get to grips with the new Sonoma. That's my personal opinion and as a pensioner I have enough time for that 🙂

Apple Secure Boot is the technology used in Macs to verify the integrity of the operating system at boot: boot loader > kernel > system volume snapshot. If this check fails, macOS won't boot. Apple Secure Boot only works during the boot process, once macOS is running it no longer performs any function. Apple defines 3 Secure Boot modes: Full Security: Only allows to boot the installed operating system or another signed version of macOS in which Apple currently trusts. It also checks the integrity of the installed version. If the check fails, the system offers to reinstall macOS or boot from a different disk. Medium Security: Checks that the installed version of macOS is legitimate but not the integrity of the system. Lets you boot any signed version of macOS in which Apple has ever trusted. No Security: other systems or versions different from those mentioned in the secure options are allowed. There are no requirements on the boot operating system. Apple Secure Boot state on Intel-based Macs can be obtained from NVRAM: nvram 94b73556-2197-4702-82a8-3e1337dafbfb:AppleSecureBootPolicy If the variable is found, it can be one of the following: %02 - Full Security Mode %01 - Medium Security Mode %00 - No Security Mode If the variable is not found, Apple Secure Boot is not supported. SecureBootModel with other value than Disabled gives Medium Security, for Full Security you must use ApECID. SecureBootModel and ApECID: with SecureBootModel=Disabled>> no security (%00) with SecureBootModel=x86legacy or any of the valid values >> medium security (%01) with SecureBootModel= any of the T2 values plus ApECID non zero >> full security (%02). Notice that since OpenCore 0.7.2: x86legacy is designed for machines without T2 chip with Big Sur and Monterey j137 doesn't work on Monterey j137 is the recommended value for macOS 10.13.2 through 10.15.x systems older than macOS 10.13.2 must set SecureBootModel=Disabled users who don't want to have Apple Secure Boot for any reason can set SecureBootModel=Disabled, even in Big Sur and Monterey. In summary, these are muy opinions: I appreciate the interest that the Opencore developers have had in making our Hacks as similar as possible to a real Mac, including Apple Secure Boot. I know that it is impossible for everything to be exactly the same, but they have managed to give OpenCore features that very often make me forget that I am using a Hack and not a real Mac SecureBootModel=Disabled does not appear to lower the Hack's security below a required level, at least for personal PCs. SecureBootModel only acts at boot time to check the legitimacy/integrity of the booting system. Another thing is in multi-user environments (business...) where a malicious user can access the Hack to boot it from a device with manipulated macOS. I don't agree 100% with @Slice. There are Macs without T2 that have Apple Secure Boot medium security, for example iMac19,1 with macOS 10.14 or newer. But I do agree with him that having SecureBootModel enabled or disabled has no/little importance in Hacks. Without forgetting that Clover lacks this property and many thousands of users have used it and are using it to full satisfaction.

Security on Apple computers provided by encryption by T2 chip which we have no. So why SecureBootModel is useless for us.

Since it makes us happy, I can't resist it!! 😊

Done

Done too But OpenCore 1.0.0 and with About This Hack==> boot loader Clover think need correction !

Sonoma 14.4.1 (23E224) Update completed no worries. If you're using OCLP Nightly version, you may as well update that to latest version.

@maly70 Try look here Placa sem fio Intel AX211NGW Wi-Fi 6 M.2: CNVio2, Bluetooth 5.3, adaptador de rede Tri Band 2.4/5/6 GHz para laptop compatível com Windows 10/11 (64bit) Linux Chrome OS disponível apenas com CPU Intel 12+ geração 【Interface NGFF (M.2) CNVio2】Esta placa LAN sem fio AX211 está disponível apenas com 12 gerações de CPU e placa-mãe de protocolo M2 CNVio2.

Thank you guys, we not forget donate to the Ukraine cause, thanks a lot for this brilliant and excellent program. In fact its so amazing, because the traditional way to install Windows has many trouble with disks, especially Nvme, and take off, put again, disconnect GPU, etc... This program is affordable and exclusive to make this task easy and softly Amazing Job ! Really !!

I doubt he will ever give up, he's got that ......'Tie me Kangaroo down Sport'........ attitude being a Man from the Land Down under.

...never give up, never surrender, you have a working ventura system, so just treat sonoma as a challenge yet unanswered, a hobby, or like me, a mini-addiction

Added recompression of WIM to ESD or ESD to WIM.

I have built a legacy kernel for Intel/AMD. I have used the Linux opemu edited. Patch is included. Needs testing... EDIT: Corrected build, I had the Darwin kernel version wrong... EDIT2: Added AMD Ryzen family 23 EDIT3: Info for rebuilding the kernel cache is here: https://kernelshaman.blogspot.com/2021/01/building-xnu-for-macos-big-sur-1101.html EDIT4: Fixed trust caches. This now supports the installer decently. EDIT5: Added Intel Merom family. EDIT6: Fix opemu. EDIT7: Fixed kernel. I have reverse engineered some of the missing routines (using KDK and Hopper). The result is a working XNU kernel. The routines are in Reversed.s Also now included in the zip is BootKernelExtensions.kc (kernel cache). EDIT8: New version based on Shanee's patch. There where errors in my patch. I have added the reverse engineered functions and new opemu. Included is BootKernelExtensions.kc XNU-14.3.0-AnV_R5.zip

June 10–14, 2024 View full article

Hi my friends, here it's all ok with native Broadcom Pcie Wireless and Bluetooth device, Model: BCM94360CD. No need use AirportBrcmFixup or BluetoothFixup kexts, just BrcmFirmwareData and BrcmPatchRAM3. Not using OCLP - OTA update fine. AirDrop et all working native. 😉

macOS Ventura 13.6.7 (22G705) Full Installer https://swcdn.apple.com/content/downloads/31/00/052-63709-A_1UWN6UY4QS/tvts64av5xzbd7cj7mfsiv4jlfvue9djvl/InstallAssistant.pkg

If the Open Core change log remains as planned, the next release of Open Core will be version 1.0.0. There's nothing significant about this version numbering, as it is simply the numerical progression from version 0.9.9. As with recent OCLP versions after OCLP 0.9.6, there does not appear to me to be any compelling reason to upgrade to the latest Open Core binaries; however, I will be updating the OC EFI attached to Post #1 only to have an OC EFI for OC 1.0.0.

@eng_redaesm Developers link, get OpenCore-Patcher.app (GUI). https://github.com/dortania/OpenCore-Legacy-Patcher/actions/runs/8326849351 @eSaF has posted the script by @LAbyOne , it works very well but I am not comfortable with a shared app on InsanelyMac whose code is not accessible. It's just a personal opinion.

Here are some benchmark test results comparing IntelLucy (V1.0.0d9) to com.apple.DriverKit-AppleEthernetIXGBE under Ventura. The test machine is the one with the MSI mainboard from my signature. AppleVTD is enabled in both test scenarios. The machine on the other side is my Ubuntu 22.04 LTS server. Both machines are equipped with an Intel X520-DA1 adapter. First, give com.apple.DriverKit-AppleEthernetIXGBE a try. The MTU was set to 2034, the maximum value that com.apple.DriverKit-AppleEthernetIXGBE supports. Note that the IPv4 receive test fails due to the lack of proper jumbo frame support because the Ubuntu server uses jumbo frames. laura@lucy ~ % iperf3 -w 384K -B 192.168.10.202 -c 192.168.10.32 Connecting to host 192.168.10.32, port 5201 [ 4] local 192.168.10.202 port 49937 connected to 192.168.10.32 port 5201 [ ID] Interval Transfer Bandwidth [ 4] 0.00-1.00 sec 801 MBytes 6.72 Gbits/sec [ 4] 1.00-2.00 sec 805 MBytes 6.76 Gbits/sec [ 4] 2.00-3.00 sec 802 MBytes 6.73 Gbits/sec [ 4] 3.00-4.00 sec 799 MBytes 6.71 Gbits/sec [ 4] 4.00-5.00 sec 803 MBytes 6.74 Gbits/sec [ 4] 5.00-6.00 sec 873 MBytes 7.32 Gbits/sec [ 4] 6.00-7.00 sec 837 MBytes 7.02 Gbits/sec [ 4] 7.00-8.00 sec 798 MBytes 6.69 Gbits/sec [ 4] 8.00-9.00 sec 816 MBytes 6.84 Gbits/sec [ 4] 9.00-10.00 sec 798 MBytes 6.69 Gbits/sec - - - - - - - - - - - - - - - - - - - - - - - - - [ ID] Interval Transfer Bandwidth [ 4] 0.00-10.00 sec 7.94 GBytes 6.82 Gbits/sec sender [ 4] 0.00-10.00 sec 7.94 GBytes 6.82 Gbits/sec receiver iperf Done. laura@lucy ~ % iperf3 -w 384K -B 192.168.10.202 -c 192.168.10.32 -R Connecting to host 192.168.10.32, port 5201 Reverse mode, remote host 192.168.10.32 is sending [ 4] local 192.168.10.202 port 49900 connected to 192.168.10.32 port 5201 [ ID] Interval Transfer Bandwidth [ 4] 0.00-1.00 sec 0.00 Bytes 0.00 bits/sec [ 4] 1.00-2.01 sec 0.00 Bytes 0.00 bits/sec [ 4] 2.01-3.01 sec 0.00 Bytes 0.00 bits/sec [ 4] 3.01-4.01 sec 0.00 Bytes 0.00 bits/sec [ 4] 4.01-5.01 sec 0.00 Bytes 0.00 bits/sec [ 4] 5.01-6.01 sec 0.00 Bytes 0.00 bits/sec [ 4] 6.01-7.00 sec 0.00 Bytes 0.00 bits/sec [ 4] 7.00-8.00 sec 0.00 Bytes 0.00 bits/sec [ 4] 8.00-9.01 sec 0.00 Bytes 0.00 bits/sec [ 4] 9.01-10.01 sec 0.00 Bytes 0.00 bits/sec - - - - - - - - - - - - - - - - - - - - - - - - - [ ID] Interval Transfer Bandwidth Retr [ 4] 0.00-10.01 sec 454 KBytes 372 Kbits/sec 5 sender [ 4] 0.00-10.01 sec 0.00 Bytes 0.00 bits/sec receiver iperf Done. laura@lucy ~ % iperf3 -w 384K -B 2a01:c22:bc0d:2000::217 -c 2a01:c22:bc0d:2000::32 Connecting to host 2a01:c22:bc0d:2000::32, port 5201 [ 4] local 2a01:c22:bc0d:2000::217 port 49902 connected to 2a01:c22:bc0d:2000::32 port 5201 [ ID] Interval Transfer Bandwidth [ 4] 0.00-1.00 sec 845 MBytes 7.08 Gbits/sec [ 4] 1.00-2.00 sec 841 MBytes 7.06 Gbits/sec [ 4] 2.00-3.00 sec 835 MBytes 7.01 Gbits/sec [ 4] 3.00-4.00 sec 841 MBytes 7.05 Gbits/sec [ 4] 4.00-5.00 sec 845 MBytes 7.09 Gbits/sec [ 4] 5.00-6.00 sec 820 MBytes 6.88 Gbits/sec [ 4] 6.00-7.00 sec 844 MBytes 7.08 Gbits/sec [ 4] 7.00-8.00 sec 842 MBytes 7.06 Gbits/sec [ 4] 8.00-9.00 sec 842 MBytes 7.06 Gbits/sec [ 4] 9.00-10.00 sec 847 MBytes 7.11 Gbits/sec - - - - - - - - - - - - - - - - - - - - - - - - - [ ID] Interval Transfer Bandwidth [ 4] 0.00-10.00 sec 8.20 GBytes 7.05 Gbits/sec sender [ 4] 0.00-10.00 sec 8.20 GBytes 7.05 Gbits/sec receiver iperf Done. laura@lucy ~ % iperf3 -w 384K -B 2a01:c22:bc0d:2000::217 -c 2a01:c22:bc0d:2000::32 -R Connecting to host 2a01:c22:bc0d:2000::32, port 5201 Reverse mode, remote host 2a01:c22:bc0d:2000::32 is sending [ 4] local 2a01:c22:bc0d:2000::217 port 49904 connected to 2a01:c22:bc0d:2000::32 port 5201 [ ID] Interval Transfer Bandwidth [ 4] 0.00-1.00 sec 1.08 GBytes 9.27 Gbits/sec [ 4] 1.00-2.00 sec 1.08 GBytes 9.28 Gbits/sec [ 4] 2.00-3.00 sec 1.08 GBytes 9.28 Gbits/sec [ 4] 3.00-4.00 sec 1.08 GBytes 9.28 Gbits/sec [ 4] 4.00-5.00 sec 1.08 GBytes 9.28 Gbits/sec [ 4] 5.00-6.00 sec 1.08 GBytes 9.28 Gbits/sec [ 4] 6.00-7.00 sec 1.08 GBytes 9.28 Gbits/sec [ 4] 7.00-8.00 sec 1.08 GBytes 9.28 Gbits/sec [ 4] 8.00-9.00 sec 1.08 GBytes 9.28 Gbits/sec [ 4] 9.00-10.00 sec 1.08 GBytes 9.28 Gbits/sec - - - - - - - - - - - - - - - - - - - - - - - - - [ ID] Interval Transfer Bandwidth Retr [ 4] 0.00-10.00 sec 10.8 GBytes 9.28 Gbits/sec 0 sender [ 4] 0.00-10.00 sec 10.8 GBytes 9.28 Gbits/sec receiver iperf Done. Now it's IntelLucy's turn. On both machines, the Hackintosh and the Ubuntu server, MTU was set to 9000. Let's take a look at the test results: laura@lucy ~ % iperf3 -w 384K -B 192.168.10.202 -c 192.168.10.32 Connecting to host 192.168.10.32, port 5201 [ 4] local 192.168.10.202 port 49428 connected to 192.168.10.32 port 5201 [ ID] Interval Transfer Bandwidth [ 4] 0.00-1.00 sec 1.09 GBytes 9.36 Gbits/sec [ 4] 1.00-2.00 sec 1.09 GBytes 9.38 Gbits/sec [ 4] 2.00-3.00 sec 1.09 GBytes 9.37 Gbits/sec [ 4] 3.00-4.00 sec 1.09 GBytes 9.39 Gbits/sec [ 4] 4.00-5.00 sec 1.09 GBytes 9.39 Gbits/sec [ 4] 5.00-6.00 sec 1.09 GBytes 9.38 Gbits/sec [ 4] 6.00-7.00 sec 1.09 GBytes 9.39 Gbits/sec [ 4] 7.00-8.00 sec 1.09 GBytes 9.36 Gbits/sec [ 4] 8.00-9.00 sec 1.09 GBytes 9.38 Gbits/sec [ 4] 9.00-10.00 sec 1.09 GBytes 9.36 Gbits/sec - - - - - - - - - - - - - - - - - - - - - - - - - [ ID] Interval Transfer Bandwidth [ 4] 0.00-10.00 sec 10.9 GBytes 9.38 Gbits/sec sender [ 4] 0.00-10.00 sec 10.9 GBytes 9.38 Gbits/sec receiver iperf Done. laura@lucy ~ % iperf3 -w 384K -B 192.168.10.202 -c 192.168.10.32 -R Connecting to host 192.168.10.32, port 5201 Reverse mode, remote host 192.168.10.32 is sending [ 4] local 192.168.10.202 port 49430 connected to 192.168.10.32 port 5201 [ ID] Interval Transfer Bandwidth [ 4] 0.00-1.00 sec 1.15 GBytes 9.85 Gbits/sec [ 4] 1.00-2.00 sec 1.15 GBytes 9.88 Gbits/sec [ 4] 2.00-3.00 sec 1.15 GBytes 9.88 Gbits/sec [ 4] 3.00-4.00 sec 1.15 GBytes 9.88 Gbits/sec [ 4] 4.00-5.00 sec 1.15 GBytes 9.87 Gbits/sec [ 4] 5.00-6.00 sec 1.15 GBytes 9.88 Gbits/sec [ 4] 6.00-7.00 sec 1.15 GBytes 9.88 Gbits/sec [ 4] 7.00-8.00 sec 1.15 GBytes 9.88 Gbits/sec [ 4] 8.00-9.00 sec 1.15 GBytes 9.87 Gbits/sec [ 4] 9.00-10.00 sec 1.15 GBytes 9.88 Gbits/sec - - - - - - - - - - - - - - - - - - - - - - - - - [ ID] Interval Transfer Bandwidth Retr [ 4] 0.00-10.00 sec 11.5 GBytes 9.88 Gbits/sec 0 sender [ 4] 0.00-10.00 sec 11.5 GBytes 9.88 Gbits/sec receiver iperf Done. laura@lucy ~ % iperf3 -w 384K -B 2a01:c22:bc0d:2000::217 -c 2a01:c22:bc0d:2000::32 Connecting to host 2a01:c22:bc0d:2000::32, port 5201 [ 4] local 2a01:c22:bc0d:2000::217 port 49432 connected to 2a01:c22:bc0d:2000::32 port 5201 [ ID] Interval Transfer Bandwidth [ 4] 0.00-1.00 sec 1.07 GBytes 9.22 Gbits/sec [ 4] 1.00-2.00 sec 1.08 GBytes 9.24 Gbits/sec [ 4] 2.00-3.00 sec 1.07 GBytes 9.15 Gbits/sec [ 4] 3.00-4.00 sec 1.08 GBytes 9.27 Gbits/sec [ 4] 4.00-5.00 sec 1.08 GBytes 9.26 Gbits/sec [ 4] 5.00-6.00 sec 1.08 GBytes 9.26 Gbits/sec [ 4] 6.00-7.00 sec 1.08 GBytes 9.27 Gbits/sec [ 4] 7.00-8.00 sec 1.08 GBytes 9.27 Gbits/sec [ 4] 8.00-9.00 sec 1.08 GBytes 9.26 Gbits/sec [ 4] 9.00-10.00 sec 1.08 GBytes 9.24 Gbits/sec - - - - - - - - - - - - - - - - - - - - - - - - - [ ID] Interval Transfer Bandwidth [ 4] 0.00-10.00 sec 10.8 GBytes 9.24 Gbits/sec sender [ 4] 0.00-10.00 sec 10.8 GBytes 9.24 Gbits/sec receiver iperf Done. laura@lucy ~ % iperf3 -w 384K -B 2a01:c22:bc0d:2000::217 -c 2a01:c22:bc0d:2000::32 -R Connecting to host 2a01:c22:bc0d:2000::32, port 5201 Reverse mode, remote host 2a01:c22:bc0d:2000::32 is sending [ 4] local 2a01:c22:bc0d:2000::217 port 49434 connected to 2a01:c22:bc0d:2000::32 port 5201 [ ID] Interval Transfer Bandwidth [ 4] 0.00-1.00 sec 1.07 GBytes 9.22 Gbits/sec [ 4] 1.00-2.00 sec 1.08 GBytes 9.27 Gbits/sec [ 4] 2.00-3.00 sec 1.08 GBytes 9.27 Gbits/sec [ 4] 3.00-4.00 sec 1.08 GBytes 9.27 Gbits/sec [ 4] 4.00-5.00 sec 1.08 GBytes 9.27 Gbits/sec [ 4] 5.00-6.00 sec 1.08 GBytes 9.26 Gbits/sec [ 4] 6.00-7.00 sec 1.08 GBytes 9.28 Gbits/sec [ 4] 7.00-8.00 sec 1.08 GBytes 9.25 Gbits/sec [ 4] 8.00-9.00 sec 1.08 GBytes 9.27 Gbits/sec [ 4] 9.00-10.00 sec 1.08 GBytes 9.26 Gbits/sec - - - - - - - - - - - - - - - - - - - - - - - - - [ ID] Interval Transfer Bandwidth Retr [ 4] 0.00-10.00 sec 10.8 GBytes 9.26 Gbits/sec 0 sender [ 4] 0.00-10.00 sec 10.8 GBytes 9.26 Gbits/sec receiver iperf Done. As the benchmark results speak for themself, there is no need for an interpretation. And now the million dollar question: Which one is better? 😼

I confirm you are one commit behind 520c922 " Fix last " ... once the app is opened it shows 1.5 But the last commit is as I wrote before bbc8902 " Add non-Metal support for macOS 14.4 " ... once the app is opened it shows 1.3

@eSaF https://github.com/dortania/OpenCore-Legacy-Patcher/blob/main/CHANGELOG.md I think you're a few commits behind They had continued until 1.5 went back... latest commit bbc8902 now 1.3 🤷 https://github.com/dortania/OpenCore-Legacy-Patcher/actions/runs/8326849351 But you made me doubt...I'll check 😂

Secound test OK on test Branch Workflow is fix Pull Request

Built Citra, it is a better emulator.

Impeccable as always 👌 Nice new interface Lightning fast in preinstalling on nvme 2min12s I know that the app is suitable for working on SSDs Testing on a USB stick the time is 1 hour and something It would be nice to be able to create a "Win to go" USB The backup function completed in 12m17s was very useful I was wondering if it was possible to develop apps for Win too, in order to insert for example it into a live ISO (like Strelec) to restore the system in case of problems Thank you

With Clover all fine with @chris1111 themes, im not test all Linux icons but everething im test is fine

Good night my Dear Friends @chris1111 @Slice et all important people to me I would like to share that I have detected the issues with compiling Clover 5158 or 5157 in Xcode 15.2 and 15.3. Despite Clang having the same version in Xcode 15.1 and Line Tools 15.1 Apple clang version 15.0.0 (clang-1500.1.0.2.5) Target: x86_64-apple-darwin23.4.0 I noticed that Clang doesn't download or install packages correctly from GCC 13.2.0, but even in Sonoma 14.4.1, if we use Xcode 15.1 and Command Line Tools from the same version, that is, 15.1, it will compile with GCC normally. You also need to download GCC via home brew 0"brew install gcc", a necessary condition. I used the code from the Clover Wiki CD ~ mkdir src cd src git clone --recurse-submodule https://github.com/CloverHackyColor/CloverBootloader.git cd CloverBootloader ./buildme Therefore, I come to inform everyone, but I am not an advanced user. I just did a lot of research, and I read that the new version of Clang doesn't have the C++20 package, or something like that. So, dear friends, if you happen to be able to install it on the Ventura, its possible too, just save and copy or add the OPT and TOOLS folders formalized in the Ventura, to src folder on Sonoma. It will compile instantly and finish Clover, even with another Xcode like 15.3. In order to collaborate with coders, I also ask for information if there is any package that we can formalize in the new Sonoma that takes the place of GCC or that makes Clang recognize the installer. It seems to me that the line of code without C++20 was compromised. I ask you if it would be possible to insert all the compilers in another area of the Mac, where we install many packages, such as the /usr/... folder. Thank you all, and I look forward to the noble coders and friends.