Сегодня я нашел отличную реализацию мако-подобного мультитач для трекпада моего нетбука с ubuntu 10.10. Это Touchegg, теперь с графическим интерфейсом настройки.

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

Что такое представление?

Представление (VIEW) — объект базы данных, являющийся результатом выполнения запроса к базе данных, определенного с помощью оператора SELECT, в момент обращения к представлению.

Представления иногда называют «виртуальными таблицами». Такое название связано с тем, что представление доступно для пользователя как таблица, но само оно не содержит данных, а извлекает их из таблиц в момент обращения к нему. Если данные изменены в базовой таблице, то пользователь получит актуальные данные при обращении к представлению, использующему данную таблицу; кэширования результатов выборки из таблицы при работе представлений не производится. При этом, механизм кэширования запросов (query cache) работает на уровне запросов пользователя безотносительно к тому, обращается ли пользователь к таблицам или представлениям.

Представляю Вам первый в своем роде проект в интернете, позволяющий эмулировать NES ROMs на Flash.

Встречайте www.nesbox.com! На сайте собрана коллекция из 1804 игр! (мне в детстве такое и не снилось.

Не так давно на хабре был топик, который привел на наш сайт 17 тысяч посетителей за два дня (11,828+5,100 on October 21, 2010). С 2009го года эта уже не первая волна, а последние иконки будут нарисованы в первой четверти 2012го года. Best reseller hosting providers.



Не хватает еще 1000 иконок для best email hosting. Готовы ли вы предложить метафоры, которых у нас еще не хватает? Тогда follow me…

Всеми любимый набор иконок — Fugue, обновился (16 июля) до версии 3.0. Изменения небольшие, были добавлены 32 гипер-маленькие иконки.

Мега-превью! (3Mb)
Иконки
Иконки + исходники

Эту статью давно стоило переписать (слишком много «экономии на спичках»), но руки не доходят. Пускай весит и напоминает о том, как мы глупы в молодости.
Одним из основных критериев успешности любого интернет-ресурса является скорость его работы и с каждым годом пользователи становятся всё более и более требовательными по этому критерию. Оптимизация работы php-скиптов — это один из методов обеспечения скорости работы системы.
В этой статье я бы хотел представить на суд общественности свой сборник советов и фактов по оптимизации скриптов. Сборник собирался мною достаточно долго, основан на нескольких источниках и личных экспериментах.

Статья написана по материалам моего доклада на CodeCamp 2009.

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

У любого проекта всегда есть что оптимизировать: можно почитать советы по оптимизации на webo.in, установить eaccelerator, memcache, проиндексировать поисковые поля в базе данных. Я предполагаю, что все это уже проделано, а сайт по прежнему тормозит.

Пришло время оптимизировать nginx...

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

Вчера в топике «Модификация изображений для сайта, или какие бывают превьюшки» в комментариях diGreez предложил, как мне показалось, очень интересный способ организации превьюшек изображений. Реализовал на PHP функцию, которая занимается созданием таких превьюшек.
Функция документирована комментариями.

В этом топике расскажу как можно в пару скриптов наладить простой сбор статистики по аномальной активности в сети.

Аномальным для нас будет на момент снятия статистики:

1. Более 20 исходящих коннектов по 25 порту с 1 IP.
2. Более 100 исходящих коннектов по 80 порту с 1 IP.
3. Более 100 исходящих коннектов по 53 порту с 1 IP.
4. Придумывайте сами, всё гибко.

Статистику будем вынимать из кэша netflow маршрутизаторов. Будет ли это Cisco или FreeBSD — не важно. О настройке netflow на FreeBSD я рассказывал в предыдущих своих статьях.

В последнее время приходится часто настраивать с нуля маршрутизаторы Cisco (в основном 800-1800 серии) для филиалов моей компании и дабы не набирать одни и теже команды третий десяток раз составил для себя небольшой шаблон настроек на разные случаи жизни. Сразу скажу что сертификаты от Cisco не получал, книжек по данным роутерам особо не читал, весь свой опыт приобрел методом научного тыка, курением мануалов на cisco.com и кое каким вдумчивым заимствованием кусков чужих конфигов…

Позволю себе поднять упавшее знамя, оставшееся после предыдущих ораторов и продолжить благое дело продвижения zsh в массы. Надеюсь, после прочтения топика вы тоже смените старый добрый, но, как по мне, так застрявший в прошлом, bash на более удобный и продвинутый zsh.
Чтобы не быть голословным, попробуем рассмотреть это дело в контексте абсолютно субъективного и предвзятого сравнения bash vs. zsh.

FreeBSD, сетевая Intel fxp, порт 100Мбит, polling, http accept-filter
в sysctl:

sysctl kern.maxfiles=90000
sysctl kern.maxfilesperproc=80000
sysctl net.inet.tcp.blackhole=2
sysctl net.inet.udp.blackhole=1
sysctl kern.polling.burst_max=1000
sysctl kern.polling.each_burst=50
sysctl kern.ipc.somaxconn=32768
sysctl net.inet.tcp.msl=3000
sysctl net.inet.tcp.maxtcptw=40960
sysctl net.inet.tcp.nolocaltimewait=1
sysctl net.inet.ip.portrange.first=1024
sysctl net.inet.ip.portrange.last=65535
sysctl net.inet.ip.portrange.randomized=0


По просьбам переписываю статью с добавлением теоретический знаний. Итак, пара определений:

С IPTV пришлось познакомиться поближе, когда в компании интернет-провайдера где я работал, решили организовать вещание IPTV. Выяснилось, что вещание осуществляется в linux и программой vlc, которая по слухам единственная в своем роде. Была установлена тарелка и DVB-карта SkyStar2, которая предположительно должна была без проблем заработать в linux'e. Так и было со всеми новыми машинами, где была установлена ubuntu server. На Debian заработало только после обновления ядра. Настройка прошла относительно легко, благо на то время уже было несколько статей на эту тему и документация к vlc была тоже очень полезна. После запуска начались некоторые проблемы с пропаданием звука и видео на каналах и другие проблемы, описанные ниже. После их появления были написаны скрипты, устраняющие эти проблемы. Сейчас на них работает 3 сервера с 5 dvb-картами в общей сложности и вещается 23 канала с 3х спутников. Под катом — перечисление проблем, которые могут появиться после запуска вещания IPTV через VLC в Linux и то как с ними бороться. Бороться будем с помощью bash.

Доброго времени суток.
Хочу вам рассказать про настройку приема спутниковых не закодированных тв каналов в linux и вещание их в локальную сеть.
Исходными данными будем считать наличие спутниковой антенны настроенной на определенный градус(например на www.lyngsat.com/amos2.html) и компьютера под управлением linux(не важно какой дистрибутив, в моем случае был Slackware). Задача очень интересная и актуальная в наше время.

Введение

С момента написания мной предыдущей статьи по оптимизации этой связки прошло довольно много времени. Тот многострадальный 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. Минусы оптимизации