Tag: komputer

Opublikowane w

Aktualizacje macOS

Pierwszą aktualizacją macOS, którą robiłem, była ta między „dużymi” wersjami, do wersji Catalina. Wtedy byłem umiarkowanie zadowolony, bo to duża aktualizacja. I pierwsza. I się udała. Od tego czasu miałem parę razy okazję aktualizować system między „małymi” wersjami i… wyrobiłem sobie zdanie.

Źródło: http://www.highstreetcomputers.com/apple-logo-broken/

Aktualizacje systemu w macOS to porażka, generalnie. „Duże” może nie są najgorsze, ale „małe” są tragiczne. Spójrzmy na listę aktualizacji Cataliny na Wikipedii, linkującą do opisu aktualizacji na stronach Apple. Od końca października 2019 do lipca 2020 było sześć aktualizacji. Każda to przynajmniej 3 GB do pobrania i blisko godzina stracona na aktualizację.

No właśnie, jeśli ktoś zastanawia się, o co mi w ogóle chodzi i czy da się system aktualizować lepiej, to szybko nakreślę jak wygląda proces aktualizacji w Linuksie. Otóż sprowadza się do pobrania pakietów i wykonania restartu. Cały czas można pracować na komputerze. Restart i okoliczne czynności nie trwają pół godziny, to zwykły reboot, jak każdy inny, czyli pewnie minuta. Aktualizowany jest zarówno kernel, kluczowe pakiety, jak i pakiety opcjonalne. Nie trzeba pobierać 3 GB, ale to już detal. Chodzi głównie o brak przerwy w możliwości korzystania z komputera.

No właśnie, gdy pisałem o aktualizacji do Cataliny i porównywałem jej czas z aktualizacją Debiana, popełniłem błąd. Porównywałem jabłka z gruszkami – w przypadku macOS brałem pod uwagę czas aktualizacji samego systemu, czyli podstawki, a w przypadku Linuksa systemu i wszystkich dodatkowych aplikacji będących w repozytoriach, a trochę tego jest (LibreOffice, Firefox, Chromium). Nie jest to aż tak ważne, bo to, czy pobieranie trwa pół godziny, czy godzinę nie ma większego znaczenia, jeśli można korzystać z systemu. Kluczowy jest czas niedostępności komputera.

Tyle o aktualizacjach systemu w makach, dopóki coś się diametralnie nie zmieni albo nie wybuchnie przy upgrade, nie będę wracał do tego smutnego tematu.

Opublikowane w

Catalina

Na początku października została wydana nowa wersja macOS o nazwie kodowej Catalina. Zaktualizowałem wczoraj i z okazji tego, że to mój pierwszy upgrade tego systemu, postanowiłem podzielić się wrażeniami z aktualizacji. Notka z tego jak mi się żyje z macOS nadal jest w planach, w trzech słowach: szału nie ma.

Aktualizacja z opóźnieniem, powody były dwa. Po pierwsze, nie ma tam żadnej zmiany, której specjalnie potrzebuję. Z rzeczy, które mnie potencjalnie dotykają ,widzę koniec wsparcia dla aplikacji 32-bit. Także zsh jako domyślna powłoka oraz lepsze security za sprawą dodatkowych uprawnień. Po drugie, czekałem z aktualizacją do Cataliny na zielone światło od zespołu zajmującego się desktopami w firmie, który sprawdzał, czy soft potrzebny do pracy działa poprawnie. Zresztą ogólnie wśród użytkowników maków zauważyłem tendencję do tego, by po wydaniu nowej wersji chwilę poczekać, na ujawnienie ew. błędów i ich poprawki.

Przyznaję, że sama aktualizacja jest zrobiona sprawnie, przebiega czytelnie i dość szybko. Dodatkowo przez większość czasu można normalnie pracować na systemie. Na szybkim łączu i dysku SSD pobranie 8 GB i instalacja zajęły nieco ponad godzinę, co uznaję za dobry wynik. Podobny czas zajmuje zaktualizowanie desktopu z Debianem. Pobranie, rozpakowanie, reboot, dłuższe uruchamianie i… jest. I działa.

Za to po instalacji trochę dzieją się cuda. Po części cuda te wynikają ze zmiany w security – trzeba pozwalać konkretnym programom na konkretne akcje. Ale po części są to zwykłe niedociągnięcia. Przykładowo jedna z pierwszych rzeczy, które mnie spotkały to:

git diff
xcrun: error: invalid active developer path (/Library/Developer/CommandLineTools), missing xcrun at: /Library/Developer/CommandLineTools/usr/bin/xcrun

Rozumiem, że rozwiązanie jest proste i łatwe do znalezienia. Jednak szukanie po forach rozwiązania problemu dla czegoś, co powinno się zaktualizować wraz z systemem? Przecież pochodzi od tego samego wydawcy i można było przewidzieć, że wymaga aktualizacji, skoro jest zainstalowane? Słabe.

Zapowiadanej zmiany powłoki na zsh jeszcze nie doświadczyłem – okazało się, że dla istniejących kont zostaje bash. Można wymusić zmianę ręcznie, co pewnie za jakiś czas zrobię.

