Re: [devel] libjpeg7 - пора?

Re: [devel] libjpeg7 - пора?

[Konstantin Pavlov]

[-- Attachment #1: Type: text/plain, Size: 359 bytes --]

On Sun, Aug 23, 2009 at 05:23:33PM +0300, Victor Forsyuk wrote:
> http://trac.imagemagick.org/browser/jpeg/trunk/change.log
> 
> Рано или поздно перейдем. Предлагаю задуматься о том, не начать ли движение
> уже сейчас...

Пора!

-- 
> мухи и котлеты будут отдельно летать над ним ;)
С alterator даже котлеты будут летать! :)
		-- legion in devel@

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 197 bytes --]

Re: [devel] libjpeg7 - пора?

[Andrey Rahmatullin]

[-- Attachment #1: Type: text/plain, Size: 883 bytes --]

On Sun, Aug 23, 2009 at 05:23:33PM +0300, Victor Forsyuk wrote:
> Рано или поздно перейдем. Предлагаю задуматься о том, не начать ли движение
> уже сейчас...
Мне кажется, или если пересобирать по частям, то в куче клиентов некоторое
время будут и старая, и новая либы? Больно популярная либа.

-- 
WBR, wRAR (ALT Linux Team)
Powered by the ALT Linux fortune(6):

<roman-> "Размещение серверов на кораблях дает ряд важных преимуществ.
         Во-первых, питаясь от обычной электрической сети в обычное время, во
         время перебоев с энергоснабжением сервера будут работать от
         корабельного дизеля, обеспеченного запасами топлива в баках на месяц
         автономного тарахтения, что позволяет IDS давать откровенно вызывающие
         своей избыточностью гарантии стрессо-устойчивости оборудования. "
<gns> roman-: "что случилось с сайтом? - он утонул"

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 489 bytes --]

Re: [devel] libjpeg7 - пора?

[Alexander Bokovoy]

2009/8/23 Victor Forsyuk <force@altlinux.org>:
>
> http://trac.imagemagick.org/browser/jpeg/trunk/change.log
>
> Рано или поздно перейдем. Предлагаю задуматься о том, не начать ли движение
> уже сейчас...
Поскольку я проводил исследование на работе по переходу на libjpeg7,
то поделюсь результатами.
1. ABI иное. Нужна пересборка.
2. API отличается в месте загрузки с одновременным масштабированием. В
jpeg7 можно указывать более широкий диапазон коэффициентов для
масштабирования и это "выбивает" некоторые приложения. В частности,
сломался gdk pixbuf jpeg loader так, что при определенных сочетаниях
исходного файла и запрашиваемого разрешения получается мусор вместо
картинки. Чинится однострочным патчем.
3. Скорость новых оптимизированных DCT и iDCT на современных
процессорах уступает на 10-15% "неоптимизированным" вариантам из
jpeg6b. Серьезную роль в этой разнице играет организация предсказания
переходов и использование кэшей первого-второго уровней в современных
процессорах. Проигрыш одинаково заметен на x86 и ARM.  Математические
оптимизации в jpeg7, направленные на уменьшение количества умножений,
оказываются невыгодными для современных процессорных архитектур,
особенно с использованием векторных инструкций -- массовые параллелизм
с умножениями обходится дешевле провалов по спекулятивному
предсказанию переходов.
4. Оба варианта jpeg6b и jpeg7 проигрывают по скорости
SIMD-оптимизациям jpeg6b от скромных японцев. Оптимизированный вариант
в среднем в 2-3 раза быстрее jpeg6b. Все они на ARM проигрывают
специализированым кодекам и декодерам на DSP (jpeg6b -- в среднем в
4-4.5 раза). Думаю, что аналогичный проигрыш и на Cell B.E. На
x86/x86_64 без использования GPU явно выгодно использовать
векторизацию, чем новые математически оптимальные алгоритмы. С GPU не
все очевидно, потому что синхронизацию памяти для CPU/GPU никто не
отменял.

-- 
/ Alexander Bokovoy

Re: [devel] libjpeg7 - пора?

[Dmitry V. Levin]

