[devel] I: gcc 11.2.1 && binutils 2.37

[devel] I: gcc 11.2.1 && binutils 2.37

[Gleb Fotengauer-Malinovskiy]

Hi,

В Сизиф отправились gcc 11.2.1 и binutils 2.37.

http://gcc.gnu.org/gcc-11/changes.html

http://gcc.gnu.org/gcc-11/porting_to.html

Enjoy!

Пакеты, которые сломаются:

Из-за binutils:

eppic	vt @everybody
koules	mike @everybody
libvamp	cas @everybody
magicpoint	rider @everybody
nx-libs	pv @everybody
rx-etersoft	lav pv kondratyuk
Xaw95	ruslandh @qa
	* The ar tool's previously unused l modifier is now used for specifying
	  dependencies of a static library. The arguments of this option
	  (or --record-libdeps long form option) will be stored verbatim in the
	  __.LIBDEP member of the archive, which the linker may read at link time.


make-initrd-bootloader	legion
	Thanks to a recent binutils change which doesn't generate unused
	symbols, it's now possible for thunk_64.o be completely empty without
	CONFIG_PREEMPTION: no text, no data, no symbols.
	https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=1d489151e9f9d1647110277ff77282fe4d96d09b


seabios	shaba @everybody
gfxboot	rider zerg
	* Configure with --enable-x86-used-note by default for Linux/x86.	
	https://review.coreboot.org/plugins/gitiles/seabios/+/6eff8085980dba0938cea0193b8a0fd3c6b0c4ca
	https://github.com/openSUSE/gfxboot/commit/14a8685c9579916f41c565d8b0a716e143c364d9


Из-за gcc:

AlephOne	azol @everybody
aiksaurus	lav @qa @everybody
asc	oddity @qa @everybody
avarice	majioa @everybody
babel	sin @python @qa @everybody
berusky	grenka
bonnie++	mike @qa
codeblocks	grenka
convert3d	darktemplar @everybody
cryptote	naf
cuneiform	george rider
dansguardian	rider @everybody
din	george @everybody
duel3	underwit @everybody
fakenes	oddity @qa @everybody
farmhash	rider @everybody
fbpager	ender @everybody
ferrisloki	darktemplar @everybody
flatzebra	viy @everybody
fs-uae	george @everybody
gle	viy @everybody
gnome-chemistry-utils	aris
gnome-quod	darktemplar @everybody
gostcrypt	cas @everybody
gsmlib	antohami @everybody
hammerhead	naf
htmlcxx	viy @everybody
imule	darktemplar @everybody
incron	rider @everybody
itk-snap	darktemplar @everybody
itpp	antohami @everybody
java-1.8.0-openjdk	cas viy @everybody
jigdo	george @everybody
kasumi	oddity @everybody
libbobpp	lav @qa @everybody
libcnc	lav @everybody
libcpptest	lav @qa
libcxxtools	sbolshakov @everybody
liblasi	mike @qa
liblog4cpp	taf @everybody
libmnetutil	viy @everybody
libmusicbrainz	darktemplar @everybody
libpqxx	viy @everybody
libprojectM	drool
libraul	pav @everybody
libuniset2	pv @everybody
libvarconf	viy @everybody
mbrola	viy msp @everybody
nut	mike @everybody
ogmtools	rider @everybody
opendbx	boyarsh @everybody
opendx	darktemplar @everybody
pekwm	george @everybody
qca-qt5	zerg
rbdoom3bfg	arbars @everybody
refal-plus	george @everybody
rxvt-unicode	legion @cpan
scourge	darktemplar @everybody
stargazer	drool @qa @everybody
ufoai	darktemplar @everybody
v4l-utils	sbolshakov rider @everybody
xsd	viy @everybody
	The default mode for C++ is now -std=gnu++17 instead of -std=gnu++14.


GTS	darktemplar @everybody
aMule	oddity @everybody
android-tools	zorg @everybody
aqualung	george @qa
citra	nenderus @everybody
cppcheck	ruslandh @everybody
freecad	cas @everybody
gdal	boyarsh @qa @everybody
gdcm	viy @everybody
herbstluftwm	@nobody
ice	lav @everybody
karbowanecwallet	drool @everybody
libcaf	lav @everybody
libebml	ender @everybody
liborcus	george @everybody
librlottie	lav @everybody
libvxl	ptrnine @everybody
libwt	pv @everybody
minetest	cas @everybody
mongo	@nobody
opencascade	cas @everybody
panzerchasm	arbars @everybody
praat	mike @qa
slicer	darktemplar @everybody
solvespace	cas lineprinter @everybody
springrts	darktemplar @everybody
uhd	antohami @everybody
vtk	darktemplar @everybody
webcamoid	lav @everybody
xapian-core	mike lav darktemplar @qa
	Some C++ Standard Library headers have been changed to no longer include
	other headers that they do need to depend on. As such, C++ programs that
	used standard library components without including the right headers
	will no longer compile.
	
	The following headers are used less widely in libstdc++ and may need to
	be included explicitly when compiled with GCC 11:
	
	    <limits> (for std::numeric_limits)
	    <memory> (for std::unique_ptr, std::shared_ptr etc.)
	    <utility> (for std::pair, std::tuple_size, std::index_sequence etc.)
	    <thread> (for members of namespace std::this_thread.)


Ri-li	@nobody
antimicro	mike @everybody
assimp	viy @everybody
bloboats	george @everybody
chuck	oddity @everybody
fluxbox	@nobody
gpsbabel	darktemplar @everybody
hashdeep	mike @everybody
holotz-castle	george @qa
java-9-openjdk	viy @jvm @everybody
libmimetic	lvol @everybody
libnewmat	@nobody
libtlsh	ptrnine @everybody
manaworld	viy @everybody
moto4lin	@mobile @qa
nted	lav @qa @everybody
qamix	@nobody
qpxtool	mike @everybody
qt4	zerg
slim	@nobody
swftools	mike @everybody
vdr	sbolshakov @everybody
xlogical	george @everybody
	GCC 11 now issues a diagnostic for ordered comparisons of pointers
	against constant integers. Commonly this is an ordered comparison
	against NULL or 0. These should be equality comparisons, not ordered
	comparisons. 


7-zip	george @everybody
fwbuilder	shaba @everybody
lib7zip	lav @everybody
libkqueue	darktemplar @everybody
libv8-3.14	antohami @everybody
procps	sem ldv @qa
upx	george @qa
vzstat	@nobody
	c-family: Macro support in -Wmisleading-indentation [PR80076]
	(https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80076)


briquolo	grenka
marsshooter	arbars @everybody
octave-geometry	manowar viy @everybody
ogre	george @everybody
s3fs	grenka
snes9x	nenderus @everybody
	GCC 11 now enforces that comparison objects be invocable as const.


crtools-ovz	andy @everybody
faketime	ldv @norebuild
mbedtls13	nenderus @everybody
stlink	week @everybody
	Enhanced -Wstringop-overflow warning.


NetworkManager	sem
dxx-rebirth	george @everybody
gnucash	cas @everybody
opensc	dd stanv timonbl4 @qa @everybody
	Enhanced -Wmaybe-uninitialized warning.


kde5-smplayer	zerg
liboqs	vt @everybody
libvzctl	shaba @everybody
	New warning -Warray-parameter, enabled by -Wall, warns about
	redeclarations of functions with ordinary array arguments declared using
	inconsistent forms. The warning also enables the detection of the likely out of
	bounds accesses in calls to such functions with smaller arrays. 


cpuminer-multi	drool @everybody
john-jumbo	george @everybody
xonotic	darktemplar @everybody
	stor-layout: Reject forming arrays with elt sizes not divisible by elt
	alignment [PR97164] (https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97023)


libgstreamermm1.0	aris
lordsawar	darktemplar @everybody
subtitleeditor	aris
	c-family: check qualifiers of arguments to __atomic built-ins (PR 95378)
	(https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95378)


qt-creator	cas @everybody
zig	vt @everybody
	"The bytecode files are versioned and there is a strict version
	check, so bytecode files generated in one version of GCC do not
	work with an older or newer version of GCC." -- gcc(1)
	(Очевидно, llvm 12 не был пересобран после внедрения LTO.)


pcb2gcode	antohami @everybody
pfstools	rider @everybody
	G++, starting with G++ 7, implements C++17 P0522R0
	(http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2016/p0522r0.html),
	Matching of template template-arguments excludes compatible templates.
	As a consequence, the following test is now rejected:
	    template <int N, int M = N> class A;
	    template <int N, int M> void fn(A<N, M> &) {}
	    template <int N, template <int> class TT> void fn(TT<N> &);
	    template void fn(A<3> &);
	because A is now considered a valid argument for TT, so both function
	templates are valid candidates, and neither is more specialized than the
	other, so it's ambiguous.
	The new behavior can be disabled independently of other C++17 features
	with -fno-new-ttp-matching.


attract	arbars @everybody
	c++: private inheritance access diagnostics fix [PR17314]
	(https://gcc.gnu.org/bugzilla/show_bug.cgi?id=17314)


ring-project	zerg @everybody
	libstdc++: Adjust static assertions in futures and promises [LWG 3466]


xrootd	arei @everybody
	New warning -Wsizeof-array-div, enabled by -Wall, warns about divisions
	of two sizeof operators when the first one is applied to an array and
	the divisor does not equal the size of the array element. 


clickhouse	rider darktemplar
	x86: Add missing intrinsics [PR95483]
	(https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95483)


x16-emulator	arbars @everybody
	Enhanced -Wformat-overflow warning.


xfs	george @everybody
	Enhanced -Warray-bounds warning.


libtasn1	sem ldv
	Improved Static Analyzer (-fanalyzer).


ruby	@ruby @everybody
	https://github.com/ruby/ruby/commit/a0a8f2abf533702b2cd96e79f700ce5b9cd94f50

-- 
glebfm

Re: [devel] I: gcc 11.2.1 && binutils 2.37

[Michael Shigorin]

On Wed, Sep 22, 2021 at 12:45:09AM +0300, Gleb Fotengauer-Malinovskiy wrote:
> В Сизиф отправились gcc 11.2.1 и binutils 2.37.

Поздравляю ;-)

> Пакеты, которые сломаются:

"шо, опять?!"

> eppic	vt @everybody
> koules	mike @everybody
> bonnie++	mike @qa
> liblasi	mike @qa
> nut	mike @everybody
> praat	mike @qa
> xapian-core	mike lav darktemplar @qa
> antimicro	mike @everybody
> hashdeep	mike @everybody
> qpxtool	mike @everybody
> swftools	mike @everybody

Добавил @everybody ко всем перечисленным @qa-пакетам,
кроме довольно чувствительного xapian-core, чтобы любой
желающий мог поучаствовать: я сейчас нечасто добираюсь
до собственно поддержки пакетов в основном сизифе,
почти полностью переключившись на sisyphus_e2k.

-- 
 ---- WBR, Michael Shigorin / http://altlinux.org
  ------ http://opennet.ru / http://anna-news.info

[devel] NM: Проприетарные форки aka sisyphus_e2k (Was: I: gcc 11.2.1 && binutils 2.37)

[Vladimir D. Seleznev]

On Thu, Sep 23, 2021 at 11:17:55AM +0300, Michael Shigorin wrote:
> On Wed, Sep 22, 2021 at 12:45:09AM +0300, Gleb Fotengauer-Malinovskiy wrote:
> > В Сизиф отправились gcc 11.2.1 и binutils 2.37.
> 
> Поздравляю ;-)
> 
> > Пакеты, которые сломаются:
> 
> "шо, опять?!"
> 
> > eppic	vt @everybody
> > koules	mike @everybody
> > bonnie++	mike @qa
> > liblasi	mike @qa
> > nut	mike @everybody
> > praat	mike @qa
> > xapian-core	mike lav darktemplar @qa
> > antimicro	mike @everybody
> > hashdeep	mike @everybody
> > qpxtool	mike @everybody
> > swftools	mike @everybody
> 
> Добавил @everybody ко всем перечисленным @qa-пакетам,
> кроме довольно чувствительного xapian-core, чтобы любой
> желающий мог поучаствовать: я сейчас нечасто добираюсь
> до собственно поддержки пакетов в основном сизифе,
> почти полностью переключившись на sisyphus_e2k.

-- 
   WBR,
   Vladimir D. Seleznev

Re: [devel] Не проприетарные, а суверенные / Apple M1 (Was: I: gcc 11.2.1 && binutils 2.37)

[Alexey Tourbin]

Кстати вышло описание процессора Apple M1. Там объясняется, как ему
удается исполнять по 8 инструкций за такт. Боюсь что VLIW его не
догонит.

What most code looks like is that it consists of short chains of
sequentially dependent macroinstructions (say 5 to 7
macroinstructions, 10 to 20 instructions long in total) which store
their result to memory or a register, and that memory or register is
not accessed until many (hundreds) of cycles later. This means that
while each sequentially dependent macroinstruction has to execute one
after the other, you can execute many of the chains in parallel...
That sounds good but you need a variety of machinery to track which
instructions are independent of previous instructions, and to track
the program order of instructions so that as branches are resolved as
correct, you know which of the instructions in program order now
resolve as correct.
(This fact is why so many people’s intuition about the value of
superscalarity is so flawed. Most people hone their assembly
optimization skills on long stretches of sequentially dependent
instructions; but such code is actually unrepresentative of most of
what runs on a CPU.
This fact is also why OoO superscalarity works so well, whereas most
attempts to create static wide machines have been problematic. All the
pieces -- out of order, prediction, and superscalarity -- work
synergistically. In particular most of these chains that are running
in parallel come from different basic blocks [ie are separated by some
sort of if() statement that the compiler can’t see past] and so are
impossible to aggregate statically.)
https://drive.google.com/file/d/1WrMYCZMnhsGP4o3H33ioAUKL_bjuJSPt/view

Re: [devel] I: gcc 11.2.1 && binutils 2.37

[arbars]

22.09.2021 03:45, Gleb Fotengauer-Malinovskiy пишет:
> Hi,
>
> В Сизиф отправились gcc 11.2.1 и binutils 2.37.
Круто!
> http://gcc.gnu.org/gcc-11/changes.html
>
> http://gcc.gnu.org/gcc-11/porting_to.html
>
> Enjoy!
>
> Пакеты, которые сломаются:
>
> Из-за binutils:
>
> ...
>
> Из-за gcc:
>
> rbdoom3bfg	arbars @everybody
Хороший повод для обновления! Уже есть новый мажорный релиз!
> panzerchasm	arbars @everybody
Исправление уже в пути!
> marsshooter	arbars @everybody
Вот с этим будет точно весело...
> attract	arbars @everybody
> 	c++: private inheritance access diagnostics fix [PR17314]
> 	(https://gcc.gnu.org/bugzilla/show_bug.cgi?id=17314)
А это уже посурьёзнее... Попробую разобраться, но чуть позже :)
>
> x16-emulator	arbars @everybody
> 	Enhanced -Wformat-overflow warning.
>
Есть решение, исправлю как только, так сразу.

И да, всем успехов в починке!

Re: [devel] I: gcc 11.2.1 && binutils 2.37

[Илья Курдюков]

В виду того, что произошло на днях с ruby, что я исправлял и оказалось что:

Не очень безопасный стиль програмирования приводит к тому, что 
компилятор ломает код за счёт межобъектной оптимизации через включенный 
LTO. И так как %check в спеках это скорее редкость для Альта, чем 
правило - то появится внезапные падения на разном софте, при использовании.

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

Поэтому совет всем: в любой непонятной ситуации - в первую очередь 
проверить с выключенныи LTO. Если помогло, то или оставить выключенным 
или искать обновления (или патчи в других дистрибутивах) или чинить самим.

On 22.09.2021 04:45, Gleb Fotengauer-Malinovskiy wrote:
> ruby	@ruby @everybody
> 	https://github.com/ruby/ruby/commit/a0a8f2abf533702b2cd96e79f700ce5b9cd94f50
>

Re: [devel] I: gcc 11.2.1 && binutils 2.37

[Anton Farygin]

Да, Илья.

Есть ещё вот такая статья годичной давности:
https://johnysswlab.com/link-time-optimizations-new-way-to-do-compiler-optimizations/

и там интересная заметка про ffmpeg, в которой говорится о том, что 
выигрыш в сборке с LTO может быть нулевым.
Конечно, компилятор развивается и на новом gcc всё может быть несколько 
лучше.



On 24.09.2021 06:32, Илья Курдюков wrote:
> В виду того, что произошло на днях с ruby, что я исправлял и оказалось 
> что:
>
> Не очень безопасный стиль програмирования приводит к тому, что 
> компилятор ломает код за счёт межобъектной оптимизации через 
> включенный LTO. И так как %check в спеках это скорее редкость для 
> Альта, чем правило - то появится внезапные падения на разном софте, 
> при использовании.
>
> С библиотеками хуже, потому что будут вызывать падения в зависимых от 
> них проектах.
>
> Поэтому совет всем: в любой непонятной ситуации - в первую очередь 
> проверить с выключенныи LTO. Если помогло, то или оставить выключенным 
> или искать обновления (или патчи в других дистрибутивах) или чинить 
> самим.
>
> On 22.09.2021 04:45, Gleb Fotengauer-Malinovskiy wrote:
>> ruby    @ruby @everybody
>>     https://github.com/ruby/ruby/commit/a0a8f2abf533702b2cd96e79f700ce5b9cd94f50 
>>
>>
>
> _______________________________________________
> Devel mailing list
> Devel@lists.altlinux.org
> https://lists.altlinux.org/mailman/listinfo/devel

Re: [devel] I: gcc 11.2.1 && binutils 2.37

[Илья Курдюков]

У меня самого ровно такие же мысли, просто интуитивно. Что если в самой 
сборке LTO не используется, то и нечего его туда засовывать насильно.

В проектах где производительность важна - критические места специально 
оптимизируют в апстриме, ffmpeg как раз такой.

По ссылке https://www.altlinux.org/LTO - хотелось бы видеть конкретные 
примеры из Альта, что скомпилировали такие-то нужные пакеты, была такая 
производительность, стала такая, чтобы наглядно было видно за что 
боремся. А не ссылки на статьи о том как это круто теоретически.

Я ваши дискуссии внимательно не читал, потому что занимаюсь починкой 
пакетов для Эльбруса, где -flto просто не поддерживается и игнорируется 
компилятором. Однако это повлияло и на меня, когда несколько проектов в 
ряд оказываются сломаны из-за LTO, когда я пытаюсь добавить патч для 
Эльбруса. Как и много замечаю уже кем-то сделанных фиксов проблем с LTO.

Моё впечатление, что создали себе гору проблем из-за "модной" фичи, не 
приносящей никакого заметного вклада в реальную производительность.

On 24.09.2021 12:48, Anton Farygin wrote:
> Да, Илья.
>
> Есть ещё вот такая статья годичной давности:
> https://johnysswlab.com/link-time-optimizations-new-way-to-do-compiler-optimizations/ 
>
>
> и там интересная заметка про ffmpeg, в которой говорится о том, что 
> выигрыш в сборке с LTO может быть нулевым.
> Конечно, компилятор развивается и на новом gcc всё может быть 
> несколько лучше.
>
>

Re: [devel] I: gcc 11.2.1 && binutils 2.37

[Konstantin Lepikhov]

Hi Илья!

On 09/24/2021, at 01:30:15 PM you wrote:

> У меня самого ровно такие же мысли, просто интуитивно. Что если в самой 
> сборке LTO не используется, то и нечего его туда засовывать насильно.
> 
> В проектах где производительность важна - критические места специально 
> оптимизируют в апстриме, ffmpeg как раз такой.
> 
> По ссылке https://www.altlinux.org/LTO - хотелось бы видеть конкретные 
> примеры из Альта, что скомпилировали такие-то нужные пакеты, была такая 
> производительность, стала такая, чтобы наглядно было видно за что 
> боремся. А не ссылки на статьи о том как это круто теоретически.
https://bugzilla.altlinux.org/34592 - пример для chromium, который,
собственно, был первым пакетом, собранным с LTO. И да, там был clang, а не
gcc.

-- 
WBR et al.

Re: [devel] I: gcc 11.2.1 && binutils 2.37

[Andrey Savchenko]

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

Днеь добрый!

On Fri, 24 Sep 2021 11:05:50 +0200 Konstantin Lepikhov wrote:
> Hi Илья!
> 
> On 09/24/2021, at 01:30:15 PM you wrote:
> 
> > У меня самого ровно такие же мысли, просто интуитивно. Что если в самой 
> > сборке LTO не используется, то и нечего его туда засовывать насильно.
> > 
> > В проектах где производительность важна - критические места специально 
> > оптимизируют в апстриме, ffmpeg как раз такой.
> > 
> > По ссылке https://www.altlinux.org/LTO - хотелось бы видеть конкретные 
> > примеры из Альта, что скомпилировали такие-то нужные пакеты, была такая 
> > производительность, стала такая, чтобы наглядно было видно за что 
> > боремся. А не ссылки на статьи о том как это круто теоретически.
> https://bugzilla.altlinux.org/34592 - пример для chromium, который,
> собственно, был первым пакетом, собранным с LTO. И да, там был clang, а не
> gcc.

Ну так, может, и стоило LTO использовать только для тех пакетов,
где от него заведомо есть практическая польза? А то включили
втихаря, а сообщество лишь перед фактом поставили.

Особенно гротескно это выглядит на фоне глобального использования
-O2, а не -O3. А ведь ситуация сравнима: для многих пакетов -O3
даст результат лучше, чем -O2, но кое-где может быть без разницы
или немного хуже, в редких крайних случаях вообще сломается сборка
либо полученный код, в т.ч. из-за проблем в самом коде.

Но с LTO подобные риски никого не остановили, в то же время
допотопный -O2 до сих пор с нами. Это непоследовательно.

Best regards,
Andrew Savchenko

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

Re: [devel] I: gcc 11.2.1 && binutils 2.37

[Gleb Fotengauer-Malinovskiy]

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

Hi,

On Fri, Sep 24, 2021 at 10:32:29AM +0700, Илья Курдюков wrote:
> В виду того, что произошло на днях с ruby, что я исправлял и оказалось что:
> 
> Не очень безопасный стиль програмирования приводит к тому, что 
> компилятор ломает код за счёт межобъектной оптимизации через включенный 
> LTO. И так как %check в спеках это скорее редкость для Альта, чем 
> правило - то появится внезапные падения на разном софте, при использовании.

А можно мне объяснить, что случилось на самом деле?  ruby-2.7.4-alt1 был
собран с LTO с помощью gcc10.  Тестовые пересборки показывали, что как
минимум сам ruby успешно пересобирался вплоть до 2021/0922, когда в Сизиф
попал gcc11, после чего сборка ruby начала очень громко падать.

ruby -- плохая иллюстрация вашей мысли или я просто не вижу, что сломалось
из-за того, что ruby-2.7.4-alt1 был собран с LTO?

> С библиотеками хуже, потому что будут вызывать падения в зависимых от 
> них проектах.
> 
> Поэтому совет всем: в любой непонятной ситуации - в первую очередь 
> проверить с выключенныи LTO. Если помогло, то или оставить выключенным 
> или искать обновления (или патчи в других дистрибутивах) или чинить самим.

-- 
glebfm

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 801 bytes --]

Re: [devel] I: gcc 11.2.1 && binutils 2.37

[Dmitry V. Levin]

On Fri, Sep 24, 2021 at 08:48:12AM +0300, Anton Farygin wrote:
> Да, Илья.
> 
> Есть ещё вот такая статья годичной давности:
> https://johnysswlab.com/link-time-optimizations-new-way-to-do-compiler-optimizations/
> 
> и там интересная заметка про ffmpeg, в которой говорится о том, что 
> выигрыш в сборке с LTO может быть нулевым.

Особенно если в случае LTO ещё и выключить в пакете часть ассемблерных
оптимизаций.


-- 
ldv

Re: [devel] I: gcc 11.2.1 && binutils 2.37

[Anton Farygin]

On 24.09.2021 18:18, Dmitry V. Levin wrote:
> On Fri, Sep 24, 2021 at 08:48:12AM +0300, Anton Farygin wrote:
>> Да, Илья.
>>
>> Есть ещё вот такая статья годичной давности:
>> https://johnysswlab.com/link-time-optimizations-new-way-to-do-compiler-optimizations/
>>
>> и там интересная заметка про ffmpeg, в которой говорится о том, что
>> выигрыш в сборке с LTO может быть нулевым.
> Особенно если в случае LTO ещё и выключить в пакете часть ассемблерных
> оптимизаций.

Да, конечно. enable-lto может делать всё что угодно для достижения цели.

Re: [devel] I: gcc 11.2.1 && binutils 2.37

[Dmitry V. Levin]

On Fri, Sep 24, 2021 at 01:30:15PM +0700, Илья Курдюков wrote:
> У меня самого ровно такие же мысли, просто интуитивно. Что если в самой 
> сборке LTO не используется, то и нечего его туда засовывать насильно.

Софтовые проекты очень редко добавляют сборочную конфигурацию для LTO, -O2,
и других компиляторных оптимизаций.  Почти во всех софтовых проектах LTO
просто должно работать, как работает -O2.

> В проектах где производительность важна - критические места специально 
> оптимизируют в апстриме, ffmpeg как раз такой.

В этом ffmpeg при включении LTO выключают часть ассемблерных оптимизаций,
вряд ли это правильно.

> По ссылке https://www.altlinux.org/LTO - хотелось бы видеть конкретные 
> примеры из Альта, что скомпилировали такие-то нужные пакеты, была такая 
> производительность, стала такая, чтобы наглядно было видно за что 
> боремся. А не ссылки на статьи о том как это круто теоретически.

Поскольку Альт в теме LTO далеко не является первопроходцем, всё это
при желании можно найти.  Впрочем, если кто-то интересуется подобными
исследованиями именно для Альт, я не возражаю.

> Я ваши дискуссии внимательно не читал, потому что занимаюсь починкой 
> пакетов для Эльбруса, где -flto просто не поддерживается и игнорируется 
> компилятором. Однако это повлияло и на меня, когда несколько проектов в 
> ряд оказываются сломаны из-за LTO, когда я пытаюсь добавить патч для 
> Эльбруса. Как и много замечаю уже кем-то сделанных фиксов проблем с LTO.
> 
> Моё впечатление, что создали себе гору проблем из-за "модной" фичи, не 
> приносящей никакого заметного вклада в реальную производительность.

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


-- 
ldv

Re: [devel] I: gcc 11.2.1 && binutils 2.37

[Dmitry V. Levin]

On Fri, Sep 24, 2021 at 03:06:40PM +0300, Andrey Savchenko wrote:
> Днеь добрый!
> 
> On Fri, 24 Sep 2021 11:05:50 +0200 Konstantin Lepikhov wrote:
> > Hi Илья!
> > 
> > On 09/24/2021, at 01:30:15 PM you wrote:
> > 
> > > У меня самого ровно такие же мысли, просто интуитивно. Что если в самой 
> > > сборке LTO не используется, то и нечего его туда засовывать насильно.
> > > 
> > > В проектах где производительность важна - критические места специально 
> > > оптимизируют в апстриме, ffmpeg как раз такой.
> > > 
> > > По ссылке https://www.altlinux.org/LTO - хотелось бы видеть конкретные 
> > > примеры из Альта, что скомпилировали такие-то нужные пакеты, была такая 
> > > производительность, стала такая, чтобы наглядно было видно за что 
> > > боремся. А не ссылки на статьи о том как это круто теоретически.
> > https://bugzilla.altlinux.org/34592 - пример для chromium, который,
> > собственно, был первым пакетом, собранным с LTO. И да, там был clang, а не
> > gcc.
> 
> Ну так, может, и стоило LTO использовать только для тех пакетов,
> где от него заведомо есть практическая польза? А то включили
> втихаря, а сообщество лишь перед фактом поставили.

Очевидно, что от LTO по умолчанию есть практическая польза.

> Особенно гротескно это выглядит на фоне глобального использования
> -O2, а не -O3. А ведь ситуация сравнима: для многих пакетов -O3
> даст результат лучше, чем -O2, но кое-где может быть без разницы
> или немного хуже, в редких крайних случаях вообще сломается сборка
> либо полученный код, в т.ч. из-за проблем в самом коде.
> 
> Но с LTO подобные риски никого не остановили, в то же время
> допотопный -O2 до сих пор с нами. Это непоследовательно.

Очевидно, что сравнение LTO с -O3 некорректно, достаточно просто
перечислить список оптимизаций, которые включает -O3.

На все эти ваши вопросы, мол продемонстрируйте, что от LTO есть польза,
отвечаю, что это очевидно.  Если вас интересуют численные показатели для
тех или иных пакетов и задач, можете это изучить и рассказать на очередной
конференции.


-- 
ldv

Re: [devel] I: gcc 11.2.1 && binutils 2.37

[Илья Курдюков]

"Если я что-то утверждаю, я не обязан представлять доказательства. Если 
вы утверждаете обратное, опровергая меня, это вы должны доказательства 
представлять." (с) Никита Михалков.

Давайте опрос проведём, кому это очевидно, а кому это совершенно не 
очевидно. Уверен что вторые будут в подавляющем большинстве. Пусть 
хотябы пара человек подтвердит, что им так же очевидно как вам.

On 24.09.2021 22:34, Dmitry V. Levin wrote:
>
> Очевидно, что сравнение LTO с -O3 некорректно, достаточно просто
> перечислить список оптимизаций, которые включает -O3.
>
> На все эти ваши вопросы, мол продемонстрируйте, что от LTO есть польза,
> отвечаю, что это очевидно.  Если вас интересуют численные показатели для
> тех или иных пакетов и задач, можете это изучить и рассказать на очередной
> конференции.
>
>

Re: [devel] I: gcc 11.2.1 && binutils 2.37

[Dmitry V. Levin]

On Fri, Sep 24, 2021 at 10:41:50PM +0700, Илья Курдюков wrote:
> "Если я что-то утверждаю, я не обязан представлять доказательства. Если 
> вы утверждаете обратное, опровергая меня, это вы должны доказательства 
> представлять." (с) Никита Михалков.
> 
> Давайте опрос проведём, кому это очевидно, а кому это совершенно не 
> очевидно. Уверен что вторые будут в подавляющем большинстве. Пусть 
> хотябы пара человек подтвердит, что им так же очевидно как вам.

Для того, чтобы очевидные вещи стали очевидными, надо открыть глаза,
иногда для этого надо прикладывать усилия. :)


-- 
ldv

Re: [devel] I: gcc 11.2.1 && binutils 2.37

[Andrey Savchenko]

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

On Fri, 24 Sep 2021 18:18:04 +0300 Dmitry V. Levin wrote:
> On Fri, Sep 24, 2021 at 08:48:12AM +0300, Anton Farygin wrote:
> > Да, Илья.
> > 
> > Есть ещё вот такая статья годичной давности:
> > https://johnysswlab.com/link-time-optimizations-new-way-to-do-compiler-optimizations/
> > 
> > и там интересная заметка про ffmpeg, в которой говорится о том, что 
> > выигрыш в сборке с LTO может быть нулевым.
> 
> Особенно если в случае LTO ещё и выключить в пакете часть ассемблерных
> оптимизаций.

Если ты внимательно читал статью, то там и в тесте без LTO они
оставались выключенными. А вообще, тот факт, что ради LTO
приходится отключать сильные оптимизации и что за столько лет оно
не научилось top level asm, говорит не в пользу повсеместного
внедрения LTO.

Best regards,
Andrew Savchenko

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

Re: [devel] I: gcc 11.2.1 && binutils 2.37

[Andrey Savchenko]

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

On Fri, 24 Sep 2021 18:34:40 +0300 Dmitry V. Levin wrote:
> On Fri, Sep 24, 2021 at 03:06:40PM +0300, Andrey Savchenko wrote:
> > Днеь добрый!
> > 
> > On Fri, 24 Sep 2021 11:05:50 +0200 Konstantin Lepikhov wrote:
> > > Hi Илья!
> > > 
> > > On 09/24/2021, at 01:30:15 PM you wrote:
> > > 
> > > > У меня самого ровно такие же мысли, просто интуитивно. Что если в самой 
> > > > сборке LTO не используется, то и нечего его туда засовывать насильно.
> > > > 
> > > > В проектах где производительность важна - критические места специально 
> > > > оптимизируют в апстриме, ffmpeg как раз такой.
> > > > 
> > > > По ссылке https://www.altlinux.org/LTO - хотелось бы видеть конкретные 
> > > > примеры из Альта, что скомпилировали такие-то нужные пакеты, была такая 
> > > > производительность, стала такая, чтобы наглядно было видно за что 
> > > > боремся. А не ссылки на статьи о том как это круто теоретически.
> > > https://bugzilla.altlinux.org/34592 - пример для chromium, который,
> > > собственно, был первым пакетом, собранным с LTO. И да, там был clang, а не
> > > gcc.
> > 
> > Ну так, может, и стоило LTO использовать только для тех пакетов,
> > где от него заведомо есть практическая польза? А то включили
> > втихаря, а сообщество лишь перед фактом поставили.
> 
> Очевидно, что от LTO по умолчанию есть практическая польза.

Как говорил мой профессор мат.анализа, «очевидно — значит легко
доказуемо». Прошу доказать в масштабах дистрибутива.
 
> > Особенно гротескно это выглядит на фоне глобального использования
> > -O2, а не -O3. А ведь ситуация сравнима: для многих пакетов -O3
> > даст результат лучше, чем -O2, но кое-где может быть без разницы
> > или немного хуже, в редких крайних случаях вообще сломается сборка
> > либо полученный код, в т.ч. из-за проблем в самом коде.
> > 
> > Но с LTO подобные риски никого не остановили, в то же время
> > допотопный -O2 до сих пор с нами. Это непоследовательно.
> 
> Очевидно, что сравнение LTO с -O3 некорректно, достаточно просто
> перечислить список оптимизаций, которые включает -O3.

Прошу пояснить как из этих перечней следует сделанное выше
утверждение.
 
> На все эти ваши вопросы, мол продемонстрируйте, что от LTO есть польза,
> отвечаю, что это очевидно.  Если вас интересуют численные показатели для
> тех или иных пакетов и задач, можете это изучить и рассказать на очередной
> конференции.

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

Best regards,
Andrew Savchenko

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

Re: [devel] I: gcc 11.2.1 && binutils 2.37

[Dmitry V. Levin]

On Fri, Sep 24, 2021 at 08:04:59PM +0300, Andrey Savchenko wrote:
> On Fri, 24 Sep 2021 18:18:04 +0300 Dmitry V. Levin wrote:
> > On Fri, Sep 24, 2021 at 08:48:12AM +0300, Anton Farygin wrote:
> > > Да, Илья.
> > > 
> > > Есть ещё вот такая статья годичной давности:
> > > https://johnysswlab.com/link-time-optimizations-new-way-to-do-compiler-optimizations/
> > > 
> > > и там интересная заметка про ffmpeg, в которой говорится о том, что 
> > > выигрыш в сборке с LTO может быть нулевым.
> > 
> > Особенно если в случае LTO ещё и выключить в пакете часть ассемблерных
> > оптимизаций.
> 
> Если ты внимательно читал статью, то там и в тесте без LTO они
> оставались выключенными. А вообще, тот факт, что ради LTO
> приходится отключать сильные оптимизации

Не надо ради LTO отключать сильные оптимизации.
Странно, что в ffmpeg так сделали.

Вообще статья действительно старая в том смысле, что оперирует старыми
версиями: gcc8 отстаёт от gcc11 на 3 года.  Гораздо интереснее было бы
увидеть результаты по текущей версии.

> и что за столько лет оно не научилось top level asm,

Насколько я понимаю, и не научится - случаев мало, разработчикам не
интересно.  Хорошо, что хоть __attribute__((__symver__)) добавили.


-- 
ldv

Re: [devel] I: gcc 11.2.1 && binutils 2.37

[Anton Farygin]

On 24.09.2021 19:10, Dmitry V. Levin wrote:
> On Fri, Sep 24, 2021 at 10:41:50PM +0700, Илья Курдюков wrote:
>> "Если я что-то утверждаю, я не обязан представлять доказательства. Если
>> вы утверждаете обратное, опровергая меня, это вы должны доказательства
>> представлять." (с) Никита Михалков.
>>
>> Давайте опрос проведём, кому это очевидно, а кому это совершенно не
>> очевидно. Уверен что вторые будут в подавляющем большинстве. Пусть
>> хотябы пара человек подтвердит, что им так же очевидно как вам.
> Для того, чтобы очевидные вещи стали очевидными, надо открыть глаза,
> иногда для этого надо прикладывать усилия. :)
>
>
Очевидно, что есть очевидные пакеты, в которых от LTO есть польза. Также 
очевидно, что есть пакеты, которые не поддерживают LTO и от этого им вред.

А ещё очевидно, что никто не сравнивал численные показатели пользы и 
вреда от LTO и тем более не сравнивал это с -O3 или отказом от поддержки 
старых x86 процессоров.

Вот тут Миловидов на простом примере проводит сравнение оптимизаций gcc 
и clang (в случае с C++, но там обычная сумма):

https://youtu.be/MJJfWoWJq0o?t=719

Можно ради интереса посмотреть разницу между нашим O2, O3 и включением 
SSE4.2

Re: [devel] I: gcc 11.2.1 && binutils 2.37

[Andrey Savchenko]

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

