-
Mobilarena
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
-
#34721
emvy
félisten
lionhearted
#34719
válasz
lionhearted
#34719
üzenetére
> Internet nélküli gépet nem tudok csinálni, mert a felhőben fut, el se érném.
bocs, aprosag: a felhoben levo gepek eleg jo reszenek nincs internetelerese, ettol meg el lehet oket erni
-
válasz
bambano
#34698
üzenetére
> ha keresek valamit a logban, akkor systemd esetén journalctl-lel kilistáztatom és utána grep-pel vagy valamivel keresem, megnézem.
Valld be, hogy csak szivatsz minket!
tenyleg kis ceg vagyunk, igy az applikacionk csak havi 5 terabajt logot produkal, sok sikert a greppel akar egy napi lognal is! (Nem, nem lehet mindig mindent ELK-ban tartani. (journalctl | grep az tenyleg kismeretu logoknal jol mukodik, de akkor nem fogod tudni hasznalni pl. a beepitett indexalast)> szerk: egyébként egy lemezhiba esetén annak van nagyobb valószínűsége, hogy a bináris log olvasható marad, vagy annak, hogy a text?
ez relevans lenne, ha pl. merevlemezre irjatok az adatokat bitrol bitre, es igy vegulis le lehet majd olvasni elektronmikroszkoppal -- de 2025-ben flash alapu tarolokat hasznalnak, titkositassal, tomoritessel, es SEMENNYIRE nem use case, hogy valaki beleb*szik egy csavarhuzot a diszkbe, es a maradekot szeretnenk visszaolvasni egy masik IBM XT-ben
de a valodi valasz egyebkent: ha fontos a log tartalma, akkor nem uldogel egy diszken backup nelkul, hanem valos idoben replikaljuk mashova is, tehat van backup
-
válasz
ViZion
#34640
üzenetére
Semmi, csak csomoan nem vettek eszre, hogy a Linuxot 99%-ban nem ugy hasznaljak manapsag, hogy 1-10 gepet menedzselgetnek kiszakadt zokniban+szandalban, hanem mobilok es szervere szazmillioira teritik, es azok a cegek, akik ezeket a szazmillios disztrokat csinaljak, megfelelonek tartjak a systemd-t, sot, azt tartjak a jelenleg legmegfelelobbnek. Nyilvan lehet hulyenek nezni a Google, Redhat, Microsoft, Amazon Linux-mernokeit, de nem veletlenul hasznaljak.
Egyekbent pont ugyanugy nyer a systemd, mint ahogy a Linux nyert a Minix ellen. A Minix sokkal szebb architektura (mikrokernel, stb.), de a Linuxot sokkal gyorsabban adoptalta a vilag. A systemd valoban nem koveti a klasszikus 'apro toolok egyuttese'-jellegu *nix filozofiat, de a Linux-fele monolit kernelnel is sokkal kozelebb volt az Unix-filozofiahoz a Minix.
Szerintem
no offense -
#34556
emvy
félisten
lionhearted
#34555
válasz
lionhearted
#34555
üzenetére
> Itt a topikban azért tudjuk, hogy a boot az egy folyamat, azzal, hogy az első lépését aláírásra kényszeríted, a többit még nem.
Termeszetesen. A jelenleg dominans megkozelitesek szinte mindig 'chain of trust' alapon mukodnek, a SecureBoot annyit probal elerni, hogy ez a lanc ne szakadjon meg akkor, amikor a firmware atadja a kontrollt az installalt operacios rendszernek.
-
> ha valaki beszerzi a MS root keyt
eleg lazan bedobtad ezt a feltetelezest
ha root keyeket 'be lehet szerezni', akkor konkretan _semmi_ nem mukodne az internetenA secure boot (altalaban, nem csak a PC-s vilagban) elengedhetlen resze a (nagyvallalati) biztonsagi technologiaknak szerintem; persze teljesen igazad van, hogy nem tokeletes.
-
> Nem, de ez sem éppen elfogadható, hogy nincs HW hiba (már) de nem tudsz vele mit kezdeni.
De volt HW hiba. Szet vannak estve a metaadatok, ez semmilyen fajlrendszeren nem segit. Az is eredmeny, hogy nagyreszt olvashato az adat.
> Azt nem is mondom, hogy ugyanígy táp kontakthiba esetén a tükör nem védett meg az adatvesztéstől
Az tokmindegy, hogy minek volt hibaja. A ZFS (es hasonlok) a lemezhibaktol vedenek. Ha mindegyik eszkozzel gond van, az egy mas ugy. -
#34492
emvy
félisten
lionhearted
#34491
válasz
lionhearted
#34491
üzenetére
> akkor hogy van az, hogy adott dolog egy másik disztróban adatik csak meg
igazabol nincs ilyen -- amikor azt irjak, h X disztro kell az Y feature-hoz, az jellemzoen csak hozzanemertes.
Ami tenyleg mas a disztrok kozott, az a frissitesi megoldasok (rolling vagy nem, mennyire teszteltek az uj csomagok, stb.)
-
A KDE alatt viszont legalabb _mukodik_. Nincs rendes hwaccel, de legalabb majdnem minden ugy nez ki, ahogy annak kell.
> Egyetlen "értlmes" megoldás, hogy amennyiben a monitorod támogatja kisebb a skálázásnak megfelelő felbontást azt állítod be. Pl. WQHD.
Ez nem ertelmes szerintem, mert homalyosabb lesz.
En tok jol elvagyok 5K2K felbontassal, 150%-os skalazassal a legujabb KDE-n. Gnome alatt az Electronos appok nem mukodtek rendesen (tobbek kozott).
Szoval ezert javaslom a KDE-t.
-
-
válasz
#78522999
#34145
üzenetére
Amit en csinalok a privat jatszos Hetzner gepemen:
- Tailscale install
- SSH 100%-ig tiltva Hetzner tuzfalon (tehat a gepig el sem jut a csomag)tailscale ssh-val be tudok menni, ha kell valami, ha meg valami miatt megdoglene a Tailscale (nem szokott), akkor meg arra az idore kinyitom a normal ssh-t
-
Elnézést, ha úgy jött le, h esetleg az általános hozzáértésedet vonom kétségbe. Storage építésénél jellemzően a célszoftvernek próbáljuk adni a kontrollt.
TrueNAS rendes Linux, abszolút való virtualizációra. Ha sima Debiant raksz fel, az is működni fog, de a TrueNAS (Scale) ad egy csomó segítséget.
-
Az a baj, h nem vagy kulonosebben tapasztalt/profi infrastruktura-mernok, de el akarod kezdeni egymas tetejere pakolni az absztrakciokat. Ez az almoskonyv szerint nem vezet jora, mert ha valami elkezd rakoncatlankodni, macerasabb lehet kinyomozni, hogy mi van.
ZFS/RAIDZ1 on bare metal (HBA), ez a megoldas, ami neked kell. Konkretan azt javaslom, hogy TrueNAS-t rakjal fel. Ha gond van, diszk ki/be, resilver, kesz. Ha alkalmazasok, szolgaltatasok kellenek, akkor TrueNAS alatt virtualizalsz.
Lehet ennel bonyolultabban is csinalni, de _szerintem_ nem tartasz ott. Ha nem fontos az adat, akkor persze jatssz vele.
-
#34090
emvy
félisten
lionhearted
#34089
válasz
lionhearted
#34089
üzenetére
Egyebkent valamennyit er, pl. a ZFS checksumolasa az tok jol mukodhet egy nagy fajl eseten is.
-
Pontosan, ELK, vagy hasonlo stack. Ezeket celszeruen strukturalt logot etetsz. Persze megcsinalhatod a parszolast sajat szabalyokkal, viszont ha journalbol jon, akkor a melo jo reszet mar megcsinalta helyetted a rendszer. Tehat valami miatt itt csomoan azt szeretnek, ha pl. a severity level beallitasara nekik kene megirni a regexet egyenkent minden processzre, de nem tudom, h ez miert elvezetes.
-
válasz
bambano
#34069
üzenetére
> és ti a terabyte nagyságrendű logokat összeöntitek egybe?
Persze, hogy keresnél egyébként? Mármint nyilván szénné van indexelve, de nem az van, h van óránként meg szolgáltatásonként egy fájl.
De természetesen strukturált logra van szükség ekkora mennyiségnél.
> miért nincsenek olyan macerák a journalnál, amiről azt hiszed, hogy text lognál vannak?
Mondj egy konkrét példát, és beszélhetünk róla. Legyen mondjuk a log rotation?
-
-
válasz
ka.laszlo
#34065
üzenetére
A log forwardingot pont nagyon tudja a journal, resze volt az eredeti celkituzeseknek. A logrotalas detto, hiszen a journal seekable, ergo a klasszikus logrotalasra nincs is szukseg. Logrotalasra alapvetoen azert van szukseg, mert a regebbi logokat idovel kidobjuk helysporolas miatt, es ezt ugy szokas megcsinalni, hogy a fajlokat dobjuk el, mert a szoveges logokban nem lehet egyszeruen ido szerint seekelni, plusz a fajl elejet truncate-elni maceras. A journalnal nincsenek ilyen problemak.
Tehat a journal alapvetoen kozelebb van a KISS-hez, mint a szoveges logfajlok rotalgatasa, mert arra van kitalalva, hogy logokat taroljon (ellenben a sima szoveges logokkal).
> Nem, egy JSON-ban szűrni sokkal kevésbé egyszerű, mint egy plaintext logfájlban, ha minimális regex ismeretei vannak valakinek.
Nem ertek egyet,
1) a komplex regex nagyon lassu tud lenni
2) minden program hajlamos sajat formatumba logolni, tehat egyszerre tobb program logjat szeretned korrelalni/szurni, akkor az seggfajas.A tobbi filozofalgatas, szoval nem mennek bele.
Nem tudom, h ti mekkora meretu logfajlokkal dolgoztok, ahol en dolgozom, ott ~ terabajt nagysagrendu log van naponta. Ti grep-et es regexet hasznalnatok arra, h keresgeljetek ennyi logban? (Nyilvan mi is hasznalunk regexeket, stb., de nem ugy, hogy bemegyek a szerverre ssh-val, es a syslog fajlokat elkezdem grepelni.)
-
A legtöbb Linux nem POSIX certified. A szabványok elsődleges célja az interoperabilitás és a minőségbiztosítás. Ha a termék szabványos, de nem oldja meg a problémádat, akkor nem vagy kisegítve. A systemd olyan problémákat old meg, amire korábban nem volt megfelelő megoldás (legalábbis a Linuxos közösség jó része úgy értékelte, hogy nem volt). De a Linux FLOSS, ezért azt használsz, amit akarsz. Ez a fo elonye, szoval nem ertem a gyaszolast
-
válasz
bambano
#34061
üzenetére
1. Az Unix alkotoinak az elkepzeleseit te is csak ertelmezed, nyilvan a sajat szemszogedbol.
2. Valtozik a vilag, nem kotelessegunk azt csinalni, amit a PDP-11-et hasznalva gondoltak az alkotok. Miert lenne?> ha az operációs rendszer nem felel meg az eredeti, alapvető tervezési filozófiájának, akkor katyvasz lesz belőle
tok jok ezek a levegobol vett allitasok, nyilvan lehetetlen ertelmes beszelgetes folytatni roluk
> majd meglátjuk, hogy a dinamikus dns konfiguráció a fontos-e vagy a jogszabály
na jo
-
válasz
urandom0
#34055
üzenetére
Journalt is tudod massal olvasni. Egyebkent meg journalctl-t pipeolhatod vim-be, ha akarod.
> Írták már, ha pl. megsérül a diszk, a bináris logot nehezebb helyreállítani.
Miert lenne nehezebb? A journal formatum append-only, ugyanugy helyre lehet allitani. Lattal mar eletben ilyen problemat?
Sot, a valosag _pont_ az ellenkezoje. A syslog joval erzekenyebb a crashekre, a journalban atomikus append van, integrity check, tud pl. kriptografikus szignalast (tuti biztos lehetsz benne, h utolag nem nyult valaki bele a logfajlodba).
-
válasz
bambano
#34056
üzenetére
Ezek ilyen filozofalgatasok, neked ez az elkepzelesed az Unixrol, masnak meg mas. Es jelenleg akik alakitjak a Linuxot, ok mashogy akarjak.
> Alaposabban belegondolva mondhatjuk, hogy a tailscale a saját megoldása miatt erősen elfogult, tehát az, hogy szerintük mi a jó dns rezolválás, messze van az általános objektív valóságtól.
A Tailscale szeretne valamit megvalositani. Olyasmit, amire oriasi igeny van. Az oprendszernek nem az a feladata, hogy valami filozofianak megfeleljen, hanem hogy lehetove tegyen kulonfele use case-eket. A dinamikus DNS konfiguracio fontos. Ezt resolv.conf hekkelessel nem tudod elegansan es robusztusan megoldani.
-
-
válasz
bambano
#34049
üzenetére
Ha neked elég az ASCII log, akkor több lehetőséged is van azt használni. A világ elég jó részének nem optimális, mert túl komplex (igen - egy JSON logban szűrni sokkal egyszerűbb).
A probléma az, hogy azt gondolod, hogy egy sztékes helyen ülsz, de a többiek azt látják, hogy egy enyhén pityókás, morcos bácsi morog a Hawaii bowl-os helyen valami olyasmiről, hogy ez régen egy jó grillező volt, és követeli, hogy neki adjanak rendes húst
-
válasz
sh4d0w
#34044
üzenetére
Mi nem mukodott az unittal? Nem tudom, hogy mi az, ami abban nem tud mukodni. Csinalsz egy unit fajlt egy perc alatt, kesz. A harmadik utan mar a vilag legegyszerubb dolga, mindent egy helyen konfigolsz.
"Red Hat megírja a unitokat"
?
resolved: ez az, ami megbizhatoan tudja a kovetkezoket:
- interfeszenkenti DNS feloldas (VPN-ek, kontenerek, stb. eseten letfontossagu)
- DNS over TLS (biztonsag)
- D-Bus tamogatas
- domain-alapu nevfeloldasi szabalyokSzerintem megegyezhetunk abban, hogy a Tailscale mernokei a vilag tetejet kepviselik, ha Linuxos halozatokrol van szo. Ok irjak:
As an aside, one major difficulty in all of this is that name resolution on Linux systems is very poorly specified, and each of these methods results in slightly different behavior. If we do a resolution for
go.akua, what will happen? Will it go to the resolver for the public internet? Will it go to the right split server? Will it get sent over Tor for some reason? Will it get sent to the potentially dodgy DNS server on the public Wi-Fi hotspot at your local coffee shop? Will it get sent over UDP, TCP or DNS over HTTPS? We don’t know. This stuff is not documented and as a result, you need to figure out what it does through blood, tears and heartbreak. For extra fun, the behavior of glibc and musl differs here too. Please document your behaviors when you write new software. This saves so many people so much time.An example of how to do this right is systemd-resolved. It can do everything a modern split-DNS VPN needs natively, so in theory there’s no extra work (except see below, because reality is not quite as clean as we’d like). The systemd team painstakingly wrote down what they do, and made it unambiguously obvious how you should twiddle things to get what you want. This is the kind of documentation that infrastructure programs should strive to have.
Szoval a resolved
1) mukodik
2) mindent tud, amit egy modern DNS kliensnek tudnia kell
3) reszletesen dokumentaltnincs mas olyan DNS megoldas, ami ezeket igy mind tudja.
A binaris logolas meg egy erdekes tema, kezdve onnan, hogy minden logolas binaris ...
Azert hasznaljak a systemd-t a a valo vilagban, mert komplex kornyezetekben is jol mukodik.
-
-
#34041
emvy
félisten
fatpingvin
#34040
válasz
fatpingvin
#34040
üzenetére
Nem, pl. azert sem, mert a su processz nem az 1-bol fog leszarmazni.
Egyebkent meg:
> Pláne úgy, hogy ez a run0 az egész PAM mechanizmust meg a polkitet berántja maga alá
pont ahogy a sudo is
A sudoval meg az is a gond, h nem all mogotte rendes maintainer garda
-
> Nahát mégiscsak érdekelnek az unalmas filozófiai feljtegetések?
![;]](//cdn.rios.hu/dl/s/v1.gif)
Az unalmasak nem. Az volt a bajom, hogy amikor adtam indokokat/referenciakat, akkor kb. megvontad a vallad, h hat oke, te maskepp gondolod -- ervek nelkul unalmas a vita.
> Namármost az az alap paradigma, hogy egy cégnek törekednie kell a profit maximalizálására.
Ez igy egyebkent nem igaz, mondjuk ugy, hogy for-profit cegnek minimum nyeresegessegre kell torekednie, a tobbi az nem egyertelmu.
> Ettől eltérni nem lehet, ahogy te is mondtad, nem elvárható.
El lehet terni, a legnagyobb cegek is elternek (mondok egy peldat, ami ugyis kibassza a biztositekot: Meta -- a Meta egyaltalan nem profitmaximalizal).
> Aztán jött a redhat és felrúgta ezt az egészet. Az 1.-es helyre egy alapvetően humán, morális szabályt helyetett, méghozzá a szabad szoftver szemléletet.
O istenem.
-
> 2004-től 2013-ig ez nem volt bosszantó
nem ismerem a reszletes szamokat / uzleti titkokat --
> vagy az a baj, hogy nem lehet maximalizálni a profitot
az mindig baj, nincs olyan, hogy nem baj -- az a baj, hogy emberek azt gondoljak, hogy for profit cegek a kozossegert vannak valahogy.. vannak persze jobb es gazosabb cegek, persze; de nem elvarhato, h karbatett kezzel uljon egy ceg, amikor kihuzzak alola a bevetelt.
-
-
válasz
sh4d0w
#33344
üzenetére
Oke, a lentebb linkelt szovegben nem lattam arra utalast, hogy megtiltana a customereknek, hogy megosszanak forraskodot. Van linked erre?
(BTW, egyaltalan nem gondolom, h a Red Hat valami jo vagy ertelmes dolgot csinal -- nem latom, h igy lenne. De a GPL-sertest se latom egyelore.)
-
válasz
sh4d0w
#33341
üzenetére
> nem teszi vissza a kozosbe, amit onnan kivett - es az az a pont, ahol valoszinuleg GPL-t sert a ceg.
A GPL-ben nincs szo olyasmirol, hogy 'vissza kell tenni a kozosbe'. A GPL arrol szol, hogy a szoftver hasznaloja szabadon hozzaferjen a forraskodhoz. A GPL nem szol arrol, hogy a kozossegnek vissza kell adni valahogy.
Konkretan lentebb linkeltem a GNU FAQ-jat, ahol cafoljak azt, amit (szerintem) gyanitotok.
"Red Hat customers and partners can access RHEL sources via the customer and partner portals, in accordance with their subscription agreement."
Tehat mindenki, aki a Red Hat-tol kap binarist, elerheti melle a forraskodot is.
-
A katedralis es bazar nem arrol szol, hogy a szoftver termek-e vagy sem (nyilvanvaloan termek), hanem a koordinacio kulonbozo modjairol. A Red Hat szamara nyilvanvaloan termek a szoftver is, csak azt bizonyos kozonsegnek ingyen adja, mert ebbol is lehet uzletet csinalni. A kozosseggel minden bizonnyal egyutt fognak mukodni a jovoben is, mert ez az uzleti erdekuk.
-
Nezd, lehet itt filozofalni, de a lenyeg, h amit a GPL megkovetel, azt a Red Hat (stb.) kovetni fogja. Ha hasznalnad, akkor nem teszik lehetetlenne, nem is ertem, hogy ezt mire mondod. Az, hogy nem hasznalhatsz valamit ingyen, amiert penzt szeretne kerni az, aki csinalja, nem hiszem, hogy valoban serti a szabadsagodat. A szabad szoftverrol evtizedek ota ugy beszel a GNU, Stallman, stb., hogy az serti a szabadsagod, ha nem tudod modositani, nem tudod elolvasni a forrast, stb. Errol itt szo sincs.
-
-
> Tehát írsz egy programot, ezt felveszik fedora tárolóba, majd átkerül centos streambe, minkkét helyen kap valami pachet, majd pachelve átkerül enterprise linuxba. Ott bezárul és ha ott kap pachet az már zárt lesz.
Ha megveszed az Enterprise Linuxot, akkor hozzaferest kell kapnod a patchelt verzio forrasahoz. Viszont ha az Enterprise Linux nem szabadon letoltheto, akkor a forrasnak nem kell szabadon letolthetonek lennie.
-
Akkor vagy forkol a kozosseg, vagy szep lassan elveszti a hozzaferest. Azert nem tudsz beperelni valakit, mert a sajat munkajat nem akarja GPL alatt licenszelni.
Nyilvan mindenki penzt akar csinalni (mindenkinek meg kell elni), tehat akkor fognak szabad szoftvert gyartani, ha valami komplementer termekbol penzt tudnak gyartani. Ez ilyen alap uzleti trukk.
-
válasz
sh4d0w
#33311
üzenetére
> Mi lesz, ha eccercsak az IBM aszondi, hogy ez már az ő szellemi IP-je és magasról tesz a GPL-re
Szerintem nem tehet magasrol a GPL-re, tul kockazatos a jatek. A GPL senkit nem kotelez arra, hogy siman publikalja a kodjat, nem? Az usernek kell megkapnia.
Licenszet barmikor lehet cserelni, nyilvan, a kovetkezo verzioban.
-
#33177
emvy
félisten
arcoskönyv
#33176
válasz
arcoskönyv
#33176
üzenetére
Csak akkor, ha bugos. Hivatalosan egyik sem tamogathatja, a kernel elvarja, hogy a / az path separator, nem lehet fajlnev resze.
-
#33108
emvy
félisten
arcoskönyv
#33107
válasz
arcoskönyv
#33107
üzenetére
Vagy siman mehetne Tailscale-n keresztul SSH-val, es akkor meg privat/publikus kulcsokat se kell lerakni sehova.
-
válasz
#68216320
#33082
üzenetére
> Jelszókezelőt nem használok és nem fogok. Ez egyszerűen egy elvi döntés, nem bármiféle minősítése a szolgáltatásnak.
Mindenkepp hasznalsz 'jelszokezelest', marmint valahol mindenkepp tarolni fogod pl. a privat kulcsokat. Az a gyanum, hogy kevesbe biztonsagosan, mintha pl. a 1Passwordban tarolnad.
-
#32871
emvy
félisten
fatpingvin
#32870
válasz
fatpingvin
#32870
üzenetére
Mainline támogatás van rá már évek óta. Elvileg nulla problémával kellene működnie. Rengeteg laptopba rakták.
-
#32849
emvy
félisten
fatpingvin
#32848
válasz
fatpingvin
#32848
üzenetére
Hm, tehat ha van egy kisteljesitmenyu NAS-od, ami tenyleg olyan oreg, hogy csak SMB1-et tudsz, akkor arrol videostreamet fogsz nyitni, es mondjuk a ... smart TV-d ahhoz csatlakozik?
-
#32847
emvy
félisten
fatpingvin
#32846
válasz
fatpingvin
#32846
üzenetére
Mi a low-end definicioja? Fajlokat masolni egyik helyrol a masikra? Arra jo az SFTP.
Viszont ha mondjuk pl. filmet akarsz nezni a NAS-rol, arra mar kevesbe.
-
Mas kerdes: szekvencialis iras eseten a ZFS ZIL mennyit tud segiteni az irasi sebessegen?
Van egy QNAP NAS-om itthon, ZFS-t hasznalok rajta. 10G neten van osszekotve a szamitogepemmel, van benne 2 db CT1000P2SSD8 (Crucial P2 1 TB) SSD mint read/write cache, es 2 db ZFS mirror pool, mindkettoben 2x10 TB HDD. Az R/W cache alatt read cache + ZIL-t kell erteni.
A halon szekvencialis irasban kb. 250 MB/sec-el sikerul irni a HDD-kre. Nekem ez kicsit kevesnek tunik, de lehet, h nem kell a ZIL-tol ennel tobbet varni szekvencialis irasnal?
A masik: a Linuxos desktopomban ket kartya van:
0b:00.0 Ethernet controller: Intel Corporation Ethernet Controller I225-V (rev 03)
0c:00.0 Ethernet controller: Aquantia Corp. AQC113CS NBase-T/IEEE 802.3bz Ethernet Controller [AQtion] (rev 03)Az elso 2.5 GbE, a masik 10 GbE. Mindketto elegge eszi a CPU-t, tehat 2 Gbps forgalomnal mar tobb, mint egy egesz CPU core-t megeszik csak az, hogy fogadja a forgalmat. Ez normalis? Lehet rajta valamit javitani?
-
válasz
Archttila
#32829
üzenetére
NFS egy seggfajas, ha nincs minden rendesen behuzalozva, laptopon meg kb. mindig, mert az NFS az a protokoll, ami az egesz rendszert le tudja dogleszteni, ha epp nem elerheto a share.
Plusz a NAS-t az jo esellyel nem csak Linuxok kozott hasznaljak, hanem telefonok, hazimozi, mittudomen is.
Ez egyebkent tipikus linukszjuzer fassag, h:
- "Nem mukodik X, es muszaj lenne, segitsetek"
- "X-et ne hasznalj, inkabb Y a jo!"Ennyi erovel azt is mondhattuk volna, hogy 'vegyel masik NAS-'t.
> az smb1-et egyébként minden jobb helyen tiltják, mert lyukas, mint a szita.
termeszetesen, viszont egy otthoni halon filmeket osztani vszeg megfelelo, egyebkent is 'guest/guest' lenne az user/pass.
-
-
Na, megvannak az okok.
1) Az un. "tiled" kijelzőket, amiknek a nagy felbontás miatt több bemeneten kell egyszerre hajtani, csak a Gnome támogatja. A támogatás úgy működik, hogy a kijelző az EDID információkban közli, hogy ő egy tiled kijelző, és el is mondja, hogy milyen elrendezésben. Ezt a Windows, a Mac és a Gnome támogatja, más nem, ordas hackek vannak egyéb window managerekre, rossz eredményekkel.
2) a videón látható tearing egy Mutter bug (a Gnome Wayland-implementációja), javítás majd idővel érkezik.
-
Van otlet arra, hogy lehetne megoldani, hogy a dual displayport bemenettel rendelkezo monitor ket felen a scrollozas szinkronban legyen?
-
Tudja valaki, hogy KDE alatt meg lehet-e az csinalni, hogy ket ugyanolyan monitort egy logikai monitorkent kezeljen a rendszer? Azaz ha pl. maximalizalok egy ablakot, akkor mindkettot kitoltse, stb.
Use case: az LG 27" 5K kijelzom 2 db 2560x2880 felbontasu monitornak mutatja magat a gep fele. A Gnome gond nelkul megoldja, hogy egybe kezeli oket, de a KDE nem.
-
válasz
sh4d0w
#32798
üzenetére
Nem tudom, nem jottunk ra. Ryzen 3600-as szervereken neztuk, determinisztikusan softlockupoltak a gepek par naponta, tucatnyi. Default Ubuntu 22.04 minimal installacio + K8s.
https://forum.proxmox.com/threads/kernel-bug-cpu-soft-lockup-vm-host-freezes.110059/
Ezt talaltuk, ami kozel all a problemahoz.
"Since I downgraded to 5.11 it did not crashed while it was crashing several times a day on 5.15 and 5.19." -- ezt esetleg probald meg meg. Nekunk nem jott be.
-
A cegnel lattunk pont ilyet Ryzen szervereken, mas kernelekkel is. Mindegyik (tucatnyi) gepen elofordult sajnos, eros terheles alatt. Intelnel nem volt ilyen.
Azt lehet megprobalni, h a boot parameterekhez hozzaadod azt, hogy processor.max_cstate=1
Mondjuk ez kicsit megb*ssza az energiagazdalkodast.
-
tenyleg kis ceg vagyunk, igy az applikacionk csak havi 5 terabajt logot produkal, sok sikert a greppel akar egy napi lognal is! (Nem, nem lehet mindig mindent ELK-ban tartani. (journalctl | grep az tenyleg kismeretu logoknal jol mukodik, de akkor nem fogod tudni hasznalni pl. a beepitett indexalast)
vagy ha lenne, gondolom zéró munkával elő tudnád szedni.
![;]](http://cdn.rios.hu/dl/s/v1.gif)
Új hozzászólás Aktív témák
Hirdetés
- Vírusirtó, Antivirus, VPN kulcsok
- ROBUX ÁRON ALUL - VÁSÁROLJ ROBLOX ROBUXOT MÉG MA, ELKÉPESZTŐ KEDVEZMÉNNYEL (Bármilyen platformra)
- Windows 10 11 Pro Office 19 21 Pro Plus Retail kulcs 1 PC Mac AKCIÓ! Automatikus 0-24
- Eladó steam/ubisoft/EA/stb. kulcsok Bank/Revolut/Wise (EUR, USD, crypto OK)
- Bontatlan - BATTLEFIELD 1 Collectors Edition - Játékszoftver nélkül
- BESZÁMÍTÁS! ASRock FORMULA OC RX 6900XT 16GB videokártya garanciával hibátlan működéssel
- Samsung Galaxy Xcover 5 64GB, Kártyafüggetlen, 1 Év Garanciával
- Telefon felvásárlás!! iPhone 14/iPhone 14 Plus/iPhone 14 Pro/iPhone 14 Pro Max
- HGST HUH721010AL5200 10TB 7.2k SAS HDD, DELL branded, nettó 38000Ft + ÁFA, 1 év garancia
- Acer Nitro 5 -AN515 - 15.6"FHD IPS 144Hz - i7-11800H - 16GB - 512GB SSD+1TB HDD -RTX 3050 - Garancia
Állásajánlatok
Cég: Promenade Publishing House Kft.
Város: Budapest
Cég: PC Trade Systems Kft.
Város: Szeged