Az Ubuntu Desktop Next .deb csomagformátumról Snappy-re vált

Címkék

Will Cooke a Google+-on jelentette be, hogy fontos közlendője van a Desktop Next-et használók számára. Mégpedig az, hogy terveik szerint a 15.10 már az Snappy Personal-ra (Snappy Personal = Snappy for desktop) épülne, ezért a jelenlegi, .deb alapú Desktop Next image búcsúzik és a helyét az új Snappy-re épülő image veszi át.

Cooke szerint a jövő a Snappy, ezért a felhasználók hamarosan kézhez kapnak egy Snappy alapú image-et, hogy játszhassanak vele.

A részletek itt olvashatók.

Hozzászólások

Mi a baj a deb-bel? Túl azon, hogy így nehezebb lesz a debianból átemelni a csomagokat.

Nem tudom mit kavarnak, de remélem nem valami elbaszott dolog lesz az eredménye, mert akkor megyek vissza Debian-ra. Nekem a Debian csomagkezelése az, ami megtetszett, ami miatt '98-'99 körül Debian-t kezdtem használni. Mivel az Ubuntu is azt használt és szimpatikus volt, váltottam Ubuntu-ra 2005 környékén. De ha nekem valami ótvart raknak össze, akkor szívbaj nélkül megyek vissza Debian-ra.

--
trey @ gépház

Én is a .deb, dpkg meg apt miatt kezdtem el ugyancsak 99-ben Debiánt használni. Tényleg mestermunka az ahogy a Debian megoldja a csomagkezelést. Frappáns, konzisztens, mérnöki szemléletel könnyedén átlátható és mind fejlesztőként ahogy felhasználóként megbízható.

Ugyanakkor végignéztem a Maemo nyüglődését a dpkg alapú rendszerfrissítésekkel. Tényleg a kínok kínja volt megcsinálni és és üzemeltetni. A debian csomagkezelési rendszere egyszerűen nem a mitsemsejtő egységsugarú konszúmer divájszának az automatikus karbantartására való. Kínok kínja a hatalmas függőségi piramisok konzisztensen tartása. Vért hugyozol, ha egy alsóbb szintű libet vagy szolgáltatást kell frissítened, mert huszonmilliárd szirszat csomag abúzálja a nem ritkán privátnak szánt API-kat és csomagok tucatjai fossák össze magukat egy-egy rendszerfrissítésnál. Tegye fel a kezét az a Debian/Ubuntu felhasználó aki mondjuk 3 éves távban még nem futott bele abba, hogy a terminálból kelljen dpkg --force-all típusú buherákkal meg repó ki - repó be varázslatokkal helyrehozni egy-egy furcsaságot ami a dist-upgrade (nem release upgrade!) után. Ez marhára benne van a pakliban. Ráadásul egy upstream developernek tényleg agyrák, hogy hónapokba kerül még a legjobb esetben is egy-egy alkalmazás frissítése a disztróban. Pedig sem a Debian sem az Ubuntu asztali kiadása nem egy app paradicsom... Gondolj bele abba, hogy mi lesz amikor tízezerszám lesznek fingóalkalmazások, akkor ki fogja ellenőrizni őket? Ki fogja láttamozni a huszonmilliárd .deb csomagot, hogy mehet-e egy releasebe?

Szóval... szép és jó a dpkg meg a .deb, de sajnos a mai elvárásoknak nem felel meg. Ha nagy szavakat akarnék mondani akkor azt mondanám, hogy valahol ez volt a gátja a Linux desktop komoly sikerének. A .deb/dpkg világban nem lehet pengén gyors itterációkban kitolni az újabb verziókat.

Na és akkor ezt még csak a disztró meg az upgrade probléma. A legnagyobb probléma a .deb világgal az a biztonság. Van mondjuk egy átlag Debian/Ubuntu installod... ott figyel az összes kontatod meg leveled a ~ alatt. Aztán letöltesz egy fingó alkalmazást .deb formában. Installod, megnyitod.. nyomkodod, röhögsz :) Pont ahogy kell. Ki és hogyan garantálja, hogy ez a blazírt app nem nyúlja le az összes kontaktodat és nem tolja el egy csendes órában egy kínai szerverre?
Ez egészen addig csak elméleti probléma ameddig párezer tényleg hasznos és ismert alkalmazás van a disztró által felügyelt csomag archívumban. De ha tényleg az a cél, hogy ha nem is százmillió, de mondjuk párszázer hasznos és mókás app legyen egy Linuxhoz akkor ez egy nagyon durva probléma.

Az Ubuntu telefonban ezért csináltuk meg a .click rendszert és a Snappy az ennek egy továbbgondolt, jobban kidolgozott fejlesztése.

De az ördög a részletekben bújik meg. Nagyon sok minden múlik azon, hogy hogyan is lesz megvalósítva az egész. Az biztos, hogy maga az Ubuntu Core az marad a Debian downstream-je. Az is biztos, hogy a snappy fejlesztés nem arról szól, hogy az Ubuntu pik-pak kidobja a .deb infrastruktúrát, mert ez nonszensz hülyeség lenne. Pont ahogy az Ubuntu telefon is egy read-only rendszer amit image alapú frissítésekkel (és nem apt-get upgrade mint a Maemo/Meego) működik, de ezzel együtt egy bit átbillentése és ott van a teljes dpkg infrastruktúra. De az appok azok teljesen confined módon települnek és frissülnek .click formátumban. Lehet persze .deb csomagokat csinálni appokank, de minek, ha ott van a sokkal kényelmesebb megoldás.

Engem nyilvánvalóan felhasználóként fogott meg a deb csomagkezelés. Egy felüdülés volt a '90-es évek végén áttérni SUSE-ról Debian-ra és az internetről telepíteni csomagokat

apt-get install $foo

megoldással. Aki még emlékszik, az rpm alapú disztrók messze voltak akkor még ettől.

A dpkg és az apt kívülről megy. Minden hülyeségével és problémájával együtt. Nehezen válnék meg tőle.

De ha az új megoldás felhasználóként ugyanazt, vagy netán jobbat hoz, akkor nyilván semmi kifogásom nem lesz ellene.

--
trey @ gépház

Tökéletesen átérzem amit írsz. Nekem melóból volt HPUX swinstallos meg SunOS pkgadd küzdelmem is nem kevés :) Ezekhez és persze ahogy te is írod az rpm-es kínszenvedéshez képest a dpkg/apt/.deb rendszer olyan mint a friss tavaszi szellő.

Amit kiemelénk az az, hogy épp ideje különválasztani a platform fejlesztést és a core karbantartást a magsabb szintű alkalmazások világától.

Mondok egy példát... nagyon aktuális. Csinálom épp az Ubuntu SDK eszközöket... ez ugye a QtCreator nevű csoda. Tényleg jó cucc, csa ugye függ a komplett Qt rendszertől. Namost, ha én azt akarom, hogy ugyanaz az app bináris ugyanúgy és egyazon forrásból készítve menjen egy két tavaly ilyenkori Ubuntun és a soron következő development releasen is akkor meg vagyok lőve. Ugyanis az előbbin még 5.2 Qt van, az utóbbin meg legalább 5.5 Qt lesz. Nyilván csilliárd API/ABI változtatással. Szóval nincs más megoldás mint egy confined, statikus, minimális függőséggel rendelkező csomagot csinálni ami mindenhol egyformán működik. Bloat? Az. Redundáns? Az. Szép megoldás? Nem. Működik? _IGEN_ Van alternatíva? Tudtommal nincs... SZóval ennyike, szép volt jó volt a .deb, de a júzer appokhoz már nem vállalható.

Ezzel együtt én is szeretem a dpkg világot... a kezemre áll. De tudom, hogy ezzel pont így vannak azok akik a snappy-t fejelsztik.

> Szóval nincs más megoldás mint egy confined, statikus, minimális függőséggel rendelkező csomagot csinálni ami mindenhol egyformán működik.

Ha ezt így megcsinálják, akkor abban az esetben fogom azt mondani, hogy viszlát. Számomra kiöli az egyik nagy előnyét az egész csomagkezelésnek: nem kell hatezer programot újrafordítani/feltelepíteni, ha pl. javítanak egy OpenSSL-sérülékenységet. Ami nem ritka eset...

> Van alternatíva?

Persze. Nem kell változtatni az API-n ilyen gyorsan: nem kötelező pontosan az upstream-verziót követni...

" Számomra kiöli az egyik nagy előnyét az egész csomagkezelésnek: nem kell hatezer programot újrafordítani/feltelepíteni, ha pl. javítanak egy OpenSSL-sérülékenységet. Ami nem ritka eset..."

Nem tudom, hogy miből vetted le ezt. Erről nyilván szó sincs.

"Persze. Nem kell változtatni az API-n ilyen gyorsan: nem kötelező pontosan az upstream-verziót követni..."

Az API-t használó magasabb szintű csomag az API változtatás elszenvedője és nem felelőse.

Esetünkben arról van szó, hogy a Qt csomagokat és velük a Qt API-kat folyamatosan frissíti az Ubuntu az épp futó development release-ben. Ezzel nincs is semmi gond. Rendszerint a KDE-s Kubuntus srácok igényére történik ez. Viszont ez azt eredményezi, hogy az újabb Ubuntuk alatt Qt-tal fordított alkalmazások nem lesznek kompatibilisek már az egy évve korábbi stabil Ubuntu kiadással sem. Ez gáz... viszont egy snappy konstrukcióban ez simán megoldható.

Ez a lényege.

Az rebuild igényt onnan vette, hogy azt írtad: "nincs más megoldás mint egy confined, statikus, minimális függőséggel rendelkező csomagot csinálni ami mindenhol egyformán működik"

Azaz az alkalmazással le akarsz ragadni egy régi Qt verziónál. Megteheted: tedd be függőségként a régit. Annak ugyanis ez a módja, ha tetszik, ha nem. Az, hogy a lib/API változik, és a fejlesztő lusta ezt követni...

Ponthogy nem akarok leragadni, hanem haladni akarok.

Mondom... van egy alkalmazás, én vagyok a fejlesztője. Azt akarom, hogy az adott alkalmazás az LTS Ubuntu alatt is azt nyújtsa mint a vacsi friss 15.10 development release alatt. Namost ... a két rendszeren két különböző Qt van, két különböző API-val. Mik a lehetőségeim? Elmondom... csinálni egy statikus csomagot (nem statikus binárist mert azt az opensource Qt nem enged) és mindenki boldog.

Szóval, ez a nagy függőségi rendszer egészen addig frankó ameddig nem akarsz gyorsan és folyamatosan rilízelni.

Erre több megoldás is van.

Egyrészt ugye simán lehet azért az, hogy az openssl az része a platformnak és konkrétan ABI/API break nélkül lehet javítást tolni rá platform fixként. Ez a valószínűbb. A másik lehetőség pedig az, hogy igen... 152 fejlesztő azzal kezdi az egyik napját, hogy frissíti a cosmagját és tol egy új kiadást. Nem olyan nagy mágia.

A 152 gánypistike ne ezt csinálja, hanem a platformmal egyetemben menjen el a sunyiba. Gondolj csak bele, hogy 100-as nagyságrendű csomag több tucat magával hozott komponens mindegyiknél, amikre bármikor kijöhet biztonsági riasztás - aztán találd ki, hogy mi up-to-date meg mi nem, és ha nem,akkor mikor lesz az.
Nagyon nem mindegy, hogy 152 fejlesztőtől vagy egytől függ a frissítés.
Ha valami része a platformnak, és ezt már írtam talán, picit másképp, azaz van belőle külön csomag (lib...), és valaki mégis a sajátját csomagolja a motyója mellé, akkor most dupla vasalt bakancsos valagba rúgást kap, mert definíció szerint ezt nem szabad.
Amikor ezt megengedik, akkor a lusta/api/abi változásokat követni lusta fejlesztő mit fog csinálni: odalöki az összes sz@rt a programja mellé, amivel biztos, hogy megy, és részéről el van intézve. A felhasználó meg azt hiszo, hogy az openssl-nél maradva ha a rendszer részeként kapott openssl-t frissíti, akkor biztonságban van, miközben a futyikepistike átal odalökött mütyőke app meg a jó ég tudja, hogy mikor fogja a maga mellé lerakott libet frissíteni.

Figyusz, nem értelek. Legalább háromszor leírtam már, hogy vannak frameworök amikben az ilyen ilyen fontos kripto libek vannak. Emberfia sehol és soha nem mondta azt, hogy a snappy világban a kernelen kívül minden libet az appoknak kell majd maguk mellé tolni.

Azt meg miből gondolod, hogy a mostani .deb/.rpm világban az alkalmazásfejlesztők nem drótoznak be mindenféle esetleges biztonsági réstől lukas libeket az alkalmazásukhoz?

Megteheti, hogy hozza magával az alkalmazás az összes függőségét? Igen. Lusta kóder mit fog csinálni? Mellécsomagolja azt, amivel neki működik, ellenberger csak a saját kódját fogja javítani, ha épp olyan kedve lesz. Ha ezt 152 kóder megcsinálja, akkor lesz n+1 valamilyen verziójú lib a rendszerben, amik esetlegesen fognak frissülni. (Láttunk már ilyen rendszert, hogy az egyik app hozta a a foobar.dll egyik, a másik a másik, a huszadik meg a huszadik verzióját...).

+1.

Illetve javaslom BZoltan-nak (akit egyébként becsülök, csak itt ebben a témában nagyon nem értek vele egyet), hogy nézzen meg egy Xilinx ISE-t Linux alatt. Vonszolja magával az összes libjét (némelyiket több példányban is). Egy horror. Nagy, lassú, és még a rendszer normális működését is meg tudja zavarni az összeütköző libstdcxx-ekkel. Tud ez ide vezetni.

Nézd... már írtam, talán neked is, hogy nem tegnap óta debiánozok. 16 éve használom a dpkg rendszert, konkrétan két Debian downstream platform fejlesztésében vettem részt. pontosan tudom, hogy pusztán a .deb vagy .rpm cosmag struktúra _NEM_ garancia arra, hogy minden alkalmazás civilizált és szép legyen. Nem azok.

Valamiért azon megy itt a pörgés (szerintem tök feleslegesen), hogy jaj, a snappy koncepcióban nincsenek _OLYAN_ függőségek mint egy .deb vagy .rpm csomagban. _OLYAN_ nincs... de olvassátok el bátran a specifikációt. Minden snapp csomagnak van framework függősége, ahogy a most már kézzel fogható Ubuntu Phoneban élő .click csomagokban sincs klasszikus dependency, viszont van egy definiált framework aminek ott kell lennie.

Vagyis maga a platform az fix. Adott a platform API keret és a programozási nyelvek saját API rétegei. Ezek vannak... ezekből kell megoldania az appnak a feladatát. Ha írsz egy appot akkor nincs olyan, hogy jaj, nekem kéne még ez vagy az a lib. Ilyent nem csinálhatsz. A platform maga tartalmat több raklap API-t, ha ... és ez fontos _HA_ de tényleg _HA_ a platform API-k nem elegendőek _AKKOR_ és csakis akkor az alkalmazásoknak lehetőségük van maguk mellé rakni egy sajét fejlesztéső könyvtárat amivel hozzáférnek egy olyan erőforráshoz ami nincs ekszpózálva (de szép szó) egyik API-ban sem.

Ez így működik. Ezer oka van annak, hogy miért... a legfontosabb az az, hogy _NEM_ lehet tízmillió consume divájszt (értsd nagymama telcsije) a mai apt-get upgrade rendszerrel frissíteni, ha a rossebb sem tudja, hogy az n+1. fingó alkalmazás lehúzott tíz rosszul karbantartott libet. Egyszerűen az van (és ezt a Maemo-Meego-Ubuntu tapasztalattal mondom), hogy csak az imiage based tranziciós update rendszer működik. Vagyis kiflesselsz egy file system deltát a divájszra amin a root fs az bizony masszívan read only. Na egy ilyen rendszerbe nem fér bele az, hogy a appok random függőségeket húznak amik aztán vagy elbarmolódnak a következp upgrade alkalmával, vagy nem. Hangsúlyozom... itt most nem arról van szó, hogy pártízezer mérnök hogyan buherálja a pécéjét, hanem arról, hogy tízmilliók kapnak a pénzükért egy automatikusan frissítendő divájszt ami cirka 3 évig koppra garanciális.

"Lusta kóder mit fog csinálni? Mellécsomagolja azt, amivel neki működik, ellenberger csak a saját kódját fogja javítani"

Pontosan ugyanezt megteheti most is a .rpm és .deb csomagok világában is. Ha nem ütközik a .deb csomagban szállítot lib az ugyanazt a libet már szolgáltató rendszer csomaggal akkor a kutya nem fog egy rossz szót sem szólni rá.

Vagyis az amin te itt nagy erőkkel rugózól és ami kapcsán meglehetősen bántó stílust engedsz meg magadnak... na pontosan az létező probléma a mostani a rendszerekben is.

Magyarul vagy van a nagy egységes platform izé (amin belül a fene sem tudja, hogyan fognak ezek kezelődni, pedig ha kellően sok minden van a platformban, akkor kb ugyanott vagyunk, mint eddig)

Vagy a fenti "Számomra kiöli az egyik nagy előnyét az egész csomagkezelésnek: nem kell hatezer programot újrafordítani/feltelepíteni, ha pl. javítanak egy OpenSSL-sérülékenységet. Ami nem ritka eset..." mégiscsak helytálló. Az meg, hogy nem olyan nagy mágia, hátszóval. Egy baszogatandó helyett 152 baszogatandó lett, különböző hozzáállással és hozzáértéssel egy random berántandó miatt, a gyakorlat azt mutatja, hogy ez bizony igencsak mágia, imho az erősen jellemző beszűkült dev szemlélet...

Egyébként -- ez már a lejjebire -- miért kéne neked frisset releaselni mondjuk egy LTS verzióra. Többek között azért választ valaki ilyet, mert nem akar mindenféle összeszevissza frissülő programot. Aki akar, az nem használ ltst (igen tudom, hogy de, az keyboard chair interface error).

"Egy baszogatandó helyett 152 baszogatandó lett"

Az a baj, hogy sokan azt hiszik, hogy a disztrók azok cégek. Hát nem azok.... egy disztróban incs baszogatás meg seggberúgás (ahoz az zeller kartárts vizionálja minden hozzászólásában)

Az OpenSSL dolog egy kicsit légből kapott. Az egész modern app világban nincsenek ilyen típusú biztonsági rések az appok oldalán. Az appok olyanok amilyenek.. ha szarok akkor majd nem veszi meg őket senki. Ha automatikusan kimutatható, hogy veszélyesek akkor meg a store robotja kivágja a francba. Az appok nem részei a disztrónak. Az appok olyanok mint az áruház polcain az árúk. Az, hogy egy farmer szar az nem az áruház biztonsági emberének a kínja.

"Magyarul vagy van a nagy egységes platform izé (amin belül a fene sem tudja, hogyan fognak ezek kezelődni..."

Miért ne lehetne tudni???

" miért kéne neked frisset releaselni mondjuk egy LTS verzióra"

Mondjuk mert az egyik ügyfél ezt akarja? A másik pedig a devel release-re akarja. Ennyi. Ha biztosan backward compatible de haladó appot akarsz csinálni akkor a disztró infrastruktúra marhára nem működik.

Meredek vagy nem meredek... a fingó alkalmazásban ritkán van komplett webszerver és php szkript hegyek.

Érts kérlek jól amit írtam. Lehet persze troll stílusban direkt félreérteni :) De szerintem érted miről beszélek. Egyszerűen az andorid és ios világ megváltoztatta azt, ahogy az appokra tekintünk. Konkrétan például az izolált és a rendszerhez csak regisztrált API-ken át hozzáférő appok egészen mások mint az exploitolható és bufferoverflownak kitett szolgáltatások. Más sztori, más problémákkal.

És el kellene gondolkozni, hogy miért is nem. Miért is megy vicc számba az, hogy "YYYY a Linux deszktop éve lesz"? Miért is nem sikerült az elmúlt húsz évben egyetlen koszlott szoftver fejlesztőt rávenni arra, hogy elsődleges targetként tekintse az asztali linuxok világát?

Nézz körül... Látsz te olyan nyereséges vállalkozást szerte-e világon aki abból él, hogy alkalmazást fejleszt asztali Linux desktopra? Van néhány cég és civil egyesület akik elhivatottságból vagy szerelemből, esetleg jótékonykodásból pénzelnek fejlesztéseket, de pont a különféle disztrók közötti és a disztrókon belüli fregmentációk és API káosz miatt képtlenség gazdaságosan, kereskedelmi modellben Linux desktopra fejleszteni.

Egy stabil platformra egy vacak Angry Birdsért egy millió eurót kell lerakni az asztal sarkára...Komoly dolgokat nem fejleszt senki ingyér. Max a presztizs, hírnév, CV fényezés, PhD dolgozat az ami kontribúcióra késztet embereket. De ez töredék...Arról nem is beszélve, hogy amióta az Apple meg a Google berántották a mobil ipart ebbe a nagyonhülye app mániába azóta szóba sem áll veled egy hardver vendor ha nem tudsz konzisztens és fenntartható app fejlesztési modellt bemutatni. Mármint, hogy kereskedelmit, nem community alapút. Mert ezen utóbbit mi szeretjük és rajongunk értük, de sajnos appok százezreit a fejlesztők nagyrésze nem a kontribúció öröméért és nem a hírnévért csinál hanem némi aprópénz reményében. Ehhez pedig stabil platform, gyorsan pörgethető rilízek és egyszerű csomagolás kell. Na ez az amit a .deb/.rpm nem tud. Sajnos.

Annyit persze had tegyek hozzá, hogy én személy szerint a hajamat tépem, hogy miért nem inkább egy user space-be települő pofon egyszerű debian/control fájlal működő .deb rendszerrel lett inkább a mostani elsősorban platform komponens fejlesztésre kitalált deb/dpkg modell kiegészítve. Mert szerintem jobb lenne a tool-okat és a konvenciókat megtartani és azokat kiegészíteni. De sajnos ez a vonat már 4-5 éve elment.

Eldöntöd, hogy melyiket támogatod, és pont. Nem kell mindenkinek megfelelni. ha meg igen, akkor vállald föl a plusz munkát. A te elveddel ha jön egy üf. a.out -os történelmi OS-sel, akkor neki egy komplett virtualizációs motyót odaraksz, csak hogy a te lomodat tudja használni?

Fejlessz ezzel a hozzáállással Windows-ra. De fusson ám '95-XP-Vista-7-8-10... satöbbi verziókon is!

(fogok reagálni lentebb olvasottakra is szerintem, csak nem akarom nagyon szétrobbantani, szori)

Egyrészt, van hogy cég :) Másrészt meg szerintem ez a kérdés szempontjából nem mérvadó. A mérvadó az az, hogy egy helyen van a dolog, vagy sok helyen kell ugyanezt javítani. Főleg úgy, hogy míg az első esetben az egy helyet karbantartó valószínűleg képben van (igen, tudom, hogy nem mindig, épp az openssl meg a debian kontextusban ugye tudunk példát...), a 152 helyet esetében meg járulékos vacak, ami nem mozgatja a fejlesztőt. Nekem személy szerint nem szimpatikus az a világ, ahol ez utóbbi a jellemző, mert saját tapasztalataim azt mutatják, hogy 152ből 140 szarni fog rá, hogy normális ütemben reagáljon. És értem, hogy ezt mondjuk egy robottal lehet nézegetni, de nekem az szintén nem túl szimpatikus, hogy ahelyett, hogy elsőre rendesen csináljuk, inkább -- mert gyorsan akarunk releaselni -- inkább automatával takarítjuk a szart a storeból...

"Miért ne lehetne tudni???" -- helyesbítek. Mivel nem ismerem a snappyt részleteiben, ezért én nem tudom. Az alapján, ami itt kiderült róla -- nevezetesen hogy kvázistatikusra fordított konténerek, amiknél van valamiféle izoláció, meg tudnak függeni platform dolgokról -- ez kb alkalmatlan arra, hogy a platform belső függéseit kezelje, tehát oda kell valami. (Vagy ha alkalmas, akkor mégiscsak ott vagyunk, hogy kb a kernel után minden ilyen konténerekben van)

"Mondjuk mert az egyik ügyfél ezt akarja?" -- Az az ügyfél hülye :) Ami még nem baj, csak én spec. annak nem örülök, ha a hülye ügyfél miatt felforgatjuk a többieknek a terepet.

" Az egész modern app világban nincsenek ilyen típusú biztonsági rések az appok oldalán" -- lemaradtam valamiről, hirtelen megtalálta a programozó társadalom a szent grált, és 60 éve először tudnak sechole mentes szoftvert írni? Örülnék, de engedelmeddel, szerintem ez egyáltalán nincs így.
---

Értem én az ilyen zárt konténereket, meg azt az igényt is, hogy gyorsan lehessen kicsapni a mindenféle dolgokat, csak nem nagyon szeretem. Azért nem, mert egyrészről ebből a folyamatos friss release, meg autoupdate őrületből nekem egyre inkább az a kialakuló képem, hogy a kedves developer kommunának büdös rendesen karbantartani a vackait, meg elég ideig megőrizni a visszafele kompatibilitást, és mostanában valahogy úgy áll az élet, hogy ők tudják mindenki más torkán letolni ezt az izét. Includeing security, üzemeltetés, meg a felhasználók (akik jó részénél egyébként baromira nincs ám igény erre). Oldják meg ahogy akarják, ő szarik rá.

És azt is értem, hogy van, amire ez kb jó /bár engem felhasználóként is igen zavar, hogy az ökoszisztéma alapvetően úgy van kialakítva, hogy feláldozza a security jó részét a fejlesztői kényelem oltárán, de látni kell, hogy egy átlag felhasználó ezt nem látja/érti/érzi át... nem is kell neki, ez bizony a szakma felelőssége/, de megintcsak a tapasztalatom azt mutatja, ezek a dev urak fogalmatlansága/hozzáállása miatt legyűrűznek majd a fingós apptól a rendes szoftverekig. A disztribútor dolga meg majd reménytelen lesz, és lehetetlen lesz neki értelmesen összerakni egy normális disztrót, ami értelmesen sec updatelhető, nem töri keresztbe a programok funckionalitását félúton az app developere, hiába akarnék én LTSt használni, ennek olyan előnyeivel pl hogy egy lib egyszer van csomagolva :)

Hozzátenném még, hogy azért érzésre olyan libek, amikből nehéz többet rendesen csomagolni viszonylag ritkák, és kb a spektrum két végén helyezkednek el: vagy valami kis randombasz, amit tessék újraírni, vagy megfixálni, hogy lehessen belőle párhuzamosan több, vagy valamelyik böszme nagy behemót, mint pl a qt. Ebből egy normális szoftverháznak túl sok nem lehet, valószínűleg érdemesebb lenne értelmesen backportolni olyan régebbi disztrókra, amiket supportálni akar (azért ezek nem megugorhatatlan feladatok, a disztribútorok nagy váltások környékén mindig meg tudják ugrani akár egy komplett kde-vel is). És továbbra is azt gondolom, hogy ha olyat fejlesztessz, amihez feltétlenbaromira muszáj a qt legújabb verziója, akkor azt nem feltétlen kell kiadni az épp futó LTSre. Jó lesz majd a következőre, amibe bemászik a qt megfelelő verziója magától. Vagy legalábbis ne álljunk már be arra, hogy ezt LTS fölé is oda lehessen taknyolni jegyében ilyen izébe csomagoljuk, mert van egy hülye ügyfél, akinek ez mindenképp az LTS fölé kell. Fizesse meg ő az árát, hogy ilyet akar, ne a többiek, akik nem :)

Én többet nem ragálok erre a "152 helyen lesz a lib és ez gáz" felvetésre. Válaszoltám ere vagy tucatszor. Kérlek olvasd el valamelyiket.

"Mivel nem ismerem a snappyt részleteiben, ezért én nem tudom."

Ez nem igaz ->

https://developer.ubuntu.com/en/snappy/
http://www.ubuntu.com/things
https://developer.ubuntu.com/en/snappy/guides/

de ott van a teljes fejlesztő gárda a freenode #snappy csatornán. Az összes név akit látsz a snappy hírekkel kapcsolatban megkereshető és munkaköri leírásukban van, hogy válaszoljanak neked (én itt most szabadidős tevékenységet csinálok)

"Az az ügyfél hülye :) Ami még nem baj, csak én spec. annak nem örülök, ha a hülye ügyfél miatt felforgatjuk a többieknek a terepet."

Én nem hülyézném le azt az ügyfelet aki mondjuk a stabil kiadású platformhoz ragaszkodik. De azt a fejlesztőt sem aki már ma a jövő évi stabil kiadásra szeretne fejleszteni húszmilliárd fork nélkül :)

"lemaradtam valamiről, hirtelen megtalálta a programozó társadalom a szent grált, és 60 éve először tudnak sechole mentes szoftvert írni? "

Igen, vélhetőleg lemaradtál arról, hogy az android, ios és ubuntu phone alkalmazások csak user space-ben és csak a regisztrált API-khoz férnek hozzá. Erre próbáltam célozni. Sajnálom, hogy páran _direkt_ félreértik ezt. De mindegy, poénkodni nem rossz... de azért szerintem te is érted, hogy mire írtam ezt és miért.

"feláldozza a security jó részét a fejlesztői kényelem oltárán"

Milyen biztonsági kompromisszumot látsz ebben az izolált és konténeres megoldásban?

" A disztribútor dolga meg majd reménytelen lesz,"

Leírtam már máshol, hogy a disztribútor dolga már most is reménytelen. Toljál be tízezer appot a Debiánba.. majd szólj ha mindegyik megérkezett az Experimental repóba. Pár évtizedbe bele fog kerülni. Szóval.. ez az út addig járható ameddig nincsenek alkalmazások.

A libekről meg szerintem kár többet beszélni mint amit eddig beszéltünk. Nem a libek lényegesek itt.

Őszinte leszek veled, annyira nem érdekel a snappy, hogy ennek én részleteiben utánaolvassak, az általad felhozott érvekre reagáltam, gondolván, hogy te mind hozzáértő a szerinted a témában releváns érveket fogod felhozni.

Annak fényében mondjuk, hogy láthatólag nem vagy hajlandó meghallgatni a másik oldal gondolatait, és vagy lesöpröd azzal, hogy nem úgy van, vagy megpróbálod mindenki szájába adni, hogy direkt félreérti, meg eltúlozza, közben a gondolatmenet számodra kellemetlen részeit egyszerűen figyelmen kívül hagyod, szóval ennek fényében szerintem nem olyan nagy vétség részemről sem, hogy nem olvastam utána részleteiben.

Főleg, mikor olyanokat írsz le, hogy "Én nem hülyézném le azt az ügyfelet aki mondjuk a stabil kiadású platformhoz ragaszkodik" miközben láthatólag nem esik le, hogy a stabil platformhoz ragaszkodás egyik legfőbb oka általában, hogy ne tegyen fel minden jöttment app egy rakás a disztribútortól különbözően buildelt függőséget, amit meg te szeretnél az arcába nyomni a konténereddel.

Nézd, értem én, hogy érintettként fáj, amikor az ember dédelgetett kicsi gyerekét kritizálják, hidd el, nem bántani akarlak én téged, akár még azt is elhiszem neked, hogy a snappy alapvetően egy jó szoftver, de azért lásd be, itt valami kívülálló szemmel egy kicsit félrecsúszott a kommunikáción. Legalábbis nekem a cikkbeli deb megy, snappy jön, az azt jelenti, hogy nincs tovább deb. Vagyis a snappynak azt le kell váltani. És ha az ilyesmire vonatkozó kérdésekre egy fejlesztőtől azt látom, hogy elkeni, hogy ez csak a fingósappnak van, meg nem a libekről van szó, miközben az jön le, hogy direkt nem akarod érteni a felvetett problémákat, annak nincs jó optikája. Nem mintha eddig komoly esély lett volna rá, de egy egy ilyen megnyilvánulás után nálam bizony kap egy olyan strigulát, hogy ilyenbe pakolt izé alaposabb elemzés nélkül a közelébe nem megy semmi komolyabbnak, amihez közöm van.

"Őszinte leszek veled, annyira nem érdekel a snappy, hogy ennek én részleteiben utánaolvassak,"

Én is őszinte leszek veled. Ha nem érdekel a téma és nincs kedved utána olvasni, akkor nem sok értelme van beleszólni.

Úgy nehéz beszélgetni, hogy én igyekszem utánanézni a dolgoknak, felkészült és szakmai válaszokat adni ameddig te csak csuklóból leszólsz dolgokat :) Gondolom ebben egyetértünk.

"a stabil platformhoz ragaszkodás egyik legfőbb oka általában, hogy ne tegyen fel minden jöttment app egy rakás a disztribútortól különbözően buildelt függőséget, amit meg te szeretnél az arcába nyomni a konténereddel."

A stabil platforomon ezt a user space-ben most is simán megteheti bárki. A felhasználó a saját home-jába azt csinál amit akar.

"Úgy nehéz beszélgetni, hogy én igyekszem utánanézni a dolgoknak, felkészült és szakmai válaszokat adni ameddig te csak csuklóból leszólsz dolgokat :) Gondolom ebben egyetértünk." -- lehet valamit rosszul csináltam, de én úgy láttam, hogy én kérdezni próbáltam, a te felkészült szakmai válaszaid viszont kimerültek abban, hogy direkt nem akarom érteni, meg hogy olvassak utána, hogy hogy is van ez, mert te azon túl, hogy "stabil platformon továbbra is megteheti bárki" nem nagyon akarod két mondatban összefoglalni, hogy mi is ez a stabil platform pl, és hogyan van managelve, ha kihúzódik alóla a deb.

Már megbocsáss, de egy szakmai beszélgetésben ne legyen már leszólandó dolog az, hogy belinkelem a specifikációt meg a dokumentációt.

azon túl, hogy "stabil platformon továbbra is megteheti bárki" nem nagyon akarod két mondatban összefoglalni, hogy mi is ez a stabil platform pl, és hogyan van managelve, ha kihúzódik alóla a deb.

Mi az, hogy nem akarom összefoglalni??? Az Ubuntunak két stabil kiadása van, az LTS és az utolsó stabil kiadás a 15.04. Mindkét verzióban és az összes Redhat/Fedorba, Suse, Debian, stb disztróban is a $HOME az maga a vadnyugat ahova bármilyen alkalmazás és a júzer ma azt pakol és azt csinála legkisebb kontroll nélkül amit akar.

Jelenleg két út van... az, hogy a fingó alkalmazás telepítéséhez is root jogok kellenek és az alkalmazás megy a root fs-be a libc meg a kernel mellé egy space-be. Vagy megy a $HOME vadnyugatába.

Ezt a kihúzódik a .deb dolgot pedig hagyjuk. Nem húzódik ki semmilyen .deb Egyszerűen a .deb nem alkalmas a consumer grade alkalmazások terítésére, ehelyett van most a click és lesz a snappy. Az, hogy ez hogyan néz ki a mostani állapotba bárki megnézheti egy ubuntu phone emulátorban.

Telepíted az Ubuntu SDK-t -> https://developer.ubuntu.com/en/ és felraksz egy 14.09-es devel-proposed emulátort. Elindítod és 'adb shell' paranccsal bemész körülnézni. ott fogod látni, hogy mit jelent ez a migráció. Meg fogsz döbbeni... ott van a dpkg meg az apt is, meg egy raklap .deb csomag... de az appok azok a click formátumban vannak és ez így jó, biztonságos és kényelmes.

Nem leszólandó, csak ha te nem vagy hajlandó infót megosztani, akkor nem fogunk róla beszélgetni (egyébként ha kicsit olvastad is, mit írok, akkor azért feltűnhetett volna, hogy utána-utána olvasok forrásoknak, de szorri, az ircen nem fogok tornázni, hogy magyarázza már el valaki.)

Érdekes, most azért hajlandó voltál modani róla valamit. Azért idézném a cikkben linkelt bejelentést: "and so the current .deb based Desktop Next image will be going away and will be replaced with the new Snappy version." -- ebből szerinted honnan kellett volna kikövetkeztetni, hogy mégiscsak ott van a dpgk meg az apt?

(Egyébként csak így csípőből harmadik útnak pl ott az selinux meg az apparmor (ha jól emlékszem az ubuntu azt tolja) ;))

"ha te nem vagy hajlandó infót megosztani, akkor "

Már megbocsáss, de itt én voltam az aki neked linkeket adott a dokumentációhoz és a specifikációkhoz. Miből jön le neked az, hogy nem osztok meg információt???

ebből szerinted honnan kellett volna kikövetkeztetni, hogy mégiscsak ott van a dpgk meg az apt?

Mondjuk onnan, hogy megnézed az Ubuntu phone megvalósítását és onnan, hogy utána nézel a dolgoknak ahelyett, hogy zérus tájkozódással csuklóból ítélkezel olyan technológia felett amit nem ismersz.

Olvassd el ezt - http://www.itworld.com/article/2914850/linux/is-ubuntu-moving-away-from…

Idézek: "Ubuntu is not moving away from Debian. They are still using Debian to build images of Ubuntu using packages from the archives. What they are doing is moving the desktop to Snappy-based images and applications."

Oké, csak akad egy olyan tévképzet, hogy te majd meggyőződ őket ennek a hasznosságáról. Holott szerintem egyrészt nem a te feladatod, valószínűleg nem is rendelkezel minden információval (nem te készíted), de ők még annyival sem, mert a publikusan elérhető információknak sem mennek utána.

Persze a te dolgod, hogy milyen vitákba mész bele, de véleményem szerint nagyon időrabló lehet és egy szinten túl felesleges is.

-----
„Egy jó kapcsolatban a társunkat az ő dolgában kell támogatni, nem a miénkben.”
rand() a lelke mindennek! :)
Szerinted…

ó, nincsenek olyan ambícióim, hogy bárki meggyőzök :)

Amúgy mondom, ennyi közszolgálatiság belefér. Konkrétan pedig én a snappy framework-ök definícióján dolgozom épp, szóval eléggé képben vagyok azt illetőleg, hogy mik a nehézségek.

Így nekem tulajdonképpen hasznos is előre tudni, hogy milyen értetlenkedésekre kell előre felkészülni.

Amúgy az tök valid kritika, hogy lehetne több ".* for dummies" jellegű doksit írni. Csak hát az is meló meg idő...

Féreérted. Az, hogy mutogatsz, hogy van doksi, meg tedd fel, meg tedd fel a kérdésed, abból nem nagyon lesz beszélgetés. Csak akkor ne csodálkozz, hogy az emberek félreértik.

Akkor pláne ne, ha a linkelt (ergo gondolom "hivatalos") leírt mondat cáfolata az, hogy van itt egy itwordos cikk, meg fel is tehetted volna megnézni, hogy nem úgy van, mint a linken. Miközben az ubuntu.comról pl. nem derül ki, hogy mi az a desktop next. Se egy menü valahol, se semmi a keresőben azon túl, hogy hosszú listák alatt van next>> link :) Szóval azért a zérus tájékozódástól messze voltam.

Nézd nekem mindegy. Azt, hogy mit jelent a Desktop Next azt konkrétan az ubuntu.com-rólmegtudhatod:

https://wiki.ubuntu.com/Unity8Desktop
https://wiki.ubuntu.com/Unity8DesktopIso
http://cdimage.ubuntu.com/ubuntu-desktop-next/daily-live/current/
http://people.ubuntu.com/~mhall119/Unity-8-Desktop.html

De persze ami mindent visz az ez... Tudom döbbenet, 2015-ben erre a szolgáltatásra hivatkozni: http://bit.ly/1Jxav6j

De ha nem akarsz olvasni az sem baj, én már vagy tucatszor leírtam itt is, hogy a.deb csomagok és a dpkg/apt nem lesz bedarálva. A core és a framework-öket továbbra is a Debianra alapozza az Ubuntu és a Debian jól megszokott és jól működő platform fejlesztése marad úgy ahogy van. A Desktop vonal megy a snappy-re ami leginkább a user space-be települő és user space-ben futó alkalmazásokat is jelenti. Sőt azt is mondtam már többször is, hogy a framework-ök hivatottak megelőzni azt, hogy 152 app pakolja maga alá be ugyanannak a libnek a 152 változatát.

Szóval minden információt megkaptál, minden területen választ kaphattál a kérdésedre.

szerinted nem volt meg a let meg google this for me? :)

Egyébként ha te ilyen érzékeny voltál lentebb a stílusra, akkor most vegyél kézbe egy tükröt. Mellesleg a hamramdik linkedre visz, neked ebből kiderül mi ez, azon kívül, hogy az eddigi desktop iso? Egyébként a többiből is az egyetlen olyan, ahol ez kb le van írva, az az utolsó, (a többiben lófasz info nincs), bár azért ott sem sok. Ráadásul people/~valaki? hátizé, azért erre mutogatni, hogy miért nem találom meg :)

Na jó, de most akkor vagy minden megy frameworkbe ami duplikálós (ami mint kiderült marad a deb, -- amiben állítólag nem lehet ezt jól kezelni :)) és tulajdonképp az lesz, hogy az ubuntu majd mégicsak becsomagolja a különböző verzióit egy egy frameworknek, mint pl a qtnek? vagy az, hogy mégiscsak lesz kódduplikáció ahol a 152es probléma előjön :)

Nézd, amikor huszadjára kell neked elmagyaráznom ugyanazt a pofonegyszerű dolgot akkor engedtessék már meg nekem némi irónia :)

"ami mint kiderült marad a deb, -- amiben állítólag nem lehet ezt jól kezelni "

Ilyent senki, sehol nem mondott. Te most úgy csinálsz mintha nem arról szólna az egész történek, hogy az appok mások mint a libek.

ill ez tegnap kimaradt, uh majd most:

"Milyen biztonsági kompromisszumot látsz ebben az izolált és konténeres megoldásban?"

1) Az appban levő adatokét? Gondolom megvan az az (egyébként túlegyszerűsítő) xkcd, hogy ugyan egy maleware az összes banki adatomat, emilemet, doksiaimat viheti, de legalább drivert nem telepíthet a gépemre. Na, ez kb ugyanaz pepitában. Ha valamelyik behúzott komponens szar, akkor az abban levő adatok bajban vannak. Ha 152 helyen szar, akkor 152 helyen külön kezelendő a probléma :) Megspékelve mindezt az általad is bemutatott, de egyáltalán nem egyedi "hát ma már töksecure, mert konténerben van" mondással, ami bizony előrevetíti, hogy a kedves urak jó része fosni fog a rendes patchelésre.
2) Ha szerinted az, hogy egy cve után az appstore robotjával kell turkálni, hogy megpróbáljuk kitalálni, mi sebezhető, nem security probléma, illetve visszalépés, akkor őszintén szólva nem nagyon tudom, hogyan magyarázzam el.

1)
">>lemaradtam valamiről, hirtelen megtalálta a programozó társadalom a szent grált, és 60 éve először tudnak sechole mentes szoftvert írni? <<

Igen, vélhetőleg lemaradtál arról, hogy az android, ios és ubuntu phone alkalmazások csak user space-ben és csak a regisztrált API-khoz férnek hozzá. Erre próbáltam célozni. Sajnálom, hogy páran _direkt_ félreértik ezt. De mindegy, poénkodni nem rossz... de azért szerintem te is érted, hogy mire írtam ezt és miért.

>>feláldozza a security jó részét a fejlesztői kényelem oltárán<<

Milyen biztonsági kompromisszumot látsz ebben az izolált és konténeres megoldásban?"

Magyarul szerinted ha a rendszer meg van védve, szerinted biztonságos, mert hát már csak regisztrált APIt ér el, és én vagyok lemaradva, nem te nem érted... Aha.

2) Hát, ha szerinted az a modell, hogy automatával kell keresgéljük hogy hol maradt még valami vulnerable a 152x duplikált kódból okosság, meg pláne jobb, mintha egy helyen lenne kezelve, akkor valamelyikünk nagyon nem érti a securityt.

"szerinted ha a rendszer meg van védve, szerinted biztonságos, mert hát már csak regisztrált APIt ér el, és én vagyok lemaradva, nem te nem érted... Aha."

1) Igen, a _RENDSZER_ ezáltal meg van védve, mert az app nem fér hozzá a _RENDSZERHEZ_

2) Valóban az jön le a hozzászólásaidból, hogy te nem érted a rendszerbiztonság lényegét. Ezt a könyvtárduplikációs dolgot már tucatszor elmagyaráztam. Nem fogom pusztán azért újra elmagyarázni mert neked nincs kedved elolvasni az amit írtam.

Ha akarod akkor ismét leírom, hogy mind a user space-be pakolt és ott kalózkodó appok ahogy a rootként rootfs-be települő appok is már eddig is biztonsági rést jelentettek a _RENDSZERE_ nézve minden disztóban.

Vagyis az appok konténerben izolálásával és a jogosultságaik kontroll alatt tartásával ezt a biztonsági rést bezárjuk. Az appok _SAJÁT_ adatai az appoké...ha egy app azt mondja, hogy ő most random számokat fog egy fájlba írni és azt időnként elküldi kínába akkor az _NEM_ biztonsági hiba ha ezt meg is teszi. Ahogy az sem biztonsági hiba, ha egy szar app szarul végzi azt amit a fogyasztónak megígért. Ez funkcionális probléma és nem biztonsági.

Remélem így már érthető, hogy miért irtam azt amit te mindenáron igyekszek kiforgatni és félreérteni. Persze, lehezt, hogy te jobban tudod nálam, hogy én mit írok... csak nem valószzínű.

Ezt én értem, eddig is értettem (más kérdés, hogy nem feltétlen ezt tartom a jó iránynak). Nem akarom félreérteni, te nem nagyon akarod megérteni, hogy én nem erről az oldaláról beszélek. Kérlek terjeszd ki az elemzésed tárgyát az appra is. Ugyanis nekem, mint végfelhasználónak az is fontos. Te ugye azt mondod, hogy az app belső dolga minden egyes app dolga, részetekről el van engedve. Namost ez a gyakorlatban azt jelenti, hogy a kódduplikált cuccokban levő sebezhezőséget is mindenki oldja meg maga. És ez azzal, hogy abba az irányba nyomjuk a cuccot, hogy legyen kódduplikáció, sokkal gyakoribb lesz, mint eddig, hiszen ugye a banális openssl példánál maradva innen 152 appnál kell lekövetnem, hogy kész van-e már, mert a disztribútor közölte, hogy ezt ő leszarja. Nekem mint felhasználónak ez baj.

"a kódduplikált cuccokban levő sebezhezőséget"

Tehát... n+1. alkalommal leírom, hogy a user space-be települő és a user space-ben izolált konténerben futó, kizárólag regisztrált API-khoz hozzáférő alkalmazásokkal együtt csomagolt akármilyen lyukas és bugos lib sem jelent semmilyen biztonsági kockázatot a _RENDSZERRE_

Érted??? Hiába van egy fingó app mellé csomagolva egy lyukas kripto lib, ha a lyukat kihasználva sem lehet semmi máshoz hozzáférni mint a fingások wav fájlaihoz. Értsd meg, hogy _NEM_ ugyanaz a biztonsági kockázata egy izolált libnek mint egy system szintem létezőnek amit _MINDEN_ akár root jogú szolgáltatás is használ.

Mesélj, milyen kompromisszumnak vannak a wav fájlok kitéve. Az appnak nincsen net hozzáférése.

Az app letörli a saját wav fájljait? Miért baj ez? Kit érdekel.. az app adta az app elvette. Ha fizettél érte akkor kérd vissza a pénzed. Kretén lés szarul működő appok milliói vannak GooglePlay és az Apple storeban. Kutyát nem érdekli.

Mellesleg ha ez probléma akkor ez ma is probléma... ha egy .deb alkalmazás a $HOME-ba pakol adatot akkor azt az alkalmazás le is törölheti. Duplaplusz ponként ugyanezt megteheti _MINDEN_ más alkalmazás is... ellentétben az izolált világban ahol egy alkalmazás saját adataihoz más alkalmazás nem fér hozzá.

Érted már?

Fussunk neki nyolcvanhetedjére...

Tehát, az izolált és konténerben futó appok bármilyen sebezhetősége nem jelent minimális kockázatot sem a rendszerre nézve. Ez megvan?

Az, hogy az app egy kalap szar és le tudja saját magának törölni a saját média fájljait (mert kívülröl ez külön engedély nélkül nem lehetséges) az a kutyát sem érdekli. Ez app quality kérdés és nem biztonsági.

Akkor fussunk neki 88adjára: nem a rendszer sebezhetőségéről beszélek már nem tudom mióta (kb ennek a subthreadnek az eleje óta). Igen, tiszta sor, hogy ott jó az izoláció, nem véletlen megy évekóta mindenféle projekt ami az ilyesmit célozza, cgroups (és annak systemd integrációja pl), apparmor, selinux, a kiscsillió féle lightweight virtualizációs konténer. Ezt nem vitattam, le is írtam vagy 5x, hogy értem, csak valamiért nem vagy hajlandó észrevenni. Értem. Igen, az izoláció security szempontból jó. az rwxrwxrwx modell gyenge. Értem. Léphetünk?

Amit én mondok, hogy ha mégis maradt valami sebezhetőség az izolációs konténerben, amit kihasználva kompromittálhatóak az adatok, az ellen ez nem véd az izoláció. Nyilván, ha ez az app saját kódja, akkor valóban kőmindegy, ha viszont valami, ami most az új rendszerben mellékerült statikusan, míg korábban a disztróval jött csomagra dependált, akkor ennek a frissítési lehetősége szarabb. És ez biztonsági kérdés. (Hint: minden biztonsági kérdés quality kérdés)

Az meg, hogy már megint egy olyan framework, amin keresztül nem lehet majd távolról hibát kihasználni, mert ő megvéd ellene, azt te is tudod, hogy nem így van. Egyszerűen csak annak a komponensnek kell sebezhetőnek lenni, amit keresztülenged magán a framework (igen csodálkoznék, ha lenne arra erőforrásotok, hogy az átmenő kommunikációt részleteiben elemezzétek, mondjuk protokollonként, mert az egy kicsit nagyobb meló, mint debbe csomagoni a világot :) )

"Értem, hogy gőzmozdony, de mi hatja" :D

Klasszik...

Értsd meg kérlek, vagy ha ez nem megy akkor egyszerűen fogadd el, hogy egy izolált és konténerben lakó, ott futó alkalmazásra kívülről semmilyen veszély nem fenyeget és ő sem jelenthet semmilyen rajta kívüli alkalmazást vagy rendszert. A sajtát homokozójéban rugdoshatja a saját homokvárát, de ez meg a kutyát sem érdekli.

Milyen szintű az izoláció? Képes-e a futtató rendszer kernelében lévő sérülékenységet kihasználni? lehetséges-e, hogy az izolált környezetben lévő komponens hibája az adott szolgáltatás elérhetetlenségéhez vezethet? Az izolált környezetben lévő, az alkalmazás hálózati forgalmának biztonságára kiható sérülékenységével mi a helyzet? A sérülékeny komponensen keresztül az adott alkalmazás által kezelt adatok elérhetősége támadható-e?

A saját homokozóban lévő homokvárat sem rugdoshatja tetszőlegesen, mert az adatok integritása, rendelkezésre állása és megbízhatósága _sem_ sérülhet. Ezt meg jelen esetben minden egyes app magával hozott függőségénél egyedileg kell frissítéssel biztosítani.

"Képes-e a futtató rendszer kernelében lévő sérülékenységet kihasználni?"

Nem, nem képes.

"lehetséges-e, hogy az izolált környezetben lévő komponens hibája az adott szolgáltatás elérhetetlenségéhez vezethet?"

Igen,lehetséges, de ez nem biztonsági hanem minőségi kérdés.

"Az izolált környezetben lévő, az alkalmazás hálózati forgalmának biztonságára kiható sérülékenységével mi a helyzet?"

Izolál környezetben az alkalmazásnak nincsen hálózati hozzáférése a felhasználó tudta nélkül. Ha a felhasználó erre explicite engedélyt ad úgy a hálózati kapcsolaton keresztül kívülről _NEM_ lehet sem a rendszert sem más alkalmazást kompromittálni. Az alkalmazás saját trehányságából fakadó saját adatainak veszélyeztetése az minőségi kérdés és nem biztonsági. Ezt már ezerszer elmagyaráztam neked.

"A sérülékeny komponensen keresztül az adott alkalmazás által kezelt adatok elérhetősége támadható-e?"

A támadhatóságot azért a rendszer ellenőrzi. Szóval egy app nem indíthat szervert csak úgy és nem fogadhat bejövő kapcsolatot. Azért a platformnak is vannak védelmi vonalai.

"A saját homokozóban lévő homokvárat sem rugdoshatja tetszőlegesen,"

de igen. Értsd meg, ha pedig nem megy akkor fogadd el, hogy definíció szerint az alkalmazások saját adatai az adott alkalmazások hatáskörében vannak. Pont. Ezen kár rugózni.

"Ezt meg jelen esetben minden egyes app magával hozott függőségénél egyedileg kell frissítéssel biztosítani."

nem kell... de lehet. Ha nem teszi és emiatt az alkalmazás nem látja el a feladatát akkor a felhasználó eltávolítja az alkalmazást és ennyi... naponta appok millióit törlik mobil eszközökről azért mert szarok... ez nem a platform kínja.

A szolgáltatás elérhetetlensége nem "minőségi" hanem rendelkezésre állási, azaz biztonsági kérdés.

A hálózati forgalom kifelé is lehet sérülékeny, például azért, mert lukas a titkosításért felelős komponens, aminek következtében kompromittálódhatnak a továbbított adatok.

Az adatok illetéktelen kézbe kerülése, illetéktelen módosítása és a rendelkezésre állásának ellehetetlenítése mind-mind biztonsági kérdés. Ezeket te "minőségi" kérdésnek titulálod. Az adat nem az alkalmazásé, hanem a felhasználóé. Az nem minőségi, hanem biztonsági kérdés, hogy a felhasználó adataihoz csak az férjen hozzá, akinek kell, illetéktelen módosítás ne történjen, illetve amikor szükséges, akkor elérhetőek legyenek.

Nagyon-nagyon nincs fogalmad arról, hogy mit jelent az adatok biztonsága - és az gond, hogy ha ilyen hozzáállás/tudáshiány jellemző a fejlesztők körében.

"A szolgáltatás elérhetetlensége nem "minőségi" hanem rendelkezésre állási, azaz biztonsági kérdés."

A fészkes fenéket. Amennyiben nem egy rendszer szolgáltatásról hanem egy alkalmazás által _IGÉRT_ opcionlis és a disztribúció által nem támogatott szolgáltatásról van szó úgy _NEM_

"lukas a titkosításért felelős komponens, aminek következtében kompromittálódhatnak a továbbított adatok."

Ez pedig a vonal másik oldalán levő szolgáltatás és az alkalmazás kínja. Az ő adatuk van a kapcsolatban, azt csinálnak vele amit akarnak. Ha te felraksz egy appot ami kriptálatlanul tol a netre olyan tartalmat ami az alkalmazás alatt található az is az app dolga.

Te totálisan félreérted az izolált appok és a core rendszer felelősségi és feladat körét.

"Az adat nem az alkalmazásé, hanem a felhasználóé. "

Aki az alkalmazás telepítésével ezeket az adatokat az alkalmazásra bízza. Ha te felraksz egy appot ami networköt és hozzáférést a kontakjaidhoz kér akkor az nem biztonsági hiba az az az app eltolja a kontakt listádat kínába, hanem egy fícsör amit te akartál. Ha hülye a felhasználó az az ő baja. A rendszer biztonsági szolgáltatsának a rendszert kell megvédeni az appoktól és az appokat kell megvédenie a többi apptól.

"Nagyon-nagyon nincs fogalmad arról, hogy mit jelent az adatok biztonsága "

Ha már személyeskedünk akkor szerintem te nagyon nem vagy ebben a témakörben kompetens. Nem értesz hozzá és nem tudod miről beszél.

"Ez pedig a vonal másik oldalán levő szolgáltatás és az alkalmazás kínja" - LOL. Van egy p2p alkalmazás, amit felrakok két eszközre, és azok tudnak egymással beszélgetni. Akkor a vonal melyik végén telepített app baja, ha lukas a titkosítás? Mi van egy SSLv2-t _is_ támogató webszerver meg egy csak SSLv2-t beszélő böngésző közötti kapcsolat esetén ki is a hülye? A szerver, ami tudna biztonságosabb csatornát kezelni, vagy a likas app, ami meg nem. Nos?

Az valóban nem az adott komponens sérülékenységére visszavezethető biztonsági hiba, hogy nem csak oda tolja az app szándékosan(!) az adatokat, ahova kell, viszont az, hogy az adatok normál továbbítása/kezelése esetén valamely komponensének a hibája miatt olyan is hozzáférhet a továbbított adatokhoz, akinek nem kéne, az bizony bazi nagy biztonsági hiba, méghozzá az adatok bizalmasságára vonatkozóan.

Te egy alkalmazás és az azt elvileg kordában tartó elméletileg jól működő izoláción nem látsz túl.

"Mi van egy SSLv2-t _is_ támogató webszerver meg egy csak SSLv2-t beszélő böngésző közötti kapcsolat esetén ki is a hülye?"

Ez jó kérdés. Szerintem az igazán okos szerverek egyszerűen letiltják a POODLE sebezhetőségnek kitet protokolt és így az összes olyan trehány app amely nem reagált a problémára egyszerűen nem fog működni. Vagyis hülye a szerver ha enged hülye appokat kalózkodni. Nekem az elmúlt időben több kliensemet kellett frissítenem, átállítanom, mert IRC és más szerverek egyszerűen átálltak a TLSv1-re.

De ismétlem... ez a sebezhetőség az app és a szerver dolga. Ha mondjukegy IRC kliensben SSLv3 protokol van és az IRC szerver ezt el is tűri akkor _KIZÁRÜLAG_ az IRC protokolon folyó tartalmat kompromittálja... ettől még maga a rendszer sem más alkalmazás adatai nem lesznek kockáztatva. Vagyis bármilyen probléma is van az appokkal az a probléma karanténben lesz az izolációs modell miatt.

Ez a poénja az egész snappy/click arkitektúrának, amit te már ezer hozzászólás óta nem akarsz megérteni.

Ezzel együtt már túl sokszor írtam le neked, hogy az ilyen kripto libek nyilvánvaló módon a platform részei és mint ilyenek a disztró firssítési ciklusában vannak karban tartva. De ezzel együtt... igen, már most is maga mellé csomagolhatja bármelyik IRC kliens a saját kripto libjét annyi lyukkal amennyivel csak akarja. Ez a lehetőség és az általad ezerrel mantrázott probléma _MOST_ is létezik... _SŐT_ _SŐT_ ha egy balfék IRC kliens ilyent tenne ma azzal bizony kompromitálná a teljes user space-t is.

Ez megvan? Fogod ezt? Érted? Mert legalább tizedjére magyarázom neked el...ha még mindig nem esik le, akkor innen nincs tovább. Ha most megérted akkor minden frankó...

Akkor pontosítom a kérdést... Van két izolált appod, mindkettő csak sslv2-t beszél, és ezeknek beszélgetniük kell egymással. Akkor most ki a hülye? Ja, hogy az OS, mert engedi az SSLv2-t... Éééértem...

Attól, hogy karanténban lesz probléma, sérül-e az adatok integritása, bizalmassága, vagy az elérhetősége?

Ilyen jellegű hibát _nem_ csak crypto libek okozhatnak, láttunk már sima inputot sz@rul feldolgozni úgy, hogy disznóságot lehetett vele csinálni.

Normális rendszerben például a crypto libet az OS adja _mindenkinek_ és per definitem nem kerülhet bele a repóba olyan app, ami ezt nem tartja be. Ahol beengednek "stabil" rendszerbe bármilyen libből bármilyen verziót, az nem stabil, hanem testing rendszer, nevezzék bárhogy.

Tudod azt hiszem te nem érted.
Úgy tudnám megmagyarázni a példát, hogy:
Nem mindegy, hogy azért nem indul a villamos, mert
- snappy - öreg nénikének gondot okoz a felszállás
- .deb - elektromos hiba miatt nem működik az ajtó.

Azt gondolom már régóta, hogy a linuxos csomagkezelés egyszerre áldás és átok.
Egyrészt nagyon jó, hogy egységesen lehet kezelni a programok telepítését, frissítését. De a többi az kb. hátrány.
- nincs egységes csomagformátum
- a disztribúció készítői tudnak csak hivatalos csomagot csinálni - ami benne van-a repoban. Ezzel kb. kizártuk a zárt forráskódú programokat.
- frissítési kényszer
- nincs átmenet két különböző disztribúció, vagy akár azonos disztribúció különböző verziói között. Pedig jó lenne.
Elrettentő példaként:
https://www.virtualbox.org/wiki/Linux_Downloads
Ez lehet minden fejlesztő rémálma. Minden disztribúció minden támogatott verziójára a fejlesztőnek kell elkészíteni a csomagot, tesztelni, közreadni stb!!! És mégsem elég!!! Mi a helyzet a többi disztribúcióval, meg a többi verzióval?
Szóval ne mondd, hogy a mostani csomagkezelés tökéletes, mert nagyon nem az. Igenis van igény rendszertől független csomagra legalábbis nekem van, mert az /opt-tal bohóckodni, meg forrásból fordítani ennél, lehet hogy izgalmasabb, csak nem jobb.

Akkor miről is? Mert a téma az, hogy a Ubuntu egy másik csomagformátumot vezet be külső fejlesztőknek, ami nagyobb szabadságot és kompatibilitást biztosít, cserébe izoláltan fut. Ennek az előnyeivel, hátrányaival.
Az egyértelmű, hogy a .deb féle csomagkezelés nem erre való. Akkor mi a problémád?

Nemnem... _TE_ beszélsz egy nem létező problémáról, pedig már huszonezerszer elmagyaráztam én is és más, hogy az általad punpált butaság _NEM_ létezik.

Hülyeséget beszéltél... máér megbocsáss. Azon rugózól, hogy szerinted egy izolált, konténerben lakó app mellé csomagolt bugláda szerinted képvisel bármilyen kockázatot. Pedig ezerszer elmagyaráztam neked, hogy _NEM_ nem képvisel. A saját szarit baromolhatja szét a szar app a szar libjeivel...de ez nem biztonsági hanem minőségi kérdés. Semmilyen valódi kockázatot nem hordoz az, hogy most lesz egy olyan csomagolási technológia amit _EDDIG_ is lehetett csinálni.

Ez az amit te nem akarsz megérteni.

A kiindulási xkcd-s példád hibás: az alkalmazás izoláció nem csak az alaprendszert védi az alkalmazásoktól, hanem az alkalmazásokat is egymástól. Azaz pont egy ilyen környezetben egy malware nem fog hozzáférni az összes banki adatodhoz, hacsak nem azon az appon keresztül kaptad be, amin keresztül bankolsz is.

még mindig arról van szó, hogy az eddig dependenciaként jövő, most odaduplikált kódban levő security javítás hogy jut el az összes apphoz. Pl a bankolós appomhoz, hogy onnan ne tudják kilopni a banki adataimat. Meg a chatelős appomhoz, hogy onnan meg ne tudják kilopni a csetem tartalmát, meg a böngésző appomhoz, hogy ne tudjanak beletaknyolni a https forgalmaba.

Mert ugye feljebb az volt a mondás, hogy ez le van szarva, mert az appok biztonságosak, mert izolálva vannak, nem kell nekik központi függőségfrissítés. idézném "egész modern app világban nincsenek ilyen típusú biztonsági rések az appok oldalán"

Tehát.. fussunk neki mégyegyszer.

Egyrészt a kripto libek azért erősen az a kategória ami a platform vagy legalábbis egy security framework része. Ha egy alkalmazás fejlesztője mégis úgy dönt, hogy ő inkább a saját forkját akarja használni akkor azt már _MOST_ is megteheti.

Ez megvan? De komolyan.. ne is olvass tovább ha ezt nem érted. Szóval fogod, hogy ma, bármelyik disztróban, bármelyik alkalmazásnak joga és lehetsőge van elforkolni egy libet és a saját modulként saját maga alá telepíteni azt? Fontos, hogy ezt megérts, mert ha ezt nem érted akkor továbbra is olyan dolgot kérsz számon egy új technológián ami a mostani technológiában _SEM_ létezik.

Igen, ha a fejlesztő saját maga akar egy libet csomagolni akkor az ő feladata és felelőssége azt a libet karban tartani és azt szinkronizálni az upstream kiadással. De természetesen ez nem egy kötelező dolog, mert ahogy már tucatszor írtam, az alapvető rendszer könyvtárak és framework-ök továbbra is állnak az alkalmazások rendelkezésére. Nincs szó arról, hogy akkor most az Ubuntu bedarálja a rendszer libeket és mindenki mehet a git repókba és fordítgathat magának. Te valamiért ilyen disztró apokalipszist vizionálsz én meg lassan már kezdem unni, hogy nyolcvanharmadik alkalommal is elmagyarázom, hogy nem erről van szó.

Igen, bakker értem. meg azt is értem, hogy ellenben azzal, amit te itt kommunikálsz, hogy izolált, húzza be magának és tartsa meg magának cuccot az új irány a diszrók eddig policy szinten nem így csinálták, és pontosan az volt, hogy igyekeztek ezt csak nyomós esetekben hagyni, a többieknek meg megmutatni, hogy ott a függőség.

Nem apokalipszist vízionálok, hanem lassú rothadást, mert az a tapasztalatom a fejlesztéssel, hogy nagy százalékban a lefordult, megy, releaseltük, leszarom van, ha erre megkapja a lehetőséget :)

"húzza be magának és tartsa meg magának cuccot az új irány"

Nem, erről természetesen szó sincs.

az a tapasztalatom a fejlesztéssel, hogy nagy százalékban a lefordult, megy, releaseltük, leszarom van, ha erre megkapja a lehetőséget :)

A mostani rendszerben sem más a helyzet. Pusztán a .deb csomagolás semmilyen minőséget nem garantál. Azt pedig több helyen leírtam, hogy egyik disztrónak sicns kapacitása többszázezer appot minőségi alapon átnéznie. Vagyis azt képzelni,hogy a mai disztró modellben lehet appok tízezreit karban tartani az ostobaság.

Próbálok insightful lenni. A bajaim ezekből összefoglalva a következők, amennyire értem a koncepciót:

1.) Lesz egy framework, de:
- Ki fogja rávenni az alkalmazásírókat, hogy azt használják: tipikusan a nagyobb upstream csapatokra gondolok (GIMP, Eclipse, akármi).
- (Megjegyzés: már most sem tudod rávenni az alkalmazások fejlesztőit, hogy ne használjanak GTK-t, amikor az egész rendszer inkább Qt-re épül)

2.) Mi lesz a most létező több tízezer alkalmazással, amelyek még nem használják ezeket?
- Eltűnnek? Nem tűnik biztatónak.
- Maradnak? Akkor meg lényegében senki sem fog igazán váltani, mert megmarad a kényelmes "régi" módszer. Meg ismét eljutunk oda, hogy szükséges a rendszernek a "régi típusú libeket" tartalmaznia a frameworkök mellett.

3.) Mi lesz a többi disztribúcióval?
- Beállnak a sorba, és ők is átveszik? Kötve hiszem, senki sem akar Canonical-függő lenni. L. még Mir.
- Mi lesz abban az esetben, ha pl. a "híres" alkalmazások ezt a frameworkosdit átveszik? (Hint: GNOME és systemd sírások)
- Szép lassan eltávolodnak, lesz külön Ubuntu, meg a "futottak még". Hurrá, sikeresen tovább tördeltük a platformot az egységesség jelszava alatt.

Megjegyzem: most sincs semmi akadálya a következőknek:
- alkalmazást saját home könyvtáradba telepíts.
- alkalmazást izolálni a többitől (pl. jogosultságok)
- alkalmazást az általa kívánt verziójú libekkel szállítani (Xilinx ISE, Dwarf Fortress, stb.)

Aminek több értelmét látom:
- Olyan alap librarycsomag biztosításának (és én ezt nevezném frameworknek), amire a Canonical garantálná, hogy backportolja és opcionálisan elérhetővé teszi (pl. az aktuális LTS-re). Értsd: nem az alkalmazás csomagolja maga mellé a Qt mittudoménhanyas verzióját, hogy legyen belőle harminckilenc példány a gépemen, hanem az alkalmazás - mint ahogy most is teszi a .deb-ben - függ a Qt adott verziójától, amit ugyanúgy, mint normális csomagot fel lehetne tenni. Ez meg már a jelenlegi toolokkal is elérhető...
Tehát nálam a framework a következőt jelenti: egy garanciát, hogy adott csomagokból, libekből ezek és ezek a verziók fent vannak. De ez most is egy létező dolog, úgy hívják, hogy stable release :-)

Mit nyerünk vele?
- Nem kell győzködni az upstream-et, hogy egy Ubuntu-only megoldás mögé álljon be
- Nem kell duplikálnunk a rendszeren elérhető programkönyvtárakat, stb: egy javítás során nem kell arra várni, míg az app fejlesztője gondol egyet és a javított frameworkkel fordít
- Stabil API-t is tudunk nyújtani: Pl. az adott kiadás mindég fixen tartalmazza magában a legutóbbi LTS-ben kiadott összegyűjtött libeket (tehát az LTS által "hivatalosan" támogatott verziót), ez a stabil API. Ha valaki nagyon akarja, az LTS-ek közötti kiadásokban használhatja a backportolt frissebbeket, és akkor ő is boldog lehet. (Qt-vel tipikusan ezt szoktam csinálni. A kiadásban ott van a Qt4, én meg PPA-ból mellétettem a Qt5-öt).

Értelemszerűen ez egyszerűsíthető: ha tudjuk, hogy nincs a régi és az új változat közt inkompatibilitás (upstream ezt illik, hogy tudja, illetve a csomag karbantartójának sem árt, ha ezt tudja, enélkül jobb, ha hozzá se nyúl...), akkor nem is kell őrizgetni a régit.

- Kompatibilisek tudunk maradni másokkal is.

Eddig nem szántam időt a Snappy-re, de az Ubuntu Touch mentén most találkoztam vele, bennem is felmerültek ezek, van pár tippem;

> Ki fogja rávenni az alkalmazásírókat, hogy azt használják: tipikusan a nagyobb upstream csapatokra gondolok (GIMP, Eclipse, akármi).
Most sem veszi rá senki őket, hogy .deb -et és .rpm -et csomagoljanak. A disztribútor is be tudja csomagolni első körben az upstream nélkül is.

> Mi lesz a többi disztribúcióval?
Na ez kínos kérdés. A Snappy-t átvehetik, de a framework-ok ABI kompatibilitását nem tudom mi garantálhatná. Mindenesetre ez nem csak az Ubuntu dolga.

> Olyan alap librarycsomag biztosításának
Ezek lesznek a framework-ok. A Snappy ugye több mint pusztán egy archiver, egy komplett architektúra, ami átfedésben van a dpkg funkcionalitásával. A dpkg brutális átszervezése is csak egy részét oldaná meg a dolognak, miközben egy csomó legacy-t kéne cipelni vele tovább, talán ezért hagyták ki.

> Nem kell duplikálnunk a rendszeren elérhető programkönyvtárakat, stb: egy javítás során nem kell arra várni, míg az app fejlesztője gondol egyet és a javított frameworkkel fordít
Az Ubuntu a zárt forrást is támogatni akarja, ez a Snappy egyik fő hajtóereje. Ott pedig a packager semmit nem tehet, egyedül az izoláció maradt.

Alapvetően a bank feladata és elemi érdeke, hogy a bank saját appja biztonságos legyen. Ebben a modellben a bank akkor is ki tud adni egy gyors workaroundot, ha a disztribúció még hetekig ül a problémán. A böngésző is jó példa ebből a szempontból: az elmúlt mondjuk két évben hány böngésző specifikus hiba volt (javascript, sandbox stb.) és hány olyan, amikor valamilyen egyéb, rendszer által szállított libben volt hiba? Gondolod, hogy ha a firefoxot rendszeresen foltozza a Mozilla, akkor az esetlegesen mellérakott openssl-t libraryból nem fogod megkapni a következő verziót a következő release-el? Ha meg a chatelős programod nem frissül rendszeresen, akkor így is - úgy is veszélyes, mert nem csak a hozzálinkelt ssl libraryban levő hibákat nem javítják, hanem az alap program hibáit sem.

A hibák döntő többsége a "változatos qualityjű" appokban van, és nem a disztribútor által alátolt rendszerben. Ha egy appot karban tartanak, akkor javítják így is, úgy is, ha meg nem, akkor meg szar van a palacsintában így is úgy is. De legalább a karbantartott (például banki) app nem lesz sebezhető azért, mert a user hülye és letölt három fingós programot meg egy nem karbantartott IRC chat klienst. Az, hogy ez neked jó-e, nem tudom: akarsz róla beszélni? Azzal kapcsolatban, hogy ez neked nem szimpatikus, nekem teljesen közömbös érzelmeim vannak: egyszerűen nem érdekel.

Te kezdted az akarsz róla beszélnivel (vagy neked szabad fricskázni?) és tekintve, hogy már nem keveset beszéltünk róla. Továbbá személyeskedés az lett volna, ha azt mondtam volna, hogy hülye vagy :) (Amit egyébként nem gondolok). Ezzel szemben azt mondtam, hogy a témában felmutatott világképed szerintem kissé túlegyszerűsít, és ezért nincs kedvem róla beszélni. Ha ez neked személyeskedés, hát hajrá. Fentebb már leírtam, hogy miért gondolom, hogy ez azért nem ilyen egyszerű, nincs kedvem mégegyszer, ne haragudj

BZoltan, azért van lehetőség ennek a formalizálására.
A megoldás, hogy Snappy-ben is formalizálni kell a függőségeket, hiába tolják ki őket static libben.

Pl. tfh az alkalmazásom függ foobar 2.0.0-tól. foobar 2.0.0 bele van fordítva a snappy csomagomba. Ugyanakkor a dependencia bele van írva a snappy valamilyen metadata-jába.
Innen, ha kijön egy security update foobar 2.0.0 alá, akkor az op rendszer értesíti a usert, hogy a foobar 2.0.0-t használó alkalmazás nem biztonságos...

Igen, ezt kéne formalizálni, ráadásul olyanformán, hogy biztonsági szempontból is okos legyen.
Az előző példán maradva. Az app függ foobar 2.0.0-tól, a foobar 2.0.0 mellékelve van az apphoz.
A metadata jól leírja, hogy az app csomag foobar 2.0.0-tól függ, oly módon, hogy foobar ott figyel az app mellett.
Namost, hogyan ellenőrzöd, hogy a metadata igazat szól-e?

Amúgy tudom, hogy nem triviális, én is dolgoztam/dolgozok csomagkezelőn.
Minden a koncepciókon múlik. És még a jó koncepteket is el lehet kúrni.

Dehát pont az a baj, hogy én reróznék ezerrel, de a disztrók nem így működnek. Az Ubuntu még csak-csak király a félévees kiadási ciklusával, de a Debian ugye kétévente ereszti ela kezét egy-egy stabil kiadásnak. Namost ha én hetente tolom a bugfixeket és az új fícsöröket akkor az ilyen csigatempó nem igazán pálya.

Szóval, hogy oldjuk meg? Van egy alkalmazásom ... fusson ugyanúgy a 7.0 és a 8.0 Debiánon is. Az utóbbi most jött ki, tessék. Minden friss és csilivili. De meg vagy lőve ha két éven át nem használhatsz semmilyen újabb API-t csak azt ami ott van benne.

Ha a két főverzióban eltér az API, akkor vagy csinálsz az alkalmazásodból is két verziót, vagy azt mondod, hogy a 8-as verzióhoz kötöd, és a hetesből hiányzó dolgokat meg backportolod.
Nem a disztribúcióknak kell hozzád alkalmazkodni, hanem fordítva. Nézz körül RHEL tájékon, ott még hosszabb ciklusok vannak, és mégis működnek a fejlesztések :-P

"Nézz körül RHEL tájékon, ott még hosszabb ciklusok vannak, és mégis működnek a fejlesztések :-P"

Nocsak, lemaradtam volna valamiről :) Lenne többmillió redhat/fedora a consumer device piacon és lenne rá sokszázezer alkalmazás? Lehet én néztem a csehkettőt, de úgy tudom, hogy a retek sem oldotta meg ezt a problémát, ahogy egyik disztró sem.

"csinálsz az alkalmazásodból is két verziót, vagy azt mondod, hogy a 8-as verzióhoz kötöd, és a hetesből hiányzó dolgokat meg backportolod."

Nincs is szebb meg olcsóbb dolog a forkolásnál és a karbantartási munkák megduplázásánál. Minden fejlesztő álma ez :D :D :D

Ez nem így megy... egy ilyen esetben a fejlesztők pont azt csinálják amit a snappy kontrollált formában kínál.

Nincs probléma, mert a RHEL-es csomagok készítői beállnak a sorba, és betartják a szabályokat - különben repül (be sem kerül) a motyójuk az EPEL-be se, hanem csinálhatnak saját repót, amit viszont komolyabb helyen - érthető okokból - nem fognak szeretni.

Ha nem akarsz egy régi környezetet támogatni, akkor ne csináld, ilyen marha egyszerű, ezt kéne felfogni.

"Ha nem akarsz egy régi környezetet támogatni, akkor ne csináld, ilyen marha egyszerű, ezt kéne felfogni."

Az volt a kiindulási felvetés, hogy de igen, akarok. Adott a probléma, olyan alkalmazást akarok csinálni egy branch-ben fejlődik, nem tudom peccselni a cél rendszert és azt akarom, hogy gyors fejlsztési ciklussal tudjak rilízelni.

Erre megoldás egy izolált és a rendszer egyik frameworkje által sem nyújtott könyvtárakat is magával hordó user space-be települő és létező alkalmazás.

Ezt a "fel kéne fogni" meg "különben repül" stílust meg tényleg hagyjuk. Én legalábbis nem szeretek ilyen modorban beszélgetni.

Ha top release-eket akarsz támogatni, akkor dobnod kell az lts támogatást. Az LTS-ben deefiníció szerint _nem_ lesz benne az, ami a "fagyasztás" óta főverzióban változott. Ezt hívják úgy, hogy stabil, tervezhető alaprendszer. Olyan, amire 2-3-5 éves fejlesztési életciklust is lehet alapozni, mert közben nem fogják 23 alkalommal átvariálni az egészet, és jóval kevesebb meló karbantartani egy kódot, ha a használt api nem változik olyan gyakorisággal, mint normális embernél az alsónadrág cseréje. Két eltérő felfogás - az egyik a stabil, hosszabb távra tervezhető környezetet részesíti előnyben, a másik meg a mindenből a legfrissebb/legújabb/leglegleg - akkor is, ha emiatt jóval többször kell a kódhoz akár alapjaiban is hozzányúlni.

A rendszer ad egy bizonyos openssl-t meg egy bizonyos Qt-t. Ezekre garantált, hogy lesz javítás mondjuk a következő öt évben. Lehet persze azt is csinálni, hogy az "alap" rendszerben nincs semmi, max. egy libc :) aztán minden app maga hozza a saját függőségeit - ilyet már láttunk a dos-os világban - egy alkalmazás, egy könyvtár, és szépen megfértek egymás mellett az ötös meg a hatos Pascal-ból érkezett unitok, nem zavarták egymást, Windows alatt meg a dll-ekkel volt ugyanígy - mindenki hozta a saját msvcrt més egyéb dll-jeit, aztán lehetett bogozni, hogy vajon az x meg az y alkalmazás miért viselkedik furán...

Megjegzem, szerintem a két felfogás békésen el képes férni egymás mellett. Minden libből és API-ból kell kettő, egy aktuális és egy fagyasztott. Az app készítője meg eldönti hogy követni akarja-e az aktuális eszközöket, vagy egyszer megírja és többet nem akar felé se nézni, csak ha nagyon muszáj.
Egy ilyen rendszer talán csak a méretében lehet nagyobb, minden másban ötvözi a két felfogás előnyeit.

Szerintem az a probléma, hogy te szerver verzióban gondolkodsz, ahol valóban fontos a 4-5 éves tervezhetőség. De ezt a technológiát nem oda szánják. Desktop oldalon az 5 évvel ezelőtti elavult vacak. Ráadásul az üzleti alkalmazások ma már böngészőben jelennek meg jellemzően, így a desktop oldali stabil apira nincs is nagyon szükség, csak egy elég modern böngészőre.

Azért RHEL is előfordul Desktop-on is, ott meg azért erősen a fontolva haladós felfogás működik. A párom notebookján még Ubuntu van, igaz LTS, aminek még azért bőven van ideje, de ha ott is a stable/devel/testing összekutyulására szavaznak (vélhetően igen, hiszen kétféle csomagolási módot nem fognak fenntartani szerintem), akkor repül, és megy a helyére CentOS.

Az a legnagyobb gond, hogy nem olvassátok el, (vagy nem akarjátok megérteni?), amit BZoltan ír.
(Az is lehet, hogy én nem értem, amit ír, de akkor majd kijavít, ha tévednék)

Az alaprendszer nem úgy néz ki, hogy "nincs benne semmi, max. egy libc"! Ott vannak a "framework"-ok, amikben benne van pl. OpenSSL, Qt, ...
Talán egy példa segíthet:
Legyen egy LTS, amiben van OpenSSL 0.9.8 framework és a Qt 4.6 framework. Van egy csomó alkalmazás, amiknek ez a két framework a függősége.
Jön egy új alkalmazás, aminek szükséges az OpenSSL 1.0 és/vagy a Qt 4.8. Akkor telepítik az OpenSSL 1.0 frameworkot és/vagy a Qt 4.8 framework-öt is az alkalmazáshoz.
Az alaprendszer ugyanolyan stabil marad, mint volt, mert továbbra is ugyanazokat a verziókat használja, mint eddig, viszont új alkalmazások telepítésére is lehetőség nyílik a régi rendszerre.
Ha biztonsági frissítésre szorul a Qt4.6, akkor azt a framework-öt kell frissíteni és kész, a "152" alkalmazást, ami használja, azt nem!
Remélem így már érthetőbb!

Azaz hozza magával a függőségét, és ha openssl-t kell frissíteni, akkor nem egyet, hanem rögtön kettőt frissíts. ha 152 app 152 különböző verziót igényel, akkor meg egyenesen 152-t - megsokszorozódik a frissen tartandó komponensek száma, ami üzemeltetési szempontból messze van az optimumtól.
Ez így egy "devel/testing" rendszer beleágyazva egy stabil környezetbe, ami fejlesztőnek lehet,hogy cool, de üzemeltetni, frissen, naprakészen tartani rémálom. Kijön egy OpenSSL sérülékenység, ami érinti lóugrásban a 0.9.x 1.0.y, z, w, verziókat - mondd meg, hogy 100+ gépen fent lévő 100*n darab openssl közül melyik az, ami sérülékeny, kell-e frissíteni, és ha igen, akkor mit okoz(hat) a frissítése.
Kontra: Van 100+ gépemen 100+ példányban legfeljebb 2-3 OpenSSL verzió, és ebben a körben kell az előbbi kérdésekre megadni a választ. Nem mindegy. Nagyon nem.

Azt hiszem erősen readonly-ban vagy.
A Snappy-vel is ugyanúgy meg tudja csinálni a disztribúció készítő, hogy csak 2-3 OpenSSL framework-öt készít és azokat használják az app-ok.
Illetve fordítva is igaz, a .deb-bel is ugyanígy tud 152 app készítő csinálni 152 app-ot, amiben benne van a 152 különböző verzió és akkor lehet frissíteni mind a 152-őt.

A probléma csak az, hogy amikor nem nyílt forrású, nagyrészt közösségi fejlesztésről van szó, akkor a gyártó jelenleg is tesz a policyre, és hozza magával a függőségeit mindenfajta retorzió nélkül. Csinál egy .deb és egy .rpm csomagot, és hogy minél több platformon fusson, az összes szükséges libet mellérakja. Nem lesz benne a hivatalos repóban, de használni kell. Itt most olyanokra gondolok, mint hogy az ebben a szálban sokat emlegetett heartbleed sebezhetőség érintette az oracle mysql enterprise bizonyos verzióit, ami jó eséllyel azt jelenti, hogy saját openssl libbel szállították. Ha ezzel lett tervezve a rendszer, akkor fel fogod rakni? Fel bizony, mert enélkül ugrik a kifizetett support. Sebezhető maradt a rendszered, miután kicserélted a "központi" openssl-t? Igen. Akkor miről beszélünk?

+1. Statisztikai programcsomag saját JRE-vel (sőt, talán JDK, nem esküszöm meg rá). Matematikai programcsomag, saját JRE-vel. Ja, és a hozzá kapcsolódó libekkel. Egy Matlab R2014a-ra find -name *.so | wc -l eredménye: 371. Oh, és van benne libssl so ;)

Ja, és még csak nem is rpm-ként jön, hanem egy sh fájlként, amit root-ként kell indítani, mert az milyen biztonságos.

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

Nem lom, hanem egy alkalmazás, amire a usernek szüksége van, ezért futtatni akarja. A telepített oprendszer meg azért van, hogy ezt az igényt kiszolgálja. Teljesen mindegy, hogy a hibás ssl library hogyan került a gépre, a fenti példa jól mutatja, hogy amint kilépünk az open source világából, a libek bizony gyakran jönnek az alkalmazással együtt.

Nem űrtechnológia sem deb, sem rpm csomagot kreálni. Anno volt néhány app, amihez volt közöm, ezekből természetesen készült csomag - akkor kifejezetten rpm-et kreáltam belőle, mert arra volt igény.
Anno volt, hogy saját repóhoz egyedi alkalmazásból kellett csomagot csinálni, hogy normálisan lehessen kezelni a telepítést/függőségeket/stb.

Hint: személyeskedés. Szerintem volt elég sok üzletileg kritikus fejlesztéshez közöm úgy, hogy az utolsó bitig szétauditálták a kódot - ezt biztosabb, komolyabb háttérnek tartom, mint a csomaggányolói státuszt bármelyik ópenszós motyó esetén (lásd debian ssl pofára esés példáját, ahol pont a karbantartónak sikerült a nagy hozzáértésével és tudásával örök emléket állítani magának...).

Annak a mérőszáma, hogy mekkora fogalmad van arról, hogy mit jelent csomagolni és egy csomagot karban tartani. Mint kiderült neked a leghalványabb fogalmad sincs erről. Ez persze nem baj, nem tolonganak az utcán a disztró maintainerek :)

Te írtad azt, hogy "Akkor tessen csomagot csinálni belőle" ... Na erre mondom azt, hogy olyant kérsz amiről te magad sem tudod, hogy mekkora meló. Mert, figyusz... az van, hogy te csinálhatsz magadnak egy lokál repóba olyan trehány csomagot amilyent akarsz. De egy disztróba betolni egy csomagot és átpaszírozni a kekecebbnél kekecebb adminokon és release-ről release-re megoldani, hogy minden szépen menjen, lekezelni a függőségek API változásait messze nem olyan egyszerű mint ahogy azt te sejteni véled. Tudni nyilván nem tudod, mert ha tudnád, akkor nem beszélnél butaságokat.

Te, figyusz... szerintem te rendes és okos arc vagy. Szimpatikus, hogy érdeklődsz az új technológia iránt és szánsz időt erre a beszélgetésre. Tényleg reszpekt... de alegnagyobb szeretettel és szakmai barátsággal mondom, hogy ha tényleg halvány gőzöd sincs arról, hogy egy disztró hogyan működik és a mai alkalmazás fejlesztőknek milyen igényeik vannak és hogy hogyan lehet a mostani desktop linux világban a jelenlegi zérus appok számát felvinni a bűvös tízezer-ötvenezer szám fölé akkor kérlek ne beszélj butaságot, mert rém kényelmetlen.

Én több platformnak az SDK-ját fejlesztettem, vagy hét éve konkrétan ebből élek, Debian, Maemo, Meego, Ubuntu rendszerekkel küzdöttünk masszív gurukkal azon, hogy ezt a problémát megoldjuk. Marhára nem triviális... és speciel ez az izolált, konténeres app management és image based inkrementális rendszer frissítési modell az ami végre megoldani látszik azt a problémát amivel évtizedek óta szopunk masszívan.

Érted... nincsenek appok linuxra, sosem voltak igazán. Az N900 szánalmas párezer appal vagánykodott. Appokat csinálni a korai Maemo-ra konkrét Debian packaging guru tudást igényelt. A Meego-ra már valamit sikerült ezen javítani. A SailfishOS úgy kalap szar ebből a szempontból ahogy van. A natúr Debián és Ubuntu egy vicc... semmi confinement, semmi security wild-wild-west. Ameddig guruknak megy és ameddig nincsenek adatlopó appok addig frankó... de marhára nem kéne erre építeni a jövőt.

Szóval érdemes az egészet egyben látni... És vaze, ha én azt mondom, hogy a kripó libek azok a platform részei lesznek akkor az úgy van. Éppeszű ember nem áll neki azon rugózni,hogy de hát akkor 152 app majd 152 féle kripto libet fog használni... _NEM_ fog, mert van és lesz is .deb alapú disztró kiadása ezeknek a libeknek. Nem az ilyen rendszer libek beágyazásáról szól a dolog, hanem mondjuk a QML plugin .so beágyazásáról. Ennyi... remélem lezárhatjuk ezt a fingfűrészelést mert kezd baromria unalmas lenni....

Attól, hogy nem tojok rendszeresen tojást, még meg tudom állapítani, hogy záp-e vagy sem az adott produktum, maradjunk ennyiben. Szoftverfejlesztés- és karbantartás terén a tojásnál jóval több tapasztalatom/gyakorlatom van - mint írtam, olyan esetekben is, ahol nem a "gyorsan kibüfi valamit" volt a cél, hanem agyontesztelt/auditált kód. Nagyon más világ a kettő.
Neked sajnos arról nincs fogalmad, hogy a rendszer- alkalmazás- és adatbiztonság fogalmak mit jelentenek, hogyan viszonyulnak egymáshoz, mire kell(ene) a fejlesztőknek odafigyelni.
Az izoláció egymástól talán megvédi az alkalmazásokat - viszont a kezelt adatok nem csak az alkalmazás izolált környezetében léteznek, szükséges adatokat cserélni, aminek során kikerül az adat az adott "biztonságos" környezetből (de eközben is az app felelőssége, hogy maximálisan biztosítsa az adatok teljes integritását), illetve bejön az a probléma, hogy azonos jellegű/feladattal bíró komponensből n+1 darab lesz a rendszerben, ami megsokszorozza a biztonsági kockázatokat, hiszen nem lehetek biztos benne, hogy az xyz lib ismert hibája minden egyes alkalmazás esetén, ami sajátot hoz belőle, javítva lett.
Ha az ilyen közös komponensekből csak kellően kis számú telepíthető, _és_ az alkalmazások önmaguk nem hozhatnak saját verzíót, akkor lehet jó is a dolog, de igen erősen meg kell húzni azt a határt, ami még ésszerűen karbantartható úgy, hogy egy adott frissítés után a rendszerről ki lehet jelenteni, hogy például az openssl CVE-12345678-as sérülékenységétől teljes mértékben mentes. Ha ilyen állapot nem érhető el, az szerintem baj. (a QML plugin is hordozhat integritást veszélyeztető hibát :-P)

Nem, ha nem vagy és sosem voltál semmilyen disztróban semmilyen csomag karbantartója, akkor neked a leghalványabb gőzöd sincs arról, hogy milyen munkát lőcsöltél látatlanban az alkalmazás fejlesztőkre amikor azt mondod, hoy hát csomagolják be az appjukat a mostani formátumokba,

"Neked sajnos arról nincs fogalmad, hogy a rendszer- alkalmazás- és adatbiztonság fogalmak mit jelentenek"

Ne haragudj, de ez komolytalan. Ebből élek, ez a szakmám...évek óta olyan projekteken és cégeknél foglalkozom kimondottan ezzel a témával akiket és amiket te is ismersz. Hülyeséget, csak azért, hogy csapkodjál és személyskedjél kár mondanod. De tényleg.

"szükséges adatokat cserélni,"

ha ezt a rendszer szabvános API-jain keresztül teszi akkor ezen API-kat olyan rendszer könyvtárak biztosítják amelyeknek megbízhatósága a platform feladata. Innentőlkezdve mondvacsinált a problémád.

DE EZT MÁR EZERSZER ELMONDTAM NEKED!!!!

"a QML plugin is hordozhat integritást veszélyeztető hibát"

Hagy már el ezt a baromságot! Nem tudsz olyan app libet írni amely az app saját adatain túl bármi másra kockázatot jelent. Hülyeséget mondasz.

Ha az adat sérülhet, illetéktelen hozzáférhet, vagy csak nem áll rendelkezésre az alkalmazás hibájából, az szerinted micsoda? Például a lib bizonyos UTF-8 karaktereket rosszul kezel, és bizonyos körülmények között nem tudja visszaadni a bemeneten kapott információkat az alkalmazásod/mást ad vissza, mint amit kéne. Szerintem ez az adatok integritását és rendelkezésre állását érintő biztonsági hiba, amit javítani kell. Az adat NEM az alkalmazásé, hanem a felhasználóé, az alkalmazás csak kezeli azokat, és bizony a rendelkezésre állás, integritás és bizalmasság feltételének meg kell feleljen.

Biztonsági témában szerintem már rég ellőtted az ásd el magad felszerelés nagybani használatát ezzel:

"Az OpenSSL dolog egy kicsit légből kapott. Az egész modern app világban nincsenek ilyen típusú biztonsági rések az appok oldalán. "

Persze, van olyan fejlesztő, akinek az a jó, ha van a release után is munkája, például azzal, hogy javítja a kiadott kódot rogyásig :-P

Összevissza beszélsz teljesen szakmaiatlan hülyeségeket.

Részemről veled ez a téma lecsukva... te egy troll vagy. Vagy csak durván inkompetens aki mégis azt képzeli magáról, hogy köze van a témához.

Sajnos nincs közöd. Kidobott idő volt minden hozzászólás amit rád pazaroltam, mert a tizedét sem érted. Sajnos igaza volt annak aki már az elején figyelmeztetett, hogy nem érdemes laikusokkal erről vitázni.

Minden jót.

R=1 userről és desktopról beszélünk, még telepítést végző rendszergazda sincs, nem hogy utána kettővel. A user NEM fog csomagot csinálni, mert nem ért hozzá, nem érdekli, nem feladata. A Matlab miért csinálna belőle disztribúciós csomagot, mikor az install scriptje működik, és úgyis ezt fogják használni, mert nem nagyon van alternatíva? Miért szopjon azzal, hogy fél évente integrációs teszteket nyom a legújabb ubuntu/kubuntu/xubuntu/debian/mint/redhat/centos/arch linux/gentoo alatt, amikor ha hoz minden libet és behányja őket egy directoryba, amire beállítja az LD_LIBRARY_PATH-t, akkor az úgy működik mindenhol? Az egyik oldalon pénzmegtakarítás, a másik oldalon a felhasználó elégedett, ebből a körből hogyan gondolod a kitörést?

Persze ha legalább izolálni tudnánk egyszerűen, és nem b*szná szét az alap rendszert... Oh, wait...

Van alternatíva?

Egymás mellé fel kell telepíteni azokat a libeket, amiknek az API-ja megváltozott. Lesz 5.2, 5.5 meg ami közöttük van.

Aztán amikor az utolsó olyan csomagot, ami az 5.2-t használja eltávolítod vagy olyanra frissíted, ami már nem az 5.2-t használja, akkor az 5.2-t automatikusan eltávolítja a rendszer.

Mondjuk nem tudom, lehet, hogy éppen a Qt esetén valami miatt ez nem megy, de akkor ez a Qt hibája és nem a deb formátumé.

Ezt, amit fent írtam, nem én találtam ki, hanem így működik az én debianom. Sok libbel megy ez. Persze simán lehet, hogy van olyan, amivel nehéz, mert nem készítették fel rá.

Amit leírsz az szép és igaz. De van vele két probléma:

1. Ha te alkalmazást készítesz egy már lezárt és befagyasztott fejlesztésű rendszerre akkor _NEM_ pakolhatsz fel rá csak úgy olyan libeket, még verzózva sem, amik arra a lezárt rendszerre el sem készültek. Nevezetesen az 5.5-ös Qt-ot a kutya sem fogja egy 14.04-es Ubuntu-ra backportolni. Egyszerűen az lesz, hogy van egy appod ami használná a Qt framework újabb kiadásainak frankóságait...de te ezt ne teheted meg, hiszen a korábbi ubuntu kiadásokon nem lesz ott a függőség. Mi a megoldás? Az, hogy összecsömagolod az appoddal azokat a függőségeket amik esetleg a hoszt gépen nem elérhetőek.

2. Ahogy te is leírod, sok olyan lib van amiknek a minor verzióik nem telepíthetőek együtt. Igen, ez csomagolási probléma. Esetünkben Qt upstream ívesen tesz arra, hogy ki és hogyan csomagolja a targézájukat... szerintük szívjon ezzel a downstream disztró. Na ez meg is történik. De egy akkora rendszerben komoly forráskód refaktoring kellene ahhoz, hogy a minor verziók megférjenek egymás mellett. Na, innentől osztják a szopógombócot.

Ha a rendszer "lezárt", akkor ott abból kell főzni, ami van. Ha egy szolgáltatást például RHEL5-ön akarok futtatni, akkor nem a RHEL6 vagy RHEL7 által nyújtott komponenseket használom, hanem azt, ami a RHEL5-ben _is_ elérhető.
A lezárt/régi rendszer és az, hogy minél frissebb komponenseket akarsz használni az csak fájdalmasan (backport) fér össze.

"Ha a rendszer "lezárt", akkor ott abból kell főzni, ami van."

Nem kell... van megoldás erre a problémára. Ezt nyújtja a snappy.

Az alkalmazás fejlesztők kimondottan szeretik a legújabb, legbiztonságosabb és legmenőbb keretrendszereket használni. Pont itt válik el a modern fejlesztési igény a régi itteratív disztróban való gondolkodástól.

Ezt eddig is megtehetted saját repóval, amiben úgy lapátoltad össze a komponenseket, ahogy akartad. Viszont a disztribúcióban egy komponens célszerűen egy példányban volt jelen - a jövőkép meg ezzel szemben az, hogy akár 152 különböző verzió/fordítási opcióval készült/hákolt-tákolt verzió is ott legyen, ami ugyan a lusta fejlesztőnek kényelmes, de biztonsági szempontból kezelhetetlen állapotot tud eredményezni.

Az, hogy az e.péló lengetési faktor miatt a fejlesztő a holnaputáni eszközöket szeretné használni, az a felhasználói oldalt nem érdekli, tessen a megadott eszközöket használni, és nem gányolni - otthon, saját kedvére csinálja, de rendszerben gondolkodni nem így kell, igazodjon a rendelkezésre álló eszközökhöz és korlátokhoz. Ha nem megy, akkor menjen kapálni.

Nem teheted meg saját repóval... mert saját repóból sem cserélheted ki az adatpációs és framework szintű libeket amiket jó esetben használ a te appodon kívül húsz másik is.

Érted, van egy appod ami az 5.4-es Qt-tal igazán kúl. Azt akarod, hogy ez fusson olyan Ubuntu-n amin csak az 5.2-es kiadás van. Te csinálsz egy repót.. okés. Belepakolod az 5.4-es Qt-ot. Na, de az összes Ubuntu-n amin 5.2-es Qt van le kellene cserélni a Qt-ot. Na ez az ami nem fog menni... ugyanis huszontucat másik app strict version függ az 5.2-esen. A két minor verzió pedig nem él meg együtt.

"igazodjon a rendelkezésre álló eszközökhöz és korlátokhoz. Ha nem megy, akkor menjen kapálni."

Kicsit zavar ez a stílus. Megoldható lenne, hogy normális hangvételben beszélünk egy technológiai kérdésről. Bevallom engem zavar az ilyen csendőrpertus leszóló fikázás.

Olyan rendszert üzemeltetni, ahol minden app a saját függőségeit hozza, normálisan nem lehet. Nem kicserélek, hanem a saját libek mellé berakom a rendszer részeként is elérhető lib egy saját, akár patkolt verziószámú verzióját. Megtehetem? Ha igen, akkor mutasd be, hogy 100 körüli alkalmazás esetén annak a komponensnek a sérülékenysége, ami nem a framework/alaprendszer része, vagy ha része, de az appok egy jelentős hányada saját maga mellé csomagolva hozza, hogyan frissíthető rövid időn belül egységesen biztonságosra? Jaaa, hogy valamennyi alkalmazást frissítsem - ha épp a fejlesztő úgy akarja. Vagy rá lehet kényszeríteni az egyes alkalmazásokat arra, hogy márpedig nem a saját, hanem a rendszer által a rendelkezésükre bocsátott libeket használja, ha van ilyen? (Tehát elsődlegesen a /lib és társai, és a saját motyók csak akkor, ha ott nincs.)
A fejlesztő szeretne minél újabb vakokkal villogni, hogy az ő motyója nem a tegnapi, hanem a holnaputáni stabil verziókat használja mindenből, és hogy ő mennyire top-on van technológiailag - az üzemeltető meg azt mondja, hogy ami működik, azt nem kéne lecserélni, úgyhogy tessen a tegnapelőtti, jól működő rendszerhez igazodni - vagy itt a kapa, és irány a krumpliföld. Nem véletlen, hogy üzletileg kritikus rendszereknél az alaprendszer életciklusát is úgy választják meg, hogy a rajta futó alkalmazással pariban legyen. Nem olyan cuccot választanak, ami max. 1-2 évig lesz támogatott, hanem ami a tervezett rendszer kivezetéséig, ami ennél általában hosszabb idő.
Ópenszósz világban mondhatja azt a fejlesztő, hogy használj mindenből a legfrissebbet - legfeljebb akiknek tényleg fontos a stabilitás és a hosszú távú támogatottság, azok elkerülik az ilyen fejlesztőt. (Igen, RHEL5/6/7 van a kezem alatt, bár ha rajtam múlna, a RHEL7 csak akkor került volna elő, amikor a RHEL5-ök kivezetése javában tart - de sajnos egy "nagyon up-to-date" fejlesztő miatt kell a RHEL7, mert a lomja olyan verziókat követel meg, ami RHEL6-on nincs. Annak ellenére tszi ezt, hogy kicsomagolva és a megfelelő helyre bemásolva pöcc-röff működik a motyó... (Nem,a z nem megoldás, hogy az ilyen cucc hoz egy komplett php/perl/python/satöbbi környezetet).
Egyébként anno volt szerencsém ilyesmihez: Tomcat-tól nginx-en meg memcached-en, mysql-en meg redisen át a jó ég tudja, hogy milyen cuccokat kellett úgy kireszelni, hogy egy darab könyvtárat nfs-en felcsatolva a motyó a központilag kialakított konfigurációt magára rántsa, és utána képes legyen az alaprendszertől függetlenül működni. Nem volt egyszerű, de össze lehetett rakni :-P

meg. Elmentem az ubuntu oldalára, ami alapján a desktop az a végfelhasználói gépekre szánt változat, abba nekem a fenit csomagok bőven benne vannak (hacsak nem az van, hogy ezekre továbbra is megmarad a deb, de erről a belinkelt bejelentés nem szól).

Az ubuntu oldaláról kurvára nem derül ki, hogy mi az a next, ezért én feltételeztem így kiadás után, hogy ez kb a fejlesztői ág neve. Ráadásul BZoltan lejebb mondta, hogy "Amit most kitaláltak az az, hogy ezt a modellt adaptáljuk az asztali Linuxra." Én ebből továbbra is azt látom, hogy ez kb az eddigi desktop image.

Ha nem, akkor kérlek javíts ki, ha viszont igen, akkor a kérdések igenis jogosak :)

kérlek, akkor -- bár már fentebb is -- magyarázd már meg, hogyan kellene ezt érteni:
Our plan for 15.10 (which is still being finalised, and will be discussed in more depth at UOS in a couple of weeks) is to have a build based on Snappy Personal and so the current .deb based Desktop Next image will be going away and will be replaced with the new Snappy version.

Pomt ezeket csináltuk meg "önhordó" verzióra, hogy egy nfs mounttal másik gépen pöcc-röff menjenek. nem volt csak vagy tucatnyi app így összerakva, de a frissen tartás nem volt egyszerű - ugyanis darabonként kellett frissíteni, még akkor is, ha ugyanazt az alaprendszer részét egyébként sem képező lib cserélődött le alattuk.

Belepakolod az 5.4-es Qt-ot. Na, de az összes Ubuntu-n amin 5.2-es Qt van le kellene cserélni a Qt-ot.

Utópia: A probléma magától megoldódna, ha a Qt frissítési ciklusát enyhén visszavágnák.. :-)

Csak annyira érdemes előre rohanni, amennyire a felhasználók tudják követni. Könnyen lehet, hogy mondjuk 5.4-en tök jól megy a cucc, aztán 5.6-ra pl. kivágnak egy csomó mindent amit használsz - mondjuk kódtisztítás ;-) címén - aztán vagy visszatérsz az 5.2-höz, és azt írod át 5.6-hoz, vagy a "kitisztított" kódokat visszarakosgatod.
Ez is benne van a pakliban, vagy nem ?

A túlzott mértékű fejlesztési rohanás könnyen halott projektbe fullhat, pl. linux kernelben anno a devfs volt ilyen a 2.6.x széria elején. Ez nekem mint debian stable használónak úgy maradt ki az életemből ahogy volt 2.4.18,2.4.26 után 2.6.18 volt, amiben már nem volt benne. :-)

------------

MIndenesetre érdekesnek hangzik, feleslegessé tenné sok esetben az apt-pinninget felhasználói oldalról.

Ami minden dependency hell elsődleges forrása lehet. :-)

--------

Nem vezetek...Jobb így. Nekem is
meg mindenki másnak is.

Hány bugot javít, és hányat rak bele? Meddig tekinthető "stabilnak", meddig lehet tervezni egy adott verzióval. Nem kötelező a régit használni - viszont ha az a célod, hogy stabil, netán LTS rendszerre, vagy épp RHEL-re akarsz fejleszteni, akkor fogadd el, hogy vannak szabályok, amik nem csak a fejlesztők rohanását óhajtják támogatni.

Azért van néhány alkalmazás, ami az EPEL repóba sem került be, mert ilyen bolondériái vannak, és a fejlesztő nem tudja/akarja megváltoztatni. Nem kényszer, csak olyan elvárás, amit minimum "illendő" betartani. Semmi sem akadályoz meg abban, hogy a a saját motyód csináljon egy /ide/teszem/a/binárisokat meg egy /ide/teszem/a/libeket/ és egy /ide/meg/berakom/a/konfigokat/ könyvtárat, meg azt is megteheted, hogy a /etc/ alá teszed a webes alkalmazásod plugin könyvtárát (láttam ilyet!), de ezzel csak azt éred el, hogy a standardokat felrúgó motyó hivatalos, normális repókba nem kerülhet be.

Kérdeztem valamit, és nem tudsz rá válaszolni, csak hajtogatod a magadét. Nézz utána, hogy rpm-alapú rendszerekben a deb(il) csomagokhoz képest mennyiben más betartandó szabályok vannak, például arra, hogy mi hol lehet. (Azzal, hogy a /usr lehet nfs-en, a /usr/lib alatti függőséggel nem készülhet az NFS előtt induló szolgáltatást nyújtó csomag, még úgy sem, hogy a /usr/lib alól maga mellé másolja, vagy magával hozza a függőségeit.)

Panorámatükröt szereltél már a fürdőszobába a mosdó fölé? Kéne... Meg tartalommal is hozzájárulni ehhez az oldalhoz - például azzal, hogy leírsz néhány hasznos dolgot arról, hogy a nagytudású potentátok, közöttük te is, hogyan csinálok deb csomagokat úgy, hogy az aztán tökéletes legyen, illetve a snappy-ról is lehetne egy összehasonlító anyagot készíteni - ha már amúgy is annyira benne vagy- hogy fejlesztői, üzemeltetői és felhasználói oldalról mit nyújt, mik az előnyei, hátrányai... Ilyesmi.

Szerintem elég sok a téma háttérét és alapjait elemző hozzászólással járultam hozzá a topikhoz. Őszintén és nagyon sajnálom, hogy a kapacitásodat meghaladja ezen hozzászólások elolvasása és értelmezése. De hát, ugye nem vagyunk egyformák.

Kedvelem ezt a fórumot és sok értelmes, érdeklődő és nyitott arc van itt akikkel érdemes beszélgetni szakmai dolgokról. Te, sajnos nem tartozol közéjük. Nekem pedig a gyógypedagógiai ambícióimat sajnos meghaladja az a kihívás amit a veled való társalgás megkövetel...így a legnagyobb barátsággal és tisztelettel én tőled most búcsúznék és a veled való mindennemmű kommunikációt lezártnak tekintem.

Igen, részben erre is céloztam, hogy csak annyira szabad fejlesztésben előre rohanni, amennyire felhasználók tudják követni.

Ezt az idő fogja eldönteni mennyire lesz népszerű az új koncepció.
Az viszont biztos, hogy ha nagyrészt beválik, akkor elkezdődik majd az a vita, hogy akkor a régi már ne legyen.

De szerintem ennyire azért ne szaladjunk előre.

Az ubuntus userek ált. szeretik az új dolgokat. (ezért használnak ubuntut :-DD / nojó, most kicsit gonosz voltam ;-) /,
én a debian stable -)) / illetve pár napja oldstable :-D / "pártból" kényelmesen figyelem a fejleményeket a "szomszéd"-ból.. ;-)

zellernek abban igaza van szerintem, hogy lehet, hogy jönnek új ficsőrök, de igen gyakran új korábban nem létező bugok is.

Ezt majd az userek / idő / fogják eldönteni, hogy az új ficsőrök hiánya, vagy az új bugok zavarják-e majd jobban.

Ez majd kiderül.

--------------------

Én mondjuk tudom magamról, hogy kissé :-)) a szokások rabja vagyok, tehát néha tényleg csak akkor lehet előre kergetni,
ha már mögöttem csak a szakadék van :-)).

Meg ugye ez ubuntu sztori, és nem debian egyelőre, tehát amíg ide leszivárog a sztori eltelik pár óraátállítás...
De nem árt tudni, milyen változások várhatóak. ;-)

Ugye aki még 2015-ben is LILO-t használ :-))), ahol tud , meg ext3-at, azt egy kicsit nehéz előre rugdosni úgy általában. :-DD.
Igen, a kérdésre a válasz az, hogy még 64bitre se tértem át. ;-)))

offtopik on:

Idén a home fájlrendszer 10 éves születésnapját ünnepli, ebből jó pár évet cryptoloop-ban, azóta már ebben változás állt be :
(közben néhányszor azért költözött, tehát nem ua. vinyó.), csak a
partíciók költözködtek.


root@osconsfortress:~# dumpe2fs /dev/sda9 | grep creat
dumpe2fs 1.42.5 (29-Jul-2012)
Filesystem created:       Sat Sep 24 12:54:59 2005

A többiről sajnos nincs adat, a 2 kicsi partíció ext2-es, a / pedig ext3-s de arról sincs adat. Nem tudom miért.
Lehet, hogy amikor készült, akkor ilyen info még nem jött létre,
vagy ext2-ből konvertálódott, és azért nincs.
Sajnos ez az info a memóriám lomtárából is évekkel korábban elveszett. :-)

offtopik off.

De szerintem az ubuntu userek nem magamfajtából vannak összegyúrva nagy többségében, úgyhogy azért nyitottabbak az újdonságokra. :-)

--------

Nem vezetek...Jobb így. Nekem is
meg mindenki másnak is.

Én csak arra kaptam fel a fejem, hogy szegény zeller azt hiszi, hogy az LTS meg a stable kiadások azok azt jelentik, hogy azokra nem lehet korszerű technológiát adaptálni.

Ez meg ugye triviális baromság.

A mostani rendszerben, minden újítás nélkül is, ha neked az old stable debianodban egy lib csak mondjuk X.3 verzióban létezik, de te egy alkalmazást akarsz írni ami az X.8-at használja akkor azt _MOST_ is megteheted... egyszerűen statikusal linkelsz vagy bepakolod a libeket az alkalmazásod mellé.

Az alkalmazásodat a disztróba nem teheted be, de csomagolhatod saját natív repóba ha akarod (ez azért komoly meló) vagy publikálod targézában user space-be.

Amit szegény zeller nem ért meg, hogy _EZ_ már _MOST_ is lehetőség. Nincs az égvilágon semmilyen megkötés, hogy egy old stable debian $HOME alá ne lehetne olyan gányt bepakolni amilyent csak a júzer akar.

Ez az egész snappy és click pont arról szól, hogy úgy tudsz feltenni _ELLENŐRZÖTT_ módon új alkalmazásokat sőt akár frameworköket a kőstabil és akár read only-ban műkődő platformodra, hogy ezzel legkevesebb biztonsági kockázatot sem kell válllnod.

Én azt nem értem, hogy ebben mi a bonyolult.

Olyan ez mintha lenne egy régi de szép ház amit még akkor építettek amikor nem volt szokás a WC... aztán amikor a házmester észreveszi, hogy mindenki csak a ház mellé megy szarni akkor hozat mobil budikat, felszerel külső csapokat és rak ki tiszta törlőt meg papír. Ennyiről szól a snappy rendszer.

Semm ilyen nem lesz ami eddig nem volt, de ami volt azt ezzel lehet normálisan, biztonságosan és kényelmesen csinálni. _LEHET_ ... de nem muszáj. Semmi nem kötelező.

HA most is beengednek hivatalos repóba olyan cuccot, ami statikusan linkelt (és nincs ár jó ok, hogy miért statikusan linkelt), ha beengednek olyat, ami maga mellé rakja a rendszer által csomagban szállított libek eltérő verzióját, akkor az nem jó. Ugyanis ebben az esetben arra a kérdésre, hogy az "xyz.so CVE-123456 sérülékenység érinti-e a rendszert" valamennyi alkalmazást végigvizsgálva lehet csak helyes választ adni - miközben egy kellően jól szabályozott esetben, csak a rendszerépítő saját repóját használva egy darab csomag friss/nem friss állapotát elég ellenőrizni.
Jól mondod: a ~ alá bepakolni az gány. Meg egy /opt/idebele/csupaújkellneki/{bin|lib|etc|share|...} alá települő, a rendszerrel érkező csomagokban lévő libek/szolgáltatások helyett sajátokat hozó motyó is gány. És ez, ha a / full read-only, akkor is biztonsági kockázat - mert n+1 eltérő verzióban létezhet a rendszerben ugyanaz a lukas komponens.

A budis hasonlatra csak annyit, hogy én szívesebben áldozok arra, hogy az épületen belül alakítsunk ki vizesblokkot, minthogy az épület mellé lehajított műanyag bódékba járjon ki mindenki. Első körben több munka és pénz, hosszabb távon viszont az a korrekt és gazdaságos megoldás.

Oks, akkor túllépve a repóban elérhető, nyílt forrású szoftvereken, kérlek magyarázd már el az összes többi vendornak, hogy miért lesz nekik jó, lényegesen nagyobb ráfordítással kiépítik a benti WC-t, aztán karbantartják - és természetesen nem is csak egyet, hanem azonnal N-et. (magyarra fordítva: M disztró L különböző verzióját támogassák, mindegyikhez kövessék a repóban levő libek változásait és persze csomagolják minden formátumba a dolgaikat. - miközben per pill még a RHEL/SLED se szokott nekik sikerülni, amikhez elég lenne egy rpm és amiknél nem nagyon ugrálnak release-n belül verziókat a libák)

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

a desktop linuxra ma elérhető proprietary programok >80%a Debian linuxra készül úgy, hogy nem is deb csomagként kerülnek fel. ez főként a Valve érdeme, két dolgot viszont jól mutat.
1. nagyon jó, stabil alaprendszert ad a Debian a deb csomagjaival egyetemben, külsős kereskedelmi programok számára.
2. külsős proprietary programok számára mindig is jobb volt Loki installert, Steamet, vagy egyéb deb/dpgk rendszertől független telepítési módot használni.

csomagolhatod saját natív repóba ha akarod (ez azért komoly meló)

Annyira azért nem.
Szerintem elég hamar össze lehet dobni egy "saját repot".

dpkg-deb csomaggal gyakorlatilag bármiből lehet csomagot csinálni, még a semmiből is ha csak egy dummy csomag kell függőségek kezelésére.
csak a DEBIAN könyvtárban levő file-kat kell szabályosan összerakni. Hogy a dpkg megehesse.
Különösen a controlt.

Innentől csak a kész csomagot kell egy megfelelő könyvtárstruktúrába betenni amit az apt tud kezelni (pool, dists), és létrehozni a Packages, Release fájlokat,
és kb. kész is a "saját repo",
amit fel lehet venni apt sources list-be.

Ha elkúrod a control fájlt akkor a dpkg úgy is visítani fog, ha a saját repodból fel akarsz tenni egy csomagot, és a függősége nem megfelelő egy másik már fent levő csomagnak a rendszerből.

Nincs az égvilágon semmilyen megkötés, hogy egy old stable debian $HOME alá ne lehetne olyan gányt bepakolni amilyent csak a júzer akar.

Ha zeller adminisztrátor szemmel nézi a júzereit, akkor azért vannak biztonsági módszerek amivel a userek garázdálkodását a HOME könyvtárban le lehet szorítani.

Pl. noexec, és TPE (www.grsecurity.net), ez utóbbi azért elég erős korlátozás. Főleg, hogy a TPE árulkodik is a kernellogban a júzerről, hogy

"grsec: denied untrusted exec (due to being in untrusted group and file in non-root-owned directory)"... :-))

--------

Nem vezetek...Jobb így. Nekem is
meg mindenki másnak is.

"Annyira azért nem."

Hát de bizony igen. De téged is megkérdezlek, hogy vagy-e bármelyik disztróban csomag kabrantartó? Vannal-e publikus repókban általad készített és karbantartott csomagok?

Én sok éve csinálom ezt és szerintem nem sportszerű kezdőknek azt a benyomást kelteni, hogy ez pofon egyszerű.

Az egységsugarú júzernek eleve meg kell értenie az egész debian/ namespace lényegét, tartalmát. A control fájlnak van jópár olyan mezője amit ugyancsak értenie kell, tudnia kell a dpkg igencsak szigorú verziókezelését és ugye csinálnia kell changelog-ot meg rules fájlt.

Nyilván nem fekete mágia, de az egyik legnagyobb probléma a .deb-bel pont az, hogy nem automatizálható és nem lehet hozzá univerzális UI frontented csinálni. Ez pedig a belépő szintű alkalmazás fejlesztőknek eleve probléma.

Szóval ne engem győzz meg :) hogy milyen egyszerű a debian csomagolás, mert én napi szinten csinálom ezt vagy nyolc éve... hanem azt a fejlesztőt aki csak egy vicces appot akar csinálni.

"zeller adminisztrátor szemmel nézi a júzereit"

Dejszen desktop történetről van szó... Nekem utoljára olyan $HOME-okat aminek nem a felhasználó volt a rendszergazdája én az egyetemen láttam 1994 környékén :D :D :D Azóta csak eltelt vagy húsz év.

Tegye fel a kezét az akinek desktop linuxa van és valaki más a rendszergazda... értelem szerűen a laikus feleség/férj meg hasonló családi ubuntuja :) nem ér.

De amúgy az a noexec és TPE amiről te írsz azok nem része a konvenciónak. Vagyis az állításom, hogy nincs ilyen megkötés az igaz.

"Vannal-e publikus repókban általad készített és karbantartott csomagok?"

Nincsenek. De a "saját" repó, és publikus repó , meg a disztribúciós repo között azért van különbség.

Az előbb "saját" repót írtál. Én ezt úgy értettem, hogy "saját" repó, az lehet személyes használatra, vagy cégen belüli saját használatra. Akkor ezt félreértettem. Bocs.

Pl. ha disztrótól eltérően használ az ember 10-12 csomagot, ott már megérheti a külön csomagoknak készíteni egy saját akár helyi repót is. mint egyesével dpkg -i vel felpakolgatni a különcöket.
Vagy ugyanazokat a külön fordított csomagokat a "család" több gépén is használod.

Mert könnyebben kezelhető, és rendszer telepítés,
frissítés után a deborphan pl. nem takarít le olyan libeket,
amik egyébként kellenek a külön fordított/ vagy plusz csomagokhoz, ha beteszed függőségnek a controlba. :-)

Erre írtam, hogy ez azért nem egy nagy művészet.
Itt azért a debian disztribúciós megkötései közül nem kell mindegyiket alkalmazni. :-))). Elég annyira összerakni, hogy a dpkg/apt-get megehesse. ;-).

Persze ha be akarod tolni egy disztróba,
na akkor az már gáz,
mert ott már mindenféle egyéb belső szabályoknak is meg kell felelni, meg hivatalos karbantartás,
meg kutyatöke, nem elég a dpkg/apt-get formai/alaki megfelelőség, és a használhatóság.

A licensz cirkuszról már nem is beszélve. Nem véletlenül van mai napig külön a debian multimedia repo pl. :-))

hanem azt a fejlesztőt aki csak egy vicces appot akar csinálni.

Hát az lehet, hogy elsőre frászt kap tőle, hogy ezt meg azt miért meg mi a francnak,
mikor belenéz egy deb csomagba dpkg-deb -R -el :-)) a licenszelésről már nem is beszélve. :-))

A debian mint disztribúció soha nem arról volt híres, hogy nagyon könnyű oda mindenféle cuccot betolni.
Csak kipróbált, tesztelt, stb. Ez nyilván nem a belépő alkalmazásfejlesztők játszótere.

És szerintem a deb csomagkezelő ezt a szemlélelet tükrözi.

Én csodálkoztam is anno az ubuntu indulásakor, hogy deb bázisú disztró és nem egy rpm-es pl.

tudnia kell a dpkg igencsak szigorú verziókezelését és ugye csinálnia kell changelog-ot meg rules fájlt.

Egy tetszőleges debian disztróbeli csomagot, ha letölt valaki , és pl. dpkg-deb -R el kicsomagolja,
és belenéz mi a DEBIAN könyvtár tartalma, azért nem egy ördögtől való dolog megérteni, hogy mi mit jelent.

Akár mintaként is használható, ha valaki deb csomagot akar készíteni.

Meg egy md5sums fájl is szerintem célszerű.
De ez lehet,hogy maszek rigolya.

Bár az md5sums megléte sajnos disztróbeli csomagoknál sem 100%, ami azért pl. szerintem kellene.
Legalább azokban, ami binárist is tartalmaz.

de ez megint offtopic.

Tudom, hogy vannak gondok az md5-el, de semminél több.
Igen tudom,
hogy a disztró Packages-ben amúgy is kell legyen sha,sha256, de az csak magát a csomagot ellenőrzi,
a kicsomagolt tartalmat már igazából nem.

Tehát ha "telepítés" után, valaki módosítja a felpakolt binárist - mondjuk nem kívánt módon -,
akkor ott a rendszeren már csak az - dlocate pl. - md5check marad.

És ha valami gond van az egyik csomag tartalmával, ha valaki mégis reparált vele a célgépen,
akkor dlocate -md5check (csomagnév)-el könnyebb leellenőrizni, hogy akkor most mi is a nagy helyzet.

És melyik fájlba piszkáltak bele.

Jó egy dummy csomagnál mondjuk nem kell, de mikor egy csomag binárist tartalmaz, és nincs benne, hát nem tudom...

Ezt mondjuk elárulhatnád disztrókarbantartóként, hogy mitől függ, hogy raknak-e bele, vagy sem.

--------

Nem vezetek...Jobb így. Nekem is
meg mindenki másnak is.

"Nincsenek. De a "saját" repó, és publikus repó , meg a disztribúciós repo között azért van különbség."

Van, hogyne lenne. De a kérdést azért tettem fel, mert nagyon más egy rendes archive-ot karban tartani és rendesen frisíteni a csomagokat mint az, hogy egyszer sikerült egy source-ot becsomagolni.

A disztrók "mindenféle belső szabályai" nem amolyan légbőlkapott hülyeségek. Ugyanezeket a szabályokat te magad is felállítanád egy idő után, ha komoly ügyfeleket szolgálsz ki.

"lehet, hogy elsőre frászt kap tőle, "

Igen, és szépen el is ballag. Ezért nincsen százezerszámra app a .deb/.rpm alapú desktop linuxokra.

" nyilván nem a belépő alkalmazásfejlesztők játszótere."

A debian nem...de az Ubuntu viszont egy debian downstream disro és ameddig 100%-ban a debian csomagkezelési technológiáját örökli és kínálja fel egyetlen lehetőségként addig az Ubuntu sem lesz a belépő alkalmazásfejlesztők játszótere. Ez pedig nem jó! Mert azt szeretnénk ha az lenne. Ameddig nem az addig a kezdő fejlesztők mennek máshova és erősítik a többi platformot. Jó ez nekünk? Szerintem nem.

"Én csodálkoztam is anno az ubuntu indulásakor, hogy deb bázisú disztró és nem egy rpm-es pl."

Ez egy döntés volt akkor... igazán nem hiszem, hogy nagyon más lenne a helyzet ha .rpm lenne most.

"Egy tetszőleges debian disztróbeli csomagot, ha letölt valaki , és pl. dpkg-deb -R el kicsomagolja,
és belenéz mi a DEBIAN könyvtár tartalma, azért nem egy ördögtől való dolog megérteni, hogy mi mit jelent."

Persze, hogy nen ördögtől való. De ha egyszer meg lehet úszni nélküle akkor miért pocsékolja erre az időt az egységsugarú fingó app fejlesztője?

"Ezt mondjuk elárulhatnád disztrókarbantartóként, hogy mitől függ, hogy raknak-e bele, vagy sem."

Egyéni gusztus kérdése... ha kötelező lenne akkor rakna bele mindenki.

> Persze, hogy nen ördögtől való. De ha egyszer meg lehet úszni nélküle akkor miért pocsékolja erre az időt az egységsugarú fingó app fejlesztője?

Tényleg iszonyatosan bonyolult egy dh_make meghívása. Minden esetben, amikor ilyet csináltam, majd' bele is szakadtam. Ha meg ennél igényesebb Debian csomagot akarsz csináltatni, akkor inkább kulturált IDE-támogatást kéne csinálni, és nem még jobban eltávolodni a többi disztribúciótól és még jobban fragmentálni...

Kicsit kellemetlenül érzem magam, hogy a harmadik alkalommal kell feltennem ezt a kérdést: Te melyik disztróban, mely csomagoknak vagy a karbantartója?

Csak mert a dh_make lefuttatása tényleg ne nagy mágia, de egy csomag karbantartása ugye messze nem merül ki abban, hogy 0.1-es verziót egy templétre ráhúzzuk.

Amúgy az Ubuntu SDK-ban van .deb csomagolásra támogatás. Onnan tudom, hogy én csináltam. De pont ezért mondom, hogy a .deb csomag formátumának a karbantartása automatikus toolokkal messze nem triviális.

De amúgy van itt egy félreértés... Szóva te is és bárki is nyugodtan csináljatok .deb csomagokat Ubuntu alá. A .deb támogatása _SOHA_ nem fog megszűnni az Ubuntu alatt. Ha valaki a .deb formátumra esküszik akkor uccu neki, csinálja.

"A .deb támogatása _SOHA_ nem fog megszűnni az Ubuntu alatt"

Már a hír eleve _rosszul_ lett megfogalmazva: "Az Ubuntu Desktop Next .deb csomagformátumról Snappy-re vált "

Mert pont hogy _nem vált_! Egyszerűen csak berak pluszba egy másik lehetőséget a külső programok egyszerű telepítésére.

"Utópia"

Épp mivel nem lehet utópiákat elvárni, ezért is lehet jobb a Snappy.

Pl. egy framework-ből mondjuk három verziót tartanak karban, egy LTS-t, egy Stabil-t meg egy Test-et.
Egy-egy app készítő meg eldöntheti, hogy melyik framework-öt szeretné használni.
Ha az LTS-est választja, akkor ritkán kell az app-ját módosítgatnia, viszont a framework új tudásait is csak erős késéssel tudja használni.
Egy Test-esnél meg pont fordítva, up to date tudja a framework új tudásait használni, viszont az új framework verzióhoz állandóan igazítania kell a programját.
Akár az app készítője azt is választhatja, hogy az app-ját is három verzióban készíti el, így a felhasználó is választhat, hogy az OS-ére melyik verziójú app-ot rakja fel.

Ezzel minden szereplő csak nyer. A disztribúció készítő, az app készítő és a felhasználó is.

az egyszeri usernek épp nem jelentett problémát a deb csomagok használata, pláne ha apt-get plusz vmilyen gui szoftverközpont is tartozik hozzá. a csomagkarbantartóknak több munka leellenőrizni rendesen a függőségeket. ellenben pont ez volt a deb alapú disztribúciók előnye az rpm disztribekkel szemben.
ez a snappy minden függőséget mellékel amire az alkalmazásnak szüksége van. remek! de hogyan lesz megoldva a snappy-ba programcsomagonként akár több példányban is bepakolt függőségek biztonsági frissítése?
egyszerű programcsomagocskáknál nem lesz gond, de összetett, nagy mennyiségű függőséggel rendelkező csomagoknál mi lesz?

A függőségek nem úgy szűnnek meg, hogy hirtelen nem lesznek és punktum. A csomagokon való függőségeket a framework-ök váltják fel. Vagyis az alkalmazás maga határozza meg, hogy milyen keretrendszerekre van szüksége. A keretrendszerek pedig pontosan ugyanazok a függőségek lesznek mint eddig, csak egységesen kezelve és verziózva. De ezen épp most dolgozunk. Nem triviális feladat.

vegyünk egy példát.
valamilyen kommunikációs program, ami egy eddig is nyílt, deb csomagban is elérhető crypto libet használ függőségként. az eddigi modellben az alkalmazás eredeti fejlesztője megírja/frissíti a kommunikációs alkalmazását > ezt a debian vagy ubuntu maintainer deb csomagolja, beállítja a crypto lib és egyéb lib függőségeit. a crypto libet hasonló módon fejlesztik, majd csomagolja az ubuntus csomagkarbantartó.
jön egy sérülékenység ami a crypto libet érinti. javítja a crytolib fejlesztője és ezt csomagolja biztonsági frissítésként az ubuntus csomagkarbantartó. ha a kommunikációs program karbantartója épp nyaral akkor sincs probléma, mögötte kicserélődik a sérülékeny cryptolib.

az új Snappy modellben egy csomagban benne van a crypto lib a kommunikációs programmal. ettől függetlenül jelen lehet még több példányban ha más program is használja azt a libet. ugyanannál a sérülékenységnél most viszont a kommunikációs csomag karbantartójának kell frissítenie a cryto libet, és mellette párhuzamosan a többi olyan csomag karbantartójának is akinek a programcsomagja ezt a libet használja.

én ezt nem nevezném az optimális fejlődés irányának.
pont az egyik előnye volt eddig a gnu/linuxoknak, hogy az egymásra építő programcsomagok miatt kisebb volt a teljes rendszer, és ami ennél fontosabb, a rendszer minden eleme megkapta a szükséges figyelmet a karbantartók részéről. nem kellett párhuzamos munkát sem végezni. de ha valamelyik csomagkarbantartó úgy látta jónak, eddig is megvolt a lehetőség statikus linkelésre.

Próbálkozott valaha, valaki azzal, hogy a semver szerint-i verzióra dependeljen, s egyszerre több lib is fent lehessen?

Tehát ha én a libsth 3.* verziójára dependelek, akkor a 3.0 is ugyanúgy jó, mint a 3.9.13
Ellenben a libtsh 3.1.* csak a 3.1.0-3.1.sok verziókat fogadja el.

Nyilván, ehhez normális semver használat kéne mindenhol, nem pedig „nemszeretemanagyszámokat”, vagy „mostéppkettőezertizenötáprilisvan” verziózás.

Biztos van annak valami oka, hogy nem így megy. Miért?
--
blogom

Az egyik szélsőség pont ugyanúgy gáz mint a másik... ahogy a full statikus binárisok is furcsák, ugyanúgy az is szopóroller tud lenni, ha te ártatlanul megírsz egy frankó alkalmazást amire egy baromarcú géniusz szétbarmol egy függőséget alattad. Láttunk már ilyent, ugyebár.

Ilyenkor mindig egy kicsit zavarban vagyok. Egyrészt mert kicsit cikinek érzem, hogy 16 év Debianozás után amiből 7 évet konkrét Debian platformok fejlesztésével töltöttem valaki elmagyarázza nekem a függőségek lényegét :) Dehát sosem árt ismételni. Másrészt azért érzem furcsán magam, mert pont abban a hozzászólásban írtam le a választ erre a hozzászólásodra is amire te ezt írtad. Dehát ismétlés a tudás anyja... szóval vannak/lesznek framework-ök amiket az alkalmazások köbetelhetnek. Ezen framework-ök tartalma pont ugyanúgy van karban tartva mint mostanság és ezelőtt a disztrók. Ennyi. Senki ne gondolja, hogy ez a snappy dolog most porba zúz mindent :)

Ha megteheti egyszerűen, és nem fogja a készítőt senki 3.14csán rúgni miatta, hogy maga alá pakoljon egyébként önálló életet is élő libeket, akkor meg fogják csinálni, hogy a fejlesztőnek "worksforme" libeket, mint saját függőségeket hozza magával a motyó. A másik lom megy egy másik verziót. A harmadik meg használja az önállóan települő libet. Igen, most is megtehetik, de esélyes, hogy valagon billentés terhe mellett.

elolvastam még egyszer a hozzászólásodat de sehol nem találtam benne választ, de még utalást sem megoldásra az általam írt problémával kapcsolatban. ez nem egy akadémikus case study, gyakorlatias példa. más tudás kell egy grafikusan jól megtervezett, user számára jól átlátható kommunikációs program megírásához és más, bizonyos szempontból komolyabb tudás kell egy titkosító program, lib megírásához. természetesen csomagkarbantartóknál is előnyös ha értik és átlátják annak a programnak a kódját amit csomagként karbantartanak.
tehát ha jön egy cryto lib sérülékenység ami érinti a kommunikációs programot, hogyan lesz gyorsan javítva ebben az új snappy rendszerben?

ha már újra elolvastam a hozzászólásodat, néhány további megjegyzés.

"Ugyanakkor végignéztem a Maemo nyüglődését a dpkg alapú rendszerfrissítésekkel."

A Maemo "nyűglődésének" nem technikai okai voltak, a Nokia pazar bénasága vezette vakvágányra. a Nokia által Internet Tabletnek nevezett még nem mobil N8xx cuccosok alatt sikeresen muzsikált. az N900 nokiával sem volt technikai probléma. aki hozzájutott elégedett volt vele. már ha hozzájutott. marketingmunka Nokia N900hoz nem létezett. végülis csak a Maemo mobiltelefonos bevezetéséről volt szó, minek reklámozni?! szabadalmi para miatt kihagyta a Nokia a multitoucht, konzervatív rezisztív érintőképernyőt kapott az N900 capacitív helyett.

"Tegye fel a kezét az a Debian/Ubuntu felhasználó aki mondjuk 3 éves távban még nem futott bele abba, hogy a terminálból kelljen dpkg --force-all típusú buherákkal meg repó ki - repó be varázslatokkal helyrehozni egy-egy furcsaságot ami a dist-upgrade (nem release upgrade!) után"

jövő hónapban lesz 17 éves a Debianom. legalább egy évtizede nem volt force típusú problémám. amikor volt, annak oka mindig külső forrásból származó zárt kódú csomag volt. az ilyenekre szerencsésebb volt már akkor is a Loki installer, ami tök jól megfér a dpgk/apt-get mellett.

"Szóval... szép és jó a dpkg meg a .deb, de sajnos a mai elvárásoknak nem felel meg. Ha nagy szavakat akarnék mondani akkor azt mondanám, hogy valahol ez volt a gátja a Linux desktop komoly sikerének. A .deb/dpkg világban nem lehet pengén gyors itterációkban kitolni az újabb verziókat."

azt állítani, hogy eddig a deb volt a linux desktop sikerének gátja imho erős kijelentés. miért nem futott be egy rpm linux desktop ha valóban a deb volt az akadály?
véleményem szerint teljesen más okok álltak a háttérben. leginkább egy ellenérdekelt konkurens hathatós lobbizása. amióta a Valve felfedezte magának a linuxot gaming platformnak sorba jönnek ki a kereskedelmi játékok linuxra. ráadásul a Valve a "konzervatív" Debian desktop linuxot választotta saját SteamOSe alapdisztribúciójaként. ez főleg játékokat jelent, de ahogyan kereskedelmi játékok úgy egyéb programok is utat találhatnak linux desktopra. csak kell egy olyan fajsúlyos cég mint a Valve játékban.
imho ha lesz ilyen, az szintén a Valve lesz. a steamen már vannak játékok mellett egyéb programok is, bár egyelőre kis számban.

"Na és akkor ezt még csak a disztró meg az upgrade probléma. A legnagyobb probléma a .deb világgal az a biztonság. Van mondjuk egy átlag Debian/Ubuntu installod... ott figyel az összes kontatod meg leveled a ~ alatt. Aztán letöltesz egy fingó alkalmazást .deb formában. Installod, megnyitod.. nyomkodod, röhögsz
Pont ahogy kell. Ki és hogyan garantálja, hogy ez a blazírt app nem nyúlja le az összes kontaktodat és nem tolja el egy csendes órában egy kínai szerverre?"

Windowson sincs erre semmilyen védelem. bármilyen telepített alkalmazás hozzáfér a user összes állományához. sőt van szép számmal win program ami adminisztrátor jogot is követel magának. ez nem volt ok a desktop Windows sikere ellen.
amikor a Maemo megjelent még Symbian uralta a smartphoneokat és mögötte a második OS a Windows Mobile volt. egyikben sem volt hathatós védelem erre a problémára. az Android valóban frappáns megoldást nyújt a "kémkedő figó alkalmazásokra", de ne állítsunk olyat, hogy enélkül esélytelen lett volna a sikerre egy mobil vagy akár asztali OS. korábban egyik mobil vagy asztali OS sem kínált megoldást erre a problémára.
érdekesség. jó régen volt egy windowsos istenszimulátor játék ami szándékosan fésülte át a kontaktjaidat, hogy a játék szereplői az ismerőseid nevét kapják.

"Lehet persze .deb csomagokat csinálni appokank, de minek, ha ott van a sokkal kényelmesebb megoldás."

ha ennyire androidos rendszert akar faragni az Ubuntu a saját linuxából, akkor nem lenne egyszerűbb android kompatibilis alrendszert csinálni az Ubuntuba?
egyből lenne millió feletti programcsomag készen. több százezer új ubuntus program szép cél, de elérni nagyon nehéz. a MS a milliárdjaival is csak vért hugyozva tudta feltolni a WP appok számát százezer felé úgy, hogy a valóban jó minőségű és hasznos appok aránya messze elmarad az androidétól.
továbbá van egy fontos képessége az androidnak, amit az Ubuntu a snappys dologgal sem tud megoldani, ez a hw platformfüggetlenség.

> amióta a Valve felfedezte magának a linuxot gaming platformnak sorba jönnek ki a kereskedelmi játékok linuxra

Nem ismerem a Valve-t, de ha jól sejtem, valami Steam a csomagkezelőjük vele, nem dpkg/rpm. Ha ez utóbbiak alkalmasak lennének, miért van a Steam..?

> Windowson sincs erre semmilyen védelem. bármilyen telepített alkalmazás hozzáfér a user összes állományához. sőt van szép számmal win program ami adminisztrátor jogot is követel magának. ez nem volt ok a desktop Windows sikere ellen.

Ellenben hány trójai szoftver vitte sikerre emiatt. :)

> továbbá van egy fontos képessége az androidnak, amit az Ubuntu a snappys dologgal sem tud megoldani, ez a hw platformfüggetlenség.

Az Ubuntu is platformfüggetlen, illetve multiplatform.

> az új Snappy modellben egy csomagban benne van a crypto lib a kommunikációs programmal
Benne lehet, de lehet, hogy framework-ként használja. Szóval az eddigi modell is működhet, csak épp van egy új: a zárt forráskód. Ott a maintainer/packager tehetetlen. Egyetlen megoldás, ha izoláljuk az alkalmazást és innen a fejlesztő felelőssége az, hogy szállítsa a javítást. Nyaral? Hát jó, közben kitör a pánik, az emberek nyomják az uninstallt és bedől a biznisze mire visszér.. Ha ez neki megéri.. :) Nyílt forrásnál bárki kiadhat belőle egy javított verziót.

A karbantartók szerepe teljesen jelentéktelen lenne a zárt forrású alkalmazások mellett, ezekre pedig az Ubuntu igényt tart. A nyílt forrású appoknál pedig simán működhet az, hogy az upstream maintainer mondjuk megkéri az eddigi Ubuntu karbantartót, hogy csomagolja helyette és akkor semmi se változott. Ha meg akarja, akkor saját kezébe veszi.

Az eddigi rendszer ott hibázott, hogy ha én írtam egy alkalmazást, azt csak igen macerásan tudtam eljuttatni oda, hogy apt-get -tel bárki telepíthesse - rossz esetben ez évekbe tellett.

Tegye fel a kezét az a Debian/Ubuntu felhasználó aki mondjuk 3 éves távban még nem futott bele abba, hogy a terminálból kelljen dpkg --force-all típusú buherákkal meg repó ki - repó be varázslatokkal helyrehozni egy-egy furcsaságot ami a dist-upgrade (nem release upgrade!) után.

\o/

A legnagyobb probléma a .deb világgal az a biztonság. Van mondjuk egy átlag Debian/Ubuntu installod... ott figyel az összes kontatod meg leveled a ~ alatt. Aztán letöltesz egy fingó alkalmazást .deb formában. Installod, megnyitod.. nyomkodod, röhögsz :) Pont ahogy kell. Ki és hogyan garantálja, hogy ez a blazírt app nem nyúlja le az összes kontaktodat és nem tolja el egy csendes órában egy kínai szerverre?

Ezt nem értem, hogy miért a csomag formátum hibája. Elmagyaráznád, hogy mire gondoltál? Egy tetszőleges másik csomagformátum mitől jobb? Mi az, ami a deb formátumból hiányzik?

Ezt androidon például megoldották. Lehet csinálni például egy központi szolgáltatást az oprendszeren belül, ami tárolja a szenzitív adatokat, és valami szabványos API-n keresztül publikálja őket a többi program felé. Ha hozzá akar férni ezekhez egy program, akkor pedig a felhasználó kap egy ablakot, hogy "a fingós app elolvasná az emailjeid, engeded-e? igen/nem/csak most az egyszer". Nem tudom, hogy hogyan gondolják megoldani a valóságban, ez csak egy lehetőség, de _technikailag_ ezt nem lehetetlen megugrani.

androidon simán csak a /data könyvtárban vannak a user adatokat és app beállításokat tartalmazó fájlok.


drwxr-x--x app_173  app_173           2014-03-16 17:55 org.hystudio.android.dosbox
drwxr-x--x app_201  app_201           2014-05-19 03:55 org.mapsforge.applications.android.advancedmapviewer
drwxr-x--x app_64   app_64            2015-04-11 07:55 org.mozilla.firefox
drwxr-x--x app_191  app_191           2015-01-24 22:19 os.tools.scriptmanager
drwxr-x--x app_154  app_154           2014-04-11 05:55 ru.zdevs.zarchiver
drwxr-x--x app_190  app_190           2014-06-15 22:50 stericson.busybox

ebből a példából látható, hogy minden alkalmazáshoz tartozó könyvtár az app "usernevére" és csoportjára van beállítva. ezért a "fingós app" jogok híján sem tudja olvasni az email alkalmazásod által helyben tárolt leveleket és címeket. ha mentesz egy képet böngészőből az a minden app által olvasható /sdcard/download könyvtárba kerül, vagy rákérdez a böngésző hova mentse.

Androidon az alkalmazás telepítésekor látod és elfogadod, hogy milyen szenzitív információkhoz akar hozzáférni majd, úgy mint GPS, telefonkönyv, SMS, hívásinformációk stb. Egyes android változatok alatt (pl. CM) ezt finoman lehet szabályozni telepítés után, akár menet közben is.

Joana Rutkowska Qubes OS-ét próbáltam, mert tetszett az ötlet. A notebookomban CoreI7-es processzor van 16G RAM-mal, és a lefuttatott tesztek alapján minden létező virtualizációt támogató technológiát ismer és azok be is vannak kapcsolva. Ennek ellenére a felinstallált Qubes OS használhatatlanul lassú volt. Két nap után megváltunk egymástól.

A Xen egészen egyszerűen túlságosan nagy overhead desktopon a cgroups-okra építő megoldásokkal szemben, és ha nem általános virtualizáció kell, hanem linux felett csak linuxot akarsz futtatni, akkor gyakorlatilag nem ad semmi pluszt.

Mit értesz rollback alatt? A Debian-ra való esetleges visszaállást?

Én mindig azt használom, ami az igényeimnek leginkább megfelel. Ha kényelmetlen lesz az Ubuntu, simán dobom. Nekem ez nem lesz probléma.

Nem ragaszkodok vallási okokból semmihez. Hiszen emlékezhetsz. iPhone-ról is simán váltottam Androidra és ha egyszer nem leszek elégedett, simán fogok akár Androidról visszaváltani iPhone-ra is.

--
trey @ gépház

Nem tudom pontosan, hogy mire gondolt, de talán arra, hogy nem lehet csak úgy visszavonni az utolsó lépést.

Ha a fenti feladatot kellene most pl. lejátszanom, akkor az új kernel telepítése, a régi csomag eltávolítása és reboot után nem tudok mondjuk egy gombnyomással visszaállni.
Meg kellene nyitnom az aptitude logot, megnézni, hogy az utolsó változás az verzióX -> verzióY volt, ezután kézzel azt kéne mondanom, hogy akkor telepítsd a verzióX-et. Akár a csomagot magát a /var/cache-ből dpkg-val, akár netről letöltve apttal vagy aptitude-dal, ez most részletkérdés.

Tehát igen, nem tetszik és visszarakom. Működik, de azért el fogok vele tölteni mondjuk 5-10 percet, pedig mehetne automatizáltan is.

Mondjuk ez nem a dpkg hibája, de pl. az aptitude kezelhetné ezt simán.

(Persze lehet, hogy tudatlan vagyok és tud ilyesmit alapból valamelyik a dpkg/apt/aptitude közül, de amikor elkezdtem használni, nem tudták én meg nem szoktam igazából nézni, hogy na, mik változtak, milyen új dolgokat lehet már csinálni a csomagokkal).

Pár csomagnál időnként működik, ami pl. másik repóban van.

Pl. jelenleg debian stable-nál iceweaselből pl. vissza tudod rakni az eggyel korábbit. aptitude rámész a csomagra, megkeresed a rendelkezésre álló verziót, és kiválasztod amelyik kell.

Ez persze nem rollback, kétségtelen. De ha nagyon akarsz körbe tudod járni más módszerrel.

de azért el fogok vele tölteni mondjuk 5-10 percet,

Nem feltétlen biztos, hogy a teljes csomagkezelő rendszert ezért szét kell verni.

--------

Nem vezetek...Jobb így. Nekem is
meg mindenki másnak is.

Na ja. De a repackage is ügyes, vagy az aktuális "kedvenc" a yum-debug-dump /yum-debug-restore páros; az utóbbi csak a RHEL6-os csomagban van benne, de RHEL5-re visszamásolva is teljesen jól teszi a dolgát, úgyhogy a get-selections/set-selections is megkapta a párját rpm vonalon :-P

Befrissül a kernel, majd neked nem teszik és visszarakod régit.

A kernel most pont rossz példa volt.

Én kernelt úgy szoktam frissíteni, mivel saját fordítást használok, hogy teszek mellé spéci extraversion-t amiről megismerem, és így nem zavarja a meglevő kernelt, modulokat, stb, akkor sem ha egyébként valami miatt verziószáma ugyanaz lenne.

De általában nincs így, olyan gyakran nem frissítek kernelt.

Szerintem működő dolgot nem kell mindjárt elrontani. :-))

Meg deb csomagkezelés alatt is vannak - kétségkívül gány elismerem :-) - módszerek,
amivel lehet hasonló hatást kiváltani.

Nem szép megoldás egyik-másik, de gyorsan megvan, és működik. Pl. lirc csomagból én még a régi 0.8.x-et használom pedig a 0.9 van a debianban. Csak nekem nem tetszik.

És mégsem aggódom,hogy egy frissítés során a rendszer esetleg lecseréli. nem fogja, eddig sem tette. :-))

Pedig hold-ra sincs(enek) beállítva a nevezett csomagok.

--------

Nem vezetek...Jobb így. Nekem is
meg mindenki másnak is.

Az, hogy a dpkg kimenetele nem mindig egyértelmű. Pl. lehet olyan, hogy a csomag fel van telepítve, de nem sikerült beállítani. Azért egy automatizált környezetben ez nem feltétlen vicces.
Ha jól tudom, a Snappy nem így működik, vagy sikerül teljesen feltelepíteni a csomagot, vagy marad a korábbi állapot.

-----
„Egy jó kapcsolatban a társunkat az ő dolgában kell támogatni, nem a miénkben.”
rand() a lelke mindennek! :)
Szerinted…

Nem tudom, hogy a 3rd party gyártók fogják-e támogatni, a .deb és a .rpm formátumokat is lassan vezették be.

Én nem ismerem a Snappy-t, de nehezem tudom elképzelni, hogy a .deb-nél lehet jobbat, okosabbat csinálni :)

Olyan egyszerű a Snappy, mint a faék, szerintem nem esik nehezükre majd bevezetni, sőt a 3rd party gyártók számára ez kifejezetten könnyebbség lesz.

Én sem ismerem nagyon, amit hallottam róla:
a) egy könyvtárba kerülnek a program dolgai (ez egy kissé szembe megy a Linux (Unix) alapfilozófiájával)
b) akár egyszerre több verzió is lehet benne
c) tartalmazza (tartalmazhatja) a program függőségeit
d) tranzakciósan telepíthető (vagy sikeresen települ, vagy egyáltalán nem települ, nincs inkonzisztens állapot, visszavonható a telepítés [rollback])
e) könnyen sandboxolható
f) a csomag read-only-ként települ.

(Olyasmi, mint az Android-os apk.)

Ennek vannak jó részei és vannak megkérdőjelezhető részei, én mindenesetre kíváncsian várom mi lesz belőle.

Ráadásul a DMG-ből lehet futtatni is az alkalmazást, amit nem muszáj "feltelepíteni" sem (legalábbis Tigerben még ment így). Persze így a munkamenet során "elkövetett" beállítások elvesznek. Szóval voltaképp van egy izolációs réteg jellegű funkcionalitása is a dolognak... Mármint erre is használható, és akkor nem kell Docker, meg egyéb tool, ha épp csak rá akarok nézni egy legfrissebb Firefoxra, vagy akármire. Ha jól megoldanák (ezt akár jól is megoldhatnák), akkor talán lenne arra lehetőség, ami minden Linuxot ellenző ember egyik fő ellenérve. Talán beállna mögé a többi nagy disztró is, esetleg lenne végre egy konzisztens csomagkezelési forma, nem lenne .deb, nem lenne .rpm, hanem csak lenne ez és kész. Na jó, letöröltem a meghatottság könnyeit. Mindenképp egy valóban funkcionális, építő jellegű kezdeményezés a Linux közösség javára, amennyiben nem zárják be a .deb ökoszisztémába. De még előbb azért elolvasom az angol nyelvű forrást, mielőtt elragadtatnám magam.

CB RIP

Próbálgatta itt valaki a desktop-next felületet?
Az egész egy használhatatlan bugkupac, aptitude nélkül fel sem tudtam rakni, mert törött volt a 15.04-en pár héttel ezelőtt.
Így is használhatatlannak bizonyult, de ha még a deb -et is dobják akkor kizártnak tartom, hogy egyhamar be tudnák állítani default felületnek. Már pár dátum ki volt tűzve, az utolsó az a 16.04 az első pedig a 13.10 volt ha jól rémlik.

Legyen a systemd része a csomagkezelő és csókolom. Olyan profik fejlesztik úgyis, hogy hibát még senki nem látott ;-)

--
A főnököm mindig megtartja amit ígér, ha pénzt ígér azt is!

Szoval .deb alapon nem lehetett meglepni az Ubuntu play-t :)

---
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....

A hozzászólásokat olvasva azt érzem, hogy a hozzászólók döntő többsége egyáltalán nem vette a fáradtságot, hogy utánaolvasson valami hivatalos oldalon ennek a Snappy dolognak. De az észosztás, az megy…

-----
„Egy jó kapcsolatban a társunkat az ő dolgában kell támogatni, nem a miénkben.”
rand() a lelke mindennek! :)
Szerinted…

Ez a snappy történet azért még eléggé mozgó valami. A snappy-t eredetileg az IoT (Internet of Things) divájszokra találták ki. Nevezetes arra, hogy ha valaki akar mondjuk egy RaspberryPi alapra egy játék robotot építeni, vagy egy faék egyszerűségű média boxot csinálni. Esetleg egy IP kamerás megfigyelő és rögzítő rendszert összerakni akkor ezekre legyen egy Ubuntus megoldás.

Szóval, hogy ne az legyyen, hogy minden hardver buherátor maga csihol össze valamit, hanem legyen az, hogy a felsorolt komponensekkel rendelkező és adot architecturájú kis eszközökre itt van tessék egy Ubuntu Core és erre lehessen csinálni amolyan bővítéseket amik snapp csomagként hajtanak meg perifériákat vagy használnak ki erőforrásokat.

Például ha van egy RPi boardod akkor arra egy kutyaközönséges Ubuntu Core az van... kernel, drájverek, kutyafülye. Na ez read only, ne kelljen vele szopnia a fejlesztőnek. Jönnek rá az image based update-ek mint a telefonre. Működik mint a vasúti klotyó. Ha mondjuk GPIO-ra ráköt a fejlesztő eg raklap szenzort és nyomógomb hegyeket... akor majd ír arra valami saját szoftvert. Na ennek a szoftvernek az életciklusát nem akarja a disztróhoz kötni. Minek is tenne ilyent? Na ezt a szoftvert nem akarja .deb-be kínozni és nem akar szívni a disztróba intergrálással, saját deb repót csinálni meg végképp nem akar. Ezek az fejlesztők nem akarnak ilyennel foglalkozni. Ők megírják a saját kódjukat és be akarják tolni a store-ba. A platformon pedig júzer szpészben szépen lehúzzák a snapp csomagot a store-ból ami települ a júzer hómjába és csókolom.

Az ilyen kis eszközökre ez a modell. Amit most kitaláltak az az, hogy ezt a modellt adaptáljuk az asztali Linuxra.

Szerintem érdekes felvetés és nem is tartom hülyeségnek. Főleg, hogy nettó ostobaságnak tartom, hogy mondjuk a levelező kliensem miért nem a $HOME alatt lakik és miért kell root jog a telepítéséhez. Legfőképp pedig miért fér hozzá bármelyik másik csomag csont nélkül a levelezésemhez. Mert ugye azt ember el nem hiszi, hogy a debian alatt minden csomagnak minden sorát minden release-nél átnézi egy kompetens mérnök? Maradjunk annyiban, hogy azért nem volt ilyen app adatlopás botrány a desktop linuxokon, mert alig van egy tucat asztali app az összes Linux desktopra :D De ha lenne akár csak tízezer... akkor kérdem én, ki nézné át a Debiannál mind a tízezer minden rilízének minden sorát? Elég lenne az első tízezer Debian app közé 4-5 olyan app ami eltolja Kínába a levelezésed és reszeltek a desktop Linux történetnek.

Szóval szeretnénk marhára már, hogy legyenek menő appok a desktop Linuxra, csak éppen azt nem tudják sokan, hogy mi lenne ha tényleg lennének... Én tudom, káosz lenne meg oltári nagy balhé... szóval ha tényleg komolyan vesszük a linux desktop ambíciókat akkor nagyon kell valami olyasmi mint a snappy.

Egy ártatlan kérdés: a systemd-s arcok hasonló terveivel nem akarjátok kicsit összébb hozni? Fentebb linkeltem, gyakorlatilag ők is ugyanezt találták ki: alaprendszer, felette framework, felette alkalmazás, mellette home, eléggé btrfs és systemd-centrikusan mondjuk, célként a disztrók "felettiséget" kitűzve [nagyjából mindegy, hogy milyen distró fut "natívan", az a kérdés, hogy maga az alkalmazás melyik os/framework/... image-t kérte be magának].

hogy mondjuk a levelező kliensem miért nem a $HOME alatt lakik

Mondjuk nem nagyon gond, amíg a /home-ra adminként lehet egy noexec-et tenni, sokfelhasználós gépen azért nem örülnék, ha mindenki kénye-kedve szerint telepítgethetne mindenfélét (ez ugye Win-en "szépen működik", aztán jönnek a support ticketek, hogy lelassult a gép... na ja, mert feldobta a Chrome-ot (üresjáratban 4-5 process), 2-3 Dropbox-klón kliensét, etc, mert azoknak nem kell rendszergazda jogkör...)

Elég lenne az első tízezer Debian app közé 4-5 olyan app ami eltolja Kínába a levelezésed és reszeltek a desktop Linux történetnek.

Ez mondjuk FS névterekkel/AppArmor-ral/SELinux-xal AFAIK megoldható is lenne.

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

Igen, elolvastam amit linkeltél és kicsit cikinek is éreztem, hogy nem tudtam erről. Bár én nem vagyok snappy core fejlesztő... szerintem ők azért tudnak erről és egészen biztos vagyok, hogy ez a két koncepció tulajdonképpen egy. Legalábbis azt pontosan tudom, hogy azok az Ubuntus (cselesen Debian kalappal) arcok akik a systemd témában állást foglaltak, érveltek, szavaztak azok most nyakig benne vannak a snappy fejlesztésben. Szóval értelmes arcok dolgoznak ezen.

"sokfelhasználós gépen azért nem örülnék, ha mindenki kénye-kedve szerint telepítgethetne mindenfélét"

Hát ugye egy sokfelhasználós Linuxon sudo jog nélkül meg semmit nem telepít az ember :) Ami azért lásuk be, eléggé erőszakos megelőzése a problémának :)

De amúgy pont a mobil Linux vonalon azért megtanultuk, hogy full multi task az nem játszik. Szóval, szép és jó dolog a multitask, de ha egy alkalmazást nem használunk akkor ezt szépen valahogy le kell keverni, mert a világ összes memóriája és CPU-ja nem elég ha tucatszám futtatják az appokat. Ami nem olyan nagy gáz, ha a csóva dróton jön, de amikor ki van mérve a milliamperóra akkor azért más a leosztás.

Szóval énúgy vagyok ezzel, hogy az egész application lifecycle management is át van gondolva ezzel az új koncepcióval. Ez persze még nincs adaptálva a desktopra, de szerintem lesz.

Mindehhez csak annyit tennék hozzá, hogy dolgoztam pár helyen, ahol 1000+ desktopot kell menedzselni. Mindenhol az derült ki, hogy sokkal egyszerűbb az üzemeltetés (értsd: olcsóbb, mert kevesebb ember több desktopot menedzsel, mert gyakorlatilag nem kellenek integrációs tesztek), amióta a Microsoft App-V -t használnak, ami koncepciójában nagyon hasonlít a snappy-ra. Ezért én valahogy nem visszalépésnek érzem, hanem felzárkózásnak.

Maradjunk annyiban, hogy azért nem volt ilyen app adatlopás botrány a desktop linuxokon, mert alig van egy tucat asztali app az összes Linux desktopra :D

Web of trust.

---
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....