sim3x

На домашнем сервере пока можно и дебиан развернуть. После установки поставить нормальный init и выбросить поттерингд.
lxc, помнится, не прибит ещё гвоздями. В отличии от libvirt, который уже прибит к policykit, но только на уровне прописанных в пакете зависимостях, а после ручной правки манифеста ставится и работает нормально.

До такого вот состояния можно и десктоп исправить:

melkij@melkij-work:~$ dpkg -l | grep systemd
ii  libsystemd0:amd64                     215-17+deb8u7                        amd64        systemd utility library
ii  libsystemd0:i386                      215-17+deb8u7                        i386         systemd utility library
melkij@melkij-work:~$ lsb_release -a
No LSB modules are available.
Distributor ID:	Debian
Description:	Debian GNU/Linux 8.8 (jessie)
Release:	8.8
Codename:	jessie
melkij@melkij-work:~$

Если только пару пакетов взять с devuan через apt-preferences:

Package: *
Pin: origin packages.devuan.org
Pin-Priority: 50

Package: libpolkit-agent-1-0 libpolkit-backend-1-0 libpolkit-gobject-1-0 policykit-1 udisks2 libudisks2-0 cgmanager libcgmanager0
Pin: origin packages.devuan.org
Pin-Priority: 700

Package: systemd systemd:amd64 systemd:i386
Pin: origin
Pin-Priority: -1

Package: pulseaudio pulseaudio:amd64 pulseaudio:i386
Pin: origin
Pin-Priority: -1

Что-то около года полёт нормальный.

Я не раз видел попытки такого разделения пользователей по классам в проектах на Django. Не знаю, почему все сразу выбирают такое решение, которое в перспективе не приносит ничего, кроме боли.

Проще всего пойти стандартным путем: унаследовать пользователя от django.contrib.auth.models.AbstractUser, а различие между пользователями определять либо по группе/разрешениям, либо добавить поле в свою модель типа is_moderator. Это будет во много раз (на порядок точно) проще реализовать и поддерживать, будет совместимость со всем стандартным кодом Django и сторонними библиотеками, любому просто войти в проект и внести изменения.

Разделение на две разных модели никаких абсолютно преимуществ не дает, кроме тонны мусорного кода и головняков с поддержкой данной гидры.

TLDR:
1) Из вашего вопроса остается неясным, почему требуется разделение по разным классам. Это самый безумный вариант для разграничения полномочий, и в Django разделение полномочий пользователей уже предусмотрено по умолчанию
2) Поддерживал пару проектов с разными классами для разных классов пользователей. Поверьте, это просто ужас-ужас в поддержке, а самое главное, что он ничем не оправдан.

Здесь стоит посмотреть с 2х строн:
1. Если вы часть команды и мелкая сошка -- смирится, либо идти по головам к начальству с наглядными примерами, и объяснением того в долгосрочной перспективе ваш подход принесет больше прибыли (меньше убытков). Если начальник адекватный, он задумается и поставит вас тимлидом, если нет -- то это его проблемы, вы свою точку зрения донесли.

2. Если вы лицо принимающее решение в команде, и являетесь тимлидом --- тогда руководить и вводить метрики, ревью кода, и т.п. штуки, чтобы когда кто-то косячил, другие говорили ему "Вася ты дурак".

Безопасно. Указанием "../" в URI подняться выше root нельзя.

Просмотрев hh пришел к мнению, что 90к можно просить на собеседованиях т.к. будут торги и скорей всего до 75-80к опустят работодатели. На сколько я прав или не прав в этом?

Какой торг, вы о чем вообще? Я набираю персонал время от времени - так не делается.

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

Но простого торга на деньги на непонятно каком основании не бывает.

Разве что вы пойдете устраиваться на работу в компанию, которая сама не знает кого приглашает и даже рынок потрудилась проштудировать перед объявлением вакансии. Чаще такое встречается в компаниях далеких от ИТ, но там нужно быть готовым, что к ИТ отнесут, утрирую, ремонт чайника секретарши.

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

Для тех, кто не в курсе - это кажется парадоксом, почему бы фирме не наступить тебе на горло, не выторговать меньшую цену за твою работу. А дело в том, что задача стоит не "взять специалиста на как можно меньшие деньги", а "взять на эти деньги как можно лучшего специалиста". Ибо в сфере ИТ сейчас жуткий дефицит на вменяемых специалистов. Пример, к нам на вакансию "Админ Линукса" приходят кандидаты, 80% из которых не знает что такое "маска IP-адреса"

Бизнес штука суровая. Без расчетов - ты прогоришь. Все расчитано.

Вот Вы жук ))). Вы после покупки батона выясняете не завышена ли на него цена была?
Если исполнитель то что делается за 20 часов сделал за 15 - красава. Я бы даже сверх заплатил. Вам выполнили услугу, да еще и на четверть быстрее, чем обещали. А Вы хотите денег содрать? АААААААААААААААААААААААААА

telebotиспользует threading, функции с декоратором message_handler вызываются из потока на его тредпуле. Курсор sqlite3, созданный в конструкторе db из главного потока, не может быть использован в вызове send_welcome -> user_register -> db.query из другого потока.

Перенесите создание курсора cur = self.con.cursor() в метод query и сделайте его локальной переменной.
Или кешируйте создаваемые курсоры в threading.local, если производительность в этой точке критична (не думаю, что это так, исходя из задач бота).

Балансировку в таких случаях делают на dns. Насколько я помню Amazon Route53 точно умеет гео-балансировку, но можно и какой-нибудь другой сервис поискать.

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

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

Нужно определиться:
a) насколько реально данные должны быть консистентны. (если не сильно - вам повезло)
b) какой объем данных нужно синхронизировать (в событиях в секунду и в мегабайтах в секунду)
И дальше исходя из этого уже садиться думать.

\[\d+\] выбирает число в квадратных скобках
Не знаю, какую документацию вы читаете, но в документации по Python никогда не говорилось, что символ / что-то экранирует.

1. Переделать логотип
2. Убрать анимацию надписи в футере (уже не модно)
3. На странице сервиса выровнять форму отзыва не по центру, а справа(по умолчанию)
4. В футере переделать кнопки соц. сетей на более свежие
5. Добавить кнопку "Наверх"
6. Вержхнее меню при прокрутке выровнить по центру(горизонтально)
7. Заменить аватарки отзывов(человечки ужасно выглядят)
8. Уменьшить высоту блока,который выезжает при смене города
Вроде все...