Oslavte vydání openSUSE Leap 16.1 s námi v Praze! Ve středu 4. listopadu 2026 (den po vydání Leapu 16.1) vás zveme na malou oslavu vydání openSUSE Leap 16.1 do pražské kanceláře SUSE. Připravili jsme pro vás dvě krátké přednášky: … více »
Dle plánu bylo PHP vydáno v nových verzích 8.5.12, 8.4.27, 8.3.36 a 8.2.35. Opraveny jsou kritické zranitelnosti CVE-2026-109618 a CVE-2026-109619 aneb PHP2Shell.
UBports, nadace a komunita kolem Ubuntu pro telefony a tablety Ubuntu Touch, vydala Ubuntu Touch 24.04-2.1 a 24.04-1.5. S opravou kritických zranitelností.
Společnost Škoda Auto zveřejnila na Printables bezplatné 3D modely příslušenství do svých vozů (držáky na nápoje, pomůcky pro vedení kabelů, mincovníky, háčky na USB kabely a čepice pro kapsy na zadních stranách opěradel sedadel, držáky na telefony a úchyty pro horní upevnění bezpečnostních pásů).
Nové číslo časopisu Raspberry Pi zdarma ke čtení: Raspberry Pi Official Magazine 170 (pdf).
Dnes v 16:00 (14:00 UTC) budou opraveny 2 kritické zranitelnosti s CVSS 9.2 v PHP.
Nizozemská policie 13. října 2026 zabavila v datacentru Amsterdam Science Park server italského poskytovatele internetových služeb Autistici/Inventati (A/I), a to na základě americké žádosti o mezinárodní právní pomoc.… více »
Do 26. října do 18:00 běží na Steamu přehlídka nadcházejících her Festival Steam Next | říjen 2026 (YouTube) doplněná demoverzemi, přenosy a dalšími aktivitami. Demoverze lze hrát zdarma.
Čínská technologická společnost DeepSeek zveřejnila na GitHubu svůj framework DeepInfer, nástroj pro efektivní offline inferenci svého modelu DeepSeek-V4.1-Flash ve velkém měřítku. Software běží na Linuxu a nativně podporuje akcelerátory Nvidia ale i čipy Huawei Ascend 950. Jedná se pouze o samotný inferenční engine, ne kompletní produkční službu. Zdrojový kód je dostupný pod licencí Apache 2.0.
Aplikační firewall OpenSnitch, GNU/Linuxový port aplikačního firewallu pro macOS Little Snitch, míří do Debianu. Požadavek #909567 na jeho začlenění byl zadán v září 2018.
Tiskni
Sdílej:
Avoid unwanted network interactions during runtime. There must be no „call home“ or update-checks without user's explicit consent.
Netrvalo to ani pět let a balíček už se (skoro) dostal do Debianu... Že by jednou přeci jenom došlo i na některé starší požadavky?
Principielně špatně je to, že žádný balíček neexistuje.A to je právě ta (ne)schopnost, na které pro včlenění toho balíku záleží. A zjevně se ještě nenašel nikdo, kdo by pro příslušný software příslušnou schopnost měl. Ale snažte se, třeba jednoho dne překonáte svoji zapšklost a povede se vám jak vyrobit balíček, tak se dohodnout s jinými lidmi

