- Xiaomi 13 - felnőni nehéz
- Redmi Note 13 4G
- Samsung Galaxy A36 5G - a középső testvér
- Yettel topik
- Samsung Galaxy S23 és S23+ - ami belül van, az számít igazán
- iPhone topik
- Samsung Galaxy S25 Ultra - titán keret, acélos teljesítmény
- Samsung Galaxy A54 - türelemjáték
- Huawei Watch GT 5 Pro - egészség + stílus
- Magisk
-
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
-
haddent
addikt
válasz
samujózsi
#29721
üzenetére
Minden esetben, jelenleg is saját dns -t használok vele. Mi ezzel a probléma? Arch -on van egy systemd-networkd és egy másik ami netctl használ, egyiknél sincs probléma, nem nyúl soha hozzá az /etc/resolv -hoz. Ha szerverre gondolsz, az is van, bind szerver, ahhoz sem nyúl.
Melóban Suse esetén meg úgyis az a bánat Yast kezel mindent
Igen, na ez jogos. Szeret várakozni 1-2 percet ha megrogyik valami requirement boot során. Utána viszont ad egy recovery root shellt aztán uccu. Én ezt eddig nem tapasztaltam a kellőnél irritálóbbnak, hogy őszinte legyek, de igen, ez lehetne jobb -
haddent
addikt
Én továbbra is teljes tisztelettel kezelem a véleményetek, de szintén újra úgy érzem le kell írjam, hogy számomra viszont baromi kényelmes, flexibilis, agilis és könnyen kezelhető az egész systemd. Kifejezetten tetszik a .service, .socket .stb.. szisztéma, a konfigjai, a journald/journalctl jól kereshető, illetve csökkenti a logok méretét, néhány apró minimál cucc amit akkor használok ha csak 1 static ip vagy 1 dhcp client kell (systemd-networkd pl.) tök jó, komolyabb feladatra ezek egyelőre nem elegek de simán van és lehet mást használni..
Én nagyon örülök neki, hogy lett és van, mert legalább egy dologban "kiegyeztek" (nagytesók rákenyszerítették) a sok idióta 26ezer kis distrot, hogy ugyan használjanak már valami egységeset, ami fentebb sorolt indokokból ráadásul (nekem) tök jól jött kezelés, karbantartás ügyileg.
Nem kell egyetérteni, nem vitaindító, nem vita. Én elfogadom teljes mértékben a véleményetek illetve a "lelki"/filozófiai indokokkal részben egyet is tudok érteni, de részemről amíg f.o.s.s., addig hibátlan. Legyen ilyen tapasztalat is
-
haddent
addikt
válasz
Dißnäëß
#29714
üzenetére
Cégek (részben pl mi is) azért használnak vSphere -t mert van fizetős support és mert drága és költeni kell. Na meg mert minden nagyrabecsült rencőrgaszda hülye a linuxhoz meg a cli -hez mint a ...
Sose fogom megérteni, főleg, hogy ha meg már vinydósz, akkor ott a hyper-v. Mindkét platformon van natív, jobb alternatíva ![;]](//cdn.rios.hu/dl/s/v1.gif)
Másik kérdésed így most este passzolnám, de érdekelne mi a célod vele, puszta kíváncsiságból
-
haddent
addikt
válasz
Dißnäëß
#29698
üzenetére
Ez már működőképes és rendkívül egyszerű, stabil és nagy hatásfokú. Ezt hívják KVM/qemu -nak. A többi vmware hyper-v meg társaik egy vicc kategória minden téren előbbihez képest.
Nálam pl. egy i7 3770 cpu szerveren fut virtualizálva egy pfSense, átpasszolva neki 4gigabites intel NIC, 0% veszteséggel, a konkrét PCI lane -t megkapja a vm. Mondjuk valszeg a winfos még ezt is el tudja b*#!@ni guest-ként is, de azért akkor is elég jó.
bambano sajnos én viszonylag későn kerültem képbe a linux-szal, éppen egyetem előtt. Egyetemen pedig a (még)továbbtanulós/architektes szakirányon a C# tolták
Ma már semmi pénzért nem tudnék (vagyis nevetségesen mocskosul rengetegért) Wintrágyán élni, lakni itthon vagy azzal dolgozni. Egy konkrét használhatatlan szemétdomb az egész.
Csak egy példa, csak ma: csudálatos májkószofttím DC -ket cserél, mindenhol DNS csere. Az összes linux szerver az enyém, mindegyiken 10 perc alatt lecseréltem, és még csak saltstackemet se vetettem be hozzá. Mivel néhány win szerver gazdája haverom aki szabin van, gondoltam jófej leszek és megcsinálom ott is, ha már van tartományi server adminom is. Ideglelés... 5-10 percig tölt, csinálja a fiókomat, előkészül, mindjárt kész... utána pofándob egy FRISSíTÉS!!!! ablakkal, amin csak egy "ok megnézem" gomb van, nem tudsz neki nemet mondani. Majd nem érzékeli a kattintást (mert ugye milyen cli/tty?!), majd 15 perc elteltével lehet elkezdeni az effektív munkát, amit 15 felugró ablak után el is jutsz az ipv4 konfigig. Egy szánalmas poén windowst használni bármire, kivéve amire kényszerülsz, azaz játékra -
haddent
addikt
válasz
samujózsi
#29666
üzenetére
Nincs. Ahogyan (szerintem) ma és már jó ideje a swap partíciónak sincs létjoga. Ahogy te magad is írtad, backup-restore, vagy akár másik gépbe betéve, bármi.. PCI -os SSD -k korában élünk, percekről van szó. Sokkal többet ér egy heti/napi mentés valami (privát) felhőba tgz -ben aztán viszlát
-
haddent
addikt
Teljesen jó úton indultál el. Kifejezetten változót nem lehet (szerintem) használni és veszélyes is lenne. Vagy az fstab fájlt frissíted, vagy a külső cred fájlt.
Nyilván ez megoldható úgy, hogy egy ssh távoli parancsfuttatással a storage gépről amikor jelszót változtatsz kiküldöd a kliens(ek)re a frissítést, vagy saltstackkel még elegánsabb stb.
De ez mind workaround szigorúan véve és jó úton indultál el
+1 workaround: ssh kulcsát felveszed a storage gépen így jelszó nélkül tud ssh -ni és sshd fuseolni is, nálam pl. így van, de ugye ez ssh/scp alapú dolgokkal működik csak -
haddent
addikt
válasz
samujózsi
#29641
üzenetére
Kipróbáltam nem egyet, természetesen szigorúan self-hosted változatban és egyértelműen a Bitwarden-RS a legjobb. A Bitwarden önmagában egy szolgáltatás is tud lenni távoli szerveren (egyébként így is biztonságos, hiszen a tömény brutális privát kulcsod csak nálad van meg..), de van self-hosted verzió. Sajnos utóbbi sok komponensből áll, bonyolult, nem túl gyors, szóval otthoni felhasználásra (sem) az igazi, szerintem. Viszont létezik egy Rust nyelven újraírt változata, a Bitwarden RS.
Na ő self-hosted, nagyon egyszerű, nagyon gyors, nagyon biztonságos. Működik a hivatalos Bitwarden kliensekkel, amik ingyenes elérhetőek iOS, Android, Win, Mac, Linux tehát minden alá. Szinkronizál, telefonokon ki tudja váltani a gyári beépített pass managert (pl. ios -en faceid -val nyílik, alapból oda ment mindent nem az icloudba stb.)samujózsi a "matemágiában" (ahogy a laposföldiek hívják) akkor érhet meglepetés, ha hülye vagy (nem te, értsd jól). Mindig akkor bukott 1-1 nagy cég aki elvileg komoly kódolást használt, amikor pl. a random seed mondjuk úgy, hogy egy statik "n4gY0nR4nd0mCuCCczzz" volt, lásd Sony
-
haddent
addikt
válasz
samujózsi
#29620
üzenetére
Lehet, hogy irreleváns, de én pont azt figyeltem meg 1 hónapja, hogy az egyik hdd magától kikapcsolt, jobban mondva a mount eltűnt és az lsblk sem látta, mint device. Sata áram ki/be megoldotta, és működött is rendesen pár órát, de megint .., indokolatlanul. Az a poén, hogy "érzésre" ilyenkor is pörgött és működött. Gyanúm szerint haldoklott valami, mert kicseréltem egy másik hdd -re, minden egyéb beállítás, mount, minden azonos és megszűnt a probléma
Bár ilyen hdd pusztulatot még sosem láttam. Zörögni, csörögni, lassulni, hibázni szoktak, mindezt jó sokáig (mármint napokban-hetekben mérhető), majd használhatatlanná válni. De ilyet.. fura
-
haddent
addikt
válasz
samujózsi
#29612
üzenetére
Jester01 köszi mindkettőtöknek, akkor gyanítom az történt, hogy a játék végeztével rátoltam egy "pi*&#ba mindent on" és ez lett a vége
Már csak azt kell megtalálnom mi a bánatért nem marad offon reboot utánIlletve ha jól látom, akkor a GSO samunál nem szerepel (tehát on gondolom?), nálam meg off [requested on] nem igazán tudom értelmezni, de gondolom az is on akar lenni. Lehet, hogy azt visszabillentem akkor
-
haddent
addikt
Egy ideje szórakozik az interfészem, szakadozik. Tudom, hogy játszottam az offloadokkal és lehet, hogy úgy felejtettem valamit. Valaki megnézné, hogy ez mennyire tűnik így validnak / gyárinak egy intel gigabit interfésznek? https://cloud.rowra.org/s/ethtool
Amit ki kellett kapcsoljak, hogy megoldódjon:[root@homesever admin]# ethtool -k lan0 | grep -i ".*off$"
scatter-gather: off
tx-scatter-gather: off
tcp-segmentation-offload: off
tx-tcp-segmentation: off
tx-tcp-mangleid-segmentation: off
tx-tcp6-segmentation: off
generic-segmentation-offload: off
tx-nocache-copy: off
rx-fcs: off
rx-all: off
Azaz a scatter-gather, tcp-segmentation-offload, generic-segmentation-offload:ethtool -K lan0 tso offethtool -K lan0 sg offethtool -K lan0 gso off
Hozzátartozik, hogy se kedvem se időm nem volt egyesével játszani ezekkel, tehát lehet, hogy nem kellett mindet lelőni
Ezek alapból be szoktak lenni kapcsolva? (Ha igen, és nekem ki kell kapcsolnom akkor következtetésképp berosált a NIC?)
Megköszönnék egy pár outputot a fennti (ethtool -k lan0 | grep -i ".*off$") parancsból tőletek. -
haddent
addikt
válasz
kovaax
#29609
üzenetére
Ja nem, egyáltalán nem neked személyesen. Csak valahogy mindig eljutunk erre a konklúzióra miután elmondtuk, hogy szar a systemd szar a linux szar a szegmentáció a sapos kislányok windowson dolgoznak és a sap nagyon fontos és nagyon nagy és nagyon nő stb... és így.. vajon miért
-
haddent
addikt
válasz
kovaax
#29601
üzenetére
Bocs, hogy belepofa "utólag" (kicsit kimaradtam utóbbi 50hsz -ből), de ez miért meglepő? Minden értelmes production rendszer unix alapú, főként valamilyen linux, hálózati cuccok meg jellemzően bsd. (Persze, JunOS, meg Palo Alto meg Fortigate meg Stormshield aha... = bsd
) Nem azért, mert linux topicban vagyunk, de konkrétan semmilyen komoly, megbízható biztonság-érzékeny rendszer nem is lehet más, mint unix, mert különben nevetség tárgya, poénnak is gyenge.
Persze, a vállalatirányítás, hr kislányok, könyvelők meg ilyen nonszenz kamuszakmák és folyamatok mehetnek vinydózon, mert a kutyát nem érdekli (de, persze, látszólag mindenkit, csak úgy értem, hogy ha összeomlik akkor max a frontemberek hisztériáznak, nem a világ dől össze a szó legszorosabb értelmében) -
haddent
addikt
válasz
bambano
#29574
üzenetére
Szerintem arra gondolt a kolléga meg Linus is fregmentáció alatt, hogy csilliárd felé ágazott/ik a linux és "központi hatalomként" csak a kernel van, de ugye abból is forkolnak ide-oda mindent és semmi nem biztos, soha. Értem én, hogy sokszor szükséges a kalapálás-hegesztés egyedi módon, de 90% -ban ez a csakazértismáséssajátésegyedileszek
-
haddent
addikt
válasz
sh4d0w
#29567
üzenetére
Már miért kéne, hogy kieséssel járjon? Az fog majd csak igazán kieséssel járni, ha 1x beüt a krach egy ősrégi szemétdomb sebezhetőségei vagy szimplán hardverhiba vagy bármi miatt és nincs hova nyúlni, mert elpárolgott a support ahogy mondod. Ilyenkor azonnal saját vagy egyéb 3rd party support által POC rendszerben ki kell dolgozni a jövőt és amint kész 1 csettinésre átállni, szerintem
-
haddent
addikt
-
haddent
addikt
válasz
vargalex
#29516
üzenetére
Persze, azt az egyet ismerik. Azt hiszik, hogy a disztrok full más oprendszerek, mert máshogy néz ki, fingja nincs róla, hogy max. a csomagkezelő a más meg kicsit át van gányolva néhány konfigurációs rész-felület
Tőlem pénteken kértem új VM -et, kifejezetten csakis Ubuntu Server jó. Felhívom, hogy hát mióta idekerültem igyekszem kialakítani valami ökoszisztémát, indokolt, hogy csak Ubuntu jó? - Hát ők megnézték és az támogatja a Dockert meg visszafele is és ők Dockerezni akarnak ezért Ubuntu kell. Mondtam, hogy jól van, akkor kaptok egy szép SLES -t előtelepítve konfigolva saltstack, docker, compose aztán ha az általatok ismert 5 parancs közül egy nem egyezik meg inkább segítek szívesen 
Ennél már csak az fájdalmasabb, amikor bármi másra használnak windows servert, mint a buta-user (gonosz vagyok, de értsd: office-böngésző-levelező bajnok) active directory domain controlnak. Arra jó, minden másra teljesen alkalmatlan -
haddent
addikt
válasz
bambano
#29512
üzenetére
Nem mindenki, csak nem tudunk róla, mert tényleg belsős. Ha jól tudom a Google -nél saját Debian forkot használnak saját hardeninggel. Ilyen méretű dolgokra gondoltam, ez alatt vicc kategória.
De ellenpéldának melóban van, hogy hozzák a teljes vm imaget aztán na tartsd karban a saját kis kiépített sles - saltstack világodban azt a szutyokszemét oracle linuxot oracle db -vel. Oracle nevet eleve meglátom már rosszul vagyok, annyi fertőt hoztak a világra
Borzalom minden amihez nyúlnak -
haddent
addikt
válasz
samujózsi
#29510
üzenetére
Ja sry, senki. Soha a büdös életben nem lesz rendes helyen productionben sem rolling sem pedig non-enterprise linux. Egyetlen harmadik út van: saját, belsős disztro
Random mindfuck: tegnap kiadtam egy pacman -Syu -t 2 hónap után. Hát mondjuk úgy, hogy a csomagok számából ítélve már kerestem a boot usb -t chroot -hoz, mire megtaláltam felállt a htpc, az összes kvm vm meg minden. Néztem nagyot
-
-
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
-
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?
-
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
-
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 
-
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.
-
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
-
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
-
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
-
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
-
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 plsamujó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..
-
haddent
addikt
válasz
bambano
#29388
üzenetére
Ebből a kommentedből is látszik, hogy nagyon más nézetet vallasz. Nem rossz vagy jó kérdése ez és nincs igazad meg nekem sem, továbbra is mindkettő kell. Egy modern, nagy, bővülő, naponta 10x commit-test-deploy ci óriás enterprise szörnyet a te módszereiddel borzalom lenne életbentartani, vagy inkább lehetetlen.
Pont a példád a tökéletes példa. 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á. A json beolvasása objektummá ami aztán iszonyú jól kezelhető pontosan 2 sor (melyből az egyik 1 import) Pythonban. Nincs elírás, nincs jajj idézőjel, space, nincs fájl ellenőrzés mert ez mind a beolvasó object exception modelljeinek része. Egyszerű, elegáns és nem utolsó sorban gyorsabb/hatékonyabb is mint a bash valószínűleg, mert egy agyonoptimalizált C kód-wrapper
A hálózati példád nem fejtetted ki ennyire, de vakon erről is kb. ez mondható el. Lehet iptables írogatni vimmel, csak aztán azt tartsa karban meg egyben aki nem normális.. Akár csak egy Vyos vagy pfSense sem tesz rá túl óriási absztrakciót, de épp akkorát, hogy át tudsz látni 1000 szabályt is.
Viszont van az a hely, pl. pont a kígyó saját farkába harap, Pythont nem lehet Pythonban fejleszteni, mert egy fos lesz. C -ben kell
Nem az absztrakció az ellenség.. nem hülyegyerekek találták ki ezeket és nem hülyegyerekek számára. Akkor van óriási probléma, amikor a hülyegyerek él az absztrakció nyújtotta lehetőségekkel és kényelmi funkciókkal úgy, hogy fingja nincs róla mi zajlik a háttérben. Na az k*#& gáz, és sajnos ebben viszont igazad van, hogy ez a többség. De nem a puska a hibás, ha lelőnek vele valakit..
-
haddent
addikt
válasz
bambano
#29381
üzenetére
Miért, Pythonban megfordult a menetirány meg az ifirány, vagy miről maradtam le? Vagy a generátorokra gondolsz, amikkel 1 sorban rendezel le egy 50 soros C headert?
Az indentálást syntax részévé tenni szerintem fura, de jó ötlet, szerinted szar. A végeredmény szerencsére az, hogy még a kókánygenyó indiánus "programozók" kódja is valamelyest olvasható, néha -
haddent
addikt
válasz
inf3rno
#29373
üzenetére
Mondanám, hogy ízlések és pofonok meg szakirányok, de itt azért jóval többről van szó. Klisés kis példa, de jelen esetben egyébként tök jól szemlélteti a két nyelv és irány viszonyát: Pythonnal a NASA repül (és repült már régóta), Java -ból a (G)Ánydroid nem tud kigyógyulni 10 éve értelmes dologgá
Kicsit poénosra is fogtam, nehogy megsértődj, szíved joga Javat szeretni Láttam mindkettőt, egyetemen én szoptam C, ADA, ASM vonallal, másik szakirány röhögött jókat a Java -val. Én tökre értem mit szeretnek rajta sokan, csak azt nem, hogy a Pythonban hogy nem látják ugyanazt csak jobban és többet De hosszú téma, nem hittérítő szakkőr és úgysem változik semmi, peace tényleg bambano azért ez így erős. Még embeddedből se láttam régóta olyat, amin legalább egy Python2 és Perl ne lett volna. De természetesen egyetértünk, hogy bash -nak érdemes nekimenni ha Linux a fő irány, elsőnek. Az még erősebb, hogy bűncselekmények, ebben formában. Ha már úgy mondjuk, hogy az a bűncselekmény amit el lehet velük követni és a többség sokszor el is követ, akkor egyetértünk
Csak itt meg felmerül az, hogy C -ben még nagyobb ordas faxságokat lehet csinálni és csinálnak is. Nem egymás ellensége a kettő, sokkal inább kiegészítik egymást, szerintem (meg sokan mások szerint)I02S3F a bash-ben az lesz nehéz, hogy egy spaghetti bánat az egész. Mindenre van kb. 4 féle elfogadható és működő szintakszis, sokszor egyszerre botrányosan explicit, hogy már fáj leírni 200char hosszú sorban egy egyszerű dolgot, néha meg leírsz 4 betűt fura karakterekkel összekötve és feltepül 25 virtuális gép
-
haddent
addikt
válasz
I02S3F
#29359
üzenetére
Először is, igaza van a többieknek. DevOps és Linux (sysadmin?) két tök más témakör. Persze van kapcsolat, sok szoros is, de ennyi erővel a programozóval is meg még ezer másikkal (egyébként a DevOps kicsit mindenes IS, dolgoztam 1.5 évig DevOps -ként).
Az 1. pont mindenképp kelleni fog mindkettőhöz, én mindenképp a Pythont ajánlanám, mert egyre csak nő a részesedése, tavaly már #1 volt. Modern, hatékony (C libek), nagyon szép explicit syntax, rengeteg nyálcsorgatós syntax sugar, programozók nedves álma, első nyelvnek is, és a DevOps is szeretettel használja glue languagenek, scriptelni, összekötni. (későbbiekben ha komolyabban érdekel viszont kötelező szopni C -vel is kicsit!) Linux specifikus esetén bash kötelező
A 2. pont számomra majdnem teljesen irrelevánsnak tűnik. Egy része nagyon mély és régi dolgok amikkel napi szinten nem foglalkozik egyik sem (threads, concurrency stb.. tanultam egyetem, de őszintén felesleges első körben, nem kernel fejlesztő leszel..), egy része meg nagyon modern és advanced (virtualization)
A 3. pont eddig a legfontosabb, nem is értem miért nem 1. számú.. Mindkét OS esetén, bash/powershell és terminál minden mennyiségben. Addig kár is kicsit is komolyabban belevágni, amíg nem tudsz minden problémát terminálból megoldani, +pont jár érte, ha már undorodsz a gui -tól és direkt terminálból esik jól minden
4. pont fontos és hasznos, deeee azért ez ilyen estimese, elolvasod, megérted aztán amikor épp valamelyik nagyon mélyen kell majd belemélyedsz
5. esszenciális, mindegyik! Sysadminnak és DevOpsnak is. nginx/apache lefedi a 95% -ot, maradék 4% IIS (win), a maradék a többi viccelődjünk kategória. Nginx -et ajánlanám, az mindent is tud, jól, nem véletlen #1 minden értelmes helyen
6. Container, orchastration, infrastructure provision én inkább ezzel összecsapnám a 2. pontból a vm -et. Kell, és nagyjából itt ~6. pont idejében releváns is már. Linux esetén egyértelműen KVM és Docker, Kubernetes. Minden más megint csak ilyen szenvedjünk egy sort kategória, meg ha épp adott melóhelyen mégis valami elavult szar van, akkor 10 perc alatt beletanulsz, ha ezeket mélységeiben ismered, érted, használod
7. Nagyon fontos, nem nehéz. Jenkinst ajánlanám, teljesen free/open source, millió plugin. Pl. jó ötlet (meg innentől mindenre) feldobni 1 már megtanult konténerbe és játszani vele
8. Nagyon fontos, el lehet benne veszni, de azért mire ideérsz belejössz. ELK, Graylog, Grafana, Prometheus, CheckMK, QRadar. Szerintem ezek a relevánsak manapság, itt is elég elavult a lista.. nagios az alapja soknak, de magában már nem sok szart ér
9. Hát ja ez már a csúcs, mindent valami távoli cloudban deployolvaBocs a hosszú válaszért, de ha komolyabban érdekel a dolog szerintem érdemes ezt az álláspontot is meghallgatnod, ez viszonylag friss tapasztalaton alapul, utóbbi 5 évben 1.5 év multinál devops, 1 év full stack developer, 1 év sysadmin / network / sec analyst. Természetesen nem kell egyetérteni meg szentírásnak venni, ahogy mondtam tapasztalat és vélemény
-
haddent
addikt
Amúgy ti miket tároltok így a h/sdd -iteken?
Én pont leszarom, ha 1:1 -ben viszik az itthonit meg a cégest is, pedig "C" típusú bevizsgálásom van, tehát a munka kényes eléggé, csak nem tárolok rajta semmit Amúgy is a legjobb hely a google drive! Ingyenes, sose vész el, ha kitörlöd is vissza tudod kérni 40 év múlva is a nagytesótól -
haddent
addikt
VPN -es kérdés: Adott egy ipsec v1 aggressive vpn kapcsolat. Megvannak a certek, felh.név, jelszó, p1-p2 paraméterek, minden. Linuxon hogyan tudom működésre bírni? Certekkel ÉS AD/Ldap username+password -del authentikál, AD/ldap -ból lekéri a csoportokat és az alapján ad ip/routing/rules. Sajnos utóbbit, hogy még a certeken felül van xauth sehol nem találok példát..
-
-
-
haddent
addikt
-
haddent
addikt
válasz
samujózsi
#29280
üzenetére
2. -re: nem része, de nagyon egyszerű és elegáns megoldás van rá systemd -vel pl.:
https://wiki.archlinux.org/index.php/Rsync#Automated_backup_with_systemd_and_inotifyEz most épp backup, de nyilván a backup is csak egy copy, tehát ua.
-
haddent
addikt
válasz
samujózsi
#29262
üzenetére
Frawly elhiszem, már van 2-3 éve Digi FTTH (családi ház) és a mai napig kissé felfoghatatlan, hogy mennyire jó és olcsó. Számomra azt hiszem így életem során eddig tapasztalt legmeglepőbb/jobb szolgáltatás amit valaha bárki fel tudott mutatni. Még a Google Fiber is max. annyival tud többet, hogy az szimmetrikus 1G, nem 1G/300M, de ez már a Digi köcsögölése nyilván tudná röhögve. Kitartás, egyszer mindenhol véget ér az internet sötét középkor
samujózsi ki kéne próbálnom, mert fejből azért ennyire nem megy, de azt hiszem alapból az rsa kulcs még encryptálva lett a "jelmondat" (húdefaszafordítások
) által, ezért még azt kibontja sima b64 encodedbe, majd parasztvakítással "megkeveri" . Azt hiszem csak utóbbi verzióval tud aláírni certeket, az encrypted nem sok mindenre jó magában, mint egy ssh key a jelszava nélkül kb.
De ezt az oldalt engedd el, borzalom a fordítás is, meg maga a parancsok is. Mi a bánatnak generálja le X néven, hogy aztán +5 paranccsal kevergesse?
[link] ez szerintem sokkal érthetőbb -
haddent
addikt
Érdekességképp megosztom a hetek óta tartó tesztelgetésem durva eredményeit. Sajnos ha én magam sokkal precízebben hajtom végre a teszteket sem lenne precíz, hiszen változik 2 mérés közt a hálózat és a távoli szerver terheltsége is. De több mérés alapján KVM virtualizáció esetén 3 dolog mondható ki: VIRTIO driver többségében nagyon jó, megfelelő beállítások és támogatottság esetén minimális <10% kb. a veszteség, ami néha erősen közelíti a nullát. Néha sajnos megmagyarázhatatlan okokból viszont elég erőteljesen megrogy, majd megint hozza a jó hatásfokot. Minden más virt-driver egy használhatatlan szemétdomb, kb. inverze az virtio-nak, 90% veszteség. A PCI pass-through továbbra is verhetetlen, mérési pontatlanságon bőven belül, nem kimutatható veszteség (ha egyáltalán van).
Mindez Digi gigabiten, ami 900-950Mbit/s stabilan tud szinte mindig. Nagyjából ezekre az eredményekre jutottak a Redhates srácok is, csak ők nagyobb 10 gigás ligában játszottak -
haddent
addikt
Egy elvetemült kérdés következik valami nagyon linuxos nagyon virtualizációs nagyon hálózatos szakember felé. Adott egy Dell Optiplex 7020, gen4 i3, 2x dedikált pci-e intel nic, 8gb ram. Bare-metal, Arch linux legleglegfrissebb kernel, mindenféle absztrakció nélkül sima iptables -szel WAN <-> LAN NAT throughput szépen szaturálja a Digi gigát megfelelő szervert választva (Antenna Hungária, JZT stb..) speedtesti-cli -vel, ~900+ Mbit/s. Eddig oké.
Adott továbbá egy KVM virtualizáció, melyhez VT-d bekapcsolva, IOMMU kernel param bekapcsolva, virtio type.
Teljesen azonos konfigokkal, 2gb ram, 2vcpu + ssd -n .qcow2 a következő érthetetlen értelmezhetetlen hülyeségek jöttek ki, teljesen azonos szabályokkal (a saját absztrakciójukon, meg ugye egyik bsd másik linux bf vs iptables stb., de elhisszük, hogy nagyjából ugyanazokra a kernel hívásokra "fordul") LAN <-> WAN NAT:OPNsense: ~4-500Mbit/s
ClearOS: ~300Mbit/s
VyOS: ~5-600Mbit/s
PfSense: ~900Mbit/sMinden esetben a guesten mindenféle hardware offload (checksum rx tx stb.) kikapcsolva. Tehát amennyire csak lehet teljesen egységes körülmények. Na most ilyenkor wattafakk van?
iptables vs bpf megérteném, de van 2 linux nagyon hasonló alapokon és 2 bsd ami egymás forkjai és ott is óriási különbségek vannak Bónusz +1: hogy lehetne még többet kisajtolni? Egyelőre PfSense -nél ragadtam érthető okokból, de az az érzésem, hogy minimálisan ~50Mbit/s így is veszteséges, ami 1g -nél belefér, de ehh...
-
haddent
addikt
válasz
bambano
#29234
üzenetére
Rendbe bizony
De már megy, hardware offloadot ki kellett kapcsolni.
Következő csoda: minden tökjól natolódik, kivéve szerencsétlen deluget. Bármit csinálok, nem tölt se föl se le lényegében. Deluge ui -ban zöld minden, de amúgy kb. 0 forgalom. Sense logban már zöld minden, NATolva van egy konkrét porton, reflekt (oda-vissza), egyszerűen nincs reject, mégis
Bár épp az előbb bugolt be, fogta magát és olyan rule alapján engedett valamit amit már töröltem. Aztán meg létrehoztam újat és arra meg nem futott rá .. Még 1-2 ilyen aztán köszönöm szépen megyek vissza iptables cli -hez -
haddent
addikt
Sziasztok KVM networkinges kérdéssel fordulnék hozzátok. A következő a setup:
vason 3 hálókártya, 2 bridgeben. Egyik egyedül, másik kettő összefogva. Kvm virt-tel, bridge módban hozzácsap mindkettőhöz 1-1 -et még, ezt kapja meg az opnsense. Megy a digi pppoe, és bármit dugok a fizikai bridgelt lanba, tök jól megy minden. Viszont a hoszt gép (és így a többi virtuál kvm gép) hiába kap ip -t, sőt pingeli a 8.8.8.8 -at, resolvolja a googlet, látszólag minden jó, minden ki van engedve, de pl "curl google.com" már kifagy, semmi
Biztos valami apró részlet, vagy óriási ,de elfáradtam, ötlet?köszi!
-
haddent
addikt
válasz
samujózsi
#28875
üzenetére
Alapvetően egy Docker container image -ről nem fogod tudni eldönteni, hogy mi van benne, erre nincs API érhető okokból. Tehát csak a készítő specifikációjában bízhatsz. DockerHub, stb.. Ha mélyebben érdekel a téma, van egy aprócsak Docker topikunk, de hátha ott több ötletet kapsz
-
-
haddent
addikt
Biztos marhára reggel van, de hirtelen.. ki látja ebben a hibát?
49 7 * * * /usr/bin/python3 /home/dc/backup.py > /mnt/BKP/log 2>&1
Kézzel futtatva tökéletes, cronnal futtatva mindig 20kb -os kis lóhere képződik, nem az elvárt gunzip. A python scriptben van a lényeg, de mivel kézzel futtatva, sőt konkrétan a cron linet kimásolva hibátlan gyanítom ebben a szemétben lesz valahol a hiba. Ötlet?
-
haddent
addikt
válasz
bambano
#28789
üzenetére
Én egy szóval nem állítottam, vagy akkor félreértettél, hogy csak annyit tenne. Nem ismerem olyan mélységeiben, hogy működési elveiről vitázzak és különösebben jelenleg nem is foglalkoztat, hiszen az iparban systemd van, akárkinek akár tetszik, akár nem. Majd ha más lesz akkor megtanulom azt 1 nap sz**ással aztán ennyi
Két dolgot állítok, egyik az személyes véleményem és tapasztalatom, hogy szerintem/nekem/én tapasztalataim alapján tök jó a systemd. Ezzel vitába lehet szállni, csak felesleges, mert mostmár egészen világosan kiemeltem, hogy szubjektív, illetve felőlem hívhatod izolált esetnek, bár nem hiszem, hogy egyedül vagyok.
A másik, objektíven, hogy ha talán pl. neked / te felhasználásodban nem is a legjobb, azért bőven használható és workarounddal simán megoldható minden, ahelyett, hogy kézzel kelljen bizbaszkodni, még ha mondjuk sysvinitben szebb is lenne, vagy neked jobban kézreállna/tetszene.Sőt, lehet, hogy többet tud a sysvinit, nem tudom. De nekem se itthon, se a szervereken melóban sehol nem volt eddig másra/többre szükségem. Azt akarom csak ezzel mondani, hogy továbbra sem vagyok semminek a hívője, pl. ott lenne a networkd is, de nem használom, mert ku***ra kevés az én igényeimnek egyelőre. De a netctl, ami nem is tudom pontosan talán Arch saját projekt de systemd mintára, az egyik legjobb, megint, nekem
-
haddent
addikt
válasz
kovaax
#28786
üzenetére
Ezt eddig nem tapasztaltam, de ha te igen biztosan előfordulhat. Mondjuk ilyen "szoftvernek" csúfolt szemetekkel, mint oracle meg java nem biztos, hogy bármi másban keresném a hibát
bambano személy szerint nekem messzemenőkig túl explicit és feleslegesen szájtépő a sysvinit. Ettől függetlenül ilyen extrém felhasználásban mint a tiéd, lehet, hogy jobb, vagy neked jobb, ezt nem vitatom, mert nem próbáltam
-
haddent
addikt
válasz
bambano
#28783
üzenetére
Mert a többi 90% -ban egyszerűbb és hatékonyabb. De ezt már túltárgyaltuk, hogy neked nem begyerés akkor sem, itt csupán szükségmegoldásról volt szó, hogy azért működésre lehet bírni, nem kell kézzel
ivana eh, jah, lényegében ugyanaz csak kicsit tisztább, hosszú volt a nap
-
haddent
addikt
válasz
bambano
#28779
üzenetére
Tisztán elméleti okoskodás részemről. Szóval lehet, hogy "oem" nem megy, de amit meg tudsz kézzel csinálni, azt scripttel is. Mi lenne, ha scriptelnéd amit kézzel csinálsz, és beraknád multi-user.target.wants -ba, majd szintén ide a postfix-et, csak a postfix.service -be tennél egy
After=manual-hax-startup- ot? Ennek pontosan azt kéne elérnie amit szeretnél, elméletben.Az más kérdés, hogy out-of-the-box miért nem működik, de szerintem azért eléggé egyedi igény ahhoz, hogy egy manual scriptet elviseljen. A sors fintora, hogy más inittel úgyis kéne írtni scriptet
-
-
haddent
addikt
válasz
inf3rno
#28774
üzenetére
Mindkettő syntaxa annyira csúnya, hogy már ott alapból elhasal részemről.. De huzamosabb ideig nem használtam egyiket sem, lehet, hogy a funkcionalitása amúgy jó. Tényleg tisztázni szeretném, hogy nincsen preferenciám sem favoritom, azt használom amit kényelmes és működik, illetve nyilván ami mögé beáll a suse meg a redhat
-
haddent
addikt
válasz
bambano
#28771
üzenetére
Hittől, terminológiától, hangzatos definícióktól és mindenféle 30 éves télapó szakállas unix idézetektől mentesen leírnád, hogy mire pazarlod a munkaidőd, amikor systemd -re kényszerülsz? Őszintén érdekel, nem szarkazmus / kötekedés. Csak mert nekem tényleg eddig kivétel nélkül csak megrövidítette a munkám, de kb. tizedére minden esetben. Nyilván ezért ""szeretem"", semmi másért
-
haddent
addikt
válasz
bambano
#28750
üzenetére
Ez már kezd áthajlani szubjektivitásba kicsit, bevallom, de szerintem nem logikus az épp előbb említett változtatásokkal fejenként 5 distro. De igaz, kicsit drasztikus vagyok, pl. nem értem a Debian/Ubuntun kívül minek bármi más deb alapú? Archon kívül minek bármilyen Arch alapú..? stb.. Meg tudnám indokolni és logikus lenne (max nem értenél egyet vele), de igazából felesleges, ez van, így van aztán kész
-
haddent
addikt
válasz
bambano
#28739
üzenetére
Ez így van, sokkal régebbi. És sokkal kevesebben használják. Most felsoroltál 3 (?) bsd disztrót ezen kívül van még talán 2 (?) direkt tűzfal (pfsense, opnsense) aztán nagyjából kifújt. Linuxból hány van? Hány olyan okoskodó jajdekülöndisztró kell akik annyit csinálnak, hogy reskin aztán hello? Mégis minek.. Mindegy, eltávolodtunk. Nekem sem felhasználói, sem programfejlesztői (igaz, nem direkt systemd plugin / lib, hanem saját..) szemszögből nem volt vele soha gondom, gyors, működik és számomra intuitív is, én szeretem. Ha ezek közül bármi változik, nem fogom szeretni. Egyszerű vagyok
Ha meg van / lesz (és nem érdekel, hogy mi vóót ecce meg talán lesz ecce..) jobb alternatíva akkor ugrok oda. Na meg ha suse, redhat, centos beáll mögé, mert köszönöm nem fogom magam szopatni melóban direkt.. inf3rno felesleges a Dockernél alacsonyabb szintű jail/container. Minimális overhead van linux host - linux container esetén, sokszor mérési hibán belüli.. Ami meg annyira erőforrás szenzitív, azt meg úgyis C -ben, ASM -ben vagy max Rustban írjuk és eszünkbe nem jutna még csak virtualizálni sem, nem?
Az meg nagyon igaz amit írtál még a Dockerről, ezer más egyéb előnnyel együtt. Na tessék, itt is itt ez a nyekergős szenvedős vergődés... Ott a Docker, megy, tökéletes, jó, támogatott, elterjedt és már van kb. 5 másik """alternatívának""" csúfolt szerencsétlenkedés (nem a bsd jailre gondolok) -
haddent
addikt
válasz
inf3rno
#28732
üzenetére
BSD -n van saját konténerizáció, nem Docker
Pont ezt akartam egyébként felhozni, hogy a BSD -k mellett az érvelés Linux-szal szemben mindig az volt, hogy sokkal összeszedettebb, nem ennyire szétszórt szanaszét ahogy ivana is írta "melyik disztrón vagyok?" Na most a systemd ezt (is) hivatott kicsit rendszerezni, és jól csinálja, ahogy írta a kolléga is.
Félreértés ne essék, én sem a fejlesztőjét sem a systemd -t nem szeretem és nem kötődöm hozzá. Baromira nem érdekel melyik lesz az irányvonal, de ugyan már legyen már egy irány, pl. ami mögé az enterprise server linuxok beállnak a többi kis szaros meg úgyis követi. Legyen már egy helyen, egy szintax szerint egy féle upstart script meg miegyéb.. Mert az kriminális ami előtte volt
Akinek meg ez az utópia (mondom, függetlenül, hogy systemd vagy más, nem érdekel! csak legyen egy uniform, ajánlott vanilla config) nem tetszik az természetesen továbbra is használhat bármi mást, csakk akkor szívjon vele személyesen és egyedül kivételesen ő, nem a sysadmin amikor egyszerre 4 distroval dolgozik rajtuk 15 különféle cuccal és mindegyiknek, még az azonosoknak is tök máshol és máshogy van minden hülyeségük..De ez továbbra is megfigyelhető, meg úgy ez jellemző a linux közösségre és pont ezért is szólják le, pontosan többek között a BSD -s srácok. Mert mindenki mindent IS jobban tud a másiknál és képtelen bármiben is megegyezni, mindenki mindent kicsit máshogy csinál. Mert pl. biztos ku.... fontos és lényeges, hogy ne "www-data" legyen hanem "www". Meg ne apache2 -nek hívjuk, hanem httpd -nek, de inkább mégis apache -nek stb stb... Na ez otthonra elmegy szórakozni, de máshova nem.
Épp ezért mondom, hogy szépen legyen csak egy "ajánlott", vagy bevállt, biztosan működő cucc, aztán mivel open source, majd akinek az nem begyere az gányol magának otthon mást
+1 elvont lelkizős kérdés: az miért nem gond, hogy kivétel nélkül az összes linux használja a GNU alapprogikat?
Ja várjunk.. pontosan van olyan elmebeteg állat aki csinál disztrót ami nem gcc -t használ -
haddent
addikt
válasz
samujózsi
#28711
üzenetére
Őszinte leszek, az életben nem olvastam a Potter gyerekről egy sort se, le**** amíg működik a cucca
De most azért kiváncsivá tettél, linkelsz 1-2 olvasmányt amiből átjön, hogy miért nem szimpatikus? Bár legyünk őszinték, Linus és Stallman is elég hát special snowflake, én mégis bírom őket -
haddent
addikt
válasz
inf3rno
#28703
üzenetére
Évek óta Archozok desktopnak és itthon szervernek is, sőt, stikában melóban is az a desktopom
Minimál, friss, rolling release és mégis stabil, teljesen vanilla lényegében a pacmant leszámítva és a Wiki tényleg fenomenális. Nyilván nem eröltetem meg nem is lehet, neked lehet, hogy nem fog bejönni, de ha hasonlóban gondolkodsz egy próbát mindenképp érdemes tennedFrawly A Gentoo lényegében annyiban más az Archtól, hogy te buildelsz/compileolsz. Tudom, hogy ez egy óriási különbség, de én a mai világban mai procikkal ezt elenyészőnek érzem, minimális vagy talán mérési hibán belüli overheadet jelent szerintem a prebuilt. Igen, az a legszexibb, de az már tényleg nem éri meg, szerintem
Egyébként ha tényleg könnyű kezelésű cucc kell, nem akarunk ennyire elmenni a vadonba, csak ne legyen telehányva akkor én az Ubuntu Server -t szoktam ajánlani az óriási community és repok, tutorialok stb.. miatt
Systemd hitvitába nem akarok megint belemenni, de annyit csak nem bírok ki, hogy offtopicba ne írjam le, hogy személyes és linux sysadminos tapasztalatom szerint is az utóbbi idők legjobb történése linux körökben.. Fenntartható, stabil, implicit és rendkívül jól rendezett
-
haddent
addikt
válasz
Frawly
#28695
üzenetére
Hát én letiltani tudok segíteni, csak aztán, hogy mi lesz nem tudom, fogalmam nincs kapásból ez mit csinál
De
systemctl status systemd-random-seed-del nézd meg, hogy hol a .service, pl nálam:... Loaded: loaded (/usr/lib/systemd/system/systemd-random-seed.service ...És konkrétan töröld ki (backup után)
Vagy kommentezd ki az ExecStart -ot és rakj be egy echot a helyére vagy valamit -
haddent
addikt
válasz
Dißnäëß
#28662
üzenetére
Ezzel nem teljesen értek egyet. Abban igazad van, hogy egy szolgáltató szolgáltat, ebből él. Tehát ha hiba van, kérés, igény bármi, akkor szólsz és ugranak rá, mert ha nem elvesztenek és elesnek a megélhetésüktől. Abban is igazad van, hogy mivel ők nem egy-kettő netán 100 instancet üzemeltetnek, hanem (száz)ezreket, vagy többet, ezért minden felgyorsul. Nagyobb csapat, egy helyen lévő hiba mindenhol javítódik, stb stb..
Na ezért nem szabad egy problémát megoldani többször, tipikus rabbit hole. Tudni kell keresni, mert 99%, hogy bármi jut eszedbe, már van rá megoldás és jobb, mintha te nekiállsz gányolni egy kis csapattal.Azzal nem értek egyet, hogy ezt lényegében részrehajlóan csak 3rd party hostinggal lehet elérni. Egyrészt elvből kiröhögöm még az olyan Azuret is, amit on-premise kihoz az m$ és ledob a pincédbe. Nálunk a cégnél van ilyen, ehh.. továbbra is az futkos ott amit az m$ akar, ki tudja mi.. Ezzel max. azt lőttük ki, hogy nem megy ki a public netre és nem tudják fizikailag elvinni az m$ telephelyéről. Ezek azért ma már megoldott dolgok szerintem, nem ezen van a hangsúly.
Nem rossz dolog ez, de az agile is kötött, főleg egy kommersz cégnél. Ami sokaknak tetszik (a mazohista hülyék
), épp ez, az előnye is, hogy kötött, az az óriási hátránya is. Míg egy open source projektnél ilyen nincs, ráadásul ott van előtted a programkód, nincs turpisság meg susmus. Szerintem a legjobb választás egy olyan open source implementáció ami mögé már kiépült egy kommersz cég, aki azonban nem az eladásból, hanem a supportból él. Ott megvan a napi szintű pörgés és a community ereje, viszont nem csak a gugli és stackoverflow marad, ha beüt a gatya.. Mindkét világ jósága.Az, hogy a legtöbb cég és kedves kollega 20-25 évvel le van maradva pedig nem azt jelenti, hogy az törvényszerűen csak úgy működhet. Mondom ezt úgy, hogy ELTE -n tanultam papíron formális matematikai nyelven ciklust meg programkódot írni és C/C++ hívő vagyok, csak nem hülye
Simán kiépíthető egy poc/teszt és egy live környezet. Előbbi akár napi szinten automatizálva rángatja a frissítéseket és verziókat, Jenkins CI build + test, amint pass át is csapja livera. Mindezt mondjuk Dockerrel megspékelve gyönyörűen logolható, nyomonkövethető és fenntartható környezetet kapsz ami oda-vissza véresre veri az akár onpremise akár public monumentális nevetséges őskövületi szarokat akik már csak a nevükből élnek, mert más előnyük nem maradt Igen, az itt felsorolt megoldások merőben más gondolkodásmódot és szakembereket követelnek meg, mint az összekattintgatom egérrel microsoft jajjdejó megvan a winserver 2016 tanúsítványom elvégeztem a tanfolyamot dege#*menővagyok, de én ebben hiszek. Elismerem és elfogadom a te véleményed is, szerintem kicsit elkanyarodtunk és olyan mélységben tárgyalunk ahol nem feltétlen van megoldás és/vagy objektív igazság, hitvallás kérdése
-
-
haddent
addikt
-
haddent
addikt
A Darktrace igen, riaszt egyből. De kijátszható, mint minden. De itt a kérdés az, hogy hogy? Pl. amit mondtál, a 443. Te ott kifele mész ugye általában.. Ha meg te hosztolsz és 443 -on beengeded akkor az nginx egyből pofánba.... ha megpróbálsz rá ssh -ni, hogy mit képzelsz
Szerintem ez kicsit sok paranoia egy átlagfelhasználó számára. Utóbbi kommentedre pedig, ha nyilvános wifiket is használ messze a legjobban egy vpn, lehetőleg OpenVPN -nel jár, mintsem bármilyen tűzfalakkal.Unixon ezek a dolgok azért nem olyan pofonegyszerűek, mint winfoson. Itt ilyen szintű hackeléshez komoly user error kell, az ellen meg semmi nem véd. Persze értem amit mondasz és jogos, de mondom, személyes véleményem (és szigorúan az, nem tény!) szerint kicsit paranoia átlagnak
-
haddent
addikt
Ez így nem feltétlenül igaz azért, meg hát eleve az iptables lényegében csak egy kernel szintű packet filter végülis, meg max egy cli hozzá. De akinek van rá igénye, annak ott a BPF, lehet vele kísérletezni, az a jövő. De persze, nyilván egy barebone iptables nem nyújtja azt out of the box mint egy stormshield + darktrace, annyira nem sokkoló hír
Mondjuk valószínűleg nincs is szükség ilyesmire, ha kattintgatós menjen-ne menjen feldobós ablakos tűzfalról történik a váltás, szerintem.
-
haddent
addikt
Ízlés kérdése. Feleslegesen (és igen, mindig, minden eset 100% -ban felesleges
) nem helyeznék ki semmit sem távoli helyszínre, főleg nem egy - egy olyan megbízható nem kémkedős aranyos kis cég kezébe, mint az m$$$$ vagy a guggle. bambano Modern, működik és egyszerű. Néhány speciális feladattól eltekintve (pl matlab) simán minden mehet webes appnak, egy helyre. Nem kell azt kiengedni sehova, mehet lokálban, aztán ha távolról mégis akarnak dolgozni akkor openvpn-as. De a lényeg, hogy nulla telepítgetés, nincs adatvesztés a kliensek meg lényegében kb eldobható hasztalan kis semmiségek. A networking is leegyszerűsödik, mert mindent megold 443 -on. Persze, nem hatékony, de azért egy modern JS / HTML5 frontend + Python backend kemény cucc tud lenni. És újra: airbag fejlesztés matlabbal, meg kernel patchelés terminálos vim -ben nem így fog történni, de így kb. ezeket leszámítva a hülye usernek oda tudsz rakni valamit amit nehéz elb.... és ha sikerül akkor is kap egy új klienst egy böngészővel aztán mehet tovább.
Nyilván ez az én értelmezésem és ennél több és kevesebb is tud lenni a "cloud". De egy példa: a cégnél konkértan 2019 -ben kiba....ott keepass fájlokat küldözgettek egymásnak emailben, és pontosan ahogy egy levlistánál régen, úgy itt is nyilván kialakult egy össze-vissza cross dependency meg 25 branch kb. És akkor így megkérdeztem, hogy oké, akkor miért nem használunk pl. egy Syspass -t? HTTPS, php encrypted, benne lehet a személyes és a csoportokra osztott jelszavak is stb.. Megszűnik a probléma. Tehát pl. kollaboráció is.
Röviden szerintem lényegében addig a pontig amíg megengedhető/belefér a veszteségesség / "hatékonytalanság", addig csak előnye van -
haddent
addikt
válasz
bambano
#28600
üzenetére
Így van. Nálunk a cégnél konkrétan egyedül harcolok *nixesként a gonosz ellen. A múltkor csináltam egy backupot a "statikus" wordpressről amit kibaxtak áázzsőőőrbe mert az jó mert májkrémszoft. Azt hiszem 1.6GB és valami 80 ezer Ft ba került
De cserébe legalább jó szar.
A felhő maga nem ördögtől való, sőt, kifejezetten előnyös én nem is kezdenék új rendszer kiépítésébe de még modernizálásba sem másképp. Mindent fel a felhőbe meg termszerverre a kliensek meg tök mindegy, ami van, 10 perc alatt egy imageből húzható haszontalan kis vackok. ...szóval ja, csak éppen self-hosted cloud, nem ilyen m$$$ -
haddent
addikt
válasz
bambano
#28593
üzenetére
Valamiért mégis. Nyilván egy otthoni kis projektről van szó, így aztán a tesztelés 3 hálózatból állt: digi (saját, itthoni), telenor (mobilnet) és telekom (meló), de ezek 1-2 percen belül tudták az újat. Ne kérdezd hogy hogyan, nem tudom. Lehet, hogy kipusholja a google direkt. Mondjuk jobban belegondolva itthon és melóban is én vagyok a "reccergaszda" és explicit módon 8.8.8.8 -at használok
-
haddent
addikt
válasz
bambano
#28589
üzenetére
Nem feltétlenül macerás. A google domains -nél pl van lehetőség dinamikus A rekordra amit API -val lehet frissíteni. Nálam így van, kb. 1-2 perc alatt befrissül, ha véletlen restartkor változna az IP -m. Persze egy cégnél, levelezésnél 1-2 perc kiesés nem feltétlenül a legszebb dolog, de nem is feltétlen indítgatják újra a szervereket. A gond inkább ott lesz, hogy az SMTP portok közül általában az összeset tiltják a p....ba nem üzleti előfizetésnél, sőt DIGI -nél pl. még üzletinél is
Backupban és a termszerverben egyetértünk CPT.Pirk ment priviben a user
-
haddent
addikt
válasz
CPT.Pirk
#28586
üzenetére
Konkréten még nem csináltam, de szerintem mindenképp érdemes lenne vetned egy pillantást a Nextcloud -ra. Eleve a fájlmegosztás sokkal elengánsabb megoldása, illetve rengeteg beépülője van, legalább 3 "office" környezet is, levelezést is bele lehet integrálni mindent. Ugyan az említett officeok közül van fizetős is, de ingyenes is. Ha ezt faszán összehoznád lényegében minden egyetlen localhost web felületen működne, így a kliensek is leegyszerűsödnek, mert nem kell minden hülyeséget telepíteni. Bocs, a Calendart alapból tudja és ingyenes, Office nélkül is
Nekem van itthon Nextcloudom, ugyan office nélkül. De ha szeretnéd adok hozzáférést, hogy körülnézz egyáltalán érdekes lehet-ecigam egy nason futtatni bármilyen szervert? Még otthonra is kényszermegoldás, nem vállalati szférába, szerintem
-
haddent
addikt
válasz
szuszinho
#28555
üzenetére
ip link-ben nem ragadt be pl tun0, vagy nincs más hülyeség?
Ha igen akkorip link set dev tun0 down. Esetlegiptables-save-ben nézd meg, hogy látszik-e a nyitott port a megfelelő irányba, illetvess -lntu(ez ubuntun lehet, hogynetstat -lntu) -ban nézd meg, hogy egyáltalán megvan-e a port listening, és ha igen a megfelelő ip -n és azon próbálod -e elérni? Lehet, hogy a vpn szétmasszírozta a dolgokat kicsit -
haddent
addikt
válasz
#68216320
#28540
üzenetére
Hasonló setupom van, annyi különbségel, hogy én mindenképp full minimált szerettem volna, ezért Arch linux van és rajta kodi-headless volt. Pont ugyanez a jelenség jelent meg, de nekem csak a Leia -val, előtte nem volt ilyen hülyesége..
Na mindegy, a lényeg, hogy nem sikerült megoldanom csak úgy, hogy van egy minimál window manager, csak éppen semmit nem észlelek belőle, mert autostart, autologin és indítja is a kodit. Így megszűnt ez a probléma, szóval tudom ajánlani, biztosan ubin is megy:- lxdm wm-t tedd fel engedélyezd stb. (lxde nem is kell hozzá)
- /etc/lxdm/lxdm.conf -ban legyen egy autologin=kodifelhasznalo sor
- az előbbi felhasználó home -jában legyen egy .dmrc fájl és tartalma:
[Desktop]
Session=kodi-standalone(Nálunk a kodi-standalone bináris is települ a kodi -val, nálatok lehet, hogy ez külön csomag)
Elvileg ennyi, reboot és egyből indul a kodi, nincs több display sleep
Ha még mindig nem megy, akkor érdemes egy .xsessionrc fájl is a homeba:
xset s off
xset -dpms
Sose fogom megérteni, főleg, hogy ha meg már vinydósz, akkor ott a hyper-v. Mindkét platformon van natív, jobb alternatíva ![;]](http://cdn.rios.hu/dl/s/v1.gif)
Ma már semmi pénzért nem tudnék (vagyis nevetségesen mocskosul rengetegért) Wintrágyán élni, lakni itthon vagy azzal dolgozni. Egy konkrét használhatatlan szemétdomb az egész.
Ja hogy az sok pénz, hát ez van 
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
- Assassin's Creed Shadows Collector's Edition PC
- Eredeti Microsoft termékek - MEGA Akciók! Windows, Office Pro Plus, Project Pro, Visio Pro stb.
- Sea of Thieves Premium Edition és Egyéb Játékkulcsok.
- Windows 10 11 Pro Office 19 21 Pro Plus Retail kulcs 1 PC Mac AKCIÓ! Automatikus 0-24
- Adobe Előfizetések - Adobe Creative Cloud All Apps - 12 Hónap - NYÁRI AKCIÓ!
- Csere-Beszámítás! Olcsó Számítógép PC Akár játékra! Intel X5650 / GTX 1650 / 24GB / 240SSD+ 500HDD
- LG 45GS95QE - 45" Ívelt OLED / 2K WQHD / 240Hz 0.03ms / NVIDIA G-Sync / FreeSync Premium / HDMI 2.1
- Bomba ár! Lenovo ThinkPad P50 - i7-HQ I 16GB I 256SSD I Nvidia I 15,6" FHD I Cam I W10 I Gari!
- AKCIÓ! Apple iPad Pro 11 2024 1TB WiFi + Cellular tablet garanciával hibátlan működéssel
- ÁRGARANCIA!Épített KomPhone Ryzen 7 7700X 32/64GB RAM RTX 5070 GAMER PC termékbeszámítással
Állásajánlatok
Cég: Promenade Publishing House Kft.
Város: Budapest
Cég: PCMENTOR SZERVIZ KFT.
Város: Budapest