I'M Keven Feil

Graphic Designer . Web Developer . Photographer

About Me

Hello

I'mKeven Doe

Developer and Startup entrepreneur

I am Keven Doe. Web scholar. Introvert. Explorer. Hardcore thinker. Devoted social media fan. Wannabe reader.

If you are going to use a passage of Lorem Ipsum, you need to be sure there isn't anything embarrassing hidden in the middle of text making it over 2000 years old.

Lorem ipsum dolor sit amet, consectetuer adipiscing elit. Aenean commodo ligula eget dolor. Aenean massa. Cum sociis natoque penatibus et magnis dis parturient montes, nascetur ridiculus mus. Lorem ipsum dolor sit amet, consectetuer adipiscing elit. Aenean commodo ligula eget dolor.

Fusce quis volutpat porta, ut tincidunt eros est nec diam erat quis volutpat porta, neque massa, ut tincidunt eros est nec diam FusceFusce quis volutpat portaFusce quis volutpat

Web Dedign

UX/UI Dedign

Wordpress

Javascript

What I do?

Graphic

Lorem ipsum dolor sit amet, augue theophrastus ex.

Photography

Lorem ipsum dolor sit amet, augue theophrastus ex.

Development

Lorem ipsum dolor sit amet, augue theophrastus ex.

Responsive

Lorem ipsum dolor sit amet, augue theophrastus ex.

Wordpress

Lorem ipsum dolor sit amet, augue theophrastus ex.

Javascript

Lorem ipsum dolor sit amet, augue theophrastus ex.

My Experience

Apple Inc.

2015-Today

Art & Creative director

Lorem ipsum dolor sit amet, consectetur adipiscing elit, sed do eiusmod tempor incididunt ut labore et dolore magna aliqua.

Facebook Inc.

2012-2015

Web designer & developer

Lorem ipsum dolor sit amet, sit augue theophrastus ex. Nec ne dicam impedit perpetua, legimus fierent molestiae ei nec. Eum ei adhuc meliore pericula.At agam omittam accumsan mel.

IBM Inc.

2011-2012

Mid-level designer

Lorem ipsum dolor sit amet, consectetur adipiscing elit, sed do eiusmod tempor incididunt ut labore et dolore magna aliqua.

My Latest Projects

[Flutter] Shared Preferences và Security Storage

flutter, shared preferences, security storage, shared_preferences, flutter_secure_storage

Sau một thời gian trải nghiệm Flutter thì hôm nay mình xin chia sẻ về Shared Preferences và Security Storage trong Flutter thông qua Take Note ngắn.

Là một Senior iOS Developer mình nhận thấy Flutter khá dễ tiếp cận và là hướng đi tốt để bổ sung thêm vũ khí cho Dev. Bản thân mình đã kiểm chứng và củng cố rất nhiều kiến thức khi so sánh lập trình Native iOS với Flutter.
Mình sẽ có thêm những bài viết mới trên để chia sẻ kiến thức. Mong rằng những chia sẻ của mình sẽ có ích với mọi người.

flutter, shared preferences, security storage, shared_preferences, flutter_secure_storage

flutter, shared preferences, security storage, shared_preferences, flutter_secure_storage

flutter, shared preferences, security storage, shared_preferences, flutter_secure_storage

flutter, shared preferences, security storage, shared_preferences, flutter_secure_storage



flutter, shared preferences, security storage, shared_preferences, flutter_secure_storage

flutter, shared preferences, security storage, shared_preferences, flutter_secure_storage

flutter, shared preferences, security storage, shared_preferences, flutter_secure_storage

flutter, shared preferences, security storage, shared_preferences, flutter_secure_storage

flutter, shared preferences, security storage, shared_preferences, flutter_secure_storage

Ref: 

https://pub.dev/packages/flutter_secure_storage

https://pub.dev/packages/shared_preferences

https://www.bezkoder.com/dart-flutter-convert-object-to-json-string/



Hackintosh sẽ ra sao nếu Apple không ra thêm mẫu máy nào chạy CPU Intel?

Apple Silicon.

Apple đang rất thành công với các mẫu máy chạy dòng CPU M1. Có vẻ như hãng sẽ không ra thêm bất kì sản phẩm nào chạy CPU Intel trong thời gian sắp tới. Vậy bức tranh Hackintosh trong tương lai sẽ ra sao?

M1 Ultra performance vs power.

