-
Fototrend
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
-
bambano
titán
válasz
Vasti74
#34752
üzenetére
Először is abból a puszta tényből, hogy megkérdezted, még nem következik, hogy az itteni fórumtagok tudják rá a választ. Másodszor az sem következik, hogy egyáltalán létezik rá válasz.
Eleve, amennyire én tudom, a hűtést *NEM SZOFTVER* vezérli. A hűtést egy mikrokontroller szerűség vezérli, a kontroller jelleggörbéjét lehet szoftverből állítani. Gyakorlatilag egy függvény, ami hőmérséklethez fordulatszámot rendel, és kb. ennek a meredekségét tudod állítani. Gyakorlatilag azt tudod állítani, hogy milyen proci hőfoknál kezdjen hűteni, és mennyire drasztikusan emelje a venti fordulatszámát, ha melegszik a proci. Ezzel be lehet állítani egyfajta egyensúlyi pontot, ahol a terhelés függvényében pörög a venti. De van még két marék paraméter hozzá.
Az egésznek mégiscsak az az alapja, hogyha melegszik a proci, növeli a vélt hűtési teljesítményt. Ha ettől nem hűl le a proci, akkor még növeli, ciklus vége. Tehát vagy le tudja hűteni, vagy feljebb pörgeti. Ezért hiába is erőlködsz, a terhelés alatti zajt érdemben nem tudod befolyásolni, max azt, hogy mikor kezdjen leszabályozni a proci.
Én ezért mondtam, hogy hagyd a fenébe, nem lehet vele mit kezdeni. Csak azt lehet vele kezdeni, hogy megoldod, hogy kevesebb hőt termeljen a proc. Vagy hardvert cserélsz.
Attól a kérdésed még helytelen marad, hogy linuxos fórumban tetted fel, ezt felesleges ezen a topicon és a topiclakókon leverni.
-
bambano
titán
válasz
Vasti74
#34745
üzenetére
A pwm-es ventilátorban két drót (+ test + fordulatszám ellenőrzés) megy a ventilátorba. Ha csökkented a feszültséget, akkor emiatt fizikailag két lehetőséged van:
1. a pwm vezérlés feszültségét csökkented, akkor egy darabig semmi nem fog történni, majd az egész vezérlés összeomlik.
2. a venti tápot csökkented, akkor a pwm feljebb fogja húzni a fordulatszámot.szerk: úgy tudod a pwm-es ventilátor fordulatszámát csökkenteni, ha képes rá, hogy átkapcsold feszültségvezérelt módba és ott csökkented a feszültséget.
a másik megoldás, hogy csökkented a proci terhelését és akkor nem kell majd annyi hűtés
-
#34720
bambano
titán
lionhearted
#34719
bambano
titán
válasz
lionhearted
#34719
üzenetére
Nem foglalkoztam azzal, hogy a te megoldásod, amelyet teljesen más problémára adtál, mint amit én kérdeztem, működik-e vagy sem. Indifferens.
"Ne harcolj olyan démonnal, ami nincs.": nincs systemd?![;]](//cdn.rios.hu/dl/s/v1.gif)
-
#34718
bambano
titán
lionhearted
#34717
bambano
titán
válasz
lionhearted
#34717
üzenetére
A drbd nem internetről jön, hanem helyi hálózatról. Az, hogy van-e hálózat, nagyon egyszerű: ha elindult a drbd, akkor van, ha nem indult el, akkor nincs.
-
#34716
bambano
titán
lionhearted
#34715
bambano
titán
válasz
lionhearted
#34715
üzenetére
jéééézus...
tehát ha nincs internetem, csak helyi háló, akkor ez el se indul?
tuttkó megoldás, megdöglött a routerem, de az a gép is, amiről a routert életre pofozhatnám.szerk: szerintem jelentkezhetnél systemd fejlesztőnek
-
#34713
bambano
titán
lionhearted
#34712
bambano
titán
válasz
lionhearted
#34712
üzenetére
Ha beállítod a drbd unitjait, akkor a systemd elindítja. A gond az, hogy a systemd megállmodói szerint van egy logikai sorrend, ahogy össze kell rakni egy gépet, és ha ezt a logikai sorrendet te felrúgod, akkor felborul a systemd is.
Akik megálmodták a debiant, azok azt gondolják, hogy úgy kell működnie, hogy vannak a blokkos eszközeid (tipikusan hdd, sdd), arra húzol raid-et. A raidre lvm-et (esetleg cryptot), az lvm köteteket pedig mountolod. Az oprendszer többi része meg ettől függetlenül ahogy a proci bírja lóerővel, indul vagy sem.
Namost ebben az esetben a drbd-nek előbb kell elindulnia, mint ahogy minden mount lefut, mert mountolni kell. A lightdm-nek meg kell várnia azt, hogy a drbd-re rakott home dirt felmountold, mert az X-nek kell a home, ahol tárolva vannak a grafikus beállítások. Szóval bele kell nyúlni a szokásos boot folyamatba, hogy előbb álljon fel a hálózat, mert a drbd-nek kell, utána teremtődjön meg a home blokkos eszköze, mountolódjon, és utána mehet a lightdm.
-
#34711
bambano
titán
lionhearted
#34710
bambano
titán
válasz
lionhearted
#34710
üzenetére
"A mount unit egyetlen kínja, hogy a fájl neve nem választható": emlékeim szerint ez benne volt valamelyik kottában.
Gondolom azt nem kell külön specifikálni, hogyha mountolni akarsz egy blokkos eszközt, akkor a blokkos eszköznek léteznie kell. -
bambano
titán
"kis ceg vagyunk": vagyis a te szükségleted az általános az összes debian usernél?
"ez relevans lenne, ha pl. merevlemezre irjatok az adatokat bitrol bitre": mindig lemezre írod az adatot, az ssd is solid state DRIVE.A logod nem csak kifejezetten lemezhiba miatt borulhat össze, hanem más hiba miatt is.
Az az orbitális nagy vicc, hogy pont ma délután futottam bele egy memória hibába, ami simán összeborogathatott volna bármilyen bináris adatállományt, miközben egy text log részben menthető maradt volna.
-
bambano
titán
válasz
urandom0
#34706
üzenetére
"Mivel én nem használok DRBD-t": nem te mondtad, hogy annyi az egész, hogy csinálunk egy unitot és akkor működik?
Nem kell tudod, hogy mi az a drbd, nem kell tudnod, hogy hogyan konfigurálódik be maga a drbd, elég, ha azt tudod, hogy systemctl enable drbd.unit (most nem írom a betű szerint pontos parancsot) elindítja.Ezek után azt kell tudnod, hogyan csinálj egy olyan működő mount unitot, ami egy blokkos eszközt megadott csatolási pontra felmountol.
Utána azt kell tudnod, hogy hogyan szinkronizálod össze azt, hogy a drbd unit csak a hálózat éledése után induljon, és a unit, ami a lightdm-et indítja, megvárja, hogy ez a specifikus mount unit lefusson.
Ezt így kell csinálni a systemd-ben.
CSAK NEM MŰKÖDIK!
Akármennyi doksit olvastam, gugliztam, NEM MŰKÖDIK!
Ami erről a systemd doksijában van, az NEM IGAZ.
NAGYON SOK napot elcsesztem erre, gugliztam, rebootoltam ezerszer ÉS NEM MŰKÖDIK.Tessék, itt van előtted a pálya, bizonyítsd be, hogy én vagyok a hülye. Ja, és ez az első forduló, ha megoldottad és nekem is működik, akkor jön a következő feladat
Meg kellene kis magyarázatocska, hogy a szerteszéjjel össze-vissza linkelt unitok (a wants meg a provides meg a társai) mitől egyszerűbbek, mint két sor az rc.local-ba.
Érdekelne az is, hogy erre csinálok egy mount unitot, az nem működik, csinálok egy exec unitot, amiben egy darab mount parancs van, az működik.
Mellesleg abba az rc.local-ba, amire külön systemd unitot kell engedélyezni, hogy a systemd bootkor lefuttassa. sysv initben meg belinkeled a runcontrol szkripteket oszt jónapot.
-
bambano
titán
válasz
urandom0
#34697
üzenetére
"10 éve használok desktopon Linuxot": örülök, hogy fiatal pályakezdők is elkezdenek linuxozni
Ez egyébként valami isteni gondviselés lehet, mert nekem pont két órával ezelőtt szállt el egy gépem memória hiba miatt. Óriási csodának gondolom, hogy nem dőlt össze a komplett root fájlrendszer.
-
bambano
titán
válasz
urandom0
#34681
üzenetére
tehát neked kell egy összekonfigurált drbd meg egy komplett teszt rendszer, ahol egy ilyenre rá tudsz nézni, és megfelelő mennyiségű találgatás után esetleg lesz megoldás.
ha te kérdeznéd ugyanezt, hogy oldjam meg sysv inittel, én fejből megmondanám, hogy mit csinálj.
Hát EZ a nagy különbség.
-
bambano
titán
ha keresek valamit a logban, akkor systemd esetén journalctl-lel kilistáztatom és utána grep-pel vagy valamivel keresem, megnézem.
ha text a log, akkor a grep külön program nélkül saját maga is képes elvégezni a munkáját.erre jobb napjaimban azt mondanám, hogy fork bomba
szerk: másik hsz-edre: "Stimmel. És a journalctl nem elérhető neked, vagy mi vele a gond?" például ha egy php alkalmazásban logot kell olvasni (nekem van ilyenem), akkor text lognál simán megnyitom, beolvasom, átnézem. bináris lognál forkolni kell egy journalctl-t és úgy kell elolvasni.
szerk: egyébként egy lemezhiba esetén annak van nagyobb valószínűsége, hogy a bináris log olvasható marad, vagy annak, hogy a text?
-
bambano
titán
válasz
urandom0
#34670
üzenetére
jaja, logszerver... múltkor is kaszálnom kellett, mert logszerverek nőttek a réten és zavarták a kilátást.
De mondok neked egy relatíve egyszerű dolgot:
debian trixie, van egy bekonfigurált drbd-m. ezt fel kell moutolni a home-ba, és ha sikerült, akkor engedni, hogy elinduljon a lightdm.ez rc.localban pár sor. lássuk a te systemd-s megoldásodat. ez egy ilyen történet, amire én gondoltam, a csomagkarbantartók meg nem. de a második fordulóra van ennél jóval cifrább is.
-
bambano
titán
válasz
urandom0
#34662
üzenetére
Ha hibás a dns konfig, akkor hibásnak *KELL* lenni a hálózatnak, különben sosem derül ki, hogy hibás a konfig. Annak is célnak kell lenni, hogy kitakarítod a hibákat a rendszerből.
Az svr4 init is újraindít processzeket, ehhez csak az inittabba kell egy sor. Nem rakás unit file szerteszéjjel szórva a komplett fájlrendszerben.
Elhiszem, hogy a doksiban el tudtad olvasni, hogy tud dependelni. A valóságban nem működik rendesen.
A szöveges logokat is lehet szűrni grep-pel. Nem találjuk fel újra a kereket.
"biztos lehetek benne, hogy" a szolgáltatásod vagy elindul, vagy nem.
Azokat a beállításokat, amiket a journald-nek meg lehet adni, csak bináris naplózással lehet megadni? Van biztosíték arra, hogy azokat a bináris naplókat 10 év múlva is fogod tudni olvasni bármivel?
Azt akarom, hogy ha más a feladat, és svr4 initben pikk-pakk össze lehet rakni, akkor systemd-ben még kevesebb meló legyen összerakni, különben nincs okom váltani. Az, hogy amit svr4 initben 20 másodperc alatt egy darab vi-jal elintézek, azt systemd-nél három nap guglizás után se lehessen elintézni, az nonszensz.
-
bambano
titán
válasz
urandom0
#34659
üzenetére
"Ez jelen pillanatban úgy működik": és itt a hangsúly a jelen pillanaton van.
Szerintem ha rossz a dns konfig, akkor működjön rosszul (vagyis ne működjön). A hiba elmaszkolása azt okozhatja, hogy a hiba oka nem kerül kijavításra.
Egyébként ezt az egész systemd alapgondolatot nem értem. Azt mondják, akik szeretik, hogy azért is jó a systemd, mert menedzseli a processzeket, újraindítja, ha elszálltak, stb. De miért is száll el egy processz, amire fontos feladatokat akartak bízni? Ha egy processz elszáll, akkor nem az a megoldás, hogy körbepakoljuk mindenféle szeméttel, ami újraindítja (és maga is bughalmaz), hanem az, hogy kijavítjuk a programot és akkor nem fog elszállni.
Egyébként amíg out of the box használom a debiant, nekem sem szokott semmi bajom lenni, még a systemd-vel sem. De abban a pillanatban, ahogy valami mást akarok, mint a csomag-karbantartók, rögtön falakba ütközöm.
-
bambano
titán
-
bambano
titán
Például a google szerverein szinte biztosan nem oob linux disztró fut. Tehát pont ők azok, akiknek teljesen mindegy, hogy mi van az átlag desktop user linuxában.
Az ibm pc azért nyert, mert az ibm hagyta, hogy belepiszkáljanak a vasba. A linux azért nyert a mininx-szel szemben, mert Linus hagyta, hogy mások is hozzájáruljanak a kernelhez. A minix egy zárt rendszer, aminek elolvashatod a forrását. Mondjuk lehet, hogy lehetne párhuzamot vonni Pöttering és AST stílusa között... lol.
Mondjuk az egy érdekesebb vita lehetne, hogy a linux miért nyert a freebsd-vel szemben is...
-
bambano
titán
válasz
urandom0
#34644
üzenetére
Az első és legfontosabb probléma a systemd-vel, hogy Pöttering elvtárs sokszor és alaposan eljátszotta a bizalmat. Aki olyan baromságot csinál, hogy ha nemlétező user alatt kellene futtatni egy programot, akkor falbackkel rootra, és azóta sem látszik, hogy javult volna a hozzáállása, azt nem engedjük be komoly rendszerbe. Lásd még fallback google dns-re. És akkor még nem beszéltünk arról, hogy pulseaudio téren is futott már ámokot az elvtárs.
A második probléma, hogy a systemd nem működik. Amennyiben olyat szeretnél vele csinálni, ami nem az alap, akkor nem működik.
Harmadik, hogy a unix az sor alapú szöveges dolgokra van optimalizálva. Az, hogy a sima txt logokról áttért binárisra, az lehet egy jó választás, ha windowsod van, de unixon nem csinálunk ilyet.
Negyedik, hogy ki a franc ez a pöttering, hogy rákényszerít engem és másokat is olyan plusz munkára, ami nem térül meg soha? Az eredeti sysv init tudott mindent, amire valóban szükség van, ha kellett syslog, ntpd, felraktad, oszt jónapot. Abnormális kiadásokra kényszerít. És ne csak arra gondolj, hogy otthon van egy linuxod, amit néha bekapcsolsz két windowsos játék között, hanem arra is, hogy vannak, akik linux üzemeltetésből keresik a kenyerüket.
Mondjuk Pöttering pont annál a redhat-nél dolgozott sokáig, akik hamisítottak már gcc-t is, mit csodálkozunk. Azóta meg összenőtt, ami összetartozik.
Tőle függetlenül én azt egy beteges dolognak gondolom, hogy egyes programozók akkor is programoznak, amikor nincs mit értelmesen programozni. Tölthetnék hibakereséssel is az idejüket, csak az büdös.
KISS: Keep it stupid and simple. Ami nem ilyen, az nem unix. Csináljon csilivili processz managementet windowsra, az oda való, minket (pláne a mi munkaeszközeinket) meg hagyjon békén.
-
#34503
bambano
titán
lionhearted
#34491
bambano
titán
válasz
lionhearted
#34491
üzenetére
"Én azt nem értem, hogy ha a linux egy nyílt környezet, akkor hogy van az, hogy adott dolog egy másik disztróban adatik csak meg.": mert nyílt környezet. Mindenki azt farag belőle, amit akar, nincs központi utasítás.
-
#34426
bambano
titán
lionhearted
#34425
bambano
titán
válasz
lionhearted
#34425
üzenetére
-
#34423
bambano
titán
fatpingvin
#34422
bambano
titán
válasz
fatpingvin
#34422
üzenetére
nem.
bele akarok rakni a pdf-be, mint konténerformátumba, egy xml fájlt IS.
mint pl. az elektronikus számla. generálsz egy pdf-et, amiben benne van a számlakép, amit nyomtatsz, ha szükséges. plusz legenerálod az online számlarendszer szabályai szerint a számlát xml-ben, és azt is belerakod a pdf-be.másképp fogalmazva: a zip vagy a tar az egy konténer formátum. zip-be (tar-ba) bele tudsz csomagolni több fájlt. tudomásom szerint a pdf is ilyen, belerakod a dokumentumodat, és rakhatsz mellé más fájlt is.
ezt hogy linuxon, cli-ben?
-
-
#34353
bambano
titán
Roland861010
#34347
bambano
titán
válasz
Roland861010
#34347
üzenetére
ebben a hsz-ben nincs kérdés.
milyen választ szeretnél? -
#34288
bambano
titán
Speeedfire
#34287
bambano
titán
válasz
Speeedfire
#34287
üzenetére
iotop?
a magas load jelentheti azt, hogy sok processz vár io-ra.szerk: elvileg nem kellene raid-et szinkronizálnia, de ne zárjuk ki.
-
bambano
titán
válasz
CPT.Pirk
#34281
üzenetére
valójában nem teljesen nagyobb írási sebességről szól a történet, hanem konstans késleltetésről. ezt úgy éri el, hogy kevésbé foglalkozik az írási hibákkal, ettől lesz kicsivel gyorsabb. a kamerarendszereknél kevésbé fontos, hogy egy-egy kép részlete megőrződjön, sokkal fontosabb, hogy hiba esetén a többi kép rögzítésre kerüljön.
igaza van ubyegon2-nek, az a diszk csak kamera real time rögzítésére való, másra nem.
-
#34256
bambano
titán
lionhearted
#34254
bambano
titán
válasz
lionhearted
#34254
üzenetére
két felhasználó apacs jelszavának tárolásához pár giga ram, néhány cpu mag, jáva, webes admin felület, saját webkonténer...
valamit nagyon nem egyformán értünk a KISS elvről.
-
bambano
titán
válasz
CPT.Pirk
#34231
üzenetére
nekem az a problémám, hogy ha egy gép nincs publikus hálózaton, nincs vele baj, akkor minek hozzányúlni?
frissíteni? mióta systemd van a legtöbb disztróban? öngyilkosság.
ha nincs olyan sérülékenység vagy hiba, ami téged konkrétan akadályoz és a frissítés megoldja, akkor felesleges frissíteni. főleg, ha "annyi meló van".ismétlem magam: ha nem romlott el, ne akard megjavítani.
-
-
-
bambano
titán
-
-
bambano
titán
válasz
#78522999
#34156
üzenetére
ja, ha mindenféle webes admin felületnek látszó hibahalmazt raksz fel a gépedre, akkor ne csodálkozz, hogy 20 percet se bír ki...
egyébként a dns szervert szokták még megborítani, ha van fent olyanod, szedd le vagy állítsd be rendesen.
lehet még olyan ok is a döglődésben, hogy a vps szolgáltató tűzfala már felfigyelt a gondjaidra, ezért lassítja a hozzáférést. velük is beszélned kellene.
-
bambano
titán
válasz
urandom0
#34153
üzenetére
ha rootként van bent, akkor ami azon a gépen van, az kuka, a komplett gép kompromittálódott.
nyilván hozzáfér az adott gépen levő privát kulcsodhoz is, ahogy leírtam az előző hsz-emben.ha nem követted el azt az orbitális hibát, hogy másolgatod a kulcsaidat mindenféle gépre, akkor ez nem olyan nagy probléma. ha ugyanazt a kulcspárt használtad egy rakás gépről, akkor bajban vagy
-
bambano
titán
válasz
urandom0
#34148
üzenetére
vajon hogyan lopja el a privát kulcsodat, ha azt soha, semmilyen körülmények között sem adod ki a kezedből? oké, a feltört rendszeren levő kulcsaidat ellophatja, de itt arról van szó, hogy aki távolról be akar jelentkezni a feltört gépre, azzal lesz baj. ha be akarsz jelentkezni a feltört gépre, akkor sem adod ki a sajátodról a saját privát kulcsodat.
-
bambano
titán
válasz
urandom0
#34143
üzenetére
ez így a nemlétező esemény. hogy sebezhetőség van az openssh szerverben, azt ki tudta lőni, de a 22-es portra nem tud rábindelni, annak nulla az esélye. a credentials lopásnak meg azért nincs értelme ebben az elképzelt felállásban, mert ha a jogosult user tudja, hogy nem a 22-es portra tette az ssh-t, akkor nem fog a 22-es porton próbálkozni, tehát nem fog legális azonosító adatokat kapni ott, aki meg a 22-es porton próbálkozik, az fake.
ha elköltöztetted az ssh-t a 22-es portról, akkor egy rakás cpu-t megspórolsz, amit a fail2ban elhasználna.
-
#34108
bambano
titán
lionhearted
#34107
bambano
titán
válasz
lionhearted
#34107
üzenetére
unixon a diszk partíció egy hatalmas blobb...
-
#34102
bambano
titán
lionhearted
#34101
bambano
titán
válasz
lionhearted
#34101
üzenetére
"Nem tudom ki hol találkozott enterprise-szal,": otthonra kell neki nas. nem enterspájz hiperkonvergált vállalati ócskavastelep
-
bambano
titán
szerintem mindent, ami állandó, és nincs túl nagy igény a biztonsági szeparációra, azt egy helyre kell tenni.
veszed a vasat, ráraksz egy alap debiant, és azon összedrótozod a kvm hostot meg a nast.egyébként meg az is kérdés, hogy neked mi az, hogy nas? nekem a nas az egy nfs szerver és pont. nincs mit virtualizálni rajta. ha guesteket akarsz rátenni, akkor lvm2.
Szerintem nem kell túlbonyolítani semmit, fájlrendszer az ext4 és jónapot. Arra kell figyelni, hogy alap beállítással kvm-et ne rakj raid1-re.
-
bambano
titán
-
bambano
titán
hogy rotálod a bináris logokat? eldobálsz fájlokat, nem?
a jobb syslogd-knek meg lehet adni, hogy milyen nevű fájlba logoljon. hogy a gép nevét bele lehet-e rakni a logfájl nevébe, azt még nem próbáltam. hogy dátumot bele lehet-e, tetszőleges formátumban, azt igen, működik. simán tudsz csinálni/var/log/%Y/%m/%d/syslog
nevű fájlt. nem kell rajta rotálni semmit, max. ráteszel egy linket a hagyományos helyéről.
-
bambano
titán
nem nekem van elképzelésem a unixról, hanem az alkotóinak. és a teljes rendszert ahhoz igazították. az, hogy csővezeték van, olyan parancssori cuccok vannak, amilyenek, az átirányítás meg a file descriptorok rendszere, mind azt mutatja, hogy szöveges feldolgozásra optimalizálták a kernelt. minden más elhajlás. jelen esetben indokolatlan és helytelen.
ha az operációs rendszer nem felel meg az eredeti, alapvető tervezési filozófiájának, akkor katyvasz lesz belőle. lásd még: m$
majd meglátjuk, hogy a dinamikus dns konfiguráció a fontos-e vagy a jogszabály. mellesleg most is dinamikus a konfig, a dhcp kliens átírja a resolv.conf-ot.
-
bambano
titán
Oké, menjünk éttermi hasonlattal.
Régen volt mindenféle étterem, majd jött a maffia, mindet erőszakkal átvette, és azóta mind vegán étterem. De az ételt mindig elsózzák és kozmás.Tehát ne csak azt az állításomat figyeld, hogy a unix filozófiájának nem felel meg a systemd, hanem azt is, hogy egyébként a systemd jelenlegi állapotában egy bughalom.
Más: az előbb jutott eszembe, míg szűkös magányomban agyaltam (
), hogy a legújabb gyerekvédelmi szabály(tervezet) fényében a systemd-resolvd nem törvénysértő?Alaposabban belegondolva mondhatjuk, hogy a tailscale a saját megoldása miatt erősen elfogult, tehát az, hogy szerintük mi a jó dns rezolválás, messze van az általános objektív valóságtól.
-
bambano
titán
nem kérdés volt, állítás.
unixon alapvetően minden szövegfájl (a szükséges kivételekkel). erre lett az egész optimalizálva.
a bináris log az olyan, hogyha én beülök egy szték vendéglőbe, akkor nekem hiába magyarázza bárki is, hogy a szója meg a tofu jó, én akkor is sztéket fogok enni. azért van unix a gépeimen, mert szöveges logokat akarok.mindig az az oprendszer van a gépemen, amellyel a legegyszerűbben meg tudom oldani a feladatomat. tehát ha ascii log elég (mindig elég), akkor nem lesz bináris logom, pláne nem lesz xml meg json meg binary blob logom.
-
bambano
titán
Ha tényleg ők a linuxos világ teteje, akkor bajban vagyunk.
"This stuff is not documented ": a valóság az, hogy documented. A resolv.conf-ban szereplő dns szerverhez fordul, pont.Egyébként a systemd-resolvd-ben az documented volt, hogyha nem jó a névfeloldásod, akkor a google névszerverére fallback-kel? Mert egy ilyen ötlettől a linux kapásból alkalmatlanná válik komolyabb helyeken való felhasználásra.
A dbus támogatás meg micsoda? Minek dbus támogatás a rezolváláshoz? Megint ez a csináljunk egy naaaagy monolitikus böszmeséget a unix alapfilozófiájából történet, ahol pottering nem érti, hogy amit csinál, az fundamentálisan rossz. vannak dolgok, amiket el kell fogadni, mint egy axiómát. A unix az KISS. Ami nem KISS, az nem unix, hanem pl. windows. a systemd nem egy tuningolt unix init, hanem egy totál más rendszer initje, ami alatt tévedésből linux kernel van.
De ezek "filozófiai" kérdések. Az alapvető probléma, hogy a systemd nem működik rendesen. Nem teljesíti a saját ígéreteit, a doksiját. Amíg nem az történik, mint ami a kottában van, addig nincs miről beszélni, az csak a mostani munkahelyén normális, hogy a világ a bétatesztelőjük, debianban eddig ez nem volt.
A systemd elkaristol, amíg az alap dolgokhoz akarod használni. Amikor nekem bonyolultabb dolgokhoz kellett volna systemd támogatás, soha nem sikerült megcsinálni, mindig valami bugba futottam bele. Egyébként meg például milyen vicces, hogy a systemd gyűjti a logokat és forwardolja a syslogd-nek. Miért nem lehet ilyenkor kihagyni a systemd-t? bináris log unixon? minek?
A systemd alapvető baja egyébként, hogy működő, tesztelt, normális megoldásokat cserél le egy katyvaszra, látható előnyök nélkül. Miközben ezzel a cserével a rendszergazdákat arra kényszeríti, hogy erőforrásokat áldozzanak a változás követésére. Minek? Ki fizeti azt meg? Én fizessem meg pottering egoizmusát? A linux régen a szabadságról szólt, nem arról, hogy minden mocskot letolnak az ember torkán. Ha azt akarom, hogy pár egoista barom hülyeségéhez kelljen erőszakkal igazodnom, veszek windows licenszet.
-
bambano
titán
válasz
urandom0
#33980
üzenetére
az xz egy annyira fontos szoftver, hogy egyáltalán nem az, még egy debian is elgurul nélküle.
Az pedig továbbra is hiba, hogy systemd jellegű óriás bináris blobok vannak a mostani disztrókban, és ész nélkül használják is azt. Jól láthatóan az alapelvtől való eltérés lényegesen elősegítette a kendácsolást.
-
bambano
titán
válasz
urandom0
#33974
üzenetére
A unix úgy született, hogy megpróbáltak komplex operációs rendszert írni, de nem sikerült. Ekkor lett az alapelve, hogy keep it stupid and simple.
A systemd teljesen egyértelműen szembemegy ezzel az alapelvvel, nagy hiba volt integrálni a disztrókba.
Minél több szemetet integrálsz az oprendszerbe, annál több támadási vektort hagysz benne.
![;]](http://cdn.rios.hu/dl/s/v1.gif)
Új hozzászólás Aktív témák
- bitpork: MOD Júni 13 Augusztus 2- szombat jelen állás szerint.
- Apple MacBook
- f(x)=exp(x): A laposföld elmebaj: Vissza a jövőbe!
- Hamarosan megkezdődik a nubia 2,8K-s táblagépének szállítása
- Kazy Computers - Fehérvár - Megbízható?
- NVIDIA GeForce RTX 3060 Ti / 3070 / 3070 Ti (GA104)
- TCL LCD és LED TV-k
- Samsung Galaxy A55 - új év, régi stratégia
- Mibe tegyem a megtakarításaimat?
- Milyen belső merevlemezt vegyek?
- További aktív témák...
- Windows 10 11 Pro Office 19 21 Pro Plus Retail kulcs 1 PC Mac AKCIÓ! Automatikus 0-24
- Microsoft licencek KIVÉTELES ÁRON AZONNAL - UTALÁSSAL IS AUTOMATIKUS KÉZBESÍTÉS - Windows és Office
- Eladó steam/ubisoft/EA/stb. kulcsok Bank/Revolut/Wise (EUR, USD, crypto OK)
- Windows 10 11 Pro Office 19 21 Pro Plus Retail kulcs 1 PC Mac AKCIÓ! Automatikus 0-24
- Eredeti Microsoft termékek - MEGA Akciók! Windows, Office Pro Plus, Project Pro, Visio Pro stb.
- Tablet felvásárlás!! Samsung Galaxy Tab A8, Samsung Galaxy Tab A9, Samsung Galaxy Tab S6 Lite
- Csere-Beszámítás! RTX Számítógép PC Játékra! R5 8400F / RTX 3070Ti / 32GB DDR5 / 1TB SSD
- ÁRGARANCIA!Épített KomPhone i5 13400F 32/64GB RAM RX 7800 XT 16GB GAMER PC termékbeszámítással
- ÁRGARANCIA!Épített KomPhone i5 14600KF 32/64GB DDR5 RAM RTX 5070Ti 16GB GAMER PC termékbeszámítással
- 4 év gari - magyar bill. - Lenovo ThinkPad Z13 G1 - AMD Ryzen R7 Pro 6850U, 13.3" 2.8K OGS érintő
Állásajánlatok
Cég: CAMERA-PRO Hungary Kft
Város: Budapest
Cég: PC Trade Systems Kft.
Város: Szeged