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

• #5020 BoB Topikgazda ubyegon2 #5018

  Új Válasz 2018-03-05 21:25:36 #5020

  Új hozzászólás

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

  Privát üzenet küldése

  

  BoB

  Topikgazda

  válasz ubyegon2 #5018 üzenetére

  Segítek szívesen mindenkinek, de amikor olyan dolgokról van szó hogy hogyan lehet mate-et feltelepíteni meg a grub konfigurációt frissíteni, akkor milyen jövő áll előtte Arch használat szempontjából?

  Olvasni kell a wikit, olvasni kell a man oldalakat, ez van. Ez nem egy plug&play disztró.

  Ez alól egy kibúvót látok, ha valaki nem beszél angolul. Akkor viszont nem is javaslom hogy Arch-ot használjon.

  [ Szerkesztve ]

  You may corrupt the souls of men, but I am steel. I am doom.

• #5024 Frawly veterán ubyegon2 #5018

  Új Válasz 2018-03-05 22:58:51 #5024

  Új hozzászólás

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

  Privát üzenet küldése

  

  Frawly

  veterán

  válasz ubyegon2 #5018 üzenetére

  Igazából Archon ez a core, extra, community elnevezések csak csomagellenőrzés komolyságára utalnak. A core a legszigorúbb, ott tesztelik legszigorúbban a csomagokat, csomag maintainerként oda a legnehezebb bekerülni, ott várják el a legnagyobb megbízhatóságot. Ettől függetlenül a community sem instabil, a core-ba csak néhány csomag van, ami az alaprendszer telepítéséhez kell, más nem is fog belekerülni, pl. a mate, mivel nem szükséges az alaptelepítéshez. Sokszor ugyanazok a maintainerek készítik a core és community csomagokat is, ha megnézed, így valójában minőségi szintkülönbség nincs közöttük. Ez csak alapfilozófia, hogy a core csomagok fontosabbak, még nagyobb figyelmet kapnak.

  Igazából ezzel az egésszel nem kell foglalkozni, vannak a hivatalos tárolók, onnan a pacman-nal telepítesz, és van a nem hivatalos AUR, ahonnan AUR-os progival, tipikusan yaourt, de fel lehet tenni mást is. Ennyit kell észben tartani.

  Archon is van stating, meg testing, ezekkel sem volt még negatív tapasztalatom, pedig a kerneleket innen szoktam szedni. Ezek a Debian testing, unstable-nek felelnek meg, de a gyakorlatban stabilabbak ezek. Archon nem nagyon fogsz találkozni beboruló, instabil, bugos csomaggal, még staging/testing tárolóban sem. Ha néha van is bug, az nem attól van, hogy a csomagkészítő hányja el a dolgokat, hanem a fejlesztő a git/dev ágba belefejleszt valamit friss feature-t, amit nem tesztel eléggé, és amíg nincs hibajavító kiadás, addig becsúszhat bug (ez is rettenet ritka, mint a fehérholló, stable tárolókban pedig elő sem fordul). Erről nem az Arch tehet, az Arch maintainer csak azt tudja csomagolni, amit az adott progihoz az eredeti fejlesztő fejleszt, azt nem látja előre, hogy a fejlesztő hagyott-e benne bugot (bár nyilván teszteli a gépén, meg testingben, meg stagingben mielőtt a stable tárolóba kerül, de az egész folyamat sokkal gyorsabb, mint a Debian/Ubuntu-vonal esetében). Az Arch alapfilozófiája, hogy vanilla csomagokkal dolgozik, nem nagyon módosítanak semmit a forráskódon, ahogy Debian/Ubuntu-vonalon (és ez jó, mert nem hekkelnek bele disztróspecifikus dolgokat, ami az életet bonyolítja). Az Arch csomagkarbantartói is épp úgy gitből húzzák az új verziókat, és az AUR-ban lévő pkgbuild scripthez hasonlóval forgatják le meg készítik a csomagokat. Igazából az egész folyamat teljesen megbízható, egy nagyon kipróbált rendszert járattak be a csomagkészítők. A gyakorlatban azt tapasztalatom, hogy az adott csomaghoz tartozó pkgbuild scriptet annyira tökélyre csiszolják, hogy ha leszeded, és kézzel újrafordítod (az a gitből a legújabb verziót fogja lehúzni), akkor az is normálisan fog működni, csak a verziószámot nem szabad elfelejteni átírni rajta, meg ha vannak verziófüggőségei más csomagoknál, akkor azoknál a verziószámot feltüntetni.

  Igazából az Arch csak annak nem való, aki nagyon kezdő/türelmetlen, vagy a gépén valami olyan speciális zárt drivert (hulladék hardverhez) vagy zárt progit kell használnia, ami régi csomagverziókra korlátozzák be, és emiatt nem frissíthet, utóbbi emberkéknek találták ki a Debiant meg a CentOS-t. Ilyen zárt hulladékokat egyébként is kerülni kell, ha egy mód van rá. Nem csak az Arch miatt, más korszerű disztróknál is ugyanez áll fenn.

  Ezért fontos a nyílt forráskód. Stallman, Torvalds meg a többiek nem azért találták ki ezt az egész GNU, free, opensource, GPL mantrát, mert ingyenélő hippik, akik be vannak szívva, meg mindent ingyen akarnak, humanitárius adakozóként azt akarják, hogy falu végén, fejkendős Mari néni unokájának is legyen ingyért valami a celeronjára, ha nem telik neki Windowsra meg MS Office-ra, hanem azért, mert észrevették, hogy jogi korlátok meg a zárt forráskód visszafogják az informatikai fejlődést, amit nem tartanak megengedhetőnek, mert utána csak a függőségi, terjeszthetőségi, karbantartási szívás van azokkal, kerülgetni kell másnak a szarjait, korlátozásait és nem tudnak az érdemi fejlesztésekre koncentrálni. Igazából a saját munkájukat könnyítik meg ezzel az alapfilozófiával, meg lehetővé teszik vele, hogy más is könnyen beszálljon a fejlesztésbe. Sőt, olyan nagy cégek mint a Samsung, Microsoft, Intel, IBM, Google sem azért fizetnek kernelfejlesztőket, meg pénzelik az egész kernelt, Linuxot, mert jótékonykodni akarnak PR-ból az adójuk 1%-ával, hanem tudják, hogy nekik is jól jön, ha kiadnak egy új technikai megoldást, hardvert, platformot, akkor mindjárt lesz rá támogatott OS, szoftver, lesz egy nyílt megoldás, amihez könnyen hozzá lehet nyúlni mindenféle megkötés nélkül. Így ha pl. a Fujitsunál holnap összedobnak valami új szuperszámítógépet, új speciális kínai processzormagokkal, akkor nem kell pl. a Microsofthoz elmenniük könyörögni, hogy lécci-lécci, támogassátok már a mi non-x86 ócskavasunkat is, adjatok ki rá valamit, ha más nem alfa állapotban, itt a sarokban porosodik, összedobtunk egy kis gépecskét, 300 ezer procimag, 25 PFLOPS összteljesítmény, 240 TB RAM, lécci-lécci, hadd wordözzünk rajta mink egy jóízűt, vaskos pénzeket tejelnénk érte. Ha egyáltalán a kérésük nem süket fülekre talál, akkor is évek lennének, mire a MS elő tudna állni valami használhatóval, addigra meg már az egész projekt aktualitását vesztené. Így meg csak ráheggesztik, hozzáfejlesztik az épp aktuális Linux kernelt, és azonnal beröffen a masina, lehet tesztelni, optimalizálni, kísérletezni vele. De elég volt megnézni, mikor törtek fel ezek a mobilos ARM-es olcsó eszközök, okosteló, táblagép, a Google egyből kapott az alkalmon, nem kellett a 0-ról OS-t kitalálni hozzá, hanem azonnal nyúltak is a Linux kernelért, kihasználva annak a rugalmasságát, portolhatóságát, jogi korlátozásmentes voltát, és az Androidot így akkora sikerre vitték, amit más azóta sem tudott megismételni, magyarán bőven visszajött nekik az a pénz, amit anno a kernel támogatásába öltek.

  Vagy egy másik példa, a mostani Spectre/Meltdown-sebezhetőség. Január elején publikálták, Linuxra már az első napokban megjelentek az első működő Meltdown patchek. A MS-nál először gond volt a patchekkel, aztán nekifutottak újra, aztán azzal is a gond volt, mert az Intel elcseszte a mikrokódot azokhoz a procikhoz is, amikhez egyáltalán adott ki. Aztán megint vissza lett vonva a Windows javítás, és azóta is várnak az Intelre, hogy mikor jön ki végre a javított mikrokód, amivel újra működhet és terjeszthető lesz a javítás. Erőforrásuk sincs rá, bevonni sem tudnak senkit a zárt forráskód miatt Közben meg a sötétebb oldalon teljesen más volt a hozzáállás. Nem vártak az Intelre, míg összeszedi magát, hanem lefejlesztettek saját, szoftveres megoldásokat, amihez nem kell a procira új mikrokód, a Meltdown elleni PTI már a kernelfejlesztők tarsolyában volt, de a Google is elég gyorsan előállt a retpoline technikával, meg pár hétre rá elkészült az user pointer sanitization. Így igaz, hogy linuxos vonalon is majd 30 napot kellett várni, míg minden foltozva lett egy új stabil kernelben, de egyrészt ezek linuxos szoftveres javítások kevesebbet lassítanak, mint a mikrokódos technika, plusz hamarabb is elkészültek, Windowsra még mindig nem jött ki a mai napig a végleges patch. Majd ha kijön, Torvaldsék megint lépéselőnyben lesznek, mert ők már nem hogy a patchon, de már annak az optimalizációin dolgoznak, amit addigra be is fejeznek, kijön a 4.16-os kernellel. Ha ők is vártak volna az Intelre, a mai napig nem lenne semmijük. A nyílt forráskód tette lehetővé, hogy ennyi fejlesztő ilyen gyorsan összedolgozzon, és ne kelljen függni az Inteltől. Csak hát megint ott van Gipsz Jakab, aki ezen kapva már tenné is fel a friss, javított kernelt, de oh wait, nem tudja, mert borul a rendszere, a zárt forráskodú szarja, amihez nem mer évek óta nyúlni, mert ne piszkáljuk azt, ami működik alapon még megy, és függősége van régi verziókhoz, így hiába lehetne előrelépni, vállalnia kell, hogy inkább sebezhető marad. Ugyebár az új kernellel dominósorban borulna neki minden, új kernel új systemdre és glibc-re dependel, de akkor már Xorgból is új kell, nem mennek a régi, egyedire fordított, azóta nyilvános nyílt forráskód hiányában újra nem forgatott kernelmodulok. Arch alatt meg a hobbista felhasználó kiad egy frissítés parancsot, és elégedetten használja az újdonságokat, anélkül, hogy PPA-val meg újraforgatással, disztrófrissítéssel, meg nem tudom mikkel kéne vergődnie, meg eltéesre meg feautre freezre és hasonló baromságokra várnia, hogy 1-2 év lemaradásban hadd használja már az épp aktuális verziókat.

  Pont most volt gondja ebből valakinek a HUP-on, Debianon akart a szentem új Wine-t, ami nemrég jött ki, frissen, ropogósan, mindenféle új DX/Vulkan támogatással. Próbálta PPA-ból felszögelni, de teljesíthetetlen verziófüggések léptek fel. Ezeket elkezdte egyenként kézzel feloldogatni, hogy azokból is új csomagokat vadászott és forgatott, de utána azoknak a telepítése is teljesíthetetlen verziófüggésbe ütközött, amiket szintén fel kellett volna oldani, de azt már nem vállalta be, mert ennyi erővel az egészet telepíthette volna újra kézzel. Archon én akkor már kb. egy hete azt a Wine 3.akármit használtam, ami szépen lecsorgott egy pacman -Syu során olyan szép csendben, hogy fel sem figyeltem rá, probléma nélkül működött, sőt, tegnap frissült még újabb verzióra (3.3), míg máshová a 3.0-ás sem érkezett meg. Azért ez nem kis különbség.

  Vagy szintén a HUP-on, még a Meltdown első heteiben indítja a topikot a szerencsétlen, hogy céges szerver, 3 tonna földdel elhantolva évek óta, megy, dolgát teszi, de most valaki véletlen átesett rajta, és ha már így belebotlottak, frissítették Meltdown ellen, és hiába zajlott le rendben a frissítés, meg volt hozzá backportolt kernel ebben a régi ágban, nem bootol. A történet lényege: CentOS 6 még 2.6.faxtudjamilyen kernel. No comment. De stabil volt, mint a beton. Míg frissíteni nem kellett. Amit nem lehet, csak ha az egész kócerájt újrarakja az ember.

  De ugyanígy fogom a fejem, mikor reklámozzák, hogy ilyen olyan LTS disztró kettőezerhuszonsokig támogatott lesz. De mi a francnak? Addigra olyan régiek lesznek a csomagok, hogy érdemben nem sok mindenre lesz használható, csak muzeális használatra lesz alkalmas, arra meg főleg desktopon minek? Ha egy új böngésző nem fog rámenni, meg egy idő után már a Flasht sem lehet frissíteni rajta? Ki a ráknak szánják?

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