Василий Банников

socks5 только умеет,
socks4 старый стандарт
https, http это proxy прикладного уровня

Короткий ответ — никак. Всё что вы можете, это максимально описать элементы сайта через schemas и семантику, а поисковики уже сами решат в каком виде давать вас в выдаче.

То, как начинал я - это уже не важно, так как не релевантно реалиям нового времени. Современному начинающему я бы посоветовал начать с учебника для начинающего, освоить основы некоторого языка, попрактиковаться с учебными примерами, потом прочитать учебник посложнее, написать пет-проект, устроиться на работу и расти там под руководством старших.

Просто начать писать код

Начиная с версии Viber 6.0, все основные функции Viber защищены с помощью сквозного шифрования: голосовые звонки между двумя абонентами, обмен сообщениями между двумя абонентами, групповые переписки, совместное использование информации в приватном режиме, а также подключенные устройства. Это означает, что ключи шифрования хранятся только на ваших устройствах, и никто, даже Viber, не имеет доступа к ним. Дополнительную информацию по шифрованию в Viber вы можете получить по этому адресу: www.viber.com/ru/security.

Как уже сказали - для сферического сервиса в ваккуме - ответа нет.
В K8S есть свои нюансы с конфигурацией pods, но в целом все как всегда:
- написать бета версию
- запустить load test
- проанализировать и прикинуть, где надо увеличить систему (sizing) а где оптимизировать
- починить код, базу данных и т.п.
- все повторить - load test и т.п.

Я могу двум разработчикам из моей команды дать написать микросервис по одному ТЗ и на одних технологиях, а на выходе получаться сервисы с разной производительностью и разным потреблением ресурсов. Как раз для сферических в вакууме случаев невозможна даже приблизительная оценка. При достаточно профессиональной команде и полной свободе выбора технологических решений можно идти от обратного - определить в ТЗ границы доступных ресурсов.

В таких случаех все решается деньгами.

Выкладки начальству о стоимости поддержки старой версии, включая совместимость современных ОС/платформ и уязвимостей.

Выкладки начальству по поводу рисков, например о возможности легко найти людей которые готовы ковыряться и поддерживать старые платформы, если вдруг вы, например, решите уйти, или если старая платформа сдохнет, а завести ее сложно, гемор с виртуалками и уязвимостями

Сроки на нормальную (в штатном режиме, а не аврале) разработке новой версии, грамотный выбор новой платформы, версии, стоимость.

Собственно как эту инфу соберешь, сам поймешь имеет ли смысл переходить

Непонятно что вы хотите увидеть в этой табличке? Кейсы в которых надо брать ООП или не-ООП?

Мы живем в эпоху мультикультурализма в разработке. Языки такие как C++/Scala в принципе - мультипарадигменные. Они являются одновременно ООП и ФП. И эта диффузия продолжается.
И другие языки тоже идут в этом направлении.

Есть хороший доклад Брагилевского где он просто напримере геометрических фигур (круг, квадрат)
показвывает что ФП и ООП - это просто две ортогональные технологии которые одинаково ведут
к успеху.

По реализациям. 99% зависит от платформы. Например языки C#/F# будут скорее всего использовать
платформу .Net и ее реализацию типов и классов. Языки Java/Kotlin/Scala - соотв будут опираться
на JVM-представление классов и ее типы. Erlang/Elixir - своя реализация типов в beam-машинке.
Нативные языки - кто во что гаразд.

Когда использовать не-объектные языки. Ну не знаю. Я-бы опять уточнил - когда вам не стоит
внедрять пользовательские типы/классы. Вот я щас пишу утилиту для копирования данных
с продуктового ftp на тестовый. Там нужно файлы выбирать по датам. Код на scala. Состоит
из 1 объекта Main и порядка 40 штук функций. Пользовательских типов нет. Вот мне как-то
так хватило и этого. Если писать notebooks под Databricks то там тоже идет такой себе
стиль программирования где нет явной декларации классов.

Вобщем самый лучший язык - это тот который вы знаете. И профессионал может решить любую
задачу в своём языке всегда. Поэтому я-бы не стал париться рисованием таких табличек.
Тем более что она очень спорная и бесполезная.

Значительная часть практических задач не упирается ни в какой язык, и выбор делается не из соображений каких-то абстрактных корректностей, фич и подводных камней, а элементарно - что лучше знаешь, на том и пишешь.
Придуманное вами сравнение по этой простой причине никакой практической пользы не несет. Впрочем, не исключено, что кто-то повысасывал из пальца и такую информацию...

ООП, например, вообще не применяется в программировании скриптов на Bash. И в PostScript ООП нет и не будет. И еще есть куча ниш, где оно просто не нужно. Но вам-то это правда нужно знать, если вы не сталкивались и не узнали именно поэтому?..

В Linux есть замечательная утилита rename. Ну, точнее, их две: одна входит в пакет util-linux, другая - скрипт на базе perl-модуля File::Rename. В deb-дистрибутивах нужный нам скрипт устанавливается в составе пакета rename и также имеет имя второе file-rename (а версия из util-linux имеет имя rename.ul). В других дистрибутивах может быть иначе, поэтому смотрим внимательнее параметры запуска (можно запустить rename без параметров и убедиться, что это нужный вариант).

Синтаксис предельно простой: rename регулярное_выражение_замены_perl имена_файлов

Синтаксис rename.ul для сравнения: rename что_заменить на_что_заменить имена_файлов

Вот что можно сделать для решения задачи (в предположении, что других точек, кроме как перед расширением, в имени файла нет):

rename 's/-\w+\././' *

Этот скрипт намного удобнее многоэтажных однострочников, да и пригодится в жизни ещё не раз.

однозначно = мощный внешний аккумулятор, который заряжать ночью дома от 220 В

Пойти в магазин автозвука и купить модуль отсечки магнитолы по разряду и вывести разьем прикуривателя уже из магнитолы. Когда замигает могнитола нужно подзарядится.

Второй вариант переходник с ардуиной и твердотельным реле, просто при нужном напряжении отрубает питание.

Третий самый ломовой, мой приятель подключился к CAN шине, соответственно считывая ее отрубал через микроконтроллер потребителей, ну и управлял машиной