daliansky/Hackintosh: A Curated Index of Model-Specific EFI Folders

A directory, not a bootloader

The name suggests a project. It is closer to a library catalogue. daliansky/Hackintosh collects links to EFI folders and installation write-ups that other people published for specific machines, then sorts them into two large tables: laptops by vendor (Acer, Asus, DELL, Gigabyte, Hasee, HP, Huawei, Lenovo, LG, Mechrevo, MSI, Razer Blade, Samsung, Shinelon, Toshiba, XiaoMi, Intel, Other) and desktops by platform (AMD Ryzen, ASRock, ASUS, Dell, Gigabyte, HP, Intel, Lenovo, minisforum, MSI, Mini, and a hardware compatibility list).

Each row carries a model name, a link to a repository holding the EFI, sometimes a link to a tutorial, and a remarks column. The remarks are where the useful detail lives. One Acer Aspire E5-476G row lists three separate links and notes that link 1 is for an i5-8250U while link 2 is an i3-6006U running OpenCore. Another row for an Acer Aspire VX5-591G notes OpenCore and an NVIDIA GTX 1050. Those two facts together tell an experienced reader a great deal about what will and will not work.

The intended audience is narrow and specific: someone who owns a machine that appears in these tables and wants a starting EFI rather than a blank OpenCore configuration. If your exact model is not listed, the repository offers no fallback path. It is an index, and an index is only as useful as its coverage.

What the tables actually contain

The laptop section is dominated by Acer in the portion visible in the README, with dozens of Aspire entries spanning the 3, 5, 7, E1, E5 and A315/A515/A715 families. Vendor headings continue through the other manufacturers listed in the table of contents. The desktop section is organised differently, by CPU platform and board vendor, and ends with a hardware compatibility list.

Two structural details matter. First, many rows link to third-party GitHub repositories rather than to content hosted here. The maintenance burden is therefore distributed: a row can be stale because the upstream EFI repository went quiet, not because daliansky stopped updating. Second, the repository ships a Tools/ directory at the top level alongside Changelog.md, LinkList.md and README.md. The README does not describe what is inside Tools/, so treat it as something to inspect directly rather than something with a documented purpose.

The update log in the README is dated 2026年6月18日 and lists newly added models: Asus X550VQ, Dell Latitude 7410, Dell OptiPlex 7070 MFF and ThinkPad E14 Gen2 AMD. A separate Changelog.md holds the full history. The last push to the repository was on 2026-08-28, so the index is being touched, though that says nothing about whether any individual linked EFI folder is current.

Finding your model and the EFI it points to

There is nothing to install from this repository itself. What you install is macOS, using an EFI folder you obtain from one of the linked per-model repositories. The README is written in Chinese with an English translation at README_en.md, and the model tables are the entry point.

Open README.md or README_en.md and find your vendor heading, then your model row. The row gives you a URL. That URL, not this repository, is where the EFI folder lives, and the README presents it as a link labelled 链接.

The repository's own top-level entries are listed in the README's directory section: Changelog.md, LinkList.md, README.md and Tools/. Once you have the linked EFI, the bootloader family is visible from the folder layout: an OpenCore EFI has an OC/ directory containing config.plist, while a Clover EFI has CLOVER/ with config.plist instead. The README's remarks column sometimes states which one a row uses, and the Acer Aspire E5-476G row is an example where that distinction is spelled out. From there you follow the tutorial linked in the same row, or the upstream repository's own README, to build the installer USB and copy the EFI partition. The index does not walk you through that step, and it does not validate the EFI you found.

Where the index model breaks down

A curated list of third-party links inherits every weakness of the links. A row can point at a repository that targets Big Sur while you want something newer. The topics list on this repository mentions bigsur, catalina, mojave, monterey and highsierra, which tells you the range of eras the collection spans, but not which row covers which. Nothing in the README marks a row as outdated.

Model naming is the second problem. The Acer tables show how granular this gets: A515-51G, A515-52G-58LZ, A515-53G-5269, A515-55 and A515-51G-58VH appear as separate rows, and some rows have no link at all. A machine that differs from a listed one by a CPU generation or a Wi-Fi card may need a different EFI, and the index cannot tell you that. It records what someone published, not what will work for you.

Finally, the index carries no verification. There is no indication that any linked EFI was reviewed, tested by the maintainer, or checked for malicious content. You are trusting a stranger's repository. That is inherent to the model rather than a defect the maintainer introduced, but it is the risk you accept when you use this catalogue.

Alternatives and how they differ

The obvious alternative is building your own OpenCore configuration from the upstream OpenCore documentation and the Dortania guides. That approach is slower and demands that you understand ACPI patching, kext loading order and platform-specific quirks. Its advantage is that you know exactly what every entry in config.plist does, and you can update it when macOS changes. An indexed EFI from this repository is a shortcut past that learning curve, at the cost of inheriting someone else's decisions and their maintenance schedule.

A second alternative is a distribution-style installer that bundles a bootloader and a set of drivers for broad hardware. Those aim at getting any machine to boot and then rely on post-install patching. This repository takes the opposite stance: it assumes a specific model and points you at a configuration built for it. The trade-off is coverage. A distribution-style installer has a path for hardware nobody has written a per-model EFI for; the daliansky index simply has no row.

A third option is community forums, and the README itself links to a thread on pcbeta.com for model discussion. Forums give you dialogue and troubleshooting; the index gives you a starting artefact. They complement each other rather than compete.

Maintenance, licensing and what the index does not promise

The repository is MIT licensed, which covers the index content: the README, the tables and the Changelog. It does not cover the linked EFI folders, each of which carries its own licence or none at all. If you redistribute an EFI you found through this index, check that repository separately. Nothing here constitutes legal advice, and the licence of an EFI folder says nothing about the legality of running macOS on non-Apple hardware in your jurisdiction.

On maintenance: the last push was on 2026-08-28, and the README's own update log is dated 2026年6月18日. The index is being extended with new models. What is not maintained here is the content behind the links, and the README provides no freshness marker per row. Upgrading means re-reading the table for your model, checking whether the linked repository has moved on, and comparing its config.plist against yours. There is no version number on the index and no release artefact to pin, so there is nothing to upgrade in the conventional sense. Your upgrade path runs through whichever third-party EFI you adopted.

Editorial conclusion

Use it if you own a machine that already appears in its tables and you want to find the EFI folder someone else maintained for that exact model instead of building one from scratch. Do not use it if your hardware is absent from the lists, because the repository does not generate a configuration for you. Before flashing anything, open the linked EFI repository and check which bootloader it uses, which macOS version it targets, and when it was last touched.

Frequently asked questions

Official sources

1. daliansky/Hackintosh on GitHub
2. Issues
3. License: MIT
4. README