LINUX.ORG.RU

Google профинансирует работу над Rust for Linux

 , ,


0

4

Компания оплатит год работы Мигеля Охеда (Miguel Ojeda) над его проектом Rust for Linux. Работа будет вестись в рамках проекта Prossimo под эгидой организации ISRG (Internet Security Research Group) — учредителя проекта Let's Encrypt.

По данным Microsoft около 70% всех уязвимостей, описанных в CVE, вызваны небезопасной работой с памятью. Написание на Rust таких компонентов, как драйверы устройств, может снизить риск появления уязвимостей.

>>> Подробности



Проверено: xaizek ()
Последнее исправление: xaizek (всего исправлений: 4)

Ответ на: комментарий от skyman

Угу, будем всю эту срань

Хороший код на Rust обязан включать в себя проверки санитайзерами и miri. Но дебилы продолжают упорствовать и позорить авторов Rust привнося в свои хелловорды критические уязвимости.

Продолжай говорить как дебил дальше: «Если скомпилировать, то работает. Бороу чекер от всего защит».

fsb4000 ★★★★★
()
Последнее исправление: fsb4000 (всего исправлений: 1)
Ответ на: комментарий от Harald

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

Поржал. Может в шараге это и так, но в кровавом энтерпрайзе девелопер и QA инженер это сильно разные позиции с разными задачами и инструментами. И нормальных QA на рынке отрывают с ногами.

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

skyman ★★★
()
Ответ на: комментарий от fsb4000

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

anonymous
()
Ответ на: комментарий от fsb4000

Хороший код на Rust обязан включать в себя проверки санитайзерами и miri. Но дебилы продолжают упорствовать и позорить авторов Rust привнося в свои хелловорды критические уязвимости.

Продолжай говорить как дебил дальше: «Если скомпилировать, то работает. Бороу чекер от всего защит».

Я не говорю, что это бесполезно или ненужно. Но если часть этих задач перенести в компилятор, и проверять строже с самого начала, то лучше будет всем.

skyman ★★★
()
Ответ на: комментарий от skyman

Как ты себе это представляешь? miri - это такой недо-valgrind, что ты им в компиляторе делать собрался?

anonymous-angler ★☆
()
Ответ на: комментарий от anonymous

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

Проверяет не нарушил ли ты ограничения возможностей.

shpinog ★★★
()
Ответ на: комментарий от anonymous

У него нет права чинить методичку, он всего лишь транслятор. что в него зальют, то из него и льется

anonymous
()
Ответ на: комментарий от shpinog

Рекомендую прекратить ему отвечать. Он ведь сумасшедший, буквально. Просто понаблюдай его фазы в других тредах. Иногда регистрируется и пытается делать вид, что нормальный, но затем под влиянием стресса (например при отсутствии аргументов) его в какой-то момент перекрывает и он начинает словесно просираться (%

anonymous-angler ★☆
()
Последнее исправление: anonymous-angler (всего исправлений: 1)
Ответ на: комментарий от anonymous-angler

Клоун, ты там опять поехал? Ты был неоднократно опущен мною, нёс херню, звал мамку. После мамка пришла и затёрла твой позор. И вот когда всё затёрто, отребье сообщает об отсутствии аргументов.

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

anonymous
()
Ответ на: комментарий от anonymous-angler

Вообще чувак здесь уже лет 10 кресты пропагандирует. В 2011 с жабкой боролся, изрыгая простыни текста. Теперь с ржавым борется, изрыгая простыни текста. Через ещё лет 10 - будет ещё с чем-то бороться. НИкто в здравом уме не будет подобной хренью заниматься. И бедняга убеждён, что сектант не он, а адепты раста.

anonymous-angler ★☆
()
Ответ на: комментарий от anonymous-angler

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

anonymous
()
Ответ на: комментарий от fernandos

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

Си может и популярен, и у него один из прекраснейших синтаксисов

И при этом поколение смузихлёбов тащится от вырвиглазного синтаксиса раста. Двуликие они какие-то.

anonymous
()
Ответ на: комментарий от anonymous

Линукс конкурент фуксии, с помощью растомусора гугл уничтожит ядро - профит

Так Фуксия вообще на C++ по части ядра и на Rust по части user-space.

EXL ★★★★★
()
Ответ на: комментарий от anonymous-angler

И с годами ему лучше не становится, всё меньше аргументов и больше агрессии.

Никто не вечен, постоянный стресс на фоне хронических неврозов из-за c++

Вообще чувак здесь уже лет 10 кресты пропагандирует. В 2011 с жабкой боролся, изрыгая простыни текста

Собственно я так и думал, синдром мессии унитаза, ему так нравится чистить свой унитаз (с++), что это стало смыслом его жизни и миссией.

shpinog ★★★
()

Rust проклят?

Почему везде где упоминается раст всегда воняет без аргументированным хейтом?

anonymous
()
Ответ на: комментарий от shpinog

Именно так. Я ему серьёзно предлагал обратиться к врачу. И тогда, и сейчас. Но чувак видимо недооценивает масштаб своей паталогии и считает что я шутки шучу (%

anonymous-angler ★☆
()
Ответ на: комментарий от anonymous

Аргументы были, не обманывай. но растоманькам не нужны аргументы, им нужен только бисер

anonymous
()
Ответ на: комментарий от anonymous

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

fernandos ★★★
()

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

«Если в вашей программе не обнаружено ошибок - позовите системного программиста. Он исправит ошибки в компиляторе.» (с)

Старая истина. И, к сожалению, до сих пор верная. Не важен язык, на котором программа написана. Важно - КЕМ и КАК она написана.

DrRulez ★★★
()

Google профинансирует работу над Rust for Linux

Могли и Царя нанять, что-ли.
Он бы их всех быстро приструнил.

Сегодня в треде - боевая ничья.

anonymous
()
Ответ на: комментарий от shpinog

Что-то мне говорит что проблем будет примерно столько же. Разница только в ‘дайте дорогу новому поколению’. Думаю что приличных программистов на расте уже больше чем программистов на С. Да и выучить Раст и начать писать на нем без последствий всяко проще чем с С. Без альтернативы языку есть ненулевой шанс что через 10 лет линукс и пилить некому будет.

mrdeath ★★★★★
()
Ответ на: комментарий от Harald

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

их и пилят, и используют, но:

  1. общая идея коммерцоидов - минимальные вложения, минимальные телодвижения и быстрая отдача. Мало кто все эти инструменты использует на регулярной автоматизированной основе, тот же PVS Studio не для нищебродов. К тому же (сюрприз!) все найденные баги надо еще и исправлять, а это противоречит установке «побыстрее слепим, тестировать будем на пользователях после впаривания им нашего продукта»; И в общем случае ты коммерцоидов не сможешь убедить, что все эти тулзы нужны. «О чем этот ботан вообще говорит?!»

  2. все эти тулзы не дают никаких гарантий, потому что это грубо говоря набор эвристик и ad-hoc правил поверх кривого ЯП, и каждый производитель просто соревнуется с себе подобными, добавляя больше эвристик и ad-hoc правил. Это тараканьи бега, и они не дают никаких гарантий, что осталось какое-то место, не покрытое ad-hoc правилом, и реальная система бабахнет именно в этом месте.

seiken ★★★★★
()
Ответ на: комментарий от mrdeath

Что-то мне говорит что проблем будет примерно столько же.

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

Разница только в ‘дайте дорогу новому поколению’. Думаю что приличных программистов на расте уже больше чем программистов на С. Да и выучить Раст и начать писать на нем без последствий всяко проще чем с С.

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

Без альтернативы языку есть ненулевой шанс что через 10 лет линукс и пилить некому будет.

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

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

shpinog ★★★
()
Ответ на: комментарий от fsb4000

Угу, несколько лет назад одна девушка рассказывала на rust conf 2018 про entity в game dev. И что же она говорила? Восхваляла borrow checker, говорила как круто что компилятор заставляет писать правильно, а затем рассказала так завуалированно про то как реализовать vec shared_ptr entities с индексом, тлдр это простой memory allocator который скрыт от проверок borrow checker потому что он не понимает эту схему что она реализовала так хитро. Иными словами неявно отключила этот чеккер. Да зашибись, отличный язык, и стнтаксис от бога.

bhfq ★★★★★
()
Ответ на: комментарий от mrdeath

Думаю что приличных программистов на расте уже больше чем программистов на С.

где же эти толпы? где их всех прячут?

Да и выучить Раст и начать писать на нем без последствий всяко проще чем с С

не понятно, с чего бы это? Для C написано столько литературы, столько бумаг в журналы заслано, столько тем в интернет форумах обсуждено, столько курсов в универах прочитано, столько опыта получено, что аналогичная деятельность вокруг Rust вряд ли 10% покроет, в сравнении с наследием C.

Порог вхождения в Rust выше, чем в C, хотя бы потому что в Rust на обучающегося сразу вываливается машинерия заимствования, ссылок, референс каунтеров и проч., без понятия для начинаюшего, зачем это все нужно. В C все просто, как валенок: есть передача по значению, а есть по указателю. Есть автоматические переменные, а есть с ручным выделением/освобождением.

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

seiken ★★★★★
()

Redox уже есть. Пусть туда финансируют, если rust им нравится.

anonymous
()
Ответ на: комментарий от shpinog

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

А ты думаешь, что Rust тебе всё это прям из каробки обеспечит и думать не надо будет?

aist1 ★★★
()
Ответ на: комментарий от Harald

Ага, ещё и архитектор и salesman, полы мыть, что ещё?

ZogG
()
Ответ на: комментарий от aist1

А ты думаешь, что Rust тебе всё это прям из каробки обеспечит и думать не надо будет?

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

shpinog ★★★
()
Ответ на: комментарий от Harald

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

Так и будет, а где покрупнее так и есть. Мейнтейнер по сути зачастую за тебя компилирует и процессом сборки занимается, но код приложения может и не писать.

А то специализации недостаточно.

Что тебя удивляет? Капиталистический рынок так устроен, здесь дело не в IT.

Разделение труда никто не отменял, улучшает стабильность производственных сил, и производство кода не исключение. Собственно от ремесленничества ( фулл-стек ), оно и переходит к специализации работников.

shpinog ★★★
()
Ответ на: комментарий от shpinog

На наших глазах происходит борьба двух сект, старые|новые свидетели идеального кода на си,

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

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

torvn77 ★★★★★
()
Последнее исправление: torvn77 (всего исправлений: 2)
Ответ на: комментарий от torvn77

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

Никто не мешал gcc собираться фрибздю много лет, от этого она gpl не становилась.

shpinog ★★★
()
Ответ на: комментарий от torvn77

экономической свободы для всех(копилефт)

Это не экономический вопрос, а правовой. Лицензирование к экономике отношение имеет околонулевое.

свободы обирать общество ради своего обогащения(проприетарщина и пермессивные лицензии)

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

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

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

За малым исключением, все эти «блага копилефта», в общей картине сводятся к перекладыванию денег из одного сектора в другой, никто за бесплатно не работает.

shpinog ★★★
()
Ответ на: комментарий от shpinog

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

torvn77 ★★★★★
()
Последнее исправление: torvn77 (всего исправлений: 1)
Ответ на: комментарий от shpinog

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

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

Там один анонимус выше сказал уже, что вся эта безопасность, которую дает Rust, обеспечивается системой ограничений на операционную семантику языка, которая делает невозможным написание некоторых программ (без unsafe). А остальные программы будет писать сильно сложнее. И может так оказаться, что практическое программирвание на Rust сильно дороже (по итогам) такового на языках со сборкой мусора.

Я не про то, что Rust — это плохо. Я про то, что чудес не будет.

aist1 ★★★
()
Ответ на: комментарий от shpinog

Благие копилефт разработки даром

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

torvn77 ★★★★★
()
Ответ на: комментарий от torvn77

Как я понял Раст позволяет делать расширения языка, которые могут быть проприетарными, при этом как показывает опыт использование таких расширений в ПО делает его по сути проприетарным

Никто не мешает тебе и для Си такой компилятор делать. Тот же msvs.

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

А так тебе и сейчас никто не мешает писать патчи к ядру, которые опираются на какой нибудь проприетарный компилятор Си, опубликуй только эти исходники, а то что они с ванильным gcc не соберутся и в ядро их не примут - вопрос десятый.

shpinog ★★★
()
Ответ на: комментарий от torvn77

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

Тогда в чём экономическая свобода и её ущемление?

shpinog ★★★
()
Ответ на: комментарий от aist1

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

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

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

Кто спорит? В пользовательских приложениях всё к этому и придёт. Речь же о ядре, туда сборщик мусора засунешь ?

Там один анонимус выше сказал уже, что вся эта безопасность, которую дает Rust, обеспечивается системой ограничений на операционную семантику языка, которая делает невозможным написание некоторых программ (без unsafe). А остальные программы будет писать сильно сложнее.

Всё это следствие не правильного понимания unsafe. 1) unsafe отключает не все проверки, а часть. 2) Его будет мало, малая часть. Условный тип ошибок ты сразу будешь понимать где искать. 3) Чудес не бывает.

