- AMD Ryzen 9 / 7 / 5 7***(X) "Zen 4" (AM5)
- AMD K6-III, és minden ami RETRO - Oldschool tuning
- TKL formátumú, vezetékmentes "Fekete Özvegyet" dobott piacra a Razer
- A partnerektől függ, hogy lesz-e Arc csúcs-VGA az aktuális generációban
- Hobby elektronika
- Elkezdtek szállingózni az Arctic P Pro sorozatú ventilátorai
- Vezeték nélküli fülhallgatók
- Milyen egeret válasszak?
- Melyik tápegységet vegyem?
- Házi barkács, gányolás, tákolás, megdöbbentő gépek!
-
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
bambano
#29496
üzenetére
Az ilyen webes kódoktól a hideg is kiráz... Meg úgy a webfejlesztéstől alapvetően
![;]](//cdn.rios.hu/dl/s/v1.gif)
(#29499) Frawly
tényleg csak arra lesz jó, hogy valaki megpróbálja jogászkodással a felelősséget áthárítani valaki másra Gyakran ez egy igen fontos szempont.
Szerintem a licenccel sincs probléma, főleg nem szerveren, mert a legtöbb szerveres dolog pont GPL-es opensource. Egy random rolling distrónál ki garantálja, hogy minden ami benne van jogilag jó? Egy normál distró esetén minden verzió adott, bármikor pontosan meg lehet mondani, hogy mit használunk, abban benne van-e egy adott rés stb.
-
Frawly
veterán
Na, látod, ezt nem kéne tényként kezelni. A rolling semmivel nem alkalmatlanabb, mint a fizetős vállalati disztrók. Ez megint csak marketing miatti sztereotípia. Igazából aki ért hozzá, annak mindegy mit használ, meg tudja válogatni az eszközöket, licenceket, meg ha valami probléma lenne, meg tudja oldani magának. Pont ez a Linux szépsége egy Windows Server ellenében, nem is a licencdíjon spórolos, hanem Linuxon minden problémát tuti meg lehet oldani, sokféle alternatívára lehet azon belül támaszkodni, és nem vagy egy multicég zárt forráskódú megoldására rászorítva, ami vagy működik, vagy nem, újraforgatni nem tudod, alternatívák nincsenek rá.
Én nem is szeretek céges supportra támaszkodni. Mert mi van, ha a supportáló cég tönkremegy, lehúzza a rolót? Vagy épp a supportjuk XY problémánál nem tud segíteni? Akkor sok ilyen felelősségetelhárítós, öltönyös-nyakkendős, hojjdeszupport-de-szupport-100-évig-eltéess lúzereknek nagyon gyorsan megáll az élet, és megy a pánikolás, hogy nem megyen a szerver, maja világvége, rohanjon mindenki a bunkerba túlélni. Aki idióta a dolgokhoz, meg gányol, azon egy support meg egy hosszú támogatási idő sem fog tudni segíteni, tényleg csak arra lesz jó, hogy valaki megpróbálja jogászkodással a felelősséget áthárítani valaki másra.
Szerintem a licenccel sincs probléma, főleg nem szerveren, mert a legtöbb szerveres dolog pont GPL-es opensource. Ez a nonfree csomagok problémája inkább a desktopot, DRM-es és egyéb dolgokat érintik, ezek meg szerveren nem létező probléma. Meg igazából a legtöbb céget nem szokta zavarni a licenc, rezzenéstelen arccal tolják a rendezetlen licencű ZFS-t, meg hasonló megoldásokat. Ahol meg annyira licencfetisiszták, ott meg pont BSD-t szoktak használni Linux helyett, mivel megengedőbb a licence, igaz cserében a leghosszabb támogatási idő BSD-ken 5 év max.
Azt én is néztem, hogy a SUSE-nek a leghosszabb a támogatási ideje, 12 év. Ja az jó hosszú. Persze a CentOS 11,5 éves támogatása se piskóta, szerintem az is overkill kategória erősen.
-
haddent
addikt
válasz
bambano
#29496
üzenetére
Hát ezért vannak a webpack meg társai. Felszippantja az összes includeot, összegyúrja, minimize aztán ott van egyetlen (vagy több) saját kis js csomag. A fejlesztés további része, ha megszűnne egy csomag támogatottsága jó kérdés lenne, de ebbe ne menjünk bele, mert egyetértenénk, hogy a js mekkora egy undormány hányinger és itt nincsenek hozzászokva, hogy egyetértünk
-
válasz
Frawly
#29486
üzenetére
Bármi ami rolling vállati környezetbe teljesen alkalmatlan. Valami kétes licensz-el rendelkező dolog bekerül akkor az tud rohadt nagy gondokat okozni. Kritikus szerver az Redhat vagy nem open Suse.
haddent: ráadásul most már a leap opensuse az konkrétan az SLES alapján megy, a .x verziók a service packek. Szóval konkrétan ki lett tolva a támogatási idő.
-
haddent
addikt
válasz
samujózsi
#29490
üzenetére
A suse nem rolling, csak van rolling IS. A Leap 15.1 sima LTS, a Tumbleweed a rolling. Attól függetlenül, hogy rolling amennyire tudom elég megfontolt lépésekben halad. Ettől tényleg kár tartani. Arch -tól jogosan tartasz, minden pacman -syu és reboot után kicsit szurkolni kell, nagy ritkán néha helyrerakni, oszt?
-
samujózsi
senior tag
válasz
bambano
#29487
üzenetére
A 20.04-re kicsi az esély. A 16.04 kb így került a vasra, úgy egy héttel a megjelenése után, de csak kényszerből, mert a régebbi kernelekkel voltak gondok az akkor vadonatúj procin, ebben találtam olyan kernelt ami többé-kevésbé jól kezelte a hardvert.
Az új rendszerekben sok a bug, ezért is tartok kicsit a rolling release-ként megjelenőktől (arch, suse). -
haddent
addikt
válasz
Frawly
#29486
üzenetére
Tudom ez (akartam) írtam én is kb. Utolsó részt annyival egészíteném ki, hogy itthon tök szívesen hegesztek bármit, mert jó érzés, szeretem, sikerül is meg tényleg minimál, friss, jó. De munkában biztos nem fogok nekiállni. Száz milliókat fizetünk vasért, milliókat supportért. Felrakom, menjen. Ha nem akkor kiverem a hisztit, hogy 2 órán belül azonnal bugfix, mert nem fejlesztésért fizetnek, nem végzem el helyettük a munkájukat mert se időm se kedvem ilyen keretek közt productionben nem saját cuccon. Tehát teljesen jó ez úgy ahogy van, mindennek megvan a saját helye
-
Frawly
veterán
válasz
bambano
#29487
üzenetére
A várással nem értek egyet. Nincs értelme várni, ennyi erővel mindig várhatnánk valamire. Ha most kell OS a szerverre, akkor most kell, azt kell feltenni, ami már most megjelent. Egyébként pont ez is a rolling előnye, nem kell semmilyen kiadásra várni, meg külön disztrófrissítésekre időt dedikálni.
Egyébként meg attól is függ, hogy mekkora támogatottsági időt akar. Ha nagyon hosszú támogatottsági idő kell, akkor a CentOS 8.1 a legjobb jelenleg ebből a szrmponból, az 11 és fél évig támogatott lesz még, ennyi év után meg nem az lesz a szempont, hogy a telepített rendszer elavul (mert az el fog már 2-5 év után avulni nagyon csúnyán, a régi verziók nem fogják tudni semmi újabb szoftvernél kielégíteni a verziófüggőséget), hanem a gép hardverügyileg is teljesen elavultnak fog számítani addigra. Vagyis vannak ennél hosszabb támogatású disztrók is, de azok már fizetősek tudtommal.
-
Frawly
veterán
válasz
samujózsi
#29478
üzenetére
Celeron meg Celeron között óriási különbségek vannak, de a 8 GB RAM-ból úgy tűnik, hogy egy modernebb, DDR3-as vagy DDR4-es rendszer, arra mehet az Ubuntu 18.04 is. De én mindenre Archot teszek, ami támogatja, akár in production szerverre, akár hobbi kenyérpirítóra. Semmilyen gond nincs a stabilitásával, főleg nem szerverre, amikor úgyis csak egy kernel, konzol, tűzfal fut, meg néhány szerver daemon, de nem futtatsz rajta grafikus felületet, meg egy csomó sallangot, így nincs is nagyon mi eltörjön.
A Debian Testinget rég nem néztem, de az Arch stabilitásával semmi baj nincs, én kapásból feltenném mindenre, ami architekturálisan támogatja, akár csak az Arch32-őt, vagy Artixot, és nem túl lassú rajta.
De a szerver is relatív fogalom, milyen szerver, milyen protokollokon szolgál ki, milyen gépeket, hányat? Helyi szerver vagy netre van kötve? Elég sok tényező van.
(#29479) haddent: az Arch komolyságával nincs semmi gond. Vállalatoknál azért nem szeretik, mert sok helyen nem ismerik, nincs hozzá annyi beginner leírás, mint a szokványosabb disztrókhoz, nincs vele tapasztalat annyi évtized, mint a már befutott Ubuntu, Debian, akármi disztrókkal, és az Arch mögött nincs semmilyen corporate háttér, hogy fizetős támogatást, vagy bármi garanciát tudnának hozzá venni. Semmi LTS meg egyéb nincs belőle, sőt, kapaszkodj meg, támogatás sincs hozzá, nem hogy 5-10 év, de 0 év sem. Magadnak támogatod. Ha nem ért hozzá valaki olyan szinten, hogy nem tudja magának támogatni, akkor tényleg ne tegye fel, telepítsen helyette Ubuntut.
A cégek, szervezet egyszerűen konzervatívak, lusták, rugalmatlanok, se frissíteni nem szeretnek, inkább beragadnak egy régi technológiába és egész addig halogatják a frissítést, amíg csak lehet. Ilyen mentalitással nem is való az Arch, nem is annak a hibája, ha valaki nincs rá megérve. Akkor tényleg nem jó ötlet erőltetni.
-
haddent
addikt
válasz
samujózsi
#29482
üzenetére
Nézd ez nem kérdéses, hogy egy LTS enterprise háttérrel bíró disztro az nagyobb nyugodtság sokaknak, mint egy Arch rolling bleeding edge cucc
De... ennek ellenére, én speciel jobban elvagyok Arch-csal, viccen kívül. Minden másnak, pl suse, centos, ubuntu vannak olyan irdatlan disztro-specifikus fa#*@!ágai, amiket nem csipázok, főleg, hogy jól láthatóan a "vanilla" tök jól, jobban működik és így... demiiilllyyjért?! 
Illetve amikor beüt a krach, akkor tudom, hogy mivel és hova kell nyúlni.
Amúgy nem kötekedés meg semmi, de szerintem suse esetén valamit benézhettél, nem lenne alapvetően indokolt, hogy többet egyen bármi másnálvargalex semmi nem hatja meg, tényleg. Volt 2 proci csere, 3 NIC csere, ram össze-vissza, ssd amin van volt, hogy live!!! futó rendszert önmagával átt dd -tem egy másik ssd -re, majd csere és a klónt használom most is
Vicc, imádom 
-
Mr Dini
addikt
válasz
samujózsi
#29482
üzenetére
Fedora szerver nem jöhet szóba? Hatalmas az image, de nagyon jól teszi a dolgát nálam (dedikált szerverek). Selinux van, de nem kötelező használni. Stabil és friss csomagok vannak, csak egyszer futottam bele, hogy a grubot kiadták hibásan, ezért nem frissült a kernel lista.
Vagy az, vagy Alpine, vagy Ubuntu Server.
-
samujózsi
senior tag
válasz
haddent
#29479
üzenetére
Na OpenSuSE SoSE
Úgy általában nem lenne vele bajom, de a szervernek csúfolt gépemen be sem bootolt.
Sem a hagyományos, sem a rolling ág.
A RH variációknál meg ott a SELinux, ami elvben tetszik, de a gyakorlatban ha valakinek sikerült vele elbarmolni valamit (én :D), az nem biztos, hogy újra hozzá mer nyúlni.
-
haddent
addikt
válasz
samujózsi
#29478
üzenetére
Természetesen semmilyen komoly helyen nem használnak Arch -ot productionben. A tipped, hogy Debian testing szerintem nem jó. Egyik oldalról valószínűleg a Debian testingnél is még sokkal gyorsabb, frissebb csomagok vannak benne, másik oldalról viszont sokkal jobban karbantartott, nagyobb, érdeklődöbb közösség által. Mondjuk így "szumma kábéra" lehet pont kijön.
Arch esetén egyébként pacman -t kell kicsit megtanulni, ezen felül minden alapvető dolog (is) vanilla.Nyilván neked kell tudnod dönteni, én jó szívvel ajánlom az Archot szervernek is, nálam lassan 3. éve fut gond nélkül. Pár havonta nagy update esetén előfordul 1-1 kernel panic, mert 1-1 csomag nem érzi jól magát a többi közt, ilyenkor chroot, eggyel régebbi package fel, aztán megy minden tovább mintha muszáj lenne neki
Általad is leírt szempontok miatt (is) nálam ő a baremetal host, rajta vannak a kvm -ek, docker mindenIlletve alternatívának én valami valódi enterprise server os -t választanék már, pl. openSUSE, redhat, centos. Mi/én most melóban is openSUSE mellett döntöttem, saltstack is tök jól integrálódik stb.
-
samujózsi
senior tag
Azon méláztam az előbb, hogy ha végre újrahúzom a szerverem, mit tegyek rá: Ubuntu 18.04 server-t vagy arch linuxot?
Előbbi mellett szól, hogy ismerem, viszonylag stabil, ellene, hogy kicsit túl nagy, a gépem meg egy gyengécske celeronos darab, 8GB RAM-mal.
Utóbbi mellett szól, hogy pici, gyors, viszont ellene, hogy nem is ismerem mélyebben és ami mindennél jobban zavar, hogy rolling release, ami (legalábbis az arch esetében) olyan érzést kelt bennem, hogy stabilitásban/megbízhatóságban valahol a debian testing környékén lehet.A kérdés: van olyan komolyabb hely, ahol az arch egyáltalán szóba jön, mint szerver OS? Meg úgy általában: mi a közvélekedés a rolling release-ekről? Merjek belevágni, ha a stabilitás legalább olyan fontos, mint a kis erőforrás igény?
-
haddent
addikt
válasz
Mr Dini
#29472
üzenetére
Őőőő na várjál, 2 órát aludtam az éjjel előre is elnézést, ha .. de.. Routered nat listája mennyiben függ össze egy linux szervered iptables -ével átirányítva egy másik szeróra? Ha van routered, akkor úgyis azon kell natolnod, nem? Ekkor viszont csak egy accept kell a szerveren -A INPUT -p tcp --dport 32400 -j ACCEPT kb ennyi
-
Mr Dini
addikt
-
haddent
addikt
válasz
Mr Dini
#29457
üzenetére
Talán kicsit megkésett és hát nem is ez a csuda firewalld, de iptables legalább működik, mindig
iptables -t nat -A PREROUTING -p tcp -i BEJÖVŐ_INTF --dport 42300 -j DNAT --to-destination fedora.server.ip.cime:32400iptables -A FORWARD -p tcp -d fedora.server.ip.cime --dport 32400 -m state --state NEW,ESTABLISHED,RELATED -j ACCEPTEzeket az ufw, firewalld meg egyéb kotlákat sosem értettem személy szerint. Plusz absztrakció, össze-vissza kever mindent egy átláthatatlan katyvasszá, de szinte ugyanolyan explicit módon cli -ből írod. Nekem vagy iptables vagy (és) valami webes felület rá ahol tudok értelmesen rendszerezni. Oké túloztam és hazudtam, vannak baromi jó cli -k, csak az nem az ufw/firewalld, hanem mondjuk a forti tűzfalaké vagy a vyos
-
-
bambano
titán
bocs, hogy offolok, de a szaktopic halott.
debian, linux, latex.egy olyan számot kellene kiírnom a dokumentum elején, ami a kiírás idején nem ismert, csak később lesz az. a problémát és a megoldást is pont úgy képzeltem el, mint a \lastpage, a page x of y típusú lapszámozásból.
a gond az, hogy a weben látott megoldásokkal nem tudom írni az .aux fájlt. valakinek van működő ötlete erre?
-
Dißnäëß
nagyúr
válasz
samujózsi
#29464
üzenetére
Én is ipchains, de folytattam kézzel netfilterrel, nem is értettem jópár rajzig, mi van
Ezt is átbújtam töviről hegyire anno.. azért itt sokminden ülepedett.De amúgy ma már annyira komplex a védelem mint olyan, hogy túl időigényes kézzel tolni, absztrakt réteget kényelmesebb nyomkodni, egy ideje ismerkedek az OPNSense-el egy VM-ben, hát GUI ide vagy oda, van egy logikája...
-
samujózsi
senior tag
válasz
Dißnäëß
#29463
üzenetére
Köszi, de annyit azért tudok, hogy tudatlanul jobb nem piszkálni a netfilter táblázatokat és azt is tudom, hogy nem értek hozzá.
Az ipchains-t még nagyon bátran piszkáltam, aztán jött a netfilter/iptables, azóta csak valami ufw jellegű eszközzel... nagyon ritka, ha másképp hozzá merek nyúlni. -
Dißnäëß
nagyúr
válasz
samujózsi
#29460
üzenetére
Én mai napig iptables-t használok, kézzel, bár az ufw könnyít(het) dolgokon.
Csekkold az iptables-persistent-et (apt install iptables-persistent), /etc/iptables könyvtárba kell és lehet a meglévő ruleset-et kitenni rules.v4 és rules.v6 fájlokba (legalábbis nálam spec, bár v6-ot nem használok sehol, így üres), iptables-save > rules.v4, ip6tables-save > rules.v6 és ezeket utána minden boot-nál tölti szépen be.Mr. Dini: iptables -Lcsak a filter tábla szabályait mutatja mindig, defaultban a filter-en mókol, Neked pedig a nat táblában is kell ügyködni. Tehát iptables -t nat -L |less és ha az is üres, akkor kvázi nincs se nat, se csomagszűrés, se semmi, feltételezhetően policy-k is ACCEPT-en mindenhol, magyarul nyitott, default tűzfalad van, azaz bocs, nincs.
Gyorsan guglizva egy jó tutorial, a csomagok útja a kernelen keresztül ascii ábrácska arany.
[link] -
sh4d0w
félisten
válasz
samujózsi
#29460
üzenetére
Fogalmam sincs, amit írtam, az iptables-re vonatkozik. De egy szösszenet:
Firewalld currently does not support outbound rules to the same capacity of inbound rules. Limitations include things such on ipsets, service names, and default outbound block by default rules required by standards such as NIST 800-171 and 800-53. Default block all needs to be done at the "raw" IPTables level via the --direct flag, and with the order of operations FirewallD uses to prioritize Rrules, rich rules, direct rules, it may be easier to enter all rules for outbound via --direct or use iptables (netfilter-persist)
-
-
samujózsi
senior tag
válasz
Mr Dini
#29457
üzenetére
Bocs, tudatlan "szakértőtől" is jöhet tipp?
Nem ismerem a firewalld-t, de ha totál üres az iptables -L akkor ott valami nem kerek. Vagy kizárólag erre használnád?
Valami rémlik az olvasmányaimból, hogy a szabályok beállítása után kell neki valami commit vagy reload.
Illetve (gondolom, systemd rendszer) nem lehet, hogy a firewalld service nincs engedélyezve/elindítva? -
Mr Dini
addikt
Üdv!
Sehogy nem bírok rájönni, hogyan tudnék egy bizonyos portot forwardolni, majd elérhetővé tenni a neten firewalld-vel. Ezekkel a parancsokkal próbálkoztam:
firewall-cmd --add-masquerade --zone=FedoraServerfirewall-cmd --zone=FedoraServer --add-forward-port=port=32400:proto=tcp:toport=42300firewall-cmd --add-port=42300/tcp --zone=FedoraServerA cél az lenne, hogy a 32400-on futó Plex szerverem kintről a 42300-en legyen elérhető ideiglesen. Viszont ez nem működik. Fedora 31.
Ami még rettentő érdekes, hogy az iptables is üres:
iptables -LÖtlet?
-
Dißnäëß
nagyúr
válasz
a.gabriel
#29455
üzenetére
Sok iszonyatosan jól szóló konfig létezik amúgy, de mind natív futtatást igényel, amiket én ismerek. Csak egy zenelejátszónak pedig felesleges PC, de persze mindenkinek szíve-joga azt használni, amit akar.
Aki ragaszkodik PC-hez, az is ki tudja vinni az I2S jelet, a Pink Faun I2S kártyájával, de azt még nem próbáltam. Aki igen, dicséri, miért is lenne rosszabb egy Pi-nél..
-
bambano
titán
válasz
haddent
#29453
üzenetére
ne találgassunk, hogy milyen irányba kell elmenni, az volt a kiinduló premissza, hogy telemetria adatokat kell kinyerni egy jáva virtuális gépből és tárolni egy adatbázisban.
mivel ugyanaz a kéz írja meg a csv legyártó rutint a jáva alkalmazásba, mint a többit, így a csv formátumával kapcsolatban nem kell jóhiszeműnek lenned, az van benne, amit kitoltál saját kicsi kezeddel.miután egy ilyen csv adatbázisba töltése egy triviális sed program, a json értelmezéséhez meg rakás szubrutin kell (tökmindegy, hogy te írtad meg, vagy más), így a végeredmény az, hogy mind hatékonyság, mind gépi olvashatóság szempontjából a csv utcahosszal veri a pythonos meg hasonló lomokat. könnyebb megírni, nincs karbantartási igénye, nem kell csomagokat telepíteni, mert sed minden unixon van, nem kell csomagokat upgradelni, stb. stb. stb. így továbbra sem értem, mi a francért megy az erőlködés json/xml irányba, mikor a csv látványosan jobb minden szempontból.
lehet vitázni arról, hogy teljesen általános csv parsolása milyen, én nem fogok részt venni egy ilyen vitában, mert nekem nem ez volt a kiinduló állításom.
-
haddent
addikt
válasz
bambano
#29443
üzenetére
Nem, ezen valóban nem lehet vitatkozni, mert pontosan gépi feldolgozás szempontból tulajdonképpen zseniális, de visszamehetünk teljesen elemi, matematikai feldolgozásra, azazl formális nyelvek és automatákra, nagyon szép, egyszerű, lineáris determinisztikus automatával felismerhető nyelv. A CSV már ott egy rakás szar, hogy nincs konkrét szabvány, de ha ezt félretesszük és jóhiszeműen feltételezzük, hogy mindenki a nevében szereplő comma -t használja, akkor is egy káosz egy json/yaml -hez képest. Ez nem szubjektivitás kérdése egész egyszerűen.
Ha esetleg netán elírtad volna és pont fordítva értetted, tehát, hogy "humán" szemszögből ronda, akkor elnézést a "kirohanásért", ehhez a véleményedhez nyilván tökre jogod van
Vagy megint elmehetünk olyan irányba, hogy nagyon végtelenül primitív egyszerű adat (struktúrának nem nevezhető) kis szösszeneteket ki lehet fosni csv -ben is, csak akkor meg elő fog jönni az a tipikus eset, amikor pl. syslog esetén nem az RFC szabvány szerint logol valaki/mi, "me' megspórolunk 3 bitet!" aztán amikor valaki parsolni, értelmezni, aggregálni, rendszerezni szeretné (pl ELK, Graylog) akkor majd írjon magának hozzá egyedi lószart, vagy töltsön le plugint, nem ám 1 kattintás a szabvány szerinti
-
Dißnäëß
nagyúr
válasz
samujózsi
#29446
üzenetére
Ha megmondod, melyik típus, lehet tudok egy jobb formware-t is ajánlani Neked.
Enyémen Padavan becenevű van egy fél éve, toronymagasan veri a gyárit, pedig az sem volt rossz (sőt). Esetleg guglizd körbe. Annyi, hogy ha ASUS-nál regisztált dinamikus DNS-ed van, az ugrik az új firmware-el, nem hajlandó felvenni a gyári fw-el beállítottat. Vagy ASUS Support-al kell töröltetni, vagy elfogadni, hogy elég kretén megoldás. (És a supportot elérni is elég kretén náluk, sajnos). -
Dißnäëß
nagyúr
válasz
a.gabriel
#29432
üzenetére
Szia, szerintem eléggé nyűgös konfigba fogtál. Az audiophile linux és társai lényege, hogy spéci kernellel, kicsit más erőforrás-elosztással és latency-kkel próbálják támogatni a hallgatózás élményét. Hogy ezeknek van-e értelme, vagy nincs, én arról nem mennék ölre senkivel, de aki ezeknek (feltételezett) előnyeit úgy gondolja, meghallja és élvezni akarja, az natívban kell, hogy futtassa ezen oprendszereket, nem pedig VM-ben.
Nos, ha már virtualizációnál vagyunk, a Matrix kártyádat a hypervisor-nak először is ki kell tudnia publikálnia a VM-ed felé, hogy az 1:1 lássa és a host egyáltalán ne üljön rajta, ott csak egy buta bypass van. Ez már félmegoldás, más, hogy képes-e erre a VMWare. Csípőből azt mondanám, miért is lenne, de lehet, mákod van. Így látni fogja a VM-be tett OS a karit, MAGÁT A KÁRTYÁT, nem az emulált valamit ... az arra tett külső DAC-ot is, de itt meg is szűnt a móka java, a sztori másik felét az életbe nem pótolod be egy VM-ből (lásd első mondatok).
Sajnos vagy sem, ha hiszel az ilyen audiophile linux dolgokban, natívan kell őket a gépen futtatnod. Tesztelni tesztelhetsz, nyomogathatod, milyen a kezelése, stb stb, tanulni jó a VM, de a végén natívba kell feltenned a zenelejátszásra dedikált vasra.
Én ilyen célra Volumio-zok, Raspberry Pi4-en, I2S kimenetre reclocker és arra balanced HDMI out PS Audio formátumban, így megy az I2S jel a külső DAC-ba, mondjuk egy Matrix Audio X-Sabre Pro-ba, Volumio-ban pedig csak I2S-re állítom a kimenetet, hálózatról pedig a NAS-ról játszik a gép és ollé. Egy ilyen konfig általában.. hogy is mondjam.. büntet.
-
Dißnäëß
nagyúr
válasz
samujózsi
#29429
üzenetére
Szia, ha mindent és mindenkit be szeretnél terelni proxy-ba, úgy, hogy ne kerülhessék meg, én úgy csinálnám, hogy:
- transzparent proxy setup, 80, 443 kienged, meg még amit akarsz-akarnak az appok, persze proxy-tól függ, utoljára a tintahallal mókoltam ilyet, annak konfigjában is kellett túrni, hogy ő most transzparens proxy ezentúl
- böngészőkben így semmit nem kell állítani, extra portokhoz kellhet külön SOCKS5 proxy esetleg..
- iptables-el natolva vannak a kliensek gondolom, nat tábla FORWARD láncban tiltani a forgalmat kifele, akár az egészet, akár csak bizonyos portokat, de inkább az egészet és akkor csak lyukat ütni annak, amit elérhetnek a kliensek
- B opció, talán csinosabb is, bár nem annyira paraméterezhető akkor a "szűrés", hogy C osztályú hálón ülnek a kliensek mondjuk, de nincs semmi nat-olás és nincs routing-juk a net irányába, nincs gateway-ük, csak egyetlen gépnek, amit - természetesen - látnak. Ezen fut a proxy, aztán hajrá.
A fix gép lehet egy mondjuk 0.1-0.10-es fix ip tartományú régióból valami, amit "papíron" tudsz követni (MAC cím alapú DHCP által osztott-at szoktam én csinálni amúgy, de ha fontos szerverek, ne függjenek a dhcp szerver leállásától, inkább kézzel állítanám be rajtuk a fix ip-t), 0.10-től felfele meg a DHCP szerver oszt már ip-ket a pool-nak és jónapot.
-
inf3rno
nagyúr
válasz
Jester01
#29440
üzenetére
Elég beírnom konzolba, hogy node, a repl szükségtelen, azért nem is jegyeztem meg, most kerestem elő google-el, hogy ne véletlen shellt vagy ilyesmit írjak. A node egyébként csomópontot jelent, nem nehéz megjegyezni. Fájl kezeléshez mondjuk kell az fs modul, ami file system, szintén elég szokványos rövidítés. Azon belül mondjuk egy fs.createReadStream vagy fs.readFile nem okoz nehézséget, hogy mit jelent, de ha mégis, akkor a számítástechnika alapjai sem mennek. Ezzel szemben az "ls -1 node_modules | wc -l " ránézésre kínai, vagy akár jelentheti azt is, hogy "let's shit node modules or go to the wc". Persze magyarázhatod tovább, a lényegen nem változtat.
-
Jester01
veterán
válasz
inf3rno
#29435
üzenetére
Ja mert a node repl az annyira érthető
Belekötöttél a grep-be, a repl meg a Read-Eval-Print-Loop rövidítése ... ez mennyivel jobb? A node meg tök értelmetlen és semmire sem utal. Azt, hogy a node alatt nem 50 idióta nevű modul van már csak halkan említem meg, pl. az egyik projektünkben:$ ls -1 node_modules | wc -l
477 -
Frawly
veterán
válasz
a.gabriel
#29430
üzenetére
Az mpd.conf fájlban a hangkártya számának átírása után tudsz menteni a Ctrl+X paranncsal, helyesebben ez kilép, de előtte meg fogja kérdezni, hogy mented-e, arra nyomsz egy y billentyűt, majd Enter, és ott újabb Enter a fájlnévre, és ki is lép.
A Synology NAS-t nem ismerem, de az mit takar, hogy nem látod? Hol keresed, milyen formában tudod elérni más OS-ek alól? Samba megosztás, vagy NFS megosztás, vagy hogyan?
Egyébként nem akarlak elkeseríteni, de ezek az audiofil disztrók nagy parasztvakítások. Teljesen szokványos Linux disztrók, annyi, hogy van bennük egy low latency kernel, amitől egyébként megint csak nem lesz jobb a hangzás. Hozzá nem értőket hülyítenek vele, mint az aranyozott csatlakozókkal, meg a 192 kHz-es mintavételezéssel.
Ha kezdő linuxos vagy, kezdj el Mint-et vagy Ubuntut használni. Low latency kernelt azokra is feltehetsz, meg zenelejátszókat, mpd-t, stb., és azokon mindenféle terminálos fájlszerkesztés nélkül állíthatod grafikus felületen, hogy melyik hangkártya lesz a kimenet.
Kiváló hangzásod nem az OS-től lesz, hanem
1) Rendes DAC vagy hangkártya, aminek jó a DAC-ja és kicsi a zaja, torzítása
2) jó erősítő esetleg
3) nagyon jó hangfal vagy fej/fülhallgatóSzoftveres oldalról meg csak annyi a teendőd, hogy ne túl alacsony bitrátás, meg gány encoderrel készült audio anyagokat hallgass.
-
bambano
titán
válasz
inf3rno
#29436
üzenetére
matlogból gyengén állóknak:
A állítás: valami szabványos
B állítás: valami szépen formázotteredeti állítás: az A and B halmaz eleme a json. ezt sugallja a mondat.
szerintem a json nem eleme B, tehát nem szépen formázott.
vagyis amit írtam, nem úgy kell értelmezni, mint ahogy te tetted (helytelenül), hogyha valami nem (A and B), akkor abból következik, hogy nem A, hanem úgy kell értelmezni, hogyha valami nem(A and B), akkor vagy (nem A) vagy (nem B). és itt most konkrétan nem B. -
inf3rno
nagyúr
válasz
samujózsi
#29421
üzenetére
Ja, de senki sem követi, akkor meg sok értelme nincsen. A JSON meg az XML ezzel szemben standard formátumok. De ha ezen belül is kell valami szabvány külön logra, akkor vagy külön MIME típust kell valamelyik fölé gyártani, ami meghatározza, hogy milyen property-k lehetnek pl egy JSON-ban. A másik megoldás az RDF vagy XML+RDF vagy JSON-LD, aminél lehet vocabot gyártani az adott célra. Nekem egyébként az szimpatikusabb, mert könnyebb módosítani, bővíteni, mint egy szabványt. A schema.org pl ilyen, csak az nem logokra van.
Sokszor jobbak a kész megoldások. Azért érdemes belenézni a kódba, mert ha sűrűn megy az eval, akkor pl injektálhatnak. Markdown parsereknél láttam ilyesmit azt hiszem.
-
inf3rno
nagyúr
válasz
bambano
#29420
üzenetére
"mondtam én, hogy * nem szabványos formátum? hint: nem mondtam." (*: a JSON)
"Monitoring adatokat pont, hogy igenis valamilyen sztenderdizált formátumban és azon belül is szépen formázva adunk ki,: vagyis csv-ben, és még véletlenül sem json-ben."
Egy kicsit önellentmondóak a hozzászólásaid.
-
inf3rno
nagyúr
-
Jester01
veterán
válasz
a.gabriel
#29430
üzenetére
ebben a dac list cards > /etc/mpd.conf látszik a DAC
Én nem látom, csak egy valószínűsíthetőleg SB128 kártyát amit gondolom a vmware emulál. Ha ez megfelel nem kell semmit csinálni mivel az a hw:0,0.
Átírni még áttudom, de nem tudom, hogyan kell elmenteni a megváltoztatott értéket.
Ott van alul a súgó: ctrl+o elmenti, ctrl+x kilép.
Ha azt az usb izét akarod használni akkor gondolom a vmware-nek kell megmondani hogy adja oda a virtuális gépnek.
-
válasz
a.gabriel
#29430
üzenetére
- továbbá az otthoni hálózatomon lévő synology nas-t sem látom, bármit teszek, mert ott tárolom az audio gyűjteményemet (böngészőn van net, tehát lát kifele a gépből)
Bridged-re kell állítani a VM hálókártyát. Ilyenkor a VM-ed az otthoni hálózattól kap címet DHCP-n és mindent látni fogsz.
(#29422) haddent Ez sem teljesen igaz, megfelelő környezetben egy managed kód lehet gyorsabb, mint egy C kód. A memória foglalás nagyon drága, persze ha jól csinálod akkor foglalsz egy gigás hugepage-et, de eddig a C programozók 99%-a nem jutott el. Mondjuk egyesek egy mmap-ig sem
A Linux kernel kb. objektumorientált kód ANSI C-ben. Van ott minden öröklődés, függvény pointerek, polimorfizmus, csak C-ben... Szóval nem explicit, de egyértelműen használva van. -
a.gabriel
tag
Nem tudom, hogy ide kell feltenni ezt a kérdést, de a Zenelejátszó építése a kiváló hangzásért topikból tanácsolták ezt nekem.
A problémám a következő:
Saját kíváncsiságomra vmware alá feltettem próbaképpen az Audiophile linux v.5 legutolsó verzióját.
Sikerült a teljes install ( a honlapon lévő lépéseket követve), de mivel most csináltam először ilyent, el vagyok akadva, mert teljesen ismeretlen a linux világa számomra.
két dologban kérném a segítségeteket:- a gépben van egy matrix audio usb3 kártya és a végén egy nuprime udsd dac, ezt nem tudom bekonfigurálni a DAC setup-ja alá, hogy meg is szólaljon
- továbbá az otthoni hálózatomon lévő synology nas-t sem látom, bármit teszek, mert ott tárolom az audio gyűjteményemet (böngészőn van net, tehát lát kifele a gépből)Innen sem tudom, hogyan tovább?
Hogyan kell beállítani, hogy a dac-t lássa a rendszer, és meg is szólaljon róla a zeneBoot:
Menu jobb egérgombbal előhívás után
Dac setup
Dac setup > list cards
Dac setup > edit mpd/comf
- ebben a dac list cards > /etc/mpd.conf látszik a DAC, csak nem tudom, hogyan kell átállítani benne a a lejjebb található értékre.
A honlapon itt szerepel az információ
1. Select “List cards” from the menu
2. Put your card in /etc/mpd.conf. Select “Edit mpd.conf”
3. Change this line:
device “hw:0,0”
to:
device “hw:1,0”
if needed.
It’s better to put the name of your card in mpd.conf like this:
device “hw:PCH”
Because cards in Linux often switch numbers.
Restart mpd when you made changes to mpd.conf
Copy your music files in Music directory and launch “Play music” from the menu
Innen nem tudom, hogyan tovább?
Átírni még áttudom, de nem tudom, hogyan kell elmenteni a megváltoztatott értéket.
Köszönettel veszek minden segítséget. -
samujózsi
senior tag
válasz
haddent
#29428
üzenetére
De minek terheljem a gépeket olyan protokollal, amire igazából semmi szükségem?
A proxy nálam eredetileg azért kellett, mert több virtuális gépen azonos linux volt és bizonyos irányokba a digi finoman szólva nem nyújtott megfelelő sebességet, így a proxy cache-elte a letöltött anyagok egy részét.Ez már elmúlt, de arra még jó (lenne), hogy logolja a kliensek forgalmát legalább olyan szinten, hogy milyen site-okat látogatnak meg.
Korábban ilyet csak az androidos mobilok csináltak, hogy kikerülve a proxy-t próbáltak a neten kószálni.
Viszont ehhez a VPN eléggé feleslegesnek tűnik, főleg, hogy a proxy-ként is működő szerverem egy celeronos kis gépecske... vagy nem értem, miről beszélsz. -
samujózsi
senior tag
válasz
samujózsi
#29424
üzenetére
O.K., részben tárgytalan, a kérdés csak annyi, hogy hogyan lehetne ezt is átterelni a proxy-n, ha az nem transzparens?
Az amazonaws kapcsolat azért van, mert szinkronizálom a firefox beállításait, könyvjelzőit és ehhez valamiért szüksége van az állandó kapcsolatra.
Viszont nagyon utálom, ha valaki megkerüli a proxyt. -
samujózsi
senior tag
Na erre mondjon valaki valami értelmeset!
Rendszerszinten (network managerben) és a firefox-ban is be van állítva, hogy használjon proxyt.
Mégis van egy nyitott tcp kapcsolata a firefoxnak egy Amazon Technologies Inc. tulajdonban lévő cím felé. Ez vajon hogy lehet? Ki lehet valahogy deríteni, hogy mi módon kerüli meg a proxy használatot valamelyik oldal vagy addon? -
haddent
addikt
válasz
bambano
#29405
üzenetére
Igen, előfordul, nem egyszer. Ahogy az is, hogy fej-fej megy a C -vel. Java meg hasonló viccek közelébe nincs soha. Nyilván amint olyan részhez érünk, ahol nem a C libeket használja, hanem pure python, akkor nagyságrendekkel lassabb, nem hittérítés részemről továbbra sem
bambano persze, ha bios -t vagy hasonlót fejlesztünk. De akár már csak kernelnél is inkább kell gondolni arra, hogy ez nem 1x megírom és 30 évig nem nyúlok hozzá majd újraírom lesz, hanem délután jön 2 másik mikrokód amiket integrálok, commit, CI tesztek stb aztán deploy meg testing aztán production. Fenntarthatóság, követhetőség. Persze mindezt ésszel, vannak helyek ahova aki nem sima C -t használ fejbe kéne lőni
-
samujózsi
senior tag
válasz
inf3rno
#29416
üzenetére
Látod, még a CSV-re is van RFC
Arra úgy a 3.0-s Excel korában találtam egy leírást/definíciót: egy sor=egy rekord, a rekord végét LF/CRLF jelzi, a mezőszeparátor egyetlen karakter, többnyire vessző vagy pontosvessző és a nem numerikus értéket illik idézőjelbe pakolni.
Ez volt az első és utolsó formátum, amire saját parsert próbáltam hegeszteni, aztán rájöttem, hogy valamivel bonyolultabb a dolog, mint a szeparátorok mentén szétrobbantani a sort, így maradtam a már kész megoldásoknál -
bambano
titán
válasz
inf3rno
#29416
üzenetére
mondtam én, hogy nem szabványos formátum? hint: nem mondtam.
(#29418) inf3rno : "Aztán próbálj emlékezni, hogy melyik fogalomhoz melyik rövidítés tartozik, főleg ha magyarul jegyzed meg, hogy melyik mit csinál. Kb. olyan, mint szótárat magolni. ": merugye java-s szabvány nevek rövidítéseit mennyivel egyszerűbb bemagolni... -
inf3rno
nagyúr
válasz
samujózsi
#29408
üzenetére
Én személy szerint rühellem ezeket a shell scriptes parancsokat, vagy nevezd, aminek akarod. sed = stream editor, grep = global regular expression print. Aztán próbálj emlékezni, hogy melyik fogalomhoz melyik rövidítés tartozik, főleg ha magyarul jegyzed meg, hogy melyik mit csinál. Kb. olyan, mint szótárat magolni. Lehet, hogy a 70-es években még ez volt a menő, de szerintem manapság már elég túlhaladott. Egyébként a funkcionális programozásra emlékeztet elég erőteljesen, nem véletlenül utálom azt is. A hülyék meg pont abban szoktak azzal kérkedni, hogy jajj mekkora májer vagyok, megcsináltam egy ezer karakteres sorban az egész programot...
-
-
Dißnäëß
nagyúr
válasz
samujózsi
#29410
üzenetére
Szerintem már hülyére beszéltétek a témát, olvasom itt fél szemmel, de leginkább az eszköz és a felhasználás határolhatja be szvsz, min ÉRDEMES fejleszteni egy adott dolgot. A múltunk pedig, hogy mit TANULTUNK, ezzel néha nagyon nincs köszönőviszonyban..
.. ragaszkodni viszont szeretünk dolgokhoz. (Ez magyar hiba).Esetemben például erősítőket tervezek monitorozni Arduino-kkal, amiket egy központi Pi-vel poll-olnék, adatot ide gyűjtenék be, majd lehet egy "csinos"
frontendet is építek az egész elé.Egy másik konténerben, ugyanezen a Pi-n, meg mondjuk futtatom a teljes házautomatizálásomat akár. De legyen két Pi, köztük pacemaker+corosync és máris megvan a virtuális ip-vel létrehozott HA (high availability), ha egyik elszállna és este nem lenne fűtés.
Ok, túlzok, de értitek.Eszembe nem jutna azon agyalni, hogy bash-ben mókoljak bármivel is.
(Ezt csak példaként hoztam).Valid dolgokról beszélgettek, csak nagyon elmenve a részletekben sztem.
-
vargalex
félisten
válasz
samujózsi
#29410
üzenetére
Bocsánat, akkor félreértettelek. Lehet, hogy haddent kolléga hozzászólásával összemostam a tiédet, mindenesetre én úgy értettem, hogy inkább a bash hiányzik ezeken a rendszereken, mint a python/perl.
Persze, bash nincs, de van busybox ash, elég sok minden megoldható. Viszont 4 MB-os flash-el szerelt routerre nem nagyon lehet python-t/perl-t varázsolni (de még 8 MB-al szereltre is csak nehezen). Attól most tekintsünk el, hogy az OpenWrt csapat dobta is a támogatását az ilyen eszközöknek 19.07-től. -
-
samujózsi
senior tag
válasz
bambano
#29407
üzenetére
Épp ezért nem fogok grep/sed helyett pythont használni, ellenben perl-t azt bármikor, ha az előbbiekkel nem lehet két mozdulattal elintézni vagy épp lehet, csak kib.lassú... (pár hónapja futottam ilyenbe, hogy sorokban stringet cserélni bizonyos esetekben nagyságrendekkel lassúbb a grep ... | sed -e ... formában, mint perl szkriptben. (Konkrétumokra nem emlékszem, talán a notebookomon megvan valahol, ha kell)
-
samujózsi
senior tag
válasz
bambano
#29405
üzenetére
Az nem bash, már bocs... egyébként van amikor gyorsabb a futása, mert a sed és a python más regex feldolgozót használnak.
Te itt foggal-körömmel véded az álláspontod, hogy bash, most meg kiderül, hogy valójában nem is a bash a lényeg, hanem a unix/linux toolok használata? (Amit viszont természetes, hogy meg kell ismerni annak, aki dolgozni akar a linuxszal) -
-
Frawly
veterán
válasz
samujózsi
#29400
üzenetére
Igen, pont ez az, hogy „általában”, meg „plusz lehetőség”. Aztán mindenki máshogy szokta. Eredetileg csak vesszővel választották el, és nem használtak idézőjeles csoportosítást, de végül úgy néz ki, hogy ez lett a szabvány, vagyis csak egy RFC ajánlás, de ez tekinthető kvázi annak, még ha sokan nem is tartják be, és pontosvesszőznek meg minden.
-
bambano
titán
válasz
samujózsi
#29400
üzenetére
ha általános csv parsert írsz, akkor fel kell rá készülni, hogy a csv, amit beletolsz, nem felel meg a szabványnak.
ha te írtad meg azt a programot is, ami a csv-t generálja, akkor meg nem. (egyébként ha a csv mezőiben soremelés van, akkor egy rekord=több sor...)egyébként poén szinten el lehet fogadni, hogy szerencsétlen a csv, mert a neve szerint vesszővel elválasztott mezők a valóságban leggyakrabban semicolon-nal elválasztottak.
![;]](http://cdn.rios.hu/dl/s/v1.gif)
De... ennek ellenére, én speciel jobban elvagyok Arch-csal, viccen kívül. Minden másnak, pl suse, centos, ubuntu vannak olyan irdatlan disztro-specifikus fa#*@!ágai, amiket nem csipázok, főleg, hogy jól láthatóan a "vanilla" tök jól, jobban működik és így... demiiilllyyjért?! 
Új hozzászólás Aktív témák
Hirdetés
- Wise (ex-TransferWise)
- exHWSW - Értünk mindenhez IS
- AMD Ryzen 9 / 7 / 5 7***(X) "Zen 4" (AM5)
- BMW topik
- AMD K6-III, és minden ami RETRO - Oldschool tuning
- TKL formátumú, vezetékmentes "Fekete Özvegyet" dobott piacra a Razer
- A partnerektől függ, hogy lesz-e Arc csúcs-VGA az aktuális generációban
- Hobby elektronika
- Elkezdtek szállingózni az Arctic P Pro sorozatú ventilátorai
- Tőzsde és gazdaság
- További aktív témák...
- Kaspersky, McAfee, Norton, Avast és egyéb vírusírtó licencek a legolcsóbban, egyenesen a gyártóktól!
- Assassin's Creed Shadows Collector's Edition PC
- Windows 10/11 Home/Pro , Office 2024 kulcsok
- 27%-OS ÁFÁS SZÁMLA I Jogtiszta Microsoft digitális és fizikai termékek I DIGITALKEYZ.COM
- Bitdefender Total Security 3év/3eszköz! - Tökéletes védelem, Most kedvező áron!
- HP Rack szerverek és tartozékok egyben vagy külön-külön
- Telefon felvásárlás!! Apple iPhone 16, Apple iPhone 16e, Apple iPhone 16 Plus, Apple iPhone 16 Pro
- ÁRGARANCIA!Épített KomPhone i5 14600KF 32/64GB RAM RX 7800 XT 16GB GAMER PC termékbeszámítással
- REFURBISHED - DELL Thunderbolt Dock WD19TBS docking station (210-AZBV)
- AKCIÓ! Apple MacBook PRO 15" 2018 i9 32GB 500GB 560X 4GB notebook garanciával hibátlan működéssel
Állásajánlatok
Cég: PCMENTOR SZERVIZ KFT.
Város: Budapest
Cég: Promenade Publishing House Kft.
Város: Budapest