Příspěvky

31

Desktop / Re:Nedostatek paměti a nenáročný editor na .rtf/.doc

« kdy: 22. 03. 2023, 16:49:19 »

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í.

32

Desktop / Re:Nedostatek paměti a nenáročný editor na .rtf/.doc

« kdy: 22. 03. 2023, 13:39:25 »

Ja mam pocit ze ten clovek nechce pomoct v zmysle ako mu vsetci hovoria ale chce riesenie podla svojho popisu.

Upřímně nechápu smysl celého topicu. Chápal bych ho do chvíle, než jsem se dočelt, že OP nezná ani základy těch XP na kterých tak lpí (/PAE etc.). Každopádně ani PAE nepomůže, pokud s ním aplikace neumí pracovat a/nebo tam není víc programů, které by se každý z nich do těch 3GB vešly. Pouštět ještě pod tímhle další virtualizaci je zoufalství.

Ale pro případ, že nejde o trollení a XP jsou hard requirement, tak jedna cesta by asi byla sehnat XP/64bit a postupně tam docvakat víc raměti jak dovolí finanční možnosti (+jak tu už mnozí navrhovali, i SSD disk dokáže hodně, jestli teda půjde ještě sehnat ten update na SATA co si tak slabě vzpomínám, že možná bude potřeba). Taky bych se, opět jak už mnozí také navrhovali, zamyslel, co z čeho virtualizovat. 32-bitové wokna dává mnohem větší smysl virtualizovat z 64bit tučňáka, než naopak - už proto, že když na ten libreoffice pod tučňákem nebude stačit ramka, tak se prostě ten XP virtuál pod tím dá vypnout, navíc je to ready na doplnění paměti. Že tím ty widle člověk odstíní od novějšího HW je vítané plus).

33

Software / Re:Reklamy procházejí skrz, pokud se neblokuje cookie,script nebo kusy js

« kdy: 04. 03. 2023, 04:13:20 »

*nedávno jsem se setkal s dalším modus operandi: www.stranka.com/a/blabla  https://ericdraken.com/a/
Potíž je že obrana proti tom třeba má instrukce o délce 50 A4. : https://linuxincluded.com/block-ads-malvertising-on-pfsense-using-pfblockerng-dnsbl/

Tak zrovna tohle je celkem triviálně řešitelné přes content adaptation, kde buď ten script on-the-fly jemně upravíte, nebo si ho prostě přesměrujete, aby se tahal odjinuď patřičně upravený.

34

Server / Re:Duplicitní zprávy ze Seznam.cz na Postfixu

« kdy: 03. 03. 2023, 23:42:34 »

Chtělo by to vidět tu konfiguraci postfixu (ořezanou o citlivé údaje). Tip: špatná síť, blbé DNS, špatné kontroly v Postfixu, Spamassassinu, skvrny na slunci, atd. Log postfixu je dobro.

V minulosti jsem se s něčím podobným občas setkal taky, obvykle to bylo způsobené věcmi jako zrušený dnsbl v konfiguraci spamassassina, starý plugin který přestal pracovat a měl být vyhozen apod.
Chce to jak píšete, prolézt logy, pokud je ten mailserver nevytížený, klidně zkusit strace -f -p (popř si tam bloknout 25ku všude kromě seznamu etc.) apod.

35

Server / Re:Update kernelu na VPS

« kdy: 24. 02. 2023, 17:22:42 »

Na Xenu většinou také, ale nemám s Xenem osobní zkušenost.

Na Xenu se dá i druhá možnost, nativní kernel pouštět z hostu - je to dobré u virtualizace pro sebe, ale jako veřejný hosting bych to tak rozhodně nedělal. Výhoda - mám jeden (dva, ...) kernely na jednom místě pro všechny guesty, nevýhoda to samé.

36

Vývoj / Re:Lua a cyklus

« kdy: 23. 02. 2023, 22:36:24 »

BTW když už tu je tolik odborníků na LUA, nemohl by někdo doporučit z toho milionu co jsou na netu k dispozici nějaký rozumný quick tutorial? To znamená žádné rozvláčné rozepisování (už vůbec ne video), ale základní principy jazyka, datové typy (třeba jako to jak tu padlo že pole jsou od jedné) a pár triviálních příkladů atd.
...zhruba ve formátu, jak tu pan Tišnovský občas popisuje různé exotické jazyky

37

Studium a uplatnění / Re:Zkušenosti s indickými kolegy vývojáři

« kdy: 21. 02. 2023, 07:37:43 »

Co jsem si všiml, je dost rozdíl, když jde o vzdálenou spolupráci s pobočkou (nebo nedejbože agenturou) v Indii a když ty Indy máte přímo jako kolegy....

Potvrzuji, jsem na tom stejně. Pokud jde o Indy ať už jako kolegy, nebo rozlezlé po dodavatelských firmách po světě, naprosto v pohodě, pokud jsou v Indii, tak jak to jen říct, no cena je odpovídající kvalitě ;-).

38

/dev/null / Re:ChatGPT a tel. číslo

« kdy: 17. 02. 2023, 17:19:22 »

Zdravím mám dotaz,
odpověď už asi znám

tak.

Je lidem jedno a telefonní číslo naťukají do kteréhokoli formuláře? (tady pošlete fotku napište tel. a uvidíte jak budete vypadat za 30 let.)

V době FB, IG, a dalších sociálních sítí již prostě tohle nikdo neřeší a vůbec to nepovažují za osobní údaj?
Argument, že mám druhé tel. číslo které je jen pro takové účely mi přijde jako: Neřeknu vám ulici kde bydlím, ale řeknu číslo domu.

Prostě digitální klondike je ve stavu, kdy pistoléros si mohou diktovat co chtějí, cowboys radši mlčí a hlídají si svá stáda, a když přicestuje nový sheriff který by chtěl přivést zákon, tak se všichni radši tváří že jako nic.

Takže ano, systém je velmi špatný, jedinec má za dost velkou cenu šanci se mu víceméně bránit, ale to je tak všechno.

39

Hardware / Re:UPS - kotel + oběhové čerpadlo

« kdy: 17. 01. 2023, 17:26:50 »

ad. původní otázka - to samé (napájení oběhového čerpadla v případě výpadku) jsem řešil loni, zjišťoval zde jmenované věci (účinnost pro nízkou zátěž, potřebu sinusu, baterky, etc.), vymýšlel optimální řešení, pak přišla vichřice a najednou se to vyřešilo naprosto pragmaticky, "na prasáka" ale celkem ke spokojenosti.

Čerpadlo u kotle mám nejobyčejnější do tisícovky včetně poštovného, běžně vydrží přes 5 let, prakticky jsem zjistil, že na nejobyčejnější UPS (nějaký obdélník) běží relativně v pohodě (asi mu to moc neprospívá a víc vrčí, ale vodu čerpá). Takže pro případ krátkého výpadku tam skončila 650W UPSka za tisícovku od ufouna Alzáka s tím, že za tu půlhodinu ročně to moc škody na čerpadle nenadělá, a pokud ano, tak stejně mám v dílně jedno rezervní, a pro dlouhodobější výpadek mám připravený 1kW agregát (který utáhne současně i mrazák) a kanystr s benzínem.
Časem k té UPS přidělám větší baterku, cílím na 2-3 hodiny pokryté z baterek, a až jednou bude solár, tak to bude jen a jen lepší.

40

Sítě / Re:Přístup na WAN z lokálních adres - povolit či nikoliv?

« kdy: 15. 01. 2023, 17:01:26 »

Ano, tohle je skoro přesně případ, o kterém jsem psal hned ve svém prvním komentáři. Akorát že 100.64.0.0/16 není privátní rozsah, je to rozsah určený právě pro NAT ISP, takže je to v pořádku. Ale hlavně – aby tohle fungovalo, musí ISP vedle DNATu veřejné IP adresy na vaši privátní také SNATovat adresy svých zákazníků za něco, co nebude zákaznický router považovat za adresu v síti svého WAN rozhraní, ale za něco z internetu, co má poslat zpátky na bránu.

Moment, tohle je nějak divné. Zákaznický router ma defaultu ven, dovnitř k zákošovi třeba jen 192.168.1.0/24, a obvykle ta síť providera nebejvá plochá, ale spíš nějaká kombinace OSPF/iBGP (neboli nexthop pro CE router je anténa na střeše, ta má zase jako nexthop nějakej PE na kostele. Aby se to doroutovalo zpátky, vůbec netřeba aby to SNATovalo za internet, stačí cokoli co se dokáže vrátit (i když za veřejku by to bylo lepší, dokážu si představit validní argumenty, proč to někdo dovnitř vlastní sítě neNATuje za veřejku, ale za privátku/nějaký privátní subnet)

BTW to jestli 100.64/10 je privátní nebo CGNAT rozsah je v našem případě irelevantní (a ve skutečnosti můj provider používá kus desítek, jen jsem nechtěl dávat přesnou identifikaci podle které by se poznal když ho tu "pomlouvám"), oboje jsou adresy, které nemají ve veřejném internetu co dělat, ale v případě připojení k síti providera na nich není nic špatného, pokud ofc nedojde ke konfliktu s adresami v LANce (i to se dá řešit, ale nekomplikujme to, tazatel kdyby to uměl řešit by se v první řadě vůbec nemusel ptát.).

Které se na WAN zákaznického routeru prostě objevovat nesmí, protože tak jsou privátní IP adresy nadefinované – mohou se používat pouze pro komunikaci uvnitř privátní sítě.

Fajn, a co s tím chcete dělat? Jednak je to slovíčkaření (veřejný internet vs. pakety od zákošů s privátními adresy providera chodí z privátního rozsahu providera....), druhá věc je čistě praktická - buď můžete být pokročilý zákazník, který když je ze strany zákoše neřešitelný problém, tak se domluvíte přímo s technikem, nebo můžete být věrozvěst-puritán, jinými slovy problémista, což stejně k absenci neveřejných adres na WANu nepovede (i malý ISP je podnikatelský subjekt, jehož smyslem existence je dle OZ tvorba zisku a kvůli dvoum lidem z několika tisíc síť předělávat nebude ani riskovat výpadek při konfigurační chybě...), zato třeba při nastavení reverze se z "kolega Vám to nastaví jak se vrátí z oběda" stane "Litujeme, ale tuto službu domácnostem neposkytujeme, pokud chcete provozovat mailserver, máme zde ceník pro business zákazníky", případně z "hmm, když Vám to občas v noci zakolísá, tak k Vám skočím a dáme tam nové pojítko v licencovaném pásmu" se stane "Podle měření Vaše připojení odpovídá smlouvě" apod.
Případně stížnostmi donutíte providera tu službu (veřejná IP) maximálně zrušit úplně, což je úplně nejhorší varianta a pár lidí z okolí Vám za to rozhodně nepoděkuje (ano, vždycky můžete zavolat na Cetin, že máte zájem o xDSL, velmi rádi Vám nacení výkop, pár metrů přes silnici to vychází kolem 150k)

41

Sítě / Re:Přístup na WAN z lokálních adres - povolit či nikoliv?

« kdy: 15. 01. 2023, 04:14:14 »

Pokud si tazatel zablokuje přístup z neveřejných IP adres, pak ze všech, tj. i těch z vnitřní sítě ISP, což je samozřejmě špatně a není k tomu vůbec žádný důvod. A popravdě ani neznám nikoho, kdo by něco takového dělal.

Není na tom vůbec nic špatně. Dělá se to proto, aby se do vnitřní sítě nedostal provoz, který tam nemá co dělat a může jít třeba o podvržené pakety.

Ano, dělá se to na ingresu z Internetu, kde opravdu pakety z rfc1918 nemají co dělat. Nicméně tazatelem popsaný případ se ingresu z internetu moc nepodobá, spíš nějaká forma přístupu do privátní sítě ISP, a zcela zřejmé a nejjednodušší řešení je samozřejmě blokovat pouze lokální adresy, které jsou použité v jeho místní síti, a ze všech ostatních (veřejnou) službu povolit.
Optimálně podle možností routeru nějakým antispoofem, rp-filtrem apod., vypisovat do filtru interní sítě ručně je cestou do pekla a současně časovanou bombou.

O tom, že to má lokální provider zprasené by se dalo dlouze diskutovat, dost často (k jednomu takovému providerovi jsem připojený taky) to historicky vypadá tak, že nějak udělá (samozřejmě na privátkách) natovanou síť pro vesnici dvě tři, pak se mu tam objeví zákazník šťoural který chce veřejku, tak mu jí tak nějak dobastlí - v mém případě 1:1 NAT na vstupu na privátku, která na mě reálně kouká z antény. Kvůli těm pár jednotkám zákošů se mu nevyplatí to celé předělávat a u nich zase ví, že nejsou překvapení že prostě občas jim kromě z veřejek přijde něco i z 100.64/16. Jak se říká, za ty prachy to jedno leftid navíc v ipsec.conf člověk přežije ;-)

42

Distribuce / Re:Vhodná distribuce pro hrátky s AI (Real-ESRGAN)

« kdy: 19. 12. 2022, 12:01:06 »

A použít přímo tu all-in-one binárku https://github.com/xinntao/Real-ESRGAN#portable-executable-files-ncnn jste zkoušel?

Dobrý hint, binárka naprosto v pohodě (v rámci možností, nemá face_enhance, každopádně vše načítá a zpracovává - nVidia, cuda a okolo jsou mimo vinu).
BTW na Ubuntu 22.04 stejný problém, tam někde něco chybí, až na to, že to žádný error nepíše. Ještě tomu dám večer čas s strace.

43

Distribuce / Re:Vhodná distribuce pro hrátky s AI (Real-ESRGAN)

« kdy: 18. 12. 2022, 21:31:58 »

A jinak AI lidé typicky používají Ubuntu, ale já jsem všude nasazoval Debian a normálně to funguje.

Díky, testnu to Ubu. Jako s cuda problém nemám, ta se inicializuje i počítá dobře na první dobrou, ale s tím Pythonem a jeho závislostmi zápasím fest. + s tím, že máloco vůbec napíše, co se tomu vlastně nelíbí :-(

44

Distribuce / Vhodná distribuce pro hrátky s AI (Real-ESRGAN)

« kdy: 18. 12. 2022, 11:44:49 »

Zdravíčko vespolek,
Po třech dnech částečných neúspěchů přicházím s prosíkem o vynadání do lam a radu, jak to dělat správně.

Začal jsem si hrát s $SUBJ - https://github.com/xinntao/Real-ESRGAN . To, že to nejde na CPU jsem zjistil poměrně rychle, vyřešil jsem to přidáním 250GB SSD do herního kompu, kde mám nVidii 1650, nainstaloval čistý Debian 11, a začal si hrát, a narážím na jeden problém za druhým.
Nainstalovat cuda nebyl problém, pak jsem postupoval přesně podle zadání - Python, Miniconda, Pytorch, git clone ... podle postupu, vše OK.
Tak se těším, že pustím podle návodu, a dostavilo se dependency hell v Pythoním provedení, změna API v TorchVision 0.13., pak bylo potřeba ještě opravit načítání monochromu. To jsem po složitém kachnění nakonec odignoroval (a pak i opravil), ale stejně jsem se dostal k tomu, že polovina "upscalnutých" obrázků byla černých.

Postupně jsem prošel několika reinstalacemi, různými downgrady PyTorch, Pythona i OpenCV, pak už i komplet reinstallem, downgrade na Debian 10 (Python 3.7), pokus na Slackware 15 - v jedné konkrétní konfiguraci s dowgradnutým TorchVision mi to fungovalo na všechny vzorové obrázky, ale už jsem nedokázal zreplikovat, jak se k ní dostat. A když jsem v ní zkusil síť trénovat, tak stejně se to vyhroutilo.

Co se týče černých obrázků, došel jsem až na opencv - Obrázek se na cv2.imread() načetl správně (byly vidět v print(img) nenulové pixely i rozměr), až na to, že na cv2.imshow(img) to opět ukázalo černé okno. Dokachněno že v opencv 4.3.xxx byla podobná chyba, tak jsem zkoušel několik různých verzí, bez jakéhokoli úspěchu, všude černo.

Tak bych se rád zeptal - poradíte linuxovou distribuci, na které Vám to funguje na první dobrou? Případně setkali jste se s podobnými chybami a podařilo se vám je nějak překonat?

45

Vývoj / Re:Go - alternativa atomics pre prilezitostne zmeny?

« kdy: 14. 12. 2022, 20:58:42 »

Třeba x86 nemá ani instrukce pro atomické čtení/zápis

LOCK XCHG,
LOCK CMPXCHG
První měl už 8086 blahé paměti.