shurshur

Когда-то давно один товарищ обнаружил, что реализация вычисления чисел Фибоначчи через рекурсию на Java работает быстрее, чем её аналог на C. Он не только поудивлялся этому, но и поизучал вопрос. Оказалось, что gcc в каждом вызове функции делал push si; push di; и по окончании pop si; pop di; хотя регистры si и di в скомпилированном коде никак не использовались. Это давало какие-то микроскопические, но всё же расходы времени.

Любой конкретный тест специфичен, он показывает не то, как быстро работает тот или иной язык (точнее, его конкретная реализация), а какие в этой реализации получились расходы времени на конкретную задачу. В другой задаче, в другой реализации того же языка, просто даже на другом оборудовании может получиться другой результат.

Операционная система, её разрядность, загруженные расширения - всё влияет.

Знание языка программирования - а лучше нескольких - это всегда плюс. Помогает как в написании своих скриптов, так и в отладке/переиспользованию чужих. И, конечно, качества и распространённость таких языков влияют. Но это всё равно опционально, в отличие от знания bash. Хотя, конечно, не знать совсем ни одного языка больше похоже на крайность, чем на норму.

Для начала проверяем RDNS/DKIM/SPF и всё такое. Большинство почтовиков очень плохо отнесутся к письму с невнятного хоста.

Копировать A1 в буфер и затем вставлять в B1 как Edit->Paste special->Paste values only.

Если на хостинге нет модуля telebot, то его туда надо установить (как правило можно сделать командой pip install telebot). Вот их собственная инструкция на этот счёт https://help.pythonanywhere.com/pages/InstallingNe...

Для изучения нет никакой нужды "скачивать" этот сайт. Достаточно консоли браузера.

Эти данные заполняет javascript на сайте (с включённым uMatrix у меня тоже ничего не показало). Надо разобраться, что и как скрипт делает, и воспроизвести его логику. Подозреваю, что нужные данные находятся в параметре vfa формы finanaliz-form, но дальше разбираться мне лень.

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

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

Задача "стать гуру" в принципе неправильно поставлена. Любой мастер начинает с того, что работает подмастерье, делая несложные вещи. Но, опять же, именно делая, а не просто читая теоретические книжки. Так что можно брать те же олимпиадные задачки и пытаться их решать. Заодно осознать всю боль о необходимости самому выделять и освобождать память.

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

Со многих точек зрения я бы предпочёл debian'ообразия, например, в нём изкаропки больше софта. Но есть доводы и в сторону centos, например, в нём есть есть готовые полиси для selinux (в debian с ними давно сложности), обычно проще с поддержкой интырпрайзного софта (всяких поделий от oracle, например).

Не слишком сложно устроенный и не слишком сопротивляющийся подобному нецелевому использованию - с помощью wget с соответствующими ключами:

wget -m https://natribu.org/

Есть также более user friendly средства с графическими интерфейсами, но я ими никогда не пользовался и в их сортах не разбираюсь.

В общем случае без программирования никуда - придётся разбираться в запутанных js, в лимитах и мерах против скачивания. Ну и ясен пень какой-нибудь вконтактик выкачать нереально просто даже в силу его объёма.

Можно пытаться угадывать, что пользователь выходит не из домашней сети и не из сети какой-то организации, а с сервера у какого-то хостера, используя какие-либо знания о сетях хостеров и провайдеров, но надёжно и во всех случаях это сделать всё равно не получится. Что касается определения факта "непрямого" доступа, если пользователь не использует прокси, которые сами явно и открыто "светят" реальные IP пользователя и всех промежуточных прокси в заголовке X-Forwarded-For, то и поймать его на этом нельзя.

Цепочки разнообразных хостов используют из соображения, что давлением правоохранителей на многих разнообразных хостеров (тем более в разных странах) вряд ли можно быстро получить доступ к данным, которые бы помогли бы идентифицировать пользователя. Но это не значит, что нельзя попасться, впрочем, чаще всего и попадаются совсем не на этом. Типичный пример - когда разыскиваемому пользователю отправляют письмо, содержащее уникальную ссылку на картинку, запрос к которой попадёт в логи с реальным IP.

На самом деле ipsec vpn это не очень-то и vpn, это просто инкапсуляция трафика в tunnel esp режиме ipsec, которая выполняется уже после маршрутизации на основе правил в конфигурации ipsec. Я бы советовал поднять с клиентом настоящие vpn (openvpn/l2tp/итд), в том числе их можно поднять поверх ipsec (если политика безопасности клиента того требует). И дальше просто даже метриками разрулить основной и резервный VPN до одинакового IP (который будет на самом деле терминироваться в разных датацентрах). Это самый простой вариант в случае если клиент не может сам балансировать между двумя точками подключения, одна из которых может отказать.