Re: [devel] [#291551] [test-only] FAILED (try 5) crtools.git=3.16.1-alt1

Re: [devel] [#291551] [test-only] FAILED (try 5) crtools.git=3.16.1-alt1

[Vladimir D. Seleznev]

Hi, devel@!

On Mon, Jan 17, 2022 at 11:29:03AM +0000, Girar awaiter (vseleznv) wrote:
> https://git.altlinux.org/tasks/291551/logs/events.5.1.log
> 
> subtask  name     aarch64    armh  i586  ppc64le  x86_64
>    #300  crtools     1:31  failed     -     1:27      49
> 
> 2022-Jan-17 11:27:29 :: test-only task #291551 for sisyphus resumed by vseleznv:
> #100 removed
> #200 removed
> #300 build 3.16.1-alt1 from /people/vseleznv/packages/crtools.git fetched at 2021-Dec-07 06:54:54
> 2022-Jan-17 11:27:30 :: #300: force rebuild
> 2022-Jan-17 11:27:30 :: [i586] #300 crtools.git 3.16.1-alt1: build start
> 2022-Jan-17 11:27:30 :: [ppc64le] #300 crtools.git 3.16.1-alt1: build start
> 2022-Jan-17 11:27:30 :: [x86_64] #300 crtools.git 3.16.1-alt1: build start
> 2022-Jan-17 11:27:30 :: [aarch64] #300 crtools.git 3.16.1-alt1: build start
> 2022-Jan-17 11:27:30 :: [armh] #300 crtools.git 3.16.1-alt1: build start
> 2022-Jan-17 11:27:38 :: [i586] #300 crtools.git 3.16.1-alt1: build SKIPPED
> 2022-Jan-17 11:28:19 :: [x86_64] #300 crtools.git 3.16.1-alt1: build OK
> 2022-Jan-17 11:28:57 :: [ppc64le] #300 crtools.git 3.16.1-alt1: build OK
> 2022-Jan-17 11:29:01 :: [aarch64] #300 crtools.git 3.16.1-alt1: build OK
> [armh] either the file containing the function 'code_syscall' or the file containing the function '' is not compiled with -fpic/-fPIC
> [armh] verify-elf: ERROR: ./usr/sbin/criu: TEXTREL entry found: 0x00000000
> [armh] verify-elf: WARNING: ./usr/bin/compel: skipping eu-elflint by request

А кто знает как такое чинить?

> 2022-Jan-17 11:29:03 :: [armh] crtools.git 3.16.1-alt1: remote: build failed
> 2022-Jan-17 11:29:03 :: [armh] #300 crtools.git 3.16.1-alt1: build FAILED
> 2022-Jan-17 11:29:03 :: [armh] requesting cancellation of task processing
> 2022-Jan-17 11:29:03 :: [armh] build FAILED
> 2022-Jan-17 11:29:03 :: task #291551 for sisyphus FAILED

-- 
   WBR,
   Vladimir D. Seleznev

Re: [devel] [#291551] [test-only] FAILED (try 5) crtools.git=3.16.1-alt1

[Alexey V. Vissarionov]

On 2022-01-24 18:54:54 +0300, Vladimir D. Seleznev wrote:

 >> [armh] either the file containing the function 'code_syscall'
 >> or the file containing the function '' is not compiled with
 >> -fpic/-fPIC
 >> [armh] verify-elf: ERROR: ./usr/sbin/criu: TEXTREL entry found:
 >> 0x00000000
 >> [armh] verify-elf: WARNING: ./usr/bin/compel: skipping eu-elflint
 >> by request
 > А кто знает как такое чинить?

ExclusiveArch: x86_64 aarch64


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

Re: [devel] [#291551] [test-only] FAILED (try 5) crtools.git=3.16.1-alt1

[Sergey V Turchin]

On Tuesday, 25 January 2022 01:51:57 MSK Alexey V wrote:
> On 2022-01-24 18:54:54 +0300, Vladimir D. Seleznev wrote:
>  >> [armh] either the file containing the function 'code_syscall'
>  >> or the file containing the function '' is not compiled with
>  >> -fpic/-fPIC
>  >> [armh] verify-elf: ERROR: ./usr/sbin/criu: TEXTREL entry found:
>  >> 0x00000000
>  >> [armh] verify-elf: WARNING: ./usr/bin/compel: skipping eu-elflint
>  >> by request
>  > 
>  > А кто знает как такое чинить?
> 
> ExclusiveArch: x86_64 aarch64
Если бы посмотрели хоть changelog, не писали бы ерунды.

Вообще, лучше не ExclusiveArch, а ExcludeArch, чтоб заранее не ущемлять любые 
другие архитектуры.

-- 
Regards, Sergey.

Re: [devel] [#291551] [test-only] FAILED (try 5) crtools.git=3.16.1-alt1

[Sergey V Turchin]

On Monday, 24 January 2022 18:54:54 MSK Vladimir D wrote:
> Hi, devel@!
> 
> On Mon, Jan 17, 2022 at 11:29:03AM +0000, Girar awaiter (vseleznv) wrote:
> > https://git.altlinux.org/tasks/291551/logs/events.5.1.log
> > 
> > subtask  name     aarch64    armh  i586  ppc64le  x86_64
> > 
> >    #300  crtools     1:31  failed     -     1:27      49
> > 
> > 2022-Jan-17 11:27:29 :: test-only task #291551 for sisyphus resumed by
> > vseleznv: #100 removed
> > #200 removed
> > #300 build 3.16.1-alt1 from /people/vseleznv/packages/crtools.git fetched
> > at 2021-Dec-07 06:54:54 2022-Jan-17 11:27:30 :: #300: force rebuild
> > 2022-Jan-17 11:27:30 :: [i586] #300 crtools.git 3.16.1-alt1: build start
> > 2022-Jan-17 11:27:30 :: [ppc64le] #300 crtools.git 3.16.1-alt1: build
> > start
> > 2022-Jan-17 11:27:30 :: [x86_64] #300 crtools.git 3.16.1-alt1: build start
> > 2022-Jan-17 11:27:30 :: [aarch64] #300 crtools.git 3.16.1-alt1: build
> > start
> > 2022-Jan-17 11:27:30 :: [armh] #300 crtools.git 3.16.1-alt1: build start
> > 2022-Jan-17 11:27:38 :: [i586] #300 crtools.git 3.16.1-alt1: build SKIPPED
> > 2022-Jan-17 11:28:19 :: [x86_64] #300 crtools.git 3.16.1-alt1: build OK
> > 2022-Jan-17 11:28:57 :: [ppc64le] #300 crtools.git 3.16.1-alt1: build OK
> > 2022-Jan-17 11:29:01 :: [aarch64] #300 crtools.git 3.16.1-alt1: build OK
> > [armh] either the file containing the function 'code_syscall' or the file
> > containing the function '' is not compiled with -fpic/-fPIC [armh]
> > verify-elf: ERROR: ./usr/sbin/criu: TEXTREL entry found: 0x00000000
> > [armh] verify-elf: WARNING: ./usr/bin/compel: skipping eu-elflint by
> > request
> А кто знает как такое чинить?
Если ключами компилятора не чинится, то отключать ассемблерные вставки, если 
возможно.

> 
> > 2022-Jan-17 11:29:03 :: [armh] crtools.git 3.16.1-alt1: remote: build
> > failed 2022-Jan-17 11:29:03 :: [armh] #300 crtools.git 3.16.1-alt1: build
> > FAILED 2022-Jan-17 11:29:03 :: [armh] requesting cancellation of task
> > processing 2022-Jan-17 11:29:03 :: [armh] build FAILED
> > 2022-Jan-17 11:29:03 :: task #291551 for sisyphus FAILED


-- 
Regards, Sergey.

Re: [devel] [#291551] [test-only] FAILED (try 5) crtools.git=3.16.1-alt1

[Alexey Sheplyakov]

Здравствуйте!

On Mon, Jan 24, 2022 at 06:54:54PM +0300, Vladimir D. Seleznev wrote:
> Hi, devel@!
> 
> On Mon, Jan 17, 2022 at 11:29:03AM +0000, Girar awaiter (vseleznv) wrote:
> > https://git.altlinux.org/tasks/291551/logs/events.5.1.log
> > 
> > subtask  name     aarch64    armh  i586  ppc64le  x86_64
> >    #300  crtools     1:31  failed     -     1:27      49
> > 
> > 2022-Jan-17 11:27:29 :: test-only task #291551 for sisyphus resumed by vseleznv:
> > #100 removed
> > #200 removed
> > #300 build 3.16.1-alt1 from /people/vseleznv/packages/crtools.git fetched at 2021-Dec-07 06:54:54
> > 2022-Jan-17 11:27:30 :: #300: force rebuild
> > 2022-Jan-17 11:27:30 :: [i586] #300 crtools.git 3.16.1-alt1: build start
> > 2022-Jan-17 11:27:30 :: [ppc64le] #300 crtools.git 3.16.1-alt1: build start
> > 2022-Jan-17 11:27:30 :: [x86_64] #300 crtools.git 3.16.1-alt1: build start
> > 2022-Jan-17 11:27:30 :: [aarch64] #300 crtools.git 3.16.1-alt1: build start
> > 2022-Jan-17 11:27:30 :: [armh] #300 crtools.git 3.16.1-alt1: build start
> > 2022-Jan-17 11:27:38 :: [i586] #300 crtools.git 3.16.1-alt1: build SKIPPED
> > 2022-Jan-17 11:28:19 :: [x86_64] #300 crtools.git 3.16.1-alt1: build OK
> > 2022-Jan-17 11:28:57 :: [ppc64le] #300 crtools.git 3.16.1-alt1: build OK
> > 2022-Jan-17 11:29:01 :: [aarch64] #300 crtools.git 3.16.1-alt1: build OK

У нас по умолчанию GCC генерит position independent code (то есть сборка
неявно происходит с -fPIC/-fPIE). Даже на тех архитектурах, где это приводит
к существенному снижению производительности (x86) и/или меняет ABI,
вот как здесь:

> > [armh] either the file containing the function 'code_syscall' or the file containing the function '' is not compiled with -fpic/-fPIC
> > [armh] verify-elf: ERROR: ./usr/sbin/criu: TEXTREL entry found: 0x00000000
> > [armh] verify-elf: WARNING: ./usr/bin/compel: skipping eu-elflint by request
> 
> А кто знает как такое чинить?

*По уму* чинить это надо в GCC, а именно: не генерить position independent,
если никто об этом не просил. Хотя бы на тех архитектурах, где это
сильно мешает. Пока GCC не починили (и даже не собираются), придётся вручную
в $CFLAGS передавать `-fno-pic -fno-PIC -fno-pie -fno-PIE`.

Всего доброго,
    Алексей

Re: [devel] [#291551] [test-only] FAILED (try 5) crtools.git=3.16.1-alt1

[Gleb Fotengauer-Malinovskiy]

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

Hi,

On Tue, Jan 25, 2022 at 02:52:26PM +0400, Alexey Sheplyakov wrote:
> Здравствуйте!
> 
> On Mon, Jan 24, 2022 at 06:54:54PM +0300, Vladimir D. Seleznev wrote:
> > Hi, devel@!
> > 
> > On Mon, Jan 17, 2022 at 11:29:03AM +0000, Girar awaiter (vseleznv) wrote:
> > > https://git.altlinux.org/tasks/291551/logs/events.5.1.log
> > > 
> > > subtask  name     aarch64    armh  i586  ppc64le  x86_64
> > >    #300  crtools     1:31  failed     -     1:27      49
> > > 
> > > 2022-Jan-17 11:27:29 :: test-only task #291551 for sisyphus resumed by vseleznv:
> > > #100 removed
> > > #200 removed
> > > #300 build 3.16.1-alt1 from /people/vseleznv/packages/crtools.git fetched at 2021-Dec-07 06:54:54
> > > 2022-Jan-17 11:27:30 :: #300: force rebuild
> > > 2022-Jan-17 11:27:30 :: [i586] #300 crtools.git 3.16.1-alt1: build start
> > > 2022-Jan-17 11:27:30 :: [ppc64le] #300 crtools.git 3.16.1-alt1: build start
> > > 2022-Jan-17 11:27:30 :: [x86_64] #300 crtools.git 3.16.1-alt1: build start
> > > 2022-Jan-17 11:27:30 :: [aarch64] #300 crtools.git 3.16.1-alt1: build start
> > > 2022-Jan-17 11:27:30 :: [armh] #300 crtools.git 3.16.1-alt1: build start
> > > 2022-Jan-17 11:27:38 :: [i586] #300 crtools.git 3.16.1-alt1: build SKIPPED
> > > 2022-Jan-17 11:28:19 :: [x86_64] #300 crtools.git 3.16.1-alt1: build OK
> > > 2022-Jan-17 11:28:57 :: [ppc64le] #300 crtools.git 3.16.1-alt1: build OK
> > > 2022-Jan-17 11:29:01 :: [aarch64] #300 crtools.git 3.16.1-alt1: build OK
> 
> У нас по умолчанию GCC генерит position independent code (то есть сборка
> неявно происходит с -fPIC/-fPIE).

Если вы имеете в виду, что у нас компилятор собран со штатной опцией
--enable-default-pie, то это не у нас, а в апстриме есть такая хорошая
фича, а мы ею просто пользуемся.

-- 
glebfm

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

Re: [devel] [#291551] [test-only] FAILED (try 5) crtools.git=3.16.1-alt1

[Vladimir D. Seleznev]

On Tue, Jan 25, 2022 at 02:52:26PM +0400, Alexey Sheplyakov wrote:
> Здравствуйте!
> 
> On Mon, Jan 24, 2022 at 06:54:54PM +0300, Vladimir D. Seleznev wrote:
> > Hi, devel@!
> > 
> > On Mon, Jan 17, 2022 at 11:29:03AM +0000, Girar awaiter (vseleznv) wrote:
> > > https://git.altlinux.org/tasks/291551/logs/events.5.1.log
> > > 
> > > subtask  name     aarch64    armh  i586  ppc64le  x86_64
> > >    #300  crtools     1:31  failed     -     1:27      49
> > > 
> > > 2022-Jan-17 11:27:29 :: test-only task #291551 for sisyphus resumed by vseleznv:
> > > #100 removed
> > > #200 removed
> > > #300 build 3.16.1-alt1 from /people/vseleznv/packages/crtools.git fetched at 2021-Dec-07 06:54:54
> > > 2022-Jan-17 11:27:30 :: #300: force rebuild
> > > 2022-Jan-17 11:27:30 :: [i586] #300 crtools.git 3.16.1-alt1: build start
> > > 2022-Jan-17 11:27:30 :: [ppc64le] #300 crtools.git 3.16.1-alt1: build start
> > > 2022-Jan-17 11:27:30 :: [x86_64] #300 crtools.git 3.16.1-alt1: build start
> > > 2022-Jan-17 11:27:30 :: [aarch64] #300 crtools.git 3.16.1-alt1: build start
> > > 2022-Jan-17 11:27:30 :: [armh] #300 crtools.git 3.16.1-alt1: build start
> > > 2022-Jan-17 11:27:38 :: [i586] #300 crtools.git 3.16.1-alt1: build SKIPPED
> > > 2022-Jan-17 11:28:19 :: [x86_64] #300 crtools.git 3.16.1-alt1: build OK
> > > 2022-Jan-17 11:28:57 :: [ppc64le] #300 crtools.git 3.16.1-alt1: build OK
> > > 2022-Jan-17 11:29:01 :: [aarch64] #300 crtools.git 3.16.1-alt1: build OK
> 
> У нас по умолчанию GCC генерит position independent code (то есть сборка
> неявно происходит с -fPIC/-fPIE). Даже на тех архитектурах, где это приводит
> к существенному снижению производительности (x86) и/или меняет ABI,
> вот как здесь:
> 
> > > [armh] either the file containing the function 'code_syscall' or the file containing the function '' is not compiled with -fpic/-fPIC
> > > [armh] verify-elf: ERROR: ./usr/sbin/criu: TEXTREL entry found: 0x00000000
> > > [armh] verify-elf: WARNING: ./usr/bin/compel: skipping eu-elflint by request
> > 
> > А кто знает как такое чинить?
> 
> *По уму* чинить это надо в GCC, а именно: не генерить position independent,
> если никто об этом не просил.

Это было намеренно решение, собирать всё с position independent на
уровне репозитория.

> Хотя бы на тех архитектурах, где это сильно мешает. Пока GCC не
> починили (и даже не собираются), придётся вручную в $CFLAGS передавать
> `-fno-pic -fno-PIC -fno-pie -fno-PIE`.

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

-- 
   WBR,
   Vladimir D. Seleznev

Re: [devel] [#291551] [test-only] FAILED (try 5) crtools.git=3.16.1-alt1

[Anton Farygin]

On 25.01.2022 19:12, Vladimir D. Seleznev wrote:
> PI же не про производительность, с другой стороны, особой пользы на
> 32-хбитных архитектурах ввиду несравненно меньшего адресного
> пространства по сравнению с 64-хбитными. Возможно, неплохая мысль
> выключить PI для них.

давно пора.

https://git.altlinux.org/gears/r/rpm-build-ocaml.git?p=rpm-build-ocaml.git;a=blob;f=scripts/ocaml;h=2d247e1f2641a49256201a57331b31360015bbd3;hb=cba6db678bdf4d689e1ed93e006285d917af8eca

Re: [devel] [#291551] [test-only] FAILED (try 5) crtools.git=3.16.1-alt1

[Alexey Sheplyakov]

Добрый день!

On Tue, Jan 25, 2022 at 07:12:22PM +0300, Vladimir D. Seleznev wrote:
> On Tue, Jan 25, 2022 at 02:52:26PM +0400, Alexey Sheplyakov wrote:
> > Здравствуйте!
> > 
> > On Mon, Jan 24, 2022 at 06:54:54PM +0300, Vladimir D. Seleznev wrote:
> > > Hi, devel@!
> > > 
> > > On Mon, Jan 17, 2022 at 11:29:03AM +0000, Girar awaiter (vseleznv) wrote:
> > > > https://git.altlinux.org/tasks/291551/logs/events.5.1.log
> > > > 
> > > > subtask  name     aarch64    armh  i586  ppc64le  x86_64
> > > >    #300  crtools     1:31  failed     -     1:27      49
> > > > 
> > > > 2022-Jan-17 11:27:29 :: test-only task #291551 for sisyphus resumed by vseleznv:
> > > > #100 removed
> > > > #200 removed
> > > > #300 build 3.16.1-alt1 from /people/vseleznv/packages/crtools.git fetched at 2021-Dec-07 06:54:54
> > > > 2022-Jan-17 11:27:30 :: #300: force rebuild
> > > > 2022-Jan-17 11:27:30 :: [i586] #300 crtools.git 3.16.1-alt1: build start
> > > > 2022-Jan-17 11:27:30 :: [ppc64le] #300 crtools.git 3.16.1-alt1: build start
> > > > 2022-Jan-17 11:27:30 :: [x86_64] #300 crtools.git 3.16.1-alt1: build start
> > > > 2022-Jan-17 11:27:30 :: [aarch64] #300 crtools.git 3.16.1-alt1: build start
> > > > 2022-Jan-17 11:27:30 :: [armh] #300 crtools.git 3.16.1-alt1: build start
> > > > 2022-Jan-17 11:27:38 :: [i586] #300 crtools.git 3.16.1-alt1: build SKIPPED
> > > > 2022-Jan-17 11:28:19 :: [x86_64] #300 crtools.git 3.16.1-alt1: build OK
> > > > 2022-Jan-17 11:28:57 :: [ppc64le] #300 crtools.git 3.16.1-alt1: build OK
> > > > 2022-Jan-17 11:29:01 :: [aarch64] #300 crtools.git 3.16.1-alt1: build OK
> > 
> > У нас по умолчанию GCC генерит position independent code (то есть сборка
> > неявно происходит с -fPIC/-fPIE). Даже на тех архитектурах, где это приводит
> > к существенному снижению производительности (x86) и/или меняет ABI,
> > вот как здесь:
> > 
> > > > [armh] either the file containing the function 'code_syscall' or the file containing the function '' is not compiled with -fpic/-fPIC
> > > > [armh] verify-elf: ERROR: ./usr/sbin/criu: TEXTREL entry found: 0x00000000
> > > > [armh] verify-elf: WARNING: ./usr/bin/compel: skipping eu-elflint by request
> > > 
> > > А кто знает как такое чинить?
> > 
> > *По уму* чинить это надо в GCC, а именно: не генерить position independent,
> > если никто об этом не просил.
> 
> Это было намеренно решение, собирать всё с position independent на
> уровне репозитория.

Это плохо обдуманное решение. И обсуждаемый баг - тому подтверждение.

> > Хотя бы на тех архитектурах, где это сильно мешает. Пока GCC не
> > починили (и даже не собираются), придётся вручную в $CFLAGS передавать
> > `-fno-pic -fno-PIC -fno-pie -fno-PIE`.
> 
> PI же не про производительность,

Не скажу про все 32-битные архитектуры, но на x86 и armv{6,7} это именно
что "про производительность" (и "про ABI"), только в плохом смысле слова.

> с другой стороны, особой пользы на
> 32-хбитных архитектурах ввиду несравненно меньшего адресного
> пространства

Именно. Никакого толку, один только вред.

Re: [devel] [#291551] [test-only] FAILED (try 5) crtools.git=3.16.1-alt1

[Dmitry V. Levin]

On Tue, Jan 25, 2022 at 07:12:22PM +0300, Vladimir D. Seleznev wrote:
[...]
> PI же не про производительность, с другой стороны, особой пользы на
> 32-хбитных архитектурах ввиду несравненно меньшего адресного
> пространства по сравнению с 64-хбитными. Возможно, неплохая мысль
> выключить PI для них.

Давайте честно скажем, что особой пользы от 32-битных архитектур уже нет.
Возможно, неплохая мысль выключить их в недалёком будущем, скажем, к p11.


-- 
ldv

Re: [devel] [#291551] [test-only] FAILED (try 5) crtools.git=3.16.1-alt1

[Leonid Krivoshein]

29.01.2022 0:30, Dmitry V. Levin пишет:
> On Tue, Jan 25, 2022 at 07:12:22PM +0300, Vladimir D. Seleznev wrote:
> [...]
>> PI же не про производительность, с другой стороны, особой пользы на
>> 32-хбитных архитектурах ввиду несравненно меньшего адресного
>> пространства по сравнению с 64-хбитными. Возможно, неплохая мысль
>> выключить PI для них.
> Давайте честно скажем, что особой пользы от 32-битных архитектур уже нет.
> Возможно, неплохая мысль выключить их в недалёком будущем, скажем, к p11.

От тяжеловесного десктопного 32-бит резонно отказываться, если больше не 
поддерживается апстримом. Если отказываться совсем, тогда ALT остаётся 
только для десктопов и "до свидания IoT, контроллеры и иже с ними".


-- 
Best regards,
Leonid Krivoshein.

Re: [devel] [#291551] [test-only] FAILED (try 5) crtools.git=3.16.1-alt1

[Dmitry V. Levin]

On Sat, Jan 29, 2022 at 12:58:57AM +0300, Leonid Krivoshein wrote:
> 29.01.2022 0:30, Dmitry V. Levin пишет:
> > On Tue, Jan 25, 2022 at 07:12:22PM +0300, Vladimir D. Seleznev wrote:
> > [...]
> >> PI же не про производительность, с другой стороны, особой пользы на
> >> 32-хбитных архитектурах ввиду несравненно меньшего адресного
> >> пространства по сравнению с 64-хбитными. Возможно, неплохая мысль
> >> выключить PI для них.
> > Давайте честно скажем, что особой пользы от 32-битных архитектур уже нет.
> > Возможно, неплохая мысль выключить их в недалёком будущем, скажем, к p11.
> 
> От тяжеловесного десктопного 32-бит резонно отказываться, если больше не 
> поддерживается апстримом. Если отказываться совсем, тогда ALT остаётся 
> только для десктопов и "до свидания IoT, контроллеры и иже с ними".

Для серверов, десктопы тоже отомрут. :)
А для контроллеров вообще универсальные ОС не нужны.


-- 
ldv

Re: [devel] [#291551] [test-only] FAILED (try 5) crtools.git=3.16.1-alt1

[Alexey V. Vissarionov]

On 2022-01-29 01:45:28 +0300, Dmitry V. Levin wrote:

 >>>> выключить PI для них.
 >>> Давайте честно скажем, что особой пользы от 32-битных
 >>> архитектур уже нет. Возможно, неплохая мысль выключить
 >>> их в недалёком будущем, скажем, к p11.
 >> От тяжеловесного десктопного 32-бит резонно отказываться,
 >> если больше не поддерживается апстримом. Если отказываться
 >> совсем, тогда ALT остаётся только для десктопов и "до
 >> свидания IoT, контроллеры и иже с ними".
 > Для серверов, десктопы тоже отомрут. :)

Для серверов у нас пока ничего и нет.

 > А для контроллеров вообще универсальные ОС не нужны.

Вот от тебя не ожидал этого заблуждения...


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

Re: [devel] [#291551] [test-only] FAILED (try 5) crtools.git=3.16.1-alt1

[Yuri Sedunov]

В Сб, 29/01/2022 в 01:45 +0300, Dmitry V. Levin пишет:
> On Sat, Jan 29, 2022 at 12:58:57AM +0300, Leonid Krivoshein wrote:
> > 29.01.2022 0:30, Dmitry V. Levin пишет:
> > > On Tue, Jan 25, 2022 at 07:12:22PM +0300, Vladimir D. Seleznev
> > > wrote:
> > > [...]
> > > > PI же не про производительность, с другой стороны, особой
> > > > пользы на
> > > > 32-хбитных архитектурах ввиду несравненно меньшего адресного
> > > > пространства по сравнению с 64-хбитными. Возможно, неплохая
> > > > мысль
> > > > выключить PI для них.
> > > Давайте честно скажем, что особой пользы от 32-битных архитектур
> > > уже нет.
> > > Возможно, неплохая мысль выключить их в недалёком будущем,
> > > скажем, к p11.
> > 
> > От тяжеловесного десктопного 32-бит резонно отказываться, если
> > больше не 
> > поддерживается апстримом. Если отказываться совсем, тогда ALT
> > остаётся 
> > только для десктопов и "до свидания IoT, контроллеры и иже с ними".
> 
> Для серверов, десктопы тоже отомрут. :)
> А для контроллеров вообще универсальные ОС не нужны.
> 
Ну, я так, наблюдающий за 1000+.git, 32-bit по-прежнему актуальны.


-- 
Yuri N. Sedunov

Re: [devel] [#291551] [test-only] FAILED (try 5) crtools.git=3.16.1-alt1

[Andrey Savchenko]

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

On Sat, 29 Jan 2022 00:30:52 +0300 Dmitry V. Levin wrote:
> On Tue, Jan 25, 2022 at 07:12:22PM +0300, Vladimir D. Seleznev wrote:
> [...]
> > PI же не про производительность, с другой стороны, особой пользы на
> > 32-хбитных архитектурах ввиду несравненно меньшего адресного
> > пространства по сравнению с 64-хбитными. Возможно, неплохая мысль
> > выключить PI для них.
> 
> Давайте честно скажем, что особой пользы от 32-битных архитектур уже нет.
> Возможно, неплохая мысль выключить их в недалёком будущем, скажем, к p11.

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

PIE на 32 битах на самом деле несёт мало пользы и больше вреда
и лучше не форсировать. С PIC аналогично — те приложения, кому нужно
для DSO, сами включат.

Best regards,
Andrew Savchenko

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

Re: [devel] [#291551] [test-only] FAILED (try 5) crtools.git=3.16.1-alt1

[Dmitry V. Levin]

On Sat, Jan 29, 2022 at 01:25:42AM +0300, Andrey Savchenko wrote:
> On Sat, 29 Jan 2022 00:30:52 +0300 Dmitry V. Levin wrote:
> > On Tue, Jan 25, 2022 at 07:12:22PM +0300, Vladimir D. Seleznev wrote:
> > [...]
> > > PI же не про производительность, с другой стороны, особой пользы на
> > > 32-хбитных архитектурах ввиду несравненно меньшего адресного
> > > пространства по сравнению с 64-хбитными. Возможно, неплохая мысль
> > > выключить PI для них.
> > 
> > Давайте честно скажем, что особой пользы от 32-битных архитектур уже нет.
> > Возможно, неплохая мысль выключить их в недалёком будущем, скажем, к p11.
> 
> По-моему, не очень хорошо, когда разработчики говорят
> пользователям, что они с их железом нам больше не нужны.
> 
> PIE на 32 битах на самом деле несёт мало пользы и больше вреда

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

> и лучше не форсировать. С PIC аналогично — те приложения, кому нужно
> для DSO, сами включат.

PIC вроде нигде по умолчанию и не включается.


-- 
ldv

Re: [devel] [#291551] [test-only] FAILED (try 5) crtools.git=3.16.1-alt1

[Andrey Savchenko]

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

On Sat, 29 Jan 2022 01:43:45 +0300 Dmitry V. Levin wrote:
> On Sat, Jan 29, 2022 at 01:25:42AM +0300, Andrey Savchenko wrote:
> > On Sat, 29 Jan 2022 00:30:52 +0300 Dmitry V. Levin wrote:
> > > On Tue, Jan 25, 2022 at 07:12:22PM +0300, Vladimir D. Seleznev wrote:
> > > [...]
> > > > PI же не про производительность, с другой стороны, особой пользы на
> > > > 32-хбитных архитектурах ввиду несравненно меньшего адресного
> > > > пространства по сравнению с 64-хбитными. Возможно, неплохая мысль
> > > > выключить PI для них.
> > > 
> > > Давайте честно скажем, что особой пользы от 32-битных архитектур уже нет.
> > > Возможно, неплохая мысль выключить их в недалёком будущем, скажем, к p11.
> > 
> > По-моему, не очень хорошо, когда разработчики говорят
> > пользователям, что они с их железом нам больше не нужны.
> > 
> > PIE на 32 битах на самом деле несёт мало пользы и больше вреда
> 
> Меньше пользы в том смысле, что там меньше бит для рандомизации адресов?
> Ну так это один из врождённых недостатков 32-битных архитектур.
> Больше вреда только на калькуляторах-переростках^W^W^W тех архитектурах,
> где мало регистров.

Смысл в том, что соотношение выгоды к проблемам не оправдывает
себя: безопасность сколь-либо существенно не увеличивается,
собираемость и производительность страдают.

Best regards,
Andrew Savchenko

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

Re: [devel] [#291551] [test-only] FAILED (try 5) crtools.git=3.16.1-alt1

[Mikhail Novosyolov]

29.01.2022 01:25, Andrey Savchenko пишет:
> On Sat, 29 Jan 2022 00:30:52 +0300 Dmitry V. Levin wrote:
>> On Tue, Jan 25, 2022 at 07:12:22PM +0300, Vladimir D. Seleznev wrote:
>> [...]
>>> PI же не про производительность, с другой стороны, особой пользы на
>>> 32-хбитных архитектурах ввиду несравненно меньшего адресного
>>> пространства по сравнению с 64-хбитными. Возможно, неплохая мысль
>>> выключить PI для них.
>> Давайте честно скажем, что особой пользы от 32-битных архитектур уже нет.
>> Возможно, неплохая мысль выключить их в недалёком будущем, скажем, к p11.
> По-моему, не очень хорошо, когда разработчики говорят
> пользователям, что они с их железом нам больше не нужны.
>
> PIE на 32 битах на самом деле несёт мало пользы и больше вреда
> и лучше не форсировать. С PIC аналогично — те приложения, кому нужно
> для DSO, сами включат.
Мне кажется, заставлять мейнтейнеров разбираться с дополнительным ворохом i586/armhel-специфичных проблем не стоит.

Re: [devel] [#291551] [test-only] FAILED (try 5) crtools.git=3.16.1-alt1

[Anton Farygin]

On 30.01.2022 03:20, Aleksey Novodvorsky wrote:
>
>
> сб, 29 янв. 2022 г., 01:26 Andrey Savchenko <bircoph@altlinux.org>:
>
>     On Sat, 29 Jan 2022 00:30:52 +0300 Dmitry V. Levin wrote:
>     > On Tue, Jan 25, 2022 at 07:12:22PM +0300, Vladimir D. Seleznev
>     wrote:
>     > [...]
>     > > PI же не про производительность, с другой стороны, особой
>     пользы на
>     > > 32-хбитных архитектурах ввиду несравненно меньшего адресного
>     > > пространства по сравнению с 64-хбитными. Возможно, неплохая мысль
>     > > выключить PI для них.
>     >
>     > Давайте честно скажем, что особой пользы от 32-битных архитектур
>     уже нет.
>     > Возможно, неплохая мысль выключить их в недалёком будущем,
>     скажем, к p11.
>
>     По-моему, не очень хорошо, когда разработчики говорят
>     пользователям, что они с их железом нам больше не нужны.
>
>
> Да, но ничто не вечно. Поддержка  p10 завершается 30 июня 2024 года.
>
> Вы полагаете, что этого мало?
>
А это может показать только время - мы не знаем что будет с 32-bit 
системами даже в этом году, не говоря уже про перспективу трёх лет.

Re: [devel] [#291551] [test-only] FAILED (try 5) crtools.git=3.16.1-alt1

[Andrey Savchenko]

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

On Sun, 30 Jan 2022 03:20:50 +0300 Aleksey Novodvorsky wrote:
> сб, 29 янв. 2022 г., 01:26 Andrey Savchenko <bircoph@altlinux.org>:
> 
> > On Sat, 29 Jan 2022 00:30:52 +0300 Dmitry V. Levin wrote:
> > > On Tue, Jan 25, 2022 at 07:12:22PM +0300, Vladimir D. Seleznev wrote:
> > > [...]
> > > > PI же не про производительность, с другой стороны, особой пользы на
> > > > 32-хбитных архитектурах ввиду несравненно меньшего адресного
> > > > пространства по сравнению с 64-хбитными. Возможно, неплохая мысль
> > > > выключить PI для них.
> > >
> > > Давайте честно скажем, что особой пользы от 32-битных архитектур уже нет.
> > > Возможно, неплохая мысль выключить их в недалёком будущем, скажем, к p11.
> >
> > По-моему, не очень хорошо, когда разработчики говорят
> > пользователям, что они с их железом нам больше не нужны.
> >
> 
> Да, но ничто не вечно. Поддержка  p10 завершается 30 июня 2024 года.
> 
> Вы полагаете, что этого мало?

Точно сказать сложно, но в целом, думаю, что для:

x86: точно мало (steam, wine, атомы)
armv7: сложно сказать, но как я понял, это оборудование ещё производят
mips32: по-видимому, уже не актуально

Best regards,
Andrew Savchenko

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

Re: [devel] [#291551] [test-only] FAILED (try 5) crtools.git=3.16.1-alt1

[Антон Мидюков]

29.01.2022 04:30, Dmitry V. Levin пишет:
> On Tue, Jan 25, 2022 at 07:12:22PM +0300, Vladimir D. Seleznev wrote:
> [...]
>> PI же не про производительность, с другой стороны, особой пользы на
>> 32-хбитных архитектурах ввиду несравненно меньшего адресного
>> пространства по сравнению с 64-хбитными. Возможно, неплохая мысль
>> выключить PI для них.
> 
> Давайте честно скажем, что особой пользы от 32-битных архитектур уже нет.
> Возможно, неплохая мысль выключить их в недалёком будущем, скажем, к p11.
> 

А что будет с репозиторием x86_64-i586? Его тоже выключим?
Он то ещё долго будет востребован.
А если не выключать, то сборка на i586 будет нужна.

-- 
С уважением, Антон Мидюков <antohami@altlinux.org>

Re: [devel] [#291551] [test-only] FAILED (try 5) crtools.git=3.16.1-alt1

[Dmitry V. Levin]

On Sat, Jan 29, 2022 at 09:32:26AM +0700, Антон Мидюков wrote:
> 29.01.2022 04:30, Dmitry V. Levin пишет:
> > On Tue, Jan 25, 2022 at 07:12:22PM +0300, Vladimir D. Seleznev wrote:
> > [...]
> >> PI же не про производительность, с другой стороны, особой пользы на
> >> 32-хбитных архитектурах ввиду несравненно меньшего адресного
> >> пространства по сравнению с 64-хбитными. Возможно, неплохая мысль
> >> выключить PI для них.
> > 
> > Давайте честно скажем, что особой пользы от 32-битных архитектур уже нет.
> > Возможно, неплохая мысль выключить их в недалёком будущем, скажем, к p11.
> 
> А что будет с репозиторием x86_64-i586? Его тоже выключим?
> Он то ещё долго будет востребован.

Интересно, почему вы так думаете.


-- 
ldv

Re: [devel] [#291551] [test-only] FAILED (try 5) crtools.git=3.16.1-alt1

[Антон Мидюков]

29.01.2022 10:06, Dmitry V. Levin пишет:
> On Sat, Jan 29, 2022 at 09:32:26AM +0700, Антон Мидюков wrote:
>> 29.01.2022 04:30, Dmitry V. Levin пишет:
>>> On Tue, Jan 25, 2022 at 07:12:22PM +0300, Vladimir D. Seleznev wrote:
>>> [...]
>>>> PI же не про производительность, с другой стороны, особой пользы на
>>>> 32-хбитных архитектурах ввиду несравненно меньшего адресного
>>>> пространства по сравнению с 64-хбитными. Возможно, неплохая мысль
>>>> выключить PI для них.
>>>
>>> Давайте честно скажем, что особой пользы от 32-битных архитектур уже нет.
>>> Возможно, неплохая мысль выключить их в недалёком будущем, скажем, к p11.
>>
>> А что будет с репозиторием x86_64-i586? Его тоже выключим?
>> Он то ещё долго будет востребован.
> 
> Интересно, почему вы так думаете.
> 

Что он будет востребован?


-- 
С уважением, Антон Мидюков <antohami@altlinux.org>

Re: [devel] [#291551] [test-only] FAILED (try 5) crtools.git=3.16.1-alt1

[Alexey V. Vissarionov]

On 2022-01-29 09:32:26 +0700, Антон Мидюков wrote:

 >>> выключить PI для них.
 >> Давайте честно скажем, что особой пользы от 32-битных
 >> архитектур уже нет. Возможно, неплохая мысль выключить
 >> их в недалёком будущем, скажем, к p11.
 > А что будет с репозиторием x86_64-i586? Его тоже выключим?

Вообще-то давно пора.

 > Он то ещё долго будет востребован.

Кем и для чего? Если есть x86_64 - там и запускать надо x86_64.

 > А если не выключать, то сборка на i586 будет нужна.

Думаю, от x86_32 можно отказаться в год 20-летия x86_64 :-)


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

Re: [devel] [#291551] [test-only] FAILED (try 5) crtools.git=3.16.1-alt1

[Антон Мидюков]

29.01.2022 16:31, Alexey V. Vissarionov пишет:
> On 2022-01-29 09:32:26 +0700, Антон Мидюков wrote:
> 
>  >>> выключить PI для них.
>  >> Давайте честно скажем, что особой пользы от 32-битных
>  >> архитектур уже нет. Возможно, неплохая мысль выключить
>  >> их в недалёком будущем, скажем, к p11.
>  > А что будет с репозиторием x86_64-i586? Его тоже выключим?
> 
> Вообще-то давно пора.
> 
>  > Он то ещё долго будет востребован.
> 
> Кем и для чего? Если есть x86_64 - там и запускать надо x86_64.
> 

Для запуска проприетарщины 32-битной.
Ну, и пока что wine всё ещё нуждается в 32-битных библиотеках.
Но к p11 это скорее всего исправится.

steam выкинем? Клиент у них всё ещё 32-битный. Старых игр 32-битных на Linux определённое количество есть.
Правда, может они уже и не заведутся, после выкидывания старых версий gcc...

-- 
С уважением, Антон Мидюков <antohami@altlinux.org>

Re: [devel] [#291551] [test-only] FAILED (try 5) crtools.git=3.16.1-alt1

[Alexey Gladkov]

On Sat, Jan 29, 2022 at 05:09:39PM +0700, Антон Мидюков wrote:
> 29.01.2022 16:31, Alexey V. Vissarionov пишет:
> > On 2022-01-29 09:32:26 +0700, Антон Мидюков wrote:
> > 
> >  >>> выключить PI для них.
> >  >> Давайте честно скажем, что особой пользы от 32-битных
> >  >> архитектур уже нет. Возможно, неплохая мысль выключить
> >  >> их в недалёком будущем, скажем, к p11.
> >  > А что будет с репозиторием x86_64-i586? Его тоже выключим?
> > 
> > Вообще-то давно пора.
> > 
> >  > Он то ещё долго будет востребован.
> > 
> > Кем и для чего? Если есть x86_64 - там и запускать надо x86_64.
> > 
> 
> Для запуска проприетарщины 32-битной.
> Ну, и пока что wine всё ещё нуждается в 32-битных библиотеках.
> Но к p11 это скорее всего исправится.
> 
> steam выкинем? Клиент у них всё ещё 32-битный. Старых игр 32-битных на Linux определённое количество есть.
> Правда, может они уже и не заведутся, после выкидывания старых версий gcc...

steam это единственное для чего x86_64-i586 может быть нужен, но и там
нужны лишь _некоторые_ библиотеки, а не приложения. В основном ему нужны
mesa и тому подобное.

-- 
Rgrds, legion

Re: [devel] [#291551] [test-only] FAILED (try 5) crtools.git=3.16.1-alt1

[Anton Farygin]

On 29.01.2022 14:29, Alexey Gladkov wrote:
> On Sat, Jan 29, 2022 at 05:09:39PM +0700, Антон Мидюков wrote:
>> 29.01.2022 16:31, Alexey V. Vissarionov пишет:
>>> On 2022-01-29 09:32:26 +0700, Антон Мидюков wrote:
>>>
>>>   >>> выключить PI для них.
>>>   >> Давайте честно скажем, что особой пользы от 32-битных
>>>   >> архитектур уже нет. Возможно, неплохая мысль выключить
>>>   >> их в недалёком будущем, скажем, к p11.
>>>   > А что будет с репозиторием x86_64-i586? Его тоже выключим?
>>>
>>> Вообще-то давно пора.
>>>
>>>   > Он то ещё долго будет востребован.
>>>
>>> Кем и для чего? Если есть x86_64 - там и запускать надо x86_64.
>>>
>> Для запуска проприетарщины 32-битной.
>> Ну, и пока что wine всё ещё нуждается в 32-битных библиотеках.
>> Но к p11 это скорее всего исправится.
>>
>> steam выкинем? Клиент у них всё ещё 32-битный. Старых игр 32-битных на Linux определённое количество есть.
>> Правда, может они уже и не заведутся, после выкидывания старых версий gcc...
> steam это единственное для чего x86_64-i586 может быть нужен, но и там
> нужны лишь _некоторые_ библиотеки, а не приложения. В основном ему нужны
> mesa и тому подобное.
>
не только steam. Весь стек wine

Re: [devel] x86_64-i586

[Dmitry V. Levin]

On Sat, Jan 29, 2022 at 02:34:59PM +0300, Anton Farygin wrote:
> On 29.01.2022 14:29, Alexey Gladkov wrote:
> > On Sat, Jan 29, 2022 at 05:09:39PM +0700, Антон Мидюков wrote:
> >> 29.01.2022 16:31, Alexey V. Vissarionov пишет:
> >>> On 2022-01-29 09:32:26 +0700, Антон Мидюков wrote:
[...]
> >>>   > А что будет с репозиторием x86_64-i586? Его тоже выключим?
> >>>
> >>> Вообще-то давно пора.
> >>>
> >>>   > Он то ещё долго будет востребован.
> >>>
> >>> Кем и для чего? Если есть x86_64 - там и запускать надо x86_64.
> >>>
> >> Для запуска проприетарщины 32-битной.
> >> Ну, и пока что wine всё ещё нуждается в 32-битных библиотеках.
> >> Но к p11 это скорее всего исправится.
> >>
> >> steam выкинем? Клиент у них всё ещё 32-битный. Старых игр 32-битных на Linux определённое количество есть.
> >> Правда, может они уже и не заведутся, после выкидывания старых версий gcc...
> > steam это единственное для чего x86_64-i586 может быть нужен, но и там
> > нужны лишь _некоторые_ библиотеки, а не приложения. В основном ему нужны
> > mesa и тому подобное.
> >
> не только steam. Весь стек wine

Интересно, когда "весь стек wine" (не знаю, что это такое) станет 64-битным?

Понятно, что старые 32-битные приложения навсегда таковыми и останутся,
но будут ли они востребованы настолько, чтобы поддерживать для них i586
и x86_64-i586, или для них будет достаточно старых операционных систем
внутри контейнеров и виртуалок?


-- 
ldv

Re: [devel] x86_64-i586

[Anton Farygin]

On 29.01.2022 14:47, Dmitry V. Levin wrote:
> On Sat, Jan 29, 2022 at 02:34:59PM +0300, Anton Farygin wrote:
>> On 29.01.2022 14:29, Alexey Gladkov wrote:
>> steam это единственное для чего x86_64-i586 может быть нужен, но и там
>> нужны лишь _некоторые_ библиотеки, а не приложения. В основном ему нужны
>> mesa и тому подобное.
>>
>> не только steam. Весь стек wine
> Интересно, когда "весь стек wine" (не знаю, что это такое) станет 64-битным?
>
> Понятно, что старые 32-битные приложения навсегда таковыми и останутся,
> но будут ли они востребованы настолько, чтобы поддерживать для них i586
> и x86_64-i586, или для них будет достаточно старых операционных систем
> внутри контейнеров и виртуалок?
>
>
Думаю что ещё лет 5-10 будет востребовано.

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

Т.е. - я бы не расчитывал на то, что wine32 станет не нужным в ближайшее 
время.

Весь другой biarch на linux уже фактически не нужен.


Мне кажется, что в этом вопросе нам придётся следовать за Microsoft - 
как только они откажутся от запуска 32-битных приложений в своих 
системах - так сразу можно и нам задуматься об удалении wine32.

Re: [devel] x86_64-i586

[Anton V. Boyarshinov]

В Sat, 29 Jan 2022 14:58:50 +0300
Anton Farygin <rider@basealt.ru> пишет:

> Т.е. - я бы не расчитывал на то, что wine32 станет не нужным в ближайшее 
> время.

Насколько я понимаю, разработчики wine работают в направлении
возможности запуска 32-битных приложений windows из 64-битного wine без
необходимости установки 32b wine библиотек в linux. И существенно
продвинулись в этом направлении.

Re: [devel] x86_64-i586

[Ilya Kurdyukov]

On 31.01.2022 16:24, Anton V. Boyarshinov wrote:
> В Sat, 29 Jan 2022 14:58:50 +0300
> Anton Farygin <rider@basealt.ru> пишет:
>
>> Т.е. - я бы не расчитывал на то, что wine32 станет не нужным в ближайшее
>> время.
> Насколько я понимаю, разработчики wine работают в направлении
> возможности запуска 32-битных приложений windows из 64-битного wine без
> необходимости установки 32b wine библиотек в linux. И существенно
> продвинулись в этом направлении.

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

Re: [devel] x86_64-i586

[Anton V. Boyarshinov]

> >> Т.е. - я бы не расчитывал на то, что wine32 станет не нужным в ближайшее
> >> время.  
> > Насколько я понимаю, разработчики wine работают в направлении
> > возможности запуска 32-битных приложений windows из 64-битного wine без
> > необходимости установки 32b wine библиотек в linux. И существенно
> > продвинулись в этом направлении.  
> 
> Но давайте обойдёмся без такого, что "они еще не закончили, а мы уже 
> удалили". Вот когда они закончат и крупные/известные дистрибутивы 
> перестанут поддерживать запуск 32-бит приложений, тогда уже следовать за 
> ними. Насчёт существенно или не существенно продвинулись - это не имеет 
> никакого значения, главное чтобы они закончили и этобы это стабильно 
> работало и не было лишь экспериментальной фичей, которая работает хуже 
> чем при использовании нормального 32-бит режима.

Так вроде никто не говорит "давайте уберём i586 завтра и полностью".

Re: [devel] x86_64-i586

[Антон Мидюков]

29.01.2022 18:47, Dmitry V. Levin пишет:
> On Sat, Jan 29, 2022 at 02:34:59PM +0300, Anton Farygin wrote:
>> On 29.01.2022 14:29, Alexey Gladkov wrote:
>>> On Sat, Jan 29, 2022 at 05:09:39PM +0700, Антон Мидюков wrote:
>>>> 29.01.2022 16:31, Alexey V. Vissarionov пишет:
>>>>> On 2022-01-29 09:32:26 +0700, Антон Мидюков wrote:
> [...]
>>>>>   > А что будет с репозиторием x86_64-i586? Его тоже выключим?
>>>>>
>>>>> Вообще-то давно пора.
>>>>>
>>>>>   > Он то ещё долго будет востребован.
>>>>>
>>>>> Кем и для чего? Если есть x86_64 - там и запускать надо x86_64.
>>>>>
>>>> Для запуска проприетарщины 32-битной.
>>>> Ну, и пока что wine всё ещё нуждается в 32-битных библиотеках.
>>>> Но к p11 это скорее всего исправится.
>>>>
>>>> steam выкинем? Клиент у них всё ещё 32-битный. Старых игр 32-битных на Linux определённое количество есть.
>>>> Правда, может они уже и не заведутся, после выкидывания старых версий gcc...
>>> steam это единственное для чего x86_64-i586 может быть нужен, но и там
>>> нужны лишь _некоторые_ библиотеки, а не приложения. В основном ему нужны
>>> mesa и тому подобное.
>>>
>> не только steam. Весь стек wine
> 
> Интересно, когда "весь стек wine" (не знаю, что это такое) станет 64-битным?

Когда все библиотеки переведут в формат PE. В собранном wine-6.22.1 таких библиотек 38.
Так что все шансы, что за год не переведут есть. И даже за пару лет.

> 
> Понятно, что старые 32-битные приложения навсегда таковыми и останутся,
> но будут ли они востребованы настолько, чтобы поддерживать для них i586
> и x86_64-i586, или для них будет достаточно старых операционных систем
> внутри контейнеров и виртуалок?
> 

А нельзя ли реализовать некоторую мини-сборочницу для сборки для i586 лишь базового минимума?
Как максимум - это пара сотен пакетов. Чтобы из них делать репозиторий с минимальным набором библиотек?
Может в спеке специальное объявление сделать о сборке для i586? Ну или жёсткий список в самой сборочнице утвердить.

-- 
С уважением, Антон Мидюков <antohami@altlinux.org>

Re: [devel] x86_64-i586

[Anton Farygin]

On 29.01.2022 15:02, Антон Мидюков wrote:
> 29.01.2022 18:47, Dmitry V. Levin пишет:
>> On Sat, Jan 29, 2022 at 02:34:59PM +0300, Anton Farygin wrote:
>>> On 29.01.2022 14:29, Alexey Gladkov wrote:
>>>> On Sat, Jan 29, 2022 at 05:09:39PM +0700, Антон Мидюков wrote:
>>>>> 29.01.2022 16:31, Alexey V. Vissarionov пишет:
>>>>>> On 2022-01-29 09:32:26 +0700, Антон Мидюков wrote:
>> [...]
>>>>>>    > А что будет с репозиторием x86_64-i586? Его тоже выключим?
>>>>>>
>>>>>> Вообще-то давно пора.
>>>>>>
>>>>>>    > Он то ещё долго будет востребован.
>>>>>>
>>>>>> Кем и для чего? Если есть x86_64 - там и запускать надо x86_64.
>>>>>>
>>>>> Для запуска проприетарщины 32-битной.
>>>>> Ну, и пока что wine всё ещё нуждается в 32-битных библиотеках.
>>>>> Но к p11 это скорее всего исправится.
>>>>>
>>>>> steam выкинем? Клиент у них всё ещё 32-битный. Старых игр 32-битных на Linux определённое количество есть.
>>>>> Правда, может они уже и не заведутся, после выкидывания старых версий gcc...
>>>> steam это единственное для чего x86_64-i586 может быть нужен, но и там
>>>> нужны лишь _некоторые_ библиотеки, а не приложения. В основном ему нужны
>>>> mesa и тому подобное.
>>>>
>>> не только steam. Весь стек wine
>> Интересно, когда "весь стек wine" (не знаю, что это такое) станет 64-битным?
> Когда все библиотеки переведут в формат PE. В собранном wine-6.22.1 таких библиотек 38.
> Так что все шансы, что за год не переведут есть. И даже за пару лет.
>
>> Понятно, что старые 32-битные приложения навсегда таковыми и останутся,
>> но будут ли они востребованы настолько, чтобы поддерживать для них i586
>> и x86_64-i586, или для них будет достаточно старых операционных систем
>> внутри контейнеров и виртуалок?
>>
> А нельзя ли реализовать некоторую мини-сборочницу для сборки для i586 лишь базового минимума?
> Как максимум - это пара сотен пакетов. Чтобы из них делать репозиторий с минимальным набором библиотек?
> Может в спеке специальное объявление сделать о сборке для i586? Ну или жёсткий список в самой сборочнице утвердить.
>
не пару сотен. Точно больше.

Отдельной сборочницы не получится.

Re: [devel] x86_64-i586

[Andrey Savchenko]

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

On Sat, 29 Jan 2022 15:10:56 +0300 Anton Farygin wrote:
> On 29.01.2022 15:02, Антон Мидюков wrote:
> > 29.01.2022 18:47, Dmitry V. Levin пишет:
> >> On Sat, Jan 29, 2022 at 02:34:59PM +0300, Anton Farygin wrote:
> >>> On 29.01.2022 14:29, Alexey Gladkov wrote:
> >>>> On Sat, Jan 29, 2022 at 05:09:39PM +0700, Антон Мидюков wrote:
> >>>>> 29.01.2022 16:31, Alexey V. Vissarionov пишет:
> >>>>>> On 2022-01-29 09:32:26 +0700, Антон Мидюков wrote:
> >> [...]
> >>>>>>    > А что будет с репозиторием x86_64-i586? Его тоже выключим?
> >>>>>>
> >>>>>> Вообще-то давно пора.
> >>>>>>
> >>>>>>    > Он то ещё долго будет востребован.
> >>>>>>
> >>>>>> Кем и для чего? Если есть x86_64 - там и запускать надо x86_64.
> >>>>>>
> >>>>> Для запуска проприетарщины 32-битной.
> >>>>> Ну, и пока что wine всё ещё нуждается в 32-битных библиотеках.
> >>>>> Но к p11 это скорее всего исправится.
> >>>>>
> >>>>> steam выкинем? Клиент у них всё ещё 32-битный. Старых игр 32-битных на Linux определённое количество есть.
> >>>>> Правда, может они уже и не заведутся, после выкидывания старых версий gcc...
> >>>> steam это единственное для чего x86_64-i586 может быть нужен, но и там
> >>>> нужны лишь _некоторые_ библиотеки, а не приложения. В основном ему нужны
> >>>> mesa и тому подобное.
> >>>>
> >>> не только steam. Весь стек wine
> >> Интересно, когда "весь стек wine" (не знаю, что это такое) станет 64-битным?
> > Когда все библиотеки переведут в формат PE. В собранном wine-6.22.1 таких библиотек 38.
> > Так что все шансы, что за год не переведут есть. И даже за пару лет.
> >
> >> Понятно, что старые 32-битные приложения навсегда таковыми и останутся,
> >> но будут ли они востребованы настолько, чтобы поддерживать для них i586
> >> и x86_64-i586, или для них будет достаточно старых операционных систем
> >> внутри контейнеров и виртуалок?
> >>
> > А нельзя ли реализовать некоторую мини-сборочницу для сборки для i586 лишь базового минимума?
> > Как максимум - это пара сотен пакетов. Чтобы из них делать репозиторий с минимальным набором библиотек?
> > Может в спеке специальное объявление сделать о сборке для i586? Ну или жёсткий список в самой сборочнице утвердить.
> >
> не пару сотен. Точно больше.
> 
> Отдельной сборочницы не получится.

По-моему, разумнее всего убирать отдельные приложения через
ExcludeArch, если их уже не реально поддерживать. Но сперва нужно
убрать PIE.

Best regards,
Andrew Savchenko

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

Re: [devel] x86_64-i586

[Anton Farygin]

On 29.01.2022 15:28, Andrey Savchenko wrote:
>> не пару сотен. Точно больше.
>>
>> Отдельной сборочницы не получится.
> По-моему, разумнее всего убирать отдельные приложения через
> ExcludeArch, если их уже не реально поддерживать. Но сперва нужно
> убрать PIE.
>
+1

Re: [devel] [#291551] [test-only] FAILED (try 5) crtools.git=3.16.1-alt1

[Alexey V. Vissarionov]

On 2022-01-29 17:09:39 +0700, Антон Мидюков wrote:

 >>>>> выключить PI для них.
 >>>> Давайте честно скажем, что особой пользы от 32-битных
 >>>> архитектур уже нет. Возможно, неплохая мысль выключить
 >>>> их в недалёком будущем, скажем, к p11.
 >>> А что будет с репозиторием x86_64-i586? Его тоже выключим?
 >> Вообще-то давно пора.
 >>> Он то ещё долго будет востребован.
 >> Кем и для чего? Если есть x86_64 - там и запускать надо x86_64.
 > Для запуска проприетарщины 32-битной.

Для этого нужны просто i586.

Кстати, именно на i586 они не работают - требуют как минимум i686,
и то не всякий.

 > Ну, и пока что wine всё ещё нуждается в 32-битных библиотеках.
 > Но к p11 это скорее всего исправится.

Насколько я понимаю, там тоже просто i586, а не x86_64-i586.

 > steam выкинем? Клиент у них всё ещё 32-битный. Старых игр
 > 32-битных на Linux определённое количество есть. Правда,
 > может они уже и не заведутся, после выкидывания старых
 > версий gcc...

Как же меня умиляет такая забота от погаМцах, от которых нам
(разработчикам) ни денег, ни уважения... :-)


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

Re: [devel] [#291551] [test-only] FAILED (try 5) crtools.git=3.16.1-alt1

[Anton Farygin]

On 29.01.2022 00:30, Dmitry V. Levin wrote:
> On Tue, Jan 25, 2022 at 07:12:22PM +0300, Vladimir D. Seleznev wrote:
> [...]
>> PI же не про производительность, с другой стороны, особой пользы на
>> 32-хбитных архитектурах ввиду несравненно меньшего адресного
>> пространства по сравнению с 64-хбитными. Возможно, неплохая мысль
>> выключить PI для них.
> Давайте честно скажем, что особой пользы от 32-битных архитектур уже нет.
> Возможно, неплохая мысль выключить их в недалёком будущем, скажем, к p11.
>
biarch на x86_64 пока нужен

Re: [devel] [#291551] [test-only] FAILED (try 5) crtools.git=3.16.1-alt1

[Alexey Gladkov]

On Sat, Jan 29, 2022 at 12:30:52AM +0300, Dmitry V. Levin wrote:
> On Tue, Jan 25, 2022 at 07:12:22PM +0300, Vladimir D. Seleznev wrote:
> [...]
> > PI же не про производительность, с другой стороны, особой пользы на
> > 32-хбитных архитектурах ввиду несравненно меньшего адресного
> > пространства по сравнению с 64-хбитными. Возможно, неплохая мысль
> > выключить PI для них.
> 
> Давайте честно скажем, что особой пользы от 32-битных архитектур уже нет.
> Возможно, неплохая мысль выключить их в недалёком будущем, скажем, к p11.

Я поддерживаю всеми руками!

-- 
Rgrds, legion

Re: [devel] [#291551] [test-only] FAILED (try 5) crtools.git=3.16.1-alt1

[Валерий Иноземцев]

[-- Attachment #1.1: Type: text/plain, Size: 982 bytes --]

29.01.2022 14:22, Alexey Gladkov пишет:
> On Sat, Jan 29, 2022 at 12:30:52AM +0300, Dmitry V. Levin wrote:
>> On Tue, Jan 25, 2022 at 07:12:22PM +0300, Vladimir D. Seleznev wrote:
>> [...]
>>> PI же не про производительность, с другой стороны, особой пользы на
>>> 32-хбитных архитектурах ввиду несравненно меньшего адресного
>>> пространства по сравнению с 64-хбитными. Возможно, неплохая мысль
>>> выключить PI для них.
>>
>> Давайте честно скажем, что особой пользы от 32-битных архитектур уже нет.
>> Возможно, неплохая мысль выключить их в недалёком будущем, скажем, к p11.
> 
> Я поддерживаю всеми руками!
> 
+100500

-- 
Valery V. Inozemtsev

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 203 bytes --]

Re: [devel] [#291551] [test-only] FAILED (try 5) crtools.git=3.16.1-alt1

[Sergey Y. Afonin]

On Saturday 29 January 2022, Dmitry V. Levin wrote:

> Давайте честно скажем, что особой пользы от 32-битных архитектур уже нет.
> Возможно, неплохая мысль выключить их в недалёком будущем, скажем, к p11.

Мне кажется немного рано. Вот к p12 уже может быть.

-- 
С уважением, Сергей Афонин

Re: [devel] [#291551] [test-only] FAILED (try 5) crtools.git=3.16.1-alt1

[Grigory Ustinov]

29.01.2022 15:48, Sergey Y. Afonin пишет:
> On Saturday 29 January 2022, Dmitry V. Levin wrote:
>
>> Давайте честно скажем, что особой пользы от 32-битных архитектур уже нет.
>> Возможно, неплохая мысль выключить их в недалёком будущем, скажем, к p11.
> Мне кажется немного рано. Вот к p12 уже может быть.
Я до сих пор в поездках пользуюсь ноутбуком на Intel Atom N270. Он 
32битный, он работает и по большому счёту он меня устраивает ровно 
настолько, что 64битный ноутбук я пока не вижу смысла покупать. Возможно 
не всем нужны большие мощности и некоторые люди могут пользоваться 
устаревшей техникой. У одного довольно известного преподавателя курса 
операционных систем вмк мгу это даже стало жизненной позицией, которую я 
поддерживаю и возможно есть и другие пользователи, которые её разделяют 
в той или иной мере.

Re: [devel] [#291551] [test-only] FAILED (try 5) crtools.git=3.16.1-alt1

[Alexey Gladkov]

On Sat, Jan 29, 2022 at 04:01:15PM +0300, Grigory Ustinov wrote:
> 29.01.2022 15:48, Sergey Y. Afonin пишет:
> > On Saturday 29 January 2022, Dmitry V. Levin wrote:
> > 
> > > Давайте честно скажем, что особой пользы от 32-битных архитектур уже нет.
> > > Возможно, неплохая мысль выключить их в недалёком будущем, скажем, к p11.
> > Мне кажется немного рано. Вот к p12 уже может быть.
> Я до сих пор в поездках пользуюсь ноутбуком на Intel Atom N270. Он 32битный,
> он работает и по большому счёту он меня устраивает ровно настолько, что
> 64битный ноутбук я пока не вижу смысла покупать. Возможно не всем нужны
> большие мощности и некоторые люди могут пользоваться устаревшей техникой. У
> одного довольно известного преподавателя курса операционных систем вмк мгу
> это даже стало жизненной позицией, которую я поддерживаю и возможно есть и
> другие пользователи, которые её разделяют в той или иной мере.

Я хочу проговорить вслух всем защитникам 32-x архитектур, чтобы не было
иллюзий и обид:

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

Когда случаются проблемы, которые я не могу сходу запатчить, то проблемный
функционал просто выключаю (удивительно как это не стало ещё заметно).
Потому что актуальные архитектуры не должны страдать от этого легаси.

Если вас такой уровень поддержки устраивает, то ок, я буду продолжать
такую поддержку 32-x сборок.

-- 
Rgrds, legion

Re: [devel] [#291551] [test-only] FAILED (try 5) crtools.git=3.16.1-alt1

[Anton Farygin]

On 29.01.2022 16:26, Alexey Gladkov wrote:
> On Sat, Jan 29, 2022 at 04:01:15PM +0300, Grigory Ustinov wrote:
>> 29.01.2022 15:48, Sergey Y. Afonin пишет:
>>> On Saturday 29 January 2022, Dmitry V. Levin wrote:
>>>
>>>> Давайте честно скажем, что особой пользы от 32-битных архитектур уже нет.
>>>> Возможно, неплохая мысль выключить их в недалёком будущем, скажем, к p11.
>>> Мне кажется немного рано. Вот к p12 уже может быть.
>> Я до сих пор в поездках пользуюсь ноутбуком на Intel Atom N270. Он 32битный,
>> он работает и по большому счёту он меня устраивает ровно настолько, что
>> 64битный ноутбук я пока не вижу смысла покупать. Возможно не всем нужны
>> большие мощности и некоторые люди могут пользоваться устаревшей техникой. У
>> одного довольно известного преподавателя курса операционных систем вмк мгу
>> это даже стало жизненной позицией, которую я поддерживаю и возможно есть и
>> другие пользователи, которые её разделяют в той или иной мере.
> Я хочу проговорить вслух всем защитникам 32-x архитектур, чтобы не было
> иллюзий и обид:
>
> Для меня эти архитектуры мертвы. У меня давно нет такого железа, чтобы
> проверять там сборки и я патчу связанные баги неглядя. Тестировать эти
> сборки у меня нет ни возможности ни желания.
>
> Когда случаются проблемы, которые я не могу сходу запатчить, то проблемный
> функционал просто выключаю (удивительно как это не стало ещё заметно).
> Потому что актуальные архитектуры не должны страдать от этого легаси.
>
> Если вас такой уровень поддержки устраивает, то ок, я буду продолжать
> такую поддержку 32-x сборок.
>
У меня точно такая же политика - если тест падает на 32-х битах и сходу 
непонятно как чинить, то я его просто выключаю.

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

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

Re: [devel] [#291551] [test-only] FAILED (try 5) crtools.git=3.16.1-alt1

[Alexey Gladkov]

On Sat, Jan 29, 2022 at 08:32:32PM +0300, Anton Farygin wrote:
> On 29.01.2022 16:26, Alexey Gladkov wrote:
> > On Sat, Jan 29, 2022 at 04:01:15PM +0300, Grigory Ustinov wrote:
> > > 29.01.2022 15:48, Sergey Y. Afonin пишет:
> > > > On Saturday 29 January 2022, Dmitry V. Levin wrote:
> > > > 
> > > > > Давайте честно скажем, что особой пользы от 32-битных архитектур уже нет.
> > > > > Возможно, неплохая мысль выключить их в недалёком будущем, скажем, к p11.
> > > > Мне кажется немного рано. Вот к p12 уже может быть.
> > > Я до сих пор в поездках пользуюсь ноутбуком на Intel Atom N270. Он 32битный,
> > > он работает и по большому счёту он меня устраивает ровно настолько, что
> > > 64битный ноутбук я пока не вижу смысла покупать. Возможно не всем нужны
> > > большие мощности и некоторые люди могут пользоваться устаревшей техникой. У
> > > одного довольно известного преподавателя курса операционных систем вмк мгу
> > > это даже стало жизненной позицией, которую я поддерживаю и возможно есть и
> > > другие пользователи, которые её разделяют в той или иной мере.
> > Я хочу проговорить вслух всем защитникам 32-x архитектур, чтобы не было
> > иллюзий и обид:
> > 
> > Для меня эти архитектуры мертвы. У меня давно нет такого железа, чтобы
> > проверять там сборки и я патчу связанные баги неглядя. Тестировать эти
> > сборки у меня нет ни возможности ни желания.
> > 
> > Когда случаются проблемы, которые я не могу сходу запатчить, то проблемный
> > функционал просто выключаю (удивительно как это не стало ещё заметно).
> > Потому что актуальные архитектуры не должны страдать от этого легаси.
> > 
> > Если вас такой уровень поддержки устраивает, то ок, я буду продолжать
> > такую поддержку 32-x сборок.
> > 
> У меня точно такая же политика - если тест падает на 32-х битах и сходу
> непонятно как чинить, то я его просто выключаю.
> 
> Я думаю что это нормально и если у владельца такой системы возникнет острая
> необходимость починить приложение на 32-х битной архитектуре, то он это
> сделает.
> 
> Но важное замечание заключается в том, что в основном такое происходит с
> разным серверным ПО.

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

Разве что такой подход приведёт к тому что владельцы старого железа скоро
не смогут говорить "у меня есть 32-битный ноут и у меня _всё_работает_".
Это наша цель ?

Какой смысл в такой архитектуре для владельца старого, но работающего
ноутбука ?

-- 
Rgrds, legion

Re: [devel] [#291551] [test-only] FAILED (try 5) crtools.git=3.16.1-alt1

[Anton Farygin]

On 29.01.2022 21:12, Alexey Gladkov wrote:
> On Sat, Jan 29, 2022 at 08:32:32PM +0300, Anton Farygin wrote:
>> On 29.01.2022 16:26, Alexey Gladkov wrote:
>>> On Sat, Jan 29, 2022 at 04:01:15PM +0300, Grigory Ustinov wrote:
>>>> 29.01.2022 15:48, Sergey Y. Afonin пишет:
>>>>> On Saturday 29 January 2022, Dmitry V. Levin wrote:
>>>>>
>>>>>> Давайте честно скажем, что особой пользы от 32-битных архитектур уже нет.
>>>>>> Возможно, неплохая мысль выключить их в недалёком будущем, скажем, к p11.
>>>>> Мне кажется немного рано. Вот к p12 уже может быть.
>>>> Я до сих пор в поездках пользуюсь ноутбуком на Intel Atom N270. Он 32битный,
>>>> он работает и по большому счёту он меня устраивает ровно настолько, что
>>>> 64битный ноутбук я пока не вижу смысла покупать. Возможно не всем нужны
>>>> большие мощности и некоторые люди могут пользоваться устаревшей техникой. У
>>>> одного довольно известного преподавателя курса операционных систем вмк мгу
>>>> это даже стало жизненной позицией, которую я поддерживаю и возможно есть и
>>>> другие пользователи, которые её разделяют в той или иной мере.
>>> Я хочу проговорить вслух всем защитникам 32-x архитектур, чтобы не было
>>> иллюзий и обид:
>>>
>>> Для меня эти архитектуры мертвы. У меня давно нет такого железа, чтобы
>>> проверять там сборки и я патчу связанные баги неглядя. Тестировать эти
>>> сборки у меня нет ни возможности ни желания.
>>>
>>> Когда случаются проблемы, которые я не могу сходу запатчить, то проблемный
>>> функционал просто выключаю (удивительно как это не стало ещё заметно).
>>> Потому что актуальные архитектуры не должны страдать от этого легаси.
>>>
>>> Если вас такой уровень поддержки устраивает, то ок, я буду продолжать
>>> такую поддержку 32-x сборок.
>>>
>> У меня точно такая же политика - если тест падает на 32-х битах и сходу
>> непонятно как чинить, то я его просто выключаю.
>>
>> Я думаю что это нормально и если у владельца такой системы возникнет острая
>> необходимость починить приложение на 32-х битной архитектуре, то он это
>> сделает.
>>
>> Но важное замечание заключается в том, что в основном такое происходит с
>> разным серверным ПО.
> Это ничто иное как деградация архитектуры. Формально архитектура есть, но
> пакеты в ней либо имеют урезанный функционал, либо вообще не работают.
>
> Разве что такой подход приведёт к тому что владельцы старого железа скоро
> не смогут говорить "у меня есть 32-битный ноут и у меня _всё_работает_".
> Это наша цель ?
>
> Какой смысл в такой архитектуре для владельца старого, но работающего
> ноутбука ?

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

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

Re: [devel] [#291551] [test-only] FAILED (try 5) crtools.git=3.16.1-alt1

[Alexey Gladkov]

On Sat, Jan 29, 2022 at 09:16:05PM +0300, Anton Farygin wrote:
> > > У меня точно такая же политика - если тест падает на 32-х битах и сходу
> > > непонятно как чинить, то я его просто выключаю.
> > > 
> > > Я думаю что это нормально и если у владельца такой системы возникнет острая
> > > необходимость починить приложение на 32-х битной архитектуре, то он это
> > > сделает.
> > > 
> > > Но важное замечание заключается в том, что в основном такое происходит с
> > > разным серверным ПО.
> > Это ничто иное как деградация архитектуры. Формально архитектура есть, но
> > пакеты в ней либо имеют урезанный функционал, либо вообще не работают.
> > 
> > Разве что такой подход приведёт к тому что владельцы старого железа скоро
> > не смогут говорить "у меня есть 32-битный ноут и у меня _всё_работает_".
> > Это наша цель ?
> > 
> > Какой смысл в такой архитектуре для владельца старого, но работающего
> > ноутбука ?
> 
> Конечно деградация архитектуры, но тащить архитектуру за апстрим нам будет
> ой как не просто. С учётом того, что она, в целом, нужна только некоторым
> владельцам 32-х битных платформ.
> 
> Поэтому надо и возложить на тех людей, кто хочет 32-бит вопросы поддержки
> желаемой ими архитектуры. Это нормальная практика, на мой взгляд.

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

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

-- 
Rgrds, legion

Re: [devel] [#291551] [test-only] FAILED (try 5) crtools.git=3.16.1-alt1

[Anton Farygin]

On 29.01.2022 21:35, Alexey Gladkov wrote:
> On Sat, Jan 29, 2022 at 09:16:05PM +0300, Anton Farygin wrote:
>>>> У меня точно такая же политика - если тест падает на 32-х битах и сходу
>>>> непонятно как чинить, то я его просто выключаю.
>>>>
>>>> Я думаю что это нормально и если у владельца такой системы возникнет острая
>>>> необходимость починить приложение на 32-х битной архитектуре, то он это
>>>> сделает.
>>>>
>>>> Но важное замечание заключается в том, что в основном такое происходит с
>>>> разным серверным ПО.
>>> Это ничто иное как деградация архитектуры. Формально архитектура есть, но
>>> пакеты в ней либо имеют урезанный функционал, либо вообще не работают.
>>>
>>> Разве что такой подход приведёт к тому что владельцы старого железа скоро
>>> не смогут говорить "у меня есть 32-битный ноут и у меня _всё_работает_".
>>> Это наша цель ?
>>>
>>> Какой смысл в такой архитектуре для владельца старого, но работающего
>>> ноутбука ?
>> Конечно деградация архитектуры, но тащить архитектуру за апстрим нам будет
>> ой как не просто. С учётом того, что она, в целом, нужна только некоторым
>> владельцам 32-х битных платформ.
>>
>> Поэтому надо и возложить на тех людей, кто хочет 32-бит вопросы поддержки
>> желаемой ими архитектуры. Это нормальная практика, на мой взгляд.
> Я призываю придумать критерий, когда можно сказать, что архитектура Х
> находится на поддержке по остаточному принципу, и далее архитектура X
> больше поддерживается вообще, потому что нам уже очень сложно.
>
> Иметь эту информацию в явном виде честнее, чем иметь архитектуру X,
> которая мантейнится по принципу "собралось и ладно". Пользователи такой
> "умирающей" архитектуры смогут что-то сделать до её окончательной
> деградации, либо уйти с неё раз она находится в этом статусе.
>
limited support

Ну и расшифровать что это означает.

Re: [devel] [#291551] [test-only] FAILED (try 5) crtools.git=3.16.1-alt1

[Sergey Afonin]

On Saturday 29 January 2022, Alexey Gladkov wrote:

> Какой смысл в такой архитектуре для владельца старого, но работающего
> ноутбука ?
 
Смысл в "сейчас", так как оборудование ещё есть. У меня вон сервер
один есть на PII, правда там p9 и я не знаю, буду ли дальше обновлять.
И c каждым годом такого оборудования всё меньше, так что чем позже
будет отказ от архитектуры, тем, всё же, лучше.

-- 
С уважением, Сергей Афонин.

Re: [devel] [#291551] [test-only] FAILED (try 5) crtools.git=3.16.1-alt1

[Alexey Sheplyakov]

Здравствуйте!

On Sat, Jan 29, 2022 at 12:30:52AM +0300, Dmitry V. Levin wrote:
> On Tue, Jan 25, 2022 at 07:12:22PM +0300, Vladimir D. Seleznev wrote:
> [...]
> > PI же не про производительность, с другой стороны, особой пользы на
> > 32-хбитных архитектурах ввиду несравненно меньшего адресного
> > пространства по сравнению с 64-хбитными. Возможно, неплохая мысль
> > выключить PI для них.
> 
> Давайте честно скажем, что особой пользы от 32-битных архитектур уже нет.

А давайте немного легче с квантором общности. Возможно, лично Вам пользы от 32-битных
архитектур и нет (хотя мне кажется, что есть, просто Вы её не замечаете).

А так-то есть вагон и маленькая тележка armv7 процессоров (и из них собирают
не только одноплатники), и в ближайшие 5 -- 10 лет они никуда не исчезнут
(а потом, возможно, из вытеснит riscv, тоже 32-битный).

Re: [devel] [#291551] [test-only] FAILED (try 5) crtools.git=3.16.1-alt1

[Denis Medvedev]

В Sat, 29 Jan 2022 19:38:55 +0400
Alexey Sheplyakov <asheplyakov@basealt.ru> пишет:

> Здравствуйте!
> 
> On Sat, Jan 29, 2022 at 12:30:52AM +0300, Dmitry V. Levin wrote:
> > On Tue, Jan 25, 2022 at 07:12:22PM +0300, Vladimir D. Seleznev
> > wrote: [...]
> > > PI же не про производительность, с другой стороны, особой пользы
> > > на 32-хбитных архитектурах ввиду несравненно меньшего адресного
> > > пространства по сравнению с 64-хбитными. Возможно, неплохая мысль
> > > выключить PI для них.
А вот если хотите потом такое сертифицировать, то лучше не надо.
> > 
> > Давайте честно скажем, что особой пользы от 32-битных архитектур
> > уже нет.
> 
> А давайте немного легче с квантором общности. Возможно, лично Вам
> пользы от 32-битных архитектур и нет (хотя мне кажется, что есть,
> просто Вы её не замечаете).
> 
> А так-то есть вагон и маленькая тележка armv7 процессоров (и из них
> собирают не только одноплатники), и в ближайшие 5 -- 10 лет они
> никуда не исчезнут (а потом, возможно, из вытеснит riscv, тоже
> 32-битный).
+1
Да и 32-битные машины никуда не делись - железо 2000х  весьма
надежно. И иногда имеет смысл даже на
64битную такое ставить чтобы побыстрее работало.

Re: [devel] [#291551] [test-only] FAILED (try 5) crtools.git=3.16.1-alt1

[Anton Farygin]

On 29.01.2022 18:50, Denis Medvedev wrote:
>> А так-то есть вагон и маленькая тележка armv7 процессоров (и из них
>> собирают не только одноплатники), и в ближайшие 5 -- 10 лет они
>> никуда не исчезнут (а потом, возможно, из вытеснит riscv, тоже
>> 32-битный).
> +1
> Да и 32-битные машины никуда не делись - железо 2000х  весьма
> надежно. И иногда имеет смысл даже на
> 64битную такое ставить чтобы побыстрее работало.

Денис, ускорение 64-х битных компьютеров за счёт установки на них 
32-битных систем это какой-то миф из детского садика.

Re: [devel] [#291551] [test-only] FAILED (try 5) crtools.git=3.16.1-alt1

[Alexey V. Vissarionov]

On 2022-01-29 18:50:46 +0300, Denis Medvedev wrote:

 >>>> PI же не про производительность, с другой стороны, особой
 >>>> пользы на 32-хбитных архитектурах ввиду несравненно меньшего
 >>>> адресного пространства по сравнению с 64-хбитными. Возможно,
 >>>> неплохая мысль выключить PI для них.
 > А вот если хотите потом такое сертифицировать, то лучше не надо.

Что сертифицировать? x86_32? Отличная шутка, но до 1 апреля еще 2
месяца :-)

 >>> Давайте честно скажем, что особой пользы от 32-битных
 >>> архитектур уже нет.
 >> А давайте немного легче с квантором общности. Возможно, лично
 >> Вам пользы от 32-битных архитектур и нет (хотя мне кажется,
 >> что есть, просто Вы её не замечаете).
 >> А так-то есть вагон и маленькая тележка armv7 процессоров (и
 >> из них собирают не только одноплатники), и в ближайшие 5 -- 10
 >> лет они никуда не исчезнут

ARM32 имеет все шансы пережить писюшатину.

 >> (а потом, возможно, из вытеснит riscv, тоже 32-битный).

А вот это мне пока видится очень маловероятным.

 > +1 Да и 32-битные машины никуда не делись - железо 2000х весьма
 > надежно.

Напомню, что "архитектура" x86_64 появилась в 2003 году - то есть,
она уже справила свое совершеннолетие.

 > И иногда имеет смысл даже на 64битную такое ставить чтобы
 > побыстрее работало.

Опасный миф. Система должна соответствовать железу, и никак иначе.


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

Re: [devel] [#291551] [test-only] FAILED (try 5) crtools.git=3.16.1-alt1

[Dmitry V. Levin]

On Sat, Jan 29, 2022 at 07:38:55PM +0400, Alexey Sheplyakov wrote:
> On Sat, Jan 29, 2022 at 12:30:52AM +0300, Dmitry V. Levin wrote:
> > On Tue, Jan 25, 2022 at 07:12:22PM +0300, Vladimir D. Seleznev wrote:
> > [...]
> > > PI же не про производительность, с другой стороны, особой пользы на
> > > 32-хбитных архитектурах ввиду несравненно меньшего адресного
> > > пространства по сравнению с 64-хбитными. Возможно, неплохая мысль
> > > выключить PI для них.
> > 
> > Давайте честно скажем, что особой пользы от 32-битных архитектур уже нет.
> 
> А давайте немного легче с квантором общности. Возможно, лично Вам пользы от 32-битных
> архитектур и нет (хотя мне кажется, что есть, просто Вы её не замечаете).
> 
> А так-то есть вагон и маленькая тележка armv7 процессоров (и из них собирают
> не только одноплатники), и в ближайшие 5 -- 10 лет они никуда не исчезнут
> (а потом, возможно, из вытеснит riscv, тоже 32-битный).

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

Вопрос же не в том, будут ли эмбеддить armv7 и riscv32, а в том, может
ли быть для этого полезен Сизиф, и если да, то в какой форме и объёме.

Если нужен только cross toolchain и кастомное ядро, то это один ответ.
А если нужен chromium, firefox, kde, и ещё 17+ тысяч исходных пакетов,
то это совсем другой ответ.


-- 
ldv

Re: [devel] subrepository for 32-bit

[Anton Farygin]

On 29.01.2022 19:00, Dmitry V. Levin wrote:
> On Sat, Jan 29, 2022 at 07:38:55PM +0400, Alexey Sheplyakov wrote:
>> On Sat, Jan 29, 2022 at 12:30:52AM +0300, Dmitry V. Levin wrote:
>>> On Tue, Jan 25, 2022 at 07:12:22PM +0300, Vladimir D. Seleznev wrote:
>>> [...]
>>>> PI же не про производительность, с другой стороны, особой пользы на
>>>> 32-хбитных архитектурах ввиду несравненно меньшего адресного
>>>> пространства по сравнению с 64-хбитными. Возможно, неплохая мысль
>>>> выключить PI для них.
>>> Давайте честно скажем, что особой пользы от 32-битных архитектур уже нет.
>> А давайте немного легче с квантором общности. Возможно, лично Вам пользы от 32-битных
>> архитектур и нет (хотя мне кажется, что есть, просто Вы её не замечаете).
>>
>> А так-то есть вагон и маленькая тележка armv7 процессоров (и из них собирают
>> не только одноплатники), и в ближайшие 5 -- 10 лет они никуда не исчезнут
>> (а потом, возможно, из вытеснит riscv, тоже 32-битный).
> Интересно, как вы оцениваете множество задач, которые реально решать на
> таких системах, и множество пакетов в репозитории, которые для этого
> понадобятся.
>
> Вопрос же не в том, будут ли эмбеддить armv7 и riscv32, а в том, может
> ли быть для этого полезен Сизиф, и если да, то в какой форме и объёме.
>
> Если нужен только cross toolchain и кастомное ядро, то это один ответ.
> А если нужен chromium, firefox, kde, и ещё 17+ тысяч исходных пакетов,
> то это совсем другой ответ.

Кстати было бы неплохо предусмотреть такой white list - что по умолчанию 
собирать на какой-то архитектуре, а что нет.

Но его сопровождение может стать отдельной весьма существенной задачей, 
если сразу не придумать её автоматизацию.

Т.е. - автоматически на сборочнице определять, нужно собирать пакет на 
32-х битных архитектурах или нет исходя, например, из сборочных чрутов 
пакетов, входящих в whitelist.

Re: [devel] subrepository for 32-bit

[Alexey Gladkov]

On Sat, Jan 29, 2022 at 08:41:21PM +0300, Anton Farygin wrote:
> On 29.01.2022 19:00, Dmitry V. Levin wrote:
> > On Sat, Jan 29, 2022 at 07:38:55PM +0400, Alexey Sheplyakov wrote:
> > > On Sat, Jan 29, 2022 at 12:30:52AM +0300, Dmitry V. Levin wrote:
> > > > On Tue, Jan 25, 2022 at 07:12:22PM +0300, Vladimir D. Seleznev wrote:
> > > > [...]
> > > > > PI же не про производительность, с другой стороны, особой пользы на
> > > > > 32-хбитных архитектурах ввиду несравненно меньшего адресного
> > > > > пространства по сравнению с 64-хбитными. Возможно, неплохая мысль
> > > > > выключить PI для них.
> > > > Давайте честно скажем, что особой пользы от 32-битных архитектур уже нет.
> > > А давайте немного легче с квантором общности. Возможно, лично Вам пользы от 32-битных
> > > архитектур и нет (хотя мне кажется, что есть, просто Вы её не замечаете).
> > > 
> > > А так-то есть вагон и маленькая тележка armv7 процессоров (и из них собирают
> > > не только одноплатники), и в ближайшие 5 -- 10 лет они никуда не исчезнут
> > > (а потом, возможно, из вытеснит riscv, тоже 32-битный).
> > Интересно, как вы оцениваете множество задач, которые реально решать на
> > таких системах, и множество пакетов в репозитории, которые для этого
> > понадобятся.
> > 
> > Вопрос же не в том, будут ли эмбеддить armv7 и riscv32, а в том, может
> > ли быть для этого полезен Сизиф, и если да, то в какой форме и объёме.
> > 
> > Если нужен только cross toolchain и кастомное ядро, то это один ответ.
> > А если нужен chromium, firefox, kde, и ещё 17+ тысяч исходных пакетов,
> > то это совсем другой ответ.
> 
> Кстати было бы неплохо предусмотреть такой white list - что по умолчанию
> собирать на какой-то архитектуре, а что нет.
> 
> Но его сопровождение может стать отдельной весьма существенной задачей, если
> сразу не придумать её автоматизацию.
> 
> Т.е. - автоматически на сборочнице определять, нужно собирать пакет на 32-х
> битных архитектурах или нет исходя, например, из сборочных чрутов пакетов,
> входящих в whitelist.

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

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

Возможно, в сборочнице стоит иметь градации поддержки архитектур (я
придумываю на ходу). Для некоторых архитектур можно собирать лишь то что
входит в базой чрут перед их смертью. Когда через ExcludeArch даже чрут не
может быть собран, то выкидывать окончательно. (Это просто абстрактные
мысли на тему).

-- 
Rgrds, legion

Re: [devel] subrepository for 32-bit

[Ilya Kurdyukov]

x86 никогда не устареет, но только из-за Wine. Потому что существует 
большое количество старых программ (без исходников), которые 
пользователи хотели бы продолжать эмулировать через Wine.

Те дистрибутивы что хотели удалить x86 в итоге столкнулись с большим 
негодованием пользователей и объявили что будут продолжать поддерживать 
необходимую для работы Wine часть.

А вот другие 32-бит архитектуры могут устареть. Но тоже не скоро, потому 
что у народа всё еще есть большое количество девайсов на них (типа 
девелоперских плат), которые вполне можно использовать.

On 30.01.2022 01:25, Alexey Gladkov wrote:
>
> На самом деле вопрос стоит ставить шире. Мы тут обсуждаем устаревание и
> последующее выкидывание какой-либо архитектуры. Для любой архитектуры икс
> будут оставаться пользователи, которые будут против остановки
> сопровождения архитектуры икс.
>
> Нужно иметь какой-то протокол, как определить, что затраты на
> сопровождение архитектуры выше от плюсов присутствия сизифа на ней.
>
> Возможно, в сборочнице стоит иметь градации поддержки архитектур (я
> придумываю на ходу). Для некоторых архитектур можно собирать лишь то что
> входит в базой чрут перед их смертью. Когда через ExcludeArch даже чрут не
> может быть собран, то выкидывать окончательно. (Это просто абстрактные
> мысли на тему).
>

Re: [devel] subrepository for 32-bit

[Aleksey Novodvorsky]

вс, 30 янв. 2022 г. в 09:16, Ilya Kurdyukov <ilyakurdyukov@basealt.ru>:
>
> https://www.linuxuprising.com/2019/06/wine-developers-concerned-with-ubuntu.html
>
> https://ubuntu.com/blog/statement-on-32-bit-i386-packages-for-ubuntu-19-10-and-20-04-lts

Речь про Ubuntu?
1. 20.04 не поддерживает x86, но установить wine можно:
https://wine.htmlvalidator.com/install-wine-on-ubuntu-20.04.html
p10 полностью поддерживает x86/
2. Поддержка  20.04 заканчиватся в первой половине 2025 года.
У p10 -- во второй половине 2024 года. При необходимости можно продлить.
Можно подождать 22.04 LTS и посмотреть, если есть сомнения.

Rgrds, Алексей

>
> On 30.01.2022 11:52, Aleksey Novodvorsky wrote:
>
>
>
> вс, 30 янв. 2022 г., 07:42 Ilya Kurdyukov <ilyakurdyukov@basealt.ru>:
>>
>> x86 никогда не устареет, но только из-за Wine. Потому что существует
>> большое количество старых программ (без исходников), которые
>> пользователи хотели бы продолжать эмулировать через Wine.
>>
>> Те дистрибутивы что хотели удалить x86 в итоге столкнулись с большим
>> негодованием пользователей и объявили что будут продолжать поддерживать
>> необходимую для работы Wine часть
>
>
> Например,  какие? Хотелось бы посмотреть, какую часть они поддерживают.
>>
>> .
>>
>> А вот другие 32-бит архитектуры могут устареть. Но тоже не скоро, потому
>> что у народа всё еще есть большое количество девайсов на них (типа
>> девелоперских плат), которые вполне можно использовать.
>
>
> Какие, кроме armh?
> На невключение mipsel в p10 жалоб не припомню.
> И "не скоро" это когда?
>
> Rgrds, Алексей
>>
>>
>> On 30.01.2022 01:25, Alexey Gladkov wrote:
>> >
>> > На самом деле вопрос стоит ставить шире. Мы тут обсуждаем устаревание и
>> > последующее выкидывание какой-либо архитектуры. Для любой архитектуры икс
>> > будут оставаться пользователи, которые будут против остановки
>> > сопровождения архитектуры икс.
>> >
>> > Нужно иметь какой-то протокол, как определить, что затраты на
>> > сопровождение архитектуры выше от плюсов присутствия сизифа на ней.
>> >
>> > Возможно, в сборочнице стоит иметь градации поддержки архитектур (я
>> > придумываю на ходу). Для некоторых архитектур можно собирать лишь то что
>> > входит в базой чрут перед их смертью. Когда через ExcludeArch даже чрут не
>> > может быть собран, то выкидывать окончательно. (Это просто абстрактные
>> > мысли на тему).
>> >
>> _______________________________________________
>> Devel mailing list
>> Devel@lists.altlinux.org
>> https://lists.altlinux.org/mailman/listinfo/devel
>
>
> _______________________________________________
> Devel mailing list
> Devel@lists.altlinux.org
> https://lists.altlinux.org/mailman/listinfo/devel
>
> _______________________________________________
> Devel mailing list
> Devel@lists.altlinux.org
> https://lists.altlinux.org/mailman/listinfo/devel

Re: [devel] subrepository for 32-bit

[Антон Мидюков]

30.01.2022 13:35, Aleksey Novodvorsky пишет:
> вс, 30 янв. 2022 г. в 09:16, Ilya Kurdyukov <ilyakurdyukov@basealt.ru>:
>>
>> https://www.linuxuprising.com/2019/06/wine-developers-concerned-with-ubuntu.html
>>
>> https://ubuntu.com/blog/statement-on-32-bit-i386-packages-for-ubuntu-19-10-and-20-04-lts
> 
> Речь про Ubuntu?
> 1. 20.04 не поддерживает x86, но установить wine можно:
> https://wine.htmlvalidator.com/install-wine-on-ubuntu-20.04.html

Через подключение Multi-Arch репозитория i386 - аналога нашего x86_64-i586.
В 22.04 они также будут поддерживать Multi-Arch в объёме, требуемом для
wine и steam. Вот и нам бы в таком же объёме и поддерживать x86_64-i586 в p11.

-- 
С уважением, Антон Мидюков <antohami@altlinux.org>

Re: [devel] subrepository for 32-bit

[Ilya Kurdyukov]

Моё личное мнение:

1. Поддерживать x86 32-бит дистрибутив нет смысла, потому что какой 
смысл в операционной системе которая не может адресовать более 4Гб 
памяти, когда размеры оперативной памяти увеличиваются и увеличиваются.

2. Но я за поддержку запуска 32-бит приложений на 64-бит системах. 
Запуск 32-бит кода в Wine точно должен быть поддержан неограниченно 
долго, до тех пор пока в большинстве x86 процессоров не уберут поддержку 
32-бит режима. Тогда уже будем использовать эмуляторы.

3. 32-бит ARM должен быть поддержан пока в ходу есть много мелких 
девайсов для него (и на многих менее 4Гб памяти, так что размер адреса 
ничем не мешает).

 > На невключение mipsel в p10 жалоб не припомню.

Ну и не должна никого волновать какая-то малораспространённая 
архитектура. Просто не надо складывать все 32-бит архитектуры в одну 
кучу, популярные стоит поддерживать, не популярные не стоит.

Re: [devel] subrepository for 32-bit

[Anton Farygin]

On 30.01.2022 11:05, Ilya Kurdyukov wrote:
> Моё личное мнение:
>
> 1. Поддерживать x86 32-бит дистрибутив нет смысла, потому что какой 
> смысл в операционной системе которая не может адресовать более 4Гб 
> памяти, когда размеры оперативной памяти увеличиваются и увеличиваются.
>
> 2. Но я за поддержку запуска 32-бит приложений на 64-бит системах. 
> Запуск 32-бит кода в Wine точно должен быть поддержан неограниченно 
> долго, до тех пор пока в большинстве x86 процессоров не уберут 
> поддержку 32-бит режима. Тогда уже будем использовать эмуляторы.
>
> 3. 32-бит ARM должен быть поддержан пока в ходу есть много мелких 
> девайсов для него (и на многих менее 4Гб памяти, так что размер адреса 
> ничем не мешает).
>
> > На невключение mipsel в p10 жалоб не припомню.
>
> Ну и не должна никого волновать какая-то малораспространённая 
> архитектура. Просто не надо складывать все 32-бит архитектуры в одну 
> кучу, популярные стоит поддерживать, не популярные не стоит.


Илья всё написал правильно, но вот 32-bit ARM это скорее про бизнес, а 
не про пользователей - я давно уже не слышал о том, что бы кто-то из 
наших разработчиков пытался что-то делать с armv7.

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

Re: [devel] subrepository for 32-bit

[Ilya Kurdyukov]

On 30.01.2022 16:24, Anton Farygin wrote:
> On 30.01.2022 11:05, Ilya Kurdyukov wrote:
>> Моё личное мнение:
>>
>> 1. Поддерживать x86 32-бит дистрибутив нет смысла, потому что какой 
>> смысл в операционной системе которая не может адресовать более 4Гб 
>> памяти, когда размеры оперативной памяти увеличиваются и увеличиваются.
>>
>> 2. Но я за поддержку запуска 32-бит приложений на 64-бит системах. 
>> Запуск 32-бит кода в Wine точно должен быть поддержан неограниченно 
>> долго, до тех пор пока в большинстве x86 процессоров не уберут 
>> поддержку 32-бит режима. Тогда уже будем использовать эмуляторы.
>>
>> 3. 32-бит ARM должен быть поддержан пока в ходу есть много мелких 
>> девайсов для него (и на многих менее 4Гб памяти, так что размер 
>> адреса ничем не мешает).
>>
>> > На невключение mipsel в p10 жалоб не припомню.
>>
>> Ну и не должна никого волновать какая-то малораспространённая 
>> архитектура. Просто не надо складывать все 32-бит архитектуры в одну 
>> кучу, популярные стоит поддерживать, не популярные не стоит.
>
>
> Илья всё написал правильно, но вот 32-bit ARM это скорее про бизнес, а 
> не про пользователей - я давно уже не слышал о том, что бы кто-то из 
> наших разработчиков пытался что-то делать с armv7.
>
> А с точки зрения сопровождения ментейнерами armv7 более сложная 
> архитектура, т.к. реального быстрого железа с её поддержкой не так 
> много, а на эмуляторах далеко и быстро не поедешь.
>
>
На самом деле энтузиастов использующих armv7 много, тут скорее вопрос в 
том, что Альт Линукс делает для их привлечения? А похоже что не делается 
ничего. Потому что есть специализированные дистрибутивы типа Armbian, 
где можно найти готовые сборки под каждую конкретную плату. А чтобы 
установить Альт - я так понимаю надо повозиться и никто помогать не 
будет. Может не получиться, может что-то не работать на конкретной 
плате. Вот поэтому среди разработчиков Альта и нет этих энтузиастов.

Так что, наверное, если из Альта убрать armv7 то мало кто расстроится, 
потому что эти люди не используют Альт.

Re: [devel] subrepository for 32-bit

[Anton Farygin]

On 30.01.2022 13:15, Ilya Kurdyukov wrote:
> On 30.01.2022 16:24, Anton Farygin wrote:
>> On 30.01.2022 11:05, Ilya Kurdyukov wrote:
>>> Моё личное мнение:
>>>
>>> 1. Поддерживать x86 32-бит дистрибутив нет смысла, потому что какой 
>>> смысл в операционной системе которая не может адресовать более 4Гб 
>>> памяти, когда размеры оперативной памяти увеличиваются и увеличиваются.
>>>
>>> 2. Но я за поддержку запуска 32-бит приложений на 64-бит системах. 
>>> Запуск 32-бит кода в Wine точно должен быть поддержан неограниченно 
>>> долго, до тех пор пока в большинстве x86 процессоров не уберут 
>>> поддержку 32-бит режима. Тогда уже будем использовать эмуляторы.
>>>
>>> 3. 32-бит ARM должен быть поддержан пока в ходу есть много мелких 
>>> девайсов для него (и на многих менее 4Гб памяти, так что размер 
>>> адреса ничем не мешает).
>>>
>>> > На невключение mipsel в p10 жалоб не припомню.
>>>
>>> Ну и не должна никого волновать какая-то малораспространённая 
>>> архитектура. Просто не надо складывать все 32-бит архитектуры в одну 
>>> кучу, популярные стоит поддерживать, не популярные не стоит.
>>
>>
>> Илья всё написал правильно, но вот 32-bit ARM это скорее про бизнес, 
>> а не про пользователей - я давно уже не слышал о том, что бы кто-то 
>> из наших разработчиков пытался что-то делать с armv7.
>>
>> А с точки зрения сопровождения ментейнерами armv7 более сложная 
>> архитектура, т.к. реального быстрого железа с её поддержкой не так 
>> много, а на эмуляторах далеко и быстро не поедешь.
>>
>>
> На самом деле энтузиастов использующих armv7 много, тут скорее вопрос 
> в том, что Альт Линукс делает для их привлечения? А похоже что не 
> делается ничего. Потому что есть специализированные дистрибутивы типа 
> Armbian, где можно найти готовые сборки под каждую конкретную плату. А 
> чтобы установить Альт - я так понимаю надо повозиться и никто помогать 
> не будет. Может не получиться, может что-то не работать на конкретной 
> плате. Вот поэтому среди разработчиков Альта и нет этих энтузиастов.
>
> Так что, наверное, если из Альта убрать armv7 то мало кто расстроится, 
> потому что эти люди не используют Альт. 


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


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

Re: [devel] subrepository for 32-bit

[Alexey V. Vissarionov]

On 2022-01-30 13:25:13 +0300, Anton Farygin wrote:

 >> На самом деле энтузиастов использующих armv7 много, тут скорее
 >> вопрос в том, что Альт Линукс делает для их привлечения? А похоже
 >> что не делается ничего. Потому что есть специализированные
 >> дистрибутивы типа Armbian, где можно найти готовые сборки под
 >> каждую конкретную плату. А чтобы установить Альт - я так понимаю
 >> надо повозиться

Да.

 >> и никто помогать не будет.

Более того, можно и на прямое противодействие нарваться.

 >> Может не получиться, может что-то не работать на конкретной
 >> плате.

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

 >> Вот поэтому среди разработчиков Альта и нет этих энтузиастов.

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

 >> Так что, наверное, если из Альта убрать armv7 то мало кто
 >> расстроится, потому что эти люди не используют Альт.

Вот не надо квантором \forall размахивать...

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

Это от бедности. Когда специализированная сборка выпекается за
3...4 минуты - никто морочиться созданием SDK не будет.

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

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

Ээнтузиастов хватает. Только зачем им отшибать энтузиазм - я не
понимаю.


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

Re: [devel] subrepository for 32-bit

[Michael Shigorin]

On Sun, Jan 30, 2022 at 03:05:18PM +0700, Ilya Kurdyukov wrote:
> Моё личное мнение:
> 1. Поддерживать x86 32-бит дистрибутив нет смысла, потому что какой 
> смысл в операционной системе которая не может адресовать более 4Гб 
> памяти, когда размеры оперативной памяти увеличиваются и увеличиваются.

На всякий напомню мнение Линуса, высказанное десятилетием раньше:
http://cl4ssic4l.wordpress.com/2011/05/24/linus-torvalds-about-pae/
(вкратце: "больше гигабайта => нужно 64-битное адресное пространство")

ПМСМ дело даже не в "увеличиваются" (на многих ещё живых железках,
сделанных из железа, памяти до 4 Гб включительно) -- а в браузерах, 
которые для активного пользователя десктопного старья вроде меня
в эту границу вплотную упёрлись ещё около Firefox 52 (т.е. когда
остальное -- это wmaker и xterm+ssh/vim, но порой не хватает).

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

Re: [devel] subrepository for 32-bit

[Andrey Savchenko]

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

On Sun, 30 Jan 2022 23:14:53 +0300 Michael Shigorin wrote:
> On Sun, Jan 30, 2022 at 03:05:18PM +0700, Ilya Kurdyukov wrote:
> > Моё личное мнение:
> > 1. Поддерживать x86 32-бит дистрибутив нет смысла, потому что какой 
> > смысл в операционной системе которая не может адресовать более 4Гб 
> > памяти, когда размеры оперативной памяти увеличиваются и увеличиваются.
> 
> На всякий напомню мнение Линуса, высказанное десятилетием раньше:
> http://cl4ssic4l.wordpress.com/2011/05/24/linus-torvalds-about-pae/
> (вкратце: "больше гигабайта => нужно 64-битное адресное пространство")
> 
> ПМСМ дело даже не в "увеличиваются" (на многих ещё живых железках,
> сделанных из железа, памяти до 4 Гб включительно) -- а в браузерах, 
> которые для активного пользователя десктопного старья вроде меня
> в эту границу вплотную упёрлись ещё около Firefox 52 (т.е. когда
> остальное -- это wmaker и xterm+ssh/vim, но порой не хватает).

Ну вот есть у людей 32-битное железо, которое ещё работает. И им
предлагается его выбросить, потому что "нужно 64-битное адресное
пространство". Мило. Более вероятно, что вместо такого дистрибутива
будет что-то другое использоваться.

P.S. Для браузера 32 бит вполне хватает 2GB RAM + zswap или 3 GB
RAM, если 100500 вкладок не открывать.

Best regards,
Andrew Savchenko

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

Re: [devel] subrepository for 32-bit

[Aleksey Novodvorsky]

вс, 30 янв. 2022 г. в 23:50, Andrey Savchenko <bircoph@altlinux.org>:
>
> On Sun, 30 Jan 2022 23:14:53 +0300 Michael Shigorin wrote:
> > On Sun, Jan 30, 2022 at 03:05:18PM +0700, Ilya Kurdyukov wrote:
> > > Моё личное мнение:
> > > 1. Поддерживать x86 32-бит дистрибутив нет смысла, потому что какой
> > > смысл в операционной системе которая не может адресовать более 4Гб
> > > памяти, когда размеры оперативной памяти увеличиваются и увеличиваются.
> >
> > На всякий напомню мнение Линуса, высказанное десятилетием раньше:
> > http://cl4ssic4l.wordpress.com/2011/05/24/linus-torvalds-about-pae/
> > (вкратце: "больше гигабайта => нужно 64-битное адресное пространство")
> >
> > ПМСМ дело даже не в "увеличиваются" (на многих ещё живых железках,
> > сделанных из железа, памяти до 4 Гб включительно) -- а в браузерах,
> > которые для активного пользователя десктопного старья вроде меня
> > в эту границу вплотную упёрлись ещё около Firefox 52 (т.е. когда
> > остальное -- это wmaker и xterm+ssh/vim, но порой не хватает).
>
> Ну вот есть у людей 32-битное железо, которое ещё работает. И им
> предлагается его выбросить, потому что "нужно 64-битное адресное
> пространство". Мило. Более вероятно, что вместо такого дистрибутива
> будет что-то другое использоваться.

Что же?
Мы поддерживаем сборки x86 еще почти три года. Ubuntu с 20.04 уже не
поддерживает, только wine
Но wine собирается в течение года решить проблему.
>
> P.S. Для браузера 32 бит вполне хватает 2GB RAM + zswap или 3 GB
> RAM, если 100500 вкладок не открывать.
Да.
Но надо смотреть вперед и соотносить усилия и результаты.
Предлагаю не спешить с выводами, а далее провести опрос наших
пользователей. Нужна конкретика, а не общие рассуждения.
Спасибо.
Rgrds, Алексей
>
> Best regards,
> Andrew Savchenko
> _______________________________________________
> Devel mailing list
> Devel@lists.altlinux.org
> https://lists.altlinux.org/mailman/listinfo/devel

Re: [devel] subrepository for 32-bit

[Alexey Sheplyakov]

Здравствуйте!

On Mon, Jan 31, 2022 at 12:03:04AM +0300, Aleksey Novodvorsky wrote:

> Мы поддерживаем сборки x86 еще почти три года. Ubuntu с 20.04 уже не
> поддерживает, только wine
> Но wine собирается в течение года решить проблему.

Та же Ubuntu поддерживает armv7 и не собирается его выпиливать.
В частности, поддерживается raspberry pi 2, и поддерживать её собираются
по крайней мере до 2030-го года. См.

https://ubuntu.com/download/raspberry-pi

Надо бы им рассказать, что для IoT ОС общего назначения не нужна.
А то мужики не знают.

> >
> > P.S. Для браузера 32 бит вполне хватает 2GB RAM + zswap или 3 GB
> > RAM, если 100500 вкладок не открывать.
> Да.
> Но надо смотреть вперед и соотносить усилия и результаты.
> Предлагаю не спешить с выводами, а далее провести опрос наших


Есть такая программа - КуМир называется. С помощью неё деток программировать
учат (насколько хорошо она для этой цели подходит - другой вопрос).
Так вот графический интерфейс у этой программы на Qt4. Это совершенно не
потому, что разработчики не умеют в Qt5, или не умеют в Qt5. Им надо
поддерживать (та-дам!) Windows XP:
 
https://www.niisi.ru/kumir/dl.htm

Это потому, что в школах полно PC, которые не умеют в 64 бита. Среди них
есть и не очень старые, например Intel Atom 2014 -- 2016 годов. И пока
они физически не выйдут из строя, покупать новые никто не будет.

Всего доброго,
    Алексей

Re: [devel] subrepository for 32-bit

[Антон Мидюков]

31.01.2022 17:23, Alexey Sheplyakov пишет:
[...]
> Это потому, что в школах полно PC, которые не умеют в 64 бита. Среди них
> есть и не очень старые, например Intel Atom 2014 -- 2016 годов. И пока
> они физически не выйдут из строя, покупать новые никто не будет.
> 

Процессоры Intel Atom, начиная с 2014, 64-битные. 


-- 
С уважением, Антон Мидюков <antohami@altlinux.org>

Re: [devel] subrepository for 32-bit

[Ilya Kurdyukov]

On 31.01.2022 03:49, Andrey Savchenko wrote:
> Ну вот есть у людей 32-битное железо, которое ещё работает. И им
> предлагается его выбросить, потому что "нужно 64-битное адресное
> пространство". Мило. Более вероятно, что вместо такого дистрибутива
> будет что-то другое использоваться.

Ну, например, есть у меня 32-бит нетбук, вот только DE для линукс стали 
тяжеловесные (а на лёгких DE сталкиваешся с разными недоработками или 
проблемами отображения). И в дистрибутивах много лишнего и раздувается 
еще объём занимаемый операционной системой в памяти. А современные 
браузеры и веб-страницы требуют много памяти и вычислительных ресурсов 
на скрипты. Так что если на старое железо и ставить дистрибутив, то или 
тоже старый или специализированный. Иначе пользоваться этим будет очень 
печально. Можете найти в интернете как пользователи Windows жалуются что 
Windows обновился и стало тормозить, а до этого было нормально. Или 
пользователей старых Айфонов, та же проблема. Так вот, дистрибутивы 
линукса тоже подвержены этой проблеме.

>
> P.S. Для браузера 32 бит вполне хватает 2GB RAM + zswap или 3 GB
> RAM, если 100500 вкладок не открывать.
>
> Best regards,
> Andrew Savchenko
>
Когда браузер уходит в своп, то всё начинает дико тормозить. И дело не 
во вкладках. А потому что многие сайты теперь не позволяют просматривать 
контент кусками. Например 10, 25, 50 записей на страницу. Вместо этого 
листаешь вниз страницы и она подгружается и подгружается. Вот тут то 
память и заканчивается, хоть даже у вас одна вкладка.

Re: [devel] subrepository for 32-bit

[Sergey Afonin]

On Monday 31 January 2022, Ilya Kurdyukov wrote:

> А потому что многие сайты теперь не позволяют просматривать 
> контент кусками. Например 10, 25, 50 записей на страницу.
> Вместо этого листаешь вниз страницы и она подгружается и
> подгружается. 

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

-- 
С уважением, Сергей Афонин.

Re: [devel] subrepository for 32-bit

[arbars]

31.01.2022 02:49, Andrey Savchenko пишет:
> Ну вот есть у людей 32-битное железо, которое ещё работает. И им
> предлагается его выбросить, потому что "нужно 64-битное адресное
> пространство". Мило. Более вероятно, что вместо такого дистрибутива
> будет что-то другое использоваться.
>
> P.S. Для браузера 32 бит вполне хватает 2GB RAM + zswap или 3 GB
> RAM, если 100500 вкладок не открывать.
>
> Best regards,
> Andrew Savchenko
>
> _______________________________________________
> Devel mailing list
> Devel@lists.altlinux.org
> https://lists.altlinux.org/mailman/listinfo/devel
Как владелец как минимум двух рабочих станций и одного самосборного 
сервака на 32-хбитной архитектуре (1-й пентиум 120 MHz c и 4-й пентиум 
на 3 GHz),
а также практикующий "некромантию" в плане старого железа как явления, 
хочу вставить свои 5 копеек в эту беседу.

Отталкиваться я буду от своих реалий, опираясь на свой опыт.

Несут мне такие машины и из школ, до которых апгрейд за счёт государства 
не дошёл, и просто обычные люди, у которых не то что на новое железо,
но и на винду с драйверами денег особо нет, а сделать доп. рабочее или 
учебное место - надо. Как итог - забиваем максимум ОЗУ, который видит мать,
ставим пингвина второй системой на отдельный диск на случай смерти 
винды, и готово.

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

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

И в этом как раз дистры, собранные для 32 бит - огромное подспорье.

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

Re: [devel] subrepository for 32-bit

[Alexey V. Vissarionov]

On 2022-01-31 22:42:10 +0600, arbars wrote:

 >> Ну вот есть у людей 32-битное железо, которое ещё работает.
 >> И им предлагается его выбросить, потому что "нужно 64-битное
 >> адресное пространство". Мило. Более вероятно, что вместо
 >> такого дистрибутива будет что-то другое использоваться.

32-битное железо бывает очень разным. Между 80386 и пнем-3 (на
котором начинают работать наши "i586") - пропасть. Между этим
же пнем-3 и пнем-4 - ну ладно, уже не пропасть, но нефиговый
каньон. И даже между пнями-4 для S478 и LGA775 - овраг, который
на кривой козе не объедешь.

 >> P.S. Для браузера 32 бит вполне хватает 2GB RAM + zswap
 >> или 3 GB RAM, если 100500 вкладок не открывать.

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

 > Как владелец как минимум двух рабочих станций и одного
 > самосборного сервака на 32-хбитной архитектуре (1-й пентиум
 > 120 MHz c и 4-й пентиум на 3 GHz),

Ээээ... ну ладно, пням-4 еще можно найти какое-то применение,
если снабдить их 4 Гб ОЗУ. Но все более древнее лично я сразу
кладу на прехитер и снимаю все интересное.

 > а также практикующий "некромантию" в плане старого железа
 > как явления, хочу вставить свои 5 копеек в эту беседу.
 > Отталкиваться я буду от своих реалий, опираясь на свой опыт.

Тогда я на всякий случай тоже уточню, что описываю свой опыт.

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

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

 > Как итог - забиваем максимум ОЗУ, который видит мать,

Это третий этап. Первые два - поиск подходящих камня и платы.

 > ставим пингвина

Да, и здесь у Альта есть серьезное преимущество в виде сборок
с sysVinit для десктопов.

 > второй системой на отдельный диск на случай смерти винды,

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

 > и готово.

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

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

Любое железо x86_32 я по умолчанию считаю устаревшим. Возможны
исключения (обычно это ноутбуки), но их пренебрежимо мало.

 > Не десктопом - так сервером,

Наоборот: не сервером - так десктопом. Вот прям сегодня я лично
собирал несколько пакетов на вполне себе десктопном аппарате с
двумя E5-2403 и 48 Гб ОЗУ :-)

 > не сервером - так роутером или файлопомойкой для телевизора.
 > Или тонким клиентом. Было бы железо, а задачи найдутся.

Для x86_64 и с недавних пор aarch64 - да. Для других архитектур
ситуация противоположная: были бы задачи, а железо уже валяется
без дела.

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

s/ железу//

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

 > настраиваем проброс "канала связи" и радуемся жизни.

Зачем такое внимание каналу связи? Уж к локальной-то сети можно
подключить любой антиквариат...

 > Если нужно что-то этакое - думаем и предлагаем возможные
 > решения на замену.

... всего компутера. То есть, камень+плата+память сразу вместо
"здрасте", а остальное по возможности, в зависимости от того,
что в данный момент есть в нычке.

 > И в этом как раз дистры, собранные для 32 бит - огромное
 > подспорье.

Есть - хорошо. Не будет их - ну и пусть с ними.

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

А для десктопа (точнее, уже "тонкого клиента") больше ничего и не
нужно: X11 с прибитой гвоздями настройкой "использовать fbdev и
xorg-drv-input-core", туда какой-нибудь легковесный window manager,
urxvt (он даже легче, чем классический xterm), firefox, клиенты VNC
и (увы!) RDP - да и все. Остальное, если понадобится, усер запустит
на "большом" компутере.


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

Re: [devel] OOM OMG OMG...

[Paul Wolneykien]

В Tue, 1 Feb 2022 00:55:18 +0300
"Alexey V. Vissarionov" <gremlin@altlinux.org> пишет:

>  >> P.S. Для браузера 32 бит вполне хватает 2GB RAM + zswap
>  >> или 3 GB RAM, если 100500 вкладок не открывать.  
> 
> Ага. А когда нужно запустить что-то еще - обязательно завершить
> этот процесс, чтобы он память не жрал.

  И тут мы возвращаемся к другому вопросу: как, всё-таки, настроить
OOM-killer так, чтобы он не отправлял систему в бесконечный цикл и не
требовал перезагрузки по питанию? Потому, что кроме старого 32-битного
железа с 3 GB RAM, есть ещё большое количества старого 64-битного
железа с 2 GB RAM, которое физически отомрёт в тех же школах наверняка
позже 32-битного.

Re: [devel] OOM OMG OMG...

[Andrey Savchenko]

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

On Tue, 1 Feb 2022 02:26:57 +0300 Paul Wolneykien wrote:
> В Tue, 1 Feb 2022 00:55:18 +0300
> "Alexey V. Vissarionov" <gremlin@altlinux.org> пишет:
> 
> >  >> P.S. Для браузера 32 бит вполне хватает 2GB RAM + zswap
> >  >> или 3 GB RAM, если 100500 вкладок не открывать.  
> > 
> > Ага. А когда нужно запустить что-то еще - обязательно завершить
> > этот процесс, чтобы он память не жрал.
> 
>   И тут мы возвращаемся к другому вопросу: как, всё-таки, настроить
> OOM-killer так, чтобы он не отправлял систему в бесконечный цикл и не
> требовал перезагрузки по питанию? Потому, что кроме старого 32-битного
> железа с 3 GB RAM, есть ещё большое количества старого 64-битного
> железа с 2 GB RAM, которое физически отомрёт в тех же школах наверняка
> позже 32-битного.

В первую очередь следует включить zswap, лучше всего с методом
z3fold. Это где-то в 1.5 раза эффективный объём памяти увеличит, но
сделает хвост более медленным, но всё равно много лучше свопа.

Best regards,
Andrew Savchenko

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

Re: [devel] OOM OMG OMG...

[Paul Wolneykien]

В Tue, 1 Feb 2022 02:55:31 +0300
Andrey Savchenko <bircoph@altlinux.org> пишет:

> On Tue, 1 Feb 2022 02:26:57 +0300 Paul Wolneykien wrote:
> > В Tue, 1 Feb 2022 00:55:18 +0300
> > "Alexey V. Vissarionov" <gremlin@altlinux.org> пишет:
> >   
> > >  >> P.S. Для браузера 32 бит вполне хватает 2GB RAM + zswap
> > >  >> или 3 GB RAM, если 100500 вкладок не открывать.    
> > > 
> > > Ага. А когда нужно запустить что-то еще - обязательно завершить
> > > этот процесс, чтобы он память не жрал.  
> > 
> >   И тут мы возвращаемся к другому вопросу: как, всё-таки, настроить
> > OOM-killer так, чтобы он не отправлял систему в бесконечный цикл и
> > не требовал перезагрузки по питанию? Потому, что кроме старого
> > 32-битного железа с 3 GB RAM, есть ещё большое количества старого
> > 64-битного железа с 2 GB RAM, которое физически отомрёт в тех же
> > школах наверняка позже 32-битного.  
> 
> В первую очередь следует включить zswap, лучше всего с методом
> z3fold. Это где-то в 1.5 раза эффективный объём памяти увеличит, но
> сделает хвост более медленным, но всё равно много лучше свопа.

  Но это всё-равно вероятностное решение будет: лопнет — не лопнет. Тут
ведь вся интрига в том, что когда ты кликаешь на ссылку, то точно не
знаешь, на какой сайт попадёшь — на лёгкий или на тяжёлый. И если память
лопнет, то наверняка придётся перезагружать всю систему, а не вкладку и
даже не браузер.

  Идеального поведения в отношении браузера я добивался отключением
overcommit_memory. В случае исчерпания памяти очередная вкладка
показывала сообщение "Извините, вкладка упала", а всё остальное
продолжало работать. Я так понял, что новый Firefox умеет не падать
целиком.
  Это действительно было идеально, но на машинке, у которой было
больше 2 ГБ, возможно даже 4 ГБ. Если памяти меньше, то с отключённым
overcommit даже простой графический сеанс уже не запустить. А там, где
сеанс и браузер запустить удаётся, часто нет возможности даже открыть
новый эмулятор терминала. По-видимому, переоцениваются потребности
очередного fork() или что-то в этом роде.
  Поэтому отключение overcommit это тоже не выход. К сожалению.

Re: [devel] OOM OMG OMG...

[Andrey Savchenko]

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

On Tue, 1 Feb 2022 13:58:53 +0300 Paul Wolneykien wrote:
> В Tue, 1 Feb 2022 02:55:31 +0300
> Andrey Savchenko <bircoph@altlinux.org> пишет:
> 
> > On Tue, 1 Feb 2022 02:26:57 +0300 Paul Wolneykien wrote:
> > > В Tue, 1 Feb 2022 00:55:18 +0300
> > > "Alexey V. Vissarionov" <gremlin@altlinux.org> пишет:
> > >   
> > > >  >> P.S. Для браузера 32 бит вполне хватает 2GB RAM + zswap
> > > >  >> или 3 GB RAM, если 100500 вкладок не открывать.    
> > > > 
> > > > Ага. А когда нужно запустить что-то еще - обязательно завершить
> > > > этот процесс, чтобы он память не жрал.  
> > > 
> > >   И тут мы возвращаемся к другому вопросу: как, всё-таки, настроить
> > > OOM-killer так, чтобы он не отправлял систему в бесконечный цикл и
> > > не требовал перезагрузки по питанию? Потому, что кроме старого
> > > 32-битного железа с 3 GB RAM, есть ещё большое количества старого
> > > 64-битного железа с 2 GB RAM, которое физически отомрёт в тех же
> > > школах наверняка позже 32-битного.  
> > 
> > В первую очередь следует включить zswap, лучше всего с методом
> > z3fold. Это где-то в 1.5 раза эффективный объём памяти увеличит, но
> > сделает хвост более медленным, но всё равно много лучше свопа.
> 
>   Но это всё-равно вероятностное решение будет: лопнет — не лопнет. 

Любое решение будет вероятностным, вопрос в величине этой самой
вероятности.

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

Ну вот я много лет работал на ноуте с 2GB (пока он не помер перед
этим НГ), правда 32 бит. Там вот, 2 GB RAM + zswap хватает для
нормальной работы с любым сайтом, будь то chromium или firefox. Но
да, сразу два очень тяжёлых сайта может не вытянуть (больше в CPU,
чем в RAM упиралось). На 64 битах потребление памяти будет больше,
конечно, но я думаю, что не более 20-30%, так что не критично.

>   Идеального поведения в отношении браузера я добивался отключением
> overcommit_memory. В случае исчерпания памяти очередная вкладка
> показывала сообщение "Извините, вкладка упала", а всё остальное
> продолжало работать. Я так понял, что новый Firefox умеет не падать
> целиком.

И firefox, и chromium так умеют. Но чаще там вкладки из-за
каких-нибудь сегфолтов вылетают.

>   Это действительно было идеально, но на машинке, у которой было
> больше 2 ГБ, возможно даже 4 ГБ. Если памяти меньше, то с отключённым
> overcommit даже простой графический сеанс уже не запустить. А там, где
> сеанс и браузер запустить удаётся, часто нет возможности даже открыть
> новый эмулятор терминала. По-видимому, переоцениваются потребности
> очередного fork() или что-то в этом роде.
>   Поэтому отключение overcommit это тоже не выход. К сожалению.

А зачем отключать overcommit? Он как раз помогает, тем более, что
горячая память далеко не вся и всякий хлам уходит в swap.

Best regards,
Andrew Savchenko

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

Re: [devel] subrepository for 32-bit

[Anton Farygin]

On 31.01.2022 19:42, arbars wrote:

> И в этом как раз дистры, собранные для 32 бит - огромное подспорье.
>
> Но они состоят, в основном, из базовых элементов, ядро+базовая обвязка 
> и установщик. Которые, как минимум, будут иметь 32-битные версии
> вполть до того момента, пока имеется поддержка в ядре. Так что я 
> "голосую" за сохранение 32-битных пакетов для базовых компонентов - 
> ядра, системных
> утилит и консольных приложений как минимум.

Во всех этих 32-bit подспорьях основная проблема это браузер.

Если машина без интернета, то да, её вполне можно задействовать и 
использовать. Но, к сожалению, сайты вернуть в 90-е не получится.

Re: [devel] subrepository for 32-bit

[Ilya Kurdyukov]

On 30.01.2022 23:50, Vitaly Lipatov wrote:
> Основным толчком к этому стал отказ от поддержки 32-битных программ в 
> MacOS X и возникла необходимость в разработке механизма, позволяющего 
> обойти это ограничение.

Вообще-то они уже свой процессор сделали на архитектуре aarch64 и 
отказываются от x86, так что теперь в Wine будут делать?

Re: [devel] subrepository for 32-bit

[Alexey V. Vissarionov]

On 2022-02-08 21:43:41 +0300, Vitaly Lipatov wrote:

 >> https://wiki.winehq.org/ARM64
 > Возможно, Илья интересовался, как же на ARM будут запускать
 > старые 32-битные Windows-программы:
 > https://github.com/AndreRH/hangover

Очень говорящее название...

1) How it works
We have one Wine on the host in 64-bit only mode and two
on the guest side for 64-bit and 32-bit. Inbetween sits
a modified version of Qemu that runs the x86(_64) code.
To glue it all together there are thunks, lots of them
handwritten to understand in which situation a pointer
is valid and in which situation it could point to a
random address and should be ignored, and how to handle
writes to resulting structures in case of errors etc.


З.Ы. (Замечу Ышо): "hangover" обычно переводят как "похмелье",
но более точным является слово "бодун" или даже "бодунище" :-)

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