[-- Attachment #1: Type: text/plain, Size: 312 bytes --]

On Sun, Aug 23, 2009 at 05:23:33PM +0300, Victor Forsyuk wrote:
> http://trac.imagemagick.org/browser/jpeg/trunk/change.log
> 
> Рано или поздно перейдем. Предлагаю задуматься о том, не начать ли движение
> уже сейчас...

Задумался.  Есть ли у нас сейчас силы бежать впереди этого паровоза?


-- 
ldv

[-- Attachment #2: Type: application/pgp-signature, Size: 197 bytes --]

Re: [devel] libjpeg7 - пора?

[Денис Смирнов]

[-- Attachment #1: Type: text/plain, Size: 2283 bytes --]

On Sun, Aug 23, 2009 at 09:53:13PM +0300, Alexander Bokovoy wrote:

Прошел почти год. Так что у нас будет с libjpeg? :)

 AB> Поскольку я проводил исследование на работе по переходу на libjpeg7,
 AB> то поделюсь результатами.
 AB> 1. ABI иное. Нужна пересборка.
 AB> 2. API отличается в месте загрузки с одновременным масштабированием. В
 AB> jpeg7 можно указывать более широкий диапазон коэффициентов для
 AB> масштабирования и это "выбивает" некоторые приложения. В частности,
 AB> сломался gdk pixbuf jpeg loader так, что при определенных сочетаниях
 AB> исходного файла и запрашиваемого разрешения получается мусор вместо
 AB> картинки. Чинится однострочным патчем.
 AB> 3. Скорость новых оптимизированных DCT и iDCT на современных
 AB> процессорах уступает на 10-15% "неоптимизированным" вариантам из
 AB> jpeg6b. Серьезную роль в этой разнице играет организация предсказания
 AB> переходов и использование кэшей первого-второго уровней в современных
 AB> процессорах. Проигрыш одинаково заметен на x86 и ARM.  Математические
 AB> оптимизации в jpeg7, направленные на уменьшение количества умножений,
 AB> оказываются невыгодными для современных процессорных архитектур,
 AB> особенно с использованием векторных инструкций -- массовые параллелизм
 AB> с умножениями обходится дешевле провалов по спекулятивному
 AB> предсказанию переходов.
 AB> 4. Оба варианта jpeg6b и jpeg7 проигрывают по скорости
 AB> SIMD-оптимизациям jpeg6b от скромных японцев. Оптимизированный вариант
 AB> в среднем в 2-3 раза быстрее jpeg6b. Все они на ARM проигрывают
 AB> специализированым кодекам и декодерам на DSP (jpeg6b -- в среднем в
 AB> 4-4.5 раза). Думаю, что аналогичный проигрыш и на Cell B.E. На
 AB> x86/x86_64 без использования GPU явно выгодно использовать
 AB> векторизацию, чем новые математически оптимальные алгоритмы. С GPU не
 AB> все очевидно, потому что синхронизацию памяти для CPU/GPU никто не
 AB> отменял.
 AB> 
 AB> -- 
 AB> / Alexander Bokovoy
 AB> _______________________________________________
 AB> Devel mailing list
 AB> Devel@lists.altlinux.org
 AB> https://lists.altlinux.org/mailman/listinfo/devel
-- 
С уважением, Денис

http://mithraen.ru/
----------------------------------------------------------------------------

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 198 bytes --]

Re: [devel] libjpeg7 - пора?

[Motsyo Gennadi aka Drool]

05.07.2010 18:14, Victor Forsiuk пишет:
> Нового libjpeg у нас в обозримом будущем не будет. Это очевидно чуть более
> чем полностью.
> 
> В свете же выпуска LTS релизов остается только очень сильно надеятся на то,
> что в ближайшие годы мейнстримные дистрибутивы будут раскачиваться и
> окончательно переключатся на новую libjpeg не так скоро. И, соответственно,
> до наступления end-of-life нашего LTS дистра арифметическое кодирование не
> станет массовым.
> 
> Напомню, libjpeg-6b не умеет arithmetic coding и такие джипеги просто не
> сможет декодировать.

	Тут мелькнула информация про такой проект:

http://libjpeg-turbo.virtualgl.org/

	Утверждается, что библиотека совместима по API и ABI с стандартной
libjpeg 6b и может быть установлена вместо обычной дистрибутивной
libjpeg для получения 50% и более выигрыша в производительности
обработки JPEG изображений.

Re: [devel] libjpeg7 - пора?

[Valery V. Inozemtsev]

[-- Attachment #1: Type: text/plain, Size: 2932 bytes --]

В Пнд, 05/07/2010 в 21:17 +0300, Motsyo Gennadi aka Drool пишет:
> 05.07.2010 18:14, Victor Forsiuk пишет:
> > Нового libjpeg у нас в обозримом будущем не будет. Это очевидно чуть более
> > чем полностью.
> > 
> > В свете же выпуска LTS релизов остается только очень сильно надеятся на то,
> > что в ближайшие годы мейнстримные дистрибутивы будут раскачиваться и
> > окончательно переключатся на новую libjpeg не так скоро. И, соответственно,
> > до наступления end-of-life нашего LTS дистра арифметическое кодирование не
> > станет массовым.
> > 
> > Напомню, libjpeg-6b не умеет arithmetic coding и такие джипеги просто не
> > сможет декодировать.
> 
> 	Тут мелькнула информация про такой проект:
> 
> http://libjpeg-turbo.virtualgl.org/

$ rpmquery -i libjpeg-turbo
Name        : libjpeg-turbo                Relocations: (not
relocatable)
Version     : 1.0.0                             Vendor: ALT Linux Team
Release     : alt1                          Build Date: Сбт 03 Июл 2010
17:36:41
Install date: Сбт 03 Июл 2010 17:39:56      Build Host:
shrek.hasher.altlinux.org
Group       : Система/Библиотеки   Source RPM:
libjpeg-turbo-1.0.0-alt1.src.rpm
Size        : 281271                           License: distributable
Packager    : Valery Inozemtsev <shrek@altlinux.ru>
URL         : http://libjpeg-turbo.virtualgl.org/
Summary     : A library for manipulating JPEG image format files
Description :
libjpeg-turbo is a high-speed version of libjpeg for x86 and x86-64
processors
which uses SIMD instructions (MMX, SSE2, etc.) to accelerate baseline
JPEG
compression and decompression. libjpeg-turbo is generally 2-4x as fast
as the
unmodified version of libjpeg, all else being equal.

> 	Утверждается, что библиотека совместима по API и ABI с стандартной
> libjpeg 6b

совместима, rpmsodiff приводить не буду

>  и может быть установлена вместо обычной дистрибутивной
> libjpeg

и установлена

>  для получения 50% и более выигрыша в производительности
> обработки JPEG изображений.

от 50%. по тестам местами и больше

> _______________________________________________
> Devel mailing list
> Devel@lists.altlinux.org
> https://lists.altlinux.org/mailman/listinfo/devel

-- 
Valery V. Inozemtsev

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 198 bytes --]

Re: [devel] libjpeg7 - пора?

[Motsyo Gennadi aka Drool]

05.07.2010 21:33, Valery V. Inozemtsev пишет:
> $ rpmquery -i libjpeg-turbo
...
> совместима, rpmsodiff приводить не буду
...
> и установлена
...
> от 50%. по тестам местами и больше

	Э...

[drool@drool ~]$ ssh git.alt task ls --done --all | grep turbo
Enter passphrase for key '/home/drool/.ssh/id_dsa':
[drool@drool ~]$

	Но ничего не находится... Пока?

Re: [devel] libjpeg7 - пора?

[Valery V. Inozemtsev]

[-- Attachment #1: Type: text/plain, Size: 1005 bytes --]

В Пнд, 05/07/2010 в 21:57 +0300, Motsyo Gennadi aka Drool пишет:
> 05.07.2010 21:33, Valery V. Inozemtsev пишет:
> > $ rpmquery -i libjpeg-turbo
> ...
> > совместима, rpmsodiff приводить не буду
> ...
> > и установлена
> ...
> > от 50%. по тестам местами и больше
> 
> 	Э...
> 
> [drool@drool ~]$ ssh git.alt task ls --done --all | grep turbo
> Enter passphrase for key '/home/drool/.ssh/id_dsa':
> [drool@drool ~]$
> 
> 	Но ничего не находится...

http://ftp.altlinux.org/pub/people/shrek/gnome/i586/RPMS.hasher/libjpeg-turbo-1.0.0-alt1.i586.rpm

для x86_64 заменить i586 на x86_64

> Пока?

это не мне решать, там либо libjpeg-6b либо libjpeg-turbo-1.0.0

> _______________________________________________
> Devel mailing list
> Devel@lists.altlinux.org
> https://lists.altlinux.org/mailman/listinfo/devel

-- 
Valery V. Inozemtsev

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 198 bytes --]

Re: [devel] libjpeg7 - пора?

[Alexander Bokovoy]

Hi,

2010/7/5 Victor Forsiuk <force@altlinux.org>
>
>
> 2010/5/8 Денис Смирнов <mithraen@altlinux.ru>
>>
>> On Sun, Aug 23, 2009 at 09:53:13PM +0300, Alexander Bokovoy wrote:
>>
>> Прошел почти год. Так что у нас будет с libjpeg? :)
>
> Нового libjpeg у нас в обозримом будущем не будет. Это очевидно чуть более чем полностью.
>
> В свете же выпуска LTS релизов остается только очень сильно надеятся на то, что в ближайшие годы мейнстримные дистрибутивы будут раскачиваться и окончательно переключатся на новую libjpeg не так скоро. И, соответственно, до наступления end-of-life нашего LTS дистра арифметическое кодирование не станет массовым.
>
> Напомню, libjpeg-6b не умеет arithmetic coding и такие джипеги просто не сможет декодировать.
>
> В чем плюс арифметического кодирования для пользователя - он создает файлы меньшего размера. Заметно меньшего. На мой взгляд, это с лихвой перевешивает некоторое отставание в скорости новых алгоритмов. В реальной жизни мы получим более быстрое открытие файлов - уменьшение времени считывания с диска с лихвой перекрывает чуть более медленное декодирование. Про загрузку по сети я уж вообще молчу...
>
Основная проблема с libjpeg7 -- состояние разработки в апстриме.
Фактически, имеющаяся модель разработки (периодически выкладываем срез
внутреннего состояния без доступной истории и внятного роадмапа,
отсутствие внятной дискуссии между пользователями и разработчиками,
отсутствие оптимизаций для современных процессоров, ...) привела к
тому, что существует по меньшей мере 4-5 форков libjpeg, реализующих
оптимизации кода для разных архитектур. Jpeg-turbo, например,
базируется на коде от японца Миясаки Масару, который сам не принимает
участие в разработке jpeg-turbo. На его коде построены и оптимизации
для ARM NEON в N900 руками Сергея Семашко. Есть также оптимизации от
Интела, Квалкома (они недавно вошли в Андроид) и ряда других компаний.

Редхат, руками Адама Ткаца, занялся jpeg-turbo. Создатели libjpeg в
рамках v8 (v8b вышел 16 мая 2010) активно эксплуатируют тему
масштабирования при декодировании, что с математической стороны сильно
ускоряет загрузку уменьшенных версий изображений, но очень плохо
укладывается на модель обработки данных на SIMD-архитектурах. В
результате, v8 проигрывает по скорости всему, перечисленному в
предыдущем абзаце до 15% -- при том, что в среднем проигрыш предыдущей
версии был в два-три раза. Но математический перфекционизм авторов
оригинального libjpeg в данном случае слабо коррелирует с реальностью
процессоров, на которых их код должен исполняться: многочисленные
ветвления, позволяющие сэкономить вычисления, приводят в реальности к
проигрышам из-за провала предсказания переходов. Порой просто лучше
масштабно пройтись "квадратно-гнездовым", чем терять десятки циклов на
провалах предсказаний. Например, в NEON можно загрузить за один раз
весь блок 8х8 и обработать его iDCT/DCT без обращения к памяти, не
теряя время.

Главный вопрос, который сейчас стоит -- это кто же будет на самом деле
апстримом для свободной реализации libjpeg? оригинальный, но не
работающий в том направлении, которое нужно реальным потребителям,
libjpeg v8 или TigerVNC, для которого jpeg-turbo пусть и необходимый,
но все же побочный продукт?


--
/ Alexander Bokovoy

Re: [devel] libjpeg7 - пора?

[Dmitry V. Levin]

[-- Attachment #1: Type: text/plain, Size: 1743 bytes --]

On Mon, Jul 05, 2010 at 11:17:42PM +0300, Victor Forsiuk wrote:
> 2010/7/5 Motsyo Gennadi aka Drool <motsyo@gmail.com>
> > 05.07.2010 18:14, Victor Forsiuk пишет:
> > > Нового libjpeg у нас в обозримом будущем не будет. Это очевидно чуть более
> > > чем полностью.
> > >
> > > В свете же выпуска LTS релизов остается только очень сильно надеятся на то,
> > > что в ближайшие годы мейнстримные дистрибутивы будут раскачиваться и
> > > окончательно переключатся на новую libjpeg не так скоро. И, соответственно,
> > > до наступления end-of-life нашего LTS дистра арифметическое кодирование не
> > > станет массовым.
> > >
> > > Напомню, libjpeg-6b не умеет arithmetic coding и такие джипеги просто не
> > > сможет декодировать.
> >
> >         Тут мелькнула информация про такой проект:
> >
> > http://libjpeg-turbo.virtualgl.org/
> >
> >        Утверждается, что библиотека совместима по API и ABI с стандартной
> > libjpeg 6b и может быть установлена вместо обычной дистрибутивной
> > libjpeg для получения 50% и более выигрыша в производительности
> > обработки JPEG изображений.
> 
> Да, я уже несколько месяцев живу на ней. Никаких проблем не обнаружилось, по
> тестам действительно раза в два быстрее... В связи с чем хочу (собственно,
> как раз собирался анонсировать) положить этот пакет в сизиф. Кто захочет
> потестировать просто устанавливайте libjpeg-turbo-* - он вытеснит
> (Obsoletes+Provides) обычный libjpeg.

Надеюсь, вы понимаете, что пакет с именем libjpeg-turbo, реализующий
libjpeg.so.62, автоматически вытеснит пакет libjpeg при сборке пакетов и
дистрибутивов?
Держать два разных пакета, реализующих библиотеку с одинаковым soname,
в репозитории скорее вредно, чем полезно.


-- 
ldv

[-- Attachment #2: Type: application/pgp-signature, Size: 198 bytes --]

Re: [devel] libjpeg7 - пора?

[Alexander Bokovoy]

2010/7/5 Victor Forsiuk <force@altlinux.org>:
> 2010/7/5 Alexander Bokovoy <ab@altlinux.org>
>>
>> Редхат, руками Адама Ткаца, занялся jpeg-turbo.
> И даже уже принял решение перейти на нее в Fedora 14.
Да, правда соответствующая бага в редхатовской багзиле ужасает.

>> Главный вопрос, который сейчас стоит -- это кто же будет на самом деле
>> апстримом для свободной реализации libjpeg? оригинальный, но не
>> работающий в том направлении, которое нужно реальным потребителям,
>> libjpeg v8 или TigerVNC, для которого jpeg-turbo пусть и необходимый,
>> но все же побочный продукт?
>
> Пусть он и побочный, но включение его в Fedora привлечет к проекту
> достаточно внимания и со стороны разработчиков. Идеальным вариантом мне
> представляется добавление реализации арифметического кодирования в
> libjpeg-turbo.
У меня не столь оптимистичный взгляд. Арифметическое кодирование пока
еще покрыто патентами, которые либо истекли, либо истекают в этом году
(Ricoh, 1993), но реальное состояние не очень понятно, пусть и
частично риски были проанализированы в 2008 году при создании Dirac:
http://lwn.net/Articles/272973/

Что касается "достаточно внимания и со стороны разработчиков" -- я бы
выждал хотя бы до ноября. Пока состояние рассылок по jpeg-turbo не
дает мне шансов говорить о каком-то прогрессе по сравнению с
оригинальным libjpeg.

Мы тоже пытаемся понять и сделать выбор у себя на работе :)
-- 
/ Alexander Bokovoy

Re: [devel] libjpeg7 - пора?

[Денис Смирнов]

[-- Attachment #1: Type: text/plain, Size: 668 bytes --]

On Mon, Jul 12, 2010 at 05:39:01PM +0300, Victor Forsiuk wrote:

VF> Коллеги, я готов выложить libjpeg-turbo в репозитарий. Да, из-за необходимых
VF> Obsoletes он начнет вытеснять libjpeg. Поэтому это не просто еще один пакет
VF> в сизифе "на пощупать". Его наличие там подразумевает, что мы двигаемся к
VF> его массовому тестированию и замене им стандартного libjpeg в следующих
VF> дистрибутивах...
VF> Поэтому я жду либо аргументированного ветирования такого перехода, либо
VF> одобрения...

Хм, а альтернативы тут не спасут?

-- 
С уважением, Денис

http://mithraen.ru/
----------------------------------------------------------------------------

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 198 bytes --]

Re: [devel] libjpeg7 - пора?

[Dmitry V. Levin]

[-- Attachment #1: Type: text/plain, Size: 346 bytes --]

On Mon, Jul 12, 2010 at 05:39:01PM +0300, Victor Forsiuk wrote:
> Коллеги, я готов выложить libjpeg-turbo в репозитарий.

Я бы хотел, чтобы в репозитории не было альтернативных libjpeg'ов.
Если libjpeg-turbo суждено заменить нынешний libjpeg-6b, то пусть пакет
продолжает называться libjpeg и замена произойдёт единовременно.


-- 
ldv

[-- Attachment #2: Type: application/pgp-signature, Size: 198 bytes --]

Re: [devel] libjpeg7 - пора?

[Alexander Bokovoy]

Hi,

>> >> Редхат, руками Адама Ткаца, занялся jpeg-turbo.
>> > И даже уже принял решение перейти на нее в Fedora 14.
>> Да, правда соответствующая бага в редхатовской багзиле ужасает.
>
> Это какая? Я смотрел 600243.
Да, эта. Правда, это я там запутался в том, что они описывают в
формальном ревью и пропустил, что "соответствует" обозначается [+], а
не означает элемент формального ревью, который пакет нарушает.

>> > Пусть он и побочный, но включение его в Fedora привлечет к проекту
>> > достаточно внимания и со стороны разработчиков. Идеальным вариантом мне
>> > представляется добавление реализации арифметического кодирования в
>> > libjpeg-turbo.
>> У меня не столь оптимистичный взгляд. Арифметическое кодирование пока
>> еще покрыто патентами, которые либо истекли, либо истекают в этом году
>> (Ricoh, 1993), но реальное состояние не очень понятно, пусть и
>> частично риски были проанализированы в 2008 году при создании Dirac:
>> http://lwn.net/Articles/272973/
>
> На самом деле, если и произойдет слияние лучшего из обох проектов, то
> произойдет это нескоро. В этом вопросе я не оптимист, а реалист...
>
> Кстати, если оценивать состояние с патентами пессимистично, то нашим лучшим
> выбором на ближайший срок был бы как раз переход на libjpeg-turbo. Мы
> получим ощутимый прирост в производительности, ничем не жертвуя взамен:
> - не нужна глобальная пересборка большей части репозитария
> - нет патентных рисков
> - из-за совпадения API и ABI в случае необходимости можно будет так же
> просто переключиться обратно на libjpeg
Да.

>> Что касается "достаточно внимания и со стороны разработчиков" -- я бы
>> выждал хотя бы до ноября. Пока состояние рассылок по jpeg-turbo не
>> дает мне шансов говорить о каком-то прогрессе по сравнению с
>> оригинальным libjpeg.
>
> С моей точки зрения эти проекты настолько разновекторны, что сравнивать их
> прогресс особого смысла нет. libjpeg-turbo - это ускоренная в реальной
> жизни, а не в теории, реализация алгоритмов. Мы получаем ускорение, и
> заметное, показа существующих джипегов. Оригинальный libjpeg в этом отстает,
> но новые арифметически кодированные файлы получат ускорение за счет меньшего
> размера (меньшее время считывания в ОЗУ может заметно перекрыть отставание
> декодера).
По словам одного из двух авторов оригинального libjpeg, сейчас остался
всего один человек, работающий над libjpeg, и тот не идет на
совместную деятельность. Фактически, это означает, что новым
поколением libjpeg будет скорее всего libjpeg-turbo, поскольку он
устраивает всех с практической точки зрения. Увы, это не решает
проблему с отсутствием разработчиков, кроме Адама Ткаца и
TigerVNC/VirtualGL больше пока никого нет. Даже этот "один из двух
авторов" заявил в мае, что он радостно поддержит libjpeg-turbo, если
не надо будет его разрабатывать.

> Я бы не стал ждать до ноября с выкладыванием libjpeg-turbo в репозитарий.
> Чем раньше и большее количество пользователей начнут его тестировать - тем
> лучше.
Конечно.

>>
>> Мы тоже пытаемся понять и сделать выбор у себя на работе :)
>
> Коллеги, я готов выложить libjpeg-turbo в репозитарий. Да, из-за необходимых
> Obsoletes он начнет вытеснять libjpeg. Поэтому это не просто еще один пакет
> в сизифе "на пощупать". Его наличие там подразумевает, что мы двигаемся к
> его массовому тестированию и замене им стандартного libjpeg в следующих
> дистрибутивах...
Мы тут  посмотрели немного на ситуацию вокруг libjpeg, с учетом
коментариев со стороны ffmpeg
(http://hardwarebug.org/2009/08/04/ijg-is-back/ и
http://hardwarebug.org/2010/02/01/ijg-swings-again-and-misses/ ),
которые пусть и немного несправедливы, отмечают реальные проблемы. Я
все больше склоняюсь к тому, чтобы переместить акцент на
libjpeg-turbo. Помимо оптимизаций есть и необходимость улучшать API, а
это нужно делать с живым апстримом.

> Поэтому я жду либо аргументированного ветирования такого перехода, либо
> одобрения...
Вето нет.

-- 
/ Alexander Bokovoy

Re: [devel] libjpeg7 - пора?

[Aleksey Novodvorsky]

12 июля 2010 г. 18:39 пользователь Victor Forsiuk <force@altlinux.org> написал:
> Поэтому я жду либо аргументированного ветирования такого перехода, либо
> одобрения...

Не читал, но одобряю.

Rgrds, Алексей

Re: [devel] libjpeg7 - пора?

[Dmitry V. Levin]

[-- Attachment #1: Type: text/plain, Size: 370 bytes --]

On Tue, Jul 13, 2010 at 04:13:09AM +0400, Aleksey Novodvorsky wrote:
> 12 июля 2010 г. 18:39 пользователь Victor Forsiuk <force@altlinux.org> написал:
> > Поэтому я жду либо аргументированного ветирования такого перехода, либо
> > одобрения...
> 
> Не читал, но одобряю.

От такого одобрения нет никакой пользы.
Одобрять нужно со знанием дела. :)


-- 
ldv

[-- Attachment #2: Type: application/pgp-signature, Size: 198 bytes --]

Re: [devel] libjpeg7 - пора?

[Aleksey Novodvorsky]

13 июля 2010 г. 4:21 пользователь Dmitry V. Levin <ldv@altlinux.org> написал:
> On Tue, Jul 13, 2010 at 04:13:09AM +0400, Aleksey Novodvorsky wrote:
>> 12 июля 2010 г. 18:39 пользователь Victor Forsiuk <force@altlinux.org> написал:
>> > Поэтому я жду либо аргументированного ветирования такого перехода, либо
>> > одобрения...
>>
>> Не читал, но одобряю.
>
> От такого одобрения нет никакой пользы.

Это не страшно, главное чтобы вреда не было.

Rgrds, Алексей

Re: [devel] libjpeg7 - пора?

[Денис Смирнов]

[-- Attachment #1: Type: text/plain, Size: 517 bytes --]

On Mon, Jul 12, 2010 at 08:29:18PM +0400, Dmitry V. Levin wrote:

DVL> Я бы хотел, чтобы в репозитории не было альтернативных libjpeg'ов.
DVL> Если libjpeg-turbo суждено заменить нынешний libjpeg-6b, то пусть пакет
DVL> продолжает называться libjpeg и замена произойдёт единовременно.

Ok, libjpeg62, только, если можно :)

По поводу shared lib policy буду занудствовать вечно :)

-- 
С уважением, Денис

http://mithraen.ru/
----------------------------------------------------------------------------

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 198 bytes --]

Re: [devel] libjpeg7 - пора?

[Dmitry V. Levin]

[-- Attachment #1: Type: text/plain, Size: 612 bytes --]

On Tue, Jul 13, 2010 at 08:50:20AM +0400, Денис Смирнов wrote:
> On Mon, Jul 12, 2010 at 08:29:18PM +0400, Dmitry V. Levin wrote:
> 
> DVL> Я бы хотел, чтобы в репозитории не было альтернативных libjpeg'ов.
> DVL> Если libjpeg-turbo суждено заменить нынешний libjpeg-6b, то пусть пакет
> DVL> продолжает называться libjpeg и замена произойдёт единовременно.
> 
> Ok, libjpeg62, только, если можно :)

Давайте будем избегать _ненужных_ переименований.  А то вон можно взять и
переименовать glibc-core в libc6, да ещё и запаковать каждую библиотеку
из glibc-core в отдельный подпакет. :)


-- 
ldv

[-- Attachment #2: Type: application/pgp-signature, Size: 198 bytes --]

Re: [devel] libjpeg7 - пора?

[Денис Смирнов]

[-- Attachment #1: Type: text/plain, Size: 473 bytes --]

On Tue, Jul 13, 2010 at 01:17:42PM +0400, Dmitry V. Levin wrote:

DVL> Давайте будем избегать _ненужных_ переименований.  А то вон можно взять и
DVL> переименовать glibc-core в libc6, да ещё и запаковать каждую библиотеку
DVL> из glibc-core в отдельный подпакет. :)

Нужность зависит от того -- будет ли в ближайшие год-два новый soname.

-- 
С уважением, Денис

http://mithraen.ru/
----------------------------------------------------------------------------

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 198 bytes --]

Re: [devel] libjpeg7 - пора?

[Yuri N. Sedunov]

В Втр, 13/07/2010 в 13:17 +0400, Dmitry V. Levin пишет:
> On Tue, Jul 13, 2010 at 08:50:20AM +0400, Денис Смирнов wrote:
> > On Mon, Jul 12, 2010 at 08:29:18PM +0400, Dmitry V. Levin wrote:
> > 
> > DVL> Я бы хотел, чтобы в репозитории не было альтернативных libjpeg'ов.
> > DVL> Если libjpeg-turbo суждено заменить нынешний libjpeg-6b, то пусть пакет
> > DVL> продолжает называться libjpeg и замена произойдёт единовременно.
> > 
> > Ok, libjpeg62, только, если можно :)
> 
> Давайте будем избегать _ненужных_ переименований.  А то вон можно взять и
> переименовать glibc-core в libc6, да ещё и запаковать каждую библиотеку
> из glibc-core в отдельный подпакет. :)

