Po půl roce vývoje od vydání verze 49 bylo vydáno GNOME 50 s kódovým názvem Tokyo (Mastodon). Podrobný přehled novinek i s náhledy v poznámkách k vydání a v novinkách pro vývojáře.
Článek na stránkách Fedora Magazinu informuje o vydání Fedora Asahi Remixu 43, tj. linuxové distribuce pro Apple Silicon vycházející z Fedora Linuxu 43.
Byl zveřejněn program konference Installfest 2026. Konference proběhne o víkendu 28. a 29. března v Praze na Karlově náměstí 13. Vstup zdarma.
Byla vydána Java 26 / JDK 26. Nových vlastností (JEP - JDK Enhancement Proposal) je 10. Odstraněno bylo Applet API.
Byla vydána nová verze 260 správce systému a služeb systemd (Wikipedie, GitHub). Odstraněna byla podpora skriptů System V. Aktualizovány byly závislosti. Minimální verze Linuxu z 5.4 na 5.10, OpenSSL z 1.1.0 na 3.0.0, Pythonu z 3.7.0 na 3.9.0…
Byla vydána nová verze 5.1 svobodného 3D softwaru Blender. Přehled novinek i s náhledy a videi v poznámkách k vydání. Videopředstavení na YouTube.
Bylo oznámeno vydání nové verze 8.1 "Hoare" kolekce svobodného softwaru umožňujícího nahrávání, konverzi a streamovaní digitálního zvuku a obrazu FFmpeg (Wikipedie). Doprovodný příspěvek na blogu Khronosu rozebírá kódování a dekódování videa pomocí Vulkan Compute Shaders v FFmpeg.
Byl představen open-source a open-hardware prototyp nízkonákladového raketometu kategorie MANPADS, který byl sestaven z běžně dostupné elektroniky a komponent vytištěných na 3D tiskárně. Raketa využívá skládací stabilizační křidélka a canardovou stabilizaci aktivně řízenou palubním letovým počítačem ESP32, vybaveným inerciální měřicí jednotkou MPU6050 (gyroskop a akcelerometr). Přenosné odpalovací zařízení obsahuje GPS,
… více »Vědci z univerzity La Sapienza v Římě vyvinuli systém, který dokáže identifikovat jednotlivce pouze na základě toho, jak narušují signály Wi-Fi. Autoři tuto novou technologii nazvali WhoFi. Na rozdíl od tradičních biometrických systémů, jako jsou skenery otisků prstů a rozpoznávání obličeje, nevyžaduje tato metoda přímý fyzický kontakt ani vizuální vstupy. WhoFi může také sledovat jednotlivce na větší ploše než kamera s pevnou polohou; stačí, je-li k dispozici Wi-Fi síť.
SuperTux (Wikipedie), tj. klasická 2D plošinovka inspirovaná sérií Super Mario, byl vydán v nové verzi 0.7.0. Videoukázka na YouTube. Hrát lze i ve webovém prohlížeči.
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:
