Kissé kritikus cikk következik, néhol talán igazságtalan, merőben szubjektív, amivel szabad egyet nem érteni. Az eredeti cím a „Mikor veszett el a régi Apple?” lett volna, de szándékosan nem szerettem volna a „Steve idején bezzeg” táborhoz csatlakozni, hiszen akkor is voltak túlkapások, kényelmetlenségek és butaságok a cég részéről.

Mint a macOS Catalina béta tesztelője, együtt éltem a rendszer hibáival, félkész újdonságainak lassú kiforrásával. Számos olyan fejlesztés került a rendszerbe, amely látványosan javítja a felhasználói élményt: brilliáns lett a Photos / Fotók alkalmazás, gyorsabb, ügyesebb, sokoldalúbb. Az iTunes szétszedése sokak számára egyszerűsíti, árnyalja a Mac használatának élményét, hiszen miért is egy zenelejátszó alkalmazásban kellett az iPad költözést véghezvinnünk? A Sidecar - ha épp jól működik - igazán nagy ötlet, bár néha még tud olyan hibákat, mint a duetDisplay tudott. :)

Amit fájdalmasan hiányolok immáron sokadjára az Apple operációs rendszereiből, az a végtelen következetesség és egyszerűség, ami régebben alapvető volt, és ami miatt a cég termékeit megszerették az emberek. Ahogy egy kedves ügyfelünk szokott fogalmazni: „amerikai háziasszonyoknak szánták a termékeket,” vagyis ügyeltek arra, hogy a felhasználói élmény végtelenül egyszerű legyen.

Az első pofon akkor ért a végleges rendszerrel kapcsolatban, amikor telepíteni próbáltam. A béta után manuálisan le kellett töltenem a végleges verziót, mert bár eltérő az Build ID, a rendszer mégsem ajánlotta fel a frissítést. Vagyis a bétáról a véglegesre egy újratelepítés volt az út. Nincs ezzel semmi baj, jó néha egy újratelepítés a Mac gépek világában is. Letöltöttem a telepítőt, végigmentem a lépéseken, majd egy utolsó kérdésben a telepítő megerősítést kért arra vonatkozóan, hogy telepíteni szeretném a rendszert. Rányomtam Install / Telepítés gombra, és magára hagytam a gépet különféle egyéb feladatokat végezve, amíg a telepítés végbemegy.

Visszatérésem után a következő ablak fogadott… 



Egy ma már nem az Apple világban tevékenykedő régi kolléga mondta azt az Apple-ről még 2004-ben, hogy az a jó benne, hogy ott lehet hagyni egy telepítőt, kattintani kell párat, és mire visszatér a gép elé, készen van. 2019-re eljutottunk oda, hogy az Install / Telepítés parancs lenyomása után nem csak az iOS kérdez rá a letöltést követően még egyszer, hogy tényleg telepíteni szeretnénk-e a rendszert, hanem a macOS a telepítő első lépésének végigfutása után feldob egy újraindításra vonatkozó kérdést, hogy tényleg szeretnénk-e telepíteni… 

Ez egy végtelenül amatőr és szerencsétlen megoldás, hiszen a Mac-ben azt szerettük, hogy önálló. Miután kiadtuk a parancsot, nem kérdez, hanem teszi a dolgát. A macOS Catalina azonban még egyszer rákérdez, hogy tényleg újra akarunk-e indulni, és ezzel elindítani a telepítést, ami fura kérdés azt követően, hogy elindítottuk a telepítő alkalmazást, végigmentünk rajta, megadtuk a céllemezt, majd egyetértve a licenccel tovább is léptünk a telepítés parancsra bökve… A Mac másfél órát állt várva a választ, és amikor visszatértem dolgozni, nem volt fenn a végleges rendszer… 

Számos figyelmeztető gondolatot megjelenítettünk azzal kapcsolatban, hogy a Catalina immáron nem csak szól, hogy bizonyos programok régiek és nincsenek optimalizálva, hanem el sem indulnak… Ennek ellenére az első nap a megjelenés után kétségbeesett gondolatokról szólt, hogy számos dolog nem fut. Az alkalmazások többségéről a telepítéskor maga a rendszer tájékoztatja a felhasználót, ám vannak olyan bővítmények, amelyekről a felhasználó nem tudja, hogy azok túl régiek. Számos Apple alkalmazás sem indul el többé - megszoktuk, hogy minden frissítés után új Server alkalmazást és Remote Desktopot kell vennünk, hogy ugyanarra a célra használhassuk a programjainkat. Az Aperture idejét múlt, de vannak felhasználók, akik megszokták, szerették, kicsit drasztikus volt tehát az Apple lépése, hogy lezárta a támogatást. Ha annyira egyszerű egy program frissítése Catalinára, ahogyan a WWDC-n mondták, akkor vajon az Apple miért nem tudta saját alkalmazásait frissíteni, hogy a felhasználói kör érezze a törődést?

Itt kell megemlítenem mégis a „bezzeg Steve idején” gondolatot. Aki régóta használ Mac-et, annak a Rosetta szó még jelenthet valamit: ez egy olyan technológia volt, amely révén a PowerPC alkalmazások az Intelre váltás után még évekig elindultak az új Mac gépek alatt… Akkoriban persze az Apple jóval kisebb cég volt, a Mac felhasználók száma törékeny, hibahatár alatti értéket jelentett. Mégis fontos volt, hogy az átállásra lehetőség legyen évekig. Tim Cook hajszolta bele az Apple-t abba a spirálba, hogy a macOS rendszereket évente óriásinak nevezett frissítésekkel bombázzák, amelyekből a felhasználók többsége csak annyit vesz észre, hogy ugyanaz a feladat, ami eddig működött, már nem végezhető el, mert ez és az a szoftver nem indul el.

Vegyük csak a ennek a rém egyszerű weblapnak a működését! A Fetch nevű FTP kliens segítségével kerültek feltöltésre a tartalmak, amelyeket a BBEdit kistestvére, a TextWrangler segítségével szerkesztettem. Mindkét program elképesztően egyszerű, évtizedek óta a piacon vannak, nem is igazán várt el az ember frissítést tőlük, hiszen semmi forradalmi nem történt a világban ezeken a területeken. Igen ám, de az Apple megkötötte a fejlesztők kezét, és kötelezővé tette a 64-bites alkalmazások kiadását, mert már csak azok futnak az új rendszeren - a Mojave csak figyelmeztetett, hogy optimalizálni kell, a Catalina már erőszakos, ő elindulni sem engedi ezeket a régebbi, de a funkciójukat tökéletesen ellátó alkalmazásokat. A Fetch elindított egy béta programot, és kiadták a szoftver új változatát - ez azért nagy áldozat a fejlesztőtől, mert a szoftver ugyanazt a feladatot fogja ellátni az alapoktól újraírva is, és a licenc elvileg élethosszig tartó, emiatt nem is kérnek el pénzt a frissítésért, csak egy 5.8-as alverzióval oldják meg a feladatot. A TextWrangler ingyenes alkalmazás volt, és a fejlesztő egyszerűen nem adott ki belőle újabbat. Érdekesség, hogy az App Store-ból továbbra is letölthető a meglévő verzió, de az nem indul el a macOS Catalina rendszer alatt - az App Store szűrője elvben ki kellene, hogy iktassa az ilyen szoftvereket, tehát az Apple itt sem végzett tökéletes munkát. A TextWrangler helyett a sokkal komolyabb, ám a felvázolt igényekhez túlzó BBEdit programot kell használnom, amely havi előfizetési díjas, és havi 1500 Ft-ba kerül, hogy elvégezzem azt a feladatot, amit az elmúlt 18 évben ingyenes alkalmazással végeztem… Tapintható tehát az előrelépés és fejlődés.

Ez egy kiragadott példa, de hány grafikus, zenész, filmes fog siratni bővítményeket, amelyek 32-bitesen meg lettek írva egykor, és már senki nem fogja őket frissíteni? Az Apple zseniális programozói, akik évente új operációs rendszer verzióval állnak elő, és olyan átütő újdonságokat mutattak be, mint a sötét mód, nem tudtak írni egy virtuális környezetet, ahol a brutális erejű processzorok megbirkóznak a 32-bites alkalmazásokkal és bővítményekkel, tudomásul véve azt, hogy egy egyszerű forráskód szerkesztő nem fog 300x gyorsabban futni, csak a gépelésünk tempójában…

Az Apple ezt megteheti, mert óriási a felhasználói bázisa, és közben a marketing gépezet ír egy bizonyos Catalyst nevű technológiáról, amely nagyon jól hangzik, de nem oldja meg ezeket a kihívásokat - a Catalyst célja, hogy az iPadOS alá írt alkalmazásokat nagyon egyszerűen átalakítsák macOS alkalmazásokká. Ennek köszönhetően a felület is inkább az iPadesre emlékeztet, de az Apple bizakodó, hogy rengeteg olyan alkalmazás elérhető lesz a Mac-re is, amely eddig csak az iPad felületén futott. Az iPad alkalmazások átírása a Mac-re azonban nem pótol olyan kieső alkalmazásokat, amelyek évtizedek óta alapvetőek voltak sok felhasználó életében. Az Apple számára fontos volna belátni, hogy egy számítógép nem egy divatcikk, amit évente cserél az ember. A számítógépre írt operációs rendszert sem kell évente frissíteni, szigorítani a használat lehetőségeit és szabályait, félkész funkciókat kiadni, amelyek majd valamelyik alverzióban teljesednek ki. Ehelyett a Steve Jobs által diktált kétéves, kiforrott stílusú frissítési ütem volna a kívánatos.

Szakmai körökben gyakorta vicceljük meg egymást azzal, hogy melyik operációs rendszerhez melyik újdonságot tudjuk társítani. Annyira értelmetlenül gyors a frissítési ütem, hogy már nem tud az ember fejből feldobni mondjuk egy olyan újítást, ami a Mavericks vagy a High Sierra rendszerhez markánsan kötődik.

