A Snap csomagtelepítés univerzálissá vált. [Canonical szerint]

Ubuntu Linux

Úgy tűnik, hogy a Snap csomag formátum immár univerzális formátummá válik a linux disztribúcióknál.

A tegnapi nap több Linux disztribúció fejlesztője és cégek, mint a Dell, Samsung, a Linux Foundation, The Document Foundation, Krita, Mycroft, Horizon Computing, és mások, bejelentették a snap univerzális Linux csomagformátumon való együttműködésüket.

A snap csomagformátum már most natívan fut az Ubuntu variánsokon, Arch Linux-on, Debian-on, és Fedora-n, mostanra már validálták CentOS, Elementary, Gentoo, Mint, OpenSUSE, OpenWrt és RHEL disztribúciókon, valamint egyéb disztribúciókon is könnyen elérhetővé lehet tenni.

Részletek itt és itt.

Szerk.: a fenti hírt a Canonical tette közzé, úgy tűnik, hogy az említett disztribútorok tudomása és egyetértése nélkül.

  • 10983 megtekintés

( gelei v | 2016. 06. 15., sze – 11:22 )

Bámulatos, hol tart már a tudomány.

Egyébként minden szarkazmus és rosszhiszeműség nélkül, miért kellett az univerzális csomagkezeléssel 2016-ig várni?

Ha benne van az adott snap csomagban, akkor úgy, hogy a snap készítője kicseréli egy nem sechole-osra.
Ha nincs benne, akkor a disztribúció készítője kicseréli egy nem sechole-osra.

Szerk.: ha a snap csomag készítője nem cseréli ki egy nem sechole-osra, akkor is elvileg nagyobb a biztonság, mivel elvileg sandbox-olva futnak ezek a programok és nem férhetnek bármihez hozzá, csak amihez joguk van (bár, hogy ez pontosan hogyan is lenne megvalósítva, arra én is kíváncsi lennék)

"Öröm és bodottá, hogy lesz és van, hatalmas lökést fog adni a linuxon futó szoftverek terjesztésének."

Azt hiszem, amiből eddig volt, volt .deb (Ubuntu/Debian/Mint), .rpm (Fedora?) és .tar.gz (Slack?) variáns is.
Nem tudom, ez mennyire visz előbbre bármit, semennyire, talán?

--

@gelei: "miért kellett az univerzális csomagkezeléssel 2016-ig várni?"

Kismillió univerzális csomagkezelő van linuxra.

"Ilyen azért nincs kismillió, sőt egy sincs, ami támogatva is lenne a főbb disztribúciók által."

Amennyire tudom, mind a kismillió meg van tűrve..

A támogatottságától én nem esnék hanyatt:

"So I've got a brand new package manager installed on my system, but that doesn't do me much good without packages to install right? Executing "snap find *" returned a... less than impressive list. In total there were 7 snaps available from the store for install-- 2 of which were example applications provided by Ubuntu."

http://www.phoronix.com/scan.php?page=article&item=ubuntu-snaps-fedora&…

"Nem tudom, ez mennyire visz előbbre bármit, semennyire, talán?"

Ezek után ahelyett, hogy egy letöltés oldalon a linux szekcióban találnál tar.gz-t, többféle deb-et, külön Ubuntura, Debianra, azok több verziójára, külön rpm-eket redhatra, suse-re... na ehelyett lesz egy darab snap.

Plusz a snappy nem csak a csomagformátumról szól, hanem mindenféle biztonsági és kényelmi megoldásokról amik vele járnak. Pl hogy az appok el vannak különítve egymástól, a frissítések és a függőségek kezelése egyszerűbb.

na ehelyett lesz egy darab snap
Sajnos nem feltétlen ennyire egyszerű. A snap tartalmazza a függőségeket, amik deduplikálódhatnak, ha a snap csomagot pontosan ugyanazon a linux rendszeren készítették. Ellenkező esetben nem deduplikálódnak, és egy kis 1MB-s alkalmazás is több 100MB-ot fog foglalni a rendszeren.

Tehát ugyanazt a programot (snap-ot) elő lehet állítani többféle linux rendszert alapul véve. Ha csak 1 snap van, az egy rendszernek jó, a többiek szívnak. Akkor ha a sw előállítója nem akar részrehajló lenni, külön snap-okat kell kitennie minden eddig is támogatott rendszerhez, azaz kb ugyanott vagyunk.

"egy kis 1MB-s alkalmazás is több 100MB-ot fog foglalni a rendszeren"

Na és? Cserébe minden csomag szállíthatja magával azt a verziót amivel kompatibilis. Pl. ha láttál már node.js alkalmazást, ott minden csomagnak külön települnek a függőségei, és mivel a függőségek maguk is csomagok, egy gyakrabban használt csomagból akár több verzió is jelen lehet egyetlen node alkalmazásban. De ezt semmilyen dependency problémát nem okoz, minden kódrészlet azt a dependencyt látja, amit magának definiált.

Kérdés mennyire kell nyugtalannak lenni emiatt. A mobil platformok használói, a windows, osx userek nem aggódnak, hogy náluk nincs ilyen modell, hogy az egyes libek külön frissülnek, mégis mindegyik népszerűbb platform.

Ráadásul linuxon is egyre több third party csomagolja maga mellé a függőségeit. Lásd a steam játékokat, lásd a chrome-ot, amik ha lehet mindenből sajátot szállítanak. Lásd a skype-ot, amiből van static build, elkerülve a függőségbeli problémákat. Mennyivel másabb az?

Amit nem a disztribútor szállít, vagy nem magadnak fordítasz forrásból, abba ugyanúgy bele lehet statikusan építve mindenféle lib annak érdekében, hogy ne legyen gond abból, ha a rendszer amin futtatnád más verziót szállít. Akkor ez most mennyivel jobb?

"senki sem adott megnyugtató, értelmes választ"

If a library which comes with snap contains a security issue, only developer of the snap can fix it, is right? Are there any mechanism to detect not secure snap packages in Ubuntu side.

Right now yes, that is the case. Later down the 16.04 timeline we will introduce a way for a developer to delegate to other developers so a group of people will be able to freely release updates to a given snap.

On the ubuntu side, as long as authors are going to use snapcraft, we will be using a manifest to keep track of packages that were used for a given build of a given snap and we'll work on a system to notify snap developers that a CVE (or other security issue) may affect their snap. Ultimately we don't want to spam people with false positives so it will be a while before this system is operational.

Kérdés hogy a fentiek mennyire számítanak megnyugtatónak.

Forrás: http://www.omgubuntu.co.uk/2016/04/ubuntu-16-04-lts-snap-packages#comme…
Érdemes a többi kommentet is nézni

> Right now yes, that is the case. Later down the 16.04 timeline we will introduce a way for a developer to delegate to other developers so a group of people will be able to freely release updates to a given snap.

Aztán vagy megcsinálják, letesztelik, whatever, vagy nem.

> On the ubuntu side, as long as authors are going to use snapcraft, we will be using a manifest to keep track of packages that were used for a given build of a given snap and we'll work on a system to notify snap developers that a CVE (or other security issue) may affect their snap. Ultimately we don't want to spam people with false positives so it will be a while before this system is operational.

Magyarul az ubuntus csapat kezében van az egész, a többi disztribúció meg csak reménykedhet?

"Na és?"
Nem pazarlás egy kicsit? Értem, hogy olcsó az erőforrás, de nem lenne kötelező pazarolni.
- - - - - - - - - - -
"A fejlesztők és a Jóisten versenyben vannak. Az előbbiek egyre hülyebiztosabb szerkezeteket csinálnak, a Jóisten meg egyre hülyébb embereket. És hát a Jóisten áll nyerésre." By:nalaca001 valahol máshol

Például: egy Fedora vX-en összeállított csomagot telepíteni szeretnénk Ubuntu vY-ra, könnyen előfordulhat, hogy nem fog menni, mert a csomag adott könyvtárakban keresi majd a függőségeit, és az a hely ubuntun másnak van fenntartva (akár u.a. a lib, de nem kompatibilis verzió).

Ennek a megoldása, hogy a csomag egy virtuális fájlrendszert lát (sandbox), és csakis azokat a függőségeket, amiket megjelölt. Az ehhez szükséges technológiának a kernelben kell lennie. 2013-ban a 3.8-as kernel véglegesítette a Linux Namespaces-t ( https://en.wikipedia.org/wiki/Linux_namespaces , http://lwn.net/Articles/531114/ ).

A 3.8-as kernelben sokan meglátták az univerzális csomagkezelő alapjait (Docker, Snappy, AppImage, FlatPak, ...). A Sappy csapatnak 3 év kellett, hogy felfedezzék a lehetőséget, ezeket kipróbálják, aztán kitalálják hogyan működjön elméletben, megírják, tesztelgessék, újraírják,.... Ez sztem sok munka, és a véglegesítéshez a 3 év reális.

( BandiG v | 2016. 06. 15., sze – 13:12 )

Hirek a jovobol:

2019: Az ubuntu mau nyelvre migralja azt a maradek ket shell scriptet ami a rendszerben maradt a SystemD/OS utan.
2020: Latak, hogy ez jo, ugyhogy uj bongeszo es office csomag irasaba kezdenek, mau nyelven. Az ipar hummogessel es kerdo tekintetekkel fogadja a bejelentest, de senki nem szol semmit.
2021: Valahol europaban az orvosok ertetlenul allnak egy luftballon szeruen felfuvodott, majd kidurrant maj esete elott.

( batyu v | 2016. 06. 16., cs – 01:26 )

Majd meglátjuk, mire lesz ez jó. Volt már ilyesmi kísérlet, de mindeddig elhalt mind. Mondjuk nem is tűntek ennyire kidolgozottnak.
Ami nekem nem tetszik az ötletben, az a tárhelypazarlás, amit hozhat magával.
Szerk.: amúgy pl archra nincs hivatalosan. Az AUR nem az.

"To install snapd you need to have one of the AUR helpers installed." a snapcraft.io arch linkjére kattintva. A repókban meg nincs, megnéztem.
Egyébként pont arch-on meg elég erős is lenne lecserélni a csomagkezelőt. Hogy párhuzamosan használható lesz-e mellette, ez érdekes kérdés, AUR-ból sok csomag érhető el most is, ami rpm-ből, vagy deb-ből szedi a binárisokat, nem mindig átjárhatatlanok a falak a disztribek között.

"Ami nekem nem tetszik az ötletben, az a tárhelypazarlás, amit hozhat magával."

És ez senkit sem zavar egyik másik oprendszer alatt, pl osx, ahol hasonló elven egybe van csomagolva az alkalmazás a függőségeivel, ráadásul ha jól tudom régen mikor az intelre váltottak a régi és új platform binárisai is egy csomagban voltak. Windows alatt se sok vizet zavar, hogy minden app mellé be vannak csomagolva a függőségei (szinte).

Egy ideális világban jobb rendszer az, ami most van. a függőségek önálló csomagok, a disztribútor frissíti, minden csak egyszer foglal helyet. Cserébe csomó szívás van a verziók közti átjárhatósággal, elég csak megpróbálni felrakni egy modern programot egy régebbi ubuntu/debian verzióra, vagy fordítva.

Elvileg erre is lenne megoldás, amit terveztek is, de már nem találom, a framework rendszer, azaz pl. Qt, Java, ... adott verziójú library-kat külön framework-ökbe rakják (szintén snap csomag), és akkor ezeket nem kell mindenhová beágyazni.

"És ez senkit sem zavar egyik másik oprendszer alatt, pl osx"

Egy-két programnál ez még elmegy, de ahogy a Phoronix cikkben is látszik, az nem igazán jó, hogy egy óra alkalmazás vagy egy számológép 100MB-os nagyságrendű legyen, miközben hagyományos csomagolással 200kB körül van.

Ezt előbb-utóbb valószínűleg meg fogják oldani, mert az elsődleges platform az IoT és a mobil eszközök, ott pedig lényeges, hogy mennyi helyet foglal.

Arról, kedves manfreed, hogy míg a Snap mellé mellé kell csomagolni a fél Ubuntut, .msi mellé nem, én legalábbis nem sűrűn látok olyan windowsos alkalmazást, amelyik feltételezné hogy nincs windowsom. Lásd még hogyan lesz 1>MB programokból (lin, win, osx) >100MB, és a 100MB programokból >1GB méretű.

Ezt miből veszed, hogy a snap mellé kell csomagolni a fél ubuntut? Az eddig olvasottak alapján ilyenről nyilván nincs szó. Lesznek dolgok, amik statikusan lesznek linkelve, de ilyenek most is vannak, lásd pl a chrome.

Windows alatt mik vannak? Pl java alkalmazások, amik nem akarják a felhasználót azzal terhelni, hogy külön JRE-t telepítgessen, ezért csomagolják maguk melé. Pár megás program mellé a párszáz mega JRE. Mennyivel is jobb?

Windows alatt se sok vizet zavar, hogy minden app mellé be vannak csomagolva a függőségei (szinte).

Csak Windows alatt viszonylag kevés a Gtk-t vagy Qt-t használó alkalmazás, azaz nem sok alkalmazás mellé kell odarakni a Gtk-t ill. a Qt-t a teljes függőségi rendszerével (első gondolatom az, hogy a legnagyobb helyet a grafikus toolkit-ek foglalják).
Itt jön elő a sokegyszínűség előnye.

(Régen használtam Windows-t saját gépemen, így lehet, hogy valamit rosszul tudok/valamire rosszul emlékszem)

GTK, vagy QT tényleg nem. De láttam már wxwidget-re épülő windows alkalmazást, aminek a könyvtárában ott figyelt a wxwidgets dll-je. Láttam már médiakonvertáló alkalmazást, aminek a könyvtárában ott figyeltek az ffmpeg, vagy mencoder dll-jei. Láttam már java alkalmazást, aminek a könyvtárában egy egész JRE ott figyelt... stb.

Én sem gondolom, hogy sok wxwidget-et használó windows alkalamazás volna. Azt már fent megállapítottuk, hogy nem sok qt-t és gtk-t hasnáló windows alkalmazás van. Csak az a baj, hogy nem ebből a háromból áll a világ. Nem csak gui toolkitekből kell kiindulni.

Ott a nem hivatalos messenger for desktop alkalmazás. Egy webapp lényegében, ha jól sejtem egy node.js alkalamzás van belecsomagolva, talán párszáz kilobájtnyi cucc majd száz megás programba. Csak azért, mert a futtatókörnyezettel egybe van építve, hogy egy kényelmes exe legyen a végeredmény. Ilyen egyre több van. Ez sem sok.

Ott van még a ... na de nem folytatom a felsorolást. Önállóan semmi se sok, add őket össze :) De nem is ez a lényeg. Windows alatt letöltesz egy programot, hiába kétszer akkora, valószínűleg menni fog, és örülsz. Mi linux alatt örülünk annak, ha valami feleakkkora, cserébe a függőségekkel csak a szívás van, ha valami thirdparty csomagot telepítenél, ami nem kifejezetten adott disztribúció adott verziójához lett összerakva. Átlagfelhasználók számára ez nem annyira nyerő.