[o Debianu] - Bavit se s někým, kdo za tebou se svým tržním podílem hluboko pod 1% přijde a začne ti diktovat nesmyslné požadavky jak máš psát svůj SW je pouhá ztráta času, nic víc. - distributorem, který má tržní podíl hluboko pod 1% [ o pozadavku Debianu mit GPL hlavicky ve vsech souborech] - Je to zcela zbytečná práce, která se dá věnovat něčemu jinému, co bude pro uživatele skutečný přínos. - Celé je to jenom byrokratická buzerace a to si ani nejsem jistý, jestli na to má Debian vůbec nějaké pravidlo a není to jenom svévole té které skupiny "baličů".. - Především pak ale ve skutečnosti nikdo netuší, jestli je toto "ten problém" [ k odchodu uzivatelu od Debianu protoze nechce pridat tvuj balicek] někdo by se mohl zamyslet, jestli pro něj není lepší nějaká jiná distribuce, než taková, která na své uživatele zcela bezdůvodně kašle
A teď si ještě přečti, co si napsal v tom svém "shrnutí". Protože to je jenom snůška nesmyslů, kde jsi tyto mé výroky účelově nacpal do tvrzení/kontextů, které já jsem nikdy netvrdil.
To shrnutí nebylo nadnesené, to bylo prostě snůška polopravd a lží. Pokuď napíšeš, že pohrdám něčím, co má minoritní tržní zastoupení, je to jako když Andrej napíše, že "Generál nevěří v mír". S minoritními projekty, které mají běžné technické požadavky problém nemám, jak jsem už ukazoval na příkladu OpenBSD. Problém mám s Debianem, který se snaží diktovat zcela nesmyslné a nereálné požadavky na změnu coding style projektu a přitom má zcela minoritní tržní zastoupení.
Stejně tak pokud napíšeš, že nabádám uživatele k odchodu od Debianu, protože nepřijme můj* balíček. Protože to opravdu není o mém balíčku - připomínám, že se tady bavíme pod zprávičkou o jiném balíčku, kde to začlenění trvá také pět let... Debianí RFP je plné takových "smutných příběhů", kde SW, který běžně v jiných distribucích je, tam "hnije" roky. A to je ten důvod, proč by se někdo mohl zamyslet, jestli to jinde není lepší. Protože jak já to, i díky GPXSee, sleduji, tak to mnohde jinde podstatně lepší je.
* Nazývat balíček v Debianu jako "můj balíček" je samo o sobě také nesmysl, nikdy to nebyl "můj balíček" ani má snaha jej vytvářet/spravovat. Ten požadavek ode mě byl pouze přesměrování požadavků uživatelů GPXSee, kteří mi psali, proč není GPXSee v Debianu(Ubuntu). Tenkrát jsem si naivně myslel, že než opakovaně odpovídat na ten samý dotaz, že to musí řešit s Debianem, bude jednodušší, když sám vznik toho balíčku iniciuji. Jak moc jsem se mýlil...
a nereálné požadavkyLžete. Vzhledem k tomu, že ostatní projekty problém nemají, jsou ty požadavky zjevně reálné. V tomto případě by se dokonce dalo říct, že triviální.
SW, který běžně v jiných distribucích jeJiné distribuce třeba nevydávají stabilní verze s příslibem, že se ten software v té verzi bude několik let udržovat s ohledem na opravy bezpečnostních chyb. Pokud nikdo nechce nést odpovědnost za to, že se tak bude dít - a chce jenom někam vrhnout kód a nechat zbytek práce na jiných - vskutku není žádným překvapením, že takový balík není přijat.
Lžete
Ne, nelžu Bourku. Opravdu je zcela nereálné, aby nějaký distributor SW (se zcela zanedbatelným tržním podílem jako Debian) diktoval projektu GPXSee takové požadavky. Jak sis mohl všimnout, takové požadavky vždy byly a budou v projektu ignorovány.
Jiné distribuce třeba nevydávají stabilní verze s příslibem, že se ten software v té verzi bude několik let udržovat s ohledem na opravy bezpečnostních chyb. Pokud nikdo nechce nést odpovědnost za to, že se tak bude dít - a chce jenom někam vrhnout kód a nechat zbytek práce na jiných - vskutku není žádným překvapením, že takový balík není přijat.
S tím bych neměl problém, pak ale ať to lidé z Debianu otevřeně napíší, že na rozdíl od jiných distribucí nejsou schopní ten balík spravovat ani to nechat dělat jiné (nebavíme se teď o mně ale o lidech, co se ten balík do Debianu pokoušeli dostat po roce 2017). A nevymlouvají se na hromadu nějakých nesmyslných požadavků, které žádná jiná distribuce nemá a s fungováním toho SW nemají nic společného.
nejsou schopní ten balík spravovat ani to nechat dělat jinéOni narozdíl od vás asi nechtějí lhát, protože jsou schopní to nechat dělat jiné. Pokud ovšem nesedí Tůma na prameni a nebrání v tom.
Nelze, než ti znovu zopakovat, aby sis zjistil fakta, než se tady pustíš do urážení druhých. Já rozhodně Debianu v ničem nebráním, GPXSee je pod GPL3, takže si v něm mohou dělat změny dle libosti. Dokonce i takové, jako když před lety "vylepšili" OpenSSL...
Nemůžu, než se opakovat aby sis zjistil fakta, než se tady pustíš do urážení druhých. Debianí změnu v OpenSSL nikdo z vývojářů OpenSSL neodsouhlasil (že mu napsali, že když chce SW s OpenSSL debugovat, tak ať si to lokálně zakomentuje fakt není odsouhlasení změny). Tobě ale očividně nejde o nic jiného, než o ty urážky druhých. Sám si nic nedokázal, a tak je plivání na ty co na rozdíl od tebe ano, to poslední co ti zbylo.
Myslím, že čas, kdy tato "diskuze" byla zábavná jsme již vyčerpali a je na čase to ukončit. Tak zase příště.
Asi nejlepší popis toho Debianího fiaska je zde: https://research.swtch.com/openssl.
Záměrně, pro další možné zvýšení entropie, se četly i data v bufferu, kam se před tím nikdy nezapisovalo. Technicky to UB je, ale žádná z podporovaných platforem se nedefinovaně nechová. Buď jsou v tom bufferu "náhodná", nebo známá (překladačem inicializovaná) data. Čili ano i ne - pro akademické debaty to je UB, pro reálný svět je to možné zvýšení entropie.