paran0id, если речь идёт не о парсинге произвольного html, а только о файлах заранее известной структуры, то это может быть оправдано. Например, мне однажды потребовалось разобрать sitemap.xml одного сайта. Вместо того, чтобы тянуть xml-парсер в скрипт, я просто выкусил текст между угловыми скобками в каждой строке.
Ziptar, в теории да. На практике же если сеть там существует ещё с допотопных времён, то там может быть что угодно и 10 уволившихся админов пережить...
Сергей Набоков, если хочется суперпростого решения на базе костыля, есть такая штука, как nameif.
Но нужно понимать, что если интерфейсы поменяют имена, то systemd это не очень понравится...
Именно поэтому настраивают в правилах udev. Чтобы на ранней стадии отработало. Если файлов нет в rules.d - их надо создавать. По умолчанию используются стандартные правила откуда-то из /lib/udev/rules.d/
Но лучше всего оставить как есть, если нет какой-то реальной задачи, где нужно обеспечить иные имена интерфейсов. Этот подход придумали именно из-за того, что именование интерфейсов может оказаться каким попало между перезагрузками. И это не шутка - такое реально случается на практике.
Аппаратный RAID - это лотерея. Если с ним что-то будет не так, то потом достать данные может оказаться нетривиальной задачей.
Реальная история. Сервер с контроллером Adaptec, при какой-то операции по соединению двух разделов в один контроллер что-то сделал не так с затиранием части данных и разрушением файлухи. Параллельно, конечно, оказалось, что бэкапы именно этого сервера уже полгода как сломались...
Восстановление потребовало недели медитаций. Коллега нашёл на диске bmp-файл и подбирал правильный порядок блоков, чтобы картинка не превращалась в художественную шахматную доску. Оказалось, RAID5 там какой-то свой, нестандартный. И в целом там данных не сошлось довольно мало, менее 2%. Пронесло, буквально...
Этот контроллер вообще чудесатый был. Запускаешь какую-нибудь операцию, например, sync на новый диск. Он через некоторое время начинает показыват, что никакой операции не выполняется. Но очевидно, что sync продолжается и по активности диска это слышно. И даже после ребута сервера он продолжается. И всё равно контроллер рапортует no operation in progress...
Разумеется, после этого контроллер был превращён в обычный контроллер дисков, а RAID собрали в mdadm.
Слишком много есть подобных историй и поэтому большинство опытных админов уверенно посоветуют софтверный RAID в операционке (необязательно mdadm, можно и zfs). Там хотя бы исходный код доступен и пользовательская база на порядки больше базы любого RAID-контроллера. И поломка контроллера не потребует срочной покупки такого же (а его может и не быть на рынке уже).
Refguser, не представляю. Я не особо часто с этим зачинщиком сталкивался, но не помню, чтобы имя файла не было видно. И в скриншотах, которые по этой ошибке в инетах гуглятся, обычно видно, какой драйцер вызвал этот Winring0.
Refguser, это скорее всего не приложение, а какой-то драйвер в ring0. Гугление по проблеме показывает, что сейчас много жалоб в инете на срабатывании на потенциально уязвимый драйвер LibreHardwareMonitor, который используют разные приложения, например, FanControl. https://www.reddit.com/r/techsupport/comments/1j8j...
tukreb, не надо стереотипы винды тащить на незнакомые для тебя операционные системы. Обновление ядра Linux никаких проблем не вызывает. Более того, даже если с ним вдруг случатся какие-то проблемы, всегда можно в загрузчике выбрать предыдущее ядро, потому что популярные дистрибутивы специально так пакетят ядро, чтобы их можно было иметь в системе несколько штук и установка нового ничего со старыми не делает. Для возврата к предыдущему ядру даже не надо воевать с "откатами" и "точками восстановления", достаточно просто выбрать не первую строчку в загрузчике.
Это как раз в винде любое обновление чего угодно может вызвать какой угодно непредсказуемый эффект. Буквально осенью тут столкнулся - прилетает обновление и система начинает время от времени непресказуемо вылетать в BSOD. Разумеется, с максимально невнятной ошибкой. Разумеется, в логах пусто. Разумеется, откат ручками решает проблему, пока винда не накатит обнову снова. Разумеется, через некоторое время откат стал недоступной опцией. Ведь процесс установки обновлений в винде слабоконтролируемый. Хорошо хоть через некоторое время проблема ушла. Видимо, фикс таки сделали. И ладно это домашний копьютер не очень активного пользователя - а если это чей-то рабочий инструмент?
Вот вин-юзеры привыкли к такому поведению и думают, что в других системах так же. Но реальность от такой веры не изменяется.
Shurik, нет, основная суть моего комментария именно в том, что надо выбирать не потому что мейнстрим, а потому что оно решает какие-то задачи каким-то образом после осознанного выбора этого самого решения разработчиком плюс затраты на имплементацию. Если уже что-то есть - то его не надо во что бы то ни стало сразу переписывать с нуля (это же ещё и ни фига не просто может оказаться).
Эта погоня за модными технологиями редко приводит к чему-то хорошему. А то начинают - то монга у них в качестве базы, то хадуп наворачивают, то в кубере всё надо запускать, то простую программу начинают на микросервисы распиливать...
JWT хорошо тем, что не нужно хранить в базе инфу о выданных токенах и в микросервисной архитектуре не нужно всем сервисам иметь доступ к этой критической информации. Проверка токена - это проверка его криптографической подписи и срока действия в нём. Если злоумышленники смогут считать базу в классическом приложении, где аутентификационные данные (токены, id сессий итд) лежат прямо в базе, то они смогут выполнять запросы от имени любых пользователей. А с JWT даже слив базы (неприятно, конечно) не приведёт к получению работающих токенов.
В принципе, можно самому реализовать те же идеи или их вариации без прямого повторения JWT. Ну для начала хотя бы не хранить идентификаторы сессий в базе, а шифровать их.
В мобильной разработке не разбираюсь, в реакте тем более, что там может быть уже наверчено не могу сказать.
Не надо делать "потому что все делают". На самом деле, далеко не всегда нужно городить jwt. Тем более что без понимания причин выбора jwt и правильных практик использования с учётом реальных сценариев угроз можно сделать ещё хуже, ещё ненадёжнее, ещё нестабильнее, чем более простые и кондовые решения.
Надо не просто гоняться за модой, а понять, почему jwt так популярно, какие задачи решает, какие сценарии угроз предотвращает (а может не предотвращаеь, но уменьшает риск), какие удобства предлагает, итд итп. И тогда, вполне возможно, даже вопросов не останется и именно jwt и будет выбрано как итоговое решение. А может и не будет.
Капсамун Артем, тогда несколько selenium запустить и на разных прокси.
Да, это больно. Но иначе парсер будет слишком очевиден и сайтозащиту ему не пройти никак.
Я бы рекомендовал бросить эту затею. Все прекрасно понимают, зачем такой интерес у многих пользователей к парсингу этого сайта и почему он так усиленно защищается ог этих действий. Интерес этот сложно назвать благовидным.
Раз gbdpi помогает - значит, блокирует именно цензурное ведомство.
Может оказаться, что ECH на самом деле не выключен. В браузерах (по крайней мере хромовых) его сложно отключить.