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.
Ak máte záujem, môžete sa zúčastniť všeobecného prieskumu linuxovej distribúcie openSUSE. Pre výhercov v tombole je pripravených 20 tričiek, 5 krabíc openSUSE 11.2 a jedna super vecička, ktorá zatiaľ nebola určená. S najväčšou pravdepodobnosťou to bude Chumby. Pre vstup do tomboly zadajte svoju e-mailovú adresu na konci prieskumu. E-mailová adresa bude použitá iba pre účely tomboly. Prieskum trvá do konca februára 2010 a výsledky budú zverejnené na openSUSE.org.
Tiskni
Sdílej:
BTW už alespoň přestal při update mazat balík běžícího jádra a poté vyžadovat reboot jako MS Windows?Jde to nastavit v
/etc/zypp/zypp.conf
## ## Packages which are parallel installable with ## diffent versions ## multiversion = kernel-desktop,kernel-desktop-base,kernel-desktop-extraBTW: reboot po instalaci jádra doporučuje prakticky každá distribuce, pokud se nepletu. Je totiž nahouby mít nainstalované nové jádro se super bezpečnostní opravou, když pořád běžíme na tom původním, děravém.
Reseni zavislosti ma taky fest vymakane. Nejvic se mu blizi Aptitude (ok, uznavam, nevim jak jsou na tom jine rpm distribuce a do problemu zavislosti v Archu jsem nezabrednul natolik, abych testnul jeho sat-solver), ktere ovsem IIRC nema Qt gui.Solver v Archu skoro ani neni
Rozhodně to není takový kanón jako v Debianu nebo SuSE. Ale to nevadí. Víš proč? Není tam bordel v repozitářích a tak ho není potřeba.
Např. nikdy nepochopím věci jako je přidávat číslo knihovny do názvu balíčku.
Taky se mi to moc nelíbí, ale je to asi nejrozumnější způsob, jak umožnit koexistenci více (major) verzí téže knihovny.
Důvod, že by to znamenalo překompilovat s novou verzí spoustu programů neberu
U některých progamů (a hlavně knihoven) může být to "překompilovat s novou verzí" dost komplikované. Chcete-li extrémní příklad, napadá mne třeba Qt. Navíc jsou tu closed source aplikace, které ani překompilovat nejde - i když ty jsou většinou buď linkované staticky nebo si potřebné verze problematických knihoven nesou s sebou.
Důvod, že by to znamenalo překompilovat s novou verzí spoustu programů neberu, protože vývojáři Archu tohle zvládnou i přes to, že je jich méně a nejsou placení.Však tuhle drobnost za nás dělá BuildService
Cílem shared library policy je umožnit běh programů, které závisí na různých verzí téže knihovny. A bez nutnosti přidávat adhoc balíčky foo-compat, nebo foo-old. Navíc tohle SUSE převzalo z Debianu, kde to má drobet jiný důvod, ale vlastnosti jsou nakonec stejné.
2) Mam pocit ze jsi asi od osuse kdysi utekl a netusis co se s nim deje dal. oSuSE-11 ma zcela prepracovany backend ktery je mnohonasobne rychlejsi nez ten puvodni. Oproti YUMu z RH/Fedory je to rychlovlak vedle couraku. Zavislosti a kolize jsou reseny da se rici uzasne (z user-friendly hlediska). Ihned vyleti dialog s navrhem reseni. V kombinaci s dobre rizenymi ificialnimi a polooficialnimi repos urcite 99% uzivatelu oSuSE-11 nema zadne problemy. Rekl bych, ze tvoje problemy budou zjevne mezi klavesnici a zidli.
Puvodne jsem pouzival Fedoru a po YUMu to je uzas.
V praci jsem nucen pouzivat i debian a cele aptitude se muze jit zahrabat. To ze je "nejlepsi" je jiz jen dalsi mytus, to mozna platilo ve srovnani s yast/zypper v oSuSE-10. Nemluve o vybornem search v yastu a One-click feaure..
Proste .. prestan omilat jiz neplatne myty a nekdy si to zase zkus .. a jeste si uvedom, ze "jinak" nemusi vzdy znamenat "spatne".
Priste zkus napsat neco konkretniho CO je spatne .. treba se zasmejeme, protoze to pouzivas spatne ...
Nemluvě o tom, že mu 80% funkcionality zypperu zcela chybí.
Co se týče downgradu tak u Debianích tools se mi nelíbí, že byly navrženy tak nějak jednocestně. Nevím jak Aptitude, ale Apt zcela jistě při řešení závislostí uvažuje pouze zvýšení verze. Snížení verze není řešením, ani když je to z logického hlediska jediné možné řešení. To je docela problém, protože si vymyslím spoustu modelových situací, kdy se dostanu do složité spirály závislostí s nutnými downgrady, a zrovna v této nejnevhodnější chvíli selže nástroj, který by to měl vyřešit? To považuji za principiálně špatné.
Z vlastní zkušenosti můžu říct, že ani při větším množství repozitářů se mi nikdy nepovedlo dostat Zypper do situace, kdy nedokázal splnit závislosti, pokud existovalo řešení. U Aptu a Aptitude se mi to v Ubuntu párkárt stalo (po testování řady novějších verzí z repoziářů Launchpadu a následných downgradech zpět) a to Ubuntu používám jen zřídka. Na vině je právě neschopnost či nechuť solveru uvažovat všechny možnosti. Vypadá to pak poněkud trapně, když jsem jako uživatel schopen vyřešit tyto závislosti "vlastnoručně" (protože přibližně vím co jsem změnil), ale věhlasná toolsa přitom okamžitě kapituluje.
Na syntaxi aptu považuji za nejhorší, že to vlastně není jedna konzistentní toolsa, ale soubor apt-get, apt-cache, apt-... atd (já nevím čeho ještě).To je IMHO dusledek unixove filozofie. Jeden nastroj na jednu vec. Jeden spravuje balicky, dalsi vyhledava ....
To evidentně vymyslel nějaký geek bez jakéhokoli smyslu pro efektivitu používání. Proč tam proboha není jen "apt install", "apt search"... a podobně?S timto souhlasim a sjednoceni bych se nebranil. Ovsem, cele je to imho dano tim, ze jednotlive nastroje vznikaly nejspis postupne.
Nejen že dvouslovný název utility s pomlčkou je na psaní docela opruz, ale kdo si má sakra pamatovat který apt-??? instaluje, který hledá, který maže atd. Je to naproto zbytečné matení uživatele.Nemam problem si to zapamatovat. Zas takova hruza to neni. Kdo si to nepamatuje, pouzije Synaptic nebo proste zkopiruje prikaz z navodu.
Co se týče update vs. upgrade vs. refresh, správný význam neurčil nikdo. A určitě neplatí, že by bylo jediné správné řešení (TM). Pouze mi přijde logické, že pro "refresh repository metadata" je použit "refresh", a pro "update balíku" je použit "update" atd.Tak jinak. Kdo urcil, ze se jedna o "Refresh" metadat a ne jejich aktualizaci a zmena verze baliku je "Update"? Ja naopak vidim jasny rozpor ve tve argumentaci. Povyseni baliku nazyvas "Update" a snizeni "Downgrade". Neni to trochu blabol? Z tohoto duvodu bych videl jako matouci spis nazvoslovi v zypperu.
Problém ovšem je, když přijde nějaké pako jako LACO, které je zvyklé že apt-get update dělá refresh metadat, apt-get upgrade dělá update balíků, a začně tyto příkazy aplikovat na zypper, u kterého mají úplně jiný význam. Jak jsem řekl, to není problém aptu ani zypperu, ale idiota uživatele, který si ani nepřečetl manuál.S tim souhlasim.
To je IMHO dusledek unixove filozofie. Jeden nastroj na jednu vec. Jeden spravuje balicky, dalsi vyhledavaJo. Tohle by mohlo mít nějakou logiku, přiznám se, že mě to nenapadlo. Vypadá to ale stejně minimálně podivně. To by taky mohl být jeden nástroj na instalaci, jiný na odinstalaci atd....
Nemam problem si to zapamatovat. Zas takova hruza to neni. Kdo si to nepamatuje, pouzije Synaptic nebo proste zkopiruje prikaz z navodu.Já taky ne. Ale přiznám se, že jsem měl vždycky plíživé nutkání celou syntaxi si předefinovat pomocí aliasů na něco, co se snadněji ťuká do klávesnice. Přece jenom "apt in" se píše lépe než apt-get install.
Tak jinak. Kdo urcil, ze se jedna o "Refresh" metadat a ne jejich aktualizaci a zmena verze baliku je "Update"? Ja naopak vidim jasny rozpor ve tve argumentaci. Povyseni baliku nazyvas "Update" a snizeni "Downgrade". Neni to trochu blabol? Z tohoto duvodu bych videl jako matouci spis nazvoslovi v zypperu.Jak říkám, je to věc pohledu. Zatím co refresh balíku lze udělat asi těžko, update je poněkud univerzálnější slovo a možná je škoda vyplýtvat ho na něco, co lze vyjádřit i jiným stejně vhodným slovem. Nejdůležitější je podívat se a porovnat funkcionalitu, kterou zypper a apt/aptitude nabízí. Zypper a package management v suse je totiž mnohem bohatší na funkce a vlastnosti než ten Debianí. Například: Můžeš instalovat jen bezpečnostní patche s update repozitáře pomocí zypper patch. Můžeš ovšem updatovat balíky na vyšší verze od stejného dodavatele zypper update. Můžeš taky upgradovat balíky na vyšší verze bez ohledu na dodavatele zypper dist-upgrade Oproti Debianu je rozdíl v tom, že repozitáře jsou tematicky a verzovaně strukturované. Takže když máš SW z určitého repozitáře, tak ho updatuješ (neboli upgraduješ v minoritních verzích) - proto asi update. Když chceš udělat větši změnu (upgraduješ balík na vyšší majoritní verzi) měníš u toho většinou repozitář (například KDE 4.3 na KDE 4.4), proto příkaz upgrade. Debian funkčně nerozlišuje mezi "patch", "update", nebo "upgrade" a místo toho má jen "upgrade". Takže nevidím v tom příliš velký rozpor, protože přístup u obou distribucí je rozdílný a rozdílná syntaxe tomuto odpovídá.
Tohle je IMHO docela nesmysl. Je to, jak bys to same chtel treba i po rpm.To je IMHO dusledek unixove filozofie. Jeden nastroj na jednu vec. Jeden spravuje balicky, dalsi vyhledavaJo. Tohle by mohlo mít nějakou logiku, přiznám se, že mě to nenapadlo. Vypadá to ale stejně minimálně podivně. To by taky mohl být jeden nástroj na instalaci, jiný na odinstalaci atd....
Tak jinak. Kdo urcil, ze se jedna o "Refresh" metadat a ne jejich aktualizaci a zmena verze baliku je "Update"? Ja naopak vidim jasny rozpor ve tve argumentaci. Povyseni baliku nazyvas "Update" a snizeni "Downgrade". Neni to trochu blabol? Z tohoto duvodu bych videl jako matouci spis nazvoslovi v zypperu.
Oproti Debianu je rozdíl v tom, že repozitáře jsou tematicky a verzovaně strukturované.Tohle mne osobne nikdy nepalilo. Ja v Debianu pouzival tematicke rozdeleni jenom proto, abych mel balicky prehledneji roztridene.
Takže když máš SW z určitého repozitáře, tak ho updatuješ (neboli upgraduješ v minoritních verzích) - proto asi update. Když chceš udělat větši změnu (upgraduješ balík na vyšší majoritní verzi) měníš u toho většinou repozitář (například KDE 4.3 na KDE 4.4), proto příkaz upgrade. Debian funkčně nerozlišuje mezi "patch", "update", nebo "upgrade" a místo toho má jen "upgrade".Ovsem se taky muzes pekne spalit protoze treba ocekavas jinou verzi nez jakou mas nainstalovanou.
Takže nevidím v tom příliš velký rozpor, protože přístup u obou distribucí je rozdílný a rozdílná syntaxe tomuto odpovídá.Nerozumime si. Ja mluvim o rozporu update x donwngrade. Oboji dela v podstate tu stejnou zmenu, jenom jinym smerem, ale oboji nazyvas uplne jinak. Cili, upgrade x downgrade je jednoznacne smysluplnejsi. Jestli provadis skok mezi verzemi, nebo jenom tahas opravy lze rozlisit i jinak nez zavadenim nove terminologie.
Nerozumime si. Ja mluvim o rozporu update x donwngrade.Já jsem to pochopil. Ale tenhle rozpor tam nevidím. Pokud jsem dobře informován, tak platí, že ani apt, ani aptitude, ani zypper nemají příkaz "downgrade". Jestliže "downgrade" neexistuje, je úplně jedno jestli se jeho opak jmenuje "update", nebo "upgrade". Pokud se přesuneme čistě do jazykové roviny, pak opensuse má "update" (meší změny) a "upgrade" (větší změny). Proti tomu pak stojí teoretický výraz "downgrade": update/upgrade x downgrade
<<
tak jsem opravdu netusil, jak velkou pravdu mam ..
Asi se zacnu zivit predvidanim budoucnosti :-P
musim ale spomenut, ze niektore repozitoare su fakt pomale...ale to nie je problem systemu
a ak mate poriadok v repozitoaroch, co zjavne niektori vyssie uvedeni nemaju, tak s tym nie je problem...
navyse automaticke refreshovanie repozitoarov sa da vypnut :)
???PS: Spominal som ze Windows je lepsi, ze???>>>ano windows je lepsi, lebo vsetky aplikacie musim stahovat z milion roznych stranok.....v com je podla teba windows lepsi???
K Ubuntu: dobry system, aj ked som mal mensie problemy v 9.10 so zvukom a trackpointom, no nic co by sa nedalo vygooglit....samozrejme aplikacie ako ftp a dhcp server trebalo nastavovat rucne v konfigurakoch, kde v suse je to vsetko v yaste > cize je to ulahcene pre uzivatelov, a navyse firewall v suse je lepsi...
Inac myslel som ze nove ubuntu bude o nieco rychlejsie ako suse, ale nie je to celkom tak. Start ubuntu (gnome) trval na mojom nb cca 65 sekund a suse (kde) mi startuje za 45 sekund....
Názory jsou od toho, aby se různily. Já třeba považuji odstranění SaX2 za velkou chybu a s tím související nemožnost nastavení X serveru v AutoYaSTu za obrovský průšvih.
Mimochodem, co je to "acat"? Tohle slovo se mi přes veškerou snahu nepodařilo dešifrovat.
Mimochodem, co je to "acat"?Tipl bych si, že je to začat
To znamena u oSuSE:
1) pri instalaci zvolit EN klavesnici (i pri ceske instalaci) a v konzoli bude en (cz tam stejne nikdo nepotrebuje)
2) timpadem bude v X11 take EN klavesnice. V Yastu na to nesmatej a bude vsechno OK
3) kazdy uzivatel si nastavi klavenici/klavesnice podle sebe v "Nastaveni desktopu".
a NIKDO Z USERU NEMA ZADNY PROBLEM
Napriklad ja mam EN+CZqwerty, zena ma CZqwertz+EN .. kazdy jinym zpusobem prepinani jak komu vyhovuje
Fungovalo to stejne jak pod KDE3 tak pod KDE4.
Chapu ze vychozi nastaveni instalace neni pro BFU prilis stastna, pri instalaci v cestine se jim to nacpe do vsech 3 urovni.
PS: ja mam naopak presvedceni, ze Gnome a KDE se nemaji vubec co drbat do nastavovani SYSTEMOVYCH veci. At si nastavuji user space desktop a u toho zustanou. Takze napriklad: systemove udelatko at nastavi parametry graficke karty a displeje (driver a maxima) a user at si na tom jen nastavuje rozlisovacky a multidisplej .. :-P
Xserver - aplikuje se na xserver pro vsechny bez ohledu co je nad tim .. (to neni dobre reseni pro desktop
Ono je to hodně o zvyku. Já to tak používám, nevadí mi to ani trochu a naopak mám problémy ve Windows, kde se to nastavuje každé aplikaci zvlášť.