Na co ta 'rychlost', uponahlanost...

Miroslav Prymek m.prymek at gmail.com
Mon Mar 5 07:36:12 CET 2012


05.03.12 01:23 Dan Lukes napsal(a):
> On 03/04/12 23:18, Miroslav Prymek:
> >A mimochodem, jestli si to treba kazdy desaty spravce resi pomoci vlastni
> >repository, je otazka, jestli by ta celkova vynalozena energie nestacila na ten
> >redhati zpusob
> 
> Ja si proste nedovedu predstavit, ze nekdo, kdo nezna program, do
> kteryho se hrabe, ani ho sam intenzivne nepouziva se v nem dokaze
> hraba (a nebo ho otestovat) tak, ze vysledek je spolehlivy

Stejnou argumentaci bys mohl pouzit pro dokazani teze, ze zady program nejde
portovat z Linuxu na *BSD.

> A proc to takhle nedela Redhat ? Nemuze. Sam to na te strance rika.
> Jde o klientelu, ktera bude mit cast aplikaci v binarni forme, ktere
> proste rekompilovat nebude mozne.

No vzdyt ja jsem psal, ze by to IMHO vyrazne pomohlo pro rozsireni
FBSD v komercni sfere. Tam je stabilni ABI IMHO docela podstatna zalezitost.

Mimochodem, jaky pristup maji v tehle veci komercni Unixy? Mate
nekdo zkusenosti?

> Takze jim nezbyva nez se pokouset o "udrzeni ABI za kazdou cenu"
> jakkoli je to mene spolehlive a podstatne narocnejsi na zdroje nez
> prosta rekompilace vsech aplikaci, coz pripadne zmeny v ABI, pokud
> by snad nejake byly, spolehlive vyresi.

Stabilni ABI je jenom jeden benefit*. Dalsi benefit je udrzeni stabilnejsiho
(->predvidatelnejsiho) chovani systemu jako celku. Nove verze nekterych
softu se proste chovaji radikalne jinak nez verze stare.

Kdyz mas odladene prostredi s nejakou verzi Samby a vis, ze ti s ni
v tehle konfiguraci funguji vsechny stovky windows desktopu se vsemi
tremi aktualne podporovanymi verzemi Windows, tak posledni, co ches,
je povysovat verzi kvuli nejakymu hloupymu buffer overflow, ktery jde
opravit jednoradkovym patchem...

A porty maji bohuzel tu blbou vlastnost, ze povysit verzi samby "musis"
(je to standardni zpusob reseni) i kdyz je ten jednoradkovy bug v nejake
prihlouple knihovne typu libiconv, na ktere Samba zavisi.

...takze pak neni divu, ze do takove situace komercni subjekt radeji
nasadi RHEL/Centos, kdyz uz mermomoci chce jit do OSS a ne pouzit
rovnou WS.

Abysme si rozumeli, ja filosofii portu ("sw tretich stran je zodpovednostitretich stran")
rozumim a nezpochybnuju. Je to jasna a cista politika, jenom je proste v nekterych
situacich dost neprakticka. A podle me by se s tim neco delat dalo,
naklady nevidim zas tak tragicky jako ty.

* btw, proc se teda udrzuje stabilni ABI u major verzi FBSD, kdyz to nema cenu?


> 
> Ale nesnazim se te presvedcit, ze to mas vzdat, nebo ze to je
> nesmysl. Jen ti nabizim mozne vysvetleni proc to o cem mluvis jeste
> nevzniklo a proc si myslim, ze to spis nevznikne. Ale muzu se plest
> - nebylo by to poprvy ani naposled.
> 

Tak ja predevsim nemam co vzdavat, protoze takovy projekt neprovozuju a 
ani se nechystam ho zakladat, na to jsem opravdu malej pan :) Jen mi
je lito, ze jeste nevznikl, a myslim si (v tom se zase mozna pletu ja),
ze by to mohlo hodne lidi k zajmu o FBSD privest.

M.


More information about the Users-l mailing list