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.
Ty floaty nejsou moc dobrý příklad. Tam se nějaký nedeterminismus hledá dost těžko.Jenže řeč nebyla jen o nedeterminismu, ale Tomas-T to rozšířil na všechny případy, kdy se kvůli zlevnění akceptuje občasný „chybný“ výsledek.
Já mám pocit, že se tenhle stochaisticný přístup k návrhům začne brzy dostávat/asi už dostává i do HW.Jako že by se třeba prodávaly paměti, které nemají kontrolní součty, takže občas může dojít (třeba vlivem kosmického záření) k překlopení bitu? Nebo že by se desetinná čísla reprezentovala tak, že půjde uložit jenom vybraná čísla a ostatní se „zaokrouhlí“ na nejbližší reprezentovatelné číslo?
Když dáte marketingu vybrat zda chce, aby procesor spočítal se 100% jistotou že 1+1=2 za 10 ms nebo do s 99,99999% pravděpodobností odhadl za 1 ms, co si asi vybere? 10x rychlejší procesor.
I kvantové počítače jdou tímhle směrem.
Na nektere veci je ChatGPT lepsi nez SO.Třeba ve vymýšlení si knihoven a funkcí, které neexistují :-)
ChatGPT funguje podobne jako Github copilot.Jestli se nemýlím, Copilot je postavený na předchozí generaci téhož modelu, jako ChatGPT, a je speciálně trénovaný na kód.
Tenhle přístup mne, co by inženýra dost děsí. Trochu mi to zavání rezignací. Nevíme jestli je to evoluce nebo rakovina. Prostě to neumíme nadesignovat, uřídit, tak to necháme jak se to vyvrbí. Evoluce funguje, ale v řádech miliónů let se spoustou slepých uliček a masových vymírání. Jsem stavební inženýr, trochu něco tuším o strojařině, a tam jen idea systémů, které nejsou 100% deterministické je nepřijatelná fantasmagorie.Já to nepovažuju za rezignaci. Narazili jsme na limity, tak jsme vymysleli, jak to hacknout a limity obejít. Jako když jsme zjistili, že lepší dalekohled v optickém spektru už na Zemi nepostavíme, protože nám brání zkreslení atmosférou, tak jsme to hackli a vystřelili jsme dalekohled do vesmíru, mimo atmosféru.
Jsem 100% pro fault tolerant systémy, nicméně ty systémy stále musí být deterministické. Jinak se inženýrská práce mění v alchymii.Ne v alchymii, ale v poctivé řemeslo. A poctivé řemeslo je super věc.
To je právě projev krize IT. Místo nástrojů, které by programátorům umožňovaly psát optimální kód, tak tu máme nástroje, které umožňují psát programátorům kód efektivně. Místo toho, aby se řešila komplexita kódu, konzistence API, tak máme nástroje, které umožní produkovat kód v prostředí s nekonzistentním, duplicitním API, nejasnými závislostmi. Za komplexitu se ale vždy platí, vyšší křehkostí (opak robustnosti), vyššími náklady, větší specializací, menší obecností.Není to projev krize IT, je to naopak ukázka toho, proč IT změnilo svět.
Obmädzovať dĺžku vstupných polí má zmysel hlavne z hľadiska security (data sanitation, input validation).Zranitelnosti typu XSS se nemůžou řešit omezením délky polí. I do vašich 255 znaků se může XSS vejít.
Nemá zmysel povoliť niekomu pasntúť do poľa pre meno 4KB dát, ktoré môžu potenciálne obsahovať XSS a iné zranitelnosti.
Ja osobne by som dĺžku emailovej adresy obmädzil na 255 znakov plus regexp na validnú email adresu.Validace se opravdu nedělají tak, že budete ignorovat standard a vycucáte si nějaké číslo z prstu. S tímhle přístupem si koledujete i o bezpečnostní chybu.
Obecně s tím souhlasím, je nesmysl vymýšlet si nějaká omezení, která nemají žádné reálné opodstatnění – hrozí akorát to, že někomu bezdůvodně odepřu přístup nebo něco neumožím. (Obzvlášť miluju validace e-mailu, které se snaží podle domény uhodout, zda jde o pracovní nebo soukromý e-mail, takže některé domény odmítají.)Zkuste se, když vyvíjíte zamyslet - co tím chcete získat, je to, co se snažíte řešit, opravdu objektivní problém? Nebo se vám "jenom nezdál něčí email"?
Nebo ta délka někde dělala nějaký problém?
Tohle bych doporučil vytisknout velkými písmeny a jako trest za porušení vytesat do kamene. Pokud něco tvořím, přemýšlím především o tom, kterým omezením uživatele se opravdu nedokážu (z hlediska cena/efekt) vyhnout. Abych si přidělával práci s tím, že budu komplikovat život uživatelům - no, v životě jsem udělal spoustu hovadin, ale tohle asi ne.
Přesně jak tu píše spousta lidí - pokud nemáte extra důvod, použijte pro validaci e-mailu knihovní funkci a nevymýšlejte kolo. A když už, tak ho aspoň nedělejte hranaté, protože kulaté se vám zdá zbytečné.
A ktery zakon mate na mysli? Ja jenom, ze stackoverflow ma HQ v New Yorku a nemyslim, ze pro pouziti cehokoliv ze stackoverflow bude rozhodujici nejaky cesky zakon.Kde má sídlo StackOverflow je úplně jedno, autorské právo se řídí podle občanství autora. A autorské právo je řešené mezinárodními smlouvami, ze kterých vychází národní legislativa. Takže pro začátek se stačí řídit českým autorským zákonem. Pokud budete potřebovat detaily, které se mohou mezi různými státy řešit, budete se na to ptát právníků a ne ajťáků na root.cz.
Aj licencovaný software môže byť voľný...Veškerý software je licencovaný. Když k softwaru nemáte licenci, nemůžete ho používat (pokud nejste jeho autor).
Mimochodem, když odesílám e-mail přes STARTLS, Tak po tomto příkazu (EHLO,STARTTLS,EHLO,MAIL FROM) zase se začíná od EHLO. Jaká je praxe při kontrole EHLO, pokud se použije pokaždý jiný EHLO string (ano, nedává to smysl...), kontrolují se obě nebo jen tam první nebo ta po STARTTLS nebo stačí když vyhoví jedna?Myslím, že na tohle máte někde ve zdejším odkladišti svoje téma. Netahejte to prosím sem, kde se řeší reálné problémy.
Root.cz (www.root.cz), informace nejen ze světa Linuxu. ISSN 1212-8309
Copyright © 1998 – 2023 Internet Info, s.r.o. Všechna práva vyhrazena. Powered by Linux.
