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



Заинтересованная аудитория: авторы HTML-контента, разработчики скриптов серверных приложений (PHP, JSP и т.д.), менеджеры веб-проектов и любые другие люди, так или иначе связанные с дизайном форм ввода данных, дизайна баз данных и онтологий, которые затрагивают личные имена людей.

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

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

IP-адрес (v4) состоит из 32-бит. Любой уважающий себя админ, да и вообще айтишник (про сетевых инженеров молчу) должен уметь, будучи разбуженным среди ночи или находясь в состоянии сильного алкогольного опьянения, правильно отвечать на вопрос «из скольки бит состоит IP-адрес». Желательно вообще-то и про IPv6 тоже: 128 бит.

Обстоятельство первое. Всего теоретически IPv4-адресов может быть:
2³² = 2¹⁰*2¹⁰*2¹⁰*2² = 1024*1024*1024*4 ≈ 1000*1000*1000*4 = 4 млрд.
Ниже мы увидим, что довольно много из них «съедается» под всякую фигню.

Записывают IPv4-адрес, думаю, все знают, как. Четыре октета (то же, что байта, но если вы хотите блеснуть, то говорите «октет» — сразу сойдете за своего) в десятичном представлении без начальных нулей, разделенные точками: «192.168.11.10».

В заголовке IP-пакета есть поля source IP и destination IP: адреса источника (кто посылает) и назначения (кому). Как на почтовом конверте. Внутри пакетов у IP-адресов нет никаких масок. Разделителей между октетами тоже нет. Просто 32-бита на адрес назначения и еще 32 на адрес источника.

Хотелось бы поговорить с вами на актуальную нынче тему, а именно — про DDoS и методы борьбы с ним. Рядовые администраторы знают, что это такое, а вот для большинства вебмастеров это аббревиатура остается загадкой до того момента пока они на личном опыте не столкнуться с этой неприятностью. Итак, DDoS — это сокращение от Distributed Denial of Service (распределенный отказ в обслуживании), когда тысячи зараженных компьютеров отправляют на сервер множество запросов, с которыми он, в последствии, не может справиться. Целью DDoS атаки является нарушение нормальной работы сервера, а в дальнейшем — «падение» сайта или сервера целиком.

Как же от этого защититься? К сожалению, универсальных мер защиты от DDoS-атак до сих пор не существует. Тут необходим комплексный подход, который будет включать меры аппаратного, программного и даже организационного характера.

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

Sony Pictures database

Исследование Троя Ханта, который взял за предмет своих изысканий, базу пользователей Sony Pictures, стоит отметить, что все пароли хранилась в открытом виде. А дальше он проанализировал пользовательские пароли. Вот такие результаты у него получились.

Длина пароля

Как мы видим, основное количество паролей с диной от 6 до 10 символов. При этом у половины он менее 8 символов.

Используемые символы

1% - только буквы верхнего регистра
4% - только цифры
45% - только буквы нижнего регистра
50% - другие варианты

Криптографическая стойкость пароля определяется вариацией букв различных регистров + цифры + спец. символы ^ длина пароля. На данном примере мы можем наблюдать, что используются пассы одного типа.

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

В предыдущей статье я рассказал о возможностях, которые предоставляет закон № 152 владельцу персональных данных. В этой частью статьи представлен сам механизм и формы запросов для реализации своих прав. В статье не рассматриваем вопрос, когда оператор вообще не имеет права обрабатывать персональные данные. Задача — сделать так, чтобы оператору персональных данных незаконная обработка этих данных стоила серьезных финансовых и временных затрат.

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

Зачем может понадобиться писать демоны на PHP?

• Выполнение трудоемких фоновых задач;
• выполнение задач, которые длятся больше, чем время ожидания при HTTP-запросе (30 секунд);
• выполнение задач на более высоком уровне доступа, чем серверный процесс (читай — под рутом).

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

Начиная с версии 5.1 mySQL поддерживает горизонтальное партицирование таблиц. Что это такое? Партиционирование (partitioning) — это разбиение больших таблиц на логические части по выбранным критериям.. На нижнем уровне для myISAM таблиц, это физически разные файлы, по 3 на каждую партицию (описание таблицы, файл индексов, файл данных). Для innoDB таблиц в конфигурации по умолчанию – разные пространства таблиц в файлах innoDB (не забываем, что innoDB позволяет настраивать индивидуальные хранилища на уровне баз данных или даже конкретных таблиц).

Как это выглядит?

Много камней было брошено в адрес MySQL, ввиду отсутствия возможности трассировки сессий и снятия stats pack отчетов, показывающих какие именно события нагружают базу данных. Начиная с версии 5.5 MySQL наконец-то озадачился необходимостью решения данной проблемы и выставил прототип, который в будущем, возможно, приведет к созданию аналогичных инструментов в MySQL. Сегодняшний мой рассказ будет о таком мощном (к сожалению пока только для разработчиков MySQL) инструменте как PERFORMANCE_SCHEMA. Итак выставляем performance_schema=ON в конфигурационном файле my.cnf, и приступаем к изучению её ограниченных, но уже крайне интересных возможностей.

Сегодня во время перевода одного сайта с таблиц MyISAM на InnoDB, у последних выяснилась одна интересна особенность. Запрос на изменение движка для двух таблиц возвращал странную ошибку «Got error 139 from storage engine». После поиска информации на эту тему, было выяснено, что данная ошибка возникает тогда, когда какая-либо строка таблицы не вмещается в половину страницы памяти, с которыми работает MySQL. Страницы эти равны 16 Кб, а половина, стало быть, 8 Кб.

Само по себе ограничение довольно странное, но на первый взгляд кажется трудно достижимым, ведь как известно, MySQL хранят текстовые данные в хранилище, отдельном от табличных строк. Оказалось, что это верно только на половину. На самом деле InnoDB хранит в отдельном хранилище только «излишки», к коим он не относит первые 768 байтов каждого текстового поля. Т.е. любой текст будет отъедать от длины строки столько байт, сколько он содержит, но не больше 768. Несложно подсчитать, что максимальное число текстовых полей длиной от 768 байт, которое можно безопасно хранить в одной таблице — 10. И действительно, если запустить пример, все пройдет гладко. Но стоит увеличить количество полей хотя бы на одно, и мы получим ту же ошибку, что и в начале.

Те из нас, кто работает с кучей Linux-серверов, а сидеть приходится под Windows вынуждены пользоваться Putty — он всем хорош: бесплатен, поддерживает все что нужно, но есть одна проблема: когда настроенных соединений становиться слишком много — массовое изменение параметров высосет из вас все соки (также как например и установка ваших любимых параметров для новых соединений). На хабре 2.5 года назад была заметка на эту тему, но там по прежнему требуется много ручной работы.

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

Скрипт берем тут — лицензия MIT = делаем что хотим (для запуска нужен питон). По умолчанию скрипт меняет цвета чтобы (мне) лучше читалось (тёмно-синий делает чуть светлее, светло синий — также), увеличивает буфер прокрутки до 20к (чтобы уехавший текст не пропадал), устанавливает размер окна по-больше, включает разворачивание по Alt+Enter на весь экран, убирает предупреждение при закрытии и включает сжатие SSH трафика.

Само собой сюда втыкать можно любые параметры. При добавлении нового соединения я просто прокатываю этот скрипт и готово. Под катом — исходник текстом, можно не кликать ;-)

Интернет-адреса IPv4 близки к исчерпанию. Для большинства компаний встает вопрос, насколько это окажет на них влияние? Нужно ли немедленно переводить всю инфраструктуру на IPv6, или можно воспользоваться другими вариантами? Ниже предлагается размышления, когда об этом стоит побеспокоиться, и когда — что важнее — не стоит.

Дисклаймер: описываю только свой личный опыт и мнения автора могут не совпадать с мнением автора. Статья огромная, читать много.

Пишу эту статью, и представляю себе тебя, читателя Хабра, которой в обеденный перерыв залез почитать что-нибудь для развития. А этот читатель, т.е. ты (да, не отворачивай глаза от букв, именно ты) давно наслышан, что своё дело – это круто. И, может быть, как раз не хватало лёгкого пинка, чтобы выйти из зоны будничного комфорта и что-нибудь, да предпринять.

Эта статья адресована тем, кто уже «на грани». Она почти лишена философии и туманных ссылок, просто тупо туду-лист. Бери и делай. Намеренно избавляю тебя от объяснений, зачем молодому проекту нужна госрегистрация, такая ли уж это свобода – быть собственником и от куда взять деньги на госпошлину. Статья адресована московским стартаперам, гео-патчи от других городов приветствуются в комментариях.
Будем считать, что с формой собственности определились — это ООО и упрощенка 6%. Если кому нужно ИП – там проще, справишься и без этой статьи.

Для создания фирмы необходимо:

В догонку к посту про макет бизнес модели, не менее полезный «самый короткий в мире маркетинговый план» (так его назвал автор, Келли Одел).

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

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

Upd: В названии статьи хоть и фигурирует SVN, но советы, изложенные в ней, подходят ко всем известным мне системам кондроля версий. Стоит так же заметить, что советы направлены в основном на командную разработку.

Немного о том, кому и зачем?

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

В общем к сути.

Сайт проконтент собирает под своим крылом базу мобильных айпи и выкладывает вот здесь: www.procontent.ru/dev/gateway-ips.html
Но попробуйте кто то применить ее для дела и тут сразу же все неудобства всплывают. Нету четкого разбиения по странам, а страна и не для всех диапазонов указана, нету экспорта хоть в какой нибудь пригодный для нормальной обработки формат.
Так вот был написан парсер, который «причешет» этот неудобный набор и даст в правильном виде.
Брать можно тут:
wapobzor.ru/3dparty/procontent_ips.php — csv версия
wapobzor.ru/3dparty/procontent_ips.php?long — csv, но ip в числовом виде
wapobzor.ru/3dparty/procontent_ips.php?php_array — в виде массива, что бы скопировать в скрипт сразу.
wapobzor.ru/3dparty/procontent_ips.php?php_array&long — аналогично
www.logofon.ru/xml/ips.xml — еще один вариант предложенный Nc_Soft

Если кому то пригодится — буду рад.
Спасибо за внимание =)

UPD: перенес в тематический блог, спасибо за подкинутую карму :-)
UPD2: добавил еще два варианта вывода.
UPD3: еще вариант базы с другого источника.

Хочу поднять вопрос, который, как мне кажется, никто не рассматривал ранее системно. Вопрос звучит так:

как называть узлы и интерфейсы узлов в сети?

Для начала обрисую суть проблемы: когда у вас 2-3-5-10 серверов, то их названия, адреса и т.д. вы быстро запоминаете, и особой путаницы они не вызывают. Но если у вас несколько тысяч серверов (добавим к реальным ещё виртуальные), если у вашего маршрутизатора несколько сотен реальных или виртуальных (в виланах) интерфейсов, каждому из которых нужно дать имя (хотя бы для PTR/A записей в DNS), когда у вас есть интерфейсы для конфигурирования коммутаторов, принт-серверов, сетевых принтеров… В этих условиях нужно реально садиться и думать, как их называть. Лучше садиться думать до того, как начали называть, чем после.

Статья раскрывает смысл термина «64 бита». В статье кратко рассмотрена история развития 64-битных систем, описаны наиболее распространенные на данный момент 64-битные процессоры архитектуры Intel 64 и 64-битная операционная система Windows.