Ярослав

Может быть проще на всех доменах прописывать алиасы (CNAME) на другое доменное имя, и тогда если надо всем "переехать" - то достаточно будет поменять только одну запись ?

На всякий случай, если нужно для регистрации в ВК, то SMS-сервисы тоже подходят. ВК делает звонок, но через минуту можно выбрать "послать SMS"

Думаю, надо учить именно на недостаточном уровне. Тогда и уровень заодно в нужных местах подтянется.

Вы говорите об ограничении в 64k портов. Оно проявляется, например, в том, что вы не сможете на сервере запустить (на одном IP) больше 64k сетевых сервисов. (ssh слушает порт 22, apache слушает 80, mysql слушает 3306) итд. Каждый слушающий сервис идентифицируется по сокету ( IP + порт), IP у вас один, портов 64k, значит, 64k слушающих сокетов.

А вот для установленных TCP соединений:

socket
An address which specifically includes a port identifier, that
is, the concatenation of an Internet Address with a TCP port.

connection
A logical communication path identified by a pair of sockets.

https://tools.ietf.org/html/rfc793

То есть, соединение идентифицируется по IP сервера, порт сервера, IP клиента, порт клиента.

Да и вы сами на любом более-менее активном веб-сервере видите через lsof множество соединений, и они все установлены с одним вашим сокетом (IP:80 или IP:443), но у них разный второй сокет. Если пользователь, например, качает какой-то файл в два потока, будет один коннект: server:80 - client:4444 и еще один коннект: server:80 - client:4445. Это разные TCP соединения.

Я, конечно, понимаю, что вы спрашивали 3 года назад... но мало ли - вдруг вопрос еще актуален (или поисковиком кто-то с похожим вопросом зайдет). :-)

Про API requests - я только что проверял - при работе сайта, он не лезет в Contentful, все данные, которые берутся из Contentful, берутся на этапе генерации статики и хранятся статично. Так что API реквесты выполняются только при перестроении сайта, и сайт даже с очень высокой посещаемостью не использует эти запросы.

Можно сделать (через dd) файл нужного размера, через mkfs его отформатировать и подмонтировать. Дать юзеру полномочия на эту файловую систему. Железно не выйдет за ее пределы.

Помимо того, что вам правильно ответили - замерьте еще бенчмарком, например, https://github.com/kdlucas/byte-unixbench . Еще: cat /proc/cpuinfo

Не слишком важно ведь, физический или виртуальный, гораздо важнее, сколько мощности он выдает. Некоторые слабые физические сервера могут быть слабее хорошей виртуалки.

Не будет это толком работать. mailchimp и подобные потому и существуют, что если вы не хотите серьезно погружаться в сферу bulk mailing (учить всякие greylisting, DKIM, DCC, DMARC, SPF, DNSBL, FBL, ARF, а еще и SMTP и DNS, автоматически обрабатывать баунсы и ансабскрайбы) - а это займет серьезное время - то толком запустить это не получится. Сервисы рассылок существуют не потому, что дураки-клиенты не догадались сто тысяч раз в цикле письмо отправить, а потому что они дешевле, чем рассылать самому (время ведь тоже не бесплатное, и упущенная прибыль от недоставленных писем - реальная)

1. MTA
постфикс - как и любой другой MTA для обычного применения, не самый удачный вариант. Не факт, что справится. Он - для очень надежной доставки, а это плохо. Нужна быстрая и менее надежная.
Если у вас сто тысяч получателей - среди них неизбежно будут "дохлые". Письма на них будут оставаться в очереди на несколько дней и постоянно будут происходит перепосылки. Попытки достучаться до мертвого сервера будут отнимать время, в которое не будет рассылаться прочая почта. Ну или придется очень хорошо его изучать, крутить настройки очереди. ( = тратить время, которое деньги).

2. Спам
Даже если вам кажется, что ваши письма кристально чистые - все равно, они будут попадать в спам. Хотя бы потому, что многие пользователи жмут кнопку "это спам" вместо отписки. И очень скоро почти вся ваша почта будет валиться в спам везде (даже для тех пользователей, которые хотят ее получать) и толку от рассылок не будет. Кроме того, будут абузы хостеру, и он очень скоро вас попросит, и придется переезжать на плохой и дорогой абузоустойчивый хостинг.

Да нормально вроде выводит:

xenon@braconnier:/tmp$ cat x.py
with open('txt') as text:
    for line in range(0, 3):
        line = text.readline()
        print(line) # Вывод начинается со Addidas
xenon@braconnier:/tmp$ cat txt 
Termit
Addidas
Nike
xenon@braconnier:/tmp$ python x.py 
Termit

Addidas

Nike

Вы может открываете как-то странно? (в примере не показали откуда text берется)

apt autoremove может быть? (в новых debian'ах просто apt, не apt-get)

Один из простейших методов стеганографии (но далеко не единственный) в том, чтобы изменять подряд младший бит каждого пикселя подряд.

Фактически препод говорил об извлечении зашифрованного сообщения из изображения. Но суть стеганографии в том, что не известен сам факт, что в нем есть зашифрованное сообщение, и уж тем более не известно, как именно оно туда вшивалось и в каком формате само это сообщение.

Конечно, если вы извлечете так побитово поток байтов и он будет осмысленным, например, строкой "Hello world!" - то вряд ли это случайность, скорее всего это на самом деле было спрятано. (Бинго! Вы обнаружили стеганографию и извлекли ее). Но такое можно только если:
1. Вы угадали правильный алгоритм извлечения, тот же, которым вшивали информацию (из бесконечного множества возможных)
2. Вы можете легко определить, что полученный результат - осмысленный, а не просто мусор

Но при правильном использовании, вшиваемая информация будет зашифрованной, поэтому отличить ее от мусора будет невозможно. Это можно проверить простым gzip'ом. Если поток хорошо сжимается - в нем сильная избыточность, это какой-то текст, структура, но не поток шума.

Это все равно что расшифровать очень надежно зашифрованный файл, потому что шифровал его дурак и не сделал все как надо (например, использовал пароль). В частном случае - возможно, в общем случае - невозможно.

Скажу как я (давным-давно) выбирал между Руби и Питоном. Это сейчас они более-менее по нишам разделились, а тогда оба были примерно одинаковыми новыми-модными языками. Поглядел список проектов на том и на другом. Везде немало. Но было принципиальное различие. На Руби почти все проекты были "полезные". Дали рубисту задачу, он ее исполнил и код в GPL выложил. А вот на Питоне было дофига "бесполезных" проектов, которые люди делали явно не ради денег. Вывод - на питоне писать приятно. Это важно.

Ну и вряд ли вы когда-либо серьезно пожалеете, вроде "ах, проект - написать магазин авиабилетов, на руби-то я бы это сделал, а на питоне такое не сделать!". Руби для веба удобнее только рубистам. Питонистам удобнее питон.

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

За двумя важными исключениями:
1) Математическое моделирование. В общем-то это и есть урок алгоритмов и применения математики. Всякие задачи коммивояжера, раскроя материала и системы массового обслуживания. Мостик между реальным миром и математическими формулами.
2) Дискретная математика. В первую очередь математическая логика. Это был единственный предмет, на который я ходил и понимал, что это мне важно, а не "чтобы сдать". И это, считаю, нужно вообще для развития, просто чтобы уметь более четко мыслить.

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

А из источников посоветовал бы такую скучную книгу как математический словарь (такое тоже есть). Без доказательств, тезисно и очень кратко описывает.

В первую очередь поддержу большинство высказавшихся: пересмотрите свою ситуацию, увидьте ее правильно. Хостинг за 100 рублей - это не норма. Хостинг может стоить 100р, и быть достаточно хорошим. А может - и в тысячу раз дороже стоить. Смотря какие требования. Вот в данный момент вы пытаетесь перейти из низшей лиги (лишь бы страничка открывалась) явно куда-то повыше, в область high availability, чтоб ваши сайты падали почти так же редко как гугл. Это решается, но обычно не за 100р.

Теперь, если все таки хочется дешево и сердито. Есть решение даже бесплатное практически. Разработайте схему backup & recovery. Например, каждый день скриптом в полночь копируйте все данные (файлы, базу) на домашний комп. Разработайте план, как восстановить это все на чистом сервере. Возьмите чистый сервер (хоть дома, на VirtualBox'е поднимите) и проверьте, чтобы вы по своей инструкции могли из бэкапов быстро все восстановить, без "творчества" и "интересно, почему оно не работает". Выберите пару провайдеров VPS которые могут вам *быстро* предоставить сервер. (Например, hetzner дает сервер быстро, за минуты, а ovh мне выдавал почти сутки). Ну и все. Живите на одном сервере, платите за один сервер. Но имейте бэкапы (и раз в полгода хотя бы проверяйте что можете все восстановить). А если вдруг что - то за 20 минут оплачиваете и получаете VPSку, по имеющейся схеме распаковываете свои сайты на ней, меняете DNS "и полетели"! :-)

А какие темы, какие программы вас "возбуждают"? Ради чего вообще язык нужен? Но в любом случае, рецепт такой - зайдите на freecode, полистайте, выбирайте клевые программы, и пишите, что-то типа:
Linux kernel - C
Splunk - Python
итд.

А в конце пересмотрите, что получилось у вас на листочке.

Дополнительно к вышесказанному — попробовать изолировать их, хранить на отдельном сервере DB (чтобы на нем ничего не крутилось, через что поломать могут) и либо строго залимитировать доступ правами СУБД (если субд позволяет такое), либо вообще прямой доступ к базе отключить (только с локалхоста), а работа с ней — через свой API (хотя бы в виде простого PHP скрипта) который может иметь функции только для нужных операций.

Например, посчитать всех пользователей из города Урюпинск. (выдает цифру, но не дает сами данные по пользователям).
Если нужно именно получение данных из базы (напр всех данных по пользователю), тот же API может выдавать их, но не более 100 пользователей за день для одного оператора. Этого достаточно для работы, но нельзя будет «высосать» всю базу через «SELECT * FROM table».

Яндекс.
т.к. почту выкачиваю, особой разницы быть и не может (вебморда не важна, а работает достаточно хорошо и то и то).
Кое-какие — заметки-наблюдения:
1. Яндекс — бесплатно, gmail — нет.
2. ПДД и ДНС-хостинг — удобно, бесплатно, записи в ДНСе появляются очень быстно после добавления, сразу же.
3. Дополнительный бонус — возможность сразу получить джаббер-аккаунты для всех почтовых ящиков на своем домене. Просто выставив галочку.
4. Спам режется просто отлично. (но и на гмейле в общем-то тоже)
5. Заметил, что ДНС иногда ложится. Ненадолго, но уже пару раз замечал. (в момент когда не резолвится мой домен — проверяю, интернет есть, резолвинг с сервера яндекса не идет). Редко, ненадолго, но все таки.