Köszönjük az adományait és a támogatását.

Frissítések alkalmazása

Egy bejelentést tettek a múlt héten, hogy megmagyarázzák, miért fontosak a biztonsági frissítések, és hogy emlékeztessk az embereket arra, hogy frissítsék a számítógépüket.

Ha még nem olvasta el, kérem, tekintse meg a „Frissítse a rendszerét!” cikket (eredeti cikk).

Elkezdtünk dolgozni a Frissítéskezelő fejlesztésén. A következő kiadásban a kezelő nem csak a rendelkezésre álló frissítéseket fogja keresni, hanem nyomon fogja követni az egyes mérőszámokat is, és képes lesz felismerni azokat az eseteket, amikor a frissítéseket figyelmen kívül vannak hagyják. Néhány ilyen mérőszám, hogy mikor volt az utolsó alkalom,amikor a frissítéseket alkalmazták, mikor volt az utolsó alkalom, amikor a csomagokat frissítették a rendszerben, hány napja jelent meg egy adott frissítés…

Bizonyos esetekben a Frissítéskezelő képes lesz arra, hogy emlékeztesse Önt, hogy alkalmazza a frissítéseket. Közülük néhány esetben talán még sürget is. Nem akarjuk, hogy buta legyen, és mégis az útjába kerüljön. Azért van itt, hogy segítsen. Ha a dolgokat a maga módján kezeli, akkor ez felismeri az intelligens mintákat és szokásokat. Ez is konfigurálható lesz, és lehetővé teszi, hogy módosítsa annak módját, ahogyan beállítja.

Nekünk vannak alapelveink a Linux Mint-nél. Az egyik az, hogy ez az ön számítógépe, nem a miénk. Mi is sok használati esetet szem előtt tartunk, és nem szeretnénk, hogy a Linux Mint-et bármelyiküknél nehezebben használhatóvá tegyük.

Még mindig stratégiákat alkotunk és eldöntjük, hogy a kezelő mikor és hogyan tegye láthatóbbá magát, így túl korai beszélnünk ezekről a szempontokról, és belemennünk azokba a részletekbe, amelyek valószínűleg a leginkább érdeklik itt. Eddig azon dolgoztunk, hogy intelligensebbé tegyük a kezelőt, és hogy több megvizsgálható információt és mérőszámot adjunk meg neki.

Hibajavítások

Tegnap a következő projektekhez jelentek meg csomagfrissítések: Xapp, warpinator, nemo, fahéj-menük, nemo-dropbox, nemo-media-columns, nemo-python. Ezek jelentős számú módosítást jelentenek, és számos problémát megoldanak.

Gyors számítógépeken egy xapp összetevő akár egy másodperccel is késleltetheti a bejelentkezési időt. Ez azért volt érvényben, hogy garantálja az értesítési terület kompatibilitását az indikátorokkal és QT-alkalmazásokkal, és megtartotta a munkamenetet annak ellenőrzésére, hogy a rendszertálca érvényben volt-e az automatikus alkalmazások előtt. Ezt a funkciót újratervezték, és a késleltetés már nem létezik.

Számos, a kedvencekhez kapcsolódó használhatósági és sokadlagos problémát megoldottak.

Egy hibát találtak annak módjában, ahogyan a Nemo a mutatószámításokat kezelte. A fájlböngésző ablakainak átméretezése az újraszámítások felhalmozódásához vezethet, és egy idő után késleltetést okozhat a fókuszban. Ezt javították.

Memóriaszivárgásokat is találtak és javította a Nemo-ban és annak néhány bővítményében.

A fájlműveletek és a miniatűrök kezelése teljesítménybeli és stabilitási javulást eredményezett.

Magán az asztalon a félkövér betűtípusokat érintő használhatósági hibákat és az ikonok rendezési sorrendjét kijavították.

Plymouth+LUKS Bug és reprodukálható build-ek

Amikor megnyitották a Linux Mint 20-ról a Linux Mint 20.1-ra vezető frissítési útvonalat, visszajelzést és hibajelentéseket kaptunk a LUKS-titkosított meghajtókkal rendelkező számítógépeken keletkező plymouth problémával kapcsolatban.

Nem tudtuk azonosítani a probléma okát. Mivel a probléma csak néhány felhasználót érintett, először azt gondoltuk, hogy hardverrel kapcsolatos, és hogy ennek valami köze volt az NVIDIA illesztőprogramokhoz.

Mielőtt elmagyarázom, mi történt, és annak következményeit, ha erre a javításra várt, szeretnék bocsánatot kérni azért, hogy ennyi időbe került, és köszönöm a türelmét. A mai naptól ez a hiba kijavításra került. Pénteken azonosítottuk az okát, és ma elküldtünk egy Plymouth csomagfrissítést a csomagtárolóinkba, amely kijavítja a problémát.

A történet azonban itt nem ér véget. Ez a hiba tudatosított bennünk egy nagyon fontos problémát, amely érinti az Ubuntu-t (és a Debian-t is, de sokkal kisebb mértékben), a nem reprodukálható build-ek kérdését.

Ez meglehetősen szakmai. Amikor a Linux Mint 19.3-ról a Linux Mint 20-ra költöztünk, akkor mi egy Ubuntu 18.04-es csomagbázisról költöztünk át Ubuntu 20.04-es csomagbázisr. Az egyik fontos különbség a két csomagbázis között az a tény, hogy az Ubuntu 20.04 egy összevont rendszer (azaz egy olyan rendszer, ahol egyes útvonalakat, mint pl. a /bin-t és a /usr/bin-t symlink-ekkel egyesítik és ténylegesen ugyanazok, ezt az alábbiakban ismertetjük: https://wiki.debian.org/UsrMerge).

Ha egy összevont rendszeren egy csomag bináris fájlt helyez a /bin könyvtárba, és egy másik csomag rossz elérési úttal (/usr/bin például) hívja meg, akkor nem számít, egyébként is működik. Ez egy fejlesztés a felhasználók számára, de el is rejti a potenciális problémákat a karbantartó szempontjából. Ha rossz útvonalon csomagol valamit, a csomagja továbbra is működik az összevont rendszereken, de nem működik az össze nem vont rendszereken.  

A 20.1-es verziótól kezdve a Linux Mint is elfogadta a usrmerge-t és minden friss telepítést összevon. A Linux Mint 20-ról történő frissítés részeként azt javasoltuk, hogy az emberek vonják össze a rendszerüket, de nem mindenki tette meg. Tisztában voltunk ezekkel a lehetséges problémákkal, és elmagyaráztuk azokat a frissítési utasításokban. Ezt ugyanúgy csinálta a Debian és az Ubuntu, amikor ezek is összeolvadtak. Minden disztribúció elkötelezett mindkét rendszer támogatása mellett.

A Debian azonban tovább ment, és megértette, hogy ez milyen hatással lehet a folyamatok felépítésére. Ha egy csomag megvizsgálja a build-környezetét, hogy felmérje egy adott bináris fájl útvonalát, és az így kapott csomagokban befecskendezte azt, akkor problémák történhetnek, ha a build-környezet eltér a felhasználóétól.

Vegye például a plymouth-ot, amikor forrásból fordítja le, átvizsgálja a build-környezetet, hogy megtalálja a systemd-tty-ask-password-agent nevű systemd bináris fájl elérési útját. A Debian rendszereken a systemd csomag biztosítja ezt a bináris fájlt és elhelyezi a /bin mappában. A plymouth build az autotools-t használja, és egy AC_PATH_PROG nevű rutint, hogy megtalálja az útvonalat a systemd-tty-ask-password-agent-hez, majd befecskendezi ezt az útvonalat a systemd szolgáltatásba, amelyet ahhoz nyújt, hogy meghívja azt.

Egy össze nem vont számítógépen a systemd-tty-ask-password-agent a /bin mappában van (ahová a systemdcsomag teszi). Egy összevont számítógépen ez mind a /bin, mind a /usr/bin mappában megvan (mivel ez a két könyvtár ott ugyanaz).

Ha a plymouth forráscsomagot egy nem összevont számítógépen szerkeszti össze, akkor a systemd-tty-ask-password-agent-et a /bin-ben találja, és befecskendezi a „/bin/systemd-tty-as-password-agent”-et a szervizfájljában. Ez az útvonal működik mind az összevont rendszereken (ahol az útvonal nem számít), mind az össze nem vont rendszeren (mivel az útvonal helyes).

Ha a plymouth forráscsomagot egy összevont számítógépen szerkeszti össze, akkor a systemd-tty-ask-password-agent-et a /bin-ben találja, és befecskendezi a „/us/bin/systemd-tty-as-password-agent”-et a szervizfájljában. Ez az útvonal helytelen, és így csak összevon rendszereken fog működni.

A Debian megértette annak fontosságát, hogy ugyanazt a kimenetet kapja a különböző környezetekben lévő build-ekből. Más szóval, a build-környezet akár összevont, akár nem, az eredményül kapott csomagoknak nemcsak minden rendszeren működniük kell, hanem minden tekintetben azonosnak is kell lenniük. A Debian folyamatos integrációs ellenőrzéseket futtat annak biztosítása érdekében, hogy minden build-je reprodukálható legyen, és javítja azokat a csomagokat, ahol ez nem így van.

A plymouth forráskódot valóban javították a Debianban, hogy megakadályozzák ezt a problémát, de az Ubuntuban nem. Ami még rosszabb, és ez valóban nagyon fontos a mi esetünkben, hogy a 20.04 óta (és így nekünk a Linux Mint 20, és nem a 20.1 óta), az Ubuntu Docker képek és felhasználói rendszerek összevontak, de a Launchpad build-környezet nem. Más szóval, néhány, a 20.04-ben elérhető forráscsomag olyan csomagokat állít elő, amelyek különböznek az adattárakban az újraépítés során található csomagoktól. Mivel a 20.04-hez tartozó Ubuntu build infrastruktúrát még nem vonták össze, nem kell aggódnunk az Ubuntu által épített bináris csomagok miatt (a forráscsomag buildek akár reprodukálhatók, akár nem, ha azok össze nem vont környezetben fognak, mindenhol működni fognak).

Mivel elsősorban a Docker-t használjuk a csomagjaink felépítésére, és mivel a képeinket (20.04 óta) összevontuk, aggódnunk kell emiatt, mint ahogy a Debian tette, és nem csak ezt az adott hibát kell kijavítanunk, hanem meg kell győződnünk arról, hogy előre észlelünk minden nem reprodukálható build-et, és mindent kijavítunk, ami változékonyságot vezet be, és már nem javítottuk a upstream-en. A lehető leghamarabb belső eszközöket fogunk fejleszteni ennek kezelésére. Felülvizsgáljuk a saját disztribúciók közötti projektjeinket is (Cinnamon, xapp, hogy néhányat említsünk), és meggyőződünk róla, hogy nem így keresnek útvonalat, vagy nem vezetnek be ilyen jellegű hibákat a saját build-jükben.

A Cinnamon fejlesztései

Bár a memória szivárgásra a megldás egy tényleges javítás, néhány szivárgás évekig észrevétlen marad. A legtöbb esetben ez azért van, mert ezek hardver- vagy driver-specifikusak, néha ez egyszerűen azért van, mert a hibajelentés nem mutat valami konkrét dologra, ami nekünk hiányzik, és nem tudjuk reprodukálni a problémát.

Maga a Cinnamon Fahéj sokszor az ön GPU meghajtóira támaszkodik. A rendszertől és attól függően, hogy mit kér tőle, akár 80 MB és 1 GB közötti RAM-ot is használhat. Különösen kicsi az Intel és a nyílt forráskódú meghajtók esetében, és különösen nagy a 64 bites saját NVIDIA meghajtók esetében. A rendszer kis méretben is elindul, és több memóriát használ, amint ön több funkciót aktivál. Általában idővel növekszik, egy bizonyos pontig. Ez a pont attól függ, hogy ön hány kisalkalmazást használ, függetlenül attól, hogy az összes funkcióját és a rendszert használja, amin dolgozik. Ha elérjük ezt a pontot és ha a Cinnamon tovább növekszik a végtelenségig, akkor ön memória szivárgást tapasztal.

Tudjuk, hogy még mindig van néhány memória szivárgás, mert hallunk olyan emberekről, akik tétlenül töltött napok után térnek issza a számítógépükhöz, hogy a Cinnamon folyamataikat úgy találják meg, hogy 2 GB, 4 GB, 6 GB RAM-ot fogyasztanak. Még nem tudjuk, mi okozza ezeket a szivárgásokat, de lesz egy megoldás a Cinnamon 5.0-ban.

A rendszerbeállítások használatával képes lesz beállítani egy maximális mennyiségű RAM-ot, amelyet a Cinnamon használhat.

Ha ezt a maximális mennyiséget eléri, a Cinnamon újraindítja magát. Ön nem fogja elveszíteni a munkamenetét vagy az ablakait, csak egy másodpercig nem reagál, miközben belülről újraindul. Ez meg fog őrizni egy naplót az ilyen eseményekről, hogy láthassa, hogy ez gyakran előfordul-e, és segít nekünk aprobléma elhárításában.

Egy másik dolog, amit javítunk, a fűszerkezelés (Spices). A korábbi Cinnamon verziókban különbségek voltak az appletek, asztali alkalmazások és a kiterjesztések számára létrehozott telepített fül és letöltési fül között. 

Módosítottuk annak a módját, ahogyan a dolgok működnek annak biztosítása érdekében, hogy minden megfelelően le legyen fordítva, és hogy minden fűszernek ugyanaz a neve, ikonja és leírása legyen, akár telepítve vannak, akár nem.

Mi is több információt jelenítünk meg, mint például a szerző nevét és a fűszer egyedi azonosítóját, és jelenleg dolgozunk annak képességén, hogy grafikusan telepíthessen harmadik féltől származó ZIP fűszereket.

A függöny mögött erősítettük a Cinnamon Spices validálását és fordítását, és folyamatos integrációt valósítottunk meg.