NiTr0

Юзать UniATA драйвер, либо для смены драйвера АТА - acronis universal restore либо ручками http://support.microsoft.com/kb/314082 либо заюзать батник fix_hdc

А в классической механике до начала 20 века никто и не заикался, что скорости могут суммироваться нелинейно, что время может течь по-разному для неподвижого и движущегося объекта и т.п. Следуя вашей логике, классическую механику "опровергли" и "разгромили", вот только почему-то ее уравнения продолжают использовать. Имеет, и прямое. Ибо является вырожденным случаем при v<<c, когда релятивистскими эффектами можно пренебречь. То же будет и с СТО/ОТО - ее дополнят/расширят, и она станет частным случаем более общей теории.

Ровно с таким же успехом, с каким "опровергнута" классическая (ньютоновская) механика СТО или квантовой механикой. То, что при околосветовых скоростях ньютоновские уравнения совершенно неприменимы, никоим образом не мешает использовать их в повседневной жизни. Внезапно, не правда ли?

не факт - монотуб на 24 жилы к примеру малопригоден для юзания на длинных трассах, в то время как 8-12 жил - прекрсно живет.

А если юзать реакторы на быстрых нейтронах, на уране-238 - то ресурсов для них гораааздо больше...

Угу, угу. Выход замыкаем на вход - случается чудо, вечный двигатель без каких-либо притоков энергии работает, выделяет энергию еще и помещение греет Уверены, что работает - купите, поставьте в запертой кладовке с видеофиксацией как Учумелые ручки предлагал, через год - просто так получите $10000. А вечный двигатель продадите кому-то из страждущих, готовых вкинуть не один килобакс в питание БС там, где нет ни 220, ни дорог для подвоза топлива, ни населения для обслуживания генератора...

Факты, факты. Пока что это - голословные заявления. Куча различных дистрибутивов (в т.ч. и бздя), гора различных версий библиотек в одной системе, и стремные костыли чтобы это все не рассыпалось, в виде уникальной копии библиотеки для каждого приложения, эдакая псевдо-статическая линковка, сводящая на нет все прелести динамических библиотек... Не зоопарк? Пробовал мейнтейнить, пробовал. Ничего сложного. Времени практически не занимает. И да, "система с зависимостями вообще" - собссно для того и придумывалась, чтобы один апдейт не ломал все сразу, и чтобы админ не плясал с бубном, дотсавляя наугад библиотеки, нужные для запуска софта. И да, вы что, держите исключительно свой софт?

Несколько NS/MX - вполне пару сотен байт дадут минимум... Запрос - 40 байт. Итого - минимум 5-кратная амплификация; негусто, но и не мало. Бот на 100мбит канале генерит 500+мбит траффика..

Угу, угу. Одна "команда" интерпретируемого языка равна нескольким сотням команд компилируемого (в лучшем случае). Уверены? Я - нет. А если конфиги разные на разных серверах - что тогда? Для каждого сервера тянуть свой недо-пакет с конфигом? Хранить их все в одной большой куче на одном сервере? Нет, это я вам открою секрет. В дистрах бекпортированием патчей на неподдерживаемые разработчиком ветки занимаются мэйнтэйнеры дистра. И именно благодаря этому можно ровно сидеть на одной и той же ветке софта все 5-7 лет, не испытывая адской попаболи от мажорного апдейта горки серверов, выливающейся в тщательное тестирование работоспособности каждого уникального конфига с новой версией софта перед накаткой на боевой сервер. И не испытывая попаболи от того, что в неподдерживаемой ветке обнаружили дыру. А нафига вообще мажорные апдейты-то? Ну кроме отдельных очень редких случаев активно развивающихся проектов? Не бредтина, а вполне здравое стремление к однообразию в софте. Вас же тянет почему-то на дикий зоопарк, при этом - без какого-либо рационального объяснения сего факта. Зоопарк ради зоопарка. Поверх которого слеплена своя корявая личная система пакетов. На обслуживание которой, уверен, тратится гора времени. Открою вам еще один огромный секрет: в рамках одной ветки софт не удаляется. Вообще. На протяжении всей ее поддержки. А в новой версии дистра - ну и пускай удаляют. Будет повод перейти на оптимизированный форк (mariadb или percona). А кто говорит исключительно о рекурсии?

