Názory k článku Softwarová sklizeň (3. 6. 2009)

pan suchy urobte nieco s tou infantilnou upravou vasej inak urcite skvelej podobizne

harvie to je uplne v poriadku, tvoje vnimanie vtipna a nudna zodpoveda viac menej tvojmu veku

Teda já nevim, ale když jsem ji viděl, vzpomněl jsem si (bůhví proč) na DOOM :-D

prave ze to ma fakt styl.. dokonce i ala doom jak uz nekdo zminil vyse i kdyz predtim by me to teda nenapadlo ;}}

screen to umi

už jsem na to přišel:

1 ;( harvie@harvie-ntb ~ $ screen -wipe
There is a screen on:
9548.pts-10.harvie-ntb (Attached)
1 Socket in /tmp/screens/S-harvie.
1 ;( harvie@harvie-ntb ~ $ screen -S 9548.pts-10.harvie-ntb -X hardcopy
 

pokud tedy například chci, aby screen každou sekundu dělal shoty vsech oken v aktualnim adresari (to je ten, ve kterem byl spusten, pokud nebylo urceno jinak), můžu v něm pustit tenhle BASHovej příkaz:

while true; do screen -S $PPID -X hardcopy; sleep 1; done &

pak můžu třeba pustit rtorrent. barvičky tam nejsou, takže můžu soubor klidně pomocí tagu pre zobrazit na webu.

/dev/vcsaN je i s barvami. Ale oboji je jen pro konzoli, pseudoterminaly asi ani dumpnout nejdou.

na screenshotování tty doporučuji fbgrab, který umí rovnou do png

Když jsou tak odhodláni používat dynamické knihovny a zakazují statické, tak by mě zajímalo, kdo kontroluje, že ty knihovny mezi jednotlivými vydáními Fedory (a mezi Fedorou a jinými distribucemi) nezměnily ABI. Nikdo? – tak ať se pak komunita nediví, že pro ostatní vývojáře je těžké dělat programy pro Linux.

co je todle za stek? je to nejaky vtip patrici k poruse osobnosti?

To je k blbinke…

Já mám na myslí právě tu situaci, kdy software pro Linux dělá (nebo chce dělat) někdo jiný – např. někdo chce udělat hru pro Linux a nemá zájem na tom, aby ta hra byla v nějaké distribuci, prostě chce, aby se to dalo na jakýkoli Linux instalovat a pustit.

Základní knihovny (libc, gtk) mezi distribucemi kompatibilní jsou, ale všechny knihovny zdaleka ne. Takhle mi třeba v Debianu přestalo fungovat gpm – po upgradu Debiana na Lenny to instalovalo novou dynamickou knihovnu libgpm, která byla nekompatibilní s tou starou, programy z distribuce to upgradovalo taky (takže ty chodily), ale programy, co jsem si zkompiloval sám po upgradu fungovat přestaly.

Co jsem měl na mysli je to, že když linuxová komunita kňourá, že firmy málo nedělají software pro Linux (hry, profesionální programy typu photoshop, apod.), tak by se jim to právě měla snažit ulehčit, a nevyrábět takováto pravidla (to s vynucením, že všechny knihovny musí být dynamické), která vedou k tomu, že se programy instalované mimo distribuci se v budoucích verzích distribuce rozbíjejí.

Pokud nemá zájem dávat to do nějaké distribuce, tak si ten balíček samozřejmě může udělat jak chce. A dávno to tak všichni dělají. A knihovny většinou neřeší vůbec a kompilují staticky.

„tak si ten balíček samozřejmě může udělat jak chce.“

A jak? Udělat balíček, který by šel instalovat na libovolnou distribuci je nedosažitelný sen… :-( Asi tak .tar.gz zbývá.

„A knihovny většinou neřeší vůbec a kompilují staticky.“

Ne všecko jde kompilovat staticky, třeba ovladače grafických karet si instalují vlastní opengl, tak by ho asi nebylo dobré staticky kompilovat.

Navíc rozhraní mezi knihovnami a systémem se taky mění. Zde je příklad, jak přibalená knihovna vede k pádu a knihovna z distribuce nikoli: http://forum.ubuntu.cz/index.php?…

Takže kdyby SDL bylo slinkováno staticky, tak by to ten uživatel nemohl rozchodit vůbec, takhle se mu to aspoň podařilo po dotazu v diskuzi.

Nejsem expert na debian, fyzicky mi tu bezi jen jeden, ale debian ma tu peknou vlastnost, ze nekompatibilni verze teze knihovny se odlisuji jiz v nazvu. Konkretne po upgradu etch->lenny mam naistalovane tyto knihovny:

libgpm2 obsahujici libgpm.so.2

libgpmg1 obsahujici libgpm.so.1.19.6 a simlink libgpm.so.1

(Ne, fakt netusim, proc je tam to „g“ nevic)

Jasně, že osobně jsem s tím neměl problém si ty programy překompilovat (a i bych si dokázal instalovat starší verzi gpm, kdyby byla potřeba kvůli binárnímu programu). Ale pro prostého uživatele to být probém může, že upgraduje distribuci a nechodí mu programy.

Taky pridam svuj postesk – Linux je pro nas jedna z podoporovanych platforem a je docela veda mit jednu binarku spustitelnou na vsech distribucich…

Podobne story je s instalaci.

Nejedna se o open source projekt.

A cim za to platite – tim, ze udrzujete API/ABI xx let – a to jenom proto, ze chcete schovat zdrojaky patentovane one-cliku a podobne chytrych kusu kodu. Pro Linux uvolnite zdrojak a on uz to nejaky dobrodej za vas zabali, kdyz to bude vubec nekomu stat za tu namahu :).

„pritom by stacilo vymyslet zpusob, kterym se predaji verze systemovych knihoven a cesty k nim uz zkompilovane binarce.“

Cesty nepotřebuješ předávat (v binárce totiž většinou nejsou, hledá je linker). A předávání verzí ti nepomůže, protože když je do toho programu zakompilované jedno ABI, tak ti nic nepomůže, ten program s novou verzí prostě chodit nebude.

Základní problém je v tom, že programátor udělá knihovnu s funkcí třeba int moje_funkce(int a, int b, char *c);

za půl roku ho napadne, že by ten jeho program mohl mít ještě nějakou novou cool funkci a změní to na: int moje_funkce(int a, int b, char *c, char *d);

• a program kompilovaný a dynamicky linkovaný vůči té staré knihovně ti s novou knihovnou začne padat (dotyčná knihovna v „d“ dostane náhodný ukazatel). Kdyby ta knihovna byla staticky linkovaná, tak tento problém nevznikne.

Většina vývojářů knihoven si na tuto situaci dává pozor a nedělá ji. Ale ne všichni. A když mají distribuce takové podmínky, že „všecko musí být linkováno dynamicky, statické knihovny se dokonce v distribuci nesmí ani vyskytovat“, tak pak není snadné udělat binárku co chodí na více distribucích.

Správně by distribuce měla rozdělit knihovny na ty, co mají stabilní rozhraní (a ty dodávat jako dynamické), a na ty, co nemají (dodávat jako statické).

DeviceKit urcite D-Bus nenahradi, je to jedna z pevnych zavislosti (plus eggdbus, ktery je planovany merge primo do glib). DeviceKit je maly demon, ktery prave pres dbus komunikuje se svymi moduly (dk-disks, dk-power). Nad nimi je postavena vrstva C knihoven (napr. gnome-disk-utility), ktere se svymi protejsky (dk-disks) komunikuje opet pres dbus. Samotny DeviceKit demon je uz na sklonku sveho zivota, z architekturnich duvodu bude mergnut do udev-extras, rozsireny o dalsi funkce (s tim souvisi take libudev, ktery se timto stane pro nektere aplikace obsolete).