Visszás számomra a biztonsággal kapcsolatos illúziók keltése az Apple részéről. Tudjuk, hogy a processzorok legmélyén futó kódban rejlő, hardver eredetű hibákat ismerték és ki is aknázták. Innentől kezdve eleve illúzió volt bármilyen sallang a biztonságról, de tételezzük fel, hogy ezeket a kilencvenes évek közepe óta jelen lévő problémákat kijavították a becsületes cégek, és csak elcsendesült a média visszhang a témában hirtelen. Az Apple azt sugallja magáról, hogy a rendszere biztonságos, és ezt számos információval alá is támasztja. Ennek ellenére az operációs rendszer a már hitelesített felhasználótól lépten-nyomon jelszavakat kér, az iOS eszköz csatlakoztatásakor újra és újra megbízhatónak kell nevezni magunkat, és számos alkalommal azonosítás szükséges. Az Apple azt mondja, hogy ez a biztonság érdekében van, de ha valami biztonságos, akkor miért kell újra és újra azonosítani magunkat? Ha egy családi ház jó környéken van, akkor szerelünk fel egy jó zárat, riasztót, esetleg kamerát. Ha a házat vizesárok veszi körül, és úgy tudunk este munka után hazamenni, hogy mindenhol fémdetektorral vizsgálnak át, ujjlenyomat olvasnak le, néhol a kulcsunkat is elő kell venni, az nem azt sugallja, hogy jó környéken élünk. Számomra a macOS által erőszakolt újabb és újabb hitelesítési igény, amely a mindennapi használat során jelen van, valami ilyesmi érzetet fejez ki. Nem az az érzésem, hogy annyira biztonságos az egész rendszer, hanem az, hogy az Apple inkább 93 helyen jelszót kér, nehogy véletlenül a nagy bizonytalanságból valami durva betörés vagy adathalász hozzáférés legyen.

Szeretnék egy olyan rendszert, ahová belépéskor hitelesítem magam, és utána a rendszer elhiszi, hogy én vagyok a felhasználó, és nem mennek el értékes percek azzal, hogy az ujjamat nyomkodom a Touch ID azonosítóhoz, vagy asztali gépen a biztonságos hosszú jelszavamat irkálom be számtalanszor. Ha a rendszer biztonságos, nem látom indokolhatónak azt, hogy lépten-nyomon azonosítani akar.



A macOS az APFS fájlrendszer megjelenése óta hadi lábon áll a tárhely foglaltság témakörével. A felhasználókat rendszeresen hozza zavarba, hogy látszólag törölnek tartalmakat, de a hely nem szabadul fel, és a rendszer akár csak hetek elteltével frissíti saját adatát arról, hogy mennyi is a szabad hely. Az Apple szép új Emoji karaktereket fejlesztett, ám ezt a területet nem javította, a jelenség továbbra is fennáll. Íme két illusztráció a System Information / Rendszerinformációk alkalmazásból, amelyben eltérő a szabad hely, ám a színes vizuális információból ez nem látszik, ott a rendszer azt sugallja, mintha tele lenne a gép SSD-je.

Sajátos jelenség az is, hogy míg a hely felszabadítás után a System Information / Rendszerinformáció már esetleg helyes adatot közöl, a Finder és a Disk Utility / Lemezkezelő még órákig téves adatot jelenít meg annak ellenére, hogy a programokat újraindítjuk, tehát elvben friss adatot kellene lekérniük… Hogy is van ez? Egyazon számítógép ugyanazon meghajtóján az egyik Apple alkalmazás szerint 776 GB szabad hely van, míg a másik szerint 469? Nem az volt a Mac vitathatatlan előnye, hogy egy cég fejleszti a hardvert, az operációs rendszert és a felhasználói szoftverek egy részét?

Értetlenül állva a hiba előtt átfutottam azt a felületet, ahol tárhelyet lehet felszabadítani. Indokolatlanul sok helyet foglaltak ugyanis az iOS Files / iOS Fájlok alatt található biztonsági mentések. Gondoltam törlök egy párat közülük, de aztán be kellett látnom, hogy nem vagyok elég körültekintő felhasználó, mert nem ismerem az eszközeim és az ismerőseim eszközeinek UUID azonosítóját… Az Apple kínál felületet arra, hogy töröljük a nagy tárhelyzabáló tartalmakat, de nem a készülék nevét írja ki, hanem az UUID-t… Mintha egy autókereskedésben nem az autó típusa, formája, színei, paraméterei alapján kellene választanunk, hanem a kezünkbe nyomnának egy sor rendszámot, és az alapján kellene álmaink járművét megvenni…

Az iOS biztonsági mentéseket egyébként úgy tudjuk könnyen törölni, ha a gépre csatlakoztatunk egy iOS eszközt, és az ekkor megjelenő, az eszközhöz tartozó felületen találunk egy Manage Backups / Biztonsági mentések kezelése gombot. Arra kattintva a rendszer felsorolja a meglévő mentéseket - forradalmi módon név szerint! Innen kijelölést követően tudunk törölni.



Érdekesség, hogy miután töröltem a feleslegesnek vélt tartalmakat, egyes eszközök mentéseinek neve megjelent a System Information / Rendszerinformációk ablakban. A már letörölt mentések ellenben Zero KB mérettel továbbra is jelen voltak az ablakban UUID alapján listázva… 

Vannak olyan dolgok egy számítógép működése kapcsán, amely igényként merül fel az emberben, de nehezen megfogalmazható. Ilyen például az a fajta odafigyelés, hogy a nagy erőforrás igényű folyamatok lehetőleg ne akkor fussanak, amikor a mobil gépet akkumulátorról használjuk. Mint óriási fotótárral rendelkező felhasználó, a nagyobb Photos / Fotók frissítések során órákig, napokig vagy akár hetekig tartó folyamatok indulnak el. A macOS Catalina például újraelemezte az összes fényképet. Ez örömteli, hiszen több a keresési kritérium, mint korábban, ezáltal sokkal könnyebb keresni a képek között. Az Apple jól felismerte ezt az igényt, hiszen ahogy több és több képünk lesz, egyre kevésbé van mód arra, hogy manuálisan lássuk el paraméterekkel, metaadatokkal a fotókat, így nagyon kívánatos, hogy a rendszer önmaga elemzi a képeket. Az arckép elemzésnél van is ígéret arra, hogy az elemzés akkor történik majd, amikor a Photos / Fotók nem fut, és a Mac töltőre van csatlakoztatva. Igen ám, de a tapasztalatok alapján a Photos / Fotók igen aktív folyamatokat indít el olyankor is, ha a Mac akkuról megy: a photoanalysisd, a photolibraryd nevű daemonok ugyan pár perc után visszaveszik magukat, ha a Mac akkuról fut, de a com.apple.MediaLibraryService nevű folyamat gátlástalanul eszi meg az akkumulátort. Ez a folyamat nem a fotóinkat elemzi, hanem a HEIC fotókat és a HEVC videókat alakítja át a fotóadatbázisból olyan formátumra, hogy más alkalmazások számára előznézeti tartalomként megjelenhessenek. Tehát a Photos / Fotók alkalmazáshoz kötődik, de nem nyújt igazi pluszt, inkább csak a sajátos formátummal kapcsolatos áthidalást végzi nekünk - értékes perceket rabolva le a Mac akkumulátor idejéből.

És itt felmerül a következő olyan dolog, amely a macOS Catalina terén számomra a leginkább hiányolt, be nem teljesedett újítás lehetett volna. Nem mondható el, hogy az évek alatt drámaian változtak volna a felhasználói szokásaim: reggel munkába menet híreket olvasok, írok, üzeneteket váltok, árajánlatot írok, közben az iPhone rá van dugva a MacBook Pro egy USB-C kapujára, hogy internetet osszon meg. A WiFi ki van kapcsolva, a Bluetooth az egér miatt aktív. Néhány éve 72-81% közötti állapotban volt az akkumulátorom, amikor beértem munkába. A macOS Catalina alatt volt már olyan, hogy lemerült a gép, de rendre 27-46% közötti értékeken van nagyjából azonos munkavégzés közben… 

Az Apple a fejlesztési rohanás közben elmulaszt olyan fontos dolgokra is figyelni, mint hogy az operációs rendszer tényleg takarékoskodjon az árammal. Néhány éve a Time Machine mentési ikon azért szűnt meg forogni mentés közben, és azért kell most plusz kattintással megnézni az aktivitását, mert az Apple energiatakarékos akart lenni. Most nincsen egy olyan korlátozás beleírva a rendszer kódjába, hogy ha akkuról fut a Mac, akkor egy sor folyamat ne indulhasson el, mert az órákat vesz el az akkumulátor élettartamából. Ennek nyomán az általam végzett, teljesen átlagos vagy az alatti felhasználás közben a Mac 10 órásra ígért akkumulátor élete 3,5-5 óra. Az ígért érték 35-50%-a. Nem azért, mert a hardver rossz, hanem mert az operációs rendszer nem figyel oda arra, hogy akkumulátorról üzemel, és elképesztő mértékben pocsékol. Ez több szempontból is rossz: egyrészt lemerül a gép, másrészt hamarabb elfogy az akkumulátor, amely AppleCare csomag mellett az Apple-nek fog pénzébe kerülni, harmadrészt pedig a felhasználó combját folyamatosan melegíti a gép, amely kellemetlen élményt nyújt a használat során.

A macOS 25., illetve szűkebben véve a Mac OS X 16. verziója kapcsán úgy gondolom, nem a valóságtól elrugaszkodó elvárás lenne egy olyan operációs rendszer, amelyik figyeli azt, hogy akkumulátorról üzemel, és az olyan feladatokat, amelyek elvégzése éppen nem szükséges, átidőzíti arra az időre, amikor töltőre lesz csatlakoztatva. Vagy akár legyen egy ilyen beállítás az Energy Saver panelen… De nincsen. Van helyette brokkoli Emoji és jelszókérés.

Screen Time / Képernyőidő - Ha kíváncsiak vagyunk, hogy mennyi időt futnak az alkalmazásaink

Két évtizedes Mac felhasználói múltam alatt ritkán fordult elő velem az a fajta bizonytalan érzés, amikor úgy éreztem, hogy valami nem lehet ilyen haszontalan, tehát biztosan én használom rosszul.

Az egyik ilyen évekkel ezelőtt az Aperture alkalmazásban volt: ha egy diabemutatóba videót is helyeztem, sehogyan sem lehetett lehalkítani a hangját, így a videórészlet hangja beleordított a produkcióba, így használhatatlan lett. Mint kiderült, itt az Apple hibájáról volt szó, amelyet aztán sohasem javítottak ki. Természetesen a videó hangsávjának törlésével más programból lehetett olyan nyersanyagot készíteni, amitől használhatóvá vált a létrehozott diabemutató.

Kizártnak tartottam, hogy 2019-ben az Apple bemutat egy olyan funkciót, amely ennyire félkész élményt jelentsen, de mégis megtörtént: a macOS 10.15 Catalina a korábbi Parental Control / Szülői felügyelet funkciót eltörölve bemutatott egy teljesen más megközelítésű Screen Time / Képernyőidő funkciót, amely egyáltalán nem egy Mac-re alkotott dolog, helyette ismét egy olyan konstrukció, amelyen érződik, hogy az iOS rendszerből írták át a macOS-re.

Ezzel kapcsolatban eleve van egy ellenérzése az embernek, hiszen számos olyan dolog van, ami jó élményt nyújt a mobiltelefonon, de nem nyújt jó élményt a számítógépen. A Mac esetén a szülői felügyelet arról szólt, hogy volt a gépen több felhasználói fiók, és a szülő tudta korlátozni, hogy mondjuk a gyermeke napi 30 perc YouTube nézésnél többre ne ragadtassa magát, vagy éppen 1 óránál tovább ne használhassa a Facebook Messangert, illetve mondjuk 21.30-kor a gép kikapcsoljon vagy elaludjon.

A Screen Time / Képernyőidő szintén ad korlátozási lehetőségeket, de a korábban beállított szülői felügyeleti paraméterek mindegyike törlődik. Ha tehát volt a családi iMac-en egy jól felépített rendszerünk arra vonatkozóan, hogy gyermekeink mennyi ideig és mit csinálhatnak a gépen, az a macOS Catalina frissítéssel alapjaiban elveszett… Ez nem kimondottan elegáns dolog az Apple-től, ráadásul míg az alkalmazások inkompatibilitására felhívja a figyelmet a frissítés előtt, a Parantal Controls / Szülői felügyelet panel egyszerűen eltűnik a System Preferences / Rendszerbeállítások programból, és vele együtt a beállításoknak is búcsút inthetünk. Vajon miért gondolják azt jól fizetett programozók, hogy az ember szívesen vesződik újra a beállításokkal? Ráadásul úgy, hogy Tim Cook amolyan szentfazékként beszélt 2019. nyarán több alkalommal is arról, hogy mennyire fontos a szülői jelenlét a gyermekek védelmében az információ technológia világában…

A Screen Time / Képernyőidő kapcsán azonban nem az a legnagyobb baj, hogy otromba módon törli a korábban elvégzett beállításainkat, hanem a működésének végtelenül amatőr módja, amely egyértelműen mutatja, hogy szimplán átírták iOS rendszerről, és a szükségesnél egy perccel sem több erőforrást fordítottak rá. A használat során arra lettem figyelmes, hogy minden alkalmazás szinte ugyanannyi időt fut, és csak az volt látványosan kevesebb, amit később indítottam el. Néhány óra Mac használat után világossá vált, hogy a funkció egyszerűen az alkalmazás futási idejét mutatja, és nem a használatot. Nyilván nem használtam egy nap 8 órát a számológépet, újabb 8 órát a naptárt, majd 8 órát a levelezést, 8 órát a Messages / Üzenetek alkalmazást, 8 órát a Safari böngészőt… Egyszerűen csak arról van szó, hogy a Screen Time / Képernyőidő nem a tényleges használatot veszi alapul, hanem azt az időt, amennyit az adott program fut. Ez az iOS rendszeren akár még hasznos is lehet, hiszen ott az aktív programot ténylegesen használjuk, vagy legalábbis látjuk, nézzük. De a Mac-en egy háttérben folyamatosan futó Messages / Üzenetek alkalmazás nem azt jelenti, hogy egész nap buborékokat küldtünk valakinek, hanem nyilván azt, hogy nem lépünk ki minden üzenetváltás után a programból, hanem az fut a háttérben. A macOS Catalina alatti Screen Time / Képernyőidő alkalmazás a háttérben futást is használatnak veszi, és ami teljesen haszontalanná teszi, hogy a háttérben futás is beleszámít a korlátozásba: vagyis ha beállítjuk, hogy mondjuk gyermekünk fiókja alatt napi 60 percet futhasson, akkor abba az is beleszámít, ha mondjuk a gyermek Pages-ben fogalmazást ír 40 percben, de a háttérben fut a Messages / Üzenetek. Így 20 perce marad arra, hogy ténylegesen üzeneteket váltson, mert a buta funkció nem vizsgálja, hogy előtérben van-e az alkalmazás.

Az iOS rendszeren, ahol a futó alkalmazás ténylegesen eltakarja a többi alkalmazást, ez működőképes megoldás, de a Mac alatt, ha már az Apple szükségesnek vélte átültetni ezt az iOS funkciót is a macOS rendszerbe, akkor kellett volna picit foglalkozni a dolog fejlesztés részével, és lehetőség szerint az alapján vizsgálni egy alkalmazás használati idejét, hogy mennyit volt az előtérben… Kizárólag ez határozza meg ugyanis a használat idejét, míg az, hogy a háttérben futott ugyanannyi időt, mint a rendszerindítást követően vele együtt elindított többi alkalmazás, teljesen haszontalan információ, és semmiféle érdemi adatot nem szolgáltat arról, hogy naponta mennyi időt töltünk el hasznosan a számítógép előtt, és mennyi időt fordítunk mondjuk üzenetváltásra.

Elsőre persze nem hittem el, hogy ez így működik, és kerestem a megfejtést, hogy hogyan lehet jól beállítani a Screen Time / Képernyőidő mérési adatait, de sajnos rá kellett jönnöm, hogy ezt a funkciót már nem a minden részletre gondoló Apple alkotta, hanem a macOS újdonságait az iOS tavalyi újdonságainak átírásából olcsón megúszó Apple írta át… 

Apróságok és nem is annyira apróságok, amelyek keserű perceket okozhatnak

