-
Mobilarena
Linux kezdőknek - érdemes beleolvasni, mielőtt kérdezel
Új hozzászólás Aktív témák
-
Frawly
veterán
válasz
qwertly
#67478
üzenetére
Csinálhatod a klónozást Windows alatt is, pl. Macriummal. Legfeljebb abból lehet gond, ha a célmeghajtó kisebb, mint a forrás. A meghajtók mérete eltérhet, a rendszer, boot, stb. partícióknak kell azonos méretűnek lennie.
De dd paranccsal is klónozható, akkor is ha egyedi disztróról van szó. Egyedül a dd parancsnál arra kell figyelni, hogy előtte lsblk-val ellenőrizd az azonosítókat /dev/akármi, ha ezt félregépeled, vagy felcseréled a kimenetet és bemenetet, helyreállíthatatlan adatvesztést okoz! Meg kicsit hosszabban fog tartani, mert azokat a szektorokat is átklónozza feleslegesen, amikben nincs adat.
De akár még úgy is csinálhatod, hogy az SSD-n létrehozod ugyanazokat a partíciókat, amik a HDD-n is vannak, megformázod őket olyan fájlrendszerre, amilyenek az HDD-n vannak. Utána csak azonos partíciók között simán átmásolod linuxos fájlkezelővel a fájlokat. A végén legfeljebb a GRUB-ot lehet újra kell telepíteni.
-
Frawly
veterán
Mit tudom én, mutt/neomutt-os levelézéskor, vim-es mailíráskor, terminálos IRC chatben, stb. jól jöhet, ha te nem is használod, de mondjuk a küldő oldalon valaki használja, akkor normálisan megjelenik nálad is, nem krix-krax lesz a helyén. Ugyanolyan Unicode karakterek, mint a matematikai, nyomdai, fonetikai jelek. Én sem használok emoji karaktereket, de tőlem elfér.
Persze ez a betűtípustól is függ, egyes betűtípusok csak egyes Unicode-karaktereket támogatnak, emoji nincs bennük megrajzolva, vagy nem mindegyik.
-
Frawly
veterán
Az szerintem jó, ha a GPU rendereli a kimenetet. Amikor valami rengeteg sort ír ki a terminálban, vagy sok sort görgetsz, akkor a szűk keresztmetszet lehet a lassú szoftver render, főleg ha nem jól van implementálva.
Az emoji-hoz meg úgyse kell más, csak UTF-támogatás, de az meg úgyis jól jön mindenhez, fájlnevekhez, cat-kimenethez, terminálos szövegszerkesztőkhöz, stb..
-
Frawly
veterán
válasz
sh4d0w
#67438
üzenetére
Ezt simán lehetne kivitelezni, MS-tól függetlenül is. Mivel shell-es toolok nyílt forráskódúak, alapból vagy egy kis módosítás után simán lefordíthatók vagy az MS által újraimplementálhatók lennének Windowsra. Ilyenekre gondolok, mint az ls, du, df, grep, dd, curl, wget, stb.. Ezek egy része már most is létezik Windows alá. A Bash sem lenne téma.
De szerintem is, hosszú távon a Windows platform vagy ki fog halni, vagy átállítják Linux vagy valami BSD-forkos kernelre.
-
Frawly
veterán
válasz
kmarci25
#67426
üzenetére
Akkor is fura. Törölni csak úgy lehet bármilyen fontos dolgot, hogy
1) fájlkezelőben törlöd magát a fájlt
2) vagy csomagkezelőben a vonatkozó csomagot távolítod el.Ezekhez viszont rendszergazdai jogot, jelszót is fog kérni a rendszer, nem lehet véletlen csak úgy letörölni.
Te egyiket sem tetted, egy egyszerű, ikonokkal/linkekkel dolgozó alkalmazásindító menüből vettél ki egy ikont/linket. Ez épp olyan, mintha Windows alatt a Start Menüből vagy az Asztalról töröltél volna egy parancsikont, ez magát az alkalmazást, rendszerkomponenst NEM távolítja el. Nem véletlenül nem kért jelszót sem hozzá.
Egy esetet tudok elképzelni, mikor a menü Automatikus Indítás részéből törölsz egy linket, akkor sem törlődik az alkalmazás, de nem fut le induláskor, az okozhat galibát, de rendszert annak sem kéne eltörnie bootképtelenre. De ilyen nem minden disztróban, asztali környezetben, grafikus felületen van.
-
Frawly
veterán
válasz
CPT.Pirk
#67409
üzenetére
Ezt utálom a Phoronixban, mindig írnak valami nyálcsorgató fejlesztést, de mindig valami nagyon távoli verzióban. Az 5.2-es kernel még nagyon messze van, az 5.1 végleges sem jött még ki.
Most a Mesa 19.1-ben bevezetett Direct3D 8-9 támogatásra is csak úgy csöppent a nyálam, Wine-ben szinte natív sebességgel fognak futni a játékok. Erre benyögi a cikk, hogy majd a 19.1-ben, ami 2019 Q2 vége. Fasza. Még egy olyan bleeding edge disztró esetében is, mint az Arch, várni kell rá egy csomót. Ubuntunál kell majd 1 év, Debiannál több is, mire lecsorognak ezek a fejlesztések.
-
Frawly
veterán
válasz
scream
#67392
üzenetére
Nincs felcserélődve. Az deafult magyar kiosztásban vannak jó helyen az í és a 0, és a rágott alma használ ANSI kiosztást az ISO világszabvány helyett. Az a megoldás jó rá, amit írtak.
De ezért érdemes megtanulni vakon gépírni. Többé nem lesz érdekes mi van a billentyűkre írva, nem kell matricázgatni a billentyűzeteket, ha külföldi. Én pl. brit ISO billentyűzetet használok, és egyáltalán nem zavar, hogy máshol van az z/y, 0/ö, stb., mivel nem nézek le. Bekapcsolom szoftveresen szabványos „hu” kiosztást és az UTF-8 kódolást, és jó idő. Nincs baj sem az ékezetes billentyűkkel, sem az ékezetes karakterekkel.
Egyébként az ANSI kiosztással sem lenne baj, de az amerikai billentyűzetre való, ahol nem használnak ékezeteket. Nemzeti, lokalizált kiosztásoknál csak a gond van vele. Nem véletlen a nemzeti gépírásszabványok is az ISO kiosztáson alapulnak.
Egyébként Amerikában is csak azért maradt népszerű az ANSI kiosztás, mert abban egy soros hosszú Enter van, amit könnyebb jobb kisujjal elérni gépíráskor, nem kell annyira messzire kinyújtóztatni, mint a fejjel lefelé fordított L alakú ISO Enternél, de ezért az egyetlen előnyért más téren kell árat fizetni.
-
#67374
Frawly
veterán
LantosBerry8
#67373
Frawly
veterán
válasz
LantosBerry8
#67373
üzenetére
GPU driver nincs rendben. Milyen gép is ez pontosan? Főleg a GPU lenne érdekes.
-
Frawly
veterán
Igen, normális. Az Android Studio egy nagy megabloat Qt-s alkalmazás. A flatpack csomagok meg nagyok, mert az összes .so modult is hozzácsomagolják az alkalmazáshoz, azokat is, amik már fent vannak a rendszereden meg fent vannak a disztród tárolójában, mert a flatpack csomag kiadója nem lehet biztos, hogy az az adott függőség a te gépeden, a disztród tárolójában elérhető lesz, vagy ha elérhető is, akkor nem lesz elavult verzió. De flatpack nélkül ezt csinálja régóta a Steam is.
A flatpack mindenképp bloat, akármit csinálsz. Ha csak egy mód van rá, ne használj ilyeneket, tedd fel az adott szoftvert a disztró tárolójából, vagy valami megbízható külső tárolóból.
(#67359) ubyegon2: így van, ebbe most nagyon beletrafáltál. Viccen kívül, van olyan flatpack csomag, ami tényleg egy giga fölötti mennyiséget hány fel a gépre. Sokkal rosszabb, mintha 400 MB-nyi KDE függőség jönne le a csomagkezelővel. Ha csak egy mód van rá, akkor az ilyen Flatpack, Snap, Appimage univerzális csomagok használatát kerülni kell. Ezeknél még sokszor az is jobb, ha inkább forráskódból forgat valaki. Tényleg csak a vészesetben érdemes hozzájuk folyamodni.
-
Frawly
veterán
válasz
Apollyon
#67352
üzenetére
Nekem még nem ment tönkre. Igazából az umount nélküli lehuzigálás nem a pendrive-nak árt fizikailag, hanem a fel nem írt adatok vesznek el, meg inkonzisztens lesz logikailag a fájlrendszer. Valóban nem javasolt lehuzigálni, akinek nincs türelme, másoljon hálózaton vagy neten keresztül.
-
Frawly
veterán
válasz
zoltanz
#67336
üzenetére
Valószínű, hogy neked nem is kell más, ha a Debian kielégíti az igényeidet, megy, és nem érzed úgy, hogy valamiben is korlátozna, vagy a régebbi csomagverziók gondot okoznának. Úgy valóban nem érdemes disztróhoppolni, hacsak nem tanulási, szakmai fejlődési célzattal.
Még a grafikus felület, DE/WM váltása sem ok disztróhoppolásra, Debian minimum netinstallra bármit feltehetsz igény szerint és feltémázhatsz.
-
Frawly
veterán
Igen, ezt valóban rosszul írtam. Azóta én is rájöttem, de nem tudtam már szerkeszteni. Kicsit csodálkozok, mert évekkel ezelőtt olvastam, hogy az Ubuntu dobni fogja a speciális architektúrákat és csak az x86-ra és x86_64-re koncentrál, mivel asztali disztró akar lenni. Azóta meg dobták az x86-ot is.
Azt tudtam, hogy van arm-fork is, de külön projektként futtatva.
-
Frawly
veterán
válasz
anorche1
#67332
üzenetére
Ja, hogy ez volt a baj. Ezek szerint csak nem frissült a keyring csomag. Máskor bármit telepítesz, ne pacman -S csomagnév formában tegyed, hanem pacman -Syu csomagnév kiadásával. Sok szívástól kíméled meg magad. Ez még Debian/Ubuntu-alapú disztrókon is így van, ahol ajánlják, hogy a apt upgrade && apt update előzzön meg minden mást.
@ubyegon: felesleges egy gépre 3 disztró. Vagy ha van is, akkor úgy nem ér semmit, hogy az idő 99%-ban Mint fut, és csak 1%-ban próbálgatod a többit. Úgy lenne értelme, hogy elszánod magad, és akkor mondjuk 3-4 hétig csak Manjaro-t nyomatsz. Vagy Chackrát, gondolom az a half rolling, ami még fent van. Úgy nem lesz egy rendszerrel tapasztalatod, ha csak néha napján megjáratod és lefrissíted. Egyébként meg ha egy disztró rendesen be van állítva, akkor a mindennapi használat során nem sok különbséget kéne érezzel és egy kiadás alapú és egy rolling disztró között. Az csak akkor jön elő, ha mondjuk forráskódból forgatva teszel fel dolgokat, vagy valami olyan új feature kell, amit csak az új verziós csomag tartalmaz.
-
Frawly
veterán
válasz
Rimuru
#67317
üzenetére
Mivel nem írtad, hogy mivel nem értesz egyet, így úgy veszem mindennel egyetértesz.
ubyegon2: most nézem, mi ez a Manjaro telepítés ott fönt a gépeden? A Mintesek vagy a HP megtudja, hogy rollingozol, és neked annyi. Örök kezdőknek nem szabad ilyet felrakni. Instabil, meg eltörik és a Wi-Fi-od sem látja. Nagyon remélem, hogy legalább Cinmanóval van feltéve
![;]](//cdn.rios.hu/dl/s/v1.gif)
(#67324) Bici: nem csak hogy a legtöbb nem rolling disztrón, de lényegében egyiken sem megy. Most az Ubi 19.04-es az első, ami az 5.0-ás kernellel tudja. Vagy ha Debian alatt SID-et használsz vagy Fedora, ami félrolling, ilyesmi. De pl. ha valaki Proton-ozik, annak is nagyon melegen ajánlottak a minél frissebb csomagok, akkor is, ha a hardver, amin fut, nem túl új.
De arra hála istennek nem kell majd sokat várni, hogy a Mint is támogassa az ilyen Raven Ridge és egyéb újdonságokat. Röpke 1 évet (20.04-es Ubuntuig)
Bár valami kernel utility ott is van biztosan, amivel hamarabb fel lehet hegeszteni egy 5.0-ás kernelt. -
Frawly
veterán
Ezt nem is tudtam, hogy a Cannonical is foglalkozik már ilyennel.
Az egész linuxos világ arról szól, hogy teszter vagy meg a saját időddel fizetsz. Nem csak Red Hatnál meg a SUSE-nél van így. Már a Win10 is erről szól, ha nem LTBS ágat használsz, akkor bizony kapod arcba rendesen a ki nem tesztelt frissítéseket, telemetriával meg kaszálják be a teszteredményeket, de legalább fizetsz is érte, hogy tesztelhess. Mac-nél meg a túlárazott hardverrel fizeted ki a szoftveres ökoszisztémát.
A CentOS meg hiába közösségi, ugyanazt a kódbázist kapod, ugyanazokat a csomagokat, ugyanazt a Red Hat patches kernelt, stb..
Bár én ezt valahol hátránynak tartom. Az ilyen spéci disztrókon gond lehet, hogy valami spéci kernelpatch vagy fordítási beállítás miatt nem megy egy lefordított csomag. Míg pl. Archon minden csomag vanilla állapotban van, nincs semmi disztróspecifikus hack bennük, ami bezavarhatna akárminek is.
-
Frawly
veterán
válasz
MineFox54
#67323
üzenetére
Nem is mondtam, hogy az Arch rossz. Nem véletlenül használom én is évek óta. Nyilván, ha szükséged van ilyen spéci i3wm-es dolgokra, meg az Arch Wikire, akkor azt kell használni. Akkor felesleges is pedzegetni, hogy esetleg nem-e Debian legyen helyette, adva lesz, hogy mit használj.
Egyébként biztos vagyok, hogy Debianra is elérhető i3gaps és egyéb, csak valami külső tárolót kell hozzá felvenni, vagy weboldalról .deb csomagot összevadászni.
Bár igazából az i3wm-es cuccok kódbázisa és függőségfája nem nagy, ilyen i3gaps, meg i3lock-color hipp-hopp leforgatható egy git clone https://blabla && ./configure && make && make install után.
-
Frawly
veterán
válasz
kovaax
#67319
üzenetére
A Red Hat meg a SUSE nem a Linuxból gazdagszik, hanem abból, hogy megoldásokat épít rá, meg supportot árul hozzá cégeknek. Maga a linuxuk nem kerül pénzbe, bármikor feltehetsz ingyen is egy Fedorát, CentOS-t vagy OpenSUSE-t, ugyanazt kapod, mínusz a support.
Azt viszont sose tudtam, hogy a Canonical miből él. Szerintem csak azért marad fent, mert Mark Shuttleworth milliomosként pénzeli. De ha megunja, hogy csak a pénzt viszi, cseszhetik.
-
Frawly
veterán
válasz
MineFox54
#67316
üzenetére
Ezt neked kell tudni, hogy mennyire van szükséged új verziós csomagokra. Jellemzően akkor van szükséged ezekre, ha nagyon új hardvered van, vagy játszol (Wine, Lutris, Stream, Proton, DXVK, stb.), vagy streames, multimédiás dolgokkal foglalkozol.
Az extrém hosszú élettartamú csomagokkal meg az a baj, hogy egy idő után elavulnak, és nem tudják kielégíteni az újabb alkalmazások függőségeit.
Véleményen szerint a Debiannak nem a hosszú csomagélettartam az előnye, hanem
1) ez a disztró támogatja a legtöbb architektúrát (arm, arm64, sh, powerpc, m68k, mips, sparc). Ez persze egy Gentoo-n is megoldható, de azon neked kell mindent fordítgatni, meg kínlódni vele. A Debian ezt készen nyújtja. Ugyanezt egy Arch, Fedora, Ubuntu nem tudja nyújtani, azok már csak jellemzően x86_64-re vannak és kifújt, se x86, se semmi (jó, van Arch32 és Arch Arm is, de az külön disztró). Ezzel szemben egy Debian elindul elvileg egy 486-oson is (386-oson is ment, amíg a 3.8-as kernelből ki nem szedték a támogatását), igaz köszönet nem lesz benne, csak a boot tart percekig, míg a modern disztrók már dobták a 686-os támogatást is lassan.
2) ehhez van a legtöbb csomag. Valami jóval 40 ezer fölött van, és még erre jön rá egy csomó PPA, meg egyéb weboldalakon fellelhető .deb csomag. Ehhez képest egy Ubuntu-n már kevesebb csomag elérhető, de még mindig szép szám, meg jók hozzá a .deb csomagok. Archon pl. ezzel szemben kb. 10 ezer csomag van mindössze, zusammen, tehát hivatalos tárolók + AUR. Persze, forráskódból forgatás is játszik, de akkor megint nem vagyunk előrébb egy Gentoo-hoz képest, a Debian meg ezt nélkülözhetővé teszi
3) nagy szervezet áll mögötte, sok fejlesztő, sok csomagfenntartó, nincs az, hogy ha valaki kiesik, annyi a projektnek, meg holnaptól egyszer csak megszűnik. Persze már egy Arch-ot sem fenyeget ez a veszély, elég széles tábora van, már jelen van 17 éve, elég sok disztró épül már rá, nagyon nem úgy tűnik, hogy a közeljövőben hanyatlásnak indulna.
4) Debianhoz előbb találsz segítséget, többen ismerik, több tutorial, blogpost, stb. van róla, ha problémába ütközöl, előbb találsz hozzá megoldást a neten, mint Archhoz. Archhoz ott a Wiki meg a fórum és kifújt.De ha rollingot akarsz, de nem akarsz Debianról váltani, akkor válts át SID tárolókra. Azzal is kvázi rollingot kapsz.
-
Frawly
veterán
válasz
kovaax
#67314
üzenetére
Nyilván, ha valakinek fizetős Oracle kell, meg Red Hat kernel alá, az így járt, maradjon csak vendor lock-in-ben. A Linuxnak az lenne a lényege, hogy nyílt forráskód, bárhol lefordítható, beüzemelhető, disztrótól, gyártótól függetlenül.
A rollingokhoz support nem jár. Azt magadnak supportálod. Ha nem bírod, használsz helyette Windowst, vagy megbízol vele külső céget.
Azt meg nem látom, hogy ha a Linux világa a pénzről szól, hol van benne a pénz. Az én meglátásom szerint nem a pénz miatt fejlesztik, hanem a nagy cégek akarnak olyan platformot, amit az egész iparág használhat, nem kell egy gyártótól függeni. Ellenkező esetben, ha nem lenne a Linux, a MS-nak még nagyobb hatalma lenne, aztán várhatnánk arra, hogy valami új architektúrát vagy technológiát támogassanak. Kicsit érdekes is lenne nagy szerverfarmokon meg szuperszámítógépeken, ha nem lenne Linux. Na, azokra próbálj Oracle-szart meg Windows felrakni, minimum érdekes lesz. De ez a valóságban nem probléma, mert akinek ilyen komoly eszközparkja van, az supportál magának bármit, ők általában saját disztrót szoktak hegeszteni és supportálni maguknak. Olyan nagyokról beszélek, mint a Google és társai. Nincsenek rászorulva egy cégre meg semmilyen LTS-re sem.
Meg az egész vita onnan indult ki, hogy volt egy szerver valahol, ami annyira nem volt fontos, hogy évekig hozzá sem nyúlt senki, nem tartotta karban. Na, azon aztán tényleg baromi fontos az Oracle, az audit, meg support, és tényleg nem mehetett volna rá rolling.
Félre ne értsd, nem a rollingot akarom éltetni mindenáron, mert nem való mindenhova, csak azt mondtam, hogy nem igaz az ellenkező mantra sem, hogy a rolling ne lenne alkalmas bármire. Itt volt kolléga, aki kijelentette, hogy szerverre nem szabad rakni, mert instabi, meg jön a szerverrendőrség, rád rúgják az ajtót, és ha meglátják, hogy ilyen Arch vagy Gentoo van fent, legumibotoznak.
-
Frawly
veterán
A keyfile-ozást nem ajánlom. Több okból is: bekészíted vele a kulcsot a lábtörlő alá, így a titkosítás komolytalanná válhat. Másrészt meg rizikós is, véletlenül olvashatatlanná válik a kulcsfájl, buktad a titkosított adatokat, ha nincsenek meg titkosítatlan mentésben. Persze lehet biztonsági másolatot tartani a keyfile-ról, de akkor meg még több kulcsot készítettél be a lábtörlő alá.
Azt kell érteni, hogy a kényelem és a biztonság ellentétes fogalmak. A jelszót beírni kényelmetlen minden bootkor meg meghajtófelcsatoláskor, főleg ha kellően erős és hosszú, de cserébe a legbiztonságosabb módszer. Én minden bootkor beverek egy 20+ karakteres ATA jelszót (korábban én is LUKS dmcrypt-et használtam épp ilyen jelszóval), majd felhasználói nevet, és egy 10+ karakteres felhasználói jelszót. De csak 1-2 másodpercig tart. Már annyira rááll a kezem, hogy fel sem tűnik, nem esik nehezemre.
-
Frawly
veterán
válasz
anorche1
#67302
üzenetére
Próbáld meg újratelepíteni a keyring csomagot. Majd kiadni a pacman-key --init parancsot. Ellenőrizd, hogy jó-e a gépen a dátum. Itt részletesen írnak a teendőkről.
Ha semmi más nem segít, a /etc/pacman.conf-ban mindjárt az elején az [options] részben a SigLevel-es változóknál a Required és Optional helyére írd be a TrustAll értéket, és úgy futtasd újra a pacmant. Csak ideiglenesen, míg felrakod a csomagot. Néha van, hogy a csomagkészítő kulcsa lejár, és elfelejt újat generálni. Jelezni kéne a Manjaro fórumán.
-
Frawly
veterán
válasz
Shyciii
#67296
üzenetére
Szerintem nem kell ezt ilyen komolyan venni, nem kell sehonnan elköszönni. A Linux világa eleve a sokszínűségről szól. Lesznek emberek, akiknek a rolling soha nem fog bejönni. A régi kiadás alapú modellhez szoktak hozzá, vagy volt valami régi rolling rendszerrel rossz tapasztalatuk, és nem tudod őket meggyőzni, hogy már nem ez a helyzet.
Meg a rolling sem való mindenkinek. Nagyon kezdőeknek az Archot ezért sem ajánlom, a Manjarót igen, de kezdőknek az AUR-ral vitézkedést az alatt sem javaslom, valami elcsesződik, nem lesz meg a tudásuk, hogy helyrehozzák, annak ellenére, hogy megoldható a helyzet olyankor is. Ha nem használnak túl friss hardvert, nekik tényleg jobb lehet valami kiadásalapú disztróval kezdeni. Legfeljebb nem frissítik, hanem újrahúzzák új kiadásnál, egy kezdő úgyis el szokta tolni az első pár telepítését, úgyis újra kell telepítsen.
Viszont aki komolyan gondolja a linuxozást, meg nem akar örök kezdő maradni, annak mindenképp javaslom a full rollingozást hosszú távon. Ha nem is feltétlenül Arch, de valami rolling rendszer. Szerintem nagyon hosszú időtávban (sok évre előre) gondolkodva előbb-utóbb a kiadás alapú disztrók is átállnak rolling modellre. Az Apple régóta így tolja, most az MS is elkezdte, igaz ők még nem valódi, hanem csak kvázi rollingot tolnak, de már jelzés értékű a tendencia.
-
Frawly
veterán
válasz
zoltanz
#67286
üzenetére
A YouTube-dl gakori frissítésére szokj rá. Vannak időszakok, hogy naponta frissül. Nem azért, mert a fejlesztők unatkoznak, hanem a Google állandóan variál valamit, hogy ne menjenek normálisan ezek a 3rd parti letöltőappok, ezeket a Google károsnak tartja, mivel ha ezekkel töltikézed le a videókat, nem fogod látni a reklámokat, bevételtől esnek el, meg nem tudnak mindenféle sütivel követni, meg az előzménylistádat marketingcélokra felhasználni, meg telemetriázni vele. Kvázi warez-nek tekintik, nem véletlen, hogy a Google sose ad ki hivatalos YouTube-letöltő appot, csak olyat, amiben nézni lehet reklámostól a videókat, de letölteni véletlenül sem.
A YouTube-dl a neve ellenére nem csak a YouTube-ról tud letölteni, hanem még vagy 100 másik hasonló videómegosztós oldalról, és valamelyiknek mindig reszelnek a kódján! Ez egy ilyen műfaj, az ilyen letöltős alkalmazásokat gyakran kell frissíteni, különben nagyon gyorsan olyan szituban találod magad, hogy valami nem működik.
Vannak ilyen alkalmazáscsoportok, amiből mindig a legfrissebb kell, pl. letöltő appok, böngészők, médialejátszók, stream lejátszók (pl. Netflix app), stb.. Ezekkel csak szívni fogsz, ha nem relatíve frisset használsz.
-
Frawly
veterán
válasz
ubyegon2
#67285
üzenetére
De a rolling abszolút összeköthető a stabilitással. Ha nem akarnék szívni ilyen bleeding edge, kísérleti Waylanddel, akkor felraknék egy Gnome-ot, Xfce-t, Openboxot vagy akármit a hivatalos tárolókból, simán menne hiba nélkül.
Igazából a rolling disztrók semmivel nem instabilabbak, mint a kiadás alapúak, sőt, inkább stabilabbak is, mivel egyszerre sose frissül túl sok dolog. Kis adagokban halad a frissítés, ha el is törik valami, akkor az az egyvalami fog csak bugzani, nem az egész disztró, és az az egy dolog is javítható szokott lenni egy kis hackeléssel vagy egy másik csomaggal történő helyettesítéssel. Ha a kiadás alapú disztrókon a disztrófrissítés kefélődik el, az egész nettó használhatatlan lesz, az összes csomag frissül egyszerre, sokkal nagyobb az esélye, hogy valami eltörik, nem frissül le rendesen.
Szerintem jelen esetben a sway-t fordító script nem fordított újra valami modult, és ez okozta a hibát. Ezeket a scripteket v1.0-ás userek töltik fel, nem garantálható a stabilitásuk.
Na meg rolling és rolling között is óriási különbségek lehetnek, fél/teljes rolling, teljes rollingnál is vannak friss és kevésbé friss megoldások. Nem lehet őket egy kalap alá venni.
-
Frawly
veterán
válasz
ubyegon2
#67281
üzenetére
Nem, az Arch-csal nem kell szívni. A hivatalos tárolói teljesen rendben vannak, még a testing is. Ami ilyen veszélyes, az az AUR, ahová akárki tölthet fel scriptet, ebben a műfajban tényleg törhetnek el dolgok, főleg, ha ezeket nem gondozzák.
Meg igazából jelen esetben nem is értem mi volt a probléma. Egy jól működő verzió frissült ugyanarra a verzióra, ami meg bugos volt. Fene se érti ezt. Aztán mindent leszedve, majd visszarakva, megint csak ugyanaz a verzió megint jó lett
-
Frawly
veterán
Jajj, ne is mondd, tegnap a Sway WM jól beszopatott Arch alatt. Az AUR-ból van fönt a git-es verzió, yay-jal kézzel befrissítettem, mert RC1-esem volt, és láttam a git-en, hogy van belőle RC5-ös. A függőségét az wlroots-t is befrissítettem, az is újrafordult. De ugyanazokat a verziókat fordította és telepítette újra, amik fönt voltak, RC1-t a master branch-ből. De mégis elkezdett az egész bugzani, használhatatlan lett, furcsa hibák tömkelegét produkálta. Le kellett kézzel szednem (-Rns kapcsoló yay-ben), a pacman és yay cache-t törölnöm (-Scc kapcsoló), majd az egész cuccos újra fordítanom, felraknom yay-jel, most megint jó. Fölöslegesen jól megszopattam magam. Pedig tudom, hogy az AUR-os csomagok veszélyesek, azokat óvatosabban is frissítem, mint a pacman-os csomagokat.
-
Frawly
veterán
válasz
ubyegon2
#67267
üzenetére
Végső soron attól függ, hogy mire lesz használva a pendrive. Ha nem lesz rajta túl sok írás, akkor mindegy milyen fs van rajta. De ha mondjuk valami OS lesz rátelepítve, vagy gyakran fog cserélődni sok adat, akkor valóban, egy nem naplózó ext2 vagy egy flashbarát f2fs ideálisabb rá, vagy FAT32 vagy exFAT, ha windowsos gépben is lesz használva. Bár az f2fs-re vigyázni kell, mert ilyen default pi-disztrókra nem biztos, hogy alapértelmezésben telepítve lesznek az f2fs-hez szükséges dolgok. Az ext2 az mindenhol megy.
-
#67243
Frawly
veterán
Plasticbomb
#67242
Frawly
veterán
válasz
Plasticbomb
#67242
üzenetére
Nem értek hozzá, biztos lehet így is. Az a gyanúm mégis, hogy ennél a kernelhekkelős megoldásnál épp úgy bukod a jövőbeni MacOS frissítéseket, ahogy egy natív Hackintosh telepítésnél. Azzal a módszerrel, ami Linusék videóján van, teljes értékű a MacOS, a jövőbeli frissítések is simán felmennek majd rá. Gondolom én, de nem vagyok Mac-es, sose volt Mac-em, ki nem állhatom az egész Apple ökoszisztémát.
-
Frawly
veterán
válasz
CPT.Pirk
#67237
üzenetére
Ezen a videón röhögtem, milyen bonyás. Nem teljesíthetetlen, de eléggé képben kell lenni hozzá, ráadásul a videón egy csomó mindent nem mutatnak meg, amit kivágtak, vagy nem látszik, mert fel lett gyorsítva a felvétel. Főleg a kommentek érnek aranyat, több embernek az álla leesett, hogy milyen bonyolult, írogatják, hogy inkább vesznek Mac-et
Pedig még előnye is van az igazi Mac-kel szemben, pl. AMD-n is használható (több core/thread érhető el, mint bármelyik Mac-en), akármilyen GPU-val megy (ezek megint csak nem érhetőek el Mac-en).
A videókártyás átadás nem nagy szám, már többször írtunk róla itt a linuxos topikokban is, mikor a VT-d-t és a PCI(e) passthrought-t feszegettük. MacOS-en sem az a nehéz, hogy átadd a videókártyát, hanem hogy a Mac idióta korlátozásait ki tudd játszani.
-
Frawly
veterán
válasz
Anakin007
#67204
üzenetére
A Kubuntuban ideiglenesen kapcsold ki a kompozitort. Annak a GPU-nak vinnie kéne azt a játékot. Nekem csak egyel újabb GPU-m van (HD3000), Intel Core i 2. generációs (ThinkPad X220-ban i7-2620M) , igaz az már OpenGL 3.0, de viszi. Ha te a tiédet OpenGL 2.0-ra állítod be a játékban, akkor mennie kéne akadás nélkül.
Ennek ellenére az Intel IGP egy rakat fos. Az újabbak is, hiába erősebbek, hiába támogatnak OpenGL 4.5-öt, DirectX 12-őt, Vulkant, egyrészt a teljesítményük kakát se ér, másrészt meg ezeket az API-kat is hiányosan támogatják. Pl. a Medal of Honor: Allied Assultnál futottam bele, hogy az OpenGL verziója megfelelt neki, de hiányolt bizonyos OpenGL extensionöket, amit egyik Intel GPU sem támogat, és ez a Steamen is ki van írva. Persze ki lehetett hekkelni környezeti változókkal és registry-trükközéssel, hogy ne keresse ezeket, hanem tiltsa le a használatukat, de azért cinkes, hogy még 2019-ben is annyit ér egy integrált GPU, hogy egy 17 éves játékot sem tud alapból futtatni, tiszta szégyen.
A mobil AMD APU procikban lévő Radeon sokkal többet ér, normálisabb fps-eket hoz, normálisan támogatja az API-kat, csak ugye nem volt elterjedve, szinte mindenki az Intelre épített. Most ugyan jelentek meg mobil Ryzen-es laptopok, de még mindig nem kellő számban, illetve ezek meg az energiakeret miatt throttlingolnak általában.
Illetve ha Thinkpad, akkor nézd meg, hogy támogat-e PCIe Express Cardot, azon keresztül tudsz rákötni külső GPU-t, én is most fogok ilyen eGPU megoldást venni. Így rendesen, asztali videókártyát tudsz asztali táppal meghajtva rákötni a laptopra, csak egy ilyen Express Card és hozzá kötött átalakító kell neki. Linuxhoz lehetőleg AMD kártyát vegyél a normálisabb nyílt driver miatt.
Sajnos muszáj ilyet beszerezni a legminimálisabb szintű játékhoz is. Ez a laptopok közös gyenge pontja, a képernyő és a GPU. A legfelső árkategóriás gamer laptopokban ez meg van oldva, normális IPS 1080+ kijelző, dedikált GPU, méreg drágán, a többi laposra meg rakják a TN paneles trágyát (azt is lehetőleg 1366x768-as felbontásban, mert azt „ought to be enough for anybody ©”) meg az integrált 3D lassító hulladékot, mert olcsó és keveset fogyaszt. Még a méreg drága Macbook laposokban is csak ilyen Intel IGP takony van.
Ez a PCIe Express Card-os móka is csak üzleti notikon játszik, ami egy szűk szelete a piacnak. A notigyártókat szívlapáttal kéne agyonvágni, hogy ne rágják a szart.
Elvárható lenne, hogy olyan GPU-t rakjanak a termékekbe, ami legalább 10 évvel ezelőttig bezárólag elviszi a játékokat, még ha kompromissszumos grafikán is, de minimálisan játszhatóan. Még a fejlesztési nehézségeket sem tudom elfogadni, nyugodtan kiindulhatnának egy 10 évvel ezelőtti csúcs GPU-ból, azt le tudják ma már gyártani sokkal kisebb csíkszélességen, úgy, hogy szinte alig fogyaszt pár W-ot. Még VRAM sem kell, mivel tudná használni a DDR4 RAM-ot, ami kielégít egy ilyen régi GPU-t sávszélességben. Érdekes telókba, táblagépekbe tudnak ARM prociba integrálni normálisabb GPU-kat, nehogy már egy laptopba ne tudjanak.
-
Frawly
veterán
válasz
ussseal
#67196
üzenetére
Ez azért attól is függ, hogy milyen GPU van a gépben, azt milyen GPU driverrel hajtod, és még attól is függ, hogy milyen játékokkal játszol, azok közül valamelyik natívan fut vagy Wine alatt, utóbbi esetben az is számít, hogy mennyire tolerálják normálisan a Wine emulációt, mekkora emulációs overhead jön ki. Egyes játékok jobban vannak windowsos driverekre optimalizálva.
Emulációnál meg a Mesa OpenGL-nél a Mesa Vulkan jobb fps-számokat adhat, ha a GPU támogatja a Vulkant.
Ez egy nagyon sok tényezős dolog, komplex téma, nem elég olvasni róla, ki kell próbálni, tesztelni kell az egyes lehetőségeket.
-
Frawly
veterán
válasz
growler
#67185
üzenetére
De lehet működne, de az megint egy plusz dolog lenne, amit fel kell tennem, és vagy működne vagy nem. Kösz, de inkább nem.
A szétgányolást meg nem csak úgy értem, hogy a rendszer működésképtelen lesz, hanem hogy felkerül egy csomó felesleges csomag. Pont így szoktak túlhízni a rendszereim, próbából felteszek minden szart, később meg nem tudom mi micsoda, nem merem leszedni. A pacman-t is hiába hívom meg, hogy a függőségeket vizsgálva szedjen le felesleges csomagokat, nem járható út, mert van néhány portable progim és játékok, amiknek kézzel tettem fel a függőségét, azokat is leszedné, holott azok kellenek. Erre megoldás lenne, ha a csomagkezelőbe felvennének egy olyan feature-t, hogy telepítéskor megjegyzést lehessen hozzáfűzni a telepített csomagokhoz, hogy mihez kerülnek fel, így eltoválításnál egy listában egyenként végig lehetne menni, hogy mi nem kell.
Egyébként ahogy olvasom, a pkexec működésképtelensége a Wayland sara. Vagyis nézőpont kérdése, a pkexec hibája is, hogy széndékosan csak Xorg-hoz fejlesztik.
Pedig még tényleg egy ilyen sudo -e vagy admin:// szerű megoldás is jó lenne, hiszen magának a proginak tényleg nem kell rendszergazdaként futnia ahhoz, hogy el tudjon érni rendszergazdai fájlokat. Ha meg tudnák ezt oldani, hogy pl. grafikus telepítőkkel és fájlkezelőkkel is menjen ez, akkor szükség sem lenne a pkexec-re.
-
Frawly
veterán
válasz
Frawly
#67182
üzenetére
Most így utánaolvasva telepítettem a polkit-gnome csomagot és úgy sem megy. Igaz a polkit managert is el kéne indítani, és azt nem tudom.
Az is biztos, hogy nem a hiányzó d-bus a baja. Feltehetném azt is, de nem fogom a telepítésem szétgányolni egy barom pkexec kedvéért.
Amit az Arch Wiki javasol: admin://, de ehhez GVFS-nek fent kell lenni, és az adott proginak is támogatnia kell elvileg.
A másik, amit az Arch Wiki említ, sudoedit, vagy sudo -e. Lényegében ez is megfelel az admin://-os megoldásnak, a progi korlátozott jogokkal fut, de a fájlokat rendszergazdaként éri el. Hátránya, hogy szövegszerkesztőkhöz jó, de fájlkezelőkhöz nem.
-
Frawly
veterán
Kösz az infót. Ezek szerint nem a disztró számít, hanem az adott proginak kell tudnia ezt az admin:// előtagot kezelnie. xed-del nem próbáltam, az nincs fent, és csak a tesztelés kedvéért nem is fogom feltenni. Én GVim-mel próbáltam, az az egyetlen grafikus szövegszerkesztőm most fent, de azzal nem megy. Terminálban indított text editorok meg kiírják, hogy nem találják az admin://-rel kezdődő fájlt.
De pl. nálam Archon a pkexec sem megy:
pkexec env DISPLAY=$DISPLAY XAUTHORITY=$XAUTHORITY gvim
==== AUTHENTICATING FOR org.freedesktop.policykit.exec ====
Authentication is needed to run `/usr/bin/env' as the super user
Authenticating as: felhasználónév
Password: bla-bla
polkit-agent-helper-1: error response to PolicyKit daemon: GDBus.Error: org.freedesktop.PolicyKit1.Error.Failed: No session for cookie
==== AUTHENTICATION FAILED ====
Error executing command as another user: Not authorizedThis incident has been reported.
Az is igaz, hogy nálam Wayland alatt hátrányból indul ez a koncept, de elvileg az XWaylandnek kielégítően kéne emulálnia minden szükséges Xorg-os hülyeséget.
-
Frawly
veterán
válasz
ubyegon2
#67174
üzenetére
Az fstab-ot már rég nem szerkesztgetem én sem. Legutoljára valami 1 éve volt, amikor tmpfs ramdrive-ot csiholtam bele, de SSD-re sem adok meg spéci paramétereket.
De van, mikor tényleg szükség van ilyenre, hogy rendszerfájlt kell szerkeszteni, és ilyenkor bizony a kezdők GUI-s megoldásokért nyúlnak. Persze pont ezért szoktuk a terminálos megoldásokat erőltetni, 1) minden disztrón egyformán megy, 2) nem gond a sudo (nincs szükség gksu, pkexec, admin://-vergődésre), persze jön is mindjárt a kritika, hogy túl szakmai, meg xaralinukszmerttermináloznikell, bezzegawindows.
Ez sok DE/WM hiányossága is. Pl. ha a grafikus felület kulturáltan be tudja kérni grafikusan a rendszergazdai jelszót frissítéskezelőnél meg systemctl-es huszárkodásnál, akkor ezt a megoldást általánosan elérhetővé kéne tenni, hogy egy kezdőnek ne ezzel kelljen foglalkozni.
(#67177) ubyegon2: most nem tudom miért kell durcizni. Senki nem mondta, hogy valami rosszat írtál volna. Én viszont úgy érzem, hogy valamivel nem értesz egyet, de nem jön le, hogy mivel.
-
Frawly
veterán
válasz
ubyegon2
#67174
üzenetére
Ezt most nem értem, szerintem akik a témában megnyilatkoztak, egyikük sem írt szakmaiatlanságot, és még azt sem látom, hogy túl szakmaian fogalmazták volna meg a kérdéskört. Elég érthető, informatív válaszok születtek.
Azt az érvedet sem tudom elfogadni, hogy a gksu-t úgyse ismerik a kezdők. Elég baj, mert a sudo-t meg ismerik, abból meg baj lesz. De még mielőtt megismernének más megoldást, veszik is ki a kezükből az alternatívát. Ja, van helyette pkexec, nagyon felhasználóbarát cucc, lehet DISPLAY és XAUTHORITY környezeti változókkal szopni. Meg van az admin://, ami szimpatikusabb ugyan, de egyrészt megint nincs reklámozva normálisan sehol, meg sanszos, hogy csak Ubuntu/Mint alapokon megy, legalábbis nálam Archon nem működik, így gondolom Manjarón is felejtős, meg Fedora-vonalon is.
Mondom, nekem nem az a bajom, hogy valamit lecserélnek, csak az, hogy 1) feleslegesen cserélik, mikor még nincs elavulva, 2) amire cserélik az egyáltalán nem jobb, sőt még rosszabb is, 3) nincs az egész kellő alapossággal dokumentálva.
De ugyanez a bajom a már említett ifconfig esetében. Minden rendszeren ott volt, elég volt neki beküldeni egy ifconfig vagy egy ifconfig -a parancsot. Mindenki ismerte, ráállt a keze több évtized alatt, mindenki happy volt. Most meg lehet km hosszú parancsokat beírni, ip show bla-bla möhöhőő net link interface kisregény lowfax plusz paraméter hóember.
Aztán jegyezd meg az összes paramétert, nekem is állandóan fel kell csapni hozzá a man-t. Ez pont az a fetrengés, ami semmire nem jó, csak kínjukban változtatni dolgokon, csak azért, hogy valami ne legyen állandó. Ezt nálunk vidéken nem fejlődésnek, hanem sz*rkeverésnek nevezik.
-
Frawly
veterán
válasz
ubyegon2
#67171
üzenetére
Ilyesmire biztosan nem gondolt, mert ezt a pkexec-es és admin://-os megoldást én is írtam neki. Egyébként el is fogadom, hogy nála nem megy, de akkor ne így legyen aposztrofálva, hanem írja meg, hogy mi a hibaüzenet.
Sőt, azt már előre kétlem, hogy egyik módszerrel sem menne. Vagy pl. mennek a progik valamelyik módszerrel, csak pont a DE default text editorja ne menne. Minimum furcsa.
-
Frawly
veterán
válasz
growler
#67159
üzenetére
Mi az, hogy a rendszer részét képező grafikus szövegszerkesztőt nem nyitja meg? Mit ír ki?
Eleve nincs olyan, hogy a rendszer részét képező. Gondolom arra gondolsz, hogy default telepítésben érkezik egy olyan grafikus szövegszerkesztő, ami az asztali környezet része.
(#67161) Cifu: ezt elismerem, hogy kellemetlen. Kulturáltabban is megcsinálhatnák. Ha nem szeretsz gépelni, akkor sudo mc-vel másold. Vagy használd terminálban a Tab-billentyűs kiegészítést, nem kell végigírni az elérési utat, nevet, csak az első 1-2 karaktert, utána Tab-ra kiegészíti.
-
Frawly
veterán
Most visszaolvastam, és azt javasolta a kolléga, hogy használja a gksu-t, „ha még van ilyen”. Ebből nekem az jön le, hogy tudatában volt annak, hogy egyes disztrókból kiszedték. Persze nem is veled akarok vitatkozni, mert valóban nem létezik már.
Igazából ezt nem szeretem, amikor valamit kivezetnek, mert elfingják magukat, hogy „deprecated”, közben meg nem volt vele semmi baj. Ugyanez volt nem csak a gksu-nál, de az ifconfig-nál, pedig az ráadásul még el is érhető, csak nem települ a net-tools csomag alapból. Pedig ha valaki, akkor én mellette vagyok a fejlődésnek (64 bit, UEFI, Vulkan, stb.) és a frissességnek, örülök, ha valami elavult dolgot kivezetnek, de ezek ilyen mondvacsinált esetek, a kivezetésükkel nem létező problémát oldanak meg, mivel MÉG nem avultak el, és behoznak szájíz alapján egy olyan dolgokat, amelyek semmivel nem jobbak, de legalább újra kell őket tanulni.
-
Frawly
veterán
Ha valakinek hiányzik a gksu, verje be terminálba ezt a sort:
alias gksu='pkexec env DISPLAY=$DISPLAY XAUTHORITY=$XAUTHORITY'
Ezután használhatja a gksu-t a szokásos módon, semmilyen csomagot nem kell feltenni hozzá.Egy másik módszer, amit újabb linkek javasolnak, pl. gedit-tel egy rendszerfájl szerkesztése:
gedit admin:///etc/fstab
Így az alkalmazás nem rendszergazdaként indul, de a fájlhoz akként fér hozzá. Igaz Ubuntu-ra említik, így valószínű Mint-en is működik, Arch/Fedora-vonalon nem tudom, hogy támogatott-e.Harmadik módszer: nagyobb asztali környezetekben (pl. KDE, Xfce), amelyek támogatják az asztali ikonokat, ott az adott alkalmazásnak csinálni egy új ikont, rá jobb kattintás, tulajdonságok, ott bejelölni valahol, hogy futtatás root-ként. Majd a root-ként indított alkalmazásban megnyitni a kívánt fájlt, vagy elvégezni a műveletet.
Mondjuk nálam ezen a téren megint csak kamatozik, hogy a legtöbb alkalmazásom terminálos (file manager, text editor, package manager, karbantartó scriptek, stb.), amelyik meg nem (qBittorrent, Firefox, stb.), azt meg nem kell soha sudo-val indítani.
De tény, hogy valóban igazságtalan, hogy a gksu-t csak úgy hirtelen kivezették, a felhasználókat meg nem tájékoztatták, hogy mit hogyan használjanak helyette. Így meg azt érték el, hogy nem fognak gksu-t használni, hanem helyette a sokkal rosszabb sudo-t fogják elővenni, vagy rootként jelentkeznek be grafikus felületre (ki lehet hekkelni, alapból nem megengedett a legtöbb login managerben és WM-ben), ami legalább olyan rossz. Ennyi erővel még az is jobb lett volna, ha inkább meghagyják a gksu-t.
-
#67136
Frawly
veterán
szallasi007
#67133
Frawly
veterán
válasz
szallasi007
#67133
üzenetére
Windowson sem egyértelmű a klónozás, ha ilyen RAID-del van bonyolítva!
VMware alatt a nested virtualizációnak mennie kéne, ha tud a proci virtuális extensiont. A legtöbb ma már tud, elég kivételes, ha nem. Viszont a nested virtualizáció nem ajánlott, nagyon szuboptimális lehet vele a teljesítmény.
Ha virtuális gépet akarsz klónozni, akkor elég csak a virtuális gép fájlait lementeni.
-
Frawly
veterán
Az 5 perc homokórázás semmiképp nem írható a Spectre és Meltdown elleni patchek számlájára. Azok csak <10% alatti lassulást okozhatnak átlag felhasználásnál. Plusz ezeket a patcheket ki tudod kapcsolni kernelparaméterekkel:
pti=off nopti nokpti noibrs noibpb noretpoline nospectre_v1 spectre_v2_user=off spectre_v2=off l1tf=off nospec_store_bypass_disable no_stf_barrierAz 5.1-es kerneltől kezdve meg lesz egy általános kapcsoló, ami letiltja az összes ilyen foltot.
Egyébként most Archon én is küzdök lassabb boottal, lassún persze nem az 1-5 perces bootot kell érteni, hanem az UEFI bootmenünél vesztek kb. 2-3 mp-et, a boot többi része lemegy 3 mp. alatt. A systemd-analyze blame azt mutatja, hogy az UEFI firmware-nél telik el az a felesleges idő, de nem tudom mit állítsak, hogy visszanyerjem. Régen ez 0-1 mp. körül volt csak.
A KDE-t, GRUB-ot nem használok, az biztosan nem oka.
-
Frawly
veterán
válasz
CPT.Pirk
#67103
üzenetére
A firmware nem probléma, az van minden disztróhoz, Arch-vonalon a linux-firmware csomagban van benne. De ehhez a kártyához nem elég a firmware, kell külön driver is, mert a kernelben nincs hozzá driver.
Megoldható, de nem kezdős műfaj. Ennek ellenére, ha érdekli, leírom neki lépésenként.
-
-
Frawly
veterán
válasz
#89874944
#67088
üzenetére
Persze, hogy nem látja. A RTL8821-eshez nincs driver a kernelben. A linux header csomagot kell feltenni, le kell tölteni az rtlwifi kódját, és saját kernelmodult kell hozzá forgatni, majd azt használni. Elég szopós móka. Ha érdekel, leírom Mintre lépésenként. Esetleg ha találni hozzá valami külső PPA tárolót, amin már úgy van fent kernelmodulként, hogy le van fordítva. De még ilyenkor is szopás lehet használni, mert ha pl. frissül a kernel, akkor a kernelmodul nem biztos, hogy működni fog tovább.
-
Frawly
veterán
válasz
IO.sys
#67081
üzenetére
Akkor mégse azt csinálod, ami le van írva, az Arrch Wiki-hez képest kihagytál pár lépést.
Az első, ahogy ott is írják, meggyőződsz, hogy egyáltalán látja-e az lspci -v az adott kártyát. Ha látja, akkor az lsmod vagy dmesg segítségével megnézed, hogy van-e hozzá betöltve driver. Ezen a ponton kiderülhet, hogy nincs, mert nincs hozzá driver, vagy a kártyához olyan spéci firmware van, amit nem tartalmaz az Archon egyébként a base részeként automatikusan felkerülő linux-fimware csomag. Nem nagyon fordul ilyen elő, de elméletileg megeshet. Ehhez tudni kéne a kártya pontos típusát.
Ha van hozzá driver is betöltve (Debian Wiki szokta írni, hogy az adott hálókártyához milyen driver való, milyen kernelmodulnak és firmware-nek kéne lennie hozzá betöltve), akkor mész tovább a következő lépésre, „ip a” parancs, megnézed látszik-e az interface, mi a pontos neve. Lehet látszik az, csak nem eth0, ahogy Debianon.
Aztán az is lehet, hogy az interface is jó, csak hálózatkezelő szolgáltatás nem fut, ami DHCP-t hívna. DHCP nem csak ahhoz kell hogy dinamikus címet kapjon, hanem a statikus címhez is be kell konfigurálni.
Szerverre lehet felesleges is a Network Manager, bár azzal a legkönnyebb bekonfigolni mindent (nmtui), és sudo systemctl enable NetworkManager && sudo systemctl start NetworkManager kiadásával indulhat a móka. A netctl kevésbé bloatabb, de azt hegeszteni kell, nyomatod be neki sorban:
sudo nano /etc/netctl/interface-névA fájl tartalma, az IP-ket aktualizáld:
Description='A basic static ethernet connection'
Interface=interface-név
Connection=ethernet
IP=static
Address=('192.168.1.102/24')
Gateway=('192.168.1.1')
DNS=('8.8.8.8' '8.8.4.4')Majd:
sudo netctl enable interface-név
sudo netctl start interface-névAz még egyszerűbb megoldás, ha a statikus IP a router DHCP beállításai között fixálod le az adott MAC cím felé. Így hiába a DHCP-vel lekért cím, a DHCP mindig ugyanazt a címet fogja neki osztani. A dhcpcd-t is kell konfigurálni, ha nincs se Network Manger, se netctl, ilyenkor:
sudo nano /etc/dhcpcd.conf# define static profile
profile static_eth
static ip_address=192.168.1.23/24
static routers=192.168.1.1
static domain_name_servers=192.168.1.1# fallback to static profile on interface-név
interface interface-név
fallback static_ethEgy újraindítás, és a dhcpcd automatikusan indul a systemd-vel, be fogja tölteni az /etc/-ből a konfigot, lefut, beállít, lekér IP-t.
Ez a szép az Archban, sokféle megoldás játszik, egyre minimalistábbak is, egyikhez sem vagy kötve gyárilag (egyedül a systemd-hez). De ha még nagyon új vagy a témában, és máshogy nem sikerül, látszik az interface, jó a driver/firmware, akkor a NetworkManagerrel tutira lehet menni.
-
Frawly
veterán
válasz
IO.sys
#67079
üzenetére
A csomagkezelő kezeli a verziófüggőségeket. Amit írtam, az bizonyos verziófüggőség átugrása a frissítési folyamatban, ez szoros értelemben véve nem is klasszikus verziófüggőség. Ezt, amit példának hoztam, egyik csomagkezelő sem kezeli tudtommal, Debianon az apt sem. Egyedül kiadás alapú disztrókon van egy olyan védelem, hogy frissíteni disztrót csak kiadások között tudsz, inkrementálisan, azaz pl. Debian 7-et nem frissíthetsz azonnal 9-re vagy 10-re, így nincs az, hogy verziót ugranál át. De ez nem a debianosok előrelátása, hanem a kiadás alapú disztrók filozófiájából ered. Rollingon ilyen nincs, eleve mindig is esélyes volt, hogy köztes verziókat ugrálsz át.
Azt meg már írtam, hogy frissítésbiztos OS, vagy úgy általában szoftver NEM létezik. Egyik platformon sem. Mindegy, hogy ingyenes, fizetős, mennyire használ új verziókat, támogatott vagy nem, rolling vagy kiadás alapú, mekkora cég adja ki, mennyire alapos tesztelés után. Mindenben előfordulhatnak frissítési bugok, de még ezeket is jobb bevállalni, mint egy rendszert teljesen elhanyagolni, és nem frissíteni egyáltalán. Hiába a régi, bevált verziók használata, meg az alapos tesztelés, soha semmi nem lehet 100%-ban bugmentes, a frissítés sem.
De ha annyira paranoid van, létezik megoldás. A szerverről csinálsz működő mentést, ennek úgyis kell lennie. Ezt beröffented egy másik vason vagy virtuális gépen, és először frissíted ezt a tesztrendszert. Lehet cifrázni ezt a technikát, hogy tárolóból is sajátot klónozol, amiben csak azok a csomagok lesznek benne, amiket ki is teszteltél előtte a hivatalos tárolókból, majd a szervert már csak erről a saját tárolóból engeded frissíteni. Körülményes, de sok cég csinálja, még Windowson is. Sőt, már az XP-s időkben is láttam ilyen céget, amelyik így csinálta, hogy a rendszerüzemeltetők előbb tesztelték a frissítéseket (pedig akkoriban az XP-s frissítések jóval bugmentesek voltak mint a mostani, hulladék Win10-esek), nem csak azt, hogy rendszerkomponenssel nem akad, de azt is tesztelték, hogy a cégnél használt meg házon belül fejlesztett programoknál nem tör-e el valamit. Majd a tesztelt frissítéseket belső WU szerverre tolták ki, és az egész céges infrastruktúra csak innen frissített. Melós, de biztosra lehet vele menni.
A biztonsági foltokat nem csak a rolling disztrók kapják meg. A kiadás alapúak is elég gyorsan kitolják, ha más nem, régi csomagba visszaportolva.
-
Frawly
veterán
válasz
Rimuru
#67071
üzenetére
Abban igazad van, hogy a v1-v2 és a v1-v4 váltás is eltörhet, de abban nem értek egyet, hogy a kettőnek az esélye pontosan megegyezik.
Pl. a v4 csomag feltételez egy olyan beállítást, konfigfájlt, libet, fájlnevet, amit a v3-as verzió hozott be. De te meg v1-v2-re nyomatod fel, aminél még semmi nyoma nem volt. Pont ez a poén, hogy a csomagfenntartó teszteli a csomagot, de csak úgy, hogy v3-ra telepíti, így nála ez a hiba nem jön ki. Lehet, hogy előrelátó a csomagoló, és teszteli v1-re telepítve is, vagy körültekintőbben csomagolja a fájlokat, kalibrálja a post install scripteket, nem feltételez túl sokat, de ebben sose lehet biztosra menni.
Vagy pl. mikor v1-v2 csomagnak még A-nak hívják a függőségét csomagnév szerint, de aztán ezt átnevezik B-re, amire a v3-as csomag fel is lesz készítve erre. De mikor a v4-eset akarnád telepíteni, az meg csak nézni fog, hogy a B függőség nincs fent, az A-ról meg még hírből sem hallott.
Persze a másik véglet is problémás lehet, mikor valaki 5 percenként frissít. Ilyenkor meg bele lehet futni valami elrontott csomagba, amit amúgy 1-2 nap alatt javítanának, de hamarabb frissítettük. Bár a két véglet között inkább a túl gyakori frissítés a jobbik, mint a túl ritka.
Elvileg erre ki lehetne találni, hogy a csomagkezelő kezelje ezt, és az érintett csomagokat kis lépésekben, inkrementálisan frissítse, azaz az v1-et előbb v3-ra (mert a v2 kihagyható a példánknál), majd a v3-at v4-re, és nem mindjárt a v1-et v4-re. De ez eléggé megbonyolítaná a frissítést, Arch-vonalon nincs is ilyen.
-
Frawly
veterán
válasz
IO.sys
#67063
üzenetére
Össze bármikor bármi összerogyhat. Bármilyen gépen, bármilyen disztró, az LTS-ek is. Garancia nincs semmire. Akkor sem, ha milliókért vesznek a szerverre Windows Server + kliensekhez licencet, az MS sem garantál semmit, nem vállal felelősséget semmiért, persze a zsozsót szívesen felmarkolja, de utána mossák kezeiket.
Nem kötelező frissíteni, de ha nagyon sokáig nem frissítesz:
1) megnő a frissítésből származó hiba lehetősége, mivel több frissítési fázis marad ki, amik hatással lehettek volna egymásra, hiszen a frissítéseket alapvetően úgy tesztelik, hogy az előző csomagverzióra telepítik rá, de ha neked még 3-7-tel azelőtti verzióra települ, előjöhetnek gubancok. Nem azt mondom, hogy gondok fognak jelentkezni, de az esélyét megnöveled így.
2) elveszti az értelmét, hogy rolling disztrót használsz.Emiatt azt javaslom, hogy azért próbálj belőni egy értelmes időt, kb. 2 hónap, esetleg kicsit hosszabb, talán 6 hónapból sem lesz baj. Egzakt válasz nem is létezik rá, hogy milyen hosszú az az idő, ami után már gáz frissíteni. Függ attól is, hogy hány csomag van telepítve, mik azok a csomagok, mennyire gyakran adnak ki hozzájuk frissítést, mi fut a szerveren, mennyi időnként lehet leállítani, mikor megengedett a kiesés. De pl. évente frissíteni rollingnál már neccesnek hangzik, nem azt mondom, hogy baj lenne belőle, de annál én mindenképp gyakrabban frissítenék.
Nem szabad félni a frissítéstől, konzolon egy parancs, gyorsan lemegy. A rollingnak pont az a lényege, hogy egyszerre mindig csak kevés csomag frissül (minél rendszeresebben frissítesz, annál kevesebb csomag egyszerre), szinte észrevétlenül, apránként cserélődnek ki a rendszerkomponensek, nem egy nagy disztrófrissítés van, amikor az összes csomag frissül, és a teljes káosz lehet belőle. Pont ezért, ha rollingon el is törik valami, fogod látni milyen frissítések voltak az utolsóak, és csak 1-2 érintett csomagot kell helyretenni, és nem az egész rendszer áll be, mint a szög, hogy csak nézel, hogy még bootolni sem bootol a kóceráj vagy semmi sem működik. Tekintsd úgy a rollingot, hogy óvatosan, csomagonként tudsz frissíteni, mindig csak 1 lábujjat betenni a hideg vízbe.
Úgy sose szabad semmihez hozzáállni, hogy jajj, el fog törni, nem merek frissíteni, mert azzal teszed összességében a legrosszabbat, hosszú távon annál károsabb nincs, bizonyítja is az eseted, amiből kiindultunk, hogy a túl régi rendszert már nem tudtad rendesen frissíteni. Annál tényleg rosszabb nem létezik, mint hogy bebetonozod magad valami teljesen elavult verzióba, végtelenségig halogatod a frissítést, így a rendszer még ha fut is, egy ponttól csak a szívás lesz vele vagy időzített bomba lesz.
Azok a régi mantrák, amik szerint „Ami nem működik, azt nem kell megjavítani” vagy „az 1000 éves uptime mindenható” már rég nem tarthatók. 10 éve még lehet igaz volt, mikor még az volt egy gyakorlat, hogy 10 évig is ki lehetett húzni egy OS-sel, és a frissítések is kisebb számúak voltak. Ma már viszont annyira jönnek mennek hardveres/szoftveres sérülékenységek, foltok, frissítések, hogy nem lehet addig futni hagyni valamit egy verzión, amíg a vas ki nem rohad alóla, vagyis lehetséges, de elég nagy felelőtlenség.
-
Frawly
veterán
válasz
Slownz
#67053
üzenetére
Ez nekem Firefox bugnak tűnik, ilyet akkor szokott csinálni, ha már össze van kuszálódva FF alatt a profil. Próbáld meg a Firefoxot Safe Mode-ban újraindani (Súgó menü, Firefox indítása addonok nélkül menüpont). Ha úgy jó, akkor hozz létre új Firefox profilt, firefox -P kapcsolóval indítod, ekkor előjön a profilmenedzser, ebben csinálsz új profilt, amit firefox -p profilnév formában írsz meg, ezt átállítod a parancsikonoknál, hogy ez induljon el. De úgy is lehet, hogy a régi profilt törlöd (könyvjelzők, jelszavak, beállítások elvesznek), akkor automatikusan az új profilt fogja betölteni.
-
Frawly
veterán
Egyetértek. A Manjaro konzervatívabb rolling, de nem annyira konzervatív, mint a kiadás alapú disztrók. Illetve nem kötelező naponta frissíteni, 1-2 havonta is elég. Így kevésbé lehet eltörő frissítésbe is belefutni, de az egyébként sem jellemző, hogy előfordulnának ezek.
Nálam sem szokott eltörni semmi, pedig már jó pár hónapja az Archot nem is a stable, hanem a testing tárolókkal használom. Így amondó vagyok, hogy a Manjaro Testinget sem nagy kockázat használni, nem hogy a stable-t.
Igazából ez a rolling nem elég stabil mantra már jó régóta nem igaz. Lehet még pár éve megállta a helyét, de már rég nem.
-
Frawly
veterán
válasz
ubyegon2
#67040
üzenetére
Nem együgyüztem, hanem azt írtam, hogy az együgyű felhasználóknak szoktam én személy szerint ajánlani, mert nekik tényleg esélytelen a Manjaro. Nem azt mondtam, hogy minden mintes együgyű. Bár ha nagyon felhúzol, rádküldöm csixyt, és szépen csinál a gépedre UEFI bootos Archot, és kötelező lesz azt használod. Még inxit is kapsz rá, meg Cinmanót, de a mintes telepítőidet kidobja az ablakon, meg le lesznek húzva a klozetba
Szépen azt fogod használni disztróhopperkedés meg mentázás nélkül. -
-
Frawly
veterán
-
Frawly
veterán
válasz
ubyegon2
#67029
üzenetére
Akkor jó, ha olvasta a hittérítést, mert alapból én is az Arch-vonalat és a Manjaro-t javasoltam volna neki. Megspórolta más a munkát, nem kell hittérítenem.
Én a Mint-et olyanoknak szoktam inkább ajánlani, akkor informatikailag nagyon együgyűek, még a Windowst sem tudták rendesen kezelni, karban tartani, annyira nincsenek képben IT ügyileg. A Mint előnye kétségtelen, hogy a leg-felhaszáló/ kezdőbarátabb disztró, hátránya, hogy LTS-alapú, nem valami friss csomagok. Illetve akkor jó még a Mint, amikor valakinek eléggé nem szabványos hardverkiépítésű gépe van, és a többi disztró futtatása gondokba ütközik, akkor Mint-en jobb eséllyel lehet életre kelteni kezdőként a dolgokat.
Azért arra ne fogadj, hogy régebbi HP üzleti notinál a csomagfrissesség nem számít. Ha pl. Wine-ozik játékok miatt, meg Proton, Vulkan, ilyesmiket akar kipróbálni, ha más nem régebbi játékokkal, legfrisebb Kodi kell, akkor azért jól tud jönni, ha frissek a csomagok. Vagy ha van valami magas DPI-s gamer egere vagy ilyesmi, akkor megint jól jön pl. a friss kernel, friss libinput, stb.. Vagy pl. ha gitről vagy AUR-ból kell valamit forráskódból forgatni (mert nincs az adott progi/verzió benne egy disztró tárolójában sem), akkor megint csak fontos lehet a frissesség. Tudom, azért, mert neked ezek nem fontosak, nem jelenti azt, hogy másoknak sem lehet fontos.
Maradjunk abban, hogy nem jelent sokat, de a distrowatchon a Manjaro top1-es helyezése, meg úgy distrowatch-tól függetlenül az Arch-vonal rendkívüli népszerűsége nem véletlen.
Egyébként annyira kezdtek felhúzni ezzel a HP gépen nem jó az UEFI linuxos boot, hogy ha alkalmam lesz ilyen gép elé ülni, már csak azért felhúzok rá egy UEFI-s Archot. Az nem igaz, hogy nem megy rajta az UEFI boot. Sejtésem szerint a HP az UEFI bootot Windowsos bootx64.EFI fájlhoz drótozta be (ahogy az Aces is szokta az Aspire sorozatnál), a felhasználóbarát modern disztrók meg a GRUB-ot és valami más elnevezésű EFI fájlt erőltetnének, ami meg nem megy. De állítom előttem lenne egy ilyen gép, 30 percen belül megoldanám, hogy bootol, mint a rakéta, UEFI systemd boottal, mindenféle GRUB, shim, meg egyéb baromság nélkül, csak figyelmesen kell az Arch Wiki alapján próbálkozni.
-
Frawly
veterán
válasz
saiyajin
#67025
üzenetére
HP gépeken problémás lehet az UEFI boot. Próbáld Legacy bootra állítani a BIOS-ban és úgy újratelepíteni a Manjaro KDE-t. Egyébként jó disztró, érdemes vele próbálkozni, főleg ha KDE kell. Mintből nincs már KDE kiadás, és ugyan KDE-t fel lehet húzni utólag egy Mint Cinnamonra is, de jobb, ha kezdőként nem ezzel kezdesz el szívni.
-
Frawly
veterán
Nem, nem iktattad ki. A Windows Vezérlőpultban Energiagazdálkodás, ott a A főkapcsoló funkciójának megadása oldalsó résznél felül van a Jelenleg nem elérhető beállítások módosítása, majd ott alul a Leállítási Beállításoknál szürkéből átállíthatóvá válik a Gyors rendszerindítás bekapcsolása (ajánlott) rész alól a pipát ki kell venni. Külön figyelni kell, mert évszakos nagy frissítések vissza szokták sunyi módon kapcsolni!!!
A legacy boot mode-ot lehet kár volt átállítani, elég lett volna a secure bootot kikapcsolni. Bár be lehet kapcsolni a legacy bootot is, de akkor ne kizárólagosan, hanem UEFI + Legacy módban, mert ha Legacy only-n van, akkor meg az UEFI-vel telepített Windows nem fog bootolni.
De ebből is látszik, hogy a linuxos terminál az ilyen GUI-s baromságok helyett mennyivel hatékonyabb, ott ugyan nincs fastboot, de a hasonló beállítások elérhetők egy soros parancs kiadása után is, vagy egy egyértelmű elérési úton lévő konfigfájlban elég egy dokumentált sort ki/átszerkeszteni. Nincs ez, hogy az elrejtett Vezérlőpult, 3. oldalsó menüjének elrejtett részében kell varázsolni, amit ember a talpán, aki megtalálja, főleg, ha nem angol nyelvű rendszert használ. Közben meg terminálos megoldások jórészt nyelv- és disztrófüggetlenek. Meg nincs az, hogy egy frissítés sunyi módon visszacsinálja a beállításokat.
-
Frawly
veterán
Próbálj belépni az UEFI bootmenüjébe induláskor, és nézd meg, hogy a GRUB-os Linux-telepítés egyáltalán listázva van-e. HP gépeken bajos lehet az UEFI.
Az UEFI-be belépéshez azért kell újraindítás nálad, mert be van kapcsolva a Gyorsboot, ezt mindenképp kapcsold ki a Windowsban (Energiagazdálkodásnál), különben zavarni fogja a linuxos dualbootot. Alapból ugyanis a Win8-10 Gyorsindítást vagy mit használ, amivel leállításkor nem állítja le a gépet, hanem félhibernációszerű állapotba küldi le, következő bootkor meg innen állítja fel a rendszert. Normál újraindításnál ilyen nincs. Ki kell kapcsolni, mert félhibernációnál nem csatolja le rendesen az NTFS partíciókat, ami Linux alatt gondot okoz, hibásnak fog látszani rajtuk a szabálytalanul leállított fájlrendszer!
-
Frawly
veterán
válasz
Rimuru
#67015
üzenetére
Jajj, annyi bajod van! De látom te sem tudsz jobbat. A csomagkezelés pont az, amit szeretnék elkerülni, külön plusz munka feleslegesen. A csomagkezelésnek akkor van értelme, ha nem magadnak csinálod a disztrót, hanem azt akarod mások is használják. Nekem ilyen célom nem lesz.
(#67014) Cyrin: Ja, az simán magyar név, csak kicsit nyelvújításos
Én azon röhögök, mikor kiderül, hogy a BP fizetős, de még a support oldal is olyan hozzá, hogy csak BP alól lehet belépni, egyébként ha más OS alól lépsz be, még ilyen 40 ezer forintos éves díjról is küldenek számlát, hogy fizesd be -
#67012
Frawly
veterán
mefistofeles
#67005
Frawly
veterán
válasz
mefistofeles
#67005
üzenetére
Igazad van, a kolléga volt túl érzékeny, és azonnal ugrott a témára. De annyiból megértem, hogy a múltban a BP-esek elég agresszívan reklámozták a disztrójukat, és elég kemény hangnemben fórumoztak több fórumon, ezért ha a BP előjön valahol, azonnal kivált heves reakciókat, akkor is, ha pl. jelen esetben nem provokációnak volt szánva.
Azon túl, hogy a BP nem szimpatikus, ez egyéni szocproblémám, általában sem ajánlok egy ilyen túlmagyarított disztrót. A Linux meg az opensource egy nemzetközi technikai mozgalom, ahogy mindent lemagyarítunk benne (a parancsokat, ilyesmiket), attól a pillanattól kezdve elszeparáljuk magunkat az eredeti ágtól, nem leszünk kompatibilisek az eredetivel, állandóan hekkelni kell a később átvett megoldásokat, ami lemaradáshoz, körülményeskedéshez vezet. Plusz önmagában sem ad hozzá semmit egy disztróhoz az, hogy magyar. Ezért jobban szoktam ajánlani disztrót keresőknek valami nagy, elterjedt nemzetközi desktop disztrót, valami nagyon szabványos csomagkezelővel, amivel a tárolókból sok csomag telepíthető (min. több tízezer), lehetőleg nem túlzottan régi verziók. Ez persze nem zárja ki, hogy egy ilyen rendszert valaki magyarul használjon. De nem csak a BP-nek vagyok ellene szakmai alapon, hanem az összes spéci céldisztrónak, itt nem értették múltkor páran, hogy miért nem ajánlom kezdőknek, hogy Kali, meg egyéb spéci disztrót tegyenek fel desktopnak, annak ellenére, hogy lehetséges pedig így eljárni. Meg ugyanilyen alapon nem favorizálom a Puppyt meg egyéb spéci disztrókat. Ezekkel hosszú távon csak a kínlódás van, ha olyan programot, beállítást akar az ember, ami nem volt benne az eredeti koncepcióban, és ugyan kivitelezhető, de akkora munka, hogy akkor már jobb egy általános disztróból kiindulni.
De pl. ami szimpatikusabb volt, pl. UHU, ott is bebizonyosodott, hogy pont azért nem életképes, mert magyar, kevés ember dolgozik rajta, ritkán vannak kiadások, és csak lemaradása van mindenben, kevés a csomag (nehéz telepíteni azt, ami nincs a tárolókban). Ugyanilyen alapon nem szokott érdekelni, ha egy adott disztró olasz, vagy francia. Sőt, ugyanezért szoktak a független disztrók is elhalni, saját csomagkezelő, saját tároló, kevés csomag, kevés fejlesztő. Míg a Debian, Ubuntu, Arch, Red Hat alap azért népszerű, mert könnyű rá építeni, sok a csomag, kvázi szabványos a csomagkezelés, így ha valaki forkol belőlük saját disztrót, tudja hasznosítani ezt a nagy bázist, van alap, amire építhet, nagy lesz már alapból csomagkínálat, stb..
Ez a saját nemzeti disztró max. csak Ázsiában indokolt, pl. ilyen kínai, arab, japán disztróknál, mert ezeknél a kulturális különbség is nagyon nagy, nem latin vagy nem hangjelelő írás, eltérő írásirány, stb. összejön, amit a nagy általános disztrók nem mindig támogatnak megfelelően. Így ezekből indokolt lehet ilyen ázsiai területre specializált disztrókat csinálni, annak ellenére, hogy ennek továbbra is megvannak azok a negatív hatásai, amiről már írtam, csak ezeknél kiegyensúlyozza egy lényeges előny. Mióta az Unicode mindenféle karaktert támogat már, meg fejlődik az általános disztrókban az ilyen alternatív írásirány, helyi lokalizációs problémák kezelése (pl. glibc-ben a lokalizáció szerinti rendezés), úgy ezeknek is egyre kevesebb értelme lesz.
(#67007) IO.sys: oké, rendben. Ezek szerint csak rosszul jött le, eléggé megkeverted az embereket ezzel a rég nem frissített Debiannal meg a distrowatch alapján disztrót kereső témával.
-
Frawly
veterán
válasz
Rimuru
#67002
üzenetére
De, karban lenne tartva, de csak megadott időpontokon. Nem verziónként csomagokat készítve és azokat telepítve. Hanem mondjuk x. hónap, y. napján kézzel futattva behúzni a forráskódot, azt a részét, amit változott, és újrafordítani azokat a részeket, amik változással érintettek. Tisztában vagyok vele, hogy elég bonyás. Azt nem is állítom, hogy elsőre menne, meg nem lennének vele eleinte megaszívások.
De ha van ilyesmire jobb ötleted, ne kímélj.
-
Frawly
veterán
válasz
Rimuru
#66996
üzenetére
Nem kell annyit karban tartani. Csak akkor kell újraforgatni, ha kedvem támad frissíteni. Inkább ciki, hogy ilyenkor a függőségeket is nekem kéne kezelni, de nem csak csomagonként, de verziónként is. Amúgy a Gentoo is szinte ugyanez. Nem nagy szám mindent forráskódból forgatni, egyedül nagy progiknál hosszú, LibreOffce, Chromium, Wine, komplett DE-k.
(#66997) borix: most lebuktam, szerintem visszamegyek Windowsra. Abból is inkább XP vagy WinME. Azok még OS-ek voltak
-
Frawly
veterán
A Sabayonról érdekelne a véleményed. Pl. egy Antergos, Manjaro, Slax, egyébhez képest hogy tetszik, mennyire gyors, milyen a csomagválaszték, stb..
A Sabayon hiába Gentoo-alapú, bináris disztró, nem kell a működtetésénél a Gentoo-hoz érteni, sem forráskódból forgatni (lehetni lehet, de nem KELL), nem hogy olaszul tudni. De még nem próbáltam ki soha, pedig egy időben szemeztem vele.
Egyébként én személy szerint egyik disztróval sem vagyok teljesen elégedett. Jobb híján az Archnál maradok, de hosszú távon nem zárom ki, hogy csinálok magamnak egy git/dev-ből forgatott friss Linux from Scratch disztrót, rommá optimalizálva. Nem sokkal nehezebb tető alá hozni, mint egy Gentoo-t, és akkor teljes a szabadság, nem kell semmilyen tárolóhoz, disztróhoz, csomagkezelőhöz, emerge-rendszerhez igazodni, meg csomagfenntartókra várni. Elég csak azt forráskódból fordítani és rolling módjára használni, amilyen csomagokat az ember tényleg használ, nem kell csomagkezelő, nem kellenek tárolók, nem kell free/nonfree kérdéskörrel foglalkozni, nincs systemd, meg semmilyen más előírás, meg disztróvezetőségi döntés, igaz pl. a függőségeket viszont ilyenkor kézileg kell kezelni.
Az Arch (abból is a Testing) tényleg csak jobb híján van egy ideje. Az az igazság, hogy lehetne benne több a bináris csomag, meg lehetne az AUR kicsit ellenőrzöttebb, illetve kicsit lanyhulnak a csomagkészítők is, a Fedorában gyakran sok csomag (kernel meg hasonlók) frissebb szokott lenni, ami elég kínos, pedig az csak félrolling disztró. Meg lehetne systemd nélküli. A Gentoo meg bonyás, és szerintem nem ad annyi előnyt, hogy megérje vele szenvedni, ha már ilyenre adja az ember a fejét, jobb akkor már a saját disztró.
-
Frawly
veterán
válasz
kovaax
#66987
üzenetére
A személyeskedést be lehet fejezni, főleg ilyen utalgató leoltogatást, ami minden konkrét ellenérvet mellőz. Igazából az a helyzet, hogy a disztró egy szinten túl mindegy, aki ért hozzá, az mindenből tud normális rendszert építeni, nincs olyan babonákra rászorulva, hogy szerverre csak Debian (meg abból is csak bizonyos verzió), meg csak LTS, meg csak apjakasza mehet. Gondolom jelen esetben még ha céges szerverről is van szó, mivel a topikban kérdezi, ezért gondolom szabad kezet kapott, hogy mit telepítsen rá. Ilyenkor meg lehet kreatívnak lenni, és nem muszáj ősi Voodoo szabályok után menni. Főleg, ha a tanulás, szakmai fejlődés, tanulási hajlandóság is játszik a projektben.
De ugyanez igaz pepitában a fejlesztésre is, egy jó programozónak mindegy, hogy milyen nyelven kell fejleszteni, mivel megvan mindegyikhez a készsége, meg amit még nem is ismer, arra is könnyen továbbképzi magát szakmailag. Általában csak kóklerek szoktak arról vitatkozni fórumokon, hogy miben „kell” fejleszteni, melyik prognyelv „A” nyelv, amit mindenkinek használnia kell, ami a hívők ajánlgatnak, mert az a tuti.
-
Frawly
veterán
válasz
Shyciii
#66980
üzenetére
Így van. Teljesen egyetértek. Ha el is törik egy frissítés Arch alatt, az
1) nagyon ritkán fordul elő
2) ha nem frissít valaki 5 percenként, hanem mondjuk 1-2 hetente, akkor belefutni is nehéz, mert gyorsan javítják
3) helyrehozni is könnyű, mert lehet downgrade-elni egy előző csomagverzióra
4) egyébként downgrade nélkül is könnyű megoldani, mert általában kézzel is javítható elég könnyen az esetek többségében egy fájl vagy symlink törlésével vagy egy config fájl szerkesztésével, a pacman meg az Arch weboldala szokta is rá a megoldást írni, általában nem kell hozzá agysebésznek vagy gurunak lenni
5) okozhat ugyan elméletileg valami jelentősebb, komolyabb problémát is, de az meg annyira ultraritka, hogy ilyen nem rolling disztrón is előfordulhat ennyi erővel, nem Arch-specifikus. Tényleg inkább elméleti eset akármelyik disztrón.De abban meg Ubyval értek egyet, hogy aki kezdő topikban keres Distrowatch-helyezés alapján disztrót, annak az Arch lehet nem a legjobb választás. Az Arch alapot a Manjaróban is meg lehet kapni, sokkal felhasználóbarátabb formában. A Distrowatch fetisisztáknak külön jó hír, hogy a Manjaro ráadásul 1. helyezett a listán, nem mintha sokat jelentene. Nyugodtam mehet fel szerverre is, arra a Manjaro Architect-et érdemes telepíteni, ami lényegében Manjaro Minimal Install, grafikus felület meg mindenféle sallang nélkül, megfelel az Ubuntu netinstallnak, Debian minimal/netinstallnak. Esetleg a legutóbbi LTS Ubuntu Server sem elvetendő ötlet, sok doksi elérhető hozzá.
Azzal is egyetértek, hogy a Debian 10 sem a legjobb választás jelen esetben Arch helyett, megint csak azért, mert nem kezdőknek való, a CentOS-t ugyanezen okból nem ajánlom. De magával a Debian 10-zel nincs probléma, igaz, hogy véglegesen még nem jött ki, de elég sok embertől olvastam, akik tesztelik, hogy semmi problémájuk nincs vele, ugyanolyan stabil és használható, mint a 9-es. Nemsokára megjelenik a 10-es, és most is elég érett állapotban van, felesleges tőle tartani, csak azért, mert még nincs „stable” státuszúvá minősítve hivatalosan. Nyugodtan fel lehet tenni, nem fog kimenni a Bétaüldözési Királyi Rendőrség, rárúgni valakire az ajtót, mert nem a stable ágat telepítette. Ha szerver, ha nem. Pláne szerveren nem ügy, ahol nincs X, nincs NV driver, meg ilyen extrák, eltörni amúgy is ezek szoktak. Meg szerveren a hardver is ritkán olyan friss, hogy gond legyen melyik kernelt, stb. használja az ember.
-
Frawly
veterán
válasz
Rimuru
#66971
üzenetére
Vállalati környezetben is simán mehet klasszikus x86 szerverfeladatokra az Arch Debian helyett. Minden a cég hozzáállásán és a szakembergárdán múlik. Meg azzal is, hogy mivel foglalkozik, pl. egyes területeken, egyes megrendelők előírnak minőségbiztosítási követelményeket, meg MS infrastruktúra meglétét, és ilyenkor nem hogy az Arch nem játszik, de még a Debian sem.
Tény egyébként, hogy a cégeknél valóban szeretik a hosszabban supportált dolgokat, meg ha valaki extra supportot nyújt (pl. Red Hat, SUSE). Bár ez is főként beidegződés sajnos, általában egy bizonyos ősi verzióba bebetonozódás szokott lenni a vége. Többek között a müncheni történetnek is ez lett a veszte, volt városi szinten linuxozás, valami külső cég által supportált, 100 éves Ubuntu 10 rendszer, meg valami dinoszauruszok korabeli OpenOffice.org (mikor már máshol évek óta a LibreOffice legújabb verzió mentek), és ez a hozzáállás egy idő után tarthatatlan lett, nem tudták vele az üzemeltetők a lépést tartani. Nem kellett hozzá 10 év sem, hogy bukjon az egész. Ilyen hozzáállással jobb is, ha windowsozik inkább valaki. Bár Windowson is lehetnek dolgok, amikor a MS kitalálja, hogy újabb CPU-n csak az utolsó Win verzió kap frissítést, meg az adott LTBS Windows támogatása lejár, stb., akkor is nagyon szokott menni a vergődés. Ne felejtsük, hogy már a Win10 is rolling.
Meg még mindig tartom, hogy egy évek óta hanyagolt szerver nem vall komoly felhasználási területre, cégre.
-
Frawly
veterán
válasz
ubyegon2
#66969
üzenetére
Hát jobb is, ha visszavonulsz, ma nagyon kötekedő kedvedben vagy, ráadásul konkrétumokat sem írsz. A szuperszámítógépeket kár is volt felhozni, általában nem Debian fut rajtuk, de nem is Arch, nem általános disztró, hanem saját kernel, saját megoldás van felreszelve rá. Már csak sima disztrót azért sem lehet felhúzni rá, mert az architektúra olyan szokott lenni, hogy nem is menne.
A szerver meg nem is feltétlenül különleges, mint azt gondolod. Nem azt mondom, hogy nem kell érteni hozzá, de nem nehezebb, mint egy normális deszktopot elemenként felépíteni, csak más elemekből áll. Lehet te azt hiszed, hogy milyen nagy ügy, de nem az. Persze szerver és szerver között is óriási különbség van, szerver pl. Win Pisti médialejtászó szervere is otthon, meg a NAS-a, routere, de pl. szerver egy webfejlesztő otthoni LAMP cucca is, esetleg egy Rasp. Pi. Vagy egy céges DNS vagy LDAP szerver. Meg a felhőben futó virtuális szerver és az a földrajzilag is szétosztott, kluszterezett szerverfarm is, amit a nagyok üzemeltetnek, pl. a Google. Ezek mind más műfaj, más méretek, másfajta terhelés, pedig mind szerver. Én alapvetően az otthoni és kis céges x86_64-es szerverekről írtam, amiken csak 1-1 klasszikus szolgáltatás fut, http szerver, FTP, valami médialejátszó cucc, és nem csatlakoznak rá milliószám.
A szerver egy elég sokmindent felölelő terület, ahogy a fejlesztés is. Pl. a szervernél a hálózati témához is érteni kell, meg ahhoz a konkrét szolgáltatáshoz, amit futtatsz rajta. Pl. egy mezei http szerver nem hozna zavarba, egy pl. egy asterixes teló/faxszerverhez hozzá sem tudnék szagolni, mert sose volt dolgom olyannal, de még csak az ilyen telekomos dolgokhoz sem értek.
De épp így a desktop is nagyon különböző, ezért is van ennyi disztró. Ahány hardver (erősebb, gyengébb, újabb, régebbi), ahány felhasználási terület (böngészés, kreatív tartalomgyártás, játékok, mérnöki CAD/workstation feladat), ahányféle felhasználó (kezdőbb, haladóbb, GUI-csilivili mániás vs. terminalgeek poweruser) annyiféle igény, disztró. Ami jó az egyik területre, nem feltétlenül legjobb a másikra. Kezdő általánosabb feladatokra jobban jár, ha valami általános disztróval kezd, nem Ubuntu Studio, meg LibreElec, meg SteamOS, Kali, Scientific Linux, Clear Linux, stb.. Ezeken is megoldható minden, csak egy kezdő nem fog vele boldogulni.
Ugyanígy a Windowsnak is megvan a felhasználási köre, játékok, MS only infrastruktúra, ugyebár próbáljon csak valami Sharepointot üzemeltetni Linux szerveren. Bár ki tudja mit hoz a jövő, mióta MSSQL, Mono is van Linuxra, meg Wine DXVK/Proton, aztán ott a Linux Subsystem for Linux, nemsokára jön a Chrome-alapú Edge, stb.. Már eleve az Adobe kreatív alkalmazások sem Windows only, van Mac-re is.
-
Frawly
veterán
válasz
Frawly
#66967
üzenetére
Illetve ha már Debian, akkor ne 9-esre frissüljön, hanem mivel úgyis újratelepítés lesz, szépen menjen fel a 10-es. Azzal megint lelesz a gond jó hosszú időre, annak ellenére, hogy ez a fajta hozzáállást nem támogatom.
Már rég nem menő az, ha egy szerverhez 10-15 évig nem nyúlnak hozzá, akkora uptime-mal fut. Ma már ezzel sok sérülékenységgel, biztonsági réssel sokkal összetettebb lett a világ. A fejlesztés üteme, módszertana is sokat változott a fejlesztőcégeknél. Lehet róla vitatkozni, hogy a rosszabbik irányba fejlődtünk vissza, mindenki ontja a bugos szoftvert és nyomatja rá ész nélkül a frissítést (agilis módszertan = kapkodás, erőltetett fejlesztési ütem), de az tény, hogy ezt éljük most, ehhez kell alkalmazkodni. Ehhez viszont a rolling alkalmazkodik a legjobban, ha tetszik, ha nem, teljesen mindegy kinek mi a hitvallása.
-
Frawly
veterán
válasz
ubyegon2
#66965
üzenetére
A legtöbb helyen általában licencspórolás miatt használnak szerveren Linuxot. És ők általában csak a Debiant ismerik, meg arról hallották, hogy szerverre való. Illetve van, aki pont a konzervativizmus miatt választ Debiant, CentOS-t, vagy valami olyan egzotikus CPU architektúrát használ, amit csak a Debian-féle disztrók támogatnak, míg pl. Arch csak x86_64-re van és kifújt (van Arch32 is, de az meg csak x86-ra), és ez kínos tud lenni, egy ARM-es, PowerPC-s vagy MIPS szerveren. De ez nem azt jelenti, hogy csak ezekkel lehet használni mindenkinek, a legtöbb szerver meg általában x86_64-es. Ha csak azt néznénk, mi hol fut szignifikikáns mennyiségben, akkor az jönni ki, hogy csak a Windows használható, így statisztikákkal értelmetlen jönni.
Igazából pont a szerver az, amire mindegy mit tesz az ember. Mehet rá Arch, mehet rá Clear Linux, Fedora/Ubuntu Server is. Akár még valami BSD is hardverkiépítéstől függően. Csak nagyon speciális szervernél tudom elképzelni, hogy a disztró számítson, pl. valami médiás felhasználási terület, vagy valami embedded mikroszerver. Aki ért hozzá, annak azért mindegy mit tesz rá, úgyis mindennel fog boldogulni (akkor is, ha valami frissítés eltörne, meg tudja oldani), aki meg nem ért hozzá, megint mindegy, hogy Debiant tesz rá vagy mást, csak kudarcot kudarcra fog halmozni.
Illetve a Debiant, CentOS-t a lustaság is motiválja sokszor, felteszik, megy, évekig nem nyúlnak hozzá. Persze ez felelőtlenség, és visszaüt. Na meg nem kezdő topikba való téma.
-
Frawly
veterán
válasz
ubyegon2
#66959
üzenetére
Akkor tőlem nevess fel. Azt meg végképp nem tudom, hogy mi tiltja meg, hogy szerverre Archot telepítsen akárki is. Megy a Debian rendőrség és legumibotozza? Tudom, biztos fontos in production szerver lehet, azért volt ennyi évig hanyagolva, hogy még mindig csak Debian 7 volt rajta. Ja, mert az Arch biztos eltörik rajta. Oh, wait, a Debian is eltört frissítés miatt. Akkor meg maradt egyéb kérdés? Archon, ha valami el is tört volna, maximum azt az 1-2 csomag érintette volna csak, és nem lett volna az egész rendszer használhatatlan.
Az meg hogy valami szerver vagy nem, teljesen mindegy. Annyi a különbség, hogy szerverre nem tesznek grafikus felületet, meg általában nem helyben, hanem SSH konzolban matatják. Ámbár fel lehet akár még rakni rá desktop disztrót is, csak értelme nincs sok, a feleslegesen futó DE/WM csak egy plusz dolog lesz, ami eszi az erőforrásokat és eltörhet, de a mai hardvereknek ez már elég kicsi overhead, meg a mai modern disztróknál elég kicsi kockázat, inkább csak a feleslegessége miatt nem ajánlom. Aki komolyan akar ilyennel foglalkozni, tanulja meg szépen a konzol, terminál használatát, annál az oknál fogva, hogy univerzálisabb megoldás.
-
Frawly
veterán
válasz
Shyciii
#66955
üzenetére
Mondjuk ha egy rendszer 100 éve volt utoljára frissítve, akkor az Arch alatt is problémás lesz. De valóban, ezért jó a rolling, azt rendszeresen lehet frissíteni, nem csak kiadásonként, és általában fájdalommentes. Nagyon ritkán van gond, általában arra is egyszerű a megoldás, amit a pacman és az archlinux.org hírszekciójában is le szoktak írni, pl. egy fájl törlése, vagy symlink létrehozása, vagy egy fent lévő csomag eltávolítása majd újratelepítése, stb.. Sokkal kevesebb eséllyel törik el a frissítés rollingnál, mint egy kiadás alapú disztrónál kiadások közötti frissítésnél. Rollingnál mindig csak pár csomag frissül, nincs nagy verzióugrás egyszerre, nem frissül túl sok minden. Kiadás alapúságnál meg inkább sikertelen szokott lenni, mint sikeres, a statisztika azt mutatja, mivel itt nagy ugrás történik csomagverziókban, meg szinte minden csomag egyszerre frissül.
-
Frawly
veterán
válasz
Laszlo733
#66907
üzenetére
A partíció átmozgatása alatt azt értjük, hogy a zsugorítás után létrejött üres helyre kihúzod a következő partíció elejét, de mindjárt utána a végét is annyival visszahúzod, így a mérete nem változik. Ugyanezt eljátszod a következő partícióval is.
De nem ajánlom, elég bonyás ez így, meg sokáig is tart HDD-nél. Inkább telepítsd újra a Linuxot.
(#66903) cigam: ez a fix /dev/sdc valami disztróba hekkelt spéci udev szabály miatt lehet. Még nem láttam ilyet.
-
Frawly
veterán
válasz
Laszlo733
#66891
üzenetére
Adatvesztésnek egyáltalán nem kéne lennie. Zsugorításkor a létrejött üres helyre át ki tudod húzni az utána lévő partíció elejét, egérrel vonszolva a partíció elejét jelképező függőleges vonalat. Bár azt nem látom, hogy az a /dev/sda6 az mi a rák, nem a root partíció, mert az az sda7. Talán a /home partíció? Vagy valami megosztott NTFS partíció?
Előbb el kéne döntened hogy milyen partíciókat akarsz pontosan. Ha még nincs belakva ez a Linux rendszer, én inkább újratelepíteném a Windows partíció zsugorítása után, normálisan vagy 1 partícióra a root, boot, home, vagy külön partíciókra. Bár azt sem látom, hogy ez milyen disztró pontosan. Annyi látszik, hogy EFI partícióról bootol, akkor külön /boot partíció nem is kell, lehet a meglévő EFI partíciót használni /boot-nak. De az egészet nem lehet így átlátni egyetlen screenshot alapján. Ez most jelen állapotában jól szét van kutyulva sda1-tól sda99-ig.
Ökölszabálynak: rootnak elég 50 giga, bootnak 200-500 mega (de ez nálad meg is van az 500 megás EFI partíció személyében), /home-nak a fennmaradó egész lemezterület. Vagy lehet egyben egyetlen partíció is. Swap partíció nem kell, lehet helyette swap fájlt használni.
-
#66881
Frawly
veterán
Plasticbomb
#66880
Frawly
veterán
válasz
Plasticbomb
#66880
üzenetére
A Clear Linuxról érdekelne majd a tapasztalatod, pl. mennyivel gyorsabb a Fodoránál. Direkt írok tapasztalatot és nem benchmark adatokat. Még nem próbáltam ki, pedig régóta tervben van véve. Elvileg csak az a specialitása, hogy a fontosabb csomagok optimalizálva vannak, ezért állítólag piszok gyors, legalábbis a phoronix.com-os tesztek szerint, amiknek viszont azóta nem hiszek, mióta az f2fs-t is a leggyorsabbnak hozták ki, közben meg tapasztalatom szerint az ext4-nél jóval lassabb.
Megint mások nem ajánlják a Clear Linuxot, mivel állítólag kevés csomag van hozzá, ezért azt mondják, hogy desktop felhasználásra nem alkalmas.
Intel projekt, de megy Ryzenen is. Annyi, hogy újabb proci kell neki, az újabban azt értve, hogy 2012-es és újabb főként, SSE 4.1, AES, stb.-t kell támogatnia, szóval annyira nem kell újnak lennie, csak ilyen C2D meg P4 és hasonló régiségeken kell elfelejteni. Ez amiatt van, hogy ezekre az utasításkészletekre van optimalizálva.
-
#66872
Frawly
veterán
Plasticbomb
#66868
Frawly
veterán
válasz
Plasticbomb
#66868
üzenetére
Nem értem, az 5-ös kernelnek kéne tudnia kezelnie azokat a hardvereket, amiket írtál. A 2. genes Ryzent és a Vega64-et is.
A nomodeset-et jól érted, az a kerneldrivert tiltja le.
(#66863) zoltanz: elég hozzá kézi mounttal felcsatolni, az a default mount paraméterekkel csatolja. Az fstab-ban sem kell megadni paramétert, és akkor defaultként csatolja fel. A chown nem igényel semmilyen speciális beállítást, normál felcsatolást, azt követően meg sudo chown korlátozottfelhasználói_név /csatolási/pont -R, és az egész a tulajdonodba kerül, tudsz rá írni.
-
Frawly
veterán
válasz
Fecogame
#66856
üzenetére
Erre sajnos nincs megoldás. Nem csak Putty-ban, de egyik terminálemulátorban, konzolban sem. Max. csak a vágólapkezelő oldaláról tudom elképzelni, hogy spéci programmal a többsoros vágólapnak eldobja az összes többi sorát, és csak az elsőt tartja meg.
Ebbe a hibába én is beleesek. Nem csak több sornál, de egy sornál is gond, hogy ha „belevágom” a sor végén az újsor karaktert, akkor beillesztve terminálba azt az egy sort, a végén az újsor miatt végre is hajtódik, mintha Entert nyomtam volna, pedig futtatás előtt át akartam szerkeszteni.
Na, ezért sem jó egérrel kijelölni. De pl. böngészőben nincs nagyon más mód rá, van a Firefoxban ugyan egy nyomi mód (F7-re jön elő a caret mode), amiben szöveget billentyűzettel lehet kijelölni, de az is elég haszontalan és nehézkes.
A stackexchange-en hadoválnak még bizonyos bracket módot tudó terminálokról, de az is eléggé ilyen adjuk a x4rnak egy pofont jellegű félmegoldás.
Ha valaki mégis tud erre megoldást, az engem is nagyon érdekelne. Ezzel haladók is szívnak, nem csak kezdők.
-
Frawly
veterán
válasz
Shyciii
#66852
üzenetére
De minek az gnome-disks? Főleg egy perzisztens live rendszerre?
Sokkal jobb helyette a dd/cfdisk/mkfs.akármicsoda kombó terminálban. A gnome-disks egy bugos hulladék meg bloat is. Ugyanezen okból nem szeretem a GParted-et is, szép csilivili felület, de pl. már a particionálásnál is mocsok lassú. Az amivel elszüttyög percekig, megcsinálom terminálban néhány másodperc alatt úgy, hogy még gépelek is közben. A GParted-nek max. csak úgy tudom elképzelni a létjogosultságát, ha valaki partíciót méretez át vele, és azt akarja, hogy megmaradjanak rajta az adatok. De ez is elég ritka kell hogy legyen, egyszer kell valamit normálisan megparticionálni, utána nem kell az életben hozzányúlni. Ha meg csak ilyen pendrive, amire rendszerek jönnek, mennek, ott meg nem cél, hogy a partíciót átméretezzük, hanem elég mindig újraparticionálni és nem baj, ha elveszik róla minden.
-
Frawly
veterán
válasz
Rimuru
#66812
üzenetére
Igaz, valóban pongyolán fogalmaztam. Én is láttam már olyan pendrive-ot, amin volt ilyen hardveres kapcsoló. De amit írtam, azt normál pendrive-ra értettem, ami előtte nem volt írásvédett, nincs rajta ilyen hardveres trükk, és egyszer csak írásvédettnek látszik. Illetve ilyen írásvédettség akkor szokott még előfordulni, ha bedöglik a pendrive, de akkor meg nem lehet rajta szoftveresen segíteni.
Igazából a dd annyira low level szinten írja az eszközt, hogy nem érdekli semmilyen partíció, titkosítás, LVM, RAID, fájlrendszer, jogosultság, írásvédelem, csatolás. Ha nem hardverhibás az eszköz, és nincs valami hardveres tiltás, felülír bármit. Nem érdekli, hogy mountolva van-e, nem érdekli, hogy rendszer fut-e éppen róla. Viszi az egészet, mint Kamaz a kereszteződésben.
Épp ezért kell nagy körültekintés, amikor az ember dd-vel vitézkedik, kétszer is megnézni az if, of paramétereket, lsblk-val háromszor is ellenőrizni, hogy tényleg arról van-e szó. Még egészen tapasztalt linuxos, unixos veteránok is beszopják, hogy nyomják a dd of=/dev/sdb-t, mert az „szokott lenni” a pendrive, csak azt hamarabb dugták be, boot előtt, így az lett a /dev/sda, a rendszer meg kivételesen /dev/sdb-re csúszott át, és máris megy a levesbe az egész rendszer.
-
Frawly
veterán
válasz
s1999xx
#66804
üzenetére
Egyetértek, írásvédett pendrive nincs. Gondolom valami olyan mappa van rajta, amihez nincs jogosultsága a korlátozott (nem rendszergazdai) felhasználónak. Nincs problem, dd-t kell ráereszteni, az törli róla a fájlrendszert, partíciókat. Vagy lehet elég mkfs-sel újraformázni, az is megszünteti ezt. Esetleg még elegánsabb a meghajtón lévő mappákat saját tulajdonba venni chown-nal.
-
Frawly
veterán
válasz
Frawly
#66809
üzenetére
Már nem tudom szerkeszteni: az egész trimezés elég 1-2 hetente átlag felhasználás mellett. Nem véletlen, hogy Ubuntun, és Ubuntu alapú disztrókon is default 1 hetente fut le az fstrim.service. Annál sűrűbben trimezni csak felesleges időpocsékolás, meg pótcselekvés. Kivéve, ha extrém felhasználás alatt van az SSD, minden nap ilyen 100 GB feletti írást, törlést csapatsz le rá, de az meg ritka felhasználási módozat. Normál desktop felhasználásnál elég az TRIM 1-2 hetente.
-
Frawly
veterán
válasz
#68216320
#66776
üzenetére
Samsung 850-nél érdemes a default fstrim-et használni. Működik a discard is, ha beteszed a /etc/fstab-ba, de a Linux kernelben az queued TRIM funkciónál feketelistázva vannak a Samsung 8XX-ek, tehát nem csak a 850, 860, hanem a 840, 830 is. Ez meg azt jelenti, hogy discard TRIM-nél a kernel azonnal kikényszeríti a kernel a TRIM végrehajtását, ez meg okozhat egy kis belassulást, ámbár nem nagyobbat, mint egy ütemezett fstrim (ami szintén azonnal végrehajtódik). Szóval nem kell ettől félni, használd azt a megoldást, ami szimpatikus. Kipróbálhatod mindkettőt, használd pár hónapig default fstrim-mel, aztán pár hónapig /etc/fstab-ba betett discard opcióval (fstrim-et kikapcsolva), meg fogod látni, hogy neked melyik a gyorsabb, kényelmesebb, kevésbé zavaróbb.
swap partíciót gyárilag csak discard TRIM-mel lehet trimezni. Bár gyakorlatilag meg lehetne rá egy Bash scriptet írni, ami kézzel hívogatsz, és az lecsatolja a swap partíciót, majd blkdiscard-dal végigtrimezi, ami után mkswap-pal újraformázza, és újra visszacsatolja, az egész nem vesz igénybe néhány mp.-et, és nem kell minden órában futtatni, 1-2 hetente elég.
Nekem nincs swapom, és fstrim-et használok, de kézileg, tehát még a fstrim systemd service sincs beütemezve x időkénti automatikus lefutásra, hanem egy saját scriptet írtam, ami kiírja a gépben lévő SSD-k SMART adatait, meg hogy a jelenlegi írástempóval mikor érem el rajtuk a TBW limitet, és végigfuttat rajtuk fstrim -a -v parancsot. Azaz kézileg trimezem őket, nem futtatom naponta, 1-2 hetente, amikor kedven szottyan rendszert karbantartani. Csak rátaposok ilyenkor a Win+X billentyűkombóra (erre drótoztam be), az megnyit egy terminálablakot, bekéri a sudo jelszót, és már nyomatja is le a dolgokat.
A lényeg csak úgyis az, hogy néha napján legyen TRIM futattva az SSD-n, és ne az legyen, amit az XP-sek szoktak csinálni, hogy évekig nem lát az SSD semmilyen TRIM-et, anélkül van használva.
Swap partíció helyett jó a swap fájl is. Annak az az előnye, hogy rugalmasan állíthatod be a méretét. Ha érzed, hogy túl nagy, nem használod ki, swapoff-fal lecsatolod, törlöd, azonos néven létrehozol helyette egy kisebbet, mkswap-pal formázod, swapon-nal (vagy reboottal) visszacsatolod, ez is csak pár másodperc. A TRIM-elése viszont hátrányos, mert trimezhetetlen lesz a swapfájl ki nem használt része, bár erre is ott van ugyanaz a technika, amit írtam, csinálsz erre scriptet, ami néha napján lecsatolja, törli a swap fájlt, fstrim-ezi a partíciót, amin rajta van, majd újrakreálja, formázza, visszacsatolja, egy 5 soros scripttel megoldható.
A swap partíció ezzel szemben discard paraméterrel könnyebben trimezhető, viszont ha a disztró túl nagyot, vagy túl kicsit hozott létre, nem jó az igényeidnek, akkor sokkal szopósabb átméretezni.
-
Frawly
veterán
Ez a másik előnye a rollingnak, nincs kiadások közötti upgrade, nincsenek elvesző beállítások, nincsen félévenkénti újratelepítés. Kívéve nálam
Simán újratelepítgetem időnként az Archot, de az én helyzetem speciális, szeretek új dolgokkal kísérletezni, meg egyre minimalistább rendszert építeni. Értsd ezen azt, hogy amikor újrahúzom, teljesen más rendszert építek, mintha más rendszert használnék és disztrót váltottam volna. Általában más grafikus felület, más alkalmazások, más megoldások. Kivéve most, mert ugyanaz a Sway WM került vissza, ugyanazokkal a terminálos alkalmazásokkal zömében, de már így is volt változás, Keepassx2 helyett kpcli került fel, netctl/wicd helyett saját WiFi-inicalizáló megoldás lesz, stb.. Tehát mindig eltér a telepített rendszer a korábbitól. -
Frawly
veterán
válasz
leviske
#66744
üzenetére
Annyira van biztonságos, mint egy nem működő, nem bootoló gép. Veszteni való nincs, meg kell próbálni. Valóban lehet az a PPA, amit írtál, az ukuu (eredeti óklingonban Ubuntu Kernel Update Utility) is ilyen külső tárolókról szedi az új kerneleket. Az 5.1 RC1 nem fontos, lehet 5.0.3 stable is, az is vadonat új, lényegében az 5.1 RC feauture-ei vannak backportolva az 5.0-ás ágba.
A rolling disztró viszont azért lenne ajánlottabb ennyire modern gépre, mert azon nem csak a kernel, hanem minden nagyon friss, mesa, Steam, Wine, stb.. Ubuntun állandóan lehet fetrengeni, hogy most kernelből kell frissebb, majd a mesa lesz neki régi, de akkor meg ebből is meg amabból is újabb kell. Sokan nem hiszik el nekem, de nem éri meg ezzel szenvedni. Nem instabilabb semmivel egy Manjaro, Arch sem egy ukuu-val reszelt, agyon PPA-zott, szénné hekkelt Ubuntu-vonalas disztrónál.
Szerk.: ja, látom, hogy félreértettél minket. Nem téged akarunk rollingra átállítani, hanem a kolléga felmerült bootképtelenségi problémáját megoldani. Ő tegnap telepítette a rendszert, nem lakott be semmit. De ez a belakás is nagyon relatív, vasárnap éjszaka tettem fel egy Archot, nem egészen 2 nap alatt be van lakva, meg lagzilajcsizva. Ennyit a belakott rendszer szentségéről. Igaz a /home megmaradt, meg a /boot is, ey csomó minden vissza van húzva config fájlokból. Ha nincs bajod a géppel, akkor valóban, elvi alapon felesleges váltani. De ha mondjuk újratelepíted egyszer a rendszert, akkor adhatsz esélyt az Arch/Manjaro-vonalnak.
-
Frawly
veterán
Akkor a profil kilőve, csak ötlet volt. Próbáld meg Safe Mode-ban indítani, Help menü - Restart with Addons disabled - Safe Mode. Ez letiltja az addonokat és reseteli a beállításokat, de csak ideiglenesen, egy futás erejéig. Így ki lehet deríteni, ha addon okozza az anomáliát.
De amit betettél képet, azt GPU driver, kompozitorprobléma is okozhatja.
-
Frawly
veterán
Ez simán lehet Linuxtól függetlenül a Firefox nyűgje is, ilyen furcsaságokat Windows alatt is csinál. Megfigyelésem szerint ennek az az oka, hogy egy idő után a profil összekuszálódik benne, ilyenkor csak létre kell hozni egy másik profilt és azzal kell használni. Persze ilyenkor az egész FF állítgatását újra kell kezdeni, könyvjelzőket, stb.-ket visszahúzni, újra beállítgatni mindent, addonokat újra feltenni. De az addonokat egyesével, óvatosan, mert azok is okozhatnak furcsa hibákat.
-
Frawly
veterán
válasz
#20584850
#66708
üzenetére
Az első sorra mit ír a systemctl?
Milyen SSD ez pontosan? Gyártó, modell? Mintből pontosan melyik verzió?
A swap-ra akkor kell csak TRIM, ha külön partíció. Ha csak swapfájl, akkor annak a fájlrendszernek a TRIM-je gondoskodik róla, amelyiken van.
Swap partíciónál discard opció kell a /etc/fstab-ba, azt az fstrim nem kezeli.
-
Frawly
veterán
válasz
Frawly
#66704
üzenetére
Idővel el fogom hagyni ezeknek a bloat progiknak a zömét. qBittorrent helyett rtorrent lesz újra, lehet valami webes interface-szel, Goldendict helyett saját szótárazó scriptet fejlesztek idővel, Gimp helyett keresek valami kisebb képmanipulálót (végül is csak vágásra, átméretezésre, RGB színek azonosítására kell, illetve régen ebben szkenneltem XSane Gimp Pluginnel, de arra már nincs szükségem). A LibreOffice, TeXlive, Chromium, Wine megkerülhetetlen marad sajnos, az első kettőre ritkán van szükség, de előfordul, a Chromium (Firefox mellé tesztelni, meg második munkamenetet tartani benne szeparációból), Wine viszont gyakran kell (szótárprogikhoz, játékokhoz)
A Wine-vel külön bajom, hogy multilib, az még hagyján, hogy sok függőséget behúz, de miért kell 32 bitesnek lennie? Egyszerűen agyrém. A 64 bites bináris is tudna 32 bites Windows-környezetet emulálni. -
Frawly
veterán
válasz
#20584850
#66703
üzenetére
Elvileg Minten nem discard-ot kell használni az /etc/fstab fájlban (bár lehet azt is), hanem gyárilag az fstrim és fstrim.timer systemd service-eket kéne használnia alapból, ezt ellenőrizheted terminálban:
sudo systemctl status fstrim
sudo systemctl status fstrim.timerA két lehetőség alternatív, ha használod a discard-ot az /etc/fstab-ban (az mindegy hová kerül az opciókon belülről, előre vagy hátra), akkor nincs szükség fstrim-re. A noatime-ra nincs szükség semmiképp. Szerepeltetheted, bajt nem csinál igazából (elméleti esetben 1-2 progi hiányolhatja, de ilyenbe nem futottam bele), de nem kímél sokat az SSD-n.
Vagy fordítva, ha a default fstrim-et használod, akkor nem kell ez a /etc/fstab discard-os állítgatás, hiába írja a linuxmintes cikk, hogy kell, nem kell. Mindkettő ugyanazt a TRIM-et hajtja végre, csak más ütemezéssel, az egyik használata feleslegessé teszi a másikat.
Az SSD típusának függvénye is. Pl. Samsung 8XX-es sorozatnál az fstrim-et jobb használni, mivel a fekete listás NCQ TRIM-es SSD-k között szerepel a kernelben, de a legtöbb SSD-nél mindegy. Ki miben hisz alapon lehet választani.
Továbbá nem kell TRIM-mel foglalkozni NVMe SSD esetén sem.
![;]](http://cdn.rios.hu/dl/s/v1.gif)
Én azon röhögök, mikor kiderül, hogy a BP fizetős, de még a support oldal is olyan hozzá, hogy csak BP alól lehet belépni, egyébként ha más OS alól lépsz be, még ilyen 40 ezer forintos éves díjról is küldenek számlát, hogy fizesd be 
Simán újratelepítgetem időnként az Archot, de az én helyzetem speciális, szeretek új dolgokkal kísérletezni, meg egyre minimalistább rendszert építeni. Értsd ezen azt, hogy amikor újrahúzom, teljesen más rendszert építek, mintha más rendszert használnék és disztrót váltottam volna. Általában más grafikus felület, más alkalmazások, más megoldások. Kivéve most, mert ugyanaz a Sway WM került vissza, ugyanazokkal a terminálos alkalmazásokkal zömében, de már így is volt változás, Keepassx2 helyett kpcli került fel, netctl/wicd helyett saját WiFi-inicalizáló megoldás lesz, stb.. Tehát mindig eltér a telepített rendszer a korábbitól.
A Wine-vel külön bajom, hogy multilib, az még hagyján, hogy sok függőséget behúz, de miért kell 32 bitesnek lennie? Egyszerűen agyrém. A 64 bites bináris is tudna 32 bites Windows-környezetet emulálni.Új hozzászólás Aktív témák
Hirdetés
A topik célja: Segítségnyújtás a Linux disztribúciókkal még csak ismerkedők számára. A szerveres kérdések nem ebbe a topicba tartoznak.
Kérdés előtt olvasd el a topik összefoglalóját!
Haladó Linuxos kérdések topikja.
Linux felhasználók OFF topikja
Milyen program ami... [link]
Shell script kérdésekkel látogassatok el a topikjába
- Vélemény Ubuntu 20.04 LTS
- Vélemény Linux Mint Debian Edition 4
- Tudástár MX-Linux 19
- Bemutató Linux a mindennapokban: Manjaro KDE
- Bemutató Linux a mindennapokban
- Hír Zöld utat adott a nyílt forráskódú Linux meghajtóknak az NVIDIA
- Hír A Steam Play hozza el a Windowsra írt játékokat Linuxra
- Hír Hova jut a világ? Linuxot kínál a Windows Store!
- Windows, Office licencek kedvező áron, egyenesen a Microsoft-tól - Automata kézbesítés utalással is!
- Eladó steam/ubisoft/EA/stb. kulcsok Bank/Revolut/Wise (EUR, USD, crypto OK)
- Assassin's Creed Shadows Collector's Edition PC
- ROBUX ÁRON ALUL - VÁSÁROLJ ROBLOX ROBUXOT MÉG MA, ELKÉPESZTŐ KEDVEZMÉNNYEL (Bármilyen platformra)
- Bitdefender Total Security 3év/3eszköz! - Tökéletes védelem, Most kedvező áron!
- Csere-Beszámítás! Ryzen 9 9950X Processzor!
- Lenovo Yoga Pro 9 (16IMH9) - Intel Core Ultra 9 185H, RTX 4060, 32GB, érintős ELKELT
- Azonnali készpénzes GAMER / üzleti notebook felvásárlás személyesen / csomagküldéssel korrekt áron
- Apple iPhone 14 Pro 128GB, Kártyafüggetlen,
- Telefon felvásárlás!! Huawei P20 Lite/Huawei P20/Huawei P30 Lite/Huawei P30/Huawei P30 Pro
Állásajánlatok
Cég: Promenade Publishing House Kft.
Város: Budapest
Cég: PC Trade Systems Kft.
Város: Szeged