Erin Catto, autor open source 2D fyzikálního enginu Box2D (Wikipedie), představil nový 3D fyzikální engine Box3D. Engine je již používán ve hře The Legend of California.
Byla vydána nová verze 4.0.0 multiplatformního svobodného frameworku pro zpracování obrazu G'MIC (GREYC's Magic for Image Computing, Wikipedie). Přehled novinek i s náhledy nových filtrů na PIXLS.US.
Český statistický úřad (ČSÚ): Průměrná hrubá měsíční mzda ICT specialistů v roce 2025 meziročně vzrostla o 6 % na téměř 100 tisíc korun. Nejlépe placeni byli vývojáři softwaru. Dlouhodobým trendem zůstává nízké zastoupení žen, a to jak mezi specialisty, tak studenty těchto oborů.
Ochranný svaz autorský (OSA) připravuje žalobu na společnost Suno, která umožňuje generování hudby pomocí umělé inteligence (AI). ČTK to sdělil předseda představenstva OSA Roman Strejček. Suno podle něj bez souhlasu využívá k trénování svých modelů hudbu autorů, které svaz zastupuje. Nedávný investigativní materiál magazínu The Atlantic ukázal, že firmy jako Suno nebo Udio k trénování modelů používají rozsáhlé databáze obsahující miliony skladeb. V databázích, které časopis zveřejnil, lze dohledat i písně řady českých a slovenských umělců.
Byl publikován přehled dění a novinek z vývoje Asahi Linuxu, tj. Linuxu pro Apple Silicon. Vyřešen byl problém s macOS 27 Golden Gate. Vývoj lze podpořit na Open Collective a GitHub Sponsors.
EU dnešním dnem zavedla clo ve výši 3 eur na balíky nízké hodnoty dovážené ze zemí mimo EU. To zahrnuje širokou škálu výrobků běžně nakupovaných on-line, jako jsou oděvy, hračky, elektronika a další spotřební zboží v hodnotě až 150 EUR.
Vyšel Redmine 7.0, jeden z nejlepších open source ticketovacích systémů. Došlo k migraci na Rails 8, vylepšení UI/UX, Workflow, byla přidána podpora náhledu pro Microsoft Office a LibreOffice dokumenty, došlo k výkonnostním optimalizacím a přibylo spoustu dalších oprav a novinek. Více informací v oficiálním oznámení.
Nové číslo časopisu Raspberry Pi zdarma ke čtení: Raspberry Pi Official Magazine 166 (pdf).
Blíží se prázdniny a než se rozutečete k moři, je na čase se opět sejít na Virtuální Bastlírně - pravidelném setkání elektroniků, ajťáků, bastlířů a obecně nadšenců do techniky. Co si pro vás strahovští bastlíři připravili tentokrát? Určitě proberou blížící se Linux Days i další události. U softwaru se chvíli zdrží a poví si kupříkladu o tom, jak se zbavit Bambu Cloudu, ale nepřijít o možnost ovládat tiskárnu na dálku. Řeč dojde i na AI,
… více »Vývojáři postmarketOS vydali verzi 26.06 tohoto operačního systému pro chytré telefony vycházejícího z optimalizovaného a nakonfigurovaného Alpine Linuxu s vlastními balíčky. Přehled novinek v příspěvku na blogu. Na výběr jsou 4 uživatelská rozhraní: GNOME, KDE Plasma Mobile, Phosh a Sxmo.
Pokud máte pravidelné zálohy dat, a nejlíp ještě nastavíte řadič RAIDu, aby pravidelně kontroloval povrch, tak by to asi mělo být bezpečné. Čím jednodušší hardware a čím nižší spotřeba elektřiny, tím vyšší spolehlivost / delší životnost. Ostatně už jsem tady o tom jednou klábosil... Některé modely mají 8x SAS na bázi LSI 1068 (FreeBSD driver mpt), šlo by to rozjet se softwarovým RAIDem ve FreeBSD. Pozor na jeden kus co má 8x SAS2 LSI2008, pro ten ještě není podpora ani ve FreeBSD CVS (ostatně ani driver pro Windows na LSI webu).
V databázovém enginu a v operačním systému, na kterém databáze běží, můžete jistě ladit nastavení VM, velikost bufferů apod... nicméně základní věc, na které stojí a padá výkonnost databáze, je definice indexů na atributy=sloupce, podle kterých se vyhledává / pomocí kterých se propojují tabulky v dotazech. A taky konstrukce dotazů (to je větší "makačka na bednu"). Tím jste se zabýval? Nebo jste použil hotový "redakční systém", u kterého se předpokládá, že toto je v pořádku, a jeho střeva do těchto detailů neřešíte?
Přijde mi zajímavé, že potřebujete pokud možno dostat celou databázi do RAMky, aby to chodilo použitelně. To může znamenat dvě věci:
1) při špičkové zátěži (která je dána aktivitou uživatelů) disky prostě nestíhají, ani při pečlivé optimalizaci. Může to být dáno skutečně velkým počtem uživatelů.
2) špatná optimalizace indexů nebo dotazů
Rád slyším, že o vytížení procesoru máte představu. Máte v těch grafech taky vidět IOps disků? V této souvislosti, pokud někde chybí index, tak to bude zvyšovat zátěž jak disků, tak procesoru. Finta s indexem spočívá v tom, že držíte v RAMce především data "identifikátorových" sloupců, která jsou krátká, takže nezaberou moc místa, a lze je snadno organizovat do binárních stromů pro rychlé porovnávání/vyhledávání (jsou takto v RAMce organizována). Koncová data (dlouhé texty, bloby) se pak tahají podle potřeby z disku.
Tradičně se databáze skutečně do RAMky nevejde, může zabírat třeba o řád nebo o dva větší prostor na disku, než kolik má stroj RAMky. Pak už záleží na zátěži aplikace v poměru k IOps disků, jestli bude výsledná latence pro koncového uživatele subjektivně snesitelná, nebo k nepoužití. Fakt je, že u mnoha internetových aplikací pro masu uživatelů prostě není jiná šance, než držet v RAMce celou databázi. Disky pak poskytují víceméně perzistentní uložení dat pro případ výpadku napájení.
RAID nenahrazuje zálohy. Netuším, zda jste schopen zazálohovat nastojato celý systém, a zase ze zálohy obnovit - třeba Ghost tuším neumí UFS, ale dobrý admin dokáže zazálohovat a obnovit systém nastojato i holýma rukama z bootovacího instalačního CDčka Dobrý nápad je, zazálohovat si alespoň konfiguráky, které Vám daly hodně práce (pro urychlení případné reinstalace) a pak samozřejmě data - statický obsah webu a obsah databáze. Záloha by měla probíhat někam mimo server. Stačí třeba nějaký obyčejný SATA disk v externím USB rámečku - důležité je, aby to zálohovací zařízení mělo svůj vlastní napájecí zdroj, protože když Vám v serveru shoří zdroj, tak poměrně často vezme ssebou board a disky. Když Vám shoří elektronika všech disků v RAIDu, tak je Vám parita na plotnách jaksi k prdu Ještě lepší je, zálohovat po síti někam kus dál, mimo stojan/místnost/budovu (pro případ požáru) - stačí mít někde k dispozici kus místa na fileserveru. Bavíme se řádově o gigabajtech, to je vcelku legrace.
Pokud se týče CPU (dnes Nehalem vs. Phenom): s procesory AMD nemám mnoho zkušeností, kvůli kompatibilitě mám radši Intel (CPU i čipset) - nicméně než přišel Nehalem, tak AMDčka kralovala v obasti latencí přístupu do RAMky (protože mají on-chip řadič RAM). To je přesně vlastnost, která hraje roli v databázové zátěži (práce s indexy, běh obecných aplikací). V případě FreeBSD bych měl možná maličko strach z kompatibility integrovaného SATA řadiče (v ne-intelském čipsetu) s operačním systémem, ale na 95% je ten strach abstraktní/zbytečný. AMDčkové stroje mívají oproti intelským čipsetům nižší strop sekvenční průchodnosti na disky, ale ve Vašem případě na ten sekvenční strop nenarazíte, protože úzkým hrdlem bude IOps strop disků a dva disky jsou s tím stropem čipsetu i sekvenčně tak nastejno.
Pokud si budete stavět server ze součástek za málo peněz, tak určitě má smysl pořídit si rozumně kvalitní motherboard s AMDčkem (nebo nějaký entry-level Nehalem v rozumném boardu), hodně RAMky a 1-2 Velociraptory + nějakou Barracudu nebo Caviar Green v externím USB rámečku (pokud nemáte někde na LANce spřátelený fileserver).
U externích USB rámečků pozor na dostatečnou ventilaci (nemívají větrák) - buď použijte jednoplotnový disk (třeba aktuální Barracudu 7200.12 až do 500 GB), nebo ten externí USB boxík trochu klempířsky upravte, aby se disk nepřehříval (nebo oboje).
Ohledně RAMky, pokud je na výběr: na shodném taktu má DDR2 nižší latence než DDR3 (resp. si vydělte CL/hodiny a dostanete hodnotu v sekundách). "ECC Registered" paměti na shodném taktu jsou pomalejší než unbuffered. V některých případech latencím pomůže, připojit na relativně pomalý řadič RAM (třeba s podporou DDR2/533) nějaké DIMMy, které mají vysoký jmenovitý takt (třeba DDR2/800) - na nižším taktu běží s kratším "CL". Je to proto, že v obchodní dokumentaci se sice CL udává v jednotkách taktů, ale v SPD EEPROM na DIMMu je ve skutečnosti uložen v nanosekundách - takže si ho BIOS při nižším taktu spočítá na odpovídající nižší počet cyklů. Vlastně z toho plyne, že ta latence v nanosekundách je pro daný modul fixní... je to víceméně vodítko, jak porovnávat latenci modulů o různých jmenovitých taktech. Taky se může stát, že paměť s příliš rychlým jmenovitým taktem nepůjde v "pomalejším" motherbordu použít (i to se stává, těžko říct, jestli je to impedančním nepřizpůsobením, nebo demencí BIOSu). Většina výrobců DIMMů (klasicky třeba Kingston) mívá jednak "obyčejnou" řadu výrobků, druhak "vyladěnou gamesáckou" řadu s vyšším taktem a trochu nižší latencí (třeba Kingston HyperX), a v některých případech jsou v nabídce dále moduly s ještě kratší latencí (Kingston HyperX "LL" nebo "ULL") - bývají dražší a hůře dostupné. Kratší latence se Vám projeví nižším vytížením resp. větším výkonem procesoru - protože řadič paměti vkládá wait staty transparentně a instrukční pipeline procesoru se po dobu čekání na data zablokuje, takže dané jádro nemůže dělat nic jiného (pokud neuvažujete HT).
Pouvažujte o solidní síťové kartě - já bych sáhl po Intelu, ostatní mohou mít jiný názor... ušetří Vám to taky nějakou zátěž CPU. V desktopových boardech, zejména s neintelskými čipsety, se dobré síťovky Intel nebo třeba Broadcom onboard prakticky nevyskytují (spíš nějaký Realtek, Marvell nebo VIA). Čili může Vám pomoci, pokud do PCI nebo PCI-e slotu přidáte síťovku od Intelu, podle mého ani nemusí být echt serverová, snad stačí desktopová (stojí asi čtvrtinu).
Nemusíte ani honit stovky wattů, stačí dobrá čtyřstovka - ale cena bude mezi 30-50 Euro.
AbcLinuxu.cz
ITBiz.cz
HDmag.cz
AbcPráce.cz
#!/usr/bin/perl
use Net::Ping;
my $ping_target = "192.168.2.8";
my $patience = 6;
my $timeout = 1;
my $num_timeouts = 0;
#my $p = Net::Ping->new();
my $p = Net::Ping->new("icmp",$timeout);
while (1)
{
if ($p->ping($ping_target))
{
#print "okay, reachable \n";
}
else
{
#print "unreachable!\n";
$num_timeouts++;
}
if ($num_timeouts == $patience)
{
print "Going to reset eth0: ";
system("LANG=en_US date");
system("ethtool -r eth0");
$num_timeouts = 0;
sleep(6);
}
else
{
sleep(1);
}
}
Obecné srovnání výkonu databáze na Linuxu vs. FreeBSD, to je tenký led, na který se nebudu pouštět. Ta databáze asi nepojede přímo na holý disk, ale skrz VM+filesystém - a ty se posledních pár let dost bouřlivě vyvíjejí, hlavně na Linuxu... Pokud Vás ten rozdíl opravdu zajímá, možná uděláte nejlíp, když na tom stroji nainstalujete oboje a zkusíte nějaký benchmark Ačkoli podle mých zkušeností se reálná zátěž simuluje dost těžko...
Tiskni
Sdílej:
