Блоатварь - неизбежное будущее линуксового народа. Таков путь.

Судя по трендам в оформлении UI

Вы опять смотрели в галерею лора?

какую-нибудь Haiku, а то и вовсе kolibriOS

SerenityOS же есть!

Т.е. есть рабочие библиотеки.

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

В японском и китайском тоже так, наверняка и другие языки найдутся.

В корейском довольно сложная письменность из комбинированных знаков.

Я хоть и не волоку в этом, но если для отображения твоего окна юзается сустемд, то если не подгрузить либу с сустемд, то отображения не будет, правильно? Значит весь этот зоопарктнужон твоей проге. Если аналлизировать проводник, то он юзает пару конских либ, где весь winapi и тд. В оффтопе же все монолитом, а в лялихе закос под posix. Кмк.

Как от этого избавиться?

1. Погромистов нужно сажать на 486 (ладна, я сёдня добрый, так что DX) и драть в одно известное место с наждачкой, до тех пор пока их код не будет вменяемо там работать.

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

Здесь происходит разрастания «depend hell», в зависимых библиотеках, как я думаю, фундаментально, связан с такой идеей, что программисты ушли в своей работе от принципа - «Не стоит порождать очередную сущностъ без необходимости», перенеся в разработку кучу шаблонов, сред написания кода и тд. Если с программированием дело обстояло, как с естественными языками, когда алфавит существует тысячи лет, как и примитивные морфемы, и чтобы выразить новое понятие, не требуется изобретать новые символы и обозначения, в базовой части, то такой проблемы банально не существовало.

Почему мне не должно быть пофиг? Я же не с окаменелой пеки образца 2005 года сижу. Объём диска - хоть попой жуй, я его даже на 50% редко могу заполнить, даже со снапшотами.

Если аналлизировать проводник, то он юзает пару конских либ, где весь winapi и тд.

Проводник загружает библиотеки через COM по мере надобности.

WinAPI – корявый, убогий, не умеет нормально в шрифты, Unicode, HiDPI.

Как раз умеет. В отличие от …

И если ты под winapi имеешь ввиду почему-то common controls и GDI32, то щас их на винде для GUI использует только легаси. Современные UI фреймворки там рендерят через DirectX

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

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

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

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

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

А как насчет меню открытия файлов ? Тоже будешь писать его вручную ? Иконки файлов согласно mime-type тоже будешь сам рисовать, пропарсивая текущую тему иконок (а пофайлово это ой как нелегко, знаю о чем говорю) ? А монтировать неподмонтированные разделы и подключать gvfs или что там нынче - тоже ручками ?

Если да, то после того как ты закончишь программировать блокнот, выглядящий в твоей системе не всрато - у тебя рядом с ним будет красоваться копия lib(gtk/qt).so, только твоя собственная и глючная.

Объём диска - хоть попой жуй, я его даже на 50% редко могу заполнить

Ага, а потом попытка затолкать это все при запуске в рам даже в сильно сжатом squashfs виде приводит к все большей и большей неработоспособности при данном объёме памяти … или еще смешнее, файл с образом перестаёт влезать в ограничения iso9660/vfat (4gb).

Ну и самое злое сжатие при распаковке проц кушать любит. Так-то из чистого рамдиска все летает, но у меня нету 20+ гигов рамы, особенно на ноуте.

1. Погромистов нужно сажать на 486 (ладна, я сёдня добрый, так что DX)

на всех живых четвёрок не найдешь.. НО всегда можно запустить bochs / qemu в Термуксе на арм- планшете. Оно конечно слегка побыстрее четверки, зато плавучка софтовая и быстрого 3д нема :)

зы: https://github.com/heroineworshiper/guicast

но юникода там кажется не было, но м.б. можно выдрать из истории cin-cv

НО всегда можно запустить bochs / qemu в Термуксе на арм- планшете. Оно конечно слегка побыстрее четверки, зато плавучка софтовая и быстрого 3д нема :)

Для этого существует 86Box с аккуратной эмуляцией скорости работы и ISA процессоров в диапазоне от 8088 до Pentium II.

Неть, только 486. Пусть погромисты следят не только за производительностью своей программы, а еще и за температурой окружающей среды )))

У 486 пиковое тепловыделение 7.5 ватт.

Окружающей среде пофиг.

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

Позанудствую.

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

На нагрев самого устройства эта характеристика не влияет абсолютно.

У атома 3735 TDP вообще 2.2 Вт, но в отличие от четверки, он не просто очень горячий, а звиздец какой горячий вплоть до ожога, просто потому что у него температурный режим выше.

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

Ты меня неправильно понял, я как раз и говорю что WinAPI развивается и умеет многие современные фичи, тогда как иксовые библиотеки подохли ещё в 90-ых.

Вот, например, демонстрация уровня обратной совместимости WinAPI, которая недостижима для любого иксового копролита:

https://baat.exlmoto.ru/~exl_lab/screens/old_winapi_apps_on_hidpi.png

