Linux

[Timiriliyev]

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

В этом есть великий смысл.

Ну а пользовательский софт (всякие браузеры, гимпы, офисы и иже с ними) так и так обновляют, если версии библиотек позволяют.

[СНовосиба]

Linux работает и пусть себе работает. Мне пофиг, как он это делает.

Так ведь плохо работает. Без правки текстовых файлов в консольном редакторе и копипаста команд в терминал практически ничего сделать нельзя.

[wandrien]

Так ведь плохо работает.

Сделай лучше.

[СНовосиба]

Каким таким еще "выпускам дистрибутива"?

Мы про Линукс, а не про Арч.

[wandrien]

Каким таким еще "выпускам дистрибутива"?

Мы про Линукс, а не про Арч.

Ах, ты про ядро. У ядра стабильное API. 

[Timiriliyev]

копипаста команд в терминал

Для инструкций терминал самое то. Виндовое "нажмите эту кнопку, потом ту" с прилагающимися скриншотами это адок.

[Toman]

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

Это зависит от политики, принятой авторами конкретного дистрибутива по отношению к конкретным программам. В большинстве случаев в дистрибутивах для обычного пользователя стремятся к тому, чтобы по возможности не сломать обновлением на недостаточно проверенные версии, а срочно проталкивать только исправления дыр безопасности или просто очевидных ошибок. Хотя иногда бывают и косяки, когда, например, полтора-два года в репе стоит старая версия программы, которая - не знаю, у всех ли или только у меня - вообще неработоспособна, поскольку при любой попытке открыть файл тут же грохается сегфолтом. Ну, это был такой единичный случай, тогда пришлось долго и нудно собирать из сорцов как раз ту программу, из-за которой я, собственно, и переходил второй раз на линукс (FontForge в Убунте).

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

Если в юниксах в 2019 не осилили GUI-интерфейсы, работающие не через временные файлы, каналы и прочую ересь, а через API

В юниксах GUI изначально делались как в общем случае сетевые (другой вопрос, что потом всё это с распространением в основном настольных ПК де-факто несколько похерили (в чём, однако, значительная доля вины как раз массово пришедших в юниксы виндовых программистов) - однако ж и пропускная способность сетевых каналов сейчас бывает довольно неплохой), чтобы не нужно было фигачить отдельные программы для "удалённых рабочих столов" и всякого такого. Про идею совать графический интерфейс в общесистемый API - это вообще атас. 1) Зачем эта нагрузка программам и целым системам, в которых нет никакой графики, 2) чем лучше это ваше жёстковстроенное GUI с на порядок меньшими возможностями настроек внешнего вида, поведения и прочего, 3) зачем вообще множить сущности (фигурирующие в общесистемном API) без необходимости? Через "временные файлы, каналы и прочую ересь" можно при необходимости передавать информацию любого рода и назначения - и именно поэтому они используются. Именно в этом, в абстракции от конкретных железок и присущих им форматов данных в пользу более универсальных объектов, и была, в основном, инновация юниксов, обеспечившая им популярность, но которую некоторые, как можно видеть, так и не поняли (пусть и с некоторым оправданием для некоторых не понявших в виде сурового детства на недоделанных компьютерах), и остаются своим пониманием и практикой в парадигме как раз даже не 70-х, на которые вы ссылаетесь, а ажно 60-х и даже конца 50-х, с привязкой сущностных понятий операционки и её базового API к конкретной периферии конкретных машин и вообще ко всему железоспецифичному, к чему только можно.

[Hellerick]

Linux работает и пусть себе работает. Мне пофиг, как он это делает.

Так ведь плохо работает. Без правки текстовых файлов в консольном редакторе и копипаста команд в терминал практически ничего сделать нельзя.

«Ничего» — это что?
Повторюсь, я этими копипастингом в терминал занимаюсь при пакетном кодировании видео.
Или, например, при пакетном концертировании .svg-картинок в растровые.
То есть ровно в тех ситуациях, когда под Windows я бы сидел и составлял .bat-файл.
Зачем еще это может понадобиться?

[4fzbl]

В линуксе же весь софт обновляется автоматически из своих реп.

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

В Линуксе софт не обновляется вообще (кроме фаерфокса) - для этого нужно переустанавливать всю систему целиком.

