- Samsung Galaxy Watch (Tizen és Wear OS) ingyenes számlapok, kupon kódok
- Apple iPhone 14 Pro Max - sziget fesztivál
- iPhone topik
- MIUI / HyperOS topik
- Samsung Galaxy Fit 3 - keveset, de jól
- Samsung Galaxy S23 Ultra - non plus ultra
- Xiaomi 14 - párátlanul jó lehetne
- Redmi Note 12 4G - valaki fizetni fog
- Milyen okostelefont vegyek?
- Samsung Galaxy S24 - nos, Exynos
Hirdetés
-
Spyra: nagynyomású, akkus, automata vízipuska
lo Type-C port, egy töltéssel 2200 lövés, több, mint 2 kg-os súly, automata víz felszívás... Start the epic! :)
-
Filléres Redmi érkezett
ma Az A3x nem kapott nagy bemutatót, egyszer csak felbukkant.
-
SGF24 - Remekül fest a Phantom Blade Zero
gp A Summer Game Fest utolsó játéka nem más volt mint a PC-re és PS5-re készülő játék, amelyhez még mindig nem kaptunk megjelenési dátumot.
-
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
-
Jester01
veterán
azért ha a spotify-on leállítom a zenét, hogy megnézzek egy youtube videót ne kelljen valahogy átadni, mert rohadtul nem fog menni normálisan a dolog.
Megkockáztatom, hogy alsa-ban régebb óta van szoftveres keverés (dmix/dsnoop) mint amióta a pulse létezik. Normális rendszeren az az alapértelmezett és csak akkor van baj ha egy adott program konkrétan a hw eszközt kéri. De a legtöbb programban ez egyébként is konfigurálható. Ha meg nem, arra nem az a megoldás, hogy kitalálunk egy új hangrendszert amit minden programba külön implementálni kell hanem megjavítjuk azt az egy programot ami hülye volt. A spotify-t amúgy nem ismerem de esélyes hogy nem hülye és be lehet állítani melyik hangeszközt használja. A teljesség igénye nélkül a chrome, firefox, mplayer, xine, xbmc, wine, teamspeak, openal mind kiválóan működik alsa-val.
Az egyetlen pulse szolgáltatás ami kicsit hiányzik az az alkalmazásspecifikus hangerőszabályzás de általában ezt tudják a programok maguk.
Jester
-
Sokat lehetne találgatni, hogy a Debian miért emelte be a systemd-t a rendszerbe, de az tényként kezelhető, hogy nagyjából pofán köpték magukat, amikor ezt megtették - szakítottak a KISS filozófiával, a POSIX kompatibilitással - és nincs kétségem afelől sem, hogy ezzel elindították a Linux világot egy proprietary irányba és már nem mások, mint a Red Hat szócsöve.
https://www.coreinfinity.tech
-
inf3rno
nagyúr
"Fejlesztői szemmel a systemd egy értelmezhető, modern, tesztekkel lefedett kód, ami fent van a githubon." - Hát 4 éve még nem volt túl erős a lefedettsége, reméljük azóta javult. [link] Ha már szóba került, akkor inkább OpenRC-hez lenne értelme hasonlítani, az állítólag hasonló tudású rendszer: [link].
Mindkettő fent van githubon. Beszéljenek a számok.
OpenRC: [link]
- 13k sor kód C-ben (összesen 21k sor adatfájlokkal)
- 41 nyitott issue, 114 zárt, 6 alap issue label
- 103 contributor, 52 watcher
- 3k commit, az utolsó 2 hónapja
- benchmark a cikkből 46.5 secSystemD: [link]
- 355k sor kód C-ben (összesen 650k sor adatfájlokkal)
- 1143 nyitott issue, 4226 zárt, 165 issue label
- 1185 contributor, 332 watcher
- 42k commit, az utolsó 3 napja
- benchmark a cikkből 43.5 sec355/13 = 27, tehát 27x annyi sor kód van a systemd-ben
13k/(41+114) = 84, 355k/(1143+4226) = 66, durván 20%-al kevesebb sor kódra jut egy issue a systemd-nél, igazából engem meglepett, hogy csak ennyivel rosszabb
13k/103 = 126, 355k/1185 = 300 sor kódra jut egy contributor
13k/52 = 250, 355k/332 = 1069 sor kódra jut egy watcher
300/126 = 2.4, 1069/250 = 4.3
tehát 2.4x több munkát végez egy contributor, és arányaiban 4.3x annyi kód jut egy watcher-re a systemd-nél, bár az utóbbi csalóka, mert(46.5-43.5)/46.5 = 6.5%-al több idő a bootolás OpenRC-vel
Nagyjából annyi a véleményem, mint eddig is, most vagy nagyon balfaszok a systemd fejlesztői és overengineered az egész, vagy a kód nagyrésze egyáltalán nem is az inittel foglalkozik, ha elfogadjuk, hogy az ő megközelítésükkel ugyanannyi kódból ki lehet hozni egy init rendszert, mint az openrc megközelítésével. Igazából meg lehet nézni még más init rendszereket is. SysVinit 8k sor, upstart 71k sor, mindkettő jóval elmarad a systemd-től, az upstart, ami legalább kicsit megközelíti kód mennyiségben.
Az a fogalom, hogy "standard-nek mondható" nem létezik. Vagy szabványosítva van valami, vagy nincs. A szabvány készítés általában több éves folyamat, nem csak ilyen összeszórunk valamit, aztán jó lesz alapon megy.
"Ez kb. minden fejlesztő több havi munkáját igényli, költsége millió $-ban mérhető. De valószínűleg a Debiannál sem két perc volt a váltás." - Pont ezért kellett volna valami normális init rendszerre áttérni, nem erre a szemétre. Mindenkinek kevesebb munkájába került volna egy moduláris init rendszerre való áttérés, mint egy ilyen monolitot beletákolni a disztrójukba, ahol minden mindennel összefügg. Sokan hoztak már ostoba döntéseket ilyen vagy olyan okból, elég csak megnézni a főpolgármester választás eredményeit pártpreferenciától függetlenül.
Buliban hasznos! =]
-
Frawly
veterán
A P3-ast extrém példának írtam. Nyilván értelmes ember nem használ ilyen gépet, csak hobbisták, retrózók. Ők viszont szórakozásból meghúzzák, hogy modernebb OS-t tesznek rá. Ilyen körülmények között de, felmerül, hogy mi milyen gépen hogy fut, meg az is, hogy a systemd valójában bloat.
C2D, C2Q, régi genes Core i gépek, laptopok használtan, meg refurbolva elég olcsón mennek. Ezért is nem értem, hogy miért veszi még mindig sok ember ezeket az Atom-os, Celeronos szutyok gépeket, de még olyan ember is betér néha linuxos topikokba, aki Pentium 4-re meg Athlon XP-re keres sovány disztrót. Meglepődünk rajta.
Pont itt a PH-n is az egyik retrós topikban most volt egy csóka, aki kései, 14 éves Pentium M-es gépre tett fel Win10-et. Nyilván nem ezt használja fő gépnek, van vagy másik 100 gépe otthon, közöttük gondolom modernebb is, inkább csak a kihívás meg érdekesség kedvéért kísérletezik ilyennel.
[ Szerkesztve ]
-
bambano
titán
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.
Egy átlagos héten négy hétfő és egy péntek van (C) Diabolis
-
bambano
titán
"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.
Egy átlagos héten négy hétfő és egy péntek van (C) Diabolis
-
Frawly
veterán
Init rendszeren tágabb értelemben nem csak a PID 1-es folyamatot hívják, hanem azt az egész megoldást, amivel a többi folyamat indítható, az induló folyamatok konfigurálhatók, stb..
De nem véletlenül írtam, hogy a systemd-vel az a baj, hogy nagyon rég nem csak egy initrendszer. Egy komplett, bloat mini OS beékelve az kernel és userspace közé. Nem csak az initfeladatokat veszi át, hanem egy csomó hálózati, biztonsági, naplózási, hardverkezelési dolgot is, meg alkalmazások közötti kommunikációs felületet.
Ha tényleg megmarad volna initrendszernek, ami tényleg csak initként működik, semmi mást nem is tud, akkor nem lenne vele nagy baj. De így kezd egyre jobban elfajulni, most fogják behozni, hogy a homed komponens a home mappát, meg egy csomó felhasználói konfigot is fog kezelni, azt is saját kézbe veszi. Így meg egy szép nap azon kapjuk magunkat, hogy az egész Linux megszűnik Linuxnak lenni, és linuxd lesz belőle, amit nem a Torvalds-féle kernel fog hajtani, hanem Pöcstering által foltozott kerneld. Na, ennek kéne elejét venni.
[ Szerkesztve ]
-
OddMan
őstag
-
inf3rno
nagyúr
Mert a backup is hozzásegít a rendelkezésre álláshoz, hiszen ha elveszik az adat, akkor minden leáll. Illetve a RAID is hozzásegít a biztonsághoz, mert többször letárolja ugyanazt, így egy meghajtó hibája miatt nem veszik el az adat, és nem kell azonnal a backup-hoz nyúlni. Ezen kívül a modern fájlrendszereknél (zfs, btrfs) RAID-el szokták kombinálni a block checksum-ozást, és így ezek a fájlrendszerek védenek bitrot ellen is, amire a backup önmagában nem képes. A helyzet komolyságától függően lehet a backup-ra is szoftveres RAID-et tenni, illetve lehet több backup-ot is használni, de ez azért a legtöbb projektnél ágyúval verébre.
Buliban hasznos! =]
-
Dißnäëß
veterán
Semmi komoly amúgy, csak nálam úgy "kell" archiválni, hogy közben elérhetőek is maradnak az adatok.
Mondjuk az a rahedli saját CD backup, amiket a kilencvenes évek óta gyűjtögettünk anno faterral, meg sokminden egyéb még.
Kitehetem polcra is (kint is van egy 500 GB-sen) ami hiperfontos nekem, a többi ennél mérsékelten fontosabb csak, de annál meg megint fontosabb, hogy egyetlen diszken legyenek.
Nem vagyok egyszerű eset. Na, ilyenekre jó a softraid + btrfs (míg a btrfs saját raid-szerű megoldása nem lesz iszonyú stabil, silent corruption ellen jó). De lehet végül nem tökölök és feldobok egy VM-ben egy BSD alapú NAS-t, alárendelem a diszkeket és jónapot, zfs.
Még agyalok ezen azért.rsync: a tippet köszi, le-man-ozom.
POKE 16017,44 ..... SYS 2077
-
samujózsi
tag
Nem, írja is, hogy nem használ RAID-et. Csak ott van valami fontosnak gondolt dolog a logban.
Lehet, hogy a statikus mára elavult, én 0.99.x kernelen kezdtem és valahol 1.0 v. 1.2 környékén hagytam abba a saját kernel fordítást, akkor még a modul elnevezés volt a szokásos, a nem modul meg ugye statikusan van beledrótozva.
Primadonnát felveszünk! https://youtu.be/9lETrcMJZJM
-
inf3rno
nagyúr
Nem éppen, mert korrekt az lenne, ha azt írná, hogy nincs csatolva rootfs, itt meg valami huszadrangú következményt ír, hogy nem tudja az initet elindítani. Igazából még azt sem, azt írja, hogy "not syncing, attempted to kill init", ami szerintem max a kernel fejlesztőknek mond bármit, vagy még nekik sem, annyira alacsony szintű bullshit.
[ Szerkesztve ]
Buliban hasznos! =]
-
Frawly
veterán
A gentoo-s kernelek is bootolnak épp úgy, ext4-ről, initramfs nélkül. Initramfs akkor kell, ha van RAID vagy LVM vagy titkosítás, esetleg a /var, stb. másik partíción lenne a roothoz képest. De ezen speciális esetek EGYIKE SEM áll fenn. Pont azért írom, hogy sima ext4 partíció, semmi extra konfig, semmi extra mount paraméter nem kell. Tehát nem ez a gond. RAID-et sem használok, csak azért lett említve, hogy nem ez a gond, hiába az md-s sorok után hal be. Egy későbbi screenshoton becsatoltam a kernel panic elejét is.
Ezt a tty konzolos mókát ki fogom próbálni. Egyébként nekem nem az a bajom, hogy nem működik, hanem hogy nem írja ki normálisan, hogy mi a baja. Lehet valami kernelfordításkor maradt ki, mert make defconfig-ot használok, de utána végigszaladok rajta egy make menuconfiggal, hogy még beletegyek 1-2 dolgot, de lényegben defconfig az egész.
[ Szerkesztve ]
-
Jester01
veterán
Rohadtul nem kéne ext4-et initramfs nélkül csatolgatni.
De. Az initramfs megint egy egyszerű dolog elbonyolítása. Ha saját rendszert építesz szépen minden szükséges megy a kernelbe és nem kell szórakozni az initramfs-el. Felcsatol valami átmeneti / könyvtárat amiben ki tudja mik vannak (és aminek a frissen tartása megint plusz feladat), futtat mindenféle mágiát majd a végén valahogy kicseréli a futó kernel alatt az igazi gyökérre. Kösz, nem kérem
Frawly: szerintem a blokk eszköz vagy annak valami függősége nincs belefordítva. Azt nem tudom qemu alá mi kell, de nekem ilyesmik vannak:
CONFIG_BLK_DEV_IDEPCI=y
CONFIG_BLK_DEV_GENERIC=y
CONFIG_BLK_DEV_IDEDMA_PCI=y
CONFIG_BLK_DEV_PIIX=y
CONFIG_BLK_DEV_IDEDMA=y
CONFIG_SCSI_MOD=y
CONFIG_SCSI=y
CONFIG_SCSI_DMA=y
CONFIG_SCSI_PROC_FS=y
CONFIG_BLK_DEV_SD=y
CONFIG_ATA=y
CONFIG_SATA_AHCI=y
CONFIG_ATA_SFF=y
CONFIG_ATA_BMDMA=y
CONFIG_PATA_OLDPIIX=y
CONFIG_PCI=y[ Szerkesztve ]
Jester
-
inf3rno
nagyúr
Int return-el is ugyanúgy megoldható, egyszerűen magasabb szinten másik integert kell visszaadni, nem azt, amit alacsony szintről kapsz. A goto err esetén nyilván nem megoldható, de gondolom legtöbbször az is magasabb szinten dől el, hogy szükség van e rá, vagy áthidalható a probléma máshogy. Nyilván kevesebb fejlesztési idő, meg egyszerűbb úgy, ahogy ők csinálják, aztán az end user szívhat vele.
[ Szerkesztve ]
Buliban hasznos! =]
-
bambano
titán
"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.
Egy átlagos héten négy hétfő és egy péntek van (C) Diabolis
-
inf3rno
nagyúr
Nem nagyon megy át, de nem ezzel van a problémánk, hanem azzal, hogy olyan hibaüzeneteket dob, amik minimálisan vagy egyáltalán nem segítenek a probléma megoldásban. Ennek semmi köze a kernel debuggolásához vagy fejlesztéséhez. A fenti esetben pl annyit kellett volna dobnia, hogy nincs rootfs csatolva és ezért leáll, mert az átlag felhasználónak erre az információra van szüksége. Ehelyett valami baromságot írt. Szerintem ez így nincs rendben, és szerintem megoldható lenne, hogy normális hibaüzeneteket adjon, csak a fejlesztők nem foglalkoznak a kérdéssel, mert plusz munka. Egyébként ez a windows-t is érinti, főleg hardver hibánál csak találgat az ember, mert nálam pl alaplap hibára írta, hogy a videokártya illesztő összeomlott...
[ Szerkesztve ]
Buliban hasznos! =]
-
Frawly
veterán
Feltettem pár hozzászólással később a hibaüzenet első felét is. Lényegében a legelső sor volt a lényeg, NULL pointer dereference. Magyarán csak olyan memóriaterületre nyúlt, amihez nem kellett volna, szimpla bug miatt totálisan összefosta magát. Ez még oké is, de akkor a kernel panic végére ne ilyen attempted to kill init baromságot írjon, félrevezetve az embert, hanem írjon akkor unknown error, vagy erre a NULL pointer reference dologra mutató dokumentációs linket.
Az amatőr ügyfélszolgálatok szoktak ilyen baromságokat javasolni, hogy egyszerű netkimaradásnál vagy energiagazdálkodási beállítás miatti gikszernél is újratelepíttetik a Windowst, csak hogy ki legyen zárva a hiba, kényelemből félrevezetik a laikust.
Mondom, nem az a baj, hogy nem ment, mert arra számítani lehetett, hogy a legfrissebb RC nem épp a legstabilabb dolog a világon. Csak akkor ne vezessen félre a hibaüzenet, jól megvezetett, mert még nincs a témában nagy tapasztalatom, és emiatt magamban kerestem a hibát, vergődtem mindenféle konfiggal, partíciócsatolással, init problémával, közben a hibának 0 köze volt ezekhez.
[ Szerkesztve ]
-
samujózsi
tag
Hát az is lehet. De miért a könyvtár (ami úgy tűnik, következetesen a DCIM alatti könyvtárak egyike) n. fájljánál?
Ettől függetlenül sajnos igazad is lehet (bár ha azt veszem, hogy nem elhajt azzal, hogy nincs joga, hanem csak lefagy, akkor nem annyira security gond)A régi ubuntun mtp-tools segítségével egyáltalán nem férek hozzá, a 18.04-en meg van gnome, ott a gnome egyből mountolja(?), nem tudom, nem azzal akad-e össze a parancssor.
Primadonnát felveszünk! https://youtu.be/9lETrcMJZJM
-
-
Dißnäëß
veterán
Így van. Általában. (Köszi a pontosítást).
Érdekes amúgy, mert az ext4 még csak nem is CoW fájlrendszer, míg egy btrfs, zfs igen. És még ezeket sem feltétlen kell defrag-olgatni, pedig jobban van bennük az implementálva, hogy ne fragmentálódjanak annyira és ez működni is látszik, míg nincsenek agyon-teleírva (kb. háromnegyede egészséges maximum).POKE 16017,44 ..... SYS 2077
-
Frawly
veterán
Na, látod, ezt nem kéne tényként kezelni. A rolling semmivel nem alkalmatlanabb, mint a fizetős vállalati disztrók. Ez megint csak marketing miatti sztereotípia. Igazából aki ért hozzá, annak mindegy mit használ, meg tudja válogatni az eszközöket, licenceket, meg ha valami probléma lenne, meg tudja oldani magának. Pont ez a Linux szépsége egy Windows Server ellenében, nem is a licencdíjon spórolos, hanem Linuxon minden problémát tuti meg lehet oldani, sokféle alternatívára lehet azon belül támaszkodni, és nem vagy egy multicég zárt forráskódú megoldására rászorítva, ami vagy működik, vagy nem, újraforgatni nem tudod, alternatívák nincsenek rá.
Én nem is szeretek céges supportra támaszkodni. Mert mi van, ha a supportáló cég tönkremegy, lehúzza a rolót? Vagy épp a supportjuk XY problémánál nem tud segíteni? Akkor sok ilyen felelősségetelhárítós, öltönyös-nyakkendős, hojjdeszupport-de-szupport-100-évig-eltéess lúzereknek nagyon gyorsan megáll az élet, és megy a pánikolás, hogy nem megyen a szerver, maja világvége, rohanjon mindenki a bunkerba túlélni. Aki idióta a dolgokhoz, meg gányol, azon egy support meg egy hosszú támogatási idő sem fog tudni segíteni, tényleg csak arra lesz jó, hogy valaki megpróbálja jogászkodással a felelősséget áthárítani valaki másra.
Szerintem a licenccel sincs probléma, főleg nem szerveren, mert a legtöbb szerveres dolog pont GPL-es opensource. Ez a nonfree csomagok problémája inkább a desktopot, DRM-es és egyéb dolgokat érintik, ezek meg szerveren nem létező probléma. Meg igazából a legtöbb céget nem szokta zavarni a licenc, rezzenéstelen arccal tolják a rendezetlen licencű ZFS-t, meg hasonló megoldásokat. Ahol meg annyira licencfetisiszták, ott meg pont BSD-t szoktak használni Linux helyett, mivel megengedőbb a licence, igaz cserében a leghosszabb támogatási idő BSD-ken 5 év max.
Azt én is néztem, hogy a SUSE-nek a leghosszabb a támogatási ideje, 12 év. Ja az jó hosszú. Persze a CentOS 11,5 éves támogatása se piskóta, szerintem az is overkill kategória erősen.
[ Szerkesztve ]
-
Frawly
veterán
Persze, tökéletes teszt meg tökéletes garanciák nincsenek semmire. A fizetős, 10 éves támogatású rendszer is épp úgy eltörhet.
A tesztrendszer nem is arra való, hogy hibátlanul teszteljen, hanem teljesen blőd hibákat ki lehessen zárni vele, mikor az egész rendszer csak úgy letérdel zusammen, meg bootképtelen lesz. Tehát nagy szarvashibák kizárására van.
Egyébként nem is annyira a használt rendszer számít, hanem a szakértelem, meg hogy az ember betartsa a szakmai ajánlásokat (redundancia, backupok, snapshotok, tesztelés), és a szoftveres infrastruktúra is minél nyíltabb, minél szabványosabb legyen, és ne ilyen házilag összegányoltatott, csak régi verziókon futó, nem szabványos, zárt kódos dolgokat kell erőltetni, ami pl. szeret akármilyen rendszeren könnyen törni, és akadálya mindenféle frissítésnek. A legtöbb cégnél az utóbbi a probléma, nem is az alatta használt rendszer, hanem az inkompetens gányolás.
-
Dißnäëß
veterán
Hát ezt próbálom mondani, hogy egyáltalán nem, nem láttatok még eleget (Minden bántás nélkül). Nem infráról beszélek és alapmegoldásokról, hanem egy üzleti részleg teljes számlázója, CRM rendszere, nyilvántartója, marketing eszközei, analitikája, full-fullba úgy az egész. És ha ezen gépeket, legyen az akár virtuális, akár fizikai, beleszámoljuk a nagy egészbe, akkor gyorsan oda a torta egyharmada MS-nek. Nyilván többet nem szeretnék erről mondani, pláne nem megoldás és cég neve(ke)t, de ez van, ezt jobb elfogadni, mint dobálózni azzal vakon, hogy 99% linux. (5 magyar telco-snál voltam és 2 banknál eddigi pályafutásom során).
De nekem mindegy is, nem hittéríteni akarok itt (pláne nem szívem mélyén Linuxosként), csak a tényeket próbálom a valósághoz közelebb hozni. 1 példa még nem példa, én pedig rálátok mindre, vannak mindenféle megoldások, de meglepően sok MS cucc van szerver oldalon is.
POKE 16017,44 ..... SYS 2077
-
samujózsi
tag
Az egy hibát csinál, nem görgeti végig a fájlrendszeren. Pár éve nyűglődött egy ismerősöm hasonló témával, akkor körülnéztem a google-n és találtam egy oldalt, ami sorolt pár ellenérvet ellenük.
Az egyik az volt, hogy ECC RAM nélkül veszélyes a crc/checksum használat ezeken a fájlrendszereken, mert ha a memóriában elállítódik egy bit, annak alapján automatikus javításba kezd(het?), ami viszont sokkal nagyobb adatvesztéshez vezethet, mintha csak az az egy bit sérülne.
Sajnos már nincs meg a bookmark
Ha ott hülyeséget irtak, mea culpa![ Szerkesztve ]
Primadonnát felveszünk! https://youtu.be/9lETrcMJZJM
-
Dißnäëß
veterán
Én ezt értem, de egy mini ITX konfigot nem kell nulláról tanulnom, pont tanulok elég újat mostanában, a Linux meg ugye tud elég sokmindent. Meg szerintem ne kategorizáljunk, azért jól tud esni, mikor megkérdeznek, miért wifin keresztül DD-zem a gyerek gépét, mikor backup-olom, az marha lassú lesz, és a válaszom, hogy 800Mbit körül hasítok egy fallal arrébbról egy lassan 4 éves router-rel, meg konkrétan az 1000-es Digimet kimaxolja, úgyis mögötte futtatok mindent, nem rajta.
Szóval vicc vagy nem, nekem bőven tökjó
Nem érdekel a Mikrotik, akinek van olyan irányú affinitása, használja, egészségére, nála sokkal fontosabb dolgokat prio-ztam előre az életemben.De ez már itt nagyon off, hogy engem mi érdekel
A passzívra: nem építettél még. Pláne nem Akasa Euler-ekkel.
[ Szerkesztve ]
POKE 16017,44 ..... SYS 2077
-
Frawly
veterán
Igen, de ha nem tudok róla, meg nem volt belőle adatvesztés, akkor miért számítana? Általában egy RAM vagy jól működik, vagy nem. Utóbbi esetben sokkal durvább jelei vannak, mint a bitflip. Ha meg működik, akkor meg a bitflipnek nincs gyakorlati jelentősége, annyira ritka.
-
_Dumber_
őstag
Nem akarom szívatni magam, ezért érdeklődöm.
Probook 470 lenne cserélve, egy kicsi, max 220mm magas (kinyitott állapotban) paraméteres gépre, hogy beférjen a monitorom alá, és ne kelljen az eget kémlelnem. Nekem kell a dupla nagy monitor. Most ezek mözül az egyik a 17.3-as laptop., de már púp nő a hátamon a lefelé nézéstől. (Tudom most nézzek 3 évig felfelé akkor helyreáll a hátam )Nem sürgős úgyhogy még nézelődök és érdeklődök ...
-
Frawly
veterán
Ja, a BogoMIPS is felesleges. A kernelben nem, mert az valami időzítéshez használja betöltés közben, de a cpuinfo-ban semmi szükség nincs rá, egy teljesen fals benchmarkérték.
Amúgy meg de, a kernel meg tud szerezni mindenféle infót, a legtöbbet a CPUID-ből tuja kiolvasni, és azt összevetni egy adatbázissal. Meg egyébként is sok infót meg tud szerezni, a modern OS-ek nem nagyon függenek a BIOS-tól. Utoljára a DOS meg a Win9x volt olyan, ami erősen függött tőle, mert egy rakat BIOS-hívást használt.
(#30669) Jester01: elhiszem, hogy a CPUID utasítás ezzel a @ jeles névvel tér vissza, de ezt a kernel lecserélhetné megjelenítéskor, simán regexppel.
-
Dißnäëß
veterán
Olvasáskor nem ? Mert mondjuk azt nem kell tudnia, mi van a hibás szektoron, de annak ténye, hogy ott valami nem oké a fej alatt egy ponton, mikor elsuhan alatta párszázszor, szerintem azt képes lenne detektálni. Lásd HDSentinel Surface Scan, Read mód. Lazán pakolgatja be nekem a feketéket egy szar vinyón.
Mondjuk nem WD Purple (ahol nincs firmware szintű CRC), hanem Seagate NAS, ahol meg van.
Na mindegy, azt hiszem, a lényegre választ kaptam, tehát LUKS mellett egy adott titkosított blokk úszik, leves, a ZFS meg erre ugyanúgy megoldás innentől, mintha LUKS nélkül válna valami alatta inkonzisztenssé. Jó. Kiváló.
[ Szerkesztve ]
POKE 16017,44 ..... SYS 2077
Új hozzászólás Aktív témák
- Samsung Galaxy Watch (Tizen és Wear OS) ingyenes számlapok, kupon kódok
- Nem tudom a dal címét, előadóját
- PlayStation 5
- Xbox Series X|S
- Formula-1
- Xbox tulajok OFF topicja
- Folyószámla, bankszámla, bankváltás, külföldi kártyahasználat
- Azonnali alaplapos kérdések órája
- D1Rect: Nagy "hülyétkapokazapróktól" topik
- iPad topik
- További aktív témák...
- Számlás!Steam,EA,Epic és egyébb játékok Pc-re vagy XBox!
- Autómatricák a legjobb minőségben, több ezer minta! PH tagoknak 30% kedvezmény!
- Bontatlan - BATTLEFIELD 1 Collectors Edition - Játékszoftver nélkül
- Játékkulcsok olcsón: Steam, Uplay, GoG, Origin, Xbox, PS stb.
- Windows, Office licencek a legolcsóbban, egyenesen a Microsoft-tól - 2990 Ft-tól!
Állásajánlatok
Cég: Ozeki Kft.
Város: Debrecen