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.
Tohle je trochu problém GoNa Go jsem právě myslel, když jsem to psal. Ten jejich error handling mě fakt otravuje. Neexistence výjimek a generik mě osobně na Go vysírá nejvíc.
jsou to dvě strany téže mince.Co? Co je jedna strana a co druhá? A jaké jedné mince?
A ano, pak se všichni diví, kolik že jsme měli těch bezpečnostních děr za minulý týden?Bezpečnostní chyby jsou imho nejčastěji špatné implementace nějakého algoritmu, špatná kontrola vstupů nebo mezí polí. Ani jedno není způsobeno jedním nebo druhý přístupem k chybovým stavům.
Způsobuje separaci místa vzniku chyby od místa jejího zpracování, a to i vertikálně, přes úrovně jednotlivých vrstev, což je IMO zlo. [...] A tak se na to kašle, nechá se to zpropagovat až kdo ví kam a tam se teprve chyba řeší. Jenže takové místo je z hlediska struktury, tj. viditelnosti a rozsahu platnosti jednotlivých entit, izolované od místa vzniku. Vlastně už se tam nedá dělat nic, než jen vzít na vědomí, že "někde dole" vznikla chyba...což je přesně to, co u velkého množství programů chceš. Nějaký velký blok kódu řeší jednu věc, například načtení credentials, připojení na server, autentizace. Nechceš řešit všechny možné chybové stavy u všech jednotlivých kroků. Chceš na nejvyšší úrovni dostat informaci "nemohl jsem se připojit, protože ..." (nelze se připojit k DB, credentials jsou neplatné, server je nedostupný apod.)
A že autodetekce kódování může selhat, je možná úsměvné, ale žádná tragedie to není. Dá se to zvolit ručně.Když se program tváří, že něco umí a ve skutečnosti to tragickým způsobem neumí, tak to není úsměvné, ale je to osina v (_|_), jako ostatně polovina věcí na Windows.
Windows to plně podporují od verze NT 4.0Jasný. Plně. Akorát sem tam převedou anglický text na čínštinu, ale to je detail
) https://en.wikipedia.org/wiki/Bush_hid_the_facts
Nevím o tom, že by POSIX vynucoval cokoli jiného než že název nesmí obsahovat "/".Aha, myslel jste "fully portable filenames", tak to jo.
V systémech, které pracují v UTF-8 by to být problém neměl (Win NT 4.0+).Windows nepoužívají UTF-8, jak již řečeno výše.
Někdy bývá v IT nastavené pravidlo tak, aby byl subset znaků použitelný pro více OS, pak se nejčastěji vychází z POSIXU.Nevím o tom, že by POSIX vynucoval cokoli jiného než že název nesmí obsahovat "/".
V praxi, kdybych nastoupil k zaměstnavateli, tak bych to nejprve respektoval. Kdybych ani po cca 3-6 měsících neviděl důvod pro takové pravidlo, inicioval bych změnu pravidla.Uživatel nemusí důvod vidět. Může to být např. proto, že nějaký interní systém (NFS, zálohování apod.) má s takovými soubory problém.
díky za informace, zajímavá je ta poznámka o té paměti - mně teď napadá, ze i ten snapshot té VM asi také ten obsah té RAMky neobsahuje :-)Snapshoty běžícího stroje image RAM obsahují (viz https://pve.proxmox.com/wiki/Live_Snapshots) a je to potřeba i pro live migraci. Jestli to platí i pro zsync, to nevím, zatím jsem to neměl potřebu zkoumat.
a i ty transakce budou možná problém. Tedy prinejmenším se asi bude muset dělat recovery při startu záložního VM - ale to asi dělají všechny pořádné DB při bootu automaticky.Recovery by měla každá rozumná DB zvládnout dobře, v tom bych problém neviděl. Spíš v tom, jestli se dá opravdu spolehnout na fsyncování změn.
díky za podnětný návrh. Jestli jsem to dobře pochopil, jedná se o HA řešeníZsync není opravdové HA řešení. Opravdové HA musí vypadat nějak takhle:
, které 'mý být' méně náročné na správu. To je trochu náš problém a obávám se, že se o to musí někdo starat. Proto bych rád vědel, co to v běžném provozu obnáší.ProxMox je klikačka, se kterou se člověk seznámí rychle a údržbu vyžaduje takovou, jako jakýkoliv linuxový stroj (hlavně updaty, případné restarty). Výhodou je, že virtuály se dají migrovat, takže je možné virtuál odmigrovat, stroj updatovat, restartovat. Totéž na druhém stroji.
Někdo tady napsal, že s verzí 4 měl problémy, verze 5 je z cervna 2017 - tedy relativně nová věc. A i ty připomínky ohledně ZFS jsou trochu znervózňující.To se týká výlučně ZFS. ProxMox má víc druhů úložišť. Já jsem chtěl ZFS hlavně proto, že s ním mám zkušenost. Bohužel na Linuxu je to se stabilitou asi tak stejný jako na FreeBSD před sedmi lety...
Za jak dlouho je možno odhadem se do problematiky zapracovat? (máme 20 let zkušenosti s unixem). Běží to skutečně bezproblémově?Týden zkoušení člověkem, který má aspoň nějaké povědomí o Linuxu a aspoň trochu tuší, co bude dělat. Pak nějakou dobu na ne-produkční testování - jak dlouho záleží na tom, jak moc velkou jistotu chce člověk mít...
Jenže ouha, oslovil jsem několik hypotečních poradců a sám jsem obešel snad všechny banky, které u nás hypotéky poskytují. Banky nejsou schopny akceptovat příjmy z kapitálového majetku a už vůbec ne pokud pochází ze zahraničí. Nakonec mi poradci poradili, že mi nezbude nic jiného, než založit české eseróčko a udělat si pracovní smlouvu. Protože když si udělám pracovní smlouvu se svojí anglickou firmou, tak to nic neřeší, české banky nebudou ochotné/schopné zkoumat zdroj příjmů a ověřovat anglické daňové přiznání mé firmy.To je dost zvláštní teda. Možná je to tím, že jsi to řešil 7 let zpátky a od té doby se úvěrový trh dost posunul? Páč dneska by to neměl být vůbec problém, viz např. https://www.fio.cz/bankovni-sluzby/uvery/americke-hypoteky (sazba je jenom o procento vyšší než u normální hypotéky, což se dá, zvlášť když je tam možnost offsetu, který využiješ, pokud máš velké přijmy).
doporucuju proxmox5 a zsyncKdyž zmiňuješ proxmox a ZFS, jaký s tím máš zkušenosti? Já jsem byl silně rozčarovanej nad stabilitou 4ky: dokud byl swap na zvolu, padalo to jak hrušky. Když jsem ho zrušil, bylo to lepší, ale pořád ne úplně stabilní. 5ka zatím vypadá být úplně v pohodě (fingers crossed).
Kdybyste někdo chtěli svobodnější práci zkusit, právě hledám kolegu: https://forum.root.cz/index.php?topic=16043.msg221636
Hask se může brát jako prostě nějaká obecná kartézsky uzavřená kategorie s morfismy jako vyjádřitelnými funkcemi (bez ohledu na vyčíslitelnost, on i takový halting problém je při vhodné restrikci rozhodnutelný, zrovna před rokem jsem o tom viděl hezkou přednášku na Oxfordu, ale to odbočuju). Rozklad morfismu je předpoklad pro to tvrzení, čili například f.g.h (wlog stačí uvažovat binární rozklad). Když si ho zadáš jako f.id, tak klidně můžeš, jen to pak je poměrně triviální. To tvrzení říká, že můžu jít jinou cestou (přes jiné objekty dané kategorie), přičemž ty morfismy na alternativní cestě jsou restrikcemi těch původních a když vyberu epimorfismy, tak budou vyčíslitelné, je-li jejich kompozice taktéž.Ok, díky, to už mi trochu začíná dávat smysl.
Ta otázka je nepřesná, zřejmě jde o to, že když mám vyčíslitelný morfismus a nějaký jeho rozklad, tak z něj vždy dostanu takový rozklad, kde každá komponenta je restrikcí nějaké dané a zároveň vyčíslitelná, protože můžu vždy jít přes epimorfismy. Existence je zaručená, protože všechny morfismy jsou totální funkce. Důkaz je přes komutativní diagramy celkem názorný (byť ne zcela triviální).To's mi to teda pořád moc neosvětlil
"Vyčíslitelný morfismus" je co? Pokud se bavíme o Hasku, jsou morfismy funkce a vyčíslitelné jsou z definice (Hask iirc neobsahuje bottom).
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.