mmemuar ;)

Vide ostatni wpis. Mercurial jest fajny, bo:

1. Nie jest gitem. Jest specjalnie robiony w taki sposób, żeby być jak najbardziej intuicyjny w użyciu i nie straszyć ludzi nadmiarem opcji (większość bardziej zaawansowanych komend jest domyślnie nieaktywna i trzeba je aktywować w konfigu).

2. Jest w pythonie. Lubimy pythona.

3. Posiada równoważnik najważniejszych funkcji darcsa -- poleceń record/pull, w postaci poleceń record/transplant.

4. Ma out of the box (acz domyślnie nieaktywną) bardzo potężną funkcjonalność Mercurial Queues, które są implementacją koncepcji quilta w oparciu o VCS. Jest to naprawdę zajebista i prosta w użyciu zabawka. Na chwilę obecną w pracy zajmuję się dokładnie tym, co opisywałem w poprzednim wpisie -- grupuję sobie poszczególne commity składające się na implementację jednego konkretnego ficzera, po czym folduję je w jeden (a następnie zmieniam im kolejność, żeby rzeczy branch-specific były zawsze commitowane ostatnie). I nawet jak hg już się dorobi rebase'a, to i tak najprawdopodobniej nie będę z niego korzystał, bo MQ też w bardzo prosty sposób umożliwia zsynchronizowanie się z nowszą wersją upstreama.

I nowy 7thguard będzie trzymany właśnie w mercurialu. Najprawdopodobniej w MQ.

Wheeeee, dawno już nie miałem tyle radochy z nowego narzędzia.

Distributed VCS-y są fajne, od paru lat w pracy używałem darcs-a. Problem z darcsem jest taki, że (a) ma w cholerę bugów i (b) praktycznie rzecz biorąc jest martwy. Czas na alternatywy.

Ostatnio bawię się bazaarem m.in. dlatego, że PLD przeszło na launchpad.net z którym bazaar jest domyślnie zintegrowany, więc gdyby kiedyś mi się nudziło i przerzuciłbym PLD-owego CVS-a do bazaara, to od razu mielibyśmy integrację z bugtrackerem. Poza tym bazaar jest dosyć intuicyjny, Shuttleworth przekonująco pisze, a całość jest w Pythonie.

Problem: nie odpowiada on mojemu trybowi pracy.

Darcs ma dwie wielkie zalety:

1. Polecenie do robienia commitów jest domyślnie interaktywne, tzn. pyta się czy zapisać każdą jedną zmianę w każdym pliku. Brzmi wkurzająco, ale, po pierwsze, wystarczy nacisnąć 'a' (all) i z głowy, a po drugie oznacza to, że mogę, mając kompletnie rozgrzebany plik z kodem, zauważyć, że właśnie stworzyłem self-contained zmianę i sobie ją commitnąć niezależnie od całej reszty śmiecia w pliku. Jest to bardzo naturalny sposób pracy, bo, zwłaszcza przy większych zmianach, dopiero w trakcie ich tworzenia zauważam wyodrębniające się niezależne, eee, ciągi funkcjonalne (?). Afaik inne VCS-y zaadoptowały to w postaci trybu "interactive" (bazaar przez plugin, hg chyba domyślnie w kodzie, nie wiem jak git).

2. Darcs nie ma rewizji, dla niego rezpozytorium to tak naprawdę zbiór patchy. Oznacza to, że (a) komenda rebase (w bazaarze jak zwykle w postaci pluginu, w hg nie mam pojęcia, czy w ogóle jest, a git ma domyślnie) jest kompletnie bez sensu, bo mogę sobie pullnąć patche z czegokolwiek na cokolwiek, ważne, żeby się nakładały i (b) mogę utrzymywać kilka wersji dokładnie tego samego drzewa, różniących się tylko i wyłącznie jednym patchem.

Punkt pierwszy to nie problem, punkt drugi i owszem. Wynikają z niego dwa różne workflowy:

1. Surwiwal fitnessu (survival of the fittest). System ma robić X. Nie mam pojęcia jaki jest najlepszy sposób na zrobienie X, więc robię kilka możliwych implementacji, po czym odpalam je na różnych maszynach. I dalej wprowadzam równoległe zmiany sprawdzając, jak różne wersje na nie zareagują. W darcsie jest to proste, wystarczy, żebym w pewnym momencie do jednego drzewka wprowadził patch XX, a do drugiego XY i pullując nowe zmiany z drzewka A do B lub vice versa, pamiętał o niepullowaniu tych konkretnych patchy. I mogę sobie tak rozwijać równoległe wersje tego samego programu praktycznie w nieskończoność, zachowując owe różniące je patche. O ile wiem w bazaarze w ogóle tak się nie da, nie wiem jak w hg i gicie.

2. Odgałęzianie się od ruchomego pnia (dla twardzieli: odbranchowywanie się od movowalnego trunka). Sprowadza się do tego, że mam gotowy kawałek softu, który jest rozwijany niezależnie ode mnie przez upstream i ja mam na ów soft nałożyć własne poprawki, sporadycznie mergując się z upstreamem. W darcsie nie problem, mogę pullować dowolne patche skądkolwiek dokądkolwiek, w pozostałych natomiast potrzebny jest rebase. Jak pisałem: bzr i git to mają, nie wiem jak hg.

Pierwszy tryb rozwoju softu jest dosyć specyficzny dla mojej pracy, drugi natomiast, co uświadomiłem sobie dosyć niedawno, wcale nie (acz też obecny). radioemiter.pl i pld-users.org to dokuwiki, www.pld-linux.org to MoinMoin, forum.pld-linux.org to bodajże phpbb (acz nie stawiane przeze mnie). I gdybym wtedy wiedział to, co wiem teraz, to wszystkie one od razu lądowałyby w jakimś VCS-ie. Bardzo ładnie ten problem wyszedł z pld-users, gdzie jeden z adminów zupgrejdował do nowszej wersji dokuwiki i wszystkie moje site-specific zmiany poszły do /dev/null. I żeby je teraz odzyskać będę się musiał z jakimiś patchami i diffami bawić (zakładając, że gdzieś się zachowała stara wersja). A tak, to jeden rebase i po paru minutach miałbym z głowy.

I właśnie dlatego nowy 7thguard, stawiany na drupalu, będzie od początku czymś wersjonowany.

Przy czym nie samym rebasem człowiek żyje. Można powiedzieć, że na co mi rebase -- ściągam najnowszą wersję upstreama, diffuję względem wersji od której się odbranchowałem, po czym próbuję nałożyć takiego patcha na swój kod z commitlogiem "upgrade to upstream X.Y.Z". Prawda, rzecz w tym, że w wypadku tego typu workflowu bardzo liczy się przejrzystość commitlogów, gdyż po paru latach pogubię się w tym, co tam właściwie jest zrobione względem oryginału, a już tym bardziej będzie z tym miał problem ktoś inny chcący też coś pomóc.

I tutaj wychodzi drugi problem z bazaarem -- nie wspiera on przepisywania historii. Rebase rebasem, ale po jakimś czasie commitlogi wyglądałyby tak: 3. implemented X; 4. fixed bug in X; 7 upgraded to upstream 5.0; 11 X obsolete, same functionality implemented elsewhere", etc, etc. Tego typu historia jest ważna w przypadku publicznego projektu, do którego jest np. bugtracker i w którym spójność całości jest święta (to dlatego Linus nie rebase'uje swojego drzewa, ani nie grzebie w jego historii post-factum). Jest ona natomiast ewidentną przeszkadzajką (bo zamazuje obraz zmian) w przypadku projektów bardziej prywatnych, typu opisanych powyżej/tych, co mam w pracy. Po prostu utrudnia życie.

Jestem praktycznie pewien, że z gitem tutaj nie byłoby problemów, nie wiem natomiast jak hg.

W ogóle dosyć oczywiste jest, że bazaar odpada i że najprawdopodobniej wyląduje na gicie. Łudzę się jeszcze, że hg spełni moje wymagania, acz nie mam jakiś specjalnych nadziei. Ot, po prostu, autorzy gita najprawdopodobniej przewidzieli powyższe przypadki użycia oraz setki innych, o których jeszcze nie pomyślałem i które pewnie nigdy nie będą mi potrzebne. Do tego git ma pewnie zaimplementowane optymalne sposoby integracji z wszystkimi innymi rozwiązaniami na rynku (perforce anyone?), więc gdybym kiedykolwiek trafił do jakiejś firmy, gdzie standardem jest coś niespecjalnie wygodnego, najprawdopodobniej byłbym w stanie uprzyjemnić sobie życie przy pomocy odpowiednio użytego gita.

Główny problem z gitem jest taki, że jest on trudny i nieintuicyjny dla ludzi wychowanych na czymkolwiek innym. Tego problemu nie ma z bazaarem, nie wiem jak z hg, ale git to jest oczywisty kosmos. Jest to trochę sytuacja jak z vimem -- używam, bo jest dla mnie wydajniejszy, niż alternatywy. Ale gdybym musiał kogoś innego zmuszać do jego używania, to już byłby problem. Ale nie muszę, bo edytować tekst można w czymkolwiek. Z VCS-ami już nie ma tak łatwo. Jeśli wrzucę 7thguarda do gita, to znacznie podniosę poprzeczkę dla kogokolwiek, kto chciałby w tym później coś pogrzebać (ditto dla pld-users i reszty). Tak nie jest w przypadku np. bazaara, bo czyś z CVS-a, SVN-a, czy czegoś takiego, będziesz się czuł jak w domu.

(To jest powód dla którego przy jakichkolwiek zmianach PLD prawie na pewno nie wyląduje na gicie. Zaawansowane funkcje gita i tak nie zostałyby wykorzystane, a ludzie by się pewnie w końcu zbuntowali, że nowy soft działa kompletnie na odwrót, niż stary dobry CVS. Tego problemu praktycznie nie byłoby właśnie z bazaarem.)

W ogóle nowy 7thguard to będzie ciekawy przypadek. W teorii w ogóle nie powinienem musieć grzebać bezpośrednio w kodzie drupala, wszystko powinno być do załatwienia themami, konfigami i pluginami. W teorii. Jak to wyjdzie w praniu, to się jeszcze zobaczy.

Hmmm, tak się zastanawiam. Może te systemy to jest nowy sposób na rozwój różnych webowych CMS-ów i takich tam? Może to właśnie powinno być specjalnie robione tak, żeby klienci mogli upgrejdować swoje rozwiązania przy pomocy jakiegoś bzr-a z rebasem? Nowe tarballe powinny od razu zawierać katalog .bzr, a nowe wersje powinny być także dostępne do łatwego pullowania/mergowania takimi narzędziami? Graficzne konfigo-klikadła powinny automatycznie commitować wprowadzone zmiany? Interesting... Ciekawym, czy dałoby się taki sposób tworzenia stron dla klientów wprowadzić w mojej opolskiej firmie. Acz to już temat na osobny wpis.

19:47 <Aria> Amazon EC2 AMI ID: ami-5ced0935 <- pld linux th base setup as a public image, you can setup an ssh key through amazon's api and run your very own.
19:47 <Aria> (Caleb Maclennan's work)

Ok, that's like way cool 'n shit. Those crazy foreigners and their crazy ideas!

(My next entry will be about Google switching to PLD. Seriously. Stay tuned.)

Ten wpis i tak jest przeraźliwie długi, nie chce mi się linkować do definicji używanych pojęć (od czego wujek google), a już tym bardziej do źródeł z których wiem w jaki sposób np. power management, albo WiFi ssie w Linuksie. Ale to zazwyczaj wystarczy poszukać prezentacji maintainerów tychże podsystemów. Oni wiedzą najlepiej co jest źle. Przykład. I dla niekumatych: ja w tym tekście w żaden sposób nie krytykuję niedesktopowych zastosowań Linuksa. A, i jeszcze polecam przeczytać to.

Im jestem starszy, tym bardziej szanuję swój czas i tym większą mam ochotę używać optymalnie dopasowanych narzędzi. Czyli np. przestać używać Linuksa na desktopie, bo prawda jest taka, że, w porównaniu do konkurencji, technicznie wypada dosyć blado.

Zaawansowane zarządzanie energią (aka hibernacja i pochodne)? Raz działa, raz nie działa, sterowniki często nie mają obsługi niczego poza on/off (a Vista afaik jest bardziej bateriooszczędna od Linuksa). Dźwięk? Podstawowy zazwyczaj działa, ale alsa jest wybitnie głupio zrobiona (próbował ktoś kiedyś wykombinować co robią różne ustawienia w mixerze?) i dalej wszyscy jeżdżą na różnych demonach dźwięku. O jakimś standardzie dla kodeków nie wspomnę. WiFi? Jak działa, to dobrze, jak nie, to masz pecha, bo pewnie nie ma dla ciebie sterowników. Obsługa 3D? Hahaha. Xorg jest sto lat za murzynami (i to prawie we wszystkim), binarne sterowniki supportują co chcą (a w ATI pewnie dalej nie działają), kernel dopiero zaczyna mieć jakieś ficzery pozwalające mu nad tym wszystkim zapanować (i nie wiadomo, czy nvidia i amd będą z tego korzystać), a konkurencja od X lat traktuje to wszystko jako oczywiste ficzery. Obsługa różnych dodatkowych urządzeń? Jak trafisz na coś supportowanego, to git, jak nie, no to pech. Rosyjska ruletka z kupowaniem jakiegokolwiek osprzętu, a przy kupowaniu laptopa to tylko z listą supportowanego sprzętu w garści.

Część z tych rzeczy to po prostu opóźnienia w rozwoju (głównie Xorg), na część natomiast jest albo za późno (ktoś ma ochotę poprawiać alsę? albo dalej twierdzić, że gstreamer wszystko rozwiąże? ile to już lat?), albo są nieuniknionymi konsekwencjami metodologi open source. Prawda jest taka, że dla producentów sprzętu/użytkowników binarne sterowniki i nieczęsto updejtowane Windowsy są zdecydowanie tańsze w supportowaniu/wygodniejsze, więc nie ma i nie będzie masowego ich otwierania. Z czego wynika, że dla rozwiązań desktopowych Linux będzie zawsze gorzej supportowany, bo zawsze będzie spora część rynku preferująca binarki. Producent może stworzyć sprzęt, napisać sterowniki, przetestować na dosłownie kilku dostępnych na rynku Windowsach, dopisać proste GUI i wsio. Na Linuksie (a) musisz mieć otwarty kod, czyli tajemnica handlowa /dev/null (tajemnica handlowa jest znacznie starsza od Linuksa i, niezależnie od życzeń Linuksiarzy, producenci raczej nie zaczną z niej rezygnować), (b) produkowanie własnego oprogramowania do obsługi sprzętu jest kompletnie niepraktyczne, więc obsługa twojego sprzętu będzie tylko do tego stopnia przyjazna, do jakiego pozwala obecny stos softu danego typu. Czyli zazwyczaj średnio na jeża albo wcale (alsa i jej intuicyjny mixer? karty 3d i zaawansowane ustawienia 3d? nie wiem, kamera i jakieś niestandardowe ficzery? wszystko padaka).

Oczywiście spora część z tych problemów zostanie rozwiązana, gdy Linux na desktopie się odpowiednio rozpędzi i producenci będą zmuszeni go supportować. Tyle, że to się nie stanie. Linux na desktopie technicznie jest sto lat za murzynami, a fajne programy open source albo już od dawna są (Firefox), albo niedługo będą (KDE-pochodne) miały porty pod Windowsa i OS X. Więc niby z jakiego powodu rynek masowy miałby wybierać desktopy linuksowe? Bo KDE4 ma fajny zestaw programików do groupware? Niedługo będzie dostępny pod Windowsy.[1] Coś jeszcze? Czy naprawdę istnieją jakieś konkretne podstawy, żeby przypuszczać, iż desktopowy Linux osiągnie masę krytyczną?

([1] I jest to afaik także prawda w przypadku typowo linuksowatych narzędzi deweloperskich. Obecnie da się spokojnie postawić linuksowe środowisko deweloperskie z desktopem na nielinuksie. ssh/vnc/sieciowe x11/samba to twoi przyjaciele.)

Natomiast w drugą stronę przewaga jest miażdżąca. Konkurencja zawsze ma soft state-of-the-art, a Linux albo całkiem sensowną alternatywę (dostępną także na systemy konkurencji...), albo popłuczyny (photoshop anyone?), albo zupełne nic (rynek gier hahaha).

Nadganianie tego typu zaległości jest możliwe jeśli się ma bardzo dużo wykwalifikowanej i skupionej na konkretnym celu kadry oraz wytworzy odpowiedni ekosystem tworzenia wysokiej klasy oprogramowania dla danego systemu. Microsoft ma tony kasy i tysiące inżynierów, więc może sobie pozwolić na przepisanie systemu grafiki w Viście od zera. Dodatkowo wytworzył gigantyczny ekosystem zewnętrznych firm, które sporo zarabiają na produkowaniu softu pod Windowsy (takie Adobe małą firmą nie jest). Linux ma: brak nawyku płacenia za cokolwiek (ekosystem możemy pożegnać), gigantyczną ilość dystrybucji praktycznie uniemożliwiającą wydawanie binarnych wersji softu oraz stosunkowo niewielką ilość rzeczywiście wykwalifikowanych inżynierów, którzy jeszcze zazwyczaj robią to samo po kilka razy (KDE vs. GNOME, PulseAudio vs. gstreamer vs. czysta alsa, chyba z dwa podejścia do nowej generacji sterów 3d w xorgu, gigantyczna ilość różnych dystrybucji, etc.). W takich warunkach można zapomnieć o dogonieniu kogokolwiek.

Heh, ja sam używam dystrybucji o której słyszał jakiś ułamek promila użytkowników Linuksa. I lubię jej używać ze względu na pewne specyficzne rozwiązania techniczne, czyli głównie poldka i duże rozdrobnienie paczek, ale tak naprawdę to się bardzo dobrze sprawdza tylko na serwerach i w niewielkich specjalizowanych środowiskach (w pracy parokrotnie używałem PLD-owych chrootów), a na desktopie jest wybitnie upierdliwe. Desktopy są znacznie bardziej skomplikowane od serwerów i jeśli mam KDE rozparcelowane na 700+ pakietów (a mam :), to można zgłupieć. A do tego dochodzi jeszcze zatrzęsienie różnych dodatkowych bibliotek i demonów do obsługi różnych rzeczy. Hal, policykit, cośtamkit, acpid, serwer dźwięku (który?), bluetooth, coś do wifi, xorg (też 700 paczek :), czcionki i co tam jeszcze. Oszaleć można. Nawiasem mówiąc ciekawym czym się teraz obsługuje WiFi z GUI? Pewnie jakąś nakładką KDE-ową na NetworkManagera (bo przecież nie można napisać po prostu NetworkManagera, tylko trzeba oddzielić backend od frontendu i napisać co najmniej dwa frontendy, jeden dla GNOME, drugi dla KDE; żeby nie było za prosto).

(Może powinno zostać jakimś oficjalnym policy PLD, że desktop ma niższy priorytet, niż serwer? Kto wie, może mogłoby to ułatwić pewne rzeczy.)

Więc o ile PLD może mi dodawać pewną wartość na serwerach (poldek, sposób pakietowania, domyślne konfigi, unifikacja względem FHS i takie tam), o tyle na desktopie praktycznie nie ma na to szans, a wręcz przeciwnie -- takie Ubuntu jest znacznie lepiej zintegrowane, przetestowane i zjada mniej czasu (dlatego staram się upgrejdować swojego laptoka tylko wtedy, gdy naprawdę muszę, bo zawsze coś się pieprzy przy okazji). Dodatkowo w takim Ubuntu Mark Shuttleworth może powiedzieć, że chce obrać kierunek rozwoju X, sypnąć groszem na ludzi to implementujących no i jakiś tam cel zostaje osiągnięty. W projekcie typu PLD jest to możliwe na znacznie mniejszą skalę (np. FHS), na pewno nie desktopową. Nie może przyjść "lider" i powiedzieć, że robimy X, bo go wszyscy oleją. A w Debianie to już w ogóle są cyrki (widzieliście jakie oni flejmy generują o wszystko? porn-geta na przykład, czy ten aplet do monitorowania zużycia CPU z rozbierającą się kobitą). O sensownym quality control można w PLD zapomnieć. Windows się wydaje raz na ruski rok, to się przy okazji mocno przetestuje, Ubuntu raz na pół roku plus Ubuntu ma ludzi od testów, a PLD ma deweloperów, którym się takich rzeczy robić nie chce (mi też się nie chce).

Pytanie: co zamiast? Na pewno nie zrezygnuję z Linuksa na serwerach -- raz, że nic mnie nie kosztuje, dwa, że lubię swoje PLD i trzy -- zawodowo jednak zajmuję się Linuksami, więc muszę mieć bieżący z nimi kontakt. Ale na desktopie? Albo Vista albo OS X. (Oczywiście nie teraz, tylko jak mi laptop padnie i będę musiał kupić nowego. Obecny by Visty nawet nie uciągnął.)

Główna zaleta Appla -- jest uniksowaty, więc mi bardziej po drodze (większość moich obecnych narzędzi po prostu się buduje i działa, bez jakiś akrobacji). Główna wada Appla -- nie mam go jak najpierw przetestować, a kupować muszę od razu ze sprzętem Appla, który jest afaik drogi (i jest go mniejszy wybór, niż standardowych intelowatych). W przypadku Windowsa Vista mam laptop dziewczyny z tymże, więc mogę sobie testować do woli (o czym będą inne wpisy; materiał do wpisu o Firefoksie mam już gotowy, więc się za jakiś czas pojawi, ale do tego od Visty nie).

Inne problemy:

1. Wirusy. W OS X afaik nie problem, ale w Viście jednak wypadałoby mieć jakiegoś antywira. Nie lubię mieć antywirów, jestem przyzwyczajony do braku konieczności ich posiadania. Z punktu widzenia odporności na wirusy kompletny chaos ABI w zatrzęsieniu dystrybucji Linuksa to zaleta.

2. Upgrejdy systemu. Upgrade poldkiem jest upierdliwy, ale prawda jest taka, że swoje desktopy upgrejduję po parę lat bez żadnych reinstalek i po kilku poprawkach zawsze prawie wszystko działa (teraz np. mam wkurzające problemy przez niedorobiony evdev w xorgu). Nie sądzę, żebym przeżył niereinstalkowy upgrade XP do Visty. Nie wiem jak z OS X. Z drugiej strony na raz wydaną Vistę przez następne wieeeele lat wychodzi soft, który można sobie po prostu upgrejdować. Na PLD jak robisz za długie przerwy, to później nowy python wymaga 70% nowego systemu (bo openldap pociągnął coś, co wymaga ixów, ixy są już nowe, więc całe kde i wszystko graficzne trzeba zassać, etc...; i chciałeś nowego pythona, a przy okazji dostałeś rozwalonego evdeva). Mnie od dawien dawna nie podnieca gonienie za numerkami (czego w znacznej mierze nauczyła mnie upierdliwość upgrejdów w PLD), więc Vista by mi tu pewnie bardzo pasowała. Ba, dalej używam KDE3.5, bo mnie przeraża KDE4.

3. Gnicie systemu. Na PLD problemu nie ma, bo poldkiem i rpm-em mam kontrolę nad wszystkim i jak mi się zrobi za dużo śmiecia, to po prostu wyinstalowywuję co chcę, jadę prostym skryptem po zagubionych plikach i mam czysto (jak mówiłem, mogę po parę lat robić upgrejdy całego systemu praktycznie bez nieprzyjemnych skutków ubocznych; wymagają tylko trochę czasu). Nie wiem jak z Applami, ale afaik Vista nadal sobie z tym problemem nie poradziła. Znajomy m.in. przez to ostatnio wrócił do XP, a laptop mojej dziewczyny zamyka się teraz po kilka minut. Dla mnie to jest naprawdę problem, ja jestem bardzo przywiązany do faktu, że PLD daje mi pełną kontrolę nad wszystkimi plikami w systemie (które do tego są uporządkowane; viva la FHS, viva la patche w PLD) i będę miał poważne problemy ze zrezygnowaniem z tego ficzeru. Ten brak kontroli na najbardziej podstawowym poziomie to jest główny powód dla którego nie lubię dotykać Windowsów. Z drugiej strony -- przy tych setkach pakietów desktopowych to ja i tak zazwyczaj nie wiem co się w systemie dzieje.

4. W Windowsie (i OS X?) za sporo rzeczy jednak trzeba płacić. I to nawet za takie, które w Linuksie dostaję jako standardowe wyposażenie. Taka Vista jest bardzo słabo konfigurowalna w porównaniu do dowolnego Linuksa. Zazwyczaj są płatne narzędzia, żeby dodać brakującą funkcjonalność, ale są brzydkie, bo są płatne. Drażni mnie wydawanie kasy na coś, co uważam za podstawową funkcjonalność. Szczęściem jednak jest sporo softu open source tego typu pod Windowsy, ale nie wiem, czy wszystkie moje potrzeby byłyby zaspokojone. Tak czy siak o tym będzie osobny wpis (z serii "Jak zostać power userem" :).

Dobra, tyle. Tak jak pisałem, na pewno w tym momencie na żadną Vistę się nie przenoszę, co najwyżej przy zmianie laptopa. Ale nawet wtedy nie jest to przesądzone, gdyż (a) tak naprawdę cieszę się z faktu, że np. w nic nie gram i rzadko korzystałbym z ficzerów, których w Linuksie nie mam, (b) jakby co, to zawsze jest laptop dziewczyny; oby mnie nie zostawiła i (c) jednak jest zestaw ficzerów typowo Linuksowych do których jestem bardzo przyzwyczajony. Acz hgw jak te rzeczy wyglądają w OS X. Przy czym gdybym dziadkowi kupował nowy laptop, to pewnie wrzuciłbym Vistę, dał mu dostęp tylko do konta nieadminowego i nie miałbym z tym większych problemów, niż mam obecnie z jego PLD i GNOMEm (mam nadzieję; nie wiem jak z wirusami).

Jak komuś się chciało to czytać w całości, to gratuluję samozaparcia. Ja to muszę przeczytać jeszcze z dwa razy, żeby zrobić korektę przed publikacją. :(

Jak klientowi zrobiłeś stronę i ją hostujesz, to wypadałoby też wypozycjonować. Problem -- poza jakimiś technicznymi zaleceniami odnośnie samej strony i dodaniem jej do paru katalogów, SEO to nic, czym się można chwalić. Losowo linkowane keywordy w ramach systemu wymiany linków, tworzenie sztucznych stronek na darmowych hostingach, czy wręcz czyste spamowanie różnych internetowych lokacji? Może jednak nie w firmie z którą mam coś wspólnego.

Tylko co robić z klientem, który domaga się takich usług? Nie mogę mu narzucić swojego "systemu wartości", zwłaszcza, że wytłumaczenie jest dla niego pewnie zbyt techniczne, a nielegalne to to afaik nie jest. Może go przekazać jakiejś firmie od SEO? Ale wtedy mogą go podprowadzić z hostingiem i obsługą WWW, a poza tym nie zobaczymy ani grosza z jego pieniędzy na pozycjonowanie. No to wejść w jakiś program partnerski z większą firmą od SEO (są takie?) i obsługiwać klienta via ów program? Tak, super, będę partnerem spamerów. Eh.

Adwordsy afaik takich klientów zazwyczaj nie interesują. Pewnie za drogie. W ogóle Adwordsy się nie skalują. Im więcej pieniędzy na twoim rynku, tym więcej wszyscy licytują. Ty dostajesz taką samą (albo gorszą) usługę, a Google tylko zgarnia coraz więcej kasy. Zdecydowanie powinny powstać jakieś alternatywy.

Może zaoferować naszym klientom za darmo opcjonalny program "wspierania lokalnej przedsiębiorczości"? Tzn. jeśli chcesz, to wybierasz sobie kilka keywordów i my w treści stron innych klientów (którzy też chcą) automatycznie podmieniamy owe słowa na linki do ciebie. Wygląda jak system wymiany linków [1], ale można przedstawić całkiem sensowną argumentację, że podstawową funkcjonalnością jest jednak prowokowanie ludzi do wchodzenia na strony innych lokalnych firm, a pozycjonowanie w Googlu jest tylko skutkiem ubocznym [2]. Bo chodzi o to, żeby klient do ciebie przyszedł. I nie jest ważne, czy zrobi to przez szukanie odpowiednich słów w wyszukiwarce, czy dlatego, że kiedyś wszedł ze strony o czymś zupełnie innym (ale też z Opola) i zapamiętał, że twoja firma istnieje.

[1] Akurat z różnych technik mrocznego SEO automatyczną wymianę linków uważam za najmniej mroczną, bo (a) nie ładuje treści tam, gdzie właściciel strony nie chce (jak spamowanie for) i (b) nie produkuje bezużytecznej treści (jak tworzenie sztucznych stron z linkami).

[2] W wersji light można to zrobić nie z linkowaniem słów w treści, ale z osobną stroną "wspieramy lokalną przedsiębiorczość" (aka "linkownia") w ramach serwisu danego klienta. To już tym bardziej nie było by się do czego przyczepić.

Eh. I tak mi się nie będzie chciało w to bawić, a nawet gdyby, to pewnie nie zadziała (nie jestem w stanie tego teraz stwierdzić, nie znam się na działaniu Googla). Acz mogłoby nieźle namieszać, gdyby jednak zadziałało i gdybyśmy to oferowali za darmo (w sumie tylko tak miałoby prawo działać). Zmniejszyć dochody Googla, to by było coś.

Ostatnio firma dla której pracuję odczuwa pewną presję finansową, a co za tym idzie pracownicy są pod presją, żeby tworzyć nowe rozwiązania, które będzie można oferować klientom. I dzięki całej tej sytuacji odnalazłem coś ważnego. Przypomniałem sobie co to znaczy, gdy mam konkretną wizję tworzonego systemu, gdy z dnia na dzień widzę, że jest postęp, a rzeczy zaczynają działać zgodnie z zamierzeniami. Gdy po tygodniu rzeczywistej pracy mam działające, dobrze przemyślane demo. Przypomniałem sobie dlaczego tyle lat temu mogłem siedzieć nad PLD i dłubać w paczkach tyle czasu, napisać automatykę, czy robić pierwsze systemy dla w/w pracodawcy. Znowu jestem na bieżąco z LWN-em i listami PLD-owymi. Jest fajnie.

(Oczywiście mój blip na tym poważnie ucierpiał, ale doba nie jest z gumy. Zobaczymy jaki sobie wypracuję rytm dnia na najbliższe kilka tygodni/miesięcy. Wątpię, żebym przetrzymał bez przynajmniej niewielkiej regularnej dawki reddita.)

Uświadomiwszy sobie na powrót co jeszcze może mnie informatycznie kręcić [1], poszedłem sprawdzić co z tego jestem w stanie znaleźć w swojej lokalnej firemce (lokalna firemka!=firma z pierwszego akapitu). Wczoraj usiadłem ze wspólnikiem i pogadaliśmy sobie o tym, jak on widzi źródła przychodów firmy informatycznej w niezbyt dużym mieście (mając rok działalności i doświadczeń za pasem). Jego cele/przewidywania: 60% z umów serwisowych dla firm, pozostałe 40% to proste projekty programistyczne poprzetykane sporadycznie czymś minimalnie ambitniejszym (pomijam klientów indywidualnych na typowe "pogotowie informatyczne"). Czyli nic dla mnie.

[1] Używanie nowych/bardziej zaawansowanych umiejętności/doświadczenia do szybkiego tworzenia/prototypowania (dla mnie) nowych działających systemów. Bonusy za konieczność douczenia się nowej technologii w trakcie.

Umowy serwisowe to zazwyczaj jeżdżenie do klienta i naprawianie mu albo sprzętu, albo użeranie się z Windowsami/dziwnymi programikami. Projekty "programistyczne" to w 90% proste strony www (z flashem), a w pozostałych przypadkach jakieś proste systemy obsługi czegokolwiek, ale też z interfejsem po www. Nie znam się na tych rzeczach, poznać nie chcę (zwłaszcza piekiełka zwanego html/css/js), a w ogóle to wszystko straszne nudy.

Czyli pracy to ja tu nie znajdę. Zajmuję się adminką jednego serwera (PLD z vserverami pod xenem) i wystarczy. Nie mam natomiast nic przeciwko czerpaniu dochodów. Niestety na tak małym rynku jest to raczej utrudnione. Stawki mamy niskie, pracownicy zarabiają niewiele, więc firma większość przychodów przeznacza na koszty stałe i pensje dla pracowników. Płacić takim darmozjadom jak ja jakiś sensownych pieniędzy po prostu nie ma z czego.

No więc temu trzeba zaradzić. Wspólnik twierdzi, że tak naprawdę wszystkie firmy potrzebują obsługi informatycznej, bo prawie wszyscy mają komputery, a prawie nikt nie wie jak z nich sensownie korzystać i się nimi zajmować (stąd te 60% na umowy serwisowe) i praktycznie nikomu nie opłaca się zatrudniać na pełen etat informatyka. Zgoda. Czyli oferując tani [2], kompetentny i spersonalizowany [3] outsourcing IT powinno dać się załapać sporą część tych mas malutkich firemek, które są poutykane po biurach na zadupiu, bądź wręcz po prywatnych mieszkaniach. Nawet bardzo tanie rynki robią się dochodowe przy odpowiedniej skali.

[2] Tani tani. Paręset złotych dla jednoosobowej minifiremki to jest dużo, bo to są pieniądze, których dany człowiek nie może wydać na ubranie czy jedzenie.

[3] Spersonalizowany -- zgłaszając się do średniej/dużej firmy ładujesz się w dział obsługi klienta. W małej/średniej firmie możesz gadać bezpośrednio z szefem, obsługiwać cię może zawsze tych samych dwóch ludzi (z których jeden może być szefem ;), oni sami będą się pewnie interesować sposobami na usprawnienie działania twojej firmy, etc, etc. Moja teoria jest taka, że jeśli sam nie wiesz czego ci potrzeba, to zdecydowanie łatwiej jest sobie niezobowiązująco pogadać z szefem zaprzyjaźnionej firemki, niż próbować szczęścia z BOK-iem czegoś większego.

Ale podczas wczorajszej rozmowy jedna rzecz mi nie dawała spokoju -- czy nie powinniśmy być w stanie zaoferować czegoś więcej albo bardzo bardzo tanio, albo wręcz za darmo w ramach naszej oferty, tak, żeby nasz mały klient miał wrażenie, że nie jesteśmy tylko ludźmi od naprawiania komputerów, ale że rzeczywiście na swój sposób chcemy mu pomóc w lepszym prowadzeniu interesu, że zależy nam na jego wydajności i sukcesie (cholera, gadam jak marketoid). No i na podstawie opisów konkretnych firm, z jakimi miał do czynienia wspólnik ostatnimi czasy, w trakcie rozmowy wpadłem na bardzo prosty, nie wymagający od nas wielkich nakładów, pomysł, mogący potencjalnie osiągnąć wymienione cele i otworzyć nam dostęp do tego rynku. Wspólnik przyznał, że koncepcja jest bardzo dobra, ma potencjał i zdecydowanie trzeba ją wdrożyć i zobaczyć co da. A o co konkretnie chodzi? No cóż, tajemnica handlowa. ;) Jeśli docelowo nie wypali, to pewnie opiszę o co chodziło (i dlaczego moim zdaniem się nie udało).

P.S.
Właśnie mi się przypomniało. Nasza (większa) lokalna konkurencja wpadła na pomysł blokowania maili od nas na swoich serwerach, co oznacza, że nie możemy się kontaktować ze wspólnymi klientami (a mamy takich). Indagowana przeze mnie konkurencja powiedziała, żebym spadał na /dev/drzewo, bo nie jestem ich klientem, więc ze mną nie będą gadać. Strasznie mnie ta małomiasteczkowość ucieszyła, więc zapukałem do naszego wspólnego klienta z prośbą o pełnomocnictwo (w końcu robimy za ich outsourcowany dział informatyczny, więc ma sens, żebyśmy gadali z firmą u której się hostują), po czym udałem się do konkurencji. Co z tego wyniknie dowiem się w poniedziałek. Stay tuned.