Snap csomagként érkezhet a CUPS a következő Ubuntu-ban

Ubuntu

Az OpenPrinting projekt blogján számol be róla Till Kamppeter a projekt vezetője, hogy továbbra is dolgoznak rajta, hogy a következő Ubuntu kiadásban már snap csomagként érkezzen a CUPS.

A témához tartozó érdekesség, hogy az új CUPS architektúrában már nem lesz PPD alapú nyomtatókonfigurálás, ahol csak lehet, IPP-t fog használni a nyomtatórendszer, dinamikus nyomtatási sorokkal. A PostScript és Raster nyomtatók kezelését két külön alkalmazás fogja ellátni a CUPS-tól jóval függetlenebbül. (Bővebben a témáról ebben a prezentációban lehet olvasni.)
 

( carlcolt | 2023. 06. 01., cs – 08:28 )

Szerkesztve: 2023. 06. 01., cs – 08:29

Hianyzott, mint sargalaz a lepratelepre.

A snap/snapd annyira szar, hogy hianyossagaira/hibaira epitve mar ket alternativaja is elterjedt, es maris harom szarbol kell valasztani. Olyan feladatra, amire korabban az apt boven eleg volt egyedul is.

Na, majd csak vigyázz, jön az immutable Snapuntu, amiben minden szoftver Snap lesz, nem csak néhány. Az is igaz, hogy ez még nem a fő csapásirány lesz, csak egy spéci, opcionális lemezkép, de ki tudja, hogy mikor lépnek rá erre az útra teljesen. Azért szoktam írni, hogy ezeket a corporate hülyeségeket hagyni kell, és független közösségi disztrókat feltenni, azokat sose nyomják tele ezzel a sok szeméttel.

Egyébként én ezeknek az univerzális csomagformátumoknak nem vagyok ellene, ha valaki okosan használja, amire valók. Pl. nálam van fent 1-2 Appimage, ezek nem telepítősek, portable futtatható fájlok, és pl. nagyon ritkán használt programokat nyitok meg velük, pl. LibreOffice, ez évente kell max. egyszer, nem akarom, hogy sok függősége fent legyen a rendszeren, és Arch alatt naponta frissüljenek ezek. Vagy pl. ha valakinek a disztrójában nincs meg valami csomag a tárolóban, és nem tudja vagy nem akarja órákig forráskódból fordítgatni. Vagy pl. Electron/web alapú szutykokra (chatkliensek, streamszolgáltatók appjai, jegyzetelős alkalmazások, IDE-k) se tarkón lövés, mert azok már eleve úgyis sandboxolt bloatok, így mindegy, hogy natív vagy konténerizált, univerzális csomagként van-e fent. Esetleg ki akar csak gyorsan próbálni egy új szoftvert, amit még sose használt, vagy valami live rendszerre kell neki portable megoldás. Tehát ésszel lenne értelme az Appimage-nek, Flatpakk-nek (a Snap-nak nincs sok), de ez, ahogy túltolják őket, ha kell, ha nem, minden natív csomag ki legyen vele váltva, az agyrém.

“The world runs on Excel spreadsheets.” (Dylan Beattie)

A Red Hat sem különb. Most olvastam a redditen, hogy megszűnik a natív .rpm csomag LibreOffice-ból, és csak flatpak lesz helyette. Nem csak az RHEL-t érinti, de az összes ráépülőt, Fedora, CentOS, Alma, Rocky, stb..

“The world runs on Excel spreadsheets.” (Dylan Beattie)

( Tron | 2023. 06. 01., cs – 09:07 )

Miért kellene valamit jól hagyni, ha szarrá is lehet rakni?

( hory v | 2023. 06. 01., cs – 10:30 )

Szerkesztve: 2023. 06. 01., cs – 10:31

mar a 22.04 -ben is snap volt a cups, nalam legalabbis:

$ snap list cups
Name  Version  Rev  Tracking       Publisher      Notes
cups  2.4.2-5  872  latest/stable  openprinting✓  -

De fut egy cups sima processzkent is, azt gyanitom, hogy az egyik csak egy proxy, de nem tudtam kigyokolni, hogy melyik.

( rpsoft v | 2023. 06. 01., cs – 10:59 )

Tud valaki linkelni valami értelmes leírást arról, hogy ez a snap cucc miért jó/rossz nekem?

Azt értem, hogy minden app minden szarral, ami kell neki összecsomagolható, és akkor a saját homokozójában futtatható. Az előbbi arra rossz, hogy ne kelljen a disztribútornak a csomagokat összehangolni, egy library verzióval fordítani, hanem feltelepíthet mind minden szart. A diszk meg a memória úgyis ingyen van. Persze lehet rendesen is csinálni, de úgy csinálják? A másik meg arra jó, hogy stabilabb legyen, de végülis eddig sem volt instabil. Jól értem?

Tud valaki linkelni valami értelmes leírást arról, hogy ez a snap cucc miért jó/rossz nekem?

Ha jol latom (wikipedia), ebbe konnyebb elrejteni azt hogy pl a geped bitkoint banyasszon valaki masnak. De gondolom csak a szokasos faszongas ez is, amikoris megjavitjak ami mukodik mert az egyszerubb mint azt megjavitani ami nem mukodik. Csak bizzunk benne hogy a bubuntus buborekbol nem terjed ki mint ahogy anno a potterix.

Nekem speciel a poetterix-szel nem volt semmi bajom, mire bekerült az LTS-be, addigra túl volt a beta-tesztelésen. De a csomagkezeléssel eddig semmi gondom nem volt, amióta van apt, illetve mandrake-en urpmi, azóta az nekem megfelelt. Még csomagokat is szoktam csinálni, ha valamit forrásból rakok fel, hogy le is tudjam szedni. De a wikis cikkből nekem annyi jött le, hogy van benne a "sandbox" buzzword, de azt nem magyarázta el, hogy az itt mit jelent.

Szerintem a snap egy nagyon jó eszköz lenne olyan third-party szoftvereknek, amik nagyon rétegigényt elégítenek ki, mert egyszerűbbé teszi a szoftver release folyamatot,hogy nem kell a széttördelt Linux ökoszisztémában 500 féle disztribhez csomagot gyártani. Saját jó példa erre az általam használt oszcilloszkóp szoftvere.

Ehhez képest mire használják??? a Pl böngészőre, amit 10-ből 9 user használ napi szinten... (facepalm)

Pontosan en is ezt gondolnam, ez nagy monstre (proprietary?) szoftverekhez volna valo, amiknek fontos, hogy sajat lib keszletet szallitsanak.

Ehhez kepest pont olyan dolgokra kezdtek el hasznalni, ahol a shared library kezeles nagyon kozponti funkciot toltott be. Pl Gimp-nel a 3rd party pluginek tamogatasa. Vagy Cups-nal a millio-fele gyarto-specifikus nyomtatodriver amik kulon csomagban erhetoek el (gutenprint es tarsai). Na ezeket faszan sikerult eltorni...

Az, hogy a bongeszoinditas b***tt lassu lett, az hogy a mount tele van fosva (most meg csak) 40 entry-vel, csak hab a tortan.

Régóta vágyok én, az androidok mezonkincsére már!

Saját tapasztalatok:

Homokozóról, ahogy én látom, szó sincs. Azt csinál minden app, amit akar.

Az a koncepció, hogy minden app minden libből a saját külön verzióját használja, hazavágja a lényeget, a processzek közti megosztást: fölöslegesen zabálja a diszkhelyet és a memóriát is, fölöslegesen növeli a startup időt, de cserébe milyen jó, hogy a disztribúciónak pont azt nem kell megcsinálnia, amit amúgy egy disztribúciónak az alap feladata volna megcsinálni. Aztán majd ha találnak egy súlyos hibát egy libben, akkor biztos új verziót kapok minden azt használó snap-ből, biztos.

Az Ubuntu elkezdte snap-ként szállítani a firefox-ot. A mentés funkciója használhatatlanná vált. A GTK ablakban elkezdtél gépelni egy fájlnevet, minden billentyűleütés után elvesztette a fókuszt. Vagy valami ilyesmi. Vártam pár hetet, nem jött javítás. Visszaátálltam nem-snap-re, a Mozilla csapat hivatalos csomagjára, az jó. Hogy van-e köze a hibának a snap-hez per se, nem tudom.

Volt egy szkriptem, felhúzott lxd/lxc konténert, mókolt benne pár percig, utána lezúzta. Mindez loopban sok százszor, egész éjjelen át. Néha elhasalt. Debuggoljunk. A snap random pillanatokban úgy döntött, hogy frissíti magát az lxd vagy lxc (nem tudom melyik volt) szoftvert, kilőve a futó konténereket. Ez eddig még lehet hogy apt-vel is ugyanaz lenne. Apt-ben csomag szinten tudom letiltani, hogy ne frissítsen. Snap-ben csak megnövelni lehet a frissítési időközt maximum 1 vagy 2 hónapra talán, teljesen letiltani nem. És azt is csak globálisan, tehát akkor a firefox-om se frissül soha. Véglegesen úgy tudtam letiltani a frissítést, hogy a snap szervert /etc/hosts-ban behazudtam 127.0.0.1-nek.

Beszéltem debian/ubuntu szakértővel, hogy hol-hogyan is lenne érdemes ezt a koncepcionális problémát felhozni nekik hogy javítsák. Azt tanácsolta, felejtsem el. Fentről ki van adva, hogy tolni kell a technológiát, hogy használható-e vagy szar az már senkit nem érdekel. Megfogadtam a tanácsát, feladtam.

Hát, amit itt írsz, az pont az, ahogy én értettem, csak még tetézve azzal, hogy szar is.

Most van kubuntu-m, a Mint chromiumjával és a Mozillateam firefox PPA-jával. De sajnálatos módon lehet, hogy keresnem kell majd egy másik distrót. Ha meg mind snap-es lesz, akkor arra gondolok, hogy még mindig jobb, mint a windows vagy a mac-nek a hátrakötött kézzel unixozunk feelingje.

Manjaro (Arch -ot nem mertem felrakni)
Minden általam használt app-hoz van csomag. A csomagkezelést kicsit szokni kellett az Ubuntu/Debian után. KDE-vel wayland alatt használom 2 monitorral, eddig 0 problémám volt vele. Nem értem miért csak most(kb 3 hónapja) váltottam.

Amit olvastam, az alapján az egyik az, hogy nagyon könnyűvé teszi azt, hogy minden program magával hoz a shared library-kből egy verziót, ami éppen kényelmes volt a csomag készítőjének, aztán pedig minden program használja a sajátját. A másik pedig, hogy egy meglevő, jól ismert, sokak által használt funkciót (apt) duplikál úgy, hogy nem mutat jelentős előnyt. Az, hogy a browserben szarul működik a mentés és a helyi file-ok megnyitása az gyerekbetegségnek tűnik.

