- sziku69: Szólánc.
- sziku69: Fűzzük össze a szavakat :)
- Luck Dragon: Asszociációs játék. :)
- D1Rect: Nagy "hülyétkapokazapróktól" topik
- eBay-es kütyük kis pénzért
- Fogkefe: elektromos vagy manuális?
- gban: Ingyen kellene, de tegnapra
- Lalikiraly: Astra kalandok @ Harmadik rész
- hdanesz: 50. Debrecen Nagydíj - nemzetközi salakmotorverseny - életemben másodjára
- Magga: PLEX: multimédia az egész lakásban
-
LOGOUT
Arch Linux topik
Új hozzászólás Aktív témák
-
Shyciii
veterán
válasz
vargalex
#6699
üzenetére
Sok nagyválalati program (pl bérszámfejtő közép és nagycégeknek) elég sok táblába kell széthúzni, ha azt akarod, hogy áttekinthető legyen, könnyen lehessen riportolni, és relatíve gyors legyen. Nyilván 100 tábla helyett lehetne 10 is, mert 1-2-be összevonod, viszont akkor egy hulladék lassú lesz a program. Így is szükséges módosítgatni, mert olyan cégek (ha már bérszámfejtés), amik 8000 munakvállalót kezelnek, azért ott egy-egy lekérdezés nem pér másodperc még így sem. Az már más kérdés, hogy ekkora mennyiség esetén már nem az SQL lenne jó választás, de erre már nincs ráhatásom. Ez van, ezt kell "szeretnem".
-
-
Shyciii
veterán
válasz
vargalex
#6697
üzenetére
Pedig nem. Többszörösen egymásbaágyazott IF függvények a saját script programhoz. Eredendően egy sorba írták (így is hosszúak az xml scriptek, hátha még mindegyiket egy sorra bontják ki), szal nekem mindenképp kell az, hogy ne kelljen folyamatosan scrolloznom.
HeidiSQL-ben meg nem szimpla lekérdezések vannak, úgyhogy az megint bukta. Olyan adatbázisokba kell belenyúlnom, amiben több 10000db tábla van... -
vargalex
félisten
válasz
Shyciii
#6696
üzenetére
Persze, nálunk is hazahozhatta mindenki a munkaeszközeit. Ezzel nincs gond. Nyilván kényelmesebb a nagyobb monitor, de nem létszükséglet. Volt olyan fejlesztő kollégám, aki még a külső monitort sem használta.
Viszont az XML egy sorában 400 karekterből bármilyen beágyazás esetén (normális formázás mellett) a töredéke információ, a többi csak tab... -
Shyciii
veterán
válasz
vargalex
#6695
üzenetére
Persze, el lehet. Sőt 13,3"-os kijelzőn is, csak épp a hatékony használattól távol van. Itt mindenki hazavihetett egy monitort magával.
Nálam csak a HeidiSQL programnak muszáj teljes kijelzőn mennie, mert különben az információk felét sem látom amire szükségem van, és akkor még nem beszéltem az XML kódról amit kezelnem kell, amik esetén egy sorban nem 20 karakter van, hanem sokszor 400 felett a sok egymásbaágyazás miatt. Nah ezt több sorba tördelve hogy megjelenjen kis ablakba baromi zavaró. -
Shyciii
veterán
El kell keserítselek, de hiába nézem közelebrről a 15"-os kijelzőt (kb 20cm csak), mégis iszonyat nagy különbség van 23" és 15" között. Egyébként kipróbáltam anno milyen az, hogy ha csak kettő programmal osztom el a kijelzőt. Erre felprogramoztam az Openbox-ot, és borzalmasan kicsi a tartalom megjelenítése elfelezve. Még egy terminal-nak nem gond, de egy Sublime-ban mikor szöveget szerkesztek, vagy kódot írok, vagy böngésző, vagy vnc, rdp, double commander, ezek mind kicsik már oda, és nem látható elég tartalom, szal továbbra is úgy tartom, hogy 15" baromi kicsi tiling-ra. Ha a felbontást emelem 2k-ra, akkor meg olyan kicsik a betűk, hogy meg lehet vakulni, szal megint semmit nem ér az egész. És kizártnak tartom, hogy van olyan fejlesztő, aki 15, 17"-on programozik úgy, hogy osztozik még 2-3 programmal. Az előző cégnél ahol dolgoztunk is a fejlesztőknek 2db 23"-os monitorjuk volt, mert a 22"-t kevésnek tartották úgy hogy Visual Studio-t használtak javarészt, meg páran Borland Delphi-t. A mostani cégnél Node.js-et használnak a fejlesztők, és mint ahogy nekem is 2db 23"-os monitorjuk van ugyanúgy 2k-s felbontással.
-
Shyciii
veterán
Frawly
Hát én több témát is rányomtam anno, de soha nem tudott olyan szépen kinézni, mint egy KDE, vagy Gnome. Mindig valahogy jobban megnézve nem volt szép, valahogy tákoltnak nézett ki az egész. Nem csak felbontás-függő, hogy tillingnak van értelme. Cseszhetem 2k-s felbontást, ha csak 15" vagy 17"-os kijelzőt használok (ugyebár notebook). EKkora kijelzőkön ilyen felbontáson semmit sem lehet látni. Tillingnak 20"-tól van értelme. Melóhelyen 2db 23"-os monitoron dolgozom. No ott már lenne értelme, de bent Windows 10-en kell dolgoznom
SiriusbNe engedj a csábító kísértésnek
Amúgy az elején én is mellette belekóstoltam vagy újra a kde-be, vagy manjaro-openbox, de 2 nap se keleltt hogy rájöjjek, hogy baromság. Amit belaktam Arch+Openbox+polybar+scriptek az annyira tökéeltesen fut, és hatákonyan használható, hog minden más túlsúlyos ehhez. Vagy ha még könnyebb lenne, mert a végletekig a legcsupaszított progit akarom használni (pl képnézőhöz feh), akkor meg már kényelmetlen lesz a használata, vagyis a ló túloldalára csúszok át. -
-
Frawly
veterán
válasz
Shyciii
#6688
üzenetére
Az Xfce-t fel lehet témázni szépre, de akkor nem lesz lightweight. Főleg azóta nem, hogy Gtk3-ra álltak át. A Gnome-ról írtakkal maximálisan egyetértek.
Tilingnak lenne értelme laptopon is. Csak akkor nincs értelme tilingozni, ha kicsi felbontást használsz, vagy kevés terminálos alkalmazást, vagy nem tudod jól kezelni a billentyűzetet, állandóan le kell nézni, idegenkedik valaki tőle. Min. FullHD felbontástól van értelme, olyan embereknek, akik majdnem csak kizárólag terminálos alkalmazásokat használnak, és billentyűzetkezelésük is vagy haladó, vagy tudnak gépírni. Annak, aki kis felbontást használ, ilyen 1366×768, 1280×720, 1280×800, vagy ezek alatt, annak nem nagyon ajánlom, hacsak nem szereti a mikroszkopikus méretű fontokat. Az 1400×900 határeset lehet. Meg annak nem jó még a tiling, aki ilyen GIMP, Darktable, Blender, KDEnlive, Davinci, meg ahhoz hasonló, nagyon GUI heavy programokat használ, ahol 8 ablak, 20 toolbar, 100 ikonnal, tele párbeszédablakokkal, ezt a helyzetet nem szokták a tiling WM-ek jól lekezelni.
Ami a kolléga problémáját érinti, hogy bizonyos mappákat ki akart zárni a fájlkezelőből, doksik megnyitásánál: én ezt fzf-t használó Bash scripttel oldom meg, ami vim-ben nyitogatja a doksikat, erőforrásigénye is 0. Ez WM független, megy bármilyen grafikus felületen, nem kell ilyen mime-akármikkel szenvedni, meg 1000 GUI-s szemét között kibogozni, hogy melyik lehet a hunyó.
-
Shyciii
veterán
válasz
Siriusb
#6687
üzenetére
Többek között ilyesmi esetek miatt hagytam ott a KDE-t. Gnome-ot mert borzalmasan lassú volt és kevés beállítási lehetőség. XFCE-t témázva is randa, és egyáltalán nem olyan gyors ahhoz képest, hogy light. Nah ezután akadtam a szemem elé a WM rendszerek. Abból a Tilingot rögtön kilőttem, mert egy notebookon nincs értelme, de Openbox, Fluxbox és társai már tetszetősek voltak. Openbox kapásból nyert ahogy átolvastam ezeket, és néztem a konfig fájljaikat. Azóta sem bántam meg, és még csak kósza ötletként sem merül fel, hogy visszamenjek másra
-
Siriusb
veterán
Végigtúrtam a konfig fájlokat, a netet is, nem találtam megoldást, miért hozza a feketelistás találatokat. Kilőttem többször is a krunner-t, volt balooctl purge, stb, semmi. Kíváncsiságból újraindítottam az X-et, így jó lett.
Tiszta MS életérzés fogott el...(#6684) BoB
Ez jó tipp, kösz!
Az még elég röhejes, hogy a krunner-ből ha a fájlt tartalmazó könyvtárat nyitom meg, azt a Nemo-ban teszi, nem a Dolphin-ban, na de mit akarok már?! -
BoB
Topikgazda
válasz
Siriusb
#6682
üzenetére
A krunner file location problémára most hirtelen workaround jutott eszembe, mégpedig a custom window rule.
Be lehet állítani hogy mekkora legyen a krunner ablak, és beállítod jó szélesre, a fájl nevek mellett lehet látni az elérési útvonalat, mert amúgy mutatja csak nem fér ki olyan kicsi az ablak alapból (nem mindet mondjuk de ha fölé viszed az egeret akkor igen).
-
Siriusb
veterán
Napok óta használom a KDE-t, jobbára még tetszik is, de van pár dolog, amitől sikítófrászt kapok. Pl. eddig Synapse-t használtam a gyors fájlmegnyitásra, szépen be volt állítva, hogy a keresésben milyen könyvtárakat hagyjon ki. Krunner-ben ezt nem tudom megtenni, mert olyan könyvtárakból (pl. backup) is ad találatot, ahonnan nem kéne, s persze az elérési utat nem lehet látni rendesen, mert levágja, csak ugyanaz a fájlnév szerepel többször egymás alatt. Összes plugin letiltva, baloosearch terminálban jól hozza a találatokat, de krunner nem.
Előbb-utóbb tényleg az lesz - ismét -, hogy openbox-szal nulláról felépítem magamnak az egészet és akkor minden úgy fog működni, ahogy én akarom.
-
BoB
Topikgazda
válasz
Blasius
#6679
üzenetére
Igen valószínű hogy az 1.20.X verziók mind használhatóak lesznek, viszont az a driver kernel-ből is csak az 5.4-ig jó, úgyhogy abból az lts-t kell használnod.
xorg statikusan addig fog működni amíg nem fog kellen más fontos dolgokhoz a frisebb verzió, mert akkor már nem fogod tudni telepíteni vagy frissíteni azt sem. Egy darabig mondjuk szerintem el fog menni.
-
Blasius
tag
Sziasztok,
GT2xx-éra nvidia kártyák használatára mi mostanság a bevett gyakorlat? Az nvidia-340xx meghajtó ha jól tudom 2019 decemberig támogatta ezt a sorozatot. Addig nagyjából jó is volt a zárt meghajtó, végülis elég jól működött.
Az arch wikin azt írják hogy a régi driver(340xx) 1.20 xorgig használható. Ez vajon azt jelenti hogy 1.20.7-1, 1.20.8, stb. is használható lesz, és csak mondjuk 1.21 nél lesz csak probléma? Szerintetek jól járok ha az xorg-server csomagot csak egyszerűen nem frissítem (letiltom a pacman.conf -ban), vagy lehet ennek valamilyen káros következménye? Például vdpau gyorsítás nem működik vagy hasonlóak.
Kipróbáltam a nouveau meghajtót is ehhez a kártyához, de az kritikán aluli: suspend nem megy, szemetel, lefagy. Egyenlőre még nem nőtt fel a feladathoz... (amd vonalon viszont a nyílt meghajtó a tapasztalataim szerint elég jó. Ha a nouveau hozná azt a minőséget akkor átállnék.)
Üdv
-
Shyciii
veterán
Épp írni akartam, hogy a config fileban alapból 3-as van beállítva a scrollozásra. 1-esre téve "normális"
De ez nekem a 0.4.1-2-esen is van. Nekem az Alacritty 10MB-al növeli a memóriafogyasztást, míg a Termite 5MB-al. Igen a termite valamiért nincs a többi nem Arch alapú distro-ban, és nem értem, hogy miért. Luke Smith-t anno néztem, meg régebben az suckless terminal-t is. Az ő verziójában mi a baj a színekkel? -
Frawly
veterán
Mégis tud scrollozni az Alacritty rendesen, csak nincs beállítva rá gyárilag a keybind. Sőt, a 0.4.2-es verzió már Vi módot is tud. Persze erre a Void tárolóiban a 0.4.1-es a legújabb. Már sokszor írtam, hogy miért fontos a frissesség, mindig le voltam hurrogva, hogy a frissesség, bleeding edge rolling a mániám, mert bőven jók azok az ezer éves verziók, amik Mintben, Ubuntu LTS-en, Debian stable-ön vannak. Ja, tényleg mind jó. Jó régi
Az is igaz, hogy ez egy szerencsétlen véletlen is, mivel a 0.4.2 két hete lépett RC fázisba, a végleges változat meg egyetlen órája jött ki, még nem is volt kint, mikor az előző hozzászólásom írtam. Ennyire gyorsan se az Arch, se az Arch Testing, se a Fedora nem követi le, pedig bleeding edge mindegyik.
-
Frawly
veterán
válasz
Shyciii
#6674
üzenetére
Memóriafoglalásra nem vettem észre jelentős különbséget. Abban viszont egyetértek, hogy a GPU gyorsítás nem számít, mert ha a WM felett fut kompozitor vagy be van kapcsolva X.org-on a DRI hardveres gyorsítás, akkor úgyis OpenGL gyorsítani fog minden X.org-os alkalmazást, Firefox, xterm, urxvt, Termite, Alacritty.
Termite-ot én is jobban szeretem, a vim-kijelölésmód miatt. Ez az Alacrittyből hiányzik, meg a görgetése is elég primitív az utóbbinak, Ctrl+Shift+PgUp/PgDn-ra görget, és csak sok sornyit, egy soros görgetést nem találtam benne, ami gáz.
Így csábítana a Termite vissza, de Archon kívül egyik disztró tárolójában sincs meg, így fordítani kell jellemzően, és a fordításának rohadt sok függősége van. Én meg gentoo-zni akarok később, és nem akarok emiatt szívni.
Amivel most kísérletezek, az a Luke Smith által módosított st, azaz a suckless-féle Simple Terminal. Egyedül a színek nem stimmelnek, azért nem vettem még használatba.
-
Shyciii
veterán
Frawly
Kipróbáltam az Alacritty-t unalmamban. Hát...Elhiszem hogy a leggyorsabb hardveres GPU által gyorsított terminál, de én a Termite-hoz képest nem látok különbséget, de elhiszem nekik, hogy pár századmásodperccel biztos gyorsabb lehet. Viszont a memóriafoglalása 2x akkora, mint a termite-é.
-
#6673
Neil Watts
veterán
Kivalo ez a Manjaro, csak epp olyan problemaval talakoztam, amivel eddig soha, sehol.
Felraktam a virt-managert igy:sudo pacman -S virt-manager qemu vde2 ebtables dnsmasq bridge-utils openbsd-netcatsudo systemctl enable libvirtd.servicesudo systemctl start libvirtd.service
Megprobaltam volna letrehozni egy virtualis gepet, es csak LXC lehetosegem van, KVM nincs.
Ezt amikor probaltam, nem vettem eszre, es megprobaltam egy OS containert letrehozni.
Van egy letezo qcow2 rendszerkepem, megprobaltam azt betallozva letrehozni a cuccot.
A letrehozas vegen panaszkodott, hogy nem tudja elinditani a 'default' network interfacet, igy futtattam a: (ezt kovettem)sudo virsh net-start defaultsudo virsh net-autostart defaultde sajnos nem mukodott.
Ujrainditottam a libvirtd-t, asudo systemctl restart libvirtd-vel, aztan futtattam asudo virsh net-start defaultsudo virsh net-autostart default
aztan mukodott...
Sajnos meg mindig nem jottem ra, mit ronthatok el, mert nem tudok tovabbra sem KVM virtualis gepeket letrehozni.
Mit nezek be?
Koszi!
Udv. core2 -
Frawly
veterán
válasz
Siriusb
#6666
üzenetére
A Double Commandernek valóban volt régen a 0.7.x-es verziók vége felé, és a 0.8.x-es verziók eleje feléig, hogy néha lefagyott. Most már ezt nem tapasztalom, nyugodtan megpróbálhatod. Ez is csak a Gtk-s verziókat érintette, Qt-snél sose tapasztaltam.
Váltani én is szoktam a grafikus felületek között, ha megunok egyet. Bár egy idő után elfogy a variáció, nagy csodát egyik se tesz, valami panel, dokk, vagy menü (indítómenü vagy egész képernyős Dash-szerűség), háttérképkezelő, asztali ikonkezelő kombinációival dolgozik mindegyik, még a tilingok is, csak ott alapból nem fedik egymást az alkalmazások, ahogy stackingnél. Meg a tilingok inkább billentyűzetes irányításra gyúrnak, nem egeresre, ennek ellenére az egeret is kezelik természetesen.
Plusz a kompozitor szokott még más lenni, de ott sem tudsz végtelen variációt, áttetszőség, áttetszőség+elmosás (Aero), árnyék, esetleg egy-két 3D-s effekt (nyúlós ablakok, 3D-s virtuális desktopváltás, ablaknyitó, záródó effektek), és kifújt.
Én pl. most váltottam SwayWM-ről vissza Openboxra, de nem a megunás miatt, hanem systemd függőségének elkerülésére. Amúgy már nem várok semmit a WM-től, alkalmazásaimat megjelenítse, elég mindegyiknek full screen, ablakdekorációk nélkül, meg elég egy háttérkép, áttetsző panel, ezen kívül áttetszőség van egyedül még a terminálon. Semmi más nem kell, se dokk, se asztali ikonok, se indítómenü (arra vagy dmenu_run-t vagy rofi-t használok, esetleg fzf-et használó shell script), se 3D effektek, se semmi. Böngészőn, Steamen, meg Wine-s programon kívül grafikus progikat se futtatok, minden terminálban fut CLI/TUI alkalmazásként. Mindenhez gyorsbillentyű van rendelve, nem kattingatos sehová, semmilyen ikonra vagy menüre.
Így ha megunok valamit, akkor inkább háttérképet, színtémát, betűtípust cserélek. Ennyi is elég szokott lenni megunás ellen újabban.
-
Shyciii
veterán
Nálam pont fordítva. Én a qt-s programoktól kapok görcsöt. Töménytelen mennyiség qt-s bloatot pakolnak fel még az egyszerűek is. Az általad említett szöveges fileok szerkesztése hosszú soroktól behaló GTK-s progikkal nem találkoztam. Igaz nem gedit-et használtam, hanem Atom, és most Sublime. Ez a szövegszerkesztőm, és ezen is kódolok. Soha semmilyen lefagyás, belassulás nem volt. Atommal mondjuk az volt a gondom, hogy maga az elindulása lassú, de az a nyomorult Electron miatt van. Minden más programom is GTK-s, de sosem fagynak. Igaz én nem szerkesztek videókat. Konvertálásra meg teljesen felesleges gui-s program. Tökéletes hozzá az ffmpeg. Eleve ezzel a minimalista Arch + Openbox-al nem volt még belassulás, vagy lefagyás. Anno még mikor Manjaro-t használtam KDE-vel, majd Arch KDE-t, nah akkor volt indokolatlan mennyiségű lefagyás, belassulás. Ezért is váltottam utána Arch + XFCE-re, de az összességében nem tetszett, úgyhogy kerestem más minimalista, de jól konfigurálhatót, és így lett Openbox. Semmilyen módon nem hiányzik az akkori KDE-s szívások.
-
Siriusb
veterán
Már nem emlékszem, mi volt a nyűgöm LXDE-vel, persze az eltelt évek alatt sokat változhatott az is.
Igen, most már DE-ben gondolkozom, hogy készen kapjak mindent. Openbox-ot épp az ellenkezőjéért szerettem, gyakorlatilag én legóztam össze az egész rendszert, kiválogattam minden feladatra a nekem tetsző alkalmazást, mindent testre szabtam. Ez nem két perc volt. Most már nem szeretnék ezzel foglalkozni, bár nincs kizárva, hogy ez lesz megint a vége.
(#6669) BoB
Ez is egy probléma, hogy egy-két jó alkalmazást qt-re fejlesztenek. Kdenlive van fent nekem is, pedig az Openshot-tal is próbálkoztam.
Na, ismét adok egy esélyt a KDE-nek. -
BoB
Topikgazda
válasz
Siriusb
#6666
üzenetére
Be lehet állítani mennyi idő múlva tűnjenek el az értesítések.
Én GNOME-ról váltottam vissza KDE egész egyszerűen azért mert a gtk-s programok csak addig működnek amíg nem terheled meg egy kicsit jobban őket.
Videoszerkesztésre az összes gtk-t használó összeomlott nálam 1000+ képnél, kivéve a Kdenlive.
Nagyon hosszú sorokat tartalmazó szöveges fájl megnyitásakor lefagyott a gedit. Kate gond nélkül vitte.
Meg volt mégegy amire már nem emlékszem, de a gtk-s program szintén összeomlott míg emez nem, na akkor betelt a pohár.
-
totron
addikt
válasz
Siriusb
#6666
üzenetére
Az LXDE miért nem? Nekem sem jött be, sokáig nem, majd de. Minimalizmust emlegettél, az tudja. Azt látom, hogy a DE-ktől nem akarsz elszakadni, mégis valami másra vágysz, de nem szeretnél vesződni az egyéni összeállítással, konfigolgatással. Jó pedig, mikor magadnak rakod össze a menüt is és minden mást. Mikor html kóddal állítod a hátteret.
-
Siriusb
veterán
...Cinnamon után minden jó...
XFCE, LXDE, ezeket rövid ideig feltettem. Mondjuk az első elfogadható.
(#6663) Bici
Mi a baj? Kicsit ráuntam. Kellene valami MÁS.
Hmmm, most kicsit elgondolkoztam az xfce-n is. Régen az openbox+tint2 volt a nyerő, olyan jól be volt állítva minden, csak akkor is rámjött a változtathatnék.
Double Commandert próbáltam régebben, de állandóan lefagyott.Szerk.:
Közben eszembe jutott az egyik problémám a KDE-vel: az értesítések automatikusan törlődnek, pl. ha jelzett a Thunderbird, hogy új levél jött, az rövid időn belül eltűnt és mindig oda kellett mennem a levelezésre, hogy lássam a helyzetet, miután visszamentem a géphez. -
Ismerem a double commandert. Használom is.
Én olyan fícsörökre gondoltam, amiktől szerintem kevésbé fapad a Nemo, mint a file másolások sorba rakása, hogy pl. winyón ne lassuljon be a párhuzamoms másolástól, vagy a részletesebb megjelenítési sorrend beállítás.
Tény, hogy a DC-hez képest a Nemo is fapad.A KDE-ből biztos kihozható sokminden, de én Qt gyűlőlő lettem 6-7 év Qt5 fejlesztés után, és emiatt kicsit fázom mindentől, ami ezzel készült. 100% szubjektív defekt.
Meg az XFCE készen van, nincs értelme a KDE-ből lemásolni.A Manjaro csak amiatt jön szóba, mert Arch alapú, de kicsit lassabban frissül, és XFCE-vel alapból marha jól néz ki.
Az Arch-omat sikerült egy félresikerült kényszerű Windows installal kinyírnom, szóval az általános gépen jó lesz a Manjaro.
Ha egy évig kibírja komolyabb hiba nélkül, akkor a melós rendszeremet is visszaköltöztetem rá. -
Frawly
veterán
Szerintem az összes ilyen Intéző-szerű fájlkezelő fapad. Ha rendes grafikus fájlkezelő kell, akkor Double Commander-t tedd fel, abból is a gtk-s verzió való Xfce-hez és Cinnamonhoz. Szerintem ez a grafikus fájlkezelők non plus ultrája, az egyetlen, ami pariban van a windowsos Total Commanderrel.
Egyébként a KDE5 belőhető, hogy minden ugyanúgy nézzen ki, mint Xfce alatt. Akármilyen UI elem idegesít, le lehet cserélni, ki lehet iktatni. Lassan már erőforrásigényre is ugyanott vannak, a legújabb Xfce hízott, az egyre újabb verziói a KDE5-nek meg soványodnak (igaz butítják is), így egy szintre ér a kettő.
Persze ha elérsz majd egy még haladóbb szintet, akkor majd saját DE-t alakítasz ki WM-ből, meg valami minimalista panelből.
Ha a legcsilivilibb kell, akkor szerintem csakis KDE vagy esetleg Compiz egy jó témával. Ez a maximum, amit grafikai szépségre ki lehet hozni a Linuxból. De én már fapados WM-ekből is láttam elég szépeket, igazából nem is annyira a WM-en vagy DE-n múlik, mint inkább a háttérkép, színösszeállítás, téma és kompozitor együttesén.
Ha XFCE-t akarsz, akkor nem kell Manjaro-t telepíteni, hanem a meglévő Arch Cinnamonra egyszerűen felteszed az XFCE fullos metacsomagját és login managerben kiválasztod az XFCE-t a Cinnamon helyett, ezt is csak egyszer kell, utána megjegyzi. Az XFCE és a Cinnamon jól megfér egymás mellett, nem vesznek össze, mert mindkettő Gtk3-as.
-
válasz
Siriusb
#6660
üzenetére
Mi a baj a Cinnamonnal? Csak a minimalizmus hiánya?
Nálam XFCE van Fedorán, és Cinnamon Arch-on.
Az XFCE szerintem nagyon jó cucc.
Kevesebb pozitív (csillivilli hiánya), és kevesebb negatív (gnome3 származékként tud alkotni a Cinnamon...) élményt ad, szóval unalmasan használható, de szerintem mégis van benne valami szerethető.
Egy jó témával szerintem annyira faszán néz ki, hogy neken nincs igényem komolyabbra.
A file kezelője kicsit fapad volt elsőre a Nemo után, de idővel rájöttem, hogy nekem nem is annyira fontosak a Nemo plusz fícsörei.
Arch-on is XFCE-zni fogok hamarosan. Mégpedig Manjaro formában.Nálam a KDE kuka az old-school Windows szerű kinézet, és néhány KDE4 óta kikopni nem akaró UI elem miatt, és a Gnome3 származékok is a címsorba rakott ikonok és a megbízhatatlan extension-ök miatt.
-
Siriusb
veterán
A minimalizmus jegyében
![;]](//cdn.rios.hu/dl/s/v1.gif)
gondolkodom azon, hogy ismét bepróbálkozok a KDE-vel és lecserélem a Cinnamon-t. Milyen mostanság a KDE (gyorsaság, erőforrás zabálás, kinézet stb), vannak tapasztalatok?Gnome shell-t nem akarok, az egy annyira félresikerült vacak lett, Mate sem fogott meg. Openbox-ot meguntam pár év után, pedig arra nem szólhatok egy rossz szót sem. Tiling cuccokat nem nekem találták ki. Nem sok választásom marad.
-
Frawly
veterán
válasz
Shyciii
#6658
üzenetére
Poén lenne, de Void-hoz nincs ilyen. Egyébként meg mi használná ezt az issue fájlt? Nekem a Void ASCII logója sem tetszik neofetchben. Béna, az Arché jobb.
De a voidosoknak egyébként is jó lenne lecserélni a mostani logót, ez a két félkörben egy pötty elég béna és semmilyen, valami dizájnantitalentum tervezhette. Mondjuk egy pipa jel ötletesebb lenne: ✓vagy ✔, esetleg kicsit szögletesítve, hogy nehogy valaki Nike márkajelnek nézze. Esetleg ilyen vonalasan 3D-ben eltolt nagy V, azaz kb. \\// vagy hasonló.
-
Shyciii
veterán
Aki nem használ login manager-t, az próbálja ki az alábbiakat:
/etc/issue fileról csináljon másolatot, majd az eredeti issue file tartalmát törölje ki, és illessze be ezt: https://pastebin.com/DK8haFBt
-
#6657
Frawly
veterán
Neil Watts
#6656
Frawly
veterán
válasz
Neil Watts
#6656
üzenetére
Nincs mit, örülök, hogy sikerült. Pont ezért is kérdeztem rá az fdisk kimenetére, mert ezek a blockdev --getalignoff megoldások nem megbízhatóak. Bonyásak is, meg nem tudni mit ellenőriz pontosan, meg hogyan. A legbiztosabb, ha az ember fdisk kimenete alapján saját maga meggyőződik, hogy a partíciók kezdő szektora 512 bájtos szektorbeállításnál 2048-cal osztható-e. A linuxos és modern windowsos particionálóprogik eleve úgy csinálják, hogy osztható, de az ördög sose alszik. Persze az is elég, ha 32-vel osztható (16K-s alignálás), régi SSD-knél és modern HDD-knél elég, ha 8-cal osztható (4K-s alignálás).
Egyébként meg az sem baj, ha a particionálás nem stimmel mondjuk egy EFI vagy boot partíción, mert oda nem történik sok írás, olvasás. De mint nálad is, a több gigás rendszerpartíció eltolása volt rossz, arra figyelni kell.
-
#6656
Neil Watts
veterán
Frawly
#6647
Szia!
A KDE Partition Manager LiveCD-rol par perc alatt megcsinalta a 3. particio igazitasat. A particiot kijelolve van egy olyan opcio, hogy "Resize/Move". Annak van egy Advanced lenyilo fule. Ott irja a szektor kezdetet es veget, meg van ott egy "align partiton" checkbox is. Ezt bepipalva mutatta (a a szektorkezdetnel az fdisk altal mutatott maradekosan oszthato ertek volt feltuntetve. Kikattintottam, majd ujra be, ekkor megvaltozott a kezdoszektor erteke - hogy megbizonyosodjak, hogy jo elosztottam az erteket magam is. Maradek nelkul megvolt, igy elmozgattam vele). Siman megcsinalta.
Koszi a segitseget!Udv. core2
-
Shyciii
veterán
LOL. Oh_my_zsh-t két dolog miatt használok csak. Az a témák, és hogy az autocompletion nem csak megjeleníti, hanem a TAB gombot nyomogatva a lehetőségek között lehet ugrálni is.
Most elkedztem olvasni a bash shell promptjáról, és bár gyorsan összeállítottam bash shell alatt is ugyanazt a promptot mint az oh my zsh bira témája adja, mindenféle plusz segéd nélkül (oh my bash, bash it). 2 sor az egész a bashrc-ben. De csak azért 2 sor, mert 2 soros promptot használtam a zsh alatt is. Ha még azt is meg tudnám oldani, hogy TAB-ra a válaszhatók között lépkedjen is, akkor egyáltalán nem lenne szükségem zsh-ra -
-
Frawly
veterán
válasz
Shyciii
#6651
üzenetére
Úgy értve a kompatiblitist, hogy elkezdesz scriptelni rá, és van pár olyan megoldása, ami normál Bash-on meg sh-n nem fog menni. Hozzászoktat ilyen nagyon baró, de spéci megoldásokhoz, és ha majd egy sima bash-os géphez kell leülnöd, akkor gondok lehetnek belőle, hogy nem mennek a zsh-n megszokott dolgaid.
-
-
Shyciii
veterán
Frawly
Te a zsh shell-ed alatt állítottál olyat, hogy a historyban ne legyen duplikáció? Találtam egy ilyen lehetőséget, de abszolút nem reagál rá. Továbbra is duplikálva kerülnek be a parancsok. Ezt használtam beírva a .zshrc -be de már a .bashrc-be is:export HISTCONTROL=ignoredups:erasedups
De probáltam csak ignoredups-al és erasedups-al is. Teljesen hatástalan. Már azon gondolkodtam, hogy zsh-ról visszaállok bash-ra, és ott is kipróbálom, mert lehet hogy csak zsh kakil rá.
-
#6647
Frawly
veterán
Neil Watts
#6646
Frawly
veterán
válasz
Neil Watts
#6646
üzenetére
A Samsung 830-ason jó a partícióeltolás. Viszont a WD Blue 3D 1 terás SSD-den az utolsó, azaz harmadik partíció eltolása nem jó, az 1808582337 kezdőszektor nem osztható sem 8, sem 16, sem ezek többszörösével. Talán a Gparted tudja javítani az eloltást, de Live rendszer alól kell csinálni, nem futhat róla a rendszer, míg a Gparted dolgozik azon a partíción.
Az normális, hogy a /dev/sdX-ek ugrálnak, minden bootkor másik meghajtó lesz sda, sdb, stb.. Ezért is kell fstab-ban meg bootmanagerekben /dev/eszköznév helyett partíció UUID-t vagy fájlrendszer UUID-t használni, az nem változik.
-
#6646
Neil Watts
veterán
Frawly
#6644
Szia!
WD WDS100T2B0A 1TB SATA SSD
fdisk -l:Disk /dev/sde: 119.25 GiB, 128035676160 bytes, 250069680 sectorsDisk model: SAMSUNG SSD 830Units: sectors of 1 * 512 = 512 bytesSector size (logical/physical): 512 bytes / 512 bytesI/O size (minimum/optimal): 512 bytes / 512 bytesDisklabel type: gptDisk identifier: C2409425-76F4-5D4F-BB91-006A5CE87158Device Start End Sectors Size Type/dev/sde1 2048 250066943 250064896 119.2G Linux filesystemDisk /dev/sda: 465.78 GiB, 500107862016 bytes, 976773168 sectorsDisk model: WDC WDS500G2B0AUnits: sectors of 1 * 512 = 512 bytesSector size (logical/physical): 512 bytes / 512 bytesI/O size (minimum/optimal): 512 bytes / 512 bytesDisklabel type: gptDisk identifier: 6125EBAE-B56E-4E10-AC20-6553DA6C9CE1Device Start End Sectors Size Type/dev/sda1 2048 976773119 976771072 465.8G Linux filesystemDisk /dev/sdc: 931.53 GiB, 1000204886016 bytes, 1953525168 sectorsDisk model: WDC WDS100T2B0AUnits: sectors of 1 * 512 = 512 bytesSector size (logical/physical): 512 bytes / 512 bytesI/O size (minimum/optimal): 512 bytes / 512 bytesDisklabel type: gptDisk identifier: E1054FD9-3426-014C-A586-245D505A59A9Device Start End Sectors Size Type/dev/sdc1 4096 618495 614400 300M EFI System/dev/sdc2 618496 1808582336 1807963841 862.1G Linux filesystem/dev/sdc3 1808582337 1953520064 144937728 69.1G Linux swapUgralnak a /dev/sdX-ek ossze-vissza az
fdisk -lkimeneteben. Ez normalis?
Udv. core2
-
Így van, itt nem arról volt szó, hogy az AMDGPU sz*r, hanem arról, hogy az Arch fejlesztőinek valószínűleg kevesebb erőforrása van az ilyen ritkább esetek kezelésére.
Persze más disztróknál is előjöhet ilyen gond, csak nálam a két szóba jövő gyorsan pörgő disztró közül a fedora volt inkább megbízható az elmúlt évek tapasztalatai alapján, és én ezért választottam azt munkára.
Míg általános használatra maradok az Arch-on. -
#6644
Frawly
veterán
Neil Watts
#6638
Frawly
veterán
válasz
Neil Watts
#6638
üzenetére
Ezek alapján minden jónak tűnik. De azért azt kéne tudni, hogy pontosan milyen SSD-kről van szó, gyártó, pontos típus.
Az alignálás valószínű rendben van, de én egy sudo fdisk -l kimenetet megnéznék a biztonság kedvéért.
-
Frawly
veterán
Én még mindig nem látom, hogy mi lenne vele a probléma. Bici esetében a laptopban lévő két GPU okozta a gondot, de ez minden disztrón, sőt, Windows alatt is szopás lehet. Tehát nem az AMD GPU-val volt a gond, hanem, hogy mindjárt kettő is van belőle! Sőt, ha Intel IGP és NV dedikált GPU van, azok között még nagyobb szívás váltani, mert zavarja egymást a kettő, meg NV-hez csak a zárt drivert lehet normálisan használni, amihez mindenféle dkms kernelmodullal kell szórakozni, ami miatt meg a kernel nem frissíthető normálisan, így összességében 100× nagyobb rémálom az 1-2 AMD GPU-s felállásnál.
Egyébként nemsokára teljes használatba veszem az asztali gépet, amit eddig csak néha használtam, akkor is csak offline windowsos játékkonzolnak, és az lesz a fő gépem, Linux is rákerül, majd megírom a tapasztalataim. Nekem egy AMD RX570 van (GCN4), ez az egyetlen GPU a gépben, elvileg vaj simán, mindenféle kernelparaméter és fekete mágiás voodoo varázslás nélkül mennie kéne első pöccre friss Arch installal, a kernelben benne lévő amdgpu driverrel, ehhez csak a linux-firmware-t kell feltenni, meg a mesa-t, és hardveres dekódoláshoz meg a libva-mesa-driver csomagot telepítve. Erre a gépre egyébként lehet Archot teszek, a systemd ellenére is, mert ezen linuxos játék is fog menni, amikkel szívás lehet systemd-mentes disztrón. Még nem teljesen döntöttem el, hogy nem mégis Gentoo lesz-e, de az Arch felé hajlok, mivel kevesebb munkával jár.
-
Shyciii
veterán
Nem lehet vele pontosan ugyanazt kialakítani, mint nekem Arch-on. Vagy ha igen, akkor olan mértékű utánajárással (4 napot szántam rá max), hogy egyszerűen nem éri meg. Arról nem beszélve, hogy kb a felét alakítottam ki debian-on mint Archon, és már több memóriát foglalt, és jócskán több csomagot pakolt fel feleslegesen. És akkor még ott az a probléma, hogy volt olyan program, amit nem találtam debianhoz, és forrásból forgatva gondjai akadtak. A GTK-s téma se működött rendesen debian alatt ugyanúgy GTK-s rendszeren természetesen. Polybar pl teljesen kuszán működött. Csomó beépített elemre nem reagált Debian alatt, mondván nem létező elem (WTF??). Szal azonnan töröltem is. Az a kombó amire én használtam volna, arra a Debian nem jó. ELhiszem hogy Debian + KDE vagy Gnome jól működik, csak olyan bloat-os rendszer nekem nem kell.
Írom mindezt úgy, hogy jelenleg a cégben csináltam egy Debian szervert, Asterisk-el, MariaDB-vel, ODBC-vel, WEBRTC-s eléréssel. Márcsak a CDR adatainak realtime átvitele van hátrea MariaDB-be. Erre még rá kell jönnöm. Erre jó a Debian, meg PHP, NginX (gondolom Apache-ra is).
-
Shyciii
veterán
Én ezért nem vettem AMD-s laptopot magán használatra (sem). Régebben, de az elmúlt időkben is a sok linuxos topicba olvasgatva továbbra is sokkal több probléma van az AMD-s GPU-kkal, mint az Intel-ekkel. Amúgy én hogy írtad megnéztem a Fedorát, illetve terveztem, aztán elkedztem olvasgatni mit, merre, hogyan, és rögtön le is tettem róla, hogy ugyanazt kialakítsam rajta, mint Arch-on, mert Fedora-n is jó sok korlátba ütköznék, mint Debian esetében.
Egyébként csak hogy Arch mennyire nem való munkára. Ugye ez otthoni magánhasználatra van ez az Arch + Openbox. Ehhez képest most ezen home office-olok probléma nélkül: OpenVPN, VNC, Telegram, Teamviewer, Zoom. Közben avi-t dekódolok mkv-be AC3-as kódolással, de volt hogy közben konvertáltam szintén parancsosors progival SACD-t nagyfelbontású FLAC-re. Semmi bajom nincs. Egyszer összeállítottam, és működik rendben. -
#6638
Neil Watts
veterán
Szia!
Bocs az offert, talan ez itt porgosebb.
Ferfiui kivancsisagtol hajtva felpakoltam a Fedora helyett egy Manjarot.
Eddig nagyon tetszik.
Az alignment is rendben van, elvileg:A
sudo blockdev --getalignoff /dev/sdasudo blockdev --getalignoff /dev/sdbsudo blockdev --getalignoff /dev/sdd
(ugrott a betujel, nem tudom miert), 0-t ad vissza, tehat a telepito jol vegezte a dolgat.Az fstab-ban a rendszer alkalmazott
discardopciokat, mind a HDD-k mind az SSD-k eseteben. Ezeket mindenhonnan eltavolitottam, mert azt olvastam, hogy ez folyamatosan TRIM-el, igy engedelyeztem az fstrim service-t./etc/fstab:
UUID=D72B-22EB /boot/efi vfat umask=0077 0 2UUID=e0f19ede-8a6c-499a-a6a1-b5f72e93cfdc / ext4 defaults,noatime 0 1UUID=6070260d-4eb6-4075-84ae-68ee25d1c35f swap swap defaults,noatime 0 2tmpfs /tmp tmpfs defaults,noatime,mode=1777 0 0# Internal HDsUUID=78254e28-4f38-490a-ad5b-c2d1e87706c3 /mnt/78254e28-4f38-490a-ad5b-c2d1e87706c3 ext4 defaults,noatime 0 0UUID=bb4fd23d-7a2e-4729-a327-4b443935324a /mnt/bb4fd23d-7a2e-4729-a327-4b443935324a ext4 defaults,noatime 0 0UUID=e10ca82f-302c-4063-91d7-6fb16e3ad4ea /mnt/e10ca82f-302c-4063-91d7-6fb16e3ad4ea ext4 defaults,noatime 0 0UUID=0a20e9a8-f876-40eb-88ad-24c17a0e1aef /mnt/0a20e9a8-f876-40eb-88ad-24c17a0e1aef ext4 defaults,noatime 0 0
sudo systemctl status fstrim.timer:● fstrim.timer - Discard unused blocks once a weekLoaded: loaded (/usr/lib/systemd/system/fstrim.timer; enabled; vendor preset: disabled)Active: active (waiting) since Sat 2020-03-21 06:32:35 CET; 15min agoTrigger: Mon 2020-03-23 00:00:00 CET; 1 day 17h leftTriggers: ● fstrim.serviceDocs: man:fstrimMar 21 06:32:35 armand-x570aoruselite systemd[1]: Started Discard unused blocks once a week.Ez igy megfelelo? :)
Van esetleg egyeb teendom?Koszi!
Udv. core2
-
Megtartottam az Arch-omat is, mert általa jobban megismerem a linuxot, de mellette ott a Fedora is, mert ha munka közben jön negy ilyen Arch-os több napos keresgélés, hogy mit kell tennem, hogy legyen kép a VGA-n, akkor az nekem sok pénzembe fog kerülni.
Sajnos, nem az első eset, hogy Arch-on napokig áll minden.
Most néhány hete két különböző is volt két különböző gépen, igaz mindkettő AMDGPU kernel paraméterekről szólt. Arch iommu és Manjaro amdgpu.dc=0 egy GCN3-as IGP-n.
Mindkettő használhatatlanná tette az adott gépet, és mindkettő működött Fedorával és Ubuntuval is.
Évekkel ezelött is volt hasonló eset, és ott is meglett a megoldás pár nap/hét alatt.
Hobbi célra ez tökéletes, de munkára szerintem nem.Valószínű, hogy egy gyakorlottabb júzernek ez sdokkal kevésbé probléma. Én most csak magamról beszélek, általánosítani nem célom.
És ne értsd félre, nem szidom az Arch-ot inkább építő céllal írtam le ezeket. Remélem, nem az ellenkezője érződik.
-
Frawly
veterán
Jó, te tudod. Nyilván azt használsz, amit akarsz, nem mi szabjuk meg. De ha már egyszer Archon megfejtetted a hiba okát, akkor nem sok értelmét látom fedorázni. Egyébként az Arch ilyen, egyszer kell szívni vele, kiismered rajta a dolgokat, utána viszont kézreáll, kezesbárány, gondod nem lesz vele többet, legalábbis nem lényegi, meg semmi olyan, amit ne tanulnál meg egyszerűen megoldani. Emiatt bőven megéri bele időt feccölni, hosszú távon bőven meghálálja magát.
Ezzel szemben kiadás alapú és félrolling disztróknál minden kiadásban mást csesznek el, és mindig teljesen új felállással szívhatsz, sose tudod mire számíts.
Fedorán egyébként azért nem volt gondod ezzel, mert ott beletesznek mindenféle csomagot, meg kernelparamétert, és ugyan ez az esetek nagyobb részében kényelmesnek tűnhet, viszont sokkal bloatabbá is teszi a rendszert. Archon ezzel szemben minimalista vonalon építkezés a cél.
-
Azonos gépre feltettem egy Fedorát, mert fontos munkák jönnek mától, és Arch vonalon volt több AMDGPU-s gond is.
A Fedora egyből beteszi a kernel paraméterek közé azt a két iommu kapcsolót.
Azt is megtudtam, hogy csak azért van nálam szükség ezen kapcsolókra, mert két AMD GPU van a gépben.A tanulság, hogy ha gond van Archon, akkor érdemes Fedorával tenni egy próbát, és ha valaki ragaszkodik az Arch-hoz valami miatt, akkor átmásolni a Fedora működését.
A Fedora csapatának gondolom sokkal több kapacitása van az ilyen ritkább (két AMD GPU) esetek tesztelésére, kivizsgálására is. -
-
Frawly
veterán
válasz
Shyciii
#6628
üzenetére
Voidot nem használom még régóta. Nem rossz, használható, de az Arch szerintem lényegesen jobb disztró. Én csak azért váltottam, hogy a systemd-t elkerüljem. Ha nem zavar a systemd, mindenképp Archon maradj.
(#6629) Siriusb: ez LVM over LUKS vagy fordítva? Ilyen felállásban ez egyszerű módon nem oldható meg. Én úgy csinálnám, hogy a cél SSD-n létrehoznám a boot partíciót, meg a LUKS partíciót, LVM-mel. Létrehoznám rajta a logikai köteteket meg azon a fájlrendszereket is, és fel is csatolnám. Meg felcsatolnám a régi SSD-n is a fájlrendszereket. Majd egyszerű fájlmásolással mindent átvinnék a két SSD között, fájlrendszerenként. A végén meg az új SSD-n az Arch indulásához módosítani kell a fájlrendszer vagy partíció UUID-it. Lehet van ennél egyszerűbb megoldás, amit nem ismerek.
-
Siriusb
veterán
Költöztetnék egy rendszert SSD-ről egy másikra. Adott egy EFi partíció, egy sima boot partíció, valamint még egy luks partíció lvm-mel megfejelve.
Arra gondoltam - mivel mehet offline az egész -, hogy létrehozom az új meghajtón a 3 partíciót és fájlrendszert (a régitől eltérő méretekkel), EFI és boot sima másolással átmegy. Luks partíciót létrehozom manuálisan, majd dd-vel a luks-ra rámásolom az lvm-et, ami feltételezésem szerint az lvm header-t is viszi, tehát egyszerű lesz az átméretezés. Ezután csak a grub telepítés marad.Vagy hozzak létre az új meghajtón PV-t (pvcreate), adjam hozzá a már létező volume group-hoz, mozgassam át logical volume-okat és válasszam le a régi meghajtót?
Lvm-mel sajnos csak annyi a tapasztalatom, hogy egyszer használtam már. -
Shyciii
veterán
Archon nekem ez 211MB kb megfelelő, mert én programok kipróbálásához mindig ezt a rendszert használtam, és bér -Rs -el szedtem le utána a progikat, de ahogy figyeltem így is marad valamennyi szemét. No meg nekem ilyen unikum cuccok is vannak, hogy flac fileok splittelése, sacd iso file-ok darabolása flac-be, szal nem mindennapi progik. Annyira nem szokványosak, hogy ezek sem gui-s felületűek
Valszeg ha full újrahúznám a rendszert, akkor már kevesebbet foglalna.
Uby sok mindent képtelen volt felfogni. Debian tőlem mehet, de csak a legminimálabb telepítővel, és a szükséges cuccokkal, mint pl php, mariadb, nginx. Akkor érzem a létjogosultságát, de amúgy nem. És most az is kiderült, hogy az sem teljesen igaz, hog az ember mindegy milyen linuxot telepít, mert utána a programokkal ugyanúgy testreszabhatja, ugyanazt kapja. Hát ez így most látszott, hogy nem. Amúgy ez nem nekem készült volna. Egyik haveromnak megtetszett az enyém puritánsága, de ő debian-al szeretné, ezért gondoltam kipróbálom, hajtott a kíváncsiság, hogy mennyire lehet. Max ha debiant akar, akkor burnsenlab helium-ot telepít, az openboxos debian alapból, csak abban is vannak felesleges cuccok, no meg tint2, ami nekem nem jött be, mert keveset tudott.
Jah azt én is néztem anno, mikor a trizen szólt, hogy comptonnak vége, és helyette picom. Tearing hálistennek beállítható külön "kapcsolóként" Intelhez, így ezért nem kell nekem picom.Voidról mi a véleményed? Vagy még nem használod olyan régóta?
-
Frawly
veterán
válasz
Shyciii
#6626
üzenetére
A 244 MB valóban sok, én is hasonló csomagokkal tolom, és nálam 160-170 MB között ingadozik (free -m). Kicsit az Arch 211 megáját is sokallom, nálam az sem volt SwayWM-mel 170 fölött soha. Az a 747 telepített csomag Archra reális, nálam is ennyi körül van, Void most 685 csomag, de ezen pl. nincs systemd, meg annak az összes szutyka. Debianon az 1362 csomag nagyon sok, azért nincs minden csomag 2-3 felé szedve. Ezt magyaráztam már ubyegonnak is, de jött azzal, hogy szerinte nem bloat. Közben meg de, csak a Mint is ilyen, amit használ és hozzászokott.
Azért nagyon nem mindegy, hogy csak fele annyi csomagot kell frissíteni, meg fele annyi szutykot betölteni, és a memóriafogyasztás is kb. fele annyi tud lenni egy Mint Cinnamonhoz képest. uby nem értette, hogy nem arról van szó, hogy nem fér bele a 16 GB RAM-ba, hanem minek töltsünk be felesleges szutyokokat, ami azért mégis időveszteség, még ha csak néhány ms is, azért a sok apró összeadódik, meg a sok felesleges csomagra frissítéskor netsávszélt és letöltési mennyiséget pazarolni.
Termite nekem hiányzik egy kicsit, szerettem a vim-mód miatt, de egyrészt ki kell próbálni más alternatívákat is, meg én minden rendszerújratelepítéskor kipróbálok új dolgokat, már csak azért is, hogy változatos legyen, ne legyen unalmas, ismerjek meg más megoldásokat is. Így most lett az Alacritty, de lehet Gentoo-n már egy harmadik megoldás lesz.
Picom nekem mindenképp kell, nem csak az átlátszóság és Aero-effekt miatt, hanem anélkül tearingelnének a mozgó grafikus elemek, pl. játék, videólejátszás, böngészőben oldalgörgetés. Kell a vsync meg a hardveres OpenGL videógyorsítás. Régen Comptont használtam, az is ugyanez a kompozitor, csak a szerző leállt a fejlesztésével, ezért forkolták, és lett belőle Picom, ezt rendszeresen fejlesztik.
Archon SwayWM-et használtam, ami az i3wm waylandes változata. Azon nem kellett kompozitor, mert a waylandes WM-ek egyben kompozitálnak is, de X.org-on kell. Nagyon elméleti esetben, ha a GPU drivere támogatja, akkor X.org-on is be lehet kapcsolni a tearfree opciót, meg a DRI gyorsítást, de ezek nem minden GPU-n állnak rendelkezésre.
Debiannal meg továbbra is az a bajom, hogy konzervatív, relatíve régi csomagverziókkal. Bár ebben fejlődtek, régen, pár éve még sokkal jobban el voltak maradva verziókkal, most már nem annyira vészesen, mint a CentOS. Ennek ellenére én soha nem láttam értelmét a Debiant erőltetni. Használható azért, azoknak, akik ebbe az apt/deb ökoszisztémába szoktak bele, és nem fontos nekik a legújabb verziók és legmodernebb technológiák (Proton, DXVK, Wayland, stb.) használata. Én a helyedben nem erőltettem volna fel az Arch mellé, nincs értelme egyszerűen.
-
Shyciii
veterán
Végülis nem szórakoztam, hanem grubosra raktam mindent. Persze előtte az EFI partícióról csináltam egy image-et.
Nagyon hasonlót használunk. Én is Openbox, Polybar, xautolock, i3lock-blur, háttérképet nitrogen jeleníti meg, termite. picom-ot már nem használom, nem kell az átlátszóság, úgyhogy kilőttem. Login managert én sem használok. Igen azt tudom, hogy a non-free, és contrib-ot rögtön érdemes felvenni, na de egy kicseszett driverrel is már szívás van. Ráadásul egy elég gyakori Atheros driverrel.
TÖbbé-kevésbé beállítottam, de a polybaron jópár elem képtelen rendesen megjelníteni, mert azt mondja hogy nincs ilyen beépített modul. Úgy látszik debian alatt forgatva ez nagyon nem jó. Pulseaudio is felrakva, engedélyezve, és közben sehol nincs a modul. Ahhoz képest, hogy Arch-ra mondják, hogy juj semmi se működik, mindent konfigurálni kell blabla, ehhez képest sokkal működőképesebb minimális konfigurálással, mint a Debian.
Úgyhogy mindjárt le is gyalulom, teszt meg volt, ennyi.
Amúgy 244MB-os foglalt a Debian ugyanazon cuccokkal (leszámítva pár programot, és mondjuk a pulseaudio, ami mg megdobná a memóriafoglaltságot), míg az Arch 211MB-ot foglalt. De a legdurvább, hogy míg az Arch 747 csomagot mutat, addig a Debian 1362db csomagot. Értem én, hogy valszeg ami Archon egy csomagban van, az Debian-on 2-3db-ban, de azért ezt erősnek érzem, főleg úgy, hogy azért én eléggé minimális konfigot használok egy átlag userhez képest. -
Frawly
veterán
válasz
Shyciii
#6623
üzenetére
Végül melyik megoldás működött pontosan?
Debiant nem tudom, nagyon rég használtam már minimal netinstall, sok éve. Mennyi az a sok memóriafoglalás?
Én is Polybar-ral tolom, meg Openbox WM és Picom kompozitor, xautolock + i3lock képernyőzárnak. Login Managert nem használok, 1-es konzolról (tty1) jelentkezve be automatikusan indul a X.org, xinit-be fel van véve az openbox-session. A háttérképet a feh jeleníti meg, terminálnak Alacritty van.
Debian-nál az ath10 drivert azért neked kell feltenni, mert non free csomagként igényel egy firmware-t, és a non free alapból tiltva van rajta, alapból le sem tölt ilyeneket, mivel a Debian szigorúan GNU Free disztró, azaz alapból csak olyan csomagokat érsz el a tárolóból, aminek szabad licence van. Egyébként a Void Linux is ilyen. Meg a Parabola, ami egy Arch-klón. Ezekben, ahogy Debianban is, az első, hogy még telepítéskor vagy közvetlenül telepítés után engedélyezni kell a nonfree tárolót.
-
Shyciii
veterán
Így már működik :) a lényeg hogy pontosan ugyanazt a rendszert hozzam létre, mint Arch alatt, csak debian alapokon. Ez a kérés, én meg nem mondtam nemet. De most ezt csinálva nekem nagyon úgy tűnik, hogy ez a debian max minimál install-al szervernek jó, mert innen felépítve desktopra eléggé pazarló. Nem csak memóriát foglal többet, de jóval több csomagot is tett fel, és még nem vagyok kész. Most egyelőre a polybar-al és az arra kirakott cuccokkal szenvedek. Halál jól működik Arch-on, debianon egyelőre nem akar. Mondjuk az külön vicc, hogy a netinstall közli, hogy az ath10-es drivert én külön adjam meg neki. Baszki netinstall. Hiányzik driver, akkor töltse már le.
-
válasz
Shyciii
#6620
üzenetére
Szerintem az fstabban át kell írni, hogy az efi partíció hova mountolódjon ( /boot), és a két rendszer miatt az efi partíción mappákba kell pakolászni a szükséges fájlokat, hogy a két rendszer ne keveredjen egymással, bár valószinüleg nem lesznek benne tök azonos nevű fájlok. Ekkor már az Arch mintájára meg tudod csinálni a debian systemd bootját is. Ki lesz tömve sajnos így az efi partíció. De a debián ezután is a grub szerint fogja kernelfrissítéskor a fájljait pakolászni és neked sk kell majd ezek után az efi mappába bevongálgatni a szükséges dolgokat sajnos. Egy rendszer systemd bootja tehát csodás és nagyszerű tud lenni, ha eleve úgy van telepítve, két rendszer viszont már zavarja egymást. Két rendszer esetén már a grub sokkal elegánsabban és egymástr nem zavarva tud működni.
-
Frawly
veterán
válasz
Shyciii
#6620
üzenetére
Esetleg még azt lehet csinálni, hogy teljesen megkerülöd a Debian GRUB-ját, és közvetlenül veszed fel a Debian kernelt és initramfs-t az Arch systemd-boot menüjébe, ahogy először próbáltad (GRUB-ból kimásolva a kernelparamétereket). De ezzel az a probléma, hogy ha Debian alatt frissül a kernel, akkor nem fogja megtalálni az új verziót. Mert a Debian beteszi ugyan az új kernelt a GRUB-jába is, de mivel ezt te megkerülöd, ezért nem fog látszani, és a régi kernellel indul a rendszer.
Az, hogy mi mennyit foglal, az attól függ, hogy mit mivel telepítesz. Egyforma csomagoknál azért nem kéne nagy különbségnek lennie.
A Termite nekem is érdekes, mert Archon kívül szinte semmilyen disztrónak nincs benne a tárolójában. Nem is értem az okát. Void meg Gentoo alatt is külön tárolóból kell forgatni. Mivel nem akartam én sem ezen tökölni, így most Voidon Alacritty-t használok, ez se rossz, csak speciális vim-módokat nem tud kijelölésnél és görgetésnél.
-
Shyciii
veterán
Köszi mindjárt kipróbálom, csak közben a debian-ra elkezdtem felpakolni ugyanazokat mint az archon (kivéve amit forgatni kell, mert nincs a tárolóban lásd termite, polybar pl). Még a felét se raktam fel, állítottam be, de már több memóriát foglal, mint az Arch...ez kicsit meglepő nekem, pedig full minimal Debian-nal kezdtem.
-
Frawly
veterán
válasz
Shyciii
#6618
üzenetére
Most én is ezzel küzdök, de Void alatt. Az GRUB-ot használ, és működik ugyan az UEFI boot, de csak akkor, ha F12-t nyomva a boot menüből kiválasztom a void_grub bejegyzést. Egyébként mindig az Arch akar indulni. Pedig az UEFI-ben be van állítva a bootsorrendnél, hogy a void_grub legyen az első.
Amit a entriesről írtam, azt visszavonom. Ez csak systemd-bootnál működik, ami közvetlen kernelt bootoltat initramfs-sel. Ha a Debian GRUB-os, akkor nem kellenek ezek a conf fájlok. Helyette Arch alatt efibootmgr-rel vedd fel a grubx64.efi-t indulásra. Még paraméterek sem kellenek neki, mert a GRUB ezt saját hatáskörben elintézi. A lényeg, hogy az UEFI BIOS találja meg a grubx64.efi fájlt:
sudo efibootmgr -c -L "Debian" -l '\EFI\Debian\grubx64.efi'Vigyázat, az UEFI-nek visszafelé perjel kell, mint Windowsnál. Ugyanis egy DOS-ból származtatott implementáció! Nem a normál linuxos-unixos perjel kell neki. A harmadik kapcsoló az efibootmgr-nél egy kis L, nem nagy i, csak rosszul látszik a Prohardver által használt talpatlan betűtípussal. Arch alól csináld természetesen, ne Debian alól.
-
Shyciii
veterán
A loader.conf-ban csak ez van:
default Arch
timeout 3Az Arch az Arch.conf-ra utal ami a /boot/loader/entries-ben van. Az Arch.conf-ban meg ez van:
title Arch Linux
linux /vmlinuz-linux
initrd /initramfs-linux.img
options root=PARTUUID=a76e14ae-961a-47e0-88df-b959e216185a rw quit loglevel=3Gondoltam csinálok erről egy másolatot amit Debian-nak neveztem el, és utána a title értékét írtam án, és a PARTUUID-jét a blkid-ből kiolvasott értékével. Csak azzel nem tudom hol utalok a debian mappában levő grubos uefi-ra.
-
Frawly
veterán
válasz
Shyciii
#6614
üzenetére
A leírásod alapján jól csinálod pedig. A /boot/loader/loader.conf hogy néz ki nálad? Tudni kéne ugyanis, hoyg indításnak mit adtál meg a debian.conf-ban. Ha GRUB jön a képbe, akkor a grubx64.efi fájllal kell indítani, de mivel nálad van shimx64.efi, ezért lehet mégis az kell helyette, a shim a Secure Bootot intézi, de ehhez a részéhez nem értek, mert én mindig letiltom a Secure Bootot.
A Debian, mint ahogy a legtöbb disztró, felteszi a GRUB-ot, ha kéred, ha nem. Nálam a Void is feltette sajnos, majd kigyomlálom belőle.
Bár annyi előnye lehet, hogy ha végképp sehogy nem boldogulsz, akkor nem a Debiant veszed fel a systemd-boot-os menübe, hanem fordítva, az Archot veszed fel a Debian GRUB-jába.
-
Shyciii
veterán
Frawly:
Jah azt elfelejtettem írni, hogy a Debian be se kerül az UEFI menüjébe, mert bár a boot/EFI alatt létrehoz egy debian mappát benne pár efi file-al, meg grub.cfg-vel, de a /boot/loader/entries alatt már nem hoz létre file-t. Valszeg azt hoztam én létre rosszul, de visszaolvasva pár írást, automtikusan be kellene kerülnie a debian-nak. -
Shyciii
veterán
Frawly:
Szia. Egyszer régen úgy rémlik, hogy leírtad, hogy mi van akkor ha valaikinek UEFI-s systems boot-os Arch van, és mellé akar egy másik linux disztrót, akkor hogyan lehet ugyanúgy UEFI-s megoldással. Muszáj feltennem a jelenlegi Arch-om mellé egy Debian 10-est, és netinstall-al felraktam egy teljesen minimal rendszert egy külön 15GB-os szeletre. Eleve érdekes hogy felrakott Grub-ot úgy, hogy meg sem kérdezte, hogy akarom-e, de mindegy. A /boot/loader/entries alatt létrehoztam egy Debian.conf-ot is az Arch mintájára. Nyilván a PARTUUID-t átírtam az új értékre. De mivel ez a szerencsétlen Debian grubosként installálta magát automatice, így persze nem működik, hisz a /boot/EFI alá létrehozott egy debian mappát amiben most van BOOTX64.CSV, fbx64.efi, grub.cfg, grubx64.efi, mmx64.efi, shimx64.efi.
Szerinted hogy tudom kikerülni egyrészt a grubot (úgyse működik, mert debian nem bootolbe, csak az arch), és hogy tudom az arch uefi+systemd-bootos megoldást megcsinálni debian esetében is. Ha egyáltalán lehet... -
Siriusb
veterán
Megkérdezném a nagyérdeműt, ki milyen biztonsági megoldásokat használ a gépén, mint pl. apparmor, firejail stb.
Kíváncsiságból feltelepítettem a vibert és firejail-lel akartam futtatni, de nem tudtam megoldani, hogy a szinkronizálás működjön.
Ellenben nem ártana pl. a böngészőt firejail-ben futtatni, talán a rootless xorg sem lenne butaság... -
Shyciii
veterán
Másfél hónapja új melóhelyen vagyok, és ott javarészt Debian van, meg egy Red Hat. Megdöbbenve látom, hogy a Debian 10.3-as Buster-en (stable) a Chromium 79-es verziónál tart. Értem én, hogy stable, és mégsem egy Arch, na de bakker. Nem véletlenül tart a 80-as verziónál (a sokadiknál), mert még a 80-asban is kritikus biztonsági rések vannak. Azért legalább ezt frissíthetnék a Debian stable kiadásánál normális tempóban. Ezt így gáznak érzem.
-
Frawly
veterán
Szerintem meg nem az Arch/Manjaro hibája, vagyis olyan értelemben az, hogy ők nem adják hozzá automatice ezeket a kapcsolókat, vagy úgy fordítják le a kernelt, hogy szükséges a kapcsoló. De ez nem azért van, hogy téged szopassanak, hanem hogy vanilla állapotban tartsák a csomagokat, neked ettől még megvan ez a lehetőséged, hogy kernelparaméterekkel meg egyebekkel szórakozz. Ez az Archnak a „hekkeld magad” filozófiájából ered, ők nem foltozgatnak semmi disztróspecifikus dolgot a csomagokba.
Ehhez képest a Debian, Ubuntu és Fedora vonalán a disztrókészítők tengernyi patcht meg disztróspecifikus beállítást eleve odahekkelnek default, azért megy. Ez hihetetlenül kényelmesnek is tűnik, de ennek is megvan legalább annyi hátránya, csak máshogy jön ki, pl. ha egy vanilla csomagot forráskódból forgatsz (mert nincs meg semmilyen tárolóban, nem hivatalos külső tárolóban sem), akkor néha meg az a szopás, hogy nem fut normálisan a kód valami disztróspecifikus patch-csel összeveszve, ami épp ott csücsül a futó binárisokban. Vagy pl. ilyen külön patcheléssel nem tudják olyan gyorsan kihozni az új verziókat, mindig csak fáziskéséssel tudják kiadni.
Ami az Arch/Manjaro hibája, az az, hogy ezeket az esetlegesen szükséges kernelparamétereket, nem kommunikálják le, de ez részben a kernelkészítők igénytelensége is, hogy nem tartják rendesen karban a dokumentációt. A kerneldoksinak tartalmaznia kéne ezeket a GPU specifikus dolgokat, hogy melyik generációs kártyára milyen kapcsolók kellenek, meg az Arch Wikinek is ki kéne térnie erre, külön felhívva a figyelmet, hogy ilyen meg olyan AMD GPU generációknál erre szükség lehet, fokozottan kell rá figyelni.
De én még az AMD-től is elvárnám, hogy a linuxos driveroldalukon összehozzanak egy általános linuxos Wiki cikket, ahol sorra veszik, hogy milyen GPU generációknál milyen beállítások, driverek, stb. kellenek a főbb disztróvonalakon, hogy használható legyen a ×4rjuk.
És itt most nem az Arch-osokat akarom védeni, hanem azt kell érteni, hogy nem vagy nem csak miattuk szenvedsz, hanem több ember és cég érdektelensége miatt kell szívni, meg küzdeni, mire rájössz ilyen hekkelős megoldásokra.
-
Én ezt most az Arch-os vagy AMD-s kernel karbantartóknak róvom fel, mert Manjaro-t is megpusztult egy másik GCN IGP-n a kernel. [link]
Megsem próbálja GCN3-as IGP-n betölteni az AMDGPU-t, hanem radeon-nal próbálkozik, persze sikertelenül. Ezt még nem fejtettem meg.
Mindeközben Fedora-n mindkét gépen hasít minden.
-
Frawly
veterán
Gondolom a frissebb kernelben megváltozott az amdgpu driver, az tette szükségessé, bár nem tudom mit csinál ez a két kapcsoló, magamtól erre rá nem jöttem volna. Egyébként nem is az a gond, hogy ilyen kernelparaméterekre szükség lesz, hanem nincs lekommunikálva rendesen, és sokszor a kerneldokumentáció sem egyértelmű. Ez utóbbit elég sokan kritizálják is, hogy a kernel doksija nincs rendesen karbantartva, a kernelt fejlesztik ezerrel, a dokumentáció meg le van maradva jócskán.
-
Sziasztok!
A korábbi hibára meglett a megoldás, amit egy fórumban találtam.
A kernel paraméterek közé be kellett tenni ezt:amd_iommu=on iommu=pt
A kérdés, hogy egy frissítéstől miért lett erre szükség?
Nagyon kiváncsi lennék a válaszra.Előre is köszi!
![;]](http://cdn.rios.hu/dl/s/v1.gif)
gondolkodom azon, hogy ismét bepróbálkozok a KDE-vel és lecserélem a Cinnamon-t. Milyen mostanság a KDE (gyorsaság, erőforrás zabálás, kinézet stb), vannak tapasztalatok?
Ellenben nem ártana pl. a böngészőt firejail-ben futtatni, talán a rootless xorg sem lenne butaság...
Új hozzászólás Aktív témák
- ÁRGARANCIA!Épített KomPhone Ryzen 7 9700X 32/64GB RAM RX 7800 XT 16GB GAMER PC termékbeszámítással
- Apple iPhone 12 Pro Max /128GB / Gyári független / 12Hó Garancia / 83% aku
- Eladó Lenovo ThinkCentre M910q i7 16GB / 12 hó jótállás
- ÁRGARANCIA!Épített KomPhone i7 14700KF 32/64GB RAM RTX 5070 12GB GAMER PC termékbeszámítással
- GYÖNYÖRŰ iPhone 12 Pro Max 256GB Pacific Blue -1 ÉV GARANCIA - Kártyafüggetlen, MS2116, 100% Akkumul
Állásajánlatok
Cég: FOTC
Város: Budapest