- D1Rect: Nagy "hülyétkapokazapróktól" topik
- Luck Dragon: Asszociációs játék. :)
- sziku69: Fűzzük össze a szavakat :)
- eBay-es kütyük kis pénzért
- Fogkefe: elektromos vagy manuális?
- sziku69: Szólánc.
- 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
-
Laszlo733
aktív tag
Sziasztok!
Kijött a pacman 5.2, de alapból nem települt, mert a yay -t még nem készítették fel rá, így a frissítéskezelőben hibára futott. Azt javasolták, hogy kerüljön törlésre a yay, majd pacman 5.2 települ és utána mehet fel a már felkészített git-yay / git clone https://aur.archlinux.org/yay-git.git yay / Ez meg is történt, de hazavágta az Octopit és sehogy sem tudom visszarakni.
Parancssoros telepítésnél bármit akarok telepíteni, többször is ezt a hibaüzenetet kapom:
Belépés a fakeroot környezetbe...
==> FIGYELMEZTETÉS: PACKAGER-nek ilyen formátumnak kell lennie: 'Példa Név <email@addres
s.invalid>'
Van ötlet, hogy ez hogyan orvosolható? -
Laszlo733
aktív tag
Igen, terminálból is betöltődik lefagy, majd összeomlik. A kimenet hibás fájlleíróra panaszkodik.
Az utolsó pár sor:"SELECT COUNT(id) FROM Images WHERE album=:a;"
Error messages: "Unable to fetch row" "database table is locked: Images" "6" 1
Bound values: (QVariant(int, 2))
ASSERT: "!isEmpty()" in file /usr/include/qt/QtCore/qlist.h, line 363
digikam.dimg: "/home/linux/Pictures/Házi videó/2013.05.16_saját/2014_Januá
r/20140102_201319.jpg" : JPEG file identified
KCrash: crashing... crashRecursionCounter = 2
KCrash: Application Name = digikam path = /usr/bin pid = 6087
KCrash: Arguments: /usr/bin/digikam
KCrash: Attempting to start /usr/lib/drkonqi from kdeinit
sock_file=/run/user/1000/kdeinit5__0
pa_write() failed while trying to wake up the mainloop: Hibás fájlleíró
pa_write() failed while trying to wake up the mainloop: Hibás fájlleíró
pa_write() failed while trying to wake up the mainloop: Hibás fájlleíró
Invalid write to eventfd: Hibás fájlleíró
Code should not be reached at ../pulseaudio/src/pulsecore/fdsem.c:199, function pa_fdsem
_post(). Aborting.
Unable to start Dr. Konqi
Re-raising signal for core dump handling.
Félbeszakítva (core készült) -
Laszlo733
aktív tag
Telepítettem az autoconf -ot, de utána így is hibára fut a yay -S gksu
Hunk #20 succeeded at 2876 (offset 5 lines).
Hunk #21 succeeded at 2888 (offset 5 lines).
patching file Makefile.am
patching file libgksu/Makefile.am
Hunk #1 succeeded at 27 with fuzz 2.
patching file libgksuui/Makefile.am
Hunk #1 succeeded at 10 with fuzz 2 (offset 1 line).
patching file libgksu/Makefile.am
Can't exec "aclocal": Nincs ilyen fájl vagy könyvtár at /usr/share/autoconf/Autom4te/Fil
eUtils.pm line 326.
autoreconf: failed to run aclocal: No such file or directory
==> HIBA: Hiba történt a prepare()-ben.
Megszakítás...
Error making: libgksu -
Frawly
veterán
válasz
ubyegon2
#6078
üzenetére
Igen, ezeket szoktam is írni. Csak az NCQ TRIM van feketelistán, nem az egész TRIM. Tehát a fstrim, fstrim.service, discard mount paraméter működik továbbra is, de a kernel azonnal kikényszeríti a végrehajtásukat, nem ütemeződnek (queue) későbbre. Ez pedig némi belassulással járhat. 860-asnál már ez nincs, ott az NCQ TRIM sincs tiltva.
-
Laszlo733
aktív tag
Sziasztok!
A yay -t szeretném telepíteni, de a az első, vagy a második makepkg -si nél hibára fut a telepítés. Mi lehet a baj?
sudo pacman -S git
mkdir src
cd src
git clone https://aur.archlinux.org/yay.git
ls
cd yay
makepkg -si
sudo pacman -S fakeroot
makepkg -si
/home/linux/src/yay/PKGBUILD: sor: 23: make: parancs nem található
==> HIBA: Hiba történt a build()-ben.
Megszakítás...
Mi lehet a probléma, illetve van -e más módja a yay telepítésének? -
Sajnos nemcsak ntfs-ről ext4-re másolásnál nyaldossa a 100%-ot a proci, hanem egy izmosabb gigabites torrent letöltésnél is, két 26 gb-os filmet töltöttem le, jöttek lefele úgy 60-80megabájt/s-el és legalább egy procimag a 4ből szinte mindig 100%-on volt a Ksysguard szerint. Kde-t használok. A proci X4 860K, 8GB ram, a rendszer egy Radeon R3 480GB ssd-n van. A kliens qbittorrent. Bár talán nem volt annyira drámai a rendszerlassulás a letöltés ideje alatt Arch alatt, mint Kubuntu alatt.
-
Nem az online TRIM érintett ebben a dologban? (a 800-as sorozat amúgy más rég kikerült a blacklist-ból) Erre a gyűlölt systemd egyébként rég nyújt megoldást, de azelőtt is lehetett ütemezett TRIM-et használni. Sok disztró főleg Arch alapúak még default discard parancsot alkalmaznak FSTAB-ban, nekik érdemes odafigyelni, aki meg pure Archot használ, csak tudja, mit hogyan kell alkalmazni.
Egyszóval az nyilvánvaló még mindig szerintetek is, hogy a Samsung 800-as sorozatnak semmi gondja nincs a TRIM-mel, kivéve 2 tipust, aminek az online TRIM ATA parancs(discard) okoz gondot?
Ez így korrekt? Vagy megint nem jól értelmezek valamit?
-
Frawly
veterán
Igazad van, rosszul emlékeztem. Régen "Samsung SSD 8*" szerepelt benne, de végül a 860-asra feloldották, a 840 rajta maradt, a 850-esre emlékeztem teljesen rosszul.
Akkor az viszont lehet oka, hogy a 850 Pro amiatt lassul be, mert az NCQ TRIM le van tiltva, emiatt a kernel azonnal kikényszeríti a végrehajtását.
-
Frawly
veterán
válasz
vargalex
#6072
üzenetére
A modern kernelekben jó pár hónapja csak a 840-es van már feketelistán, a 850-860-as szériát kivették belőle. Nekem is ubyegon mutatta.
Schyciii: nyilván nem konzumer SATA SSD-t kell virtual hostingra használni, arra valóban nem való. Arra enterprise NVMe SSD kell. De sima workstation, desktop, home felhasználásra teljesen jó a 850-860 Pro, még nagyobb fájlmásolásoknál is.
Minimalista felhasználásra, főleg desktop Linux alá, esetleg C2D és annál gyengébb gépekbe (amik jobb SSD-t nem hajtanának ki) az A400 is teljesen jó, WIn10, Linux 4-6 mp. alatt bootolni tud rajta, programok azonnal betöltődnek, ennyi a lényege, nem kell várni, míg HDD-t rotyogtat a rendszer. Csak nagy fájlmásolásokat ne akarj rajta, mert arra már nem való. Ha erre próbálod használni, akkor nagy csalódás lesz a vége, és rájössz, hogy nem volt értelme az SSD-n spórolnod, pár ezres árdiffiért vehettél volna valami jobbat. Ezért első kérdés a Milyen SSD-t veszek topikban, hogy mekkora anyagi keret van rá, és milyen felhasználásra lesz, milyen gépbe.
A400-nál attól is nagyon függ a belassulás, hogy mennyi írás van rajta, mennyire van betelítve adattal, és eleve mekkora tárhelyes modell. Ami az A400-ról nagyon hiányzik, az a DRAM cache, de annak a hiánya inkább random lemezműveleteknél látszik meg jobban.
-
Shyciii
veterán
Nah nekem Kingston A400-as van
Mondjuk anno azért vettem, mert olcsó volt. Már nem is emlékszem, hogy hány éves.
Sok általános weboldalon én is mindig azt olvastam, hogy a Samsung 840 Pro és 850 Pro jó SSD, de sajnos amit mondtam, azt megerősítette a Rackforest, és a Doclernet is. Ha nem ismered őket, akkor mindketten hostingot végeznek, és hát mi is ezt tapasztaltuk. Otthoni használatra biztos jók ezek a Samsungok, de nagyobb másolás esetén bukováriak. És akkor még ott a trimmelési gondjuk. Mondjuk erről csak akkor olvastam, mikor elkedzem linuxozni. Viszont most olvasom vargalextől, hogy a 850 Pro is érintett ebben. Hihetetlen, hogy ezt képtelenek megoldani.
Amúgy én egy ideje szemezgetek a WD Black SN750-es SSD-vel. Persze M.2-essel. Mondjuk még nem néztem meg, hogy a notebookomba betehető-e, befér-e. -
Frawly
veterán
válasz
Shyciii
#6069
üzenetére
Pedig a 850 Pro egy elég jó SSD, nincs is rajta NAND cache, csak DRAM cache. Nagyon gyors, klasszik/planár MLC NAND van rajta, még nagyobb csíkszélességen gyártva, így nem csak gyors, de elég strapabíró is. NAND cache ezért is nem kell neki, mert olyan jófajta NAND van rajta, ami nem cache módban is elég gyors, konzisztensen tudja tartani az írást/olvasást, végig a meghajtó teljes tárterületén.
Ezzel a cache problémával inkább nagyon olcsó SSD-ken találkozni, ahol planár TLC, vagy gyérebb 3D TLC/QLC NAND van (A400, BX500, 660p), na, azok tényleg mocskosul be tudnak lassulni, ha kifogy alóluk a cache. Ha viszont sokat másolsz nagy tételben, akkor nyilván nem ilyen SSD-t kell venni.
Illetve nálam áll hegyekben a sok giga RAM is kernel cache-nek, meg az MX300-nak is még normális a cache-elése, nem egy sebességbajnok SSD, de azt a sebességet konzisztensen, belassulások nélkül tartja, így talán én azért nem futottam bele abba, amit írtok.
Egyébként az iotop-pal tudod nézni, ha a rendszer I/O miatt van terhelve.
-
Shyciii
veterán
Double Commander-t használok
Kipróbáltam neked terminal alóló, és ugyanaz a jelenség. Viszont itt szembetűnőbb volt még egy dolog. Semmi gond nem volt egészen addig, míg az SSD cache-e be nem telt. Ahogy betelt, onnantól kezdve akadozik a kurzor, miközben a proci most 22% átlagt mutatott. És így viszont már nagyon ismerős jelenség. Semmi bug nincsen, hanem az SSD a "szar".
Ugyanis van egy másik tapasztalatom kb 2 évvel ezelőttről. Vannak olyan szervereink, amik RAID1-es köteget használnak Samsung 850Pro SSD-vel. No ott láttam ezt a jelenségget először. Nagy file másolásakor amíg a cache nem telik gyors, és utána drasztikusan leesik a teljesítmény, de olyan szintre, hogy ha valaki távasztalozott arra a szerverre, akkor ki is esett onnan. Amióta már a az SSD-s szerverekben Intel S35 és S46-al kezdődő típusokat használunk, azóta semmi ilyen gond nincsen. Egyszerűen vannak SSD-k, amik szarok olyan nagy file-ok írásában, amik nagyobbak, mint a cache-e. -
Frawly
veterán
Egyébként én arra gyanakszok még, hogy itt a legtöbben valami ocsmány, intézőszerű fájlkezelőt használtok, Nautilus vagy Dolphin, vagy hasonló szutykot, és az bugzik be. Próbáljátok ki terminálban, mc-vel vagy hasonlóval, hogy hogyan alakul a CPU terhelés, meg ott is akad-e az egér.
-
Frawly
veterán
válasz
Shyciii
#6066
üzenetére
Na, a 27% már reálisabb, de amellett még mindig nem kéne akadnia az egérkurzornak. Nálam ilyen nagy SSD-ről SSD-re másolás közben is teljesen simán gördül az egérkurzor, sehol egy megakadás. Pedig mint írtam, sima vanilla Arch, meg lófütykös számítási teljesítményű régi notebook.
De, hogy ha 2-3 hónapja nem csinálta, akkor az van, amit legelőször írtam, hogy ez valami friss bug, vagy a kernelben, vagy valami userspace toolban, ami most jött elő nemrég.
-
Shyciii
veterán
Én újra kipróbáltam a saját ssd-mről ssdm-re másolni egy 14GB-os filet, de ugyanaz. Conky és htop is átlag 27%-os cpu terhelést mutat minden magra, de közben az egérkurzort mozgatva rettentően akadozik. Viszont így elgondolva ezt 2-3 hónapja biztos nem csinálta, mert kb akkor szerveztem át a winyót, és helyezgettem ide-oda cuccokat, és közben tudtam dolgozni, szal itt valamelyik frissítés után lett nekem ilyen. Mindegy, ritkán van ilyen
-
Frawly
veterán
válasz
vargalex
#6064
üzenetére
Ezt tényleg nem ártana tisztázni. Van ugyanis olyan taskmanager, amit 100% terhelésnek veszi az összes mag együttes terhelését, van, amelyik többszáz %-nak (pl. négy szálas procinál 400%-ot vesznek teljes terhelésnek, 8 szálasnál 800%-ot).
Én htop-pal néztem, a CPU [Bar] oszlop van nálam bekapcsolva, ami 100%-nak veszi az összes magra számított max. terhelést. De amikor a szálaknál listázza a terhelést, meg folyamatoknál, azt viszont egy magra vetítve méri.
Még azért a proci sem lenne mindegy.
-
Frawly
veterán
válasz
vargalex
#6062
üzenetére
Jó, de itt maximumra járatott prociról beszéltünk. Az 1 magra eső terhelés nem releváns, egy 12 szálas procinál azért ne számítson a 100% egy szálra eső terhelés, mikor az csak összességében a proci ~8%-a. Persze nem azt mondom, hogy nem magas nálam is, mert egy normálisan megírt OS-nél, drivernél max. 1-2% körül kellene, hogy legyen. De az ntfs-3g-nél megszoktam, hogy bloat, annál örülni kell, hogy támogatott az NTFS egyáltalán, hacsak lehet, tartós linuxozásnál kerülni kell az NTFS partíciók használatát.
De ext4-nél valóban én is sokallom azt az 5-25%-ot (egy magra 20-100%). Amit még nem írtam: nálam titkosítás sincs (vagyis van, de az hardveres, szoftveres szint felé transzparens). Szóval nem kellene ennyinek lennie, de azért attól messze van, hogy kimaxolja a procit, meg gondot okozzon.
-
Frawly
veterán
válasz
Shyciii
#6060
üzenetére
Morbid, amit írtok, Archon nekem meg nem eszi meg, ext4-ről másolok ugyanarra az ext4 partícióra, egy régi SATA SSD, és a proci sem erős, egy i5-2520M, ami kb. egy asztali közepes C2Q szintjén lehet mindössze, szóval kb. 10 éves szint, másolás közben 5-25% között ingadozik az össz procihasználat (ez már ki van vetítve 4 szálra, a 100% lenne az, amikor az összes szál maximumra lenne terhelve). Az idő java részében közötte van a két szélső értéknek, és 11% körül van. Az is igaz, hogy nálam az SSD sem gyors (MX300), tartós írásnál mindössze 300 MB-ra maxolódik ki, még az sincs meg mindenhol, néha beesik 200 közelébe, pedig SATA3 módban fut, nem ütközik bele SATA2 limitbe.
Kipróbáltam NTFS-ről is ext4-re, igaz az SATA2-re korlátozott SSD-ről ment (mSATA Samsung 860 EVO), de ramdrive-ra másoltam, ami kb. 6000 MB/sec-et tud. Itt sem volt több 33-37%-nál a procihasználat, igaz ezt konzisztensen tartotta, nem nagyon ingadozott. Pedig a legfrissebb rendszerem van Archon, friss ntfs-3g-vel, kernellel, meg mindennel, annyira friss, hogy a Testing tárolóból van a legtöbb minden. Talán ami nálam eltér, hogy terminálos alkalmazásokat használok, meg ultraminimalista waylandes felületet, míg nálatok a grafikus felületnek egy ilyen lemeztartalmat kijelző frissítési bugja dobhatja meg a procihasználatot.
Meg kéne nézzétek, hogy konkrétan melyik folyamat eszi annyira a procit.
-
Shyciii
veterán
Az a baj, hogy nekem notebookom van, így nem tudok belerakni még egy SSD-t, mert nincsen hely. Saját SSD-mről másolva 200GB-nyi egy fileos adatot ugyanarra az SSD-re nekem is megeszi a procit, illetőleg a proci terhelés a conky szerint 35% körül van, de az egérkurzoron látni, hogy baromira belassult a rendszer. Ez viszont a SATA csatoló egyértelmű hibája, mert ebből a szempontból nemigen van előrelépés a PATA-hoz képest. USB-s külső SSD van, de ugye ott is az USB korlátozza le.
-
Frawly
veterán
válasz
Shyciii
#6058
üzenetére
Ebben teljesen igazad van, még ramdrive-nál és NVMe SSD-nél sem lenne szabad 100%-ig tekernie a procit, akkor sem, ha az gyengébb. Épp ezért, én inkább gyanakszok arra, hogy valami újonnan előkerült bug, de tényleg simán lehet, hogy ennyire szuboptimálisra van megírva.
-
Shyciii
veterán
válasz
vargalex
#6048
üzenetére
vargalex, Frawly
Ezesetben viszont akkor sem az SSD-t, vagy a procit tartom hibásnak, hanem a szabványt, ahogyan kezeli a háttértárakat. Igaz már rég volt, de ha visszaemlékeztek, akkor a csatoló szabványa szabja meg, hogy a procit mennyire terheli (lásd régen PATA, SCSI). Ugyebár SCSI mérföldekkel gyorsabb volt anno bárminél, és másoláskor a proci 5% körül terhelődött, és lazán csinálhattál bármit mellette, míg PATA-s winyóknál lazán 10x, 15x-ös volt a terhelés a SCSI winyókhoz képest.
-
-
BoB
Topikgazda
-
Frawly
veterán
válasz
vargalex
#6049
üzenetére
Én nem néztem rá. Igaz csak most lett nemrég AMD-s gépem, és még arra is lusta voltam feltenni Linuxot, mert mikor időm van elé ülni, Win10 alatt nyomatok rajta AAA-s játékcímeket. Pedig még a partíciós hely is meg van a Linuxnak hagyva
De emlékszem, hogy régen ki volt hangsúlyozva, hogy csak Intel procikhoz kell külön microcode csomag (intel-ucode), AMD procikhoz a linux-firmware csomag tartalmazta. Ezek szerint már 1 éve külön van, de én lemaradtam róla, mert egy darab hír sem volt róla. Aki nem veszi észre, annak elég kínos.
-
Frawly
veterán
válasz
ubyegon2
#6043
üzenetére
Ez lehet, hogy az SSD teszi annyira gyorssá az I/O műveleteket, hogy a proci lesz a szűk keresztmetszet.
De még simán lehet az is, amit én írtam, hogy bugos a legutóbbi verzió. Az ntfs-3g-ből nem jön ki túl sűrűn verzió, ezért simán lehet, hogy már egy régebbi LTS kiadáson is az utolsó verzió van. Vagy az is lehet, hogy a legújabb kernelekben van egy bug, ami előhozza ezt a procitúlpörgetés ntfs-3g-vel.
(#6044) Shyciii: ezt mondom én is, hogy a 100% az túl durva. Bár az is igaz, amit uby ír, hogy a procitól is függ. De nálad HDD-re megy, és nem SSD-re, ami jobban be tudná pörgetni.
-
vargalex
félisten
Az emlékezetemben nekem már úgy élt, hogy az AMD procikhoz külön csomag van. Most jutott eszembe ez a hozzászólásod, így megnéztem gyorsan a microcode wiki history-t. Jól emlékeztem, az a jó pár hónapja egészen pontosan 2018 augusztus 26-án volt.
Nyilván azóta ránéztem már az oldalra, ezért emlékeztem... -
Sonja
nagyúr
válasz
Shyciii
#6044
üzenetére
Én ilyenre inkább exFAT-re formázott USB-s külső HDD-t használok. Hamarosan véglegesen bekerül a kernelbe a Microsoft-os exFAT implementáció, így natív lesz a sebessége. Eddig minden cucc (régi 2012-es TV, Dune HD médialejátszó, stb.) szépen kezeli, probléma nélkül. Szvsz érdemesebb átváltanod rá.
-
-
-
válasz
vargalex
#6042
üzenetére
Igazad van, marhaságot írtam, az SSD teszi éppen bottleneck-ké a CPU-t! Egyszóval a lassú HDD esetén nem lenne akkora a terhelés.
(#6041) Frawly
Ne röhögtess így kora reggel! Csak nem fog egyszerre ugyanazon bug egy nyamvadt elavult LTS-en meg a super ropogós rollingon is jelentkezni!
És ahogy a mester is említette, nem volt arról szó, hogy az ntfs-3g terhelné a CPU-t, csak annyi, hogy közel 100-on pörgött, de másolás közben az emberek leállítanak közben minden egyéb folyamatot? Lószart.
Egyszóval amit a kolléga tapasztalt, az maga a normál működés abban a helyzetben. Ki kell lőni a -csába a Wines fs-et és minden OK lesz.
Egyébként meg meg kéne nézni a futó processzeket cli-ben és látható lenne minden, nem kéne itt a Látóasszony topik munkáját átvenni. (gondolom, ha én 1bites Ubuntu származék használóként használom a cli-s rendszer monitorozást, akkor Archereknek ez főleg menni fog)
-
vargalex
félisten
Ugyan nem írta a kolléga, hogy milyen CPU-ról van szó, de nyilván 1 mag futott 100%-on, kérdés az milyen sebességre képes.
Mégpedig valószínűleg pont azért, mert SSD-ről meglehetősen gyorsan lehet olvasni, így valóban az ntfs-3g terhelte. Persze az elért olvasási sebessegről sem tudunk semmit... -
Frawly
veterán
válasz
ubyegon2
#6038
üzenetére
Az ntfs-3g valóban terheli a procit, de azért 100%-ra nem kéne pörgetnie. Már a második user a héten, aki erre panaszkodik, ráadásul nem csak Arch alatt, szerintem ez egy bug lesz a legfrissebb verzióban. Lehet kipróbálom most már én is, és jelentek nálam hány %-ot eszik az ntfs-3g.
-
válasz
attilav2
#6037
üzenetére
Viszont egy negatív jelenséget felfedeztem ami sajnos érinti az Arch-ot és a (K)ubuntu-t is
Ezt nem volt érdemes felfedezni, NTFS-re dolgozni mindig is nagy processzor terhelést jelent Linuxos fs-ről. Az lenne egy igen szép baleset, ha valaki azt fedezné fel, hogy akármelyik disztrón nem így van!
(ezért is ellenjavallt NTFS-re torrentezni például)A világ leggyorsabb SSD-it is használhatod, teljesen mellékes, írhattad volna azt is, hogy az összes géped piros otthon.
Keresgéltem a google-ban de megoldást nem igazán találtam erre.
Fentiek alapján nem meglepő.
de végülis nem tetszett a rendszer filozófiája
Jaj ne, ennyire fennköltek ne legyünk már, filozófus vagy te vagy mi? Ez ilyen nagyArchú dolog lehet, mert mindig filozófiáról beszéltek. Nem teszik a frissítési/csomagkezelési rendszere és kész.
-
Kipróbáltam a Kubuntut a hardveresen gyorsított chromium-beta chromium-dev miatt, de végülis nem tetszett a rendszer filozófiája, vissza tértem az Arch-ra, amit megint uefi telepítéssel raktam fel. Ezúttal viszont grub-ot raktam fel systemd-boot helyett és a másik lemezen levő szintén uefi módú windowst az os-prober segítségével adtam hozzá a grub menüjéhez ezen leírás szerint, működik. Nem kellett átmásolni a Microsoft mappát a windows efi partíciójáról /boot/EFI alá mint systemd-boot-nál, így nem jelenik meg kétszer a windows boot manager az alaplap menüjében. A grub és az os-prober ezt kultúráltabban megoldja.
Viszont egy negatív jelenséget felfedeztem ami sajnos érinti az Arch-ot és a (K)ubuntu-t is, hogy mikor átmásoltam a zenéimet (több tíz giga) az ntfs-es adattáróló lemezről a linuxos lemezre akkor közel 100% körül volt a prociterhelés(Pedig mindkét lemez ssd). Keresgéltem a google-ban de megoldást nem igazán találtam erre. -
Frawly
veterán
Egyébként nagy francok az archosok. Sokszor még hír sincs kint egy változásról. Pl. jó pár hónapja kikerült a linux-firmware csomagból az AMD procikhoz a microcode csomag, és most már külön csomagban van, amd-ucode néven. De erről se hír, se értesítés, gondolom mert úgy gondolták, hogy a rendszert nem töri el működésképtelenre, nincs szükség kézi beavatkozásra (de, szükség van rá). Én is csak azért vettem észre, mert múltkor itt egy kolléga felhozta UEFI systemd-boot kapcsán. Az Arch Wikiben már benne van, de aki nem tud a változásról, az nem fogja keresgetni benne.
Gondolom úgy voltak vele, hogy majd az emberek észreveszik frissítéskor, vagy egy olyan csomag telepítésekor, aminek opcionális függősége.
-
Frawly
veterán
válasz
Laszlo733
#6032
üzenetére
Akkor meg is van a gond. Nemrég a base csomagot átrendezték, nem jó a régi telepítési módszer. A base már nem tartalmaz egy csomó mindent, így pl. kernelt és mkinitcpio-t sem. Pár napja variálták át. bob linkelt róla ennek a topikoldalnak a tetején, a #6007-es hozzászólásban, de itt a hír még egyszer.
Szóval pacstappal (vagy chroot környezetben pacmannal) nyomathatod is fel a linux linux-firmware mkinitcpio nano csomagokat is, mint a huzat.
Pont egy olyan szerencsétlen átmeneti időszakot fogtál ki, amikor már átvariálták, meg hír is van róla, de a Wiki-ben a telepítési útmutatóban még nem írták át. Annyira tudtuk előre, hogy ezt jó páran meg fogják szívni
Szerk.: de, át van írva már a telepítési útmutatóban. Ezért kell mindig a legfrisebb Arch Wiki alapján telepíteni, és nem ilyen más weboldalakon közzétett régi ismertetők alapján.
-
Laszlo733
aktív tag
Sziasztok!
Natív telepíteném az Arch -ot efi módban, /dual boot nincs / de a telepítés felénél a gép újraindításánál a következő hibaüzenetet kapom:
Minimal BASH like line editing is supported. For the first word, TAB lists possible command completions. anywhere else TAB lists possible device or file completions
Mit rontok el, hogy nem jó a grub?
Így telepítettem a grub -ot:
pacman -S grub efibootmgr
grub-install --target=x86_64-efi --efi-directory=/boot
grub-mkconfig -o /boot/grub/grub.cfg
-
Frawly
veterán
Nekem mindenre van, a vim a fő szövegszerkesztőm, és file viewerem, grafikus felületen is (terminálban), nem csak konzolos felületen. Nem csak erre-arra használom. Vifm-ben még a csoportos átnevezés is vim-ben történik, meg sed/awk helyett is ezt használom, amikor csak lehet. Bashban is vi-módot használok. Meg Bashban is van egy olyan funkció, hogy meg tudom nyitni az utolsó parancsot átszerkesztésre vim-ben, fc paranccsal, vagy Esc + v egymásutánjával is ugyanezt a hatást érem el, ez utóbbi a Bash-féle vim-módban visual módba lép be.
Sőt, a WM-et és a böngészőket is vim-es módban meg vim-addonokkal használom, meg sok más programban is vim-billentyűket (Vifm, zathura, less, neomutt, Termite, stb.). Tehát nálam a vim egy életforma, mivel több mint egy text editor, egyenesen egy interakciós módszer, egyfajta működési filozófia az összes proginak. Kár, hogy nem mindegyikben lehet bekapcsolni, vagy konfigurálni vi/vim-módot.
-
Frawly
veterán
válasz
vargalex
#6021
üzenetére
Igen, ha a terminál emulátorral vágod ki egérrel, akkor nem gond, mert akkor nem a vim küldi vágólapra, hanem a terminálemulátor. De! A vim-nek pont az az értelme, hogy gépírástartásban kapcsolgass a módok között. Ahogy kinyúlsz egérért kijelölgetni, értelmét veszti a vim, annyi erővel használhatnál gedit-et, vagy Kate-et, vagy Geany-t.
A vim-nek pont az lenne a lényege, hogy y-nal (yank) jelölj ki normal vagy visual módban. Így kijelölve viszont a garfikus felület felé nem regisztrálódik, ha nincs a vim vágólaptámogatással lefordítva. Tudom, mert szívtam miatta, meg az Arch fórum tanulsága szerint mások is szoptak miatta.
A sima vim csomag annak van, aki konzolból használja csak a gépet (nem grafikus felület + terminál kombóval), és nem akar GVim-et is feltenni, hanem a legminimalistább akar maradni.
-
vargalex
félisten
Engem soha nem zavart a clipboard támogatás hiánya. Kijelölök egy szöveget és középső gombbal (vagy touchpad esetén a 2 gomb egyidejű nyomásával) beillesztem. Nem akarom én nézegetni a vágólapot, nem kell többszörös tartalom, stb.. Mindig az utoljára kijelöltet akarom beilleszteni és ez megy oda-vissza a sima alap vim-el is.
-
Frawly
veterán
Nem. A gvim csomagban lévő „sima” terminálos vim nem GUI-s frontend. Épp olyan karakteres üzemmódú alkalmazás, mint a vim csomagban lévő vim vagy az mc, ranger, stb.. Fut grafikus felület nélkül is konzolban.
Amiről te beszélsz az a gvim csomagban lévő gvim bináris, ami valóban egy grafikus alkalmazás (grafikus felületen GVim-nek látszódik), aminek kell grafikus felület, X.org vagy XWayland, hogy futni tudjon, különben el sem indul, kiírja, hogy nem talált megfelel display-t.
Amiről én beszélek, az a gvim csomagban lévő „sima” vim bináris. Ez Archon +clipboard és +xterm-clipboard compiler flagekkel lett eleve lefordítva. Emiatt ahogy írod is, működik a vim-ből szöveg kihelyezése vágólapra, amit lát egy grafikus X.org-os progi is, pl. egy Gtk-s Firefox. Akkor is látják, ha nincs xsel, vagy stb.. Ennek viszont feltétele, hogy a vim vágólaptámogatással legyen fordítva. Persze az is kell, amit írsz, hogy a terminál tudjon grafikus vágólapot kezelni, de nem tudom kit hülyítünk, minden közismert terminálemulátor tudja ezt, aki meg valami olyan spéci őskövületet használ, ami ezt nem tudja, az magára vessen.
Archban a gvim és a vim csomag egymást kizárja. Ha fent van a vim, akkor a gvim csomag telepítésénél kérdez, hogy lecserélheti-e a vim csomagot, ha nem engeded meg neki a cserét, akkor a gvim nem települ. Persze nem csak a GVim-et telepíti a gvim keretében, hanem a sima vim-et is, pont ezért van ütközés a két csomag között, mert mindegyik ugyanazt a vim binárist is feltenné.
De ez így van Ubuntu- és Debian-származékokon is, azoknál a vim-gtk vagy vim-gnome csomagban lévő vim (és nem gvim) binárisnak van vágólaptámogatása. A különbség annyi, hogy vágólaptámogatással nem rendelkező vim nincs is ezeken a disztrókon, vagyis van, de azt már vim-tiny-nak hívják.
-
F34R
nagyúr
van ha aktiv az xsel, vagy xclip.. egyebkent meg nincs.. [link] meg ugyszint akkor tudod hasznalni ha a terminal emulatorban van clipboard tamogatas. egybkent guirol terminalba siman ment eddig is, vica versa voltak gondok. A gvim meg egy gui-s frontend extrakkal. Nem is kerdes, hogy ezert mukodnek benne az altalad emlitett dolgok. Nalam ez valtozo mi van fent, legendas Distro hopper vagyok.
-
Frawly
veterán
Nem. A gvim csomag Arch alatt két vim-et is tartalmaz. Egy grafikus Gtk-s GVim-et (ez az, amiről te beszélsz), és egy terminálos „sima” (karakteres felületű) vim-et is (de ennek is van clipboard támogatása), ez utóbbit használom én.
Ha a sima vim csomagot teszed fel, akkor az csak egyfajta vim-et tesz fel, de az sem terminálra, hanem konzolra van tervezve.
Persze ez Arch alatt van. Más disztrókon annak a kérdése, hogy a disztró készítői a vim-et milyen csomagba milyen compiler flag-ekkel fordították. Az archerek úgy döntöttek, hogy a sima vim csomagban lévő vim-nél kihagyják a clipboard funkciót a fordítás során, míg a gvim csomagba lévő vim-ben meghagyták. Lehet vitatkozni azon, hogy ez mennyire jó ötlet, de önkényesen így döntöttek.
Mivel te Gentoo-t használsz, nálad ez nem probléma, szépen a vim fordításakor bekapcsolod azt az opciót, hogy clipboard támogatás is legyen, már nem is tudom minek hívják ezt a flaget. Ez a vim vs. gvim csomag felrakása csak az Archnál kérdéses, de ez itt pont releváns, mert az Arch topikban vagyunk, nem a Gentoo-sban. De sokan már Archon is egy huszárvágással véget vetettek ennek a kérdésnek, és vim/gvim helyett neovim-et tesznek fel, amiben szintén van clipboard támogatás tudtommal.
-
-
Frawly
veterán
válasz
vargalex
#6015
üzenetére
Jó, de a vi sem lesz fent. Egyébként meg aki a vi-t tudja használni (mint te és én is), az meg nem vi-t fog feltenni, hanem mindjárt vim-et. Vagyis még inkább gvim-et, mert abban is van sima vim és az úgy van lefordítva, hogy működik a vágólapja a grafikus felület felé. A sima vim csomagban lévő vim-nél ez nem működik, fordítás közben lett kihagyva ez a feature. De gvim helyett lehet neovim-et is használni.
Egyébként a legkorrektebb lenne a szövegszerkesztőkre egy metacsomagot csinálnia az Archnak, editor néven. Így csak install közben annyit kellene tenni, hogy a pacstrap-nak vagy pacmannak a base linux csomagok mellé felsorolni az editor metacsomagot, és telepítéskor számozva rákérdezne, hogy melyik text editort telepítse, onnan meg mindenki kiválaszthatná magának, ami neki kell. Ez főleg kezdőknek lenne hasznos, akik nem tudják előre mit is akarnak, mi a választék.
Aki rutinos róka, az azonnal nyomatja a base linux gvim vagy base linux nano csomagokat, nem akasztja meg ez a változás.
-
Le is zavartam gyorsan egy Arch telepítést virtuális gépben hogy kipróbáljam működik e a megváltozott feltételekkel az install. Működik.
A base rendszer felrakása pacstrap '/mnt base' helyett így néz ki: 'pacstrap /mnt base linux'
a nano szövegszerkesztő már nem része a telepítőnek, az alaprendszer felrakása és chroot olás után lehet felrakni. Az mkinitcpio parancs paraméterezése is kicsit változott: 'mkinitcpio -p linux' (asszem ez volt régen) helyett csak simán 'mkinitcpio -P' -
Frawly
veterán
válasz
vargalex
#6009
üzenetére
Igen, valóban igazad van. Lefuttattam most egy pacman -Syy parancsot és ezután már a pacman -S base nem is metapackage-t, hanem egy szál csomagot akar tényleg telepíteni.
Viszont írja, hogy opcionális függőségnek fent van a linux: bare metal support. Ez mi a tök? Esetleg ez csak simán a kernelt jelenti?
Az sem értem, hogy akkor mi a különbség a metacsomag és a csoport között.
-
vargalex
félisten
Jó lett volna, ha frissíted a repo-t a
pacman -Selőtt. Így nyilván nálad még a cache-elt verziót jelentette. A linkelt hírben egyébként metapackage-t írnak, nem package-t és ez az infó jött RSS feed-ből is.
Ahogy a hír is mondja, eddg a base egy group volt, most viszont metapackage lett. -
Frawly
veterán
Ez sajnos nem tűnik igaznak. Mármint nem téged kritizállak, hanem a hír valódiságát. Most próbáltam ki egy pacman -S base parancsot, a core tárolókban még a régi metacsomagot jelenti, aminek 53 csomag a tagja. Az testing tárolókban is még mindig egy metacsomag, de már csak 3 tényleges csomagot foglal magában: gcc-libs, glibc, linux. Tehát nem igaz, hogy kernelt nem tartalmaz.
Az meg egy kritikus döntés, hogy e2fsprogs-ot sem fog, mert az nagyon szükséges lenne, meg ha a kernelt is kiszedik belőle, függőségnek be kéne húzza mindkettőt. Ez a túlzott karcsúsítás csak arra jó, hogy egy csomó kezdőbb user kifelejtsen valamit, aztán menjen a vergődés, hogy se formázni, se ellenőrizni nem tudja a fájlrendszereit.
Az viszont nem baj, ha a text editort kihagyják belőle. Eddig vi volt a default, de azt sokan nem tudják használni, aki meg guru, úgyis gvim-et tesz fel (akkor is, ha terminálban használja, mert a gvim csomagban lévő vim-ben normálisan működik a vágólap a grafikus felület felé). Aki meg nem ismeri a vi/vim-et, az meg eddig is nano-t használt, vagy mceditet, vagy hasonlót, most csak annyi a különbség, ha nano-nál marad, akkor fel kell tennie.
-
Frawly
veterán
válasz
vargalex
#6003
üzenetére
Jó tudni. LTS kernelt nem használtam még Archon, csak tárolósat meg git-eset. Azt hittem, hogy ahogy azoknál, átnevezi a meglévő kernelt, és nem lesz benne a nevében az lts.
Mondjuk nem is fogok egyhamar LTS kernelt használni Archon, az Arch lényege a frissesség. Ha LTS-re van igény, akkor másik disztró után néznék inkább. Persze teszt erejéig oké, nem is biztos, hogy megoldja a szóban forgó fordítási problémát.
-
válasz
wwenigma
#6004
üzenetére
Grubnál elég egyszerű hozzáadni az Lts kernelt, az lts kernel telepítése után:
grub-mkconfig -o /boot/grub/grub.cfg
Ezzel alapból az lts kernellel fog indulni azthiszem. De kiválasztható marad a sima kernel is ha jól emlékszem. Már systemd-boot-ot használok ott picit macerásabb hozzáadni új kernelt, de nem bonyolult az sem. -
viszont gksu helyett lehet nem artana mast talalni. 
Mondjuk anno azért vettem, mert olcsó volt. Már nem is emlékszem, hogy hány éves.
biztos nem fogod eszrevenni egyebkent. 
(ezért is ellenjavallt NTFS-re torrentezni például)
Köszi mindenkinek, így már felment. 
Új hozzászólás Aktív témák
- Samsung Galaxy Watch8 - Classic - Ultra 2025
- Kormányok / autós szimulátorok topikja
- Ventilátorok - Ház, CPU (borda, radiátor), VGA
- Sony Xperia 1 V - kizárólag igényeseknek
- BestBuy topik
- AMD K6-III, és minden ami RETRO - Oldschool tuning
- Renault, Dacia topik
- ASZTALI GÉP / ALKATRÉSZ beárazás
- Robotporszívók
- Videó stream letöltése
- További aktív témák...
- Designer 4K Monitor - BenQ PD-2700-U
- StarTech Thunderbolt 3 TB3DKDPMAW - Dual-4K Dock
- Xiaomi Redmi 14C 128GB, Kártyafüggetlen, 1 Év Garanciával
- AKCIÓ! Apple Macbook Pro 16" 2019 i9 9980HK 64GB DDR4 512GB SSD Radeon Pro 5500M garanciával
- Bomba ár! Fujitsu LifeBook U727 - i3-7GEN I 16GB I 256SSD I 12,5" FHD I Cam I W11 I Garancia!
Állásajánlatok
Cég: FOTC
Város: Budapest