- Mindent a StreamSharkról!
- Digitális Állampolgárság Program
- leslieke farmerzsebe
- Fűzzük össze a szavakat :)
- Szólánc.
- Asszociációs játék. :)
- Elektromos rásegítésű kerékpárok
- 1 Kis segítséget kérnék :)
- Nagy "hülyétkapokazapróktól" topik
- Fogadj örökbe egy szervert, avagy hogyan építsünk otthoni labot I. (az alapok)
Új hozzászólás Aktív témák
-
És ez már minden jelentősnek mondható disztróban benne van, legalább van valami közös pont.
Igen, én pont ezért döntöttem úgy, hogy maradok a Systemd-nél. Mert akárhova megyek (mondjuk másik munkahelyre), vagy akármilyen projektet kapok meg, szinte biztos, hogy Systemd-es disztróval fogok találkozni. Akkor már érdemesebb azt megismerni és használni, mint harcolni ellene.
A kis Pepper roboton, amiről tettem be képet, azon immutable Gentoo van, az is Systemd-es. Ezen meg is lepődtem.
-
bambano
titán
Tehát te el tudod dönteni, hogy azt a gépet, amire testinget raktam, mire használom, a rajta levő adatok biztonsági besorolása milyen, mekkora kárt okozhat az elvesztésük, kiszivárgásuk, stb. stb.
Ha igen, vagyis pontos információkkal rendelkezel erről, akkor igazad van. Ha nem, akkor tévedés, amit mondtál.
Egy átlagos héten négy hétfő és egy péntek van (C) Diabolis
-
válasz
urandom0
#212
üzenetére
Nem tudom, nekem tetszik. És ez már minden jelentősnek mondható disztróban benne van, legalább van valami közös pont.
Az emberiség két legnagyobb találmánya az írás és a mikrohullámú sütő. / ~ / Szakmai jellegű kérdésekkel privát üzenetben NE keressetek! Ezeknek a fórumon a helyü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.
[ Szerkesztve ]
Az emberiség két legnagyobb találmánya az írás és a mikrohullámú sütő. / ~ / Szakmai jellegű kérdésekkel privát üzenetben NE keressetek! Ezeknek a fórumon a helyük!
-
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.
Jia Tan is tök jól beilleszkedett. Egy mintagyerek volt, a lépcsőházban is mindig előre köszönt
Nekem ennyit megér a stabilitás.
Minden vicc nélkül mondom, ha a rendszerprogramok és az alkalmazások el vannak különítve (akár flatpakkal, akár dockerrel, akár csak egy distrobox konténerrel), akkor a rendszer stabilabb lesz.
---
Debianban a contrib, non-free és a non-free-firmware repókat nem tekintik a rendszer részeinek, ezért a security team nem is foglalkozik vele. Ezt eddig nem tudtam...
"Some non-free packages are distributed without source or without a license allowing the distribution of modified versions. In those cases no security fixes can be made at all."
Ez bizony szomorú.
Innentől fogva viszont egyáltalán nem tekintenem ezeket a repókat biztonságosabbnak, mint a flatpakot. Gyakorlatilag ugyanúgy 3rd party repók.
-
Külön weboldala is van az anti-systemd fan clubnak: https://nosystemd.org
Nem mondom, hogy nincsenek benne értelmes érvek, mert vannak. De a Systemd körül kialakult gyűlöletet túlzónak érzem, és szerintem sokan csak azért utálják, mert új, és más, mint ami korábban volt.
Én teljesen jól elvoltam SysV inittel is, a Slackware-féle BSD-szerű init rendszerrel is, és elvagyok Systemd-del is. Nem tapasztaltam egyikkel sem problémát. -
Ezért most egy nuc-ot használok, testing debiannal,
Ajajj, az nem annyira jó. Azt tudod ugye, hogy a testing biztonsági frissítéseit nem menedzseli a security team?
Erről a Firefoxos problémáról más is írt, azt hiszem, a kezdő topikban.
-
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.
Egy átlagos héten négy hétfő és egy péntek van (C) Diabolis
-
te honnan veszed, hogy ennyire bízunk a disztrók saját tárolóiban?
Onnan, hogy ezt bizonygatjátok itt már napok óta
De arra senki nem számít, hogy jönnek gyüttmentek, és ezt a kockázatot jelentősen megnövelik.
De pont ez nem tudta nekem eddig még senki sem elmagyarázni, hogy mitől gyüttmentek a flatpak maintainerek (gondolom, rájuk gondoltál), és miért nem azok a Debian maintainerek? Meggyőző észérvet még senkitől sem olvastam.
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?
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.
-
bambano
titán
-
bambano
titán
válasz
DarkByte
#206
üzenetére
"Nehéz ez után komolyan venni amiket írsz": nem baj. Az elég komoly probléma lenne, ha egy fontostalan anonim topicban elhangzottak alapján határoznám meg magam, vagy tenné ezt bárki más.
Debianban nincs szerver meg desktop. Amit elkottáznak a desktop részen, az kihat a szerverre is. Lásd még: systemd, udev és hasonlók. Ma már minden reboot egy hideglelős rémálom.
"Szerver oldalt a Docker-re kellene orrolnod": ez a cikk és a kapcsolódó fóruma a flatpakről szól. A docker eléggé offtopicnak tűnik, tehát vedd úgy, hogy itt a dockerről *semmit* nem mondtam, ez alapján nem lehet információd arról, hogy szeretem vagy utálom.
Egy átlagos héten négy hétfő és egy péntek van (C) Diabolis
-
DarkByte
addikt
Nehéz ez után komolyan venni amiket írsz, hogy még mindig nem volt meg ezen a ponton hogy a Flatpak hozza magával a libc-t. Pedig annyiszor írtam én is a Docker-t hasonlatnak, ott is ez történik.
Egyébként továbbra sem értem, hogy neked miért ennyire valagfájásod ez a Flatpak téma, amikor látszólag te a szerver vonal jövőjét félted, pedig ott nem is akar versenyezni, mert GUI alkalmazások terjesztésére van kitalálva.
Szerver oldalt a Docker-re kellene orrolnod amiért már bő egy évtizede ugyanezt csinálja.
(és azóta se semmisült meg a világ) Jó, oké, ott általában az alap image-ekben benne van a kicsontozott OS image csomagkezelője továbbra is, de ez nem törvényszerű, lehet akár egyetlen nagy statikus bináris is a konténerben. (meg glibc helyet musl libc, vagy akár a binfmt_misc-et kihasználva valami teljesen más architektúrához tartozó dolgok)[ Szerkesztve ]
-
Én örülök a Systemd-nek, de ha te a régi rendszerrel akarsz szórakozni, arra is van megoldás, viszont akkor meg kár itt gyűlölködni, akkor használd azt. Még kezdőként is lehet használni a Systemd-t és értelmezni a parancsait.
[ Szerkesztve ]
Az emberiség két legnagyobb találmánya az írás és a mikrohullámú sütő. / ~ / Szakmai jellegű kérdésekkel privát üzenetben NE keressetek! Ezeknek a fórumon a helyük!
-
Bizony. A Red Hat megiratta ezzel a felkegyelmuvel azt a rendszert, ami a corporate iranyba viszi a Linuxot, Debianek, meg meg egy valag masik disztribucio meg csak annyit lattal belole, hogy mar nem nekik kell init scripteket irogatniuk es karbantartaniuk, hanem a systemd-vel kapnak egy jo adagnyit. Ami persze igaz, csak egy kalap szar az egesz.
https://www.coreinfinity.tech
-
Pedig lenne ra ok boven, amiert le kellene csukatni - a tobbi vadpontot megtalaljuk azutan is, hogy mar ul.
A systemd egy mindent felzabalo, ostoba operacios rendszer az operacios rendszeren belul. Eloszor egy parhuzamos init rendszernek indult, de mara mar bezabalta a service managementet, az alkalmazas managementet, a userek kezeleset, a rendszer beallitasait, session managementet, device managementet. A KISS filozofiat hirbol sem ismeri es valoszinuleg a problemak nagy resze is ebbol fakad - tul a szerzoje ostobasagan es hozza nem ertesen. A csavo egyebkent a Red Hattol atment a Microsofthoz - ott nem fog kilogni a sorbol.
Miket "tud" a systemd? Nos, tudja azt, ha screenben inditasz el egy tavoli munkamenetet, mert mondjuk egy sokaig futo script es nem akarod, hogy megszakadjon a melo, ha kilepsz, akkor o elozekenyen azt a tavoli munkamenetet is lezarja. "Tudja" azt, ha nem sikerul valamiert a tuzfal szabalyokat ervenyesiteni, akkor is felhuzza a halozatot, de ertesitest legalabb nem kuld arrol, hogy gaz van a tuzfallal, igy az admin hiheti, hogy minden rendben van... amig eszre nem veszi, hogy az ssh portra, vagy a web portra omlenek a requestek. Mi tudja elcseszni a tuzfal konfigot? El tudja kefelni az admin... vagy az, hogy felveszel a rendszerbe CUPS-on keresztul egy nyomtatot... Termeszetesen arra is van lehetoseg, hogy egyszer, s mindenkorra hazavagd az alaplapod, mert az EFI ertekeket nem konstansokba olvassa be a laprol, hanem sima valtozokba, amiket akar veletlenul is felulirhatsz. Allitolag a systemd olyat is tud, hogy barmilyen alkalmazast, scriptet service-kent futtasson, de egeszen biztosan allithatom, hogy ez nem igy van, nagyonsok evvel ezelott volt valami, amit nem tudtam igy megoldani, pedig a systemd nagykonyve szerint csinaltam. Nyilvan azota nem probaltam, mert ha 1-2 alkalommal kell ez a funkcio es ebbol egyszer nem sikerul, akkor nem baszodik vele az ember, keres mas megoldast. Ezenkivul magara teszi az 1-es PID-et, aminek normal esetben a kernelnel kellene lennie, igy ha a systemd ledoglik, akkor ledoglik a teljes rendszered - hipiszupi. A logolas binaris, tehat eleve kell egy futo rendszer, hogy tudd olvasni... A halozati interface-eket eloszeretettel nevezgeti at, allitolag hardvercimeknek megfeleloen, de nem mindig sikerul neki, tehat azt a feladatot, amire ezt az atnevezosdit kitalalta herr pocstering... hat azt mersekelt sikerrel sikerult megoldania. Evtizedes vagy idosebb konvenciokat rugott fel a parancsok hasznalatat tekintve - es meg szerintem napestig lehetne sorolni a hibakat.
A systemd iroja meg egy ostoba, arrogans es agressziv f.sz, aki nem tudta elviselni a kritikakat es minosithetetlen stilusban reagalt a jelzett problemakra, amit vegul odaig sikerult tolnia, hogy Torvalds kozolte vele: vagy fixalja a szarjat, vagy egyetlen commitot sem fogad be tole, amig nincs fix.
Szoval boven van ok utalni a systemd-t.
https://www.coreinfinity.tech
-
-
A Linux 4% asztali reszesedese pont jo
Dehogy jó. Pont azért nem portolnak rá egy csomó szoftvert, mert nincs felhasználóbázis, plusz a hatmilliófelé húzó közösségnek sem lehet semmit értelmesen legyártani.
Tele van mindenfele csillogo-villogo kutyuvel, ami elvonjak a figyelmet
KDE Flashback...
Mindezek tetejebe egy update lassu
Ezt adom! Én a Windows 10 frissítéseit nem győzöm kivárni. Már tikkelek, ha frissíteni akar valamit..
Meg nagyobb baj, hogy az alkalmazasok egy resze is a magaeva tette ezt a filozofiat, pl. egy Symantec Endpoint scan-t elinditani parancssorbol olyan korulmenyes, amivel nagyjabol a DOS korszakban talalkoztam utoljara.
Látod, ehhez nem értek, én csak egy mezei asztali user vagyok, aki nem akar (újabb) Windows verzióra váltani (pedig tudnék, mert 100% jogtiszta licenszem van), de a Recall és hasonló takony szolgáltatások miatt nem vagyok rá hajlandó váltani. Nekem ez már sok. És itt jön a nagy frusztráció, hogy van a Mac (felejtsük el), van a ChromeOS (felejtsük el), meg van a Linux, ami jó lenne, de az sem az igazi, mert az asztali Linuxokkal is millióegy probléma van. A BSD meg egy tökönszúrás.
[ Szerkesztve ]
Az emberiség két legnagyobb találmánya az írás és a mikrohullámú sütő. / ~ / Szakmai jellegű kérdésekkel privát üzenetben NE keressetek! Ezeknek a fórumon a helyük!
-
bambano
titán
Szerinted szerverről itkávézom?
Szerk: csak neked, elrettentés képpen: egy "rendes" gépet használtam desktopnak, stabil debiannal, de nem bírtam elviselni a hűtés hangját. Ezért most egy nuc-ot használok, testing debiannal, amin fut ez a firefox nevű csoda, ami akkor is 70 fokon főzi a szupertakarékos fél-notebook processzort, amikor kb. nem csinál semmit, és képes 8-25-ös határok között bármekkora loadot csinálni. Ez egy olyan alkalmazás, híven a mai tendenciákhoz, aminek egy 70 magos T-s proci kevés.
És ezek után páran csodálkoznak, hogy ideges vagyok a desktop helyzettel kapcsolatban. A mai it en-bloc egy szemétdomb.
Megnéztem a legújabb it biztonsági törvénytervezeteket és rögtön utána az állásportálokat kecskepásztori pozíciók után kutatva. Kánaán lenne. lehet, nektek is
[ Szerkesztve ]
Egy átlagos héten négy hétfő és egy péntek van (C) Diabolis
-
bambano
titán
Pottering nem a saját fajtám, kikérem magamnak.
Az első és legfontosabb baj a systemd-vel, HOGY NEM MŰKÖDIK! abban a pillanatban, amikor olyat akarsz vele csinálni, ami nem az alap desktop elvárás, felborul a fenébe.A másik nagy probléma, hogy olyan döntéseket hozott meg Pottering, ami abszolút védhetetlen és ostoba, és amikor ezt felrótták neki, akkor rendes elmepata módjára reagált (sose tudom, hogy az szocio- vagy pszichopata).
Egyik húzása az volt, hogy megírtad a unit fájlt, és ha nem volt jó az userid meghatározása, akkor helyette fallbackkel. ROOTRA! Nem nobodyra, amit minden normális csinálna, hanem rootra. A másik, hogy ha nem volt korrekt a névfeloldás konfigja, akkor fallbackelt a google dns szerverére, amiért a jelenleg hatályos magyar törvények szerint kettő év börtön jár.
Aki ennyire nem hajlandó semmit betartani, ami az opensource szoftvert jellemezte huszonx évig, arról csak azt tudom feltételezni, hogy a következő döntése is elmeroggyant lesz. Vagyis nekem kockázat, rettegés, pluszmunka.
A másik probléma, hogy azt állítja, ő egy taskmanagert készített. Ami közben csendben átvette egy rakás más program helyét is. Például time source, syslog, stb.
A harmadik, hogy a unix alapelve, hogy karakteres fájlokkal dolgozik. Ehhez képest a rendszer log már bináris. Vagyis unixon semmi keresnivalója.
Kösz, nem kérem. Menjen át windowst fejleszteni.
Egy átlagos héten négy hétfő és egy péntek van (C) Diabolis
-
-
"Elnézve az Linux ~4% körüli asztali részesedését, amit 30 (!) év alatt össze tudott hozni... hát annyira nagyon nem rémálom a Windows hozzá képest. Pont ezaz, hogy a Linuxot kellene versenyképessé tenni."
A Linux 4% asztali reszesedese pont jo, nem kell, hogy Windows-za varazsoljak, de egyebkent tenyleg remalom a Windows kezelese. Kattints ide, kattints oda, legelabb ketfele felulet, ahol a beallitasokat tudod maceralni, egyseges hotkey-t felejtsd el. Tele van mindenfele csillogo-villogo kutyuvel, ami elvonjak a figyelmet es nem hagyjak, hogy a dolgodra koncentralj, de legalabb meg mindig eroforras-igenyesebb, mint egy Linux (Ubuntut kiveve). Mindezek tetejebe egy update lassu, mert meg mindig nem sikerult azt felgyorsitani, belepes utan meg mindig sok ideig szarozik a rendszer, mielott hasznalhatova valik. A power userek kezebol is kivettek a kulonbozo telepitesi es management eszkozoket es ugy garazdalkodik a Microsoft a gepen, mintha a sajatja lenne - nincs full kontrollod felette.
Meg nagyobb baj, hogy az alkalmazasok egy resze is a magaeva tette ezt a filozofiat, pl. egy Symantec Endpoint scan-t elinditani parancssorbol olyan korulmenyes, amivel nagyjabol a DOS korszakban talalkoztam utoljara.
https://www.coreinfinity.tech
-
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.Az emberiség két legnagyobb találmánya az írás és a mikrohullámú sütő. / ~ / Szakmai jellegű kérdésekkel privát üzenetben NE keressetek! Ezeknek a fórumon a helyük!
-
bambano
titán
Nem, a linuxot nem kell "versenyképessé" tenni. Nincs is hol, a linux nem versenyez a windowszal.
Egyébként is miben tennéd versenyképessé? Elektromos csellentyűcske kategóriában? Abban tennéd versenyképessé, hogy minden marhaságra legyen grafikus cucc? Amit úgysem használsz, mert a szerveren nem csinálsz ilyet. Okleveles kettősklikkelőknek ott a windows.
Megmondom, miben kell versenyezni. Senkit nem érdekel, hogy hogyan érem el az eredményt. Ahogy a görög kereskedők megmondták: a bevétel erősíti a szabályt. Az számít, hogy az előfizetőm minél jobb szolgáltatást kapjon, mert egyébként a lábával meg a pénzével szavaz. Beteszi a lábát a konkurenciához, és otthagyja a pénzét. Senki nem foglalkozik azzal, hogy én "kényelmes" klikkelős felületen oldom meg, hogy működjön a dhcp-je, a dns feloldása meg a routingja, kizárólag az számít, hogy működjön és neki mi a felhasználói "élménye". Márpedig ha egyszer vérrel-verejtékkel eljutottam odáig, hogy működik, akkor a linux nagyságrendekkel jobb, mint a windows. Nem véletlen, hogy a "versenyképessé kell tenni" linux még az ms saját felhőjében is leverte a windowst, mint vak a poharat.
Ezért marhaság azt mondani, hogy legyen "versenyképesebb", meg egyszerűbb meg kényelmesebb. A linux egy pályán versenyez: a hatékonyság pályáján, és eddig nyerésre áll. Minden változtatás csak ront rajta.
Egy átlagos héten négy hétfő és egy péntek van (C) Diabolis
-
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.
Egy átlagos héten négy hétfő és egy péntek van (C) Diabolis
-
Nem gondolod, hogy ennél azért már tovább jár a történet? 2024-et írunk, nem 1984-et. Haladni kéne a korral.
A windows meg egy rémálom, fusson ámokot máshol.
Elnézve az Linux ~4% körüli asztali részesedését, amit 30 (!) év alatt össze tudott hozni... hát annyira nagyon nem rémálom a Windows hozzá képest. Pont ezaz, hogy a Linuxot kellene versenyképessé tenni.[ Szerkesztve ]
Az emberiség két legnagyobb találmánya az írás és a mikrohullámú sütő. / ~ / Szakmai jellegű kérdésekkel privát üzenetben NE keressetek! Ezeknek a fórumon a helyük!
-
Én meg pont azt nem értem, hogy miért bízik mindenki ennyire a disztrók saját tárolóiban. Még mindig nem találtam meg például azt, hogy hol van leírva, hogy milyen ellenőrzéseket végeznek a csomagokon.
Azt viszont nem jelentheted ki, hogy a Flathubon nincs biztonsági ellenőrzés. #163-ban leírtam, hogy mi a helyzet Flathubnál, ennél többet sajnos nem írnak. Tehát legfeljebb azt mondhatod, hogy nem tudjuk, pontosan milyen ellenőrzések vannak Flathubon.
Azt biztosan tudjuk, hogy van code review, van manuális ellenőrzés, megnézik a csomagok jogosultságainak változásait is, és ha kell, visszatartják a csomagot. -
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.
https://www.coreinfinity.tech
-
bambano
titán
A unix alapfilozófiája, hogy KISS: keep it stupid and simple. A unixot úgy fejlesztették ki, hogy katonai megrendelésre csináltak egy oprendszert, amihez vaskos könyvben adták a követelményeket. Belebuktak. Ekkor a unix három atyja kitalálta, hogy csinálnak maguknak egy oprendszert, amin a kedvenc játékuk fut, és egyetlen elvárást támasztottak: képes legyen hatékonyan programokat futtatni és összekapcsolni.
MINDEN, ami ezt az elvet megszegi, azt erőlteti, hogy az az oprendszer nem unix. Mindenki azt használ, amit akar, csak ha nem unix, akkor ne erőltesse a unix nevet.
Én nem kritizáltam a cikket, elolvastam, további bizonyítás nélkül elhiszem, hogy a cikk jó. A téma rossz, ez a probléma. Mintha egy főzőtopicban azt magyaráznák, hogy a szója/vegán steak milyen jó. Le lehet írni, hogy a vegán sztéket hogy kell elkészíteni, de az egy húsps topicban offtopic. Pontosan ugyanezért utálják (utálom) a systemd-t, mert alapjaiban rúgja fel a unix alapszabályát.
A másik alapszabály, hogy ha valaki windowsosan akar használni egy gépet, rakjon rá windowst. Én elfogadom, ha valaki windowsos akar lenni, de azt nem, hogy akkor *minden* működjön úgy, mint a windows, és akkor nekem nem marad rendes oprendszer. Az átláthatóság, változatlanság, stabilitás erény, ha szigorú üzemeltetést akarsz csinálni. A windows meg egy rémálom, fusson ámokot máshol.
Egy átlagos héten négy hétfő és egy péntek van (C) Diabolis
-
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.Az emberiség két legnagyobb találmánya az írás és a mikrohullámú sütő. / ~ / Szakmai jellegű kérdésekkel privát üzenetben NE keressetek! Ezeknek a fórumon a helyük!
-
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.
Az emberiség két legnagyobb találmánya az írás és a mikrohullámú sütő. / ~ / Szakmai jellegű kérdésekkel privát üzenetben NE keressetek! Ezeknek a fórumon a helyük!
-
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.
Oké, akkor lehet, hogy én értelmeztem félre. De mindegy is szerintem.
Mindezek ellenére nem haszontalan, hogy körbejáródik a flatpak/egyéb csomagz témaköre.
Igen, szerintem is.
-
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. -
Ne az én fogalmázáskészégemről szoljón a topik, kérlek titeket. Lehet persze kritizálni, csak nem biztos, hogy van értelme.
totron
Nem arról van szó, hogy Árnyék kolléga jobban meg tudta fogalmazni, hanem arról, hogy azt írta, amit hallani akarsz.
sh4d0w
Én abszolút értékelem, hogy a Debian security csapat ilyen sokat tesz a biztonságért, nekem csak annyi a problémám, hogy eddig senki nem tudta bemutatni azt a dokumentációt, ami leírja, hogy a csomagbefogadás során mit és hogyan ellenőriznek.
Az AI véleményére pedig, ha nem haragszol, nem adok egy lyukas garast sem.
Azt pedig kizártnak tartom, hogy alapos codereview-t végeznek minden egyes programon. Mennyi csomag van most egy Debianban kiadásban, 65 ezer? Ha ezeknek csak a negyede szoftver, az is 16 ezer csomagot jelent. A világ összes programozója nem lenne elég arra, hogy ennyi csomagot alaposan átnézzen.Abban egyetértünk, hogy a 3rd party repó legyen az utolsó, ahhonan az ember letölt bármit is. Csak abban nem, hogy én a Flathubot nem tartom úgy 3rd party repónak, mint mondjuk az AUR-t vagy a COPR-t, mert azokat senki nem ellenőrzi. Ahhoz képest egyébként, hogy mennyire nem ellenőrzi az AUR-t senki sem, eddig egyetlen egy esetben találtak benne veszélyes programot, az is egy kriptominer volt. Egyébként a miner a user systemd unitjai közé írta be a sajátját - flatpak esetén ezt alapból nem tudta volna megtenni, mert nincs hozzá jogosultsága.
Én nem tartom veszélyesebbnek a Flathubot, mint mondjuk az universe vagy multiverse repókat.-----
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.
-
totron
addikt
dd!
Igaz is, előremutatóbb a süketek párbeszéde. Élhetünk-e a gyanúperrel, hogy te a linux témakör szentimentális vetületéhez tudsz és szeretnél inkább kapcsolódni? Azt gondolom igen. Segond, én is inkább ezt a vonalat erősítem ma már. Meg aztán ez a lapcsalád sem vállaltan mélyszakmai, nyomokban tartalmaz azért ilyet is. Van tehát helye mindenféle közelítésnek. Annak viszont már nincs, hogy ahhoz, hogy benned teljes legyen a mentális-érzelmi megélés, azért beállítasz fórumtársakat - vagy csak engem - olyannak, amilyenek valójában nem. Ezen faragj kicsit és könnyebb lesz a lét.
Fentebb megköszöntem a kommentjét, hogy dolgozott vele, érvelt, mégfentebb értékeltem és méltattam - teljesen saját indíttatásból - a posztjai minőségét úgy általánosságban is, mert tényleg azok. Úgyhogy légy szíves. -
El se kezd, mert nem olvasom el, gondolom a szokásos flémelésed, valakibe megint bele kell kötni.
Mi volt tartalmilag ekkora probléma azzal, amit urandom0 itt előadott? Teljesen jól megírta a cikket és a tőle telhetőeket mind beletette a kérdések megválaszolásába is, ennek ellenére megy az acsarkodás, mert ezt én már nem hívnám szakmai diskurzusnak.
Ez a baj a Linux világgal, hogy már egymást is b*sztatjátok, nem csak a Windows usereket (ÉS ŐKET SEM SZABADNA!).
[ Szerkesztve ]
Az emberiség két legnagyobb találmánya az írás és a mikrohullámú sütő. / ~ / Szakmai jellegű kérdésekkel privát üzenetben NE keressetek! Ezeknek a fórumon a helyük!
-
totron
addikt
Ha jól értelmezem már megint szekértáborozol. Nem rá gondoltam fogalmazásilag, hanem magamra. Árnyék kollega aktuálisan van benne, fejében ott vannak készenlétben a összes kifejezések. Tartalom és forma összeér tehát és még szándéka is volt közreadni a véleményt, ami szuper. Tetszik érteni?
A flatpak összességében pont ott jár, hogy rév és vám. Ez persze szubjektív. Legyen és legyenek meg a követői is, nálam 2 paraszthajszállal negatívba hajlik a jelenség.
-
válasz
urandom0
#163
üzenetére
Ejnye, kihagytad középiskolában az irodalom órákat? Tessék gyakorolni a fogalmazást.
![;]](//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.[ Szerkesztve ]
Az emberiség két legnagyobb találmánya az írás és a mikrohullámú sütő. / ~ / Szakmai jellegű kérdésekkel privát üzenetben NE keressetek! Ezeknek a fórumon a helyük!
-
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.
https://www.coreinfinity.tech
-
Miért?
Ha a libc nem kompatibilis a kernellel, maximum nem indul el a program. De egyrészt én ilyet még nem láttam, pedig elég sok flatpak programot futtatok különféle disztrókon, másrészt elméletben is elég kicsi rá az esély.Az újabb verziójú libc kompatibilis a régi kernelekkel, elég hosszútávon visszamenőleg.
-
És most akkor harmadszor is: a libc6 bent van a Freedesktop runtime-ban. Meg egyébként olyan libek is, mint a libstdc++, illetve a coreutils-ból kb. minden.
Egy flatpak alkalmazás nem támaszkodhat a host libjeire. Nem is nagyon tudna, mert a flatpak futtatókörnyezet felcsatolja a saját /usr könyvtárát az alkalmazás számára, ami a Freedesktop /usr könyvtárára fog mutatni, tehát az alkalmazás az /usr/{lib,lib64} alatt a Freedesktop libjeit tudja csak elérni.
Ez egészen addig így van, amíg explicit nem adsz host-os jogosultságot az alkalmazásnak, de a host /usr könyvtára akkor is csak a /run/host könyvtárba fog felcsatolódni, tehát az /usr marad továbbra is a Freedesktop-féle /usr. -
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.
Egy átlagos héten négy hétfő és egy péntek van (C) Diabolis
-
#170
urandom0
senior tag
Kisgépkezelő
#168
válasz
Kisgépkezelő
#168
üzenetére
Sokszor nem válaszolok egy-egy hozzászólásra, az pont azért van, mert nem akarom tovább boncolgatni a témát.
-
#169
DarkByte
addikt
Kisgépkezelő
#168
DarkByte
addikt
válasz
Kisgépkezelő
#168
üzenetére
Azért lehet próbálkozni az értelmes vitával. Bár a többség lehet bontja a sátorfáját és.. csomagol.
-
Próbálj kicsit túllátni a Debianon, nem csak az az egy disztró létezik.
Ha valaki nem csak a Debianra akarja kiadni a programját, hanem a lehető legtöbb disztróra (vagy legalább a 4-5 top disztróra), akkor mindegyik disztrón le kell tesztelnie a programját (sőt, igazából minden disztró minden forgalomban lévő verzióján le kell), függetlenül attól, hogy a libreadline-t a fejlesztő és a csomagoló már letesztelte. Ez már így elég sok teszt.A fejlesztő így is-úgy is tesztel, hisz az az egyik feladata. Neki csak könnyebséget jelent, hanem X disztrón kell tesztelnie, hanem csak a flatpak runtime-mal.
-
erős opció, hogy ha egy kívülről jövő meteort bontogatsz/futtatsz, akkor abban lehet bármi
De miért tartod a Flathubot kívülről jövőnek, a disztró saját csomagjait pedig belülről jövőnek?
Az én meglátásom szerint, egy Flathub csomag "befogadási procedúrája" és karbantartása gyakorlatilag nem különbözik egy belülről jövő csomagétól.
A Flathub ezt szépen leírja: Submission"Once your pull request has been submitted, it will be reviewed. Reviewers may post comments and may ask for certain fixes or clarifications. Once all comments are resolved, a test build can be started on the pull request by commenting
bot, build $FLATPAK_ID.
If the test build is successful, the application is tested by installing and running it. Further feedback may be provided after that." (kiemelés tőlem)A csomagkarbantartási vonatkozóan szintén vannak elvárások: Maintenance
"A test build will be started on every push to a pull request and if it is successful the bot will post a link to a Flatpak bundle generated from the PR contents. This temporary build can be used to test the changes made in the PR.""Whenever an official build from a merge commit is built, if any permission is changed or any critical Appstream field changes value, the build will be held for moderation.
Moderators will manually review the build and the permission change and can approve or reject the change if it is wrong or ask for more information."
Kérdezem én, ha te magad töltesz le egy forráskódot és te magad fordítod le, abban sem bízol meg? Mert gyakorlatilag a Flathub is ezt csinálja (kivéve a zárt forráskódú programoknál, de az eredet ott is visszaellenőrizhető).
Csak mellékesen: a csomagok fordítási folyamata is nyít és átlátható, itt lehet követni: https://buildbot.flathub.org/
-
bambano
titán
"Totál tudatlan vagyok ehhez, csak el tudom képzelni, hogy mekkora cumi ez a fejlesztőknek.": semekkora. a disztró kiadásának korai állapotában fixálják, hogy alapvető libek melyik verzióban fagynak be, és utána mindenki ahhoz igazodik. Mint ahogy rögzítik, hogy a kiadás melyik kernel főverzión alapul, és kész.
pont ezzel csökken az app fejlesztők dolga, mert nem kell találgatni, hogy mihez igazodjanak.
Egy átlagos héten négy hétfő és egy péntek van (C) Diabolis
-
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.
Egy átlagos héten négy hétfő és egy péntek van (C) Diabolis
-
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?
[ Szerkesztve ]
Az emberiség két legnagyobb találmánya az írás és a mikrohullámú sütő. / ~ / Szakmai jellegű kérdésekkel privát üzenetben NE keressetek! Ezeknek a fórumon a helyük!
-
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.
[ Szerkesztve ]
-
AI... amit ma "AI"-nak hívnak, az gyakorlatilag egy statisztikai alapon működő szöveggenerátor. Nem mondom, hogy ne lenne hasznos, de a valódi intelligenciától még nagyon távol áll.
A munkahelyemen van egy ilyen robotunk: [link]
Mostanában kísérletezünk azzal, hogyan lehet összekötni az OpenAI API-val. A kommunikáció megy, de az ún. "mesterséges intelligencia" nem elég intelligens ahhoz, hogy beszéd közben mozgassa is a robotot. Úgyhogy egylőre ott tartunk, hogy áll egy helyben, mint a cövek, aztán mondja a magáét -
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
Leírjátok, hogy vannak-e biztonsági tesztek a Debian csomagokon, de azt nem, hogy mit értetek biztonsági teszt alatt, vagy hogy mit kellene vizsgálnia, vagy mi lenne a célja pontosan az ilyen teszteknek...?Én amit tudtam, leírtam: Vannak automatizált tesztek, amik bizonyos patterneket (SQL injection, XSS, stb.) illetve megtalálnak backdoorokat, malware-eket.
Ezek azok a területek, amiket automatizált tesztekkel viszonylag könnyen le lehet fedni.
Ami ezeken túl van, pl. az, hogy egy alkalmazás mennyire kezeli biztonságosan a sessionöket, vagy hogy milyen fájlokat ér el futás közben, milyen hálózati forgalmat generál, stb., azokat úgy lehet tesztelni, hogy az ember tesztkörnyezetet állít fel, és tesztesetek vizsgál.
De egyrészt ez nem a maintainerek munkája, hanem a szoftverfejlesztőé (van olyan fejlesztési módszer, ahol először a tesztet írják meg, és utána írják meg a programkódot, aminek meg kell felelnie a teszteken), másrészt ez borzasztóan sok energiát igényelne. Ilyeneket biztosan nem csinál senki sem. -
-
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?Az emberiség két legnagyobb találmánya az írás és a mikrohullámú sütő. / ~ / Szakmai jellegű kérdésekkel privát üzenetben NE keressetek! Ezeknek a fórumon a helyük!
-
Ezek nagyrészt hibaellenőrzések, nem biztonsági ellenőrzések.
És tudod, mi a legszebb ebben? Hogy ezekre alapvetően azért van szükség, mert a csomag, miután a Debian befogadta, onnantól a rendszer része lesz. Függ más csomagoktól, és más csomagok is függhetnek tőle. Ez az egész ellenőrzési folyamat rengeteg energiát emészt fel a maintainerek és tesztelők részéről.
Ezzel szemben, ha az adott alkalmazás kikerül a függőségi rendszerből, onnantól fogva teljesen a fejlesztő feladata biztosítani azt, hogy a lehető leghibamentesebben működjön, és onnantól fogva a rendszer maintainereinek és tesztelőinek nem kell vele foglalkozni, ergo rengeteg erőforrás szabadul fel rendszeroldalról.
A tesztelés és a hibamentes működés bizotsítása egyébként is a fejlesztő feladata, és a fejlesztő futtat is mindenféle teszteket a szoftveren. Csak Linuxon a függőségi rendszer miatt muszáj azt is külön letesztelni, hogy a csomag hogyan illeszkedik a disztróba.
Más operációs rendszereken ilyet nem látsz, ott csak a drivereket és egyéb rendszerkomponenseket ellenőrzik ilyen szinten.
-
Ja értem, oké
Tehát tulajdonképpen nincs semmilyen vizsgálat. Pedig jó lenne, ha lenne, talán akkor a Debian stable sem lenne tele sebezhetőségekkelDe távol álljon tőlem, hogy bántsam a Debiant, egy nagyon jó rendszernek tartom. A maintainereknek is minden elismerésem.
De némi józan ésszel könnyen belátható, hogy nincs olyan teszt a világon, ami - néhány triviális biztonsági problémát leszámítva - alkalmas lenne arra, hogy a csomagok biztonságát garantálják. Vannak automatizált tesztek, amik bizonyos patterneket (SQL injection, XSS, stb.) illetve megtalálnak backdoorokat, malware-eket. Ilyeneket le lehet futtatni, de ehhez is kell szakember, idő, energia.A legbiztosabb módszer a sebezhetőségek kiszűrésére az, amit Lasse Collin is megtett, hogy sorról sorra, commitról commitra végigellenőrizni a forráskódot.
-
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.
Az emberiség két legnagyobb találmánya az írás és a mikrohullámú sütő. / ~ / Szakmai jellegű kérdésekkel privát üzenetben NE keressetek! Ezeknek a fórumon a helyük!
-
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.
[ Szerkesztve ]
https://www.coreinfinity.tech
-
-
-
-
-
válasz
urandom0
#137
üzenetére
Érdekes... Ottani "fejlesztő" tölthet fel Flathubra? Van valami ilyesmi korlátozás, vagy ezt lehetetlen kiszűrni?
Az emberiség két legnagyobb találmánya az írás és a mikrohullámú sütő. / ~ / Szakmai jellegű kérdésekkel privát üzenetben NE keressetek! Ezeknek a fórumon a helyük!
-
-
a másik flatpak csomagot is összerakhatta volna deb-ben
Amikor elkezdődött ez az egész flatpakos történet, 2007-ben, akkor még talán lehetett volna deb-et használni. Hogy miért nem arra esett a választás, én nem tudom megmondani, de komolyan írni fogok egy e-mailt Alexander Larssonnak, megérdeklődöm tőle
még mindig hangsúlyozom, hogy a flatpak egy csomagolási módszer.
Nem CSAK csomagolási módszer, hanem ott van még mellette a futattókörnyezet, ami elindítja a programot, kezeli a jogosultságokat (a Bubblewrap segítségével), meg ott a flatpak-builder, ami csomagokat épít, meg az egyéb infrastruktúrális dolgok, pl. a távoli repók kezelése, stb.
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.
Korábban azzal volt problémád, hogy a flatpak fejlesztésére elvont erőforrások hiányoznak az alap fejlesztésekből, most meg az a gond, hogy a usereknek problémát okoz a flatpak... most akkor döntsük el, hogy ki szívjon, a user vagy a fejlesztő?
Én azt gondolom, a usereknek semmilyen jelentősebb töbletterhet nem jelent a flatpak. Sőt, a userek is profitálnak abból, ha a fejlesztőnek nem kell 3-4-5-6-akármennyi disztróra csomagolnia, tesztelnie, hanem azt az energiát a szoftver fejlesztésére, unit tesztelésre és hibajavításra fordíthatja. -
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.
[ Szerkesztve ]
Egy átlagos héten négy hétfő és egy péntek van (C) Diabolis
-
é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.Dehogynem, ugyanis egy flatpak csomagban nincs benne minden függőség, hanem a nagyrészük a runtime-okban van. Mielőtt azt mondanád, hogy ezt is meg lehet oldalni mondjuk apt-vel, közlöm, hogy pl. Suse-ra nincs apt. Tudom, forgassak magamnak egyet...
És akkor még mindig csak a csomagkészítésről van szó, arról nem is beszéltünk, hogy nem csak elkészíteni kell a csomagot, hanem illik azért letesztelni minden egyes disztrón is.
És akkor arról még nem beszéltünk, hogy a flatpak tud sandboxot is...akkor az azért nem fog települni debianon, mert az ubuntu alaprendszer újabb
Igen, ezt írtam én is.
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.
Igen, meg ha az a lib egy másik libre hivatkozik, azt is fel kell raknom. És ha van 5 ilyen libem, meg azoknak van még 15 tranzitív függősége, akkor már 25 libem, amire folyamatosan ügyelni kell. Frissítgetnem kell őket, vigyáznom kell, hogy ne törjenek el, stb. És közben minden egyesnél release-nél tesztelnem is kell minden rendszeren.
Miközben flatpak esetén kikötöm, hogy org.freedesktop.Platform 23.08-as verzió kell és kész, ennyi. Két évente pedig frissítem, mert egy ilyennek 2 év a támogatása.A baj az, hogy te csakazértsem akarod átlátni ezt az egészet, és nem akarod megérteni, hogy egy csomagot kiadni Ubuntura, Debianra, Fedorára, Archra, Suse-ra az mondjuk 25 emberóra, míg ugyanezt flatpakban 1 emberóra.
Akárhogy is csűröd-csavarod, mindig ott lyukadunk ki, hogy a te megoldásod sokkal melósabb. -
#133
urandom0
senior tag
Kisgépkezelő
#131
válasz
Kisgépkezelő
#131
üzenetére
A legtöbb programnál nincs gond a flatpak futási sebességével. Az indulási sebesség az, ami lassabb, mint a csomagkezelős appoknál, illetve sok helyet foglalnak a flatpakos appok, mint a natívak.
-
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.
Egy átlagos héten négy hétfő és egy péntek van (C) Diabolis
-
#131
Kisgépkezelő
senior tag
DarkByte
#128
Kisgépkezelő
senior tag
válasz
DarkByte
#128
üzenetére
Fentebb valaki vélelmezte, hogy a flatpak erőforráspazarló. Lefuttattam 2-2 Cinebench mérést flathubról és csomagkezelőből telepített bottlesben. Ha már lúd, legyen kövér alapon W11-en is mértem kettőt.
W11 616p
Linux+Bottles 611p
Mindent sajnos nem futtat, de azért nem semmi, hogy amit meg igen, azt meg ilyen jól. -
Miért választod a flatpaket, miért nem választod mondjuk az rpm-et?
Mert a flatpakot oda tudom adni az Archosnak, a Debianosnak, az Ubuntusnak, a Fedorásnak, az OpenSuses-nak, és működni fog.
É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.
A probléma megoldása maga a flatpak és a snap
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.
Na látod, pont erről beszélek. Csomagoljam be rpm-be, a Debianos konvertálja át magának deb-re, és tesztelje is, ha már úgyis ott van. Vagy konvertáljam át én, és teszteljem le én? Oké, megteszem, de akkor már kétszer annyi munkát végzek, mint ha feldobtam volna Flathubra.
Egyébként az átkonvertálás egyáltalán nem ilyen egyszerű. Ha én megcsinálom a csomagot mondjuk Ubuntura, és ez van a debian/control fájlban:
Depends: efibootmgr (>= 17), python3 (>= 3.9), libgtk-3-dev (>= 3.24)És ha ezt a csomagot egy Debianosnak odaadom, akkor a Debianosnál azért nem fog települni, mert efibootmgr-ből nála csak 16-os van, az OpenSusesnál azért nem fog futni, mert nála a libgtk-3-dev helyett libgtk3-devel van, az Archosnál meg azért nem, mert nála meg csak AUR-ban van efibootmgr (ott is csak forráskódban).
Nem hülyeségből találták ám ki a flatpakot meg a snapot, ha ez ilyen könnyen menne, mint ahogy állítod, akkor nem találták volna ki.é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?
Igen.
É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.
Mert ha megcsinálom Debianon, akkor az még nem lesz megcsinálva Fedorán, Archon, OpenSusén, satöbbin. Esetleg azt csinálhatom, hogy deb-be csomagolok, és belerakok minden libet, amire szükségem van (vagy eleve statikusan fordítom le a programom), és azt konvertálgatom át rpm-be, tar.gz-be, stb. És akkor gyakorlatilag feltaláltam az appimage-et
Side note: a flatpak nagyon minimálisat szemetel. Magának a flatpaknak csak néhány függősége van, többségében olyanok, amik úgyis fent vannak a gépen (libc6, libsystemd0, stb.), és maguk a flatpak appok is összvissz 2 könyvtába pakolják a dolgaikat. Én örülök neki, hogy a rendszer és az appok két teljesen más rétegben vannak.Szerencsére dönthetsz úgy, hogy nem kell a programom, ez teljesen elfogadható. Vagy oda is adhatom a forrást, és lefordítod magadnak. De akkor neked kell gondoskodnod, hogy a program megfelelően fusson a disztródon, neked kell beszerezned a függőségeket hogy egyáltalán leforduljon, stb. De nyilván az átlagos végfelhasználóktól ezt nem várhatom el.
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
Igen, erre próbáltam utalni én is a libadwaitás példámmal.
akkor é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.
Oké, de nem lehet mindenki ilyen született talentum, mint te. Én azt értem, hogy ha te csomagolsz be egy programot, az a program el fog futni DOS 6.22-tól kezdve a Haikun keresztül a NetBSD-ig bezárólag mindenen, még tamagochin is. De sajnos vannak nálad gyengébb képességűek is
-
#128
DarkByte
addikt
Kisgépkezelő
#123
DarkByte
addikt
válasz
Kisgépkezelő
#123
üzenetére
Én pont a Bottles-t próbáltam ki Flatpak alatt nemrég. Egy régebbi CD iso-s játékot akartam beüzemelni, a CDemu-s emuláció azért megtréfált a Flatpak sandbox-olásával, de Flatseal-el meg sikerült oldani hogy lássa amit kell, és gyönyörűen ment utána. Kimondottan örültem hogy a kísérletezéssel nem a host gépet kellett szétbarmolni, így bármikor eldózerolhattam és újrakezdhettem.
[ Szerkesztve ]
-
Én biztos vagyok benne, hogy lejjebb lenne. Ez a pöcsteringezés meg ne is haragudj meg de végtelenül gyerekes.
[ Szerkesztve ]
Az emberiség két legnagyobb találmánya az írás és a mikrohullámú sütő. / ~ / Szakmai jellegű kérdésekkel privát üzenetben NE keressetek! Ezeknek a fórumon a helyük!
-
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.
Egy átlagos héten négy hétfő és egy péntek van (C) Diabolis
-
#123
Kisgépkezelő
senior tag
Kisgépkezelő
senior tag
A hasznos alkalmazások közé én benevezném a Bottles-t. Valószínűleg most az a leg felhasználóbarátabb megoldás Win szoftverek futtatására. Itt-ott elérhető ugyan natív csomagként is, de a fejlesztő kifejezetten a flatpakot ajánlja.
-
Hát igen, ez nézőpont kérdése is. A Red Hat erősen viszi egyfajta irányba a Linuxot, nézőpont kérdése, hogy kinek tetszik vagy nem tetszik ez az irány. Ha megkérdezel egy Devuan usert, neki nem annyira fog tetszeni
Meg a Red Hat sem fekete-fehér (hanem piros), nyilván vannak jó és rossz döntései. Pl. amit a CentOSsel tettek, az sokaknál kiverte a biztosítékot. -
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. -
válasz
urandom0
#118
üzenetére
Mondjuk a Red Hatet is szidják rengetegen, mégis az (is) tolja elég erősen a Linux szekerét. Red Hat nélkül nem ott állna a Linux, ahol most van.
[ Szerkesztve ]
Az emberiség két legnagyobb találmánya az írás és a mikrohullámú sütő. / ~ / Szakmai jellegű kérdésekkel privát üzenetben NE keressetek! Ezeknek a fórumon a helyük!
-
válasz
DarkByte
#114
üzenetére
Windowson esetleg Dockerrel lehetne megoldani a sandboxingot (de a Windowsos Docker tulajdonképpen Hyper-V+egy minimal Linux distro), a függőségeket (runtime-okat) msi csomagba lehetne rakni, a függőségkezelést pedig wingettel lehetne talán megoldani. És igen, maguk a programok statikusan fordíttott self executable-k úgy, hogy a runtime-okban lévő libeket onnan húzzák be.
De Windows-on senki nem akar ilyet csinálni, mert ott ott vana WinApi, az MFC, a .net, mint stabil API-k, azokra lehet építkezni. -
a flatpak nem ad apit. semmilyet, se stabilt, se instabilt. az apit a linuxos programok, libek adják
Igen, ez így van. Stabil API alatt nyilván a runtime-okban lévő libeket értem.
Ha fejlesztek egy programot, és mondjuk a org.freedesktop.Platform runtime 23.08-as verziójára dependelek, akkor van egy stabil API-m, teljesen függetlenül attól, hogy a disztrókban milyen csomagok vannak. Ezt értem az alatt, hogy a flatpak nekem stabil, fix, kiszámítható API-t ad.ugyanezt egy deb-be vagy targz-be is bele lehet csomagolni.
Igen, csak nincs minden disztróban dpkg. Persze, le lehet fordítani minden disztróra a dpkg-t meg az apt-t is vagy bármit, és lehetnének deb csomagok flatpak csomagok helyett, csak akkor kb. ugyanott lennél, mint most a flatpak.
Te alapvetően azt nem veszed figyelembe, hogy hatalmas nagy különbség van aközött, hogy valami lehetne, és aközött, hogy valami kész van, lehet használni, és van hozzá infrastruktúra. Ahogy DarkByte írta, nem technológiailag nagy dolog a flatpak, hanem mert felismerték, hogy ez egy működőképes dolog, és van rá igény.
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.
Miért bízol meg jobban a disztród maintainereiben, mint a flatpak maintainerekben?
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,
Menj fel a valadoc.org-ra. Bal oldali oszlopban látsz egy határ libet (pontosabban az API doksijukat). Ezek azok a libek, amik a legtöbb disztróban ott vannak, általánosan elérhetők. A Linuxos programok többsége ezek közül legalább egyet, de inkább többet használ. Nézzük meg mondjuk a libadwaitát, ezt majdnem minden GTK-s program használja.
A kérdés az, hogy ha én szeretném használni a programomban mondjuk a TabOverview komponenst, akkor azt támogatja-e az Ubuntu 20.04-ben lévő libadwaita, a 22.04-ben lévő, a 24.04-ben lévő, a Debian 11-ben lévő, a Debian 12-ben lévő, az Arch-ban lévő, az OpenSuse Leap-ben lévő, az OpenSuse Tumbleweedben lévő, a Fedora 40-ben lévő, a Fedora 41-ben lévő, ... ezeket így mindet végig kellene zongoráznom. És ha használok mondjuk 4-5 ilyen libet (ami nem sok), akkor ezt mindegyiknél végig kellene tesztelnem.Ezzel szemben flatpaknál az van, hogy tudom, hogy milyen verzió van a org.gnome.Platform 47-es verziójában, a flatpak csomaggal arra dependelek, és kész, nincs vele több dolgom. Ez az a különbség, ami miatt a flatpak appterjesztésre használhatóbb. A sandboxingról nem is beszélve, de azt most szándékosan figyelmen kívül hagyom.
Személetbeli különbségeink vannak.
Te nagyon elméleti oldalról közelíted meg.
Persze, hogy meg lehet csinálni ezt meg azt is, hiszen meg tudja oldani a Firefox is, meg az OpenTTD is. Nyilván be lehet csomagolni targz-be az egész világ, meg lehet fordítani akármi --prefixxel, meg deb-be is belefér minden.
Csak te azt nem veszed figyelembe, hogy ha egy szoftverfejlesztőnek választania kell aközött, hogy lefordítja, teszteli és csomagolja a programját az összes céldisztróra, vagy aközött, hogy megcsinálja mindezt egyszer, és működik, akkor nyilván az utóbbit fogja preferálni. Főleg, ha fizetős szoftverről van szó, nagyon nem mindegy, hogy 2-3 manuális tesztelőt kell alkalmazni, akik napi 8 órában tesztelgetik az új funkciókat minden egyes céldisztrón, vagy egyet, aki teszteli a flatpak csomgot és kész.Senki nem akar azzal szopni, hogy na most akkor Mint 22-n azért nem megy, mert a libadwaita más flagekkel van fordítva, most Debianon azért nem megy, mert kettővel korábbi apt verzió van fent, most Leap-en hibára fut mentéskor, mert ott SELinux van, Garudán KDE-n összeesik a layout, mert custom téma van megadva GTK_THEME-nek...
a flatpakesek nem értenek hozzá, különben nem lenne flatpak.
Azért ennyire ne nézzük már butának a másikat. A flatpak egyik "élmunkása" Alexander Larsson, aki "Senior Principal Software Engineer" volt a Red Hatnél, több, mint egy évtizedig. Szerintem ő több programot csomagolt be, mint amennyivel mi egy év alatt találkozunk. Hidd el, hogy jobban képben van a dolgokkal, mint itt mi mindannyian.[ Szerkesztve ]
-
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.
Egy átlagos héten négy hétfő és egy péntek van (C) Diabolis
-
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.
[ Szerkesztve ]
-
válasz
DarkByte
#105
üzenetére
Igen, ez így van, de ha a flatpakot kell más operációs rendszerekben lévő megoldásokhoz hasonlítani, akkor nem tudok jobbat, mint a MacOS-féle app bundle. Az más kérdés, hogy maga az app bundle az appimage-hez jobban hasonlít.
Olyan beépített Windows-os megoldást viszont nem tudok mondani, ami hasonlítana a flatpakhoz.
[ Szerkesztve ]
-
-
-
bambano
titán
válasz
urandom0
#104
üzenetére
"A fejlesztőcégek folyamatosan azon pörögnek, ha szóba kerül a Linux, hogy nehéz rá fejleszteni, mert semmi sem egységes": én arról nem tehetek, hogy nem értenek hozzá.
Eddig is lehetett fizetős appokat rakni linuxra, mi változik?
Egy átlagos héten négy hétfő és egy péntek van (C) Diabolis
-
DarkByte
addikt
Ezzel nem tudok vitatkozni, tény hogy borzasztó fragmentált a Linux.
Ha hirtelen a világ eldöntené, hogy mostantól akkor csak Debian-al és deb-el megyünk tovább, akkor az egész Flatpak-esdi értelmét vesztené, de amíg ilyen nem történik (és valljuk be, ennek sokkal nagyobb az esélye, pont az általad leírt dolgok miatt) addig a Flatpak is elfér a futottak még kategóriában.(Egyébként én nem érzem akkora nagy technológia wasistdas-nak a Flatpak-et, hogy őszinte legyek. Nem néztem jobban utána de tippre ez is az cgroup, namespacing és társait használja a kernel-ben, amúgy meg lényegében a layer-ezett fájlrendszer, mint amit a Docker is csinál. Kb. a portal-ok rész az ami kicsit kreatívabb.
Inkább a felismerés hogy így is lehet terjeszteni alkalmazásokat, találkozva azzal hogy van sok kezdő/lusta/sandbox-ot preferáló user akinek ez valós igénye.
Ahogy nézem kb. 10 fős kis csapat viszi. Ennyi ember a Debian jobbá vagy rosszabbá tétele szempontjából nem zavar vizet.)
[ Szerkesztve ]
-
bambano
titán
válasz
DarkByte
#103
üzenetére
Én nem beszélek el melletted..
Arról van szó, hogy van egy (a példa kedvéért) tulajdonsága a debian csomagkezelőnek, ami egyes emberek szerint hiba. Ezért ők nem azt választják, hogy megjavítsák a debian csomagkezelőt, hanem csinálnak helyette egy másikat. Ezzel az egyik probléma az, hogy nulláról elkezdeni valamit az *mindig* definíció szerűen bughalmaz lesz. A másik, hogy ha szerintük tényleg hiba az a tulajdonság, akkor ha megjavítanák, akkor az is megkapná a javítást, aki egyébként nem flatpakezik.A nagy probléma még az, hogy ha az a hiedelem, hogy az adott tulajdonság hiba, tévedésen alapul, akkor egyrészt kidobsz egy rakás melót, másrészt forkolsz egy programot és egy közösséget (programozói erőforrást) is. Na ez nem hiányzik senkinek.
Ez pont olyan sületlenség, mint amikor okosok kitalálták, hogy az X nem jó, erre a közösség elkezdett waylandet fejleszteni, de az ostobácska canonicalnak fontos volt, hogy ők nem waylandeznek, hanem majd jól megmutatják a világnak a mir-t. Pofára is estek, idáig porzott...
Az, hogy az opensource világban jogod van forkolni, nem jelenti azt, hogy kötelező. Az, hogy forkolhatsz valamit, mindaddig nem zavar, amíg engem nem érint. Tőlem mindenki megcsinálhatja az n+1. (n>400) pár kiadás után elhaló disztróját, de szerintem mindenkinek gyorsabb és nyugisabb lenne, ha az ilyen emberek vennének egy nagy bmw-t meg egy rendes motorosfűrészt (lásd még: [link] ).
Egy átlagos héten négy hétfő és egy péntek van (C) Diabolis
-
válasz
urandom0
#104
üzenetére
Naaaaaa.
"Red Hat went public on August 11, 1999". Non-profit cegek nem mennek tozsdere.
https://www.coreinfinity.tech
-
A Red Hat nem kommercializálta a Linuxot, nem is volt célja. A Canonical volt ráálva erre a témára kb. 20 éven keresztül, de pár éve (sok milliárd EUR elégetése után) rájött, hogy ez nem fog működni. Azóta gyakorlatilag annyi az Ubuntu, hogy fognak egy Debian unstable-t, újraforgatják egy saját patch settel, aztán megbrandelik saját névvel, hátterekkel, egyebekkel és kiadják más néven. Nem mintha ez olyan rossz lenne, szerintem az Ubuntu azóta jó, amióta a Canonical csak minimálisan nyúl bele.
A fejlesztőcégek folyamatosan azon pörögnek, ha szóba kerül a Linux, hogy nehéz rá fejleszteni, mert semmi sem egységes. Se a disztrók, se a csomagformátumok, se az asztali környezetek, semmi. A flatpakkal kapcsolatos egyik várokozás az, hogy ezt a szétszórtságot kicsit összerakja, lesz egységes csomagformátum az appoknak, egységes store (legalább webes, ha asztali egyelőre nem is), és lesznek fizetős appok is, í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.
Majd meglátjuk, így lesz-e.Amúgy ez inkább Macesítés, mint Windowsosítás. A Flatpak a MacOS-féle .app formátumhoz hasonlít.
-
DarkByte
addikt
Szerintem itt kicsit elbeszélünk egymás mellett. A Flatpak nem céloz kiszolgálókat. Arra ott a Docker és alternatívái, nem is volna értelme versenyezniük. Tisztán végfelhasználói, ott is leginkább grafikus alkalmazások terjesztésére kitalált dolog.
Végfelhasználói Linux Windows-osításában értettem úgy hogy a Canonical előrehaladott az Ubuntu-val. (egyébként ők is tolják a Snap-ot, ami a Flatpak saját megfelelője)
Nem tudom beleférek-e a gyűjtődbe. Linux-on/ra fejlesztek, de az is igaz hogy az leginkább Java, kisebb részt shell és automatizáció. Van itthon homeserver Proxmox-al (Debian, Home Assistant), Raspberry-k, Microtik router, saját laptopon Arch KDE-vel, desktop-on Win11-en WSL2, stb.
A Red Hat-ot mondjuk én nem bírom, a ló túloldala. A fizetős support-jukhoz volt közöm a Keycloak kapcsán és ritka undorító az a több rétegű subscription wall mögé pakolása az információknak amit csinálnak. De ugyanezekért nem a szívem csücske az Oracle sem
Kár hogy már nehéz ennyire átszellemült lenni a szakma után egy ideje, kicsit kiölte belőlem a meló mókuskereke azt a fiatal lelkesedést.
[ Szerkesztve ]
-
bambano
titán
válasz
DarkByte
#101
üzenetére
"Az elit önző hozzáállással nem tudok mit kezdeni.": feltételezem, nem linuxból élsz. Másrészt meg amíg használsz (közvetve is) linuxos szolgáltatásokat, addig téged is érint. Márpedig használsz, a magyar internet szolgáltatók elsöprő többsége linuxos cuccokat használ a core internet szolgáltatáshoz.
"Én személy szerint üdvözlöm hogy a Linux-on egyre több lehetőség van.": én meg nem, mert azt látom, hogy nem "lehetőségeket" pakolnak a linuxokba, hanem bugokat. Már a debian is jó tempóban halad afelé, hogy olyan legyen, mint egy windows, és pont ugyanolyan szemétdomb is.
Lehet, hogy a canonical *próbálkozik* a linux kommercializálásával, de a redhat régen megtette, nagyobb kazal pénzért vette meg őket az ibm.
Egy átlagos héten négy hétfő és egy péntek van (C) Diabolis
-
DarkByte
addikt
Nem látom hogy attól hogy a Flatpak létezik neked mitől lett rosszabb a Debian-od.
A Flatpak amúgy sem használható az OS rendszeralkalmazások terjesztésére, egy alap környezetnek futnia kell ami felett el lehet az ilyen programokat indítani. Szóval a klasszikus csomagkezelők ugyanúgy kellenek továbbra is.
Maximum azt érheti el az törekvés, hogy a rendszer csomagkezelője rejtettebb szintre lesz pakolva pár distro-ban, eldugva az avatatlan szemek elől. (az immutable OS ezt tkp. meg is valósítja, a SteamOS kiváló példa, átlag Józsi ne tudja tönkre tenni ha nem ért hozzá, de amúgy még azt is fel lehet oldani ha kell)
Kb. úgy tekintek a Flatpak-re mint Android-on a Play Shop-ra, vagy Windows-on a Steam-re vagy a Chocolatey-re. Egy plusz alkalmazás terjesztési csatorna.
Én személy szerint üdvözlöm hogy a Linux-on egyre több lehetőség van.
Az elit önző hozzáállással nem tudok mit kezdeni.Nem kötelező használni. Közelébe nem kell menned, ha nem akarod. Docker helyett is lehet deploy-olni szerverre a mai napig a klasszikus módon, vagy virtuális gépet futtatni, vagy amit akarsz. Pedig volt egy időszak amikor a microservice folyt a csapból is.
Biztos vagyok benne hogy amíg létezni fog Linux lesz legalább egy olyan distro amelyik továbbra is a klasszikus csomagkezelést fogja preferálni elsődlegesként.
A Linux kommerszé tételével próbálkozás amúgy se újdonság, a Canonical ezt próbálja elérni már idestova 20 éve.
[ Szerkesztve ]
![;]](http://cdn.rios.hu/dl/s/v1.gif)
Szokásos Linuxos hozzáállás, még a saját fajtánkat is utáljuk.
Új hozzászólás Aktív témák
lo Áttekintjük az elméleti alapjait és az alapvető parancssori működést valamint néhány hasznos alkalmazást.
- Akciós! PC , i7 10700 , RTX 3060 Ti , 32GB 3200MHz , 512GB NVME , 1TB HDD
- Samsung Galaxy S24 +512GB, fekete 2027/02/28-ig garanciális
- iPhone 16 Pro Max 256gb, független,bontatlan
- Apple iPad Mini 7, Blue, 128Gb., Wifi, új, 2 év garival + Pencil 2, karcmentes
- Lenovo ThinkPad P51,15.6",FHD,i7-7700HQ,24GB DDR4,512GB SSD,M12000 4GB VGA,WIN10