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 - Ħαℓ₸℮ℵ ␏⫢ ⦚

Stran: 1 ... 6 7 [8] 9
106
Hardware / Re:Čím čistit matnou obrazovku?
« kdy: 21. 12. 2021, 11:57:26 »
Když se zeptám laicky, měla vy okena vadit? Předpokládám že jde o stejný materiál ale jen s "hrubou strukturou" a žádná antiROFLexní vrstva tam není (na matné - jaký význam)

107
Hardware / Kapacita baterky neodpovídá
« kdy: 21. 12. 2021, 11:48:31 »
Na smartfounu bych měl mít 4Ah baterku,přesto ale systematicky delší dobu pozoruji že podle výpisu nabíjení má spíš poloviční kapacitu (srovnáním proudu a procent nebo za nějakou dobu)

Telefon mám 2 roky (model starý 2.5 roku) , používal se ale poslední rok jenom. Baterku netůruji, nabijim v chladu, proudem do 1.5A (max umí 2.3) a ne na 100% (většinou)

Je to nějaká chyba měření nebo to skutečně má menší kapacitu? A je to reálné že takto by se snížila?

Paradoxně nepozoruju že by výdrž telefonu byla nějak nízká.


Kód: [Vybrat]
# 1%  ... 40mAh , řádek refresh 120s
#údaje z /sys/class/power/battery/ : voltagenow currentnow temp capacity

3700 mV   13°   -256 mA   50%
 4183 mV   14°   1104 mA   54%
 4194 mV   15°   1097 mA   56%
 4214 mV   15°   1145 mA   59%
 4226 mV   15°   1147 mA   61%
 4166 mV   16°   585 mA   64%
 4250 mV   16°   1158 mA   67%
 4260 mV   16°   1157 mA   70%
 4268 mV   16°   1141 mA   72%
 4279 mV   16°   1141 mA   74%
 4289 mV   16°   1149 mA   76%
 4299 mV   16°   1146 mA   78%
 4307 mV   16°   1138 mA   80%
 4317 mV   16°   1138 mA   82%
 4326 mV   16°   1132 mA   83%
 4335 mV   16°   1130 mA   85%
 4346 mV   16°   1134 mA   86%
 4356 mV   16°   1122 mA   87%
 4362 mV   17°   1131 mA   89%
 4374 mV   17°   1119 mA   90%
 4388 mV   17°   1111 mA   91%
 4388 mV   17°   1043 mA   92%
 4389 mV   16°   977 mA   93%
 4389 mV   16°   921 mA   94%
 4389 mV   16°   874 mA   95%
 4389 mV   15°   825 mA   96%
 4322 mV   15°   279 mA   96%
 4388 mV   16°   785 mA   97%
 4388 mV   17°   788 mA   97%
 4388 mV   17°   772 mA   97%
 4389 mV   17°   743 mA   97%
 4389 mV   17°   691 mA   97%
 4389 mV   16°   645 mA   97%
 4389 mV   16°   604 mA   97%
 4389 mV   15°   566 mA   98%

Jednoduchým výpočtem se zjistí: 4000/100/120*3600=proud 1200mA na jedno procento (formulace technicky trochu tahá za uši) ... Můžete srovnat jestli sedí proud a přírustek procent


S hysterzí ukazatele % počítám, údaje beru z prostředka (tedy ne hned po zasunutí céčka) a taky ne hned sousední řádky. Opakuji, že to je opakované pozorování

108
Sice jsem si četl iptables-extensions mana, ale nejsem moc moudrý z voleb persistent (u SNAT jen) a fully-random(ized)

persistent nemá smysl řešit, když --to je jedna IP ?

fully-randomized se liší oproti random, že používá (pseudo)generátor namísto hashe? Nebo liší se sekvence nějak? (často je vidět, že čísla portů rostou/klesají o jedničku nebo dvojku)