Подобного дерьма в сизифе уж полно.

-- 
Yuri N. Sedunov

Re: [devel] libjpeg7 - пора?

[Alexey Shabalin]

13 июля 2010 г. 13:17 пользователь Dmitry V. Levin <ldv@altlinux.org> написал:
> On Tue, Jul 13, 2010 at 08:50:20AM +0400, Денис Смирнов wrote:
>> On Mon, Jul 12, 2010 at 08:29:18PM +0400, Dmitry V. Levin wrote:
>>
>> DVL> Я бы хотел, чтобы в репозитории не было альтернативных libjpeg'ов.
>> DVL> Если libjpeg-turbo суждено заменить нынешний libjpeg-6b, то пусть пакет
>> DVL> продолжает называться libjpeg и замена произойдёт единовременно.
>>
>> Ok, libjpeg62, только, если можно :)
>
> Давайте будем избегать _ненужных_ переименований.  А то вон можно взять и
> переименовать glibc-core в libc6, да ещё и запаковать каждую библиотеку
> из glibc-core в отдельный подпакет. :)

Я бы даже поднял вопрос о пересмотре(дополнении, уточнении) полиси.
Зачем в название вносить номер, если в репо библиотека присутствует в
единственном числе. Зачем нам уподоблятся дебиану?
Если библиотек разных версий в репо несколько (и это действительно
нужно), то это оправдано.
А имеено надо пересмотреть фразу в полиси "Пакет должен иметь название
lib%name%abiversion".

