The OpenNET Project / Index page

[ новости /+++ | форум | теги | ]



Вариант для распечатки  
Пред. тема | След. тема 
Форум Разговоры, обсуждение новостей
Режим отображения отдельной подветви беседы [ Отслеживать ]

Оглавление

Анализ проблем с GPL у бизнес-модели Red Hat , opennews (??), 25-Июн-23, (0) [смотреть все]

Сообщения [Сортировка по времени | RSS]


230. "Анализ проблем с GPL у бизнес-модели Red Hat "  +/
Сообщение от Аноним (204), 26-Июн-23, 20:42 
Конкретизируй. Что такое "более-менее сложной области"? В чем заключается R&D? Мне почему-то вспоминаются только патенты на мышки, алгоритм сжатия Люмпеля-Зива-Велча и jpeg за которые дрючили софтописателей пока сроки патентов на них не истекли и не придумали другие алгоритмы. Сейчас они никому не нужны, и честно говоря эти алгоритмы не rocket science. Всё на уровне студенческих курсовиков и задачек из книжек Д.Кнута. Объективно это современный вариант средневековой цеховщины, когда какие-то секреты мастерства передавались от отца к сыну или от мастера подмастерью.
И главное - на кой мне какому-то хамоватому анониму давать преференции? Не обижайся, но богатым клиентам за сотни миллионов ты ничего не продашь. Иначе бы ты тут не сидел.
Ответить | Правка | Наверх | Cообщить модератору

232. "Анализ проблем с GPL у бизнес-модели Red Hat "  +/
Сообщение от Аноним (198), 26-Июн-23, 21:04 
> Что такое "более-менее сложной области"?

Какая-нибудь физика плазмы, молекулярная биология, lossless-сжатие аудио и видео в рилтайме с качеством в разы выше на данный момент имеющегося + автокоррекция ошибок (чтобы 4K видео с 6канальным звуком передавалось по обычному модему на 33600 бод в обе стороны без задержек) и так далее. На твое усмотрение, короче.

> В чем заключается R&D?

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

> Мне почему-то вспоминаются только патенты на мышки, алгоритм сжатия Люмпеля-Зива-Велча и jpeg за которые дрючили софтописателей пока сроки патентов на них не истекли и не придумали другие алгоритмы.

Мне вспоминаются многолетние рыдания на тему как бы мы классно какую-нибудь штуку из какого-нибудь MPEG скопипастили, но нельзя. А сами придумать что-то получше неспособны в принципе (история Theora и VP8/VP9 как бы намекает).

> И главное - на кой мне какому-то хамоватому анониму давать преференции?

Ну ты же заявил что патенты не нужны и Public Domain рулит. Неужели нет желания бесплатно потрудиться на общее благо ради подтверждения собственного тезиса?

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

Just for lulz, чувак.

Ответить | Правка | Наверх | Cообщить модератору

235. "Анализ проблем с GPL у бизнес-модели Red Hat "  +/
Сообщение от Аноним (204), 26-Июн-23, 21:58 
Не вижу постановки задачи. Так, один трёп. По поводу физики и биологии ничего не скажу.
А по аудио-видео - существующие алгоритмы сжатия уже подошли к теоретическому пределу. "В разы лучше" сделать физически невозможно.
Опять-таки не вижу причин тратить время и силы на твои хотелки.

> Ну ты же заявил что патенты не нужны и Public Domain рулит. Неужели нет желания бесплатно потрудиться на общее благо ради подтверждения собственного тезиса?

Не путай общее благо и свой карман. Общедоступная наука, образование, знание, ПО - это общее благо для всех.
А желание что-то продавать за "сотни миллионов" - это нечто прямо противоположное, противопоставление узкокорыстных интересов обществу. Слышали мы эти байки про эффективных собственников, что разбогатеют и начнут производство с наукой развивать. Никак за 30 лет не нажрутся.

Сейчас, благодаря конкуренции и проекту GNU, c софтом всё более-менее хорошо. Есть дешёвые и даже бесплатные ОС, браузеры, текстовые редакторы, компиляторы, БД и прочее. Шароварщики пропали как класс. А совсем недавно, 20-30 лет назад практически всё было платное.

И не надо передёргивать. Я говорил, что патенты на софт вредны. И про Pubic Domain я говорил в контексте науки и математических алгоритмов. Свой код автор может лицензировать как хочет.

Ответить | Правка | Наверх | Cообщить модератору

238. "Анализ проблем с GPL у бизнес-модели Red Hat "  +/
Сообщение от Аноним (198), 26-Июн-23, 22:17 
Так и запишем: халявы этот анонимус хочет, а предоставлять ее самому - категорически нет. Предсказуемо, чоужтам.
Ответить | Правка | Наверх | Cообщить модератору

244. "Анализ проблем с GPL у бизнес-модели Red Hat "  +/
Сообщение от Аноним (204), 26-Июн-23, 22:49 
Вы мне приписываете собственные грязные мысли. Посмотрите в зеркало.
Ответить | Правка | Наверх | Cообщить модератору

248. "Анализ проблем с GPL у бизнес-модели Red Hat "  +/
Сообщение от Аноним (198), 26-Июн-23, 22:58 
С фига ли? Я не проповедую отмену патентов и всеобщий Public Domain. Или в следующий раз мне теги <сарказм> и <доведение до абсурда> нужно прописывать в явном виде?
Ответить | Правка | Наверх | Cообщить модератору

281. "Анализ проблем с GPL у бизнес-модели Red Hat "  +1 +/
Сообщение от Аноним (281), 27-Июн-23, 02:27 
> По поводу физики и биологии ничего не скажу.

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

> А по аудио-видео - существующие алгоритмы сжатия уже подошли к теоретическому пределу.

А вот это уже интересно, нельзя ли зацитировать теорию описывающую предел?

> "В разы лучше" сделать физически невозможно.

Да вообще-то можно супер-эффективное сжатие. Смотрите, magnet-ссыль содержит лишь 20 байтов хеша, но он уникально идентифицирует конкретный мувик. А то что словарь для декомпрессии великоват... ну... мало ли чего... зазеркальте пиратскую бухту и сможете декомпресить ссылки в многогиговые файлы, где взять столько дисков - ваши проблемы :)))

> собственников, что разбогатеют и начнут производство с наукой развивать. Никак за
> 30 лет не нажрутся.

Однако если посмотреть в каком виде оказываются объекты без собственника...

Ответить | Правка | К родителю #235 | Наверх | Cообщить модератору

314. "Анализ проблем с GPL у бизнес-модели Red Hat "  +/
Сообщение от Аноним (204), 27-Июн-23, 18:58 
> А вот это уже интересно, нельзя ли зацитировать теорию описывающую предел?

Это очевидное следствие из алгоритмов сжатия.
Есть такое понятие - энтропия. Чем она выше, тем хуже файл сжимается. Классические алгоритмы, тот же LZW создают словарь повторяющихся строк и заменяют их на код этой строки в словаре, который короче этой строки.
В сжатом файле энтропия всегда выше чем в исходном. Но энтропия не может увеличиваться до бесконечности. В случано сгенерированной последовательности байтов энтропия максимальна. Поэтому текстовые файлы сжимаются хорошо, бинарные хуже, а созданный генератором случайных чисел набор байтов - хуже всех. И поэтому же при сжатии уже архивированных файлов они очень плохо сжимаются, а на 2-3 итерации размер архива начнет расти - из-за заголовка архива и всякой служебной информации.
Вот первая же ссылка нагуглилась: https://habr.com/ru/articles/181045/

Ответить | Правка | Наверх | Cообщить модератору

