Дмитрий

Если "mc --version" > 4.7.6 то можно очень легко прикрутить 256-цвеную схему:

Качаем скин, напимер, отсюда:
http://www.midnight-commander.org/attachment/ticket/2469/xoria256.ini,
кладем его в ~/.config/mc/skins (или в ~/.mc/skins), и запускаем mc командой
TERM=xterm-256color /usr/bin/mc --skin=xoria256
TERM можно прописать в .profile, скин в ~/.config/mc/ini, тогда все по дефолту будет

Первый же ответ в гугле - https://devcenter.heroku.com/articles/sqlite3

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

Можно написать демон для systemd если в вашей операционной системе он используется.

Создаём файл демона:
sudo touch /etc/systemd/system/bot.service

Вставляем туда следующее:

[Unit]
Description=My bot
After=multi-user.target
 
[Service]
Type=idle
ExecStart=/usr/bin/python /путь/до/скрипта/bot.py
Restart=always
 
[Install]
WantedBy=multi-user.target

После этого в консоли выполяем:

sudo systemctl daemon-reload
sudo systemctl enable bot.service
sudo systemctl start bot.service

Чтобы остановить бот:
sudo systemctl stop bot.service
Чтобы удалить из автозагрузки:
sudo systemctl disable bot.service
Чтобы проверить работу демона:
sudo systemctl status bot.service

1. сделать git rm <название файла>, предворительно скопировав его, чтобы не потерять
2. добавить файл в .gitignore
3. закоммитить изменения

В буквальном смысле синглтон призван упростить владение, инициализацию, контроль времени жизни и доступ к элементам глобального состояния программы. Эта фраза является самой важной. А важнее всего - правильно понять ее.

Подход многократно обличался антипаттерном за то, что "глобальное состояние программы - это зло", не смотря на то, что глобальное состояние продолжает оставаться в программе даже после удаления всех синглтонов из проекта.
Я видел проекты с более чем 50 синглтонами и очень тяжелыми проблемами их связи между собой. В синглтоны без разбора и по незнанке вытаскивали буквально все. Это яркий пример антиподхода применения абсолютно любого паттерна.
Важно понимать что никакой элемент проектирования не является антипаттерном, он приводит к проблемам только при неумелом использовании.

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

В качестве альтернативы синглтонам пропагандируются два других подхода: Registry / Service locator и Dependency injection.
К слову, все альтернативы столь же активно и все так же незаслуженно обзываются антипаттернами. :)

Теперь к примерам.
- DirectX. Для работы с графикой тебе необходимо по одной инстанции интерфейсов IDirect3D и IDirect3DDevice. Эти две инстанции декларируют глобальное состояние программы. Инстанции всех буферов, текстур, шейдеров и поверхностей создаются с использованием этих инстанций. Разумным будет предоставить доступ к инстанциям DirectX через подход синглтона.
- OpenGL старых добрых версий. Процедурный интерфейс OpenGL как бы намекает на отсутствие необходимости в глобальном состоянии. Но не тут то было. Для работы с OpenGL необходимо не просто создать контекст, но еще и помнить поток, в котором этот контекст связан с поверхностью вывода. В многопоточной среде контекстов может быть несколько для параллельной загрузки ресурсов. В этом случае помнить надо уже два потока и два контекста (минимум). Само собой, в синглтоне это глобальное состояние смотрится удобнее.
- Sockets. Не важно какие. Когда твое приложение представляет собой MMO проект и у тебя гора подсистем, постоянно и обособленно общающихся с сервером, сетевое подключение разумно оформить в виде синглтона.
- Assets/Resources - они бывают разные, кешируемые и нет, доступные из сети, с жесткого диска, из подсистемы пререндеринга. Опять же, я несколько раз видел боль и страдания от неоднородного контроля ресурсов без соответствующей подсистемы. А сама подсистема управления ресурсами всегда централизована и лучше всего реализуется именно на синглтоне.

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

Конфиг в студию + схему таблички и запрос в SphinxQl
Пока моя догадка что у вас разная кодировка

