- Hamarosan megkezdődik a nubia 2,8K-s táblagépének szállítása
- Barátokká váltak az eddig rivális AI-óriások
- ASUS blog: Ideális olcsó utazós gép lett az új Vivobook S14
- Az Aura Displays hordozható monitorhármasa jól felturbózhatja a produktivitást
- Dual Mode-os IPS monitorral adott magáról életjelet a Gigabyte
- NVIDIA GeForce RTX 5070 / 5070 Ti (GB205 / 203)
- AMD K6-III, és minden ami RETRO - Oldschool tuning
- AMD Ryzen 9 / 7 / 5 / 3 5***(X) "Zen 3" (AM4)
- TCL LCD és LED TV-k
- Milyen asztali (teljes vagy fél-) gépet vegyek?
- Milyen billentyűzetet vegyek?
- Házi hangfal építés
- Nvidia GPU-k jövője - amit tudni vélünk
- ASUS blog: Ideális olcsó utazós gép lett az új Vivobook S14
- AI-ra, játékra, mindenre kiváló lehet a Gigabyte új PC-je
-
PROHARDVER!
Arch Linux topik
Új hozzászólás Aktív témák
-
Shyciii
veterán
válasz
anorche1
#8098
üzenetére
Van egy ilyen sorod:
URxvt.font: 9x15,xft:TerminessTTFNerdFontMonoEzt változtasd meg mondjuk 11x17-re, vagy 13x19-re, vagy akár még nagyobbra.
De amúgy nemigazán értem, mert ez urxvt-t feltételez, te viszont xterm-et írtál. Szerintem az xterm ezt használja:
XTerm.vt100.font: 9x15
Ilyen sorod viszont nincsen. Nem lehet, hogy nem xterm-et használsz, hanem urxvt-t?
-
Shyciii
veterán
válasz
Archttila
#8097
üzenetére
Szívesen
Picit módosítottam most a scriptet (rég nyúltam hozzá), és feltűnt, hogy volt amit kétszer raktam bele a telepÍtőbe (nem mintha gondot okozna, meg tizedmásodpercek alatt kész vele), úgyhogy töröltem a duplikációt, meg kikommenteztem a root jelszó megadását. Már egy ideje úgy használom a notit, hogy nincs root user. Aztán kiszedtem a manuális visudo-s megoldást, és a user sudo jog megadását is automatizáltam (user bekerül a sudo csoportba, és a sudo csoportnak adom meg a sudo jogot). -
anorche1
őstag
válasz
Shyciii
#8096
üzenetére
Koszi szepen!
Mas:
Egy i3 -as rendszert csiszolgatok, es egy dologra nem birok rajonni. Hogyan tudom a xterm font meretet novelni? Tul aprok a betuk.
Picit csaltam, a manjaro i3 -as .Xresources fajljat hasznalom, nem sajatot irtam. Ezt itt talaljatok:
[link]
Mit kellene atirnom, hogy nagyobb betuket kapjak? -
Archttila
veterán
válasz
Shyciii
#8095
üzenetére
Értem.
Közben felfedeztem egy érdekességet.
archinstall scriptnél amikor ahhoz a részhez érsz, hogy mit pakoljon fel (0.desktop, 1.minimal, 2.xorg) leave blank meg nem tesz fel semmit, szóval a tegnapi leave blank 160 csomagjával szemben az 1-es minimal csak 140 csomagot telepit.
Gondolom ez bug, mivel a leave blank-nál lenne logikus a 140, minimalnal meg a 160.Mindenesetre érdekes.
Köszi a scriptet
-
Shyciii
veterán
válasz
Archttila
#8093
üzenetére
sati
Ezért mondtam, hogy mindenképp figyelemesen nézd végig :) nekem egyszerűen "muszáj" a NetworkManager, mert notit használok, és nem csak vezetésére, hanem vezetéknélkülire is csatlakozom, ráadásul unifi-s eszközöket is tesztelek vele, így egyszerűen sokkal gyorsabb, és kényelmesebb a NetworkManager. Ha sima pc-m lenne, akkor dhcpcd, oszt kész 🙂
anotche1
Hazaérek, és felpakolom az automount scriptet pastebin-re.
-
Archttila
veterán
válasz
Shyciii
#8090
üzenetére
achinstall script:
Nálam telepítés után a free -m parancs 66MB-ot mutat, a neofetch pedig 161 csomagot. Ebbol a htop és a neofetch utólag került telepitésre, szóval 159. (bár lehet van benne feleslegesen egy networkmanager csomag is)![;]](//cdn.rios.hu/dl/s/v1.gif)
Az általad készített scriptet még editálom
illetve az alapinstall (így hogy már rendesen működik a gyári) felesleges meló, de a post-tot jó lenne majd valamikor összekalapálni. 
Frawly komát miért függesztették fel?
Mit gondoltok, az install script milyen hatással lesz a disztróra nézve? Szerintetek többen neki fognak futni a telepítésnek mint korábban?
Szerintem remek kezdeményezés.
Tényleg pikk-pakk vele az install. -
Blasius
tag
Sziasztok, mindenkinek ajánlom figyelmébe a ramrootot
:https://aur.archlinux.org/packages/ramroot/
Ez a valami lényegében egy script ami feltölti az egész rendszert bootoláskor egy ramdrive-ra (zram). Ez a folyamat nem éppen gyors, de ha megvan akkor a rendszer már a ramdrive-ról fut. Betöltés után már a suspendet célszerű használni rendes újraindítás helyett. Ha nem akarod hogy az ssd-t babrálja vagy hogy a régi típusú merevlemezt ki/be kapcsolgassa/parkolgassa a rendszer, akkor ez egy jó megoldásnak tűnik. De, ahogy írják is, valami miatt csak 5.10 alatti kernellel működik.
Minthogy a rendszer ramdrive-ról fut, a “menet közben” elvégzett változtatások újraindításkor elfelejtődnek. Frissíteni, maradandó változásokat csinálni tehát csak akkor lehet ha a rendszer “rendesen” fut azaz nem ramdrive-ról. A naplózás sem marad meg. Mondjuk nekem alapvetően negatív a véleményem a naplózásról. Egy túlbonyolított, kikapcsolhatatlan, fölösleges teher ami hibakeresésben, legalábbis nekem, még soha sem segített.
Üdv
-
Shyciii
veterán
válasz
Archttila
#8089
üzenetére
Igen, kalapáltak rajta, mert az elején összeomlott párszor, de most kipróbálva jól működött. Simán felment.
Persze, hogy publikus. Semmi olyan nincsen benne, ami titkos lenne:
https://github.com/og900aero/archlinux
Arra figyelj a scriptekben (install.sh, install2.sh), hogy ez kifejezetten számomra van kialakítva. Eleve feltételezi ugyanazt a partíciós kiosztást, van benne a notebookhoz szükséges tapipad beállítás, hogy érzékelje a double tap-ot, saját programok, csak systemd-boot-al csinálja stb., szal mindenképp értően kell belenézni, hogy neked ebből mi használható. Igyekeztem commentezni a sorokat, hogy érhetőebb legyen. Ha van kérdésed, akkor nyugodtan tedd fel.
-
Shyciii
veterán
Egy gyors teszt:
Arch linux saját minimal telepítése (python -m archinstall guided):
- Memory: 78MB
- Packages: 161Debian 10.9 minimal install with standard system package:
- Memory: 69MB
- Packages: 394Arch Linux (saját minimal scriptem):
- Memory: 78MB
- Packages: 158Amint látható, egy minimal Debian bizony kevesebb memóriát zabál, miközben jelentősen több csomagot pakol fel a saját telepítője.
És persze üdvözlendő, hogy az Arch Linux új saját telepítője minimal-t választva tényleg eléggé minimal, vagyis jól sikerült ez a része. Bár az is sejthető, hogy ha nem minimal-t választ az ember, hanem Xorg, vagy Desktop-ot, akkor már jóval bloat-abb lenne, mint az én verzióm, mert kétlem, hogy Xorg-ból nem a teljes pakkot nyomja fel. -
Shyciii
veterán
válasz
anorche1
#8086
üzenetére
Én ezeket raktam fel (Xorg lés intel driver)
xorg-server, xorg-xinit, xorg-fonts-encodings, xorg-mkfontscale, mesa, xf86-video-intel, intel-media-driver
Ez utóbbi viszont videókártya függő. Arch wiki ír is róla:
- HD Graphics series starting from Broadwell (2014) and newer are supported by intel-media-driver.
- GMA 4500 (2008) and newer GPUs, including HD Graphics up to Coffee Lake (2017) are supported by libva-intel-driver. -
anorche1
őstag
Mely csomagok szuksegesek, hogy integralt intel gpu -val mukodjon minden (pl. hardvers gyorsitas)? i7-4800mq -ba epitett hd4600 -rol van szo.
En ezeket tettem fel, de valoszinuleg ez tobb, mint kellene:
xf86-video-intel, mesa, xf86-video-vesa vulkan-intel libva-intel-driverMeg en a xorg csomag csoportot egy az egyben telepitem, de valoszinuleg ez is felesleges.
-
Frawly
veterán
válasz
Archttila
#8083
üzenetére
Nem tudom. Én btrfs-re csinálnám, és ahhoz RAID sem kell, mert be van építve a btrfs-be, hogy lemezen átnyúló redundáns kötetet is tud. A ZFS dettó. Az ext4-gyel sincs baj, ha RAID van alatta. Amelyik jobban tetszik, jobban bízol benne. Esetleg a RAM-tól is függhet, de ha az RPi-ról van szó, akkor azon a 4 giga RAM elég a ZFS-hez is.
-
-
Frawly
veterán
válasz
Archttila
#8081
üzenetére
Én azért X.org-ozok, mert azon többféle WM van. A Wayland jó, de csak kevés WM érhető el alá. Jó a Sway, de meg akarok ismerni mást is. Nem akarok olyan szemellenzős lenni, mint a kollégák a Linux OFF topikban, hogy 7-10 éve vannak beleragadva ugyanabba a disztróba, grafikus felületbe, megoldásba.
Az Xmonad-nak az a baja, hogy Haskell-ben van írva, az meg egy nagyon spéci programozási nyelv, ami funkcionális, mindenféle lamba calculus kell hozzá, hogy megértse valaki. Ilyen teljesen elvont, nyakatekert koncepció. Emiatt én sose fogom megérteni, feltenni. Ha sima C-ben, vagy göcsörtös C++-ban vagy hasonló sztenderd imperatív strukturált nyelven lenne írva, akkor megküzdenék vele, de így felejtős örökre.
Én, ha most kéne gépet venni, akkor akármennyire is AMD Ryzen párti vagyok, mivel azt nem nagyon lehet normális áron kapni, mivel hiány van abból is, simán Intel i5-10400-at, vagy i5-11400-at vennék, 6 mag, 12 szál, iGPU, hozzá 2×8 giga DDR4 RAM. Sima ATX, semmi ITX meg passzív, meg egyebek, készleten is van szinte mindenhol, ajánlott fogyasztói árnál nem sokkal magasabban. Ennek van most a legjobb ár/értékaránya, mármint az olyanok közül, ami jövőtálló is. Bár egy Ryzen 1600-3600 se rossz vétel egy olcsó B450-es lappal, csak ugye azt ki is kell fogni, hogy legyen valahol normális áron készleten, és annak alacsonyabb az IPC-je, és ahhoz kell dedikált GPU is. Később meg beledobnék GPU-t, ha lement az ára, vagy most egy 750Ti vagy hasonló alap kártyát (bár az linuxozáshoz nem a legjobb, mivel NV), AMD RX560, vagy ilyesmi, aminek nem szabadult úgy el az ára. Én nem vagyok márkahívő, simán azt veszem, ami a legjobb vétel, és van benne annyi időtállóság, hogy később se kelljen kidobni, meg sztenderd alkatrészekkel lehessen bővíteni. Egyedül GPU-ból szoktam lehetőleg AMD-hez ragaszkodni, de ott sem márkahűségből, hanem Linuxon ahhoz a legjobbak a GPU driverek összességében, és nem kell zárt driverrel szórakozni, ahogy NV kártyák esetén. De laptopnál elmegy most az Intel IGP is, a legújabb Xe UDH 730-750 nem is annyira rossz, felért az AMD Vega 3-8-10 szintjére, teljesítményben legalábbis, de driverben sem annyival rosszabb.
-
Archttila
veterán
Meg a dwm-bspwm váltás is sok hete csúszik
A bspwm-en én is gondolkodom már egy ideje
bár sajnálnám dobni a Sway-t mert hozzád hasonlóan nekem sincs vele semmi bajom. (neked sem volt ha jól rémlik) és különben is, tetszik ez az Xorg mentes élet.
Viszont jó lenne kipróbálni mást is, tanulni valami újat, kísérletezni új panellal, ilyesmik...
Xmonad-ot egyszer megnéztem (és szégyen van sem) de nekem magas. ellenben bspwm konfigokban mazsolázva azt éreztem, hogy ez nekem való, átláthatóbb, emészthetőbb.Pulseaudio-Pipewire váltás meg egy hete volt meg
Ezt én is megejtettem még ARM-on. Hibátlanul működött, annyi hogy a Sway miatt módosítani kellett pár dolgon de semmi komoly...:
XDG_CURRENT_DESKTOP=swayGép. Tudod én voltam az, aki több százeres ITX-eket épített anno
olyanokat, amilyeneket boltosbéla max csak júúútyúbon látott de az elmúlt 30 évben egyetlen gépet sem bíztam volna soha másra.Igen ITX lett, de csak egy alap 4 magos passive motyó 8GB rammal, PICO PSU-val
Több mint tökéletes és teljesen néma, pont amilyenre szükségem van az OLED TV alá Ha minden a terv szerint megy, (és nem dobom a Sway) akkor szinte pikk-pakk belakom az új rendszert.
A Raspberry meg kap egy DietPI-t Pi-Hole-al, rtorrent-tel vagy a már megszokott qBittorrent-nox-al, plex-el, Sambaval, SSH-val... és kb ennyi, 0/24 mehet is a dolgára -
Frawly
veterán
Ja, mondtam én, hogy nem nehéz. Sok felhasználó azért fél tőle, mert nem érti hogyan működik, meg ilyen Buguntu telepítő összegányolja neki automatán nem működőre, vagy mint ubyegon, hogy kifogtak nem szabványos UEFI implementációs gépet, ahol az UEFI boot Windows only-ra van bedrótozva. Persze ez utóbbit is meg lehet oldani, csak nem olvasnak utána. Ebből meg az a mítosz alakul ki, hogy az UEFI boot szar, meg nem működik, meg lehetetlen, meg így meg úgy.
#8075 sati: a DE-k nem nyúlnak a default shellhez. Ő állította át a user accountban. Én is átállóban vagyok, a /bin/sh symlinket lecseréltem /bin/bash-ról /bin/dash-ra. De ez a scriptshellt cseréli le. A dash egy minimalistább, gyorsabb shell, ami jobban POSIX szabványos, szemben a Bash-sal. Pár héten belül a Bash interaktív shellt is lecserélem zsh-re. Meg a dwm-bspwm váltás is sok hete csúszik. Pulseaudio-Pipewire váltás meg egy hete volt meg.
A váltás nem megy azonnal, mert zsh alatt is ki kell kísérletezni beálításokat, pl. vi-mód, prompt csere, autokiegészítés, stb.. Persze mindezt oh-my-zsh nélkül, saját kútfőből. Az oh-my-zsh lényegében csak egy pluginmanager, ami a zsh-be tud felhasználói scripteket és beállításokat importálni. De ilyeneket kézzel is tudsz magadnak írni a zshrc-be, nem kell hozzá külön bloatot feltenni.
Gépösszerakósdival csak annyiból nem jó várni, hogy ha magyarban vetted, helyi boltban, akkor főleg célszerű 3 napon belül összerakni, hogy ha valami nem működik, hibás, akkor 3 napon belül visszajuttatva azonnal cserélniük kell, nem ülhetnek rajta 15-30 napig ilyen-olyan bevizsgálás, javítás, stb. címén. De ha online vetted is, akkori is meg 14 vagy mennyi napon belül érdemes megejteni, hogy ha hibás, el tudj állni a vételtől.
-
attilav2
őstag
Openbox + tint2 tálca egy ideális kezdő pálcika wm, Rimuru arch telepítési blogjában van róla leírás, illetve jó még az Arch openbox wiki, Debian openbox wiki
-
Frawly
veterán
válasz
attilav2
#8071
üzenetére
Elég ritkán történik meg, ahogy nézem, gyorsan helyre is hozták. Nyilván ők is emberek, korlátozott erőforrásból (saját pénz, adományok, nonprofit működés) nem tudnak egész szerverparkokat és adatcentereket ballancerrel megoldani, előfordul, hogy az az egyetlen szerveren lerohad valami, csak az nem hibázik, aki nem dolgozik. Ilyenkor visszanézel később. Semmit nem lehet ellene tenni.
-
Frawly
veterán
Ó, bazz, elfelejtettem előtte topikot váltani, nem ide akartam. Benéztem melyik topikba megy. Most már mindegy, itt hagyom, nem írom át az OFF-ba is. Gondoltam megindulhatna egy disztrófüggetlen eszmecsere róla, de így már mindegy.
#8069 attilav2: igen, BT-vel lehetnek bajok. Igaz az Pulseaudio-val is problémás. Semmit nem konfiguráltam, Arch Wiki ajánlására benyomattam a pacman -S pipewire pipewire-pulse pipewire-alsa parancsot, erre engedélyt kért, hogy leszedje a pulseaudio-t. Telepítés után reboot és minden ment. Nem kellett hozzá semmit konfigurálni. Igaz a DAC-om még nem próbáltam ki rajta, minden más egyelőre úgy tűnik megy, böngésző, lejátszóprogramok, játékok, egyelőre nem futottam semmi hibába. Még a pulsemixer és pamixer is épp úgy működik. A HUP-on már régóta ajánlgatják, de eddig nem mertem feltenni, mert nem volt időm, hogy ha nincs hang, akkor újabb problémát kelljen megoldani. A másik gépemen egyébként fent volt a Pipewire, Archon és Artixon is, de azokon a Pulseadio mellett, nem helyett üzemelt, ami azért elég lényeges különbség.
-
attilav2
őstag
Én is átlőttem egyszer pipewire-ra, de az előlapi fejhallgató kimeneten nem adott hangot, próbáltam debugolni, valamelyik audio sink nem működött, legalábbis a systemd-s debug eszközök szerint. Vissza állítottam a pulse-t egyből működött a fejhallgató. Az arch pipewire wiki szerint a bluetooth-al is lehetnek gondok. Leírhatnád hogy a pipewire-t hogyan konfiguráltad be, milyen csomagokat tettél fel, szedtél le.
-
Frawly
veterán
Némileg OFF-beli OFF, de átlőttem Archon a Pulseaudio-t Pipewire-re. Minden működik továbbra is. RAM fogyasztás nem változott, de a CPU terhelés lement kb. felére. Eddig tetszik, de még nem tudtam kellően tesztelni.
Azért nem az Arch topikba írom, mert nem archosokat is érdekelhet, illetve sem nem kezdő, sem nem haladó téma. Egyszerű ajánlás.
-
Frawly
veterán
Csinálj UEFI-t. Jobb, gyorsabb, egyszerűbb. Arch Wiki systemd-boot szócikkét nézd.
Az UEFI boothoz csak 1 extra partíció kell, de még ez se extra, mert egyben a /boot szerepét is betölti. Egy kb. 100 megás, vagy kicsivel nagyobb FAT32 partíció, mindenképp 1 giga alatt adj meg neki méretet, Archnak nem kell sok hely, ha lesz mellette más OS is, akkor viszont nem árthat 200 mega felett adni, akár 500-ig is. A típusa mindegy is, de „EFI System” típus szokott lenni, és FAT32-re kell formázni, és így kell telepítéskor felcsatolni /boot-ként. Annyi, hogy UEFI bootnál a partíciós tábla ne dos/MBR legyen hanem GPT.
Lényegében az egész systemd-boot telepítése csak egyetlen bootctl install parancs. Meg az EFI partíción két .conf fájl szerkesztése kézzel, amibe megadod neki a bootmenü opcióit, és a kernelparamétereket, initramfs nevét. De cserébe se GRUB, se semmilyen nyomorékság nem kell hozzá, később nem törnek el ilyen hülyeségek.
UEFI BIOS-ban sem kell általában állítani semmit, a legtöbb gépen a deafult az UEFI boot vagy UEFI + Legacy BIOS boot. Bár én azért meggyőződnék, hogy a bootopció UEFI only boot-on legyen, az a legtisztább, nehogy elkezdjen az Arch iso mégis Legacy BIOS módban bootolni.
Az UEFI boot egyébként sok mindenben megegyezik a Legacy BIOS boottal. Annyi a változás, hogy az OS-ek a bootkódjukat többé nem a lemez 0. szektorába, az MBR-be teszik bele, hanem a FAT32-es EFI partícióra teszik .EFI fájlok formájában. Így több OS megfér egymás mellett kulturáltan, és nem írják felül egymás bootszektorát, és emiatt többé az OS-ek telepítési sorrendje is mindegy lesz. Az UEFI BIOS meg tudja kezelni ezeket az .EFI fájlokat, indítani. Ennyi a lényege tömören.
De az UEFI bootnak van egy csomó előnye. GPT partíciós táblával megy, amiben csak sima (nem göcsörtös) partíciók vannak, nincs vergődés többé ilyen elsődleges, kiterjesztett, logikai partíciókkal, nem kell bootflagekkel szórakozni, nem kell külön bootmanagert telepíteni (hiszen az UEFI BIOS egyben már bootmanager is, és tudja menedzselni neked az általa detektált EFI partíciókon lévő .EFI fájlokat).
Plusz az UEFI bootnak előnye lehet, hogy a gép az OS betöltése előtti eszközinicializálási időt lerövidítheti. Nem minden gépen, de néhányon ez lehet a helyzet. Hiszen ha nem hagyományos BIOS módban bootol, akkor nem végez el egy csomó, visszafelé kompatibilitás miatt benne hagyott hagyományos BIOS POST eszköztesztet, és kihagyva ezeket a sallangokat gyorsabban eljuthat a gép az OS betöltőjéig.
Meg most már így 2021-ben nem célszerű MBR Legacy BIOS bootot erőltetni, hacsak nincs annyira szükség az adott gépen, hogy valami legacy OS-t futtass, DOS, Win9x, XP, vagy hasonló.
A másik előnye az UEFI bootnak, hogy pl. Archnál csak egyszer kell megcsinálni. Utána megmarad, esetleges újratelepítésnél már hozzá se kell nyúlni az EFI partícióhoz, simán bootol majd vele az új telepítésű rendszer is, főleg, ha PARTUUID-kel hivatkoztál a root partícióra és nem particináltál újra. Ez jelentős kényelem a hagyományos MBR-es boottal szemben. Illetve előny, hogy ha nem is bootolna a rendszer egyszer, akkor is könnyű megjavítani, mert a FAT32-es partíciót minden OS olvassa, írja és csak szöveges config fájlokat kell a sytemd-boothoz szerkesztened, emiatt nem kell speciális Live rendszert, meg GRUB javítókonzolt beizzítani, hanem bármivel megjavíthatod a dolgokat. Ez se elhanyagolható.
-
Sonja
nagyúr
Gép meglett, de most végeztem az összetevéssel.
Ubuntu 20.04 szépen elindult, így majd csak holnap délután fogok neki az Arch telepítésnek. Viszont nem tudom, hogy csináljak-e UEFI-t vagy maradjon az MBR?! 
Soha nem csináltam UEFI telepítést, azt se tudom, hogy kell, és milyen partíciókat létrehozni. 
-
Frawly
veterán
válasz
Apollyon
#8058
üzenetére
Máris nem időtálló, vagyis persze, nem avult el, de ha annak idején vette volna azt, amit írtam, azt most minimális pénzből upgrade-elhette volna egy 5600X-re, vagy 5800-ra, ami főleg az egy szálas ereje alapján köröket fut az 1. genes Threadripper köré. Ezt csak példának írtam, hogy a papíron brutális hardverre pénzégetés nem mindig a legjobb dolog, akkor se, ha van pénzed. Meg igazából a prémium hardver sose érte meg, mert nem volt jó az ár/értékaránya. Kicsi többletteljesítményért és presztízsbeli előrelépésért aránytalan felárat kellett mindig is fizetni, magyarán nem a teljesítményt meg nem az időtállóságot fizeted meg, csak a prémium életérzést, hogy elmondhasd, hogy neked az aktuális leg-leg van meg.
Attól is függ, hogy mire használja valaki. Mert az a 1920-as Threadripper amúgy erősebb, mint egy akárhány genes közép-Ryzen. De csak akkor, ha olyan felhasználásod van, hogy a magokat mindet kihajtod általában, meg hasznosul a sok cache is, pl. server/workstation-szerű felhasználásnál. Ha csak ilyen átlag user desktop és youtuber felhasználás, meg némi gaming, ott inkább az számít, hogy legyen 4-6 mag és egy magon legyen erős.
Míg ha SSD-be vagy jobb monitorba fektetett volna, akkor az mindenképp hasznosul, több tárhelye lett volna videókat vágni, VM-ezni, meg a több pixel jobb képminőséget, jobb olvashatóságot adott volna neki.
De billentyűzeteknél is ezt játszotta a koma. 400 dolláros, spéci, ergononomikusan osztott mechanikus billentyűzetből már a másodikat vette nemrég. Míg egy sztenderd, normál ANSI kiosztású 100-150 dolláros, jobbfajta kapcsolós mechanikus billentyűzettel jobban járhatott volna, de nyilván olyat nem vett, mert olyan csak a proliknak van, és nem prémium, ergo „égő”.
A másik oldalon meg van a fószernek egy erőforrásokkal feleslegesen spórolós mániája is. Nyitja a VM-et, erre büszkén mondja, hogy 2 szál, 4 giga memóriát adott neki. Közben meg a többi 20-22 szál, meg a többi ~55 giga memória ott áll üresen, de nyilván nem lehet a VM-nek többet adni, mert az milyen lenne már, hogy a megvett hardver lenne valamire használva, rárúgná az ajtót a helyi kommandós osztag.
-
befrissült a KDE, azóta a kijelölés a terminálban... mondjuk úgy, hogy kevéssé látható.
hol állítom ezt be valami normális erősségűre? -
Apollyon
Korrektor
De ugyanezt játszotta el a procival is. 12 magos, 24 szálas Threadripper 1920-ast vett, amihez drága, spéci alaplap is kell...
Ha van pénz lóvéra, akkor miért ne? Lehet, hogy olyan dolgokat is csinál a gépével, amiről nem beszél. Pl. bányászik vagy boinc-ozik vagy valami. Az biztos, hogy az ő gépe időtálló lesz. Bár most a globális chiphiány miatt valószínűleg mindenkié.
-
Frawly
veterán
válasz
Shyciii
#8056
üzenetére
Azért szerintem a 8 ajánlottabb. Nagyon keservesen, de beleférnék én is a 4-be, de akkor a rendszerhez swapot kell tartani, meg én rendszeresen vagyok 3 giga felett, és akkor már gyakran elkezdené használni a swapot is. 8-nál is kell még a swap, de akkor szinte csak nagyon ritkán nyúl hozzá. 16 gigánál meg átlagosabb desktop felhasználásnál teljesen elhagyható a swap.
Egyébként igen, nekem is ment le az idők folyamán a memóriaigényem, eleinte KDE-vel meg Cinnamonnal kezdtem, meg egy időben Chrome-ot is használtam. De aztán ahogy lett előbb mindenféle kisebb DE, majd WM-ek, Openbox, i3, Sway, dwm, egyre inkább ment lefelé. De ehhez nem csak a WM-ek járultak hozzá, hanem ahogy telt az idő, egyre inkább több programom terminálos lett. Régen pl. használtam LibreOffice-t, GUI-s text edittort, torrent, stb., ezeket fokozatosan kiváltottam terminálos megoldásokkal.
Ennek ellenére a memóriafogyasztásra figyelek. Minden gépemben 16 giga van (bár két laptopnál levesz belőle az integrált GPU is), és általában a nagy része üres, de mégis figyelek erre, mert elsősorban innen mérni le, ha valami megoldás bloat. Ha sok memóriát eszik, és nem azért, mert nem férne bele, de amelyik progi sok memóriát használ, annak a szutykainak a betöltögetésével a procinak is időznie kell, többletfeladata van, sanszosabb, hogy más I/O műveleteket (lemez) is jobban igényel akkor, az meg növeli a reagálási időket, pár ms itt, pár amott. Hiába bika a proci, javarészt egy szálon töltődnek ezek a szutykok.
Ez nagyon szépen tapintható a két véglettel. Egy KDE pl. 8-9 mp. alatt tölt be SSD-vel is. Ugyanez egy minimalista WM-mel, konzolos bejelentkezéssel harmada, majdnem negyede is lehet időben. És nem a gép lesz gyorsabb, egyszerűen csak kevesebb mindent kell a procinak betöltögetni, kevesebb utasítást kell végrehajtania, kevesebb minden olvasódik be háttértárról, és a sok kicsi meg összeadódik. De ugyanez van betöltési időknél egy terminálos progi betöltődése még ms-ben sem nagyon mérhető, míg egy nagyobb GUI-s alkalmazás, ami ugyanazt csinálja, azért több msec vagy akár majdnem másodpercben is mérhető késéssel töltődhet be. Azért nagyon nem mindegy, hogy valami azonnal vágódik a képernyőre, még az embernek a billentyűt sincs ideje felengedni, vagy van-e egy kis töltögetés.
Persze a másik végletre is figyelni kell, mikor valaki pótcselekvésből túl sok RAM-ot vesz. Pl. a DistroTube csatornán az amerikai faszi, eleve 32 giga RAM-mal vette a mostani gépét, abból is általában 20+ giga állandóan kihasználatlanul állt, mivel minimalista tiling WM, terminálos alkalmazások, kevés grafikus progi (böngésző, OBS felvétel 1080p-ben, KDEnlive videóvágás 1080p-ben, néha 1 szál VM). Erre pár hónapja bővítette 64 gigára. Nyilván semmi nem lett gyorsabb, most már 20-30 giga helyett 52-62 giga áll üresen. Ráadásul ez az a mennyiség, amit már a kernel cache-elésre se használ el, ez ilyen abszolút pocsékolás, pénzégetés, pótcselekvés, e-pénisznövelés.
De ugyanezt játszotta el a procival is. 12 magos, 24 szálas Threadripper 1920-ast vett, amihez drága, spéci alaplap is kell. Elégette rá az értelmetlenül sok pénzt anno, mikor megjelent. Közben meg egy 1600-2600-as Ryzennel (plusz egy normális B450-es AM4 alaplappal), simán jobban járt volna, az is 6 mag, 12 szál, bőven elegendő lett volna neki, de még akár gyorsabb is lett volna, mivel egy mag magasabb órajelre turbózik fel (hiszen egy magra több Watt energiakeret jut). De ha 6 mag nem elég, egy Ryzen 2700X (akkor még nem jelent meg a 3xxx/5xxx sorozat) mindenképp már sok lett volna neki, de a proci-lap csak töredékébe került volna. Ugyanígy, 32 helyett vett volna 16 gigát, azért ezen a szinten nagy különbségek vannak. Ezt megfejelte Radeon VII workstation kártyával, amit megint nem használ ki, néha napján játszik csak, akkor is 1080p-ben. Akkor már jobban járt volna egy jóval olcsóbb RX5700-zal, felébe sem került akkor, játékokban talán még kicsivel több fps-t is kapna. Ez az, hogy az overkill hardvernek a legtöbbször nincs értelme. A többletpénzt meg beletehette volna több/nagyobb SSD-be, akárhány TB-ba, vagy lecserélhette volna a 3 darab FullHD monitorját 4K-ra, vagy vett volna még jobb kamerát, az értelmesebb pénzköltés lett volna, ha már a pénz mindenképp égette a zsebét.
-
Shyciii
veterán
8GB ram? Nekem a kezdetek óta 4GB van, és amióta openbox-al elkezdtem ismerkedni, azóta sosem fogytam ki belőle, pedig a swappiness 10-re van állítva. Most hogy régóta bspwm-et használok, azóta meg pláne nem tudok kifogyni, pedig volt, hogy 20 felett volt a távasztali csatlakozás, böngésző, openvpn, fájlkezelő, terminál ablakok.
-
Frawly
veterán
válasz
Archttila
#8054
üzenetére
Nem kell figyelni semmilyen sorrendre. Ugyanazon EFI partíciót használják, sőt, az azon lévő .EFI fájlokat is tudják közösen használni, ha az adott disztrók mindegyike támogatja a systemd-bootot. Annyi, hogy a közösen használt /boot/loader/*/*.conf fájlokba hozzá kell adni a másik rendszer kernelbetöltő sorát, paraméterestől, root partícióstól, stb. és simán bootolnak.
Ez a jó az UEFI bootban, hogy azonos EFI partíciót használnak, legfeljebb különöbző .EFI fájlokat, amik megférnek egymás mellett. Mert MBR Legacy BIOS bootnál az volt, hogy átírogatták az OS-ek egymás alatt az MBR-t, így számított a sorrend.
-
Frawly
veterán
válasz
Archttila
#8049
üzenetére
A retró játékokat jellemzően elég jól futtatja a Wine. Amelyiket mégse, arra natív Windows telepítést tarts. virtuális gépben sose lesz az igaz, meg lehet GPU passthrough-val szórakozni.
8 giga arra, amit írsz, elég, de a 2×8 nem sokkal drágább, és időtállóbb. Ha nem is használod ki, akkor is a kernel befogja cache-elni, befoghatod ramdrive-nak, böngészőcache-nek, így pocsékba nem megy, meg legalább akkor a swap-ot is teljesen mellőzheted.
A 8 giga attól is függ, hogy integrált vagy dedikált GPU-t használnál (ami a RAM-ból foglal le magának).
#8050 Apollyon: a SwayWM kevesebbet fogyaszt, mint az i3 és a dwm, de nem a WM része miatt, hanem mivel Wayland, ezért nem futtat komplett X.org servert, hanem csak egyes programokhoz XWayland emulációt. Illetve Wayland alatt nekem ugyanolyan problémátlan volt a Wine, Steam, mint X.org alatt.
-
Apollyon
Korrektor
Látom nem spóroltál a tárhellyel.)
(#8049) sati: ha nem tolsz komoly dolgokat 8 giga ram is elég lesz, de az a jövőbiztos, ha 2x8 van... Bár ha jól olvastam, eddig 4-ből is kijöttél, akkor már a 8 is kánaán lesz.))) Böngészésre biztos elég és vm-re is, ha csak az lesz amit írtál.
Ha meg van steamed, akkor protonnal elvileg jól kell fussanak a dóz only cuccok is, pláne a régiek.
Mondjuk swayt sose használtam, csak i3 volt meg dwm, és szigorúan X, mármint, ha wayland alól tolod, akkor lehetnek gondok steammel is. -
Archttila
veterán
En is pentekre terveztem be a desktop gep szereldet
Eddig ARM-on zuztam az Arch-ot, de vegul ugy dontottem megy vissza a PI servernek a szekreny tetejere Memoriaval kapcsolatban lenne egy kerdesem. Sway melle (kb 400MB az alaprendszer) szerintetek eleg lesz a 8GB RAM ugy, hogy idonkent azert befigyelne egy kis virtualizacio? Semmi komoly, csak amolyan disztro mustra.
Illetve a gaming vonalat egy ideje mar elengedtem, de a retro (2000 elotti) jatekok azert meg a szivem csucskei. Szoval idonkent ezeket is Windows alatt inditanam WM-be, mert korabbi tapasztalataim szerint azert a Wine sem tud mindent elfogadhatoan futtatni. Mondjuk az is igaz h jo reg volt mar mikor utoljara hasznaltam...Holnap adnam le a rendelest iPon-os ismerosnek, de ha azt mondjatok hogy felesleges a 16GB-os KIT akkor nem vennem meg.
-
Frawly
veterán
válasz
attilav2
#8046
üzenetére
Valahol már minden modern initrendszer kicsit systemd-szerű lett, mindegyik támogat párhuzamos service-indítást, service-függőségkezelést, eseményekre reagálást.
dhcp service-nek gondolom vannak kapcsolói, hogy kiírja mit csinál. Szerintem hosszabb távon jó, ha nem írja, nem hányja tele a képernyőt szeméttel, meg kicsit gyorsabban is fut.
-
attilav2
őstag
A Runitban az nem tetszik így első blikkre hogy elég szűkszavú, pl mikor az OpenRC elindítja a dhcpcd-t akkor szépen látszik ahogy végbe megy a dhcp folyamat, ugyanígy az nfs szervernél is látom hogy miket írkál ki. Runitnál semmi visszajelzés, csak annyi hogy a szolgáltatás elindult... ez így nagyon systemd-s. Meg ha el akarok indítani bootoláskor egy szolgáltatást akkor symlink készítésével tudom megtenni, ez sem jön be, itt megvan az elégépelés esélye, szerintem macerásabb mint az rc-update. Persze OpenRC-nél is van szolgáltatás aminél symlinkelni kell, pl dhcpcd, de ezek kivételek, a nagy többség az rc-update-val felvehető az indítási listára. Talán azt lehet modani hogy az OpenRC konzervatív megodásokat használ, a Runit meg inkább systemd szerű.
-
Frawly
veterán
-
Frawly
veterán
válasz
attilav2
#8042
üzenetére
Az OpenRC-vel nekem vegyesek a tapasztalataim. Gentoo alatt bejött, Artix alatt hagyott kívánni valót maga után, de azért használható volt.
Amúgy isten hozott a minimalistább WM-ek világában. Igen itt minden kényelmi funkcióért küzdeni kell. De csak először, amíg meg nem érted mi kell hozzá, meg el nem mented azt a néhány .xml meg .conf fájlt a home-ból, .config mappából, utána elég csak azokat visszahúzni minden gépen, minden újratelepítésnél és meg fogod látni hogy így a fájlokat visszamásolva az egész sokkal gyorsabban újra bekonfigurálható, újra belakható, sokkal részletesebben testre szabhatóbb, mint a KDE valaha is volt/lesz, nem kell egyenként minden grafikus szarban hatodik fül eldugott menüjének akármijére kattintgatni végig, mire minden be lesz állítva. Az már csak hab a tortán, hogy mennyivel gyorsabb vele a gép, szemének alig hisz az ember, hogy a grafikus felület milyen gyorsan bevillan.
Azzal is egyetértek, hogy az Artix dokumentációja elég gyér, bár ők ezt úgy gondolják, ha valamit nem találsz benne, akkor az Arch Wikit olvassad. De a Gentoo Wiki is hasznos, meg tapasztalatom szerint a Debian Wiki is, utóbbi főleg a Wi-Fi driverek kinyomozásához, de vannak még benne egyéb jó dolgok, amik a többi Wiki-ben nincsenek benne.
-
attilav2
őstag
Egyre jobban kezdem belakni az Artixot, tetszik az openrc, érthető logikája van. Viszont a disztró dokumentáltsága hagy kívánnivalót maga után, hol a gentoo wikiben hol az arch wikiben hol az artix saját oldalán van a megoldás. Arra nem találtam leírást sehol hogy melyik csomagot kell telepíteni az openrc-s bluetooth szolgáltatáshoz, illetve ami volt leírás az abban levő csomag már nem létezett, végül a google egy artixos github tárolóhoz vezetett amiben ott volt a csomagnév: bluez-openrc, ezt kellett felrakni és elindítani, és a megfelelő pulse bluetooth modulok betöltése után már ugrásra készen állt a bluetooth fejes. Bliuetoothctl-lel a párosítás simán ment, de kapcsolódni stabilan az istennek nem akart, végül a pulseaudio többszöri újraindítása oldotta meg a dolgot és ment a fejes. Openboxot kezdem belakni, beállítottam időzített képernyővédőt és lezárást(xscreensaver) a debian openbox wiki alapján, billkombóra bekapcsoló képernyőzárat(xlockmore) egy linuxos fórum alapján. Sokkal gyorsabb ez a sovány openbox wm+tint2 mint a KDE, csak minden kényelmi funkcióért meg kell küzdeni
Az is tetszik még az openrc-ben hogy amikor elindítok egy szolgáltatást akkor általában kapok valami visszajelzést, mikor az nfs servert indítottam akkor is kaptam egy egész korrekt visszajelzést hogy milyen paraméterekkel indult, systemd-nél nincs visszajelzés. Szerintem az Artix az Arch és a Gentoo keveréke, a gentoo szállítja az init rendszert és nagyrészben a rendszer konfigurációs struktúrát, az arch pedig a csomagkezelőt és a rendszer konfigurációs struktúra kisebb részét. OpenRC-s szolgáltatásokat/gentoo specifikus részeket a gentoo wiki alapján állítom be. Arch specifikus részeket meg arch wiki alapján, ha valami ezekben nincs meg általában segít a google 
-
Frawly
veterán
válasz
attilav2
#8040
üzenetére
Elvileg a cryptsetup defaultjai megbízhatók. AES256, XTS, meg valami min. 2048 bites hash.
Bitlocker megint olyan, hogy zárt forráskód. Próbálhatod helyette a VeraCrypt-et, az TrueCrypt formátumú konténereket és partíciótitkosítást tud, és azt el tudja olvasni írhatóra a LUKS.
A cryptsetup alapból nem titkosítja le az egész meghajtót, hanem csak headert ír fel, meg egy két adatot és csak annyit titkosít. A jövőben rákerülő adatok viszont titkosítva lesznek. Ennek ellenére cryptsetup után ajánlanak egy teljes dd if=/dev/rand parancsos végigírást, de szerintem ez nem szűkséges, majd ahogy telíted be a meghajtót, partíciót, majd titkosodik az egész adatterület.
-
attilav2
őstag
A LUKS titkosítási paramétereibe nem mélyedtem bele, alap beállításokkal titkosítottam, a linkelt leírásnak és videónak megfelelően, remélem így is jól véd
TRIM jó kérdés megy e, ha nagyon belassul egy idő után a rendszer akkor nyilván nem, de majd akkor keresek rá valami megoldást, sajnos az angolom elég sekélyes, arch fórumon / redditen, stb, nem tudok kérdezni LUKS vs TRIM témában, majd lehet valakit megkérek. A bitlockerrel titkosított meghajtót úgy tűnik csak olvashatóra lehet felcsatolni linux alatt dislockerrel, pedig írható megoldásnak hirdeti magát a dislocker, még tovább kell keresgélnem leírásokat. A ruby függőség nélküli dislocker-t érdemes telepíteni aur-ból(dislocker-noruby) az alap dislocker egy frissítés után elhasalt a ruby frissülése miatt.
Az viszont feltűnő hogy a bitlocker legalább 1-1.5 órát molyolt egy ssd titkosításával(256 AES XTS-re állítottam a gpedit-ben), míg a LUKS töredék idő alatt megvolt. Lehet hogy azért van ez a nagy időkülönbség mert a bitlocker a meghajtón levő adatokat titkosítja mikor átkonvertálok egy lemezt, a LUKS meg valószínűleg nem foglalkozik a meghajtón már rajta levő adatok titkosításával hiszen a LUKS kötetet létrehozása után formázni kell, és ha adatok kerülnek rá akkor röptében titkosítja. Az Arch mellett az Artix-ot is újratelepítettem titkosítva.
Nagy dilemma hogy mi legyen a külső hdd-kkel, hiszen a bitlocker írhatóságával gondok lehetnek linux alatt, lehet azt csinálom hogy a kritikus adatokat titkosított konténerbe rakom, nem egész lemezeket titkosítok. -
Frawly
veterán
válasz
attilav2
#8038
üzenetére
Így van, ezeket teljesen jól foglaltad össze. Ha nem támogatja a BIOS, attól még használhatod, de bootkor, egy másik rendszer alól kell kinyitni hdparm-mal. Nyilván, így bootolni nem lehet róla, csak adattárnak használni.
Másrészt meg valóban, nagyon kell figyelni, hogy jól jelszavazd le, és ne felejtsd el a jelszót, mert a hardveres titkosítás nem csak az adataidat, hanem az SSD-t is védi lopás esetére, és ha nem tudod a jelszót, akkor reszeltek az egész drive-nak, nem lehet kinullázni, hekkelni, a gyártó sem tudja neked leoldani a titkosítást. Pontosan, ahogy írod, mehet a kukába. De ez téged véd, mert ha valaki megfújja a gépet, SSD-t, akkor hiába is próbálja elpasszolni, téglásítva lesz az egész SSD, se újraformázni, se semmit csinálni nem lehet vele. Jó, nagyon kevés kivétel van, mikor valami BIOS-os jelszavazási gyengeség (pl. üresen hagyja az admin jelszót, és az csak user ATA passwordot állítja, vagy az admin jelszót a gép sorozatszáma alapján generálja ismert algoritmussal, de ez ritka, gyártók kerülik).
A LUKS ezzel szemben törölhető, ha el is felejtetted a jelszót, csak az adatokat bukod róla, a drive bármikor leformázható. Meg a LUKS megbízhatóbb is, mivel opensource és auditált, így biztos lehetsz benne, hogy se NSA hátsó ajtó, se implementálási gyengeség nincs benne hagyva. Ha betartod a cryptsetupos ajánlásokat, akkor bombabiztos a LUKS, se az FBI, se a CIA ki nem nyitja a rohadt büdös életben, hacsak nem tudnak valahonnan szerválni egy qvantumszuperszámítógépet, ami bruteforce-szal belátható időn belül törni tudja.
-
attilav2
őstag
Asztali gépek/alaplapok BIOS-ai/UEFI-ei általában nem ismerik a SATA jelszó funkciót, az én lapom is ilyen sajnos
Másrészt ha elgépelem a jelszót első megadáskor akkor a meghajtót dobhatom a kukába(utána már nem lehet használhatóvá tenni, ha nem ismert a jelszó, míg szoftveres titkosításnál újra partícionálás formázás után használatba vehető), ezért félek a hardveres titkosítástól. -
Frawly
veterán
válasz
attilav2
#8036
üzenetére
A crypttabot azért nem tudom, mert ugyan használtam LUKS-ot már, de nem SSD-vel, hanem HDD-vel, és ott nem kellett TRIM-mel, discard-dal szórakozni.
Egyébként én még mindig amondó vagyok, ha SSD-id vannak, akkor az azokba beépített hardveres titkosítást használd. Neked is könnyebb, mert gép bekapcsolásakor a BIOS bekéri a meghajtók ATA jelszavát, onnantól kinyílik a titkosításuk, és a továbbiakban minden szoftver, OS, akármi úgy érzékeli, hogy titkosítatlan meghajtóra dolgoznak, közben meg titkosítás alatt van, de hardveresen, transzparensen.
-
attilav2
őstag
válasz
attilav2
#8029
üzenetére
Letitkosítottam a windowsos lemezeket is, windowsos rendszer ssd + exfat adattároló ssd, bitlockerrel. Az aur ban levő dislocker meg tudja nyitni a bitlockerrel titkosított lemezeket, itt van egy leírás a használatáról: https://www.ceos3c.com/open-source/open-bitlocker-drive-linux/
Frawly:
További beállításokat eszközöltem hogy a LUKS átengedje a TRIM-et, létrehoztam a /etc/crypttab.initramfs -t és beleírtam ezt: rd.luks.options=2e1434a6-a4ac-49bf-91a0-d4f7dd5d3619=discard (a titkosított lemez uuid-je szerepel benne) ahogy a wikiből kihalásztam így kell csinálni, bár lehet elég lett volna a rd.luks.options=discard, inkább biztosra mentem, utána újra generáltam az initramfs-t. fstab-ba bekerültek a discard,noatime opciók.
Nem reklamált a rendszer bootoláskor, persze tudom ez nem azt jelenti hogy működik trim, de akár működhet is
A wiki szerint, ha jól értelmezem. az /etc/crypttab -os bejegyzéseket az initramfs miatt nem veszi figyelembe bootoláskor a rendszer bootlemez esetén, illetve ez a fájl arra való hogyha a bootlemezen kívül van más titkosított lemez akkor azoknak az automatikus felcsatolását lehet benne defdiniálni a megfelelő opciókkal. -
Frawly
veterán
válasz
attilav2
#8031
üzenetére
Az Arch Wiki ajánlja még a rd.luks.options=discard kernelparamétert is, ahogy a screenshoton is látszik. Ezen túlmenően a crypttab-ba és az fstab-ba is kell a discard paraméter, ha az SSD-n lévő fájlrendszer támogatja, ha nem támogatja, akkor meg fstrim-et kell helyette ütemezni.
Egyébként az SSD-k nem szeretik a szoftveres titkosítást, mert az teleírja őket, és nem látják, hogy mi a hasznos adat, mi nem. Ezen a TRIM egy kicsit tompít, de az SSD-knek nem nagy barátja az egész lemezes szoftveres titkosítás.
Ezzel a linkeden azért nem foglalkoztak, mert ott NVMe SSD-t használtak, azon meg máshogy van megoldva a TRIM-nek megfelelő opció, hardveresen, így nem kell ezzel szórakozni.
Azért is támogat több SSD is hardveres öntitkosítást, közöttük a 860QVO is támogatja az AES-256-ot. De! Ehhez olyan alaplap kell, ami van TPM 2.0 chip, és a BIOS is támogatja az ATA jelszót. Az a baj, hogy a legtöbb konzumer gép nem támogatja, csak céges notik, céges desktop, thin client, workstation, server, stb.. Nem is értem, hogy a konzumer lapokról ezen mit spórolnak le, mert nem valami drága megoldás. Persze elméletben lehet úgy is használni, hogy az alaplap nem támogatja, hanem boot után te nyitod ki hdparm segítségével, de ilyenkor meg nem lehet róla bootolni. Csakis ATA, SATA, AHCI SSD-knél fontos ez..
-
attilav2
őstag
Így jó a LUKS discard vagy máshol is állítani kell valamit? Fstabba mehet a discard a opció?
a /boot/loader/entries/arch.conf -ban adtam meg az allow-discards paramétert ami a wikiben van, bebootolt a rendszer tehát nagy bajt nem csináltam. Jól adtam meg ezt az opciót?
A többi beállítással is foglalkozni kell, vagy ez így elég?
-
Frawly
veterán
válasz
attilav2
#8028
üzenetére
Persze, hogy működik. Ez egy teljesen sztenderd telepítés, annyi benne a csavar, hogy cryptsetup-pal letitkosította a második partíciót, és arra telepítette a rendszert. Illetve a systemd-boot menüjében hozzáadott egy extra sort: options cryptdevice=PARTUUID=bla-bla... Illetve, ha tudod így telepíteni, akkor ennél kell maradni, és hagyni a GRUB-ot.
Amire még figyelj, hogy ha SATA SSD-ről van szó, akkor a TRIM átengedéséről a LUKS rétegén gondoskodni kell. NVMe SSD-nél (amilyen a leírásban is van), meg HDD-nél nem kell ilyen.
Vim az hasznos, de nem kötelező azt használni konzolban sem. Bármit felrakhatsz magadnak, leginkább a micro nevű text editort ajánlom, de van helyette egy csomó másik: ne, e3, ee, nano, tilde, mcedit, emacs, uemacs, vagy amit akarsz. Van egy rakat, közülük egy csomó „hagyományosabb” a vim-nél. Régen a base csomag része volt a vi, de már nem az. De szerintem a vim a legjobb az összes közül, főleg, ha tud valaki gépírni. Illetve az Emacs is nagyon jó, de azt sem sokkal könnyebb megtanulni, mint a vim-et.
-
-
attilav2
őstag
Találtam egy jó leírást, egyszerű LUKS telepítés, systemd-boot -al:
https://jherrlin.github.io/posts/arch-install/
VirtualBoxban kipróbáltam, nekem működött!
Itt meg egy magyarázó videó, szintén alap LUKS telepítés, Grub boot -al:
https://www.youtube.com/watch?v=XNJ4oKla8B0
Ezt is megcsináltam vboxban, ez is működött.
Vim vágólapkezelés:
https://vim.fandom.com/wiki/Copy,_cut_and_paste
konzolban hasznos -
Frawly
veterán
válasz
Archttila
#8026
üzenetére
Lehet használni többfélét is, és akkor a pacman sorrendben végigpróbálja őket, ha nem elérhető az elsőként szereplő szerver, akkor próbálja tölteni a másodikról. A rollingnak ez hátránya, hogy gyakran frissül, sok csomag, és nagyon le kell követnie a mirrornak is a sok apró változást, ha egy-két csomag nem frissül, dőlhet a függőségi sor, mint a dominóknál. Ez egy lassabban frissülő, kiadás alapú disztrónál (Debian, Ubuntu, Red Hat vonala) nem olyan nagy gond, de elméletileg ott is előfordulhat.
-
Frawly
veterán
Én mondanám, hogy megmondtam, és mondom is. Talán nincs még 2 hete, hogy valaki az Linux OFF topikban jelezte, hogy gondja van a Void magyar mirrorjával. Erre írtam, hogy ez a baj a kicsi disztrókkal, nem sok mirror, de még nagy disztrónál, mint az Arch, ott sem mindegy, hogy mely mirrorokat használja az ember, és nem csak letöltési sebesség miatt, hanem a tier1 mirrorokhoz képest történő syncállapot miatt, amibe itt most ti is belefutottatok. Épp ezért nem csak pinget meg nyers letöltési sebességet kell nézni, hanem pl. készenléti időt (szerverkimaradás), sync-frissességet. A német szerverek általában jobbak ebben, mint a magyar. Az archlinux.org-on lévő mirrorösszeállítóval lehet nézelődni.
Egyébként nem is jártam messze a megoldástól az Syu-val, hogy nem volt teljesen lefrissülve, de ezek szerint nem user error, hanem mirror synclag miatt.
-
Sonja
nagyúr
Igen, ezért volt ez "nehéz" így hirtelen kideríteni. Én magam nem is gondoltam rá, hogy szervert cseréljek.
Egyébként pedig neked is köszönöm a segítséget (growler-nek szintén)! Szerk.: Azért írom, hogy "nehéz", mert én mindenféle kulcsos próbálkozást kipróbáltam, amit a google-vel találtam, de eredménytelen volt.
-
Sonja
nagyúr
Megtaláltam a megoldást az Arch fórumán! Méghozzá szintén magyar az illető, szóval talán olvassa ezt a topikot. Köszönöm neki!
-
Frawly
veterán
Gummiboot tudtommal már nincs. Az a systemd-boot régi neve volt. De nem tömi tele a partíciót. Ennek ellenére nem írtam, hogy nekem sem volt még gondom a GRUB-bal, mikor még használtam. Egyszer volt, hogy nem bootolt, de akkor balfék Win7 update-je írta felül, nem Linux oldalán volt a hiba. Én csak azért nem használom a GRUB-ot, mert 1) feleslegesen nagy, bloat valami, 2) nincs rá szükségem. De ahogy olvasom a fórumokat, nagyon sok embernek eltörik, és rendszeren jönnek kérdésekkel, hogy nem bootol. Systemd-bootnál ilyet még nem hallottam, az is igaz, hogy annál lehet azért nem, mert aki olyat használ, az ért hozzá, és jól rakja fel magának. Na, meg sokkal egyszerűbb is, csak egy szál .EFI fájl, meg két darab plain text .conf fájl, az egész egy pirinyó megoldás.
De elvileg az EFI stub boot még elegánsabb, ott semmilyen bootmanager nincs (az UEFI már önmagában is egy bootmanager), ott a kernel bootol közvetlenül EFI binárisként. Ennek viszont van 1-2 hátránya, néhány nem annyira szabványos alaplap UEFI-je nincs vele kibékülve, meg ha pl. hirtelen átszerkesztett paraméterekkel kell hívni a kernelt, akkor azt nem lehet egykönnyen kivitelezni.
GRUB csak akkor kell, ha valaki ZFS-ről, btrfs-ről, RAID-ről, egész lemezes szoftveres titkosításos megoldásról (esetleg LVM-ről), stb. akar bootolni. Akkor kell. De ezek nem az átlag felhasználói réteg, az simán titkosítatlan ext4 partíciókat használ, ahhoz nem kell. Még legacy BIOS bootnál sem, mert vannak nála soványabb, biztosabb megoldások, amik nem törnek el.
-
Frawly
veterán
válasz
Shyciii
#8009
üzenetére
A GRUB egy hulladék, az eltörik Ubuntun, Minten, meg mindenhol. Archnak előnye, hogy ott ki is kerülheted, ha nem teszed fel a GRUB-ot, akkor nem lesz mi eltörjön. Illetve, de, a rendszergazdának van erre ideje. Mert ez a munkája. Ha túl nehéz neki, elmegy szenet lapátolni, vagy munkanélkülinek.
Abban viszont egyetértek, hogy a Linux sem tökéletes. Az Arch sem. Ma már az OS-ek, böngészők kódbázisai olyan nagyok, hogy áttekinthetetlen kódméret, főleg, ha a csomagokat is hozzávesszük. Ráadásul egyre inkább rohannak a verziókkal. Nem csak a rolling, a Win10, fejlesztők, stb. is.
#8010 Sonja: nálam simán jó. Települ és működik az mc. Semmilyen PGP hiba nincs. Pedig semmilyen ilyen refresh-keys mókolást nem ejtettem meg.
Ilyenkor általában megéri egy pacman -Syu parancsot kiadni, mert az, ha van új keyring csomag, akkor azt is befrissíti, és utána menni fog az mc.
-
Sonja
nagyúr
-
hmmm
ezt nézted már? -
-
Sonja
nagyúr
Frissítettem a rendszerem, de leállt egy hibával. A Midnight Commander (mc) PGP aláírása sérült vagy érvénytelen hibával állt meg. Oké, leszedtem az mc-t, majd frissítettem a rendszert. Mondom megnézem, hogy felteszem az mc-t, de a hiba ugyan az maradt! Ilyenkor mit lehet tenni?
Itt a pontos hiba. -
Shyciii
veterán
Hát nekem volt, hogy a grub-ot újra kellett építenem frissítés után, mert elpukkant. Ablakkezelő is pukkant meg. Ezek egy olyan szakmában nem férnek bele, ahol egy fél órás leállás komoly pénzbe kerülhet. Ezért van az, hogy nem az oprendszer a megoldás, hanem más rendelkezésreállási megoldás. Előző melóhelyemen is így volt, és a mostanin nem is. Legtöbbször nincs idő arra, hogy a rendszergazda megnézze mi a gond, hegesztgesse. Lehetőleg azonnal dolgoznia kell tovább. És mivel a Linux sem tökéletes rendszer, így nem az a megoldás.
-
attilav2
őstag
válasz
Shyciii
#8005
üzenetére
Nekem még nem volt olyan hogy frissítés után ne bootolt volna be, igaz nem is nvidiát használok aminek csak zárt drivere van, az egy kernelfrissüléskor lehet megfagy bootkor, szerencsére amd vga-m van. Olyan már párszor volt hogy a KDE-t úgy hazavágta egy update hogy nem indult, de akkor használtam másik desktopot. Tv tuneremhez dkms-es drivert használok, volt hogy kernelfrissüléskor nem fordult le, de attól még bebootolt a rendszer, csak a tuner nem működött, néhány hét múlva javították a driverét, nem létfontosságú mert tv-m is van.
-
Frawly
veterán
válasz
Shyciii
#8005
üzenetére
Nekem még sose volt olyan, hogy egy Arch ne bootolt volna frissítés miatt. Soha!!! Volt, hogy frissítés tört el ugyan dolgokat, nagyon ritkán (kb 2 évente egyszer) 1-1 progi crachelt, meg produkált olyan bugot, amit workarounddal, csomag downgrade-del, stb. kellett megoldani (ilyenkor is megoldható pár perc alatt), de olyan sose fordult elő, hogy az egész rendszer enblock bootképtelen lett volna, meg rendszer nélkül maradtam volna akármikor is. Az is igaz, hogy nálam ez még Windowszal sem fordult elő, csak hogy 1-1 nem tetsző driver kékhalált okozott, de ilyenkor is elég volt egy csökkentett módú újraindítás, és a driver eltávolítása, vagy eszköz letiltása.
És itt azt kell érteni, hogy nem csak az Archot védem, meg istenítem, hanem igazából ez bármilyen disztróra igaz. Még talán BSD-kre is, ha a cég megtanulja magának megoldani, talál hozzá szakembert, akkor szinte bármilyen elterjedtebb modern OS-es ökoszisztémán el lehet lenni, annak bármelyik disztribúciójával.
-
Frawly
veterán
válasz
attilav2
#8003
üzenetére
Teljesen jó termelésirányításban, meg akármire is. Ezt már többször is írtam, hogy céges felhasználásra csak LTS az igaz volt régen, de már jó pár éve nem az.
Igazából a rollingságát is lehet tompítani az Archnak. Pl. nem frissíted olyan gyakran, meg helyi tárolót hozol létre, ahova csak olyan csomagot engedsz be, amit egy tesztgépen már teszteltél, a többi gép meg már csak ezeket húzhatja le. Ja, külön munka, de ha az egész cég archos ökosisztéma, csomó géppel, akkor simán megéri.
Inkább csak annyi, hogy általános ipari és céges felhasználásnál szerintem elveszik az Arch előnye, de hátránya se nagyon van. Igazából ízlés kérdése, hogy ki mit ismer, miben bízik, stb.. A legtöbb helyen nem azért van Red Hat alapú disztró, meg Ubuntu LTS, meg Debian, mert azok a legstabilabbak, hanem a legtöbb IT szakember azokat ismeri, így azokat vállalja be. Sokan csak egy Archot azért nem piszkálnának meg bottal sem, mert nem ismerik, nem szokták még meg, és úgy vannak vele, hogy éles környezetben nem fognak elkezdeni tanulgatni. De ez nem jelenti azt, hogy éles környezetben ne lenne bevethető.
Félig a lustaság is benne van. Az informatikus nem szeret dolgozni, minek frissítgessen állandóan Archot, ha egyszer egy CentOS-nél meg elmegy, hogy évente egyszer frissíti, és 10 évig nem kell komolyabban hozzányúlnia. Az LTS meg a miegymás ezt a lustaságot is kiszolgálja. Szintén a lustaságot van hivatva segíteni, hogy a nagy céges corporate disztrókra supportot is tudsz venni, ami ugye nem szükséges, de sok cégnél kényelmes, hogy ha gond van valamivel, akkor nem neked kell megcsinálni, hanem lehet a megoldásért más hátát verni, meg mindig mástól várni a megoldást.
Sőt, tovább megyek, a legtöbb helyen azért van Windows onlyság is, mert azt biztosan ismerik, van vele belső tapasztalat, ahhoz mindig találni szakembert is, mert Dunát lehet velük rekeszteni, van hozzá support. Nem azért használják, mert stabilabb meg jobb lenne.
-
Shyciii
veterán
válasz
attilav2
#8003
üzenetére
Én is jópár éve használok Arch-ot, és volt hogy a frissítés után nem tudott bebootolni. 2-3 ilyen alkalom volt, míg Windows 10-es munkaállomások a melóhelyemen egyszer sem haltak meg. De ettől függetlenül nem az a gond, hogy valaki Windows-t használ, és összeomlik, és akkor kész vége. A jobb melóhelyeken, vagy nagyobb cégeknél, vagy akár kisebbeknél is ha jó rendszergazdájuk van, akkor ott kezdődik, hogy minimum van 2-3 gép tartalékban, felinstallálva+programok, és csak a user-t kell létrehozni, meg mondjuk microsoft365-be bejelentkezni, és kész. Persze ehhez kell egy olyan felfogás is, hogy lokálisan semmit nem tárolunk. Arra ott van a file szerver, vagy ha pl MS gold partner, akkor szinte biztos hogy OneDrive is van használatban. Innentől kezdve semmi extra egy új tartalék gépet üzembehelyezni. Gyorsabb, mint hogy helyrehozd a Windowst, vagy Linuxot. A még komolyabb MS technológiát használó cégek meg akár roaming profile-t is használhatnak pluszban, ami aztán végképp fullosan visszahozza még a profile adatait is, hogy milyen ikon és hol vannak az asztalon. Szal egy cégnél, főleg termelésirányítást is végző cégnél, ami kritikus munka minimális leállásal, ott nem az oprendszer számít, hanem a rendszer egészének működése.
-
válasz
attilav2
#8003
üzenetére
évek óta kizárólag Arch fut a saját munkaállomásomon, bár nyilván ha valami nyűgöm volna, azt magamnak könnyen tudom orvosolni.
ennek ellenére nem nagyon volt bajom, sima irodai munkára bátran merném ajánlani.
termelésirányítónak, stb... ha az adott szoftver fut Linuxon, akkor nem érzem hogy bármivel nagyobb kockázat vagy probléma lenne, mint a Windows, sőt... -
attilav2
őstag
El tudnátok e képzelni az Arch-ot produktív munkában ? Pl Termelésirányításban egy gyárban az üzemvezetők ilyen rendszeren dolgoznának win10 helyett? Szerintem kijelenthető hogy a Win10 frissítési folyamata ma már több leállási kockázattal jár mint az Arch-é. Én jópár éve használom az Arch-ot, pár évet használtam újra telepítés nélkül is, folyamatos frissítéssel, bátran ki merem jelenteni hogy a w10 frissítési folyamata megbízhatatlanabb és jóval lassabb is. Csak a KDE-vel volt gondom az évek során, magával a rendszerrel nem, de produktív környezetbe lehet nyilván más akár pehelysúlyú megbízhatóbb desktopot választani. Ami aggasztóbb és akadálya a váltásnak hogy sok vállalatirányítási szoftver nem érhető el linux alá. Meg egyáltalán kérdéses hogy a válallatirányítási rendszerek szállítói mernének e garanciát vállalni a hosszútávú működésre egy rolling disztribúció alatt?
Egy jelentős érv a váltás mellett lehetne a vírusokkal szembeni immunitás, hiszen a vírusok jelentős többsége windows platformra készül.
Az Arch abszolút párhuzamba állítható a Win10-el, hiszen mindkettő rolling.
Nektek mi a véleményetek az Arch produktív környezetben való munkaállomáskénti használatáról? -
Frawly
veterán
válasz
attilav2
#8001
üzenetére
Az efistub nagy királyság, annak a lényege, hogy a kernel közvetlenül .EFI binárisként bootol, nincs semmilyen bootmaganer (az UEFI egymagában is egy bootmanager). De az efistub-ot nem támogatja sok nem szabványos gyártói UEFI, meg ha initramfs, titkosítás, stb. van, akkor vagy nehézkes lehet, vagy lehetetlen.
Én systemd nélküli disztrókon lehetőleg efistub bootot használok, systemd-s disztrókon systemd-bootot, mert az is még kellően egyszerű. GRUB-ot csak akkor tennék fel, ha valami RAID-ről, egzotikus partíciótípusról, spéci titkosítós mókáról kell bootolni, vagy MBR Legacy bootkor (bár akkor is hajlanék valami egyszerűbb bootmanager felé).
-
attilav2
őstag
válasz
Shyciii
#8000
üzenetére
Ebben a leírásban külön van az efi és a boot partíció, én jobban szeretem ha egybe van. A youtubeon vannak LUKS Arch telepítési videók, de többnyire Grub-osak, nem tudom miért ragaszkodnak annyira a Grub-hoz, mikor a systemd-boot sokkal egyszerűbb, mondjuk systemd mentes rendszeren érthető, de itt Arch LUKS telepítési videókról van szó, nem az Arch egy systemd mentes forkjáról ahol érthető ha Grub-ot használnak. Artixon én is Grub-ot használok, efistub meg hasonló csak uefi nvram-ba író megoldások jöhetnének még szóba Grub helyett, de ha átrakom a lemezt egy másik gépbe akkor már nem bootolna mert a másik gép uefi-jében értelemszerűen nincs ott a bejegyzés.
Egyelőre a jövő zenéje lesz a titkosított ökoszisztéma, mert csak akkor van értelme ha minden adatomat letitkosítom, a külső lemezeken levőket is, a külső lemezeket valószínűleg bitlockerrel oldom majd meg, hogy win alatt is használhatóak legyenek. Linux alá van bitlocker megnyitó tool, csak nem tudom mennyire stabil.
![;]](http://cdn.rios.hu/dl/s/v1.gif)
illetve az alapinstall (így hogy már rendesen működik a gyári) felesleges meló, de a post-tot jó lenne majd valamikor összekalapálni. 
:
Munka, gyerek, munka, gyerek mu...
Se digivel se vodás mobilnettel nem tölt be az oldal 
Soha nem csináltam UEFI telepítést, azt se tudom, hogy kell, és milyen partíciókat létrehozni. 
A wiki szerint, ha jól értelmezem. az /etc/crypttab -os bejegyzéseket az initramfs miatt nem veszi figyelembe bootoláskor a rendszer bootlemez esetén, illetve ez a fájl arra való hogyha a bootlemezen kívül van más titkosított lemez akkor azoknak az automatikus felcsatolását lehet benne defdiniálni a megfelelő opciókkal.
Új hozzászólás Aktív témák
Hirdetés
BoB
- Samsung Galaxy A12 64GB, Kártyafüggetlen, 1 Év Garanciával
- LG 27UL550-W - 27" IPS / 3840x2160 4K / 60Hz 5ms / HDR10 / AMD FreeSync
- Samsung ME46B 46" LED Monitor
- BESZÁMÍTÁS! Gigabyte H610M i5 13400F 16GB DDR4 512GB SSD RX 6700XT 12GB DeepCool MATREXX 40 650W
- 1-12 részletre.Új noblechairs EPIC műbőr FEKETE - FEKETE. 2 év garancia!
Állásajánlatok
Cég: PC Trade Systems Kft.
Város: Szeged
Cég: CAMERA-PRO Hungary Kft
Város: Budapest