Разработчики дистрибутива openSUSE представили проект zssh, в котором предпринята попытка реализации протокола SSH на языке Zig. Реализация включает код для разбора протокола и работы со связанными с SSH примитивами, такими как ключи, сертификаты и механизм обмена сообщениями с ssh-agent. Реализации алгоритмов шифрования заимствованы из существующих библиотек. Код проекта распространяется под лицензией GPLv3...Подробнее: https://www.opennet.dev/opennews/art.shtml?num=64272
нам действительно нужно что-то лучшее чем OpenSSH?
Ээээ... Да? В текущем, как и в любом другом проекте с подобной длины историей - слишком много legacy и функциональных возможностей, входящих за пределы первоначального назначения наросло.
с sudo на doas перешли уже?
Шило на мыло.
> с sudo на doas перешли уже?На sudo-rs жи ). И да, аж вот целая ubuntu ).
А doas чот подозрительные васяны делали, ну их )
На run0.
видишь ли SSH2 описывается спецификациями RFC4251–4254, т.е. ты не можешь убрать "функциональных возможностей", если они они есть в стандарте, т.е. zssh будет повторять все те же функции, иначе это уже не SSHчто касается кода, все сильно зависит от того как он изначально написан, вот ты зумерок, смог бы провести презентацию, в которой бы описал бы проблемы "legacy" в оригинальном коде? я допустим не стал бы на себя брать такую работу и ответственность
и одно известно точно, что чем больше времени потрачено на проект, чем больше его популярность и проверка сообществом, тем больше вероятность того, что его код был вычитан и выверен не единожды, т.е. чем больше ты работаешь над своим кодом, чем чаще ты возвращаешься к нему со свежим взглядом, тем больше ты его улучшаешь, и OpenSSH прошел проверку временем
а SUSE тем временем придумала Agama, когда в попытках преодолеть ограничения действующего инсталлера, она убила хорошо работающее решение, не дала ничерта взамен, модель данных для автоматизации примерно таже, но теперь у нас JSON вместо XML, а так все то же самое.. это отдельная тема, не будем в подробности лезть, но для примера сойдет
так откуда у тебя уверенность, что zssh не будет очередной сомнительной идеей?
> видишь ли SSH2 описывается спецификациями RFC4251–4254, т.е. ты не можешь убрать
> "функциональных возможностей", если они они есть в стандарте, т.е. zssh будет
> повторять все те же функции, иначе это уже не SSHНу вот какими RFC описываются SFTP и SCP?
А собственная реализация сертификатов от SSH из драфта вышла? А вот тебе её прям зачем-то _НАДО_ реализовывать?
А вот поддержка socks-прокси в SSH спецификациях есть? А VPN? Ну, тот который с -w?> что касается кода, все сильно зависит от того как он изначально написан,
> вот ты зумерок, смог бы провести презентацию, в которой бы описал
> бы проблемы "legacy" в оригинальном коде? я допустим не стал бы
> на себя брать такую работу и ответственностьНу посмотри на поддерживаемые ОС и архитектуры - и выкинь все по-с-дохшее, предполагаю что не ошибешься.
> и одно известно точно, что чем больше времени потрачено на проект, чем
> больше его популярность и проверка сообществом, тем больше вероятность того, что
> его код был вычитан и выверен не единожды, т.е. чем больше
> ты работаешь над своим кодом, чем чаще ты возвращаешься к нему
> со свежим взглядом, тем больше ты его улучшаешь, и OpenSSH прошел
> проверку временемТут не поспоришь. Но что выгодней - длительный срок жизни с "чисткой" ошибок или существенно более современная кодовая база меньшего размера - вопрос дискуссионный.
> а SUSE тем временем придумала Agama, когда в попытках преодолеть ограничения действующего
> инсталлера, она убила хорошо работающее решение, не дала ничерта взамен, модель
> данных для автоматизации примерно таже, но теперь у нас JSON вместо
> XML, а так все то же самое.. это отдельная тема, не
> будем в подробности лезть, но для примера сойдетНу да - обёртка над ruby'шным yast тут конечно очень актуальный пример...
> так откуда у тебя уверенность, что zssh не будет очередной сомнительной идеей?
> Ну вот какими RFC описываются SFTP и SCP?Расширения для SSH2 вполне вписываются в стандарт. А само оно вот описывается здесь: https://datatracker.ietf.org/doc/html/draft-ietf-secsh-filex...
> А собственная реализация сертификатов от SSH из драфта вышла? А вот тебе её прям зачем-то _НАДО_ реализовывать?
https://www.ietf.org/ietf-ftp/internet-drafts/draft-miller-s...
Wi-Fi6 Wi-Fi7 был тоже в драфте, а клепались устройства и чипы. И мне SSH без расширений как чемодан без ручки.
> Ну посмотри на поддерживаемые ОС и архитектуры - и выкинь все по-с-дохшее, предполагаю что не ошибешься.
Так в том то и дело, что одни предположения, т.е. если я поднимаю вопросы, то ты безапеляционно сыпешь утверждениями - чувствуешь разницу?
Давай покажи мне "поддерживаемые ОС и архитектуры": https://github.com/openssh/openssh-portable
> Ну да - обёртка над ruby'шным yast тут конечно очень актуальный пример...
Идеальный пример, кодовая база плохая (не в SSH, но по твоей теории и в SSH), она плохо интегрируется, они не могут вынести это в либу, все понятно, НО ЧТО ОНИ ДАЛИ ВЗАМЕН? и теперь перечитывай мой оригинальный абзац про Agama (где я пишу что они убили то что хорошо работало для конечного использования, а не про то как оно написано). Так вот где гарантия что zssh будет решением, а не такой же поделкой? Ну сломают они все, и их сервер не будет совместим практически ни с одним клиентом (к примеру, я не утверждаю). Вот я и спрашиваю, а зачем? Если это будет в лучших традициях SUSE, когда мы все сломаем, а новое построим наполовину. Притом а надо ли "чинить", в случае с YaST хотя бы понятно, чем они руководствовались.
И если меня спросить а во что я верю больше, в эволюцию проверенного решения или в новое решение с сомнительным менеджементом, ну ответ очевиден.
>> Ну вот какими RFC описываются SFTP и SCP?
> Расширения для SSH2 вполне вписываются в стандарт. А само оно вот описывается
> здесь: https://datatracker.ietf.org/doc/html/draft-ietf-secsh-filex...Ну, т.е. есть протухший в 2007 году _draft_, ага.
>> А собственная реализация сертификатов от SSH из драфта вышла? А вот тебе её прям зачем-то _НАДО_ реализовывать?
> https://www.ietf.org/ietf-ftp/internet-drafts/draft-miller-s...Еще один _draft_, но посвежее. Самое в этом забавное, что _принятый_ RFC 6187 openssh та-дааам! Не реализует. У них свой NIH лисапет. Но СТАНДАРТ - СТАНДАРТ ЭТО ВАЖНО, ага
Вопрос "а нафига это поддерживать (всем остальным)" - без ответа.
> Wi-Fi6 Wi-Fi7 был тоже в драфте, а клепались устройства и чипы. И
> мне SSH без расширений как чемодан без ручки.Ну так у тебя ж openssh никто и не отбирает, нет? У меня вот - нет.
>> Ну посмотри на поддерживаемые ОС и архитектуры - и выкинь все по-с-дохшее, предполагаю что не ошибешься.
> Так в том то и дело, что одни предположения, т.е. если я
> поднимаю вопросы, то ты безапеляционно сыпешь утверждениями - чувствуешь разницу?
> Давай покажи мне "поддерживаемые ОС и архитектуры": https://github.com/openssh/openssh-portablehttps://github.com/openssh/openssh-portable/blob/master/READ...
Э? Это вот если по коду не ходить. Если ходить да еще не только в portable - то не удивлюсь, если по углам еще куски ssh1 остались. Опять же, autoconf в 2025 году выглядит "свежо и загранично"...>[оверквотинг удален]
> то как оно написано). Так вот где гарантия что zssh будет
> решением, а не такой же поделкой? Ну сломают они все, и
> их сервер не будет совместим практически ни с одним клиентом (к
> примеру, я не утверждаю). Вот я и спрашиваю, а зачем? Если
> это будет в лучших традициях SUSE, когда мы все сломаем, а
> новое построим наполовину. Притом а надо ли "чинить", в случае с
> YaST хотя бы понятно, чем они руководствовались.
> И если меня спросить а во что я верю больше, в эволюцию
> проверенного решения или в новое решение с сомнительным менеджементом, ну ответ
> очевиден.Но вопрос был "нужно ли нам что-то лучшее, чем openssh", а не "могут ли эти конкретные товарищи это "более луДшее" обеспечить"?
RFC 6187 - покрывает только X.509v3 Certificates for Secure Shell AuthenticationЭто всего лишь новая версия сертификатов, которая может быть не сделана еще в кодовой базе, в чем твой аргумент? Как это относится к тому что было сказано ранее?
6187 описывает то что работает с тем самым драфтом, т.е без SSH драфта, 6187 нужен ровно на 0 процентных пунктов
ты вот воду мутишь, флудишь, а к чему ты апелируешь - хз, вообще вне контекста
> Ну так у тебя ж openssh никто и не отбирает, нет? У меня вот - нет.
ну так и как это связано с контекстом? я ему посыл - что стандарты в драфте очень частое явление, и в оборудовании и в вебе и в прочих сферах, что реализации на базе этих стандартов ценны и часто становятся эталоном, а он мне про то, что у меня не забирают OpenSSH, ну спасибо, капитан
> Э? Это вот если по коду не ходить.
а ты сходи открой ssh.c и поищи где именно такая совместимость убивает качество внутри ssh.c?
> Но вопрос был "нужно ли нам что-то лучшее, чем openssh", а не "могут ли эти конкретные товарищи это "более луДшее" обеспечить"?
Т.е. я писал это тоже вне контекста? А не потому, что нам предлагается альтернатива, которая должна быть чем-то лучше OpenSSH? Наверное если бы статья звучала как 2.5 покемона собираются там что-то поэкспереметинровать на тему SSH используя малоприменимый язык программирования, и все это не должно иметь большой импакт на сообщество, мы всего лишь хотим:
Have a working implementation of the ssh protocol in Zig.
Be flexible, as to allow for hacking of the protocol (i.e. testing PQC algorithms).
Be agnostic of cryptography libraries (i.e. libcrypto, leancrypto).
и можно добавить
Have a fun.то наверное я бы и не стал ничего коментировать.
> RFC 6187 - покрывает только X.509v3 Certificates for Secure Shell Authentication
> Это всего лишь новая версия сертификатов, которая может быть не сделана еще
> в кодовой базе, в чем твой аргумент? Как это относится к
> тому что было сказано ранее?Оу. Ну, восстанавливаем логику дискуссии:
1. Ты пишешь, что не понятно, нужно ли нам что-то лучше, чем openssh
2. Я отвечаю, что скорее всего - "да", т.к. в текущем уж больно много всего помимо собственно SSH "наросло"
3. Ты говоришь, что "наросшее" убирать "никак ниможна" по тому, что оно - часть стандарта.
4. Я тебе тычу пальцем в вещи, которые НИКАКИМ стандартом не требуются - но реализованы, и в вещи, которые как раз таки стандартом _являются_ но вот не сделаны в пользу NIH-лисапеда.
5. Ты делаешь вид, что не понимаешь, к чему тут это. Ну привет, чо.> 6187 описывает то что работает с тем самым драфтом, т.е без SSH
> драфта, 6187 нужен ровно на 0 процентных пунктовНу вот если из zssh выкинут поддержку openssh-совместимых сертификатов и _по стандарту_ запилят поддержку x509v3 - я буду вполне доволен.
(Кстати, если "впоперёк стандарта" выкинут вот например поддержку kerberos - тоже не обижусь, хоть в общем-то и пользовался)> ты вот воду мутишь, флудишь, а к чему ты апелируешь - хз,
> вообще вне контекстаНу что, стало понятней?
>> Ну так у тебя ж openssh никто и не отбирает, нет? У меня вот - нет.
> ну так и как это связано с контекстом? я ему посыл -
> что стандарты в драфте очень частое явление, и в оборудовании и
> в вебе и в прочих сферах, что реализации на базе этих
> стандартов ценны и часто становятся эталоном, а он мне про то,
> что у меня не забирают OpenSSH, ну спасибо, капитанНе-не-не. У меня все ходы записаны! Ты говоришь, что SSH (и вся обвязка) часть СТАНДАРТА. Что очевидная вот не правда. Ты говоришь "ну пусть не стандарт - мне без этих расширений жизнь не мила!" - Я отвечаю, "пользуйся на здоровье! Никто ж не отнимает - но и реализовывать вот это всё - не обязательно от слова "совсем" - ты делаешь вид, что не понял, о чем речь.
>> Э? Это вот если по коду не ходить.
> а ты сходи открой ssh.c и поищи где именно такая совместимость убивает
> качество внутри ssh.c?Может еще код ревью забесплатно провести? И генетическую экспертизу шотландца до седьмого колена сделать?
>[оверквотинг удален]
> SSH используя малоприменимый язык программирования, и все это не должно иметь
> большой импакт на сообщество, мы всего лишь хотим:
> Have a working implementation of the ssh protocol
> in Zig.
> Be flexible, as to allow for hacking of
> the protocol (i.e. testing PQC algorithms).
> Be agnostic of cryptography libraries (i.e. libcrypto, leancrypto).
> и можно добавить
> Have a fun.
> то наверное я бы и не стал ничего коментировать.Ну вот это ДВА РАЗНЫХ ВОПРОСА. Ответ на первый - "да", на второй - "возможно, нет".
То что драфтам много лет совсем не означает, что функционал ими описываемый и в опенссаш реализованный вдруг стал лишним. Тот же scp вполне активно использую, т.к. удобен и проверен временем. Зачем городить очередное васяноподелие без поддержки поивычных фич, если оригинал с ними работает как надо, я не понимаю. Это сродни переписыванию пабочтх инструментов на другой раст... язык просто потому что кому-то делать нечего и новых идей нет.
> То что драфтам много лет совсем не означает, что функционал ими описываемый
> и в опенссаш реализованный вдруг стал лишним. Тот же scp вполне
> активно использую, т.к. удобен и проверен временем. Зачем городить очередное васяноподелие
> без поддержки поивычных фич, если оригинал с ними работает как надо,
> я не понимаю. Это сродни переписыванию пабочтх инструментов на другой раст...
> язык просто потому что кому-то делать нечего и новых идей нет.А почему бы туда вот еще... о, открывашку для бутылок не встроить? ИДЕЯ!
/Может по тому, что это - внезапно - не задача secure socket shell? Или по тому, что поверх ssh можно организовать передачу файлов хучь через cat| хучь через tar cf - |, хучь... и раздувать для этого кодовую базу абсолютно критичного с т.з. безопасности - вот абсолютно не обязательно? Да не, ерунда какая-то.../
И вот штопор еще, штопора не хватает!
Нужно. Но вот где найти это лучше?
Поддержка XDG wont-fix. Еще вопросы?
Синтаксис конечно отвратный (как и в расте), но намного более современный чем ржавчина.
Если уж и переписывать, то на нём.
>но намного более современный чем ржавчинаА что это означает? На всякий случай, вдруг вы не знает, Zig не решает проблемы при работе с памятью, а Rust - решает (кроме утечек). Это и есть, по-вашему, более современный синтаксис?
А какая связь между способом выражения кода программы и менеджементом памяти?
потому что у такого переписывания должна быть цель кроме собственно переписывания. При переписывании на Rust ты бонусом получаешь отсуствие многих типов критических уязвимостей. На Zig?
>При переписывании на Rust ты бонусом получаешьБонусом к чему?
Вот то-то же. Переписыватели на что угодно делают это ради самого переписывания, не нужно обманывать самих себя и других.
>Синтаксис конечно отвратный (как и в расте)Борцун с синтаксисом как всегда не осилил язык, и по этому его не критикует.
Как освоение языка помменяет его ужасный синтаксис?
Судя по описанию, ZIG выглядит гораздо лучше ржавчины и go хотябы тем что компиится из C, а не бустрапится. Да и название не имеет негативный смысл. В последних выпусках Lunduke доходиво объяснил, что такое Rust. Последние новости от Ubuntu только дополняют картину.
> Судя по описанию, ZIG выглядит гораздо лучше ржавчиныУгу, только по описанию.
> Lunduke доходиво объяснил, что такоеRust
Ad Free, Big Tech Free, Non-Woke, Audience Supported.
Т.е нющеброд без поддержки серьезных компаний?
Явно серьезный аргумент))
не paywall-free
>Big Tech FreeТо есть прямо говорят что на него не стоит тратить время тк для карьеры не полезно 🗿
Корпорации, все чаще использующие свербыстрый Bun, не могут с этим согласится.
https://github.com/oven-sh/bun
> Ad Free, Big Tech Free, Non-Woke, Audience Supported.
> Т.е нющеброд без поддержки серьезных компаний?Т.е. не corporate shill. По крайней мере, по заявлениям.
> Явно серьезный аргумент))
Да, это серьезный аргумент.
>Судя по описанию, ZIG выглядит гораздо лучше ржавчины и go хотябы тем что компиится из C, а не бустрапится.Слова ыксперда. А отладочные символы в нём откуда, неуж-то из сишной лапши, в которую он оттранслировался?
Зачем сравнивать языки с явно разными областями применения? Популярно говоря, Go — убийца Джавы, Rust — C++, а Zig — C. Почитайте статьи Алексея Кладова: https://matklad.github.io/2025/08/09/zigs-lovely-syntax.html
> Почитайте статьи Алексея КладоваКто это?
Известный программист, эксперт (настоящий, а не Опеннетный) по языкам Rust и Zig.
У этого ноунейма в профиле девиз: "Computers, democracy, and nervous disorder." Спасибо хоть сам признался.
> LundukeЛол
Никогда о нем не слышал. Загуглил, открыл его Youtube.* Linus torvalds and communism
* Python is DEIзакрыл таб
> ZIG ... название не имеет негативный смыслК сожалению, имеет :(
Радует, что кто-то из гигантов обратил внимание.
Я конечно предпочёл бы развитие Hare, но Zig тоже лучше, чем rust.
Хуже, на самом деле, если говорить о потенциальных ошибках при работе с памятью. А зачем он нужен (Zig), если таких гарантий не предоставляет?
Так ты тоже никаких гарантий при работе с памятью не предоставляешь
Это не ты там выше писал, что Zig хуже, потому что у него синтаксис не даёт гарантий безопасной работы с памятью?
>кто-то из гигантов обратил внимание
>гигантовLooks inside... SUSE 🤷🏻♂️
Дружно поприветствуем разработчика!
Выше комментаторы то и дело сравнивают zig и раст. Но zig вообще не далеко ушел от си. Я бы даже сказал, что это и есть си, только внешне удобство поменяли. Под капотом одно и то же. Память вручную выделять, вручную освобождать. Нет сборщика мусора. Все принципиально тоже самоеПереписанная с си на зиг программа ничего не поменяет. Ни в производительности ни в безопасности. Переписывание ради переписывания
> Переписывание ради переписыванияэто-таки как раз про раст
Сразу видно "эксперта". Rust решает проблемы при работе с памятью. Ради этого переписывать на этот ЯП имеет смысл. А Zig по сути, никаких проблем не решает. Зачем он тогда нужен?
Зиг решает проблему UB. А раст решает? Без спецификации точно решает. Нет спецификации - нет UB.
UB - не проблема
Скорее, NIH...
> Rust решает проблемы при работе с памятьюложь, дальше не читал
Гугл недавно специально для тебя отчёты опубликовал с обновлёнными пруфами
> Гугл недавно специально для тебя отчёты опубликовал с обновлёнными пруфамиГде признался, что сдался, переписывать все.
Далее придумал причину почему он не "не может", а "не хочет" переписывать то что есть.
а в сбербанке заставляют всех ставть касперского, в том числе в дочерних компанияхугадай с трёх раз, почему
Решает, но не всё, а заявляется что как будто бы все.
вот именно... всё что делает раст - стелит соломку для тех, кто городит джунгли указателей. Если замена аллокатора в дебаг сборке + доп. флаги компиляции + статический анализатор не отлавливают 99+% ошибок с памятью, то тебе никакой раст не поможет - с таким подходом к разработке тебе и останется только и делать что переписывать чужое.
Раст как раз таки поможет:)
Поможет остатся безработным, потому что вакансий считай нет.
Zig паразитирует на волне сиубийства. Он пытается убедить мимокрокодилов, что проблемы сишки, требующие создания нового языка - это проблемы поверхностные (вроде синтаксиса), а по сути в 1972 всё сделали верно. Так он уворачивается от решения сложных проблем и получает поддержку культистов, которым только дай намёки на ООП поискоренять.Итоги: в GNU C имеется более полноценная поддержка RAII, чем в Zig (см. лаконичный _cleanup_free_ в systemd вместо defer отдельной строчкой).
> это проблемы поверхностные (вроде синтаксиса)Проблемы то есть. Прочитайте https://www.adacore.com/uploads/books/pdf/Safe_And_Secure-Ru... первую главу. Но их можно решить статическим анализатором.
> Итоги: в GNU C имеется более полноценная поддержка RAIIОна делается через атрибуты, которые вешаются только на функцию. Чтобы это было похоже на defer, то нужно макросами обкладываться. Ну или нужна поддержка анонимных функций, чего нет.
> Чтобы это было похоже на defer, то нужно макросами обкладыватьсяЯ: пора пересаживаться со стула на кресло (на полноценный RAII как в C++ или Rust, без зиговского неосиляторства)
Ты: Чтобы стул стал похож на табуретку, нужно отпилить спинку или садиться боком
>> Чтобы это было похоже на defer, то нужно макросами обкладываться
> на полноценный RAII как в C++ или Rust, без зиговского неосиляторстваВ С++ есть аналог defer как раз таки для цели позвать код без создания класса под него.
> В С++ есть аналог deferЕго нет[1] и defer слабее RAII, но язык позволяет его сделать. В отличие от Zig, который так расширять язык не даст, не осилил RAII и пустил в ход классическое "свобода это рабство", то есть "копипаста лучше абстракций", то есть я хотел сказать "явное лучше неявного"[2]. Вызывайте деструкторы сами. Да, в цикле, если придётся. Да, [s]не обляпайтесь[/s] не перепутайте порядок.
[1] scope_exit и прочих ещё нет, отказались добавлять в C++23 и C++26, это в подвешенном состоянии висит - https://en.cppreference.com/w/cpp/experimental/lib_extension...
[2] Zig does not support RAII or operator overloading because both make it very difficult to tell where function calls happen just by looking at a function body. https://ziglang.org/download/0.1.1/release-notes.html
Ты за композицию или за наследование?
В C завозят defer.
> (см. лаконичный _cleanup_free_ в systemd вместо defer отдельной строчкой).Ну вот в systemd свой cleanup, в ядре линукса свой, в другом проекте еще какой-то, а в zig из коробки есть и он один и тот же в любой билиотеке. В этом плюс коробочного решения. Даже в std в с++ уже добавили, хотя решение аля defer пишется просто и на самом деле есть во многих библиотеках.
> Нет сборщика мусораА в расте есть что-ли? Только не надо про arc.
Самое смешное, что в раннем дизайне ржи GC имелся. Выкинули ради боровов.
Тут прекрасно всё. От самой идеи сделать "реализацию протокола SSH на языке Zig" за целый один хакатон, до выбора наиболее маргинального хостинга кода, где его никто никогда не найдёт.
а не маргинальный хостинг кода это какой? тот что от фирмы microsoft?
По определению, тот, которым пользуется большинство. На текущий момент это Гитхаб.
ок, лучше пользоваться немаргинальным гитхаб от фиры microsoft, потому что им пользуется большинство
Если тебе нужно привлечь бесплатных разработчиков в проект — да, таки лучше. Если нужно просто интересно провести время, можно пользоваться чем угодно.
Все правильно, подальше, подальше, чтоб не нашли.Замена openshit конечно давно нужна, но не от этих альтернативно-одаренных же ж.
посмотрел я этот zig, это какой-то новый вид извращений. не думаю, что zssh будет поддерживаться дольше, чем этим занимается автор.
Суда по новости, он не для поддержки, а для экспериментов.
> посмотрел я этот zig, это какой-то новый вид извращенийПоконкретнее, пожалуйста.
Уважаемые эксперты, объясните дилетанту, зачем переписывать вполне работающие программы на новых языках? Вон переписали в Ubuntu часть утилит на Rust и оказалось, что они не то что стали безошибочными, а банально не имеют стандартного функционала. Так в чем профит?
Данный конкретный случай - что бы не испортить экспериментами нормальную библиотеку.
У многих из переписанных на коррозийный язык под шумок сменяется лицензия на более удобную для использования крупным пизнецом.
Серьезные господа из списка Forbes и без этого найдут способ как проигнорировать законы если очень захочется (история с тренировкой нейронок на пиратском контенте тому пример), копилефт может максимум помочь держать в узде проприетарные импульсы среднего бизнеса
Серьёзные господа финансируют фрибздунов, чтобы плейстейшоны и нефтликсы работали, а не теряли гешефт при публикации исходников.
Бэкдоры, сэр. В случае с Rust существует один единственный компилятор.
... и потом вся эта многоходовочка по переписыванию кучи софта порушится если написать второй компилятор. Хороший план, надежный как швейцарские часы /s
Не напишешь новый компилятор. rustc - это и есть текущий набор стандартов, и любое изменение в корявости выходящего наружу кода моментально бегут поправлять в документации.
ИМХО:Начну издалека. В принципе, чем плоха ситуация когда нет исходников? Тем что уж слишком сложен машиный код (или ассемблер) для чтения и изменения, по крайней мере для большинства программистов. По той же причине плох намерено обуфицированый исходный код. Отсюда приходим к откровению, что код на низкоуровневом языке и имеющий анти-паттерны может в пределе мало отличаться от блоба.
Низкоуровые языки это зло с которым приходится мириться если железо недостаточно быстрое. Но вот прекрасное будущее настало, железо уже достаточно быстрое, значит можно переписать код на более высокоуровневом языке. В результате есть надежда на получение клона проекта, но с более внятным кодом, который больше людей смогут читаться и изменять
> более внятным кодом, который больше людей смогут читаться и изменятьПоэтому мы выберем язык, на котором пишут полтора человека (его определённо поймут больше людей, чем код на си).
Мне кажется, что переписать программу и сделать её более внятной/быстрой/поддерживаемой реально только если ты сам работал над тем, что сейчас переписываешь и можешь держать в голове весь функционал, который тебе предстоит сделать, чтобы заранее избежать все грабли и костыли, которые были неизбежны при первом написании. И другой язык тут не поможет. (но и не то что бы прям навредит, если ты в нём разбираешься, я думаю)
>его определённо поймут больше людей, чем код на сиДа, без тени иронии. Языки одного уровня очень похожи. Если человек изначально знает язык такого же уровня как Zig, то привыкание к новому синктатическому сахару должно произойти достаточно быстро
> ...значит можно переписать код на более высокоуровневом языке
> Языки одного уровня очень похожину ты либо крестик сними, либо штаны надень.
Zig уровнем повыше чем Си будет. Это конечно не Питон, но уже выше чем Си
>зачем переписывать вполне работающие программы на новых языках?Затем, что они не работают, очевидно же. Если для вас наличие трудноуловимых багов, а так же тонны CVE не являются аргументом, то для вас ничто не будет аргументом.
>и оказалось, что они не то что стали безошибочнымиФантазии про безошибочность - это ваши фантазии. Гарантии, предоставляемые растом давным давно известны. Если кто-то не может прочитать эти гарантии, и понять, к чему они применимы, то это только его беда. А то развелось растохетйтеров, которые сами же и не знают раста.
А почему нельзя программы обложить тестами и формальной верификацией? Религия запрещает?
Зачем идти более трудозатратным путем когда сам язык программирования может часть работы проделать за разработчиков?
Да-да, а выучить новый язык и переписать на нем программу, наплодив новых багов - это менее трудозатратный путь. Я напомню речь о переписывании, а не о новых программах.
>А почему нельзя программы обложить тестамиТесты - это доказательство наличия ошибок, а не их отсутствия.
>и формальной верификацией?И вот мы изобретаем rust или ats заново, где проверки встроены в компилятор.
>Религия запрещает?Это вы у сишников спросите. Методы верификации известны давным давно, только вот почему-то ими мало кто пользуется.
Раст и близко не является формальной верификацией, а тесты помогают отлавливать семантические ошибки которые Раст пропустит.
Да нет там профита, просто о том, что уже сделано известны плюсы и минусы, вот и переписывают по накатанному. А если начать решать задачи, которые пока не решены, то тут одних кодеров мало.
>В качестве целей проекта заявлено создание SSH-стека на языке Zig, легко расширяемого для проведения экспериментов и исследований, например, связанных с тестированием посткватновых алгоритмов шифрованияпередайте этим сказочным, что в ssh уже 100 лет в обед как есть посткванты, ничего переписывать не нужно.
Как эксперимент конечно пусть играются, но идея в корне сомнительна. В таких критичных приложениях крайне важна корректность, соответственно максимальная защита от любых ошибок(в том числе с памятью)
Не существует языка, который в полной мере закрывал бы все потребности.
Ada/SPARK?
Ага, НАЧИНАЙТЕ переписывать на хрусте!(до сих пор не пойму, почему кто-то еще не пилит на этом хороший и фкуссный грант. А то и два.)
Зачем изобретать "лучший Си", когда Си уже является лучшим? <donk/>Более безопасные языки уже существуют, а что насчёт более "точных"? Си является абстракцией PDP-11 над современными системами с многоуровневым параллелизмом (на уровне инструкций, ядер, процессоров) и многоуровневой памятью (L1i, L1d, L2, L3, L4, ОЗУ), иногда гетерогенными.
По-настоящему низкоуровневому языку не нужен сложный компилятор.
>Зачем изобретать "лучший Си", когда Си уже является лучшим?Вы имеете в виду лучшим в плане непродуманности?
>Си является абстракцией PDP-11Вот беда, PDP-11 давным давно вышли из употребления.
>и многоуровневой памятью (L1i, L1d, L2, L3, L4, ОЗУ)Ха, ха, ха. Язык с поддержкой кеша, ничуть не лучше кучи других языков. Вы юморист?
>По-настоящему низкоуровневому языку не нужен сложный компилятор.Нужен и ещё как. Нужна как минимум поддержка зависимых и афинных типов.
Пользуясь случаем, хочу задать вам, как апологету си вопрос: зачем вам нужно отсутствие гигиенических макросов, возможность выхода за границы массива, возможность потерять нулевой терминатор в строке? Для каких практических целей вам это нужно?
Я не тот аноним, но могу ответить> возможность потерять нулевой терминатор в строке?
А строки прям всегда обязаны быть NULL-терминированы? В GCC даже придумали __attribute__((nonstring)) для этого
> возможность выхода за границы массива
Возможность делать что угодно быть должна. Например, я знаю что там где заканчивается массив у меня начинается следующий и это именно то, что мне и надо. Страницы памяти могут объединяться в фолианты. Тут можно дофига примеров придумать где это не просто нужно, а только так и можно реализовать задуманное.
> отсутствие гигиенических макросов
что-то на индусском
> Возможность делать что угодно быть должна.
> Например, я знаю что там где заканчивается массив у меня начинается следующийТолько вот оптимизирующий компилятор будет рассуждать исходя из того, что ты не можешь этого знать (если стандарт не даёт гарантий в конкретном случае). Не можешь по указателю на 1 массив обратиться ко 2 массиву => записи во 2 массив не обнаружено => 2 массив остался неизменным => где-то за сотню километров компилятор радостно выкидывает куски кода, потому что доказал, что во 2 массиве одни нули или что похуже (компилятор может специально гадить, потому что стандарт не запрещает[1]).
Близкие темы:
- ядро Linux собирается с -fno-strict-aliasing
- стандартного C недостаточно для системного программирования
- pointer provenance
- type punning через union и memcpy[1] Например, только в C++26 компиляторам запретят крысить в случае чтения неинициализированных переменных. Компилятор видит это чтение? Видит. Значит, может выдать ошибку? Может. Должен? Нет. А если не ошибку, то какое ещё поведение разумно? Честно прочитать эту область памяти. А ещё разумные варианты есть? Нет. Но при чём тут разум, стандарт не запрещает рассуждать "это UB, а UB можно воспринимать как невозможное событие, а значит можно молча выкинуть вот это...", а значит так и сделаем.
https://www.reddit.com/r/cpp/comments/1ft0ar1/can_a_c26_comp.../
https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2024/p27...
>А строки прям всегда обязаны быть NULL-терминированы?Внезапно, но в си строк вообще нет, их имитируют с помощью массивов. И да, новый вариант строки должен быть безопаснее.
>Например, я знаю что там где заканчивается массив у меня начинается следующийНет, не знаете. Иначе взяли бы зависимые типы и доказали бы это.
>что-то на индусскомКак всегда, апологеты си практически ничего не знают.
В книгах тоже строк вообще нет, их имитируют с помощью массивов.
> Более безопасные языки уже существуют, а что насчёт более "точных"?Кто за это заплатит? Обмазывайтесь интринсиками, ассемблерными вставками, жалуйтесь в LLVM, чтобы они там сами как-нибудь.
Но вообще языки или их библиотеки расширяются под железо. Именованные адресные пространства для гарвардской архитектуры (avrgcc), far-указатели для 8/16-битных архитектур, iohw.h для I/O-портов у x86 (QNX), __builtin_expect, std::ckd_add, std::countr_zero, std::simd.
А что до полноценного использования этого
> с многоуровневым параллелизмом (на уровне инструкций, ядер, процессоров) и многоуровневой памятью (L1i, L1d, L2, L3, L4, ОЗУ), иногда гетерогенными.То будущее, наверное, за абстрагированием - пусть JIT решает, как делить большую вычислительную задачу, чтобы она хорошо легла на эту конкретную железку. Оптимальное выравнивание, AoS vs. SoA тоже можно абстрагировать. Язык при этом рискует выродиться в DSL на питоне... Пока что-то похожее только в машинном обучении обитает (dynamic computation graphs, cuda kernel autotune, вот это вот).
Хороший язык. Даже в Redox начали драйвера с Rust на Zig переписывать.
> Хороший язык. Даже в Redox начали драйвера с Rust на Zig переписывать.Можете ссылку дать?
pq в openssh с версии 3.5 .. когда выкидывают легаси - получается libressl. плюс boringssl, gnutls, wolf, matrix и т.п.. и вот это.. на вкус и цвет выбираем любимые cve..
Закапывайте. Zig до сих пор не имеет стабильной версии, а значит, в абсолютно любой момент может перестать компилировать уже существующие программы.
все норм - зигхайльссх еще несуществующая программа, ее не перестанет.
О, ужас!
Вот это новость для авторов zssh. Придется таки сворачивать проект.
Так и Раст не имеет, меняется с каждым микрорелизом. Закапывать так обоих сразу.
в общем инсталлятор они уже допереписали (нет) и срочно нужна новая имитация бурной деятельности, а то споснор может подумать что можно перестать им платить.
ssh over http/3 вот что нужно развивать
Мда, стандартная библиотека, экосистема, UTF-8 на уровне языка...Рождён мертвым.