Вирусов под Виндоус нет уже очень давно, со времен Висты. Антивирус не нужен.

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

[4fzbl]

У меня в линуксе трудностей с кодеками не возникало вообще.

Ставь openSUSE, познай боль.

Да пробовал

[4fzbl]

Простой юзер не знает команд линукса

За каким чертом в операционной системе нужны "команды", "оболочки", и прочий привет из 70-х? Если в юниксах в 2019 не осилили GUI-интерфейсы, работающие не через временные файлы, каналы и прочую ересь, а через API, это не проблема пользователя.

В старой Убунте завезли интеграцию через dbus и кнопки повышения полномочий, но через пару лет все поломали. Что за отношение к пользователям?

В нормальных линуксах, таких как Убунту и Андройд, команды и не нужны

[СНовосиба]

2) чем лучше это ваше жёстковстроенное GUI с на порядок меньшими возможностями настроек внешнего вида, поведения и прочего

Через "временные файлы, каналы и прочую ересь" можно при необходимости передавать информацию любого рода и назначения

Почему оно "жестковстроенное"?

Через файлы и каналы в основном передается текст, который заново парсится программой, вместо объектов в машинном представлении. Контролировать процесс передачи также невозможно, если протокол обмена этого не предусматривает. Почему строки, числа, списки, структуры в 2019 году нельзя передавать как строки, списки и структуры, а не текст, и не возиться с парсингом, экранированием пробелов и т.п.?

[wandrien]

Почему строки, числа, списки, структуры в 2019 году нельзя передавать как строки, списки и структуры, а не текст, и не возиться с парсингом, экранированием пробелов и т.п.?

Передавайте. Не возитесь.
Я вам разрешаю.

[Bhudh]

Почему строки, числа, списки, структуры в 2019 году нельзя передавать как строки, списки и структуры, а не текст, и не возиться с парсингом, экранированием пробелов и т.п.?

Почему нельзя? Сейчас, наоборот, JSON во все поля.

[Lodur]

Не попадалось еще файла, который mpv не воспроизводит.
В винде нет mpv, но есть MPC-HC и VLC - они такие же самостоятельные полноценные приложения, как mpv в линуксе.

Так что паритет.

Этот ваш mpv умеет правильно обрабатывать все фичи матрёшки? Из виндусовых плееров (как бесплатных, так и платных, кстати), всё умеет только MPC и его форки (MPC-HC, MPC-BE). Если умеет - это круто, да.

[wandrien]

Не попадалось еще файла, который mpv не воспроизводит.
В винде нет mpv, но есть MPC-HC и VLC - они такие же самостоятельные полноценные приложения, как mpv в линуксе.

Так что паритет.

Этот ваш mpv умеет правильно обрабатывать все фичи матрёшки? Из виндусовых плееров (как бесплатных, так и платных, кстати), всё умеет только MPC и его форки (MPC-HC, MPC-BE). Если умеет - это круто, да.

Не знаю таких подробностей. Какие фичи, например?

[Lodur]

Какие фичи, например?

Например, встраивание видео (и прочих связанных дорожек) из внешнего файла в произвольное место данного. С корректной обработкой остальных дорожек (звук, субтитры). Например, есть релизы сериалов, где опенинг и эндинг, повторяющиеся во всех сериях, закодированы отдельно (с лучшим качеством), представляют собой два отдельных файла матрёшки, и подключаются к каждой серии "на лету", вставляясь в нужные места каждой серии.
Правильная обработка меню с наборами дорожек из содержащихся в матрёшке. Например, у нас есть перевод аниме на английский в виде субтитров, два перевода на русский в виде субтитров, и два перевода на русский в виде озвучки на основе этих субтитров. Мы кидаем в матрёшку две звуковые дорожки в дополнение к оригинальной, плюс пять файлов субтитров - английские, два русских, два русских урезанных (только переводы надписей и караоке-переводы песен), плюс шрифты, используемые в субтитрах. Делаем меню: 1) Первая русская дорожка + первые урезанные субтитры (по дефолту), 2) вторая русская дорожка + вторые урезанные субтитры, 3) японская дорожка и первые полные русские субтитры, 4) японская дорожка и вторые полные русские субтитры, 5) японская дорожка и английские субтитры, (можно ещё 6) просто видео и японская дорожка - вдруг японец скачает, ему никакие субтитры не нужны, только мешать будут). Всё должно переключаться на лету из контекстного меню плеера (или парсера mkv).

