A Skype mostantól hivatalos snap-ként elérhető a Linux felhasználók számára

 ( trey | 2018. február 2., péntek - 10:21 )

A Skype mostantól hivatalos snap-ként elérhető a Linux felhasználók számára. Részletek a bejelentésében.

Hozzászólás megjelenítési lehetőségek

A választott hozzászólás megjelenítési mód a „Beállítás” gombbal rögzíthető.

Hogy miként?

+1, mi az a snap?

Disztribúció-független csomagformátum a Canonicaltól: https://snapcraft.io/

Es ez a snapsz tud olyat, hogy elzarja a skype-ot minden mastol :) ? En csak ezert nem hasznalok skypeot...

sudo snap install skype

error: This revision of snap "skype" was published using classic confinement
and thus may perform arbitrary system changes outside of the security
sandbox that snaps are usually confined to, which may put your system at
risk.

If you understand and want to proceed repeat the command including
--classic.

:(

igen. Legalábbis for certain definition of elzárja, de apparmorozott, talán cgroupsozott, saját rw mountos area, snapek közötti interfaceket lehet engedni, nem engedni. Mármint lehet olyan is, hogy a skype snap használja-e, azt passz.

Mondjuk mikor utoljára néztem, akkor selinux pl még nem ment, anélkül meg nehéz valami nem ubuntun.

"Disztribúció-független" jó is lenne, ha már az lenne :)

A készítők állítása szerint a népszerű disztokban elérhető.
Szóval többé-kevésbé annak tekinthető, nekem akkor sem tetszik. :(

Aztán fel akarja tenni az ember máshova és rájön h outdated verzió meg senki sem tartja karban :)

Na igen... a "disztok" nem tűnt fel? Így is majdnem értelmes a mondat. :DDD
disztrok akart lenni...

thx

Valami, aminek a unity mellett lenne a helye ;)
Rettentően utálom, ha egy rendszeren egynél több csomagkezelő van. Ubuntun most akkor is ez a helyzet, ha eltekintek a python, a ruby sajátjától és az eclipse marketplace-től.

Ha egy projekt OS és OS-en belül disztrófüggetlen akar lenni, akkor a legjobb megoldása, ha saját csomagkezelőt épít.
Az jár a legkevesebb munkával + minden disztrón ugyanazt az élményt kapod, a csomagok elnevezése nem disztribúciófüggő, stb.

+1
Most itt van a snap mikor már van flatpak és appimage. Lenyomják mindenki torkán majd pár év múlva dobják.
Szerintem létjogosultsága sincs ezeknek Linuxon mert épp a Linux lényeg veszik el vele.
Eddig is meglehetett oldani, hogy egy appnak minden függősége ott legyen mellette. Csak ugye 2018-ban ne keljen már a felhasználót megkérni, hogy md5sum apnname.tar.gz majd sudo tar -zxvf apnname.tar.gz -C /opt/appname , mert képtelen rá, de ha egy 'csomagkezelő' ezt teszi az már OK.

Nem lesz ennek ugyanaz a vege, mint Windows alatt (volt?) szokas, hogy minden program mindenhova szemetel, aztan uninstall utan ott marad a szemet fele?

Nem, mert saját mappa alá tesz mindent:

https://docs.snapcraft.io/reference/confinement

attol meg otthagyhatja a szemetet :-)

Siman el todok kepzelni olyan verzio frissitest, ahol mondjuk egy regi lib melle kerul egy uj, es ugyan a regi nem kell mar, de ott marad.

De legalabb nem kell evente ujratelepiteni, mint a Windowst kellett, hanem eleg evente letorolni az osszes snap cuccot es ujra telepiteni a legfrissebb verziokat.

Egyetértek. Arra gondoltam hogy a sandbox miatt elég a saját mappáját törölni kézzel az uninstall után maximum, úgy tuti törlődik minden.

"Nem, mert saját mappa alá tesz mindent:"

Elvileg Android appoknak is így kéne működni, mégis egy csomó szemetel a közös tárolóba.

Mert kér és kap hozzá engedélyt. Ahogy néztem, strict módban nem tud szemetelni a snap app.

Persze. Tehát sokat nem fog érni a snap sem, ha tud kérni, és fog kapni engedélyt mondjuk a teljes home mappához, vagy letöltés mappához, vagy akármihez.

Pedig olyan felhasználási módok bőven vannak, ahol van értelme ennek. Aztán innentől könnyű abuzálni a rendszert. Ahogy azt Androidon is teszik.

Strict módban nem tud szemetelni: Úgy érted, hogy egyáltalán nincs mód arra, hogy egy app hozzáférjen a saját mappáján kívül valamihez? Akkor viszont hogy oldja meg a külső fájlok betöltését, vagy írását, ha a user szándékosan menteni akar? Van egy ötletem arra hogy volna jó, lent írtam is, de kétségeim vannak afelől, hogy ez tényleg így is működik.

Androidon a fájl betöltés annyi, hogy eldobsz egy intentet, majd amelyik alkalmazás hallgat rá, megpróbálja betölteni, és visszaadni.

A gyakorlatban kiválasztom, melyik fájlkezelő töltse be, neki meg már van joga hozzá. A snap világban nem tudom hogy néz ki, de valami hasonló (rendszerkomponens, ami csak betölt, s az app már csak a memóriaban kap egy objektumot a filera) lehet megoldás.

Lesd meg a fenti linket. Az én olvasatomban nem fér máshoz strict módban a saját mappáin kívül. Az hogy te milyen app-ot telepítesz és annak milyen joga van, teljesen rajtad áll, ahogy Android-on is.

+1

Mi van?

Annyiszor volt már téma a hup-on is a snap, hogy megdöbbentett a csodálkozásotok.
Jó, én még csak egyszer használtam egy nagyon alfa android emulátor telepítésénél, de akkor az egyszer tette a dolgát. (Nem úgy, mint az emulátor, aminek már a neve sem ugrik be.)

+1, én sem értem ezt. Még ha az ember nem is használja, volt itt arról szó, hogy hacsak nem új tag vagy, legalább felületesen tudod mi az a snap

Ezt néztem én is. Mi a tök? Túl öreg vagyok. El kéne mennem inkább napszámosnak.

--
Tanya Csenöl az új csatorna

Szerintem jól megcsinálták és rengeteg munkát spórolnak sok embernek. Gyakorlatilag az van, hogy az eredeti csomagkezelővel az OS libjeinek verzióihoz illesztett programokat tudsz feltenni. Viszont ha újabb kell, akkor nem kevés szívás és munka a forrásból fordítgatás meg a szükséges újabb libek biztosítása.

Snappel meg a cucc hozza magával a függőségeit és így tudsz használni újabbat adott programból egyetlen kézmozdulattal, ráadásul automatikusan frissülve.

Nézzétek meg a store-t, elég jó cuccokat raktak fel (például Ubi 16-os verziókhoz viszonyítva LibreOffice 5.1 -> 5.4, Inkscape 0.91 -> 0.92, Gimp 2.8.16 -> 2.8.22, friss adatbázisok stb):

https://snapcraft.io/store/

Lassan eljutunk a kutyafule.msi-ig. ;)

----------------
Lvl86 Troll, "hobbifejlesztő" - Think Wishfully™

Nekem a gobolinux jutott eszembe :-)

Szép lassan újrafeltalálnak mindent, ami a VMS-ben WNT-ben létezik.

Ez igaz :) Viszont Win-en a másik féle nem volt szerintem. Illetve alapból nem korlátozza az app-ok jogait ún. sandbox-al.

Erre is lett volna szépen lassan az UWP. Erre persze mindenki elkezdett sírni, hogy jaj, mi lesz a winapi-val, amit korábban mindenki a pokolba kívánt. :)

De ilyen ez, hogy van-e rajta sapka vagy nincs.

----------------
Lvl86 Troll, "hobbifejlesztő" - Think Wishfully™

Szerintem az UWP az átlag userek miatt bukott meg. Olyanok miatt akik azt sem tudják mi az a winapi és nem is érdekli őket. Abban a csomagban ahogy azt a Microsoft erőltette egy rossz termék. Piacképtelen.


Normális HUP-ot használok!

Igazából nem az UWP a lényeg itt, hanem az appx, és Win32 API-t használó alkalmazást is becsomagolhatsz abba és teríthetsz Windows Store-on keresztül. Ilyen például a Paint.NET, az Inkscape, a Spotify stb. Egyik sem UWP app.
Az UWP másra való.

Persze milyen remek hogy felteszek 10 darab msi-t, mert 10 darab alkalmazást telepitettem. Ezek felraknak 8 féle Qt-t, 2 féle Gtk-t, 4 féle openssl -t, meg 5 féle JRE -t. Aztán hogy ezek közül ki és hogyan telepiti majd a security updateket az már a kutyát nem érdekli.

Aki szeretne kulturáltan csomagkezelni és közben folyamatosan mindenből frisset használni, az menjen archozni. Az uborka féle csomagkezelés ezek szerint arról szól hogy fél-1 évente kiadunk egy nagy release -t. Aki ezt használja az napról napra elavultabb (bár legalább karbantartott) szoftvereket használ, aki meg frisset szeretne, az mehet kókányolni (ppa, snap, kutyafüle).

--
debian,libreelec,openmediavault,ubuntu,windows,arch,lineageOS
zbook/elitebook/rpi3/nexus5_hammerhead

a corporate vilag arra hasznalja, hogy kitol valamit a gyarkapun, es a helyet is beszantja (ie. nem foglalkozik vele tobbet).

Viszont van egy masik felhasznalasi terulete, ami baromi jo:
CI-bol csinalsz appimage-t egy projektbol. Igy barki tesztelheti a legujabb git verziot, megha regi linux disztroval is rendelkezik.

En nehany programot igy telepitek. Szerintem tok jo megoldas.
Ugye ha .deb-et gyartasz, akkor melyik ubuntu verziora? a legutobbi lts-re?
vagy ami most fog megjelenni? vagy a ketto kozott levo 3 verzio valamelyikere?
Vagy masik linux disztrora? Ez orult mennyisegu munka, amit egy random projekt nem tud felvallalni. De egy appimage keszitest igen.

Az se eletszeru, hogy mindenkitol elvarod, hogy forrasbol tudjon telepiteni, majd azt frissiteni hetente.

---
Saying a programming language is good because it works on all platforms is like saying anal sex is good because it works on all genders....

"Az se eletszeru, hogy mindenkitol elvarod, hogy forrasbol tudjon telepiteni, majd azt frissiteni hetente."
Miért?
Még egy Gentoo sem követeli meg a fordított forráskód ismeretét. Egy portage/emerge gui frontend használata nem bonyolultabb mint egy Ubuntu szoftverközponté. Legfeljebb tovább tart a csomag "telepítése".


Normális HUP-ot használok!

Üdvözöllek az informatikában. Ez egyébként minden területen előfordul: ld. .NET: projekt referenciát használsz? Ki tudja, hogy mikor töri el valaki a másik projektben az API-t, ami miatt a te cuccod nem fog menni. nugetet csinálsz belőle? Ok, megoldja a törés problémát, viszont akkor fogsz szívni, ha majd egyszer frissítesz.

Nagyon téves az az elgondolás, hogy egy disztribúció összetákolója és csomagolója pontosan és jól tudja, hogy milyen lib mikor hogy mivel cserélhető és mit fog eltörni melyik programban.

----------------
Lvl86 Troll, "hobbifejlesztő" - Think Wishfully™

> Nagyon téves az az elgondolás, hogy egy disztribúció összetákolója és csomagolója pontosan és jól tudja, hogy milyen lib mikor hogy mivel cserélhető és mit fog eltörni melyik programban.

Ez azért többnyire igaz a fejlesztőre is aki annyit tud tenni, hogy teszteket ír, amit a disztribútor épp úgy tud használni mint ő maga. Nem gondolom, hogy emiatt lenne szükség a snapra/flatpakre.

Nekem inkabb azt aruld el, hogy ubuntu sajat homebrew megoldasa mitol jobb, mint a masik ketto?
(flatpak, appimage).

Ha fogadni kene, akkor en azt mondanam, hogy az appimage fog elterjedni, es ket ev mulva ezt *is* dobja az ubuntu.

Olyan deja vu erzesem van... (mir vs. wayland, upstart vs. systemd, stb, stb)

---
Saying a programming language is good because it works on all platforms is like saying anal sex is good because it works on all genders....

Mitől jobb? Jó cég áll mögötte és sandbox-olja a cuccokat, illetve megvan az erőforrása a cégnek az elterjesztéshez és a különféle OS-ekre való ráreszeléshez.

Eddig az uborka az összes innovációját beszántotta, mert nem terjedt el, de ne igyunk előre a medve bőrére :)

--
debian,libreelec,openmediavault,ubuntu,windows,arch,lineageOS
zbook/elitebook/rpi3/nexus5_hammerhead

Telegram snapként van fent bubin, a home alatt egy snap almappa alá menti a dolgait (megosztott képek, fájlok pl.), nekem pl. marha idegesítő.

En rendkivul szeparacio/izolacio parti vagyok. Szamomra inkabb az a zavaro, ha minden egy mappaba dobal be mindent es minden mindent lat. Ha nincs valamire apparmor profil, csinalok magamnak.
De izlesek es pofonok... :)

Az oké, csak minek ehhez egy "snap" almappába rakni? Ha valami telegramban letöltött cuccot keresek, akkor azt keresem a Downloads, esetleg egy Telegram mappában a home alatt, a "snap" az eszembe se jutna.

Nyilván ha rákeresek a "telegram" szóra meglesz, de akkor is, milyen user experience már ez?

Lehet azért kell külön gyűjtő mappa, hogy tudják AppArmorral szeparálni az adat hozzáférést.

LOL

Pedig így logikus szerintem és egyszerű az AppArmor confinement:

https://docs.snapcraft.io/reference/confinement

Idézet:
Strict confinement gives you the following readable and/or writable paths:

- /snap/<snap>/<revision> (read-only, snap install path)
- /var/snap/<snap>/<revision> (read/write, per-revision data)
- /var/snap/<snap>/common (read/write, common data)
- /home/$USER/snap/<snap>/<revision> (read/write, per-revision user data)
- /home/$USER/snap/<snap>/common (read/write, common user data)

" Ha valami telegramban letöltött cuccot keresek, akkor azt keresem a Downloads, esetleg egy Telegram mappában a home alatt, a "snap" az eszembe se jutna."

Szerintem nem az a tervezett viselkedés. Mármint egy snap alkalmazásnak illene tudnia a snap mappán kívül is elhelyezni user adatokat. Csupán beállítás kérdése.

Persze ha a snap csomag default hozzáférést kapna a home mappádhoz, akkor meg az lenne a probléma, hogy vajon mi máshoz nyúl még ott hozzá?

Ideális egy olyan jogosultságrendszer lenne, ahol minden alkalmazás a saját kis burkában élne, és egy speciális apin keresztül tudna csak hozzáférést kérni és kapni rendszerkomponenseken keresztül (nem saját file dialóguson) saját hatókörén kívüli fájlokhoz.

Teszem azt telegramban amikor lementesz egy fájlt, akkor bejön egy rendszerkomponens, amivel kijelölöd hova menthet, az alkalmazás kap egy referenciát, amit használhat amíg le nem zárja. Vagy ugyanez egy teljes mappával.

A sokat szidott GoboLinux nem ilyen volt?
Most vágott belém a felismerés villáma: Poliverzum 10 évvel megelőzte a korát, a HUP-ról pedig bannolva lett.

