Zobrazit příspěvky

Tato sekce Vám umožňuje zobrazit všechny příspěvky tohoto uživatele. Prosím uvědomte si, že můžete vidět příspěvky pouze z oblastí Vám přístupných.


Příspěvky - RDa

Stran: [1] 2 3 ... 196
1
Server / Re:Hardwarový RAID nebo ZFS?
« kdy: 20. 05. 2025, 17:26:38 »
U 6 disku je to zcela jedno a pokud HW raid ma moznost pracovat se SSD (umi TRIM) tak pouzivej HW raid. Jinak radeji sw raid.. nez se ucit nejaky custom frikulinsky hw raid tool / klikatko.

Pokud bys mel disku 60, tak se oplati premyslet o ZFS.

Pro 600 disku je pak ZFS spise jedina moznost.

2
Server / Re:Geograficky redundantní NAS
« kdy: 15. 05. 2025, 10:27:37 »
PS: za zvážení stojí otázka, jak moc je pravděpodobné, že časem přibude třetí region, a vybrat vhodný přístup hned na začátku. Master-master je jedna věc, N-uzlový mesh je ještě další úroveň.

Pokud by naopak mel 3 lokace (klidne tu treti jako pasivni/zalozni), tak by bylo nejvhodnejsi vzit CEPH.
(pripadne to resit jako 2+2 (+2) pro klasicky setup kde si muzete po jednom updatovat nody a nic nevypadne)

3
Server / Re:Geograficky redundantní NAS
« kdy: 14. 05. 2025, 18:25:19 »
Ona ta konektivita (sirka pasma) je potreba v zavisloti na pomeru RO:RW operaci. Pokud je veskera aktivita RO, tak nepotrebujete konektivitu zadnou ,)

Pro master-master (vs master-slave) je pak dulezitejsi latence na konektivite - aby slo vykomunikovat zamky v nejakem rozumnem case. A na to nema vliv objem zaplacenych prostredku - vice penez do storage technologie vam nezlepsi experience.

Zpet k tomu memu - pokud fakt neni rozpocet na 3rd party proprietarni reseni, tak nezbyva nic jineho nez si zkulturnit sve aplikace, aby si do zeli nelezli.. a pak muzete nasadit nejakou jednodussi formu reseni i ve vlastni rezii.

PS: ale zalohovat (a obnovovat) bych tenhle bastl pak nechtel :D

4
Server / Re:Geograficky redundantní NAS
« kdy: 14. 05. 2025, 17:39:13 »
Ano, pro master-master to bude chtit nejen tlustsi linku, ale hlavne redundantni.

Na druhou stranu - podle toho popisu mi vychazi ze workload je spis RO, a pokud nekde dochazi k zapisum tak to budou spis logy/databaze a to lze agregovat/distribuovat jinak (u DB by se taky dala udelat segmentace, aby ten rw sdileny obsah byl co nejmensi a zbytek jen ro).

1TB je zde spise vyhoda (a to se pres 10G da pretahnout za 20 min cely).


Jeste jinak - jsi schopen na svych klientech striktne oddelit kam zapisama sahaji ?

(napada me pak reseni mit dve nezavisle NAS s NFS, a na obou NAS pobezi neco navazane na inotify a vsechno co se zmenilo, bude pushnuto pres 10G na druhy breh ... ale je zde velice silnej pozadavek, aby nedochazelo ke konfliktum)

Ke konfliktum treba nedojde, kdyz kazda aplikace (resp. bezici instance) bude bezet pouze na jedne strane, a na druhe se spusti az jedna lokace klekne. Pripadne ty appky musi mit vlastni individualni (lokalni, nesyncovanej) temp a pod.

5
Server / Re:Geograficky redundantní NAS
« kdy: 14. 05. 2025, 12:37:48 »
A znas alespon zakladni pozadavky?

- pristup jako block device vs pristup jako k souborum/objektum?

- potrebujes garantovanou synchronicitu dat (a tudiz ztrata spojeni bude znamenat media offline, nebo drop do RO), nebo lze akceptovat lazy-sync s nejakou latenci?

- potrebujes pristup skrze klasicke protokoly (smb/nfs), nebo jde o datove uloziste pres vyssi API ?

- co jsou klienti daneho storage reseni? a jaka data tam jsou ulozena

6
Software / Re:Plný unicode font se všemi znaky
« kdy: 11. 05. 2025, 20:50:03 »
Treba u toho noto je cjk jako zvlast balicek (lze nainstalovat primo nebo skrze USE flag dependency), pak jeste je tam neco s emojis jako extra.

Kód: [Vybrat]
$ USE=cjk emerge media-fonts/noto media-fonts/noto-emoji -pv

These are the packages that would be merged, in order:

Calculating dependencies... done!
Dependency resolution took 8.63 s (backtrack: 0/30).

[ebuild  N     ] media-fonts/noto-cjk-20190416::gentoo  USE="X" 1,838,037 KiB
[ebuild  N     ] media-fonts/noto-emoji-20241003::gentoo  USE="X -icons" 202,212 KiB
[ebuild   R    ] media-fonts/noto-20250501::gentoo  USE="X cjk* extra" 0 KiB

Total: 3 packages (2 new, 1 reinstall), Size of downloads: 2,040,248 KiB

7
Sítě / Re:Přenos dat chytrého vysavače
« kdy: 10. 05. 2025, 11:17:20 »
Jestl to ma kameru a pripojeni na internet, tak tve oblidli uz je nafoceno do detailu a poslano do Ciny.

Rule #1 - nekupovat chytre veci, kdyz nejste ochoten ztratit sve soukromi. V cine ani americe se na takove koncepty nehraje.

8
Bazar / Re:Prodám rackové servery HP, Dell, IBM
« kdy: 09. 05. 2025, 11:13:13 »


A kde jsou ty stroje k vyzvednutí?

Pokud neni uvedeno mesto je to Praha. Zlaty zakon ceske inzerce :D

9
Prepnuti power profile na balanced + doladeni pres "moderni" power settings v novych wokennich settings = tadaaa, najednou mam TDP limit 30 W, boost snad kolem 40 W a je to uplne jinej vesmir.

Nedokazi ovsem urcit, v cem presne je rozdil (resp. co za volani tu zmenu udelalo)... a uz vubec ne, jaky nastroje na to pouzit pod tucnakem.

Typicky se pouzivaji k nastaveni power managementu zadni vratka (MSR), ze ktereho si to PSP firmware prevezme a podle toho ridi limity spotreby a frekvenci.

Samozrejme tomu jde udelat hezkou fasadu skrze ACPI, ale dnesni vyrobci ci programatori biosu to nemaji jako prioritu. Protoze uvest na trh dokonaly produkt by znamenalo nizsi prodeje pristi generace.

10
Vývoj / Re:Budoucnost Rust v embedded světě
« kdy: 05. 05. 2025, 11:29:39 »

Tak to je opravdu velké nepochopení, memory-unsafe kód jde samozřejmě napsat i bez malloc/free. Např. tento kód v C:
Kód: [Vybrat]
int main()
{
    int a[1] = {42};

    int i;
    for (i = 0; i < 2; ++i) {
        printf("%d\n", a[i]);
    }
   
    return 0;
}
je memory-unsafe a žádné malloc ani free tam není. Mimochodem je napsaný podle všech "Rules for Developing Safety-Critical Code", ničemu z toho neodporuje. Rust by to samozřejmě chytil.


Na tohle vam ale staci chytrejsi C prekladac, zrovna gcc-15 se v tomhle chova zvlastne, puvodni kod neukazuje zadnou chybu, ale pridanim printf("%d\n", a[2]); pred return si to zacne stezovat i na "undefined behavior" v ramci vaseho cyklu, v zavislosti na urovni optimalizace:
Kód: [Vybrat]
$ gcc -O0 -Wall -Warray-bounds=2 test.c -c -o test.obj


$ gcc -O1 -Wall -Warray-bounds=2 test.c -c -o test.obj
test.c: In function ‘main’:
test.c:9:9: warning: iteration 1 invokes undefined behavior [-Waggressive-loop-optimizations]
    9 |         printf("%d\n", a[i]);
      |         ^~~~~~~~~~~~~~~~~~~~
test.c:8:19: note: within this loop
    8 |     for (i = 0; i < 2; ++i) {
      |                 ~~^~~


$ gcc -O2 -Wall -Warray-bounds=2 test.c -c -o test.obj
test.c: In function ‘main’:
test.c:9:9: warning: iteration 1 invokes undefined behavior [-Waggressive-loop-optimizations]
    9 |         printf("%d\n", a[i]);
      |         ^~~~~~~~~~~~~~~~~~~~
test.c:8:19: note: within this loop
    8 |     for (i = 0; i < 2; ++i) {
      |                 ~~^~~
test.c:12:5: warning: array subscript 2 is above array bounds of ‘int[1]’ [-Warray-bounds=]
   12 |     printf("%d\n", a[2]);
      |     ^~~~~~~~~~~~~~~~~~~~
test.c:5:9: note: while referencing ‘a’
    5 |     int a[1] = {42};
      |         ^

Naimplementovat statickou kontrolu kodu, kdy se pro iterator ve for cyklu odvodi compile-time range by nemel byt probem, aby to chytlo tenhle pripad.

A pokud bude index odvozovan dynamicky (z uzivatelkskeho vstupu), tak to zachrani jedine runtime bounds check - ale to prijde s vykonnostnim omezenim. A stejne tak v safety critical kodu ten bounds check muzete pridat treba makrem, pokud nejste linej, pripadne pouzit C++ a pretizit [] operator a udelat si tam runtime kontrolu pri kazdem pristupu.

11
Windows a jiné systémy / Re:Mount v macOS rozbije Finder
« kdy: 04. 05. 2025, 16:25:24 »
Jop, ten issue #4 vytvoril kolega. A pak jsem prisel na to, ze z finderu zmizne slozka, kdyz je do nej namountovany virtualni FS. Pritom ostatni FS (fat/exfat) co jsou FSkit based (overeno pres mount) normalne funguji a slozka nemizne, objevi se na ni normalne jina ikonka - ze se jedna o mountpoint.

12
Pokud to bude pomale i v jinem distru, nebo treba instalaci win.. tak muze byt problem v chlazeni. Mam cca 10x vetsi pocet ryzen soc mrtvolek nez intelu, ve stavu ze se to ani nezapne. Kremik pak ma casto nejaky flek - jako kdyby se tomu vyparila pasta nebo co :D takze bych pro jistotu zkontroloval chlazeni - pokud pojde pasta/heatpipe tak bude throttlovat.

13
Vývoj / Re:Budoucnost Rust v embedded světě
« kdy: 04. 05. 2025, 10:54:49 »
Ono to neni zadne terno a nikdy nebude - RUST ma vyhody pro klasicke programovani, kde to dela kdejaky lojza ktery si nevidi za spicku nosu - resp. nema vubec poneti o implementacnich detailech a jak cpu/os funguje, ale ma/musi neco kodit. Takze ho pak doslova zachranuje prekladac, aby mu to vratil ze takhle ne kamo.

U embedded veci a hlavne tech, ktere jsou opravdu kriticke existuji coding practices / rules - napr. https://en.wikipedia.org/wiki/The_Power_of_10:_Rules_for_Developing_Safety-Critical_Code - aby se dalo tvorit i s tim co mame (tj s C), klidne si najdete videa na YT ktere se tohoto tykaji.. nektere jsou usmevne, kdyz autori zjisti nejakou novinku protoze tohle jim jako fakt nikdo predtim nerekl :D :D

Nemyslim si, ze ten hardcore embedded slevi ze svych standardu a presune zodpovednost z pravidel/lidi na pouhy prekladac. I v rustu jde napsat nesmyslny konstrukt (nekonecna rekurze) a proste to skonci padem ze dojde pamet.

A dalsi vec proc RUST v embedded ne: typicky mensi embedded zarizeni ma omezenou pamet a malloc/free tam neni bezna vec, takze ona ochrana kterou RUST prinasi je k nicemu. A jak uz bylo zmineno - existuji urcite knihovny ktere jsou hlavne v C, treba na hw akceleratory nebo nejakou overenou sw funkcionalitu. To zas musite includovat a jste zpet v klasice.

14
Windows a jiné systémy / Re:Mount v macOS rozbije Finder
« kdy: 02. 05. 2025, 11:37:01 »
Ahoj.
To je fakt zvláštní, že se do toho přidaného mountpointu nedá ve Finderu vůbec dostat. To spíš vypadá jako nějaký problém s právy, resp. mapováním uid, i kdy i v tomhle případě by ten mountpoint sám o sobě měl zůstat viditelný.

Neni to problem s pravy, protoze uzivatel tam pres shell/terminal vleze a jine aplikace to samozrejme taky vidi.


Nicméně ad-hoc vytvořit složku v /Volumes by s root právy jít mělo. Stejně tak tam na test připojit filesystém.
Tohle taky nefunguje?
sudo mkdir /Volumes/mountpoint

to prave nejde ani s rootem, read-only filesystem

15
Windows a jiné systémy / Mount v macOS rozbije Finder
« kdy: 02. 05. 2025, 10:29:02 »
Ahoj, řešíme jeden problém - při namountování virtuálního filesystému (přes FSKit) v terminálu je normálně dostupný obsah, ale ve Finderu je daný mountpoint neviditelný - prostě složka zmizne ze seznamu souborů. Objeví se ale znova po umountu.

Mountujeme to do obyčejné pod-složky v jiné složce, protože do /Volumes to zatím netuším jak dostat (to je read-only a mountpoint tam vytváří bůhví co).

Nějaký nápad proč se tak děje a kde hledat potíže či jak debuggovat co si myslí Finder?

(jiné aplikace při ručním nabrowsování do dané složky data vidí správně)

A pak - jaká magie řeší viditelnost mountů ve /Volumes ?

Stran: [1] 2 3 ... 196