-- 
Alexey Shabalin

Re: [devel] libjpeg7 - пора?

[Денис Смирнов]

[-- Attachment #1: Type: text/plain, Size: 1605 bytes --]

On Tue, Jul 13, 2010 at 08:29:25PM +0400, Alexey Shabalin wrote:

AS> Я бы даже поднял вопрос о пересмотре(дополнении, уточнении) полиси.
AS> Зачем в название вносить номер, если в репо библиотека присутствует в
AS> единственном числе. Зачем нам уподоблятся дебиану?

Затем, что наш apt -- глючное дерьмо.

И при изменении soname у библиотеки без изменении имени apt-get upgrade и
частичные обновления _даже при наличии compat-библиотеки_ накрываются
медным тазом.

AS> Если библиотек разных версий в репо несколько (и это действительно
AS> нужно), то это оправдано.
AS> А имеено надо пересмотреть фразу в полиси "Пакет должен иметь название
AS> lib%name%abiversion"

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

Hint: glibc принципиально отличается от других библиотек тем, что в
системе очень сложно найти приложения или библиотеки, которые бы не
использовани glibc.

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

Делать же такую точку перегиба из обновления каждой библиотеки -- бред.

P.S. Кстати, я был несколько неправ -- переименование libjpeg  это
маловажная фича, и при этом само по себе, если будет сделано неправильно,
может создать проблемы. Вот если у нас все-таки появится libjpeg7 -- тогда
переименование обоих пакетов будет обязательным, IMHO.

-- 
С уважением, Денис

http://mithraen.ru/
----------------------------------------------------------------------------

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 198 bytes --]

