Хотя официально он поддерживается только на Windows, благодаря открытой модели сообщество может портировать его на Linux. Это шаг в сторону open-source-комьюнити, с которым Microsoft активно сотрудничает через WSL, Visual Studio Code и GitHub.
Все собирается из коробки, внешних зависимостей нет.
У меня это первый редактор в линуксе, который умеет в выделение, копирование и вставку текста в tmux мышкой.
vi такого не умеет:
Вспоминается DOS Navigator (когда-то я на нём сидел) общим объемом 0,5 МБ при несравнимо большей функциональности
Да какая разница, библиотеки или бинари? GPL - это запретительная вирусная лицензия, поэтому пользоваться ей неудобно: "Вы можете смотреть на код и даже собирать его, но не более. А если посмотрите, запомните и напишете похожее, то встретимся в суде!".
В продукт GPL код затащить сильно сложнее. GPL лишь добавляет страданий и отрезает от продукта огромное сообщество разработчиков, не добавляя ничего кроме политических лозунгов.
К тому же нет никакого мирового суда и международного права. GPL нарушается даже членами Linux Foundation. Смысл?
Опенсорс давно перешел на настоящие разрешительные открытые лицензии, позволяющие переиспользовать открытый код и участвовать в разработке максимальному количеству разработчиков. А GPL на свалке истории.
Так не воруй код, и никакой боли не будет.
Это здесь не при чем. Любое адекватное руководство будет сопротивляться внедрению GPL кода в проект.
Нет смысла релизить что-то с GPL в 2025. Никто не сможет воспользоваться для работы софтом с GPL без боли. А значит патчей от работяг и адекватного сообщества можно не ждать.
Проблема С++, что он не имеет пакетного менеджера с изолированным окружением, в который вы можете добавить свой пакет и забыть о его распространении под другие платформы, где может применяться С++. Таким пакетным менеджером мог бы стать conan, но очень далек от этого.
nix как раз такой пакетный менеджер, буквально основная фича - это собирать пакеты с внешними зависимостями, в изолированном окружении.
Вы очень много страдаете со сборкой и пакетированием. Больше половины статьи об этом. Воспользуйтесь nix, он прекрасно работает как пакетный менеджер для с++ и установки системных зависимостей вроде gcc.
Там все это буквально пара строк в buildInputs и nativeBuildInputs. И rpath сам патчит. Жаль что на виндовс его нет.
Windows 95-98-Me - это недо-ОС, которое чуть что валилось в синий экран
Современные линуксы такие же: все живет в ядре, даже блютус. В итоге падение в декодере кодека блютус наушников == валится вся система. Ничего, живет как-то. Даже пользуется кто-то.
А как при этом решается вопрос с обратной совместимостью при расширении стандарта unicode, что происходит регулярно?
Подозреваю вы тут что-то путаете или не понимаете как юникод работает.
Диапазоны значений (0 to D7FF16 and E00016 to 10FFFF16) никогда не менялись и не будут меняться как раз для обратной совместимости с UTF-16
Это же получается, что используя такой трюк мы автоматически предполагаем, что обновление стандарта поломает наш код
А как скомпилированный код из стандартной библиотеки узнает об изменении стандарта юникода? Юникод - это не просто стандарт и кодировка, а еще и очень много кода, реализующего вышеперечисленное.
При чтении из UTF-8 проблемы может и нет, но ведь существует UTF-32, которым тип Char и представлен.
Откат изменений? (или хоть какой-то аналог Windows System Restore)
Неужели переход на «std::string» вместо «const char *» достоин увеличения мажорной версии пакета? Вообще в целом непонятно почему это написано в чейджлоге для пользователей. Какое мне дело какие там типы под капотом?
Увы, драйверная модель от этого никак не защищает: в случае возникновения ошибки в драйвере, в пространстве ядра, нет никакой гарантии, что не затронуты критические структуры ядра (например, связанные с файловой системой), а потому единственно надежный выход в такой ситуции - прекратить выполнение ОС. Ну, а уж как это оформить - как сообщение kernel panic на консоль или как известный многим синий экран (BSOD) - это вопрос эстетический.
Почему вы умалчиваете что операционных системах 21 века есть поддержка драйверов в userspace? Еще во времена win 9x стало понятно что падать всей системой из-за сегфолта в минорной подсистеме - плохо.
Защитить от сбоев в подсистемах ОС может только модель микроядра с выносом этих подсистем в пространство пользовательского режима. Но это оказалось слишком медленным, а потому индустрия по этому пути не пошла (хотя и пробовала).
Ложь. Драйвера в юзерспейсе как раз работают быстрее из-за того что в них нет ненужного копирования памяти userspace <-> ядро. И не надо виртуальную машину с интерпретатором байткода в ядро засовывать.
А если серьезно, то в Linux, в отличие от NT (и современной Windows, как ее потомка), тогда не было (и, кажется, до сих пор нет) стандартного бинарного интерфейса, позволявшего использовать заранее скомпилированные модули с любым ядром.
Посмеялся в голос сейчас. В линуксе нет возможности вчера работающий модуль взять и скомпилировать для нового, потому что ядро линукс нестабильно. API меняются каждый релиз. Бинарная совместимость между ядрами - это межгалактические технологии для этого ядра из прошлого века.
И, таки да, разработчики Linux были не первыми: в браузеры интерпретаторы кода пытались затащить, причем - не однажды (правда, там оно как-то плохо прижилось).
Что? В браузерах давно есть JavaScript. И WebAssembly если нужен перф.
eBPF - это костыль из-за того что в линуксе нет драйверной модели. А отсутствие драйверной модели - следствие того, что линукс - это монолитное ядро из 90х, на техническом уровне windows 3.х
Нужно давно было уходить от модели монолитного ядра как это сделали в Apple и Microsoft.
Почему eBPF — это революция
Затащить в ядро интерпретатор байткода, то есть по сути переизобрести джава апплеты для браузера (только запускать их с правами ядра) - это ну никак не может называться революцией.
Революцией было бы уже наконец изобрести драйверную модель и перестать падать в kernel panic из-за сегфолта в коде мигания светодиодом, как это было во времена win98
Я просто не понимаю как во всем этом костыле на костылях, подпертых костылями может получиться что-то безопасное. Наверное, никак.
Важно понимать кому и какой вопрос вы задаете. С позиции embedder'a это ЕДИНСТВЕННЫЙ правильный ответ.
С точки зрения стандарта Си и реализации его компиляторов у указателя совсем другое определение. А что там считают эмбеддеры, Си, его стандарт и разработчиков компиляторов совершенно не колышит.
10+ лет опыта программирования микроконтроллеров на российском рынке - это скорее минус, чем плюс. Встречал мало подобных личностей, которые вообще бы умели программировать. Кодировать - да. Особенно учитывая специфику HW разработки и её относительную простоту.
Даже на, казалось бы, простой вопрос - что такое указатель никто ответить не может. Все повторяют глупость про адрес в памяти.
В оправдание Линуса можно сказать, что вопрос российской агрессии в Финляндии стоит очень остро, его изучают начиная со школы, а сам он служил в армии и хорошо знаком с историей российско-финских войн, так что у него наверняка есть небольшое субъективное предубеждение против РФ.
Все собирается из коробки, внешних зависимостей нет.
У меня это первый редактор в линуксе, который умеет в выделение, копирование и вставку текста в tmux мышкой.
vi такого не умеет:
Как там с поддержкой UTF8?
Да какая разница, библиотеки или бинари? GPL - это запретительная вирусная лицензия, поэтому пользоваться ей неудобно: "Вы можете смотреть на код и даже собирать его, но не более. А если посмотрите, запомните и напишете похожее, то встретимся в суде!".
В продукт GPL код затащить сильно сложнее. GPL лишь добавляет страданий и отрезает от продукта огромное сообщество разработчиков, не добавляя ничего кроме политических лозунгов.
К тому же нет никакого мирового суда и международного права. GPL нарушается даже членами Linux Foundation. Смысл?
Опенсорс давно перешел на настоящие разрешительные открытые лицензии, позволяющие переиспользовать открытый код и участвовать в разработке максимальному количеству разработчиков. А GPL на свалке истории.
Это здесь не при чем. Любое адекватное руководство будет сопротивляться внедрению GPL кода в проект.
Нет смысла релизить что-то с GPL в 2025.
Никто не сможет воспользоваться для работы софтом с GPL без боли. А значит патчей от работяг и адекватного сообщества можно не ждать.
nix как раз такой пакетный менеджер, буквально основная фича - это собирать пакеты с внешними зависимостями, в изолированном окружении.
Вы очень много страдаете со сборкой и пакетированием. Больше половины статьи об этом. Воспользуйтесь nix, он прекрасно работает как пакетный менеджер для с++ и установки системных зависимостей вроде gcc.
Там все это буквально пара строк в buildInputs и nativeBuildInputs. И rpath сам патчит. Жаль что на виндовс его нет.
Это высказывание было актуально лет 5 назад.
Подскажите аналоги библиотек работы с аргументами командной строки или терминалом для Си и С++ уровня:
https://docs.rs/clap/latest/clap/
https://crates.io/crates/ratatui/
Что использовать вместо ratatui на Си? nurses?
А чтобы ещё под windows работало?
ChatGPT выдаёт то же самое решение с первого промпта, только без ошибок и с более элегантным и надежным кодом. https://chatgpt.com/share/681d1ad9-ba0c-8000-bf4e-0a180a3047e2
Кого вообще волнует мнение этих маргиналов?
Сколько у них пользователей? 10к найдется?
Современные линуксы такие же: все живет в ядре, даже блютус. В итоге падение в декодере кодека блютус наушников == валится вся система. Ничего, живет как-то. Даже пользуется кто-то.
В линуксе перестал отваливаться звук после перезагрузки?
А можно кратко что там? Вольный пересказ целей проекта Rust, как недавно Страуструп выступил? https://cacm.acm.org/blogcacm/21st-century-c/
Строки в Rust всегда корректные UTF8 последовательности в байтовом представлении именно потому что даныые пролностью проверяются https://github.com/rust-lang/rust/blob/master/library/core/src/str/validations.rs#L126
Покажите proof of concept
Подозреваю вы тут что-то путаете или не понимаете как юникод работает.
Диапазоны значений (0 to D7FF16 and E00016 to 10FFFF16) никогда не менялись и не будут меняться как раз для обратной совместимости с UTF-16
А как скомпилированный код из стандартной библиотеки узнает об изменении стандарта юникода? Юникод - это не просто стандарт и кодировка, а еще и очень много кода, реализующего вышеперечисленное.
Зачем вы галлюцинируете вместо того, чтобы просто открыть доки: https://doc.rust-lang.org/std/primitive.char.html
Есть современная nixOS, где стабильный формат конфигурации, нет dependency hell и пакетов в несколько раз больше, чем в репозиториях убунты.
А убунта - это легаси дистрибутив
А где установка без root прав?
Возможность установить разные версии библиотек?
Откат изменений? (или хоть какой-то аналог Windows System Restore)
Неужели переход на «std::string» вместо «const char *» достоин увеличения мажорной версии пакета? Вообще в целом непонятно почему это написано в чейджлоге для пользователей. Какое мне дело какие там типы под капотом?
Почему вы умалчиваете что операционных системах 21 века есть поддержка драйверов в userspace? Еще во времена win 9x стало понятно что падать всей системой из-за сегфолта в минорной подсистеме - плохо.
Ложь. Драйвера в юзерспейсе как раз работают быстрее из-за того что в них нет ненужного копирования памяти userspace <-> ядро. И не надо виртуальную машину с интерпретатором байткода в ядро засовывать.
Посмеялся в голос сейчас. В линуксе нет возможности вчера работающий модуль взять и скомпилировать для нового, потому что ядро линукс нестабильно. API меняются каждый релиз. Бинарная совместимость между ядрами - это межгалактические технологии для этого ядра из прошлого века.
Что? В браузерах давно есть JavaScript. И WebAssembly если нужен перф.
eBPF - это костыль из-за того что в линуксе нет драйверной модели. А отсутствие драйверной модели - следствие того, что линукс - это монолитное ядро из 90х, на техническом уровне windows 3.х
Нужно давно было уходить от модели монолитного ядра как это сделали в Apple и Microsoft.
Затащить в ядро интерпретатор байткода, то есть по сути переизобрести джава апплеты для браузера (только запускать их с правами ядра) - это ну никак не может называться революцией.
Революцией было бы уже наконец изобрести драйверную модель и перестать падать в kernel panic из-за сегфолта в коде мигания светодиодом, как это было во времена win98
Я просто не понимаю как во всем этом костыле на костылях, подпертых костылями может получиться что-то безопасное. Наверное, никак.
Никак, сон в линуксе не работает, кроме образцово-показательных платформ.
С точки зрения стандарта Си и реализации его компиляторов у указателя совсем другое определение. А что там считают эмбеддеры, Си, его стандарт и разработчиков компиляторов совершенно не колышит.
10+ лет опыта программирования микроконтроллеров на российском рынке - это скорее минус, чем плюс. Встречал мало подобных личностей, которые вообще бы умели программировать. Кодировать - да. Особенно учитывая специфику HW разработки и её относительную простоту.
Даже на, казалось бы, простой вопрос - что такое указатель никто ответить не может. Все повторяют глупость про адрес в памяти.
??? какое оправдание может быть национализму?