Az Apple a macOS Catalina megjelenésével párhuzamban jelentősen átszervezte az iCloud Drive működését, logikáját. Ez a felhasználó számára alapból semmi látványosat nem jelentette, ám a háttérben komoly változások zajlottak le, ami miatt egy bizonyos bird nevű folyamat akár napokig dolgozott a gépünkön a háttérben, amíg a szinkronizálást elvégezte. Sokan nem értették, hogy a frissítés után napokkal vagy hetekkel később miért merül gyorsabban a Mac a kelleténél, vagy éppen miért zúg a ventilátor. Ennek egyik oka lehetett, hogy a bird folyamat akár 150-180% CPU kihasználtsággal is pörgött.

Sajnos a folyamat során előfordulhatott, hogy hiba csúszott a gépezetbe, és bizonyos tartalmak nem kerültek szinkronizálásra. Ezt onnan vehettük észre, hogy a mappa alatt a Waiting… / Várakozás… felirat jelent meg. Ha ilyen mappát áthelyeztünk egy szintén iCloud Drive-on lévő másik mappába - például a Desktop / Íróasztal felületéről egy másik helyre - előfordulhatott, hogy a szinkronizálás sosem történt meg. Mivel tipikusan olyan mappát teszünk el, amelyet nem használunk már aktívan, így előfordulhatott, hogy csak hónapokkal később derült ki, hogy egyébként a tartalom hiányos, és valahol elveszett út közben.

A jelenségre az hívta fel a figyelmet, hogy a felhasználói mappánkban létrejött egy Recovered Files nevű mappa, amelyben érthetetlen okból olyan fájlok szerepeltek, amelyeknek nem ott kellett volna szerepelniük. Számos esetben ez a hiba későbbi verziókban is előfordult, még a macOS 10.15.3 esetén is példa volt rá, hogy bizonyos dolgok átkerültek ebbe a mappába, és nem voltak megtalálhatóak az eredeti helyükön. Az eredeti helyen kiürült mappák voltak, amelyek a felhő ikonra bökve sem töltődtek meg tartalommal… Míg a felhő kapcsán az ember a biztonságot, a redundanciát feltételezi, a macOS Catalina kapcsán sajnos a potenciális adatvesztés lehetőségének rémképe jelent meg előttünk azért, mert van valami hiba a háttérfolyamatban, ami meggátolta számos felhasználónál az iCloud Drive normális működését.

Az esetleges megoldást a tartalmak lementése, az iCloud Drive kikapcsolása és teljes törlése, majd a visszaszinkronizálás jelentette, ez azonban olyan kényelmetlenség, amelyet nem szívesen néz el az Apple-nek az ember, amikor a gondtalan felhasználói élmény ígéretével kecsegtetnek.

Hogy a hiba még mindig jelen van, arra utal az a tény, hogy például az iCloud Drive-on tárolt Desktop / Íróasztal felületére mentett fájl nyitott állapotban való áthelyezése egy másik mappába tévedésből írásvédetté teszi a fájlt. Ha beleírunk, és menteni próbáljuk, a létrehozó program jelez, hogy sajnos nincsen lehetőségünk menteni, mert a fájl nem írható. Ha belegondolunk abba a könnyedségbe, hogy a Mac OS 9 alatt gondtalanul helyezhettünk át nyitott fájlokat a rendszeren belül bárhová, mindig minden megfelelően működött, ez elég komoly visszalépés 2019-re, illetve 2020-ra, hiszen a hiba jelenleg is reprodukálható.

Rendszer újratelepítés - A kereskedő küzdelmei

A macOS operációs rendszerek egyik legkedveltebb képessége több évtizedes felhasználás során az egyszerű telepítés volt. A Mac OS 9 alatt egyszerűen át lehetett húzni a rendszert egyik lemezről a másikra, és annyira okos volt, hogy máris lehetett indítani - ilyen semelyik másik operációs rendszernél nem volt, és borzasztó könnyűvé tette például egy használt számítógép újratelepítését. A Mac OS X UNIX alapra helyeződött, tehát ez a paraméter némileg bonyolódott, de előbb telepítő DVD-vel, aztán FireWire-ös, USB-s, majd Thunderbolt alapú meghajtóval játék volt újratelepíteni a rendszert.

A macOS Catalina ebben is változást hozott - mintha az Apple törekedne arra, hogy mindent megváltoztasson, ami könnyű és szerethető volt. Az Apple T sorozatú chipek megjelenése biztonságot jelent a rendszerek számára, hiszen korlátozható számos paraméter, akadályozható a hozzáférés a gép tartalmához, ha azt a tulajdonosa védeni szeretné.

Van azonban olyan élethelyzet, amikor a tulajdonos eladja a számítógépet, vagy egy nagyobb céges csere során egy egész flotta lecserélésre kerül. A költöztetést követően ilyenkor egyszerűen letörlik a régi gép lemezét, és leadják a számítógépet.

Igen ám, de az Apple gondoskodó csapata alapértelmezés szerint nem teszi lehetővé azt, hogy külső meghajtóról induljon a rendszer, és telepíthető legyen… Próbáltam megfejteni, hogy ennek milyen biztonsági oka lehet, hiszen internet alapú visszaállítás esetén telepíthető a rendszer, így arra a következtetésre jutottam, hogy ez tényleg csak a kereskedők életének megnehezítését célozza.

