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 - Jakub Štech

Stran: 1 ... 4 5 [6] 7 8 ... 22
76
Ale stále zůstává nezodpovězena otázka, jak ty architektonické dovednosti ověřit v rámci 1-2 hodin.

To je právě pointa moje a dalších tady: nijak. Nejde to. Někteří si nalhávají že jakoukoliv směrodatnou indicii o kandidátově vhodnosti vydestilují z toho, jak rychle nebo elegantně napíše na papír algoritmus pro rebalancing rb-stromu nebo vyjmenuje pořadí operátorů v C, ale je to jen placebo pro recruitery.

Ať jen neplácám, dobrého člověka přivedete jen podle reputace. Ať už je reputací něčí doporučení nebo třeba bohatě zdokumentovaná kariéra ve free software projektech. Myslet si že něco tak komplexního zanalyzujete jedním dotazníkem a pár hodinami pohovoru je naivní.

77
Čas za jaký kandidát uběhne 100m sprint se taky ojebat nedá a přesto se shodneme že to je u softwarového inženýra irelevantní metrika :-)

78
To tam máte pěknou marži, CZC to prodává za 9200 :-) mimochodem záruka je v ČR nepřenositelná, v praxi lze uplatnit jen podvodem, tj. že se nový majitel bude vydávat za originálního kupujícího. Což u čím dál víc obchodů nejde, protože RMA proces vyvoláváte ze svého účtu (např. Alza).

79
Sítě / Re:Jak umlčet televizi způsobující DoS 60 p/s
« kdy: 07. 03. 2022, 09:57:05 »
Ideální je TV nemít vůbec, vzít LibreELEC a k tomu připojit monitor. Vyhnete se tím povinnosti platit ČT, nevtahujete si do domu kdovíjaký malware a i spotřeba je menší. Různé firmy se pravidelně zbavují velkých 24/7 displayů z digital signage a konferenčních aplikací. Očekával jsem otřesnou kvalitu obrazu ale ukázalo se, že v tom jsou docela slušné IPS panely. Nevýhodou (pro některé) je obvykle absence vestavěného zvuku.

80
Na primáru dělejte co dvě hodiny snapshoty (btrfs, zfs, lvm), jejich diffy oproti předchozímu snapshotu posílejte na repliku, kde to rovnou aplikujte na živý filesystem. Něco jako:

Kód: [Vybrat]
# tohle v cronu na primáru jednou za 2h
btrfs subvolume snapshot -r / /mnt/backup/snapshots/123
btrfs send -p /mnt/backup/snapshots/122 /mnt/backup/snapshots/123 | gzip > /mnt/backup/temp/122-to-123.gz
scp /mnt/backup/temp/122-to-123.gz replika:/mnt/backup/incoming/new.gz
rm -f /mnt/backup/temp/122-to-123.gz
btrfs subvolume delete /mnt/backup/snapshots/122

Kód: [Vybrat]
# tohle v systemd.path triggeru na replice, čekat na /mnt/backup/incoming/new.gz
gzip -d < /mnt/backup/incoming/new.gz | btrfs receive /mnt/backup/replica
rm -f /mnt/backup/incoming/new.gz

V /mnt/backup/replica bude vznikat chronologická řada snapshotů se stejnými názvy a obsahem jako na primáru, a narozdíl od rsync je to atomická operace.

81
Nastavte si rootfs read-only a ten, kdo zapisuje, se s tím buď smíří, a nebo se přihlásí sám :-)

Provozujeme takhle tisíce systémů, na rootfs je od nabootování 0 B trafficu klidně rok.

82
Odkladiště / Re:Vyskočení chrániče likviduje elektroniku
« kdy: 26. 02. 2022, 19:26:37 »
Může to být dokonce na jiném chrániči! Jestli máte topologii rozvaděče klasicky

elektroměr fáze -> hlavní vypínač -> chrániče -> jističe -> kabely do domu
přívod nulák -> chrániče -> nulový můstek -> kabely do domu
přívod zem -> můstek -> kabely do domu

, tak stačí kdekoliv propojit N+PE, a máte vytvořenou cestu kolem všech chráničů. Protože všechny N a všechny PE máte spojeny do jedné "mědi". Pak je to už jen o tom, který chránič má trochu vyšší citlivost, nebo jinou teplotu, nebo je někde moc/málo utažená svorka atd.

83
Odkladiště / Re:Vyskočení chrániče likviduje elektroniku
« kdy: 26. 02. 2022, 16:28:58 »
Ještě mě napadlo – nemáte někde v domě pár kabelů bez osazených zásuvek "na budoucnost", které někdo chytře bezpečně zakončil např. wago svorkou "do zkratu"? Zažil jsem situaci, kde někdy (ne vždy) po zapnutí silnějších spotřebičů (varná konvice, vysavač) vybavil chránič.

