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 - Wasper

Stran: 1 2 3 [4] 5 6 7
46
Hardware / Re:UPS pro malou spotřebu a dlouhý čas
« kdy: 04. 07. 2023, 14:36:57 »
Daleko raději bych měl zálohovaných DC 12V, ale to by chtělo mít po celém obydlí roztahaných 12V a maximum věcí napájet z tohoto DC rozvodu. To bych pak řešil jedním macatým zdrojem 13.7V, který bude napájet celý DC rozvod, ke kterému bude přes polyswitch připojená třeba velká trakční gelovka. Samozálohovací a bezpečný systém.
Tohle mi nepřipadá dobře, teda jestli nechcete mít po bytě roztahané měďěné traverzy jak na staré ústředně. Zatím to dělám jako Vy (autobaterka na staré UPS, utáhne to celé odpoledne, a pro nouzi ve stodole benzínový agregát), ale jestli budu dělat nejlépe solárem nabíjený DC rozvod, tak to bude někde kolem 48V nebo i výš.

47
Jestli vono to nebude spis tak, ze s vekem nam odchazeji chutove bunky... a dochazi trpelivost... a snizuje se tolerance veskereho BS...
Tohle vysvětlení jsem si taky dlouho představoval, nicméně návštěva bývalého kolegy, který se vykašlal na obor a začal farmařit to dokáže vyvrátit celkem zdařile.

48
Přesně tohle je řešitelné přes selinux, jedna z věcí, které umí, je když něco v kontextu např user_t spustilo binárku wget_exe_t tak aby to automaticky nahodilo kontext wget_t, zatímco při puštění z podezrelyprogram_t do nějakého restricted_t.
A každý z těch kontextů může mít jiná práva. Jediný problém je, že je to dost netriviální hračka.

49
Server / Linuxový souborový systém s línou deduplikací
« kdy: 30. 05. 2023, 15:08:53 »
Zdravim vespolek
Nemate prosim nekdo zkusenost/doporuceni, jestli existuje pod Linuxem pouzitelny filesystem, ktery umi deduplikovat data na nem, a da se realne pouzit/nekdo ho pouzivate?

O co jde - hraju si s neuronkama, prakticky kazdy projekt ma jine requirementy (uz jsem rikal, ze nenavidim ekosystem kolem Pythonu?) a vysledkem je dost pres desitku venv-u, ktere jsou z vetsi casti hodne podobne, a jen mamuti jako pytorch uziraji tretinu disku, coz je dost nemile.

Jako last resort mam programek, co prochazi disk a kdyz se shoduje sha256 tak ze 2 fajlu udela pres hardlink jeden, ale jestli to jde nejak elegantneji, tak se rad priucim a zkusim neco noveho.

50
Software / Re:iOS 16 a non-trusted intermediate CA
« kdy: 12. 05. 2023, 22:44:12 »
Co máš v X509v3 Authority Key Identifier toho root.cz? Je tam DirName ukazující na tu root CA ca.moje.org+její serial nebo jen keyid té squid.moje.org?
Ale bez tohoto by mělo asi řvát i vše ostatní.
V mluvě OpenSSL x509v3_config:
authorityKeyIdentifier = keyid, issuer:always
Hmm, diky, dobry hint, jdu si hrat

V koncovem certu je jen authorityKeyIdentifier = KeyID (sedi)

u intermediatky:
authorityKeyIdentifier = keyid:always, issuer:always
a je v ni Dirname, KeyID i Serial (a sedi)
subjectKeyIdentifier = keyid

51
Software / iOS 16 a non-trusted intermediate CA
« kdy: 12. 05. 2023, 20:25:44 »
Zdravím,
rád bych se zeptal, jestli někdo nemáte zkušenost s následujícím problémem.
Mějme privátní CA, dejme tomu ca.moje.org - ta je importnuta do trust store, a je označena jako trusted root CA (Settings - General - About - Certificate trust setting).
Mějme web, podepsaný touhle CA - řekněme web.moje.org. Ten funguje v Safari perfektně.

A pak mějme nějakou proxy, která přebaluje SSLko. Proxy dostala vlastní CA certifikát, dejme tomu squid.moje.org. Když vlezu odkuďkoli na třeba root.cz, tak je vše v pořádku, trust path je následující:

ca.moje.org -> squid.moje.org -> root.cz

Problém je, že to funguje odevšuď, z Win, z Linuxu, dokonce včetně star39ho iPhone s iOS15, ale ne v iOS16, ten mě tvrdohlavě tvrdí, že "not trusted" a já nemůžu přijít na to proč (on to nepoví). Standardní hledání po netu nikam nevedlo, odpovědi jako "nastav tomu trusted" moc nepomáhají když to evidentně trusted je (viz ten test s web.moje.org).
Pokud ale vygeneruju pro squid samotnou self-signed CA a tu importnu, tak to ale začne fungovat.

Nemáte prosím někdo s tímhle zkušenost? Nějaký chybějící nebo přebývající attribut/extension?

52
Server / Re:Smysluplnost "aliasů" v hlavičkách To,Cc
« kdy: 29. 04. 2023, 19:10:04 »
Chtěl bych zde kriticky a revisionisticky probrat užitečnost, a smysl "Jmen" v jednotlivých příjemcích v e-mailové zprávě (MIME Message) v hlavičkách To,Cc,Reply...

Jde o : To: "Petr Pavel" <ruskytrol@media.ru>, Petr Paul <petr@pavel.cz> , "£1b0r Obusek" <chiucpebomber@xgs.cz>, milenka  <zlata@adamovska.cz> (to byl jen příklad)

Dává to v dnešní době smysl?
Ano.

Citace
0. Je to k nečemu dobré reálně?. Odesilatel tuto informaci nepotřebuje, resp. není potřeba ji cpát do přenášené zprávy. Pro Příjemce to může mít jistou, diskutabilní hodnotu
A pro odesilatele?

Citace
1. Je správná aby MSA hlavičku To: vyčistil? (nechal jen <a@b.dom>)
Proboha proč? "Vašek Novák" <3e9abn@duck.com> prostě nechce, aby každej troll a bot viděl jeho skutečný mail popř. když už mu ho zneužije, tak aby ho mohl rychle zablokovat, ale chce aby ostatní věděli, kdo to je.

Citace
3. Jak se k tom ustaví MUA(programy), když příjemce má kontakty uložené pod jiným jménem?
Outlook to matchne podle email adresy, jinak asi co agent to jinak.

Citace
nemůže to sloužit k fingerprintingu, jelikož jednotlivé páry jméno-mail nesou jistou entropii.
Proboha proč? Co by mělo být výsledkem onoho fingerprintingu? Jakou další informaci by ten fingerprinting jako měl získat?
Prostě tím říkám, že jsem Franta Vocásek a když mi někdo bude chtít poslat mail, tak technicky musí použít adresu fvocas@evil.org. Nic jako entropie (čeho?) nedává smysl.


53
To tě ale ve vztahu k doručovacím službám vůbec nemusí zajímat, protože je čistě jejich věc, jak mají svoje systémy udělané. A zcela jistě ty systémy počítají jak s nedostupností signálu díky pokrytí, tak třeba při výpadcích.
Třeba žehličkou? ;-)

Citace
Už z důvodu bezpečnosti se doručovací služby na jakékoliv veřejné či jiné WiFi obvykle nepřipojují a využívají jenom data nebo případně WiFi ve svých vlastních provozovnách.
Jaké bezpočnosti?! On někdo svéprávný ještě dnes považuje internet jako takový za bezpečný? Je rok 2023 a né 2003, máme DNSSEC, TLS, VPN a další cizí zkratky...

54
Vývoj / Re:Jazyk pro ML
« kdy: 03. 04. 2023, 08:16:51 »
Trochu OT ,ale dnes existují projekty, které mají perfektní dokumentaci v tom smyslu, že bloky kódu v postupu
mají nahoře ouška s nabídkou bash/node/Pascal/python/
Hezké. Když mám python3.11 a chci použít PyTorch, tak to ouško mi prosím pěkně pomůže v čem?
Stejně jako když mezi pytorch a torchvision se tak jako změní API kolem resnet50_weights.

Citace
Co je binární wheel?
https://realpython.com/python-wheels/#telling-pip-what-to-download

55
Vývoj / Re:Jazyk pro ML
« kdy: 02. 04. 2023, 23:25:03 »
bohuzel ve svete AI a ML se pythonu utect neda.
tady C(++) neni idealni - to rikam s tim,ze osobne Python nesnasim.
Nejvtipnější na tom celém je, že to, co reálně počítá, tak je C/C++, ten Python to převážně jen lepí dohromady.
Takže spíš jde o kompatibilitu s kolegy než o nutnost per se.

56
Co já vím, tak Komerčka vyžaduje nejprve zadání uživatelského jména. Hned pod tím je souhlas se zapamatováním údajů pomocí cookies. Následně chce telefonní číslo a pak ověření pomocí klíče...
Takže, patrně, když nedáš souhlas s cookies, musíš při dalším prihlášení projít toto celé znovu. Když souhlas dáš a cookies nevymažeš, může být ten krok příště přeskočen.
Já předpokládám, že to tam (cca nedávno) přidali proto, aby když se někdo (dictionary) trefí do username, tak aby to hned neotavovalo majitele účtu SMSkou/appkou, takže jakási forma slabé předautentizace.

