В сезон активного развития крипто валют решил и я попробовать себя в этом народном развлечении. Основной целью было, правда, не извлечение прибыли, а создание решения для майнинга в домашних условиях с максимальной эффективностью при минимальном шуме.

Как известно, самый популярный способ майнинга валют основанных на scrypt алгоритмах - это использование обычных топовых видео карт для перебора хэшей. Причем эффективность этого процесса пропорциональна естественно мощности карт и их количеству. Таким образом энтузиасты собирали целые фермы, где на одну материнскую плату приходилось 2-5 видюх и вся эта конструкция занималась круглосуточно вычислениями. Естественно охлаждающие системы видео карт не рассчитаны на то, что карта будет постоянно под 100% нагрузкой, а рядом от нее будут такие же грелки. Поэтому для того чтоб не пожечь карты их приходилось разносить подальше друг от друга, а в идеале еще и обеспечивать приток холодного воздуха для системы охлаждения. В результате получались просто монстры, которые еще и гудели как идущий на взлет самолет.

Естественно уподобляться массам, которые собирают фермы которые занимают место и издают много шума у меня не было ни желания ни возможности, банально не было даже помещения где все это расположить. От этого задача становилась еще интереснее: нужно было создать майнер, который был бы компактным, да еще и не шумел при полной нагрузке, ну или шумел так чтоб его можно было держать в квартире и одновременно там жить.

Выбор видео карт

Началось все естественно с выбора видео карт. Нужно было найти карту с наилучшим соотношением производительность (в количестве хэшей) и энергопотребление. Да именно потребление энергии основная проблема тк при майнинге видео карта потребляет весьма много электричества. Ну и цена тоже играла не последнюю роль.

После долгих поисков, чтения профильных форумов, спецификаций и расчетов был выбран Radeon R9 290, который по соотношению количество мегахэшей на ватт электричества оказался более эффективен, чем его старший и более дорогой товарищ Radeon R9 290X. Невероятно но факт.

В принципе все это легко нагуглить, но тем не менее опишу свой опыт. Итак, есть windows сервер (в моем случае Windows Server 2008, но все описанное ниже применимо ко всем windows), на этом севере работает некое веб-приложение, которое хочется коллективно развивать командой из нескольких человек. Идеи лучше чем Git в голову не пришло.

Подготовительный этап 

На сервере ставим и настраиваем SSH сервер (в моем случае это оказался Bitvise SSH Server, далее все настройки буду описывать относительно него).

Создаем пары public и private ключей для нужных пользователей, в настройках этих пользователей на SSH сервере добавляем им соответствующие public ключи и убеждаемся что разрешена авторизация по ключу.

Если требуется работать с Git из интернета, также пробрасываем соответствующий порт наружу, обычно это 22, но в моем случае получилось 222 по техническим причинам. Проверяем доступность сервера по SSH снаружи и возможность авторизации с ключом, PuTTY в помощь :)

Ставим собственно Git (в моем случае это msysgit). Народ предлагает ставить в короткий путь вроде C:/Git, но я ставил в каталог по-умолчанию, все работает. Через Git GUI создаем репозиторий, в моем случае это С:/Webroot/test-git.

Недавно мной было замечено, что если отправлять собственным скриптом multipart письмо на адрес @mail.ru, то оно приходит не корректно: в теле письма показывается часть заголовка и далее все части включая вложения в закодированном виде.

Происходит это ввиду того, что mail.ru почему-то не придерживается стандарта RFC, который регламентирует, что для переноса строк используется "combination CRLF (US-ASCII values 13 and 10) indicating a new line" оно же "\r\n" и заменяет такую конструкцию на двойной перевод строки, от этого нарушается разбор письма по стандарту и пользователю предлагается исходный текст письма.

Очень надеюсь, что mail.ru исправятся и будут нормально разбирать письма как все остальные, кто соблюдает стандарты, а пока временным решением является замена "\r\n" на "\n", после этого письма нормально разбираются нa mail.ru и становятся читабельными, также такой подход нормально воспринимается и другими почтовыми сервисами (gmail, yandex).

Ссылки по теме: RFC 822 и Википедия с полезной информацией и ссылками на другие RFC.

В последнее время китайские производители упрочняют свои позиции на рынке мобильных телефонов. Появляется все больше достойных устройств, которые подкупают невысокой ценой и солидными характеристиками. Вот и ко мне в руки попал один из таких телефонов, в силу отсутствия подробной информации о нем в поисковой выдаче, я решил попробовать написать обзор. Это мой первый обзор, поэтому не судите строго.

Мне требовалось приобрести в подарок не очень дорогой телефон, с двумя сим-картами и элегантным внешним видом, ну и естественно с хорошей начинкой. Основной задачей была максимальная фичность за небольшие деньги и при этом приятно выглядящая, казалось бы почти не реализуемая задача в районе цен до 10 тас.руб. Времени на заказ из Китая не было, поэтому пришлось найти что-то из ассортимента яндекс-маркета.

После изучения маркета было выбрано порядка 20 претендентов на покупку, в основном это были модели от Samsung, LG, ZTE, Fly, Lenovo, Alcatel. Этот список был быстро сокращен ввиду дороговизны именитых брендов и не подходящего внешнего вида многих других (но это дело вкуса каждого). В итоге осталось несколько моделей от ZTE и Fly ввиду привлекательной цены и интересных характеристик, но глаз зацепился за Changhong W20, а его характеристики не оставили шансов конкурентам.

Become root. If you're root, you should know what to do.

Когда-то я собрал программный RAID на основе Silicon Image 3132 (тык и крутим до соответствующего заголовка), по прошествии времени появилась необходимость запустить этот же самый RAID-1, но на встроенном SATA-контроллере без поддержки RAID, т.е. перенести массив в новые полностью софтовые условия.

Изначально все выглядело просто: переткнул харды и на новой системе сказал, что они продолжают быть массивом. Но на деле все оказалось не так просто. Диски были подхвачены Device Mapper и появились как /dev/mapper/sil_***. dmraid признал, что они принадлежали к какому-то массиву, но собрать их обратно в массив при помощи mdadm не получалось и по отдельности они были не доступны для чтения информации - fdisk показывал неверную таблицу разделов.