Линус Торвальдс подключился к обсуждению возможности добавления в ядро Linux средств для разработки на языке Rust. Джош Триплет (Josh Triplett) из компании Intel, работаюдий над проектом по доведению языка Rust до паритета с языком Си в области системного программирования, предложил на начальном этапе добавить в Kconfig опцию для поддержки Rust, которая не приводила бы к включению в число зависимостей компилятора Rust при выполнении сборки в режимах "make allnoconfig" и "make allyesconfig" и позволяла бы более свободно экспериментировать с кодом Rust. Аналогичный трюк был реализован при добавлении в ядро экспериментальной поддержки сборки в Clang в режиме оптимизаций на этапе связывания (LTO, Link Time Optimization), после которой планируется добавить и поддержку сборки с защитой потока выполнения команд (CFI, Control-Flow Integrity)...Подробнее: https://www.opennet.dev/opennews/art.shtml?num=53344
что же будет когда Линус уйдёт? Ох боюсь эти хипстеры развалят ядро к чертям.
Останется Грег вместо Линуса.
Вот это-то как раз и вызывает опасения.
Грег только кажется мягким. Но отбрить умеет - да так что ему еще и спасибо говорят, хотя все-равно вышло по его.
Ой, боюсь Микрософт пропихнет своего человечка и будет как с Нокией.
Этих мудаков надо гнать от ядра поганой метлой.
Ядро и так разжирело и расползлось.
Требования к процу и потребление ОЗУ и без того серьезно росли и продолжают расти...С таким прогрессом и людей от Микрософта не надо.
Use "make menuconfig" Luke.
Дано: AMD Athlon(tm) II X2 220 Processor, 4Gb RAM
Ubuntu 12.04: все летает, не более 1Гб рамы занято, свопа не нужно
Ubuntu 14.04: работает, без свопа не ок, можно жить, но ядро нужно ставить 4.4 из xenial
Ubuntu 18.04: тормозит, своп постоянно забит, переключение окон тормозит, все тормозит, и похоже что ядро течетПоследнее нормальное ядро - это 2.6.32, ветка ядер 3.x - адовое тормозилово, ядра 4.x получше, но еще не тестировал
Вообще, весьма интересно будет попробовать нарисовать какие-то тесты чтобы можно было бы говорить предметно, с цифрами
Э парниша, тут опеннет, а не кернел.орг. Тут, как собственно и там, тебе никто, ничего не должен.
Коли сам не можешь разобраться - оформи баг репорт и жди ответа.
А если хочешь качать права - купи себе Винду и клюй мозги суппорту Микрософта.
чо там с 12309
Не задолбало ещё про несуществующее справляться?
> Не задолбало ещё про несуществующее справляться?В смысле, "с глаз долой - из сердца вон!"?
Тогда ошибку на "not found" поправьте, что ли. А то палевно:https://bugzilla.kernel.org/show_bug.cgi?id=12309
> Bug Access Denied
> You are not authorized to access bug #12309. To see this bug, you must first log in to an account with the appropriate permissions.
>
> Тогда ошибку на "not found" поправьте, что ли. А то палевно:Зачем? Такой баг был. Его пофиксили и закрыли. А то что там толпа даунов навалили еще 20 других багов вопя что это то же самое - пусть и получают плашку в фэйс. Кому будет сильно надо, не развалятся новый баг создать. С ***детальным*** описанием ***СВОЕЙ*** ситуации и конфигурации, если, конечно, цель - починить баг и получить нормально работающую систему. А так извините, господа тролли, сломали вам ваше шапито.
>>> Не задолбало ещё про несуществующее справляться?
>> Тогда ошибку на "not found" поправьте, что ли. А то палевно:
> Зачем? Такой баг был. Его пофиксили и закрыли.За квасом? Читать, хотя бы целыми комментариями (вместе с процитированным), а не отдельными строками? Не?
> А то что там толпа даунов навалили еще 20 других багов вопя что это то же самое - пусть и получают плашку в фэйс. Кому будет сильно надо, не развалятся новый баг создать. С ***детальным*** описанием ***СВОЕЙ***
> ситуации и конфигурации, если, конечно, цель - починить баг и получить нормально работающую систему. А так извините, господа тролли, сломали вам ваше шапито.Э-э-э, поздравляю. Абсолютно мимо темы и не отвечает ни на один затронутый вопрос:
мало того, что речь шла о якобы несуществующем баге, так и подкол был в сторону закрытия доступа на _чтение, для всех_.
Пафосные речи про фейсы, плашки и троллей ну совершенно никак не объясняют, почему нельзя было просто закрыть ветку на запись. Увы.
> За квасом? Читать, хотя бы целыми комментариями (вместе с процитированным), а не
> отдельными строками? Не?Это какой-то жирный и глупый троллинг. Попробуйте еще раз.
> мало того, что речь шла о якобы несуществующем баге, так и подкол
> был в сторону закрытия доступа на _чтение, для всех_.Ну так там набежали какие-то тролли, вот и результат.
> Пафосные речи про фейсы, плашки и троллей ну совершенно никак не
> объясняют, почему нельзя было просто закрыть ветку на запись. Увы.Потому что там развели неконструктивный срач и вообще помойку. Теперь бсдотной троллоте и мсовским ботикам станет немного неудобнее. Что как бы хорошо и правильно.
>>>>> Не задолбало ещё про несуществующее справляться?
>>>> Тогда ошибку на "not found" поправьте, что ли. А то палевно:
>>> Зачем? Такой баг был. Его пофиксили и закрыли.
>> За квасом? Читать, хотя бы целыми комментариями (вместе с процитированным), а не
>> отдельными строками? Не?
> Это какой-то жирный и глупый троллинг. Попробуйте еще раз.Ну, не будте так самокритичны -- не такой уж и жирный, ваш троллинг-то.
А с чтением вы попробуйте еще разок -- вдруг получится. А там глядишь и с троллингом получше станет.>> Пафосные речи про фейсы, плашки и троллей ну совершенно никак не
>> объясняют, почему нельзя было просто закрыть ветку на запись. Увы.
> Потому что там развели неконструктивный срач и вообще помойку. Теперь бсдотной троллоте
> и мсовским ботикам станет немного неудобнее. Что как бы хорошо и правильно.Пафосное бла-бла про мсботов и происки "бсдотной троллоты" конечно же отличное объяснение и оправдание цензуры на ровном месте 🙄
> Ну, не будте так самокритичны -- не такой уж и жирный, ваш троллинг-то.Хорошо.
> А с чтением вы попробуйте еще разок -- вдруг получится. А там
> глядишь и с троллингом получше станет.Вы хотите говорить, но не имеете что сказать.
> Пафосное бла-бла про мсботов и происки "бсдотной троллоты" конечно же отличное объяснение
> и оправдание цензуры на ровном месте 🙄На опеннете в основном какие-то такие рожи на тот баг ссылаются. А что до цензуры, кому багфиксы надо - они совершенно свободны создать новый баг. А то что багтрекер предназначен для конструктивного взаимодействия а не помощи каким-то левым телам в поливании проекта фекалиями или пикировках, имхо, само собой подразумевается. Имхо, у тролоты морда треснет юзать багзилу как площадку для антипиара.
А так чисто по человечески, вас никто не заставляет линухом пользоваться. Судя по тому что я вижу вы линем и не пользуетесь. Либо из-под палки, "потому что работодатель заставил". Интересно, я угадал?
> чо там с 12309Он починен и закрыт. А если у вас что-то вылезает, это не 12309 уже.
Ля он тебе полупруфы кидает, что линукс в последнее время не торт.
А ты все равно недоволен.
А что он не торт? Первым добавил поддержку WireGuard, старается поддерживать различные имеющиеся и появляющиеся девайсы и одноплатники.
Fedora 31 без гуевтстоит самба, трансмишен, несктклауд
637M в htop из 16G доступных
может гуи жрут много, может бубунта тупит, хз
1. Если поставишь КДЕ, то окружение будет работать вполне норм
2. Томозят в основном не ДЕ, а приложения. Но не в случае с гномом. В случае с гномом тормозят и приложения, и гном.
Вам к коняникалу.
CentOS 8 с ядром UEK6 (5.x) и с родным ядром (3.10+) вполне умещается в 512M.
У CentOS 8 ядро не 3.10.
> У CentOS 8 ядро не 3.10.Да, простите, 3.10 это у 7.
Восьмёрка - 4.18+.
>CentOS 8 с ядром UEK6 (5.x) и с родным ядром (3.10+) вполне умещается в 512M.даже 7й центос уже разжирел за 512МБ. есть один VPSик, там yum нормально не работает. хотя на нём висит только bind и haproxy.
7 лезет плохо, да. 8 постригли, и он лезет - сам удивился. После старта VPS в минималке используемый объём порядка 160 мб.
Сейчас глянул на один из почтовиков - из 2G - 350M с рабочим постфиксом, опендкимом, давкотом, OCFS2. Всё остальное - буферы и кеш.
> Сейчас глянул на один из почтовиков - из 2G - 350M с
> рабочим постфиксом, опендкимом, давкотом, OCFS2. Всё остальное - буферы и кеш.В случае редгада и менее 512 мегов - проблемы в их гадском пакетном манагере: эта пакость на питоне улетает в OOM и делает базе пакетов харакири. А так то все работает, пока пакет пожирнее не попробуешь вкатить - после чего система немного превращается в тыкву.
Тем не менее, помещается.
А для bloatware - немножко свопа и vm.swappiness=1, чтобы без причины в своп не лезло.
> Тем не менее, помещается.Тем не менее, когда у вас пакетник резко и внезапно дохнет в стиле "кровь, кишки, расФЕДОРАсило" - это ну вообще совсем не айс.
> А для bloatware - немножко свопа и vm.swappiness=1, чтобы без причины в своп не лезло.
Кусок гуано на пихоне вместо пакетного менеджера само по себе блоатваре, при том весьма похабное и стремное. В том же дебиане например пакетный манагер просто на голову лучше.
>Ubuntu 12.04: все летаетПодозреваю, в 2012-м ещё не знали про Meltdown и Spectre.
Брэд оф сив кэйбл. Дома тоже машина core2duo и 4GB. Арч, соответственно ядра свежайшие, ничего не течёт... ssd поставь, кстати, даже дешевый 40гб за 1тыр, будет небо и земля.
Сейчас я вас научу плохому.0. Я подозреваю, что вы уже используете 32-битную ubuntu. Если нет, переставьте.
1. Именем рута, откройте /etc/default/grub в своём любимом текстовом
2. Найдите строчку GRUB_CMDLINE_LINUX_DEFAULT. Там у вас скорее всего присвоено "quiet splash"
3. Добавьте туда опций ядра, чтобы получилось так в одну строчку:
GRUB_CMDLINE_LINUX_DEFAULT="quiet splash nopti noibrs noibpb nospectre_v1 nospectre_v2 no_stf_barrier spectre_v2_user=off spec_store_bypass_disable=off l1tf=off mds=off tsx=on tsx_async_abort=off kvm.nx_huge_pages=off"
4. Потом нужно обновить параметры GRUB. На ubuntu вроде update-grub2
5. ПерезагрузитесьПоздравляю! После этого ваша система снова полна уязвимостей. Вы получили достижение "вернуть 2007-ой".
Список уязвимостей должно быть видно через lscpu.А если серьёзно, может пора купить новый комп?
> Поздравляю! После этого ваша система снова полна уязвимостей. Вы получили достижение "вернуть
> 2007-ой".По расходу памяти этого не видно. Может стоит читать что написано, а не фантазировать?
> А если серьёзно, может пора купить новый комп?
Сразу новый комп с виндой, да?
> 0. Я подозреваю, что вы уже используете 32-битную ubuntu. Если нет, переставьте.Могу посоветовать радикальное лечение: перейти на 10-й дебиан :). Он на 32 битах работает изуметельно, даже на древних, следующие 3-4 года можно вообще не дергаться.
> 3. Добавьте туда опций ядра, чтобы получилось так в одну строчку:
> GRUB_CMDLINE_LINUX_DEFAULT="quiet splash nopti noibrs noibpb nospectre_v1 nospectre_v2
> no_stf_barrier spectre_v2_user=off spec_store_bypass_disable=off l1tf=off mds=off
> tsx=on tsx_async_abort=off kvm.nx_huge_pages=off"...и получите пачку уязвимостей в подарок...
> А если серьёзно, может пора купить новый комп?
Занафига? Десятый демьян с XFCE лично я завожу даже на совсем винтажных экспонатах типа селерон-1800 хрен знает какого года, для ютуба юзерам хватает.
>AMD Athlon(tm) II X2 220 Processor, 4Gb RAMСидишь со старьем а претензии к ядру. 😂
Райзены сейчас по цене грязи, обновись уже. 🤣
> Райзены сейчас по цене грязи, обновись уже. 🤣И получи в подарок PSP и прочие uefi secureboot'ы.
> Ubuntu 18.04: тормозит, своп постоянно забит, переключение окон тормозит, все тормозит,
> и похоже что ядро течетПереходи на debian 10 с xfce, ядро по вкусу, это пофиг :D
> Последнее нормальное ядро - это 2.6.32, ветка ядер 3.x - адовое тормозилово,
> ядра 4.x получше, но еще не тестировалВ убунте проблема ну вообще совсем не в ядрах. Ядро это наименее проблемная часть убунт, но они успешно справляются с торможением, напихивая в систему всякое гомно на пихоне и тому подобное счастье :)
> Требования к процу и потребление ОЗУ и без того серьезно росли и
> продолжают расти...Да ну не пинди! До сих пор бутается на винтажном роутере с 32 мегами RAM на все - там же все и вся опциональное нафиг.
Человечка?
А то, что Майкрософт уже много лет как является платиновым партнёром Linux Foundation (поинтересуйтесь, что это им даёт) вас не пугает?
> Останется Грег вместо Линуса.Ты его предупреди, а то он не в курсе.
Грег тоже немолодой, как и Фёдор Т`so.
Страшно себе представить что будет если Линус получит шальную пулю от мирных протестующих в своем SJW-шном Портланде, Орегон.
Этот Линус и так уже сломался. Наш Линус указал бы своим пальцем куда им надо идти со своим Растом. А этот или успокоительных переел или ему кто-то сказал что надо делать чтобы его окончательно не выгнали.
корпорации намекнули Линуксу что он может остаться на панели если пойдет против ветра ?
не надо приписывать Линусу своё узколобое мышление.
Если ты сделал Хэллоу Ворлд на Раст это не значит что твой кругозор резко расширился. Наоборот он сузился до фанбойства Раста.
То-есть если человек поэкспериментировал с другим языком программирования и понял, что он может быть лучше (=более удобный/безопасный/т.п.) в каких-то сценариях, это значит что его кругозор сузился? Очень "креативный" логический вывод. Т.е. по такой логике, человек с самым широким кругозором это тот, кто научился писать на C древней версии стандарта в одном стиле и никогда больше ничего не пробовал и не менял свое мнение? Мне кажется это не совсем отвечает идеям "широкого кругозора".
Какую конкретно проблему может решить до сих пор ЭКСПЕРИМЕНТАЛЬНЫЙ язык в ядре широко распространенной ОС? Никакой, кроме ЕЕЕ (ТМ) мелкософт. Человек с широким кругозором - это тот, кто понимает, зачем корпорации делают те или иные телодвижения. Еще для кругозора историю развития технологий полезно изучать, вместо хипсторских говноязыков всяких.
> сих пор ЭКСПЕРИМЕНТАЛЬНЫЙ языкс разморозкой, там пару лет назад все стабилизировалось
Ачеридной растофанбой
> с разморозкой, там пару лет назад все стабилизировалосьИменно поэтому пару месяцев назад выкатили очередное это, с несовместимыми изменениями? :)
Я понятия не имею и не хочу гадать. Я не разработчик ядра. Не был разработчиком ядра на C и не планирую присоединяться на rust. Более того, я не занимаюсь гаданием о том, чем там "корпорации" занимаются и не очень люблю копаться в заговорческих теориях о том как майкрософт (судя по всему, руками людей из других компаний) собирается уничтожить Linux (или к чему это "EEE (TM) мелкософт" было?). Мой комментарий не отвечал на критику использования rust в ядре, он отвечал на заявление вида "если ты попробовал rust, то ты фанбой и твой кругозор сузился". Нет, это не то, как это работает. А обсуждение зачем в ядре rust, какую проблему он решит, какие проблемы он принесет и т.п. я оставлю разработчикам ядра, потому что рассуждать на уровне выше "бабок на базаре" мои знания мне не позволяют.
Так есть такие персонажи. За новую блестящую погремушку схватились и суют ее везде. Это как дети на отдыхе с родителями. Им втюхивают всякую чурчхелу на пляже, а они и просят - дай-дай )Верно сказано уже - надо смотреть дальше и шире. Задавать вопросы. Зачем? Кому выгодно? И вдруг (внезапно) окажется, что это компании определенные преследуют свои интересы. Именно поэтому Microsoft носится с C# и TypeScript. Именно поэтому Google сейчас свой Dart пытается вбить гугло-хомякам и мобильным разработчикам. Им пыль в глаза пускают - а они и рады.
линукс это ядро, а не ос
Вот вот. Позволят неоюразованным растопрограммистам писать в код в ядре. rust нужно запретить
Если не Торвальдс, то кто, да? Откуда столько тупых в айти, лол
Куча проектов держатся на личности своих создателей. И без них не особо интересны. Ну или едут не туда, выезжая по инерции - та же MS при Манделе, Эпл при кто-у-них-там-после-Джобса...
Тот же Питон повернул не туда после ухода Гвидо.
Погодите, т.е. при Гвидо питон шел куда надо?Хорошо тогда что этот Гвидо ушел, может ещё шанс на нормальный язык.
> Погодите, т.е. при Гвидо питон шел куда надо?Гвидо разрабатывая питон бурчал: "не сбить нас сверного пути: нам все-равно куда идти". Правда в конце концов он сам же и заколебался, но это уже другая история.
> Хорошо тогда что этот Гвидо ушел, может ещё шанс на нормальный язык.
Отличный ЯП - может почти что угодно, при том - одинаково паршиво.
Бизнес очень хочет IT услуг, но не хочет за это платить. Поэтому они продвигают технологии, максимально упрощающие вход в IT неквалифицированных людей, надеясь, что они снизят стоимость специалистов.
Бизнесу нужны фреймворки для того, чтобы писать тонны кода быстро и дешево. Правда множество фреймворков, наслаиваясь на приколы языков и компиляторов, в итоге ловят кучу багов, падают в производительности и т.д. Ядро - это продукт для работы с хардваром, поэтому по крайней мере Линус не хочет в довесок к уже немаленькому линуксу тянуть и поддержку рантаймов этих ваших растов.
Ровным счётом ничего. Линус уже давно не кодит ядро, лишь отвечает на письма и советы раздаёт.
В ИТ хороший менеджер десятка кодеров стоит.
> В ИТ хороший менеджер десятка кодеров стоит.И даже тысячи. Один хреновый менеджер может слить результат работы 1000 человек как делать нефиг.
Сделают форк ядра с зоопарком, а оригал уйдёт в небытие
> оригал уйдёт в небытиеЭто что за зверь такой? Звучит как гибрид орангутана с гамадрилом?!
Батя невесты жестко осадил жениха-растолюба читать далее...
С подключением!
а если sysvinit на rust переписать и вернуть в debian, а от systemd-зависимостей избавиться?
после того как вы допишете сисвинит до состояния в котором он являтся заменой системд вы получите ещё один системды.. и разница будет лишь в том что вместо самодуров разработчиков системде у проекта во главе будете вы.. проще уж сразу свой форк системды на расте сделать..
кстати про systemd на rust, https://github.com/KillingSpark/rustysd хотя там цель была не systemd на rust ради rust, а показать, что функционал systemd возможно реализовать на других языках
на баше давайте
слабак, вот на posix sh - другое дело!)
> на баше давайтеС экранированием заманаешься.
Ну ты лох... sysvinit читается как систем пять инит! Пять карл! Ревизия юникса была в которой данный инит стал дефолтным
> Ну ты лох... sysvinit читается как систем пять инит! Пять карл! Ревизия
> юникса была в которой данный инит стал дефолтнымграмароглистам не понять модель каверканья транслитературных слов, подчёркивающую неуважение к обсуждаемым предметам.
rust evangelism strikeforce!
> имеет шанс завязнуть в своём болотеДипломат.
А чо Раст? Давайте сразу на питоне, а то многие не могут участвовать в разработке ядра линукс. Это их дискриминирует.
На джаваскрипт могут программировать даже нейтив американс.
«Чукча не читателиус», рад приветствовать.
Потому что раст выдает ту же скорость, что и С++, при этом предоставляя на порядок больше гарантий.
unsafe не безопаснее ленты которой перетянули рядом с открытым люком.
Если бы был компилятор/препроцессор C каждый раз, когда делается что-то потенциально опасное требовал бы писать какую-нибудь директиву типа #unsafe, думаю само это уже чуток, но улучшило бы качество продукта.
Другой вопрос что в классическом C это пришлось бы писать почти везде и сильно ухудшило бы качество уже кода.
Как быть когда народ, бизнес, нарастающая сложность требует гарантий, хоть каких-то?
Rust как раз отражает возникший спрос. Соответствует ли он ему, это уже другой вопрос.
Но уже понятно, что просто сказать "лучше тестируйте", "нанимайте профи" и т.п. уже не достаточно.
Что-то он это улучшит, где-то поднимет дискуссию, где-то сам Rust потом еще будут допиливать...
>Если бы был компилятор/препроцессор C каждый раз, когда делается что-то потенциально опасное требовал бы писать какую-нибудь директиву типа #unsafe, думаю само это уже чуток, но улучшило бы качество продукта.Епрст. Прагма unsafe сделана для ЯП, где работы с указателями нуль. При чем тут Си, который работает только с указателями и другого режима у него нет? Господин иксперт, идите учить матчасть. Для вас смысл unsafe все еще не раскрыт.
>Как быть когда народ, бизнес, нарастающая сложность требует гарантий, хоть каких-то?
А вы из под какой ОС написали это сообщение? Ядро линукса (сюда же андроид) на сях, ядро винды на сях, ядро макос на сях. Вы ядру значит доверяете, а программам нет? Это ваши личные половые трудности, что вы нанимаете программистов, которым вы не доверяете. Наймите Торвальдса и делов-то.
>Как быть когда народ, бизнес, нарастающая сложность требует гарантий, хоть каких-то?И Java их даёт уже не один десяток лет. Ещё есть виртуальные машины, контейнеры, микросервисы. Rust то зачем нужен?
Затем, что джава не нужна.
Безумно жирная и откровенно переусложненная для нынешнего времени.. и это притом, что багованного барахла на ней понаписано более, чем немало.
> и это притом, что багованного барахла на ней понаписано более, чем немало.Это прекрасно демонстрирует, что инструмент не помогает вправлять кривые руки, следовательно все языки существующие лишь ради ограничения возможности программиста не нужны. Нужен Си для самого производительного кода и языки набитые сахаром вроде шарпа и Perl. Если сделать язык, на котором могут писать даже идиоты то только идиоты на нём и будут писать.
>> и это притом, что багованного барахла на ней понаписано более, чем немало.
> Это прекрасно демонстрирует, что инструмент не помогает вправлять кривые руки, следовательно
> все языки существующие лишь ради ограничения возможности программиста не нужны. Нужен
> Си для самого производительного кода и языки набитые сахаром вроде шарпа
> и Perl. Если сделать язык, на котором могут писать даже идиоты
> то только идиоты на нём и будут писать.Перл и шарп не набитые сахаром.
Они вообще едва ли когда-то таковыми были, поскольку набивка их - синтаксический мусор и горы оверхеда.Если сделать язык, на котором будут способны писать даже идиоты, то и идиоты смогут решать посредством него какие-то свои, специфические задачи( которых наверняка хватает ) и чего-либо плохого лично я в этом не вижу.
Другое дело, что подобный "взгляд" на проблему( что язык не надо делать простым "просто потому что" ) ведет к совершенно гротескному положению дел в разработке по и откровенному уродованию ЯП и самой разработки, тогда как результат от этого, нередко, лучше не становится.
>Безумно жирная и откровенно переусложненная для нынешнего временидай угадаю, ты не программист, а кульсисоп? и про жабку судишь по местным креативам?
> дай угадаю, ты не программист, а кульсисоп? и про жабку судишь по
> местным креативам?Забавное слово. Самого так часто называют ?)
Поскольку лично я, по итогу многих лет разработки, слышу это слово впервые.Просто это ненормально, когда, для каких-то даже относительно простых вещей, требуются баснословные вереницы кода и многие месяцы/годы обучения именно "самому языку".
Жаба в этом смысле чем-то плюсЫ напоминает: нЕкогда крутая, логичная и лаконичная, с течением времени и появлением новых технологий/подходов к разработке, полухаотически допиливалась для хоть какой-то актуализации..
Как итог - нереально жирная лексика, бескрайние кучи барахла.. и "основа", на которой, вроде бы, сделать можно и очень многое, но почти нифига - просто, быстро и без тонн уродливого кода.п.с: жабу сужу по мобильной разработке и в т.ч по тому простому факту, что, посредством нее, программист по итогу многих месяцев( а то и лет ) обучения, с кучей страданий и расходов для конторы( посколькумобильные жаба-программисты еще каких-то денег стоят.. по "инерции" ) выдаст приложение только под андройд, тогда как другой программист, по итогу месяцев обучения и применению штук типа react-native, выдаст на выходе 2 приложения - для андройда и для яблока, более того, при нормальной реализации, у 80+% приложений даже не будут ощущаться проблемы с производительностью( поскольку у норм реализованных приложений, подавляющая часть времени ожидания - это просто ожидание выполнения запросов к бэкенду ).
Конечно, можно сказать, что подобные штуки базируются на модулях с "нативным" для платформ кодом, но для 90+% типовых приложений( формы/поля/статистика/итп ) не требуется вообще на него глядеть и все потребности полностью покрываются штуками вроде того же JS( или Dart ).
> дай угадаю, ты не программист, а кульсисоп? и про жабку судишь по местным креативам?Чтобы судить о жаба программах можно быть даже домохозяйкой - УГшность этого софта самоочевидна. Хуже только гадюка да электрон чтоли.
> И Java их даёт уже не один десяток лет. Ещё есть виртуальные
> машины, контейнеры, микросервисы. Rust то зачем нужен?Там, в отличие от, придумали как все это в compile time, а не в run time обтяпать. Так что жаба вообще совсем не конкурент по перфомансу и предсказуемости.
Увы, мнение об отключении всех проверок в unsafe — это типичное заблуждение, потому что в документации к языку Rust сказано, что unsafe позволяет:Разыменовывать сырой указатель;
Вызывать и объявлять unsafe функции;
Читать или измененять статическую изменяемую переменную;
Реализовывать и объявлять unsafe типаж;
Получать доступ к полям union.
Ни о каких отключениях всех проверок Rust здесь и речи не идет. Если у вас ошибка с lifetime-ами, то просто добавление unsafe не поможет коду скомпилироваться. Внутри этого блока компилятор продолжает проверять код на соответствие системы типов, отслеживать время жизни переменных, корректность на потокобезопасность и многое-многое другое. Подробнее можно прочитать в статье You can’t "turn off the borrow checker" in Rust.К unsafe не стоит относиться как "я делаю, что хочу". Это указание компилятору, что вы берете на себя ответственность за вполне конкретный набор инвариантов, которые компилятор самостоятельно проверить не может. Например, разыменование сырого указателя. Это мы с вами знаем, что сишный malloc возвращает NULL или указатель на аллоцированный кусок неинициализированной памяти, а компилятор Rust об этой семантике ничего не знает. Поэтому для работы с сырым указателем, который вернул, к примеру, malloc, вы должны сказать компилятору: "я знаю, что делаю; я проверил, там не нулл, память правильно выравнена для этого типа данных". Вы берете на себя ответственность за этот указатель в блоке unsafe.
>к примеру, malloc, вы должны сказать компилятору: "я знаю, что делаю; я проверил, там не нулл, память правильно выравнена для этого типа данных". Вы берете на себя ответственность за этот указатель в блоке unsafe.Ровно тоже делает разработчик на С, далее приводит указатель к нужному типу, работает с ним и освобождает. В С++ operator new ещё и возвращает указатель нужного типа на полностью сконструированный объект и может бросить (он или конструктор объекта) исключение, а деструктор освободит все ресурсы выделенные объектом. Или раст в состоянии автоматически освободить системный хэндл или указатель выделенный в ансейф блоке?
>Или раст в состоянии автоматически освободить системный хэндл или указатель выделенный в ансейф блоке?Да никак он не освободит. Вызывать раз free() это совсем детский случай. Но также жду ответа от ржависта.
> Да никак он не освободит. Вызывать раз free() это совсем детский случай.
> Но также жду ответа от ржависта.Мне интересно как ржависты хотя-бы из юзермода безопасно делают какой-нибудь sendmsg() когда у него прототип явно тому не споособствует :)
Как интересно, ржава сы-куны только минус поставить смогли, и молчок в тряпочку? А то все позиксное апи мало того что си, мало того что везде указатели, так это еще самый древний и дурной диалект сей, 89-й, где UB просто в крови. Ибо "int something" там может означать все что угодно. Как правило от 16 до 64 битов шириной, без каких либо гарантий. Что очень доставляет системным програмерам. И, главное, ничего с этим чудом не поделаешь - апи такое! Если его изменить - программы сломаются. И кому это апи будет нужно...? Не понимаю как это апи вообще секурным может быть, хоть тресните.
Да, типичная история. unsafe указатель оборачивают в структуру Rust и для нее пишут деструктор (реализуют Drop trait)
после этого раст автоматически освободит системный хэндл после окончания его жизниВот тут подробнее
https://medium.com/dwelo-r-d/wrapping-unsafe-c-libraries-in-...
Ну это порнография. Враппер на внутренний небезопасный деструктор. Где тут иксперт по unsafe. Вот он этому коду будет доверять? Ведь там есть магическое слово unsafe. А то, что нижележачий деструктор на плюсах может быть бажным никого не волнует!
>>> Да никак он не освободит.
>> после этого раст автоматически освободит системный хэндл после окончания его жизни
> Ну это порнография. Враппер на внутренний небезопасный деструктор.
> И вообще НИЩИТАИЦА! ЭТО НИЩИТАИЦА, Я СКАЗАЛ!1!Движок форума съел последнюю строчку. Я восстановил.
> Вот он этому коду будет доверять? Ведь там есть магическое слово unsafe. А то, что нижележачий деструктор на плюсах может быть бажным никого не волнует!
> А вообще, баги могут быть в микрокоде и железе, поэтомо в ж*пу все тесты, анализаторы, МИЗРЫ и прочее ограничивающее креативность настоящих разработчиков барахло для ламаков! Потому что анонимный гладиолус!Тут движок целый абзац съел. Не благодари!
Вы не правы, у С++ основная проблема это не сложность и гарантии, это невероятно долгая компиляция. Любой средний проект файлов на 200-300 компилируется по часу на современных 6-8 ядерниках. Будь ядро на С++ Линус на своём райзене компилировал бы его часов 7. Раст по всем тестам и личному опыту компилируется ещё дольше, иногда раза в полтора. В реальной разработке а не в хипстерский проектах на 10 файликов это выливается в кучу проблем.
Просто кто-то не умеет свой проект правильно готовить.
Дело не в конкретно C++. Любой язык с метапрограммированием будет компилить долго.
В свое время Oracle демонстрировал, что java способна выдавать такую же скорость, как ассемблер (на одной единственной задаче для одного единственного процессора). Но это ж не повод?
С одной стороны, чем больше всяких ЯП поддерживается при разработке - тем проще порог вхождения в проект (типа есть те кто умеют в Ржавого, но не умеют в Сишечку). Но и усложняют требования к мантейнерам и ревизорам кода - а именно на их нехватку Линус и жаловался.
с разморозкой, но нас, и бизнес, не интересует скорость
На html и CSS могу, подключив bootstrap 4!
Слабак, уже есть bootstrap 5.0.0 alpha 1
https://github.com/twbs/bootstrap/releases/tag/v5.0.0-alpha1
> Слабак, уже есть bootstrap 5.0.0 alpha 1
> https://github.com/twbs/bootstrap/releases/tag/v5.0.0-alpha1А кого уже заколебали эти адские переростки - есть чудный w3.css, сделаный ни много, ни мало автором w3schools. Который таки показал как делать as simple as possible, but not simpler than that. Этим гении от вебмакак и отличаются...
"Ольга" это, полагаю, такая тонкая отсылка к ольгинским ;)
Полагаю, Rust продвигается в ядро ошибочным способом.Следует транслировать его в Си (где это возможно) с asm вставками (где невозможно) для популярных платформ. Тогда неверующие воочию увидят непревзойдённую эффективность и безопасность решения и сразу сдадутся.
А ещё обязать писать код с закрытми глазами, без монитора. Чтоб наверняка дошло как плох Rust.
Благодарю за идею. Заказал самый лучший микроконтроллер Arduino 101 и 5 соединительных проводников типа пап-папа. Теперь осталось найти подходящие сервопривод, реле и линейку (суперклей у меня уже есть). Подскажите пример кода на Rust, который обработает вывод компилятора и установит высокий уровень на 10м пине.
Суперклей из старых запасов, с толуолом? :)
Это "Момент" был с толуолом.
ТНТ слишком радикальное средство для выпрямления рук.
ищи тут https://www.rust-lang.org/what/embedded
https://internals.rust-lang.org/t/impediments-to-transpile-r...
Какая неожиданность. :)In the last week or so, the points has been made multiple times that Rust could never unseat C because it just was not portable enough.
This is indeed a fair point, rustc is currently bound to LLVM which supports much less platforms than C compilers do
Но там джва года прошло, а я так и не дочитал.
> Следует транслировать его в СиЗачем тогда этот ваш раст нужен? Генерить Си-код, теоретически, можно вообще из любого ЯП'а.
https://andrei-markeev.github.io/ts2c/Ещё чуть-чуть и можно будет в ядро контрибутить
> https://andrei-markeev.github.io/ts2c/
> Ещё чуть-чуть и можно будет в ядро контрибутитьВот это правильно! Давно пора!!111 Осталось добавить обвязку для выполнения в ядре printf() и abort();
> printf() и abort();printf -> printk
abort -> panic :D
>> Следует транслировать его в Си
> Зачем тогда этот ваш раст нужен? Генерить Си-код, теоретически, можно вообще из
> любого ЯП'а.В том то и дело. При этом в результате трансляции некоторых ЯП образуется вермишель. Но Rust то рвёт всех как Тузик грелку. Представляете себе лицо Линуса, когда ему дают вариант на Си в 2.71 — 3.15 раз более оптимальный, чем он написал ручками?
> Но Rust то рвёт всех как Тузик грелкуОсобенно по скорости компиляции, ага.
> Представляете себе лицо Линуса, когда ему дают вариант в 2.71 — 3.15 раз более оптимальный, чем он написал на Си?В каком плане более оптимальный? Как раз таки Си - наиболее оптимальный ЯП для решения задач из области разработки системного ПО и, тем более, ядер ОС из существующих в природе. В идеале, конечно, ядро ОС должно реализовываться на более низкоуровневом ЯП'е, нежели С, но, за неимением такового, приходится использовать последний. Высокоуровневые ЯП'ы с функцией подтирания соплей за нерадивыми разрабами в этой области нафиг не сдались.
> Высокоуровневые ЯП'ы с функцией подтирания соплей за нерадивыми разрабами в этой области нафиг не сдались.Да, именно об этом и говорит нам новость.
Уровнем ниже — "языки ассемблера" ("высокоуровневая" абстракция над оп-кодами), и их вовсю используют. Там, где без этого будет плохо.
А C — как раз таки кросс-ассемблер "среднего" уровня. Где всё ещё всё можно, но есть инструменты для написания "универсального" кода. И современные реализации, что приятно, знают обо всякой рутине. Вроде размера указателя или приведения типов.Но кое чего начинает не хватать. Ядер в последнее время стало много, а C хорошо заточен под программирование *одного* потока. "Фреймворки" (библиотеки) понятно есть, но для их использования надо прокачивать скилл шизофреника (утрирую, но не сильно).
Вот где-то здесь (как мне кажется) начинается заход на более "молодёжные" ЯП. Но конкретно на счёт rust есть сомнение, т.к. от него явственно попахивает оверинженирингом. Поглядим, может и сумеют зашлифовать. Ну или выпустят на следующем витке какой-нибудь "corrosion"…
> Уровнем ниже — "языки ассемблера" ("высокоуровневая" абстракция над оп-кодами),
> и их вовсю используют. Там, где без этого будет плохо.
> А C — как раз таки кросс-ассемблер "среднего" уровня. Где всё ещё
> всё можно, но есть инструменты для написания "универсального" кода.С не просто кроссассемблер, а абстракция над машинным кодом PDP (см. пре- и пост-инкременты/декременты). В языке отсутствуют аналоги для команд обмена (bswap и xchg), lock лишь недавно появился. Потоковые "мультимедия" инструкции вообще отдельная тема.
> Потоковые "мультимедия" инструкции вообще отдельная тема.Кроме потоковых инструкций, на "ассемблере" можно и вот так: (GPL2+, сперто из examples)
#include "lwan.h"LWAN_HANDLER(hello_world)
{
static const char message[] = "Hello, World!";response->mime_type = "text/plain";
lwan_strbuf_set_static(response->buffer, message, sizeof(message) - 1);return HTTP_OK;
}int
main(void)
{
const struct lwan_url_map default_map[] = {
{ .prefix = "/", .handler = LWAN_HANDLER_REF(hello_world) },
{ .prefix = NULL }
};
struct lwan l;lwan_init(&l);
lwan_set_url_map(&l, default_map);
lwan_main_loop(&l);lwan_shutdown(&l);
return 0;
}...а чо, ассемблерщики или там какие растаманы покажут нам чонить сравнимое? А то я нечто похожее только на Go видел :). Это lwan.ws, с очень милыми корутинами, кстати. И кстати си достаточно низкоуровневый чтобы эти самые корутины на нем можно было выпилить, даже если их изнчально и не было. А растаманы так расширять ЯП могут? Ассемблерщики то смогут... если не заколебутся раньше :)
> с очень милыми корутинами, кстати. И кстати си достаточно низкоуровневый чтобы
> эти самые корутины на нем можно было выпилить, даже если их изнчально и не было.Зашкаливающее знания матчасти анонимами 🙄
http://www.dabeaz.com/coroutines/ - реализация корутин на питоне 2 в 2009 году.
Еще есть для жабки/Scala/Clojure/Kotlin
https://github.com/leonoel/cloroutine/tree/master/src/clorou...
https://github.com/Kotlin/kotlinx.coroutines> А растаманы так расширять ЯП могут?
Просто зашк... а не, не буду повторяться ...
https://docs.rs/corona/0.4.3/corona/
> A library combining futures and coroutines.https://docs.rs/coroutine/0.8.0/coroutine/
> Coroutine implementation in Rust.
> http://www.dabeaz.com/coroutines/ - реализация корутин на питоне 2 в 2009 году.
> Еще есть для жабки/Scala/Clojure/Kotlin
> https://github.com/leonoel/cloroutine/tree/master/src/clorou...
> https://github.com/Kotlin/kotlinx.coroutinesЭтот мусор вообще к чему? Он позволяет выжать больше перфоманса? Или там будет код лаконичнее и симпатичнее? Или это до кучи, "с лопаты"? Это в упомянутом случае был реверанс на тему низкоуровневости си, пример что при желании си может стать и довольно высокоуровневой штукой, где минимальный "вебапп"/"микросервис" - полстранички кода аж. С минимумом зависимостей. У той фигни весь бинарь с кучей фич менее 200К на все. Сравним с jvm, python, clojure... :D
> Просто зашк... а не, не буду повторяться ...
Ну так покажи пример столь же лаконичного вебсервака на расте? Вот конкретно та штука для этого на сях лезет в весьма солидные дебри с setjmp и сотоварищи, вытворяя ту еще черную магию. Но это все "где-то там" и сделано автором той вундервафли. А для юзера "либы" получился симпатичный и относительно высокоуровневый интерфейсик для дерга.
>> https://docs.rs/corona/0.4.3/corona/ A library combining futures and coroutines.
> https://docs.rs/coroutine/0.8.0/coroutine/Отлично, только это - не вебсервак. А покажете весь вебсервак с корутинами и чтобы не менее лаконично чем тот пример? Я пока только у go'пников что-то сравнимое видел, но у них бинарь такого пошиба - мегов на 6, и тормознее, с GC и прочими прелестями :)
> https://docs.rs/tokio/0.2.9/tokio/task/index.html
На мой вкус - многовато странного мусора в синтаксисе. А нельзя было оставить аккуратный сиобразный синтаксис не усугубляя его лишними закорючками? В сях и так странных закорючек хватает :P
>> Но Rust то рвёт всех как Тузик грелку
> Особенно по скорости компиляции, ага.
>> Представляете себе лицо Линуса, когда ему дают вариант в 2.71 — 3.15 раз более оптимальный, чем он написал на Си?
> В каком плане более оптимальный? Как раз таки Си - наиболее оптимальный
> ЯП для решения задач из области разработки системного ПО и, тем
> более, ядер ОС из существующих в природе.Это не совсем так. Си всем понятен, это не всегда хорошо. Вы пробовали отправлять код в ядро? Сразу же отвечают: вот тут ошибка, вот так не пишут, и так далее. Приходится читать очередную главу из Кернигана и Риччи. Очень долго и не оптимально.
да отстаньте вы уже от людей! со своими модными штучками. напишите сво линукс, в чем проблема? сделайте форк и балуйтесь. реально эти покемоны уже достали.
Проблема в том, что кто-то читает выборочно, потому недостаточно осведомлён о передовых достижениях науки. Британские учёные скрестили Тузика и Грелку, и новое животное порвало само себя.
Ну так он, говорят, все проверки сделает в compiletime-а, соответственно код на C, будет гораздо более надёжный, чем если-бы его сразу писал человек. При этом будет компилироваться для всех платформ, которые поддерживает язык С. Сплошные профиты же.
Rust полагается на оптимизации, которые производит LLVM. Прямая компиляция в Си ничего не даст, даже ухудшить может ситуацию, потому что Си не дает тех гарантий для LLVM, которые дает Rust.
Не совсем понятно почему? Там-же большая часть контролей, вроде, на уровне компилятора. Т.е. сам компилятор контролирует, что что-то куда-то не вылезло и ни на кого не налезло.. Runtime-проверок должно быть не больше, чем в C, иначе не понятно, почему Rust на уровне, а по заявлению некоторых, и быстрее, чем C.
asm код это итак результат компиляции. Но пользовать этот Дизассемблироавнный код будет еще той морокой.
Растоманы победили?
Хайп ради хайпа
Проблема растаманов в том, что они не могут без Cargo. В ядре запрещено использование библиотек. Человек загрузил архив ядра, распаковал и просто скомпилировал, все!Опасность заключается в том, что Растаманы по старой привычке станут в своих исходиках прописывать имена внешних библиотек.
И они не замечают использование библиотек, потому что Cargo сам всё скачает, соберёт, а потом ещё их сборку опубликует.Кстати на https://doc.rust-lang.org/cargo/getting-started/installation... официальный способ инсталляции этого чуда:
$ curl https://sh.rustup.rs -sSf | sh
Похоже, у Линуса хронические сотрясения от фейспалмов или его уже всё задолбало.
Сразу видно очень умного человека. Уточните, пожалуйста, на чем вы программируете и какой у вас опыт разработки?
И эти люди говорят про безопасность.
https://forge.rust-lang.org/infra/other-installation-methods... же
Ещё можно из репозиториев своего дистра установить.
> $ curl https://sh.rustup.rs -sSf | shБезопасТность такая безопасТнность...
В чём проблема напрямую rustc запускать? А ещё никто не запрещает класть зависимости рядышком.
> никто не запрещает класть зависимости рядышкомОга. Мало нам инитрд с коллекцией шлака, без которого ОС уже не может взлететь, так теперь ещё нужен будет рядом с ядром навалить груду навоза, а загрузчик теперь должен будет не просто загрузить ядро в память и передать ему управление, а прошерстить его код, найти требуемые функции в приложенных библиотеках и подгрузить их вместе с ядром.
Для внешнего кода нет разницы, один там крейт или несколько десятков. На выходе тот же бинарный полуфабрикат в количестве одной штуки. Прям как в няшном си.
то что карго удобный не означает что драйвера в ядре обязательно надо писать с его использованием.. особенно если такие драйвера просто никто не примет в ядро тут хочешь не хочешь а перепишешь на чистый раст без карго.
Тут такое, всё что может использоваться во зло, будет использовано.
ну откуда вы повылазили то...
у раста есть ядро, которое работает вообще без внешних зависимостей
вот ссылка, для самый продвинутых https://doc.rust-lang.org/core/index.html
У C# тоже есть ядро не требующее фреймворка. Давайте и C# добавим.
А ты, похоже, даже в своем расте не разбираешься.Core - это и есть внешняя зависимость. Более того, в этом Core куча примитивов, которые в ядре просто неприемлемы, но которые требуются всякими языковыми конструкциями. Собственно, это основная претензия к расту - он абсолютно неюзабелен как системный ЯП из-за этого. Если бы это просто был "Си со сборкой мусора во время компиляции", ядро бы давно уже на него перешло.
Стоп - стоп, какая внешняя зависимость core??...core это всеголишь набор кучки трейтов и макросов которые реализованы самим языком.
Хотите реально внешнюю библиотеку (я не про std), возьмите alloc....
> у раста есть ядро, которое работает вообще без внешних зависимостейIt is the portable glue between the language and its libraries, defining the intrinsic and primitive building blocks of all Rust code.
и что с того, если это ядро не входит в реализацию самого ЯП и при этом реализует его возможности, т.е. является, по сути, внешней зависимостью? ЯП, требующий зависимости для использования языковых конструкций? ЯП, не обладающий zero runtime для реализации ядра ОС - ну чё, круто. стильно, модно, смузихлёбно
>>> у раста есть ядро, которое работает вообще без внешних зависимостей
>> It is the portable glue between the language and its libraries, defining
>> the intrinsic and primitive building blocks of all Rust code.
>> It links to no upstream libraries, no system libraries, and no libc.
> и что с того, если это ядро не входит в реализацию самого
> ЯП и при этом реализует его возможности, т.е. является, по сути,
> внешней зависимостью?Если читать целиком, а не отдельными буквами - ничего. Потому что чушь.
> ЯП, требующий зависимости для использования языковых конструкций? ЯП, не обладающий zero runtime для реализации ядра ОС - ну чё, круто. стильно, модно, смузихлёбно
Прежде чем пройти по ссылке, подготовь ведерко со льдом и огнетушитель, предупреди соседей:
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
https://www.redox-os.org/
> https://www.redox-os.org/Этой шляпой хотя-бы ее авторы пользуются? А то с дровами в юзермоде и микрокернелом оно кажется как максимум сможет быть машиной для чтения почты. Игори? Серваки? 4К видео? Удачи :)
> https://www.redox-os.org/Этим хотя-бы авторы оного уже пользуются? Не говоря о тех кто на него ссылается :)
> ЯП, не обладающий zero runtime для реализации ядра ОС - ну чё, круто. стильно, модно, смузихлёбно
>> https://www.redox-os.org/
> Этим хотя-бы авторы оного уже пользуются? Не говоря о тех кто на него ссылается :)
> И вообще, это НИЩИТАИЦА! НИЩИТАИЦА Я СКАЗАЛ!Какая-то совсем уж унылая отмазка.
Через некоторое время..Сборка ядра:
Компилятор языка а1 не обнаружен.
Компилятор языка а2 не обнаружен.
Компилятор языка а3 не обнаружен.
...
Компилятор языка аN не обнаружен.
Компилятор языка C обнаружен.
Слишком мало языков для сборки ядра.
Вавилонское столпотворение.
Будешь платить за рас(т)ововерную сборку ядра. Ишь ты вздумал сам собирать из исходников, соответствющих бинарям.
"Хозяин, надо больше компиляторов!"
С возрастом Линус становится адекватнее, это радует))
не одыкватнее. Любому анонимному комментатору opennet, очевидно что у Линуса сотресение мозга от феспалмов, раз он согласен добавить поддержку этого "ужастного недоязыка" с unsafe блоками!!!!!
> Любому анонимному комментатору opennet очевиднолучше так: любом иксперту опеннета. знатный троллинг, продолжайте
кто-нибудь, скажите им что разводить зоопарк в ядре - это плохо!
Опоздал с этим на много лет, увы Торвальдс, по его же заявлениям не знает всего ядра теперь.
Да там его кода уже наверное не осталось
А Танненбаум предупреждал!
> А Танненбаум предупреждал!Таненбаум в отличие от опеннетчиков намного более здравомыслящий тип, который даже местами признал что его взгляды тоже не вели к наилучшим результатам.
кто-нибудь, скажите психиатрам что разводить зоопарк - это плохо!
Конференция Linux Plumbers будет только в конце августа и она вообще-то даже не про ржавчину. Тут что, будут про каждое упоминание Rust в этой связи постить новость? Это ли не фанатизм?
Надеюсь, дядя Линус не позволит пихать этот неуместный слог в без того жирное ядро
>>драйвер должен быть в формате, при котором сбои будутРади этого стоило доставать с полки раст
Если я всех индусов буду называть ржавыми то они выкинут эту дрянь из ядра как они выкинули чёрных?
Линуса задолбали. Он возьмёт тактику, что будет соглашаться с тем, что ржавый в ядре нужен, но разносить все попытки его туда засунуть. Молодец, так и надо. Это уже политика
> Линуса задолбали. Он возьмёт тактику, что будет соглашаться с тем, что ржавый
> в ядре нужен, но разносить все попытки его туда засунуть. Молодец,
> так и надо. Это уже политикаТорвальдс вообще сообразительный тип - вы там пободайтесь с этим, на публику, и в моем формате, а я посмотрю выйдет ли у вас чего дельное и не задолбаетесь ли :)
Пусть еще добавят поддержку язык brainfack и 1С :))))
А так на деле надо чтобы использовался один язык. Проще аудит проводить.
Хочу поддержку Паскаля и Бейсика, пусть добавят
Ты забыл топнять ножкой, ламерок.
Известны случаи написания драйверов под Windows на Паскале (точнее, на Delphi). Так что вперёд. :)
Первоначально оно так и было (стырено с яблока) поэтому ранние API были не в сишной нотации.
Вы вообще о чём? Ядро NT фактически перекуплено компанией Microsoft у профессионалов и уходит корнями к DEC/VAX и VMS. Когда оно начиналось, яблоком в гараже закусывал Джоббс, рисуя Стиву Возняку золотые горы. Но это всё вряд ли имеет отношение к тому факту, что Delphi позволяет собрать пригодный для загрузки в ядро модуль.
Ну да, а до NT окошек не было. :)
Ядро и окошки две большие разницы.
Так речь и шла про окошки.Вообще язык не определяет можно или нет на нем писать для ядра.
Это определяется
1. Наличием кмпилятора (и линкера) позволяющих из этого языка собрать код не требующий рантайма или линкующего напрямую с рантаймом ядра (или в ядре должна быть машина по выполнению промежуточного кода :)
2. Наличием договоренностей, что на этом можно писать и будет сопровождаться.
> Так речь и шла про окошки.Да ну? Где это она шла? Может Вы темой ошиблись? Эта называется "Линус Торвальдс подключился к обсуждению начальной реализации поддержки Rust в ядре Linux"
и в https://www.opennet.dev/openforum/vsluhforumID3/121235.html#72 просят добавить Паскаль.
> Вообще язык не определяет можно или нет на нем писать для ядра.
Ещё как определяет. Напишите что-либо для ядра на "нестандартном" языке, разберитесь, есть ли в ядре рантайм и какой, потом вернёмся к вопросу.
Я думаю, если rust будут использовать в ядре, то язык станет более востребованным. Соответственно есть все шансы на большую пополищацию данного языка.Само ядро хуже от этого врятли станет. Вопрос с переносимостью, раньше достаточно было переноса на платформу компилятора и минимум библиотек, теперь ещë нужно, что бы Rust там зарускался.
Вот, вот! И все это не про безопасность, а про запланироааное устаревание. Как еще более простимулировать людей к обновлению железа, тех которые даже в игры не играют? А давайте е*нем в ядро раст? Кто компилил огнелис тот в цирке не смеется.
Это мелклмягкие хотят писать драйвера на русте. Больше он никому практически не упал, элоп я не знаю где там его использует. Видимо хотят поэкспериментировать с брейнфаками в ядре прежде чем тащить их в свои проприетарные ос.
Брался за раст раза три с интервалом в год. Ну не могу проглотить я этот ужасный синтаксис... Но в ядре такая вещь, считаю, должна быть. Годнота ведь. Эх.. Вот бы у простого си или го такие фичи.
Фичастость в ядре не поможен. Там реальный структурный код, не ООП.
Cмотря что понимать под ООП
Тем не менее мы регулярно имеем баги/уязвимости с использыванием разыменования указателя, nil-указателя, переполнения буферов, стеков и прочих типичных си-ошибок, даже переписывание констант, практически во всех подсистемах линукса. Здесь уже на кривые руки автора не спишешь - если язык это позволяет, то где-то оно рано или поздно, намеренно или случайно всплывет.
Тем не менее не надо драматизировать. Чистый Си - это эталон в драйверостроении.
Утверждается, что ObjectiveC по ABI полностью совместим с этим чистым C. Т.е., я полагаю, что в ядре не должна требоваться какая-то специальная поддержка кода на ObjectiveC.
Звучит так, как будто Линус действительно заинтересован в поддержке раста.
Линуса просто скупили корпорации в рамках ЕЕЕ, это очевидно любому разбирающемуся человеку.Никто в сваём уме ни будит писать праграммы на rust, а тем болие едро.
надеюсь инициатива просто обосрёстся и на этом дело закончится
Пидаrustы, что они хотят сделать с ядром
Ну давайте все модные недоязыки в ядро запихнём
блин, читаю новости на опеннете и понимаю, что реально надо ставить другую операционку. перетаскивать на неё всё с линукса, фуууух, гемор. 2020 - реально паршивый год, а ещё только июль.
Выньдовз?
Даже не знаю, посоветуйте альтернативу. Я знаю, что в фряхе пилят поддержу wsl2 - это может быть оно, но если нет, то баш на виде тоже в принципе нормально работает. Плюс всегда можно запустить виртуальную.
Но внутри WSL2, всё равно, ядро Linux.
нет, внутри wsl2 hyper-v в котором запущено ядро другой ос. например freebsd.
> нет, внутри wsl2 hyper-v в котором запущено ядро другой ос. например freebsd.Где вы там оное нашли? :)
Зачем всё это? Вы можете использовать hyper-v, внутри которой запускать Windows 10
Могу посоветовать Redox, очень стабильная юникс лайк система, правда пакетов немного.
Думаю быстро с линукса пересядешь.
linuh хуже
Genode
Я уже давно использую Windows 10 и у меня всё работает замечательно. Никаких рустов и тому подобной гадости в ядре.
Переходите на windows 10, самую лучшую ос в мире.
Просыпайся, тролль, ты все проспал. Microsoft уже давно Rust обкатывает, а Linux только подтягивается. "Лучшая ос в мире" - ну ты толсто завернул, конечно)
О, да ты даже не подозреваешь, каких гадостей в твоей Windows 10 понапихано.
подключился: если хотите - пилите, но не здесь
Rust - это всего лишь статистический анализатор, встроенный в компилятор. Какие проблемы?
Rust - это всего лишь статистический анализатор, встроенный в компилятор LLVM. Не в GCC, а в LLVM.Договаривать надо, да? LLVM создается проприетарщиками. Rust is Not GNU.
А что думает о Rust товарищ Ричард Мэтью Столман?
"The nonfree compilers that are now based on LLVM prove that I was right -- that the danger was real"
https://metager.org/meta/meta.ger3?eingabe=supporting+LLVM+i...
У Rust не нон-фри компилятор.
>Линус не согласился и выразил опасение, что тогда начальная поддержка Rust окажется не протестированной на сборку и имеет риск завязнуть в своём болоте, в котором небольшая группа заинтересованных в проекте разработчиков проверяет работу кода только в своих специфичных условиях и добавляет неправильные вещи, так как они остаются спрятанными и не всплывают при тестировании ядра в других окружениях.Этот диагноз пославил Линус Торвальдс! Всё. Тема закрыта.
нестабильный компонент в системной сборке, прогрессивно накапливающий баги, вкусно, что уж
Опасаюсь, что вы слишком оптимистичны в этом вопросе.
> Этот диагноз пославил Линус Торвальдс! Всё. Тема закрыта.Это не диагноз а описание типового антипаттерна - и предложение на эти грабли не наступать.
Rust это что, такое оборудование такое, что его необходимо обрабатывать в ядре?
Если Rust включат в ядро то он станет гораздо популярнее. Это очень хорошо что язык с автоматическим управлением памятью без сборщика мусора и ориентированный на безопасность и скорость исполнения станет распространен.
Гнать растаманов ссаными тряпками!
> Гнать растаманов ссаными тряпками!Это слишком просто. Пусть сперва попашут над своим нафигнужным мусором, а когда задолбаются, можно вспомнить про этот пункт.
Ядро это вам не в бирюльки играть, пусть в другом месте попашут.
> Ядро это вам не в бирюльки играть, пусть в другом месте попашут.Ядерщики никогда не комплексовали по поводу выноса unsupported шмотков кода.
Когда читаю комментарии новостей о Rust, такое ощущение, будто пересматриваю "Зелёного слоника".