Lehet, hogy rosszl kérdeztem.

Mi olyan jelentős hátrányt okoz neked, hogy nem akarod használni?

 

Azért kérdezem, mert én napi szinten használom és van is vele egy kazal problámám, csak épp egyik sem az, amit fent írtak. A fentiek nálam vagy nem jelennek meg v. minimális negatív hatással vannak az életemre.

Amik pedig vannak problámák, azok személyesen nekem okoznak gondot. Ezért kérdezem, hogy neked milyen blocker jellegű (major v. critical) gondod van vele?

Major/critical gondom nincs vele, csak nem szeretem, ha valami meg van oldva egész jól, és lecserélik valamire, ami visszalépés. Eddig is lehetett tákolni, ha volt valahonnan egy lefordított binárisom és összegyűjtöttem hozzá a libeket (pl. egy régebbi, closed source program), de a csomagkezelés és a disztribúció csomagjai használatának az komoly elvi előnye, hogy a programok úgy vannak lefordítva, hogy a közös részeken tényleg osztozzanak. Az apt (Ubuntun) és az urpmi (Mandrake-en) jól kezelte a függőségeket, ha forrásból kell telepíteni valamit, már ezért megéri nekem általában becsomagolni.

Szóval ez nem blocker gond, csak nem szívesen térek át valamire, ami látszólag nem megold, hanem ront elvi problémákat.

En elmondom mik a fo problemaim.

Hasonloan a systemd-hez, ez is anti-Unix filozofia. Nincs igazabol egy vilagos konkret celkituzese, pontos problem statement, hogy mit is akar megoldani. Kicsit mindent is akar csinalni, es egyiket sem jol. Egyszerre akar lenni csomagkezelo, appstore, container, security sandbox, jogosultsagkezelo, service manager.

Borzasztoan eroforras-pazarlo (SBC-ken vagy kis VM-eken kulon elvezet). +mount pollution.

Szokszor funkciovesztessel jar (pl ahol kulon telepitheto plugin-kezeles volt).

Ez az immutable dolog elegge betesz power usereknek, ha egy fileba bele kell editalni, akkor az egesz squashfs image-et ujra kell buildelni. Igen, sajnos neha bele kell nyulnod dolgokba.

Altalaban minden ilyen "what happens in containers, stays in containers" rendszer jellemzoje, hogy remek kifogast ad a packager-eknek arra, hogy ne tartsanak rendet, ossze-vissza szetszorjak a file-jaikat, FHS-t leszarjak. Mehet a "/"-be, mehet a "/root" ala, "/home/zhengwuxiao"-bol futo service, miert is ne?! (ez utobbit dockerhub-rol leszedett image-ben lattam, a nevre nem pontosan emlekszem de valami hasonlo volt)

Nem oldja meg a fuggoseg-mentesseget, csak egy magasabb szintre helyezi at a depenency hell-t.

Nehezen introspect-alhato, kulon koroket kell futnod, hogy kideritsd, hogy konkretan milyen libek vannak telepitve belul (pl, hogy eldontsd egy security issue erint-e).

Megprobalja enandroidizalni a rendszert. Nem azert hasznalok Linuxot, mert Androidot vagy iOS-t akarok hasznalni.

Yet another jogosultsagkezeles, ami raadasul nem tul hatasos, cserebe teljesen rendszeridegen.

Yet another service manager.

Rengeteg konkret bugja es buta implementacios reszlete van, amit mar sokan masok kitargyaltak.

Régóta vágyok én, az androidok mezonkincsére már!

Egy részükkel egyetértek. Habár a legtöbb megemlített dolog nem snap specifikus.

 

Néhány megjegyzés:

 

A mountok enélkül is szaporodnak. Ez a néhány új valójában nemsokat számít.

 

A problem statement, célkitűzés stb. rémlik, h volt, amikor indult, most nem találom, csak ezt:

https://ubuntu.com/core/services/guide/snaps-intro

 

Az erőforrás pazarlás ritkán valódi probléma manapság IMO.

 

A csomagfile-ok szerkesztése eddig is gebaszos volt.

 

A függőség kezelés kisebb probléma lett IMO.

Amiket irtal (mount nem szaporodik "annyira", fuggosegkezeles nem "akkora" problema, eroforas pazarlas nem "akkora"), ezek azert igazak mert _jelenleg_ keves dolgot raktak snap-re. Amig defaultbol van 6-7 snap fenn a gepen, addig ez valoban nem "akkora" problema. Ha majd 100-200 lesz, a delta-upgrade layereikkel, meg kulonbozo "base", "core", "gtk" snap csomag verziokra fuggesekkel, akkor terjunk vissza erre a kerdesre...

