Byla vydána beta verze Ubuntu 25.04 s kódovým názvem Plucky Puffin. Přehled novinek v poznámkách k vydání. Dle plánu by Ubuntu 25.04 mělo vyjít 17. dubna 2025.
Textový editor Neovim byl vydán ve verzi 0.11 (𝕏). Přehled novinek v příspěvku na blogu a poznámkách k vydání.
Živé ISO obrazy Debianu Bookworm jsou 100 % reprodukovatelné.
Boudhayan "bbhtt" Bhattcharya v článku Uzavření kapitoly o OpenH264 vysvětluje, proč bylo OpenH264 odstraněno z Freedesktop SDK.
Představeny byly nové verze AI modelů: DeepSeek V3-0324, Google Gemini 2.5 a OpenAI 4o Image Generation.
XZ Utils (Wikipedie) byly vydány ve verzi 5.8.0. Jedná se o první větší vydání od backdooru v XZ v loňském roce.
Byla vydána nová verze 0.40.0 multimediálního přehrávače mpv (Wikipedie) vycházejícího z přehrávačů MPlayer a mplayer2. Přehled novinek, změn a oprav na GitHubu. Požadován je FFmpeg 6.1 nebo novější a také libplacebo 6.338.2 nebo novější.
Byla vydána nová verze 2.20 svobodného video editoru Flowblade (GitHub, Wikipedie). Přehled novinek v poznámkách k vydání. Videoukázky funkcí Flowblade na Vimeu. Instalovat lze také z Flathubu.
LibrePCB, tj. svobodný multiplatformní softwarový nástroj pro návrh desek plošných spojů (PCB), byl vydán ve verzi 1.3.0. Přehled novinek v příspěvku na blogu a v aktualizované dokumentaci. Vypíchnut je interaktivní HTML BOM (Bill of Materials) a počáteční podpora Rustu. Zdrojové kódy LibrePCB jsou k dispozici na GitHubu pod licencí GPLv3.
Minulý měsíc Hector "marcan" Martin skončil jako upstream vývojář linuxového jádra i jako vedoucí projektu Asahi Linux. Vývoj Asahi Linuxu, tj. Linuxu pro Apple Silicon, ale pokračuje dál. Byl publikován březnový přehled dění a novinek z vývoje. Vývojáře lze podpořit na Open Collective.
24.7.2009 12:52
Tomáš Bžatek | skóre: 29
| Brno
19.7.2009 01:01
Limoto | skóre: 32
| blog: Limotův blog
HPLIP není proprietární
Použijte čistou variantu. Pokud použijete multilib, bude Vás to srát, dále Vás to bude srát a po tom všem Vás to ještě nasere.
A pročpak to? Používám to tak skoro pět let a pořád mne to netento…
AbcLinuxu.cz
ITBiz.cz
HDmag.cz
AbcPráce.cz
/usr/lib, ale dnes už je to skoro všude opraveno; a i tam, kde ne, jde většinou o triviální patch.
…a to nemluvím o tom, co se děje s PREFIX/bin, či problémy s /usr/include, případně dalšími konflikty (konfigurace, data programů).
Zajímavé je, že já takové zkušenosti nemám. Tak mne poučte: co se děje s PREFIX/bin? Jaké problémy jsou s /usr/include? Jaké konflikty jsou ohledně konfigurace a dat programů?
Možná každý mluvíme o něčem jiném. Já jsem mluvil o 64-bitovém systému, kde jsou pouze některé 32-bitové programy (a to ty, které z nějakých důvodů nejsou k dispozici jako 64-bitové) a kvůli nim navíc 32-bitové knihovny (oddělené od 64-bitových). Takže netuším, proč mluvíte o mixování dvou systémů do jednoho.
$ sdl-config --libs -L/usr/lib -Wl,-rpath,/usr/lib -lSDL -lpthreadPokud při pohledu na
/usr/lib začnete přemýšlet jak se to řeší v multilibu tak odpověď je hrůza zvaná multiarch-wrapper která nějak pozná pro jakou architekturu budeme kompilovat a pak spustí příslušný knihovna-config-{32,64} které má někde bokem.
To všechno za předpokladu že se Vám podaří takový systém sestavit. Kompilace a instalace multilib programů je narozdíl od normálního C-M-I tria poměrně detailní a namahavá ruční práce, posuďte sám při pohledu do CLFS. Všimněte si, že jako první se kompiluje 32 bit, aby se následnou instalací 64 bitu "vyřešily" případné konflikty přepsáním...
Takže abych to shrnul - multilib verzus chroot:
Mimochodem, jak tedy standardnimu (autoconf) configure skriptu vysvetlit, ze chci kompilovat pro 'sekundarni' architekturu na multiarch systemu? Pri crosscompilaci jednoduse staci pouzit --host option, ale pro tenhle pripad to nefunguje.
23.7.2009 01:54
setarch nebo linux32? S nimi to jde?
-m32, ve složitějších pomáhá linux32.
21.7.2009 11:28
tsLnox | skóre: 31
| blog: Blog jednoho ukecaného Gentoolemana
| Žďár nad Sázavou
21.7.2009 09:31
pushkin | skóre: 43
| blog: FluxBlog
21.7.2009 20:12
pushkin | skóre: 43
| blog: FluxBlog
Adobe Flash je 64 bit, včera jsem ho ve svém Gentoo instaloval a zadal jsem instalaci jen 64bit, tj. USE="-32bit" .
21.7.2009 20:13
pushkin | skóre: 43
| blog: FluxBlog
).
22.7.2009 21:23
Jardík | skóre: 40
| blog: jarda_bloguje
23.7.2009 02:02
Jardík | skóre: 40
| blog: jarda_bloguje
no dovolim si rict ze je to presne naopak, V linuxu (BSD..) je to delano daleko lip. Ve Windows je nejaka hloupa redirekce u 32-bit programu (napriklad TC nevidi c:\windows\system32\drivers\etc\hosts --starsi verze v nejnovejsi verzi je volba na vypnuti one redirekce). Navic v windows/system32 ve x64 verzi windows neni 32-bitova cast systemu ale 64-bit , 32-bit jcast systemuje je nekde ve wow64_32mode nebo tak nejak.
Kde jsou widle je i hnuj.
kazdopadne souhlasim ze to neni uplne idealni ale urcite lepsi nez ten mrglajz ve Windows.
Nechte si ty urážky, prosím.
To sice musím, ale je jich relativně málo. Navíc je rozdíl mezi xyz-32bit.x86_64.rpm a xyz.i586.rpm. Rozhodně je s tím méně práce než s instalací dvou samostatných kompletních systémů.
Nechte si ty urážky, prosím.To je spíš zoufalství nad tím, že si pořád melete tu svou aniž víte o čem mluvíte. A to je opět bez urážky, to je prostě fakt. Vážně: dělal jste někdy systém od základu -potažmo multilib- z vanilla balíků nebo ne? Neexistuje žádná jiná cesta jak získat patřičné zkušenosti, než si to vyzkoušet.
To sice musím, ale je jich relativně málo.Není! Ne v LFS pro multilib, tam musíte přeložit téměř vše 2x. Většina věcí co překládáte jsou podpůrné knihovny o kterých normální smrtelník ani neví, maximálně něco tuší. Pokud vynecháte tři z padesáti, tak to není "relativně málo".
Rozhodně je s tím méně práce než s instalací dvou samostatných kompletních systémů.Není, viz vše co jsem do teď řekl. Máte pro tento svůj názor nějaký argument? Já jsem jich snesl asi deset ... bavme se věcně.
Ne v LFS pro multilib, tam musíte přeložit téměř vše 2x.
Nemusíte. Pokud to tak děláte, je to jen váš problém. Podívejte se do nějaké normální distribuce, kolik je tam *-32bit balíčků a kolik je tam balíčků celkem.
dále už je poměr knihoven podstatně větší
To tvrdíte vy. Já mám momentálně nainstalováno 1664 balíčků a z toho 103 jsou *-32bit.
Znovu upozorňuju že se bavíme o LFS a ne Vaší oblibené distribuci nebo co nazýváte normálním. Nemá cenu v této diskusi pokračovat, pokud nezměníte svůj pohled z pozice uživatele distribuce na pozici tvůrce distribuce.
Znovu upozorňuji, že není absolutně žádný důvod, proč by při přibližně stejné instalaci měl podíl knihoven (a potažmo *-32bit balíčků) na tom, zda se jedná o LFS, OpenSuSE nebo jakoukoli jinou distribuci. Doporučuji přestat s tím povýšeneckým "tomu vy nemůžete rozumět" a zkusit používat věcné argumenty.
Je potřeba vzít v úvahu i fakt, že 32-bitové verze nepotřebujete od všech knihoven, ale jen od těch, které používá nějaký 32-bitový program, který nemůžete instalovat ve 64-bitové verzi (typicky proto, že neexistuje). Řada těchto programů si navíc přibaluje své vlastní verze těchto knihoven.
1664 balíčků a z toho 103 jsou *-32bitTak na tuto "statistiku" se můžeme podívat různými pohledy. Za prvé je rovnou vidět, že 103 případů se v absolutním rozměru nedá považovat za něco na čem nezáleží, jak jste se snažil naznačit. Za druhé abychom mohli Vaše čísla poměřit relativně tak si uvědomte, že distribuce dělí tarbally na několik balíčků. Typicky 1 ku 3 - blabla, libblabla a blabla-devel, což po úpravě dává opět asi 20% podíl. V realitě je ten poměr zřejmě o něco větší, např. moje /usr/src má jen kolem 400 položek a odhadl bych že knihovny jsou tak 50%.
Doporučuji přestat s tím povýšeneckým "tomu vy nemůžete rozumět" a zkusit používat věcné argumenty.Věcných argumentů bylo použito dost, poměrně přesně jsem Vám popsal jaké jsou s multilibem problémy. Vaše reakce byla, že máte jiné zkušenosti, přičemž je zřejmé že ale ne s výrobou LFS. To není povýšenecké, ale bavíme se každý o něčem jiném. To, že řešíte, jestli je těch problémů 50, 103, nebo 150, jen podtrhuje nesmyslnost debaty.
Řada těchto programů si navíc přibaluje své vlastní verze těchto knihoven.V tom případě nebude potřeba žádný multilib.
Vaše reakce byla, že máte jiné zkušenosti, přičemž je zřejmé že ale ne s výrobou LFS.
Pořád jste ještě nevysvětlil, v čem je ten zásadní rozdíl, jestli to buildujete pro LFS nebo pro klasickou distribuci.
Řada těchto programů si navíc přibaluje své vlastní verze těchto knihoven.V tom případě nebude potřeba žádný multilib.
To bohužel není pravda. Obvykle nejsou přibaleny všechny knihovny, ale jen ty, u kterých autoři počítají, že by s nimi mohly být problémy. Bývá to např. Gtk nebo libstdc++ (ve starších distribucích je ještě verze 5, v novějších už 6).
Pořád jste ještě nevysvětlil, v čem je ten zásadní rozdíl, jestli to buildujete pro LFS nebo pro klasickou distribuci.Vysvětlil ale zřejmě ne dost jasně. Takže rozdíl je např. v tom, že těch 103 nebo kolik problémů neřešíte, protože je někdo vyřešil před Vámi. Pokud náhodou rebuildujete něco z toho, tak na to máte automatickej nástroj, do kterého se zadá tarball a vylezou 3 nebo kolik rpmek (debů, ... bla). "Multilib" se pak řeší tak, že se tento nástroj tupě použije na 32 bit arch, a nainstaluje se jen ten -lib balík. Pokud náhodou překládáte něco o čem distribuce ještě neslyšela, ergo k čemu ten nástroj není, tak máte aspoň spoustu vodítek jak to udělat a multilibovou verzi potřebujete jednou za uherskej rok, přesně jak jste řekl, a to nějak přetrpíte.
Obvykle nejsou přibaleny všechny knihovny, ale jen ty, u kterých autoři počítají, že by s nimi mohly být problémy.Což je absolutně k ničemu, protože pak taková knihovna bude požadovat nějakou fixní verzi např. glibc, kterou ale už program nedodává. Pokud ve svém multilibu máte jinou tak se můžete jít klouzat. Další bod pro chroot.
Vysvětlil ale zřejmě ne dost jasně. Takže rozdíl je např. v tom, že těch 103 nebo kolik problémů neřešíte, protože je někdo vyřešil před Vámi. Pokud náhodou rebuildujete něco z toho, tak na to máte automatickej nástroj, do kterého se zadá tarball a vylezou 3 nebo kolik rpmek (debů, ... bla). "Multilib" se pak řeší tak, že se tento nástroj tupě použije na 32 bit arch, a nainstaluje se jen ten -lib balík. Pokud náhodou překládáte něco o čem distribuce ještě neslyšela, ergo k čemu ten nástroj není, tak máte aspoň spoustu vodítek jak to udělat a multilibovou verzi potřebujete jednou za uherskej rok, přesně jak jste řekl, a to nějak přetrpíte.
Jinak řečeno, dál trváte na své představě, že mluvím jen o 'zypper install xyz-32bit', nebo nanejvýš o 'rpm -i xyz.src.rpm ; rpmbuild SPECS/xyz.spec', a vůbec netuším, co obnáší napsat si vlastní specfile a vytvořit vlastní balíček. Nebo snad že napsat si vlastní specfile a vybuildit pomocí něj balíčky je z nějakého záhadného důvodu jednodušší než vybuildit odpovídající balíčky pro LFS. Není a už z principu nemůže být, protože se jedná o přesně stejnou činnost. Spíš to může být i o trochu těžší, protože občas je potřeba přiohnout trochu vzdorovitý build systém některých projektů, aby odpovídal filosofii rpmbuildu.
Což je absolutně k ničemu, protože pak taková knihovna bude požadovat nějakou fixní verzi např. glibc, kterou ale už program nedodává. Pokud ve svém multilibu máte jinou tak se můžete jít klouzat. Další bod pro chroot.
Pokud by tomu tak bylo, pak tou knihovnou, se kterou by mohly být problémy, bude i glibc a bude v zájmu producenta přibalit i ji. Oni totiž "překvapivě" i producenti closed source software mají zájem na tom, aby jejich software běhal na co nejvíce systémech.
dál trváte na své představě, že mluvím jen o 'zypper install xyz-32bit', nebo nanejvýš o 'rpm -i xyz.src.rpm ; rpmbuild SPECS/xyz.spec', a vůbec netuším, co obnáší napsat si vlastní specfile a vytvořit vlastní balíčekAž do této chvíle jste se o svoje zkušenosti nepodělil... a i tak je tento Váš argument jen v souladu s tím, co jsem napsal - nemyslím že byste psal specy pro těch 103 balíků které tam již máte a zbytek je spíš sváteční zejména s ohledem na multilib, přičemž máte k dispozici nejen vodítka jak to ohnout ale i celou multiarch mašinerii kterou již někdo postavil. Je to velmi odlišné od toho, že nemáte nic a začínáte na zelené louce. S jednou architekturou je to i jednodušší, než sestavovat balíky, s cross překladem je to oser a s multiarch je to oser na druhou.
Pokud by tomu tak bylo, pak tou knihovnou, se kterou by mohly být problémy, bude i glibc a bude v zájmu producenta přibalit i ji.Což nás zacykluje na začátek debaty kde jsou všechy knihovny přiloženy a není co řešit :)
nemyslím že byste psal specy pro těch 103 balíků které tam již máte
Jistě že ne, stejně jako jsem je nepsal pro těch zbylých 1561. Protože mi to nestojí za to a samostatně si dělám jen balíčky, které v distribuci nejsou nebo je potřebuji v jiné variantě. Stačí že vím, co to obnáší, nemusím si to za každou cenu zkoušet prakticky pro všechny.
Je to velmi odlišné od toho, že nemáte nic a začínáte na zelené louce.
To je. Ale ta odlišnost je především v tom, že si nemusím dělat všechno od nuly. To, jestli tam mám dvoje knihovny nebo jen jedny, už není tak podstatný rozdíl.
Což nás zacykluje na začátek debaty kde jsou všechy knihovny přiloženy a není co řešit :)
Řekl jsem snad, že jsou přibaleny všechny? Jasně jsem napsal, že jsou přibaleny ty, u kterých se očekávají problémy s kompatibilitou. Dokonce jsem výslovně napsal, že to nebývají všechny.
Ale ta odlišnost je především v tom, že si nemusím dělat všechno od nuly. To, jestli tam mám dvoje knihovny nebo jen jedny, už není tak podstatný rozdíl.Rozdíl je v tom, jestli všechno buildujete pro 2 architektury zvlášť - na což stačí často svaté trio C-M-I, nebo se s každou patláte ručně ve stylu multilib. Režie a mentální náročnost toho druhého přístupu je mnohonásobně vyšší než toho prvního.
Jasně jsem napsal, že jsou přibaleny ty, u kterých se očekávají problémy s kompatibilitou. Dokonce jsem výslovně napsal, že to nebývají všechny.To je hezké, ale teoreticky může problém způsobit jakákoliv knihovna. Buď tam dáte všechno a pak je to schopné samostatného života a nebo ne a můžete očekávat problémy. A neexistuje žádné jednoduché pravidlo stylu že čim víc toho přibalíte tím menší je pravděpodobnost problémů.
Rozdíl je v tom, jestli všechno buildujete pro 2 architektury zvlášť - na což stačí často svaté trio C-M-I, nebo se s každou patláte ručně ve stylu multilib. Režie a mentální náročnost toho druhého přístupu je mnohonásobně vyšší než toho prvního.
Což je vaše tvrzní, moje zkušenost je opačná. Můžeme to opakovat pořád dokola, stejně žádného z nás nepřesvědčí slova toho druhého, jsou-li v rozporu s jeho vlastními zkušenostmi. Podstatné je, že jsem ale pořád neslyšel žádný argument, proč by relativní náročnost hybridního řešení vůči dvěma samostatným architekturám měla být výrazně odlišná u něčeho jako LFS oproti klasické distribuci.
To je hezké, ale teoreticky může problém způsobit jakákoliv knihovna. Buď tam dáte všechno a pak je to schopné samostatného života a nebo ne a můžete očekávat problémy. A neexistuje žádné jednoduché pravidlo stylu že čim víc toho přibalíte tím menší je pravděpodobnost problémů.
To není můj problém, jen jsem popisoval svá pozorování ohledně těch několika closed source aplikací, kvůli kterým mám v systému 32-bitové knihovny.
Absolutní náročnost: kolik práce dá vyrobit daný balíček. Relativní náročnost A vůči B: jaký je poměr (absolutní) náročnosti A a B.
Konkrétně mi jde o tohle: označme S1 náročnost vytvoření samostatných balíčků nějaké knihovny v distribuci typu LFS, H1 náročnost vytvoření balíčků pro hybridní systém tamtéž. Potom označme S2 a H2 odpovídající náročnosti pro distribuci typu OpenSuSE (myslím opravdu vytvoření, ne jen sestavení z připraveného specfilu). Vy tvrdíte, že poměr H1/S1 je výrazně vyšší než H2/S2 a proto že jsou mé zkušenosti z OpenSuSE (a dalších klasických distribucí) nepřenositelné na LFS. Já tomu nevěřím a ptám se, proč by tomu tak mělo být.
Vy tvrdíte, že poměr H1/S1 je výrazně vyšší než H2/S2Ne, já tvrdím že H1-S1 je vyšší než H2-S2. Protože H>S a protože H1/H2 = S1/S2 ~ 100. Proč mínus a ne děleno, protože existuje jistá (absolutní) hranice, kterou když H a S přelezou tak se na to vykašlete, jelikož máte i jiné věci na práci.
23.7.2009 21:52
Jardík | skóre: 40
| blog: jarda_bloguje
)
Tiskni
Sdílej:
