O víkendu probíhá konference OpenAlt 2025 (Stream). Na programu je spousta zajímavých přednášek. Pokud jste v Brně, stavte se. Vstup zdarma.
Josef Průša představil novou velkoformátovou uzavřenou CoreXY 3D tiskárnu Prusa CORE One L a nový open source standard chytrých cívek OpenPrintTag i s novou přepracovanou špulkou.
Na GOG.com běží Autumn Sale. Při té příležitosti je zdarma hororová počítačová hra STASIS (ProtonDB: Platinum).
Ubuntu 25.10 má nově balíčky sestavené také pro úroveň mikroarchitektury x86-64-v3 (amd64v3).
Byla vydána verze 1.91.0 programovacího jazyka Rust (Wikipedie). Podrobnosti v poznámkách k vydání. Vyzkoušet Rust lze například na stránce Rust by Example.
Ministerstvo průmyslu a obchodu vyhlásilo druhou veřejnou soutěž v programu TWIST, který podporuje výzkum, vývoj a využití umělé inteligence v podnikání. Firmy mohou získat až 30 milionů korun na jeden projekt zaměřený na nové produkty či inovaci podnikových procesů. Návrhy projektů lze podávat od 31. října do 17. prosince 2025. Celková alokace výzvy činí 800 milionů korun.
Google v srpnu oznámil, že na „certifikovaných“ zařízeních s Androidem omezí instalaci aplikací (včetně „sideloadingu“) tak, že bude vyžadovat, aby aplikace byly podepsány centrálně registrovanými vývojáři s ověřenou identitou. Iniciativa Keep Android Open se to snaží zvrátit. Podepsat lze otevřený dopis adresovaný Googlu nebo petici na Change.org.
Byla vydána nová verze 18 integrovaného vývojového prostředí (IDE) Qt Creator. S podporou Development Containers. Podrobný přehled novinek v changelogu.
Cursor (Wikipedie) od společnosti Anysphere byl vydán ve verzi 2.0. Jedná se o multiplatformní proprietární editor kódů s podporou AI (vibe coding).
Google Chrome 142 byl prohlášen za stabilní. Nejnovější stabilní verze 142.0.7444.59 přináší řadu novinek z hlediska uživatelů i vývojářů. Podrobný přehled v poznámkách k vydání. Opraveno bylo 20 bezpečnostních chyb. Za nejvážnější z nich bylo vyplaceno 50 000 dolarů. Vylepšeny byly také nástroje pro vývojáře.
Vývojář Kubuntu Jonathan Riddell oznámil, že Canonical končí s financováním Kubuntu. Kubuntu tak bude komunitní distribucí jako jiné deriváty Ubuntu, skončí i možnost placené podpory a Jonathan se nebude moct ve své pracovní době věnovat Kubuntu.
Tiskni
Sdílej:
Konecne nekdo dava najevo ze KDE je bastl neuveritelnyho ROZMERU, polofunknci, hnusny, neprehledny, neergonomicky, nestabilni betasmejd uz nekolik let. FUUUUUUUUUUUUUKde to v tom oznámení najdu? Ten důvod je úplně prozaický, stačí číst
This is a rational business decision, Kubuntu has not been a business success after 7 years of trying, and it is unrealistic to expect it to continue to have financial resources put into it.
"Mustafa, Mustafa! Ty jsi ale vul ..."Nebo tak nejak to priblizne bylo.
.
Otázka je: Jaký smysl má takový komentář, který kritizuje KDE, nejpokročilejší GUI na světě, ale nenabízí žádnou alternativu? Já si myslím, že konkurenceschopná alternativa není. Příznivci OS X nebo Windows si třeba myslí něco jiného, ale v rámci svobodných desktopů (a podle mého názoru i ve srovnání s těmi komerčními) nemá KDE konkurenci.
Je-li KDE opravdu tak strašně špatné, pak zkrátka musí být něco špatně s ovládáním všech počítačů obecně.
Ale bez jediné zmínky o něčem, co by KDE sahalo po kotníky, je samotná kritika KDE celkem bezúčelná a nepřináší žádnou zajímavou diskusi o tom, jak by tedy desktop měl vypadat.
Protože byla ve zprávičce řeč o Ubuntu, neodpustím si dodat, že Gnome je (odjakživa) po všech stránkách horší než KDE, je to ubohost, která ve verzi 2.x mohla konkurovat leda tak Windows 98 a ve verzi 3.x zatím nemůže konkurovat vůbec ničemu, ani svým předchozím verzím.
Moje oblíbená slovní úloha: Máme okno IM programu, který se má automaticky po přihlášení spustit. Nesmí se objevit v přepínači oken ani v přepínači ploch. Musí se objevit na všech plochách, na konkrétním monitoru (na tom „vedlejším“), vždy ve stejné poloze a vždy 100% neprůhledné, bez ohledu na nastavení ostatních oken. Druhý IM program se musí s tím prvním automaticky seskupovat do jednoho okna, je-li spuštěn. Jak tohle udělám v Gnome??? V KDE je to hračka. Gnome si ani neškrtne. Pak ať mi někdo vypráví o použitelnosti!
Snad Kubuntu pofrčí dál jako komunitní projekt, protože nové KDE 4.8.0 je opravdu super a byla by velká škoda přijít o distro, které se primárně zaměřuje na KDE desktop.Kvůli výpadku jednoho (ač fulltime) developera, se distro určitě nepoloží.
Muzete mi prosim zdelit *technicke* duvody tohoto rozhodnuti?
Redhat a Debian pouzivam od roku cca 1997, takze jsem to peklo asi musel zazit, jen si ho moc nevybavuji.selektivní paměť je krásná věc, udržuje člověka šťastnějšího, neb ho nesere to nepříjemné, na které zapomněl ale že jsem svině, tak ti to připomenu
rpm neumí samo o sobě řešit závislosti při instalaci, to ti jen vybleje seznam požadavků, který danej balíček chce, a je na uživateli, jak si je najde
což se řeší nějakou nadstavbou, jako třeba yum, anebo urpmi, když kolega mluvil o Mandrake, která má nějakou svoji databázi, kde se snaží najít, co ty požadavky splňuje, aby se to mohlo instalovat zároveň s oním balíčkem, co to požaduje
no a peklo je, když jsou v té databázi chyby (což byl myslím docela častý případ Mandrake, v dobách, kdy se jmenoval Mandrake), anebo ještě hůř když jí nemáš vůbec
přičemž typickou chybou v oněch databázích (respektive repozitářích jejichž obsah je těmi databázemi reprezentován) je nekonzistence verzí
poučeni z krizového vývoje distributoři svoje nástroje vyladili (takže funguje téměř spolehlivě zjištění shody mezi požadavkem a tím, co ho naplňuje) a zavedli pravidla, která mají inkonsistencím předcházet, přesto se dodnes nějaký problém občas vyskytne
no a v dobách dávných, které si už nepamatuješ, těch problémů bylo hafo, uživatelé stahovali někde po školách apod. balíčky, na což čekali hodiny, nosili si je domů na disketách, takže často museli dělat "retransfer", a když takový balíček přinesli, tak on jim při pokusu o instalaci vypsal tunu závislostí, takže do školy utíkali nanovo postahovat závislosti, pro které si odpovídající balíčky hledali ručně na službách typu rpmfind, a při pokusu ty závislosti doma nainstalovat jim to vypsalo další závislosti závislostí, a tak dále, a když už jim po dvou týdnech snažení zbývalo stáhnout poslední balíček, tak zjistili, že nesedí verze, protože někdo něco mezitím aktualizoval, a celý kolotoč shánění balíčků můžou začít nanovo (tentokrát zkrácený alespoň o to, že nemuseli hledat nýbrž věděli jména potřebných balíčků, a to všech najednou)
je možné, že pokud jsi již v těch dobách seděl se svým počítačem někde na tlustokabelu, tak jsi ten problém nevnímal tak intenzivně
Sorry, ale placate nesouvisejici veci dohromady. Jedna vec je balickovaci technologie jako RPM ci DEB a druha je zprava softwarovych repositories.jsou to sice dvě věci (což myslím vcelku jasně plyne i z mého příspěvku), ale ty že nesouvisí? - ohó, to je něco jako kocovina bez chlastačky?
Ani DEB a ani RPM nebyly navrzene pro nic vice nez instalaci, upgrade a smazani balicku, plus rychly test zavislosti a pro dalsi veci se proto pouzivaji nadstavby jako yum ci apt. Zde neni mezi nimi zadny zasadni rozdil.teoreticky, teoreticky ... prakticky, takový yum byl kupříkladu přijat až do RHEL5, tedy teprv před pěti lety, v dobách dávnějších tu byly zabugovanější a věčně nechodící nástroje, zatímco třebas takový dselect se mi vždy jevil poměrně spolehlivý, i před těmi deseti a více lety
Pokud nekdo zprasi repositare, vytvori tam vnitrni konflikty a nekompatibility, ani RPM a ani DEB mu nepomuze.totéž, co výše - situaci zpraseného Debianu stable si nevybavuju (což není příliš směrodatné, jednak moje paměť, a jednak jsem se s Debianem potkával jen na cizích strojích, ale i tak to jistou nenulovou vypovídací hodnotu má); připomínám, že tehdá ještě nebylo Ubuntu, o kterém jsem již něco na téma "deb hell" slyšel takže je hezké, když si tu teoreticky řeknem, že to není vina formátu, ale pokud se reálné problémy týkaly především dister na určitý formát vázaných, resp. přímo práce s oním formátem ... těžko se zlobit na uživatele, že označuje za "rpm hell" situaci, kdy má problémy při pokusu spustit příkaz
rpm -i balíček.rpm
Vetsinou reaguji na posuky, kteri vykrikuji, ze RPM nikdy, jedine DEB, ale nejsou mi schopni *technicky* zduvodnit proc. V nejlepsim pripade argumentuji situaci pred dvanacti trinacti lety, coz je zrale pro vysetreni Chocholouskem.jasně; potom ovšem nevím, na jaké vyšetření je zralé tvrzení ve smyslu, že RPM hell neexistovalo ("nikdy jsi neměl problém", "si moc nevybavuješ") :-p že jsme na tom dneska o mnoho lépe přeci není důvod snažit se historii přepisovat do růžova - naopak, chyby bychom neměli přehlížet, ať se z nich můžem poučit co se týče oněch pošuků, pokud nechceš jen bohapustě flejmovat, myslímže lepší šance někoho přesvědčit, že by měl svůj názor přehodnotit, bude, když popravdě přiznáš, že problémy byly, a že se od té doby řešily, než když mu budeš do očí lhát, že si nějaké rpm hell jen vymýšlí
No wonder Bill Gates is a billionaire; are you autistic or just a cunt?
totéž, co výše - situaci zpraseného Debianu stable si nevybavujuDebian mel lepe spravovane repositare, souvisi to s tim jak byl organizovan od sameho pocatku.
teoreticky, teoreticky ...Znovu - najdete mi zasadni technicke rozdily mezi DEB a RPM; dokumentaci co nelze - zdrojovy kod - mate. Tvrdim, ze je to jedno, zasadni rozdily tam nejsou a oba systemy jsou rovnocene - pokud je nejaky problem, tak bych ho nehledal tam.
Jonathan has always been the only Kubuntu developer who was paid by Canonical. The rest of the Kubuntu development team are community people.