- A nagy Triple Channel Tesz: Hogyan lett egy hibás 24GB-os Kitből 1 "Tökéletes"
- XIAOMI Smart Air Purifier 4 Compact EU - légtisztító újabb okoseszköz a lakásban
- Optikai szál nem kell félnetek jó lesz, avagy a damil alapú hálózat
- A PC-m több mint 1 évtizedes története - AMD FX OC, 64GB RAM, ipari SSD - 1.rész
- Agglegénykonyha 15 – Néhány tavaszias recept
- Luck Dragon: Asszociációs játék. :)
- D1Rect: Nagy "hülyétkapokazapróktól" topik
- MasterDeeJay: Legolcsóbb "x99" gép építése. (folyamatban)
- sziku69: Fűzzük össze a szavakat :)
- sziku69: Szólánc.
- gban: Ingyen kellene, de tegnapra
- Luck Dragon: MárkaLánc
- f(x)=exp(x): A laposföld elmebaj: Vissza a jövőbe!
- MasterDeeJay: Low budget (50.000 forint) light gémer gép összerakása
- lezso6: Szekunder szarkazmus
-
LOGOUT
LOGOUT
Új hozzászólás Aktív témák
-
Sziasztok!
ide irok, mert talan ez aktivabb topic mint a manjaros
dell e6440 -en hasznalok manjarot. A problemam, hogy windows 10 -hez kepest sokkal rosszabb a hangminoseg, sokkal dobozosabb a hangja, meg halkabb is.
A gyarto honlapjan talaltam linux drivereket, de debianhoz, .deb csomagokkal.
Hogyan tudnam pl. a "oem-audio-hda-daily-lts-quantal-dkms_0.201305151525~precise1_all.deb" drivert telepiteni manjarora?
A csomagon beluli data.tar.gz -bol atmasoltam a fajlokat a megfelelo mappakba, volt restart is, de nem erzem, hogy tortent volna barmi is. -
Néztem egy traceroute -6 www.youtube.com -ot és a vége felé az összes címet kicsillagozza, lefuttattam NetworkManager, systemd-networkd és netctl alatt is, ugyanaz az eredmény. Ha ipv4-el nézem akkor nincs kicsillagozott cím. A youtube egyébként bejön működik, ipv6-os módban töltődik be a firefox kiegészítők szerint.
-
attilav2
őstag
Kíváncsiságból visszatértem a networkmanagerre, ki/bekapcsoltam egyes beállításokat a nmtui-ban, restartolgattam a service-t, végül bejött a youtube, működik ez csak rugdosni kell
Ezeket kapcsolgattam ki/be:
Require IPv6 addressing for this connectionIPv6 CONFIGURATION: Automatic/Automatic(dhcp only)
Végül mindent visszatéve alapra is ment a youtube.
Egyelőre marad a networkmanager, kíváncsi vagyok meddig működik yt. -
Nálam NetworkManager van, LAN oldalon IPv6 és IPv4 osztva OpenWrt alapú routerről. Igaz, WAN oldalon csak IPv4 van az UPC-nek köszönhetően. Systemd-networkd-vel is kapsz IPv6 címet? Én valami olyanra gondolok, hogy a youtube a Digi hálózatáról valamiért nem megy rendesen IPv6 alatt, ellenben IPv4-el igen.
Frawly: Nálam a wifivel sincs semmi gond. Ma is egész nap wifi-n lógok, itthonról dolgozom, így a céges VPN-re is folyamatosan csatlakozva vagyok (OpenVPN) délelőtt 10 óta.
-
Nálam NetworkManager van, LAN oldalon IPv6 és IPv4 osztva OpenWrt alapú routerről. Igaz, WAN oldalon csak IPv4 van az UPC-nek köszönhetően. Systemd-networkd-vel is kapsz IPv6 címet? Én valami olyanra gondolok, hogy a youtube a Digi hálózatáról valamiért nem megy rendesen IPv6 alatt, ellenben IPv4-el igen.
Frawly: Nálam a wifivel sincs semmi gond. Ma is egész nap wifi-n lógok, itthonról dolgozom, így a céges VPN-re is folyamatosan csatlakozva vagyok (OpenVPN) délelőtt 10 óta.
-
Nálam NetworkManager van, LAN oldalon IPv6 és IPv4 osztva OpenWrt alapú routerről. Igaz, WAN oldalon csak IPv4 van az UPC-nek köszönhetően. Systemd-networkd-vel is kapsz IPv6 címet? Én valami olyanra gondolok, hogy a youtube a Digi hálózatáról valamiért nem megy rendesen IPv6 alatt, ellenben IPv4-el igen.
Frawly: Nálam a wifivel sincs semmi gond. Ma is egész nap wifi-n lógok, itthonról dolgozom, így a céges VPN-re is folyamatosan csatlakozva vagyok (OpenVPN) délelőtt 10 óta.
-
Nem fogjátok elhinni mi volt a probléma.
A networkmanager! Openwrt routerem van és ipv4-ipv6 dualstackre van beállítva ez alapján: [link]
A networkmanager látszólag jól lekezeli mert ipv6 címet is oszt a gépnek, de lehet hogy a youtube esetén ez okozta a galibát, hogy esetleg a networkmanager rosszul kezelte a dual stacket, ez csak tipp. Most átváltottam a systemd-networkd.service -re a NetworkManager.service -t kilőttem, és láss csodát egyből bejött a youtube. -
A systemd-networkd -t átállítottam dual stackre, és így is bejön a youtube. Akkor a networkmanagerben kefélhettek el valamit valószínűleg.
Mondjuk kisebb hátrány hogy a systemd-networkd-nek nincs grafikus konfigoló sőt semmilyen konfigoló programja, nincs net ikon a kde-ben a tálcán forgalmi statisztikával. Nade ezzel együtt lehet élni.
-
Nem fogjátok elhinni mi volt a probléma.
A networkmanager! Openwrt routerem van és ipv4-ipv6 dualstackre van beállítva ez alapján: [link]
A networkmanager látszólag jól lekezeli mert ipv6 címet is oszt a gépnek, de lehet hogy a youtube esetén ez okozta a galibát, hogy esetleg a networkmanager rosszul kezelte a dual stacket, ez csak tipp. Most átváltottam a systemd-networkd.service -re a NetworkManager.service -t kilőttem, és láss csodát egyből bejött a youtube. -
Lehet hogy a nyílt ati driver okozza a galibát? A catalyst felrakása nekem bonyolult, még az X-et is downgradelni kell. Ha lesz új vga-m talán megoldódik a gond, majd egyszer ha lesz rá pénzem akkor nvidia-t választok. Lehetséges hogy a radeon 6670 túl régi? És romlik a támogatás színvonala?
-
LOL
Szerinted ha "csak úgy" probléma lenne ezzel nem ettől zengene az Arch fórum (nem ez)?
Mindemellett nekem sincs vele gondom, ezért tényleg felesleges volt felraknod...
De, szerintem is ettől zengene. De a kolléga valamiért nem akarja elhinni nekünk (pedig már mindannyian írtuk), hogy nem az Arch-ban kell keresni a hibát, akárhogy bizonygatjuk... Itt konkrétan kérte is (illetve kijelentette, hogy új telepítésnél tuti gond lesz), így gondoltam jó fej leszek. A telepítés pedig néhány percet vett el az életemből, aztán töröltem is a virtuális gépet.
-
Most kísérletképpen felraktam virtualboxban az Arch-ot. Az eredmény ugyanaz, nem megy a youtube firefox és chromium alatt, a fejléc bejön de az oldal üres fehérség.
Képernyőkép:
[link]
Ezt már nem lehet a 2d gyorsítás hibájára fogni, valódi és virtuális gépen is jelentkezik a hiba, újonnan telepített Arch-nál legalábbis egészen biztosan. Valamit nagyon elkeféltek, valami közös libraryt-t amit a komolyabb böngészők használnak, mint az opera firefox chromium.
Szeretem az Arch-ot, jó lenne ezt a hibát megoldani, jelentenem kellene a hibát, csak az angolom hiányos.
Régi telepítéseknél nem jelentkezik a hiba azért nem tapasztaljátok szerintem, próbáljatok új telepítést legalább virtuális gépbe és tuti hogy ti is belefuttok ebbe hibába.Most volt egy kis időm, így feldobtam Virtualbox-ba egy alap Arch-ot gnome-val és feltettem a chromiumot is. Az eredmény:
Szóval, nincs itt semmi gond...
-
Felraktam a tor browsert a honlapjáról: https://www.torproject.org/projects/torbrowser.html
Megy a youtube:
[link]Két dolog lehetséges, vagy a tor proxy miatt töltődik be a yt, és akkor az arch hálózatkezelésében van valami baki, vagy pedig a tor browser statikusan lett fordítva és mivel nem használja a rendszer libjeit emiatt küszöbölődik ki a hiba.
-
Felraktam a tor browsert a honlapjáról: https://www.torproject.org/projects/torbrowser.html
Megy a youtube:
[link]Két dolog lehetséges, vagy a tor proxy miatt töltődik be a yt, és akkor az arch hálózatkezelésében van valami baki, vagy pedig a tor browser statikusan lett fordítva és mivel nem használja a rendszer libjeit emiatt küszöbölődik ki a hiba.
-
Win10 et használok elsődlegesen, mind a chrome a firefox az edge böngészőkben bejön a youtube. Arch linux alatt viszont akármivel próbálkozok opera chromium firefox, csak az oldal fejléce és egy nagy fehérség jön be. Már kétszer újraraktam az Arch-ot, és ugyanez a hiba. Kubuntu 18.04 alatt szintén bejön a youtube minden böngésző alatt, még úgy is hogy rendszert frissítettem telepítés után és akkor sem jött elő a hiba, tehát az Arch valamelyik összetevőjében van a hiba.
-
Szerintem, ha proxyn keresztül (valamennyire) megjelenik az oldal, akkor nem az Arch-ban kell keresni a hibát. Én is inkább DNS szerverre gondolnék. Nézd meg, hogy Arch alatt mi a DNS szervered és nézd meg azokon a rendszereken is, ahol megjelenik az oldal.
Ha holnap lesz időm, feltolok egy Arch-ot virtuális gépre és megnézem.
-
-
-
Win10 et használok elsődlegesen, mind a chrome a firefox az edge böngészőkben bejön a youtube. Arch linux alatt viszont akármivel próbálkozok opera chromium firefox, csak az oldal fejléce és egy nagy fehérség jön be. Már kétszer újraraktam az Arch-ot, és ugyanez a hiba. Kubuntu 18.04 alatt szintén bejön a youtube minden böngésző alatt, még úgy is hogy rendszert frissítettem telepítés után és akkor sem jött elő a hiba, tehát az Arch valamelyik összetevőjében van a hiba.
-
Most kísérletképpen felraktam virtualboxban az Arch-ot. Az eredmény ugyanaz, nem megy a youtube firefox és chromium alatt, a fejléc bejön de az oldal üres fehérség.
Képernyőkép:
[link]
Ezt már nem lehet a 2d gyorsítás hibájára fogni, valódi és virtuális gépen is jelentkezik a hiba, újonnan telepített Arch-nál legalábbis egészen biztosan. Valamit nagyon elkeféltek, valami közös libraryt-t amit a komolyabb böngészők használnak, mint az opera firefox chromium.
Szeretem az Arch-ot, jó lenne ezt a hibát megoldani, jelentenem kellene a hibát, csak az angolom hiányos.
Régi telepítéseknél nem jelentkezik a hiba azért nem tapasztaljátok szerintem, próbáljatok új telepítést legalább virtuális gépbe és tuti hogy ti is belefuttok ebbe hibába. -
Most kísérletképpen felraktam virtualboxban az Arch-ot. Az eredmény ugyanaz, nem megy a youtube firefox és chromium alatt, a fejléc bejön de az oldal üres fehérség.
Képernyőkép:
[link]
Ezt már nem lehet a 2d gyorsítás hibájára fogni, valódi és virtuális gépen is jelentkezik a hiba, újonnan telepített Arch-nál legalábbis egészen biztosan. Valamit nagyon elkeféltek, valami közös libraryt-t amit a komolyabb böngészők használnak, mint az opera firefox chromium.
Szeretem az Arch-ot, jó lenne ezt a hibát megoldani, jelentenem kellene a hibát, csak az angolom hiányos.
Régi telepítéseknél nem jelentkezik a hiba azért nem tapasztaljátok szerintem, próbáljatok új telepítést legalább virtuális gépbe és tuti hogy ti is belefuttok ebbe hibába. -
Próbaképp felraktam a Kubuntu 18.04-et, természetesen ebben megy firefox és chromium alatt a youtube. Most újrainstalláltam az Arch-ot, és persze se a firefox se a chromium se a falkon nem viszi a youtubeot, helyette csak az oldal fejléce jön be és egy üres fehér lap.
Screenshot:
[link]Sejtésem szerint egy olyan libraryvel lehet gond amit a legtöbb böngésző használ, kivéve a midori-t mert abban megy a youtube. Lehet hogy ezt hibaként jelenteni kellene az Arch-nak? Sajnos az angol tudásom nem valami jó... Milyen infókat kell összegyűjteni egy hibajegyhez?
Akinek megy a youtube firefox és chromium alatt, milyen vga-t használ, és nyílt vagy zárt driverrel?
-
Sziasztok!
Mire lehet számítani egy AMD C-70 procival szerelt kis Acer netbook és Arch Linux találkozásakor?
[link]
A gépben 4 GB memória van, nem volt még alkalmam kipróbálni. Van-e tapasztalat a grafikus vezérlő működéséről és úgy általában a Linuxos élményről erről a procival.
Általános használatra lenne a gép, a gyári belassúlt, használhatalan Windowst cserélnénk Linuxra. -
V5 121?
Nekem ilyenem van debiannal. Hasznalhato a gep, de lassu, pedig SSD-t raktam bele.
Akkor erezni a lassulast, amikor az alkalmazasok (pl. bongeszo) elindulnak, vagy tobb tab meg van nyitva, animalt reklamok szaggatnak, pl. a mobilarena mostani fooldalan levo vodaf*ne reklam elegge akad.Azert nem olyan gaz, hasznalhato. Lenyeg, hogy egyszerre egy dolgot csinalj es neha igy is turd a varakozasokat.
Az arch nalam nem volt nyero ezen a gepen, mert az uj kernelekben a regi radeon driver neha el tud romolni, de azert nem veszes az sem.
A debian 4.9-es kernele mindent tud, amit ez a GPU tud.
Kulon munkat igenyel mindket disztron a 3D gyorsitas bekapcsolasa pl. bongeszokben. Erre oda kell figyelni, mert sokat segit.Ezen kivul az IGP kepes regi jatekokat (pl. Quake 3) tokelesen elvinni, de ujabbakkal is elbir.
Itt a proci a szuk keresztmetszet, a GPU sokkal jobb, mint gondolna az ember.Amire oda kell figyelni ennel a gepnel linux eseten:
- tapipad indulasnak ki van kapcsolva
- tapipadra koppintas nem muxik alapbol
- wifi/BT alapbol nem megyDebian alatt ezekre mind van megoldas, Arch eseten nem tudom.
-
Sziasztok!
Mire lehet számítani egy AMD C-70 procival szerelt kis Acer netbook és Arch Linux találkozásakor?
[link]
A gépben 4 GB memória van, nem volt még alkalmam kipróbálni. Van-e tapasztalat a grafikus vezérlő működéséről és úgy általában a Linuxos élményről erről a procival.
Általános használatra lenne a gép, a gyári belassúlt, használhatalan Windowst cserélnénk Linuxra. -
Próbaképp felraktam a Kubuntu 18.04-et, természetesen ebben megy firefox és chromium alatt a youtube. Most újrainstalláltam az Arch-ot, és persze se a firefox se a chromium se a falkon nem viszi a youtubeot, helyette csak az oldal fejléce jön be és egy üres fehér lap.
Screenshot:
[link]Sejtésem szerint egy olyan libraryvel lehet gond amit a legtöbb böngésző használ, kivéve a midori-t mert abban megy a youtube. Lehet hogy ezt hibaként jelenteni kellene az Arch-nak? Sajnos az angol tudásom nem valami jó... Milyen infókat kell összegyűjteni egy hibajegyhez?
Akinek megy a youtube firefox és chromium alatt, milyen vga-t használ, és nyílt vagy zárt driverrel?
-
Az Arch Wikinek ezt a cikkét nézd.
A lényeg, hogy fel kell lennie csatolva a EFI partíciónak, tipikusan /boot-ként. Ekkor arch-chrootban kiadod a bootctl --path=/boot install parancsot, és felteszi az EFI partícióra az Arch indítófájlait. Ezzel nincs vége, mert szerkeszteni kell egy konfigfájlt is, a /boot/loader/loader.conf néven, sőt, kell egy conf fájl a /boot/loader/entries/-be is, ennek a neve szabadon választott, de össze kell egyeztetni a loader.conf-ban írtakkal. Én is így csináltam meg az Arch EFI bootját, csak X220-on. Működik. Úgy is, hogy ha Win10 van mellette.
Ha elakadnál, akkor nyugodtan kérdezz még, lehetőleg a hibaüzenettel együtt, amit kiírt.
-
Nincs hátránya, de Arch-nál felesleges, mivel ott eleve live iso-t töltesz be, és igaz nincs grafikus felület, de pl. a cfdisk text user interface-t tud nyújtani, ami legalább olyan használható, mint egy grafikus tool. Annyi, hogy utána a csatolásokat is neked kell csinálni, mivel az Archban nincs telepítő, de pont ez a poén benne, hogy mindent te csinálsz kézzel, látod mi futott le, mit tettél fel, így nincs az, hogy nem tudod miért nem megy. Különösen áll ez az UEFI bootra, amit a telepítők 90+%-a el szokott qrni, pedig a világ legegyszerűbb dolga, ha egyszer kézzel telepítve Wiki alapján megérted hogyan működik.
Ha nagyon kell akkor live rendszerre is fel lehet rakni gpartedet, nem kell is cfdisk-el vacakolni.
-
Telepitettem mar (egyszer) Arch-ot, de mivel nem sajat gep volt, es windows particio is volt mellette, es nem volt meg tapasztalatom az Arch particionalojaval, igy bolcsebbnek lattam hipszterkedes helyett az altalam ismert modszerrel menni, es nem elcseszni mas rendszeret.
Legkozelebbi telepitesnel mar magabiztosabb leszek.
-
Nincs hátránya, de Arch-nál felesleges, mivel ott eleve live iso-t töltesz be, és igaz nincs grafikus felület, de pl. a cfdisk text user interface-t tud nyújtani, ami legalább olyan használható, mint egy grafikus tool. Annyi, hogy utána a csatolásokat is neked kell csinálni, mivel az Archban nincs telepítő, de pont ez a poén benne, hogy mindent te csinálsz kézzel, látod mi futott le, mit tettél fel, így nincs az, hogy nem tudod miért nem megy. Különösen áll ez az UEFI bootra, amit a telepítők 90+%-a el szokott qrni, pedig a világ legegyszerűbb dolga, ha egyszer kézzel telepítve Wiki alapján megérted hogyan működik.
-
Sziasztok! Szeretnék kicsit ismerkedni az Arch-al, sok jót hallottam már róla. Jelenleg a laptopomra szeretném telepíteni (ThinkPad X230), most van rajta dualbootban egy Windows10 és egy Ubi 18.04. Viszont a partícionálással totál elakadtam. Szeretném róla az uborkát letakarítani és a helyére rakni az Archot, viszont fogalmam sincs, hogy kéne. UEFI-t használok a laptopon, a Windows már megcsinálta az EFI partíciót, innen viszont nem tudom merre tovább. A wikin valószínűleg a bénaságom miatt nem tudok eligazodni, tudna valaki segíteni, pontosan merre induljak el?
Előre is köszi!
-
Sziasztok! Szeretnék kicsit ismerkedni az Arch-al, sok jót hallottam már róla. Jelenleg a laptopomra szeretném telepíteni (ThinkPad X230), most van rajta dualbootban egy Windows10 és egy Ubi 18.04. Viszont a partícionálással totál elakadtam. Szeretném róla az uborkát letakarítani és a helyére rakni az Archot, viszont fogalmam sincs, hogy kéne. UEFI-t használok a laptopon, a Windows már megcsinálta az EFI partíciót, innen viszont nem tudom merre tovább. A wikin valószínűleg a bénaságom miatt nem tudok eligazodni, tudna valaki segíteni, pontosan merre induljak el?
Előre is köszi!
-
Ha kikapcsolom a hardveres gyorsítást a chromiumban akkor sem jelenik meg a youtube.
Opera alatt is fehérséget ad a youtube-ra, sőt a falkon browser is ugyanezt a tünetet produkálja.
Tehát a firefox chromium opera falkon browserek alatt csak a yt fejléce jelenik meg egy üres fehér oldallal. Csak a midori hozza be a yt-ot.
dailymotion rendesen megy firefox és chrome alatt, sőt a vimeo is.
Inxi kimenete:[xfce@attilav aur]$ inxi -Fxxx
System:
Host: attilav Kernel: 4.14.48-1-lts x86_64 bits: 64 compiler: gcc v: 8.1.1
Desktop: Xfce 4.12.4 tk: Gtk 2.24.32 info: xfce4-panel dm: startx
Distro: Arch Linux
Machine:
Type: Desktop Mobo: ASUSTeK model: A88X-PLUS v: Rev X.0x
serial: <root required> UEFI [Legacy]: American Megatrends v: 3003
date: 03/10/2016
CPU:
Topology: Quad Core model: AMD Athlon X4 860K bits: 64 type: MCP
arch: Steamroller rev: 1 L2 cache: 2048 KiB
flags: lm nx pae sse sse2 sse3 sse4_1 sse4_2 sse4a ssse3 svm
bogomips: 29525
Speed: 1695 MHz min/max: 1700/3700 MHz Core speeds (MHz): 1: 1695 2: 1690
3: 1695 4: 1694
Graphics:
Card-1: AMD Turks XT [Radeon HD 6670/7670] driver: radeon v: kernel
bus ID: 01:00.0 chip ID: 1002:6758
Display: server: X.Org 1.20.0 driver: radeon resolution: 1920x1080~60Hz
OpenGL: renderer: AMD TURKS (DRM 2.50.0 / 4.14.48-1-lts LLVM 6.0.0)
v: 3.3 Mesa 18.1.1 compat-v: 3.1 direct render: Yes
Audio:
Card-1: AMD FCH Azalia driver: snd_hda_intel v: kernel bus ID: 00:14.2
chip ID: 1022:780d
Card-2: AMD Turks HDMI Audio [Radeon HD 6500/6600 / 6700M Series]
driver: snd_hda_intel v: kernel bus ID: 01:00.1 chip ID: 1002:aa90
Sound Server: ALSA v: k4.14.48-1-lts
Network:
Card-1: Realtek RTL8111/8168/8411 PCI Express Gigabit Ethernet
driver: r8169 v: 2.3LK-NAPI port: d000 bus ID: 05:00.0 chip ID: 10ec:8168
IF: enp5s0 state: up speed: 100 Mbps duplex: full mac: f0:79:59:6c:c6:58
Drives:
HDD Total Size: 618.55 GiB used: 10.32 GiB (1.7%)
ID-1: /dev/sda vendor: Samsung model: SSD 840 Series size: 111.79 GiB
speed: 6.0 Gb/s serial: S19HNEBD353510Y rev: AB0Q scheme: MBR
ID-2: /dev/sdb vendor: AMD Radeon model: R3SL480G size: 447.13 GiB
speed: 6.0 Gb/s serial: E201607070040523 rev: 2C scheme: GPT
ID-3: /dev/sdc vendor: A-Data model: SP600 size: 59.63 GiB speed: 6.0 Gb/s
serial: 2E4620012337 rev: 5.2 scheme: MBR
Partition:
ID-1: / size: 58.44 GiB used: 10.32 GiB (17.7%) fs: ext4 dev: /dev/sdc1
Sensors:
System Temperatures: cpu: 14.5 C mobo: N/A gpu: radeon temp: 48 C
Fan Speeds (RPM): cpu: 0
Info:
Processes: 147 Uptime: 4h 04m Memory: 7.74 GiB used: 1.67 GiB (21.6%)
Init: systemd v: 238 Compilers: gcc: 8.1.1 Shell: bash v: 4.4.23
running in: xfce4-terminal inxi: 3.0.10 -
Xfce-Dusk témát használok. Az utóbbi időben ahogyan jönnek a frissítések, egyre több helyen nem használja a beállított témát. Ez mivel van összefüggésben? GTK? Most átraktam Adwaita-dark témára, ezzel most jó. Annyi a különbség, hogy ez nem fekete hanem szürke. Picit zavar. Van valami jó fekete téma ami használható?
-
Ilyet még nem tapasztaltam!
Arch alatt Firefox és a Chromium egy üres fehér képernyőt jelenít meg a youtube helyett, csak a fejléc látszik az oldalból, a midori simán behozza a youtube-ot. Windows alatt is megy a youtube firefox és chrome alatt. Ilyet még nem pipáltam! Milyen hiba ez?
Képernyőkép:
[link] -
Lehet, hogy lényegtelen dolog. De lehet fontos is. Leírom.
Szóval többször neki kezdtem a pamac-el feltenni ezt a js52 csomagot. Aztán az itt kapott link segítségével feltudtam frissíteni.
Viszont én root mc-vel kerestem a fájlt és töröltem is. Volt még egy ugyanilyen nevű fájl is csak az @ karakterrel kezdődött és a szine is eltért mc szerint az előtte lévőtől. Töröltem azt is. Majd sudo pacman -Syu paranccsal frissítettem a rendszert.
Szóval ez a @ elejű fájl nem olyankor keletkezik, ha szöveges fájlt kezdünk módosítani? Lehet törölni akarta a szkript, de nem ment végbe. Vagy a szkriptben felülírás van, nem törlés? -
Nem baj, hogy kérdeztél, megvan legalább itt is. Én is belefutottam, de magamtól rájöttem, ha ez a fájl létezik, akkor szimplán csak törölni kell rm paranccsal. Utána szépen megy a frissítés. Majdnem beírtam én is ide figyelemfelhívásnak, de aztán megjelent az Arch oldalán is a hírekben, aztán úgy voltam vele, hogy az elég figyelmeztetés mindenkinek.
Egyébként nem értem, hogy a csomagkészítő milyen nem vettem fel scriptbe, ha létezik a fájl, akkor telepítés során automatikusan törlődjön.
-
Sziasztok!
A következő csomagfrissítési hibába futottam, a js52 csomag frissítésekor.
js52 (JavaScript interpreter and libraries-Version 52)ütköző fájlok:
js52 /usr/lib/libmozjs-52.so.0 már létezik a fájlrendszerbenAz 52.7.3-1 csomag frissűlne 52.7.3-2 verzióra.
Firefoxot használok, annak szükséges. Előjött már másnál is ez a hiba?https://www.archlinux.org/news/js52-5273-2-upgrade-requires-intervention/
Célszerű ilyenkor a híreket vagy a hivatalos fórumot megnézni. Ha van valami hiba, valószínűleg mások már megoldást is találtak a problémádra.
-
A systemd-analyze outputját felejtsd el, bullshiteket írogat. Stopperral mérd. A bootmenüben ahogy indítod a rendszerd, onnan indítsd a mérést, és ott állítsd le, ahogy minden ikon az asztalon, tálcán, stb. megjelent.
Az a HP Elitebook, ami neked van, elviekben UEFI-s és támogatja a GPT-t. Az UEFI-ben állítsd át a Boot type-ot vagy Legacy + EUFI-re, vagy UEFI-re. Tessék csak szépen próbálkozni vele.
A telepített rendszer csak akkor fog az UEFI-ben látszódni, ha az OS megtette a szükséges bejegyzést magában az UEFI-ben. Valószínű jó az a GPT-s átállás, csak az OS telepítésekor az UEFI boot részletei nem megfelelően lettek beállítva, ezért nem bootol.
Jó az, minek stoppereljem, érezhetően kb annyi az így is.
Nincs GPT, mint említettem, felment a teszt Mint C és első dolgom volt gpartedben csinálni 4 elsődleges partíciót próbaképpen. A negyediknél jött az ismerős ablak, hogy csak 4 elsődleges ......
Szóval bootol ez rendesen, csak nincs választási lehetőség, mert desktopon van, amikor pendrive-ról bootolok.
Annyira látszik, hogy semmi nem akarja ezt az UEFI-t!![;]](//cdn.rios.hu/dl/s/v1.gif)
Mondhatnám azt is, hogy fák jú GPT/UEFI ! -
Hasznosak ezek az optibay-ek valóban. Mint Cinnamon amúgy most sem túl gyors bootban:
ubyegon@HP-EliteBook-8470p ~ $ systemd-analyze
Startup finished in 5.315s (kernel) + 1.534s (userspace) = 6.849sKipróbálom valamelyik Arch klónnal, de nem pure Arch lesz, mert már megszoktam, hogy 5-10 perc egy full install.
A GPT-re átállás nem sikerült, pedig live alól inicializáltam, el is tűnt minden, de egyrészt a HP biosában nem lehetett választani, majd körül kell benne néznem, másrészt MBR maradt. Lehet, hogy bios is régi ebben a Elitbookban.
Most jött ki friss Antergos, érdemes bepróbálkozni vele? Anno elég gyatra volt a Inchi nevű telepítősegéd benne.
Meglepő, de Mint Cinnamonnal 500 mega alatt maradt a memória (boot után 423MB), FF 3 lapjával lépte át az 1gigát. Meglátjuk, mit ad ehhez az Arch alap.
A Cin 3.8 a Mint 19 alatt simán kiröhögi a KDE-t, ha most ennyit zabál csak.
-
Márpedig szerencsénk van, mert a DVD meghajtót a laptopból úgy kivágjuk, hogy csak nyekken. Konkrétan a bal vállunk felett hajítjuk hátrafelé. Persze nem mindenhol opció, mert az X220-ban mivel szubnotesz, eleve nincs ODD, így nincs az, hogy a HDD-t átrakod a helyére. Meg a 2. SSD sem azért kéne nekem, mert annyira szűkében vagyok a tárhelynek, csak inkább szeretném külön lemezen tudni a két OS-t.
Az 2,7 másodperces antergosos Cinnamon-boot az nagyon szép. Lehet ahhoz jobb gép kéne. NVMe-vel is max csak ilyen 0,1-0,5 mp-eket lehet lefaragni, inkább a procin, buszsebességen múlik, nem az SSD-n. Esetleg ha a kernelben a hardverdetektálást fel lehetne gyorsítani nem használt komponensek detektálásának a letiltásával.
Hasznosak ezek az optibay-ek valóban. Mint Cinnamon amúgy most sem túl gyors bootban:
ubyegon@HP-EliteBook-8470p ~ $ systemd-analyze
Startup finished in 5.315s (kernel) + 1.534s (userspace) = 6.849sKipróbálom valamelyik Arch klónnal, de nem pure Arch lesz, mert már megszoktam, hogy 5-10 perc egy full install.
A GPT-re átállás nem sikerült, pedig live alól inicializáltam, el is tűnt minden, de egyrészt a HP biosában nem lehetett választani, majd körül kell benne néznem, másrészt MBR maradt. Lehet, hogy bios is régi ebben a Elitbookban.
Most jött ki friss Antergos, érdemes bepróbálkozni vele? Anno elég gyatra volt a Inchi nevű telepítősegéd benne.
Meglepő, de Mint Cinnamonnal 500 mega alatt maradt a memória (boot után 423MB), FF 3 lapjával lépte át az 1gigát. Meglátjuk, mit ad ehhez az Arch alap.
A Cin 3.8 a Mint 19 alatt simán kiröhögi a KDE-t, ha most ennyit zabál csak.
-
Ha minimalista WM-mel használod, akkor a bootidő leszorítható 4 mp. környékére egy sima SATA3 SSD-vel. Ez Minten elérhetetlen.
Szép is lenne, ha WM-et kéne használni, hogy megfelelő bootidő legyen. Amúgy igazad van, Mint Cinnamonnal 5 sec alá nem ment a bootidő, Debian Cinnamonnal viszon 3 sec volt, pár éve kipróbáltam Antergossal, az 2,7 sec bootidőt hozott. Mindenütt a leglomhább DE volt fenn, szóval nem kell ide WM.
Jó dolog az SSD, én is sokáig küzdöttem ellene, mert minek az, ha WD Black-et használok rendszer alatt, de szerencsére már megvannak, így viszont a leggyorsabb, legstabilabb HDD-t tárolásra használom, ha ezt előbb tudom, dupla tárhelyet vehettem volna az áráért.
Desktopnál lehet a legjobban megoldani, mert ott valóban elég egy 10 rugós 12GB-os SSD és xTB HDD tárolásra. Laptopnál kicsit nehezebb ezt megoldani, ha csak ki nem dobod a DVD írót.
-
Óó, ne aggódj, ha Archot teszel rá, azt azért SSD-n is érezni. Ha minimalista WM-mel használod, akkor a bootidő leszorítható 4 mp. környékére egy sima SATA3 SSD-vel. Ez Minten elérhetetlen.
Ennek az SSD-korszaknak már nagyon ideje volt, a HDD-k nagyon visszafogták már a mai gépeket. Főleg a Win10-nél fontos az SSD, mert mocskosul tekeri a lemezt, részben az NTFS fossága miatt, másrészt a registry írása, olvasása is elég lassú. Linux fronton el lehet lenni HDD-vel, de az SSD ott is sokat gyorsít. Ma már nem éri meg spórolni rajta, ha más nem egy olcsó 120 gigás Kingston A400-at be kell szerezni, vannak boltok, ahol 10 ezer alatt megkapod, alig drágább, mint egy nagyobb pendrive. Lesz ez még olcsóbb, ha lemennek reálisabb szintre az memória/SSD árak.
Ha minimalista WM-mel használod, akkor a bootidő leszorítható 4 mp. környékére egy sima SATA3 SSD-vel. Ez Minten elérhetetlen.
Szép is lenne, ha WM-et kéne használni, hogy megfelelő bootidő legyen. Amúgy igazad van, Mint Cinnamonnal 5 sec alá nem ment a bootidő, Debian Cinnamonnal viszon 3 sec volt, pár éve kipróbáltam Antergossal, az 2,7 sec bootidőt hozott. Mindenütt a leglomhább DE volt fenn, szóval nem kell ide WM.
Jó dolog az SSD, én is sokáig küzdöttem ellene, mert minek az, ha WD Black-et használok rendszer alatt, de szerencsére már megvannak, így viszont a leggyorsabb, legstabilabb HDD-t tárolásra használom, ha ezt előbb tudom, dupla tárhelyet vehettem volna az áráért.
Desktopnál lehet a legjobban megoldani, mert ott valóban elég egy 10 rugós 12GB-os SSD és xTB HDD tárolásra. Laptopnál kicsit nehezebb ezt megoldani, ha csak ki nem dobod a DVD írót.
-
A manóba, tényleg kevesebb nullát írtam, szokni kell még ezt a 14" -os ketyerét vagy túl gyorsan írtam.
Szóval nyugodtan meg lehet venni ilyen kifutó SSD-ket olcsón
Az Intel 520 esetén ez különösen jó üzlet volt, mert pár évvel ezelőtt magasan a legjobb consumer SSD volt megbízhatóság terén és gyakorlatilag feleződött az új eszköz ára az új modell miatt. A Furyra meg használtan elég nehéz volt lecsapni, nagyon ajánlott még a legtöbb új modellel szemben is, a milyen SSD-t....topikból infóztam vétel előtt.
Annyira jók ezek az SSD-k, hogy ha nem Arch-ot rakok rá, akkor is repül a rendszerem!
-
Jó neked, hogy ilyen 10-12 gigás SSD-kkel beéred, én 480-525 gigás kategóriában nézelődök
Tudom, hogy elgépelted, gondolom a 12-es az 120 gigás akart lenni, az Intelnél meg a 10 az lehet 120 vagy 180 giga?Abban igazad van, hogy átlag felhasználó, amilyen én is vagyok, elvan planár TLC-vel is, mivel nem ír annyit rá, hogy számítson a TLC, 3D TLC, MLC írásterhelhetőségi különbsége. Amúgy is a vezérlő fárad el, nem a cellák. Szóval nyugodtan meg lehet venni ilyen kifutó SSD-ket olcsón, nem baj az se, ha planár TLC, csak sokat nem szabad érte adni.
A 16K-s align onnan jön, hogy 3D TLC-nél 16K-s lapokba vannak a cellák szervezve, nem 4K-ba. Ez az átlag usert nem érinti, mivel a modern particionálóprogik és telepítők továbbra is úgy alignálnak, hogy mindenfajta eszköznek megfeleljen tekintet nélkül a fizikai szektorméretre, az OS felé meg tudják a 0,5K-s módot emulálni (egy szektor 512 bájt sémát). A lényeg, hogy ilyen DOS-os meg meg Win9x-es progikkal nem szabad particionálni, meg XP és annál régebbi Windows telepítőjével sem, azok a partíciókat 63-mal osztható szektoron kezdik, mivel a HDD-ken egy sávban 63 szektor volt. Ez az SSD-nek nem jó, jelentősen belassul tőle.
A manóba, tényleg kevesebb nullát írtam, szokni kell még ezt a 14" -os ketyerét vagy túl gyorsan írtam.
Szóval nyugodtan meg lehet venni ilyen kifutó SSD-ket olcsón
Az Intel 520 esetén ez különösen jó üzlet volt, mert pár évvel ezelőtt magasan a legjobb consumer SSD volt megbízhatóság terén és gyakorlatilag feleződött az új eszköz ára az új modell miatt. A Furyra meg használtan elég nehéz volt lecsapni, nagyon ajánlott még a legtöbb új modellel szemben is, a milyen SSD-t....topikból infóztam vétel előtt.
Annyira jók ezek az SSD-k, hogy ha nem Arch-ot rakok rá, akkor is repül a rendszerem!
-
Az msata SSD tényleg drágább, 15 alatt nem is nagyon van jó minőségű 12GB-os. Amúgy jelennek meg még újak ezzel a csatolóval is, van még időd válogatni.
Valóban, Linuxon pl. a fájlrendszer is eleve tartalékol, az ext4-nél valami 5% ez
Ez ki is ment a fejemből, ebből is látszik, milyen elavult a Win fájlrendszere......
3D TLC-s SSD-kről épp nemrég olvastam, nem olcsók, átlagfelhasználó elvan egy mezei SSD-vel is, én az elsőt pont akkor vettem, mikor kifutó lett az Intel 520 10GB, a laptopba meg vettem egy használt Fury 120-ast. Ezek elketyegnek még jó darabig. 16K-s meg a többi align-ról még nem is hallottam, ezért jó, hogy legalább valaki követi az SSD totyikot!
Jó neked, hogy ilyen 10-12 gigás SSD-kkel beéred, én 480-525 gigás kategóriában nézelődök
Tudom, hogy elgépelted, gondolom a 12-es az 120 gigás akart lenni, az Intelnél meg a 10 az lehet 120 vagy 180 giga?Abban igazad van, hogy átlag felhasználó, amilyen én is vagyok, elvan planár TLC-vel is, mivel nem ír annyit rá, hogy számítson a TLC, 3D TLC, MLC írásterhelhetőségi különbsége. Amúgy is a vezérlő fárad el, nem a cellák. Szóval nyugodtan meg lehet venni ilyen kifutó SSD-ket olcsón, nem baj az se, ha planár TLC, csak sokat nem szabad érte adni.
A 16K-s align onnan jön, hogy 3D TLC-nél 16K-s lapokba vannak a cellák szervezve, nem 4K-ba. Ez az átlag usert nem érinti, mivel a modern particionálóprogik és telepítők továbbra is úgy alignálnak, hogy mindenfajta eszköznek megfeleljen tekintet nélkül a fizikai szektorméretre, az OS felé meg tudják a 0,5K-s módot emulálni (egy szektor 512 bájt sémát). A lényeg, hogy ilyen DOS-os meg meg Win9x-es progikkal nem szabad particionálni, meg XP és annál régebbi Windows telepítőjével sem, azok a partíciókat 63-mal osztható szektoron kezdik, mivel a HDD-ken egy sávban 63 szektor volt. Ez az SSD-nek nem jó, jelentősen belassul tőle.
-
Valóban, Linuxon pl. a fájlrendszer is eleve tartalékol, az ext4-nél valami 5% ez, ami ha rájön az overprovisioningre, akkor az már magában elegendő lehet. Ezt a szabad hely hagyása igazából windowsos usereknél fontos.
Második OS futtatására venném, jelenleg egy külső SSD-t használok erre, de az kicsi (64 GB), és idegesít, hogy lóg ki a gépből USB-SATA átalakítós kanócon. A ThinkPad X220-amba már benne van egy SATA SSD, így már csak mSATA-nak marad hely. Viszont ez egy elavult, kifutott csatolófelület, egyre inkább nem kapni, ami van, az is drága.
A 3D TLC-s SSD-k még a 4K AF-es HDD-knél is jobbak, mert 16K-s alignálást igényelnek. A több pedig jobb
Persze nem kell aggódni, mert a modern particionálóprogramok, OS telepítők 1024K-n alignálnak (2048-cal osztható szektoron kezdődnek a partíciók, azaz egész MB-os határon), ami megfelel az 1K, 2K, 4K, 8K, 16K, 32K, 64K, 128K, 256K, 512K, 1024K-s alignálásnak is, mivel ezekkel is osztható maradék nélkül.Az msata SSD tényleg drágább, 15 alatt nem is nagyon van jó minőségű 12GB-os. Amúgy jelennek meg még újak ezzel a csatolóval is, van még időd válogatni.
Valóban, Linuxon pl. a fájlrendszer is eleve tartalékol, az ext4-nél valami 5% ez
Ez ki is ment a fejemből, ebből is látszik, milyen elavult a Win fájlrendszere......
3D TLC-s SSD-kről épp nemrég olvastam, nem olcsók, átlagfelhasználó elvan egy mezei SSD-vel is, én az elsőt pont akkor vettem, mikor kifutó lett az Intel 520 10GB, a laptopba meg vettem egy használt Fury 120-ast. Ezek elketyegnek még jó darabig. 16K-s meg a többi align-ról még nem is hallottam, ezért jó, hogy legalább valaki követi az SSD totyikot!
-
OP-re 8-27 százalékot célszerű tartalékolni, de ez bőven megvan a gyári lefoglalással is, mert nem valószínű, hogy 100 százalékig teletömöd a többi részt a meghajtón. De ha mégis, a 120GB-os még így is jól lesz.
Sokan totál értelmetlenül hagynak még pluszban ki helyet, mert nem tudják, hogy az ő SSD-jük is 128-as a valóságban.HDD-ből az AF-es a jó, az már 4k-s, WD1003FZEX például.
Ha valaki akkora idióta, hogy csurig pakolja a meghajtóját, akár HDD-n is.......
Amúgy msata-s SSD-t tárolásra akarsz venni a laptopodba? (az árát említetted, ezért gondoltam)
ATA jelszavas titkosítás ez jó móka, ha elfelejted a jelszót.
Valóban, Linuxon pl. a fájlrendszer is eleve tartalékol, az ext4-nél valami 5% ez, ami ha rájön az overprovisioningre, akkor az már magában elegendő lehet. Ezt a szabad hely hagyása igazából windowsos usereknél fontos.
Második OS futtatására venném, jelenleg egy külső SSD-t használok erre, de az kicsi (64 GB), és idegesít, hogy lóg ki a gépből USB-SATA átalakítós kanócon. A ThinkPad X220-amba már benne van egy SATA SSD, így már csak mSATA-nak marad hely. Viszont ez egy elavult, kifutott csatolófelület, egyre inkább nem kapni, ami van, az is drága.
A 3D TLC-s SSD-k még a 4K AF-es HDD-knél is jobbak, mert 16K-s alignálást igényelnek. A több pedig jobb
Persze nem kell aggódni, mert a modern particionálóprogramok, OS telepítők 1024K-n alignálnak (2048-cal osztható szektoron kezdődnek a partíciók, azaz egész MB-os határon), ami megfelel az 1K, 2K, 4K, 8K, 16K, 32K, 64K, 128K, 256K, 512K, 1024K-s alignálásnak is, mivel ezekkel is osztható maradék nélkül. -
Na, látod, azt nem tudtam, hogy a tartalék területet overprovisioningnek hívják. Az viszont vitatott, hogy egy 120 gigás meghajtónál 8 giga elég-e. Valamennyit biztosan segít, de hogy milyen mértékben, az vitatható.
Azt én sem szoktam javasolni, hogy particionálatlan helyet hagyjunk. Csak abban a speciális esetben jó, ha nagyon laikus felhasználóhoz kerül az SSD, akinek nem lesz adattárolási fegyelme, és állandóan csurig pakolva használja az SSD-t. Aki viszont nem ilyen, ne hagyjon particionálatlan helyet az SSD-n, csak arra figyeljen, hogy ne legyen állandóan csurig, legyen rajta tartósan legalább kb. 10% hely (néha be lehet menni ezalá, de ne legyen tartós állapot). Jobb, ha ez a szabad terület a partíción van meg, mintha partíción kívül. A hatása a wear levelingre mindkettő megoldásnak azonos.
Már a HDD-k sem örültek, ha csurig voltak töltve. Pedig azoknál nincs se TRIM, se wear leveling. Még a 4K alignálás sem csak a SSD-k specialitása. Igazából az SSD úgy kell használni, mintha HDD lenne. Egy plusz dologra kell figyelni, a TRIM menjen, meg pár havonta ránézni a SMART adatokra, nehogy valami bugos program írási kergekórt kapva szétírja. Meg ugye defragolni nem kell, de ez sem gond, mert Win7 és attól felfelé már alapból nem defragolja, Linuxon meg sose volt erőltetve a felhasználó tudtán kívül a defrag, ott neked kell futtatni, nincs az, hogy véletlenül lefutott, mert nem akadályoztad meg, elfelejtetted letiltani.
Így ha lehet is az SSD-vel bonyodalom, az csak a TRIM körül lehet, esetleg az ATA jelszavas titkosítás terén (de az meg megint lehet HDD-nél is).
OP-re 8-27 százalékot célszerű tartalékolni, de ez bőven megvan a gyári lefoglalással is, mert nem valószínű, hogy 100 százalékig teletömöd a többi részt a meghajtón. De ha mégis, a 120GB-os még így is jól lesz.
Sokan totál értelmetlenül hagynak még pluszban ki helyet, mert nem tudják, hogy az ő SSD-jük is 128-as a valóságban.HDD-ből az AF-es a jó, az már 4k-s, WD1003FZEX például.
Ha valaki akkora idióta, hogy csurig pakolja a meghajtóját, akár HDD-n is.......
Amúgy msata-s SSD-t tárolásra akarsz venni a laptopodba? (az árát említetted, ezért gondoltam)
ATA jelszavas titkosítás ez jó móka, ha elfelejted a jelszót.
-
Nincs nekem ezzel gondom, inkább örülök, ha valaki képben van az SSD dolgaival kapcsolatban, mert bár már nem annyira féltjük, mert tudjuk, hogy mindent kibír, a vezérlő adja meg magát úgyis. Ettől még jó, ha tudja a felhasználó, mi micsoda. Hányan tudják szerinted, mi a különbség a 120 és 128 gigás meghajtók között? Mi az overprovisioning?
Te és sokan tudjátok ezeket, de legtöbben nem. Ez viszont helytelen, de legalábbis értelmetlen felhasználói szokásokat alakíthat ki! Feleslegesen hagynak particionálatlan területeket például előbbiek, de akár a trim miatt is.
Szóval csak legyél képben! Én már nagyon nem vagyok, nem mint ha.....(szerintem, mivel én sem értek hozzá)
-
Pedig ugyanazt mondjuk, azért nem volt vita. Azt is elismertem, hogy pontatlanul használtam a fogalmakat, ebben sem volt vita. A lényeg lényegén meg amúgy sem változtat, Samu 850-en nem jó ötlet a discard TRIM-et erőltetni, és az is tény, hogy nem veszteni semmit a hiányával, de ha ez utóbbiakkal nem értesz egyet, cáfolhatsz nyugodtan. Érdemi cáfolatra gondoltam, nem elnevezéseken lovaglásra, azon túlvagyunk.
De ha már Gyurmafigura paprikás kedvében van, akkor mégis húznám még azzal az idegeit, hogy a security erase is trimmelés lényegében, és annak is van kétféle változata, egy rövidebb, és a meghajtó teljes felületén végrehajtott. A rövidebb azoknál a meghajtóknál lehetséges, amelyek támogatnak öntitkosítást. De a security erase-t nem a kernel intézi, hanem az SSD vezérlője, ha erre kap parancsot.
Júbájgön: az EFI partíció FAT32-es, bár az elméletileg nem igényel trimmelést, mert egyszer ráírod, ami rákerül, utána nem nagyon történik róla törlés, csak néha felülírás kernelfrissítéskor (initramfs, fallback). Egyébként másra nem használnék FAT-ot, NTFS partícióm sincs (jó, vagy egy nyomorult darab egy külső meghajtón). Viszont nem kerülne semmibe lefejleszteni, hogy az fstrim vigye a FAT-ot is, soha nem tudni mikor jön jól, elfér, ha tudja. Nem lenne bonyolult implementálni, lényegében a FAT a legegyszerűbb létező fájlrendszer a swap után, már ha utóbbit lehet fájlrendszernek tekinteni.
Az fstrim-nél meg nem értem, hogy miért lenne nekem kötelességem rájönni a futási sebesség rejtélyeire. Tippem persze van. Első futáskor végignézi a fájlrendszer foglalási tábláit, megnézi, hogy mely szektorokhoz nem tartozik fájl, és ezekre mindegyikre kiküldi a TRIM parancsot, akkor is, ha ezek közül van olyan, ami már TRIM-elve van (tehát az adott partíció egész üres területét trimmeli). Második futásnál viszont a fájlfoglalási táblában az újonnan kiürült szektorokat keresi meg, és csak azokat trimmeli. Pedig még a forráskódjából is puskázhatnék, ha nem lennék lusta.
SSD topikot meg jó nyomon követni, melyik szériával mik a tapasztalatok, hogy alakulnak az árak. Egyszerűen tanulságos, még akkor is, ha nem akarsz SSD-t venni. Már pedig akarok (mSATA-s menne bele a fő gépembe 2. SSD-ként, már csak annak van hely), de nem találtam még jó áron. Nagyon fent vannak az árak, de nézelődök.
Persze emlékszem a fénykorodra, mikor te is aktívan részt vettél SSD-s flame-ekben, hogy pl. kell-e kímélni, le kell-e tiltani az atime-ot. Akkor azzal csesztettelek, hogy ki kell venni az SSD-t a gépből, betenni üvegvitrinbe, akkor nem kap sok írást. Csak ezzel azóta nem poénkodok, hogy pár helyről kiderült, hogy üvegvitrinben is bedöglenek ezek, épp úgy a vezérlő adja be a kulcsot.
Nincs nekem ezzel gondom, inkább örülök, ha valaki képben van az SSD dolgaival kapcsolatban, mert bár már nem annyira féltjük, mert tudjuk, hogy mindent kibír, a vezérlő adja meg magát úgyis. Ettől még jó, ha tudja a felhasználó, mi micsoda. Hányan tudják szerinted, mi a különbség a 120 és 128 gigás meghajtók között? Mi az overprovisioning?
Te és sokan tudjátok ezeket, de legtöbben nem. Ez viszont helytelen, de legalábbis értelmetlen felhasználói szokásokat alakíthat ki! Feleslegesen hagynak particionálatlan területeket például előbbiek, de akár a trim miatt is.
Szóval csak legyél képben! Én már nagyon nem vagyok, nem mint ha.....(szerintem, mivel én sem értek hozzá)
-
Ilyen értelemben nem ugyanaz. Igazából ugyanazt mondjuk, csak a kifejezéseket használtam pontatlanul.
Ha nagyon a mélyére nézünk, TRIM-ből csak egy van. Ezt lehet kétféleképpen is kettébontani, attól függően, hogy milyen időbeli beosztásban van végrehajtva.
Az egyik a folyamatos TRIM (discard) a másik az időszakos (fstrim). Ez a felbontás Windows alatt is él, a Windows kernel (Win7 és attól felfelé) folyamatos TRIM-et alkalmaz (menet közben TRIM-el, mikor valami törlésre kerül, azzal együtt a TRIM parancsot is kiküldi), míg egy-két SSD-gyártónak és defrag progit fejlesztő szoftvercégnek van időszakos TRIM-es megoldása (ami viszont megy XP-n, Vistán is, ha a meghajtó és a driver tudja a TRIM-et).
Egy másik bontásban meg van a queued TRIM (a kiküldött TRIM parancsok későbbre ütemezve, kötegelve futnak) és a sima TRIM, aminek egyrészt ilyen terminológia miatt a felülete nem göcsörtös, és a TRIM parancsok valós időben hajtódnak végre, nem ütemeződnek kötegelt végrehajtásra.
Ezeket párokat keresztben is lehet párosítani, négyféle kombinációban. Kivéve, ha nem megy a queued TRIM, mert a kernelben tiltva van. Igazából még mindig áll, amit mondtam. A discard TRIM-et nem tanácsos használni feketelistás meghajtókon, mert nem kötegelve futnak, hanem azonnal hajtódnak végre valós időben egyenként, és ettől belassulhat a meghajtó. fstrim-nél ez mindegy, ahogy írtátok, „kevésbé zavaró”.
Egyébként meg azt a mai napig nem sikerült megfejtenem, hogy az fstrim első futtatásra miért végez sokára, akkor is, ha trimmelt meghajtón fut. A 2-3., stb. futásnál már 0 mp. alatt végez. Majd egy reboot, és újra az első futtatásra mintha újra végigtrimmelné az SSD üres szektoraihoz tartozó cellákat.
Pont a queued TRIM miatt vettem anno Crucial MX300-at. Két fontos szempont volt, tudjon ATA-jelszavazható hardveres AES öntitkosítást a meghajtó, és ne legyen feketelistán a meghajtó queued TRIM ügyében. A Samsung 840, 850 emiatt esett ki, öntitkosítást tud, de a queued TRIM tiltva van. Kiderült, hogy felesleges volt aggódni, mert csak fstrim-et használva is normálisan trimelődik a meghajtó, és nem baj, ha nem használjuk a discard paramétert.
Igazából pedig a feketelistás meghajtók is tudnák, de firmwarehiba miatt okozna a használata anomáliát, ezért van a kernelben szoftveres úton letiltva. Ami duplán meglepő, hogy az illető SSD-k gyártói nem akarják ez ellen a firmware-t patchelni. Tudom, a Linux marginális platform, 0%-os részesedés, a kutya nem használja, mert csak a Windows a tuti. Az néha kísérletezik vele, akinek nincs pénze Mac-re vagy Windows licencre, de előbb-utóbb ők is letörlik, és ChromeOS-t vagy Androidot tesznek fel.
A másik, amit nem értek, hogy az fstrim miért nem támogat minden fájlrendszert. Olyan egyszerűt pl. mint a különböző altípusú FAT fájlrendszerek. A discard támogatja, az fstrim nem. Így ha valaki ilyen fájlrendszert akar trimmelni, feketelistás meghajtón is használni kell a discard TRIM-et.
"ugyanazt mondjuk" vs "8xx-es Samsungon is megy a queued TRIM"
Ok, kiszálltam ebből a vitából
-
Ilyen értelemben nem ugyanaz. Igazából ugyanazt mondjuk, csak a kifejezéseket használtam pontatlanul.
Ha nagyon a mélyére nézünk, TRIM-ből csak egy van. Ezt lehet kétféleképpen is kettébontani, attól függően, hogy milyen időbeli beosztásban van végrehajtva.
Az egyik a folyamatos TRIM (discard) a másik az időszakos (fstrim). Ez a felbontás Windows alatt is él, a Windows kernel (Win7 és attól felfelé) folyamatos TRIM-et alkalmaz (menet közben TRIM-el, mikor valami törlésre kerül, azzal együtt a TRIM parancsot is kiküldi), míg egy-két SSD-gyártónak és defrag progit fejlesztő szoftvercégnek van időszakos TRIM-es megoldása (ami viszont megy XP-n, Vistán is, ha a meghajtó és a driver tudja a TRIM-et).
Egy másik bontásban meg van a queued TRIM (a kiküldött TRIM parancsok későbbre ütemezve, kötegelve futnak) és a sima TRIM, aminek egyrészt ilyen terminológia miatt a felülete nem göcsörtös, és a TRIM parancsok valós időben hajtódnak végre, nem ütemeződnek kötegelt végrehajtásra.
Ezeket párokat keresztben is lehet párosítani, négyféle kombinációban. Kivéve, ha nem megy a queued TRIM, mert a kernelben tiltva van. Igazából még mindig áll, amit mondtam. A discard TRIM-et nem tanácsos használni feketelistás meghajtókon, mert nem kötegelve futnak, hanem azonnal hajtódnak végre valós időben egyenként, és ettől belassulhat a meghajtó. fstrim-nél ez mindegy, ahogy írtátok, „kevésbé zavaró”.
Egyébként meg azt a mai napig nem sikerült megfejtenem, hogy az fstrim első futtatásra miért végez sokára, akkor is, ha trimmelt meghajtón fut. A 2-3., stb. futásnál már 0 mp. alatt végez. Majd egy reboot, és újra az első futtatásra mintha újra végigtrimmelné az SSD üres szektoraihoz tartozó cellákat.
Pont a queued TRIM miatt vettem anno Crucial MX300-at. Két fontos szempont volt, tudjon ATA-jelszavazható hardveres AES öntitkosítást a meghajtó, és ne legyen feketelistán a meghajtó queued TRIM ügyében. A Samsung 840, 850 emiatt esett ki, öntitkosítást tud, de a queued TRIM tiltva van. Kiderült, hogy felesleges volt aggódni, mert csak fstrim-et használva is normálisan trimelődik a meghajtó, és nem baj, ha nem használjuk a discard paramétert.
Igazából pedig a feketelistás meghajtók is tudnák, de firmwarehiba miatt okozna a használata anomáliát, ezért van a kernelben szoftveres úton letiltva. Ami duplán meglepő, hogy az illető SSD-k gyártói nem akarják ez ellen a firmware-t patchelni. Tudom, a Linux marginális platform, 0%-os részesedés, a kutya nem használja, mert csak a Windows a tuti. Az néha kísérletezik vele, akinek nincs pénze Mac-re vagy Windows licencre, de előbb-utóbb ők is letörlik, és ChromeOS-t vagy Androidot tesznek fel.
A másik, amit nem értek, hogy az fstrim miért nem támogat minden fájlrendszert. Olyan egyszerűt pl. mint a különböző altípusú FAT fájlrendszerek. A discard támogatja, az fstrim nem. Így ha valaki ilyen fájlrendszert akar trimmelni, feketelistás meghajtón is használni kell a discard TRIM-et.
Te amúgy érzel kényszert SSD-n FAT akármiről futtatni a rendszert?
Egyébként meg azt a mai napig nem sikerült megfejtenem, hogy az fstrim első futtatásra miért végez sokára
Ezt pedig jó lenne, ha megfejtenéd!
Amennyit lebzselsz az SSD topikban, simán kideríthetnéd. Nagyon anno olvastam erről a témáról, de már nem emlékszem, mi volt a lényeg. -
Nem megy a queued trim mert a kernelben le van tiltva, ahogy a legutóbbi hosszabb írásomban írtam, de látom hasztalan volt
Mégegyszer: a discard nem a queued trim-et állítja be, hanem alapvetően a trim-et, ha a meghajtó tudja azt akkor azt. Ugyanaz mint az fstrim csak folyamatosan megy.
Szerk. Vargalex éppen megelőzött
-
De, 8xx-es Samsungon is megy a queued TRIM, de teljesítményvesztés léphet fel, ezért nem érdemes használni. Ez csak azzal jár, hogy a mount opciók között nem szerepelteted a discard-ot.
A hiánya egyáltalán nem fájó. Bőven elég, ha az fstrim-et használod helyette, vagy fstrim systemd service engedélyezésével, vagy néha napján kézzel lefuttatva a sudo fstrim -a -v parancsot. Ezek a megoldások is rendesen TRIM-elik a meghajtót, semmi hátrány nem ér.
Fájlrendszernek XFS semmiképp. Vagy ext4, vagy f2fs. Mindkettővel van tapasztalatom. Mindkettő egyformán gyors. Az ext4 szerintem jobb, mivel az f2fs bootkor néha lassan ellenőrzi a fájlrendszert (fsck), az ext4-nél ez is villámgyors.
Nem megy a queued trim mert a kernelben le van tiltva, ahogy a legutóbbi hosszabb írásomban írtam, de látom hasztalan volt
Mégegyszer: a discard nem a queued trim-et állítja be, hanem alapvetően a trim-et, ha a meghajtó tudja azt akkor azt. Ugyanaz mint az fstrim csak folyamatosan megy.
Szerk. Vargalex éppen megelőzött
-
De, 8xx-es Samsungon is megy a queued TRIM, de teljesítményvesztés léphet fel, ezért nem érdemes használni. Ez csak azzal jár, hogy a mount opciók között nem szerepelteted a discard-ot.
A hiánya egyáltalán nem fájó. Bőven elég, ha az fstrim-et használod helyette, vagy fstrim systemd service engedélyezésével, vagy néha napján kézzel lefuttatva a sudo fstrim -a -v parancsot. Ezek a megoldások is rendesen TRIM-elik a meghajtót, semmi hátrány nem ér.
Fájlrendszernek XFS semmiképp. Vagy ext4, vagy f2fs. Mindkettővel van tapasztalatom. Mindkettő egyformán gyors. Az ext4 szerintem jobb, mivel az f2fs bootkor néha lassan ellenőrzi a fájlrendszert (fsck), az ext4-nél ez is villámgyors.
-
Sziasztok!
Cégnél kaptam egy 500 GB-os SSD-t, így arra fogok a notebookon átköltözni. Kérdésem, hogy ki milyen filerendszert javasol? Nálam az XFS, illetve EXT4 merült fel. Persze más is lehetséges. Az szinte biztos, hogy LVM-en lesz.
Sajnos az SSD az egy Samsun 850 EVO, így a queued trim nem fog menni. Jobban járok a discard mount opció helyett az fstrim.service futtatásával? -
Kösz a válaszokat. Jó tudni, hogy nem csak én szívok ilyennel akkor. Pedig tényleg teljesen támogatott Intel Wi-Fi kártyával tolom, ami megint csak a Linux kernel által teljesen támogatott üzleti szubnoteszben működik.
Korábbi kernelre nem váltok vissza, mert amúgy más baj nincs vele, és ezzel a netctl-es trükkel használható a rendszer, de kezd már frusztrálni, hogy az utóbbi időben túl sok baj van ezzel, ha így megy tovább, akkor át kell állnom Gentoora.
Egyébként ezt sem értem, mert ha a kernel lenne hibás, vagy a csomagkarbantartó hibázna, akkor nem lenne az, hogy a 4.16.x-es kernelek közül egyikkel jó lenne, a másikkal nem, hanem akkor mindig konzisztensen rossznak kéne lennie egy bizonyos verziószám fölött. De nincs így, egyszer megjavult, jó egy ideig, aztán megint előjön. Nagyon komolytalan ez így, mint egy hullámvasút.
-
Par napja jott frissites Solus-ra, es jott vele a 4.16.7-es kernel. Aznap este felraktam, de masnap reggel mar jott is egy masik frissites, ami kernelt cserelt, a 4.15.18-67.current x86_64-ra. Lehet, h erdemes lenne megprobalnod, neked is vissza menni. Talan valami nem stimmel meg a 16-os vonalal
-
Blogolásom folytatom ide, nem offolom vele a kezdő témát. Most megint nem jó a NetworkManager. Hetekig jó volt, tegnap előtt frissített a 4.16.6-os kernelre, és elkezdett megint szórakozni. Tegnap a 4.16.7-re frissült, és ez sem segített. Lehal random pontokon a Wi-Fi, persze nem szakad meg a kapcsolat, csak elkezdenek nem betöltődni az oldalak. Ahogy beszögelem a /etc/resolv.conf-ba a 8.8.8.8-as Google-féle DNS-t, egy rövid időre megjavult, majd újra lehal, és semmi nem segít rajta. Ráadásul beállítási módozat sincs, amin változtathatnék.
Úgyhogy megint az van, hogy NetworkManagert letiltottam, és wpa_supplicant-os profilt betöltve netctl-lel használom a netet, így jó, bár ennek a módszernek van egy olyan hátránya, hogy bootkor beakad néhány másodpercre, míg a wpa_supplicant kapcsolódik, ami kicsit kellemetlen.
Kezdek közelebb lenni a probléma gyökeréhez, eddig azt hittem, hogy a 238-as systemd-vel van gond, közben meg a kernel lesz a ludas. Abból is tesztelni fogom más disztrókkal, mert lehet csak a csomagkészítő hányja el a dolgokat Arch alatt, kihagy a fordítás során valamit, ami kéne a kernelbe.
Abban is biztos vagyok, hogy nem a Wi-Fi kártya, meg a tré Wi-Fi jelerősség az oka, mert bizonyos szoftveres megoldásokkal jó, Win10 alatt megint jó. Archon majdnem egy évig jó volt. Ha a kártya haldokolni, mindenféle környezetben lenne vele problémám.
-
Blogolásom folytatom ide, nem offolom vele a kezdő témát. Most megint nem jó a NetworkManager. Hetekig jó volt, tegnap előtt frissített a 4.16.6-os kernelre, és elkezdett megint szórakozni. Tegnap a 4.16.7-re frissült, és ez sem segített. Lehal random pontokon a Wi-Fi, persze nem szakad meg a kapcsolat, csak elkezdenek nem betöltődni az oldalak. Ahogy beszögelem a /etc/resolv.conf-ba a 8.8.8.8-as Google-féle DNS-t, egy rövid időre megjavult, majd újra lehal, és semmi nem segít rajta. Ráadásul beállítási módozat sincs, amin változtathatnék.
Úgyhogy megint az van, hogy NetworkManagert letiltottam, és wpa_supplicant-os profilt betöltve netctl-lel használom a netet, így jó, bár ennek a módszernek van egy olyan hátránya, hogy bootkor beakad néhány másodpercre, míg a wpa_supplicant kapcsolódik, ami kicsit kellemetlen.
Kezdek közelebb lenni a probléma gyökeréhez, eddig azt hittem, hogy a 238-as systemd-vel van gond, közben meg a kernel lesz a ludas. Abból is tesztelni fogom más disztrókkal, mert lehet csak a csomagkészítő hányja el a dolgokat Arch alatt, kihagy a fordítás során valamit, ami kéne a kernelbe.
Abban is biztos vagyok, hogy nem a Wi-Fi kártya, meg a tré Wi-Fi jelerősség az oka, mert bizonyos szoftveres megoldásokkal jó, Win10 alatt megint jó. Archon majdnem egy évig jó volt. Ha a kártya haldokolni, mindenféle környezetben lenne vele problémám.
![;]](http://cdn.rios.hu/dl/s/v1.gif)
Mondhatnám azt is, hogy fák jú GPT/UEFI !
Tudom, hogy elgépelted, gondolom a 12-es az 120 gigás akart lenni, az Intelnél meg a 10 az lehet 120 vagy 180 giga?
Új hozzászólás Aktív témák
- Hitelkártyák használata, hitelkártya visszatérítés
- Milyen légkondit a lakásba?
- 5.1, 7.1 és gamer fejhallgatók
- Építő/felújító topik
- Otthoni időjárás-állomás
- TCL LCD és LED TV-k
- NVIDIA GeForce RTX 5070 / 5070 Ti (GB205 / 203)
- Büszke apukák és anyukák topikja
- Le Mans Ultimate
- Futárcégek
- További aktív témák...
- PC Game Pass előfizetés
- Game Pass Ultimate előfizetések 3 - 36 hónapig azonnali kézbesítéssel! 13 hónap ultimate - 45.000 ft
- MEGA AKCIÓ! - Jogtiszta Windows - Office & Autodesk & CorelDRAW - Azonnal - Számlával - Garanciával
- Forza horizon 6 prémiumot vásárolnék
- Forza Horizon 6 Premium / Standard Pre-Order kódok
- G.SKILL TRIDENT Z RGB 16GB (2x8GB) DDR4 3200MHz F4-3200C16D-16GTZR
- Svájci jellegű bicska eladó
- 27% - ASUS ROG CROSSHAIR X670E HERO Alaplap.
- 27% - GAMING PC! Intel i7-13700KF / RTX 4070 Ti / Z690 / 32GB 3600MHz / 1TB NVMe / 850w! BeszámítOK
- Eladó új Lenovo ThinkBook 16 Ultra 5 225U 32GB DDR5 FHD+ Garancia
Állásajánlatok
Cég: aiMotive Kft.
Város: Budapest
Cég: Laptopműhely Bt.
Város: Budapest