А какие мировые практики в bug bounty в таких случаях, когда бага не в самом софте, а в сторонней зависимости (у которой, тоже возможно есть свой bug bounty)?
То есть вы утверждаете, что закрытия бага в QtNetwork недостаточно и абсолютно такая же уязвимость через неинициализированную память остаётся в телеге даже с новой версией Qt?
Или же с пропатченным Qt уязвимость превращается в обычный баг?
Я практически целиком прочитал ваш опус, но, несмотря на ваши утверждения, так и не понял, это всё-таки баг в телеграмме или в QtNetwork и он теоретически воспроизводим в других приложениях?
Количество циклов как раз таки уменьшается. 5 раз зарядить до 80% это 4 цикла. Плюс, аккумулятор чуть дольше будет жить если его не заряжать на максимум. И если телефон всё время на зарядке - то циклы не тикают :)
А если люди, которые как я, любят сидеть на последних или предпоследних версиях айфонов (зачем это именно мне - отдельная долгая история), то такой финт значительно увеличивает цену продажи предыдущего б/у телефона.
Потенциальный покупать видит красивые циферки, что количество циклов сильно меньше количества дней эксплуатации и ведётся на это, думая что телефон мало использовался.
Хотя сейчас на удалёнке я почти всегда держу телефон на подставке с медленной индукционной зарядкой на 80% - и от батареи телефон работает только когда я куда-либо выбираюсь.
Если бы вы сфокусировались на том, чтобы по отдельности отдать все дорожки в миди + бонусом отдельно вокал, вы бы забрали себе весь рынок.
Обладая минимальными навыками использования аудио редакторов и имея все партитуры в midi можно делать намного более качественный выхлоп, чем синтезирование звука нейросетью. В профессиональном сведении и мастеринге пока что нет и близко ничего автоматизированного, что бы могло превзойти человеческие уши.
Git с котиками куда полезнее. Ну или классический git book. А тут фривольный пересказ с упущением многих важных моментов. Выглядит как не очень реферат. Рекомендовать как туториал точно не стоит.
Увы, при более-менее нагруженном UI (например, таббар с градиентами) будет дико тормозить. Непрактично. И, главное, это не чистый qss.
Виндовые кнопки, к примеру, отрисовывается с анимациями, но это платформозависимое решение, там под капотом winapi дёргается. И это тоже не чистый qss.
Я тут попробовал еще раз перечитать то, что написал автор. Как я понял, он взял исходники некоторых тем из Qt5 и скомпилил их в свой пакет в слегка видоизменённом стиле, опустив при этом вопросы лицензирования. При этом слегка упустив то, что Qt может собираться статически. До изучения системы плагинов Qt автор пока ещё не дошел.
Я не знаю, что такое “стили .so”. Поясните, что вы имеете в виду? Обычно под .so понимают расширение для динамических библиотек в линуксе. Это никак не связано с Qt и темами.
В документации Qt примеров достаточно. Впрочем, как я уже написал, вы просто вызвали setStyle :)
Попробуйте сделать анимации на qss. Единственный способ, который я знаю, это использование QPropertyAnimation с ручным переопределением обработчика paint event. Но это уже не qss.
Если вы попробуете разработку с QML, то возвращаться на виджеты не захотите. Ну разве что вы любите мешать UI код и бизнес логику. И документации предостаточно. Попробуйте открыть официальную документацию по Qt. Там про стили и QML написано даже больше, чем про виджеты.
Ок. Вы показали как загрузить стиль. По сути вы описали два метода из документации по Qt - перечислить стили, установить стиль.
И да, заголовок про ненужность QML - слишком громкий. Можете на qss и виджетах сделать переливающийся фон у кнопки? На QML это пару строк кода и будет с большего делаться на GPU, на чистом qss вы не сделаете вообще никаких анимаций.
Вы просто немного поиграли со стилями, слово «шаблон» в контексте вашей статьи мне непонятно. Сразу хочется у вас спросить, а вы исходники Qt в той части где идёт работа с qss открывали?
В целом, поддержка css (qss) в Qt - это чистого вида натягивание совы на глобус. Причём в кулуарах одной из конференций мне довелось об этом поговорить с разработчиками. Просто в то время это был тренд и не было нормальных альтернатив для быстрого прототипирования стилизованных окон.
На текущем проекте (энтерпрайз, куча легаси) у нас обвязка, которая на основе json генерирует qss со всеми нужными стилями. И я задолбался подпирать костылями то, что где-то изначально упустили. Наиболее классическая ситуация - это когда разработчики виджетов не совсем аккуратно реализуют поддержку setFocus, setParent внутри каких либо обработчиков и повреждается внутренний кэш qstylesheet (там вектор указателей на QObject) - и в процессе смены стилей в лучшем случае всё дико тормозит, а в худшем - access violation из-за обращений к уже удалённым объектам.
Мой личный вывод - если вы всё ещё сидите на виджетах, то наследуйтесь от QStyle либо QProxyStyle и ручками, под каждую платформу, пилите нужный стиль. Программно, без всяких там qss. Будет намного более предсказуемо и быстро.
Прямо таки решается куда редиректнуть по время сканирования? Что за фантазии и причём тут вообще QR коды (?кликбейт), если речь о сервисах по сокращению ссылок?
Зачем эта реклама в новостях на Хабре?
Минусующие дадут пояснения? Вроде всё вежливо и по существу. Без минусов к статье / карме написал.
Статьи у вас, как правило, хорошие. Но вот новости… ну кто так пишет/переводит?
История чатов, архив переписки и тп.
P.S. я имею в виду, если прямо сейчас собрать все проекты в мире, где есть баг баунти и найденная уязвимость в кутэ - можно сорвать большой куш :)
А какие мировые практики в bug bounty в таких случаях, когда бага не в самом софте, а в сторонней зависимости (у которой, тоже возможно есть свой bug bounty)?
То есть вы утверждаете, что закрытия бага в QtNetwork недостаточно и абсолютно такая же уязвимость через неинициализированную память остаётся в телеге даже с новой версией Qt?
Или же с пропатченным Qt уязвимость превращается в обычный баг?
Я практически целиком прочитал ваш опус, но, несмотря на ваши утверждения, так и не понял, это всё-таки баг в телеграмме или в QtNetwork и он теоретически воспроизводим в других приложениях?
Количество циклов как раз таки уменьшается. 5 раз зарядить до 80% это 4 цикла. Плюс, аккумулятор чуть дольше будет жить если его не заряжать на максимум. И если телефон всё время на зарядке - то циклы не тикают :)
А если люди, которые как я, любят сидеть на последних или предпоследних версиях айфонов (зачем это именно мне - отдельная долгая история), то такой финт значительно увеличивает цену продажи предыдущего б/у телефона.
Потенциальный покупать видит красивые циферки, что количество циклов сильно меньше количества дней эксплуатации и ведётся на это, думая что телефон мало использовался.
Хотя сейчас на удалёнке я почти всегда держу телефон на подставке с медленной индукционной зарядкой на 80% - и от батареи телефон работает только когда я куда-либо выбираюсь.
Если бы вы сфокусировались на том, чтобы по отдельности отдать все дорожки в миди + бонусом отдельно вокал, вы бы забрали себе весь рынок.
Обладая минимальными навыками использования аудио редакторов и имея все партитуры в midi можно делать намного более качественный выхлоп, чем синтезирование звука нейросетью. В профессиональном сведении и мастеринге пока что нет и близко ничего автоматизированного, что бы могло превзойти человеческие уши.
Ваша модель может отдавать сгенерированную музыку отдельными дорожками для каждого инструмента? Как бы именно это - киллер фича Suno.
Т.е. вжух-вжух и в 50 раз снизили? Такое чувство что ваши цифры и текст нагенерировала какая-то слабенькая модель :)
Git с котиками куда полезнее. Ну или классический git book. А тут фривольный пересказ с упущением многих важных моментов. Выглядит как не очень реферат. Рекомендовать как туториал точно не стоит.
Увы, при более-менее нагруженном UI (например, таббар с градиентами) будет дико тормозить. Непрактично. И, главное, это не чистый qss.
Виндовые кнопки, к примеру, отрисовывается с анимациями, но это платформозависимое решение, там под капотом winapi дёргается. И это тоже не чистый qss.
Я тут попробовал еще раз перечитать то, что написал автор. Как я понял, он взял исходники некоторых тем из Qt5 и скомпилил их в свой пакет в слегка видоизменённом стиле, опустив при этом вопросы лицензирования. При этом слегка упустив то, что Qt может собираться статически. До изучения системы плагинов Qt автор пока ещё не дошел.
Я даже не знаю, как прокомментировать ваш поток сознания :)
Для этого уже давно есть QtQuick / QML.
Я не знаю, что такое “стили .so”. Поясните, что вы имеете в виду? Обычно под .so понимают расширение для динамических библиотек в линуксе. Это никак не связано с Qt и темами.
В документации Qt примеров достаточно. Впрочем, как я уже написал, вы просто вызвали setStyle :)
Попробуйте сделать анимации на qss. Единственный способ, который я знаю, это использование QPropertyAnimation с ручным переопределением обработчика paint event. Но это уже не qss.
Если вы попробуете разработку с QML, то возвращаться на виджеты не захотите. Ну разве что вы любите мешать UI код и бизнес логику. И документации предостаточно. Попробуйте открыть официальную документацию по Qt. Там про стили и QML написано даже больше, чем про виджеты.
Ждём ваших результатов.
Ок. Вы показали как загрузить стиль. По сути вы описали два метода из документации по Qt - перечислить стили, установить стиль.
И да, заголовок про ненужность QML - слишком громкий. Можете на qss и виджетах сделать переливающийся фон у кнопки? На QML это пару строк кода и будет с большего делаться на GPU, на чистом qss вы не сделаете вообще никаких анимаций.
Вы просто немного поиграли со стилями, слово «шаблон» в контексте вашей статьи мне непонятно. Сразу хочется у вас спросить, а вы исходники Qt в той части где идёт работа с qss открывали?
В целом, поддержка css (qss) в Qt - это чистого вида натягивание совы на глобус. Причём в кулуарах одной из конференций мне довелось об этом поговорить с разработчиками. Просто в то время это был тренд и не было нормальных альтернатив для быстрого прототипирования стилизованных окон.
На текущем проекте (энтерпрайз, куча легаси) у нас обвязка, которая на основе json генерирует qss со всеми нужными стилями. И я задолбался подпирать костылями то, что где-то изначально упустили. Наиболее классическая ситуация - это когда разработчики виджетов не совсем аккуратно реализуют поддержку setFocus, setParent внутри каких либо обработчиков и повреждается внутренний кэш qstylesheet (там вектор указателей на QObject) - и в процессе смены стилей в лучшем случае всё дико тормозит, а в худшем - access violation из-за обращений к уже удалённым объектам.
Мой личный вывод - если вы всё ещё сидите на виджетах, то наследуйтесь от QStyle либо QProxyStyle и ручками, под каждую платформу, пилите нужный стиль. Программно, без всяких там qss. Будет намного более предсказуемо и быстро.
Прямо таки решается куда редиректнуть по время сканирования? Что за фантазии и причём тут вообще QR коды (?кликбейт), если речь о сервисах по сокращению ссылок?