Сформирован (https://blog.gtk.org/2017/10/23/gtk-3-92/) очередной тестовый выпуск будущего стабильного релиза GTK+ 4. Ветка GTK+ 4 развивается в рамках нового процесса разработки, который пытается предоставить разработчикам приложений стабильный и поддерживаемый в течение нескольких лет API, который можно использовать не опасаясь, что каждые полгода придётся переделывать приложение из-за изменения API в очередной ветке GTK+. До полной стабилизации GTK+ 4, приложения, предлагаемые для пользователей, рекомендуется продолжить собирать с использованием ветки GTK+ 3.22, которая будет поддерживаться три года.Основные изменения (ftp://ftp.gnome.org/pub/gnome/sources/gtk+/3.92/gtk+-3.92.1....) в GTK+ 3.92.1:
- Прекращение поддержки сборочной системы на базе autotools в пользу инструментария Meson (https://www.opennet.me/opennews/art.shtml?num=47031);
- Поддержка управления шрифтами через CSS-свойство font-variant (https://developer.mozilla.org/en-US/docs/Web/CSS/font-variant);
- В GtkEntry добавлен виджет для выбора Emoji. Также добавлены хинты для ввода Emoji с клавиатуры;
- Все виджеты портированы на GtkSnapshot;
- GtkLabel и GtkEntry переведены на использование GSK (https://wiki.gnome.org/Projects/GTK+/Gsk) (GTK Scene Kit), обеспечивающего отрисовку графических сцен через OpenGL и Vulkan;
- Почти завершена работа над кодом отрисовки через графический API Vulkan. Из нереализованных возможностей осталась только отрисовка размытых теней. Изменена внутренняя логика отрисовки через Vulkan, вместо записи промежуточных результатов в виде поверхностей Сairo задействованы текстуры. Устранены все заглушки для отрисовки текста через Сairo. В GSK для бэкенда Vulkan задействована многофазная отрисовка, реализован кэш глифов для исключения повторной отрисовки глифов, поддержка размытия и возможность профилирования вывода. Добавлены API gsk_text_node_new, gsk_blur_node_new, gsk_cross_fade_node_new и gsk_blend_mode_new;- Внесены изменения в обработку ввода: в GdkEvent добавлены новые методы доступа к полям, традиционные сигналы событий ввода (например, ::key-press-event) теперь поступают от контроллера событий, в большинстве внутренних виджетов прекращено использование традиционных сигналов сбытий ввода, GDK_SEAT_CAPABILITY_ALL_POINTING теперь включает события сенсорного экрана;
- В GtkOverlay реализован режим размытия содержимого за дочерними элементами;
- Появилась возможность использования штатного диалога выбора файлов в старых выпусках OS X;
- В GtkPlacesSidebar добавлена поддержка libcloudproviders;- Для несвязанных с окнами виджетов теперь допустим размер 0x0;
- Добавлена поддержка изменения размера мозаично размещённых окон (tiled)- В интерфейсе инспектирования расширена информация об узлах отрисовки, добавлены сведения о параметрах gsk и vulkan;
- Удалены API: gdk_window_new_input, gtk_widget_set_redraw_on_alloc, gtk_widget_get_{border,content,margin}_allocation и gtk_container_propagate_draw.URL: https://blog.gtk.org/2017/10/23/gtk-3-92/
Новость: http://www.opennet.me/opennews/art.shtml?num=47436
Это они его переписывают или хотят 3-ю версию довести до кондиции и сделать ЛТС с именем 4?
Они хотят довести до LTS веток каждый мажорный релиз, причем с меньшими различиями между ветками, чтобы в пределах веток поддерживать совместимость. Так что нет, третья останется третьей.
> Это они его переписывают или хотят 3-ю версию довести до кондиции и
> сделать ЛТС с именем 4?Нет. Это отдельная, просто у них традиция приписывать версии выше примерно 3.90 до релиза 4.0. Раньше такое частенько случалось в опенсурсе. Как и нечетная нумерация для нестабильных релизов, о которых сейчас только разные олдфаги помнят, наверное.
Отдельная - в смысле переделывают? Меня внутренности интересуют, а в циферки каждый разработчик вкладывает своё понятие.Так тут будет что-то мажорное или просто продолжается полировка версии 3?
> Так тут будет что-то мажорноеТы новость читал?
Читал и что? Намекаешь, что там не описаны мажорные изменения и их не так много? Так и вавилон не за один день строился
С полгода назад тут новость пробегала о новой нумерации версий. Суть в том, что стабильной называется разработческая ветка (которая ломается каждый релиз), а устаревшей - стабильная (к которой только мелкие исправления вносятся). После выхода 4.0 будем иметь: стабильную 4 (с релизами 4.0, 4.1, 4.2, ...) и устаревшую 3 (с мелкими релизами 3.22.1, 3.23, 3.24, ...). Через два года 4.какаябудет объявляется устаревшей и выходит новая стабильная 5, цикл продолжается.
Давайте похлопаем этому анониму за талант в ЛПП и перекручивании фактов!
У тебя явно никогда не ломались темы\виджеты в GTK3. Давай похлопаем тебе, а?
Знаете товарищи, я пытался привыкнуть к гному, но мириться с его тормозами.... сил уже не осталось. Их интерфейс имеет какую-то свою фишку, которая порой притягивает, и благодаря этому хочется постоянно пробовать новые версия гнома, но увы, пока присутствуют тормоза, гном так и будет оставаться богомерзким гномом.
Казалось бы при чём тут Гном в новости про новый тулкит, но анонимные аналитики не дремлют.
> Казалось бы при чём тут Гном в новости про новый тулкитДа-да, отображение GtkLabel через (полурабочий тормозной) 3D-драйвер конечно не приведёт к тормозам.
Зачем вам полурабочий тормозной 3D-драйвер?
Судя по api:
>>gsk_blur_node_new gsk_cross_fade_node_new и gsk_blend_mode_newрисовать блур, затухание и блендинг.
Или возложить на процессор?
Не рисовать их вообще — не вариант?
где gnome-shell, где gtk, и где полурабочий 3d-драйвер?
Я бы ответил где, в рифму, но это не печатаемо. Так что, где-то ниже. Вы попали в просак.
Знаю это чувство. Мне даже нравятся интерфейсные решения, я понимаю логику, которая стоит за ними, и чувствуется, что это как будто бы идёт в пределе к чему-то беспрецедентно хорошему, при этом не копирующему ни винду, ни макось.
При этом гном единственное ДЕ, на которое можно положиться из коробки. Я вот, допустим, не помню, как там работает и настраивается работа с двумя дисплеями. Но беру ноут с гномом на митап, ничего не проверяя, и знаю, что когда подключу его к проектору, я легко найду нужную кнопку в настройках, и это 100% будет работать без xrandr, конфигов и вбивания пикселей руками.
Аналогично и со всем остальным, с управлением файлами, с подключением к фтп серверу или там дропбоксу, с календарем, отправкой почты, сканированием, распечаткой. С горем пополам, но достичь выполнения любой типовой описнопланктонной задачи через интерфейс гнома можно прямо на месте, не читая килобайты манов. Про остальные ДЕ такого сказать не могу. Заслужено дефолтное окружение в гну/линуксе.
Так что даже пользуюсь этим. С выключенными анимациями. Потому что дёрганые анимации хуже, чем никаких. Но гномьи тормоза даже курсора это ппц, да.
Если ты понимаешь логику гном, скажи мне для чего часы в верхней панели по центру, и почему они делаю такие большие заголовки у приложений?
по феншую в gnome нельзя окна раскрывать на весь экран? ссылка на скин https://ibb.co/kYdD36
> для чего часы в верхней панели по центруДля того чтобы смотреть время
>и почему они делаю такие большие заголовки у приложений?Тут три момента: сенсорные экраны, CSD и просто удобство.
>по феншую в gnome нельзя окна раскрывать на весь экран?Можно
>Для того чтобы смотреть времяСмотреть время??? Б**ть, это не смотреть, это пялиться на время.
>Тут три момента: сенсорные экраны, CSD и просто удобствоМух от котлет делить не учили? Какое б**ть удобство в огромных кнопках может быть??? Разве что тем, кто мышь держит двумя пальцами в раскарячку
> Какое б**ть удобство в огромных кнопках может быть???На ноутбуках с сенсорным экраном - удобство.
В win для этого же сделали плитки и плоский дизайн. Так лучше?
>На ноутбуках с сенсорным экраномНоутбуки с сенсорными экранами и удобство - это два разных мира.
>В win для этого же сделали плитки и плоский дизайн
Ах вон оно что, на винду равняются...Тогда понятно. Ну что же, идиотам идиотово...
>Так лучше?Нет.
> Ах вон оно что, на винду равняются...Они не на винду равняются, а видят что, как бы нам не хотелось обратного, движется всё в сторону отказа от мыши. Поэтому и развивают в этом направлении. Win, в данном случае, делает тоже самое, но несколько в другом исполнении.
ЗЫ. К слову, вроде как темы в GNOME никто не отменял.
>движется всё в сторону отказа от мышиКак в ваши головы это вообще все заходит? Откуда этот бред? Ты решил, что все поделятся на гиков-красн0глазиков и кассиров макдака?
А вы с современными школьниками младших классов общаться пробовали?
Они уже предпочитают сделать что-то на телефоне и планшете с тачем, чем взять ноут/десктоп и мышку. Даже, казалось бы, вещи, которые с мышкой быстрее - полазить по вебу; смонтировать видео с эффектами и музыкой.Так что пока вы делите всех на гиков и кассиров макдака, новое поколение подрастает с совсем другими привычками к UI. А это еще не стало доступным управление движением взгляда, к примеру...
>новое поколение подрастает с совсем другими привычками к UIкогда работа выходит на уровень чуть сложнее вэб сёрфинга и игрулек, то сразу начинается "Дай мне ноутбук/компьютер, мне надо это-это-это сделать в школу/универ/..."
>>новое поколение подрастает с совсем другими привычками к UI
> когда работа выходит на уровень чуть сложнее вэб сёрфинга и игрулек, то
> сразу начинается "Дай мне ноутбук/компьютер, мне надо это-это-это сделать в школу/универ/..."гнумтри разработан с учётом в том числе киосков и касс и нет никакой причины искусственно делить интерфейсы на мышевозные и пальцевые в эпоху универсальных дизайнов. это один из пунктов современного дизайн-кода: интерфейс должен быть готов к любому использованию из коробки, потому что ты не знаешь чем там будет пользователь в кнопки тыкать. за опциональное уменьшение кнопок и прочие твики можно проголосовать\настроить плагинами.
>нет никакой причины искусственно делить интерфейсы на мышевозные и пальцевые в эпоху универсальных дизайновОдни из рэдмонда так уже считали. Где они на рынке мобильных устройств все мы знаем.
а какое удобство в маленьких кнопках? компьютерами таки пользуются не только мастера киберспорта сбивающие пиксель с головы собаки с закрытыми глазами..
Для инвалидов отдельные средства есть.
> Мух от котлет делить не учили? Какое б**ть удобство в огромных кнопках
> может быть??? Разве что тем, кто мышь держит двумя пальцами в раскарячкуТы живешь на другой планете и планшеты туда не завезли? Ребят, соберите несчастным аборигенам транспортник.
У меня не сенсорный экран, а монитор 24". И дома и на работе. На арботе два. Нахрена мне такие заголовки? Достаточно высоты в 24 пиксела, чтобы там все прочитать.
Кстати, приложения открываются всегда расползаясь по двум дисплеям и не помнят предыдущих размеров. Это вообще какой-то афедрон.
>> Если ты понимаешь логику гном, скажи мне для чего часы в верхней панели по центру,Не знаю, кому как, а мне так удобнее, чем высматривать в свалке в правом углу. И в этом и логика.
>> и почему они делаю такие большие заголовки у приложений?
>> по феншую в gnome нельзя окна раскрывать на весь экран? ссылка на скин https://ibb.co/kYdD36В дремучих 2002+ годах, когда я впервые заимел Линуксы (ASP 8, кажется, был самый первый какой-то был, но из-за сложности с интернетами задержался только дебиан 4 на 4 ДВД. Даже купил звуковую карту вместо встроенной в материнку, чтобы слушать музон) я плевался от Gnome-HIG, который и во 2м гноме был странный и из-за которого тот же хиганутый на всю голову Pidgin (Gaim) тратил напрасное вертикальное пространство драгоценное. Тогда это было совершенно неюзабельно на 480 пикселях вертикальных. Там панельки, сям панельки и в итоге на список контактов остаётся не у дел. Но спустя пару лет с ростом разрешений это стало восприниматься вполне нормально.
Я на своём фулл-хд экране нормально воспринимаю большие кнопки и заголовки, не мешают.
А мне казалось, что размер элементов должен зависеть от физических размеров экрана, а не от разрешения (если оно, конечно, не 640x480).
Мне кажется, что это вообще наследие винды, что если разрешение больше, то элементы должны быть меньше.
Имхо, если разрешение больше, элементы должны быть _чётче_.
> А мне казалось, что размер элементов должен зависеть от физических размеров экрана,
> а не от разрешения (если оно, конечно, не 640x480).
> Мне кажется, что это вообще наследие винды, что если разрешение больше, то
> элементы должны быть меньше.
> Имхо, если разрешение больше, элементы должны быть _чётче_.Так, да не так. Когда мы говорим об примерно одного размера физических экранах на одном расстоянии от глаз - это так. Когда у нас есть экран телефона, экран планшета, экран ноута, экран десктопа, экран ТВ - все внезапно сильно усложняется. И если разрешение среда знает, физический размер с грехом пополам (не всегда) выяснить может, то о расстоянии до глаз она не знает категорически. Разве что эвристикой. А это определяет размер элементов куда больше, чем разрешение.
Вы же не хотите иметь один размер элементов на экране Full HD 22" и на телефоне Full HD 5" ? И пропорциональный DPI (т.е. в 4 раза больше на втором) тоже не хотите.
Таки всё так. Ну вот тогда должен быть "класс устройств". А то тут пишут про "Так удобнее там-то тыкать". Ну так на классе устройств "планшет" оно как бе одно, а на мониторе 22" оно другое. вообще, эти споры о кнопках непонятны во всяких Unix'ах, Linux'ах. Большинство DE позволяет сделать кнопки как надо, где надо, а то и вообще убрать. Но, sensible defaults должны быть, как ни крути. Вот про них и вой, как понимаю.
Расстояние от глаз для монитора и планшета/смартфона не сильно отличается, где-то раза в полтора. Дело прежде всего в физическом размере экрана, а не в расстоянии.
"и почему они делаю такие большие заголовки у приложений?"Ну в основном потому, что туда добавляются необходимые кнопки помимо закрыть/свернуть/развернуть, что неплохо там экономит место, см. наутилус в гноме 3.22. В отличие от других ДЕ, где заголовок окна просто занимает место и не несет в себе никаких полезных функций.
> "и почему они делаю такие большие заголовки у приложений?"
> Ну в основном потому, что туда добавляются необходимые кнопки помимо закрыть/свернуть/развернуть,
> что неплохо там экономит место, см. наутилус в гноме 3.22. В
> отличие от других ДЕ, где заголовок окна просто занимает место и
> не несет в себе никаких полезных функций.Вообще-то, все это должно настраиваться. Если я работаю в полноэкранном режиме, зачем мне заголовок с меню и кнопками? Мне нужно меню, которое пулл-даун. Желательно открепляемое и несворачиваемое после открепления.
Пальцем я ничего не тыкаю -- на сей счет есть мышка и планшет, котороые делают все очень аккуратно.
>> "и почему они делаю такие большие заголовки у приложений?"
>> Ну в основном потому, что туда добавляются необходимые кнопки помимо закрыть/свернуть/развернуть,
>> что неплохо там экономит место, см. наутилус в гноме 3.22. В
>> отличие от других ДЕ, где заголовок окна просто занимает место и
>> не несет в себе никаких полезных функций.
> Вообще-то, все это должно настраиваться. Если я работаю в полноэкранном режиме, зачем
> мне заголовок с меню и кнопками? Мне нужно меню, которое пулл-даун.
> Желательно открепляемое и несворачиваемое после открепления.
> Пальцем я ничего не тыкаю -- на сей счет есть мышка и
> планшет, котороые делают все очень аккуратно.и оно таки настраивается! но пока через правку конфигов и твиктулзы. есть причины не перегружать гуишку настроек этими пунктами, что-бы неопытные пользователи не понавключали себе того что потом не смогут выключить. но да стоит проголосовать за добавление каждого популярного твика в какой-нить пункт адвансед настроек типа флагов в бразерах
Единственное, чего я не понимаю в логике гнома – там не предусмотрено решения для автозапуска фоновых сервисов при входе в систему. То есть я включаю компьютер, и пока ручками не запущу эволюшн и пиджин, никаких уведомлений не будет. Это вымораживает. Хочу как в андроиде.А то, из-за чего опеннет уже который год бомбит, по мне, не стоит таких эмоций вот вообще.
>мне для чего часы в верхней панели по центруЭто не часы, а в первую очередь центр уведомлений, календарь, и погода. Гном построен вокруг идеи, что важен центр экрана, куда пользователь смотрит всё время, а остальное не должно привлекать внимание, и должно быть доступно взмахом мышки "куда-нибудь туда", без точного позиционирования. Если понять это, то решение "овервью окон – взмах влево-вверх, уведомления – взмах вверх, настройки и изменение состояния – взмах впарво-вверх" оказывается более чем правильным.
>и почему они делаю такие большие заголовки у приложений?Потому что в них предлагается размещать что-то поезное (кнопки, менюшки). Кэп. Меня сильнее раздражает бесполезные редмонд-стайл заголовки гнома 2/qt, в которых было всегда ровно три малюсеньких кнопки на все 900x32 пикселей, одна из которых (minimize) ещё и ненужная. Вас нет?
>по феншую в gnome нельзя окна раскрывать на весь экран?f11?
> Единственное, чего я не понимаю в логике гнома – там не предусмотрено
> решения для автозапуска фоновых сервисов при входе в систему. То есть
> я включаю компьютер, и пока ручками не запущу эволюшн и пиджин,
> никаких уведомлений не будет. Это вымораживает. Хочу как в андроиде.Эм. Да вроде всегда был. Стандартный механизм XDG там используется нынче, как давно уже везде. Что в /etc/xdg/autostart или в ~/.config/autostart имеет метку "X-GNOME-Autostart-enabled=true" - автозапускается.
Хотите гуй к пользовательскому автозапуску - первая вкладка ("автозапуск") в gnome-tweak-tool. Пара кликов и ваш пиджин всегда запускается сам.
>>по феншую в gnome нельзя окна раскрывать на весь экран?
> f11?Двойной клик по заголовку.. F11 это вроде только браузер и терминалы умеют.
> Двойной клик по заголовку.. F11 это вроде только браузер и терминалы умеют.Третий гном точно не умеет f11. Он вобще не может ни спозиционировать окно, ни запомнить его прежние координаты и размеры. евинс уже задолбал в конец -- всякий раз нужно его из масштаба в 735% приводить в одно из окон. Кстати, окуляр тоже накрылся -- полный интерфейк.
Тогда почему, уведомления показываются маленьким круглешком? почему не мигает, тебе пришло уведомление,а в это время ты отвелекся, и всё, хз что тебе пришло, я вообщевообще не замечал этого маленького кружочка, и получается постоянно смотришь, нет ли у тебя уведомления, а не работаешь. https://ibb.co/dhB6am
Поддерживаю вас. Тоже вкатили различные решения и элементы ДЕ, но тормоза... Как ложка дегтя. Казалось бы, с таким подходом минимализма (интерфейса, настроек, функций) - все должно летать (и разрабатываться легче), но всё не совсем так.Зачем хард так агрессивно юзать? Если не ссд, то система ощутимо тормозит. Что там за гигабайты по dbus гонять? Имхо, всё это зло высокоуровневой абстракции, упрощающая работу нескольким прогерам, но неэффективно использующая мощности компьютера.
Пересаживаясь с ноутбука, где жутко тормозит система, на обычный планшет (который на порядок медленнее), где андроид летает со скоростью звука (и не важно сколько там у вас вкладок открыто) - это гневное ощущение только увеличивается.
Купил мак, понял что гномосеки не только не поняли основую идею но еще и извратили то что было в старом гноме.
> Купил мак, понял что гномосеки не только не поняли основую идею но
> еще и извратили то что было в старом гноме.Да в Маке тоже сомнительных решений полно. Почему, блин, просто нельзя развернуть окно на полный экран, какого черта я должен искать и устанавливать для этого третьи приложения? Почему я не могу создать простой, блин, текстовый файл правой кнопкой мыши? Выловить этого козла, который в яббле интерфейсами занимается и я-ца ему оторвать.
Как же я вас понимаю.
А так всё просто: пиппл и так хавает, выстаивает многочасовые пробки ради того, чтобы купить новый *фон, контора получает бабло. Все довольны в этом кружке по интересам.
Может лучше наконец в 2017 году купить видеокарту с поддержкой 3D-ускорения?
> Может лучше наконец в 2017 году купить видеокарту с поддержкой 3D-ускорения?Конечно! Давайте всем офисным сотрудникам понаставим мощных видюх, по 16ГБ памяти, и core i7, а то у них DE тормозит. Бред!
Какой бред? ЧТо надо сделать чтобы гном начал тормозить на более менее современном компьютере. AMD A4 4400 с 4 Гб ОЗУ и встроенной графикой вполне достаточно. Ну вот если компьютере еще менее мощный, то таки лучше присмотреться к более легким окружениям.
> Какой бред? ЧТо надо сделать чтобы гном начал тормозить на более менее
> современном компьютере. AMD A4 4400 с 4 Гб ОЗУ и встроенной
> графикой вполне достаточно. Ну вот если компьютере еще менее мощный, то
> таки лучше присмотреться к более легким окружениям.Пользователь не должен замечать работы DE. Если Ваше окружение жрет ресурсы, а тем более требует еще и поддержки 3D, то это плохое окружение. Если, конкретно Вам нравится любоваться, на то как у вас красиво прячутся окошки, по всему рабочему столу мигают всякие свисто-перделки, то это Ваше личное дело, обычным людям надо просто работать, быстро переключаться между приложениями иметь удобное меню, эргономичную панель и т.д.
А еще обычным людям необходимо постоянство, чтобы человек через 2 года вернулся на свое прежнее место и у него не было вот такой реакции: "Бл** что это за н*** ???" А это именно то, что происходит со всеми DE линукса, пожалуй за исключением XFCE, который, лично я не могу терпеть по другим причинам.
>Пользователь не должен замечать работы DE. Если Ваше окружение жрет ресурсы, а тем более требует еще и поддержки 3D, то это плохое окружение.
>А еще обычным людям необходимо постоянство, чтобы человек через 2 года вернулся на свое прежнее место и у него не было вот такой реакции: "Бл** что это за н*** ???"Да-да, у вас в конторе целероны с ХП именно поэтому, а не по причине ни-ще-бродства, вот прям верю.
>>Пользователь не должен замечать работы DE. Если Ваше окружение жрет ресурсы, а тем более требует еще и поддержки 3D, то это плохое окружение.
>>А еще обычным людям необходимо постоянство, чтобы человек через 2 года вернулся на свое прежнее место и у него не было вот такой реакции: "Бл** что это за н*** ???"
> Да-да, у вас в конторе целероны с ХП именно поэтому, а не
> по причине ни-ще-бродства, вот прям верю.Мне всегда нравилась эта позиция, особенно распространённая среди геймеров, что вкидывать ресурсы железа в ненужные свистоперделки -- это по пацански, и повышает статус в группе, а нежелание заниматься таким -- железобетонное свидетельство нищeбрoдства и ведёт к опусканию в разряд омег. Такая детская незамутнённость всегда наводила меня на мысль, что все геймеры -- подростки. Что странно и противоречит фактам: мне приходилось встречать среди геймеров и дяденек лет по тридцать.
Обратная крайность тоже вызывает большие сомнения в психическом здоровье страдающих ею. Странно как-то в 2017г экономить мегабайты ОЗУ и гигабайты на диске, теряя время и нервы на колупание системы в попытках привести ее к состоянию 10-15-летней давности, вместо того, чтобы просто пойти и купить новое железо. Не какое-нибудь мегакрутое и стоящее овердофига, а просто соответствующее требованиям современного софта.
> Обратная крайность тоже вызывает большие сомнения в психическом здоровье страдающих ею.
> Странно как-то в 2017г экономить мегабайты ОЗУ и гигабайты на диске,
> теряя время и нервы на колупание системы в попытках привести ее
> к состоянию 10-15-летней давности, вместо того, чтобы просто пойти и купить
> новое железо. Не какое-нибудь мегакрутое и стоящее овердофига, а просто соответствующее
> требованиям современного софта.Крайности всегда странны. Но ты упускаешь из вида один нюанс: если тебе хочется современного железа, то тебе придётся менять его каждые два-три года. Причём это накладно вне зависимости от твоего уровня доходов и уровня притязаний, то есть того насколько ты хочешь отставать от топовых железок. Ну, смотри, допустим ты определил для себя, что выделить сумму N т.р. на железо приемлимо для тебя и тебя устроит производительность. Проходит два года, тебя уже не устраивает производительность, даже если за это время твои требования к производительности не изменились. Если при этом твоё понимание приемлимой стоимости железа тоже не изменились, значит ты идёшь и ещё раз тратишь сумму N т.р. только на то, чтобы сохранить производительность на том же уровне. И это повторяется каждые 2-3 года. Это просто такой принудительный взнос на разработку нового железа.
При этом, в принципе, можно заниматься апгрейдами, у себя дома так вообще без проблем можно вкинуть в десктоп изначально денег с такой задумкой, чтобы потом поддерживать его на уровне итеративными апгрейдами. Я так и делаю, собственно, меняя мать раз в 7-10 лет и вкладывая в среднем, может быть 1k рублей в год на поддержание заданного уровня производительности. Это не совсем работает: это очень видно по времени пересборки системы, оно всё же растёт. Но, пока я могу пересобрать всю систему за выходные, я не особо парюсь на этот счёт и полагаю, что мне этой матери вполне хватит до 2020 года, а там посмотрим.
Возвращаясь к организациям: у них с апгрейдами проблемы: одно дело работать с сотней системных блоков, и другое дело работать с сотней материнок, двумя сотнями планок оперативки, и вагонами другой требухи, отслеживая каждую деталь, спотыкаясь о вопросы их совместимости друг с другом и проч. Кроме того организация не будет покупать б/у железки в розницу на avito. Поэтому организация, как правило, меняет системники целиком. И организация не готова каждые два три года менять всё железо. Деньги небесплатны. Деньги могут работать и зарабатывать деньги. Это капитализм, детка. Деньги будут вкидываться в регулярную смену железа, только если такие вливания приносят больше финансовых плодов, чем проценты по вкладу в банке, чем доходы от инвестиций в ПИФы, чем перепродажа апельсинов и прочие более простые способы заработать деньги на деньгах.
Вообще не понимаю что такое "апгрейды" и зачем они нужны. Это какой-то упоризм - купить дешевое гогно, через год его продать за треть цены в лучшем случае, купить другое дешевое гогно, чуть получше, goto 1. Я в 14-м году собрал себе домой систему на Asus Rampage 4, i7-3970X, 64Gb мозгов и NVidia Titan X 6Gb. Стоило все это ~200k, но даже сейчас оно лучше многого того, что продают как новое. И менять что-то в ближайшие 5-6 лет я смысла не вижу. Я так делаю, с тех пор как я собрал свой первый комп в 2002г. Оно так банально дешевле, особенно если откладывать деньги на счет в банке, чтобы банк платил тебе проценты, а не брать кредит к дедлайну, чтобы ты платил проценты банку.
В организациях тоже самое - закупаются компы и эксплуатируются 5-7 лет, после чего идут в утиль. То, что "IT-шнеги" зачастую не способны рассчитать запас мощности компов или менеджерье п...ит деньги, закупая самое дешевое гогно, собранное в подвале Джамшутами - это совсем другая проблема. О том, чтобы заранее предусмотреть средства на модернизацию, и вложить их адресно для сохранения, и не трогать на текучку - вообще речи нету.>Деньги будут вкидываться в регулярную смену железа, только если такие вливания приносят больше финансовых плодов
Во, сразу видно модно-молодежный стиль мышления. Однако хипсторы от экономики в погоне за большими и быстрыми деньгами обычно забывают, что простои и факапы прибыли не приносят совсем, и вообще чреваты штрафными санкциями. Опять-таки, что в РФ такой стиль мышления цветет и процветает - это совсем другая проблемы, плоды которой можно зримо увидеть, если отъехать от DC километров на 200-300. Увы, законы мироздания красивыми речами и презенташками изменить невозможно, чтобы что-то получать, надо что-то вкладывать. Курицу, несущую золотые яйца, желательно все-таки кормить, иначе она сдохнет, и яиц не будет. Мне тут недавно рассказали, что даже на Почте России сейчас меняют компы и автотранспорт. То есть до самых тупых стало доходить, что если юзверь проголосует ногами, то можно и вовсе обнаружить себя выкинутым на обочину просить милостыню.
Так-то все любят получать и никто не любит тратить, включая и нас с тобой. Просто у одних есть мозги, и они могут планировать на несколько ходов вперед, а другие модно-молодежно "живут одним днем"(tm).
> Вообще не понимаю что такое "апгрейды" и зачем они нужны. Это какой-то
> упоризм - купить дешевое гогно, через год его продать за треть
> цены в лучшем случае, купить другое дешевое гогно, чуть получше, goto
> 1.Я описывал выше два примера стратегий поддержания железа в актуальном состоянии. Либо менять каждые два три года, либо не менять, но поддерживать в актуальном состоянии. Ничего не надо продавать. Не, ну бывает конечно, если меняешь процессор, то старый можно и продать, если кто купит. Но процессор далеко не всегда самое узкое место. Такие задачи, как покупки SSD, жёстких дисков, планок оперативки не требуют замены, они аддитивно вставляются в существующую систему.
> Я в 14-м году собрал себе домой систему на Asus
> Rampage 4, i7-3970X, 64Gb мозгов и NVidia Titan X 6Gb. Стоило
> все это ~200k, но даже сейчас оно лучше многого того, что
> продают как новое.Главное купить мать, которую можно потом постепенно обвешивать всякими приблудами. Чё делать с видеокартами я не знаю, но у меня каких-то особых требований к видеокартам нет, да и они мне достаются бесплатно, потому что брат мой их меняет довольно часто, ему надо чтобы всякие крутанские игрушки шли, желательно на максимальных настройках.
> И менять что-то в ближайшие 5-6 лет я
> смысла не вижу. Я так делаю, с тех пор как я
> собрал свой первый комп в 2002г. Оно так банально дешевле, особенно
> если откладывать деньги на счет в банке, чтобы банк платил тебе
> проценты, а не брать кредит к дедлайну, чтобы ты платил проценты
> банку.Проценты в банках целиком съедаются инфляцией и в лучшем случае ты выходишь по нулям. Полезнее деньги тратить сразу, по мере поступления.
>>Деньги будут вкидываться в регулярную смену железа, только если такие вливания приносят больше финансовых плодов
> Во, сразу видно модно-молодежный стиль мышления.Вообще-то этот стиль мышления был разработан в средних веках. А с приходом капитализма он стал доминирующим. Если он тебе кажется модно-молодёжным, то напрашивается предположение, что родился ты в СССР, воспитан там же, и капиталистическое мышление, которое всё измеряет деньгами, и именно от денег пляшет при принятии решений тебе _кажется_ новым, несмотря на весь его возраст.
> Однако хипсторы от экономики в погоне
> за большими и быстрыми деньгами обычно забывают, что простои и факапы
> прибыли не приносят совсем, и вообще чреваты штрафными санкциями.Вероятность простоев и факапов должна учитываться при расчёте рисков. Если она не учитывается, то смените менеджера на того, кого преподам в ВУЗе удалось научить этому.
> Мне тут недавно рассказали, что даже на Почте России сейчас меняют компы
> и автотранспорт. То есть до самых тупых стало доходить, что если
> юзверь проголосует ногами, то можно и вовсе обнаружить себя выкинутым на
> обочину просить милостыню.Хых. Почта России. Судя по её факапам, там смена компов не поможет. Они ввалились в серьёзный системный кризис, где сама структура организации не соответствует решаемым задачам. Смена компов может быть тоже необходима -- ну, если менять софт, если большее количество задач сваливать на компьютеры, если уделять больше внимания прогнозированию, моделированию, и прочим вещам, то действительно может потребоваться поменять парк компьютеров. Но если просто поменять 286 на i7, то ничего не изменится.
> Так-то все любят получать и никто не любит тратить, включая и нас
> с тобой. Просто у одних есть мозги, и они могут планировать
> на несколько ходов вперед, а другие модно-молодежно "живут одним днем"(tm).Если те, у кого есть мозги, не занимаются вычислением ожидаемой прибыли, то они принимают решения навскидку. Если есть несколько вариантов как можно действовать, то можно сказать "мне интуиция подсказывает, что надо принять решение X", это действительно путь для тех, у кого мозгов слишком много. Те же кто потупее начинают считать, учитывая все возможные факторы, в том числе и упомянутые тобой риски. Они выражают всё в деньгах, или в распределениях вероятностей прибылей, сооружают математические модели, обсчитывают их по каждому из возможных решений, после чего выбирают то решение, для которого ожидаемая прибыль максимальна. Ну и риски приемлимы, конечно.
Те же, у кого мозгов вообще нет, не сочиняют никаких моделей, а пользуются существующими и проверенными практикой моделями. Собственно для этой категории граждан и существует экономическое образование. Предыдущая -- сочиняющая модели категория -- это математики. А первая, с мозгами переполняющими череп -- это анонимы опеннета.
>>Пользователь не должен замечать работы DE. Если Ваше окружение жрет ресурсы, а тем более требует еще и поддержки 3D, то это плохое окружение.
>>А еще обычным людям необходимо постоянство, чтобы человек через 2 года вернулся на свое прежнее место и у него не было вот такой реакции: "Бл** что это за н*** ???"
> Да-да, у вас в конторе целероны с ХП именно поэтому, а не
> по причине ни-ще-бродства, вот прям верю.Celeron'ов и XP к счастью нет, но Core 2 Duo кое-где остались. Только что в этом плохого, если железо через столько лет продолжает выполнять свои функции? Вы повзрослеете, начнете работать и все поймете, а пока принимайте мои слова как данное.
Кстати, что это за новое слово у школьников и студентов появилось "ни-ще-бродство"? Я уже не первый раз вижу, но не могу уловить скрытый смысл. Это типа, кому мама и папа не покупают все самое последнее и новое, автоматически переводится в разряд "ни-ще-брод"ов ? :-))))
Нет, это когда ты имея возможность купить нормальный автомобиль среднего класса ездишь на ржавой шахе, из которой гайки уже сыплются. Так, может, понятнее будет?
> Нет, это когда ты имея возможность купить нормальный автомобиль среднего класса ездишь
> на ржавой шахе, из которой гайки уже сыплются. Так, может, понятнее
> будет?Ладно, глупости все это. Мы разговариваем про предприятие и бизнес, где под любое действие необходимо экономическое обоснование, а Вы мне неуместные аналогии приводите. Сознайтесь, что были не правы и закончим на этом ;-)
Ога. Это когда не имея средств и надобности вместо ржавой шохи покупают бэху и издят в магазин за продуктами за две остановки.
Я просто поставил гном на планшет, и получил лагодром.
Acer w500. И да драйвера просто изменяют характер лагов. Тормозит все дико. Ибо во 1 видео во 2 постоянное обращение к диску.
> Я просто поставил гном на планшет, и получил лагодром.
> Acer w500. И да драйвера просто изменяют характер лагов. Тормозит все дико.
> Ибо во 1 видео во 2 постоянное обращение к диску.И да, лучше б они отдельную екранную клавивтуру завезли. То что есть ща на линуцксах это какой-то гребанынй стыд. Игрушки для детей дошкольного возраста есть... но нет нормальной независимой от DE екранной клавиатуры
> Может лучше наконец в 2017 году купить видеокарту с поддержкой 3D-ускорения?Зачем интерфейсу такая карта? Пирдеть и свистеть?
И к чему в здесь об этом? Проблема по-вашему в GTK или что вы хотели сказать?
> В GtkEntry добавлен виджет для выбора Emoji. Также добавлены хинты для ввода Emoji с клавиатуры;Ну всё, теперь заживём. Это именно то, что не хватало.
https://keddr.com/wp-content/uploads/2015/03/Emoji-Keyboard.jpg
А вот так и надо сделать, общаться небольшими ребусами будем. Исчезнет недопонимание между народами, один универсальный язык, который поймет каждый. Английский оставить для кодинга.
Шо ж ты делаешь, ирод? Как мне теперь развидеть это? :)
> Шо ж ты делаешь, ирод? Как мне теперь развидеть это? :)Отак: http://static.nix.ru/autocatalog/keyboards_sven/160817_2245_... =)
Не практично.
Вообще бы классно было бы иметь на клавиатуре вместо NumPad'а EmojiPad ⌨️
Ну так настро... А, у тебя мак? Сочувствую.
Чего сочувствовать. В macOS с Emoji всё в порядке, ну так речь о другом.
Emoji очень много, и их до сих пор не хватает. Например, только вот добавили зебру 🦓 (пока только в iOS завезли). А раньше просто лошадь была 🐎
Поэтому было бы прикольно иметь на ⌨️ вместо бестолково NumPad этакую сенсорную панель для выбора Emoji
>> В GtkEntry добавлен виджет для выбора Emoji. Также добавлены хинты для ввода Emoji с клавиатуры;
> Ну всё, теперь заживём. Это именно то, что не хватало.Это, типа, бусы, которыми решено привлекать папуасов.
А как там бинарная совместимость ?? Приложение времен ASPLinux 10 запустится ??
запустится, если рядом положишь gtk нужной версии -)
А зачем в опенсорсе бинарная совместимость? Важна совместимость на уровне исходников, перекомпиляция вам в руки.
Ну собери исподник 10 и более летней давности современным gcc. С - совместимость, ога.
А в современном GCC изчезла опция -std=c89/99/...?
Ты никогда не видел, сколько в сорцах любого дистра патчей с характерными названиями patch-gccXX? Наворачивание костылей на костыли - зело увлекательное занятие, скажу я тебе.
Как зачем? Тебе не приходилось несколько часов пересобирать грядку пакетов после апдейта какой-нибудь миниатюрной библиотечки типа libjpeg? Бинарная совместимость -- это удобно, и будет подлым ломать её в минорных релизах.
Приходилось
emerge @preserved-rebuild
;)
> Приходилось
> emerge @preserved-rebuild
> ;)Если приходилось, то чего я объясняю тогда, ты и сам понимаешь.
И что такое пару чаcов по сравнению с пересборкой всего @world
> А зачем в опенсорсе бинарная совместимость?Не все любят пересобирать мир каждую неделю.
на gma3150 gnome-shell не юзабелен, как и юнити...ток lxde, xfce, e17 и дальше тоже лаги, на r5 230 caicos gnome-shell вполне ничего. и если выбирать между кде и гнум-шелл то я выбираю гнумшелл ;)...хотя кде тоже ничего.
:D
IceWM же этому господину, ну или голый Open(или другой)Box
а у Вас есть сборочки с e17 и e21?
Человек перечислял DE, ты ему советуешь WM... Миш, вторник уже, завязывай бухать.
> на gma3150 gnome-shell не юзабелен, как и юнити...ток lxde, xfce, e17 и
> дальше тоже лаги, на r5 230 caicos gnome-shell вполне ничего. и
> если выбирать между кде и гнум-шелл то я выбираю гнумшелл ;)...хотя
> кде тоже ничего.на gma500 проблема в основном в том, что dri,libva,mesa и прочее завязаны на старые версии ядра и иксов. А то, что работает - софтверное. Как-то так (возможно ошибаюсь).
Крестик на тулките большой чтобы точно попасть в него?
> Прекращение поддержки сборочной системы на базе autotools в пользу инструментария MesonЭх, молодёжь... По описанию Мезона (да и других "новых" систем сборки, типа Шейк) может показаться, что главное - задавать цели и предпосылки. Так вот, make прекрасно с этим справляется, написан на Си, лёгкий, быстрый, портируемый. Автотулсы решают другую задачу - анализ окружения и настроку исходных текстов для него. Даже Cmake за годы не догнал Autotools. А "системы сборки" на Питоне или Хаскеле - это вообще ни в какие ворота не лезет.
А ты побовал? Meson шикарен!
Так и Meson не собирает, собирает Ninja. Ninja пошустрей make будет, хотя КМК и не такая фичастая.
> Автотулсы решают другую задачу - анализ окружения и настроку исходных текстов для негоТак и cmake и meson решают ту же задачу.
> Даже Cmake за годы не догнал Autotools.В чём это выражается? Действительно интересно, без подколов.
> А "системы сборки" на Питоне или Хаскеле - это вообще ни в какие ворота не лезет.А это принципиально? m4 и Perl чем-то лучше?
> А это принципиально? m4 и Perl чем-то лучше?Наверно, это придётся повторять всё чаще: m4 или Перл не нужны во время конфигурирования. Только шел, даже не Баш, плюс несколько утилит POSIX (опять же хорошо портируемых).
> Только шел, даже не БашЗависит от радиуса кривизны рук разработчика. Некоторые ухитряются писать bash-only макросы.
Ну да ладно, ты лучше объясни, зачем во время конфигурирования эти 100500 шелл-скриптов, напиханных в дерево исходников? Для небольших проектов их объём может в разы превышать объём кода. А с задачей обеспечения переносимости они справляются примерно никак, опять-таки в силу кривизны рук макросописателей, помноженной на разбросанные по самим автотулзам баги.
>> Только шел, даже не Баш
> Зависит от радиуса кривизны рук разработчика. Некоторые ухитряются писать bash-only макросы.
> Ну да ладно, ты лучше объясни, зачем во время конфигурирования эти 100500
> шелл-скриптов, напиханных в дерево исходников? Для небольших проектов их объём
> может в разы превышать объём кода. А с задачей обеспечения переносимости
> они справляются примерно никак, опять-таки в силу кривизны рук макросописателей, помноженной
> на разбросанные по самим автотулзам баги.Это вы ещё Gradle не видели. ;) Обслуживающий сборку код - очевидно ради самого процесса написания обслуживающего кода и ничего больше. Это завораживает.
> Даже Cmake за годы не догнал Autotools.По тормознутости, сложности и ненадёжности? Я верю, что в этом никто и никогда не сможет сравняться с autotools.
Но с тем, что системы сборки на питоне — зло, полностью согласен.
>> Даже Cmake за годы не догнал Autotools.
> По тормознутости, сложности и ненадёжности? Я верю, что в этом никто и
> никогда не сможет сравняться с autotools.Дело в том, что я часто вижу такое "конфигугирование":
if platform.system() == 'Linux':
# Enable EpollВместо того, чтобы проверить наличие sys/epoll.h и epoll_create(), с помощью вызова компилятора для простой программы.
Конечно, platform.system() == 'Linux' быстрее, но в корне неверно.
Скорость всех этих поделок объясняется очень просто - системы конфигурации проверяют не то, что нужно.
> Дело в том, что я часто вижу такое "конфигугирование":
> if platform.system() == 'Linux':
> # Enable Epoll
> Вместо того, чтобы проверить наличие sys/epoll.h и epoll_create(), с помощью вызова компилятора
> для простой программы.Зачем для проверки наличия файла запускать компиляцию? А autocrap таки её запустит дважды: и для проверки наличия заголовка, и для проверки наличия функции. cmake же найдёт файл сам и запустит компиляцию только один раз, чтобы проверить наличие функции. Причём не будет генерить на ходу временный исходный файл, а использует стандартный CheckFunctionExists.c.
> Скорость всех этих поделок объясняется очень просто - системы конфигурации проверяют не
> то, что нужно.И что же из описанного абзацем выше не то, что нужно?
> Зачем для проверки наличия файла запускать компиляцию? А autocrap таки её запустит дважды: и для проверки наличия заголовка, и для проверки наличия функцииВот-вот. Затем, что только компилятор знает, где <foo/bar.h> лежит. Затем, что файл может присутствовать и проглатываться препроцессором, но не самим компилятором или компоновщиком (например, потому что библиотека не установлена). И автотулсы, и симэйк не делают ничего сами, а только то что им сказано: проверить файл, проверить функцию, и т. п. Так что тут мимо. Не только незнание матчасти, но и непонимание целей и задач.
> только компилятор знает, где <foo/bar.h> лежит.Откуда он это может знать, если не из опций, которые ему передаёт система сборки?
> файл может присутствовать и проглатываться препроцессором, но не самим компилятором или компоновщиком
> (например, потому что библиотека не установлена).Откуда же он тогда взялся? Это тебе надо систему чинить, если у тебя там такой бардак.
> Причём не будет генерить на ходу временный
> исходный файл, а использует стандартный CheckFunctionExists.c.Вот это смешно было :)
Между прочим, я уважаю cmake, и пишу на нём аккуратно, но те задачи, которые должна решать система сборки, cmake делает не очень удобно. Например, глобальный файл config.h, выяснения в какой библиотеке находится некая функция, там нет аналога make distcheck.
>> Причём не будет генерить на ходу временный
>> исходный файл, а использует стандартный CheckFunctionExists.c.
> Вот это смешно было :)Поделись, где ты увидел про лопату? Я б тоже поржал.
> Между прочим, я уважаю cmake, и пишу на нём аккуратно, но те
> задачи, которые должна решать система сборки, cmake делает не очень удобно.
> Например, глобальный файл config.h, выяснения в какой библиотеке находится некая функция,
> там нет аналога make distcheck.Что не так с глобальным config.h? Хочешь — делай его, хочешь — 100500 разных, хочешь — вообще не делай, а определяй макросы через add_definitions().
AC_SEARCH_LIBS заменяется на цикл с CHECK_LIBRARY_EXISTS — не очень удобно, но можно и потерпеть, особенно учитывая, что такие вещи выносятся в отдельные модули для повторного использования, и с высокой вероятностью уже есть готовый.
make distcheck — не шибко часто используемая фича, нужная главным образом для обнаружения ошибок, вызванных кривой архитектурой autotools.
https://www.opennet.me/opennews/art.shtml?num=47031> По сравнению с Autotools время сборки GTK+ сократилось в три раза. На пути к переходу на Meson также находится проект Mesa - сборка Mesa при помощи Meson оказалась в 4 раза быстрее при первом запуске и в 10 раз быстрее при повторном.
Здесь что-то не чисто. Сборка - это вызовы компилятора/компоновщика, время не зависит от "системы сборки".
В случае с autocrap — это ещё и прогон 100500 тестовых компиляций для проверки наличия тех или иных либ, функций, заголовков и т. п.
но автотесты же не должны входить во время сборки...
Должны или не должны... Какая разница, если они входят? Ну, ты попробуй собрать gtk без прогона автотестов и увидишь сам.
> но автотесты же не должны входить во время сборки...Во время сборки не проходят. Проходят во время конфигурации. Тебе ./configure && make запускать доводилось? Загляни как-нибудь в config.log и ужаснись.
Давайте еще говорить, что после перехода с gzip на xz время сборки уменьшилось, так как теперь загрузка быстрее.
> Здесь что-то не чисто.В новости ошибка - там замеры были не на mesa, а на libdrm. Библиотека libdrm небольшая и запуск configure идет дольше сборки. Для больших библиотек типа mesa выигрыш будет максимум 10% (и то, только если сам meson окажется быстрее configure в десять раз).
сравнивают скорее всего
$meson buildir && cd builddir && ninja
c
$./configure && makeпо сути сравнение
make -j1 vs ninja -j$(nproc)
Сравнение времени выполнения meson и configure в большистве случаев бесполезно, т.к. сборка занимает по времени много больше."Корректность" сравнения зашкаливает.
Просто для примера сборка одного проекта.
cmake + ninja 1917.45s user 133.06s system 1013% cpu 3:22.26 total
cmake + make -j$(nproc) 1890.67s user 141.66s system 941% cpu 3:35.91 totalПрофит сомнителен.
> сравнивают скорее всегоНет. Если они и хитрят, то с выбором железа для сборки.
> сборка занимает по времени много больше.
GTK сваян на C. Компиляторы C просто реактивные, по сравнению с некоторыми. При этом, в отличие от configure, процесс собственно компиляции отлично ускоряется увеличением числа ядер. А вот ./configure будет тормозить на 8-ядерном процессоре ровно так же, как он тормозил на одноядерном. Если в проекте несколько скриптов ./configure, то каждый из них будет тормозить, и делать они это будут по-очереди, занимая ровно одно ядро.
Ещё интереснее, когда distcc используешь, чтобы собирать свою генту в офисе, где удалось тихим вечерком два десятка офисных компов в сборочный кластер собрать, чтобы по-бырому раскатать дженту на не очень шустром ноуте. Там этот configure начинает откровенно выбешивать. Вообще складывается ощущение, что вся сборка состоит из бесконечных вызовов ./configure и бесконечных проверок того, что char занимает 1 байт, "может что изменилось с предыдущего раза и char подрос?". Весь этот вывод configure уже заучен наизусть, я его сам могу на клавиатуре набрать с закрытыми глазами, ан нет, автотулзы продолжают долбить в одну и ту же точку.
А, и да, я отмечу, что так бесили они меня более десяти лет назад, и те два десятка офисных компов были селерончиками в которых, если мне память не изменяет, стояли смешные 256Mb оперативки. Что будет сейчас, если это не селерончики, а какие-нибудь двух-четырёх ядерные монстры, я вообще с трудом представляю. Секунд десять думает emerge, потом ещё тридцать секунд configure, после чего пять секунд компиляции, две секунды линковки, и ещё секунд десять на emerge. Что-нибудь в этом стиле. Реально погреться такому кластеру удастся только на всяких там файрфоксах да опенофисах.
> Если в проекте
> несколько скриптов ./configure, то каждый из них будет тормозить, и делать
> они это будут по-очереди, занимая ровно одно ядро.Зависит от проекта. Если в проекте собираются одновременно несколько подпроектов/библиотек, то не кто не запрещает во время компиляции одного запустить configure у другого. AFAIK gcc так и делает.
> бесконечных проверок того, что char
> занимает 1 байт, "может что изменилось с предыдущего раза и char
> подрос?". Весь этот вывод configure уже заучен наизусть, я его сам
> могу на клавиатуре набрать с закрытыми глазами, ан нет, автотулзы продолжают
> долбить в одну и ту же точку.Учить нужно не вывод, а маны :) Я сам так много лет смотрел и думал - сколько можно проверять char? Наконец залез в доки и нашел:
https://www.gnu.org/software/automake/manual/html_node/confi...
https://www.gnu.org/savannah-checkouts/gnu/autoconf/manual/a...
https://www.gnu.org/savannah-checkouts/gnu/autoconf/manual/a...Сделал программу, которая собирает config.cache после сборки. Потом запускаю вторую программу, которая анализирует все имеющиеся config.cache и создает config.site, в который попадают только те переменные, которые имеют одно и тоже значение во всех config.cache.
Тестировал на lfs, но большого выигрыша не увидел (собираю на четырех ядрах). Возможно на blfs выигрыш будут более значимым (особенно на Xorg - там реально в раза два быстрее должно получится).
> Сделал программу, которая собирает config.cache после сборки. Потом запускаю вторую программу, которая анализирует все имеющиеся config.cache и создает config.site, в который попадают только те переменные, которые имеют одно и тоже значение во всех config.cache.И это работает? Ну, в том смысле, что между генерацией config.cache и следующим запуском ./configure произойдёт установка пакета, которая вообще-то может инвалидировать какие-то переменные в этом config.cache. Кстати да, я даже конкретный сценарий могу предложить. Ставим софтину с опциональной зависимостью от gtk. Её configure проверяет наличие gtk, не находит его в системе, вносит в config.cache запись о том, что gtk в системе нет. Ставим gtk. А теперь ставим софтину с жёсткой зависимостью от gtk. Теперь configure заглядывает в config.site, находит, что gtk в системе нету, и отказывается генерировать Makefile.
Другое дело, что может если собрать переменные, которые стопудов никогда не меняются (скажем, относящиеся к проверкам libc и cc) и один раз их сложить в config.site...
Кроме того, тут встаёт проблема, что если я в процессе пересборки системы занимаюсь вознёй с этими кешами, то я встраиваю в процесс пересборки ещё более тормозной этап, нежели ./configure -- себя. Таким образом, чтобы с этого получить хоть какой-нибудь бонус по скорости, надо это всё автоматизировать, а для этого надо лезть в портажи и перелопачивать eclass'ы. В идеальном случае будет достаточно изменить один eclass, но я не верю в идеальные случаи. Скорее всего придётся поменять несколько eclass'ов, и ещё процентов 10 ебилдов всё равно будут всё делать по-своему. То есть, здравый баланс между оптимизмом и пессимизмом предсказывает часов 40-80 на перепиливание портажей. _Моих_ 40-80 часов, а не сборочного кластера. Причём с неопределённым результатом: может быть не удастся сделать так, чтобы config.site не создавал бы помех, и не приходилось бы ещё и вручную периодически вмешиваться, чтобы сборка продолжалась бы.
>> Сделал программу, которая собирает config.cache после сборки. Потом запускаю вторую программу, которая анализирует все имеющиеся config.cache и создает config.site, в который попадают только те переменные, которые имеют одно и тоже значение во всех config.cache.
> И это работает?Собираем всю систему и попутно собираем все config.cache. Генерируем config.site. Повторная сборка системы будет гораздо быстрее.
Но да, все это можно легко сломать.
> Другое дело, что может если собрать переменные, которые стопудов никогда не меняются
> (скажем, относящиеся к проверкам libc и cc) и один раз их
> сложить в config.site...Таких переменных не так уж и много. Выигрыш будет не большой.
Тут нужна методика четко позволяющая отделить переменные и константы для конкретно вашей системы. Есть у меня мысль попробовать исключить все переменные, которые используются менее трех раз.
Но в итоге и встает вопрос, а стоит ли оно того?
> Таким образом, чтобы с этого получить хоть какой-нибудь бонус по скорости, надо это всё автоматизировать, а для этого надо лезть в портажи и перелопачивать eclass'ы.
У меня своя система сборки. На все правки, включая написание программ для сборки и обработки config.cache ушло 3-4 часа.
Но как я сказал, выигрыш не велик, а вероятность получить проблемы после очередных изменений в системе далеко не нулевая.
С другой стороны, если появилась проблема - отключаем config.site и собираем как обычно. Вроде ничего сложного.
Вообще нужно поработать с этим какое-то время, чтобы набрать некоторую статистику по отказам.
> У меня своя система сборки. На все правки, включая написание программ для
> сборки и обработки config.cache ушло 3-4 часа.Поддержание своей системы сборки будет требовать гораздо больше времени. Все эти задачи связанные с обсчётом депендансов, выкачиванием сорцов нужных версий из нужных мест по нужным протоколам, обходом всех специальных случаев... В gentoo это решается написанием ебилда на каждый пакет. Но, вот, допустим, я пользуюсь оверлеем rust, чтобы иметь в системе расты разных версий, причём хоть самых-самых nightly. Иногда это требует правки ебилдов. Но мне приходилось отказываться от внесения каких-то изменений, потому что это были изменения, которые не примут в "апстрим", а самостоятельно поддерживать эти изменения я не готов совершенно. Внести и отправить пулл-реквест -- легко: поигрался с ebuild, выполняя работу emerge поэтапно, создал патч, оттестил его, отправил и забыл. А вот следить за актуальностью моего форка оверлея -- не, спасибо, вот заняться мне больше нечем. Если что, я могу и потерпеть пару месяцев, а там проблема тем или иным способом разрешится.
> С другой стороны, если появилась проблема - отключаем config.site и собираем как
> обычно. Вроде ничего сложного.Я в генту последнее время избегаю использовать keyword'ы типа ~amd64, потому что практика показывает, что эти флаги накапливаются в /etc/portage, и лет через десять это кончается тем, что либо emerge не может обсчитать зависимости, либо сборка внезапно обламывается в какой-то момент, и если месяц не обновлял мир, то потом такое обновление займёт пару часов (моего времени, не процессорного) в то, чтобы найти причины отказов и устранить их. И хорошо, если все эти причины выявятся на этапе обсчёта депендансов, а не начнут выскакивать в рандомные моменты сборки, в течение нескольких часов работы emerge. В общем, приемлимый для меня компромисс между надёжностью и конфигурабельностью со временем смещается в сторону надёжности.
Тем более надёжность важна, если мы создаём не наколенное решение для применения на локалхосте, а вполне себе системное решение, у которого будут сотни и тысячи пользователей.
Если мы попытаемся этот config.site впилить, например, в emerge и дополнить этим костылём с рестартом сборки, то встанет вопрос: как мы можем выяснить программно, что сборка обломалась из-за косяков с config.site? Или после каждого облома мы на всякий случай будем удалять config.site и делать рестарт -- а вдруг прокатит?
> Но как я сказал, выигрыш не велик, а вероятность получить проблемы после очередных изменений в системе далеко не нулевая.
Да, на самом деле эта вероятность получить проблемы и есть основная претензия к autotools.
autotools -- это такое хакерское решение: минимумом усилий максимум результата. Но *nix в своём развитии ушёл за границы возможного для autotools, требования изменились. Изменилась и среда: сегодня нет необходимости тщательно проверять компиляторы C, потому что времена, когда каждый компилятор C имел свои собственные нюансы реализации, ушли в прошлое (почему C не считался кроссплатформенным языком в 80-е, да и в 90-е в общем-то? Как раз потому, что написать код, который скомпилируется двумя разными компиляторами и будет при этом работать как надо -- это был высший пилотаж программирования на C). Потому что есть стандарты и не только на компиляторы, но и на libc и на многое другое. Потому что есть pkg-config, который легко можно использовать непосредственно из makefile'а, проверяя наличие библиотек и их версии. Потому, что есть github, где очень легко отправлять pull-реквесты, получать их, создавать issues, обсуждать их, и находить решения: сегодня если софтина не собирается на какой-то особо хитрой конфигурации, то этим проблемам несложно найти решение и без autotools. Тем более, что autotools не решает этих проблем: configure в лучшем случае, поможет диагностировать эти проблемы. Потому, наконец, что сегодня из сорцов собирают только те, кому это интересно и кто готов разбираться в чём проблема, а не любой пользователь *nix, и просто потому, что других способов поставить софт не существует. А тем, кому интересно собирать софт из сорцов, совсем не обязательно иметь configure для того, чтобы делать сообщения об ошибках более информативными.
Если комментаторы опеннета в большинстве своём и выступают против замены autotools на что-то ещё, то это их "старпёрский bias" -- опеннетовское когнитивное искажение, вызванное тем, что каждому опеннетовцу хочется выглядеть старпёром, а лучший способ выглядеть старпёром -- всегда выступать в пользу музейного софта и всегда против всего нового.
>> У меня своя система сборки. На все правки, включая написание программ для
>> сборки и обработки config.cache ушло 3-4 часа.
> Поддержание своей системы сборки будет требовать гораздо больше времени.На самом деле - не факт. Все зависит от задач. Если вы постоянно (ежедневно) меняете набор приложений - то да, лучше использовать готовый дистрибутив. Если набор приложений относительно стабилен - то затраты по времени не большие.
Вы хорошо озвучили проблемы gentoo:
1. Глубокая модификация требует больших затрат по времени.
40-80 часов для задачи, которая в моем случае отняла 3-4 часа (да и то, если бы я сам не писал программы для этой задачи, то правки/тест сборочной системы отняли бы менее 30 минут).У меня в год на систему уходит 40-80 часов, да и то, только если я провожу эксперименты вроде обсуждаемого.
2. Поддержка своих изменений. Чем их больше, тем сложнее поддерживать. В итоге от них приходится отказываться.
У меня есть похожая проблема, но на другом уровне: я часто модифицирую софт под свои нужды и большинство патчей не пойдут в апстрим. Их приходится поддерживать, что и отнимает основное время при возне с системой.
> Если мы попытаемся этот config.site впилить, например, в emerge и дополнить этим
> костылём с рестартом сборки, то встанет вопрос: как мы можем выяснить
> программно, что сборка обломалась из-за косяков с config.site? Или после каждого
> облома мы на всякий случай будем удалять config.site и делать рестарт
> -- а вдруг прокатит?Как вариант. Можно еще научить систему составлять список таких случаев и сохранять логи неудачной и удачной сборки (или сразу делать с них diff) для быстрого разбора проблемы.
> Потому что есть pkg-config, который легко
> можно использовать непосредственно из makefile'а, проверяя наличие библиотек и их версии.Совершенно верно!
> Если комментаторы опеннета в большинстве своём и выступают против замены autotools на
> что-то ещё, то это их "старпёрский bias" -- опеннетовское когнитивное искажение,
> вызванное тем, что каждому опеннетовцу хочется выглядеть старпёром, а лучший способ
> выглядеть старпёром -- всегда выступать в пользу музейного софта и всегда
> против всего нового.Тут не соглашусь. autotools давно пора выкинуть, но:
1. Зачем писать новые системы сборки, когда для 95% проектов достаточно make + pkg-config? Зачем генерировать майкфайлы, неужели нельзя сделать их статичными, а все переменные собрать в одном файле?
2. Если уж хочется написать новую систему сборки, зачем делать хуже, чем было? Один синтаксис управления cmake чего стоит: -DCMAKE_INSTALL_PREFIX=/usr против --prefix=/usr.
3. Если проект большой - сделайте свою компактную систему сборки и встройте ее в проект, типа как в AOSP, а не заставляйте тянуть и собирать кучу зависимостей.
> Весь этот вывод configure уже заучен наизусть, я его сам могу на клавиатуре набрать с закрытыми глазами, ан нет, автотулзы продолжают долбить в одну и ту же точку.Во-первых, у configure есть кеш, см. (./configure --help); во-вторых, даже если автор не предусмотрел (--enable-foo/--with-bar), любую закорюку/переменную можно переопределить в командной строке, так что configure будет думать, что проверка сделана и результат взят из кэша. Например, моэно убедить configure, что заголовок sys/wtf.h существует, и т. д.
Такие дела :)
>> Весь этот вывод configure уже заучен наизусть, я его сам могу на клавиатуре набрать с закрытыми глазами, ан нет, автотулзы продолжают долбить в одну и ту же точку.
> Во-первых, у configure есть кеш, см. (./configure --help); во-вторых, даже если автор
> не предусмотрел (--enable-foo/--with-bar), любую закорюку/переменную можно переопределить
> в командной строке, так что configure будет думать, что проверка сделана
> и результат взят из кэша. Например, моэно убедить configure, что заголовок
> sys/wtf.h существует, и т. д.Если я вожусь с командной строкой, то тормоза вносимые моими кривыми пальчиками и процессом мышления гораздо выше, чем тормоза ./configure. Это значит, что я только что сделал wget, потом tar jxf, вот сейчас делаю ./configure, потом буду делать make, потом искать способа потестировать работает ли без установки, потом решать, что делать с результатом -- вкатать в /usr/local при помощи make install, поставить в ~/local, поставить при помощи INSTALL_ROOT в /tmp, а потом вспоминать, читая man'ы и сорцы, как теперь всё это ebuild'ом раскатать в /usr, чтобы потом можно было бы удалить при помощи emerge... Короче эта история надолго. И в этой истории пара-тройка выполнений ./configure, пока я собираю все опции для него, которые я хотел бы ему передать, -- это вообще ни о чём.
> стабильный и поддерживаемый в течение нескольких лет APIНескольких — это двух-трёх? Потом всё равно переписывать?
>Прекращение поддержки сборочной системы на базе autotools в пользу инструментария MesonА патриарх СПО это одобрил? Или Gtk 4 не является частью проекта GNU?
Красношапка одобрила. Кто платит, тот и одобряет.
Хотя вон и в GNU awk запилили cmake. Может стало-таки доходить и до них, насколько autocrap ужасен.
Какая великая сила денег заставляет клепать такие жуткие дефолтовые темы?
Наверное, полное отсутствие этой силы.
А вот фиг, без денег школьники на гномелуке клепают красивые темы, а дефолтом какая-то страхолюдина на скринах всю дорогу
Кстати, да. Темы Gtk3 - это какой-то туманный образ нормальных мыслеформ после похмелюги.
Так попробуй на трезвую голову осмыслить.
Ни разу не видел его трезвым с 2008-го.
Из-за идиотских скроллбаров и микроскопических подвижных границ разделения панелей браузера (Caja), в которые не так просто попасть "наощупь" мышкой, минут пять пытался отсоединить флэшку, так как её значок оказался в самом низу дерева папок браузера и загораживался внезапно возникающими скроллбарами. Доколе такое издевательство будет продолжаться?
Так не ной здесь, а напиши в багтрекер Caja.
Тут общая концепция в тулките такая, а не конкретный файл-менеджер: появляющиеся/исчезающие скроллбары загораживают часть области, на чем они как бы присутствуют. Так, что объекты, хоть и видны, но ими невозможно манипулировать - ни взяться мышкой за них, ни ещё что-либо с ними сделать, хотя курсор мыши находится прямо над ними - мешают скроллбары.
> Тут общая концепция в тулките такая, а не конкретный файл-менеджер: появляющиеся/исчезающие
> скроллбары загораживают часть области, на чем они как бы присутствуют. Так,
> что объекты, хоть и видны, но ими невозможно манипулировать - ни
> взяться мышкой за них, ни ещё что-либо с ними сделать, хотя
> курсор мыши находится прямо над ними - мешают скроллбары.В Nautilus почему-то такой проблемы нет.
наверняка это можно настроить через css стили или ещё как. А вот, как (в генте себе так сделал)/etc/environment:GTK_OVERLAY_SCROLLING=0
долгое время пытаюсь понять. Кто-то вообще пишет что-то на GTK в рабочее время ??
> долгое время пытаюсь понять. Кто-то вообще пишет что-то на GTK в рабочее
> время ??Да. Сотрудники RedHat.
Да. Ниже то, что смог вспомнить.Из минусов.
1. Нет обработки ошибок выделения памяти, поэтому в embedded многие вещи уже не реализуешь, как например, уменьшение кешей в других процессах при нехватке памяти. Но частично решаемо.
2. Завязка на работу с обычными строками там, где мы можем передавать массив символов и его размер (производительность).
3. Профилирование как-то выдало узкое место в самом неожиданном месте... в приведении типов виджетов. А там это частое явление, если делать всё по правилам.
4. Крайне сложно читать их исходники, т. к. многие заголовочные файлы генерируются автоматически при компиляции. А нужно просто посмотреть как сделано, не компилировать. Ну и объявление функций через макросы аля G_DEFINE_WITH_PRIVATE.
5. Очень много глюков от версии к версии. И они не исчезают в новых версиях, а появляются новые.
6. В этом самом стабильном 3.22 выпилили произвольные CSS-свойства. Мы не смогли найти, как в наших виджетах заставить их снова работать, приходится изворачиваться.
7. Вызывание родительских функций у наследника. Префикс названий разный, могли бы и задефайнить с приведением типов.
8. Glade содержит много ошибок и раньше очень часто падал, сейчас реже.Из плюсов:
1. Прозрачность, т. к. язык Си.
2. Полноценное наследование с виртуальными методами.
3. Есть и резиновый интерфейс, и стандартный набор виджетов.
4. Работает на слабом железе достаточно шустро, если грамотно писать код. Для нас большой плюс.
5. Очень хорошо продуманные наименования в API. Всё систематизировано. Это очень важно в больших проектах. Хорош для обучения новичков, - пока они пишут виджеты, не получится не соблюдать стилистику.
6. GObject Introspection. Кто знает, поймёт все преимущества.
7. Т. к. нет полноценной обработки ошибок, то и нам самим достаточно вставлять обычные assert'ы в GUI.
8. В GLib встроено много того, чего недостаёт в стандартной библиотеке. Например, g_path_get_basename. Если кто-то сталкивался с basename поймёт все те проблемы, которые идут от basename+dirname при использовании GNU-расширений.
> 3. Профилирование как-то выдало узкое место в самом неожиданном месте... в приведении типов виджетов. А там это частое явление, если делать всё по правилам.ЭЭ они же просто указатели всегда, разве нет?
Раскройте макрос GTK_LABEL(label), будете удивлены. :) Там встроено самотестирование. Выполняется функция g_type_check_instance:
https://github.com/GNOME/glib/blob/master/gobject/gtype.h
https://github.com/GNOME/glib/blob/master/gobject/gtype.cМожно, конечно делать явное приведение типов, но самотестирование имеет свои плюсы. Тем более, что грамотный подход позволяет снизить до минимум накладные расходы. Ну и стараемся соблюдать стилистику GTK.
> Прекращение поддержки сборочной системы на базе autotools в пользу инструментария Meson;Надеялся, что meson будет параллельно работать. Облом.
> В GtkEntry добавлен виджет для выбора Emoji. Также добавлены хинты для ввода Emoji с клавиатуры;
2017-ый год. Элементарнейшее undo (ctrl-z) не работает. Зато Emoji!
> GtkLabel и GtkEntry переведены на использование GSK (GTK Scene Kit), обеспечивающего отрисовку графических сцен через OpenGL и Vulkan;GtkLabel и GtkEntry переведены на использование GSK (GTK Scene Kit), обеспечивающего отрисовку графических сцен через OpenGL и Vulkan;Означает ли это что анимации будет отрсовывать не проц а видеокарта и гном перестанет лагать?