Софт под винду написанный чуть ли не до выхода самой первой версии X11, запускается на современом HiDPI мониторе и имеет отличную поддержку современных фич: векторные шрифты c Grayscale-сглаживанием, корректная трансформация всех координат и… никакого мыла.

Тебя удивляет, что в gtk есть виджеты для проигрывания музыки и видосиков, которые тянут за собой всё это?

Но так то да, пухнет) используй другие тулкиты или собирай сам gtk.

$ ldd /usr/lib/libgtk-4.so | wc -l
67

$ ldd /usr/lib/libgtk-x11-2.0.so | wc -l
53

Напомнило мне что софт на motif тоже имеет поддержку xft-шрифтов, если написан не через жопу. А motif на секундочку появился в конце 80-х, 1989 вроде.

корректная трансформация всех координат

Вот это не понял что такое.

запускается на современом HiDPI мониторе

Запустится он тоже запустится.

софт на motif

Софт на Motif умер давным давно, а софта на WinAPI тонны.

Вот это не понял что такое.

Корректная трансформация UI-координат (клики мышкой, GDI) на HiDPI дисплеях вместо мыльцового растягивания.

Запустится он тоже запустится.

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

Работать в таких окружениях та ещё боль, именно поэтому Motif умер ещё в нулевых. Его убили Qt и GTK+, которые в отличие от него развиваются.

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

И почему мне не должно быть пофиг, если каждые несколько лет я меняю одно железо на другое с x2 приростом оперативки? Тем более какие-то сквошэфэсы ты тут выдумал… Кому и зачем оно нужно кроме установщиков и шизов бубунты с их snap-ом?

или еще смешнее, файл с образом перестаёт влезать в ограничения iso9660/vfat (4gb).

«И почему мне не должно быть пофиг» было удвоено. Он пишется на флэшку. У меня там 64/256Гб обычно. Если это как-то будет мешать загрузке, сделаЮТ (Или сделаЮ) раздел для EFI + нормальную (Не vfat) ФС и продолжу работу.

Ну и самое злое сжатие при распаковке проц кушать любит. Так-то из чистого рамдиска все летает, но у меня нету 20+ гигов рамы, особенно на ноуте.

Да ладно! У тебя там селерон что ли или окаменелось образца 2005 года? Я прозрачное сжатие использую (Вся ФС жмётся в момент чтения/записи) и никаких проблем не испытываю, а ты мне тут рассказываешь что «ой не могу терпеть, оно проц кушает что бы загрузиться». Приятного аппетита ему (сжатию) короч, пусть кушает и не обляпается (:

Ещё риахт к этому припурутить и будет збс (Серьёзно, не сарказм).

Motif was created by the Open Software Foundation (OSF) to be a standard graphical user interface for Unix platforms

Цитата из википедии. Вот почему я его сравниваю собственно, это штука была разработана как типа как стандартное апи для графики, наподобие WINApi, но для юниксов

Софт на Motif умер давным давно

Там немного сложно. Вот я прямо сейчас из CDE это всё пишу. Довелось потыкать CDE и до добавления поддержки юникода и до добавления поддержки 64 бит. Развитие есть, скажем так. Довелось и браузер на motif потыкать, Mosaic-CK, причем оно даже некоторый сайты может сейчас открывать сейчас, я даже скрин в галерее с этим браузером постил.

Работать в таких окружениях та ещё боль

Нормально тут работается.

которые в отличие от него развиваются

Они API постоянно ломают, это не развитие, а боль в заднице. Я не могу что-то из GTK2 или QT3 собрать на последних версиях, а с программами на Motif такой проблем нет.

типа как стандартное апи для графики, наподобие WINApi, но для юниксов

И не взлетело в отличие от.

с программами на Motif такой проблем нет.

Всё так, сегодня нет программ на Motif и нет таких проблем.

Развитие есть, скажем так.

Ага. Уровня /necro

И почему мне не должно быть пофиг, если каждые несколько лет я меняю одно железо на другое с x2 приростом оперативки?

Ты как героинщик, которому пофиг абстяга, ведь у него есть еще доза, а значит все норм, не вредит

Да ладно! У тебя там селерон что ли или окаменелось образца 2005 года?

А что, селероны, атомы, атлоны, и в конце концов АРМы \ МИПСы \ РИСКи которые никак не убьют штеуд потому что вынуждены тормозить на велосипедах с квадратными колесами, подпертыми костылями - уже не процы ?

Уровня /necro

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

сегодня нет программ на Motif

Есть. Я даже находил графическое меню выключения написанное на motif. То есть кто-то взял и заморочился, если что такой штуки в CDE по дефолту нет. Нашел даже клон пэйнта(classic-colors) и собрал его. То есть реально API не поломали. Eсть и просмотрщик pdf написанный на motif, я вроде даже видел порт xterm на motif.

Они API постоянно ломают, это не развитие, а боль в заднице.

Боль в заднице, потому у них этого API нет, а вместо этого сраный биндинг \ линковка.

Будто под линем они есть.

Поздравляю с выходом из бункера

https://www.gog.com/en/games?systems=linux

Жалкое подобие правой руки.

Боль в заднице, потому у них этого API нет, а вместо этого сраный биндинг \ линковка.

Сам понял чо сказал?)

Это много? Тут всё по делу и делится между процессами в shared memory. Любая популярная проприетарщина грузит в 100 раз больше.

Сам понял чо сказал?)

Да.

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

В свою очередь в случае с Шindows, такого не происходит (хотя и может) - функции там выполняются системным вызовом, а не include.

Именно поэтому хеллоуворлд в окошке на винде у тебя будет занимать 15 Кб (из примера делфи) и запустится в любой винде начиная с 3.11. А хеллоуворлд на гтк будет занимать пару мегабайт.

Лол. Абсолютно никакой разницы, точно так же там динамические библиотеки и тут.

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

И еще одно - собери хеллоу ворлд на gtk и посмотри, сколько он занимает.

Для справки.

https://github.com/sde-gui/rainbow-cm - менеджер буфера обмена. Размер исполняемого файла и зависимости:

vadim@aquila:~$ du -h --apparent-size /usr/bin/rainbow-cm
80K	/usr/bin/rainbow-cm
vadim@aquila:~$ LANG=C readelf -a /usr/bin/rainbow-cm | grep NEEDED | sort -u | grep -o '\[lib.*'
[libc.so.6]
[libgdk-x11-2.0.so.0]
[libgio-2.0.so.0]
[libglib-2.0.so.0]
[libgobject-2.0.so.0]
[libgtk-x11-2.0.so.0]
[libpango-1.0.so.0]
[libX11.so.6]
vadim@aquila:~$ 

https://github.com/sde-gui/spicview - просмотрщик изображений. Размер исполняемого файла и зависимости:

vadim@aquila:~$ du -h --apparent-size /usr/bin/spicview 
144K	/usr/bin/spicview
vadim@aquila:~$ LANG=C readelf -a /usr/bin/spicview | grep NEEDED | sort -u | grep -o '\[lib.*'
[libcairo.so.2]
[libc.so.6]
[libgdk_pixbuf-2.0.so.0]
[libgdk-x11-2.0.so.0]
[libgio-2.0.so.0]
[libglib-2.0.so.0]
[libgobject-2.0.so.0]
[libgtk-x11-2.0.so.0]
[libjpeg.so.8]
[libm.so.6]
[libpango-1.0.so.0]
[libsmfm-core.so.4]
[libsmfm-gtk2.so.4]
vadim@aquila:~$ 

Путь блоатваре - в контейнеры и виртуалки.

Так же как раньше было себе дороже запускать венду на bare-metal.

IMHO на bare-metal лучше пользоваться immutable штуковинами типа гипервизоров Talos и SmartOS.

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

Кек.

А что, селероны, атомы, атлоны, и в конце концов АРМы \ МИПСы \ РИСКи которые никак не убьют штеуд потому что вынуждены тормозить на велосипедах с квадратными колесами, подпертыми костылями - уже не процы ?

Они не вынуждены. Они и есть велосипед с квадратными колёсами. Всё как в физике: с круглыми - едет, с квадратными - тормозит.

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

Нативное ГУИ - это пиксели. Кстати про пиксели. Даже не знаю, зачем глупые людишки рисуют прямоугольники с помощью rectangle(x1,y1,x2,y2), а не скажем пикселями в четыре цикла :)

Вопрос: у меня стоит Арч, чистые иксы, gtk4 и qt6. В каком тулките откроет свой диалог моя система?

Браузер кстати - это единственный способ заставить программы выполняться нативно без переделки и бесконечных ifdef'ов, потому что HTML - это пожалуй единственная технология которая стабильна вот уже 30 лет, и даже те элементы которые помечены как deprecated - не выбрасываются, а всего лишь не рекомендуются, именно поэтому сайты написанные в 1994 году - до сих пор отображаются as is.

У меня есть система видеонаблюдения. Самописная, на основе motion. ГУЙ к ней я предпочел сделать на веб, знаешь почему? Да потому что видеонаблюдать за своим домом я могу при помощи тега <img src=> хоть на MacBook M2, хоть на Motorola MPX200 (2003 г.р.). Это тебе как пример переносимости софта.

А для панели управления не предпочёл.

А для панели управления не предпочёл.

Да, потому что панель управления - часть ДЕ. А если бы я писал прикладной софт который сам по себе тяжеловесен - я бы писал его на электроне.

Какого «ДЕ»?

У тебя в планах целое DE написать?

А если бы я писал прикладной софт который сам по себе тяжеловесен - я бы писал его на электроне.

CAD?

Симулятор электрических цепей?

Программу 3D-скульптинга?

Систему видеомонтажа?

Или «тяжеловесный софт» - это Скайп?

Предлагаю форсить новое выражение на ЛОРе.

На 486, быдло!!

Других он хочет на 486 посадить, а сам - на электроне писать. Непоследовательно как-то.

У тебя в планах целое DE написать?

В идеале - да.

Да. Видеоредакторы, КАДы, звуковые редакторы и тд. Короче любой емкий софт, ядро которого будет тяжелее электрона.

Текстовый редактор на нем я бы писать не стал.