> комбинация из применения умных указателей во время выполнения и проверок на этапе компиляции

Что из этого не умеет делать с++?

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

ну хоть кто-то сделал на расте что-то полезное

слава б-гу

Красота. Хорошая новость.

> В минимальной конфигурации ядро требует для своей работы всего 13 КБ оперативной памяти

А сколько на диске занимает?

>ядро требует для своей работы всего 13 КБ оперативной памяти.

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

виндакапец уже настал. линухкапец на подходе...

>Компания Vivo

Прощупывают что-то через суббренд.

Если кто не знал, то:
BBK → Oppo и Vivo.
Oppo → realme и OnePlus.
Vivo → iQOO

p.s.:
https://www.opennet.me/opennews/art.shtml?num=58613

Надо посчитать сколько там у них unsafe. ЕВПОЧЯ.

> ...ошибками при работе с памятью, которые по статистике Google и Microsoft составляют 70% от всех уязвимостей в операционных системах

напомню: в ВАШИХ операц.системах! Написанных ВАШИМИ индусами и прочими "специально отобранными HRами" фуфелами.

Я вот пишу на C# - да, довольно далеко от C++, но... кто мешает в том же С++ юзать "умные указатели"?? Факт тот, что "проблемы с памятью" больше проблема низкоквалифицированных, ДЕШЁВЫХ кадров, а не языка. Писали же как-то в 2000-ых большие системы! И ничё, без всяких Растов вылизывали код и работало со 100% гарантией. Эмбед - тот вообще на Си - тоже устройства работают ГОДАМИ БЕЗ СБОЕВ. Так что лажа с памятью - извини, макросоfак, твоя личная халтура.

Отличная новость. Пойдет в массы - найдут толпу других ошибок и уязвимостей, кроме как работы с памятью. Да еще и unsafe в продуктиве подсыпет радостей, и все вернется на круги своя С и С++
Это поделие на бумаге выглядит красиво, эксплуатация покажет другое. "Вот те крест на все пузо" :)

Раст вошел в рыночек ОС, и теперь сишка будет вытеснена! Лет через 30 - так точно!

Поделка уровня Tizen, которую даже из часов уже выкинули.

А почему не ресдох? Она - всё?

Hmm. We’re having trouble finding that site.

We can’t connect to the server at blueos.vivo.com.

If you entered the right address, you can:

    Try again later
    Check your network connection
    Check that Firefox has permission to access the web (you might be connected but behind a firewall)

Ну и на фиг. Насколько криво DNS настроен, что у меня не резолвится.

DNSSEC и DoT отключать ради китайщины не буду.

Очень интересно. Надо попробовать на Raspberry Pi Pico2.

очередная фуксия?

Но... на расте ничего больше хелловрота не написано...

про безопасную работу с памятью всего один абзац, я не куплю

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

13 RAM, ARM, RISC-V, POSIX, Rust.
Да это офигенное ядро!

>Предоставляется собственная файловая система

У нас что и так файловых систем в зоопарке мало (и при этом ни одной нормальной нет)? Теперь для этого говна реализации писать и отлаживать придётся, а файловые системы - это rocket science.

В тексте новости забыли важную деталь упомянуть: компания КИТАЙСКАЯ. Что сразу означает, что тем, у кого действуют партийные комитеты, по-умолчанию не то что доверия нет, а есть сразу активное недоверие.

И почему же не 10 из 10?

Интересно, кто использует в энтерпрайзе зюзю вместо нормального RHEL или его форков.

SUSE кинул наш Великий Центральный Банк с поддержкой. Так что можно пользоваться, но осторожно.

Это всё от того, что у разрабов Суси гнилая плоть, не кошерная!

Обратите внимание, на каком языке он написан.

Печать 🖨️ уже во многом устаревшая сфера.
Постепенно сходит на нет, как дискеты 💾 когда-то

"With my mostly external work I got a victim of it and they laid me off"

Скорее, под external work имеется в виду не удаленная работа, а работа по внешним, связанным со стеком печати задачам, напрямую не связанным с сиюминутными бизнес-интересами менеджеров.

С печатью в Linux дичь полная. Если сканирование работает из коробки, то с печатью танцы с бубном как на этапе настройки так на этапе работы. Единственное спасение - это печать через виртуальные машины Windows.

> с 2021 года взявшего на себя сопровождение сервера печати CUPS

Это того самого CUPS, который дырявый как шерето?
Уязвимости нашли в 2024.

> получил сообщения от более 30 работников Canonical, которые выразили недоумение решением по его увольнению, так как он проделывал значимую работу по поддержанию стека для вывода на печать

И результаты этой работы можно почить тут
opennet.ru/opennews/art.shtml?num=61942

> Из-за потери работы Тилль столкнулся с необходимостью как-то зарабатывать на жизнь

Ого! Ничоси! Разве так бывает?
Но Щтольман рассказывал что "творчество — это удовольствие и награда само по себе" и "Факты говорят, что люди программируют не ради богатства"

> намерен перевести проект на финансирование за счёт спонсоров

В соседней теме обсуждали инициативу Maintenance Fee.
И что-то аноны платить не собираются.

Бедный Тилль!
Надеюсь он не помрет с голоду, ожидая подачки от неблагодарных потрбятелей из Сообщества™

> Из-за потери работы Тилль столкнулся с необходимостью
> как-то зарабатывать на жизнь

Беднягя.
С 2006 года страдал фигней за деньги Каноникла и в ус не дул.
А потом ВНЕЗАПНО оказалось, что деньги беруться не из воздуха))

Добро пожаловать в реальный мир, друг!

ЗЫ: интересно, а сколько еще таких непонятно чем занимающихся по корпам распихано?

Все что нужно вам знать про шв@60дку и разработку затобесплатного некакввенде.

"Нам в цапопикал этот цупс нахрен и не нужен! Еще платить какому-то хмырю зарплату непонятно вообще за что!" (с)Кумар Нacpaл Нии6@ать Раджа, только что повышенный из глиномесов в старшие менеджеры.

Вам, кстати, тоже не нужен. Вы бохатые и купите себе принтер с ps, ни копейки не переведя автору (который это прекрасно понимает, судя по тому что клянчит денег у работодателей или вон фаундейшна, а не открыл страничку на поцреоне)

Потом будете cat'ом печатать. Ну а управление вам "и нахрен не сдалось!" как обычно.

Объясните дураку, вот подключил я принтер с драйверам к cups серверу.
Какие потом драйвера выбрать на windows для удаленного доступа
к этому принтеру ? (родных допустим для windows нет)

Кто-то PAPPL от создателя CUPS использовал ?

https://www.msweet.org/pappl/

Напоминает анекдот про дрова (дрова нужны, нет, утром дров нет).

Видимо и Каноникал уже не нужен десктоп (уже давно не приоритет) с принтерами. Весь уклон на сервер.

В новости как всегда всё переврали. По пунктам.

1. Поддержку и разработку CUPS ведёт Michael R Sweet, который уволился из Apple. И, судя по коммитам https://github.com/michaelrsweet , проблем с финансированием у него нет.

2. Герой топика сопровождает только cups-filters, и, надо отметить, особо не напрягается https://github.com/tillkamppeter Вклад на уровне обычного человека, который кодит в свободное от работы время.

3. Перед отправкой CUPS в свободное плавание Apple пытались полностью переделать CUPS, избавившись от устаревшего PPD с параллельным выкидыванием поддержки всех старых принтеров. После перехода CUPS в OpenPrinting и увольнения Мишани ничего особенного не изменилось. Мишаня продолжил пилить хотелки Apple, а поток денег в его сторону даже увеличился. Есть серьёзное подозрение, что так Apple пытается протащить непопулярное решение. Также в интересах Apple избавиться от поддержки Kerberos, что там, собственно, и происходит.

4. И немного про выкидывание PPD. Многие согласны, что эта технология устарела, но с одной стороны у нас куча старых и надёжных принтеров, которые печатают под линуксом, а с другой - попытка родить фреймворк, на который должны перейти все производители. К тому же IPP Everywhere и PAPPL до сих пор не умеют того, что умеет PPD - выдавать адекватную информацию о своих настройках. По этой причине каждый производитель обязан не только запилить свой сервер (с помощью фреймворка PAPPL), но и сделать диалог настроек под линейку своих принтеров (Для сравнения с PPD, достаточно было предоставить этот файлик PPD, где содержится вся информация о принтере).

5. Также стоит отметить, что до сих пор ни один производитель не сделал адекватную поддержку принтеров с помощью новой технологии под линукс, HP до сих пор добавляет новые принтеры в виде PPD, игнорируя попытки сообщества сделать поддержку PAPPL.

Вывод. Ситуация с печатью весьма неоднозначная. С одной стороны разрабы CUPS настоятельно советуют не использовать PPD для новых принтеров, в то время как альтернатива в виде PAPPL очень сложная и до сих пор не готова.

> столкнулся с необходимостью как-то зарабатывать на жизнь

Я тоже как-то столкнулся. Пришлось быстро взрослеть.

> "Из-за потери работы Тилль столкнулся с необходимостью как-то зарабатывать на жизнь"

А вот это автор новости серьёзно пишет? Всегда надо быть готовым к потери работы!
Нужно завязывать на себя всё, до чего можно дотянуться. И уходить тоже после увольнения с тем, до чего можно дотянуться! Если так работал бы, то его Red Hat быстро бы наняли.

Пожелаю удачи Тиллю во всех его начинаниях. Принципиальный человек. А Cannonical ничего хорошего не пожелаю.

Ещё, пожалаю Тиллю изменить лицензию CUPS на GPL_v3. Сейчас там пермиссивная Апаче2.

>для продолжения развития OpenPrinting намерен перевести проект на финансирование за счёт спонсоров или найти работодателя, который по аналогии с Canonical позволил бы ему заниматься проектом OpenPrinting на своём рабочем месте

Да просто выкинуть. Если бы было нужно - канони-калл бы разраба не выкинул. Рыночек порешал.

>после того как компания Apple потеряла интерес к разработке проекта для платформ, отличных от macOS

Опять же рыночек порешал. Есть десктопные ОС, скот должен сидеть на них. А линукс как рынок для офисных програм бесперспективен. Для игрушек ещё может быть - покуда срезаем косты через перевод всех дров на Zink + GSP и выкидыванием всего без Vulkan+GSP и покуда Вульва интерес не потеряла.

> или найти работодателя, который по аналогии с Canonical позволил бы ему заниматься проектом OpenPrinting на своём рабочем месте.

Сейчас мс (лучший друг опенсорса) подсуетится.

На AI заменили =) А то ли ещё будет…

Интересно, на сколько реально увидеть десктопы с CPU ARM и главное GPU Mali? Почему не делают дешевые видеокарточки, на mali для десктопа?

...а для Mali T720 делать поддержку OpenGL 3.0 так никто не собирается.

Я недавно обнаружил, что некоторые люди, которым мы доверяем производительность операций с GPU на стороне процессора,.. не умеют или не всегда хотят верно бенчмаркить.

Вот их бенчмарк: https://github.com/vkmark/vkmark (анализ для коммита 2c5f020005a597fb4b7d9ed1eaa1bf40e466bf01, все лицензии на код находятся в соответствующих репозиториях)

>vkmark offers a suite of scenes that can be used to measure various aspects of Vulkan performance.

https://www.collabora.com/news-and-blog/blog/2017/07/18/vkma.../

>A few years ago we were pleasantly surprised to learn that developers were using glmark2 as a testing tool for driver development, especially in free (as in freedom) software projects. This is a goal that we want to actively pursue for vkmark, too.

Давайте посмотрим, как эти понтовые заявления соотносятся с реальностью.

```c++
// With a lot of contractions
class Scene
{
public:
...
    virtual bool is_valid() const;
...
    virtual VulkanImage draw(VulkanImage const&);
...
    virtual void update();
...
    unsigned int average_fps() const;
...
};
```

1. Виртуальные функции, Карл!
2. `unsigned int average_fps() const;` - СРЕДНЕЕ. FPS.
3. Функции не являются inline. И не force-inlined.

```c++
scene.start();

while (scene.is_running() &&
        !(should_quit = ws.should_quit()) &&
        !should_stop)
{
    ws.present_vulkan_image(
        scene.draw(ws.next_vulkan_image()));
    scene.update();
}

auto const scene_fps = scene.average_fps();

log_scene_fps(scene_fps);
```

Где находятся функции (в отдельном translation unit):

```c++

void Scene::start()
{
    current_frame = 0;
    running = true;
    start_time = Util::get_timestamp_us();
    last_update_time = start_time;
}

unsigned int Scene::average_fps() const
{
    return last_update_time > start_time ?
        current_frame * 1000000 / (last_update_time - start_time) : 0;
}

bool Scene::is_running() const
{
    return running;
}

VulkanImage Scene::draw(VulkanImage const& image)
{
    return image.copy_with_semaphore({});
}

void Scene::update()
{
    auto const current_time = Util::get_timestamp_us();
    auto const elapsed_time = current_time - start_time;

    ++current_frame;

    last_update_time = current_time;

    if (elapsed_time >= duration)
        running = false;
}

void log_scene_fps(unsigned int fps)
{
    auto const fmt = Log::continuation_prefix + " FPS: %u FrameTime: %.3f ms\n";
    Log::info(fmt.c_str(), fps, 1000.0 / fps);
    Log::flush();
}

uint64_t Util::get_timestamp_us()
{
    struct timespec ts;
    clock_gettime(CLOCK_MONOTONIC, &ts);
    uint64_t const now = static_cast<uint64_t>(ts.tv_sec) * 1000000 +
                        static_cast<uint64_t>(ts.tv_nsec) / 1000;
    return now;
}

```

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

```c++
current_frame = 0;
running = true;
start_time = Util::get_timestamp_us();
last_update_time = start_time;

while (running &&
        !(should_quit = ws.should_quit()) &&
        !should_stop)
{
    auto image = ws.next_vulkan_image();
    VulkanImage draw_result = image.copy_with_semaphore({});
    ws.present_vulkan_image(draw_result);

    struct timespec ts;
    clock_gettime(CLOCK_MONOTONIC, &ts);
    uint64_t const current_time = static_cast<uint64_t>(ts.tv_sec) * 1000000 + static_cast<uint64_t>(ts.tv_nsec) / 1000;
    uint64_t const elapsed_time = current_time - start_time;

    ++current_frame;

    last_update_time = current_time;

    if (elapsed_time >= duration){
        running = false;
    }
}

unsigned int const scene_fps =     last_update_time > start_time ? current_frame * 1000000 / (last_update_time - start_time) : 0;

auto const fmt = Log::continuation_prefix + " FPS: %u FrameTime: %.3f ms\n";
Log::info(fmt.c_str(), scene_fps, 1000.0 / scene_fps);
Log::flush();
```

1. Мы измеряем не FPS, а время. Но... они сначала вычисляют FPS из времени, усекают его до целого числа, затем время из FPS, и также усекают его. Это была проблема, которую я заметил первой, что заставило меня покопаться в этом.
2. Они используют `clock_gettime` вместо `__rdtsc` + `_mm_lfence` для получения точных тиков ЦП. Ни один разумный микро-бенчмарк не полагается на время, предоставляемое через системные вызовы.
3. В коде измерения времени - ненужные операции.
4. Мы видим ненужные операции между точками, где мы получаем время. В идеале `ws.present_vulkan_image(scene.draw(ws.next_vulkan_image()));` должно быть сендвичем между двумя гаджетами

```c++
_mm_lfence();
const uint64_t current_time = __rdtsc();
_mm_lfence();
```
.

6. Вместо измерения времени отдельных операций, они проводят бенчмаркинг в течение заранее заданного периода времени. Это противоположно тому, как обычно делают бенчмаркинг.
7. Они вычисляют средний FPS, используя `last_update_time - start_time` в качестве времени, а не сумму точных интервалов.
8. Никакой коррекции систематической погрешности, вносимой самими инструкциями измерения времени.

Мы просто предположили инлайнинг, но разумеется, компиляторы не настолько умны для этого. Для правильного бенчмаркинга им понадобится `MainLoop` в качестве шаблона и предоставление реализаций сцен в качестве аргументов шаблона, тогда компилятор заинлайнит реализацию прямо в горячий цикл.

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

Вот небольшой патч https://0x0.st/8kvd.patch , просто запихивающий `__rdtsc` туда, без каких-либо других необходимых изменений этого. И график гистограммы (нормализованной до плотности вероятности) времен (оставлен только первый пик, и на самом деле измерения расположены с 8 тиками, так что 8 тиков с количеством 0, затем тик с количеством, а затем снова 8 тиков с количеством 0 и тик с количеством) и соответствующая kernel density estimation. 2 изображения, одно в крупном масштабе, другое увеличено возле моды распределения, обратите внимание, что счетчики гистограммы очень шумные, более чем в два раза больше моды на ее пике. Команда была `./src/vkmark -D <device uuid> -p immediate -b effect2d:kernel=none:duration=4200000 --run-forever > results.txt`, после чего парсинг скриптом.

Вот что вам нужно знать об инженере из Collabora, который это разработал.

О, может быть, другие бенчмарки дадут лучшие результаты? Я нашел `https://github.com/RippeR37/GL_vs_VK` (коммит 735d153f7d85b7ce8d7097e89e877304ee23180b) , понтовую часть Phoronics Test Suite.

>This project is part of my master-thesis and aims to compare OpenGL and Vulkan API in terms of API-related overhead.

Если вы думаете, что этот бенчмарк отличается... нет, он в основном повторяет те же ошибки (за исключением виртуальных функций): неиспользование `rdtsc` напрямую (вместо этого он использует `glfwGetTime` из динамической библиотеки, определенной как
```c++

GLFWAPI double glfwGetTime(void)
{
    _GLFW_REQUIRE_INIT_OR_RETURN(0.0);
    return (double) (_glfwPlatformGetTimerValue() - _glfw.timer.offset) / _glfwPlatformGetTimerFrequency();
}
```

где

```c++
uint64_t _glfwPlatformGetTimerValue(void)
{
    struct timespec ts;
    clock_gettime(_glfw.timer.posix.clock, &ts);
    return (uint64_t) ts.tv_sec * _glfw.timer.posix.frequency + (uint64_t) ts.tv_nsec;
}
```
- да, те же яйца, только в профиль), фактический вызов получения времени находится в отдельной функции в отдельном translation unit, а не заинлайнен в нужное место.

и только для малины все никак и никак не напишут нормальный драйвер  Вулкан

Не нужно. Уже есть NsCDE.

Ну это точно выглядит лучше жтк4

Выглядит лучше Gnome.

KDE никак не могут решить: прямые углы у окон делать или скругленные. А тут решили просто - пусть зависит от того, с какого расстояния смотреть.

Главное, никаких udisks и gvfs.

Но к такому роскошному рабочему столу нужна ещё и клавиатура без клавиш-стрелочек. Для аутентичности.

Пропатчили, стало быть, BSD под CDE...

Шрифты, конечно, просто ух.

Ничто не греет душу так, как старая добрая казённая соляра нахаляву)

Одновременно режет глаза и штырит, капитально.

Но, колхозное происхождение - скрыть невозможно.

> В 2012 году код CDE 2.1 был открыт консорциумом The Open
> Group под лицензией LGPL.

Вот если ю они так в 2002 расщедрились... мир был бы немного другим.

А когда уже портируют интерфейс редмонд и перестанут выделываться?

Братишка! Братишка! Я тебе принес DE из 90х. Ну что ты сердишься? Давай посидим, попользуемся вместе

По своему мило, но субъективно Be/Haiku как развитие этого дела всё же лучше.

А так забавно конечно. Серый фон проводника, потому что на ЭЛТ белый режет глаза (и без всякого HDR) и вообще жжёт люминофор и сажает катоды почём зря. Интересно, проводник тоже с открытием каждой папки в новом окне и навигацией через контекстное меню?

Подозреваю сабж работает без systemd, wayland?

Лучшая DE без всякой инклюзивности которая сейчас так и прёт!

Хех, прям пахнуло историей )))
Хотя нет, в прошлом году у одного заказчика был сервер на HP-UX / Itanium 2 - там такой же был рабочий стол ....

много лишних элементов интерфейса, много места жрётся в пустую.

заголовок окна - один кирпич, текстовые элементы управления - еще кирпич,

лучше всего вопрос решен в мак систем классик.

а выглядит вобщем неплохо, гараздо гараздее плоскотни.

Раньше программисты делали для программистов. А потом появились дэзайнэры.

Ой! Прямо салярис!!!!

Использую на OpenBSD Fluxbox. Проблем не вижу, DE не нужны.

Астрологи сообщают что число некромантов выросло вдвое...🤣

Надо все остальные среды рабочего стола под сабж портировать! Вот тогда заживём, без systemd, без wayland!

В принципе от такого никто не застрахован так что просто надо это принять

> ведущую на сайт pypj.org (от официального сайта pypi.org домен отличается буквой "j" вместо "i" с расчётом на невнимательность получателя)

А ведь могли ɪ или í использовать еще, например и кучу других похожих букв
Ну если рассчитано на тех кто один фиг не смотрит
В латинице вообще(в расширенной) десятка полтора производных от i

Правильные адреса, проверяйте внимательно:

www:    https://pypі.org
E-mail: noreply@pypі.org

По теме:
1. Разрабам необходимо подписывать релизы пакетов OpenPGP.
2. Пользователям кроме проверки цифровой подписи следить за неизменностью ключа по сравнению с предыдущим релизом, а если ключ изменился, то проверять кросс подписи старого и нового ключей.

Надо просто профиксить латинский язык, надо выбросить j из алфавита и оставив i.

Пора уже нейросетью скопировать все нужные пакеты и закрыть эту богодельню.

Много питонисты зарабатывают? Говорят питонистов джунов после курсов расплодилось, что не устроиться.

У меня одного PyPI читается в голвое как paypal?

Не можешь победить - возглавь.

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

PS: Это, кстати, идея для стартапа, который сможет выполнять эту работу регулярно и со знанием дела.

> AI избавляет от необходимости разбирать документацию на API, отслеживать изменения в API и подбирать правильные вызовы

Это "пробитие дна деградации"

и противоречит

>  рассматривается как инструмент, помогающий в разработке, но не снимающий ответственности за добавляемый год и требующий проверки и контроля за качеством

Дадад, просто автоконверсия говорили они
А потом "Вы что и есть за меня будете?"
Может лучше ручками, чтоб не отвыкать?

Так это вайп или вайб кодинг?

> " Кристиан также высказал идею задействования AI для автоматизации проверки дополнений к GNOME Shell и генерации патчей с учётом изменений, вносимых в новых выпусках GNOME Shell"

Для GNOME, это будет слишком сложно!

> Благодаря применению AI-ассистента, Кристиану потребовалось около пяти часов для портирования

