День образования на Хабре продолжается. Думаю, это можно всем нам простить, поскольку сегодня всё-таки нерабочее воскресенье, в ВУЗах — финал сессии, а завтра — вполне тематический праздник «Татьянин день» (День студента, с которым и поздравляю всех причастных).

Так вышло, что я имею возможность оценить ситуацию сразу с разных сторон баррикад (я — аспирант, но уже преподаю в ВУЗе). Дальше хочется немного рассказать о своём пускай скромном, но всё же опыте, и, основываясь на нём, предложить несколько шагов к заветной цели (порассуждаем о хорошем образовании, которые бы нравилось всем: студентам, преподавателям, работодателям). Идеи я размещал в порядке нарастания их утопичности. Да, я отдаю себе отчёт в том, что никто не станет этот план реализовывать. Да, я начал с себя и кое-что хорошего уже постарался сделать в обозреваемой области.

Я подумал, чем же я могу поделиться с уважаемыми хабрачитателями, кроме сугубо специализированных знаний. Наверно, многие считают лишним разжевывание мануалов, но я уже много лет именно этим и занимаюсь, отвечая на массу вопросов каждый день. И не понаслышке знаю, каково это — отвечать на несформулированные вопросы :)
Поэтому я посчитал возможным описать несколько простых правил, которые как мне кажется, могут помочь коммуникативному процессу.

Herb Sutter (автор Exceptional C++, бывший глава ISO C++ standards committee, мистер Free Lunch Is Over и прочая, и прочая) работает в Microsoft и иногда по средам читает атомные лекции.

Я наконец-то на одну такую попал, и очень радовался. На умных мужиков всегда радостно поглядеть и послушать.
Для отчета — кроме Херба, видел живого Олександреску и живого Walter Bright (который "D").

Лекция называлась «Machine Architecture: Things Your Programming Language Never Told You» (здесь можно скачать презентацию и видео) и была про конкретную часть abstraction penalty — Memory Latency.

Я попытаюсь коротко рассказать о ключевой мысли лекции. Она простая, очевидная и тысячу раз сказанная. Думаю, еще раз повторить азбуку — никогда не повредит.

Внезапно оказалось, что Shoreline firewall совсем не освещен на Хабре, несмотря на то, что является крайне удобным инструментом (и весомым аргументом против pf в холиварах) для настройки файрволла под линуксом.

Просьба не холиварить на темы «Линукс — говно, у нас в OpenBSD круче», «А у меня Kerio WinRoute, а вы все неудачники» и подобные.
Статья для тех, кто выбрал Linux из каких-то соображений и не хочет тратить уйму времени на изучение iptables (а там есть, где запутаться).

Посему, под катом простыня

Введение.

На фоне многочисленных постов о паролях решил провести небольшое исследование.

В настоящее время парольная защита является самым распространённым и, к сожалению, самым ненадёжным методом защиты. Существует много статей на тему «Как составить стойкий пароль», но мне не встречались статьи, где приводятся реальные данные о надёжности паролей.

В исследовании проводится оценка надёжности паролей противостоять атакам грубой силы. Наиболее эффективный метод грубой силы при переборе паролей для хеш-функций является составление радужных таблиц.

Расчёты проводятся для трёх хеш-функций md5, sha1 и sha2 (модификация sha512). В расчёт не берутся данные о коллизиях в данных хеш-функциях, так как с практической точки зрения в реальном подборе пароля они не помогут, да и достойных реализаций в ПО на настоящий время в открытом доступе нет. В исследовании принимают участия пароли длиной 7, 8, 10 и 12 символов трёх различных алфавитов.

Для наглядности результатов приводятся данные о количестве паролей, объёме дискового пространства для хранения радужных таблиц и ориентировочном времени построения радужных таблиц.

Beginning.

*магнит отображает суть всей переделки и
является окончательным штрихом всего труда

Очень мне захотелось свой системный блок сделать тихим, чтобы несмотря на работу в режиме 24\7 — не грелся, а я слышал только музыку и никаких посторонних шумов. Сказано — сделано!

