1. Я правильно понял, что мед.страховка на работе отсутствует? Иначе какая мне разница, сколько стоит поставить пломбу или удалить нерв из зуба?
В Норвегии, мед.страховки как таковой нет. Каждый житель Норвегии имеет право на «бесплатную» медицину. Допустим серьезные операции, роды и т.п. проводятся совершенно бесплатно. По менее серьезным вопросам, если не обращаться в частные клиники, а идти к своему терапевту, который дает направления к специалистам, то все что переваливает за 2тыс. крон в год, оплачивает государство. Но, к сожалению, стоматология сюда не входит, так что придется платить из своего кармана (насколько я знаю, можно получить частично возврат суммы превышающей 10тыс крон в год)
Но, допустим, страховку за границей, мой работодатель оплачивает.
2. Что там слышно про ужасы ювенальной юстиции? Типа, что маленьких детей, чуть что, отбирают у родителей и прочее. Слухи это или есть что-то?
Как по мне — слухи, я это только в ютубе по русским новостям видела. Во всяком случае, за три года я никого не встречала кто бы столкнулся с такой ситуацией или рассказывал бы мне, что у кого-то отобрали ребенка.
3. «каждому человеку дана возможность изменить свою жизнь, кто-то этим пользуется, а кто-то нет. » — этот лозунг был бы более к месту, если бы вы сами, из Одессы, нашли работу в Норвегии и переехали туда. А так, основную часть проблемы за вас все-таки решили ваши родители, а «остальное было делом техники». Хотя вы все равно молодец, конечно.
Да, возможно в этом контексте кричаще получилось (но это мой слоган по жизни). Я считаю, что всем дается огромное количество возможностей в жизни, но к сожалению мы их часто упускаем, возможно из-за страха, возможно из-за лени.
Но Вы так же попробуйте найти работу будучи в Норвегии ;).
Вообще, основной критерий — открываемость. Т.е. гугл начинает кидать почту в спам, если владельцы ящиков не читая выбрасывают письмо. Ну и всякие полезные мелочи, типа ссылки на отписку не только внизу в подписи, но и в специальном поле List-Unsubscribe (про этом тут на хабре уже был пост). Mail.ru популярен в России, а у него уже активно используется технология FBL: при нажатии на кнопку SPAM получаешь уведомление, что ленивый юзер вместо отписки нажал на кнопку. Соответственно, чтобы не рассылать нежелательную почту, то отслеживаешь такие уведомления и отменяешь подписку. Т.е. основные тезисы:
— Не слать абы кому, а сначала присылать подтверждающее письмо со ссылкой (чтобы явно видно было, что клиент подписался и подтвердил почту);
— Давать способы как можно более простой отписки (ссылки, которые ведут на сайт, на котором надо пройти авторизацию и самому найти выключатели подписки — гарант попадания в спам) по клику;
— Отслеживать боунсы (письма, сообщающие, что письмо не дошло и адреса такого нет и т.д.) и отписывать. Т.е. стараться по максимуму ловить такие уведомления и отписывать. Не слать тупо письма, половина которых пойдет на несуществующие адреса, половина уже давно у получателей в спаме;
— Ну и подписывания всякими ДКИМ и прочими плюхами, которые позволяют подтвердить, что почта действительно от этого сервера;
— Не слать всякое говно. Если ваша рассылка не является интересной, то ее будут удалять не открывая, а это значит низкая открываемость и попадание в спам;
Т.е. в основном не магические решения со значками в заголовках, а вполне понятные механизмы. А вообще, напишу я человеку, который уже на этом собаку съел, чтобы он пост написал. Может согласится.
Я тоже долгое время так думал. К сожалению, между академической тусовкой и реальной жизнью у зена такие проблемы, на фоне которого игры в паравиртуализацию уже не заметны.
Во-первых цитрикс, который очень очень виндовый и которого вполне устраивает продажа vdi'ев. xen server для них уже давно имиджевый проект, для которого продажа саппорта — лишь галочка при разводе энтерпрайз-клиентов. При формальном опенсорсе xenserver совершенно не libre software, так как весь governance намертво в зубах у цитрикса, а фичи они пилят большей частью под нужды десктопа.
У xenserver'а ужасный код за пределами самого зена. Я несколько раз показывал этот код, покажу ещё раз:
cmd = ["ls", path, "-1", "--color=never"]
try:
text = pread2(cmd).split('\n')
Такой индусный код у них всюду в sm'ах. А block devices — это святая святых виртуализации.
Далее, кто, кроме цитрикса там? Амазон. Много амазон своих наработок отдал? Я на 1000% уверен, что у них там свой тулстек и никому они его не отдадут. SUSE подпиливает, oracle ещё.
После того, как RH махнул рукой на зен, opensource'ной версии (production ready) де-факто не осталось.
Но главное — зен слишком сфокусирован на вопросах микроядра. Ведь (особенно, в свете миража и эквивалента от эрланга) зен просто выступает как микроядро, обеспечивая message passing (events) между доменами (процессами).
Как все микроядерные штуки оно хорошо в теории и отвратительно на практике. Например, xenbus, при кажущейся красоте — омерзительный протокол с кучей рейсов, ведущий к тому, что на хостах с xen'ом до сих пор более одного домена в один момент времени стартовать не может. У цитрикса в коде даже есть отдельный хак с sleep'ом, чтобы домены не смели слишком часто рестартовать.
То, что у зена до сих пор референсным является 2.6.18-xen — ещё тот показатель. pv_ops при формально заявленной поддержке всего и вся — второсортное ядро для зена (кривое управление памятью, плавающие таймеры и т.д.), а это означает, что зен не с линуксом, а сам по себе (что очень согласуется с идеей «микроядро»).
И эта ситуация тянется годами. За это время kvm из поделки для гиков стал очень крутой штукой, основой для RH, самым массовым гипервизором для openstack'а, в то же самое время цитрикс валандается c VDI'ем.
То есть зен стремительно теряет все свои преимущества. kvm уже давно работает со скоростями, сравнимыми с xen'ом (по сетевой и дисковой производительности превосходя оный за счёт отсутствия идиотских лимитов ring buffer'ов), а «родной для линукса» много значит в контексте продакт-деплоя.
Вы ж понимаете, что это громкие слова. По пунктам:
PayPal: переводят сайт на NodeJS с Java. Процессинг платежей так и остается на смеси Java и C++, и планов по миграции на что-то другое для этих задач нет. Цель миграции для сайта — иметь возможность быстро менять наполнение, проводить A/B тесты для конверсий и т.д. Т.е. сугубо маркетинговые задачи. С той же легкостью они могли мигрировать на Django или Rails — им просто нужен был инструмент, позволяющий работать с фаннелом в очень сжатые сроки. Ну и сами понимаете, сайт для них — это не узкое место в плане производительности.
Walmart и LinkedIn: Node.js используется как прокси для мобильных сервисов. Весь тяжелый процессинг так же остается на стороне Java. Поэтому неудивительно, что на Black Friday в волмарте Нод вел себя спокойно — он также не был узким местом.
Групону до перехода хватало производительности Рельсов. Тот факт, что Node.js им подошел, меня нисколько не удивляет. Кроме того, при переходе ребята сильно переработали архитектуру всего сервиса, и основной выигрыш в производительности поличили именно от этого, а не от скорости v8.
Trello — небольшой проект. Называть хайлоадом все, что смотрит в интернет, я бы не стал.
ql.io мертв уже больше года. Но даже когда он еще жил, он был «research»-проектом и никогда не процессил больших объемов данных. В инфраструктуре Ebay он не используется. Ближайший аналог — YQL — крутится на JVM+Rhino, и там нагрузки действительно колоссальные.
> Что для вас хайлоад? Сотня млн. запросов в день, норм? А несколько сотен?
Хайлоад не начинается с какой-то четкой границы. И не зависит только от запросов в секунду. Например, допустим, у нас есть сервис, в котором нет сетевых эффектов: у каждого пользователя свой набор данных и никто не запрашивает чужие данные: т.е. нет никакого обмена сообщениями, общих документов, одновременного редактирования и т.п. Один железный бокс в такой системе обслуживает 50 пользователей с комфортным запасом по производительности. У нас 5 миллионов пользователей, и для них мы подняли 100 тысяч таких боксов, пошардили данные и настроили лоад-балансер и автозамену падающих узлов. Если их станет в два раза больше, мы просто поднимем в 2 раза больше боксов, и за исключением выросших затрат на хостинг, к никаким другим последствиям это не приведет. Хайлоад ли это?
А вот если есть сетевые эффекты, то рост пользовательской базы в 2 раза может легко привести к тому, что какие-то части системы не смогут работать без значительной переработки. Вот именно такие «узкие места» в производительности в моем понимании — хайлоад. В Фейсбуке это рассылки уведомлений, сообщений, обновление новостных лент. А вот система загрузки фотографий явно скейлится линейно с ростом нагрузки, и хайлоадом при всем количестве железа может быть названа только с натяжкой.
Во всех вышеперечисленных примерах Node.js, хоть и является частью большой системы, но не оказывается узким местом в плане роста инфраструктуры, поэтому заслуги платформы в успехе данных проектов практически нет. На месте Node.js мог оказаться Питон, Руби, PHP или Perl, и ничего бы кардинально не поменялось.
И да, Нод я люблю и на нем работаю. В нашем проекте есть части на Node.JS, Erlang, Java, Python, и несмотря на миллионы пользователей и большую нагрузку, я не могу назвать части, написанные на NodeJS, хайлоадом. Узкие места сейчас для нас покрывают Erlang и Java — там хайлоад есть. Показательно, что именно из-за них мне приходится иногда просыпаться по ночам. Из-за Node.js я не просыпаюсь не потому, что он супер-надежный, а потому, что он не находится на критическом пути.
В этих компаниях та же ситуация, и я уверен, что пока Эран и его друзья смотрели на равные графики нодовских процесссов, ребятам из отделов бекенд-сервисов Волмарта пришлось изрядно попотеть.
Единственный хайлоад-проект на Ноде, о котором мне известно — это Voxer.
Холиварить только не будем :) так же подчеркну, мы еще не перенесли все на продакшн, продолжаем тестирование и проверки на косяки с боевой нагрузкой. А так же нам интересно использование дополнительных компонентов postgresql 9.3 (работа с json и hstore), плюс у нас большой интерес к postgis. Соответственно мы аккуратно подходим к переходу на postgresql в продакшн.
Я админ и немного программист, для меня приятно, что чем меньше точек отказа (точек администрирования), тем лучше.
Вот с чем мы столкнулись используя mysql (percona):
— master-slave: всегда требовал ручного вмешательства.
— master-master: тормоза, несколько раз разваливался так, что поднимались из бекапов на новом серваке
— учитывая наследственность БД (на начальном этапе разработки были ручные вставки, было много myisam) целостность данных постоянно под вопросом. На начальных этапах приведения в порядок базы у меня была постоянная борьба с NOT NULL
— периодически обновления движка БД вскрывают несовместимость опций конфига или изменения в них
— обилие движков иногда побуждает программистов делать за счет них костыли
— ограничение в фичах побудило плотно использовать mongo, что в общем-то можно закрыть за счет postgresql
Вот почему нам интересен postgresql:
— стабильная работа master-slave
— pgpool (да и слона можно заточить :)
— работа с json (позволит отказаться от mongo)
— hstore: тут очень интересна скорость работы (в нашем случае так же может позволить сократить или отказаться от парочки костылей)
— единый формат хранилища, не нужно мучится с движками, также я не припомню, что бы конфиг сильно менялся
— возможность писать дополнения на разных языках
— postgis
— при увеличении нагрузки на БД (те же новые фичи будем использовать) планировщик запросов PG окажется в большом выигрыше по сравнения с оптимизатором мускуля
И дополнительно на других моих проектах:
— адекватная работа с объемами данных больше 500 Гб (возможно мои кривые руки, но у меня не было ни одно счастливой БД на мускуле больше 5 Гб). Один раз я дожил на БД для заббикс объемов в 450ГБ, после чего перешли на postgresql и там сейчас база ~>1,2 Тб и отлично живет без шардинга. (собственно pg и попробовали вместо шардинга на мускуле)
— адекватная работа с большим количеством клиентов (опять же, возможно мои кривые руки, но у меня есть PG база, которая нормально живет при 2500 клиентов 1С на ней, а 1с очень неаккуратен с соединениями, а был мускуль, который на 500 коннектах слал всех нах)
Почему нету? Есть, просто почему-то не все про них умудряются прочитать в документации.
Нужно подключить сорцовый репозиторий и собирать с какими угодно опциями:
У нас тут даже свой emerge world apt-build world есть (:
А про необязательные зависимости: в aptitude по умолчанию включена опция «Устанавливать рекомендуемые пакеты». Если её отключить, то в системе окажется гораздо меньше неиспользуемых пакетов.
Блин) Забыл упомянуть одну из главных фич, до которой руки не добрались.
Когда потом делаешь анализ не всегда ясно отчего «курс акций» пошел вверх или вниз. У меня была идея, когда есть еще интерфейс, по типу дневника, в который заносятся все события, которые относятся к SEO. Они привязываются к дате внесения изменения и потом наносятся на график или просто выгружаются/отображаются.
Таким образом будет легче проконтролировать свои вмешательства в сайт.
НУ как пример — красная пунктирная линия на графике «курса» выдачи в поисковой ситеме. На линии указано к примеру «Произведено то-то и то...» Ну это, так… К примеру о реализации. Но вещь очень полезная получится.
Анонимайзеры разные бывают, например с tor и i2p вполне удобно работать.
Капчи в лоб — пустая трата денег. Если нужно долго и много, то нужно умнее делать. Например гугл очень любит, когда ему статистику «пользователя отдают» и зареганному пользователю гораздо реже капчу выпадает. Если на практике, то полезно под каждую проксю сделать и хранить отдельную куку, юзерагента, можно акк зарегать.
Парнеры qip, tut.by, livejournal.ru. Объемы можно любые, но опять-же по умного нужно делать, а не в лоб.
Отвечу ссылкой: www.mfisoft.ru/products/sorm/sorm2/sormovich, так что подробнее рассказывать не буду.
При использовании предпочтение отдается не свежим версиям, а испытанным ибо очень жесотоки требования 24/7 и работа системы в автономнейшем режиме, ибо она физически не имеет выходов в сеть. А даунтайм затрудним.
Как минимум стоило написать жалобу в деньги(@)mail.ru, а лучше еще и в милицию/полицию.
То что не упакован не удивительно (легче обойти эвристики антивируса на начальном этапе пока в базы не попал). А вот с ключами конечно не на уровне, достаточно было шифровать каждый файл случайным ключом, а сам ключ приписывать в конце зашифрованный публичным ключом.
Я за статью поставил плюс, но, по-моему, от таких статей больше вреда чем пользы.
Знаете, есть такая японская концепция — Сюхари. Грубо говоря, это принцип обучения: «строго соблюдай правила (процессы)» — «адаптируй правила (процессы)» — «избавься от всех правил (процессов)».
Вы тут пишете про то, как сами перешли на третью стадию. А многие команды и разработчики даже и в первой стадии не находятся. Но, конечно, теперь им будет легче обосновать, почему надо забить на процессы и кодить как попало, без итераций, планирования, ретро и прочей «ненужной мишуры».
Учитывая размер ботнета зашедшего «на огонек» к Habrahabr.
А так-же интенсивность запров: на графике любой отброшенный SYN пакет пришедший с ip принадлежащего к ботнету можно классифицировать как неудавшийся запрос.
В такой ситуации перспективы использования предлагаемой конструкции на php/mysql выглядят весьма прохладными.
А наивность авторов вызывает широченную улыбку.
Ну и следующий вопрос — а зачем так сложно, если схожих результатов можно добиться просто используя nginx с набором локаций, директивой limit_req и shell script? Без php/mysql/блэкджека/этихсамых?
Автор молодец, что следит за сайтами клиентов и ищет правду в таких «скриптах».
Недавно сам столкнулся с такой проблемой и искал вариант «декондига» таких подарков и остановился примерно на следующем варианте:
В Норвегии, мед.страховки как таковой нет. Каждый житель Норвегии имеет право на «бесплатную» медицину. Допустим серьезные операции, роды и т.п. проводятся совершенно бесплатно. По менее серьезным вопросам, если не обращаться в частные клиники, а идти к своему терапевту, который дает направления к специалистам, то все что переваливает за 2тыс. крон в год, оплачивает государство. Но, к сожалению, стоматология сюда не входит, так что придется платить из своего кармана (насколько я знаю, можно получить частично возврат суммы превышающей 10тыс крон в год)
Но, допустим, страховку за границей, мой работодатель оплачивает.
Как по мне — слухи, я это только в ютубе по русским новостям видела. Во всяком случае, за три года я никого не встречала кто бы столкнулся с такой ситуацией или рассказывал бы мне, что у кого-то отобрали ребенка.
Да, возможно в этом контексте кричаще получилось (но это мой слоган по жизни). Я считаю, что всем дается огромное количество возможностей в жизни, но к сожалению мы их часто упускаем, возможно из-за страха, возможно из-за лени.
Но Вы так же попробуйте найти работу будучи в Норвегии ;).
vpsboard.com/
lowendstock.com/
list.lowendserv.net/
www.frugalboxes.com/vps
vpsrecord.com/offers/
sip_caller.sh <recipient> <path-to-audio-file>иsip_sendim.sh <recipient> <message>.— Не слать абы кому, а сначала присылать подтверждающее письмо со ссылкой (чтобы явно видно было, что клиент подписался и подтвердил почту);
— Давать способы как можно более простой отписки (ссылки, которые ведут на сайт, на котором надо пройти авторизацию и самому найти выключатели подписки — гарант попадания в спам) по клику;
— Отслеживать боунсы (письма, сообщающие, что письмо не дошло и адреса такого нет и т.д.) и отписывать. Т.е. стараться по максимуму ловить такие уведомления и отписывать. Не слать тупо письма, половина которых пойдет на несуществующие адреса, половина уже давно у получателей в спаме;
— Ну и подписывания всякими ДКИМ и прочими плюхами, которые позволяют подтвердить, что почта действительно от этого сервера;
— Не слать всякое говно. Если ваша рассылка не является интересной, то ее будут удалять не открывая, а это значит низкая открываемость и попадание в спам;
Т.е. в основном не магические решения со значками в заголовках, а вполне понятные механизмы. А вообще, напишу я человеку, который уже на этом собаку съел, чтобы он пост написал. Может согласится.
Во-первых цитрикс, который очень очень виндовый и которого вполне устраивает продажа vdi'ев. xen server для них уже давно имиджевый проект, для которого продажа саппорта — лишь галочка при разводе энтерпрайз-клиентов. При формальном опенсорсе xenserver совершенно не libre software, так как весь governance намертво в зубах у цитрикса, а фичи они пилят большей частью под нужды десктопа.
У xenserver'а ужасный код за пределами самого зена. Я несколько раз показывал этот код, покажу ещё раз:
github.com/xapi-project/sm/blob/6e37a85ef88b97c84c6177eccc652e3528bf9b59/tests/faultinjection/util.py
cmd = ["ls", path, "-1", "--color=never"] try: text = pread2(cmd).split('\n')Такой индусный код у них всюду в sm'ах. А block devices — это святая святых виртуализации.
Далее, кто, кроме цитрикса там? Амазон. Много амазон своих наработок отдал? Я на 1000% уверен, что у них там свой тулстек и никому они его не отдадут. SUSE подпиливает, oracle ещё.
После того, как RH махнул рукой на зен, opensource'ной версии (production ready) де-факто не осталось.
Но главное — зен слишком сфокусирован на вопросах микроядра. Ведь (особенно, в свете миража и эквивалента от эрланга) зен просто выступает как микроядро, обеспечивая message passing (events) между доменами (процессами).
Как все микроядерные штуки оно хорошо в теории и отвратительно на практике. Например, xenbus, при кажущейся красоте — омерзительный протокол с кучей рейсов, ведущий к тому, что на хостах с xen'ом до сих пор более одного домена в один момент времени стартовать не может. У цитрикса в коде даже есть отдельный хак с sleep'ом, чтобы домены не смели слишком часто рестартовать.
То, что у зена до сих пор референсным является 2.6.18-xen — ещё тот показатель. pv_ops при формально заявленной поддержке всего и вся — второсортное ядро для зена (кривое управление памятью, плавающие таймеры и т.д.), а это означает, что зен не с линуксом, а сам по себе (что очень согласуется с идеей «микроядро»).
И эта ситуация тянется годами. За это время kvm из поделки для гиков стал очень крутой штукой, основой для RH, самым массовым гипервизором для openstack'а, в то же самое время цитрикс валандается c VDI'ем.
То есть зен стремительно теряет все свои преимущества. kvm уже давно работает со скоростями, сравнимыми с xen'ом (по сетевой и дисковой производительности превосходя оный за счёт отсутствия идиотских лимитов ring buffer'ов), а «родной для линукса» много значит в контексте продакт-деплоя.
PayPal: переводят сайт на NodeJS с Java. Процессинг платежей так и остается на смеси Java и C++, и планов по миграции на что-то другое для этих задач нет. Цель миграции для сайта — иметь возможность быстро менять наполнение, проводить A/B тесты для конверсий и т.д. Т.е. сугубо маркетинговые задачи. С той же легкостью они могли мигрировать на Django или Rails — им просто нужен был инструмент, позволяющий работать с фаннелом в очень сжатые сроки. Ну и сами понимаете, сайт для них — это не узкое место в плане производительности.
Walmart и LinkedIn: Node.js используется как прокси для мобильных сервисов. Весь тяжелый процессинг так же остается на стороне Java. Поэтому неудивительно, что на Black Friday в волмарте Нод вел себя спокойно — он также не был узким местом.
Групону до перехода хватало производительности Рельсов. Тот факт, что Node.js им подошел, меня нисколько не удивляет. Кроме того, при переходе ребята сильно переработали архитектуру всего сервиса, и основной выигрыш в производительности поличили именно от этого, а не от скорости v8.
Trello — небольшой проект. Называть хайлоадом все, что смотрит в интернет, я бы не стал.
ql.io мертв уже больше года. Но даже когда он еще жил, он был «research»-проектом и никогда не процессил больших объемов данных. В инфраструктуре Ebay он не используется. Ближайший аналог — YQL — крутится на JVM+Rhino, и там нагрузки действительно колоссальные.
> Что для вас хайлоад? Сотня млн. запросов в день, норм? А несколько сотен?
Хайлоад не начинается с какой-то четкой границы. И не зависит только от запросов в секунду. Например, допустим, у нас есть сервис, в котором нет сетевых эффектов: у каждого пользователя свой набор данных и никто не запрашивает чужие данные: т.е. нет никакого обмена сообщениями, общих документов, одновременного редактирования и т.п. Один железный бокс в такой системе обслуживает 50 пользователей с комфортным запасом по производительности. У нас 5 миллионов пользователей, и для них мы подняли 100 тысяч таких боксов, пошардили данные и настроили лоад-балансер и автозамену падающих узлов. Если их станет в два раза больше, мы просто поднимем в 2 раза больше боксов, и за исключением выросших затрат на хостинг, к никаким другим последствиям это не приведет. Хайлоад ли это?
А вот если есть сетевые эффекты, то рост пользовательской базы в 2 раза может легко привести к тому, что какие-то части системы не смогут работать без значительной переработки. Вот именно такие «узкие места» в производительности в моем понимании — хайлоад. В Фейсбуке это рассылки уведомлений, сообщений, обновление новостных лент. А вот система загрузки фотографий явно скейлится линейно с ростом нагрузки, и хайлоадом при всем количестве железа может быть названа только с натяжкой.
Во всех вышеперечисленных примерах Node.js, хоть и является частью большой системы, но не оказывается узким местом в плане роста инфраструктуры, поэтому заслуги платформы в успехе данных проектов практически нет. На месте Node.js мог оказаться Питон, Руби, PHP или Perl, и ничего бы кардинально не поменялось.
И да, Нод я люблю и на нем работаю. В нашем проекте есть части на Node.JS, Erlang, Java, Python, и несмотря на миллионы пользователей и большую нагрузку, я не могу назвать части, написанные на NodeJS, хайлоадом. Узкие места сейчас для нас покрывают Erlang и Java — там хайлоад есть. Показательно, что именно из-за них мне приходится иногда просыпаться по ночам. Из-за Node.js я не просыпаюсь не потому, что он супер-надежный, а потому, что он не находится на критическом пути.
В этих компаниях та же ситуация, и я уверен, что пока Эран и его друзья смотрели на равные графики нодовских процесссов, ребятам из отделов бекенд-сервисов Волмарта пришлось изрядно попотеть.
Единственный хайлоад-проект на Ноде, о котором мне известно — это Voxer.
Я админ и немного программист, для меня приятно, что чем меньше точек отказа (точек администрирования), тем лучше.
Вот с чем мы столкнулись используя mysql (percona):
— master-slave: всегда требовал ручного вмешательства.
— master-master: тормоза, несколько раз разваливался так, что поднимались из бекапов на новом серваке
— учитывая наследственность БД (на начальном этапе разработки были ручные вставки, было много myisam) целостность данных постоянно под вопросом. На начальных этапах приведения в порядок базы у меня была постоянная борьба с NOT NULL
— периодически обновления движка БД вскрывают несовместимость опций конфига или изменения в них
— обилие движков иногда побуждает программистов делать за счет них костыли
— ограничение в фичах побудило плотно использовать mongo, что в общем-то можно закрыть за счет postgresql
Вот почему нам интересен postgresql:
— стабильная работа master-slave
— pgpool (да и слона можно заточить :)
— работа с json (позволит отказаться от mongo)
— hstore: тут очень интересна скорость работы (в нашем случае так же может позволить сократить или отказаться от парочки костылей)
— единый формат хранилища, не нужно мучится с движками, также я не припомню, что бы конфиг сильно менялся
— возможность писать дополнения на разных языках
— postgis
— при увеличении нагрузки на БД (те же новые фичи будем использовать) планировщик запросов PG окажется в большом выигрыше по сравнения с оптимизатором мускуля
И дополнительно на других моих проектах:
— адекватная работа с объемами данных больше 500 Гб (возможно мои кривые руки, но у меня не было ни одно счастливой БД на мускуле больше 5 Гб). Один раз я дожил на БД для заббикс объемов в 450ГБ, после чего перешли на postgresql и там сейчас база ~>1,2 Тб и отлично живет без шардинга. (собственно pg и попробовали вместо шардинга на мускуле)
— адекватная работа с большим количеством клиентов (опять же, возможно мои кривые руки, но у меня есть PG база, которая нормально живет при 2500 клиентов 1С на ней, а 1с очень неаккуратен с соединениями, а был мускуль, который на 500 коннектах слал всех нах)
Нужно подключить сорцовый репозиторий и собирать с какими угодно опциями:
У нас тут даже свой
emerge worldapt-build world есть (:А про необязательные зависимости: в aptitude по умолчанию включена опция «Устанавливать рекомендуемые пакеты». Если её отключить, то в системе окажется гораздо меньше неиспользуемых пакетов.
Когда потом делаешь анализ не всегда ясно отчего «курс акций» пошел вверх или вниз. У меня была идея, когда есть еще интерфейс, по типу дневника, в который заносятся все события, которые относятся к SEO. Они привязываются к дате внесения изменения и потом наносятся на график или просто выгружаются/отображаются.
Таким образом будет легче проконтролировать свои вмешательства в сайт.
НУ как пример — красная пунктирная линия на графике «курса» выдачи в поисковой ситеме. На линии указано к примеру «Произведено то-то и то...» Ну это, так… К примеру о реализации. Но вещь очень полезная получится.
Капчи в лоб — пустая трата денег. Если нужно долго и много, то нужно умнее делать. Например гугл очень любит, когда ему статистику «пользователя отдают» и зареганному пользователю гораздо реже капчу выпадает. Если на практике, то полезно под каждую проксю сделать и хранить отдельную куку, юзерагента, можно акк зарегать.
Парнеры qip, tut.by, livejournal.ru. Объемы можно любые, но опять-же по умного нужно делать, а не в лоб.
Прокси очень хороший способ, но не единственный.
При использовании предпочтение отдается не свежим версиям, а испытанным ибо очень жесотоки требования 24/7 и работа системы в автономнейшем режиме, ибо она физически не имеет выходов в сеть. А даунтайм затрудним.
То что не упакован не удивительно (легче обойти эвристики антивируса на начальном этапе пока в базы не попал). А вот с ключами конечно не на уровне, достаточно было шифровать каждый файл случайным ключом, а сам ключ приписывать в конце зашифрованный публичным ключом.
Знаете, есть такая японская концепция — Сюхари. Грубо говоря, это принцип обучения: «строго соблюдай правила (процессы)» — «адаптируй правила (процессы)» — «избавься от всех правил (процессов)».
Вы тут пишете про то, как сами перешли на третью стадию. А многие команды и разработчики даже и в первой стадии не находятся. Но, конечно, теперь им будет легче обосновать, почему надо забить на процессы и кодить как попало, без итераций, планирования, ретро и прочей «ненужной мишуры».
Учитывая размер ботнета зашедшего «на огонек» к Habrahabr.
А так-же интенсивность запров: на графике любой отброшенный SYN пакет пришедший с ip принадлежащего к ботнету можно классифицировать как неудавшийся запрос.
В такой ситуации перспективы использования предлагаемой конструкции на php/mysql выглядят весьма прохладными.
А наивность авторов вызывает широченную улыбку.
Ну и следующий вопрос — а зачем так сложно, если схожих результатов можно добиться просто используя nginx с набором локаций, директивой limit_req и shell script? Без php/mysql/блэкджека/этихсамых?
Недавно сам столкнулся с такой проблемой и искал вариант «декондига» таких подарков и остановился примерно на следующем варианте: