Uncle Vёder

Такое категорическое утверждение меня заинтересовало. Быстрогугл выдал это: У нас в городе два водозабора. Как оно что делается на Камском - хз. На Чусовском, который в том числе питает мой дом, и на котором я несколько лет назад был на экскурсии, система очистки двойная: хлор+озон. На вкус вода отвратительная. Ну т.е. со временем можно и привыкнуть, но всё равно чувствуется что-то не то. Да банально чай мутнеет через полчаса после заварки. А уж после нормальной воды всё это явно чувствуется. Зато не слышал чтобы кто-то через нашу воду чем-то отравился или заразился - зараза в такой адской водичке не выживает. Одно время возил воду с дачи. Потом покупал, в больших бутылях или на разлив. Потом надоело, купил за 500р обычный фильтр-кувшин. Со своей задачей (удаление постороннего привкуса) справляется на все 146%, даже картриджи ходят раза в два дольше, чем положено. Второй раз проснулся. Опять на дачу ехать.

Та же хрень. При попытке скачать то ошибка непонятная валится, то "извините, сервисы недоступны". Да, про "показать всю суть Origin" вышло чертовски верно.

Спасибо анонимусу, закинувшему 490р на ЯД.

Починено.

Я не знаю куда это ещё написать, напишу сюда. Нужен человек, умеющий пользоваться торрентами и способный на слух отличить старую озвучку MC от новой. Если человек при этом умеет пользоваться аудиоредактором - вообще идеально. Но можно и без этого. СРОЧНО.

И снова требуется человек с аудиоредактором и руками из нужного места.

Что-то не набралось участников на игру.

Старт третьей игры турнира запланирован на вечер воскресенья (13 сентября). Записываемся!

Да в общем-то никакую и нигде. У большинства современных приложений даже в тяжёлых режимах работы (кодирование видео, архивация, математические рассчёты, компиляция) потолок находится в районе ПСП 25-30ГБ/с - это штатный двухканальный режим модулей DDR3-1600/1866. Многие приложения и 20ГБ/с пробить не могут, а это уже самая простая DDR3-1333, но тоже в двухканальном режиме. Но от разогона 1333МГц памяти ещё иногда можно получить немного профита. А 2ГГц модули, DDR4 и 3/4-канальные режимы - это плацебо. По крайней мере на десктопах (да и на рабочих станциях пожалуй тоже).

