Byl vydán Debian 12.10, tj. desátá opravná verze Debianu 12 s kódovým názvem Bookworm. Řešeny jsou především bezpečnostní problémy, ale také několik vážných chyb. Instalační média Debianu 12 lze samozřejmě nadále k instalaci používat. Po instalaci stačí systém aktualizovat.
Byla vydána nová verze 4.5 svobodného notačního programu MuseScore (Wikipedie). Představení novinek v oznámení v diskusním fóru a také na YouTube.
Byla vydána nová verze 8.6.0 správce sbírky fotografií digiKam (Wikipedie). Přehled novinek i s náhledy v oficiálním oznámení (NEWS). Nejnovější digiKam je ke stažení také jako balíček ve formátu AppImage. Stačí jej stáhnout, nastavit právo ke spuštění a spustit.
O víkendu probíhá v Praze na Karlově náměstí 13 konference Installfest 2025. Na programu je celá řada zajímavých přednášek a workshopů. Vstup je zdarma. Přednášky lze sledovat i online na YouTube.
Byla vydána nová verze 2.49.0 distribuovaného systému správy verzí Git. Přispělo 89 vývojářů, z toho 24 nových. Přehled novinek v příspěvku na blogu GitHubu a v poznámkách k vydání.
Premiér Petr Fiala (ODS) dnes na síti X vyloučil, že by za jeho vlády mohla začít platit vyhláška, podle níž by poskytovatelé internetového připojení měli uchovávat adresy internetových stránek, na které se lidé připojují.
Flock 2025, tj. konference pro přispěvatele a příznivce Fedory, proběhne od 5. do 8. června v Praze.
Zemřel Mark Klein, který dlouhá léta pracoval pro telekomunikační firmu AT&T a proslavil se jako whistleblower, když zveřejnil informace o spolupráci AT&T s agenturou NSA. Cílem spolupráce bylo sledovat veškerou komunikaci občanů za pomocí zařízeních v místnosti 641A. O spolupráci obou subjektů napsal knihu Wiring Up The Big Brother Machine...And Fighting It.
Byla vydána nová verze 16 integrovaného vývojového prostředí (IDE) Qt Creator. Podrobný přehled novinek v changelogu.
Texas Instruments představil nejmenší mikrokontrolér na světě MSPM0C1104. Je o 38 % menší než současné nejmenší mikrokontroléry. Má pouze 1,38 mm².
Rozhodl jsem se trochu osvětlit problematiku instalování programů v Linuxu. Protože je to téma rozsáhlé, začněme hned bez prodlev. Programy lze v Linuxu instalovat třemi způsoby:
Já se v textu věnuji hlavně bodu jedna, zmiňuji i bod tři. Na téma druhé byl na AbcLinuxu publikován seriál Nebojíme se kompilace.
Balíček je soubor, který má přesně definovanou logickou strukturu a jeho název je tvořen podle určitých syntaktických pravidel. Pro každou distribuci je obvykle určen jeden typ balíčků. Znamená to, že chceme-li instalovat nový program, je vhodné (téměř nutné) najít balíček pro svou konkrétní distribuci.
Balíček hledejme v tomto pořadí, ušetříme si čas, nervy a případnou ostudu při dotazu ve fóru:
Je vhodné zmínit, co není balíček. Balíčkem v tomto kontextu
nejsou soubory .tar, .gz, .tar.gz, .bz2 a podobné kombinace. Jsou to pouze
komprimované archivy, které obvykle obsahují zdrojové kódy, nebo program a
jeho data, která obvykle nelze instalovat pomocí balíčkovacího systému. Je
to příklad produktů Mozilla.
(Všechny lze ale obvykle sehnat v patřičném balíčku pro vaši distribuci.)
Pokud archiv obsahuje připravený program (např.
firefox-1.0.tar.gz), "instaluje" se pouhým rozbalením do
nějakého adresáře, např. do domovského adresáře uživatele nebo do adresáře
/usr/local/ (ve druhém případě jako root). Pak už jen stačí
spustit program, jehož jméno se obvykle shoduje s názvem balíčku a celého
programu: /usr/local/bin/firefox.
Poznámka: Podobně nesrozumitelná situace panuje v případě Java programů
s příponou .jar. Ty se obvykle pouze spouštějí příkazem
java -jar jmeno_programu.jar. (Ačkoliv i .jar je
"balíček", není ale určen k instalaci.)
Ruku v ruce s vývojem distribucí se ustálily také balíčkovací systémy, které jsou pro každou distribuci typické. Dá se tedy říci, že pro každou z nich je typický určitý balíčkovací systém. Proč je nutné používat odpovídající balíček? Systém balíčků spočívá v tom, že instalovaný soubor je začleněn do databáze již instalovaných programů, data jsou zkopírována na "správné" místo a v databázi jsou následně uloženy informace o tom, že tento proces proběhl. Tyto údaje jsou nutné pro pozdější odinstalaci balíčku.
Zde vzniká problém, který je noční můrou mnoha uživatelů a může být i
příčinou jejich "odchodu" k jiné distribuci. Je to systém závislostí.
Princip je jednoduchý: určité balíčky mají vyznačenu závislost na jiném
balíčku. Instalujete-li např. program.rpm, často vyžaduje také
instalaci třeba libprogram.rpm. Úmysl je jistě chvályhodný,
ale problém bývá v tom, že uživatel musí mnohdy ručně hledat požadované
balíčky, a to i přesnou verzi. Obranou proti tomu by mělo být správné
pořadí při instalaci, případně použití inteligentnějšího nástroje -
nadstavby, která zvládne řešení problémů se závislostmi za uživatele.
Slackware závislosti neřeší, Debian má vynikající nástroj apt, Gentoo stejně výborný systém emerge, které si s problematikou závislostí poradí hned v zárodku, RPM distribuce mohou využít např. urpmi (Mandrake) nebo yum (Fedora).
Pokud bychom se pokoušeli instalovat balíček, který není určen pro naši distribuci, a ono by se to povedlo, hrozí, že si databázi o nainstalovaném softwaru poškodíme a budou tedy následně problémy s odinstalováváním programů. Aplikace pro instalaci softwaru obvykle poznají, že daný balík není určen pro tento typ balíčkovacího systému a instalaci odmítnou. Nemá proto význam překonávat tuto logiku, spíš je vhodné hledat správný typ balíčku.
Nyní tedy krátké, ale praktické informace o distribucích a jejich balíčkovacích systémech. Nebo spíše obráceně?
Balíček RPM (struktura) vznikl původně pro Red Hat Linux, název je akronym pro RPM Package Manager, původně snad Red Hat Package Manager. Dnes se používá i v distribucích Fedora Core (následník RHL pro desktop, vznik 2003), SUSE a Mandrakelinux. Mandrakelinux se od větve RHL odtrhl na konci devadesátých let. Distribuce SUSE byla původně založena na Slackware, ale adoptovala také formát balíčků RPM. Kromě toho používají RPM ještě další distribuce odvozené od RHL.
Je vhodné podotknout, že kromě klasických balíčků jako
firefox-1.0-8.i386.rpm, které obsahují data, tedy to, co
potřebujeme nainstalovat, existují také balíčky se zdrojovými kódy
aplikací, např. firefox-1.0-8.src.rpm. Pokud je
nainstalujeme, získáme pouze zdrojové kódy aplikací, které je
nutné ještě zkompilovat. Tato činnost se vykonává výjimečně a začínající
uživatel ji vůbec nemusí provádět.
Názvy balíčků se v těchto distribucích liší, aby se vzájemně odlišily a nemátly uživatele. Na druhou stranu jistě existují balíčky, které přenášet lze; ale platí to spíše výjimečně! Tak jako se liší názvy, liší se i obsah balíčků. Logická struktura je stejná, ale například adresáře mají v každé z těchto distribucí (bohužel) nepatrně odlišnou strukturu, přesněji řečeno: některé programy se mohou instalovat jinam. Proto si nainstalováním nesprávného balíčku můžeme "zaneřádit" systém. Proto znovu opakuji: každému, co jeho jest.
harddrake-10.1-27.5.101mdk.i586.rpm xine-lib-1.0.0-2.1.fc3.fr.x86_64.rpm kernel-module-alsa-0.9.8-1.fr_2.4.20_20.9.i586.rpm anjuta-1.2.2-1.0.yd4.fr.ppc.rpm
Jména jsou tvořena podle specifikace. Ve zkratce:
AbcLinuxu.cz
ITBiz.cz
HDmag.cz
AbcPráce.cz
name-version-release.architecture.rpm
Ne všechno je tak růžové, takže lze běžně nalézt RPM balíčky, které se normy pojmenovávání nedrží; ale s tím asi nic neuděláme.
Univerzální službou pro stažení RPM balíků je rpmfind.net. Každá distribuce má pochopitelně své archivy, kde naleznete aktuální (a počeštěné) verze. Standardní program, který umí s balíčky pracovat, je rpm. Existuje ale množství nadstaveb, více níže.
Balíky DEB jsou používány v Debianu a distribucích odvozených, např. Knoppix, Ubuntu. Způsob jejich pojmenování je následující:
name_version-revision_architecture.deb
Velkou roli hrají podtržítka a pomlčky. Podtržítko odděluje jméno programu od verze, pomlčka verzi od revize a opět podtržítko revizi od architektury. Na všechno jsou předpisy ;-).
Zdroje balíčků naleznete v seznamu zrcadel na debian.org.
Balíčky pro Slackware mají příponu TGZ. Ve skutečnosti se jedná o klasický archiv .tar.gz, který ale vždy obsahuje dodatečné informace, které jsou typické právě pro balíček. Také zde existuje syntaxe pojmenovávání:
name-version-architecture-buildauthor.tgz
Zdrojem pro Slackware balíčky je archiv LinuxPackages.net, oficiální balíčky jsou k dispozici na Slackware Package Browser.
Gentoo je výkonná distribuce založená na výrazně odlišných principech. Je-li Fedora Core nebo Mandrakelinux distribucí založenou na binárních balíčcích, potom je Gentoo distribucí založenou na zdrojových souborech, které se kompilují na míru cílovému počítači. Výhodami a nevýhodami se zde zabývat nebudeme, ale pokusíme se pochopit princip balíčkovacího systému.
Balíčkovací systém je postaven na tzv. portage stromu. Jedná se
adresářový strom uložený v /usr/portage. Každý z
adresářů obsahuje další adresáře, které specifikují název balíčku. V
adresáři balíčku jsou mimo jiné také skripty s příponou
.ebuild. Obsahem tohoto skriptu je popis balíčku, licence,
verze, architektura, závislosti. V každém adresáři označujícím program bývá
více ebuildů označujících verzi. Lze tak provozovat více verzí zároveň,
stejně jako držet se starší verze.
$ ls kde-base -c1 celkem 12K 512 arts/ 512 kde/ 512 kdeaccessibility/ 512 kdeaddons/ 512 kdeadmin/ 512 kdeartwork/ 512 kdebase/ 512 kdebindings/ 512 kdeedu/ 512 kde-env/
O systému emerge vyšel skvělý dvoudílný článek Balíčkovací systém Gentoo Linuxu.
Výběr několika zajímavých otázek. Nepokrývá samozřejmě všechny aspekty používání balíčkovacích systémů na všech distribucích. Podrobnější informace naleznete v článcích a příručkách:
Záleží na tom, co máš za distribuci:
Každý program používá konfigurační soubory, kde se musí zadat adresy repozitářů na Internetu, odkud se balíčky budou stahovat. To je však téma na další články.
dpkg -i balicek.deb.rpm -e xx.686.rpm, hlásí rpm, že
xx.686.rpm není nainstalován. Přitom vím, že nainstalovaný
je.rpm -e xx.V adresáři /var/log/packages/ se nacházejí textové soubory
s popisem nainstalovaných balíčků. Z těchto souborů lze zjistit mnoho
informací. Každý ze souborů se jmenuje stejně jako nainstalovaný balíček
(pouze nemá příponu .tgz):
$ ls /var/log/packages/*alsa* -c1 16K /var/log/packages/alsa-driver-1.0.8_2.4.29-i486-1 8,0K /var/log/packages/alsa-lib-1.0.8-i486-1 4,0K /var/log/packages/alsa-oss-1.0.8-i486-1 4,0K /var/log/packages/alsa-utils-1.0.8-i486-1
Hledáme-li balíček, ve kterém se nachází soubor radeon.o
(jaderný modul), můžeme to zjistit následovně:
$ grep 'radeon.*\.o' /var/log/packages/* /var/log/packages/kernel-modules-2.4.27-i486-1:\\ lib/modules/2.4.27/kernel/drivers/char/drm/radeon.o.gz /var/log/packages/kernel-modules-2.4.29-i486-1:\\ lib/modules/2.4.29/kernel/drivers/char/drm/radeon.o.gz
Soubor se tedy nachází v balíčcích
kernel-modules-2.4.27-i486-1 a
kernel-modules-2.4.29-i486-1.
rpm2tgz, která převede RPM balíček
do TGZ. Funguje to snad vždy. Balík, ve kterém se nachází, najdete pomocí
předchozího tipu ;-).Balíčkovací systém zůstává pořád stejný, a to RPM. Urpmi, apt, yum jsou pouze nadstavby pro automatickou aktualizaci, které stejně instalují prostřednictvím rpm. Není tedy problém použít více těchto nástrojů zároveň.
./configure. Ale co když soubor
configure žádný není? Potom napíšu příkaz make,
make install nebo popořadě za sebou, či jak? V mém
terminálu však příkaz make vůbec nefunguje, (odpověď terminálu
- příkaz nenalezen). Který balíček mně chybí? A jak se má tedy správné
instalovat vcelku, abych viděl, co a jak a kam který soubor se
překopíroval?Pokud jste začátečník, úplně zbytečně se pouštíte do kompilace. Programy, které budete potřebovat, se nacházejí na instalačním CD nebo na Internetu - každopádně však ve formě balíčku, který stačí pouze řádně nainstalovat pomocí některého nástroje (rpm, yum, Yast, urpmi). Záleží na vaši distribuci.
Programy s příponou .exe nelze v Linuxu spustit(*). Jedná se o binární kód, a ten je ve Windows, DOSu a Linuxu odlišně interpretován. Pokud stahujete nějaký soubor, přesvědčte se, že je určen pro Linux a že se jedná o balíček podle výše zmíněných pravidel.
(*) Poznámka: Množství .exe programů určených pro Windows lze v Linuxu spouštět prostřednictvím Wine či Cedega.
rpm -qa vypíše
všechny nainstalované balíčky.
rpm -qa | grep -i 'gcc' vypíše
balíčky, v jejichž názvu se objevuje řetězec "gcc".pkgtool, jednak
jednotlivé příkazy installpkg, removepkg (a další).
Chci ještě zmínit skvělý program Checkinstall, který
funguje v mnoha distribucích. Umí vytvářet balíčky pro zvolenou distribuci,
já jej používám na Slackwaru. Příkaz checkinstall se provádí
po dvojici příkazů configure a make. Po správném
nastavení vyrobí balíček (TGZ, DEB, nebo RPM) a korektně jej nainstaluje
tak, aby šel později stejně korektně a bezchybně odinstalovat. Je to
opravdu skvělá pomůcka, díky níž si v systému uchováte pořádek. Používám ji
samozřejmě pouze v případech, kdy si chci "ušít" balíček na míru, nebo
pokud balíček pro Slackware neexistuje.
Nástroje: Tisk bez diskuse
Tiskni
Sdílej:
harddrake-10.1-27.5.101mdk.i586.rpm
Mandrakelinux
xine-lib-1.0.0-2.1.fc3.fr.x86_64.rpm
Fedora Core 3
anjuta-1.2.2-1.0.yd4.fr.ppc.rpm
YellowDog Linux 4.0
Jen ze zvedavosti: pro kterou distribuci je tenhle balik? Fedora?
kernel-module-alsa-0.9.8-1.fr_2.4.20_20.9.i586.rpm
RH 9. Google ví...
java -jar program.jar spusti instalaci programu (klasicky wizzard s tlacitky Dalsi, Dalsi, Hotovo).
Dale bych jeste doplnil, ze pod RPM distribucemi se da celkem snadno priradit soubor na disku k distribuci. Napriklad si v mc projdu disk a najdu tam v /usr/lib adresar openoffice. Chci odstranit cely balicek OpenOffice. Tak si otevru ten adresar, vyberu si soubor (napriklad README) a spustim:
$ rpm -qf README.html OpenOffice.org-1.1.3-2mdkA pak uz vim, proc
rpm -e openoffice hlasilo neznamy balicek 
16.2.2005 11:58
Jiří Svoboda | skóre: 37
| blog: cat /dev/mind
| Prostějov
A nejhorsi je, ze ma Yeti pravdu.
16.2.2005 13:04
Jiří Svoboda | skóre: 37
| blog: cat /dev/mind
| Prostějov
Jinak mas pravdu. Mne nastesti RPM vyhovuje, rebuidoval jsem jen mplayer. Az se poradne naucim vyrabet baliky, mozna sem o tom napisu.
.
16.2.2005 12:17
Jiří Svoboda | skóre: 37
| blog: cat /dev/mind
| Prostějov
a to robim tak, ze pomocou checkinstallu spravim balik na testovacom stroji a potom, ak treba, balik rucne upravimHmm, to taky dava "smysl". Nebylo by lepsi ten balicek vytvorit rovnou korektne?!
chcekinstall je _jednoduchy_ instalacny program, robi presne to na co je urceny, nic viac, nic menej.Ne, nedela to, k cemu je urceny, resp. dela to spatne. Mnoho jeho chyb bylo nahore popsano. Jelikoz jsi neuvedl ani jeden argument, ze tomu tak neni, tak nechapu, proc bych mel v tehle diskusi pokracovat.
Ne, nedela to, k cemu je urceny, resp. dela to spatne.Odmítáš připustit, že někomu by funkce checkinstall mohly vyhovovat a ani by nechtěl, aby svou práci dělal jinak? To je zvláštní, ne? Vždyť záleží na každém, co si zvolí za programy, které bude používat. Pokud někomu vyhovuje checkinstall a žádné další, lepší nebo propracovanější funkce od něj neočekává, pak je to zjevně program pro něj jako dělaný. Checkinstall není určen pro vytváření balíků komplikovaných a komplexních aplikací, které například nějak ovlivňují způsob startování systému, přidávají soubory do /etc apod. Takže Apache a spol., které zmiňoval Yeti, by nikoho ani nenapadlo tím balíčkovat. Může však být prospěšný, chceš-li vytvořit balíček třeba pro nově zkompilovaný styl pro Gtk+/Qt, applet do nějakého panelu, sadu ikon apod.
Odmítáš připustit, že někomu by funkce checkinstall mohly vyhovovat a ani by nechtěl, aby svou práci dělal jinak? To je zvláštní, ne? Vždyť záleží na každém, co si zvolí za programy, které bude používat. Pokud někomu vyhovuje checkinstall a žádné další, lepší nebo propracovanější funkce od něj neočekává, pak je to zjevně program pro něj jako dělaný.Ale vubec ne, nicmene debata je o tom, zda checkinstall funguje dobre nebo spatne. Je kazdeho vec, jestli pouziva spatne programy, ja to nikomu rozmlouvat nebudu...
Může však být prospěšný, chceš-li vytvořit balíček třeba pro nově zkompilovaný styl pro Gtk+/Qt, applet do nějakého panelu, sadu ikon apod.S velkou pravděpodobností bude i jednoduchý aplet zabalený špatně, což se projeví při nakopírování na jiný stroj nebo při odinstalování. Konkrétně: V %post fázi nevolá gconftool, namísto toho si přibalí soubory gconf backendu. Pokud je náhodou ve stejné konfigurační složce i konfigurace jiného programu, odstraňování balíků poškodí konfigurační databázi. V %post fázi nezavolá scrollkeeper-update, takže po nainstalování balíku na jiný stroj neuvidíte dokumentaci. Stejně tak v %post fázi nezavolá update-desktop-database, takže nebudou fungovat některé funkce závislé na desktop souborech. Opět se projeví po nainstalování balíku na jiný stroj.
ktora okrem toho, ze program nainstaluje, ho este aj zapise do databazi nainstalovanych programov (spolu z informaciami potrebnymi na odinstalovanje).Mas tam chybu - spolu s obvykle spatnymi informacemi... :-P
16.2.2005 22:41
Jiří Svoboda | skóre: 37
| blog: cat /dev/mind
| Prostějov
).
16.2.2005 12:22
configure && make && make install, tak to vyjde uplne nastejno. K cemu je teda ten checkinstall?
Ad 4/ Napr. k tomu, ze kdyby to fungovalo spravne, tak predchozi zbytecnou verzi smaze a nebude se valet zbytecne na disku. Pokud to neumi, tak viz ad 3/
Ad 5/ Viz ad 3/
Ja totiz hlavne nechapu, proc resis ty body 3-5 pomoci checkinstallu, na ktery se vubec neda spolehnout, spis naopak. To uz je opravdu lepsi nechat si to zkompilovane nekde v /usr/src/ a spolehnout se na make uninstall.
Cili suma sumarum - pokud jsem neschopen vytvorit si korektne RPM, tak si to nainstaluju do /usr/local a na takove pitomosti jako je checkinstall se muzu tak leda zvysoka...
P.S. Za teckou se pise velke pismeno. Uz po tobe ten humus dal nehodlam lustit, takze jestli chces pokracovat ve flameseni, tak zacni psat normalne.
make install se nepredavaji spravci balicku chybne informace, takze tento problem skutecne nastat nemuze. To neni vubec o tom, jestli funguje spravne make install, ale o tom, ze funguje spatne checkinstall.
2. Jo, jiste, ja to chapu, pak by ale nemel cpat spravci RPM balicku v distribuci zadne nesmyslne informace.
3. Pokud pises jako prase, tak musis pocitat s tim, ze ti to nekdo vytkne. Napr. to tvoje j narvane uplne vsude, to je opravdu parada cist. Kurnik to neumis psat spisovne slovensky nebo alespon nevytvaret pripitomele patvary, ktere ti buhviproc pripadaji asi c00l?! 
.
Checkinstall nepozná (a nemůže poznat) instalované soubory od editovaných. Pokud make install přidá něco do /etc/passwsd, bez okolků ho zařadí do balíku. A při mazání takového balíku máte po systému. tu si autor aj sam odpovedal - proste sa to nedaDá, když balíček vytváří člověk.
checkinstall je urceny _iba_ na instalaciu.Potom můžu rovnou používat make install nebo tar xzf -C /, od balíčku čekám i nějakou "přidanou hodnotu" než jen pouhé nakopírování souborů do systému.
? :) a ked das 'make install' a njeco sa v strede instalacie pokazi tak co sa stane ? :) to iste. proste len dalsi nezmyselny proti-argument na checkinstall, vlastne vsetky boli take..Když rpmbuild pod non-root účtem spustí make install a uprostřed instalace do dočasného adresáře se neco pokazí, tak se nic neděje.
Potom můžu rovnou používat make install nebo tar xzf -C /, od balíčku čekám i nějakou "přidanou hodnotu" než jen pouhé nakopírování souborů do systému.Tys to ale vubec nepochopil. ;o) Ta pridana hodnota prece spociva v tom, ze se predaji chybne informace spravci balicku v dane distribuci, takze pokud si system nahodou nenaboris uz pri instalaci, tak si ho velmi pravdepodobne naboris pri te odinstalaci. No a to se prece vyplati!
ano o tom sa tu bavime. vy totizto cakate od programu veci, ktore vela krat nezvlada ani clovek :)A v tom bude jádro pudla, "my" to totiž od programu nečekáme, protože víme, že vytvořit balíček je to úkol pro člověka a ne pro stroj.
ano s tymto suhlasim, avsak aj tak nemas 100% istotu, ze ked to urobis naostro, tak pojde vsetko ok.Naostro už se právě žádný make install nespouští, naostro se spouští instalační skripty, které já napíšu do spec souboru.
make install urychlit instalaci?
asi si uz zabudol, co si cital v mojich predchadzajucich prispevkoch :) urychluje instalaciu tak, aby sa to potom aj dalo komfortne odinstalovat.No vzhledem k tomu, ze neumis ani poradne psat, tak predpokladat nejakou logiku v teto uvaze je asi opravdu naprosto naivni.
a kde tam akoze hovorim, ze 'som hrdi na to ako pisem' ? :) to ako prekrucas slova inych ludi je sila :)Takze aby bylo jasno! Pisu: Dalsi tvoje prispevky psane zprznenou poloslovenstinou proste hodlam ignorovat. Je to koneckoncu tvoje vizitka. Reakce: ok, nikto ti to nezakazuje :) a je mi jedno co si o tom myslis, to si si uz mohol vsimnut :) A o neco drive: budem pisat tak, ako sa mi pise najlepsje a najrychlejsje, nikto ta nenuti to citat.. Na zbytek nehodlam reagovat, ale tvoje narceni z toho, ze neco prekrucuju, tady nehodlam nechat bez reakce. Pokud jsi tim myslel neco jineho, tak si to srovnej v hlave a pak neco napis, srozumitelne a jasne. Jestlize okazale a opakovane ignorujes pripominky ke svemu pravopisu a jeste to davas nekolikrat najevo, tak jsi na to patrne hrdy, pokud ne, pak jsi schizofrenni.
:))) to, ze ignorujem doslova provokativne narazky na moj pravopis znamena, ze som hrdy na to ako pisem ? :) zaujimava dedukcia. to ti vazne z toho toto vychadza ? :) btw, tento tvoj prispevok je uz dost mimo temu, nemyslis ? to je sila, takyto ludja :)Ano, pro normalni lidi ano. Pokud na to nejsi hrdy, tak tim odpornym zpusobem nepis! To je opravdu sila.
16.2.2005 12:28
Jiří Svoboda | skóre: 37
| blog: cat /dev/mind
| Prostějov
16.2.2005 22:53
Jiří Svoboda | skóre: 37
| blog: cat /dev/mind
| Prostějov
.
grep radeon*.o /var/log/packages/*nemělo by to být spíše
grep 'radeon\.o' /var/log/packages/*
Tématem jsou sice balíčky a ne regexpy, ale i tak:
* v shellu znamená libovolně dlouhá (i nulová) posloupnost libovolných znaků
* v regulárních výrazech grepu, sedu etc. znamená, že předchozí regulární výraz (zde písmeno n) se opakuje libovolně krát. Shellová hvězdička se pak zapíše jako .*
Navíc ten parametr grepu není v uvozovkách, takže pokud v aktuálním adresáři je soubor radeonblabla.o, shell to expanduje a grep dostane radeonblabla.o.
Správně by to tedy bylo
grep 'radeon.*\.o' /var/log/packages/*jestli to teda má matchovat radeoncokoliv.o. Pokud to má matchovat jenom radeon.o, tak buď
grep 'radeon\.o' /var/log/packages/*(předpředpředchozí příspěvek), nebo jednoduše
fgrep radeon.o /var/log/packages/*
PS: U rpm:
locate radeon.o | xargs -r rpm -qfPPS: Na oplátku mně můžeš vinadat za pravopis a můžeš mně taky vynadat za styl :o)
Nehledal jsem konkrétně radeon.o, ale jakýkoliv modul radeonxxxx.o (je to jedno).Pak je ten regexp špatně. Ale nejde o to že bych se v tom vyžíval, ale protože jsem kvůli podobné chybě kdysi ztratil něco času. Tak proč na to neupozronit. Ne? Pokud chcete vyhledat radeonxxxx.o, pak je dobře:
grep 'radeon.*\.o' ...
. = libovolný znak * = předchozí znak kolikrát chcete (třeba vůbec) \. = oporavdová tečka :)
takže už mlčííím.
23.2.2005 00:38
TomCat | skóre: 11
| blog: Proti proudu
| Praha-západ
Když to je těžké.. obsahuje-li článek nepřesnosti nebo dokonce chyby, je diskuse vhodným místem, kde na takové věci upozornit. Je dobré znát obě strany mince. I negativní reakce přeci mají smysl, když se drží tématu.
Problém v poslední době je tu ten, že se obvykle dvě strany debatujících hádají neustále o tomtéž a nikam to nevede. Ke všemu se pak v těch diskuzích ani nedá vyhledávat, když někteří neumí psát ani správně česky/slovensky.
Na druhou stranu mohlo být hůř -- kdyby se tu objevila debata o tom, jestli je lepší používat checkinstall pro balíčky kolem KDE nebo Gnome ;) (aneb -- hlavu vzhůru, ono se to časem zase vytříbí)
Ano, a to mě zajímá. Ale jaksi nenacházím reakce na článek, pouze hádky o velikosti bábovek...Když to je těžké.. obsahuje-li článek nepřesnosti nebo dokonce chyby, je diskuse vhodným místem, kde na takové věci upozornit. Je dobré znát obě strany mince. I negativní reakce přeci mají smysl, když se drží tématu.
A dost.. ne že by nebyly metriky na to, aby i tenhle paskvil dokázaly převést do podoby blízké normálním slovům, ale nemáš-li co říct, tak radši nepiš. A nebo si zaveď ještě vlastní sémantiku na jednotlivá známá slova, ať jsi fakt c00l l00s3r.
Schopnost psát správně je projevem určité kultivovanosti. Když někdo bude vykládat sebelepší věci, pokud je nedokáže říct správně, tak mu stejně nikdo nebude rozumět. V tomhle jsem zajedno s jm. A dost už té flame na téma pravopisu, dobrá? Názory obou táborů už tu zazněly.
nikde ma nikto neobmedzuje pisat tak ako chcem ja, tak to aj budem robit. je mi jedno ci sa v tom da alebo neda vyhladavat, ked njekto bude chcjet tak si to precita cele.Ano, a proto jsi hulvat a ignorant. Tyhle diskuse jsou tady proto, aby se v nich dalo vyhledat reseni problemu. Pokud nekdo przni pravopis jako ty, tak v nich vyhledavat mohou jenom lide, kteri pisi stejnou hotentotstinou, jako ty - takze asi pouze ty. Tobe je to jedno, ze se v te diskusi neda vyhledavat, no jiste, protoze jsi bezohledny k ostatnim. Precte si to cele - no jiste, za pul roku, az bude nekdo neco ve fulltextu hledat, tak si precte cele Abicko, aby neco nasel. Ty jsi vazne chytrak, to se jen tak nevidi. A jeste si ublizene stezuj na narazku na tvuj odporny pravopis. Parada.
cize vlastne znehodnocujes tuto diskusiu. ano, mas sa za co ospravedlnovat.Tobe se za nic neomlouvam ani omlouvat nehodlam...
16.2.2005 23:09
Jiří Svoboda | skóre: 37
| blog: cat /dev/mind
| Prostějov
Takze sem na konec diskuse (doufam definitivni) doplnim jen jedno (a doufam z toho nebude dalsi flame):
16.2.2005 19:40
17.2.2005 20:17