День добрый,
сим постом хочу предупредить русскоязычное сообщество о новой фишинг тенденции, семимильными шагами двигающейся по Европе. В настоящее время накрыло Германию. Думаю такими темпами очень быстро доберется до России и СНГ.

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

На такую уловку попадаются даже люди, серьезно относящиеся к безопасности своих данных, например проверяющие URL в браузерах перед оплатой PayPal и т.д. Это объясняется высоким уровнем доверия к информации, висящей например внутри крупного банка.

^{Локализованная игра. Слов тут нет.}

Экономика — очень прикольная штука, которая часто заставляет делать странные вещи. Например, есть игра «7 на 9», в которой нет ни одного английского слова, только цифры. И всё же мы занялись её локализацией для того, чтобы иметь возможность продавать почти в два раза дешевле.

Вообще, в каждой сфере начиная от продажи железа и заканчивая косметикой, есть огромное количество мифов про настоящую цену товара. Например, многим вспоминается фраза, что себестоимость кроссовок Адидас — 2 бакса, а остальное они добавляют за логотип. Ещё некоторые не верят, что обычные налоги в нашей стране составляют больше 50%, потому что привыкли к «разрекламированным» 13%.

Вот про эти мифы я и поговорю на примере точного образования цены настольной игры.

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

Часто ли уходя за очередной чашечкой кофе или выйдя из кабинета/офиса совершить личный звонок, ты ловишь себя на мысли что забыл заблокировать экран своего компьютера? А на компьютере в это время осталась открытая переписка в Skype/почте или еще хуже — сессия root'а в консоли? В результате ты стараешься вернуться к своему компьютеру как можно быстрее, чтобы добрые коллеги не успели поставить фоном рабочего стола обои с Черным Властелином.
В данной статье приведу пример решения этой проблемы с блокировкой экрана, которое поможет закрыть доступ к рабочему столу в тот момент когда ты отойдешь от компьютера.

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

Введение

С момента написания мной предыдущей статьи по оптимизации этой связки прошло довольно много времени. Тот многострадальный Pentium 4 c 512Мб памяти, обслуживающий одновременно до тысячи человек на форуме и до 150,000 пиров на трекере уже давно покоится на какой-нить немецкой, свалке, а клуб сменил уже не один сервер. Всё сказанное в ней всё ещё остаётся актуальным, однако есть вещи которые стоит добавить.
Статья большая, так что будет поделена на логические блоки:

0. Зачем вообще что-то оптимизировать?
  
1. Оптимизация ОС (FreeBSD)
  1.1 Переход на 7.х 
  1.2 Переход на 7.2
  1.3 Переход на amd64
  1.4 Разгрузка сетевой подсистемы
  1.5 FreeBSD и большое кол-во файлов
  1.6 Softupdates, gjournal и mount options
  
2. Оптимизация фронтенда (nginx)
  2.1 Accept Filters
  2.2 Кеширование
  2.3 AIO
  
3. Оптимизация бэкенда
  3.1 APC
  3.1.1 APC locking
  3.1.2 APC hints
  3.1.3 APC fragmentation
  3.2 PHP 5.3
  
4. Оптимизация базы данных
  4.1 MySQL 
  4.1.1 Переход на 5.1
  4.1.2 Переход на InnoDB
  4.1.3 Встроеный кеш MySQL - Query Cache
  4.1.4 Индексы
  
4.2 PostgreSQL
  4.2.1 Индексы
  4.2.2 pgBouncer и другие.
  4.2.3 pgFouine
  
4.3 Разгрузка базы данных
  4.3.1 SphinxQL
  4.3.2 Не-RDBMS хранилище
  4.4 Кодировки
  4.5 Асинхронность
  
Приложение. Мелочи.
  1. SSHGuard или альтернатива.
  2. xtrabackup
  3. Перенос почты на другой хост
  4. Интеграция со сторонним ПО
  5. Мониторинг
  
 6. Минусы оптимизации

Все мы знаем как хорошо и похвально принимать участие в разработке открытых проектов.
К тому же потом можно мерятся количеством коммитов в rails и зарплату попросить побольше.

А что если вы решили написать свой open source проект?

Бывало ли когда-нибудь так, что вы набирали в браузере длинный и интересный текст, внимательно вычитывали его, и тут, буквально через мгновение, понимали, что при обращении к сайту произошла ошибка, а ваш текст в форме был стёрт?

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

И, тем не менее, вы писали длинный текст именно там, где ничего для сохранения данных формы не сделано.

Можно ли теперь как-то восстановить данные, если вы не можете скопировать текст из формы и не можете отправить POST-запрос повторно?

Не закрывайте браузер!

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

При дроблении картриджей в дробильно-сортировальном комплексе произошел взрыв из-за мелкодисперсного тонера (порошка) и как следствие — пожар

Вчера на американских биржах произошла маленькая, но очень интересная аномалия, о которой оперативно сообщила аналитическая компания Nanex Research.

31 января 2013 года примерно за 400 миллисекунд до официальной публикации недельногого отчёта по запасам природного газа резко увеличилась торговая активность по фьючерсам на природный газ и паям индексных фондов, таких как UGZ, UNG и BOIL.

Отчёт опубликован в 10:30:00. На графике вверху показана активность на торгах индексным фондом UGZ в промежутке с 10:29:59 до 10:30:02, с официальными метками времени транзакций от разных бирж.

