abclinuxu.cz AbcLinuxu.cz itbiz.cz ITBiz.cz HDmag.cz HDmag.cz abcprace.cz AbcPráce.cz
AbcLinuxu hledá autory!
Inzerujte na AbcPráce.cz od 950 Kč
Rozšířené hledání
×
dnes 20:22 | Pozvánky

Zítra proběhne jednodenní online konference InstallFest 2021. Na programu je celá řada zajímavých přednášek, workshopů a také stánků. Dění lze sledovat na Twitteru.

Ladislav Hagara | Komentářů: 0
dnes 13:11 | Nová verze

Byla vydána nová verze 6.5 v Javě napsané aplikace pro komplexní návrh rozmístění nábytku a dalšího vybavení v interiérech Sweet Home 3D. Vyzkoušet lze online verzi. Nedávno byly aktualizovány také knihovny nábytku.

Ladislav Hagara | Komentářů: 0
dnes 08:00 | Humor

Nové verze webových prohlížečů Firefox a Chrome byly vydávány každých 6 týdnů. Vývojářům Firefoxu se nelíbilo, že Chrome bude mít vždy větší číslo verze, proto se rozhodli vydávat nové verze Firefoxu každé 4 týdny. Aktuální stav: Firefox 86 byl vydán v 8. týdnu a Chrome 89 v 9 týdnu letošního roku. V kterém týdnu bude mít Firefox větší číslo verze než Chrome?

… více »
Ladislav Hagara | Komentářů: 23
dnes 07:00 | Zajímavý článek

Thom Holwerda popisuje na OSnews pracovní stanici Raptor Blackbird Secure Desktop (architektura POWER9) a své zkušenosti s ní včetně provozu desktopových aplikací.

Fluttershy, yay! | Komentářů: 1
dnes 06:00 | Nová verze

Byla vydána nová verze 1.54 editoru zdrojových kódů Visual Studio Code (Wikipedie). Přehled novinek i s náhledy a animovanými gify v poznámkách k vydání. Ve verzi 1.54 vyjde také VSCodium, tj. komunitní sestavení Visual Studia Code bez telemetrie a licenčních podmínek Microsoftu.

Ladislav Hagara | Komentářů: 2
včera 14:23 | Zajímavý článek

Check Point zveřejnil report, podle kterého NSA v roce 2013 vytvořila exploit pro operační systém MS Windows. Exploit sloužil k lokální eskalaci práv. O rok později tento exploit ukradli hackeři z Číny. Až po dvou letech byl exploit zveřejněn a Microsoft vydal aktualizaci. Jinými slovy, celé téma se točí o tom, jak NSA zřejmě přispěla ke globálnímu snížení kybernetické bezpečnosti. Celý příběh podrobně naleznete na checkpoint.com.

Max | Komentářů: 6
včera 09:11 | Komunita

Framework Flutter (Wikipedie) pro vývoj mobilních, webových i desktopových aplikací byl vydán ve verzi 2 a související programovací jazyk Dart (Wikipedie) byl vydán ve verzi 2.12. Proběhla online konference Flutter Engage. Videozáznam je k dispozici na YouTube. Canonical zde oznámil (Twitter, YouTube), že Flutter je výchozí volba pro vývoj nových aplikací pro Ubuntu.

Ladislav Hagara | Komentářů: 0
včera 09:00 | IT novinky

Společnost AMD na YouTube představila novou grafickou kartu AMD Radeon RX 6700 XT postavenou na architektuře RDNA 2. V prodeji bude od 18. března. Její cena byla stanovena na 479 dolarů.

Ladislav Hagara | Komentářů: 22
včera 08:00 | Nová verze

Uživatelsky přívětivý shell fish byl vydán ve verzi 3.2.0 Vylepšuje uživatelské rozhraní (doplňování, práce s historií úprav textu aj.), přidává napovídání argumentů dalších aplikací, zjednodušuje syntaxi (expanze rozsahů), opravuje chyby.

Fluttershy, yay! | Komentářů: 0
3.3. 16:00 | Zajímavý software

Steam Link je nově dostupný také pro 64bitový x86 Linux. Streamovat hry z výkonného počítače s nainstalovanou službou Steam lze tedy vedle telefonu, tabletu nebo televize i do počítače s Linuxem. Instalovat Steam Link lze z Flathubu. Od prosince 2018 je k dispozici Steam Link pro Raspberry Pi.

Ladislav Hagara | Komentářů: 0
Vzděláváte se formou hromadných online kurzů (MOOC)?
 (57%)
 (10%)
 (1%)
 (6%)
 (26%)
Celkem 114 hlasů
 Komentářů: 0
Rozcestník

Jaderné noviny - 1. 8. 2007

9. 8. 2007 | Robert Krátký | Jaderné noviny | 4717×

Aktuální verze jádra: 2.6.23-rc1. Citáty týdne: Ingo Molnar, Arjan van de Ven, Len Brown. Zpráva o stavu suspend a hibernace. Regulace využití paměti v kontejnerech. i386 a x86_64: zase spolu? Historické verze jádra v repozitáři gitu.

Obsah

Aktuální verze jádra: 2.6.23-rc1

link

Aktuální předverze je i nadále 2.6.23-rc1, během minulého týdne nebyly vydány žádné nové předverze. Do hlavního git repozitáře však bylo od vydání -rc1 přesto začleněno přes 500 patchů a -rc2 už má zpoždění. Šlo většinou o opravy, ale přibyla i "literární" dokumentace k Lguest, mechanismus, pomocí kterého může jaderný kód požádat o upozornění, má-li na něj být uplatněna preempce, nové konfigurační možnosti pro softwarové uspání a hibernaci a podpora framebufferu u AMD Geode LX. Kromě toho byla odstraněna podpora procesorů SuperH sh73180 a 7300 a zmizel i celý port pro arm26. Trochu změněno bylo API pro kontrolu zahlcení TCP.

Aktuální verze -mm stromu je 2.6.23-rc1-mm2. Mezi nedávné změny patří podpora více cílů netconsole, subsystém pro desku Sonics Silicon a několik oprav reiser4.

Starší jádra: 2.6.16.53 bylo vydáno 25. července s asi desítkou oprav. 2.4.35 bylo vydáno 26. července s několika backportovanými ovladači a pár opravami.

Citáty týdne: Ingo Molnar, Arjan van de Ven, Len Brown

link

Tty vrstva je jedním z mála míst v jádře, kterých se děsně bojím.

-- Ingo Molnar

Byl bych raději, kdyby lidem méně záleželo na tom, kdo napsal kód, který byl nakonec začleněn, a více na problému, který se tím vyřešil... Když někomu záleží na desktopu, měl by být rád, že je teď plánovač o hodně lepší - díky konkurenci dvou plánovačů, které se ve většině aspektů lišily jen o vlásek.

-- Arjan van de Ven

Tahle specifikace říká, že systémy, které se neumí automaticky po 15 minutách nečinnosti uspat, tu nálepku _nemohou_ získat. Nebude nálepka, nebudou ani vládní zakázky na počítače. Pokud Linux nedokáže poskytnout STR (Suspend-to-RAM, uspání do RAM), které by bylo funkční, běžně nasazované a ve výchozím nastavení zapnuté, tak budou mít naše plány na ovládnutí světa vážnou trhlinu.

-- Len Brown

Zpráva o stavu suspend a hibernace

link

Rafael Wysocki, aktuální správce jaderného kódu pro uspávání a hibernaci, sestavil dlouhý dokument popisující současný stav. Tento dokument je koncipován jako úvod do aktuálního (tj. v jádře 2.6.23-rc1) designu kódu, který implementuje uspávání (suspend-to-RAM a standby [uspání do RAM a pohotovostní režim]) a hibernaci. Stav, známé problémy a vývojové plány. Je to na dlouhé čtení, ale pokud vás tento subsystém zajímá, tak to stojí za to.

Regulace využití paměti v kontejnerech

link

"Kontejnery" je termín označující odlehčený přístup k virtualizaci, při kterém běží všechny hostované systémy na jádře hostitele (na rozdíl od běhu s vlastními jádry při využití celého virtuálního stroje). Kontejnerová technika bývá při běhu efektivnější, ale jsou s ní spojeny specifické problémy; protože všechny kontejnery běží na stejném jádře, je potřeba vytvořit celou řadu interních bariér, které dají každému kontejneru iluzi, že má celý stroj pro sebe. Přidávání těchto bariér do linuxového jádra probíhá už několik let - různé projekty, které se v této oblasti angažují, připravují sadu rozhraní, kterou by mohli všichni používat.

Důležitou součástí kompletní implementace kontejnerů je regulace zdrojů; bylo by těžké udržovat iluzi o samostatném stroji pro každý kontejner, kdyby jeden z těchto kontejnerů zahlcoval celý systém. Rozsáhlým patchům pro správu zdrojů se v minulosti dostalo chladného přijetí, ale korektní implementace založená na systému kontejnerů procesů by mohla být do jádra přijata. Skupinové plánování pro CFS je možné brát jako jeden z druhů správy zdrojů založených na kontejnerech. Ale je potřeba se postarat o mnohem více věcí než jen procesor.

Jedním z nejžádanějších zdrojů na mnoha systémech je paměť. Kontejner, který by rostl bez omezení a vytlačil ostatní kontejnery do swapu, by v konferenci linux-kernel nebyl moc populární. Ve snaze předejít takovým nepříjemnostem pracují Balbir Singh a Pavel Emeljanov na implementaci kontejnerového regulátoru paměti. Patch je teď ve čtvrté verzi.

Patch začíná jednoduchou abstrakcí: "počítadlo zdrojů" [resource counter], které je určeno pro použití s kontejnery. Bude fungovat s kterýmkoliv zdrojem, u kterého lze popsat obyčejnými celými čísly maximální povolené a aktuální využití. K dispozici jsou metody, které umožňují připojení těchto počítadel ke kontejnerovým objektům, a které zároveň umožní dotazování a nastavování z uživatelského prostoru.

Počítadla poslouží k monitorování využití paměti každého kontejneru. Využití paměti lze brát jako aktuální residentní sadu: počet residentních stránek, které si procesy v kontejnerech namapovaly do svých virtuálních adresních prostorů. Na rozdíl od některých dřívějších patchů se tento reguláror snaží sledovat i využití stránkové keše. Takže program, který je velmi malý, ale dává spoustu dat ze souborového systému do stránkové keše, bude vypadat, že používá hodně paměti.

Aby mohl sledovat využití stránek jednotlivými kontejnery, musí se regulátor napojit na nízkoúrovňovou stránkovou keš a kód pro vracení stránek. Také potřebuje místo pro ukládání informací o tom, ke kterému kontejneru je která stránka počítána. Proto byla vytvořena nová struktura:

    struct meta_page {
	struct list_head lru;
	struct page *page;
	struct mem_container *mem_container;
	atomic_t ref_cnt;
    };

Globální správu paměti mají na starosti dva seznamy řazené podle pravidla least-recently-used (LRU) [nejvíce dávno používané], protože se předpokládá, že stránky, které nebyly dlouho používány, bude nejbezpečnější odstranit, když paměť dochází. Když však přibudou kontejnery, přestává globální správa stačit. Takže struktura meta_page umožňuje vložit každou stránku na samostatné LRU seznamy pro jednotlivé kontejnery. Když pak proces běžící v kontejneru přibere stránku a způsobí, že kontejner narazí na svůj paměťový limit, musí jádro - pokud chce tento limit dodržet - vyřadit některé jiné stránky daného kontejneru. Pokud k takové situaci dojde, prohlédne se kontejnerový LRU seznam, aby se našly stránky patřící kontejneru, které lze vrátit, aniž by se musela procházet paměť, která s daným kontejnerem nesouvisí.

Struktura page v globální paměťové mapě má přidaný ukazatel na příslušnou strukturu meta_page. Přibyl také nový příznak stránky, který tu strukturu může uzamknout. Pro jaderné stránky žádná struktura meta_page není, ale vytvoří se jedna pro každou stránku uživatelského prostoru nebo stránku keše stránek - i pro procesy, které nebyly zařazeny do kontejneru (takové procesy jsou automaticky umístěny do výchozího, globálního kontejneru). Regulátor paměti má tedy značnou režii - pět nových ukazatelů (jeden ve struct page, čtyři ve struct meta_page) a jeden atomic_t pro každou aktivní stránku v systému - nic příjemného.

S tímto mechanismem může jádro implementovat základní kontrolu nad využíváním paměti v kontejnerech. Zbývá jeden menší problém: co když se jádru nepodaří stlačit paměť kontejneru pod limit? V takovém případě nastoupí obávaný out-of-memory killer [zabiják procesů při nedostatku paměti]; k dispozici je speciální verze OOM zabijáka, která své řádění omezuje na jediný kontejner. Některé procesy tedy nepřežijí, ale ostatní kontejnery by měly zůstat nedotknuty.

Jeden za zajímavých aspektů problému, který pravděpodobně není zcela dořešen, jsou stránky používané procesy z několika kontejnerů. Do této kategorie spadají mnohé sdílené knihovny, ale mohlo by tam patřit i využívání stránkové keše. Stávající kód přičte stránku prvnímu kontejneru, který ji používá. Pokud by byla stránka vybrána k odstranění, došlo by k odmapování ze všech kontejnerů; pokud pak tu stránku přivolá [faults in] jiný kontejner, bude mu od té chvíle připočítána. Takže za nějakou dobu by vracecí mechanismus mohl způsobit, že by se připočítávání sdílených stránek mohlo rozdělit mezi všechny kontejnery v systému - nebo by se hromadilo v jediném neomezeném kontejneru, pokud by takový existoval. Bude potřeba mechanismus pečlivě otestovat s různými zátěžemi, aby se dalo určit, jestli nebude mít za následek opravdové problémy. A vypadá to, že s testováním se sotva začalo.

Prozatím máme regulátor paměti, který, jak se zdá, zvládá základní věci, což je dobrý začátek. Určitě je vhodný pro použití s kontejnery, ale možná se projeví jako užitečný i v jiných situacích. Administrátor systému třeba nemusí chtít plnohodnotné kontejnery, ale mohlo by se mu hodit držet na uzdě paměťově náročné procesy (updatedb, zálohování atd.). Uživatelé by mohli, dejme tomu, přiškrtit OpenOffice.org, aby z paměti nevytlačilo všechny ostatní zajímavé věci.

i386 a x86_64: zase spolu?

link

Adresář arch ve zdrojových kódech jádra obsahuje všechen kód specifický pro jednotlivé architektury. Kódu je tam spousta, i když se vývojářská komunita už roky snaží při každé příležitosti věci zobecňovat. V současné době podporuje Linux 26 architektur, které tam mají své zastoupení, přičemž mnohé z nich obsahují několik podadresářů. Dvě z těchto architektur jsou i386 (původní architektura Linuxu) a x86_64 - 64bitový velký brácha i386. Tyto dvě architektury toho mají dost společného a usiluje se o sdílení kódu, kdykoliv to je možné. Přesto však zdrojové stromy zůstávají odlišné.

Podle některých vývojářů způsobuje rozdělení architektur problémy. Oprava chyby, kterou je nutné provést v jednom, se často týká i druhého - není však zaručeno, že oprava opravdu na obou místech proběhne. I nové funkce musí být přidávány dvakrát. Je poměrně snadné způsobit problémy v jedné architektuře, zatímco pracujete na té druhé. Vývojáři pracující na projektech specifických pro jednotlivé architektury - často se mluví o virtualizaci - nakonec mají více práce, když musejí držet krok se dvěma velmi příbuznými stromy. V reakci na podobné stížnosti byly v jádře 2.6.15 sjednoceny stromy 32bitové a 64bitové architektury PowerPC - a panuje všeobecná shoda, že to byl rozumný krok. U variant x86 však zatím ke spojení nedošlo.

Možná se však blíží změna: Thomas Gleixner a Ingo Molnar nedávno představili patch pro sloučení obou architektur. Ten patch je obrovský: má přes 9 MB a mění 1764 souborů. Je tolik vázán na aktuální stav jádra, že jej lze aplikovat jen na jediný konkrétní bod v git repozitáři. Není to však patch, který by měl být začleněn do hlavního jádra; jeho účelem je pouze ukázat, jak by vypadal výsledek. Pokud nakonec dojde na začleňování, provede se to jinak:

Dalším krokem bude vygenerování plně funkčního postupného přechodu z aktuálního kódu na kompletní strom arch/x86, který bude možné rozebrat a zkontrolovat. Výsledkem bude přibližně 1000 - 2000 commitů.

To je také trochu děsivé, takže vývojáři, kteří na věci pracují, se všemožně snažili, aby šlo změny začlenit bez obav. Sloučení nebudou doprovázet žádné úpravy kódu: ze stromu bude možné sestavit přesně stejné obrazy jádra před i po sloučení.

Patch vytváří architekturu nazývanou x86 a přesouvá do ní všechno ze stávajících dvou architektur. V těch několika případech, ve kterých mají obě architektury identickou kopii nějakého souboru, je v novém stromě vytvořen jen jediný soubor. Častěji však mívají stejně pojmenované soubory na stejných místech, jejichž obsah se liší. To jsou pak do nového stromu přesunuty oba soubory s příponami _32 nebo _64. Obě architektury například obsahují kernel/ioport.c; nová architektura x86ioport_32.c a ioport_64.c. Nakonec se používá hrstka triků, aby se zajistilo, že bude pro každou cílovou architekturu zkompilován ten správný soubor.