W ogóle model zarządzania aktualizacjami aplikacji (nie mylić z systemem) pod macOS jest fatalny, zbliżony do Windowsowego. Czyli każda aplikacja żyje własnym życiem. Centralny manager pakietów, instalacja z użyciem repozytoriów i aktualizacje w jednym miejscu, znane z Linuksa są dużo łatwiejsze i wygodniejsze.

UPDATE Pochwaliłem za wcześnie. Dziś dostałem info, że dostępna jest aktualizacja do 10.15.1. Zacytuję opis z forum:

macOS Catalina 10.15.1 is a fairly significant update, introducing new emoji characters that were added in iOS 13.2 earlier this week, adding support for the AirPods Pro that are launching tomorrow, and bringing Siri privacy controls to the Mac to allow users to opt out of sharing their Siri recordings with Apple.

Jeśli ktoś przypuszcza, że jest mi to wszystko totalnie obojętne, to ma rację. Aktualizacja emoji zajęła pół godziny. I tym razem uważam, że to trochę sporo, skoro chodzi o takie drobiazgi.

UPDATE Minęło trochę czasu i wyrobiłem sobie ogólnie opinię o aktualizacjach macOS.

Opublikowane w

Mac i problemy z locale w terminalu – HOWTO

Jak pisałem, częściowo siedzę na macu. Zrozumiałem ludzi, którzy narzekali na obsługę systemu klawiaturą w macach. Wiele skomplikowanych combo na trzy palce. Ale to mogła by być kwestia przyzwyczajenia, zwłaszcza w trybie graficznym. Jeśli jednak ktoś korzysta głównie z terminala, to „fun” jest na zupełnie innym poziomie. Otóż funkcję klawisza Ctrl w macOS „normalnie” (czyli w GUI) spełnia lewy klawisz command, umieszczony tam, gdzie normalnie jest alt. Jeśli jednak przejdziemy do terminala, to w aplikacjach uruchomionych w konsoli żeby zrobić ctrl-c należy wcisnąć… control-c. Tak, jest też osobny klawisz control, którego należy używać w terminalu.

Jeśli jednak korzystamy z VirtualBox i uruchomimy tam Linuksa, to żeby utworzyć nową zakładkę w przeglądarce należy użyć… control-t. W GUI. W tej samej przeglądarce pod macOS używamy command-t. IMO totalna porażka UXowa i coś do czego nie sposób się przyzwyczaić, jeśli ktoś używa systemów na przemian. Można najwyżej nieustannie pamiętać, ale u mnie kończy się to masą missclicków. Zobaczę jeszcze co będzie po podłączeniu zewnętrznej, pecetowej klawiatury, choć to raczej z ciekawości – w końcu to nie stacjonarka. Ew. poszukam jakiegoś software’owego rozwiązania, choć staram się unikać przemapowywania klawiszy jak mogę – ciężko się później korzysta z instrukcji w necie.

Z pozytywów – doceniam działające kopiowanie i wklejanie w terminalu przy pomocy command-c i command-v. Pod Linuksem są na to osobne skróty, choć do tego akurat używałem myszy i zaznacz (i automatycznie skopiuj) i środkowego przycisku do wklejania. Domyślnie działa też – analogicznie jak pod Linuksem – wklejanie zaznaczonego w terminalu tekstu przy pomocy środkowego klawisza myszy. Niestety, jest ograniczone do konsoli, aby skopiować jakieś polecenie z przeglądarki trzeba już używać skrótów klawiszowych.

Wracając do tematu z topica. Po zmianie systemu na macOS i logowaniu przy pomocy ssh na serwery witał mnie komunikat w stylu:

-bash: warning: setlocale: LC_ALL: cannot change locale (pl_PL.UTF-8)
-bash: warning: setlocale: LC_ALL: cannot change locale (pl_PL.UTF-8)
-bash: warning: setlocale: LC_ALL: cannot change locale (pl_PL.UTF-8)

Sprawa jasna, problem ustawieniami locales, tyle, że nigdy mi się nie zdarzał, w systemie (macOS) niby są ustawione. Na chwilę odpuściłem temat, bo mało estetyczny komunikat przy logowaniu to nie dramat, ale szybko okazało się, że potrafi to wpływać – rzecz jasna ujemnie – na działanie poleceń i skryptów. Gdy tylko siadłem do szukania rozwiązania okazało się, że problem jest popularny, wręcz powszechny.

Pierwsze rozwiązanie, które znalazłem, wyglądało elegancko i nawet tłumaczyłoby, czemu nie działa skoro locales są ustawione. Niestety, po włączeniu i otwarciu nowych zakładek w terminalu, a nawet restarcie terminala okazało się, że… nie działa. Teraz widzę, że rozwiązanie jest stare, z 2012, wtedy mi umknęło.

Dopiero tu znalazłem faktyczne rozwiązanie problemu z locale w terminalu pod macOS. Jest proste i sprowadza się do dodania dwóch linii w pliku ~/.bash_profile:

export LC_ALL=en_US.UTF-8
export LANG=en_US.UTF-8

Powinno działać także z wersją polską, ale nie testowałem – w moim przypadku powyższa wersja jest OK, przynajmniej po pobieżnym sprawdzeniu nie zauważyłem problemów. Ustawienie z pierwszego rozwiązania również zostawiłem.