Egy külső meghajtóról 8-11 perc alatt újratelepíthető a macOS egy üres meghajtóra. Mivel a gépek tiltják a külső indítást, így marad az internet alapú visszaállítás - ez internet kapcsolattól függően 48-180 perc közötti időt igényel. Ha a telepítő betöltődik, elérhető a rendszerindítás védelmet szabályozó program, ám az felhasználói jelszót kér a külső lemezről indítás korlátozásának feloldásához. Mivel a lemez üres, nincsen már rajta felhasználó, így jelszó sem adható meg, tehát a korlátozás nem oldható fel. Nem világos, hogy az Apple-nél mi volt a cél ezzel, illetve hogy átgondolták-e, hogy milyen jelszót kellene megadni akkor, amikor a lemez le van törölve és üres, de a lényeg, hogy ez nem működik.

Hogy még egyszerűbb legyen az élet: ilyen esetekben általában nem az aktuális, hanem az eggyel vagy kettővel korábbi rendszer települ újra, mert a gép azt az Internet Recovery meghajtót éri el az Apple szervereiről. Vagyis a 8-11 perces telepítés helyett újratelepítünk egy korábbi operációs rendszert. Hogy a külső telepítő tiltás korlátozását feloldjuk, létre kell hoznunk egy fiókot, aminek van jelszava. Ezt követően ismét elindítjuk az Internet Recovery funkciót, ami az Apple szervereinek terhelésétől függően 13-35 perc alatt betöltődik, és itt a védelem funkciónál immáron létező felhasználóval ki tudjuk kapcsolni a tiltást.

Ezt követően 8-11 perc alatt külső meghajtóról tudjuk telepíteni az operációs rendszert, letörölve a 48-180 perc alatt teljesen feleslegesen feltelepített előző rendszert a felhasználói fiókkal.

Az ezzel kapcsolatos kálvária jól mutatja, hogy egyszerűen nincsen már meg az az érzete a macOS Catalina operációs rendszernek, ami az Apple legendához hozzájárult, hogy valaki mindenre odafigyelt, mindig volt egy végső tesztelő, aki észrevette a hibákat, és a végleges verzió előtt javíttatta azokat.

Mail - Végre tanulj meg számolni! És kilépni…

Az aktív levelező felhasználók már felismerhették, hogy a rendszerezés mellett a jelölések használata is igen praktikus, ha még nem zártunk le egy feladatot, de nem szeretnénk, hogy elvonja a figyelmet a többiről. Nem feltétlenül kell mindent az Inbox / Bejövő fiókban tárolni, hiszen lehet zászlóval is jelölni és elrakni a levelet, és a zászlóval jelölt levelek egy különálló Flagged / Megjelölt gyűjteménybe kerülnek. Itt aztán ahogyan teljesítjük a feladatainkat, örömmel láthatjuk, hogy a levelek fogynak. Vagy nem fogynak? A Mail - immáron sokadik operációs rendszer verzió óta - nem képes a valós levelesláda tartalmat kiírni: az ablak tetején ténylegesen jó számot ad, míg balra az eszköztárban és levelek fölött valótlan adatot közöl.

Erre mondhatnánk, hogy szokjunk át a felsőre, vagy ne használjuk a Mailt ebben az ósdi régies nézetben. Egyrészt ettől még nem oldódik meg a probléma, másrészt pedig felmerül egy kérdés az Apple oly takarékos és átgondolt programozási hagyományaival szemben: miért is nem egyazon változóra hivatkozik mindhárom kijelző hely? Van a Mail kódjában kettő számláló vagy valamiféle tár, ami egy régebbi adatot közöl, és van egy, ami aktuális információt jelöl? Ez nem csak pazarló, felesleges kódot jelent a programban, de erőforrást is igényel, ráadásul hibásan is működik, tehát nem túl igényes megoldás.

A Mail alkalmazással kapcsolatos kedvenc hibám, amikor egy rendszerfrissítésnél újra szeretném indítani, de a Quit / Kilépés parancs elszürkül, és szabályosan sosem lép ki a program. Ez a hiba Mac OS X 10.2 óta jelen van a rendszerben, tehát nem vártam, hogy a nagy hirtelenjében összecsapott Catalina oldja majd meg, nem is lett így. Erre a megoldás csak a kényszerített kilépés, amely nem túl barátságos módja, hogy kiszálljunk a levelezésünkből.

Disk Utility / Lemezkezelő - A butítás maradandó lett

Amikor Sir Jonathan Ive átvette az interfész tervezés feladatát az Apple-nél, voltak olyan változások, amelyek sokaknak nem igazán tetszettek. A zseniális hardver tervező a szoftverek világában nem mindig találta el, hogy mitől lesz jó egy alkalmazás vagy akár csak egy felület. Az ugyanolyan fehér lapoknak csak a tartalma különbözött, és bizony nem volt már jellegzetes egy-egy alkalmazás pusztán a megjelenése, az ablak szélei okán.

A forradalmi áttervezés egyik áldozata a Disk Utility / Lemezkezelő lett, amely eleinte annyira fejlett volt, hogy nem kellett külső szoftver vagy Terminal a lemezműveletekhez. De aztán…

Miután az Apple szinte minden gépében áttért a szilárdtest meghajtókra, a tárhelyet kerek formával kezdték illusztrálni, mint a forgó merevlemezeket. A tárhelyünk egyfajta diagrammá vált, amelyen sok esetben az a remek tulajdonsága is megvan, hogy egyszerűen nem tudunk kiválasztani egy kisebb méretű partíciót, ha ilyen hoztunk létre.