Câu truyện bắt đầu từ những ngày cuối tháng 6 năm 2020, Apple công bố sẽ sử dụng CPU mà hãng phát triển dựa trên nền tảng ARM trên các model Macintosh trong tương lai. Con CPU M1 là bước đầu tiên,  vừa rồi Apple đã đem cuộc chơi đi xa hơn với mẫu M1 Ultra, và rồi Apple sẽ còn đi xa hơn nữa trong các mẫu Apple Silicon kế tiếp. Vui quá, người chơi hệ Macintosh thì quá vui vì máy Mac càng ngày càng mạnh, mỏng, mát hơn.

CPU Intel cuối cùng được Apple sử dụng là Ice Lake với mã I7-1068NG7 và I5-1038NG7 trên Macbook Pro 13 inh. Đi cùng với nó là iGPU Intel® Iris® Plus. Có nghĩa là các phiên bản macOS sắp tới Apple sẽ chỉ có kext cho iGPU Intel Iris Plus là tối đa. Người chơi hệ Hackintosh bắt đầu buồn từ đây.

Một combo Intel 12th Gen Hackintosh.

Hackintosh trên Laptop sẽ dừng cuộc chơi ở intel thế hệ 10, tương ứng với các mã CPU dùng iGPU Intel Iris Plus hoặc Intel UHD 630. Từ thế hệ 11 trở đi, Intel dùng dòng iGPU xịn hơn trong khi macOS không hỗ trợ dòng iGPU này,  VGA rời thì không nhận trên macOS dẫn tới Laptop sẽ ngừng cuộc chơi đầu tiên. Hạn chế trong nâng cấp phần cứng Laptop không cho phép bạn lựa chọn.

Hackintosh trên Desktop sẽ cố gắng thêm thời gian dài nữa vì có thể lắp card rời. CPU Desktop thế hệ 11, 12 vẫn tương thích được với macOS. Có chăng thì thế hệ 12 tích hợp E-core sẽ cần thêm thủ thuật để kích hoạt nhưng vẫn khá OK, ít nhất là trên macOS Monterey. VGA AMD vẫn sẽ được support dài vì Apple còn cần support eGPU trên các máy Macbook Pro 13 inh 2020 thêm nhiều năm nữa. 

Nếu có ý định mua một chiếc Laptop mới tinh để cài macOS dùng, bạn hãy cân nhắc tới việc mua 1 chiếc Real Mac hoặc lắp máy bàn.

Hãy comment xuống bên dưới nhu cầu của bạn là gì nhé, bạn sẽ tiếp tục hackintosh hay gia nhập hội những người dùng macintosh? 

OpenCore Phần 1: macOS sẽ khởi động như thế nào?

OpenCore Phần 1: macOS sẽ khởi động như thế nào?
 
Để khởi đầu công cuộc cài macOS, mình nghĩ bạn nên bắt đầu với cơ chế khởi động (boot) của hệ điều hành thông qua OpenCore. Điều mà hầu hết các bài hướng dẫn nơi khác đều coi là thứ không cần phải biết thì ở đây chúng ta không làm vậy.

Mình đoán là bạn đã từng mong chờ Phần 5 của chuỗi bài về Hackintosh và cũng từng đó thắc mắc vì sao mình không viết tiếp. Từ hôm nay mình sẽ viết chuỗi bài mới với OpenCore. Mình khuyến khích bạn đọc Phần 1 2 trước, Phần 3 và 4 bạn có thể bỏ qua (vì đó là kĩ thuật cũ trên Clover).

Phần cứng mặc định là CPU Intel thế hệ thứ 6-7-8-9 hoặc cao hơn, các hệ thống thấp hơn cũng làm tương tự và mình sẽ nói thêm trong từng bài.
Mình cũng rất muốn có thêm một hệ thống CPU AMD để thử nghiệm nhưng tình hình tài chính hiện nay chưa cho phép chơi lớn đến mức đó, bạn nào thiện trí có thể cho mình mượn hoặc thuê CPU AMD thì mình rất cảm ơn.

Còn nữa, Hội Dev Thích Moè là sân chơi riêng dành cho lập trình. Hỏi đáp, nghiên cứu về cài macOS thì qua group OpenCore for macOS, mình cũng không muốn tạo thêm group nhưng suy nghĩ lại thì có group riêng sẽ dễ lắng nghe phản hồi và dễ định hướng nội dung cho bài viết trong tương lai. 

OpenCore đơn giản nó là:

OpenCore là bootloader thế hệ mới thay cho Clover và Chameleon. OpenCore không chỉ  cho hệ thống Hackintosh mà còn sử dụng được trên hệ thống real macs (máy mac thật). Giúp cho "người chơi" dễ dàng cài đặt song song nhiều hệ điều hành cùng lúc. Về mặt sâu hơn thì OpenCore đem lại nền tảng boot "sạch sẽ" và gần giống với cách thức hoạt động của real mac hơn, cách mà OpenCore nạp Kext cũng được cải tiến hơn (đó là lí do vì sao boot vào macOS với  OpenCore nó lại nhanh hơn hẳn so với người tiền nhiệm Clover.

OpenCore is an alternative bootloader to CloverEFI or Chameleon. It is not only for Hackintosh and can also be used on real macs for purposes that require an emulated EFI. It also aims to have the ability to boot Windows and Linux without the need for using different acpi tables. It has a clean codebase and aims to stay closer to how a real mac bootloader functions. Kext injection has been greatly improved. While already functioning well.
Source: insanelymacdiscord

OpenCore nó hoạt động thế nào?

OpenCore hoạt động như thế nào? duongth.dev
OpenCore hoạt động như thế nào?
UEFI bản chất nó là một hệ điều hành siêu mini được load sau khi bạn ấn nút nguồn. Nó sẽ tìm kiếm kệ điều hành có sẵn trong máy tính và khởi động hệ điều hành đó lên. Dấu hiệu nhận biết nó chính là logo của mainboard hoặc hãng laptop.

Giả sử bạn chỉ có cài mỗi Windows, UEFI sẽ tìm tới boot của Windows và Windows sẽ thực hiện quá trình boot. Cơ chế boot của Windows không phải trọng tâm của chuỗi hướng dẫn nhưng bạn tò mò có thể xem thêm tại đây: Link

Giả sử bạn muốn multi boot Windows + macOS + Linuxs thì làm thế nào để  quản lý được chúng? OpenCore bản chất cũng là một hệ điều hành siêu mini, được load sau UEFI, nó rà soát và đưa ra những hệ điều hành có trong máy tính, rồi từ OpenCore đi đâu là tuỳ vào lựa chọn của bạn:

  • Nếu bạn chọn Windows hay Linux thì OpenCore sẽ tìm tới boot tương ứng và thực hiện quá trình boot như trên.
  • Nếu bạn chọn macOS, nó sẽ đóng vai trò giả lập lại môi trường để đánh lừa macOS, giúp chúng ta vượt rào và đây chính là nguyên lý cơ bản của bộ môn thể thao trí tuệ cuốn hút nhất hiện nay mang tên "Hackintosh".

OpenCore sẽ được cài đặt ở đâu? 

Đầu tiên mình chuẩn hoá lại từ ngữ để bạn không bị nhầm lẫn giữa ổ cứngphân vùng.
  • Ổ cứng sẽ dùng chỉ thiết bị vật lý : ổ HDD, ổ SSD.
  • Trên mỗi ổ cứng sẽ chia ra nhiều phân vùng để quản lý dữ liệu: phân vùng C, phân vùng Data....
Trong ngôn ngữ bình dân chúng ta gặp hằng ngày từ "ổ" được dùng chung cho cả ổ cứng và phân vùng ( ổ C, ổ D, ổ Win, ổ Data, ổ cứng HDD, ổ cứng SSD, ổ USB ....). Nhưng về kĩ thuật thì phải phân định rõ ràng và không tồn tái khái niệm "ổ" chung chung.
OpenCore quản lý các hệ điều hành có sẵn như thế nào?
OpenCore sẽ được đặt vào phân vùng EFI trên ổ cứng. Từ tương quan giữa vị trí đặt OpenCore và vị trí cài đặt macOS mình chia thành 2 cách bố trí hệ điều hành phổ biến:
  1. Cài chung Windows và macOS trên cùng một ổ cứng.
  2. Cài riêng macOS trên ổ cứng độc lập. (ở đây lại chia tiếp làm 2 trường hợp nhỏ, mình sẽ nói cụ thể bên dưới)
Mình có lưu ý với bạn rằng macOS Catalina tương thích với mọi loại ổ cứng  HDD và SSD có mặt trên thị trường. Bởi vậy bạn không cần phân vân là nên cài lên ổ cứng HDD hay SSD làm gì cho mệt, chỉ có điều cài lên HDD thì macOS load chậm hơn SSD - hiển nhiên là vậy.

Cách 1:  Cài chung Windows và macOS trên cùng một ổ cứng.

Đây là phương án chia phân vùng phổ biến trên laptop hoặc desktop có 1 ổ cứng duy nhất. 
Cài chung Windows và macOS trên cùng một ổ cứng. duongth.dev
Cài chung Windows và macOS trên cùng một ổ cứng.
  • Trường hợp A: cài mới từ đầu. Gọn gàng và sạch sẽ với phân vùng EFI ở đầu -> Windows  -> macOS.  Phân vùng macOS trước hay Windows trước không quan trọng, nó không ảnh hưởng gì đến quá trình cài và chạy của macOS. Tuy nhiên mình thấy để  Windows trước sẽ tiện hơn,  khi bạn muốn gỡ bỏ macOS khỏi ổ cứng chỉ cần xoá OpenCore và format phân vùng macOS là máy tính lại y hệt như chưa từng cài macOS.
  • Trường hợp B: máy đang có sẵn Windows, bạn quyết định giữ lại Windows hiện tại thì sẽ phải tách một phân vùng EFI mới >200MB từ phân vùng chứa Windows, chuyển boot của Windows qua phân vùng EFI mới và xoá phân vùng EFI cũ đi. Nhưng đôi khi cách này gây ra rắc rối nhỏ và phải làm lại theo trường hợp A.

Nguyên nhân :

  • Mặc định khi cài, Windows sẽ tự động tạo phân vùng EFI (nếu máy đang không có phân vùng EFI nào). Phân vùng này sẽ có dung lượng 100MB.
  • MacOS thì lại yêu cầu phân vùng EFI phải có dung lượng tối thiểu 200MB.


Cách 2: Cài riêng macOS lên một ổ cứng độc lập.

Chi thêm vào trăm ngàm, mua SSD mới cài macOS không có gì khó hiểu với hệ thống Desktop cả. Gần đây cách cài riêng này cũng được sử dụng trên Laptop khi các hãng có option 2 ổ cứng.
Cài riêng macOS lên một ổ cứng độc lập duongth.dev
Cài riêng macOS lên một ổ cứng độc lập.
Cài riêng trên 2 ổ độc lập bạn sẽ không cần phải cân nhắc đụng chạm đến windows hiện tại. Tất cả chỉ là lắp ổ cứng mới -> chia ổ cứng mới với phân vùng EFI >200MB và tiến hành cài macOS là xong.

Trường hợp A: Bạn để OpenCore trên phân vùng EFI của ổ cứng chứa macOS.

  • Ưu điểm: Độc lập và an toàn cho cả Windows và macOS. Bạn có thể rút một trong 2 ổ cứng ra mà vẫn có thể an toàn boot vào hệ điều hành tương ứng. 
  • Nhược điểm:  Sẽ phát sinh ra vấn đề khi bạn muốn cài lại Windows. Bộ cài Windows sẽ báo lỗi khi phát hiện toàn bộ hệ thống có tới 2 phân vùng UEFI. 
  • Khắc phục: Bạn có thể tháo ổ  cứng macOS ra, cài lại Windows xong thì lắp ổ cứng chứa macOS vào. Cũng có thể cài Windows từ win mini hoặc làm theo Trường hợp B.

Trường hợp B: Gom OpenCore vào chung với boot của Windows trong phân vùng EFI của ổ cứng chứa Windows hoặc phân vùng EFI của ổ cứng chứa macOS, sau đó xoá đi phân vùng EFI còn lại.

  • Ưu điểm: dễ dàng cài lại Windows mà không bị cảnh báo gì.
  • Nhược điểm: Chung EFI nên khi ổ cứng chứa OpenCore bị rút ra, hệ điều hành ở ổ cứng còn lại không thể boot được.
  • Khắc phục: Làm theo trường hợp A.
Cả hai trường hợp A-B đều không ảnh hưởng hay gây lỗi gì trong quá trình cài đặt và sử dụng macOS. Bạn chỉ cần cân nhắc xem sẽ chọn phương án nào mà thôi. Cá nhân mình sử dụng trường hợp A.

Next:

Hôm nay đến đây là vừa đủ. Mình khuyên bạn nên tìm hiểu thêm ở nhiều nguồn khác nhau và tham gia thảo luận  ngay bên dưới comment hoặc tại OpenCore for macOS.

Hẹn gặp lại ở bài sau  mình sẽ viết về "Các thành phần của OpenCore và nguyên lý sử dụng". 
Nếu bạn mong chờ bài viết tiếp theo hãy mạnh dạn comment ý kiến cuối bài.
Cảm ơn bạn.

Thủ thuật 30s : Lấy lại dung lượng ổ cứng sau thời gian dài dùng Xcode.

 Sẽ có một ngày bạn cảm thấy vì sao ổ cứng của mình đầy nhanh đến vậy? Hôm nay mình sẽ trả lời cho bạn. Thủ thuật dưới đây đã giúp mình lấy lại tới 120GB trên ổ cứng SSD quý giá.

Sau thời gian dài chăm chỉ làm việc của mình, công ty đã quyết định nâng cấp ổ cứng của chiếc mac mini từ 1TB HDD lên SSD 2560GB Samsung 860 evo. Tất nhiên rồi, công việc trôi chảy hơn, mọi cái làm việc hiệu quả hơn. Cho đến một ngày phát hiện ra ổ cứng bị đầy lên nhanh đến lạ.
120GB được lấy lại ngon lành.
Lục lọi một hồi thì hoá ra nguyên nhân chính là:
~/Library/Developer/Xcode/DerivedData/ là thư mục được Xcode sử dụng để giữ lại data của các project mà bạn đã làm việc ( build, log, lib .v.v...... ở dạng temp data). Xcode không hề tự động dọn dẹp nó khi project bị đóng lại - nhằm tăng tốc xử lý. Nếu bạn có hoài nghi gì về chức năng của nó thì dễ dàng chứng minh tính hiệu quả. Mỗi khi bạn build project, folder này sẽ tự động sinh (nếu như chưa tồn tại), data build sẽ lưu ở đây.
.
~/Library/Developer/Xcode/Archives/ là thư mục kế tiếp. Xcode sẽ lưu file . xcArchive - chính là tiền thân của .ipa. Cho đù ổ cứng bạn có đầy đến đâu và trí tưởng tượng bạn có phong phú đến đâu cũng bất ngờ về dung lượng của nó. Và nó sẽ tiếp tục "phình" lên sau mỗi lần ta build Archive.
Để build ra 1 file ipa 40MB có thể cần tới 800MB cho file xcArchive và hơn thế nữa.
Video hướng dẫn thao tác.
Nếu như bạn thấy hay và hữu ích thì hãy chia sẻ cho đồng nghiệp cùng biết nhé.
Cảm ơn.

Phần 4: Hackintosh thực hành patch DSDT cổng USB


Cổng USB phải là điều bạn quan tâm đầu tiên bởi vì bộ cài sẽ được cắm vào cổng này. Thực hành patch DSDT cho cổng USB cũng rất điển hình, từ sau guide này level bạn sẽ lên một bậc. Cho tiện thì mình sẽ gọi chung ổ USB, ổ cứng di động là USB.
Mình nhắc lại điều đã nói ở Phần 1: "Hãy gạt bỏ những suy nghĩ và phương pháp mà trước giờ bạn thường sử dụng để đọc bài này".  Mình cam đoan nếu như bạn bỏ qua Phần 1, Phần 2Phần 3 thì đọc Phần 4 này bạn sẽ không hiểu gì cả.
Các bài hướng dẫn tràn lan đang dẫn dắt bạn theo hướng "cài lấy được":
* Bạn không hiểu vì sao lại làm thế dẫn tới suy nghĩ không cần phải biết chỉ cần làm theo.
* Lâu ngày sẽ sinh tâm lý không muốn tìm hiểu thêm, trốn tránh các bước khó càng nhiều càng tốt, bạn tìm lý do để bao biện cho việc lười biếng này, 2 trong số đó là:
*phải là dân IT, phải là dân lập trình mới fix được lỗi của DSDT.
*phải có kiến thức, có kinh nghiệm mới chơi được Hackintosh. 

Điều này là sai, mình khẳng định là sai.
Bạn không trốn tránh mãi được, mình và chuỗi bài viết của mình sẽ giúp bạn đối mặt với khó khăn thay vì né tránh nó.
Lỗi "cấm đi ngược chiều" thần thánh do không nhận USB.


So sánh nhỏ:
Cách patch DSDT kiểu cũ để xử lý vấn đề USB như này:
Đầu tiên bạn phải tải các file công cụ về rồi tiến hành:
Bước 1) dịch file DSDT.aml ra DSDT.asl,
Bước 2)  fix sạch  error của DSDT,
Bước 3) rename device và apply patch,
Bước 4) save lại ra DSDT.aml.

Bước 2) ☠ chính là bước làm newbie nản lòng nhất vì không phải lỗi nào cũng có patch fix sẵn.

Cách mình đưa ra:
Vận dụng tính chất External include của ACPI (đã nói ở Phần 2)để thực hiện các thao tác tương đương.
Bước 1) rename Device và Method _DSM bằng config
Bước 2) override method _DSM của EHCI và XHCI bằng một SSDT khác.

* không cần tải thêm công cụ nào hết.
* không cần dịch ngược, không cần fix error DSDT không đụng chạm gì vào file DSDT gốc.
=> loại bỏ khó nhăn nhức đầu nhất với newbie.

Hiện tại trong đầu bạn có thể sẽ xuất hiện vài dấu "?" lớn như sau:
EHCI và XHCI là gì?
* Method _DSM là gì?
External include là gì và nó hoạt động như nào?
Find and Replace ACPI của Clover hoạt động ra sao?
...
thì bạn hẵng kiềm chế mình sẽ giải thích sau khi thao tác xong.

Patch DSDT cho cổng USB:

Bước 1) rename Device và Method _DSM.

Bước 2) override method _DSM cho XHC
Để đảm bảo override method _DSM cho XHC thành công, bạn sẽ override luôn _OSI
Dùng SSDT-XHC.amlSSDT-XOSI.aml