Буквально несколько дней назад со мной (а точнее - с моим компьютером) произошла одна неприятная история. Ничего нового я из неё, в принципе, не почерпнул, но в очередной раз утвердился в некоторых вещах. Если вы любите, чтобы ваш компьютер работал без сбоев и ошибок - эта информация может оказаться очень полезной. Началось всё очень просто. Стали как-то криво работать торренты. Допустим есть у нас некая папка, и в ней лежит 10 файлов. Создаём мы торрент из одного и встаём на раздачу - всё хорошо. Повторяем операцию для оставшихся девяти - всё опять же отлично. А теперь берём и делаем один большой торрент на всю папку. И вот тут начинаются проблемы: при попытке встать на раздачу некоторые файлы отображаются недокачанными, причём всего на 1-2%, а то и меньше. Чешем репу, пересоздаём торрент - та же борода. Тут стоит сделать небольшое отступление и пояснить, как вообще работает протокол BitTorrent. Подробно эту информацию можно почерпнуть из той же википедии, а здесь кратко о том, что из себя представляет торрент-раздача. При создании торрента программа как правило предлагает нам выбрать размер блока. Далее файл считывается с диска, условно разбивается на блоки заданного размера, и для каждого блока строится хэш (по алгоритму SHA1). Отдельно сохраняется информация об имени и размере файла. Это и есть основная составляющая torrent-файла. Когда клиент сети BT запрашивает данные, он получает их кусками в виде тех самых блоков, после чего локально пересчитывает и проверяет хэш, а при его несовпадении - запрашивает блок повторно. Аналогично при попытке встать с уже скачанными файлами на раздачу отдельно сверяется каждый блок. Такая система обеспечивает довольно хорошую целостность данных и защиту от коллизий. Чуть интереснее происходит, если файлов в раздаче несколько. Чтобы не расходовать блоки (а значит и сетевой траффик впоследствии) впустую (особенно когда блоки здоровые - по 16МБ, а файлов много и они мелкие), файлы считываются потоком непрерывно в виде одного большого сырого набора данных. Получается, что если хвост первого файла занял не весь доступный объём блока, то оставшееся свободное место будет дописано уже данными следующего файла (именно поэтому при выборочном скачивании содержимого торрент-раздач зачастую всё равно подтягивается разный мусор). Так вот, в нашем случае проблема заключалась в том, что при проверке хэшей после добавления свежесозданного торрента наблюдалось расхождение данных. Причём расхождение мизерное - всего один блок на файл, да и то не на каждый. Но расхождение было. А если расхождение есть у инициатора раздачи - значит и остальные не смогут её до конца скачать. Оперативно нашли простой выход: отправить файлы для групповой раздачи в отдельную резервацию. Тогда всё создавалось и перехэшировалось нормально. Хотя как нормально... тоже через раз. Нужно было копать глубже и решать проблему. Первым делом подозрение пало на сам алгоритм BitTorrent и файловую систему NTFS. Основывалась идея на том факте, что проблемы всплыли именно с многофайловыми раздачами, в которых один блок может содержать данные сразу нескольких файлов. Была мысль, что в некоторых исключительных случаях вместо пустого хвоста файла в данных каким-то образом оказывается рандомная каша, которая и вызывает расхождение. Для начала были перепробованы разные варианты программ для создания torrent-файлов (в нашем случае это были qBittorrent 3.4.3, uTorrent 2.2.1 и Torrent Builder 3.2.2). Результат оказался довольно странным: торренты созданные разными программами давали расхождение в разных файлах. Это исключило влияние конкретной программы, но только ещё больше запутало ситуацию. Определённо нужно было найти в этом какую-то закономерность. Я подсчитал MD5-хэши исходных файлов, с которыми успешно работали одиночные раздачи. А потом посчитал MD5-хэши для тех же самых файлов, но лежащих в резервации для групповой раздачи. Не сказать, что я сильно удивился тому, что хэши местами не совпадали. Проблема была не в BitTorrent, а в самих файлах. Решив воспроизвести ошибку, я выбрал один файл и скопировал его в другую папку на том же HDD. MD5-хэш поменялся. Почесав бороду, я сделал ещё одну копию файла, но в этот раз хэш остался неизменным, что меня сильно обескуражило. Сделал третью копию - хэш опять совпадает с исходным. Тут я решаю перепроверить первую копию... и да, хэш тоже совпал с хэшем исходного файла. Тут в самую пору было бы задуматься о поехавшей крыше. Но я решил продолжить эксперименты, и таки нашёл ситуацию, в которой баг 100% воспроизводится: нужно было копировать сразу по несколько файлов. Тем временем была предпринята попытка сравнить различающиеся копии файлов. На тестовых образцах все отличия составляли ровно 1 байт. Причём байт этот находился в файле совершенно произвольно, а не в конце, что забивало последний гвоздь в крышку гроба теории о глюках алгоритма BT. Но кого же тогда подозревать? Файловую систему? Жёсткий диск? Шифрование и сжатие данных NTFS были у меня выключены изначально. Ради эксперимента отключил последнее, что могло влиять на результат - кэширование операций записи средствами той же NTFS. Результата это не дало никакого (ну, кроме снижения производительности). Был так же испробован и другой HDD, но и на нём ошибка спокойно воспроизводилась в тех же условиях. Иногда даже не нужно было копировать файл - каждый новый запуск MD5 давал новый хэш. А совсем неразбериху в ситуацию вносило то, что исходный хэш у некоторых копий действительно периодически восстанавливался. Что может произвольно портить файлы, при этом иногда ещё и восстанавлиая их в изначальное состояние? Не знаю, сколько бы я ещё ломал голову, если бы Minamoto Michi не подкинул интересную идею: может, с файлами и дисками на самом деле всё в порядке, просто они криво читаются? А действительно. Куда читаются файлы? Где считаются функции хэширования? Оперативная память. Вот я мудааак... Тут стоит сделать ещё одно небольшое отступление. Весной этого года я решил наконец слегка подразогнать свой компьютер и даже планировал написать об этом пост в бложек. Однако планам не суждено было сбыться. Если разгон видеокарты удался относительно успешно, то с процессором вышла полная жопа. Он легко брал высокие частоты, но совершенно отказывался их удерживать. Промучавшись около недели, я выяснил, что всё упёрлось в мощность цепей питания материнской платы. Они банально не выдерживали возросшей нагрузки и слишком быстро перегревались. А поскольку покупка новой материнки в мои планы не входила, затею пришлось забросить. Тем не менее, в процессе перебора конфигураций я слегка подразогнал память со штатных 1333МГц до 1600МГц, и даже проверил систему в этом режиме на стабильность (с помощью OCCT). Память. Да, память. Я уже давно знал, что сбои в оперативной памяти могут привести к порче данных на внешних носителях. У меня уже был печальный опыт на другом железе, когда из-за переразогнанной памяти слетела MBR на системном диске. И в последнее время я действительно наблюдал чуть больше различных мелких глюков софта, чем привык видеть обычно, но не придал этому значения. При первой же выдавшейся возможности, я хватанул первое, что попалось под руку (а под руку попался старый HBCD с Memtest86+ 4.20) и запустил тест. Буквально через несколько минут перед моим взором предстала такая картина: В принципе, дальше тест уже можно было не продолжать. Если бы даже он завершился без ошибок, это всё равно не отменило бы сбои в начале. Рабочая память не должна давать ни одной ошибки. Скинув параметры памяти в заводские настройки, я повторно врубил Memtest86+ и укатил на дачу. И не зря. Учитывая, что памяти у меня 16ГБ, каждый проход полного теста занимал около 3 часов. Вернувшись с дачи, я увидел, что вполне успешно завершены уже два прохода. Можно было для верности погонять ещё, но на это уже не было времени. Загрузив систему, я попытался повторить все те действия, которые приводили к появлению битых копий файлов. Ни в одном из вариантов баг больше не воспроизводился. Мораль этой истории: 1. Если у вас проблемы с битыми файлами - не факт, что виноваты в этом жёсткий диск или файловая система. Проблемы с оперативной памятью тоже легко могут оказаться причиной сбоев. 2. Тестов на стабильность не бывает много. Если у вас уверенно прошёл тест OCCT - не забудьте попробовать Linpack, AIDA, Prime, Memtest и вообще всё, что попадётся под руку. Чем больше и дольше - тем лучше. 3. Если компьютер глючит больше чем обычно, а вы его не так давно разгоняли - не стоит пытаться искать тому какие-то сторонние причины. Начните с исключения основного фактора, т.е. самого разгона. Не забывайте ставить лойс, если хотите, чтобы я таки написал большой пост про разгон. Ну или дизлойс, если хотите, чтоб я убился апстену. И комменты тоже пишите.

Да? Ну ладно, исправил. Проглядели. В следующем выпуске напишем.

Ладно, отпишусь более конструктивно, по всем работам. 1. От работы так и веет желчью и мизантропией, а никак не летним настроением. Однозначно дизлойс и хренов за воротник автору. 2. Грядки, птички, солнышко. Вроде всё присутствует. Но как-то слабовато. 3. Лето, пикничок на природе, Аска, Рей. Далеко не самая крутая техника рисования, конечно, но зато хорошо передаёт настроение. Да ещё и бонусом - герои Евы. Однозначно лойс и голос. 4. Да простит меня автор, но фанфик я читать не стал. 5. То ли лето, то ли осень - не совсем понятно. Как и про вторую работу, сказать ничего плохого не могу, но и голосовать тоже не буду. 6. А вот тут уже явно чувствуются старания и творческий подход, которых не хватало 2 и 5 работам. И я может бы даже и отдал бы голос, если бы не... 7. LOOOOOL. Меня просто порвало. Царевна-пис это однозначно главный вин конкурса. Вторая работа, за которую отдаю свой голос.

Хроника ЕнЕ. Выпуск №26

Ну тогда хренов за воротник тому автору. Мало того что идея паршивенькая, так ещё и плагиат. ЗЗЫЖ: аж на две недели голосование? Ё...

ЗЫЖ: чому вместо первой работы чёрный квадрат? Или это авторская задумка такая - типа лето просрано?

Это нормально. Там начинается не EoE, а оригинальный Rebirth в первозданном виде. Почитайте вот эту статью и всё тайное станет явным: https://vk.com/wall-3718188_188491 Действительно в файле есть пара косяков. Впрочем, смотреть это не должно мешать. А в ближайшие дни будет исправленная версия.

Мимо кассы. Это две разные версии Death: оригинальная Death и Death(true)2. Точно так же Rebirth и Air тоже разные вещи. К BD-переизданию это отношения не имеет.

Бывает.

Ты того, поторопись. Два дня с половиной до окончания приёма работ.

Tesla Model X уже на финишной прямой. Скоро в продаже. Всего $132K. http://geektimes.ru/post/261256/ http://mashable.com/2015/09/01/tesla-model-x-signature-pricing/?utm_cid=mash-com-Tw-main-link http://www.teslamotorsclub.com/showthread.php/52766-Model-X-Configuration-has-begun!

Анбоксинг BD:

http://danbooru.donmai.us/posts/1715680

Шок, сенсация: паркетник с постоянным полным приводом, блокировкой межосевого дифференциала и понижайкой. Я же говорю - деление весьма условное.