Új hozzászólás Aktív témák

• #81333 urandom0 senior tag K0zm0 #81329

  Új Válasz 2021-11-23 05:59:48 #81333

  Új hozzászólás

  Összes hozzászólása itt Válaszok az összes hozzászólására itt Válaszok erre a hozzászólásra

  Privát üzenet küldése

  

  urandom0

  senior tag

  válasz K0zm0 #81329 üzenetére

  Jó cikk, és alapvetően igazak a felvetései, de azért vannak benne butaságok.
  Az, hogy a sandboxolt programok hozzáférnek a fájlrendszerhez, azért van így, mert a felhasználók jellemzően fájlokkal dolgoznak, amiket el kell tudniuk érni. Próbáljon meg kiadni olyan Gimpet, ami alapértelmezetten nem fér hozzá a /home-hoz, és nézze meg, mit szólnak hozzá a felhasználók...
  Másrészt totális ellentmondás az, hogy először azért ekézi a Flatpakot, mert nem a rendszer szolgáltatásait használja, hanem mindenből sajátot hoz, utána meg a portálokat szidja, miközben azok épp azért jöttek létre, hogy az alkalmazás jobban tudjon integrálódni a rendszerbe.
  Amiatt sem célszerű ekézni a rendszert, hogy ezeknek a standalone csomagformátumoknak szükségük van egy-egy service-re, mert ennyi elővehetjük a .deb-et, hisz annak is kell apt meg dpkg, elővehetjük az .rpm-et, mert nyilván annak is kell egy program, ami kezelni tudja, elővehetjük az Arch-ot a pacman miatt, meg a Manjarot a pamac miatt...
  Maga a cikkíró nagyon leragadt a visszafelé kompatibilitás problémáján, miközben szerintem ennél sokkal nagyobb gond a disztribúciók és az asztali környezetek közti különbségek. Ezek okozzák az igazi problémát. Windows-on nincs probléma ebből, mert ha WinRT appot írsz, akkor ott a WinRT API fix halmaza, amire lehet alapozni. Vagy ha .NET 5 kell, akkor számíthatsz rá, hogy minden gépen ott van, vagy ha nincs, a Windows automatikusan le tudja tölteni.
  Ez az, ami Linuxon nincs. Fogalmad sincs, hogy a célgépen van-e GObject vagy nincs, van-e Seahorse, vagy KWallet, vagy egyik sincs, van-e bármilyen embedded HTML megjelenítő, mondjuk WebKitGTK, QtWebKit, KHtml... plusz nehezítő tényező a csomagformátumok és a függőségek különféle változatai.

  Fejlesztőként két dolgot lehet tenni, vagy azt mondjuk, hogy csak és kizárólag egy adott disztrón, mondjuk Ubuntu 21.04-en fog menni a programunk, semmi máson (sokan ezt csinálják, de ez nekik is rossz, mert felhasználókat buknak), a többiek meg oldják meg, ahogy akarják... vagy fogjuk valamelyik standalone csomagformátumot, és abban tesszük közzé a programot. És akkor előre-hátra 4-5 disztróverzión belül biztosan megy a program, az összes disztrón megy a program ami támogatja az adott csomagformátumot (kb. mindegyik), és van mögötte egy egységes store, mint pl. a flathub, és akkor nem kell küzdeni a teljesen eltérő disztrók és asztali környezetek különbségeivel.

  A visszamenőleges kompatibilitás önmagában nem lenne megoldhatatlan, nyugodtan el lehet tárolni a korábbi libverziókat, mint ahogy sok esetben így is van (egyébként Windows-on is, a WinSxS mappában). A cikkben példaként hozott Master Pdf Editor épp ezért működik, mert libek egy adott verzióját igényli. De egy nem systemd-es rendszeren már lehet, hogy nem indulna el, mivel a libsystemd.so.0-ra is hivatkozik...

Új hozzászólás Aktív témák