Алексей Черемисин

Да, стоит! Только не подержанный, да можно и подержанный. Сам купил в прошлом году подобный, правда i5, 8гб, 500гб. SSD ставится легко по производительности, от ноута супруги практически не отличается (MacBook Air i3).
Можно спокойно работать с 1-2 виртуалками под VMWare Fusion.
Для разработки как раз.

Да, на вопрос - сколько протянет? Предыдущий макбук white unibody Core2Duo вот прямо сейчас лежит на столе. 2009 года выпуска. Батарея еще держит около часа. Я как бы с него переезжаю :-D Пол года к ряду.

Вариантов несколько. Использовать QT-python.
Использовать sciphy -www.scipy-lectures.org/advanced/image_processing
Использвать PIL/Pillow - https://habrahabr.ru/post/247219/ и pillow.readthedocs.io/en/3.3.x

Во всех этих фреймворках можно поставить две точки, нарисовать маркер и его двигать по изображению. Ну а длину линии всегда можно вычислить по теореме Пифагора - a**2 + b**2 = c**2

Можно поступать по разному.
Использовать скрипт, с зависимостяти, или просто вставить это в Makefile отдельным таргетом, чтобы можно было вытащить все зависимости.
Или использовать submodules -

https://git-scm.com/book/ru/v1/Инструменты-Git-Подмодули

И перейти с использования CVS и SVN на git или mercurial!

Скорее всего это tar-архив, возможно зазипованный. Попробуйте его посмотреть командой tar -tf my.dar
Еще попробуйте опции -z или -J
Ну точно! http://doc.ispsystem.ru/index.php/Технические_подр...
tar -tzf mybackup.dar И tar -xzf mybackup.dar

Обычно запущено одна или пара виртуалок (VmWare Fusion), эклипс с пирогами, пара браузеров (хром и сафари) с парой десятков табов и всякая чушь по вкусу типа скайпов, мессаджей айтермов и впэнов :-)
А вот фотошоп не пользую, предпочитаю pixelmator!

Ух, он вам не нужен (RTlinux)! Тем более, он не развивается уже лет 10-15.
Более того, когда, еще в 1999 году проводили тестирование реалтайм функциональности линукса в разных вариантах, сравнивая их с настоящими ОСРВ, то отличий стандартных RT функций ядра, разных RT-расширений и большинства функционала коммерческих ОСРВ - не нашли! Вот моя, сильно порезанная статья того времени - www.osp.ru/os/1999/09-10/177813
Из нее выкинули, по коммерческим причинам, все тесты, упоминания и сравнения с коммерческими ОСРВ (я всё-таки их не буду называть, по этическим соображениям).
В общем, просто рекомендую пользовать стандартный шедулер и не париться. Ну а если не будет хватать, если еще куча специализированных шедулеров, заточенных на РВ, в разных вариациях.
Если все нужно в коммерческом смысле, то есть и куча дистрибутивов, типа MontaVista Linux, оптимизированных под очень серьезные задачи, с допиленными шедулерами, собственными стеками и IPC.

Ну, можно передавать картинку из памяти - QPixmap::QPixmap(const char * const[] xpm)
Только перед этим ее нужно преобразовать изображение в массив xpm.

Еще можно:
1) сначала из потока байт создаем
QImage::QImage(uchar * data, int width, int height, Format format)

2) потом получившийся QImage переделываем в QPixmap
bool QPixmap::convertFromImage(const QImage & image, Qt::ImageConversionFlags flags = Qt::AutoColor)

3) передаем его в img1.setPixmap

Хороший вопрос!
На третий взгляд, я бы поступил по следующему алгоритму.

Взял бы базу данных, ну например mysql.... Для хранения кешей и коллизий.
Итак, нам нужно пройтись по записям бигфайла, и сформировать новый бигфайл.
1) берем строчку файла, считаем от нее (или какой-то части), например sha1.
2) ищем по базе данных наш sha1
(таблица в "hashes" c полями "hash" и "offset", "count")
2.1) Если не нашли:

• копируем текущую строку в новый файл
  
• заносим наш sha1 и начало строки в базу (это нужно для коллизий)
  

2.2) Если нашли:

• из базы забираем смещение начала строки
  
• из старого файла вытягиваем всю строку по смещению и сравниваем
  
• если строки равны, то переходим на п1) (можно еще и обновить count этой записи)
  
• если строки не равны, у нас коллизия (!), обрабатываем ее
  

3) Обработка коллизии
(таблица в "collisions" c полями "hash" и "offset", "count")

• берем из collisions все записи по нашему хешу
  
• для каждой записи вынимаем строку из старого файла и сравниваем
  
• если строки равны, то переходим на п1) (можно еще и обновить count этой записи)
  
• если строки не равны, добавляем новую запись в таблицу collisions с новым смещением, текущюю строку пишем в новый файл
  
  

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

PS. Можно еще дополнительное поле в каждой из таблиц сделать "count", обновлять его, если произошло сравнение записей, для статистики.

Здесь совсем нечеткая логика, скоре всего вам нужно будет парсить фразы на лексемы, затем определять грамматику самой фразы. Причем "после завтра в 5 30" и "завтра после 5 30" хоть и отличаются на одну букву, а промахнуться можно на сутки :-)
ну и наверняка не обойдется без какой нибудь векторной математики, типа какое действие за каким следует и к чему относится.
Ну и как минимум нужно много, очень много тестовых образцов. Например "вчера он сказал, что завтра будет дождь, дождя не было", "два дня назад от третьего воскресенья октября".

Так или иначе, лучше использовать NIO, и проверять наличие данных через selector! Вот на почитать - www.javaportal.ru/java/articles/useselectfast.html... (ожидание входящих данных)
И откажитесь вообще от sleep - это не очень красиво.
Да, возможно, данные придется буферировать, так как они могут прийти в двух пакетах, например "BEG" и "IN"
С файлами отдельная история - наверное поможет вот это! Механизм аналогичный - https://docs.oracle.com/javase/tutorial/essential/...

Вообще-то postressql всегда была именно реляционной, а в последние 2-3 года туда прикрутили в блобы кучу дополнительных индексаторов. И настала возможность делать "объектный" поиск по этим блобам.
Собственно профит в том, что отдельные поля могут индексироваться на манер текстовых поисковиков, например по json-полям с некоторой агрегацией.
На мой взгляд, это просто разновидность текстового поиска в реляционной базе, хотя и сильно улучшенного.
Выгода - хранить json + реляционную информацию, во многих случаях это бывает выгодным. В других - просто взять nosql (elastic/mongo) выгоднее. Ну многие наверное будут отказываться от отдельного solr/elastic.

Подозреваю, что не происходит "перекомпиляция" pyc-файлов.

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

Добро пожаловать в битрикс :-D
$APPLICATION->IncludeComponent(...); Подключает компонент, у которого свои шаблоны (html+php), php-код, javascript и прочее. В это место страницы вставляется то, что получилось в результате выполнения кода компонента. Да: компоненты могут быть комплексными и включать в себя туеву хучу других компонентов, для этого нужно лезть в код и шаблоны соответствующего компонента.
$APPLICATION->IncludeFile(...); Подключает дополнительный файл, аналогично директиве include в PHP, но может передавать туда и параметры.
Ну а в остальном, да, нужно смотреть Уроки и читать Документацию на битрикс.
Все ужасы программазма там в действии, с кривой архитектурой и плохим стилем. Зато он самый обожаемый заказчивами и на нем "много чего можно сделать".