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.
Aktualizace stabilního jádra 2.6.22.10 vyšla 10. října s přibližně desítkou oprav.
Starší jádra: 2.6.16.54 vyšlo 7. října s několika změnami, především v subsystému MD. 2.6.16.55-rc1 vyšlo ten samý den a opravuje několik bezpečnostních chyb.
Nevím, jak dlouho to sleduješ, ale zatím se žádný pokus o začlenění LSM nevyhnul přehnané kritice od určitých skupin. Jen ten, kdo se chce nechat rozsekat na příslovečné kousíčky, by navrhoval malý LSM.
Jsem dvakrát tak účinný jako Viagra.
-- Dave Jones
Specifikace Controller Area Network (CAN) popisuje síťovací stack určený pro konkrétní prostředí: embedded realtime řadičové sítě [controller networks]. Fyzická vrstva používá diferenciální sériovou technologii, která má být velmi odolná proti elektrickému rušení. Protokoly vyšších úrovní používají krátké datagramy (maximálně 8bajtové) a hodně kontrolních součtů, aby minimalizovaly dopady chyb. Protokoly jsou co nejjednodušší, aby embedded řadiče zatěžovaly co nejméně. S CAN se můžete setkat v relativně malých a náročných prostředích - třeba v automobilech. Není tedy nic divného na tom, že je to právě výrobce automobilů - což není zrovna typ firmy, které by se vyznačovaly vývojem linuxových novinek - snaží dostat implementaci CAN do hlavního jádra.
V minulosti už se objevily linuxové implementace CAN, ale žádná se do jádra nedostala. Většina z nich se však snažila o ten nejjednodušší přístup: CAN řadič převlékly za sériový port a protokoly implementovaly na aplikační úrovni. Tento přístup sice funguje, ale ztrácí se tím výhoda vyplývající z toho, že máme síťovací stack. Všechny CAN aplikace, které by chtěly využít fronty, kontrolu kvality služby, API sokety atd., by takové funkce musely implementovat samy. To se však možná změní, protože sada patchů PF_CAN, kterou poslali Urs Thuermann, Oliver Hartkopp a několik dalších, se dostává do použitelného stavu.
Jak se dalo očekávat, přidávají tyto patche novou rodinu protokolů PF_CAN, která může být předána systémovému volání socket(). Pak je možné sokety vázat, číst a zapisovat do nich všemi běžnými způsoby. Základní surové sokety lze využít k posílání a přijímání datagramů na vysílací ([broadcast]) sběrnici. K dispozici je mechanismus pro přidávání filtrů, aby mohly být na daném zařízení přijímány jen datagramy, o které máme zájem. Implementace PF_CAN také obsahuje síťové ovladače pro několik CAN rozhraní. Se vším všudy to prostě vypadá tak, jak by člověk od nové rodiny síťových protokolů v jádře očekával. Bude-li kód začleněn, aplikace využívající CAN budou vypadat jako všechny ostatní síťové linuxové aplikace.
Jonathana Corbeta však zaujalo, že kód představili vývojáři z firmy Volkswagen. Není tak neobvyklé vidět Linux v různých embedded prostředích a také není neobvyklé, když firmy Linux vylepšují, aby šel lépe použít v oblasti, kde to potřebují - ta možnost je jedním z hlavních důvodů, proč vůbec Linux používat. Ale není zdaleka běžné, aby společnosti, jejichž hlavní zájmy jsou od hackování jádra velmi vzdálené, přispívaly změnami do hlavního vývojového stromu. Proto Jonathan poslal panu Thuermannovi pár otázek ohledně této práce. Ukázalo se, že vytvoření síťové podpory CAN pro Linux trvalo velmi dlouho:
Docela dost programátorů CAN dříve pracovalo na microřadičích [micro-controller] a našemu síťovému přístupu moc nerozumějí. Na druhou stranu, síťově orientovaní lidé mají potíže s některými částmi PF_CAN proto, že CAN odolává našim snahám z něj udělat síťový protokol (např. žádné adresy, není to vrstvené). Takže nám trvalo více než rok, než jsme se v konferenci socketcan shodli na současném návrhu.
Výsledná sada patchů se blíží dokončení a Urs by chtěl požádat všechny, které implementace CAN zajímá, aby se podívali na dokumentaci a archívy konference, než se zapojí do diskuze.
Další otázka, která člověka napadá, je něco ve smyslu "jak dostanu roota na svém volkswagenu?" Ale kombinace Linuxu a CAN se - zatím - v žádném volkswagenu nedodává. Používá se však velmi intenzivně ve výzkumných projektech; Urs také zmínil potenciální využití v uživatelských rozhraních: informační a zábavní systémy [infotainment], navigace, komunikace mezi auty a další. CAN se také používá pro komunikaci externích diagnostických a monitorovacích systémů se zabudovanými systémy. Jestli si linuxové systémy postavené na CAN někdy najdou cestu do sériově vyráběných aut, to se teprve uvidí. Urs k tomu napsal:
Počkejme a uvidíme 
. Ale já bych na to nesázel. Kdybychom však jednou v novém autě v přihrádce u spolujezdce našli cédéčko se zdrojáky, to by bylo vážně bezva.
Ať už se jeden konkrétní výrobce rozhodne jakkoliv, zdá se jasné, že potenciálních uživatelů řádné implementace CAN v linuxovém jádře je mnohem více. Elektronické hračky [gadgets] jsou jen jednou podmnožinou embedded aplikací; mnohé komplexní embedded systémy budou potřebovat tento druh jednoduché a odolné komunikační infrastruktury.
Nejdřív se však kód musí dostat do jádra. Vývojáři CAN se v srpnu trošku nepohodli se správci síťování, což situaci nijak neprospělo. Vypadá to však, že problémy byly vyřešeny, a vývojáři CAN posílali patche, které adresovaly připomínky těch, kteří kód kontrolovali. Zařazení do 2.6.24 je sice velmi nepravděpodobné, ale jeden další vývojový cyklus by mohl stačit, aby se kód dostal do stavu, kdy bude připraven k začlenění.
Když se to vezme kolem a kolem, tak jeden nebo dva zádrhely se daly čekat. Společnosti jako Volkswagen nemají ve zvyku příspívat do jádra. Přesto však VW udělal práci, která byla užitečná pro ně, ale teď ještě vyvíjí (nezanedbatelné) úsilí, aby mohl kód sdílet se zbytkem světa. Vývojáři ve VW se na vývojovém procesu jádra nepodílejí každý den, a není proto překvapující, že došlo k nějakým třenicím. Slouží jim ke cti, že ty problémy ustáli a pravděpodobně to nevzdají.
Takový příběh by se, s horším nebo lepším koncem, mohl opakovat často. Spousty firem přizpůsobují Linux vlastním potřebám - proto svobodný software používají. Budeme-li mít štěstí, pokusí se některé z těchto firem dát kód zpátky, aby ho mohli využívat a vylepšovat i ostatní. Tyto firmy nebudou obeznámeny s našimi postupy a možná nebudou mít čas nebo vůli vytrvat i přes nepřátelské reakce. Když se jim pokusíme se začleňováním pomoci, vyděláme na tom; jinak bychom mohli přijít o příspěvky, které by stálo za to v jádře mít.
(Vizte také: Controller Area Network na Wikipedii.)
Funkce printk() je jedním z hlavních komunikačních kanálů mezi jádrem a uživatelských prostorem. printk() je velmi podobná printf() ze standardního C, včetně podpory úrovní logování. Funkce se v poslední době příliš neměnila, ale pár lidí by ji chtělo vylepšit.
Nejambicióznější změny protlačuje Vegard Nossum. Ta práce původně vzešla z diskuzí o oživeném patchsetu Linux-tiny. Jedním z nejrychlejších způsobů, jak zmenšit velikost binárního obrazu jádra, je odstranění všech volání printk() a příslušných řetězců. Nevýhodou je samozřejmě to, že jádro pak už nemůže komunikovat. Když se něco pokazí na systému bez printk(), většinou neexistuje způsob, jak zjistit, co je za problém. Obyčejně stačí jeden takový zážitek, aby se člověk rozhodl, že pár tisíc řetězců navíc není ten nejhorší způsob, jak využít kousek paměti.
Vegardův původní patch tento problém řešil přepracováním definice printk(), aby mohly být při kompilaci odstraněny hlášky pod určitou úrovní logování, zatímco ty důležitější by byly ponechány. Taková změna však znamenala zcela novou infrastrukturu kprint() a nefungovaly kvůli tomu některé části kódu volající printk().
Patch také prováděl několik dalších změn. Konkrétně se Vegard snažil pomoci vývojářům, kteří chtějí (za běhu systému) překládat hlášky jádra do jiných jazyků. Podpora lokalizace přímo v jádře nikdy nebyla příliš populární myšlenka, takže část práce je potřeba provést v uživatelském prostoru. Ale lidé, kteří pracují na překladech, si i tak myslí, že by bylo fajn, kdyby byly zprávy z jádra formátovány tak, aby to překlad trochu usnadnilo.
Jedna z věcí, které překlad komplikují, je zakódování parametrů do zpráv. Překladatelé by byli raději, kdyby se zavedl formát, ve kterém by parametry a řetězce byly odděleny, aby šlo snadno napsat výrazy, které by zachytily řetězce, a s parametry by se pracovalo samostatně. Takže Vegardův patch úplně změnil výstupní formát. Parametry byly i nadále zakódovány, ale drženy samostatně s tím, že by uživatelský démon věci poskládal. Zatímco u současného jádra by jádro mohlo vypsat něco jako:
AbcLinuxu.cz
ITBiz.cz
HDmag.cz
AbcPráce.cz
usb-storage: detekován flash disk na 12
nový formát by vypadal asi takto:
"usb-storage: detekován flash disk na %d", "12"
A ve skutečnosti by toho bylo ještě více - nový formát obsahoval pole pro úroveň logování, aktuální čas, název souboru, číslo řádku a aktuální funkci.
Patch vyvolal trochu znepokojení. Především proto, že se zdá divné, když patch určený ke zmenšení jádra nakonec přidává nový formát bufferu logu a přibližně 1600 řádků kódu. Nikomu se také nechce připravovat komplikovanějšího uživatelského démona jen kvůli porozumění jaderným zprávám. Celkově se zdálo, že jde o přidávání spousty komplikací, aniž by to přinášelo nějaké velké výhody. Tento patch se tedy daleko nedostal.
Na návrh Alana Coxe přišel Vegard s mnohem jednodušším řešením zaměřeným na problém překladů. Místo vytváření úplně nového formátu logů prostě nový patch dává značky (0x1f) okolo všech zakódovaných parametrů. Tento znak se na sériových konzolích nezobrazuje (i když na VGA konzolích v současné době způsobuje "divné" znaky), ale překladatelský kód ho může zachytit. Toto cílenější řešení ještě nebylo příliš komentováno, ale možná ukazuje způsob, jak vytvářet zprávy, se kterými se bude překladatelům lépe pracovat, aniž by docházelo k velkým změnám jádra - nebo nutilo změny vývojářům.
Mezitím se Jan Engelhardt rozhodl jádro trochu vyzdobit přidáním možnosti barevného výstupu zpráv. První verze patche nastavovala pro všechny zprávy stejnou barvu; další přidávaly barvy pro jednotlivé úrovně logování. Některým vývojářům se taková funkce líbí, jiní to považují za zbytečnost. Někdo poznamenal, že obarvování není užitečné - kdyby bylo, implementovalo by se to už před nějakými 16 lety. Nakonec však patch možná zařazen bude, protože je malý a výstupní formát se nijak nezmění. Můžeme jen doufat, že distributoři odolají pokušení nastavovat zprávám tak odporně nečitelné barvy jako u nástrojů typu ls.
Nástroje: Tisk bez diskuse
Tiskni
Sdílej:
Teda bez toho doktorátu, ale aspoň s přičichnutím ke kybeře a řídicí technice.
26.10.2007 00:49
Prcek | skóre: 43
| Jindřichův Hradec / Brno
Konkrétně se Vegard snažit pomoci vývojářůmJá nerozumět, co vy říkat?
Tady mozna chybi "by": nový formát by obsahoval pole pro úroveň logováníNechybí. Nový formát (tak, jak ho Vegard navrhoval) obsahoval různé věci. Teď už je neobsahuje, protože patch pozměnil. Ale kdybychom tam to "by" dali, tak by se význam nijak výrazně nezměnil (pokud by to začlenili do jádra, tak _by_...). Díky za upozornění.
Na návrh Alana Coxe přišel Vegard ...http://www.abclinuxu.cz/kdo-je/alan-cox
obarvování není užitečné - kdyby bylo, implementovalo by se to už před nějakými 16 lety
Zvláštní způsob uvažování. Zejména když i člověk uvědomí, že stejně by se dalo odpálkovat všechno, co v jádře není od roku 1991…
klogd nebo syslog-ng uměl v případě potřeby sekvence pro přepínání barev odstranit. Možná by to naopak měl dělat automaticky a naopak jen na vyžádání je tam nechat.
).
kprint()nema byt infrastrukturu
printk()
26.10.2007 13:52
michich | skóre: 51
| blog: ohrivane_parky
.
Ne, že bych chtěl brečet na špatném hrobě, tohle nedorozumění je samozřejmě už v anglickém originále, píšu to spíš proto, aby to tu někdo nevzal jako fakt, že to tak je. Není. Třeba obyč RS-485 je na tom s odolností proti rušení podstatně líp...
Úplně jiná píseň je CANOpen - nadstavba nad CANem, která specifikuje poměrně složitou hierarchii komunikujících objektů. Cpát to do socketů by byla vysloveně šílenost. Ostatně je to možná i zbytečně složité do jádra. Spíš než v C bych to napsal v C++. Navíc jsem zatím viděl implementované spíš různé podmnožiny, kolikrát nepříliš standardní, než plnohodnotný CANOpen. CANOpen je dost možná složitější a úchylnější než ASN.1 Žádný div, že se nikomu moc nechce, programovat celý ten objektový stack do nějakého MCUčka.
27.10.2007 16:02
Petr Tomášek | skóre: 39
| blog: Vejšplechty
27.10.2007 16:06
michich | skóre: 51
| blog: ohrivane_parky