Сегодня я хочу сделать новогодний подарок, а так как самое ценно в мире — это опыт, знания и технологии, то хочу поделиться этим всем с вами. Надеюсь, что мой трехлетний опыт работы системным инженером/архитектором поможет некоторым хостерам открыть для себя новые горизонты.

Следует отметить, что под клиентом воспринимается обычный аккаунт на LAMP (Linux+Apache+Mysql+PHP), с одним-двумя виртхостами и работающим со всеми опциями php.ini по умолчанию. Основное — это 16MB RAM и 30 сек исполнения. Вполне достаточно для большинства движков — Wordpress, Drupal и Joomla.

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

С Новым Годом! С Новым Счастьем!

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

Вообщем, идея протокола такая — он позволяет строить распределенную децентрализованую сеть обмена сообщениями, предоставляющую различные сервисы. Сеть должна строиться и настраиваться автоматически, при минимальном вмешательстве со стороны пользователя. По техническим причинам, автонастройка допустима только в одном сегменте (256 узлов), но с учетом того, что каждый узел может обслуживать до 2^32 клиентов, это более, чем достаточно.



Некоторые принципы и идеи позаимствованы из FTN (фидонет). Что-то придумано с нуля или по образу и подобию уже существующих систем. Многое предстоит придумать и реализовать, а потом много раз переделывать и дополнять. Не знаю, сколько это займет времени… Но попробовать стОит.

Вот такой текст я разместил на своем сайте год назад. И вот что из этого получилось…

Давно хотел написать подобную заметку, но все не решался выносить свои мысли, метафоры и рассуждения на широкий суд хабраобщественности.

«Стартап — недавно созданная компания, обладающая ограниченными ресурсами и строящая свой бизнес на инновациях и инновационных технологиях». Я очень часто размышляю над сутью этих слов. Почему-то многие, от кого мне приходилось слышать слово «Стартап», по большей части, не понимают, в чем его основное предназначение. Довольно смешно выходит, когда очередной новостной портал называют стартапом. Или в десятый раз переваренный контент — инновациями.

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

Если вы считаете себя стартапером, у вас есть свой личный «инновационный» проект, вы каждый день смотрите с завистью на очередную новость про «корпорацию добра» и в тайне от жены откладываете деньги на неделю отпуска с ноутбуком на чердаке — скажите, много ли вопросов вы задаете сами себе? Нет, не пытаетесь стремглав найти решение, а просто составляете список тех насущных вопросов, которые вам когда-то придется решить, начав изобретать очередной велосипед в своем уютном гараже? И на каком месте в этом списке стоит вопрос «Кому это нужно?».

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

Читал и я, даже возмущался: «Нет, ну как же можно по телефону кому-то там сказать свой пароль». Но, увы, лучше всего запоминается удар граблей по собственному лбу. Так и вышло. За последние пару месяцев я стал свидетелем и даже участником нескольких ситуаций, о которых рассказывать стыдно, но социально полезно.

Все мы обо всём прекрасно знаем в общем и в теории, но в частных случаях и на практике — знаниями часто пренебрегаем. Тут лучше всего спасает опыт (в идеале: негативный, но чужой). Им и хочу поделиться, а вас приглашаю заняться тем же в комментариях (несколько простых, но очень полезных советов — там уже прозвучало).

Задача: собрать малогабаритный домашний сервер с четырьмя 3,5-дюймовыми HDD, по возможности тихий. Служить будет в качестве NAS, backup-сервера и торрентокачалки.

Решение

Последняя версия этой статьи о делегировании.
Есть такое умное слово — делегирование. Определение я бы дал такое: делегирование — это процесс передачи ответственности за результат исполнение на другого субъекта. Вряд ли, кто то в здравом уме скажет «Я тебе это делегирую», чаще мы используем слово «поручаю». Попробую поделиться своим опытом, как перекладывать с больной головы на здоровую.

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

