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).
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.
Aktuální předverze je 2.6.22-rc5, vydaná 16. června. Obsahuje hodně oprav - takže si Linus trochu postěžoval, že je i takto pozdě ve vývojovém cyklu začleňováno tolik věcí. Vizte podrobnosti v dlouhém changelogu.
Od vydání -rc5 bylo do hlavního git repozitáře přidáno jen několik patchů.
Během minulého týdne nevyšla žádná nová verze stromu -mm ani starších jader. Všichni měli zjevně plné ruce práce s "diskuzí" o GPLv3.
Takže mám dost. Končím tady provždycky. Chci odsud vypadnout dřív, než mě to natolik otráví, že bych nakonec začal používat Windows. Občas si možná trochu pohraju s kódem v uživatelském prostoru, ale jádro je pro mě černá díra, do jejíhož horizontu událostí už nechci nikdy vstoupit.
-- Con Kolivas
Z toho příběhu plyne poučení, že se v současné době prostě nevyplatí kontrolovat cizí kód [code review]. Z osobního hlediska je výhodnější počkat, až se do jádra dostane patch plný chyb, a pak ty problémy opravit (aspoň si vás někdo všimne). Aby se to změnilo, měli bychom klást větší důraz na důležitost kontroly kódu tím, že budeme "odměňovat" lidi, kteří tomu věnují svůj čas, a "odměňovat" vývojáře/správce, kteří budou brát kontroly kódu vážně.
Jak je vidět, v nedávném GPLv3 flamewaru o 1000 zprávách je jen málo věcí, které by ospravedlnily tak velké plýtvání bity. Tady je pár ukázek.
Myslím, že Open Source komunita (a FSF také) by udělala mnohem lépe, kdyby se *nezaměřovala* na "právní pravidla" ohledně toho, co se smí a nesmí dělat, a raději vynaložila větší úsilí na ukazování lidem, že celá ta "Open Source" věc vlastně funguje. A já jsem přesvědčen, že právě to Linux posledních deset let dělá!
Ale pokud tou otázkou myslíš "řekl bys, že je GPLv3 v pohodě bez toho nového povídání v sekci 6 o 'spotřebitelských zařízeních'?", pak by odpověď byla ano, myslím, že současný návrh GPLv3 vypadá, až na tu drobnost, dobře.
Nerozumím tomu, jak můžeš tvrdit, že výrobce omezuje tvoje svobody. _Ty_ jsi se rozhodl, že půjdeš a produkt si koupíš, i když jsi věděl, že se výrobce nepřetrhne, aby ti usnadnil zařízení hacknout. V mnoha případech ani výrobce nemá na vybranou (napadají mě třeba kanály a certifikace 802.11b, GSM atd.), jestli věci uživatelům otevřít. A změna licence s tím nic nevykouzlí.
-- Paul Mundt
V tom, co dělá TiVo, vidím daleko více zákazů než svobod. Je důležitější umožnit jediné firmě kvůli jejímu obchodnímu modelu vydávat zákazy, nebo zachovat ducha hackování a sdílení, díky kterému se daří svobodnému softwaru a Linuxu? Copak myslíš, že by byl Linux úspěšný, kdyby měly počítače zámky, které by lidem bránily, aby na nich Linux upravovali?
Takže místo abych TiVo považoval za "zlo", beru ho jako včelu dělnici, která sice nikdy nikomu své geny nepředá, ale stejně pomůže lidem, kteří ty geny předají: jádru (do jisté míry - ani ne kvůli samotným patchům, ale kvůli rozšíření obzorů v oblasti PVR) a projektům jako MythTV (opět ne kvůli patchům, ale protože lidem pomohl lépe chápat dané problémy).
Myslím, že RMS by měl akceptovat skutečnost, že většina kódu byla napsána, aniž by lidé souhlasili s jeho ideologií. A měl by přijmout _zodpovědnost_, kterou svým géniem nebo náhodou (vyberte si) získal, a pokusit se _pochopit_, jak ti lidé uvažují - místo aby se snažil prosadit vlastní plány.
-- Ingo Molnar
Dovolím si nesouhlasit. Přijetím _jeho_ licence jsi přijal i jeho postoj. Pokud se ti to nelíbí, vyber si jinou licenci (což samozřejmě můžeš).
GPLv2 neříká, že se máš stát otrokem RMS a ve všem jej následovat a se vším souhlasit. Fakt. Musel jsi číst nějakou jinou verzi (třeba nějaký počáteční nevydaný návrh?).
Co je tady, kruci? Konference linux-kernel nebo Nikajský koncil?
-- Al Viro
Skoro přesně před rokem, zatímco vývojáři diskutovali o změnách souborového systému ext3, napsal Andrew Morton:
Přesto je pravda, že linuxové souborové systémy začínají být trošku rozvrzané a blížíme se k okamžiku, kdy bychom mohli těžit z nového, který začne na zelené louce. Mohl by být založen třeba na reiser4 - nedíval se na něj někdo? Už tu leží pár let.
Reiser4 asi ještě bude nějakou dobu ležet bude. Ale to neznamená, že by nebyl zájem o vytváření zajímavých nových souborových systémů. V květnu jsme mluvili o LogFS, ale není to jediný nováček na scéně.
Asi nejzajímavější účastník je btrfs, který Chris Mason oznámil 12. června. Jde o úplně nový souborový systém určený pro standardní rotační ukládání s několika zajímavými funkcemi:
Rychlá kontrola souborového systému je pro btrfs důležitým designovým cílem. Data a metadata jsou uspořádána způsobem, který offline checkeru [kontrolnímu programu] umožňuje číst disk téměř sekvenčním způsobem. To by mělo proces výrazně urychlit; kontrola souborového systému obvykle znamená velké množství vyhledávacích operací. V plánu je i online kontrola, která však zatím nebyla implementována; jakmile bude fungovat, mohlo by se úplně zrušit kontrolování při připojování.
Tento souborový systém je zatím v rané fázi vývoje - nedoporučuje se pro data, která byste si chtěli ponechat. Zatím nebylo provedeno moc výkonnostních testů a je pravděpodobné, že ještě dojde k mnoha optimalizacím. Celý souborový systém je například v tuto chvíli chráněn jediným mutexem, což je řešení, které by si pravděpodobně na moderních systémech se 4096 procesory moc dobře nevedlo. Také je potřeba se postarat o několik detailů - třeba by neměl "oopsovat", když dojde místo, je potřeba přidat podporu přímého I/O, zápisu přes mmap(), rozšířených atributů atd. Ale btrfs se podařilo upoutat pozornost, takže pokud dostojí nadějím, které jsou do něj vkládány, mohli bychom v budoucnu používat btrfs systémy.
(Další informace na stránce projektu btrfs.)
Druhý nedávno představený souborový systém je NILFS, který je teď ve druhé verzi. NILFS (New Implementation of a Log-structured Filesystem) je souborový systém strukturovaný jako log - úložné médium je bráno jako kruhový buffer a nové bloky jsou vždy zapisovány na konec. Tyto souborové systémy obvykle dosahují dobrých výsledků v testech, které měří výkon při zápisu, protože všechny zápisy jsou prováděny na souvislé bloky; výkon při čtení už tak dobrý není. Souborové systémy strukturované jako log se často používají na flash zařízeních, protože přirozeně zajišťují rovnoměrné opotřebení. Vypadá to však, že NILFS není určen pro flash.
Místo toho klade NILFS důraz na snímky. Přístup, který využívá strukturu jako log, je specifickou formou copy-on-write, takže se nabízí vytváření snímků. Vývojáři NILFS mluví o vytváření "souvislých snímků", které lze použít pro záchranu při problémech způsobených uživatelem - typu "rm -r". NILFS je prý škálovatelný díky 64bitovým datovým strukturám, ale podpora architektury x86_64 je kupodivu na seznamu zatím nesplněných úkolů. Zatím také nepodporuje rozsahy.
(Další informace na nilfs.org.)
Obecně platí, že uživatelé Linuxu o jádře spíše nechtějí vědět. Pokud je všechno v pořádku, tak fungují připojená zařízení, běží programy a jádro to všechno potichu zařídí. Když se však vyskytne problém, bývá nutné pročítat zprávy, které jádro posílá. Tyto zprávy dávají smysl vývojářům, kteří je napsali, ale pro zbytek světa už tak zřejmé nebývají. Neal Stephenson ve svém příběhu Na počátku byla příkazová řádka říká, že jaderné zprávy jsou stejně "zlověstně nečitelné jako graffiti tagy". Pro vývojáře jádra je nejčastěji hodnota jaderné zprávy v tom, že může určit, která část kódu si stěžuje - a z toho lze odvodit samotný problém.
Pro běžné uživatele je však těžší jaderné zprávy takto používat - a ti, kteří nemluví anglicky, to mají ještě horší. Není tedy překvapivé, že se čas od času objeví diskuze na téma vylepšení zpráv.
Reformátoři zpráv mají většinou dva cíle:
Potíž je samozřejmě v tom, že přiřazení identifikátorů ke zprávám je pořádný kus práce. V jádře jsou desítky tisíc volání printk(); každému z nich je potřeba přiřadit identifikátor a změnit kód. S každou novou verzí jádra přibývají - ve velkých počtech - nové zprávy. Snadno si lze představit, jak rychle by vývojáře začalo otravovat přiřazování identifikátorů. Z těchto důvodů Linus dříve návrhy na vylepšení zpráv odmítal.
Ale je to stejně zpátky. Japonští uživatelé, kteří mají potíže s podporou Linuxu, navrhli nový přístup. Každá jaderná zpráva by měla přiřazeno jméno komponenty a číslo. Komponenta by byla určena definicí v souboru:
AbcLinuxu.cz
ITBiz.cz
HDmag.cz
AbcPráce.cz
#define KMSG_COMPONENT "railgun"
Volání printk by pak byla upravena tak, aby obsahovala číslo zprávy:
printk(KMSG_ERR(100) "Railgun omylem vystřelila - pardón\n")
Výsledkem by byla zpráva, které by předcházel řetězec railgun.100:, což by umožnilo přeložení zprávy a také vyhledání v manuálu. Aby se zaručilo, že bude nějaká dokumentace opravdu k dispozici, vyžaduje návrh dokumentaci přímo ve zdrojovém kódu; asi takto:
/**
* message
* @100:
*
* Popis:
* Railgun omylem vystřelila, protože uživatel
* nespecifikoval žádnou akci.
*
* Uživatelská reakce:
* Obsluha by si měla dávat pozor, aby stála bokem.
*/
Skripty kerneldoc by byly aktualizovány, aby posbíraly všechny tyto zprávy a vyrobily z nich tisknutelnou příručku. Další nástroj by kontroloval zdrojové soubory a upozorňoval na zprávy, u kterých by chyběl popis.
Podobná schémata byla již v minulosti kritizována a totéž se stalo i tentokrát. Přidaná práce, která vyplývá z takového dokumentování zpráv, je pro některé vývojáře příliš; David Miller to vyjádřil trefně:
Řekl bych, že moje reakce na něco takového, pokud by se to do jádra dostalo, by byla asi taková, že bych přestal psát kód, který podává užitečné zprávy, protože muset ho ještě takto dokumentovat je příliš práce, takže by mi to ani nestálo za to.
Obtížné by bylo také aktualizování zpráv - kód se často mění, aniž by byly změněny i okolní komentáře; není důvod se domnívat, že by jaderné zprávy byly výjimkou.
Andrew Morton místo toho navrhl řešení, které by vývojáři mohli spíše akceptovat. Přidala by se nová podoba printk(), která by pracovala s ID zpráv (v zatím neurčeném formátu). ID by bylo vypsáno společně se zprávou, ale všechno ostatní - překlady, popisy, upřímné soustrasti atp. - by bylo v databázi mimo jádro.
Klíčové je, že by se od vývojářů neočekávala jakákoliv práce s touto databází - dokonce ani s jadernými zprávami. Místo toho by byl "tým pro jaderné zprávy", který by měl za úkol tyto informace udržovat. Čas od času by se někdo z týmu podíval na nový kód, přidal potřebná ID a poslal správci patch. Pokud by o to sami neměli zájem, nemuseli by se tohoto procesu vývojáři vůbec účastnit.
I tento návrh má své nedostatky; jedním z nich je to, jak by byl tým starající se o zprávy financován (nebo jinak motivován). Dopad by však mohl být tak malý, že by to komunita mohla přijmout. Jednoho dne si možná i uživatelé Linuxu budou muset na poličkách vyhradit místo na pořádné manuály o zprávách.
Nástroje: Tisk bez diskuse
Tiskni
Sdílej:
16.7.2007 00:05
freshmouse | skóre: 42
| blog: Bruno Banány
16.7.2007 10:01
freshmouse | skóre: 42
| blog: Bruno Banány
Koho by napadlo, že tam jedno slovo chybělo a druhé přebývalo...
Zas tak moc odlišné od http://en.wikipedia.org/wiki/Railway_gun to není.
.
17.7.2007 15:44
Cubic | skóre: 24
| blog: obcasne_vyplody
| Essex
pravdepodobne kanon s revolverovym zaverem
18.7.2007 10:19
Cubic | skóre: 24
| blog: obcasne_vyplody
| Essex
It is a common misnomer to refer to Gatling guns (rotary cannons) as chain guns; even in some video games, such as Wolfenstein 3D and Doom, the player carries a minigun referred to as a chain gun. In fact, most Gatling-type guns—weapons such as the M61 Vulcan, the M197, the GShG-7.62, the M134, and the XM214—are externally-powered but are not chain guns.ikdyz wikipedia taky neni vsevedouci a neomylna
18.7.2007 10:24
Cubic | skóre: 24
| blog: obcasne_vyplody
| Essex
The most commonly produced and used chain gun...zjistite ze tam neni ani vulkan ani zadny minigun ale treba kanon z AH-64 Apache coz je prave mnou zminena zbran, ale samozrejme s pouzitou definici principu stralby pomoci externiho pohonu souhlasim
Pokud je starsi, tak Japonci a Taiwanci, ty novejsi pak nejspise Cinani. Pro ne je anglictina zcela nezajimavy jazyk casto.
Par Cinanu na svem konte take mam.
I ti prispevatele do jadra. Zrovna jeden takovy mi tu po ranu dela kulisu na praci na telefonu. Ze zemedelske oblasti zvane Beijing
A prekvapive, ty "hlasky" nepotrebuje jen vyvojar jadra, ovsem to nekteri vyvojari jadra jaksi ignoruji 
V linuxu to kdysi takhle fungovalo - dostal si kod chyby a perror dalo vysvetleni. Ted uz nejak ne.
AFAIK to tak pořád funguje. Musíte rozlišovat mezi signalizací chyby syscallu pro volající proces a chybovým hlášením, které jádro zapisuje do logu (prostřednictvím syslogu).
16.7.2007 10:13
andree | skóre: 39
| blog: andreeeeelog
ako fakt nechapem, ze v jadre je tolko experimentalnych veci, niektore ktore vobec nik nepouziva a pritom perfomance patche od CK tam nedaju, lebo..? pochybujem ze jeho kod je taky hrozny, ze by nevyhoval standardom alebo co... to je jadro skostnatene natolko ze tam je dolezitejsie ze je tam (?)prehladny kod, miesto aby bol vykonny/lepsi?
tiez to mohli vyriesit pomocou konfiguracie jadra - v pripade ze by si clovek zaskrtol "CKs improvements", skompilovalo by sa to s jeho patchami - a bolo by po probleme... a casom by mozno zistili podla ohlasov pouzivatelov, ze niektore tie patche su fakt dobre...
no co uz, tak je o jedneho skveleho vyvojara menej asi ich uz je privela, ze si ich linux nemusi drzat...
16.7.2007 20:34
andree | skóre: 39
| blog: andreeeeelog
16.7.2007 16:47