Hirdetés
- TCL LCD és LED TV-k
- AMD Navi Radeon™ RX 9xxx sorozat
- Milyen videókártyát?
- Az AI-piac kivégezte a Micronhoz tartozó Crucialt
- Milyen asztali (teljes vagy fél-) gépet vegyek?
- Intel Core Ultra 3, Core Ultra 5, Ultra 7, Ultra 9 "Arrow Lake" LGA 1851
- A fával keres kapcsolatot a Gigabyte új alaplapja
- Kormányok / autós szimulátorok topikja
- Milyen monitort vegyek?
- Pánik a memóriapiacon
-
PROHARDVER!
Mára a ProHardver!/IT.News Fórum is nagylétszámú Linuxban jártas taggal büszkélkedhet. Nehéz szinteket felállítani egy olyan rendszer ismeretében, ami annyira sokrétű, hogy teljesen szinte lehetetlen megismerni minden egyes részét. Azt azonban mindenki tudja, hogy kezdő-e vagy sem. Elsősorban nekik szólnak az alábbiak, de érdemes mindenkinek elolvasnia, mint útjelző táblát.
Új hozzászólás Aktív témák
-
válasz
Rhino666
#35244
üzenetére
Az a baj, hogy (szerintem) a systemd-t két körben kell vizsgálni.
Az első kör az, hogy ha minden úgy működik, ahogy a kottában van, akkor van-e szükség egy ilyen cuccra.
A második kör az, hogy teljesíti-e az ígéreteit a systemd.
Szerintem teljesen unix ellenes szemlélet a systemd, tehát irtani illik.
Szerintem a systemd egy orbitális kupleráj, nem működik.
Akkor lehetne beszélni arról, hogy kell-e ekkora filozófia-váltás a unixba, ha működne. Addig nem. -
#35243
lionhearted
őstag
Rhino666
#35241
válasz
Rhino666
#35241
üzenetére
Értem én, az a kérdés, hogy mennyi az idő is csak akkor probléma, ha legalább kettő órád van. Ha csak egy, akkor nem az...
Nem elvilegről beszélünk, ezek működő megoldások. Tény, hogy alkalmazkodni kell a systemDhez, mert ha fordítva akarod, akkor ez lesz belőle.
@bambano: nem feltétlenül, a network managered definiálja, hogy mit jelent.
-
#35240
lionhearted
őstag
Rhino666
#35239
válasz
Rhino666
#35239
üzenetére
Mondjuk a kommented alapján simán fstab sort írtál neki, nem .mount fájlt, amire tudnád linkelni a következő szolgáltatást.
Szóval a helyes megfejtés:
1. Mount leíró az nfsre network-online.targettel.
2. Service leíró a fenti mountra dependálva, vagy after remote-fs.target. utóbbi lehet magában is elegendő lenne, fstab netdevvel, rég volt már.. -
válasz
Rhino666
#35227
üzenetére
Sorstárs...
Az egyetlen működő workaround mellé még kettő:
1. engedélyezed az rc.local service-t, és a /etc/rc.local-ba írod bele az összes kritikus cumót.
2. nem netdev meg hasonlókra dependelsz a systemd-ben, hanem routable-ra. Ezt még nem sikerült életre rugdalnom, de ez a menő egyes eldugott doksik szerint.Egyébként nagy fanja vagyok az utáljuk p-t csoportnak, de néha felmerül bennem, hogy azok a debianos karbantartók a fakezűek, amelyek a szkripteket faragják.
-
válasz
Rhino666
#35231
üzenetére
Hát nem tudom, én mindig az látom, hogy a Debianosok sírnak a Systemd miatt. Sosem láttam se CentOS rendszergazdától, se OpenSusestól, hogy mennyivel jobb volt a CentOS a Systemd előtt... a Devuan is egy Debian fork. CentOS-ből vagy OpenSuse-ből miért nincs Systemd mentes fork?
Most vagy a Debian rendszergazdák annyira boomerek, hogy képtelenek rendesen megismerni a Systemdet![;]](//cdn.rios.hu/dl/s/v1.gif)
vagy a Debian kefél el valamit, hogy ennyire nem működik nála a Systemd.server/share /mnt/network nfs defaults 0 0Ennek működnie kell sima Debian alatt is, és szerintem működik is, AMÍG a hálózat előbb áll fel, mint ahogy a rendszer megpróbálná felmountolni. Nem véletlenül találták ki anno az LSB-t sem, pont az ilyen problémákra.
-
válasz
Rhino666
#35227
üzenetére
De minek használsz egyáltalán Debiant, ha ennyire nem bírod? Kényszerít rá valaki? Mi értelme van annak, hogy szopatod vele magad, ha egyszer van egy rakat másik disztró, amit lehet használni helyette?
Én x-systemd.automount-ot szoktam használni (meg x-systemd.timeout-ot is, de az másra való), csak úgy simán fstabba, és dependelek a network-online.target-re, soha nem szokott gond lenni vele. Mondjuk nem Debianon, azt nem használok.
Úgy általánosságban így néz ki a dolog nálam://server/share /mnt/network cifs credentials=/root/.smbcreds,_netdev,x-systemd.automount,x-systemd.requires=network-online.target,x-systemd.device-timeout=10,noauto 0 0
És mondom, sose volt eddig gondom vele.
-
#35224
lionhearted
őstag
Rhino666
#35223
-
Lenry
félisten
válasz
Rhino666
#35219
üzenetére
nem annyira
lenry@Echo-Five:~$ ssh E6
##############################################
# LibreELEC #
# https://libreelec.tv #
##############################################
LibreELEC (official): 12.2.1 (RPi4.aarch64)
Echo-Six:~ # uname -a
Linux Echo-Six 6.12.56 #1 SMP Sat Nov 1 08:49:19 UTC 2025 aarch64 GNU/Linux -
sonar
addikt
válasz
Rhino666
#34890
üzenetére
Saját vélemény, tapasztalat, hogy jó az a SELinux. Amikor még a konténer technológia még nem volt ilyen elterjedt és egy sérülékenységet kihasználva bejutottak a webserverre, akkor addig jutottak. Semmi egyebet nem tudtak csinálni. Míg ahol nem volt SELinux, ott gyalu, és restore backupból a szerver kompromittálódott.
SELinux, AppArmor - MAC, MandatoryAccessControl, vagyis felcimkézel mindent, hogy melyik process mihez férhet hozzá. "Felülírva" a klasszik user/group szintű jogosultságokat.
-
válasz
Rhino666
#34890
üzenetére
Az SELinux az annyira secure lett, hogy kb. használhatatlan. Gyakorlatban az AppArmor egy sokkal értelmesebb security modul. A kernel hardening az passzív védelem gyakorlatilag kikapcsolsz felesleges dolgokat, ez aktív. Előbbivel óvatosan, nagyon hülye guide-ok vannak.
Máig a kedvencem amikor valami kezdő security-s az ügyfélnél szólt, hogy kapcsoljuk ki az IP forwardingot, mert az nem secure. Ezután jeleztem neki, hogy a termék egy router
-
.-..-.
tag
válasz
Rhino666
#34864
üzenetére
Rhino666, Archttila:
Köszönöm.
Azt hiszem, akkor a systemd-networkd/systemd-resolved lesz a választott páros.
Egyszerűen, a "ha már úgyis ott van, akkor azt használom" alapon.Más:
Az ssh portot (egyelőre) átraktam a 63633 portra és ezt nyitottam ufw-ben.
Akkor a fail2ban megfelelő így?# /etc/fail2ban/jail.local
[sshd]# To use more aggressive sshd modes set filter parameter "mode" in jail.local:# normal (default), ddos, extra or aggressive (combines all).# See "tests/files/logs/sshd" or "filter.d/sshd.conf" for usage example and details.#mode = normalenabled = trueport = ssh,sftp,63633logpath = %(sshd_log)sbackend = %(sshd_backend)s -
.-..-.
tag
válasz
Rhino666
#34806
üzenetére
Aha, így már talán kapisgálom...
Mondjuk nincs szükségem rá, de értem, hogy miért használják páran.growler:
Kíváncsi még lennék rá, de időm biztosan nem lesz ilyennel szórakozni.
Jelen esetben mások tapasztalata elég a válaszra.Lenry:
Azért is kérdeztem, mert ugyan erősen alkalmi játékos vagyok és így a tapasztalatom nem reprezentatív, de ~1éve már játék ügyben sem indítom el a Win-t és a Steam kliens segítségével futó játékok (Steam letöltés vagy külső könyvtárból) a Proton-nal nálam nem okoznak gondot. -
Vasti74
senior tag
válasz
Rhino666
#34764
üzenetére
Ízlésekről kár vitatkozni ;-) Én agyhúgykövet kapok a házi összeszerelésű gépektől... Pedig összeraktam életemben pár 1000 darabot: XT-vel kezdtem, és SuperMicro szervereket is raktam össze. OK, azok mondjuk jók voltak ;-) A kettő között meg sok mindent.
De már eleve az, hogy lóg bennük egy halom kábel, fúúúj! ;-) Aztán a sok felesleges "szellőzőnyílás", a betekintő ablakok, a világító mindenfélék, hát, nem az én világom.
A brand gépekben általában akkora az alaplap, hogy kitölti a házat, így nem lóg sem csatlakozó, sem kapcsoló, sem LED kábelen. Egyszerűek és okosan megtervezettek, minimalisták: szépek :-) Szerintem így kell kinéznie egy PC-nek, belül meg így - itt áll még az asztalom mellett, lehet, hogy visszakerül a Lenovo helyett, pedig annak sem a kinézetével van bajom ;-) -
Vasti74
senior tag
válasz
Rhino666
#34754
üzenetére
Az a gáz, hogy ez egy nem egy tegnap kijött mega-különleges gép, hanem egy több éves valami. És azért csalódtam már megint a kedvenc rendszeremben, mert pl. Windows alatt lehet piszkálni a ventilátor fordulatot, tehát a lehetőség adott. De míg régen az volt, hogy linux alatt minden kapásból működni fog (hardver) , amiért Windows alatt küzdeni kell, mára ez kb. úgy néz ki, hogy egy csomó mindent el lehet felejteni linux alatt, ami Windows alatt kapásból működik, vagy pár kattintással működésre bírható :-(
És az, hogy ez a BIOS dolga lenne, nem nagyon vigasztal, mert régen is az volt, mégis lehetett szabályozni, ha akartam (volt olyan gépem régen, hogy akartam, és tudtam is) Talán mert régen igazán és értelmesen fejlesztettek, most meg érzésem szerint a fejlesztés valahol a farigcsálás és a tákolás között helyezkedik el.
Nem tudom, szerverfronton mi van, de ha ott is ilyen jó a helyzet, akkor piszkosul örülök, hogy már rég nem foglalkozok ezzel ;-)
Na kiduzzogtam magam, megyek aludni :-) -
#34742
lionhearted
őstag
Rhino666
#34734
válasz
Rhino666
#34734
üzenetére
Igen is, meg nem is. A brand gépek tervezhetnek azzal a hűtéssel, ami benne van, irányával vagy mennyiségével is. Egyszerűbb, értelmes nem bazári top-down hűtő sincs már minden foglalatra... arról nem is beszélve, ha már van hozzá alkatrész (ahogy nekem is volt elfekvőben, bár nem volt hangos a gyári se, de mégis 7/24ben akarom járattni).
Ha ezen túl vagyunk, akkor sincs meg a szabályzásod továbbra sem, gondolom nem véletlenül hiányzik neki a PWM. Ha meg van is belső szabályzása, nem a te aftermarket hűtődre, lehet azt is feltekeri...Arról nem is beszélve, ha nem sztenderd felfogatós, ahogy a HPba se tudtam beszerelni az amúgy CPU szinten rávaló hűtőt, mert nem úgy volt kialakítva.
+1 egy ellenállásos szabályzó mennyibe is fáj most?
-
.-..-.
tag
válasz
Rhino666
#34738
üzenetére
Nálam 134.0.6998.117 (Official Build, ungoogled-chromium) Arch Linux (64-bit) ami rendben van.
VPN-t is használok és amikor valami bajuk van az IP-vel, akkor mindenáron be akarnak jelentkeztetni, hogy nem vagyok-e robot. Ekkor váltok másik VPN-re.
Szóval szerintem nem az IP-vel van gondjuk, mert anno mikor nálam is ilyen probléma volt, akkor másik browser-ből működött a YT ugyanarról a gépről/IP-ről.
Illetve működött a yt-dlp is, ami szintén ugyanarról a gépről/IP-ről futott. -
.-..-.
tag
válasz
Rhino666
#34732
üzenetére
Ez melyik ungoogled-chromium?
Azért kérdem, mert a napokban telepítettem Arch-ot és én is azt a böngészőt használom (+ublock-origin) és nálam megy a YT rendesen.
Régebben volt nálam is 20mp probléma (ha beletekertem akkor is csak karikázott), de most semmi ilyesmi nincs. -
válasz
Rhino666
#34696
üzenetére
Én meg sokszor rólatok gondolom az, hogy a Systemd utálat nagyrészt abból fakad, hogy nem akarjátok megismerni, és ragaszkodtok a régi megoldásokhoz.
10 éve használok desktopon Linuxot, előtte 3 évig használtam már szerveren is, és soha nem találkoztam az általad írtakkal. Soha nem láttam korrumpálódott journalt, soha nem okozott problémát beleolvasni, soha nem volt olyan, hogy ne lett volna hozzáférhető, és soha nem volt nehezebb archiválni.
Ha nem indult el a rendszer, bebootoltam live CD-ről, és tudtam olvasni a logokat.Egy adatbazis eseten nem szamit hogy binaris-e vagy sem, ugyanis alapvetoen...
Abból a szempontból nagyon is számít, hogy a bináris feldolgozás sokkal gyorsabb. És ha az még az oda-vissza konvertálásnak van is némi plusz erőforrásigénye, cserébe sokkal gyorsabb keresni a bináris logban, sokkal gyorsabban és egyszerűbben szűrhető, sokkal gyorsabban, és szerintem ezek sokkal gyakoribb use casek, mint az, hogy 10 év múlva is olvasni kell.
És mindemellett grepelhető is, és exportálható szöveges formátumban, ha valaki azt szeretné. Nem is értem a syslog melletti ragaszkodást, a journal kb. minden szempontból többet tud. -
válasz
Rhino666
#34694
üzenetére
Én pl. sosem hallottam még egy indokot a binary log ellen. Az, hogy a log nagy mennyiségű, gyorsan változó adat, amelyet célszerű indexelni és metaadatokkal ellátni, az már eleve implikálja, hogy érdemes bináris formában tárolni.
Nem véletlenül alakultak ki a bináris fájlformátumok, jpg-t sem szöveges dokumentumban tárolunk, és az adatbázisok is jellemzően binárisak. És a log sem egyéb, mint adatbázis.
Na mindegy, a lényeg, hogy mindenki megtalálhatja az a disztrót, ami számára a legszimpatikusabb. -
válasz
Rhino666
#34692
üzenetére
Persze, minden megoldható, ha újraírjuk, átírjuk, szabványosítjuk, gyököt vonunk belőle, deriváljuk és hozzáadjuk a jogosultságkezelést
A szabványosítás egyébként megtörtént, úgy hívják, bináris log. Itt van hozzá a leírás, itt meg a referencia implementáció.
Amiket leírtál, annak kb. a felét pont a binary log oldja meg, pl. az indexelést vagy a metaadatok hozzáfűzését. Lehet plain textet indexelni, de senki nem csinálja, főleg nem logban, ahol folyamat jönnek és jönnek az adatok, így folyamatosan újra és újra kellene indexelni az egészet.Az 1.-es pl. megoldható manuális munkával (és reménykedsz benne, hogy nem crashel tőle a program), de a journal-ban alapból ott a program PID-je.
A plain textetet is lehet szabványosítani, persze, csak nem annyira jó dolog a flat file db, mert lassú, mert az indexelhetősége közel nulla, stb.... -
válasz
Rhino666
#34690
üzenetére
A legtöbb pont nem értelmezhető bináris log nélkül, azaz vagy nem lehet megcsinálni szöveges loggal, vagy nem lehet normálisan megcsinálni.
Meg lehet csinálni pl. a logban mezők hozzárendelését valamilyen flat file adatbázis formátummal, mondjuk CSV-vel, az akár nyers formában is olvastható. De attól az még nem lesz indexelhető, attól még lassú lesz (ami embedded eszközökön érezhetően lassít a működésen), stb. -
válasz
Rhino666
#34669
üzenetére
Valojaban a systemd egyetlen dolgot sem csinal jol: itt tobben tobbszor is emlitettek, hogy mekkora jo feature, hogy barmibol tudsz service-t csinalni. Nos, ez teljesen nem igaz, nalam altalaban 3 alkalombol 2x nem sikerul (pedig sem hulyenek, sem tapasztalatlannak nem tartom magam) - miutan ez a kelletenel tobbszor fordult elo, igy mar nem is probalkozom vele.
-
válasz
Rhino666
#34647
üzenetére
Akkor lenne monolitikus, ha egy bináris lenne az egész, vagy több bináris, de annyira összehegesztve, hogy egyik nélkül nem működne a másik.
Nem tudom, mit jelent az, hogy minden átfut rajta. De simán lehet olyan Systemd buildet csinálni, ahol csak a core van, semmi más. -
válasz
Rhino666
#34642
üzenetére
- ebbol kifolyolag tulsagosan osszetett, bloatware
- ebbol kifolyolag tele van biztonsagi resekkel
- ebbol kifolyolag mesterseges fuggosegeket general
Ez nem igaz, a systemd moduláris. Van az init része, a service része, meg a journald, ez a core, de ezek is el vannak osztva több, különböző binárisra (és nem is kötelező mindegyiket futtatni). Minden más része opcionális.
De alapvetően az egyes szolgáltatásokat valakinek el kell látnia, teljesen mindegy, hogy azt most a független X bináris látja el, vagy a Systemd projektből jövő Y bináris. Semmivel nem vagy előrébb, ha a systemd-networkd helyett a dhcpcd fut, ha udev helyett eudev fut, ha systemd-journald helyett syslog fut...- azt hazudja hogy ujraindult a service, mikor nem is
Sosem találkoztam ilyennel. A journal corupptiont is csak hallomásból ismerem, de ahogy utána olvastam, sok esetben kiderült, hogy fájlrendszer hiba, vagy lemez hiba okozta.Szerintem a Systemd ellenességnek nincs értelme, már csak azért sem, mert egy csomó pluszt nyújt a Systemd. Szedett-vetett init scriptek helyett egységes, normális (függőségkezelt) service unitok, szűrhető, kereshető, jól használható log, stb.
A UNIX filozófia meg már az X-nél megbukott.
-
válasz
Rhino666
#34627
üzenetére
KDE Wayland?
Innen másoltam: https://wiki.archlinux.org/title/Variable_refresh_rate
Itt valóban írják, hogy már frissítésre szorul.
-
válasz
Rhino666
#34625
üzenetére
Én sem azt mondtam, hogy mindenkinek vannak
De Vasti végigpróbált már ki tudja hány disztrót, több géppel is, és mindegyiknél előjöttek a problémái. Csak bizonyos hardverek, szoftverek és beállítások kombinációja esetén állnak fenn ezek a problémák.
A VRR állapota jelenleg:
Ha te nem esel bele ebbe a körbe, az tök jó, de sokan igen.A HRD monitor támogatás pedig így néz ki:
- KDE Plasma 6.0 introduced experimental HDR support for Wayland session.
- DRM clients can directly pass HDR metadata, but this is not available from regular userspace clients, only specialized software can use it.
- COSMIC developers have promised HDR support in the initial stable release.
- Hyprland introduced HDR support since #8715.
- Wlroots, "Add HDR signalling" MR.
- GNOME 48-beta introduces HDR support and toggle under Wayland.
Ettől függetlenül persze meg lehet próbálni a Voidot, hátha patcheltek benne valamit, ami megoldja a problémákat.
-
válasz
Rhino666
#34623
üzenetére
Ezek architekturális gondok, nem azért vannak, mert egy-egy disztróban gond van a csomaggal, hanem mert a desktop Linux, szépen kifejezve, kissé le van maradva 4K támogatásban (és VRR-ben is, mint ahogy HDR-ben is).
A Void egyébként nem rossz, én régebben használgattam, nem volt vele gondom. Mondjuk az már tényleg rég volt, 2017 környékén.
-
daninet
veterán
válasz
Rhino666
#34594
üzenetére
Közben megtaláltam a redhat doksiban, hogyaszondja:
In addition, asoundelement with'ich6'model set can have optionalcodecsub-elements to attach various audio codecs to the audio device. If not specified, a default codec will be attached to allow playback and recording.Szóval nem bug hanem feature, ha a fejhallgatódon van mikrofon akkor default beállításokkal így jártál
Szuper. Egy hónapom ment rá erre, jó ideje vezetékkel használom a fülest. -
daninet
veterán
válasz
Rhino666
#34591
üzenetére
pipewire-t próbáltam de nem volt hang valamiért és visszaraktam pulseaudio-ra. pedig szenvedtem vele egy ideig
Most beleírtam virsh konfigba a <sound> részbe, hogy<codec type='output'/>
Elvileg most erőlteti hogy csak kimenet lehet a pulseaudio.
Holnap meló közben tesztelem, most gyors vm indítás után ~okénak tűnik
![;]](http://cdn.rios.hu/dl/s/v1.gif)
vagy a Debian kefél el valamit, hogy ennyire nem működik nála a Systemd.
Új hozzászólás Aktív témák
- Ubuntu Linux
- HBO Max
- Samsung Galaxy S25 Edge - a tegnap határán
- TCL LCD és LED TV-k
- AMD Navi Radeon™ RX 9xxx sorozat
- Luck Dragon: Asszociációs játék. :)
- Garancia kérdés, fogyasztóvédelem
- Fele annyit ér az iPhone Air, mint amennyibe pár hete került
- Milyen videókártyát?
- One mobilszolgáltatások
- További aktív témák...
- Telefon felváráslás!! Samsung Galaxy S22/Samsung Galaxy S22+/Samsung Galaxy S22 Ultra
- Google Pixel 10 Pro XL Moonstone Super Actua 120 Hz, Pro kamera 5 zoom 256 GB Használt,Gari
- Apple iPhone 8 64GB Fekete 1 év Garancia Beszámítás Házhozszállítás
- HIBÁTLAN iPhone 13 mini 128GB Starlight -1 ÉV GARANCIA -Kártyafüggetlen, MS3614, 100% Akkumulátor
- 153 - Lenovo LOQ (15IRX9) - Intel Core i5-13450HX, RTX 4060
Állásajánlatok
Cég: PCMENTOR SZERVIZ KFT.
Város: Budapest
Cég: ATW Internet Kft.
Város: Budapest