1. Fórum Root.cz
  2. Profil Logik
  3. Zobrazit příspěvky
  4. Příspěvky

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.


Příspěvky - Logik

Stran: 1 ... 10 11 [12] 13 14 ... 68
166
Server / Re:Migrace RAID 5 ze tří disků na čtyři
« kdy: 22. 02. 2021, 17:11:45 »
Citace
Jediná ztráta oproti hot spare disku je ta časová ztráta než další disk doplníte.


Pokud algoritmy na expanzi počítají s možností tuto expanzi po chybě "zresuscitovat a pokračovat v ní". Což nemusí být pravidlem....

167
Server / SAMBA - change UID
« kdy: 22. 02. 2021, 12:45:15 »
Ahoj,
mám sambu s user LDAP backendem jako domain controller. Jednoho uživatele mi samba založila s UID 65535, což je problém, protože toto ID se někdy mapuje na "uživatel nenalezen". Potřeboval bych ho změnit.


Pomocí ldbedit jsem změnil user id v souboru
/var/lib/samba/private/sam.ldb
Začalo se to chovat divně, jako by měl uživatel dvě uid, někdy se použilo to, někdy to. Podle
https://www.blackhole-networks.com/Cheatsheets/Samba4Map/
jsem našel, že ještě musím změnit
/var/lib/samba/private/idmap.ldb
ale ani to nepomohlo, pořád mi to vrací spíš toho starýho uživatele, než toho novýho (i po restartu),
ale zná to obě uid uživatele (viz níž).


Evidentně ještě někde zůstává starý UID. Ale kde? Nevíte někdo?


Dík


Kód: [Vybrat]

root@server:~# wbinfo --sid-to-uid S-1-5-21-154350746-2280197263-2174721776-1106
65535

root@server:~# wbinfo --uid-to-sid 65535
S-1-5-21-154350746-2280197263-2174721776-1106
root@server:~# wbinfo --uid-to-sid 65540
S-1-5-21-154350746-2280197263-2174721776-1106


root@server:~# id -u logik
65535
root@server:~# id -un 65535
DOMAIN\logik
root@server:~# id -un 65540
DOMAIN\logik


168
Server / Re:Migrace RAID 5 ze tří disků na čtyři
« kdy: 21. 02. 2021, 02:21:11 »
Já bych to formuloval:
Když něco manipuluji s diskovým polem, tak musím předpokládat, že až to pokoním, se něco stane i se zálohou a mít v takovém případě zálohu zálohy :-)

169
Vývoj / Re:Python zaokruhlovanie na cele cislo nefunguje spravne
« kdy: 19. 02. 2021, 18:49:05 »
Mlocik:To ale zacházíš se znalostí původních nezaokrouhlenejch čísel. Todle řeší problém, když nejdřív zaokrouhlíš, a pak Tě napadne spočítat průměr. Tam už nijak nevyřešíš, že průměr čísel 0.5,1.5 Ti vyjde 1.5, protože dostaneš čísla 1,2 a z nich nijak nevyčteš, co byly původně.
Zatímco  u velkých sad čísel (pokud tedy nemají nějaké obskurní rozdělení), když to zaokrouhlíš tím IEEE způsobem, tak se Ti chyba "požere"  s poměrně velkou statistickou jistotou.

PS: A úplně nejlepší je takovej průměr znova zaokrouhlit. Vyjde Ti, že průměr čísel 0.5 a 1.5 je 2....

170
Vývoj / Re:TCP bezpečnost
« kdy: 06. 02. 2021, 22:15:26 »
Citace
Samozřejmě, ale tazatel je bohužel v situaci, že tam plnohodnotnou knihovnu pro TLS nedá,
IMHO jediná správná cesta je takové zařízení oddělit od NETu něčím, co zvládne spolehlivý ověřený
transportní protokol(ať už nějakou VPN, TLS, nebo nevímco).Cokoli jiného je hezké pro naučení se, ale jinak to bude vždycky ve výsledku dražší a přitom děravé.

171
Server / Re:SAN - profesionální řešení okolo 50 tisíc, resp. do 100 bez disků
« kdy: 01. 02. 2021, 14:49:45 »
Citace
a Vy důvěřujete jemu, že Vás podrží, kdyby se něco zvrtlo.
To je dobrá poznámka. Jedna z věcí, které si člověk draze platí u enterprise řešení je "přenesení zodpovědnosti".Tedy, že když se něco zvrtne, tak sice to firmu stojí třeba úplně stejně, jako když selže adminovo "samodomo" řešení,ale admin může říci: použil jsem enterprise hardware, víc jsem udělat nemohl.

172
Vývoj / Re:Python zrychlenie kódu
« kdy: 19. 01. 2021, 15:27:12 »
hejch:
Citace
. IN ti dotaz nezrychlí.
To bych se hádal. Načtění X záznamů z databáze najednou oproti načítání řádek po jednom zrychlí přístup do databáze v podstatě vždy. To je můj "denní chleba".

kit:
Citace
Že je IN ptákovinou, jsem zjistil po prvním benchmarku, ve kterém propadl.
Nejlepších výsledků jsem dosáhl, když jsem data nahrál do dočasné tabulky a provedl JOIN. Indexy zafungovaly a jelo to jako blesk.
Co já mám (s postrgresem) zkušenosti, tak hromadné načtení záznamů pomocí IN je vždy rychlejší, než načítání "po jednom", a nijak výkonnostně netrpí.Naházení do dočasné tabulky se dá udělat i jednodušeji pomocí
Kód: [Vybrat]
WITH data AS (
     VALUES (....),(...)
) 
SELECT .....
ale nevidím důvod, proč by takovýto join měl proběhnout rychleji než operátor IN. Co jsem si teď zkusil na svejch malejch datech, tak IN byl rychlejší než JOIN (0.100-0.300ms versus 0.400-0.800ms), a lišili se i trochu v plánech (IN použil bitmap index scan, zatímco JOIN použil jen čistej index scan). Pokud jsem použil JOIN na temporary table, tak bez VACUUM ANALYZE na tu temporary table se použil sekvenční scan, po ANALYZE se použil stejnej plán, jako u JOINu na "WITH data AS ....".

Jaký výsledky a jaký plány to generuje Tobě?


Wangarg:
Citace
Kód: [Vybrat]
root.get_child(["0:Objects", "4:new_Controller_0", "3:GlobalVars", tag_string])
nie je tam asi 5000 premennych a ja musim citat zapisovat len konkretnu. S tymto si presne adresujes.
No podstata mého dotazu je, že začátek tý adresace je vždy stejný, takže by to mělo jít znova použít. Navíc, nejde náhodou o todle?
https://github.com/FreeOpcUa/python-opcua/
Pokud ano, tak opravdu po stromě lezeš (jen to nevíš :-)), takže můžeš na začátku vyselektit ten 3:GlobalVars a pak už jen hledat ten podřízenej nod podle tagu. Ale třeba se pletu?

173
Studium a uplatnění / Re:Štúdium fyziky
« kdy: 19. 01. 2021, 14:57:19 »
Jinak: koukni se na obor biomechanika na FAV v Plzni.

174
Vývoj / Re:Python zrychlenie kódu
« kdy: 18. 01. 2021, 17:08:58 »
Nejprve si zjisti (pomocí profileru), co vlastně trvá dlouho. Databáze?
Pak pomocí
Kód: [Vybrat]
WHERE tag IN ( ...,...,...,....) ORDER by tag
to načti z DB najednou a zpracovávej to v Pythonu.Pokud sql dotaz trvá dlouho, tak Ti asi taky schází index na políčku tag v databázi?

Ale jinak je ten kód podivnej, co je např.
Kód: [Vybrat]
OPC_Output_write = root.get_child(["0:Objects", "4:new_Controller_0", "3:GlobalVars", tag_string])
To je nějaký lezení po stromě? Pak určitě se nemusí pokaždé lézt znovu z kořene, ne?

175
Odkladiště / Re:Elektrická zásuvka - rozbočovač/rozvodka
« kdy: 04. 01. 2021, 19:49:24 »
qelurg: Seš si jistej? Z toho, co o tom vím (ne moc :-)), tak IMHO klidně můžeš na II zemnit např. kovovej kryt, kterej je od živé části oddělenej patřičnou izolací.  IMHO norma nezakazuje připojení PE vodiče k spotřebiči třídy II, ale jen požaduje, aby toto připojení bylo izolované od živých části stejně, jako "uživatel". Ale rád se nechám poučit, pokud to je jinak....
A v jakém případě je PE připojení zdroj rizika? Když teda neberu to, že to je "zfušovaný" a přístroj neplní ani požadavky na I, ani na II, nebo když je mezi PE a živejma částma nedostatečná izolace, která může vést k požáru?

176
Vývoj / Re:Vlastní SSD caching pro klasické FS
« kdy: 16. 12. 2020, 17:15:20 »
Když jsme u bcache - to je bloková cache. Předpokládám tedy, že když mám btrfs raid 0
ze dvou disků, tak musím udělat bcache nad těmi disky, tedy cachuju mirorovaná data.
Jak to bcache zvládá? Nedochází k tomu, že se nejčastěji čtená data cachují zbytečně dvakrát?

177
Bazar / Re:Sháním backplate pro AM4
« kdy: 11. 12. 2020, 21:59:54 »
by_cx: Dík, viz PM

178
Bazar / Re:Sháním backplate pro AM4
« kdy: 11. 12. 2020, 11:08:55 »
Nikdo nemáte? Např. z kikslý desky pro AM4? Nebo nevíte, kde by šel v rozumnym čase sehnat (ebay vím)?

179
Bazar / Sháním backplate pro AM4
« kdy: 10. 12. 2020, 10:55:22 »
Neválí se Vám náhodou někomu někde backplate pro socket AM4, kterýho byste byli ochotni se (za rozumnou protihodnotu) zbavit?


180
Sítě / Re:100 Mbit, 1GBit, 10 GBit, 40 GBit k čemu vlastně?
« kdy: 23. 11. 2020, 13:53:45 »
Citace
Popravde jsem jeste nepotkal spravne zapojenej Cat5
Já jo. Čínskej kabel, od pohledu tloušťka drátečků jak u nejlevnějšího telefonního, kroucení pouze symbolický (u konektoru desítky centimetrů rozkroucený).....

Stran: 1 ... 10 11 [12] 13 14 ... 68