Byla vydána verze 4.0 multiplatformního integrovaného vývojového prostředí (IDE) pro rychlý vývoj aplikaci (RAD) ve Free Pascalu Lazarus (Wikipedie). Přehled novinek v poznámkách k vydání. Využíván je Free Pascal Compiler (FPC) 3.2.2.
Podpora Windows 10 končí 14. října 2025. Připravovaná kampaň Konec desítek (End of 10) může uživatelům pomoci s přechodem na Linux.
Již tuto středu proběhne 50. Virtuální Bastlírna, tedy dle římského číslování L. Bude L značit velikost, tedy více diskutujících než obvykle, či délku, neboť díky svátku lze diskutovat dlouho do noci? Bude i příští Virtuální Bastlírna virtuální nebo reálná? Nejen to se dozvíte, když dorazíte na diskuzní večer o elektronice, softwaru, ale technice obecně, který si můžete představit jako virtuální posezení u piva spojené s učenou
… více »Český statistický úřad rozšiřuje Statistický geoportál o Datový portál GIS s otevřenými geografickými daty. Ten umožňuje stahování datových sad podle potřeb uživatelů i jejich prohlížení v mapě a přináší nové možnosti v oblasti analýzy a využití statistických dat.
Kevin Lin zkouší využívat chytré brýle Mentra při hraní na piano. Vytváří aplikaci AugmentedChords, pomocí které si do brýlí posílá notový zápis (YouTube). Uvnitř brýlí běží AugmentOS (GitHub), tj. open source operační systém pro chytré brýle.
Jarní konference EurOpen.cz 2025 proběhne 26. až 28. května v Brandýse nad Labem. Věnována je programovacím jazykům, vývoji softwaru a programovacím technikám.
Na čem aktuálně pracují vývojáři GNOME a KDE Plasma? Pravidelný přehled novinek v Týden v GNOME a Týden v KDE Plasma.
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ů.
Aktuální verze stabilního jádra je 2.6.16.6
2.6.16.7 2.6.16.8 2.6.16.9. Byla oznámena 19. dubna. Obsahuje opravu chyby, která umožňovala únik informací na některých AMD procesorech. Co se týče předchozích verzí, tak 2.6.16.6 přinesla poměrně dlouhou řádku oprav, zatímco 2.6.16.7
a 2.6.16.8 obsahovaly pouze po jedné bezpečnostní opravě.
Aktuální předverze je 2.6.17-rc2. Linus ji oznámil 18. dubna. Je tam hodně oprav, ale také zjednodušená forma patche pro předcházení hladovění scheduleru, vyladění algoritmu používaného při přetížení paměti [memory overcommit], odstranění zastaralých ovladačů blkmtd a qlogicfc, odstranění nespravovaných ovladačů Sangoma WAN, systémová volání splice() a tee() a dotazovatelné atributy sysfs. Vizte dlouhý changelog.
Stojí za zmínku, že prototypy metod splice() ve struktuře file_operations byly opět změněny. Verze tohoto týdne výpadá takto:
AbcLinuxu.cz
ITBiz.cz
HDmag.cz
AbcPráce.cz
ssize_t (*splice_write)(struct pipe_inode_info *pipe, struct file *out,
loff_t *offset, size_t len, unsigned int flags);
ssize_t (*splice_read)(struct file *in, loff_t *offset,
struct pipe_inode_info *pipe, size_t len,
unsigned int flags);
Nový je parametr offset, který popisuje, kde by měl proud I/O začít.
Od vydání -rc2 bylo do hlavního stromu začleněno několik desítek patchů.
Aktuální -mm strom je 2.6.17-rc1-mm3. Mezi nedávné změny patří začlenění ovladače pro ACPI dock, podpora virtuálního adaptéru i2c, pár úprav správy paměti, aktualizace ovladače TPM a nová verze knihovny zlib.
-- Dave Aitel
Vývojáři, kteří se zajímají o kontejnery a virtualizaci debatovali o rozhraních, pomocí kterých by virtualizovali přístup k různým systémovým zdrojům. Nikdo však nemluvil o virtualizaci přístupu k systémovému času. Tedy až doposud. S patchi pro virtualizaci času od Jeffa Dikea může mít každý strom procesů svou vlastní představu o tom, kolik je hodin.
Jeffův patch přidává do struktury úloh novou strukturu "time namespace" [časový jmenný prostor]. Ve výchozím nastavení sdílejí všechny procesy čas hostitelského systému. Ale nová volba (CLONE_TIME) v systémovém volání unshare() procesům umožňuje odpojení od systémového času. Po takovém volání je proces - a všechny potomky, které vytvoří - schopen mít vlastní hodnotu času. Pro nastavení hodnoty virtualizovaného času nejsou - na rozdíl od běžného systémového času - potřeba speciální práva.
Interně je virtualizovaný čas uložen jako obyčejný offset; kdykoliv proces požaduje aktuální čas, připočte se offset k aktuálnímu systémovému času a je vrácen výsledek. Tento přístup má výhodu v jednoduchosti a rychlosti; proces, který běží s virtualizovaným časem, také nepřijde o úpravy času, které provede například NTP. Na druhou stranu tato implementace nepodporuje možnost zmást procesy tím, že by se krutě zahrávalo s jejich představou o čase - například spuštěním času jinou rychlostí nebo dokonce pozpátku. Je však pravděpodobné, že tento nedostatek nebude trápit více než malé procento potenciálních uživatelů virtualizovaného času.
Jeffův cíl je urychlení systémového volání gettimeofday() v instancích User-mode Linuxu. Umožní-li jádro podstromům procesů mít vlastní hodnoty času, mohl by User-mode Linux prostě používat hostitelovo volání gettimeofday(), místo aby ho zachytával a pak implementoval sám. A protože gettimeofday() je jedno z nejčastěji používaných volání, mohlo by to znamenat výrazný rozdíl.
Aby však mohl z této změny User-mode Linux těžit, je potřeba ještě jedna změna. UML ovládá většinu procesů pomocí ptrace(); konkrétně zachytává a interpretuje systémová volání pomocí operace PTRACE_SYSCALL. Aby bylo gettimeofday() opravdu rychlé, je potřeba zařídit, aby toto konkrétní volání nebylo zachytávané. Takže Jeffův patch zároveň rozšiřuje ptrace() o operaci PTRACE_SYSCALL_MASK. Tato nová operace může nastavit bitmask značící, která systémová volání mají být zachytávána, a která mají být provedena bez zastavení.
Výsledkem je - při použití vhodně opatchovaného UML - volání gettimeofday(), které běží na 99 % rychlosti nativního procesu. To by mohlo být dost dobré na to, aby byl patch zařazen do rozrůstající se sady rozhraní podporujících virtualizaci a kontejnery.
Dan Bonachea nedávno nahlásil problém. Vypadá to, že má program, ve kterém zapisuje na stejný popisovač souboru více vláken současně. Čas od času něco z tohoto výstupu zmizí - přepsáno jinými vlákny. Náhodné vytrácení dat není obecně považováno za žádoucí a Dan tvrdí, že POSIX vyžaduje, aby byla volání write() thread-safe [pracovala spolehlivě i při současném spuštění více vlákny]. Takže by rád, aby byl problém napraven.
Andrew Morton rychle poukázal na příčinu tohoto chování. Podívejte se, jak vypadá implementace write():
asmlinkage ssize_t sys_write(unsigned int fd, const char __user *buf,
size_t count)
{
struct file *file;
ssize_t ret = -EBADF;
int fput_needed;
file = fget_light(fd, &fput_needed);
if (file) {
loff_t pos = file_pos_read(file);
ret = vfs_write(file, buf, count, &pos);
file_pos_write(file, pos);
fput_light(file, fput_needed);
}
return ret;
}
Tuto funkci nelze zamykat, takže dvě (nebo více) vlákna provádějící současný zápis mohou získat stejnou hodnotu pos. Obě pak zapíší svá data na stejné místo souboru a vlákno, které zapisovalo poslední, vyhraje.
Obalení celé funkce nějakým zámkem (například zámek inode) by problém vyřešilo a volání write() by bylo thread-safe. Cena takového řešení by však byla vysoká: další zamykací vrstva, kterou přitom téměř žádná aplikace nepotřebuje. Takové zřetězení write() operací by také znemožnilo současné zapisování do stejného souboru - schopnost, která se některým aplikacím může hodit.
Takže si někteří vývojáři nebyli jisti, jestli by toto chování vůbec mělo být napravováno. Není to věc, která by způsobovala potíže více než 99.9 % aplikací, a pro ty, které potřebují provádět tento typ současného zapisování, jsou k dispozici jiné možnosti. Například zamykání v uživatelském prostoru nebo použití volby O_APPEND. Proč tedy do jádra přidávat zbytečnou režii?
Linus odpověděl, že tu jde o "kvalitu implementace", a že pokud existuje nenáročné řešení, jak systém přimět, aby fungoval tak, jak to uživatelé očekávají, není důvod se tomu bránit. On sám navrhoval aplikovat zámek přímo na pozici v souboru. Jeho patch přidává mutex f_pos_lock do struktury file a využívá tento zámek k zřetězení jednotlivých použití a změn pozice v souboru. Tato změna způsobí zřetězení volání write(), zatímco další formy (asynchronní I/O, pwrite()) zůstanou nezřetězené.
Patch nebyl příliš komentován a v současné době už je začleněný. Jeho osud bude pravděpodobně záležet na tom, jestli bude předcházení problémů v takto neobvyklém případě považováno za dostatečně důležité ve srovnání s cenou, kterou za to zaplatí ostatní uživatelé.
V roce 2001 proběhla v rámci prvního Linux kernel summitu diskuze o bezpečnostních politikách. Na setkání bylo rozhodnuto, že není zájem o začlenění několika konkurenčních implementací, které byly v té době dostupné. Místo toho měli vývojáři, kteří se zajímali o bezpečnost, vytvořit obecné rozhraní, aby ho mohla využívat kterákoliv bezpečnostní politika. Výsledkem bylo API Linux Security Modules (LSM) - dlouhá řada háčků [hooks], které lze použít k zachycení téměř jakékoliv operace v jádře.
Minulý rok začali někteří vývojáři mluvit o tom, že by možná bylo lepší LSM z jádra odstranit. Od doby, kdy bylo LSM začleněno, se objevil pouze jediný bezpečnostní mechanismus, který jej skutečně využívá: SELinux. A protože SELinux má pouze jednoho uživatele, a lze o něm také uvažovat jako o poměrně obecném a samostatném bezpečnostním řešení, není jasné, jestli je rozhraní LSM vůbec potřeba. Diskuze se však minulý rok vytratila a o vyhození LSM se příliš nemluvilo.
Až do teď. V reakci na aktuální diskuzi o LSM háčcích poslal James Morris patch přidávající LSM na seznam věcí k odstranění. A ne za dlouho. Navrhované datum je tento červen - neboli jádro 2.6.18. Pokud patch projde, LSM velmi brzy zmizí.
Nejprve to vypadalo, že by projít mohl: několik vývojářů jádra se postavilo za odstranění LSM, přičemž nikdo nebyl proti. Jediné, na čem se neshodli, bylo datum odstranění, protože někteří považovali 2.6.18 za příliš brzy. Ostatní však argumentují tím, že diskuze z minulého roku by se měly počítat do obvyklé jednoroční lhůty pro podobný druh změny, a proto už není nutné déle čekat.
Člověk by si řekl, proč ten spěch. Kromě argumentu "jen jeden uživatel" je toho však ještě víc. Jamesův patch obsahuje tento text:
Takže LSM představuje pokušení, jak problémy řešit špatným způsobem. Kromě modulu bezpečnostních úrovní (který je, kromě jiného, považován za dveře otevřené dokořán bezpečnostním chybám, ale bez zájmu vývojářů) jde o epizody jako debata o realtime bezpečnostním modulu nebo Integrity Measurement Architecture [architektura pro měření integrity], z nichž ani jedna nebyla implementována jako bezpečnostní modul. Hlavním problémem je však možná toto:
Jádro 2.6 - záměrně - neposkytuje natahovatelným modulům přístup k tabulce systémových volání. Ale rozhraní LSM je skoro stejně dobré - dává natahovatelnému modulu příležitost zachytit téměř jakoukoliv operaci, kterou se jádro může pokusit provést. LSM háčky by se měly omezovat na udržování interních záznamů a vracení stavu povoleno/zakázáno jádru - ale neexistuje způsob, jak podobné omezení vynutit. Status GPL-only [pouze GPL] také LSM API příliš nepomáhá.
Zainteresovaným lidem se příliš nechce ukazovat prstem na společnosti, které rozhraní LSM zneužívají. Jedním z příkladů však může být modul pro zobecněnou správu událostí [kernel generalized event management], který byl minulý rok poslán do konference kernel-mentors. Při nahrání vyhodil KGEM právě nahranou bezpečnostní politiku a nainstaloval na její místo sebe. Pak začal dodávat události týkající se bezpečnosti (proprietární) uživatelské aplikaci, která prováděla rozhodování zaměřené na ochranu linuxových uživatelů před vzrůstající hrozbou virových útoků. Kolem implementace tohoto modulu bylo hodně otázek, avšak využití LSM k přebití aktuální bezpečnostní politiky a poskytnutí háčků proprietárnímu kódu bylo považováno za zvláště nechutné.
Přes to všechno i přes tlak vývojářů zatím není jasné, jestli nakonec LSM půjde pryč nebo ne. Zatím nepanuje shoda o tom, že by SELinux měl být chápán jako jediná Správná Bezpečnostní Politika; hodně potenciálních uživatelů se těžko srovnává s jeho komplikovaností a často jej prostě vypnou. Síla SELinuxu je zřejmá, ale snadnost použití věc jiná.
Existují i jiní uživatelé LSM, jen ještě nebyly předloženy k začlenění do hlavního jádra. Například:
Některé z dřívějších diskuzí však naznačují, že AppArmor možná bude mít do jádra těžkou cestu. Konkrétně používání názvů souborů jako základu bezpečnostní politiky bylo silně zpochybňováno. Na systému, který umí pevné a symbolické odkazy, vícero jmenných prostorů, sdílené podstromy a ještě více, není název souboru zdaleka jednoznačný. Proto SELinux využívá rozšířené atributy k aplikování značek přímo na soubory místo spoléhání na jejich názvy.
Vzhledem k tomu, že bezpečnost rozhodně není vyřešený problém, bylo by překvapivé, kdyby existoval jediný přístup, který by vyhovoval všem uživatelům. Takže je docela dobře možné, že se vynoří něco, co se kvalifikuje jako druhý uživatel, a zachrání LSM API před odstraněním.
Nebo alespoň udrží nějaké API. Pokud zůstane LSM, provedou pravděpodobně vývojáři změny, které ztíží jeho zneužívání. To může zahrnovat nalezení způsobů, jak omezit činnost LSM háčků, a poskytnutí možnosti zadrátovat do jádra při kompilaci jedinou bezpečností politiku. Takže ačkoliv je reálná šance, že budoucí jádra budou obsahovat LSM rozhraní, může se od toho dnešního dost lišit. Všichni vývojáři bezpečnostních modulů, kteří chtějí mít vliv na to, jakým způsobem se bude rozhraní vyvíjet, by se měli k diskuzi brzy přidat.
Následující obsah je © KernelTrap
19. dub, originál
Linus Torvalds připravil jádro 2.6.17-rc2 a vysvětlil, že ačkoliv obyčejně vydává -rc verze každý týden, tentokrát čekal kvůli cestování a všeobecnému klidu déle: Předpokládám, že odteď přejdu zpátky na týdenní rozvrh, i kdyby byl i nadále klid (což doufám). Linus také připojil krátké shrnutí změn:
Nic moc extra zajímavého, protože velkou část diffu zabírá aktualizace MIPS a obrovský diff z dlouho odkládaného odstranění ovladačů Sanoma WAN, které byly už dlouhou dobu nefunkční. Totéž platí pro ovladač qlogicfc (nahrazený ovladačem qla2xxx).
Díky tomu má diff tuny výmazů, i když ostatní změny moc velké nejsou. Ale jsou tam opravy netfilteru, další práce na splice a hromada náhodných věcí: usb, scsi, knfsd, fuse, infiniband...
Nástroje: Tisk bez diskuse
Tiskni
Sdílej:
Děkuju za další díl Jaderých novin, hlavně za část ohledně bezpečnostních mechanismů a LSM. Jiank pokud by se někdo z uživatelů SELinuxu chtěl vyjádřit, přemýšlím, jestli kamarádovi nasadit na comp OpenSuSE nebo Fedoru, FEdora se mi zdá lepší a navíc má SELinux (SuSE asi zase AppArmor), tak se můžete projevit a taky mi tím pomůžete :D
al-Quaknaa
Dost dobre nechapu, ze si nemuze strom udelat jednou a pak uz s tim neotravovat (a kontrolovat zavislosti "online"). Clovek si naklepe a odklepe co chce a nechce a pak ceka na vyhodnoceni zavislosti, pak musi zavislosti vyresit a zas ceka na vyhodnoceni zavislosti od tech zavislosti a pak je vyresi a zas ceka (a nebo si sledovat zavislosti rucne a vybrat si je sam, protoze system zavisly balicky sam neoznaci) a tak porad dokola
Máte na výběr ze dvou možností. Buď si zkontrolujete závislosti kliknutím na příslušné tlačítko (plus jednorázově na konci) nebo si zapnete automatickou kontrolu po každé změně. Z vašeho poněkud zmateného popisu jsem nepochopil, kterou variantu jste používal, ale zkoušel jste i tu druhou?
Ještě poznámka: ne, závislosti se opravdu nemohou vyřešit samy. Když vytvoříte omylem kolizi, jak by měl instalátor poznat, který z těch balíčků má instalovat. Když A závisí na B a vy zvolíte instalovat A a neinstalovat B, jak má instalátor poznat, jestli má nainstalovat B nebo neinstalovat A? Když program vyžaduje MTA a vy žádný nemáte, jak má podle vás instalátor poznat, který z nabízených chcete?
clovek chce Gnome desktop, ze kteryho tam sice system nepredvybere ani pulku, zato je tam pulka KDE
Ten základní výběr je desktopový systém s Gnome jako primárním desktopovým prostředím. Nikde není řečeno, že tam bude celé Gnome (pokud po něčem takovém toužíte, je to otázka jednoho kliknutí navíc) ani že tam nebude absolutně nic z KDE (je to distribuce pro rozumné uživatele, ne pro GUI šovinisty).
A pak si stejne stahl milion balicku navic, co sem vubec nechtel
Na základě svých zkušeností jsem skálopevně přesvědčen, že instalační program neinstaloval nic, co jste si buď sám nevybral, nebo na co vás výslovně neupozornil, že bude instalovat také. Ano, ty automatické závislosti jsou trochu nepříjemné, ale na konci výběru balíčků se vám zobrazí seznam, kde jsou všechny automaticky přidané balíčky vypsány, a vy tento seznam musíte potvrdit (nebo to samozřejmě odmítnout a výběr ještě upravit). Jestli nedáváte při konfiguraci instalace pozor, nestěžujte si na instalátor, ten za to nemůže.
docela neslusnost nepockat na me, kdyz jsem pryc, a po doinstalovani zapsat zavadec na disk a restartovat se
Považuji za velmi podstatnou výhodu, že instalační program vás nechá nakonfigurovat celou první fázi instalace a pak ji celou najednou provede. Do toho samozřejmě spadá i instalace zavaděče. Že jste si jeho konfiguraci nezkontroloval (a případně neupravil), to je jen váš problém, na instalační program to, prosím, nesvádějte.
P.S.: nechápu, proč své stesky na instalátor SuSE (nebo spíš na své problémy při jeho používání) píšete ke článku o něčem úplně jiném.
Ad 2a: Při jakémkoli předvýběru se stane, že tam budou chybět věci, které někdo považuje za "naprosto nezbytné", a naopak tam budou věci, které někdo považuje za "naprosto zbytečné" Kdyby nic jiného, tak už proto, že pro spoustu balíčků existují jak lidé, kteří je považují za "naprosto nezbytné", tak lidé, pro které jsou "naprosto zbytečné". Ono je to totiž subjektivní hodnocení. Právě proto máte možnost si ten počáteční výběr upravit tam, kde vám nevyhovuje.
Ad 2b: Opakuji, že ne každý je takový GUI-šovinista, aby musel ze svého počítače za každou cenu odstranit cokoli, co má něco společného s jiným desktopovým prostředím, než které primárně používá. Pokud jím jste, fajn, máte možnost si ten výběr upravit. Prostě vezměte na vědomí, že autoři toho předvýběru jsou tolerantnější a "desktop s Gnome" pro ně neznamená "desktop bez jakékoli stopy KDE", stejně jako "desktop s KDE" pro ně neznamená "desktop bez jakékoli stopy Gnome".
Ad 3: Pokud jste žádné balíčky navíc nepotvrzoval, pak tam žádné nejsou. Je samozřejmě logické, že odhad spotřebovaného místa je pouze orientační. Navíc záleží na tom, co vlastně přesně znamená ta hodnota 4300 MB, o které mluvíte.
Ad 4: Pokud jste konfiguraci zavaděče nenastavoval, pak jste byl asi spokojen s tím, co vám instalátor navrhnul. Pokud jste s tím spokojen nebyl, měl jste si ji přenastavit. Promiňte, ale nechápu, v čem vidíte problém: instalátor vám navrhnul nějakou konfiguraci zavaděče, vy jste ji beze změn odsouhlasil a ta konfigurace vám funguje; tak na co si vlastně stěžujete? Na to, že se vás na konfiguraci zavaděče zeptal před tím, než začal rozdělovat disk a instalovat RPM a ne až potom?
Ad 2b: pokud máte omezené místo, pak je logické, že nepoužijete defaultní výběr, ale ořežete ho. Nechápu, proč se tak divíte, že vám v takovém případě defaultní výběr nevyhovuje.
Ad 3: neodpověděl jste na otázku, nezbývá mi tedy, než ji zopakovat. Co přesně znamená ta vámi uváděná hodnota?
Ad 4: zavaděč se konfiguruje společně se vším ostatním ještě před definitivním potvrzením instalace. Tedy ve stejnou chvíli, jako vybíráte software, konfigurujete časovou zónu, defaultní runlevel, rozdělení disku atd. Stejně jako u všeho ostatního i u konfigurace zavaděče vám instalátor navrhne nějakou konfiguraci a vy máte možnost ji změnit. Pokud jste to neudělal, je to jen a jen váš problém a nechápu, proč to vyčítáte instalačnímu programu; zejména nechápu, na co si stěžujete, když sám uvádíte, že vám ten jeho návrh vyhovoval.
2b: Pochopte konečně, že "desktop s Gnome" neznamená "desktop, kde je jen Gnome (a nic jiného)". Oba standardní výběry jsou velmi podobné, pouze v jednom je trochu zdůrazněno KDE (a nastaveno jako defaultní WM), zatímco ve druhém Gnome. V obou jsou ale základy obou desktopových prostředí a několik dalších jednodušších window managerů.
3: Je mi líto, ale pořád jste neodpověděl. Až konečně řeknete, co přesně ta vaše hodnota 4300 MB znamená, tedy jak přesně jste k ní došel (du? df? nějak jinak?), můžeme se bavit o tom, čím ten rozdíl může být. Pro začátek pár tipů: jednak 1 GB není 1000 MB, jednak ne všechny soubory, které v systému máte, pocházejí z instalace. Např. u mne zabírá ~/.kde 13 MB a ~/.mozilla dokonce 168 MB… Také nezapomeňte na prostor rezervovaný pro roota, žurnál a nastavení velikosti bloků filesystému.
4: Říkám vám, že jste ho potvrdil (spolu se vším ostatním) a hlavně že jste si ho nakonfigurovat mohl, pokud byste o to stál; instaloval jsem ten systém tolikrát, že mi můžete věřit. Pokud nedáváte pozor a nevšiml jste si toho, je to jen a jen váš problém. Je tam nastavení defaultního jazyka a rozložení klávesnice, typu myši, rozdělení disku, výběr software, nastavení zavaděče, časové zóny a defaultní runlevel (snad jsem na nic podstatného nezapomněl). U všech těchto nastavení vám instalační program něco navrhne a vy máte možnost to buď nechat podle jeho návrhu nebo si to udělat po svém. Pak musíte zvolenou konfiguraci potvrdit a teprve potom se začne instalovat ((pře)rozdělí se disk, vytvoří se filesystémy a nainstalují se balíčky). Takže pokud si stěžujete, že jste nekonfiguroval zavaděč, je to stejné, jako byste si stěžoval, že jste nenastavil defaultní jazyk, nerozdělil disk nebo nevybral balíčky k instalaci.
3. Několik hintů, čím to může být, jsem vám naznačil - rezervované bloky, žurnál, soubory vzniklé až po instalaci (nemusejí být jen v domácích adresářích)…
4. Konfigurace zavaděče se provádí před tím, než systém začne instalovat balíčky. Tečka. Přesvědčí vás aspoň tohle, nebo mi budete tvrdit, že jsem si to nakreslil v GIMPu? (No dobře, nakreslil, ale jen ty šipky.)
Už mne to začíná unavovat, pokud dál chcete opakovat nepravdivá nebo zavádějící obvinění na adresu distribuce, která vám nepadla do oka, klidně si v tom pokračujte, všichni ostatní už snad pochopili, jak se věci mají.
2.5.2006 23:31
.so který žádný z nainstalovaných programů nevyužívá je k ničemu bez ohledu na preference. To se vám asi někdo snaží sdělit.
so souborech, je řeč o balíčcích. Pro kohokoli, kdo není GUI-šovinista, jsou balíčky s KDE knihovnami užitečné. Proto v defaultním výběru distribuce jsou, ne proto aby provokovaly ortodoxní gnomisty, kteří při každé zmínce o KDE vidí rudě.
Ale i kdyby šlo o jednotlivé so soubory, tak s vámi naprosto nemůžu souhlasit. Co třeba starší verze základních knihoven pro zpětnou kompatibilitu? Co 32-bitové verze knihoven pro kompatibilitu? A samozřejmě i další knihovny, které je dobré mít v systému k dispozici, přestože je zrovna teď žádný program nevyužívá.
Navíc, upřímně řečeno, ohledně toho, zda ty knihovny opravdu k ničemu potřeba nejsou, považuji za směrodatnější názor těch, kdo u SuSE distribuci dávali dohromady, než názor člověka, který sám přiznává, že má celé tři dny zkušeností a který sám dal najevo, že při instalaci nedával pozor, co vlastně nastavil…
9.5.2006 17:46
DjAARA | skóre: 32
| Praha|Náklo|Olomouc
9.5.2006 18:22
DjAARA | skóre: 32
| Praha|Náklo|Olomouc
3.5.2006 20:01
