Drugi wykład z cyklu seminariów o systemach wbudowanych i FreeBSD
Koło Naukowe Telephoners działające przy Katedrze Telekomunikacji AGH w Krakowie, wspólnie z firmą Semihalf sp.j., zapraszają na drugi wykład dotyczący systemów wbudowanych i FreeBSD.
Na najbliższym wykładzie Rafał Jaworowski, współwłaściciel firmy Semihalf sp.j., przedstawi zagadnienia związane z zastosowaniem systemu operacyjnego FreeBSD w systemach wbudowanych. Omówiony zostanie szereg obszarów, od zagadnień związanych z niskopoziomowym wsparciem dla nowych architektur, poprzez mechanizmy wewnątrz jądra systemu, aż po konstrukcję sterowników do urządzeń. Szczegółowo przedstawione kwestie techniczne oparte są na rzeczywistych projektach uruchamiających system FreeBSD na układach firm Marvell oraz Freescale.
Wykład ma charakter otwarty. Każdy zainteresowany będzie mile widziany.
Miejsce: Sala wykładowa 201 (I piętro) w budynku D6, Katedra Telekomunikacji, Akademia Górniczo-Hutnicza im. Stanisława Staszica w Krakowie. Termin: Czwartek, 26.03.2009 o godzinie 18.30.
Licencja BSD jest na zasadzie od wszystkich dla "kogokolwiek". Licencja GPL jest od wszystkich dla wszystkich. Wspomniany tutaj "kogokolwiek" może wykorzystać coś tylko dla siebie, tylko dla konkretnego grona, a resztą olać, a GiePeeLowiec robi dla wszystkich i tylko dla wszystkich.
Tak to można wyjaśnić po kilku piwach, dla kogoś kto jest po kilku piwach. 😀 Reszta niech minusuje. 😀
GPLowiec może również wszystko to co BSDowiec, do puki nie będzie chciał dystrybuować swojego softu. Czyli możesz zmieniać do woli, ale jeśli chcesz sprzedać, albo dać to musisz ze źródłami.
A mają dość sporo do zmienienia, bo ficzerów mimo wszystko brakuje. Linux na tym rynku został już dość porządnie przetestowany, a poprawkami musisz się podzielić tylko w przypadku patchowania gotowego oprogramowania. Firmware'y i tak pozostają zamknięte, podaje się tylko patche na jądro i ewentualnie toolchain.
Innymi slowy, jesli mamy zamiar zrobic Kolejny Najtanszy Router Do Domu, Linux jest idealny. Jesli mamy zamiar zrobic jakis bardziej innowacyjny produkt, moze sie okazac, ze ograniczenia nakladane przez licencje GPL nam nie pasuja. Patrzac na stale rosnace zainteresowanie BSD w sektorze embedded, firm nalezacych to tej drugiej kategorii nie jest wcale tak malo.
Niespodzianka trasz: Linux idealnie sprawdza się też na dużo bardziej zaawansowanych urządzeniach za kilkanaście/kilkadziesiąt KPLN, takich jak kontrolery WLC, macierze albo switche FC. Potwierdzą to np. Cisco, IBM czy Brocade. Firmy, które swojego biznesu nie operają wyłączenie na pracy innych nie mają problemu z GPL i obiektywnie wybierają produkt po prostu lepszy i stabilniejszy, jakim jest Linux.
@Ole: Tylko tam, gdzie Linux nie robi niczego istotnego, na przyklad robi za przerosniety bootloader (Cisco) albo tam, gdzie nadzoruje tylko prace sprzetu (Brocade). Innymi slowy, Linux sprawdza sie w przypadku sprzetu wlasnie tych firm, ktore opieraja sie na pracy innych zamiast dopisac cos do systemu od siebie. Pewnym wyjatkiem jest tutaj IBM, ktory inwestuje calkiem sporo w kod w kernelu – ale w kod, ktory dla wszystkich innych firm jest bezuzyteczny, bo dotyczy sprzetu, ktory produkuje wylacznie IBM.
Te firmy natomiast, ktore _musza_ zrobic cos innowacyjnego w kernelu, wybieraja system nie tylko lepszy i stabilniejszy, ale takze bardziej wolny licencyjnie, czyli FreeBSD. Przykladem jest chociazby Juniper, NetApp czy Apple.
Linux w Cisco nie robi za bootloader tylko za RTOS. 😉
Co do Brocade – to czego więcej oczekujesz od kernela niż kontrolowanie pracy sprzętu? Ma obsługiwać stos IP? Obsługuje. Ma uruchamiać programy? Uruchamia. No to co jeszcze ma robić? Wykrzaczać się na USB? To tylko FreeBSD. 😉
Co do Apple/Juniper to powód wyboru był oczywisty: wziąć działający kod, zmodyfikować, nic nie dać od siebie, sprzedać z zyskiem. Z GPL tak się nie da.
@Ole: Nie, w Cisco Linux nie robi za RTOS. Pod Linuksem dziala IOS – jako proces – a Linux sluzy glownie uruchomieniu go. I robi rozne pomniejsze rzeczy w rodzaju systemu plikow.
Co do Apple i Junipera – tak sie sklada, ze obie firmy oddaly bardzo duzo FreeBSD. Z tym, ze na warunkach akceptowalnych z punktu widzenia ich strategii biznesowej – a tak z GPL sie nie da.
trasz: W Cisco Linux robi za RTOS. Jak nie wierzysz, rozbierz sobie obraz do kontrolera WLC. Poza tym już raz pytałem: czego oczekujesz od kernela, skoro system plików nazywasz "pomniejszą rzeczą"?
@Ole: W Cisco – i w tych duzych routerach, i w duzych Catalystach, numerow nie pomne, bo to nie moja branza – Linux robi rozne pomniejsze rzeczy, ktore z pewnym uproszczeniem mozna nazwac bootloaderem. Nie jest to w polowie tak istotne, jak rola Linuksa w routerach Linksysa, czy rola FreeBSD w routerach Junipera. W Cisco wszystko, co jest istotne – i wszystko, w co pakuje sie kase – robi IOS, chodzacy pod Linuksem jako proces. RTOS to tam byl kiedys, jak jeszcze uzywali QNX-a. Jak nie wierzysz… Coz, pogadaj z kims, kto pracuje w Cisco. ;-P
Inna sprawa, ze Cisco specjalnie szczesliwe z Linuksem nie jest. Ale aktualnie maja wieksze problemy, wiec wersji, w ktorej Linuksa zastapiono czyms innym, nie spodziewalbym sie wczesniej niz za dwa lata.
Pomijajac rzeczy dyskusyjne, w rodzaju lepszego zorganizowania kodu i samego projektu, dzieki czemu latwiej calosc ogarnac – licencja. W przypadku kodu na GPL musimy to, co zmienimy, rozdac za darmo calemu swiatu. Co nie jest fajne w dwoch przypadkach – jesli mamy zamiar wypuscic na rynek cos innowacyjnego, co musi dzialac w kernelu (vide Juniper, Nokia i pare innych firm produkujacych sprzet sieciowy bazujacy, czesto dosyc odlegle, na FreeBSD), i jesli potrzebujemy kawalka sprzetu, ktory objety jest NDA uniemozliwiajacym nam publikacje zrodel sterownika.
Oczywiśie masz rację, ale na szczęście producenci mają wybór na siłe nikt im tego Linuxa (GPL) nie wciska. Zwłaszcza, że w przypadku firm takich jak Juniper nie rozmawia się tu o tysiącach ale milionach dol. inwestycji. Pltaforma jest do tego wybierana dla całej gamy produktów nie dla jedengo modelu. Jak niedawno wspomniałeś w profesjnolnym sprzęcie jest używany VxWorks, Cisco używa swojego IOS, ich marka Linksys stoi na Linuksie. Dzięki czemu to routerów linksys można znaleźć oprogramowanie znacznie zwiększające jego możliwości (OpenWRT) powstało raczej bez poważnego uszczerbku dla producenta. BSD (według skanera nmap) jest powszechne w dlinkach.
Nawiasem mówiąc Linksys w wyniku użycia Linuksa został zmuszony do ujawnienia kodu źródłowego i dzięki temu powstały sterowniki wifi dla broadcoma.
@Tomasz Chiliński: W ogromnej wiekszosci wypadkow 'free' implikuje 'darmowy'. W przypadku GPL oprogramowanie mozna sprzedac tylko raz – bo potem klient dostaje prawo do rozpowszechniania go dalej za darmo.
Hmm, a jakoś Check Point'owi nie przeszkadza GPL.
I całkiem nieźle na tym zarabiają (SPLAT – SecurePlatform), na dodatek właśnie wykupili Nokię (tę część odpowiedzialną za bezpieczeństwo) i prawdopodobnie uśmiercą IPSO w najbliższym czasie zastepując ją SPLATem.
Polecam zobaczyć sobie pricelist.checkpoint.com 🙂
IPSO to jest właśnie basowane na BSD (bodajże FreeBSD) – tylko że od jakiegoś czasu sama Nokia nie wiedziała co z IPSO zrobić uśmiercić przejść na Linuxa, czy unowocześniać. A uzywała IPSO nie tylko w dla aplianców Check Pointowych, ale i dla całej masy innego specjalizowanego sprzętu sieciowego.
Powiedzmy lepiej wprost – każdy ma prawo wybrać sobie model biznesowy jaki mu pasuje:
BSD – nie ujawniamy naszych kodów konkurencji i często implementujemy koło od nowa.
GPL – ujawniamy nasze kody konkurencji i troche rzadziej implementujemy koło od nowa 🙂
Tak ja to niestety widzę jeśli chodzi o wszelkie wbudowane rzeczy.
Pozdrawiam 🙂
@Einaingahxu1hied: IPSO od bardzo dawna uzywalo kodu CheckPointa chodzacego pod systemem i sprzetem Nokii. Wykupienie jednego przez drugie bylo do przewidzenia.
A co do przyszlosci IPSO – pomysl w wolnej chwili, dlaczego od paru miesiecy Nokia znow inwestuje w rozwoj FreeBSD. 😉
Z tą lepszą organizacją kodu to jakaś kpina. Jak można twierdzić coś takiego, skoro dopiero jakieś pół roku temu FreeBSD zaczęło rezygnować z CVS i to na dodatek na rzecz SVN, równie niewygodnego do rozwoju tak wielkiego kodu.
Na dodatek dochodzi do takich kuriozalnych sytuacji, jak np. że nielubiany developer FreeBSD commituje swój kod do drzewa poprzez inną osobę, bo nikt mu nie chce dać dostępu r/w.
@Ole: Nie "zaczelo rezygnowac", tylko po prostu przemigrowalo. I odbylo sie to, wyobraz sobie, dosyc plynnie – ot, po prostu zaczeto uzywac SVN; cala historia z CVS zostala przekonwertowana do nowego repo.
SVN w rozwoju "tak wielkiego kodu" sprawdza sie dobrze. Duze commity – naprawde duze – potrafia chwile potrwac, ale ogolnie calosc sprawdza sie bez zarzutow. Problem z "nielubianymi developerami" tez wziales z sufitu – zasady sa takie, ze kod commituja osoby zaufane, tzw. commiterzy. Jesli kod pochodzi od osoby niezaufanej z jakiegos powodu, to musi przejsc przez zaufana.
> Otóż właśnie FreeBSD stosuje SVN dlatego, że projekt
> jest dobrze zorganizowany i w związku z tym scentralizowany
> SCM całkowicie wystarcza.
Chyba nie chcesz przez to powiedzieć, że ktoś kto używa rozproszonego systemu wersji, że ma bałagan? 😉 Scentralizowany SCM jest jednym z większych "pain in the ass" wielkich projektów z wieloma, niezależnymi developerami, tylko nie każdego stać na to, aby z niego wymigrować. Do tego przyznaje się nawet autor tekstu z powuższego URL:
"Why do you seem to be pushing subversion?
It's because I am. I think the whole hg/git thing is a distraction. We need something NOW. svn will work for us and gains us some huge benefits immediately.
"
Słowem: mogli przemigorwać na coś lepszego ale musieli ASAP wyjść z CVS, na zmianę organizacji pracy nie starczyło czasu/zapału/zasobów.
> Jeśli ktoś nie ma r/w to nie jest deweloperem. Po prostu.
No popatrz, a w Linuksie (OpenSolarisie, Firefoksie, GNOME, Dovcote, …) można bez r/w. Czyli wszędzie tam, gdzie używa się rozproszonych systemów kontroli wersji.
> na zmianę organizacji pracy nie starczyło czasu/zapału/zasobów.
Powstaje zasadnicze pytanie: a po co zmieniać organizację pracy która dobrze funkcjonuje? Wg. tej logiki, 10 lat temu Torvalds powinien był zmienić organizację pracy i przejść na CVS. Wiemy, że tego nie zrobił, tylko napisał sobie własny RCS odwzorowujący jego system pracy — i bardzo dobrze. FreeBSD stosowało organizację pracy opartą na CVS (później CVS+Perforce), więc naturalnym jest, że przemigrowali na SVN.
> No popatrz, a w Linuksie (OpenSolarisie, Firefoksie, GNOME, Dovcote, …) można bez r/w. Czyli wszędzie tam, gdzie używa się rozproszonych systemów kontroli wersji.
Serio? Tzn. jak postawię sobie własne drzewo git-a z kernelem Linuksa i zacznę w nim nanosić poprawki to stanę się deweloperem kernela? Owszem, w DRCS-ach wszystkie drzewa są równe. Ale drzewa z których robione są dystrybucyjne tarballe są równiejsze.
Mamy 2 systemy współpracy:
1. System klasyczny, stosowany w BSD i projektach komercyjnych, gdzie każdy deweloper może wprowadzać poprawki do drzewa dystrybucyjnego. Kryterium bycia deweloperem jest uprawnienie zapisu do repozytorium. W związku z tym muszą istnieć procedury regulujące zostawanie deweloperem. Scentralizowane RCS-y powstały właśnie do obsługi takiej sytuacji.
2. System linuksowy, gdzie maintainer drzewa dystrybucyjnego ogląda każdą łatę i decyduje czy włączyć ją czy nie. W tym systemie nie ma _formalnego_ kryterium bycia deweloperem: teoretycznie patche ludzi z wewnątrz i zewnątrz projektu są równo traktowane. (Podkreślam, teoretycznie — w praktyce maintainer preferuje łatki ludzi których już zna). DRCS-y powstały z uwagi na specyficzne wymagania w takiej sytuacji: potrzebny jest nie tyle system zarządzania kodem i historią zmian, co system zarządzania indywidualnymi łatkami.
Wbrew pozorom pierwszy system jest znacznie bardziej demokratyczny: wszystkie decyzje podejmowane są przez ogół deweloperów, a nie tylko przez jedną osobę.
To który system działa lepiej zależy tylko i wyłącznie od osoby lidera projektu, która determinuje stosowany sposób zarządzania.
@Ole: Umknela ci jedna, podstawowa kwestia. Dostep R/W maja _committerzy_, nie _developerzy_. Developowac mozesz bez tego; jedyne, czego nie bedziesz mogl zrobic, to zacommitowac tego wlasnorecznie do glownego drzewa. Wlasciwie to developowac bez tego _musisz_, bo bez developowania nie dostaniesz commit bita.
Porownujac z Linuksem sytuacja wyglada tak, ze w Linuksie committer jest jeden – Linus – a cala reszta nadsyla mu swoje zmiany, ktore on musi wciagnac. We FreeBSD natomiast committerow jest wiecej, a osoby nie bedace committerami musza wysylac im swoje zmiany. Paradoksalnie wiec, rozwoj FreeBSD jest bardziej rozproszony – a jednoczesnie bardziej zorganizowany.
A co do zalet jednego modelu nad drugim – nie zastanowilo cie, ze Linux rozwija sie w podobnym tempie jak FreeBSD, mimo ze naklady finansowe i ludzkie w jego rozwoj sa rzad wielkosci wieksze? To efekt przede wszystkim wlasnie chaotycznego modelu rozwoju. Modelu, w ktorym scentralizowany VCS nie zdalby egzaminu, wiec trzeba bylo wymyslec inny. Projekty, ktore nie maja problemu z chaotycznym rozwojem, nie potrzebuja VCS-a, ktorego glowna zaleta jest mozliwosc uzywania w projekcie bez sensownej organizacji.
Pitolenie. Mamy np. również trzeci system gdzie grono deweloperów spokojnie sobie tworzy kod a następnie jest on zatwierdzany (nierzadko per łatka) przez audytorów. Do takiego modelu (albo nawet z silniejszą kontrolą) przystosowany jest DVCS: Monotone. Audyt występuję w wielu większych projektach, nie tylko w stricte HI. I to nie tylko audyt bezpieczeństwa ale i audyt zmiany.
Można to wszystko (czyt. każdy z systemów) zawrzeć w scentralizowanym VCS, takim jak Subversion czy CVS. Albo w rozproszonym (i po prostu lepszym) takim jak Git czy Monotone. Możliwość podesłania łatki istnieje zawsze, w dowolnym systemie. Możliwość wyróżnienia oficjalnego repo takoż. Dorabiasz bzdurną ideologię.
Dodaj komentarz