Вобщем сижу тут, разрабатываю один проект. Дошел до того шага, когда нужно начинать обмениваться данными между разными сервисами и вроде как нужно прикручивать Docker, связывать контейнеры и будет мне счастье, но так ли это?

Структура проекта следующая:

• SQL-сервер
• Web-backend на PHP
• Web-frontend на Flutter
• Сервис №1 на Java
• Сервис №2 на Java

С самого начала проектирования я планировал завернуть это все в Docker, но у меня получается целая куча контейнеров:

1. SQL-сервер
2. Web-backend
3. Web-frontend
4. Внешний nginx, который проксирует запросы куда надо
5. certbot для внешнего nginx, чтобы получать сертификаты
6. Сервис №1 на Java
7. Сервис №2 на Java

Docker принято использовать для упрощения развертывания, переноса, создания нужного окружения на машинах, где может не быть нужных пакетов. В моем случае, я вижу в использовании Docker только усложнение конфигурации и лишнюю точку отказа. Прав ли я? Может я просто устал и упускаю что-то? Как вы думаете: Docker - это серебряная пуля или стрельба из пушки по воробьям?

Vivid Money - европейский финтех стартап. Основной продукт - мобильное приложение.

Запустились в Германии, Франции, Испании и Италии (основатели экс-топы из Тинькофф).

Ищем Scala-разработчиков c production опытом на Scala в офис в Москве или по России на удаленку.

Задачи: разработка бэкенда в сore-платформе и платежах.

FP cтек технологий: ZIO, scalates, cats, tofu, typed schema, tagless final, circe, fs2, droste etc. Другое: Redis, Consul, Postgresql, Kubernetes, Helm, DynamoDB, Kibana (ELK), Grafana, Prometheus, gRPC. Условия: зп от 200 тыс. на руки и выше (ориентируемся на уровень кандидата + учитываем итоги интервью), опционы, бенефиты с едой, спортом, англ.

Описание вакансии: https://jobs.vivid.money/jobs/Careers/33579000001439340/Backend-Developer-Sca...

Подробности в личке @Dante2707(телега)

Сижу правлю текст в nano, простой такой текстовый файл из смеси русских и аглицких буковок... Жму Ctrl+X, на вопрос, надо ли сохранять файл, жамкаю «Y», возвращаюсь в консольку. Смотрю файл — а мои последние изменения не записаны. Чудеса, думаю, вот меня приглючило... Ещё раз редактирую, Ctrl+X, «Y» — файл записан.

Спустя пару минут снова немного меняю файл, Ctrl+X, «Y» — и опять, зараза, не записан. И тут до меня допёрло: клавиша «Y» и «Н» — это одна и та же клавиша!.. И в зависимости от раскладки она работает то как «Yes», то как «Нет»...

Мне вот интересно, это какие надмозги придумали?..

"NixOS - это дистрибутив Linux, базирующийся на Nix, системе управления пакетами, основанной на функциональном подходе. NixOS - это эксперимент, который позволит выяснить возможно ли существование операционной системы, в которой пакеты, конфигурационные файлы, загрузочные скрипты и т.д. управляются функциональным способом, т.е. они все собраны детерменированными функциями, и они больше никогда не меняются после данной сборки."

Вот собственно основные концепции данной любопытной разработки:
- Вся система, включая ядро, системные сервисы, конфигурационные файлы и т.д. собирается, так называемыми Nix выражениями детерменированным и воспроизводимым способом.
- Поскольку изменения концигурации не деструктивны(они не перезаписывают существующие файлы), пользователь может легко откатиться к предыдущим конфигурациям. Например, загрузочное меню Grub в NixOS позволяет пользователю загрузиться в любую предыдущую конфигаруцию системы, которая ещё не была убрана сборщиком мусора. Это довольно полезно, если что-то идёт не так.
- Обновление конфигурации настолько безопасно, насколько может быть безопасна установка "с нуля", поскольку реализация конфигурации не сохраняет предыдущие свои состояния.
- Многопользовательская система управления пакетами - каждый пользователь может устанавливать программы таким же путём, как и пользователь с правами администратора. Этот менеджер пакетов не похож на большинство остальных, как, например, RPM