109
Sítě / Udělá tento řádek z full cone NATu symetrický?
« kdy: 13. 12. 2021, 11:47:49 »
Je pravda, že v linuxu pomocí přidání jednoho řádku do iptables se stane z full cone natu symetrický?
Kód: [Vybrat]
# iptables -S -t nat
-A POSTROUTING -o eth0 -j MASQUERADE --random # existující NAT maškaráda, (šlo by nahradit -J SNAT 77.256.123.123)
-A PREROUTING -i eth0 -j DNAT --to-destination 192.168.10.250 # přílepek.
Ze zajímavosti, u toho přílepku se musí určit vnitřní IP, ač je logické, že to musí být adresa toho stroje na tom vnitřním rozhraní. Nebo by to šlo bez toho?
A hraje roli nevinná volba --random?

110
Vývoj / xargs - použití n-tic položek do jednoho příkazu
« kdy: 13. 12. 2021, 11:22:28 »
Dá se použít xargs k nějakému takovému výsledku?
Kód: [Vybrat]
# echo 1 2 3 4 5 6 | xargs -d " " comm -a % -b %
#případně
# echo -e "1 \n2 \n3 \n4 \n5 \n6\n" | xargs comm -a % -b %
#nebo ještě lépe
# echo -e "1 \n2 \n3 \n4 \n5 \n6\n" | xargs comm -a %2 -b %1
#vypis prvnich dvou
comm -a 1 -b 2 , comm -a 3 -b 4, comm -a 5 -b 6
#vypis "nebo ještě lépe"
comm -a 2 -b 1 , comm -a 4 -b 3 , comm -a 6 -b 5

#prozatím vím jen o:
# echo -e "1 \n2 \n3 \n4 \n5 \n6\n" | xargs -n 2 comm -a -b  # ===> Parametry se přidají na konec příkazu
# echo -e "1 \n2 \n3 \n4 \n5 \n6\n" | xargs -I _ comm -a _  -b  _  # ===> výsledkem ale je comm -a 1 -b 1 atd.

Četl jsem man, klíčové jsou volby -n, -L -x ,- d -I. Ale volba I podle nápovědy implikuje -L 1 a -x. Ale i tak jde určit -I, a -L/-n.
Mimochodem, jaký je rozdíl mezi volbou -n a L? Nenarazil jsem na to. Hraje u xargs taky rozdíl když jsou záznamy oddělené mezerou nebo novým řádkem? (Jaké vím, že -vlastní oddělovač jde určit -d, ale právě v man se něco píše od space separated arguments myslím.)


Použilo by se na takovéhle zadání třeba sprintf nebo zřetězení xargs | xargs?

111
Proč by nebylo?  Hudbu máte, Soubory máte, služby pouští hudbu a můžete s nima naložit dle libosti. Stejně jako youtube-dl

Stejně jako jisté doplňky do prohlížeče, který zpracovají obsah co vám jako tak pošle server a naloží s ním příslušně

