🚀 go-pugleaf

On 2011-04-19, Radosław Gancarz <N0Spam_radekg@hell.pl> wrote:
> Andrzej Rosa <bakters@yahoo.com> wrote:
>> >> Twórców kernela _Linuksa_ nie obchodzi przenośność kodu?  To nawet kiedyś
>> >> było prawdą.  Tak w okolicach wersji 0.1, o ile dobrze pamiętam.
>> > A próbowałeś kiedyś kompilować jakieś sterowniki spoza tych, które są
>> > w kernelu? 
>> Owszem.  Co ciekawe, te same sterowniki działały na x86_32 i x86_64,
>
> Ta sama binarka?

Ten sam kod.  Binarnie muszą być niezgodne, bo to przecież inna
architektura.

>> a na Windows to są dwa różne sterowniki.
>
> Ale jesteś w stanie stwierdzić,ze były kompilowane z różnych źródeł?

Opóźnienie w wydaniu sugeruje, że to inny kod.  

>> > Co jakiś czas przestają się kompilować bo developerzy
>> > postanowili, że znowu coś zmienią a osoba która ten sterownik rozwijała
>> > zaspała/wyjechała pracować do UK/kupiła inny sprzęt i po zabawie.
>> 
>> To kwestia stabilnego ABI dla modułów kernela, nie przenośności kodu.
>
> O, to API od ABI też nie odróżniasz...

Nadal nijak się to ma do przenośności kodu.  

>> ABI stabilne nie jest i nie będzie, za to kod jest przenośny.  Bardzo.
>
> API też nie jest stabilne, więc zdarza się, że kod nie daje się przenieść 
> pomiędzy wersjami kernela.

Można zrobić we własnym zakresie.  Tzn wystarczy wybrać sobie
którąkolwiek wersję kernela i wydawać sterowniki na nią.  Jakoś nikt się
do tego nie pali.

[...]
>> Dystrybuuje je potem za pomocą własnych menadżerów, robi
>> artwork, selekcję, wstępną konfigurację, utrzymuje stronę, forum i
>> pewnie parę innych rzeczy. 
>
> Znaczy poza własnym PM-em nie robią nic, czego nie robiłyby inne
> dystrybucje bazujące na innych dystrybucjach... 

No i?  Mieli pomysł na dystrybucję, to zrobili dystrybucję.   

>> Mimo to paru ludzi na krzyż sobie z tym
>> radziło (nie wiem jak jest teraz, trochę się rozwinęli).
>
> Więcej: http://www.sabayon.org/pages/show/id/62

Trzeba by kiedyś przetestować, bo jak się Ubuntu wygłupi, wartło by
ludzi przeflancować na coś utrzymywalnego.  

>> > Błąd w założeniach - sprawdź sobie za co płacisz RH, kupując RHEL.
>> 
>> Wcale nie błąd.  Płacisz może za support, ale bez przewagi jakości RHEL
>> nad konkurencją renoma RH by mocno ucierpiała.
>
> Każdy może wspierać RHEL (czy, w wersji light, CentOS)...

A mimo to ludzie płacą RH, między innymi dlatego, że RH demonstruje know
how na przykładzie RHEL.  

>> > A może zapomniałeś lin-propagandę z czasów, gdy Linux i OSS było modne
>> > i firmy miały żyć z supportu tego bałaganu? 
>> 
>> No i żyją.
>
> Tak sobie, vide SuSE ćośtam, obecnie Novell (przejęty przez Attachmate).

Właśnie obecnie to juz nie Novell, tylko niezależny biznes.  A
przynajmniej tak ma być.  BTW - VMWare chciało SuSE kupić.  Podobno
negocjacje rozbiły się o cenę, bo Novell za dużo chciał.  Jakby z SuSE
miało być tak marnie, sprzedaliby ich za bezcen, nie?

[...]
>> Im lepsza jakość softu, im mniej problemów, tym więcej kontraktów można
>> obsłużyć tą samą obsadą.  Im lepsza jakość, tym wyższa renoma, która
>> znowu wpływa na liczbę i wartość kontraktów.
>
> Wszyscy mają z grubsza ten sam soft, modulo ewentualne dodatki CS
> i odpały ideolo.

Z grubsza, to i Fedora ma ten sam soft co RHEL. 

>> Więc nie, nie opłaca się psuć OSS w celu zwiększenia popytu na support.
>
> Nie rozumiesz. Nie "psucie OSS" (zakładam, że w obu przypadkach autor 
> dostaje mniej więcej tyle samo patchy od użytkowników) tylko utrzymanie
> rozdrobnienia dystrybucji i "distro lock-in" (dla nietrywialnych przypadków
> przejście z jednej dystrybucji na drugą wymaga jednak więcej zabawy niż 
> upgrade do kolejnej wersji).

Tak, z tym się zgodzę.  Tyle że nie mam zamiaru narzekać na jedyny
działający model biznesowy w tej kategorii.  Zauważ, że oprócz tego typu
dystrybucji masz wyłącznie tworzone małymi nakładami dystrybucje
community, których wkład w rozwój oprogramowania jest o rząd wielkości
mniejszy niż RH czy SuSE.  

Bez dochodów nie ma nakładów.  A ja jednak chce używać coraz lepszego
softu.

>> > Znaczy licencja nie pozwalała Sunowi/Oracle i ich licencjonobiorcom wypuścić 
>> > nie-GPL-owej implementacji VM Javy, która zostałaby zoptymalizowana tak, żeby 
>> > była energooszczędna? Coś się gubisz.
>> 
>> Nic się nie gubię.  Google chciało system otwarty, zamknięty za drogo by
>> ich kosztował.  Otwarta implementacja Javy ME zawiera powyższy haczyk.
>> Dlatego Google zdecydował się na clean room.
>
> ... co jakby nijak ma się do energooszczędności ale doceniam chęć
> zdryfowania.

To Ty starasz się zamieszać, MSZ zupełnie świadomie.  

Ale zakładając, że może i nie, to Sun nieprzypadkowo wybrał taką
politykę licencyjną.  Mogli wybrać dowolną, ale zrobili właśnie tak.
Google musiał sobie z tym poradzić.

>> > A mimo to dajesz roota aplikacjom połatanym takimi łatami?
>> I mam 50% szans na trojana, bo albo będzie, albo go nie będzie?
>
> Znaczy jednak dajesz i masz nadzieję, że nie zrobią Ci z systemu jesieni
> Średniowiecza.

BTW - w Web of Trust wierzysz, czy też go postmodernistycznie
dekonstruujesz?
   
>> > Może wymienisz 3 najważniejsze?
>> 
>> Gry są duże.  OSS lepiej sobie radzi z małymi projektami.
>
> Chyba, że są małe. Na róznych stronach można znaleźć masę gier casual
> itp. malutkich rzeczy, czasem całkiem fajnych. Praktycznie wszystko we
> Flashu.

W HTML5 też można znaleźć coraz więcej.  

>> Gier się nie używa.  W gry się gra, raz, może dwa razy, po czym się je
>> zapomina.  OSS lepiej sobie radzi z projektami użytkowymi.
>
> Biblioteki do tworzenia gier? Też nie ma szału a to niby produkt klasy
> "pisane przez nerdów dla nerdów", więc powinno się udać...

To może jeszcze się udać, szczególnie w przypadku jakichś małych
producentów.  Niektóre gry otwarły źródła silników, zachowując prawa do
oprawy graficznej.  Zależy jak na tym wyjdą, albo się to bardziej
upowszechnić.

[...]
>> > Konsekwencja KISS - skoro takie prostackie są wystarczające to po co je
>> > komplikować?
>> No właśnie się nie opłaca, przynajmniej autorom. 
>
> Zatem "Im lepsza jakość softu, im mniej problemów, tym więcej kontraktów 
> można obsłużyć tą samą obsadą.  Im lepsza jakość, tym wyższa renoma, która
> znowu wpływa na liczbę i wartość kontraktów." to nieprawda?

Jakich kontraktów?  Fire and forget.

>> Za to doszlifowanie
>> *jednego* programu do instalacji czegokolwiek to zupełnie inna ekonomia.
>
> Od pewnego czasu w Windows jest *jedno* *systemowe* narzędzie do 
> instalacji oprogramowania, nazywa się "Windows Installer". Instalatory
> firm trzecich zazwyczaj używają go jako backendu. 

I do czegoś się nadaje, choćby do w miarę czystego odinstalowania softu.
Lepsze niż nic.

-- 
Andrzej Rosa
Working Gentoo flavor:  http://www.funtoo.org
Maintained by Daniel Robbins.