Lưu file config, SSDT-XHC.aml và SSDT-XOSI.aml bạn cứ lưu lại vào máy tính, xong xuôi chúng ta sẽ nói chung một thể sẽ lưu nó ở đâu trong bộ cài.

EHCI(Enhanced Host Controller Interface) và XHCI(eXtensible Host Controller Interface) là khái niệm về phần cứng, 2 module này quản lý các cổng USB 2.0 và 3.0. Khi bạn cắm thiết bị USB vào, hệ điều hành sẽ thông qua 2 module quản lý này để điều khiển thiết bị. MacOS quản lý EHCI và XHCI thông qua tên của Device trong DSDT. Rename chúng cho giống với máy Mac thì MacOS sẽ điều khiển chúng trơn chu được.

Method _DSM (Device-Specific Methods), nó định nghĩa các thuộc tính của thiết bị. MacOS chỉ lấy các thuộc tính của thiết bị thông qua method này. Các method _DSM nguyên bản của DSDT/SSDT của máy Hackintosh không có chứa thuộc tính MacOS cần, cho nên bạn có thể ung dung loại bỏ mà không gặp vấn đề gì.

SSDT là bảng phụ của DSDT, nó sẽ được gộp vào DSDT khi nạp vào hệ điều hành. Mình gọi đây là cơ chế  External include.
External include hoạt động ra sao ?

  1. => Rename _DSM thành XDSM, method _DSM trở nên vô nghĩa vì nó sau khi rename thì là XDSM mà MacOS không load gì từ XDSM hết.
  2. => Bởi vì không còn thấy _DSM trong DSDT nên MacOS sẽ tìm kiếm _DSM của device ở SSDT.
  3. => Trong bài này, MacOS tìm đến  và load _DSM của EHCI và XHCI có trong nội dung của file SSDT-XHC.aml.