330. "Анализ проблем с GPL у бизнес-модели Red Hat "  +/
Сообщение от Аноним (-), 28-Июн-23, 02:43 
> Это очевидное следствие из алгоритмов сжатия.

Теория не может быть следствием из алгоритмов сжатия.

> Есть такое понятие - энтропия. Чем она выше, тем хуже файл сжимается.

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

> Классические алгоритмы, тот же LZW

Не надо мне рассказывать что я знаю, я даже кодил LZ unpacker'ы лично. Но раз вы такой умный вы можете рассказть как оценить энтропию "в этом мувике" для начала. Чтобы понять расстояние от теоретического предела. Более того - пойнт lossy сжатия в том что оно часть информации теряет, но человек это не замечает, или не очень замечает. Это несколько меняет правила игры.

> В сжатом файле энтропия всегда выше чем в исходном. Но энтропия не может увеличиваться
> до бесконечности.

И вы конечно же сформулируете какой-то осмысленный верхний предел, показав что он и правда близок к тому что есть?

А то насколько я вижу, современные кодеки как раз более-менее прокачали удаление избыточности и пришли к тому что опробование наилучших вариантов как это делать и их комбо требует неслабо так времени на кодирование при котором пытаются понять наилучшие из вариантов как кодировать. Вы же понимаете что есть много способов даже получить битовый поток дающий идентичный результат при декодировании. У LZ-like даже есть такое понятие как Optimal Parsing, но эта задача полностью и честно решаема только для самых тривиальных форматов типа LZ4. В более сложных и фичастых оптимальный парсинг вообще нереально сделать за разумное время. В лучшем случае бывает приблизительная эвристика. А уж современные форматы видеокодеков - заведомо в субоптимальном режиме кодируют, отбрасывая большую часть пространства поиска эвристикой, и даже так это очень медленно.

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

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

> Вот первая же ссылка нагуглилась: https://habr.com/ru/articles/181045/

Вопросы были более конкретные и предметные, про оценку энтропии в видео и как оценили близость. Нет, статьями для нубов не отделаетесь - я как раз в теме.

Ответить | Правка | Наверх | Cообщить модератору

315. "Анализ проблем с GPL у бизнес-модели Red Hat "  +/
Сообщение от Аноним (204), 27-Июн-23, 19:03 
> Да вообще-то можно супер-эффективное сжатие. Смотрите, magnet-ссыль содержит лишь 20 байтов хеша

Некорректное утверждение. Расчет хеша, контрольной суммы - это не сжатие.
Это всё равно что сказать: URL - это сжатый сайт, а строка, содержащая путь к файлу на диске равно архиву файла.

Ответить | Правка | К родителю #281 | Наверх | Cообщить модератору

332. "Анализ проблем с GPL у бизнес-модели Red Hat "  +/
Сообщение от Аноним (-), 28-Июн-23, 02:48 
> Некорректное утверждение. Расчет хеша, контрольной суммы - это не сжатие.

Ну как, это мухлевание с словарем :). Очень большим слованем, размером с весь контент TPB :). И вы можете возразить, но brotli мухлюет примерно так же: у него встроеный словарь на этак примерно 120 кило хлама, во ВСЕХ реализациях. Выжимка из типовых конструкций веба. И поскольку этот хлам уже есть у всех клиентов - его не надо передавать, можно только ссылку на него передать. И это по общей идее процесса не настолько уж и отличается. Вон то просто чуть более масштабная и глобальная версия идеи. Правда хранить словарь такого размера очень напряжно.

Ответить | Правка | Наверх | Cообщить модератору

Архив | Удалить

Рекомендовать для помещения в FAQ | Индекс форумов | Темы | Пред. тема | След. тема




Партнёры:
PostgresPro
Inferno Solutions
Hosting by Hoster.ru
Хостинг:

Закладки на сайте
Проследить за страницей
Created 1996-2024 by Maxim Chirkov
Добавить, Поддержать, Вебмастеру