Tag: daj się poznać

Tryby operacyjne – tryb rzeczywisty

Tryby operacyjne

Tryb operacyjny (ang. operating mode) procesora to po prostu pewien dobrze zdefiniowany tryb, w którym procesor zachowuje się w ściśle określony, charakterystyczny dla danego trybu sposób. Ciężko o formalną definicję tego pojęcia, ale myślę że zamieszczone niżej opisy trybów operacyjnych IA-32 (architektura potocznie zwana x86) i Intel 64 (architektura x86-64) rozwieją wszystkie wątpliwości.

Intel Architecture 32 bit (x86)

Architektura ta posiada 3 tryby operacyjne plus jeden quasi-tryb:

  • Real mode (tryb rzeczywisty) – inicjalny tryb pracy procesora, posiada interfejs programistyczny procesora Intel 8086 wraz z kilkoma rozszerzeniami – między innymi z możliwością przejścia do trybu chronionego. Dużo szczegółów poniżej.
  • Protected mode (tryb chroniony) – natywny tryb procesora, jeśli czytasz tę notkę z komputera PC, to bardzo prawdopodobne, że Twój procesor właśnie używa tego trybu. Tryb ten pozwala na użycie pełnego potencjału nowoczesnego procesora i to on będzie nam towarzyszył przez znacznie większą część programowania systemu operacyjnego. Dużo szczegółów wkrótce.
  • System management mode (tryb zarządzania) – bardzo nietypowy tryb, w którym mamy wysoko uprzywilejowane środowisko, pozwalające na zarządzanie energią, obsługiwanie krytycznych błędów itp. Na razie tryb ten nie będzie nas interesował.
  • Virtual-8086 mode – wspomniany quasi-tryb, który pozwala na uruchamianie programów przeznaczonych na procesor 8086 w trybie chronionym.

Intel 64 (x86-64)

Architektura ta posiada wszystkie tryby, które posiada IA-32 plus:

  • IA-32e mode, który posiada dwa podtryby:
    • Compatibility mode (tryb zgodności) – podtryb pozwalający uruchamiać aplikacje 16 i 32-bitowe bez potrzeby rekompilacji ich dla procesora 64-bitowego. Co ciekawe, aplikacje działające w trybie Virtual 8086 nie będą działały w tym trybie.
    • 64-bit mode – natywny dla 64-bitowego procesora tryb, który pozwala na korzystanie z dobrodziejstw architektury x86-64. Jeśli Twój system jest 64-bitowy, to najprawdopodobniej Twój procesor pracuje właśnie w tym trybie.

Warto wspomnieć, iż niektórzy wyróżniają tryb nazywany potocznie Unreal mode (tryb nierzeczywisty), jednak nie będę go opisywał.

Tryb rzeczywisty

Wady i zalety

Tryb rzeczywisty to inicjalny tryb procesora, który istnieje do dziś ze względu na inżynierów procesorów, którzy chcą zachować wsteczną zgodność z procesorami sprzed ery 80386. Jakie są tego konsekwencje? Niestety bardzo dotkliwe.

  • Nieco ponad 1 MiB adresowalnej pamięci, a faktycznie nieco poniżej 1 MiB pamięci do użycia
  • Brak zdecydowanej większości ficzerów architektury IA-32, w tym m. in.:
    • Brak jakiejkolwiek ochrony pamięci, co za tym idzie – brak pamięci wirtualnej
    • Brak wielowątkowośći/wieloprocesowości (nikłe możliwości emulacji)
    • Każdy „proces” może wszystko – np. mazać dowolny fragment pamięci, wykonywać instrukcje systemowe itp.
    • Niemożność użycia wszystkich rejestrów, które w trybie chronionym są ogólnodostępne
    • Ograniczone i skomplikowane możliwości adresowania pamięci

Jedyne zalety trybu rzeczywistego, to dość bogate funkcje oferowane przez BIOS, z których będziemy mieli okazję skorzystać.