Akkor lelkek lehetünk. Erősen szeparáció/izolációpárti vagyok magam is, értsd az ilyen MS- és snap-féle hulladékokat olyan erősen szeparálom el az egész géptől, hogy fel sem teszem, megy a szemeteskonténerbe/profilba/levesbe.


„Pár marék nerd-et leszámítva kutyát se érdekel már 2016-ban a Linux. Persze, a Schönherz koliban biztos lehet villogni vele, de el kéne fogadni, ez már egy teljesen halott platform. Hagyjuk meg szervergépnek…” Aron1988@PH Fórum

Ez is egyfele vedekezes. :)

Pontosan milyen szempont alapján tartod hulladéknak?

Én meg simán megoldottam egy saját webapp scripttel a linuxos skypeot. :-)


Normális HUP-ot használok!

Remek ötlet ez a snap, így már minden csomag linuxon is lehet végre több 100 megás...
Mondjuk ezek az elektronos szarok már alapból bazi nagyok. Dehát olcsó a tárhely meg a ram, minek takarékoskodni.

Úgy van. Az shared objectek is feleslegesek. Jobb mindent statikusan linkelni.
--
ulysses.co.hu

Teljes VM/csomag?

Az nem a docker? ;)

Ami pontosan annak a következménye, hogy ha azt akarod, hogy működjön a saját programod, akkor nem bízhatsz meg a 3rd partykban.

----------------
Lvl86 Troll, "hobbifejlesztő" - Think Wishfully™

32 gb ramom van, és 20 ezer bruttóért vettem 1TB -os (1000GB-os) vinyót. Az amazonban meg konkrétan fillérekért veszek neked akárhány GB helyet. Tehát RAM és disk manapság annyi van mint a disznó, tehát kit érdekel.

--
debian,libreelec,openmediavault,ubuntu,windows,arch,lineageOS
zbook/elitebook/rpi3/nexus5_hammerhead

RPi-t nem használsz ebből következően. :D

Mit jelentenek nálad a fillérek?

Amazonban 1 GB tárhely S3-ban: $0.0245 per GB, azaz 2,45 dollárcent, az jelenleg 6 forint gigabájtonként havonta 248,71 forinttal számolva dolláronként.
Ha long-term backupot akarsz, akkor Glacier, $0.0045 per GB, azaz 0.45 dollárcent, az jelenleg 1.2 forint gigabájtonként havonta.

Mondjuk, ezekben az olcsó a tárhely/ram kombókban mindig az tetszik, amikor szembesülsz azzal, hogy már megint elfogy valamelyik production DB alatt a tárhely, ami csak n*10 GB :P

Másrészt: hiába olcsó a tárhely, a sávszélesség szűkös.

----------------
Lvl86 Troll, "hobbifejlesztő" - Think Wishfully™

ez egy piros pont az m$-nek.

--
GPLv3-as hozzászólás.

Snap... vicces egy jószág. Ugye egy linuxos repoból általában free, openszósz szoftverek telepíthetőek (egy apt-get install a "gyári" repokból nem hoz mást).
Na, itt a snap, akár egy rubymine is telepíthető. Heppi. Ja, mégse: ez egy 30 napos demo.

De van más is: snap find paraméter nélkül, ubuntu 16.04-en ad egy 18 soros listát. Egy "snap find a" már 45 sor. Honnan? Miért? Az egy dolog, hogy nézzem meg a doksit, de ez enyhén szólva is logikátlan. Ráadásul a find-nak nincs sok paramétere, a --sections az egyetlen érdemi paraméter, de az a help szerint "restricts..." ami az én értelmezésemben szűkítést jelent. Szóval na... utálom. :D

Az update sem update nála hanem refresh. Miért kell állandóan eltérni a standard-ektől? Minden csomagkezelőnél update van. Felügyelhette volna hozzáértő Ubuntuéktól legalább a tervezés elején.