Open source počítačová hra na hrdiny NetHack (Wikipedie, GitHub) byla vydána v nové verzi 5.0.0. První verze této hry byla vydána v roce 1987.
Evropská komise naléhavě vyzvala členské státy EU, aby kvůli ochraně nezletilých na internetu urychlily zavádění unijní aplikace pro ověřování věku a zajistily její dostupnost do konce roku. Členské státy mohou zavést aplikaci EU pro ověřování věku jako samostatnou aplikaci nebo ji integrovat do takzvané evropské peněženky digitální identity.
Richard Biener oznámil vydání verze 16.1 (16.1.0) kolekce kompilátorů pro různé programovací jazyky GCC (GNU Compiler Collection). Jedná se o první stabilní verzi řady 16. Přehled změn, nových vlastností a oprav a aktualizovaná dokumentace na stránkách projektu. Některé zdrojové kódy, které bylo možné přeložit s předchozími verzemi GCC, bude nutné upravit.
Zulip Server z open source komunikační platformy Zulip (Wikipedie, GitHub) byl vydán ve verzi 12.0. Přehled novinek v příspěvku na blogu.
Před 30 lety, tj. v úterý 30. dubna 1996, byl spuštěn Seznam.cz.
Byly zpracovány a zveřejněny všechny videozáznamy, které stojí za zveřejnění, z konference FOSDEM 2026.
Od úterý 28. dubna musí nově uváděné notebooky v Evropské unii podporovat nabíjení přes USB-C. Jednotná nabíječka byla schválena Evropským parlamentem v říjnu 2022.
Byly publikovány informace o kritické zranitelnosti CVE-2026-31431 pojmenované Copy Fail v Linuxu, konkrétně v kryptografii (AF_ALG). Běžný uživatel může získat práva roota (lokální eskalaci práv). Na všech distribucích Linuxu vydaných od roku 2017. Pomocí 732bajtového skriptu. V upstreamu je již opraveno. Zranitelnost byla nalezena pomocí AI Xint Code.
Textový editor Zed dospěl do verze 1.0. Představení v příspěvku na blogu.
Vývojáři svobodného 3D softwaru Blender představili (𝕏, Mastodon, Bluesky) nejnovějšího firemního sponzora Blenderu. Je ním společnost Anthropic stojící za AI Claude a úroveň sponzoringu je Patron, tj. minimálně 240 tisíc eur ročně. Anthropic oznámil sponzorství v tiskové zprávě Claude for Creative Work.
Jsem zakladatelem tohoto portálu. Linux jsem používal spousty let, nějaký čas jsem se aktivně podílel na jeho propagaci v Česku (CZLUG, časopisy ComputerWorld, Network Magazine atd). Se současným Abíčkem už nemám nic společného.
Na základě minulé diskuse o programátorských dotazech v poradně jsme se s Robertem rozhodli, že uděláme více poraden. Nastřelil jsem první návrh jejich členění, když se v diskusi objevil zajímavý nápad, jak na problém jít jinak. Dosud jsme se snažili mít co nejvíce fór v poradně, abychom poskytli co nejpřesnější tématické členění. A každý si mohl sledovat fórum svého zájmu. Nicméně mnozí čtenáři na nějaké členění kašlali a pokládali dotazy v prvním formuláři, na který narazili. Mnohdy byla kombinace dotazu a zvoleného fóra řekněme zvláštní. Horší ale bylo, že prakticky nikdo takto špatně zařazené dotazy nehlásil, takže je správci nemohli přesunout do správného fóra. Navíc pro některé dotazy bylo těžké určit, které fórum je nejlepší.
Návrh je tedy elegantní - fóra zrušit, zavést štítky. Při zadání dotazu se provede analýza textu a dotazu se automaticky přiřadí štítky. Čtenáři pak sami budou moci přidat či odebrat štítky. Kliknutím na štítek se zobrazí další dotazy označené tímto štítkem. Ve výpise diskusí (zruší se současná fóra) bude filtr, kde si budete moci omezit výběr podle určitého kritéria. Například dotazy se štítkem nvidia a bez štítku ubuntu.
Z důvodu použitelnosti nepřipadá v úvahu ovládání přes klasické formuláře či odkazy. Tato funkce bohužel bude muset záviset na javascriptu a bude psána přes AJAX. U seznamu štítků bude odkaz Upravit, které změní tuto oblast na dvě. V jedné bude seznam vybraných štítků s linkem odebrat. Druhý bude automaticky dotahovaný abecedně řazený seznam všech štítků. Když na některý kliknete, štítek se přidá do druhého seznamu. Všechny změny se dějí okamžitě, bez potvrzování či odesílání formulářů. Prostě jako gmail. Kdo přidal či odebral značku, nebude nikde vidět, jen se to uloží do logu, jako způsob detekce škůdců.
Administrátoři budou moci přidávat nové štítky. Každý štítek bude mít ascii kód, lidské jméno a seznam klíčových slov pro automatickou detekci. Jedno klíčové slovo může být použito pro více štítků. Štítky budou fungovat na veškerý obsah, tedy i na zprávičky, články, wiki atd.
Až se dostanu k Visiu, nakreslím mockup, jak bych si to představoval konkrétně. Snad je zatím ten textový popis dostatečný. Jaký máte názor? A jak moc by vadilo AJAX řešení? Vždy jsme měli zásadu, že důležité funkce musí fungovat i v textových prohlížečích, jenže neveřím, že formulářové ovládání štítků by někdo používal. Viz hodnocení, které pro nízký zájem chce Robert úplně zrušit. Takže proto bych zde udělal výjimku a napsal příjemné ovládání přes AJAX.
Tiskni
Sdílej:
Vždy jsme měli zásadu, že důležité funkce musí fungovat i v textových prohlížečích, jenže neveřím, že formulářové ovládání štítků by někdo používal.Neřek bych, že jde o tak stěžejní funkci, aby musela fungovat i v textovejch browserech. A jiný použitelný řešení asi neni. Neviděl bych v tom zásadní problém. Většina lidí používá textový browsery asi jen v nouzovejch případech a tam je stejně bude nejvíc zajímat vyhledávání, pokud sem přijdou svůj nouzovej případ řešit. Pokud tam bude možný pracovat se štítkama, myslim, že bude spokojenost všude.
Pokud jde o systemove veci, zadne zamykani nebude, cele to musi fungovat asynchronne a bez rizika zamrznuti. I z duvodu pouzitelnosti by bylo krajne nevhodne, aby uzivatel musel cekat, az nekdo jiny dokonci editaci znacek nebo mu vyprsi timeout. Muj navrzeny konkurentni pristup je mozna zivelny a muze se jevit chaoticky, ale urcite bude pohodlnejsi.
Navic nechapu, proc omezovat primitivni zapisy do databaze. Od toho tu databaze je, aby se s ni pracovalo. A jelikoz design bude asynchronni, nebudou tyto requesty nikoho brzdit.
Ta poznamka o jetty je dobra, mozna ji udelame. Jen musim overit, jak se to bude chovat k sessione. Rozhodne nesmim zapomenout na securitu, aby asi nejaky chytrak nenapsal kod, ktery treba odstrani vsechny stitky. Mozna by to chtelo udelat jeste nejakou archivni tabulku. Jen pro jistotu. Dalo by se s ni pracovat lepe nez s logem.
. Ta klíčová slova se mi nejprve moc nepozdávala, ale jak jsem se trochu zamyslel, dává to smysl.
Třeba - kód python, název Python, slova - interpret, python, skript. Pravděpodobně bude kód tagu zároveň jedno klíčové slovo, nebo ne?
).
, ale kdež, vždyť to o Jave opravdu JE! V další větě můžou být uvedeny důvody, a pak to dokonce i dává smysl (oštítkovat).
(obecně) Nestrkat komplikace, kde není potřeba; čím jednodušší to bude, tím spíše je šance, že to bude dávat rozumné(!) výsledky.
čím jednodušší to bude, tím spíše je šance, že to bude dávat rozumné(!) výsledky.Pokud bude ten algoritmus primitivní, tak to ani nemá moc cenu -- stejných výsledků dosáhnu s normálním fulltextovým vyhledáváním. Přinos by byl v tom, kdyby texty prošly nějakou hlubší analýzou a ta jim přiřadila štítky. Pokud se ty štítky budou automaticky přiřazovat jen nějak jednoduše, byl bych proto, aby se přiřazovaly střídmě -- je lepší mít méně oštítkovaného obsahu (ale kvalitně) a zbytek si prohledat fulltextem, než tam nalepit štítků, co to jen jde, a pak se divit, že je ten systém zahlcený a nedá se v něm vyznat (spousta chybně přiřazených štítků, přes které pak člověk nevidí to, co skutečně hledá).
Jaký máte názor?To zní dobře.
A jak moc by vadilo AJAX řešení?Mě osobně vůbec, nevím co to je
možno by nebolo od veci zaviesť stromovú štruktúru "štítkov" ... základ tak ako sú teraz diskusie, ale jeden formulár a nechať všetko na useroch. Možno spôsob ako na last.fm je použiteľný, aj keď, diskusie nie sú dlhodobá záležitosť.
tam napr označenie "Brutal Death" má význam len pod väčším "Metal" ... podobné väzby imho vzniknú i tu.
hmm, rozšíriť tento systém i napr na FAQ a pod ...
Nezdá se mi, že je (teoreticky) možné rozumně přiřadit štítky jen podle obsahuprotože jsem to pochopil jako, že to vůbec nemá cenu zkoušet. Podle mě by to vedlo k tomu, že by většina dotazů skončila bez štítků. Svým komentářem jsem chtěl podpořit tvrzení, že přiřazování podle obsahu s následnou možností změny je v podstatě nutnost.
. Akorat jeste planuju nejakou cache, at minimalizuju pocet SQL requestu. Je to v cvs, pokud se nekdo chce podivat.