Jak się domyślam, większość czytelników zapewnie właśnie czyta z wypiekami na twarzy, doniesienia na temat najnowszej bety (5) systemu iOS w wersji 7, ale co tam – postaram się jeszcze bardziej rozpalić atmosferę i podnieść temperaturę tego gorącego wieczoru! Nie tak dawno pisałem na applesauce na temat fajnego odtwarzacza muzycznego o dość swojsko brzmiącej nazwie – VOX (nie wiem czemu, ale mi ta nazwa od razu przypomina hicior pt. Bananowy song pewnego zespołu).
Okazało się więc, że odtwarzacz opuścił fazę beta i pojawił się całkiem niedawno w Mac App Store. Program może działać zarówno jako zamiennik iTunes, lub tylko jako „specjalista” od formatów obcych temu pierwszemu. Decyzję o tym podejmujemy przy pierwszym uruchomieniu aplikacji.
VOX jest nadal darmowy, ale jako zakup wewnątrz (in-app purchase) możemy odblokować funkcję radia. Kosztuje to €0.89 więc nie majątek, ale przez ograniczony czas (dzięki współpracy Coppertino i MacRumors), a dokładnie to do północy dnia dzisiejszego, możecie tę funkcjonalność odblokować całkowicie za darmo!
gdy program jest wciąż uruchomiony, wchodzimy na tę stronę, wpisujemy swoje dane (mail najlepiej ten sam co w MAS…) i po chwili VOX radośnie zakomunikuje, że RADIO zostało zaktywowane! :)
Kto z Was (niestety będę tu faworyzował płeć brzydką) za „wczesnego młodu” nie bawił się klockami? Chyba większość budowała domki w skali, małe garaże, trzymała w nich resoraki… Teraz, Ci którzy swoją budowlaną, twórczą pasję realizują zawodowo, profesjonaliści – wykorzystują drogie specjalistyczne oprogramowanie wspomagające proces projektowania. Oprogramowanie CAD pozwala również, na wizualizację tychże wizji. Nie każdy jednak chciałby wydawać ogromne kwoty pieniędzy. Są tacy, którzy chcieliby się skupić na wnętrzu i wyposażeniu pomieszczeń w budynku. I tacy, którzy chcą urządzić swój pokój lub cały domek, ale nie wiedzą za bardzo jaka aranżacja, ani jakie gabaryty mebli się sprawdzą.
Dla tych właśnie “ciekawskich” powstał Sweet Home 3D. Darmowy program (licencja GPL) autorstwa Emmanuela Puybaret to intuicyjne, proste i wcale nie prymitywne narzędzie to planowania “zagospodarowania przestrzennego” naszych mieszkań. Dostępny jest zarówno dla Maczków (wspierane systemy OS X 10.4 – 10.8) jak i dla pecetów (platformy Windows, Linux i Solaris).
Co więcej, programu nie trzeba nawet instalować, gdyż dostępny jest również w wersji online! I to w wielu językach (nasz rodzimy język wspiera jednak tylko wersja instalowana lokalnie).
Na co pozwala Sweet Home 3D? Na całkiem sporo:
rysować pomieszczenia (podłogi, sufity, ściany),
wymiarować elementy rysunków,
dodawać meble oraz wyposażenie, i modyfikować ich gabaryty oraz inne parametry jak: pozycja, kolor, czy tekstura,
wyświetlać natychmiastowy trójwymiarowy podgląd projektowanego na płaszczyźnie dwuwymiarowej pomieszczenia,
dodawać opisy tekstowe oraz określać położenie pomieszczenia względem kierunków świata,
generować fotorealistyczne obrazy i filmy, z możliwością dostosowania oświetlenia do naszych potrzeb oraz z uwzględnieniem pory dnia i/lub lokalizacji,
importowanie planów pomieszczeń, modeli 3D i tekstur,
wydruk i eksport stworzonych projektów w postaci pliku PDF, bitmapy, grafiki wektorowej i filmu,
rozszerzyć możliwości dzięki wtyczkom napisanym w Javie.
Sami zresztą zobaczcie efekt kilku minut pracy z tym programem:
Lub odwiedźcie galerię projektów wykonanych przez innych użytkowników tego świetnego programu.
Jeśli wymierzycie swoje pokoje, znajdziecie w domyślnej bibliotece obiektów lub pośród dostępnych za darmo – swoje graty, zmodyfikujecie ich wymiary, dopasujecie kolorystykę i materiały, to okaże się, że w niedługim czasie odtworzycie swoje cztery kąty w trójwymiarze na ekranie komputera!
Bardzo fajną rzeczą w Sweet Home 3D jest wirtualny spacer, możemy zabawić się w paparazzi i z kamerą zwiedzać pomieszczenie, przyglądając się z bliska obiektom.
A już wisienką na torcie jest stworzenie ścieżki ruchu kamery, ustawienie pozostałych parametrów i wygenerowanie filmu z takiej wirtualnej podróży! Niestety wymaga to silnego komputera i trochę czasu, ale efekty są miłe dla oka i dają satysfakcję.
Sam korzystam z tego programu na zajęciach Informatyki w szkole, w której uczę i uwierzcie, że dzieciaki mają wielką frajdę i potrafią wykazać się ogromną pomysłowością. I to wszystko dostępne jest za darmo, nie instaluje się godzinami i nie zajmuje wiele miejsca na dysku :) Ponieważ program działa – i to całkiem sprawnie – na Maczkach, grzechem było o nim tu nie wspomnieć.
Większość możliwości Sweet Home 3D wyjaśnia dokumentacja oraz samouczek wideo – niestety przydatna jest tu znajomość języka angielskiego, co jednak w obecnych czasach nie powinno dziwić.
Jeśli jeszcze nie zakupiliście – zachęceni moimi wcześniejszymi artykułami – aplikacji Air Video na Wasze iUrządzenia to prawdopodobnie już tego nie zrobicie. Dla przypomnienia: rozwiązanie to pozwala na odtwarzanie bezprzewodowo praktycznie dowolnego materiału wideo z dysku Maca/PC. „Ekranami” mogą być: iPhone, iPad, iPod Touch, a dzięki AirPlay również Apple TV. Nazwałem Air Video killer app, z uwagi na fakt, że dzięki niej, bez jailbreaka, eliminujemy ograniczenie telejabłka odnośnie źródła materiału filmowego. Okazuje się jednak, że Air Video ma konkurencję i to nie byle jaką!
Możecie mi zarzucić, że ameryki nie odkryłem, bo obie appki pojawiły się w… 2009 roku. Faktycznie, nie traktuję tego wpisu jako „news”, a jako informacje, że gdy się znajdzie już jakieś rozwiązanie, z którego człowiek korzysta każdego dnia, przyzwyczai się, jest zadowolony z rezultatów, itp. To zawsze jest szansa na to, że odkryje się i polubi alternatywę. Przyznam się bez bicia, że moją uwagę na StreamToMe zwrócił narkoman w swoim tweecie. Chwalił algorytmy kompresji użyte w tym rozwiązaniu. No i postanowiłem sam się o tym przekonać. Nim jednak opiszę swoje wrażenia najpierw przedstawię Wam zestawienie porównawcze Air Video oraz StreamToMe, i wyjątkowo zrobię to w formie tabeli, aby skrócić wpis ;)
Niestety, nie wszystkie informacje zawarte w tej tabeli są łatwo dostępne na stronach producentów. Trochę poszperałem na forach, część informacji potwierdziłem wykonanymi samodzielnie testami, jednak nie dam sobie żadnej części ciała uciąć, że wyżej wymienione dane są zgodne w 100% z rzeczywistością…
Jak zauważyliście podstawową zaletą StreamToMe jest możliwość streamingu nie tylko wideo, ale również muzyki i zdjęć. Bardzo podoba mi się możliwość odtwarzania muzyki i dzięki temu, że StreamToMe wspiera również formaty bezstratne (np. FLAC), mogę wyeliminować aplikacje AceMusic/AcePlayer. Wyświetlanie zdjęć również działa zacnie, jednak mam pewne zastrzeżenia, co do szybkości wyświetlania zdjęć – choć jest i tak zdecydowanie lepiej, niż na Toshibie.
Bardzo cieszy mnie fakt wsparcia napisów w formacie .txt do filmów. Co prawda zawsze można wykorzystać Jublera albo PYMplayer do konwersji na .srt, ale miło gdy nie trzeba tego dodatkowego procesu angażować.
Muszę pochwalić StreamToMe za działanie po 3G. Faktycznie da się na takim łączu obejrzeć i film i zdjęcie i nawet posłuchać muzyki.
Rewelacją dla mnie jest też fakt udostępnienia klienta StreamToMe dla komputerów Mac – myślę, że nie tylko właściciele MacBooków Air z małymi dyskami docenią tę możliwość! Swego czasu nawet testowałem podobne rozwiązanie z wykorzystaniem Air Video Server oraz aplikacjami autorstwa Ericy Sadun, niestety z dość marnymi rezultatami.
Co do jakości streamowanego materiału w sieci lokalnej w porównaniu do Air Video, to StreamToMe pokazuje swoją wyższość, wraz ze wzrostem jakości źródłowego pliku wideo (najlepiej w rozdzielczości HD). Oczywiście bardzo szczegółowe testy mogą jeszcze skuteczniej przechylić szalę na korzyść StreamToMe. Jeśli ktoś z Was będzie się nudzić, to może takie wnikliwe badania wykonać, np. ile milisekund szybciej rozpoczyna się odtwarzanie pliku po sieci w obu aplikacjach. Mi szkoda na to czasu, doceniam wygodę obu rozwiązań i myślę, że będę używać StreamToMe zamiennie z Air Video. Aczkolwiek z uwagi na wsparcie dla audio oraz pozostałe zalety, bohater dzisiejszego wpisu ma spore fory…
Ciekawe czy i kiedy InMethod przedstawi nową wersję Air Video by powalczyć z produktem Matthew Gallaghera?
Zgodnie z sugestią narkomana śpieszę donieść, że wersja 4.0 beta ServeToMe (na razie tylko dla Maczków) wspiera już streaming wideo w jakości Full HD (1080 p)! Wstyd przyznać, ale sam nie dorobiłem się jeszcze żadnego wyświetlacza potrafiącego taką rozdzielczość obsłużyć… Jednak posiadacze MacBooków i iPadów z Retiną oraz Apple TV 3G wraz z dużym telewizorem, na pewno się ucieszą :)
Dzisiejszy wpis nie będzie – dla odmiany – ani o AirPlay ani o appkach dla iOS. Mimo, swojego wieloletniego doświadczenia z Maczkami oraz OS X, stosunkowo rzadko opisuję aplikacje bądź rozwiązania problemów na tej platformie. Jest to spowodowane m.in. tym, że:
nie mam właściwie jakichś większych problemów ani z komputerem ani systemem (odpukać!) – być może mój workflow jest tak zoptymalizowany lub tak prosty, że nie ma wielu sytuacji, które zmuszają mnie do większego wysiłku umysłowego i wgryzania się w temat,
wiele rzeczy, które robiłem wcześniej na iMacu, obecnie wykonuję na iUrządzeniach, a co za tym idzie – rzadziej korzystam z komputera,
bardzo często rozwiązanie problemu wydaje mi się na tyle banalne, że jestem (prawdopodobnie błędnie) przekonany, że wszyscy inni już sobie poradzili z tym dawno, albo temat jest trywialny i nie warto zaśmiecać bloga czymś tak oczywistym.
Tym razem jednak, “wdepnę” na teren, który do tej pory eksploatował mocno Kuba i opiszę wyjście z sytuacji, zasygnalizowanej przez znajomego zajmującego się zawodowo usługami w branży poligraficznej. Oczywiście rozwiązanie ma swoje wady, i właściwie to taka trochę partyzantka i prowizorka, ale – co istotne – koszt realizacji jest niewielki (nie napiszę, że zerowy, bo jakby nie patrzeć czas spędzony na instalacji, konfiguracji, weryfikacji, itp. też ma swoją cenę).
Aby nie przedłużać przedstawiam opis problemu: klient posiada nowego MacBooka z procesorem i5 oraz OS X 10.8.3. Ponadto stare maczki oraz legalne licencje oprogramowania przeznaczonego dla starszych komputerów z procesorami PowerPC (np. Freehand MX). I wiele prac w nich stworzonych. Chciałby, rzecz jasna, móc wykorzystać te programy i dokumenty na nowym MacBooku. Jednak jak się domyślacie, skok technologiczny oraz zmiany jakie zaszły przez tyle lat w software i w hardware, uniemożliwiają taką bezbolesną podróż z przeszłości do teraźniejszości. Sposobów na zmianę tego stanu rzeczy jest kilka:
aktualizacja posiadanego zaplecza programowego do nowszych/najnowszych wersji – dość kosztowny zabieg,
próba konwersji dokumentów do formatu “zjadliwego” przez inne, nowe (również darmowe) programy – duże prawdopodobieństwo, że jeśli w ogóle się to uda, to zawartość dokumentów nie będzie zachowana w 100% w identycznej postaci,
zakup używanego komputera, z systemem w wersji wspierającej kod przeznaczony dla procesorów PPC – rozwiązanie tańsze niż aktualizacja wszystkich programów, ale dość kontrowersyjne, w sytuacji gdy chwilę wcześniej nabyło się (niestety bez wcześniejszego rozeznania) nowego, ślicznego i szybkiego MacBooka…
uruchomienie systemu ze wsparciem dla PPC, na wcześniej wspomnianym komputerze oraz instalacja leciwego softu.
Jak się domyślacie, zdecydowałem się na karkołomną próbę realizacji tego ostatniego.
Wiedziałem, że istnieje możliwość wirtualizacji systemu Mac OS X. Bliższa weryfikacja potwierdziła, że praktycznie każde z istniejących rozwiązań, czyli Parallels Destop, VMware Fusion oraz Oracle VirtualBox potrafią stworzyć i obsłużyć maszynę wirtualną z systemem Mac OS X… w wersji Server (dokładnie wersje 10.5/10.6). Ostatnia wersja systemu dla Maców, która wspiera wykonywanie kodu PowerPC to 10.6 czyli Snow Leopard. Pomimo faktu, że samego systemu nie da się zainstalować na komputerze z takim procesorem, to instalowany dodatkowo komponent o historycznie uzasadnionej nazwie – Rosetta, pozwala systemowi uruchomionemu na maszynie z procesorem Intela na wykonanie kodu programu stworzonego dla platformy PPC.
Niestety system Mac OS X w wersji serwerowej jest zabezpieczony kluczem, i nie jest tak popularny i łatwo dostępny. Krótkie sprawdzenie podaży tej wersji systemu na najpopularniejszym portalu aukcyjnym tylko potwierdziło, że nie będzie łatwo. Owszem, teoretycznie mógłbym ściągnąć obraz płyty z sieci, ale co z licencją/numerem seryjnym?
Postanowiłem więc sprawdzić czy da radę zainstalować system w wersji desktopowej. A jako oprogramowanie do wirtualizacji wybrałem darmowego VirtualBoksa. Okazało się, że mam płytę z systemem Mac OS X 10.6 zakupioną jak tylko ów się pojawił (moje iMadło przyszło do mnie fabrycznie bodajże z 10.5.2).
Początki były dziecinnie proste – instalacja VB, tworzenie nowej maszyny wirtualnej przebiega właściwie bez jakichkolwiek zakłóceń i zaklęć, większość opcji można pozostawić w ustawieniu domyślnym. Ja poza wyborem systemu (typ: Mac OS X, wersja: 64 bity), zostawiłem sugerowany przydział pamięci RAM (2 GB), zalecaną przestrzeń dyskową i jej rodzaj (dynamicznie alokowany wirtualny dysk o pojemności do 20 GB, format VDI).
Następnie dokonałem modyfikacji pewnych bardziej zaawansowanych ustawień po kliknięciu Settings dla właśnie utworzonego profilu maszyny wirtualnej. Na karcie System odhaczyłem napęd dyskietek w sekcji Boot Order. Zwiększyłem również na karcie Display ilość pamięci dla VM do 64 MB oraz włączyłem akcelerację 3D (w sumie to nie mam przekonania, że akurat te opcje robią jakąś odczuwalną różnicę, ale skoro karta graficzna ma 256 MB VRAM i nie najgorsze GPU, to postanowiłem zaryzykować).
Na karcie Storage w sekcji Attributes wskazałem wcześniej zrzuconą do obrazu DMG, płytę z instalką systemu Snow Leopard (zrobiłem tak, ponieważ mój napęd optyczny jest kapryśny i hałasuje, skorzystałem więc z opisywanego wcześniej tu patentu płyty zdalnej – z wykorzystaniem czytnika w pececie).
Start maszyny, bootujemy z wirtualnego obrazu CD/DVD, pojawiają się napisy :P białe na czarnym i po chwili wszystko staje na takim etapie:
Aha, cytując klasyka: Huston mamy problem. Gdyby to był Mac OS X Server to pewnie bazowy system by ruszył i instalacja została zainicjowana. Ale mamy system w wersji desktop, więc musimy znaleźć sposób by oszukać VirtualBoksa. Przejrzenie ustawień nie wniosło wiele ale postanowiłem wyłączyć opcję Enable EFI (special OSes only).
W efekcie po restarcie VM powitało mnie tym razem poniższe okienko:
Ewidentnie trop był dobry, więc zacząłem przeglądać zasoby internetu w poszukiwaniu rozwiązania bądź podpowiedzi, która naprowadzi mnie na właściwą ścieżkę. Kilkadziesiąt minut wnikliwego surfowania przyniosło skutek. Okazało się, że najbardziej pomocne były nie strony i fora związane z wirtualizacją a te poświęcone… hackintoshom.
Faktycznie problem leży (upraszczając nieco temat) po stronie tzw. boot loadera i zanim dokona się instalacji systemu, należy wystartować VM z boot loadera w odpowiedniej wersji, tak by “oszukać” VirtualBoksa, że ma do czynienia z system we właściwym wydaniu. Okazało się, że istnieją dwa (o komercyjnie dystrybuowanym kiedyś Rebel EFI z Psystara pisać tu nie będę) takie alternatywne boot loadery w postaci obrazów .iso. Jeden to EasyEFI (wersja testowana przeze mnie to v.2.2 ver.3) a drugi The Empire EFI. Do gustu przypadł mi zdecydowanie pierwszy, mimo świetnego logo nawiązującego do Gwiezdnych Wojen, którym wita użytkownika The Empire EFI. Niestety, ale ten ostatni chyba dłużej startuje, poza tym oferuje domyślnie niższą rozdzielczość ekranu.
Należy wskazać alternatywny boot loader jako “płytę startową” (karta Storage), uruchomić VM, zaczekać chwilkę aż pojawi się poniższy ekran (EasyEFI):
a następnie wejść w menu VirtualBox -> Devices -> CD/DVD Devices -> Choose a virtual CD/DVD disk file… i wskazać obraz .dmg z instalką systemu. Wcisnąć klawisz funkcyjny F5, ikonka znajdująca się na środku ekranu powinna zmienić podpis z “EasyEFI” na “Mac OS X Install DVD”. Już tylko wciśnięcie klawisza Enter dzieli nas od rozpoczęcia procesu instalacji!
Po wybraniu języka głównego systemu nim rozpoczniemy właściwą instalację, musimy jeszcze sformatować plikopartycję, na której 10.6 ma być zainstalowany, bez tego instalator nie znajdzie dysku:
Jako, że system “gościa” ma służyć właściwie tylko jako launcher, środowisko pozwalające na uruchomienie starszych programów, odznaczyłem zbędne składniki, i zahaczyłem opcjonalny komponent, kluczowy w naszym zadaniu:
Teraz był test cierpliwości. Początkowe zakładane 19 minut przedłużyło się do około pół godziny, a zwieńczeniem całego procesu był poniższy komunikat:
Na szczęście okazuje się, że ten typ tak ma i podjęte czynności wcale nie zakończyły się niepowodzeniem. Niestety, wybranie przycisku Uruchom ponownie, nie restartuje poprawnie VM, w związku z czym należy dokonać tego wybierając opcję Reset w menu Machine VirtualBoksa. Co więcej, najprawdopodobniej powita nas znane już oko z komunikatem: “Fatal! No bootable medium found. System halted.”
Raz jeszcze musimy wskazać wirtualny plik .iso z alternatywnym boot loaderem nim wystartujemy VM “od zera”. W przypadku EasyEFI ujrzymy następujący ekran:
Wybranie ikonki jabłuszka i zatwierdzenie Enterem spowoduje uruchomienie zainstalowanego systemu. Działa nawet pod Mavericksem :) (10.9 DP4).
Właściwie można by uznać, że problem jest rozwiązany. Dla potwierdzenia ściągnąłem pod zwirtualizowanym Snow Leopardem program viJournal w wersji Universal i wymusiłem uruchomienie kodu PowerPC. Poniżej efekt:
No tak, ale wypadałoby jeszcze usprawnić komunikację między gospodarzem (host) i gościem (guest). Niestety z uwagi na brak oficjalnego wsparcia systemu Mac OS X w wersji desktop, nie ma dla niego zestawu “sterowników” zwanych VirtualBox Guest Additions. To oprogramowanie zapewnia m.in. działanie drag&drop, wspólny schowek (Shared Clipboard), udostępnione foldery (Shared Folders) i inne udogodnienia. Pierwsza myśl jaka mi przeszła przez głowę: użyję pendrive’a jako nośnika między oboma systemami! Fajnie, tylko… nie działa. Pendrive się nie montuje w systemie gościa, więc nie mamy dostępu do jego zawartości. Zapewne Guest Additions załatwiłyby ten problem rownież… Zonk.
Kolejna myśl: sieć lokalna. Oczywiście najpierw upewniłem się, że w obu systemach załączone jest Udostępnianie plików (Preferencje systemowe -> Udostępnianie), dodane katalogi i przyznane odpowiednie prawa użytkownikom. W dodatkowych opcjach na wszelki wypadek załączone zostało udostępniane przy użyciu obu protokołów, tj. AFP oraz SMB. Cóż… na wirtualnym 10.6 przeglądanie sieci nie wyświetla żadnych zasobów sieciowych, zaś próba podłączenia się do widocznego z poziomu gospodarza wirtualnego Snow Leoparda, zwraca komunikat błędu.
No tak, czyli mamy zwirtualizowany system, na który dane możemy wrzucić z fizycznej płyty CD/DVD, obrazu takowej w postaci pliku .dmg/.iso oraz ściągając je z Internetu! Chwila kontemplacji podbródka a chytry i przebiegły plan skrystalizował się w meandrach zwojów mózgowych. Przecież mogę zainstalować na obu systemach DropBoksa i w ten sposób, trochę na około, za pośrednictwem Internetu wymieniać dane między dyskami gospodarza i gościa. No tak, ale “na dzień dobry” DropBox to liche 2 GB za darmo…
Czas wrócić do sieci lokalnej. Sprawdzam adresy IP maszyny fizycznej i wirtualnej. Są inne :) I tak ma być! Ale przynależą również do innych podsieci. W takim razie wciskam Command+K wywołując polecenie Połącz z serwerem… z menu Idź Findera. Podaje adres maszyny wirtualnej i… błąd! Czas zobaczyć czy może w drugą stronę zadziała?
Jest dobrze, pada monit o nazwę użytkownika i hasło. Udało się! Mogę teraz spokojnie podmontować dowolny zasób iMaca (oraz również dysk z peceta) pod wirtualnym systemem:
Pozostaje jeszcze kwestia uruchamiania systemu. Na chwilę obecną każde ponowne uruchomienie VM wymaga sprawdzenia w ustawieniach Storage, czy obraz alternatywnego boot loadera jest wskazany jako wirtualny dysk CD/DVD; inaczej zainstalowany system się nie uruchomi. Lipa, żonglowanie podmontowanymi obrazami i/lub fizycznymi dyskami CD/DVD z napędu hosta, to mało atrakcyjne zajęcie. Na szczęście na dysku EasyEFI.iso znajdziemy pakiet Chameleon:
Instalacja tegoż, powoduje wgranie bootloadera oraz rozszerzeń systemowych (kext) do naszego zwirtualizowanego Snow Leoparda.
Na koniec procesu uruchamia się Terminal, w którym należy podać hasło oraz program Kext Utility, którego zadaniem jest naprawa przywilejów modułów. U mnie aktywność instalatora zaowocowała zgłoszeniem błędów z instalacją kilku rozszerzeń, zaś Kext Utility zakończyło pracę z radosnym kelnerem panikarzem (ale tylko za pierwszym razem) ;) Dzięki bogom wszelakim, VM uruchamia się i póki co nie zauważyłem by stabilność systemu została w jakikolwiek sposób zachwiana. Nie da się jednak ukryć, że dobór rozszerzeń wymaga rozwagi i… odwagi. Tak czy inaczej, dzięki „kameleonowi”, 10.6 wstaje o wlasnych siłach, bez pośrednictwa EasyEFI w wirtualnym napędzie!!!
Reasumując: mamy działający system 10.6 z dostępem do Internetu oraz zasobów sieci lokalnej, zdolny do egzekucji programów pisanych na procesory PowerPC. Pełen sukces? W zasadzie tak, są jednak drobne “ale”:
jeśli chcemy skorzystać z fizycznej płyty w napędzie komputera musimy z menu VirtualBox (Devices -> CD/DVD Devices) wybrać opcję Host Drive ‘nazwa napędu’, niestety nie działa nagrywarka pod VM, zatem napęd optyczny tylko do odczytu (być może da się to zmienić, ja temat odpuściłem),
zdaża się, że nie działa poprawne zamykanie systemu 10.6, po wybraniu tej opcji i tak trzeba ręcznie wyłączyć VM, najlepiej klikając przycisk zamknięcia okna i wybierając opcję: Power off the machine,
restartowanie zdaje się działać od czasu do czasu również wybiórczo – jeśli “zamieszamy” zbytnio, niektóre procesy systemowe mogą przestać funkcjonować poprawnie; w takim wypadku postępujemy jak w przypadku zamykania, można ew. wykonać jeszcze Reset z menu Machine VirtualBoksa,
gdy pod wirtualnym 10.6 zechcemy wybrać opcję Ten Mac… z menu Jabłko – Finder się restartuje,
zamiast wyłączania VM możemy ją zahibernować, klikając przycisk zamknięcia okna i wybierając opcję: Save the machine state, jednak zdarza się, że po przywróceniu maszyny, występują sporadyczne kłopoty z siecią lokalną,
nie działa drag&drop, wspólny schowek, współdzielone foldery, obsługa USB i wiele innych rzeczy,
nie polecam aktualizacji zwirtualizowanego Snow Leoparda do najnowszej wersji (10.6.8) – przynajmniej bez zrobienia kopii zapasowej dysku wirtualnego,
last but not least: nie można wybrać z poziomu VM innej niż domyślna rozdzielczości ekranu; jak wcześniej wspomniałem dla The Empire EFI jest to 1024 x 768, zaś dla EasyEFI 1280 x 1024; oczywiście w sieci można znaleźć kilka różnych przepisów, jak tę sytuację zmienić, niestety u mnie udało się – próbując wymusić rozdzielczość 1440 x 900 x 32 – osiągnąć w trybie okienkowym tylko 1152 x 864…; mimo zmian ustawień panelu preferencji Chameleon, nie udało mi się uruchomić na pełnym ekranie VM w natywnej rozdzielczości mojego iMaca, tj. 1680 x 1050. W trybie okienkowym dobrym wyjściem jest też korzystanie z opcji Switch to Scale Mode znajdującej się w menu View VirtualBoksa, aczkolwiek zdaje się ona zniekształcać proporcje ekranu (wysokość zwiększona w stosunku do szerokości).
Nie jestem pewien czy czegoś nie pominąłem, jeśli podany wyżej przepis Wam nie zadziała, lub znacie/znajdziecie sposoby na wyeliminowanie opisanych ograniczeń – będę wdzięczny za wszelkie pytania, sugestie i wskazówki.
Jedną z nowych rzeczy, które Apple zaimplementowało w systemie iOS 7 jest AirDrop. Osobiście nie bawię się betami tej wersji mobilnego systemu (z różnych względów), więc nie mogę wypowiedzieć się jak tu działa AirDrop. Pozwolę sobie jednak na koniec wpisu przedstawić własne zdanie, co ta funkcja powinna oferować, by nie odejść w zapomnienie i stać się użytecznym i powszechnie wykorzystywanym narzędziem.
Niecałe trzy miesiące temu na łamach applesauce opisywałem darmową alternatywę dla desktopowego AirDropa. Wrócę do tego rozwiązania, ponieważ zgodnie z obietnicą, autor stworzył wersję Filedrop dla iOS! Appka (niestety nie uniwersalna) jest oczywiście darmowa (brawo!) ale zoptymalizowana dla iPhone, więc na iPadzie nie wygląda jak należy…
Z poziomu Maca i PC można więc przesyłać bezprzewodowo pliki wszelkiego rodzaju (jak również foldery z plikami), które po akceptacji na iPhone, lądują w wewnętrznym magazynie Filedrop.
Z poziomu smartfona możemy natomiast dowolny plik/folder z tego magazynu przesłać na inne urządzenie, wysłać do inne zainstalowanej na iPhone aplikacji, lub po prostu skasować (appka obsługuje gesty przesuwania palcem po pliku, w prawo i w lewo).
Oczywiście Filedrop pozwala też wysłać na inne urządzenie z iOS, Maca lub peceta zdjęcie z Rolki z aparatu oraz zawartość schowka.
Autor zaktualizował również programy Filedrop dla OS X oraz Windowsa. Niestety największe bolączki, czyli konieczność pilnowania by aplikacja była cały czas uruchomiona oraz niewielka szybkość transferu większych plików, nadal psują końcowy efekt.
Czas zatem na głównego bohatera dzisiejszego wpisu i bynajmniej nie będzie to czarny charakter :) Flick to kolejna DARMOWA alternatywa dla AirDrop. Właściwie trudno to rozwiązanie uznać za alternatywę, bo oferuje znacznie więcej niż produkt Apple. Flick umożliwia wymianę informacji oraz plików różnych typów między następującymi platformami:
Już samo to (oraz fakt, że możemy z tego wszystkiego korzystać za darmo!) sprawia, że Flick zdobył moje uznanie. Dalsze testy tylko to pozytywne wrażenie wzmocniły.
Co możemy przesłać między urządzeniami dzięki Flick?
zdjęcia (możemy uruchomić aplikację Aparat bezpośrednio we Flick, lub wybrać wcześniej zrobione zdjęcie z Rolki)
kontakty
notatki (na komputery trafiają w postaci dokumentów .txt)
grę Kółko i krzyżyk :D (niestety działa tylko między iUrządzeniami, na komputery Mac i PC dochodzą pliki z którymi systemy nie wiedzą za bardzo co zrobić…)
pliki (np. załączniki z aplikacji Mail, tak .doc/.docx, .pdf, itp.).
Z braku odpowiedniego sprzętu nie mogłem sprawdzić jak działa Flick PC na Linuksie, zaś wersja dla urządzeń z systemem Android nie jest jeszcze dostępna.
Na OS X oraz Windowsie, Flick instaluje się jako usługa działająca w tle (można oczywiście ją w dowolnym momencie wyłączyć, korzystając z menuletu na Macu oraz ikonki aplikacji w zasobniku systemowym „Okienek”). Jeśli chcemy wysłać jakikolwiek plik musimy przeciągnąć go do górnej krawędzi ekranu. Pojawi się tzw. Flicktop, półprzezroczysty pasek aplikacji który znajduje się nad wszystkimi innymi oknami, zawierający listę wykrytych i podłączonych urządzeń. Wskazujemy adresata i następnie „wypychamy” w górę miniaturkę pliku, która zajmuje centralne miejsce ekranu.
Flick dla iOS działa bardzo podobnie, z tą różnicą, że aplikację musimy uruchomić sami, natomiast po zainicjowaniu transferu możemy przełączyć się do innej appki, a Flick będzie działać dalej w tle. Gdy np. odbieramy jakiś plik i mamy załączone Powiadomienia, po zakończeniu operacji Flick nas o tym poinformuje.
Możemy do iPhone lub iPada wysłać praktycznie dowolny plik. Oczywiście Flick nie potrafi wszystkiego wyświetlić, ale potrafi przesłać plik w nieznanym sobie formacie do innego zainstalowanego na iUrządzeniu programu, które przyjmie kopię do swojego sandboksa. Np. wysyłając film w formacie .avi (DivX), próba odtworzenia takowego na iPhone w aplikacji Flick daje następujący rezultat:
ale gdy wybierzemy jako program docelowy appkę, która wie co z filmem zrobić (np. CineXPlayer)
to kopia filmu będzie już zdatna do obejrzenia.
Nie będę się rozpisywać więcej w kwestii obsługi Flick, bo to rozwiązanie jest naprawdę proste, wygodne i intuicyjne. „Flikowanie” na iOS działa bardzo podobnie do tego jak obsługujemy inną, starszą – i myślę, że znaną niektórym z Was – appkę, pod nazwą Mover+.
Poza tym, na stronie dewelopera znajdziecie filmy prezentujące Flick w działaniu oraz dokumentację.
Przesyłanie po WiFi działa między wszystkimi testowanymi urządzeniami, natomiast przesyłanie po Bluetooth zadziałało mi tylko między iPadem oraz iPhonem.
Po przetestowaniu różnych rozwiązań do przesyłana danych uważam, że przed Apple stoi całkiem spore wyzwanie. Co więc powinien oferować Air Drop na OS X oraz iOS?
O to moje sugestie:
wymiana plików i danych między oboma systemami, AirDrop na iOS MUSI „gadać” z AirDrop na OS X, inaczej nie ma sensu, (a niestety na to, że Apple przygotuje Air Drop na konkurencyjne platformy i systemy, raczej nie ma co liczyć – choć Safari, iTunes, QuickTime, Bonjour i kilka innych rzeczy na Windowsa wydali :)),
działanie jako usługa systemowa w tle, z wykorzystaniem systemu powiadomień – chodzi o to, by monit o przyjęcie pliku z innego urządzenia znajdującego się w tej samej sieci, pojawiał się bez wcześniejszego uruchamiania osobnej, dedykowanej aplikacji – tak jak otrzymujemy informację o tym, np. że ktoś chce się do nas dodzwonić ;)
wspólny magazyn AirDrop dostępny dla każdej aplikacji iOS, która potrafi tworzyć i/lub otwierać dokumenty (wiadomo, że systemowe appki nie radzą sobie ze wszystkimi typami plików, a tworzenie osobnych kopii plików dla każdej aplikacji to marnotrawstwo cennego miejsca).
Ciekaw jestem, czy Apple uda się zamienić fajny pomysł w użyteczną usługę, czy „zrzut” na iOS podzieli los wersji desktopowej…
Bonus :)
Wyżej narzekałem na powolność Filedrop. Postanowiłem więc, sprawdzić szybkość przesyłania tego samego pliku między iMadłem i pecetem. Oba komputery spięte są ze sobą kablem RJ45 za pośrednictwem Time Capsule, oba posiadają interfejsy sieciowe Gigabit Ethernet. Przesyłany był za każdym razem ten sam plik (film DivX, Hotel Transylvania) o wielkości 733 MB. Wyniki dla Filedrop, Flick oraz połączenia systemowego poniżej:
Dziś dla odmiany będzie… o tym, co w tytule :) Już słyszę te głosy rozczarowania: „znowu o AirPlay!”, „applesauce staje się monotematyczne!”, itp. Cóż, po pierwsze to – wolnoć Tomku w swoim domku, po drugie – tematyka związana z technologią AirPlay jest bardzo ciekawa a tematów wciąż przybywa, po trzecie zaś – chciałbym aby applesauce było kopalnią wiedzy na ten temat, swoistym mini-kompendium dedykowanym – między innymi – temu właśnie tematowi. A jako, że znaczna część czytelników, to posiadacze pecetów i mniej lub bardziej szczęśliwi użytkownicy Windowsa, dzisiejszy artykuł poświęcony będzie temu systemowi. (więcej…)
Stali i uważni czytelnicy applesauce wiedzą jak zafascynowany jestem technologią AirPlay. Legendarna prostota jak na produkt Apple przystało, a do tego niesamowita uniwersalność. Bo AirPlay to strumieniowe przesyłanie nie tylko dźwięku, ale również zdjęć, wideo, sklonowanego obrazu a nawet granie na zdalnym ekranie! I z każdą aktualizacją systemów iOS/OS X możliwości AirPlay się zwiększają. Nie bez znaczenia jest też wsparcie tego – jakby nie patrzeć zamkniętego – standardu, ze strony innych producentów. AirPlay to rozwiązanie klasy premium, nie tylko z uwagi na cenę i wymagania ale przede wszystkim za oferowaną wygodę i jakość. Wadą tegoż jest ograniczenie do sprzętu Apple (iPhone, iPad, iPod Touch, Apple TV, AirPort Express, komputery), i certyfikowanych odbiorników (AirSpeakers). Oczywiście są też urządzenia posiadające nieautoryzowane wsparcie AirPlay, jak np. Raspberry Pi. Kolejna sprawa – WiFi. Bez sieci bezprzewodowej (i to naprawdę szybkiej) o AirPlay możemy zapomnieć. Zatem router/punkt dostępowy to tzw. must have. I to muszą być urządzenia wspierające mDNS… A gdy zechcemy zezwolić komuś na streamowanie treści z jego iUrządzenia, to musimy przyłączyć go do naszej głównej sieci, sieć użyczana tu nie wystarczy… Ogólnie jednak jest więcej zalet niż wad, przynajmniej dla osoby, która w ekosystem Apple „wrosła” i się w nim dobrze czuje. (więcej…)
Wreszcie mamy wakacje! Ok, wiem, że nie wszyscy. Ja – podobnie jak dzieci i młodzież ucząca się – mam ten przywilej odpoczynku w miesiącach letnich. Osoby postronne widzą tylko tę jaśniejszą stronę (tyyyle wolnego!) zaś Ci, którzy choć trochę popracowali w niedocenianym zawodzie nauczyciela wiedzą, że ciemna strona wcale mniej istotna nie jest. Ale ja nie o tym. Przez ostatnie dwa miesiące, nawał różnych spraw o mniejszej atrakcyjności, lecz wyższym niż blog priorytecie, skutecznie mnie od sieciowej aktywności odsunął. Oczywiście biernie śledziłem co się dzieje (aczkolwiek np. bety iOS7 nie zainstalowałem, i jeśli ciekawi jesteście mojego zdania, to wizualnie mi się nowa wersja systemu BARDZO nie podoba :> za te ikonki i gradienty wysłałbym cały zespół „twórców” na kwartał ciężkich robót w siedzibie M$ w Redmond…), jednak dopiero teraz mam czas i siły by wynagrodzić Wam to wielotygodniowe milczenie. (więcej…)
Być może jestem w błędzie, ale zakładam, że spora część szanownego grona czytelników zna, przynajmniej z nazwy odtwarzacz audio zwany Vox (o ile mnie RAM nie myli, to wcześniej był… Tool Player). Od samego początku player ten zwracał na siebie uwagę minimalistycznym a przy tym przejrzystym i intuicyjnym interfejsem, możliwością odtwarzania wielu formatów audio, z którymi bez wcześniejszej konwersji iTunes nie daje sobie rady, oraz niewielkim apetytem na zasoby systemowe (ta „mocarna pchełka” zajmuje na dysku zaledwie 4 MB…).
Teoretycznie, popularność iTunes Match czy serwisów streamingowych jak Spotify, WiMP czy Deezer sprawia, że tego typu programy zdają się stawać niszowymi. Jednak wiele osób wciąż ma muzykę na płytach, kupuje wersje cyfrowe zapisane w formatach bezstratnych, jak np. FLAC, i niestety, wciąż dość powrzechny jest problem braku dostępu do sieci, lub niewielka przepustowość takiego połączenia.
Kolejna sprawa to opcje programu. Vox, nawet w wersji 0.3-coś-tam to narzędzie o potężnych możliwościach. Możemy wygodnie i pod wieloma względami dostosować charakterystykę dźwięku do własnych oczekiwań oraz w zatuszować niedoskonałości materiału źródłowego. Możemy również z poziomu aplikacji, dokonać konwersji do jednego z kilku formatów, przy okazji wpływając na wyjściowe parametry dźwięku. Kolejną ciekawą funkcją jest zmiana prędkości odtwarzania utworu, bez jego zniekształcania, inaczej mówiąc np. wokalistka w zwolnionym tempie nie zaczne śpiewać basowo :) Dostępna jest również pokaźna lista w pełni modyfikowalnych efektów, jak np. wielozakresowy kompresor. Muszę przyznać, że sam z wielu tych „bajerów” nie miałem okazji wykorzystać, poniekąd z braku wiedzy, jak ich użyć. Niemniej, zaawansowani muzycy potrafią zrobić z tychże użytek.
Zachęcam Was do przetestowana wersji beta najnowszej odsłony odtwarzacza VOX, odsłony znacznie różniącej się nie tylko wyglądem, od poprzednika. Póki co widać, że mamy dodyspozycji znacznie mniej. Odtwarzacz, korektor i właściwie tyle. No i zajmuje 5 razy więcej miejsca na dysku!
Na chwilę obecną trudno znaleźć sensowny argument za aktualizacją. Ale są też, w tej nowej – przypominam, to wciąż beta! – wersji, pozytywy: możemy bezpośrednio z odtwarzacza wybrać wyjście dźwięku. Podobno wyjście „na słuchawki” oferuje specjalny profil, znacząco poprawiający wrażenia słuchowe – nie zdążyłem jeszcze tego sprawdzić… Możemy również, zamiast katalogów z plikami audio wskazać bibliotekę iTunes. Miło. Ewidentnie widać, że autorzy wzięli się ostro do pracy i chcą z naprawdę wyśmienitego grajka, zrobić program idealny.
Mnie ciekawią dwie sprawy: czy im się to uda i czy program będzie nadal dystrybuowany za darmo…?
Nie tak dawno opisywałem na łamach applesauce swoje boje z klimatyzatorem. Jedną z kwestii, która mnie pozytywnie zaskoczyła, było to, że dzięki dedykowanej aplikacji oraz posiadaniu konta w serwisie producenta, mogę zdalnie urządzenie wyłączać – a co ważniejsze – również je włączać. Postanowiłem sprawdzić, jak wygląda sprawa uruchamiania, bądź wybudzania komputerów, na odległość. I temu właśnie tematowi poświęcam niniejszy wpis.
Na samym początku zdradzę, że finalne efekty są dość zdywersyfikowane i zależą od wielu czynników, które nie omieszkam się opisać. Temat potraktowałem raczej ambicjonalnie, ponieważ jak dotąd udawało mi się funkcjonować bez takich udogodnień, ale jak wiadomo, apetyt rośnie w miarę konsumpcji, a z oczekiwaniami dotyczącymi wygody, jest identycznie :)
Większość z Was, drodzy czytelnicy jeśli nie miała do czynienia, to słyszała pojęcie: WOL – Wake On LAN, czyli wybudzanie po sieci lokalnej. Oczywiście określenie to, używane jest obecnie także do opisania innych metod, ale po kolei. Załóżmy, że mamy komputer i chcemy go zdalnie obudzić, w takiej sytuacji pojawiają się następujące problemy do rozwiązania:
platforma: Mac / PC
sposób podłączenia do sieci: Ethernet / WiFi
dostęp do sieci, lokalnie lub z Internetu: LAN / WAN
stan komputera: uśpiony / wyłączony
Z powyższymi wiążą się kolejne komplikacje. Spędziłem kilka długich dni na testach i poszukiwaniach, a sprawę utrudniały dość często sprzeczne informacje, dostępne u wielu źródeł.
Całą tajemnicę budzenia na odległość, można uprościć do dwóch, koniecznych warunków:
z urządzenia nadawczego (komputera/smartfona/tabletu/itp.) wysyłamy specjalnie spreparowane dane, zwane Magic Packet,
odbiorca pakietu musi mieć aktywny interfejs sieciowy, bym móc ten magiczny pakiet przyjąć.
Rzecz jasna, „od kuchni” jest to znacznie bardziej skomplikowanie…
STAN KOMPUTERA
Niezależnie od tego, czy komputer jest uśpiony czy wyłączony, by zagwarantować odbiór magicznego pakietu, karta sieciowa komputera MUSI być zasilana. Wyłączony interfejs oznacza komputer odłączony od sieci.
Sytuacja I – Komputer uśpiony
Sprawdzamy odpowiednie preferencje systemowe. Dla OS X weryfikujemy, czy „zaptaszkowana” jest opcja Budź przy dostępie przez sieć, którą znajdziemy w kategorii Oszczędzanie energii.
Pod Windowsem natomiast, musimy sprawdzić właściwości karty sieciowej, w dwóch miejscach:
Zarządzanie energią (tu warto zaznaczyć wszystkie opcje, lub ew. pominąć pierwszą, związaną z oszczędzaniem energii)
Zaawansowane (tutaj warto dla każdej właściwości związanej z budzeniem, przełączyć wartość na Włączone)
Może się okazać, że mamy pecha i akurat nasz sprzęt nie posiada interfejsów sieciowych wspierających Wake On LAN… Kolejna sprawa to notebooki i laptopy – może się okazać, że aby wybudzić uśpiony taki komputer, musi być on podłączony do prądu, inaczej mówiąc zasilany z sieci energetycznej, a nie oczekujący na zasilaniu bateryjnym. Z drugiej strony, komputer przenośny częściej mamy pod ręką, zatem zapewne rzadziej zachodzi potrzeba zdalnego wybudzenia.
Sytuacja II – Komputer wyłączony
Tutaj niestety muszę zmartwić wszystkich użytkowników jabłuszek – na chwilę obecną nie ma możliwości zdalnego zastartowania wyłączonego Maczka :/ Trudno powiedzieć, co odpowiada za taki stan rzeczy, czy „Think Different”, czy wyjście z założenia, że macuserzy nie wyłączają swoich komputerów, tylko je usypiają? Nawet jeśli OS X jest stabilny jak skała, to jednak wyjeżdżając na dwutygodniowe wakacje, zostawiać go uśpionego (zwłaszcza, gdy brak UPSa) nie będziemy. A los bywa tak perfidny i dowcipny, że akurat w tym właśnie czasie, możemy potrzebować dostępu do istotnych plików…
Tak czy inaczej, jedyne wyjście na to by Mac dał się obudzić (i dotyczy to zarówno budzenia w sieci lokalnej jak i przez Internet), to przełączyć w tryb sleep. W tym stanie podtrzymywana jest pamięć, karty sieciowe i inne niezbędne komponenty. Nie wiem, z jakim poborem mocy należy się w takiej sytuacji liczyć, będzie to zdecydowanie więcej niż gdyby komputer był wyłączony (no, nie całkowicie). Z drugiej strony możemy śmiało założyć, że z uwagi na przyjazność środowisku, produkty Apple, nie są aż tak łakomymi pożeraczami energii.
Z pecetem jest tu nieco lepiej, ale za pełen sukces odpowiada „szczęście egzemplarza”. To od możliwości płyty głównej oraz dostępnych ustawień w BIOSie/EFI zależy czy nasz komputer włączymy zdalnie czy nie. Pecet w moim domu, bazuje na starej już płycie głównej Asus P8P67LE, ze zintegrowanym Gigabit Ethernetem firmy Realtek (PCIe). W BIOSie, w trybie zaawansowanym, w menu Advanced i kategorii zwanej APM załączyłem „Power On By PCIE”. Tak po prawdzie, z lenistwa, to załączyłem prawie wszystkie dostępne tam opcje Power On :)
Bardzo często przy złączu RJ-45, na tylnym panelu, znajduje się dioda sygnalizująca pracę karty sieciowej, jeśli się świeci przy wyłączonym komputerze, to oznacza, że ten interfejs jest podtrzymywany, a Magic Pocket powinien uruchomić urządzenie.
PODŁĄCZENIE DO SIECI
Według praktycznie wszystkich źródeł, komputer, który chcemy wybudzić zdalnie, powinien być podłączony do sieci po kablu. Informacje takie, znajdziemy również w appkach dla iPhone, które potrafią wysłać magiczny pakiet (opiszę je nieco dalej). Śmiem twierdzić, że nie jest to stuprocentowa prawda, i zależy to od konkretnego modelu komputera, płyty głównej, bezprzewodowej karty sieciowej, oraz systemowego wparcia. Mój stacjonarny pecet nie posiada karty WiFi, ale sprawdziłem możliwość wybudzenia bezprzewodowego w służbowym laptopie (Asus K52JC), niestety próby zakończyły się całkowitym niepowodzeniem.
Okazuje się, że – dla odmiany – z komputerami Apple jest tu lepiej. Firma, jak ma w zwyczaju, wdrożyła własną implementację WOL zwaną WOD – Wake On Demand. Nie będę tu przepisywać specyfikacji, streszczę tylko wyjaśniając, że funkcja ta działa oczywiście tylko z uśpionymi komputerami, oraz wykorzystuje technologię Bonjour a dokładnie usługę Bonjour Sleep Proxy, oraz działa również z kartami bezprzewodowymi AirPort! Czy nasz komputer posiadający taką kartę WiFi obsługuje WOD, należy sprawdzić w aplikacji Informacje o systemie (dawniej Profil systemu).
O dziwo mój stary iMac wspiera Wake On Demand i przewodowo i bezprzewodowo.
BUDZENIE W SIECI LOKALNEJ
To przysłowiowa bułka z masłem, o ile nasze komputery spełniają wyżej opisane warunki. Potrzebujemy jedynie „prowodyra”, czyli urządzenia które wyśle Magic Packet. Ja oczywiście od samego początku myślałem o iPhone, urządzeniu, które mam praktycznie 99% czasu przy sobie, jako inicjatorze pobudki pozostałych gratów. W tym celu przeprowadziłem szybkie poszukiwania odpowiedniej aplikacji. App Store „wypluł” pokaźną listę, którą zgrubnie odfiltrowałem, zostawiając na polu bitwy tylko darmowe appki. Poniżej przedstawię dwie, moim zdaniem najlepsze.
NetAwake – program autorstwa Power of Two Software to, szybkie proste i estetyczne i estetyczne rozwiązanie WOL. Przewagą NetAwake nad innymi programami jest to, że wykorzystuje Bonjour, do wyszukiwania możliwych do wybudzenia maszyn w sieci.
Inaczej mówiąc, jesteśmy zwolnieni z odnajdywania i wpisywania fizycznych adresów interfejsów, tzw. adresów MAC, które to stanowią kluczową informację determinującą odbiorcę magicznego pakietu.
W przypadku innych platform trzeba ręcznie dodać wpis zawierający nazwę i MAC adres. Myślałem, że instalacja tego, rozwiąże sprawę, jednak NetAwake nie chce, z automatu, mojego peceta zobaczyć…
Chyba jedyną wadą NetAwake jest fakt, że nie ma możliwości podania adresu IP, co przy budzeniu z sieci zewnętrznej (WAN) jest elementem niezbędnym.
Ograniczenia tego, nie ma druga z polecanych przeze mnie appek.
Mocha WOL – to produkt MochaSoft znanego z wielu innych programów wspierających zabawy w sieci.
Nie jest może idealny, ale posiada wystarczające możliwości konfiguracyjne i jest również darmowy.
Pozwala również na zmianę domyślnego (9) portu usługi!
Gdy mamy już ściągniętą i zainstalowaną taką aplikację na iPhone, dodaliśmy komputery, są uśpione (lub wyłączone, w przypadku PC wspierającego Power On…), możemy śmiało rozpocząć pobudkę na odległość!
To zdecydowanie najtrudniejsza w realizacji sprawa, właściwie to możliwa do osiągnięcia w bardzo specyficznych warunkach.
Na pierwszy rzut oka, wygląda na to, że jedynym problemem jest dostarczyć pakiet z sieci rozległej WAN do lokalnej LAN. Ale to zaledwie początek góry lodowej…
Po pierwsze musimy uświadomić sobie, że nasza sieć lokalna, jest widoczna w Internecie pod publicznym adresem IP, przypisywanym naszemu modemowi, przez dostawcę usługi (ISP). Problem w tym, że większość popularnych usług (Neostrada, Net24, itp.) przypisuje ten adres dynamicznie, czyli zmienia się on co jakiś czas, a zmiana ta może być inicjowana przez operatora, bądź wynikać np. z restartu modemu (po zmianie ustawień lub przerwie w zasilaniu). Gdy adres się zmieni, to go nie znamy, więc trudno z zewnątrz dostać się do swojej sieci.
Najlepszym rozwiązaniem jest posiadanie stałego publicznego (zewnętrznego) adresu IP. Niektórzy operatorzy (np. w sieciach kablowych) oferują taką możliwość za dodatkową opłatą, u innych wiąże się to ze zmianą „taryfy”, z indywidualnej na firmową.
Alternatywnym rozwiązaniem są serwisy DDNS, jak no-ip.com czy dyn.com które pozwalają na rejestrację domeny powiązanej ze zmiennym publicznym adresem naszej sieci. Niestety, aby móc aktualizować to przypisanie, musimy:
„poświęcić” jeden z komputerów w naszej sieci lokalnej, zainstalować na nim oprogramowanie klienckie, które po każdej zmianie adresu IP wyśle notyfikacje to naszego konta w serwisie DDNS, lub
posiadać router wspierający usługę Dynamic Domain Name System, a urządzenie włączone 24 godziny na dobę, samo będzie wysyłać aktualizacje do serwisu.
Niestety, Time Capsule nie wspiera DDNS w taki sposób, by możliwe było skorzystanie w wyżej wymienionych serwisów.
Próbowałem zgłębić temat iCloud i usługi Zdalnie na moim Macu (Back To My Mac), bo przecież tą drogą aktualizacje zmian adresu IP również się dokonują. Jednak, jak się okazało, Apple korzysta tu z protokołu i adresacji IPv6, co sprawę komplikuje na tyle, że się w końcu poddałem.
Gdy się uporamy ze zmiennym publicznym adresem IP, będziemy musieli się zmierzyć z kolejnym problemem – przekierowanie portu, na którym działa usługa WOL (domyślnie 9, ale często też wykorzystywany jest port o numerze 7). Znów, wygląda to trywialnie i właściwie w przypadku znakomitej większości routerów, to prosta sprawa. Sęk w tym, że przekierowanie powinniśmy ustawić na tzw. adres rozgłoszeniowy (ang. broadcast address) naszej sieci lokalnej! Dlaczego? Ano dlatego, że interfejsy sieciowe, nawet jeśli są podtrzymywane „przy życiu”, to gdy komputery są uśpione bądź wyłączone, nie mają przypisanych prywatnych adresów IP. Dlatego magiczny pakiet wysyłany musi być do wszystkich potencjalnych odbiorców, czyli po całej puli adresowej sieci lokalnej. Lecz tylko odbiorca, posiadający właściwy adres MAC, przesyłkę odbierze i zinterpretuje.
Tu pojawia się kolejna wada Time Capsule – nie pozwala na przekierowanie portu na adres rozgłoszeniowy (np. 192.168.1.255).
Próbowałem partyzantki, tj. ręcznej edycji pliku konfiguracyjnego TC, bez skutku. Utworzyłem podsieć, czyli ograniczyłem o połowę pulę DHCP, zmieniłem maskę podsieci na 255.255.255.128, tak by broadcast był pod adresem 192.168.1.127 – to również nie zadziałało.
Przeprowadziłem też zabawę z przypisywaniem adresów statycznych komputerom, i utworzyłem przekierowania portów dla tych konkretnych IP.
I… nawet to poskutkowało, ale tylko przez kilka minut po uśpieniu/wyłączeniu komputerów. Dokładnie trwało to tyle czasu, ile funkcjonowały wpisy w tablicy ARP routera. Wpisy tworzone są dynamicznie i przechowywane w pamięci podręcznej, oraz usuwane/odświeżane po upłynięciu tzw. czasu życia odwzorowania.
No to mamy trzecią już wadę Time Capsule – brak możliwości utworzenia statycznych odwzorowań w tablicy ARP.
No to by było chyba na tyle :) Jeśli macie jakieś pytania, lub własne doświadczenia, podzielcie się nimi w komentarzach. Mam nadzieję, że to mini-kompendium, zebrane w jednym artykule, mimo że dotyczy konfiguracji mojego „parku maszynowego”, pomoże zainteresowanym, w rozwiązaniu podobnych problemów.
Ja, chcąc nie chcąc, muszę zakceptować niedoskonałości TC i zrezygnować z budzenia komputerów przez Internet. Bardziej mnie jednak irytuje fakt, że wciąż nie wiem, jak rozwiązali ten problem magicy z Samsunga…
Zapraszam Cię do innych ciekawych wpisów dotyczących sieci, które ukazały się na applesaue.pl:
