- Android szakmai topik
- Milyen okostelefont vegyek?
- iPhone topik
- Apple Watch
- A hagyományos (nem okos-) telefonok jelene és jövője
- Samsung Galaxy S25 Ultra - titán keret, acélos teljesítmény
- Fotók, videók mobillal
- Samsung Galaxy Watch (Tizen és Wear OS) ingyenes számlapok, kupon kódok
- Samsung Galaxy S24 Ultra - ha működik, ne változtass!
- Android alkalmazások - szoftver kibeszélő topik
-
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
-
Frawly
veterán
válasz
haddent
#29720
üzenetére
Ezzel nincs is baj, hogy neked a systemd bejön. Nem vesszük le a fejed, mert nekünk meg nem jön be, és nem is akarunk meggyőzni, hogy ne használd, vagy hogy szar lenne. Mindenki azt használ, amit akar. Vagyis akarna. Azt kell érteni, hogy a systemd-ben nem az a rossz, hogy most X embernek tetszik, Y embernek meg nem, hanem hogy annak is használnia kell, aki nem akarja, mert minden disztróban ott van, minden csomag lassan már dependel rá. Így az is szenved miatta, aki nem akarja használni, vagy nem használja. Ez a rettenet gond vele. És ez nem is magának a systemd-nek a hibája, hanem a disztróké, akik mind defaulttá tették, a csomagkészítőknek és szoftverfejlesztőknek, akik mindent erre dependelnek. Szóval azzal nem lenne baj, ha Lénártdőtőke saját magának hülyeségeket írogatna, mert csak egy hobbiprojekt lenne. Hanem mióta mindenki mindent erre dependel, azóta nem lehet megkerülni lényegében. A Linux meg pont arról a szabadságról szólna, hogy modulárisan lecserélheted és kombinálhatod minden részét, olyan kernelt, amilyet akarsz, olyan fordítást és verziót, amilyet akarsz, olyan initrendszert és rendszerlogolót, amilyet akarsz, olyan grafikus felületet, WM-et, DE-t, login managert, display servert, amilyet akarsz, olyan shellt teszel fel, amilyet akarsz, olyan compilert használsz, amilyet akarsz, és még sorolhatnám nagyon sokáig. Na, az, hogy a systemd-re minden dependel már, az pont ezt a szabadságot sérti meg. Mert ja, feltehetsz systemd-mentes disztrót, de szopás van, ha pont egy olyan szoftvert akarsz feltenni, ami meg dependelne rá, nálam meg nincs systemd. És valóban fel lehet tenni systemd-mentes disztróra is ilyen d-re végződő pótmodulokat, elogind, f4×0mtudjamilyend, de ezek a systemd újraimplementálásai, és ha ezeket mindet felteszed, akkor hiába használsz systemd-mentes rendszer, lesz helyette lényegében egy systemd2-pótd-d, és csak áltatod magad, hogy kikerülted, valójában valamilyen formában, eltérő implementációban továbbra is használni kényszerülsz.
Meg az, hogy systemd nem maradt meg egy init rendszernek. Már rég nem csak init-ként szolgál, hanem logolástól elkezdve a hálózat és eszközök, userek kezeléséig, meg egy csomó biztonsági manőverig mindent a saját irányítása alá vett, most a home mappa kezelése következik a homed-vel. Ha csak init-et csinálna, akkor le lehetne cserélni bármilyen initrendszerre, és nem lenne vele gond, használná az, akinek tetszik. De így, hogy lényegében egy miniOS, a kernel és az userspace között, ami önálló életet él, így nem lehet kivágni a rendszerből. Főleg mióta minden erre épít. Egyszerűen a linuxos világ rákfenéje, ezért utálják, egy nagy bloat alrendszer, amibe nem lehet belenyúlni, el van takarva a működése bináris szutykokkal, és nem lehet kiirtani már sehonnan. Egyre inkább átveszi a linuxos rendszer feletti uralmat, lassan a disztrók már nem is Linux disztrók, hanem systemdnix vagy Linuxd vagy Poetterix disztrók. Ez vele a gond. Mi meg a hagyományos, sysvinites, klasszikus Linux rendszert kérnénk vissza helyette, ami teljes választási szabadságot ad minden tekintetben, de ezt már nem lehet, mióta mindenhez systemd kell, és minden erre dependel. Ezért szidjuk, mint a bokrot.
-
samujózsi
senior tag
válasz
haddent
#29722
üzenetére
Akkor ez debian/ubuntu specifikus?
Mert nekem rendre felülírta a resolv.conf tartalmát és miután sikerült rábeszélni, hogy az én szerveremet használja, még akkor is csak úgy, hogy a rendszerem (egy része?) a 127.0.0.53:53 dns-t keresi és az megy tovább a sajátomra, ha úgy látja jónak.
Ebből következik pár hibaüzenet a logban, meg az, hogy egyes módosítások a host nevekben nem mindig érvényesülnek azonnal.Apropó log: jó szokása a journalnak, hogy szabálytalan leállásnál megsérül.
-
samujózsi
senior tag
válasz
haddent
#29720
üzenetére
Próbáltál már saját dns-t használni vele? Lehetőleg úgy, hogy a systemd teljesen ki legyen iktatva a névfeloldásból?
Egy agyrém.
Kihagyni azt hiszem, nem is lehet.
Jó másfél éve, hogy szoptam vele, aztán tegnap, hogy előjött a systemd téma, kicsit nézelődtem a google-n és ez eszembe juttatta, mert más is panaszkodik rá.
Vagy... Amikor bootnál/shutdown-kor elakad valami. Mondjuk épp nem érhető el bootkor a dhcp szerver és képes percekig várni rá...
Persze, lehet módosítani a timeoutot, csak esetenként tojik rá. Stb.
A szerverem már szénné hackeltem miatta, így most működik, csak ritkán kergül meg, de ha legközelebb összefutok valami hasonlóval, majd leírom. -
Dißnäëß
nagyúr
válasz
haddent
#29713
üzenetére
Na ez nagyon jó, a vasamon most egy QEMU/KVM van az XFCE Virtual Machine Manager-e szerint, úgy pár hónapos Debian rendszer, ezt kezdem belakni. Nem gondoltam volna, hogy egy cégben is használt vSphere-el szemben ez labdába rúghat, az azért elég durvi cucc, ahogy láttam, csak itthon nem szórakoztam még el vele.
A tervem az, hogy a host-ot és annak fizikai hálókártyáját ugyan az ASUS router-em LAN portjára kötöm, de lesz egy VM, ami egy teljes saját alhálónak (a többi VM-nek) lenne a tűzfala, router-e, VPN koncentrátora, mindene (egy OPNSense, én most azt tanulgatom, iptables kézzel írás után elég nyakatekert, de szokható). És pár egyéb VM egy kicsivel nagyobb projektecske környezeteinek, amibe végre belevágok.
Amúgy eredetileg nem ezért jöttem ide, csak már reflektálok és köszi a visszajelzést.
--------------------------------------------------------------------------------------------------------------------------------------------
És akkor amiért jöttem: a jövőben szeretném a gépet Pendrive-ról boot-olni.
Van 3 teljesen új, teljesen egyforma, síkugyanolyan, egyszerre vettem.1. Mindegyikre tegyem ki a /boot-ot és a végén dd-vel másoljam át 1-es tartalmát 2-3-ra
VAGY
2. MD RAID1-ezzem be őket ? Egyedülállóan is boot-olnak ilyenkor nyilván. De szerintem ez csak komplikálja a dolgokat, mert minek.Nyilván ha a rendszeren upgrade-et ill. full-upgrade-et tervezek letolni, feltétlen beteszem az egyik pendrive-ot és mount-olom a /boot-ba, majd upgrade lefut, frissebb kernel a boot-on (a pendrive-on), a pendrive-ot ismét átmásolom a másik kettőre, frissítve így őket is aktuális boot-olóra és kész, kivehetem (a /boot-ot meg umounttal egyidőben egy HDD alapú kamu /boot-al helyettesítem - vagy nem kell egyáltalán, full tökelvan a gép apt upgrade-et nem cseszegetve /boot nélkül ? Mert akkor ha umount-olom a pendrive-os /boot-ot és kihúzom a kütyüt, nem is tökölnék a helyettesítésével amúgy. Ha minek).
-
-
samujózsi
senior tag
válasz
haddent
#29611
üzenetére
Ez egy rtl81xx:
Cannot get device udp-fragmentation-offload settings: Operation not supportedtx-checksumming: offtx-checksum-ipv4: offtx-checksum-ipv6: offscatter-gather: offtx-scatter-gather: offtcp-segmentation-offload: offtx-tcp-segmentation: offtx-tcp-mangleid-segmentation: offtx-tcp6-segmentation: offudp-fragmentation-offload: offtx-nocache-copy: offrx-fcs: offrx-all: off -
Frawly
veterán
válasz
haddent
#29576
üzenetére
Pont ezért kell vanilla Linuxot használni, és nem agyonforkolt, agyonpatchelt enterprise valamit, amire már Linus sem ismer rá. Azért egy kvázi sztenderd vanilla kernel + glibc + systemd kombóra lehet építeni. Ugye mivel szerverről van szó, se X, se Wayland, se játék, se Pulseaudio, se semmi nem jön szóba, ami a képbe bezavarna.
(#29577) bucihost: na látod, most sikerült csupa olyat sorolnod, amiből van linuxos alternatíva. Én olyanra céloztam, hogy pl. Adobe Photoshop kell egy spéci plugin miatt, vagy valami spéci vektorrajzos megoldás, amire nem jó a linuxos Inkscape, stb.. Azért ilyesmiket nehezebb házon belül lefejleszteni, mint egy kasszaprogramot. Nincs egy fajsúlyban a kettő.
Egyébként a kasszaprogramnál nem is az a szívás, hogy lefejleszd, meg multiplatformos legyen, hanem hogy a NAV is elfogadja. De ez megint nem a Linux hibája, hogy a NAV-nak is MS kényszere van. Ez pont egy ördögi kör, hogy midenki MS-megoldást használ, mert csak azt támogatja mindenki, és így továbbra is ebbe a körben tartanak mindenkit. Pont ebbe a függőségi játékba nem kell belemenni.
-
bambano
titán
válasz
haddent
#29576
üzenetére
nem akarom találgatni, hogy mire gondolt a kolléga, arra tudok reagálni, amit leírt. márpedig az, ha szabadon cserélgethetem a fő komponenst is egy disztróban, akkor az kompatibilis -> nem lehet fragmentált.
azokból a cuccokból, amik alapvetően meghatároznak egy asztali disztrót, kevesebb variáció van, mint a másik oprendszernél. mert attól, hogy a verziószám utolsó jegye más, még kompatibilis marad, és nyugodtan csereberélheted, főleg a kernelt, mert Linus elég hevesen szokott reagálni, ha egy kernel patch beküldője megtöri az userland kompatibilitást.
-
-
vargalex
félisten
válasz
haddent
#29515
üzenetére
Én is ezeket értem alatta és pont ezért kérdezem. Viszont ennek ellenére több ügyfelünk is Ubuntut használ production-ban. Van olyan állami ügyfelünk, aki az általunk supportált SLES-t váltotta arra úgy, hogy egyikhez sem ért. Persze, velünk megszüntette a supportot...
És van nagy telekommunikációs ügyfelünk is, ahol production-ban Ubuntu van. Ez utóbbi pedig rendes hely... -
samujózsi
senior tag
válasz
haddent
#29509
üzenetére
Félreértesz: egy rolling release folyamatosan hozza az új verziókat, ami egy nem-rolling rendszeren nem jellemző.
Ki vállal be egy olyan fejlesztést, amit (durva túlzással) havonta hozzá kell igazítani az op.rendszer újabb és újabb darabjaihoz, mikor egy hagyományos rendszernél ezt csak akkor kell meglépni, ha már nincs support a használt rendszerre vagy azt egyéb ok miatt újabb verzióra kell felhúzni? -
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.
-
-
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.
-
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. -
bambano
titán
válasz
haddent
#29392
üzenetére
itt megint a túltervezés példáját láthatjuk.
"ha kalapácsod van, mindent szögnek nézel"
biztos, hogy objektumként kell átadni a validált adatokat?másik hsz-edben:
"Monitoring adatokat pont, hogy igenis valamilyen sztenderdizált formátumban és azon belül is szépen formázva adunk ki, hogy univerzális és kompatibilis legyen ne csak a te shell scripteddel, hanem grayloggal, prometheussal, kibanával meg nagyjából bármivel is, ne kelljen külön parser meg interpreter hozzá. ": ezt max. akkor csináljuk így, ha feladat, hogy ilyen cuccokkal interfészelni kell. ha nem feladat, akkor nem csináljuk így."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.
"Ebből a kommentedből is látszik, hogy nagyon más nézetet vallasz.": így van. ha például azzal kezdem a threadet, hogy "elsőnek bash", akkor ez alatt azt értem, hogy először bash és nem azt, hogy kizárólag bash.
-
samujózsi
senior tag
válasz
haddent
#29392
üzenetére
Ott a kulcsszó: szerializáció (fújj... nincs erre valami mádzsár ixpressön?
)
A csv az alkalmatlan erre, viszont egyszerű adatsorok továbbítására nagyszerű. Ha már van benne idézőjeles mező... hát akkor már mindegy.Ezeket a dekorátorokat utálni fogom, amíg csak élek. Egyszerűen képtelen vagyok megjegyezni, hogy hol, hogyan tudnám használni saját célra.
-
haddent
addikt
válasz
haddent
#29390
üzenetére
Na meg van az a szint, amit bash -ben elkezdeni is nevetséges lenne, C/C++ -ban meg olyan szinten fájdalmas makrós szörnyedtség (vagy 3rd party keretrendszer és társai), hogy inkább feladod az életet is. Itt egy kis kedvenc pl. saját kód
Egy webszerver POST endpointját kidekorálom vele felparaméterezve egy előredefiniált schemával és hátradőlök, a függvény megkapja a parsolt, validált adatokat objektumként. Na ezt nagyon nem szeretném C -ben implementálni pl
samujózsi semmivel, ebben igazad/tok van. Nem tudom miért a json lett "A" (de)szerializációs best practice, de ez van. Mondjuk jóval jobban olvashatóbb és sokkal bonyolultabb objektumok kényelmes tárolására is alkalmas, gondolom..
-
bambano
titán
válasz
haddent
#29380
üzenetére
c-ben meg jávában (meg kb. mindenben) úgy írod, hogy:
if feltétel then feltételes ág;
ezt fordítva írni elég nagy bűntett. illetve tabulálást a szintaxis részévé tenni szintén az.
de nem is ez a fő probléma a pythonnal, hanem az, hogy arra csábít, hogy minden olyan dolgot, amit normális programozói felfogással bashban pár sorban el lehet intézni, azt pythonban írd meg, OBJEKTUMORIENTÁLTAN. ezért szívlapát járna mindenhol. folyton vitatkoznom kell olyanokkal, akik összekeverik azt, hogy valami szabvány lehet használni azzal, hogy kötelező használni.
tehát a vége az, hogy ha valaki betépve csinált magának egy programozási nyelvet, azt nem feltétlenül jó általánossá tenni. és igen, a rendesen telepített szervereken se python, se perl. minél kevesebb eszközt adsz a leendő betörő kezébe, annál biztonságosabb a történet.
-
inf3rno
nagyúr
válasz
haddent
#29362
üzenetére
Nem tudom, én csak ránézek egy Python kódra és elfog a hányinger. Nekem a Java, ami mindig is tetszett, szép, rendezett. Kivéve a többszálú programozás, az annyira nem jön be egyik nyelven sem, abból nekem az tűnik vállalható iránynak, amit a nodejs csinál, hogy megosztott memória helyett mennek az üzenetek, de az meg gondolom jóval lassabb, mint a többi.
-
Dißnäëß
nagyúr
válasz
haddent
#29362
üzenetére
Szvsz úgy érdemes DevOps-ot tolni, hogy miközben egy programozási nyelvet tanul az ember, elkezdi alulról a classic IT stack-et is tanulni, az pedig infrastruktúránál kezdődik.
Nem kell CISCO CCNA (de nem ártana)
... de az OSI modellt betéve illik tudni, vagy hogy mi a különbség egy Layer3/4-es illetve Layer7-es load balancer között, amikor 2+ fizikai host-on, egyszerre több VM-ben a legkülönfélébb dolgok futnak HA-ban, mert az az igény ? És akkor jön az Apache, Tomcat, HAProxy, nginx, meg egyéb reverse és normál proxy típusok, egy kis HyperV-zés, fájlrendszer típusok és alap hatásuk (előny, hátrány), némi VMWare-ezés, például affinity group-ok, vCPU-k, aztán storage kapcsán NAS, SAN, vSAN, Fibre Channel, vissza network környékére biztonság, csomagszűrő és application tűzfalak, nat-olgatás, VLAN-ok, QoS, majd egy kis security alapok, PKI, RSA, ilyesmik.. úhhh nagyon hosszú még a lista és egy kurva kódot nem ütött le az ember, nemhogy OS-t telepített volna. 
Sokkal inkább mennék DevOps tudás felszívása esetén időrendben inkább, tehát infra, network (néha egybeveszik), DB, OS, APP, middleware, virtualizáció, konténerizáció, aztán jönnek a logikai szerkezetek, mit hol min tároljunk, fájlrendszerek és azok előnye-hátránya, local/distributed, és melyiket mikor mire, minimális SQL és azokra az elérés, konnektorok (ha kell), [... nagylevegő ...]
és még felhőnél sem járunk, microservices & GW-s, messaging queues, .. szóval az egyik agyféltekét full erre a classic stack-re fókuszálnám, ami mára már rendesen bebonyolódott-fejlődött, de azért az alap legó kockákat ismerni illik. Másik agyfélteke meg mehet python-ra közben, bár ez is érdekes, mert én node.js-en kezdtem és hogy is mondjam.. fasza.
És akkor lehet SOAP-ozni, XML, mert multik azért nem feltétlen tartják az iramot mindig a legújabb motyókkal, majd JSON/REST, API dolgok.. Van egy frontent fejlesztő haverom, fiatal srác, marha komoly guruja több nyelvnek is, kicsit most van fullstack-esedőben, de ahogy megy lefele backend irányba (még nincs a közelében), már bejön az, hogy fogalma sincs, mi az a MySQL Router, mire jó a Ceph, zfs, brtfs, XFS (és mire nem), raid szintek, raid kontrollerek (vagy nemkontrollerek), na meg akkor ismét csak network stack és suricata/zorp/ufw/iptables/routing/portok/socket-ek/vpn módszerek és típusok (pl. OpenVPN-nél nagyon nem mindegy, hogy tap vagy tun), ..
Nem rossz ez a modell szerintem és a 4-es pont nagyon is valid, sőt. Mai világban, ahol minden mindennel össze van kötve, abszolút must-have, sokkal több, mint esti mese, amit lehet csak úgy skip-elni és majd összeszedni wiki-ről, amikor odaér az ember. Pont fordítva gondolom: ha fejlesztés közben kell megoldás valamire, annak utánajárni sokkal kisebb rizikó - remélhetőleg nem refaktor indukáló
- mint egy felépített várnál mikor kiderül, hogy a ZFS alatt a raid kontroller nem IT módban van, vagy storage-ban mekkora legyen egy blokkméret, milyen redundanciát adjunk, vagy hogy mekkora VM kell egy új akárminek, esetleg konténerizálható-e de akkor swap-et ki kéne kapcsolni, ilyesmik + a teljes megoldás monitorozása, nem feltétlen nagios (bár aki szereti).. de akár ELK, akár más.. kinek mi a szájíze .. (vagy egy felhős dashboard és annak elemei), .. A DevOps szvsz úgy mindenes, hogy ő nem a "mindenes informatikus" aki elvan a sarokban facsén és közben a főnök tudta nélkül csorog le a poresz az üvegen, mert megteheti, hanem az, aki end-to-end képes átlátni egy üzleti igény megvalósításának kihívásait mind programozástechnikai, mind alátett infra szempontból és akkor SOKKAL de sokkal nagyobb esélye van arra a cégnek, hogy egy új gigaprojektet nem kell 2 év múlva kikukázni, mert kiderül, hogy vagy nem skálázódik, vagy szarul, vagy megesz valami erőforrást, holott nem feltétlen kéne, vagy inkonzisztensen tárolódik valami adat, queue, akármi.
Nagy felelősség van egy jó DevOps-oson, ha nekem cégem lenne és menne jól, mocskosul megfizetném, hogy nálam maradjon (ha jó).
-
Frawly
veterán
válasz
haddent
#29260
üzenetére
Érdekes tanulságösszegzés. Irigylem a problémádat. Szívesen cserélnék veled, hogy az 1 gigás netem nem futja ki magát virtuális gépben. Ehelyett ilyen csóresz 15 mbites neten van, amihez még kaka Wi-Fi jelerősség is társul az albérletben
De legalább qemu-kvm-ben nem lassul, igaz nincs is hova neki, mert akkor átmenne negatívba a sebessége -
samujózsi
senior tag
válasz
haddent
#29244
üzenetére
Szakértő nem vagyok, de... a kernelek gondolom, eltérő konfiggal működnek, tapasztalataim szerint ez bőven elég lehet jelentős eltérésekhez a performancia terén.
Nem állítom, hogy erről van szó, csak tipp.Amit viszont nem értek... [link] ennyire nem törődnek a doksival, vagy máshol kéne keresni? Mert ez nagyon elavult
-
#29245
Cirbolya_sen
aktív tag
haddent
#29244
Cirbolya_sen
aktív tag
válasz
haddent
#29244
üzenetére
Én ennyire mélyen nem mentem bele, az előkészületeknél a leírások alapján egy mini pc-re, az ipFire maradt, erre ígérték, hogy működni fog Digi PPPoE gigán. A BSD verzióknál, az volt a mondás, hogy a több magot nem tudják lekezelni, és érdekes, mert az OPNsense és PfSense összehasonlításokban, egy picivel az OPN jött ki győztesnek
A mini pc telepítve, már csak idő kérdése, hogy megnézzem, hogyan muzsikál élesben.
-
samujózsi
senior tag
válasz
haddent
#28877
üzenetére
Félreértesz, azt hiszem. Nem a konkrét tartalmára vagyok kíváncsi, hanem fogalmazzunk úgy, a metaadatokra. Az image konkrét méretére, a hozzá tartozó teljes leírásra, aminek egy része a search kimenetében megjelenik. Satöbbi.
Tegnap próbálkoztam közös felebarátunknál, a google-nél, és arra jutottam, hogy erre nincs parancs, valami webes API segítségével lehetne lekérni, ha jól értem. Ha... kérdés, hogy jól értem-e? -
inf3rno
nagyúr
válasz
haddent
#28792
üzenetére
Én állítottam, de én sem ismerem mélységeiben, csak sok videoban ilyesmit mondtak, hogy a sysvinit csak elindítja a dolgokat, de nem menedzseli, ezért mennyivel jobb a systemd vagy a launchd BSD-nél. Mélyebben belenézni nekem sem volt még időm. Ha nem így van, akkor valóban értelmetlen pénzkidobás volt az átállás systemd-re. A másik érv a sysvinit ellen az volt, hogy distro függő a scriptelése. Ennek se jártam utána, hogy tényleg így van e, viszont ez annyira nem probléma, ha valaki csak a kedvenc disztroját használja. Inkább akkor gond, ha valaki sokak által használt szoftvert ír, és szeretné, hogy eltérő disztrokon is ugyanúgy viselkedjen.
-
bambano
titán
válasz
haddent
#28787
üzenetére
azt gondoljátok, hogy az init csak egy shell szkriptet indít el, ami nem így van. induláskor a runlevelnek megfelelő szkripteket indítja el, és amikor elérte a végleges runlevelt, akkor utána az inittabban leírt daemonok futását menedzseli ugyanúgy, mint a systemd. viszont az inittab kevesebb szájtépést tartalmaz, mint a systemd fájljai, tehát nem igaz, hogy a sysvinit szájtépő.
továbberősítitek bennem azt a véleményt, hogy azért rossz a sysvinit, mert nem tudjátok, mit tud.
-
kovaax
őstag
válasz
haddent
#28780
üzenetére
A függőség kezelése is szar, az After nem azt jelenti, hogy akkor indul, ha az előző elindult ténylegesen, hanem ha elkezdte indítani. Szóval amikor szépen összeügyeskedtem, hogy az oracle után induljon el az azt használó alkalmazás, azt tapasztaltam, hogy az alkalmazás mindig elhal, mert nem tudja elérni az adatbázist, mivel a systemd nem várja ki azt a 10 másodpercet, míg az oracle tényleg elérhető lesz. Míg ha egy buta scriptbe beleírom, hogy oracle majd az alkalmazás, akkor működik minden, szarni a systemd-be...
-
válasz
haddent
#28780
üzenetére
Szvsz célszerűbb a Wants= alkalmazása, ha minden service fájl normálisan meg van csinálva akkor elvileg elég lenne dependálni a mount service-ére. A szkriptnek meg ennyi kell egy service fájlba, erre ugyan úgy tudsz dependálni. A oneshot típus aktív marad ha nullával lép ki a szkript.
[Unit]
Description=<...>
[Service]
Type=oneshot
ExecStart=<script path>
RemainAfterExit=true
StandardOutput=journal -
bambano
titán
válasz
haddent
#28778
üzenetére
alapvetően most cseréltünk szervereket az egyik helyen, ahol dolgozom, újra lett húzva minden nulláról, és azt találtam ki, hogy drbd-vel realtime mentést csinálok. mivel kitolom a házból máshova, így legyen rajta titkosítás. és hogy gyors is legyen, raid1-be raktam. ezt elvileg meg kellett volna tudni csinálni systemd-vel, de a doksija alapján nem működött. mondjuk az md raid drivert is szétokoskodták, a raid1-be rakott raid1 például egy neuralgikus pontja.
vagy ilyet akartam megcsinálni, hogy a postfix ne induljon el addig, amíg nincs felmountolva a leveleket tároló partíció.
úgyhogy most úgy van összerakva, hogy rebootkor a gép félig elindul, utána kézzel összerakom a maradékot.
-
bambano
titán
válasz
haddent
#28772
üzenetére
"mire pazarlod a munkaidőd, amikor systemd -re kényszerülsz?": hát systemd-re, mi másra.
ha azt akartad megkérdezni, hogy mit nem tudtam megcsinálni vele, akkor a válaszom: stackelj egymásra raid1-et, drbd-t, lvm-et, cryptofst, raid1-et különböző sorrendekben. ez nem működik a debian systemd-jével. -
bambano
titán
válasz
haddent
#28759
üzenetére
de nem csak egy szempont szerint kell ezt a dolgot értékelni.
ha a te szempontodat, a szoftverfejlesztés hatékonyságát nézzük elaprózott platformon, akkor igazad van, hogy nem logikus.Itt az a lényeg, legalábbis az én véleményemnek ez az alapja, hogy az is számít, hogy a szabad szoftver megad egy csomó szabadságot, és ebbe az is beletartozik, hogy forkolod a cuccot. Az egész miskulancia arra épül, hogy nem pofázunk, hogy rossz, hanem írunk jobbat. Tehát ha felmerülne, hogy a disztró készítés jogát korlátozzuk, azzal kompletten kiherélnénk az egész szabad szoftveres eszmét. Ilyet, hogy nem nyúlhatsz bele valamibe, csak a nagy ellenség, az m$ csinál, debianék meg archék nem.
Nem tudok ennél fontosabb elvet szabad szoftver kérdésben.
-
bambano
titán
válasz
haddent
#28748
üzenetére
"Linuxból hány van? Hány olyan okoskodó jajdekülöndisztró kell akik annyit csinálnak, hogy reskin aztán hello": de mi ezzel a gond? te, mint user, megkapod a választás szabadságát, hogy bizonyos célra optimalizált disztrót választhass. te, mint fejlesztő, nyugodtan csinálhatsz saját disztrót, ha akarsz. szerintem ez nem gond, sőt.
gond akkor van, amikor valaki marhaságot tesz kötelezővé. van vagy 400 disztró, egyet se vagy köteles használni. virágozhat minden virág.
-
inf3rno
nagyúr
válasz
haddent
#28733
üzenetére
Lement a szerkesztési idő. :S Az egy iránnyal egyetértek, de ezt nem így csinálják normálisan. Csinálnak egy szabványt, hogy ilyennek kell lennie egy startup scriptnek, aztán azt a szabványt valósítják meg eltérő rendszerek. Nem tudok róla, hogy Linux-nál lenne ilyen szabványosító szervezet, de ráférne ugyanúgy, ahogy pl a webre megy a W3C. Talán egy fokkal demokratikusabb módon, hogy ne fél tucat ember döntsön egy-egy szabványról, de ne is bárki, aki az utcáról beesett.
Az, hogy disztrónként eltérő mi hol van igazából nem számít. Irni kell rá egy pár soros scriptet, ami elfedi a különbségeket, ha ennyire fontos neked. Tutira van már ezer létező dolog a témában.
Elvileg a musl a szabvány követő, és a gcc ami rosszul lett implementálva. Üdv. a való világban Neo.
Sajnos sok olyan dolog van Linuxban, ami azért olyan amilyen, mert valaki 30 éve tákolt valamit, ami félig használható, és mindenki más lusta volt újraírni. Nem mintha ez más OS-ekre nem lenne jellemző. Amennyire én tudom Windows-ban is vannak évtizedes kódok. -
inf3rno
nagyúr
válasz
haddent
#28733
üzenetére
Elvileg a BSD jail hasonló, mint az LXC, eggyel alacsonyabb szintű, mint a Docker. A Docker pl nekem azért jó, mert beírom, hogy hardened alpine dockerhubon, aztán nem kell security expert-nek képeznek magam hónapokig, hogy egy normálisan beállított rendszeren menjen a webszerver. Nyilván ennek nem csak előnye van, de mindenkinek véges az ideje...
Fejlesztői szemmel pont, hogy a systemd nem összeszedett. Lehet, hogy felhasználói szemmel annak tűnik, de a moduláris felépítés alapvető ahhoz, hogy egy nagy közösség tudjon hozzáfejleszteni. Az alapján, amiket a systemd-ről olvasni, inkább zárt forrású kódhoz való megközelítés, aminél egy szűk fejlesztői csapat dolgozik a kódon. A BSD-ről eddig az a benyomásom az alapján, amit linkeltem, hogy átgondoltabb, mint a Linux, viszont valszeg emiatt és a kisebb közösség miatt lassabban is fejlődik. A nagyobb közösség meg mindig hozza a potterhez hasonló fazonokat, úgyhogy van ennek előnye és hátránya is. Igazából az utóbbival se lenne gond, ha helyén kezelnék a fazont és a projektjeit és nem emelnék be gondolkodás nélkül egyébként stabil rendszerekbe. Ez már inkább valami politika lehet, másképp nem tudom elképzelni, hogy ilyesmi előforduljon.
-
bambano
titán
válasz
haddent
#28733
üzenetére
"a BSD -k mellett az érvelés Linux-szal szemben mindig az volt, hogy sokkal összeszedettebb": azért tűnhet messziről összeszedettebbnek a bsd, mert *SOKKAL* régebbi (úgy értem, le van maradva, mint állat), mint a linux. Amikor utoljára megnéztem, a töredékét tudta, a töredéke mennyiségű szoftver volt rá, és brutálisan ócska volt a kernele a linuxhoz képest. Tudásban nagyjából a 2.4.x-es linuxok szintjén járt, vagy még előtte. Például nem volt benne rendes smp, nem volt benne multithreaded hálózati stack, rotfl.
egyébként ja, a bsd-k sokkal összeszedettebbek, merugye nincs openbsd, freebsd, netbsd, pcbsd, meg freenas meg hasonlók... ja, de, mégiscsak töredezett az is, legalábbis a felhasználói bázisának nagyságához képest... nincs elég emberük, hogy széttördeljék
"Baromira nem érdekel melyik lesz az irányvonal, de ugyan már legyen már egy irány": volt egy irány: svr4 init. A debian rc rendszere pontosan ugyanúgy nézett ki, mint pl. a solarisé. Emlékeim szerint a slackware-é is ugyanilyen volt. Majd jött az okoskodó redhat, aki mindig mindenben mást csinált és sajnos túl ritkán verték érte pofán (lásd gcc 2.96), és elkezdték tördelni az egységességet. Hol is dolgozik pöcstering?
-
samujózsi
senior tag
válasz
haddent
#28712
üzenetére
Konkrétumot nem tudok linkelni, nem suoktam bookmarkolni az írásait. A systemd bug reportok környékén érdemes nézelődni, ha ilyet akarsz látni. Néha bicskanyitogatóan arrogáns stílusban reagál és természetesen mindenki hibás, csak ő a helikopter... én kb ezt láttam tőle.
Nekem nem volt dolgom vele, csak olvastam róla negatív kritikákat és emiatt néztem utána, hogy mennyi az igaz mindebből. Úgy tűnt, elég sok.
Systemd meg nagyjából a linux windows-osítása.
-
válasz
haddent
#28710
üzenetére
Mert egy határ szar? Mert bloatware módon minden alrendszert be akar nyelni? Mert kinyírhattad vele az alaplapodat? Mert a printer install szétcseszi a tűzfal konfigot, ettől függetlenül elindítja a networköt, de a sysadminnak nem szól róla? Mert sokmindent akar csinálni, de semmit sem jól? Mert Frawly fórumtárs (és még sokan mások) mostanság szívnak a seed service-szel, mert belassítja a bootot? Mert ha invalid username-mel indítottál bármit, akkor fallbackelt rootra (!)? Mert ha nincs DNS szerver a hálózatban a network indulásakor, akkor minden további értesítés nélkül fallbackelt a Google DNS-re? Mert... Mert... Mert...?
Mert az egész hóbelevanc törekvés a corporate linux létrehozására?
-
inf3rno
nagyúr
válasz
haddent
#28700
üzenetére
Az Arch dokumentációját már elég sokat használtam, valamiért mégsem telepítettem még soha azt a disztrót. Lehet adok neki egy esélyt. :-) Igazából megint ott vagyok, hogy ki kéne próbálni 4-5 disztrót mielőtt döntenék. :-) Végülis pendrive-ról megoldható vagy esetleg virtuális gépen.
-
Frawly
veterán
válasz
haddent
#28694
üzenetére
Igen, írtam is a legelső vonatkozó hozzászólásomban, hogy ezt próbáltam először. Látszólag le is tiltja, nem ír semmi hibaüzenetet, de aztán reboot után pofátlanul továbbra is ott virít ez a futó random seed service, és dicsekszik, hogy 9 mp-cel hosszabbította meg a bootot. Valahogy mindig visszamászik, hiába tiltom le
-
Dißnäëß
nagyúr
válasz
haddent
#28607
üzenetére
Az esetek többségében - kivétel mindig lesz, lehet nem is kevés - a mögöttes folyamatok sem mindegy, milyenek.
Például egy ~100+ "gépes" (VM-ek és konténerek vegyesen) teljes IT stack-et Azure-ben felépítve és üzemeltetve az erőforrás igénye sem összemérhető egy on-premise private cloude-éval, a hozzá adott csilliárd analitikáról és automatizálhatóságról meg n+1 nézetről nem is beszélve.
És aki azt mondja, nem tökéletes, meg itt-ott beteg, szar, izé ? Hát én még private cloud-ból sem láttam olyat, amibe nem lehet belekötni.
De a folyamatok mögötte akkoris... private cloud-nál vagy urambocsá, annak "elődjénél", az on-premise (akár DC-ben is) lévő üzemeltetésnél waterfall gigaprojektek verekednek iszonyú hiperdilettáns ITIL-helpdesk-szolgáltatási szinteken és xyz Service Management / Ticketing tool-okon keresztül mind hardver erőforrásért, mind élőember (know-how) erőforrásért, és mire elér valami egy úgy-ahogy értékelhető stádiumba, már újra kéne tervezni lassan a projektet, mert a világ odakint közben fordult kettőt. Egy tényleges public cloud mögött pedig (jó esetben, ha alkalmazható, de nem kötelező) egy agilis csapat valamiféle formája van, relatív nagy sebességű reakciókkal változó üzleti igényekre, amiket rendszerben is le tudnak követni és nem úgy, hogy feladom ticket-be a Change Request-et, vagy L1 felveszi nagylassan-tökhanyagul az incidens ticket-et és onnantól várunk heteket, néhol hónapokat
hogy történjen valami a hülyebuta-erőforráshiányos-nagyájtín a háttérben, hanem kb. behúzza PO a sprintbe, valamilyen prio-val ellátja oszt a devops összeüti neki öt kattintással, mondjuk egy új UAT környezetet, mert (ahogy az lenni szokott) a tesztelők épp elfogytak egy új feature tesztelésére tervezett környezetből, "mert azon még az xy release-be menő akármi egyéb fut " épp a Tosca-val, Katalonnal, vagy kőbaltával fullmanuálban. Ez agilisben egy szó szerint agilisen, gyorsan reagálva történve van lekezelve, hozzá egy ezzel kompatibilis Azure-ös pár kattintásos dologgal, amikor fogom az egyik korábban összeállított template-et (vagy az élest "replikálom", ez a legjobb, konzisztens lesz a teszt, abból pikkpakk beröffen egy újabb környezet (legyen az VM vagy konténer), felkonfigolódik, igény esetén még a frissítések is lejönnek rá, hálózat, környezeti változók, minden fiszfasz kialakul és ready to serve. Ott már nincs az, hogy az üzemeltető alvállalkozó embere túrja egy hétig meg konfigolgatja, aztán úgyis elakad, úgyis hívja Bélát a fő architektet, aki morogva de kisegíti, közben eltelt 7 nap.. Ez élőben úgy néz ki, hogy gomb megnyom, közben kimegyünk kajálni a közeli kínaiba, és mire visszaérünk, az infrás átkurjant az asztal fölött a tesztelőnek, hogy nyomhatjátok, közben JIRA-ban az erre kanban board-on felvett standalone issue-t gyorsba bekommenteli és cső, Done. Szóval a public cloud szvsz nem CSAK magáról a technológiáról szól, hanem a mögé tett folyamatok gyorsaságról is. Arról nem beszélve, hogy ha a 100 gépből 20-30 teszt és ezek lefutnak és van kis levegő "semmittevés" teszt oldalon, ha épp nem kell az erőforrás, lelövi az ember és a stopper megáll: nem fizet érte az ember. Ha pedig kell, akár csak pár órahosszára is, akkor megint "play gomb" és mehet a boogie, pár plussz dolcsiért.
Összességében a private cloud-ban megoldott public cloud-os tech sima mezei installációként még nem adja mindazt a plusszt, amit tényleg ad egy public cloud. Persze ha nagyon kapálózik az ájtí főfejes, jöhet az MS felajánlani, hogy helybe letelepíti az ezsört az összes funkciójával együtt on-premise, csilingel is a kassza, ez szép megoldás lesz (és mindenki jól jár hehe, szép kis ország).. , csak ha 100 gép helyett 20-ra mondjuk nincs szükséged, mivel Nálad a host, az attól még bekapcsolva marad és fogyaszt, van egy költsége, míg a public cloud-ban a leverage effekt érvényesül, azaz tojsz magasan ezekre, ha nem használod az aktuális gépet pár órára vagy napra, lelövöd és kész, annyival kevesebb a költséged is, a többi meg a provider dolga (PaaS és ház a szilícium völgyben azért előrébb vannak tőlünk pár évvel). Az más, és mindenki döntse el magának, hogy a működő gépekért elkért költségbe beárazza-e a cloud szolgáltató e költségeket szétterítve - hogyne, nem hülye. De azért összességében még mindig van, amikor éves szinten több tíz millióval (!) jobban térül egy fully fledged Azure installáció, legyen az kicsi vagy nehézsúlyú k*sok gépes birkózó, mint egy on-premise private cloud csilliárdért, ami ennek tizedét sem (!!!) tudja... ahol a beszerzéstől az IT vezéren vagy CEO fővezéren át sokak kapnak vastag borítékot a beszállítótól, hogy ugyanmár, vegyétek a mi hardverünket és tessék-lássék supportunkat, segítünk, jóleszaz, egy kis Cisco ide, egy kis F5 oda, egy rack ide, egy EMC amoda, jólvan, buksisimi... A kassza meg csilingel..
Mondom ezt elfogultságmentesen kő linux pártiként és kicsit (de nem vakon) anti M$-esként.
Baszottul csak előre van út, szerintem. Erősen felhasználásfüggő, mi mire kell és megfelelő, nem jó mindenre sem egyik, sem másik megoldás, de azért a public cloud-ot nem tudnám most úgy leírni és lehúzni, mint ahogy akárcsak 2 éve is néztem rá.
A motyók több mint felét már egy ideje cloud szolgáltatóknak gyártják és ők is veszik, illetve lassan ők lesznek abban a helyzetben, hogy keresztbe-kasul bevásárolnak beszállítókból, maguknak ...
Át kell állni fejben, nincs mese.
-
samujózsi
senior tag
válasz
haddent
#28636
üzenetére
Repoban bízni... hivatalosban még fogjuk rá.
De az ubuntu universe/multiverse repok?
Vagy a fedora... nem jut eszembe ott minek hívják ezeket a külsős dolgokat.
És akkor ott a snap, ami... hát nem tudom...
Vagy a letölthető konténerek.És ezekkel nem is az az elsődleges problémám, hogy esetleg malware van bennük, sokkal inkább az, hogy mennyivel több sec.hole lehet az ilyen helyekről telepített szoftverek egy részében, mint a hivatalos példanyokban.
Nem általában és minden tűnik megbízhatatlannak, de ezek (egy részük) sokkal kevésbé ellenőrzött források tudtommal. -
-
sonar
addikt
válasz
haddent
#28626
üzenetére
Nem 100%-osak az ismereteim, de mondjuk az általad felsorolt cuccokkal meg tudod különböztetni, hogy a 443-on https megy vagy éppenséggel ssh tunnel?
szép dolgok - amit fentebb irtam. Hogy nagyon testre lehet szabni, hogy ki mihez fér hozzá kifele a neten. De ez másik szint.
Viszont neked még jó lehet az App Aromor. Alapban bent van az ubuntu-ban. Mélységi tapasztalataim nincsenek, de elvileg azzal is sokmindent lehet szabályozni. -
#68216320
törölt tag
válasz
haddent
#28551
üzenetére
Az a furcsa helyzet állt elő, hogy több dolgot is módosítottam, többek között az openbox start script-et is és most úgy tűnik rendben van.
Viszont így nem tudom mitől
Szóval a következő reinstallnál újra előjöhet a probléma. Próbáltam összeírni a változtatásokat, majd kiderül akkor, hogy mennyire voltam pontos.
Köszönöm az ötletet, mentettem mindent egy következő "visszavágóra". -
#68216320
törölt tag
válasz
haddent
#28549
üzenetére
Nekem van egy OpenBox a gépen és mégis ezt csinálja.
Gyanítom, hogy olyan gondja lehet, hogy amikor a monitor/TV lekapcsol vagy valami energiatakarékos funkció lép életbe (pl. a TV full fekete képnél lekapcsolja a világítást) akkor úgy érzékeli, hogy kihúzták a kábelt. Vagy már tényleg nem tudom
Hogy lássak egy működő példát. De pontosan az volt, mint amit írtál.
Meg se jelent a nat listában. Fura ez a Fedora na.
Új hozzászólás Aktív témák
Hirdetés
- Assassin's Creed Shadows Collector's Edition PC
- ROBUX ÁRON ALUL - VÁSÁROLJ ROBLOX ROBUXOT MÉG MA, ELKÉPESZTŐ KEDVEZMÉNNYEL (Bármilyen platformra)
- Játékkulcsok olcsón: Steam, Uplay, GoG, Origin, Xbox, PS stb.
- Bontatlan - BATTLEFIELD 1 Collectors Edition - Játékszoftver nélkül
- Adobe Előfizetések - Adobe Creative Cloud All Apps - 12 Hónap - NYÁRI AKCIÓ!
- AKCIÓ! Gigabyte H510M i5 10400F 16GB DDR4 512GB SSD GTX 1080Ti 11GB Rampage SHIVA Zalman 600W
- Azonnali készpénzes GAMER / üzleti notebook felvásárlás személyesen / csomagküldéssel korrekt áron
- Game Pass Ultimate előfizetés azonnal, élettartam garanciával, problémamentesen! Immáron 8 éve!
- Samsung Galaxy Xcover 5 64GB, Kártyafüggetlen, 1 Év Garanciával
- ÁRGARANCIA!Épített KomPhone Ryzen 7 5700X3D 32/64GB RAM RTX 5070 12GB GAMER PC termékbeszámítással
Állásajánlatok
Cég: Promenade Publishing House Kft.
Város: Budapest
Cég: PC Trade Systems Kft.
Város: Szeged