Před 25 lety zaplavil celý svět virus ILOVEYOU. Virus se šířil e-mailem, jenž nesl přílohu s názvem I Love You. Příjemci, zvědavému, kdo se do něj zamiloval, pak program spuštěný otevřením přílohy načetl z adresáře e-mailové adresy a na ně pak „milostný vzkaz“ poslal dál. Škody vznikaly jak zahlcením e-mailových serverů, tak i druhou činností viru, kterou bylo přemazání souborů uložených v napadeném počítači.
Byla vydána nová major verze 5.0.0 svobodného multiplatformního nástroje BleachBit (GitHub, Wikipedie) určeného především k efektivnímu čištění disku od nepotřebných souborů.
Na čem pracují vývojáři webového prohlížeče Ladybird (GitHub)? Byl publikován přehled vývoje za duben (YouTube).
Provozovatel čínské sociální sítě TikTok dostal v Evropské unii pokutu 530 milionů eur (13,2 miliardy Kč) za nedostatky při ochraně osobních údajů. Ve svém oznámení to dnes uvedla irská Komise pro ochranu údajů (DPC), která jedná jménem EU. Zároveň TikToku nařídila, že pokud správu dat neuvede do šesti měsíců do souladu s požadavky, musí přestat posílat data o unijních uživatelích do Číny. TikTok uvedl, že se proti rozhodnutí odvolá.
Společnost JetBrains uvolnila Mellum, tj. svůj velký jazykový model (LLM) pro vývojáře, jako open source. Mellum podporuje programovací jazyky Java, Kotlin, Python, Go, PHP, C, C++, C#, JavaScript, TypeScript, CSS, HTML, Rust a Ruby.
Vývojáři Kali Linuxu upozorňují na nový klíč pro podepisování balíčků. K původnímu klíči ztratili přístup.
V březnu loňského roku přestal být Redis svobodný. Společnost Redis Labs jej přelicencovala z licence BSD na nesvobodné licence Redis Source Available License (RSALv2) a Server Side Public License (SSPLv1). Hned o pár dní později vznikly svobodné forky Redisu s názvy Valkey a Redict. Dnes bylo oznámeno, že Redis je opět svobodný. S nejnovější verzí 8 je k dispozici také pod licencí AGPLv3.
Oficiální ceny Raspberry Pi Compute Modulů 4 klesly o 5 dolarů (4 GB varianty), respektive o 10 dolarů (8 GB varianty).
Byla vydána beta verze openSUSE Leap 16. Ve výchozím nastavení s novým instalátorem Agama.
Devadesátková hra Brány Skeldalu prošla portací a je dostupná na platformě Steam. Vyšel i parádní blog autora o portaci na moderní systémy a platformy včetně Linuxu.
Máme za úkol někomu rychle a jednoduše vysvětlit, jak si na tom svém "Linuxu" nainstaluje jabber klienta psi.
aptitude install psi
yum install psi
urpmi psi
yast --install psi
Prakticky každá distribuce má vlastní balíčkovací systém a příkazy, které zařídí instalaci softwaru. Ovšem každý z nich dělá prakticky to samé, takže při podrobnějším pohledu zjistíte, že se yum
od urpmi
liší pouze v nepodstatných detailech (jako že jeden je v Pythonu a druhý v Perlu).
Za vznikem a současným vývojem stojí společnosti Connectiva a Canonical (Ubuntu), ale Smart není určen pouze pro distribuce založené na Debianu. Naopak, mezi přispěvateli nalezneme osoby jako Seth Vidal (autor yumu), nebo Michael Vogt (autor Synapticu). Správce balíčků Smart, který vznikl na základě zkušeností s projektem apt-rpm
, si stanovil na první pohled nesplnitelný cíl. Poslat všechny ty yum
y, apt-get
y, nebo urpmi
do důchodu a alespoň malinko sjednotit ten dnešní linuxový instalační guláš. Jeho domovská stránka labix.org/smart nabízí odkazy na balíčky (sebe sama) pro mnoho distribucí. Část z nich (SUSE, Debian, Mandriva nebo Ubuntu) už Smart nabízejí ve svých repositářích.
Protože se jedná o nástroj určený pro více distribucí, udělal jsem test na Ubuntu Feisty Fawn a, jelikož nejvíce ohlasů na Smart jsem měl od uživatelů OpenSUSE, také na OpenSUSE 10.2. Obě distribuce běžely ve VMware, přičemž SUSE mělo tu výhodu, že to byl přímo nakonfigurovaný obraz z mono-project.com.
Je poněkud zvláštní, že přestože vývoj Smartu sponzoruje Canonical, tak v Ubuntu zatím jako výchozí není, stejně jako v distribuci Mandriva (která odkoupila původního autora, společnost Connectiva). Paradoxně největším současným uživatelem tohoto balíčkovacího systému jsou (alespoň jak vyplývá z četnosti materiálů na webu) uživatelé distribuce SUSE. Na suseportal.cz/smart o něm nalezneme velice pochvalný článek.
V příkazové řádce stačí napsat smart
a program vypíše seznam možných parametrů. Pokud máte raději grafické rozhraní, napište smart --gui
. Bohužel se aplikace neinspirovala třeba u Aptitude, který je možné spustit bez rootovských práv a získat je až v okamžiku, kdy se rozhodneme zasáhnout do systému. Vzniká tak nekonzistence v tom, že nástroj v konzolové verzi určité funkce umožňuje i bez práv roota, ale v grafické verzi ne. Na druhou stranu jí trpí snad každý grafických správce balíčků, který jsem kdy viděl.
V SUSE se při prvním spuštění navíc ptá na to, zda se má daný repositář zahrnout do seznamu kanálů.
Jak je vidět, tak Smart přebírá konvence pojmenování kategorií z jednotlivých distribucí.
Pokud se srovná základní operace hledání s výchozím Adeptem z Ubuntu, působí Smart pro začátečníka trochu těžkopádně. Například výsledky hledání balíčků ve Smartu sice přesně odpovídají tomu, co získáme příkazem smart search psi
nebo aptitude search psi
, ale přístup Adeptu mi přijde pro méně zkušené uživatele vhodnější.
Ovšem co je ještě horší, je nepodpora regulárních výrazů. I nezkušeného uživatele je možné naučit psát místo psi
^psi$
pro omezení výpisů, ne tak ve smart
u. Je nutné poznamenat, že si v tomto případě nemá konzolová verze s grafickou co vyčítat.
Instalaci je možné provést z kontextového menu (vynecháme-li konzolovou možnost smart install psi
).
Potom se nám sice zobrazí dialog pro potvrzení závislostí, ale jinak je to vše. Snad jenom pozornější uživatel si všimne, že se mu změnila ikona u psi.
A teprve po stisknutí tlačítka v levém horním rohu (Apply marked changes) dojde k zobrazení podobného okna se zobrazením všech provedených jmen a ke stahování.
A instalaci (nesmíte ovšem zapomenout vypnout cokoliv, co si zamkne databázi dpkg
- třeba Adept - jinak místo povedené instalace dostanete tuto chybovou hlášku). Nepříjemné je, že se balíčky neuloží, takže je nutné je stahovat znovu.
Při spuštění smart --gui
z konzole se v ní zobrazuje postup instalace, takže je možné se na první pohled přesvědčit, že smart využívá pouze služeb dpkg
(respektive rpm
). Bohužel mě trochu zarazily volby --force-depends
(všechny potíže se závislostmi přepne na varování) a --force-remove-essential
(povolí odstranění nezbytných balíčků).
A zde přichází velká bolest Smartu, která je zmíněna i na výše uvedené wiki Ubuntu. Neumí reverzní závislosti, což je pro člověka navyklého na aptitude
velká chyba. Takže, pokud chceme psi zase odinstalovat, zůstane nám v systému knihovna libqca1c2
, pokud si ji neodinstalujeme ručně.
Protože test probíhal na alfa verzi Ubuntu, nechtělo se mi stahovat celých přibližně 416MB balíčků, takže jsem jen porovnal výstupy z obou aplikací. Jak Adept, tak Smart nabídly stejné počty a velikosti balíčků, takže tato vlastnost pracuje na jedničku.
Další vlastnosti už spíše letecky.
Kanál je v terminologii Smartu způsob, jak získávat informace z repozitáře. Jejich počet je úctyhodný (apt-deb, apt-rpm, databáze programu dpkg, rpm metadata (yum), urpmi formát a podobně). Pokud chceme získat seznam aktuálních balíčků, je nutné provést update.
Ovšem Smart toho nabízí více:
Více toho je na na stránce labix.org/smart/features.
Smart je bezpochyby velice zajímavý počin. A protože za ním stojí kvalitní lidé, je docela pravděpodobné, že se postupem času stane nejpoužívanějším nástrojem pro instalaci softwaru v Linuxu. Na první pohled je vidět, že vývoj začal na debianních systémech, čemuž odpovídá i použitá terminologie (update je stažení aktuálního seznamu balíčků, upgrade je instalace novějších verzí, ale volba dist-upgrade
v něm obsažena není). Stejně tak ovládání grafické verze připomíná nástroje z Debianu (Aptitude nebo Synaptic).
Z hlediska debianních systémů toho Smart příliš nového nenabízí. Na druhou stranu zase má vlastnosti, které například Aptitude chybí. Kritickou vlastností je ovšem chybějící správa reverzních závislostí.
Do distribuce SUSE přináší jednoduše použitelný konzolový správce softwaru ve stylu Debianu, protože spuštění nativního správce balíčků Yast trvá (alespoň pro mě) neskutečně dlouhou dobu a to jak v grafické, tak v textové verzi. Takže pomocí smartu můžeme i v SUSE instalovat balíčky pomocí smart install software
a nemusíte čekat několik desítek sekund na to, než se zpracují metainformace nativního nástroje. Navíc mi použítá verze pro SUSE (z Guru's RPM repository) přišla daleko lépe integrovaná do systému než ta pro Ubuntu.
Pro distribuci Mandriva je také Smart dostupný. Dokonce je možné si nechat vygenerovat zdroje pro Smart na stránce easyurpmi.zarb.org/?language=cz.
Nástroje: Tisk bez diskuse
Tiskni
Sdílej:
Portage je AFAIK nejvyspelejsi Linuxovy balickovaci system, ted je rec o Gentoo, ne o Debianu =)Ať to čtu jak to čtu, tak tomu rozumím tak, že je Portage nejvyspělejší balíčkovací systém v Gentoo, což asi nebude to, co jsi chtěl říct
aptitude
.
Portage je AFAIK nejvyspelejsi Linuxovy balickovaci systemSystém, který neumí řešit reverzní závislosti (klidně odinstaluje potřebnou knihovnu, a čeká, že si to uživatel spraví přes revdep-rebuild, až zjistí, že to má rozbité), který neumí řešit konflikty souborů (klidně přepíše soubor souborem z jiného balíčku, a pak ho odmaže při mazání prvního balíčku) ani neumí generovat automatické závistlosti (pokud na to tvůrce ebuildu nepřijde sám a ručně nepřidá), a který je na dotaz reverzní závislosti 1000× pomalejší než RPM. rozhodně nelze řadit ani mezi vyspělé systémy. Za sebou nechává už jen pkg ze Slackware. Tím nenapadám jeho kompilační a konfigurační schopnosti, ale co se týče balíčkovacích schopností, přišly mi spíše zoufalé. Nevím, zda se v posledních letech něco změnilo, ale protože mi přišel už pětačtyřicátý duplikát jedné z chyb portage, na kterou jsem narazil v roce 2003 při psaní revdep-rebuild, tak pochybuji. A smart je pouze nadstavba nad balíčkovacím systémem.
Portage je AFAIK nejvyspelejsi Linuxovy balickovaci system,Omyl, je to Paludis
Nepříjemné je, že se balíčky neuloží, takže je nutné je stahovat znovu.Pokud ten Smart chce nainstalovat balíček voláním dpkg, stejně ho AFAIK musí někam uložit. Zajímalo by mě, co autory vedlo k tomu tam ten balíček nenechat. Představte si, že by došlo k chybě při instalaci 150MB velkého balíčku... to by jednoho asi docela nakrklo.
Smart je ve verzi 0.xx a bude se snad jeste zlepsovat
man debfoster
root@kubuntu610:~# apt-get autoremove ... The following packages were automatically installed and are no longer required: nvidia-kernel-common linux-headers-2.6.17-10 The following packages will be REMOVED: linux-headers-2.6.17-10 nvidia-kernel-common ...
lenovo:~# apt-get autoremove E: Invalid operation autoremove lenovo:~#
deb http://ftp.cz.debian.org/debian jessie main contrib non-free
fred@fred:~$ sudo apt-get autoremove
Reading package lists... Done
Building dependency tree
Reading state information... Done
0 upgraded, 0 newly installed, 0 to remove and 0 not upgraded.
fred@fred:~$
deb http://ftp.cz.debian.org/debian jessie main contrib non-free
cezz@dm6:~$ sudo apt-get install mc
Reading package lists... Done
Building dependency tree
Reading state information... Done
mc is already the newest version.
0 upgraded, 0 newly installed, 0 to remove and 0 not upgraded.
Naozaj nefunguje apt-get remove
a nasledne
apt-get autoremove
namiesto jedneho jednoducheho
aptitude remove
?
V ubuntu man stranke pre apt-get som autoremove nenasiel napriek tomu ze funguje (teda funguje ako funguje, chcel mi odinstalovat polovicu systemu.. a rozhodne nie nepotrebne veci) a v debiane tato feature nie je vobec.
Ten nástroj jsem nikdy nepochopil
apt-get install aptitude install apt-get remove aptitude remove apt-get update aptitude update apt-get upgrade aptitude upgrade apt-cache search aptitude search ...Skutečně nemyslím, že člověk, co zvládne
apt-get
bude mít s aptitude
výraznější potíže apt-file ...
...Když někoho vidím, jak kvůli instalaci balíčku pouští nějaký klikadlo, otevírá se mi pacman v kapse. Prostě budeme podporovat lenost a potenciálně nebezpečné chování uživatelů, jen aby se cítili spokojení (oni a jen oni)...
Mohl byste mi prosím prozradit, proč je uživatel líný, když místo CLI verze správce balíčku provádí tuto činnost v GUI verzi?
je líný měnit svoje návyky ze systému, ze kterého přechází, odkdy se v systémech z Redmontnu tak intenzivně pracuje v textovém režimu? Zřejmě to souvisí s tím, že UNIX byl kdysi primárně určen ke zpracovávání textu, a systémy z Redmontnu mají jako povinné (skoro, ale bez něj jsou takřka neovladatelné) vybavení polohovací zařízeníNo počkejte, přeci nemůžete na základě toho, jak si někdo spravuje balíčky, tvrdit, že je líný měnit své návyky (bylo-li co měnit)? To přeci vůbec neznamená, že v jiných případech CLI nevyužívá. Nevidím jediný rozdíl mezi tím, jestli napíšu aptitude install wget, spustím aptitude a v něm si instalaci wgetu vyberu a nebo použiju Synaptic. Vy jste si evidentně vybral to první (pacman), ale roztrubovat tu, že kdo nepoužije CLI je líný měnit návyky, to vám trochu ulétlo, ne?
Když někoho vidím, jak kvůli instalaci balíčku pouští nějaký klikadlo, otevírá se mi pacman v kapse.Linux a OSS je o svobodě. Když chce někdo klikat, ať si spustí
smart --gui
a kliká. Když chce být v konzoli, tak prostě napíše smart install
. Ostatně, co se konkrétně naučíš při ruční a grafické instalaci balíčku? Já v tom, z hlediska znalostí, vůbec žádný rozdíl nevidím (ano, konzole je produktivnější) Všechno, co musíš znát - repository, updaty, ... - se týká grafické i konzolové instalace stejně.
... Ostatně, co se konkrétně naučíš při ruční a grafické instalaci balíčku? ...Zrovna u instalace balíčku toho moc nebude, to je pravda, ale minimálně si uživatel začne zvykat, že pracuje na UNIX-like systému, kde je Xserver nadstavbou, a zvykne si, že systém je ovladatelný z textového režimu, však UNIX vzniknul, je (a doufejme, že i bude) navržen jako plně ovladatelný a použitelný v textovém režimu. Pokud se uživatel naučí pouštět Xwindow aplikace s rootovským oprávněním, tak se dočkáme toho, že pro chmod bude startovat konqueror (chmod souboru s root právy)... a to je hodně hloupý nápad.. To je totéž, jako kdybys šoupnul svoje nádobíčko lvovi do tlamy a třel mu rozkrok mokrou žínkou. Naprosté šílenství.
že pracuje na UNIX-like systému, kde je Xserver nadstavbou, a zvykne si, že systém je ovladatelný z textového režimuJenže uživatelům je nějaký Unix úplně šumák, stejně jako mě je šumák mechanismus vstřikování paliva do válců, nebo formát mikroinstrukcí mého SATA řadiče na desce. A tak je to taky správné, protože nikdo nemůže vědět všechno a dnes se dostáváme do stavu, kdy jsme rádi, že víme aspoň něco
Ostatně, nevím o tom, že by slovo unix znamenalo systém ovladatelný pouze z konzoleSlovo UNIX (Unics) je dítkem Kernighana, jako narážka na Multics (neefektivní systém z doby kdy UNIX vznikal). UNIX byl navržen jako systém pro zpracování textu. toto vlákno už neobohatím, a doufám že se flame nepřesune do tohoto zápisu, ve kterém se snažím objasnit svůj názor.
no já si zas myslím, že za úspěchem *buntu skutečně stojí hlavně ta klikavost...Mě připadá *buntu jako nejméně klikací z "velkých" distribucí (spolu s Debianem). Pokud chcete nastavit takřka cokoliv mimo nástroje desktopových prostředí, tak prostě musíte do CLI nebo aspoň ručně editovat konfiguráky. To je podle mě všecko, jenom ne klikavost.
Kdysi se mi povedlo tady na ábíčku nechtěně rozpoutat diskuzi, ve které jsem byl pranýřován za lenost, snahu klikat a pokusil jsem se trošku věštit, kam se linux ubírá (posuďte sami kdo se trefil blíž: http://www.abclinuxu.cz/forum/show/103987)V té diskusi vystupuješ jako líný BFU, nedivím se Dolimu a spol, že do tebe šli tvrdě.
JNejběžnějším uživatelům je jedno, jestli si balíček zaškrtnou v Synapticu, Adeptu, Yumexu nebo v čemkoli jiném a jestli je balíček typu RPM, Deb nebo třeba tar.gz.To není pravda. V LE se tímto poměrně dost trápíme. V Linuxu neexistuje snadný způsob, jak popsat instalaci balíčku tak, aby to bylo platné alespoň pro nejrozšířenější distribuce.
smart
vůbec nezkoušel?
I kdyz jsem priznivce apt-get, tak jsem rad ze smart jde cestou sjednoceni. Sice by udelali lepe, kdyby apt dali na vsechno, ale kdyz jednou bude smart a jednotne balicky, tak pak installace budou v pohode a velke firmy budou mit balicky uz pro vsechno.
Sice by udelali lepe, kdyby apt dali na vsechno
Ne a ne. Smart pouze nabizi jednotnou spravu balicku. Zadne jednotne balicky. To ze na dvou distrech jede stejny Smart, neznamena, ze lze balicky michat…ale kdyz jednou bude smart a jednotne balicky, tak pak installace budou v pohode a velke firmy budou mit balicky uz pro vsechno.