Dotaz: Proměnná PATH

[DWD]

Proměnná PATH se nastavuje v souboru /etc/profile. Měl by tam být řádek podobný tomuto:

PATH="/cesta:/cesta:/cesta"

Přitom tam žádný takový řádek nemám. Můj soubor /etc/profile vypadá tak:

# /etc/profile -*- Mode: shell-script -*- 
# (c) MandrakeSoft, Chmouel Boudjnah <chmouel@mandrakesoft.com>

loginsh=1

if [ "$UID" -ge 500 ] && ! echo ${PATH} |grep -q /usr/games ; then
    PATH=$PATH:/usr/games
fi

umask 022

USER=`id -un`
LOGNAME=$USER
MAIL="/var/spool/mail/$USER"
HISTCONTROL=ignoredups
HOSTNAME=`/bin/hostname`
HISTSIZE=1000

if [ -z "$INPUTRC" -a ! -f "$HOME/.inputrc" ]; then
    INPUTRC=/etc/inputrc
fi

# some old programs still use it (eg: "man"), and it is also
# required for level1 compliance for LI18NUX2000
NLSPATH=/usr/share/locale/%l/%N

export PATH PS1 USER LOGNAME MAIL HOSTNAME INPUTRC NLSPATH
export HISTCONTROL HISTSIZE 