V mnoha případech (jestli ne ve většině) je v obou souborech hodně společného kódu - ten je tam však zatím ponechán. V tuto chvíli jde o to, aby byly oba stromy spojeny bez vlivu na výsledné jádro; to je patrně jediný způsob, jak zařídit přijetí tak velké změny. Jakmile dojde ke sloučení, začnou být příležitosti pro odstraňování duplicitního kódu lépe vidět - soubory budu většinou hned vedle sebe. Lze si představit armádu údržbářů, která se na tu práci vrhne - většinou by mělo jít o přímočaré změny. Až by to bylo hotové, měli bychom novou a naleštěnou sloučenou architekturu bez duplicitního kódu a všichni by se mohli radovat.

A nebo také ne. Andi Kleen vyjádřil svůj nesouhlas s takovou změnou:

Myslím, že to není dobrý nápad, protože bychom se nikdy nemohli zbavit starého smetí. Dle mého ne zcela skromného názoru je arch/x86_64 v mnoha směrech výrazně čistší než arch/i386 a já bych rád, aby to tak zůstalo. Obecně je také mnohem snazší hackovat na arch/x86_64 než na arch/i386, protože je možné jednodušeji testovat na regrese a vůbec je potřeba se starat o daleko méně nepořádku. A nevím, jak se toho u i386 zbavit - kromě vyházení těch starých věcí.

Andi, coby správce architektur i386 a x86_64, má v této debatě docela silné slovo. Jeho hlavním argumentem je, že rozdělení architektur umožňuje udržení množství starších věcí v i386 - což odpovídá běžné praxi při správě jaderného kódu. Kód, který podporuje pouze novější hardware, bývá mnohem čistší než kód, který se musí potýkat i se staršími kousky - ale odstraňovat podporu stále používaného hardwaru není možné. Takže je raději pro novější věci vytvořen nový subsystém, přičemž starší kód může být spravován samostatně, dokud se nevytratí. Klasickým příkladem je způsob implementace SATA ve vlastním subsystému, místo aby byla podpora přidána do kódu IDE. Andi, společně s několika dalšími vývojáři, tvrdí, že by podpora rodiny procesorů x86 měla být řešena stejně.

Vypadá to však, že většina prvotních účastníků diskuze s Andim nesouhlasí. Argumentují tím, že na rozdíl od IDE se 32bitová architektura v dohledné době nevytratí. Množství podivnůstek, které jsou skutečně pouze v i386, je považováno za poměrně malé. Linus tvrdí, že je snazší se starat o starší kód, když je součástí sdíleného stromu, než když je odstrčen do kouta. Podle debaty, která následovala po prvním oznámení, se zdá, že většina lidí považuje sjednocení stromů za správný postup.

Objevilo se i pár návrhů, aby byl patch zařazen už do 2.6.23, ale asi bude lepší, když to tak nedopadne. Ve 2.6.23 už je věcí hodně a tento patch je nový. Když se mu nechá jeden vývojový cyklus na práci, jen to pomůže. Kromě toho ještě nevznikl repozitář s těmi 1000 nebo kolika samostatnými commity.

Nejpodstatnější však je, že ještě neproběhla skutečná diskuze o sloučení. Přepracovat dvě architektury do jedné přes stížnosti jejich správce by hraničilo s nepřátelským převzetím kódu. Správci nemají absolutní vetovací pravomoce, ale ignorovat správce při začleňování takhle velkého patche by nemělo být tak snadné. Takže vývojáře sjednocené architektury x86 čeká ještě jeden velký problém: hezky vyřešili technické otázky a přesvědčili většinu vývojářské komunity, ale je v zájmu všech, aby našli způsob, jak přesvědčit i správce kódu, se kterým pracují.


Následující obsah je © KernelTrap

Historické verze jádra v repozitáři gitu

link

25. črc, originál

V nedávné diskuzi na LKML se mluvilo o importu kompletní historie linuxového jádra do git repozitáře. Linus Torvalds poznamenal: Vlastně jsem se o něco podobného pokoušel s BitKeeperem někdy na počátku aféry se SCO. Bylo dost náročné hledat všechny staré stromy a patche - jsou v různých formátech a na některé není spoleh. Uvažoval jsem o znovuvytvoření opravdu staré historie v gitu, ale i to je hodně práce. A pochopitelně to není moc užitečné - jen zajímavé z archeologického hlediska. Spousta informací o raných jádrech je shromážděna na oldlinux.org a Linus už z BK do gitu importoval kompletní historii od 2.5.0 do 2.6.12-rc2. Později mluvil o tom, proč je pro sestavování historie vhodnější git než BK:

Dobrá zpráva je, že git by se na vytváření historie hodil daleko více, protože můžete prostě importovat náhodné stromy a pak historii poskládat zpětně - zkusit je všechny poslepovat dohromady. A když najdete nový strom, prostě ho přilepíte místo jiného. To bylo s BK velmi složité (a BK nebyl obecně moc ku pomoci, když chtěl člověk udržovat několik nezávislých stromů, a nešlo s ním historii předělávat a udržovat několik verzí).

       

Hodnocení: 100 %

        špatnédobré        

Nástroje: Tisk bez diskuse

Tiskni Sdílej: Linkuj Jaggni to Vybrali.sme.sk Google Del.icio.us Facebook

Komentáře

Vložit další komentář

9.8.2007 07:12 pet
Rozbalit Rozbalit vše Diky
Kdyz uz jsem prvni ;-), tak bych chtel autorovi vyjadrit diky za jeho vytrvalou praci. Bez nej bych s mou anglictinou o novinkach v kernelu nic nevedel.

Jeste jednou: DIKY
9.8.2007 07:52 alium | skóre: 38 | blog: Category 1100
Rozbalit Rozbalit vše Re: Diky
Tez se pripojuji, je to skvele cteni !
Pavel Půlpán avatar 9.8.2007 09:31 Pavel Půlpán | skóre: 21 | Trutnov
Rozbalit Rozbalit vše Re: Diky
+1 Obzvlast jsem si s chuti precetl sekci o sjednocovani i386 s x86_64. :-)
An infinite number of monkeys typing into GNU Emacs would never make a good program.
Honza Balák avatar 9.8.2007 10:48 Honza Balák | skóre: 23 | blog: Jaxův linuxový zápisník | Předklášteří
Rozbalit Rozbalit vše Re: Diky
JJ, velmi zajímavé čtení.
<null>
Limoto avatar 9.8.2007 15:23 Limoto | skóre: 32 | blog: Limotův blog
Rozbalit Rozbalit vše Re: Diky
+10 ;-)
xsubway avatar 9.8.2007 09:03 xsubway | skóre: 13 | blog: litera_scripta_manet
Rozbalit Rozbalit vše Re: Jaderné noviny - 1. 8. 2007
... Pokud Linux nedokáže poskytnout STR (Suspend-to-RAM, uspání do RAM), které by bylo funkční, běžně nasazované a ve výchozím nastavení zapnuté, tak budou mít naše plány na ovládnutí světa vážnou trhlinu.

-- Len Brown
Asi je to pravda, ale ta formulace je jak z 007 :-D
12.8.2007 02:05 Olsen
Rozbalit Rozbalit vše Re: Jaderné noviny - 1. 8. 2007
No, špíš než 007 bych řekl EXCEL SAGA...
9.8.2007 09:07 Peto_MiG
Rozbalit Rozbalit vše Re: Jaderné noviny - 1. 8. 2007
Celkom vtipné.. že staré stromy sú zaujímavé len z archeologického hľadiska.. a začlenené sú jadrá od verzie 2.5.0 :-) Nie je to tak dávno čo 2.5.0 štartovalo novú éru jadra, a ja stále ešte považujem 2.6 za "nový" kernel.

Vtipné :-)
9.8.2007 11:34 Michal
Rozbalit Rozbalit vše Re: Jaderné noviny - 1. 8. 2007
+1 Na 90% serveru u nas si spokojene brouka 2.4
mkoubik avatar 9.8.2007 11:47 mkoubik | skóre: 5 | blog: lorem_ipsum | Praha 8 - Bohnice
Rozbalit Rozbalit vše Re: Jaderné noviny - 1. 8. 2007
Nedávno jsem si stáhnul freex 0.1.0, nebo jak se tenkrát linux jmenoval, a je to zajímavé čtení. Má to pár kB a je tam jenom to, co v jádře musí být.
10.8.2007 12:51 Michal Ludvig | skóre: 16
Rozbalit Rozbalit vše Re: Jaderné noviny - 1. 8. 2007
9.8.2007 16:06 Michal Kubeček | skóre: 71 | Luštěnice
Rozbalit Rozbalit vše Re: Jaderné noviny - 1. 8. 2007