В этой статье я расскажу о том, как загруженность шины данных влияет на масштабируемость (scalability) приложений. Под масштабируемостью мы будем понимать не только способность многопоточного приложения сокращать свое время выполнения по мере увеличения числа потоков. Мы также добавим сюда и способность однопоточного приложения, запущенного одновременно в несколько копий (instances), выполняться за тот же самый промежуток времени, что и одна копия. Хотя последний пример было бы правильнее охарактеризовать таким свойством как пропускная способность (throughput), так как он относится к «серверному» режиму запуска приложений. Т.е. это такой режим, при котором на сервере запускается однопоточное приложение, каждый раз когда к нему подключается новый клиент. Главная задача при разработке таких приложений — это снижение их зависимости от общих ресурсов, одним из которых может являться шина данных.

Сетевой инженер Кристиан Кильхофнер (Kristian Kielhofner), купив новые серверы для обработки VoIP-трафика, столкнулся с неприятной проблемой. Серверы периодически падали без видимой причины. Но самое странное, что на серверах иногда отключался Ethernet-контроллер. Отключался в прямом смысле: система некоторое время работала нормально, но после обработки определённого количества трафика интерфейс выдавал аппаратную ошибку и обрывал связь, а восстановление работы было возможно только после холодной перезагрузки.

Кристиан провёл небольшое исследование и нашёл ряд сообщений о том, что у других пользователей тоже бывают проблемы с контроллерами Intel 82574L, говорили, что у них баги в EEPROM, ASPM и т.д. Кристиан с коллегами потратил несколько месяцев на поиск причин, почему в их случае контроллеры выдавали ошибку. В конце концов, им удалось докопаться до сути.

Полгода назад здесь была опубликована статья, которая меня возмутила. В комментариях я обещал, что напишу свою версию. С другой стороны мне не хотелось этого делать, так как получу закономерные вопросы: «А ты собственно кто такой?». Не люблю подписываться в интернет-постах, у меня портилось мнение о многих писателях после того, как читал их жж-блог. Читаешь книгу, думаешь: «Классный чувак!», почитаешь блог, мнение меняется: «Что за кретин?». Такая разница возникает из-за того, что книга проходит пост-обработку, много раз редактируется.
Данная статья переписывалась несколько раз, в этом варианте, считаю, что она получилась наиболее взвешенной. Статья вполне подходит для хабрахабр, так как от людей технической направленности выходило немало известных произведений. И кому-то из вас захочется написать свою историю.

Это мой первый пост на Хабре, поэтому не судите строго. Я достаточно много занимаюсь не только разработкой, но и постановкой процессов, в том числе тестирования. И всегда несколько скептически относился к ручному тестированию, точнее к той его части, которая отвечает за «обеспечение работоспособности существующей фунциональности» (в простонародье регрессионное тестирование). Что же плохого в этом тестировании и почему многие компании его тогда используют? Кто интересуется ответом на эти вопросы, могут потратить еще пару минут на дальнейшее чтение.

С 2011 года суперкомпьютер IBM Watson начал свою работу в сфере здравоохранения: в рамках сотрудничества с медицинскими организациями WellPoint и Memorial Sloan-Kettering Cancer Center он стремится помочь врачам в диагностике заболеваний и выборе методов лечения.

Но, как и любому врачу (да и всем нам), Watson’у необходимо постоянное повышение квалификации, и он поступает в медицинский колледж Кливлендской клиники.

Что-то на Хабре совсем нет постов о таком замечательном инструменте как DipTrace. Думаю необходимо исправлять эту ситуацию.



DipTrace — это мощная система проектирования принципиальных схем и печатных плат (EDA — система).
Внимание! Под катом трафик!

Это перевод статьи с ReadWrite.com от Майка МакДермента — основателя и CEO FreshBooks. Читайте его в Twitter @MikeMcDerment



В конце прошлого года Google Apps отключили регистрацию бесплатных аккаунтов. Вы, должно быть, расстроились и подумали, что для владельцев малого бизнеса это настоящая трагедия. Ведь бесплатно — это всегда хорошо, так?

Нет, не так.

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

Но обо всём по порядку.

Данная статья является логическим продолжением следующих статей:

• Работа с памятью (и всё же она есть)
• Насколько большие массивы (и значения) в PHP? (Подсказка: ОЧЕНЬ БОЛЬШИЕ)

Цель этой статьи — заставить всех, особенно программистов на Си, сказать «я не знаю Си».
Хочется показать, что тёмные углы в Си значительно ближе, чем кажется и даже тривиальные строки кода несут в себе undefined behavior.

От переводчика. Занимаясь созданием и внедрением системы электронного архива, мы не раз сталкивались с ситуациями, когда организации вводят документы в систему без разбора, не уделяя должного внимания экспертизе их ценности. Об этом уже писали. В обсуждениях наших предыдущих публикаций по данному вопросу большинство участников отстаивали следующий взгляд: сохранять можно всю поступающую информацию, она в любой момент может пригодиться. Насколько обоснован такой подход в масштабах крупной организации. Что дешевле и эффективнее: сохранять все, что возможно сохранить — или же грамотно управлять информацией, своевременно удаляя все ненужное? Любопытную статью на эту тему мы нашли в блоге Джорджа Парападакиса, ECM-специалиста из компании IBM. Ее перевод мы и предлагаем вниманию наших читателей.