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

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

v tom pripade je to v poradku i u tveho veku… ehm 150?

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 ;}}

a je možné nějak udělat čistě textový screenshot? například pokud mi běží nějaká aplikace (at uz ncurses, nebo normální), tak bych rád získal textový soubor, ve kterém bude jen obsah okna terminálu (samozřejmě je možné logovat veškerý výstup programu, ale to je poměrně dost neúsporné, zvlášť u ncurses aplikací)

screen to umi

no o screen mi vicemene jde, ale ten umi myslim jenom log. hledal sem v manualu i na webu a nasel jsem jenom zpusob, jak ukladat veskery vystup do souboru. ja bych ale potreboval jednorazove dumpnout vybranej screen tak, abych moh vysledek ukazat treba na webu…

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.

takže celej skript bude vypadat asi takhle:

#!/bin/sh
cd /srv/http/downloads
screen -U bash -c ‚while true; do screen -S $PPID -X hardcopy; sleep 30; done & rtorrent‘
 

k tomuhle screenu se pak můžu kdykoli připojit a přidávat tam torrenty, na webu pak můžu sledovat postup (doporučuji pomoci php přidat tag pre, v hlavičce nadeklarovat kodovani a „zaheslovat“).

No tady je pokrocilejsi verze: automaticky stahovani torrentu ve screenu s webovym monitorem…

http://aur.archlinux.org/…-screen.bash http://aur.archlinux.org/packages.php?…

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

0 ;) harvie@harvie-ntb ~ $ setterm -dump 1 /dev/vcsa1 nelze načíst 1 ;( harvie@harvie-ntb ~ $ ls /dev/vcsa1 ls: nelze přistoupit k /dev/vcsa1: Adresář nebo soubor neexistuje

sudo cat /dev/vcc/1

ale vystup je nejak rozm*danej

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.

"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á. 

Autopackager ( http://www.autopackage.org/ )? Loki instalator ( http://icculus.org/loki_setup/ )? Install Jammer? ( http://www.installjammer.com/ )?

Možností jsou – používají se – nevidím problém,…

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 :).

Jeden člověkoden je dost podhodnocená představa – jestli ten program prodáváš, tak ho taky musíš testovat a to bude podstatně víc než člověkoden. Nezapomeň, že i když to někde nebude chodit třeba kvůli tomu, že dotyčná distribuce má bug v kompilátoru, stejně vina za to bude přisuzována tobě jako vývojáři toho programu.

ja bych zustal u toho, ze spousta vyvojaru se chova jako banda linejch, egocentrickejch a neprispusobivejch hovad, ktery se v zivote nedohodnou ani na velikosti fontu (a uz vubec ne na moznosti si velikost vybrat).

v linuxu chybi jednotny system instalace a nikdo se na nem v zivote nedohodne. pritom by stacilo vymyslet zpusob, kterym se predaji verze systemovych knihoven a cesty k nim uz zkompilovane binarce. take by bylo vhodne udelat system, ktery by umoznil z jednoho binarniho balicku instalovat stejne binarky na ruzna mista (podle zvyklosti distribuce).

o co, ze za 50 let se nic nezmeni? vsadim svy nejoblibenejsi bo­ty.

„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é).

no tak pokud jde o ty prenositelny binarky, tak sem vzdycky myslel, ze staci pustit gcc s argumentem -static a prakticky vsechny knihovny se do binarky nalinkuji natvrdo. existuji prece programy (napr sash – standalone shell), ktery funguje i bez glibc a je tedy zavisly jenom na kernelu (kde neni problem s kompatibilitou).