for i in /etc/profile.d/*.sh ; do
	if [ -r $i ]; then
		. $i
	fi
done

unset i

Trochu divný soubor. Vůbec tam takový podboný řádek není. Co je to za pořádek? A když do toho souboru budu někdy potřebovat podobný řádek přidat, ani nevím, kam. Kam ho připsat?

Když jsem zadal do Konzole příkaz echo $PATH, přesto se mi nějaké cesty vypsaly:

/usr/bin:/bin:/usr/local/bin:/usr/X11R6/bin/:/usr/games:/usr/lib/qt3//bin:/home/david/bin:/usr/lib/qt3//bin

Teď by mě zajímalo, kde na ně přišel, když ve výše uvedeném souboru je pendrek. Dále nemůžu pochopit, co v tady tom výpise dělají dvojité lomítka. Mají tam být snad cesty oddělené dvojtečkama a v žádné cestě by se neměly psát dvě lomítka hned za sebou.

Odpovědi

[Begleiter]

for i in /etc/profile.d/*.sh ; do
	if [ -r $i ]; then
		. $i
	fi
done

Tento kód je pro tebe nejklíčovější. Znamená to vložení všech čitelných zdrojových souborů z adresáře /etc/profile.d/ odpovídajících masce *.sh.

Tzn. že proměnná PATH se bude nastavovat v některém z nich. Pomůže např. program grep.

[DWD]

Ale kompletní řádek PATH="adresáře oddělené dvojtečkama" není ani v jednom tom souboru. Kam mám připsat, když budu chtít do proměnné PATH něco přidat? Například teď bych potřeboval do proměnné PATH přidat aktuální adresář tečku. A nevím kam, protože ani v jednom souboru není ten řádek, ve kterém by byly všechny ty pathy obsažené pohromadě. Všechno je tam rozhazané jak salát. Každý kousek v jiném souboru. To je nepořádek. Přitom v Linuxu je obvyklé, že všechny proměnné pathy jsou v řádku PATH="adresáře oddělené dvojtečkama", který je v jednom souboru.

Nebo když se například bude někde doporučovat něco podobného jako Do souboru /etc/profile si přidejte řádek PATH="/bin:/sbin:/usr/bin:/usr/sbin:/usr/local/bin:/usr/local/sbin:/usr/games:/usr/bin/X11", nebo něco podobného, tak ani nebudu vědět, kam do toho souboru ho připsat. Kam patří?

[Begleiter]

When bash is invoked as an interactive login shell, or as a non-interactive shell with the --login option, it first reads and executes commands from the file /etc/profile, if that file exists. After reading that file, it looks for ~/.bash_profile, ~/.bash_login, and ~/.profile, in that order, and reads and executes commands from the first one that exists and is readable.

When a login shell exits, bash reads and executes commands from the file ~/.bash_logout, if it exists.

When an interactive shell that is not a login shell is started, bash reads and executes commands from ~/.bashrc, if that file exists. The --rcfile file option will force bash to read and execute commands from file instead of ~/.bashrc.

Dovolil jsem si ocitovat manuálovou stránku k Bashi.

Klíčové konf. soubory jsou tedy ~/.bashrc a ~/.bash_profile

[DWD]

Klíčové konf. soubory jsou tedy ~/.bashrc a ~/.bash_profile

Tam taky nemám žádný řádek PATH="cesty oddělené dvojtečkama", kde by byl kompletní seznam pathů. A když ho tam dopíšu, nic se neděje.

Já jsem to chtěl kvůli tomu, abych systém v případě potřeby mohl přinutit, kde má hledat spustitelné soubory a kde má spuštěný program hledat doplňující soubory například pluginy - hlavně pokud jsou ty pluginy jinde, než v systémovém adresáři. Všude se doporučuje Upravte řádek PATH="/něco:/něco" v souboru /etc/profile připsáním cesty... ale já tam nic připsat nemůžu, protože tam žádný takový řádek nemám, ve kterém by byly shrnuté všechny pathy. Dokonce ani v souborech /etc/profile.d/*.sh, ani v ~/.bashrc a ~/.bash_profile.

[Begleiter]

Smiluju se nad vámi a poradím

Nakonec souboru ~/.bashrc přidejte následující:

PATH="${PATH}:.:/moje/programy"

Vysvětlení: '.' zastupuje aktuální adresář (tak jste to chtěl). /moje/programy je další vámi přidaný adresář.

[Begleiter]

PATH="${PATH}:.:/moje/programy"
export PATH

Bez export PATH by to asi nefungovalo. Omlouvám se.

[Michal Kubeček]

Přidávat tečku do cesty je hodně špatný nápad.

[moira]

Dvě lomítka v cestě ničemu nevadí. Snadno se to stane, když v nějakém skriptu spojuješ dvě cesty, přičemž jedna lomítkem končí a druhá začíná.

[DWD]

Tak jsem to udělal. Do souboru ~/.bashc jsem připsal: PATH="${PATH}:.:./plug-ins" Potom jsem otevřel adresář, ve kterém mám nakompilovaný Audacity, mám ho nakompilovaný v adresáři /home/david/kompilace/audacity135/audacity-src-1.3.5-beta, tam mám spustitelný soubor audacity a ve stejném adresáři mám i podadresář plug-ins, ve kterém mám nyquistové pluginy. Když jsem spustil Audacity poklepáním na ten spustitelný soubor, spustím ten program, ale pod efektama se mi ty nyquistové pluginy neobjevují, program je stále nenačítá. Přitom vím, že ty pluginy jsou funkční, protože když jsem je předtím měl v systémovém adresáři, tak je Audacity uměl najít a daly se používat. Takže nevím, jakou dělám chybu. Dokonce jsem ten program spouštěl až po úpravě toho bashrcu a přesto se ty pluginy nenačítají.

[DWD]

Zdá se, že jsem na problém přišel: Při spouštění Audacity nestačí na spustitelný soubor jenom poklepat, ale musím to celé dělat pomocí Konzole: Nejdříve se přesunout do adresáře, ve kterém je ten spustitelný soubor, potom zadat ./audacity Program se spustí a efektů už je konečně více.

[DWD]

Teď jsem si něco vyzkoušel: Smazal jsem z ~/.bashc ten připsaný řádek

PATH="${PATH}:.:./plug-ins"

a funguje to pořád stejně. Podle toho vidím, že tam vůbec takový řádek nemusím připisovat, ani nic podobného, ani jinak zasahovat do proměnné PATH. Tak jsem přišel na to, jak to funguje: Na tom, jak mám nastavené proměnné PATH to vůbec nezáleží. Prostě záleží jenom na tom, jakým způsobem ten Audacity, který mám kompilovaný v home, spouštím: Pokud ho spouštím poklepem na spustitelný soubor, program se sice spustí, ale pluginy ze složky plug-ins, která je vedle spustitelného souboru, se pod efekty neobjeví. Když ten program ale spustím z Konzole, např cd /cesta/ke/slozce/se/spustsouborem a pak ./audacity, tak se všechny tam ty pluginy pod efekty objeví. Takže je důležitý jenom způsob spouštění, a ne zásah do proměnné PATH.

[Michal Kubeček]

To by byl hodně nepodložený závěr. Na hodnotě PATH záleží, ale problém je v tom, kde ji Audacity vezme. Když spustíte Audacity z interaktivního shellu, zdědí hodnotu proměnné PATH od něj a bude to ta, kterou jste si upravil v ~/.bashrc. Zatímco když ho spustíte "poklepem" (strašný výraz), zdědí proměnnou PATH opět od svého rodiče, ale tím je v tomto případě window manager. Takže si zkuste projít konfiguraci svého grafického prostředí, kde se tam dá nastavit environment spouštěných programů.

[DWD]

Když spustíte Audacity z interaktivního shellu, zdědí hodnotu proměnné PATH od něj a bude to ta, kterou jste si upravil v ~/.bashrc. V tom případě nevím, jak z toho mohl získat cestu ./plug-ins , když v ~/.bashrc už nic takového nemám a nemám tam už ani aktuální adresář tečku. V ~/.bashrc mám:

# .bashrc

# User specific aliases and functions

# Source global definitions
if [ -f /etc/bashrc ]; then
	. /etc/bashrc
fi

[Michal Kubeček]

Tak jste ji třeba nastavil někde jinde, těch includovaných souborů je víc než jen ~/.bashrc

[DWD]

Do jiných souborů jsem nic nepsal. Potom zbývá jenom ta možnost, že už to tam nastavené bylo jako výchozí.

[Begleiter]

Zakopaný pes je, že do proměnné PATH přidáváte relativní cestu (adresáře). ./plug-ins je třeba nahradit absolutní cestou, tedy cestou začínající '/'.

A hlavně nezapomeňte proměnnou PATH exportovat (export PATH).

[DWD]

Přidat do PATHu místo relativní cesty absolutní cestu. Taky by to šlo, ale to potom má hodně nevýhod: Budu muset pro každý spustitelný soubor přidávat novou cestu do PATHu, místo, aby stačila jedna pro všechny. Nebudu moct složku se spustitelným souborem a se všim, co k němu patří, přesunovat jinam, kam chci, už se k tomu budu muset chovat, jako by to bylo přibité. Taky nebudu moct nadřezené adresáře přejmenovávat. Ikdyž na druhou stranu, ani při použití relativních cest nejsem úplně bez omezení.

Mrzí mě, že to není tak jednoduché, jak jsem si představoval. Aby byl spustitelný program schopný načíst a najít různé doplňky, musím přizpůsobovat nějaké PATHy a navíc ani tak to pravděpodobně nebude ono. Naproti tomu si vezměme chování HTML dokumentů. Z toho bychom si měli vzít příklad. HTML dokumenty se chovají výborně, narozdíl od programů. HTML dokument můžu například umístit do nějakého adresáře, v tom adresáři můžu mít všechny doplňující soubory k tomu HTML souboru, například obrázky a jiné věci a HTML soubor si je vždycky najde. Stačí mít ve zdrojovém kódu HTML dokumentu zadané vhodné relativní cesty. Navíc tu složku s dokumentem a všemi doplňkami můžu kdykoliv přemístit jinam, kam chci a schopnost načítání se nenaruší. Dokonce můžu přejmenovávat i nadřazený adresář a nic se tím nenaruší. A co víc. Vůbec není zapotřebí upravovat proměnnou PATH. Je to vinikající chování HTML dokumentů, jenom škoda, že se tak výborně neumí chovat různé spustitelné soubory aplikací a podobně.

[Filip Jirsák]

To ale něco děláte špatně. $PATH je proměnná, kde hledá shell příkazy, které spouštíte. Načítání doplňků nějakým programem by na téhle proměnné vůbec nemělo záviset, a nechápu, proč by někdo něco takového udělal. Takže buď je něco špatně udělané v tom programu, nebo něco děláte špatně vy – asi by bylo dobré napsat, o co se vlastně pokoušíte.

[Begleiter]

Pokud se budete držet při sestavování programů Filesystem Hierarchy Standard, tak se vyhnete mnohým problémům.

Všechen software by měl být instalován z (oficiálních) balíčků, přičemž by měl být dodržen Filesystem Hierarchy system...

Pokud se nechcete FHS držet, tak aspoň dejte všechny spustitelné soubory do jednoho adresáře, který přidáte do PATH.

[DWD]

dejte všechny spustitelné soubory do jednoho adresáře, který přidáte do PATH. Takovým způsobem bych to nerad řešil, protože časem takových programů můžu mít třeba i padesát, ke každému tomu programu nějaké ty pluginy, a tak dále, a kdybych to všechno měl sypat do jedne složky dohromady, měl bych zachvíli pěkný nepořádek. Ani bych nevěděl, co k čemu patří a možná by se i mydlily názvy souborů (například dva soubory se stejným názvem ve společném adresáři se navzájem přepíšou).

O co se vlastně snažím. Nevím, jestli to mám psát, asi to bude blbost, ale napíšu, o co jsem se snažil. Protože mám rád pořádek, rozhodl jsem se trochu uspořádat a překompilovat některé programy. Chtěl jsem, aby každý program měl svoji složku, ve které by bylo všechno, co ten program potřebuje: Hlavní spustitelný soubor a všechny jeho pluginy a jiné věci, nebo co k tomu programu zrovna patří. Každý ten program by měl svoji vlastní složku, ve které by bylo všechno, co k němu patří. Všechno takto přehledně uspořádané. A aby spuštěný program byl schopný všechny doplňky hledat ve svoje složce. Dokonce jsem chtěl, aby ikdyž složku s programem přesunu kamkoliv, nebo přejmenuji některý nadřazený adresář, stále by spuštěný program hledal doplňky ve složce, ve které se nachází. Čili zřejmě by musel načítat svoje doplňky relativním způsobem, ne absolutním. Takže programy by byly vlastně takové kazety, které můžu kdekoliv spustit. A úplně ideální by bylo, kdyby v těch "kazetách" byly obsažené i všechny knihovny, které program potřebuje, pokud potřebuje, a i ty knihovny aby program byl schopný načíst tak, jak jsem před chvíli popsal o doplňcích. Tyto knihovny by byly obsažené ve složce toho programu, který ji potřebuje. A co když několik programů potřebuje stejnou knihovnu? Nevadí, v tom případě by se knihovna nakopírovala do několika těch složek.

Nakonec u některých programů by bylo lepší, kdyby se nemusely ani instalovat a daly by se rovnou používat.

HTML dokumenty mám vlastně taky v takových "kazetách". Každý html dokument mám v jedne složce a v ni všechno, co ten dokument potřebuje. Hlavní soubor a k němu všechny doplňkové soubory, které k tomu souboru patří, například obrázky. Všechno rozdělené do složek, podle toho, co kčemu patří. Dokonce není problém ani když chci složku s dokumentem kamkoliv přemístit nebo přejmenovat nadřazený adresář. Nic nezabrání tomu, aby se doplňkové soubory k dokumentu správně načetly.

[Filip Jirsák]

Pokud máte rád pořádek, používejte to, jak vám programy instaluje distribuční správce balíčků. Snažit se udělat pořádek v systému, kterému příliš nerozumíte, zpravidla nevede k dobrým koncům. Ostatně „pořádek v programech“ nespočívá v tom, že máte programy pěkně úhledně srovnané jeden vedle druhého – to, kde je jaký soubor, není podstatné. Podstatné je, aby bylo jasné, k čemu ten soubor patří, na čem závisí a co závisí na něm. Pak je možné jej správně aktualizovat, udržovat aplikace na něm závislé a odstranit jej v případě, kdy přestane být potřeba.

Roztahat duplicitní knihovny po celém systému rozhodně není dobrý nápad, už se vám pak nikdy nepodaří to všechno správně udržovat a aktualizovat. Dalo by se to řešit pomocí odkazů, místo kopírování knihoven byste na ně vytvářel odkazy.

Pluginy ani žádné „a tak dále“ v $PATH nepotřebujete, stačí spustitelný soubor programu. Takže si můžete vytvořit jedno místo a tam si nalinkovat všechny spustitelné soubory.

[Petr Šobáň]

Já mám svoje programy (většinou spustitelné skripty) v home v adrsáři bin ten jsem si přidal do PATH.

Pokud si chcete optimalizovat programy tak většina balíčkovacích systémů má i src balíčky co si můžeš upravit a přeložit sám a pak je zase normálně nainstalovat.

Jinak nedoporučuji zde zavádět nějaké novoty - jako vše v jednom adresáři. (Je to fakt cesta do pekel věř skušenějším)

Stačí kouknout do windows jaké to tam dělá problémy

[Filip Jirsák]

Já mám svoje programy (většinou spustitelné skripty) v home v adrsáři bin ten jsem si přidal do PATH.

On je snad někdo, kdo to tak nemá?

[Petr Šobáň]

On je snad někdo, kdo to tak nemá?

Určitě se někdo najde kdo se to bude snažit zase vše cpát do jednoho adresáře někam do /tmp a pak se diví že mu tam mizí soubory

[Begleiter]

Snažíte se udělat "pořádek" v systému, kterému moc nerozumíte.

Držte se Filesystem Hierarchy Standard.

[DWD]

Teď mě napadá, jestli jsem se vlastně nesnažil napodobit podobný pořádek, jaký používá GoboLinux. Tam je v systému adresář /programy nebo tak nějak a v tom adresáři jsou podadresáře různých programů, co program, to podadresář. V každém tom jednotlivém podadresáři jsou všechny soubory, které k tomu programu patří a mám pocit, že i knihovny a pokud stejnou knihovnu používá několik programů, mám pocit, že se knihovna opakuje v několika složek s programama (nejsem si ale jistý, jestli to úplně pravda). Instalace programů se vlastně rovná nakopírování složky s programem do adresáře /programy. Aby systém lépe našel spustitelné soubory, je tam i adresář se symbolickými odkazy spustitelných souborů. Odinstalace programu je vlatně smazání podadresáře s programem a odstranění nefunkčního symbolického odkazu ze složky se symbolickými odkazy. Kompilace programů v GoboLinuxu má prý taky nějaké usnadnění.

Uspořádání, jaké má GoboLinux, se mi líbí. Vyplatí se přechod na GoboLinux? A vyvíjí se ještě vůbec tato distribuce? A jak je to se závislostmi balíků, repozitáři apod?

[Filip Jirsák]

Uspořádání, jaké má GoboLinux, se mi líbí.

Proč? Já přenechávám starost o detaily správy nainstalovaného softwaru správci balíčků. Nevím, proč bych jej měl kontrolovat nebo se starat o to, jak a kam programy instaluje. Připadá mi to jako zlozvyk z Windows, kde se o to systém moc nestará a pak tahle práce zbývá na uživatele. Podle mne má ale počítač sloužit člověku, ne naopak, takže mu takovouhle práci rád přenechám.

[Atrament]

Ano to co se snažíš napodobit opravdu vypadá jako GoboLinux, s tím rozdílem, že knihovny jsou stejně jako všude jinde sdílené, takže není pravda, že máš v jednotlivých adresářích úplně všechno co daná aplikace potřebuje k chodu. Kdysi jsem se na GoboLinux díval, ale nelíbilo se mi.

Ale můžeš pro začátek udělat toto: nech knihovny a takový ten základní systém (gnu utilitky, glibc, grub, xorg...) na balíčkovacím systému a kompiluj si takové ty uživatelské aplikace co třeba používaš - scribus, vlc, inkscape, smplayer a já nevím co ještě. Udělej si ve svém home adresáři třeba adresář apps a aplikace kompiluj s prefixem /home/DWD/apps/jmeno_aplikace. Nainstalované binárky z adresáře /home/DWD/apps/jmeno_aplikace/bin můžeš třeba nalinkovat do /usr/local/bin knihovny z /home/DWD/apps/jmeno_aplikace/lib do /usr/local/lib atd. Odinstalaci můžeš provést jak jsi psal - smazat adresář s aplikací a následně smazat mrtvé symlinky z /usr/local.

Při kompilaci se neboj využít balíčkovací systém - například sudo apt-get build-dep smplayer ti nainstaluje všechny dev balíčky potřebné ke kompilaci smplayer.

[DWD]

Jinak v Linuxu považuji za nedostatek takovou věc, že hotový balík je použitelný většinou do jediné distribuce Linuxu a jediné verze distribuce; v jiných distribucích nebo verzích nemusí fungovat. Proto, když budu někdy potřebovat přejít na novější Linux (ať už z důvodu, že se mi bude novější Linux hodit, nebo z důvodu, že mě k přechodu na novější Linux přinutí novější hardware podporovaný jenom v novějším Linuxu), mám to stížené. Všechny balíčky různých aplikací a pod, které jsem si za celou dobu postahoval, budu muset zahodit a stahovat je znovu, tentokrát z nových repozitářů. Je to práce navíc (ikdyž je to usnadněné tím, že můžu použít nástroj pro automatické řešení závislostí) a taky je možná i riziko, že v nových repozitářích bude chybět některá aplikace, z těch, co jsem předtím měl.

Tady by se hodilo, kdyby hotový balík byl přenesitelný do více Linuxů.

[Begleiter]

balík je použitelný většinou do jediné distribuce Linuxu a jediné verze distribuce

A od čeho jsou zdrojové kódy (texty)? Jinak je velmi užitečné naučit se vytvářet vlastní balíčky. Např. v Arch Linuxu se vytvářejí balíčky velmi snadno. Prostě jednou vytvoříte či jinak získáte -- dalo by se říct -- Bash skript PKGBUILD, který popisuje závislosti, jaké volby se mají použít při kompilaci... Podle tohoto skriptu se vytvoří požadovaný balíček. Nemusím snad zdůrazňovat, že takový skript stačí většinou jenom mírně upravit v případě nové verze programu.

[Filip Jirsák]

To je ale nevýhoda všech operačních systémů – i *BSD, Windows atd. Balík určený pro jednu distribuci linuxu nemůžete snadno použít v jiné distribuci linuxu, ve FreeBSD, ve Windows 7… Problém je totiž to, že se na Linux díváte jako na jeden operační systém. Ve skutečnosti je ale tím systémem jedna distribuce. Když budete chtít přejít na novější verzi té distribuce, není v tom žádný problém. Ale když budete chtít změnit operační systém (jinou distribuci nebo i jiné jádro OS), samozřejmě že si nemůžete přinést vše z toho původního systému. To by pak všechny systémy musely být stejné, a neměl byste žádný důvod ke změně.

[DWD]

Když budete chtít přejít na novější verzi té distribuce, není v tom žádný problém.

V tom případě jsem taky musel všechny balíčky vyhodit a stáhnout nové. Například jsem měl MandrivaLinux 2007.1 a přecházel jsem na MandrivaLinux 2008.0. Musel jsem všechny stažené a vypálené balíčky vyhodit a stáhnout je znovu, z nových repozitářů. Nebo jsem to dělal zbytečně?

Ale narazil jsem naopak na situaci, že program (binární) šel použít ve Windows 98, ale zároveň i v 2000, XP, atd.

[Filip Jirsák]

V té novější verzi distribuce pravděpodobně byly novější balíčky, takže je logické, že jste je musel stáhnout znovu. Pokud jste chtěl zůstat u starých, neměl jste dělat aktualizaci (ale nechápu, jaký by k tomu byl důvod).

[DWD]

Vysvětlím, proč by se hodilo, kdyby hotový balík byl přenesitelný do více Linuxů. Například proto:

Mám v počítači nainstalovanou určitou distribuci a verzi Linuxu. V něm mám nainstalované různé aplikace. Všechno funguje jak chci a všechno mi vyhovuje. Tak to budu mít nainstalované několik roků. Všechny balíčky, které jsem si za celou dobu postahoval, budu mít zalohované na DVD. Potom se rozhodnu, že si pořídím ještě jeden počítač. Stejný počítač, ani stejný harware už neseženu, budu si muset koupit jiný, novější. Tady můžu narazit na problém: Verzi Linuxu, kterou mám na tom prvním počítači, a která funguje bez problému, nemusí fungovat dobře nebo vůbec, na tom novějším počítači. Může být problém s grafickou kartou nebo s čímkoliv jiným. (Nebo to nehrozí?) Pokud nějaký takový problém nastane, nezbyde mi nic jiného, než si pořídit novější verzi Linuxu. A tady jsme u toho, o čem jsem před chvíli mluvil: Kdyby hotové balíky byly přenositelné z jednoho Linuxu do druhého, nemusel bych nic vyhazovat. Všechny balíčky, co mám zalohované na tom DVD bych mohl nakopírovat do počítače s tím novým Linuxem a mohl bych je znovu použít. Což bych taky udělal, protože nemám důvod vyhazovat něco, co mi celou dobu vyhovovalo. Ve skutečnosti však ty zalohované balíky použít nemůžu, protože do toho nového Linuxu nemusí pasovat. Budu si muset všechny balíčky, které potřebuji, stáhnout znovu, tentokrát z nových repozitářů. Je to práce navíc, ikdyž je pravda, že to mám usnadněné nástroji pro automatické vybírání závislostí. Ale hlavně: Je riziko (nebo snad není?), že v těch nových repozitářích už bude chybět některý program, z těch, které jsem používal na starém počítači a který potřebuji a potom bych byl v pytli.

[Filip Jirsák]

Nevidím důvod, proč si balíčky vypalovat na DVD a proč na počítači udržovat starou verzi programů, ve kterých jsou známé chyby. Píšete o linuxu jako distribuci, pak ale nedává smysl spousta dalších věcí, o kterých píšete – problémy s novějším počítačem apod. Pro novější počítač budete třeba potřebovat novější verzi jádra, ale kvůli tomu nemusíte měnit distribuci.

Bylo by lepší, kdybyste si nejprve zjistil, co jsou to linuxové distribuce, jak fungují správci balíčků atd. To, o čem píšete, pramení z nepochopení těchhle principů.

[DWD]

Pro novější počítač budete třeba potřebovat novější verzi jádra, ale kvůli tomu nemusíte měnit distribuci.

Pro novější počítač nemusí stačit jenom novější jádro, aniž bych měnil distribuci nebo verzi distribuce. Například když se stane, že určitá verze Linuxu nepůjde do počítače nainstalovat vůbec, tak těžko můžu doinstalovat nové jádro, když nemám nainstalovaný operační systém; nezbyde potom nic jiného, než si vybrat novější verzi operačního systému, která už nainstalovat půjde. Nebo když do nového počítače nainstaluji určitou verzi operačního systému a nebude fungovat grafická karta. Mohlo by se to sice obejít bez instalace novějšího operačního systému a stačilo by doinstalovat jenom novější jádro, které už ovladač k moji grafické kartě má, ale těžko toho docílím, když bez obrazovky na instalaci jádra neuvidím.

Nevidím důvod, proč si balíčky vypalovat na DVD a proč na počítači udržovat starou verzi programů

To je taková pojistka. Jistější pro mě je mít někde schované aplikace, které potřebuji, ikdyž časem třeba i zastarají. Je to pořád lepší, než potom některý důležitý program nesehnat vůbec, ani v nové, ani staré verzi. Myslím si totíž, že existuje riziko, že v novějších repozitářích může některý program chybět, nebo může být některý program zkažený. Doufejme ale, že to není moc pravděpodobné.

[Begleiter]

Rozlišujte pojmy (linuxová) distribuce, Linux (jádro) a také GNU/Linux (operační systém založený na Linuxu (jádro) a softwaru z projektu GNU).

Dále byste si měl nastudovat pojmy jako jsou repozitáře (balíčků), správce balíčků a také obecně, co je balíček...

Nemá smysl se s váma o něčem bavit, dokud nebudete znát tyto a další pojmy!

[Filip Jirsák]

Nevím, čemu říkáte „verze Linuxu“, takže o pravdivosti vašeho výroku těžko rozhodnout. Základní VGA režimy bude umět i sebenovější grafická karta, takže novější jádro nainstalujete hravě. Riziko toho, že nějaký důležitý program se z repozitáře odstraní nebo v něm bude nepoužitelná verze, v mizivé míře samozřejmě existuje, ale pro vás existují daleko pravděpodobnější problémy. Takže to, co řešíte, bych si nechal na později, až to bude aktuální a všechny ty závažnější problémy budete mít vyřešené.

[Petr Šobáň]

Panebože o čem to tady pořád melete ?

Vy chcete aby linux uměl všechno a byl to zázrak.

Ukažte mi nějaký OS který splňuje vaše požadavky a to že staré programy nepůjdou na novém OS je u všech OS.

Moje programy co jsem psal chodí na MS-DOS, win95, ale na vistách a dalších už je nespustíš tak naco mi leží na CD ?

Tak i různé programy pro win spustíš pouze na některých win a na dalších je nespustíš.

Pokud chceš zálohovat programy tak si musíš zálohovat zdrojové kody ty vždy přeložíš a pokud ne můžeš zdroják upravit.

PS. Jak vidím tak linux není pro tebe - pořiď si ten zázračný OS co umí všechny tvoje požadavky, já ale takový OS neznám.

PS2. Pokud chceš spouštět staré programy tak si musíš schovat i starý HW na kterém to poběží.

[Ash]

Máte to nějaké popletené, u starého systému chápete že nemusí fungovat na novém hw, že bude potřeba novější, a u staré aplikace vypálené na DVD to nechápete a chcete mermo mocí aby byla přenositelná na nové železo? To je trochu schýza za vaší strany :) Vymýšlíte problém který neexistuje.

[DWD]

Nevím, čemu říkáte „verze Linuxu“

Asi jsem se celou dobu blbě vyjadřoval: Distribuci Linuxu jsem myslel to, jestli je to Mandriva nebo Ubuntu nebo RedHat a tak dále. Verzemi Linuxu jsem myslel to, jak nová je distribuce, například jestli Mandriva Linux 2008.0 nebo 2010.1 a podobně. Potom nevím, jak jsem tyto věci měl správně vyjádřit.

Jaktože nevím, co jsou to balíčky, co jsou to repozitáře, co je správce balíčků. Co asi celou dobu používám. To, že vypadá, že nerozumím základním pojmům, bude asi tím, že že si vymýšlím přehnané požadavky na operační systém a neumím pořádně vysvětlit, o co se mi jedná.

PS. Jak vidím tak linux není pro tebe - pořiď si ten zázračný OS co umí všechny tvoje požadavky, já ale takový OS neznám.

Pochopil jsem, že vůbec žádný operační systém není pro mě, ani celý počítač. Proto udělám nejlépe, když se na počítače vykašlu úplně, měl jsem to udělat dávno.

[Filip Jirsák]

Rozhodně nenastane případ, že byste si do počítače mohl nainstalovat Mandrivu 2008, ale Mandriva 2007 by tam nešla. Může to nastat pro verze distribucí vzdálené třeba 10 let, ale pak vám budou k ničemu i balíčky vypálené na DVD, protože ty do té nové distribuce nejspíš taky nenainstalujete, a i kdyby ano, nebudou fungovat.

Vaš požadavky nejsou ani tak přehnané, jako hlavně nesmyslné. Když si nainstalujete nějakou distribuci, budete normálně používat její balíčkovací systém a programy (a případně distribuci) průběžně aktualizovat, na problémy, o kterých uvažujete, v příštích deseti letech nenarazíte.

[Michal Kubeček]

Rozhodně nenastane případ, že byste si do počítače mohl nainstalovat Mandrivu 2008, ale Mandriva 2007 by tam nešla. Může to nastat pro verze distribucí vzdálené třeba 10 let

To je nesmysl. Když si vezmete těch jedenáct po sobě jdoucích verzí z jednotlivých let, tak pokud to na začátku nejde a na konci ano, musí někde existovat bod, kde verze n nejde a n+1 ano.

[DWD]

Podobný případ se mi už stal. Do notebooku Acer Extensa 5635Z jsem zkusil spustit živě zatím bez instalace Ubuntu 8.04. Byl problém s grafickou kartou, vůbec nic jsem neviděl, úplně roztrhaný obraz. Ani tlačítko pro ukončení jsem neviděl. Taktak se mi povedlo systém ukončit. Ubuntu 10.04 už problém s obrazem neměl, tak jsem ho nainstaloval.

[lertimir]

Celkem bych i trochu chápal, jak to myslíte s těmi balíčky software, ale dle mne, je to jednak obrovská a jednak zbytečná práce. obrovská v tom, že každý balíček by musel být, vždy a uvnitř postaven relativními odkazy. zbytečná v tom, že se tím by případně jez zvyšoval současný balíčkovací chaos. Současná struktura je taková, že programy mají standardní instalace v share a v bin jsou buď spouštěcí skripty nebo jen odkazy. V podstatě se to blíží objektovému principu. Program je objekt a vy k němu nemáte přímý přístup. Jen přes standardní balíčkovací systém. I při kompilaci je to vidět. když v ./configure --prefix="path" zadate relativní cestu dopadne to většinou špatně. Předělat to na adresářový baliček vidím jako nerealizovatelné a tady neudržovatelné, jaké knihovny budou sdílené a jaké si baličky budou vozit sebou.

a z hlediska spolupráce starých programů s novým jádem problémy nejsou. tedy když jsou dobře kompilovany. Tím myslím, že program si linkuje knihovnu např. libwx_base_xml-2.8.so.0 což je stabilní odkaz a ne libwx_base_xml-2.8.so.0.6.0, což je aktuální knihovna o dva řády verzí níže. Když linkuje tu druhou tak je samozřejmě problém. A druhá vec je rozhodnutí jestli chci preferovat konzervativní distribuce, které mají pomalý cyklus ale je tam nižší pravděpodobnost regresí nekompatibilit a problémů a nebo být vice na hraně a mít nové verze.

Na druhou stranu máte-li sadu nutných programů, které potřebujete, je nejjednodušší je mít ve zdroji jako tar.gz a dokompilovat, kde je potřeba. v delším časovém profilu se to ale stejné týká jen programů pro konsoli. V současnosti například programy ve zdrojovém kódu pro KDE 3.x do 4 bez úprav nezkompilujete. A kdoví jak to bude s Gnome 3?

[iKoulee]

Dobry vecer,

Pro novější počítač nemusí stačit jenom novější jádro, aniž bych měnil distribuci nebo verzi distribuce.

Situace je trochu komplikovanejsi. Kdykoliv Vam nebude stacit jenom jadro, neexistuje sance jak prenest spustitelne soubory. Toto nelze provest v podste pouze pri zmene architektury pocitace. Pokud architektura zustava, staci pouze zmenit jadro a muzete instalovat treba 100 let stary sw, je velice pravdepodobne ze se Vam instalace nezadari z originalniho media, musel by jste si jej upravit (pridat novejsi jadro) coz ale neni akce schudna pro uplneho zacatecnika.

Myslím si totíž, že existuje riziko, že v novějších repozitářích může některý program chybět, nebo může být některý program zkažený.

Ohledne dostupnosti software v repository: ano existuje sance ze software, ktery pouzivate nemusi byt v nekterem z nasledujicich release, ale je velmi mala, v podstate to znamena, ze autori distribuce usoudili, ze jej jiz nikdo nepouziva a nebo je jeho pouzivani nebezpecne. (V prvnim pripade Vam jej na pozadani jiste do distribuce vrati, ve druhem by to byla silenost.) Pokud po zalohovani sw i tak zatouzite, doporucuji vypalit baliky vcetne zavyslosti, nemel by byt problem je nainstalovat i v pozdejsi verzi distribuce za predpokladu ze bude zachovana architektura jak jsem zminoval vyse. K tomuto vsak opet potrebujete jiste znalosti o balikovacim systemu, jelikoz se nejedna o uzivatelskou akci (zde je treba zduraznit ze vsechni UNIX a UNIXlike systemy, mozna s vyjimkou OSX, nepovazuji, narozdil od MS produktu instalaci SW za uzivatelskou akci, jelikoz i instalace toho nejtrivialnejsiho programu muze mit fatalni dusledky)

Ohledne Vaseho puvodni dotazu:

1. pridavat si '.' do defaultnich cest (vyznam promnenne PATH) je velice nebezpecne
2. zridit si adresarovou strukturu jakou jste nastinil je samozrejme mozne, ale neni to trivialni operace, jako je upraveni obsahu promnenne, na to aby jste toho mohl dosahnout musite udelat mnoho prace a mit pomerne rozsahle znalosti (v podstate vse co za vas resi autori jednotlivych linuxovych distribuci)
3. doporucil bych Vam vyzkouset PCBSD system portu by Vam mohl vyhovovat, protoze pouziva obdobnou metodiku jakou jsem pochopil ze vyzadujete.

[DWD]

Pokud po zalohovani sw i tak zatouzite, doporucuji vypalit baliky vcetne zavyslosti, nemel by byt problem je nainstalovat i v pozdejsi verzi distribuce za predpokladu ze bude zachovana architektura jak jsem zminoval vyse.

Jestli by si ale knihovny, na kterých hlavní balík závisí, nevadily s knihovnama obsaženýma v te pozdější verzi distribuce.

Do toho zachování architektury patří to, aby jsme nezaměňovali 32 bitové za 64 bitové, nebo do toho patří více věcí?

[iKoulee]

Jestli by si ale knihovny, na kterých hlavní balík závisí, nevadily s knihovnama obsaženýma v te pozdější verzi distribuce.

To by nemel byt problem, v podstate, pokud distribuce bude obsahovat novejsi verzi knihovny nebude treba starou ani instalovat, protoze knihovny jsou zpetne kompatibilni

Do toho zachování architektury patří to, aby jsme nezaměňovali 32 bitové za 64 bitové, nebo do toho patří více věcí?

Pokud uvazujete nad architekturou x86, tak x86 na x86_64(amd64) spustit v omezene mire lze ale je mozne, ze v budoucnu se mainstreamova architektura osobnich pocitacu zmeni, napr arm, itanium atp.

[Filip Jirsák]

Knihovny nemusí být a nejsou zpětně kompatibilní (v rámci velkých verzí, opravy by zpětně kompatibilní být měly). Důležité je ale to, že aplikace obyčejně nezávisí na nějaké knihovně, ale na verzi knihovny. A systém taky jednotlivé verze knihoven rozlišuje. Takže není problém mít vedle sebe nainstalováno několik verzí téže knihovny, a každá aplikace použije tu, kterou potřebuje.

[iKoulee]

Pokud si vyvojari alespon hraji na posix meli by symboly zustat mezi verzemi zachovane.

Nicmene uznavam, ze to neni nezbytne nutne a dopustil jsem se nadbytecneho zjednoduseni.

[Begleiter]

Pokud budete používat "rolling-release" distribuci, tak se vyhnete problému upgradu ze starší verze distribuce na novější. Např. Arch Linux používá "rolling-release model".

[Ash]

+1, používám stejný OS už léta a světe div se, mám aplikace stále aktuální. A nic nemusím ručně stahovat nebo o čem to ten člověk mluvil.

[Michal Kubeček]

To není tak úplně pravda. S "rolling updates" se změní pouze to, že změny narušující kompatibilitu nebudou přicházet v dávkách ale průbežně. Rozhodně nemůže počítat s tím, že nějakým zázrakem zmizí. Někomu vyhovuje jeden model, někomu druhý.

[Begleiter]

Samozřejmě máte pravdu. Ale to slůvko "průběžně" je zcela zásadní.