Tomu by odpovídalo, že "trusted" prohlížeč tohle už nedělá.

IMHO tím řešili v loňském roce docela rozšířené útoky.

57
Vývoj / Re:Jazyk pro ML
« kdy: 02. 04. 2023, 18:37:13 »
Citace
Jsem asi už starej na to, abych Python ocenil. Z těch nemnoha setkání si pamatuju v jeho historii jakési kotrmelce "doprovodné infrastruktury" (package management), na které se mi trochu těžko zapomíná.

To bolo kedysi. Dnes má Python package management vyriešený. Funguje to bez problémov.
Citace
Kéž by. Teprve ve chvíli, kdy se něco nevede tak, jak by mělo, tak člověk začne přicházet na to, jaký Goldbergův stroj pod tím "vyriešený" vlastně existuje.

Takže pár rantů:
- na úplném začátku mi zkušený kolega řekl, ať používám venv. No velmi brzy jsem pochopil, proč.
- pip už konečně umí upgradnout celý projekt?
- python3.11 není kompatibilní s 3.10, nebo "Currently, PyTorch on Windows only supports Python 3.7-3.9;" - wtf? Jako py2 vs py3 chápu, ale rozbití back kompatibility v 3.xx řadě?
- část projektu se dělá (doporučuje dělat) přes condu, část přes pip, a není to jen úlet, spíš pravidlo.
- sranda, když má člověk openssl, libgd, ... v systému, a ono mu to během instalace prerekvizit začne sosat privátní kopie do environmentu.
- když z nějakého důvodu binární wheel nedělá úplně to, co má, to teprve pak nastává veselí.

58
Zařízení uváděná na trh by měla splňovat požadavky na EMC/EMI, aby se vzájemně nerušila. Samozřejmě realita ...
Přesně. Co dělá vlastně ten mobil? Vysílá po krátkých dávkách, někde v pásmu 700MHz - 2.4GHz. Na rozdíl od WiFiny, která má pár mW, je to (podle podmínek příjmu) až do 2W (platí to pořád? I když i 5G mobily mají 2G fallback). Co se stane, když se to přiblíží špatně stíněnému zařízení? No každý vodič, každá ploška na plošňáku se stane anténou, a bude to přijímat. Takže u digitálu to v klidu může udělat z nuly jedničku a naopak, u analogu, když se to dostane na nelineární polovodičový přechod, tak i když ta součástka takhle vysoké frekvence nezvládne, minimálně to posune pracovní bod. V NF to bude dělat známý bordel (z každého polovodiče po cestě se stane AM demodulátor), ve VF to může užitečný signál vyrušit, fantazii se meze nekladou.

Smazat to data na disku přímo nemůže, jak už bylo řečeno několikrát, nepřímo, pokud se zblázní elektronika disku, tak se stát může cokoli :). Zničit elektroniku to přímo také nemůže, ten výkon který projde vzduchem je příliš malý aby to tepelně poškodilo přechod. Nebyl bych si jistý u špatně navrženého (a neodstíněného) pulsního zdroje, dobře mířené sepnutí IGBT ve správnou chvíli může být fatální, ale opět, na to jsou normy EMC, aby se tak nedělo.

tl;dr: Pokud jsou ostatní zařízení správná, nemělo by to vadit, ale k otevřenému kompu bych to nedával.

ad popsaný případ - nešlo o pravý opak, slabý signál (třeba vypadla blízká BTS) -> špatná slyšitelnost a vysoký vysílací výkon -> ruší to více než obvykle?


P.S. tenhle topic je naprosto ukázkový. Někdo neznalý se na něco zeptá, a polovina lidí místo rozumné odpovědi si z něj dělá srandu. A pak se divíme, že si někteří lidi najdou "pravdu" jinde a pak choděj bourat 5G věže. Ach jo.

59
Tak protože bývá zvykem, pokud se podaří problém vyřešit se podělit o výsledek, tak jsem tu.
Celý problém byl nakonec v Nvidia GTX1650, která by správně měla umět fp16, ale neumí. S původní kartou se vše rozběhlo (před chvílí, tehdy jsem to vzdal) se switchem --fp32.

To vysvětluje i to, že nic z výše popsaných problémů nebyl problém distribuce. Ach jo, alespoň error to napsat mohlo...

60
Ty programy pod XP jsou x86...
A to je problém? Už to z hlavy nedám přesně, ale XP pokud se nepletu maj CSRSS.exe coby 32bitovej subsystém a WOW64 v případě 64bit a normálně to koexistuje, klidně i s WOW což byla vrstva pro staré už nevím jestli 3.xx nebo přesně. Někdo znalejší mě doufám opraví.

Stran: 1 2 3 [4] 5 6 7