Jak dlouho jste byl v komatu? :-)

Nie je to tak dávno čo 2.5.0 štartovalo novú éru jadra…

…něco přes šest let…

…a ja stále ešte považujem 2.6 za "nový" kernel

Po téměř třech a půl letech?. Pro srovnání: nejdelší interval mezi dvěma stabilními řadami ve starém modelu číslování byl dva a půl roku…

Limoto avatar 9.8.2007 15:22 Limoto | skóre: 32 | blog: Limotův blog
Rozbalit Rozbalit vše Re: Jaderné noviny - 1. 8. 2007
Až by to bylo hotové, měli bych novou a naleštěnou sloučenou architekturu bez duplicitního kódu a všichni by se mohli radovat.
Luboš Doležel (Doli) avatar 9.8.2007 16:21 Luboš Doležel (Doli) | skóre: 98 | blog: Doliho blog | Kladensko
Rozbalit Rozbalit vše Re: Jaderné noviny - 1. 8. 2007
Díky, opraveno.
10.8.2007 11:00 valesek | skóre: 10
Rozbalit Rozbalit vše Re: Jaderné noviny - 1. 8. 2007
Me se libil tento text k x86_64 a i386: "Nejpodstatnější však je, že ještě neproběhla skutečná diskuze o sloučení. Přepracovat dvě architektury do jedné přes stížnosti jejich správce by hraničilo s nepřátelským převzetím kódu. Správci nemají absolutní vetovací pravomoce, ale ignorovat správce při začleňování takhle velkého patche by nemělo být tak snadné. Takže vývojáře sjednocené architektury x86 čeká ještě jeden velký problém: hezky vyřešili technické otázky a přesvědčili většinu vývojářské komunity, ale je v zájmu všech, aby našli způsob, jak přesvědčit i správce kódu, se kterým pracují."

A pripomelo mi to par slov ministra Hackera ze serialu "Jiste, pane ministre" : "Kdysi jeden poradce prezidenta Nixona rekl : Podrzte je pod krkem a srdce i rozum se jiz pridaji"

:)))
10.8.2007 11:04 Michal Kubeček | skóre: 71 | Luštěnice
Rozbalit Rozbalit vše Re: Jaderné noviny - 1. 8. 2007
V Pratchettově verzi tam bylo něco jiného než krk…
David Heidelberg avatar 10.8.2007 16:44 David Heidelberg | skóre: 46 | blog: blog_
Rozbalit Rozbalit vše Re: Jaderné noviny - 1. 8. 2007
10.8.2007 14:54 Jiri
Rozbalit Rozbalit vše IDE se vytrati...
Na to, ze USB 1.1 je uz beznadejne out, jsem si uz zvykl. Na to, ze moje analogova TV karta bude sama o sobe brzo k nicemu, taky. A ted se mam dost rychle smirovat i s tim, ze mi zmizi IDE? Kam ten svet speje? Pripojim vubec nejaky muj ted uz pet let stary HW ke stroji, ktery si za tri roky koupim?
10.8.2007 18:48 trekker.dk | skóre: 71
Rozbalit Rozbalit vše Re: IDE se vytrati...
Kde jsi přišel na to, že ti zmizí IDE? IDE bude v jádře ještě hodně dlouho (vzpomeňme, jak dlouho mizel DevFS, který měl být jenom dočasné řešení)
Quando omni flunkus moritati
10.8.2007 19:14 Michal Kubeček | skóre: 71 | Luštěnice
Rozbalit Rozbalit vše Re: IDE se vytrati...
Já to pochopil spíš tak, že se bojí, že nebude podporované na základních deskách. Na druhou stranu, proč dělat takovou tragédii z toho, že do nového počítače nebude moci dát pět let starý disk?
10.8.2007 20:09 thingie
Rozbalit Rozbalit vše Re: IDE se vytrati...
Když ho mam ve skříni, jsou v něm nějaká data a co pak s nimi? Jistě, on by možná byl mrtvý, ale ztěžovat si to ještě tímhle...
10.8.2007 22:19 Michal Kubeček | skóre: 71 | Luštěnice
Rozbalit Rozbalit vše Re: IDE se vytrati...
To je pak ovšem moje blbost. Když si nechám data, která bych mohl potřebovat, na 5¼-palcové disketě (nebo zipce, ať nechodíme tak daleko do historie) a zahodím poslední mechaniku, na které bych je mohl přečíst, taky to bude především můj problém a ne nepodpory staršího hardware ze strany výrobců.
10.8.2007 21:28 Petr Pluháček | Ostrava
Rozbalit Rozbalit vše Re: IDE se vytrati...
Protoze zatimco nekteri 5let stary hardware povazuji za srot, nekde jinde (prispevkove organizace, atp.) muze byt povazovan za vykrik moderni techniky. Nejsem sice zastancem tahani historie za kazdou cenu, ale dokud se IDE disky vyrabeji, tak historii zdaleka nejsou. ;-) A Linux si vzdy drzel kredo, ze ma co nabidout i dychavicnejsim pocitacum :-)
10.8.2007 22:16 Michal Kubeček | skóre: 71 | Luštěnice
Rozbalit Rozbalit vše Re: IDE se vytrati...
Protoze zatimco nekteri 5let stary hardware povazuji za srot, nekde jinde (prispevkove organizace, atp.) muze byt povazovan za vykrik moderni techniky.