Интересно, сколько бы часов заняло портирование у местных экспертов, воюющих против AI?

Ведь недавно тут новость была, что ИИ на самом деле замедляет разработку (в чреднем на 19%). Значит, без ИИ портирование сабжа заняло бы чуть более 4 часов вместо 5!

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

> Кристиан Шаллер (Christian Schaller), возглавляющий Fedora Desktop Team и группу по развитию десктоп-систем в компании Red Hat, опубликовал результаты оценки пригодности применения больших языковых моделей в процессе разработки графических приложений для Linux. В качестве эксперимента он воспользовался AI-ассистентом Claude для перевода устаревшего графического приложения Xtraceroute на актуальные технологии.

Кринж. Лидеры везде одинаковые что ли? Решил показать на собственном примере как может вышивать крестиком^W^W пользоваться ии. Вы без ии не можете нормальный десктоп сделать, с ии тем более не сможете, только багов больше будет. Готовятся поди к сокращениям.

Не тем дядька занялся.

Надо было GIMP на Qt перетащить.

> AI экономит время, избавляя от необходимости [...] отслеживать изменения в API

А можно ли использовать AI для внесения изменений в API с сохранением обратной совместимости? Чтобы не приходилось использовать AI для избавления от необходимости отслеживать изменения в API?

Сейчас найдётся азиат, который сделает это втрое быстрее без ИИ ассистента...

>Red Hat is an open hybrid cloud technology leader, delivering a consistent, comprehensive foundation for transformative IT and artificial intelligence (AI)

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

"I was curious how well the AI could deal with such a complex API, so I took a look at the code. But it seems that the project doesn’t use Vulkan?

There is `vulkan_renderer.c` but: the render method is a TODO comment, the file doesn’t appear in the sources list in `meson.build`, and isn’t referenced in any other files.

The actual rendering happens in `globe_widget.c` using a for loop over all the pixels in the texture – no GPU rendering. (See `render_3d_globe()`.)"

Очередной "AI"-булшит.

Почему надо постоянно ломать, а не сохранять совместимость по API?

По сути тут можно сказать реализация обычного конвертера на безе ИИ, т.е. находим устаревшую функцию и заменяем ее на новую из описания в базе. С одной стороны для простых прикладных программ это норм, а вот в  системном софте это может быть засада, слишком перегруженным может быть код. ИИ не генерит алгоритмы, а просто переписывает код и использование ИИ-ассистентов это более высокий уровень высокоуровнего программирования.
Сама статья похожа на рекламу Granite.code

скриньте! через месяц в новостях OpenNET:

> В компания Red Hat услышали рекомендации Кристиана Шаллера (Christian Schaller), возглавляющего Fedora Desktop Team, и теперь в компании

Red Hat отсутствует скептическое и негативное отношение к применению AI. Руководство Red Hat выкинула Кристиана Шаллера "на мороз", теперь его функции выполняет AI.

Отличные новости. Рад за ИИ и за будущее.

> При этом AI рассматривается как инструмент, помогающий в разработке, но не снимающий ответственности за добавляемый код и требующий проверки и контроля качества.

Как ты будешь проводить контроль качества, если всё пишется за тебя?
А если всё пишется без тебя - это значит, что у тебя нет опыта и говорить про твою экспертизу нельзя. Вот это грядущее.

Как ведь хорошо же!

Подскажите, а около пяти часов для портирования это разве мало? Всю жизнь пользовался компьютером как домохозяйка, не раз хотел изучать базовое программирование, но нет, не выходит. Тупо интересно, сколько времени занимало бы подобное без ИИ?

Какие же дедушки там сидят, что только сейчас поняли мощь ИИ?

А что, приложение на GTK v(любой) --> Qt v(нужной) было бы неплохо.

Тоже пользую.
Мне нравится.
Вбил wayland_wl_registry_bind в поле и нате описание, пример.

Иногда угадывает, что я хотел include и показывает include-путь. Аще!