А остальные программы будет писать сильно сложнее.

Скорее окажется, что это просто вопрос привычки. Вполне себе пишут, многим нравится, было бы всё как ты говоришь, никто бы садо мазо не занимался и лепил на си.

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

Речь про ядро. В ядре сборщика мусора не будет. Всё остальное и так в вебне с сборщиком мусора, или скоро окажется там.

shpinog ★★★
()
Ответ на: комментарий от shpinog

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

Всё это следствие не правильного понимания unsafe. 1) unsafe отключает не все проверки, а часть. 2) Его будет мало, малая часть. Условный тип ошибок ты сразу будешь понимать где искать. 3) Чудес не бывает.

Дело не в суровости, а в самом операционной семантике. Семантика владения (только одна сылка на мутабельный объект) не позволяет написать некоторые программы, т.е., строго говоря, безопасный Rust не полон по Тьюрингу. И тут возникает следующий вопрос. Вот есть множество корректных программ на том же С (для примера), и есть можество корректных программ на Rust. Так же есть инъекция из последнего в первое. Вопрос в том, на сколько множетсво корректных программ на Rust меньше множества корректных программ на С, и что это значит с практической точки зрения.

Со своего опыта я скажу, что моя попытка перевести мой проект (сложные структуры данных) в Rust уперлась в то, что слишком много сложного кода попадало в unsafe. Смысл в Rust быстро теряется, когда такого кода много (O(N)). Так что получалось именно то самое — чудес не бывает.

Скорее окажется, что это просто вопрос привычки. Вполне себе пишут, многим нравится, было бы всё как ты говоришь, никто бы садо мазо не занимался и лепил на си.

А потом уходят продолжать на GoLang.

Речь про ядро. В ядре сборщика мусора не будет.

В том-то и дело, что как раз для ядра сборщик мусора имеет смысл. По крайней мере, как опция. ARC с детектором циклов — это тоже сборщик мусора. Кроме того, многие конкуррентные структуры данных как раз требут сборщика мусора (но уже не ARC).

aist1 ★★★
()
Ответ на: комментарий от aist1

Семантика владения (только одна сылка на мутабельный объект) не позволяет написать некоторые программы, т.е., строго говоря, безопасный Rust не полон по Тьюрингу.

Это не так, там просто подход другой. Я не пишу на раст, и не спец, но тебе бы rustbook почитать хотя бы.

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

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

Со своего опыта я скажу, что моя попытка перевести мой проект (сложные структуры данных) в Rust уперлась в то, что слишком много сложного кода попадало в unsafe. Смысл в Rust быстро теряется, когда такого кода много (O(N)). Так что получалось именно то самое — чудес не бывает.

Сложный код, как правило пишется один раз. Вокруг такого когда делаются библиотеки. В любом сложном коде 90% сложности в логике и алгоритме, а не в синтаксисе вокруг всего этого. Учитывая, что в целом сахара в rust из коробки намного больше, то ты скорее упёрся в low skill, а не в возможности языка.

А потом уходят продолжать на GoLang.

Там gc. И гугель

В том-то и дело, что как раз для ядра сборщик мусора имеет смысл. По крайней мере, как опция. ARC с детектором циклов — это тоже сборщик мусора. Кроме того, многие конкуррентные структуры данных как раз требут сборщика мусора (но уже не ARC).

man почему с++ не в ядре. В целом, можно и с сборщиком мусора извратится, но я на таких низких уровнях не шарю, думаю бородачи и Линус у которых 40+ лет опыта, лучше знают что и почему.

shpinog ★★★
()
Ответ на: комментарий от aist1

т.е., строго говоря, безопасный Rust не полон по Тьюрингу

Вроде для доказательства полноты по Тьюригу достаточно написать игру «Жизнь» или даже упрощенную версию(одномерную версию) подобной игры «Правило 110».

https://en.wikipedia.org/wiki/Rule_110

Я писал игру жизнь на многих языках, последний раз на Zig :). И видел как писали на Rust: https://youtu.be/Y5-ZgxfQvpc

Так что safe Rust определенно полон по Тьюрингу.

fsb4000 ★★★★★
()
Ответ на: комментарий от fsb4000

Так что safe Rust определенно полон по Тьюрингу.

Я поправлюсь.

Согласен, если говорить строго, то он по Тьюрингу будет полон, так как на нем можно написать интерпретатор полного по Тьюрингу языка, в котором не будет чекера. Мой пример был в том, что там в безопасном подмножестве не напишешь двухсвязный список (в частности) или обобщенный граф (вообще). Их, разумеется, можно написать просто в байтовом массиве, но там не будет зашитой в язык семантики владения. Пример разруливания владения в двухсвязном списке с помощью unsafe тривилен (легко верифицируем человеком), и создают впечатление, будто и все остальные случаи использования unsafe тоже будут такими же тривиальными. У меня не взлетело.

@shpinog – ты просил примера, вот он.

aist1 ★★★
()

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

x86-
()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.