- D1Rect: Nagy "hülyétkapokazapróktól" topik
- Luck Dragon: Asszociációs játék. :)
- vrob: Az IBM PC és a játékok a 80-as években
- bambano: Bambanő háza tája
- Gurulunk, WAZE?!
- f(x)=exp(x): A laposföld elmebaj: Vissza a jövőbe!
- vrob: 1991 - játék a PC-n
- gban: Ingyen kellene, de tegnapra
- Argos: Szeretem az ecetfát
- sziku69: Fűzzük össze a szavakat :)
Új hozzászólás Aktív témák
-
válasz
urandom0
#209
üzenetére
De nem csak te létezel a földön, és nem csak a te használati eseted létezik, van még rajtad kívül pár millió Linux user, egészen eltérő elvárásokkal.
Ezt már én is akartam írni neki.
Szóval akkor ez a Debian is úgy biztonságos, hogy közösen elhisszük, hogy az... Testinget meg tényleg nem kéne használni, mert a biztonsági frissítések oda kerülnek be utoljára, ami több napos csúszás is lehet.
-
bambano
titán
válasz
urandom0
#209
üzenetére
"De pont ez nem tudta nekem eddig még senki sem elmagyarázni": Bőven kaptál magyarázatot, ne azt mond, hogy nem magyarázták meg, azt mond, hogy nem értesz vele egyet.
"(gondolom, rájuk gondoltál)": nem kell találgatnod, le volt írva, hogy kikre gondoltam.egyébként meg: aki beilleszkedik a debianos közösségbe és megtartja a szabályokat, az debian karbantartó. aki nem illeszkedik be és egyetlen célja, hogy áthágja a unixos és a debianos szabályokat, és hogy meghajlítsa a közösséget maga felé, az gyüttment.
"De nem csak te létezel a földön, és nem csak a te használati eseted létezik": amit én akarok, az nem korlátoz másokat. amiket ők akarnak, az korlátoz engem.
"egészen eltérő elvárásokkal": van párszáz disztró, válasszon másikat magának. vagy windowst, engem nem izgat. rontsák el a redhatot, ahogy akarják. Nekem megfelel, hogy ha az alkalmazása nem indul el flatpak nélkül, akkor majd én reszelek rajta, hogy menjen. Nekem ennyit megér a stabilitás.
-
válasz
urandom0
#188
üzenetére
Mióta van Systemd azóta meg főleg, bár ezt sem tudta még senki értelmesen nekem elmagyarázni, hogy miért baj a Systemd meg, hogy miért kellene Poetteringet lecsukatni. Csak megy a hümmögés meg a mellébeszélés meg a semmivel alá nem támasztott gyűlöletbeszéd.
Szokásos Linuxos hozzáállás, még a saját fajtánkat is utáljuk. -
bambano
titán
válasz
urandom0
#191
üzenetére
"Én meg pont azt nem értem, hogy miért bízik mindenki ennyire a disztrók saját tárolóiban.": te honnan veszed, hogy ennyire bízunk a disztrók saját tárolóiban?
Vannak feladatok. Megnézi az ember a választási lehetőségeket, azok paramétereit és a hosszabb távú kilátásokat. Ez így együtt megad egy kockázati szintet. Vagy elfogadod valamelyik cucc kockázatát, vagy nem lesz megoldva a feladat. De arra senki nem számít, hogy jönnek gyüttmentek, és ezt a kockázatot jelentősen megnövelik. Nem azért "bízok" a debian repókban, mert hiszek benne, hanem mert valamelyiket el kell fogadni ahhoz, hogy be tudd kapcsolni a pc-det meg a szerveredet. De miért kellene örülni annak, hogy az egyébként sem alacsony kockázatot flatpakkel, systemd-vel meg hasonló marhaságokkal fellövik az egekbe? Nekem voltak szervereim, amik nemrég még 6-os debiant futtattak. *MINDENT* meg tudtam csinálni rajtuk, amit a munka igényelt. Minek változtatni? A l'art pour l'art változtatás csak kockázat és költség, ablakon kidobott munka.Maximum az történhet, hogy úriember nem piszkol oda, ahonnan eszik. Ha nem tetszik neki a pénzkeresetre használt oprendszere, akkor csendben marad. ugye.
-
válasz
urandom0
#181
üzenetére
Mondtam mar, hogy kerdezd meg oket. Nemigen ertem egyebkent ezt a fajta bizalmatlansagot a Debian fele, mikor vakon bizol a Flathubban, pedig ott nincs biztonsagi ellenorzes, raadasul a Debian repository-k 1st party, a Flathub meg akarmilyen disztribucion 3rd party - teljesen mellekes, hogy Te mit gondolsz rola. Code review eseten egyebkent sokat lehet optimalizalni a folyamaton, plane, hogy a csomagok egy resze alig 1-2 KB terjedelmu, egy bevizsgalt csomag eseten meg utana eleg a diff-eket megnezni.
-
válasz
urandom0
#185
üzenetére
Így van, amit tudok, azt igyekszem saját repókból megoldani, de vannak olyan dolgok, amiket egyszerűen máshogy nem tudok... Törekszem erre a... nem is tudom hogyan nevezzem, talán izoláltságra? Lásd Android. Szerintem az egy ilyen szempontból teljesen jól használható rendszer. Annál tökéletesen működik az elszigeteltség, viszont ott már eleve akkora a kínálat, hogy sose fogy el és igen gyorsan elérhető minden a Play Áruházból, nincs szükség arra, hogy bármit is külső APK-ból telepítsek.
Ennek ellenére Debianon és Minten is számomra elkerülhetetlen. -
válasz
urandom0
#181
üzenetére
Viszont a gyakorlatban alig van olyan ember, aki csak a repó által biztosított csomagokat használja. Ha valaki töltött le valaha az életben egy Gnome kiterjesztést, egy KDE témát, egy akármilyen .sh fájlt, egy scriptet a Gimphez, bármilyen Python vagy NodeJS modult... akkor ő már eleve veszélynek tette ki magát. De akár egy szimpla böngésző-kiegészítő is lehet veszélyes.
Gnome kiterjesztések böngésző kiegészítőjét felraktam Firefoxra, aztán rájöttem, hogy talán mégse kéne. Végül szerencsére Debianon meg is találtam a szükséges Gnome kiterjesztéseket, benne vannak a Bookworm repójában. Szuper. Ennek ellenére kénytelen vagyok külső szoftvereket használni (igen, kénytelen). Lemezképek kiírásához nekem a Balena ETCHER vált be a legjobban, ezt a gyártó honlapjáról lehet csak letölteni. Az Epson fotószkenneremnek szintén nincs közösségi Linuxos drivere, egyedül az Epson honlapjáról letölthető csomagokkal képes működni. Lemezsebesség mérésére a KdiskMarkot Githubról lehet letölteni (AppImage). Videókártya benchmarkhoz a Superposition az Unigine honlapjáról tölthető le.
-
totron
addikt
válasz
urandom0
#181
üzenetére
De azt melyik sorom üzente számodra valaha is, hogy ilyen fajta lennék? Hogy az csipegetem ki a világ történései közül ami nekem tetszik? A tényállás az, hogy ettől pont hülyét kapok és nem egy 'önsorsrontásom' volt már, ami ennek kiváló tanúbizonysága. Talán nem ártana egy személyes sörözés, mert így, nem semennyire ismerve egymást túl sok a fölös félremenés.
Neked is leírom, hogy magamra gondoltam, nem vagyok már topon fogalmazásilag, ne Rowon félreértelmezését vidd tovább, köszönöm.
Mindezek ellenére nem haszontalan, hogy körbejáródik a flatpak/egyéb csomagz témaköre. -
válasz
urandom0
#151
üzenetére
Aligha hiszem, hogy van okod ilyesmit kijelenteni. A megbizhatosag magaban foglalja a biztonsagot is es nem veletlenul letezik a Debian Security Team. Termeszetesen soha senki nem jelentette ki - ebben a topicban sem -, hogy nincs es nem lesz a Debianban sebezhetoseg, mindazonaltal szeretnek ramutatni, mekkora ostobasag volt a linked: 2023. junius 10-en jelent meg a jelenlegi stable es belinkeltel tobbnyire 2024-es CVE-ket. Kabe nagyjabol 1-2 lehet ezekbol a CVE-kbol olyan, ami a kiadas idejen tenylegesen detektalhato lett volna. Mindezeken tul az sem mindegy, hogy egy sebezhetoseg CVSS score-ja mondjuk 4.0 alatt van, vagy sem. Nagyon sok helyen a medium besorolast kapott serulekenysegek nem showstopperek, hanem a javitas megerkezeseig mitigalandok vagy security sign-off-ot igenylok.
Nemcsak a csomagok/modulok, hanem a teljes szoftverek biztonsagat sem lehet garantalni, de vannak olyan eszkozok, amelyek meg forraskod formaban kepesek ramutatni vagy a programozasbol szarmazo kozvetlen biztonsagi hibakra (pl. c kodban hianyzik a user controlled valtozo hosszanak ellenorzese), vagy a mar bejegyzett serulekenyseggel hasznalt komponensekre - mindezt automatikusan a CI/CD pipeline-ban, human beavatkozas nelkul. Nem kerek arra valo hivatkozast, hogy a Linuxra fejleszto hobbiprogramozoknak nem telik CI/CD pipeline-ra, vagy Sonarqube-ra, mert mindegyik kivitelezheto ingyen, vagy tenyleg gombokert, masreszt egy reszuk biztosan nem hobbiprogramozo, hanem professzionalis, aki a munkahelyen csinalja az uzleti szoftver, a szabad idejeben meg Linuxra ir valamit.
Megkerdeztem tobb, egymastol fuggetlen AI-t is, milyen biztonsagi ellenorzeseket vegeznek a Debian Projectben: code review, dependency CVE check, vulnerability scanning - a teljesseg igenye nelkul.
"Milyen egy biztonsági ellenőrzés egyébként?
Hát ez az, pont erre várom én is a választ tőletek
"Nem, nem ezt kerdezted, hanem azt, hogy Debianek milyen ellenorzeseket vegeznek - nem biztos, hogy egy altalanos ellenorzes es a DB altal elvegzettek teljesen fedik egymast.
Az altalad leirtak alapjan en nem latom biztositottnak, hogy a Flathub megbizhato csomagokat kinal es tovabbra is fenntartom azt a velemenyemet, hogy nagyjabol az utolso megoldas legyen barmelyik 3rd party csomagforras hasznalata, beleertve a PPA-kat is.
Ettol fuggetlenul felolem mindenki azt hasznal, amit akar es meg csak karorvendeni sem fogok, ha valaki emiatt bekap valami tamadast, azt viszont nagyon is szeretnem elerni, hogy aki ebbe a topicba teved, vagy mar itt van, tisztan lassa a veszelyeket, a mukodesi mechanizmusokat, veszelyeket.
-
bambano
titán
válasz
urandom0
#166
üzenetére
de egy ponton túl mégiscsak támaszkodik a disztró libjeire, mert libc-t azért nem tesz flatpakbe, remélem. tehát ha nem azt teszteli, hogy a programja fut-e a disztró libreadline-jával, akkor azt fogja letesztelni, hogy az általa berakott libreadline fut-e a disztró alap libjeivel, pl. libc-vel. semmit nem spórol.
-
bambano
titán
válasz
urandom0
#152
üzenetére
Tehát ha a debianosok egy függőség tesztelését egyszer végzik el, az nem jó, ha minden alkalmazás minden fejlesztője leteszteli újra, az jó és az nem pazarlás.
Vegyük példának a libreadline-t. Tegyük fel, hogy ezt 20 alkalmazáshoz használják/linkelik. A debianos verzió szerint a libreadline fejlesztő és a libreadline csomagoló ember leteszteli, ez két teszt, majd minden alkalmazáshoz hozzálinkelik, megbízva a disztró irányelveiben. A te megoldásod szerint 20 alkalmazásfejlesztő 20x letölti a csomagot, mind a 20 leteszteli és utána beleteszi a flatpakbe.
na ez a dependency hell.
-
válasz
urandom0
#156
üzenetére
Vagány munkahely lehet. Ipari robotot azt láttam már, de az olyan értelemben messze van az ilyen robotoktól, hogy annak nincs "önálló" intelligenciája, hanem be van programozva neki pár darab minta, ami alapján dolgozni kell és azt csinálja 0-24 óráig szinte felügyelet nélkül.Szerk.: egyébként milyen funkciót lát el ez a kis robot? Publikus-e?
-
totron
addikt
válasz
urandom0
#104
üzenetére
így az appfejlesztők majd nagyobb kedvvel fordulnak a Linux felé, ami elméletileg több és jobb minőségű appokat eredményez, ami több Linux usert, és így nagyobb piaci részesedést vonz be.
JAJJ. A létező legrosszabb filozófia és irány egy free konvencióhoz. Haljon ki akkor inkább, ilyen szintű korcsosulás, pálfordulás helyett. Azt meg nem értem miért járna együtt automatikusan a minőséggel a fizetős mivolt. Tényleg röhej több ponton a szoftverminőség enduser fronton, a köré körített igénytelenség/foskód megideologizálása meg egy külön misét megér, de ettől még nem a fenti a kiút ebből. EZ az igazi Windowsosítás, nem a csomagformátumon áll vagy bukik a dolog.
Miért is kellene tessen bármi a külső fejlesztőknek? Miért kell erőszakkal összeboronálni akarni két világot? [link]
Eleve az app kifejezést hagyjuk meg Androidra. Vaskalaposnak tűnhet ez az okfejtés most, de tényleg nem kell mindenhova fúzió. -
totron
addikt
válasz
urandom0
#155
üzenetére
Egyfelől ki lett jelentve, hogy a flatpak több rendszererőforrást igényel futtatásilag, mint az integráltak (értem, hogy itt a munkaerőre gondoltál). Meg ott van maga a tény, bocsánat: erős opció, hogy ha egy kívülről jövő meteort bontogatsz/futtatsz, akkor abban lehet bármi. Anélkül is ott, hogy belemennénk biztonsági szűrések metódusaiba akármelyik oldalról is. Tehát ezt miért nem látod? Amikor olyan jó, összeszedett, alapos cikkeket írsz és pont ezt nem látod. Az a bűvésztrükk jut eszembe erről Copperfieldtől mikor eltüntette a Szabadság-szobrot. Nem lövöm le a megoldását - könnyen rá lehet keresni - de nagyon ide vág szerintem.
-
válasz
urandom0
#152
üzenetére
Ja igen, ez a
dependency hell
meg hasonló történetek, hogy úgy kell összelegózni mindent, hogy egymással is biztosan működjenek meg az egyéb függőségek is. Totál tudatlan vagyok ehhez, csak el tudom képzelni, hogy mekkora cumi ez a fejlesztőknek.nem biztonsági ellenőrzések.
Milyen egy biztonsági ellenőrzés egyébként? -
válasz
urandom0
#148
üzenetére
ChatGPT-t megkérdeztem, szerinte (tételezzük fel, hogy nagy vonalakban igaz az, amit ír):
A Debian fejlesztői csapata alapos tesztelési folyamatokat alkalmaz a csomagok stabilitásának és megbízhatóságának biztosítása érdekében, mielőtt azok bekerülnének a Stable kiadásba. Az alábbiakban bemutatom a főbb lépéseket, amelyek során a csomagokat tesztelik a Debianban.1. Új csomagok és frissítések beérkezése a "Unstable" tárolóba (sid)
Minden új csomag vagy csomagfrissítés először a Unstable tárolóba kerül. Ez az a hely, ahol az új verziókat először elérhetik a fejlesztők és a tesztelők. A Unstable tárolóba kerülés előtt a csomagok a fejlesztők által lokálisan vagy a saját környezetükben tesztelhetők. A csomagokban található hibák és problémák a Unstable tárolóban való megjelenés után is gyorsan kerülhetnek javításra, mivel az ezen a szinten lévő csomagok nem garantáltan stabilak.
2. Automatikus tesztelés és integrációs tesztek
A csomagokat gyakran automatizált tesztekkel is ellenőrzik, például az autopkgtest segítségével, amely a csomagok telepítését és működését teszteli. A csomagok integrációs tesztelése során az automatikus tesztelő rendszerek ellenőrzik, hogy a csomagok megfelelően működnek-e más csomagokkal együtt, és nem okoznak-e hibákat a rendszer működésében.
3. A "Testing" tárolóba való áthelyezés
Miután egy csomag sikeresen megállja a helyét a Unstable tárolóban, és némi idő elteltével nem történt benne kritikus hiba, akkor az automatikusan átkerül a Testing tárolóba, ahol további tesztelés és felügyelet alatt áll. A csomagok a Testing tárolóba kerülésük után is folytatódó tesztelésnek vannak kitéve. Itt a Debian tesztelői és a közösség által jelentett hibák alapján még mindig történhetnek változtatások.
4. Tesztelők és közösségi visszajelzések
A Testing tárolóban található csomagok nagy része közvetlenül a Debian közösségi tagjainak és tesztelőinek a visszajelzései alapján kerül módosításra. A Debian közösségében aktívan dolgozó tesztelők és felhasználók, akik saját rendszereiken próbálják ki a csomagokat, segítenek az esetleges hibák és inkompatibilitások felfedezésében.
5. A csomagok átvétele a "Stable" kiadásba
Ahhoz, hogy egy csomag végül bekerüljön a Stable kiadásba, több kritériumnak kell megfelelnie: A csomagnak hosszú ideig (általában legalább 1 hónapig) a Testing tárolóban kell maradnia, hogy biztosítsák a stabil működését. Néhány csomagnál szükség van a biztonsági frissítésekre, és a csomagnak meg kell felelnie a Debian biztonsági irányelveinek. A csomagnak nem lehetnek kritikus hibái, és kompatibilisnek kell lennie a Debian stabil kiadási követelményeivel. Ha minden feltétel teljesül, a csomag átvételre kerül a Stable tárolóba, ahol már garantáltan stabil és megbízható.
6. Debian kiadások és az LTS (Long Term Support)
Miután egy Debian verzió eléri a Stable státuszt, a csomagok még hosszú ideig karbantartás alatt állnak, és biztonsági frissítéseket kapnak. Ha egy csomag később egy új Debian kiadásban is bekerül, az egy újabb tesztelési cikluson megy keresztül a következő kiadás előtt.
7. PPA (Personal Package Archives) és egyéb nem hivatalos források
A Debian fejlesztői és csomagkarbantartók a hivatalos tárolókon kívül más forrásokból is tesztelhetik a csomagokat, például PPA-k vagy más külső tárolók használatával. Az ilyen csomagok nem részei a hivatalos Debian tárolóknak, de segíthetnek a tesztelési folyamatokban, és a közösségi visszajelzések is fontos szerepet játszanak.
Összességében a Debian csomagok tesztelési folyamata egy folyamatos, iteratív eljárás, amely a Unstable tárolóban kezdődik, és fokozatosan halad előre a Stable kiadás felé, minden lépésnél biztosítva a stabilitást és a megbízhatóságot.
-
válasz
urandom0
#146
üzenetére
Pont nem, pl. Debian alatt. Stable-be csak biztonsági oldalról is megvizsgált csomagok kerülhetnek be. Ez persze nem jelenti azt, hogy időnként nem csúszik át ez-az, de az esélye sokkal kisebb, mint más esetekben, ahol egyáltalán nincs vizsgálat.
Kiváló példa az xz backdoor.
-
bambano
titán
válasz
urandom0
#134
üzenetére
"Dehogynem, ugyanis egy flatpak csomagban nincs benne minden függőség, hanem": egy másik flatpak csomagban van benne.
a másik flatpak csomagot is összerakhatta volna deb-ben.de azt a flatpak csomagot is meg kell csinálnia valakinek, és ha rá is alkalmazzuk az állításaimat, ő is rakhatná deb-be.
még mindig hangsúlyozom, hogy a flatpak egy csomagolási módszer. hogy mi kerül bele, a csomagolón múlik, aki ugyanezen döntéseket egy deb vagy rpm csomag esetén is meg tudja hozni.
"Akárhogy is csűröd-csavarod, mindig ott lyukadunk ki, hogy a te megoldásod sokkal melósabb.": de itt az is a probléma, hogy a fejlesztő a saját problémáját át akarja tolni az userre. userből nagyságrendekkel több van, tehát ez pazarlás.
Én pontosan átlátom, hogy miről beszélsz. Csak én nagyobb képet nézek, te meg kevered az érteni kifejezést az egyetérteni kifejezéssel. Attól még értem amit mondasz, hogy nem értek egyet vele.
-
bambano
titán
válasz
urandom0
#130
üzenetére
"Esetleg azt csinálhatom, hogy deb-be csomagolok, és belerakok minden libet, amire szükségem van": és akkor ez pontosan miben is más, hogy összeválogattad és flatpaket csináltál belőle, mintha debet csináltál volna?
hint: semmiben.
q.e.d.ha pedig megcsináltad a debet és az nem települ debianon, akkor az azért nem fog települni debianon, mert az ubuntu alaprendszer újabb, nem pedig azért, mert flatpak helyett deb-be csomagoltad. következmény: fel kell raknod duplikátumként azt a libet, amelyik az alaprendszerben régebbi, de azt fel kell raknod flatpak esetén is, meg deb esetén is.
itt is jól látszik, hogy nem sikerül azonosítani a probléma valódi okát, ezért hamis megoldás születik.
-
bambano
titán
válasz
urandom0
#118
üzenetére
"Ezt értem az alatt, hogy a flatpak nekem stabil, fix, kiszámítható API-t ad.": na mégegyszer: NEM a flatpak adja a stabil apit. a flatpak, nevezzük most egyszerűen, egy konténer formátum, amibe konkrét fixált verziójú libeket raknak és attól lesz stabil az api.
Tehát a fejlesztés úgy zajlik, hogy összeválogatod a libeket, lefordítod velük a programodat, *választasz* egy csomagformátumot és becsomagolod. Miért választod a flatpaket, miért nem választod mondjuk az rpm-et? semmi nem akadályoz meg téged abban, hogy rpm-et (vagy deb-et) válassz, a hype miatt választod a flatpaket.
Én értem, hogy a fejlesztőnek problémás, hogy melyik csomagformátumot választja, de akkor azt a problémát kell megoldani, nem flatpaket meg snapet fejleszteni helyette.
"Igen, csak nincs minden disztróban dpkg": hát legyen. egyébként csomagolj rpm-be, debianra van rpm->deb konverter, tehát fel lehet rakni rpm-et debianra. gyakorlatilag ha aktuális fedorara fejlesztenél, lefednéd vele a számba vehető disztrók 95%-át flatpak nélkül.
Az is a kond, hogy igen gyakran kiderül, hogy egy rendszer túltervezett. Mindenáron bele akarják erőltetni a legújabb technológiákat, fancy cuccokat, ha kell, ha nem. Én dolgoztam isp-nél, amikor indult a szolgáltatás, minden nagy cég tolakodott, hogy az ő cuccát használjuk, meg hozták a prezentációikat, meg a rendszerterveiket. Én meg röhögve kihajítottam mindet, és töredékéből megcsináltam jól. Jártam úgy másik melómban, hogy nem tudtam elejét venni a túltervezésnek, baj is volt belőle folyamatosan.
"Ezzel szemben flatpaknál az van, hogy tudom, hogy milyen verzió van a org.gnome.Platform 47-es verziójában": és a többi verzióban? Legyen fent az org.gnome.Platform csomagból több az user gépén, mert a te cuccod a 47-esre dependál, a másik cucca a 48-asra? És ha a válaszod igen, ezt miért nem tudod megcsinálni debiánon? Egyszerűbb neked felrakni a flatpaket, ahelyett, hogy megnéznéd a helyes megoldást, és rákényszeríteni a leendő felhasználóidat, hogy szemeteljék tele a gépüket flatpakkel, miattad? Akkor nem kell a programod.
Az opensuse, az arch, a fedora, a debian *NEM GYÁRT* libeket. Tehát neked nem disztróhoz kell megnézni a függőségeket, hanem lib verziószámhoz. ugyanolyan verziószámú lib *MINDEN* disztrón ugyanazt az apit nyújtja. Tehát NEM IGAZ, hogy minden disztróra foglalkoznod kell a lib apijával, azzal kell esetleg foglalkoznod, hogy van-e megfelelő verziószámú lib a disztróban. debianban például beleírod a kontroll fájlba, hogy melyik lib milyen határok közé eső verziószámú kiadásával működik a programod, oszt jónapot.
Ha én fejlesztő lennék, három választási lehetőségem lenne:
1. minden disztróra lefordítom
2. megtanulom a flatpaket
3. megtanulom egyszer és mindenkorra, hogy hogyan kell normálisan fordítani a programot, hogy mindenhol működjönakkor én tuttira a harmadikat választanám. Pláne, hogy nem kellene túl sok disztróra megtanulni, elég lenne csak az, ami az üzleti világban elterjedt.
Ilyen architekturális meg stratégiai kérdésekben redhatesnek lenni eléggé komoly anti-ajánló. Ugye arról a redhatról beszélünk, akik elbarmolták a gcc-t, anno, akik erőltették pöcsteringet, akiknek nem volt jó a deb, kellett az rpm, stb? ha a redhat anno elfogadja a deb-et, ami egyébként anno kilométerekkel jobb volt bárminél, nem véletlenül másolja azóta is mindenki, akkor most töredék ennyi csomagolási probléma sem lenne a linux világban.
"Szerintem ő több programot csomagolt be, mint amennyivel mi egy év alatt találkozunk.": ezt ugye elég nehéz megítélni, mivel itt mindenki anonim. Másrészt ha az lesz az indoklás, hogy ő többet csomagolt be, mint én, akkor nagyon hamar elő fogom venni a légy meg a tehénoutput esetét.
-
urandom0
senior tag
válasz
urandom0
#118
üzenetére
Még egy dolgot el is felejtettem.
Nagyon sok disztrónál legalább két csomagváltozatot kell karbantartani, van egy "stable" és egy "oldastable". Debian, OpenSuse, Fedora... mind így csinálják.
Namost, ez meg a csomagkarbantartókra ró igen nagyon terhet.
De ha egyik napról a másikra úgy döntenek, hogy innentől fogva nincs natív csomag, hanem van egyetlen egy flatpak csomag, akkor a maintainerek is rengeteg munka alól mentesülnek.
Nézd meg pl., hogy mennyi elárvult Debian csomag van. Mert a maintainernek nincs ideje, nincs motivációja, stb. Ha nem is mindet, de sokat át lehetne tenni flatpak csomagba, és akkor legalább nem oldstable és stable verziókat kell karbantartani, hanem csak egy current verziót. -
bambano
titán
válasz
urandom0
#111
üzenetére
Szerintem szemléletbeli problémád van:
a flatpak nem ad apit. semmilyet, se stabilt, se instabilt. az apit a linuxos programok, libek adják. vagyis az lesz a flatpakBEN az api, amit oda csomagoltak. ugyanezt egy deb-be vagy targz-be is bele lehet csomagolni. tehát az api stabilságához a flatpaknek semmi köze.deb-hez van közös terjesztési módszer és központi repó is. az, hogy a flatpakhez csinálnak egy n+1. repót, nem feltétlenül jó, mert nem tudjuk, hogyan kerül bele egy csomag. max. azt tudjuk, mit írtak le arról, hogy hogyan kerül bele egy csomag, de hogy az alapján konkrétan mi történik, senki nem tudja. az, hogy mit raksz fel, erősen bizalom alapú, és ezt a bizalmat a flatpak nálam nem szerezte meg. és ahogy látom, nem is fogja.
a sereg disztró sem igaz. a disztrók zömében azonos szoftvereket csomagolnak, legfeljebb sebességbeli eltéréseik vannak. oké, most a nagyon egzotikus disztrókról ne beszéljünk a musl libc-vel.. de a disztrók zöme, főleg, amik üzleti szempontból számítanak, gnu libc-t, gnu compiler collectiont, ugyanazt az X apit, stb. használnak, max. azon van vita, hogy dash vagy bash.
én például használok 8-as firefoxot debian testingen. pont tegnap akadt a kezembe az openttd, ott a targz-ben benne volt minden lib, amire verziózottan szüksége van. a mozilla is meg tudta oldani a debian verziókon keresztüli széleskörű kompatibilitást, meg az openttd közösség is, hogy csak két példát mondjak hirtelen. de emlékeim szerint ez igaz volt eddig a sunos java-ra is. szóval egyáltalán nem lehetetlen megcsinálni, csak érteni kell hozzá. a flatpakesek nem értenek hozzá, különben nem lenne flatpak.
-
DarkByte
addikt
válasz
urandom0
#113
üzenetére
Windows-on csakugyan nincs, de ez szerintem leginkább OS limitáció.
Tudtommal elég sok minden nincs meg az alkalmazás szintű ilyen szintű szeparációhoz.Pl. Video/audio server alternatívának kb. csak az RDP van.
Igaz azzal is vannak mókás lehetőségek, pl. FreeRDP képes csak egy-egy Windows alkalmazást az ablakaival áthozni Linux-os window session-be a teljes desktop távoli elérése nélkül. (a WinApps nevű cucc használja pl. aktívan)Ami létezik és legközelebb van filozófiában az talán a PortableApps és a self executable programok.
Elvetemültebb lenne, de úgy tudom Wine-t jó sok szenvedés árán le lehet fordítani Windows-ra is, és azzal már lehet namespace-eket csinálni. Régi játékokhoz egyébként gondoltam már erre, csak ennyire nem vagyok elvetemült
Viszont a Flatpak WSL2-ben működik már egy ideje. Persze megint kérdéses mi értelme van, ha WSL2 distro-ból annyit hozol létre a gépre, amennyire szükséged van.
-
-
válasz
urandom0
#104
üzenetére
Naaaaaa.
"Red Hat went public on August 11, 1999". Non-profit cegek nem mennek tozsdere.
-
bambano
titán
"Meg a deb függ kb. mindentől.": és? az összes modern deb frontend képes letölteni és felrakni a függőségeket is. és így egy csomag nem x giga, hanem pár mega.
"De még egy 20.04-es Ubuntura is csak problémásan tudok feltelepíteni egy olyan deb-et, ami 24.04-hez készült.": mert közben minden fejlődött. a libc6 is. tehát a flatpak is megakadhat, nem lehetsz biztos benne.
de még mindig kérdés: aki veszi a fáradtságot és becsomagolja a discordot flatpakbe, az miért nem csomagolja be deb-be és kész? vagy deb-be és rpm-be, és jónapot?
-
bambano
titán
nem, a debian alaprendszere koncepcionálisan jó.
mindent meg lehet vele csinálni.
csak érteni kellene hozzá.egyébként miért baj, hogy van egy jó csomagkezelő rendszer? ha mellé van még másik 3, ami ócska, de nem kötelező használni, akkor mit számít?
az szerintem is pazarlás, hogy amikor már volt egy jól működő, korszerű deb, akkor a retekhatnek mi a fenéért volt fontos kitalálni az rpm-et, ami akkor még nagyságrendekkel gagyibb csomagkezelő volt.
"Az informatika már csak ilyen, mindig van mit tanulni, és mindig vannak újdonságok.": majd ha megfizetik. egy csomagoló se erőszakolja rám a munkaidőm elpazarlását.
"ami nem fog egy rendszerfrissítés után bootolhatatlanná válni":
vi hires_utolso_mondatok.txt -
"A legtöbb flatpak csomag közvetlenül a Github repóból készül a Flathub infráján, teljesen nyitott manifest fájllal. Az ilyenek visszaellenőrizhetők."
Nem az a lenyeg, hogy visszaellenorizheto-e, hanem hogy megteszi-e valaki, mielott a userhez eljut a file es nem, nem teszi meg senki.
"Ez kb. ugyanaz a szituáció, mint ha fognál valakit, leültetnéd a géped elé, adnál neki root jogokat és kijelentenéd, hogy a Linux nem biztonságos, mert bárki feltörheti.
Ha valaki random dolgokat tölt le a netről, és vakon ad nekik futtatási jogosultságokat, és le is futtatja őket, akkor ne csodálkozzon, ha lyukas a rendszere, mint az ementáli."Ezzel most nem mondasz ellen, hanem pont egyetertesz velem a sandbox semmilyenseget illetoen.
"Igen, azt a pillanatot várom én is, amikor az átlagos Linux felhasználó SELinux policyket fog írkálni."
Javasolnam, hogy ne menjunk egy bizonyos szint ala.
/.local es tarsai: iden aprilisi a bejegyzes a Fedora project foruman.
Meg egy szo a Flatsealrol, mert korabban nem olvastam azt az oldalt. Ez a masik olyan alkalmazas, ami ebben az egesz okoszisztemaban iszonyu veszelyes - ha valami, hat ez a root jelszo a sima usernek, mert nem csak a jogosultsagok szukebbre vonasara alkalmas, hanem azok kitejesztesere is.
Mindezek melle koszonom, hogy jobban kitertel a security-re is, meg ha az by design nem is jo.
-
Vladi
nagyúr
A flathub. Az a 3. fél. Eddig a disztribútor csomgaolt, most szemrebbenés nélkül mondja, hogy használj ilyet, a másik szutyok egyikét. Ezt végignéztem enterprise linuxon. Egyik kiadásban még sikerült mindent becsomagolni a következőben már a flathubra mutogattak. Köszi. Persze fedorában ott a csomag, nem lenne nagy meló átportolni. Ez jön a többi disztróban is.
2. nem. Adott disztróban. Tehát a dnf/rpm mellé kapok még egyet.
3. nem növekedett túlzottan... köszi. pár hónap alatt másodjára kapom meg, hogy vegyek hardvert. Bocs, de ez a hozzáállás a microsoft sajátja, nagyjából ilyenek miatt jöttem el abból a világból. Ez most jön utánunk.
-
urandom0
senior tag
Egy élő példa, tavaly nyáron találtak egy malware-t, ami Minecraft modokba rejtettek el. A malware a ~/.config/systemd/user vagy /etc/systemd/system/, és a ~/.config/.data mappákba rakta a fájlait. Ha a Minecraftot olyan launcherrel futattad, amit csomagkezelővel töltöttél le vagy a netről szedtél le, akkor meg tudta fertőzni a rendszered, be tudta írni magát a ~/.configba és a saját service-ét a ~/.config/systemd/user-be.
Ha viszont flatpakos launcherrel futtattad, akkor viszont nem tudta beírni magát ezekre a helyekre, mert nem volt hozzá jogosultsága. Most végignéztem az összes launchert flathubon, amiket a 'minecraft' szóra kidobott, egyetlen egyet találtam, aminek filesystem=home jogosultsága van, a többi viszont nem tud írni a ~/.config-ba. -
Meg mindig nem erted. A fejleszto sajat maga rakja bele az arto kodot a fejlesztesebe, miutan az installbase eleg nagy lett. Itt aztan alairhatsz barmit.
Biztonsag szempontbol egy olyan platform, ami egy egyszeru dotfile-lal torheto, az minden, csak nem biztonsagos, ennel meg a normal csomagokra vonatkozo ACL-ek (SELinux, AppArmor) es filesystem jogosultsagok is nagyobb vedelmet nyujtanak.
De az utolso mondattal legalabb egyet lehet erteni.
-
Speciel Debian eseten van biztonsagi ellenorzes a csomagokra, mielott a stable-be kerul. Az olyan slendrian disztribuciok, mint az Ubuntu, persze futyulnek erre, tobbek kozott ezert kaptak be az xz-alapu ssh backdoort.
A verified flatpak az egvilagon semmilyen biztonsagot nem ad, mert artalmas kod kesobb is belekerulhet az appba, hiaba egy a fejleszto es a koder. Megint visszautalok az xz-re, ahol egy uj fejleszto vette at a csomag karbantartasat, majd idovel becsempeszte a backdoort.
A usernek pedig nem olyan szoftvert kell adni, amirol reklamozzuk, hogy secure es kozben egy mozdulattal megsemmisitheto a vedelmi vonala, hanem olyat, ami tenylegesen biztonsagos.
Szokásos Linuxos hozzáállás, még a saját fajtánkat is utáljuk.
![;]](http://cdn.rios.hu/dl/s/v1.gif)
Úgy látom mindegy, hogy mit írsz, aki beléd akar kötni, az azért is beléd fog.
"
Új hozzászólás Aktív témák
Hirdetés
- AMD Ryzen 7 7700X - Új, 1 év garancia - Eladó!
- Apple Watch ultra 2 49mm Natur Titanium, Új, 1 év Apple garanciával
- Gamer PC - R5 5600, RTX 3060 és 16gb RAM + GARANCIA
- HP Zbook 14 laptop (14FHD/I7-G5/8GB/128SSD/MagyarVilágítós)
- Jó áron ÁRON ELADÓ! Üzleti HP Elitebook 1040 G9 Laptop! / i5-1245U 16GB 256GB
- Eredeti, új Lenovo 330W töltők - ADL330SDC3A
- Samsung Galaxy A13 64GB, Kártyafüggetlen, 1 Év Garanciával
- Újszerű Apple Macbook Air 13 - M2 - 30 Ciklus - 100% Akkumulátor - 8GB/256GB SSD - MAGYAR - Éjfekete
- FÉL ÁR ALATT! Lian Li UNI FAN SL120 RGB 1db-os és 3db-os ventilátor szett garanciával
- ÁRGARANCIA!Épített KomPhone i9 14900KF 64GB RAM RTX 5080 16GB GAMER PC termékbeszámítással
Állásajánlatok
Cég: PCMENTOR SZERVIZ KFT.
Város: Budapest
Cég: CAMERA-PRO Hungary Kft
Város: Budapest