Re: [devel] libjpeg7 - пора?

[Alexey Shabalin]

13 июля 2010 г. 21:13 пользователь Денис Смирнов написал:
> On Tue, Jul 13, 2010 at 08:29:25PM +0400, Alexey Shabalin wrote:
>
> AS> Если библиотек разных версий в репо несколько (и это действительно
> AS> нужно), то это оправдано.
> AS> А имеено надо пересмотреть фразу в полиси "Пакет должен иметь название
> AS> lib%name%abiversion"
>
> Искренне надеюсь что это крайне неразумное предложение никогда не будет
> принято.
А разумному требованию никто не следует. Пакетов вида
lib%name%abiversion в сизифе гораздо меньше чем lib%name.
И у нас есть автоматические Provides вида lib%soname, которых зачастую
достаточно.
Иногда лучше привести правила к действительности, чем подгонять
действительность под правила.

-- 
Alexey Shabalin

Re: [devel] libjpeg7 - пора?

[Денис Смирнов]

[-- Attachment #1: Type: text/plain, Size: 1258 bytes --]

On Tue, Jul 13, 2010 at 09:28:35PM +0400, Alexey Shabalin wrote:

AS> А разумному требованию никто не следует. 

К счастью эти слова есть пример так называемой лжи, и некоторые пакеты
собираются в соответствии с ShareLibsPolicy.

AS> Пакетов вида
AS> lib%name%abiversion в сизифе гораздо меньше чем lib%name.
AS> И у нас есть автоматические Provides вида lib%soname, которых зачастую
AS> достаточно.
AS> Иногда лучше привести правила к действительности, чем подгонять
AS> действительность под правила.

_Иногда_.

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

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

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

-- 
С уважением, Денис

http://mithraen.ru/
----------------------------------------------------------------------------

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 198 bytes --]

Re: [devel] libjpeg7 - пора?

[REAL]

Alexey Shabalin пишет:
> Я бы даже поднял вопрос о пересмотре(дополнении, уточнении) полиси.
> Зачем в название вносить номер, если в репо библиотека присутствует в
> единственном числе. Зачем нам уподоблятся дебиану?
> Если библиотек разных версий в репо несколько (и это действительно
> нужно), то это оправдано.
> А имеено надо пересмотреть фразу в полиси "Пакет должен иметь название
> lib%name%abiversion".

Имеется в виду SharedLibsPolicy? По-моему, там не только это надо бы 
пересмотреть ;)

Мне, например, там не встречалась мысль, озвученная ldv@, но 
интересная: при смене soname не менять название пакета, а номер к 
названию добавлять только к тем, кто в System/Legacy libraries.

-- 

REAL aka Евгений Ростовцев, программист ЦНИТ КемГУ

Re: [devel] libjpeg7 - пора?

[Денис Смирнов]

[-- Attachment #1: Type: text/plain, Size: 583 bytes --]

On Wed, Jul 14, 2010 at 10:24:20AM +0800, REAL wrote:

R> Мне, например, там не встречалась мысль, озвученная ldv@, но 
R> интересная: при смене soname не менять название пакета, а номер к 
R> названию добавлять только к тем, кто в System/Legacy libraries.

В тексте самого SharedLibsPolicy сказано, почему так делать нельзя.

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

-- 
С уважением, Денис

http://mithraen.ru/
----------------------------------------------------------------------------

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 198 bytes --]

[devel] libjpeg-turbo - пора?

