The OpenNET Project / Index page

[ новости /+++ | форум | wiki | теги | ]

Фреймворк для написания защищённых драйверов для ядра Linux на языке Rust

01.09.2019 09:34

Джош Триплет (Josh Triplett), работающий в компании Intel и входящий в комитет, курирующий развитие Crates.io, в своём выступлении на конференции Open Source Technology Summit представил рабочую группу, нацеленную на доведение языка Rust до паритета с языком Си в области системного программирования.

В рабочей группе, которая находится в процессе создания, разработчики Rust совместно с инженерами из компании Intel подготовят спецификации с определением функциональности, которую необходимо реализовать в Rust для системного программирования. Системное программирование часто требует низкоуровневых манипуляций, таких как выполнение привилегированных процессорных инструкций и получение детальных сведений о состоянии процессора. Из уже развиваемых для Rust подобных возможностей отмечается поддержка неименованных структур, объединений (union), ассемблерных вставок (макрос "asm!") и формата чисел с плавающей запятой BFLOAT16.

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

В ходе обсуждения выступления Джоша была высказана идея добавления в ядро Linux возможности разработки драйверов на языке Rust, что позволит с минимальными усилиями создавать безопасные и более качественные драйверы, избавленные от таких проблем, как обращение к области памяти после её освобождения, разыменование нулевых указателей и выход за границы буфера.

Грег Кроа-Хартман (Greg Kroah-Hartman), отвечающий за поддержку стабильной ветки ядра Linux, выразил готовность добавить в ядро фреймворк для разработки драйверов на языке Rust, если он будет обладать реальными преимуществами по сравнению с Си, например, будет предоставлять безопасные обвязки над API ядра. Кроме того, Грег рассматривает данный фреймворк только как опцию, не активную по умолчанию, чтобы не включать Rust в число сборочных зависимостей к ядру.

Оказалось, что несколько команд уже работают в данном направлении. Например, разработчики из компании "Fish in a Barrel" подготовили инструментарий для написания загружаемых модулей для ядра Linux на языке Rust, используя для повышения защиты набор абстрактных прослоек над интерфейсами и структурами ядра. Прослойки автоматически генерируются на базе имеющихся заголовочных файлов ядра при помощи утилиты bindgen. Для сборки прослоек используется Clang. Собираемые модули помимо прослоек используют пакет staticlib.

Параллельно развивается ещё один проект, сосредоточенный на разработке драйверов для встраиваемых систем и устройств интернета вещей, который также использует bindgen для генерации прослоек на основе заголовочных файлов ядра. Фреймворк позволяет добиться повышения безопасности драйверов без внесения изменений в ядро - вместо создания в ядре дополнительных уровней изоляции для драйверов, предлагается блокировать проблемы на этапе компиляции, применяя более безопасный язык Rust. Предполагается, что подобный подход может оказаться востребован производителями оборудования, разрабатывающими проприетарные драйверы на скорую руку без проведения должного аудита.