Find and Replace ACPI của Clover sẽ Find and Replace tên toàn bộ DSDT và SSDT có sẵn của hệ thống. Cái lợi của nó là sẽ bao phủ DSDT và tất cả các bảng SSDT.

  • Cách patch kiểu cũ không thể bao phủ toàn bộ mà chỉ rename trên DSDT và các SSDT được patch mà thôi. Nếu bạn chọn patch toàn bộ SSDT đồng nghĩa ngồi fix toàn bộ các lỗi của từng file, cũng đồng nghĩa với việc tăng rủi ro patch sai. Newbie patch sai thì lại càng rối và rối. 
  • Nếu bạn chọn patch một vài SSDT cần thiết, khả năng phát sinh các lỗi khi hoạt động do rename thiếu.Nếu trong DSDT của bạn, không có XHC1 mà nó đã sẵn là XHC thì không sao hết, không find thấy XHC1 nên sẽ không thực hiện replace này. Tương tự nếu DSDT không có EHC0, EHC1 thì cũng không thực hiện replace.

Rename _DSM thành XDSM từ bài này không chỉ có tác dụng cho riêng cụm USB mà có tác dụng cho toàn bộ các thành phần khác của hệ thống. Từ giờ trở đi muốn MacOS load _DSM của thành phần nào, bạn sẽ phải dùng thêm SSDT_DSM cho thành phần đó. Đọc lại Phần 2 bạn sẽ hiểu tại sao lại thế.

_OSI dùng để xác định phiên bản của Windows, dựa vào đó sẽ có cấu hình cụm USB phù hợp. Phần cứng dùng để Hackintosh không được thiết kế để chạy MacOS nên khi MacOS load DSDT sẽ không tìm thấy cấu hình USB phù hợp với mình, override _OSI sẽ cấu hình lại cụm USB phù hợp với MacOS.Rename _OSI thành XOSI, MacOS sẽ load lại XOSI trong SSDT-XOSI.aml.

