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.
Nadace GNOME ve spolupráci s Endless spustila Community Engagement Challenge. Cílem této výzvy je přitáhnout k open source novou generaci vývojářů. Máte-li nápad, jak toho dosáhnout, můžete se přihlásit do 1. července. Mezi vybrané projekty bude rozděleno 65 000 dolarů.
Tiskni
Sdílej:
Když pošleš nějaký užitečný patch, tak proč ne? Co zajímavého jsi pod tímto jménem zatím vytvořil a publikoval?
Nejsou. Tak čím tedy chceš přispět nebo čím jsi už někam přispěl?
odin je jinak určitě jako moc fajn a určitě by mu jako udělalo radost kdybys vodešla vod neomarxistů a židozednářů ;D ;D
si totiž myslim že nazi open source vývojářů je děsně málo tak tamten jako musí bejt jedině unser gutiger odin :O :O :D :D ;D
Svobodný software se většinou vyvíjí distribuovaně a ti lidé se nepotkávají, často se znají jen pod nějakou přezdívkou nebo jménem, ale nikdy se neviděli. Nemusíš s nikým chodit na oběd. (srovnej si to s klasickým zaměstnáním, kde se s těmi lidmi musíš stýkat osobně každý den a navíc máš na výběr jen z firem v okolí tvého bydliště)
Nicméně zapojit se do cizího projektu je někdy obtížné i pro bílého heterosexuálního muže (a to nemluvím o té technické/programátorské stránce – ta může být totiž paradoxně lehčí). Tak doporučuji nehledat neexistující souvislosti a domnělé antipatie – začátky můžou být těžké pro každého. Tak si z toho nic nedělej a pokračuj dál.
V tom případě asi fork.
Komu se to nechce číst celé – nejdůležitější odstavec:
But last week, the company suddenly informed both the KDE e.V. board and the KDE Free QT Foundation that the economic outlook caused by the Corona virus puts more pressure on them to increase short-term revenue. As a result, they are thinking about restricting ALL Qt releases to paid license holders for the first 12 months.
Nicméně neviděl bych to nijak tragicky. Svobodný software je nezničitelný a žádná firma ho nemůže zastavit – tohle oznámení je potřeba brát tak, že možná odpadl velký přispěvatel, ale na tom svobodném softwaru jako se nemění nic. Jestliže je dnešní verze Qt dostatečně dobrá a dá se na něm stavět desktop, bude dobrá i zítra. Jen ten vývoj bude pomalejší, ale to někdy vůbec není na škodu.
buďto plať nám, nebo si pořiď 3 vývojáře, a vyvíjej si sám.
A co bys čekal? Že ti bude navěky poskytovat nějakou službu (vývoj, podporu…) zadarmo? Proč by to dělal? Proč by měl mít takovou povinnost?
Na rozdíl od toho proprietárního softwaru tady máš možnost vzít si poslední verzi a vyvíjet si ji sám nebo si zaplatit někoho (kohokoli dle svého výběru), kdo ti tu službu poskytne. Tohle je obrovská výhoda oproti proprietárnímu softwaru, kde jsi odkázaný na monopol původního autora. U svobodného softwaru tahle závislost není. Ano, jednoho dne může „vyschnout pramen“ a ten, kdo dřív dělal něco zadarmo pro ostatní, to přestane dělat – ovšem to znamená, že se situace přestane (zadarmo) zlepšovat, nikoli, že by se zhoršila. Pak je na ostatních, kdo nastoupí místo něj a bude pokračovat ve vývoji. Ale to dobré, co se do té doby stalo, to nezmizí. Díky svobodné licenci to nemůže zmizet, nejde to vzít zpět.
Na tohle není potřeba GPLv4, tohle lze realizovat se současnými licencemi, třeba s GPLv3. Stačí, aby přispěvatelé nepřeváděli svoje autorská práva na hlavního autora nebo mu neposkytovali neomezenou licenci (typicky nějakým CLA). Tzn. stačí, aby přispěvatelé svoje patche posílali jen s GPLv3 licencí a neposkytovali žádnou další ani nepodepisovali žádnou další smlouvu. Hlavní autor pak může jejich příspěvky začlenit a pokračovat ve vývoji, ale nemůže změnit licenci (třeba na tu proprietární).
Nemám úplně vyhraněný názor na to, zda to takhle dělat nebo ne. Každý z těch přístupů má něco do sebe, jeden dává jistotu, že licence bude pořád stejná, zatímco druhý umožňuje třeba duální licencování, což je možnost, jak získat peníze a podpořit rozvoj toho svobodného softwaru. Nebo jde upgradovat licenci, jako když se objeví nějaké nové hrozby (např. upgrade z GPLv2 na GPLv3).
Svým způsobem je to podobná diskuse jako copyleftové vs. necopyleftové licence. Tam se kloním (pro většinu softwaru) k těm copyleftovým. Necopyleftové licence umožňují změnit licenci komukoli, copyleftové jen autorovi a ten postup popsaný v prvním odstavci to neumožňuje ani autorovi. Z mého pohledu je optimální copyleftová licence s tím, že autor může využít i duální licencování nebo povýšit licenci na novou verzi. Ten (trochu extrémní) třetí případ může dávat někdy smysl, ale spíš bych se držel toho copyleftu. Přeci jen, když něco vytvořím a investuji do toho spoustu času, tak by mi to mělo patřit a měl bych mít právo s tím nakládat dle svého (a svobodná licence zároveň zaručuje, že nemůžu sebrat práva ostatním). Pak jsou projekty, kde není „jeden hlavní autor“ a jde o kolektivní dílo – tam dává víc smysl ten třetí přístup, kdy licenci nemůže změnit nikdo.
Další možnost je, že se předem definuje proces, jak tu licenci lze případně měnit, aby to respektovalo zájem většiny přispěvatelů, ale nebylo potřeba žádat individuální souhlas od všech (často nemusí být možné je už vůbec kontaktovat).