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 2.6.23-rc8, vydaná 24. září. Obsahuje poměrně málo oprav a Linus věří, že finální vydání už se blíží: Samozřejmě, že když mám já dobrý pocit, tak obyčejně přijde nějaký padouch a najde nové problémy, ale na to se vykašlu a budu si ten pocit užívat, jakkoliv krátce potrvá.
Do hlavního repozitáře od té chvíle přibylo dalších přibližně 50 patchů.
Aktuální verze -mm stromu je 2.6.23-rc8-mm1. Mezi nedávné změny patří vylepšení ext4, podpora "bind" připojení pouze pro čtení, práce na kdump a přepracování exportního kódu NFS.
Aktuální stabilní jádro je 2.6.22.9, vydané 26. září. Obsahuje několik desítek oprav. 2.6.22.8 vyšlo 24. září s jedinou bezpečnostní opravou problému s právy ve zvukovém subsystému. 2.6.22.7, vydané 21., opravovalo také jedinou chybu: problém s právy v kódu architektury x86_64. Připravuje se větší aktualizace 2.6.22, která by měla být vydána zanedlouho.
Starší jádra: 2.6.20.20, vydané 23. září, opravuje zmiňovanou bezpečnostní chybu v x86_64 a ještě jeden problém. Řada 2.6.16 se vrátila 25. září verzí 2.6.16.54-rc1. 2.4.35.3 (23. září) rovněž obsahuje opravu x86_64 a pár dalších.
V současné době jsou sysfs soubory, které se chtějí "zabít", nuceny požádat někoho jiného (pracovní frontu), aby je zabil, což je velmi nehumánní. Tato sada patchů upravuje implementaci sysfs souborů tak, že budou moci v míru a pokoji spáchat sebevraždu.
-- Tejun Heo pracuje na soucitnějším jádře.
Obecně bývá lepší uživatelům umožnit zabezpečení vypnout, místo aby se spoléhalo na to, že si přečtou manuál a sami ho zapnou.
-- Alan Cox
Vývojáři projektu MadWifi oznámili své rozhodnutí zanechat vývoje stávajícího ovladače pro Atheros (který obsahuje část dostupnou pouze v binární podobě) a místo toho pracovat na svobodném ovladači ath5k: Abychom podtrhli naše rozhodnutí, prohlašujeme ovladač MadWifi za zastaralý [legacy]. Ath5k nakonec MadWifi nahradí. Prozatím bude MadWifi i nadále podporován, chyby budou opravovány a bude-li to možné, budeme aktualizovat HAL. Je však nepravděpodobné, že by přibývaly funkce nebo se kód nějak výrazněji měnil.
Oznámení o oživení linux-tiny, patchsetu zaměřeného na snížení náročnosti [footprint] jádra pro embedded zařízení, vedlo k několika diskuzím. Mluvilo o různých věcech; kde by měl linux-tiny růst, jestli mají být z jádra odstraněny ty spousty printk() řetězců atd.
Projekt linux-tiny založil v prosinci 2003 Matt Mackall, přičemž cílem bylo shromažďovat patche, které snižují náročnost na disk i paměť, a také nástroje pro práci na malých systémech. Na LWN se tehdy psalo o oznámení a před rokem o kódu. Mnohé věci z linux-tiny se dostaly do hlavního jádra, ale dost jich pořád zůstává mimo.
Za snahou o oživení projektu stojí Consumer Electronics Linux Forum (CELF). Plán oznámil šéf skupiny pro architekturu Tim Bird a připojil i jméno nového správce: Michael Opdenacker. První krok už je skoro dokončen; patche byly aktualizovány z jádra 2.6.14 na 2.6.22. Byla založena stránka pro sledování stavu aktualizací, ale je zřejmé, že hlavní motivací je začlenění patchů do jádra, nikoliv údržba mimo hlavní strom.
Andrew Morton se hned nabídl, že bude patche spravovat:
Vážně, dávat tyhle věci do nějaké soukromé sbírky patchů by mělo být až to poslední - to se dělá jen s patchi, u kterých se shodneme, že nikdy nemají šanci se do jádra dostat.
Reakce byly docela pozitivní a Michael Opdenacker odpověděl:
Andrew, máš úplnou pravdu... Ty patche by se všechny měly snažit dostat do jádra, nebo nepřekážet.
Měl jsem teď několik bláznivých týdnů, ale od příštího týdne ti začnu patche posílat jeden po druhém, počínaje těmi nejjednoduššími.
Zatímco se budou jednotlivé patche připravovat k začlenění, bude celý patchset v samostatném repozitáři. Je však jasné, že se nikomu nechce příliš dlouho spravovat strom mimo jádro. Patche pak mohou snadno zastarat; zařazení do hlavního jádra je naopak dostane do rukou většího počtu vývojářů.
Následovaly podrobnější diskuze o tom, jakou by patche měly mít strukturu, a jaké jsou obecně jejich funkce. Samostatná diskuze se týkala printk() a množství paměti, které všechny ty statické řetězce spolykají. printk() je už dlouho považováno za oblast, kterou by mělo jít vylepšit, aby se snížila spotřeba paměti jádra.
Pomocí printk() jsou do logů nebo na konzoli vypisovány nejrůznější zprávy; v řadě 2.6 je kolem 60 tisíc volání. Specifickým voláním může být přiřazena úroveň závažnosti, což poskytuje něco na způsob primitivní kategorizace zpráv ve stylu syslogu. Bohužel je zatím možné tato volání buď mít (a přijít kvůli řetězcům o paměť), nebo vůbec nemít (zakázat při konfiguraci před kompilací). Je dost obtížné diagnostikovat problémy bez aspoň nějakých informací, ale všechna ta data mohou zase velikost jádra zvýšit o 5 - 10 %.
Rob Landley začal pracovat na způsobu, jak umožnit zakompilování zpráv podle úrovně závažnosti. Vývojář pracující s embedded zařízením by mohl odstranit KERN_NOTICE, KERN_DEBUG a podobné zprávy s nízkou závažnosti a ponechat jen ty důležitější:
[...] kompilátor má odstraňovač mrtvého kódu [compiler's dead code eliminator] a ten vyhodí printk, která vás nezajímají, takže nebudou obraz jádra nafukovat. Ale to neznamená, že by byly printk _úplně_ odstraněny, a proto volání panic() zůstanou. Sami si přesně nastavíte, kolik toho chcete - s pomocí informací, které už v jádře jsou.
Landleyho návrh má nevýhodu v tom, že by byl potřeba nový příznak pro printk() nebo vytvoření nové funkce, která by návrh implementovala, přičemž příslušné změny by se do jádra dostávaly postupně. Mezi tím by však vývojáři programující pro malé systémy pořád hledali způsoby, jak dostat zprávy, které potřebují, a přitom ty ostatní z kódu odstranit. Debatovalo se také o použití samostatných volání pro každou úroveň závažnosti. Například pr_info() nebo podobně nazvaná funkce by byla použita pro zprávy dané úrovně. Pak by bylo možné použít preprocesor pro odstranění zpráv, které vývojáře nezajímají.
Vegard Nossum na základě této diskuze sestavil RFC o novém API pro logování jaderných zpráv. Začíná požadavkem, aby bylo API zpětně kompatibilní se stávajícím způsobem používání printk(), přičemž výstupní formát by byl rozšiřitelný buď při kompilaci nebo za běhu. RFC se také snaží řešit, jak by vícenásobná volání printk() mohla vyústit jen v jedinou zprávu, ale zdá se, že je to přetechnizované řešení otázky, která by měla být poměrně přímočará.
Dalším kandidátem je patch DoPrintk od Tima Birda. Patch už je součástí patchsetu linux-tiny a vývojářům umožňuje vybírat zdrojové soubory, u kterých bude printk() povoleno - z ostatních bude odstraněno.
Je příliš brzy se snažit odhadnout, které (pokud vůbec nějaké) změny printk() nakonec projdou. Nevypadá to, že by existoval velký zájem pomoci malým systémům snížit nároky jádra při zachování všech diagnostických zpráv.
Systémové volání timerfd() bylo přidáno do jádra 2.6.22. Hlavní myšlenka timerfd() - umožnit procesu přiřadit k událostem časovače popisovač souboru - kontroverzní není, ale implementace, poněkud opožděně, vyvolala pochybnosti. Michael Kerrisk poukázal na to, že timerfd() není konzistentní se stávajícími systémovými voláními týkajícími se časovače (a je méně výkonné než tato volání). Kromě toho verze v 2.6.22 nefunguje tak, jak by měla. Po dlouhé diskuzi začalo být jasné, že problémy s tímto systémovým voláním nebudou vyřešeny do vydání 2.6.23. Takže předverze 2.6.23-rc7 timerfd() vyřazuje z provozu, aby se vývojářům aplikací zabránilo v používání API, které bude změněno.
Kvůli tomu všemu poslal Davide Libenzi (tvůrce původního volání timerfd()) návrh na přepracované API. Jediné systémové volání se změnilo na tři různá s několika novými funkcemi.
S novým API by aplikace, která chce vytvořit popisovač souboru pro události časovače, provedla následující volání:
AbcLinuxu.cz
ITBiz.cz
HDmag.cz
AbcPráce.cz
int timerfd_create(int clockid);
clockid popisuje, které hodiny se mají použít; bude to buď CLOCK_MONOTONIC nebo CLOCK_REALTIME. Návratová hodnota bude, pokud vše proběhne v pořádku, požadovaný popisovač souboru.
Událost časovače je možné požadovat pomocí:
int timerfd_settime(int fd, int flags, const struct itimerspec *timer,
struct itimerspec *previous);
fd je popisovač souboru získaný z timerfd_create(). timer udává požadovaný čas vypršení (a interval opětovného zapnutí, je-li požadován). Tento čas je obyčejně relativní, ale pokud časovač nastaví ve flags bit TFD_TIMER_ABSTIME, bude interpretován jako absolutní čas. Pokud previous není NULL, bude struktura, na kterou se ukazuje, naplněna předchozí hodnotou časovače. Tato schopnost získat předchozí hodnotu je jednou z vlastností, které v původní implementaci timerfd() chyběly.
Stará implementace také aplikacím neumožňovala se prostě zeptat, jaká je aktuální hodnota časovače. Nové API poskytuje funkci, která to umí:
int timerfd_gettime(int fd, struct itimerspec *timer);
Toto systémové volání uloží aktuální čas vypršení (pokud existuje) přiřazený k fd do timer.
Rozhraní read() se v podstatě nezměnilo. Proces, který čte časovačový popisovač souboru, se zablokuje, pokud časovač ještě nevypršel. Pak načte 64bitovou celočíselnou hodnotu, která určuje, kolikrát časovač vypršel od posledního přečtení. Časovačový popisovač souboru může být předán funkci poll(), což časovačům umožní, aby se s nimi pracovalo v hlavní smyčce událostí aplikace [main event loop].
Reakce na nové API byly přinejlepším tlumené; snad to mlčení znamená, že už jsou vývojáři s novými systémovými voláními spokojeni. Nebo je to proto, že tato verze nebude kontrolována o nic pečlivěji než ta předchozí. Zatím to vypadá, že by nová sada systémových volání mohla být začleněna do 2.6.24.
Nástroje: Tisk bez diskuse
Tiskni
Sdílej:
Aktuální předverze je 2.6.23-rc8...No, nakonec se nějaký padouch asi našel
Nevíte někdo, co se děje? Tolik předverzí jsem k jednomu jádru ještě neviděl.
10.10.2007 22:33
Prcek | skóre: 43
| Jindřichův Hradec / Brno
11.10.2007 01:44
patchi, u kterých se shodneme… – má být patchy – ch je tvrdá souhláska a to má přednost před pádovou koncovkou (výjimkou je skloňování dle hrad – známé tácy, kecy atd. Viz Jazykovou poradnu ÚJČ.
Absolutní přednost tvrdé/měkké samohlásky před koncovkou podle skloňování je sice možná oficiálně správná, ale považuji ji (společně s kurzem a pulzem) za jednu z největších ptákovin, jaké kdy ÚJČ v rámci zjednodušování pravopisu vymyslel. Mne osobně nikdo nedonutí psát zvěrstva jako "od Nohavici" (a pokud byste se chtěl vykrucovat, že "c" vlastně není měkká souhláska, tak ani "od Maryši").
V tomto případě je navíc podle mne pochybená už úvaha, že lze "ch" na konci považovat za tvrdou samohlásku. Pokud je totiž podle vás tvrdá, tak byste to měl především přestat skloňovat podle "měkkého" vzoru stroj a použít hrad.
10.10.2007 23:19
Prcek | skóre: 43
| Jindřichův Hradec / Brno
.
)
)
):
Podstatná jména obecná – domácí a začlenitelná přejatá – Feminina – Substantivní typy – I. typ se singulárovým nominativním formantem -a (vz. „žena“)
K tomuto typu náležejí především všechna feminima mající tvarotvorný základ zakončen souhláskou morfonologicky tvrdou a dále některá jména se souhláskou obojetnou; jména s finálou měkkou mají zde postavení okrajové. Toto skloňování se nazývá tvrdé. V žádném pádě nejsou v tomto typu tvary variantní.
Celé paradigma má tedy tuto podobu:
sg N -K + -a pl N,A,V -y(i) G -y(i) G -ø D,L -ě(e) D -ám A -u L -ách V -o I -ami I -ouMalou, nepočetnou skupinu mezi jémny ženského rodu s Nsg na -a tvoří substantiva s měkkhou souhláskou na konci tvarotvorného základu, která způsobuje, že se u nich objevují prvky měkké deklinace: vedle pravidelné koncovky -e proniká do D, L sg varianta -i (moravská), a to u apelativ i rodných jmen, např. gejša, D, L gejše i gejši, (Máňa – D, L Máně i Máni). Náležejí sem nečetná apelativa cizího původu, jako doňa, dueňa, báryšna, ňaňa, vikuňa, viskačka, kombuča, gutaperča, skica. Domácích apelativ je nemnoho, řadí se sem např. káča (vlastně apelativizované Káča, domácká podoba jména Kateřina). (Větší počet rodných jmen, jako Nataša, Soňa, Zoja, zvláště hypokoristik, jako Anča, Bláže, Naďa, Táňa; viz 2.1.2.1.1b.
[viz Podstatná jména vlastní níž v tomto výtahu])
Apelativa s finálou -j („sója“) mají pevné tvary tvrdého skloňování podle vz. „žena“ pouze N, A, V a I sg, v ostatních pádech se skloňují podle vz. „růže“, tedy… [příklady]. Paradigma těchto jmen je tedy smíšené bez tvarových variant. … [opět příklady slov z této skupiny]
Podstatná jména vlastní – Skloňování jmen osobních – Feminina – Nsg zakončena na samohlásku [a], vz. „žena“
(a) Většina jmen sem náležejících se skloňuje pravidelně podle uvedeného vzoru: [příklady]
(b) Je-li před koncovým -a vyslovována souhláska měkká, píše se v Gsg -i a v D, L je podoba variantní, např. u jmen jako Naďa (Gsg Nadi, D, L Nadě, oblastně i Nadi, A Naďu atd.), Máňa (Máni), Danica (Danici), Nataša, Uša, Aglaja, Zoja, Mája (i Maja, špan. Maya), Gaja (řec. Gaia – Gsg Gaii, D, L Gaie, A Gaiu atd.). – Jména zakončená na -ia vyslovované jako [ija] mají však českou obdobu na -ie (např. Felicie) a vzhledem k tomu skloňování jiné (srov. 2.1.2.1.3 [Nsg zakončen na [-e] nebo [-ije], [-ijo], vz. „růže“]).
(c) Jména zakončená na -ea, -ua, např. Andrea, Médea, špan. Dorotea, Dulcinea, ital. Rea, afric. Efua, mají v D, L sg (na rozdíl od tvarů vzoru) koncovku -i; v souhlase s výslovností mají v některých pádech dvě pravopisné podoby: Andrea – Gsg Andrey (i Andreji), D, L Andrei (i Andreji), A Andreu, V Andreo, I Andreou.
--
Co se učí ve školách je často dost vzdálené tomu, jak je to v jazyce (kodifikováno) doopravdy. Kdo z nás třeba na základní nebo střední škole slyšel něco o adjektivním skloňování podstatných jmen? Kdo z nás slyšel o skloňování jednoho slova podle více různých vzorů? Kdo z nás slyšel o podtypech (podvzorech) mimo profláknutého hrad – les?
Skloňování podle vzrou „stroj“ sem nebudu celé opisovat, jenom stručně – finální souhláska základu je měkká, z obojetných jen -l, -s a -z. Koncovka v pl I je -i. Z přejatých slov se sem zařaují např. … skeč, smeč… [psáno už počeštěné]. Zvláštní postavení má několik jmen cizího původu se základem na -c, která zčásti náležejí k nespisovné slovní zásobě, jako tác, hec, kec, truc, frc, flanc. Skloňují se jako jména s finální kmenovou souhláskou tvrdou, tj. v Gsg tácu, hecu, kecu, trucu, v N, A, I pl tácy, hecy atd. [Dále se rozebírá paradigma zdvojené, kde se používají životné i neživotné tvary.]
Patch by se tedy měl skloňovat dle vzoru “stroj“ podle finální měkké souhlásky, výjimak se na něj snad nevztahuje žádná. Jsem zvědav, zda se taky začne psát počeštěně „peč“
10.10.2007 13:38
Marián Kyral | skóre: 29
| blog: Sem_Tam
| Frýdek-Místek
10.10.2007 15:22
Marián Kyral | skóre: 29
| blog: Sem_Tam
| Frýdek-Místek
Z logiky věci vyplývá, že když vydám první verzi programu, tak jakákoli nová funkce se přidá pomocí záplaty.A to si právě nemyslím. Záplatou se opravuje poškozená nebo vadná věc. Nepřidává se tím nová funkce. Na kalhoty se dává záplata, když jsou roztržené - ne když chci přidat další kapsu.
10.10.2007 15:44
Marián Kyral | skóre: 29
| blog: Sem_Tam
| Frýdek-Místek
10.10.2007 21:48
Marián Kyral | skóre: 29
| blog: Sem_Tam
| Frýdek-Místek
Kalhotám chybí kapsa. Z mého pohledu je to vada.Mali sme jedného takéhoto zákazníka. Objednal a zaplatil si sw ekvivalent teplákov bez vreciek a potom donekonečna prichádzal s požiadavkami na vrecká, pútka, zipsy a ozdoby, pričom argumentoval, že si objednal "nejaké nohavice" a to čo on žiada, je štandardná vlastnosť nohavíc, podľa neho sa jedná o chybu a dodané tepláky neakceptuje. Môžete hádať, ako sme ho mali radi.
To je celkem normální. Podle mých zkušeností je čestnou výjimkou spíš zákazník, který se takto nechová. U některých už jsem začal vážně uvažovat, že si od nich nechám otázky typu "Opravdu jsou tohle všechny tiskové výstupy, které budete potřebovat?" zodpovídat písemně s úředně ověřeným podpisem. Ne že by to předešlo námitkám typu "No dobře, neřekli jsme výslovně, že to má tisknout knihu hostů, ale to je přece samozřejmost, ne?", ale aspoň jim budu mít co omlátit o hlavu.
Větší legrace byla s jedním, který mne jisté designové rozhodnutí nechal dvakrát předělat tam a zpátky a pokaždé mi vysvětlil, že je přeci jasné, že to musí být takhle, protože obráceně by to mohl chtít jen naprostý blbec.
To je celkem normální.Je to bežné, ale nie je to normálne. Toľko k terminológii.
10.10.2007 19:16
zoul | skóre: 43
| blog: ☂
| Boskovice
Úplně stejně blízko má k opravě už anglické patchTo ano - ale na rozdíl od českého slova záplata je patch v angličtině už ustálen i v tom programátorském smyslu. A vzhledem k tomu, že je ten termín (i díky stejnojmenné utilitě) v češtině známý a používaný, tak mi připadá vhodnější. Ale na druhou stranu - asi bych se nenechal k používání té záplaty dlouho přemlouvat - obecně mám raději přeložené výrazy.
btw, čo tak jeden "pseudočlánok", linkovaný z JN, so zoznamom prekladov bežných termínov? Nech si i okoloidúci zvyknú zvyknú používať "ustálené preklady"
10.10.2007 13:24
Marián Kyral | skóre: 29
| blog: Sem_Tam
| Frýdek-Místek
Sice se na patchi určitě zase někdy zarazím, protože ch a měkké i pro mne vypadá hrozně, ale budu si muset zvyknout.
11.10.2007 12:52
zoul | skóre: 43
| blog: ☂
| Boskovice
Právě proto si myslím, že synonym resp. překladů je vhodné použít pro upřesnění významu asimilovaného slova, ovšem jinak je lepší používat toto slovo samotné ve smyslu v jakém bylo přejato.A co ohýbání? Zrovna v případě patche dopadá docela žalostně.
12.10.2007 17:18
Hobit | skóre: 7
| blog: Kdo si hraje, nezlobí
Taky pěkné "české" slovo.. Dle Slovníku jazyka českého z r. 1946 se psalo se "s", pochází z francouzštiny a znamená "přibližovati dnešku něco staršího"..
a pak toho nechal a dneska je to pro něj oficiálně upgrade - už se to prostě vžilo.