Перейти до

ttttt

Сitizens
  • Всього повідомлень

    2 081
  • Приєднався

  • Останній візит

  • Дней в лидерах

    14

Все, що було написано ttttt

  1. ttttt

    Бестопливный генератор.

    Почему будущее за термоядерными? Пока никому не удалось построить реактор, который выделяет больше энергии, чем потребляет, если речь о fusion. Зато месторождений урана уже на пару тысяч лет вперед есть.
  2. ttttt

    Бестопливный генератор.

    SMir, вы называете догмой теории, подтвержденные реальными экспериментами и наблюдениями. Вы или не понимаете слово догма или недостаточно познали топик, о котором рассуждаете. Вся суть науки в том, чтобы не воспринимать ничего на веру - т.е. как раз полная противоположность догмы. А вы сами только одними догмами и говорите: зачем-то пытаетесь протолкнуть какую-то ничем не подтвержденную чушь сюда и хотите, чтобы вам поверили. Кому такое понравится?
  3. ttttt

    Бестопливный генератор.

    ну для зарадки разных девайсов хватит, вот их поновее видео уже с реальными продуктами: http://bcove.me/xolv5bxk
  4. ttttt

    Бестопливный генератор.

    ted talk с демо такого девайса, ничего катастрофичного: http://www.ted.com/talks/eric_giler_demos_wireless_electricity.html
  5. ttttt

    Бестопливный генератор.

    Это был J. P. Morgan и ни о каком заборе "энергии эфира" речь не шла, только о передаче без проводов. https://en.wikipedia.org/wiki/Wardenclyffe_Tower
  6. ttttt

    Бестопливный генератор.

  7. ttttt

    Хелп! Ломанули сервер!

    Причем тут tcp wrappers? Почитайте о чем речь вообще. Если важна производительность - никто не будет перечитывать hosts.allow каждый раз, а будет стараться сделать все в своих силах, чтобы производительносьт была максимальная, т.е. будет что-то типа хэш таблицы с разрешенными адресами, может быть даже с маленьким блум фильтром, чтобы он весь в одну cache line влез и отказ был за одно обращение к L3. А если не важна производительность, то зачем вообще рассуждать о производительности? Я не вижу здесь аргументов, вижу только камень в огород PL research. Кому-то что-то модно, кому-то позорно, да уж. Не позорьтесь. И что? У них есть проблема - arm дико медленные и нужно очень сильно экономить ресурсы, чтобы юзеры комфортно себя чувтсовали на таких системах и пока ее можно решить только нативными приложениями. В тоже время в других местах не так, например гугл продолжает пилить JIT в v8, а все попытки нативных приложений в браузере ни к чему не привели. Надоели уже ваши глупости. Managed языки - это что вообще, языки на vm'ах microsoft'а? Какое отношение они имеют к интерпретаторам? Причем тут вообще microsoft, их чудо-софт и их отношение к чему-то?
  8. ttttt

    Хелп! Ломанули сервер!

    Ой, факты, возьмите любой пример TCP сервера, скомпилируйте и померяйте. accept() в обычном режиме будет делать аж 2 переключения контекста, в ядро и обратно, это хз сколько, 10к циклов или больше, а доступ к L3 кэшу два раза и вычисление хэша из 32-битного айпишника - до 100 циклов, вот вам и в 100 раз разница. В самом лучшем случае интерпретатор с JIT быстрее, чем компилируемый язык (AOT), потому что может оптимизировать машинный код на лету, зная как он исполняется и речь вообще не об этом. Какой зоопарк, сколько можно уже? У меня как раз однообразнее и проще, чем зоопарки любой пакетной системы. И когда-то это все было в бинарных пакетах и занимало просто немеряно времени, сейчас вообще времени не занимает, потому что выкинули бинарные пакеты. Какое тут вообще может быть объяснение. И проблема даже не в самих пакетах, а в системе с зависимостями вообще. Мне нужно свой софт держать, а вы рассуждаете с точки зрения использования только того, что вам предлагают в пакетах и небось мейнтенить какой-то пакет даже не пробовали.
  9. ttttt

    Хелп! Ломанули сервер!

    Что я зря заявил? Какие доказательства, конкретнее.
  10. ttttt

    Хелп! Ломанули сервер!

    Причем тут интерпретируемые языки? На пальцах: системный вызов, типа accept() жрет в 50-100 раз больше ресурсов, чем пару команд проверки доступа - на любом языке. Но за ним еще один - close(). Они и будут узким местом, а не проверка доступа и не язык. Ну скажем так, за 5x никто париться не будет, в среднем с большого списка серверов будет даже ниже, а открытые рекурсивные позволяют получить ответ 70x. Ну поправили конфиг в скрипте и передеплоили без сборки, всего-то делов. Надо апдейты - подтянули новый исходник, передеплоили с пересборкой. Причем это все будет одинаково хоть для одной машины, хоть для десятка. Я вам открою секрет, для кучи софта во всех репозиториях всех дистров уже давным давно закончилась поддержка, а у части она заканчивается еще до того, как его успевают добавить в релиз и особенно этим страдает дебиан. Но вы же ничего не делаете. А вот я могу обновить, если надо. А если конфиг несовместимый, то придется править, но и вам тоже, когда вы обновитесь, если вообще обновитесь, дебиан же Чтобы зависимости не задевали все сервисы, если в них что-то случилось или другие сервисы еще не готовы к новому API. Чтобы можно было использовать разные дистры, и что за бредятина про привязку к одному дистру? Завтра ребята из дебиана решат, что ну его нафиг, будем делать новый дистр и новую систему пакетов и вы останетесь ни с чем, ну или решат удалить какой-то софт, или перестанут обновлять или не обновят вовремя - и у вас будут проблемы. MySQL еще не удалили? Интересно будет посмотрить на реакцию админов, когда MySQL удалят, некоторые дистры уже поудаляли. А репозиторий свой оформить (даже для одной системы пакетов) совсем не проще, чем создать свою систему, независимую от дистра. А раз не проще, то зачем?
  11. ttttt

    Хелп! Ломанули сервер!

    Это принципиальность опять про религию. Я апач только в пример привел, пусть тогда эксплоит для какой-то новой дыры в nginx, вот недавно как раз CVE в парсере была, можно тоже код исполнять. Да, при условии, что таких дыр нет в процессоре, сетевой карте, стэке tcp ядра. И потому что а) это не Си и дибильных ошибок с арифметикой указателей, ручным управлением памяти и т.д. нет и б) ограничение доступа происходит сразу после accept(), всего две строчки кода, а дальше по коду уже не страшно. Даже если бы на Си было, тоже не было бы опасностью, обычно у всех же ограничение доступа по IP сразу после accept(). Потому что нужен огромный пакет в ответ, чтобы была эта самая амплификация Очень сильно ошибаетесь. Как раз не имеем ни зоопарка, ни дыр, ни проблем с обновлением вообще. Это почти как свои пакеты, только без зависимостей и всего софта вперемешку в одном дереве. В смысле одного сервера до актуальных версий? И какой еще анализ конфигов? Конфиги только генерируются, старым версиями неоткуда взяться, все обновляется на всех серверах одновременно. Если во время деплоя на одном каком-то выпало с ошибкой - можно посмотреть что там случилось и передеплоить на него еще раз. Если нужен новый сервер или пару - добавили ssh ключи и запустили деплой, оставив в конфиге только эти два сервера и через 5 минут или пол часа (смотря какой cpu и диск) имеем два новых полностью настроенных сервера. Тем что можно деплоить все или любые сервисы на все или на любой сервер сразу "по нажатию кнопки", и что каждый сервис изолирован вместе со всеми зависимостями, и не привязан к дистру и соответственно не нужно следовать ограничениям пакетной системы, что очень сильно все упрощает и экономит время. Вы зря так на пакеты молитесь, они не созданы для современных условий. Раньше ведь ни виртуализации, ни амазона, ни рекспейса не было и все думали, что большой проект - это пару больших машин, большой сервер субд и админ, который это все настроит. Пакеты под такую задачу вполне хорошая идея. Но сейчас уже не так, и нужно чтобы было так же легко работать с десятком машин, как и с одной, а лучше с сотней. И пакеты больше не подходят, а только создают геморой.
  12. ttttt

    Хелп! Ломанули сервер!

    Какой-то детский лепет уже Вот допустим эксплоит в апаче, как вы зарежите его файрволом, например ipfw? Естественно, что апач должен продолжать отвечать на запросы. Другие бд тоже не смотрям в мир, есть своего рода бд прокси, который раскладывает данные по шардам/серверам. Вот он смотрит в мир, но ему тоже не нужен файрвол для ограничения доступа. Открою вам еще больший секрет: для доменов нужен авторитативный сервер, а не рекурсивный. Авторитативный может смотреть в мир сколько влезет и в качестве амплификатора использоваться не будет. Нет конечно. Из сырцов почит все, да, кое-что статически кросс-компилится, тогда компилится на той машине, с которой деплоится. Апдейт библиотеки занимает очень мало времени, потому что все библиотеки собираются вместе с каждым сервисом изолированно от остальных. Конфиги генерируются, ничего руками не делается. Уже об этом говорил в прошлой теме. Чего сравнивать, было дело и с дебианом. Сейчас поддержка серверов вообще времени не отнимает, софт деплоится все равно чаще, раз в пару дней может, если в среднем.
  13. ttttt

    Хелп! Ломанули сервер!

    Вы не подменяйте понятия, файрвол и ограничение доступа - разные вещи. Мне нужно разграничивать доступ, но мне не нужно это делать файрволом. Мускула вообще нет. Мда. Вы вообще понимаете, что такое dns amplification? Такие атаки возможны, только если ваш рекурсивный днс криво настроен, т.е. в мир открыт. Даже инициатива была выловить кривые днс, проверьте себя: http://openresolverproject.org/ Это не аргумент, это ваша религия. Я могу точно также спросить, и накой пользоваться файрволом в ядре, который в каждом ядре разный, а где-то вообще нет, если можно для sshd пользоваться tcp wrappers? А для чего-то другого мне и не нужно. Да нету админа вообще, никакого. Ха, зоопарк. Зоопарк - это традиционный подход, который вы проповедуете: админы, пакеты, ручками деплоить на каждой машине из терминала, каждая машина имеет разное предназанчение и т.д. Как только у вас будет много машин - окажется, что нихера такой подход не работает и добавление админов ничего не решит, единственный способ все это держать - только автоматизировать, а админы обычно не в состоянии это делать. Вот и нет админов. И деплоить софт раз в пару дней занимает ну максимум пол часа.
  14. ttttt

    Хелп! Ломанули сервер!

    Вот скажите, зачем оно вам? Оно нужно только хостингам с sshd открытым на весь мир, потому что они не могут использовать белые списки или отключить пароли.
  15. ttttt

    Хелп! Ломанули сервер!

    Ну расскажите мне, зачем файрвол на машинах. Это админская чушь "по феншую" уже поднадоела, почему нельзя головой подумать? Вот если нет реальной надобности держать файрвол, зачем держать файрвол? Админов, вообще-то, никто спрашивать не будет по архитектуре, а то они понаделают.. Да и нет у меня админов, они давно заменены скриптами.
  16. ttttt

    Хелп! Ломанули сервер!

    Ну если у вас один дистр какой-то на всех машинах, то еще терпимо ограничивать что-то файрволом. А когда это и линуксы и фря и где-то есть файрвол, а где-то нет и файрволы, как вы понимаете, разные, то какое вообще ограничение файрволом? Это будет ужас для админа.
  17. ttttt

    Хелп! Ломанули сервер!

    Кайот, что-то у вас много правил каких-то непонятных. Нехорошо следовать каким-то правилам непонятно кем и зачем придуманным, хорошо - думать своей головой.
  18. ttttt

    Хелп! Ломанули сервер!

    Эта "штука" работает для sshd на всех системах по дефолту, ее специально включать не надо, ее можно только специально отключить.
  19. Ну собери клиентов на месяц вперед, пообещай им запуск 1-го июля и тогда и приходи искать сервер, а будет мало денег - вернешь их всем и бросишь это дело, зачем рисковать?
  20. ttttt

    Хелп! Ломанули сервер!

    Лучше начните с основ - белых списков, tcp wrappers в sshd ведь на всех системах включен по дефолту. Открываете /etc/hosts.allow и пишите туда только свои айпишники, например: sshd : 1.1.1.1 1.1.1.2 : allow sshd : 2.2.2. : allow sshd : ALL : deny
  21. Уже твоя третья тема, мог бы давно взять сервер и попробовать что к чему Вон на днях тут фрихост предлагал за 220 грн. сервер с 30 мегабит каналом.
  22. ttttt

    Будущее торентов ?

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

    Будущее торентов ?

    Ну и главное, что забыли, во всех других странах, где активно боролись с пиратством - никто никуда не перешел почему-то. Просто стали намного маньше пользоваться торрентами и файлообменниками.
  24. ttttt

    Будущее торентов ?

    Ну правильно, зачем тогда юзерам возвращаться на сайт? Зачем выкладывать, если все могут качать не заходя? В этом главное отличие торрентов. Да и в emule они не анонимно, в imule только.
×
×
  • Створити нове...