Приведу конфиг на всякий пожарный который, я из проекта в проект слегка переписываю под нужны..

## Базовый конфиг для всех источников
source sitename_config
{
	type			= mysql
	sql_host		= localhost
	sql_user		= root
	sql_pass		= mysql
	sql_db			= new_site
	sql_port		= 3306

    	sql_query_pre = SET NAMES utf8
    sql_query_pre = SET CHARACTER SET utf8
}

# применили конфиг путем наследования
source sitename_audio :sitename_config
{
	sql_query = \
		SELECT a.* \
		FROM  audio a
# указываем какие поля мы хотим индексировать
		sql_attr_uint	 = user_id
		sql_field_string = id3_title
		sql_field_string = id3_artist
		sql_field_string = description
		sql_attr_json    = id3_json
}

index sitename_audio 
{
	source			  = sitename_audio 
	path			  = e:/Server/sphinx/data/sitename_audio
	docinfo			  = extern
	charset_table     = 0..9, A..Z->a..z, _, a..z, U+410..U+42F->U+430..U+44F, U+430..U+44F
	min_word_len      = 3
	html_strip        = 1       
	min_infix_len     = 3      
	index_exact_words = 1
	blend_chars = &,U+23

	#morphology		= stem_en
	#morphology		= stem_enru, soundex, metaphone

# морфология через словари словоформ...
	morphology      = lemmatize_ru_all
}

##################
#  Comon config
##################

indexer
{
	mem_limit		= 128M
}

searchd
{
	listen			= 9312
	listen			= 9306:mysql41
	log				= e:/Server/sphinx/log/searchd.log
	query_log		= e:/Server/sphinx/log/query.log
	read_timeout	= 5
	max_children	= 30
	pid_file		= e:/Server/sphinx/log/searchd.pid
	max_matches		= 1000
	seamless_rotate	= 1
	preopen_indexes	= 1
	unlink_old		= 1
	workers			= threads # for RT to work
	binlog_path		= e:/Server/sphinx/data
}

common
{
	lemmatizer_base = e:/Server/sphinx/dicts/
}

Терпеть не могу тёмные темы. Либо слишком мало контрастности, когда они серые, либо слишком «выжигающие» буквы, когда фон тёмный.
Тут на хабре было исследование опубликовано, и в ЖЖ где-то его видел, медики говорят, что лучшая тема это тёмно-синее на бежево-жёлтом и какие-то ещё там сочетания цветов.

E-AutoPay, Автокассир, JustClick, Glopart, EcommTools
Не использовал, но видимо то, что нужно.

Канала в 100Мбит/с для 10 тысяч юзеров одновременно смотрящих видео с сайта - банально не хватит.
Школьные знания математики подсказывают, что одному пользователю достанется всего лишь 10килобит/с пропускной способности. У видеофайлов есть такая характеристика как битрейт, если она будет меньше скорости передачи, то возникнут задержки при воспроизведении.
Если юзеры будут смотреть разные видеофайлы, то производительности дисковой подсистемы тоже не хватит.

Какие возможные подводные камни в данной реализации?

Банальный недостаток знаний, как основ, так и всего остального.

Возможно нужно какие-то шаги изначально сделать, чтобы потом не было проблем?

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

Для 10 тыщ одновременных зрителей Nginx хватит, производительность сервера надо мерить. Скорее всего, если на сервере кроме вещания не будет будет вообще ничего, потянет. По интернет каналу хватит одновременно либо на 200 человек для роликов с телефона, либо 50-100 в SD качестве, 25-50 в HD

Зря вы так фреймворки не любите. Представьте вам придется контролировать заголовки, маршрутизацию и кроме этих прелестей смешивать html и программный код. Как только вы дойдете до пункта 2 вам станет не по себе, а сопровождать ваш код сможете только вы. Вы даже не сможете пустить в проект верстальщика(если он не владеет Python). Нет вы конечно можете к вашему проекту написать маршрутизатор, привинтить Jinja и SQLAlchemy что в итоге приведет к созданию фреймворка, но судя по вашему вопросу создавать свой фреймворк в ваши планы не входит.

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