Phương pháp này có tên gọi là "hot patch". 
Nó được sinh ra trong hoàn cảnh từ Skylake trở đi có nhiều hệ thống nếu patch trực tiếp vào file DSDT/SSDT sẽ không thể boot được.
Phương pháp này cũng có lợi điểm là tái sử dụng mạnh mẽ cho bất kỳ hệ thống nào, bạn thấy đó không cần quan tâm DSDT/SSDT hiện tại ra sao, chỉ cần thực hiện 2 bước là patch xong DSDT cho cổng USB.

Tổng kết:
*Chúng ta khởi động như vậy thôi, nhồi thêm nữa sẽ phản tác dụng.
*Để hoàn thành toàn bộ cho cổng USB sẽ cần thêm một số patch DSDT nâng cao, cần thêm Kext nữa.
*Kext sẽ nói sau khi xong hết về patch DSDT cho các thành phần khác.
*Patch DSDT nâng cao sẽ nói thêm sau khi cài xong MacOS cho thong thả.
*Config nãy lưu lại, sẽ tiếp tục dùng cho các bài tiếp theo.

Phần 4 sẽ kết thúc ở đây, bạn từ từ ngâm cứu sẽ là tiền đề tốt để làm theo Phần 5 sắp tới nhé.

Bạn đang mong chờ gì ở bài viết tiếp theo hãy mạnh dạn comment ý kiến cuối bài.

Kĩ thuật "trét" kem tản nhiệt CPU nào tốt nhất?


Như chúng ta đã biết, không có bất kì bề mặt nhân tạo nào phẳng tuyệt đối. Do đó, chắc chắn giữa CPU và Heatsink tản nhiệt luôn luôn có một khe hở nhỏ, cho dù rất nhỏ thì nó cũng làm ảnh hưởng tiêu cực tới hiệu suất tản nhiệt. Lấp đầy khe hở nhỏ này bằng kem tản nhiệt là cách tốt nhất để giảm thiểu các ảnh hưởng tiêu cực này tới mức tối đa.
Bản thân kem tản nhiệt không có tính đẫn nhiệt tốt như kim loại, cho nên bạn hãy chú ý về liều lượng khi sử dụng sao cho hợp lý. Bài viết này mình sẽ bàn về cách "trét" kem  tản nhiệt sao cho hiệu quả, mình dịch từ "Thermal Paste Application Techniques" kết hợp với văn phong cá nhân. Cũng chú ý là thuật ngữ "Thermal Paste" dùng chỉ cho kem tản nhiệt silicon, kem tản nhiệt dạng kim loại lỏng thì là "Liquid Metal"  và hôm nay chỉ bàn về  Thermal Paste thôi.

Test Setup
Để dễ dàng quan sát khả năng bao phủ bề mặt của các kiểu "trét" kem tản nhiệt, chúng ta sẽ dùng 2 tấm nhựa acrylic trong suốt để mô phỏng lại bề mặt của Heatsink tản nhiệt. Một tấm sẽ đặt tại trước (vị trí tiếp xúc với CPU), một tấm ở mặt sau để bắt chặt tấm mặt trước, như vậy chắc chắn sẽ đem lại kết quả giống với Heatsink tản nhiệt thật.

Kỹ thuật "trét" kem
Những kỹ thuật "trét" kem tản nhiệt được thử nghiệm sau dây  hầu hết là các kĩ thuật được khuyến cáo sử dụng từ internet, ngoài ra thì có thêm vài kĩ thuật "trét" ngẫu hứng nhưng hợp lí. Các thao tác thực hiện đúng quy trình và cố gắng để kem trải đều trên bề mặt nhất có thể. Mình đảm bảo, khi bạn có ý định thực hiện lại thử nghiệm này, mức độ phủ cũng tương đương như này.
Hạt gạo (Rice size).
Một đường kem đậm (Thick line).
Trải kem (Roughly spread).
Vòng tròn (Circle shape).
Hạt gạo lớn (2x Rice size).
Ba đường kem (Three thin lines).
Trải đều kem (Smoothly spread).
Vòng tròn chấm (Circle with dot).
Một đường kem (Thin line).
Xoắn ốc (Spiral pattern).
Chữ X (X shape).
Khuôn mặt vui vẻ (Happy face).
Hầu hết là các kiểu "trét" quen thuộc (trừ cái Happy Face là ngẫu hứng) kiểu gì cũng mang lại hiệu quả nhất định. Dự đoán là kiểu chấm hoặc đường thẳng sẽ hạn chế được bọt khí nhưng lại không thể bao phủ được hết bề mặt CPU. Cũng tương tự như vậy mình dự đoán kiểu xoắn ốc sẽ bao phủ được toàn bộ bề mặt nhưng sẽ nảy sinh nhiều bọt khí. Chúng ta hãy thử xem xem kết quả ra sao khi nhìn qua mặt tấm nhựa acrylic xem sao.

