- Bemutatkozott a Poco X7 és X7 Pro
- Yettel topik
- Honor Magic V3 - mágikus realizmus
- Csonkítás áldozata lett a nemzetközi Redmi Note 15 Pro+
- Ez lehet az Apple hajlítható telefonjának formája, mérete
- OnePlus 8T – fazonigazítás
- Megtartotta Európában a 7500 mAh-t az Oppo
- Xiaomi 15 - kicsi telefon nagy energiával
- Poco F7 – bajnokesélyes
- Honor Magic6 Pro - kör közepén számok
-
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
-
#35274
bambano
titán
lionhearted
#35272
válasz
lionhearted
#35272
üzenetére
Ezért rendes helyen fenékbe billentés jár.
Hogy egy mindenféle gyüttment hülyeségei miatt megsértsenek hálózatbiztonsági szabályokat, az orbitális disznóság. Másrészt ha ő okoskodik az üzemeltetők helyett, akkor esetleg sosem derül ki, hogy nagy baj van a hálózaton, és nem megjavítják, hanem kehesen megy tovább.Meg egyébként a fallback úgy is működött a systemd-ben, hogyha nem létező userid-vel akartál indítani egy szolgáltatást, akkor fallbackelt rootra. Akinek ilyen megfordul a fejében, az nem normális.
-
válasz
kovaax
#35265
üzenetére
Emvynek is:
oké, akkor két kérdésem van:
- trixie, drbd-n van a home, hogy oldod meg, hogy az X ne induljon el addig, amíg a home nem elérhető?
- trixie, két hdd-ből csinálsz egy raid1-et, arra ráraksz egy drbd-t, arra egy cryptot és arra egy raid1-et. esetleg alulra egy dm-integrity-t.Lehet ömleszteni a válaszokat.
-
A mondat helyes értelmezése a következő: függőség van, beírod a systemd-be, az nem vesz róla tudomást, és akkor katyvasz van.
Tehát ha függőség van, azt úgy tudod megoldani, hogy letakarítod a systemd hülyeségeit amennyire csak lehet, és kézzel megcsinálod saját magadnak.Milyen szuper, hogy van ez a systemd, a fő előnye, hogy ki kell pucolni?
-
válasz
kovaax
#35249
üzenetére
"Az "init" része szerintem jó dolog a párhuzamosítás miatt": csak így nem tudod megjósolni, hogy mi milyen sorrendben indul el, így ha függőség van, katyvasz van.
Régen ha beleírtam az rc.local-ba, akkor az úgy volt.És egy másik történet, hogy a systemd ordenáré módon bugos.
A tapasztalatom az, hogyha úgy akarod összerakni a gépedet, ahogy a disztró készítői megálmodták, akkor többnyire működik. Felrakod default install, nem babrálod, megy. (Amíg megy...) De ha egyszer is olyat akarsz, ami a disztró készítőinek nem volt meg, akkor összeborul az egész a fenébe (ide mindenki képzeljen el egy erősebb helyhatározót
) -
válasz
Rhino666
#35244
üzenetére
Az a baj, hogy (szerintem) a systemd-t két körben kell vizsgálni.
Az első kör az, hogy ha minden úgy működik, ahogy a kottában van, akkor van-e szükség egy ilyen cuccra.
A második kör az, hogy teljesíti-e az ígéreteit a systemd.
Szerintem teljesen unix ellenes szemlélet a systemd, tehát irtani illik.
Szerintem a systemd egy orbitális kupleráj, nem működik.
Akkor lehetne beszélni arról, hogy kell-e ekkora filozófia-váltás a unixba, ha működne. Addig nem. -
#35245
bambano
titán
lionhearted
#35243
válasz
lionhearted
#35243
üzenetére
Az általam üzemeltetett összes debianon megdöglik a drbd, ha az interfészen dhcp kliens van, mert mikor a drbd elindul, még nincs ip cím.
Tehát amit én láttam, az de, feltétlenül. -
-
válasz
Rhino666
#35227
üzenetére
Sorstárs...
Az egyetlen működő workaround mellé még kettő:
1. engedélyezed az rc.local service-t, és a /etc/rc.local-ba írod bele az összes kritikus cumót.
2. nem netdev meg hasonlókra dependelsz a systemd-ben, hanem routable-ra. Ezt még nem sikerült életre rugdalnom, de ez a menő egyes eldugott doksik szerint.Egyébként nagy fanja vagyok az utáljuk p-t csoportnak, de néha felmerül bennem, hogy azok a debianos karbantartók a fakezűek, amelyek a szkripteket faragják.
-
systemd-s bohóckodás helyett vagy beírod a crontab-ba (annak az usernek a crontabjába, amelyikkel futtatni akarod) @reboot címkével, vagy berakod a /etc/rc.local fájlba. Ez utóbbihoz lenni kell systemd service-nek, szóval nem teljesen systemd mentes megoldás.
De egy program elindítása az linux-kezdő kérdés, nem haladó.
-
#35132
bambano
titán
lionhearted
#35126
válasz
lionhearted
#35126
üzenetére
-
#35128
bambano
titán
lionhearted
#35126
válasz
lionhearted
#35126
üzenetére
A többi hogy lett lefoglalva kicsiben?
szerk: közben látom, hogy azok másik vg.
De azért az is furcsa, hogy a vg-k nem egyformán lettek megkreálva. -
#35120
bambano
titán
IstvánLászló
#35119
válasz
IstvánLászló
#35119
üzenetére
Az átlag alaplap nem tud raidet, softraid van rajtuk, ami nullát ér.
-
#35116
bambano
titán
IstvánLászló
#35114
válasz
IstvánLászló
#35114
üzenetére
Ha van lehetőség, akkor a raid1-ben KÜLÖNBÖZŐ diszkeket kell tenni. Annyi a lényeg, hogy az elérési idejük között ne legyen túl nagy különbség, mert ha az egyik sokkal hamarabb végez, mint a másik, akkor a lassút kidobja a kernel a tömbből.
-
válasz
Ablakos
#35112
üzenetére
az efax végű az smr, az earx meg cmr.
ez baj.
ezt rosszul tűri a kernel. javasolt a cseréje. (az smr cseréje)az, hogy install után elindul a szinkronizáció, önmagában nem baj, mert tömb létrehozásakor kell. de ha ismételten elindul, az gond.
szerk: diszk hibát destruktívan badblocks -vsw-vel szoktam ellenőrizni, de ahhoz szét kell szedni a tömböt.
-
-
-
válasz
_kovi_
#35060
üzenetére
Nem ártana elmondani, hogy mi az a storage.
fc? escon? ficon? iscsi?
a debiant lehet telepíteni iscsi-re, akár full iscsi-re, ha a bios képes bootolni iscsi-ről vagy http-ről, akár úgy, hogy a /boot egy pendrive-on van (jelzem, csomó szerverben ezért van usb csatlakozó az alaplapon, hogy oda bedugj egy pendrive-ot.
Ha felraktad a debiant alap iscsi-re, akkor tudsz olyan kernelt fordítani, ami kell, olyan initramfs-t, ami kell. Megcsinálod a multipath-ot, és utána repóból felhúzod rá a proxmoxot (nem csak iso-ból lehet proxmoxot telepíteni, hanem alap debianra apt-get-tel is).Emlékeim ködösek, hogy ilyet csináltam-e már 12-es debiánnal, de 13-assal biztosan, nincs két hónapja se és működött rendesen.
-
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.
-
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
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
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
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
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
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. -
"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.
-
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.
-
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.
-
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.
-
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?
-
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.
-
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.
-
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.
-
-
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...
-
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
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
válasz
lionhearted
#34425
üzenetére
-
#34423
bambano
titán
fatpingvin
#34422
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?
-
Tudja valaki, hogyan lehet egy xml-t belerakni egy pdf-be?
Nem konvertálni akarom, hanem belerakni.
tia. -
-
#34353
bambano
titán
Roland861010
#34347
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
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.
-
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
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.
-
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.
-
-
-
![;]](http://cdn.rios.hu/dl/s/v1.gif)
)
Új hozzászólás Aktív témák
- Luck Dragon: Asszociációs játék. :)
- Sorozatok
- Forza sorozat (Horizon/Motorsport)
- Na, milyen hardver kerül a fa alá?
- OFF TOPIC 44 - Te mondd, hogy offtopic, a te hangod mélyebb!
- sziku69: Szólánc.
- BestBuy topik
- DUNE médialejátszók topicja
- Audi, Cupra, Seat, Skoda, Volkswagen topik
- sziku69: Fűzzük össze a szavakat :)
- További aktív témák...
- DELL Precision 5540 Workstation i7-9850H Nvidia Quadro T2000 32GB 512GB 15.6" 1év garancia
- GYÖNYÖRŰ iPhone 12 Mini 128GB Black-1 ÉV GARANCIA -Kártyafüggetlen, MS4206, 100% Akksi
- GYÖNYÖRŰ iPhone 12 Mini 128GB Purple-1 ÉV GARANCIA - Kártyafüggetlen, MS3630
- Eredeti Microsoft Windows 10 / 11 Pro OEM licenc Akciós áron! 64/32 bit Azonnali kézbesítéssel
- Eladó Samsung S23 Ultra 8/256GB / 12 hó jótállás
Állásajánlatok
Cég: Laptopszaki Kft.
Város: Budapest
Cég: BroadBit Hungary Kft.
Város: Budakeszi