https://www.opennet.ru/openforum/vsluhforumID3/87037.html Представлены (http://www.kernel.org/) очередные корректирующие релизы ядра Linux: 3.0.49 (https://lkml.org/lkml/2012/10/28/97) (31 исправление (http://www.kernel.org/pub/linux/kernel/v3.0/ChangeLog-3.0.49)), 3.4.16 (https://lkml.org/lkml/2012/10/28/101) (42 исправления (http://www.kernel.org/pub/linux/kernel/v3.0/ChangeLog-3.4.16)) и 3.6.4 (https://lkml.org/lkml/2012/10/28/99) (85 исправлений (http://www.kernel.org/pub/linux/kernel/v3.0/ChangeLog-3.6.4)). Как обычно, в анонсе выхода новых версий подчеркивается обязательность проведения обновления. <br><br><br><br><br>Из подсистем, в которых устранены ошибки можно отметить: mac80211, vlan, sparc64, drm/i915, Xen, cgroup, ext4. Достаточно большая порция исправлений касается подсистемы USB и сетевого стека (IPv4, IPv6). В новый выпусках также устранена уязвимость (http://permalink.gmane.org/gmane.comp.security.oss.general/8562) (CVE-2012-0957), позволяющая получить доступ к части содержимого стека ядра через манипуляции с вызовом uname() с опцией UNAME26.<br><br><br>В указанны https://www.opennet.ru/openforum/vsluhforumID3/87037.html#84 Fri, 02 Nov 2012 08:17:01 GMT да-да-да<br>Помним помним, после скачка света<br>NTldr not found<br>Самая стабильная система, ага...<br> https://www.opennet.ru/openforum/vsluhforumID3/87037.html#83 Wed, 31 Oct 2012 17:27:02 GMT Исправили !<br> https://www.opennet.ru/openforum/vsluhforumID3/87037.html#82 Wed, 31 Oct 2012 15:03:16 GMT &gt; Скажи мне, о чудо, НАХ диски такого размера?<br><br>&#171;что? автопоезда? не, не слышал: у меня в мой запор всё помещается, нах эти автопоезда нужны? ламеры криворукие, не смогли в запор запихать!&#187;<br> https://www.opennet.ru/openforum/vsluhforumID3/87037.html#81 Wed, 31 Oct 2012 14:59:38 GMT &gt; Я вот чему удивляюсь: NTFS уже хреновых 20 лет, а с ней <br>&gt; ни разу таких массовых проблем не было.<br><br>(улыбается). guest login. право на запись и запуск одного батника из пары строк. прощай, дорогая ntfs. настолько, что вытащить что-то оттуда становится ой, как проблематично. как минимум до xpsp1 или sp2, дальше не проверял.<br><br>подчёркиваю, GUEST login.<br><br>то, что ты о чём-то не знаешь, не значит, что этого нет. это всего лишь значит, что у m$ нет публичного багтрекера.<br> https://www.opennet.ru/openforum/vsluhforumID3/87037.html#80 Tue, 30 Oct 2012 10:06:49 GMT На мой взгляд самая большая кака в нтфс - MFT. Точнее малая избыточность хранения.<br> https://www.opennet.ru/openforum/vsluhforumID3/87037.html#79 Tue, 30 Oct 2012 07:47:33 GMT для отстающих и врунов можно новость и повторить:<br>&gt;проблема проявляется значительно реже чем предполагалось и разработчикам так и не удалось полностью повторить все условия её возникновения. Пока все гипотезы возможных причин возникновения потери данных у пользователей носят только умозрительный характер и не подтверждены на практике<br><br>а вы кто из них? просто тупой или брехло?<br> https://www.opennet.ru/openforum/vsluhforumID3/87037.html#78 Tue, 30 Oct 2012 07:06:07 GMT то то в новости пишут что журнал гробит FS.<br>или вы забыли еще как delayed alloc убивал файловую систему если был reset или power lost?<br> https://www.opennet.ru/openforum/vsluhforumID3/87037.html#77 Tue, 30 Oct 2012 03:33:15 GMT &gt; Того. Ты уверен, что ты айтишнег?<br><br>Уверен. Как ты эти шпиндели собрался агрегировать? Софтово? Извини, тот же dedicated контроллер массива сделает это лучше, и throughput будет бОльшим.<br><br>Ну и да: открываю секрет для безграмотных: командный цикл достаточно длинный. Поэтому отсылка команд одному LUN'у будет куда легче отсылки команд сотне LUN'ов. Плюс чередование данных на шине. Если шина общая - на throughput это повлияет прямым и непосредственным образом.<br><br><br><br><br><br> https://www.opennet.ru/openforum/vsluhforumID3/87037.html#75 Tue, 30 Oct 2012 03:26:55 GMT &gt; А что, УПСы. еще не изобрели?<br><br>Тут шла речь о том, как быстро и просто покалечить NTFS, а не о УПС'ах. ext'ы в таких случаях как правило восстанавливаются с журнала без каких-либо граблей.<br><br>