Adresowanie

Adresowanie w trybie rzeczywistym nie odbywa się w typowy, liniowy sposób. Pamięć adresowana jest w następujący sposób:

Segment : Przesunięcie

Tak zaadresowana pamięć mapowana jest na fizyczny adres o postaci:

16 * Segment + Przesunięcie

Dziwne, prawda? Jeszcze dziwniejsze jest to, że pojedynczy adres fizyczny ma wiele reprezentacji w formacie „rzeczywistotrybowym”, gdyż segmenty zachodzą na siebie. I tak np. 0x12B1 : 0x0069 odpowiada adresowi 0x12B79 (0x10 * 0x12B1 + 0x0069 = 0x12B79), natomiast 0x1000 : 0x2B79 odpowiada adresowi… 0x12B79! (0x10 * 0x1000 + 0x2B79 = 0x12B79).

Do dyspozycji mamy 6 16-bitowych rejestrów segmentowych: CS, DS, ES, FS, GS oraz SS. Stos obsługuje się używając pary rejestrów SS : SP.

Dostępne tryby adresowania to:

  • [BX + offset]
  • [SI + offset]
  • [DI + offset]
  • [BP + offset]
  • [BX + SI + offset]
  • [BX + DI + offset]
  • [BP + SI + offset]
  • [BP + DI + offset]
  • [offset]

Gdzie offset zawiera się pomiędzy -32768 oraz 32767.

Z adresowaniem związane jest jeszcze jedno ciekawe zjawisko, mianowicie, gdy segment ustawimy na 0xFFFF, natomiast przesunięcie na wartość pomiędzy 0x10, a 0xFFFF, to zaadresujemy 64 KiB powyżej granicy 1 MiB, co najprawdopodobniej zaowocuje „zawinięciem” pamięci. Dokładniej zjawisko to potraktujemy przy okazji omawiania linii A20.

Funkcje oferowane przez BIOS

BIOS oferuje do użycia w trybie rzeczywistym szereg funkcji dostępnych poprzez przerwania (o przerwaniach będzie jeszcze rozlegle w kolejnych odcinkach). Opis niektórych funkcji można znaleźć tu. Przykład użycia funkcji BIOS będzie można prześledzić w następnych częściach cyklu.

Podsumowanie

Jak widać, tryb rzeczywisty ma bardzo niewiele do zaoferowania programiście systemów operacyjnych. Tryb rzeczywisty powinien nam zatem posłużyć do szybkiego przejścia do trybu chronionego i ewentualnego wykonania niezbędnych czynności poprzedzających. Aha i tak, system operacyjny DOS działał w całości w trybie rzeczywistym :)

QEMU – podstawy

Emulator, maszyna wirtualna?

QEMU to zarówno maszyna wirtualna jak i emulator, ale co to tak właściwie znaczy?

QEMU jest emulatorem, gdyż potrafi uruchamiać pojedyncze programy jak i całe systemy operacyjne napisane dla procesora innego, od tego na którym aktualnie pracuje. Jest to możliwe dzięki szybkiej translacji rozkazów procesora docelowego na rozkazy procesora na którym działa QEMU.

QEMU w trybie wirtualizacji (potrzebny Xen lub moduł KVM) działa natomiast bezpośrednio na procesorze gospodarza.

Obsługiwane przez QEMU procesory to m. in.: x86, x86-64, PowerPC, MIPS, ARM, SPARC. Pełna lista tutaj.

Podstawowa obsługa – uruchamianie

QEMU to narzędzie konsolowe, podstawowy schemat uruchamiania to:

qemu [options] [image]

Wśród opcji możemy podać m. in.:

-M machine – wybór konkretnej architektury do emulacji (-M ? wyświetla listę dostępnych)

-cpu model – wybiera konkretny procesor (-cpu ? wyświetla listę dostępnych)

-fda file, -fdb file, -hda file, -hdb file, -hdc file, -hdd file, -cdrom file – włącza do naszego emulowanego systemu urządzenia: dystkietkę (przedrostki f), dyski (przedrostki h), cdrom z zwaratością taką jak zawiera file. Uwaga: nie można używać jednocześnie hdc i cdrom.

-boot x – ustala kolejność bootowania: a, b – pierszeństwo dyskietek, c – dysk twardy, d – cdrom.

-m megs – ustala ilość wirtualnego ramu na megs MiB, domyślnie jest to 128 MiB

-kernel file – bezpośrednio uruchamia podany plik zawierający jądro naszego systemu operacyjnego zgodnie ze specyfikacją Multiboot (będzie o tym, w którymś z najbliższych wpisów)

Istnieje jeszcze wiele przełączników pozwalających ustawiać sieć, bluetooth oraz różne inne urządzenia, ale tyle co tu opisałem, w zupełności wystarczy początkującemu osdevcowi :)

Spójrzmy na parę przykładów:

qemu linux.img

Uruchamia system z podanego obrazu linux.img, wszystkie opcje pozostają domyślne.

qemu -hda hda.img -m 128

Uruchamia emulator z podłączonym dyskiem o zawartości hda.img ze 128 MiB ramu. To co się dalej stanie, zależy od zawartości hda.img, gdyż wirtualny BIOS będzie próbował bootować system właśnie z owego dysku. Różnica między tym a poprzedni przykładem jest taka, iż poprzednia komenda mówiła explicite: „bootuj linux.img”, w tym przypadku dajemy QEMU informację o stanie: „Jest dysk, rób co chcesz” ;)

qemu -kernel kernel.bin

Uruchomi nasz kernel według specyfikacji Multiboot, inaczej mówiąc – nie potrzebujemy żadnego bootloadera, a nasz kernel powinien być w jakimś dobrze zdefiniowanym formacie wykonywalnym, np. ELF (o tym też innym razem).

Ficzery QEMU

W QEMU lubię szybkość działania i łatwość obsługi, ale to nie jedyne jego, oprócz wspomnianej już wieloarchitekturowości i bogatych możliwości konfiguracji,  zalety. Istotną cechą QEMU jest to, iż wspiera VBE 2.0 oraz posiada natywne wsparcie dla GDB. Moim ulubionym „ficzerem” jest natomiast QEMU monitor.

QEMU monitor

QEMU monitor, to diagnostyczny tryb emulatora pozwalający podglądać interesujące rzeczy. Po uruchomieniu systemu w QEMU wciskamy CTRL+ALT+2 i już jesteśmy w trybie monitora (CTRL+ALT+1 wraca z powrotem na ekran systemu, natomiast CTRL+ALT pozwala „odzyskać” z powrotem myszkę). W trybie monitora mamy dostępny szereg komend:

info cpus – podaje aktualny stan procesorów

info registers – wyświetla zawartość wszystkich rejestrów dostępnych dla danej architektury. Polecenie to jest szalenie przydatne, szczególnie na początkowych etapach osdevu – np. gdy chcemy sprawdzić czy stronicowanie jest już aktywne, gdzie właśnie utknął EIP naszego procesora i w wielu, wielu innych przypadkach.

Komenda info potrafi jeszcze co nieco, ale na razie tyle nam wystarczy. Kolejne przydatne polecenia to:

x /fmt addr oraz xp /fmt addr – pierwsza z nich wyświetla zawartość wirtualnej pamięci pod adresem addr w formacie fmt, natomiast druga robi to samo, tyle że dla pamięci fizycznej. Format jest natomiast następujący: count – ilość elementów do wyświetlenia (liczba dziesiętna), format – format wyświetlenia zawartości pamięci, tj. x – hex, d – dziesiętny, u – dziesiętny bez znaku, o – oktalny, c – char lub (uwaga!) i – instrukcja!, size – rozmiar, tj. b – 8 bitów, h – 16 bitów, w – 32 bity, g – 64 bity. Przykłady:

xp /40db 0x7C00

Wyświetli dziesiętnie 40 elementów bajtowych spod adres 0x7C00.

xp /40xh 0x7C00

Wyświetli heksadecymalnie 40 elementów dwubajtowcyh spod adresu 0x7C00.

xp /10i $eip

Wyświetli 10 kolejnych instrukcji po aktualnej pozycji EIP. Widzimy, że nie musimy tu podawać rozmiaru, gdyż jak wiadomo w x86 instrukcje mają zmienny rozmiar. Takie wyświetlenie jest szczególnie przydatne, gdy zastanawiamy się gdzie właśnie utknął nasz kernel :)

QEMU monitor posiada jeszcze wiele przydatnych opcji jak np. zrobienie screena, czy nagranie dźwięku jednak nie widzę sensu opisywania ich na obecnym etapie. Kompletny spis można znaleźć tu.

Na zakończenie

QEMU będzie nam bardzo pomocne w całej serii artykułów Tworzenie systemu operacyjnego. Będzie więc wiele okazji aby przećwiczyć zdobytą tutaj wiedzę na temat obsługi tego niezwykle zgrabnego narzędzia. Tymczasem zapraszam do ściągnięcia QEMU stąd, zapoznania się z dokumentacją tu oraz do spojrzenia na inne emulatory, np. bochs. Aha, jeśli ktoś naprawdę nie znosi konsolowych aplikacji, to istnieje parę graficznych nakładek na QEMU, jak np. qtemu czy qemulator, jednak żadnej z nich nie testowałem.

Tworzenie systemu operacyjnego – część 0x00: Wstęp i formalizmy

Skąd pomysł?

Po ponad 6 miesiącach od powstania idei serii postów, pierwsza część ujrzała właśnie światło dzienne. Pomysł na cykl notek zrodził mi się zaraz po ukończeniu kursu „Systemy operacyjne” na mojej ulubionej uczelni. Według (genialnego!) Prowadzącego, około 15% studentów po tym kursie przystępuje do napisania własnego systemu operacyjnego i wygląda na to, że ja jestem w grupie tych ~19 osób. Zapowiada się świetna zabawa :)

Co to będzie?

Seria będzie dokumentować i opowiadać o moich zmaganiach z próbą napisania (od zera) systemu operacyjnego o pewnej funkcjonalności. W postach postaram się zawrzeć wiedzę i kod, który krok po kroku będzie układał się w pełnowartościowy system operacyjny.

Po co to?

Cykl postów o tematyce programowania systemu operacyjnego będzie dokumentacją moich poczynań. Posty będą zdecydowanie miały charakter poznawczy, gdyż w żadnym przypadku nie jestem autorytetem w tej dziedzinie, a (na razie!) tylko początkującym amatorem. Proponuję więc nie polegać na zawartej tu wiedzy podczas kolokwiów z architektury komputerów ;) Proszę też o regularne komentarze z poprawkami do prezentowanych przeze mnie zagadnień – z pewnością będę je wtedy poprawiał. Przy okazji serii mam nadzieję zachęcić czytelników do zagłębienia się w fascynujący świat programowania systemowego, odkryć go nieco, a może nawet skłonić do napisania własnego systemu operacyjnego? Ponadto, nie znalazłem w internecie publikacji w języku polskim, które prowadziłyby krok po kroku (no dobrze, kilka by się znalazło, jednak kroki kończyły się zwykle na 3 odcinkach) po niezwykle zawiłej tematyce tworzenia systemu operacyjnego – będę więc pionierem ;> Przypominam również, że powstający system operacyjny nie ma za zadanie przewyższyć udziału rynkowego takich świetnych systemów jak Microsoft Windows, GNU/Linux czy Mac OS X, gdyż byłoby to niedorzeczne. To po prostu zwykły projekt eksperymentalny.

Co będzie potrzebne?

Najważniejszą rzeczą jest wytrwałość i chęć zdobywania wiedzy :) Posiadając te dwie cechy, nawet całkowity nowicjusz sporo może wynieść z tego cyklu. W swoich wypocinach postaram się zgrabnie balansować między nadmierną gęstością tekstu, a przesadną zwięzłością. Trudniejsze rzeczy postaram się dokładnie objaśniać, łatwiejsze będę traktował po macoszemu, dodając odnośniki, z których będzie można doczytać więcej. Zachęcam do komentowania rzeczy niejasnych i skomplikowanych tak, abym z czasem mógł dostosować poziom.

System operacyjny, przynajmniej z początku, będzie napisany w języku C z małym dodatkiem assemblera x86 (będę używał „dialektu” NASM-a), zatem znajomość C, jak również nieco assemblera zdecydowanie się przyda.

Z całą pewnością potrzebny będzie jakiś działający system operacyjny z dostępnymi narzędziami programistycznymi. W swoich postach będę opisywał tworzenie systemu operacyjnego w środowisku GNU/Linux w połączeniu z typowymi dla tej platformy narzędziami takimi jak gcc czy binutils. Przedstawione przykłady, da się jednak bez problemu skompilować pod Windowsem, czy Mac OS X, wymagałoby to jednak nieco więcej pracy (jeśli będzie taka potrzeba, mogę opisać techniki w oddzielnym poście). Zwolenników systemów innych niż Linux zachęcam do zainstalowania jakiejś łatwej i przyjemnej dystrybucji, choćby na maszynie wirtualnej i programowania w takim środowisku. Gwarantuję, że inicjalny trud się opłaci.

Kolejna rzeczą, która nie jest konieczna, ale znacząco ułatwi nam programowanie i testowanie naszego systemu będzie emulator platformy x86 (gdyż na tą platformę będzie powstawał nasz system). Mój wybór padł na qemu. Emulator przyda się, aby uruchamiać świeżo skompilowany system – choć oczywiście dla wytrwałych pozostaje opcja odpalania systemu na prawdziwej maszynie.

Formalizmy

Koniec gadania, przystępujmy do rzeczy. Chcemy napisać system operacyjny, no dobrze… tylko co to tak właściwie jest? W literaturze dałoby się znaleźć setki mniej lub bardziej zmyślnych/złożonych/obszernych definicji, wymyślić nowych można by było kilka kolejnych, a więc… która jest dobra? Odpowiedzi na to pytanie nie ma, gdyż brakuje obiektywnych kryteriów oceny, czy dana definicja jest poprawna, zła, ładna, zgrabna itd. Mi najbardziej do gustu przypadła następująca:

System operacyjny jest to zbiór programów i procedur spełniających dwie podstawowe funkcje:

– zarządzanie zasobami systemu komputerowego,

– tworzenie maszyny wirtualnej.

Natomiast najtrafniejsza definicja zasobu systemu to wg mnie:

Zasobem systemu jest każdy jego element sprzętowy lub programowy, który może być przydzielony danemu procesowi.

Definicją procesu zajmiemy się przy innej okazji.

