-
Mobilarena
Arch Linux topik
Új hozzászólás Aktív témák
-
#9031
IstvánLászló
őstag
vargalex
#9028
IstvánLászló
őstag
válasz
vargalex
#9028
üzenetére
+1 igen maximálisan eggyetértek amit mondasz,dettó én is azt szertem hogy gépemen az rendszerem azt csinálja amire nekem szűkségem van.
cibus nak
Ó mik a felesleges cuccok,mindenkinek más más és pláne van lehetőség 0-áról építeni a tetszésünk szerint alakitan és testre is szabn sajáti igényeink szerint a rendszert....
-
cibus
senior tag
válasz
vargalex
#9028
üzenetére
Tudja hogy mik a felesleges cuccok amik lassítják, azt miért ne gyomlálhatná ki? Plusz az első bejelentkezéskor van egy programválasztó , csak be kell pipálni mit akarsz hogy települjön, és automatán csinál mindent. ez volt számomra a legnagyobb érv, nem lesz tele szeméttel, plusz attól hogy ők így bekonfigurálták előre, attól még utólag minden változtatható saját ízlése és utána egy rém egyszerű backuppal el lehet menteni mindent egy későbbi visszaállításra, telepítésre. Szerintem zseni, főleg kezdőként. És nagyon nagyon gyors rendszer.
Persze lehet van akinek ez nagyon nem tetszik, de szerencsére nem kötelező ezt a rendszert használni
-
Sz_Imre
senior tag
válasz
vargalex
#9022
üzenetére
Nem az a honlapja.
Ezt Ravepriest1 (és társai által létrehozott közösségi arch linux disztribúció, azaz RaveOS)
Gnome asztali felületet használ.#9023 BoB: Mert nem az a weboldala, hanem amit linkeltem vargalex-nek)
További információ róla. -
-
attilav2
őstag
válasz
vargalex
#8819
üzenetére
Lehetséges.
Egyébként a viszonylag gyakori link up/down az a mediatek switch hülyesége miatt is lehet, ezt már az AC57U-nál is megfigyeltem(normál üzemben mindig 1gb/s-re áll vissza a link), mert amikor az archer c7v5(atheros SoC, atheros switch) volt itthon egy rövid ideig használva(a gyenge wifi és gyenge SoC miatt nem vált be), akkor nem volt tele vezetékes háló fel/le csatlakozással az openwrt log.
Ezért is érdekelne a qualcomm-os dynalink, jó lenne ha 2 hétig tesztelhetném Persze csak úgy add kölcsön hogy már openwrt-sítve van. Ha kölcsön akarod adni, akkor ne futárral küldd le, nehogy elvesszen(ahhoz drága), ha pesten járunk valamikor lehet át tudom venni, vagy öcsém lehozza nekem(ha gyál-ig el tudod vinni). -
attilav2
őstag
válasz
vargalex
#8815
üzenetére
Érdekes, a dhpcd.conf volt statikusra(192.168.0.66-ra azthiszem) állítva mert az archer c7v5-öt flasheltem át openwrt-re tftp-n. Most működik az ipv4 h visszaálítottam dhcp-re. Próbálkoztam networkmanagerrel, leállítottam és kikapcsoltam a dhcpcd-t, de továbbra is fennált az ipv4 probléma mialatt a networkmanager ment. Érdekes hogy a dhcpcd-ben beállított statikus ip okozhat linksebesség anomáliát, meg check cabling üzenetet a dmesg-ben.
Ez a zárt r8168 driver stabilabbnak tűnik ami a linksebességet, link stabilitást illeti. A r8169-el gyakran volt link up/down, a gyári r8168 stabilan tartja a link-et.
-
attilav2
őstag
válasz
vargalex
#8815
üzenetére
Merre vagy helyileg? Szívesen kipróbálnám azt az USB-s NIC-et...
Ha már a felajánlásoknál tartunk szívesen kipróbálnám a Dynalink-DLWRX36-ot, mivel autista vagyok, nem merek külföldről rendelni(pláne ilyen nagy értékben), angolul alig tudok, a vámeljárástól is félek. A Dynalinkre viszont kíváncsi vagyok abból a szempontból hogy anyám Unisoc Tiger T618-as Galaxy Tab A8-asával szakadozna e a wifi, mert az AC57U-val szakadozott, és AX3200-al is szakadozik(mindkettő mediatek-es). Hátha qualcomm-os ap-val nem kapcsolódna le a wifiről. Megmutattam neki hogy kapcsolódhat újra, de akkoris macera. Meg arra is kíváncsi vagyok hogy a torrentet hány megabájt/s-al töltené a dynalink, az AC57U(amit ap módban seedelni használok hogy ne kelljen járatni egy pc-t) 5-10megabájt/s-al tölt le. -
attilav2
őstag
válasz
vargalex
#8815
üzenetére
Akkor nem marad más mint az arch újratelepítése 0-ról, vagy debian. Szegedi vagyok, te meg a fővárosi vagy ha jól tudom.
Valamelyik csomag elk*rta a hálózati beállításokat, fogalamam nincs merre keressem a hibát. Valószínűleg valami a nic firmware-t fekteti meg arch alatt(mert ha újraindítással megyek más rendszerre akkor hasonló hibák jönnek, kikapcs/bekapcs-os reboot-kor teljesen jó más rendszerek alatt a nic), tippem sincs mi lehet. -
attilav2
őstag
válasz
vargalex
#8813
üzenetére
Azthiszem feladom, próbálkoztam a hivatalos (realtek) oldalról letölthető driverrel(r8168-8.052.01.tar.bz2, az arch féle r8169-et blacklistre tettem), ipv4 továbbra sem megy, pl prohardvert az ip begépelésével sem érem el, megpingetni sem tudom(hálózat elérhetetlen). Az 1Gbit-es linksebességet viszont úgy tűnik stabilan tartja. Csak ipv6-os oldalak jönnek be. MacOS, Windows alatt normálisan megy az integrált nic. Van axagon ade-src usb-s nic-em, de azzal is hasonló tapasztalatom van arch alatt, mivel az is realtek chipes... Lehet rendelni kéne valahonnan egy asix chipes usb-s nic-et, de magyarországon ilyet nem forgalmaznak tudomásom szerint, max aliról lehetne rendelni, de külföldről nem merek, macera a vámeljárás, angolul sem tudok annyira jól, ha valami gond lenne a rendeléssel/szállítással h reklamáljak. Rakok debiant arch helyett.
-
jimmy399
senior tag
válasz
vargalex
#8754
üzenetére
Nekem sem volt dedikált VGA-m csak egy inetgrált volt amikor átálltam Debianra. Amúgy a nagyon friss és ropogós szoftverekből amiket az Arch ad, kb semmit se veszek észre hogy kevesebb lenne egy Debian, mégha régebbi is minden benne természetesen átlag használat mellett. Bár, most, hogy Debian 12-re váltottam kissé bugzik az xfce4-ben a panel, hogy hiába van automatikus elrejtésben nem tűnik el...
-
Blasius
tag
válasz
vargalex
#8746
üzenetére
Szia,
Hidegen is csinálja, 36 fokon is előjött. 1080 soros YouTube nézés közben fel szokott menni a hőmérséklet kb 50 fokig. Az egyik stressz tesztet (amelyikben a Zeppelin van) a linkről próbáltam, ott felment 55 fokig is, és minden ok volt.
A videókártya nem éppen egy mai darab, akár valami hibája is lehet. Vagy valami miatt nem kompatibilis az alaplappal. Tekergetem majd a bios pci-e beállításokat és hátha belebotlok valamibe. Windowsom nincs ezen a gépen, azt nem tudom kipróbálni. -
-
Shyciii
veterán
válasz
vargalex
#8604
üzenetére
No ez nagyon dícséretes, de ne magadból indulj ki, hanem egy átlag userból. Még aki linuxot használ otthon, azok nagy %-a azt sem tudja, hogy mi az hogy openwrt. Felrakta az ubuntut, mert azt sokan dícsérik, és hasonló a windowshoz, oszt annyi. A Winesek meg pláne nem tudják mi az. Szal ők a boldog tudatlanok, hogy védve vannak, oszt csókolom.
Jópofa az nftable wikije. Én itt néztem: Link
ott meg 3 féle értéket mutat
Viszont attól függően hogy ki mire használja a home serverét, nem túl szerencsés minden forgalomra egységes limit rate-et beállítani, különben lehetnek meglepetések. Rendes szerveren meg kifejezetten hibás dolog (én pl megszívnám, ha így tennék a szervereinken)
Gyanítom ezért van az, hogy Debian (minimal) alatt az alap beállításban semmi nincs. Az összes policy accept, oszt csókolom. Arch-ot meg nemigen használnak szervernek, így gondolom úgy veszik, hogy a user kevésbé képzett, legyen neki valami. -
Shyciii
veterán
válasz
vargalex
#8602
üzenetére
Most otthoni felhasználásról beszélünk ha jól sejtem. Az otthoni routerek 95%-ának a szoftvere mint egy ementáli sajt, ha a gyári firmware van rajta, és elvétve frissítik (kétlem hogy sokan OpenWRT-t raknak fel a gyári helyett mezei usereknél), és a feldolgozási sebessége is egyenlő a nullával. Legtöbbjük fele olyan gyors sincs, mint a mögötte levő számítógép. Szal én ezekben a home routerekben sosem bíztam, ha biztonságról van szó, és mást se bátorítok arra, hogy most akkor minden rendben van, mert router mögött van. Egyébként évente szoktak csinálni felmérést a home routerekről elég nagy mintavételezéssel, és katasztrófális a helyzet a biztonságuk terén.
pkttype host limit rate 5/secondősszintén szólva passz. A pkttype -nek (packet) három értéke van: broadcast, unicast, multicast. Szal a host nem tom hogyan jön ki, és nem is találok utalást a reference-ben sem.
Ráadásul utána ez van: reject with icmpx type admin-prohibited
counter
Ezt sem értem, hogy miért icmp admin-prohibited típussal utasítjuk vissza? Egyáltalán miért pazarlunk erőforrást arra, hogy aki épp floodol minket, és rossz esetben alig tudjuk feldolgozni, még külön küldözgetünk neki vissza ilyet és ezzel még mi is terheljük a saját gépünket/szerverünket? Miért nem dobjuk el simán?
Arról nem is beszélve, hogy ez a szabály sima filter inputként van, vagyis a leglassabb feldolgozással bír. Az ilyet én ingress hookba raknám netdev alá. Ez már olyan alacsony szinten van, hogy jóval gyorsabb a feldolgozási sebessége, mint a filter inputé. -
Archttila
veterán
válasz
vargalex
#8583
üzenetére
Szerintem a tmpfs vicceli meg:Megneztem, nem!## tmpfstmpfs /tmp tmpfs rw,noatime,nodev,nosuid,mode=1777 0 0tmpfs /var/tmp tmpfs rw,noatime,nodev,nosuid,noexec,mode=1777 0 0tmpfs /var/log tmpfs rw,noatime,nodev,nosuid,noexec,mode=0755 0 0tmpfs /var/cache/pacman/pkg tmpfs rw,noatime,nodev,nosuid,noexec,mode=0755 0 0 -
Archttila
veterán
válasz
vargalex
#8560
üzenetére
Újraindítottam de:
[alucard@arch ~]$ sctl.status systemd-sysctl.serviceOct 13 13:38:17 arch systemd[1]: Starting Apply Kernel Variables...Oct 13 13:38:17 arch systemd-sysctl[2919]: Couldn't write '1' to 'net/ipv6/conf/all/disable_ipv6', ignoring: No such file or directoryOct 13 13:38:17 arch systemd-sysctl[2919]: Couldn't write '1' to 'net/ipv6/conf/enp1s0/disable_ipv6', ignoring: No such file or directoryOct 13 13:38:17 arch systemd[1]: Finished Apply Kernel Variables.Pedig létezik a file:
[alucard@arch ~]$ cat /etc/sysctl.d/40-ipv6.conf## Disable IPv6net.ipv6.conf.all.disable_ipv6 = 1net.ipv6.conf.enp1s0.disable_ipv6 = 1 -
#68216320
törölt tag
válasz
vargalex
#8416
üzenetére
A "/etc/default/grub" fájban nem találok erre vonatkozó részt.
Hol lehetne átírni? Közvetlenül a /boot/grub.cfg-ben nem szeretném, mert egy esetleges grub generálásnál újra átírja majd.
Valami olyan helyen volna ideális a "vmlinuz-linux-zen" és "initramfs-linux-zen.img" fájlokat megadni, ahol "grub-mkconfig" már azzal hozza létre a grub.cfg-t.Jelenleg így rakom fel a grub-ot:
grub-install --target=x86_64-efi --bootloader-id="Arch Linux" --efi-directory=/boot --recheckgrub-mkconfig -o /boot/grub/grub.cfgNem lehetne itt valahogy megadni a linux-zen-t?
-
#68216320
törölt tag
válasz
vargalex
#8388
üzenetére
Igazad lehet. Viszont fura, hogy most nem wayland indult el. Mindenképp xorg van, ami nem gond és így működik az xrandr.
Már csak ott akadok el, hogy hol tudnám automatikusan kiadni ezt a parancsot minden login alkalmával, hogy beállítsa a gamma értéket.
Próbáltam ~/.xinitrc fájlban, de nem csinálta meg. -
#68216320
törölt tag
válasz
vargalex
#8386
üzenetére
Köszönöm. Nálam nem hozza ezt valamiért, csak Gnome, Gnome-Classic és a Kodi van.
Viszont a /etc/gdm/custom.conf tartalmazott kikommentelve egy ilyet:
WaylandEnable=false
Ezzel már az öreg xorg van használatban és működik is az xrandr gamma állítása.
Vajon nálam miért nem jelent meg a lehetőségek között az x-org? -
kzs
tag
válasz
vargalex
#8335
üzenetére
Ez jo ötlet (csak nem tudtam, milyen opciokkal a journalctl -ban).
4 sorban mutat figyelmeztetést:
Mar 07 14:47:38 homelinux NetworkManager[568]: <warn> [1646660858.3753] vpn[0x5-------------,xxxxxxxx-c98c-4001-89c3-xxx,"kapcsolatnév",if:19,dev:2:(kapcsolatnév)]: did not receive valid IP config informationMar 07 14:47:38 homelinux NetworkManager[568]: <warn> [1646660858.3752] vpn[0x5------------,xxxxxxxx-c98c-4001-89c3-xxx,"kapcsolatnév",if:19,dev:2:(kapcsolatnév)]: config: no VPN gateway address receivedMar 07 14:47:38 homelinux nm-wireguard-se[115568]: g_variant_builder_add_value: assertion '!GVSB(builder)->expected_type || g_variant_is_of_type (value, GVSB(builder)->expected_type)' failedMar 07 14:47:38 homelinux nm-wireguard-se[115568]: g_variant_new_string: assertion 'g_utf8_validate (string, -1, NULL)' failedValamivel okosabbak vagyok, de még nem sokkal.
"no VPN gateway address received" ill. "did not receive valid IP configuation": nem értem, be van állitva a remote endpoint, és korabban ugyanezekkel müködött + wg-quick müködik
A masik 2 sort "g_variant ... / GSVB ... failed": ezt egyszerüen nem tudom, micsoda.Ha esetleg van tipped?
Amugy tovabb keresgélek. -
csixy
addikt
válasz
vargalex
#8195
üzenetére
Köszönöm Lenry és vargalex !
A megoldás az lett, hogy blacklist-re tettem az újabb kernelek x@r rtw88_8821ce támogatását ... Tehát létrehoztam a /etc/modprobe.d/blacklist.conf állományt ezzel a tartalommal: blacklist rtw88_8821ce ... és visszatelepítettem az rtl8821ce-dkms-git-et és újraindítottam a gépezetet. Pöpecz lett!
-
csixy
addikt
válasz
vargalex
#8195
üzenetére
Leszedtem a dkms-t. Az LTS kernel nem látja a kártyát és szerencsére így az öreg tp-link kártya működik és nem fagy ki a rendszer. Az aktuális linux kernellel elindul a wifi, de nem sokkal utána lefagy a rendszer és ugyanez van a ZEN kernellel is. A
options rtl8821ce msi=1bejegyzéssel is és ha kikommentelem, akkor is lehal. A manjaro telepítést már leszedtem.Más: Az mi célt szolgál, hogy a modprobe (uefi esetében) nem hajlandó felderítgeni a többi partíciókra telepített rendszereket?
-
jimmy399
senior tag
válasz
vargalex
#8168
üzenetére
A journal-ok megvannak de nem tudom már pontosan mikor volt ez a fagyás, ha jól emlékszem, akkor a kernelbéli radeon driver okozta a bug-ot.
A wikiben minden létező kernelparamétert meg mindent megadtam, túrtram a netet, de semmi eredmény.
Amikor fagyás volt, visszaálltam a legutolsó jó kernelre és úgy ment tovább. Viszont volt vele szívás, mert a kernel-headers is kellett mert van pár program aminek külön forgatni kell modult (virtualbox pl) a dkms-el.
Nem tudom hogyan lehetne gyorsan megkeresni a sok-sok log közzül, mert már áttértem Debian vonalra, nincs szükségem további meglepetésekre a gördülő frissítések miatt.
Sokáig használtam Arch-ot (kb 5-6 év), de mostanság nagyon sok bug és inkompatibilitás jelent meg, ami korábban nem fordult elő, pedig nem egy nagyon új hardvert használok. -
jimmy399
senior tag
válasz
vargalex
#8163
üzenetére
Az integráltan van egy 19 inch-es és van egy külön dedikált is a hd 5550 amin szintén van egy 19 inches monitor.
Teljesen kifagyott a gép mert nem reagált a billentyűzetre, még a num lock se működött, viszont ssh-n keresztül még be lehetett lépni rá de újraindítani nem lehetett ott sem. Csak a reset segített.attilam: lts kernellel is ugyan az a helyzet.
-
Frawly
veterán
válasz
vargalex
#7844
üzenetére
Igen, egyetértek, a Waylandet nem szabad erőltetni. A böngészők kiválóan elmennek XWayland X.org emulációval, jó, nem ideális, de működőképes, nem fagy, nem crashel, stabil. Ez a Wayland-támogatás még minden böngészőn gyerekcipőben jár, ahogy a hardveres videókódolás is. Semmi baj nincs az XWaylanddel, egy csomó alkalmazás X-es, azokhoz úgy is fel kell tenni, pl. Wine, Steam, médialejátszók, meg még egy rakat népszerű program. Még egy jó évtizedig nem jön el az a pont, mikor minden normálisan támogat natívan Waylandet, ami jó lenne, mert amúgy jó cucc nagyon, csak még korai adoptáció szakaszában van. Kevés progi támogatja natívan, kevés WM/DE érthető el rá. Már használható állapotban van napi szinten, csak túlerőltetni nem kell.
-
Frawly
veterán
válasz
vargalex
#7760
üzenetére
Video accceleration nincs, de OpenGL vagy WebGL renderelésnek kellene lennie, és nála az sincs. Ami baj, mert így minden kirajzolandó elemet a proci számol, hangsúlyozom nem videóról van szó, hanem mindenféle weboldalelemről, kép, font, átlátszóság, stb.. Az is lehet, hogy a Chromiumnak nem tetszik a RPi4 GPU drivere, vagy csak az a része, amit a Wayland hajt.
A video acceleration az más, akkor a GPU nem a kirajzolást gyorsítja, hanem a videókodeket dekódolja ki (vagy encode-olja), hogy ne a procinak kelljen.
-
Archttila
veterán
-
Frawly
veterán
válasz
vargalex
#7755
üzenetére
Oké, akkor elsiklottam felette. De örülök, hogy ennyire képben vannak, mert ez sok embernek okoz gondot, nem csak Archon, hanem mindenféle Linuxon, Deb/Ubuntu és Red Hat/Fedora vonalán is. Sok ember csak emiatt írja le az UEFI bootot, pedig nem is azt tehet róla, hanem a gyártó idiotizmusa. Sőt, még ennél is rosszabb, mert aki teljesen kezdő, és az az első tapasztalata a Linuxszal, hogy mindjárt az első telepítés után nem bootol neki, az meg nem azt fogja levonni tanulságnak, hogy a gyártó tehet róla, meg az UEFI boot, hanem azt hiszi, hogy a Linux ×4r, és pattintja is vissza a Win10-et. Amiben az az irónia, hogy az egész szenvedést a MS okozta karöltve a gyártóval, és visszamenekül azok karjaiba, holott pont ezt akarták elérni.
-
-
#63718632
törölt tag
válasz
vargalex
#7677
üzenetére
@Frawly
Értetlenségem oka ez lehet:[Arch Linux][~]$ iduid=1000(arcsi) gid=985(users) csoportok=985(users),98(power),108(vboxusers),986(video),991(lp),995(audio),998(wheel),999(adm)[Arch Linux][~]$ groupspower vboxusers users video lp audio wheel adm[Arch Linux][~]$
Tiszta Arch-on most nem tudom megnézni, mert töröltem a vgépet.
Viszont ezt a szisztémát az összes "barátságos" Arch rendszernél tapasztaltam.
Az elsőnek létrehozott felhasználó az, akit a telepítőben megadsz.Az is érdekes, hogy az Arch Wiki a users csoportot most a használaton kívűli csoportnak mondja a power csoporttal együtt.
-
Frawly
veterán
válasz
vargalex
#7672
üzenetére
Igen, nálam is így hozza létre az useradd -m parancs, amit mindig az Arch Wiki alapján csinálok. Az megint más, hogy én utána usermod-dal berakom a felhasználóm a video, storage, disk, audio, wheel csoportba is, néhány szoftvernek meg a sudo-nak szüksége van ezekre. De ez sem úgy történik, hogy így hozódik létre telepítéskor, hanem én futtatom tudatosan ezeket a user/group parancsokat, semmilyen automata installer nem dönti el ezt helyettem. Ez a jó az Archban, csak a systemd és az initramfs van eldöntve az ember helyett, minden mást saját maga állíthat, telepíthet.
Engem egyébként nem érdekelne, hogy a userem tagja-e a userem nevű csoportnak, vagy csak a users-nek. Teljesen mindegy. Ha annyira zavar valakit, később egy darab usermod paranccsal át tudja ezt szabni magának, csak akkor lehet a fájlrendszeren a user fájljainál át kell szabni a csoportjogosulságokat is chmod-dal.
Egyébként míg nem lesz jó a Gentoo-m, addig feldobok egy Archot az Artix helyére. Oka: Artixon nem tudtam megoldani a lassú mirrorokat, és a rendszer idle memóriafogyasztása elszállt 300 MB-ra, ami nálam sok. Archon 140-170 körül tartottam, pedig ott systemd is van.
-
Frawly
veterán
válasz
vargalex
#7667
üzenetére
Igen, ezt megerősítem, ha valaki az Arch Wiki user and groups cikkét követi, akkor ott a legelején említett useradd -m blabla sor felhasználónév felhasználót default a felhasználónév csoportba létrehozva teszi be, Archon és Artixon is. Bár nem is értem mit kever a kolléga, ez neki miért fontos, mert ha nincs is saját csoportban, akkor is épp úgy kéne működjön minden. Szerintem valami kókler install scripttel telepítette, vagy rosszul másolt ki valami parancsot.
Egyébként meg úgy kell felhasználót hozzáadni, ahogy Chuck Norris csinálja, systemd-homed-vel, akkor a gid/uid lesz a legkisebb probléma
-
#63718632
törölt tag
válasz
vargalex
#7667
üzenetére
Telepítéskor az első létrehozott user-re gondoltam. Eddig ahány ahányféle telepítésem volt, abban mindben users volt a groups kimenetben, de saját nevű csoport nem.
Második felhasználó hozzáadásakor, mint ahogy említetted. Valóban létrejön a saját csoportja, másban nincs is benne.
Ezért is vágtam rá gyorsan az első hozzászólásban, mert nekem is furcsa volt deb rendszerek után. -
-
csixy
addikt
válasz
vargalex
#7656
üzenetére
Köszönöm. Ha legközelebb ilyesmire lesz szükségem utána fogok keresni linux vonalon. Csak a neten mindig a windowsos leírást lehetett megtalálni anno. Logikus, hogy linuxszal jobban kell működjön a buherálás, hiszen a végén a cél a vas szintjén mindig linux.
Frawly #7655 : Az is érdekes hogy linuxon sokkal gyorsabb a betömörítés folyamata, vagy a szoftverek telepítése wine alá, mint windowson.
-
Frawly
veterán
válasz
vargalex
#7442
üzenetére
A queque-d (NCQ) TRIM és annak tiltott állapota nem függ attól, hogy discard vagy fstrim-mel van-e hasznával. Az NCQ vs. nem-NCQ TRIM épp úgy megy mindkét megoldással párosítva. Plusz a kernel ATA quequed TRIM blacklistjén lévő SSD-k elég régiek, már kapni sem lehet nagyon őket, nem valószínű, hogy valaki belefut modern rendszeren.
A Dolphin-ra nem tudok mit mondani, ezek szerint tudja (bár ha fájlokról van szó, nem mappákról, akkor én nem vagyok benne biztos, hogy akkor is menni fog neki), csak locale probléma volt. Nekem eddig ezt a fajta rendezést egyik fájlkezelő se tudta (még a fájlkezelők non plus ultrája, a Total Commander se), egyik OS alatt se. Igaz nagyon korán, még a DOS-os időkben ráálltam, hogy bevezető 0-kkal toldom meg, mert úgy minden alatt működik. Meg szerintem doksiknak, mappáknak nem is a legjobb ilyen "1" és "10" nevet adni, mert visszanézi az ember pár hónap, pár év múlva, hogy az ilyen pöcs nevű fájlokról, mappákról fogalma sem lesz, hogy mi a rákra szolgáltak, egyenként meg kell nyitogatni, vagy valami view-er programmal átmenni rajtuk. Ehelyett célszerű rendes beszédes nevet adni mindennek, rendesen kiírva, ez már nem CP/M, DOS, meg FAT12-16, hogy 2-8 karakteres nevekbe kell beleférni. És a hosszú, beszédes fájlnév, mappanév még akkor se probléma, ha valaki CLI-ből használja a rendszer, terminálból, konzolból, SSH-ból, mert a Tab-os kiegészítés ilyenkor is kiegészíti őket 2-3 karakter bevitele alapján, nem kell az embernek a körmét legépelni.
Fájloknál arra is törekszek, hogy mindig legyen valami értelmes kiterjesztés, akkor is, ha Linuxon nem szokott számítani (nincs is kiterjesztés, az a név része), hogy mi a kiterjesztés. Pl. valaki itt nemrég leszólt, hogy a pain text, nem forráskódos fájloknak .txt kiterjesztést adok, mikor az felesleges, meg windowos berögződés. És ez a két utóbbi érv igaz is, én akkor is szeretem látni a kiterjesztést, mert később, évek múltán is látni fogom külön megnyitogatás nélkül, hogy mi volt benne, és nem tévesztem össze kiterjesztés nélküli shell scriptekkel, binárisokkal. De tőlem lehet .text vagy .doksi vagy .szöveg vagy akármi, csak kiderüljön micsoda, és ne legyen összetéveszthető más tartalommal, pl. plain text fájlnál .doc kiterjesztés nem jó, mert arról azt gondolhatja később valaki, hogy még a docx előtti időkből származó MS Word doksi, és a .tex kiterjesztés is megtévesztő, mert az meg a *TeX/*LaTeX forrásfájlok kiterjesztése.
-
Shyciii
veterán
válasz
vargalex
#7438
üzenetére
Kéne, de nem kapja meg. És az is feltűnő volt, hogy eddig külsős megoldásból 3-at is láttam, és egyik sem csak udev-es megoldással csinálta meg. Gondolom nem véletlenül. Gyakorlatilag mindegyik csak arra használta az udev-et, hogy egy szolgáltatást restartoljon, ami meg egy scriptet indít, és scriptben kezelték le. Nekem is csak így működik rendesen. Sőt most hogy találtam végre egy fuse-t használó mtp-s programot, ami nem csak olvashatóvá teszi az mtp tartalmát, hanem írhatóvá is (simple-mtpfs, jmtpfs pl nem engedi írni, hiába adom meg opcióként akár -o rw-vel, vagy umask-al, vagy owner a saját useremmel), így azt is beleteszem majd ebbe a scriptbe szerintem, ha meg tudja különböztetni az udev azt hogy usb-vel rádugom a telefont és aközött, hogy be is kapcsolom az mtp-t rajta. Mert mindkettőnél egyelőre csak azt látom, hogy usb-s actiont ír ki, vagyis eléggé félrevezető. Ha nem tudja az sem baj, mert egy gombhoz rendeltem az mtp felmountolását és a vifm megnyitását pont abba a mappába, úgyhogy használható az is.
-
anorche1
őstag
válasz
vargalex
#7443
üzenetére
Nem a verzioval van a gond. Manjaro alatt lefrisitettem (arra, amin arch -on is van), illetve archon downgradeltem (arra, amin manjaro volt), ujra is inditottam a gepeket, de archon tovabbra sem volt jo, manjaron igen.
Egy masik kerdesem is lenne kozben. Kde konsolban hogy lehet beallintani, hogy a
[felhaszanalonev@gepnev]mas szinu legyen mint az, amit irok, vagy ami a programnak a kimenete?
Settings/Edit Current Profil/Appearence alatt megtalaltam a temakat, meg engedi szerkeszteni az altaluk hasznalt szineket, de sajnos egyszerre valtozik minden szoveg szine (foreground sor elso oszlopban talalhato szinulesz minden). -
Frawly
veterán
válasz
vargalex
#7374
üzenetére
Oké, öntsünk tiszta vizet a pohárba, mert kiforgatjátok amit írok. Annyiból tényleg szakmai tévedést írtam, hogy a bloatságot a gvfs-nek tudtam be, meg hogy nevében keverem az udiskie-t az udisks2-vel. De azt kell érteni, hogy a LÉNYEGBEN igazam volt. Jó, akkor nem a gvfs a bloat, hanem az udisks2, ami magával hoz, és ne hazuttoljatok meg légyszi, itt van a pacman -S gvfs kimenete Artixon:
looking for conflicting packages...Packages (21) argon2-20190702-3 btrfs-progs-5.9-1 cryptsetup-2.3.4-1 device-mapper-2.02.187-3 dmraid-1.0.0.rc16.3-12 dosfstools-4.1-3 gcr-3.38-1
gptfdisk-1.0.5-1 libatasmart-0.19-5 libblockdev-2.24-1 libbytesize-2.4-1 libyaml-0.2.5-1 lvm2-2.02.187-3 mdadm-4.1-2 ndctl-70.1-1
parted-3.3-2 thin-provisioning-tools-0.9.0-1 udisks2-2.9.1-1.1 volume_key-0.3.12-3 xfsprogs-5.8.0-1 gvfs-1.46.1-1Total Installed Size: 54.15 MiB
:: Proceed with installation? [Y/n]
Felrak 54 mega szutykot, közötte az udisks2-őt, ha újraindítom a gépet, ott fut a folyamatok között az udiskd, eszi a rengeteg memóriát. Vagyis ahhoz képest rengeteg, amire az ember használná. Kötve hiszem, hogy ez Artix-on lenne csak így, bizonyíték, hogy Arch-on is így van (kattintsatok a Dependencies-re, majd alul Show more...), és kötve hiszem, hogy pont a Manjaro vagy akár a Debian/Ubuntu-vonal lenne kivétel. Nézzétek át a process listát, ágábrázolásban, mi fut, mi indította, mihez kell. Az a baj, hogy aki megszokta a bloatabb DE-ket, azoknak nehezebb elmagyarázni, mert az hiszik, hogy ezek a rendszer, meg a Linux kernel részei, közben nem.
Az udiskie-t csak én keverem, mert van egy csomó ilyen szutyok, udisks, udisks2, udiskd, udiskie, és annyira hasonló a nevük, hogy simán lehet keverni, bár ez sem teljes tévedés, mert van egymáshoz közük, pl. az udiskie egy frontend az udisks2-höz és udiskd-hez (ami az udisks2 daemonja), és az udisks pedig az elődje, amire az udiskd2 előtt épült. Tehát ha az egyiket felteszitek, rántja magával a többit. Lehet itt vitatkozni, hogy nem az alkohol káros a szervezetre, hanem a májzsugor, amit magával hoz, a lényegen nem fog változtatni.
Fejezzétek be a gvfs leírását, igen, én is tudom, hogy egy virtuális fs driver, ami a userlandban implementál fájlrendszert, hogy ne kelljen a kernelspace-ben a kernel fs drivereket használni, amihez root jog kell, meg olyan fájlrendszer is implemetálva legyen, amihez nincs kerneldriver közvetlenül, pl. hálózati csatolások, egyéb protokollok, NFS, Samba, FTP, MTP, PPT, stb.. Annyiból viszont igenis bloat, mint már írtam, és a kimenet is bizonyítja, hogy hozza magával a bloat szutykokat. Ezeket nem csak hogy felteszi, de a párat a háttérben is futtatni fog szép szorgosan. Gondolom valaki annyira keményen dolgozik érte, le tudta tiltani, hogy ezek a komponensek automatice induljanak, de egyrészt minden frissítéskor vissza fogja őket tenni a vonatkozó csomagok postinstall scriptje, azaz lehet vele fetrengeni minden telepítéskor, frissítéskor, és meg ha tényleg szükség van az általa nyújtott funkcióra, akkor kézzel indítva futtatni őket, oh, de wait, pont az automatikáról volt szó, hogy csatoláshoz ne kelljen semmit külön kézileg indítani, mert akkor az egész értelme ment le a lefolyóba.
Én meg már ötödször leírom, hogy pont ezeket kerülöm, hogy sok felesleges ballaszt azért menjen a háttérben, mert majd egyszer hátha kell. Nagy ritkán. De azért foglaljon folyamatosan. És nem maga az elfoglalt memória, hanem rendszerinduláskor a sok felesleges dolog betöltése. Ezek némelyike nem tűnik nagynak, egy kis 14 MB itt, egy kis 50 MB ott, egy kis 30 MB-os dbusd amott, egy kis SuzukiSwiftd, amott, logind, anámykínyja-spi-bus-launcher, spi2-nyomorékság, és az ember csak pislog, hogy a RAM használat nőtt 300-500-1000 MB-tal, és hiába combos a gép, i9, Ryzen 7-9, Threadripper, azért azoknak is idő induláskor betölteni ezt a sok szutykot, mert igaz, hogy gyorsabban töltik be, meg több mindent párhuzamosítanak, de akkor is idő nekik betölteni, mindegy milyen kevés ms, az az idő ott van, és sok ilyen sallangnál a végén elég meredeken összeadódik. És ha még tényleg annyira megkerülheteten lenne, hogy tényleg minden szoftvernek kéne nonstop, minden percben, arra azt mondanám, hogy nincs mit tenni. De van, mert megkerülhetők ezek. Pont ez a szépsége a Linuxnak, hogy itt nem kötelező a sok bloatot használni. Windows, MacOS alatt kell, mert azok készre drótozott egyenrendszerek, amik le is vannak zárva a felhasználó elől.
Már pedig ha az ember javarészt terminálos programokat futtat, GUI-sat kivéve, akkor meg aztán tényleg hulla felesleges ezeknek a 99%-a, lehet ezek nélkül is meghajtót kényelmesen felcsatolni, hangot csiholni, alkalmazásoknak kommunikálni, stb.. Még a hálózat is megoldható mindenféle netctl, NetworkManager meg egyéb nélkül.
Egyébként meg ez a meghajtócsatolás Linuxon el van maradva sok évvel. Külön halom bloat kell, hogy a jenlegi csatolási körülményesség megkerülhető legyen, mindenféle keretrendszerek és service-ek futtatása. Ennek nem szabadna így lennie. Értem hogy a biztonság miatt van így, hogy korlátozott user ne tudjon mesterséges chroot környezet beröffenteni (mikor is előre preparált fájlrendszereket csatol fel /proc, /etc, stb. helyekre, root jogot szerezve), de ez egy másik véglet. A user mappájába, user joggal, userspace driverrel engedniük kéne akárminek a csatolását, mindenféle szutyok feltétele nélkül, mindenféle root jog nélkül, out of the box, úgy, hogy kényelmesen automatizálható legyen, és ne legyen gebasz a korlátozott user írási jogával sem. Ebben a tekintetben tényleg le van maradva a Linux kb. 20-30 évet. És itt nem arról van szó, hogy aki haladó, ezt ne tudná megoldani, de ez a fetrengés felesleges hozzá, más OS-eken ez egy alap dolog, hogy van egy meghajtó, a user felcsatolja magának. Ami egyébként biztonságilag sem problémás, mert ha ugyanaz a korlátozott user bebootol egy Live rendszert, akkor ott root joggal fogja elérni ezeket a meghajtókat úgyis. Ha meg ez valaki ki akarja védeni, akkor nem elég a felcsatolást megnehezíteni, hanem titkosítás kell. Így erre a linuxos felcsatolási ökoszisztémára nagyon ráférne egy nagy adag modernizáció.
-
szuszinho
őstag
válasz
vargalex
#7325
üzenetére
Már mindent Dockerben futtatok. Pillanatok alatt vissza tudtam tenni mindent egy OS telepítés után.
Eddig Ubuntu szervert használtam, nem volt ilyen problémám. A jelenlegi beállítások is egy az egyben onnan vannak.
Sajnos a tűzfalhoz nem értek, ezért sem tudom, hogy mit kellene módosítani.iptables-save: [link] -
Frawly
veterán
válasz
vargalex
#7264
üzenetére
Igen, ezt pont ezért írtam neki előre, hogy kell az EDITOR="blabla" a visudo parancs elé. Nem véletlenül írok litániákat, igyekszek minden buktatóra és félreértési pontra részletesen kitérni, azokra is, amelyek az emberek 99%-a szerint anélkül is egyértelműek, de én tudom tapasztalatból, hogy abban a fentmaradó 1%-nyi esetben milyen hatalmas szopásokat lehet megelőzni, ha az ember nem tömör balladai homályozik, hanem normálisan és részletesen írja le a dolgokat, úgy, hogy semmi ne maradjon ki, semmiben ne legyen kétség, félreértés.
-
Frawly
veterán
válasz
vargalex
#7261
üzenetére
Nem értek teljesen egyet. A kernel bootkor állítja be az entrópiát a random seedhez, akkor még desktop gépen is szöveges konzol van csak, se egér, se billentyűzet, se semmi. Nem látom be, hogy ez hogyan más egy headless cucctól.
Ennél az alacsony entrópiánál is meg kell jegyeznem, hogy ez újabban ilyen paranoia csak, 40+ évig elég volt a „sima”, normál entrópia, most néhány paranoid ultra hardened biztonságmániás, NSA-CIA-ellenes sznob kitalálta, hogy mivel nem tökéletes randomságot ad, ezért elméletileg támadható, és ebben a vonatkozásban is próbálnak túlzásba, végletbe esni. De az van, hogy elméletileg minden lehetséges, de a gyakorlatban a sima entrópiás SSH/AES-hez használt, SHA, RSA hasheket sem tudta még senki feltörni, ha nem volt benne szándékos vagy túl felelőtlen implementációs hiba.
Mondom, én most nem veled vitatkozok, meg nem próbálom a szakmai hozzáértésed kétségbe vonni, hanem ez a toljuk a magas entrópiát meg legyen deafult a haveged mánia ellen akarok a józanság irányába érvelni.
#7262 sati: kösz, ezt nem is ismertem. Ki fogom próbálni, mert csak azért X.org-ozok most is, mert a Sway-nek alapból kell a systemd, ami systemd-mentes disztrókon eddig gondot okozott nekem.
Egyébként azt kell mondjam, hogy objektíve nézve a systemd-nek vannak előnyei:
1) bootidő egyértelműen a leggyorsabb az összes initrendszer között, mármint rendes menetben, mikor nem vár kilőhetetlen start job is running szutykokra
2) ha beállítasz egy szolgáltatást, akkor az tuti működik.Persze ettől még utálom, és nem kéne mindent kötelezően a systemd-re dependelni. De sajnos most az OpenRC-vel szenvedek megint, hogy hiába állítom be a /etc/conf.d/consolofont fájlban, hogy az általam megadott Terminus2 32pt fontot használja, azt használja is, de csak bootkor és boot után az elsőnek megnyitott (tty1) konzolon. Ahogy átváltok tty2-re már újra bolha VGA BIOS betűk vannak.
Ezzel szemben systemd-s disztrókon a terminus-font csomag telepítése után megadom az /etc/vconsole.conf fájlban megadom, hogy FONT=term-232n, akkor az működni fog, nem csak boot után, nem csak tty1-en, hanem minden tty-on, éjjel, nappal, fejen állva is.
Érdekes, Gentoo-n jó volt OpenRC-vel, Void-on jó volt runit inittel, de most Artix-on nem jó OpenRC-vel. Fene se érti ezt, a doksik alapján jó helyen állítom, működik is, de csak félig.
-
#63718632
törölt tag
-
Frawly
veterán
-
Frawly
veterán
válasz
vargalex
#7250
üzenetére
Elbeszélünk egymás mellett: én nem azt mondom, hogy valamihez nem jön jól a haveged, mert néha tényleg előnyös vagy indokolt lehet a használata. Ezt sose vitattam. De nem annyira alap dolog, hogy egy alaptelepítésbe beleerőltessék per default. Példának itt van ez a most szóba hozott sudo, sok usernek az alapabb dolog lenne, mert már reflexszerű toolként használják, és a legtöbb haladó disztrón külön kézzel kell feltenni, beállítani, hogy működjön. Na, így kéne ennek lennie a haveged-del is.
-
Frawly
veterán
válasz
vargalex
#7225
üzenetére
Igen, alacsony az entrópia, de működik haveged nélkül. Azt se felejtsük, hogy attól még, hogy valami szerver headless, az nem azt jelenti, hogy:
1) NSA és CIA elleni is titkosítva kell legyen
2) annyira magas entrópia kell a random seednek, hogy erős legyen a generált hash és titkosítási kulcsEgy házi projektben bőven elvan a szerver alacsony entrópiával is, pl. házi NAS, egyéb házi megoldás. Egy céges, mission critical szerver az más, ami meg van nyitva a publikumnak, és kívülről a netről törhetik, és komolyabb támadásnak van kitéve, mert mondjuk egy ismert szervezet oldala, vagy más szervere (ftp, egyéb).
Igazából ezt, hogy headless, még annyiból sem értem, hogy egy szervernél holt mindegy, hogy van-e rá mondjuk egy monitor, billentyűzet kötve vagy headless. Attól, hogy valami headless, még nem igényli jobban a magasabb entrópiát.
Persze, nem veletek vitatkozok, mert egyes esetekben valóban hasznos lehet a haveged, ezt nem vitatom, de hogy mindjárt default installba kötelezően a userre rátukmálni, az szerintem egy kicsit túlzás. Főleg ARM platformon, ahol az erőforrások amúgy is korlátosak általában. Egy desktop gépnél, egy mainstream full bloat DE-s disztrónál azt mondom, hogy ott beleerőltetik, mert már úgyis olyan hardverigénye van, hogy nem oszt, nem szoroz. De itt RPi-ról beszélünk.
Persze az is igaz, hogy a haveged csak addig fogyaszt erőforrást, amíg lefut, utána elvileg kilép, nem fut tartósan, de pl. a telepített csomagja foglalja a plusz helyet. Sokkal bölcsebb lenne, ha az Arch ARM Wiki inkább csak ajánlaná a havegedet, de opcionálisan. Úgy aki paranoid a biztonság terén, az feltenné, aki meg nem, arra meg nem lenne +1 sallang rátolva.
-
-
Frawly
veterán
válasz
vargalex
#7223
üzenetére
Kösz az infót, érdekes, ezt nem tudtam. Egyébként meg továbbra sem indokolt a haveged, SSH-hoz sem kötelező, a kernel anélkül is generál random seed-et. Az is igaz, hogy nem olyan nagy tragédia, ha fent van, de azért egy RPi-on elég korlátozottak az erőforrások, én emiatt leszedném mindenképp a havegedet.
Arch ARM-et sem használtam még, nem tudtam, hogy ott tényleg van egy alaprendszer.
-
Frawly
veterán
válasz
vargalex
#7142
üzenetére
Szerintem ez végig hardverhiba volt, azért jó a legújabb alaplappal minden kernel. Lehet az egyel régebbi alaplap már megbízhatatlanul működött, ami LTS kernelnél nem jött ki, mert az mondjuk nem rakott rá olyan terhelést, nem tartalmazott valami olyan optimalizációt, ütemezőt érintő módosítást, ami kiütköztette volna a hibát.
Ilyen Windows esetében is láttam, hogy halódó hardveren még jól ment az XP (vagy talán még a Win7 is), de mondjuk az újabb windowsok nem, mert azok jobban meghajtják, és kiütközik a hiba. Sőt, ugyanez tuningnál is előfordul, hogy mikor már olyan magasra vannak húzva az órajelek, akkor félstabil állapotba kerül, és régebbi Windows verziók alatt, vagy 32 bit alatt stabilnak látszik, újabb 64 bites verziókkal újraindulgat, kékhalálozik. Ugyanez teszteknél, pl. Cinebench még lefut, de pl. a Prime95 már behasal rajta, de még GPU-nál is láttunk ilyet, hogy 3D Mariska, meg Unigine teszt rendben lement rajta, meg néhány játék, míg a FurMark teszt, meg néhány még újabb játék meg már hibát produkált vele. Ez ilyen műfaj, hardverek tudnak ilyen borderline hibát produkálni, miközben halódnak szép fokozatosan megfelé.
-
Frawly
veterán
válasz
vargalex
#7110
üzenetére
Ez igaz, az SBC-k nem érték még utol a desktop platformot. Meg talán sose fogják, mivel úgy vannak kitalálva, hogy 1/10-ed annyit fogyasszanak.
Az i3 egy elég széles skálán mozgó proci egyébként. Nagyon nem mindegy, hogy mobil vagy dekstop, és hogy hányadik generáció. Pl. az i3-10100 egy elég combos proci, simán ver egy pár generációval előtte lévő asztali i5-i7-et! Ugyanis dupla annyi cache van benne, és dupla annyi mag/szál, mint a korai i3-akban, IPC is jócskán nőtt, meg megkapott egy csomó utasításkiegészítést, ami előtte nem volt i3-akon elérhető. De mondjuk egy i3-330M vagy i3-4120U az nem lesz valami combos, azzal sanszos nem lesz kihajtva még több magon sem a gigabites net, talán a 4120U az határeset lehet.
Itt azt kell érteni, hogy bár megfizethető, a világviszonylatban a gigabit luxus. Bár megfizethetővé tette a Digi, meg a gigabites hálókártyák sem drágák már, de még sok ember UTP kábelinfrastruktúrája, routere, gépe nincs rá felkészülve, sem LAN-on, sem WAN-on.
(#7109) Shyciii: még nem próbáltam ki a transmission-cli-t. Hétvégén sem volt rá időm. Fel van telepítve, de nincs bekonfigolva, nem röffentettem még be, igaz torrentet sem kellett letöltenem azóta. Lehet majd ezen a héten, mert vagy szabin vagy influenza miatti betegszabin leszek valószínű, így lesz elég időm és türelmem, hogy beállítsam, és megtanuljam használni.
Mondom, nekem a qB-vel nem az a bajom, hogy Qt-s meg bloat, persze ezek hátrányai azért, hanem hogy a fejlesztők a libtorrent-rasterbar mögött kullognak rendszeresen, ez már rendszeres, hogy eltörik, és képtelenek időben kijavítani. Mert én vagyok a bloat legnagyobb ellensége, de ha valami tényleges átütő előnyt ad, azért néha használok én is bloat dolgokat, nyilván a minimumra szorítva, a legindokoltabb esetben. Ez utóbbi esetkörbe a qB eddig nálam belefért, de nem kap több esélyt.
De ezen a ponton az bizonyosodott be, amit előre tudtam, meg ide a PH-ra is sokat írtam, hogy a minimalizmusnak pont az a lényege, hogy a minimalista/CLI programoknak nem nagyon van függősége, egyszerű a kódbázisa, így nincsen mi eltörjön rajtuk, nem függenek mindenféle más kódtól, és nincs az, hogy a sok függőség közül eltörik valami. Meg emiatt kódból forgatni is könnyebb, könnyebb frissen tartani ezeket a progikat, akkor is, ha nincsenek benne egy adott disztró tárolójában. Az már csak hab a tortán, hogy nagyon villámgyorsan is futnak, töltődnek be, és alig esznek memóriát.
-
Shyciii
veterán
válasz
vargalex
#7112
üzenetére
Ha nem csak desktop vonalat veszem, akkor még rosszabb a helyzet, mert az összes szerver kategória is belekerül, meg a mobilplatform. Ami azért gáz, mert a jelenlegi mobilom grafikus chipjének számítási teljesítménye köröket ver rá...szal ha minden kategóriát beleveszek, akkor végképp a béka feneke alatt van az i3.
Mégegyszer mondom: világviszonylatban a home server topic abszolút nem releváns. Még az is relevánsabb, hogy maga a gyártó, hova sorolja a saját prociját, pedig szeretnek túlozni. Továbbra sem a magyar home szerver topic határozza meg, hogy egy processzor a teljesítménye folytán mennyire számít erősnek. Rengeteg több szakma által elismert teszteket, hardveres architektúra felépítés stb alapján határozzák meg. Részemről lezárom ezt a témát, mert ez már átfordult a nevetséges kategóriába. -
Shyciii
veterán
válasz
vargalex
#7110
üzenetére
Teljesen mindegy, hogy ki milyen procit használ a Home server topicban. Nézd meg világviszonylatban (igen, önmagában Magyarország nem számít annak), hogy a procik listáján hol szerepel egy 3-4 generációval régebbi noteboook Core i3-as. Még csak nem is középkategória, hanem jócskán azalatt. Attól hogy valakinek nincsen pénze opel corsa-ra, attól még a trabant nem erős autó...
-
Frawly
veterán
válasz
vargalex
#7107
üzenetére
Ez van, a gigabit luxus, kihajtani csak extrákkal lehet, UTP6 kábel, gigabites router, erős proci, stb.. Nálam eleve csak egy magon is elég erős x86_64 procik futnak, és gigabites netem sincs, mindig 50 Mbit alatt, így nem érint, hogy mi hány magot használ. Ennek ellenére én is pozitívnak tartom, ha egy alkalmazás fel van készítve a több mag használatára, úgy a kernel szabadabban pakolgatja az erőforrásait, mégis csak segíthet a futásának az olajozottságán.
sot par hete istenitettem, h mennyivel jobb ARM-on mint az FF. Most fordult a kocka, 2 het mulva meg ujra, ki tudja.
Új hozzászólás Aktív témák
Hirdetés
BoB- Azonnali fotós kérdések órája
- 3D nyomtatás
- Győr és környéke adok-veszek-beszélgetek
- AMD Ryzen 9 / 7 / 5 7***(X) "Zen 4" (AM5)
- PlayStation 4
- Vezetékes FÜLhallgatók
- Elemlámpa, zseblámpa
- Luck Dragon: Asszociációs játék. :)
- Fortnite - Battle Royale & Save the World (PC, XO, PS4, Switch, Mobil)
- sziku69: Szólánc.
- További aktív témák...
- Windows, Office licencek kedvező áron, egyenesen a Microsoft-tól - Automata kézbesítés utalással is!
- Számlás!Steam,EA,Epic és egyébb játékok Pc-re vagy XBox!
- Microsoft licencek KIVÉTELES ÁRON AZONNAL - UTALÁSSAL IS AUTOMATIKUS KÉZBESÍTÉS - Windows és Office
- Antivírus szoftverek, VPN
- Bontatlan - BATTLEFIELD 1 Collectors Edition - Játékszoftver nélkül
- ÁRGARANCIA!Épített KomPhone Ryzen 7 7700X 32/64GB RAM RTX 5070Ti 16GB GAMER PC termékbeszámítással
- iKing.Hu - Apple iPhone 13 Pro Max - Graphite - Használt, újszerű
- BESZÁMÍTÁS! CSAK KIPRÓBÁLT! ASUS ROG Ally X (2024) 1TB kézikonzol garanciával hibátlan működéssel
- Azonnali készpénzes AMD Radeon RX 5000 sorozat videokártya felvásárlás személyesen / csomagküldéssel
- Dell USB-C dokkolók: (K20A) WD19/ WD19S/ WD19DC + 130W, 180W, 240W töltők
Állásajánlatok
Cég: CAMERA-PRO Hungary Kft
Város: Budapest
Cég: PC Trade Systems Kft.
Város: Szeged