- Friss koncepciót hoz a Nothing Phone (3)
- Fotók, videók mobillal
- iPhone topik
- Ismét a Honoré a legvékonyabb hajlítható
- A lapkakészlet és az akku különbözteti meg a Motorola Edge 60 és Edge 60 Pro-t
- Nem növel telepméretet a Galaxy S26 Ultra
- Megjelent a Poco F7, eurós ára is van már
- Magyarországról is elérhető a Xiaomi Pay
- Xiaomi 14T Pro - teljes a család?
- Netfone
-
Mobilarena
Arch Linux topik
Új hozzászólás Aktív témák
-
vargalex
félisten
Szerintem is elbeszélünk egymás mellett: ahogy írtam, az Arch Linux ARM alapvetően kis headless gépekre (értsd: nincs is rajta monitor kimenet) készített distro (csak, hogy azokat a vasakat említsem, amik miatt egyáltalán létrejött a projekt: Pogoplug, SheevaPlug, Seagate Dockstar, Seagate GoFlex Home, Seagate GoFlex Net, stb.). Ezeket az eszközöket csak SSH-n tudod elérni (jó, ott van még a soros port, de az átlag usernek nem opció). Márpedig az SSH szolgáltatás indításához random kulcsok generálására van szükség, ami a kis entrópia miatt blokkolva lesz. Ergo nem éred el sehogy a gépedet. Szóval, indokolt, hogy az alaptelepítés része legyen.
-
vargalex
félisten
-
-
vargalex
félisten
Szerintem a wiki-ben nagyjából ott is a válasz: "
Haveged was created to remedy low-entropy conditions in the Linux random device that can occur under some workloads, especially on headless servers."Márpedig az Arch Linux ARM elsőslegesen headless server-ekhez készült. Ezért is része több dolog az alaptelepítésnek, hiszen egy olyan rendszert kell elindítani, ami rögtön távolról is elérhető, tehát pl. az SSH kulcsok generálása is megtörtént (ehhez pedig kell a random úgy, hogy semmi felhasználói aktivitás nem volt).
Az már más kérdés, hogy a projekt indulása óta már több olyan board is van (pl. a kolléga által használt Raspberry Pi), amire kijelző is köthető, tehát akár teljesértékű desktop rendszerként lesz használva. Én anno pl. Seagate GoFlex Net-en használtam nagy megelégedéssel. -
#7188
vargalex
félisten
Xenophobermn
#7186
vargalex
félisten
válasz
Xenophobermn
#7186
üzenetére
Visual Studio Code-ban működik PHP esetén is, ott dupla kattintásra csak a változó nevét jelöli ki $ nélkül.
-
-
vargalex
félisten
Sziasztok!
Érdekes esetem volt, gondoltam leírom, hátha mással is megesik:
Szóval, van egy céges Dell Latitude 5590-es notebook-om, amin természetesen Arch linuxot használok. 2019 szeptemberében (alig 1-2 hetes volt a gép) munka közben szétesett a kép, össze-vissza villódzott, majd a bekapcsoló gomb hosszú nyomására történő kikapcsolás utáni bekapcsolásra csak hibakód villogást produkált (az elején lévő erre is szolgáló leden). Később mégis elindult, de jelentettük a Dellhez és cserélték is az alaplapot. Ez az alaplap az utóbbi 2 hétben viszont négyszer-ötször ismét hibakódot produkált (egy másikat, ez a ledek villogása szerint CPU hiba), így ismét jelentettük. Jött a szervizes, ismét cserélték az alaplapot (múlt pénteken).
Ezután érdekes számomra a történet. Ugyanis az új alaplappal random idő után (2-10 perc közti időtartam) lefagyott a grafikus felület, az egér sem reagált. 1-2 perc múlva az egér visszajött, de a grafikus felület nem. Terminálon (tty3-on) be tudtam jelentkezni és GPU crash dump-ot láttam a logban. Ez azért érdekes, mert nincs külön GPU, a CPU-ba (I5-8350u) integrált van csak. Viszont újraidítva a grafikus felületet, ismét ment néhány percig, majd újra hiba. Újraindítás után ugyan ez folytatódott.
Gondoltam megnézem LTS kernellel. Hibátlanul ment, egész hétvégén nyüstöltem.
Persze még pénteken ismét lejelentettem, hogy nem jó az új alaplap, tegnap jöttek is ismét cserélni. Ez az alaplap viszont már a friss kernellel is hibátlanul működik.
Láttatok már ilyen hibát? Az LTS kernel ennyivel hibatűrőbb lenne? Úgy gondolom, hogy nyilván volt valami hardware hiba a cserélt alaplapon, ha az előtte és az utána lévő sem produkálta ezt a hibát. De a CPU-ba integrált GPU?Annyit megtudtam a szervizestől, hogy ezek egyébként Csehországból érkeznek, javított, átnézett alaplapok.
-
vargalex
félisten
válasz
Shyciii
#7113
üzenetére
Ne a mobilod grafikus teljesítményét nézd, hanem a CPU számítási teljesítményét. Hiszen pl. a transmission nem a GPU-t használja! És ne is céges szerver kategóriát.
De hagyjuk, nem akarod megérteni, hogy a többség (Magyarországon) Core i3-nál jóval gyengébb CPU-kon torrentezik. És még a routeren torrentezést nem is említettem, ahol még csak nem is ARM, hanem MIPS architechtúrán tolják ugyan ezt.
Ezekhez képest írjuk itt mi az erős CPU-t. De ezt leírtam már az összes hozzászólásomban. Sehol nem írtam olyat, hogy nézd meg általánosságban. És valóban nevetséges, hogy csak részleteket ragadsz ki a hozzászólásaimból, a lényegén teljesen átsiklasz... -
vargalex
félisten
válasz
Shyciii
#7111
üzenetére
Ez az x86 világban igaz. De mondom, nézz szét a NAS-ok között. Sőt, sokan használják android boxokat linux-al ilyen célra, amik szintén ARM-el szeretlek.
A home szerver topicban pedig az a jellemző, hogy passzív hűtéssel ellátott lapokat használnak. Ezt az általad említett CPU-kkal nem tudod megtenni.
És még egyszer mondom, ne desktop vonalban gondolkodj! -
vargalex
félisten
válasz
Shyciii
#7109
üzenetére
Márpedig egy Core i3 nem csak egy RPi4-hez, hanem egy átlagos NAS CPU-jához (ami általában szintén ARM) igen is erős CPU-nak számít. Ezt kell elfogadni. Nem feltétlenül mai desktop CPU-khoz kell hasonlítani. Azoknak nyilván nem gond a gigabit. De nem is feltétlenül csak ARM-hez. Nagyon sokan, köztük én is "szar Celeron, meg Nxxxx-es" CPU-val szerelt lapokat (én konkrétan Intel J3455-öt) használnak otthoni mindenes szervernek. Elég lenne csak benézni a Home server / házi szerver építése topic-ba. Szerintem az én szerverem sem bírná a gigabitet torrentben 1 magon, persze kipróbálni nem tudom, mert 500 Mbps-es netem van. Szóval minden csak viszonyítás kérdése.
És ugye az eredeti kérdező nem is desktopról beszélt, hanem konkrétan az RPi-ről. Amit egyébként én sem használnék desktop eszköznek (még az operátorok számára sem).
-
vargalex
félisten
válasz
Shyciii
#7105
üzenetére
Azért egy bármilyen Core I3-at nem szabad összehasonlítani egy RPi-vel. Ég és föld a különbség. Láthatod, hogy nálad a transmission kihajtja a gigabitet, míg a kollégánál 80-160 Mbps-nél vége. Pedig a csúcs RPi-vel használja. Így nála teljesen jogos a több magos alkalmazás igénye.
-
-
vargalex
félisten
válasz
Siriusb
#7061
üzenetére
Én is éppen tegnap frissítettem a teljes rendszert, és gond nélkül megy tovább a qbittorrent (qbittorrent-nox-ot használok). Valóban áprilisi verzió, amit egyébként tegnap flaggeltek out-of-date-ra. De ez még nem jelenti, hogy máris lenne újabb verzió. Persze lehet, hogy egy rövid időre volt a repoban...
-
#7055
vargalex
félisten
Xenophobermn
#7054
vargalex
félisten
válasz
Xenophobermn
#7054
üzenetére
Azért azt lássuk be, hogy ez nem normális... Mitől kellene mindig telepíteni a grub-ot???
-
#7052
vargalex
félisten
Xenophobermn
#7051
vargalex
félisten
válasz
Xenophobermn
#7051
üzenetére
Pedig akkor az lesz, amit a kolléga ír. Nem jó SSD-re mutat az EFI bejegyzés. Próbáltad úgy is, hogy visszarakod a másik SSD-t is?
BIOS-ban sem tudsz boot manager-t váltani? -
vargalex
félisten
válasz
Shyciii
#6700
üzenetére
Hát, nem tudom. Én Oracle-ben vagyok járatos. Megfelelő indexeléssel, particionálással nem lesz gyorsabb, áttekinthetőbb, ha szétdobod... Persze valószínűleg azért dobod szét, mert nincs particionálás. Egy bérszámfejtő alkalmazáshoz tartozó adatbázisban nincs annyi különböző adattípus, ami indokolná azt a sok táblát.
-
-
vargalex
félisten
válasz
Shyciii
#6696
üzenetére
Persze, nálunk is hazahozhatta mindenki a munkaeszközeit. Ezzel nincs gond. Nyilván kényelmesebb a nagyobb monitor, de nem létszükséglet. Volt olyan fejlesztő kollégám, aki még a külső monitort sem használta.
Viszont az XML egy sorában 400 karekterből bármilyen beágyazás esetén (normális formázás mellett) a töredéke információ, a többi csak tab... -
#6527
vargalex
félisten
teleahocipöm
#6526
vargalex
félisten
válasz
teleahocipöm
#6526
üzenetére
Az, hogy kiléptet a Chromium szerintem nem a hw-tól függ.
-
-
vargalex
félisten
válasz
#63718632
#6191
üzenetére
Annak, hogy az amd-ucode.img létrejön-e a /boot-ban semmi köze a használt bootloader-hez. Az egyszerűen az amd-ucode csomag telepítésétől függ, ugyanis az hozza létre. Itt láthatod is a Package Contents alatt. Szóval, úgy tűnik, hogy mégsem került telepítésre, vagy az általad használt telepítő script utólag feleslegesen pucolja ki a /boot-ból.
Nyilván a használt telepítő scripttől (ha használ olyat az ember, de szerintem jobb az Arch wiki-t követni) az függ, hogy a microcode bejegyzést létrehozza-e a használt bootloader-nek megfelelően. -
vargalex
félisten
Az emlékezetemben nekem már úgy élt, hogy az AMD procikhoz külön csomag van. Most jutott eszembe ez a hozzászólásod, így megnéztem gyorsan a microcode wiki history-t. Jól emlékeztem, az a jó pár hónapja egészen pontosan 2018 augusztus 26-án volt.
Nyilván azóta ránéztem már az oldalra, ezért emlékeztem... -
vargalex
félisten
Ugyan nem írta a kolléga, hogy milyen CPU-ról van szó, de nyilván 1 mag futott 100%-on, kérdés az milyen sebességre képes.
Mégpedig valószínűleg pont azért, mert SSD-ről meglehetősen gyorsan lehet olvasni, így valóban az ntfs-3g terhelte. Persze az elért olvasási sebessegről sem tudunk semmit... -
vargalex
félisten
Engem soha nem zavart a clipboard támogatás hiánya. Kijelölök egy szöveget és középső gombbal (vagy touchpad esetén a 2 gomb egyidejű nyomásával) beillesztem. Nem akarom én nézegetni a vágólapot, nem kell többszörös tartalom, stb.. Mindig az utoljára kijelöltet akarom beilleszteni és ez megy oda-vissza a sima alap vim-el is.
-
vargalex
félisten
Jó lett volna, ha frissíted a repo-t a
pacman -Selőtt. Így nyilván nálad még a cache-elt verziót jelentette. A linkelt hírben egyébként metapackage-t írnak, nem package-t és ez az infó jött RSS feed-ből is.
Ahogy a hír is mondja, eddg a base egy group volt, most viszont metapackage lett. -
vargalex
félisten
válasz
attilav2
#5945
üzenetére
EFI esetén valóban a legegyszerűbb a systemd-boot használata. Évek óta azt használom, nincs gondom vele.
Nem kell kézzel bepötyögni, berakhatod egyetlen paranccsal:echo "options root=PARTUUID=$(blkid | grep sda2 | sed 's/\(.*\)PARTUUID="\(.*\)"$/\2/') rw" >> /boot/loader/entries/arch.confTermészeteesen itt az sda2 a megfelelő partíció számával helyettesítendő. De magát a root partíciót megadhatod labellel, vagy akár device-val is.
-
#5904
vargalex
félisten
SteveBeard
#5903
vargalex
félisten
válasz
SteveBeard
#5903
üzenetére
Nézd meg, hogy hol keresi a wget-et. Lehet, hogy csak nem jó helyen...
-
vargalex
félisten
válasz
Shyciii
#5860
üzenetére
Nem írtam, hogy scriptekkel kellene telepíteni. Én még soha nem telepítettem úgy... Csak annyit írtam, hogy miért van NetworkManager-ed, ha nincs GUI-d és nincs is hozzá semmilyen config.
A telepítő indításkor alapból indítja a dhcpcd-t, így van net. Viszont ez a service telepítés után nincs engedélyezve, így a már telepített rendszert boot-olva kell egysystemctl start dhcpcd.servicevagy interface specifikusan
systemctl start dhcpcd@interface.servicede ez ott is van a wiki-n.
-
vargalex
félisten
válasz
Shyciii
#5856
üzenetére
Ha nincs GUI, akkor miért raktál fel NetworkManager-t? Ha jól látom, az alapból semmilyen konfigurációt nem tartalmaz, így nem is fog DHCP-n IP-t kérni. Úgyhogy, vagy beállítasz egy connection-t a /etc/NetworkManager/system-connection-s alá, vagy tiltsd a NetworkManager-t és engedélyezd a megfelelő interface-ra a dhcpcd-t.
Ha ez egy szerver, akkor felesleges a NetworkManager. Teljesen jó a systemd-networkd, vagy a dhcpcd. -
vargalex
félisten
Én először rTorrent-et használtam, majd sokáig Transmission-t. Aztán visszatértem az rTorrent-re, majd váltottam qBittorrent-re. Utóbbi jóval gyorsabban elkezd maximális sebességen tölteni. Az rTorrent sajnos feleslegesen jobban terheli a háttértárat seed alatt (nagyságrendekkel több adatot olvas, mint kellene). Én egyelőre maradok a qBittorrent-nél, ami nálam egy AsRock J3455-ITX lapon fut (az otthoni mini szerverem/NAS-om, természetesen Arch-al), gond nélkül kihajtja az 500 Mbps-es netet. 60 MB/s letöltésnél a magok még csak fel sem kapcsolnak maximális órajelre...
-
vargalex
félisten
válasz
Shyciii
#5762
üzenetére
A transmission valóban kis erőforrásigényű, nem véletlenül alkalmazzák embedded rendszereknél is.
16 MB/s persze nem gond egy x86-os CPU-nak. Az érvelésedet továbbra sem értem, különösen annak fényében nem, hogy úgyis nyitva van több fül a böngésződben. Egy új fül már nem hinném, hogy (sokkal) több RAM használatot eredményezne, mint egy új natív alkalmazás...
Új hozzászólás Aktív témák
Hirdetés
- Székesfehérvár és környéke adok-veszek-beszélgetek
- Hardcore café
- Több évig húzódó per várhat az Apple-re az iPhone-ok uralma miatt
- A fociról könnyedén, egy baráti társaságban
- Milyen alaplapot vegyek?
- Nintendo Switch 2
- Apple asztali gépek
- Kuponkunyeráló
- MasterDeeJay: Noname 1TB-os SATA SSD teszt
- Autós topik
- További aktív témák...
- Windows 10 11 Pro Office 19 21 Pro Plus Retail kulcs 1 PC Mac AKCIÓ! Automatikus 0-24
- Antivírus szoftverek, VPN
- Microsoft licencek KIVÉTELES ÁRON AZONNAL - UTALÁSSAL IS AUTOMATIKUS KÉZBESÍTÉS - Windows és Office
- Adobe Előfizetések - Adobe Creative Cloud All Apps - 12 Hónap - NYÁRI AKCIÓ!
- Vírusirtó, Antivirus, VPN kulcsok
- ÁRGARANCIA!Épített KomPhone i5 14600KF 32/64GB RAM RX 9070 16GB GAMER PC termékbeszámítással
- LG 45GS95QE - 45" Ívelt OLED / 2K WQHD / 240Hz 0.03ms / NVIDIA G-Sync / FreeSync Premium / HDMI 2.1
- Xiaomi 11T Pro 128GB, Kártyafüggetlen, 1 Év Garanciával
- Csere-Beszámítás! Gamer PC Számítógép! I5 12600KF / RTX 3070 / 32GB DDR4 / 512GB SSD
- Telefon felvásárlás!! Samsung Galaxy A16, Samsung Galaxy A26, Samsung Galaxy A36, Samsung Galaxy A56
Állásajánlatok
Cég: CAMERA-PRO Hungary Kft
Város: Budapest
Cég: Promenade Publishing House Kft.
Város: Budapest