Клуб в спячке Опции Поделиться

[speccyfighter]

От той переписки остались твои ответы из рассылки на почту. Ну полистал, почитал, освежил память...
Ну как сказать... После осенних тестирований очень даже актуально.
Так что все правильно.
"Чтобы на старые грабли не наступать" (С)

"Стрижка только начата" ©:

Тут Антон баг в сизифе на sysv выловил:
https://bugzilla.altlinux.org/show_bug.cgi?id=39423

Пошатался по вэбу, посмотрел код и нашёл пятый сломаный симлинк:
https://bugzilla.altlinux.org/show_bug.cgi?id=39423#c1

При этом, тот дебил, который это натворил, усиленно ломает альтернативы и придумывает фееричные отмазки:
https://github.com/systemd/systemd/commit/6...omment-42656968

И более рукожопого быдлокодера чем он, на Линукс ещё не было.
А эта хрень, ломает в альтах все стартеркиты на sysv.

И посмотрел между делом:
В Слаке и devuan, не systemd-udev, а eudev. А значит им это не грозит.
Вот такая вот фигня присходит сейчас в Линукс.
И если вся эта феерия в Линукс будет заканчиваться дьявольским шабашом, не исключаю что пойду на винду.
Да, читал в альтовой декабрьской рассылке devel, очередной срач про баш-портянки от сисадминов не способных осилить баш-скрипты, выказывая этим, свою профнепригодность.
Такие дела...

[Koi.v2]

Виндовс скучный

[speccyfighter]

Виндовс скучный

Зато в Линукс у меня жизнь на p9 стала черезчур весёлой:
- Не слишком часто, но довольно часто, на p9, на выходе из suspend, у меня рандомно графику в X-сах на BDW GT2 валит в чёрный экран. "Мягкий" выход, только по Alt+SysRq+k. Нахер улетает всё. Включая терминал со всеми выбросами. Это шо блин, это на Линукс такой стиль разработки?! Да нахер бы он впёрся такой хороший. Вот и сейчас всё нахер поулетало, включая терминал со всеми выбросами. Во времена ядра 4.1.21 на Lenovo G50 вообще ничего подобного не было! Вообще! В линукс подобные вещи принято дипломатично называть регрессиями. А давайте все вещи называть своими именами, - это у какого-то линуксового программиста, пишущего код системного уровня под железо и весьма посредственно знающего его, руки растут из жопы.
В теории надо было бы багрепорт. А вешать-то на что и что приводить? В логах же ничего.

- У меня используется ut2004-linux. Именно линукс-версии. Под его не-демо версию (хотя есть и его линукс демо-версия с претензией на полноценную) специально был куплен серийник. И линукс версия используется принципиально. А не запусти в операционке, которая сидит поверх другой операционки и попутно выгреби по выбросам кучу говна и взрывов. Попутно собиралось куча модов, хаков, рецептов. Собиралось по крупицам. Каждое проверялось и/или отлаживалось руками. На всё это ушли месяцы и годы. Тот пакет в своём роде уникален на платформе линукс. Таких пакетов в линукс можно пересчитать по пальцам одной руки. А ункален он тем, что он под две архитектуры сразу. Безкостыльно. И работало это всё, до сраных современных линуксовых инновацй, без единой проблемы 12 лет подряд. Но теперь, в том коде который в p9, персонаж от первого лица периодически фризит, - нужно отпускать клавишу вперёд и нажимать снова. Доинновировались... Годы труда улетели коту под хвост.

- Под ut2004-linux нужна libstdc++.so.5. Эта библиотека из gcc3.3. Во всех линукс основных веток, пакет с этой библиотекой лежит в репозитории, - и в арче, и в слаке, и в диване. Просил в альтах собрать пакет. И только в альтах она wontfix. Устанавливай мол руками из p8. А в p10 тоже также нужно будет смешивать код двух репозиториев?

- Набросал mplayer-vc. Ну там для тех у кого железо X-сы не тянет. Или у кого-то они отвалились, чинить не хочется, а кино посмотреть хочется. Ну или для тех, у кого аллергия на X-сы. Это же вроде бы Unix, - место всем найдётся. И везде с мультиюзер в tty это будет работать. Но не в альтах. Вот попросите неальтовцев показать права на /dev/fb0. И в коде же обрабатывается доступ по группе. Просил в конфиге исправить монопольный захват и дать доступ по группе. Думаете исправили? Багрепорт уже год висит. Там чтобы поправить, работы на десять минут. Везде это работает, а под альты что? В пакете в постинсталл-скрипах, костыли вворачивать? Ну чтоб в tty мультиюзер нахрен не ломался. Нет, ну конечно можно пакет и под альты собрать. Но вот нахер он нужен с костылями? А без костылей, это пользователю мозг сломает.
И mplayer-vc делался же специально, чтобы консоль упостить, настолько насколько это возможно. А то развели срач про консоль для админов. Это в гуях, то покрути, сё покрути. Что там в mplayer-vc крутить? Там же всё автоматизировано настолько, насколько это возможно. Полный KISS. Куда уж проще? Только монопольный захват раскрути и всё. Но вот обязательно надо создать трудности, чтобы их героически преодолевать.

И что характерно, в начале жизни p8, на Lenovo G50 всё работало замечательно. Всё, это значит всё. У меня месяца два-три ушло на то, чтобы подобрать идеально Линукс-совместимое железо, перебрав тонны чужих логов. И тут поехало... Чтобы в Линукс жизнь мёдом не казалась. Про сломаный не так давно в ядре rtc уже молчу.

Говорите в Линукс жизнь веселее? Хрена себе веселье... А тут мудила поттер, ещё и симлинки в /dev поломал на init -ах.


Сообщение отредактировал speccyfighter - 12.12.2020, 17:32

[DdShurick]

А тут мудила поттер, ещё и симлинки в /dev поломал на init -ах.

Это он специально, потому что не "мудила рукожопый", а свою монополию защищает.
Переходи на репу Slackware, как я.

[Koi.v2]

Я много раз пытался переехать на что-то другое, но как-то не срастается.
Это как с DE не счесть сколько раз пытался слезть с kde, ну блин всегда возвращаюсь.
Уже давно смерился что нет линуксов где все работает как должно.

[speccyfighter]

Я много раз пытался переехать на что-то другое, но как-то не срастается.
Это как с DE не счесть сколько раз пытался слезть с kde, ну блин всегда возвращаюсь.
Уже давно смерился что нет линуксов где все работает как должно.

Тут речь уже не о привычках. А о том, сдохнет ли в p10 xfce-sysv или нет. Причём не только xfce-sysv, а вообще все sysv. А их в репозитории штук пять. Включая сервер на sysv.
Куда нахер писать, если оно сломано:

Код

# grep -ri 'stderr' /etc/ | grep to
/etc/libvirt/virtproxyd.conf:#      output goes to stderr
/etc/libvirt/virtlockd.conf:#      output goes to stderr
/etc/libvirt/libvirtd.conf:#      output goes to stderr
/etc/libvirt/virtlogd.conf:#      output goes to stderr
/etc/grub.d/05_altlinux_theme:    # Step #7: Everything went fine, print out a message to stderr ...
/etc/apf/apf.conf:# $debug: whether to emit messages to STDERR; 0 to disable (default)
/etc/vmware-tools/tools.conf:# and to stderr for more severe than 'message'.
/etc/vmware-tools/statechange.subr:#    Write a formatted error message to stderr and exit.
/etc/vmware-tools/statechange.subr:#    Stderr is spammed, program exits with exit code 1.
/etc/lvm/lvm.conf:    # Controls the messages sent to stdout or stderr.
/etc/lvm/lvm.conf:    # The fields included in debug output written to stderr.

Код

# grep -ri 'stdout' /etc/ | grep to
/etc/grub.d/05_altlinux_theme:    # ... and write our configuration snippet to stdout. Use the colors
/etc/info-dir.old:* zcat: (gzip)Overview.                         Decompression to stdout.
/etc/net/scripts/contrib/selectprofile:# profile name on stdout. Applicable cases to use such a script are
/etc/vmware-tools/tools.conf:# std: Logs to stdout for level >= 'message',
/etc/lvm/lvm.conf:    # Controls the messages sent to stdout or stderr.
/etc/info-dir:* zcat: (gzip)Overview.                         Decompression to stdout.

Сообщение отредактировал speccyfighter - 12.12.2020, 23:49

[DdShurick]

busybox init как альтернатива. В Puppy более десяти лет, полёт нормальный.

[dango_]

Тут Антон баг в сизифе на sysv выловил:
https://bugzilla.altlinux.org/show_bug.cgi?id=39423

Пошатался по вэбу, посмотрел код и нашёл пятый сломаный симлинк:
https://bugzilla.altlinux.org/show_bug.cgi?id=39423#c1

При этом, тот дебил, который это натворил, усиленно ломает альтернативы и придумывает фееричные отмазки:
https://github.com/systemd/systemd/commit/6...omment-42656968

И более рукожопого быдлокодера чем он, на Линукс ещё не было.
А эта хрень, ломает в альтах все стартеркиты на sysv.

А разве что-то поменялось?

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

Хм, эта? Начиная с:
https://lists.altlinux.org/pipermail/devel/...ber/212953.html
и далее по теме

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

У меня вашего терпения не было. Да и сейчас снова нет. Убитая на ровном месте таблица разделов поставила точку.

[speccyfighter]

А разве что-то поменялось?

Хм, эта? Начиная с:
https://lists.altlinux.org/pipermail/devel/...ber/212953.html
и далее по теме

Оно, Дан.
Особенно возмутило это:
https://lists.altlinux.org/pipermail/devel/...ber/212972.html
https://lists.altlinux.org/pipermail/devel/...ber/212978.html

Так и хочется настучать на клавиатуре:
- Слышь, ненекрофил, ты бы рот свой закрыл.

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

А этому фанатику systemd:
https://lists.altlinux.org/pipermail/devel/...ber/213006.html
- Текст сначала научись форматировать, дебил фанат "инноваций". Твою писанину читать невозможно.
- "Может, проще init-скрипты вынести в отдельный пакет, которым будет рулить группа любителей sysvinit?", - сам понял что сказал?

[speccyfighter]

ИМХО:
Альтовая система с xfce на sysvinit, на дистовотч вышла далеко за пределы необъятной и набрала в рейтинге 10 из 10-ти. И захотеть испортить репутацию своего же проекта, может захотеть только ненормальный. Но вместо того чтобы искать и придти к компромиссному решению, устроить грандиозный срач в рассылке devel, это конечно нечто. Учитывая что сторонников sysv, больше чем озвученные в рассылке.


Сообщение отредактировал speccyfighter - 14.12.2020, 18:02

[speccyfighter]

Там в том треде devel говорят, что симлинки var в sysv работают. Хрен там. Они работают на уровне профайла, - если не симлинки, грохнуть и создать симлинки:

Код

# cmp ./mkimage-profile/live/image-scripts.d/50-var-run-fix \
> mkimage-profile/rootfs/image-scripts.d/50-var-run-fix
#

Код

# cat ./mkimage-profile/rootfs/image-scripts.d/50-var-run-fix
#!/bin/sh

# this was a bunch of dirty complaints
sed -i 's,/var/run,/run,' /{etc,lib}/tmpfiles.d/*.conf ||:

[ ! -L /var/run ] && rm -r /var/run && ln -s ../run /var/run
[ ! -L /var/lock ] && rm -r /var/lock && ln -s ../run/lock /var/lock

:

Инсталляционные sysv разломаны, а миграция p8=>p9 гарантированно разломана. И при переезде с p8-sysv-xfce на p9-xfce-sysv, раздастся грандиозный грохот.


Сообщение отредактировал speccyfighter - 15.12.2020, 11:54

[YYY]

https://lists.altlinux.org/pipermail/devel/...ber/212972.html
https://lists.altlinux.org/pipermail/devel/...ber/212978.html

обычное поведение системг-фанбоев...

[speccyfighter]

Про багрепорт, который регрессия в p9
Ошибка 38777 - xorg устанавливает малый неверный размер матрицы
https://bugzilla.altlinux.org/show_bug.cgi?id=38777
Исполнитель: Valery Inozemtsev

я вообще молчу. Пока в системе грохота нет ну и хрен с ним. Но сам баг никуда не делся.
Мнение некрофила:
И вообще этот баг ламерский. Почему ламерский? Потому что только ламер, детально не ознакомившись со спецификацией, мог взять байты Basic Display Parameters и использовать их как размер активной области матрицы LCD в миллиметрах. Уже детально развернул суть секций спецификации с побайтной привязкой к EDID, - как делать неправильно, а как правильно. И что в байтах и полубайтах представляет из себя размер матрицы. Багрепорту четыре месяца. Со стороны ненекрофилов движухи никакой. И вообще, в частности, для LP156WHB-TPC1, дефолтные 96dpi, это глупость.

[speccyfighter]

Что это всё было?
Процесс разработки xfce-sysv.

Сообщение отредактировал speccyfighter - 15.12.2020, 12:44

[speccyfighter]

Что это всё было?
Процесс разработки xfce-sysv.

Иногда подопрёшь голову руками, смотришь на всё это тупо в экран и думаешь:
Пипец какой...

[speccyfighter]

Про багрепорт, который регрессия в p9
Ошибка 38777 - xorg устанавливает малый неверный размер матрицы
https://bugzilla.altlinux.org/show_bug.cgi?id=38777
Исполнитель: Valery Inozemtsev

я вообще молчу. Пока в системе грохота нет ну и хрен с ним. Но сам баг никуда не делся.
Мнение некрофила:
И вообще этот баг ламерский. Почему ламерский? Потому что только ламер, детально не ознакомившись со спецификацией, мог взять байты Basic Display Parameters и использовать их как размер активной области матрицы LCD в миллиметрах. Уже детально развернул суть секций спецификации с побайтной привязкой к EDID, - как делать неправильно, а как правильно. И что в байтах и полубайтах представляет из себя размер матрицы. Багрепорту четыре месяца. Со стороны ненекрофилов движухи никакой. И вообще, в частности, для LP156WHB-TPC1, дефолтные 96dpi, это глупость.

Нутыж 1R4 показываешь!
А вот хер этот номер пролезет:
https://glenwing.github.io/docs/VESA-EEDID-A1.pdf

Потому шо спецификация VESA EEDID 1R3, таблицей 3.1 для туполобых говорит, что байты 15h 16h это сантиметры.

Давайте абстрагируемся от X-сервера и вообще от линукса:
Если бы в своей школе в пятом классе на уроке математики я бы попытался размер округлённый до ближайшего сантимера перевести в миллиметры для указания его точного реального размера в миллиметрах, мне бы учительница влепила в дневник единицу и выгнала бы из класса за родителями. А в коде линукс этот номер пролазит. Вы шо, блин, в школе не учились?

Спецификация 1R3, как и 1R4, вам бестолковым ясно говорит, что только байты 12 13 14 первого дескриптора содержат точный размер матрицы в миллиметрах в формате полубайт-байт. Байт 12 первого дескриптора, в общем массиве edid, находится по смещению 66 (dec; первый байт edid - смещение ноль). Байт 14, это два полубайта для координат X и Y. Вы шо программисты, спецификации вообще не читаете? Как же вы тогда код и патчи пишете? Это шо, я пользователь должен вам специалистам это объяснять? Вы шо блин, охренели?

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


Кстати:
В сизифе у edid-decode, сменился формат вывода. Теперь дамп edid представлен одним hex-массивом без побайтной детализации дампа по секциям, как это было в версии edid-decode, которая в p9. Посему, чтобы дамп edid детально разложить на секции, нужно в спецификации (см. pdf) VESA EEDID смотреть таблицу в разделе 3.1 EDID Format Overview.

И ещё, моё ИМХО некрофила:
Для декодирования edid, рекомендую использовать edid-decode.
И настоятельно, крайне не рекомендую использовать parse-edid из пакета read-edid.
Потому как он несёт полный бред:
(см. выше взрыв возмущения безграмотного использования байтов 15h 16h edid для вывода размера дисплея LCD в миллиметрах и описание этих байтов в спецификации)

Код

# parse-edid < /sys/devices/pci0000:00/0000:00:02.0/drm/card0/card0-eDP-1/edid
Checksum Correct

Section "Monitor"
    Identifier ""
    ModelName ""
    VendorName "LGD"
    # Monitor Manufactured week 0 of 2014
    # EDID version 1.4
    # Digital Display
    DisplaySize 340 190
    Gamma 2.20
    Option "DPMS" "true"
    Modeline     "Mode 0" -hsync -vsync
EndSection

Потому как размер в миллиметрах, это

Код

# echo -e '1366*0.252\n768*0.252' | bc -l
344.232
193.536

И edid-decode, из основных параметров и Modeline, отображает верно:

Код

# edid-decode < /sys/devices/pci0000:00/0000:00:02.0/drm/card0/card0-eDP-1/edid \
> | grep -A1 'DisplayPort interface\|Detailed Timing Descriptors'
    DisplayPort interface
    Maximum image size: 34 cm x 19 cm
--
  Detailed Timing Descriptors:
    DTD 1:  1366x768    60.005 Hz 683:384  47.404 kHz  76.320 MHz (344 mm x 194 mm)

По этому последнему выбросу, явно видно, что кодер писавший edid-decode, внимательно ознакомился со спецификацией. Ошибок нет. Вывод верный.
А программист parse-edid, двоечник, прогулявший все уроки математики.
Я бы этот read-edid, вообще удалил бы из репозитория нахер. Чтобы не держать этот бред.


Сообщение отредактировал speccyfighter - 16.12.2020, 11:00

[speccyfighter]

Взять что ли повесить багрепорт на read-edid?
В смысле на его безграмотное враньё в выводе DisplaySize, со ссылкой на описание байтов 15h 16h в спецификациях VESA EEDID 1R3/1R4.

Дополнив ссылками на спецификации.
Вот как-то так:


Ошибка:
В parse-edid неверный размер дисплея

Пакет:
read-edid

Исполнитель:
Vladislav Zavjalov

Комментарий:
Сабж:
В DisplaySize, parse-edid выводит неверный размер дисплея, указывая его в миллиметрах:

# parse-edid < /sys/devices/pci0000:00/0000:00:02.0/drm/card0/card0-eDP-1/edid | grep DisplaySize

DisplaySize 340 190

В то время как реальный размер в миллиметрах:

# echo -e '1366*0.252\n768*0.252' | bc -l
344.232
193.536

который содержат байты 12 13 14 (два полубайта) первого дескриптора (см. Table 3.21 в спецификации 1R4).


Спецификации:
VESA EEDID Version 1, Revision 4:
https://glenwing.github.io/docs/VESA-EEDID-A2.pdf
VESA EEDID Version 1, Revision 3
https://glenwing.github.io/docs/VESA-EEDID-A1.pdf


Пояснения:

VESA EEDID Version 1, Revision 4 (Описание байтов 15h 16h):
https://glenwing.github.io/docs/VESA-EEDID-A2.pdf

Таблица структуры EDID:
Table 3.1 - EDID Structure Version 1, Revision 4
Page 19 of 91

Раздел детального описания байтов 15h 16h:
3.6.2 Horizontal and Vertical Screen Size or Aspect Ratio: 2 Bytes
Page 25 of 91

Цитата из описания байтов 15h 16h:
The horizontal and vertical screen size parameters provide information on the screen dimensions of the display device, rounded to the nearest centimeter (cm).

Байты 15h 16h содержат размер дисплея округлённый до ближайшего сантиметра. При декодировании edid, размер дисплея при использовании байтов 15h 16h, должен указываться только в сантиметрах. Переводить содержимое этих байтов из сантиметров в миллиметры нельзя.

Эти же два байта, 15h 16h, кратко упоминаются примечанием в колонке Format, таблицы 3.1 EDID Format Overview, в спецификации 1R3.

edid-decode, декодирует edid верно. Правильно указывая размер дисплея и в Maximum image size, и в Detailed Timing Descriptors.


Ошибка пересекается с багом:
Ошибка 38777 - xorg устанавливает малый неверный размер матрицы
https://bugzilla.altlinux.org/show_bug.cgi?id=38777


Сообщение отредактировал speccyfighter - 16.12.2020, 12:58

[speccyfighter]

А-а.. Ну уже есть:
https://bugzilla.altlinux.org/show_bug.cgi?id=38841

Бегло перечитал.
Доставил тот комметарий, где сисадмин внедряет мейнтейнеру пакета, почему dpi должен быть точным и почему ломать его, не нужно и вредно:
https://bugzilla.altlinux.org/show_bug.cgi?id=38841#c12

Но не менее интересно почитать комментарий в котором мейнтейнер пакета начинает нести бред.

Особенно учитывая что в p8 это работало правильно. А в p9, следуя прогрессу, это благополучно сломали.

И вообще отказываюсь понимать, зачем правильно работавшее в p8

... в p8 через intel_drv ... для матрицы LP156WHB-TPC1 Lenovo G50-80, установить верно не только правильный размер активной зоны матрицы, но и правильный DPI, точное значение которого между 100 и 101, т.е. буквально идеально:

Код

$ sed -n '81p; 84,85p; 123,124p; 269,271p' /var/log/Xorg.0.log
[    32.851] (--) intel(0): Output eDP1 using initial mode 1366x768 on pipe 0
[    32.852] (**) intel(0): Display dimensions: (344, 194) mm
[    32.852] (**) intel(0): DPI set to (100, 100)
[    33.416] (II) intel(0): switch to mode 1366x768<>60.0 on eDP1 using pipe 0, position (0, 0), rotation normal, reflection none
[    33.430] (II) intel(0): Setting screen physical size to 344 x 194
[   200.923] (II) intel(0): switch to mode 1024x768<>60.0 on eDP1 using pipe 0, position (0, 0), rotation normal, reflection none
[   216.086] (II) intel(0): resizing framebuffer to 1366x768
[   216.087] (II) intel(0): switch to mode 1366x768<>60.0 on eDP1 using pipe 0, position (0, 0), rotation normal, reflection none

нужно было сломать в p9.

Кстати это же, про почему нельзя ломать реальный dpi, stranger573 объснял и на форуме. Бесполезно. Как об стенку горохом.


Сообщение отредактировал speccyfighter - 16.12.2020, 17:34

[dango_]

Что это всё было?
Процесс разработки xfce-sysv.

Как-то так: https://www.youtube.com/watch?v=8gtgU15URmo
Х-)

Сообщение отредактировал dango_ - 21.12.2020, 11:13

[dango_]

Релиз пользовательского окружения Xfce 4.16

[speccyfighter]

Релиз пользовательского окружения Xfce 4.16

Всё о чём сказала эта новость, своими комментариями, так это то, что сегодня в линукс, 99% дебилов, припёршихся в линукс за халявой и красивыми постоянно новыми картинками на экране. И только 1% комментаторов, увидел, что по сравнению с версией 4.14, когда-то лёгкий xfce, распух на 50%. И в средней конфигурации 64 бит, на холодном старте, стал съдать треть гигабайта.

[DdShurick]

сегодня в линукс, 99% дебилов

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

когда-то лёгкий xfce, распух на 50%. И в средней конфигурации 64 бит, на холодном старте, стал съдать треть гигабайта.

Лично я попробовал, поддавшись на хвалебные речи, и вернулся на JWM.

[dango_]

Всё о чём сказала эта новость, своими комментариями, так это то, что сегодня в линукс, 99% дебилов, припёршихся в линукс за халявой и красивыми постоянно новыми картинками на экране. И только 1% комментаторов, увидел, что по сравнению с версией 4.14, когда-то лёгкий xfce, распух на 50%. И в средней конфигурации 64 бит, на холодном старте, стал съдать треть гигабайта.

Уровень комментаторов на Opennet (и не только) давно уже лежит ниже плинтуса. Обратная сторона популяризации Linux.
Только это рак с обширными метастазами. Неизлечимо.

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

Ключевое слово "халява". Насколько ты не платишь, настолько ты и получаешь.
Увы, обратку получают все.

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

Вечный бой с ветряными мельницами.

Лично я попробовал, поддавшись на хвалебные речи, и вернулся на JWM.

Я так и не дернулся с винды. Скажем так, по совокупности факторов.
Наименьшее число проблем было в Debian и Devuan.

[Koi.v2]

Уровень комментаторов на Opennet (и не только) давно уже лежит ниже плинтуса.

Там всегда так было и лор в эту же кучу.

[speccyfighter]

Я так и не дернулся с винды. Скажем так, по совокупности факторов.

Дан, хочечь моё мнение? И не дёргайся с винды.
Я тут в нашей теме Xfce с SysV конечно возможно и погорячился, но у всякого терпения тоже есть предел:
https://forum.altlinux.org/index.php?topic=...54895#msg354895

Читать отсюда и по Ответ #1428:
https://forum.altlinux.org/index.php?topic=...54801#msg354801

А хотел как лучше, чтобы в xfce-sysv была альтернатива виндовой Victoria. Без копипастов скриншотов из винды. А получилось как всегда. Мне что терерь, ходить по двум десяткам апстримных проектов и развешивать баги на код и man -ы? А нафига мне это надо?

Наименьшее число проблем было в Debian и Devuan.

Так и есть:
Вместо того чтобы править код и маны в двух-трёх десятках пакетов и стучать в каждые двери апстрима, они просто собрали с --enable-compat-symlinks и забыли про проблему:

В debian -овском свежем dosfstools 4.1-2, {fsck,mkfs}.vfat есть:
https://packages.debian.org/bullseye/dosfstools
https://packages.debian.org/bullseye/amd64/...stools/filelist

И в p8/branch они были.

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

Код

$ rpm -qpl ./kernel-image-un-def-5.10.1-alt1.x86_64.rpm | grep vfat
/lib/modules/5.10.1-un-def-alt1/kernel/fs/fat/vfat.ko

Про то что в линукс на стандарты вывода с некоторых пор что-то там поклали и parted с fdisk -om своим умолчанием выводят по-разному, один в мегабайтах, другой в мебибайтах, и в стандартах на вывод бардак, вообще молчу.

И бороться со всем этим в линукс, всё равно что ссать против ветра.


Сообщение отредактировал speccyfighter - 1.1.2021, 12:13

[dango_]

Всех с Новым Годом!

[dango_]

Я тут в нашей теме Xfce с SysV конечно возможно и погорячился, но у всякого терпения тоже есть предел:
https://forum.altlinux.org/index.php?topic=...54895#msg354895

Читать отсюда и по Ответ #1428:
https://forum.altlinux.org/index.php?topic=...54801#msg354801

Читал. Даже перечитывал, чтобы разобраться.
Ну, Юрий, ты все сказал. Что еще добавить?

Адаптированный анекдот:
- Мама, мама, там папа со стула упал, когда делал ревью кода на гитхабе!
- Он что-то сказал?
- А мат выбросить?
- Да.
- Он молча упал.

А хотел как лучше, чтобы в xfce-sysv была альтернатива виндовой Victoria. Без копипастов скриншотов из винды. А получилось как всегда. Мне что терерь, ходить по двум десяткам апстримных проектов и развешивать баги на код и man -ы? А нафига мне это надо?

На поверку никому уже ничего не надо.

Про то что в линукс на стандарты вывода с некоторых пор что-то там поклали и parted с fdisk -om своим умолчанием выводят по-разному, один в мегабайтах, другой в мебибайтах, и в стандартах на вывод бардак, вообще молчу.

И бороться со всем этим в линукс, всё равно что ссать против ветра.

Угу.

Дан, хочечь моё мнение? И не дёргайся с винды.

Да и так не дергаюсь. Там то, что нужно работает. Правда, и тамошних траблов хватает.
А если уж и встает поперек души, лайвы, виртуалки и новости быстро стали охолаживать порывы.
А на что-то вдумчивое времени не хватает. Да и желание сильно поубавилось.

[dango_]

Не то чтобы...
Выпуск дистрибутива Slackel 7.4
Глянуть что ли...

[YYY]

С Новым годом!

Код

.     .    O  .         O
  o       .       .   .    .               .     O
   .  o _.,--------.   O       O    .       o
     ,'"            `.    .            O        .
O  /                 \     o    .
   f .                 Y
. |  \________________j  .        o     .      o
   |  f                Y   .                     .
  O|  l________________j          .         O
   | f|||||l ,--   --.||  O  o      ,----------------.
. | |jjj|l`  ,-.  ,-.|l           f         C        Y
   j_j,-```  f  | f  ||-.   .      |       Новым      |
  f   Y (|   l_0, l_0,| j          l     2021 годом!  j
  l   jY |       `.   |f   O     .  `-._    ______.,-'
   `-' `-|,        )  l'            o   )  /    .
  o    ||f ,-  `--'  _ Y      o      _,' ,'
   O   jjj  `.       ,`| `-..___..,-'_.,'    O     o
     . '''\   `-----'  j      `""""''
.      O  |.        ,'     o                  .
    o  .   | `-._.,-'   O         .    o         o
      ____ |      l ____   .   O
  o ,'-+-->l   -'  Y<--+`.   o
   /+--+,' \`-.__,'| `.+--\      .    .    o
  /-+--+`-, \.____,j ,'+--+\  .                   O
f--+--+-<   \    /  >-+--+-Y   o       O      .
j--+--+--`.  `. / ,'--+--+-l     O      o
f+--+--+--+-`.  Y /-+--+--+--Y  .             o
|+--+--+--+--+\ |f--+--+--+--|           .         .
|+--+-f+--+--+-\|j--+--+Y-+--|  o           o
|+--+-|+--+--+--|+--+--+|-+--|                    o
|+--+-|+--+--+--|+--+--+|-+--|

Сообщение отредактировал YYY - 3.1.2021, 19:29

[speccyfighter]

Читал. Даже перечитывал, чтобы разобраться.
Ну, Юрий, ты все сказал. Что еще добавить?

Адаптированный анекдот:
- Мама, мама, там папа со стула упал, когда делал ревью кода на гитхабе!
- Он что-то сказал?
- А мат выбросить?
- Да.
- Он молча упал.

Думали закрыли #39491 с notabug и успокоились?
Щас я вам устрою спокойную жизнь:
https://bugzilla.altlinux.org/show_bug.cgi?id=39503
Щоб жизнь мёдом не казалась. А вы там уже разбирайтесь между собой, кто эту всю фигню будет исправлять.
Думаете если пошлёте в апстрим, сразу побегу? Щас. Роняя тапки на ходу.
Мне надо было, пару раз сходил. Но это надо было лично мне. А тут выразребайте сами, - "сам испёк, сам и ешь".
Причём #39491 не просто не перенаправлен на пакеты по которым это ударило, а закрыт с notabug.
Будете потихоньку разламывать мне систему на sysv и спокойно при этом почивать? Не парни, так не пойдёт.

Сообщение отредактировал speccyfighter - 4.1.2021, 18:03