Не вся задуманная функциональность пока реализована, но фреймворк уже вполне пригоден для работы и использован для написания рабочего драйвера для Ethernet-контроллера LAN9512 USB, поставляемого в плате Raspberry Pi 3. В качестве эталонной реализации при написании Rust-драйвера был использован существующий драйвер smsc95xx, написанный на языке Си. Отмечается, что размер модуля и накладные расходы от runtime-компонентов при разработке драйвера на Rust незначительные, что позволяет применять фреймворк для устройств с ограниченными ресурсами.

  1. Главная ссылка к новости (https://linux.slashdot.org/sto...)
  2. OpenNews: Эксперимент по разработке частей ядра Linux на языке Rust
  3. OpenNews: Выпуск операционной системы Redox OS 0.5, написанной на языке Rust
  4. OpenNews: Cloudflare опубликовал реализацию VPN WireGuard на языке Rust
  5. OpenNews: Intel развивает открытую прошивку ModernFW и гипервизор на языке Rust
  6. OpenNews: Компилятор Rust добавлен в состав дерева исходных текстов Android
Лицензия: CC-BY
Тип: К сведению
Ключевые слова: rust, kernel, driver
При перепечатке указание ссылки на opennet.ru обязательно
Обсуждение (194) Ajax | 1 уровень | Линейный | Раскрыть всё | RSS
  • 1.2, Аноним (2), 10:25, 01/09/2019 [ответить] [﹢﹢﹢] [ · · · ]  
  • –9 +/
    >BFLOAT16

    И где в системном программировании растоманы видели 16-тиразрядные числа с плавающей точкой? А также где он видели соответствующе аппаратные ускорители?

     
     
  • 2.40, Аноним84701 (ok), 12:14, 01/09/2019 [^] [^^] [^^^] [ответить]  
  • +12 +/
    >> 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.

     
  • 2.45, Ю.Т. (?), 12:26, 01/09/2019 [^] [^^] [^^^] [ответить]  
  • +1 +/
    Не смотрел, но предполагаю: обычный float с 16 десятичными знаками. А что, в системном программировании запрещено использовать вещественные числа?
     
     
  • 3.51, Аноним (51), 12:36, 01/09/2019 [^] [^^] [^^^] [ответить]  
  • +/
    Возможно, имелось в виду, что в ядре FPU и всяческие векторные инструкции не юзаются, чтоб не тратить ресурсы на сохранение контекста (за редкими исключениями вроде криптографии)
     
  • 3.94, all_glory_to_the_hypnotoad (ok), 15:08, 01/09/2019 [^] [^^] [^^^] [ответить]  
  • +1 +/
    float и любые другие похожие числа не вещественные.
     
     
  • 4.138, asdasdasd (?), 20:52, 01/09/2019 [^] [^^] [^^^] [ответить]  
  • –1 +/
    Математики проснулись? XD
     
  • 4.223, Аноним (223), 23:10, 02/09/2019 [^] [^^] [^^^] [ответить]  
  • +/
    > float и любые другие похожие числа не вещественные.

    И не (обязательно) числа.

     
  • 2.189, fi2fi (?), 11:47, 02/09/2019 [^] [^^] [^^^] [ответить]  
  • +/
    может тут Intel FPGAs???
     

  • 1.3, zo0M (ok), 10:26, 01/09/2019 [ответить] [﹢﹢﹢] [ · · · ]  
  • +3 +/
    Ржавчина распространяется, радует)
     
     
     
    Часть нити удалена модератором

  • 3.30, burjui (ok), 11:37, 01/09/2019 [^] [^^] [^^^] [ответить]  
  • +/
    Rust даже с unsafe намного лучше C
     
     
  • 4.32, заминированный тапок (?), 11:48, 01/09/2019 [^] [^^] [^^^] [ответить]  
  • +1 +/
    судя по всему, opennet тоже на раст переписан :D
     
  • 4.183, Аноним (183), 11:20, 02/09/2019 [^] [^^] [^^^] [ответить]  
  • +/
    чем?

    если писать что-то для ядра, то ты почти всегда пишешь unsafe

     
     
  • 5.200, Wilem (?), 14:49, 02/09/2019 [^] [^^] [^^^] [ответить]  
  • +/
    Есть такая штука - переиспользование кода. С unsafe ты пишешь что-то базовое, хорошо тестируешь, а потом делаешь надстройки поверх, без unsafe. Так весь растовый stdlib построен.

    Есть например проект, где на расте пилят операционку с нуля в формате блога - https://os.phil-opp.com/ , и там далеко не всё unsafe.

    Также есть куча библиотек-драйверов для embedded устройств, построенных поверх unsafe-кода и в них unsafe практически нет, например https://github.com/japaric/l3gd20/blob/master/src/lib.rs.

     
  • 5.215, burjui (ok), 16:44, 02/09/2019 [^] [^^] [^^^] [ответить]  
  • +/
    > чем?

    borrow checker, move semantics, ADT (Enum), pattern matching, generics
    Да хотя бы этим. Пожалуй, если начну перечислять каждое преимущество Rust над C, случайно напишу ещё одну Rust Book, только хуже.

     
     
  • 6.245, Аноним (245), 01:19, 04/09/2019 [^] [^^] [^^^] [ответить]  
  • +1 +/
    Пока что ты написал типовой список баззвордов.
     
     
  • 7.248, имя (ok), 02:20, 04/09/2019 [^] [^^] [^^^] [ответить]  
  • +/
    > ADT
    > pattern matching
    > типовой список баззвордов

    Вы всё ещё собираете-разбираете tagged union руками, с ручной копипастой, например, [CODE]else if (s.type = JSON_ARRAY)[/CODE] или [CODE]else if (s instanceof JSONArray)[/CODE]?

    Хотя о чём это я, на опеннете ведь кроме суровых энтерпрайзников и программистов GNOME никого нет…

     
  • 7.249, burjui (ok), 21:36, 04/09/2019 [^] [^^] [^^^] [ответить]  
  • +/
    > Пока что ты написал типовой список баззвордов.

    Аргумент, достойный высоко просвещённого мыслителя. Ну да, сложно спорить, когда не понимаешь смысл "баззвордов". С такими аргументами, как у вас, я бы вам посоветовал разыменовать указатель на всем известное направление (гугл).

     
  • 2.43, user90 (?), 12:23, 01/09/2019 [^] [^^] [^^^] [ответить]  
  • –1 +/
    Энтропия, приятель. В запущенных случаях, без должного ТО все гниет и ржавеет..
     
  • 2.240, Аноним (240), 14:02, 03/09/2019 [^] [^^] [^^^] [ответить]  
  • +3 +/
    >Ржавчина распространяется

    Нужно антикоррозийное средство.

     
     
  • 3.246, Аноним (245), 01:19, 04/09/2019 [^] [^^] [^^^] [ответить]  
  • +1 +/
    Палец линуса.
     

  • 1.4, Аноним_t (?), 10:26, 01/09/2019 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    > В качестве эталонной реализации при написании Rust-драйвера был использован существующий драйвер smsc95xx, написанный на языке Си.

    Даже здесь не смогли написать сами, а как всегда - "переписали". Интересно, это свойство языка или свойство программистов на этом языке?

     
     
  • 2.11, Аноним (11), 10:37, 01/09/2019 [^] [^^] [^^^] [ответить]  
  • +/
    А что такого?
    Более чем нормально переписать с языка, где половина разработки - борьба с самим языком, его дырами, утечками, ub и т.д.
     
     
  • 3.27, заминированный тапок (?), 11:32, 01/09/2019 [^] [^^] [^^^] [ответить]  
  • +2 +/
    >Более чем нормально переписать с языка, где половина разработки - борьба разработчика с самим собой, его дырами, криворукостью, ub и т.д.
     
     
  • 4.130, имя (ok), 19:17, 01/09/2019 [^] [^^] [^^^] [ответить]  
  • +4 +/
    А вот и внимательные гении без единого double free в огромном хелоу-ворлде подошли.
     
     
  • 5.135, аноним3 (?), 20:28, 01/09/2019 [^] [^^] [^^^] [ответить]  
  • +2 +/
    они все думают что их инструмент единственно верный. и не понеимают того , что ключь на 10 не нужно сравнивать с разводным)))
     
  • 5.169, Урри (?), 09:21, 02/09/2019 [^] [^^] [^^^] [ответить]  
  • +/
    Для неосиляторов и макак давно придуманы удобные библиотеки. Например, https://github.com/Snaipe/libcsptr
     
     
  • 6.173, имя (ok), 10:23, 02/09/2019 [^] [^^] [^^^] [ответить]  
  • +3 +/
    > 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); }

    Ну ооооочень удобные библиотеки. Кому там ржавые закорючки не нравились?

    И, к слову, ни одного примера с передачей владения в вызываемую функцию.

     
     
  • 7.175, Совершенно другой аноним (?), 10:37, 02/09/2019 [^] [^^] [^^^] [ответить]  
  • +/
    >> 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.


     
  • 4.152, Аноним (152), 03:11, 02/09/2019 [^] [^^] [^^^] [ответить]  
  • +1 +/
    Печально, что жалкие людишки не подходят для написания кода на этом великолепном ЯП.
     
     
  • 5.247, draw1 (?), 02:01, 04/09/2019 [^] [^^] [^^^] [ответить]  
  • +/
    Жалкие людишки, в базовой комплектации, вообще мало для чего подходят. Но обучение и практика, и, как следствие, знания и опыт (в это сложно, наверное, будет поверить) творят прям чудеса (включая rocket science, не говоря уж про какие бы то ни было ЯП).
     
  • 2.12, Аноним (12), 10:39, 01/09/2019 [^] [^^] [^^^] [ответить]  
  • +6 +/
    так здесь наоборот, позволит сравнить пригодность языка для подобных задач
    эсть наглядный и рабочий "эталон", а не конь в вакууме
     
  • 2.201, Wilem (?), 14:52, 02/09/2019 [^] [^^] [^^^] [ответить]  
  • +1 +/
    Это демонстрация того, что оно работает. Что бы показать, что что-то работает правильно, надо иметь эталон для сравнения. И вот непонимание таких очевидных вещей - это свойство не языка, а комментаторов не имеющих отношения не то, что к разработке, а даже к здравому смыслу.
     

  • 1.7, Аноним (-), 10:33, 01/09/2019 [ответить] [﹢﹢﹢] [ · · · ]  
  • +8 +/
    > Джош считает, что будущее системного программирования за Rust
    > а язык Си в современных реалиях претендует на место, которое в
    > прошлые годы занимал Ассемблер.

    Скорее всего соглашусь, но, опять же, это дело достаточно отдалённого будущего. Через 8-9 лет, это в лучшем случаем. В худшем случае (если индустрия и энтерпрайз будут со скрипом переходить на новый язык) раст может никогда и не заменить чистый си - у этих двух языков может быть своего рода паритет. Ассемблер, да, очень специальный язык. Он всегда будет, но будет лишь в необходимой минимальной мере.

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

     
     
  • 2.14, Аноним (14), 10:49, 01/09/2019 [^] [^^] [^^^] [ответить]  
  • +14 +/
    > тебе должно быть фиолетово на какие-то там тенденции - ты просто пишешь на том языке, который любишь

    О, уже безусловный базовый доход ввели, а я и пропустил.

     
     
  • 3.28, Аноним (28), 11:35, 01/09/2019 [^] [^^] [^^^] [ответить]  
  • +8 +/
    Анон, не все готовы продать душу за лишний динар, как ты. Кое-кто может что-то делать и для души, как говорится, ради удовольствия.
     
     
  • 4.140, пох. (?), 21:42, 01/09/2019 [^] [^^] [^^^] [ответить]  
  • +2 +/
    а детей твоих кормить кто будет - штандартенфюрер?!

    "для души" хорошо работать, пока ты не закончил универ по курсу гендерных штудий (если злой препод нагружает заданиями - надо пожаловаться на харасмент и анэквалити)

     
     
  • 5.158, Штандартенфюрер (?), 06:50, 02/09/2019 [^] [^^] [^^^] [ответить]  
  • +5 +/
    Аргумент так себе.
    Потому что нет такого преступления, которое человек не попытался бы оправдать необходимостью кормить своих детей. Это никогда им не помогает, но они пытаются снова и снова.
     
     
  • 6.179, пох. (?), 11:01, 02/09/2019 [^] [^^] [^^^] [ответить]  
  • +/
    да неважно, детей или себя самого - важно что жрать все хотят. И никакого способа кроме ежедневного офисного рабства в общем-то для получения этого жрат не придумано. "и хрен вы меня найдете" удается на самом деле единицам, да и те часто через пару лет возвращаются изрядно пощипанными и поджав огрызок откусанного хвоста

     
     
  • 7.194, Аноним (194), 12:06, 02/09/2019 [^] [^^] [^^^] [ответить]  
  • +/
    не понимаю что мешает на работе на одном языке для себя на другом если желание есть и хобби такое.
     
     
  • 8.198, пох. (?), 13:12, 02/09/2019 [^] [^^] [^^^] [ответить]  
  • +1 +/
    то что когда начинается работа за жрат - никакого для себя уже, к сожалению, н... текст свёрнут, показать
     
     
  • 9.216, Anonymoustus (ok), 18:07, 02/09/2019 [^] [^^] [^^^] [ответить]  
  • +1 +/
    Ты не вполне прав Dlang 8212 самый что ни на есть проект-хобби уровня подст... текст свёрнут, показать
     
  • 7.229, Аноним (229), 05:22, 03/09/2019 [^] [^^] [^^^] [ответить]  
  • –1 +/
    Не был в офисе уже 12 лет, на доход не жалуюсь, зарабатываю программированием. Что я делаю не так?
     
     
  • 8.235, пох. (?), 11:47, 03/09/2019 [^] [^^] [^^^] [ответить]  
  • +/
    сказки рассказываешь, вот что не так а не жаловаться - это молодец, не жалуйся ... текст свёрнут, показать
     
  • 8.242, Аноним (-), 16:10, 03/09/2019 [^] [^^] [^^^] [ответить]  
  • +/
    Ну я 5 лет там не был, но оно когда как - бывает, что зарабатываю ощутимо меньше... текст свёрнут, показать
     
  • 3.203, Wilem (?), 14:57, 02/09/2019 [^] [^^] [^^^] [ответить]  
  • +1 +/
    > О, уже безусловный базовый доход ввели, а я и пропустил.

    Валидный аргумент, и в этом смысле непросто - вакансий на раст мало. Но. Я например завтра иду на собеседование на фул-тайм писать на расте. Микросервисы и embedded. И это в небольшом городе. Полагаю, в Москве или крупных европейских городах с этим ещё лучше.

    Хотя про вакансии на раст есть одна оговорка. Их может быть мало, но это не значит, что на нём не пишут внутри компаний (а на нём пишут) потому, что на него переходят программисты, которые уже в штате, и нужды кого-то тащить извне особо нет. Что правильно. Если у тебя есть толковые инженеры, они на чём угодно смогут, если посчитают это разумным.

     
  • 2.61, Аноним (61), 12:56, 01/09/2019 [^] [^^] [^^^] [ответить]  
  • –1 +/
    Си это удобный ассемблер.
     
     
  • 3.65, Anonymoustus (ok), 13:12, 01/09/2019 [^] [^^] [^^^] [ответить]  
  • +2 +/
    > Си это удобный ассемблер.

    Си ни в каком виде не ассемблер. Небось вычитал где-то красивую метафору и понравилась? Си _был_ чем-то вроде макроассемблера для системы команд PDP, но для других архитектур он ничем принципиально не отличается от прочих языков. Яблоки в своё время вообще сделали системным языком объектный Паскаль с музыкой и танцами — и ничего.

     
  • 3.99, Аноним (99), 15:14, 01/09/2019 [^] [^^] [^^^] [ответить]  
  • +1 +/
    > Си это удобный ассемблер.

    Знаю, как удобно написать на С команду cvttsd2si. А как написать cvtsd2si -- не знаю.

     

  • 1.8, Hellraiser (??), 10:34, 01/09/2019 [ответить] [﹢﹢﹢] [ · · · ]  
  • +6 +/
    вот чем оказывается занимаются в штеуде вместо фикса уязвимостей в их процах
     
     
  • 2.10, Аноним (10), 10:36, 01/09/2019 [^] [^^] [^^^] [ответить]  
  • +8 +/
    Ты обнаглел гой.
    Чтоб барин что там исправлял.
    Побежал покупать новый процессор на 3% быстрее прошлого поколения
     
     
  • 3.68, Аноним (68), 13:35, 01/09/2019 [^] [^^] [^^^] [ответить]  
  • +5 +/
    > На 3% медленнее с новым Intel ME и свежим спектром.

    Fixed.

     

  • 1.16, Аноним (16), 11:10, 01/09/2019 [ответить] [﹢﹢﹢] [ · · · ]  
  • +2 +/
    >более качественные драйверы, избавленные от таких проблем, как обращение к области памяти после её освобождения, разыменование нулевых указателей и выход за границы буфера  

    строго говоря, в самом расте выше перечисленное достигается не с помощью какой-то особой магии, а например тупо рантайм-проверками в выражениях вроде "a[i]".

    Переходить ради такого на новый язык, в котором к тому же из всех архитектур полноценная поддержка есть только у x86? Сильно сомневаюсь.

    Раст пилится не как язык системного программирования, а как замена C++ в браузерах и прочем юзерспейсе. На нишу Си он претендовать не может (в обозримом будущем)

     
     
  • 2.21, Аноним (223), 11:20, 01/09/2019 [^] [^^] [^^^] [ответить]  
  • +2 +/
    > Переходить ради такого на новый язык, в котором к тому же из всех архитектур полноценная поддержка есть только у x86?

    А в чём проблема с другими архитектурами? Он же на LLVM.
    Впрочем, автора «инициативы» ввиду места работы другие архитектуры и не волнуют.

     
  • 2.33, Илья (??), 11:51, 01/09/2019 [^] [^^] [^^^] [ответить]  
  • +7 +/
    > строго говоря, в самом расте выше перечисленное достигается не с помощью какой-то особой магии, а например тупо рантайм-проверками в выражениях вроде "a[i]".

    Есть проверки в рантайме, а так же есть статический анализатор, "борроу-чекер".

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

    Вы не сможете создать две мутабельные ссылки на какой-нибудь участок памяти без явного заворачивания их в какой-нибудь <Arc<Mutex<...>>>.

     
     
  • 3.36, JL2001 (ok), 12:07, 01/09/2019 [^] [^^] [^^^] [ответить]  
  • +/
    > Например, анализатор не даст вам разделить какую-нибудь область памяти между двумя потоками,
    > пока вы явно не дадите слово пацана за то, что вы
    > предусмотрели все возможные последствия.

    и много то слово пацана стоит? компилятор вообще не должен бы верить программисту без тридцати трёх подписей и печатей "да я понимаю что я делаю"

     
     
  • 4.38, Илья (??), 12:10, 01/09/2019 [^] [^^] [^^^] [ответить]  
  • +2 +/
    Ну так и есть вообще.
     
  • 3.58, Аноним (58), 12:46, 01/09/2019 [^] [^^] [^^^] [ответить]  
  • –2 +/
    Если вся разница только в статическом анализаторе, то (сюрприз!) для C они тоже есть.
     
     
  • 4.63, red75prim (?), 13:01, 01/09/2019 [^] [^^] [^^^] [ответить]  
  • +/
    Сюрприз! Теорема Райса. Если язык не разработан для того, чтобы обеспечивать, скажем, отсутсвие висящих указателей, то статический анализатор сможет отловить только какие-то частные случаи, или отловить всё, но при этом выдавать и false positives.
     
     
  • 5.72, Аноним (28), 14:01, 01/09/2019 [^] [^^] [^^^] [ответить]  
  • –8 +/
    > Сюрприз! Теорема Райса.

    Сюрприз! Это теорема из _теории_ алгоритмов. То есть это теория, а не истина. Слышал о теории большого взрыва? Часть физиков её принимает, часть физиков нет. Понимаешь? Каждые N столетий те или иные теории могут подвергнуться опровержению. Таким образом мы не можем в споре аппелировать к теореме Райса, как к конечной истине. Это всего лишь одна из _интерпретаций_ рельности. В рамках своей интерпретации ты прав абсолютно! В рамках теории Большого взрыва ты прав абсолютно! Но в рамках теории космологической модели эволюции крупномасштабных структур ты неправ. Так как же ты можешь быть неправ в рамках неевклидовой геометрии.

     
     
  • 6.84, Аноним84701 (ok), 14:38, 01/09/2019 Скрыто модератором
  • +/
     
     
  • 7.89, Anonymoustus (ok), 14:47, 01/09/2019 Скрыто модератором
  • –1 +/
     
  • 7.91, nox. (?), 14:54, 01/09/2019 Скрыто модератором
  • –4 +/
     
     
  • 8.95, Аноним84701 (ok), 15:09, 01/09/2019 Скрыто модератором
  • +/
     
  • 7.92, nox. (?), 14:59, 01/09/2019 Скрыто модератором
  • +/
     
     
  • 8.98, Аноним84701 (ok), 15:11, 01/09/2019 Скрыто модератором
  • +/
     
     
  • 9.112, Аноним (28), 16:05, 01/09/2019 Скрыто модератором
  • –3 +/
     
     
  • 10.113, лол (?), 16:14, 01/09/2019 Скрыто модератором
  • +/
     
     
  • 11.115, Аноним (28), 16:27, 01/09/2019 Скрыто модератором
  • +/
     
     
  • 12.121, кек (?), 16:43, 01/09/2019 Скрыто модератором
  • +1 +/
     
  • 10.117, Аноним84701 (ok), 16:30, 01/09/2019 Скрыто модератором
  • +/
     
  • 7.109, Аноним (-), 15:56, 01/09/2019 Скрыто модератором
  • –3 +/
     
  • 5.102, Илья (??), 15:28, 01/09/2019 [^] [^^] [^^^] [ответить]  
  • +/
    > false positives.

    Не знаю как вам, а мне "ложные срабатывания" гораздо понятнее, чем "false positives."

     
  • 5.228, Илья (??), 01:20, 03/09/2019 [^] [^^] [^^^] [ответить]  
  • +/
    > false positives.

    Справедливости ради стоит сказать, что раст тоже зачастую вполне валидный код не пропускает.

     
  • 3.59, Аноним (16), 12:47, 01/09/2019 [^] [^^] [^^^] [ответить]  
  • +/
    в других языках разделение памяти между потоками успешно решается указанием "это потоко(не)безопасно" в документации. Не самая большая проблема.

    правило двух мутабельных ссылок введено для специфических случаев вроде инвалидации итератора при vector.push_back() (которые в C++ и так прекрасно ловятся и самим компилятором, и всеми возможными санитайзерами), а в остальном это мерзкое ненужное ограничение. Недаром в расте из коробки есть костыли вроде RefCell.

     
     
  • 4.104, Илья (??), 15:43, 01/09/2019 [^] [^^] [^^^] [ответить]  
  • –3 +/
    > Не самая большая проблема.

    не соглашусь.

     
  • 2.188, Омномним (?), 11:44, 02/09/2019 [^] [^^] [^^^] [ответить]  
  • +/
    >замена C++ в браузерах и прочем юзерспейсе

    Пока допилят, C++ превратится в прекрасного лебедя. Уже C++20 не за горами.

     
     
  • 3.199, red75prim (?), 13:17, 02/09/2019 [^] [^^] [^^^] [ответить]  
  • +/
    Прекрасного лебедя в органических наростах 10, 20, 40 летней давности. Напильник прилагается: c++ core guidelines.
     
  • 2.204, Wilem (?), 15:00, 02/09/2019 [^] [^^] [^^^] [ответить]  
  • +1 +/
    > Переходить ради такого на новый язык, в котором к тому же из всех архитектур полноценная поддержка есть только у x86

    А в чём неполноценность? Код на расте под разные армы собирают и запускают и оно работает.

     

     ....большая нить свёрнута, показать (26)

  • 1.17, Аноним (17), 11:11, 01/09/2019 [ответить] [﹢﹢﹢] [ · · · ]  
  • +17 +/
    > Предполагается, что подобный подход может оказаться воспребован производителями оборудования, разрабатывающими проприетарные драйверы на скорую руку без проведения должного аудита.

    Знаете к чему это приведет? К тому, что потом часть производителей, что все же пишут нормальные драйвера с должным аудитом, под давлением эффективных менеджеров будут писать их на скорую руку.

     
     
  • 2.20, анонимус12345 (?), 11:17, 01/09/2019 [^] [^^] [^^^] [ответить]  
  • +/
    плюсану тебе анонимный сборат
     
  • 2.22, Аноним (22), 11:23, 01/09/2019 [^] [^^] [^^^] [ответить]  
  • –2 +/
    А какая разница? Всё равно не нужно
    > производителями оборудования, разрабатывающими проприетарные драйверы
    > проприетарные
     

  • 1.19, анонимус12345 (?), 11:16, 01/09/2019 [ответить] [﹢﹢﹢] [ · · · ]  
  • +9 +/
    >Предполагается, что подобный подход может оказаться воспребован производителями оборудования, разрабатывающими проприетарные драйверы на скорую руку без проведения должного аудита.

    ооо, это то, о чём мечтают все "эффективные менеджеры": "пишите на Расте, там само собой всё становится безопасно и можно не тестить!" >_< (слов нет)

     
     
  • 2.24, KaE (ok), 11:24, 01/09/2019 [^] [^^] [^^^] [ответить]  
  • –1 +/
    И самое главное за памятью и указателями не следить. А если за памятью не следить, то работы меньше. А если работы меньше, то и зп ниже, а жиробасу во главе конторы прибыли больше. В этом и суть работы эффективного менеджмента.
     
     
  • 3.34, Илья (??), 12:01, 01/09/2019 [^] [^^] [^^^] [ответить]  
  • +/
    > А если за памятью не следить, то работы меньше.

    А кто сказал, что в расте не нужно следить за памятью? Там только что и делаешь, что "следишь за памятью" в момент написания кода.

     
     
  • 4.42, Forth (ok), 12:22, 01/09/2019 [^] [^^] [^^^] [ответить]  
  • +/
    Там не за памятью следят, а за использованием ссылок. Где ненужно ссылки не распихивают по переменным.
     

  • 1.26, Аноним (26), 11:27, 01/09/2019 [ответить] [﹢﹢﹢] [ · · · ]  
  • –1 +/
    надо sysvinit на rust переписать и вернуть в debian, ubuntu
     
     
  • 2.39, n80 (?), 12:12, 01/09/2019 [^] [^^] [^^^] [ответить]  
  • +1 +/
    Как будто сейчас в Debian нет sysvinit Право, замучали уже это форсить это De... текст свёрнут, показать
     

  • 1.29, Адекват (ok), 11:35, 01/09/2019 [ответить] [﹢﹢﹢] [ · · · ]  
  • +4 +/
    "Тревога!Тревога! Волк унес зайчат!!"

    "Джош считает, что будущее системного программирования за Rust, а язык Си в современных реалиях претендует на место, которое в прошлые годы занимал Ассемблер".

    Школьники-неосиляторы добрались до программирования ?
    Вообще дико видеть такие высказывания, учитывая, что ядро Линукса написано на СИ, кстати ядра виндов и маков на чем написаны ? Или что им движет ? зачем нужно "это", если давно уже есть и активно используется СИ ? Что может "это", что НЕ может СИ ?

    ЗЫ: Жду агрессивных высказываний вида "ты ретроград, против технического прогресса, иди вообще откатись на самую первую версию СИ, а лучше на БИ, и не мешай прогрессу своими высказываниями ретроградными".

     
     
  • 2.31, KaE (ok), 11:39, 01/09/2019 [^] [^^] [^^^] [ответить]  
  • +/
    >Что может "это", что НЕ может СИ ?

    кто НЕ может на СИ может на "этом".

     
     
  • 3.44, n80 (?), 12:24, 01/09/2019 [^] [^^] [^^^] [ответить]  
  • +2 +/
    Вот это, кстати, вряд ли.

    Писать на C гораздо легче, как по мне (в C умею, а вот растопрограммы пока что даже читать практически не получается, возможно, надо начать пытаться писать и тогда дело пойдёт, но это как-то не в приоритете совсем). Другое дело, что раст упрощает нахождение (а местами и вообще избегание) некоторого класса ошибок, которые нельзя просто так взять и совсем не допускать в C (не говоря уж про обнаружение в имеющемся коде), так что не надо тут про неосиляторов. Но как по мне, конечно, лучше бы пилили статический анализатор для C, пусть даже и требующий добавления нестандартных расширений языка. Но раз уж так, пусть делают.

     
     
  • 4.141, Forth (ok), 22:35, 01/09/2019 [^] [^^] [^^^] [ответить]  
  • +/
    Ты попробуй. У меня где-то с неделю ушло на въезжание что к чему.
    Конечно есть еще неясные темы, но в целом пишется и как то пока обратно на C не хочется.
     
     
  • 5.157, Anonymoustus (ok), 06:45, 02/09/2019 [^] [^^] [^^^] [ответить]  
  • +/
    > Ты попробуй. У меня где-то с неделю ушло на въезжание что к
    > чему.
    > Конечно есть еще неясные темы, но в целом пишется и как то
    > пока обратно на C не хочется.

    Так вот почему тебе так припекло, что ты удалил мои комментарии. Вот так молодец!

    Предвзятые «модераторы» — это то, что на следующий год лишит опеннет ещё половины донатов.

     
     
  • 6.162, имя (ok), 07:12, 02/09/2019 [^] [^^] [^^^] [ответить]  
  • –1 +/
    > Так вот почему тебе так припекло, что ты удалил мои комментарии. Вот так
    > молодец!

    Да-да, а бесполезные крики про макак, рукожопость и умственную отсталость всех, кто попытался написать хоть что-то сложнее hello world и быстрее, чем за выходные, тут, конечно же, вообще ни при чём.

    И эти люди ещё смеют что-то говорить про переход на личности в соседнем треде.

     
     
  • 7.163, Anonymoustus (ok), 07:28, 02/09/2019 [^] [^^] [^^^] [ответить]  
  • +1 +/
    Атмосферу на форуме всегда создают модераторы. Это разве новость? Если бы вахтёры не стирали наши содержательные комментарии, разжирев на донатах, не было бы этих потоков яда. У приличного уважающего себя анонима нет иного выхода, кроме заниматься троллингом. В этом виноваты исключительно местные вахтёры. Я уже дал опеннету чорную метку и не рассматриваю форум как место для содержательного общения.
     
     
  • 8.165, Maxim Chirkov (ok), 08:02, 02/09/2019 [^] [^^] [^^^] [ответить]  
  • +/
    Провёл аудит недавно удалённых ваших сообщений, всё удалено по существу Ваши с... текст свёрнут, показать
     
     
  • 9.168, Anonymoustus (ok), 09:00, 02/09/2019 [^] [^^] [^^^] [ответить]  
  • –1 +/
    То есть когда в мой адрес пишут буквально эти же самые слова, никто не замечает ... текст свёрнут, показать
     
     
  • 10.193, Maxim Chirkov (ok), 11:58, 02/09/2019 [^] [^^] [^^^] [ответить]  
  • +/
    Я в последнее время модерирую почти только на основе жалоб через Сообщить модер... текст свёрнут, показать
     
     
  • 11.217, Anonymoustus (ok), 18:13, 02/09/2019 [^] [^^] [^^^] [ответить]  
  • +/
    Зачем вообще заниматься безрезультатным лечением прыщей, а не самой болезни Сде... текст свёрнут, показать
     
  • 7.164, Anonymoustus (ok), 07:31, 02/09/2019 [^] [^^] [^^^] [ответить]  
  • +/
    А такой сверхсодержательный комментарий они оставили:

    https://www.opennet.ru/openforum/vsluhforumID3/118332.html#104

    Я считаю, что излишне что-то ещё по этому поводу пояснять. Опеннет мёртв как площадка для общения. Здесь ничего не будет, кроме яда и срачей.

     
     
  • 8.221, Илья (??), 21:09, 02/09/2019 [^] [^^] [^^^] [ответить]  
  • +/
    Тут, пожалуй, соглашусь... текст свёрнут, показать
     
  • 2.37, JL2001 (ok), 12:09, 01/09/2019 [^] [^^] [^^^] [ответить]  
  • –1 +/
    > Школьники-неосиляторы добрались до программирования ?
    > Вообще дико видеть такие высказывания, учитывая, что ядро Линукса написано на СИ,
    > кстати ядра виндов и маков на чем написаны ? Или что
    > им движет ? зачем нужно "это", если давно уже есть и
    > активно используется СИ ? Что может "это", что НЕ может СИ ?

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

    вот именно что вылизать код на расте (лично я за D) гораздо быстрее, легче, требует меньшего опыта и знаний
    даж на жаве есть неочевидные и странные соглашения по работе кода, но в сях - он весь из такого

     
  • 2.48, Аноним (48), 12:33, 01/09/2019 [^] [^^] [^^^] [ответить]  
  • +2 +/
    Остожонее, не переполни буфер!
     
  • 2.49, n80 (?), 12:34, 01/09/2019 [^] [^^] [^^^] [ответить]  
  • –2 +/
    Строго говоря, не от хорошей жизни они на C написаны Ещё бы стандарт у C развив... текст свёрнут, показать
     
     
  • 3.55, Anonymoustus (ok), 12:40, 01/09/2019 [^] [^^] [^^^] [ответить]  
  • –1 +/
    Вот это новости На чём же они должны быть написаны Назови-ка с аргументами, че... текст свёрнут, показать
     
     
  • 4.69, n80 (?), 13:39, 01/09/2019 [^] [^^] [^^^] [ответить]  
  • +/
    Ха, как будто на этот вопрос есть простой ответ У всех имеющихся инструментов е... текст свёрнут, показать
     
     
  • 5.76, JL2001 (ok), 14:20, 01/09/2019 [^] [^^] [^^^] [ответить]  
  • +1 +/
    > Зачем я серьёзно отвечаю троллю, косящему под олда — вопрос, конечно, интересный.

    хороший серьёзный ответ прочтут и другие

     
  • 5.79, Anonymoustus (ok), 14:23, 01/09/2019 [^] [^^] [^^^] [ответить]  
  • +/
    На этот вопрос есть ответ и он давно дан в написанном ПО Выбор для написания си... текст свёрнут, показать
     
     
  • 6.83, Forth (ok), 14:38, 01/09/2019 [^] [^^] [^^^] [ответить]  
  • +/
    Фортран да, не годится.
    А что мешает на паскале писать системное ПО?
    Не могу вспомнить примера, когда на C будет заведомо проще и удобнее писать.
     
     
  • 7.87, Anonymoustus (ok), 14:44, 01/09/2019 [^] [^^] [^^^] [ответить]  
  • +/
    Да ничего, в принципе, не мешает, просто сейчас не модно. А Яблоки же таки писали на своём варианте.

    Но есть всё же обоснованные мнения против, пусть и относящиеся к старым версиям языка:

    https://wiki.lazarus.freepascal.org/Why_Pascal_is_Not_My_Favorite_Programming_

    Да и сам Вирт для создания ПО предлагает всё-таки другие языки. Не вижу оснований сомневаться в компетентности Вирта. :)

     
  • 6.108, n80 (?), 15:54, 01/09/2019 [^] [^^] [^^^] [ответить]  
  • +/
    А тут кто-то спорил с тем, что он даёт возможности Я лишь говорю про возможност... текст свёрнут, показать
     
     
  • 7.159, Anonymoustus (ok), 06:50, 02/09/2019 [^] [^^] [^^^] [ответить]  
  • +/
    > В среде зрелых персонажей это лишнее.

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

     
  • 4.153, Аноним (152), 04:12, 02/09/2019 [^] [^^] [^^^] [ответить]  
  • +1 +/
    Я тоже добавлю, хоть вопрос и не мне На паскале, на модуле, на обероне, да хотя... текст свёрнут, показать
     
     
  • 5.156, Anonymoustus (ok), 06:39, 02/09/2019 [^] [^^] [^^^] [ответить]  
  • +1 +/
    В этом вашем ИТ не ценятся интеллектуальные изобретения, потому что надо продава... текст свёрнут, показать
     
     
  • 6.171, Совершенно другой аноним (?), 10:01, 02/09/2019 [^] [^^] [^^^] [ответить]  
  • +/
    >> Даже про одинаковую сущность PAE и AMD64 не знают и не понимают, а проповедуют прогрессивность уродца.

    Всё-же PAE, которая (Physical Address Extension) это немного другое, поменьше, чем AMD64. PAE это до 36-ти битов физического адресного пространства (32-х битах виртуального), а AMD64 - по-моему это уже 40+ битов физического адресного пространства(64-х битах виртуального), плюс расширение регистров до 64-х бит (rax и т.д.), плюс доп. регистры (r8 - r15), ну и что SSE теперь должно быть обязательно, возможно и ещё, что-то по мелочи, что так на вскидку не вспомнилось.

     
     
  • 7.174, Anonymoustus (ok), 10:37, 02/09/2019 [^] [^^] [^^^] [ответить]  
  • +/
    Не другое То же самое И в соответствующих документах это прямо написано AMD64... текст свёрнут, показать
     
     
  • 8.178, Совершенно другой аноним (?), 10:44, 02/09/2019 [^] [^^] [^^^] [ответить]  
  • +/
    У нас используется PAE, и PSE36 в самописных системах без 64-х битного режима - ... текст свёрнут, показать
     
     
  • 9.180, Anonymoustus (ok), 11:07, 02/09/2019 [^] [^^] [^^^] [ответить]  
  • +/
    Не хочу тратить своё время на бессмысленные споры Берите документацию 171 пер... текст свёрнут, показать
     
  • 9.182, Anonymoustus (ok), 11:09, 02/09/2019 [^] [^^] [^^^] [ответить]  
  • +/
    Я не про это, а про доступ к регистрам ... текст свёрнут, показать
     
     
  • 10.190, Совершенно другой аноним (?), 11:49, 02/09/2019 [^] [^^] [^^^] [ответить]  
  • +1 +/
    Прошу прощения, всё-же не понял, про что Вы У нас, в самописной системе использ... текст свёрнут, показать
     
  • 2.205, Wilem (?), 15:03, 02/09/2019 [^] [^^] [^^^] [ответить]  
  • +1 +/
    > зачем нужно "это", если давно уже есть и активно используется СИ ? Что может "это", что НЕ может СИ ?
    > ЗЫ: Жду агрессивных высказываний вида

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

     
  • 2.244, Ordu (ok), 00:42, 04/09/2019 [^] [^^] [^^^] [ответить]  
  • +/
    Что может СИ, чего не может ассемблер Что может ассемблер, чего не могут машинн... текст свёрнут, показать
     

     ....большая нить свёрнута, показать (33)

  • 1.35, Аноним (35), 12:05, 01/09/2019 [ответить] [﹢﹢﹢] [ · · · ]  
  • –4 +/
    > избавленные от таких проблем, как обращение к области памяти после её освобождения, разыменование нулевых указателей и выход за границы буфера.

    CONFIG_PAX_KERNEXEC=y

    Решает проблемы С без всяких *растов

     
     
  • 2.52, n80 (?), 12:36, 01/09/2019 [^] [^^] [^^^] [ответить]  
  • +/
    Даже те проблемы, которые таким путём как бы решаются, и то решаются не полностью, увы. Это совсем не «серебряные пули».
     

  • 1.41, бублички (?), 12:19, 01/09/2019 [ответить] [﹢﹢﹢] [ · · · ]  
  • +2 +/
    почему не C# или даже VB?
     
     
  • 2.47, JL2001 (ok), 12:32, 01/09/2019 [^] [^^] [^^^] [ответить]  
  • +/
    > почему не C# или даже VB?

    требуют ж интерпретатор байткода

    возможно если впихнуть их в llvm, то получится что-то

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

    было бы очень интересно сравнить один и тот же код скомпилированный в машкады и запущеный на виртмашине с хорошей рантаймоптимизацией
    llvm такое позволяет?

     
  • 2.75, пох. (?), 14:18, 01/09/2019 [^] [^^] [^^^] [ответить]  
  • –4 +/
    открывай сбор донейтов. Я пожертвую пару рублей (за js, конечно, кому нужен этот ваш устаревший и не имеющий модного npm поделок проклятого m$ который хочет всех пороботить?!)

     
     
  • 3.148, бублички (?), 00:29, 02/09/2019 [^] [^^] [^^^] [ответить]  
  • +/
    вижу по теме донейтов ты больной на обе головы. здесь круглый год и в каждой теме подобный комментарий от тебя, хорошо если лишь один а не 5 или 10. нет бы давно уже денег на визит к доктору насшибал, всё здесь словоблудием занимаешься
     
  • 3.167, Аноним (167), 08:50, 02/09/2019 [^] [^^] [^^^] [ответить]  
  • +/
    От слова робот?
     
  • 2.105, Аноним (99), 15:47, 01/09/2019 [^] [^^] [^^^] [ответить]  
  • +/
    > почему не C# или даже VB?

    Потому что Sign# уже был в MS Singularity.

     

  • 1.46, user90 (?), 12:30, 01/09/2019 [ответить] [﹢﹢﹢] [ · · · ]  
  • –1 +/
    > Джош считает

    Ну, теперь все! раз сам Джош так считает..

    Да пусть развлекаются. Мне как-то попадался даже компилятор для bash-скриптов, идея примерно того же уровня.

     
  • 1.60, Адекват (ok), 12:53, 01/09/2019 [ответить] [﹢﹢﹢] [ · · · ]  
  • +3 +/
    Вообщем, в недалеком будущем будет тут новость вида "по причине того, что gcc и СИ пользуются только 3% пользователей линукс, было принято решение дропнуть СИ и gcc, а в замен им предоставить rust и grr, а так же заменить устаревший glibc на новый прогрессивный gliRust, или сокращенно glist"
     
     
  • 2.170, Урри (?), 09:41, 02/09/2019 [^] [^^] [^^^] [ответить]  
  • +/
    Судя по количеству уже написанного кода, это новости _далекого_ будущего.
     
     
  • 3.212, Аноним (99), 15:46, 02/09/2019 [^] [^^] [^^^] [ответить]  
  • +/
    > Судя по количеству уже написанного кода, это новости _далекого_ будущего.

    Вопрос не в переписывании существующего кода, а в возможности его трансляции на другой язык.

     

  • 1.62, Аноним (58), 12:57, 01/09/2019 [ответить] [﹢﹢﹢] [ · · · ]  
  • +1 +/
    Раст не готов для системного программирования, но "в будущем будет как С, а C будет как ассемблер".
    Похлопаем джошу за раздувание абстракций и бесполезную работу. Когда потомки спросят кто виноват, скажу это все Джош Триплет.
     
     
  • 2.66, Anonymoustus (ok), 13:18, 01/09/2019 [^] [^^] [^^^] [ответить]  
  • +1 +/
    Зато хоть стало понятно, почему Штеуд разучился делать процессоры.

    Давай, Интел, жги сам себя!

     

  • 1.67, Egan (?), 13:23, 01/09/2019 [ответить] [﹢﹢﹢] [ · · · ]  
  • +5 +/
    По моему опыту си никаким боком не может заменить ассемблер в ядре. На ассемблере пишут то, что вообще непонятно на чем еще можно писать.
     
  • 1.77, Аноним (77), 14:21, 01/09/2019 [ответить] [﹢﹢﹢] [ · · · ]  
  • +1 +/
    Это пропихивание Раста, или да? Кому-то неймётся и он, для раздувания ЧСВ, хочет потеснить С?
     
  • 1.80, Аноним (-), 14:29, 01/09/2019 [ответить] [﹢﹢﹢] [ · · · ]  
  • +5 +/
    почему люди так любят раст? У него же синтаксис страшный как моя жизнь
     
     
  • 2.107, Аноним (107), 15:53, 01/09/2019 [^] [^^] [^^^] [ответить]  
  • +3 +/
    > синтаксис страшный как моя жизнь

    +10 к элитарности

     
     
  • 3.116, Илья (??), 16:29, 01/09/2019 [^] [^^] [^^^] [ответить]  
  • +1 +/
    > синтаксис страшный как моя жизнь

    да, страшный, тут ничего не скажешь, не c# ни разу.

     
  • 2.122, Аноним (11), 16:53, 01/09/2019 [^] [^^] [^^^] [ответить]  
  • +1 +/
    Так кажется, когда видишь некоторые примеры и не до конца понимаешь, что они делают.
    Всё встает на свои места, если хоть чуть-чуть разобраться.
    Так-то в C || C++ можно и похлеще языковые конструкции встретить.
     
     
  • 3.137, qwerty123 (??), 20:52, 01/09/2019 [^] [^^] [^^^] [ответить]  
  • +2 +/
    >Всё встает на свои места, если хоть чуть-чуть разобраться.

    Ага.

    - "Мы не будет использовать указатели! У нас автомагия!"
    прошло 5 минут...
    - "Если надо использовать указатели, то вот вам как в Си"

    А теперь найдите системный код без указателей.

     
     
  • 4.230, Анонимкаааа (?), 08:27, 03/09/2019 [^] [^^] [^^^] [ответить]  
  • +1 +/
    Очередной чукча-писатель. В расте есть указатели, но не сырые, а умные, с владением явным всегда. Хочешь указатели сырые, именно сишные, где никто ничего не гарантирует, хочешь эксплуатировать свои любимые double-free, утечечки, по которым так скучал - пишешь 'unsafe' и довольствуешься этим говном. В этом плане, в расте нет указателей настолько же, насколько их нет в плюсах.

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

     
  • 2.161, Проходил мимо (?), 07:08, 02/09/2019 [^] [^^] [^^^] [ответить]  
  • +2 +/
    Нет там ничего особо страшного.
     
  • 2.206, Wilem (?), 15:09, 02/09/2019 [^] [^^] [^^^] [ответить]  
  • +/
    > почему люди так любят раст? У него же синтаксис страшный как моя жизнь

    Приведи пару примеров.

     

  • 1.123, Аноним (11), 16:59, 01/09/2019 [ответить] [﹢﹢﹢] [ · · · ]  
  • –5 +/
    Забавно, что есть искренние защитники языка, в котором нельзя банально стринги сложить без прямого использования функции 💩
    Да, толковой альтернативы C не было в 90-ые. Но, люди, на дворе почти 2020-ые.
     
     
  • 2.125, Адекват (ok), 17:22, 01/09/2019 [^] [^^] [^^^] [ответить]  
  • +4 +/
    Я си изучаю месяц и уже пришел к выводу, что это не баг а фича В СИ - все есть ... текст свёрнут, показать
     
     
  • 3.126, Аноним (126), 18:00, 01/09/2019 [^] [^^] [^^^] [ответить]  
  • +/
    >Я си изучаю месяц

    щас иксперд нам всё расскажет... и как стринги он не носит

     
  • 3.127, Аноним (11), 18:34, 01/09/2019 [^] [^^] [^^^] [ответить]  
  • +/
    В C++ строки ВНЕЗАПНО тоже всего лишь массив чаров, но там средства языка позволяют адекватно реализовать std::string, чего нет и никогда не будет в C:
    std::string str1 = "one", str2 = "two";
    std::string str3 = str1 + str2; // "onetwo"
    Добро пожаловать в мир нормальных языков!

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

    > Если чего-то нет - можно написать свою функцию.

    Круто! Давай писать всё с нуля, к черту многолетние либы. Да к черту и функции, которые в других языках есть в стандартной либе, ведь можно свою написать! :)

    (надеюсь это был троллинг, тогда лайкос за него)

     
     
  • 4.128, Dmitry (??), 19:08, 01/09/2019 [^] [^^] [^^^] [ответить]  
  • +2 +/
    Мне больше нравятся паскалевские строки, когда нулевой элемент строки и есть сама длина строки.
    С ними гораздо проще выполнять любые действия. Не нужно перебирать по одному байту, в поиске "\0"
    Никаких выходов за пределы строки и утечек памяти.
    Единственное неудобство - ограничение такой строки в 255 символов.
    Но с другой стороны. Загляните в код любого драйвера. Где вы там видели строки больше 100-200 символов ?
     
     
  • 5.129, Аноним (126), 19:12, 01/09/2019 [^] [^^] [^^^] [ответить]  
  • +/
    в плюсах, как бы, объект string также содержит длину строки и ничего не перебирается, и ноль в конце есть для совместимости с системными функциями.
     
  • 5.241, Anonimous (?), 14:38, 03/09/2019 [^] [^^] [^^^] [ответить]  
  • +/
    В современном Паскале особых ограничений нет (до High(SizeInt)).
     
  • 4.166, pripolz (?), 08:50, 02/09/2019 [^] [^^] [^^^] [ответить]  
  • +1 +/
    По поводу сложения std::string - это не рекомендованных практика, т.к. несет в себе потерю производительности во столько раз, сколько раз там "+".

    "А + Б + Ц" несет в себе 3 разных сложения с выделением памяти и т.д.

     
  • 4.172, Совершенно другой аноним (?), 10:12, 02/09/2019 [^] [^^] [^^^] [ответить]  
  • +/
    Вы не правы. В C++ строки это отдельный тип (реализованный через объект, который внутри может быть хранить строки по форме, похожей на паскалевские строки с хранением длины строки отдельно и строки - отдельно). В C, на самом деле, отдельного строкового типа - нет, есть массив, и есть частный, договорной случай ASCIIZ строк - типа, а давайте, то, что ограничивается 0 и будем считать строкой. Со всеми вытекающими последствиями. В C Вам никто не мешает реализовать свой вариант строк, удобный именно Вам, ну или использовать какую-нибудь библиотеку, в которой это уже реализовано до Вас и для Вас.
     
  • 4.181, Аноним (99), 11:09, 02/09/2019 [^] [^^] [^^^] [ответить]  
  • +1 +/
    > В C++ строки ВНЕЗАПНО тоже всего лишь массив чаров, но там средства
    > языка позволяют адекватно реализовать std::string, чего нет и никогда не будет
    > в C:
    > std::string str1 = "one", str2 = "two";
    > std::string str3 = str1 + str2; // "onetwo"
    > Добро пожаловать в мир нормальных языков!

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

     
  • 4.184, Ordu (ok), 11:23, 02/09/2019 [^] [^^] [^^^] [ответить]  
  • +/
    > std::string str1 = "one", str2 = "two";
    > std::string str3 = str1 + str2; // "onetwo"
    > Добро пожаловать в мир нормальных языков!

    Но так же никто не делает на практике. Выделять память под третью строку, чтобы просуммировать две предыдущие? Как правило есть предвыделенный буфер, который перевыделяется. Часто этим предвыделенным буфером является первая из суммируемых строк. Если нет, то это часто форматный вывод в динамически выделяемый буфер. Что в C++, что в rust'е.

     
  • 2.150, vitalif (ok), 01:59, 02/09/2019 [^] [^^] [^^^] [ответить]  
  • +2 +/
    Блин ну сложение строк это конечно просто самая нужная функция в ядре - куда уж без неё
     

  • 1.132, Корец (?), 20:08, 01/09/2019 [ответить] [﹢﹢﹢] [ · · · ]  
  • +1 +/
    А чё не JS-то?
     
     
  • 2.142, JL2001 (ok), 22:43, 01/09/2019 [^] [^^] [^^^] [ответить]  
  • +3 +/
    > А чё не JS-то?

    потомучта динамическая типизация должна сдохнуть в муках

     
     
  • 3.250, Аноним (250), 10:06, 06/09/2019 [^] [^^] [^^^] [ответить]  
  • +/
    Только скорее ты сдохнешь быстрее :)
     

  • 1.139, Ordu (ok), 21:13, 01/09/2019 Скрыто модератором [﹢﹢﹢] [ · · · ]
  • –1 +/
     
     
  • 2.154, pripolz (?), 04:15, 02/09/2019 Скрыто модератором
  • –1 +/
     

  • 1.149, Аноним (149), 01:52, 02/09/2019 [ответить] [﹢﹢﹢] [ · · · ]  
  • +13 +/
    Объясните, кто-нибудь, на пальцах, почему драйвера, и вообще ядро, нельзя писать на современных плюсах С++?
    Из-за "тяжелого" рантайма? Или там есть какие-то фундаменталные ограничения? Чесслово не могу понять.
     
     
  • 2.151, НяшМяш (ok), 02:40, 02/09/2019 [^] [^^] [^^^] [ответить]  
  • +3 +/
    В MacOS X, например, IOKit - это C++ фреймворк для системных драйверов. Но для того чтобы рантайм не был тяжёлым, из него выпилили исключения, множественное наследование, шаблоны и RTTI.
     
     
  • 3.177, Аноним (240), 10:43, 02/09/2019 [^] [^^] [^^^] [ответить]  
  • +2 +/
    А вот шаблоны зря. Они же compile time и потому в runtime ничего не весят.
     
     
  • 4.185, Аноним (99), 11:28, 02/09/2019 [^] [^^] [^^^] [ответить]  
  • +/
    > А вот шаблоны зря. Они же compile time и потому в runtime
    > ничего не весят.

    Для NT реализована стандартная библиотека C++ https://github.com/icestudent/ontl
    где всё вышеперечисленное сохранено (с учётом естественных ограничений на использование исключений на высоких IRQL).

     
     
  • 5.236, Аноним (240), 12:34, 03/09/2019 [^] [^^] [^^^] [ответить]  
  • +/
    Судя по нику разработчика, дальше курсовика не продвинется.
     
     
  • 6.239, Аноним (99), 13:01, 03/09/2019 [^] [^^] [^^^] [ответить]  
  • +/
    > Судя по нику разработчика, дальше курсовика не продвинется.

    Судя по истории в 10 лет коммитов и порядка 50 человеко-лет по некоторым метрикам, тема курсовика того Студента "ненавязчивый троллинг ламеров".

     
  • 3.220, 123 (??), 21:05, 02/09/2019 [^] [^^] [^^^] [ответить]  
  • +1 +/
    Ну т.е. выпилили всё что делает его С++-ом )))
     
  • 2.187, Аноним (99), 11:41, 02/09/2019 [^] [^^] [^^^] [ответить]  
  • +/
    > Объясните, кто-нибудь, на пальцах, почему драйвера, и вообще ядро, нельзя писать на
    > современных плюсах С++?

    На С++ возможно написать работающую программу, не владея на должном уровне языком и/или не понимая принципы работы базовых вещей (таких как аппаратный стек). Для ядра такое неприемлемо. Язык С отсеивает опасных и потому нежелательных дилетантов.

    > Из-за "тяжелого" рантайма? Или там есть какие-то фундаменталные ограничения?

    Рантайм может быть существенно сокращён в объёме и не является обязательным.

     
     
  • 3.191, Аноним (149), 11:49, 02/09/2019 [^] [^^] [^^^] [ответить]  
  • +5 +/
    > На С++ возможно написать работающую программу, не владея на должном уровне языком и/или не понимая принципы работы базовых вещей (таких как аппаратный стек). Для ядра такое неприемлемо.

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

     
     
  • 4.196, Аноним (99), 12:39, 02/09/2019 [^] [^^] [^^^] [ответить]  
  • +/
    Возможно, но уровни эти существенно разные. Насмотрелся на PHP-разработчиков, лабающих на плюсах, но впадающих в ступор при виде С.
     
     
  • 5.218, Anonymoustus (ok), 18:17, 02/09/2019 [^] [^^] [^^^] [ответить]  
  • –1 +/
    > Возможно, но уровни эти существенно разные. Насмотрелся на PHP-разработчиков, лабающих
    > на плюсах, но впадающих в ступор при виде С.

    Как же они на плюсах работают? А пример какой-то их работы есть где посмотреть?

     
     
  • 6.232, Аноним (99), 09:13, 03/09/2019 [^] [^^] [^^^] [ответить]  
  • +/
    >> Возможно, но уровни эти существенно разные. Насмотрелся на PHP-разработчиков, лабающих
    >> на плюсах, но впадающих в ступор при виде С.
    > Как же они на плюсах работают?

    На плюсах, в отличии от С, можно поставить + между двумя строками, вот и работают, передавая на каждый чих vector<string> по значению. Работает же, а шо тут такого? (с)

    > А пример какой-то их работы есть
    > где посмотреть?

    Специально не искал, видел такое в проприетари, подрабатывая "реаниматором".

     
  • 3.226, Аноним (223), 23:28, 02/09/2019 [^] [^^] [^^^] [ответить]  
  • +2 +/
    > На С++ возможно написать работающую программу, не владея на должном уровне языком и/или не понимая принципы работы базовых вещей (таких как аппаратный стек).

    Не так. На С++ невозможно написать работающую программу, владея на должном уровне языком и понимая принципы работы базовых вещей. Потому что овладеть всем этим и понять его для человека физически невозможно.
    Да, Rust стремится раздуться в такого же монстра, но пока отстаёт.

     
     
  • 4.231, Аноним (99), 08:30, 03/09/2019 [^] [^^] [^^^] [ответить]  
  • +/
    >> На С++ возможно написать работающую программу, не владея на должном уровне языком и/или не понимая принципы работы базовых вещей (таких как аппаратный стек).
    > Не так. На С++ невозможно написать работающую программу, владея на должном уровне
    > языком и понимая принципы работы базовых вещей. Потому что овладеть всем
    > этим и понять его для человека физически невозможно.

    Оба тезиса не противоречат друг другу. Таков эффект Даннинга - Крюгера.

    > Да, Rust стремится раздуться в такого же монстра, но пока отстаёт.

     
  • 3.237, Аноним (240), 12:41, 03/09/2019 [^] [^^] [^^^] [ответить]  
  • +/
    >не владея на должном уровне языком и/или не понимая принципы работы базовых вещей (таких как аппаратный стек). Для ядра такое неприемлемо. Язык С отсеивает опасных и потому нежелательных дилетантов.

    Да ладно вам. Как это C вам отсеет HelloWorld-прогеров или запретит им на Сях писать? Ну отсейте производителей железок тогда, которые вам хоть какие-то кривые драйвера на Сях, заметьте, предоставили.

     
  • 2.207, Wilem (?), 15:12, 02/09/2019 [^] [^^] [^^^] [ответить]  
  • +/
    Писать можно что угодно на чём угодно. Если вопрос в "что лучше", а то лучше то, что лучше а не то, что хуже.  Извините.  Список того, чем раст лучше ц++ есть и не один.  Несколько лет назад была конфа где разработчику фейсбука рассказывал о самых жёстких багах в их коде на ц++, так вот каждый баг из этого списка просто бы не существовал на расте, т.к. компилятор бы не позволил такое сделать. https://www.reddit.com/r/rust/comments/cq9rco/cppcon_2017_curiously_recurring_
     
     
  • 3.210, Аноним (99), 15:35, 02/09/2019 [^] [^^] [^^^] [ответить]  
  • +/
    > Писать можно что угодно на чём угодно. Если вопрос в "что лучше",

    Вопрос вообще не в лучше/безопаснее и проч.

    Группа людей с консервативными взглядами годами совместно работает над ядром. Эта группа решает вопросы на каком языке разрабатывать ядро и в каком месте должна стоять запятая в принимаемых патчах. Про С++ говорят примерно то, что я мягко резюмировал в #187.

    Тот факт, что Грег заявил "как здорово, давайте посмотрим, что вы нам предложите" совсем не означает, что предложеное не завалят по формальным поводам на ревью.

     
     
  • 4.211, Аноним (99), 15:39, 02/09/2019 [^] [^^] [^^^] [ответить]  
  • +/
    > предложеное

    То есть если вот такое я хочу отправить как патч, мне укажут на ошибку и не примут. Хотя остальное может иметь гарантии в 146% безопасности, подкреплённые 7-ю печатями.

     
  • 3.227, Аноним (223), 23:30, 02/09/2019 [^] [^^] [^^^] [ответить]  
  • +/
    > Если вопрос в "что лучше", а то лучше то, что лучше а не то, что хуже.

    Ну какой там ещё C++ или rust, ты русским-то языком мне парсер сломал.

     
     
  • 4.234, Wilem (?), 10:20, 03/09/2019 [^] [^^] [^^^] [ответить]  
  • +/
    Извините, не могу как аноним править, поторопился.
     
  • 3.238, Аноним (240), 12:48, 03/09/2019 [^] [^^] [^^^] [ответить]  
  • +/
    >так вот каждый баг из этого списка просто бы не существовал на расте, т.к. компилятор бы не позволил такое сделать

    А, собственно, что мешает компилятору C++ тоже стать значительно более строгим, даже особо не меняя стандарты языка? Ввести опцию-режим суперстрогости -fsuperstrict

     

  • 1.155, Аноним (155), 04:21, 02/09/2019 [ответить] [﹢﹢﹢] [ · · · ]  
  • –1 +/
    Тем временем: https://paste.pics/b49d5b5b7eebf3dd595bff89333d4c90
     
  • 1.176, Аноним (176), 10:39, 02/09/2019 [ответить] [﹢﹢﹢] [ · · · ]  
  • +1 +/
    Ну наконец то у Intel пропадут все дырки в процессорах и драйверах. Останутся только электроны, раст и терможвачка.
     
  • 1.186, Аноним (186), 11:28, 02/09/2019 [ответить] [﹢﹢﹢] [ · · · ]  
  • +1 +/
    За теми, кто ставит компилятор не из пакетов, а скачивая и исполняя баш-скрипты,... текст свёрнут, показать
     
     
  • 2.195, Аноним (195), 12:22, 02/09/2019 [^] [^^] [^^^] [ответить]  
  • +/
    Не волнуйся, если хотя бы один такой бекдор вскроется, то это скомпрометирует всю систему целиком.
     
     
  • 3.213, Аноним (186), 15:57, 02/09/2019 [^] [^^] [^^^] [ответить]  
  • +/
    Ну вскроется, и что дальше? Перекомпилировать весь софт на чистых доверенных системах с новыми бэкдорами, на этот раз завёрнутыми в SGX? Никто это делать не будет.
     
  • 2.208, Wilem (?), 15:16, 02/09/2019 [^] [^^] [^^^] [ответить]  
  • +/
    > Как такое может найти популярность в среде программистов

    Для этого можно почитать мнение и аргументацию этих самых программистов. Ничего сложного в этом нет, всё в гугле. Без обид, но твои опасения про пакеты в сравнении с тем, что раст даёт разработчикам - это несоизмеримо.

     

  • 1.202, Аноним (202), 14:55, 02/09/2019 [ответить] [﹢﹢﹢] [ · · · ]  
  • +1 +/
    Интересные замечания по теме
    https://lwn.net/Articles/797714/
     
  • 1.209, Аноним (-), 15:20, 02/09/2019 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    Драйвер nvidia будет? :)
     
     
  • 2.233, Аноним (99), 09:14, 03/09/2019 [^] [^^] [^^^] [ответить]  
  • +/
    > Драйвер nvidia будет? :)

    Так то не шутите, желанья сбываются. :)

     
     
  • 3.243, аноним3 (?), 18:01, 03/09/2019 [^] [^^] [^^^] [ответить]  
  • +/
    раст не создавался как системный язык. не надо народ пугать. когда он дорастет до такого уровня, то он раздуется как с++ и никто уже ничего полностью в нем понять не сможет))) и появится новы сраст какой нибудь. не парьтесь
     

  • 1.251, Игорь Николаев (?), 05:28, 07/09/2019 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    Всё хорошо.
    Вот только ethernet в rpi3 виснет. И всю усбню вешает.
     

     Добавить комментарий
    Имя:
    E-Mail:
    Текст:



    Спонсоры:
    Слёрм
    Inferno Solutions
    Hosting by Ihor
    Хостинг:

    Закладки на сайте
    Проследить за страницей
    Created 1996-2019 by Maxim Chirkov
    Добавить, Поддержать, Вебмастеру