On Fri, 24 Sep 2021 21:29:36 +0300 Dmitry V. Levin wrote:
> On Fri, Sep 24, 2021 at 08:04:59PM +0300, Andrey Savchenko wrote:
> > On Fri, 24 Sep 2021 18:18:04 +0300 Dmitry V. Levin wrote:
> > > On Fri, Sep 24, 2021 at 08:48:12AM +0300, Anton Farygin wrote:
> > > > Да, Илья.
> > > > 
> > > > Есть ещё вот такая статья годичной давности:
> > > > https://johnysswlab.com/link-time-optimizations-new-way-to-do-compiler-optimizations/
> > > > 
> > > > и там интересная заметка про ffmpeg, в которой говорится о том, что 
> > > > выигрыш в сборке с LTO может быть нулевым.
> > > 
> > > Особенно если в случае LTO ещё и выключить в пакете часть ассемблерных
> > > оптимизаций.
> > 
> > Если ты внимательно читал статью, то там и в тесте без LTO они
> > оставались выключенными. А вообще, тот факт, что ради LTO
> > приходится отключать сильные оптимизации
> 
> Не надо ради LTO отключать сильные оптимизации.
> Странно, что в ffmpeg так сделали.

Пожалуйста, прочитай внимательно исходную ссылку. Не разработчики
ffmpeg так сделали, а автор теста выключил asm, чтоб можно было
сравнить ffmpeg с lto и без lto в чистом виде.

А автор так сделал потому, что при включенном lto *некоторые* asm
оптимизации ffmpeg выключаются и сравнение было бы некорректным,
поскольку сравнивалась бы не разница с lto и без, а разница full
asm w/o lto vs lto + partial asm. Детали можно посмотреть в ffmpeg
configure — там всё просто и понятно.

Так что цифры по ссылке — это чистая разница на коде с LTO и без,
из которых видно, что эффект от LTO на качественно написанном коде
очень слабый, а время на сборку удваивается, т.е. овчинка выделки не
стоит.

В моём понимании LTO наиболее эффективен там, где много
неоптимального, грязного или вообще мёртвого кода. Что chromium
хорошо подтверждает.

> > и что за столько лет оно не научилось top level asm,
> 
> Насколько я понимаю, и не научится - случаев мало, разработчикам не
> интересно.  Хорошо, что хоть __attribute__((__symver__)) добавили.

Ну если ffmpeg — это редкий и неинтересный для разработчиков gcc
случай, то вопросов больше не имею.

Best regards,
Andrew Savchenko

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

Re: [devel] I: gcc 11.2.1 && binutils 2.37

[Dmitry V. Levin]

On Fri, Sep 24, 2021 at 10:48:06PM +0300, Andrey Savchenko wrote:
> On Fri, 24 Sep 2021 21:29:36 +0300 Dmitry V. Levin wrote:
> > On Fri, Sep 24, 2021 at 08:04:59PM +0300, Andrey Savchenko wrote:
> > > On Fri, 24 Sep 2021 18:18:04 +0300 Dmitry V. Levin wrote:
> > > > On Fri, Sep 24, 2021 at 08:48:12AM +0300, Anton Farygin wrote:
> > > > > Да, Илья.
> > > > > 
> > > > > Есть ещё вот такая статья годичной давности:
> > > > > https://johnysswlab.com/link-time-optimizations-new-way-to-do-compiler-optimizations/
> > > > > 
> > > > > и там интересная заметка про ffmpeg, в которой говорится о том, что 
> > > > > выигрыш в сборке с LTO может быть нулевым.
> > > > 
> > > > Особенно если в случае LTO ещё и выключить в пакете часть ассемблерных
> > > > оптимизаций.
> > > 
> > > Если ты внимательно читал статью, то там и в тесте без LTO они
> > > оставались выключенными. А вообще, тот факт, что ради LTO
> > > приходится отключать сильные оптимизации
> > 
> > Не надо ради LTO отключать сильные оптимизации.
> > Странно, что в ffmpeg так сделали.
> 
> Пожалуйста, прочитай внимательно исходную ссылку. Не разработчики
> ffmpeg так сделали, а автор теста выключил asm, чтоб можно было
> сравнить ffmpeg с lto и без lto в чистом виде.

Я про то, что именно разработчики ffmpeg для включения LTO почему-то
выключают часть ассемблерной оптимизации.


-- 
ldv

Re: [devel] I: gcc 11.2.1 && binutils 2.37

[Dmitry V. Levin]

On Fri, Sep 24, 2021 at 10:13:49PM +0300, Anton Farygin wrote:
> On 24.09.2021 19:10, Dmitry V. Levin wrote:
> > On Fri, Sep 24, 2021 at 10:41:50PM +0700, Илья Курдюков wrote:
> >> "Если я что-то утверждаю, я не обязан представлять доказательства. Если
> >> вы утверждаете обратное, опровергая меня, это вы должны доказательства
> >> представлять." (с) Никита Михалков.
> >>
> >> Давайте опрос проведём, кому это очевидно, а кому это совершенно не
> >> очевидно. Уверен что вторые будут в подавляющем большинстве. Пусть
> >> хотябы пара человек подтвердит, что им так же очевидно как вам.
> > Для того, чтобы очевидные вещи стали очевидными, надо открыть глаза,
> > иногда для этого надо прикладывать усилия. :)
> >
> Очевидно, что есть очевидные пакеты, в которых от LTO есть польза. Также 

Есть пакеты, которым LTO принесло пользу,
не связанную с увеличением производительности, например:
https://sourceforge.net/p/linuxquota/code/ci/b0f95e3954f85d97a99f8a08645418945484dbca
- это off-by-one buffer overflow fix, если что.


-- 
ldv

Re: [devel] I: gcc 11.2.1 && binutils 2.37

[Andrey Savchenko]

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

On Fri, 24 Sep 2021 23:20:40 +0300 Dmitry V. Levin wrote:
> On Fri, Sep 24, 2021 at 10:48:06PM +0300, Andrey Savchenko wrote:
> > On Fri, 24 Sep 2021 21:29:36 +0300 Dmitry V. Levin wrote:
> > > On Fri, Sep 24, 2021 at 08:04:59PM +0300, Andrey Savchenko wrote:
> > > > On Fri, 24 Sep 2021 18:18:04 +0300 Dmitry V. Levin wrote:
> > > > > On Fri, Sep 24, 2021 at 08:48:12AM +0300, Anton Farygin wrote:
> > > > > > Да, Илья.
> > > > > > 
> > > > > > Есть ещё вот такая статья годичной давности:
> > > > > > https://johnysswlab.com/link-time-optimizations-new-way-to-do-compiler-optimizations/
> > > > > > 
> > > > > > и там интересная заметка про ffmpeg, в которой говорится о том, что 
> > > > > > выигрыш в сборке с LTO может быть нулевым.
> > > > > 
> > > > > Особенно если в случае LTO ещё и выключить в пакете часть ассемблерных
> > > > > оптимизаций.
> > > > 
> > > > Если ты внимательно читал статью, то там и в тесте без LTO они
> > > > оставались выключенными. А вообще, тот факт, что ради LTO
> > > > приходится отключать сильные оптимизации
> > > 
> > > Не надо ради LTO отключать сильные оптимизации.
> > > Странно, что в ffmpeg так сделали.
> > 
> > Пожалуйста, прочитай внимательно исходную ссылку. Не разработчики
> > ffmpeg так сделали, а автор теста выключил asm, чтоб можно было
> > сравнить ffmpeg с lto и без lto в чистом виде.
> 
> Я про то, что именно разработчики ffmpeg для включения LTO почему-то
> выключают часть ассемблерной оптимизации.

Потому что gcc неспособен скомпилировать все ассемблерные
оптимизации вместе с LTO. Но, как мы уже выяснили, разработчиков
gcc это не особо волнует.

Best regards,
Andrew Savchenko

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

Re: [devel] I: gcc 11.2.1 && binutils 2.37

[Anton Farygin]

On 24.09.2021 23:47, Andrey Savchenko wrote:
> On Fri, 24 Sep 2021 23:20:40 +0300 Dmitry V. Levin wrote:
>> On Fri, Sep 24, 2021 at 10:48:06PM +0300, Andrey Savchenko wrote:
>>> On Fri, 24 Sep 2021 21:29:36 +0300 Dmitry V. Levin wrote:
>>>> On Fri, Sep 24, 2021 at 08:04:59PM +0300, Andrey Savchenko wrote:
>>>>> On Fri, 24 Sep 2021 18:18:04 +0300 Dmitry V. Levin wrote:
>>>>>> On Fri, Sep 24, 2021 at 08:48:12AM +0300, Anton Farygin wrote:
>>>>>>> Да, Илья.
>>>>>>>
>>>>>>> Есть ещё вот такая статья годичной давности:
>>>>>>> https://johnysswlab.com/link-time-optimizations-new-way-to-do-compiler-optimizations/
>>>>>>>
>>>>>>> и там интересная заметка про ffmpeg, в которой говорится о том, что
>>>>>>> выигрыш в сборке с LTO может быть нулевым.
>>>>>> Особенно если в случае LTO ещё и выключить в пакете часть ассемблерных
>>>>>> оптимизаций.
>>>>> Если ты внимательно читал статью, то там и в тесте без LTO они
>>>>> оставались выключенными. А вообще, тот факт, что ради LTO
>>>>> приходится отключать сильные оптимизации
>>>> Не надо ради LTO отключать сильные оптимизации.
>>>> Странно, что в ffmpeg так сделали.
>>> Пожалуйста, прочитай внимательно исходную ссылку. Не разработчики
>>> ffmpeg так сделали, а автор теста выключил asm, чтоб можно было
>>> сравнить ffmpeg с lto и без lto в чистом виде.
>> Я про то, что именно разработчики ffmpeg для включения LTO почему-то
>> выключают часть ассемблерной оптимизации.
> Потому что gcc неспособен скомпилировать все ассемблерные
> оптимизации вместе с LTO. Но, как мы уже выяснили, разработчиков
> gcc это не особо волнует.
>
ну это же прямо первой ссылкой гуглится:

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=57703

Re: [devel] I: gcc 11.2.1 && binutils 2.37

[Andrey Savchenko]

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

On Sat, 25 Sep 2021 00:06:34 +0300 Anton Farygin wrote:
> On 24.09.2021 23:47, Andrey Savchenko wrote:
> > On Fri, 24 Sep 2021 23:20:40 +0300 Dmitry V. Levin wrote:
> >> On Fri, Sep 24, 2021 at 10:48:06PM +0300, Andrey Savchenko wrote:
> >>> On Fri, 24 Sep 2021 21:29:36 +0300 Dmitry V. Levin wrote:
> >>>> On Fri, Sep 24, 2021 at 08:04:59PM +0300, Andrey Savchenko wrote:
> >>>>> On Fri, 24 Sep 2021 18:18:04 +0300 Dmitry V. Levin wrote:
> >>>>>> On Fri, Sep 24, 2021 at 08:48:12AM +0300, Anton Farygin wrote:
> >>>>>>> Да, Илья.
> >>>>>>>
> >>>>>>> Есть ещё вот такая статья годичной давности:
> >>>>>>> https://johnysswlab.com/link-time-optimizations-new-way-to-do-compiler-optimizations/
> >>>>>>>
> >>>>>>> и там интересная заметка про ffmpeg, в которой говорится о том, что
> >>>>>>> выигрыш в сборке с LTO может быть нулевым.
> >>>>>> Особенно если в случае LTO ещё и выключить в пакете часть ассемблерных
> >>>>>> оптимизаций.
> >>>>> Если ты внимательно читал статью, то там и в тесте без LTO они
> >>>>> оставались выключенными. А вообще, тот факт, что ради LTO
> >>>>> приходится отключать сильные оптимизации
> >>>> Не надо ради LTO отключать сильные оптимизации.
> >>>> Странно, что в ffmpeg так сделали.
> >>> Пожалуйста, прочитай внимательно исходную ссылку. Не разработчики
> >>> ffmpeg так сделали, а автор теста выключил asm, чтоб можно было
> >>> сравнить ffmpeg с lto и без lto в чистом виде.
> >> Я про то, что именно разработчики ffmpeg для включения LTO почему-то
> >> выключают часть ассемблерной оптимизации.
> > Потому что gcc неспособен скомпилировать все ассемблерные
> > оптимизации вместе с LTO. Но, как мы уже выяснили, разработчиков
> > gcc это не особо волнует.
> >
> ну это же прямо первой ссылкой гуглится:
> 
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=57703

Гуглить ничего не нужно: я изначально про этот баг и говорю, он
даже упомянут на нашей вики. Как мы видим из этого бага, за более
чем 7 лет (семь, Карл!) разработчики gcc не почесались проблему
исправить. Мало того, она даже никому не назначена:
Assignee:	Not yet assigned to anyone

Что красноречиво говорит об уровне поддержки LTO в gcc.

-O3 лучше поддерживается (без шуток), давайте на него перейдём —
пользы больше будет, по крайней мере на 64-битных архитектурах.

Best regards,
Andrew Savchenko

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

Re: [devel] I: gcc 11.2.1 && binutils 2.37

[Anton Farygin]

On 25.09.2021 01:19, Andrey Savchenko wrote:
> On Sat, 25 Sep 2021 00:06:34 +0300 Anton Farygin wrote:
>> On 24.09.2021 23:47, Andrey Savchenko wrote:
>>> On Fri, 24 Sep 2021 23:20:40 +0300 Dmitry V. Levin wrote:
>>>> On Fri, Sep 24, 2021 at 10:48:06PM +0300, Andrey Savchenko wrote:
>>>>> On Fri, 24 Sep 2021 21:29:36 +0300 Dmitry V. Levin wrote:
>>>>>> On Fri, Sep 24, 2021 at 08:04:59PM +0300, Andrey Savchenko wrote:
>>>>>>> On Fri, 24 Sep 2021 18:18:04 +0300 Dmitry V. Levin wrote:
>>>>>>>> On Fri, Sep 24, 2021 at 08:48:12AM +0300, Anton Farygin wrote:
>>>>>>>>> Да, Илья.
>>>>>>>>>
>>>>>>>>> Есть ещё вот такая статья годичной давности:
>>>>>>>>> https://johnysswlab.com/link-time-optimizations-new-way-to-do-compiler-optimizations/
>>>>>>>>>
>>>>>>>>> и там интересная заметка про ffmpeg, в которой говорится о том, что
>>>>>>>>> выигрыш в сборке с LTO может быть нулевым.
>>>>>>>> Особенно если в случае LTO ещё и выключить в пакете часть ассемблерных
>>>>>>>> оптимизаций.
>>>>>>> Если ты внимательно читал статью, то там и в тесте без LTO они
>>>>>>> оставались выключенными. А вообще, тот факт, что ради LTO
>>>>>>> приходится отключать сильные оптимизации
>>>>>> Не надо ради LTO отключать сильные оптимизации.
>>>>>> Странно, что в ffmpeg так сделали.
>>>>> Пожалуйста, прочитай внимательно исходную ссылку. Не разработчики
>>>>> ffmpeg так сделали, а автор теста выключил asm, чтоб можно было
>>>>> сравнить ffmpeg с lto и без lto в чистом виде.
>>>> Я про то, что именно разработчики ffmpeg для включения LTO почему-то
>>>> выключают часть ассемблерной оптимизации.
>>> Потому что gcc неспособен скомпилировать все ассемблерные
>>> оптимизации вместе с LTO. Но, как мы уже выяснили, разработчиков
>>> gcc это не особо волнует.
>>>
>> ну это же прямо первой ссылкой гуглится:
>>
>> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=57703
> Гуглить ничего не нужно: я изначально про этот баг и говорю, он
> даже упомянут на нашей вики. Как мы видим из этого бага, за более
> чем 7 лет (семь, Карл!) разработчики gcc не почесались проблему
> исправить. Мало того, она даже никому не назначена:
> Assignee:	Not yet assigned to anyone
>
> Что красноречиво говорит об уровне поддержки LTO в gcc.
>
> -O3 лучше поддерживается (без шуток), давайте на него перейдём —
> пользы больше будет, по крайней мере на 64-битных архитектурах.

А кто-то запрещает сейчас собирать пакет с -O3 ?

Re: [devel] I: gcc 11.2.1 && binutils 2.37

[Anton Farygin]

On 24.09.2021 21:29, Dmitry V. Levin wrote:
> On Fri, Sep 24, 2021 at 08:04:59PM +0300, Andrey Savchenko wrote:
>> On Fri, 24 Sep 2021 18:18:04 +0300 Dmitry V. Levin wrote:
>>> On Fri, Sep 24, 2021 at 08:48:12AM +0300, Anton Farygin wrote:
>>>> Да, Илья.
>>>>
>>>> Есть ещё вот такая статья годичной давности:
>>>> https://johnysswlab.com/link-time-optimizations-new-way-to-do-compiler-optimizations/
>>>>
>>>> и там интересная заметка про ffmpeg, в которой говорится о том, что
>>>> выигрыш в сборке с LTO может быть нулевым.
>>> Особенно если в случае LTO ещё и выключить в пакете часть ассемблерных
>>> оптимизаций.
>> Если ты внимательно читал статью, то там и в тесте без LTO они
>> оставались выключенными. А вообще, тот факт, что ради LTO
>> приходится отключать сильные оптимизации
> Не надо ради LTO отключать сильные оптимизации.
> Странно, что в ffmpeg так сделали.

Всё что сделали в ffmpeg для LTO звучит вот так:

     /* When direct symbol references are used in code passed to a 
compiler that does not support them
      *  then these references need to be converted to named asm 
constraints instead.
      * Instead of returning a direct symbol MANGLE now returns a named 
constraint for that specific symbol.
      * In order for this to work there must also be a corresponding 
entry in the asm-interface. To add this
      *  entry use the macro NAMED_CONSTRAINTS() and pass in a list of 
each symbol reference used in the
      *  corresponding block of code. (e.g. 
NAMED_CONSTRAINTS(var1,var2,var3) where var1 is the first symbol etc. ).
      * If there are already existing constraints then use 
NAMED_CONSTRAINTS_ADD to add to the existing constraint list.
      */

Сложно оценить, какая деградация производительности будет в этом месте, 
но то что она будет - это 100%.



>
> Вообще статья действительно старая в том смысле, что оперирует старыми
> версиями: gcc8 отстаёт от gcc11 на 3 года.  Гораздо интереснее было бы
> увидеть результаты по текущей версии.
Да, мне тоже было бы интересно это увидеть. Если найду время - посмотрю.

Re: [devel] I: gcc 11.2.1 && binutils 2.37

[Andrey Savchenko]

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

On Sat, 25 Sep 2021 11:04:40 +0300 Anton Farygin wrote:
> On 25.09.2021 01:19, Andrey Savchenko wrote:
> > On Sat, 25 Sep 2021 00:06:34 +0300 Anton Farygin wrote:
> >> On 24.09.2021 23:47, Andrey Savchenko wrote:
> >>> On Fri, 24 Sep 2021 23:20:40 +0300 Dmitry V. Levin wrote:
> >>>> On Fri, Sep 24, 2021 at 10:48:06PM +0300, Andrey Savchenko wrote:
> >>>>> On Fri, 24 Sep 2021 21:29:36 +0300 Dmitry V. Levin wrote:
> >>>>>> On Fri, Sep 24, 2021 at 08:04:59PM +0300, Andrey Savchenko wrote:
> >>>>>>> On Fri, 24 Sep 2021 18:18:04 +0300 Dmitry V. Levin wrote:
> >>>>>>>> On Fri, Sep 24, 2021 at 08:48:12AM +0300, Anton Farygin wrote:
> >>>>>>>>> Да, Илья.
> >>>>>>>>>
> >>>>>>>>> Есть ещё вот такая статья годичной давности:
> >>>>>>>>> https://johnysswlab.com/link-time-optimizations-new-way-to-do-compiler-optimizations/
> >>>>>>>>>
> >>>>>>>>> и там интересная заметка про ffmpeg, в которой говорится о том, что
> >>>>>>>>> выигрыш в сборке с LTO может быть нулевым.
> >>>>>>>> Особенно если в случае LTO ещё и выключить в пакете часть ассемблерных
> >>>>>>>> оптимизаций.
> >>>>>>> Если ты внимательно читал статью, то там и в тесте без LTO они
> >>>>>>> оставались выключенными. А вообще, тот факт, что ради LTO
> >>>>>>> приходится отключать сильные оптимизации
> >>>>>> Не надо ради LTO отключать сильные оптимизации.
> >>>>>> Странно, что в ffmpeg так сделали.
> >>>>> Пожалуйста, прочитай внимательно исходную ссылку. Не разработчики
> >>>>> ffmpeg так сделали, а автор теста выключил asm, чтоб можно было
> >>>>> сравнить ffmpeg с lto и без lto в чистом виде.
> >>>> Я про то, что именно разработчики ffmpeg для включения LTO почему-то
> >>>> выключают часть ассемблерной оптимизации.
> >>> Потому что gcc неспособен скомпилировать все ассемблерные
> >>> оптимизации вместе с LTO. Но, как мы уже выяснили, разработчиков
> >>> gcc это не особо волнует.
> >>>
> >> ну это же прямо первой ссылкой гуглится:
> >>
> >> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=57703
> > Гуглить ничего не нужно: я изначально про этот баг и говорю, он
> > даже упомянут на нашей вики. Как мы видим из этого бага, за более
> > чем 7 лет (семь, Карл!) разработчики gcc не почесались проблему
> > исправить. Мало того, она даже никому не назначена:
> > Assignee:	Not yet assigned to anyone
> >
> > Что красноречиво говорит об уровне поддержки LTO в gcc.
> >
> > -O3 лучше поддерживается (без шуток), давайте на него перейдём —
> > пользы больше будет, по крайней мере на 64-битных архитектурах.
> 
> А кто-то запрещает сейчас собирать пакет с -O3 ?

Речь про общий переход на уровне репозитория с помощью %optflags
rpmbuild.

Best regards,
Andrew Savchenko

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

Re: [devel] sisyphus_e2k vs GPL

[Dmitry V. Levin]

On Thu, Sep 23, 2021 at 11:17:55AM +0300, Michael Shigorin wrote:
[...]
> я сейчас нечасто добираюсь
> до собственно поддержки пакетов в основном сизифе,
> почти полностью переключившись на sisyphus_e2k.

В GPLv2 написано буквально следующее:

   6. Each time you redistribute the Program (or any work based on the
   Program), the recipient automatically receives a license from the
   original licensor to copy, distribute or modify the Program subject to
   these terms and conditions. You may not impose any further restrictions
   on the recipients' exercise of the rights granted herein.

Другими словами, GPLv2 запрещает МЦСТ налагать дополнительные ограничения
на распространение ядра linux и другого софта под GPLv2.

   7. If, as a consequence of a court judgment or allegation of patent
   infringement or for any other reason (not limited to patent issues),
   conditions are imposed on you (whether by court order, agreement
   or otherwise) that contradict the conditions of this License, they
   do not excuse you from the conditions of this License. If you cannot
   distribute so as to satisfy simultaneously your obligations under this
   License and any other pertinent obligations, then as a consequence
   you may not distribute the Program at all. For example, if a patent
   license would not permit royalty-free redistribution of the Program
   by all those who receive copies directly or indirectly through you,
   then the only way you could satisfy both it and this License would
   be to refrain entirely from distribution of the Program.

Другими словами, если МЦСТ по той или иной причине не может выполнить все
условия GPLv2, то МЦСТ вообще не имеет права распространять ядро linux и
другой софт под GPLv2.

Аналогично GPLv3 п.10 и п.12.

Всякий раз, когда МЦСТ распространяет GPL-софт под NDA, МЦСТ совершает
нарушение, при котором, согласно GPL, МЦСТ утрачивает право на
распространение, в результате чего каждый акт распространения под NDA
становится противоправным действием, а всякий, кто получил GPL-софт под
NDA, на самом деле получил его нелегально, и всякое его использование,
изменение, и дальнейшее распространение автоматически нелегально.

Ни для кого не секрет, что МЦСТ является давним и последовательным
нарушителем GPL, и я не понимаю, почему человек, "почти полностью
переключившись на sisyphus_e2k", ещё и гордится своим соучастием
в этом противозаконии.


-- 
ldv

Re: [devel] sisyphus_e2k vs GPL

[Michael Shigorin]

On Mon, Sep 27, 2021 at 01:46:28PM +0300, Dmitry V. Levin wrote:
> Ни для кого не секрет, что МЦСТ является давним и последовательным
> нарушителем GPL, и я не понимаю, почему человек, "почти полностью
> переключившись на sisyphus_e2k", ещё и гордится своим соучастием
> в этом противозаконии.

Гм, а чем тут гордиться?  Это как ты бы гордился своим когдашним
сотрудничеством с так называемой "оппозицией", бишь иноагентами.

Безобразие с GPL (и не только) стараемся выправить, а упомянул
с тем, что сейчас мне не особо до пакетов на x86 (только не на
время выборов).

При этом прямо обозначу, что лицензии на ПО мне важны, но не
важнее интересов Родины -- в этом плане я и впрямь не лучше
тех же израильских террористов, убивших недавно очередного
иранского физика-ядерщика.

Можешь расчехлять помидоры, но сперва -- зеркало.

-- 
 ---- WBR, Michael Shigorin / http://altlinux.org
  ------ http://opennet.ru / http://anna-news.info

Re: [devel] sisyphus_e2k vs GPL

[Dmitry V. Levin]

On Mon, Sep 27, 2021 at 01:57:17PM +0300, Michael Shigorin wrote:
> On Mon, Sep 27, 2021 at 01:46:28PM +0300, Dmitry V. Levin wrote:
> > Ни для кого не секрет, что МЦСТ является давним и последовательным
> > нарушителем GPL, и я не понимаю, почему человек, "почти полностью
> > переключившись на sisyphus_e2k", ещё и гордится своим соучастием
> > в этом противозаконии.
> 
> Гм, а чем тут гордиться?  Это как ты бы гордился своим когдашним
> сотрудничеством с так называемой "оппозицией", бишь иноагентами.
> 
> Безобразие с GPL (и не только) стараемся выправить, а упомянул
> с тем, что сейчас мне не особо до пакетов на x86 (только не на
> время выборов).
> 
> При этом прямо обозначу, что лицензии на ПО мне важны, но не
> важнее интересов Родины -- в этом плане я и впрямь не лучше
> тех же израильских террористов, убивших недавно очередного
> иранского физика-ядерщика.

"Патриотизм - последнее прибежище негодяя".  Я тебя услышал.


-- 
ldv

Re: [devel] sisyphus_e2k vs GPL

[Dmitry V. Levin]

On Mon, Sep 27, 2021 at 02:08:46PM +0300, Aleksey Novodvorsky wrote:
[...]
> Я прошу без политики и перехода на личности.

Длительное и последовательное нарушение GPL не может быть без политики.
Т.н. суверенное право нарушать GPL и есть политика.


-- 
ldv

Re: [devel] sisyphus_e2k vs GPL

[Michael Shigorin]

On Mon, Sep 27, 2021 at 02:00:21PM +0300, Dmitry V. Levin wrote:
> "Патриотизм - последнее прибежище негодяя".  Я тебя услышал.

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

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

-- 
 ---- WBR, Michael Shigorin / http://altlinux.org
  ------ http://opennet.ru / http://anna-news.info

Re: [devel] sisyphus_e2k vs GPL

[Anton V. Boyarshinov]

В Mon, 27 Sep 2021 14:08:46 +0300
Aleksey Novodvorsky <aen@basealt.ru> пишет:

> > > > Ни для кого не секрет, что МЦСТ является давним и последовательным
> > > > нарушителем GPL, и я не понимаю, почему человек, "почти полностью
> > > > переключившись на sisyphus_e2k", ещё и гордится своим соучастием
> > > > в этом противозаконии.  
> > >
> > > Гм, а чем тут гордиться?  Это как ты бы гордился своим когдашним
> > > сотрудничеством с так называемой "оппозицией", бишь иноагентами.
> 
> Я прошу без политики и перехода на личности.

Вопрос соблюдения лицензий на свободное ПО, несомненно, является темой
данного списка рассылки. В отличие от обсуждения так называемых
иноагентов.

Но вопрос о соблюдении лицензий на свободное ПО, несомненно, является
политическим и неразрывно связан с теми или иным личностями, которые их
соблюдают или не соблюдают.

Re: [devel] sisyphus_e2k vs GPL

[Paul Wolneykien]

В Mon, 27 Sep 2021 13:57:17 +0300
Michael Shigorin <mike@altlinux.org> пишет:

> При этом прямо обозначу, что лицензии на ПО мне важны, но не
> важнее интересов Родины

  Интересно, а почему ты в этом вопросе так уверен в МЦСТ?

Re: [devel] sisyphus_e2k vs GPL

[Anton V. Boyarshinov]

В Mon, 27 Sep 2021 13:57:17 +0300
Michael Shigorin <mike@altlinux.org> пишет:

> > Ни для кого не секрет, что МЦСТ является давним и последовательным
> > нарушителем GPL, и я не понимаю, почему человек, "почти полностью
> > переключившись на sisyphus_e2k", ещё и гордится своим соучастием
> > в этом противозаконии.  
> 
> Гм, а чем тут гордиться? 

Не знаю чем тут гордиться, но ты же гордишься (и, собственно, твои
письма ниже по треду это подтверждают)

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

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

Re: [devel] sisyphus_e2k vs GPL

[Michael Shigorin]

On Mon, Sep 27, 2021 at 02:46:47PM +0300, Anton V. Boyarshinov wrote:
> > Это как ты бы гордился своим когдашним сотрудничеством с так
> > называемой "оппозицией", бишь иноагентами.
> Почему "бы"? Я горжусь сотрудничеством с оппозицией, на которую
> повесили ярлыки "иноагентов", Дима, я полагаю, тоже. И не
> только "когдатошним".

Вот со своего бревна тогда и начинайте, коллеги.

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

-- 
 ---- WBR, Michael Shigorin / http://altlinux.org
  ------ http://opennet.ru / http://anna-news.info

Re: [devel] sisyphus_e2k vs GPL

[Anton V. Boyarshinov]

В Mon, 27 Sep 2021 14:50:55 +0300
Michael Shigorin <mike@altlinux.org> пишет:

> On Mon, Sep 27, 2021 at 02:46:47PM +0300, Anton V. Boyarshinov wrote:
> > > Это как ты бы гордился своим когдашним сотрудничеством с так
> > > называемой "оппозицией", бишь иноагентами.  
> > Почему "бы"? Я горжусь сотрудничеством с оппозицией, на которую
> > повесили ярлыки "иноагентов", Дима, я полагаю, тоже. И не
> > только "когдатошним".  
> 
> Вот со своего бревна тогда и начинайте, коллеги.
> 
> А про ярлыки можем потолковать, когда почитаете соответствующий
> штатовский закон и практику его применения.

Мы это уже сделали, а ты?
Не позорься сильнее, чем это необходимо.
Практика применения соответствующего штатовского закона не имеет ничего
общего с российской, по которой можно объявить иноагентом любую
организацию или любого человека, которые хоть когда-то хоть за что-то
получали хоть сколько-то денег из за границы (хоть 100р) и занимаются
хотя бы какой-то общественной деятельностью. А можно не объявлять --
полный произвол.

Re: [devel] sisyphus_e2k vs GPL

[Anton Farygin]

On 27.09.2021 14:56, Anton V. Boyarshinov wrote:
> В Mon, 27 Sep 2021 14:50:55 +0300
> Michael Shigorin <mike@altlinux.org> пишет:
>
>> On Mon, Sep 27, 2021 at 02:46:47PM +0300, Anton V. Boyarshinov wrote:
>>>> Это как ты бы гордился своим когдашним сотрудничеством с так
>>>> называемой "оппозицией", бишь иноагентами.
>>> Почему "бы"? Я горжусь сотрудничеством с оппозицией, на которую
>>> повесили ярлыки "иноагентов", Дима, я полагаю, тоже. И не
>>> только "когдатошним".
>> Вот со своего бревна тогда и начинайте, коллеги.
>>
>> А про ярлыки можем потолковать, когда почитаете соответствующий
>> штатовский закон и практику его применения.
> Мы это уже сделали, а ты?
> Не позорься сильнее, чем это необходимо.
> Практика применения соответствующего штатовского закона не имеет ничего
> общего с российской, по которой можно объявить иноагентом любую
> организацию или любого человека, которые хоть когда-то хоть за что-то
> получали хоть сколько-то денег из за границы (хоть 100р) и занимаются
> хотя бы какой-то общественной деятельностью. А можно не объявлять --
> полный произвол.
>
Коллеги, вы ошиблись рассылкой. Не могли бы вы выяснить кто из вас 
иноагент и какой закон лучше где-то в другом месте, т.к. создаёте много 
ненужного шума.


А вот вопрос с GPL в МЦСТ мне очень интересен и я бы хотел видеть письма 
по делу.


Спасибо.

Re: [devel] sisyphus_e2k vs GPL

[Anton V. Boyarshinov]

В Mon, 27 Sep 2021 14:58:17 +0300
Anton Farygin <rider@basealt.ru> пишет:

> А вот вопрос с GPL в МЦСТ мне очень интересен и я бы хотел видеть письма 
> по делу.

А что тут может быть написано по делу? За последние лет 5 тут
наблюдается примерно такой цикл:

do
   мы планируем открыть GPL код
   мы планируем открыть GPL код очень скоро
   ой, нет, мы не можем открыть код, во всяком случае сейчас
end

За это время какие-то куски кода периодически утекали, кто-то вне МЦСТ,
вроде бы, пилит qemu, но МЦСТ остаётся внутри вышеописанного цикла.

Re: [devel] sisyphus_e2k vs GPL

[Илья Курдюков]

Была такая история (из Википедии):

В 2004 году в прессе появились сообщения от компании Intel, что компания 
пригласила несколько групп разработчиков из «Эльбрус МЦСТ», а также 
UniPro на работу в Intel, в том числе Бориса Бабаяна.[5] При этом, 
несмотря на заявления Intel о заключении договора о покупке компаний 
МЦСТ и UniPro, сообщений об исполнении этого договора не появлялось, а 
обе компании заявили о продолжении работы в качестве независимых 
организаций

Ссылки на новостные сайты:

http://www.algonet.ru/?ID=448783

https://www.sostav.ru/news/2004/05/24/713/

Так что Интел узнал тогдашние ноу-хау и опыт.


On 27.09.2021 18:42, Paul Wolneykien wrote:
> В Mon, 27 Sep 2021 13:57:17 +0300
> Michael Shigorin <mike@altlinux.org> пишет:
>
>> При этом прямо обозначу, что лицензии на ПО мне важны, но не
>> важнее интересов Родины
>    Интересно, а почему ты в этом вопросе так уверен в МЦСТ?
> _______________________________________________
> Devel mailing list
> Devel@lists.altlinux.org
> https://lists.altlinux.org/mailman/listinfo/devel

Re: [devel] sisyphus_e2k vs GPL

[Leonid Krivoshein]

27.09.2021 13:57, Michael Shigorin пишет:
> On Mon, Sep 27, 2021 at 01:46:28PM +0300, Dmitry V. Levin wrote:
>> Ни для кого не секрет, что МЦСТ является давним и последовательным
>> нарушителем GPL, и я не понимаю, почему человек, "почти полностью
>> переключившись на sisyphus_e2k", ещё и гордится своим соучастием
>> в этом противозаконии.
> Гм, а чем тут гордиться?

Полагаю, это интересная техническая задача, другие мотивы вторичны.


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

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


> Безобразие с GPL (и не только) стараемся выправить, а упомянул
> с тем, что сейчас мне не особо до пакетов на x86 (только не на
> время выборов).
>
> При этом прямо обозначу, что лицензии на ПО мне важны, но не
> важнее интересов Родины -- в этом плане я и впрямь не лучше
> тех же израильских террористов, убивших недавно очередного
> иранского физика-ядерщика.
>
> Можешь расчехлять помидоры, но сперва -- зеркало.

-- 
Best regards,
Leonid Krivoshein.

Re: [devel] sisyphus_e2k vs GPL

[Anton Farygin]

On 27.09.2021 15:04, Anton V. Boyarshinov wrote:
> В Mon, 27 Sep 2021 14:58:17 +0300
> Anton Farygin <rider@basealt.ru> пишет:
>
>> А вот вопрос с GPL в МЦСТ мне очень интересен и я бы хотел видеть письма
>> по делу.
> А что тут может быть написано по делу? За последние лет 5 тут
> наблюдается примерно такой цикл:
>
> do
>     мы планируем открыть GPL код
>     мы планируем открыть GPL код очень скоро
>     ой, нет, мы не можем открыть код, во всяком случае сейчас
> end
>
> За это время какие-то куски кода периодически утекали, кто-то вне МЦСТ,
> вроде бы, пилит qemu, но МЦСТ остаётся внутри вышеописанного цикла.

Ну тогда о чём это обсуждение ?

Очевидно, что заставить МЦСТ исправить историю с GPL можно только 
юридически, т.к. по доброй воле не получается.

[devel] [OT] FARA (was: sisyphus_e2k vs GPL)

[Michael Shigorin]

PreScriptum: остальное ушло лично по личной просьбе cas@;
он прав, это всё здесь офтопик.

On Mon, Sep 27, 2021 at 02:56:26PM +0300, Anton V. Boyarshinov wrote:
> > А про ярлыки можем потолковать, когда почитаете соответствующий
> > штатовский закон и практику его применения.
> Мы это уже сделали, а ты?

А я знаком с Бутиной лично.

> Не позорься сильнее, чем это необходимо.

...и почитай хотя бы http://regnum.ru/news/1492588.html
(там вплоть до мыслепреступления -- и да, невинный Билли,
братец Джимми).

-- 
 ---- WBR, Michael Shigorin / http://altlinux.org
  ------ http://opennet.ru / http://anna-news.info

Re: [devel] [OT] FARA (was: sisyphus_e2k vs GPL)

[Anton V. Boyarshinov]

В Mon, 27 Sep 2021 15:35:52 +0300
Michael Shigorin <mike@altlinux.org> пишет:

> PreScriptum: остальное ушло лично по личной просьбе cas@;
> он прав, это всё здесь офтопик.
> 
> On Mon, Sep 27, 2021 at 02:56:26PM +0300, Anton V. Boyarshinov wrote:
> > > А про ярлыки можем потолковать, когда почитаете соответствующий
> > > штатовский закон и практику его применения.  
> > Мы это уже сделали, а ты?  
> 
> А я знаком с Бутиной лично.

Нашёл чем гордиться

> > Не позорься сильнее, чем это необходимо.  
> 
> ...и почитай хотя бы http://regnum.ru/news/1492588.html
> (там вплоть до мыслепреступления -- и да, невинный Билли,
> братец Джимми).

Какой смысл читать пересказы, когда можно ознакомится с
первоисточниками, а именно со списком признанных иноагентами в США и в
РФ и с основаниями на которых это было сделано?

Re: [devel] sisyphus_e2k vs GPL

[Dmitry V. Levin]

On Mon, Sep 27, 2021 at 03:35:25PM +0300, Anton Farygin wrote:
> On 27.09.2021 15:04, Anton V. Boyarshinov wrote:
> > В Mon, 27 Sep 2021 14:58:17 +0300, Anton Farygin пишет:
> >
> >> А вот вопрос с GPL в МЦСТ мне очень интересен и я бы хотел видеть письма
> >> по делу.
> > А что тут может быть написано по делу? За последние лет 5 тут
> > наблюдается примерно такой цикл:
> >
> > do
> >     мы планируем открыть GPL код
> >     мы планируем открыть GPL код очень скоро
> >     ой, нет, мы не можем открыть код, во всяком случае сейчас
> > end
> >
> > За это время какие-то куски кода периодически утекали, кто-то вне МЦСТ,
> > вроде бы, пилит qemu, но МЦСТ остаётся внутри вышеописанного цикла.
> 
> Ну тогда о чём это обсуждение ?
> 
> Очевидно, что заставить МЦСТ исправить историю с GPL можно только 
> юридически, т.к. по доброй воле не получается.

На мой взгляд, не все осознают степень нелегальности распространения
GPL-кода, которую практикует МЦСТ.  Не все отдают отчёт в том, что
не только МЦСТ нарушает GPL, распространяя GPL-код под НДА, но и все
получатели GPL-кода на этих условиях получают и используют такой код
нелегально.  В том числе, что особенно обидно, и те из наших коллег,
которые трудятся над sisyphus_e2k - я не знаю ни одного из них, кто бы
не расстраивался из-за невозможности опубликовать sisyphus_e2k.


-- 
ldv

Re: [devel] sisyphus_e2k vs GPL

[Andrey Savchenko]

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

On Mon, 27 Sep 2021 20:07:47 +0300 Dmitry V. Levin wrote:
> On Mon, Sep 27, 2021 at 03:35:25PM +0300, Anton Farygin wrote:
> > On 27.09.2021 15:04, Anton V. Boyarshinov wrote:
> > > В Mon, 27 Sep 2021 14:58:17 +0300, Anton Farygin пишет:
> > >
> > >> А вот вопрос с GPL в МЦСТ мне очень интересен и я бы хотел видеть письма
> > >> по делу.
> > > А что тут может быть написано по делу? За последние лет 5 тут
> > > наблюдается примерно такой цикл:
> > >
> > > do
> > >     мы планируем открыть GPL код
> > >     мы планируем открыть GPL код очень скоро
> > >     ой, нет, мы не можем открыть код, во всяком случае сейчас
> > > end
> > >
> > > За это время какие-то куски кода периодически утекали, кто-то вне МЦСТ,
> > > вроде бы, пилит qemu, но МЦСТ остаётся внутри вышеописанного цикла.
> > 
> > Ну тогда о чём это обсуждение ?
> > 
> > Очевидно, что заставить МЦСТ исправить историю с GPL можно только 
> > юридически, т.к. по доброй воле не получается.
> 
> На мой взгляд, не все осознают степень нелегальности распространения
> GPL-кода, которую практикует МЦСТ.  Не все отдают отчёт в том, что
> не только МЦСТ нарушает GPL, распространяя GPL-код под НДА, но и все
> получатели GPL-кода на этих условиях получают и используют такой код
> нелегально.

Это не так. С точки зрения GPL использование такого кода не
нарушает GPL, что чётко разъясняется FSF:
https://www.gnu.org/licenses/gpl-faq.html#StolenCopy

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

Легально ли будет использовать все свободы GPL по отношению к такому
коду с точки зрения российского законодательства — отдельный вопрос.

Разумеется, получатель такого кода имеет право не использовать свои
права в отношении данного кода, что мы и делаем.

Раз уж мы заговорили про нарушения, позвольте мне напомнить, что
у нас в Сизифе (без e2k) и так нарушается GPLv2, поскольку мы
распространяем драйвера ядра, несовместимые с ним по лицензии:
https://www.gnu.org/licenses/gpl-faq.html#NonfreeDriverKernelLinux

Привет ZFS. Скорее всего, проприетарные драйвера nVidia сюда же
попадают. Ну ещё можно всякие mali вспомнить. Но так делает большая
часть дистрибутивов и все тихонько закрывают на это глаза как на
меньшее зло (из моего обсуждения данного вопроса с представителями
EFF на полях FOSDEM).

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

Да, это обидно и плохо. Но полемика на devel ничего в данной
проблеме не решит.

Best regards,
Andrew Savchenko

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

Re: [devel] sisyphus_e2k vs GPL

[Andrey Savchenko]

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

On Mon, 27 Sep 2021 15:04:20 +0300 Anton V. Boyarshinov wrote:
> В Mon, 27 Sep 2021 14:58:17 +0300
> Anton Farygin <rider@basealt.ru> пишет:
> 
> > А вот вопрос с GPL в МЦСТ мне очень интересен и я бы хотел видеть письма 
> > по делу.
> 
> А что тут может быть написано по делу? За последние лет 5 тут
> наблюдается примерно такой цикл:
> 
> do
>    мы планируем открыть GPL код
>    мы планируем открыть GPL код очень скоро
>    ой, нет, мы не можем открыть код, во всяком случае сейчас
> end
> 
> За это время какие-то куски кода периодически утекали, кто-то вне МЦСТ,
> вроде бы, пилит qemu, но МЦСТ остаётся внутри вышеописанного цикла.

Не совсем так:
https://storage.mcst.ru/pub/pdk/cur/patches/gc-7.2d/
https://storage.mcst.ru/pub/src/rust/rustc-1.38.0/
ну и в pub у них ещё много чего есть.

Конечно, это немного по сравнению с тем, что они должны открыть
и самого главного пока что нет. Но это уже что-то.

Best regards,
Andrew Savchenko

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

Re: [devel] sisyphus_e2k vs GPL

[Dmitry V. Levin]

On Tue, Sep 28, 2021 at 12:22:38AM +0300, Andrey Savchenko wrote:
> On Mon, 27 Sep 2021 20:07:47 +0300 Dmitry V. Levin wrote:
> > On Mon, Sep 27, 2021 at 03:35:25PM +0300, Anton Farygin wrote:
> > > On 27.09.2021 15:04, Anton V. Boyarshinov wrote:
> > > > В Mon, 27 Sep 2021 14:58:17 +0300, Anton Farygin пишет:
> > > >
> > > >> А вот вопрос с GPL в МЦСТ мне очень интересен и я бы хотел видеть письма
> > > >> по делу.
> > > > А что тут может быть написано по делу? За последние лет 5 тут
> > > > наблюдается примерно такой цикл:
> > > >
> > > > do
> > > >     мы планируем открыть GPL код
> > > >     мы планируем открыть GPL код очень скоро
> > > >     ой, нет, мы не можем открыть код, во всяком случае сейчас
> > > > end
> > > >
> > > > За это время какие-то куски кода периодически утекали, кто-то вне МЦСТ,
> > > > вроде бы, пилит qemu, но МЦСТ остаётся внутри вышеописанного цикла.
> > > 
> > > Ну тогда о чём это обсуждение ?
> > > 
> > > Очевидно, что заставить МЦСТ исправить историю с GPL можно только 
> > > юридически, т.к. по доброй воле не получается.
> > 
> > На мой взгляд, не все осознают степень нелегальности распространения
> > GPL-кода, которую практикует МЦСТ.  Не все отдают отчёт в том, что
> > не только МЦСТ нарушает GPL, распространяя GPL-код под NDA, но и все
> > получатели GPL-кода на этих условиях получают и используют такой код
> > нелегально.
> 
> Это не так. С точки зрения GPL использование такого кода не
> нарушает GPL, что чётко разъясняется FSF:
> https://www.gnu.org/licenses/gpl-faq.html#StolenCopy
> 
> Т.е. с точки зрения GPL не важно как получен код, если он под GPL
> и используется в соответствии с GPL.
> 
> Легально ли будет использовать все свободы GPL по отношению к такому
> коду с точки зрения российского законодательства — отдельный вопрос.

Слово probably не придаёт уверенности, однако, если это соответствует
действительности, то GPL-софт, даже полученный незаконными способами,
с точки зрения GPL ничем не отличается от софта, полученного законными
способами.  В таком случае несмотря на то, что МЦСТ нарушает GPL,
распространяя GPL-код под NDA, получатели этого кода не нарушают GPL
до тех пор, пока сами не накладывают ограничений на распространение
этого кода.

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

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

> Раз уж мы заговорили про нарушения, позвольте мне напомнить, что
> у нас в Сизифе (без e2k) и так нарушается GPLv2, поскольку мы
> распространяем драйвера ядра, несовместимые с ним по лицензии:
> https://www.gnu.org/licenses/gpl-faq.html#NonfreeDriverKernelLinux
> 
> Привет ZFS. Скорее всего, проприетарные драйвера nVidia сюда же
> попадают. Ну ещё можно всякие mali вспомнить. Но так делает большая
> часть дистрибутивов и все тихонько закрывают на это глаза как на
> меньшее зло (из моего обсуждения данного вопроса с представителями
> EFF на полях FOSDEM).

Распространение проприетарных (nVidia) и лицензионно несовместимых (zfs)
драйверов в форме отдельных пакетов, по всей видимости, формально не
нарушает GPLv2, поскольку при такой упаковке эти драйвера можно как-то
использовать без ядра.

Тем не менее, это несомненно является лицемерным перекладыванием
ответственности за неизбежное нарушение лицензии на пользователей этих
драйверов.

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

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

Важно, чтобы все понимали, что происходит.  Когда законы не работают,
публичность создаёт давление, которое может поменять ситуацию.


-- 
ldv

Re: [devel] sisyphus_e2k vs GPL

[Alexey Gladkov]

On Tue, Sep 28, 2021 at 01:47:51AM +0300, Dmitry V. Levin wrote:
> > Это не так. С точки зрения GPL использование такого кода не
> > нарушает GPL, что чётко разъясняется FSF:
> > https://www.gnu.org/licenses/gpl-faq.html#StolenCopy
> > 
> > Т.е. с точки зрения GPL не важно как получен код, если он под GPL
> > и используется в соответствии с GPL.
> > 
> > Легально ли будет использовать все свободы GPL по отношению к такому
> > коду с точки зрения российского законодательства — отдельный вопрос.
> 
> Слово probably не придаёт уверенности, однако, если это соответствует
> действительности, то GPL-софт, даже полученный незаконными способами,
> с точки зрения GPL ничем не отличается от софта, полученного законными
> способами.  В таком случае несмотря на то, что МЦСТ нарушает GPL,
> распространяя GPL-код под NDA, получатели этого кода не нарушают GPL
> до тех пор, пока сами не накладывают ограничений на распространение
> этого кода.
> 
> > Разумеется, получатель такого кода имеет право не использовать свои
> > права в отношении данного кода, что мы и делаем.
> 
> Передачу такого кода своим сотрудникам для использования и доработки,
> по всей видимости, следует считать распространением.
> 
> > Раз уж мы заговорили про нарушения, позвольте мне напомнить, что
> > у нас в Сизифе (без e2k) и так нарушается GPLv2, поскольку мы
> > распространяем драйвера ядра, несовместимые с ним по лицензии:
> > https://www.gnu.org/licenses/gpl-faq.html#NonfreeDriverKernelLinux
> > 
> > Привет ZFS. Скорее всего, проприетарные драйвера nVidia сюда же
> > попадают. Ну ещё можно всякие mali вспомнить. Но так делает большая
> > часть дистрибутивов и все тихонько закрывают на это глаза как на
> > меньшее зло (из моего обсуждения данного вопроса с представителями
> > EFF на полях FOSDEM).
> 
> Распространение проприетарных (nVidia) и лицензионно несовместимых (zfs)
> драйверов в форме отдельных пакетов, по всей видимости, формально не
> нарушает GPLv2, поскольку при такой упаковке эти драйвера можно как-то
> использовать без ядра.
> 
> Тем не менее, это несомненно является лицемерным перекладыванием
> ответственности за неизбежное нарушение лицензии на пользователей этих
> драйверов.
> 
> Мы могли бы пойти дальше и отделить такой софт ещё более формально,
> например, в отдельную компоненту репозитория, чтобы пользователь
> не мог установить такие пакеты совсем уж случайно.

Как у соседних дистрибутивов non-free ? Было бы здорово!

> > > В том числе, что особенно обидно, и те из наших коллег,
> > > которые трудятся над sisyphus_e2k - я не знаю ни одного из них, кто бы
> > > не расстраивался из-за невозможности опубликовать sisyphus_e2k.
> > 
> > Да, это обидно и плохо. Но полемика на devel ничего в данной
> > проблеме не решит.
> 
> Важно, чтобы все понимали, что происходит.  Когда законы не работают,
> публичность создаёт давление, которое может поменять ситуацию.

Как минимум пользователи будут знать, что они в зоне опасности, когда
пользуются sisyphus_e2k.

-- 
Rgrds, legion

Re: [devel] sisyphus_e2k vs GPL

[Dmitry V. Levin]

On Tue, Sep 28, 2021 at 02:07:00AM +0300, Aleksey Novodvorsky wrote:
> вт, 28 сент. 2021 г., 01:47 Dmitry V. Levin <ldv@altlinux.org>:
> 
> > On Tue, Sep 28, 2021 at 12:22:38AM +0300, Andrey Savchenko wrote:
> > > On Mon, 27 Sep 2021 20:07:47 +0300 Dmitry V. Levin wrote:
> > > > On Mon, Sep 27, 2021 at 03:35:25PM +0300, Anton Farygin wrote:
> > > > > On 27.09.2021 15:04, Anton V. Boyarshinov wrote:
> > > > > > В Mon, 27 Sep 2021 14:58:17 +0300, Anton Farygin пишет:
> > > > > >
> > > > > >> А вот вопрос с GPL в МЦСТ мне очень интересен и я бы хотел видеть
> > письма
> > > > > >> по делу.
> > > > > > А что тут может быть написано по делу? За последние лет 5 тут
> > > > > > наблюдается примерно такой цикл:
> > > > > >
> > > > > > do
> > > > > >     мы планируем открыть GPL код
> > > > > >     мы планируем открыть GPL код очень скоро
> > > > > >     ой, нет, мы не можем открыть код, во всяком случае сейчас
> > > > > > end
> > > > > >
> > > > > > За это время какие-то куски кода периодически утекали, кто-то вне
> > МЦСТ,
> > > > > > вроде бы, пилит qemu, но МЦСТ остаётся внутри вышеописанного цикла.
> > > > >
> > > > > Ну тогда о чём это обсуждение ?
> > > > >
> > > > > Очевидно, что заставить МЦСТ исправить историю с GPL можно только
> > > > > юридически, т.к. по доброй воле не получается.
> > > >
> > > > На мой взгляд, не все осознают степень нелегальности распространения
> > > > GPL-кода, которую практикует МЦСТ.  Не все отдают отчёт в том, что
> > > > не только МЦСТ нарушает GPL, распространяя GPL-код под NDA, но и все
> > > > получатели GPL-кода на этих условиях получают и используют такой код
> > > > нелегально.
> > >
> > > Это не так. С точки зрения GPL использование такого кода не
> > > нарушает GPL, что чётко разъясняется FSF:
> > > https://www.gnu.org/licenses/gpl-faq.html#StolenCopy
> > >
> > > Т.е. с точки зрения GPL не важно как получен код, если он под GPL
> > > и используется в соответствии с GPL.
> > >
> > > Легально ли будет использовать все свободы GPL по отношению к такому
> > > коду с точки зрения российского законодательства — отдельный вопрос.
> >
> > Слово probably не придаёт уверенности, однако, если это соответствует
> > действительности, то GPL-софт, даже полученный незаконными способами,
> > с точки зрения GPL ничем не отличается от софта, полученного законными
> > способами.  В таком случае несмотря на то, что МЦСТ нарушает GPL,
> > распространяя GPL-код под NDA,
> 
> Факт нарушения есть при отказе предоставить исходный код без дополнительных
> условий в ответ на формально зафиксированое требование.
> 
> Мне такого факта неизвестно.

Ну как же, в GPLv2 ясно написано:
6. Each time you redistribute the Program (or any work based on the
Program), the recipient automatically receives a license from the
original licensor to copy, distribute or modify the Program subject to
these terms and conditions. You may not impose any further restrictions
on the recipients' exercise of the rights granted herein.

Фраза "You may not impose any further restrictions on the recipients' exercise
of the rights granted herein" означает, что при распространении GPL-кода
запрещается создавать дополнительные ограничения.  Всякий раз, когда
МЦСТ передаёт GPL-код (в данном случае не важно, бинарный или исходный)
под ограничивающим NDA, происходит формальное нарушение GPL.


-- 
ldv

Re: [devel] sisyphus_e2k vs GPL

[Anton Farygin]

On 28.09.2021 02:13, Alexey Gladkov wrote:
>> Распространение проприетарных (nVidia) и лицензионно несовместимых (zfs)
>> драйверов в форме отдельных пакетов, по всей видимости, формально не
>> нарушает GPLv2, поскольку при такой упаковке эти драйвера можно как-то
>> использовать без ядра.
>>
>> Тем не менее, это несомненно является лицемерным перекладыванием
>> ответственности за неизбежное нарушение лицензии на пользователей этих
>> драйверов.
>>
>> Мы могли бы пойти дальше и отделить такой софт ещё более формально,
>> например, в отдельную компоненту репозитория, чтобы пользователь
>> не мог установить такие пакеты совсем уж случайно.
> Как у соседних дистрибутивов non-free ? Было бы здорово!

zfs не non-free, не путайте.

Re: [devel] sisyphus_e2k vs GPL

[Alexey V. Vissarionov]

On 2021-09-28 01:47:51 +0300, Dmitry V. Levin wrote:

 >> Это не так. С точки зрения GPL использование такого кода не
 >> нарушает GPL, что чётко разъясняется FSF:
 >> https://www.gnu.org/licenses/gpl-faq.html#StolenCopy
 >> Т.е. с точки зрения GPL не важно как получен код, если он
 >> под GPL и используется в соответствии с GPL.
 >> Легально ли будет использовать все свободы GPL по отношению
 >> к такому коду с точки зрения российского законодательства —
 >> отдельный вопрос.

Строго говоря, ГК РФ это не регламентирует. Да и GPL - не более,
чем "традиция делового оборота".

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

Нет.

Если субъектом права является организация (team как общественное
объединение, да и контора тоже) - никого не должно волновать (и
не волнует), что происходит внутри.

А если субъектом права является отдельный человек - он всегда
может ограничить свои действия fair use в собственном понимании.

 >> Привет ZFS. Скорее всего, проприетарные драйвера nVidia сюда
 >> же попадают. Ну ещё можно всякие mali вспомнить. Но так делает
 >> большая часть дистрибутивов и все тихонько закрывают на это
 >> глаза как на меньшее зло (из моего обсуждения данного вопроса
 >> с представителями EFF на полях FOSDEM).

И это абсолютно правильно: если нет явного умысла - проще считать
эти действия fair use.

 > Распространение проприетарных (nVidia) и лицензионно
 > несовместимых (zfs) драйверов в форме отдельных пакетов, по
 > всей видимости, формально не нарушает GPLv2, поскольку при
 > такой упаковке эти драйвера можно как-то использовать без ядра.

cat ... | hexdump -C | lp

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

 > Тем не менее, это несомненно является лицемерным перекладыванием
 > ответственности за неизбежное нарушение лицензии на пользователей
 > этих драйверов.

А им пофигу - у них fair use (они могли с тем же успехом получить
проприетарную блобятину самостоятельно и абсолютно законно).

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

Зачем подкладывать пользователям такую свинью?

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

+100500

 > Важно, чтобы все понимали, что происходит. Когда законы
 > не работают, публичность создаёт давление, которое может
 > поменять ситуацию.

http://pics.rsh.ru/img/gafometer_u67qh.png


-- 
Alexey V. Vissarionov
gremlin ПРИ altlinux ТЧК org; +vii-cmiii-ccxxix-lxxix-xlii
GPG: 0D92F19E1C0DC36E27F61A29CD17E2B43D879005 @ hkp://keys.gnupg.net

Re: [devel] sisyphus_e2k vs GPL

[Alexey V. Vissarionov]

On 2021-09-28 02:21:20 +0300, Dmitry V. Levin wrote:

 >> Факт нарушения есть при отказе предоставить исходный код без
 >> дополнительных условий в ответ на формально зафиксированое
 >> требование. Мне такого факта неизвестно.
 > Ну как же, в GPLv2 ясно написано: 6. Each time you redistribute
 > the Program (or any work based on the Program), the recipient
 > automatically receives a license from the original licensor to
 > copy, distribute or modify the Program subject to these terms
 > and conditions. You may not impose any further restrictions on
 > the recipients' exercise of the rights granted herein.

Ну да.

 > Фраза "You may not impose any further restrictions on the
 > recipients' exercise of the rights granted herein" означает,
 > что при распространении GPL-кода запрещается создавать
 > дополнительные ограничения. Всякий раз, когда МЦСТ передаёт
 > GPL-код (в данном случае не важно, бинарный или исходный)
 > под ограничивающим NDA, происходит формальное нарушение GPL.

Это объезжается довольно просто: при нарушении NDA расторгается
договор, после чего поборники следования букве GPL остаются в
своем праве распространять что угодно куда угодно, но уже без
доступа к дальнейшим наработкам. Метод рабочий, бьет прицельно
по самому болезненному месту - по кошельку.


-- 
Alexey V. Vissarionov
gremlin ПРИ altlinux ТЧК org; +vii-cmiii-ccxxix-lxxix-xlii
GPG: 0D92F19E1C0DC36E27F61A29CD17E2B43D879005 @ hkp://keys.gnupg.net

Re: [devel] sisyphus_e2k vs GPL

[Dmitry V. Levin]

On Tue, Sep 28, 2021 at 11:29:50AM +0300, Alexey V. Vissarionov wrote:
> On 2021-09-28 02:21:20 +0300, Dmitry V. Levin wrote:
> 
>  >> Факт нарушения есть при отказе предоставить исходный код без
>  >> дополнительных условий в ответ на формально зафиксированое
>  >> требование. Мне такого факта неизвестно.
>  > Ну как же, в GPLv2 ясно написано: 6. Each time you redistribute
>  > the Program (or any work based on the Program), the recipient
>  > automatically receives a license from the original licensor to
>  > copy, distribute or modify the Program subject to these terms
>  > and conditions. You may not impose any further restrictions on
>  > the recipients' exercise of the rights granted herein.
> 
> Ну да.
> 
>  > Фраза "You may not impose any further restrictions on the
>  > recipients' exercise of the rights granted herein" означает,
>  > что при распространении GPL-кода запрещается создавать
>  > дополнительные ограничения. Всякий раз, когда МЦСТ передаёт
>  > GPL-код (в данном случае не важно, бинарный или исходный)
>  > под ограничивающим NDA, происходит формальное нарушение GPL.
> 
> Это объезжается довольно просто: при нарушении NDA расторгается
> договор, после чего поборники следования букве GPL остаются в
> своем праве распространять что угодно куда угодно, но уже без
> доступа к дальнейшим наработкам. Метод рабочий, бьет прицельно
> по самому болезненному месту - по кошельку.

Этот метод использовала в своих договорах печально известная grsecurity.

Но МЦСТ просто объявляет передаваемую информацию конфиденциальной
и запрещает дальнейшее распространение.

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


-- 
ldv