[Michael Shigorin]

On Mon, Jul 05, 2010 at 11:05:42PM +0400, Valery V. Inozemtsev wrote:
> http://ftp.altlinux.org/pub/people/shrek/gnome/i586/RPMS.hasher/libjpeg-turbo-1.0.0-alt1.i586.rpm

Спасибо, попробую.  На всякий:

Selecting libjpeg-turbo for 'libjpeg-turbo-1.0.0-alt1.i586.rpm'
The following extra packages will be installed:
  libgle libjpeg-turbo xscreensaver-hacks-gl xscreensaver-modules-gl
The following packages will be REMOVED:
  libjpeg libjpeg-utils xscreensaver-hacks xscreensaver-modules
The following NEW packages will be installed:
  libgle libjpeg-turbo xscreensaver-hacks-gl xscreensaver-modules-gl

-- 
 ---- WBR, Michael Shigorin <mike@altlinux.ru>
  ------ Linux.Kiev http://www.linux.kiev.ua/

Re: [devel] libjpeg-turbo - пора?

[Andrey Rahmatullin]

[-- Attachment #1: Type: text/plain, Size: 762 bytes --]

On Mon, Jul 19, 2010 at 05:14:30PM +0300, Michael Shigorin wrote:
> Selecting libjpeg-turbo for 'libjpeg-turbo-1.0.0-alt1.i586.rpm'
> The following extra packages will be installed:
>   libgle libjpeg-turbo xscreensaver-hacks-gl xscreensaver-modules-gl
> The following packages will be REMOVED:
>   libjpeg libjpeg-utils xscreensaver-hacks xscreensaver-modules
> The following NEW packages will be installed:
>   libgle libjpeg-turbo xscreensaver-hacks-gl xscreensaver-modules-gl
xscreensaver-modules требует libjpeg-utils

-- 
WBR, wRAR (ALT Linux Team)
Powered by the ALT Linux fortune(6):

> ЗЫ с понедельника ухожу в отпуск, ранее чем через 3 недели меня
> не ждите :)
Типа бяку подложил и быстро-быстро смотался...
		-- ktirf in sisyphus@

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 490 bytes --]

Re: [devel] libjpeg-turbo - пора?

[Motsyo Gennadi aka Drool]

> On Mon, Jul 05, 2010 at 11:05:42PM +0400, Valery V. Inozemtsev wrote:
>> http://ftp.altlinux.org/pub/people/shrek/gnome/i586/RPMS.hasher/libjpeg-turbo-1.0.0-alt1.i586.rpm

To shrek.

Валера, а почему *-devel не упаковываешь?

Wrote: /usr/src/RPM/SRPMS/libjpeg-turbo-1.0.0-alt0.M51.1.src.rpm
Wrote: /usr/src/RPM/RPMS/i586/libjpeg-turbo-1.0.0-alt0.M51.1.i586.rpm

Re: [devel] libjpeg7 - пора?

[Alexey Gladkov]

23.08.2009 18:23, Victor Forsyuk wrote:
> http://trac.imagemagick.org/browser/jpeg/trunk/change.log
> 
> Рано или поздно перейдем. Предлагаю задуматься о том, не начать ли движение
> уже сейчас...

https://bugzilla.mozilla.org/show_bug.cgi?id=586320

-- 
Rgrds, legion

Re: [devel] libjpeg7 - пора?

[Alexey Gladkov]

21.08.2010 19:37, Alexey Gladkov wrote:
> 23.08.2009 18:23, Victor Forsyuk wrote:
>> http://trac.imagemagick.org/browser/jpeg/trunk/change.log
>>
>> Рано или поздно перейдем. Предлагаю задуматься о том, не начать ли движение
>> уже сейчас...
> 
> https://bugzilla.mozilla.org/show_bug.cgi?id=586320
> 

Ну вот и всё:

https://bugzilla.mozilla.org/show_bug.cgi?id=573948

"Replace libjpeg with libjpeg-turbo" - RESOLVED FIXED

-- 
Rgrds, legion

Re: [devel] libjpeg7 - пора?

[Dmitry V. Levin]

[-- Attachment #1: Type: text/plain, Size: 632 bytes --]

On Wed, Mar 30, 2011 at 02:36:52AM +0400, Alexey Gladkov wrote:
> 21.08.2010 19:37, Alexey Gladkov wrote:
> > 23.08.2009 18:23, Victor Forsyuk wrote:
> >> http://trac.imagemagick.org/browser/jpeg/trunk/change.log
> >>
> >> Рано или поздно перейдем. Предлагаю задуматься о том, не начать ли движение
> >> уже сейчас...
> > 
> > https://bugzilla.mozilla.org/show_bug.cgi?id=586320
> 
> Ну вот и всё:
> 
> https://bugzilla.mozilla.org/show_bug.cgi?id=573948
> 
> "Replace libjpeg with libjpeg-turbo" - RESOLVED FIXED

Нам в этой связи нужно что-то предпринимать?
Например, обновить пакет libjpeg-turbo?


-- 
ldv

[-- Attachment #2: Type: application/pgp-signature, Size: 198 bytes --]

Re: [devel] libjpeg7 - пора?

[Alexey Gladkov]

30.03.2011 10:55, Dmitry V. Levin wrote:
> Нам в этой связи нужно что-то предпринимать?

Я хотел продемонстрировать направленность в проекте и поддержать топик :)

> Например, обновить пакет libjpeg-turbo?

Это сделать безусловно нужно. :)

-- 
Rgrds, legion