Текущие мэйнтейнеры пакетов с фреймворком Qt в Debian приняли решение своими силами не обеспечивать сопровождение следующей значительной ветки Qt 6, релиз которой запланирован на декабрь. При этом сопровождение прошлой ветки Qt 5 будет продолжено без изменений. Поставка Qt 6 в Debian будет обеспечена если найдутся новые сопровождающие, готовые на должном уровне обеспечить поддержку пакетов с новой веткой...Подробнее: https://www.opennet.ru/opennews/art.shtml?num=53568
О,я могу помочь!
Только я пока программировать не умею. Но ничего.
А программировать уметь и не надо. Но md-формат, кстати, придется освоить.
Так это тебе в мозиллу нужно идти, тебя там с радостью возьмут и будут платить сотни денег.
Мозилла сокращает персонал.
Сокращает персонал айтишников, эффективные менеджеры и люди, которые не умеют программирование там еще нужны
Так может предоставишь пруф своим словам в виде свежей вакансии?
тебя на опеннете что ли забанили?!
> Так может предоставишь пруф своим словам в виде свежей вакансии?Могу предоставить огроменную такую табличку с надписью "сарказм".
Кто-то спутал мозиллу с майкрософт. Ведь людей (и не только, животных тоже), которые не умеют программировать с радостью берут именно туда.
Так ведь немудрено спутать. mdn, msdn - попробуй отличи, да еще кнопки sd рядом, можно случайно нажать.
Ты главное побольше вопросов в irс задавай. Желательно, составленных искуственным интеллектом.
Вопросов о гендерном и расовом разнообразии?
Извините, у вас опечатка. О рассовом и гендерном говнообразии. У меня в голове не укладывается почему расисты орущие о необходимости преференций для небелых за безусловно бывшее когда-то рабство и для других всяческих. Когда произошло то переломное событие при котором программирование из академической науки превратилось в сборище фриков?
> Когда произошло
> то переломное событие при котором программирование из академической науки превратилось
> в сборище фриков?Видимо, когда все стали слишком чувствительными и стали задавать себе вопросы:
1. "а насколько это плохо, что у нас в команде нет чёрных и женщин?"
2. "не может ли кто-то обидеться на название функции / переменной и т.п.?"Правильные ответы должны быть:
1. Нет, это не плохо и никого это не должно волновать. Если всё работает идеально, какая разница, человек какого цвета / пола / сексуальной ориентации это делал? Именно тот, кого волнует состав исполнителей в первую очередь (а не качество продукта) и есть настоящий расист и сексист.
2. Если кто-то хочет обидеться и быть обиженным - он найдёт на что. Хочет обижаться на то, что ночь тёмная, а день светлый - пусть хоть с утра до вечера ноет. Собаки лают - караван идёт.Но почему-то сложилось несколько иначе.
Интересно, вот те SJW, кто усиленно педалирует разнообразие, если будет выбор перед ними - установить кардиостимулятор, в создании которого не участвовало достаточное количество чёрных и женщин (например), или же умереть за идею, к какому варианту они будут склоняться в большинстве? Таки что-то мне подсказывает, что это не второй будет.
>Когда произошлоThere is some sort of perverse pleasure in knowing that it's basically impossible to send a piece of hate mail through the Internet without its being touched by a gay program. That's kind of funny
Олман Эрик, 1998 год.
Короче в опенсурсе это кажись у истоков
И таки хде тот пошлипочт теперь?
Помоги финансово
Им уже помогали, но бабки все на привлечение женщин спустили. Debian Women Project давно у них. Вот теперь имеем результат.
Пусть теперь сами себя финансируют.
Не переживай, программировать и не нужно уметь, главное смузи хлебать не забывай..
> В вашей деревне искаженное представление об ITшниках.
> В моей реальности больше пивасик попивают и катаются на электросамокатах.Все правильно - в твоей деревне, как и везде, старики одни остались. С гироскутером не в ладах, только на самокате еще как-то.
И ты, дед, перебирайся уже в город. Смузи пить научишься не закусывая, бороденку в барбершопе завьют и отбелят, седина не будет видна!
А там, глядишь, программировать на markdown начнешь...
Фрактал им в помощь!
Печально. Хотя вон у Neptune, Netrunner и пр. есть время и ресурсы. Эх, объединить бы как-то их усилия...
В мире альтернативно ориентированных это невозможно. Каждый начинает копать себе свою песочницу, ибо чужой код обладает фатальным недостатком: "его писали не мы". Вот поэтому как тараканы плодятся версии Qt, вылупились системда, вейленды... А софта как не было, так и нет. А что есть - это наследие прошлого, которое стараются выбросить и написать вместо него ещё одну версию Qt.
А что не так с кутями? Емнип, там в 5 совместимость со 2 версией (и с минимальными затратами такой код портируется). Как и остальное. Перепутали видимо с гтк и гномом. Если бы вы использовали старые версии тулкитов, и новые версии тулкитов, такой дичи бы не сообщали (скорее всего).
> в 5 совместимость со 2 версиейОчень интересно, продолжай рассказывать сказки.
Ой, да ладно. Это "совместимость", конечно, и с небольшими костылями (штатными), но факт остаётся -- по принципу гтк там ничего не переписывали. Только выкидывали целиком, да, но если говорить о qtcore это так, а настоящая совместимость там на -2 версии. Но такой код будет не очень хороший. Какие могут быть сомнения? Там по 20 лет тащат legacy/deprecated как намёк на то, что пора бы и переписать.
Пакетные менеджеры - основной минус линукса и одна из основных причин его непопулярности.
Почему - читайте новость.
Собственно, вся суть идеи пакетных менеджеров и их мейнтейнеров.
Поддерживать пакеты должны разработчики.
Некоторые не понимают, что дистрибутив - это не просто куча пакетов. Нет никакого смысла в "поддержке" приложения без учёта инфраструктуры вокруг негою
Смотрит на Арч: йой, най буде.
Наплодили 100500 дистрибутивов Поповы, а поддерживать этот зоопарк должны разработчики. Это ты хорошо придумал.
В целом есть стандарт куда класть файлы, а остальное должен обеспечивать дистрибутив.
Я думаю, что должен быть какой-то универсальный API для пакетов, но тогда непонятно
нахрена нужны все разновижности систем поставки.
От разработчика нужно exe deb rpm appimage на гитхабе и исходники для сборщиков дистр-ов, тогда будет выбор новенькое или протестированное поставить
Вот Qt Company и поддерживает. За деньги.
Чуть собачья. Дебьян давно загибаться начал, как приняли s-d и из совета директоров начались массовые увольнения. Прекращение поддержки Qt просто ещё один гвозь в крышку гроба дебьяна.
Все загибается и загибается. Никак не загнется только почему-то. Как сидел на нем, так и сижу, никаких проблем.
Да, я тоже вон 6-й запустил, тоже никаких проблем. Работает, грузится. Когда же он загнётся?
Так и не так давно он полетел под откос, ну вот примерно с распространением убанты и понеслось. Любые монструозные образования умирают очень долго: любители погреть ручки будут пинать до последнего, а потом ещё оживят и продолжат пинать.
> ну вот примерно с распространением убанты и понеслосьда никуда ничего не понеслось. Вполне себе сосуществуют. Для хомячков - убунта, для нормальных людей - деб.
Уже давно дебиан паразитирует на убанте, а не наоборот. Это ли не показатель? Про хомячков достаточно прохладно, любой выберет продукт который хотя бы между релизами не делает мозги, и чем меньше возни, тем лучше. Из альтернатив этому только роллинг.
Что-то я без всякой возни с 9 на 10 обновился... Наверно, что-то не так сделал.
Только вот у Ubuntu есть PPA, в котором есть куча доп. пакетов.
Как же ж я живу-то на Дебе без этих PPA, непонятно кем собранных. И без Каноникла с Шаттлвротом, у которых то юнити, то мир, то еще какая-нибудь фигня, то они амазоны с мордокнигами в дистриб пихают...
А куда в демьяне PPA делся то?
> Пакетные менеджеры - основной минус линуксаКонечно, гораздо удобнее искать крякнутый софт по всему Интернету.
Как будто крякнутый софт чем-то отличается от софта из левых реп. Хотя да, конечно же, отличается (;
У дистрибутива нет левых реп, их использует пользователь на свой страх и риск, это не обязательно.
Ну так и кряковарез пользователь ставит на свой страх и риск. А как в линуксе "не обязательно" - это ты расскажи центосникам, сусечникам, бубунтоводам, а то мужики-то и не знали, что подключать репы - не обязательно.
У Росы нет левых реп.
А кто-то заставляет всякую какашку в систему тащить? А в винде без этого не выживешь. Нужен графический редактор - лезешь на торренты, нужен матпакет - лезешь на торренты. Да за всем лезешь на торренты, чего в саму винду мелкомягкие положить не догадались.
Что значит "не выживешь"? Купил софт, поставил - он работает. Вне зависимости от того, 10-ка стоит на компе или 7-ка. Вот что значит грамотный дизайн. А не как у некоторых, три года прошло - всё, у нас новый дистр, новые либы, конпелюуйте заново.
Ну купи Фотошоп или Матлаб. Ценник-то видел?
Переехал из РФ в цивилизацию, пришлось забыть про торренты. Три года полет нормальный, все стоит лицензионное и стоит копейки.ОЕМ ключ от десятки стоит на ебее 4 бакса, все проверки проходит, в мс стор пускает.
Фотошоп+лайтрум подписка стоит 5 баксов в месяц. На фоне айти зарплат в 10k$+ это просто жалкий чих.
Игры все из стима тоже нельзя сказать что дорого раз в месяц купить парочку в сумме баксов на сто.
Подписка на нетфликс тоже пять баксов в месяц. А это анлим сериалы и фильмы, по трекерам искать не надо.
Итого домашний комп чистый, все лицензионное, никаких кряков и троянов, линукс смысла не имеет.
А, ну тогда мы закрываем РФ и едем к вам.
И да, Линукс все-таки смысл имеет, поскольку винда - кривая, тормозная, неудобная и дырявая поделка, которую после XP можно отправить на свалку истории. В игры играть пойдет, но и только, работать в ней невозможно.
На фоне аренды маленькой комнатушки, вы хотели сказать.
Зато этот софт хотя бы последней версии. А в Linux если хочешь что-то поновее мамонтовых окаменелостей, что лежат в репе, то будь добр перетряхнуть весь Github в поисках исходников. А потом потратить пару вечеров, чтоб суметь это собрать. А если нужно пересобрать что-то крупное вроде того же Qt, так беги в магазин за нормальной машиной, хотя бы 16Гб памяти чтоб было и подходящий проц.
> А в Linux если хочешь что-то поновееВы не единственный человек в мире которому понадобилась эта новая версия, неужели вы правда думаете что ни в одном дистрибутиве не придумали решения этой проблемы?
> Вы не единственный человек в мире которому понадобилась эта новая версия, неужели вы правда думаете что ни в одном дистрибутиве не придумали решения этой проблемы?Вероятно, человек просто не слышал о таких вещах, как:
- бэкпорты
- репозитории разработчиков
- контейнеры
- дистрибутивы с роллинг-релизом
Решение проблемы одно:> Qt имеет очень большой объём кода, для сопровождения которого требуется много ... <выделено жирным> ресурсов для сборки</выделено жирным>
Теперь простым русским языком: у Дебиана стало не хватать денег, чтобы заплатить за сборку раздутых пакетов. Потому что бинарные пакеты все любят, а платить за их сборку никто не любит и не все это могут себе позволить.
Раздутых пакетов умышленно раздуваемых разрабами - потому что иначе их компания будет не нужна - можно и старыми сборками довольствоваться до конца вселенной, только пересобирать их за счёт дебиана. Кто в здравом уме будет платить Qt Company за бинарные сборки Qt, если каждый сможет их сделать сам или скачать у Дебиана? А если допустим смогут, то Qt Company умрёт, а с ней и Qt умрёт. Она ведь не от хорошей жизни непопулярные шаги делает. Видимо Qt 6 получился очень жирным и сложным и будет ей дорого обходиться, но иного пути развития для проекта нет.
Аналогично с телефонами. Если каждый сможет собрать для своего телефона сборку прошивки, или хотя бы скачать её, то компании просто уйдут с этой операционной системы туда, где им дают больше контроля над пользователями. Новых телефонов под неё не будет и она умрёт.
Обобщаю: СПО не может решить проблему того, что проекту нужны деньги на развитие в условиях, когда никто не хочет платить. Поэтому все проекты, перешагнувшие их предел затрат на разработку, уходят от СПО в проприетарь. На проприетарь хотя-бы лицензии продавать можно.
Человек высше не знает и не понимает, что теперь есть Flatpack, Snap, AppImage, которые позволяют использовать софт самых свежих версий и необходимость пересобирать или подключать сторонние репозитории почти отпала. Например, вот помню, когда вышел LibreOffice 7.0, так на второй день после релиза он тихо обновился в фоне и работаешь.
Ну да, лишние небезопасные прослойки жрущие память, спасибо, не нужно
> А в Linux если хочешь что-то поновее мамонтовых окаменелостей, что лежат в репе, то будь добр перетряхнуть весь Github в поисках исходниковНу да... А можно просто использовать Арч, где всё новое. А если чего-то не хватает, есть AUR.
В этом году в школу первого сентября идёте?
Для начала: а зачем вам софт самой наипоследнейшей версии? У меня в дебе стоит FF 68 и норм, ядро 4.9, emacs 26... Можно юзать unstable, но зачем, если и так все работает.
Когда-то тоже гонялся за свежатинкой, потом повзрослел и пришло понимание, что лишнее это все, если и так работает.
>ядро 4.9А чё не 2.6.27?
4.9 LTS, до сих пор обновляется и еще пару лет будет.
А в чем собственно проблема? 4.9 - одна из актуальных веток ядра - https://www.kernel.org/
Анон уважать не будет
А чтоб ты спросил
>искать крякнутый софт по всему Интернету.Не напоминая мне моё виндоюзерское прошлое. Аж чуть тошно не стало.
Пакетные менеджеры - это очень хорошая идея. Централизованный проверенный источник приложений. Главным недостатком линукса есть его зоопарк, каждый дистрибутив вынужден пилить свои репозитории своими силами. В итоге получаем, что в разных дистрах пакеты разные, по-разному собраны, разных версий. Софт-то есть, но его пакета под отдельно взятый дистрибутив может и не быть. Сейчас дальше всех убежала Canonical со своим snap. Они и первые сделают из него коммерческую площадку и начнут деньги получить с его помощью, даже комиссию введут в 29%(ну не 30% же, это ж не гугл). К сожалению, будущее за этим. Стандартные пакетные менеджеры будут, но всё больше юзеров с течением времени перейдет на иные способы получения ПО, вроде snap или даже может быть(если ну очень всё хорошо будет(хотя слабо верится(очень слабо(крайне слабо)))) flatpak.
> Пакетные менеджеры - это очень хорошая идеяТам надо было добавить "в текущем виде", мой провтык. В целом да, это хорошая идея, если бы была хорошая реализация.
> Сейчас дальше всех убежала Canonical со своим snap
И снап, и флат пока оочень далеки до идеала
Хотелось бы что-то похожее на карго (жонглирование с разными версиями зависимостей, например), и чтоб было дефолтом в дистрах как Пёттеринг
А в Каноникал после провала Юнити 8 уже не верится. Они опоздали быть истинным дефолтом, да и слишком слабы для этого, при всем уважении> даже комиссию введут в 29%
Не думаю, что они станут тем дефолтом, который сможет это сделать.
И флат тоже не станет, по крайней мере в текущем виде
Flatpak - это провал, имхо. Идея хорошая, но реализация как всегда. Снап тоже говнище. Но! Canonical предусмотрительно не введа поддержку сторонних репозиториев для snap, соответственно имеем ОДИН репозиторий ПОЛНОСТЬЮ контролируемый Canonical. Что это значит? А это значит то, что после достижение критической массы, т.е. после того, как snap станет реально популярным и востребованным среди разработчиков - опа, тут же будем видеть небольшие, но всё-таки изминения условий, ужесточение правил, комиссия и т.п. Но при этом, есть все шансы, что благодаря snap и Canonical Linux наконец станет коммерчески интересен производителям десктопного софта. Сейчас же, делать коммерческий софт под линуксы просто анриал сложно. Непонятно под какой дистрибутив его делать, непонятно как его распространять, непонятно как тестировать. Вариант вроде собрать .deb или .rpm сомнительный, учесть весь зоопарк нереально, а держать штат мейнтейнеров под все популярные дистрибутивы - бред же.Во многом, из-за проблемы дистрибьюции софта, десктопный линукс мертв. То, что мы ставим на десктопы, это совсем не тот уровень. Мне тяжело это признавать, но мы все должны что-то с этим делать. Комьюнити не в состоянии поддерживать и оперировать столь сложными процессами. Этим должна заниматься крупная коммерческая компания, которой ну очень интересно чтобы ИХ линукс стал той самой 3-й ос, о совместимости с которой будут кричать разрабы какого-нибуть проф. софта.
>Вариант вроде собрать .deb или .rpm сомнительный, учесть весь зоопарк нереально, а держать штат мейнтейнеров под все популярные дистрибутивы - бред жеБред это как раз snap. А адекват: rpm+deb.
Замечательная аргументация, держи в курсе.
> коммерческий софтДля коммерческого софта есть windows, в linux он не нужен, а тому кому нужен — собрать под любой дистрибутив не проблема, у них целые отделы для этого.
>Непонятно под какой дистрибутив его делатьОбычно исключительно под убунту пакеты и делают. То что они встают на дебиан - это side effect.
Canonical движется по пути Google Store, где вирусы и половина программ не работают или глючат
А нужно ли это? Меня, например, устраивает, что есть куча разнородных дистрибутивов, всяких несовместимостей, различных репозиториев и неумелых разработчиков очередных проигрывателей, нравится эта движуха. Не будет Qt6 в Debian, отлично опять новость и обсуждение на OpenNET, иначе будет скучно как в могиле и только искусственные новости от маркетологов.А так, просто покупаешь железо совместимое с Linux (яблочники ведь так и делают). Компиляторы есть, IDE есть, редакторы есть, офисные пакеты есть, игры, чёрд возьми, есть.
В конце концов централизация - это в конечном счёте коррупция, спекуляция и заболачивание.
> всё больше юзеров с течением времени перейдет на иные способы получения ПО, вроде snap или даже может быть(если ну очень всё хорошо будет(хотя слабо верится(очень слабо(крайне слабо)))) flatpak.И зацветёт тогда в Linux вирусня.
Наличие вирусов - следствие популярности ОС. Пакетный менеджер может минимально защитить, модераторы могут софт проверять, но вирусы однозначно будут, если линь на декстопах таки когда-нибудь стрельнет.
Ваши заявления абсолютно голословны. С таким же успехом можно написать что наличие вирусов - следствие архитектуры и традиционного использования ОС. Пакетный менеджер гарантирует что пакет это именно тот бинарник что собрал майнтейнер, что прежде чем попасть в stable софт прошёл ревью и тестовую эксплуатацию у пользователей и вирусов однозначно в нём нет.
> Пакетный менеджер гарантируетЭто не заслуга пакетного менеджера, а заслуга организации всего этого.
Если мейнтейнеры плохие, ленивые, или неквалифицированные, то тут привет.
Тоже самое и с Windows — можно сделать первоклассный Windows Store с качественным и проверенным софтом.
Тоже самое и с линуксами. Что касается около серверного, то хорошо вылизано, к ближе десктопу хуже.
В каком там софте тысячи глаз проглядели тайм бомбу «плюнь на устаревший софт в репах!»?
>что прежде чем попасть в stable софт прошёл ревьюА где гарантия что reviewer компетентен?
> Сейчас дальше всех убежала Canonical со своим snap. Они и первые сделают из него коммерческую площадку и начнут деньги получить с его помощью, даже комиссию введут в 29%(ну не 30% же, это ж не гугл). К сожалению, будущее за этим.Говоришь как будто что-то плохое.
Вряд ли... Canonical сдался на тему десктопов.Раньше у них чего только не было, в том числе в 2010-ых где-то магазин с платными Приложениями. Магазин музыки. Облачное хранилище...
А сейчас ничего этого нет.
нет, основной минус линукса это отсутствие виндовых игр и прог.м
А ничего, что они на винище порой идут, когда на винде нет?
Хахах, наивные. Так они банально платить не пробовали? Деньги с донатов плюс всегда можно нагнуть каноникал.Рекомпиляция 100500 qtшных пакетов, с которых половина тупо зафейлится - удовольствие куда ниже среднего. Разве что нанять пару студентов которые будут затpахиваться с этим вместо реального секаса.
Что конкретно зафейлится? Собрать Qt из исходников довольно тривиальная задача.Вопрос только в том, зачем рекомпилировать, если есть официальные готовые бинарники, которые просто работают.
После 5.14.2 нет.
Под все архитектуры? И как без сборки проверить воспроизводимость сборки, хоть на том же ч86_64?
Ну извините, кого интересует воспроизводимость сборки -- того для начала сборка волновать и должна. Хотя есть, конечно, одни дармоеды тут...
> Вопрос только в том, зачем рекомпилировать, если есть официальные готовые бинарники, которые просто работают.Вы, похоже, не совсем понимаете, для чего нужны дистрибутивы
Как раз тут очевидно. Для поднятия эго их сборщиков.
Приятно собирать чужое и выкладывать под своим именем, по себе знаю
Денис, ну, право, сколько можно!
> Собрать Qt из исходников довольно тривиальная задача.QT3+GCC7 = пару сотен исправлений. большинство из которых - седом. Было нужно некое старье поддерживать до позапрошлого года... Для меня это оказалось тривиальным на вторую неделю, чо.
Копатели в старье должны страдать, тут всё просто.
Речь о Qt 5.15 и Clang 10 / GCC 10.
Вы в курсе, сколько bundled-зависимостей у Qt, которые в любой приличной ОС развязывают — и почему это нужно? Вы в курсе проблем вида «foo зависит от bar>=2.0, buz собирается только с bar<2.0»? Вы в курсе, что с каждым релизом Qt что-то перестаёт с ним собираться, а с мажорным, где заметно ломают обратную совместимость, проблем будет вагон и маленькая тележка? Вы никогда не чинили Qt-шные сборочные скрипты? А тесты после сборки не забываете прогонять?Вопросы риторические.
> Вы в курсе, что с каждым релизом Qt что-то перестаёт с ним собиратьсяЗначит, не только у GTK проблемы. Да и значительные проблемы появились только с темами в 3.x. А сборка в пределах одной серии версий (2.x, 3.x) поддерживается, хоть потихоньку и захламляется сообщениями "deprecated".
А выложите, кстати. Так-то альтовский пакет qt3 собирается gcc9, если кому понадобится.
Иные пакеты, использующие Qt, зафейлятся при обновлении Qt
> Деньги с донатов плюс всегда можно нагнуть каноникал.Они собирают донаты.
> Рекомпиляция 100500 qtшных пакетов
Ну так они телеметрию и "анти-функции" вырезают всегда. И ещё вставляю 100500 патчей, которые как раз фейлят компиляцию.
"Платить деньги" - это не решение в опенсорсе, развал мозиллы - явный тому показатель. В хороший опенсорс идут, чтобы бороться со злом, а не чтобы зарабатывать деньги. Если за поддержку опенсорса надо доплачивать, то это уже плохой опенсорс, находящийся на грани своего развала.Вот только дебиан - давно уже не хороший опенсорс, с тех самых пор, как они приняли ЗЛОd и создали debian women project.
А ты за бесплатно работаешь, да?
Давай я тебе скину тогда одно ТЗ, а ты за бесплатно мне ПО напишешь.То, что за опенсурс не надо платить, только твоя точка зрения.
Разработчики тратят своё время и жизнь на написание этого по, поэтому они совсем не против денежного вознаграждения.
А с твоей точкой зрения, линукс загнется через 2 дня, ибо за просто так никто опер сурс делать не будет.
Кстати у Линуса Торвальдса ЗП в год около 6000 тысяч долларов.
Иди отпиши ему, что он должен сейчас просто так писать опер сурс.
Он поржет над тобой и отправит тебя на 3 весёлых буквы.
600 тысяч долларов точней.
> А ты за бесплатно работаешь, да?Нет, представь себе, *работаю* я не за бесплатно, но делаю при этом не то, что нужно мне или миру, а то, что нужно тем, кто печатает деньги. В разработке софта я учатсвую бесплатно, но это не работа, а улучшение мира.
> Давай я тебе скину тогда одно ТЗ, а ты за бесплатно мне ПО напишешь.
Можешь писать своё ТЗ в коменты, но чтобы кто-то, например я, написал по нему опенсорс, ты должен убедить например меня, что твой проект представляет собой большее добро, чем мои текущие (о которых я здесь говорить не буду во избежание деанона фемками). Если не убедишь - пустозвон. Это опенсорс, детка.
> Кстати у Линуса Торвальдса ЗП в год около 6000 тысяч долларов.
И это плохо. Потому что вот когда он начал её получать, линукс и начал скатываться, потому что вместо написания хорошего кода (т. е. создания мирового добра) он начал заниматься тем, что нужно феминисткам, которые платят ему зарплату, т. е. корёжением кода с поломками совместимостей.
>И это плохо. Потому что вот когда он начал её получать, линукс и начал скатываться, потому что вместо написания хорошего кода (т. е. создания мирового добра) он начал заниматься тем, что нужно феминисткам, которые платят ему зарплату, т. е. корёжением кода с поломками совместимостей.Вы всегда можете написать свою ос как хотите. Это же опер сурс. И делайте её за так.
Ну а насчёт поработать за так в опен сурс. Отвечу заранее: иди сам и работай в опер сурс бесплатно.
Зачем мне её писать, когда всё уже написано?
Ну и лицемер же вы.По вашей точке зрения на мир - пишут код за деньги в опен сурсе только злодеи и подонки.
Но при этом вы без зазрения совести пользуетесь трудом этих подонков и указываете другим как жить.
Какое же это лицемерие и наглость.
Вы просто очередная лгун с opennet.
Мне искренне жаль своего потраченного времени на вас.
Лицемер здесь пока что только вы, причём очереднАЯ (sic!)> пишут код за деньги в опен сурсе только злодеи и подонки.
Где я это сказал?
> Но при этом вы без зазрения совести пользуетесь трудом этих подонков
Даже если и так, не вижу ничего плохого в том, чтобы пользоваться полезными результатами деятельности подонков. Особенно, сделанными тогда, когда подонками они ещё не были. Таким образом хотя бы немного компенсируется вред, нанесённый подонками и лгунами вроде вас обществу.
> указываете другим как жить.
Также не вижу ничего плохого в повторнеии самоочевидных истин, если кто-то делает вид, что их не понимает.
> лгун
И где это я соврал, интересно?
Кстати, чисто на всякий: http://emboxing.ru
>Можешь писать своё ТЗ в коменты, но чтобы кто-то, например я, написал по нему опенсорс, ты должен убедить например меня, что твой проект представляет собой большее добро, чем мои текущие (о которых я здесь говорить не буду во избежание деанона фемками). Если не убедишь - пустозвон. Это опенсорс, детка.Ясно, понятно, ты сам очередной пустозвон.
Можешь только писать красивые слова, а как только дошло все до дела, пошли отговорки. Впрочем ничего другого от людей, требующих от других работать за бесплатно я и не ожидал.
Всего хорошего.
Пустьзвон здесь только ты, потому что *работать* бесплатно никто не предлагает. Бесплатно предлагают бороться со злом, весь опенсорс на этом построен. Но тогда объяснить другим, что ты предлагаешь именно бороться со злом - твоя прямая обязанность.
Вы предложили ему написать ПО.
Он предложил Вам опубликовать ТЗ.
Вы обозвали его пустозвоном.Пустозвон -- насколько понимаю, тот, кто бьёт в колокола без повода.
И да, завязывайте с отговорками или внимательно перечитайте пп. 4, 6, 8 http://wiki.opennet.ru/ForumHelp
Целиком и полностью поддерживаю. Опенсорс - это прежде всего идея. А когда идея становится проплаченной, она перестаёт быть идеей.
>становится проплаченнойВы точно понимаете значение слова opensource?
А вы точно читаете соседние новости?
Ну началось, сейчас опять до "демократий" по Аристотелю, римлянам, французам и американцам доберёмся уж в который раз.А всё потому, что некоторые не в курсе разницы между открытыми исходниками, свободными программами, ответственностью добровольцев и профессиональной ответственностью. Это всё может как сочетаться в одной точке (проекте, человеке), так и очень даже нет.
Когда сочетается -- в виденных случаях было хорошо. Когда нет -- обычно это про нестроения, жадность, непрофессионализм. Требовать такого от других -- не работает. Делать и выращивать самому -- порой бывает.
Просто кути5 сегодня - хватает всем и на всё. Потому и не спешат бежать. Некоторым(не мне, из-за HIDPI) даже третьей версии хватате.
Мне не хватает. Я хочу QPainter поверх OpenGL из Qt6 и биндинги из QML для нормальных виджетов.
>Qt6Неужели я опять вылез из криокамеры
в кутэ5 не всё сломали, требуется кутэ6
Не переживай, в gtk3 уже все сломали, а теперь все сломают и в gtk4. Любители сломанного гномна голодать не будут.
Там cmake простыня огромная, пробросы env. Фу!
Интересно. Из RHEL8 его выкинули изначально, дебиан - следующий... Qt походу умирает. Жаль.
Дебьян умер давно, после того как все изначальные разработчики уволились из-за s-d. REHL следующий.
Ну прям день пророков. В каком месте-то он умер, можешь пояснить?
> после того как все изначальные разработчики уволились из-за s-dDebian - это не Red Hat, и даже не Mozilla. Там не работают, а, значит, и не увольняются. Там только волонтёры насколько я знаю. Пусть и зовутся они "разработчик Debian", "сопровождающий Debian".
Qt он как и электрон. Не нужен, но все им почему-то пользуются.
Единственное адекватное нативное средство кроссплатформы на все актуальные десктоп и мобайл платформы
Альтернативы?
flutter?Пока не готово, но потенциал есть
Небось, для Linux поверх Говнотыка будет? Фу!
Обещают в будущем интерфейс для интеграции с любыми фреймворками, он ведь в opengl рендерит
Даже без Vulkan?
Нет там опенгл, отрисовка примитивов через skia на цпу производится.
Нормально, но для десктопа проще FLTK взять. Вчера вечером себе програмку запилил (проще сделать, чем искать готовую) на нём - кода мало, работает как надо, выглядит стильно если под лупой не разглядывать, потребление памяти 1836 КБ.
>Разработчик GoogleЭлектрон 2.0
Не единственное точно, embarcadero.
Адекватных. Я не зря это дописал.
У Embarcadero даже IDE нет на онтопик
Пока qt не предоставит нормальные статические линкованные файлы на выходе, я даже не рассматриваю ее как IDE. Да можно собрать свое из сорцоы под каждую ОС.
Статику лучше не надо, если сам софт не под GPL/LGPL
> Альтернативы?Java, wxWidgets
Не знаю, каким надо быть извращенцем, чтоб использовать это на мобилках
Это как Qt Widgets на iOS собрать
Особенность десктопов и мобил уже в том, что им в принципе не может потребоваться одинаковое приложение с одинаковыми интерфейсами уже даже ввиду разных габаритов и соотношений экранов, методов взаимодействия пользователя с «железкой» и проч.
Если надобится - значит, что-то пошло не так.И, кстати, по поводу эпически кроссплатформенных интерфейсов - вебстраница. Открывается везде и на всем, где есть совместимый браузер.
С функционалом - сложнее, но очень многие вещи уже можно делать посредством веба.Просто, умеренно-быстро, не требует компиляций и порог входа условно-небольшой( хотя попробуй изучить html 5, css 3, свеженький JS, инструментарий для его обработки и проч ).
Но результат ИМХО получается весьма неплохим.
Попробуй на веб странице адекватный редактор фоточек сделать, файловый менеджер или хотя бы банальный фонарик?
Figma и всякие Adobe-приблуды какгбе намекают, что ты не совсем прав.А доступ к ФС и аппаратуре из интернета в целом и с веб-страницы в частности - зло в чистом виде.
Ну фигма это всё же не фоторедактор, и для пользователя ничего хорошего в зависимости от привязки к онлайну нет.
Попробуй на чем угодно адекватный редактор фоточек сделать или, хотя бы, банальный фонарик( на десктопе то, угу ) ?И это даже без учета принципиальной разности как в размерах экрана, так и в подходах к управлению на десктопе и смартфоне.
п.с: редакторы фоток нынче нередко есть онлайн и уже лет 5 это нечто совершенно обыденное явление. Удивительно что ты не в курсе.
Ну а в случае с именно доступом из веба к железу - он постепенно усиливается.
Еще несколько лет назад посредством веба даже к веб-камере на десктопе или мобильнике было практически невозможно подключиться - для этого требовалось делать пусть и примитивное, но именно приложение.
Но нынче уже только так проводятся видеоконференции онлайн посредством веб-страниц.. и никакого флеша.Но пока для чего-то серьезного, как минимум, в случае с мобильными устройствами, обычно пишут приложения на кроссплатформенных штуковинах вроде React-Native( qt, кстати, при этом выкидывают на помойку ввиду громоздкости и трудоемкости поддержки этого барахла. Кроме шуток, довольно часто встречаются конторы, переходящие с qt, на котором была написана начальная версия приложения, на что-то получше )
> п.с: редакторы фоток нынче нередко есть онлайн и уже лет 5 это нечто совершенно обыденное явление. Удивительно что ты не в курсе.Я поэтому написал "адекватный". Сейчас глянул что там есть на рынке (pixlr вверху выдачи гугла), попробовал открыть текстурку, с которой работаю - пишет "Изображение, которое вы выбрали, очень большое (8192 x 8192) измените его размер перед началом редактирования, чтобы сэкономить память и минимизировать время загрузки". Это не серьёзно же. На тех же мобилках нынче фотки и поболее бывают, а тут такой лимит для десктоп версии. Да и функционал куцый.
Нет, конечно, на жс можно много чего сделать, есть даже реализация h264 кодека на жс, но это ж ерунда.
> Еще несколько лет назад посредством веба даже к веб-камере на десктопе или мобильнике было практически невозможно подключиться
До чего дошёл прогресс🤣
Видеозвонки на мобилках ещё в нулевых были.
> Но пока для чего-то серьезного, как минимум, в случае с мобильными устройствами,
> обычно пишут приложения на кроссплатформенных штуковинах вроде React-Nativehh.ru Россия:
android developer - 2 742 вакансии
ios developer - 2 440 вакансий
react native developer - 473 вакансииЭлитарный фреймворк для особо серьёзных приложений, ага.
>> Но пока для чего-то серьезного, как минимум, в случае с мобильными устройствами,
>> обычно пишут приложения на кроссплатформенных штуковинах вроде React-Native
> hh.ru Россия:
> android developer - 2 742 вакансии
> ios developer - 2 440 вакансий
> react native developer - 473 вакансии
> Элитарный фреймворк для особо серьёзных приложений, ага.Потом, правда, окажется, что React-Native разработчик - это разработчик и под андройд и под айось :)
Кроме шуток, сейчас нередко пилят приложения чисто под андройд или айос, но на штуках вроде RN, т.е без "нативной" джава, свифта и проч, хотя лично я не совсем подобное одобряю.А теперь чуть уточненные результаты поиска( параметры те же ):
Swift developer - 1093 вакансии
Objective-c developer - 551 вакансия
Java android developer - 1156 вакансий
Kotlin android developer - 896 вакансий.. ну и React-Native developer - 473 вакансии. Не так уж плохо с учетом того, что о подобных гибридных штуковинах заказчики в РФ только-только начинают узнавать нормально. Пару лет назад вакансий было несколько десятков.
Ну и, куда же без Ылитарности. Тот же hh, та же РФ:
QT( включая просто упоминания в тексте вакансии типа "опыт работы с QT будет плюсом" ) - 436 вакансий
QT Android developer - 44 вакансии
QT iOS developer - 23 вакансии
QT mobile developer - 8 вакансийВот уж где илита так и прет.. прям изо всех щелей.
Хотя.. это фактически подтверждает мои слова о том, что qt из мобильных устройств летит прямиком на помойку[истории] и поддержка им каких-то там абстрактных мобильных устройств уже не является особым аргументом.
> Кроме шуток, сейчас нередко пилят приложения чисто под андройд или айос, но
> на штуках вроде RN, т.е без "нативной" джава, свифта и проч,
> хотя лично я не совсем подобное одобряю.Нередко их потом переписывают на натив(kt/swift), т.к. лагает, да и реактщикам порой приходится куски на нативе под обе платформы делать. Я не топлю за qt, но плюсы по мне так разумнее выглядят чем дёрганье нативных виджетов из js движка. Да и тот же свифт собирается под линукс (а значит и андроид теоретически), и котлин что-то там про исполняемые бинарники заявлял. И дарт компилится в бинарник, а значит тормозная скриптуха всего лишь 1 из многих выборов для кроссплафтормы.
>> Кроме шуток, сейчас нередко пилят приложения чисто под андройд или айос, но
>> на штуках вроде RN, т.е без "нативной" джава, свифта и проч,
>> хотя лично я не совсем подобное одобряю.
> Нередко их потом переписывают на натив(kt/swift), т.к. лагает, да и реактщикам порой
> приходится куски на нативе под обе платформы делать. Я не топлю
> за qt, но плюсы по мне так разумнее выглядят чем дёрганье
> нативных виджетов из js движка. Да и тот же свифт собирается
> под линукс (а значит и андроид теоретически), и котлин что-то там
> про исполняемые бинарники заявлял. И дарт компилится в бинарник, а значит
> тормозная скриптуха всего лишь 1 из многих выборов для кроссплафтормы.А минусить то за что ?) -Я просто привел более корректные цифры по вакансиям, в т.ч и богоподобному QT( по которому суммарно всех вакансий, включая даже те, где он просто мельком упоминается, примерно как для одного RN, в котором ожидается именно соотв разработчик )
2-3 года лет назад подобное частенько бывало - тогда RN был еще сыроват и нередки были проблемы с производительностью да и с работоспособностью( вылеты или в нативе или в жс ).
Хотя, они и сейчас бывают, но только если RN-разработчик - вчерашний вебпрограммист и прогает под мобилу аккурат как на вебе, с кучей постороннего мусора и нагромождений( TS, StyledComponents + еще какой-нибудь Vue-Native до кучи.. который на базе RN работает лишней прослойкой ), которые браузер еще прощал, а подобная штуковина - уже нет.
Ну и иногда переписывают на "натив" реально мудреные приложения, которые пилились более года и по ходу дела несколько раз менялась концепция, что в итоге привело к наличию фактически 2 разных приложений - под яблоко и андройд, с разными дизайнами и с ощутимо различающимся функционалом.Если же приложение написано сколь-нибудь нормально, оно не лагает( если только на старых бюджетных андройдофонах ).
Другое дело, что языки вроде Си или плюсОв могут очень многое прощать в плане архитектуры, поскольку скомпиленный код работает быстрее и может "пережевать" гораздо больше обезьяньего когда с горами оверхеда.
Хотя и в случае с JS и RN - все-таки применяется движок из WebKit.. и компиляция есть, пусть и JIT( хотя сейчас уже хитрее, в случае с т.н RN Hermes для Android ).Порой - бывает.. но речь об очень специфических случаях, поскольку весь основной функционал( работа с пушицы-уведомлениями, камера, геолокация, карты, анимация, работа с ФС итд итп ) уже давно реализован в модулях и нередко из десятков и сотен разных приложений, лишь для какого-то одного, с очень специфическими потребностями, требуется запилить подобие "модуля"( и то, потому что обычно требуется подключить какое-то очень стороннее и закрытое SDK, которе распространяется лишь обычным архивом с бинарниками.. и то, после регистрации и СМС ), т.е нередко нужно писать даже не совсем "модуль", а "прослойку" на нативе( обычно это ObjC и Java ), чтобы этот модуль можно было бы дергать из JS.
Дело не в том, на чем собирается свифт.
Дело в том, что он - крайне нишевой язык, тогда как у того же JS имеется куча наработок почти на все случаи жизни, да и работает он на огромном множестве разных устройств..С флаттером и дартом вообще отдельный разговор.
Да, жс - лишь один из многих вариантов, но возможность запросто собирать платформо- и архитектуронезависимую часть, в которой реализована основная логика - весьма интересная штука( что приводит к порождению штук вроде Expo у того же React-Native. Хотя Expo категорически не одобряю ).
Скорее всего, если на смену JS что-то и придет, то это будет или WASM или - байт-код LLVM, полученный из какого угодно ЯП, который поддерживает "компиляцию" в соотв байткод.
> А минусить то за что ?)Я своё отношение высказал в комменте, а не минусовалкой)
> Если же приложение написано сколь-нибудь нормально, оно не лагает( если только на
> старых бюджетных андройдофонах ).Даже на дисплеях 1440p 120гц со сложной вёрсткой? Как только появляется новое мощное железо, програмиисты находят, чем его нагрузить.
> Другое дело, что языки вроде Си или плюсОв могут очень многое прощать
> в плане архитектуры, поскольку скомпиленный код работает быстрее и может "пережевать"
> гораздо больше обезьяньего когда с горами оверхеда.Да, и тут уже выигрыш от удобства разработки на js не так очевиден, если приходится больше внимания уделять оптимизации.
> Скорее всего, если на смену JS что-то и придет, то это будет
> или WASM или - байт-код LLVM, полученный из какого угодно ЯП,
> который поддерживает "компиляцию" в соотв байткод.Дарт уже готов для прода, компилится сразу в исполняемый код. Библиотек разве что меньше и архитектура замороченная, на плюсах и то проще делать UI.
>> Если же приложение написано сколь-нибудь нормально, оно не лагает( если только на
>> старых бюджетных андройдофонах ).
> Даже на дисплеях 1440p 120гц со сложной вёрсткой? Как только появляется новое
> мощное железо, програмиисты находят, чем его нагрузить.Мы все еще про мобильные устройства говорим ?
Тем более, что не стОит мешать частоту кадров и скорость отрисовки( в том же RN, к примеру, при миниальнейшей оптимизации, перерисовываются лишь компоненты с измененными входными данными. Тут уж хоть с частотой 100 000 000 гц на экран выводи - никакой разницы не будет. В случае с остальным - оптимизированная анимация обычно идет через "натив" - т.е из JS в нативную часть отправляется пачка точек и проч, по которым планируется анимация, далее - сигнал для старта, после чего сама анимация происходит чисто на нативе, без обмена данными с JS-потоком, разве что по окончании ему сообщает. И это уже идет "искаропки" )В случае с мобильными устройствами, сложная верстка - это обилие списков, в т.ч вложенных, с кучей элементов.
А просто обилие оформления - вообще не проблема, т.к без наличия изменений входных данных, они не изменяются.Для тех случаев, где требуется что-то особо динамично отрисовывать ИМХО есть игровые движки, которые в т.ч для этого и предполагаются.
> Да, и тут уже выигрыш от удобства разработки на js не так
> очевиден, если приходится больше внимания уделять оптимизации.Учитывая, что при этом не требуется этот бесконечный цирк с типизациями на фоне огромного обилия RN и JS-пакетов на все случаи жизни и это при наличии пакетного менеджера, все-таки плюсы есть.
Реально серьезные оптимизации требуются крайне редко.
На самом деле, нередко приходится заниматься обратным - черти-какие разрабы начитаются каких-нибудь хренабров, медиумов итд итп и на ровном месте начинают тянуть в проект гору мусора, которая, мало того, что делает код громоздким и добавляет кучу оверхеда( простой и кэповский код на JS размазывается на десяток файлов, появляются абстрактные классы, интерфейсы, публичные-приватные методы. Что, ни разобраться в этой помойке, ни просто взять и сделать правки, практически невозможно, как будто кто-то только начитался этой белиберды про паттерны и заблевал этим весь проект ) , так еще и само приложение делателя тормозным, безумно жрущим ресурсы, а сам проект - малоподдерживаемым.> Дарт уже готов для прода, компилится сразу в исполняемый код. Библиотек разве
> что меньше и архитектура замороченная, на плюсах и то проще делать
> UI.Дарт и его инфраструктура почти намертво к гуглу привязаны и их будущее практически полностью зависит от его прихоти - очень с серьезная неопределенность.
Вдобавок, дарт уже даже подыхал разок вроде бы как.
Потому прогеры не очень-то и спешат за него браться.Нужен не просто исполняемый код, а максимально пережеванный, но не заточенный под конкретную архитектуру, который без серьезных проблем можно оптимально собрать под разные архитектуры( в т.ч те их модификации, которых пока даже нет ).
За подобным будущее ИМХО.
> Мы все еще про мобильные устройства говорим ?Ага, One plus 8 например - 1440x3168 120гц дисплей.
> Реально серьезные оптимизации требуются крайне редко.
В проектах где я работал (фото/видео/аудио обработка/трансляция) почему-то часто требуется🙂
>> Мы все еще про мобильные устройства говорим ?
> Ага, One plus 8 например - 1440x3168 120гц дисплей.Сколько там реально герц - это, скорее, тайна за семью печатями, поскольку в обычном режиме работы подобные частоты приведут лишь к ускорению разряда аккума.
Обычно более-менее шустрая перерисовка( реальная ) происходит лишь в тех областях, где были изменения, но это уже старый подход. Сейчас наверняка что-то еще хитрее.> В проектах где я работал (фото/видео/аудио обработка/трансляция) почему-то часто требуется🙂
Подобные проекты - менее 5%.
Есть, конечно, в немалом количестве те, куда просто требуется встроить воспроизведение аудио или видео с того же ютубчика, но это каких-либо сложностей не вызывает, как и необходимости работы с наливом не требует.Медиа, ее обработка и передача - вообще отдельная история и там да, нередко очень много чего требуется, поскольку крайней ресурсоемкая и специфичная штука.
Там не то, что работа с нативом и модулями частенько требуется - там еще и с самим конторами вроде эппла вопросы решать приходится( по итогу которых они обычно просто шлют в известном направлении с тонким намеком на перспективу толстого наказания по случаю чего ).
Помню, требовалось как-то во времена еще 5-го айфона запилить приложение - подобие скайпа, но с кучей фич, потоковым видео итп.. Практически все нативные библиотеки и модули, которые имелись, не позволяли сделать это нормально( или качество было ужасное и устройство эпически накалялось, т.к перекодирование шло чисто на ЦП или трафик на раз-два прожирался, поскольку шло в толстом формате и нередко требовало подключение к вайфаю ), но тот же "нативный" FaceTime запросто это делал без особых проблем... по итогу долгого гугления и срачей оказалось, что у яблока есть несколько уровней АПИ - самый открытый и тупой для обычных сторонних разработчиков, более продвинутый - для "приближенных" контор и реально крутой( с задействование множества аппаратных узлов, которые недоступны сторонним разрабам. Во времена 5-ки, это были в т.ч узлы аппаратной обработки видеопотока, которые были доступны фейстайму и недоступны всем остальным ) - для своих продуктов( если даже кто-то из сторонних разрабов расковыряет этот АПИ, сказать что ему будет а-та-та при попытке выгрузки такого приложения в сторонки - не сказать ничего ).
И с какими же ЯП можно использовать Java-GUI, кроме ней самой?
С любым компилируемым через сишную обёртку jni.
Спасибо, не нужно
Поэтому и придумали SNAP и другие аналоги. Правда я сам сильно их недолбливаю, лучше уж из бинарников запускать.
Ага, под рутом
Из бинарников менее безопасно
зачем под рутом?
Так выстрел в ногу доя лохов же. Реальные пацаны откобейнивают себе бошку
Да. Давайте откажемся от всех этих пакетных менеджеров, снапов, флатпаков. Будем как в винде софт распространять. Придумаем инсталяторы, будем в них паковать софт вообще со всеми зависимостями, даже GlibC будем ложить, ну а мало ли. А ещё лучше, будем статически всё линковать, компиляторы быстро компилируют.
До сих пор не понимаю почему так не делается в никсах. Софт который работает только в пределах поддержки дистра не дело.
Любая программма это виртуальная машина :)
Потому что любой серьёзный софт тянет сотни зависимостей. По вашей схеме мейнтейнеры каждого такого мегапакета должны заботиться обо всех этих зависимостях. Это на порядки увеличивает сложность поддержки, к тому же ухудшает контроль за качеством — больше вероятность не только сбоев, но и вредоносных изменений. Экосистема Windows (равно как и macOS, *BSD и т.д.) частично выигрывает ещё и за счёт своей единообразности: стабильное API, единый набор системных компонентов. В Linux этой роскоши нет.
> стабильное API, единый наборНу вот и что мешает кутятницам всё это сделать? Почему постоянно всё ломают?
"Серьёзный софт" что под венду, что под мак таскает с собой скомпиленные авторами либы, сабж в т.ч. В линукс же есть парочка своих экосистем (KDE/Gnome), которые включают в себя подавляющее большинство нужных gui прог. Ну а для отщепенцев есть шлакпак.
Потому, что если в библиотеке находится дыра, то придется обновить все приложения использующие её. Если это дыра в glibc то придётся переустановить всю ОС, а это трафик, процессорное время и ресурс SSD. Разделяемые библиотеки они именно для снижения расходов существуют.
Делается. Потом разрабов поливают говном за такое.
Потому что подход -- "чтоб работало", а не "впарить и сбежать".
так есть же уже appimage
Неотключаемые обновления они могут засунуть себе в телевизор.
А что же будет с Kubuntu?
Собственно, при чем тут кубунту?
Судя по букве K — там должен быть KDE который на Qt.
Мг. А сама Убунта основана на Дебиане, отсюда и вопрос.
Надо подсказать мэйнтейнерам из Debian включать в дистрибутив _LTS_ версии Qt. Они же включают предшествующую версию LTS, а потом портируют вручную из LTS. Маразм же.
Просто циклы релизов Debian и Qt не совпадают. А обновлять минорную версию Qt в стабильном дистрибутиве - это из области фантастики.Но для админа локалхоста всегда есть Debian testing, зачем у себя на компе держать stable, непонятно.
Хорошая идея, вот только LTS Qt платный, Debian будет сам платить за всех? Если что одна лицензия 4к долларов стоит на Qt. Поэтому мб вы сами задонатите столько денег, чтобы на всех хватило?
А разве платные не бинарники? Я думал исходники можно брать и собирать.
В том-то и проблема, что они и исходники зажимать будут.
Не имеют права зажать больше чем на 12 месяцев. А тормоза в дебиане всё равно больше.
12 месяцев без секьюрити-патчей - ни один дистр не возьмёт на себя такую ответственность. Здесь в выигрыше только роллинг-дистры, ибо они сразу переходят на новую версию.
Qt 5.12 LTS последнее обновление 15 часов назад
Qt 5.15 LTS последнее обновление 9 часов назад
Qt dev последнее обновление 6 часов назад
Посмотрим, что будет после Qt 6
https://code.qt.io/cgit/qt/qt5.git/
Самый свежий из бесплатных, я не понимаю в чём проблема. Для остальных тарболов backports, для гита experimental.
Единственное что им можно подсказать не использовать это проприетарное гэ с мутной лицензией
Разрабы бегут из дебиана как крысы с тонущего корабля...
Никто никуда не бежит, новость прочти внимательно. У людей тоже есть личная жизнь, работа. А пакетить таких монстров как Qt- та ещё задачка. Особенно при переносе патчей. Вот если бы объявили Qt5 deprecated сразу после выхода 6 - глядишь они бы и продолжили работать как работали. А так паковать уже 2 суперкомбайна - черезчур.
Патчи не так уж и сложно переносить. Скорее проблемы с тем, что новая версия внезапно перестает собираться или - еще хуже - работать под архитектурой вроде mips.
Никому не хочется работать под диктовку шляпы и космонавта, да ещё и за спасибо. Лучше уж тогда в тот же Ред Хат или Каноникал на зарплату пойти.
Выпускать новые версии QT выгодно только самому Qt Project, потому что они на это заработывают.Выпуск новых версиий QT не даёт пользы конечному пользователю.
Вообще постоянная разработка софта, это афера придуманная самими пограмистами, чтобы было за что деньги получать.
Программу надо написать один раз, чтобы работала как надо и все.
Вон авторы форка KDE 3.5 TDE Trinity форкнули себе QT. Это самый лучший вариант, что можно придумать.
Давно туда не заглядывали? Они там в QT5 уже поглядывают.
Поглядывать поглядывают, но ещё не перенесли.
Погодите, они ещё на Qt 4 не перенесли.
Товарищ отчасти прав.В свете сказанного мной ниже мы имеем очевидную проблему.
Программа А версии 1 зависит от библиотеки B начиная с версии 2 до версии 3.
Если вышла новая версия библиотеки B v4, а старые версии помечены как небезопасные,
то уже нет возможности установить программу A пока она не обновится до версии 2, когда совместимость будет восстановлена. Казалось бы какая ерунда.Проблема заключается в том, что во-первых условная программа зависит часто от минимум дюжины библиотек каждая из которых в свою очередь зависит еще от десятка других.
Во-вторых существует много программ, которые зависят от похожего списка библотек.И все они развиваются с разной скоростью. Без специальных мер, автоматически через определенное время наступает ситуация, когда одну программу собрать уже нельзя, а другую еще нельзя.
Тоже касается библиотек.Просто пользователи дистрибутивов с этим редко сталкиваются, так как за них всю работу выполняют
разработчики дистрибутивов.Для облегчения жизни всех было бы идеально запретить обновлять программы и библиотеки чаще, чем раз в год имея версии с долгой поддержкой, где обновление возможно раз в 3-5 лет.
Но я не знаю ни одних разработчиков библиотек, которые бы с этим согласились.
Это обычно молодые люди, которые по своей наивности уверены, что еще пару изменений
и наступит рай. За это их должны бить линейкой по пальцам более старшие товарищи.Но таких нет. Тот же Linux слишком часто меняет версии. Хотя для него цикл - 1 версия в 5 лет было бы идеальным подходом. И пользователям приходится самим исправлять ситуацию оставаясь на много версий назад в своих рабочих машинах.
Я бы тут с удовольствием повторил жест Линуса в сторону NVIDIA обращенный к нему самому.
кому нужна эта гонка?
Я к тому что жить можно, только если дистрибутив с одной средой рабочего стола, напритмер КДЕ, и QT соответствующей версии и сторонние программы пишут основываясь на этих вирсиях.
Допуским Кубунту, какой-то фиксированной версии, для него пишут программы. Вышла новая Кутэ, выпустили новую версию КДЕ и соответственно Кубунту, сторонние разработчики тоже обновились.
А то что мы сейчас имеем это адок.
>наступает ситуация, когда одну программу собрать уже нельзя, а другую еще нельзя.<держите хоть 5 библиотек
> держите хоть 5 библиотекказалось бы да... но нет. Их просто не будет в дистрибутиве.
Причем по очень простой причине - их самих будет не собрать
потому как зависимости будут сломаны.Вы прежде чем комментировать вообще читаете, что пишут?
Вы пытались понять, что пишут?
Вы пытались задать вопросы, если Вы что-то не поняли?
Если ответ на все - нет, то зачем это вброс?
P.S. Если Вы узнаете о новых правилах распространения библиотек
Qt, то там вообще нет вариантов что-то сделать. Но главное не это.
Главное это понять зачем это было сделано. Но для Вас это высший пилотаж.
Даже не пробуйте.
если все так плохо в этой схеме, может пора менять схему, а не изгибаться в 3 слоя?
На самом деле сопровождение пакетов это действительно большая проблема.
Я не знаю кто и как пишет эти программы, но слишком часто они не собираются без танцев с бубном.Проблемы по нисходящей следующие:
1. Слишком часто разработчики не тестируют свои же изменения.
Программа элементарно не собирается из-за того что забыли включить
обычный #include <something> причем часто из стандартных библиотек.
Вылеты по ошибке компилляции тоже нередкость.2. CMAKE. Это почти абсолютное зло. Эта вещь в себе, которая не находит библотеки которые лежат в стандартном пути. Если авторы напортачили с соотвеnствующими файлами .cmake то проблемы будут. Зачем этот ужас придумали понять невозможно.
2.1. Да, возможно будут комментарии, что мол его надо уметь готовить.
Казалось бы логика в этом может быть. Но как быть с фактом, если сами создатели этого cmake и одновременно авторы некоторых других пакетов вроде vtk сами не умеют готовить это поделие, чтобы оно просто компилировало их собственную библиотеку без ошибок! Сборка vtk или paraview от них же это бесконечный танец с бубном. Несовместимость версии 8.2 с gcc10 и переделанный API в версии 9.0, которой уже несовместим с зависимыми приложениями. которые еще не успели отреагировать. И тут мы попадаем в главную проблему3. Динамические библиотеки. Может когда-то на заре появления компьютеров в этом был смысл. Теперь это одна сплошная проблема.
Нет они не совместимы с разными версиями зависимых от них программ.
Нет никакого удобства поставить себе одну версию одной библиотеки и радоваться. И нет никакой дополнительной безопасности они не несут.
Нельзя обновится но более исправленную версию и не бояться проблем с безопасностью. Слишком часто если не постоянно там происходят несовместимые изменения на уровне API, которые должны иметь отражение в зависимых программах - иначе не будет работать.Тот же flatpack и подобные пакеты идеальные примеры ущербности концепции динамических библиотек. Просто достаточно взять более сложную программу, чем mkdir. Тот же firefox да и все остальные браузеры поставляются со своими версиями стандартных библиотек, которые лежат в специальном месте отличном от стандартного. Иногда системные библиотеки работают. Но слишком часто - нет.
Эта же проблема касается разных дистрибутивов. Каждый собирает условную библиотеку на свой вкус и включает туда что ему лично кажется нужным или не включает что ему кажется не нужным. Мало того пути инсталляции слишком часто отличаются. Отсюда те самые *.cmake файлы "помогающие" найти библиотеку среди 2х сосен. И главное кто что только не придумывает! И тебе /opt и /usr/local/lib или вообще /usr/fignaydesh/usr/lib64/bin/ итд.
В общем понять разработчкиов Debian несложно. Сложно понять зачем и кто весь этот геморой устроил? Почему нет стандартов и каждый копает свой несовместимый ни с чем огород?
> 1. Слишком часто разработчики не тестируют свои же изменения.Программа элементарно не собирается из-за того что забыли включить
обычный #include <something> причем часто из стандартных библиотек.
Вылеты по ошибке компилляции тоже нередкость.Разница между объявлением и опредлением функции - основы основ для программистов на С и С++. Если бы ты в жизни написал хотя бы одну программу, то знал бы, что "твоя проблема" возникает, не из-за "недостатка тестирования", а в ситуациях, когда меняются файлы заголовков у библиотек-зависимостей. Qt таким даже на минорных релизах часто грешит, те быстро попадают в репо некоторых дистрибутивов-торопыг (да, да, Арч, не прячь глаза, я про тебя говорю), а разработчики программ, зависящих от Qt, не всегда успевают обновить кодовую базу до последней версии. Исправляются такие "проблемы" элементарно, по возможности сразу в апстриме, да это и не проблемы вовсе, а обычный рабочий процесс разработчиков и сопроводителей программ. Впрочем, в последних, бездельниках, многие незнайки-улучшатели не нуждаются, пока им самим не придется для себя собрать их любимый хеллоуворлд из исходников. Вот тут-то и начинается мамочка-помоги.
> 2. CMAKE. Это почти абсолютное зло. Эта вещь в себе, которая не находит библотеки которые лежат в стандартном пути. Если авторы напортачили с соотвеnствующими файлами .cmake то проблемы будут. Зачем этот ужас придумали понять невозможно.
Плохому танцору и яйца будут мешать. А тем, кто освоил основы компиляции программ, понимает процесс, и GNU make будет полезным и удобным инструментом.
> 3. Динамические библиотеки. Может когда-то на заре появления компьютеров в этом был смысл. Теперь это одна сплошная проблема.
Нет они не совместимы с разными версиями зависимых от них программ.
Нет никакого удобства поставить себе одну версию одной библиотеки и радоваться. И нет никакой дополнительной безопасности они не несут.Идиоты-менеджеры в IT - ЭТО сплошная проблема. Никто учиться не хочет, лучше ничего не уметь и, хоп, сразу руководить. Скоро код писать некому будет. Хотя с такими руководителями, оно и к лучшему.
Цитату же комментировать не буду по очевидным причинам. Взял в рамочку - повешу в туалете.--
Вопрос напрашивается сам собой, сколько горе-теоретик сопровождал программ? Может, это ему нужно запретить пользоваться Интернетом и бить линейкой по губам, чтобы молчал о том, в чём не разбирается? Может ему хотя бы на троечку изучить предмет, прежде чем раздавать советы по переустройству мира, так чтобы одному ему было хорошо и удобно, а всё остальное - сломать? Вопрос риторический, можно не отвечать.
> Разница между объявлением и опредлением функции - основы основ для программистов на С и С++.Разница между читателем и чукчей писателем - основы для ведения дискуссии на проф. уровне.
Пожалуйста не несите пургу и выучите хотя бы один язык. Прочитайте текст несколько раз
и задавайте вопросы ПО тексту вместо того чтобы нести отсебятину, которая не имеет отношения к вопросу.> Плохому танцору и яйца будут мешать.
Расскажите это авторам cmake.
> Вопрос напрашивается сам собой, сколько горе-теоретик сопровождал программ?
Я все таки предлагаю выучить русский язык, научится читать и только после этого вступать
в дискуссии!С Вашим мнением есть элементарная проблема. Оно не имеет ничего общего с моими словами.
Оно не противоречит им, не критикует с любыми аргументами в руках. Оно что называется ортогонально.Это как на вопрос - сколько градусов ответить - пол шестого.
Подумайте над этим. Прохожие люди не показвают на вас пальцем? Вы не замечали какого-то необычного отношения к своей персоне?
Короче по твоему мнению надо заставить всех разрабов бандлить свои либы, линковать протухшие дырявые версии статически (ну, чтобы мейнтейнеров лишний раз не напрягать, конечно же) и далее по списку. Зачем тогда вообще нужны мейнтейнеры и их дистрибутивы? Пусть все желающие мейнтейнеры объединятся под одним флагом, разрабы будут клепать своё дерьмо как и раньше, все будут счастливы! Разве что все кроме пользователей.
> Короче по твоему мнению надо заставить всех разрабов бандлить свои либы, линковать протухшие дырявые версии статически (ну, чтобы мейнтейнеров лишний раз не напрягать, конечно же) и далее по списку. Зачем тогда вообще нужны мейнтейнеры и их дистрибутивы?Я не знаю кто Вы и где Вы. Может Вам подарить зеркало? Вы отлично с ним спорите.
У меня только один вопрос. - Зачем Вы отвечаете мне? Причем тут я?
Если Вы не смогли увидеть моего ответа на Ваш вопрос, то обычная практика - задать вопрос
и ждать ответа. Вы не хотите попробовать себя так вести?
Но нет же, именно это ты и написал. Потому и отвечают тебе, логично?
>Но нет же, именно это ты и написал. Потому и отвечают тебе, логично?Что именно я написал? Цитату можно?
Мне отвечать логично, когда есть смысл. Даже когда другая точка зрения.
Причем я действительно ответил на данный вопрос в соседнем комментарии.
Но его предпочли не заметить.Постановка проблемы и ее решение это два разных тезиса и путать их не надо!
Переводя на сегодняшний политический язык. То что Лука приписал себе голоса
и провел нечестные выборы это постановка проблемы.
Предложение с ним расправится это уже предложение решения. Не факт,
что говорящий первое подразумевает второе. Но люди примитивны и по другому мыслить
не способны.
1. У них могла быть элементарно другая версия glibc/libstdc++ под рукой.2. Ой да...
3. Когда-то может выручить dsohowto, когда-то -- set versions, но с крупными библиотеками и комплексами такое действительно бывает; порой возможно держать несколько параллельных веток библиотек, в т.ч. с заголовками (как вот те же qt3/4/5 нынче), порой это затруднительно.
> И главное кто что только не придумывает
А тут надо вручать уже не dsohowto, а сразу fhs.
> Почему нет стандартов и каждый копает свой несовместимый ни с чем огород?
Стандарты есть в пределах "территорий" -- проектов, сообществ, тех же дистрибутивов.
Во многом выбор дистрибутива и есть выбор набора стандартов.
Вот не знаю, я для себя и на Qt4 спокойно пишу и все работает.
Если только для себя любимого. А то если захочешь опубликовать, то в дистрах Qt 4 и нет уже.
В альте, например, есть (и худо-бедно поддерживается). Хотя да, qt4-софт потихоньку уходит из репозитория -- что-то переписывают, что-то ломается при сборке теми же новыми компиляторами или с новыми другими библиотеками и через полгода-год удаляется.
Qt без сопровождение = дистриб без юзеров, это очень фундаментальная либа
рип дебиан. они хоть что-то могут поддерживать или после десятилетия сустемдэ все мейнтейнеры закончились?
Еще один. Могут они поддерживать и поддерживают. Нужен Qt - вместо того, чтоб ныть, запишись в мэйнтейнеры, узнаешь, какая это простая и безгеморная работа. Особенно, в свободное время.
я поддерживаю пакеты в другом дистрибутиве линукса. зачем мне записываться в мейнтейнеры дебиана и поддерживать дистрибутив с сустемдэ?
Затем, что сильно много воняешь вместо реальной работы.
Как один из двух текущих мэйнтейнеров Qt 5, считаю что это сугубо внутренний процесс и наверное даже недостойно новости на OpenNet. Qt 6 без сопровождения не останется, просто это новые пакеты и им нужны новые мэйнтейнеры (как и всем новым пакетам).
> без сопровождения не останется, просто это новые пакеты и им нужны новые мэйнтейнеры"У людей нет хлеба? Ну, пусть тогда едят пирожные!" (с)
> Как один из двух текущих мэйнтейнеров Qt 5О, замечательно, тогда воспользуюсь случаем и спрошу насчёт:
> Qt имеет очень большой объём кода, для сопровождения которого требуется много времени и ресурсов для сборки
У qt множество пакетов. Но только 2 из них большие: qtbase-opensource-src и qtwebengine-opensource-src. Не знаю, сколько в последнем именно qt, а сколько браузерного движка Blink, развиваемого гуглом.
Архив qtbase-opensource-src занимает 46,7 MB. Сборка для самой популярной платформы amd64 согласно https://buildd.debian.org/status/logs.php?pkg=qtbase-opensou... занимает где-то 34 мин. ... 1 час 18 мин.
Для сравнения архивы Firefox и Chromium занимают в несколько раз больше. Сборка Chromium длится и 16 часов. Из-за ошибок безопасности, надо быстро реагировать. С наборами компиляторов gcc, llvm аналогично. Причём поддерживаются несколько версий одновременно. Компилятор для одного единственного языка программирования Rust собирается несколько часов!!! LibreOffice обновляется часто, архив большой, собирается тоже часами. На этом фоне поддержка qt выглядит заметно проще. И это только в сравнении с пакетами, который первыми приходят на ум.
> Архив qtbase-opensource-src занимает 46,7 MB. Сборка для самой популярной платформы amd64
> согласно https://buildd.debian.org/status/logs.php?pkg=qtbase-opensou... занимает
> где-то 34 мин. ... 1 час 18 мин.
> Сборка Chromium длится и 16 часов.
> LibreOffice обновляется часто, архив большой, собирается тоже часами.На чём они их собирают, интересно? На 6-ядерном 2-ГГц Phenom 2010 года Хромиум собирается меньше часа, а Qt — несколько минут. На свопящемся 15-летнем Athlon 64?
Мне вот тоже интересно, где Debian публикует технические характеристики сборочных машин. В данном случае речь идёт о "x86-csail-01".
https://db.debian.org/machines.cgi?host=x86-csail-01 Тут инфы нет.
Да, но во-первых у меня самого железо более слабое, чем официальные сборочные сервера, а во-вторых, проблемы чаще всего возникают не на amd64, а на менее популярных архитектурах, вроде mips* или s390x. И собирать приходится не один раз, а в несколько итераций.Скажем, qtwebengine на mipsel собирается больше суток, и его как раз недавно пришлось много патчить, чтобы он по-прежнему собирался без ошибок. Впрочем, в Qt 6 наверное поддержку этой архитектуры вообще удалим.
А ещё надо пересобирать все пакеты, которые зависят от Qt и следить, чтобы они не сломались.
Единственный адекватный коммент среди всего мусора. Спасибо вам.
Теперь я спокоен за кутю, ведь её сопровождает аноним Вася Пупкин с опеннетару.
Тебе нужно открыть глаза - во всех некоммерческих дистрибутивах сопровождающие частные лица. Ты даже сопровождающим ядра можешь отправить патч от имени Вася Пупкин с ящика "жена собака жизни точка нет".
Коллега, спасибо за труды.
Вот бы строгость и качество Qt и простоту и удобство GTK в новом пакете и универсальность под всеми дистрибутивами ну то есть какой-то WinAPI что ли
> давно зрели сомнениясозрели сразу, как только перешли на системду.
" Отдельно подчёркивается, что качество кода и лицензионная политика Qt Company не связаны с принятым решением."Ну да, конечно.
Ребят, типа KDE 6 не будет у debian?
Лучше забыть вообще про кеды и кутю с их политикой-то.
Эээ… где-то в тредах к прошлой новости написали, что она будет на GTK4
Отличный пример с OpenСascade самой последней версии.Запускаем со списком параметров:
cmake $ARGS $PATH >> build.log 2>&1Один из которых -D3RDPARTY_QT_DIR=/usr/lib64
путь действительно редкий. никто не догадается.
Результат - ошибка выполнения.
Открываем cmake-gui $PATH и что же мы видим?
Параметр 3RDPARTY_QT_DIR неопределен.... ну действительно откуда.
ручками вводим /usr/lib64 и прямо в GUI перезапускаем конфигурацию.
И что же мы видим? - Все прекрасно. Полный успех.Далее запускаем make - опять работает...
Каждый может убедиться на своем опыте.
P.S. Брать здесь - https://github.com/Open-Cascade-SAS/OCCT
это для простоты. можно с ориг сайта. но там не дают доступ без пароля.P.P.S. у меня тот же скрипт прекрасно работал пару месяцев назад.
А вот теперь нет. И уверен, что еще через пару месяцев наверно опять все будет нормально.
И так ведь каждый раз. Я не говорю, что проблема в Qt. Но ранее с версией Qt4 такой проблемы не было. Кто-то меняет версии как перчатки и другие элементарно за этим не успевают.
Они не пишут еще один редактор или картинко-показатель. Они пишут сложный и объемный программный продукт, в котором по мимо Qt хватает работы. И по хорошему им бы Qt3 хватило за глаза.
Но нет. Скоро будет только Qt6 и все обязаны на него перейти, так как пред. версию быстро удалять со всех репозиториев. В Gentoo несмотря сборку из исходников никаких Qt4 уже давно нет.
Ну разумеется они же протухли.
Если кто не понял это были танцы с бубнами very light версии.
Если бы только так все решалось... Хотя все равно неприятно.
Скрипт то не работает и где править не ясно - все ведь верно.
Вот поэтому от Qt и стараются отказаться.
походу ребята нужно спрыгивать с debian на nixos
"кто не скачет, тот на альт" :D
> Майкл Штапельберг (Michael Stapelberg) объявил о прекращении сопровождения в Debian поддерживаемых им пакетов из-за недовольства текущим состоянием инфраструктуры проекта. ... Штапельберг являлся мэйнтейнером около 170 пакетов ... Претензии к инфраструктуре касаются излишне усложнённого сборочного стека https://michael.stapelberg.ch/posts/2016-11-25-build-tools/И это так. В Debian 4 и 5 SPEC-файлы были просты и понятны. Сейчас они стали значительно жирнее, чем раньше. Также стало сложнее вносить правки в SPEC-файл. Ты хочешь добавить или удалить параметр ./configure, открываешь ./debian/rules, а там этого нет! Всё раскидано по куче файлов (особенно в таких больших проектах, как Qt5). Или несколько отдельных команд заменили на какой-нибудь dh_autobuild, из-за чего, например, ты хочешь убрать из сборочного процесса команду make tests, а её нет. И даже с новыми сокращалками сборочного процесса, код всё равно пухнет!
Когда в каждом новом релизе SPEC-файлы пухли всё сильнее, было ожидаемо, что однажды самолёт под названием Debian не сможет со всем этим взлететь. Что однажды релизнется какая-нибудь новая программа, которую сложно пакетировать, и никто не захочет писать под неё 200-килобайтный SPEC. У таких пакетов, как Qt, LLVM, Chromium, Mesa, скрипты сборки огромны, а для Qt 6 их явно придётся писать заново, не базируясь на Qt 5.
> В Debian 4 и 5 SPEC-файлы были просты и понятныЭээ... ничего, что в демьяне не спеки, а правила? :D
Ну и да, dh_* -- тоже медаль о двух концах.> для Qt 6 их явно придётся писать заново, не базируясь на Qt 5
Почему?
Сейчас 10.5.0 идет на 3 DVD. А будет еще четвертый. С Qt6 :)