Jump to content

Estrax

Members
  • Content Count

    1358
  • Joined

  • Last visited

  • Days Won

    45

Estrax last won the day on June 25

Estrax had the most liked content!

Profile Information

  • Gender
    Mężczyzna (Male)
  • Location:
    T6 & SF
  • Interests
    Product / DevRel / ML / Audio / Quantum Computing / Infrastructure & Platform Engineering.

Recent Profile Visitors

1236 profile views
  1. @danek121 od wielu lat jest w macOS aplikacja Automator, która z pewnością da sobie z tym radę.
  2. Na $299 bym nie liczył - przedział $250-400 to półka cenowa Chromebooków i komputerów z W10S - Apple wciąż stara się pozycjonować jako marka "premium", więc z ich perspektywy bardziej adekwatnym byłoby $499, co przy aktualnej cenie Maca Mini ($799) i kilku cięciach budżetowych (spowodowanych np. wsadzeniem taniego w produkcji ARMowego APU) jest do osiągnięcia.
  3. Z97 jest wciąż wspierane - do odpalenia jest zarówno Haswell, jak i Broadwell - ot kwestia posiadania SMBIOSu iMac14,4 lub iMac15,x.
  4. A kto powiedział, że otwartej... wystarczy, że wypuszczą kolejną kartę a'la Afterburner (do której w zasadzie też nie będzie dokumentacji) za jedyne $2000, pod nazwą "akcelerator obliczeniowy Jabłko TimKuk 123abcxyz", która to karta będzie określana jako "karta akceleracyjna PCIe, która odciąża procesor włączając kalkulator" - i po sprawie.
  5. Owszem, bo nie od dziś wiadomo, że Apple próbuje uciec od ARMów, głównie z racji wysokich opłat licencyjnych. Od 2014 w Apple są co najmniej dwa zespoły R&D pracujące nad ich własną architekturą, nijak niezwiązaną z ARM - z własnego doświadczenia powiem, że zejdzie im co najmniej drugie tyle, zanim efekty ich prac zobaczymy gdziekolwiek. Owszem, bo do tego to zmierza - "podstawa" będzie na ARM, a reszta to po prostu masa kart rozszerzeń. Takie CPU x86 czy inne FPGA czy ASIC będą po prostu kartami na PCIe (czy pod inny interfejs), tak jak np. karta Afterburner, czy Xeony Phi.
  6. Nie wiem, co rozumiesz przez: jeśli mówisz o szczytowej, chwilowej, iście "benchmarkowej" wydajności, to takowe już mają, w obrębie ograniczonej liczby API systemowych - ale i benchmarki między platformami się różnią, więc wynik np. 5000 pkt na ARM nie jest wynikiem nadającym się do porównania z 5000 pkt na x86, bo to nie te same punkty i nie ta sama skala. Jeśli jednak mówisz o wydajności rzeczywistej, to i tak porównujemy tu jabłka () z gruszkami, a wyjaśnienie znajdziesz w mojej poprzedniej odpowiedzi w tym temacie. Przecież rynek takich osób to nawet nie promil użytkowników sprzętu z jabłkiem - stąd Apple nie musi o nich dbać, bo to się po prostu fiskalnie nie opłaca niemniej, Apple od dawna zarabia konkretne pieniądze przez AppStore, stąd tak czy tak będą musieli zapewnić dostępność środowisk programistycznych na ich platformy, a to w zasadzie od razu implikuje możliwość instalacji zewnętrznych bibliotek, aplikacji i skryptów, więc o to bym się nie martwił. Po prostu menedżery paczek takie, jak homebrew zostaną zastąpione przez ich ARMowe odpowiedniki ("homebrew-arm" ). Instalacja Windowsa wciąż będzie możliwa, w końcu istnieje Win10 ARM - po prostu będzie on wyraźnie odstawał wydajnościowo macOSowi, głównie z racji optymalizacji architektury CPU pod jeden konkretny OS.
  7. Ale tu nikt nie mówi o i9 na Z370; po prostu aby ruszyć CPU (i3, i5, i7, i9) dziewiątej generacji (tj. modele z numerkiem 9000, np. i3 9100, i5 9400, i7 9700), potrzebujesz zaktualizować UEFI. Z370 domyślnie wspierały i3, i5 i i7 ósmej generacji, tj. modele z numerkiem 8000 (takie, jak i3 8100, i5 8400, i7 8700, etc.).
  8. @314TeR Nie do końca się z Tobą zgodzę. ARMów od lat używa się z powodzeniem w serwerowniach, przy czym zazwyczaj nie jest to sprzęt do wysokowydajnych obliczeń bazujących na CPU, a bardzo często trafiają one do macierzy dyskowych i do akceleratorów korzystających głównie z GPU. Apple nie wprowadza na tym polu rewolucji. Przeskok między PPC i x86 to zupełnie inny problem niż przeskok z x86 do ARM, gdyż zarówno x86 jak i PPC projektowane były do tych samych celów (głównie desktopy i długotrwałe obciążenie), a do tej pory nie pojawiły się ARMy projektowane stricte w tym celu - wciąż ich głównym celem jest energooszczędność w środowisku wielu krótkotrwałych obciążeń - stąd taka a nie inna architektura rdzeni, ich ilość, jak i ich aranżacja (m.in. big.LITTLE). Długotrwałe, stałe 100% obciążenie na ARMach aktualnej konstrukcji się kompletnie nie sprawdza - zawodzi cache, w sytuacjach, gdy aplikacja musi korzystać z wielu wątków jednocześnie i każdy jest maksymalnie obciążony, a jest to wciąż codzienność komputerów w zastosowaniach profesjonalnych (w szczególności przy obliczeniach, kodowaniu audio lub video, czy trenowaniu sekwencyjnych modeli NN, przy których GPU na niewiele się zdaje). Pełen przeskok z x86 na ARM to co najmniej 2-3 lata, gdyż Apple potrzebuje trochę czasu na przygotowanie nowej architektury ich CPU - ARMy produkowane przez Apple optymalizowane są na poziomie architektury pod ograniczoną ilość mobilnych API systemowych, w przypadku systemów desktopowych nie jest to takie proste, gdyż ilość dostępnych API jest znacznie większa, a nie sądzę, że Apple zacznie produkować układy o fizycznym rozmiarze na poziomie dwukrotnych rozmiarów Threadripperów na TRX40, czy też że Apple magicznie odetnie kompatybilność z aplikacjami z macOS 10 i pozostanie na aplikacjach z iOS. Potrzebne im będzie też kilka nowych ASICów w stylu Afterburner card, by zapewnić odpowiednią wydajność wszędzie tam, gdzie ARM się po prostu nie nadaje. Ponadto, developerzy będą musieli przepisać znaczną część kodu ich aplikacji - tu nie wystarczy kompilacja pod inny target OS - aby cieszyć się przyzwoitą wydajnością na ARMach potrzebne będzie w wielu przypadkach ugryzienie na nowo tematu wielowątkowości. Największa szansa na większą ilość montowanych ARMowych chipów i ASICów jest w MacBookach, Macu Mini, oraz w tym budżetowym iMacu - głównie będą zaprzęgane do prostych, specyficznych zadań, tak jak teraz. Nie zgodzę się też z Tobą, że jest to koniec sceny OSx86 - x86 w Macach będzie wciąż istniał, i to będzie mieć się dobrze jeszcze przez lata. Na rynku za to pojawi się więcej dostępnych platform wykorzystujących na jednej mobo zarówno x86, ARMowe CPU, jak i inne ASIC. Ba, w dobie wirtualizacji hardware (w tym ARMów na x86), jestem w stanie powiedzieć, że scena hackintoshowa będzie mieć się nawet lepiej, niż do tej pory.
  9. Tak czy tak, na wielu płytach na Z370 będziesz musiał zrobić aktualizację UEFI, aby ruszyły CPU serii 9000, wiele płyt z chipsetem Z370 po wyjęciu z pudełka wspiera tylko serię 8000. Co do nowszego chipsetu w postaci Z390 - też jest do ruszenia.
  10. W kwestii TB3, pod mATX będzie ciężko, ale jeśli nie przeraża Cię zwykły ATX, to jedną z najtańszych opcji będzie Gigabyte Z390 Gaming X + karta Gigabyte GC-Titan-Ridge - niestety, przy takim budżecie, szukać będziesz musiał obu z drugiej ręki.
  11. Jeśli nie jest to bardzo paląca sprawa, to na ten moment bym się wstrzymał, gdyż dużo zależy od tego, czy (a w zasadzie to kiedy) nowe Maczki dostaną Comet Lake - HT mimo wszystko trochę daje (jakieś 40%). Generalnie, do 2000 pln to na nic mniejszego niż mATX bym się nie napalał, gdyż zarówno budy mITX jak i mobo mITX są drogie. Kolejny minus płyt mITX to jedynie dwa sloty na RAM. Niemniej, na ten moment do 2k pln spokojnie wyrwiesz na nówkach coś w stylu i3 9100 (lub i5 9400) + mobo B360 mATX + 16 GB RAM + SSD 256 GB M.2 NVMe + zasilacz 500W 80 Plus Gold (modularny, jakiś beQuiet, SPC czy tani Seasonic) + jakaś obudowa. Ba, może nawet jakąś mobo na Z390 uda Ci się trafić. Max, do czego zrobisz tu upgrade to i9 9900k, RAM spokojnie wrzucisz i 64 GB (a nawet i 128 GB, jeśli tylko poszperasz za kościami 32 GB), a i zmieści się też normalna GPU, jeśli tylko potrzeba Ci coś więcej, niż iGPU.
  12. Zarówno Z270 jak i Z170 są do ruszenia, ale wpływają one na wybór CPU pod tę platformę. Z pewnością jednak nie schodziłbym poniżej 8 GB RAM, jest to w zasadzie takie kompletne minimum, by macOS nadawał się do użytku.
  13. Miałem ten sprzęt w rękach - jako mały komputer do pracy pod linuxem czy windowsem jest okej, o tyle pod macOS jest to kompletnie nietrafiony zakup - pokładowe WiFi jest nie do ruszenia, a i o wspomnianej "rozbudowie" to można tu tylko pomarzyć. Wymienić możesz w porywach dysk (M.2 NVMe 2280) i RAM (2x SO-DIMM DDR4). Max, jakie tu wsadzisz, to 64 GB. CPU jak i WiFi to wlutowane BGA, więc w zasadzie o wymianie możesz zapomnieć, bo nie będzie ani łatwa, ani tania (o dostępności innych CPU na FCBGA1528 nie wspominając). dGPU do NUCa nie wsadzisz, pozostaje jedynie eGPU na TB3.
  14. No to nie ma co bawić się w macOS, szczególnie, że na dłuższą metę pewnie przyda Ci się też pcie passthrough, a bez wsparcia dla VT-d możesz o tym zapomnieć. Skoro to ma być do nauki, to zakup poleasingowego desktopa na Ivy Bridge czy Haswellu będzie strzałem w dziesiątkę - coś pokroju HP 8300, Dell 7010, czy Lenovo M92/M92p w dobrym stanie wyrwiesz za góra 300 pln, dołożenie do tego RAMu (DDR3) do 16 GB to grosze, podobnie z SSD. W efekcie, poniżej 500 pln dostajesz konfigurację, na której Hyper-V, Proxmox czy ESXi działać będą znacznie sprawniej, niż pod macOS - w końcu jeden poziom bliżej do bare metal. Jeśli na hoście macOS chcesz wirtualizować cokolwiek innego niż macOS, to o nested VT-x nie masz co myśleć. Częściowy support dla fake-nested-VT-x był w virtualboxie przez chwilę, ale został wycięty w wersji 6.1. Są w zasadzie też checkboxy w Parallels i VMWare, ale nie działa to w pełni (spróbuj wewnątrz zwirtualizowanego środowiska postawić kolejny hypervisor, to zobaczysz co z tą opcją jest nie tak ). Soft do wirtualizacji jest mocno okrojony (w stosunku do linuxowych odpowiedników), a i wiele funkcji nie działa jak trzeba (EPT, MMU, problemy z zarządzaniem pamięcią, sypiące się VMki z error code informującym o nieprawidłowo działającej wirtualizacji). Opcja fizycznie w Parallels jest, ale to, jak ona w praktyce działa (a w zasadzie to dlaczego nie działa), to wręcz temat na całą książkę.
  15. @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.
×
×
  • Create New...

Important Information

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