Nejak tomu nerozumim :-(

Co vlastne chcete? Protlacit ten svuj program do [vsech] distribuci nebo ho dodavat extra? Pokud extra, co vam brani se z vysoka vykaslat na pravidla distribuce? A pokud ho chcete protlacit do distribuci, tak holt musite prijmout jejich podminky …

BTW: Dovoluji si silne pochybovat, ze by v nejake distribuci meli extremni zajem o closed source program – pokud se tedy nejedna o ovladac k nejakemu zelezu …

„nemyslim, ze existuje mezi lidma co delaji distribude poptavka po podpore binarek chodici na vice distribucich bez rebuildu.“

Existuje poptávka, lidi např. hodně fňukají, že se pro Linux nedělají hry nebo specializované profesionální programy. V těchto případech vývojář musí vyrobit binárku, co chodí na více distribucích bez rebuildu.

„takova knihovna ma byt opravena“

To je Sysifofská práce: tři špatné knihovny opravíš a další tři nové špatné se ti do distribuce dostanou. Tento proces nikdy neskončí. Existence nekompatibilních knihovnen se nezbavíš, můžeš se zbavit leda důsledků, a to např. tím, že nespolehlivé knihovny linkuješ staticky, že je dáš do speciálního adresáře /usr/lib/only-for-fedora-9 a zajistíš, že se s nimi nebude linkovat nic jiného než programy z distribuce „Fedora 9“ nebo že ty knihovny budeš přibalovat rovnou ke každému programu. A když ty zmiňované „Guidelines“ všechna tato řešení zakazují, tak pak máme takovou situaci, že binárka zkompilovaná na jedné distribuci nechodí na jiných distribucích.

„moznost verzovani ABI, SONAME apod.“

Což vede leda k tomu, že místo pádu v případě nekompatibilních rozhraní se ti program nespustí – je to lepší než segfault, ale podstatu problému to neřeší.

„Holt vynecháš rychle se měnící distribuce (Fedora) a budeš podporovat jenom ty dlouhodobé (RHEL/Centos, Debian, Ubuntu LTS)“

RHEL instalované mám, a že by to bylo nějak víc kompatibilní než ostatní distribuce, bych netvrdil.

Příklad: chtěl jsem instalovat Wine. V neoficiálním repozitáři pro RHEL je jen verze 1.0.1. Takže BFU může skončit u této verze a novou si tam nenainstaluje, protože balíček neexistuje.

Já jsem se rozhodl kompilovat. S plnou podporou všech možností se to stejně nezkompilovalo, protože autoři Wine mají novější verze knihoven (např. gnutls) než jsou v RHEL. Nějak se to nakonec zkompilovalo (bez hal, šifrování, scanneru, gphoto a nevím čeho ještě; tvrdilo to, že s OpenGL) a 3D grafika nefungovala stejně. Po několikadenním zkoumání a doinstalaci více -devel balíčků a nové kompilaci 3D fungovalo (který balíček tomu pomohl opravdu nevím, protože výstup ./configure byl v obou případech stejný).

A co má dělat BFU, co neumí kompilovat, když chce jeden nový program, třeba to Wine? Smazat RHEL a nainstalovat si tam novou Fedoru nebo Ubuntu, pro které nový balíček s Wine existuje? – jenže tím si tam zavede spoustu dalších bugů v kernelu i v userspace (a napíše na spoustu internetových fór, jak ten Linux padá) a po roce ztratí na svou distribuci bezpečnostní updaty.

„Sorry, ale todle je blbost. Udelas SW, ale uz nemas cas/penize udelat balicek pro distribuce?“

Když si vezmeš, kolik jich je, a že nová verze té samé distribuce nepouští binárky pro starou verzi – pak ano, je to problém. Programy se buď distribuují v .tar.gz, nebo v .rpm, které není pro tu distribuci, kterou mám, takže je třeba ho ručně rozbalit (takhle jsem instaloval třeba Intel C

• pro mě to problém není si to rozbalit a změnit ve skriptech

cesty, ale prostý BFU takhle nic nenainstaluje).

Proč se ty distribuce nemůžou domluvit na společném formátu balíčku a na seznamu knihoven, které vývojář může používat (a všechny distribuce pak garantují, že dodají knihovnu binárně kompatibilní s knihovnami z toho seznamu)?

Já u svých programů balíčky pro distribuce taky nedělám. Kdyby existoval jeden formát balíčku, tak bych dělal.

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).