A látványosan nehezebben használható kezelőfelület mellett az igazán bosszantó dolog a működéssel van: ha az ember klónozni akar egy rendszert egy másik meghajtóra, szinte biztosan nem lehet, mert valami hibaüzenetbe ütközünk. De sok esetben az Apple gyári PCIe SSD meghajtóin sem tudunk elvégezni egy törlést, formázást, partíció megszüntetést…

Valahogy a Disk Utility / Lemezkezelő esetén sem érezni azt, hogy az Apple fejlesztői tesztelték, élesben használták volna ezt a programot, hiszen számos esetben olyan folyamat miatt nem hajtható végre például egy művelethez szükséges lecsatolás (unmount), amely mély rendszerfolyamat - például kextcache -, amelyre a felhasználó semmilyen hatással nincsen, egyszerűen csak újra és újra hibaüzenetbe ütközik, noha mindent szabályosan próbál végrehajtani…

Image Capture / Képletöltő - bohózatba illő szkennelési funkciók, súlyos adatvesztés az importálásnál

Az Image Capture / Képletöltő egy olyan program a rendszerben, amelyet sokan még sosem indítottak el, mások azonban aktívan használják akár a szkenneléshez, akár a fényképek letöltéséhez a fényképezőgépükről.

Maga az ötlet a Mac OS X hőskorában zseniális volt: a mappába letöltött képeket akár azon nyomban AppleScript futtatásával tudjuk kezelni - van például olyan ügyfelünk, akinek olyan eseményt írtunk, hogy az Image Capture / Képletöltő letöltés után a képek eredetijéből lekicsinyített másolat megy egy mappába, ahonnan egy FTP kliens máris feltölti egy weblapra a képet, és egy sporteseményen gyakorlatilag szinte élőben jelennek meg a képek.



Az Apple néhány operációs rendszerrel ezelőtt viccet csinált a programból: a szkennelésnél korábban rendelkezésre álló elforgatási funkció immáron nem a beolvasandó lap alapján létrejövő végterméket fordítja el, hanem a kijelölést. Ha valaki rájön, hogy mi értelme van a precíz kijelölésünket 90, 180, 270 vagy 360 fokkal elforgatni, írja meg! Évek alatt erre nem sikerült rájönni. Ellenben ha fejjel lefelé rakunk be a lapolvasóba valamit, akkor már nincsen olyan lehetőség, hogy az helyesen jelenik meg a Preview / Megtekintő programban, hanem mindenképpen utólag lehet megfordítani… Egy hasznos funkciót elrontott az Apple, a hibát a Catalina rendszer sem javítja, csak a design változott picit.

Elképesztően durván súlyos azonban az a hiba, amelynek eredménye akár adatvesztés is lehet!

Az Image Capture / Képletöltő program segítségével le tudunk tölteni egy külön projekthez, témához, megbízáshoz tartozó képeket a Mac-re anélkül, hogy valamelyik képkezelő programba importálnánk azokat. Vagyis nem kell sem a Photos / Fotók , sem mondjuk az Adobe Lightroom képtárába tenni, hanem a képek egyszerűen fájlokként kerülnek mentésre, és a Finder ben tároljuk azokat, illetve onnan tudjuk őket megnyitni és más programban feldolgozni. E célra előfordulhat, hogy létrehozunk egy mappát - mondjuk Esküvő 2020AUG30 névvel. Az importálás után az Image Capture / Képletöltő a következő importálásnál is ezt a mappát ajánlja majd fel - emlékszik rá, hogy mi volt a legutóbbi importálásnál a választott hely, és ezt kínálja kényelmi okokból.

Igen ám, de előfordulhat, hogy az Esküvő 2020AUG30 képeit már feldolgoztuk, továbbküldtük, archiváltuk, és a mappát a gépről a tartalmával együtt letöröltük. Vagyis már nem létezik a legutolsó importálási helyszín, amelyet a program felkínál.

A következő importálásnál az Image Capture / Képletöltő azonban mégis ezt a mappát kínálja fel, mint legutolsó preferált importálási cél, és az importálás folyamata látszólag le is zajlik. Ha be van pipálva az import utáni törlés, a program le is törli a kártyánkat, illetve mivel látjuk a zöld pipákat a képeknél, manuálisan is törölhetünk, hiszen abban a hitben vagyunk, hogy a képek már letöltődtek.

Igen ám, de amikor keresnénk a képeket, ébredünk rá, hogy a program egy nem létező mappába hajtotta végre az importálást, vagyis hiába keressük őket, azok nem léteznek többé…

Döbbenetes, és az Apple-re nem jellemző, hogy induláskor a program nem képes megnézni azt, hogy a menüben lévő utolsó kiválasztott mappa létezik-e még. Vagy legalább az importálásnál ellenőrizni, hogy létezik-e az a mappa, ahová írnia kellene az adatokat. Nem is világos, hogy a program az importálás akár hosszú percei alatt mit csinál, hová ír, miért nem csatol vissza hibaüzenetet, és miért nem ellenőrzi a kártyán lévő fájlméretet a fájlrendszerben lévő fájlmérettel, mielőtt az automata törlést végrehajtja… 

Elképesztően súlyos és amatőr hiba ez egy alapszolgáltatást kínáló rendszerprogramban, amely a macOS Catalina egyetlen frissítésével sem lett gyógyítva.



Cikk: Birincsik József, 2019. október 9. és 2020. augusztus 28. között több lépcsőben

 



 

     Keresés a lap tartalmában a Google motorja segítségével: