Keresés

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

  • Frawly

    veterán

    válasz Cifu #67116 üzenetére

    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_barrier

    Az 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.

    [ Szerkesztve ]

  • Frawly

    veterán

    válasz CPT.Pirk #67103 üzenetére

    Nem tudom, nem használok ilyet. De ahogy nézem a fórumokat, Manjaro-n és Ubuntu-n is drivert kell hozzá fordítaniuk az embereknek, úgyhogy nem csak Minten és Debianon van ilyen.

  • 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.

    [ Szerkesztve ]

  • Frawly

    veterán

    válasz Cifu #67150 üzenetére

    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.

  • Frawly

    veterán

    válasz Cifu #67154 üzenetére

    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.

    [ Szerkesztve ]

  • 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.

    [ Szerkesztve ]

  • 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 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.

    [ Szerkesztve ]

  • 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.

    [ Szerkesztve ]

  • Frawly

    veterán

    válasz BoB #67180 üzenetére

    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 authorized

    This 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.

    [ Szerkesztve ]

  • 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.

    [ Szerkesztve ]

  • 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.

    [ Szerkesztve ]

  • 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 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 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 :DDD

    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.

    [ Szerkesztve ]

  • 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 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.

  • Frawly

    veterán

    válasz BoB #67278 üzenetére

    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 #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 ;]

    [ Szerkesztve ]

  • 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.

    [ Szerkesztve ]

  • 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 #67291 üzenetére

    Ez az én hibám, hogy elkezdtem az Arch-offot, csak amit gyurmafigura írt, annyira találó volt az esetemre, hogy nem bírtam ki, hogy ne ide írjam.

  • 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 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.

    [ Szerkesztve ]

  • Frawly

    veterán

    válasz Bici #67309 üzenetére

    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 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

    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 #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 #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 Dave™ #67322 üzenetére

    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 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 ;]

    (#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.

    [ Szerkesztve ]

  • 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 Cifu #67334 üzenetére

    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 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.

    [ Szerkesztve ]

  • 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 Bici #67355 üzenetére

    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.

    [ Szerkesztve ]

  • 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

    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.

  • 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 kmarci25 #67412 üzenetére

    Leírhatnád mi volt a megoldás, kíváncsivá tettél. Az alkalmazásindító menüből eltávolítás csak egy ikont távolít el, nem magát a programot.

  • 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 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 Dave™ #67441 üzenetére

    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..

    [ Szerkesztve ]

  • Frawly

    veterán

    válasz Dave™ #67443 üzenetére

    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

    válasz Fecogame #67455 üzenetére

    parancs | grep -E "\e[31m"

    Ha esetleg nem működne, akkor így is meg lehet próbálni
    parancs | grep -E "\\e[31m"

  • Frawly

    veterán

    válasz CPT.Pirk #67476 üzenetére

    Ez milyen gép egyébként? Próbáltad a kiírt Clonezillát másik gépen is bootoltatni?

  • 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

    válasz Bici #67480 üzenetére

    Nem. Passzolom. Még nem volt időm kipróbálni. De te írhatsz róla benyomást, a saját topikjában, amit nyitsz, vagy akár ide, esetleg a Linux OFF topikba.

  • Frawly

    veterán

    válasz Szokenesz #67520 üzenetére

    A Chromiom-vaapi verzióban nézz szét a chrome://flags és chrome://gpu oldalakon, hátha találsz még vonatkozó beállítást.

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