Při úklidu na Utažské univerzitě se ve skladovacích prostorách náhodou podařilo nalézt magnetickou pásku s kopií Unixu V4. Páska byla zaslána do počítačového muzea, kde se z pásky úspěšně podařilo extrahovat data a Unix spustit. Je to patrně jediný známý dochovaný exemplář tohoto 52 let starého Unixu, prvního vůbec programovaného v jazyce C.
FFmpeg nechal kvůli porušení autorských práv odstranit z GitHubu jeden z repozitářů patřících čínské technologické firmě Rockchip. Důvodem bylo porušení LGPL ze strany Rockchipu. Rockchip byl FFmpegem na porušování LGPL upozorněn již téměř před dvěma roky.
K dispozici je nový CLI nástroj witr sloužící k analýze běžících procesů. Název je zkratkou slov why-is-this-running, 'proč tohle běží'. Klade si za cíl v 'jediném, lidsky čitelném, výstupu vysvětlit odkud daný spuštěný proces pochází, jak byl spuštěn a jaký řetězec systémů je zodpovědný za to, že tento proces právě teď běží'. Witr je napsán v jazyce Go.
Yazi je správce souborů běžící v terminálu. Napsán je v programovacím jazyce Rust. Podporuje asynchronní I/O operace. Vydán byl v nové verzi 25.12.29. Instalovat jej lze také ze Snapcraftu.
Od soboty do úterý probíhá v Hamburku konference 39C3 (Chaos Communication Congress) věnovaná také počítačové bezpečnosti nebo hardwaru. Program (jiná verze) slibuje řadu zajímavých přednášek. Streamy a záznamy budou k dispozici na media.ccc.de.
Byl představen nový Xserver Phoenix, kompletně od nuly vyvíjený v programovacím jazyce Zig. Projekt Phoenix si klade za cíl být moderní alternativou k X.Org serveru.
XLibre Xserver byl 21. prosince vydán ve verzi 25.1.0, 'winter solstice release'. Od založení tohoto forku X.Org serveru se jedná o vůbec první novou minor verzi (inkrementovalo se to druhé číslo v číselném kódu verze).
Wayback byl vydán ve verzi 0.3. Wayback je "tak akorát Waylandu, aby fungoval Xwayland". Jedná se o kompatibilní vrstvu umožňující běh plnohodnotných X11 desktopových prostředí s využitím komponent z Waylandu. Cílem je nakonec nahradit klasický server X.Org, a tím snížit zátěž údržby aplikací X11.
Byla vydána verze 4.0.0 programovacího jazyka Ruby (Wikipedie). S Ruby Box a ZJIT. Ruby lze vyzkoušet na webové stránce TryRuby. U příležitosti 30. narozenin, první veřejná verze Ruby 0.95 byla oznámena 21. prosince 1995, proběhl redesign webových stránek.
Všem čtenářkám a čtenářům AbcLinuxu krásné Vánoce.
vždycky se snažím všechny problémy řešit sám a až v té nejkrajnější situaci žádám o pomoc. Nejkrajnější situace právě nastala.
Na začátek trochu historie: přes rok jsme měli server s nainstalovaným NetBSD 1.6 na softwarovém RAIDU (včetně boot partition), pak jsme upgradovali na NetBSD 2.0, a až mě to přestalo bavit, rozhodl jsem se k radikálnímu kroku: přeinstalovat na FreeBSD 5.4, samozřejmě opět s HDD v softwarovém RAIDu.
V čem je problém? No, v podstatě v ničem, server byl stabilní pod NetBSD, i nyní pod FreeBSD, služby fungují, žádné fatal errory, ve /var/log/messages všechno v normálu, logy démonů taky nevykazují abnormality... prostě paráda, chtělo by dodat. Jenže se průběžně stává jedna nepříjemnost: na serveru je nainstalovaná Samba (dříve Samba 3.0.4, nyní 3.0.14) a když z klientské stanice, která má nasdílenou (promiňte mi ten Windowsovský termín) jednotku Z: z tohoto serveru, kopíruji řádově 100MB adresáře (plné fotek v JPEGu) jinam na jinou nasdílenou jednotku Z: opět z tohoto serveru, tak se (zdůrazňuji občas
) nějaký soubor poškodí (s originálem se rozchází asi "jen" ve 20 bajtech, většinou je to v za půlkou souboru). Máme to vyzkoušené pouze se soubory typu JPEG (řádově 500kB - 4MB), které se z jednotky P: na jednotku Z: kopírují takřka denně a pouze aktuální adresáře, protože se chyba objevuje zřídka kdy, a když chci chybu uměle vyvolat, tak se mi to samozřejmě nepodaří. Navíc je záhadou, že pokud nasimuluji pád RAIDu (vytrhnu disk), tak se na některém z RAIDových disků (máme dva) objeví soubor v pořádku. A není to pokaždé stejný disk.
Vyměnil jsem základní desku, ATA kabely, jeden z disků, case, zdroj, síťovku, procesor, grafickou kartu (já vím, že to grafárnou bejt nemůže ale jistota je jistota), operační systém, vyhodil jednu paměť (ostatní 2 jsou tam od začátku) a dneska poprvé to udělalo znova na tom FreeBSD... Fakt nevím co s tím.
V zásadě vylučuji chybu softwaru, spíš bych to viděl na hardware, ale jaká součástka? Paměť? Tu jsem kontroloval memtesterem a měla by být okay, stejně se jí chystám vyměnit...
Teď HW konfigurace (i když nevím, jestli v něčem pomůže):
- síťovka Ovislink s čipem Relktek 8139 (to je standard, navíc byla jednou měněná, takže myslím, že problém tady nebude)
- harddisky 2 x WD1200JB (Western Digital, 120GB, navíc jeden měněnej a to ten problém nevyřešilo, jak píšu, dneska to udělalo znova)
- paměť 768 MB (3 x 256 MB, SDRAM klasické, značky různé, tady bych možná viděl jádro problému, ale na druhou stranu je ten systém celkem stabilní, takže chyba v pamětech by se musela projevit už dřív, třeba při instalaci...)
- deska QDI Kinetiz 7B (předtím 7E, má smysl upgradovat BIOS?)
Fakt nevím co s tím. Logy nic nehází, navenek to vypadá všechno OK, systém nepadá, Samba jede v pohodě (klidně pošku konfiguráky)... Moje poslední naděje jsou paměti (ale jak píšu, ten memtester běžel snad dvě hodiny a nic nezjistil). Navíc se s tím serverem nedá moc experimentovat, protože jede, a kromě toho zmíněného kopírování jedou všechny ostatní služby OK (OpenLDAP, Apache2). Na serveru mají uživatelé uložený i maily *.PST z Outlooku, což jsou soubory okolo 1-2 GB, ty se otevírají, ukládají, kopírují v pohodě...
Sorry za dlouhej text a díky moc za jakoukoli radu, třeba i to, jak identifikovat problém, protože po půl roce, co se tohle děje stále nevím, kde ten problém je.
). No a dela to furt. Je to divny...
Ony jsou ty poskozene JPEGy docela vtipny. Jak jsou dobre komprimovane, tak jakykoli zasah zpusobi hezke veci. Treba po poskozeni, ktere se vyskytuje u nas na serveru, je vetsinou JPEG vizualne stejny, ale cast je treba do zelena, nebo do ruzova, nebo do sediva...
Tiskni
Sdílej: