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.
Lidi dělají divné věci. Například spouští Linux v Excelu. Využít je emulátor RISC-V mini-rv32ima sestavený jako knihovna DLL, která je volaná z makra VBA (Visual Basic for Applications).
Aktuální předverze je (k 6. 6. 2007) 2.6.22-rc4, vydaná 4. června. Přidává několik stovek oprav zaměřených na další stabilizaci 2.6.22. Vizte podrobnosti v dlouhém changelogu.
Od vydání -rc4 se do hlavního jádra žádné další patche nedostaly.
Aktuální verze -mm stromu je 2.6.22-rc4-mm1. Mezi nedávné změny patří operace pro vypnutí veškerých I/O přístupů (pro virtualizované hosty), dlouhý patch opravující zásek při selhání stránky, další práce na uspávání/hibernaci, patch O_CLOEXEC (vizte níže), kód pro podporu Xen na architektuře x86-64, podpora v ext4 pro nové systémové volání fallocate() a sada kontejnerových patchů.
Starší jádra: 2.6.16.52 bylo vydáno 31. května a obsahuje hrstku oprav.
Jsem přesvědčen, že probíhá nějaká soutěž o vytvoření nejhoršího grafického poštovního klienta pro Linux. Nejsem si jistý, jaká je první cena, ani kdo vyhrává, ale všichni soutěžící jsou strašní.
-- Dave Jones
Lotus Notes nemá vážnou konkurenci.
Andyho skript pro kontrolu patchů rozpozná (tedy měl by) zalamování slov, roztahování tabů a snad i vyplňování volným místem. Až to uvedeme do chodu, měli by všichni, kdo pošlou vadné patche, dostat za pár minut od robota odpověď, která jim řekne, co udělali špatně - a tak se věci z velké části napraví samy.
Už se na to táááák těším. <Posílá zmínku komisi pro Nobelovu cenu>
Článek o sysletech stručně zmínil problém s používáním popisovačů souborů k nízkoúrovňové komunikaci s jádrem. Pro popisovače souborů je vyhrazen jediný jmenný prostor a na alokaci těchto popisovačů se vztahují přísná pravidla. Dokud má aplikace daný prostor plně pod kontrolou, funguje všechno dobře a je možné se spolehnout na pravidlo o "nejnižším dostupném popisovači". Jakmile však začnou popisovače pro své vlastní účely používat i skryté úrovně (především knihovna C), zvyšuje se pravděpodobnost konfliktů a zmatků na úrovni aplikací. Aplikace, která chybně odhadne, kde bude popisovač souboru alokován, nebo bez okolků "vyčistí" otevřené popisovače knihoven, selže. Je to evidentně dost reálný problém - do té míry, že se glibc snaží seč může, aby interní popisovače souborů nepoužívala vůbec pro nic.
Je to také problém pro vývojáře jádra. Nechce se jim vytvářet nové služby založené na popisovačích souborů (například události signalizující dokončení u asynchronního I/O založeného na sysletech), pokud je glibc nebude používat. Hledají se tedy alternativy, z nichž většina spočívá ve vytvoření samostatného prostoru pro "systémové" popisovače souboru. Jeden způsob navrhl Linus:
Což by *mohlo* být něco tak jednoduchého jako určení, že "bit 30 v popisovači souborů označuje samostatný fd prostor", plus nějaké příznaky, aby open a spol. vracely tyto samostatné fd. Pro "select()" by pak byly k ničemu (samozřejmě za předpokladu plochého adresního prostoru), ale všemu ostatnímu by přišly vhod.
Davide Libenzi ten nápad rozvinul a poslal patch pro vytvoření nesekvenční oblasti pro popisovače souborů. Aktuální jádro popisovače sleduje v lineárním poli - technika, která funguje správně, dokud platí pravidlo o "nejnižším dostupném popisovači". Jakmile však začneme v číslech popisovačů nastavovat bity vyššího řádu, přestane být lineární pole praktické. Takže Davidův patch vytváří samostatnou datovou strukturu ve formě spojového seznamu, která se používá pro ten nesekvenční rozsah popisovačů souborů. Druhá část sady patchů opravuje systémové volání dup2(), aby používalo nový rozsah popisovačů. Běžné chování dup2() se nezměnilo, ale pokud je cílový popisovač souboru předán jako FD_UNSEQ_ALLOC, bude z nesekvenční oblasti alokován náhodný popisovač souboru. Specifický popisovač z této oblasti lze vyžádat předáním čísla vyššího než FD_UNSEQ_BASE.
Takový přístup má výhodu v tom, že nevyžaduje žádná nová systémová volání nebo změnu výchozího uživatelského binárního rozhraní. Ale podle Ulricha Dreppera není takový atribut žádná výhoda. Protože využívání této možnosti stejně vyžaduje změny v aplikacích, tak už by Ulrich raději viděl nové systémové volání. Navrhuje:
AbcLinuxu.cz
ITBiz.cz
HDmag.cz
AbcPráce.cz
int nonseqfd(int fd, int flags);
Toto systémové volání by duplikovalo otevřený popisovač souboru fd do nesekvenčního prostoru, volitelně by bylo možné při té příležitosti fd zavřít. Parametr flags by umožňoval kontrolu nad dalšími atributy nového popisovače. Obzvláště důležité je, jestli se popisovač objeví v adresáři /proc/pid/fd. Optimálním způsobem zavírání všech otevřených popisovačů souborů je totiž prosté přečtení tohoto adresáře, což ukáže, které popisovače jsou otevřené. Budou-li speciální popisovače drženy mimo tento adresář (například by mohly být přesunuty do paralelního adresáře private-fd), zabrání to aplikacím, aby, byť v dobrém úmyslu, uzavřely popisovače knihovny.
Bylo také navrženo, že by systémové volání open() mohlo mít příznak, který by způsobil zvolení nesekvenčního popisovače už od začátku, takže by nebylo nutné mít samostatné volání nonseqfd(). Existuje však dost systémových volání, která vytvářejí popisovače souborů, ale nemají parametr pro příznaky, takže by nebyla schopna vracet nesekvenční popisovače; klasickým příkladem je socket(). Bude tedy potřeba mít systémové volání, které dokáže popisovač nakopírovat do nového prostoru.
Ulrich navrhl, aby byly všechny popisovače souborů v nesekvenčním prostoru alokovány náhodně. Nerad by se dočkal situace, kdy si budou vývojáři aplikací myslet, že se mohou spolehnout na jakékoliv specifické chování při využívání tohoto prostoru. Objevily se také návrhy, že by nesekvenční prostor mohl být užitečný pro vysoce výkonné aplikace, které drží velká množství otevřených popisovačů souborů - například webové servery. Takové aplikace většinou nepotřebují záruku "nejnižšího dostupného popisovače" a s radostí by se obešly bez režie, kterou implementace této záruky přináší. Nevypadá to však, že by byla aktuální Davidova implementace psána s ohledem na tisíce nesekvenčních popisovačů.
Ulrich také pracoval na vyřešení souběhu [race condition], který se projevoval u určitých druhů aplikací. Pokud proces provede exec(), je možné požadovat automatické uzavření popisovače; k tomu se používá systémové volání fcntl(). Potíž je v tom, že mezi vytvořením popisovače (třeba pomocí volání open()) a následným voláním fcntl() uplyne nějaký čas. Pokud se jiné vlákno rozdělí a spustí nový program v době mezi těmito dvěma voláními, nebude mít jeho kopie nového popisovače nastaven příznak zavřít-při-exec, a ten tedy zůstane otevřen.
Obecné řešení problému chvíli potrvá, ale oprava případu s open je poměrně jednoduchá. Ulrich pro tento účel navrhuje nový příznak O_CLOEXEC. Nezdá se, že by byl někdo proti, takže se nový příznak možná objeví v 2.6.23.
Uživatelé jader 2.6.22-rc si pravděpodobně všimli občasných varování a tracebacků souvisejících s alokacemi nulové délky. V jádře je totiž kód, který po kmalloc() požaduje alokace objektů s nulovou velikostí. Nikdo pořádně nevěděl, jak často se to stává, dokud nebylo začleněno varování (jako součást sady patchů se SLUB alokátorem); když se teď ty případy ukazují, tak to vypadá, že rozhodování o tom, co s tím, bude těžší, než by si kdo myslel.
Jednou možností je vracet NULL. Na první pohled by to dávalo smysl; volající požadoval, aby nebyla alokována žádná paměť, a kmalloc() mu vyhověl. Problém je s tím, že ukazatel NULL už má spoustu významů. Říká, že alokace selhala (což se nestalo - vždycky zbývá dost paměti na to, aby se dalo alokovat dalších nula bajtů), a často se používá pro označení faktu, že nějaká konkrétní struktura nebo subsystém nebyly inicializovány. Kromě toho to vypadá, že se občas vyskytne situace, při které by alokace nulové délky nemusela být nutně chybná; vezměme si například alokaci struktury, která byla v důsledku jaderných konfiguračních voleb optimalizována až na nula členů. Takové případy by šlo obcházet, ale není jisté, že by přidávání dalších kliček a výhybek stálo za tu námahu, když je možné nulové alokace řešit v rámci kmalloc().
Další možností je vracet nejmenší objekt, jaký kmalloc() zvládne - v současné době osm bajtů. Tak to ostatně kmalloc() potichu dělalo roky. Takové řešení sice patrně funguje, ale má tu nevýhodu, že vrací paměť, do které lze zapisovat. Ačkoliv jsou nulové alokace zjevně korektní, těžko hledat někoho, kdo by si myslel, že dává smysl ukládat do nulových kousků paměti. Ve většině případů by se tam nevešla ani vysoce zkomprimovaná data. Lidé, kteří se zabývají odhalováním chyb, by byli raději, kdyby jádro při každém pokusu o zápis do paměti alokované pomocí kmalloc(0) hlasitě protestovalo.
Což nás přivádí ke třetí možnosti: patch od Christoph Lametera, který nutí kmalloc(0) vracet speciální hodnotu ZERO_SIZE_PTR. Jde o ne-NULL hodnotu, která se tváří jako normální ukazatel, ale způsobuje chybu při každém dereferencování [použití odkazované hodnoty]. Při kfree() s touto speciální hodnotou bude samozřejmě provedena správná akce.
Vypadá to, že poslední možnost míří tím správným směrem, protože umožňuje alokace s nulovou délkou, aniž by se snažila maskovat nějaké pozdější nesprávné chování. Překvapivě se však objevila stížnost i v tomto případě: každé volání kmalloc(0) pak vrací stejnou hodnotu. Člověk by myslel, že to nebude problém; následné nulové alokace budou od sebe vzdáleny nula bajtů, přesně jak to říká C standard. Jenže někteří vývojáři mají obavy, aby to nezmátlo kód, který porovnává ukazatele, aby zjistil, jestli jsou dva objekty totožné. Navíc je zjevně v uživatelském prostoru běžné, že se nulové alokace používají jako způsob generování unikátních hodnot cookies. Pokud by všechny nulové alokace vracely stejný ukazatel, přijdou tyto cookies o svou unikátnost.
Nevypadá to však, že by si kvůli tomuto problému někdo dělal vrásky; Linus píše:
Když už jsou líní si vytvořit "generátor náhodných ID", tak by se aspoň ksakru mohli naučit používat "kmalloc(1)" místo "kmalloc(0)", aby dostali svoje unikátní cookie. Chtít po alokátoru, aby dělal idiotské věci jen proto, že si nějaký idiot myslí, že alokátor paměti je alokátor cookies, to je prostě ujetý.
Dokáži pochopit, že u věcí, jako jsou uživatelské knihovny, je potřeba brát ohledy na bláznivé lidi - ale u interních jaderných knihoven to tedy určitě nutné není.
Přičtěte si k tomuto komentáři skutečnost, že v rámci jádra ještě nikdo takové využití kmalloc() nevymyslel, a argumentaci s "unikátním cookie" dojde dech. Patch s ZERO_SIZE_PTR a bez varování se tedy v nějaké podobě pravděpodobně dostane do jádra, ale asi ne dříve než v 2.6.23.
Výrobci hardwaru pro bezdrátové síťování si během let vymysleli velkou a nápaditou hromadu důvodů, proč odmítají dávat k dispozici svobodné ovladače a hardwarové informace o svých produktech. Jedním z těchto důvodů je i dodržování regulací; kdyby mohly nedůvěryhodné třetí strany upravovat ovladače pro bezdrátová zařízení, mohly by také (nevědomky nebo úmyslně) zařízení naprogramovat tak, aby fungovalo mimo rámec frekvencí a úrovní výkonu povolených v dané oblasti. Někteří výrobci zjevně věří, že by mohli být viněni z toho, co lidé s jejich hardwarem dělají - zvláště v těch částech světa, kde jsou regulace pro využití spektra poměrně přísně prosazovány. Ačkoliv jsou v této souvislosti často zmiňovány Spojené státy, lidé z oboru se více obávají Japonska. Každopádně tyto regulace existují na celém světě (různé regulace) - a od linuxového systému s radiovými vysílači se očekává, že je bude dodržovat.
Proto Larry Finger nedávno představil novou verzi svého návrhu na mechanismus, který by Linuxu umožnil provozovat bezdrátové adaptéry v souladu s právními požadavky. Schéma je založeno na vytvoření databáze popisující regulační režimy v různých částech světa. Při startu systému by uživatelský démon (nějak) zjistil, kde se systém nachází, získal by z databáze příslušné parametry a nakrmil jimi subsystém mac80211, který by instruoval ovladače, jak zařízení naprogramovat. Pokud by nebyly požadované informace získány z uživatelského prostoru, využilo by jádro minimální konfiguraci, o které by se vědělo, že je povolena všude - za předpokladu, že taková existuje.
Objevilo se několik zajímavých reakcí, počínaje připomínkou, že vrstva mac80211 není vhodným místem pro regulační modul. Existují bezdrátové adaptéry pln kompatibilitou s MAC, které mac80211 nevyužívají, i když se jich otázka regulace týká také. Kromě toho mohou linuxové systémy obsahovat i jiné vysílače, například Bluetooth atd. Pokud bude do jádra přidán takovýto způsob pojistky pro dodržování regulací (a odstraněn z různých ovladačů, ve kterých už je), bylo by lepší ho přidat jen jednou tak, aby fungoval ve všech situacích. Ukázalo se, že podobné cíle měl modul "frequency broker" [vyjednavač frekvence], ale jeho vývoj se moc daleko nedostal.
Pro některé uživatele je příliš horlivé vynucování regulací starostí navíc. Mezi uživateli Linuxu jsou i lidé, kteří mají licence umožňující širší využití spektra. Je pochopitelné, že by rádi využívali svůj hardware (je-li takového využití schopen) způsobem, který by jim umožňoval vytěžit z volnějších limitů maximum. Pokud by jádro nakonec obsahovalo regulační mechanismus, který by nešlo přenastavit, bránilo by to některým uživatelům v něčem, na co mají právní nárok. Aspoň do chvíle, než by se ponořili do kódu a regulační mechanismus vypnuli.
Samozřejmě, pokud mohou regulační mechanismus obejít ti, kteří smějí, pak to mohou udělat i ostatní. Což vede k otázce, jestli je vůbec možné, aby byl regulační režim implementovaný ve svobodném softwaru vůbec kdy z hlediska úřadů dostatečný. Luis Rodriguez poukázal na dubnové rozhodnutí (PDF) Federální komise pro komunikaci [U.S. Federal Communications Commission], které napovídá, že by s tím mohly být problémy:
Komise se nezabývala možností, že by výrobci pro implementaci bezpečnostních opatření používali open source software. Připouštíme však, že hardwarová a softwarová bezpečnostní opatření, která spolupracují s open source softwarem, nemusejí být vázána open source smlouvou. V souladu se záměry Cognitive Radio Report and Order [Zpráva a nařízení týkající se poznávacího radia] a žádosti firmy Cisco tímto stanovujeme, že by výrobci neměli záměrně zveřejňovat charakteristické prvky používané pro implementaci bezpečnostních opatření v softwarem definovaném rádiu, pokud by to zvýšilo riziko proražení nebo jiného obcházení, které by umožnilo provoz rádia způsobem porušujícím pravidla Komise. Systém, který je zcela závislý na open source prvcích, bude jen velmi těžko prokazovat, že je dostatečně bezpečný na to, aby mohl být autorizován jako softwarem definované rádio..
(Zvýraznění doplněno.)
Nebude-li pro regulační úřady svobodný svobodný regulační mechanismus nikdy dost dobrý, stojí za to si položit otázku, jestli má vůbec cenu, aby vývojáři linuxového jádra na implementaci takového modulu vynakládali úsilí. Dalo by se argumentovat tím, že prvozování vysílačů v souladu s jejich licencováním je správná věc, bez ohledu na to, jestli to státní orgány považují za dost bezpečné. Jenže hlavním cílem je snaha uchlácholit státní orgány, takže jediným možným způsobem bude asi provést to, co už udělal Intel - přesunout regulační kód zpět do firmwaru zařízení, tj. zcela mimo hostitelský operační systém. Tento přístup přináší další výhodu v tom, že odstraňuje jednu z výmluv, proč nevydávat svobodné ovladače.
Nástroje: Tisk bez diskuse
Tiskni
Sdílej:
Proto Larry Finger nedávno představil novou verzi svého návrhu na mechanismus, který by Linuxu umožnil provozovat bezdrátové adaptéry v souladu s právními požadavkyPředpokládám, že si výrobci HW najdou jinou výmluvu, oblíbené jsou třeba smlouvy s třetími stranami.
Jde o ne-NULL hodnotu, která se tváří jako normální ukazatel, ale způsobuje chybu při každém pokusu o zrušení odkazu na ni [dereferencing].
Nejsem si jistý, jaký je oficiální český výraz pro deferencing, asi bych napsal použití (nebo klidně dereferencování, ať si obrozenci prskají), ale zrušení to nebude zcela určitě.
Referencing má význam spíš "odkazovat se na něco". Dereferencovat pointer znamená prostě použít hodnotu, na kterou se odkazuje. V daném kontextu to znamená, že
char* p = kmalloc(...); char c = *p;
způsobí chybu.
x=x+1;), takže možná proto mají lidé problém pochopit ukazatele :)
Hmm, někteří lidé zase mají problém pochopit bindingy. 
x=!x+1. Jiste sam citete, ze leve x je misto v pameti, kdezto prave x je hodnota.
Nejsem expert na jazyky, ale me tento jev ucili pod pojmem implicitni dereference. Mozna ze mluvime o teze veci.
Mimochodem, máte příklad takových jazyků? Rád bych konkrétní názvy, abych si mohl něco dohledat.
i = deref(i) + 1 - to přeci nedává smysl, ne? Buď je levé i adresa, když je třeba ho dereferencovat, nebo pravé i dereferencovat vůbec nejde, ne? Taky nemůžu napsat p_i = *p_i + 1 (nebo můžu, ale bude to nesmysl). Buď to, nebo je chápání operátoru přiřazení autorem poněkud divné. Nebo mě jen možná mate vysoce abstraktní sémantika places v Lispu, kde se fakt jen šoupe s obsahem přihrádek.
i = i; a i = 1;. Přiřazovátko je typu (proměnná)=(hodnota). V prvém případě musím vyhodnocovat adresu i, v druhém nemusím. Tento krok navíc, který uživatel nemusí zapisovat, se nazývá implicitní dereference. Pokud by tomu tak nebylo, byl by příkaz 1 = 1 v pořádku, což jistě není. C je tímto prolezlé, tudíž práce s ukazateli a explicitní dereference (a reference) se v učebnicích vysvětluje, kdežto implicitní derefernce se bere za samozřejmost.
Do stejné kapitoly patří implicitní type casting. Např. int i; long int j; i + j; V tomto případě programátor nemusí nic řešit. V C by snad i prošlo, kdyby jeden z nich byl float. Avšak v jazycích, které umožňují parametrický polymorfimus (např. C++), by již podobné výstřelky mohly vyjít pěkně draho.
Implicitní derefencování striktně rozlišuje mezi hodnotou a proměnnou. Proměnnou považuje za ukazatel do paměti, kde hodnotu ukazatele, adresu, nelze programátorsky změnit (něco jako const * int, jenže tady dochází k dvojí dereferenci).
Pokud mluvíte o Lispu, tak je třeba mít na paměti, že se jedná o funkcionální jazyk. A takové jazyky a zvláště ty, které se snaží o referenční transparentnost, si mohou dovolit mnoho zjednušení a předpokladů, co se týče vyhodnocování výrazů.
"Někteří výrobce zjevně věří, že by mohli " vyrobce -> vyrobci.Díky, opraveno.
Jsem pro "dereferencovani", popisovačů souborů => file descriptoru, nízkoúrovňové komunikaci => low-level komunikaci, jmenný prostor => namespace, nové systémové volání => novy system call, příznaky => flagy, atd. atd.Dereferencování už je probíráno výše - bohužel jsem tam nepochopil pravý význam. Za ostatními výrazy si však stojím a nebudu je psát anglicky, když pro ně existují výstižné a jednoznačné překlady. V případech, kde by to nemuselo být zcela zřejmé, uvádím původní výraz do závorky (nebo naopak - ponechávám původní výraz a do závorky uvádím popisný český překlad).
btw, "jmenný prostor" ma tiež niečo do seba
namespaceAfaik je jmenný prostor v češtině terminus technikus
jako by nekdo prekladal printf() na vytisknif(), struct na struktura, exit() na konec()Což však nedělám
Pro ostatní zmiňované pojmy (kromě alokace - ten také nepřekládám) platí to, co jsem psal výše: nebudu je psát anglicky, když pro ně existují výstižné a jednoznačné překlady. V případech, kde by to nemuselo být zcela zřejmé, uvádím původní výraz do závorky (nebo naopak - ponechávám původní výraz a do závorky uvádím popisný český překlad).
Důvodem je to, že článek není určen pouze programátorům - zatímco programátor by neměl mít problém s pochopením např. slova "nízkoúrovňová", laik a/nebo neangličtinář by pravděpodobně výrazu "low-level" neporozuměl.
28.6.2007 13:48
29.6.2007 14:06
1.7.2007 15:43