A problem statement-tel kapcsolatban bizonyara nekem volt szakmai artalom, hogy architectkent a linken leirtaknal sokkal egyszerubb, kisebb feature-oket is nagysagrendekkel reszletesebben ki kellett fejteni. Ok, nyilvan nem vartam user-story szintu lebontast, vagy reszletes "MoSCoW" rendszeru besorolast, de azert egy high-level osszefoglalot igen, hogy mik a prioritasok. Hogy ez elsosorban alkalmazas csomagolas? Vagy elsosorban security sandbox? Vagy ilyesmi. Es a fejlesztest is ugy kene csinalni, hogy az elsonek megjelolt prioritas legyen eloszor "kesz", az mukodjon jol. Aztan utana kezdjenek hozza a nice to have dolgonak. Ugyanaz, mint a systemd volt. Az alap service management funkcionalitasnak most is van rengeteg 15+ eve broken resze (sd-notify a kedvenc peldam), de mar szamat sem tudod megmondani Pottering-ek hany tovabbi invaziv side-projectbe kaptak bele.

Régóta vágyok én, az androidok mezonkincsére már!

Igy. Először meg kellene határozni hogy mik a problémák amiket meg akarunk oldani, ezek miért problémák, mi és hol fáj. Ezután meghatározni a kontextust, a határt (boundary), majd a capability-ket, amiket szállítani akarunk. Ezután lehet kb. elkezdeni a hogyan-ról, trade-off analízis mellett.

Nem lehet, h fordítva ülsz a lovon és számon kérsz olyat, amiről fogalmad nincs, h hogyan mi a helyzet vele?

Honnan veszed, h nem volt problem statement és a többi dolog? Lehet, h volt, sőt valószínű, h igen, max te nem találod v. csak nem kötötték az orrodra.

 

Nem mondom, h nem válna a hasznára a transzparencia és a szervezettség a projektnek (és több másik ubuntu-s projektnek is), vmint a product managementnek is vannak gebaszai, azért az általad felvázolt szitu erős túlzás.

 

Tegyük fel, h lesz 1000 entry a /proc/mounts-ban. És akkor mivan? És mi van, ha azokat a felvetődő problémákat kezelik ment közben? Úgy érzem, h te vagy a nyuszika, az Ubuntunak meg van a fűnyírója. Azért és hőbörögsz, amit még el sem követett.

Megintcsak, jobb lenne, ha nem lennének egyedi mount-ok. Bár engem inkább amiatt zavar, amikor egyszercsak az mondja, h busy (kevésszer, de volt ilyen) snap remove során.

 

BTW a hagyományos csomagkezelőkkel hogyan oldod meg, h installálható legyen egy alkalmazásnak lényegében az összes verziója az összes támogatott disztrib verzióra (és ideálisan disztrib-re) úgy, h a minor verzión belül automatikusan frissüljön (a lehetőség legyen meg)?

Nos, bizonyara igazad van, es en ulok forditva a lovon.

Ettol fuggetlenul azert elgondolkodtato, hogy a nagy security sandboxinggal sikerult megoldani, hogy lokalis user root-ot szerezzen: https://www.zdnet.com/article/multiple-vulnerabilities-found-in-snap-confine-function-on-linux-systems/ Es itt nem egy hibarol van szo, hanem rogton 7-rol. Amugy a flatpak sem jobb: https://flatkill.org/ Nalam hozzaertobb emberek mindket rendszer jogosultsagkezelesi reteget egy netto security theater-nek tartjak.

"Tegyük fel, h lesz 1000 entry a /proc/mounts-ban. És akkor mivan?"

Aaa, vegulis, persze semmi nincs. Haladni kell a korral, el kell fogadni, hogy a rendszernek efelett a resze felett is elveszted a kontrollt. :) Amugy meg tudnek meselni, hogy milyen misztikus ezoterikus bajokat tud okozni tul sok mount entry. Volt szerencsem debuggolni ilyet, amikor egy ansible scriptben egy bind mount volt elleakelve (a mount parancs kimeneteben csak egy peldanyban latszott). Persze tudom, meg lehet oldani a kernelnek ezeket a skalazhatosagi problemait, ra lehet reszelni a kernelt erre a szelsoseges use-case-re is. Mint ahogy Lennart is azon porgott egy idoben, hogy dbus-t hangmintak kuldozgetesere akarta abuzalni (persze nem birta), ezert elkezdte nyomatni a kdbus-t, hogy kernelbe keruljon, mert ugy talan majd eleg gyors lesz...

Bár engem inkább amiatt zavar, amikor egyszercsak az mondja, h busy (kevésszer, de volt ilyen) snap remove során.

Na, ez pl egy konkret problema. Ilyet dockerrel szoptam be. Nagy orom, amikor automatizalni akarsz valamit (ertsd: lenyegesen gyorsabban jottek letre es szuntek meg a kontenerek, mint azt manualisan csinalnad) es randomly neha device or resource busy-t kapott a dockerd. Erre mit csinalt? Sajat listabol torolte a kontenert, a mountot, meg a layer filejait meg szepen otthagyta. Orom volt debuggolni release hatarido elott, mikor stability teszten kijott...

BTW a hagyományos csomagkezelőkkel hogyan oldod meg, h installálható legyen egy alkalmazásnak lényegében az összes verziója az összes támogatott disztrib verzióra (és ideálisan disztrib-re) úgy, h a minor verzión belül automatikusan frissüljön (a lehetőség legyen meg)?

Na, most terunk vissza arra amirol beszeltem. Hogyha kimondjak az elejen, hogy a snap (vagy flatpak) erre valo es nem masra, majd a fejlesztesnel arra koncentralnak, hogy ezt a funkciot jol ellassa, akkor talan valami jo megoldas is szulethetett volna. Meg egyebkent volt mar AppImage evekkel korabban, hogy megint miert kellett egy sajatot irni belole... Na peldaul ebben is lehetnenek transzparensek, hogy elmagyarazzak.

Régóta vágyok én, az androidok mezonkincsére már!

En felsoroltam egy nehany technikai jellegu problemat ezzel az egesz megoldassal kapcsolatban. Te pedig azon porogsz, hogy alaptalaul vadolom oket azzal, hogy nem volt vilagos fokusza a projektnek. Akkor tekintsd ugy, hogy ez utobbi resz a _velemenyem_. Ami semmit nem valtoztat azon, hogy technikailag sok szempontbol szar.

Régóta vágyok én, az androidok mezonkincsére már!

En ugy tekintem, h azt sem tudod, hova akarsz kopni.

 

Ocsaroltad a dockert, a systemd-t, a snap-et, a flatpak-et es meg azon is kiakadsz, h nem a te izlesednek megfeleloen szolgaljak fel neked a fasztudja mit.

Mindezt leginkabb egy bekezdesen belul. Gozom nincs, mit akarsz kihozni. Vmi frusztracio lehet a hatterben:)

 

t

Szerintem te nagyon nem tudod ertelmezni a szovegemet, ellenben mindenaron szemelyeskedni akarsz.

Ugy latszik meg mindig nem jott at, hogy nem "ocsarolok", hanem konkret problemakrol beszelek, amik nem feltetlen csak a snap alatt jottek elo, de a snap sajnos ugy lett megtervezve, hogy ezeket a problemakat erosen provokalja. Igy jott a kepbe a docker, annyi szerepe van a tortenetben, hogy onnan tudom, hogy az adott megoldas (mount-ok korlatlan szaporitasa, mount-ok konkurens letrehozasa es torlese) problemas.

A systemd meg sajnos ott jott kepbe, hogy tulsagosan is jo hasonlat arra, amit a snap-nel is csinaltak: az alapfunkcionalitasban otthagynak elvarratlan problemakat, befejezetlen alap feature-oket. Kozben meg rohannak elore mindenfele mas (az alapfunkcionalitashoz erintolegesen sem tartozo, de legalabb invaziv) feature beletuszkolasaval. Ha mindenkeppen erdelel, hogy mi nem felel meg az izlesemnek, akkor ez az.

A flatpak csak azert kerult emlitesre, mert akkor azzal jonnel, hogy "dehat nemcsak a snap-nek vannak security problemai". Es miert jonnek ide a security problemak?! Mert pont abbol adodnak, hogy olyasmit akartak felvallalni (sandboxing, sajat jogosultsagkezelesi rendszer kiepitese), ami megintcsak nem tartozott hozza az alapfunkcionalitashoz (alkalmazascsomagolas), majd - ahogy a linkeken elolvashattad - eleg masszivan el is rontottak. Tenylegesen tobb kart csinaltak vele (pl. local root), mintha semmit nem csinaltak volna.

Régóta vágyok én, az androidok mezonkincsére már!

> Szerintem te nagyon nem tudod ertelmezni a szovegemet, ellenben mindenaron szemelyeskedni akarsz.

Érdekelne, hogy miből vetted ezt le.

 

> nem "ocsarolok", hanem konkret problemakrol beszelek,

OK, akkor problámázol rajtuk. Résztben konkrét problámákról írsz, részben nem. Amennyire én látom, szubjektív problámákat fogalmaztál meg (FHS, Nehezen introspect-alhato, Megprobalja enandroidizalni a rendszert, Yet another service manager és még biztosan van).

Emellett vagy írsz konkrétumokról is v. legalábbis utalsz vki(k)re, akik írnak.

Számomra továbbra sem világos, h milyen, h alapvetően neked mi a fájásod: mi a konkrét jelenség, ami nem működik?

 

Írok én amúgy:

- Leszedek egy csomagot (core akármi v. gnome akármi) és megáll működni egy másik csomag (hibás dependency kezelés?).

- LXD ZFS backenddel egy idő után busy mountpointokra panaszkodott, mert nem stop után nem tudott umountolni vmit és ott volt vmi gebasz. A problémát a snap refresh triggerelte. Egyrészt probléma maga a bug is, az viszont méginkább, hogy nem is lehetett gyakorlatilag debuggolni, évekig maradt így. Aztán újabb core-ra váltás megoldotta.

- Az apt körül kialakult szofisztikált megoldásoknak nincs (stabil) alternatívája (apt-listchanges, puppet support, proxy support, korábban csomagok fixálása)

- Nincs éles határvonal a hivatalos csomagok és az akárki által összerakott csomagok között)

- AFAIK nem nagyon lehet belenyúlni, pl. ha én egy másik csomaggal akarok helyettesíteni egy csomagot, akkor nemsok esélyem van, hiszen hova rakjam?

- Amíg az extra RAM fogyasztás (klasszik szerver és desktop környezetben) elenyésző IMO, az extea helyfogyasztásra ez kevésbé igaz, legalábbis gyakrabban okoz problémát a tapasztalataim szerint, mivel a rendszerpartíció kisebb szokott lenni, különösen VM-ek esetén.

- Azért a RAM usage overhead is tud valóban probléma lenni, bár ha jól láttam, az IOT eszközöket senki nem említette itt, pedig elvileg az egyik célterülete elvileg pont az és amiatt hozták létre. Lehet, csak én gondolok félre vmit az IOT-ről, mivel ott valóban korlátozott mennyisésgű resource szokott rendelkezésre állni gyakran.

 

Ezek szerintem konkrét problémák és részük valóban húsbavágó, amivel a canonical a saját usereit szopatja.

Mondjuk az itt felsorolt problémák jelentős részével nem volt szerencsém találkozni (air gapped install és társai), de örülök, hogy meg van oldva. :)

"It was designed for IoT," - ez végülis megmagyaráz bizonyos tervezési mintákat, de azért IoT-nél azt gondolná az ember, hogy mindenekelőtt erőforrás-takarékosnak kellene lenni. Elnézve, hogy pl openwrt-nél milyen módszerek vannak, hogy beleférjen az image az eszközön levő pártíz MB flashbe... valahogy nehezen tudom belelátni, hogy beágyazott rendszereken a snap jól tudna működni. Hacsak nem olyan IoT-ben gondolkodtak, mint az Android-os telefonok, ahol 6-12GB ram és 128GB flash az alap.

"From a technical standpoint, it definitely sucks the most at desktop stuff" - akkor nemcsak én érzem így, hogy teljesen idegen az egész megközelítés

"relies on a central store, curated and managed by Canonical" - amikor arról beszéltem, hogy szerintem nem volt világos célkitűzése a projektnek volt bennem egy konteó, hogy valójában "Az Appstore" volt "A Célkítűzés" és minden más use-case ennek lett alárendelve. Sajnos érzek némi megerősítést ebben...

Régóta vágyok én, az androidok mezonkincsére már!

Jól összefoglaltad. Nekem még így se lenne bajom, hogy léteznek ilyen megoldások, mint a Snap, Flatpak, Appimage, ahogy fentebb írtam a téma elején, okosan, mértékkel használva nyújthatnak előnyt bizonyos extrémebb, megszorult helyzetekben. A gond az velük, hogy a nagy cégek (Canonicial, Red Hat)
1) tolják rá mindenkire, ha kell, ha nem, arra is, aki nem kéri
2) minden csomagnál erőltetik, olyannál, ahol lenne pedig rendesen a rendszerhez fordított, natív csomag, ami tudná a rendszer függőségeit használni, meg minden, és mégis be van erőltetve, hogy legyen minden Snap, Flatpak, stb..

Sokszor ez egyébként kényelem és lustaság kérdése. Rájöttek, ha rátolják valaki másra az univerzális csomag készítését, akkor nem kell nekik a disztró tárolójában saját csomagot fenntartani, tesztelni, alkalmazottat fizetni. Így meg megcsináltatják a munkát mással ingyen.

Az immutable rendszereknek is valóban meglenne az értelme, de nem desktopon, oda agyrém. Hanem beágyazott eszközökön, kiosk rendszerű felhasználásnál, egyéb speciális célfelhasználásnál. Csak most mivel ez a legújabb buzzword, ezért elkezdték desktopra is kihozni, hátha rákap a nép.

“The world runs on Excel spreadsheets.” (Dylan Beattie)

Ezekkel kb egyetertek. Ez egy kompromisszum. Arra volna szabad hasznalni, hogy proprietary szoftvereket lehessen futtatni diszto-agnosztikusan. Ott tenylegesen lehetove tesz valamit, ami amugy nem, vagy csak nagyon nagy szivasok aran menne. Hozzatesz valamit. Ahogy pl a Canonical csinalja, az inkabb elvesz.

Az immutable-os megjegyzeseddel is egyetertek. Ami Openwrt-n mukodik, az desktopra nagyon nem idealis. (Teszem hozza, ott is mindig van overlay, amivel runtime tudod felulirni a squashfs image-ben levo fileokat. De mivel ott van egy kozponti konfig management rendszer, ezert meglepoen ritkan kell file szinten belenyulnod.) Szerverre meg ha ilyesmi modellt akarsz, arra mar megvan a docker, meg CI/CD image build tamogatas, akar K8s ha nagyon komolyan akarod tolni...

Régóta vágyok én, az androidok mezonkincsére már!

Nálunk a céges Linux distribből van 22.04 LTS alapú is, ahol már snap-es a Firefox alapból.  Bizonyos virtual desktop környezetekben a home directory remote serverről jön, ott belefutottunk ebbe a bugba: Bug #1989156 “firefox won't start (Permission denied) if $PWD is...” : Bugs : snapd package : Ubuntu (launchpad.net) Vajon ha ekkora lendülettel bevezetik, hogy legyen minden snap, akkor miért nem tolnak effortot az ilyen banális hibák javításába?

Nem szeretném védeni a snapet, mert az implementáció khm, khm, finoman szólva az én tapasztalataim alapján is, pedig én csak véletlen szoktam belebotlani, szóval inkább csak ilyen tényszerűség jelleggel:

Homokozóról, ahogy én látom, szó sincs. Azt csinál minden app, amit akar.

Van benne egy egyébként koncepció szinten egész normális Interfaces nevű dolog, ami pontosan arra való, hogy ne csináljon semmit. Ez tulajdonképpen egy absztrakció aclek, cgroupok, apparmor meg seccomp felett. Nyilván nem egyedi dolog ez (főleg ma már) kb minden konténerizációs technika ilyenekre épít, és ad valami absztrakciót,  ami abban a kontextusban elfed ebből a komplexitásból, de alapvetően kellene legyen homokozó.

Az a koncepció, hogy minden app minden libből a saját külön verzióját használja, hazavágja a lényeget, a processzek közti megosztást: fölöslegesen zabálja a diszkhelyet és a memóriát is, fölöslegesen növeli a startup időt,

Ez valahol nyilván preferencia kérdése is, de nem hiszem, hogy minden annyira fekete-fehér,  volna, hogy az legyen a lényeg, hogy minél kevesebb diszk és memória legyen, ez egy meglehetősen mindenkinek maga felé hajlik a keze, ma a gyakorlatban szerintem ez elég ritkán fáj erősen. Nem a libek memórafoglalása lesz a mérvadó, és a néhány giga terület se lesz akkora katasztrófa...

de cserébe milyen jó, hogy a disztribúciónak pont azt nem kell megcsinálnia, amit amúgy egy disztribúciónak az alap feladata volna megcsinálni. Aztán majd ha találnak egy súlyos hibát egy libben, akkor biztos új verziót kapok minden azt használó snap-ből, biztos.

... mert azért azt is tudjuk, hogy vannak a hagyományos disztribúciós felállásnak is problémái. Elég nehéz ám mindenféle dependencyt mindenféle felállásban támogatni, meg a mindenkinek a mindenféle csomagformátumát megugrani, előállítás oldalon azért ez komoly fejfájás. User oldalon meg azért tud fájni, hogy nem nagyon van szabadságod pl bizonyos dolgok verzióival értelmesen előre szaladni, nem véletlen megy a hosszas rugózás a mindenféle melyik disztrót használjam vonalon mindig, meg kerülnek be ezt támogató megoldások a hagyományos csomagkezelőkbe is (lásd pl dnf modules). És persze az is igaz, hogy ezek az új confinement technikák megkövetelik, hogy egy csomó dolgot csináljon a fejlesztő, amit eddig a disztribútor csinált, és ez azért nem triviális, meg elsumákolható, rohadtul nem volt tiszta sokszor ("vitatkoztam" anno én is itt kollégával anno, hogy ezeket bizony ha én üzemeltetek elvárom), de összességében szerintem azért mostanra látszik, hogy ez is kezd kialakulni, a konténeres ökoszisztéma azért adja ezekre a kérdésekre a válaszait (nyilván a saját kompromisszumaival), meg azért vannak dolgok, amiket gyanús, hogy viszonylag könnyen lehet jobban lehet csinálni saját hatáskörben, mint a disztrók ált (random scriptnyelv libek és hasonlók pl) Snap mondjuk nem tudom, hogy áll, szóval ha tippelnem kéne, szarul :)

Szóval azt hiszem nem baj az, ha vannak lehetőségek, aztán meg kell nézni melyik usecaseben melyik a jó kompromisszum (ebben pl elég fos az ubuntu :) ), valami konténerizáció, valami hagyományos, esetleg valmi hibrid (pl rpm-ostree). Mi anno pl nézegettük, platformként nem tűnt rossznak a snap, voltak neki szimpatikus ígéretei.

snap random pillanatokban úgy döntött, hogy frissíti magát az lxd vagy lxc (nem tudom melyik volt) szoftvert, kilőve a futó konténereket.

Itt lehet, hogy aki csinálta volt gyökér (vagy hát, hozta magával az unattended-upgades minesetjét, ami kb ugyanazt jelenti :D), mert elvileg ezt is lehet basztatni a servicet tartalmazó snapnál, hogy legyen kedves és ne indítsa újra a futó szolgáltatást magától. (Az viszont vastagon az ejnye részben van, hogy ezt szerintem az admin nem tudja felülbírálni).

 Apt-ben csomag szinten tudom letiltani, hogy ne frissítsen. Snap-ben csak megnövelni lehet a frissítési időközt maximum 1 vagy 2 hónapra talán, teljesen letiltani nem. És azt is csak globálisan, tehát akkor a firefox-om se frissül soha. 

Csomagokat egyesével tudsz holdra tenni, akár forever is. Az, hogy az automata updatet teljesen kikapcsolni, az mondjuk elég blama megintcsak.

entről ki van adva, hogy tolni kell a technológiát, hogy használható-e vagy szar az már senkit nem érdekel. Megfogadtam a tanácsát, feladtam.

Igen, ubiék szeretik ezeket elbaszni.  

( XMI | 2023. 06. 01., cs – 11:55 )

Jeee! Alig vártam már, hogy végre snap-ben érkezzen a cups is! És mivel - helyesen - látják, hogy szeretjük a snap-et, ezért nem egy, hanem rögtön _két_ snap-et kapunk! Egy áráért! Az pedig, hogy a PPD-alapú konfigurálás megszűnik, külön öröm, különösen a régebbi nyomtatók tulajainak.

(Ja, nem...)

Régóta vágyok én, az androidok mezonkincsére már!

Hú, apám, nagyon meg tudjátok hozni az ember kedvét hozzá. Eddig is nagy rajongója voltam a cuccnak, most aztán alig győzöm visszafogni magam. De legalább trey szereti, berendezkedett rá, hogy 10 évig használ egy verziót, bár az is lehet azért, mert egy régiben nem kapja meg ezeket a csoda Snapokat. Az is igaz, hogy annyi jobb normális disztró létezik, ahol ezek nincsenek. Plusz az is igaz, hogy sok embernek a nyomtatás ma már elég marginális téma, nem vagy nem nagyon nyomtatnak, kb. mint a CD/DVD írás. Viszont akinek kell mégis, annak nagyon, gondolom örülnek ennek a nem PPD-alapú szívásnak.

