Google zveřejnil seznam 1220 projektů od 195 organizací (Debian, GNU, openSUSE, Linux Foundation, Haiku, Python, …) přijatých do letošního, již dvacátého, Google Summer of Code.
Na základě DMCA požadavku bylo na konci dubna z GitHubu odstraněno 8535 repozitářů se zdrojovými kódy open source emulátoru přenosné herní konzole Nintendo Switch yuzu.
Webový prohlížeč Dillo (Wikipedie) byl vydán ve verzi 3.1.0. Po devíti letech od vydání předchozí verze 3.0.5. Doména dillo.org již nepatří vývojářům Dilla.
O víkendu probíhá v Bostonu, a také virtuálně, konference LibrePlanet 2024 organizovaná nadací Free Software Foundation (FSF).
Nová vývojová verze Wine 9.8 řeší mimo jiné chybu #3689 při instalaci Microsoft Office 97 nahlášenou v roce 2005.
Coppwr, tj. GUI nástroj pro nízkoúrovňové ovládání PipeWire, byl vydán v nové verzi 1.6.0. Zdrojové kódy jsou k dispozici na GitHubu. Instalovat lze také z Flathubu.
Byla vydána dubnová aktualizace aneb nová verze 1.89 editoru zdrojových kódů Visual Studio Code (Wikipedie). Přehled novinek i s náhledy a animovanými gify v poznámkách k vydání. Vypíchnout lze, že v terminálu lze nově povolit vkládání kopírovaného textu stisknutím středního tlačítka myši. Ve verzi 1.89 vyjde také VSCodium, tj. komunitní sestavení Visual Studia Code bez telemetrie a licenčních podmínek Microsoftu.
Proton, tj. fork Wine integrovaný v Steam Play a umožňující v Linuxu přímo ze Steamu hrát hry určené pouze pro Windows, byl vydán ve verzi 9.0-1 (𝕏). Přehled novinek se seznamem nově podporovaných her na GitHubu. Aktuální přehled her pro Windows běžících díky Protonu také na Linuxu na stránkách ProtonDB.
Byla vydána verze 1.78.0 programovacího jazyka Rust (Wikipedie). Podrobnosti v poznámkách k vydání na GitHubu. Vyzkoušet Rust lze například na stránce Rust by Example.
Služba Dropbox Sign (původně HelloSign) pro elektronické podepisování smluv byla hacknuta.
Tiskni Sdílej:
Autor asi myslel o dost méně pracnější. S rychlostí to imho nemá co dělat, leda tak s rychlostí bastlení.
Benchmarky vskutku nemám, je to spíš můj úsudek, že select na jedny tabulce s vhodnými indexy je rychlejší než selecl na více tabulkách.Myslím, že za ty desítky let vývoje relačních databází by se na to už přišlo, že jsou relační databáze nesmysl a je lepší vše nacpat do jedné tabulky. Stačí si uvědomit, že u řídké tabulky se musí z disku načíst mnohem víc dat (i ty prázdné nebo nezajímavé hodnoty, které nepotřebuju), a načítání z disku je ta nejdražší operace.
nestoji to za dalsi cas straveny vyvojom a vrstvenim roznych tabuliUznávám, že výkon zde asi není tak důležitý, ale udělat kvalitní návrh takovéto DB nezabere až tolik času a hlavně to hodně práce ušetří v budoucnu, při rozvoji aplikace, úpravách. Normální formy a další doporučení pro návrh databází nejsou jen akademické bláboly, má to svůj smysl. Efekt je např. v tom, že při přidání další služby prostě jen přidám záznam do číselníku služeb (DML operace) a nebudu musel upravovat tabulky (DDL operace) ani aplikaci – což v případě, kdy je vše namaštěné v jedné tabulce, musím.
To, ze ldap musi navrhovat nekdo se 'zkusenostmi' jak pisete je problem tohoto nastroje.Neřekl bych, že je potřeba mít o tolik víc znalostí než pro návrh kvalitního schématu relační databáze. Spíš bych řekl, že to bude naopak – u LDAPu tě vedou ty standardizovaná schémata (nejužitečnější vlastnost LDAPu), zatímco u návrhu schématu relační databáze autora většinou jen „selský rozum“, pocity jak by to „mělo vypadat“ (podle toho to pak dopadá) a v lepších případě zkušenosti a načtené teorie z knih. U LDAPu tam člověk vrzne ty struktury, které už vlastně dostal naservírované a nemá toho tolik co zkazit (jasně, třeba uspořádání toho stromu se dá zkazit, ale není tam taková volnost jako u relační DB). Dřív jsem byl z LDAPu hodně nadšený, ale časem to vyprchalo. U jednodušších systémů je problém, že má člověk uživatele na jednom místě (LDAP) a ostatní data na jiném místě (např. SQL databáze) a mezi nimi nefunguje referenční integrita a záznamy je potřeba synchrozizovat. Také čím dál víc aplikací umí ověřování vůči SQL databázi, nejen vůči LDAPu. U složitých systémů se zase člověk nevyhne nějakému tomu IDM, takže pak zase není problém, aby aplikace měly svoje (relační) databáze uživatelů a IDM to všechno režíroval. LDAP se pak hodí hlavní pro nějakou tu prostřední kategorii (kdy ještě IDM není potřeba) a ta je celkem úzká. Asi nejzajímavější je mít data v relační DB a nastavit LDAP server tak, aby fungoval jako rozhraní k této SQL databázi pro aplikace, které LDAP potřebují – pak má člověk jak relační tak LDAPový přístup k uživatelům a data jsou na jednom místě.
LDAP neslouží jen pro autentizaci uživatelů, to je jen jeho zjednodušené chápání. Lze do něj ukládat k jednotlivým záznamům fotografie uživatelů, čísla kanceláří, telefonní čísla, číslo přiděleného služebního auta, reference na nadřízeného apod.Do LDAPu toho jde dát opravdu hodně, ale potíž je v tom, že se tam nevejde úplně všechno – není tak univerzální jako relační databáze, kterou nakonec člověk stejně má. A potom je část dat tam a část tam – proto mi přijde vhodnější použít LDAP jen na ověřování a všechny ostatní data mít jinde (datová vrstva aplikace nemusí pracovat se dvěma protokoly ale jen s jedním).