A GNOME 3.22 széleskörű Flatpak támogatással érkezik. A Szoftverek alkalmazás most már képes Flatpak tárolófájlok telepítésére, ami azt jelenti, hogy anélkül lehetséges a Flatpak tárolók és alkalmazások telepítése, hogy egyáltalán használni kelljen a parancssort. Számos egyéb apróbb változtatás teszi egyszerűbbé a Flatpak alkalmazások telepítését és frissítését, mint például az egyes alkalmazások forrásinformációinak megjelenítése, valamint azon részletek megjelenítése, hogy az alkalmazások biztonságos környezetben vannak-e.
A GNOME 3.22 olyan fejlesztői eszközöket is bemutat, amelyek lehetővé teszik az alkalmazások számára, hogy a Flatpak biztonsági szolgáltatásainak minden előnyét élvezzék. Ez lehetővé fogja tenni az alkalmazásoknak, hogy a felhasználók számára sokkal nagyobb védelmet biztosítsanak a jövőben.
Több fájl átnevezése
A Fájlok alkalmazás mostantól képes több fájl egyidejű átnevezésére. Ez kifejezetten akkor hasznos, ha hasonló fájlok gyűjteményével dolgozik, mint például videók, zenék vagy fényképek. A fájlok átnevezhetők egy sablon használatával, amelyet minden fájlra alkalmaz, vagy az összes fájlnévre rákeresve és bizonyos részeket kicserélve. A sablon mód lehetővé teszi, hogy a fájlokból származó információk is részei lehessenek a fájlnévnek, mint például a létrehozás dátuma, illetve zenei fájloknál a szám sorszáma, az előadó neve vagy az album neve.
Az új szolgáltatás használatához egyszerűen jelöljön ki több fájlt, és válassza az Átnevezés… menüpontot a helyi menüben, vagy nyomja meg az F2 billentyűt.
Fényképmegosztás
A legutóbbi kiadásban a Fényképek számos új fényképszerkesztő funkciót kapott. A 3.22-nél egy másik kritikus funkció került bevezetésre: annak képessége, hogy egyszerűen lehessen fényképeket megosztani másokkal. Az új megosztás funkció lehetővé teszi a fényképek megosztását a Google tárhelyére való feltöltéssel, vagy e-mail mellékletként történő elküldéssel. További megosztási célok is tervbe vannak véve a jövőben, beleértve a közösségi hálózatok széles körét.
A fényképmegosztás teljesen integrálva lett az Online fiókokkal, így a Google tárhelyére való feltöltéshez először hozzá kell adni egy Google fiókot a Beállítások alkalmazásban.
Továbbfejlesztett Szoftverek
A Szoftverek alkalmazás megjelenése megújult a GNOME 3.22-ben. A nyitóoldalt átalakították, és mostantól több alkalmazáscsempét jelenít meg, valamint a kategória szakasz a böngészést az élmény szerves részévé teszi. A csillagos értékelés is sokkal hangsúlyosabban jelenik meg annak érdekében, hogy könnyebbé tegye a legjobb telepíthető alkalmazások megtalálását.
A Szoftverek egyéb fejlesztéseket is kapott. A színekkel kódolt jelvények egyértelműen jelzik, hogy egy alkalmazás szabad szoftver-e, valamint számos lista és oldal elrendezése is kifinomultabbá vált.
A Wayland állapota
A Wayland a következő generációs megjelenítési és beviteli technológia GNU/Linuxon. Megszünteti a grafikai problémákat, megold régóta fennálló hibákat, és lefekteti a biztonságosabb alkalmazások alapjait. A Wayland új funkcionalitásokat is hoz, mint például a többérintéses érintőtábla-gesztusok.
A GNOME Wayland támogatása folyamatosan fejlődött a legutóbbi kiadásokban. A GNOME 3.20-ban vált használhatóvá a felhasználók többségénél. Azóta a támogatás továbbfejlesztése folytatódott a hiányzó szolgáltatások többségének elkészítésével. Ebbe beletartozik a Wacom rajztáblák támogatása, a kijelzők elforgatásának képessége, és a GNOME képernyő-billentyűzetének támogatása. Számos kisebb hiba is megoldásra került a Wayland használhatóságának összecsiszoltabbá tételéhez.
Továbbfejlesztett Fájlok alkalmazás
A tömeges átnevezés mellett a Fájlok alkalmazás nagy számú egyéb fejlesztést kapott a GNOME 3.22-nél. A tömörített fájl funkcionalitás közvetlenül integrálva lett, így egy tömörített fájl kibontása (mint például egy .zip vagy .tar.gz fájl) csak egy dupla kattintást igényel önálló alkalmazás használata helyett. Új tömörített fájlok is létrehozhatók számos formátum használatával.
A Fájlokban a nézet és a tartalomrendezés vezérlőelemei is felújításra kerültek a 3.22-ben. Ez lehetővé teszi a rács- és a listanézet közti váltást egyetlen kattintással, valamint egyértelműbbé teszi a nagyítást és a rendezési lehetőségeket. Ezeket a változtatásokat a Gina Dobrescu által elvégzett használhatósági tesztek jelentették, amelyek egy Outreachy gyakornokság részeként készültek.
Más felhasználói felület elemek továbbfejlesztései közé tartozik a lebegő állapotsor automatikus elrejtése, hogy ne legyen útban, valamint további információk felvétele a kiszolgálókhoz történő kapcsolódásnál, beleértve azt is, hogy mely fájlprotokollok vannak támogatva.
Újratervezett billentyűzetbeállítások
A GNOME billentyűzetbeállításai felújításra kerültek a 3.22-ben. A gyorsbillentyűk listája mostantól egyszerűbben böngészhető, és az új megjelenés az előző verzió számos hibáját kiküszöböli. A keresési funkció gyorsabbá teszi a kívánt gyorsbillentyű megtalálását, és a gyorsbillentyűk beállításának folyamata sokkal világosabb visszajelzést nyújt.
Újratervezett dconf szerkesztő
A dconf szerkesztő, amely a beállítások böngészésére és megváltoztatására szolgáló alkalmazás, megjelenési frissítést kapott a 3.22-ben. Az új verzió egyszerűsített felülettel rendelkezik az útvonalsáv köré szervezve. Az új „késleltetés mód” lehetővé teszi több változtatás egyszerre történő elvégzését. Továbbá számos visszaállítási lehetőség teszi lehetővé a látható beállítások visszaállítását, vagy azok rekurzív visszaállítását (az aktuális mappában és bármely almappájában).
És ez még nem minden…
Szokás szerint sok más egyéb kisebb fejlesztés is található ebben a GNOME kiadásban. Álljon itt néhány ezek közül:
- A Naptár új verziója mostantól lehetővé teszi a riasztások beállítását az eseményekhez. Lehetővé teszi továbbá annak megváltoztatását, hogy egy esemény mely naptárhoz tartozik, valamint az eseményszerkesztés újratervezett dátumválasztókat kapott. A naptárrácsban az események mostantól áthelyezhetők fogd és vidd módon, és az évnézet elrendezését is finomították.
- A Polari, a GNOME IRC kliense mostantól képes emlékezni a jelszavakra, és automatikusan újrahasználni azokat, amelyeket a NickServ szolgáltatásnak küldtek el.
- A Térképek mostantól a Mapbox szolgáltatását használja az OpenStreetMap adatok szolgáltatójaként. Ettől azt várják, hogy megbízhatóbb szolgáltatást nyújt a jövőben.
- A teljesítmény drámaian javult a Zenékben. Az alkalmazás mostantól gyorsabban tölt be, és az albumok rácsa automatikusan beállítja magát, hogy az elérhető helyet a lehető legjobban használja ki.
- A Videók mostantól lehetővé teszi a különböző sebességeken történő lejátszást. Ez különféle esetekben lehet hasznos, mint például előadások hallgatásakor vagy jegyzeteléskor.
- A Gépek, a GNOME virtuális és távoli gépek használatához készített alkalmazása képessé vált a klónozásra. Ez egyszerűvé teszi másolatok készítését a gépekről.
- A Web, a GNOME böngészője mostantól rendelkezik egy gyorsbillentyű ablakkal, amely megkönnyíti az elérhető gyorsbillentyűk megismerését. A címsávban lévő új helyi menü lehetővé teszi a „Beillesztés és megnyitás” használatát, valamint számos hibaoldalt is újraterveztek.
- Folytatódik a Könyvek, a GNOME e-könyv alkalmazásának fejlődése, amely mostantól kezdeti támogatással rendelkezik az ePub könyvek megtekintéséhez. Várható, hogy ez a funkció a jövőbeli kiadásokban kiforrja magát.
100%-os magyar fordítás
A Gnome magyar fordítócsapatának köszönhetően a 3.22-es kiadás teljes felhasználói felületét sikerült a kiadás napjára honosítani. A fordítók nemcsak a programokat, hanem a kapcsolódó dokumentációk több mint felét is feldolgozták már, így a legnépszerűbb programok súgófájljai szintén magyar nyelven olvashatók.
További részletek
- A hozzászóláshoz be kell jelentkezni
- 5570 megtekintés
Hozzászólások
a) megoldották a linuxosok nagy problémáját, az eltérő csomagformátumot
b) beépült a Skynetbe (akarom mondani még jobban integrálták a Google-ökoszisztémába)
c) végre külső alkalmazás nélkül kicsomagol zip-et és targézát (aztán majd jól pofára esnek - mint a FreeBSD-féle libarchive - egy-egy spécibb ZIP-formátumtól, vagy rar-tól, 7zip-től, arj-től, stb)
d) immár képes egyszerre több fájl nevében a kis "a"-t nagy "A"-ra cserélni. Mondjuk tény, ez az xfce-nél még csak kb 5 éve működik, de már itt is van.
...
x) egy IRC kliens képes megjegyezni a jelszavakat.
Nagy dolgok ezek kérem.
=====
tl;dr
Egy-két mondatban leírnátok, hogy lehet ellopni egy bitcoin-t?
- A hozzászóláshoz be kell jelentkezni
a)
Még nem egészen, mert az új formátumok közül csak a FlatPak-et támogatja (RedHat), a Canonical új formátumát nem és hasonlóan azt a formátumot sem, amit Poettering a systemd-be akar tenni :) Ja, és Dockerül se beszél.
Azt hiszem kéne csinálni egy új csomagformátumot, ami mindenkinek az igényeit lefedi...
BlackY
--
"en is amikor bejovok dolgozni, nem egy pc-t [..] kapcsolok be, hanem a mainframe-et..." (sj)
- A hozzászóláshoz be kell jelentkezni
Már van.
.tar.gz ;)
- A hozzászóláshoz be kell jelentkezni
Kár, hogy nem csomagformátum :)
- A hozzászóláshoz be kell jelentkezni
Hanem?
--
Blog | @hron84
Üzemeltető macik
- A hozzászóláshoz be kell jelentkezni
Hanem tömörített archívum. Egy csomag sokkal több mindenről szól: van struktúrája, amely metaadatokat tartalmaz, nem csak fileok tömörített halmaza.
A tar.gz az nem csomagformátum.
Mint ahogy az RPM sem csak egy cpio archívum: nem minden cpio archívum RPM csomag.
- A hozzászóláshoz be kell jelentkezni
Technikailag a tar.gz is tartalmazhat metaadatokat, illetve lehet strukturaja, ezt senki nem tiltja meg neki. Hogy ezt most nem tar.gz -nak fogjuk hivni, hanem .lnxpk -nak, az tokeletesen irrelevans.
--
Blog | @hron84
Üzemeltető macik
- A hozzászóláshoz be kell jelentkezni
Nem irrelevans, hiszen a *.odt-t is mashogy dolgozod fel klienskent, meg a *.zip-et is, pedig a *.odt is csak egy zip. Meg a *.jar is, meg a *.apk, a *.ipa, a *.appx es meg sok mas minden.
Az, hogy valami formailag micsoda (egy ZIP archivum, egy tar.gz archivum, egy cpio orachivum), vagy szemantikailag micsoda (minek kéne benne lennie és azoknak mi a jelentése) az baromira nem ugyanaz.
A ZIP/tar.gz/xz csak egy mechanizmus. A benne lévő tartalom meg policy.
https://en.wikipedia.org/wiki/Separation_of_mechanism_and_policy
- A hozzászóláshoz be kell jelentkezni
+1
- A hozzászóláshoz be kell jelentkezni
+1
- A hozzászóláshoz be kell jelentkezni
Mivel Linuxon elvben nem is letezik a kiterjesztes intezmenye, ezert ha egy .zip fajlban megvan az a struktura, aminek egy .odt fajlban meg kell lennie, akkor klienskent kutya kotelessegem ugyanugy feldolgozni a kettot.
De nezd meg peldaul az Arch Linux csomagkezeleset (ugy ertem, a binarisoket): a csomagok tar.xz fajlokban vannak, ami ugyebar egy archivum, megis, mivel megvannak azok a metaadatok benne, amiknek ott kell lenniuk, ezert ezek a fajlok teljes jogu csomagokka valnak a csomagkezelo szamara (es forditva: ha nincsenek meg a metaadatok, ez a fajl nem tobb, mint egy tar.xz archivum).
De ha mar a kedvenc peldadat, a Debian csomagkezelot rangattuk elo: attol, mert egy AR archivban van egy data.tar.xz meg egy control.tar.gz es az archivot ugy hivjak, hogy lofasz.deb attol az meg nem lesz egy debian csomag, az tovabbra is egy AR archivum marad. A control.tar.gz -nek ugyanis eleg sok metaadatot kell tartalmaznia ahhoz, hogy az ot tartalmazo archivum Debian csomagnak minosuljon.
Nem a kiterjesztes es nem is az archiv formatum teszi a csomagot csomagga, hanem a metaadat. Hogy a fajlt hogyan hivjak, mire vegzodik a neve, az tokeletesen irrelevans. Ha egy lofasz.tar.gz -ben van olyan metaadat, amit megeszik egy adott tipusu csomagkezelo, akkor az az archivum csomagarchivumnak minosul.
--
Blog | @hron84
Üzemeltető macik
- A hozzászóláshoz be kell jelentkezni
-áh, mindegy-
- A hozzászóláshoz be kell jelentkezni
"Mivel Linuxon elvben nem is letezik a kiterjesztes intezmenye"
Azert nezd meg, hogy egy desktop environment hogyan mukodik.
MIME típus alapján akar felismerni file-okat, viszont a legtöbb MIME-típushoz kiterjesztés alapú glob pattern tartozik. Nem véletlenül, ők sem tudnak jobbat kitalálni.
Nézd csak meg: https://www.freedesktop.org/wiki/Software/shared-mime-info/
" attol, mert egy AR archivban van egy data.tar.xz meg egy control.tar.gz es az archivot ugy hivjak, hogy lofasz.deb attol az meg nem lesz egy debian csomag, az tovabbra is egy AR archivum marad. "
Pont errol van szo: attol, hogy egy lofasz.txt benne van egy lofasz.tar.gz-ben, az meg nem lesz Slackware csomag.
"Ha egy lofasz.tar.gz -ben van olyan metaadat, amit megeszik egy adott tipusu csomagkezelo, akkor az az archivum csomagarchivumnak minosul. "
Probalj meg deb metaadatot betenni .tar.gz-be es a dpkg-val megetetni, mint deb csomagot. Nem fog menni.
A metaadat es az archivum formatum egyutt szamit.
De fentebb azt mondtak, a tar.gz (azaz az archivum formatum) mar eleg, hogy valami csomag legyen. Hat lofaszt.
- A hozzászóláshoz be kell jelentkezni
> Probalj meg deb metaadatot betenni .tar.gz-be es a dpkg-val megetetni, mint deb csomagot. Nem fog menni.
De nem is errol volt szo
> De fentebb azt mondtak, a tar.gz (azaz az archivum formatum) mar eleg, hogy valami csomag legyen. Hat lofaszt.
Ha van olyan csomagkezelo, ami nev es fajllista alapjan kepes csomagot kezelni, akkor eleg lehet.
--
Blog | @hron84
Üzemeltető macik
- A hozzászóláshoz be kell jelentkezni
Kár, hogy ez nem igaz, mert a Slackware pont ilyen csomagokat használ ;)
De persze a forráskódra gondoltam.
Ezért nem is értem ezt a mizériát. Az appok 99%-a megvan a repóban. A maradék 1%-ot meg igazán le tudja szerintem fordítani, akinek kell.
Nem kell a linuxból windows-t csinálni, mert teljesen más. Valahogy a gnome project ezt a 3.0 óta nem képes észrevenni.
Volt már számos ilyen világmegváltó ötlet (autopackage, meg hasonlók), de egyik sem terjedt el.
- A hozzászóláshoz be kell jelentkezni
Slackware-n nincs csomagkezelés. Archívumokat tömörítesz ki a root directoryba. Szép munka, valóban. Ez nem csomagkezelés.
- A hozzászóláshoz be kell jelentkezni
Nem a csomag file formátumán múlik, hogy van-e "rendes" csomagkezelés, hanem magán a csomagkezelőn. A slack féle tar.gz-kben is van description meg post-install script, meg gondolom maga a csomagkezelő is csinál ezt-azt, pl karbantart egy csomag adatbázist/naplót, hogy uninstallálni is lehessen. Csak függőség kezelés nincs, de az sem a tar.gz formátum miatt, mert abban akár lehetne ugyanolyan control file is, mint egy deb csomagban (ami többek között leírja a függőségeket is).
- A hozzászóláshoz be kell jelentkezni
". A slack féle tar.gz-kben is van description meg post-install script"
Na, hát akkor a tar.gz önmagában nem csomagformátum.
Csak akkor lesz az, ha lesz benne description meg post-install script.
Épp ezt mondom: a tar.gz az archív formátum, nem csomagformátum.
- A hozzászóláshoz be kell jelentkezni
Nyakatekert érvelés.
A deb csomag is csak egy archívum, ami a file formátumot illeti. Csak attól lesz csomag formátum, hogy benne vannak a csomagra jellemző egyéb infók.
"Debian packages are standard Unix ar archives that include two tar archives optionally compressed with gzip (zlib), Bzip2, lzma, or xz (lzma2): one archive holds the control information and another contains the installable data.[2]"
- A hozzászóláshoz be kell jelentkezni
Ez így van. Épp ezért nem igaz az, hogy minden tar.gz formátumú file egy csomag, azaz a tar.gz az nem csomagformátum.
Ellenben minden deb formátumú file az csomag (mert a deb formátum nem csak a tömörítést és archiválást, hanem a szükséges tartalmat is definiálja).
- A hozzászóláshoz be kell jelentkezni
"Ez így van. Épp ezért nem igaz az, hogy minden tar.gz formátumú file egy csomag, azaz a tar.gz az nem csomagformátum."
És? Senki nem állította, hogy minden tar.gz file egy "csomag". Nem is ezen indult a vita. Te azt mondtad, hogy slackware-n nics csomagkezelés, mert tar.gz formátumot használ és csak kitömörít a rootba:
"Slackware-n nincs csomagkezelés. Archívumokat tömörítesz ki a root directoryba."
Én meg elmagyaráztam, hogy de, attól még van csomagkezelés, mert a debian csomagokhoz hasonlóan a slack tar.gz csomagok sem "egyszerű" archívumok, mert tartalmaznak csomag információt is, ami alapján a csomagkezelő dolgozik.
- A hozzászóláshoz be kell jelentkezni
Megsúgom, hogy slackwaren minden csomaginformáció opcionális.
Ha nincs benne a tar.gz-ben semmi sem, csak fileok, Slackware-en az is egy "csomag".
Ennyire van ott csomagkezelés.
- A hozzászóláshoz be kell jelentkezni
Ha nincs benne csomaginformáció, akkor az nem "csomag" és lényegében a csomagkezelőt megkerülve telepíted. Ettől még van csomagkezelő.
Ugyanígy tar.gz-t debianra is tudsz "telepíteni", megkerülve a csomagkezelőt. Kicsomagolod és kész, minden a helyére kerül, csak a csomagkezelő nem tud róla.
- A hozzászóláshoz be kell jelentkezni
Azaz a tar.gz nem csomagformátum. Hanem archiválási formátum.
Mint ahogy a ZIP file sem lesz ODT dokumentum, csak ha speckó a felépítése.
- A hozzászóláshoz be kell jelentkezni
> És? Senki nem állította, hogy minden tar.gz file egy "csomag".
#comment-2022947
ugyanazt a topikot olvassuk?
itt konkrétan az áll, hogy a targézé egy csomagformátum.
--
blogom
- A hozzászóláshoz be kell jelentkezni
Már azon vitatkozunk, hogy min vitatkozunk?
A tar.gz egy archívum, ha technikailag mint egy fájlt nézzük. Ahogy a zip is, vagy az ar (deb) is. De amint a tar.gz-be a csomagkezelő által értelmezhető egyéb információkat is becsomagolunk (description, post install script, esetleg függőségek leírása), onnantól miért ne nevezhetnénk "csomag"-nak és miért ne kezelhetné ezt az erre felkészített csomagkezelő? (lásd slack)
A deb is pont így működik. Kutya közönséges ar fomrátumú általános célú archívum, deb kiterjesztéssel. Nem direkt csomagkezelő formátum. Attól lesz "csomag", hogy az archívumba bele vannak mentve a csomag infók is.
Egyébként én ezen kezdtem el vitatkozni:
"Slackware-n nincs csomagkezelés. Archívumokat tömörítesz ki a root directoryba."
- A hozzászóláshoz be kell jelentkezni
Szvsz egyszerusitsuk le: minden archivum csomag, amit valamilyen csomagkezelo felismer csomagkent. Ha van olyan csomagkezelo, ami csak kibontja a gyokerre a csomag tartalmat (lasd meg: slackware), az a fenti allitast nem invalidalja, mivel az ilyenek lete inkabb kivetel a szabaly alol, semmint a szabalyt alkoto dolgok osszege.
Egyebkent egy .tar.gz eseten siman el tudom kepzelni, hogy van olyan csomagkezelo, ami a csomag neve es tartalma alapjan kepes felepiteni a csomag metaadatait, vegulis a legtobb csomagfajl semmi egyebbol nem all, mint fajllistabol meg a csomag neve-verzio-architektura kombinaciobol. A fuggosegi informaciok nem kell, hogy szuksegszeruen a csomag reszet kepezzek.
--
Blog | @hron84
Üzemeltető macik
- A hozzászóláshoz be kell jelentkezni
(Csak kiegészítés: a FreeBSD csomagformátuma talán a 9-es vezióig tar.gz volt - most tar.xz - és a többi csomagkezelőhöz hasonlóan ott is az archívumban levő speciális nevű fájlokban szerepeltek a metaadatok.)
=====
tl;dr
Egy-két mondatban leírnátok, hogy lehet ellopni egy bitcoin-t?
- A hozzászóláshoz be kell jelentkezni
"Nem kell a linuxból windows-t csinálni, mert teljesen más."
Csak azért, mert valakik azon dolgoznak, hogy kényelmes és átlagembereknek könnyen használható legyen egy rendszer még nem jelenti azt, hogy Windows-t csinálnak belőle. Vagy azt akarod mondani, hogy a linux sose lehet igazi rendszer az átlag usernek?
Egyébként nem muszáj átlag userről beszélnünk. Nekem meg se kottyan forrásból lefordítani valamit. De mégsem teszem ha nem muszáj. Fáj telepíteni a sok dev csomagot, fáj folyton figyelni hogy van-e újabb verzió valamiből, és ha van újra fordítgatni. Minek? Miért ne legyen kényelmes?
- A hozzászóláshoz be kell jelentkezni
"Nem kell a linuxból windows-t csinálni, mert teljesen más. Valahogy a gnome project ezt a 3.0 óta nem képes észrevenni."
A Gnome project az OS X-et másolja, nem a Windowst, nem tudom feltűnt-e.
És azért, mert az OS X (most már macOS) a legsikeresebb desktop UNIX.
- A hozzászóláshoz be kell jelentkezni
A mockupok alapjan A-tol Z-ig meritenek minden ismertebb OS dizajnjabol. Ennek koszonhetoen a GNOME desktop egy elegge sajatos hibrid lett, amibe nekem pl. bele kellett szoknom, hiaba ismerem az OS X-t. Az szerintem tok irrelevans, hogy a legsikeresebb desktop UNIX, UI-ra nem sok kihatasa van annak, hogy megis milyen a rendszer mukodesi elve, foleg OS X eseten ami a bevett *nix GUI stacket total lecserelte, az Androiddal, Chrome OS-el egyetemben.
- A hozzászóláshoz be kell jelentkezni
Engem zavar csak ebben a csomagolásdi-konténeresdiben, hogy ez szembeköpi a DLL-ek előnyét, a kevesebb memóriafölhasználást?
Persze tudom, ma már, amikor a telefonokban is több GB memória van, ez talán nem olyan nyomós szempont.
--
„Spiró ótvar, Konrád átok, Nádastól meg mindjárt hányok!”
- A hozzászóláshoz be kell jelentkezni
De megakadályozza azokat a függőségi problémákat amik a shared lib-ek miatt előjönnek. Valamit valamiért.
- A hozzászóláshoz be kell jelentkezni
Lehetne statikusként is fordítani az appot, és akkor nincs shared lib sem.
- A hozzászóláshoz be kell jelentkezni
Csinálják is sokan, és ugyanott vagyunk a memóriapazarlás tekintetében.
Cserében ezek a konténeres megoldások adnak még néhány plusz jóságot.
- A hozzászóláshoz be kell jelentkezni
- A hozzászóláshoz be kell jelentkezni
Szerintem ezt már a szám alapján mindenki ismeri, kattintani sem kell :)
- A hozzászóláshoz be kell jelentkezni
Az nem csomagformatum, hanem az egesz Unix concept tovabbgondolasa, aminek az egyik mellekhatasa pont az amit a flatpak es tarsai kft. eppen vakargat. Csak ebben a mokolasban minden marad a sajat helyen, nincs egybegyurva az egesz. Ha egy szoftver azt mondja, hogy neki bizony a foobol csak a 32 bites, 0.2-es verzioju az elfogadhato, akkor szepen megkapja azt, ha pedig nincs, akkor telepul a tobbi foo melle. De ez csak egy szelete a conceptnek. Es minek utan kesz sincs, igy tamogatni sem tudja a gnome.
- A hozzászóláshoz be kell jelentkezni
Látom, többeknél kiugrott az szarkazmus-detektor... :)
Lacyc3: igen, erre utaltam a kb. szó szerinti idézettel ;) [use case vs. igény, de ja...]
pacm4n: olvastam a koncepciót, többé-kevésbé tetszett is, a fenti inkább a hírnek szólt, hogy jujj, van flatpak, akkor már mindent támogatunk, ami nincs egészen így. (azt meg külön flamebaitnek szántam, hogy behoztam a systemd-t is mellé, ahhoz kivételesen nem csak az kell és ott a systemd mint építőelem és nem mint rendszer jelenik meg. Sajnos fordítva sikerült, a haterekre számítottam, hogy ugranak :) )
BlackY
--
"en is amikor bejovok dolgozni, nem egy pc-t [..] kapcsolok be, hanem a mainframe-et..." (sj)
- A hozzászóláshoz be kell jelentkezni
Èn mindig ezen szarok be "keményen dolgoztunk azon, hogy...".
--
robyboy
- A hozzászóláshoz be kell jelentkezni
a) megoldották a linuxosok nagy problémáját, az eltérő csomagformátumot
Az arch -osok nem hallottak ilyesmi problémáról
--
arch,debian,osmc,android,windows
- A hozzászóláshoz be kell jelentkezni
Dehogynem.
- A hozzászóláshoz be kell jelentkezni
Én 3 éve folyamatosan Arch -ozok, munkára (is), és még gyakorlatilag soha egyetlen dolgot se kellett kézileg felmatyizni a gépre.
https://www.archlinux.org/packages/
https://aur.archlinux.org/
Kérlek mondj egy dolgot, ami 20 embernél többet érdekel és nincs róla csomag.
--
arch,debian,osmc,android,windows
- A hozzászóláshoz be kell jelentkezni
Visual Studio Code
RPM/DEB csomagot szállít belőle az MS, de amúgy open source, lehetne belőle csomag, de nincs
https://github.com/Microsoft/vscode
Brackets
https://github.com/adobe/brackets
Ezek eléggé elterjedt editorok.
Persze Atom csomag van.
- A hozzászóláshoz be kell jelentkezni
https://aur.archlinux.org/packages/visual-studio-code/
https://aur.archlinux.org/packages/brackets/
Vagy az aur nem játszik?
- A hozzászóláshoz be kell jelentkezni
User-produced content mióta az OS része?
" Any use of the provided files is at your own risk."
Ugyanmár, az AUR ugyanolyan 3rd party content, mint a PPA vagy az EPEL.
- A hozzászóláshoz be kell jelentkezni
Innen indultunk:
- "soha egyetlen dolgot se kellett kézileg felmatyizni a gépre."
- "mondj egy dolgot, ami 20 embernél többet érdekel és nincs róla csomag."
Ki beszélt arról, hogy az OS részének kell lennie? Ki mondta, hogy közösségi csomagok nem csomagok?
Túl rég archoztam, most látom, hogy nem annyira triviális az aur csomagok telepítése mint amire emlékszem, hogy azt ne nevezhessük "felmatyizásnak".
- A hozzászóláshoz be kell jelentkezni
Az AUR-ból telepités igy néz ki:
yaourt visual-studio-code
yaourt brackets
Aztán felmegy és jónapot. Igen, user supplied cuccok ezek, de a közösség úgymond QA alatt tartja. Előfordul hogy nem megy fel, mert valami nem stimmel, de évek alatt alig párszor láttam ilyet, és pár órán belül javitják.
Szóval továbbra is azt állítom hogy arch -ra _nem_ kell kézileg felmatyizni semmit.
--
arch,debian,osmc,android,windows
- A hozzászóláshoz be kell jelentkezni
Ilyen alapon egyetlen disztrót sem érint a csomagprobléma. :) Arra próbáltam reflektálni, hogy azért létezik kapásból AUR, mert az Archosok hallottak erről a problémáról, és workaroundolják. És ez elmondható az összes disztribúció, összes community tárolójáról, max a monitor mögött ülő lacika nem tud erről a problémáról, de ettől még rengeteg erőforrás van amögött, hogy ez számára ne tűnjön fel. Sokkal egyszerűbb lenne a disztribúciók és a community-k élete, ha a desktop alkalmazásoknak lenne végre egy szabványos terjesztési hálója, egy mindenhol működő ultimate edition megoldással/csomagformátummal. És lehet erre is linkelni az xkcd vonatkozó anyagát, mert sajnos itt is ezerfelé oszlik az erőforrás, flatpak (freedesktop.org), snap (ubuntu), appimage, és még jön majd Poettering és a systemd-sek elképzelése is, valószínűleg szintén freedesktop.org ajánlásként, ami talán majd standard lesz és több, mint két évtized után létrejön majd egy alap amire rámondhatjuk, hogy az a Linux OS.
- A hozzászóláshoz be kell jelentkezni
" több, mint két évtized után létrejön majd egy alap amire rámondhatjuk, hogy az a Linux OS."
Speciel akkor már inkább a GNU felé kéne tendálni, az az eredeti open-source Unix-like OS projekt.
- A hozzászóláshoz be kell jelentkezni
Egyik nem zárja ki a másikat, a GNU elképzelése már manifesztálódott a Guixban. De jóideje már a Linux Foundation féle Linux Standard Base is jelen van, ami a POSIX és a Single UNIX Specificationre illetve GNU-ra alapoz. Viszont utóbbi pont nem deklarálja azokat, amiket a freedesktop.org igyekszik pótolni.
- A hozzászóláshoz be kell jelentkezni
" c) végre külső alkalmazás nélkül kicsomagol zip-et és targézát (aztán majd jól pofára esnek - mint a FreeBSD-féle libarchive - egy-egy spécibb ZIP-formátumtól, vagy rar-tól, 7zip-től, arj-től, stb)"
Na ennek utánanéztem.
Eddig az történt, hogy a Nautilus a file-rollert hívogatta felparaméterezve, hogy akkor $ezt $ide, $ilyen_formátumba csomagold össze (vagy ki), és a file-roller a saját, tizenéve fejlesztgetett kútfeje alapján ezt lefordította a különféle parancssoros csomagolók kapcsolóira, és azokat hívogatta.
Most a file-rollert kivették ebből a képből (de az egész gnómból - még - nem, noha láttam a devel listán ilyen ötletet is), fogták a libarchive-ot, tettek fölé egy GTK-s előtét libet, és azt drótozták bele a Nautilusba.
Szóval egy látnok vagy, pontosan úgy fog fejre állni, mint a libarchive :).
___
Arany János: Grammatika versben
- A hozzászóláshoz be kell jelentkezni
Látnoki plecsnit a mellyemre!
=====
tl;dr
Egy-két mondatban leírnátok, hogy lehet ellopni egy bitcoin-t?
- A hozzászóláshoz be kell jelentkezni
http://nedudu.hu/data/_uploaded/image/cartoon/zahylatnok.jpg
--
A főnököm mindig megtartja amit ígér, ha pénzt ígér azt is!
- A hozzászóláshoz be kell jelentkezni
- A hozzászóláshoz be kell jelentkezni
és ezáltal növelje az elérhető alkalmazások számát.
Nem az alkalmazások mennyiségével van gond. Hanem az alkalmazások minőségével, integráltságával. Ezen a Flatpak sem segít. Mondhatja magáról a Debian, a CentOS, a Fedora meg mindenki, hogy default telepítésben harmincezer....ööö...háromszázezer csomagot telepít - ha azokat a kutya nem használja, mert nehezen kezelhetőek.
- A hozzászóláshoz be kell jelentkezni
Na igen, es ezen a KDE-GNOME szembenallas sem segit.
--
Blog | @hron84
Üzemeltető macik
- A hozzászóláshoz be kell jelentkezni
Szembenállás? Van hely, elférnek azok egymás mellett is.
--
♙♘♗♖♕♔
- A hozzászóláshoz be kell jelentkezni
Nem sikerult megerteni a problemat latom. Arrol van itt szo, hogy a ket desktop kornyezet nem igazan akar kozos dolgokert kozosen kuzdeni, hogy legalabb a 3rdparty appok integracioja konnyebb legyen. Mar az is nagy szo, hogy a KDE egyaltalan kepes tamogatni a Gtk/GNOME appok talcaikonjait, de ennel tobbre nem telik toluk. Se a GVFS-t se a dconf-ot nem tamogatja, mindenre van sajat alternativaja, ami meg csak egeszen veletlenul sem kompatibilis a GNOME megoldasaival (tegyuk rogton hozza, ez forditva is igy van, csak ott KIO meg KConf a ket erintett rendszer). Vagyis, ha 3rdparty-kent desktop-fuggetlen appot akarsz kesziteni, akkor keszitsd fel KDE-re. GNOME-ra, Enlightenment-re, meg a jo eg tudja meg mire. Megaharaposlo.
--
Blog | @hron84
Üzemeltető macik
- A hozzászóláshoz be kell jelentkezni
Erre talaltak ki a freedesktop.org "szabvanyait". Aztan erdekes modon, sokan utaljak ezeket a dolgokat.
- A hozzászóláshoz be kell jelentkezni
+1 Raadasul a legtobb kereskedelmi szoftver pont magasrol tesz a KDE, GNOME dizajn iranyelvekre, ez egy nem letezo problema a fejlesztok szamara. Arrol nem is beszelve, hogy ma mar hasonloan jelentektelen user bazissal rendelkezik a GNOME-on kivul minden asztali kornyezet.
- A hozzászóláshoz be kell jelentkezni
"ma mar hasonloan jelentektelen user bazissal rendelkezik a GNOME-on kivul minden asztali kornyezet"
lol
Mutass erről valamit ami alátámasztja :D
- A hozzászóláshoz be kell jelentkezni
Nem kell lolozni. Minden nagy diszno alapertelmezetten GNOME-ot hasznal, a magasan legnagyobb desktop reszesedessel es OEM tamogatottsaggal rendelkezo Ubuntu is, egyeduli kivetel az Opensuse, amivel szemben ott van _minden mas_. A desktop hasznalatrol pedig felesleges szamszeru adatokat kerni, hacsak nem az volt az eredeti szandekod is, hogy miutan ugysem lehet ezt grafikonokkal bozonyitani, ezert aztan majd jol odamondhasd milyen hulyeseget is allitottam, eljatszva a hupon bevett "IT laikus" szerepet.
- A hozzászóláshoz be kell jelentkezni
Ez az érvelés rendben is van, csak sokan nem a default-ot használják... olyan szinten, hogy a Debian-nál két kattintás a KDE-t tenni a GNOME helyett. Ubiból ott a Kubuntu. Fedorából a KDE Spin. Ha jól rémlik a Manjaro (ami gyakorlatilag a desktop Arch :) ) KDE-s. ...
A másik oldalról nézve: többnyire egy-egy szoftver fejlődése két dolog miatt mehet - valaki marha sok pénzt dönt bele (ha nem közvetlenül, akkor fejlesztőkkel emberórában, ahogy a fizetős disztrók alkalmazottai ráállnak egy-egy szoftverre), vagy sokan használják (olyanok, akik adnak vissza a közösségnek). AFAIK tonnaszámra egyik cég se talicskázza hozzájuk a pénzt/fejlesztői órákat (https://ev.kde.org/getinvolved/supporting-members.php - ha magánszemélyektől is tarhálnak, az gyanús :) ), vagyis marad az utóbbi.
Márpedig azért azt, hogy a KDE SC-t nem fejlesztik legalábbis megkérdőjelezhető lenne állítani, még az ötös is egy objektíven nagyobb tudású DE/alkalmazás-gyűjtemény, mint egy GNOME.
BlackY
--
"en is amikor bejovok dolgozni, nem egy pc-t [..] kapcsolok be, hanem a mainframe-et..." (sj)
- A hozzászóláshoz be kell jelentkezni
Tisztában vagyok minden felvetett ponttal, de átlagbinugzos, ha fel is rak valamit, ami nem Ubuntu, akkor általában a default mellett fog dönteni. Ez nyilván nem reprezentatív felmérés, de ha a legnagyobb online "fórumot" nézzük (reddit), és az IT-től teljesen irreleváns subredditeket, akkor ha bele is fut az ember valamilyen linuxos screenshotba, és az éppen nem Ubuntu, akkor is még mindig GNOME, általában Mint/Cinnamon. De jobb híján most rákerestem a Lifehacker szavazására, ahol a GNOME 67,38 százalékot visz el a 100-ból, nyilván ez sem az igazi, de míg nem telefonálnak haza a környezetek, addig maradnak ezek. A definitív Manjaro desktop egyébként pont egy harmadik szereplő, az Xfce. :) Habár szerintem egy kezdőnek inkább az Arch Anywhere telepítőszkript ideálisabb, ha fel tud hülyéskedni egy Win XP-t valaki, akkor az is menni fog és aztán nem kell attól rettegnie, hogy Manjaroék éppen mikor unják meg a fejlesztést.
Szerk.:
Éveken keresztül Slackware + KDE user voltam, a 3-mas szériától kezdődően, ismerem és szeretem is. :) Csak leírtam a véleményem a mostani jelentőségéről.
- A hozzászóláshoz be kell jelentkezni
http://hup.hu/szavazasok/20101201/hovd_2010_kedvenc_desktop_kornyezet
http://hup.hu/szavazasok/20111210/hovd_2011_kedvenc_desktop_kornyezet
http://hup.hu/szavazasok/20121209/hovd_2012_kedvenc_desktop_kornyezet
http://hup.hu/szavazasok/20131212/hovd_2013_kedvenc_desktop_kornyezet
http://hup.hu/szavazasok/20141215/hovd_2014_kedvenc_desktop_kornyezet
http://hup.hu/szavazasok/20151213/hovd_2015_kedvenc_desktop_kornyezet
- A hozzászóláshoz be kell jelentkezni
Igen, tudok erről a szavazásról, ahol az X11 window managerek verik az Aqua-t, és a tiling wm-ek látható részt képviselnek a tortában. Nyilván tükrözi a valóságot. Én még a fentebb linkelt ~10 ezres mintavétellel rendelkező Lifehackeres szavazásra sem bíznám az életem, nemhogy egy párszáz fősre, ami a valósággal ellentétes adatokat prezentál. (Kapásból desktopon OS X-t többen használnak, mint az összes X11 *nix környzetet együttvéve)
- A hozzászóláshoz be kell jelentkezni
6 évet linkeltem be, csak hogy a trendet próbáljam érzékeltetni :)
- A hozzászóláshoz be kell jelentkezni
Szerintem minden HUP user követi. :) Én 10 vagy 11 éve, passz. Ha a poweruserekről beszélünk, akkor nyilván más a leányzó fekvése, ha pedig arról, hogy a poweruserek mekkora részt képviselnek a userek halmazban, akkor pedig megint más.
- A hozzászóláshoz be kell jelentkezni
"jelentektelen user bazis" mert "Minden nagy diszno alapertelmezetten GNOME-ot hasznal"
Nagy disznók:
1. Mangalica - Default GNOME alapú DE
---Userek: 60 % használja a defaultot, 40 % nem, hanem mást
2. Csüngőhasú - Default GNOME alapú DE
---Userek: 65 % használja a defaultot, 35 % nem, hanem mást.
3. Politikus - Default nem GNOME alapú DE
---Userek: 60 % a defaultot használja, 40 % mást.
Ez a példa szemlélteti a legjobban, hogy nem lehet ilyen következtetést levonni, hogy a GNOME-on kívül minden más DE userbázisa jelentéktelen.
1. Honnan tudod melyik a nagy disznó? Egyik régióban ez, a másikban az. Lehet, hogy valami kínai, vagy indiai általunk nem is ismert disznónak nagyobb bázisa van, mint pl a Mint-nek...
2. Honnan tudod, hogy hányan használnak a defaulton kívül mást egy disznón belül?
3. Ha van hivatalos más DE kiadása is egy disznónak, melyik a default, mit jelent az? Egyik disznónál ez lehet egyértelmű, de a másik nagy disznónál is? (ha már tisztázva van, hogy egyáltalán melyik a nagy disznó)
4. Mi lesz, ha a Unity tényleg áttér Qt-re, akkor hova kell számítani? Ha nem a GNOME családba, akkor is még a GNOME a jelentős egyedül?
Szerintem ez a téma finghegedülés csupán. De ilyen határozottan állítani valamit egy finghegedülős témában az inkább vágyálom.
- A hozzászóláshoz be kell jelentkezni
Ez zsenialis volt, koszi. :) Engem teljesen hidegen hagy a reszesedes, magyaran vagyalmaim sincsenek ezzel kapcsolatban. Chrome OS az elsodleges desktopom, amin van chrootban egy Ubuntu Xfce-vel, a PC amin pedig produktivkodom az egy CentOS. En csak mellekesen irtam le azt ami mar sok esetben egyertelmuve valt. Az alapbeallitasok pedig inkabb feltetelezhetoek, mint az egyeb variaciok, ez nemcsak itt, de mindenhol igy van. A widgetrendszerrol pedig megcsak nem is tettem emlitest, a Unity sajat desktop kornyezettel fog rendelkezni, evidens hogy onnantol nem egy gnome shell lesz. A lenyeg egyebkent azon volt, hogy a kereskedelmi alkalmazasok szarba sem veszik a GNOME, KDE UX guideline-okat, es ezt nem kell bizonygatni, mert ez egyertelmu.
- A hozzászóláshoz be kell jelentkezni
A nevető harmadik meg a Unity. Sztem Unity-nek van a legnagyobb install base-e.
--
GPLv3-as hozzászólás.
- A hozzászóláshoz be kell jelentkezni
A Unity egyelore csak egy gnome shell, nem kornyezet.
- A hozzászóláshoz be kell jelentkezni