Jump to content

Leaderboard


Popular Content

Showing content with the highest reputation since 05/04/20 in all areas

  1. 1 point
    wujek_bogdan

    VMware Fusion vs Parallels Desktop

    A w wielu przypadkach wystarczy po prostu WINE. Niestety musimy poczekać, aż developerzy WINE poradzą sobie z dostosowaniem WINE do pracy w w pełni 64-bitowym środowisku. Obecnie, po porzuceniu przez Apple wsparcia dla aplikacji 32-bitowych (czyli od 10.15), WINE przestało działać Więcej szczegółów tutaj: https://www.codeweavers.com/about/blogs/ken/2019/10/3/crossover-for-catalina-progress-october-3-2019
  2. 1 point
    Estrax

    VMware Fusion vs Parallels Desktop

    @NX44 Podstawowa kwestia, do czego ma to służyć? Nauka podstaw wirtualizacji, jakieś małe konfiguracje, czy coś na większą skalę? W jakim celu jest Ci potrzebny akurat nested VT-x? Ktoś w video tutorialu tak Ci zasugerował, czy masz faktyczną potrzebę posiadania jego i wiesz konkretnie dlaczego jest Ci on potrzebny? Nie zrozum mnie źle, ale po prostu na ten moment wygląda mi to na sytuację, którą można by było opisać wyrażeniem "zamienił stryjek siekierkę na kijek". Prawda jest taka, że macOS i wirtualizacja to nie jest najlepsze połączenie, jeśli myślisz o tym na poważnie. Ogromny procent narzędzi pod macOS, które służą do wirtualizacji i tematów wokół jest okrojonych (w stosunku do ich linuxowych odpowiedników). macOS do pracy jako SRE/DevOps/SysOp nadaje się tylko jako terminal z ssh. Reszta to po prostu masa użerania się z czymś, co na dowolnym linuxie działa bez jakichkolwiek problemów. W przypadku nested VT-x, pełne jego wsparcie masz tylko, gdy odpalasz macOS jako zwirtualizowany OS na hoście macOS. Wirtualizując jakikolwiek inny OS pod macOS, o wsparciu dla nested VT-x możesz zapomnieć. A co do Parallels vs VMware, jeśli Twoje zastosowanie to ot odpalenie sobie Windowsa, bo brakuje Ci jakiejś aplikacji pod macOS, to Parallels się sprawdzi - ba, będzie on ciut sprawniej działać od Fusion czy innej konkurencji (np. w postaci virtualboxa). Do czegokolwiek bardziej zaawansowanego oba będą jednakowo beznadziejne, gdyż współdzielą znakomitą większość wad w temacie wirtualizacji.
  3. 1 point
    v-on

    VMware Fusion vs Parallels Desktop

    Dla mnie VMware (ale nie używałem zagnieżdżania) Ale jeżeli chodzi o mnie - to przesiadłem się na Proxmox na osobnym sprzęcie. Za cenę licencji VMware kupisz małą skrzyneczkę w stylu lenovo m72e tiny. Jeżeli potrzebujesz tylko windowsa - to wystarczy w 100%, a jeżeli kilka systemów, to darmowy Proxmox (odpowiednik VMware ESXi) - szczególnie jak wirtualizujesz linuksy na debianie/ubuntu, to możesz uruchomić kilka na raz bez straty "mocy" w trybie container.
  4. 1 point
    AppleALC ani VoodooHDA nie ma tu nic do rzeczy, bo to urządzenie USB. Sprawdź na Windows albo w ogóle innym kompie czy wtedy mikrofon działa, żeby wykluczyć awarię samej kamerki. Zobacz też w urządzeniach Audio i Midi czy może tam nie jest wejście wyciszone, albo pokombinuj z różnym próbkowaniem.
  5. 1 point
    reyder

    Mac OS - kiepski i niedopracowany system

    Nic tutaj nie zrobisz, musisz robić tak jak Apple chce albo się będziesz męczył. Ja mam Plexa postawionego na Freenas i dysk sieciowy leci przez SMB. Pamiętam jakim koszmarem było ustawienie własnego dzwonka na iphone. chyba nadal nie można ściągnąć sobie mp3 i ustawić tylko trzeba kombinować.
  6. 1 point
    Jest to część standardu ACPI, ACPI z kolei to standard pozwalający na komunikowanie się sprzętu z oprogramowaniem. Dzięki niemu z poziomu oprogramowania jest możliwe kontrolowanie pewnych aspektów zarządzania energią. DSDT to pewnego rodzaju tabele opisujące jakie urządzenia znajdują się na płycie głównej. Na podstawie tych tabel system operacyjny rozpoznaje urządzenia i wczytuje odpowiednie sterowniki (a mówiąc precyzyjniej: rozszerzenia jądra) dla tych urządzeń. W macOS, w przeciwieństwie do Windows, sterowniki są integralną częścią systemu (choć są od tego wyjątki). System może je załadować, lub nie, w zależności od tego na jakim sprzęcie jest uruchomiony. Filozofia jest tutaj więc zbliżona do tego jak działają systemy Linuksowe. W przypadku nowych płyt głównych zazwyczaj poprawki DSDT nie są wymagane, starsze płyty, jak twoja, wymagają ich dużo częściej. Część poprawek może być nałożona "w locie" przez bootloader. Niestety nie ma tutaj prostej odpowiedzi ponieważ najpierw trzeba zidentyfikować problemy jakie twój sprzęt ma. Ogólne informacje znajdziesz tutaj: https://www.insanelymac.com/forum/topic/278170-dsdt-—-what-is-it-and-how-do-i-get-it/ https://hamac.pl/forum/27-dsdt-opisy-narzędzia-przykłady/ Jest kilka wątków na tym forum, są też wątki na insanelymac. Są nawet gotowe DSDT dla tej płyty - ale z tymi bym uważał. Musisz mieć identycznią konfigurację: tak samo skonfigurowany BIOS i taką samą wersję BIOS-u. Nie masz też pewności, że gotowe DSDT jest przygotowane prawidłowo.
  7. 1 point
    Nasedo

    Czy Hackintosh to emulacja?

    Witam Was serdecznie, Do napisania tego postu skłonił mnie mój kolega, który upiera się iż Hackintosh jest emulacją. Swoją opinię prawdopodobnie zaczerpnął z Wikipedii, podającej iż jednym ze sposobów instalacji Hackintosha na PC jest emulacja (U)EFI. Chciałbym prosić o Wasze wypowiedzi, przemyślenia mówiące o tym, czy Hackintosh jest emulacją, czy jest pełnoprawnym, natywnie działającym systemem na komputerach PC - jedynie systemem, który jest poddany odpowiednim modyfikacjom. O ile jestem w stanie zgodzić się, że Mac może być emulowany na wirtualnym środowisku, lub używając emulatora komputera Mac, o tyle nie zgadzam się osobiście z twierdzeniem iż Hackintosh jest emulacją. Osobiście mam własne doświadczenia z Hackintoshem, m.in. Leopard na Acer Aspire One A150, Snow Leopard Toshiba Equium A200, Lion na Lenovo Thinkpad X61 i w przypadku każdego z tych komputerów nie dostrzegłem tego, bym emulował komputer z systemem OS X, a po prostu system ten instalowałem na komputerach PC. Bardzo proszę o Wasze wypowiedzi.
  8. 1 point
    MKjanek32

    Czy Hackintosh to emulacja?

    Może opiszę, jak to konkretnie wygląda w każdym z wymienionych przypadków. 1. Komputer z BIOSem + Chameleon: Chameleon emuluje jakieś podstawowe funkcje EFI potrzebne do uruchomienia Mac OS Xa, których nie ma w BIOSie. 2. Komputer z BIOSem + Clover (albo z UEFI + Clover w trybie kompatybilności z BIOSem): Clover przed załadowaniem się uruchamia pełne UEFI (bodajże projekt DUET), po czym wykorzystuje je do wystartowania OS Xa. 3. Komputer z UEFI + Clover: Clover wykorzystuje UEFI płyty głównej do uruchomienia OS Xa. Sposób niemalże taki sam, jak w prawdziwym Macintoshu, do tego stopnia, że OS X może używać prawdziwego NVRAM płyty głównej. Dalej przebiega to już identycznie w każdym przypadku: OS X pracuje natywnie. Ładuje sterowniki, pobiera w odpowiednim momencie z urządzenia SMC klucz do rozszyfrowania kilku składników (w PCtach oczywiście tego urządzenia nie ma, więc instaluje się sterownik FakeSMC zastępujący je) i uruchamia się. Przez działanie natywne rozumiem, że: -System wszystkie instrukcje procesora wykonuje bezpośrednio, bez żadnego tłumaczenia. -System ma bezpośredni dostęp do wszystkich elementów komputera - procesor, RAM, magistrale PCI i PCI-E, wszystkie karty, porty, kontrolery dysków, itd. Jaka jest więc rola Clovera jako bootloadera? -Wybór systemów (jak np. GRUB). -Zrobienie kilku rzeczy umożliwiających prawidłowe działanie OS Xa - m. in. wstrzyknięcie informacji o modelu Macintosha, na jakim system jest rzekomo uruchomiony. W prawdziwym Macu te dane są odczytywane z SMBIOS. W PCtach są w nim oczywiście inne informacje, a wiele składników systemu (np. sterowniki zarządzania energią) potrzebuje nazwę modelu Macintosha do prawidłowego działania. Wstrzykuje się więc dane modelu zbudowanego na sprzęcie tej samej generacji, co nasz komputer - przykładowo dla Haswella będzie to iMac 14,1. Mam nadzieję, że wyjaśniłem zrozumiale. A przy okazji pięknie widać, dlaczego instalowanie Clovera w trybie legacy (kompatybilności) na płycie głównej z UEFI nie ma absolutnie sensu.
  9. 1 point
    oswaldini

    Czy Hackintosh to emulacja?

    Emaulacja Mac OS X na PC co za bzdura. Tak po ludzku mówiąc Mac OS X ma w systemie zaszyty boot.efi (/System/Library/CoreServices/) i jest to aplikacja efi, w zasadzie bootloader. UEFI PC ma zaszyte ścieżki, w których "zaszyte" są bootloadery innych systemów (Win, Linux) i stamtąd je ładuje, bootloadery potem robią "swoje" (w linux i mac os x np ładują drivery i kernel), niestety nie ma tam, info o lokalizacji boot.efi w Mac OS X. Gdyby PC był kompatybilny wystarczyłaby kosmetyczna zmiana oraz dodanie drivera HFSPlus.efi do odczytu partycji Macowych ALE wymagany jest min. FakeSMC.kext do odpalenia Mac OS X na PC, boot.efi z Mac OS X nie załaduje sterowników z zewnątrz, Clover modyfikuje zachowanie makowego bootloadera i dodaje m.in możliwość załadowania dodatkowych driverów. FakeSMC.kext oszukuje Mac OS X o występowaniu applowego SMC i dzięki temu daje się odpalić system. Jeżeli wszystkie komponenty są kompatybilne to działają natywnie na driverach apple i nic nie trzeba dalej popychać, emulować itp. Suma summarum, Clover modyfikuje zachowanie makowego bootloadera boot.efi w celu możliwości załadowania driverów, a przy okazji daje dużo więcej możliwości - np modyfikowanie driverów apple w locie w pamięci systemowej (bo tam są ładowane podczas startu) zamiast modyfikować ręcznie pliki fizycznie na dysku. Kolega na siłę szuka dziury w całym bo ma klapki na oczach. Zapytaj kolegi czy zmiana bootloadera na prawdziwych makach też emuluje na nich system Mac OS X... Np macosxbootloader który pozwala uruchomić nowsze systemy OS X na starych Makach z 32-dwu bitowym efi.
  10. 1 point
    Grzesiek13

    Czy Hackintosh to emulacja?

    Kolega to chyba z MyApple... 1. Clover przypomina każdy inny bootloader a system sam z siebie nie korzysta z Clovera, to jedynie warstwa 2. Generalnie tak ale nie ma to w zasadzie związku z uruchamianiem systemu bo o bootloader się rozchodzi Zmień kolegów
  11. 1 point
    Nasedo

    Czy Hackintosh to emulacja?

    Ja to wiem, Ty to wiesz, wiele osób to wie... Jednak, próbuję zdobyć jak największą liczbę argumentów do dyksusji z moim kolegą. Jeżeli mówimy o EFI - dotyczy to nowych komputerów i jak najbardziej to jest prawda. Natomiast moje doświadczenia, jak napisałem powyżej były związane z trzema różnymi komputerami, w których był tradycyjny BIOS. Jednak, w każdym z tych komputerów, mimo iż kosztowało to pracy i wysiłku OS X w wersjach Leopard, Snow Leopard, Lion - działały poprawnie, stabilnie... i według mnie NATYWNIE. Nie było tam elementu EMULACJI. Jeżeli nawet jakiś bootloader musiał emulować EFI - to komputer PC działał bez innego systemu operacyjnego, pod kontrolą którego miałby pracować OS X.
  12. 1 point
    oswaldini

    Jak to wszystko działa ?

    W chameleonie jest tak, że bootloader "podstawia" tabele DSDT z pliku. Wówczas system "widzi" to co mu podamy, zamiast to co znajduje się faktycznie w sprzęcie. Ma to wiele zastosowań, głównie takie, że nie trzeba grzebać w kextach. Wiele różnych modyfikacji można zastąpić jedną. Często modyfikacja DSDT umożliwia rzeczy, które były by niemożliwe do osiągnięcia przez modyfikacje kextów. Na przykład u mnie, w DSDT mam poprawki do dźwięku, grafiki, jasności ekranu, usypiania, power managemntu, resetu biosu i inne. Bez DSDT musiałbym modyfikować i dodawać znacznie więcej kextów. Dużą zaletą DSDT jest to, że jest uniwersalne, raz zrobione będzie działać na każdej wersji Mac OS X, ewentualnie będzie wymagało nowych, małych poprawek. DSDT z SL z powodzeniem można używać na Lionie. Jest to także o tyle dobre, że po wprowadzeniu zmian do DSDT nie musimy kompilować na nowo całego BIOSu z przerobionymi tabelami i nie musimy wgrywać tego BIOSu do PC. Z przerobionymi tabelami w BIOSie mogłyby być np problemy w windowsie (m.in przy zmianie dev id chipsetu czy wifi) To zależy od urządzenia. Jeśli chodzi o temperaturę, to najczęściej używa się pluginów do FakeSMC. Pluginy do FakeSMC czytają dane z kontrolerów IO na płycie głównej (Winbond, ITE) lub w przypadku kiedy są nie obsługiwane czytają dane z ACPI o ile się nie mylę. Są też pluginy do geforceów i radeonów. Jak to działa - nie mam pojęcia, wiem że plugin odpowidzialny jest za "zczytanie" danych z kontrolera IO. org.chameleon.Boot.plist (dawniej com.apple.Boot plist) to plik konfiguracyjny chameleona, można w nim włączyć różne fixy i dostosować ustawienia. Jeśli chodzi o stringi, to kiedyś była jedyna metoda odpalania kart graficznych, która nie wymagała dodawania kextów. Obecnie mamy Graphics-Enablera, który radzi sobie z większością kart, które da się uruchomić w OS X oraz dopisywanie grafiki do DSDT, kexty jak ATY_Init, więc EFI-String traci mocno na popularności. com.apple.Boot.plist to nie jest plik konfiguracyjny chameleona, no po części. Plik ten naturalnie występuje w systemie i za pomocą stringów się tam znajdujących "wydajesz" komputerowi polecenia co ma zrobić. Np kiedyś komputery Apple'a nie były uruchamiane w 64bitach a w 32 - był wpis właśnie w tym pliku. Chameleon także używa tego pliku - teraz został przemianowany na org.chameleon.Boot.plist - i w nim można dodawać stringi aby nie robić burdelu w pliku systemowym. Oczywiście jeżeli nie mamy tego pliku w /Extra bootloader czyta plik z katalogu systemowego. Chameleon obsługuje więcej stringów niż sam system - to oczywiste, np. GraphicsEnabler. Co do EFI String - jest to już mało popularne bo jest kłopotliwe, czasochłonne itp. Jest to jednak niezastąpione przy dwóch grafikach w komputerze - zwłaszcza Nvidii i ATI. Przez EFI Stringa można też odpalić LAN.
×
×
  • Create New...

Important Information

By using this site, you agree to our Terms of Use.