1
Hardware / Re:PC sestava pro Linux
« Poslední příspěvek od Vít Šesták (v6ak) kdy Dnes v 03:42:16 »Kdysi platilo, že X3D jsou lepší pro hry, ale horší pro kompilaci.
Poslední příspěvky
2
Hardware / Re:Chování nabídky napětí USB-C nabíječky s PD
« Poslední příspěvek od Vít Šesták (v6ak) kdy Dnes v 03:31:49 »Nevím, jestli proti spojení dvou zdrojů bude chránit dioda, záleží na implementaci. Každopádně:
1. Dioda znamená nějaký pokles napětí (=> ztráty a teplo), navíc se může lišit s proudem. Obojí je problematické.
2. Jedním z těch zdrojů může být i USB A, kde se s tím ještě spíš nepočítalo. Ale pravda, USB C zdroj by s tím měl počítat, pokud na druhé straně bude USB A, tak to nebude čekat na povolení. Ale právě proto USB C samice nesmí jen tak napájet bez souhlasu protistrany.
3. Vzpomínám si na tabulku s USB huby pro Raspberry Pi první generace, IIRC jich svého času dost umožňovalo backfeeding, kdy se celé Raspberry Pi napájelo z hubu přes USB A na Raspberry Pi, ačkoli tento konektor má přenášet proud výhradně opačným směrem.
1. Dioda znamená nějaký pokles napětí (=> ztráty a teplo), navíc se může lišit s proudem. Obojí je problematické.
2. Jedním z těch zdrojů může být i USB A, kde se s tím ještě spíš nepočítalo. Ale pravda, USB C zdroj by s tím měl počítat, pokud na druhé straně bude USB A, tak to nebude čekat na povolení. Ale právě proto USB C samice nesmí jen tak napájet bez souhlasu protistrany.
3. Vzpomínám si na tabulku s USB huby pro Raspberry Pi první generace, IIRC jich svého času dost umožňovalo backfeeding, kdy se celé Raspberry Pi napájelo z hubu přes USB A na Raspberry Pi, ačkoli tento konektor má přenášet proud výhradně opačným směrem.
3
Vývoj / Re:zobrazenie obrázkov z DB na webe bez koncovky.
« Poslední příspěvek od Kit kdy Dnes v 02:25:06 »Tu koncovku bych tam určitě nechal. Nebudeš muset manipulovat s hlavičkami HTTP.
Do databáze bych uložil jen názvy a náhledy. Originály obrázků do souborového systému. Vyzkoušeno.
Do databáze bych uložil jen názvy a náhledy. Originály obrázků do souborového systému. Vyzkoušeno.
4
Vývoj / Re:zobrazenie obrázkov z DB na webe bez koncovky.
« Poslední příspěvek od BoneFlute kdy Dnes v 02:13:23 »1/ Ukládat si do filecache včetně koncovky. Pomocí htaccess následně řešíš jen existenci
2/ Ukládat si do filecache bez koncovky, ale s fixním typem. IMHO poněkud vachrlaté. A u toho originálu se ti to asi nebude chtít.
3/ Ukládat si do filecache bez koncovky, a hned vedle ukládat soubor s mime. Něco jako "5b17f8185e71449983e3600a0c2d8527" = obsah. "5b17f8185e71449983e3600a0c2d8527.mime" a v něm obsah "image/png". Pokud se dotazuješ na soubor bez koncovky tak stejně budeš muset posílat nějak hlavičku, takže nějaká mikro-proxy tam bude potřeba. Pomocí čistě htaccess by to asi nešlo. Možná nějaké pravidlo na serveru, záleží.
2/ Ukládat si do filecache bez koncovky, ale s fixním typem. IMHO poněkud vachrlaté. A u toho originálu se ti to asi nebude chtít.
3/ Ukládat si do filecache bez koncovky, a hned vedle ukládat soubor s mime. Něco jako "5b17f8185e71449983e3600a0c2d8527" = obsah. "5b17f8185e71449983e3600a0c2d8527.mime" a v něm obsah "image/png". Pokud se dotazuješ na soubor bez koncovky tak stejně budeš muset posílat nějak hlavičku, takže nějaká mikro-proxy tam bude potřeba. Pomocí čistě htaccess by to asi nešlo. Možná nějaké pravidlo na serveru, záleží.
5
Windows a jiné systémy / Re:Vlastnosti macOS pro linuxáka
« Poslední příspěvek od fortran1986 kdy Dnes v 00:37:55 »Já jsem si koupil nový MacBook s M1, ale z toho systému bych se osypal, takže jsem jej dal na používání dětem, kteří si na tom pouští pohádky.
Problém není při práci v konzoli, ale to grafické prostředí je příliš jiné. Já jsem zvyknutý pracovat s i3wm a to tam nejde snadno zprovoznit a přehazovat se v oknech jak to dělají ostatní mi přijde jako krok zpět. Překvapivě mi i přišlo, že spousta věcí je složitější a nejsou tak elegantní jako v Linuxu. Např. repozitáře programů k instalaci nejsou úplné a je mnohem častěji potřeba instalovat stahováním někde z webových stránek.
Děti asi také půjdou brzy na Linux a ten notebook dám úplně pryč.
Jediná výhoda je kvalitní hardware, nízká spotřeba a dlouhá výdrž baterií. Ten systém ale není pro každého a hrozí, že když si něj zvyknete, nebudete se cítit doma zase třeba v Linuxu nebo Windows.
A je problém tam hodiť Linux alebo FreeBSD? Majú to tam nejako zablokované.
Ja teda neviem tiež uvažujem nad Macom, ale primárny OS by som chcel:
1. FreeBSD
2. Windows 11 (.NET vývoj)
3. Mac OS možno na hrajkanie sa s Mac only technológiami (Swift)
6
Sítě / Re:Venkovní síťový kabel na 300 m a 1 Gbit
« Poslední příspěvek od googler2 kdy Dnes v 00:36:49 »Na tu coax alternativu som sa zabudol pozriet (uz mi to tu niekto zmienikl)...No to na prvy pohlad vypada o dost jednoduchsie ako optika, teda ak netreba riesit rozne (kompatibilne) frekvencie konvertorov, mody, ohmy, konektory, moduly, pocet vlakien atd 
7
Vývoj / Re:Prečo nie je Lisp populárnejší?
« Poslední příspěvek od Kit kdy Dnes v 00:27:12 »8
Windows a jiné systémy / Re:Vlastnosti macOS pro linuxáka
« Poslední příspěvek od fanoush kdy Dnes v 00:26:50 »zadna udrzba jako na widlich.jako ze na obou neni?
nebo na windows je a na macos neni? v tom pripade co si mam pred tou udrzbou navic ve windows co v macos neni predstavit?
9
Vývoj / Re:zobrazenie obrázkov z DB na webe bez koncovky.
« Poslední příspěvek od fortran1986 kdy Dnes v 00:24:33 »AI mi radí použiť k SQL Serveru ešte noSQL
Redis, Memcached, atď
Ale ja neviem je to dobrý nápad? neni to kanón na vrabce? Ono by sa to dalo použiť neskôr aj na iné optimalizácie nie?
Redis, Memcached, atď
Ale ja neviem je to dobrý nápad? neni to kanón na vrabce? Ono by sa to dalo použiť neskôr aj na iné optimalizácie nie?
10
Vývoj / zobrazenie obrázkov z DB na webe bez koncovky.
« Poslední příspěvek od fortran1986 kdy Dnes v 00:19:45 »Ahojte v mojej web platforme ukladám obrázky do DB. Mám tam aj plnú velkosť obrázka a k tomu dva náhľady v rôznych velkostiach (MD, SM, Full):
Hlavný obrázok je uložený v takom formáte v akom ho nahral užívateľ (v prípade, že ide o webový formát teda webp, jpeg, png, gif, avif ak to neni webový formát napr psd, raw alebo tiff systém si ho skonvertuje do webp a uloží) a k nemu je v tabulke stĺpec contentType aby sme vedeli aký formát obrázok používa.
K databáze som spravil ImageCacheService ktorý tieto obrázky lazy metódou ukladá do filesystemu a keď treba posiela ku klientovi (je to rýchlejšie ako priamo select do db). Ak je v DB novší obrázok ako je dátum obrázka na disku obrázok sa prepíše verziou z DB. názvy obrázkov sú GUIDy tiež z DB tabulky a k nim som pridal extension (podla formátu) nakoľko súbory majú extension http server ich posiela so správnym mime type. Premýšlam ale že tie extensions vypnem. Aby som prípadným zlodejom podľa možnosti skomplikoval sťahovanie obrázkov. Viem že to neni veľká kompikácia (preto tam davam aj vodoznak atd) ale bol by som rád keby moje obrázky vyzerali takto:
a nie takto:
ide len o to že tie mime types sú v DB a ja som robil cache koli tomu aby som nerobil zbytočne veľa prístupov do DB, keď koncovku vypnem, ako zistím mimeType obrázka? Mám si urobiť nejakú ďalši in-memory cache na mimeTypes? Alebo na to použijem noSQL databázu. Keby išlo o malý web tak to vyriešim nejakým actorom s ConcurrentDictionary. Ale na webe budú možno aj 10tky miliónov obrázkov. Takže potrebujem riešenie ktoré do pamate načíta tie obrázky ktoré sa bežne načítajú a tie ostatné čo sa málo používajú, by mohol postupne čistiť garbage collector. Určite nechcem všetko v pamati.
Hlavný obrázok je uložený v takom formáte v akom ho nahral užívateľ (v prípade, že ide o webový formát teda webp, jpeg, png, gif, avif ak to neni webový formát napr psd, raw alebo tiff systém si ho skonvertuje do webp a uloží) a k nemu je v tabulke stĺpec contentType aby sme vedeli aký formát obrázok používa.
K databáze som spravil ImageCacheService ktorý tieto obrázky lazy metódou ukladá do filesystemu a keď treba posiela ku klientovi (je to rýchlejšie ako priamo select do db). Ak je v DB novší obrázok ako je dátum obrázka na disku obrázok sa prepíše verziou z DB. názvy obrázkov sú GUIDy tiež z DB tabulky a k nim som pridal extension (podla formátu) nakoľko súbory majú extension http server ich posiela so správnym mime type. Premýšlam ale že tie extensions vypnem. Aby som prípadným zlodejom podľa možnosti skomplikoval sťahovanie obrázkov. Viem že to neni veľká kompikácia (preto tam davam aj vodoznak atd) ale bol by som rád keby moje obrázky vyzerali takto:
Kód: [Vybrat]
<img src="5b17f8185e71449983e3600a0c2d8527">a nie takto:
Kód: [Vybrat]
<img src="5b17f8185e71449983e3600a0c2d8527.webp">ide len o to že tie mime types sú v DB a ja som robil cache koli tomu aby som nerobil zbytočne veľa prístupov do DB, keď koncovku vypnem, ako zistím mimeType obrázka? Mám si urobiť nejakú ďalši in-memory cache na mimeTypes? Alebo na to použijem noSQL databázu. Keby išlo o malý web tak to vyriešim nejakým actorom s ConcurrentDictionary. Ale na webe budú možno aj 10tky miliónov obrázkov. Takže potrebujem riešenie ktoré do pamate načíta tie obrázky ktoré sa bežne načítajú a tie ostatné čo sa málo používajú, by mohol postupne čistiť garbage collector. Určite nechcem všetko v pamati.
