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ů.
Na čem pracují vývojáři webového prohlížeče Ladybird (GitHub)? Byl publikován přehled vývoje za duben (YouTube).
Aktuální stabilní verze řady 2.6 je 2.6.19.1, vydaná 11. prosince. Obsahuje docela dost oprav, včetně dvou týkajících se bezpečnostních problémů.
Během minulého týdne nevyšly žádné předverze, protože pořád probíhá začleňování nových patchů do 2.6.20. Do hlavního git repozitáře se jich dostala slušná řádka; shrnutí níže.
Aktuální verze -mm stromu je 2.6.19-mm1. Mezi nedávné změny patří nové debugovací funkce pro kmap_atomic(), podpora ovladačů v uživatelském prostoru a mechanismus pro přenos veřejných klíčů pro eCryptfs. Především se však -mm výrazně zmenšil, protože se patche přesouvají do hlavního stromu.
Adrian Bunk vydal 2.6.16.35 s několika desítkami oprav (jedna řeší bezpečnostní problém). Také vydal 2.6.16.36-rc1 s několika dalšími patchi.
Pokud to skutečně chceme udělat, tak bychom místo chození kolem horké kaše ty binární moduly měli rovnou zakázat.
Nakonec jde o to, jestli máme nebo nemáme dost síly, abychom je dotlačili k tomu, aby se chovali tak, jak chceme - jsme připraveni je přinutit, aby dostáli svému slovu?
To současné polovičaté řešení, kdy pouze jeden modul po druhém nutíme exportovat EXPORT_SYMBOL_GPL, nedává příliš smysl - bylo by lepší, kdybychom se už nějak rozhodli; ať tak nebo tak.
-- Martin Bligh
Varujte lidi 12 měsíců dopředu (čas na rozmyšlení toho, co budou dělat, promluvení s právnickým oddělením atd.) a pak nechte jádro natahovat jen moduly označené jako GPL.
K tomu bych se přikláněl. Pomohlo by to těm, kdo se snaží získat specifikace zařízení, a kdo přesvědčují organizace, aby své ovladače vydaly jako open source.
Patch, který vyplivne zprávy z logu při načtení takového modulu, aby byli lidi aspoň dopředu varováni, udělám za chvilku.
V době psaní minulého shrnutí teprve proces začleňování patchů do 2.6.20 začínal. Linus se od té doby nenudil; některé ze zajímavějších věcí jsou popsány níže.
Uživatelské změny:
Vývojářské změny:
Začleňování pokračuje, takže čekejte zařazení pár dalších věcí, než 2.6.20 dostanou konečnou podobu.
Některé patche se do jádra dostanou skoro přesně takové, jak vypadaly původně. Jiné musí projít různými změnami. Rekordmanem v počtu vývojových verzí je možná DevFS; Richard Gooch zrovna vydal 157. revizi, když byl tento osudem prokletý subsystém zařazen do jádra 2.3.46. V porovnání s tím je Jevgenij Poljakov zatím na začátku s kevent č. 26; přesto už mu to musí připadat jako dlouhá doba.
V tomto případě však může dlouhá doba znamenat, že systém funguje tak, jak má. Subsystém kevent je zásadní přírůstek k linuxovému API systémových volání. Jak tam jednou bude, bude nutné jej podporovat navždy. Přidání rozhraní kevent s chybami nebo takového, které neposkytuje nejlepší možný výkon, by byla vážná chyba. Nikomu se nechce za pár let navrhovat a implementovat nové rozhraní, zatímco by bylo nutné neustále podporovat i to staré. Takže dává smysl postupovat pomalu a ujistit se, že bylo vše dobře promyšleno.
Počet lidí komentujících patche kevent je poměrně nízký; z nějakého důvodu to vypadá, že mnoho jindy hlasitých vývojářů nemá, co by k tomuto API řeklo. Naštěstí se o toto rozhraní začal zajímat Ulrich Drepper (správce glibc) a tvrdě prosazoval změny, o kterých byl přesvědčen, že jsou nezbytné. Člověku připadá, že už se Ulrich a Jevgenij mají za poslední měsíc navzájem tak akorát. Ale jde jim ke cti, že se drží své práce. Ulrich zatím novou verzi API nekomentoval. Jasně však odráží některé věci, které požadoval.
Zatímco Jevgenije zajímalo, jak dostat události z jádra, Ulrich se staral o výkon a stabilitu. Takže chtěl, aby existoval způsob, jak by mohly vícevláknové programy zrušit vlákna, aniž by se ztratila informace o tom, které události už byly zpracovány. Kdykoliv je to možné, tak chce události zpracovávat bez zásahu jádra. A velmi tlačil na to, aby byly hodnoty vypršení v absolutním formátu. Jevgenij většinu těchto přání splnil (i když občas se zaťatými zuby).
Stále je možné dostat kevent popisovač souboru otevřením /dev/kevent, ale není to už jediný způsob. Systémové volání kevent_ctl() je i nadále používáno ke správě událostí:
AbcLinuxu.cz
ITBiz.cz
HDmag.cz
AbcPráce.cz
int kevent_ctl(int fd, unsigned int cmd, unsigned int num,
struct ukevent *arg);
S kevent_ctl() může aplikace přidávat požadavky na události, odstraňovat je nebo je na místě upravovat. Nová operace KEVENT_CTL_READY může být použita k označení specifických událostí jako "ready"; jádro pak vzbudí jeden nebo více procesů čekajících na události.
Synchronní rozhraní se trochu změnilo:
int kevent_get_events(int ctl_fd, unsigned int min_nr,
unsigned int max_nr, struct timespec timeout,
struct ukevent *buf, unsigned flags);
Rozdíl je, že hodnota vypršení je teď struct timespec. Taková hodnota je však interpretována jako relativní čas vypršení - pokud flags neobsahuje KEVENT_FLAGS_ABSTIME. V takovém případě je timeout absolutní čas a kód vypíše varování v tom smyslu, že se Jevgenij mýlil, když věřil, že by nikdo nechtěl používat absolutní časy.
Očekává se však, že aplikace, kterým záleží na výkonu, budou používat kruhový buffer v uživatelském prostoru místo synchronního rozhraní. Tento kruhový buffer je pořád zakládán pomocí kevent_init():
int kevent_init(struct kevent_ring *ring, unsigned int ring_size,
unsigned int flags);
Parametr popisovače souboru byl z tohoto systémového volání odstraněn; místo toho otevře kevent_init() nový popisovač souboru a předá jej zpět jako svou návratovou hodnotu. Takže není nutné otevírat /dev/kevent.
Struktura kevent_ring se od posledně trochu změnila:
struct kevent_ring
{
unsigned int ring_kidx, ring_over;
struct ukevent event[0];
};
Nová hodnota ring_over počítá, kolikrát se přetočil index kruhu. Tento parametr se používá k tomu, aby bylo zaručeno, že jádro i aplikace vidí stav kruhového bufferu stejně, než je aplikaci dovoleno označit události jako zpracované.
Čekání na příchod událostí do kruhu se dělá pomocí kevent_wait(), která teď vypadá takto:
int kevent_wait(int ctl_fd, unsigned int num, unsigned int old_uidx,
struct timespec timeout, unsigned int flags);
I tady je hodnota času vypršení struct timespec a absolutní časy vypršení musí být opět označeny příznakem KEVENT_FLAGS_ABSTIME. Toto volání počká, dokud nebude připravena aspoň jedna událost, pak zkopíruje až num událostí do kruhového bufferu. old_uidx je index poslední události, o které ví volající aplikace; pokud je mezi tím, než aplikace provede kontrolu a tím, než zavolá kevent_wait(), přidáno více událostí, volání se okamžitě vrátí.
Ve starších verzích patche neexistoval způsob, jak říct jádru, že byly z kruhu zpracovány události; nezbývalo než doufat, že se to stalo až tehdy, kdy se index přetočil a události byly přepsány. V nové verzi je však sledována aktuální pozice aplikace a jádro by mělo být občas uvědoměno, když jsou události v kruhovém bufferu uvolněny. To dělá kevent_commit():
int kevent_commit(int ctl_fd, unsigned int new_idx, unsigned int over);
new_idx je index poslední události, kterou aplikace zpracovala. Hodnota over by měla být pole ring_over ze struktury kevent_ring. Pokud hodnota neodpovídá tomu, jak si jádro myslí, že by měla vypadat, pokus o aktualizaci indexu selže s předpokladem, že byl volající proces na chvíli odstaven a věci proběhly, zatímco se nedíval. Kdyby tato kontrola nebyla provedena, mohly by zmatky kolem přetočení indexu způsobit ztrátu událostí.
Doposud nejvýznamnější komentář se týká toho, že název "kevent" naznačuje API pro jádro. Jeff Garzik by dával přednost názvu jako "uevent" (ačkoliv už v jádře existuje subsystém, který vrací "uvents"). Pokud bude tohle jediná závažná připomínka, mohl by si kód kevent najít cestu do jádra dlouho před tím, než Jevgenij prolomí rekord DevFS.
Následující obsah je © KernelTrap
8. pro, originál
Kristian Høgsberg oznámil, že pracuje na novém stacku pro firewire, aby nahradil ten, který je v současné době v jádře. Mám v plánu podporovat stejné funkce jako současný stack, ale ne nutně zachovat kompatibilitu rozhraní. Kristian vysvětlil: Prozatím mám hotový nízkoúrovňový ovladač OHCI, transakční logiku střední úrovně a ovladač SBP-2 (úložné zařízení) je v podstatě také hotov. Dále objasnil, že původně neměl v úmyslu přepisovat celý stack: Nejdříve jsem chtěl jen opravit ovladač OHCI. Jenže jakékoliv přepisování, které řeší jeho problémy, natolik zpřehází kód, že je to dost na to, aby už nefungovaly různé kličky a berličky, které tam jsou. A upřímně, většině těch berliček ani nevěřím. Takže jsem se rozhodl napsat ovladač OHCI od nuly.
Ben Collins vyjádřil určité pochybnosti ohledně rozhodnutí opustit současný stack: Ten strom je dost starý a šla do něj spousta práce (spousta mojí práce, takže přiznávám, že trochu bráním vlastní dítko). Nejsem si jistý, jestli je "nahrazení" rozumné nebo dokonce potřebné. Oddělit novou větev, pročistit, ale přepisování mi nedává smysl. Když jsem začal spravovat ieee1394, bylo to proto, že neexistovala podpora pro big-endian a 64 bitů. Skoro tři měsíce jsem strávil prací na tom, aby kód fungoval na PPC a UltraSPARC. Ne proto, že by bylo těžké ty problémy opravit, ale proto, že pro mnoho takových případů není ten hardware moc dobře definovaný. Kristian k tomu řekl: Nedělám to bez promyšlení. Je to dost práce, vzniknou kvůli tomu regrese a kód bude nějakou dobu nestabilní. Jde mi však o to, že pokud byste skutečně chtěli opravit problémy s ohci1394 (PCI ovladač ve starém stacku), bylo by nutné s kódem tolik zamíchat, že by to způsobilo stejně regresí jako čistý přepis. Hlavními problémy v ovladačích ohci1394 jsou irq_handler a řešení resetu sběrnice a konfigurační ROM.
Nástroje: Tisk bez diskuse
Tiskni
Sdílej:
11.1.2007 00:26
Prcek | skóre: 43
| Jindřichův Hradec / Brno
Trochu konstruktivně: pokud je to původem rus žijící v USA, tak samozřejmě nepřepisovat. Pokud je to ale rus, který své jméno píše obvykle azbukou, tak je to Jevgenij Poljakov a basta. 
Také si myslím, že používat v českém textu [...] anglickou transkripci ruských jmen je barbarství.Viz vysvětlení níže. Jistě sis už stačil všimnout, že to barbarství není žádným pravidlem, a jména normálně převádím do češtiny. Tentokrát jsem se spletl v původu jména.
tím spíš v textu, kde se občas používají české překlady anglických termínů bez ohledu na srozumitelnostTo má být tak kousavý sarkasmus, nebo si opravdu myslíš, že něco překládám "bez ohledu na srozumitelnost"? Kdykoliv se někdo ozve s připomínkou k nějakému použitému překladu, tak se to snažím odůvodnit. A pokud se ukáže, že jsem napsal nesmysl, tak to také opravím. Máš-li tedy konkrétní připomínku k překladu, sem s ní. Jestli si chceš jen tak všeobecně kopnout, použij soukr. mail.
To má být tak kousavý sarkasmus, nebo si opravdu myslíš, že něco překládám "bez ohledu na srozumitelnost"?
Možná to vyznělo víc ironicky, než jsem chtěl, ale myslím to naprosto vážně. Chcete-li příklad, napadá me třeba frame diverter z minulého dílu - anglický termín byl násilně přeložen do češtiny, původně dokonce tak, že to naprosto změnilo význam. Ale jde mi o něco jiného: termín frame diverter byl nakonec přeložen do češtiny jako odchylovač rámců/paketů a dokonce není ani v závorce původní výraz. Zkuste si schválně nechat Googlem vyhledat fráze "frame diverter", "odchylovač rámců" a "odchylovač paketů". U první mi našel skoro 15000 stránek, pro zbývající dvě ani jednu (dokonce ani bez uvozovek). Čtenár Jaderných novin, by si tedy musel přečíst anglický originál, aby zjistil, o čem je vlastně řeč.
Prostě jsem obecně proti tomu, aby se k anglickým termínům za každou cenu vymýšlely české překlady. Tam, kde existuje běžně používaný český termín, je to v pořádku, ale pokud zažitý český termín neexistuje, považuji za chybu, když si překladatel nějaký vymyslí jen proto, aby to znělo česky, a nehledí na srozumitelnost textu.
frame diverter z minulého dílu - anglický termín byl násilně přeložen do češtiny, původně dokonce tak, že to naprosto změnilo význam.Bohužel jsem udělal chybu. Když mě na ni jeden čtenář upozornil, opravil jsem ji. Také jsem se zastyděl, protože místo abych použil Google, jako to dělám obvykle, když potřebuji zjistit, co nějaký termín znamená, tak jsem tam ve spěchu zapomněl provizorní překlad.
frame diverter byl nakonec přeložen do češtiny jako odchylovač rámců/paketů a dokonce není ani v závorce původní výraz.Mnohdy do závorky původní anglický termín dávám, viz jiné díly. Rozhodl jsem se to převést do češtiny, protože uvažuji takto: - Pokud někdo anglicky umí, tak pro něj nebude problém odvodit z tohoto českého překladu původní termín. Nejedná se totiž o nějaký překlad opisem nebo nevyzpytatelný novotvar. Nicméně není problém ten anglický tvar do závorky doplnit. - Ten, kdo anglicky neumí, tak z "frame diverter" nebude vůbec moudrý (pokud náhodou daný termín nezná díky programátorské zkušenosti). Proto mi připadá důležité to překládat, aby si čtenář (který anglicky neumí) mohl udělat představu o tom, k čemu to slouží.
Ten, kdo anglicky neumí, tak z "frame diverter" nebude vůbec moudrý (pokud náhodou daný termín nezná díky programátorské zkušenosti).Ten text implikuje, ze kdyz to prelozis, tak ten, kdo neumi anglicky bude o neco moudrejsi. Ja myslim, ze nebude a akorat to zmate toho, kdo anglicky termin zna. Jasne, ma smysl prekladat casto uzivane veci, ale myslim, ze nez se snazit o preklad vseho, je casto lepsi dat do zavorky par slov popisu. Co je srozumitelnejsi ... mysi prorok (mouse foreteller) ... nebo ... mouse foreteller (predpovida vase pohyby mysi) ...? Uprimne jedinej praktickej smysl prekladani anglickych terminu vidim v tom, ze je muzeme ohybat. Jinak slovo jako slovo. Hlavne, kdyz se domluvime, ne? :)
Jasne, ma smysl prekladat casto uzivane veci, ale myslim, ze nez se snazit o preklad vseho, je casto lepsi dat do zavorky par slov popisu. Co je srozumitelnejsi ... mysi prorok (mouse foreteller) ... nebo ... mouse foreteller (predpovida vase pohyby mysi) ...?Myslím, že na to nahlížím stejně, jen mám o něco posunutou hranici, na základě které rozlišuji, co ještě je vhodné přeložit, a co už by bylo lepší nechat v původním znění s českým vysvětlením. Například "mouse foreteller" bych asi opravdu překládal, i když bych použil něco jako "předpovídač myši". Bude asi lepší, když si tu hranici nastavím trochu blíž k anglickým verzím...
O tom slyším prvně, kam to chystají?
Ne, že bych nějaké ty modely nedělal, jen jsem netušil, že to mám kvůli myšce v kernelu.
tak je to Jevgenij Poljakov a basta.To je prosté: spletl jsem si toho člověka s jiným. Nedávno se mi stalo, že jsem do češtiny přepsal jméno vývojáře, který své jméno píše anglicky. A tentokrát jsem myslel, že je to ten samý. Ostatně, mrkni na předchozí díly, kde je psáno Poljakov (i když, pravda, tam mám Evgenij - to je tak napůl, ale to jen kvůli tomu, že jsem nevěděl, že je vhodnější psát Jevgenij). Stejně tak česká jména nenechávám bez diakritiky.
Nedávno se mi stalo, že jsem do češtiny přepsal jméno vývojáře, který své jméno píše anglickyPrávě proto jsem se jistil tou první větou.
Pokud je to ale rus, který své jméno píše obvykle azbukou, tak je to Jevgenij Poljakov a basta.Jenze on se v mailech podepisuje jako Evgeniy Polyakov a tuhle transkripci ma i ve From, takze asi chce aby se o nem tak psalo, ne? Navic ho pod timhle jmenem lide znaji, takze ja naopak nevidim duvod proc o nem na Abicku psat jako o Jevgeniovi. Evidentne je s tim anglickym tvarem spokojen, jinak by ho nepouzival, takze ho tady bud piste azbukou at je to presne, nebo se drzte takove transkripce kterou si urcil on sam a nevymyslejte pro nej neco "lepsiho". Jestli mi neverite ze se tak podepisuje muzu vam par jeho mailu preposlat.
11.1.2007 18:02
Bluebear | skóre: 30
| blog: Bluebearův samožerblog
| Praha
PS: kdyby mě opravil/doplnil místní češtinář, vůbec bych se nezlobil.
11.1.2007 20:27
Bluebear | skóre: 30
| blog: Bluebearův samožerblog
| Praha
12.1.2007 11:08
