Потом одумаемся и выложим лтс ветку в открытый доступ.
Они не одумались, есть давний договор с KDE публиковать в течении года изменения. Поэтому они опубликовали 5.15.3, но текущая версия что-то типа 5.15.8.
С учетом их текущей политики в общем-то и не очень важно. Отсутствие доступа к LTS ветке вынудило использовать LTS форк от проекта KDE, поэтому не их сборки среди которых LTS не было, ни их git репозиторий не очень-то и нужны.
Как-то неправильно акценты расставлены. Они заблокировали скачивание Qt в скомпилированном виде под официально поддерживаемые платформы. Скачать исходники из git и собрать самому это никак не мешает.
Ядро linux - довольно тяжёлое, в нём много лишнего, совершенно не нужного для мобильных устройств.
В Linux kernel практически каждый модуль можно выключить в конфигураторе ядра, а часто и для отдельного модуля есть пяток опций чтобы выключить внутри модуля ненужное.
Вроде JIT в автовекторизацию, по идее этот подход можно использовать для Эльбрус. Правда автовекторизация работает далеко не всегда даже в AOT где по идее можно использовать намного больше CPU/memory по сравнению с JIT. И вообще может Java runtime нужной версии не портирован и запускали в режиме эмуляциии x86
Может это и хорошо, быстрее можно переучиться на что-нибудь более эргономичное. Например тайловые оконные менеджеры и какой-нибудь современный командный интерпретатор типа fish (ну или bash/zsh + куча дополнений)
Чего реально не хватает в линуксе, так это среды разработки уровня Visual Studio. Да, нативной, написанной не на джаве или электроне. С мощным отладчиком
А может не хватает именно "Visual Studio", чтобы даже пункты меню были на тех же местах? KDevelop, Qt Creator сразу приходят на ум, и для DE на основе Qt у них вполне стандартный интерфейс. И разве в 21ом веке это важно? В эпоху LSP вы можете в консольном редакторе выделить кусок кода и выбрать в списке доступных рефакторингов например извлечь в отдельный метод, не говоря уже о автодоплнениях, переходу по символу и т.д. и все это будет работать в огромных проектах.
Без дурацких make-файлов и bash-скриптов. Вот это все, унаследованное из 80-х - реальный недостаток, и к сожалению он засел в мозгах линукс-разработчоков настолько
А какое отношение make/bash имеет к IDE? Не хотите, не используйте их в своей системе сборке, в чем проблема? И на минуточку "нейронные сети" например были изобретены в где-то в 1940-1950, может тоже откажемся от этих устаревших технологий?
Это показывает что в приложении используется "flutter", но не то что это "flutter" приложение. Если дошло до распаковки apk файлов, то ведь можно увидеть что там "дофига" kotlin/java кода, и скорее можно сказать что это "native" приложение с вкраплениями flutter, чем наоборот?
Насколько я понимаю, речь идёт о том, что в rust некоторые виды действий не имеют Option, и если условие не выполняется
А какие именно "действий"? В голову приходит только "fallible allocation", но обертку над менеджером памяти ядра все равно нужно будет делать отдельно, стандартные функции выделения памяти использовать вряд ли удастся, например из-за наличия kmalloc и vmalloc. А раз придется делать заново, то в чем сложность добавить Result/Option в новые функции выделения памяти не очень понятно.
Претензии, которые предъявляют к Rust'у весьма любопытны. Ядро не должно падать по "одной ошибке", даже если это логическая ошибка, а в Rust весьма трудно избежать паник
Это на мой взгляд самый слабый аргумент против. В изначальном ядре, без патчей для добавления поддержки Rust, есть функция "panic", и куча ее вызовов с помощью макросов BUG/BUG_ON и так далее. Поэтому почему Rust в отличие от С должен быть особенным и не содержать неявных вызовов panic! совершенно непонятно.
Ну формально говоря в основном это правда. IBM поднялся именно на военных заказах, разработку Интернет (ARPANET) оплатил DARPA.
А откуда у них деньги на выкуп акций?
https://habr.com/ru/company/selectel/blog/574030/
Но Sony вроде прекратил заниматься мобильными телефонами:
https://habr.com/ru/news/t/446014/
nginx и evernote давно вроде принадлежат американским корпорациям,
или я что-то пропустил?
Просто взяли и применили https://ru.wikipedia.org/wiki/Аксонометрическая_проекция два раза, в чем открытие?
Они не одумались, есть давний договор с KDE публиковать в течении года изменения. Поэтому они опубликовали 5.15.3, но текущая версия что-то типа 5.15.8.
С учетом их текущей политики в общем-то и не очень важно. Отсутствие доступа к LTS ветке вынудило использовать LTS форк от проекта KDE, поэтому не их сборки среди которых LTS не было, ни их git репозиторий не очень-то и нужны.
Как-то неправильно акценты расставлены. Они заблокировали скачивание Qt в скомпилированном виде под официально поддерживаемые платформы. Скачать исходники из git и собрать самому это никак не мешает.
А что с остальными? На операции ведь еще есть анестезиолог, медсестра,
помощники хирурга, то есть там целая банда "клеймителей" должна быть.
В Linux kernel практически каждый модуль можно выключить в конфигураторе ядра, а часто и для отдельного модуля есть пяток опций чтобы выключить внутри модуля ненужное.
Как все основные части были под lgpl 4 версии, так в 5 и остались. Что поменялось?
Вроде JIT в автовекторизацию, по идее этот подход можно использовать для Эльбрус. Правда автовекторизация работает далеко не всегда даже в AOT где по идее можно использовать намного больше CPU/memory по сравнению с JIT. И вообще может Java runtime нужной версии не портирован и запускали в режиме эмуляциии x86
Изображений вообще не видно
Интересно какая у них версия Qt? Так как на неё весь интерфейс завязан у них вроде была древняя древняя Qt.
Может это и хорошо, быстрее можно переучиться на что-нибудь более эргономичное. Например тайловые оконные менеджеры и какой-нибудь современный командный интерпретатор типа fish (ну или bash/zsh + куча дополнений)
А может не хватает именно "Visual Studio", чтобы даже пункты меню были на тех же местах? KDevelop, Qt Creator сразу приходят на ум, и для DE на основе Qt у них вполне стандартный интерфейс. И разве в 21ом веке это важно? В эпоху LSP вы можете в консольном редакторе выделить кусок кода и выбрать в списке доступных рефакторингов например извлечь в отдельный метод, не говоря уже о автодоплнениях, переходу по символу и т.д. и все это будет работать в огромных проектах.
А какое отношение make/bash имеет к IDE? Не хотите, не используйте их в своей системе сборке, в чем проблема? И на минуточку "нейронные сети" например были изобретены в где-то в 1940-1950, может тоже откажемся от этих устаревших технологий?
Это показывает что в приложении используется "flutter", но не то что это "flutter" приложение. Если дошло до распаковки apk файлов, то ведь можно увидеть что там "дофига" kotlin/java кода, и скорее можно сказать что это "native" приложение с вкраплениями flutter, чем наоборот?
Когда это Яндекс.Go стал flutter приложением?
А какие именно "действий"? В голову приходит только "fallible allocation", но обертку над менеджером памяти ядра все равно нужно будет делать отдельно, стандартные функции выделения памяти использовать вряд ли удастся, например из-за наличия kmalloc и vmalloc. А раз придется делать заново, то в чем сложность добавить Result/Option в новые функции выделения памяти не очень понятно.
Это на мой взгляд самый слабый аргумент против. В изначальном ядре, без патчей для добавления поддержки Rust, есть функция "panic", и куча ее вызовов с помощью макросов BUG/BUG_ON и так далее. Поэтому почему Rust в отличие от С должен быть особенным и не содержать неявных вызовов
panic!совершенно непонятно.А смысл покупать железо которое ты будешь использовать с Linux и выбирать не поддерживаемое или плохо работающее с Linux железо?