Teraz kilka słów wyjaśnień. Jak widać z definicji systemu operacyjnego – nie jest on sam w sobie programem, a zbiorem programów i procedur. System, który będziemy implementować za jakiś czas będzie wyglądał z punktu widzenia czysto technicznego jakby był jednym programem, jednak to tylko decyzja implementacyjna – w ogólności tak być nie musi. Pierwsza funkcja, którą pełni system operacyjny wydaje się być jasna – zarządza on zasobami, które oferuje. Zarządza, czyli udziela dostępu użytkownikowi, czy też raczej programowi użytkowemu. Zasoby sprzętowe to na przykład dysk twardy, pamięć, czy też komputery podłączone w sieci, do stacji na której działa system operacyjny. Zasoby programowe to natomiast wszelkiego rodzaju tablice, czy też semafory. Druga funkcja, czyli tworzenie maszyny wirtualnej może brzmieć nieco tajemniczo. Sama maszyna wirtualna jest raczej kojarzona z procesem wirtualizacji, stawianiem odseparowanych serwerów itp., tym razem chodzi jednak po prostu o tworzenie warstwy abstrakcji łatwej do oprogramowania, użytkowania i tę właśnie warstwę nazywamy maszyną wirtualną. Nieformalnie reasumując: system operacyjny ma za zadanie oferować to, co posiada, w przystępnej formie ;)

Rozważmy teraz takie pytanie: Czy program działający na mikrokontrolerze np. mikrofalówki, lodówki, czy pralki jest systemem operacyjnym? Odpowiedź na to pytanie (według podanej wyżej definicji) to: nie. Program ten jest zadany odgórnie, nie ma możliwości oprogramowywania go – nie posiada żadnej warstwy abstrakcji i o zasobach tutaj też trudno mówić. Z kolei, zastanówmy się nad takim telewizorem, który działa w oparciu o jądro Linux. Tu sprawa nie jest już taka prosta. W końcu wiadomo, że Linux to system operacyjny (puryści mogliby się doczepić do tego stwierdzenia.. ;)), tylko że ten system dla użytkownika końcowego jest całkowicie przezroczysty – nie ma on bezpośredniego dostępu do zasobów, szczególnej maszyny wirtualnej też tu nie widać. Zatem, czy patrząc na telewizor w kontekście pudełka,  w którego środku coś się dzieje i otrzymujemy obraz, należy mówić o systemie operacyjnym? Tak jak już mówiłem, z definicjami nie jest łatwo.

Na koniec

To tyle na pierwszy odcinek serii. W kolejnym odcinku zajmiemy się już konkretami, czyli własnościami architektury x86. Poniżej załączam listę stron z materiałami, które zdecydowanie będą się przydawać.

OSDev.org – bardzo aktywny serwis typu wiki, traktujący o tematyce programowania systemów operacyjnych. Polecam od niego zaczynać szukanie odpowiedzi na pojawiające się wątpliwości.

Bona Fide OS Developer – strona zawiera pokaźną ilość przydatnych tutoriali, niestety nie jest zbyt często uaktualniana

Operating System Resource Center – skarbnica wiedzy o wszelakich zasobach systemów operacyjnych. Panuje tam trochę bałaganu, nie mniej jednak, można tam znaleźć masę przydatnych informacji.

Intel® 64 and IA-32 Architectures Software Developer’s Manuals – darmowe (!) podręczniki Intela do architektury x86 (i x86-64), zawierające 2 grube tomy na temat programowania systemowego. Przystępnie napisane, zwięźle objaśniają subtelności architektoniczne. Da się tam chyba znaleźć odpowiedź na każde pytanie, choć tego nikt nie jest pewien, bo nikt nie dał rady ich przeczytać ;)

Into the Void – skrócony (jakby ten intelowski okazał się za długi, ciężko dostępny) opis instrukcji architektury x86

W porządku, to tyle. Do usłyszenia w następnej części!

Mój udział w konkursie „Daj się poznać”

Konkurs daj się poznać oficjalnie rozpoczęty! Na stronie uczestników aktualnie widnieją 24 osoby (w tym ja, a jakże!), co należy uznać za niemały sukces. W tej notce chciałbym po krótce wyjaśnić, co będzie można u mnie przeczytać/zobaczyć.

Co?

Moim projektem jest… system operacyjny. Pomysł na serię postów dotyczących osdevu jest dosyć leciwy, jednak brak czasu i motywacji spowodowały odwlekanie go w czasie. „Daj się poznać” natomiast ma być dla mnie motywacją, aby owa seria powstała. Chciałbym jednak podkreślić, że konkurs sam w sobie nie jest powodem powstania projektu i niezależnie od przebiegu „zawodów” seria będzie miała swoją kontynuację.

Po co?

Odpowiedź na pytanie jest bardzo prosta – aby się czegoś nauczyć. Zaczynając ten projekt nie mam zamiaru przewyższyć udziału rynkowego takich świetnych systemów jak Microsoft Windows, GNU/Linux czy Mac OS X. Inicjatywa ma być zabawą połączoną z całkiem poważnym „riserczem”.

Dla kogo?

Seria ta przeznaczona jest dla wszystkich, którzy zainteresowani są tym, jak działa komputer (a konkretniej model systemowy architektury x86) – w detalach! Część czytelników zapewne zechce skompilować i pobawić się kodem, inni pewnie przejrzą tylko omawiane aspekty – wszyscy czytelnicy jednak, mam nadzieję, czegoś ciekawego się dowiedzą.

Kiedy?

Seria postów na ten temat ruszy jak tylko wrócę z urlopu – czyli najprawdopodobniej na przełomie sierpnia i września :) Wszystkich, którzy są zainteresowani, już dzisiaj zachęcam do subskrypcji kanału RSS, gwarantuję, że nie pożałujecie :) Posty dotyczące projektu oznaczone będą tagiem osdev, dodatkowo te, biorące udział w konkursie tagiem daj się poznać.

Problemy?

Widzę jeden poważny problem – częstotliwość postów. Tak jak wspomniałem, osdev to poważny temat, który wymaga na bieżąco intensywnego doszkalania się – nie wiem, czy będę w stanie produkować pełnej jakości (a innych, niż dopracowane – nie chcę) posty dwa razy w tygodniu (szczególnie, że niektóre zagadnienia wymagają przyswojenia dwóch setek stron z manuali Intela ;)).  Opcją jest również od czasu do czasu post o używanych przeze mnie narzędziach – które również mogą się przydać innym. Jeśli jednak nie podołam „z normą” – trudno, obejdzie się bez nagród ;). Mam nadzieję, że konkurs przysporzy mi wiernych czytelników serii – i to jest dla mnie priorytetem.

Do usłyszenia na przełomie sierpnia i września i nie zapomnijcie o zasubskrybowaniu kanału!

Byłbym zapomniał – kodów źródłowych projektu szukajcie tutaj, na razie niestety, nic tam nie ma.

Konkurs „Daj się poznać”

Wydaje mi się, że środowisko polskich programistów jest naprawdę aktywne, jeśli chodzi o rozmaite wydarzenia, konferencje, inicjatywy czy konkursy. Widocznym problemem jest jednak brak lub mała widoczność projektów open source, które znacząco mogłyby podnieść jakość „sceny”. Naprzeciw temu (i nie tylko temu) zagadnieniu wyszedł Maciek Aniserowicz (ogromne wyrazy uznania!) ze swoim konkursem „Daj się poznać”. Zasady są bardzo proste – blogowanie przez minimum 10 tygodni wokoło projektu open source, którego samemu się tworzy. Autorzy najlepszych wpisów na swoich blogach zostaną nagrodzeni rewelacyjnymi i licznymi nagrodami po zakończeniu konkursu – 15 listopada. Start już 1 sierpnia, a więc nie zwlekajcie z rejestracją (ostateczny termin – 15 sierpnia)! :)

Od siebie dodam, że zamierzam wziąć udział w konkursie (ciekawe jak to będzie z regularnością moich wpisów, bo jak wiadomo, mam z tym problem, ale przy takiej motywacji.. ;>) z chyba dość nietypowym pomysłem, który zarazem będzie realizacją moich półrocznych planów. Nie będę wychodził przed szereg i więcej szczegółów na temat mojego projektu dopiero po oficjalnym rozpoczęciu :)

Blog Maćka

Strona konkursu