Джош Триплет (Josh Triplett), работающий в компании Intel и входящий в комитет, курирующий развитие Crates.io, в своём выступлении на конференции Open Source Technology Summit представил (https://hub.packtpub.com/rust-is-the-future-of-systems-progr.../) рабочую группу, нацеленную на доведение языка Rust до паритета с языком Си в области системного программирования.В рабочей группе, которая находится в процессе создания, разработчики Rust совместно с инженерами из компании Intel подготовят спецификации с определением функциональности, которую необходимо реализовать в Rust для системного программирования. Системное программирование часто требует низкоуровневых манипуляций, таких как выполнение привилегированных процессорных инструкций и получение детальных сведений о состоянии процессора. Из уже развиваемых для Rust подобных возможностей отмечается поддержка неименованных структур, объединений (union), ассемблерных вставок (макрос "asm!") и формата чисел с плавающей запятой BFLOAT16.
Джош считает, что будущее системного программирования за Rust, а язык Си в современных реалиях претендует на место, которое в прошлые годы занимал Ассемблер. Rust
не только избавляет разработчиков от свойственных языку Си проблем, возникающих из-за низкоуровневой работы с памятью, но и предоставляет возможность применения при разработке современных парадигм программирования.В ходе обсуждения (https://lwn.net/Articles/797714/) выступления
Джоша была высказана идея добавления в ядро Linux возможности разработки драйверов на языке Rust, что позволит с минимальными усилиями создавать безопасные и более качественные драйверы, избавленные от таких проблем, как обращение к области памяти после её освобождения, разыменование нулевых указателей и выход за границы буфера.
Грег Кроа-Хартман (Greg Kroah-Hartman), отвечающий за поддержку стабильной ветки ядра Linux, выразил готовность добавить в ядро фреймворк для разработки драйверов на языке Rust, если он будет обладать реальными преимуществами по сравнению с Си, например, будет предоставлять безопасные обвязки над API ядра. Кроме того, Грег рассматривает данный фреймворк только как опцию, не активную по умолчанию, чтобы не включать Rust в число сборочных зависимостей к ядру.
Оказалось, что несколько команд уже работают в данном направлении. Например, разработчики из компании "Fish in a Barrel" подготовили (https://github.com/fishinabarrel/linux-kernel-module-rust) инструментарий для написания загружаемых модулей для ядра Linux на языке Rust, используя для повышения защиты набор абстрактных прослоек над интерфейсами и структурами ядра. Прослойки автоматически генерируются на базе имеющихся заголовочных файлов ядра при помощи утилиты bindgen (https://github.com/rust-lang/rust-bindgen). Для сборки прослоек используется Clang. Собираемые модули помимо прослоек используют пакет staticlib.
Параллельно развивается (https://github.com/lizhuohua/linux-kernel-module-rust) ещё один проект, сосредоточенный на разработке драйверов для встраиваемых систем и устройств интернета вещей, который также использует bindgen для генерации прослоек на основе заголовочных файлов ядра. Фреймворк позволяет добиться повышения безопасности драйверов без внесения изменений в ядро - вместо создания в ядре дополнительных уровней изоляции для драйверов, предлагается блокировать проблемы на этапе компиляции, применяя более безопасный язык Rust. Предполагается, что подобный подход может оказаться воспребован производителями оборудования, разрабатывающими проприетарные драйверы на скорую руку без проведения должного аудита.Не вся задуманная функциональность пока реализована, но фреймворк уже вполне пригоден для работы и использован для написания рабочего драйвера для Ethernet-контроллера LAN9512 USB, поставляемого в плате Raspberry Pi 3. В качестве эталонной реализации при написании Rust-драйвера был использован существующий драйвер smsc95xx, написанный на языке Си. Отмечается, что размер модуля и накладные расходы от runtime-компонентов при разработке драйвера на Rust незначительные, что позволяет применять фреймворк для устройств с ограниченными ресурсами.
URL: https://linux.slashdot.org/story/19/08/31/2138249/should-the...
Новость: https://www.opennet.ru/opennews/art.shtml?num=51401
>BFLOAT16И где в системном программировании растоманы видели 16-тиразрядные числа с плавающей точкой? А также где он видели соответствующе аппаратные ускорители?
>> BFLOAT16
> И где в системном программировании растоманы видели 16-тиразрядные числа с плавающей точкой?
> А также где он видели соответствующе аппаратные ускорители?Наверное, вне криокамеры?
> The bfloat16 format is utilized in upcoming Intel AI processors, such as Nervana NNP-L1000, Xeon processors, and Intel FPGAs,[2][3][4] Google Cloud TPUs,[5][6][7] and TensorFlow.[7][8] Arm Neon and SVE also supports bfloat16 format.[9] (c) wikipediaМожно ведь догадаться из контекста ("работающий в компании Intel") или хотя бы пробежать глазами оригинал:
> BFLOAT16 support into Rust
> Many Intel processors including Xeon Scalable ‘Cooper Lake-SP’ now support BFLOAT16, a new floating-point format.
> This truncated 16-bit version of the 32-bit IEEE 754 single-precision floating-point format was mainly designed for deep learning.
> This format is also used in machine learning libraries like Tensorflow that work with huge datasets.
Не смотрел, но предполагаю: обычный float с 16 десятичными знаками. А что, в системном программировании запрещено использовать вещественные числа?
Возможно, имелось в виду, что в ядре FPU и всяческие векторные инструкции не юзаются, чтоб не тратить ресурсы на сохранение контекста (за редкими исключениями вроде криптографии)
float и любые другие похожие числа не вещественные.
Математики проснулись? XD
> float и любые другие похожие числа не вещественные.И не (обязательно) числа.
может тут Intel FPGAs???
Ржавчина распространяется, радует)
Rust даже с unsafe намного лучше C
судя по всему, opennet тоже на раст переписан :D
Скорей тогда уж - на ассемблере. Но, это/оптимзированность и компактность нужные вкупе для формата комментариев - главный же его плюс,
в т.ч.в ср.с ЛОР с почти нечитабельными своей несвязанностью комментариями и многостраничностью. Если бы не цензура просто противозаконного уровня, начиная с моего ника, вообще был бы идеал, а так что есть, т.б.что кому сказать нечего - того же и небанят/незачищают тут.
реплика была не на тему чёткости опенета
а на тему любви его анонов к расту
Это то - на здоровье...
Но, ведь не все. Не все.Ну и на сайте, да всё же есть она проблемка неизлечимая похоже - в головах админов
(может на Brainfuck слепивших реально сайт?)
- позорнейшая невозможность правки своих же сообщений безаакаунтно,
хотя бы пока IP не сменился или Cookies там(хоть у меня выклченны они, и IP сам меняется, падлой провайдером - чтобы деньги доп-но брать ещё и за стабильность динамического IP...),
но всё же было бы лучше чем ничего.
А то приходится и самому оставлять и другим тоже опечатки всякие. В итоге, часто перечитываешь и сам ужасаешься - я же это только что вычитавал перед отправкой! А, часто бывает особенно невыспавшись или к вечеру [пока напишешь] - уже сил нет дописывать, не то что вычитывать, тем более и клавиатура сама - то ненажмётся, то наоборот отошлёт чего не жал, не говоря про уже мимо, иногда так что весь текст теряется, так что приходится доп-но спешить оттослать. А, глянешь затем - а, там... И неисправишь уже, ну не маразм?...
>[оверквотинг удален]
> брать ещё и за стабильность динамического IP...),
> но всё же было бы лучше чем ничего.
> А то приходится и самому оставлять и другим тоже опечатки всякие. В
> итоге, часто перечитываешь и сам ужасаешься - я же это только
> что вычитавал перед отправкой! А, часто бывает особенно невыспавшись или к
> вечеру [пока напишешь] - уже сил нет дописывать, не то что
> вычитывать, тем более и клавиатура сама - то ненажмётся, то наоборот
> отошлёт чего не жал, не говоря про уже мимо, иногда так
> что весь текст теряется, так что приходится доп-но спешить оттослать. А,
> глянешь затем - а, там... И неисправишь уже, ну не маразм?...всё верно, что написано пером (или напечатно на форуме), то не вырубишь топором
а первая опечЯтка дороже второй
чем?если писать что-то для ядра, то ты почти всегда пишешь unsafe
Есть такая штука - переиспользование кода. С unsafe ты пишешь что-то базовое, хорошо тестируешь, а потом делаешь надстройки поверх, без unsafe. Так весь растовый stdlib построен.Есть например проект, где на расте пилят операционку с нуля в формате блога - https://os.phil-opp.com/ , и там далеко не всё unsafe.
Также есть куча библиотек-драйверов для embedded устройств, построенных поверх unsafe-кода и в них unsafe практически нет, например https://github.com/japaric/l3gd20/blob/master/src/lib.rs.
Rust это ниасилятором Си, включая его грабли как dumbtest,
(да и в Rust есть полезное, но их 1 может 2 и то недоработанные так - что нафиг!
за то вредных фич - куча...
А, синтаксис - хуже BASIC'a из самых первых версий в ч.н. с префиксами,
номеров строк только не хватает дл полноты :]
ну так и в BASIC давно их их,
а тот намного приятней... и для новичков - несравнимо проще.
- тогда смысл делать УберBASIC-2 под С++, но с извратским синтаксисом, ещё и теряющим совместимость с BASIC)
и такое ощущение что он и направлен именно на BASICовцнев[на микроконтроллерах прежде всего] и может C#ников (но и тут без вариантов по кр.мере массово), и т.б.реальным системным программистам т.е.Сяшникам т.е.даже не С++сникам(в смысле - с гуаноклассами алгоритмов, чужих+вечно баговых и лаговых)
- на нём делать просто нечего. И дело тут вовсе не только в синтаксисе, а в рациональности.А, так - и на C# уже писались ОС, где они все теперь... Так и тут будет.
> чем?borrow checker, move semantics, ADT (Enum), pattern matching, generics
Да хотя бы этим. Пожалуй, если начну перечислять каждое преимущество Rust над C, случайно напишу ещё одну Rust Book, только хуже.
Пока что ты написал типовой список баззвордов.
> ADT
> pattern matching
> типовой список баззвордовВы всё ещё собираете-разбираете tagged union руками, с ручной копипастой, например,
else if (s.type = JSON_ARRAY)илиelse if (s instanceof JSONArray)?Хотя о чём это я, на опеннете ведь кроме суровых энтерпрайзников и программистов GNOME никого нет…
> Пока что ты написал типовой список баззвордов.Аргумент, достойный высоко просвещённого мыслителя. Ну да, сложно спорить, когда не понимаешь смысл "баззвордов". С такими аргументами, как у вас, я бы вам посоветовал разыменовать указатель на всем известное направление (гугл).
Энтропия, приятель. В запущенных случаях, без должного ТО все гниет и ржавеет..
без должного и штрафующего стороннего ТО
>Ржавчина распространяетсяНужно антикоррозийное средство.
Палец линуса.
> В качестве эталонной реализации при написании Rust-драйвера был использован существующий драйвер smsc95xx, написанный на языке Си.Даже здесь не смогли написать сами, а как всегда - "переписали". Интересно, это свойство языка или свойство программистов на этом языке?
А что такого?
Более чем нормально переписать с языка, где половина разработки - борьба с самим языком, его дырами, утечками, ub и т.д.
>Более чем нормально переписать с языка, где половина разработки - борьба разработчика с самим собой, его дырами, криворукостью, ub и т.д.
А вот и внимательные гении без единого double free в огромном хелоу-ворлде подошли.
они все думают что их инструмент единственно верный. и не понеимают того , что ключь на 10 не нужно сравнивать с разводным)))
Для неосиляторов и макак давно придуманы удобные библиотеки. Например, https://github.com/Snaipe/libcsptr
> smart struct log_file *log = unique_ptr(struct log_file, { .fd = … }, cleanup_log_file);
> void cleanup_log_file(void *ptr, void *meta) { close(((struct log_file *) ptr)->fd); }Ну ооооочень удобные библиотеки. Кому там ржавые закорючки не нравились?
И, к слову, ни одного примера с передачей владения в вызываемую функцию.
>> smart struct log_file *log = unique_ptr(struct log_file, { .fd = … }, cleanup_log_file);
>> void cleanup_log_file(void *ptr, void *meta) { close(((struct log_file *) ptr)->fd); }
> Ну ооооочень удобные библиотеки. Кому там ржавые закорючки не нравились?Посмотрите APR, это которая Apache Portable Runtime, ну это если мы про C.
Печально, что жалкие людишки не подходят для написания кода на этом великолепном ЯП.
Жалкие людишки, в базовой комплектации, вообще мало для чего подходят. Но обучение и практика, и, как следствие, знания и опыт (в это сложно, наверное, будет поверить) творят прям чудеса (включая rocket science, не говоря уж про какие бы то ни было ЯП).
так здесь наоборот, позволит сравнить пригодность языка для подобных задач
эсть наглядный и рабочий "эталон", а не конь в вакууме
Это демонстрация того, что оно работает. Что бы показать, что что-то работает правильно, надо иметь эталон для сравнения. И вот непонимание таких очевидных вещей - это свойство не языка, а комментаторов не имеющих отношения не то, что к разработке, а даже к здравому смыслу.
> Джош считает, что будущее системного программирования за Rust
> а язык Си в современных реалиях претендует на место, которое в
> прошлые годы занимал Ассемблер.Скорее всего соглашусь, но, опять же, это дело достаточно отдалённого будущего. Через 8-9 лет, это в лучшем случаем. В худшем случае (если индустрия и энтерпрайз будут со скрипом переходить на новый язык) раст может никогда и не заменить чистый си - у этих двух языков может быть своего рода паритет. Ассемблер, да, очень специальный язык. Он всегда будет, но будет лишь в необходимой минимальной мере.
И вообще мы слишком завязаны на корпорациях. Если _тебе_, программист, нравится тот или иной язык, тебе должно быть фиолетово на какие-то там тенденции - ты просто пишешь на том языке, который любишь.
> тебе должно быть фиолетово на какие-то там тенденции - ты просто пишешь на том языке, который любишьО, уже безусловный базовый доход ввели, а я и пропустил.
Анон, не все готовы продать душу за лишний динар, как ты. Кое-кто может что-то делать и для души, как говорится, ради удовольствия.
а детей твоих кормить кто будет - штандартенфюрер?!"для души" хорошо работать, пока ты не закончил универ по курсу гендерных штудий (если злой препод нагружает заданиями - надо пожаловаться на харасмент и анэквалити)
Аргумент так себе.
Потому что нет такого преступления, которое человек не попытался бы оправдать необходимостью кормить своих детей. Это никогда им не помогает, но они пытаются снова и снова.
да неважно, детей или себя самого - важно что жрать все хотят. И никакого способа кроме ежедневного офисного рабства в общем-то для получения этого жрат не придумано. "и хрен вы меня найдете" удается на самом деле единицам, да и те часто через пару лет возвращаются изрядно пощипанными и поджав огрызок откусанного хвоста
не понимаю что мешает на работе на одном языке для себя на другом если желание есть и хобби такое.
то что когда начинается работа за жрат - никакого "для себя" уже, к сожалению, не остается. По краней мере, последние десять лет.Ну то есть хеловорд ты еще в режиме хобби осилишь, а драйвер необычной железки - вряд ли. Что, собственно, все происходящее в мире открытого софта и показывает. Нет больше ни разработчиков не на подсосе у корпораций, ни независимых проектов-хобби уровня хотя бы того же sqlite. Одни школьные поделки (и то стараются в "summer of code" проскочить, чтоб гугль кормил)
> то что когда начинается работа за жрат - никакого "для себя" уже,
> к сожалению, не остается. По краней мере, последние десять лет.
> Ну то есть хеловорд ты еще в режиме хобби осилишь, а драйвер
> необычной железки - вряд ли. Что, собственно, все происходящее в мире
> открытого софта и показывает. Нет больше ни разработчиков не на подсосе
> у корпораций, ни независимых проектов-хобби уровня хотя бы того же sqlite.
> Одни школьные поделки (и то стараются в "summer of code" проскочить,
> чтоб гугль кормил)Ты не вполне прав. Dlang — самый что ни на есть проект-хобби уровня <подставьте_ваше_любимое>. Из-за отсутствия его стандартизации и широкой поддержки со стороны бизнесов он как раз попадает в категорию независимых любительских проектов.
Не был в офисе уже 12 лет, на доход не жалуюсь, зарабатываю программированием. Что я делаю не так?
> Не был в офисе уже 12 лет, на доход не жалуюсь, зарабатываю
> программированием. Что я делаю не так?сказки рассказываешь, вот что не так.
а не жаловаться - это молодец, не жалуйся и дальше.
Ну я 5 лет там не был, но оно когда как - бывает, что зарабатываю ощутимо меньше офисосидельцев. Хотя ну и что.
> О, уже безусловный базовый доход ввели, а я и пропустил.Валидный аргумент, и в этом смысле непросто - вакансий на раст мало. Но. Я например завтра иду на собеседование на фул-тайм писать на расте. Микросервисы и embedded. И это в небольшом городе. Полагаю, в Москве или крупных европейских городах с этим ещё лучше.
Хотя про вакансии на раст есть одна оговорка. Их может быть мало, но это не значит, что на нём не пишут внутри компаний (а на нём пишут) потому, что на него переходят программисты, которые уже в штате, и нужды кого-то тащить извне особо нет. Что правильно. Если у тебя есть толковые инженеры, они на чём угодно смогут, если посчитают это разумным.
Си это удобный ассемблер.
> Си это удобный ассемблер.Си ни в каком виде не ассемблер. Небось вычитал где-то красивую метафору и понравилась? Си _был_ чем-то вроде макроассемблера для системы команд PDP, но для других архитектур он ничем принципиально не отличается от прочих языков. Яблоки в своё время вообще сделали системным языком объектный Паскаль с музыкой и танцами — и ничего.
> Си это удобный ассемблер.Знаю, как удобно написать на С команду cvttsd2si. А как написать cvtsd2si -- не знаю.
вот чем оказывается занимаются в штеуде вместо фикса уязвимостей в их процах
Ты обнаглел гой.
Чтоб барин что там исправлял.
Побежал покупать новый процессор на 3% быстрее прошлого поколения
> На 3% медленнее с новым Intel ME и свежим спектром.Fixed.
>более качественные драйверы, избавленные от таких проблем, как обращение к области памяти после её освобождения, разыменование нулевых указателей и выход за границы буферастрого говоря, в самом расте выше перечисленное достигается не с помощью какой-то особой магии, а например тупо рантайм-проверками в выражениях вроде "a[i]".
Переходить ради такого на новый язык, в котором к тому же из всех архитектур полноценная поддержка есть только у x86? Сильно сомневаюсь.
Раст пилится не как язык системного программирования, а как замена C++ в браузерах и прочем юзерспейсе. На нишу Си он претендовать не может (в обозримом будущем)
> Переходить ради такого на новый язык, в котором к тому же из всех архитектур полноценная поддержка есть только у x86?А в чём проблема с другими архитектурами? Он же на LLVM.
Впрочем, автора «инициативы» ввиду места работы другие архитектуры и не волнуют.
> строго говоря, в самом расте выше перечисленное достигается не с помощью какой-то особой магии, а например тупо рантайм-проверками в выражениях вроде "a[i]".Есть проверки в рантайме, а так же есть статический анализатор, "борроу-чекер".
Например, анализатор не даст вам разделить какую-нибудь область памяти между двумя потоками, пока вы явно не дадите слово пацана за то, что вы предусмотрели все возможные последствия.
Вы не сможете создать две мутабельные ссылки на какой-нибудь участок памяти без явного заворачивания их в какой-нибудь <Arc<Mutex<...>>>.
> Например, анализатор не даст вам разделить какую-нибудь область памяти между двумя потоками,
> пока вы явно не дадите слово пацана за то, что вы
> предусмотрели все возможные последствия.и много то слово пацана стоит? компилятор вообще не должен бы верить программисту без тридцати трёх подписей и печатей "да я понимаю что я делаю"
Ну так и есть вообще.
Если вся разница только в статическом анализаторе, то (сюрприз!) для C они тоже есть.
Сюрприз! Теорема Райса. Если язык не разработан для того, чтобы обеспечивать, скажем, отсутсвие висящих указателей, то статический анализатор сможет отловить только какие-то частные случаи, или отловить всё, но при этом выдавать и false positives.
> Сюрприз! Теорема Райса.Сюрприз! Это теорема из _теории_ алгоритмов. То есть это теория, а не истина. Слышал о теории большого взрыва? Часть физиков её принимает, часть физиков нет. Понимаешь? Каждые N столетий те или иные теории могут подвергнуться опровержению. Таким образом мы не можем в споре аппелировать к теореме Райса, как к конечной истине. Это всего лишь одна из _интерпретаций_ рельности. В рамках своей интерпретации ты прав абсолютно! В рамках теории Большого взрыва ты прав абсолютно! Но в рамках теории космологической модели эволюции крупномасштабных структур ты неправ. Так как же ты можешь быть неправ в рамках неевклидовой геометрии.
>> Сюрприз! Теорема Райса.
> Сюрприз! Это теорема из _теории_ алгоритмов. То есть это теория, а не истина.
> Слышал о теории большого взрыва?Успокойтесь, приложите лед к пострадавшей части тела, откройте словарь и посмотрите значения слов "теория" и "теорема".
> Часть физиков её принимает, часть физиков нет. Понимаешь? Каждые N столетий те или иные теории могут
> подвергнуться опровержению. Таким образом мы не можем в споре аппелировать к
> теореме Райса, как к конечной истине.Еще раз посмотрите внимательно в словарь:
https://en.wikipedia.org/wiki/Rice%27s_theorem#Proof_by...'s_recursion_theorem
https://en.wikipedia.org/wiki/Rice%27s_theorem#Proof_by...
> откройте словарь и посмотрите значения
> слов "теория" и "теорема".Это было жестоко, но красиво!
>[оверквотинг удален]
>> Сюрприз! Это теорема из _теории_ алгоритмов. То есть это теория, а не истина.
>> Слышал о теории большого взрыва?
> Успокойтесь, приложите лед к пострадавшей части тела, откройте словарь и посмотрите значения
> слов "теория" и "теорема".
>> Часть физиков её принимает, часть физиков нет. Понимаешь? Каждые N столетий те или иные теории могут
>> подвергнуться опровержению. Таким образом мы не можем в споре аппелировать к
>> теореме Райса, как к конечной истине.
> Еще раз посмотрите внимательно в словарь:
> https://en.wikipedia.org/wiki/Rice%27s_theorem#Proof_by...'s_recursion_theorem
> https://en.wikipedia.org/wiki/Rice%27s_theorem#Proof_by...чувак, ты это... если обосрaлся, то прими это как должное. хватить хeрнeй заниматься, будь мужиком.
> чувак, ты это... если обосрaлся, то прими это как должное. хватить хeрнeй
> заниматься, будь мужиком.Кто и где? Ты опять читаешь между строк и додумываешь?
ЗЫ:
чей-то ты странный какой-то. пох такой керней обычно не мается.
Кстати, вообще-то пох это пох (русскими буквами П О Х) а не N O X
и ты
https://www.opennet.ru/~nox.
совсем-совсем не палишься опять на самовосхвалении :)
Ниче, бывает.
Аноним84701, кестати, это не тебя вчера овнили в топике про i2p? если это ты, то всё понятно
> Аноним84701, кестати, это не тебя вчера овнили в топике про i2p? если это ты, то всё понятноВ смысле, "овнили" == грозились вычислить меня по айпи и прислать товарища майора, брызгали слюной и обзывались, потом тихо-мирно сдулись, но так и не привели ни одного технического аргумента и проигнорировали все технические вопросы?
Тогда да, "овнили".А ты случайно не тот самый, обделавшийся^W "заовнивший всех и вся" в том топике аноним, пишуший из под его ника?
ЗЫ:
Не зря мне формулировки показались странными. О анонимный аноним, ты совсем-совсем не палишся:
https://www.opennet.ru/~nox.
и
https://www.opennet.ru/~%D0%CF%C8.Хотя рассказывать о том, как это низко -- писать из под чужого ника, я не буду.
Судя по усердному раскидыванию минусиков и плюсиков, замены внятной аргументации своих утверждений хамством и ad hominem -- до осознания этого ты еще не дорос.
> как это низкоСогласен. Твоё поведение низкое и истеричное. Ставить себе плюсики, ставить оппоненту минусики, устраивать истерики, зачем-то давать ссылки на словарные статьи, хотя предложение очень простое было "Теорема Райса это утверждение из теории алгоритмов". Довольно простое предложение для уяснения, но наш Аноним84701 не смог выполнить процедуру чтения и восприятия. А чувачёк-то дешёвый оказался. Ещё и глупости про чужие ники. Я не могу использовать никакие ники, так как надо для это регистрироваться и иметь учётную запись. Я же просто анонимный пользователь. Обратись к модератором, может быть они тебе разъяснят что к чему.
> Ещё и глупости про чужие ники. Я не могу использовать никакие ники, так как надо для
> это регистрироваться и иметь учётную запись. Я же просто анонимный пользователь.И тут ты тоже обделался )))
> И тут ты тоже обделался )))Продолжай цирк ) У всех анонимных пользователей здесь уникальные идентификаторы. У меня 28 в этой ветке. Все сообщения под 28-м идентификатором написал лично я. Могу продолжить лекцию о том, как работает опеннет - специально для клоунов.
> Продолжай цирк ) У всех анонимных пользователей здесь уникальные идентификаторы. У меня 28 в этой ветке. Все сообщения под 28-м идентификатором написал лично я.
> Могу продолжить лекцию о том, как работает опеннет - специально для клоунов.http://wiki.opennet.ru/ForumHelp
> Иконки рядом с именем участника
> (ok) - сообщение от зарегистрированного участника;
> (?) - сообщение от не зарегистрированного участника;
> (??) - сообщение с ником зарегистрированного участника, но добавленное без авторизации
> (-) - анонимный аноним, например, использующий Tor.
> (номер) - номер первого сообщения данного анонима в обсуждении,Вот такие вот "лекции, как работает" от Знатоков и Экспертов )))
>> как это низко
> Согласен. бла-бла-бла
> зачем-то давать ссылки на словарные статьи,Вообще-то, это два доказательства теоремы, на что намекает "proof" в ссылке.
Но видимо пройти по ссылке слишком сложно, как и уточнить значение слова "теорема", лучше продолжать нелепые оправдания в комментариях?> простое было "Теорема Райса это утверждение из теории алгоритмов". Довольно простое
> предложение для уяснения, но наш Аноним84701 не смог выполнить процедуру чтенияТ.е. сказать этим ты хотел ровным счетом ничего и сравнение фиолетовой теории большого взрыва и теплой _теоремы_ Райса было болтологией? Примерно это я и подозревал.
Загугли хотя бы "проблема остановки", "машина тьюринга", "полнота по Тьюрингу" и не делай нам больше смешно.
> Успокойтесь, приложите лед к пострадавшей части тела, откройте словарь и посмотрите значения
> слов "теория" и "теорема".Да, посмотрел. Как это отменяет тот факт, что "Теорема Райса это утверждение из теории алгоритмов"?
Довольно простое предложение для уяснения, но обделался ты конечно знатно в его восприятии. Ничего, бывает.
> false positives.Не знаю как вам, а мне "ложные срабатывания" гораздо понятнее, чем "false positives."
> false positives.Справедливости ради стоит сказать, что раст тоже зачастую вполне валидный код не пропускает.
в других языках разделение памяти между потоками успешно решается указанием "это потоко(не)безопасно" в документации. Не самая большая проблема.правило двух мутабельных ссылок введено для специфических случаев вроде инвалидации итератора при vector.push_back() (которые в C++ и так прекрасно ловятся и самим компилятором, и всеми возможными санитайзерами), а в остальном это мерзкое ненужное ограничение. Недаром в расте из коробки есть костыли вроде RefCell.
> Не самая большая проблема.не соглашусь.
>замена C++ в браузерах и прочем юзерспейсеПока допилят, C++ превратится в прекрасного лебедя. Уже C++20 не за горами.
Прекрасного лебедя в органических наростах 10, 20, 40 летней давности. Напильник прилагается: c++ core guidelines.
> Переходить ради такого на новый язык, в котором к тому же из всех архитектур полноценная поддержка есть только у x86А в чём неполноценность? Код на расте под разные армы собирают и запускают и оно работает.
> Предполагается, что подобный подход может оказаться воспребован производителями оборудования, разрабатывающими проприетарные драйверы на скорую руку без проведения должного аудита.Знаете к чему это приведет? К тому, что потом часть производителей, что все же пишут нормальные драйвера с должным аудитом, под давлением эффективных менеджеров будут писать их на скорую руку.
плюсану тебе анонимный сборат
А какая разница? Всё равно не нужно
> производителями оборудования, разрабатывающими проприетарные драйверы
> проприетарные
>Предполагается, что подобный подход может оказаться воспребован производителями оборудования, разрабатывающими проприетарные драйверы на скорую руку без проведения должного аудита.ооо, это то, о чём мечтают все "эффективные менеджеры": "пишите на Расте, там само собой всё становится безопасно и можно не тестить!" >_< (слов нет)
И самое главное за памятью и указателями не следить. А если за памятью не следить, то работы меньше. А если работы меньше, то и зп ниже, а жиробасу во главе конторы прибыли больше. В этом и суть работы эффективного менеджмента.
> А если за памятью не следить, то работы меньше.А кто сказал, что в расте не нужно следить за памятью? Там только что и делаешь, что "следишь за памятью" в момент написания кода.
Там не за памятью следят, а за использованием ссылок. Где ненужно ссылки не распихивают по переменным.
надо sysvinit на rust переписать и вернуть в debian, ubuntu
Как будто сейчас в Debian нет sysvinit. Право, замучали уже это форсить.> $ dpkg -l | grep sysvinit
> ii sysvinit-core 2.96~beta-1 amd64 System-V-like init utilities
> ii sysvinit-utils 2.96~beta-1 amd64 System-V-like utilities
> $ lsb_release -a
> No LSB modules are available.
> Distributor ID: Debian
> Description: Debian GNU/Linux bullseye/sid
> Release: stable-updates
> Codename: sid(это Debian testing, если что)
Наличие единственной библиотеки systemd можно и пережить, хоть и немного не хватает порой аналога гентушных USE-флагов, тогда б можно было выпилить неиспользуемые зависимости от libatk, libavahi, libsystemd и прочего неиспользуемого на конкретной системе. Но библиотеки — чай, не сервисы, пусть уж валяются, на десктопе не стоит их выпиливание пересборки мира.
> $ dpkg -l | grep systemd
> ii libsystemd0:amd64 242-4 amd64 systemd utility library
> ii libsystemd0:i386 242-4 i386 systemd utility library
"Тревога!Тревога! Волк унес зайчат!!""Джош считает, что будущее системного программирования за Rust, а язык Си в современных реалиях претендует на место, которое в прошлые годы занимал Ассемблер".
Школьники-неосиляторы добрались до программирования ?
Вообще дико видеть такие высказывания, учитывая, что ядро Линукса написано на СИ, кстати ядра виндов и маков на чем написаны ? Или что им движет ? зачем нужно "это", если давно уже есть и активно используется СИ ? Что может "это", что НЕ может СИ ?ЗЫ: Жду агрессивных высказываний вида "ты ретроград, против технического прогресса, иди вообще откатись на самую первую версию СИ, а лучше на БИ, и не мешай прогрессу своими высказываниями ретроградными".
>Что может "это", что НЕ может СИ ?кто НЕ может на СИ может на "этом".
Вот это, кстати, вряд ли.Писать на C гораздо легче, как по мне (в C умею, а вот растопрограммы пока что даже читать практически не получается, возможно, надо начать пытаться писать и тогда дело пойдёт, но это как-то не в приоритете совсем). Другое дело, что раст упрощает нахождение (а местами и вообще избегание) некоторого класса ошибок, которые нельзя просто так взять и совсем не допускать в C (не говоря уж про обнаружение в имеющемся коде), так что не надо тут про неосиляторов. Но как по мне, конечно, лучше бы пилили статический анализатор для C, пусть даже и требующий добавления нестандартных расширений языка. Но раз уж так, пусть делают.
Ты попробуй. У меня где-то с неделю ушло на въезжание что к чему.
Конечно есть еще неясные темы, но в целом пишется и как то пока обратно на C не хочется.
> Ты попробуй. У меня где-то с неделю ушло на въезжание что к
> чему.
> Конечно есть еще неясные темы, но в целом пишется и как то
> пока обратно на C не хочется.Так вот почему тебе так припекло, что ты удалил мои комментарии. Вот так молодец!
Предвзятые «модераторы» — это то, что на следующий год лишит опеннет ещё половины донатов.
> Так вот почему тебе так припекло, что ты удалил мои комментарии. Вот так
> молодец!Да-да, а бесполезные крики про макак, рукожопость и умственную отсталость всех, кто попытался написать хоть что-то сложнее hello world и быстрее, чем за выходные, тут, конечно же, вообще ни при чём.
И эти люди ещё смеют что-то говорить про переход на личности в соседнем треде.
Атмосферу на форуме всегда создают модераторы. Это разве новость? Если бы вахтёры не стирали наши содержательные комментарии, разжирев на донатах, не было бы этих потоков яда. У приличного уважающего себя анонима нет иного выхода, кроме заниматься троллингом. В этом виноваты исключительно местные вахтёры. Я уже дал опеннету чорную метку и не рассматриваю форум как место для содержательного общения.
Провёл аудит недавно удалённых ваших сообщений, всё удалено по существу. Ваши сообщения удаляют исключительно за оскорбления собеседников, хамство и неуместный троллинг.Примеры из сообщений, удалённых за несколько последних дней:
"На сдаче едят свои ноги или Вождя?"
"Наш вождь Сатья Наделла не ест свои ноги"
"ногоеды насовали внутрь архива"
"294-й утёнок, никто не осудит"
"В первый класс я ходил с твоей мамой"
"Уж теперь-то заживём!"
"От тебя невероятно смердит убожеством даже анонимно. Эта вонь летит впереди тебя."
"Вижу, чадо, что тебе в школе на уроке информатики ещё не объяснили"Манера вашего общения сильно напоминает пользователя "КГБ СССР" (https://www.opennet.ru/soft/troll_log.html) который оскорблял всех подряд, а потом прикидывался невинно пострадавшим.
То есть когда в мой адрес пишут буквально эти же самые слова, никто не замечает? Какая поразительная избирательность.
Донатов будет всё меньше — это главное.
Я в последнее время модерирую почти только на основе жалоб через "Сообщить модератору" и уведомлений бота.
В вашем случае в логе модерирования много удалений вместе с подветкой, в которых ваше сообщение удалялось как часть подветки вместе с верхними сообщениями, т.е. первичным было удаление исходного оскорбления, а не вашей ответной реакции.
Зачем вообще заниматься безрезультатным лечением прыщей, а не самой болезни? Сделайте обязательную регистрацию — и все начнут немного думать, что пишут, исчезнет часть соблазна тупого троллинга. Уберите этот чёртов плюсомёт: он ничего не отражает, только играет на низменном у самых недоразвитых анонимов. А удалять комментарии — это вообще какое-то первобытное варварство, даже если в них оскорбления, хамство и маты. Комментарии можно просто скрывать. Кому интересно, тот себе откроет. Боты — тоже варварство. Какой смысл людям писать содержательные комментарии, если их запросто жрёт тупой скрипт? Почему капча для зарегистрированных пользователей, если комментарии со ссылками? Не первый же год всё это продолжается, неужели нельзя сделать какие-то выводы…
А такой сверхсодержательный комментарий они оставили:https://www.opennet.ru/openforum/vsluhforumID3/118332.html#104
Я считаю, что излишне что-то ещё по этому поводу пояснять. Опеннет мёртв как площадка для общения. Здесь ничего не будет, кроме яда и срачей.
> А такой сверхсодержательный комментарий они оставили:Тут, пожалуй, соглашусь
> Школьники-неосиляторы добрались до программирования ?
> Вообще дико видеть такие высказывания, учитывая, что ядро Линукса написано на СИ,
> кстати ядра виндов и маков на чем написаны ? Или что
> им движет ? зачем нужно "это", если давно уже есть и
> активно используется СИ ? Что может "это", что НЕ может СИ ?процитирую сам себя:
> да и вообще. если код на си или си++ вылизан, то такому
> по ничего не грозит.вот именно что вылизать код на расте (лично я за D) гораздо быстрее, легче, требует меньшего опыта и знаний
даж на жаве есть неочевидные и странные соглашения по работе кода, но в сях - он весь из такого
Остожонее, не переполни буфер!
> учитывая, что ядро Линукса написано на СИ, кстати ядра виндов и маков на чем написаны ?Строго говоря, не от хорошей жизни они на C написаны.
> зачем нужно "это", если давно уже есть и активно используется СИ ?
Ещё бы стандарт у C развивался /хотя бы/ со скоростью стандарта плюсов (казалось бы, куда уж медленнее, но нет). Имеющееся положение дел у C очень огорчает, но переходить на плюсы или что-то с ещё более требовательным рантаймом как-то совсем не хочется.
> Что может "это", что НЕ может СИ ?
Кое-что таки может. Говоря коротко, чем больше можно выловить проблем на этапе компиляции, тем меньше лишней преждевременной седины, сей инструмент как раз на такое вылавливание очень ориентирован. Вообще говоря, стоит читать примеры из документации на инструмент, прежде чем говорить о школьниках-неосиляторах.
> Строго говоря, не от хорошей жизни они на C написаны.Вот это новости! На чём же они должны быть написаны?
> Ещё бы стандарт у C развивался /хотя бы/ со скоростью стандарта плюсов (казалось бы, куда уж медленнее, но нет). Имеющееся положение дел у C очень огорчает, но переходить на плюсы или что-то с ещё более требовательным рантаймом как-то совсем не хочется.Назови-ка с аргументами, чего тебе не хватет в C89/90.
> Кое-что таки может. Говоря коротко, чем больше можно выловить проблем на этапе компиляции, тем меньше лишней преждевременной седины, сей инструмент как раз на такое вылавливание очень ориентирован. Вообще говоря, стоит читать примеры из документации на инструмент, прежде чем говорить о школьниках-неосиляторах.Вот и выросло поколение, не знающее историю Сишечки.
> Вот это новости! На чём же они должны быть написаны?Ха, как будто на этот вопрос есть простой ответ. У всех имеющихся инструментов есть довольно крупные недостатки. Можно перечислить свойства, которыми должен обладать язык, но ни в одном они не сочетаются. Говорю же, не от хорошей жизни был сделан выбор, когда они начинались — выбора по факту и не было, а дальше уже тянут лямку legacy. Но это не значит, что нельзя иначе.
> Назови-ка с аргументами, чего тебе не хватает в C89/90.
Судя по выбору стандартов, автор поста — явный тролль, у которого на всё готовы аргументы в духе «это не нужно / это для неосиляторов / это можно сделать портянкой макросов или сторонними библиотеками / это ошибка, которую не заметит только скорбный разумом, внимательнее нужно быть / всегда так делали и это работает» и т.д. Я в курсе стандартных контраргументов по поводу фич того же C99, только вот тема слишком субъективная и холиварная, а мне это не упёрлось.
Некоторое из того, нехватка чего недавно в очередной раз всплывала: типизированные enum (нет, -fshort-enums или #define с приведением типа на каждую константу — не решение), возможность вывести известное на этапе компиляции (но не очень известное кодеру) число в сообщении static_assert без извращений (всего-то нужно было понять, какого размера структура получилась вместо ожидаемого, обычно это делают через скрипты и autotools или через совсем уж негуманные хаки на макросах, но это реально отвратительный путь для такого простого действия), возможность объявить union из структуры (саму структуру объявлять прямо внутри union, а не отдельно) и массива байтов / uint16_t для чтения содержимого структуры (так, чтобы при этом чтобы не было нужно указывать размер этого массива, а он вычислялся исходя из размера структуры, т.е. typedef union { struct { ... }; uint8_t bytes[]; } some_type_t;, а ещё чтобы использование такого объявления не было UB, если заранее известна целевая архитектура), возможность явным образом разрешить/запретить компилятору переставлять поля конкретных типов структур (а не только вставлять выравнивания) и вообще выкидывать те, которые в конкретном варианте сборки не используются или всегда константны.
> Вот и выросло поколение, не знающее историю Сишечки.
Мал^WМолодой человек, а ты готов эту клевету подтвердить аргументами (чего именно из истории C и его предшественников я упустил и как это может помочь делу) или кроме отсылки к возрасту, как водится, аргументов нет? Конкретику, конкретику в студию.
На всякий случай, уточню: я не топлю за rust, но того уровня статического анализа, который даёт -Wall -Wextra -Werror -Wnarrowing -Wwrite-strings -Wcast-qual (и ещё немного флагов) мне мало. А более продвинутому статическому анализу некоторые вещи в стандарте C, скажем так, не помогают.
Зачем я серьёзно отвечаю троллю, косящему под олда — вопрос, конечно, интересный. "В интернете кто-то не прав.pcx", мда.
> Зачем я серьёзно отвечаю троллю, косящему под олда — вопрос, конечно, интересный.хороший серьёзный ответ прочтут и другие
>> Вот это новости! На чём же они должны быть написаны?
> Ха, как будто на этот вопрос есть простой ответ. У всех имеющихся
> инструментов есть довольно крупные недостатки. Можно перечислить свойства, которыми должен
> обладать язык, но ни в одном они не сочетаются. Говорю же,
> не от хорошей жизни был сделан выбор, когда они начинались —
> выбора по факту и не было, а дальше уже тянут лямку
> legacy. Но это не значит, что нельзя иначе.На этот вопрос есть ответ и он давно дан в написанном ПО. Выбор для написания системного ПО всегда стоял и стоит между непереносимыми ассемблерами или переносимыми языками. Си был условно низкоуровневым _переносимым_ языком. Выбор был очевиден для всех тогда и таковым остаётся доныне. Legacy тут совершенно ни при чём. Си даёт квалифицированному программисту возможности, которых не дают, например, Паскаль или Фортран при написании системного ПО. Удивительно, что приходится объяснять столь банальные и общеизвестные вещи на как бы айтишном форуме.
Так от какой такой «не от хорошей жизни»? С конкретикой, пожалуйста.
У Си, впрочем, есть очень серьёзный недостаток: Си требует развитых мозгов и поэтому совершенно не подходит обезьянам.
>> Назови-ка с аргументами, чего тебе не хватает в C89/90.
> Судя по выбору стандартов, автор поста — явный тролль, у которого на
> всё готовы аргументы в духе «это не нужно / это для
> неосиляторов / это можно сделать портянкой макросов или сторонними библиотеками /
> это ошибка, которую не заметит только скорбный разумом, внимательнее нужно быть
> / всегда так делали и это работает» и т.д. Я в
> курсе стандартных контраргументов по поводу фич того же C99, только вот
> тема слишком субъективная и холиварная, а мне это не упёрлось.Автор просто в курсе, что большинство жалобщиков не смогут объяснить даже себе различий между стандартами, ибо тех стандартов никогда не читали, но плачут о недостатке прогресса развития инноваций. Жалобщикам постоянно чего-то не хватает: то прямых рук, то мозгов, то денег. И постоянно что-то мешает: то ноги, то legacy, то «морально устаревшие» языки программирования, то другие люди.
> На всякий случай, уточню: я не топлю за rust, но того уровня
> статического анализа, который даёт -Wall -Wextra -Werror -Wnarrowing -Wwrite-strings
> -Wcast-qual (и ещё немного флагов) мне мало. А более продвинутому статическому
> анализу некоторые вещи в стандарте C, скажем так, не помогают.А мне показалось, что ты как раз чуть ли не за деньги тут рекламируешь обезьянохруст, противопоставляя его сишечке. Почему не С++, почему не Objective-C, почему не D наконец? А, анон? Чем тебе так приглянулся недоязык с уродливым дегенеративным синтаксисом, созданный в берлоге браузерных макак и продвигаемый, как ни странно, обос**вшимся по уши производителем процессоров?
> косящему под олдаВот так одной фразой и палится школота.
Фортран да, не годится.
А что мешает на паскале писать системное ПО?
Не могу вспомнить примера, когда на C будет заведомо проще и удобнее писать.
Да ничего, в принципе, не мешает, просто сейчас не модно. А Яблоки же таки писали на своём варианте.Но есть всё же обоснованные мнения против, пусть и относящиеся к старым версиям языка:
https://wiki.lazarus.freepascal.org/Why_Pascal_is_Not_My_Fav...
Да и сам Вирт для создания ПО предлагает всё-таки другие языки. Не вижу оснований сомневаться в компетентности Вирта. :)
> На этот вопрос есть ответ и он давно дан в написанном ПО.
> Выбор для написания системного ПО всегда стоял и стоит между непереносимыми
> ассемблерами или переносимыми языками. Си был условно низкоуровневым _переносимым_ языком.
> Выбор был очевиден для всех тогда и таковым остаётся доныне. Legacy
> тут совершенно ни при чём. Си даёт квалифицированному программисту возможности, которых
> не дают, например, Паскаль или Фортран при написании системного ПО. Удивительно,
> что приходится объяснять столь банальные и общеизвестные вещи на как бы айтишном форуме.А тут кто-то спорил с тем, что он даёт возможности? Я лишь говорю про возможности, которых в C очень не хватает.
> Так от какой такой «не от хорошей жизни»? С конкретикой, пожалуйста.
Сам же выше и перечислил. Асм не переносим (не говоря уж про то что код получается либо читабельным, либо оптимизированным, либо крайне тяжёлым в поддержке, если не подходить по принципу "время студентов ничего не стоит, пусть и в машкоды руками транслируют"), фортран (при всех его плюсах, одни лишь модули вместо пары из заголовочных файлов и объектников/исходников мне греют душу невыразимо, что бы там фанаты разделения объявления и реализации не говорили) не подходит, ибо лишён многих нужных фич (ну не предполагалось его использовать для этого вообще), у паскаля были хуже компиляторы и тоже фич не хватает (а Модула-2 опоздала, да и не сказать, что сильно лучше Си), остальные языки или уже отмерли (и были такие, что не жалко), или ещё не появились (в смысле наличия библиотек и хорошего оптимизирующего компилятора, а не только ранних спецификаций).
> У Си, впрочем, есть очень серьёзный недостаток: Си требует развитых мозгов и
> поэтому совершенно не подходит обезьянам.И зачем здесь эта очередная хлипкая попытка самоутверждения?
А потом он удивляется, почему его посты к срачам приводят, хотя всего-то стоит подавлять в себе эти абсолютно неинформативные вставки, не добавляющие по сути ровно ничего, кроме попыток автора возвыситься над «сирыми и убогими». Не надо возвышаться, факты надо.> Автор просто в курсе, что большинство жалобщиков не смогут объяснить даже себе
> различий между стандартами, ибо тех стандартов никогда не читали, но плачут
> о недостатке прогресса развития инноваций. Жалобщикам постоянно чего-то не хватает: то
> прямых рук, то мозгов, то денег. И постоянно что-то мешает: то
> ноги, то legacy, то «морально устаревшие» языки программирования, то другие люди.Разницу между стандартами я знаю в достаточной мере, чтобы заниматься дополнительным ручным трудом только в случае, когда это действительно необходимо (т.е. когда под целевую платформу компилятора нормального нет и не будет), а не тупо везде по принципу «ну ничего страшного же». И как по мне, предлагать что-то старше С99 могут либо бедолашные (кто по каким-то причинам очень ограничен в выборе компилятора), либо откровенно лютые ретрограды, которые отрицают stdint.h (а мне потом за ними чистить код, написанный в предположениях вида sizeof(int) == 2 и тому подобных) и считают необходимым заводить переменные строго в начале функции, а не минимизировать их область видимости (хотя это и холиварный тезис, но чем меньше контекст, тем проще код анализировать мозгами, и это нужно, не потому что мозги маленькие, а потому что если где-то можно накосячить, то рано или поздно накосячено будет и нужно минимизировать такие возможности by-design, а заодно не добавлять лишних сложностей для поиска косяков) и заводить разные переменные для разных нужд (которые компилятор всё равно сольёт в одну область памяти, если так можно), а не делать эту работу за компилятор (добавляя нелепые ошибки при этом, конечно же). Уже ради этих двух вещей нужен C99 (ими дело не ограничивается, но я про достаточный критерий). А если нужны атомарные операции, потоки (системное программирование ядром не ограничивается), static_assert и прочие мелкие радости — уже C11 нужен. Только вот мой тезис в том, что останавливаться на этом не нужно. Понятно, что можно закат Солнца вручную организовывать, только вот зачем, разве что ради сомнительного самоутверждения (путь школоты, которая не по возрасту, а по строению души) и job security.
> А мне показалось, что ты как раз чуть ли не за деньги
> тут рекламируешь обезьянохруст, противопоставляя его сишечке. Почему не С++, почему не
> Objective-C, почему не D наконец? А, анон? Чем тебе так приглянулся
> недоязык с уродливым дегенеративным синтаксисом, созданный в берлоге браузерных макак
> и продвигаемый, как ни странно, обос**вшимся по уши производителем процессоров?Что-что? Где это я такой тезис толкал? Наоборот, про синтаксис (и вообще читабельность) один из моих первых постов в этой теме был. Как и в случае не к ночи помянутого systemd, я вижу определённый смысл в том направлении (в самом направлении, подчёркиваю), в котором они работают, но конкретная реализация меня очень не устраивает. Но работать-то нужно. Рано Сишечке останавливаться на достигнутом.
>> косящему под олда
> Вот так одной фразой и палится школота.Если что-то можно сказать лаконично и доходчиво, на наиболее понятном для оппонента языке, — не вижу причин этого не делать, меня это школотой не делает, возможно, даже напротив: показывает что ещё не совсем мозги одеревенели (впрочем, с моей работой это вряд ли грозит).
А вот чьё-либо брызгание слюной на тему дегенератов, макак, маленьких мозгов, школотунства и прочих далёких от техники понятий — как раз такого оратора показывает со стороны если не возраста, то уж точно состояния души. В среде зрелых персонажей это лишнее.
> В среде зрелых персонажей это лишнее.В среде зрелых комментаторов, дружок, не переходят на личность, друг друга не называют персонажами и не бывает предвзятых модераторов, которые стирают комментарии старших товарищей исключительно из-за жжения у себя пониже спины.
Я тоже добавлю, хоть вопрос и не мне.>Вот это новости! На чём же они должны быть написаны?
На паскале, на модуле, на обероне, да хотя бы на плюсах.
>Назови-ка с аргументами, чего тебе не хватет в C89/90.
Не слишком ли жирный? Или серьезно? В антиквариате даже машиннонезависимых типов нет. Нитей нет. Моделей памяти нет. И это "системный" язык! На этом вообще нельзя писать без гамака, весь код сразу же становится непереносимым, все нужно обмазывать макросами и ассемблером. Ах да, для прикладного программирования тоже не подходит - вместо строковой библиотеки какой-то ад. Ну, может хоть байтовые трюки можно попробовать, язык же для этого? А нет. Тут не кастуй, это UB. Знаковое переполнение - UB. Битовые поля - UB. Сдвиги - UB. Битовые хаки снабжены таким количеством UB, что нужно 10 лет опыта чтобы примерно понимать что не делать, ессно компилятор ничего не скажет - все развалится когда нибудь само. Поддержки такой стандартной концепции как атомик - нет (а в "современном" С11 нет векторов). Может быть, метапрограммирование хорошо реализовано? Нет, препроцессор убогий. Вот и получается, что язык-то - говно.
> Я тоже добавлю, хоть вопрос и не мне.
>>Вот это новости! На чём же они должны быть написаны?
> На паскале, на модуле, на обероне, да хотя бы на плюсах.В этом вашем ИТ не ценятся интеллектуальные изобретения, потому что надо продавать инновационные прогрессивные новинки, а значит для программирования нужны не учёные, а индусы и умственно равные им эмигранты.
>>Назови-ка с аргументами, чего тебе не хватет в C89/90.
> Не слишком ли жирный? Или серьезно? В антиквариате даже // дальше поскипаноНет, в самый раз, причём жир натуральный, а не пальмовый.
Антиквариат, напоминаю повторно, был написан для системы команд PDP. Антиквариат отражает собой _эту_ архитектуру. Он не предназначался для написания программ для x86, которой вообще не было во дни его создания. Сишечку, наверное, не стоило бы преподавать и учить для работы на иных архитектурах, и такое мнение нередко высказывают, но так уж сложилось, что антиквариат востребован повсюду. Однако регулярно находятся дурачки, повторяющие мантру про Си как ассемблер. Это какой-то позор. Да, для PDP Си действительно был заменителем ассемблера, но для x86 таковым не является. Открываешь любой толковый учебник по ассемблеру штеудовского хлама и начинаешь прозревать, как всё на самом деле плохо в этом вашем винтеловском ИТ, сколько внутри паутины, костылей, подпорок и распорок. Но кто ж нынче читает те учебники… Даже про одинаковую сущность PAE и AMD64 не знают и не понимают, а проповедуют прогрессивность уродца.
А я недавно начал изучать малоизвестный среди опеннетовских аналитиков D. Не могу нарадоваться — так хорош этот язык. Уже написал несколько хеллоуворлдов и не останавливаюсь на достигнутом.
>> Даже про одинаковую сущность PAE и AMD64 не знают и не понимают, а проповедуют прогрессивность уродца.Всё-же PAE, которая (Physical Address Extension) это немного другое, поменьше, чем AMD64. PAE это до 36-ти битов физического адресного пространства (32-х битах виртуального), а AMD64 - по-моему это уже 40+ битов физического адресного пространства(64-х битах виртуального), плюс расширение регистров до 64-х бит (rax и т.д.), плюс доп. регистры (r8 - r15), ну и что SSE теперь должно быть обязательно, возможно и ещё, что-то по мелочи, что так на вскидку не вспомнилось.
>>> Даже про одинаковую сущность PAE и AMD64 не знают и не понимают, а проповедуют прогрессивность уродца.
> Всё-же PAE, которая (Physical Address Extension) это немного другое, поменьше, чем AMD64.
> PAE это до 36-ти битов физического адресного пространства (32-х битах виртуального),
> а AMD64 - по-моему это уже 40+ битов физического адресного пространства(64-х
> битах виртуального), плюс расширение регистров до 64-х бит (rax и т.д.),
> плюс доп. регистры (r8 - r15), ну и что SSE теперь
> должно быть обязательно, возможно и ещё, что-то по мелочи, что так
> на вскидку не вспомнилось.Не другое. То же самое. И в соответствующих документах это прямо написано (AMD64 без PAE не работает). Отличия сугубо косметические.
Можете сказать без обращения к документации, сколько вам и вашим программам доступно для самостоятельной адресации на самом деле? Если помните, как устроена виртуальная память в x86. Уверен, что многих поклонников жирных регистров и 64-битного светлого будущего ждёт большой сюрприз.
>>>> Даже про одинаковую сущность PAE и AMD64 не знают и не понимают, а проповедуют прогрессивность уродца.
>> Всё-же PAE, которая (Physical Address Extension) это немного другое, поменьше, чем AMD64.
>> PAE это до 36-ти битов физического адресного пространства (32-х битах виртуального),
>> а AMD64 - по-моему это уже 40+ битов физического адресного пространства(64-х
>> битах виртуального), плюс расширение регистров до 64-х бит (rax и т.д.),
>> плюс доп. регистры (r8 - r15), ну и что SSE теперь
>> должно быть обязательно, возможно и ещё, что-то по мелочи, что так
>> на вскидку не вспомнилось.
> Не другое. То же самое. И в соответствующих документах это прямо написано
> (AMD64 без PAE не работает). Отличия сугубо косметические.У нас используется PAE, и PSE36 в самописных системах без 64-х битного режима - т.е. 32-х разрядный защищённый режим - есть, PAE - есть, правда только из-за NX-бита, а вот 64-х разрядности - нету. То, что оно входит в AMD64 в качестве требований, как и тот-же SSE, не означает, что это одно и тоже.
> Можете сказать без обращения к документации, сколько вам и вашим программам доступно
> для самостоятельной адресации на самом деле? Если помните, как устроена виртуальная
> память в x86. Уверен, что многих поклонников жирных регистров и 64-битного
> светлого будущего ждёт большой сюрприз.В 32-х битном режиме доступно 4G виртуального адресного пространства. Которые обычно разделяются на две части - ядерную и прикладную, как вариант по 2G каждая, ну или можно сделать и 1G/3G и, на самом деле любое другое.
Не хочу тратить своё время на бессмысленные споры. Берите документацию «первооткрывателей» и читайте, она написана очень ясным языком и занимает немногим более тысячи страниц. У Штеуда мануалы на эту тему потолще будут.
AMD64 Architecture Programmer’s Manual
Volume 1: Application Programminghttps://www.amd.com/system/files/TechDocs/24592.pdf
Volume 2: System Programming
> В 32-х битном режиме доступно 4G виртуального адресного пространства. Которые обычно разделяются
> на две части - ядерную и прикладную, как вариант по 2G
> каждая, ну или можно сделать и 1G/3G и, на самом деле
> любое другое.Я не про это, а про доступ к регистрам.
Прошу прощения, всё-же не понял, про что Вы. У нас, в самописной системе используется PAE, при этом все регистры 32-х разрядные (eax и т.д) - сам процессор 64-х разрядность (в виде AMD64) не поддерживает.
> зачем нужно "это", если давно уже есть и активно используется СИ ? Что может "это", что НЕ может СИ ?
> ЗЫ: Жду агрессивных высказываний видаСтоило бы ждать ссылок на описание преимуществ языка над Си. Но на самом деле стоило бы не ждать, а самому пройти почитать, что бы вообще понимать о чём идёт дискуссия, а то неудобно получается.
> Что может "это", что НЕ может СИ ?Что может СИ, чего не может ассемблер? Что может ассемблер, чего не могут машинные коды? Это не риторические вопросы, это вопросы одного типа. И я очень рекомендую подумать их, и подумать почему же ядра сегодня пишут на C, если их можно писать на ассемблере. А зачем от машинных кодов ушли к ассемблерам? Это очень полезные размышления, и никто кроме тебя проделать их за тебя не сможет.
> ЗЫ: Жду агрессивных высказываний вида "ты ретроград, против технического прогресса, иди вообще откатись на самую первую версию СИ, а лучше на БИ, и не мешай прогрессу своими высказываниями ретроградными".
Я смотрю комментаторы выше тебя разочаровали в твоих ожиданиях. Держи: ты ретроград, против технического прогресса, иди вообще откатись на самую первую версию СИ, а лучше на БИ, и не мешай прогрессу своими высказываниями ретроградными".
> избавленные от таких проблем, как обращение к области памяти после её освобождения, разыменование нулевых указателей и выход за границы буфера.CONFIG_PAX_KERNEXEC=y
Решает проблемы С без всяких *растов
Даже те проблемы, которые таким путём как бы решаются, и то решаются не полностью, увы. Это совсем не «серебряные пули».
почему не C# или даже VB?
> почему не C# или даже VB?требуют ж интерпретатор байткода
возможно если впихнуть их в llvm, то получится что-то
языки с интерпретируемым байткодом имеют особую прелесть в рантаймоптимизациях
было бы очень интересно сравнить один и тот же код скомпилированный в машкады и запущеный на виртмашине с хорошей рантаймоптимизацией
llvm такое позволяет?
открывай сбор донейтов. Я пожертвую пару рублей (за js, конечно, кому нужен этот ваш устаревший и не имеющий модного npm поделок проклятого m$ который хочет всех пороботить?!)
вижу по теме донейтов ты больной на обе головы. здесь круглый год и в каждой теме подобный комментарий от тебя, хорошо если лишь один а не 5 или 10. нет бы давно уже денег на визит к доктору насшибал, всё здесь словоблудием занимаешься
От слова робот?
> почему не C# или даже VB?Потому что Sign# уже был в MS Singularity.
> Джош считаетНу, теперь все! раз сам Джош так считает..
Да пусть развлекаются. Мне как-то попадался даже компилятор для bash-скриптов, идея примерно того же уровня.
Вообщем, в недалеком будущем будет тут новость вида "по причине того, что gcc и СИ пользуются только 3% пользователей линукс, было принято решение дропнуть СИ и gcc, а в замен им предоставить rust и grr, а так же заменить устаревший glibc на новый прогрессивный gliRust, или сокращенно glist"
Судя по количеству уже написанного кода, это новости _далекого_ будущего.
> Судя по количеству уже написанного кода, это новости _далекого_ будущего.Вопрос не в переписывании существующего кода, а в возможности его трансляции на другой язык.
Раст не готов для системного программирования, но "в будущем будет как С, а C будет как ассемблер".
Похлопаем джошу за раздувание абстракций и бесполезную работу. Когда потомки спросят кто виноват, скажу это все Джош Триплет.
Зато хоть стало понятно, почему Штеуд разучился делать процессоры.Давай, Интел, жги сам себя!
По моему опыту си никаким боком не может заменить ассемблер в ядре. На ассемблере пишут то, что вообще непонятно на чем еще можно писать.
Это пропихивание Раста, или да? Кому-то неймётся и он, для раздувания ЧСВ, хочет потеснить С?
почему люди так любят раст? У него же синтаксис страшный как моя жизнь
> синтаксис страшный как моя жизнь+10 к элитарности
> синтаксис страшный как моя жизньда, страшный, тут ничего не скажешь, не c# ни разу.
Так кажется, когда видишь некоторые примеры и не до конца понимаешь, что они делают.
Всё встает на свои места, если хоть чуть-чуть разобраться.
Так-то в C || C++ можно и похлеще языковые конструкции встретить.
>Всё встает на свои места, если хоть чуть-чуть разобраться.Ага.
- "Мы не будет использовать указатели! У нас автомагия!"
прошло 5 минут...
- "Если надо использовать указатели, то вот вам как в Си"А теперь найдите системный код без указателей.
Очередной чукча-писатель. В расте есть указатели, но не сырые, а умные, с владением явным всегда. Хочешь указатели сырые, именно сишные, где никто ничего не гарантирует, хочешь эксплуатировать свои любимые double-free, утечечки, по которым так скучал - пишешь `unsafe` и довольствуешься этим говном. В этом плане, в расте нет указателей настолько же, насколько их нет в плюсах.Только тот, кто ничего не знает о расте будет писать такой комментарий, как ваш, чукча-писатель.
Нет там ничего особо страшного.
> почему люди так любят раст? У него же синтаксис страшный как моя жизньПриведи пару примеров.
Забавно, что есть искренние защитники языка, в котором нельзя банально стринги сложить без прямого использования функции 💩
Да, толковой альтернативы C не было в 90-ые. Но, люди, на дворе почти 2020-ые.
> Забавно, что есть искренние защитники языка, в котором нельзя банально стринги сложить
> без прямого использования функции 💩
> Да, толковой альтернативы C не было в 90-ые. Но, люди, на дворе
> почти 2020-ые.Я си изучаю месяц и уже пришел к выводу, что это не баг а фича. В СИ - все есть ячейка памяти. Если чего-то нет - можно написать свою функцию. Да поначалу дико, что нет explode как в php, но потом выясняется, что все-таки есть (не помню название), а потом - что оно не нужно, ведь можно функцию самому написать. Кстати что значит сложить стринги ? Я вот их не ношу, по этому не в теме.
По сабжу - если "стринг" это строка, то в си это массив, со своими элементами и как нужно сложить два массива - если элементы типа int, то что нужно - сложить a[0]+b[0].....a[n]+b[n] или дописать один массив в конец другого ?
>Я си изучаю месяцщас иксперд нам всё расскажет... и как стринги он не носит
В C++ строки ВНЕЗАПНО тоже всего лишь массив чаров, но там средства языка позволяют адекватно реализовать std::string, чего нет и никогда не будет в C:
std::string str1 = "one", str2 = "two";
std::string str3 = str1 + str2; // "onetwo"
Добро пожаловать в мир нормальных языков!Кроме того, это довольно безопасное применение чаров, где можно не выстрелить случайного себе в ногу при работе с сырыми чарами и маллоками, что может допустить и опытный разработчик.
> Если чего-то нет - можно написать свою функцию.
Круто! Давай писать всё с нуля, к черту многолетние либы. Да к черту и функции, которые в других языках есть в стандартной либе, ведь можно свою написать! :)
(надеюсь это был троллинг, тогда лайкос за него)
Мне больше нравятся паскалевские строки, когда нулевой элемент строки и есть сама длина строки.
С ними гораздо проще выполнять любые действия. Не нужно перебирать по одному байту, в поиске "\0"
Никаких выходов за пределы строки и утечек памяти.
Единственное неудобство - ограничение такой строки в 255 символов.
Но с другой стороны. Загляните в код любого драйвера. Где вы там видели строки больше 100-200 символов ?
в плюсах, как бы, объект string также содержит длину строки и ничего не перебирается, и ноль в конце есть для совместимости с системными функциями.
В современном Паскале особых ограничений нет (до High(SizeInt)).
По поводу сложения std::string - это не рекомендованных практика, т.к. несет в себе потерю производительности во столько раз, сколько раз там "+"."А + Б + Ц" несет в себе 3 разных сложения с выделением памяти и т.д.
Вы не правы. В C++ строки это отдельный тип (реализованный через объект, который внутри может быть хранить строки по форме, похожей на паскалевские строки с хранением длины строки отдельно и строки - отдельно). В C, на самом деле, отдельного строкового типа - нет, есть массив, и есть частный, договорной случай ASCIIZ строк - типа, а давайте, то, что ограничивается 0 и будем считать строкой. Со всеми вытекающими последствиями. В C Вам никто не мешает реализовать свой вариант строк, удобный именно Вам, ну или использовать какую-нибудь библиотеку, в которой это уже реализовано до Вас и для Вас.
> В C++ строки ВНЕЗАПНО тоже всего лишь массив чаров, но там средства
> языка позволяют адекватно реализовать std::string, чего нет и никогда не будет
> в C:
> std::string str1 = "one", str2 = "two";
> std::string str3 = str1 + str2; // "onetwo"
> Добро пожаловать в мир нормальных языков!В "нормальном языке" результатом такого должен быть статистический массив символов, созданный на этапе трансляции, а не вот эти вот 3 вызова malloc, убивающие программу при нехватке памяти.
> std::string str1 = "one", str2 = "two";
> std::string str3 = str1 + str2; // "onetwo"
> Добро пожаловать в мир нормальных языков!Но так же никто не делает на практике. Выделять память под третью строку, чтобы просуммировать две предыдущие? Как правило есть предвыделенный буфер, который перевыделяется. Часто этим предвыделенным буфером является первая из суммируемых строк. Если нет, то это часто форматный вывод в динамически выделяемый буфер. Что в C++, что в rust'е.
Блин ну сложение строк это конечно просто самая нужная функция в ядре - куда уж без неё
А чё не JS-то?
> А чё не JS-то?потомучта динамическая типизация должна сдохнуть в муках
Только скорее ты сдохнешь быстрее :)
Грег заразился хипстерством. Ха-ха, ему что мама не рассказывала, что хипстерство заразно? Если его не выкинут срочно из разработчиков ядра, с целью ограничить распространение инфекции, то есть риск эпидемии.
Его не выкинут а повысят. Он в нужном направлении смотрит. Си - это устаревший кросплатформенный ужас, который позволяет просто взять и собрать весь софт под новый Бродком или прости господи Ексунос. Ну кому такой нужен?
Такое программирование совсем не безопасно.
Объясните, кто-нибудь, на пальцах, почему драйвера, и вообще ядро, нельзя писать на современных плюсах С++?
Из-за "тяжелого" рантайма? Или там есть какие-то фундаменталные ограничения? Чесслово не могу понять.
В MacOS X, например, IOKit - это C++ фреймворк для системных драйверов. Но для того чтобы рантайм не был тяжёлым, из него выпилили исключения, множественное наследование, шаблоны и RTTI.
А вот шаблоны зря. Они же compile time и потому в runtime ничего не весят.
> А вот шаблоны зря. Они же compile time и потому в runtime
> ничего не весят.Для NT реализована стандартная библиотека C++ https://github.com/icestudent/ontl
где всё вышеперечисленное сохранено (с учётом естественных ограничений на использование исключений на высоких IRQL).
Судя по нику разработчика, дальше курсовика не продвинется.
> Судя по нику разработчика, дальше курсовика не продвинется.Судя по истории в 10 лет коммитов и порядка 50 человеко-лет по некоторым метрикам, тема курсовика того Студента "ненавязчивый троллинг ламеров".
Ну т.е. выпилили всё что делает его С++-ом )))
> Объясните, кто-нибудь, на пальцах, почему драйвера, и вообще ядро, нельзя писать на
> современных плюсах С++?На С++ возможно написать работающую программу, не владея на должном уровне языком и/или не понимая принципы работы базовых вещей (таких как аппаратный стек). Для ядра такое неприемлемо. Язык С отсеивает опасных и потому нежелательных дилетантов.
> Из-за "тяжелого" рантайма? Или там есть какие-то фундаменталные ограничения?
Рантайм может быть существенно сокращён в объёме и не является обязательным.
> На С++ возможно написать работающую программу, не владея на должном уровне языком и/или не понимая принципы работы базовых вещей (таких как аппаратный стек). Для ядра такое неприемлемо.Хотите сказать на чистом С _невозможно_ написать работающую программу, невладея на должном уровне языком и/или не понимая принципы работы базовых вещей?
Ну ерунда-же.
Возможно, но уровни эти существенно разные. Насмотрелся на PHP-разработчиков, лабающих на плюсах, но впадающих в ступор при виде С.
> Возможно, но уровни эти существенно разные. Насмотрелся на PHP-разработчиков, лабающих
> на плюсах, но впадающих в ступор при виде С.Как же они на плюсах работают? А пример какой-то их работы есть где посмотреть?
>> Возможно, но уровни эти существенно разные. Насмотрелся на PHP-разработчиков, лабающих
>> на плюсах, но впадающих в ступор при виде С.
> Как же они на плюсах работают?На плюсах, в отличии от С, можно поставить + между двумя строками, вот и работают, передавая на каждый чих vector<string> по значению. Работает же, а шо тут такого? (с)
> А пример какой-то их работы есть
> где посмотреть?Специально не искал, видел такое в проприетари, подрабатывая "реаниматором".
> На С++ возможно написать работающую программу, не владея на должном уровне языком и/или не понимая принципы работы базовых вещей (таких как аппаратный стек).Не так. На С++ невозможно написать работающую программу, владея на должном уровне языком и понимая принципы работы базовых вещей. Потому что овладеть всем этим и понять его для человека физически невозможно.
Да, Rust стремится раздуться в такого же монстра, но пока отстаёт.
>> На С++ возможно написать работающую программу, не владея на должном уровне языком и/или не понимая принципы работы базовых вещей (таких как аппаратный стек).
> Не так. На С++ невозможно написать работающую программу, владея на должном уровне
> языком и понимая принципы работы базовых вещей. Потому что овладеть всем
> этим и понять его для человека физически невозможно.Оба тезиса не противоречат друг другу. Таков эффект Даннинга - Крюгера.
> Да, Rust стремится раздуться в такого же монстра, но пока отстаёт.
>не владея на должном уровне языком и/или не понимая принципы работы базовых вещей (таких как аппаратный стек). Для ядра такое неприемлемо. Язык С отсеивает опасных и потому нежелательных дилетантов.Да ладно вам. Как это C вам отсеет HelloWorld-прогеров или запретит им на Сях писать? Ну отсейте производителей железок тогда, которые вам хоть какие-то кривые драйвера на Сях, заметьте, предоставили.
Писать можно что угодно на чём угодно. Если вопрос в "что лучше", а то лучше то, что лучше а не то, что хуже. Извините. Список того, чем раст лучше ц++ есть и не один. Несколько лет назад была конфа где разработчику фейсбука рассказывал о самых жёстких багах в их коде на ц++, так вот каждый баг из этого списка просто бы не существовал на расте, т.к. компилятор бы не позволил такое сделать. https://www.reddit.com/r/rust/comments/cq9rco/cppcon_2017_cu.../
> Писать можно что угодно на чём угодно. Если вопрос в "что лучше",Вопрос вообще не в лучше/безопаснее и проч.
Группа людей с консервативными взглядами годами совместно работает над ядром. Эта группа решает вопросы на каком языке разрабатывать ядро и в каком месте должна стоять запятая в принимаемых патчах. Про С++ говорят примерно то, что я мягко резюмировал в #187.
Тот факт, что Грег заявил "как здорово, давайте посмотрим, что вы нам предложите" совсем не означает, что предложеное не завалят по формальным поводам на ревью.
> предложеноеТо есть если вот такое я хочу отправить как патч, мне укажут на ошибку и не примут. Хотя остальное может иметь гарантии в 146% безопасности, подкреплённые 7-ю печатями.
> Если вопрос в "что лучше", а то лучше то, что лучше а не то, что хуже.Ну какой там ещё C++ или rust, ты русским-то языком мне парсер сломал.
Извините, не могу как аноним править, поторопился.
>так вот каждый баг из этого списка просто бы не существовал на расте, т.к. компилятор бы не позволил такое сделатьА, собственно, что мешает компилятору C++ тоже стать значительно более строгим, даже особо не меняя стандарты языка? Ввести опцию-режим суперстрогости -fsuperstrict
Тем временем: https://paste.pics/b49d5b5b7eebf3dd595bff89333d4c90
Ну наконец то у Intel пропадут все дырки в процессорах и драйверах. Останутся только электроны, раст и терможвачка.
>будущее системного программирования за RustЗа теми, кто ставит компилятор не из пакетов, а скачивая и исполняя баш-скрипты, а потом ставит зависимости из центрального репозитория, сайт которого не заботает без javascript, а система сборки допускает выполнение команд и ставит зависимости в подпапку?
Иными словами:
* подвергает риску сборщиков пакетов
* подвергает риску пользователей собранных пакетов
* неэффективно собирает, перерасходуя ресурсы.Как такое может найти популярность в среде программистов, отличных от любителей NPM? А то, что это собираются использовать для системного программирования и что мне придётся использовать ядро, собранное этим, вообще меня в шок подвергает.
Можно забэкдорить всю инфраструктуру, забекдорив сборочную систему. Бэкдор можно сделать необнаружимым на системах, использующих забэкдоренные компоненты. То есть на всех системах, потому что без драйверов и ядра ни одна система не работает. И не надо тешить себя иллюзией, что колибри ОС вам поможет. Ведь модули UEFI тоже можно забэкдорить, а бэкдор в них адаптировать для инфицирования Kolibri OS и компиляторов для неё.
Не волнуйся, если хотя бы один такой бекдор вскроется, то это скомпрометирует всю систему целиком.
Ну вскроется, и что дальше? Перекомпилировать весь софт на чистых доверенных системах с новыми бэкдорами, на этот раз завёрнутыми в SGX? Никто это делать не будет.
> Как такое может найти популярность в среде программистовДля этого можно почитать мнение и аргументацию этих самых программистов. Ничего сложного в этом нет, всё в гугле. Без обид, но твои опасения про пакеты в сравнении с тем, что раст даёт разработчикам - это несоизмеримо.
>сайт которого не заработает без javascriptВместо тормозного crates.io есть lib.rs (серверная часть на Rust и работает без JS)
>ставит зависимости в подпапкуМожно прописать переменную окружения "CARGO_TARGET_DIR", тогда все крейты будут собираться в одной папке. Но при обновлении компилятора и при несовпадении версии крейта он будет собран заново.
Интересные замечания по теме
https://lwn.net/Articles/797714/
Драйвер nvidia будет? :)
> Драйвер nvidia будет? :)Так то не шутите, желанья сбываются. :)
раст не создавался как системный язык. не надо народ пугать. когда он дорастет до такого уровня, то он раздуется как с++ и никто уже ничего полностью в нем понять не сможет))) и появится новы сраст какой нибудь. не парьтесь
Всё хорошо.
Вот только ethernet в rpi3 виснет. И всю усбню вешает.