“The world runs on Excel spreadsheets.” (Dylan Beattie)

sok embernek a nyomtatás ma már elég marginális téma

A nyomtatás az IT-nak az az ága, ami több (minimum 3) évtizede folyamatosan egy akut problémaforrás. Nagyon sok megoldást, technológiát kitaláltak, és szerintem már nagyon sokszor közel kerültünk a győzelemhez, de akkor mindig jöttek az újabb és újabb idióták a szarságaikkal, és a bevált/beválni látszó technológiákat (lásd. pl. LPD vagy PostScript) kibaszták, és lecserélték valami szemétkupacra. Említsünk meg a (Windows) szoftver printereket, a senki mással nem kompatibilis, NIH jegyében feltalált n-dik lapleírónyelvet, a végtelenféle tintasugaras szart, amit akkor is kurvadrága üzemeltetni, ha havonta 1000 oldalt akarsz nyomtatni vele, meg akkor is, ha csak egyet.

Ez így van, a nyomtatás mindig is egy neuralgikus pont volt, minden OS-en, nem csak Linuxon és Mac-en. Szerintem az új szabványokkal nincs baj, IPP, PDF, XPS, SVG, stb., csak nem elég elterjedt. Már régen is ott volt a PS, DVI, stb., csak azok sem lettek univerzálisak, a PS állt még hozzá legközelebb, hogy ténylegesen minden támogassa. Újra feltalálni valóban nem kéne a kereket, de még a főbb újra feltalált leírónyelvvel sem lenne gond, PCL, SPL, RPCS, stb., de akkor tegyék nyílttá, licencmentessé, és használja mindenki. Még mindig egy jól kitalált leírónyelv, mint valami hülye bináris, nem visszafejthető interface.

“The world runs on Excel spreadsheets.” (Dylan Beattie)

( DirtY_iCE | 2023. 06. 01., cs – 12:08 )

Rossz irany, szerintem egybol systemd-be kene integralni hogy a beepitett webszerverehez tartozo qr kodot ne csak a kepernyon tudja megjeleniteni, hanem egybol ki is nyomtatni.

Nem, sajnos akarhogy is nezem a datumot, nem apr 1 van hanem jun 1...

I hate myself, because I'm not open-source.

Ebből lesz a kötelező "áruház". Lassan fizetős is lesz, meg reklámos is.
Az első dolog amit letörlök (minden dist upgrade után is) a snap meg a d-je.

Btw. szépen fejlődik a Devuan. Se' systemd, se' snapd, csak boldogság ;)

http://plazmauniverzum.hu <> A látható anyag 99.999%-a plazma <>

( the_manni | 2023. 06. 01., cs – 20:48 )

ez még a világnál is betegebb, megelőzte a korát. saját disztrib futtat saját chrootban saját alkalmazást. azta

( lacesz v | 2023. 06. 01., cs – 21:08 )

Nem értem miért kell erőltetni a snap-et?! Felesleges... Inkább koncentrálnának olyan fejlesztésekre amivel nem csak a háttérképeket, de a gépház alatt is van érdeme...

( MysteryKe | 2023. 06. 02., p – 06:39 )

Nekem volt olyan program, amit nem emlékszem már, hogy APT-ből vagy dpkg-val telepítettem-e, de mindenféle sz*r függés miatt vagy nem települt vagy ha települt akkor nem működött. Aztán kattintottam kettőt az Ubuntu áruházban vagy mi a tökben, települt és elindult. Ugyanígy a PyCharm és az IntelliJ IDEA is. Tetszett, hogy ugyan robosztus szoftverek, de nem kell miattuk szétcs*szni a rendszert, csak kattintok kettőt, teszi a dolgát. Az APT meg folyton szívat a visszatartott csomagjaival, aztán sipákol, hogy vannak frissítendő csomagok, de aztán mégsem hajlandó megcsinálni. Csak ha külön kérem, hogy szedjen le egy rakás csomagot.
 

Úgy gondolom, (hogy nem ennek a közösségnek), de akiket át akarnak csábítani linuxra, azoknak ez a megoldás szimpatikusabb. Régen sokat szórakoztam SuSE 6.4 - 10 alatt is .rpm csomagokkal, de nagyon ritkán volt olyan, hogy ne próbálta volna megkeseríteni az életemet a függési háló.

Addig orulsz majd csak amig nem kell kezzel belenyulni az apparmor rule-okba. Desktopon meg nem is zavarna, de van csomag ami csak snap-ben van az ubuntu serveren es mindenfele extra security dependencia miatt nem nagyon lehet vele dolgozni. Amig nem csinal az ember magikus dolgokat. Az egesz snap egy jo nagy mess es kb az unstable allapotaban raktak be productionbe :D

Ezt mind a flatpak mind az appimage jobban csinalja.

( Raynes v | 2023. 06. 04., v – 20:46 )

Várjatok, most olvastam el újra figyelmesebben, és most látom, hogy nem a Canonical jóvoltából lesz belőle Snap, hanem már maguk a CUPS fejlesztői azok, akik szintén ezt a hülyeséget erőltetik. Szégyen.

“The world runs on Excel spreadsheets.” (Dylan Beattie)