- Fotók, videók mobillal
- Az Oppo Find X8 Ultra lett a legvékonyabb kameramobil
- Apple AirPods Pro (2. generáció) - csiszolt almaságok
- iPhone topik
- One mobilszolgáltatások
- Samsung Galaxy S21 és S21+ - húszra akartak lapot húzni
- 45 wattos vezeték nélküli töltés jön az új iPhone-ba
- Google Pixel topik
- Okosóra és okoskiegészítő topik
- Motorola Razr 60 Ultra - ez a kagyló könnyen megfő
-
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
ubyegon2
#60196
üzenetére
Pedig Atommal horgászni lehet hatékonyabb, mint gondolnád. Ha nem jön a kapás, akkor atomot nekik felkiáltással bevágod vízbe, úgyis oda való, mire kiugrik belőle az összes hal, hogy ők ezzel a sz@rral egy tóban csak azért sem
(#60205) berojocy: swap arra a felhasználásra már 8 giga mellé sem kéne, annyinál átlag felhasználásnál (hacsak nincs túl sok füles böngészés, meg masszív párhuzamos virtuálgépezés, vagy ilyesmik) bele sem nyal a swapba. Amúgy a 16-os Ubi helyett, a 18.04-est ajánlanám neki, ha nem volt nagyobb gondja, és azon a vonalon akarna maradni, a Mint nem rossz, de az előrelépés úgyse lenne neki. Ha meg váltani akar disztrót, akkor Manjarót, Fedorát ajánlom, a Mintet ilyenkor sem (szegény Cinmanó megint), az meg nem lenne eléggé más az Ubuntuhoz képest.
Ha már sok RAM + swap, pont pár órája futottam bele egy elég haladó unixos-linuxos faszi videójába, sokmagos AMD FX procis gépében ott figyelt a 32 giga RAM, amiből 30,3 giga ott állt kihasználatlanul a top szerint, de ott figyelt felcsatolva a teljesen üresen kongó 16 (!!!) giga swap pluszban. Facepalm erősen. Még jó, hogy nem a MS ajánlásait olvasta, hogy a fizikai memória kétszerese legyen a swap
Ráadásul Xfce-vel meg twm-mel nyomja minimalistán, majdnem csak terminált használ, mellette csak egy szintén minimalista videórögzítő szoftvert (azt sem túl magas felbontáson) meg egy max. 1-2 gigás emulátoros környezetet (simh-ban OpenVMS és egyéb legacy rendszert, azt is csak teszt erejéig). Pedig nem is tűnik idiótának, fejből vágott mindenféle OpenVMS-ses, solarisos meg ultrixes parancsokat, nem bénázott, elég veteránnak néz ki. Lehet valami régi rossz beidegződés, amit még kicsi memóriás gépek korszakában szokott meg, mikor a RAM felét adta swapnak automatikusan, különben nehogy instabillá váljon a rendszer. Vagy valami telepítő oldotta meg neki így automatán, amit azért kétlek. Teljesen megértem, igaz, hogy a 16 gigát sem tudom kihasználni az enyémben, de állandóan rettegnék, hogy 32-ből bármelyik másodpercben kifuthatok 
Bár ki tudja, lehet van pár tera tárhelye, és poénból tett be swapot, „ezt használd öcsém, ne anyád kenyérpirítóját” felkiáltással. Sose tudni A RAM-nál meg lehet úgy volt vele, hogy Linux boxnak nem kell annyi, de ha már úgyse nagy pénz amerikai fizetésekhez mértek kimaxolni, akkor megteszi, nem akart további bővítgetéssel, meg alkatrészrendeléssel tökölni a jövőben. Ekkora RAM-ra már tényleg áll az az ősi kínai mondás, miszerint ought to be enough for anybody © ® -
Frawly
veterán
válasz
#20749568
#60191
üzenetére
Lehet vinné a Linuxot is, elvileg a prociba integrált GPU az pl. kompatibilis, meg jó eséllyel az Intel chipsetben lévő cuccok is (hangchip, lemezvezérlő), de pl. a beépített Wi-Fi, BT kártyáról semmit nem tudni. Ahogy írták, UEFI is lehet szopós, igaz azt általában meg lehet oldani, még ha kínkeservesen is.
279 ójróért ne ilyen szart vegyél, ennyiért kapsz használt üzleti notit vagy szubnoteszt. Vagy ha nem ragaszkodsz a Linuxhoz, csak tó partján meccsnézésre és mobilnetezére kell, ahhoz jó egy nagyobb telefon vagy tablet is.
Az Androidnak elég kevés köze van a Linuxhoz, igaz, hogy egy szénné hekkelt Linux kernel hajtja, de nagyon sokat módosítanak rajta, és egyfajta köztes réteg csak, mert a dolgok zöme javás szutyokban fut.
-
Frawly
veterán
válasz
vargalex
#60158
üzenetére
Kösz a segítséget, új shell nyitása után megy.
Nekem valami olyan lenne a legjobb, hogy ha valahogy a pacmannak a tárolókban lévő összes csomag nevét ki tudnám listázni, meg külön az összes fájlnevet. Tudom, tetemes lista, de ezt már pipe-pal meg tudnám etetni grep-pel, és úgy már megtalálnám, hogy mit keresek.
-
Frawly
veterán
válasz
vargalex
#60153
üzenetére
Kösz az ajánlást. zsh-ra már tervezek átállni egy ideje, ezeket a completion csomagokat nem ismertem. Most egyelőre feltettem ezt a bash-completion-t, de semmivel nem egészít ki jobban, mint nélküle. Csomagneveket sem egészíti ki. Talán újraindítás kéne neki? Próbáltam sudo-s parancsokat is, meg sudo nélkülieket is.
Természetesen használom a pacman -Fs, pacman -Ss kapcsolókat is, de általában azzal sem találom meg, amit keresek, pedig az -Fs előtt lefuttatok pacman -Fyu parancsot is.
-
Frawly
veterán
válasz
ubyegon2
#60149
üzenetére
Az Arch ilyen, nem valami felhasználóbarát. Ott neked kell utánanézni dolgoknak, meg Wiki-t nyálazni. Grafikus csomagkezelés sincs. Ezért nem szoktuk kezdőknek ajánlani, ők jobban járnak Arch-vonalon a Manjaro-val.
Nem rossz az Arch, csak minimalista, hogy karcsú állapotban tartsák, meg ne kelljen nagyon belehekkelni csomagkészítéskor a csomagokba, azok minél közelebb legyenek a git-es upstream forráshoz, azaz az eredeti vanilla állapothoz. Mint kiderült, nem is az Arch hibájából szívtam mostanában dolgokkal, hanem a systemd, kernel, Xorg fejlesztőkkel szaladt el a ló, és adják ki megfelelő tesztelés nélkül a bugos szarokat legújabb verzióként. Az Arch meg mivel bleeding edge-ezésre, meg eredeti állapotban tartásra megy rá, így elsők között ezt ők szívják meg, meg az Archerek. Nem baj, ahogy te mondanád, legalább visszavesznek az Arch-ukból
-
Frawly
veterán
válasz
ubyegon2
#60147
üzenetére
Nem tudom, még nem használtam azt a parancsot. Már egy ideje nem apt-ozok egyáltalán, pacman megy helyette.
A csomaglista mindenképp segítség, nem csak az, hogy mit kell feltenni, hanem hogy pl. pontosan hogyan hívják a csomagot. Arch alatt rendszeresen szívok ezzel, pl. most nemrég egy játékhoz szükséges sdl2 image csomag szopatott meg, emlékeztem rá fejből is, hogy kelleni fog, össze-vissza írogattam egybe, kötőjellel, mikor kiderült hogy alsókötjellel kell írni. Vagy pl. a wine-nál kiegészítésnek ott van a wine-mono csomag, bezzeg a wine gecko már _-jellel van összekapcsolva. Ezeket mindig felteszem, mert enélkül minden Wine-frissítés után elkezdené külön letölteni ezeket a komponenseket, míg ha fent vannak ezek a csomagok, akkor csak akkor frissíti őket, ha van belőlük újabb, ami sokkal ritkább. De hogy a kedvencedet említsem, az inxi-t, annál meg kiírta a pacman, hogy error: target not found: inxi, de így jártam a scite-vel is. Mondom mi az any*d, utána kellett ennek is nézni, és kiderült, hogy az AUR-ban van, és emiatt yaourt-tal kell felnyomatni. Ez elég genya volt, a csomaglistából sem derült ki, hogy melyik tárolóból ment fel.
-
Frawly
veterán
válasz
ubyegon2
#60145
üzenetére
A dpkg -l (Archon pacman -Qq) paranccsal az a probléma, hogy elvileg az összes csomagot kilistázza, azokat is, amik az alaprendszernek részei, meg azokat is, amik függőségként kerültek fel. A askubuntun azt írják, hogy erre a apt-mark showmanual parancs való, az kilistázza, amit te kézzel tettél fel, függőségek nélkül.
Erre Archon, Manjaro-n a pacman -Qetg való, de talán könnyebben megjegyezhető -Qget formában, persze semmi köze nincs semmilyen get-ezéshez, a groups, explicit, rövidítései, a t-nek nincs jelentése, az csak egy kapcsoló, aminek épp csak ez betű maradt (és az alaprendszerhez tartozó csomagokat szűri ki).
(#60145) ubyegon2: de, a csomaglista segít, mert új rendszeren lehet nem fog emlékezni elsőre minden programra, ami a régi rendszeren fent volt. Így meg nem kell memóriából tolni, hanem egy listafájlból ki tudja nézni, ami tényleg kell neki, és nem felejt ki semmit.
-
Frawly
veterán
válasz
Skullwipe
#60100
üzenetére
Félreértettél, mert a programokat újra kell telepíteni, de ez nem Windows, hogy mindenféle .NET keretrendszert, meg SP pakkot, meg DirectX-et, meg MS Visual C++ Runtime anyjakínyját be kelljen tárazni, meg drivereket meg telepítőket netről összevadászni, meg virusirtózni és registryzni. Felrakod az alaprendszert, elindítod a csomagkezelőt, felteszed azokat a programokat tárolóból, amit használni szoktál (csak beírod sorban a nevüket, vagy kiválasztod őket listában és egy füstre telepít mindent), a mentésből a progik beállításait visszamásolod, és készen vagy. Nem kell vele Windows módjára fetrengeni, meg 3 napot várni, mire 250 frissítést egyáltalán megtalál a Windows Update, miközben 15-ször indítja újra a gépet. Bár már a Windows 10 ilyen téren kulturáltabb lett, mert egy csomó ilyen pakkot indításból tartalmaz, meg a Windows Update-en a drivereket is megtalálja, az update-ek összevont havi rollupok, így kevesebb van belőlük (meg az évfordulós meg őszi-tavaszi nagy frissítésekhez adnak ki új telepítőket kompletten), meg a felhasználói mappád, dokumentumokat annál is át tudod tenni másik partícióra, hogy újratelepítésnél ne vesszenek el. Meg ugye SSD-vel a Windows is gyorsabban telepszik.
(#60101) vargalex: Igen, kösz a kiigazítást, valóban így helyes. Benéztem a history fájl nevét, meg nem emlékeztem, hogy az Arch telepítő Zsh-s. Júbájgon8-nak abban igaza van, hogy a kolléga Mintre akarja, így az Arch-os példával nem sokat tud kezdeni.
Az viszont igaz, hogy a /var/log mappa, meg az apt history elmentésének nem sok értelme van, egyszerűbben is lehet listát nyerni a telepített csomagokról. Persze el lehet menteni a komplett /var/-t, csak értelmét nem látom.
-
Frawly
veterán
válasz
Skullwipe
#60098
üzenetére
A shell history az a /home/felhasználóneved/.bashrc-ben található, Arch telepítéskor meg mivel root-tal csinálod, ezért a /root/.bashrc-ben.
Húzd újra teljesen az egész telepítést, ne csak a Cinnamont. Előtte a /home/felhasználóneved/ mappát mentsd el. Ebben /home/felhasználóneved/.config/ mappában vannak a programok beállításai, a /home/felhasználóneved/Desktop/ mappában meg azok az ikonok, amelyeket kitettél az asztalra Cinnamonban. Ezeket újra tudod hasznosítani egy új telepítésben. Az még jobb, ha a /home külön partíción van, mert akkor újratelepítés után is megmarad. Ezt a /home/felhasználóneved mappát rövidítik ~/-nek is. Lényegében olyan, mint Windows alatt a C:\Users\felhasználóneved mappa, bár a Windows a beállításokat inkább a registryben tárolja, de az Asztal, Letöltések, stb. Windows alatt is itt tárolódik.
Arch telepítését scriptből nem ajánlom. Nem fogod látni mit csinál, nem fogod érteni mitől megy vagy mitől nem. Ha kezdőként az Arch életérzést akarod, akkor tegyél fel Manjarót, az felhasználóbarátabb formában adja meg lényegében majdnem ugyanazt.
-
Frawly
veterán
válasz
kovaax
#60094
üzenetére
Akkor igaza volt a kollégának, nálad nem opció az összes OS újratlepítése, így a GPT-re átállás sem. Ezt az MBR vs. GPT vitakört mindig lefutjuk, nem okoztál semmilyen ramazurit.
A pontos hibaüzenet viszont kéne, meg hogy melyik progival próbáltad telepíteni, esetleg a telepítő írja-e ki.
(#60072) BoB: azért jegyezzük meg, csak a noob-ok telepítenek scriptből, akkor is, ha saját tákolmány
A telepítés menetében lehetnek változások időről időre, nem akarom automatizációval elcseszni. Inkább gépelgetek, meg figyelek jobban, de nem akarok szívni. Annyira gyakran úgyse telepítek, hogy megérje scriptet hegeszteni hozzá. Meg ez a mostani kör újratelepítés volt, nem is telepítés, tehát a telepítéshez képest egy csomó lépés kimarad. -
Frawly
veterán
válasz
Drughi
#60087
üzenetére
Némelyik BIOS-ban ha nincs is bootsorrend-állítás, de bootkor valami billentyűre elő lehet csalni bootmenüt. Ez általában F12 szokott lenni.
A Bitlocker elvileg nem zavarhatna be, de franc tudja, a MS-tot ismerve bármi lehetséges. Secure boot ki van kapcsolva?
16.04 LTS-t semmiképp se, már túl régi.
-
Frawly
veterán
válasz
ubyegon2
#60067
üzenetére
Nem papagájkodás. Az MBR még az eredeti IBM PC XT-re készült 1983-ban. Most meg már eltelt 35 év. Az alaplapok már csak azért támogatják az MBR-t (emulációként), hogy ha valaki WinXP vagy annál régebbi legacy OS-t akar használni, be tudja bootolni, azok még nem támogatják a GPT-EFI bootot. De ha az a kifogás, hogy az UEFI túl új, akkor meg csak mondom, hogy az meg 2005-től létezik a mai formájában, a PC-k előtt is volt már szervereken és maceken.
Nem biztos, hogy van belakott rendszere. Különösen érdemes belakás ELŐTT figyelni erre, hogy később meg ne az legyen az indok, hogy jajj, be van lakva. Sok embernél ezt a belakási mizériát sem értem, az SSD topikban is megfigyelem, hogy mindenki ragaszkodik foggal-körömmel a rendszeréhez, mindegy hány éves, mennyire teleszemetelt install.
Magam részéről legutóbb Archot 30 perc alatt felhúztam. Azért ilyen lassan, mert ott neked kell kézzel gépelgetni a parancsokat, Wiki-t nyálazni mellé, meg netinstall, meg kell várni, mire letöltődnek a csomagok a gépedre. Egy offline intalleres Linux fent van 5-15 perc alatt, pláne SSD-re. Belakni néhány nap, nem kell vele 5 perc alatt rohanni. Mikor épp használnál egy progit, felteszed, beállítod (linuxnál vissza lehet másolni mentett conf fájlt /etc/-ből meg a régi home-ból). Annyira nem olyan nagy szám, mint amennyire az emberek rettegnek tőle. Mintha valami szent dolog lenne egy belakott rendszer. Azt értem, hogy kényelmesebb annál maradni, csak a túlzott ragaszkodást nem szoktam érteni. Majd belakódik az megint, néha nem is árt tiszta lappal kezdeni. Én sem telepítek újra naponta (jó, most volt egy kivételes eset pár napja).
Értem én, hogy Windows alatt keservesebb, mert az Update-ek soká érnek le, ha régi lemezképből lett telepítve (bár ezen a MS is segített a rollup-okkal), meg a driverek is szopósabbak (azokat meg érdemes gyűjteményben összeszedni, meg mindig frissen tartani ezt a pakkot).
Az UEFI-nek az a baja, hogy sok OS rosszul implementálta az EFI bootot, a telepítő összegányolja az UEFI bejegyzéseket, meg az OS-ek rákényszerítik az UEFI-re a saját bootloadereitket (NTLDR, GRUB, stb.), teljesen feleslegesen, mikor az UEFI már önmagában is bootloaderként működik, nem kell összeláncolni még további rendszerbetöltőkkel. Legdurvább Fedorán az UEFI boot. Az UEFI loader indítja a shim bootmanagert, az a GRUB-ot, a GRUB indítja az initramfs-ből a kernelt. Agyrém, kéne még közé 5 bootloader, hogy hosszabb és bonyolultabb legyen a láncolat. Közben meg az UEFI önmagában elég, hogy indítsa a kernelt/initramfs-t systemd boottal. Rosszul használják, főleg azért van vele a rettenet sok szívás, esetleg kis részben az is beleszól, hogy pár szutyok gyártó, főleg az alsó kategóriás olcsó termékeibe nem szabványosan implementálja. Aztán mindenki retteg tőle, meg nem meri használni, mert nem fog bootolni a gép.
-
Frawly
veterán
válasz
lacafaca
#60064
üzenetére
Elég régóta nem az a hely. Én neked adok igazat, szerintem igenis volt köze a kérdésnek a Linuxhoz, a RPi-s rendszerek is Linuxok. Jó, annyira nem szoros a kapcsolat, de ha egyszer kezdő topik, és a kezdő Windows alól tud csak indulni, akkor miért ne, a lényeg, hogy kezdő és linuxozni szeretne. Rendszeres kérdés szokott lenni a topikban, hogy hogyan kell Ubuntu vagy Linux Mint-es lemezképet Windowson pendrive-ra kiírni, az sem annyira más téma. Szerintem az összefoglalóban ezt a kérdéskört jobban ki kéne emelni. Azért ne húzd ki nagyon a gyufát a topikban, most kiírtad a lemezképet, de garantálom neked, hogy lesz még bőven pont, ahol meg fogsz akadni, és akkor megint jönni fogsz kérdezni
Esetleg ha annyira meglincsel a tömeg, akkor próbálkozz az RPi topikjával.(#60057) ubyegon2: tudom, elvagyok én magammal jól. Csak ha már felvetettem több problémát, akkor gondoltam írok megoldást is, amolyan blogolásszerűen. Igazából ezt az Arch-topikba vagy a Haladóban kéne, de azt olvassa összvissz 2-3 ember. Itt meg mindenki megfordul, meg ezekbe a problémákba nem csak Archerek, de bárki belefut, aki frissebb disztrót használ, pl. fedorások is. Esetleg Linux OFF, de ott off topikban meg a szakmai téma off.
-
Frawly
veterán
válasz
kovaax
#60063
üzenetére
De, lehet logikai partícióra tenni. De a GRUB indítókódjának benne kell lennie az MBR-ben is, így telepítéskor a renszerbetöltő helyének eszköznevet kell megadni szám nélkül, pl. /dev/sda és nem /dev/sda1. Egyébként meg 2018-ban GPT partíciós tábla (nincs többé logikai meg elsődleges partíciózás) és EFI partíció/boot (nem kell MBR-ezni).
-
Frawly
veterán
válasz
Frawly
#60030
üzenetére
Na, úgy néz ki, hogy felesleges volt mérgelődni, mert ma lejött a 4.16.4-es kernel, és ezzel eltűntek ezek a hibaüzenetek. Igazából még watchdog did not stop-ot sem láttam most, igaz nehéz elolvasni, mert villámgyorsan írja ki, journalctl-ben meg nem látszik.
Gnome alatt most egyelőre az Intel modesetting driver meg a NetworkManager Wi-Fi-kezelése is teljesen jó, már napok óta nem futottam bele semmilyen bugba. Lehet csak én fogtam ki ezekkel egy balszerencsés szériát, amit tetéztem egy bugos KDE-vel, de akkor is betette nálam a kaput.
-
Frawly
veterán
válasz
vargalex
#60027
üzenetére
Akkor visszavonom, és a systemd-sek szégyelljék a pofájukat elfelé. Talán még az is lehet, hogy Intel modesetting driver bug meg a NetworkManager szakadozása sem Archék hibája, bár most utóbbi kettővel nincs baj Archon Gnome-mal. Az utóbbi időben mégis kezd már sok lenni így összességében.
-
-
Frawly
veterán
válasz
ubyegon2
#60021
üzenetére
Az elgépelés nem érdekel. Tényleg ki fogom próbálni, hogy Manjaro alatt milyen a KDE. Nem fogom használni, csak ránézek azzal is szórakozik-e, vagy csak Archon ilyen kalap fekália. Bár azt még mindig nem értem, hogy mi alapon várjuk, hogy majd pont Arch-alapú Manjarón lesz jobb, de majd meglátjuk, ahogy a vak asszony mondaná.
Egyébként Archék kezdenek szétesni, mostanában egyre több Archer panaszkodik, hogy a kernel leálláskor protocol error-t írogat, meg /oldroot/fssys lecsatolási hibákat (ezt nálam is írogatja), megoldás az utóbbira nincs, ráadásul már a telepítő is csinálhatja leállításkor. Ezek ártalmatlan hibaüzenetek, mint a watchdog did not stop, de idegesítő. Összeszedhetnék magukat.
(#60017) csixy: a linkgyűjteményt nem tudom hétvégénél korábbra ígérni.
-
Frawly
veterán
Ki fogom próbálni a Manjaro KDE-t. De szerintem nem fog segíteni, mert az is Arch alapú. Ha meg sima, alap Archon ilyen, mindjárt frissen telepített, mindenféle spéci hekkelést nélkülöző, stock rendszeren is, ráadásul Linux-barát, nem túl régi, nem túl új hardverről futtatva, akkor a fene megette.
Az azért sokat elárul, hogy ugyanezen a gépen, ugyanígy friss, stock Arch telepítésen meg a Gnome-nak az égvilágon semmi baja, sehol egy szál bug. Pedig én világ életemben KDE-s voltam, de ennek most vége.
-
Frawly
veterán
Ugye most csak viccelsz! Ha linuxozol, akkor nem árt tisztában lenni, hogy mi micsoda. Mi a Xorg, miben különbözik a Wayland, mi a Mesa. Mi a kernel, mi a systemd.
A Waylandnek a lényege a Xorg-hoz képest, nagyon leegyszerűsítve, hogy minden egyben. Míg Xorgon külön van a grafikus/display server, WM, kompozitor, addig a Wayland az mind együttvéve. Persze még ez is pontatlan, mert olyan, hogy Wayland nincs, az csak a protokoll neve, magának a tényleges megoldásnak mindig van valami saját neve (Sway, Weston, Gnome Shell). Ha most a következő kérdésed, hogy mi az a szerver, meg a kompozitor, abba nem megyek bele, ha kéred, szedek neked össze jól magyarázó linket a témában.
A Mesa meg lényegében parasztosra leegyszerűsítve az OpenGL-támogatást adja, hogy a GPU-n tudd használni a 3D-s hardveres gyorsítást. Mesa nélkül csak 2D-s gyorsításod lehet (erről linuxos driver gondoskodik), vagy legrosszabb esetben az sem (bár ez elég ritka).
Egyébként a többieknek is címezve: ez a Wayland még nagyon kísérleti, nagyon korai szakban van. Van előnye, pl. a vágólap tartalma külön kezelőprogi nélkül nem szűnik meg, ha bezársz egy progit, nem kell hozzá külön kompozitort is futtatni, meg ahogy én érzem, gyorsabb is kirajzolásban, grafikus teljesítményben. De még túl kevés dolog támogatja, azok is általában bugosak. Van 3 komoly implementáció, amelyik tényleg normálisan támogatja, lényegében Gnome, Sway, Weston, a többi elég kísérleti meg demo cucc, vagy csak félig támogatja (mint a KDE Plasma 5.x). Login Managerekből meg csak a GDM támogatja rendesen, az SDDM részlegesen (önmaga nem Waylanden fut, de tud waylandes sessiont indítani), a többi egyáltalán nem. Ez így még nagyon kevés, kell még neki minimum 5 év, hogy elterjedjen, rendesen támogatott legyen, legyen annyira stabil, mint most a Xorg-os megoldások.
A waylandes megoldásokat kicsit elölről kell tanulni. Se Xorg drivereket nem támogat, se xbacklight, se setxkbmap, se xrandr, nem kompatbilis sok Login Managgerrel, semelyik X-es kompozitorral, stb.. Mindent máshogy kell rajta megoldani, így meg nem lehet a régi ismereteket használni rajta.
-
Frawly
veterán
Kösz ránézek erre is. Archon sose volt 90 másodperc a watchdog-hiba, csak pár tized másodperc, inkább csak idegesítő, hogy irkálja.
A Gnome teljes egészében waylandes. Általában a fullos csomag felrakja az X-et is, de csak fallback opcióként, alapból a Gnome Wayland sessionnek kell indulnia a GDM-ből. Kivéve az Ubuntu, ahol eleve a Xorg-os Gnome az alapértelmezett, de itt is átállítható full Waylandre.
-
Frawly
veterán
válasz
ubyegon2
#59994
üzenetére
Hát, ebből lehet Gentoo lesz előbb-utóbb. Utoljára ilyen bugos KDE-t még a KDE4 alatt láttam (talán 4.8-as), ami Debian 7-en futott, már nem emlékszem a pontos verzióra. Az volt ilyen használhatatlan bughalmaz.
Ráadásul nem értem a NetworkManagert sem, mindig ugyanúgy telepítek kézzel, semmi script vagy barmolás, csak az Arch Wiki és kékluficet cikke szerinti szabvány lépések, és Openbox, IceWM, Xfce, i3wm alatt szarakodott, most Gnome alatt teljesen jó. Vagyis egyszer átvágta magát Airplane Mode-ba Gnome alatt, de lehet én nyúltam mellé, és megnyomtam véletlenül valami hotkeyt. Vagy itt is lehalt a Wi-Fi, de a Gnome kulturáltabban lekezelte, nem tudom, eddig csak egyszer fordult elő, akkor is kikapcsoltam az Airplane Mode-ot, és utána azonnal megint jó lett.
Az meg hogy a grafikai hiba sem fordul elő, azt annak tudom be, hogy a KDE csak félig waylandes, a Gnome-ban meg teljes a támogatás, ki van belőle vágva a vérbe a b*zi X. Mindegy, még sose volt Gnome a fő rendszeremen, legalábbis nem Gnome Shell 3, még anno a 2-es verzió régi Ubik alatt, amikor még nem tértek át Unityre. Legalább ezt is tesztelem alaposabban. Azt közben még a régi telepítésen kizártam, hogy a grafikai bugot a 18.x-es Mesa okozná, arra jutottam, hogy az új X nem fér össze a kései 4.15-ös és korai 4.16-os kernelek modesetting Intel driverével. Közben még futok köröket a Sway-jel is.
-
#59984
Frawly
veterán
Flowtation
#59983
Frawly
veterán
válasz
Flowtation
#59983
üzenetére
Alapvetően nem szokott gond lenni, de néha szükség lehet némi reszelésre. Főleg az nem mindegy, hogy amelyik gépbe átrakod, abban milyen GPU van. Illetve nekem legutóbb ilyen esetben nem bootolt az Arch, mert 2. gen. Core i procis gépből áttettem 3. genesbe, ott meg az initramfs-be kellett valami crc32-intel hook is. Utána nem volt vele gond, igaz az GPU az egyezett (Intel IGP mindkét gépben).
-
Frawly
veterán
Kösz, ennek a kernelparaméternek utánanézek. Schedulert nem váltok viszont. Néztem a phoronixon is, mindegyik egykutya, egyiknek ez, másiknak az fekszik. Egyelőre úgy tűnik, hogy az f2fs ugyanolyan sebességet produkál érzetre, mint az ext4.
Közben újradobtam 1 nap után az Archot, most nem volt cécózás, lement a telepítés kb. 30 perc alatt. A KDE akkora bughalmaz volt rajta, hogy használhatatlan volt, így újratelepítettem, nem akartam Qt-s rendszert vegyíteni Gtk-ssal, mert az álmoskönyvek szerint sem jó ötlet. Most Gnome3-mal tettem fel, ez eddig nem bugos. Nem áll kézre, kicsit lassabb vele a boot, kapásból bekajál 1 giga memóriát kb., de bug egy sem jött elő, nem szórakozik a NetworkManager, nem volt gond a modesetting Intel driverrel. Minden megy szépen, hiba nélkül. Igaz a Gnome-ban még sok minden nincs beállítva, de már most jobb, mint a KDE volt. Fáj a szívem a KDE-ért, de a Plasma5-öt az utolsó verziókra úgy szétcseszték, hogy menthetetlen, számomra innentől halott. Ezzel akkorát süllyedtek a szememben, hogy többet rá sem nézek, és másoknak sem fogom ajánlani.
-
Frawly
veterán
Gondolom van valami megállapodás, hogy az ő rendszerük kerül a laptopokra. Vagy valami együttműködési viszont. Én még nem próbáltam, de nem hangzik jól, hogy csak áruházból tudsz telepíteni.
Folytatva a KDE-s szenvedésem: úgy néz ki dobni fogom. Sajnos nem támogatja már a régi jó átlátszó ablaktémákat, még a Plasma5-ösök közül is sok nem működik. A bezárt progik is segfaultolnak, a Double Commander Qt-t még bezárni sem kell hozzá, segfaultot dob induláskor. Beállításokat sok programnál elfelejti. Így persze, hogy gyors és kevés RAM-ot eszik, ha mindent kivettek belőle.
-
Frawly
veterán
válasz
Frawly
#59962
üzenetére
Sajnos a NetworkManager is épp úgy bugos, ezzel ugyan nem szakadozik a Wi-Fi, hanem csak úgy lehal az eszköz. Szóval az Intel modesetting driveren kívül a másik bug is megmaradt, fölöslegesen szaladtam vele egy kört. Most ez vagy az új kernel, új systemd vagy az Arch Linux hibája.
A KDE viszont mégse vészes annyira. 408 megát eszik boot után, igaz hogy gyorsan felmegy. Össz rendszerbetöltési idő 9 mp. körül van, az ekkora DE-nél nem olyan rossz, kb. 4 másodperccel nyújt rá az openboxos megoldásra, és már az f2fs sem érződik lassúnak.
-
Frawly
veterán
válasz
Frawly
#59955
üzenetére
Na, akkor jelentem fent van a KDE f2fs-en. Megérte váltani, mert x4rabbmintvót. Legalábbis máshogy.
Most ugyan nincs grafikus hiba, bár a startx az Intel Xorg driver felrakása nélkül nem indult el modesetting flip done akármi hibákra hivatkozva. Ez azért meglepő, mert a KDE waylandes, fel is tettem a kde-wayland-session csomagot, de állítólag az login manager (SDDM) még X-et használ. Majd ha átállítom azt is Waylandre, kiszedem a Xorg drivert.
Viszont a KDE nem tetszik, nehezen állítom be, nem találom a régi aerós-átlátszó Cupertino témát. Ikonok egyszer eltűntek, azt most az ikontéma újraalkalmazásával megoldottam. A fontok élsimítása is szarabb, mint volt.
Ami a legkevésbé tetszik az az f2fs. Mintha lassabb lenne a boot, mármint a bootloader töltése, onnan, hogy dobja a kernel az infókat betöltés közben, onnan már begyorsult, meg így is gyorsult valamennyit, mióta feltettem még több csomagot (aminek lassítania kellett volna), de az openboxos 4-5 másodperces betöltési időtől messze kerültem. Természetesen erre számítottam, de a vicc az volt, hogy már grafikus környezet nélkül is lassabb lett a boot, a hajam tépem. Még jó, hogy az adatpartíciót nem állítottam még át ext4-ről.
Arch újratelepítése viszonylag gyors és sima volt. Még az UEFI boothoz sem kellett hozzányúlni, mivel a PARTUUID azonos maradt a root partíción. Viszont a pacstrap base meg az intel-ucode addig nem ment fel, míg a bootpartícióról a vmlinuz image, és intel-ucode.img fájlokat nem töröltem. A KDE viszont beszopatott, Arch Wiki bénán van megírva a KDE szócikkben írja a telepítést, csak az van elrejtve másik szócikkbe, hogy az SDDM-et hogy lehet engedélyzeni systemd service-ként. Persze megtaláltam, de nem értem, hogy ilyen fontos infót miért kell elszórni egy másik szócikkben.
-
Frawly
veterán
válasz
stigma
#59956
üzenetére
Első körben szedd le az Intel drivert, ami feltettél, nézd meg utána. Másodszor át lehetne állítani, hogy a Gnome ne X-en fusson, hanem Waylanddel, de ezt nem vágom most fejből, hogy hol kell, utánaguglizni lusta vagyok. De ez utóbbit csak akkor, ha az első lépés nem segített. Elvileg a felbontást magától be kéne lőnie natív felbontásra.
-
Frawly
veterán
válasz
stigma
#59953
üzenetére
Nem hinném, hogy komolyabb baj lesz vele.
Most én is telepíteni fogok, már gurul le a friss Arch installer, és újrahúzom a rendszert. Hátha megoldja a kernel modesetting driver problémáját. Igaz az én gépem régi, i7-2620M-es proci, benne HD3000-es GPU, az azért nem tegnap jött ki. Végre hosszú kihagyás után újra KDE-zni fogok, meg kipróbálom az f2fs-t SSD-n. Lehet meg fogom bánni, bár ki tudja, be is jöhet.
-
-
#59938
Frawly
veterán
ArthurShelby
#59934
Frawly
veterán
válasz
ArthurShelby
#59934
üzenetére
Tedd fel az inxi csomagot, és illeszd be ide a terminálban kiadott inxi -Fxxx kimenetét. Lehet tényleg az a baj, hogy az Ubiban még ott van a Xorg Intel driver, mikor azt már nem kéne használni.
-
Frawly
veterán
Na, úgy néz ki, hogy sem nekem, sem gyurmafigurának nem lett igaza a kernel frissülését illetően. Én azt mondtam, hogy az Arch staging/testing után a 4.16-os kernel egy-két napon belül fog megjelenni a stable (core) tárolóban, ő azt írta (ha jól emlékszem), hogy egy hónap. Közben meg pontosan 16 napba telt, mire a 4.16.2-2-es megjelent.
Igaz már a 4.16.3-at használom a Testingből, a 4.17-RC1 fordítására még nem volt időm. Ez is problémás, de kezdem azt hinni, hogy talán mégse a kernel lesz a baj, hanem a 18-as főverzió óta a Mesa, ők nem örülnek egymás társaságának annyira. Pedig üzleti notiban, Intel CPU-ben lévő nem túl régi generációs Intel GPU-nál nem sok opensource-barátabb GPU létezik a földkerekségen, mégis szopok vele.
-
#59932
Frawly
veterán
ArthurShelby
#59930
Frawly
veterán
válasz
ArthurShelby
#59930
üzenetére
Ubuntu hányas ez konkrétan, a sima verzió egyáltalán? A gépben lévő NV kártya pontos típusa? NV kártyáknál állítólag a zárt drivereknél érdemes maradni, azt viszont nem tudom, hogy a 340-es vagy a 390-es ágnál.
A GRUB-nak annyi köze van a fényerőállításhoz, hogy a kernel ezt energiatakarékos ACPI funkcióként kezeli, és ez paraméterekkel szabályozható a kernel betöltődésekor, de ezt a boot nagyon korai szakaszában kell megtenni, mikor a bootmanager indítja a kernelt. Ennek nem muszáj a GRUB-nak lenni, lehet másik bootmanager is, syslinux, UEFI.
Linuxon nincs Eszközkezelő. A legtöbb drivert a kernel tartalmazza (és kernelparaméterrel szabályozható, esetleg terminálból kernelmodul betöltésével), 1-2 extra eszközhöz meg a csomagkezelővel szedsz le a tárolókból csomagot hozzá.
-
Frawly
veterán
válasz
Frawly
#59877
üzenetére
Na, frissült a kernel a Testingből 4.16.2-1-ről 4.16.2-2-re és ezzel megint szopat. Zároltam a gépet Super+L billkombóval, amire bejön az LXDM. Most visszajöttem a géphez, beléptem újra a desktopra, de nem töltötte be. Gondolom megint atomic flip modesetting bug. Hétvégén tényleg újrahúzom most már a rendszert, mert marhára elegem van. Addig meg felszögelem a 4.17-RC1-es kernelt.
-
Frawly
veterán
Így van. Igenis számít. A 18-as egy csomó új plugint támogat, pl. natív Netflix-plugin. Csak az egészet cseszni lehet, ha csak ilyen-olyan zugtárolóból lehet alfa-béta-git-ként frissíteni, így hiába van új verzió, ha éveket kell várni, hogy a stabil tárolókban megjelenjen. Túlzásnak tartom, hogy ennyi időt ülnek rajta egy főverzión.
-
Frawly
veterán
válasz
saxonb76
#59884
üzenetére
Kicsúsztam a szerkesztési időből. Ha csak Pythonra kell Linux, akkor az is elég lehet, ha az SSD-re telepített Windows alá felteszel virtuális gépet (A VMware Playert ajánlom, stabilabb, mint a VirtualBox), és abba telepíted a Linuxot, így nem kell mindig átbootolni, meg így a windowsos partíciókat sem kell csesztetni. Vagy ha Win10-ed van, akkor abba telepíthető ilyen Linux subsystem, abban is kéne futnia a Pythonnak, és ahhoz még virtuális gépet sem kell bebootolni.
BoB (#59890): egyelőre Archon a Tesing tárolót tesztelem. Még sose engedélyeztem előtte a pacman.conf-ban, csak kézzel szedtem belőle néha a linux és linux-headers csomagot.
-
-
Frawly
veterán
válasz
saxonb76
#59886
üzenetére
Nem mindegy. Melyik rendszert használod gyakrabban? Főleg, ha a Windows a gyakrabban használt, akkor az menjen az SSD-re, az jobban igényli a sok lemezművelet miatt az SSD-t, hogy ne lassuljon annyira be. Linux jobban elvan HDD-n is, mivel nem tekeri a lemezt ész nélkül, meg a fájlrendszerei sem töredeznek annyira.
A telepítés sorrendje sem számít, ha UEFI-s bootmódot használsz. A sorrend csak a BIOS Legacy bootnál nem mindegy, hogy a Windows ne írja felül a Linux bootmanagerét.
-
Frawly
veterán
válasz
Damateo
#59880
üzenetére
Azért írtam, hogy a filekezelőnek is kell támogatnia, hogy külön beállítás nélkül felismerje.
Kézzel csatolva minden program fogja látni. Terminálban add ki ezeket a parancsokat
sudo modprobe fuse
sudo ifuse /csatolasi/mappaAz mindegy melyik mappába csatolod, csak létezzen, meg legyen jogod oda írni. Ha felcsatolta, de nem tudsz rá írni, akkor lehet felcsatolás után (második parancs) kell egy sudo chown felhasználóneved /csatolási/mappa -R parancsot is futtatnod, de ezt is csak egyszer kell.
-
Frawly
veterán
Nem értem, hogy engem miért szivat. Nálam Sandy Bridge van (i7-2620M), igaz sok éves proci, de nem annyira régi, hogy elavult legyen, vagy ősi technológiát használjon. Csak annyi a hátránya, hogy nem támogatja a DX12 és Vulkan API-kat, meg néhány százalékkal gyengébb, mint a későbbi generációs IGP-k, de nekem elég, mert kis felbontáson használom, ha meg játszok is, akkor meg régebbi játékokkal, amit lazán visz maxon. Ettől függetlenül egy böngészőben futó YT videónak bugmentesen kéne, hogy menjen benne, meg nem kéne modesetting driver hibákkal elszállnia leállításkor az LXDM-nek. Nálam nincs semmilyen KDE még, az átállást lehet elhalasztom időhiány miatt még egy héttel.
Egyelőre nálam marad a testingből a 4.16.2-es kernel, lekopogom ez eddig hibátlan, nem merek frissíteni sem stable, sem újabb testing verzióra. Ennek ellenére nagyon böki a csőröm. Főleg az, hogy bugreportok sincsenek rajta a bugtrackeren, így pedig esély sincs rá, hogy javítsanak a helyzeten. Ha ez hosszú távon így marad, és majd az Arch újratelepítése sem oldja meg, akkor vagy át kell álljak én is Gentoo-ra, vagy marad a fedorázás. Harmadik lehetőség nem jut eszembe, amire váltani tudnék (érdemi visszalépés nélkül), remélem nem lesz szükség rá, mert eddig az Arch is nagyon bejött.
-
Frawly
veterán
-
Frawly
veterán
Kösz a visszajelzést, engem is Intel IGP-vel szopat (HD3000). Eddig sose volt gondom a legfrissebb kernelekkel, még akkor sem, ha friss git-dev-RC verziót használtam belőle. Most meg elkezdett szivatni. Eddig az is aggasztott, hogy az Arch bugtrackeren sincs belőle bugreport, de jó tudni, hogy nem vagyok vele egyedül. Majd csak javítják akkor.
-
Frawly
veterán
válasz
Frawly
#59814
üzenetére
Kezd már elegem lenni az új kernelekből. Tegnap az 4.15.15 is elkezdett szórakozni, pedig ez a stabil tárolóból települt. Belassult a grafikus kirajzolás, főleg videólejátszás alatt, azaz megint modesetting driver problémázott. Most testingből felpattintottam a 4.16.2-őt, ezzel most nincs anomália, de most már kezd tényleg aggasztani. Eddig azt hittem, hogy a csomagfenntartó cseszte el a 4.16-os korai buildet, de már a 4.15.15 stable ág is szórakozik. Ebből tényleg újrahúzás lesz.
Azért nem értem, mert nem használok zárt forráskodú szutykot, meg csomagtárolón kívüli felberhelt komponenst sem, amivel össze tudna akadni az új kernel.
-
Frawly
veterán
válasz
ubyegon2
#59823
üzenetére
Nyilván nem ilyen Pop-szutykot kell feltenni, aminek a telepítője rendes particionálásra sem ad lehetőséget. Úgyis Ubuntu alapú Gnome környezetes, akkor már menjen Ubuntu a helyére, abban is Gnome van most már. Fölösleges származékdisztrót használni, ha ott van rá az eredeti.
lwm-en gondolom LVM-et értesz. Ha meg valaki komolyabban linuxozik, és az a fő rendszere, érdemes a partíciókat átállítani ext4-re. Az ntfs-3g igaz, hogy írja, olvassa az NTFS partíciókat, de elég vaskos CPU-overheaddel. Igaz én most teszek kitérőt az f2fs-sel, de csak azért, hogy SSD-n legyen azzal is tapasztalatom, a tesztek jobb I/O teljesítményt mérnek vele, de az ext4 is villámgyors, nem volt vele SSD-n sem gondom.
-
Frawly
veterán
válasz
Slownz
#59817
üzenetére
Futtasd le még egyszer, az outputot másold be ide. Nekünk mondani fog valamit. Egyébként te is megnézheted, azóta eléred-e a /dev/sdb1-et, vagy most már ír-e hibát bootkor.
Ezekre a /dev/sd[nevekre] nagyon vigyázni, véletlenül rossz betűjelet adsz meg particionálásnál vagy formázásnál, és egy másik meghajtót fog particionálni, vagy annak a partícióját fogja formázni, ami adatvesztést okoz!!! Kétszer is nézd meg lsblk-val, hogy biztosan jó meghajtóra dolgozz. Ez nagyon veszélyes móka, most nemrég egy ismerősöm írta, hogy 20 éves linuxos és unixos tapasztalattal a háta mögött pont pár hete fordult vele elő, hogy véletlenül a rendszermeghajtót dd-zte végig, mikor egy lemezképet akart pendrive-ra kiírni, hogy egy másik gépen OS-t telepítsen! Ezt még nagyon profi veteránok is benézhetik, véletlenül elszúrod, odalesznek az adataid. Nem győzöm hangsúlyozni, hogy mennyire oda kell erre figyelni, főleg, ha nincs az adatokról biztonsági mentésed, ami meg egy külön hiba. Külön trükkös, hogy nem lehet emlékezetből dolgozni, néha ezek a betűjelek cserélődnek, így néha egy-egy boot után ami /dev/sda szokott lenni, simán lehet belőle /dev/sdb vagy ha több meghajtó is van, akkor /dev/sdc! Különösen kezdőknek ajánlott odafigyelni, akiknek az outputok sem mondanak semmit.
Azt meg ubyegon jól írja, a fájlrendszer UUID-je is változik, módosítani kell az /etc/fstab fájlban. Az UUID-t az lsblk -f paranccsal tudod ellenőrizni.
-
Frawly
veterán
Közben fejlemények, ubyegon is hadd örüljön. Életemben először downgrade-elnem kellett a kernelt, 4.16.0-2-ről 4.15.15-1-re. A vicc az, hogy 4.16.0-1 jó volt, ment hibátlanul. 4.16.0-2 viszont elkezdte kikapcsoláskor random a [drm_kms_helper] *ERROR* [CRTC:37:pipe A] flip_done timed out hibákat dobni, meg várakozni a LXDM bezárására. Ez modesetting driver hibájánál szokott előfordulni. A 4.16.0-1-et nem tudtam visszatenni, mert már nincs meg, a staging tárolóból kikerült, a testingben már csak 4.16.0-2 van.
Emiatt nem aggódok, mert tudom, hogy nem lesz gond a 4.16.0-val,az 1-es build az normálisan ment, a 2-esben a csomagkarbantartó keffintett el valamit. Ha a túlzott frissesség lenne a baj, akkor már az 1-es builddel is baj lett volna.
Abban meg gyurmafigurának igaza lett, hogy nem 1-2 nap, mivel ma már nálam az 5. nap telik el, és még nincs a stable tárolókban a 4.16. Ahogy nézem a kernel.org-on, az Arch tárolóban lévő 4.15.15 után a 4.15.16 fog jönni, és csak utána a 4.16.1.
Az eset nem tántorított el a friss csomagoktól, de a f2fs + KDE5-ös újratelepítést elhalasztottam miatta a következő hétvégére.
-
Frawly
veterán
válasz
Slownz
#59811
üzenetére
Ha a HDD-ről egy az egyben nem kellenek az adatok, akkor futtass rajta fdisk-et live alól terminálban, abban megadod, hogy create new GPT (vagy DOS) partition table, majd utána write table to disk and exit. De ha akarod, kilépés előtt létrehozhatsz rajta egy új partíciót is. Azt meg utána megformázod kézzel szintén terminálból sudo mkfs.ext4 paranccsal. Arra vigyázz, hogy ezeket a műveleteket biztosan a jó meghajtón futtasd, nálad azt hiszem /dev/sda lesz, de inkább ellenőrizd terminálban az lsblk paranncsal, ott rá fogsz ismerni, hogy sda, vagy sdb, vagy mi a neve.
fdisk helyett használhatsz cfdisk parancsot is, annak kicsit barátságosabb a felhasználói felülete, meg azt érdemes így indítani
sudo cfdisk /dev/sdx -z
A z a végén fontos, mert úgy teljesen új partíciós táblát kezd, nem a régit buherálja. Az x helyére meg a saját HDD-d betűjelét írod. -
Frawly
veterán
válasz
Slownz
#59806
üzenetére
Nem értem, mi az, hogy az egyik HDD-det? Egy HDD-t látok csak, az is valami USB-n van felcsatolva, azon van a rendszer is. Most hogy néz ki a partíciós táblád? Nézz rá live-val. Én nem is lemezhibát látok, hanem ahogy nézem, még mindig az USB-port szórakozik nálad, már múltkor is írtad, hogy valami csodalaptopról vagy táblagépről vagy miről tolod, és gond volt a boottal. Szerintem ez még mindig ugyanaz a hiba.
A jövőben ha csak az NTFS partíciót akarod ext4-re formázni, ahhoz nem kell Gparted, elég lett volna a sudo mkfs.ext4 /dev/sda2-őt kiadni jelen esetben. Gparted max. csak ahhoz kell, ha az 500 megás és a 82 gigás partíciót akartad volna összevonni, de még az is megoldható lett volna fdisk vagy cfdisk segítségével, utána mehetett volna az új partícióra az mkfs.ext4.
-
Frawly
veterán
válasz
ubyegon2
#59805
üzenetére
Nem, ne örülj az 1)-es pontnak, mert bár a sok csomagnak megfelel, de a frissítések elég ritkán jönnek ki Debillányéknál, szóval már ez sem áll, a 2)-es pont meg bukta.
Abban viszont igazad lehet, hogy kapitányt keverem gyurmafigurával.
A Mintet sem tudod ünnepelni, mert hosszú távon cseszheted a KDE-det náluk. Mondom én, hogy Arch lesz belőle, lehet már azon tolod, csak féled nyilvánosan bevallani
A Fedorát hagyjuk meg Torvaldsnak. -
Frawly
veterán
válasz
ubyegon2
#59795
üzenetére
Most ki nem tojja le, hogy a Fedora minek a tesztdisztrója? Friss, támogatott, sok csomag érhető el rá. Torvalds sem azért használja, mert x4r, és szereti magát instabil disztrókkal szivatni. A Debianról neki is az a véleménye, ami nekem, sőt, az övé az enyéménél is durvábban lesújtó.
Igazából egy disztrónál az számít, hogy
1) sok ember álljon mögötte, mert ez gyakori, rendszeres, kiszámítható frissítéseket és sok csomagot jelent
2) legyen mindig minél frissebb.Mert ugye hiába fasza egy disztró, ha alig van rá csomag, mindent neked kell forráskódból forgatni vagy sok csomag van, de megint hekkelned kell mindent, meg tíz kiló külső tárolót hozzáadni, mert túl régiek.
-
Frawly
veterán
válasz
ubyegon2
#59795
üzenetére
Ezt nem értem, KDE-n is könnyű felhozni alkalmazást a rendszerértesítési területről. Be lehet állítani a terület tulajdonságainál, hogy mely appletek látszódjanak mindig, melyiket rejtheti el. A Cinnamont csak azért nem tudod elengedni, mert a megszokás nagy úr.
Kapitányt illetően meg lehet rosszul emlékszem, lehet mégis AMD-je van.
-
Frawly
veterán
válasz
ubyegon2
#59790
üzenetére
Hivatalosan a Fedora is rolling. Azt mindig keverem milyen rolling, de kétség kívül az, elég, ha az éppen aktuális csomagverziókra ránézel benne. Az egész LTS-ezés egy másik problémára, a zárt kód használatára próbál megoldást nyújtani, de ahelyett, hogy megoldaná, csak újabb problémákat hoz létre. Egyébként meg nem szólni be, lassan te is azon kapod majd magad, hogy rollingon vagy, már megkezdted az átállást a KDE-vel meg a 4.15-ös kernellel, már egyre többször futsz neki az Arch-vonalnak is, még egy-két ilyen lépés, és te is átkerülsz végleg a sötét oldalra, és már csak nosztalgiával tudsz visszaemlékezni, hogy szegény Cinmanót tudtad volna 2399-ig LTS-ben használni, de mégis lemondtál róla, szégyen szemre az utolsóként ráoltottad a villanyt szerencsétlenre
-
Frawly
veterán
válasz
lev258
#59789
üzenetére
Azt nem tudom, nem volt még NV kártyám, csak ATi/AMD és Intel GPU-kat használtam. De azt olvastam, hogy már a nyílt driver sem olyan rossz, annak ellenére, hogy a zárt állítólag több fps-t hoz. Kapitány majd megmondja, ő elvileg újabb NV-kártyát használ Arch-alapú disztrón.
Plusz most már a Wayland miatt is halnak ki a proprietary Xorg driverek, egyelőre az NV nem adta fel a zárt drivert, de támogatja már a modesettinget is benne, amit az Arch Wiki szerint kézzel kell engedélyezni. Majd szép lassan feladják ők is a zárt drivert, mint az AMD meg az Intel. Egyszerűen zárt drivernek nehéz lépést tartani az új kernel, Xorg, Wayland protokollt használó kompozitoros verziókkal, mire kihozzák az új zárt drivert, addigra már el is avult, a saját farkukat kergetik vele. Emiatt nem jó ötlet semmiből zártat használni, nem csak az opensoure-os hippikommuna hitvallás miatt, hanem a zárt forráskód akadályozza a fejlődést és a szabad frissítést.
A Xorg még tartja magát, mert sok kis WM eleve csak arra van, meg a nagyok közül a Cinnamon, Gnome is próbálja még támogatni, de hiába az ellenállás, a Wayland szép lassan veszi át az uralmat. Lehet lassítani a fejlődést, de megállítani nem. Ugyanúgy el fog terjedni, ahogy a systemd, szép lassan minden átveszi. Most már az alternatív disztrók inites rendszerei is abból állnak, hogy symlinkek halmazával odagányolsz bennük egyfajta systemd emulációt.
-
Frawly
veterán
Az nem feltétlenül „természetes”. Akkor lehetnek bonyodalmak, érdemes kártyakivétel előtt leszedni az NV drivert. A zárt drivert majd amúgy is felejtsd el, a linuxos világ átállt az összes gyártó új/régi kártyáján nyílt kerneldriverre, a 3D-s funkciókat meg Mesaval oldják meg. Néhány hónap múlva amúgy is disztrót is kell frissítened, min. 16.04-re, de még inkább 18.04-re, ami a következő LTS verzió, és 2023 áprilisáig támogatott. Bár köztudottan nem vagyok híve ezeknek az LTS-bullshiteknek, sokkal inkább megéri modern, friss, rolling disztrókat használni (Arch, Manjaro, Fedora, stb.), főleg ha játszol vagy multimédiázol.
-
Frawly
veterán
Nagyjából így kéne lemennie. Attól is függ, hogy Uborkán milyen drivert használsz most jelenleg. Ha kernel modesetting driver + Mesa fut, akkor simán úgy kéne lezajlania, ahogy írtad, következő bootkor az Intel modesetting drivert kéne beröffentenie automatikusan a kernelnek (hacsak nincs letiltva nomodeset paraméterrel), és a fent lévő Mesa-nak is tovább kéne működnie. Bár ki tudja, az 14.04 elég régi, tudom hogy LTS, és valami 2019 augusztusáig támogatott, de azért visszaüthet, hogy nagyon régi verzió.
-
Frawly
veterán
válasz
CPT.Pirk
#59745
üzenetére
Akkor lehet én használom a kifejezést rosszul. Én half rolling alatt azt értem, ami a Fedora, hogy alapvetően jönnek rá a friss csomagok, új verziók, de van egy pont, ahonnan nem tudsz már frissíteni, csak ha kompletten disztrót frissítesz, új főverzióra. Lehet ennek tényleg más a neve, nem half rolling. Azért mindenképp az olyan maximálisan rolling disztrókat preferálom, mint az Arch, egyszer felteszed, az életben többet nem kell újratelepíteni, nincsenek főverziók közötti distroupgrade-ek, a végtelenségig frissítheted, amíg ki nem rohad alóla a gép.
-
Frawly
veterán
válasz
Rimuru
#59739
üzenetére
Lehet igazatok van, és én emlékszem rá rosszul, és tényleg 1 hónap lesz. Most már kíváncsivá tettetek, megnézem mennyi idő lesz.
A half rollinggal az a bajom, hogy nem akarok disztrót upgrade-elni, nem csak hogy nem félévente, hanem soha. Bár most újrahúzom az Archot, ami még csak egy éve van fent az egy éve megvett gépen, mert úgyis gond van a NetworkManagerrel, meg már annyi szar fent van, hogy átláthatatlan a rendszer, és úgyis vissza akarok állni az örök kedvencemre a KDE-re, meg akkor már kipróbálom SSD-n az f2fs-t, hogy mennyivel jobb, mint az ext4. Az ilyen éles váltásokat jobb tiszta lappal kezdeni. Egyébként az életben nem akarok OS-t újratelepíteni. Bár lehet eltolom még egy héttel, mert vannak dolgok, amit még ezen a telepítésen akarok tesztelni.
Szóval tényleg csak az a bajom a Fedorával, hogy half rolling, ha lenne ilyesmi full rollingban, akkor tenném is fel. Ilyenkor rendszeresen elgondolkozok, hogy a Gentoo ezért lenne jó, ott tudnám mindig git-dev-ből a ropogós, legfrissebb kódot forgatni, de ki a ráknak van arra ideje, hogy állandóan forrjon a gép, míg pörgeti le az új kódokat? Így is meló mellett alig van szabadidőm, mikor gépezni tudok, meg pihenni.
-
Frawly
veterán
Szépen levezeted, logikusnak hangzik, amit írsz, de innen tapasztalatom szerint csak napok kérdése. Majd megnézzük mikor érkezik a stable core tárolóba, április 3-án került be a stagingbe.
Egyébként te is nyugodtan felteheted, nem tapasztalok vele anomáliát. Már többször elgondolkoztam a Fedorán, az ottani srácok beelőzik néhány nappal az Archot frissességben, de az mindig eltántorított, hogy csak half rolling a Fedora. Amúgy melyik disztró a legfrissebb? Mármint azok közül, amelyik bináris csomagokkal dolgozik, és nem forráskódból kell mindent forgatni.
Addig is, próbából, míg fent van nálam ez a régi Arch telítés, engedélyezem a testing tárolókat általános jelleggel a pacman.conf-ban.
-
-
Frawly
veterán
válasz
ubyegon2
#59705
üzenetére
Aztarohadás. 4.15, milyen frissek lettek Minték
Kár, hogy szegény Cinmanó nem élhette meg az ünnepi pillanatot, hogy frissebb kernel lehet alatta. Archon most röffentettem be a 4.16-ot, igaz kézzel kellett szednem a Staging tárolóból a linux-header csomaggal együtt, tehát nem jön automatikusan, de 1-2 nap múlva a stabil tárolóba is várható. Véletlenül rászoksz te is az Archra és a frissességre, akkor neked annyi, nem fog többé kelleni Mint.(#59709) growler: az több minden egyébtől is függ, hogy mutat-e piros mezőket. Proci típusától, a checker verziójától, hogy mennyire friss, van-e fent új mikrokód a procihoz, kernelt mivel és milyen config-gal fordították le. A checker 35. verziója nálam írogatott egy-két piros mezőt, de ezek nem azt jelentették, hogy sebezhető vagyok, mert nálam az összes létező javítás fent van és aktív, mikrokód is fent van, és a kernelkimenet szerint frissült a 2018-02-07-eire. A checker 36-os verziója valóban nem jelez piros mezőket, de csak a design-ja változott, a nem sérülékenységet jelző piros mezőket lecserélték benne narancssárgára. Kernelből a 4.15 sem volt sebezhető, 4.15.9 óta meg az összes védekezési technika bekerült (legutóbb IBRS).
Engem annyiból nem érdekel, hogy most befoltozták ezeket, de itt a BranchScope. Mire meg azt befoltozzák, lesz másik. Szerintem mindig lesz majd valami be nem foltozott procisérülékenység. Szélmalomharc lesz belőle.
-
Frawly
veterán
válasz
ubyegon2
#59702
üzenetére
Nem csak egy gépen figyeltem meg, hanem már sokon. Nem mutatnak egyforma számokat ezek a progik, sem a CPU%-ra, sem a memóriafoglalásra. Eleve CPU-nál különböznek, hogy egy magra vetítik-e le a terhelést, vagy az összes magra (így pl. egy négymagos gépen a teljes terhelést 400%-nak mutatják, a 100% meg valójában egy magra levetítve 25%-ot jelent), meg hogy egyes kernelfolyamatok terhelését beleszámítják-e. Ugyanígy memóriánál, már a shared memóriát is máshogy számolják, van, amelyik nem számolja bele, van, amelyik a cache-t is hozzászámolja. Emiatt nem nagyon érdemes arra támaszkodni, hogy mit írnak ezek.
Ha a kollégának az lenne a gondja, hogy nem működik neki a hardveres dekódolás, akkor nagyon magas CPU százalékokat kéne kapnia, ilyen 80-90% körülit. Az VA-API alkalmazása attól is függ, hogy konkrétan milyen GPU-ja van.
-
Frawly
veterán
válasz
Skullwipe
#59669
üzenetére
Bizony, ezért kell ezeket a Wiki-ket olvasni. Nem csak az Arché jó, a Gentoo Wiki-jében is vannak jó dolgok, amik máshol nem olvashatók, meg néha a Debiané is ír elég exkluzív infókat, főleg driverfronton. Ezeket tényleg akkor is érdemes olvasgatni, ha másfajta Linuxot használsz, sokmindenre találni megoldást, ami mindegyik modern systemd disztrón működik.
-
Frawly
veterán
válasz
Bubisati
#59666
üzenetére
Olyat ne is keress, gondolom magyarul akarnál rajta gépelni. Azt a billentyűzetkiosztást tegyed fel, ami csak simán magyar-nak van titulálva, tehát nem 101 gombos, meg ANSI, meg ilyen baromságok vannak mögé írva. Én ezt svéd billentyűzetnek nézem, de nem érdekes, ha nem nézel le rá mi van rányomtatva a billentyűkre, akkor akármilyen szabvány kiosztással lehet használni, magyarral is. Az én lapotjaimon is brit angol kiosztás van, és teljesen jól gépírok rajtuk magyarul, Windows és Linux alatt is. Nem nézek le a billentyűkre, így nem zavaró, hogy más van ráírva.
-
Frawly
veterán
válasz
Frawly
#59645
üzenetére
Ezt még kiegészíteném azzal, hogy mindenképp kell a grafikus felület. Lehet ugyan használni az UCI protokollt használó sakkmotorokat konzolból, de nagyon kényelmetlen, mindig be kell neki a játszma összes lépését az első lépéstől, meg hozzáigazítani az időket a sakkórán. Régebben a WB protokollosak ellen egész könnyen lehetett játszani konzolból is. Még táblát is ki tudtak rajzolni karakteresen. Ezek a modern UCI-sok is ki tudnak, de lépéseket nagyon körülményesen kezelik.
-
Frawly
veterán
válasz
anorche1
#59641
üzenetére
Ez így működhet. Pl. Sparky Linux IceWM-mel, vagy bármilyen más sovány disztró IceWM, Openbox, LXDE felülettel. Kézzel leforgatod forrásból rá az ingyenes Stockfish sakkmotort. Fel lehet tenni a disztró tárolójából is, de ott nem olyan gyakran frissül, és ezt a kicsi sakkmotort könnyen és gyorsan lefordul forráskódból forgatva is (csak gcc kell neki, ami fent kéne hogy legyen alapból), nincs függősége, és így legalább mindig a legfrissebb lesz fent.
Ehhez Arena for Linuxot teszel fel, ez grafikus keretprogram (sakk GUI). Az IceWM konfigba, a ~/.icewm/startup fájlba beteszed (Openboxnál vagy LXDE-nél a ~/.config/openbox/autostart fájlba), hogy az Arena induljon el, így a grafikus felülettel betölt sakkprogram is.
Persze az Arénát is konfigolni kell, megadni neki, hogy hol van a sakkmotor, meg milyen paraméterekkel használja. Megnyitáskönyvnek a Dann Corbit-féle Superbookot ajánlom, az ingyenesek között azt találtam a legjobbnak.
Ha nem kell, hogy sakktábla kirajzolva legyen, akkor akár egy grafikus felület nélküli Linuxot is elég feltenni, és a sakkmotort közvetlenül lehet használni konzolból, beadagolod neki a játszmabeállításokat (időkontroll, játékerősség, stb.), és tolhatod is be neki billentyűzetről befelé a lépéseket, majd írja rá az ő lépéseit.
Szerk.: ahogy nézem, még a Stockfisht sem kell lefordítani, mert a legújabb verzió benne van az Arenában.
-
Frawly
veterán
válasz
Slownz
#59628
üzenetére
Ubuntunak az az oldala, amit írsz, Debian Wiki, Arch Wiki, Gentoo Wiki, kerneldrivereket taglaló oldalak, Wi-Fi firmware csomagoknak a leírása, hogy konkrétan milyen kártyát támogatnak.
Munkás, mert neked kell utánakeresni a konkrét hardvernek, nincs róla komplett lista, amiről először modelleket tudnál kinézni, hogy majd azt veszed, hanem fordítva kell keresgélni. Ha megtalálod valamelyik listán, hogy támogatott, akkor meg lehet venni.
-
Frawly
veterán
válasz
Skullwipe
#59622
üzenetére
De, hidd el, ritka nagy barom. A Linuxot bármire fel lehet tenni, akkor is, ha régi ATi/AMD kártya van benne. Meg a nyomtató már az a műfaj, amiknek jobb a támogatása, mint Windowon, a gutenprint és hasonló csomagok feltételével általában még ősrégi nyomtatók is életre kelthetők.
Nyilván minél szutyokabb, régebbi a gép, minél régebbi videókártya/GPU van benne, annál nehezebb, annál inkább soványabb, fapadosabb disztró kell rá, meg annál spécibb csomagokat kell feltenni, de most csak ezért új hardvert vetetni. Ennyi erővel vegyen mindenki Macet, vagy valami androidos gépet, az telepített rendszerrel jön, meg arra könnyű újraresetelni az OS-t. Jenkiknek lehet ez a beidegződése, elcsesződött az OS, meg nem tudjuk felrakni, menjünk el új gépet venni, nehogy gondolkodni kelljen, meg segítséget kérni, mert lehet a régi is menne egy kis beletett munkával.
Én inkább azt szoktam javasolni, hogy ez csak új vagy használt gép, nyomtató, stb. vásárlásánál legyen szempont, kirohadt a régi, kell egy másik, akkor nézelődés közben célszerű eleve olyat venni, aminek alapból jó a linuxos támogatottsága is. Akkor is, ha valaki még nem linuxozik, de majd valamikor tervezi rá átállni. Win only szutykot nem éri meg megvenni, nem csak azért hogy a Linuxot éltessük, hanem az a gyártó, aki csak egyféle platformra hajlandó drivereket kiadni, annak általában a supporthoz való hozzáállása is problémás, meg a Windows-drivereit sem szokta kellő időközönként frissíteni, és már csak emiatt is rossz ómen, mikor felmegy az ember a weblapjára a terméknek, hogy csak Vista, meg Win7 támogatott, XP, Win8-10 nem, onnan már le lehet venni, hogy retek az egész. Annak ellenére, hogy attól még Linux alatt valami nyílt driver támogathatja, de én ilyet alapból nem vennék össze, ami ennyire lutri.
-
Frawly
veterán
válasz
Skullwipe
#59616
üzenetére
Ááá, akkora barom ez a fószer, hogy a fal adja a másikat. Szerinte linuxozáshoz venni kell gépet, ami eleve azzal jön, meg ha nem megy a nyomtató Linux alatt, akkor venni kell másik nyomtatót. Itt ki is nyomtam, ekkora idiótával még ilyen gyakorikérdések típusú oldalon sem nagyon találkozni, pedig azokon az oldalakon van néhány nehézsúlyú troll, aki az optikai meghajtó tálcáját használja pohártartónak.
Mindezt negyvenakárhány percben.
-
Frawly
veterán
válasz
zoltanz
#59532
üzenetére
Mint múltkor írtam, kezdj el egy használt üzleti szubnotira gyűjteni. A 2-3. genesek nem drágák, de még kellően jó a teljesítményük, főleg ha SSD-t teszel bele, meg egy kis plusz RAM-ot. Linuxos kompatibilitásuk is kiemelkedően jó. Már csak azért is próbálj rá félretenni, mert ezek a netbookok nem valami tartósak, nem strapabírók, hiába vigyázol rá, gyorsan tönkremennek (papírvékony, könnyű biliműanyagból eszkábált kártyavár az összes, törik, csuklik, nyeklik, hűtése nem megfelelő, zsanér kopik, stb.), nehezen javíthatók, alkatrész nagyon drága hozzájuk, nem éri meg javítani. Nem csak a gond velük, hogy túl gyengék. Tudom, írtad, hogy nem engedheted meg, de előbb-utóbb nem úszod meg, hogy válts valami értelmesebb gépre. Azt értem, hogy megpróbálod ezzel kihúzni, amíg csak lehet, de azt is csak egy pontig lehet játszani. Ráadásul a notivásárlás, főleg használtan, olyan, hogy jó időben előre kell nézelődni, lehet úgy fogsz ki valami jó vételt, kiárusítást, készletkisöprést, akár online boltban, stb., és nem kell gyorsan kapkodva összevenni valami szart, amikor a netbook épp beadja váratlanul a kulcsot. Én volt, hogy azért vettem csak ilyen használt üzleti lapost, mert épp volt valahol jó áron, tartalék gépnek, pedig nem is volt rá szükségem, de mindig próbálok ilyet tartani, ha a fő gépem tönkremenne, akkor is azonnal lehessen nyúlni egy másikért. Már jól is jött, mert az egyik gép tönkrement, igaz az én hibámból.
-
Frawly
veterán
válasz
Keef_Lee
#59540
üzenetére
Ez sokmindentől lehet. Lehet a Spectre elleni védekezés okozza, ha fent van a mikrokódcsomag is. Indítsd ezeket a problémás szoftvereket terminálból, nézd meg mit ír ki üzenetképpen, mikor kilép. Sokszor hagy maga után hibaüzenetet, csak egy grafikus felületen nem látod.
Ha gyorsan akarod megoldani, próbáld ki új Live Lubuntuval, vagy friss Lubuntu telepítésével.
-
Frawly
veterán
válasz
Apollyon
#59534
üzenetére
A Gentoora vagy LFS-re átállást én is fontolgatom, de aztán mindig arra jutok, hogy az Archcsal szemben nem adna már valódi előnyt, csak több időm menne el rá. Pedig biztos jó dolog, mikor mindent te fordítasz, úgy lesz a legmegbízhatóbb a bináris, úgy a gép procijához lesz optimalizálva a kód, ki lehet hagyni a binárisokból a debugging symbolst (igaz azt utólag is el lehet távolítani belőle), meg egyebek, a felhasználó dönti el, hogy milyen kapcsolókkal mit fordít bele a binárisba, nem kell csomagkarbantartóra várni, míg feltölti az új verziót a tárolókba, stb.. A kérdés csak az, hogy ezzel mennyivel lennék előbbre érdemben, mert ezek ma már a mai gépeknél meg friss rolling disztrókkal szemben már nem jelentenének sok pluszt.
A systemd-re lehet haragudni, de az a jövő. A Linux folyton szabványosodik, a systemd is ennek a része, a fejlesztők munkáját van hivatva segíteni azzal, hogy elfedi a disztrók közötti különbségeket rendszerindítás és service/daemonkezelés terén, egyfajta közös pontot teremtve. Ahogy az X és a Wayland is arra van hivatva, hogy egységes API-t biztosítson a GUI-knak, WM-eknek, DE-knek. Ahogy nézem, a modern init-es rendszerek is már csak gányolások, mindenféle symlinkezéssel trükköznek, hogy úgy látszódjon megy a systemd is, de közben mégse, de muszáj így emulálni dolgokat, mert túl sok szoftver igényli már.
A Pulseaudio meg nem azért lassú, mert annyira bloat, hanem pl. a prioritása is elég agresszívre van beállítva a legtöbb disztróban, de azért, hogy valós időben ne szakadozzon a kapcsolat a hangszerverrel, meg ne legyen nagy latencyje.
-
Frawly
veterán
válasz
Frawly
#59530
üzenetére
A Windowsnál sem valami könnyű hibát jelenteni. Insider programban van rá mód. Azon kívül meg a supportot kell hívni, és ők nyitnak hibajegyet. De inkább elhajtanak a francba, ha OEM Windowsod van, nem foglalkoznak veled. Esetleg answeres.microsoft.com fórumán, de ott is csak angolul lehet írni, de közveltenül hibajegyet nyitni nem.
De ez olyan szoftvereknél is problémás, amelyeknek rendes, nyilvános, központi bugtrackere van, rendes linkkel, űrlappal, és rendesen lejelented a hibát angolul. Még ott is szokott menni a fetrengés, hogy az egyik fejlesztő bezárja a hibajegyet, mert szerinte nem bug, hanem feature, a másik megint kinyitja, mert szerinte ennek nem így kéne működni. A harmadik fejlesztő meg átalakítja feature requestté. A negyedik meg rögzíti, hogy készül hozzá a javítás, ami végül soha nem készül el, mert pont nem ér rá, de a többiek meg úgy hiszik, hogy javítva lesz a hiba. Vagy az egyik fejlesztő bezárja, mert már szerinte jelentve lett ez a hiba, csak épp arra nem lesz reagálás, hogy mit lett az eredeti bejelentéssel. Aztán van olyan hibajelentő oldal is, ahol annyira káoszba fullad a hibabejelentés, hogy hónapokig nem reagálnak, minden hiba addig 50× lesz jelentve, azt sem tudják merre kapjanak, melyik hiba hányszor lett jelentve, melyik hibajegyeket kéne lezárni, vagy ha megvan oldva, akkor az összes érintett hibajelentést lezárni, ezzel gyakran küszködnek a fejlesztők, terhes adminisztratív munka nekik, amit a hátuk közepére nem kívánnak, annak ellenére, hogy ez nekik lenne fontosabb visszajelzéseket kapni, nem a hibabejelentőnek. Ha van is idejük a szoftveren dolgozni, inkább fejlesztenek, a kuli adminisztratív munkát meg próbálják másra lőcsölni, akinek van ehhez türelme. Komolyabban kéne vegyék ezt az egészet, de sokszor nem teszik. Ha más nem ezért is kéne ezt megkönnyíteniük, meg korrektebbül eljárni, mert ha nem tudják a hibabejelentéseket kezelni, akkor senki nem fog hibát bejelenteni, nem fognak visszajelzéseket kapni, ott fognak állni egy bugos szoftverrel, azt sem tudva hogy hol lehetne rajta javítani. Meg a hibabejelentőt is komolyabban kéne venni, aki rászánta magát, hogy szoftverüket használja, rászánta az idejét, hogy leírja és jelentse a hibát, ezt illene jobban meghálálni.
-
Frawly
veterán
válasz
hódmaci
#59526
üzenetére
Nem, nem adott ország fejlesztőihez futnak be, hanem egy központi hibakezelő oldalra (bugtracker) vagy fórumra. Az angolt meg azért követelik meg, mert eleve a fejlesztők is angolul kommunikálnak, mert azt mindegyikük érti. Függetlenül attól, hogy a többségük eleve nem angol anyanyelvű. Ettől függetlenül, ha találsz magyar Mint fejlesztőt vagy karbantartót, megírhatod neki a hibát, hátha ő nyit róla hibajegyet. Esetleg a magyar Linux Mint fórumon jelezd. Ezzel nem a magyarokat akarják kiközösíteni, csak kicsi nyelv, és kevesen értik.
Ahogy nézem, a Mintnél macerás hibát jelenteni, mert minden csomagnál, komponensnél máshol kell a hibát jelenteni, az Ubuntuból jövő csomagokkal kapcsolatos hibát, pl. az Ubuntu bugtrackerén kell jelenteni, a Cinnamonnal kapcsolatos hibát annak a bugtrackerén, stb..
-
Frawly
veterán
válasz
ubyegon2
#59508
üzenetére
Igen, nem ismerem annyira, egy ideje nem használom. Múltkor még nem írtad, hogy van benne. Ezek szerint van, de minek, ha semmit nem lehet rajta állítani, legalább egy pythonos GUI felületet összedobhattak volna neki néhány főbb opcióval, különösen a vsync miatt, hogy abszolút kezdő szerencsétlenek ne csak szörnyülködjenek, hogy miért csíkoz a kép görgetés közben meg videólejátszás alatt.
-
Frawly
veterán
válasz
Apollyon
#59505
üzenetére
Ez ilyen műfaj. Még ESR-rel ki lehet húzni FF-szal, de nem érdemes, mert csak halogatod az elkerülhetetlent. Nem csak Pulseaudio terén, de ugyanez igaz az NPAPI támogatásra is. Jobb előbb ezt elfogadni, mint halogatva nem tudom meddig szívni vele, meg bebetonozódni régi verziókba. De nem csak a Pulseaudioval van így, hanem a systemd, Catalyst, egyéb zárt driverekkel is ez a helyzet. Elhiszem, hogy sokan nem örülnek ennek, de a linuxos világ nem a konzervativizmusról híres. Bizony fejlődés van, haladni kell a trendekkel, lehet persze széllel szemben is hugyozni, de elég kimerítő lesz, és erősen kérdőjeles, hogy megéri-e.
-
Frawly
veterán
Én sem flame-ből említettem meg. Ahogy már írtam, inkább csak azért szoktam a hátrányairól írni, mert sokan még mindig kultuszból tisztelik a Debiant. Ennyi. Tőlem aztán használja, aki akarja, azért van sokféleség a linuxos világban, hogy mindenki azt használhasson, amit akar, de én továbbra is ellenjavallani fogom kezdőknek, gamereknek, meg olyanoknak, akiknek friss verziókra van szüksége valami grafikus, multimédiás, netes technológia használata miatt. Mikrobi kollégánál sem azt találtam gondnak, hogy dobta az Archot, és visszament Debianra, hanem eléggé elhamarkodta szerintem a döntést, a váltás indoka volt elég mondvacsinált.
Archot sem akarom felmagasztalni, megvannak annak is a hiányosságai. Nem vagyok a marketingesük, meg kultuszt sem akarok köré. Általában azért dicsérem, mert tényleg aranyat ér benne a friss csomagkínálat és a rolling frissítési mechanizmus, de ez nem csak az Archnál említhető előnyként, hanem bármilyen frissességre törekvő rolling disztróra igaz. Lehetne említeni a Voidot és társait, de a maga félrolling módján még a Fedorát is ide sorolnám.
Júbájgön is azt nem érti, hogy nem a Cinmanót akarom bántani, mert a maga idejében tényleg jó volt, de valahogy elakadt a fejlődésben, és a mai napig nem tudtak pl. egy kompozitort default belerakni, normálisan kidrótozott GUI-beállításokkal, emiatt én kezdőknek elkezdtem nem ajánlani. Ezt meg ő mindig szentségtörésnek éli meg, hogy miért agitálok a szent Cinmanó ellen. Pedig a DE-k között továbbra sem tartom rossznak, csak már nem tartom ajánlhatónak, főleg nem nagyon kezdőknek.
-
Frawly
veterán
Nem, nem akarom lehúzni a Debiant. Sokáig volt etalon, míg a többi kisebb disztró még akkoriban amatőr és béna volt. Viszont változnak az idők, nagyon stabilak már a kisebb disztrók is, nagyon feljöttek használhatóságban, csomagszámban, megbízhatóságban, sokszor felhasználóbarátságban is, és adott esetben már többet nyújtanak. Már az Ubuntut és a Mintet is kezdik leszorítani. Inkább fogalmaznék úgy, hogy a Debiant ma már sokan inkább egyfajta tradicionális hitvallásból tisztelik, és magasabbra magasztalják annál, mint ami a tényleges szintje a mai disztrók között. A distroupgrade beborulását sem csak a Debian ellenében lehet megemlíteni, hanem bármilyen nem rolling disztrónál így van, az mindig kényes, nem garantálható a sikeressége.
Abban igazad van, hogy Archon kevesebb a csomag, ezért többször kell AUR-ozni, ezt írtam én is, hogy ez egyetlen hátránya ennek a disztrónak. Viszont az AUR-ból telepítés is általában sima a legtöbb esetben, én sem szeretek onnan telepíteni, de annyira nem rémálom, mint sok ember tartja.
Catalystnak sem vagyok ellene, sokáig az nyújtotta AMD-ATi-n a legjobb teljesítményt, de az AMD is belátta, hogy nehézkesen szögelik, a zárt forráskód csak kolonc az opensource világ nyakán, így már ők is a nyílt driverre koncentrálnak, így jobban lépést tartanak az új csomagverziókkal. Az meglehet, hogy már jó ideje Debianon sem támogatott. Meg ahol még támogatott, ott is Xorg alatt, Wayland semmit nem tud vele mit kezdeni, meg olyan új technológiák sem, mint a Vulkan. Ragaszkodni persze lehet a régi, megszokott dolgokhoz, csak sokszor az értelme kérdőjelezhető meg.
-
Frawly
veterán
Ja, végül is Debian alatt is mindent meg lehet csinálni ugyanolyanra. Épp úgy fel lehet építeni az alapoktól minimum netinstallból. Csak sokkal régebbi lesz az összes csomag, ez a fő különbség. Meg nem lesz rolling, hanem neked kell disztrót upgrade-elned. Ami vagy bedől, vagy bedől előbb-utóbb. De amíg nem, addig megy. Stabilan. Csak friss szoftverre (Wine, mesa, Kodi, stb. egyik új funkcióját próbálnád ki) ne legyen szükséged, mert nem fogod tudni feltenni. Legfeljebb SID-ből. Oh, wait, akkor meg miért nem inkább mégis Arch? Legfeljebb regexpezed máshogy a csomagkezelőt, meg nem teszel föl meg szedegetsz le kazal csomagot egyszerre, ha mégis, akkor uninstall előtt az Arch topikban érdeklődsz, mi nem megy, mi az, amit próbáltál. Egyébként komolyan mondom, ha értesz hozzá, mindegy milyen disztrót használsz, mert amit egyikkel meg tudsz csinálni, azt a másikkal is meg tudod. Különbség csak preferencia terén lesz, milyen alapfrissességet akarsz, milyen frissítési mechanizmust, milyen csomagkezelőt, és hogy mennyit akarsz vele dolgozni, mennyire akarod részletesen testre szabni. Ezért szoktam mindenkit lebeszélni, hogy túl vadul próbálgasson ezerféle disztrót, meg fent legyen 20 multibootban. Inkább érdemes egy nagyobb disztrót feltenni, és megtanulni azon megoldani az összes problémát, akármilyen kínkeserves is. Kezdőbb linuxosoknak szokott lenni egy korai korszaka, mikor mindent kipróbálnak. Olvas valami Nevenincs Ezoterikus disztróról (ami tipikusan egy nagyobb disztró ronggyá forkolt kistestvére, sokkal kevesebb ember van mögötte, így a fejlesztéssel, bugok javításával, kiadásokkal is sokkal lassabban haladnak), már pattintja is fel, mert az hátha majd viszi a Wi-Fit, meg a KataLányIstot. És lehet vinni is fogja. A következő kiadásig. Meg addig is csak időt nyer, mert nem fogja tudni miért kezdtek el működni dolgok, meg hogyan lehetne működésre bírni őket más disztrók alatt. Amikor már ebben az Egzotikus disztróban is elakad, mert valami eltörik, akkor átnyergel majd másik random disztróra, amivel más nyűgök lesznek előbb-utóbb.
Ezért írtam Archot is csodatelepítőszkriptek nélkül teszünk fel. Igen szopó, ha nem mennek dolgok, lehet először vért fog hugyozni az illető. De ahogy halad lépésről-lépésre, csomagról konfigfájlra, úgy fogja látni mi hogy kezd el működni, így ha később elszaródik, tudni fogja hogy kell megoldani, hová kell nyúlni. Míg szkripttel telepítve nem fogja érteni, hogy mi került fel, mi miért működik, meg mi miért kezd el nem működni. Akkor meg jön a sírás, hogy ő ezt a szart nem, ennyi ideje neki nincs, neki van élete, visszateszi inkább az Ubuntut vagy a Windowst. Azokkal lehet boldog is lesz. Amíg minden megy. De egyszer csak ott is lesz valami probléma, amit el kell hárítani.
Valaki írta a HUP-on, és nagyon igaz, hogy a Linux nincs ingyen. Valódi pénz helyett idővel fizetsz, tanulópénzt fizetsz, meredek a tanulási nehézsége. Bele kell tenni az időd, energiát, hogy élvezni tudd az előnyeit. Türelem kell, sok utánaolvasás, de megéri, mert utána a saját rendszered ura vagy. Nem kell valami multira várnod, míg egy hiba elhárítódik, frissítés megjelenik, valamit támogatni szíveskednek, meg nem vagy a kényük-kedvüknek kitéve, hogy eldöntik helyetted neked mi lesz a jó, mit futtathatsz a gépen, hány példányban, milyen korlátozásokkal. Aztán ott hőbörögnek a fórumon, hogy szemét MS, megszüntetett valami funkciót egy frissítéssel, meg mi az hogy telemetriával figyel meg, meg visszamászik a Candy Crush. Közben meg van egy másik rendszer, amit használva tehetnének ellene, hogy ilyet el se játszhassanak velük, de abba meg időt kell ölni, nem rakják nekik össze, nem rágják a szájukba.
Egyébként megértem, hogy csábító a Debian, azt sokan jobban ismerik. Régebb óta jelen van, jobban van dokumentálva. A régi csomagverziók miatt a Catalyst sem lesz problémás, nem fognak neki bezavarni. De a Catalyst halott, előbb-utóbb nem úszod meg, hogy dobjad, ha más nem, majd egy Debian-frissítésnél, amit nem fogsz tudni a végetlenségig halogatni. Szóval csak a Catalyst meg csak x dolog miatt nem nagyon éri meg disztrót váltani.
-
#59396
Frawly
veterán
norbert400
#59395
Frawly
veterán
válasz
norbert400
#59395
üzenetére
Elvileg nem oszt semmit sehová, ha kézi particionálást választasz telepítéskor, akkor felhoz egy partíciókezelőt, ahol te alakítod ki a partíciót, meg megmondhatod, hogy melyikre mi kerüljön.
-
#59394
Frawly
veterán
norbert400
#59393
Frawly
veterán
válasz
norbert400
#59393
üzenetére
Ezt csak újratelepítéssel tudod megoldani, meg ez nem a partíciós táblád. Az SSD-t szándékosan osztottad ketté? Ami egyébként jó ötlet, én úgy csinálnám, hogy az SSD-n a rendszernek min. 20 GB-ot adnék, ezt a telepítőben / (root) gyanánt csatolnám (8 giga elég kevés egy komplett, felhasználóbarát disztrónak, ami egy csomó előretelepített csomaggal jön), a fennmaradó részére is egy ext4 partíció, ezt /home-ként csatolnám. A HDD-t meg egyben particionálnám. Az eseted elég könnyű, mert ahogy nézem se EFI partíció, se Windows, se semmi más nem zavar be. Arra kell még figyelni, hogy a rendszerbetöltő helyének a telepítőben /dev/sda formájában add meg, nehogy valami szám kerüljön mögé.
-
Frawly
veterán
válasz
lev258
#59388
üzenetére
De Manjaróról volt szó, ami nem Arch, csak az alapja Arch. Inkább úgy mondanám, hogy aki kézileg telepítette az Archot (nem szkripttel trükközte ki), és be is lakta, az jó eséllyel többet tud a Linuxról, mint egy ubuntus. De nem jelenthető ki biztosra. Gányoló felhasználók minden disztrónál vannak, aki gányolni akar, az gányolni is fog akármin, nem lehet megakadályozni.
-
Frawly
veterán
Ja, úgy megy vele, hogy csak na. Amíg megy. Mert aztán nem megy majd egyszer csak. Mert egy frissítés eltöri. Már az AMD sem támogatja Linux alatt a Catalystot. Meg ezért nem éri meg semmilyen zárt drivert használni, egy ponton túl gátja lesz annak, hogy a rendszer frissüljön, pont ezért preferálja a Windowson és Macen kívüli világ a nyílt forráskódot.
-
Frawly
veterán
válasz
ubyegon2
#59330
üzenetére
Csak hogy tudd, a Win7, Win8, Win8.1, Win10 minden verziója tud EFI partíció nélkül is települni BIOS MBR boottal. Tehát ezeknél sem kötelező. Valószínű a kollégánál azért EFI-vel települt, mert a BIOS-ában a UEFI + Legacy boot van beállítva, a gép először az EFI bootot próbálja meg, és a modern OS telepítők is általában dual módban vannak összeállítva, így tud EFI boottal is indulni, és akkor abban is települ.
Mondjuk engem anno a Rufus megszopatott mocskosul, mikor a játékos gépre Win10-et telepítettem. Megadtam a Rufusnak, hogy UEFI boothoz írja ki a lemezképet, aztán hozzáadtam a tényleges .iso-t. Na, ez hiba volt, mert nem vettem észre, hogy ahogy hozzáadom a lemezképet, utána magától visszanyomja default BIOS MBR bootra, és még egyszer át kell állítani. Kétszer egymás után szivatott meg, mire rájöttem a trükkre.
Ráadásul Xfce-vel meg twm-mel nyomja minimalistán, majdnem csak terminált használ, mellette csak egy szintén minimalista videórögzítő szoftvert (azt sem túl magas felbontáson) meg egy max. 1-2 gigás emulátoros környezetet (simh-ban OpenVMS és egyéb legacy rendszert, azt is csak teszt erejéig). Pedig nem is tűnik idiótának, fejből vágott mindenféle OpenVMS-ses, solarisos meg ultrixes parancsokat, nem bénázott, elég veteránnak néz ki. Lehet valami régi rossz beidegződés, amit még kicsi memóriás gépek korszakában szokott meg, mikor a RAM felét adta swapnak automatikusan, különben nehogy instabillá váljon a rendszer. Vagy valami telepítő oldotta meg neki így automatán, amit azért kétlek. Teljesen megértem, igaz, hogy a 16 gigát sem tudom kihasználni az enyémben, de állandóan rettegnék, hogy 32-ből bármelyik másodpercben kifuthatok 
Bár ki tudja, lehet van pár tera tárhelye, és poénból tett be swapot, „ezt használd öcsém, ne anyád kenyérpirítóját” felkiáltással. Sose tudni 
Ú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!
- Kaspersky, McAfee, Norton, Avast és egyéb vírusírtó licencek a legolcsóbban, egyenesen a gyártóktól!
- Bitdefender Total Security 3év/3eszköz! - Tökéletes védelem, Most kedvező áron!
- Windows 10 11 Pro Office 19 21 Pro Plus Retail kulcs 1 PC Mac AKCIÓ! Automatikus 0-24
- Sea of Thieves Premium Edition és Egyéb Játékkulcsok.
- Antivírus szoftverek, VPN
- ÁRGARANCIA!Épített KomPhone Ryzen 7 5700X 16/32/64GB RAM RX 7600 8GB GAMER PC termékbeszámítással
- ÁRGARANCIA! Épített KomPhone Ryzen 7 9800X3D 32/64GB RAM RTX 5070 12GB GAMER PC termékbeszámítással
- Telefon felvásárlás!! Samsung Galaxy A16, Samsung Galaxy A26, Samsung Galaxy A36, Samsung Galaxy A56
- BESZÁMÍTÁS! Microsoft XBOX One S 1TB lemezes játékkonzol garanciával hibátlan működéssel
- BESZÁMÍTÁS! Intel Core i9 9900KF 8 mag 16 szál processzor garanciával hibátlan működéssel
Állásajánlatok
Cég: PC Trade Systems Kft.
Város: Szeged
Cég: Promenade Publishing House Kft.
Város: Budapest