Hình dạng kem tản nhiệt khi lắp Heatsink
Hầu như dù cố cẩn thận thế nào thì kết quả cũng không thể hoàn hảo, đã xuất hiện bọt khí, kích thước của chúng khá nhỏ, trên hình được khoanh xanh. Khoanh nào lớn thì bọt khí lớn, khoanh nào nhỏ thì bọt khí nhỏ. Những khoanh tròn đỏ là vùng mà kem tản nhiệt không thể phủ tới. Theo tư duy thông thường, phủ càng rộng và càng ít bọt khí thì hiệu quả tản nhiệt càng cao.
Hạt gạo (Rice size).
Một đường kem đậm (Thick line).
Trải kem (Roughly spread).
Vòng tròn (Circle shape).
Hạt gạo lớn (2x Rice size).
Ba đường kem (Three thin lines).
Trải đều kem (Smoothly spread).
Vòng tròn chấm (Circle with dot).
Một đường kem (Thin line).
Xoắn ốc (Spiral pattern).
Chữ X (X shape).
Khuôn mặt vui vẻ (Happy face).
Điều đầu tiên quan sát thấy, kiểu Hạt gạoMột đường kem không hề có bọt khí nhưng không thể bao phủ hoàn toàn bề mặt CPU. Thậm trí tăng lượng kem cho chấm lớn hơn với Hạt gạo lớn, Một  đường kem đậm hay Ba đường kem cũng không bao phủ hết được CPU ngược lại còn làm ra tăng thêm bọt khí. 
Kiểu Trải kem Trải đều kem đem tới mức bao phủ tuyệt vời nhưng lại sinh ra khá nhiều bọt khí.
Kiểu Xoắn ốc đem lại mức phủ kem rất tốt, cách tra kem này sẽ giúp không khí thoát kịp và ít sinh bọt khí, nhưng khó mà có thể đạt được mức hoàn hảo 100%.
Hình dạng Chữ X đem đến kết quả tốt nhất. Chữ X cho phép kem lan đều ra mọi phía của CPU, hình dáng này dễ dàng đẩy không khí ra khỏi mặt tiếp xúc hạn chế bọt khí. 
Kiểu Happy face có phạm vi phủ kem không được tốt, có khá nhiều bọt khí đã xuất hiện.

Chắc hẳn bạn đã có những suy đoán riêng về hiệu quả nhưng cụ thể ra sao mời bạn xem kết quả test nhé.

Kết quả Stress thực tế

Cấu hình test:

Kết quả test:

Nói chung là kết quả của các kiểu trét kem không có chênh lệch quá nhiều. Chữ X đem lại kết quả tốt nhất. Kiểu Trải đều kem đứng thứ 2, kiểu Hạt gạo (nhỏ) đứng thứ 3. Không thể tin được là kiểu Happy face lại xếp thứ 4. Đáng buồn nhất là kiểu Hạt gạo lớnMột đường kem đậm lại không đem lại hiệu quả tản nhiệt cao. Kết quả này củng cố cho mệnh đề quá nhiều kem hoặc quá ít kem cũng như hình dáng trét không hợp lí sẽ không đem lại hiệu quả tốt nhất.

Lời kết:
Với hình dạng Chữ X sẽ giúp cho kem giàn đều trên bề mặt, lượng kem vừa đủ sẽ ít sinh bọt khí. Cũng đừng lo lắng ít kem sẽ tải nhiệt kém mà ngược lại, nhiều kem có thể khiến phản tác dụng, cứ tra như này là được rồi.
Trét kem chữ X như vậy là OK rồi.
Kiểu Hạt gạo (nhỏ) cũng được cá nhân mình áp dụng trong nhiều năm qua, kết quả test xếp thứ 3 cũng khá OK. Sau khi đọc xong bài dịch này, mình hi vọng bạn sẽ thử qua hình Chữ X cho lần trét kem kế tiếp, mình cũng sẽ chuyển qua Chữ X.
Hay là thử qua kiểu Happy face, dù sao thì đứng thứ tư, chênh lệch so với kiểu chữ X khoảng 0.25 độ cũng chấp nhận được. Hơn nữa khá thú vị chúng ta luôn luôn có một CPU vui vẻ nằm dưới bộ tản nhiệt phải không nào. 

Chúc các bạn thành công.


What clients say

Start Work With Me

Contact Us

JOHN DOE
+123-456-789
Melbourne, Australia