Příspěvky

1

Hardware / True RMS měřák s přepínáním

« kdy: 21. 03. 2023, 13:46:41 »

Když mám True RMS měřák, je možné ho(teoreticky) přepnout do ne-True_RMS režimu ? Existuje nějaký takový?

čili sématicky : True rms vlastnost je "umí" nebo "je"

Připodobnění: jsou true rms a ne-true-rms měřáky ve vztahu
★802.11ac - 802.11g ("ac" jde jen na 5GHz a g na 2.4GHz, tudíž nejsou interoprabilní)
nebo
★802.11n- 802.11b ("n" umí pár věcí navíc oproti "b", ale dokáže i "b" samotné)


(obráceně asi, to snad vyplývá z logiky věci, něco jako přenášet USB 3.0 přes USB 2.0)

A vůbec, je tato vlastnost true rms pro napětí a proud společně?
Je true rms jen pro AC proud nebo i AC napětí? (vždy jsem o tom slyšel e spojení "true rms ampérmetr)
v

2

Odkladiště / Re:Obsluha relací u klienta nebo na serveru

« kdy: 20. 03. 2023, 13:53:26 »

Aha,omlouvám se za nedoruzmění, vzniklo zestručněním.

Platí buď a nebo. "

Dřív to fungovalo  na způsob client side (cookies) session handling .
 Nová verze změnila session handling na
server-side session handling"

3

Odkladiště / Obsluha relací u klienta nebo na serveru

« kdy: 20. 03. 2023, 01:35:44 »

Co se myslí server-side - v následujicim kontextu?

client side (cookies) session handling
server-side session handling


Je to JWT potažmo tokeny? Pokud ano, proč jedno je  s přídomkem client a druhé server? I nacookies se dá definovat že je server based (musí mít server někde uloženy asociace »phpsessid« hodnot). (Analogie: amerika taky na gløbusu může být východ a sssr západ) 


(Mimochodem je nějak signifikantní  rozdíl v požití mezery v prvním a pomlčky v druhym?)

4

Server / Re:Při absenci MX záznamu:doručení na A~doménu OK,ale na AAAA~doménu NE

« kdy: 17. 03. 2023, 22:59:58 »

TLDR: z novější verze RFC se vytratila definice "implicit MX" a  zmínka  "A RR is found"  je zaměněná na implicit MX

mě právě zajímá důvod, proč pro AAAA tohle nejde, zda to je nějaké vůle providerů, bestpractice, má to nějaké racionální důvody nebo jaké to má důvod. Nebo že když v posledním RFC bylo "A RR" a v novém RFC se už v dané pasáži slovo RR nevyskytuje a implicit MX není definované, tak postmástři si nevěděli co počít?
Jeden by čekal, že když tento "fallback" bude fungovat pro A záznam, tak i pro AAAA (a připomínám, zkoušel jsem oddělené domény 3.řádu)

Tady smtp rfc[/url]

To je pěkné, ale v aktuálním RFC 5321(stačí v dolním linku zaměnit 2821 za 5321, ale to jen pro pořádek dnes jsou lidi, co neví co je odkaz, že se kromě kliknutí dá z něj získat bazální hodnota URL a že link má href a že se URL dá upravit, věřím že vy ne) jsem nenašel definici implicit MX  a hlavně je zaměněno  "if A is found"  na " if no MX"Tady je ta pasáž

If an empty list of MXs is returned,

the address is treated as
if it was associated with an implicit MX RR, with a preference of 0, pointing to that host

V 2821:

If no MX records are found,
but an A RR is found,
 the A RR is treated as
   if it was associated with an implicit MX RR, with a preference of 0,
   pointing to that host

RFC 2821 obsolete

5

Software / Menší úprava části videa bez nutnosti překódování

« kdy: 17. 03. 2023, 22:24:35 »

=>
  string(1602) "Modelová situace: mám hotový  mp4/mkv()např hevc,h264) soubor s videem (tedy zdrojové klipy nemám , ani verzi v vyšším rozlišení) o délce 4800 sec a chci v části 3020-3030s  přepsat jiným videem (například aktualizace inforgrafiky), část 3230-3240 uplně smazat a na pozici 2720 vložit jiný 20sec klip

Jde to udělat tak,anichž by celé 4800s muselo procházet/ecodovat celé?

Tím myslím něco na způsob ffmpeg -c copy.

Jde to udělat na úrovni kodeku  nebo kontejneru? a který kontejner to umí? Napadá mě mkv, umí nějak slepit /navinout části klipů nebo nejdebože do jedné timeline vložit víc videí(tím by dotaz odpadl skoro) , pokud i tohle,musí mít stejné rozlišení fps, kodek? Nebo i stejné parametry enkodéru

Pokud je potřeba znát parametry enko´déru, dají se kompletně zjistit z mkv  a z mp4? Co znám,tak mkv obashuje nějaká metadata kde jsou argumenty x264, ale umíto i mp4? Jdou pak parametry enkodéru nějak rekonstruovat?


Pokud ano, je k tomu potřeba znát třeba parametry příkazové řádky ffmpeg,x26*?

Pozn: toleruje se nepřesnost kvůli klíčovým snímkům nebo GOP.(že to bude třeba useklé dřív nebo to část nahrazená později, jde o proof of koncept - dá se řešit že nahrazující klipy by obsahovaly i orig.video v reálu) Vím že někdy může dojít k časové nepřesnosti: buď při zrychleném seeku a nebo při  vytváření odvozeného klipu( úsek 3-8s z 20sec klipu)  a ještě v případě podmínky zakázaní re-encodování.(ta zde v dotazu  platí taky)

6

Server / Při absenci MX se nedoručí na AAAA

« kdy: 17. 03. 2023, 21:02:34 »

Zdravím,je nějak definované,jak doručit mail na doménu(za zavináčem),která nemá MX záznam?

 Je to nějak standardizované a děje se v praxi,že se zkusí "fallback" na A záznam,když tedy MX není? Tuším, že v RFC to je zmíněné, ale nevím jak moc MUST,SHOULD,MAY a nevím jestli toto rfc bylo aktualizované pro IPv6

K jádru dotazu, Platí totéž i pro IPv6 (tedy když nemá MX, ale má jen AAAA)?

Mám jen jeden vzorek dat (jeden outbound) a výsledek,že v případě  poslání doménu (třetího řádu)s jen "RR:A" mail přijde
ale v případě poslání na doménu s jen "RR:AAAA" se vrátí jako PermError - no valid mx Record



(Otázka míří na sending side.Předpokládá se,  že na straně příjemce nezáleží, příjemcův SMTP server na IPv4 a IPv6 adresu tuto poštu ochotně přijme.Vlastně nikde ani není dáno že musí jít o téhož přijemce, může jít o 2 příjemce,které spolu nesouvisejí, ale první doména má jen A RR, druhá AAAA RR)


Případně,je nějaký dobrý vysvětlení, proč v případě jen-A záznamu  ji doručí,ale pro jen-AAAA doménu se vrátí jako nedoručitelná-noMXchyba

7

Distribuce / Re:Jaká verze Ubuntu na starý Asus Eee

« kdy: 17. 03. 2023, 16:31:27 »

Přínosné poznámky k3dAR... 👍
Aby tazatel měl obrázek, dodám, že smartphone střední třídy dokáže plynule v browseru* stahovat a přehrávat 1080p60fps video a to vše při 500mA spotřebě (displej bude třetina...) 1-cell Li-pol baterky 4V(neměl jsem spuštěný htop a až teď mě napadlo ho spustit vzdáleně  přes sshd v telefonu, ono by to šlo na split screen, ne že ne)


* URL je přímo mp4 soubor ; z youtube to taky zvládne, ale u toho jsem nezkoumal spotřebu


Pochybuji, že tohle ten křáp zvládne, ten výkon je fakt žalostný. A spotřeba nebude pod 2W....
(jasně že akcelerace je klíčové slovo)

8

Hardware / Re:hučení do hardisku

« kdy: 16. 03. 2023, 18:12:29 »

https://www.youtube.com/watch?v=tDacjrSCeq4

K jakému roku se to video datuje? platí to i dnes?

K tomu mě napadlo, že něco podobného jsem asi někde četl nebo viděl, že je možnost nějak odstřelit HDD nějakým zdrojem zvuku nebo co? Nevím co to bylo.... jestli Ultrazvuk nebo obyčejný vibrace mobilu..

9

/dev/null / Re:význam dat v play.google.com/log

« kdy: 16. 03. 2023, 17:38:50 »

No to podle tě asi  vakcíny v sobě maj 5G čipy co vysílají na frekvence mozkových vln...
Důchodce a paranoidy si dělej z někoho jínýho ... 
jednak firefox nemá oprávnění k GPS, za takové údaje se v mém telefonu nevyskytují(kromě historie, přístup- údajů k  ruzným werbům *)

Nebo to jsou nějaké koordináty Math:GeoRandom(), údaje nějaké náhodné platební karty, a útržky kůže peněženky nějakého náhodného člověka nebo přístupové údaje co si javascript webu google vymyslel? To by mě trochu uklidnilo. Myslíš ty údaje co jsi vyjmenoval jsou moje přímo nebo náhodné? Jaká by to podle tě mělo důvod posílat na play.google.com/ takovéhle náhodné údaje?

jelikož já ( mobilu(číslo(kreditní kartu))) nemám ani bitcon(ovou pěněže nku)


Jak bys "smazal" "data-in-(wannabe)-transit" ?

*ale když si vezmeme ty přístupové údaje na ruzne werby, vždy než se vyplní, firefox ukáže dole zámeček a bez kliknutÍ se nevyplnÍ

10

Server / Re:Nefunkční mailserver s Postfixem

« kdy: 16. 03. 2023, 11:24:07 »

Znáte někdo to  ten  mailserver ve formě hotového balíku(či docker) jako mailcow, poste pro platformu 32bitový ARM?(armv7l)


Ta neexistence PTR není vyloženě stopka. Neškrnete se stím  na microsoft(hotmail i hoste) a centrum + na "domácích instalacích", akademických appliancí, ale na seznam , google(gmail i hosted) se doručit dá. (Čímž neříkàm že je vyřešeno, jen předkládám osobní statistiku)

11

/dev/null / význam dat v play.google.com/log

« kdy: 15. 03. 2023, 22:08:43 »

Zde jsem na to upozornil. Zapomněl jsem zmínit, že se to páchá i na youtube.com
 Během 7 min na stránce minut 16 pokusů o odeslání v časech 7s, 35s, 2min,4,5


Některá pole se mění (typicky timestampy začínačící 16789), pak se mění čísla v párech [null,float nebo nula], magický string (\"O43z0dpjhgX20SCx4KAo\") zůstává. Ale zkoušeno jen na jednom pageview.
Jaký je význam?

Kód: [Vybrat]

[[1,null,null,null,null,null,null,null,null,null,
[null,null,null,null,"cs-CZ",null,"9",null,null,[1,false]]],1654,
[["1678913564561",null,[],null,null,null,null,"[[[\"/client_streamz/po/w/cec\",null,[\"ec\",\"rk\"],[[[[null,11],[\"O43z0dpjhgX20SCx4KAo\"]],[2]],[[[null,14],[\"O43z0dpjhgX20SCx4KAo\"]],[1]]],null,[]],[\"/client_streamz/po/w/el\",null,[\"en\",\"rk\"],[[[[\"q\"],[\"O43z0dpjhgX20SCx4KAo\"]],
[null,0.19999980926513672]],[[[\"S\"],[\"O43z0dpjhgX20SCx4KAo\"]],[null,0.7000007629394531]],[[[\"r\"],[\"O43z0dpjhgX20SCx4KAo\"]],[null,2893.199999809265]],[[[\"y\"],[\"O43z0dpjhgX20SCx4KAo\"]],

[null,0.09999942779541016]],[[[\"e\"],[\"O43z0dpjhgX20SCx4KAo\"]],[null,0.7999992370605469]]],null,[]],
[\"/client_streamz/po/w/rl\",null,[\"mn\",\"ac\",\"sc\",\"rk\"],[[[[\"c\"],[null,1],[null,2],[\"O43z0dpjhgX20SCx4KAo\"]],[null,3.3000001907348633]],[[[\"c\"],[null,2],[null,2],[\"O43z0dpjhgX20SCx4KAo\"]],
[null,1.9000005722045898]]],null,[]],[\"/client_streamz/po/w/csc\",null,[\"cs\",\"rk\"],[[[[null,3],[\"O43z0dpjhgX20SCx4KAo\"]],[1]]],null,[]]]]",null,null,null,null,null,null,-3600,null,null,null,null,[],1,null,null,null,null,null,[]]],"1678913585043",[]]:
hlavičky
X-Goog-AuthUser: 0

Co ty údaje znamají a proč je jejich komplicem doména play.google.com?

Call chain je povětšinou v youtube.com/.../base.js , funkce: g.k.send, xfa,$fa,r, g.k.flush, g.k,G.K,oba,a

Ale hledat něco v 624kB minifikovaného javascriptu to nevím,,, nevím, před spaním raději preferuji penetrační testování internetových bankovnictvích případně válení sudů po střepech na chodbě olomoucké hospody v fotbalovém dresu sparty

12

Windows a jiné systémy / Re:Přenesení dat aplikace mezi telefony

« kdy: 15. 03. 2023, 17:05:46 »

ta pri dohlednai v Play to samozrejme videt je okamzite v url ;-)
https://play.google.com/store/apps/details?id=app.diary

Já ale nemám potřebu navštěvovat  play.google.com, dokonce ho mám zablokované v DNS, jelikož  z webových browserů webové stránky vyhledávače" google.com", dokumenty google "docs.google.com"
 a další z nějakého prapodivného důvodu periodicky odesílají v pravidelných intervalech (desítky s) XmlHttpReqeusty s nějakým binárním smetím
 na play.google.com/log

Proto jsem tuto celkem logickou akci (najít na google play název aplikace a podívat se do URL) neudělal.

13

Server / Re:Google, Seznam vs. domácí server

« kdy: 11. 03. 2023, 13:06:48 »

. Typicky virusfree.cz mají většinou špatně nastaveny DKIM podpisy (délka klíče a parametr t). To se pak zákazníci diví!

Fun fact, ještě víc než zákazníci se diví ti, co jim chtějí napsat.

14

Server / Re:Náhrada SMS brány Vodafone

« kdy: 11. 03. 2023, 13:05:28 »

Ročně kolem 15 tisíc sms.

a kolik takovéhle množství srandy stojí? Méně než 22500 Kč?

15

Sítě / Re:Přestal fungovat internet na Linuxu

« kdy: 11. 03. 2023, 13:03:43 »

                 --flush   -F [chain]          Delete all rules in  chain or all chains

pouze odhaduju:
TIpl bych še sis nainstaloval nějaký firewall a  ho nastavil že blokuje
Je to divné,  přidaná pravidla(příkazem) do iptables nepřežijí restart


chtělo by to udělat inventář firewallů, ufw,iptables, nftables, a tak