Megérkezett az OTA-9-es frissítés az ubuntus telefonokhoz

Ubuntu

A menet közben megjelent javítókiadás, az OTA-8.5 után ismét teljes értékű kiadással jelentkezik a Canonical az Ubuntut futtató telefonokhoz. Még nem jött ennyire izgalmas frissítés az eszközökhöz. Az OTA-9 ugyanis több, mint 250 javítással vagy új funkcióval érkezik. Ahogy arról már korábban beszámoltunk, a könnyebb beazonosíthatóság kedvért a korábbi, eszközönként eltérő kiadási számokat felváltotta az egységes OTA-szám. Most már ez található meg a Rendszerbeállítások/A telefon névjegye alatt.

Az OTA-9-es frissítés a következő eszközökhöz érkezik meg:

  • Google Nexus 4 (mako)
  • Google Nexus 7 (flo)
  • Bq Aquaris E4.5 (krillin)
  • Bq Aquaris E5 (vegetahd)
  • Meizu MX4 (arale)

A kiadás fontosabb javított hibái, új funkciói:

  • VPN támogatás (FONTOS: Egyelőre csak a funkcionalitás, illetve az indikátor támogatás készült el, a beállítófelület a következő OTA-val fog érkezni. Viszont egy prototípusa a felületnek addig is letölthető innen. [bejelentés])
  • A Bejövő/kimenő hívás, a telefonelőzmények, illetve az SMS/MMS üzenetek esetén végre fel van tüntetve, hogy melyik SIM kártyához tartoznak (csak több SIM kártya esetén)
  • Webböngésző: Már az alkalmazás kezeli a saját letöltéseit, illetve végre lehetőség van egy fájlt a Letöltések mappába letölteni, nem csak egy másik alkalmazásnak átadni.
  • Egyéni csengőhang megadásának lehetősége a Rendszerbeállítások/Hang alatt
  • Új Kamera alkalmazás, állítható a képek képaránya (4:3, 16:9), illetve kikapcsolható a zárhang
  • Frissebb Bluez5 Bluetooth implementáció használata
  • Névjegyek alkalmazás: Kiválasztható az alapértelmezett címjegyzék
  • Továbbfejlesztett vCard importálás
  • A lencsék (az Alkalmazások lencsénél is) frissítése esetén már nem törlődik, majd újra megjelenik a korábbi tartalom, hanem csak frissítésre kerül. Ez igen látványos pl. új alkalmazás telepítésekor. Az új ikon végre csak megjelenik a többi között, és nem az összes kerül törlésre, majd újra megjelenítésre
  • Új, 15.04.3-as keretrendszer
  • Egységesített, továbbfejlesztett „Bottom-edge”, azaz a kijelző aljáról indított gesztus
  • A Rendszerbeállítások/Fiókok alatt most már csak azok a fiókok látszanak alapértelmezetten, amikhez van telepítve olyan alkalmazás, ami használni tudja azokat
  • A lencséken működik a közvetlen zenelejátszás (most már nem kell megnyitni a Zenelejátszó alkalmazást)
  • Online fiókok: SASL autentikációs bővítmény engedélyezése
  • Rengeteg javítás az Értesítésrendszer körül
  • Új jogosultságkérő ablak
  • A böngészőnél a lapok közötti váltás animációja nem volt gördülékeny több lap esetén
  • HDR lehetőség kiszedése a Kamerából videózás esetén, hiszen olyankor nem használható
  • Gyorsbillentyű-, illetve fókuszkezelés körüli javítások asztali módban
  • Néhány alkalmazás többször is látszott a Rendszerbeállítások/A telefon névjegye/Tárhely menüpont alatt
  • Csak csatolmányt tartalmazó MMS üzenet esetén az értesítésnél csak a küldő neve látszik, az üzenet „törzse” nem
  • Videózás esetén a bekapcsolt lámpa/vaku kikapcsol, ha alkalmazást váltunk
  • Zenelejátszó: Az „Előző szám” gomb hosszabb megnyomása esetén most már a szám elejére ugrik az előző szám helyett
  • Letöltés esetén „hiányzó ikon” jelenik meg az Indikátoron
  • Autós Bluetooth-rendszerhez csatlakozáskor nem jelent meg a készülék töltöttségi szintje
  • Autós Bluetooth-rendszerről való lecsatlakozás után a hang nem váltott vissza a hangszóróra
  • Megszakított hívás utáni azonnali tárcsázáskor előfordulhatott, hogy „Nincs hálózat” hibaüzenet jelent meg, majd 1 másodperc múlva már minden jó lett
  • A tartózkodási hely már lokalizált címekkel (város, utca, stb) tér vissza a különböző lencsékhez
  • Rendszer szerte át lettek variálva a betűméretek, így most már mindenhol követi a dizájnban előírtakat
  • Alacsony töltöttségi szintnél most már hangjelzés is van az értesítésablak mellett
  • Hangerő-változtatásnál mostantól fel van tüntetve, hogy milyen eszköz hangerejét változtatjuk (Hangszóró és fülhallgató [„sima”, Bluetooth, USB])
  • A thai karakterek nem jelentek meg a webböngészőben
  • Számos változtatás a motorháztető alatt, beleértve a konvergenciát elősegítő változtatásokat is
  • Frissített fordítások

Ez a frissítés szintén a korábbiaknál már megszokott módon fog megjelenni. Fázisokban, 24 óra leforgása alatt lesz elérhető a felhasználók számára.

A javított hibák listája ezen, a kommitok listája ezen, a kiadási megjegyzések pedig ezen a linken találhatóak meg.

A magyar fordítási hibák itt jelenthetőek.

( pch v | 2016. 01. 27., sze – 18:16 )

Külső alkalmazások továbbra se tudják kezelni az értesítéseket?
A hangul hinába fut, ha nem látok értesítést :(

pch
--
http://www.buster.hu "A" számlázó
--

Amúgy mennyire használható? Gondolkodom az Ubuntura váltáson, de egyelőre nem merek belevágni.

----
"Mert nincs különbség: mindenki vétkezett, és híjával van az Isten dicsőségének. Ezért Isten ingyen igazítja meg őket kegyelméből, miután megváltotta őket a Krisztus Jézus által." (Róma 3.22-24)

Az en igenyeinet kielegiti:
- van rajta bongeszo
- a kozossegi appok mukodnek, twitter, facebook, g+
- gmail van rajta, meg nativ levelezo kliens is
- podcast lejatszo eleg jo, zenelejatszoval lehet zenet hallgani
- van ra egy csomo encsempencsem jatek, sok jo van kozte
- van document viewer
- nekem kicsit szet kellett szorni dolgokat kulonbozo cuccokra, ugyhogy lett evenote meg pockit accom
- nagyon kenyelmes a teminal

Ami hianyzik:
- biztos jo az a telegram chat, de senki sem hasznalja az ismeroseim koreben, van valami betas hangouts, de az nem kuldd notificationt, meg ha ugy dont a rendszer, hogy kidobja a memoriabol, akkor annak reszeltek, eszre sem veszed, hogy nem vagy online, a tobbi chat meg valami webapp, szoval kene valami nepszeru chat kliens
- ne csak a gyari appok kuldjenek notificationt
- normalis navigacio, ami van az nem igazan mukodott meg nekem
- a wifi transfer egy jo ftp szerver, de korulmenyes hasznalni, sec policyk miatt, es igy nincs ertelmes wifis file transfer
- a futo alkalmazasok nem szaggatnak, de betolteni oket neha sokaig tart, beallitasok rohadt lassu, galeria, camera app szinten
- valami sync megoldas, en most rsynccel nyomulok, de valljuk be ez nem valami proper megoldas

A legtobb app webapp, annak minden elonyevel es hatranyaval egyutt. Igazabol nekem vannak aprobb problemaim appokkal (ketto jut eszembe, a twitter appon valaki profiljat megnyitva, ha a tovabbi tweetekre megyek, akkor neha az utolsot nyitja meg, ill a podcastlejatszo, neha nem inditja el a lejatszast, as akkor ki kell kapcsolni, es remelni, hogy megjavul), meg sok mindent kicsit kerulouttal lehet megcsinalni, en egyutt tudok ezekkel elni, es nem akarnek visszamenni Androidra, mert hasznalni meg nagyon jo erzes, bejon a gesztus vezerles, nem szaggat, olyan fluid, plusz lehet lelkesedni a frissitesekre, mert van valtozas boven. :D

Big Data trendek 2016

Lassan egy éve használom elsődleges telefonként és meg vagyok vele elégedve. Van még pár gyerekbetegsége, de ha az ember utánaolvas, és együtt tud élni ezekkel, akkor teljesen használható a dolog. Meg szépen fejlődik a dolog, úgy érzem, hogy 1-2 éven belül le fogja vetkőzni minden ilyen gyerekbetegségét. Van egy Nexus4-esem a Bq mellett, azon mindig a fejlesztői kiadást futtatom, volt, hogy kölcsön adtam egy-két hétre ismerősöknek, mindnek az volt a véleménye, hogy a következő cserénél ott lesz az Ubuntus telefon a befutók között, csak legyen nagyobb a készülékválaszték. :)

Nekem a használhatóság határás súrolja, sajnos alúlról. BQ Aquarius E4.5-öm van, két sim-es életet élek.
Tetszik nagyon ez a felület. Először egy kicsit furcsa androidos telefon után, de miután megszokod baromi jó. Akksija nem nagyon merül. Kb egy hónapig használtam 'élesben'. Most csak akkor veszem elő, mikor frissítés jön ki, játszadozok vele egy kicsit.

Pont telefonálni pl. halál vele. Valakit felhívni túl körülményes és lassú:
Névjegyzék (2-3mp várakozás míg betölt) -->
Rányomok az emberre, megnyílik a névjegy. -->
Rányomok a hívás gombra, elindítja a 'tárcsázó' alkalmazást, (2-3mp) és bemásolja a telefonszámát -->
Megnyomom a zöld hívás gombot, feltéve, hogy jó sim van kiválasztva. Ha nem, akkor nyomni kell mégegyet.

Ez számomra túl macerás. 2 kattintást és pár másodperc várakozást simán meg lehetne spórolni. Ráadásul eddig nem is láttam, hogy melyik telefonszámomat hívták/küldtek sms-t. Szerencsére ezt ebben a kiadásban javították. Kipróbálni még nem tudtam.

Plusz a hiányzó alkalmazások. 3 van ami nélkül lehet élni, csak szívás:
-BKK Futár
-Volánbusz menetrend,
-Normálisan működő navigáció

Egyébként pozitívan állok hozzá. Jó cucc lesz ebből. Egyszer. :)

Csináltam erre egy bugreportot:

https://bugs.launchpad.net/ubuntu/+source/dialer-app/+bug/1469382

Nekem úgy tűnik, hogy szerintük ez így nagyjából jó. Száncsi. Ha majd lesz rá időm (2025-ben :D), csinálok egy normális tárcsázót. Addig meg szégyenszemre visszaálltam Androidra. De ha az uNav már tényleg használható (ahogy a cikkszerző írta felettem), akkor teszek vele egy próbát, nekem az volt a leginkább deal-breaker. Meg jó lenne HDMI output, de arra tudok várni :D (Van Nexus4-em, de nem akarom átinstallálni, az legalább jól használható a napi dolgokra...)

Pár száz kilométert már navigáltam vele. :) Egyébként tudom, hogy mi lehetett nálad a probléma. Gondolom mivel Nexusod van, ezért a sima Ubuntu csatornát használtad, mivel ahhoz azt ajánlják. Viszont az egy általános csatorna is, ahová nem raknak be semmi zárt dolgot, leszámítva a drivereket. Minden másik Ubuntuval árult telefon saját csatornát használ, amiben benne van a HERE AGPS alapból. Anélkül a pár másodperces pozíciónálás kb. 20 percig tart. De simán használható a Bq csatornája is N4-gyel, válthatsz rá adatvesztés nélkül, és akkor ott is szuperül megy.

Félreérted a helyzetet. Alapvetően az Ubuntu Touch miatt vettem annak idején N4-et. De amikor pár próbálkozás és sok várakozás után rájöttem, hogy a N4 agps sose lesz használható (mint kiderült hibásan, de ez most mind1), akkor vettem egy Bq4.5-öt. Ezzel már tovább húztam, de akkor nem volt még normális navi és sakkprogram, így kénytelen voltam visszaállni Androidra. Akkor született az a bugreport. Azóta egy haveromat rászedtem, hogy írjon egy sakkprogramot, már csak deployolni kell az Ubuntu Playbe :D Szóval jöhet az uNav teszt :D A N4 marad Android, hogy legyen egy használható telefonom is. :P

Nagyon penge, hogy vetted a fáradságot a bugreporthoz. Riszpekt :)

Abban egyetértek veled, hogy amikor kiválasztok egy számot akkor én azt szeretném hogy azt hívja és nem azt, hogy csak bemásolja a dialerbe a számot. De a többit illetőleg Allan Pope egyből megírta a frankót. Ha neked valaki annyira favorit akkor nyilván ott van a Recent hívások között. Az pedig ott van kéznéz.

Az pedig egy örök UX probléma, hogy milyen funkciókat pakoljon ki a ember egy alkalmazás főoldalára. Régi tapasztalat, hogy ha a gyors elérhetőség kedvéért minden felhasználó mindne igénye szerint kipakolunk mindent akkor egy idő után átláthatatlan és kesze-kusza lesz az alkalmazás. Lásd amikor egy vindóz ddeszktopra húszmilliárd shortcut-ot pakol ki az egységsugarú felhasználó.

Az uNav pedig tényleg nagyon sokat fejlődött. Nekem is az volt a fordulópont.

Igazán nagyot az dobna, ha a dialer és a contacts indításából 2 másodpercet le tudnánk faragni :)

Engem sokkal jobban bosszant, hogy ha rányomok egy telefon ikonra akkor azt várom, hogy elinduljon a hívá és nem azt, hogy bemásolja a számot a dialerbe. Lobbizok is rendesen, hogy ez megváltozzon. Bár szkeptikus vagyok a sikeremet illetőleg :)

Az alkalmazások indulási sebességével konkrétan én és az én csapatom izzad vért. A probléma nem az alkalmazás és nem is a Unity. A probléma az, hogy a QML engine piszok lassan inicializálja az qml alkalmazásokat. Erre van egy megoldás (ugyanaz mint a meego-ban), de az meg nem igazán jön ki az apparmorral.

Nagyob sok kör lefutása után most ott tartok, hogy sikerült rábeszélni a security arcokat meg a főnökséget és kitépjük a dialer, settings, contacts alkalmazásokat az apparmor alól és ezeket felhúzzuk a mapplauncherd megoldás alá. Ezzel a méréseink szerintem 1-1.5 másodpercet tudunk lefaragni a startup időből. OTA10-re talán meglesz, de OTA11-re mindenképpen. Abban bízok, hogy ez a gyorsítás ráveszi az apparmor fejlesztőket, hogy megoldják a dolgot a többi apphoz is.

Igen erős irónia volt.

Nem tartom minőségi szoftverbe valónak, hogy elkezdünk pár alkalmazással ilyen szinten kivételezni. Különben is: külső fejlesztésű alkalmazások hogyan küzdjenek meg a lassú QML loaddal? Ők is kikerülnek az apparmor alól? Some kind of security.

Úgy gondolom, most egy vacak mérnöki döntés eredménye miatt (kipróbálta bárki is előre, hogy a QML load lassú? Utánanézett-e, hogy húha, a fixnek baja van az apparmorral) elkezdett a csapat gányolni. Pedig ezek annak idején - úgy gondolom - a platform alapját érintő döntések voltak.

Ez is egy kicsit az Ubuntu sufnibarkács jellegét adja számomra. Győzz meg, ha nem így van. Elejétől követem, mit csinálnak ezzel a rendszerrel, az első nagyobb ilyenre (mir vs wayland) még azt mondtam, oké, lehet ez jó. A snappy-s őrületnél már rezgett a léc (tényleg, erről letettek azóta? Vagy egy újabb OpenSSL vuln. után lehet drukkolni, hogy frissül az adott libje az alkalmazásnak?). De amikor ilyenekről olvasok, akkor fogom a fejem.

És cikisnek találom, hogy ilyen, _alap használhatóságot_ érintő problémákat külső felhasználók jelentenek. Ezt a fejlesztők, vagy legalább a belső tesztelők hogyan engedhetik egyáltalán ki a kezükből?

> Nem tartom minőségi szoftverbe valónak, hogy elkezdünk pár alkalmazással ilyen szinten kivételezni.

Kivételezésről szó sincs. A settings, dialer, contacts alkalmazások esetében a confinement egy amolyen elméleti jelentőségű dolog. Konkrétan ezen alkalmazások esetében pusztán formaiság az apparmor mögött tartás. Más rendszerekben is külön jogosultsági csoportban vannak az ilyen core alkalmazások.

> külső fejlesztésű alkalmazások hogyan küzdjenek meg a lassú QML loaddal?

Ameddig meg nem sikerül oldanunk az Apparmor és QML engine közötti multi-therading alap problémát addig sajnos igen. Ennek a problémának a megoldása viszont sok munka lesz. A settings-dialer-contacts alaklamzások várható gyorsítása vélhetőleg fog akkor viszhangot jelenteni, hogy sikerül ennek a problémának a megoldását felgyorsítani.
Vehető ez úgy mint egy csali. A motiváció és a ROI mérlegelése nem utolsó szempont egy ilyen horderejű munka esetében.

> kipróbálta bárki is előre, hogy a QML load lassú?

Ne viccelj :) A QML engine teljesítménye azóra téma amióta ez a technológia megjelent. Két PhD dolgozatot tele lehetne írni erről a témáról. Sőt, olvastam erről a témáról nem keveset.
A QML alkalmazások indulása minden Qt kiadásban csiszolva van. A cachingtől kezdve a komponensek implementálása folyamatosan fejlődő dolgok.

Az Apparmornak pedig alapből semmi problémája nincsen a QML-lel. Évek ót tesztelve van a dolog. Az esetünkben egy a QML engine által indított threadek apparmor profiljának beállítása, ami egy nagyon-nagyon eldugott helyzetben probléma csak. Konkrétan arról van szó, hogy az appalauncher daemon által előmelegített processz az alkalmazés indulásakor kapja meg az apparmor profilt, viszont maga a QML engine a saját szája íze szerint dobálja fel a threadeket amikek a megfelelő apparmor profilba való állítása már nem lehetséges. Illetve lehetne az, de nem minden thread esetében. Bonyoult. 2-3 kernel fejesztő és 2-3 QML engine fejlesztő is tud a dologról. Ez egy múlt heti felfedezés és senki nem örül neki. Sem az upstream apparmor sem az upstream Qt csapatból. Van ez így. A Sailfish és a Meego nem futottak bele ebbe a problémába mert egyik sem használ semmilyen alkalmazás confinementet. Az Ubuntu használ, ez pedig alapvetően jó dolog. De a nem nulláról induló alkalmazások profil beállításának a problémájára senki nem számítot.
De a dolog még ennél is bonyolultabb. Órákig tudnék erről beszélni... de nagy tisztelettel kérlek, hogy ne nézd gányoló madárnak azért a csapatot aki ezen dolgozik.

> snappy-s őrületnél már rezgett a léc

Én nem a snappy-n dolgozom. De amikor ezt a problémát akkor felvetetted akkor szerintem alaposan elmagyaráztam, hogy miért teljesen alaptalan az aggodalmad. Ha ez nem elég akkor kérlek fordulj a snappy fejlesztőkhöz a kérdéseddel. Van IRC csatorna, vam levlista, van G+ csoport. De ez nem az én asztalom.

> És cikisnek találom, hogy ilyen, _alap használhatóságot_ érintő problémákat külső felhasználók jelentenek.

Ki mondta és hol, hogy külső felhasználók jelentették volna ezt?

> Ezt a fejlesztők, vagy legalább a belső tesztelők hogyan engedhetik egyáltalán ki a kezükből?

Vállalható és ideiglenes kompromisszumokat minden új platformnak kötnie kell. Minden ilyen döntésnél mérlegeli minden éppeszű döntéshozó, hogy milyen következményekkel járna akár az, hogy kienedi a kezéből a munkát vagy az, hogy nem. Húsz éve élek szoftver fejlesztésből... én még tökéletes szoftvert nem láttam. Olyan szoftver nincs amiben ne lennének bugo, amelyek minden esetben és helyzetben tökéletsen és gyorsan működnek.... Ja, bocs, de igen.. láttam. Tényleg láttam... olyan kóder kollégák satupadján akik megesküdtek, hogy még egy hét és akkor már tökéletes lesz :) Aztán sosem lesz az. Ez egy ilyen iparág. Két évig fejlesztettem MRI-hez szoftvert, még az sem volt tökéletes, abban is voltak szuboptimális dolgot. Pedig az rákdiagnosztikára használt cucc.

Szóval egy kicsit kevesebb intrikát és egy kicsit fékezetteb habzású cinizmust, ha kérhetnék... de tényleg. Mi is csak mérnökök vagyunk, tesszük a dolgunkat. Kevesen vagyunk, kicsik vagyunk, sok a meló, sok a fícsör, nagy a nyomás. Kis lépésekben haladunk, de haladunk. Amit csinálunk az nem tökéletes, de legalább szabad szoftvert fejlesztünk olyan nyitottan ahogy csak lehet.

Tudom, hogy az ilyen webes fórumokon ez nem szokás, de ha már ilyen intrikus és cinikus hangot ütsz meg, megkérdezhetem, hogy bennet személy szerint kit tisztelhetek.

Ez egy szakmai kérdés, szakmai téma. Nem hiszem, hogy van jelentősége az anonimitásnak és az a tapasztalatom, hogy az arcukat, nevüket vállaló emberek sokkal jobban ragaszkodnak a konkrét szakmai vonalhoz és kevésbé mennek el a beszólogatós, sértegetős irányba.

Ha technikai problémákat látsz akkor kérdezz bátran. Nem hiszem, hogy bármilyen technikai kérdés elől elbújtam volna, ahogy azt sem hiszem, hogy bármelyik másik OS fejlesztői közül itt zsizsekelnének a mérnökök, hogy a kérdésekre válaszoljanak.

Én szakmai témákban és kérdésekben nem bírom a cinizmust és a másik hülyének nézését. Azt szoktam feltételezni minden esetben, hogy mindenki a szaktudásának és lehetőségeihez mérten a legjobb megoldásra törekszik. Nagyjából erre számítok egy ilyen beszélgetés esetén is.

Szóval, ha kérhetlek akkor vegyük a témát és egymást komolyan, és adjuk meg egymásnak az alapvető szakmai tiszteletet. Én nem tegnap óta vagyok a szakmában és nagyon nem kedvelem az olyan beszélgetéseket amikor valaki egy fejlesztői csapatot nem ismerve, az fejlesztési területről felszines ismeretek alapján lenéző, lesajnáló beszólásokkal vagánykodik.

Én is szóltam még le régebben így... aztán ot találtam magam a szopógép rossz oldalán párszor és azóta egy kicsit óvatosabb vagyok amikor más munkáját, más projektjét kell megítélni. Néha az első látszat csal.

Szerintem wachag sem a csattogós lepkét tologatja már. Elég gyakran nem szoktam vele egyetérteni, de azért alapvetően nem mond hülyeségeket.

Biztos nekünk hiányosak az infóink, de a "vegyük ki a security megoldás felügyelete alól, mert úgy gyorsabb lesz" című szöveg bennem felvet néhány kérdést.

Amennyiben csak ezt a félmondatot nézed a tehnikai kontextusból teljesen kiaragadva akkor igen, felvet.

De pont ezeket a kérdéseket válaszoltam meg, rövidnek éppen nem mondható hozzászólásokban.

1) A cora appok confinementje amúgy is elvi biztonságot ad. Alapvetően ezeknek az appoknak semmi értelme az apparmor mögött lenniük.

2) A startup time problémáját ahogy írtam nem az apparmor és nem a confinement okozza. Ebből a szempontból ez a kérdés nem releváns.

3) Az architektúrába eredetileg nem tervezett applauncherd megoldás az ami nem fér meg egy fedél alatt az apparmorral. Ez az amire nem számítottunk és ez az ami mindenkit meglepett. Ezzel a problémával az applauncherd-t használó korábbi OS-ek (maemo, meego, nemo, sailfish) mert ők semmilyen alkalmazás confinement-et nem használnak.

4) az alkalmazás confinement lényege az, hogy az alapvetően ismeretlen eredetű alkalmazások ne férjenek hozzá más alkalmazások adataihoz és a rendszer szolgáltatásihoz a megfelelő profil nélkül. Ez értelemszerűen nem releváns egy dialer vagy settings alkalmazás esetében. Egyrészt mert ezen alkalmazások mind nyílt forráskódú, szabad szoftverek amiket bárki és bármikor auditálhat, tehát annak az esélye, hogy a dialer app lenyúlja a fingó alkalmazás adatait, hogy is mondjam... nem sok :)

5. Az applauncherd mint megoldás egy plugin jellegű technológia. Már tavaly is és tavaly előtt is tudtunk az előnyeiről. A fél csapat dolgozott a Meego-n, ismerjük az appa lifecycle lényegét. De úgy voltunk vele, hogy csak akkor vesszük elő ha tényleg szükség lesz rá. A startup time-ot a QML caching-gel és a UI komponensek egy más implementációjával terveztük csökkenteni, ami részben sikerült is, de még mindig nem elég jó. Ezért vettem elő az applauncherd-t. Az első teszteket már tavaly nyáron elkezdtük (https://launchpad.net/mapplauncherd) és konkrét protptípus is volt rá (https://launchpad.net/~ubuntu-sdk-team/+archive/ubuntu/testing) Ha ez az applauncherd vs. qml engine multihreading probléma nem jön elő akkor ez a megoldás a mostani OTA9-cel ment volna ki. De gondolom nem az a projekt a világ első olyan szoftver projektje amit az utolsó kanyarban fog meg egy szívós probléma.

Alapvetően tényleg gyakran nyers a stílusom, ezért elnézésed kérem.

Nehéz megfogalmazni, hogy ezzel a megoldásotokkal mi a bajom - nem ültem benn meetingek sorozatán, hogy lássam minden hátterét - de igazából a következő ellenérzéseim vannak:
- Elkezditek kétfelé választani az alkalmazásokat, vannak "egyenlőbbek". Ennek lesznek következményei. Ki dönti el, mi core és mi nem?
- Gyorsítást úgy értek el, hogy visszavesztek az alap biztonságból - "core" alkalmazásnál lehet, hogy nem számít, de mi tartja vissza a 3rd party-t, hogy ők is így oldják meg a dolgaikat?
- Ha a 3rd party alkalmazások ezt a módszert nem alkalmazhatják, ők hogyan oldják majd meg a lassú betöltést? Vagy ők így jártak?
- ha már egy tárcsázó alkalmazásnál - aminek nem gondolnám, hogy bonyolult az UI-ja - problémás a betöltés, mi lesz egy bonyolultabbnál?
- Ha a biztonságot - mintha másutt így írtad volna - nem csorbítja igazán, akkor minek egyáltalán az apparmor?
- Nagyon sok helyütt "elvi" biztonságról írtál. Mi a helyzet a gyakorlattal?

Az a bajom, hogy azok, amiket leírtál, szépen hangzanak, de nem győztek meg igazán. Mintha bezártátok volna magatokat egy olyan helyzetbe, ahonnan elegánsan nem tudtok kijönni, és most kerestek egy szükségmegoldást. Ez előfordul fejlesztésnél - küzdök is a könnyeimmel rendesen, amikor közlik, hogy milyen workaroundot kellene csinálni - csak számomra az a kérdés, hogy ennek a dolognak nem rögtön az elején kellett volna kiderülnie (proof of concept, deszkamodell, whatever...), amikor még nem késő technologiát változtatni?

Nagyon nem mítingek sorozatán dőlnek el az Ubuntuban az ilyen dolgot.

> Elkezditek kétfelé választani az alkalmazásokat, vannak "egyenlőbbek". Ennek lesznek következményei. Ki dönti el, mi core és mi nem?

Nem kezdjük el ketté választani az alkalmazásokat és nem kell eldönteni, hogy mi a core és mi nem az. A confinementből nem kerül ki semmilyen más alkalmazás. Egy szóval sem említettem, hogy bővülni fog azon alkalmazások köre amik ilyen boostert kapnak.

> Gyorsítást úgy értek el, hogy visszavesztek az alap biztonságból

Erről szó sincs. Semmilyen alapbiztonságból nem veszünk vissza.

> mi tartja vissza a 3rd party-t, hogy ők is így oldják meg a dolgaikat?

3rd party alkalmazások csak apparmor confinementben indulnak el. Ez elég komoly visszatartás :)

> - Ha a 3rd party alkalmazások ezt a módszert nem alkalmazhatják, ők hogyan oldják majd meg a lassú betöltést? Vagy ők így jártak?

Egyelőre, sajnos igen. De a problémán dolgozunk és a fix előbb vagy utóbb meg fog érkezni.

> ha már egy tárcsázó alkalmazásnál - aminek nem gondolnám, hogy bonyolult az UI-ja - problémás a betöltés, mi lesz egy bonyolultabbnál?

Nem feltétlenül bonyolultságfügő a dolog. Amúgy a legbonyolultabb alkalmazás az pont a Settings és ez górcső alatt is van.

> - Ha a biztonságot - mintha másutt így írtad volna - nem csorbítja igazán, akkor minek egyáltalán az apparmor?

Na, ez egy értelmes kérdés. A válasz bővebben itt van : https://en.wikipedia.org/wiki/AppArmor Röviden az a lényeg, hogy az apparmor az alkalmazástól védi meg a rendszert és a többi alkalmazást. így gondolom már világos, hogy egy nyílt forráskódú sytsem alkalmazásnál miért elméleti vagyis az apparmor jelentősége? Gyakorlati biztonságról, ebben az értelemben a dialer meg a settings esetében nincs értelme beszélni. A dialer app nem fogja lenyúlni a kontaktlistádat és nem küldi el egy pakisztáni szpemmernek. Ahogy settings app sem fogja a böngésző history-dat lenyúlni és egy reklámszervernek kitolni. Sőt, a contacts app sem fogja letörölni a kedvenc játékod highscore-ját.

> Az a bajom, hogy azok, amiket leírtál, szépen hangzanak, de nem győztek meg igazán.

Ez az igazság, hogy ez tényleg a te bajod :) Én minden konkrétumot, tény és a jelenlegi viszonyokhoz vezető utat leírtam. Meggyőzni nem kívánlak, nem vagyok marketinges és az égvilágon semmilyen érdekem nincs abban, hogy pont téged meggyőzzelek. Én mérnökmunkára iratkoztam fel ebben a projektben. Szakmai kérdésekre egyenes válaszokat tudok adni. Egy szakmai kérdésnek nem meggyőzőnek kell lennie, hanem kielégítőnek. Ha a kérdéseidre nem kaptál választ akkor kérdezz bátran. Nincsenek titkok.

> Mintha bezártátok volna magatokat egy olyan helyzetbe, ahonnan elegánsan nem tudtok kijönni, és most kerestek egy szükségmegoldást.

Ez felesleges és értelmetlen spekuláció. Nem erről van szó. De már leírtam, hogy a QML alkalmazások startup ideje egy cirka hét éve ismert kihívás. Az applauncher integráció amit mi mostanra terveztünk be már másfél évvel ezelőtt az asztalon volt. Szó sincs arról, hogy most keresnénk megoldást és amúgy ez a technika egy kimondottan elegáns megoldás. Mondom, a Meego-ban és a Sailfish-ben is pontosan ez a rendszer van. Nálunk is ez lesz, csak az apparmort fel kell rá készíteni.

> ennek a dolognak nem rögtön az elején kellett volna kiderülnie

Az elején frankón le lett protózva a dolog, megvolt a proof of concept, már szeptemberben tudtam számokat mutatni, hogy 1.3-1.7 másodpreccel javul minden QML alkalmazás start ideje az applauncherrel. De had ne kezdjem el magyarázni, hogy az integrációs fázis az miben különbözik a concepting fázistól. Nem alapvető technológiák összeférhetetlenségéről van szó hanem egy speciáls corner case-ről ami egy fork() exec()-re cserélésével és az apparmor profil létrehozásának egy biztonságosabb helyre való átrakásáal jött elő. Marha bonyoult módon jutottunk el ide, de röviden annyival tudnám összefoglalni, hogy a fészkes fene gondolta volna... ez egy nagyon az integráció utolsó lépésénél felmerülő erősen szopógép kaliber probléma.

> küzdök is a könnyeimmel rendesen, amikor közlik, hogy milyen workaroundot kellene csinálni

Egyrészt ez nem workaround. Másrészt már megint ez a cinikus magas ló. Nem tudom, hogy neked milyen ipari tapasztalataid vannak, de feltételezem, hogy aki látott már élesben komoly szoftver fejlesztési projektet... és komolya alatt most 50-100 fő feletti, több éven át tartó eurótízmilliós nagyságrendő befektetést igénylő szoftver projeket az tudja, hogy bizony vannak kompromisszumok. Néha ezért, néha azért. Néha banálisak, néha üzletei okból, néha határidők miatt, néha azért mert nincs elég ember, nincs elég pénz, nincs elég tudás...ha nagy rendszert fejlesztesz akkor előbb vagy utóbb, kisebb vagy nagyobb workaround-oka fogsz látni vagy éppen csinálni. De hangsúlyozom, hogy esetünkben nem workaround-ról van szó. De nyilván az Ubuntu fejlesztés során is vannak workaroundok. Ezeket szerintem érdemes szakmai alázattal nézni.

Ez pedig nem nyersség kérdése. Ha szakmabeli vagy akkor tőlem lehetsz nyers, de az a megfigyelésem, hogy aki már hallott szopógépet üveghangon sikítani az alapvetően bajtársiasan áll a másik mérnökhoz aki éppen megemeli a szopótalicskát. Sőt, azt figyeltem meg, hogy cinikusan azok szoktak beszólogatni akik igazán még nem járták meg a hadak útját. A múltkor például volt itt egy júzer aki szerint ezt az egész Ubuntu telefon dolgot pár hét alatt néhány ember meg tudná csinálni :)

A saját dialer is csak egy egy alkalmazás. A megfelelő jogosultságokkal el kell látnod és uccu neki. Értelem szerűen ha te egy egy teljesen saját privát alkalmazást akarsz írni akkor azt csinálsz amit akarsz. Ha nem akarok akkor nem lesz confined az appod. De a hivatalos store-ba ez nem fog bekerülni.

Az account providerek beállítása nem tudom, hogyan működik. De keresdk seb128 vagy kenvdandine cimborákat a freenode-on. Ők tudják.

Van még amúgy ilyen kérdésem: ha és valamiért véletlenül bármilyen sechole kerül ebbe a pár alkalmazásba - ez mindenütt előfordul - lesz-e különbség apparmorral vagy nélküle?

> Ha nem akarok akkor nem lesz confined az appod. De a hivatalos store-ba ez nem fog bekerülni.

Ez egyfelől jogos, másfelől a lassú QML load nem lesz a felhasználók számára blocker?

Egyébként az upstream-mel (Qt) mennyire vagytok (milyen, van-e) kapcsolatban? Úgy gondolnám, elég "nagyok" (értsd: komoly felhasználók) vagytok ahhoz, hogy ezzel foglalkozzanak ők is, elvégre embedded alkalmazások irányában eléggé terjedni akarnak.

> ha és valamiért véletlenül bármilyen sechole kerül ebbe a pár alkalmazásba - ez mindenütt előfordul - lesz-e különbség apparmorral vagy nélküle?

Ismétlem :) Az apparmor feladata nem az alkalmazás védelme, hanem a rendszer és a többi alkalmazás védelme magától az alkalmazásól. Vagyis midnen apparmor confinementben levő alkalmazás csak a saját adataihoz és az apparmor profiljában rögzített szolgáltatásokhoz fér hozzá.

> a lassú QML load nem lesz a felhasználók számára blocker?

Nyilvánvaló módon aránylag kevés felhasználó dönt az Ubuntu telefon mellett azért mert annak ilyen kellemesen lassan indulnak az alkalmazásai. Értelem szerűen ez a probléma az egyik legkomolyabb fejfájásunk mostanában. De több fronton is támadjuk a dolgot. Az applauncher csak az egyik potenciális segítség.

> Egyébként az upstream-mel (Qt) mennyire vagytok (milyen, van-e) kapcsolatban?

Több upstream modul admin is dolgozik nálunk. Vagy egy tucat Qt contributor van az Ubuntu csapatban. Minden Qt rendezvényen ott vagyunk. Fizetünk a Qt Company-nak némi pénzt is. Az adott problémáról tudnak és folyanatosan konzultálunk.

Maga a QML alkalmazások lassú indulása egy közismert probléma és szerintem nincsen rá csodaelixír amitől egyszercsak hirtelen minden qml app mint a villám indulna. Ez nem olyan dolog :)

> Tekintve, hogy az a celja az egesz dolognak

Nem ez a célja: https://en.wikipedia.org/wiki/AppArmor

De értelem szerűen az a kitétel, hogy minden szoftverben van (nemcsak, hogy lehet, hanem fix,hogy van) hiba elvileg hideglelést és agygörcsöt kellene hoznia mindenkire aki szoftvert használ :)

Biztos lehetne ezen orakig rugozni, foleg a pongyola megfogalmazasomon. Az apparmor dobozba zarja az alkalmazasokat, es nem engedi okat onnan kitorve mas rendszerekhez hozzaferni. En erre gondoltam, mikor azt mondtam, hogy "Tekintve, hogy az a celja, hogy mas rendszereket megvedjen", attol fuggoen melyik iranybol nezzuk :)

-
Big Data trendek 2016

Valójában ez sajnos nem igaz. Igaz, hogy ezek az alkalmazások részei a rendszernek, de sejtésem szerint a dialer és a contact nagy valószínűséggel külső forrásból is etethető (pl. weblapon telefonszámra kattintva vagy e-mail-ből elmentett vcard fájlból). Ha van bennük például egy BoF hiba, de a QML miatt még egy XSS-t vagy egy SQLi-t is el tudok képzelni, akkor a támadó megfelelően preparált bevitt adattal szétszedheti a rendszered és az Apparmor nem fog megvédeni.

A dialer app [1] telefonszám bevitele egy kutyaközönséges stock komponens, minden módosítás nélkül. Ha az kompromitálható akkor a Unity8 dash-ben a keresés is kompromitálható. A Unity8 pedig értelem szerűen nincsen apparmor mögött.

Vagyis ha a QML engineben és magában a TextArea komponensben ilyen támadhatóság van akkor az egész rendszer veszélyben van. De ugyanez elmondható bármelyik másik rendszerről is, az iOS és az Android is pontosan így van ezzel.

De egyébként a Qt-nál és a a Canonical-nél sem nyeretlen egyévesek ülnek a security csapatban :) alaposan meg vannak nézve ezek a dolgok.

[1] http://bazaar.launchpad.net/~phablet-team/dialer-app/trunk/view/head:/s…

> Véd-e ettől az apparmor?

Nem, ettől az apparmor sem véd meg. Ha ilyen alapvető vulnaribility van a Qt-ban akkor ott már a Unity8 shell szinten is problémák vanak. Hiszen maga a shell is Qt és QML.

Magukban a QML Setting/Dialer/Contacts appok nem lehetnek sérülékenyek. Mezitlábas QMl alkalmazások ezek.

"Nem, ettől az apparmor sem véd meg", plusz mindig a hasznalhatosagot es a biztonsagot kell merlegre tenni, es tokeletes megoldas nincs. Ha mindent megenged a szabaly, akkor ertelem szeruen a tamadonak is konnyebb a dolga, ha pedig ultra biztonsagos, akkor valoszinuleg jogos felhasznaloi funkciok serulnek.

-
Big Data trendek 2016

Az utolsó bekezdésedre: ebből nem következik, hogy a Qt, QML jelenlegi állapotában alkalmatlan egy (mindenki számára örömmel használható) telefonos rendszer megvalósítására? Ha az alkalmazások betöltése lassú marad - mint írtad, nincs csodaelixír - akkor hogyan éritek el, hogy egy tetszőleges (valami alkalmazásboltból letöltött) szoftverre ne mondják a felhasználók, hogy "lassú vacak"?

Ez azért is érdekel, mert maga a Qt alap számomra nagyon szimpatikus, úgy gondolom, szép jövője lehet, de erre a kérdésre nem látok megnyugtató választ. (Ha lenne, gondolom ti sem "trükköznétek" így).

> ebből nem következik, hogy a Qt, QML jelenlegi állapotában alkalmatlan egy (mindenki számára örömmel használható) telefonos rendszer megvalósítására?

Egyértelmű, hogy ebből nem következik. A Qt és QML technológiák már évekkel ezelőtt is bizonyították a Nokia N9 (Maemo6 vagy Meego) esetében, hogy kivállóan alkalmasak mobil platform építésére. A Jolla telefon is Qt/Qml alapokra épül és az Ubuntu telefon is kivállóan működik.

Hogy a felhasználó mire mond mit azt sem én sem más nem tudja befolyásolni. A felhasználó maga eldönti, hogy milyen termék felel meg az igényeinek. Akinek döntő fontosságú, hogy bizonyos alkalmazások ne 2.4 hanem 1.2 másodperc alatt induljanak el az a jelen helyzetben jobban teszi ha másik telefont keres. Ezerszer elmondtam itt a hupon már, hogy az Ubuntu telefonnak a jelen fejlesztési állapotban nincsen olyan ambíciója, hogy a világ összes telefon felhasználónak az összes igényét maradéktalanul és kompromisszumok nélkül kiszolgálja.

> nem látok megnyugtató választ. (Ha lenne, gondolom ti sem "trükköznétek" így).

Úgy érzem, hogy visszatértünk a kiindulási ponthoz és innentől csak ismételni tudnám magam. De azt mindenképpen leszögezném, hogy trükközésről szó sincs. Minden megoldás amit használunk teljesen közismert, a szakmában használt és elfogadható megoldás. Az apparmor sem trükközés, az applauncherd sem trükközés, a QML engine sem trükközés, a system appok confinementből való kiemelése sem trükközés.

Ez kicsit fura nekem. Ha az Apparmor miatt lassú a dolog, akkor nem lenne jobb, ha a főnökséget arról győznétek meg, hogy ezt oldják meg, a „kitépés” helyett? Mert, ha jól értem ez egy demonstráció, hogy anélkül mennyivel gyorsabb lenne. Egyébként már most is sokat javult az alkalmazás indulás, de tény, hogy még mindig van hová fejlődni. :)

Nem az apparmor miatt lassú, az apparmor az semmilyen teljesítmény kompromisszummal nem jár.

Ami lassú az a qml engine. Az erre készített megoldás az ami nem jön ki az apparmorral.

A dolog lényege az, hogy az alkalmazások nem a nulláról indulnának, hanem egy app launcher daemon készenlétben tartana egy alap alkalmazás templétet amire felfűzné az indítandó alkalmazást. így a QML enginnek nem kellene minden app induláskor szöszmötölnie. Ez a megoldás az ami nem megy az apprmorral.

( uid_19334 | 2016. 01. 29., p – 23:24 )

a böngészõ miket tud? Képek/js tiltása, inverz színû mód, szöveg újratördelése stb van benne?
(Van olyan böngészõ rá ami tudja?)