Azt akartam mondani, hogy linux esetében a használt toolkiteket mindenféleképpen hozzá kell(ene) csomagolni, míg Windows esetében nem feltétlen (a legtöbb az "alapot" használja). Így azért kicsit érthetőbb, hogy a windózerek miért nem rinyálnak, hogy nagyok a programjaik.
Persze, kivételek vannak, pl. akár az általad említett "messenger for desktop", de nem mindegy, hogy 20 telepített programból kettő ilyen monstrum a beépített függőségei miatt, vagy 20-ból 20.

De nem kell hozzácsomagolni. ha megnézed a snap működését láthatod, hogy vannak külön app csomagok és framework csomagok.

Valószínűleg úgy fog ez működni, hogy az ilyen függőségek, mint a qt, java, vagy python önálló framework csomagban lesznek, akár több verzió külön külön is elérhető lesz, és mindegyik app csomag arra fog hivatkozni, ami neki éppenséggel kell. Ha több appod van, és mindegyiknek más verzió kell, akkor fent lesz több verzió ugyanabból, és mindegyik használj azt, ami neki való.

Nyilván nem fogják a qt-t, vagy az egész java jre-t csomagolni minden egyes qt-t vagy javát használó app csomagjába bele.

nem azzal, hogy egyszerre többféle Java is fentlehet a gépemen?

És akkor, mondjuk az ÁNYK-s csomag megmondja, hogy neki 1.7_u13 (hasraütöttem) verzió kell, a JetBrainses dolgok, hogy nekik 1.6 legutolsó, a de másik három Java alkalmazás meg az 1.8 valamit (ugyanazt) szeretné.

Ilyenkor, most vagy van egy JVM a gépemen, és minden azt használja (1 függőség, de rengeteg app nem megy), vagy __mindenki__ maga mellé csomagolja a megfelelő JVM-et (ez legalább 5 JVM a fenti példában.) Legalábbis, én, most felhasználóként nem ismerek más módszert .deb csomagkezeléssel. (ha van, akkor megköszönök minden segítséget)

De a snappel mindenki megmondja, melyik JVM kell neki - és akkor ők azt látják, a többit nem, futás közben. Így nem kell mindenkinek maga mellé csomagolnia (elég 3 példány, nem kell 5), de mindenki a megfelelő verziót látja maga mellett.

Ez egy sokkal low-levelebb libnél azért meg tudja könnyíteni az ember életét, szerintem. De lehet, teljesen rossz elképzelésem van a snapről.
--
blogom

Ha jól értem a dolgokat, akkor a snap abban több, hogy nem csak az alkalmazások telepítését hanem a futását is menedzseli. Telepítéskor nem a klasszikus módon kihány egy csomó fájlt a helyére a fájlrendszerben, hanem alkalmazásonként szeparáltan teszi, és az alkalmazásokat sandboxban futtataja úgy, hogy mindegyik alkalmazás csak azokhoz a komponensekhez fér hozzá, amire neki tényleg szüksége van.

Nyilván megoldják, hogy adott app hozzáfér a fájlrendszer azon részeihez, amihez neki hozzá kell férnie. Egy mc esetében ez nyilván a teljes root lesz.

Ami szerintem (legalábbis desktopon) kényelmes és biztonságos lenne, ha alapból egy app se férne hozzá semmihez, csak a saját sandboxolt gyökeréhez. Ott tárolhat beállításokat, cache-t, mindent, ami kell neki.

Ha pedig az user cuccaival kell dolgoznia, a közösből betölteni valamit, vagy oda írni, akkor az usertől kellene hozzáférést kérnie egy rendszerszintű apin keresztül.

Teszem azt, egy böngésző az első letöltés megkezdése előtt meghívja az apit, hogy az user jelöljön ki egy mappát ahova a letöltések mennek. Az user kijelölhetne egy mappát, bepipálhatná, hogy ez az engedély tartós legyen, vagy csak amíg fut az app.

Vagy egy képszerkesztő a kép megnyitásakor meghív egy apit, hogy az user válasszon már ki egy fájlt. Aztán amíg az app fenntartja a referenciát ahhoz a fájlhoz, addig hozzáfér.

A különbség a mostani fájl megnyitás/mentés dialógusokhoz képest annyi lenne, hogy nem az alkalmazás intézné a fájlkiválasztás/jelölés részét, hanem egy rendszerkomponens, az app nem tudna a fájlrendszerről és a fájlokról semmit, csak arról, amihez majd hozzáférést kap. Megbízhatóbb lenne, mert csak azért nem kell az alkalmazásnak minden fájlt látni, hogy tudjon mutatni egy listát, hogy aztán te egyet kiválassz. Megbízhatóbb olyan szempontból is, hogy az app sunyiban nem tud más fájlokhoz nyúlkálni.

Egyébként androidon hasonló van már. A fejlesztők dolgoznak is ellene, inkább kérik a jogosultságot a teljes sd kártyához, mintsem az android fájl/mappaválasztójára hagyatkozzanak, csak mert... valahogy lopni kell az user adatait :) Vagy ios-en. Ott nincs olyan, hogy egy fájlrendszert lát minden app, mindegyik a sajátját látja, és ha egy képet tallóznál be, akkor hozzáférést kell adnod a camera roll-hoz.

Persze ez egy olyasmi amit a hardcore régi motorosoknak le kell nyelni, mert azért ez mégis csak egy plusz réteg korlátozás.

Az UAC nem így múködik.

"De a legbiztonságosabb mégis csak az volna, ha a user nem férne hozzá a számítógép power on gombjához;)"

Vagy mindenki olyan programot használna csupán, aminek a kódját saját maga nézte át, és győződött meg arról, hogy az a program tényleg csak azt teszi, amit el is vár tőle. A programokat pedig megbízható arcok írnák hátsó szádék nélkül :)

home

Can access non-hidden files in user's $HOME to read/write/lock. This is restricted because it gives file access to the user's $HOME.

Usage: reserved Auto-Connect: yes

Enélkül vajon van hozzáférése a home-ban levő rejtett fájlokhoz/könyvtárakhoz, vagy azokhoz úgy en bloc nem lehet hozzáférést kérni/adni? Egyik se jó, a) esetben random snap lophatja pl. a levelezésemet, b) esetben grafikus alkalmazásoknál (mert ugye elvileg azokhoz tervezték) tök jó lesz, hogy pl. minden alkalmazásban más és más fontokat lát fog látni még ugyanaz a user is. (csak ezért most nem telepíteném :) )

BlackY
--
"en is amikor bejovok dolgozni, nem egy pc-t [..] kapcsolok be, hanem a mainframe-et..." (sj)

Én azt gondolnám, hogy nem lesz hozzáférésed a rejtett fájlokhoz és a home-on kívüliekhez egyáltalán.

A Krita-t felinstalláltam és valóban csak a home könyvtáram látszik, illetve a /snap/krita könyvtár.
Az Open ablakban nem látszanak a rejtett fájlok, de a képet el tudom nevezni rejtett fájlnak és az Open recent meg is tudja nyitni, illetve könyvtárat is tudok átnevezni rejtett nevűre.

Szerk.: kicsit azért fura, mert ha begépelem pontosan egy külső könyvtár nevét, akkor már látja a könyvtárat, de benne a fájlokat nem, ha fájl nevet gépelek be, akkor a fájlt is látja, ki is írja a méretét, módosítás idejét, de a könyvtár listában nincs benne és megnyitni sem tudja.

Mire akarsz kilyukadni? Hogy akadályozza meg az UAC, hogy a firefox sunyiban hozzáférjen a dokumentumok mappa tartalmához például? (amire ugye semmi szüksége, de egy gyanús weblap egy ffox sebezhetőséget kihasználva könnyedén okozhat kárt). Egyébként nem olvasom el ezt a dokumentumot, abból indulok ki amit windows alatt láttam.

Korábban ez volt a terv, de úgy tűnik, hogy ezt már elvetették és automatikus deduplikálást csinálnak, legalábbis endi123 ezen bejegyzése szerint.

Tehát, ha jól értem, akkor pl. az ÁNYK telepítésénél, amiben benne lesz a Java 1.7_u13, ha le akarom tölteni, de már a gépemen van már másik snap alkalmazás, amiben benne van a Java 1.7_u13, akkor nem tölti le újra és nem is telepíti, csak a maradékot.
Természetesen ennek is van előnye is, hátránya is.

Disztribúció független, már most elérhető szinte mindegyikre. (Ebben jön fel mellé most a Snap)

Ott már megoldott a library-k kiszervezése, így pl. a LibreOffice hagyományos csomagok ~240MB-osak, a snap csomag 1.1GB, a flatpak 150MB.

Deduplikálva (ostree) tárolja a fájlokat, így telepítve is kisebb lesz, mint a Snap-es.

Ez nem része a környezetnek, hanem hasonló csomag, mint az alkalmazás, de ebben a függő library-k vannak csak, pl. Qt, Gnome, Java, ... lib.
Tehát ahelyett, hogy 101MB Qt lib. + alkalmazás lenne egy csomagban, lesz két csomag egy 100MB Qt csomag és egy 1MB alkalmazás csomag, amihez kell a Qt csomag is.
Ha pl. 10 Qt alkalmazást felraksz, akkor 1010MB helyett csak 110MB-ot fog foglalni.

Ezt a csomag fajtát FlatPak-nél Runtime-nak hívják, Snap-nél Framework volt még korábban, de most már nem találok utalást rá.

A szövegértés neked sem erősséged? Egyetlen feature-ről beszélünk ebben a szálban.
Igen, ezt csinálják a csomagkezelők is, és?
A Ferrarinak is négy kereke van, meg a Trabantnak is.
Egyik bizonyos dolgokban jó, a másik másokban.

Ráadásul az új csomagkezelők (flatpak, snap, docker) nem zárják ki a régieket, szépen megférnek egymás mellett.

Ha megéljük, meglátjuk. Addig is hype-oljunk lelkesen.
Egy kis off-topik: 


Debian:
$ readelf -d libssl.so.1.0.0 | grep SONAME
 0x000000000000000e (SONAME)            Library soname: [libssl.so.1.0.0]

Centos:
$ readelf -d libssl.so.1.0.1e | grep SONAME
 0x000000000000000e (SONAME)             Library soname: [libssl.so.10]

a snap csomag 1.1GB, a flatpak 150MB
A szoftverhez kellenek a függőségek, ezért csalóka ilyenekkel reklámozni a flatpakot (a készitőre gondolok).

Elvileg csak a letöltés menete más, a végeredmény ugyanaz:
A snappy letölti a csomagot (deduplikáltan), és deduplikálva tárolja (a függőségeket).
A flatpak letölti a csomagot, deduplikálja a csomagban foglalt függőségeket, és letölti a csomagban nem található függőségeket.

Lényeges különbség inkább abban van, hogy:

- Snap esetén a függőségek fixek. Ennek fontos következménye, hogy egy adott snap mindig mindenütt ugyanúgy fut. Ha valahol hiba van, könnyű reprodukálni.

- Snap minden függőséget tartalmaz.
Általában snapot és flatpakot repoban fogják tárolni, saját protokollal elérhetően. Normál esetben nem fogunk 1.1GB snap v.flatpak fájlokkal találkozni. A letöltést, frissítést rsync szerűen intézi mindkettő, csak azt tölti le ami hiányzik.
Amikor ki szeretnél menteni magadnak egy programot (későbbre, ha nem lesz net, vagy odaadni vkinek), akkor vagy csinálsz egy saját repót, vagy lemented kézzel fájlokba. Egyedül itt jön be az, hogy snap vagy flatpak fájlokkal bíbelődj. Snap esetén 1 fájl lesz, flatpak esetén könyvtár.

Ezeket honnan veszed? A Snappy oldalán semmi ilyesmit nem találok. A korábbi phoronix cikkben valóban van olyanról szó, hogy dolgoznak rajta, meg jó volna ilyesmi.
Ha már ezek készen vannak, akkor a Snappy leírásánál ezeket miért nem írják?

Mindenesetre akár készen van, akár majd kész lesz, ez jó hír! ;)

Szerk.:
"vagy csinálsz egy saját repót,"

Ez is a FlatPak-nél szépen le van írva, hogy tudsz ilyeneket csinálni, de a Snap-nél nem találtam ilyet, még csak utalást sem rá.

( enpassant v | 2016. 06. 16., cs – 17:33 )

A turorial alapján, kipróbáltam Ubuntu-n a demó csomagokat (hello, hello-world), szépen települnek is, de a hello, hello-world parancsokra ezután azt mondja, hogy nincs ilyen.
Mi lehet a gond? 


> snap list
Name         Version               Rev  Developer  Notes
ubuntu-core  16.04+20160531.11-56  122  canonical  -

> sudo snap install hello

Name   Version  Rev  Developer  Notes
hello  2.10     20   canonical  -

> snap list
Name         Version               Rev  Developer  Notes
hello        2.10                  20   canonical  -
ubuntu-core  16.04+20160531.11-56  122  canonical  -

> hello
zsh: command not found: hello

> hello.command
zsh: command not found: hello.command

Próbáld így: 


man snap

info snap

snap --help

jó eséllyel valamelyik elárulja, hogy mi a "dpkg -L hello" avagy "rpm -ql hello" megfelelője, amiből kiderül, hogy végül is települt-e bármiféle futatható program, és ha igen, akkor milyen egzotikus könyvtárba ($HOME/bin, pl)

( mrev | 2016. 06. 16., cs – 18:54 )

Mekkora egy gtk-s hello world program snappy csomagja?

A csomagoláskor meddig lesznek követve a függőségek? Egy alkalmazás hivatkozik néhány so könyvtárra, azok némelyike hivatkozik további so-kra és így tovább. Egy egyszerű alkalmazás is be fogja húzni a rendszer jelentős részét.

A libc része lesz minden snappy csomagnak?

--
ulysses.co.hu

Szerk.

Korábban néztem az Ubuntu core-t, akkor teljesen kezdetleges állapotban volt, nem volt benne semmi, ami az élethez nélkülözhetetlen. Változott-e ez a helyzet mára? Érdekelt volna, hogy milyen ötletek és algoritmusok vannak a dolog mögött, kicsit szétnéztem a google-ben, de csak hülye buzzwordöket találtam, hogy gyors, tranzakciós, cloud és iot, meg effélék, és semmi arról, hogy hogyan működik. Mintha direkt titkolnák.

( Dacr (nem ellenőrzött) | 2016. 06. 18., szo – 23:48 )

Tehát a /var/lib/snapd/snaps alatt lévő hello-world_26.snap mindent tartalmaz, ami kell neki és nem csomagolja ezt kisehova, hanem a program meghívásakor a snapd ezt a konténert indítja el (minden függőségével a memóriába kicsomagolva)? Jól értem? Ez akkor azért memóriában is zabálni fog, nem csak diszken, mert ha van két progim ugyanazon függőségekkel, akkor két példányban lesz a memóriában a függőség. Nem?
Nagyon nem látom még át a motorháztető alatti működését, örömmel venném, ha valaki tisztába tenné ezt nálam :)
Áh, látom csinált a / alá egy snap mappát és ide csomagolt ki mindent.

Ebből az írásból kiderül, hogy egy nagy hazugság az egész bejelentés, szó sincs arról, hogy együttműködnének a különböző disztribúció készítők, sőt nem is keresték meg őket.
A repository nem nyílt forrású és nem is várható, hogy az legyen, azt várhatóan csak a Canonical fogja üzemeltetni.
A Canonical továbbra is egyedül csinálja és még erősen félkész állapotban van.

Szerk: ja és systemd, dehát azt mondani sem kell.

Snapnél nem, Poetteringnek saját tervei vannak és tudjuk, hogy akkor még upstream-et is képes megállítani :) http://0pointer.net/blog/revisiting-how-we-put-together-linux-systems.h… [disclaimer]anti-systemd-ellenes vagyok, szerintem jó cucc[/disclaimer]

BlackY
--
"en is amikor bejovok dolgozni, nem egy pc-t [..] kapcsolok be, hanem a mainframe-et..." (sj)

Csak én érzem úgy, hogy a Fedora 24 release posztjába nem ok nélkül került bele ez:

Flatpak (formerly xdg-app) is another building-block feature, with Software able to track installed Flatpaks and adding more features in the future as the technology develops.

:)

BlackY
--
"en is amikor bejovok dolgozni, nem egy pc-t [..] kapcsolok be, hanem a mainframe-et..." (sj)

Ez rendben is van, éljen a verseny, de AFAIK már 23-ban is ott volt az alap repókban a Flatpak, úgyhogy ezt tényleg nem tudom másként értékelni, mint egy (szvsz. nagyon helyes) visszaszólás a Canonical (tényleg... megkérdőjelezhető) PR fogására :)

BlackY
--
"en is amikor bejovok dolgozni, nem egy pc-t [..] kapcsolok be, hanem a mainframe-et..." (sj)

Hát, RHEL-ék a 6-ban pl. pont rárepültek :)

In Red Hat Enterprise Linux 6, init from the sysvinit package has been replaced with Upstart, an event-based init system. This system handles the starting of tasks and services during boot, stopping them during shutdown and supervising them while the system is running. For more information on Upstart itself, refer to the init(8) man page.

(https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Linux/…)

BlackY
--
"en is amikor bejovok dolgozni, nem egy pc-t [..] kapcsolok be, hanem a mainframe-et..." (sj)

( NevemTeve | 2016. 10. 16., v – 10:19 )

Azóta valami változás? Meghódította a snap a világot, vagy azóta már újabb univerzális megoldás született?