Příspěvky

Namisto toho AI slopu jsi mel napsat konkretni model, ata id (hdparm -i / -I) nebo full smart (smartctx -x), a hlavne cenu, moznost dokladu, dph status, a zaruku.

hdparm ani smartctl tezko hodi, pokud nechce lepit 3. pin, staci si precist cast toho AI slopu 

Osobně to neřeším. A nějak si nevybavuji za celých 39 let co jsem na světě že by to někdo řešil. Samozřejmně je dobrý mít pojistku (ale to vždy -- myslím od pojišťovny, ne jistič) a já osobně mám po cestě ještě všude v rozvaděči shellyny, který předpokládám že by zareagovali nebo položili život za další elektroniku kdyby to přišlo zvenku. Ale kdo ví :-)

Střílím dost od boku, ale co nastavení DNS na Androidu (Private DNS) ?

Ale Ondřeji, prosím tě. Turris v NICu je fakt oddělenéý, ta nálada je tam fakt jiná. Bohužel. Spin-off nevyšel, k tomu se radši ani nevracet, kolik peněz tam zahučelo. Vývoj je takový polotovar. Špatně vybrané procesory. Můžeme začít i tím, že MOX vlastně neměl nikdy vzniknout nebýt představenstva a kolegia, které muselo dofinancovat IGG kampaň. Je to taková hračka pro kutily. Když se podíváme na Turris Omnia NG, tak to je průser, což prostě vedení nevidí, protože jsou nasmlouvané dealy a partneři to chtějí. Stojí to za ten shit storm, co je tady nebo na fóru Turrisu? Stále to nefunguje. Stále je to rozbité. Můžeme se podívat na to, že vlastně ani testy už neprobíhají. 2 měsíce nebyl opravený port na MOXovi.

Do toho odchod dvou lidí - Michala a Petra, oba na vedoucích pozicích v Turrisu.

Pěkně se to rozpadá.

To by mě zajímalo co je na NG takový průser? Byl jsem mezi prvníma adopters a až na to že jsem vylosoval vadný kus (což se stává, předpokládám že si Turris team tohle už vyříkal s výrobcem) tak ten router prakticky funguje a nezažil jsem že by bylo něco rozbité. Aspoň z té běžné funkčnosti, ale na routeru neprovozuju LXC, docker a podobné chujoviny od čehož jsou servery, ne routery...

Já bych šel taky cestou vlastního VPS. Výhody vidím v tom, že IP nebude vedená v žádném VPN seznamu a není problém si tam rozběhnout více VPN služeb a mít něco v záloze. Ne vždy a ne všude běží bez problémů různé VPN.

Mim. na to aby mi běžela VPNka i z různých divných sítí a zemí se mi docela osvědčil netbird který spojení umí encapsulovat přes http/quic relay ;-)

Je snad chybou XML, že jsou lidé líní se ho naučit a místo toho ho pomlouvají?

Já jsem třeba XML uměl velmi dobře. Taky XSLT, XML Schema atd. Stejně ho pomlouvám, protože oproti JSON to je prostě těžce neefektivní, složitý formát který obrazně řečeno k předání jednoduché informace mezi stroji typu { "temperature": { "value": 20, unit: "C" } } nebo {"payment": {"currency": "CZK", "value": 210.20, ... }} potřebuje poměrně dost boilerplate a heavy parser.

Kód [Vybrat] Rozbalit


<temperature value="20" unit="C"/>
<payment currency="CZK" value="210.20"/>

mi připadá čitelnější.

A pak si někdo vzpomene že XML umí schéma a namespace a že to každý cool a in člověk musí použít

<?xml version="1.0" encoding="utf-8"?>
<temp:record
  xmlns:temp="https://example.com/temperature"
  xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
  xsi:schemaLocation=" https://example.com/temperature https://example.com/temperature/temperature.xsd">

  <temp:temperature temp:value="20" temp:unit="C" />

</temp:record>

Samozřejmě, že jednoduché XML takhle vypadat nemusí. Jenže proč to nepoužít když to jsou "výhody" xml. A jakmile je reálně začnete používat, syntaktická i implementační režie(celkem zbytečná) kolem rychle narůstá.
Navíc, čitelnost pro člověka je příjemný bonus, ale u formátu určeného primárně pro komunikaci mezi stroji není primární. API nefunguje tak že jednu odpověď píše sekretářka a druhá sekretářka ji čte. Osobně si myslím že je důležitý rozumný kompromis mezi čitelností pro člověka (v případě debuggingu, auditu etc.), jednoduchostí a množstvím režie (aneb kolik potřebujete serverů na generování a čtení).

Proč se tedy pro tvorbu webů místo HTML nepoužívá JSON, když je tak skvělý?

Nechete přirovnávat HTML ke XML, že? Přestože tam je podobnost, HTML má trochu daleko k validnímu XML...
A jinak je to protože první použití HTML bylo lidmi (psali ho lidé). Nešlo o strojově generovaný kód. Jenže taky se podívejte kdy HTML a XML vzniklo. Kdyby dneska někdo navrhoval nový formát pro browsery, osobně si myslím že HTML by už nepoužil.

Je snad chybou XML, že jsou lidé líní se ho naučit a místo toho ho pomlouvají?

Já jsem třeba XML uměl velmi dobře. Taky XSLT, XML Schema atd. Stejně ho pomlouvám, protože oproti JSON to je prostě těžce neefektivní, složitý formát který obrazně řečeno k předání jednoduché informace mezi stroji typu { "temperature": { "value": 20, unit: "C" } } nebo {"payment": {"currency": "CZK", "value": 210.20, ... }} potřebuje poměrně dost boilerplate a heavy parser.

Pokud jsou v JSONu české znaky, tak se to čte blbě. Jak poznáš znakovou sadu, ve které byl napsán?

To je fiktivní problém nebo reálný? Všechny nové systémy běží v UTF-8. Je reálný důvod aby někdo běžel v něčem jiném? Navíc RFC kolem JSONu říká že dokument musí být jen a jen v UTF-8, takže to poznám zcela jednoduše.

JSON nemá ani komentáře. V XML je můžeš i zpracovávat. JSON nemá ani definici použité znakové sady. Processing instructions JSON také nemá a přitom je to fakt mocný nástroj. Uživatelé JSON si však zvykli na to, že je to jen serializovaný datový strom a tak ho také používají.

Komentáře - Proč by proboha někdo chtěl do generovaného výstupu dávat komentáře (api request, response, dokumenty atd.) Aby zvýšil bandwidth a cenu parsování dat nesmyslem který druhá strana zahodí?
Co se processing instruction týče, tak je to jen věc syntaxe, sémantiky a kontraktu, žádná magie. Cílová aplikace to musí podporovat tak jako tak, takže jaký je přesně rozdíl mezi
<?cache ttl="200"?>
a
{"_cache": { "ttl": 200 } }

Myslel jsem, ze XSLT se uz moc nepouziva? Webum nerozumim, ale na frontendu se to pouzivalo nekdy pred 30 lety a na backendu uz bylo XML prevalcovano JSONem. Ale chapu, pokud delas nejake one-man show aplikace, tak muzes pouzivat i vicemene obskurni technologie.

JSON je jen slabou náhražkou XML a obvykle se používá v rámci jedné aplikace tam, kde jeho chudé vlastnosti stačí, zejména v ekosystému JavaScriptu. Pro výměnu dat se však stále používá XML. Mrkni se třeba na API nějakého e-shopu nebo banky. XML.

S tím mohu jen nesouhlasit. JSON, případně jeho odnože a REST/GraphQL jsou de-facto moderní komunikační standardy pro API. Pokud někdo dělá nové API (a nepotřebuje kompatibilitu se "starým") světem, šáhne po JSONu. Stačí se podívat na API všech světových big-companies(google, openai, meta ...), nová API vznikajicí v rámci eu (PSD2 třeba) a osobně když to vezmu z osobní zkušenosti -- dělal jsem u integrací eshop<->dopravce (v mezičlánku co sjednocoval API všech velkých dopravců). Když pominu věci jako FTP (ano CSV/FTP jako API :-D) tak dopravci co neměli nové systémy používali SOAP. Ale všichni dopravci kteří přešli na nové systémy používali bezvýhrady JSON.
Popravdě neznám jediný nový produkt který by jako primární API používal XML. XML je těžce neefektivní a složité.
Na druhou stranu, ano pravda, v ČR stále máme nová api na SOAP (eet2). Ale popravdě, Český stát byl vždycky co se techniky týče trochu zaostalý (ale už se to lepší)

Ak ti AI pise aj testy aj kod tak ty ani netusis, ci sa to sprava, ako sa to spravat ma.

Když použiju nějakou knihovní funkci, tak taky netuším, jestli se chová, jak má. Ty si sám píšeš testy i na každou vnější závislost, nebo taky spoléháš na to, že to otestoval někdo jiný - a šťourat do toho začneš až když nějaký test na vyšší úrovni nebo praxe ukážou problém?

já třeba jo

Zvláště u webservis oni rádi mění api a chování aniž by dali vědět.

Něco jiného je testovat závislost kterou nemám pod správou (web api etc.) a něco jiného je knihovna. Kterou pod správou mám přesnou verzi a když neprovedu upgrade, aplikace bude fungovat dál. Osobně to nikomu neberu, ale kde je ta hranice? Za chvíli někdo může psát testy jestli se compiler chová tak jak se chovat má...

Je rozumný nápad objednávat z e-shopu který je prolezlý URL shopify, .well,known, .produce, produce_batch, api/collect, doménami níže: ?
upcart.app

Kód [Vybrat] Rozbalit

     
      1 ohttp-relay-safebrowsing-android.google.fastly-edge.com
      2 browser.sentry-cdn.com
      2 slide.upcart.app
      2 tr.runconverge.com
      2 www.fbsbx.com
      4 cdn.shopify.com
      6 api.config-security.com
      6 api.whaledb.io
      6 app.consentmo.com
      6 cdn.rebuyengine.com
      6 cdn.506.io
      6 otlp-http-production.shopifysvc.com
      6 pixel.wetracked.io
      6 static.klaviyo.com
      6 static.rechargecdn.com
      6 subscription-admin.appstle.com
      6 t.contentsquare.net
      6 tseish-app.connect.trustedshops.com
      6 widget.trustpilot.com
      6 www.clarity.ms
      8 monorail-edge.shopifysvc.com
     10 b.applovin.com
     12 jointrybe.com
     12 static.runconverge.com
     16 shop.app
je to log sprchy dns requestů, očištěný o  pan-webové sledovače jako tiktok, google.h.seznam, nel.cloudflare)

Tedy jestli už podle

Naštěstí checkout narazil na zablokovanou doménu shop.app.
e-shop je tasty-dose.de .... ale dotaz obecně je zda se pozná  už podle takovéhle "úrovně" e-shopu, že bych si tam nesvěřil ani GET požadavek.

Obávám se že údaje  se rozsemení po všech darknetech podle počtu xthml requestů na bezprecedentě vysoké množství domén.
co je zač. shop.app doména. nějaký koncentrátor?

Shopify je docela známy systém na shopy. klaviyo/upcart jsou taky celkem známý. Třeba shop.app jsem neznal ale přijde mě to jak agregátor typu glami. Ty většinou mají tracking. Holt využívají hodně služby třetích stran ...

která je v základu zdarma a platí se jen za víc profi funkce, které 90% uživatelů nikdy nepoužije.

To bych neříkal. Zrovna celkem běžný GoPro Hero13 generuje 5k videa pro které je základní verze nepoužitelná

Elementary OS jsem zkoušel dříve ale vůbec mi ten Pantheon desktop nesedl.

ten je pry DEI... takze tam si jako bily muz patch neposles.

Jasně protože je zcela normální být id*ot a posílat do pr*ele lidi kvůli národnosti, sexuální orientaci, vyznání, politice atd. že? Sorry, ale s takovým vývojářem bych taky nechtěl pracovat a to ani kdyby jeho patch měl přinést do projektů výrazné vylepšení ;-) (a bylo by mi fakt jedno jestli je bílý, žlutý, oranžový, černý, růžový, žid, křesťan nebo ateista...).

To pomůže spíš proti normální policii, majitel ručníku a obušku nejspíš bude vědět po čem jde. Pomůže mít možnost zničit klíč, někdo na ABCLinuxu kdysi řešil autodestrukci dát termitem, pak ještě kapsle s kyanidem...

Každopádně tohle myslím demonstruje že čím dál zajde threat model, tím absurdnější opatření z toho vyplave

kapsle s kyanidem je jed pro cloveka

Čímž ve finále zabezpečí ve spojitosti s termitem ten notebook -- protože z něj nebude nikdo už moct vymámit data co byly na notebooku případně klíče k zálohám ...

Nějak bych řekl že pokud vám jde o "absolutní" anonymytu, s JS a médii nemáte šanci. Samotné uBlock atd. už o vás něco řekne. JavaScript vykecá poměrně opravdu hodně, samotné TCP taky (a jako že tyhle společnosti jsou opravdu kreativní, viz. meta a listen na localhostu na mobilním zařízení etc.). Jediná cesta jak být opravdu anonymní je fungovat jak píše a6b. 
Nicméně pokud Vám jde o zablokování běžného trackovacího JavaScriptu z "big company" tak uBlock fungovat bude :-)