Hirdetés
- One mobilszolgáltatások
- Apple iPhone Air - almacsutka
- Yettel topik
- Fotók, videók mobillal
- Tényleg háromra szűkül a Xiaomi 17 Ultra kameráinak száma
- Nem lesz olcsó a Realme GT 8 Pro Európában
- Xiaomi 13T és 13T Pro - nincs tétlenkedés
- Bemutatkozott a Poco X7 és X7 Pro
- Fele annyit ér az iPhone Air, mint amennyibe pár hete került
- Android szakmai 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
-
bocs, hogy offolok, de a szaktopic halott.
debian, linux, latex.egy olyan számot kellene kiírnom a dokumentum elején, ami a kiírás idején nem ismert, csak később lesz az. a problémát és a megoldást is pont úgy képzeltem el, mint a \lastpage, a page x of y típusú lapszámozásból.
a gond az, hogy a weben látott megoldásokkal nem tudom írni az .aux fájlt. valakinek van működő ötlete erre?
-
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.
-
válasz
inf3rno
#29436
üzenetére
matlogból gyengén állóknak:
A állítás: valami szabványos
B állítás: valami szépen formázotteredeti állítás: az A and B halmaz eleme a json. ezt sugallja a mondat.
szerintem a json nem eleme B, tehát nem szépen formázott.
vagyis amit írtam, nem úgy kell értelmezni, mint ahogy te tetted (helytelenül), hogyha valami nem (A and B), akkor abból következik, hogy nem A, hanem úgy kell értelmezni, hogyha valami nem(A and B), akkor vagy (nem A) vagy (nem B). és itt most konkrétan nem B. -
válasz
inf3rno
#29416
üzenetére
mondtam én, hogy nem szabványos formátum? hint: nem mondtam.
(#29418) inf3rno : "Aztán próbálj emlékezni, hogy melyik fogalomhoz melyik rövidítés tartozik, főleg ha magyarul jegyzed meg, hogy melyik mit csinál. Kb. olyan, mint szótárat magolni. ": merugye java-s szabvány nevek rövidítéseit mennyivel egyszerűbb bemagolni... -
válasz
samujózsi
#29400
üzenetére
ha általános csv parsert írsz, akkor fel kell rá készülni, hogy a csv, amit beletolsz, nem felel meg a szabványnak.
ha te írtad meg azt a programot is, ami a csv-t generálja, akkor meg nem. (egyébként ha a csv mezőiben soremelés van, akkor egy rekord=több sor...)egyébként poén szinten el lehet fogadni, hogy szerencsétlen a csv, mert a neve szerint vesszővel elválasztott mezők a valóságban leggyakrabban semicolon-nal elválasztottak.
-
válasz
samujózsi
#29395
üzenetére
"írj korrekt csv parsert shellben! (+1: minek, ha van készen más script nyelven?": azt felejtetted ki a történetből, hogy olyan csv parsert kell írnod, ami az általad generált, nem általános csv-t képes parsolni.
vagyis ha a parsered nem tudja parsolni a csv-det, akkor saját magadban kell keresned a hibát.
-
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.
-
válasz
samujózsi
#29382
üzenetére
"Te egyszerűen gyülölöd valamiért.": igen, ez így van.
azért, mert azt látom, hogy egy csomó kód "overengineered", túl van tervezve, és ahelyett, hogy hatékonyan, tömören megcsinálták volna, "szépen" csinálták meg.egyszer régen egy korábbi munkámban monitoring adatokat kellett gyűjtenem egy appból, és a tisztelt fejlesztővel hetekig veszekedtem, hogy azt az adatot, amit egyszerű, egysoros, csv jellegű formátumban ki tud adni, ne json-ben meg xml-ben adja már ki, mert azt sokkal nagyobb meló parsolni.
de jártam már úgy is, még a múlt évezredben, hogy egy internet szolgáltató rendszerét megtervezték úgy, ahogy a cisco elképzelte (ami nyilván minél több dobozt akart eladni). lett belőle egy akkora architektúra, hogy a2-es lapra fért csak ki nyomtatva. azt megkaptam, kiröhögtem, utána megcsináltam ugyanazt shellben, összesen kevesebb, mint két képernyőnyi shell kóddal meg ötvenedannyi programmal.
ja nem. nem csak a múlt évezredben jártam így, hanem a mostaniban is...
de szerintem ha ebből flame-t akarunk csinálni, akkor élesszük fel egy korábbi posztom topicját és ott: [link]
-
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.
-
válasz
I02S3F
#29375
üzenetére
az egyetlen programozási nyelv, amiről nagyjából biztos lehetsz, hogy minden unixon és unix származékon van, az a shell. ha megtanulod a bash-t annyira, hogy azt is tudd, mi az, amiben elferdül az alap szabvány shelltől, akkor minden rendszeren fogsz tudni programozni vele.
ugyanez nem igaz se a pythonra, se a perlre, se a hasonló programnyelv-tervezési bűncselekményekre.
-
válasz
Dißnäëß
#29308
üzenetére
a debian telepítője alapértelmezetten tud bootolni titkosított partícióról. minek ehhez usb?
a másik kérdés: ha egy alkalmazás nem támogatja a ha clustert, akkor azt nemigen fogod átteni ha clusterre. olyat, hogy egy san partíciót két helyre mountolj írhatóan, cluster fájlrendszerek tudnak, ha jól emlékszem az ocfs és a gfs ilyen.
inkább azt csináld meg, hogy írsz egy egyszerű programot, ami egy master könyvtárból szétmásolja több alkönyvtárba a fájlokat és ezekre ereszted rá a feldolgozó programokat.
vagy ha nem tudod kikerülni a folyosón a jáva architektedet, akkor az azt fogja mondani, hogy csinálj message queue service-t.
teljesítmény bővítésre mindig a legegyszerűbben járható út először a több ram, utána a nagyobb vas.
-
válasz
samujózsi
#29205
üzenetére
"Azért az érzed, hogy itt átlaguserről van szó, nem hobbista kernelfejlesztőről?": de itt az alapeszméről van szó.
nem mondtam, hogy hatékonyan fog belenyúlni, nem mondtam, hogy sikeres lesz, azt mondtam, hogy hagyni kell.az opensource és a linux alapeszméje, hogy mindenki buherálhatja. ezt az alapeszmét szerintem helytelen lenne megölni.
az egy másik tészta, hogy a hivatalos kernelbe mi hogyan kerül bele és az is, hogy a júzer saját energiáit vagy másokét hogyan pazarolja. ha be akar menni bekötött szemmel az erdőbe, hagyni kell, hagy menjen. ha koppan, koppan, ez téged ne zavarjon. de lehet, hogy felfedezünk egy új mingót.
-
válasz
samujózsi
#29199
üzenetére
"És sokadszor: átlag felhasználó ne akarjon kernel dumpot fejteni.": miért? azok, akik most kernelt fejlesztenek, átlag felhasználóként kezdték és nulláról tanulták meg azt, a dump olvasást is.
a linux egy szabad világ, ne akarjuk előírni senkinek, hogy mit csináljon. azt mondhatod, hogy te nem tudsz átlag felhasználónak dump olvasásban segíteni. ha más tud, vagy megtanulja önállóan, akkor mindenki boldog.
-
"Ez teljesen megoldhatatlan. A kernel nem valami 10 ezer soros sufni program.": ha meg tudod számolni, hogy hány sorból áll a kernel, akkor megoldható.
"Az end-user beleértve a rendszer gazdit is inkább ne nyúlkáljon kernel kódba pls.": miért ne? azért opensource, hogy bárki belebabrálhasson.
-
válasz
kraftxld
#28810
üzenetére
nincs jobb ötletem, mint az, hogy meg kell találni azt a pontot, ahova a drbd-t be lehet szúrni.
persze kérdés, hogy a sas miben tárolja az adatokat. tehát az a valódi kérdés, hogy blokkos eszközt kell replikálni, vagy esetleg az, hogy adatbázist kell?
a másik lehetőség, hogy aki felvette érte a zsetont, az befárad és megoldja
-
válasz
kraftxld
#28808
üzenetére
nincs jobb ötletem, mint a 8 pár guest között drbd-vel replikálni.
persze jobb lenne a vmware blokkos eszközeit replikálni drbd-vel, de ha az nem megy, akkor marad a guest.vagy ha sokat akarsz dolgozni, akkor kuka az egész és újracsinálni xen vagy kvm alatt
az alá simán be lehet tolni a drbd-t. esetleg belegondolni, hogy tényleg kell-e gfs2, nem jó-e helyette nfs.szerk: annak van valami előnye, hogy egy vason 8 virtualizált gépen futtatsz egy sas clustert, ahelyett, hogy egy natív vason futtatnál egy sas-t?
-
"Ha minden normálisan működik és rendesen van megírva a service fájl": ezt nem vitatom, csak ha összeveted azzal, amit a vita elején írtam, akkor kiderül, hogy ez egy üres állítás.
te azt támasztod feltételnek, hogyha minden normálisan működik, én meg azt írtam, hogy a systemd jelentős része nem működik. következmény: a feltétel utáni rész sosem valósul meg.
-
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.
-
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.
-
válasz
inf3rno
#28773
üzenetére
"az a benyomásom, hogy túl keveset tud": érted már, hogy miért JÓ?
"Mármint az jött le, hogy annyit csinál összesen, hogy elindít egy bash scriptet bootoláskor, amit megadsz neki, aztán kalap.": ennél azért többet csinál, nem ártana ismerni, mielőtt azt hiszed, hogy arra a feladatra a systemd jobb.
-
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. -
debianon és solarison is ugyanúgy működött, tehát van két "disztró", akkor már szabványos?
ha az init maga szabványos, de nem korrekten implementálják, akkor az az init hibája vagy az implementációé?szerinted jó a systemd, szerintem egy nagy vödör csavar. hogy ne tartson ez a vita túl sokáig, azt is megígérem neked, hogyha külső segítségre lesz szükségem hardverfejlesztési stratégia kialakításához, te leszel az első, akit meg fogok keresni.
és azt az állításomat is fenntartom, hogyha szerinted a systemd magas százalékban le van fedve tesztekkel, akkor a tesztek se érnek többet egy vödör csavarnál. a systemd használata egy rakás elpazarolt munkával jár és ez engem bosszant.
-
válasz
inf3rno
#28768
üzenetére
de mennyi felesleges munkát és kárt fog okozni pöcstering, mire végre felfogja a többség, hogy el kell zavarni, és mennyi meló lesz majd egy elcseszett systemd-ből migrálni egy másik rendszerbe megint?
Ráadásul ha mindent magába olvaszt, akkor az nem egy linux kerneles unix lesz, hanem egy linux kerneles windows.
"mert jobb, ha egy külön service manager felel a szolgáltatások futtatásáért": volt service manager, úgy hívták: init.
"Mondjuk, mint már előzőleg írtam, azért ráférne a szabványosítás mielőtt ténylegesen kódot írunk rá": tényleg mondtad, pedig nem kellene, mert téves. az init eléggé szabványos volt. szabványosítás igényével lecserélni egy egységes, szabványosnak tekinthető rendszert egy egyedire, tévedés.
-
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.
-
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.
-
"A klasszik BSD style init lényegében egy shell scriptet indít, esetleg több shell scriptet, rohadtul nem a stabilitás mintaképe.": értem, tehát az egy darab, ezer éve használt, debuggolt init shell szkript az instabil, a rakás systemd szkript meg stabil.
kizártnak tartom, hogy magamévá tegyek egy ilyen véleményt systemd-től függetlenül.
"Fejlesztői szemmel a systemd egy értelmezhető, modern, tesztekkel lefedett kód": ez csak annyit jelent, hogy a teszteset írók munkája se ér egy vödör csavart se.
"service fájlt írni elég egyszerű.": és működő service fájlt?
"a sysvinit buta, mint a franc": aki ért hozzá, az ezt a tényt pozitívumként kezeli, nem hátrányként. érdekes módon én mindent meg tudtam oldani vele triviálisan.
"A gcc talán a legkomolyabb compiler jelenleg": melyik gcc? és miért nem az intel c fordítója a legkomolyabb?
-
"A systemd amúgy az OS X initjére hasonlít erősen, nem a windowsra.": én nem arról beszéltem, hogy a szolgáltatásai mire hasonlítanak, hanem arról, hogy milyen szemlélettel programozták le. Ez a nagy bloatware egybe-minden-vackot szemlélet ez windows. Ez az állítás nem zárja ki, hogy beleértsd, hogy akkor az osx-et is lewindowsoztam.
"Amúgy érdekes, hogy a deb alapú csodák használói vinnyognak folyamatosan a systemd-re.": mert a deb alapú csodák tökéletesen működtek külsőleg oktrojált szemét nélkül is. Semmi szükség nem volt rá, hogy az rpm kitalálójának alkalmazottja szétcsessze a deb alapú csodákat is. Egyébként pöcstering már kifejtette, hogy a csomag rendszert is meg akarja reformálni meg a home könyvtárakat is. Csak azt nem értem, miért nem tette még helyre senki. Ha osx-et meg windowst akar csinálni a debianból, tegye meg otthon magának. Az én rendszereimet meg hagyja békén, mert az én fizetésem függ tőlük és ezért harapok.
"A pulseaudio funkciója feltétlen szükséges a rendszerbe a normális működéshez": nem, nem szükséges. De hagy emeljem már ki a korábbi állításomat ismét: sokkal könnyebben elfogadnák az emberek pöcstering lomjait, ha azok nem lennének tele hibával. És könnyebb lenne elfogadni pöcsteringet, ha amikor egy hibára reagál, a válasza nem tűnne totál elmebetegnek.
"Az ALSA magában nem elég több programos használathoz": minek kellene több programból használni a hangrendszert??? Az olyan lenne, mint amikor egy társaságba kerülsz több nővel, és egyszerre pofáznak mindenféléről. Az ember füle nincs felkészítve arra, hogy több, különböző audio streamet értelmezzen.
"A BSD init amúgy egy mindennél rosszabb szkript gányolás, komplex rendszerek készítésére alkalmatlan.": merugye a systemd az nem egy szkript gányolás...
-
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?
-
válasz
inf3rno
#28725
üzenetére
a deuvan például összekeveri az ethernet interfészeket telepítés után. én nem tudok olyan disztróval dolgozni, ami telepítés után nem érhető el, mert a másik ethernet lett az eth0.
a systemd-ről meg annyit, hogy nem valós problémákat talál fel. tehát például lehetne probléma, hogy mennyi idő alatt bootol egy linux. csak ki a bánatos francot érdekli, hogy 10 másodperc vagy 4, amikor egy csomó ibm szerveren a raid vezérlő kernele 300 másodpercig bootol. Ha systemd-vel 307 másodperc alatt bootol be a debian, svr4 inittel meg 312. és akkor mi van? miközben ritkábban, mint évente egyszer kell bootolni.
ezzel szemben meg ha nem teljesen abban a sorrendben stackeled össze a raidet, az lvm-et meg a drbd-t, ahogy az ostobenkó elképzelte, akkor fél éves sz.pás kideríteni, hogy te írtad rosszul a mount unitot vagy a köcsög szkriptjei nem működnek (hint: utóbbi). Ezt a fél évet ki fogja kifizetni?
-
a systemd-ben levő cuccok jelentős százaléka nem működik.
megismétlem: NEM MŰKÖDIK. az svr4 init töredékét se tudta annak, amit a systemd, de azt mindig megcsinálta jól.a másik probléma, hogy a unix attól lett unix és sikeres, hogy kis, egyszerű építőelemekből van összerakva. van másik irányzat, azt windowsnak hívják. windowsos szemlélettel unixot programozni alapvető tévedés, mintha egy vegán arról kezdene vitatkozni, hogy a bélszínt mennyire átsütve szereti.
a harmadik probléma, hogy egy közösség által összelapátolt rendszerben egy őrültnek ekkora hatalmat adni a kezébe pocsék ötlet. különös tekintettel arra, hogy pöcstering nem először próbálkozott és bukott meg a hülyeségével, lásd pulse audio.
a negyedik probléma, hogy senkinek nincs joga ekkora pénzkidobásra kényszeríteni senkit, amennyibe a systemd megtanulására fordítandó erőforrás kerül, különös tekintettel arra, hogy egyébként a systemd nemlétező problémákra ad (rossz) megoldást.
tehát a 2-4 problémák akkor is a systemd ellen szólnának, ha egyébként az rendesen működik. de mivel ettől a rendes működéstől igen messze vagyunk, az, hogy a systemd megvalósítása egy rakás sz.r, übereli az összes többi problémát.
további probléma még, hogy például akik devuant fejlesztenek, fejleszthetnének debiant is, ha nem ette volna bele a fene a systemd-t a debianba. azzal, hogy systemd-s lett a debian, pazarlódik a munkaerő és lassul a fejlesztése. így eljutottunk odáig, hogy akik eddig debianra alapozták az életüket, azoknak most jelenleg nincs működő oprendszer választási lehetőségük.
-
-
szerintem félreértetted, amit írtam.
annyi minden szól a felhő ellen, hogy ezek korrekt megoldása önmagában tönkre teheti a költségvetést.emvy: én meg biztos vagyok benne, hogy a nagy szolgáltatói felhő összességében többe kerül. vagy úgy jár legjobban, ha mindent megcsinál maga itthon, vagy úgy, ha a saját méretosztályára szakosodott szakértővel megcsináltat mindent (tanyacsenöl rulez).
-
válasz
CPT.Pirk
#28584
üzenetére
a levelezés elsősorban attól függ, hogy milyen internet kapcsolatotok van. fix ip nélkül kicsit macerás levelezni.
skype for businness pótlékot nem ismerek, helyette voip-t tudok elképzelni. a szervert is illik backupolni, tehát arra is gondolni kellene.kérdés még, hogy azt a bizonyos tervezőprogramot a munkaidejük mekkora részében használják, mert ha csak ritkán, akkor lehet terminálszerverre felpakolni.
csoportmunkára sokan használnak zimbra-t.
-
válasz
Dißnäëß
#28578
üzenetére
igen, teljesen beteg dolog, hogy ezt raid5-tel akarod megcsinálni
azt kellene eldöntened, hogy pontosan mit is akarsz. ha azt akarod, hogy legyen egy realtime másolatod, ami titkosítva van, arra nem ez a megoldás, hanem a crypto blokk device. ha azt akarod, hogy legyen másolatod, arra a korábban említett network blokk device nem alkalmas, mert teljesen döglött és nem vagy nem jól fejlesztett technológia.
ha azt akarod, hogy legyen egy gyors, redundáns, titkosított cuccod, akkor egymásra pakolsz 1-több drbd-t, arra crypto-t majd arra raid1-et. készülj fel rá lélekben, hogy ha systemd alapú oprendszered van, nagyon hosszasan, harsányan és cifrán fogod pöcstering anyját emlegetni. én 4 hónapig tettem
-
válasz
#68216320
#28473
üzenetére
1. szerintem lesz elég bajod a cuccal, totálisan felesleges még egy dockerrel is bonyolítani az életedet.
2. ha van fent lamp, akkor valóban igaz, hogyha felraknád az nginx-et is, akkor összeakadnának, de minek raknád fel, ha van fent apacs. azt a feladatot, amit az nginx-re bíznak, megoldja az apacs is. -
szerintem elsősorban arra figyelj oda, hogy hagyd békén a kernelt. annak az esélye, hogy itt kérdezned kell, és ezek után jobban beállítod a kernelt, mint a komplett linux közösség esze alapján gyárilag megvan, nulla. nem tudom, mit értesz jiffy/HZ alatt, de azt se piszkálnám.
a nagyobb szolgáltatók 40-100 gigabit/sec közötti forgalmat képesek generálni egy kernellel. tehát ha 100 gigánál lassabb a hálózatod, akkor nem a kernel lesz a szűk keresztmetszet.
másrészt ha ennyire aggódsz a tcp kapcsolatok miatt, miért nem használsz udp-t?
-
válasz
#68216320
#28364
üzenetére
"Irigyellek, hogy egy olyan 4TB-os HDD-t, aminél még csak gyenge szektor van nem pedig bad-block, te csak úgy kihajítasz.": ezek a diszkek maguk menedzselik a hibás szektorokat. amikor ez már kívülről is látszik, az azt is jelentheti, hogy elfogyott a menedzselésre fenntartott hely. tehát a diszk erősen halad az elromlás felé.
engem nem zavar, ha a hsz-emet mellőzöd, téged fog zavarni, ha az adataidat is?
-
válasz
#68216320
#28357
üzenetére
oké, akkor a részletek:
ha raid1 tömbbe teszed a partíciót, akkor az elejére odateszi az md superblockot. majd csak utána tudod rátenni az ext4fs első szektorát.
tehát ha raidben volt a partíció, akkor csak úgy tudod megnézni, hogy van-e rajta fájlrendszer, hogy csinálsz egy ideiglenes raid kötetet és belerakod (vagy tudod, hogy a mountot hogy kell paraméterezni elcsúsztatott szektoros mounthoz).vagyis normálisan nincs látható fájlrendszer a raidből kihullott partíción. hasonló módon értelmetlen fájlrendszert kreálni, mielőtt visszarakod a kötetbe.
ezt azért érdemes tudni, mert elfeded a valódi problémát, így azt nem javítod meg, vagyis lélekben készülj fel rá, hogy megint szét fog hullani a kötet.
-
-
válasz
kezdosql
#28335
üzenetére
"Linux alatt napi frissites tonkretette a firefoxot, ahogy webre csatlakozik azonnal merevre fagy a linux": be tudsz rá jelentkezni hálózaton?
szerk: ha mostanában jött elő, hogy "megfagy" a linuxod firefoxtól, akkor lehet, hogy egy videokártya tisztítás segít rajta. lehet, hogy nem megfagy, hanem megfő.
-
válasz
radi8tor
#28307
üzenetére
az interfaces fájlban található dolgokat a hálózat indulásakor állítja be a kernelben.
tehát ha sem reboot nem volt, sem kézzel nem gyalultad ki a régi konfigot, akkor a kernelben benne van.ha bcp-zni akarsz, akkor egyszerűen másold le egy backup könyvtárba a konfigot módosítás előtt.
-
válasz
Fecogame
#28282
üzenetére
az alapkérdés az, hogy hol legyen a vezérlőterminál.
ha azt csinálod, hogyssh user@gep 'command' &, akkor az ssh klienst futtató gépen van a vezérlő terminál, vagyis a kliens gépnek működnie kell, az ssh parancsot futtatnia kell mindaddig, amíg a távoli gépen le nem fut a parancs.ha pedig azt csinálod, hogy
ssh user@gep 'nohup command &', akkor az ssh kapcsolat lebomolhat a parancs elindításakor és nem kell megvárni a kliens gépen, hogy lefusson a távoli gépen a parancs. -
válasz
dzoli87
#28274
üzenetére
a gond az, hogyha veszel egyszerre négy diszket, egy szállítmányból, egy gyártásból, akkor nem őrültség feltételezni, hogy egyszerre fognak tönkremenni. ha fontos az adat, akkor meg lehet fontolni a raid5-öt, de ahogy a kolléga is javasolta, nem egyforma diszkekből. a raid10 talán jobb lehet, vagy a raid1+0, mert az akár két diszk kiesését is eltűri.
de ha fontos az adat, akkor inkább backup.
-
oké, de az nfs reexport azt jelenti, hogy:
forrás nfs szerver --- nfs protokoll ---> köztesnfs szerver --- nfs protokoll ---> végső kliens
ehelyett lehetne:
forrás nfs szerver --- nfs protokoll ---> végső kliens
ha ez nem működik, akkor azt tudod csinálni, hogy legyen a forrásból leszedett adat helyi. például blokkos eszközként rakd fel a forrást a host nfs szerver alá. vagy pedig először rsync-celj a forrásról a host gépre, és onnan nfs.
-
azt, hogy smb fájlrendszert tovább lehet-e osztani nfs-en, még nem próbáltam.
azt viszont, hogy nfs fájlrendszer nem lehet továbbosztani nfs-en, az nfs szabvány is tartalmazza.
értelmetlen ötlet, ha egyik gépre fel tudod venni az nfs-t, akkor azon is, ahova egyébként továbbosztanád.
Új hozzászólás Aktív témák
- Eredeti Microsoft termékek - MEGA Akciók! Windows, Office Pro Plus, Project Pro, Visio Pro stb.
- Bitdefender Total Security 3év/3eszköz! - Tökéletes védelem, Most Ünnepi áron! :)
- Kaspersky, BitDefender, Avast és egyéb vírusírtó licencek a legolcsóbban, egyenesen a gyártóktól!
- ::::: HATALMAS LEÁRAZÁSOK! I JOGTISZTA MICROSOFT TERMÉKEK I 27%-OS ÁFÁS SZÁMLA I 10 ÉV GARANCIA ::::
- Vírusirtó, Antivirus, VPN kulcsok GARANCIÁVAL!
- GYÖNYÖRŰ iPhone 14 Pro 128GB Space Black-1 ÉV GARANCIA - Kártyafüggetlen, MS3781, 100% Akkumulátor
- Bomba ár! HP EliteBook 840 G7 - i5-10G I 16GB I 256GB SSD I HDMI I 14" FHD Touch I Cam I W11 I Gari!
- ÁRGARANCIA!Épített KomPhone Ryzen 7 9700X 32/64GB RAM RX 9070 16GB GAMER PC termékbeszámítással
- 130 - 131 - Lenovo Legion Pro 7 (16IRX9H) - Intel Core i9-14900HX, RTX 4080
- Telefon felvásárlás!! iPhone 14/iPhone 14 Plus/iPhone 14 Pro/iPhone 14 Pro Max
Állásajánlatok
Cég: ATW Internet Kft.
Város: Budapest
Cég: BroadBit Hungary Kft.
Város: Budakeszi