А кто сказал, что атака - на вашу сеть?

Эта принципиальность следует из осознания того факта, что дыра может быть в любом демоне. И чем меньше сервисов торчит в мир - тем выше безопасность. Не? Есть сервисы, которые должны быть доступны извне. Есть - которые не должны. Нафиг их все в мир высовывать? Чего-чего? Демон на интерпретируемом языке? И сколько кппс его скукожат? Любой пакет. Не обязательно огромный. Ответ 200-300 байт (хоть ANY) на 64 байт - уже неплохая амплификация. Даже если NS на сотню байт - тоже неплохо. Имеете. Один пакет тянет скажем 1.0.4 библиотеку, другой - 1.0.7, третий сборанный 3 года назад - 0.9.5 еще пользует, в итоге работа превращается в русскую рулетку или в слежение за всеми библиотеками. И каждая из библиотек висит в памяти и жрет ее. Накатка обновлений, соответственно, тоже превращается в печаль. Есть у вас машина. Работает на ней сервис, эксим допустим. Тюните вы ему конфиг по мере изменения характера спама. Работает год, другой, накатываете на него минорные апдейты. Как в вашем видении это должно происходить? Далее, окончилась поддержка вашей ветки - что вы будете делать? Накатывать мажорный апдейт, плясать с бубном вокруг сменившихся конфигов, ловить баги из-за особенностей? И да, вы для каждого пакета мониторите багтрек для оперативного обновления с целью закрытия 0-day уязвимостей? Тем что можно деплоить все или любые сервисы на все или на любой сервер сразу "по нажатию кнопки", и что каждый сервис изолирован вместе со всеми зависимостями, и не привязан к дистру и соответственно не нужно следовать ограничениям пакетной системы, что очень сильно все упрощает и экономит время. А смысл в изоляции зависимостей? Смысл в отвязке от дистра, если не разводить зоопарк дисторов? Не проще репозиторий свой оформить? Опять же - установить все из пакетов можно, дав одну-единственную команду. Для дебиана - apt-get install <список пакетов>, для RHEL/клонов - yum install <список пакетов>. Все. Максимум - конфиги поправить (или скопировать преднастроенные). Наоборот - с пакетами гораздо легче обслуживать большой парк машин. Особенно с большим кол-вом сервисов. Особенно - если задача стоит в обслуживании, а не разворачивании и бросании насамотек инсталляций.

Я говорил о разграничении доступа к прочим сервисам. Которые в мир торчать не должны принципиально, а должны быть доступны лишь с некоторых подсетей. Да хоть консоль квагги/бёрда/что там еще для маршрутизации юзается. И да, я к примеру у себя вообще апач нах выпиливаю поэтапно, переводя новые инсталляции на nginx+php-fpm/perl-fpm/прочие fastcgi. Несколько возросшая сложость настройки с лихвой компенсируется производительностью и меньшей ресурсоемкостью. Не нужен? Вы уверены, что в нем нет remote code execution дыр? Вы тщательно изучали код его, прогоняли через особый набор юнит-тестов на предмет обработки некорректных данных пакета? Или таки нет? С чего вы взяли, что его нельзя использовать для амплификатора? Он что, не будет отвечать на запросы с фейковых ип? А кто его тогда поднимет, кроме единственного и незаменимого вас? А если вы в больницу в это время попали на неделю - чо, по выписке сливать воду и закрывать бизнес? Итого - имеем зоопарк версий библиотек, которые жрут память, плавающие от сервиса к сервису дыры (или вы помните, какой версии в каком сервисе та же libpng к примеру, или pam?), и огромные проблемы с обновлением. Сколько времени обновление одного сервера до актуальных версий занимает? Не просто накатка бинарников, а анализ конфигов? И чем ваше решение принципиально лучше банального apt-get install ..... (если надо - со своим репозиторием модифицированных пакетов) ?

Чего-чего? И чо, buffer overflow exploit'ы без файрвола зарежете? Ах да, труЪ админы до таких мелочей не опускаются, у них весь софт по дефолту - без уязвимостей, и доступ к серверу только брутом ssh можно получить... И других серверов БД тоже? Открою огромный секрет: dns amplification подвержен любой днс сервер, открытый в мир. А закрыть сервер в мир прову, у которого свое доменное имя - бред редкостный... А вот ограничить флуд, лимитировав кол-во пакетов в секунду - легко. А нехрен зоопарк осей разводить, чтобы потом в ядрах путаться. Бздя, по большому счету, юзается только из религиозных соображений. Ибо в стагнации уже хрензнает сколько лет.И нехрен разводить зоопарк методов ограничения доступа, чтобы никто кроме вас не смог в этих кишках разобраться? Чо, и упавший сервер святым духом поднимается, и софт новый по мановению руки накатывается, и апдейты сами по себе ставятся? Кого-кого деплоить?Вы что, из сырцов все собираете? Помойка нравится - слаку ставьте, ощутите все прелести. Ну или генту, сравните ее обслуживание с обслуживанием того же дебиана/рхел по затратам времени, прослезитесь. Кстати, сколько времени при вашем подходе занимает апдейт библиотек на мажорные версии, из-за чего рассыпается половина системы? Или вы секьюрити патчи бэкпортируете, как мэйнтейнеры дебиана/редхэта? Или просто забиваете на апдейты? О рассыпании серверов из-за сменившейся структуры конфигов сервиса - помолчу.

Ну расскажите мне, зачем файрвол на машинах. Это админская чушь "по феншую" уже поднадоела, почему нельзя головой подумать? Вот если нет реальной надобности держать файрвол, зачем держать файрвол? Например, где конкретно нет надобности разграничить доступ к сервисам на "доверенные"/"локалка"/"мир"? Вы мускул открытым портом в мир высовываете? На PPTP (юзаемый, к прмеру, для доступа извне в сеть) не ставите лимит на коннекты дабы не зафлудили его? На DNS не режете rate запросов, давая тем самым пищу ддосу через dns amplification? И накой при наличии файрвола в ядре городить костыли в юзерленде в виде tcpwrappers, который с одними сервисами работает, с другими - не работает, с третьими - работает только если собрать с нужным флагом? Что вами руководит - тяга к зоопаркам, как и в случае дистров? Единственный и незаменимый мегоодмин, привязанный 24 часа в сутки 7 дней в неделю к местонахождению сети (ибо если крякнется что-то - никто, кроме него, не осилит сеть поднять)? И да, судя по вашему зоопарку - вы таки и понаделали...

Машины без файрвола вообще? Оригинально-с... И да, админа, разводящего зоопарк разных дистров и тем более разных осей без крайней на то нужды (а ее собссно и нет в большинстве случаев - бздя по большей части ставится исходя из привычки, а не реальной необходимости в каком-либо специфичном функционале) и так ждет ужас. Вернее, его преемника, который будет весь этот зоопарк причесывать и риводить к единообразному виду.

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

Строго говоря - гадость может сидеть уже даже в биосе Прецеденты "бирусов" уже есть.

ну сравните. абиллс - бесплатен, нодени - 500$. далее, коммерческая версия - идет цена с установкой одного сервера биллинга/бд и одного браса, нодени - as-is (не осилил установку - ССЗБ). по функционалу абиллс тоже вроде как поинтереснее будет. хотя да, те же карты в нодени сделаны на первый взгляд весьма годно (в отличие от абиллса), вот только бы не привязка к яндекскартам - openlayers же есть, и подложки хоть с openstreetmap, хоть с других карт...

Адептам PPTP - задачка: сколько пптп туннель выжмет мбит на каком-то 2-головом пеньке по 2ггц на голову? Учитывая, что в виндах пптп крутится в юзерленде, в отличие от л2тп/пппое? О л2тп - это отдельная, печальная песня для владельцев роутеров...

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

Отличия от фри собссно расписаны. + доступ к обновлениям (автор вроде как обновления фри версии теперь пореже выкладывает). + основное за что платятся деньги - настройка и поддержка + полная документация.

Слепить свой ебилд с патчами никто не помешает. Если сильно уж надо...

Поможет, почти все ключики вынесены в use-флаги.

В принципе много времени доработка не занимает. Сколько за них хотите?

Больше сечение - меньше просадка напряжения, меньше потери, дольше работает. Ток заряда - менее ампера.