Android: powrót do macierzy?

Android, co by o nim nie mówić, nie jest już projektem niszowym i znajduje swoje miejsce na rynku. W cieniu tego rozwoju zaczęły się toczyć rozmowy na temat zbliżenia odmiany Linuksa stosowanej w tej platformie do macierzystego projektu.

Aktualizacja: już wiadomo, że będzie 2 nowych deweloperów Androida do kontaktów z Linuksem, a także pojawiła się seria łatek, których brak blokował włączenie przynajmniej 75% kodu sterowników z Androida!

Gdyby Android nie stał się sercem kolejnych modeli współczesnych telefonów (już ponad 30) i czytników książek elektronicznych, zapewne nikt nie przejmowałby się odgałęzieniem Linuksa autorstwa Google. Chciałoby się jednak, żeby różnice między dwoma tak ważnymi liniami kodu były jak najmniejsze, a najlepiej żeby w ogóle ich nie było — i właśnie pojawia się na to szansa.

Chris DiBona (Google) studzi zapały: jego zdaniem ten proces zajmie lata, ale nie dlatego, że jest technicznie trudny, ponieważ firma stara się trzymać blisko linii doglądanej przez Torvaldsa. Problem raczej w niewdzięcznej roli, w jakiej znalazło się Google: po jednej stronie mają producentów urządzeń, którzy najczęściej skupieni są na doraźnym sukcesie, a z drugiej — deweloperów i zwolenników WiOO, których interesuje spójność projektu oraz to, żeby kod nadawał się do rozwijania przez długi czas i na wielu platformach.

Rozmowy na ten temat toczyły się na tegorocznym Linux Collaboration Summit w San Francisco.

żadnych reklam, sama wiedza.

Zarejestruj się na BEZPŁATNY NEWSLETTER i raz w tygodniu otrzymuj najważniejsze wiadmości
ze świata IT, nowych technologii i kryptowalut.

