Po velkém úspěchu prvního MobileLinux Hackdaye se vracíme do Českých Budějovic s druhým ročníkem. V pátek 30. října 2026 od 10:00 se v prostorách Jihočeské univerzity uskuteční Embedded & MobileLinux Hackday #2. Těšit se můžete na témata jako Immutable Linux na telefonech (BengalOS), U-Boot a upstream vývoj, AI optimalizace pro embedded systémy nebo otevřený hardware. Nebude chybět praktické hackování, sdílení zkušeností a možnost … více »
Dne 21. října 2026 vydal projekt Node.js bezpečnostní aktualizace opravující deset zranitelností, včetně jedné umožňující potenciální vzdálené spuštění kódu (RCE). Nejzajímavější je CVE-2026-111497, chyba dekodéru Brotli, kterou objevili výzkumníci využívající OpenAI Codex Security. Chyba je v nativním dekodéru Brotli, nikoli v samotném JavaScriptu. Speciálně vytvořený komprimovaný vstup způsobí, že dekodér zamění
… více »Francouzský výrobce kabelů Nexans upozornil na napjaté dodávky elektrických kabelů. Výstavba nové výrobní linky pro některé typy kabelů může trvat přibližně tři roky. Datacentra potřebují rozsáhlé nízkonapěťové a středněnapěťové rozvody. Poptávka roste současně s modernizací elektrických sítí. Někteří odběratelé proto uzavírají výrazně delší dodavatelské smlouvy [Reuters].
Představena byla (𝕏) virtuální platforma FLYBENCH FPV, která nováčky provede zapojením a konstrukcí dronů.
Google Chrome 156 byl prohlášen za stabilní. Přehled novinek v poznámkách k vydání. Opraveno bylo 353 bezpečnostních chyb. Vylepšeny byly také nástroje pro vývojáře.
Indická společnost eMudhra po bezpečnostním incidentu, tj. kompromitaci soukromých klíčů osmi mezilehlých certifikátů své certifikační autority, opouští globální byznys s SSL/TLS certifikáty.
Dle Phoronixu zveřejnila společnost Trend Micro prostřednictvím programu Zero Day Initiative (ZDI) několik hlášení bezpečnostních zranitelností přímo na veřejném mailing listu LKML, přestože některé chyby dosud nemají opravu začleněnou do hlavní větve jádra. Mezi hlášenými problémy jsou dvě zranitelnosti s hodnocením CVSS 9.0, týkající se SMB Direct a KSMBD, které mohou umožnit vzdálené spuštění kódu. Další hlášení se týkají … více »
Správce hesel KeePassXC byl vydán ve verzi 2.8.0. Přechází na Qt 6, podporuje vkládání hesel s Waylandem, rychlé odemykání pomocí Polkitu nebo možnost nastavení klávesových zkratek (seznam změn).
Databáze DuckDB (Wikipedie) byla vydána ve verzi 2.0.0 LTS. S kódovým názvem Cinnamon Teal (čírka skořicová). S vyladěným protokolem Quack.
V implementaci Broadcom 802.11 byla zjištěna chyba ve zpracování WPS/EAP, týká se to SDK od roku 2010. Broadcom podle výzkumníka Quentina Kaisera odmítl CVE přidělit. Modemy Huawei a Technicolor jsou používány i v ČR, v LTE routerech, běžných domácích routerech a firemních přístupových bodech, jejich současný počet a zranitelnost konkrétních verzí však zatím neznáme. Více detailů a demo. GitHub / Broadcom 802.11 SDK Detection Toolkit.
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.