Сообщение о новом дистрибутиве на osnews

>>> Подробности

Привет, ЛОР!

Я уже давно заметил, что ЛОР — сообщество поклонников продукции одной мелкомягкой корпорации добра.
Причём, все восхваляют этот самый продукт, и утверждают, что там всё работает идеально, из коробки и вообще никаких проблем.

Решил я тут накатить себе эту самую винду на второй SSD.
Захотелось поиграть в виар (HL Alyx), а на линуксе оно пока что не заводится.

Ну, купил винду на сайте MS (то ещё приключение), скачал образ, залил на флешку...
Упс.

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

Пришлось идти другим путём — пробрасывать второй диск в виртуалку и ставить винду туда.
После нескольких часов сношений, это таки удалось. А именно:

1. создаём виртуалку в QEMU
2. пробрасываем блочный девайс /dev/nvme1n1 в режиме SATA
3. устанавливаем венду
4. добавляем загрузочную запись через efibootmgr
5. загружаем винду
6. ловим BSoD
7. перезагружаем винду в безопасном режиме
8. ставим драйвера на чипсет
9. перезагружаем винду
10. PROFIT

CPU: AMD Ryzen 9 5900X 12-Core @ 24x 3.7GHz
GPU: AMD Navi 21 [Radeon RX 6800/6800 XT / 6900 XT] 

06:00.0 Network controller [0280]: Intel Corporation Wi-Fi 6 AX200 [8086:2723] (rev 1a)
07:00.0 Ethernet controller [0200]: Realtek Semiconductor Co., Ltd. RTL8125 2.5GbE Controller [10ec:8125] (rev 04)

Bus 006 Device 002: ID 0499:174d Yamaha Corp. Steinberg UR24C

К нам часто приходит парень и покупает мел. Он говорит, что он его ест. Я думал, ну у всех свои странности. Потом пришла девушка и тоже покупает мел, чтобы его есть. Что вообще происходит? Зачем, для чего?

Допустим, у нас есть простой класс с виртуальным методом:

class A {
public:
    virtual ~A() = default;
    virtual void f(void *ptr) = 0;
};

Подразумевается, что разные реализации A принимают в методе f указатели на разные объекты и как-то их обрабатывают. То есть, типичная реализация метода f такая:

void B::f(void *ptr) {
    auto data = (SomeType*) ptr; // SomeType разный для разных наследников A
    //делаем что-нибудь с data
}

Допустим, я хочу избавиться от необходимости кастовать ptr в конкретный тип в каждом наследнике класса A (например, потому что методов подобных f очень много и наследников очень много).

И я делаю что-то вроде такого:

template<typename T> class ATemplate: public A {
protected:
    virtual void realF(T *t) = 0;

public:
    void f(void *ptr) final {
        realF(static_cast<T*>(ptr));
    }

};

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

Однако если посмотреть на результат компиляции, то теперь у нас при каждом вызове f происходит два косвенных перехода - сначала при вызове f (ведь это виртуальная функция), а затем при вызове realF (ведь это тоже виртуальная функция). А хотелось бы обойтись одним переходом. Ведь на самом деле можно было бы подложить адрес realF на место f в таблице виртуальных методов (кастование указателя это лишь синтаксический сахар и на уровне ассемблерного кода не создаёт инструкции, поскольку это лишь вопрос интерпритации указателя дальше по коду, а сам указатель не меняется).

В Java есть type erasure и поэтому можно было написать просто:

class A<T> {
    public abstract void f(T arg);
};

class B<SomeType> {
    public void f(SomeType arg) {
        // что-то делаем
    }
};

В C++ мы не можем сделать базовый класс (A) шаблонным, иначе сломается runtime полиморфизм. Чтобы и не надо было делать явный каст в наследниках, и полиморфизм работал, пришлось сделать костыль с промежуточным шаблоном-наследником, но он приводит к генерации неоптимального кода.

Какие ещё есть варианты повторить то, что можно сделать в Java?

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

Сам по себе десктоп клиент ватсапа в любом случае требует зондофон и без него зарегать и использовать аккаунт не получится ведь ?

GTK2: Aeterna
Openbox: Aeterna
Обои

>>> Просмотр (1366x768, 1035 Kb)

После увиденного скрина с xfce в галерее, решил тоже себе поставить. Работает шустро. Даже firefox не тормозит теперь (до этого в KDE притормаживал). Скажу только, что изменил:

- Добавил яблоко в Menu :)
- Поставил темы Candido-graphite
- Шапка от Candido-redux
- Тема firefox iFox Graphite
- В xfceшной консоли убрал меню, добавил прозрачность, забиндил свою комбинацию клавиш открытия таба

В gaim убрал галку show buddy icons :-)

Собирал графическим инсталятором от xfce

>>> Просмотр (1024x768, 278 Kb)

По сусекам поскреб, собрал абсолютно бесшумную железку:

Athlon 2000+
Radeon 9200
512 озу
2 x 40 gb

Firefox с NoScript летает, без него иногда подтормаживает.
Рипы dvd крутит без проблем. 720p аниме ест неплохо, но тормозит на динамичных заставках :)

Простая тема xfwm, сделал под впечатлением от этого.
Тема gtk2 на движке mist, заодно пилю gtk3.

>>> Просмотр (1280x1024, 436 Kb)

В основном вся представленная техника используется для прослушивания futurepop, J-rock и серфинга по русифицированному куску интернетов. На фото:

• два стола непонятно какой марки и модели;
  
• стул непонятно какой марки и модели;
  
• чемодан столяра непонятно какой марки и модели;
  
• два системника с железом внутри; что за DE, думаю, говорить не надо;
  
• хипсторские наушники очень известной компании German Maestro, ценятся за крепко сбитый дизайн, эргономику и звук, идеально подходят для того, чтобы в них спать, модель 8.35 D;
  
• собственно, камера, которой я всё это снимал, находилась в чужом смартфоне, по этой причине на фото её нет;
  
• также на фото можно лицезреть джой для тщетных попыток научиться летать в одном популярном хипсторском симуляторе от Maddox Games.

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

Вот и всё, вроде.

>>> Просмотр (2048x1536, 472 Kb)

Здрасьте, кто не спит!

Происходит переезд с CentOS на Debian. На что обратить особое внимание? Переезжает простецкая малонагруженная ерунда типа nginx, php, mariadb, openvpn, wireguard, ftp, qemu c виндовс гестом, postfix+dovecot и прочие незначительные мелочи.

UPD: Контейнеры и всякие снапы не нужны. Убунту не предлагать.

Где будут неожиданности или просто расслабиться и получать удовольствие?

Заранее благодарю за конструктивные рекомендации!

Хочу мыллер поднять и nextcloud. При этом меня интересует не протухшая версия последнего. Соответственно протухший php я бы тоже не хотел.
Ну и собственно вопрос: что из этого выбрать в 2019 году?
До сегодняшнего дня сижу на Debian на серверах.

Вышла новая версия красивого и полнофункционального Gemini-клиента — Lagrange, написанного на языке C с использованием библиотеки SDL.

Gemini — это новый протокол прикладного уровня, по своему предназначению являющийся простой альтернативой HTTP и усовершенствованной альтернативой Gopher, то есть проектом «посередине» между ними в плане сложности. Он появился как реакция на недостатки последних, в особенности HTTP. В основу его дизайна легли идеи уважения приватности пользователя и сознательного отказа от расширяемости в пользу консервативного сохранения спецификации в минимальном, но удовлетворяющем пользовательские потребности виде (сейчас она заморожена). Проект использует уже знакомые многим стандарты, вроде URI, MIME и TLS. Проект не использует HTML, CSS и JavaScript — для разметки файлов предлагается похожий на Markdown формат Gemtext, а запуск кода и применение стилей на стороне клиента не предусмотрены. Для интерактивного взаимодействия с сервером существует CGI и потоковая отправка сообщений клиенту с помощью долгоживущего TCP-соединения (вследствие чего, например, возможна реализация чата). Сайты принудительно используют шифрование с помощью TLS без CA — вместо него используется механизм TOFU, а для аутентификации пользователей используются пользовательские сертификаты.

Сообщество разрастается интересными для пользователей проектами, вроде поисковой системы GUS, агрегатора новостей CAPCOM, каталогом Gemini-капсул (так называются местные сайты) Medusae, техническими демо возможностей протокола, вроде анонимной текстовой доски, агрегатора ссылок и чата. Доступны прокси как для просмотра Geminispace с помощью HTTP [1] [2] [3], так и для просмотра HTTP с помощью Gemini, и то же самое для Gopher.

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

Lagrange является одним из таких проектов — небольшим Gemini-клиентом с поддержкой аппаратного ускорения с помощью SDL и плавного листания страниц, отображения картинок на странице, вкладок, тем оформления, закладок, истории, пользовательских сертификатов, оглавлений, новостных лент.

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

В разработке порт Lagrange на мобильные платформы! А до тех пор пользователи могут попробовать Ariane на Android, например.

>>> Подробности

Так уж получилось, что, вроде бы, в последних выпусках ядра Linux или в каком-то другом компоненте что-то сломали, из-за чего на последней Fedora с Intel HD 4000 производительность графики просто отвратительная. Мне было влом разбираться, из-за чего такая регрессия на вполне известном старом железе (Thinkpad X230) и поэтому опытным путём было выяснено, что на Ubuntu 20.04 всё в порядке — на ней сейчас и пытаюсь жить.

Я избегаю использование LTS-дистрибутивов на рабочем железе, т.к. понятия не имею, откуда брать для них программы. Для Fedora это практически не является проблемой, т.к. инструменты разработки там поддерживаются хорошо и всё нужное можно найти в основных (или не очень, вроде полуофициального RPM Fusion) репозиториях. С Ubuntu это не так: из-за заморозки пакетов, пожалуйста, ешь устаревшие программы и на каждый чих подключай дополнительный репозиторий/PPA, что на самом деле не очень вариант, т.к. они не всегда есть, а если и есть — поддерживаются какими-то левыми людьми (что не плохо само по себе, просто не ясно, как долго и как качественно оно будет поддерживаться).

Ubuntu неплохой дистрибутив, но управление пакетами с помощью Apt — последнее, чем мне бы хотелось заниматься. Слава Богиням, практически все графические программы поставляются в виде Flatpak/Snap/AppImage, чего не сказать о CLI, демонах и средствах разработки. Но и тут повезло: и эту нишу закрывает ещё один пакетный менеджер — Nix, не заставляя устанавливать целую NixOS, разработчики которой сами признают, что оно пока непригодно для десктопа. Nix прекрасен: опакечено и собрано всё на свете, а чего нет — скорее всего присутствует в оверлеях (практически как в Gentoo!).

Установка буквально в одну команду (в этом примере для единственного пользователя):