Dlouho jsme nemohli přijít na důvod, až jsme nakonec našli v liště skrytý kabel CYKY zakončený třísvorkovou wago do zkratu. Autor to udělal kvůli bezpečnosti, aby nešel zapnout příslušný jistič... ale tím, že spojil do zkratu všechny tři dráty propojil i N a PE. Když se soustava zatížila větším spotřebičem, úbytek napětí na vedení vyvolal v rozvaděči několikavoltový potenciál mezi N a PE, proud tekl tímto kabelem do wago svorky a zpět, to překonalo mezní proud chrániče a bylo hotovo.

84
Odkladiště / Re:vyskoceni chranice likviduje elektroniku
« kdy: 25. 02. 2022, 13:30:03 »
Vybavení chrániče by určite nemělo s sebou vzít i jističe, to podle mě poukazuje na nějakej problém v zapojení, např. uvolněná svorka nuláku někde v rozvaděči. Souhlas s hodnocením velkých pánů z elektriky.cz, takhle agresivně arogantní komunitu jen tak někde nenajdete.

85
/dev/null / Re:potrebujete "nove" fonty?
« kdy: 29. 01. 2022, 20:44:25 »
Krásný objev, ale většina z nich bude na dnešní poměry moc omezená... chybí diakritika, nebo dokonce emoji a tak. Jsou ale moderní bitmapové fonty bez těchto nedostatků :-) např. Cozette.


86
Dejte hash nebo nějakou jeho část do názvu souboru, např.

$ sha512sum "17bd629f8f703109 precious-memories.zip"
17bd629f8f703109b3a494b4cab571069a49cffe7eb6696fa1ab3d034b4efbd59b6f181c82dca123d2ae3a7811123e30270531dbb558c33f6b6fb71344251e76  17bd629f8f703109 precious-memories.zip

Vyberte hashovací funkci, která je na zamýšlením hardwaru nejrychlejší... u mě (Aarch64 NAS) takto vyšel blake2s.

87
V čem? Já se v GDM přihlásím normálně jedním nebo druhým.

88
Hardware / Re:Kapacita baterky neodpovídá
« kdy: 21. 12. 2021, 19:07:05 »
V té tabulce jsou uváděny limity nabíjecího proudu (proto Max). Interpretujte to jako "pod 26 °C musím omezovat nabíjecí proud" a nabíjejte baterii v normálních podmínkách, vydrží podstatně déle.

Co se těch čísel, která dostáváte od Linuxu, těm se v podstatě nedá věřit. Nepíšete sice co za přístroj a fuel gauge chip tam máte, ale většina z nich je mizerná i s kalibrací, kterou ve většině případů stejně nemají. Např. na PinePhone je obvod AXP803, který sice celkem přesně měří proud (a integruje miliampérhodiny), ale procenta počítá jakýmsi proprietárním algoritmem, který zohledňuje i napětí baterie a aktuální zátěž, a je prostě špatně, protože se chová zhruba jako co popisujete.

89
2.) komprese gzip  dd if=/dev/sda of=/dev/null bs=1/2/4M | gzip -1/-9 >/jinydisk/outfile.out

Co tady tou inkantací přesně myslíte? dd čte /dev/sda, posílá to do /dev/nullu, a jeho stdout (na který neposílá nic) komprimujete... tedy měříte rychlost gzipu na stojící rouře.

90
Hardware / Re:Přesnost Arduino váhového senzoru
« kdy: 04. 12. 2021, 17:06:20 »
U těchto snímačů je mnoho problémů které přesnému vážení brání. V datasheetu uváděné hodnoty udávají chybu měření (chyba linearity, opakovatelnost, drifty a teplotní ovlivnění) 50 až 100 gramů, takže na setiny gramu se s tímto dostat nedá.

Dalším neduhem tenzometrů je tečení, kdy se při stálé zátěži těleso snímače postupně deformuje, třeba v horizontu dnů, týdnů. Nelze je trvale zatížit.

A i když budete mít excelentní laboratorní tenzometr za pár tisíc USD, se kterým se na ty setiny gramu dostat dá, problém se přenese na stranu elektronickou, kde budete potřebovat velice přesně a opakovatelně měřit mikrovolty (v prostředí kde indukovaný a kapacitně vázaný šum je v desítkách milivoltů), což opět bude stát hodně peněz.

Stran: 1 ... 4 5 [6] 7 8 ... 22