Но автообновление проблему ликвидации уже существующего ботнета не решит ...
Никто такого и не говорил, кажется. Проблему можно было бы решить в 2018 году, если вы MikroTik автоматически пропатчил роутеры тем, кто их подключает и больше ничего не делает.
На ваши вопросы отвечаю: да, конечно, настраивал и использую.
Проблемы с 16 мегабайтной "переполненной" флешкой понятны, но при грамотной системе обновления всё это можно технически обойти, было бы желание у производителя.
Можно я вам тоже вопрос задам? Вы видели какая модель обновления в LTS версиях той же Ubuntu? Вот ровно то же самое нужно было бы и сделать Mikrotik.
Там, где настолько критичная инфраструктура, что не допускает 1 минутного простоя сервиса, скачка питания и т.д., там все обновления, конечно, должны проходить вручную и под контролем специалистов с предварительным тестированием новой версии прошивки.
Но что-то я сомневаюсь, что у 200 тыс. зараженных роутеров везде так.
Короче, я считаю, что производитель должен был сделать функцию автообновления, как минимум включить её по-умолчанию для критических дыр в безопасности, естественно с возможностью отключения. И тогда масштаб ботнета был бы гораздо скромнее.
Некоторые и операционку годами не обновляют, только потом, когда словят проблемы, то обвинять вендора во всех смертных грехах как-то не очень спешат: сам отключил автобоновления - сам виноват.
Согласен, проблемы с переводом на англ. язык уже больше года точно. У меня смена языка нормально работает только на десктопе, на ipad — ни в какую, сколько бы не пробовал. Причем, даже если и удалось переключить интерфейс на англ. язык, то всё равно на некоторых страницах вылезает то русский, то иероглифы, а иногда и то и другое сразу. Иногда еще вылезают ошибки шаблонизатора, когда он не может найти локализованные строчки для отображения и выводит что-то типа «order.price», «order.qty» и т.д.
По моему опыту, из всех интернет магазинов aliexpress — самый косой и кривой.
Что там с кодом магазина происходит даже страшно представить, доходили слухи, что комменты в коде и документация там ни китайском, а разрабам приходится всё это переводить через google translate и пытаться понять, что же там хотел рассказать китайский разработчик.
Ну и где можно подробно ознакомиться со слитыми документами, в частности с принципом работы «Наутилус-С»? Линки выше на mega.nz ведут на старый слив про 0day technologies.
Я работал в Яндексе около года, могу сказать по своему опыту, что всего лишь пару раз пришлось использовать DFS в реальном коде. Но, Яндекс это большая компания, возможно там есть несколько отделов, где необходимость использования алгоритмов несколько выше.
В целом, как мне кажется, большие IT компании стоят перед задачей найма программистов «потоком», для этого нужен какой-то более-менее стандартизированный метод оценки. Причем этот метод должен по-хорошему основываться на каких-то численных показателях для сравнения кандидатов друг с другом. В то же время, метод оценки программистов по количеству решенных алгоритмических задач не является идеальным. У него большой процент false negative ошибок, когда в целом хорошие программисты сталкиваются с проблемами при реализации чисто алгоритмических задач, а люди с олимпиадным прошлым получают бонус.
Но, при всех своих недостатках этот метод работает. Тот кто решил все задачи с большой долей вероятности является неплохим разработчиком, даже с учетом того что в 95% случаев в работе умение решать такие задачи не требуется.
Критикам алгоритмических задач на собеседовании можно предложить придумать свой вариант метода оценки кандидатов. Допустим у вас есть 100 кандидатов, 10 интервьюеров, каким образом вы бы построили метод оценки? Причем ваш метод по-хорошему должен быть максимально справедливым, т.е исключать человеческий фактор со стороны интервьюера, а так же давать на выходе какие-то числа для сравнения кандидатов друг с другом.
Почему никто из рекламирующих лазерную коррекцию подробно не пишет вероятности в % по возможным осложнениям? Упоминают просто что, да, «иногда» они бывают. В штатах например бывали случаи когда люди совершали суицид после LASIK'a. Кому интересно, почитайте на lasikcomplications.com
Никто такого и не говорил, кажется. Проблему можно было бы решить в 2018 году, если вы MikroTik автоматически пропатчил роутеры тем, кто их подключает и больше ничего не делает.
На ваши вопросы отвечаю: да, конечно, настраивал и использую.
Проблемы с 16 мегабайтной "переполненной" флешкой понятны, но при грамотной системе обновления всё это можно технически обойти, было бы желание у производителя.
Можно я вам тоже вопрос задам? Вы видели какая модель обновления в LTS версиях той же Ubuntu? Вот ровно то же самое нужно было бы и сделать Mikrotik.
Отвечу вам и на комментарий @valentin-hl выше.
Там, где настолько критичная инфраструктура, что не допускает 1 минутного простоя сервиса, скачка питания и т.д., там все обновления, конечно, должны проходить вручную и под контролем специалистов с предварительным тестированием новой версии прошивки.
Но что-то я сомневаюсь, что у 200 тыс. зараженных роутеров везде так.
Короче, я считаю, что производитель должен был сделать функцию автообновления, как минимум включить её по-умолчанию для критических дыр в безопасности, естественно с возможностью отключения. И тогда масштаб ботнета был бы гораздо скромнее.
Некоторые и операционку годами не обновляют, только потом, когда словят проблемы, то обвинять вендора во всех смертных грехах как-то не очень спешат: сам отключил автобоновления - сам виноват.
Скрипт автообновления прошивки роутера: https://github.com/beeyev/Mikrotik-RouterOS-automatic-backup-and-update
Можно настроить на запуск например каждую неделю.
По-хорошему, сам производитель роутера должен был сделать функцию обновления прошивки при выявлении критических уязвимостей.
По моему опыту, из всех интернет магазинов aliexpress — самый косой и кривой.
Что там с кодом магазина происходит даже страшно представить, доходили слухи, что комменты в коде и документация там ни китайском, а разрабам приходится всё это переводить через google translate и пытаться понять, что же там хотел рассказать китайский разработчик.
В целом, как мне кажется, большие IT компании стоят перед задачей найма программистов «потоком», для этого нужен какой-то более-менее стандартизированный метод оценки. Причем этот метод должен по-хорошему основываться на каких-то численных показателях для сравнения кандидатов друг с другом. В то же время, метод оценки программистов по количеству решенных алгоритмических задач не является идеальным. У него большой процент false negative ошибок, когда в целом хорошие программисты сталкиваются с проблемами при реализации чисто алгоритмических задач, а люди с олимпиадным прошлым получают бонус.
Но, при всех своих недостатках этот метод работает. Тот кто решил все задачи с большой долей вероятности является неплохим разработчиком, даже с учетом того что в 95% случаев в работе умение решать такие задачи не требуется.
Критикам алгоритмических задач на собеседовании можно предложить придумать свой вариант метода оценки кандидатов. Допустим у вас есть 100 кандидатов, 10 интервьюеров, каким образом вы бы построили метод оценки? Причем ваш метод по-хорошему должен быть максимально справедливым, т.е исключать человеческий фактор со стороны интервьюера, а так же давать на выходе какие-то числа для сравнения кандидатов друг с другом.