О наличие специалиста по найму - рекрутера на тот момент никто не думал и все делали своими силами.
Правил русский язык, я так понимай, тоже не кто не думать. /s
Делали своими силами -- и правильно делали.
Рекрутер отсеивал сразу не подходящих кандидатов и мне не приходилось тратить на них время;
Подходящих кандидатов рекрутер тоже отсеивал.
большинство кандидатов после получения оффера принимали его, даже не смотря на то, что мы предлагали меньше денег чем рынок региона, да тут стоит упомянуть, что наши проекты и продукты были очень интересными и это тоже играло значение.
Поздравляю, теперь вы часть современного HR карго-культа. Теперь в вашей организации работают самые дешёвые и низкокачественные кадры, в чём, собственно, и заключается смысл HR.
ОК, принято. Тогда как минимум налицо терминологическая коллизия. Но опять-таки, как я упомянул в своём комментарии насчёт HTTPS в 2024 году и вы сами упомянули про MitM, в настоящее время практическую актуальность такой режим работы потерял.
По вашей логике тогда вообще всё NAT-маршрутизатор. VPN -- это NAT-маршрутизатор, и прокси это NAT-маршрутизатор.
Прокси работает на самом высоком уровне модели OSI: открывает сокет и слушает соединения, никаких пакетов прокси не фильтрует и собственно на маршрутизацию пакетов никак не влияет.
Маршрутизатор сокетов не открывает, а вместо этого манипулирует пакетами.
Толку от этого не особо много. По тексту совершенно очевидно, что вы не понимаете, как работают интернет-протоколы и HTTP- и SOCKS-прокси, поэтому в тексте масса фактологических ошибок.
HTTP‑прокси хорош для веб‑сёрфинга, SOCKS5 — для универсальных задач
HTTP-прокси в 2024 году хорош примерно ни для чего, т.к. практически все веб-сайты стали использовать шифрование. Если вы используете HTTP-прокси и что-то можете полезного сделать в сети, то это HTTPS-прокси.
Прокси не шифруют данные (за редким исключением HTTPS‑прокси).
Никакие прокси вообще не шифруют данные, ни HTTPS-, ни SOCKS-прокси. Данные шифруются на клиенте и расшифровываются на конечном сайте. Прокси просто пропускает шифрованные данные через себя.
В большинстве случаев прокси просто перенаправляет твой трафик, не шифруя его.
Никакой прокси не шифрует траффик. Все прокси просто перенаправляют твой траффик. Нешифрованного HTTP-траффика сейчас осталось очень мало.
Исключение — HTTPS‑прокси, который шифрует только веб‑трафик, но и он уступает VPN.
Ничего HTTPS-прокси не шифрует. Разница между HTTP- и HTTPS-прокси только в том, что HTTPS-прокси поддерживает метод CONNECT, который позволяет туннелировать TLS-соединения.
SOCKS‑прокси Медленнее, чем HTTP
С какой стати? Протокол SOCKS гораздо более простой и легковесный, чем HTTP. Никакой особой функциональной разницы между HTTPS- и SOCKS-прокси нет, они позволяют делать одно и то же, просто протоколы разные.
3. Транспарентный прокси
Этот тип прокси работает в фоновом режиме и часто используется без ведома пользователя.
А в каком ещё режиме может работать сервер, если не в фоновом?
Например, компании или учебные заведения могут настроить транспарентный прокси, чтобы фильтровать контент или контролировать доступ к сайтам.
Ты отправляешь запрос, не подозревая, что он проходит через прокси. Сервер автоматически перенаправляет его через себя, сохраняя или изменяя информацию.
Ну да, если пользователь не может в силу собственного слабоумия открыть настройки браузера и посмотреть, задан там прокси или нет, то он действительно не подозревает :-) Но это применимо к абсолютно любому типу прокси.
Если в настройках браузера прописать себе проксю -- то сервер автоматически перенаправляет! А пользователь-то не подозревает! Это всё заговор ящериков, не иначе!
Это вообще неправильное определение транспарентного прокси. Транспарентный прокси -- это такой, который определяется конечным сайтом как прокси (по специальным заголовкам, которые он добавляет в запрос).
Пользователю не нужно ничего настраивать.
Ну да, кроме необходимости прописывать прокси в настройках браузера. (Конечно можно раздать настройки прокси по DHCP в локальной сети, но можно с таким же успехом раздать настройки как транспарентных, так и анонимных прокси -- тип прокси на автоматическую раздачу не влияет)
Короче, не статья, а детский сад. Штаны на лямках, деревянные игрушки, горшок ручкой во внутрь.
Кэширование - это ОБЯЗАТЕЛЬНОЕ свойство прокси? или нет?
Нет, не обязательное.
И вообще - есть ли какие иные, кроме сокрытия адреса источника, свойства, которые обязаны быть у узла, чтобы он был прокси?
Сокрытие адреса источника не является обязательным свойством прокси сервера. Большинство прокси-серверов являются т.н. transparent proxy (т.е. прозрачными, в противоположность анонимным): при выполнении HTTP-запроса они добавляют заголовок X-Forwarded-For , содержащий IP адрес клиента, для которого выполняется запрос.
Единственное обязательное свойство прокси сервера следует из смысла английского слова proxy. "To do something by proxy" приблизительно означает делать что-то либо по доверенности, т.е. прокси сервер получает запрос от клиента, соединяется с сайтом, который указан в запросе, отправляет этот запрос сайту и передаёт полученный ответ клиенту.
Сначала люди просто заходили на сайты напрямую — что-то вроде: "О, интернет, тут можно смотреть картинки". Потом начали появляться проблемы: сайт заблокирован, доступ ограничен, провайдер записывает, кто куда ходил... и так далее. Тогда-то и появились прокси.
Как высказался один из комментаторов выше: шта?
Открою автору страшную тайну: прокси появились именно для того, чтобы блокировать сайты. В различных организациях для того, чтобы запретить доступ к определённым сайтам, доступ из локальной сети наружу к портам 80 и 443 вырезается на фаерволле. Открыть сайт в броузере можно только при использовании прокси-сервера организации, на котором реализованы чёрные или белые списки доменов.
Использование прокси для анонимизации и обхода блокировок -- это побочный, а не основной их функционал.
Фотография при найме в продуктовых командах неотъемлемая часть. Люди хотят работать в комфортной средне, а фотография в СНГ - первый способ понять человека лучше) Найм это буквально Тиндер, где если резюме не понравилось на первичном скоринге - оно улетает в корзину.
Собственно, это всё, что нужно знать об HR и рекрутерах -- абсолютно бесполезные и профессионально непригодные люди, которые перепутали Тиндер и работу.
HR -- самое худшее, что случилось с ИТ-индустрией, тупой карго-культ, бесмыссленный и беспощадный.
Во-первых, нет никакого «стандарта FFP», есть EN 149, который описывает 3 маркировки, начинающиеся с букв «FFP», что вы сами и пишете. Во-вторых, не я же, а вы приравняли все эти три маркировки к одной конкретной из американского стандарта.
Ещё раз повторяю, придираетесь к мелочёвке. Или, перефразируя ваше высказывание чуть выше, "скажи, что ты душнила, не говоря, что ты душнила". FFP -- это надмножество над FFP2, про эквивалентность маркировок я нигде не утверждал, по указанию на N95 вы прекрасно поняли, что речь идёт об FFP2.
Во-вторых, вы, видимо, так и не поняли, что «можно ли защититься» — это не ответ да/нет, с ровно двумя вариантами «нет, обязательно заболеете, что вы ни делайте» и «да, можете хоть в зоне карантина ковидной больницы жить 24/7».
Нет, это вы чего-то не поняли. Никакими масками защититься нельзя, даже со 100% фильтрацией, просто потому, что невозможно её на протяжении месяцев её носить с идеальным прилеганием к лицу. По итогу переболели все.
Т.е. вы утверждаете, что FFP2-маска не соответствует стандарту FFP и никакого отношения к нему не имеет? Ну и хорошо, допустим, что FFP -- это не стандарт, а классификация, а стандарт на самом деле EN 149. Придиратесь к мелочёвке.
Речь о том, что по мнению немецких регулирующих органов, листом газеты от короны не защититься, а вот автору оригинального комментария никакие научные данные не нужны и всё и так очевидно.
Если хотите знать моё мнение, то вводить обязательное ношение газентного листа перед лицом -- глупо и абсурдно, потому что ни к какому сколько-то значимому уменьшению риска инфекции эта мера не приведёт. То же самое и с масками.
Мне очевидно, что дигидроген моноксид -- это яд. Все люди, когда либо его употреблявшие, умрут или уже умерли. Какие ещё научные данные нужны? Требую запретить проивзодство, хранение и оборот этого ядовитого вещества. (Вот примерно по такой же логике работали масочные мандаты в пандемию)
Что значит эффективно? Какие научные данные нужны? Если что-то распространяется воздушно-капельным путём, очевидно, что барьер как-то снизит распространение.
Я конечно понимаю, что вам всё очевидно и никакие данные не нужны, но давайте я вам просто напомню: в Германии, например, были введено обязательное ношение масок не абы каких, а стандарта FFP (аналог стандарта N95 в США) -- маски изготовленные по этим стандартам используются в промышленности для фильтрации мелкодисперсной пыли. В качестве причины было указано, что из-за крайне малого размера частиц вируса обычная маска не их отфильтровывает.
Уже только по этой причине получается, что не каждый барьер снижает распространение (и даже у масок FFP/N95 не очень понятно какая эффективность, т.к. они изначально предназначены для других целей). Также есть масса всяких практических вопросов, связанных с использованием масок, пожалуй самый насущный -- какова максимальная длительность использования одной маски.
Представим себе гипотетический сценарий: некий человек в течении получаса ходил в маске на улице по морозу, маска промокла от дыхания, при этом он её три дня не менял. Дальше этот гипотетический человек спускается в ней в метро. И что тогда? Помогает ли она ему? Или же у маски в этом сценарии вообще отрицательная эффективность?
Я согласен с тем, что дебажить такого рода проблему как с форками mail в systemd совсем не тривиально. Я бы попробовал включить LogLevel=debug и посмотреть, есть ли какая-то информация о том, какие процессы systemd убивает при завершении юнита.
Если у нас есть подозрение, что собеседник по какой-то причине оказался не готов к интервью, устал, его что-то отвлекает или просто на улице жара, мы просто спросим его об этом и предложим перенести встречу. Это нормально и все мы люди, все мы устаем, погода от нас не зависит, и все мы это понимаем. Камера помогает получить предпосылки.
Ещё раз просто просто приведу цитату из интервью:
Второй красный флаг, который частично касается вопроса выше о проактивности: когда я уже на собеседовании вижу, что человек очень устал.
Какое тут может быть вырывание из контекста? Вы проболтались и теперь вы очень неловко пытаетесь переобуться. "Жара, все мы люди, все мы устаём..." -- нет, давайте без этого. В процессе интервью вы отсеиваете людей, которые вам кажутся усталыми. Красный флаг -- это про отказ, а не про перенос встречи.
Мы не утверждаем, что наши методы уникальные или даже универсальные, мы рассказываем, как мы проводим интервью. Они могут подходить не всем.
Конечно уникальные, не нужно прибедняться. Такой цирк-шапито надо ещё поискать :-)
Для нас есть разница между «гореть своим делом и хотеть деньги за свою работу» и «хотеть денег и выполнять функцию» — там речь именно про эту разницу. Мы тщательно следим за ростом наших коллег и стараемся их в этом поддерживать, делать процесс этого роста прозрачнее, как с точки зрения их навыков, так и с точки зрения компенсации их труда, так что бесплатно работать не нужно — это плохая практика :)
Так а в чём проблема в "хотеть денег и выполнять функцию"?
В любом случае, если вы подходите для наших вакансий — можете попробовать пройти собеседование и сравнить реальность и ожидания :)
Ой нет, спасибо. Вдруг я усталый? Или в камеру смотреть не буду. И вообще, я на работу только за деньгами хожу.
Уважаемый, ну не надо паясничать. Про налоги написано не на заборе, а в налоговом законодательстве. 45 тыс. евро в год в Германии -- это 2062 евро в месяц после налогов. 250 тысяч рублей в Москве -- это 1920 евро в месяц по сегодняшнему курсу после налогов. Речь о том, что сравнивать заработные платы в разных странах без учёта ставки налогов не вполне корректно.
В linux "fork()" обозвали "clone()", но суть от этого не изменилась.
Вы какие-то странные утверждения делаете. В Linux fork -- это fork, это системный вызов из тех времён, когда в ядре не было неймспейсов, он не принимает никаких параметров. clone -- это другой, хоть и похожий, но более новый системный вызов, с помощью которого можно поместить дочерний процесс в другой неймспейс.
Начинаю копать и выясняю, что этот самый "mail" (который пакуют во всякие "mailutils", "mailx" и т.п.) работает, оказывается, в асинхронном режиме!
Применительно к процессам "асинхронный режим" -- это, на мой взгляд, неправильная терминология. mail форкается и выходит, не дожидаясь завершения дочернего процесса.
но пока не знаю, как правильно её купировать.
Вызывать в вашем юните mail с параметром -S sendwait. В чём проблема с KDE я не понял.
Больше можно не думать обо всех этих "демонизациях", логировании и прочей IT-гигиене. "Сделай тяп-ляп, а systemd за тобой подотрёт". В любой момент может оказаться, что писатель очередного ПО всю зачистку переложил на systemd.
Так ведь в этом и смысл systemd. Ваш юнит просто пишет свой вывод в stdout/stderr, это всё логгируется с помощью journald. Можно настроить юнит так, чтобы юнит перезапускался, если процесс завершается с ненулевым статусом. И т.д. и т.п., у systemd масса всякого функционала.
systemd теперь является де-факто стандартом в большинстве линкус-дистрибутивов, разработчику больше не нужно самому имплементировать демонизацию, логгирование и т.д. На самом деле, вероятность того, что писатель очередного ПО как-то криво сделает зачистку гораздо выше, чем вероятность того, что её криво сделает systemd.
Если вы пишете софт под Devuan или под какие-то очень старые системы на SysVinit -- тогда да, надо самому имплементировать всё это добро.
Правил русский язык, я так понимай, тоже не кто не думать. /s
Делали своими силами -- и правильно делали.
Подходящих кандидатов рекрутер тоже отсеивал.
Поздравляю, теперь вы часть современного HR карго-культа. Теперь в вашей организации работают самые дешёвые и низкокачественные кадры, в чём, собственно, и заключается смысл HR.
Детский сад. Штаны на лямках, деревянные игрушки, горшок ручкой вовнутрь.
ОК, принято. Тогда как минимум налицо терминологическая коллизия. Но опять-таки, как я упомянул в своём комментарии насчёт HTTPS в 2024 году и вы сами упомянули про MitM, в настоящее время практическую актуальность такой режим работы потерял.
По вашей логике тогда вообще всё NAT-маршрутизатор. VPN -- это NAT-маршрутизатор, и прокси это NAT-маршрутизатор.
Прокси работает на самом высоком уровне модели OSI: открывает сокет и слушает соединения, никаких пакетов прокси не фильтрует и собственно на маршрутизацию пакетов никак не влияет.
Маршрутизатор сокетов не открывает, а вместо этого манипулирует пакетами.
Толку от этого не особо много. По тексту совершенно очевидно, что вы не понимаете, как работают интернет-протоколы и HTTP- и SOCKS-прокси, поэтому в тексте масса фактологических ошибок.
HTTP-прокси в 2024 году хорош примерно ни для чего, т.к. практически все веб-сайты стали использовать шифрование. Если вы используете HTTP-прокси и что-то можете полезного сделать в сети, то это HTTPS-прокси.
Никакие прокси вообще не шифруют данные, ни HTTPS-, ни SOCKS-прокси. Данные шифруются на клиенте и расшифровываются на конечном сайте. Прокси просто пропускает шифрованные данные через себя.
Никакой прокси не шифрует траффик. Все прокси просто перенаправляют твой траффик. Нешифрованного HTTP-траффика сейчас осталось очень мало.
Ничего HTTPS-прокси не шифрует. Разница между HTTP- и HTTPS-прокси только в том, что HTTPS-прокси поддерживает метод
CONNECT, который позволяет туннелировать TLS-соединения.С какой стати? Протокол SOCKS гораздо более простой и легковесный, чем HTTP. Никакой особой функциональной разницы между HTTPS- и SOCKS-прокси нет, они позволяют делать одно и то же, просто протоколы разные.
А в каком ещё режиме может работать сервер, если не в фоновом?
Ну да, если пользователь не может в силу собственного слабоумия открыть настройки браузера и посмотреть, задан там прокси или нет, то он действительно не подозревает :-) Но это применимо к абсолютно любому типу прокси.
Если в настройках браузера прописать себе проксю -- то сервер автоматически перенаправляет! А пользователь-то не подозревает! Это всё заговор ящериков, не иначе!
Это вообще неправильное определение транспарентного прокси. Транспарентный прокси -- это такой, который определяется конечным сайтом как прокси (по специальным заголовкам, которые он добавляет в запрос).
Ну да, кроме необходимости прописывать прокси в настройках браузера. (Конечно можно раздать настройки прокси по DHCP в локальной сети, но можно с таким же успехом раздать настройки как транспарентных, так и анонимных прокси -- тип прокси на автоматическую раздачу не влияет)
Короче, не статья, а детский сад. Штаны на лямках, деревянные игрушки, горшок ручкой во внутрь.
Нет, не обязательное.
Сокрытие адреса источника не является обязательным свойством прокси сервера. Большинство прокси-серверов являются т.н. transparent proxy (т.е. прозрачными, в противоположность анонимным): при выполнении HTTP-запроса они добавляют заголовок
X-Forwarded-For, содержащий IP адрес клиента, для которого выполняется запрос.Единственное обязательное свойство прокси сервера следует из смысла английского слова proxy. "To do something by proxy" приблизительно означает делать что-то либо по доверенности, т.е. прокси сервер получает запрос от клиента, соединяется с сайтом, который указан в запросе, отправляет этот запрос сайту и передаёт полученный ответ клиенту.
Как высказался один из комментаторов выше: шта?
Открою автору страшную тайну: прокси появились именно для того, чтобы блокировать сайты. В различных организациях для того, чтобы запретить доступ к определённым сайтам, доступ из локальной сети наружу к портам 80 и 443 вырезается на фаерволле. Открыть сайт в броузере можно только при использовании прокси-сервера организации, на котором реализованы чёрные или белые списки доменов.
Использование прокси для анонимизации и обхода блокировок -- это побочный, а не основной их функционал.
Тренд нынче такой. Помнится, героиня Horizon Forbidden West со времён Horizon: Zero Dawn тоже знатно оскуфела:
Скрытый текст
Собственно, это всё, что нужно знать об HR и рекрутерах -- абсолютно бесполезные и профессионально непригодные люди, которые перепутали Тиндер и работу.
HR -- самое худшее, что случилось с ИТ-индустрией, тупой карго-культ, бесмыссленный и беспощадный.
Хотел написать какой-нибудь едкий коммент, но мне лень.
Ещё раз повторяю, придираетесь к мелочёвке. Или, перефразируя ваше высказывание чуть выше, "скажи, что ты душнила, не говоря, что ты душнила". FFP -- это надмножество над FFP2, про эквивалентность маркировок я нигде не утверждал, по указанию на N95 вы прекрасно поняли, что речь идёт об FFP2.
Нет, это вы чего-то не поняли. Никакими масками защититься нельзя, даже со 100% фильтрацией, просто потому, что невозможно её на протяжении месяцев её носить с идеальным прилеганием к лицу. По итогу переболели все.
Так он здоров. Его без прививочного сертификата, ковид-теста и QR-кода на улицу не выпускают. :-)
Т.е. вы утверждаете, что FFP2-маска не соответствует стандарту FFP и никакого отношения к нему не имеет? Ну и хорошо, допустим, что FFP -- это не стандарт, а классификация, а стандарт на самом деле EN 149. Придиратесь к мелочёвке.
Речь о том, что по мнению немецких регулирующих органов, листом газеты от короны не защититься, а вот автору оригинального комментария никакие научные данные не нужны и всё и так очевидно.
Если хотите знать моё мнение, то вводить обязательное ношение газентного листа перед лицом -- глупо и абсурдно, потому что ни к какому сколько-то значимому уменьшению риска инфекции эта мера не приведёт. То же самое и с масками.
Мне очевидно, что дигидроген моноксид -- это яд. Все люди, когда либо его употреблявшие, умрут или уже умерли. Какие ещё научные данные нужны? Требую запретить проивзодство, хранение и оборот этого ядовитого вещества. (Вот примерно по такой же логике работали масочные мандаты в пандемию)
Я конечно понимаю, что вам всё очевидно и никакие данные не нужны, но давайте я вам просто напомню: в Германии, например, были введено обязательное ношение масок не абы каких, а стандарта FFP (аналог стандарта N95 в США) -- маски изготовленные по этим стандартам используются в промышленности для фильтрации мелкодисперсной пыли. В качестве причины было указано, что из-за крайне малого размера частиц вируса обычная маска не их отфильтровывает.
Уже только по этой причине получается, что не каждый барьер снижает распространение (и даже у масок FFP/N95 не очень понятно какая эффективность, т.к. они изначально предназначены для других целей). Также есть масса всяких практических вопросов, связанных с использованием масок, пожалуй самый насущный -- какова максимальная длительность использования одной маски.
Представим себе гипотетический сценарий: некий человек в течении получаса ходил в маске на улице по морозу, маска промокла от дыхания, при этом он её три дня не менял. Дальше этот гипотетический человек спускается в ней в метро. И что тогда? Помогает ли она ему? Или же у маски в этом сценарии вообще отрицательная эффективность?
Так Гугл тоже катится. Они решили катиться вместе :-)
Я согласен с тем, что дебажить такого рода проблему как с форками
mailв systemd совсем не тривиально. Я бы попробовал включитьLogLevel=debugи посмотреть, есть ли какая-то информация о том, какие процессы systemd убивает при завершении юнита.Ещё раз просто просто приведу цитату из интервью:
Какое тут может быть вырывание из контекста? Вы проболтались и теперь вы очень неловко пытаетесь переобуться. "Жара, все мы люди, все мы устаём..." -- нет, давайте без этого. В процессе интервью вы отсеиваете людей, которые вам кажутся усталыми. Красный флаг -- это про отказ, а не про перенос встречи.
Конечно уникальные, не нужно прибедняться. Такой цирк-шапито надо ещё поискать :-)
Так а в чём проблема в "хотеть денег и выполнять функцию"?
Ой нет, спасибо. Вдруг я усталый? Или в камеру смотреть не буду. И вообще, я на работу только за деньгами хожу.
Уважаемый, ну не надо паясничать. Про налоги написано не на заборе, а в налоговом законодательстве. 45 тыс. евро в год в Германии -- это 2062 евро в месяц после налогов. 250 тысяч рублей в Москве -- это 1920 евро в месяц по сегодняшнему курсу после налогов. Речь о том, что сравнивать заработные платы в разных странах без учёта ставки налогов не вполне корректно.
Вы какие-то странные утверждения делаете. В Linux
fork-- этоfork, это системный вызов из тех времён, когда в ядре не было неймспейсов, он не принимает никаких параметров.clone-- это другой, хоть и похожий, но более новый системный вызов, с помощью которого можно поместить дочерний процесс в другой неймспейс.Применительно к процессам "асинхронный режим" -- это, на мой взгляд, неправильная терминология.
mailфоркается и выходит, не дожидаясь завершения дочернего процесса.Вызывать в вашем юните
mailс параметром-S sendwait. В чём проблема с KDE я не понял.Так ведь в этом и смысл systemd. Ваш юнит просто пишет свой вывод в stdout/stderr, это всё логгируется с помощью journald. Можно настроить юнит так, чтобы юнит перезапускался, если процесс завершается с ненулевым статусом. И т.д. и т.п., у systemd масса всякого функционала.
systemd теперь является де-факто стандартом в большинстве линкус-дистрибутивов, разработчику больше не нужно самому имплементировать демонизацию, логгирование и т.д. На самом деле, вероятность того, что писатель очередного ПО как-то криво сделает зачистку гораздо выше, чем вероятность того, что её криво сделает systemd.
Если вы пишете софт под Devuan или под какие-то очень старые системы на SysVinit -- тогда да, надо самому имплементировать всё это добро.