- Ivqkzy-: 2. gépem
- D1Rect: Nagy "hülyétkapokazapróktól" topik
- MasterDeeJay: Noname 1TB-os Sata SSD teszt. (Blue)
- Luck Dragon: Asszociációs játék. :)
- Gurulunk, WAZE?!
- Sub-ZeRo: Euro Truck Simulator 2 & American Truck Simulator 1 (esetleg 2 majd, ha lesz) :)
- Parci: Milyen mosógépet vegyek?
- sziku69: Fűzzük össze a szavakat :)
- eBay-es kütyük kis pénzért
- Elektromos rásegítésű kerékpárok
Új hozzászólás Aktív témák
-
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.
-
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.
-
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.
-
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
-
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.
-
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.
-
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.
-
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.
-
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
"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.
-
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.
-
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.
-
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.
-
-
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] ).
-
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.
-
bambano
titán
Amit próbáltam leírni, hogy a flatpak fejlesztésére elvont erőforrások hiányoznak az alap fejlesztésekből. Plusz a linux elwindowsosítására felhasznált erőforrások is hiányoznak. Nem az a probléma, hogy neked lesz flatpaked, hanem az, hogy ettől nekem rosszabb lesz a disztróm. Meg attól is, ha olyanok kedvéért marhaságokat erőltetnek a linuxokba, akik egyébként nyugodtan felrakhatnának maguknak egy windowst.
"De szerintem a Linux szélesebb körű elterjedéséhez": ez önmagában probléma. Ne terjedjen tovább a linux, ha az az ára, hogy windowsos marhaságokat kell beleerőltetni a disztrókba. Ne kelljen már nekem freebsd-re átszoknom, hogy másoknak jobb legyen a linux kernelre alapozott windowsuk.
-
bambano
titán
Hát ja, hiszen linuxra milyen bonyolult fejleszteni, bezzeg windowsra, amiből kb. 5x annyi variáns van, triviális.
Másrészt meg az üzleti fejlesztőknek nem kell mindenre fejleszteniük. Elég 2-3 üzleti disztró aktuális verziójára fejleszteni, és kész. Valójában nincs egetverő különbség az alapvető dolgokban."A Flatpak-el össze lehet zárni az app-ot a függőségeivel": szemben például a tar.gz-vel, amiben szintén össze lehet zárni a programot a függőségeivel. Csak nem kell hozzá a flatpaket is ismerni. Meg deb-ben is össze lehet zárni, csak ezt büdös megtanulni.
-
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
"Az lenne az utolsó, amit csinálnék egy Linux rendszeren, hogy egy weboldalról töltsem le a telepítőt": amíg biztos vagy benne, hogy nem térítették el a dns rezolválásodat (mondjuk DoH-val, ugye mozilla???), addig nyugodtan felrakhatod a mozillától a böngészőt. ki más tudná jobban lefordítani, mint a mozilla?
meg a windows userek is így rakják fel, nem történik tőle semmi. -
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 -
bambano
titán
tehát usernek egyszerűbb felrakni egy flatpaket és utána abban letölteni egy böngészőt, mint hogy elmenjen a mozilla főoldalára és simán letöltse, kicsomagolja és kész?
a program karbantartójának meg egyszerűbb megcsinálni a szokásos deb és rpm mellé a targz után, hogy még van flatpakje, snapje meg a fene tudja még mije? -
bambano
titán
"Kezdve azzal, hogy ha gcc-ből is eleve más verziót kér valami, meg vagy lőve, hiába szánnád rá a mókolási időt.": igen, azok álltak neki flatpacket fejleszteni, akik nem tudták, hogy egyáltalán nem vagy meglőve másik verzióval. Debianon legalábbis biztos nem, és, szerintem, bármelyik másik disztrón is meg tudnám oldani nem nagy mókolással.
A biztonsági frissítésekkel sincs baj, van security-updates oszt jónapot. A windows ebben biztosan nem jobb. mondjuk másban se...
-
bambano
titán
Egyébként a következő az alapbajom:
1. ha azt a rengeteg erőfeszítést, amit ilyen hülyeségek kifejlesztésére elpazaroltak, az alaprendszer hibajavításába ölték volna, az alaprendszer is jó lenne.
2. amikor ilyen plusz hülyeségek megtanulására kényszerítik a felhasználókat, rendszergazdákat, az is ordenáré nagy pazarlás.Mondjuk rögtön elkezdhettük volna 30 évvel ezelőtt, hogy mi a fenének rpm, mikor már volt egy rendes csomagkezelő. Csak hát a redhat mindig is egyénieskedett...
-
bambano
titán
tehát ha nincs rendesen fent friss kodek, akkor ki kell találni egy új csomagolási rendszert és abban kell terjeszteni a kodekeket, ahelyett, hogy csinálnának egy friss kodekpakkot és azt terjesztenék?
ez olyan, mintha nem tudnék lejátszani egy filmet, és az lenne a javaslat, hogy rakjak fel kvm-et, libkvm-et, abba virtualizáljak egy windowst, abba rakjam fel a phvm drivereket, meg egy médialejátszót és azzal nézzek filmet... mindezt persze cloudba, mert ma már cloud nélkül nem ember a júzer.
egyébként nekem az mplayer mindent vitt eddig. csak a vlc-vel fordult elő, hogy nem látott mindent, de az nálam tárgytalan.
![;]](http://cdn.rios.hu/dl/s/v1.gif)
Új hozzászólás Aktív témák
- Legion 5 17ACH6H 17.3" FHD IPS Ryzen 7 5800H RTX 3060 16GB 512GB NVMe magyar vbill gar
- Latitude 5520 27% 15.6" FHD IPS érintő i7-1185G7 MX450 16GB 512GB NVMe ujjlolv IR kam gar
- Apple Watch Ultra 2 49MM e-Sim 2028.06.05-ig Média Markt Garancia Makulátlan Új állapotú
- Ninebot e2 plus garanciával
- PNY RTX 5080 16GB GDDR7 Overclocked Triple Fan - Új, 3 év garancia - Eladó!
- BESZÁMÍTÁS! ASRock B460M i5 10400 16GB DDR4 512GB SSD RTX 2060 Super 8GB Rampage SHIVA TT 500W
- BESZÁMÍTÁS! MSI B450M R5 3600 16GB DDR4 512GB SSD RTX 2060 Super 8GB THERMALTAKE Core V21 500W
- Azonnali készpénzes INTEL CPU NVIDIA VGA számítógép felvásárlás személyesen / postával korrekt áron
- BESZÁMÍTÁS! Asus TUF F15 FX506HM Gamer notebook - i5 11400H 16GB DDR4 RAM 512GB SSD RTX 3060 6GB W10
- Telefon felvásárlás!! iPhone X/iPhone Xs/iPhone XR/iPhone Xs Max
Állásajánlatok
Cég: Promenade Publishing House Kft.
Város: Budapest
Cég: CAMERA-PRO Hungary Kft
Város: Budapest