To je sice hezké, ale opravdu vám připadá pravděpodobné, že někdo, kdo je na tom tak špatně, si pořídí tak moderní desku, že na ní nebude IDE řadič?

ale dokud se IDE disky vyrabeji, tak historii zdaleka nejsou.

Dodnes se vyrábějí disketové jednotky a diskety a přesto spousta počítačů disketovou mechaniku nemá. PS/2 klávesnice a myši se také pořád vyrábějí (dokonce bych řekl, že jsou stále většinové) a přesto ve spoustě počítačů (i klasických PC, nejen notebooků) není PS/2 port. A tak by se dalo pokračovat.

A Linux si vzdy drzel kredo, ze ma co nabidout i dychavicnejsim pocitacum

Tak to zkusím to speciálně pro vás napsat ještě jednou ještě srozumitelněji. Tady nejde o to, co bude nebo nebude podporovat Linux, ten samozřejmě IDE disky ještě hodně dlouho podporovat bude. Jde o to, že není moc daleko doba, kdy většina nových základních desek nebude na sobě mít IDE řadič, ale pouze SATA. A moje poznámka zněla, že to není zase taková tragédie, protože považuji za krajně nepravděpodobné, že někdo bude chtít do počítače s takto moderní základní deskou dávat pět let starý disk (jednak kvůli velikosti, jednak kvůli spolehlivosti).

13.8.2007 15:37 Jiri
Rozbalit Rozbalit vše Re: IDE se vytrati...
Ano, mas pravdu, pochopil jsi to spravne. A souhlasim s Tebou. Ale ja mam ted dva IDE disky, z nichz jeden je pomerne novy a velky. Zaroven premyslim o koupi noveho stroje, nebot ten stavajici uz pomalu zacina nevyhovovat (ale mozna to budu resit koupi vice pameti a karty s USB 2.0 porty - opet asi zbytecna investice do stareho kramu), takze bych byl dost nerad, kdybych ty disky nemohl pripojit.
Luboš Doležel (Doli) avatar 13.8.2007 20:28 Luboš Doležel (Doli) | skóre: 98 | blog: Doliho blog | Kladensko
Rozbalit Rozbalit vše Re: IDE se vytrati...
Pokud vám o ten disk tak jde, tak si kupte SATA - PATA redukci.
Limoto avatar 13.8.2007 22:19 Limoto | skóre: 32 | blog: Limotův blog
Rozbalit Rozbalit vše Re: IDE se vytrati...
a nebo rovnou PATA řadič ;-)
14.8.2007 01:00 Michal Kubeček | skóre: 71 | Luštěnice
Rozbalit Rozbalit vše Re: IDE se vytrati...
Myslím, že v tuto chvíli se ještě není čeho bát, většina současných desek má na sobě pořád ještě jeden IDE řadič (i když obvykle už jen s jedním kanálem, tedy teoreticky na dva disky). A jak už podotkli kolegové, pořád je tu možnost si tam dát IDE řadič jako samostatnou kartu.

Založit nové vláknoNahoru

ISSN 1214-1267   www.czech-server.cz
© 1999-2015 Nitemedia s. r. o. Všechna práva vyhrazena.