112
Aha, 241.
Mimochodem na té stránce je napsáno
Kód: [Vybrat]
    main (#14552)
    v250-rc2 ... v245-rc1
Proč je tam verze uvedená dvakrát? Po rozbalení trojtečky se tam ukáže "interval verzí". Předpoklám správně, že tento opravný commit byl pro verzi* 245 a jen pro pořádek to píše ve kterých dalších verzích* až po současnou(250) to je?

* Nebo přesněji že to je první verze, která obsahuje tento comit
* možná je to tag nebo release

113
Software / HTTPSEverywhere se občas nechová jak má
« kdy: 10. 12. 2021, 22:32:45 »
Zkusil jsem si přidat doplněk HTTPS Everywhere , verze 2021.7.13. Pro Firefox android.

Asi jsem měl jiná očekávání, co bude principem fungování a že vůbec nebude spoléhat na nějaké seznamy a za druhé že Defaultně vypnutá volba Encrypt All Sites Eligible is ON je to co nechci.


Ale i tak mám nějaké problémy. (budu popisovat jak zadávám do adresního řádku)
- na idos.cz i https://idos.cz browser ukazuje na Redirect loop
- u některého procenta stránek, třeba kapral.cz , psycho.cz,pikao.cz se mi po odpálení "entru" ukáže Warning stránka rozšíření "HTTPS.E... zabránil načtení stránky. Možnosti. Proceed anyway, Disable, copy url"


jaká je příčina proč to nejde? Chápu, dnes je spousta možností, Location na www., Location na https://, Hlavičky,, weby co jedou na obou protokolech, jen na HTTP, jen na HTTPS, chybové kódy na url

A anketa: používáte nějaký takovýhle doplněk a neblbne ani u okrajových webů (divný konfig, jen http)? Co tam bylo potřeba nastavit?

114
Nevím jak to nazvat : předhřáté / homomorfní / mezilehlé šifrování.  A mám na mysli teď use case  stahování klasického souboru přes https z nějakého serveru.

Klasické šifrování : na souboru je uložený nějaký soubor. Když si ho někdo chce stáhnout (dnes je https běžné jak arm jako hlavní počítač). Soubor se přečte a https engine ho zašifruje.
Důležité vlastnosti: každé spojení je šifrované jiným náhodným klíčem pro zajištení forward secrecy (jen kdysi dávno pokud vím se používal přímo klíč serveru a když došlo k získání klíče, forward secrecy bylo pryč. Asi jakoPGP.)  O forward secrecy to ale nebude. Taky nehraje roli, jestli samotný server používá šifrované úložiště, ty soubory tak jako tak musí přečíst


Nové šifrování? : Vlastnost že by soubor by na serveru nebyl uložen nešifrovaný v případě disků bez šifrování. V případě šifrovaného úložiště by se právě ani soubor nedešifroval do plaintextu ( to je důležité do plaintextu, musel by se transformovat nějak jinak)...

Existuje něco takovéhleho? Jak se tomu říká? Používá se to v NSA, bílém domě, u hamáčka?

Prostě by to mělo fungovat, že pro  protokol TLS  uživatele a uživatele samotného to bude transparentní  na úložišti budou zvláštně zašifrované. Že nebude docházet k jejich dešifrování, ale nějaké zvláštní transformaci, která způsobí, že TLS vrstva u klienta (nezměněná) je dešifruje jako u normálního HTTPS (spíš TLS).
A nebo jinak, kdyby server nepoužíval šifrované disky, tak by tohle zamezilo možnosti přečíst obsah souborů pře čtení (a teď pozor, bojím se  to napsat a tady může být zádrhel) disku / paměti / trafficu serveru.


Postřehy:
- Možná někdo navrhne prostě na disk uložit zašifrovaný 7z soubor a ty co ho stáhnou odkázat na klíč. Tohle ne.
- Jak jsem psal, použít pro soubory šifrované úložiště . Řeší to to problém ? Tohle není jednoduchá otázka. Já myslím že ne.
- Jako jakýsi první nástřel by mohlo být, [zkratkovitě], že na server by se nahrál soubor zašifrovaný privátním klíčem serveru a TLS vrstva na serveru by "ten soubor posílal bez šifrování".Bohužel, tento příklad by platil jen v tom starém režimu TLS bez forwaed secrecy, kde se jelo na statický klíč.
- Filozoficko-logicky, má něco takovéhleho smysl a nebo jde dokázat, že něco takovéhleho neexistuje a že i kdzby se to nějak "naimplementovalo", vždy by musel existovat způsob, jak data vyčíst (z disku logicku ne, ale s pomocí RAM?)?

115
Hardware / Re:Aky disk do NASu?
« kdy: 09. 12. 2021, 20:41:42 »
že disky nejsou sešroubovány, ale.hermeticky zavařený.

Někde jsem četl, že v nové generaci disků jsou ještě lépe utěsněny než ta předchozí (první)

116
Dělám něco špatně, nebo příkaz journalctl při současném použití -r a -n 7004 blbne? Jako vím, že mohu použít journalctl -r | head -n7004, ale proč to blbne v tamtom?

čas nyní 20:21-, nejnovější záznam 20:20. záznam na pořadí 7004 cca v 17:0x.


Očekáváno : vypíše posledních 7004 záznamů od nejnovějších dolů (parametr r). Vypadá to jako když kombinace -r a -n blbne.

Místo toho: chybí prvních 7003(přibližně) záznamů, začíná od 7004tého (přibližně) a vypisuje k 14008mému řádku (přibližně)


Zkoušel jsem i argumenty --no-pager, --no-tail --pager-end

Kód: [Vybrat]


pixla@id:~ $ journalctl   -n 7004 -r  | cat | head -n9 | grep -Pio "^.+:\d\d "
-- Logs begin at Wed 2021-12-08 22:15:43 CET, end at Thu 2021-12-09 20:22:10
pro 09 17:07:12
pro 09 17:07:12
pro 09 17:07:02
pro 09 17:07:02
pro 09 17:07:02
pro 09 17:07:02
pro 09 17:07:02
pro 09 17:07:02
pixla@id:~ $ journalctl   -n 7004 -r  | cat | tail -n9 | grep -Pio "^.+:\d\d "
pro 09 13:24:07
pro 09 13:24:07
pro 09 13:24:07
pro 09 13:24:07
pro 09 13:23:55
pro 09 13:23:55
pro 09 13:23:55
pro 09 13:23:55
pro 09 13:23:43

# wtf where 19:12


workaround: (mírný časový posun ,nehraje roli , čas 20:33)

 $ journalctl -r |head -n 2 |grep -Pio "^.+:\d\d"
-- Logs begin at Wed 2021-12-08 22:15:43 CET, end at Thu 2021-12-09 20:31:40
pro 09 20:31:40
...atd


Komentář k řetězení:

nadbytečný cat - vím, byl jsem líný ho umazat při testování
tail a head - aby tu nebyly tisíce řádků
grep - ovoce, které skryje nepotřebné detaily

117
Důvod nepoužití těch utilit, je lenost +  že to právě běží na NASu, s vlastním "os", kde není ani smartmontools (získávání smart je tam zrůdnost a hdparm je osekaný, neumí -M) , apt, dpkg, pacman, yum a nepřipojen k internetu, takže používám "co dům dá". 

Asi si ho stáhnu  a  zkopíruji do sbin/ stejně jako nepodporaný exFAT co tam "neměl podporu".




Proč by to nemělo být "uložené" sekvenčně? Opakuji, nebudu kopírovat soubory, ale blokové zařízení. Zdrojová data z podstaty budou sekvenčně čtená a možná snad je obava u těch zapisovaných, ale tam jsem myslel, že pomůže buffer a velké bloky, kdy na disk se vychrlí vždy blok o 100MB třeba a i tím bude zajištěné, že buď se zapíše krátký komprimovaný blok a nebo se 1:1 zkopíruje "nekomprimovaný" ( poněkud binárně řečeno- komprese g/zip jak ji známe přece  precuje někde mezi)

A nebo se poohlédnu po již hotovém řešení...


Přitom by mi stačilo  to jednoduché řešení - nulové bloky to zapisovat nebude a nenulové to zapíše celé (akorát otázka je vhodná velikost bloku něco mezi 4MB a 512MB?) a zápis nějaké "bitmapy" obsazení.

Účel: v podstatě mít možnost přistupovat k 10TB disku velice rychle. Ale nemám peníze na nákup 10TB SSD. Proto chci disk přečíst předem (cca 10-15 hodin) a uložit ho bez nul, což dle odhadu bude 25% max. a pak se v něm pohybovat. (A  nebo aspoň udělat bitmapu, ze které uvidím hned, kde jsou ty bloky rozmístěné)




118
Hardware / Re:Aky disk do NASu?
« kdy: 09. 12. 2021, 17:09:15 »
A kolik ten starý Enterprise disk žere elektřiny ? Když to bude o 10W víc než nový (což u výkonný Enterprise disků nebude problém), tak to bude rázem cca 500 Kč ročně navíc na každý disk za provoz.

Mimochodem ty heliové disky mají menší spotřebu než srovnatelné normální. Helilum není vodík, uník zjevní není takový problém. Ono v tom disku není žádný přetlak, takže to helium nemá "motivaci" někam unikat.

Tak především Helilium ani není Helium. Uník nezávisí na srovnání(rozdílu) s atmosférickým tlakem 100kPa, ale s tlakem Helia v atmosféře , což je jiné (ale netvrdím to jistě, myslím, že by se k nim mohly připočítat plyny s nižší nebo vyšší úníkovostí(velikostí molekuly), ale ne vyšší). Našel jsem že ve vzduchu ho je asi 5ppm, takže asi nula nula nic.

Nikde jsem nenašel tlak Helia v discích, ale důležitý je i to, že ve vypnutém disku logicky bude rozmístění (a tlak) homogenní, ale v běžícím prý jiný (v závislosti na vzdálenosti od středu plotny logicky) a rozdíl může dělat prý až 2700mmHg..

Co se týče srovnání spotřeby (enterprise držák, moderní úsporný), nemá cenu se ptát na spotřebu toho starého, ale na rozdíl spotřeb.. A jestli to vychází na 4W v idle a 6W v zápisu, pak to je opravdu zanedbatelné za rok (4*5*8=160Kč) (4W, 5 Kč/kWh, 8=365*24/1000)

S spotřeba disku vs spotřeba ze sítě??? To si taky myslím že je pod rozlišovací schopnost. Max 20%. Navíc Když už NAS samotný běží...

119
Pardon , dohnalo mě Copy Paste jako Maláčovou. Sorry, hledal jsem ve slovníku... Nejdřív jsem myslel, že jde o inkontinenci.  Test s gz byl samozřejmě bez "of->null".
A jen poznámka na okraj, měřil jsem to i s "před"příkazem time a i | dd of, abych měl přehled o množství dat na vstupu i výstupu

Kód: [Vybrat]
[root@nasturbace #]$ time dd if=/dev/sda bs=1M count=160 skip=4000000 | gzip -1nebo9 -c  | dd of=/dev/null

### skoro prázdná oblast
160+0 records in
160+0 records out
167772160 bytes (160.0MB) copied, 6.811203 seconds, 23.5MB/s
real    0m 6.81s
user    0m 0.00s
sys     0m 0.62s
319+1 records in
319+1 records out
163592 bytes (159.8KB) copied, 6.817881 seconds, 23.4KB/s

### neprázdná oblast (pozor, osmina velikosti)

sudo time dd if=/dev/sda bs=1M count=20 skip=19000 | gzip -c -4  | dd of=/dev/null
20+0 records in
20+0 records out
20971520 bytes (20.0MB) copied, 5.780149 seconds, 3.5MB/s
real    0m 5.78s
user    0m 0.00s
sys     0m 0.06s
40925+1 records in
40925+1 records out
20953927 bytes (20.0MB) copied, 5.807068 seconds, 3.4MB/s


Holt asi na to budu muset použít i7... I komprese prázdného místa jede 20MB/s

A ještě nějaká rada, když chci aby byla utilizována maximální rychlost čtení i zápisu, vyplatí se to nějak "bufferovat do RAM", pokud by byl druhý(nebo i první) disk pomalejší? (S přihlédnutím, že občas se tam najde blok nul a tím pádem by se výstupní disk mohl chvíli flákat) . Že kdybych použil "mezi" pipami něco jako dd if | docasnybuffer14GBRAM |dd of.... (Vykládám to lapidárně)


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
Sorry, hledal jsem ve slovníku... Nejdřív jsem myslel, že jde o inkontinenci.

120
Hardware / Re:Aky disk do NASu?
« kdy: 09. 12. 2021, 08:16:42 »
Citace
MG04
No ta cena není zlá (hlavně je nový z obchodu a se zárukou, což je u disků kruciální), ale jde o starou řadu už (kapacita je subjektivní a někdy ty poloviční kapacity musí kupovat, příští rok už třetinové). Myslím, že se doprodává 07, aktuálně je 08 a MG09. Důležité je že až od 07 jsou plněné balónky héliém.

Stran: 1 ... 6 7 [8] 9