Суммарно вечеров 10 в ней намотал эпизодами.

1. Началось с видеомонтажа где-то в 2016 году. Оказалось, что тогда на десктопе не было ни одной нормальной софтины чтобы поперетаскивать куски видосов и помонтировать, повырезать. Kdenlive падало в кору, всё остальное выглядело убого и криво. Все вокруг для этого юзали маки. В блендере всё просто идеально, за исключением вырвиглазного интерфейса и вырвимозговых хоткеев и прочей трешанины на стыке человек-машина. Как будто с велосипеда на белаз пересел, нихрена понять невозможно. Блендер как профессиональная софтина жрал примерно всё, сохранял проекты любого размера и рендерил это не давясь в готовый видос через внешний ffmpeg - было хотя-бы предсказуемо.

2. Потом оказалось, что это годная софтина сварганить модельку для 3D-принтера ender-3, там есть даже плагин в коробке который заделывает дырки в моделях, чтобы дальше слайсеры это прожевали. Моделька была успешно напечатана PETG-пластиком и поюзана.

3. Потом оказалось, что в нём можно пытаться рисовать планы куска квартиры для ремонта, пытаться расставлять мебель, оно понимает метры и офигенно всё это рендерить с фотокачеством в фотки и видосы. Можно походить по этой виртуальной хате как в FPS-шутере, записать положение камеры во время этого хождения и потом по записанному положению камеры запустить рендеринг в видос: https://www.youtube.com/watch?v=rVBNgLuaKEQ - всё размыто и дёргается, потому что ставил мало семплов, забыл выключить «бокэ» на линзе камеры и некоторые поверхности были в режиме фигни какой-то, запускать перерендер я уже не могу, на ThinkPad T14 gen 3 один такой кадр несколько секунд… Но если есть желание, можно отточить всё до идеального ray tracing результата с переливами отражений и теней в стеклянных там кубах и прочей фигни.

Я раскрыл 1% возможностей и уже неистово прусь!

Единственное препятствие - нифига не интуитивно, при попытке элементарно поковыряться в носу нужен гугл. Всё сделано достаточно низкоуровнево, типа сишечка в мире 3D-моделирования. Зато после некоторой привычки появляется дофига возможностей делать всякое.

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

Нормально закрывать TCP-коннект между А и Б по инициативе А так:

1. А шлёт FIN («я всё сказал»)
2. Б шлёт FIN + ACK («вас понял, я тоже всё»)
3. А шлёт ACK («вас понял»).

Три вопроса вопроса:

1. Непонятно, зачем посылать FIN на шаге (1), когда можно послать RST и забыть обо всём. Видимо это не экологично: потеря RST приведёт к сохранению коннекта на Б, в сценарии выше (1) можно повторить, если долго не будет (2)?

2. А есть какая-то другая причина, почему после (1) коннекшн ещё остаётся? Может ли Б после получения FIN что-то PUSH в этот коннекшн? Но это бессмысленно, софтина на А уже вызвала close() на сокете.

3. Проводил эксперимент:

1. A - C++ сервер вида «socket();setsetsockopt();bind();listen(port 12345);accept();». Также, в этом сервере написано «По приходу чего-нибудь в коннект, вычитать всё через read() и сразу сделать close(socket)»;
2. Б: «nc 127.0.0.1 12345»
3. Б что-то PUSH в коннекшн (печатаю в nc рандомную строку, жму enter), A это вычитывает из сокета и делает сразу close(socket);
4. В tcpdump видно, как от А к Б прилетает FIN + ACK. Зачем тут ACK? ACK на PUSH прилетело пакетом ранее….
5. В ответ на FIN от Б прилетает один ACK, как будто nc не собирается закрывать. Всмысле? Какой смысл тут не хотеть закрывать?
6. Ввожу в nc ещё одну строку, отправляю (от Б летит PUSH + ACK). Зачем тут опять ack?
7. От A приходит RST. Это уже выглядит как «слыш ты кто»?