Bez reklam.

  1. Awatar mini
    mini

    Biedny Google..

  2. Awatar ufoludek
    ufoludek

    "Developerzy i zwolennicy WiOO" odwalają w tym wypadku niezłą WiOOchę. Z jednej strony jako główny plus WiOO podają to, że każdy może sobie kod wziąć, sforkować i robić z nim w zasadzie co chce, o ile udostępni źródła, ale jak Google dokładnie to zrobiło, to natychmiast "środowisko" zaczęło sdzlochać, że jak to tak można forkować bez ładowania dodatkowych zasobów w pomaganie "środowisku" z przerzucaniem tych zmian do
    głównej gałęzi.
    Drodzy "developerzy i zwolennicy", kod Androida jest dostępny na licencji GPL. Chceta, to bierta i merdżujta, ale od prób wymuszenia na Google'u dodatkowego wsparcia wara.

    No chyba że GPL = "forkować możesz wszystko, oprócz kernela".

    1. Awatar przemo_li
      przemo_li

      Forki kernela to norma wśród dystrybutorów, choć częściej są to mikro-forki (co jakiś czas wracają do wanilii), ale zawsze reperują kernel do stanu najnowszego.

      Tutaj się to powtarza. Problem w tym, że fork Google (i jego partnerów), może przerosnąć rozwój samego jądra :), ale bez wpływu na główną gałąź 🙁 dlatego Google musi utrzymywać "synchronizację", a devi głównej o nią zabiegać.

      1. Awatar Budyń
        Budyń

        Google nic nie musi.
        Natomiast jeżeli byłoby, jak piszesz, to by oznaczało że model rozwoju Linuksa się nie sprawdza… w sensie, że "many hands doing the light work" prowadzi do nikąd, a używalnego Unixa jest w stanie zrobić jedna, za to duża firma (Apple, Google…)

        1. Awatar aaa
          aaa

          Musi, ponieważ jeśli odejdzie za daleko, trudniej mu będzie wprowadzać poprawki, które pojawią się w głównej gałęzi.

        2. Awatar przemo_li
          przemo_li

          @Budyń Google nie rozwija samodzielnie jądra, robią to konkretni dystrybutorzy. Problem polega na tym, że jest to wąska działka, i tak jak Android nie ma wpływu na rozwój wirtualizacji tak główna gałąź może nie być innowacyjna na polu smartfonów.

          Model rozwoju kernela jest jak na razie najlepszy z istniejących pod względem liczby niepowiązanych firm zaangażowanych w rozwój.
          Dystrybutorzy Androida mogą się dostosować.

        3. Awatar kwant
          kwant

          @przemo_li – potwierdzeniem prawdziwości Twoich słów jest wspólna praca nad jądrem deweloperów RedHata, IBMa i Novela. Firmy dość duże, konkurujące ze sobą na wspólnym polu (rozwiązania serwerowe) a jednak rozwijają Linuxa wspólnie. Czyli da się – a jest to najtrudniejszy przypadek.

          Wprowadzony do Linuxa kod przez IBMa niewątpliwie pogorszy jego konkurencyjność w stosunku do RH i Novela. Mimo wszystko opłaca się to zrobić bo w zamian dostanie się ,,wkład'' od tysięcy innych deweloperów. To jest chyba najpiękniejsze w całym OpenSource.

          Sądzę, że na dłuższą metę mocne rozsynchronizowanie się Androida z Linuxem (w sensie jajek) może być problemem.

          Trzeba pamiętać, że Google używa Linuxa na swoich serwerach przetwarzających dane. W ciągu wielu lat istnienia dopracowali się swoich modyfikacji i jakoś nie widać, żeby je udostępniali. Nie muszą bo używają ich wewnętrzenie – nie sprzedają serwerów z ich softem tylko rezltaty jego działania. Troch szkoda, to gigantyczna firma z gigantycznym budżetem i kupą zdolnych ludzi – na pewno ich modyfikacje są wartościowe.

    2. Awatar Reddie
      Reddie

      ale od prób wymuszenia na Google’u dodatkowego wsparcia wara

      Ale prosić mogą?

      1. Awatar kocio
        kocio

        No, ufoludek ma strasznie mocny reflektor i rzeczywiście wszystko wygląda w ostrym świetle, choć tak oczywiście nie jest. Wyszło śmiesznie: DiBona nie ma z tym problemu (sam przecież mówi, że starają się minimalizować różnice – to w ich interesie), a on tu o wymuszaniu… Nie każda rozmowa to zaraz szantaż.

        A ma ktoś może informacje jak to poszło? LCS było w połowie miesiąca, więc pewnie są już jakieś wstępne ustalenia.

        1. Awatar kocio
          kocio

          Nie widzę nic niepokojącego, że masz takie zdanie, ale fiksowanie i generalizowanie wydaje mi się w ogóle kiepskim sposobem.

          Czy zafiksowałeś też swoje zdanie o producentach sprzętu np. po tym, jak któryś stworzył niezgodny z niczym interfejs? Bo to też jest problem dla nabywców i niektórzy czują się wkurzeni i lekceważeni – różnica tylko taka, że nie słowami.

          Dlatego nie polecam fiksowania, a już zwłaszcza jednostronnego.

          (Coś mi nie wyszło, ale to miała być odpowiedź do ufoludka.)

        2. Awatar ufoludek
          ufoludek

          W tej materii swoje zdanie o developerach i zwolennikach zafiksowałem po poście Grega K-H.
          W skrócie: ZOMG sforkowali nasz kod, więc teraz vendorzy mogą pisać drivery tylko pod Androida, więc to problem Google'a, żeby zrobić tak, że te drivery będą też pasować do mainline!

        3. Awatar ufoludek
          ufoludek

          Also: takich wypowiedzi było więcej, i bynajmniej nie były one w tonie prośby. Raczej żądanie w stylu "wprawdzie działacie zgodnie z GPL, ale powinniście oprócz GPLa dostosować się do kilku warunków, które wam niniejszym dorzucamy, bo jak nie, to jesteście fe".

        4. Awatar bies
          bies

          Dokładnie tak! Macie prawo do danego zachowania ale uznajemy je za niegrzeczne a nawet złe. To już kwestia G. czy chce nie być ,,evil''.

          Normalny lobbing, podobnie jest to załatwiane w przypadku dokumentacji sprzętu dla Linuksa i innych otwartych systemów.

        5. Awatar kocio
          kocio

          No właśnie – to tak samo jak z działaniami firm produkujących urządzenia z Androidem (i nie tylko): mają prawo robić różne chore rzeczy, ale uznajemy je za irytujące i ograniczające możliwości użytkowników. A jak się to nie podoba, to się stara, żeby do tego nie dochodziło. I tyle.

        6. Awatar ufoludek
          ufoludek

          Czyli przestrzeganie spisanych (mniej lub bardziej klarownie) reguł = bycie evil?
          Skoro zapisy GPL są niewystarczająca, to należałoby zmienić GPL, a nie dorzucać stosującej się do niej firmie dodatkowe wymagania już po fakcie.

        7. Awatar bies
          bies

          Rozumiem, że nie rozumiesz. Zapisy GPL są wystarczające (dla autorów Linuksa). Lobbing konsumencki czy społecznościowy nie dotyczy formalnej zgodności z licencją bo tego G. nikt nie odbiera. Dotyczy wizerunku (w oczach pewnej grupy).

          Fork bez chęci merge dla mnie jest evil, YMMV.

        8. Awatar me
          me

          i właśnie dlatego prawo jest tak przerośnięte, i nadal można je interpretować

        9. Awatar szarpaj
          szarpaj

          Przecież sam Google mówi, że chciałby się dokleić do mainline, bo teraz, o ile pamiętam wywiad (także z panem DiBona), to teraz to wygląda tak:
          1) biorą jakieś jajo
          2) paczują swomimi rzeczami
          3) po jakimś_czasie (~pół roku ztcp) biorą nowsze jajo
          4) portują pacze, dodają nowe
          5) wróc do punktu 3

          Gdyby byli zespawani z vanilla, byłoby im łatwiej, bo co jakiś_czas by nie musieli wszystkiego portować do nowszego jaja. Chociaż ten model/wywiad dotyczył akurat ich gałezi serwerowej, a nie Androida. Tak czy inaczej cały proces pewnie potrwa chwilę dłużej niż jeden commit spree.

        10. Awatar ufoludek
          ufoludek

          @szarpaj: Google mówi, że "proces zajmie lata", co równie dobrze można odczytać jako delikatne spławienie.

        11. Awatar szarpaj
          szarpaj

          W wywiadzie, jak wspomniałem, chodziło o część serwerową. Dokładniej to sieciową część (którą Google skutecznie testuje na swoich farmach serwerów). Tutaj raczej nie ma problemu z producentami sprzętu.

          Jak też wspomniałem, czepianie się braku współpracy i czepianie się czepiania się braku współpracy, też wydaje się nie na miejscu, skoro sam Google chciałby się zintegrować. Na dłuższą metę, pozostając przy swoim, będą musieli portować coraz więcej i więcej swoich rozwiązań lub przestać portować? I wtedy zrobią totalnego forka i będą sami rozwijać? Być może to część planu dominacji nad światem, kto wie. (;

        12. Awatar szarpaj
          szarpaj

          http://lwn.net/Articles/357658/

        13. Awatar Reddie
          Reddie

          @ufoludek: ale wcale nie trzeba. Skąd ten nawyk, by wszystko i wszystkich mierzyć swoją miarą?

        14. Awatar ufoludek
          ufoludek

          @Reddie: z doświadczenia? Jak firma mówi "jasne, super, tylko to potrwa lata" to znaczy, że nie ma zamiaru specjalnie nic w tym kierunku robić.

        15. Awatar Mikołaj
          Mikołaj

          Bycie not evil bardzo się Google opłaca (przy najmniej jak do tej pory). A brak współpracy w rozwoju jądra to również strata dla samego Google, które jak wiadomo powszechnie z niego korzysta. Więc to że developerzy przypominają o tym fakcie fimie która jak to firmy mają czasem menadżerów którzy rozumieją tylko zyski doraźne jest jak najbardziej na miejscu (wystarczy zastanowić się jaka filozofia przyświecała panu B.G gdy wydawał Vistę i jak się to dla niego skończyło). A i tak Google zrobi jak zechce, bo nikt nie zamierza zmuszać ich do niczego.

        16. Awatar blain
          blain

          No tak, bo każde przedsięwzięcie planowane na dłużej niż rok upada.
          To się okaże czy mają zamiar, na razie to wróżysz z fusów.

        17. Awatar ufoludek
          ufoludek

          @blain: spróbuj w wolnej chwili popracować nad rozróżnianiem "hurra! wprawdzie zajmie to kilka lat, ale zarobimy kupę kasy!" a "jasne, też byśmy chcieli być blisko main line'a, ale to zajmie kilka lat…".

        18. Awatar ufoludek
          ufoludek

          @Mikołaj: a w jaki dokładnie sposób brak współpracy w rozwoju jądra to strata dla Google? Cokolwiek by Google nie zrobił dostęp do źródeł main line'a i tak ma.
          Że musi sobie coś tam backportować? Ich wybór. Albo mogą sobie spokojnie portować wybrane poprawki (bo przecież nie cały development odbywający się na branchu Linusa jest im potrzebny), albo się męczyć z portowaniem swoich zmian, które nie są kompatybilne z tym, co się na nowych wersjach dzieje (mechanizmy synchronizacji?).

        19. Awatar Reddie
          Reddie

          @ufoludek: z twojego doświadczenia, jak rozumiem. Czyli znowu wracamy do punktu wyjścia: dlaczego mierzyć wszystko twoim doświadczeniem? : )

        20. Awatar ufoludek
          ufoludek

          @Reddie: A dlaczego nie? Możesz mu przeciwstawić swoje. Potem możemy się pobawić w mierzenie, kto ma większe 😉

          Bardziej serio: jeżeli masz jakieś fajne, możliwie obiektywne dane pozwalające na interpretację mglistych wypowiedzi firmy, stawiających słuchacza przed perspektywą kilkuletniego oczekiwania na wynik, to wal śmiało. Najlepiej w stylu "GUS podaje, że w 79% przypadków taka wypowiedź ze strony przedstawiciela firmy oznaczała, że rzeczona firma przeznaczyła 10M$ na opłacenie developerów, a z tego 63% merge'y zakończyło się sukcesem i projekty trzymają się blisko mainline'a".

        21. Awatar Reddie
          Reddie

          Kocio parę pięter niżej ma fajne, choć całkowicie subiektywne dane. Oczywiście możesz dowodzić że te wypowiedzi to zasłona dymna Google'a 😉

    3. Awatar Maciej Grela
      Maciej Grela

      Przeczytaj sobie zanim zaczniesz biadolić: http://lwn.net/Articles/383276/

      1. Awatar trasz
        trasz

        @Maciej Grela: Szkoda, ze to "wyjasnienie" jest w calosci oparte na argumentach jednej tylko strony. W dodatku ze strony Grega K-H, ktory wslawil sie jako autor bredni pt "Stable ABI nonsense".

        1. Awatar kocio
          kocio

          Rzeczywiście, nawet bardzo szkoda, ale przedstawiciele Google nie dotarli na to spotkanie, choć byli zaproszeni.

          W komentarzach z kolei odzywa się tylko DiBona, który już nie pierwszy raz zachowuje się cokolwiek arogancko (co jest niefajne, ale nie najważniejsze), a i tak niczego nie tłumaczy, tylko rzuca jakieś półsłówka (i to jest dopiero niedobrze).

          W ogóle ktoś nieźle podsumował postawę Google na rynku urządzeń wbudowanych porównując ich z Nokią:

          http://lwn.net/Articles/384021/

        2. Awatar Maciej Grela
          Maciej Grela

          @trasz: Post był skierowany do ufoludka, który widzi w tej sytuacji jakąś nieszczerość "deweloperów i zwolenników WiOO", natomiast po przeczytaniu przytoczonego artykułu widać, że G-KH wskazuje przykłady, jak elementy polityki Google:
          – przyczyniają się do duplikacji pracy (kod usb-gadget i Bluetooth)
          – utrudniają portowanie driverów (wakelocki)

          Jak pewnie zauważysz, są to powody techniczne dalekie od "domagania się większej uwagi" jak twierdzi ufoludek. Z drugiej strony argumenty padające ze strony Google są podobne do innych bolączek środowiska embedded opisanych np. tutaj:

          http://lwn.net/Articles/318611/

          Co do Twojej niechęci do "Stable API nonsense" – nie zbaczaj z tematu.

        3. Awatar ufoludek
          ufoludek

          @Maciej Grela: ależ nieszczerość jest. Stawia się określone warunki (GPL) + podaje forkowanie jako jeden z koronnych argumentów za OS, ale jak taki fork zaczyna odnosić sukces, to walimy w nutę "ZOMG ALE JAK TO?!?!?!?!!!111".
          Albo warunki są na początku i się ich trzymamy, albo ryzykujemy uznanie za [tu wstaw jakiś epitet, którym Twoim zdaniem obdarzam niniejszym "developerów i zwolenników"].

        4. Awatar kocio
          kocio

          Przydajesz nierealistycznie rozdęte znaczenie licencji. GNU GPL to przecież tylko fundament prowadzenia projektu WiOO, a nie gwarancja, że się uda, że będzie efektywny itp. Forki mogą być różne i mieć różne skutki. Poza tym węszysz awanturę tam, gdzie jej nie ma, stawiając Google jako biednego przedsiębiorcę, którego czepiają się bez sensu wredni twórcy.

          Otóż Google (i wiele innych firm) najwyraźniej w przypadku Androida nie chwyta, że WiOO to nie tylko licencja, ale też społeczność, zasady współpracy itp. To, że nie są spisane w formie umowy/licencji itp. nie znaczy, że do niczego nie służą. Przeciwnie – gdy już wiadomo podstawowe rzeczy, to dopiero zaczyna się formowanie projektu, jego związków z innymi projektami, cała dynamika forkowania, kanały komunikacji, systemy współpracy itp. To jest cała kultura pracy WiOO, która generalnie się sprawdza.

          W podtekście jeszcze słyszę, że ci czepialscy zazdroszczą sukcesu i chcą coś narzucić właścicielowi forka, który wie lepiej i nikt nie musi mu niczego uświadamiać. A tymczasem im też raczej zależy na sukcesie Androida, a nieraz nawet są użytkownikami tych urządzeń.

          W dodatku fork z Androida to wcale nie jest jeden, tylko gąszcz dziwnych wersji. Wątpię, żeby to pomagało Google. I tak nikt im nie może skutecznie niczego narzucić – jeśli nie zechcą, to to się nie poprawi – więc nie są takimi ofiarami, jak ich oświetlasz. Jeśli przedstawią argumenty, dlaczego tak jest i że to ma sens, to dyskusja będzie o tych argumentach, a na razie są argumenty dlaczego robią źle, a brak sensownej odpowiedzi.

          Wreszcie pytanie o prawa moralne do nacisków: jeśli można mieć oczekiwania wobec projektów społecznościowych, to dlaczego nie można ich mieć wobec firm? We współczesnym świecie ściana między firmą a ludźmi nie jest już tak szczelna. A skoro tak, to wreszcie lepiej słyszą to, co ludzie na zewnątrz myślą i czego chcą. Nikt rozsądny nie sprawdza, czy to klient, który zagłosował portfelem, czy potencjalny klient, czy ktoś inny. Po prostu się komunikuje. I to jest właśnie ta sytuacja.

        5. Awatar ufoludek
          ufoludek

          @kocio: Pliz, nie próbuj mi wmówić, że FLOSS oznacza radosną współpracę wszystkich ze wszystkimi i pomaganie sobie nawzajem przez konkurencyjne projekty 🙂
          Forki bez zamiaru merge'a jak najbardziej powstają i nikt o to kopii nie kruszy. Nie przypominam sobie bojów o to, żeby BMP merge'ować z powrotem do XMMS. Co więcej, jest ono przedstawiane jako siła FLOSS — bierz i zrób swoją wersję.

          Licencji przypisuję takie znaczenie, jakie moim zdaniem ma — określa zasady, na jakich można korzystać z kodu. Autorzy kodu powiedzieli "możesz z tym kodem robić to i to, a my będziemy zadowoleni". Firma biorąc kod opiera się na licenji. Jeżeli teraz, już po wzięciu kodu i włożeniu weń jakiejś tam pracy, zaczynają się pojawiać naciski w sprawie jakichś niepisanych reguł (do których sama społeczność się niespecjalnie stosuje) to znaczy, że społeczność nie potrafiła na początku jasno określić, na jakich zasadach udostępnia kod.
          Tę sytuację można próbować podciągnąć pod stosowanie się do prawa vs stosowanie się do prawa i bycie na dokładkę uprzejmym. Państwo na mnie nie naciska, żebym był uprzejmy, tylko żebym przestrzegał prawa. W przypadku FLOSS państwem (w znaczeniu prawodawcy, autora licencji) jest społeczność, więc jeśli ma jakieś oczekiwania, to niech se je wpisze w ustawę i już.

          Co do zazdrości, to i owszem. Dla mnie to jest zazdrość. Patrz post Grega. Chodzi o to, że drivery mogą powstawać tylko na Androida a mainline będzie musiał je portować, więc żeby mainline'owcy się nie musieli napracować należy ponaciskać Google, żeby odwalił brudną robotę.

          Moralnego prawa do nacisków społeczności FLOSS nie odbieram, ale nieco je ograniczam. Społeczność, która na naciski userów, żeby dodać ficzer A albo poprawić buga B często odpowiada "zrób se sam" ma w moich oczach nieco mniejsze prawo do domagania się, żeby coś zrobił ktoś inny.

        6. Awatar Maciej Grela
          Maciej Grela

          @trasz: W jakim sensie "gorzej" ? Jakies konkretne zagrozenia widzisz ?

        7. Awatar trasz
          trasz

          @Maciej Grela: Rzecz w tym, ze utrzymywanie synchronizacji z mainline prawdopodobnie skonczyloby sie jeszcze gorzej. W sensie, Google marnowaloby jeszcze wiecej czasu. Ale tego Greg K-H nie powie.

        8. Awatar kocio
          kocio

          @ufoludek: Nie wiem dlaczego wspominasz o radosnej współpracy, chyba mnie nie zrozumiałeś – przecież wyraźnie mówiłem, że licencja to tylko podstawa, a ustalenie konkretnych zasad to osobna robota. Samo się nie zrobi.

          Jeśli o tym się pamięta, to łatwo też zrozumieć, dlaczego społeczność od początku nie określiła wymagań. Teraz mam już pewność, że chcesz mieć wszystko na talerzu, a to tak nie działa, ten proces jest dynamiczny i elastyczny. Nie wiem jak chciałbyś osiągnąć te dwie cechy określając z góry na sztywno wszystko. Nie wiem też dlaczego wpływanie miałoby być gorszą metodą niż twardy nakaz lub zakaz. Dla mnie to mentalność urzędnicza – bałwochwalstwo wobec papierków zamiast komunikacji, argumentacji i negocjowania.

          Pisałem też już, że forki nie mają ustalonej wartości: mogą być oceniane jako pozytyw i jako strata. To bardzo zależy od kontekstu. Tu wszystko na razie wskazuje, że to wina zaniedbania, a nie zabieg mający pozytywne cele.

          W przytoczonym tekście na LWN można wyczytać, że wskutek bajzlu z forkiem Androida googlowi serwerowcy nie mogą łatwo skorzystać z jakiejś rzeczy (!), oraz że firmy zrzucają poprawki w postaci wielkich, nieczytelnych łatek, pokrywających się w zasadzie z kolejnymi wydaniami. Trudno zazdrościć takiego stanu, bo to jest merytorycznie kiepskie. Naprawienie tego da korzyść wszystkim, nawet nie widzę tu sprzecznych interesów, a łatwiej garstce inżynierów dostosować się do głównego źródła.

        9. Awatar Maciej Grela
          Maciej Grela

          @ufoludek:

          Ja myślę jednak, że kocio ma tutaj rację. Licencja jest jedynie mniej lub bardziej doskonałą kodyfikacją zasad "kultury opensource". Przykład, który podałeś z państwem i prawem jest bardziej trafiony, niż ci się wydaje. Pomiędzy zachowaniami, które są prawnie nakazywane a rzeczywistymi zachowaniami ludzi istnieje spory obszar "niepisanych" norm, które uważane są za społecznie przydatne z tego czy innego powodu. Przykładowo, prawo nie nakazuje ci opiekować się rodzicami na starość ale jednak jest to obowiązek, który najprawdopodobniej będziesz wypełniać.
          Podobnie, licencja jest "prawem" a wokół niej znajdują się różne konwencje stosowane w projektach open-source, zasady współpracy i komunikacji etc. One naprawdę zostały wypracowane przez lata aby jak najlepiej służyły rozwojowi projektów i utrzymały się dlatego, że *działają*. Walka z nimi nie jest potrzebna.

          Co do forków to oczywiście one powstają, czasem na dobre, czasem na gorsze. Ale ciężar forka kernela (lub np. xorg) jest trochę większy niż BMP zatem większy jest też opór materii. Zresztą trudno to nie jest tak, że Google "ogłosiło fork linuksa" oficjalnie tak, jak zwykle się to robi. Po prostu istnieje obawa, że oba drzewa zaczną się rozmijać.

          Co do zazdrości, driverów i portowania proponuję przyjrzeć się sprawie dokładniej – jest sobie przykładowo producent kontrolera wyświetlacza LCD. Czy producent tego układu ma być zmuszony do pisania drivera dwukrotnie (np. raz do zastosowania w telefonie na Androidzie i drugi raz do zastosowania w telefonie na Maemo) ? Zdaniem deweloperów jądra (i moim też) to bezsens. Parcie na ujednolicenie kodu/przerobienie mechanizmu wakelock/włączenie wakelocków do mainline/ jest dla mnie jak najbardziej rozsądnym posunięciem w celu utrzymania atrakcyjności platformy dla obecnych i przyszłych producentów telefonów. Po prostu świat nie kończy się na Google.

        10. Awatar trasz
          trasz

          @Maciej Grela:

          1. Regresje. Obecnie Google ma wlasnego brancha i wie, co do niego wchodzi i jakie moga byc konsekwencje. Uzywajac "waniliowego" kernela straciliby to.

          2. Bezsensowny code churn, wynikajacy m.in. z braku stabilnego API i ABI. Zyskow w praktyce nie ma z tego zadnych, a problemow jest masa, bo do zmian kodu wszyscy naokolo musza sie przystosowac. Utrzymujac wlasnego brancha mozna ograniczyc ten problem; w przypadku uzywania kernela "waniliowego" trzeba caly czas sie z tym babrac.

          3. "I gadaj tu z debilem" effect. W sensie, bezsensowne uzeranie sie z developerami kernela, ktorym wydaje sie, ze wiedza lepiej. To, ze w czesci przypadkow faktycznie wiedza lepiej, niewiele zmienia.

        11. Awatar kocio
          kocio

          Oj, chyba nie ma brancha, tylko różne branche, do których wlatują różne rzeczy, nie zsynchronizowane ze sobą nawzajem…

          Z kolejnej wypowiedzi DiBony (cały czas po trochu czytam dyskusję pod tekstem o ELC w LWN, długi jest) wynika, że to raczej kwestia priorytetów, i że czas na sprzątanie przyjdzie. Więc widać chcą to "stracić", i wcale im się nie dziwię.

          Oczywiście własny branch Androida nie będzie taki zły, jeśli będzie spójny i regularnie synchronizowany z Linuksem, np. co wersję jądra. Na razie jednak to wcale tak nie wygląda: mają muzeum (stare wersje), wielkie nieczytelne łatki i wiele osobnych gałęzi.

        12. Awatar ak47
          ak47

          1 A to jest jakaś różnica w regresji w branchu i w regresji w mainline?
          2. Łatanie dziurek + nowa funkcjonalność to faktycznie nic
          3. Można wiedzieć "lepiej" można też skorzystać z czyjegoś "know how"

        13. Awatar kocio
          kocio

          A teraz jak to jest w tej chwili (wedle opisu z LWN), a nie jak się wydaje, że jest:

          1. Jak się ma ileś niezsynchronizowanych gałęzi (wcale nie jedną…), gdzie łatki lądują co wydanie, a nie na bieżąco, to ryzyko regresji jest duże.

          2. To samo z łataniem dziurek – trzeba zgadywać który fragment co właściwie poprawia.

          3. Tu racja – własna gałąź jest bardzo praktyczna. Byle w miarę spójna i co jakiś czas (lub pojedynczymi łatkami na bieżąco) synchronizowana z główną linią. I o to wszystkim chodzi – bynajmniej nie o to, że muszą koniecznie korzystać z czystego jądra od Linusa. Byle dało się też to wdrażać w drugą stronę.

          Z wypowiedzi KH wynika, że problem polegał na tym, że ludzie od Androida się pojawili, a potem zniknęli, a potem znów to samo, choć już tym razem było "o łatkę od przyjęcia"! To już niezrozumiałe.

        14. Awatar ufoludek
          ufoludek

          @ak47:
          1. jak się ma brancha, na którego się przenosi z heada tylko wybrane zmiany, to ryzyko regresji jest znikome. W przeciwieństwie do jechania cały czas na headzie, na którym ileśset osób uprawia radosną twórczość.

          2. łatanie dziurek można sobie przenieść. Nowa funkcjonalność nie zawsze jest potrzebna, bo w końcu Android nie aspiruje do bycia uniwersalnym systemem na wszystkie platformy. Jak jakiś ficzer będzie potrzebny, to można go przenieść. Większość nowych ficzerów desktopowych czy serwerowych w telefonie potrzebna nie jest.

          3. mając swojego brancha można wiedzieć lepiej i nie trzeba się użerać z innymi, którym się wydaje, że wiedzą lepiej. Skorzystać z czyjegoś know how można, bo można podejrzeć, co robi w mainline.

        15. Awatar ak47
          ak47

          @ufoludek
          1. to żart?
          2. I widzisz masz synchronizacje, tylko że w drugą stronę, ktoś musi odwalić tą robotę. A im więcej będziesz miał różnic tym trudniej będzie się synchronizować.
          Misiu śniegowy, zapędzasz się, Android to system, a kernel jest linuksowy, więc nadal uniwersalny. Mimo że nowe drivery będą go mało dotyczyły to nowe funkcjonalnośći typu ip over usb czy modyfikacje stacku wifi już w znacznym stopniu.
          3. wierze że jesteś geniuszem który zjadł już zęby na niejednym projekcie i nigdy nie miałeś zagwozdki która okazała pokłosiem decyzji sprzed kilku miesięcy. Można robić wiele rzeczy ale rzeczowa rozmowa z kimś kto już robi to samo od kilku lat wcale nie jest głupim pomysłem.

        16. Awatar ufoludek
          ufoludek

          @ak47
          1. nie, nie żart. Kod, którego się nie zmienia, się nie psuje sam z siebie. Trasz pisał o regresjach związanych ze zmianami ludzi spoza Google.

          2. nie, nie zapędzam się. Kernel jest liuksowy, ale z modyfikacjami. I ma działać na pewnej określonej grupie urządzeń.

          3. nie, nie jestem geniuszem i miałem zagwózdkę nie raz. I co z tego? Jesteś w stanie skumać, że nie wszystkie zmiany wrzucane na mainline są dobre z punktu widzenia np losowo wybranego Google? Że czasem ci świetni i doświadczeni developerzy mają pomysły, które komuś innemu mogą bruździć?
          Przykład z życia to akurat nie kernel tylko glibc i opinia, niewątpliwie doświadczonego, świetnego i w ogóle, developera, że ARM i embedded to szajs i on nie ma zamiaru tego wspierać. Bo on wie lepiej a inni są głupi.
          O to w tym użeraniu z "wiedzącymi lepiej" chodzi.

        17. Awatar Maciej Grela
          Maciej Grela

          @trasz:

          1. Zgadzam się, zawsze od mainline mogą przyjść regresje. Niemniej działa to też w drugą stronę, jeżeli Google będzie bardzo zwlekać z mergowaniem kodu do mainline (a planują go mergować) to gdy to w końcu zrobią może się okazać, że to *ich* zmiany w core kernela narobią regresji w najmniej oczekiwanych miejscach. Ten kij ma dwa końce. Zresztą większość bugów i regresji w kernelu pojawia się w driverach, które ludzie od androida są w stanie ogarnąć, telefon komórkowy nie używa ich znowu tak wiele (driverów znaczy się).

          2. Tu się w zasadzie zgadzam, ale widać że masz jakąś fiksację na punkcie tego "Stable ABI nonsense" :).

          3. Trzeba do tego podejść rozsądnie – bo może to tobie się *wydaje*, że wiesz lepiej ? Bycie pracownikiem Google ani deweloperem Androida czy deweloperem mainline nie czyni z nikogo geniusza i warto mieć to na uwadze. Skupiać się na konkretach a nie uogólnieniach. Temat kontynuowany w odpowiedzi dla "ufoludka".

          @ufoludek:

          3. Dyskusje na temat słuszności czy nie jakiejś łatki czy rozwiązania toczą się cały czas i ludzie naprawdę są w stanie przyjąć krytykę, jeżeli jest ona uzasadniona. Google, gdyby brał udział w rozwoju mainline tak samo jak inni miałby dużo większe możliwości wpływu na jego kierunek niż odgradzając się murem. Przecież tam nikt nie chce z nimi walczyć.

          Piszesz, jakby "użeranie się" było regułą a tymczasem jest zjawiskiem marginesowym.

          A co do przykładu "z życia" związanego z maintainerem Glibc to istnieje np. biblioteka http://sourceware.org/newlib/ która powstała właśnie w celu zastąpienia opasłego glibc w zastosowaniach embedded.

        18. Awatar Maciej Grela
          Maciej Grela

          @ak47:

          1. Czasem błąd da się zauważyć przed zaaplikowaniem łatki jeżeli wyśle się ją na grupę mailingową odpowiedniego subsystemu.

          2. No i właśnie *dlatego* należy dążyć do współpracy w temacie kernela Androida a nie tworzyć problemy.

        19. Awatar ak47
          ak47

          1. A to błędy są odkrywane natychmiast po zaaplikowaniu łatki?
          2. Intel pracuje nad portem pod x86 więc ta twoja ograniczona grupa urzadzeń bardzo się powiększy. Ktoś inny (wydaje mi się) pracuje nad portem pod mipsa
          3. Akurat wypowiedzi programistów projektów sricte GNU uważam za folklor, więc wcale mnie to nie rusza. Pewnie jakby ktoś podsyłał łatki ten pan i tak je by zaaplikował mimo że uważa to co powiedział.

        20. Awatar ufoludek
          ufoludek

          @ak47:
          1. Jak ktoś łatki bierze od razu po ich wrzuceniu na mainline, to jest głupi i sam się prosi o kłopoty. Równie dobrze może po prostu jechać na mainline. Albo się z braniem zmian odczekuje, aż się trochę "uleżą", albo się je analizuje (bo można się bawić w analizowanie, jak do analizy jest kilka łat po kilkadziesiąt-kilkaset linii) pod kątem zwał. Crosschecking kodu to dość potężne narzędzie wykrywania błędów.

          2. Świetnie. To może Intel się pobawi w portowanie na mainline, skoro mu to potrzebne?

          3. Akurat ten konkretny gość (Drepper) by nie zaaplikował. Historia skończyła się powstaniem eglibca. Drepper to przypadek skrajny. Mniej skrajne przypadki są równie upierdliwe.

        21. Awatar szarpaj
          szarpaj

          Wydaje mi się, że DiBona wspominał tez o innych rzeczach, które tu są pomijane (wspominał o tym kocio (poniżej)). Po prostu w tej chwili Android rozwija się zbyt szybko żeby „Google community” (czyli piszący drivery producenci) miało się jeszcze dogrywać z mainline.

          Możliwe, że Google chciało uniknąć użerania się z developerami kernela (typu: wcięcia koniecznie na X spacji, nieczytelny kod, brak komentarzy, whatever, foo i bar) lub, po prostu, pracownikowi producenta łatwiej jest napisać kod do „forka” Google niż śledzić zmiany w mainline.

        22. Awatar Maciej Grela
          Maciej Grela

          @szarpai:

          Oczywiście, że narzekają na brak komentarzy i nieczytelny kod. Pamiętaj, że kod kernela pisany jest w celu używania go i utrzymywania przez kilka lat a nie wyrzucenia na śmietnik wówczas, gdy producent zadeklaruje "end-of-life" swojego produktu i przestanie się nim interesować zabierając się do produkcji nowego bardziej lanserskiego gadżetu.

          Jest to sztandarowa bolączka wszystkich deweloperów embedded – deweloperzy kernela naciskają na nich żeby tworzyli kod czytelny, poprawny i wykorzystujący optymalnie API które kernel dostarcza. Deweloperzy embedded są natomiast często zmuszeni do narzeźbienia czegokolwiek co działa w ich konkretnym (często *bardzo* wąskim) zastosowaniu lub do jak najszybszego przeportowania drivera z "łindołsa". Jednym z powstających przy tej okazji problemów jest tworzenie własnych implementacji różnych mechanizmów (np. blokad czy list) które w innych częściach kernela obsługiwane są przez współdzielone API. Oczywiście nie muszę chyba tłumaczyć, że takie podejścia nie są dla kernela korzystne w dłuższej perspektywie.

        23. Awatar ufoludek
          ufoludek

          @Maciej Grela: dodajmy jeszcze, że developerzy kernela te współdzielone API sobie od czasu do czasu radośnie zmieniają (ostatnio bodajże coś z konwersją kodowania znaków? z uzasadnieniem, że teraz się będą funkcje fajniej nazywać), co generuje dodatkową robotę dla biorących świeże źródła.

    4. Awatar 3ED
      3ED

      No jak google chce z każdą wersją kernela forkować go i pisywać bardzo dużo kodu czy po prostu mieć przestarzały kernel? Jeżeli to o te sterowniki chodzi to nikt nic nie musi ale chce bo taki google czerpie z tego korzyści.

      1. Awatar awoe
        awoe

        Zmiany w kernelu Windowsa są rzadsze niż w przypadku Linuxa, dla zwykłego użytkownika nie ważna jest super nowoczesność tylko sprawne działanie.
        Przestarzały kernel to nie problem, ja do tej pory używam ostatniej wersji z wsparciem dla oficjalnych sterowników ATI Catalyst na Radeony z serii 1xxx i tracę na tym tylko wsparcie dla systemu plików ext4.

  3. Awatar jellonek
    jellonek

    ból w tym, że firmy wypuszczające telefony nie bardzo rozumieją gpl (z reszta – google rowniez, skoro trzyma rowniez _zamknieta_ linie kodu, "uwalniajac" ja co jakis czas w wiekszych odslonach), przez co nie daje sie doprosic o zrodla modyfikacji kernela, dopasowujace go do danego sprzetu.
    piszac w skrocie – trzeba sie niezle omailowac (a i tak w sumie to niewiele daje) by dobrac sie do zrodel kernela, ktory sie ma zainstalowany w telefonie…

    1. Awatar krzabr
      krzabr

      Chyba tylko w przypadku devów bo większość osób wie tylko tyle że tam jest robocik od googla zamiast jabłka .

  4. Awatar krzabr
    krzabr

    Jest wiele gałęzi linuxa i jakoś nikt nie umiera z tego powodu , ba nawet wiele dystrybucji nie jest wogóle ze sobą kompatybilnych , problemem faktycznie tu jest to o czym ktoś wspomniał że linia Androida będzie zbyt szybko się rozwijała . I to jest zagrożeniem .

    Inna sprawa : Port androida na x86 jest już całkiem używalny a netbookach .
    Po lekkiej konfiguracji udało mi się go uruchomić na moim aspire one 150 , jedynie nie działa ifconfig do zmiany mac oraz dzwięk a tak to wszystko hula ;D

    http://www.androidx86.org/

  5. Awatar kocio
    kocio

    I jeszcze, żeby do reszty obalić idiotyczną aferę o "wrednych linuksiarzy kontra biedne, uczciwe Google":

    "Why did Google do this? Basically because they were so busy working on Android specifics that they were ignoring the big picture. Google open source engineering manager Chris DiBona said at the Linux Collaboration Summit that Google had to do a "better job" of contributing Android patches back to the Linux kernel. DiBona also said that Google would be hiring two new Android developers to work on better collaboration with the Linux kernel developers."

    [ http://blogs.computerworld.com/16000/android_and_… ]

    Zwłaszcza te dwie nowe osoby do komunikacji są nową i oczekiwaną informacją! Być może Google samo by na to w końcu wpadło, ale sądzę, że jednak był w tym wyraźny wpływ społeczności Linuksa. Dla jednych to nadmierne żądania, dla drugich – zwrócenie uwagi na problem. Ja się zaliczam do drugich.

    1. Awatar kocio
      kocio

      A, nie spodziewałem się, ale jak się doczyta dalej to jest jeszcze więcej dobrego! Z tego samego niusa:

      „he could draw my attention to a series of nine patches entitled „Suspend Blocker API (version 4)” from [Google developer] Arve Hjønnevåg.” (…) „I can certainly say that if this patch set is accepted, it will allow us to merge at least 75% of the android drivers that are currently out of tree because of API differences between the Android kernel and the vanilla one.”

      I nawet KH czuje się z tego powodu szczęśliwy – czyli jednak coś osiągnięto.

      1. Awatar ufoludek
        ufoludek

        Spoko, spoko. Poczekajmy aż te patche zostaną zaakceptowane. A potem zmerge'owane drivery.
        Zasadniczo wysłać patcha jest prosto — robimy diffa między naszym repozytem a mainline i wysyłamy. A że nieakceptowalny? Ooops…

        Tak, jestem cynikiem 🙂

        1. Awatar bies
          bies

          Nie Ufciu, jesteś trollem. Nie pamiętam już czy bsdzianym ale pasujesz z tym całym jadem do Linuksa.

          A G. nie będzie chciało być evil i zrobią tego merge'a, ot co.

        2. Awatar kocio
          kocio

          Ja nie bardzo rozumiem dlaczego, ale niektórzy kochają robić z igły widły i uparcie widzieć Czarną Dziurę jak na zdjęciu jest jakiś ciemny kłaczek… Ale wystarczy przeczytać jeszcze jedno zdanie z tekstu Vaughan-Nicholsa:

          "So far, it seems they've met with some easily addressable technical suggestions, but no major push back"

          żeby wiedzieć, że łatki są w dobrym stanie. Zabawne, jego blog nazywa się "Cyber Cynic" – ale jakoś trzyma się faktów, a nie dziwaczy na siłę.

        3. Awatar ufoludek
          ufoludek

          @bies: jedno nie wyklucza drugiego. Można być trollem i cynikiem jednocześnie. Bsdzianym tylko częściowo, bo Apple to nie jest całkiem BSD. Coby było zabawniej, przez ładnych parę (coś koło 7-8) lat byłem równie pro-WiOO jak Ty czy kocio, ale jakoś mi przeszło 🙂

          @kocio: gdyby wszyscy wszędzie widzieli to samo, to świat byłby nudny i nie byłoby o czym dyskutować.
          Co do nazwy bloga Vaughan-Nicholsa, to jest ona ździebeńko na wyrost. Cynikiem to on może jest jak pisze coś o softwch zamkniętych. Jak tylko wspomina coś o WiOO, to natychmiast wpada w hurra-optymizm.

        4. Awatar bies
          bies

          Aaaa jabłecznik… No to wszytko jasne. Teraz pasujesz wyśmienicie do charakterystyki.

        5. Awatar kocio
          kocio

          "gdyby wszyscy wszędzie widzieli to samo, to świat byłby nudny i nie byłoby o czym dyskutować"

          Jest jeszcze istotna kwestia jak się rozmawia o tych różnicach – czy się podrzuca fakty, czy dyskutuje wyłącznie o swoich przekonaniach, czy się roznieca emocje, czy myśli na chłodno itd.

          Ogólnie lubię podyskutować i nie zależy mi, żeby ktoś koniecznie przyjmował moje zdanie, ale uparte wałkowanie swoich wyobrażeń powoduje, że zwyczajnie czuję jak tracę czas. W takich warunkach to żadna satysfakcja, po prostu nudna orka.

        6. Awatar trasz
          trasz

          @kocio: Problem w tym, ze tutaj fakty podrzuca wlasnie twoj adwersarz. Przykladowo, zwraca ci uwage na fakt, iz proby merge'owania kodu Google'a byly wczesniej, i wiadomo, jak sie skonczyly. Ty natomiast powtarzasz to, co powiedzial ichni pijarowiec od Open Source. Nie ma sprawy, wierz sobie, ze wszystko bedzie tak, jak obiecuja. Ale nie nazywaj obietnic faktami.

        7. Awatar ufoludek
          ufoludek

          @kocio: sorry, ale większość powyższej dyskusje jest właśnie na temat przekonań. To, czy Google powinno coś zrobić czy nie, to tylko i wyłącznie przekonanie. No chyba, że potrafisz podać jakiś fakt na poparcie tego, że powinno. Odpowiedni punkt w licencji byłby takim faktem. Jego brak powoduje, że wszystko, co mówimy, to tylko nasze przekonania.

          Tam, gdzie się da, zazwyczaj fakty podaję. Niektórych faktów podać nie mogę lub są dla Was nieweryfikowalne. Gdybym w dyskusji o interpretacji zapowiedzi G. napisał "swoją opinię opieram na tym, że kiedyś przy jakimś projekcie firma X powiedziała nam coś podobnego i było to spławienie, bo nie mieli zamiaru tego robić", to potraktowałbyś to jako fakt?

          Fakt w tej dyskusji pojawił się dopiero w momencie, gdy wrzuciłeś informację o przekazaniu patcha i zatrudnieniu developerów. Wcześniej były tylko wypowiedzi i mgliste zapowiedzi.

        8. Awatar kocio
          kocio

          Faktem jest że odbyło się spotkanie, że istnieje taki problem, że DiBona zadeklarował mgliście o tych około 2 latach. Ktoś potem zaczął wątek jak to biedne Google i de facto to idiotyczne użalanie się nad nimi (bo nie wyglądało, żeby oni sami tak się postrzegali – po prostu głupio milczeli, dopóki nie dali znać, że też chcą to poprawić) pokutowało dalej. Na koniec dopiero udało mi się znaleźć podsumowanie co ustalono i to kolejny fakt. Realizacja, odwołanie albo przeciągający się brak wykonania to będzie kolejny fakt.

          Przepraszam, ale to, że kiedyś firma X coś obiecała i to była ściema, zupełnie niczego nie wnosi, bo firma Y z kolei obiecała i zrobiła. Pewnym wskaźnikiem mogłoby być co Google do tej pory robiło, ale na tym rynku zachowują się nieco inaczej.

          Ale się cieszę, że najwyżej się znudziłem, ale nie znalazłem komentarzy obrażających do wycięcia. Zawsze lepsza rozmowa jałowa niż agresywna i jałowa. =}

          Dobra, dla mnie EOT.

        9. Awatar ufoludek
          ufoludek

          Generalnie podpisuję się pod EOT, jeno jedna uwaga:

          Przepraszam, ale to, że kiedyś firma X coś obiecała i to była ściema, zupełnie niczego nie wnosi, bo firma Y z kolei obiecała i zrobiła.

          Wrong. Wnosi tyle, że takie jest moje dotychczasowe doświadczenie, więc na tej podstawie wysuwam przypuszczenia odnośnie przyszłości. Ktoś (Ty z firmą Y) może wysunąć doświadczenie i związane z tym przewidywania zgoła przeciwne.
          Obiektywnych danych statystycznych brak, więc każdy z nas może się co najwyżej podpierać własnym doświadczeniem, i to właśnie zrobiłem.

  6. Awatar kocio
    kocio

    Fajny artykuł o kulisach rozwoju Androida:

    http://www.visionmobile.com/blog/2010/04/is-andro…

    1. Awatar ufoludek
      ufoludek

      Artykuł zaiste ciekawy. Ładnie demitologizuje androidową "otwartość".

      1. Awatar kocio
        kocio

        No właśnie to jest w tym najlepsze, że pokazuje to na konkretach, a nie na zgadywankach (w tym, tak samo jak Vaughan-Nichols, bije na głowę twoje komentarze – można się czegoś z tego dowiedzieć).

        To pozwala sobie wyobrazić, jaką rolę pełni Google w promowaniu otwartych rozwiązań w środowisku, które dotąd żyło w totalnych lochach. Oczywiście to wciąż daleko od standardów FSF (które w pełni podzielam), ale doceniam tę powolną zmianę – wolę tak, niż wcale.

  7. Awatar mic
    mic

    Cały Linux. Zrobili ledwo 30 telefonów z Androidem i już nie mogą połapać się w tym burdelu? Dziwię się dlaczego firmy zainteresowane Open Source nie "wezmą na warsztat" któregoś z BSD? Idealna licencja dla softu w którym można poprawić co trzeba i nie przejmować się krzykaczami i oszołomami w stylu Stallmana. Apple korzysta z kodu BSD i jakoś dobrze na tym wychodzi.

    1. Awatar kocio
      kocio

      Muszę cię zmartwić – z *BSD, Solarisem, Haiku, Syllable, ReactOS-em… czy czymkolwiek innym na wolnych licencjach byłoby dokładnie to samo, bo ten bajzel nie wynika z natury Linuksa, tylko z obecnej natury rynku telefonów.

      Na pocieszenie dodam, że wcześniej było (i nadal często jest) jeszcze gorzej, bo tu jest mniej więcej to samo, tylko z dewiacjami, zafiksowaniem na starszej wersji itp., a tak to w ogóle każdy sobie dłubał kod praktycznie jednorazowego użytku.

      1. Awatar trasz
        trasz

        @kocio: Nie do konca. Problem z Linuksem jest to, ze zachodzi w nim bardzo wiele bezsensownych zmian utrudniajacych merge'owanie. Inne systemy nie maja tego problemu, bo developerzy mysla zanim napisza.

        1. Awatar kocio
          kocio

          Pomijam prostackie uproszczenie (można odnieść wrażenie, że Linux to jakaś enklawa, gdzie nie myślą), ale Google o tym nie wiedział jak wybierał jądro do Androida?

        2. Awatar trasz
          trasz

          @kocio: Obserwujac rozwoj Linuksa rzeczywiscie, mozna odniesc takie wrazenie. Google obchodzi ten problem uzywajac wlasnego brancha. A wybrali Linuksa chociazby dlatego, ze mozna latwo znalezc ludzi, ktorzy maja o nim jako takie pojecie, albo dlatego, ze w momencie podejmowania decyzji wsparcie dla architektury ARM bylo w innych otwartych systemach takie sobie.

        3. Awatar Maciej Grela
          Maciej Grela

          @trasz: Myślę po prostu, że FreeBSD nie wspiera(ł) wystarczającej ilości urządzeń występujących w zastosowaniach embedded (np. odpowiednik podsystemu MTD w Linuksie). Nie wiem też, jak wygląda wsparcie dla suspendu i zarządzania energią.

      2. Awatar mic
        mic

        Linux to jądro plus dodatki. Nie ma czegoś takiego jak system bazowy, więc zawsze będzie bajzel. FreeBSD jest systemem kompletnym do którego później możesz doinstalować co chcesz. No i mam wrażenie, że zmiany wprowadzane są po dokładnym przemyśleniu. Jak jest z Linuksem to wszyscy niestety wiemy: "Koko dżambo i do przodu!" 😉

        1. Awatar norbert_ramzes
          norbert_ramzes

          @mic równie dobrze mogę skopiować twój komentarz i zamienić miejscami FreeBSD na Linux i odwrotnie – kto będzie miał wtedy rację?

          Poczytaj co to LSB.

  8. Awatar mic
    mic

    @norbert_ramzes
    A która dystrybucja kieruje się wytycznymi LSB? Na moje to chyba żadna tak w 100%. A jeśli nie w 100% to robi się bajzel i każdy sobie rzepkę skrobie.
    P.S. No to skopiuj mój komentarz i nanieś swoje poprawki. Sam jestem ciekawy jaki wyjdzie z tego potworek 😉

Dodaj komentarz

Twój adres e-mail nie zostanie opublikowany. Wymagane pola są oznaczone *