[wandrien]

Какие фичи, например?

Например, встраивание видео (и прочих связанных дорожек) из внешнего файла в произвольное место данного. С корректной обработкой остальных дорожек (звук, субтитры). Например, есть релизы сериалов, где опенинг и эндинг, повторяющиеся во всех сериях, закодированы отдельно (с лучшим качеством), представляют собой два отдельных файла матрёшки, и подключаются к каждой серии "на лету", вставляясь в нужные места каждой серии.
Правильная обработка меню с наборами дорожек из содержащихся в матрёшке. Например, у нас есть перевод аниме на английский в виде субтитров, два перевода на русский в виде субтитров, и два перевода на русский в виде озвучки на основе этих субтитров. Мы кидаем в матрёшку две звуковые дорожки в дополнение к оригинальной, плюс пять файлов субтитров - английские, два русских, два русских урезанных (только переводы надписей и караоке-переводы песен), плюс шрифты, используемые в субтитрах. Делаем меню: 1) Первая русская дорожка + первые урезанные субтитры (по дефолту), 2) вторая русская дорожка + вторые урезанные субтитры, 3) японская дорожка и первые полные русские субтитры, 4) японская дорожка и вторые полные русские субтитры, 5) японская дорожка и английские субтитры, (можно ещё 6) просто видео и японская дорожка - вдруг японец скачает, ему никакие субтитры не нужны, только мешать будут). Всё должно переключаться на лету из контекстного меню плеера (или парсера mkv).

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

Судя по этому - https://github.com/mpv-player/mpv/issues/3073 - часть возможностей поддерживается, часть нет.

[Lodur]

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

Судя по этому - https://github.com/mpv-player/mpv/issues/3073 - часть возможностей поддерживается, часть нет.

Ну, вот, например, у этой релиз-группы встраиваемые опенинг и эндинг во многих релизах:
https://coalgirls.wakku.to/
Скачал первую серию, первый опенинг и первый эндинг их релиза Ovarimonogatari. Таки да: с этими файлами (опенинга и эндинга) в одной папке с файлом серии они воспроизводятся в нужных местах, если убрать - их нет.

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

Насчёт меню - я сам такие делал, когда был в одной релиз-группе, но её уже нет... Старые релизы у меня лежали, но погибли вместе с жёстким диском. Надо будет полазить где-нибуть на Т.ру, поискать. Как время будет - поищу.

[Hellerick]

Очень не люблю, когда такой кройкой и шитьем занимаются.
Потом файлы не переименовать, не перекодировать для просмотра на другом устройстве.

[Lodur]

Очень не люблю, когда такой кройкой и шитьем занимаются.
Потом файлы не переименовать, не перекодировать для просмотра на другом устройстве.

Зато видео они хорошее делали.

[Hellerick]

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

[Lodur]

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

Под "хорошим" я понимаю видео с наименьшей потерей качества картинки по сравнению с оригиналом. Это ж пережатые блюреи с намного меньшим битрейтом. Можно, конечно, качать BD-ремуксы, там вообще видео оригинальное идёт, но лично у меня столько места нет.

[Hellerick]

Я для родителей постоянно кино качаю. Они мне составляют списки жалемых фильмов, я их нахожу по возможности в качестве 1080p, если нужно -- склеиваю, перекодирую в стандартный формат со стандартным кодеком, оставляю только русскую звуковую дорожку, если нужно -- прожигаю субтитры. Потом еще даю всем файлам единообразные названия. В среднем гигабайта 4-5 на фильм получается. Артефактов сжатия не замечаю.
Мне такой процесс униформизации нравится. Сейчас вот на переносном винчестере лежит 21 фильм готовый к просмотру.
Хотелось бы такие стандартизированные фильмы потом куда-нибудь выкладывать. Но приходится после просмотра удалять.

[Timiriliyev]

Сейчас идёт бурное развитие кодеков для сжатия видео, да и аудио тоже. H.265 и VP9 уже успели устареть, выкатили новый AV1. Фантастическое качество при фантастически низком битрейте. Вот бы только часов в сутках больше для рендера, а у зрителя оборудование для просмотра мощнее.