- sziku69: Szólánc.
- Luck Dragon: Asszociációs játék. :)
- LordAthis: Ismét egy "Idióta" A.I. Projekt, hogy meglovagolja az aktuális trendeket...
- Geri Bátyó: Agglegénykonyha 1 – rizseshús másképp
- bambano: Bambanő háza tája
- Kalacskepu: Elrontott Radeon X1950 Pro megjavítása
- sziku69: Fűzzük össze a szavakat :)
- GoodSpeed: Bye PET Palack, hello SodaStream
- talmida: Változások
- 25
-
LOGOUT
Arch Linux topik
Új hozzászólás Aktív témák
-
Shyciii
veterán
válasz
jimmy399
#6899
üzenetére
Akartam is kérdezni, hogy miért akartál mindenáron partícióról bebootolva telepíteni, és miért nem jó a pendrive-os telepítés, majd utána a grub update lefuttatása mely megtalálja a win-t, és kész. Miért kellett ezt megfordítva bonyolítani amivel elcsesztél vagy fél napot, ahelyett, hogy fél óra alatt felmegy usb-ról a win, grub reconfig 1-2 perc alatt és kész
-
jimmy399
senior tag
-
Frawly
veterán
válasz
jimmy399
#6895
üzenetére
Ja, értem. Azt nem tudom milyen Win10 telepítő ez, a hivatalos 1903, 1909-es verziójú, hivatalos Win10 telepítőkön az install.wim lemezkép pont azért 3,99451 GiB-os (maximum 4 289 073 755 bájt), hogy EFI partícióként viselkedő FAT32-partícióról is telepíteni lehessen, ami csak 3,999999999 GiB-os (4 294 967 295 bájtos, azaz 2^32-1 bájtos) fájlokat támogat.
Mindjárt mondanám is, hogy hiba volt FAT-ot szabványosítani EFI partíciónak, de nem arra tervezték, hogy sok gigás wim lemezképeket innen telepíts, hanem rendesen feltelepített OS-t töltsenek be pár megás EFI fájlok, vagy maximum 30-50 megás initramfs, meg Linux kernel induljon el róla. Ez abszolút a Windows Telepítő és MS hibája, hogy a telepítőjükben nem lehet betallózni más partíciókról és meghajtókról az install/wim fájlokat.
-
jimmy399
senior tag
Nem, nem jól írtam le akkor. Az mstől letöltött eredrti iso fájlból kimásolt telepítővel akartam megcsinálni a telepítést. Ehhez ugye létrehoztam egy külön partíciöt. Felmásoltam, majd grub-mkconfiggal létrehoztam a grub configot. Viszont nem tette be a telepítőt a menübe mert eleve nem is keresi az os-prober, mert ahogy olvastam azt csak a csm módon telepített rendszereket nézi meg. Ilyenkor amikor uefi-ben telepített rendszeren futtatom csak az ESP-n néz szét és ha van rajta más rendszer is, akkor azt be is teszi, esetemben a win10 boot loadert. A win10 telepítőt meg nem, mert nem az másik sima ntfs partíción van. Namost megpróbáltam kèzzrl hozzáadni az efibootmgr programmal a telepítőn lévó bootmgr.efi-t az uefi firmware-be kozvetlenul felvenni a listába de hiába tettem meg akkor is a grub indul el.
Fat32-ben eleve nem lehet egyszerűen használni egy pendrive-ot mert van 4gb-nál nagyobb .wim fájl. -
Frawly
veterán
válasz
jimmy399
#6892
üzenetére
UEFI módban fel lehet venni bármilyen EFI fájl indulását. Ki kéne deríteni, hogy az illető partíción lévő Windows mivel indul, biztos vagy ebben az efibootmgr.efi-ben? De én nem javaslom Windows Telepítő partíció futtatását. A gyártók telepakolják reklámmal, demóval, szeméttel, malware-rel, meg nem is a legfrissebb verzió, ha feltelepíted, napokig frissítgeti magát, 100× újraindulva. Ha Win10 telepítő kell, a MS oldaláról letöltöd a legfrissebb iso-t, és elve a Media Creation Tool-lal kiírja magát USB-re, vagy ha Linxux alatt látogatod meg az oldalt, akkor kimásolod az iso tartalmát egy FAT32-re formázott USB drive-ra, és telepíted azzal, rendes alaprendszert, tisztán, gyártói szemét nélkül, csak a MS Candy Crush és egyéb szemete és live/reklám csempéi lesznek benne default telepítéssel.
-
jimmy399
senior tag
Sziasztok!
Megpróbáltam megtalálni a megoldást, de nem sikerült. Így a ti segítségeteket kérem.
Annak idején sima BIOS módba bootolva lehetett olyat csinálni, hogy az os-prober megtalálta a Windows telepítő partíciót a gépen, s betette a grub menübe, így egy hdd/ssd-ről közvetlenül lehetett indítani a Windows telepítőt. Namost, átállok uefi-re és ott már nem ismeri fel az os-prober, mert ahogy kivettem, az csak az MBR-es BIOS módban indított rendszeren tud ilyet csinálni.
Viszont én szeretném UEFI alatt is megoldani, de ha kézzel próbáltam felvinni a grub menübe a Windows boot loader (telepített Windows 10) mintájára, akkor nem sikerült elindítani így. Valami hibára futott, hogy nem tudja az efi fájlt betölteni. bootmgr.efi lenne a fájl neve, elvileg ez indul el amikor a windows telepítőt indítjuk el, de itt nem tudtam műkö9désre bírni.
Próbáltam a efibootmgr-rel is hozzáadni a EFI stub-hoz, ami sikerült is, és beállítottam, hogy azt indítsa el a következő reboot-kor, de nem történik semmi, rögtön a grub indul el...Egyáltalán meg lehet ezt oldani valahogy hogy a grub-ból indítva sikerüljön bebootolni a Windows 10 telepítőt, vagy nem?
-
Frawly
veterán
válasz
Archttila
#6890
üzenetére
RPi-re talán elmegy az Xfce, de a sima Openbox, vagy IceWM vagy hasonló jobb lenne. Meg pdf-nézőnek mindenképp Zathura akkor, ha Single Board Computerről van szó.
A picom bekonfigolható, hogy vsync legyen csak benne (meg hardveres OpenGL gyorsítás, hogy ne szaggasson a grafikus felület, ha görgetsz meg ablakot mozgatsz):
picom --backend glx --vsyncPersze mellette az Xfce saját kompozitorát teljesen tiltsd le.
A Chromium picom-os tiltólistázásával pontosan mit akarsz elérni? SBC-re egyébként Chromium helyett Firefox vagy Pale Moon, erőforrás-takarékosabb. A Chrome, Chromium, és a rajtuk alapuló böngészők, Vivaldi, Opera jobban eszik az erőforrást, ami nagyon korlátozott ilyen RPi-szintű gépeken. A B550-es Ryzenen mindegy, annak nem kottyan meg semmi, de egy ilyen kompakt kis gépnél minden csepp erőforrás-megtakarítás fontos, a sok kicsi sokra megy.
-
Archttila
veterán
milyen grafikus környezetet használsz most
Még mindig nincs kész az asztali gépem (most már megvárom a b550-es lapokat) így jobb híján továbbra is az RPI4/Manjaro (ARM) páros dübörög.
de legalább már Arch alapon vagyok! 
Szóval Xfce edition mellett raktam le a voksomat mivel korábban évekig ezt használtam így most nem volt kedvem a KDE kiadással bohóckodni (meg amúgy sem a szívem csücske) Tudom bloat ez is de DE-ek közt akkor is még mindig Ő a light
viszont ezzel párhuzamosan egy másik SD kártyán építem a kis saját Openbox-om aminek a konfigját majd áthozom a desktop-ra Egyébként (főleg ha feltolom 2GHz-re a kis Pi-t) egész használható!
Egyedül az Xfce compositor fogja meg néha, de az is csak inkább a Chromium-ot...
Ha már itt tartunk, szerinted ha kikapcsolom Xfce alatt a compositort és telepítek egy picom-ot, akkor az bekonfigurálható úgy, hogy csak v-sync legyen és semmi más? Esetleg alternatív megoldáskánt tiltó listázni benne a Chromiumot? -
Frawly
veterán
válasz
Archttila
#6886
üzenetére
A proc bejegyzés nem szükséges bele, legalábbis én nem tudok olyan felállást elképzelni, ahol kellhet. Vedd ki, legfeljebb mentsd el a mostani fstab-ot biztonsági másolatként, és ha nem bootolna mégse (kötve hiszem, de tegyük fel a legrosszabbat), akkor bebootsz egy Arch-iso-t vagy akármilyen Live Linuxot és visszamásolod a régi változatot.
Pdf-olvasóra Zathura, bár lehet nem fog tetszeni, hogy főleg billentyűzetes irányításra tervezték, ezért nincs menürendszere (de egérrel is irányítható, csak kattitantani nem tudsz mire), de cserébe villámgyors, extra lightweight, pluginekkel kezel Djvu, ps, Comicbook formátumokat is. Esetleg xpdf, mupdf, qpdfview.
Bár attól is függ, hogy milyen formátumok támogatását akarod tőle, milyen grafikus környezetet használsz most. Mert pl. ha KDE, akkor egy Okular is pehelysúlyúbb, mint egy Acrobat Reader vagy egy Foxit Reader. Ha Gnome vagy más Gtk-s felület, Mate, Cinnamon, Xfce, akkor az Evince sem annyira bloat, mert azok a libek, amiket használna, már eleve be vannak töltve a rendszeren.
-
Frawly
veterán
válasz
Archttila
#6882
üzenetére
Tegyük tisztába: UUID-ből háromféle is van egy lemezen, függetlenül attól, hogy GPT vagy MBR/dos. Van a
1) lemez-UUID, ez a partíciós táblához tartozik, akkor generálódik újra, ha újrainicializálod a lemezt, új partíciós táblával
2) PARTUUID, ez a partíciók UUID-je, minden partícióhoz, partíció újra létrehozásával új generálódik
3) fájlrendszer-UUID, ez nem a partícióhoz, hanem a rajta lévő fájlrendszerhez tartozik. Ez formázáskor generálódik újra (pl. mkfs.akármi). fstab-ban az UUID=akár-mi-csoda érték erre az UUID-re utal, ezt szokták UUID-n érteni, amikor ilyen néven emlegetik.Na, már most a te kimenetedben világosan látszik, hogy a blkid-vel a PARTUUID-t kérdezted le, de az fstab-ba a fájlrendszer-UUID-t írtad be, ezért nem egyezik. Bármelyiket megadhatod, de akkor használd következetesen, ne keverd őket.
Ez a jó az Archban, egyszer megszenvedsz vele, megtanulod mi hogy működik, onnantól megtanultad magadnak megoldani, supportálni, semmilyen Calamares, meg Canoical-fasz-ez Installerre, meg Red Hótt supportjára nem leszel rászorulva soha többé, hogy mindenféle csilivili installereken, és 200 megás Gtk-hegyeken keresztül védjenek meg öltönyös-nyakkendős, céges-trenddiktátor idióták.
-
Archttila
veterán
válasz
Archttila
#6881
üzenetére
Nem, sajnos mégsem jó:
blkid
[alucard@desktop ~]$ sudo blkid/dev/mmcblk0p1: SEC_TYPE="msdos" LABEL_FATBOOT="desktop" LABEL="desktop" UUID="3D33-128E" BLOCK_SIZE="512" TYPE="vfat" PARTUUID="25aae5bf-01"/dev/mmcblk0p2: LABEL="desktop" UUID="822a76e2-6287-49ee-9198-264010321f78" BLOCK_SIZE="4096" TYPE="ext4" PARTUUID="25aae5bf-02"/dev/sda1: PARTUUID="0e6e9bbc-add8-6e40-899c-29a261542086"mount
[alucard@desktop ~]$ sudo mount -amount: /mnt/PiDrive1: can't find UUID=0e6e9bbc-add8-6e40-899c-29a261542086.Nem az van, hogy a GPT meghajtókat máshogyan kell jegyezni az fstab-ban?
fstab
proc /proc proc defaults 0 0/dev/mmcblk0p1 /boot vfat defaults 0 2/dev/mmcblk0p2 / ext4 defaults,noatime 0 1UUID=0e6e9bbc-add8-6e40-899c-29a261542086 /mnt/PiDrive1 ext4 defaults,noatime 0 1Nem volt még GPT-s HDD-m, de így lehet nem is lesz
-
Shyciii
veterán
válasz
Archttila
#6879
üzenetére
Mert szerintem nem azaz UUID-je. Ha megnézem az fdiisk-el az enyémeimet, akkor legalábbis nem az.
Szerintem inkább a blkid parancsot használd, hogy kiderítsd mi is azaz UUID, amit tudsz használni a csatoláshoz.
De jó az lsblk -f is. Én mindig ezekből nyertem ki az UUID értékét. -
Archttila
veterán
Valami oknál fogva nem tudom fstab-ba csatolni a GPT-s külső HDD-ket UUID-el. A korábbi DOS-os label meghajtókkal nincsen ilyen gond, ott szépen működik, de GPT-vel:
Disk /dev/sda: 931.49 GiB, 1000170586112 bytes, 1953458176 sectorsDisk model: Elements 25A2Units: sectors of 1 * 512 = 512 bytesSector size (logical/physical): 512 bytes / 512 bytesI/O size (minimum/optimal): 512 bytes / 512 bytesDisklabel type: gptDisk identifier: 7784D56C-124B-234B-83A9-6FBD1581B0D3Device Start End Sectors Size Type/dev/sda1 2048 1953458142 1953456095 931.5G Linux filesystem[alucard@manjaro ~]$ sudo fdisk /dev/sdaWelcome to fdisk (util-linux 2.35.1).Changes will remain in memory only, until you decide to write them.Be careful before using the write command.Command (m for help): iSelected partition 1Device: /dev/sda1Start: 2048End: 1953458142Sectors: 1953456095Size: 931.5GType: Linux filesystemType-UUID: 0FC63DAF-8483-4772-8E79-3D69D8477DE4UUID: 89E931D2-0765-B449-B910-F6E0F0FDA7F5nem látja:
sudo mount -amount: /mnt/PiDrive1: can't find UUID=89E931D2-0765-B449-B910-F6E0F0FDA7F5 -
Shyciii
veterán
válasz
#63718632
#6877
üzenetére
Nem ismerem ezt a szériát, főleg ilyen kis kijelzővel, mert nekünk min 15,6-os kellett a munkák miatt. Amúgy meg ki kell kapcsolni a secure bootot, aztán egyrészt kiderül, hogy bebootol-e a win, és ha igen, akkor a biztonsági funkció jelen esetben az ujjlenyomat olvasó működik-e tovább. De nekem az lenne az első, hogy legyalulnám a francba a wint
-
Frawly
veterán
-
Shyciii
veterán
Sajnos sanszos, hogy az ujjlenyomatolvasó megköveteli a secure boot-ot (ha nem valami gagyi), ugyanis azzal lehet növelni a biztonságot. Az usb-s tokenek használata bejelentkezés esetén is kellett secure boot az előző melóhelyemen, meg azon notik esetén, amibven alappból volt TPM chip.
-
Frawly
veterán
válasz
#63718632
#6870
üzenetére
Ha a Secure Boot be van kapcsolva, akkor szopás az UEFI boot, olyan bootmanager kell akkor, ami kezeli a shim-et. Azt nem tudom, hogy a systemd-boot kezeli-e. Sose használtam Secure Bootot, az első, amit kikapcsolok, mert
1) mint védelem nem sokat ér ténylegesen
2) csak megkeseríti az ember életét OS-ek telepítésekor
3) akármilyen OS-en driverek telepítésekorAz ujjlenyomat-olvasónak nem kéne elvileg megkívánnia a Secure Bootot, de ki tudja, lehet azon a gépen fogja. Mondjuk ezekben én nem tudok neked segíteni, mert semmi ilyen flancos dolgot nem használok, se Secure Boot, se ujjlenyomat-olvasó, se Windows Live arcfelismerés, se VR-szemüveg, se multimonitor setup, se 100 gombos 3000000 DPI-s Gaming Pro RGB Ultra egér, se BT-os eszközök, se USB-s vibrátor, se semmi ilyen szarokat nem használok, nem kötözgetek a gépre. Így ilyen spéci dolgokról nem tudok nyilatkozni, hogy mi mit igényel, hogy menjen. Régi vágású vagyok, bekapcsolom a gépet, beépített eszközöket, beépített kijelzőjét használom, egy kijelző, 1 virtual desktop, tapipad, stb..
-
-
#63718632
törölt tag
válasz
Shyciii
#6871
üzenetére
Tudom, nem nagyon ajánlott, de én szinte realtime frissítek
.
A pamac indikátor ott csücsül a tálcán, aztán ha jelez. Megy a pacman -Syu, hiába állítottam 48 órára a keresést-figyelést. Mindíg jelez, amint van valami. Másra nem is nagyon használom csak erre, meg ha keresek valami csomagot. -
Frawly
veterán
válasz
#63718632
#6868
üzenetére
Tudtommal EFI partícióból nem lehet kettő azonos meghajtón. De pont az az EFI partíció lényege, hogy több OS-nek is elfér rajta az .EFI fájlja, nem írogatják át egymás dolgait, megférnek egymás mellett. A MBR bootnak pont ez a baja, hogy az egyes OS-ek kicserélgetik egymás alatt az MBR indítókódot. Ez UEFI bootnál nincs.
Simán telepítheted az Archot systemd-boottal a Win10 mellé, amennyiben nem használsz Secure Bootot. A Windowst nem a systemd-boot teszi bele a menübe, hanem a Windows alakítja ki hozzá a szükséges dolgokat az EFI partíción, amit az UEFI talál meg. Te csak a meglévő EFI partíción létrehozol 1 mappát meg 2 konfig fájlt, és a végén kiadsz egy bootctl --path=/boot install parancsot. Ez egy teljesen új systemd-bootx64.EFI fájlt fog létrehozni a /boot/EFI/systemd mappában. A Windowst indító /boot/EFI/BOOT/BOOTX64.EFI fájlhoz nem nyúl hozzá egyáltalán, a Windows nem is fog róla tudni, hogy rajta kívül új OS lett telepítve.
-
#63718632
törölt tag
Meg lévő Win10 telepítés mellé, dual bootban is lehet alkalmazni a systemd-bootot? Az asztali gép mellé érkezik majd egy kis Dell noti is.
[link]
Egy db. m2-es SSD van benne (256 GB), telepített Win10-el. Erre is Arch-ot szeretnék majd telepíteni.
El gondolkodtam azon, mint azt fentebb említették. Hogy a linuxnak is készítek saját kis efi partíciót, hogy ne közösködjön a Win10-ével, meg emez ne rondítson frissítéskor bele.
Mi a helyzet, ha az Arch-ot systemd-boottal telepítem? Fölveszi a Win10-et az indító menüjébe? -
Frawly
veterán
Ez igaz, az is az, de annyira egyszerű, hogy lényegében egyetlen kicsi .EFI fájl, meg 1-2 hozzá tartozó .conf fájl, nem kell újratelepíteni soha, még Arch újratelepítésekor sem. Elég a .conf fájlban az UUID-ket egyeztetni, és ez elég ahhoz, hogy bármilyen Arch telepítés bootoljon. Nekem már több mint 3 éves az EFI partícióm a rendszer alatt, pedig számtalanszor volt Arch újratelepítve.
Lehetne magát a Linux kernelt is EFI stub fájlként bootoltatni, akkor tényleg nincs semmilyen bootmanager az UEFI-n kívül, de ez Arch alatt tudtommal ez nem megy az initramfs miatt.
GRUB akkor kell, ha valami bonyolultabb bootfelállás van, mondjuk valaki RAID-ről vagy ZFS-ről vagy hasonlóról bootol, vagy UEFI Secure Boot miatt shim kell, vagy MBR Legacy BIOS boot van.
-
ztsoft
őstag
Megint nem tudok belépni a BIOS-ba (át akartam rendezni a boot sorrendet).
De a Win vígan indul. Még sem jó ötlet ezen a gépen a Win UEFI partícióját használni. Át fogom gondolni, hogy annyira fontos-e a Win.Át fogom nézni a systemd-boot-ot, nem sokat vesztek vele, még ha újra is kell rakni az Arch-ot.
-
Frawly
veterán
Ha az Arch Wiki systemd-boot cikke alapján csinálod, akkor nem kell GRUB-ot sem telepíteni. Az UEFI/EFI bootnak pont az a lényege, hogy az UEFI már önmagában is egy bootmanager, nem igényli további bootmanager feltételét.
Az egyébként önmagában nem baj, ha 9,3 MiB maradt csak az EFI partíción. Ráfért, aminek rá kell. Úgyse történik rá sok írás, sok olvasás, mindegy mennyi szabad hely van rajta.
A HDD kivétele szerintem azt okozta, hogy 1-2 UEFI boot opció mögött a meghajtó elérhetetlenné vált, és ilyenkor sok UEFI BIOS automatikusan törli a bootbejegyzést az UEFI-ből.
-
ztsoft
őstag
válasz
Laszlo733
#6860
üzenetére
+ (#6862) Frawly
Köszönöm a válaszokat. Ami a méretet érinti, a 100MB-ból 9,3MB maradt a GRUB telepítése után.
Kézzel telepítek (kell a gyakorlás), a particionálást még a cfdisk-kel csinálom (később jöhet az fdisk is, most nem akartam reszkírozni, hogy elcseszem).
Így is volt valamilyen hiba, csak a Win indult (nem volt GRUB), de még a BIOS-ba sem tudtam belépni (csak egy fehér kurzor fogadott). Ha kivettem a HDD-t, akkor jól működött minden, ha vissza tettem, akkor ismét rossz volt.
Kis pihenő után sikerült elindítani ismét a telepítőt, így a chroot-tal újra felraktam a GRUB-ot és jó lett. Most már folytathatom a telepítést.
-
Frawly
veterán
Nem kell még egy EFI partíció. Nem is lehet belőle egy lemezen egynél több. Használd a Windows EFI partícióját. A Wikire nem kell hallgatni, nekem 100 MB-on elfér nem csak az Arch, hanem régebben mellé fért a Windows EFI is. Ezt a 250-500 megát azért ajánlgatják ilyen linuxos wikikben, mert nem tudják hogy milyen disztróhoz lesz, Debian/Ubuntu-vonalon pl. be tudnak rá halmozódni a régi kernelek, meg azt se tudják, hogy hány OS-t használsz multibootban, és biztos, ami biztos alapon overkill EFI partícióméretet ajánlanak.
-
Frawly
veterán
válasz
Shyciii
#6857
üzenetére
Az Openbox nem dinamikus, hanem stacking WM, ami azt jelenti, hogy az ablakokat floating módban kezeli és azok részben vagy egészben átfedhetik egymást. Az Awesome dinamikus tiling WM, de azok között a legfelhasználóbarátabb.
Az xmonad nekem is magas a Haskell miatt. Akkor már inkább dwm, mert C-ül legalább tudok, az annyira nem átláthatatlan. Amit a dwm-ben nem szeretek, hogy mindenhez patchelni kell, és a patchek nem kompatibilsek automatán, hanem kézzel kell őket beszúrogatni, ami több patchnél egyre nagyobb munka, egyre kényesebb művelet. Igazából a legtöbb dinamikus tiler dwm-klón, az xmonad is, csak C helyett Haskell-ben írva, a Qtile Pythonban, a Spectrewm C-ben (de támogat külön konfigfájlt), stb.. Igazából az awesome is dwm-klónként indult, csak a nyelv változott, amiben írták (C, de konfigjában már Lua-ra épít), de eltávolodott tőle, ahogy adták hozzá a feature-öket.
vim-nél én is abszolút sorszámot használok, sortöréssel, és görgetésnél mindig a sor végére görgetődik le a képernyő, nem csúszik át sor a következő képernyőre (lastline opció). A wildmenu parancskiegészítés csak parancsmódban működik, kettőspont karakter után. Tényleg csak az abszolút minimumot használom a konfigomban. Pont amiatt, amit már írtam. Nem értek egyet azzal, hogy sokan szénné konfigolják, meg hozzáadnak 100 addont minden apró-cseprő dologhoz, és ha véletlenül vanilla vim-hez vagy vi-hoz kell leülniük, jól arcra esnek, mert nem bírják használni, hirtelen a spéci beállításaik és addontengerjük nélkül élhetetlen lesz nekik.
-
Laszlo733
aktív tag
Szia !
A Win10 -re kell tenni a boot -ot, csak azt ne formázd elég a 100MB az ugye fat32:
Így állítsd be, ha nem kell Home könyvtár:
Win -es fat32 szekesztés boot efi katt, plusz esp és boot -ot külön ráteszed
A többit ext4 és formázhatod
Ha kell swap, akkor a ext4 helyett kiválaszot a swap -et / nem tudom hogy mivel telepítesz/, külön ráteszed a swap -et pl 4GB
A gyökér / kiválasztod, majd külön ráteszed, hogy root mehet neki az összes maradék hely
Utána mehet az install és OK lesz. -
ztsoft
őstag
Sziasztok!
UEFI-s telepítéssel kapcsolatban lenne egy kérdésem. Windows 10 mellé tenném (ugyan arra a HDD-re), de arra nem találtam egyértelmű választ, hogy kell-e még egy EFI System partíció, vagy használhatom a Windows-ét (egy januári Youtube videóban csinál egy másikat)?
Amiért kérdezem, a Wiki szerint 260–512 MB kell, a Windows-é csak 100MB.
Több videóban láttam, hogy a GRUB-nak a Windows EFI System partícióját adja meg a telepítő alkalmazásban (Ubuntu és társai).
-
-
Shyciii
veterán
válasz
Archttila
#6856
üzenetére
Openbox, Awesome egyremegy. Mindkettő dinamikus WM.Ugyanazt adják részben. Mondjuk az Awesome több erőforrást használ, mint az Openbox. Xmonad már más tészta. Ő más elven működik, mert ő tiling window manager. Ráadásul a Haskell leírónyelve nem user friendly, úgyhogy pont rosszal próbálkoztál :) Mindenesetre el kellene döntened, hogy dynamic, vagy tiling WM érdekel :)
-
Archttila
veterán
Nem akarom elkiabálni, de lehet átugrom az Openbox-ot
Pár perce használom az Awesome WM-et és azt kell mondjam, hogy eddig nagyon tetszik. Igen, sajnos ez még nem Arch (nincs még itt az asztali gépem) de ami késik nem múlik... 
Tettem egy próbát az Xmonad-al, de férfiasan bevallom kevés vagyok még hozzá.
-
Frawly
veterán
válasz
Shyciii
#6854
üzenetére
Itt van a vimrc konfigom, de neked csak az első néhány sor kell (sorszámozás, sortörés, tört sor görgetése, automatikus parancskiegészítés, 24 bites színmélység, színtéma), a többi map, meg let részt még nem ajánlom, nagy részüket én se használom, a let rész meg csak azért van, ha oldalsáv nézetben fájltallózást nyitok meg vim-ben, annak a vizuális megjelenítését olvashatóbbá tegye, de ezt a feature-t is rettenet ritkán használom.
Elindulásnak a vimtutor parancsot ajánlom, meg ezt a netes játékot. Amíg megszokod a módokat, meg a szövegben mozgást.
Mikor én próbálkoztam először vim-mel, akkor elkövettem azt a hibát, hogy próbáltam annyira szénné konfigolni, hogy lényegében úgy működött, mintha csak egy normál szövegszerkesztő lett volna, működött az egér, kurzormozgató billentyűkkel navigáltam, nem kellett módot váltani, stb.. Na, ezt nem szabad, mert egyrészt így soha nem tanulja meg az ember, meg így pont az értelme, legjobb oldala veszik el.
-
Frawly
veterán
válasz
Shyciii
#6852
üzenetére
Az Xmonad nem Haswell-ben, hanem Haskell-ben van írva, de az nekem is meredek, ha ez megnyugtat. Pont a Linux OFF topikban hoztam elő ezt a funkcionális programozás témát, hogy mennyire elvont, erre le lettem oltva, hogy én vagyok hülye, mert ott a szakik a topikban már az 1930-as évek óta használják, meg möhőő, meg jóaz, nekik tökéletesen érthető. Értem, akkor májerkedjenek csak.
vim/neovim mindegy, de idő megtanulni. Nem is a billentyűk jelentését, hanem amikor vim-ben szerkesztesz, sok szövegszerkesztési problémát át kell fogalmazni, nem úgy kell csinálni, ahogy hagyományos editorokban. A vim ugyanis nem arra a filozófiára épül, mint egy hagyományos text editor, hanem egyfajta interaktív sed-nek lehet tekinteni, és inkább text processornak lehet nevezni. Külön meg kell szokni a módokat, az egésznek a logikáját, elsőre idegen lesz. Nekem is nagyon sokszor neki kellett futnom, mire sikerült megszoknom. A lényeg, hogy mikor tanulod, akkor nem a billentyűk memorizálása a legfontosabb, hanem egy újfajta gondolkodás elsajátítása. Eleinte idegen érzés lesz nagyon, mintha az orroddal vagy a lábujjaiddal kéne szövegszerkeszteni, nehezen boldogul vele, aki még csak most kezdte tanulni, türelmet igényel. Érnie kell a folyamatnak, ahogy formálja a gondolkodásod, nem lehet sürgetni, meg siettetni.
Meg igazából a vim-nek akkor van értelme igazán, ha tudsz gépírni. Az egész úgy van tervezve, hogy gépírástartásból legyen vezérelve, és nem nyúlsz ki onnan egérhez, kurzormozgató billentyűkhöz, stb.. A vim egyfajta speciális gondolkodásról, filozófiáról szól, amit ha megtanulsz, nem csak szövegszerkesztésre tudsz használni, hanem mindenfajta szoftver vezérlésére, vim billentyűkiosztást és logikát fogsz használni mindenhol, shell, terminál, fájlkezelő, böngésző, ablakkezelő, médialejátszók, stb.. Lényegében a gépet fogod teljesen máshogy használni, azt fogja eredményezni.
Egy jótanács: mindegy, hogy vim vagy neovim, ha tanulod, akkor próbáld alapállapotában használni, ne konfigold szét őket a saját jelenlegi berögződéseidhez. Ha változtatsz is a konfigon, csak egyszerű dolgokat, sorszámozás, sortörés, magyar nyelvi helyesírás-ellenőrző használata, stb., azaz csak pár sornyi alap dolgot tegyél bele a vimrc-be, de billentyűket ne nagyon szabj át, meg addonokat se telepíts, mert úgy nem a vim-et fogod megtanulni, hanem a saját konfigod használatát.
-
Shyciii
veterán
BoB, Frawly
Hát akkor mikor lesz hosszabb időm, akkor elkezdem tanulgatni a regexp-et, de most kb úgy állok hozzá, mint az Xmonad Haswell-jében írt configjához: a hideg kiráz tőle
Először még a neovim-et szeretném kipróbálomni, hogy meg tudom-e szokni szövegszerkesztélésre. Ha nem, akkor marad a sublime. -
ztsoft
őstag
Én is cserélek, igaz, maradok laptopnál (nekem elég ez is) meg Intel-nél (T7200 -> I3-6006U), de nálam minden csere lesz, HDD is. Eljött az ideje, hogy az Acer Aspire 5310-est lecseréljem egy Aspire 3-asra (I3-6006U, DDR4, HD520). Eddig jók a tapasztalatok, Kubuntu 20.04-es Live-al néztem (semmi extra beállítás), böngészőben Youtube 4K közel 90%-os CPU terhelésen ment. Jövő hónapban jön még az SSD, meg RAM bővítés és egy darabig ez is kiszolgál. Addig gyakorlom az Arch telepítést (a Win10-en már túl vagyok, sajnos néha elő kell vennem).
Nem igazán értem a Win10-et, gyári driver-ek, támogatás, mégis szarul működik. Eldobálja a Wi-Fi-t (úgy vettem észre, hogy nem volt bekapcsolva az auto csatlakozás), saját maga alatt lelövi a HDD (halottam, hogy kattant), úgy, hogy közben használtam. A Kubuntu alatt viszont tökéletesen működött minden.
-
Frawly
veterán
válasz
#63718632
#6849
üzenetére
Az végül is a teljesítmény szempontjából nem annyira releváns, hogy milyen formában érkezik. Ezek a brand céges gépek annyiból hátrányosak csak, hogy nem fogadnak sztenderd tápot, hanem csak spéci jó bele, ami miatt nehéz bővíteni, meg dedikált GPU-ból is általában csak alacsony profilú jó beléjük. Meg a brand BIOS miatt nem lehet tuningolni őket.
A Haswell jó tartja magát CPU erőben, 4 magnál főleg, kellően magas órajel, IPC, cache. Főleg, ha később lemegy az ára, akár felbővíthetsz i7-4770-4790(k)-re is, egyelőre az még nem éri meg, túl van árazva a használt piacon, de majd a Ryezenek miatt le fog menni az ára. Nem is értem miért van fent az ára ennyire a 4. gen-es használt inteleknek. Ahogy nézem, ezek még nem is DDR4-esek, csak 3-asok. Egy használt i7-4790(k) árában kb. egy új Ryzen 1600(AF)-et kapni valami B450-es lappal, egyedül annyi veszteség van, hogy ahhoz már DDR4-es memória kell.
Egyedül a Haswellbe beleintegrált HD4600 GPU nem valami fényességes, az előző generációkhoz képest +60%-kal gyorsabb, de az újabbaktól elmarad, meg nincs benne Vulkan, DX12, OpengGL 4.5, Iris driver támogatás, ennyiből nem öregedett jól. Meg hardveres dekódolásnál sem tud VP8-9-et, HEVC-t, és 60 fps-es 4K-val sem tudom hogy áll, arról nincs infó a neten.
Úgyhogy hosszú távon szerezz be egy olcsó, használt RX560-570, RX470 kártyát, azoknak a linuxos támogatása is nagyon jó (nem kell zárt driverrel szívni, mint NV-nál), meg mindent támogatnak, teljesítményben is jók.
-
Frawly
veterán
válasz
#63718632
#6847
üzenetére
Önmagában még a Win10 elfutogat ilyenen, főleg, ha SSD van alatta, ami nagyon kell is a 10 alá. De ahogy böngészel rajta, meg még fut más is a háttérben, az erőforrások jobban fogynak, mint Linuxon. Az AMD szinte mindig felejtős volt mobil CPU-k terén, most jöttek fel a Ryzen 2xxxU-4xxxU sorozattal az Intel mobil CPU-k szintjére. Prociba integrált GPU-ban mindig is verték az Intelt, ami továbbra is mellettük szól, mert olyan laptopokban, amelyekben nincs dedikált GPU, az IGP sokat számít azonos procierő mellett.
-
Frawly
veterán
Frissítésnél opció lett volna a pacman --overwrite kapcsoló helyett a vonatkozó fájlok eltávolítása rm paranccsal, de azt kockázatosnak ítéltem, féltem, hogy letörölve őket működésképtelen lesz a rendszer. Főleg az ilyen polkites cumók veszélyesek, pont hasonló polkit-mókával küldtem már halálba Arch telepítést, ilyeneket nem szívesen törölgetek.
-
Frawly
veterán
válasz
Shyciii
#6841
üzenetére
Vifm-ből hívott csoportos átnevezés vim-ben grep/sed-szintaxissal:
:%s/[0-9]{2}/0\0/gNem teszteltem, de azt kéne csinálnia, amit írsz, a kétjegyű számokat (de csak azokat) átcseréli háromjegyűre. Ha látod a listán, hogy helyesen cserélt le mindent, a végén ZZ billentyűkkel kilépsz vim-ből, és visszakapod a Vifm-et, az átnevezett fájlokkal.
A „:” parancsmódba teszi le a vim-et, az „s” a substition rövidítése/parancsa (általános alakja s/keresett/cserestring/ formában szokásos), előtte a % jel azt jelenti, hogy az összes sorban hajtsa végre, ne csak az első sorban, a „g” a végén meg a global rövidítése, ami miatt egy soron belüli többször előfordulásokat is lecserél, ez az esetünkben nem szükséges, mert egy sorban egy egyezés lesz, de én megszokásból mindig gyűröm a végére a g-t. A [0-9] számjegyet jelent, a {2} pontosan két előfordulást egymás után (lehetne [0-9][0-9] formában is írni), a \0 a keresett kifejezést teszi oda az extra 0 után pluszban.
Nem árt megtanulni regexp-pül, mert nem csak csoportos átnevezéshez jön jól, de scriptekben, meg úgy általában linuxoknál, Unix-származékoknál, programozásnál, nem csak vim-ben, de bármilyen regexp képes editorban, prognyelvben, terminálban grep/sed-hez, még a Total Commander, Double Commander is támogatja alternatívaként a saját regexp formátumán felül. Előnye, hogy a Commader-ek [bla][bla] regexpjénél többet tud, rugalmasabb, igaz bonyolultabb is, és nehezebben olvasható.
Az awk-t én sem szeretem, túl bonyolult a szintaxisa, de ha oszlopszerű adathalmazból akarsz kinyerni oszlopokat, akkor arra viszont könnyebben használható, mint egy posix/grep/perl regexp.
(#6842) májkimiki: ez ilyen. Főleg, ha ilyen 2 magos, 2 szálas példányod van (vannak erősebb, 4 magos, 4 szálas modellek is), nuku L3 cache, alacsony órajel, alacsony IPC. Ahogy nézem, még hardveres virtualizációt sem támogat. Ha ez vigasztal, Windows alatt még sokkal rosszabb lenne.
-
#63718632
törölt tag
Na ettől kapok agyf.........t!
[link]
Nagyjából 3 és fél órája volt rendszerindítás. FF-ban megnyitva 4 lap: PH Fórum, LM.hu, Ubi.hu, HUP.hu, Distrowatch, Tutanota és a Google kezdőlapja. Az idő előrehaladtával egyre jobban lassúl, proci az egekben.
FF addon-ok: Ublock Origin, PrivacyBadger, Disconnect, CookieAutoDelete, NoScript, FB Container.
Chromium addon-ok: NoScript és FB Container kivételével uazok.
Brave-t próbáltam másik rendszeren hasonló setup-al, szintén lassul. Talán a legkedvezőbb mértékben.
Azzal meg itt bajban vagyok, mert AUR-ból jönne. De a build vége felé elszáll checksum hibával.
Legszívesebben kivágnám az ablakon a notit A6-ostúl, -stúl, -stúl, -stúl.
-
Shyciii
veterán
Ezt jó, de az a bajom vele, hogy a szintaxisa számomra totál elbonyolított (hasonlóan mint az awk, vagy sed parancsé). Míg totál érthető a Double Commander és Total Commander megoldása (még a hülyéknek is), addig ez azért eléggé el van bonyolítva.
Pl ahogy most nézek egy példát:
image_10.jpg -> image_010.jpg (lényeg hogy minden image_szám file esetén 3 jegyű legyen a számozás).
megoldás: perl-rename -n 's{^(.*/)?(.*_)(\d+)([.][^.]+)$}{sprintf "%s%s%03d%s", $1, $2, $3, $4}e' * (ezt találtam rá egy fórumban)
Ugyanez Double Commander alatt be kell állíítani, hogy a számláló 3 karakter legyen, majd ennyi a szintaxis: [N1:6][C].[E]
Kész. Totál egyszerű, míg a perl-rename egy halandónak totál katyvasz
-
Frawly
veterán
válasz
Shyciii
#6838
üzenetére
Vifm-nek nincs saját csoportos átnevezés-lehetősége. Vagyis van, de az nem saját, hanem más programot hív meg. Alapból úgy van a konfigja megírva, hogy a vim-et hívja meg, abban van a fájllista, amit kijelöltél, ott lenyomatod regexp mintákkal meg tételesen, hogy mit mire akarsz átnevezni, mentesz és kilépsz, és maguktól átneveződnek a fájlok, mappák.
Tehát alapból kijelölöd a fájlokat, majd cw, és előjön a vim, ha fent van nálad. De elvileg bármilyen szövegszerkesztőből csinálhatod, akár nano, akár más, akár még grafikus GUI editor is lehet, csak akkor a vifmrc-ben a vicmd-t át kell írni. A lényeg, hogy tudjon regexp mintákkal dolgozni a text editor.
Az Arch frissítés most nálam is problémás volt. Nem tört el semmit, jól működik a rendszer, de a frissítés nem akart lemenni, nss és lib32-nss lowfax miatt, /usr/lib/p11-kit-trust.so és /usr/lib32/p11-kit-trust.so fájlok már léteztek a rendszeren. Az --overwrite kapcsolót használva viszont már rendben lement a frissítés, és reboot után bugmentesen működik tovább a rendszer. Persze Archon is ritkán van ennyire durva frissítési hullám, évente max. 1-2×. Legtöbbször egy hét alatt max. csak ilyen 10-20 csomag jön össze 100-200 MiB terjedelemben (nálam), és azoknak a frissítése sem szokott problémás lenni.
-
Shyciii
veterán
Valamelyikőtök régen azt mondta, hogy ezzel a kapcsolóval kierőszakoljuk ugye a csomaglisták frissítését, így biztos azonnal láthatóak az új csomagok, míg ennélkül lehet, hogy csak pár óra múlva "kapcsol észbe" a rendszer.
Mostmár jó ideje a vifm-et használom, és azt kell mondjam, hogy szeretem használni. Egy nagy hátránya van a Double Commanderrel szemben: a csoportos átnevezés lehetősége. Ez ugyanaz, mint ami a Windows-os TOtal Commanderben is van, hogy változókatm szabályokat lehet beállítani, hogy hogyan nevezzen át sok file-t. Időnként kell ilyet használnom, úgyhogy arra a kis időszakra lehet hogy visszarakom a Double Commander-t, majd mikor kész, akkor uninstall. -
Frawly
veterán
válasz
#63718632
#6831
üzenetére
Az biztos, hogy nagy előrelépés lesz az az újabb asztali konfig egy mobil AMD-s laptophoz képest. Az A6 asztali változatban sem túl erős proci, az A-s sorozatból szerintem az asztali A10, ami minimálisan elmegy szódával.
Asztali gép további előnye, hogy könnyebben bővíthető. Ha most a 4. gen i5 alatt már DDR4-et használsz, akkor később nem nagy befektetéssel váltasz Ryzen platformra, amihez csak procit és lapot kell venned, ami nem olyan rettenet nagy pénz, ha nem a legfelső kategóriából veszed. De ezzel a 4. gen i5-tel is el lehet lenni még hosszú évekig. Főleg olyan lájtos felhasználással, ha csak 10 fülön böngészel, meg linuxozol (ami eleve erőforrástakarékosabb, mint a Windows), arra még overkill is.
(#6836) Shyciii: elvileg a -Syu is elég. Az Syyu csak annyival több, hogy az mindenképp kierőszakolja a csomaglisták letöltését a tárolókból, akkor is, ha a legutóbbi listák óta nem történt benne módosulás. Ezt akkor érdemes csak megcsinálni, ha új tárolót vettél fel, de elvileg akkor sem muszáj.
Egyébként most engem is nyakon öntött egy nagy frissítés, így hogy beszélünk róla, nyomtam neki én is. 1 hete frissítettem, és mégis 401 csomag frissül 1276 MiB terjedelemben, és 5220 MiB-ot módosít a rendszeren
Előtte 2 hónapig nem frissítettem, és annyi idő alatt jött össze ugyanennyi frissítés, most meg 1 hét alatt, ez nem semmi. Az én update-em még nem futott le, de én nem számítok problémára, a pálcika WM meg a terminálos cuccok nem nagyon tudnak eltörni, annyi egyszerűek, hogy nincs rajtuk semmi bonyolítás. -
Siriusb
veterán
válasz
_Dumber_
#6833
üzenetére
Nekem is ez volt, lefuttattam egy frissítést, de nem jött új kde csomag tegnap óta. Újraindítottam az X-et, azután legalább a krunner működött, hát parancsoltam:
kquitapp5 plasmashell
és
kstart5 plasmashell
Így most megy, de újraindítás nem volt.Szerk.:
Hopp, mesa volt a ludas: https://bbs.archlinux.org/viewtopic.php?id=255761 -
_Dumber_
őstag
Sziasztok
A tegnapi frisstés hazavágta a rendszerem.. illetve él, de így kicsit macera dolgozni vele.
KDE:
Bejelentkezni enged, az automatikusan induló programok mind működnek, shortcut-ról bármit tudok indítani, miután a teminal fut onnan is bármi elindul.
Ami nem megy: nincs háttérkép, nincsenek ikonok, nincs tálca, nincs egérművelet a kmunkaterületen. Bámilyen munkaterület configgal kapcsolatos tevékegység alatt elszáll a systemconfig. Magyarán a munkaterület nem megy.
Melyik program felelős ezért? MIt probáljak downgradelni? A plasma-framwork már megvolt, de nem lett jobb.Tegnapi frissítési lista:
[2020-05-15T21:41:28+0200] [ALPM] upgraded linux-api-headers (5.4.17-1 -> 5.6.11-1)
[2020-05-15T21:41:29+0200] [ALPM] upgraded glibc (2.31-2 -> 2.31-3)
[2020-05-15T21:41:31+0200] [ALPM] upgraded gcc-libs (9.3.0-1 -> 10.1.0-1)
[2020-05-15T21:41:31+0200] [ALPM] upgraded libtool (2.4.6+42+gb88cebd5-12 -> 2.4.6+42+gb88cebd5-13)
[2020-05-15T21:41:31+0200] [ALPM] upgraded imagemagick (7.0.10.11-1 -> 7.0.10.11-3)
[2020-05-15T21:41:31+0200] [ALPM] upgraded libsasl (2.1.27-2 -> 2.1.27-3)
[2020-05-15T21:41:31+0200] [ALPM] upgraded a2ps (4.14-9 -> 4.14-10)
[2020-05-15T21:41:31+0200] [ALPM] upgraded a52dec (0.7.4-10 -> 0.7.4-11)
[2020-05-15T21:41:31+0200] [ALPM] upgraded aalib (1.4rc5-13 -> 1.4rc5-14)
[2020-05-15T21:41:32+0200] [ALPM] upgraded linux (5.6.11.arch1-1 -> 5.6.12.arch1-1)
[2020-05-15T21:41:32+0200] [ALPM] upgraded acpi_call (1.1.0-316 -> 1.1.0-319)
[2020-05-15T21:41:33+0200] [ALPM] upgraded linux-lts (5.4.39-1 -> 5.4.40-1)
[2020-05-15T21:41:33+0200] [ALPM] upgraded acpi_call-lts (1.1.0-144 -> 1.1.0-147)
[2020-05-15T21:41:33+0200] [ALPM] upgraded mesa (20.0.6-2 -> 20.0.7-1)
[2020-05-15T21:41:33+0200] [ALPM] upgraded signon-kwallet-extension (20.04.0-1 -> 20.04.1-1)
[2020-05-15T21:41:33+0200] [ALPM] upgraded btrfs-progs (5.6-1 -> 5.6.1-1)
[2020-05-15T21:41:33+0200] [ALPM] upgraded kio (5.70.0-1 -> 5.70.0-3)
[2020-05-15T21:41:33+0200] [ALPM] upgraded kaccounts-integration (20.04.0-1 -> 20.04.1-1)
[2020-05-15T21:41:33+0200] [ALPM] upgraded libakonadi (20.04.0-1 -> 20.04.1-1)
[2020-05-15T21:41:34+0200] [ALPM] upgraded mariadb-libs (10.4.12-1 -> 10.4.13-1)
[2020-05-15T21:41:34+0200] [ALPM] upgraded mariadb-clients (10.4.12-1 -> 10.4.13-1)
[2020-05-15T21:41:34+0200] [ALPM] upgraded mariadb (10.4.12-1 -> 10.4.13-1)
[2020-05-15T21:41:34+0200] [ALPM] upgraded akonadi (20.04.0-1 -> 20.04.1-1)
[2020-05-15T21:41:34+0200] [ALPM] upgraded kmime (20.04.0-2 -> 20.04.1-1)
[2020-05-15T21:41:34+0200] [ALPM] upgraded akonadi-mime (20.04.0-1 -> 20.04.1-1)
[2020-05-15T21:41:34+0200] [ALPM] upgraded ksmtp (20.04.0-1 -> 20.04.1-1)
[2020-05-15T21:41:34+0200] [ALPM] upgraded libkgapi (20.04.0-1 -> 20.04.1-1)
[2020-05-15T21:41:34+0200] [ALPM] upgraded kmailtransport (20.04.0-1 -> 20.04.1-1)
[2020-05-15T21:41:34+0200] [ALPM] upgraded kpimtextedit (20.04.0-1 -> 20.04.1-1)
[2020-05-15T21:41:34+0200] [ALPM] upgraded kidentitymanagement (20.04.0-1 -> 20.04.1-1)
[2020-05-15T21:41:34+0200] [ALPM] upgraded kcalutils (20.04.0-1 -> 20.04.1-1)
[2020-05-15T21:41:34+0200] [ALPM] upgraded akonadi-contacts (20.04.0-1 -> 20.04.1-1)
[2020-05-15T21:41:34+0200] [ALPM] upgraded akonadi-calendar (20.04.0-1 -> 20.04.1-1)
[2020-05-15T21:41:34+0200] [ALPM] upgraded libkleo (20.04.0-1 -> 20.04.1-1)
[2020-05-15T21:41:34+0200] [ALPM] upgraded plasma-framework (5.70.0-1 -> 5.70.1-1)
[2020-05-15T21:41:34+0200] [ALPM] upgraded akonadi-search (20.04.0-1 -> 20.04.1-1)
[2020-05-15T21:41:34+0200] [ALPM] upgraded kldap (20.04.0-1 -> 20.04.1-1)
[2020-05-15T21:41:34+0200] [ALPM] upgraded libkdepim (20.04.0-1 -> 20.04.1-1)
[2020-05-15T21:41:34+0200] [ALPM] upgraded kimap (20.04.0-1 -> 20.04.1-1)
[2020-05-15T21:41:34+0200] [ALPM] upgraded pimcommon (20.04.0-1 -> 20.04.1-1)
[2020-05-15T21:41:34+0200] [ALPM] upgraded grantleetheme (20.04.0-1 -> 20.04.1-1)
[2020-05-15T21:41:34+0200] [ALPM] upgraded kdepim-apps-libs (20.04.0-1 -> 20.04.1-1)
[2020-05-15T21:41:34+0200] [ALPM] upgraded calendarsupport (20.04.0-1 -> 20.04.1-1)
[2020-05-15T21:41:35+0200] [ALPM] upgraded akonadi-calendar-tools (20.04.0-1 -> 20.04.1-1)
[2020-05-15T21:41:35+0200] [ALPM] upgraded mailimporter (20.04.0-1 -> 20.04.1-1)
[2020-05-15T21:41:35+0200] [ALPM] upgraded libgravatar (20.04.0-1 -> 20.04.1-1)
[2020-05-15T21:41:35+0200] [ALPM] upgraded kmbox (20.04.0-1 -> 20.04.1-1)
[2020-05-15T21:41:35+0200] [ALPM] upgraded messagelib (20.04.0-1 -> 20.04.1-1)
[2020-05-15T21:41:35+0200] [ALPM] upgraded mailcommon (20.04.0-1 -> 20.04.1-1)
[2020-05-15T21:41:35+0200] [ALPM] upgraded akonadi-import-wizard (20.04.0-1 -> 20.04.1-1)
[2020-05-15T21:41:35+0200] [ALPM] upgraded akonadi-notes (20.04.0-1 -> 20.04.1-1)
[2020-05-15T21:41:35+0200] [ALPM] upgraded akonadiconsole (20.04.0-1 -> 20.04.1-1)
[2020-05-15T21:41:35+0200] [ALPM] upgraded kontactinterface (20.04.0-1 -> 20.04.1-1)
[2020-05-15T21:41:35+0200] [ALPM] upgraded ktexteditor (5.70.0-1 -> 5.70.1-1)
[2020-05-15T21:41:35+0200] [ALPM] upgraded akregator (20.04.0-1 -> 20.04.1-1)
[2020-05-15T21:41:35+0200] [ALPM] upgraded alsa-plugins (1.2.2-1 -> 1:1.2.2-2)
[2020-05-15T21:41:35+0200] [ALPM] upgraded analitza (20.04.0-1 -> 20.04.1-1)
[2020-05-15T21:41:35+0200] [ALPM] upgraded appstream (0.12.10-2 -> 0.12.11-1)
[2020-05-15T21:41:35+0200] [ALPM] upgraded appstream-qt (0.12.10-2 -> 0.12.11-1)
[2020-05-15T21:41:35+0200] [ALPM] upgraded ark (20.04.0-1 -> 20.04.1-1)
[2020-05-15T21:41:35+0200] [ALPM] upgraded artikulate (20.04.0-1 -> 20.04.1-1)
[2020-05-15T21:41:35+0200] [ALPM] upgraded baloo-widgets (20.04.0-1 -> 20.04.1-1)
[2020-05-15T21:41:35+0200] [ALPM] upgraded binutils (2.34-2 -> 2.34-3)
[2020-05-15T21:41:35+0200] [ALPM] upgraded blinken (20.04.0-1 -> 20.04.1-1)
[2020-05-15T21:41:35+0200] [ALPM] upgraded cantor (20.04.0-1 -> 20.04.1-1)
[2020-05-15T21:41:35+0200] [ALPM] upgraded openexr (2.4.1-2 -> 2.5.1-1)
[2020-05-15T21:41:35+0200] [ALPM] upgraded kio-extras (20.04.0-1 -> 20.04.1-1)
[2020-05-15T21:41:35+0200] [ALPM] upgraded dolphin (20.04.0-1 -> 20.04.1-1)
[2020-05-15T21:41:35+0200] [ALPM] upgraded dolphin-plugins (20.04.0-1 -> 20.04.1-1)
[2020-05-15T21:41:35+0200] [ALPM] upgraded eventviews (20.04.0-1 -> 20.04.1-1)
[2020-05-15T21:41:36+0200] [ALPM] upgraded fftw (3.3.8-2 -> 3.3.8-3)
[2020-05-15T21:41:36+0200] [ALPM] upgraded filelight (20.04.0-1 -> 20.04.1-1)
[2020-05-15T21:41:36+0200] [ALPM] upgraded freerdp (1:2.0.0_rc4-8 -> 2:2.1.0-1)
[2020-05-15T21:41:36+0200] [ALPM] upgraded gcc (9.3.0-1 -> 10.1.0-1)
[2020-05-15T21:41:36+0200] [ALPM] upgraded gdb-common (9.1-2 -> 9.1-3)
[2020-05-15T21:41:36+0200] [ALPM] upgraded gdb (9.1-2 -> 9.1-3)
[2020-05-15T21:41:36+0200] [ALPM] upgraded gegl (0.4.22-1 -> 0.4.22-3)
[2020-05-15T21:41:37+0200] [ALPM] upgraded gimp (2.10.18-6 -> 2.10.18-8)
[2020-05-15T21:41:37+0200] [ALPM] upgraded grantlee-editor (20.04.0-1 -> 20.04.1-1)
[2020-05-15T21:41:37+0200] [ALPM] upgraded grub (2:2.04-6 -> 2:2.04-7)
[2020-05-15T21:41:37+0200] [ALPM] upgraded gst-plugins-bad-libs (1.16.2-9 -> 1.16.2-11)
[2020-05-15T21:41:37+0200] [ALPM] upgraded zvbi (0.2.35-3 -> 0.2.35-4)
[2020-05-15T21:41:37+0200] [ALPM] upgraded gst-plugins-bad (1.16.2-9 -> 1.16.2-11)
[2020-05-15T21:41:37+0200] [ALPM] upgraded gtkspell (2.0.16-7 -> 2.0.16-8)
[2020-05-15T21:41:37+0200] [ALPM] upgraded libkipi (20.04.0-1 -> 20.04.1-1)
[2020-05-15T21:41:37+0200] [ALPM] upgraded libkdcraw (20.04.0-1 -> 20.04.1-1)
[2020-05-15T21:41:37+0200] [ALPM] upgraded gwenview (20.04.0-2 -> 20.04.1-1)
[2020-05-15T21:41:37+0200] [ALPM] upgraded incidenceeditor (20.04.0-1 -> 20.04.1-1)
[2020-05-15T21:41:37+0200] [ALPM] upgraded libkcddb (20.04.0-1 -> 20.04.1-1)
[2020-05-15T21:41:37+0200] [ALPM] upgraded k3b (1:20.04.0-1 -> 1:20.04.1-1)
[2020-05-15T21:41:37+0200] [ALPM] upgraded kaccounts-providers (20.04.0-1 -> 20.04.1-1)
[2020-05-15T21:41:37+0200] [ALPM] upgraded kdav (20.04.0-1 -> 20.04.1-1)
[2020-05-15T21:41:37+0200] [ALPM] upgraded kalarmcal (20.04.0-1 -> 20.04.1-1)
[2020-05-15T21:41:37+0200] [ALPM] upgraded kdepim-runtime (20.04.0-1 -> 20.04.1-1)
[2020-05-15T21:41:37+0200] [ALPM] upgraded kaddressbook (20.04.0-1 -> 20.04.1-1)
[2020-05-15T21:41:37+0200] [ALPM] upgraded kalarm (20.04.0-1 -> 20.04.1-1)
[2020-05-15T21:41:37+0200] [ALPM] upgraded kalgebra (20.04.0-1 -> 20.04.1-1)
[2020-05-15T21:41:38+0200] [ALPM] upgraded kalzium (20.04.0-2 -> 20.04.1-1)
[2020-05-15T21:41:38+0200] [ALPM] upgraded kdeedu-data (20.04.0-1 -> 20.04.1-1)
[2020-05-15T21:41:38+0200] [ALPM] upgraded libkeduvocdocument (20.04.0-1 -> 20.04.1-1)
[2020-05-15T21:41:38+0200] [ALPM] upgraded kanagram (20.04.0-1 -> 20.04.1-1)
[2020-05-15T21:41:38+0200] [ALPM] upgraded kate (20.04.0-1 -> 20.04.1-1)
[2020-05-15T21:41:38+0200] [ALPM] upgraded kbruch (20.04.0-1 -> 20.04.1-1)
[2020-05-15T21:41:38+0200] [ALPM] upgraded kcalc (20.04.0-1 -> 20.04.1-1)
[2020-05-15T21:41:38+0200] [ALPM] upgraded kdeconnect (20.04.0-1 -> 20.04.1-1)
[2020-05-15T21:41:38+0200] [ALPM] upgraded kdegraphics-mobipocket (20.04.0-1 -> 20.04.1-1)
[2020-05-15T21:41:38+0200] [ALPM] upgraded ktnef (20.04.0-1 -> 20.04.1-1)
[2020-05-15T21:41:38+0200] [ALPM] upgraded libksieve (20.04.0-1 -> 20.04.1-1)
[2020-05-15T21:41:38+0200] [ALPM] upgraded kpkpass (20.04.0-1 -> 20.04.1-1)
[2020-05-15T21:41:38+0200] [ALPM] upgraded kitinerary (20.04.0-2 -> 20.04.1-1)
[2020-05-15T21:41:38+0200] [ALPM] upgraded kdepim-addons (20.04.0-1 -> 20.04.1-1)
[2020-05-15T21:41:38+0200] [ALPM] upgraded kdialog (20.04.0-1 -> 20.04.1-1)
[2020-05-15T21:41:38+0200] [ALPM] upgraded kgeography (20.04.0-1 -> 20.04.1-1)
[2020-05-15T21:41:38+0200] [ALPM] upgraded khangman (20.04.0-1 -> 20.04.1-1)
[2020-05-15T21:41:38+0200] [ALPM] upgraded kig (20.04.0-1 -> 20.04.1-1)
[2020-05-15T21:41:38+0200] [ALPM] upgraded kiten (20.04.0-1 -> 20.04.1-1)
[2020-05-15T21:41:38+0200] [ALPM] upgraded kleopatra (20.04.0-1 -> 20.04.1-1)
[2020-05-15T21:41:39+0200] [ALPM] upgraded klettres (20.04.0-1 -> 20.04.1-1)
[2020-05-15T21:41:39+0200] [ALPM] upgraded kmail-account-wizard (20.04.0-1 -> 20.04.1-1)
[2020-05-15T21:41:39+0200] [ALPM] upgraded mbox-importer (20.04.0-1 -> 20.04.1-1)
[2020-05-15T21:41:39+0200] [ALPM] upgraded pim-data-exporter (20.04.0-1 -> 20.04.1-1)
[2020-05-15T21:41:39+0200] [ALPM] upgraded pim-sieve-editor (20.04.0-1 -> 20.04.1-1)
[2020-05-15T21:41:39+0200] [ALPM] upgraded kmail (20.04.0-1 -> 20.04.1-1)
[2020-05-15T21:41:39+0200] [ALPM] upgraded kmplot (20.04.0-1 -> 20.04.1-1)
[2020-05-15T21:41:39+0200] [ALPM] upgraded knotes (20.04.0-1 -> 20.04.1-1)
[2020-05-15T21:41:39+0200] [ALPM] upgraded konsole (20.04.0-1 -> 20.04.1-1)
[2020-05-15T21:41:39+0200] [ALPM] upgraded kontact (20.04.0-1 -> 20.04.1-1)
[2020-05-15T21:41:39+0200] [ALPM] upgraded korganizer (20.04.0-1 -> 20.04.1-1)
[2020-05-15T21:41:39+0200] [ALPM] upgraded kqtquickcharts (20.04.0-1 -> 20.04.1-1)
[2020-05-15T21:41:39+0200] [ALPM] upgraded krdc (20.04.0-1 -> 20.04.1-1)
[2020-05-15T21:41:39+0200] [ALPM] upgraded ktouch (20.04.0-1 -> 20.04.1-1)
[2020-05-15T21:41:39+0200] [ALPM] upgraded kturtle (20.04.0-1 -> 20.04.1-1)
[2020-05-15T21:41:39+0200] [ALPM] upgraded kwalletmanager (20.04.0-1 -> 20.04.1-1)
[2020-05-15T21:41:39+0200] [ALPM] upgraded kwordquiz (20.04.0-1 -> 20.04.1-1)
[2020-05-15T21:41:39+0200] [ALPM] upgraded lib32-glibc (2.31-2 -> 2.31-3)
[2020-05-15T21:41:40+0200] [ALPM] upgraded lib32-gcc-libs (9.3.0-1 -> 10.1.0-1)
[2020-05-15T21:41:40+0200] [ALPM] upgraded libkexiv2 (20.04.0-1 -> 20.04.1-1)
[2020-05-15T21:41:40+0200] [ALPM] upgraded marble-common (20.04.0-1 -> 20.04.1-1)
[2020-05-15T21:41:40+0200] [ALPM] upgraded libkgeomap (20.04.0-1 -> 20.04.1-1)
[2020-05-15T21:41:40+0200] [ALPM] upgraded libksane (20.04.0-1 -> 20.04.1-1)
[2020-05-15T21:41:40+0200] [ALPM] upgraded libmagick6 (6.9.11.10-1 -> 6.9.11.11-2)
[2020-05-15T21:41:44+0200] [ALPM] upgraded linux-headers (5.6.11.arch1-1 -> 5.6.12.arch1-1)
[2020-05-15T21:41:47+0200] [ALPM] upgraded linux-lts-headers (5.4.39-1 -> 5.4.40-1)
[2020-05-15T21:41:47+0200] [ALPM] upgraded marble (20.04.0-1 -> 20.04.1-1)
[2020-05-15T21:41:47+0200] [ALPM] upgraded minuet (20.04.0-1 -> 20.04.1-1)
[2020-05-15T21:41:47+0200] [ALPM] upgraded okular (20.04.0-1 -> 20.04.1-1)
[2020-05-15T21:41:47+0200] [ALPM] upgraded opencv (4.3.0-5 -> 4.3.0-7)
[2020-05-15T21:41:48+0200] [ALPM] upgraded parley (20.04.0-1 -> 20.04.1-1)
[2020-05-15T21:41:48+0200] [ALPM] upgraded pipewire (0.3.4-1 -> 0.3.5-1)
[2020-05-15T21:41:48+0200] [ALPM] upgraded print-manager (20.04.0-1 -> 20.04.1-1)
[2020-05-15T21:41:48+0200] [ALPM] upgraded pulseaudio-alsa (2-5 -> 1:1.2.2-2)
[2020-05-15T21:41:48+0200] [ALPM] upgraded python-appdirs (1.4.3-5 -> 1.4.4-1)
[2020-05-15T21:41:48+0200] [ALPM] upgraded python-beaker (1.11.0-3 -> 1.11.0-4)
[2020-05-15T21:41:48+0200] [ALPM] upgraded python-setuptools (1:46.2.0-1 -> 1:46.3.0-1)
[2020-05-15T21:41:48+0200] [ALPM] upgraded python2-appdirs (1.4.3-5 -> 1.4.4-1)
[2020-05-15T21:41:48+0200] [ALPM] upgraded rocs (20.04.0-1 -> 20.04.1-1)
[2020-05-15T21:41:48+0200] [ALPM] upgraded spectacle (20.04.0-1 -> 20.04.1-1)
[2020-05-15T21:41:48+0200] [ALPM] upgraded step (20.04.0-1 -> 20.04.1-1)
[2020-05-15T21:41:48+0200] [ALPM] upgraded telepathy-kde-accounts-kcm (20.04.0-1 -> 20.04.1-1)
[2020-05-15T21:41:48+0200] [ALPM] upgraded vigra (1.11.1-22 -> 1.11.1-24)
[2020-05-15T21:41:48+0200] [ALPM] upgraded w3m (0.5.3.git20190105-1 -> 0.5.3.git20200507-1)
[2020-05-15T21:41:48+0200] [ALPM] upgraded xorg-xvinfo (1.1.4-1 -> 1.1.4-2)
[2020-05-15T21:41:48+0200] [ALPM] upgraded xorg-xwininfo (1.1.5-1 -> 1.1.5-2)
[2020-05-15T21:44:32+0200] [ALPM] upgraded package-query (1.10-1 -> 1.11-1) -
#63718632
törölt tag
Remélem érezhető javulást hoz az új konfig. Ettől a mobil A6 APU-tól már a hideg ráz. A CPU része nagyon renyhe, állandóan a maxon pörög a kihasználtság. Pedig csak jobbára böngészek, igaz 10 fölötti nyitott lapok vannak általában/böngésző. Kín kivárni mire ráfrissítek vagy visszaképek egy oldalon. Nem beszélve, ha még YT is van közben.
Hajlamos olyanra is, ha ott hagyom pár órára nyitott munkamenettel, restartolni kell mert a plafont veri a cpu indikátor és semmit nem lehet csinálni. Memória minimális a 6GB-ból és nem is swapol. A CPU viszont be van akadva. Szóval nem mindig érzem az SSD feelinget. Öreg fos Satellite, megérett a cserére. -
Frawly
veterán
válasz
#63718632
#6829
üzenetére
Az ilyen hardverdekódolásos témánál lehet fent többféle csomag is, nem vesznek össze, legfeljebb nem használja azokat, amiket nem tud használni, mert nem relevánsak az adott GPU-hoz. Ez nem olyan, mint a GPU driver, hogy ha elcseszed, akkor nincs grafikus felületed vagy ilyesmi. Nyugodtan lehet vele kísérletezni, el nem tudod rontani. Célszerű a csomagokat egyenként feltenni, és után tesztelni, hogy tudjad melyik működik a te GPU-dhoz.
mpv alatt a hwdec kapcsolót tedd be az mpv.conf-ba, és lejátszás közben a terminálban tudod nézni a kimenetet (vagy i vagy I-t nyomva lejátszás közben), hogy használ-e VAAPI-t.
Egyébként meg ez a hardveres inteles VAAPI dekódolás túl van lihegve. Én most kapcsoltam be Arch Testing + Sway WM Wayland alatt Firefox betában, és menni megy, de alig alacsonyabb a CPU terhelés lejátszás közben, a htop 50-100% (a 4 mag = 400%-ból)-os terhelés helyett kb. 20-25%-kal mutat csak alacsonyabbat, ezt így egy kicsit soványnak érzem. Én i5-2520M-et használok (Sandy Bridge mobil), amiben Intel HD3000 GPU van, ez már ősréginek számít.
-
Frawly
veterán
válasz
#63718632
#6827
üzenetére
Akkor csak leszeded ezt a két csomagot: sudo pacman -R xf86-video-ati xf86-video-amdgpu. Az is jó, ha csak simán átszereled az SSD-t.
Haswell-hez nem jó az intel-media-driver. Ahhoz libva-intel-driver csomag kell. Esetleg még az Arch Wiki a VP8-9 dekódoláshoz Haswll-nél ajánlja az intel-hybrid-codec-driver AUR csomagot is.
-
#63718632
törölt tag
-
Frawly
veterán
válasz
#63718632
#6825
üzenetére
Semmilyen galiba nem lesz. Átklónozod a telepítést és bootolni fog. Az Intel-AMD váltás nem probléma, mert mind a procihoz, mind a GPU-hoz a kernel szolgáltatja a nyílt drivereket, és a linux-firmware csomag a fw részét, meg a mesa csomag is közös, de ezek mind alapból ott kellene, hogy legyenek.
Arra figyelhetsz, hogy ha fent lenne a xf86-video-ati vagy xf86-video-amdgpu csomag, akkor azt szedd le pacmannak, mielőtt klónozol. De még ez sem létszükséglet, mert ha fent is hagyod valamelyiket, a Xorg-nak detektálnia kéne, hogy már nem használhatók. Esetleg még az amdgpu pro zárt driver ne legyen fent, ha telepítettél volna olyat.
Az ilyen váltás csak akkor cinkes, ha valaki zárt NV driverrel használ NV GPU-t, és arról vált valami másra, Intel, vagy AMD GPU-ra. Bár akkor sem egy olyan nagy tragédia, mert akkor is bootolni fog az átklónozott telepítés, annyi, hogy a grafikus felület nem fog menni, hanem konzolban kell az NV-s cumókat leszedegetni, és utána újraindítás után jó lesz Arch esetén.
Amire még figyelj: ha Intel GPU-t használva kell a hardveres videódekódolás, akkor ahhoz telepíteni kell vagy az intel-media-driver vagy libva-intel-driver csomagot, attól függően, hogy konkrétan milyen Intel GPU-ról van szó. Akár mindkettő felmehet. Ha nem telepítesz ilyet, az nem okozza a rendszer működésképtelenségét, csak videólejátszás közben a procit fogják pörgetni a médialejátszó programok, ha videót nézel.
-
Shyciii
veterán
AZért mp3-at tömörítettem, mert az volt kapásból kéznél abban a mappában ahol épp voltam. Ez csak tesztre kellett, hogy vifm alatt is működik-e.
Script hiba biztos nem lehet, mert mint mondottam terminálból gyönyörűen működik. Csak a vifm írja ki ezt a hibaüzenetet, de akkor majd írok egy ezzel foglalkozó fórumba, mert ilyen hibát csak vi-sek írnak ahogy kerestem. -
Frawly
veterán
válasz
Shyciii
#6822
üzenetére
Fura. Ez szerintem valami script-lefutási hiba, nem a /tmp méretével függ össze.
Már eleve azt nem értem, hogy minek mp3-akat összetömöríteni, mikor azok már elve tovább nem tömöríthetők. Mivel eleve átmennek egy pszichoakusztikus adatcsökkentésen, majd egy Huffman-tömörítésen, tovább már semmi nem tud rajtuk tömöríteni.
-
Shyciii
veterán
Semmilyen nagy file-ról nincsen szó. Terminál alatt simán le is fut, csak gondoltam bekötöm vifm alá. Egy 8,5MB-os tömörített file-ról van szó, ami kitmöröítve se sokkal nagyobb, mert régi mp3-ak (tesztre jók voltak). Ezt használja a script kitömörítésre: tar xzf $1
Egyébként jó kis script ismerteket kitömöríti (terminalban használom):
bashrc-be kell berakni:
ex ()
{
if [ -f $1 ] ; then
case $1 in
*.tar.bz2) tar xjf $1 ;;
*.tar.gz) tar xzf $1 ;;
*.bz2) bunzip2 $1 ;;
*.rar) unrar x $1 ;;
*.gz) gunzip $1 ;;
*.tar) tar xf $1 ;;
*.tbz2) tar xjf $1 ;;
*.tgz) tar xzf $1 ;;
*.zip) unzip $1 ;;
*.Z) uncompress $1;;
*.7z) 7z x $1 ;;
*) echo "'$1' cannot be extracted via ex()" ;;
esac
else
echo "'$1' is not a valid file"
fi
} -
Shyciii
veterán
Frawly
Találkoztál már olyannal, hogy a vifm-ben ha egy parancsot akartál futtatni, akkor kiírta, hogy Tmp file too large. Egyszerűen egy tömörítést hajtanék végre tar-al, ami konzolban megy, vifm alatt meg kiírja ezt a hibát. /tmp mappában .8GB szabad hely van, szal az nem lehet gond. -
Shyciii
veterán
válasz
Archttila
#6818
üzenetére
Én openbox alatt a következőket használtam:
Terminál - Termite
Telefon felcsatolása - gvfs-mtp
Hangkeltő - Pulseaudio
Egyébként az Openbox konfigurálása rém egyszerű (pláne aki ismeri az XML nyelvet). Igazából gyorsan meg vagy vele, ha pontosan tudod, hogy mit szeretnél. Inkább a polybar testreszabása lesz hosszadalmasabb, mert ott több próbát fogsz tenni, me rájössz, hogy inkább mgis más sorrendbe akarod kirakni, vagy inkább ezt középre, vagy inkbb mégse kell, mást jelenítenél meg
Openbox alatt a témázás, automatikus elindulások, billentyű konfigok, ablakok viselkedése stb gyorsan megvan. -
Archttila
veterán
Githubhon rengeteg hasznos guide és script halmazt találtam, így azt hiszem egyelőre nincs többre szükségem, ezen felul elmentettem pár hasznos YT csatornát is, de köszönöm a sok hasznos okosságot és felajánlást!
Közben történt a desktop körül pár változás, (konkréten most nincs de soon status-ba van)
így a TV alatt lapulo PI-re kell hagyatkoznom, illetve arra sem 
mert eladtam, 
de jövő hét szerdán érkezik egy 4 gigás modell szóval (ha lassan is) de indul az az Openbox project. (egész nap ezen kattogok a munkahelyen ) Szóval (egyelőre) nem Arch alapokon startolok lévén nekem már van itthon egy felkonfigolt Raspbian Lite server. Semmi extra csak ami feltétlen szükséges: iptables, ssh, samba, transmission, dlna, sftp... ezeket csak azért írom, hogy mert bár messze állok az általatok bírtokolt tudástol 
de ilyesmit álmomból felkeltve is összedobok terminalba service-ket lelövök, source-bol forgatok, illetve olyan 8-10 éve kernelt is forgattam egy régi Inteles Prescott vasra (azt hiszem default nem volt HT) elvagyok mc-be maximum egy Double Commander-t tennék fel, nem kell Login manager tökéletes az xinit startx megoldás és sorolhatnám... szóval ˜hálisten nem teljesen az alapoktol kell kezdenem. Lényegében amiben majd segítségre szorulok azok inkább a korábban DE-vel jövő bloat programok, a WM rendszer jellegéhez igazított alternatívái, mert ugye ezekkel eddig nem kellett foglalkoznom mivel (többnyire) hozta magával puttonyba a dagadt Meta package.
szóval gondolok itt ilyenekre, hogy XFCE4 terminal helyett ti melyiket javasolnátok, vagy pl hogyan (inkább melyik) progival automatizáljam a telefonom felcsatolását (mert gondolom erre sem lesz fent alapbol semmi), Pulseaudio vagy Alsa....? szóval ezeknek a kisérletezésvel nem töltenék el heteket ha nem muszaj, mert azért csak könnyebb megnézni 1-3 alternatívát és dönteni, nemde? szerk.: az Openbox alatt szokásos editorok, témázók, compiz és ezek automatikus indítása eléméletben
már megy, meg guide-ok alapján annyira nem tűnik nehéznek, inkább időigényes pepecselős szerkesztgetés (amit élvezni fogok) -
-
Frawly
veterán
válasz
Shyciii
#6815
üzenetére
Redditen unixporn topik, meg YouTube videók, alattuk mindig meg van adva a git tároló a konfigfájlokkal, onnan sokat lehet meríteni. Nem csak Openboxhoz, hanem bármihez, sőt, új CLI-s terminálos programok felfedezéséhez is jó, amiket még nem ismert az ember. Na, meg a nagyobb YouTube-erektől is sokat lehet tanulni, videón mutogatják, hogy mi hogy működik, mit hogyan lehet konfigolni, mire kell figyelni, mire milyen alternatívák vannak. Ilyen csatornák, mint Luke Smith, DistroTube/Derek Taylor, Brodie Robertson, ne meg teljesen kezdőknek rettenet hasznos lehet Chris Titus Tech, gotbletu, és van még ilyen pár, ott volt valami amerikai orvostanhallgató csóka a vim/markdown témájával, az is nagyon hardcore-ban tolja, annak már nem is emlékszem a nevére. Egyedül ilyen politikus megmondólúzereket nem érdemes nézni, mint Bryan Lunduke, meg ilyen n+1. teszteljük a Gnome vagy XY disztró legújabb kiadását, mert most fedezték fel maguknak a Linuxot emberek, mint Switched to Linux, Linux bloke, stb., ezeket szerintem szimplán időpocsékolás nézni, annyira amatőrök.
-
-
Frawly
veterán
válasz
Archttila
#6810
üzenetére
A WM attól függ, hogy hogy használod a gépet. Mennyire használsz csak GUI-s programokat, vagy mennyire csak terminálosokat, milyen programokat és azokból hányat futtatsz egymás mellett, pl. vannak-e ilyen nagyobb szerkesztőprogramok, amik sokféle eszköztárral, dokkal, ablakkal, alablakkal dolgoznak (pl. GIMP). Mennyire akarsz 3D effekteket és egyéb csicsát, mekkora képernyőt, felbontást használsz, hány darab monitorhoz milyen multimonitor kezelést igényelsz.
WM-nél a „jobb” nem nagyon értelmezhető, legfeljebb adott felhasználásra lehetnek minimalistább, egyszerűbb, kevesebb erőforrást lekötő WM-ek, de ezek sem mindenkinek jobbak, és általában ezek terminálos/TUI felhasználást feltételeznek, meg azt, hogy mindent billentyűzetről vezérelsz, és nem akarsz egerezni.
Az Openbox elég népszerű, mert kellően minimalista, mégse olyan fapados, hogy egerezős, GUI-s usernek használhatatlan legyen. Egy elég reális köztes alternatíva bárkinek, bloat rendszert és minimalista terminálos workflow-t használó usernek is elmehet.
Persze annyiból már az Openbox is fapados, hogy se háttérképkezelés, se dokk/panelkezelés nincs benne, se mindenféle vágólap/rendszerértesítő, billkiosztás-váltó service, nem tartalmaz GPU kompozitálást, ezekről mind magadnak kell gondoskodni 3rd party csomag telepítésével és konfigurálásával, saját DE-t kell építeni belőle, mert default csak egy szürke háttérrel meg egy magától nem frissülő jobb egérklikkes „Start”-szerű menüvel jön és kifújt. Így pl. neked érdemes lehet Openboxhoz picom kompozitort, Tint2-panelt, xfce4-clipman-t feltenni hozzá, a menüje frissítéséhez mmaker-t, esetleg valami másik alkalmazásindító menüt kínáló alkalmazást, rendszerértesítőt (pl. Dunst), háttérképkezelésre feh vagy nitrogen, témázáshoz Obconf, asztali ikonok kezelésre PCmanFM, és még lehetne hosszan sorolni.
Meg annyiból limitált az Openbox, hogy pl. csak monokróm képi elemekkel (xpm-képformátum) témázható. Meg egyesek a virtuális desktop, multimonitor kezelését, tiling képességeit fapadosnak tartják.
Mondom, mindenkinek a saját igényei, felhasználása, gépe szabad felhasználható erőforrásai szabják meg, hogy mi a jobb WM neki, és azokhoz mit tegyen fel. Ez idővel is változhat, mert még Linux alatt is változhatnak idővel az ember felhasználási szokásai.
-
Archttila
veterán
válasz
Shyciii
#6811
üzenetére
Koszonom!
Tiling nem kell, szoval akkor marad az Open es a polybar mert arra gondoltam, hogy ha mar ugy is valtok Debian/Xfce vonalrol akkor legyen ez egy nagy ugras, igy elengedem a DE-et es Arch/openbox/polybar vonalon elek tovabb.
(mindig is akartam egy minimal rendszert)Elkezdtem visszaolvasni 1000 hszt es azt kell mondjam rengeteg hasznos okossagot leirtatok mar
persze nyilvan lesz meg par kerdesem, de majd ugy is meglatjatok... -
Frawly
veterán
válasz
Archttila
#6809
üzenetére
Igazából már bármelyik linuxos particionálóprogram 1024K-n alignál, már a windwososak is. A rossz eltolás csak akkor szokott fenyegetni, ha a kedves user XP-vel meg hasonló retró régiséggel particionál, vagy valami elavult, régi verziós particonálóprogrammal, esetleg klónozásnál szúrja el az eltolást, ha HDD-s rendszerről klónoz SSD-re.
A swap kötelező használata bullshit. 0,5-4 GB RAM-nál még talán elment a biztonság kedvéért pár giga swap, biztos, ami biztos, hátha egyszer mégis kell alapon, de 16 és 16+ GB RAM mellett, átlag felhasználásnál a rendszer nem fog hozzányúlni, hiába van, már 8 GB RAM-nál sem nagyon szokott beleírogatni, csak jelképesen pár KB-okat. Egy kivétel, ha valami nagyon speciális alkalmazást használsz, ami rendellenesen sok memóriát eszik, pl. nagy fejlesztőkörnyezetekben több gigás projekteket nyitogatsz meg, meg 3D renderelés, SQL szerver, meg képszerkesztőben sok gigapixeles poszterek, térképek szerkesztése, videóvágó progikban hatalmas felbontású és sávszélű nyers videók szerkesztése és effektezése, nagyobb virtuális gépek vagy egyszerre több virtuális gép futtatása, hasonlók, de ez ugye nem átlagos, normál felhasználás többé. De normál felhasználásnál ilyen Arch + Xfce és Arch + Openbox rendszer alá már a 16 GB RAM is overkill.
Az Xfce-vel nincs semmi baj, de az Openbox érdemesebb lenne, azt egyszer konfigolod be, és évekig szolgál. Jelenleg én is Openbox-on vagyok Polybar-ral. Értelmes felhasználással még sose használtam ki a 16 GB RAM-ot, talán 1-2× ment el a memóriahasználat 8-12 gigáig, mikor annyira sok minden meg volt nyitva (meg még KDE futott), meg 2× fogyott el a memória, de az nem értelmes felhasználásnál, hanem bug miatt a Chrome/Chromium kapott memory leaket. De igazából minimális swap mellett, minimalistább rendszernél (minimalista WM, terminálos alkalmazások, Firefox) még 4 GB RAM-mal is el lehet lenni, de azért a 8GB ma már ajánlott átlag usernek, aki bloatabb, full DE-ket használ, meg nagyobb GUI-s programokat, GIMP, LibreOffice, KDEnlive, Atom vagy Visual Code, Chrome/Chromium, stb..
Persze annyiból meg a 16 GB RAM is megéri, hogy nem sokkal drágább, mint a 8, és a Linux kernel akkor is befogja valamire a kihasználatlan részt, ha nincs kihasználva. Befogja eszközök, fájlrendszerek cache-elésére, így használva van valamire, nem csak az van, hogy ott áll üresen a memória kihasználatlanul. Át lehet bele tenni a böngészőcache-t, stb., lehet bele tmpfs ramdrive-ot csinálni benne, stb., így mindig kihasználható a parlagon maradt üres RAM. Olyan nincs, hogy valakit azért vitt el a mentő, mert túl sok RAM-ja volt. Talán utoljára Win9x-en emlékszek olyanra, hogy default beállíton gond volt, ha 1 GB-nál több RAM-ot tettél alá, de erre is volt hack, hogy menjen, meg többet lásson.
Igazából EFI partíciónál is mindegy mekkora, amíg a szükséges EFI fájlok, kernelek ráférnek. Akár még egy FAT12-es floppy is lehet EFI meghajtó, nyilván így senki nem használja. Meg lehetne akár egy 20 megás FAT16 partíció is. Ez a legtöbb oldal által emlegetett 250-500 gigás FAT32 EFI partíció is csak azért van ajánlva, hogy ha utóbb mégis több OS-t teszel fel rá, és gyűlnek rajta az EFI fájlok, akkor ne fussál ki a helyből, meg a Windowsnak is ugyebár kellhet rajta a hely. De Windowsnál sem gond ez, vagy másik dual/multiboot OS-nél, ha azokat másik meghajtóra telepíted, amiknek saját EFI partíciója van.
Legutóbb egy brit csávón röhögtem, saját YouTube-csatornája van, és a 20.04-es Deepin Ubunturól csinált review-t. Miután végzett a rendszer bemutatásával, a videó végén benyögte, hogy a bemutatott rendszer csak tesztrendszer volt, ha magának telepítené fel tartós használatra, lenne swap. A háttérben látszott, hogy megy neki a htop, benne mutatja a 32 GB RAM-ot, amiből talán 2-3 giga volt kihasználva (ebben már cache/buffer is benne volt). Ja, arra tényleg létfeltétel úgy a swap, már így is ~29 gigabájt állt csak benne üresen. De ugyanez volt a DistroTube csatornás fazonnál, aki eleve 32 giga RAM-mal vette a gépet, ami eleve nem volt kihasználva, 20+ giga rendszeresen ott volt neki kihasználatlanul (minimalista WM, terminálos alkamazások futnak csak nála, legfeljebb 1-2 kisebb VirtualBox gép meg OBS, amivel FullHD-ben streamel, és utóbbi sem eszik pár giga RAM-nál többet, meg néhány opensource játék, amik megint nem esznek 4 gigánál több RAM-ot), de felbővítette 64 gigára, mert az kell. Nála enyhítő körülmény, hogy legalább a swapot nem erőlteti, az lenne még csak szép. Holott a felhasználása beleférne simán 16 GB-ba úgy, hogy szintén nem lenne szüksége swapra.
Az ilyen 16 GB RAM Windowson is csak akkor szűk, ha spéci felhasználás van, vagy valaki olyan gamer, hogy a legújabb játékokat is 4K-ben erőlteti, és még mellette streameli is a játékot. Ilyenkor már valóban néhol nem lehet elég 16 GB RAM, de ilyenkor is csak minimálisan kéne neki több, és ez sem azért van, mert az adott cucc nem férne bele a memóriába, de a Windows memóriakezelése, memóriahasználata eleve nem olyan hatékony, mint a Linuxszé. De aki csak sima gamer, FullHD-ban játszik, átlag felhasználás, annak még Win10 alatt is bőven elég a 16 GB RAM, a legeslegújabb játékokhoz is.
-
Archttila
veterán
Huh, ez aztán a részletes válasz!
Az SSD partícióeltolása miatt nem kell aggódni, a cfdisk modern tool, eleve 1024K-val tolja el a partíciókat, ami mindenfajta SSD-hez és modern HDD-hez megfelelő.
Erre voltam kíváncsi, köszönöm!
A többi már megy*, hiszen Vboxban van egy félig belakott Arch rendszerem, illetve korábban évekig Debian (netinst) volt a gépen Xfce DE-vel.
Swap-al kapcsolatban régen azt olvastam, hogy mindegy mennyi RAM van a vasban, a rendszer normális (hibamentes) működéséhez akkor is ajánlott a Swap használata. (lehet bullshit)Egyébként szívem szerint egy Openbox/Tint párost konfigolnék a végtelenségig
de sajnos család/munka mellett erre (már) nem nagyon van idő így marad az Xfce.*ez a Grub nélküli EFI boot új volt, köszönöm!
-
Frawly
veterán
válasz
Nagytoll
#6807
üzenetére
Ez általában is igaz, ha valami USB csatlakozást használó eszköz (mint ez a USB BT adaptert használó egér) problémás, akkor az első, hogy átdugdosod másik USB portba, lehetőleg a gép hátuljába is, mert a gép előlapján vagy tetején lévő USB kivezetések nem minden háznál valami megbízhatóak.
Bár azt nem értem, hogy ha interferencia volt a gond, akkor az Windowson miért nem jött elő? Erről az interferenciáról hülye szóviccként mindig az jut eszembe, ahogy Vágási Feri szállt be Win95-tel az internetbe
-
Nagytoll
senior tag
válasz
Nagytoll
#6802
üzenetére
Megvan a probléma.
Interferencia...
Pedig ez volt az első amit kizártam. Nem hittem hogy tényleg be tudnak egymásnak zavarni a dolgok. Eddig sose volt interferencia gondom.Bluetoothon keresztül elsőre jónak tűnt ameddig be nem dugtam a dongle mellé egy pendrive-ot és elkezdtem rá írni dolgokat. Egyből megfagyott az egérmutató
Most úgy néz ki jobb a helyzet hogy a Logitech unifying vevő a gép hátuljába az alapba van dugva olyan portba ami körül nincs más. Közben 2 másik eszközhöz is kapcsolódva volt a gép Bluetoothon.
Az lesz a végső megoldás amit valahol olvastam, hogy egy USB hosszabbító kábellel távolabb lesz a Logitech dongle, így elvileg nem lesz annyi interferencia.
-
Frawly
veterán
válasz
Archttila
#6803
üzenetére
A cfdisk után nem feltétlen kell a -z kapcsoló. Az csak arra való, hogy ha lenne már a meghajtón valamilyen partíciós tábla, akkor nem abba particionál, hanem teljesen új, üres partíciós táblát kezd, ír fel, olyat, amilyet kérsz, gpt vagy dos/mbr. Nyilván ha EFI boot van, akkor gpt kell.
Az SSD partícióeltolása miatt nem kell aggódni, a cfdisk modern tool, eleve 1024K-val tolja el a partíciókat, ami mindenfajta SSD-hez és modern HDD-hez megfelelő.
Hacsak nem akarsz hibernálni, 16 GB RAM mellett szerintem semmilyen swap nem kell, nem hogy swap partíció. Ha esetleg később mégis szükséges lenne swapra, azt lehet fájlként is létrehozni, pl. 8 gigás swap fájlt így tudsz akármikor, telepítés után is létrehozni:
dd if=/dev/zero of=/elérési/út/swapfile bs=1M count=8192
mkswap /elérési/út/swapfile
swapon /elérési/út/swapfile
Illetve be kell tenni a /etc/fstab-ba is ezt a sort:
/eléséri/út/swapfile none swap defaults 0 0Az Arch-nak nem kell nagy EFI partíció, jelenleg nekem 100 megás van, és abból is 51 MB szabad. Ha egyedüli rendszered az Arch azon a lemezen, akkor neked se kell nagyobb. Csak egyes disztróknál kell nagyobb, mint az Ubuntu, Debian alapúak, meg Void, amelyek otthagyják a régi kerneleket szaporodni. De adhatsz végül is 500 megát is neki, 400 mega ide vagy oda ma már nem tétel. De csak Archhoz overkill az 500 MB. Az EFI partíció típusának EFI system-et kell megadni, és az Arch Wiki alapján mkfs.vfat-tal FAT32-re kell formázni.
EFI bootoláshoz nem kell GRUB sem, az Arch Wiki systemd-boot cikke alapján csináld.
Root partíciónak annyit adj, amennyire szükséged szokott lenni, nálam 50 giga van, de az overkill, nagyját nem használom, 11 GB-ból megáll a teljesen belakott Arch telepítésem, de aki nagyon fullos, GUI-s, DE-s kiszerelésben használja, annál sem hinném, hogy 20-30 gigánál többre szükség lenne, én is csak biztos, ami biztos alapon szabtam ilyen nagyra. Persze ez mindenkinél felhasználásfüggő, mennyi programot, csomagot telepít, hol van a Steam mappája, stb..
A maradékot (~461 GB) meg adhatod /home-nak, ahol nem csak az user home mappája lehet, hanem használhatod általános adatpartíciónak is, bármilyen adat tárolósára, torrent, dokumentumok, portable programok, stb..
Partíciókat, ha csak speciális igény nincs, simán, ext4-re kell formázni.
-
Siriusb
veterán
-
Archttila
veterán
Már majdnem elindítottam élesbe (is) a telepítést amikor rátaláltam erre a hasznos hozzászólásodra, szóval:
Egy 512GB-os 3D TLC-nél a cfdisk -z formában javasolt? (EFI mód) Ha igen akkor mennyit érdemes adni az EFI-nek és mennyit a Swap-nak? (16GB DDR4)
Én így terveztem:
EFI/500MB
Swap/16GB
System/... -
Nagytoll
senior tag
A nagy részével tisztában voltam köszi
Elsőre meg akartam bizonyosodni hogy nem hardveres probléma. Akkor ugye előjönne minden platformon.
A GPU driveres dolog érdekesen hangzik. Ez eszembe sem jutott.
A legújabb amdgpu/mesa driver van fent. A napokban frissítettem 19.xx valami driverről, de ott is akadt.
Mindjárt megnézem hogy Bluetoothon keresztül mit produkál az egér. Eddig a gyári unifying vevővel használtam.
-
Frawly
veterán
válasz
Nagytoll
#6800
üzenetére
WinPE és MacOS nem releváns, azok külön a saját drivereikkel hajtják az egeret. Azzal Linuxnál nem mész semmire, hogy Windows alatt megy. Az alatt persze, hogy megy, mert a driverek 99%-a arra készül, és a gépek 98%-án az fut. Még jó hogy azon nem akad.
Ubuntuval nem azért kéne megnézni, mert az is Live, mint a WinPE, hanem az Ubuntu-kernelben esélyesen többféle szutykot beleforgatnak, meg többféle firmware-t mellékelnek a Live-ban is. Archon lehet minimalizmus miatt a kernelcsomag fenntartója nem fordított bele valami olyan kernelmodult, ami kéne a Logitech egerednek, vagy beleforgatott, de valami firmware-t vagy hasonlót is fel kéne tenni. Ezért kéne előbb Ubuntuval tesztelni, de lehet akár Mint is, az is jó rá. Ami tetszik, csak kezdőknek való, mainstream Ubuntu-alapú disztró legyen, ami támogat Live módot, hogy ne kelljen egy egyszerű hardver kipróbálásához feltelepíteni az egészet, ami külön munka lenne. Nem biztos, hogy segít, de egy Live bebootolást egy pendrive-ról megér, hátha okosabbak leszünk. Mert ha mégis megy azzal, akkor tudjuk, hogy az Archon hiányzik hozzá valami. Az Arch ugyanis alapból egy KISS (Keep it simple stupid) disztró, sok mindent neked kell benne feltenni, külön, magától nem települ, meg nem detektálódik.
Még az sem biztos, hogy egérprobléma, GPU driver is tud pl. akadásokat okozni, mikor az egeret mozgatod.
de legalább már Arch alapon vagyok! 
Tehát így:
De a Win vígan indul. Még sem jó ötlet ezen a gépen a Win UEFI partícióját használni. Át fogom gondolni, hogy annyira fontos-e a Win.
Előtte 2 hónapig nem frissítettem, és annyi idő alatt jött össze ugyanennyi frissítés, most meg 1 hét alatt, ez nem semmi. Az én update-em még nem futott le, de én nem számítok problémára, a pálcika WM meg a terminálos cuccok nem nagyon tudnak eltörni, annyi egyszerűek, hogy nincs rajtuk semmi bonyolítás.
mert eladtam, 
de jövő hét szerdán érkezik egy 4 gigás modell szóval (ha lassan is) de indul az az Openbox project. 
de ilyesmit álmomból felkeltve is összedobok terminalba 
Új hozzászólás Aktív témák
- GYÖNYÖRŰ iPhone 14 Pro Max 256GB Space Black -1 ÉV GARANCIA - Kártyafüggetlen, MS3172
- ÁRGARANCIA!Épített KomPhone Ryzen 7 7800X3D 32/64GB RAM RTX 5090 32GB GAMER PC termékbeszámítással
- Bomba ár! HP ProBook 440 G6 - i5-8GEN I 8GB I 256SSD I HDMI I 14" FHD I Cam I W10 I Gari!
- Kaspersky, BitDefender, Avast és egyéb vírusírtó licencek a legolcsóbban, egyenesen a gyártóktól!
- Bomba ár! Lenovo ThinkPad T460 - i5-6GEN I 8GB I 256GB SSD I 14" FHD I Cam I W10 I Garancia!
Állásajánlatok
Cég: FOTC
Város: Budapest