Выглядит всё это, как всем известный TortoiseSVN для Windows. Только называется RabbitVCS и уже для Linux.
Если не верите, смотрите скриншоты :)

С того момента как я начал программировать я наблюдал и думал об одном особом явлении — как большинство программистов активно избегают всего, что касается дизайна интерфейсов и вопросов юзабилити.


Я понимаю, откуда это пришло. Большинство программистов любят программировать. Они готовы учиться новым особенностям языков программирования, пробуют новые компоненты и библиотеки, улучшают свои алгоритмы и архитектуру кода или скажем оптимизируют структуру используемых данных. Это кажется очень важным, потому что, программа хороша настолько, насколько хороши её коды и алгоритмы и насколько все это оптимизировано. И это так. Но только если программы пишутся для программистов.

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

Почитал я, как люди бьются с пользователями своего софта и решил поделиться с миром опытом. Сразу скажу, что опыт у меня не маленький — в своё время мои программы пользовались большим спросом и на их поддержке я не одну собаку съел. В результате клиенты пИсали кипятком, а пользователи саботировали любой другой софт, спускаемый сверху, кроме моего. В качестве истории успеха приведу не слишком большой проект автоматизации АЗС.

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

Представляю вашему вниманию перевод очередного замечательного эссе Пола Грэма What Startups Are Really Like.

Октябрь 2009
(Это эссе основано на выступлении в Школе Стартапов в 2009г.)

Я не знал о чем говорить в Школе Стартапов, поэтому я решил спросить создателей стартапов, которые мы профинансировали. О чем я еще не написал?

Я нахожусь в необычной ситуации, имея возможность проверить те эссе, которые я написал о стартапах. Надеюсь, что эссе на другие темы тоже верны, но у меня нет возможности их проверить. Эссе о стартапах проверяются 70 разными людьми каждые 6 месяцев.

Итак, я отправил всем основателям письмо, в котором спросил их, с какими неожиданными вещами они столкнулись, создавая стартап. Фактически, я спросил их, что я сам неправильно понимаю, потому что я все объяснил достаточно хорошо, и ничто не должно было их удивлять.

Я с гордостью могу сказать, что получил один ответ, который гласил:

Что больше всего меня удивило, так это то, что все действительно было довольно предсказуемо!

Плохая новость состоит в том, что я получил больше 100 других ответов с описаниями неожиданностей, с которыми столкнулись основатели стартапов.
Полученные ответы четко разбивались на несколько категорий; примечательно, как часто несколько человек были удивлены в точности одним и тем же.

STL славится своей способностью заполнять метры экранного пространства сообщениями об ошибках. Надоело смотреть на экран и видеть перлы вроде:

testmap.cpp:25: error: no matching function for call to ‘std::map<int, double, std::less, std::allocator<std::pair<const int, double> > >::map(int, int, int)’
/usr/include/c++/4.3/bits/stl_map.h:175: note: candidates are: std::map<_Key, _Tp, _Compare, _Alloc>::map(const std::map<_Key, _Tp, _Compare, _Alloc>&) [with _Key = int, _Tp = double, _Compare = std::less, _Alloc = std::allocator<std::pair<const int, double> >]
/usr/include/c++/4.3/bits/stl_map.h:165: note: std::map<_Key, _Tp, _Compare, _Alloc>::map(const _Compare&, const _Alloc&) [with _Key = int, _Tp = double, _Compare = std::less, _Alloc = std::allocator<std::pair<const int, double> >]


ну и еще пара десятков строк.

Предыстория

Я учился на первом курсе, когда один мой знакомый поделился со мной секретом, как прогуливать пары без каких либо проблем. Идея заключалась в том, что нужно было посещать только те предметы, которые являлись «важными» с точки зрения сдачи сессии. В результате можно было спокойно прогуливать пары без страха быть отчисленным. Мне эта идея казалась бесполезной, поскольку я не стремился прогуливать занятия и считал своим долгом использовать все возможности, которые давал университет.

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

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