sh <(curl -L https://nixos.org/nix/install) --no-daemon

Что нам сразу установит Nix с нестабильным каналом пакетов.

А чтобы не возиться с nix-env -Ai package вручную, есть Nix Home Manager:

nix-channel --add https://github.com/nix-community/home-manager/archive/master.tar.gz home-manager
nix-channel --update home-manager
nix-shell '<home-manager>' -A install`

После установки которого у нас в $HOME/.config/nixpkgs/home.nix появляется нечто похожее на configuration.nix из NixOS, где можно централизованно описать состояние своей домашней директории. Моя свежеустановленная конфигурация выглядит так:

{ config, pkgs, ... }:


let
  nixGLIntel = (pkgs.callPackage "${builtins.fetchTarball {
    url = https://github.com/guibou/nixGL/archive/master.tar.gz;
  }}/nixGL.nix" {}).nixGLIntel;
  pkgsNixOS = import <nixos> {};
in
{
  # Let Home Manager install and manage itself.
  programs.home-manager.enable = true;

  home.packages = with pkgs; [
    youtube-dl
    fd
    ripgrep
    docker-compose
#    emacs
  ];

  programs.mpv = {
    enable = true;
    package =
      pkgs.writeShellScriptBin "mpv" ''
        #!/bin/sh

        ${nixGLIntel}/bin/nixGLIntel ${pkgs.mpv}/bin/mpv "$@"
      '';
  };

  programs.emacs = {
    enable = true;
    package = pkgsNixOS.emacsPgtkGcc;
  };

  services.syncthing.enable = true;

  # Home Manager needs a bit of information about you and the
  # paths it should manage.
  home.username = "commagray";
  home.homeDirectory = "/home/commagray";

  # This value determines the Home Manager release that your
  # configuration is compatible with. This helps avoid breakage
  # when a new Home Manager release introduces backwards
  # incompatible changes.
  #
  # You can update Home Manager without changing this value. See
  # the Home Manager release notes for a list of state version
  # changes in each release.
  home.stateVersion = "21.05";
}

В ней можно отметить несколько моментов.

• Наличие nixGL. К сожалению, Nix всё ещё плохо работает с программами, которым нужно графическое ускорение. Этот небольшой враппер чинит GPU-ускорение, позволяя программам, вроде mpv, корректно использовать GPU и VA-API.
• Странный пакет Emacs под названием emacsPgtkGcc. PGTK и native-comp — это патчи для Emacs, превращающие Emacs в правильную GTK-программу и включающие компилирование Elisp-кода в натив с помощью libgccjit. Мой выбор пал на Nix именно из-за того, что с помощью него можно легко установить данный патчсет, даже ничего не компилируя.
  • Установите Cachix — с помощью этой программы можно указать адрес кэша уже собранных Nix-пакетов.
    • nix-env -iA cachix -f https://cachix.org/api/v1/install
  • Добавьте оверлей для Emacs, где хэш — последний удачно собранный коммит.
  • Включите нужные репозитории с кэшем пакетов для оверлея.
    • cachix use nix-community
    • cachix use mjlbach
  • После очередного home-manager switch у вас появится Emacs.
  • Для отображения ярлыков в меню добавьте export XDG_DATA_DIRS="$HOME/.nix-profile/share:$XDG_DATA_DIRS" в свой $HOME/.profile.

commagray@Cloudsdale:~$ cat ~/.config/nixpkgs/overlays/emacs.nix 
import (builtins.fetchTarball {
  url = https://github.com/nix-community/emacs-overlay/archive/2438466b9a4f496191838457d208c09ebbe97991.tar.gz;
})

• Сервис Syncthing. Home Manager умный и умеет управлять systemd-юнитами. Список поддерживаемых демонов тут.
• Home Manager умеет управлять настройками отдельных программ. Список поддерживаемых программ тут.

В таком виде у меня практически девственно чистая Ubuntu, коротая вряд ли сломается из-за конфликта установленных пакетов. Такой способ сработает со всеми дистрибутивами и даже macOS. Пользоваться приятно, не говоря уже о таких великих вещах, как nix-shell.

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

Инновационный интерфейс, новая корневая идея, всплывающие окна, тонущие двери, убегающие стенки, конкурирующие звёзды, толкающие шары

Приглашаю в творческю мастерскую идей интерфейса

Есть обширное рабочее пространство. Одни окна лежат поверх других. Есть обычные координаты xгоризонталь и yвертикаль. Также есть zглубина. Слишком глубокие окна тонут и сворачиваются в иконку нижнего моря панели. Слишком близкие окна конкурируют с другими близкими окнами, конкуренты представляются как звёзды в верхней панели небе.

Например я пишу в чате, рисую картину, и играю в сапёра. Все эти окна топовые, они в самом вершу, поэтому это звёзды, звёзды конкурируют, это разные задачи как разные рабочие столы.

Передо мной круглая дверь около изображения, на ней надпись размытие. Я постучал в дверь. Из неё вышли две двери, размыть гаусово, размыть пиксельно, дверь из которой они вышли вывернулась на изнанку и утонула.

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

Я листаю каталоги информация загружается и стенки убегают. Ограниченность оперативки не позволяет мне разогнать все стенки, я какбы в пузыре стенок.

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

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

Но я до этого ясно видел последствия трогания шара в этом векторе, потому что я представлял дальнейшие касания. Это как всё равно как нажать на кнопку.

Прошу не придираться к фантастичности и другому. А приглашаю в мастерскую перлов во имя новых идей !!

Перемещено tazhate из development

Всем более-менее опытным программистам, работавшим с энтерпрайзом, четко известен следующий эмпирический закон:

Девятое Правило Гринспуна, о котором он сознательно предпочел умолчать

Любая более-менее крупная программа на Java или C# является программой на XML

Вобщем, в один прекрасный день, работая на C#, я написал на XML-конфиг некоторых приблуд для UI. Это смотрелось настолько элегантно и красиво, и кастомизировалось настолько проще, по сравнению с обычным хардкодом, что я долго лелеял идею о том чтобы воткнуть подобное еще куда-либо в проект.

Не так давно, такой шанс появился, и я перевел в декларативное описание на XML воркфлоу основных бизнес-процессов системы.

Получилось опять же крайне неплохо, но потом я посидел и подумал.

А что если эти два конфига объединить в один XML?

Ой, стойте, но тогда ведь получается, что туда же можно перенести и разнообразные простые валидаторы и предикаты действий по бизнес-логике? Описание геттеров/сеттеров и простой арифметики - не такое уж сложное занятие, тем более проект и так в System.Reflection по уши.

Черт! Но вообще-то ведь и сложные тоже не проблема - ведь они явлются в 99% случаев не более чем SQL/HQL-запросами, которые никто не мешает хранить в конфигах.

Ух, а ведь если подумать еще - то туда же можно перенести и сами действия по бизнес-логике, не так ли?

Но ведь можно пойти и дальше. Из XML можно вообще-то говоря даже и генерировать модель данных для всей логики системы! И ведь это не просто бредовая идея - такое отчасти давно уже делается стандартными средствами .Net-платформы, например тем же Entity Framework.

И тут я задался вопросом - а зачем нам тогда вообще большая часть кода на C#? Сторонние библиотеки мы ведь точно так же можем вызывать из интерпретатора XML.

Вон оно как все отлично то выходит.

Хм, правда что-то эта модель несколько, скажем так, раздулась.

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

И тут меня осенило. Где-то я это уже видел. Может быть в одной книжке, давно забытой на полке? Или в старой статье семьдесят мохнатого года?

Вспомнив окончательно, я просто расплакался.

Итак:

Вторая Теорема Лавсана

Каждый XML-программист (то есть любой продвинутый java/c#-программист) в конечном итоге доходит до лиспа, просветляется и плачет.

Дискач.

Да, я понимаю, что я школота, хоть и старый пердун и что мне такое не под силу. Но почему-то до меня никто не сделал git branches/commits viewer’a, глядя на который было бы что-то понятно о проекте.

Я хочу чтобы по умолчанию ось времени была по горизонтали. А бранчи и коммиты отображались в стиле https://www.nobledesktop.com/image/gitresources/git-branches-merge.png. При этом расстояние между коммитами было определено временем между ними (чтобы ось времени была действительно осью времени). Тогда гже гуще - сразу видно - велась работа.

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

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

Ну и, конечно, возможность узреть разницу между двумя любыми «нодами» как meld показывает dir-diff. Ну и конечно diff’ы между файлами.

Также пользователь должен иметь возможность задать фильтр, а следом переключиться в обычный, не завязанный на время список коммитов (как в большинстве git viewer’ов).

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

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

Я вообще не представляю с чего начать. Курить SDL? Граф явно придется самому рисовать, во-первых graphviz рисует уродство, а во вторых мне же надо будет соmmit messages рисовать если, например, удаление позволяет. И они должны быть всегда горизонтальными независимо от ротации.

Вообще что взять за UI framework? QT? И там внутри какой-то 2d-canvas? Напоминаю, что это должно быть быстрым (ну конечно при условии, что я не нагорожу алгоритмического огорода).

Посоветуйте, что курить.

Суп, ЛОР. Накатил на свой x230 привычную генту + кде.
Для экономии пространства на экране отказался от панелей (в верхней части экрана остался огрызок с автоскрытием, содержащий трей и часы). Пока не решился переходить на тайловые WM, ибо не готов лишить себя всех плюшек, что даёт KDE из коробки, так что установил скрипт для тайлинга в kwin, и получилось вполне комфортно. Программы запускаю просто начиная печатать на свободном рабочем столе, или нажимая хоткей для вызова krunner.

Иконки/тема: Breeze (пока не надоели)

>>> Просмотр (1366x2304, 1345 Kb)