После полутора лет разработки опубликован выпуск операционной системы Redox 0.6, разработанной с использованием языка Rust и концепции микроядра. Наработки проекта распространяются под свободной лицензией MIT. Для тестирования Redox OS предложены готовые загрузочные образы (61 МБ). В отличие от прошлых выпусков, ветка 0.6 рассматривается как пригодная для экспериментов на реальном оборудовании, а не только в QEMU и VirtualBox...Подробнее: https://www.opennet.dev/opennews/art.shtml?num=54316
Великолепная ось на божественном языке!
Фроктааааал!
Он собирает шаблон "от утечек памяти".
Я удивлён что не нашёл заветных слов "Новость прислал: Fracta1L" )
при чём даже новость написал бы на Расте, тк тест на русском языке может содержать ошибки
Божественный язык - это лисп. Не смейте называть вашу смузинедоделку божественным.
Божественный язык -- машинный код.
Но да будет слово ваше: «да, да»; «нет, нет»; а что сверх этого, то от лукавого.
Евангелие от Матфея 5:37 – Мф 5:37
> Божественный язык - это лисп.<ссылка на xkcd>
И что в ней великолепного? Ни киберпунк ни автокад не запустить, даже блютуз наушники не работают. Оxepеть, такая великолепная, что вообще ничего сделать в ней нельзя - только включить, полюбоваться на рабочий стол и выключить.
Ждём нашествие растофобов
А std то на си почему-то написана. Ай-яй-яй. Ждём нашествия Си-фобов.
Что такое std?
Si table of dannye.
Кажется, тв только что поставил рекорд по "-"
Скорее всего это работа одного человека со скриптом. Наверное кому-то на больную мозоль наступил или ещё чего. Время от времени у совершенно случайных моих сообщений бывают такое вот необычное количество минусов.
sexually transmitted disease
Life?
А что их ждать, если одного unsafe достаточно, чтобы похерить все крики растовцев о Безапашности(тм)?
До сих пор помню, как затравили того автора, что для критических частей своего растового веб-сервера их заюзал (ради +150% к скорости) и огреб от токсичного растового коммунити.
Перед вами два стула, на одном производительность, а на другом - безопасность
Очень спорная аналогия с двумя стульями 😂😂😂
правильный ответ: сам сяду на производительность, а мать посажу себе на колени.
А просто взять и написать производительно и безопасно уже нельзя, ну совсем никак ? Разгневаются боги хрустоманов...
Возьму производительность и срублю безопасность
Три. Третий - удобство использования
Того автора затравили действительно из-за unsafe, но не от факта его наличия. А от того что данный unsafe ДЕЙСТВИТЕЛЬНО был не безопасен и автора за это чморили, а автор не мог быстро и красиво решить данную проблему без потери производительности.Как итог, автор свою проблему решил, с другим unsafe, другими вещами, а та уязвимость исправлена и производительность уже не 150% а гдето 140%:)
Получается что наличие unsafe в коде позволило выявить проблему безопасности? Потенциальное CVE. Ведь люди которые искали ошибки смотрели на блоки unsafe.Надо же, я думал что один unsafe написал в коде и все - считай что в С++ попал, а мог и не учить раст даже. НУ ничего, там наверно осталось полно утечек памяти, вот порадуюсь когда у кого-нибудь сервер крашнется. Когда-нибудь. Пусть и без privilege gain..
> А что их ждать, если одного unsafe достаточно, чтобы похерить все крики растовцев о Безапашности(тм)?Ансейф отключает некоторые проверки, но не все. Кроме того, небольшую ансейфовую часть легче проверить, чем когда вся программа - ансейф.
Если так все просто и ансейф теперь не совсем ансейф и вообще, его легко проконтролировать блоком, то простой вопрос: почему была такая травля того кодера? Использование вполне аргументированно и, как тут ты красиво поёшь, вообще ничего не меняет, как комарик укусит, то что так много злобы на него вылилось?
Да примерно по тем же причинам, по которым ты тут троллить пытаешься. Кто-то ЧСВ повышал.
> До сих пор помню, как затравили того автораА помните как Боинг затравили за 737MAX? Такая-же история: не будем ставить индикатор рассогласования датчиков углов атаки - напишем в инструкции как распознать ситуацию, пилоты умные, справятся.
Так и тут. Не буду ставить unsafe - умные программисты, которые будут дорабатывать мой код, определят нужные прекондишны без всяких unsafe и не будут стрелять в ногу пользователям.
Упустили предысторию.Давайте поставим более экономичные двигатели (большей степени двухконтурности) большего диаметра с минимальными затратами. Только они не влезают под крыло 737-го. Переделывать шасси дорого, поэтому вынесем их вперед, перед крылом. -> У самолета уплыл центр тяжести, и на продувках моделей он стал срываться в штопор на больших углах атаки. -> Ограничим углы атаки системой корректирующей тупых пилотов. -> Чтобы не переделывать тренажеры, и не переобучать летчиков, скажем что он ничем не отличается от предыдущего боинга. Профит!
Разбивается первый боинг! Причем летчики очень долго боролись с машиной, что явно видно. Скажем что, нужно было выполнить несколько простых действий. Летчики виноваты!
Разбивается второй боинг! Летчики выполнили указанные простые действия, и разбились в три раза быстрее.
Акции боинга упали. Отлично, начинаем самовыкуп акций. Все равно рынок скоро все забудет, акции возрастут, профит!
> Разбивается первый боинг! Причем летчики очень долго боролись с машиной, что явно
> видно. Скажем что, нужно было выполнить несколько простых действий. Летчики виноваты!Не совсем так. Команда летевшая на предыдущем рейсе (рейс перед крушением) замечает странное поведение стабилизатора высоты. Стабилизирует самолёт вручную и смотрит в quick reference handbook. Идентифицирует ситуацию как runaway stabilizer (идентифицирует неправильно, но описанные там действия позволяют исправить ситуацию), выполняет предписанные действия и сажает самолёт.
Техники проверяют стабилизатор, ничего не находят. Следующая команда замечает странное поведение стабилизатора высоты, несколько раз возвращает стабилизатор в нормальное положение с помощью ручного управления электроприводом стабилизатора (это прекращает работу MCAS на 10 секунд после каждого ручного воздействия). Потом, похоже, команда начинает паниковать: ручное управление приводом стабилизатора больше не трогают и пилот просто тянет штурвал на себя (стабилизатор как-раз нужен, чтобы снять нагрузку со штурвала). MCAS, которой теперь никто не мешает, перекладывает стабилизатор полностью на пикирование и пилотам не хватает силы противодействовать.
А действия простые - каждые 10 секунд дергать рычажок stab trim в направлении nose up, пока второй пилот листает quick reference handbook.
> А действия простые - каждые 10 секунд дергать рычажок stab trim в
> направлении nose up, пока второй пилот листает quick reference handbook.Этот самый рычажок находится на штурвале под большим пальцем левой руки. Снять нагрузку со штурвала - это часто используемое действие.
Я и не знал, что на опеннете есть даже пилоты боингов. Или их конструкторы.
Видел я этот момент. Сначала кто-то выкатил большущий тест http-клиентов на Расте, раскатал всех в стиле "все п-сы, а я д'Артаньян". Но актиксу реально сильнее всех досталось. Потом начилась дискуссия на гитхабе, где этот д'Артаньян продолжал раздувать гребешок, но большинство вроде были более-менее адекватны и спокойны. Тем не менее, одного оказалось достаточно, чтобы нормальный, но не стойких духом разработчик забросил довольно неплохой фреймворк.Жаль, если честно. С такими нервами это всё равно бы случилось рано или поздно, но жаль. Собственно, все эти Code of Conduits создаются, чтобы такое происходило пореже, а не ради черножизненной дичи.
Не, там вылез какой-то тип со стороны, не имеющий отношения ни к тестам, ни к актиксу, и выдал что-то вроде "Не хрен тебе на расте писать с такими замашками". Этому сообщению понаставили минусов, а в остальном цивильно убеждали автора актикса, что как-то нехорошо получается, надо бы поправить.
> В новой реализации удалось избавиться от утечек памятиА что их ждать, если даже сама новость намекает на некоторую фундаментальную дырявость и неспособность решать за проггера часть проблем, которые сабж типо_решает
>> В новой реализации удалось избавиться от утечек памяти
> А что их ждать, если даже сама новость намекает на некоторую фундаментальную
> дырявость и неспособность решать за проггера часть проблем, которые сабж типо_решаетСразу видно отличное знание матчасти и сути проблемы, как и отличное понимание принципов и нюансов работы и реализации ядерного менеджера памяти (это ведь типичная проблема всех местных экспертов в целом и жопоскриптозников в частности)!
Поэтому следует ценить это особо ценное мнение!
И откуда вы это помните, кто и через кого вам эту историю пересказал? По тону вашего комментария видно, что вы вообще не в курсе той истории, что там реально произошло.
>Ждём нашествие растофобовНашествие-то растофанов уже в самом разгаре.
Вот бы кто-нить сказал зачем это нужно.
А так непонятно?
Для популяризации языка как языка системного уровня.
Создания сообщества, стандартных библиотек, развития самого раста и т.д.Никто систему эту ставить на десктопы или серверы не будет. Сейчас это скорее как "я могу я сделаю!", чтобы позволить утвердится языку.
А если получится что-то хорошее, через лет 5 возможно уже будет у кого-то основной ОС.
> А если получится что-то хорошее, через лет 5 возможно уже будет у кого-то основной ОС.Я конечно за раст, и все такое, но 5 лет до основной ОС - это фантастика.
Что более реально за 5 лет - это как ОС в какой нибудь телек или другой умный гаджет. Что тем не менее будет офигенно.
Для этого им прийдется изучить нормальные языки программирования, чего не случится в ближайшие 5 лет, так что мечты
Если без написания ненужных ОС язык не может утвердиться, то это - ненужный язык. Иными словами - ненужный язык - это язык, от которого не зависит нужное ПО. К расту, к счастью, это не относится, на нём уже написаны тонны нужного ПО и один ненужный браузер-банкрот, который некому финансировать, потому что всем оплату рекламой и шпионажем подавай.
Чтобы доказать что язык можно использовать в других системах, мы не будем его использовать в других системах, а создадим свою ненужную систему которой никто не будет пользоваться. Видимо целевая аудитория должна поверить на слово что если водород работает в дерижабле, то и в самолёте будет работать точно также.
> А если получится что-то хорошее, через лет 5 возможно уже будет у кого-то основной ОС.И каждые полгода придется все переписывать наново, ввиду очередных ломающих совместимость изменений языка.
> Много времени при подготовке новой версии было потрачено на борьбу с нарушающими совместимость изменениями в ночных сборках Rust, связанными с переработкой макроса Asm.
Что значит никто не будет ставить на десктопы? Автор изначально её пилил для своего ноута, поскольку его не удовлетворял линукс.
> Вот бы кто-нить сказал зачем это нужно.Чтобы было. Тебе жалко что ли? Ну так займись тем, что нужно.
В документации сказано: https://doc.redox-os.org/book/ch01-05-why-redox.html
для убийства линукса
>сказал зачем это нужно.зря они распыляются на реальное железо. на сервере всё равно виртуализация в 99% случаев.
для того чтобы стремительным домкратом всех подвинуть на серверах достаточно было бы написать 1 путний webсервер, 1 dns-сервер и 1 субд.
> Вот бы кто-нить сказал зачем это нужно.Исходя из https://doc.redox-os.org/book/ch01-05-why-redox.html
этого:
> There are numerous places in the MINIX 3 source code where we would like to make changes,
> so many that perhaps a rewrite in Rust makes the most sense.Для того чтоб написать на хрусте.
для чего вообще все существует в этой реальности?
Вот оно будущее! Уже сейчас.
> утечек памяти, которые создавали проблемы
> стандартная Си-библиотека
> борьбу ... в сборках Rust ... макроса AsmЗнаете, что лишнее в этой недооси? Раст!
Её уже рассматривают как замену CentOS?
нет, только для фуксии с гармонью
Отличная новость.
Как там дела с производительностью? Это наверное единственно что сейчас актуально. Далее можно обсудить фракталов и целесообразность выбора языка, раз он позволяет такие фракталы, можно будет посчитать статистику относительно конкурентов.
На производительность микроядернвх ОС сильно влияют DAC, MAC. Пока их нет с производительностью все должно быть хорошо.
зачем писать все? почему не сделать свое ядро и libc нормально, а потом переписывать остальное?
Может быть это не очевидно, но делать новое проще чем сделать нормально или исправить и доделать старое (это вообще не реально).
если бы это было так, то природа давно реализовала бы этот подход массово. Но нет, эволюция рулит.
Эволюция действует более широкими категориями, на больших временных периодах. Миллионы никому не нужных проектов умирают на разных стадиях завершённости, люди же десятилетиями используют и подпирают сотнями костылей очевидно хреновые решения без возможности их исправить, поскольку любое исправление потребует большой вовлечённости десятков и сотен квалифицированных индивидуумов.
есть такое понятие как эволюционный тупик, тогда природа делает несколько шагов назад к другой ветке которая изначально вроде казалась менее жизнеспособной
Я не вижу как это применимо к разработке ПО. У нас нет столько ресурсов и возможностей.
возможностей не было 30 лет назад, сейчас программистов как собак не резанных, чем они все занимаются ? бабловыжиманием ? где тот энтузиазм создателя ? пока не проплатят то не пошевелим и пальцем для общего блага ?
Капитализм, детка. Кровавый совок захотели? Дак вы не по адресу.
Да совок в любом случае говно
Пишут веб сайты же
Пишут коменты
Вероятно даже точнее будет утверждать о многих тысячах и миллионах, рассматривая всю популяцию, поскольку придётся не только разработать и внедрить, но и убедить остальных, что это лучше и правильнее (а это возможно самое сложное).
на самом деле, природа это делает каждый раз, когда у одной матери появляется несколько детёнышей: такой себе природный форк, на случай если сиблинги зафейлятся.
> зачем писать все?just for fun?
> почему не сделать свое ядро и libc нормально, а потом переписывать остальное?
А зачем это делать последовательно? Если бы эту Redox пилил бы один программист, то ему бы может и было бы удобнее делать последовательно. Но программистов больше одного, возможна параллелизация усилий, а раз так то удобнее заниматься всем сразу, чтобы друг у друга под ногами не болтаться.
А ей разве нужна libc? Насколько я понимаю, для самой ОС и базового окружения не нужна, только что бы сторонний софт (который на Си) запускать.
> А ей разве нужна libc? Насколько я понимаю, для самой ОС и
> базового окружения не нужна, только что бы сторонний софт (который на
> Си) запускать.Да. Чтобы сторонний софт запускать. Было бы обломно иметь OC и не иметь под неё браузера, IDE и всех прочих прелестей. Но сейчас всё равно рано о чём-то говорить, они, как я понимаю, usb hid так и не поддерживают, поэтому клавиатуры/мышки не работают. Разве что искать доисторическое железо с PS/2.
>Было бы обломно иметь OC и не иметь под неё браузеравесьма тупо пилить микроядерную десктопную ось в условиях дикой конкуренции и непонимания 99.9% населения зачем дескпопной оси быть микроядерной.
линух свой успех с серверов начал, похоже редокс убьет идиотский маркетинг, а жaль
>>Было бы обломно иметь OC и не иметь под неё браузера
> весьма тупо пилить микроядерную десктопную ось в условиях дикой конкуренции и непонимания
> 99.9% населения зачем дескпопной оси быть микроядерной.Кому какое дело до 99.9%?
> линух свой успех с серверов начал, похоже редокс убьет идиотский маркетинг, а жaль
О каком маркетинге ты говоришь? Чтобы говорить о маркетинге, надо сначала заявить о каком-то преимуществе перед конкурентами. Какие преимущества редокс предлагает или мог бы предложить? Конкурировать с linux'ом на серверах? Хаха. С вендой на десктопах? Хахаха. С андройдом на мобилках? Это просто лол.
Редоксу нет никакой потенциальной ниши, кроме крacнoглaзых фанатиков, типа меня. И он на эту нишу очень неплохо заточен. Я с радостью соскочу с linux'а, который давно превратился в корпоративное уг, чья сложность зашкаливает из-за того, что корпоративное уг и из-за того, что он во всех бочках затычкой пытается быть. Который написан на окаменелом C. Вокруг которого сформировалось дебильное сообщество 99.9%, которые разницу между микроядерностью и монолитностью понимают на основании неполных пересказов исторического cpaча между Торвальдсом и Танненбаумом, и при этом не отличают убунты от линукса, а высшим достижением считают способность собрать LFS (впрочем 99.9% из них никогда даже не пытались). Оставшиеся 0.01% -- это старпёры типа местного поха, которые давно линукс используют для зарабатывания денег, и любые изменения экосистемы для них PITA, потому что перечёркивает их знания и навыки доведённые до рефлексов.
Я сегодня не хочу иметь ничего общего ни с линуксом, ни с его сообществом. Redox же -- позволяет уйти от C, используя его исключительно для легаси кода. Redox -- это не миллиарды строк кода, а гораздо меньше, разобраться в этом проще. Redox -- это дружелюбное сообщество. Просто няшка, ради которой можно потерпеть и отсутствующие драйвера. Я когда пришёл в linux, драйверов не было, и ничего, жил же как-то. Поживу и ещё.
> Редоксу нет никакой потенциальной ниши, кроме крacнoглaзых фанатиков, типа меня. И он на эту нишу очень неплохо заточен.хммм...
> Я сегодня не хочу иметь ничего общего ни с линуксом, ни с его сообществом.У вас противоречие тут закралось. Феномен фанатизма встречается именно и только лишь в рамках Linux и прочей религии вокруг него. Вам будет очень трудно найти такое в сообществах других ОС. Разве что только Apple...
Ни BSD, ни даже Windows от такого не страдают.> Я с радостью соскочу с linux'а, который давно превратился в корпоративное уг, чья сложность зашкаливает из-за того, что корпоративное уг и из-за того, что он во всех бочках затычкой пытается быть.
Справедливости ради, Linux очень плохо справляется со своей вновь приобретенной корпоративностью. Его сложность продиктована отсутствием стандартизации и автоматизации. То что в нем появилось - мало, а работает как попало, потому что нет архитектуры ОС.
> Который написан на окаменелом C.
А вот это одна из причин его убогости в корпоративном сегменте. Видите ли, корпоративный программист это такой человек, у которого все мысли и концепты объектно-ориентированы. Их речевой центр мозга превращает всё это не в звуковые сигналы, а сразу сериализирует в XML. Вместо рукопожатия используется SOAP Envelope. И вот у вас есть Linux написанный на С. Оно конечно годится для запуска JVM и даже свежего .NET 5, но работать с компонентами ОС. "Компонентами" сказал я, ха-ха. С зоопарком библиотек к которым надо линковаться без высокоуровнего API, если таковым не считать dbus, который фанатики не жалуют, да и сам он мягко говоря звёзд с неба не хватает. А еще люди на Linux на полном серьёзе пытаются писать софт на Python. Каждый раз переизобретая по 2-3 раза полурабочие биндинги к сишным либам для каждой версии своего несовместимого барахла. "Открытая система", блин. Когда куча софта в системе написана на питоне в котором маршалинг не происходит дальше локально установленного интерпретатора, а сериализация объектов не поддерживает нативно ни XML, ни даже JSON. Все через конвертацию и полный DOM. Зато есть либок 5-6 которые делают это наполовину и одинаково хреново. Своего SDK для С++ в Linux нет, если таковым не считать Qt, но вот только не понятно, зачем себя тогда через Linux наказывать... У Linux вообще нет SDK.
И всё же главная проблема, которая сдерживает развитие unix-like ОС - это не столько С, сколько POSIX.
Я в курсе что MS со своими WTF-16 помесями - это жесть, но setlocale... а какие там треды. А если setlocale и треды одновременно. И ACL, которые в нем не стандартизированы, но Linux их использует. Причем адепты культа реально уверены, что это стандарт. А на самом деле есть NT ACL - эксклюзивны для Windows. Псевдо-Posix ACL. Специфичные для Linux и то не обязательные. И есть NFSv4 ACL, которыми пользуются все остальные ОС. Из-за этого, кстати файлопомойку на Linux делают только дураки-фанатики.Я бы сообществу Rust пожелал от всей души не с С сражаться а с POSIX. Потому что эта штука не актуальна для разработки надёжного софта. Тут даже не столько в С дело. Вот подумайте сколько linux-программ на С обрабатывают ошибки malloc? Полтора землекопа? А со стороны ядра что при этом? Что-то адекватное возвращается. Нет. Memory overcommitment и потом полный OOM. И это воспитывает соответствующих программистов. Запросить 146GB памяти и форкнуться, а ОС потом разберется. А ОС она типа умная? Нет такая же. Методом тыка грохну что хочу.
Но ведь можно костылик написать, переподнимем процесс, который убивается OOM-киллером. А лучше напишем питон-скриптик перепинывания, сборки деплоя и сразу в докер. Это еще и полностью решает проблему полного отсутствия setup.exe. Ведь не пользователь должен решать, какой у него софт, не разработчик, которые его написал, а меинтейнер. Самая важная вахтёрша, суть которой собирать и поставлять софт в ОС, в которой нет стандартизации и автоматизации для развертывания консьмерского софта и поэтому разработчики не собирают одну программу под 500 несовместимых на пустом месте дистров, которые ломают совместимость с самими собой со следующим мажорным апдейтом. И вот вахтёрша решит, как правильно доставлять твой софт до пользователя и еще откажется это делать, потому что фильтрует софт по религиозно-лицензионным признакам. В корпоративной среде нужно еще свою вахтершу содержать для таких задач. Она думает о себе как об инженере, а на самом деле эникей по линуксу. Ой всё... я 15 лет это жрал. Просто уже подросло новое поколение фанбоев, а воз и ныне там.
> Я бы сообществу Rust пожелал от всей души не с С сражаться а с POSIX.Когда софт пишется на rust'е, POSIX не особо актуален. Если даже если он и есть где-то внизу под всеми абстракциями, он закопан глубоко. Rust использует utf8 в качестве внутренней кодировки. Под дефолту он предполагает, что внешняя тоже utf8. Я к тому, что тут и бороться-то особо не нужно.
> Вот подумайте сколько linux-программ на С обрабатывают ошибки malloc? Полтора землекопа?
Их очень сложно обрабатывать осмысленно. Когда malloc обломался, значит что и следующий malloc не пройдёт. Когда malloc обломался, значит что у системы не осталось свободной памяти. Разадресация нуля, как способ прибить программу -- это вполне себе способ. Я сталкивался с аргументацией о том, что именно так и надо, потому как при отсутствии свободной оперативки крайне сложно что-то осмысленное делать, даже упасть контролируемо сложно.
То есть, может быть как-то можно сделать иначе, но это нужен какой-то другой подход к менеджменту виртуальной памятью. Общесистемно другой, и я даже не представляю какой. Я лишь из самых общих соображений допускаю, что как-то можно сделать лучше.
> Это еще и полностью решает проблему полного отсутствия setup.exe. Ведь не пользователь должен решать, какой у него софт, не разработчик, которые его написал, а меинтейнер.
Это, как раз, мне кажется правильным -- программиста вообще надо от пользователя отстранять как можно дальше, и втыкать между ними специально обученных людей, которые умеют общаться и с программистом, и с пользователем, потому как программист умеет писать программы, а вот UX обеспечивать -- нет. Бывают исключения, но они именно что исключения. Вот то, что стандартизация осталась на уровне наколенной поделки никому неизвестного финского студента, вот это реально плохо.
Добра :3
Если там будет нормальный GUI и жрать будет ресурсов хотя бы как WIN XP, то в пекло все эти разжиревшие Линуксы в которых без командной строки работать практически невозможно. А вообще тут все переходят на ARM и если ребята впишутся в этот переход могут солидную долю рынка у Мелкософта отжать. Ну и без мобильной версии тоже никак.
> на окаменелом сПока лучше языка то и нет. Уже и не помню, когда у меня с ним были проблемы с той же паятью или еще с чем либо. Каких-то вещей не хватает, например сдвигов. Просто есть задачи, которые на чем то другом писать бессымсленно.
>> А ей разве нужна libc? Насколько я понимаю, для самой ОС и
>> базового окружения не нужна, только что бы сторонний софт (который на
>> Си) запускать.
> Да. Чтобы сторонний софт запускать. Было бы обломно иметь OC и не
> иметь под неё браузера, IDE и всех прочих прелестей. Но сейчас
> всё равно рано о чём-то говорить, они, как я понимаю, usb
> hid так и не поддерживают, поэтому клавиатуры/мышки не работают.Значит они всё правильно делают. Кто-то пишет ядро, потому что может. Кто-то занимается прослойками совместимости с существующим софтом, а в ядро не лезет раньше времени.
> Разве что
> искать доисторическое железо с PS/2.Есть и новое такое. Но там, вероятно, и остальное поддерживается примерно на том уровне.
> Есть и новое такое. Но там, вероятно, и остальное поддерживается примерно на
> том уровне.Это даже по фану. Можно написать драйвер для своей сетевушки. Поддержка usb hid -- это уровень абстракции, чтоб его написать надо быть высоколобым разработчиком понимающим принципы ядра, под которые это делается. А драйверок запилить по аналогии с существующим -- это и Васян из 9б справится.
> только что бы сторонний софт (который на Си) запускатьНе который на Си, а который подгружает libc и делает вызовы к его фукнциям. Это можно сделать на любом языке, который умеет C ABI FFI.
>> только что бы сторонний софт (который на Си) запускать
> Не который на Си, а который подгружает libc и делает вызовы к
> его фукнциям. Это можно сделать на любом языке, который умеет C
> ABI FFI.Вы готовы показать ссылку на проект "который подгружает libc", а не слинкован с ней статически, поскольку у того "любого языка" рантайм написан на Си?
> Вы готовы показать ссылку на проект "который подгружает libc", а не слинкован с ней статически$ ldd /bin/ls
libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x00007fcccfb9f000)> поскольку у того "любого языка" рантайм написан на Си
Этот пункт не понял. Почему у языка рантайм должен быть на Си, при чём тут это? Берём любой язык и делаем из него вызов к libc.so, при этом без разницы что за язык и какой у него рантайм. Это просто вызов функции произвольной динамической библиотеки, что на Линуксе что на Винде.
>> Вы готовы показать ссылку на проект "который подгружает libc", а не слинкован с ней статически
> $ ldd /bin/ls
> libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x00007fcccfb9f000)Здесь "погружает" не ls, а системный загрузчик (ld-linux), выполняя динамическое связывание. ls начинает исполняться после этой фазы. Если бы ls подгружал, там происходил бы вызов функции dlopen(), примерно как в man dlopen. Но есть нюанс. libdl.so сама импортирует libc.so, а значит опять всё сделал системный загрузчик.
Если подходить формально, мой вопрос содержит ошибку ("статически"), за которую Вы ухватились. По существу, она ничего не меняет, от техники связывания поведение не изменится: libc в обоих случаях загружена и инициализирована до вызова точки входа (и тем более main()) из ls.
Наверное, Вы имели ввиду "использует libc".
>> поскольку у того "любого языка" рантайм написан на Си
> Этот пункт не понял. Почему у языка рантайм должен быть на Си,
> при чём тут это?Он не должен. Но почему-то по факту так (не всегда, но примеров пока нет).
> Берём любой язык и делаем из
> него вызов к libc.so, при этом без разницы что за язык
> и какой у него рантайм. Это просто вызов функции произвольной динамической
> библиотеки, что на Линуксе что на Винде.Вот, уже без "подгружаем", а просто "делаем" вызов... софта на Си, к которому "любой язык" сбоку прикручен системным загрузчиком, который тоже на Си.
> Вот, уже без "подгружаем", а просто "делаем" вызов... софта на Си, к которому "любой язык" сбоку прикручен системным загрузчиком, который тоже на Си.Не понимаю про что спорим. Да, с dlopen() я перепутал, чё с меня взять - я тупой жавер, а не сишник - я ваще не должен знать разницы между "сокетом" и "процессом" (это один чел в Мейлру так однажды пошутил про жаверов).
Смысл в том, что вызов к libc.so может сделать любой процесс, не важно из какого языка он скомпилен. И этому процессу будет также не важно, какая у libc реализация - его интересуют только сигнатуры функций и поведение по контракту. О чём я и говорю - libc нужен программам, которые пользуются этим API и не более. На редоксе этот API предоставляется через relibc, на линуксе через GNU libc. Ещё бывает musl. И так далее. При этом программам под редокс либц может быть вообще не нужен, т.к. между ядром и программой используется другая обёртка над этим ядром. А может быть и ваще без обёртки - херач сразу сисколлы и не горюй, на расте для линуксовых сисколлов тупо есть либа, как есть либа для сисколлов виндовых.
>> Вот, уже без "подгружаем", а просто "делаем" вызов... софта на Си, к которому "любой язык" сбоку прикручен системным загрузчиком, который тоже на Си.
> Не понимаю про что спорим.В том-то и дело. Вы сами начали оспаривать мой тезис "нужна libc ... что бы сторонний софт (который на Си) запускать". Я могу к нему добавить, что Glasgow Haskell Compiler транслирует в Си, MLton транслирует в Си, ocamlopt транслирует в машинный код, но рантайм всё равно там на Си. Рантайм Perl и Python наверняка на Си, но я сам не смотрел. Потому мне интересно, есть ли какие-то примеры, не гипотетическая возможность, а факты.
> Да, с dlopen() я перепутал, чё с
> меня взять - я тупой жавер, а не сишник - я
> ваще не должен знать разницы между "сокетом" и "процессом" (это один
> чел в Мейлру так однажды пошутил про жаверов).
> Смысл в том, что вызов к libc.so может сделать любой процесс, не
> важно из какого языка он скомпилен.Интересно, в частности, зачем таким проектам вообще нужна libc, если у них свой рантайм.
> При этом программам под редокс
> либц может быть вообще не нужен, т.к. между ядром и программой
> используется другая обёртка над этим ядром. А может быть и
> ваще без обёртки - херач сразу сисколлы и не горюй, на
> расте для линуксовых сисколлов тупо есть либаВот видите, самодостаточным языкам не нужна libc, они и так работают.
> как есть либа для
> сисколлов виндовых.Это очень печальный звоночек, если там действительно используются "сисколы" (вектора которых меняются), а не ntdll.dll (или kernel32.dll).
> есть ли какие-то примеры, не гипотетическая возможность, а фактыИзвините, я наверно туплю. Примеры чего? Софта на Си, которому не нужен libc? Или софта не на Си, которому не нужен libc? Ясен пень есть - ядро любой операционки, к примеру. Оно не может зависеть от libc, потому что libc сам зависит от вызовов к ядру. Или какой-нибудь эмбед. Плюс скорее всего виндовым программам оно не нужно, у винды свой API к ядру. Хотя для винды, безусловно, есть реализация libc.
Кстати пишут, что Golang ваще игнорирует libc, и что на Линуксе, что на Винде сам обращается к ядру через системные вызовы.
> Интересно, в частности, зачем таким проектам вообще нужна libc, если у них свой рантайм.
Не знаю.
> Вот видите, самодостаточным языкам не нужна libc, они и так работают.
Да я в курсе... опять не понимаю, к чему это? Я что, говорю, что программам, которым не нужен libc - нужен libc?
> Это очень печальный звоночек, если там действительно используются "сисколы" (вектора которых меняются), а не ntdll.dll (или kernel32.dll).
Это я фигню написал - да, там обёртка над kernel32.dll.
>> есть ли какие-то примеры, не гипотетическая возможность, а факты
> Извините, я наверно туплю. Примеры чего? Софта на Си, которому не нужен
> libc? Или софта не на Си, которому не нужен libc?С Вами каши не сваришь... Вы же сами начали оспаривать мой тезис. Наверное, у Вас должны быть какие-то примеры, способные его (мой тезис) опровергнуть? Вот их и хотелось бы посмотреть.
> Ясен
> пень есть - ядро любой операционки, к примеру. Оно не может
> зависеть от libc, потому что libc сам зависит от вызовов к
> ядру. Или какой-нибудь эмбед. Плюс скорее всего виндовым программам оно не
> нужно, у винды свой API к ядру. Хотя для винды, безусловно,
> есть реализация libc.Речь шла о запуске прикладного софта под Redox. Пример с ядром не подходит.
> Кстати пишут, что Golang ваще игнорирует libc, и что на Линуксе, что
> на Винде сам обращается к ядру через системные вызовы.$ ldd `which go`
linux-vdso.so.1
libpthread.so.0 => /lib64/libpthread.so.0
libc.so.6 => /lib64/libc.so.6
/lib64/ld-linux-x86-64.so.2>> Интересно, в частности, зачем таким проектам вообще нужна libc, если у них свой рантайм.
> Не знаю.
>> Вот видите, самодостаточным языкам не нужна libc, они и так работают.
> Да я в курсе... опять не понимаю, к чему это? Я что,
> говорю, что программам, которым не нужен libc - нужен libc?Вы говорите, что "подгружает libc и делает вызовы к его фукнциям". Я думал знаете, зачем.
> Речь шла о запуске прикладного софта под Redox.relibc - реализует API libc для ядра редокса. Программы, написанные под libc при этом могут работать на редоксе. Поэтому relibc - полезен. При этом сами программы могут быть написаны не на Сях. Я писал про это. Например, они могут быть написаны на Расте, т.к. std Раст-а на линуксе использует libc. А может и не использовать, если сделать реализацию std, которая минуя API libc, напрямую обращается к API redox-а.
> $ ldd `which go`
Не компилятор, а программы, скомпилированные Golang. Сам не проверял, но пишут, что оно так.
> Вы говорите, что "подгружает libc и делает вызовы к его фукнциям". Я думал знаете, зачем.
Любая программа, если она использует libc - использует libc. Либо он статически прилинкован в бинарь, либо подгружается динамически - не важно, изнутри через dlopen или снаружи через механизмы ОС. В чём вопрос?
>> Речь шла о запуске прикладного софта под Redox.
> relibc - реализует API libc для ядра редокса. Программы, написанные под libc
> при этом могут работать на редоксе. Поэтому relibc - полезен. При
> этом сами программы могут быть написаны не на Сях. Я писал
> про это. Например, они могут быть написаны на Расте,Ясно, примеров нет и не будет.
>> $ ldd `which go`
> Не компилятор, а программы, скомпилированные Golang.https://go.googlesource.com/go/+/refs/heads/master/src/built...
$ ldd `which gitea`
linux-gate.so.1
libdl.so.2 => /lib/libdl.so.2
libpthread.so.0 => /lib/libpthread.so.0
libpam.so.0 => /lib/libpam.so.0
libc.so.6 => /lib/libc.so.6
/lib/ld-linux.so.2> Сам не проверял, но пишут, что
> оно так.Убедили.
>> Вы говорите, что "подгружает libc и делает вызовы к его фукнциям". Я думал знаете, зачем.
> Любая программа, если она использует libc - использует libc. Либо он статически
> прилинкован в бинарь, либо подгружается динамически - не важно, изнутри через
> dlopen или снаружи через механизмы ОС. В чём вопрос?У меня больше нет к Вам вопросов.
> Ясно, примеров нет и не будет.Примеров чего? Я устал уже пытаться угадать то, что вы имеете ввиду. Каждый раз предлагаю несколько вариантов, и ни разу не получаю подтверждения вида "да, я вот именно это имею ввиду". Попробую угадать ещё раз:
- Интересует пример программы, написанной на Расте, но использующий libc? Это - практически все программы, написанные на Расте под Линукс, т.к. растовкий std для Линукса подстроен над libc
- Или неиспользующие libc, но при этом под Линукс? Таких не знаю, и скорее всего если они есть, то очень мало, просто потому, что это бессмысленно - отказаться от std, но при этом написать что-то полезное? Хотя технически это возможно, т.к. для Раста делают кучу no_std библиотек, т.е. таких, которые не зависят от растовского std. Обычно их делают для эмбеда, но ничто не мешает применять их (и применяют) в любом окружении. Более того, считается, что если твоя либа no_std - то это более козырно, чем если она не-no_std, т.к. её переиспользуемость повышается.
- Или интересуют программы под Редокс, которые используют напрямую редоксовское API, но при этом опционально могут для чего-то вызвать ещё и relibc? Вообще без понятия, это ж фактически research-проект, под который очень мало чего есть, а уж тем более найти человека, которые оттуда какие-то практические примеры знает - это надо очень постараться. Но опять-таки, чисто из технического устройства ничто такому подходу не противоречит.
- Или какой-то другой вариант? Сформулируйте чётко, тогда будет конкретный ответ.
> $ ldd `which gitea`
Оно будет залинковано на libc если собиралось через cgo, а не go. Кроме того, пишут, что до версии го 1.5 оно линковалось к libc ради DNS-а, но потом и это выпилили. У меня стоит по-моему ровно одна программа, написанная на го - docker, и оно "not a dynamic executable". Можно конечно предположить, что либц там просто внутри, но я натыкался на высказывание о том, что Гугл именно сам для го запилил обращение к сисколлам, и либц они вообще не используют, кроме каких-то частных случаев, а то и вообще без.
> У меня больше нет к Вам вопросов.
Да это ради бога. :)
> Кроме того, пишутЗабейте. Вы ещё предыдущим своим сообщением убедили меня, что верить Вам не стоит. Остальное не читал, извините, что не ответил.
> убедили меня, что верить Вам не стоитВерить? Мда, худшее, что я ожидал для себя из данной дискуссии - это мне бы предоставили контр-аргументы доказывающие, что я неправ. Ну постыдился бы немного, сказал бы спасибо за объяснения и ушёл просветлённым. А вы мне про веру. Ну мы же не в церкви, при чём тут вера? Я, правда, так и не понял что именно вы хотели узнать, и все мои попытки это выяснить, уточняющие вопросы и так далее были проигнорированны. Так что видимо и предмета разговора нет.
>> убедили меня, что верить Вам не стоит
> Верить? Мда, худшее, что я ожидал для себя из данной дискуссии -
> это мне бы предоставили контр-аргументы доказывающие, что я неправ.Во-первых, что бы я с Вами дискутировал, Вам необходимо понимать, о чём вообще речь: что такое связывание, как оно работает, порядок загрузки модулей и так далее.
Во-вторых, бремя доказательства исходного Вашего утверждения лежит на Вас. Достаточно было привести хоть один пример, но Вы решили поиграть в игру "и чо?"
> исходного Вашего утвержденияКакого?
>> исходного Вашего утверждения
> Какого?Перечитайте ветку, коль с памятью плохо.
> Вот, уже без "подгружаем", а просто "делаем" вызов... софта на Си, к
> которому "любой язык" сбоку прикручен системным загрузчиком, который тоже на Си.
hexdump -C /libexec/ld-elf.so.1 | (head -n3 ;tail)
00000000 7f 45 4c 46 02 01 01 09 00 00 00 00 00 00 00 00 |.ELF............|
00000010 03 00 3e 00 01 00 00 00 00 90 00 00 00 00 00 00 |..>.............|
00000020 40 00 00 00 00 00 00 00 d8 47 02 00 00 00 00 00 |@........G......|
00024c50 00 00 00 00 00 00 00 00 aa 00 00 00 01 00 00 00 |................|
00024c60 30 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |0...............|
00024c70 48 46 02 00 00 00 00 00 da 00 00 00 00 00 00 00 |HF..............|
00024c80 00 00 00 00 00 00 00 00 01 00 00 00 00 00 00 00 |................|
странный какой-то Cи. Наверное, новый стандарт.
>[оверквотинг удален]
> 00024c50 00 00 00 00 00 00 00 00 aa
> 00 00 00 01 00 00 00 |................|
> 00024c60 30 00 00 00 00 00 00 00 00
> 00 00 00 00 00 00 00 |0...............|
> 00024c70 48 46 02 00 00 00 00 00 da
> 00 00 00 00 00 00 00 |HF..............|
> 00024c80 00 00 00 00 00 00 00 00 01
> 00 00 00 00 00 00 00 |................|
>
Бывает нечто, о чем говорят: «смотри, вот это новое»; но это было уже в веках, бывших прежде нас.
Figure 3-11: ELF header
char magic[4] = "\177ELF";// magic number
char class; // address size, 1 = 32 bit, 2 = 64 bit
char byteorder; // 1 = little-endian, 2 = big-endian
char hversion; // header version, always 1
char pad[9];
short filetype; // file type: 1 = relocatable, 2 = executable,
// 3 = shared object, 4 = core image
short archtype; // 2 = SPARC, 3 = x86, 4 = 68K, etc.
int fversion; // file version, always 1
int entry; // entry point if executable
int phdrpos; // file position of program header or 0
int shdrpos; // file position of section header or 0
int flags; // architecture specific flags, usually 0
short hdrsize; // size of this ELF header
short phdrent; // size of an entry in program header
short phdrcnt; // number of entries in program header or 0
short shdrent; // size of an entry in section header
short phdrcnt; // number of entries in section header or 0
short strsec; // section number that contains section name strings
(с) Linkers & Loaders by John R. Levine
>> странный какой-то Cи. Наверное, новый стандарт.
> Бывает нечто, о чем говорят: «смотри, вот это новое»; но это было уже в веках, бывших прежде нас.
> Figure 3-11: ELF header
> char magic[4] = "\177ELF";// magic number...
> (с) Linkers & Loaders by John R. LevineНу вот видишь - совсем не сишка.
>>> странный какой-то Cи. Наверное, новый стандарт.
>> Бывает нечто, о чем говорят: «смотри, вот это новое»; но это было уже в веках, бывших прежде нас.
>> Figure 3-11: ELF header
>> char magic[4] = "\177ELF";// magic number
> ...
>> (с) Linkers & Loaders by John R. Levine
> Ну вот видишь - совсем не сишка.Даже и не знаю, что сказать Вам по этому поводу... Представьте себе конфету. Шоколадную. Вы же вкушаете её без фантика, верно? Потому она из какао, а не из бумаги с фольгой.
Ну и вот. Кстати, вместо "статически" в моём вопросе выше должно быть другое слово.
интересно сравнить с ReactOS, который давно и неспешно пилится на языке Си
...которая ограничена снаружи закостенелой мвязкой WinNTs + WinNTApi + Common WinAPI и спецификой проекта как свободного внешнего клона для запуска РЕ?Сравнивать надо бы с какой-нибудь сисярп-ос (как она там называлась?), где подобного нету, а так же встроен фреймворк, сборщик мусора, и менеджер модулей (не путать с пакетами для софта)
как там дела с беткой?
> интересно сравнить с ReactOS, кНельзя сравнивать, реакт пытается реализовать стандарты и быть совместимой. Суть редоха в нескучных сисколах, и этим все сказано.
интереснее с haiku os например
Монолитные ядра быстрее. Если в микроядерной системе упадет планировщик процессов или файловая система или сетевой стек, что толку будет от работающего ядра?
Микродро может их перезапустить, вспоминаем дедушку Таненбаума и Миникс его.
Только концепция дедушки как-то не прижилась и на то были причины.
> Эндрю Таненбаум, труды которого в своё время вдохновили Линуса Торвальдса на создание ядра Linux, опубликовал открытое письмо к компании Intel, в котором высказал благодарность за использование операционной системы MINIX в составе прошивки чипа Intel ME 11 (Management Engine). Intel ME 11 поставляется во всех современных ПК и ноутбуках с процессорами Intel, что делает MINIX наиболее широко используемой ОС в мире.+ Google Fuchsia
+ Huawei HarmonyOS
+ QNXЯ бы не сказал, что совсем уж не прижилась.
>Google FuchsiaЕщё не родилась, а уже сдохла
>Huawei HarmonyOS
Назло маме отморожу импортозамещение
>QNX
Сдохла вместе с Blackberry, несмотря на полтора мегаспецзакрытых девайса, которые её пытались пользовать.
Примеры так себе, если честно.
QNX используется почти всеми ведущими производителями автомобилей.
не разрушай его карточный домик
Да лана, в моей калине нет никакого куникса
В автопроме сейчас используется Automotive Grade Linux (AGL).
Ты не путай магнитолку с автопилотом.
аПтопилот вообще на ubuntu (лук ат тесла)
> аПтопилот вообще на ubuntu (лук ат тесла)У тесла есть рабочий (в реальности, а не сказках маркетолухов) автопилот? Да еще и на бубунте? Ну-ну.
Версия 7.0 выпущена в марте 2017 года, 7.1 в июле 2020. Она точно живая такими темпами? Или просто на столько совершенна, что не требует улучшений и исправлений больше 3 лет?
Это-ж не линух.
Не все банкоматы на Windows XP. Есть же QNX.
У нас в Украине ПриватБанк начинает внедрять в банкоматы Linux. Нахрена им старый QNX
> MINIX -ОС в составе *прошивки* [определенного набора ревизий, к которому можно сделать harend] чипа Intel ME 11. Прекрасно работает как firmware И как обучающее наглядное пособие из книги Танненбаума "Опыт Создания ОС или сказ о том, на какие грабли девелоперы уже наступили", на десктопе для общих задач неприменима.
> QNX -RTOS для *прошивок*, Скорее мертва, по разработке. Прекрасно работает как firmware для требовательных железок, легко hardend'ится, но на десктопе для общих задач неприменима
> Google Fuchsia -Пре-пре-пре-альфа концепт, о будущем которого гугл говорит, как для firmware IoT и мобильных *потребительских устройств*, заменяя собой связку луникс+jwm. Позиционируется как неотъемлимая часть монолитного блоба прошивки, где рут есть только у сервисника и црушника (в этом фатальный недостаток ляликса - там рут получить сравнительно легко, приходится извращаться с бутлоадерами и А/В-разделами с постоянной проверкой чексумм всего и вся)
> Huawei HarmonyOS -Пре-пре-пре-альфа концепт, о будущем которого хуавей говорит, как для firmware IoT и мобильных *потребительских устройств*, заменяя собой потенциально запрещенную к поставке торгово-экспортной комиссией штатов связку луникс+jwm. Позиционируется как неотъемлимая часть монолитного блоба прошивки, где рут есть только у сервисника и кагэбиста (оба члены КПК и ККА не ниже лейтенанта в звании) (в этом фатальный недостаток ляликса - там рут получить сравнительно легко, приходится извращаться с бутлоадерами и А/В-разделами с постоянной проверкой чексумм всего и вся)
> GNU HURD + 100500 других микроядерных ОС - или свободная реплика миникса, или студенческие поделки без сферы применения.-------------------------
Все из них ИЛИ есть ранние proof-of-concept, ИЛИ имеют очень-очень узкую нишу и как правило, требуют заточки под железо. Макинтош не предлагать, там та же самая проблема с работой кекстов.
-------------------------
Такое вот себе, не думаю, что имей микроядра прямо такие киллер-фичи перед гибридами или монолитами, то не имели бы они свою долю рынка.
картинка с профессором Преображенским и риторическим вопросом>>>не думаю, что имей микроядра прямо такие киллер-фичи перед гибридами или монолитами, то не имели бы они свою долю рынка.
товарищ, скокатибелет?
уже годам к 20 - 25 любому прямоходящему и регулярно занимающемуся высшей нервной деятельностью сапиенсу должно быть очевидно из опыта, данного ему в ощущениях, что киллер-фич для ПО есть всего три:
1. киллерфича просто скопировать
2. киллерфича недорого или нисколько стоить
3. киллерфича просто пользоватьсяна этих киллерфичах выросли микрософт, гугель, япель, линуксь и амозонт.
все остальные киллерфичи - мнимые величины. гибриды-хрениды, монолиты-шмонолиты.
это все, разумеется, для массового ни за что не отвечающего ПО. там, где подразумевается хоть какая-то ответственность типа выплат по страховке, наблюдаем внезапно куникс, как в автопроме. или аду, как в ввс сша.
Сказать-то что хотел?
что ты букв не знаешь
Ты бы это... завязывал бы уже с веществами.
Недавно выпустили вторую версию DevKit HarmonyOS, саму операционную систему уже полностью показали, в Китае доступен закрытый бета тест, уже продают телевизоры с HarmonyOS на борту.
Хорошо что напомнили об этом.```
1 мая 2017 года корпорация Intel подтвердила и исправила в своей прошивке Management Engine[23] ошибку удаленного повышения привилегий (CVE-2017-5689), наличие которой давно предполагалось членами сообществ Coreboot и Libreboot[24][25]. Каждая платформа Intel с любой из технологий Intel Standard Manageability, Active Management Technology или Small Business Technology и с микроархитектурой центрального процессора от Nehalem (2008) до Kaby Lake (2017) содержит «дыру безопасности» с удаленным взломом в IME (Intel Management Engine)[26][27]. Ещё одним предполагаемым риском безопасности в IME является технология Intel vPro cellular radio[28], с помощью которой аппаратные компоненты могут быть доступны удаленно или компьютер может даже быть поврежден, однако нет никаких доказательств, что такая способность существует в самом чипе (vPro предназначен для использования службами внешних радиоустройств, отчего и пошел этот слух)[29].
```
Источник https://ru.wikipedia.org/wiki/Libreboot
> ... были причины.именно что были. А сейчас куда не плюнь попадешь то в песоцницу, то в контейнер какой или вообще в виртуалку.
Миникс же в каждом проце от интел, шпиенит за вами прямо сейчас.
Очень даже прижилась.
И открыт NetSurf (С) с SDL2 (С) backend'ом. Libc у них тоже на С?)
> NetSurf (С) с SDL2 (С)то есть их надо переписывать просто потому что ты сказал? они ОС пишут, а не всё-всё-всё, на всё-всё-всё пяти землекопов не хватит, даже если цель переписать будет
> Libc у них тоже на С?
на 35%, остальное на расте
relibc is a portable POSIX C standard library written in Rust.
Вызовы ядра на C, Карл, потому что на расте это сделать невозможно.
> Вызовы ядра на C, Карл, потому что на расте это сделать невозможно.Ты обо*рался. Причем аж два раза.
https://github.com/torvalds/linux/blob/fcadab740480e0e0e9fa9...
static inline long stub_syscall2(long syscall, long arg1, long arg2)
{
long ret;__asm__ volatile (__syscall
: "=a" (ret)
: "0" (syscall), "D" (arg1), "S" (arg2) : __syscall_clobber );return ret;
}
https://github.com/kmcallister/syscall.rs/blob/master/src/pl...
#[inline(always)]
pub unsafe fn syscall2(n: usize, a1: usize, a2: usize) -> usize {
let ret : usize;
asm!("syscall" : "={rax}"(ret)
: "{rax}"(n), "{rdi}"(a1), "{rsi}"(a2)
: "rcx", "r11", "memory"
: "volatile");
ret
}
Ассемблерная вставка внутри unsafe это эталон безопасности.
> Libc у них тоже на С?)libc сложно написать без C, потому что libc наполовину состоит из заголовков для C.
Их libc является rust + c.Вызовы ядра просто на C, а все остальное покрыто безопасными обертками, кодом и все только на расте.
> покрыто безопасными оберткамивот только почему-то были утечки памяти на расте :)
>> покрыто безопасными обертками
> вот только почему-то были утечки памяти на расте :)О, подтянулись очередные зксперты. Не было там "утечки памяти на расте" - просто нужно читать глазками, а не опой и знать хотя бы азы низкоуровневщины, а не только JS с питончиком.
Memory leaks are memory safe! И хотя это кажется абсурдным, но это правда.
Весьма бесполезная штука конечно, но как proof of concept низкоуровневой системности Хруста - маст хэв!
> . В новой реализации удалось избавиться от утечек памяти, которые создавали проблемы при использовании старого менеджера памяти.Оно же не течёт???
Это как с консервативными сборщиками мусора или обычной кучей. Они как бы не текут, но иногда память заканчивается, поскольку дефрагментировать не удаётся.
Что ты там дефрагментировать в куче собрался, дефрагментатор мамкин?
Вы того? Не знаете как организуется память в оперативной памяти? Понятно, понятно.
Я, вообще-то, сам писал сборщики мусора и очень хорошо знаю как оно работает. Ну так что там аноним дефрагментировать собрался?
Вы, наверное, слишком много пишете последнее время, и код через чур сложный, а уже конец года, это всё равно что релизить ночью в пятницу...Куча сама "дефрагментируется" https://www.opennet.dev/openforum/vsluhforumID3/122777.html#250
и возможно намудрить с последовательностью alloc() free() так, что слияние при освобождении части кучи окажется невозможным. На это и был намёк у меня изначально. Но я не заявлял, что являюсь менеджером кучи и буду дефрагментировать за него. Если хотите, что бы именно "дефрагментация" было написано, извольте, тоже про память:/*
* The defrag ratio allows a configuration of the tradeoffs between
* inter node defragmentation and node local allocations. A lower
* defrag_ratio increases the tendency to do local allocations
* instead of attempting to obtain partial slabs from other nodes.
*
* If the defrag_ratio is set to 0 then kmalloc() always
* returns node local objects. If the ratio is higher then kmalloc()
* may return off node objects because partial slabs are obtained
* from other nodes and filled up.
*
* If /sys/kernel/slab/xx/remote_node_defrag_ratio is set to 100
* (which makes defrag_ratio = 1000) then every (well almost)
* allocation will first attempt to defrag slab caches on other nodes.
* This means scanning over all nodes to look for partial slabs which
* may be expensive if we do it every time we are trying to find a slab
* with available objects.
*//*
* By default, transparent hugepage support is disabled in order to avoid
* risking an increased memory footprint for applications that are not
* guaranteed to benefit from it. When transparent hugepage support is
* enabled, it is for all mappings, and khugepaged scans all mappings.
* Defrag is invoked by khugepaged hugepage allocations and by page faults
* for all hugepage allocations.
*/
> Я, вообще-то, сам писал сборщики мусора и очень хорошо знаю как оно работает.Хорошо будешь знать после того, как сам напишешь malloc.
Иногда надо запускать программы дефрагментации, чтоб память быстрее была. Там красные квадратики инода появляются, надо чтоб они были синие и желтых не должно быть, но это когда свежеотформатированная память .
> быть, но это когда свежеотформатированная память .а это надо компьютер после выключения заземлять хотя бы минут 15 в выключенном состоянии, чтобы заряд из ячеек памяти как следует ушел, тогда форматировать не обязательно. у меня 16 гиг памяти, это часа два форматируется на ddr3, а если мемтестом форматировать, то еще дольше.
Chunks of memory are maintained using a `boundary tag' method as
described in e.g., Knuth or Standish. (See the paper by Paul
Wilson ftp://ftp.cs.utexas.edu/pub/garbage/allocsrv.ps for a
survey of such techniques.) Sizes of free chunks are stored both
in the front of each chunk and at the end. This makes
consolidating fragmented chunks into bigger chunks very fast. The
size fields also hold bits representing whether chunks are free or
in use.
> Иногда надо запускать программы дефрагментации, чтоб память быстрее была.Вы ткнули пальцем в небо и угадали. Копирующий сборщик мусора за счёт расположения логически близких блоков в одной линейке кеша может дать выигрыш по скорости по сравнению с консервативным.
> Что ты там дефрагментировать в куче собрался, дефрагментатор мамкин?На фоне слов "консервативный сборщик мусора" и "дефрагментация", как правило, появляется мысль о варианте mark-and-compact, но иногда только о поколениях.
это как болячка у Linux - когда оно вызывает такой дефрагментатор?.. только его завуалировано назвали компактофикатор...
> это как болячка у Linux - когда оно вызывает такой дефрагментатор?..Кто "оно"?
> только
> его завуалировано назвали компактофикатор..."Компакт" подразумевает перемещение блоков, что не всегда возможно (поскольку требует коррекции ссылок). Это не единственная стратегия дефрагментации. Если моменты освобождения смежных блоков детерминированы, возможно обеспечить выделение памяти с учётом того, что при освобождении блоков произойдёт слияние свободного места.
> Язык сфокусирован на безопасной работе с памятью, обеспечивает автоматическое управление памятью
> В новой реализации удалось избавиться от утечек памяти
Да, такое бывает, год назад сделал утилиту мониторинга и оставил её работать на недельку-две. Результат конечно был забавный, но утилита вместо десятка мегабайт была за полгига. Полностью избежать всех утечек можно только на ручном управлении.
Мне лично нравится rust, но топить за полную 100% безопасность и утечек памяти глупо, хотя некоторые вещи на этапе компиляции отлавливаются.
> Мне лично нравится rust, но топить за полную 100% безопасность и утечек памяти глупо, хотя некоторые вещи на этапе компиляции отлавливаются.Посему надо объявить раст устаревшим и выпив смузи, закурив это вейпом, идти писать свой нескучный язык, математически никак его не обосновывая, но говоря что он 100% безопастный и не повторяет ошибок C\C++ и Rust!
С тем же успехом можно хоронить Kotlin "патамушта" есть java Очень глупо объяснять людям, что разные языки под разные нужды. В расте действительно есть множество полезных инструментов, которые в С++ добавили только в 20 версии (и то, если не ошибаюсь, модулей туда не занесли) или их попросту нет.
Только большая часть возможностей котлина будет в новой java.
Имеет ли смысл котлин только из-за более копактного синтаксиса и @nonnull на уровне языка?
Да, @nonnull в джаве былобы очень кстати
Интересно под какие это другие вещи Kotlin был придуман?:) Если Kotlin появился ответом гугла на Oracle/(что там еще)Sun судебные тяжбы. И является именно ПСЕВДО заменой джавы.
Kotlin детище JetBrains и очень сомнительно, что по заказу гугля.
Уже исть язык Pony, но там математически обосновано все
Ну вот это исключительно твоя попорукость, нечего её на rust сваливать. Или кривые unsafe, или копятся где-то указатели (которые "умные", в rust, вроде, за пределами unsafe других и нет).
> Или кривые unsafe, или копятся где-то указатели (которые "умные", в rust, вроде, за пределами unsafe других и нет).rust не даёт гарантий насчёт утечек памяти. Откройте наконец документацию и почитайте её. std::mem::forget работает без всяких unsafe, и при этом позволяет создать утечку в полпинка:
{
let leak: Vec<u8> = Vec::with_capacity(1_000_000);
std::mem::forget(leak);
}Вот тебе и утечка мильона байт, потому как за пределами блока уже нет указателей на них. И, обрати внимание, ни одного unsafe. Есть и менее очевидные способы утечь память -- скажем Rc вполне это может делать, достаточно циклическую структуру собрать.
Вот именно, ваша утечка памяти является ПОЛНОСТЬЮ безопасной как для ПАМЯТИ так и для всей проги.
> Вот именно, ваша утечка памяти является ПОЛНОСТЬЮ безопасной как для ПАМЯТИ так
> и для всей проги.It depends... Всё зависит от того, как ты определяешь понятие safety. Rust определяет так, что утечка памяти не считается unsafe. И это не потому, что нет ничего плохого в утечке, и не потому, что разработчики раста не хотели обезопасить программиста от утечек памяти, а потому, что они не нашли способа обезопасить программиста от утечек памяти.
И на фоне этого, мне не нравится твоя позиция, она мне напоминает позицию "зелен виноград": если раст не избавляет от утечек, значит утечки -- это хорошо. По Фрейду это рационализация, то есть целенаправленное искажение реальности с целью уложить факты в красивую картину мира. Картина мира в твоей голове не должна быть красивой, она должна максимально соответствовать миру.
Еще раз,1. unsafe не считается безопасно/не_безопасно, оно считается как Сделай что-то но игнорируя проверки, играй с указателями как Я скажу, ломай поведение проги только лишь потаму что это захотел я.
При использовании unsafe к данной функции ЧИТАЙТЕ зачем там unsafe... и уже потом используйте. Итоговое поведение можно покрыть тестами и оно ВОЗМОЖНО будет полностью safe, а возможно и нет. Да и на случай проверок по коду данный момент будет отмечен.2. Утечки плохи для памяти в плане, ну течет:) ну не контролируемо, память может закончится. Но еще раз, причем тут раст? Раст вам дал все гарантии какие смог и утечку в safe rust действительно сделать трудно, но это возможно (банально вызвать forget, ManuallyDrop, Box::leak, ...) .Раст дал безопасную работа с памятью (move sematic, borrow checker, ...) как смог безопасно? безопасно.
3. "а потому, что они не нашли способа обезопасить программиста от утечек памяти." Вы же понимаете что вы написали ровно то как и unsafe, "программиста нельзя обезопасить от unsafe, бо раст не умеет определять safe код это или действительно unsafe", как решается подобное? только тестами. которые в расте хороши, но и всеже к этому приближается +- clippy, ... возможно что-то в этом плане еще улучшат.
Я не понимаю, чего ты не понимаешь и почему ты упорствуешь. Есть гипотеза, что ты пытаешься осмыслить мир постфактум, игнорируя историю этого мира, которая привела к сложившемуся положению дел. Весьма математический подход к проблеме, который иногда подходит и технарю/инженеру, но лишь иногда. Многие инженерные системы невозможно понять, игнорируя историю их создания и применения.Раст возник не спонтанно в вакууме, а из некоей исходной задумки Стива Клабника. Которая развивалась вместе с растом. Потом к Стиву присоединились другие люди, и у них были свои идеи, которые конфликтовали местами с идеями Клабника, всё это довольно долго варилось, и в результате получилось то, что получилось. Если смотреть с этой точки зрения, то говорить, что раст не предохраняет программиста от утечек, потому что в утечках нет никакой опасности -- это совершенно не верно. Он не предохраняет от утечек, потому что нет способа дать динамически выделяемую память и предохранить от утечек, не ограничивая программиста серьёзно в том, как он будет эту память использовать.
> 3. "а потому, что они не нашли способа обезопасить программиста от утечек памяти." Вы же понимаете что вы написали ровно то как и unsafe, "программиста нельзя обезопасить от unsafe, бо раст не умеет определять safe код это или действительно unsafe"
Возможно. То есть да, в некотором смысле я именно это и написал. Невозможно создать действительно безопасный язык программирования. Поэтому "безопасность" раста -- это ограниченная безопасность, некий компромисс между языком, который не позволяет ничего, но абсолютно безопасен, и языком, который позволяет много чего, но не совсем безопасен.
Мне кажется, что ты пытаешься определить понятие safety как "те гарантии которые даёт rust". Это в некотором смысле правильно, но по хорошему это следовало бы называть Rust Safety, потому что safety в общем -- это более широкое понятие.
Хочешь пример опасности утечек памяти? Представь себе автопилот, который падает в OOM в самый ответственный момент. Да хрен с ним с автопилотом: OOM это возможный вектор для DoS атаки.
> std::xxxТак это же проклятый C++ из-за которого горят дыры. Только истинный Rust !
>> std::xxx
> Так это же проклятый C++ из-за которого горят дыры. Только истинный Rust
> !Чё? Где ты там увидел C++, родный?
www.google.com/search?q=std%3A%3A
> www.google.com/search?q=std%3A%3AИ что гугл пишет? Я просто стараюсь с ним не общаться без большой надобности. А первая страница результатов ddg при поиске std:: о какой-то венере Sexually Transmitted Diseases.
> std::mem::forgetНу ок, ещё один способ отстрелить ногу. Прибегание к нему без учёта последствий разве не точно так же обуславливается криворукостью.
> Полностью избежать всех утечек можно только на ручном управленииЭто шутка такая?
С языка снял :^)Ну что, растофаноманы, чем будете отвечать?
Отсутствием сегфолтов каждый день разработки
Я уже который год пишу на С, мне за это даже денежки платят. И у меня нету сегфолтов, совсем, я уже забыл как они выглядят.Может просто надо хоть чуть-чуть научиться программировать и руки из _опы достать? А то повылазят всякие обезьяны, и ничего не изучая лезут в профессию.
> Я уже который год пишу на С, мне за это даже денежки платят. И у меня нету сегфолтов, совсем, я уже забыл как они выглядят.https://www.cvedetails.com/vulnerability-list/vendor_id-33/p...
Лично ты никого не интересуешь, интересует сишный софт который так или иначе дырявый. Дыры находят постоянно.
Что и silent memory corruption и потенциальных buffer overrun и double free нет? Фаззер, ASAN, UBSAN, TSAN, MSAN когда последний раз запускали?
https://www.opennet.dev/openforum/vsluhforumID3/122777.html#139вот.
Rust даёт гарантии memory safety. memory leaks к этому не относятся и гарантий относительно их никто не давал. Так что по ссылке выше от анона всё правильно написано.
растаманы потекли :))) но это, внезапно, нормальное их состояние.
> растаманы потекли :))) но это, внезапно, нормальное их состояние.Ну во-первых, на Rust я написал, пока что, около 2kloc, что мало, чтобы являться специалистом по rust и вообще "растаманом".
Во-вторых, я читать умею: https://en.wikipedia.org/wiki/Memory_safety - найди мне тут leak-и.
> С языка снял :^)
> Ну что, растофаноманы, чем будете отвечать?А зачем вам, жопоскриптозникам, не способным хотя бы смутно понять, что за утечки могут быть в _ядерном_менеджере_памяти_, отвечать?
Если вы всерьез считаете, что там, в реализации менеджера аллоцировали память в heap, то ... медицина тут бессильна.
Можно сказать что вы невнимательно прочитали новость.А можно по существу - утечка памяти которую допускает реализация mm - это логическая ошибка mm а не проблема с памятью самого mm.
Ну а чего ещё ожидать, когда неосиляторы, выбравшие себе язык с автоматическим управлением памятью, берутся писать менеджер памяти?
И? Ни один язык не спасет от утечек, в частности языки с gc
Чуть погодя и уязвимоси латать будут.
Утечка памяти — это логическая ошибка, от них тебя даже Раст не спасёт.
Ух, ты... как запели растаманы!
А из-за чего они взялись?
> из-за чегоиз-за раста, очевидно.
Еще раз, причемтут язык? Язык все свои гарантии дал.Здесь, нет ни std, ни какого рантайма. Вы его пишите взаимодействуя с небезопасным оборудованием.
Чтобы на расте сделать безопасным тотже C надо писать безопасные обертки над структурами, памятью, вещами. Если обертки написаны хорошо то утечек (НЕ СО СТОРОНЫ ЯЗЫКА, а с СИ стороны) нет.
И утечки не являются НЕ безопасной работой с памятью, уймитесь уже. Не безопасная работа с памятью вызывает неопределенное поведение, если утечка безопасна для всей проги то она является БЕЗОПАСНОЙ.
Даже safe-семантика Rust не гарантирует защиту от утечек памяти, как не гарантирует остутствие дедлоков (хотя существенно снижает вероятность обеих ошибок). Ни утечка пямяти, ни дедлок не являются по своей сути нарушениями безопасности работы с памятью и не приводят к UB.
> Ни утечка пямяти,
> ни дедлок не являются по своей сути нарушениями безопасности работы с
> памятью и не приводят к UB.Угу, поведение определённое: на машине разработчика с 64 ГБ ОЗУ работает, а у пользователя с 8ГБ не работает.
Для растаманов течка - нормальное состояние :) то, что проги падают от нехватки утекшей памяти - это норма :)
> верификация источника по цифровой подписи, контроль целостности, возможность повторяемой сборки,Годно.
https://gitlab.redox-os.org/redox-os/redox/-/jobs/31100/arti.../А где подписи самих исошек?
>Полностью переписана система управления памятью ядра (rmm, kernel memory manager).Когда некрофилу нечем заняться, он дристает
>В новой реализации удалось избавиться от утечек памяти
Никогда такого не было и вот опять. Так что там говорили про память?
>Значительно доработана развиваемая проектом стандартная Си-библиотека Relibc, способная работать не только в Redox, но и в дистрибутивах на базе ядра Linux.
И зачем им stdlib? Хотят без сей, пусть страдают без сей. А то биполярочка какая-то.
>Напомним, что операционная система развивается в соответствии с философией Unix и заимствует некоторые идеи из SeL4, Minix и Plan 9. Redox использует концепцию микроядра, при котором на уровне ядра обеспечивается только взаимодействие между процессами и управление ресурсами, а вся остальная функциональность вынесена в библиотеки, которые могут использоваться как ядром, так и пользовательскими приложениями. Все драйверы выполняются в пространстве пользователя в изолированных sandbox-окружениях.
Чем оно лучше GNU/HURD?
> И зачем им stdlib? Хотят без сей, пусть страдают без сей. А то биполярочка какая-то.Для поддержки программ, написанных под libc. Не на языке Си, а под libc. То есть для совместимости со старьём.
> Для поддержки программ, написанных под libc. Не на языке Си, а под libc. То есть для совместимости со старьём."Написать под libc"? Так теперь называется использование стандартной библиотеки? И я знаю, что язык отдельно, stdlib отдельно, но прикладные программы напрямую syscall'ы не дёргают, аллокаторы тоже стандартные используют.
man 7 libc
> прикладные программы напрямую syscall'ы не дёргаютСкорее всего, у редокса свой API для прикладных программ. В таком раскладе libc - это для совместимости с программами, написанными для API под названием libc.
>>В новой реализации удалось избавиться от утечек памяти
> Никогда такого не было и вот опять. Так что там говорили про память?Ох уж эти жопоскриптозники. Все они знают, обо всем имеют свое ценное мнение!
Еще бы хоть немного представляли себе принцип работы kernel memory manager и о каких утечках памяти там может быть речь (hint: динамично выделять память в реализации менеджера памяти немного ... сложновато), да шкурки от бананов не бросали где попало - цены бы им не было.
УРРРАААААААААААА
Почему у линуксоидов раздирает жопу под каждой новостью о других операционных системах: проприетарных, свободных, закрытых, открытых — всё равно.Вы — отбросы мира Open Source.
Толстовато. Вернись обратно в свой загончик
Ну вот, типичный линаксоед.
Тоньше надо быть, тоньше. Толстые набросы прекрасно работают в SJW-новостях, а не в чисто технической
> у линуксоидовУ комментаторов на Опеннете в смысле?))
>> у линуксоидов
> У комментаторов на Опеннете в смысле?))У больных сектантов, по каким-то причинам избравших линукс объектом своей фалометрии.
Как пропатчить KDE 5 под Redox OS 0.6?
Может, быстрее наоборот? Пропатчить Redox на C++ под KDE.
Ядро математически верифицировано? Значит есть дырени. В расте есть дырени!
И кстати да, оно по прежнему тормозит или растанавты <двуличненько> разрешили использовать блоки unsafe? И как, много памяти натеклоу? В растовые дырени.
питонист рассуждает о том что раст тормозит, забавно!)
Lewd. А ведь до сих пор процветает постановка диагноза по аватарке и вангование по нику.
Ну вообще, да https://www.factorname.ru/index.php?option=content&task=view... :)PS К Python отношусь лояльно.
> В новой реализации удалось избавиться от утечек памяти- В Rust не может быть утечек памяти, - говорили они...
Справедливости ради, даже в самом безопасном языке со встроенным GC может течь память.
Иногда из-за неоптимальности стратегии сборки мусора.
Иногда из-за того, что разрабы GC забыли обнулить где-то счетчик и пустые линки могут считаться как полноценный живой линк на память.
Но в подавляющем большинстве случаев это все кривые руки кодеров, думающих что по выходу из блоки все их new() автоматом заdelete()'ит. Или просто играются самописными коллекциями, забывая обнуть неиспользуемое. Короче, тут даже самая совершенная связка язык-компилятор-сборщик потечет.
в java сборщик мусора может даже "острова изоляции" удалять, которые простой подсчет ссылок никогда не найдет.
При этом в больших программах на java всё равно происходят утечки памяти, просто где-то случайно осталась ссылка объект и всё
> Справедливости ради, даже в самом безопасном языке со встроенным GC может течь память.Справедливости ради все же есть языки, где память не может течь в принципе.
Чисто функциональные лиспы с GC не занимаются подсчетом ссылок и у них не может быть, ввиду парадигмы языка, циклических зависимостей. GC пробегает от корня, строит однонаправленное дерево живых объектов и быстро компактифицирует кучу.
Не смотря на функциональность, эти языки вообще ничем не уступают всем остальным языкам, так как нужная мутабельность (если она действительно нужна) легко реализуется сопрограммами. Ну разве что надо научиться предварительно обдумывать программу, прежде чем начинать программировать.
> Но в подавляющем большинстве случаев это все кривые руки кодеров
Да, тут вы 100% правы.
> Чисто функциональные лиспы с GCМожно пример?
> - В Rust не может быть утечек памяти, - говорили они...Кто говорил? Опять таблетки не пьёшь?
Утечки памяти являются безопасными по причине того что это НЕ НАРУШАЕТ ПАМЯТЬ ПРОГИ/ИНСТРУКЦИЙ, в расте это не запрещено. Если есть неопределенное поведение то это запрещено.Да и утекала память в их планировщике озу, там реализация не совсем от гарантий языка зависит...
IRL, суровые мемлики заканчиваются для процесса фатально. Возможно "в тот самый момент", когда принудительная терминация закончится потерей данных. Мемлик в коре ОС, заканчивающийся терминацией, ну, вы поняли.Но у растаманов оно безопасно, угу.
А ещё можешь себе яйца дверью нарочно прищемить, и Раст тебя от этого не защитит. Ужасный язык.
Ваши растофетиши мне мало интересны, проделывайте это над собой сами.
Растоманы не умеют в mmu или хотя-бы mpu?
растаманы вообще хоть во что-то умеют?! написали микроядро, которое уже течёт?!
Ну чо, уже попробовали на "реальном оборудовании"?
А надо? Мне и Линукса хватает, пускай он уже и устаревшее легаси
Мне - нет, это я у местных растома.. тьфу, растофанов спрашиваю)
Делаем ставки, что быстрее взлетит: ReactOS или Redox.
Чернобыль
>В новой реализации удалось избавиться от утечек памяти, которые создавали проблемы при использовании старого менеджера памяти.А из-за чего появились утечки ведь в rust автоматическое управление памятью и встроенный статический анализатор.
В любом языке можно устроить утечку. Создать вектор размером в 999999999999 элементов и не удалять его до конца жизни программы. Компилятор не телепат, откуда ему знать, ошибка это или фича?
Ваш пример это как сделать утечку специально
Интересно было откуда они возникли конкретно в redox
Откуда ты знаешь, что специально?
А что, раст уже перестал сам удалять неиспользуемое? Надо вручную это делать?
> В любом языке можно устроить утечку. Создать вектор размером в 999999999999 элементов
> и не удалять его до конца жизни программы. Компилятор не телепат,
> откуда ему знать, ошибка это или фича?Из отсутствия доступа к вектору.
> Из отсутствия доступа к вектору.А кто сказал, что доступа нет? Программа может раз в год читать значение нулевого элемента, например.
>> Из отсутствия доступа к вектору.
> А кто сказал, что доступа нет? Программа может раз в год читать
> значение нулевого элемента, например.Вы сами написали, что доступа к вектору нет, только к одному его элементу.
> Вы сами написали, что доступа к вектору нет, только к одному его
> элементу.А дальше? Как компилятор об этом узнает?
>> Вы сами написали, что доступа к вектору нет, только к одному его
>> элементу.
> А дальше? Как компилятор об этом узнает?Произведёт семантический анализ.
> Произведёт семантический анализ.Теорема Райса: нельзя доказать, что программа обладает неким семантическим свойством в общем случае. Так что не сработает.
Вы описали частный случай.
> А из-за чего появились утечки ведь в rust автоматическое управление памятью и встроенный статический анализатор.Не знаю, но документация на std::mem::forget:
Каждая новость о программе на rust вызывает такой сильный пароксизм ненависти, что лучше просто запрещать комментарии сразу.
Отрицание
Гнев <----- вы находитесь здесь
Торг
Депрессия
Принятие
Дохтур последний пункт - это не Принятие, а Безразличие.
Это первый.
> В новой реализации удалось избавиться от утечек памятиборьба с утечками памяти в самом безопасном языке во вселенной <----- вы находитесь здесь
Просто некоторые видели синтаксис этого ЯП, видимо хватило ;)
Вы не в состоянии выучить отличия одного си-подобного языка от другого?
> отличияОга, незначительные такие)) И давайте-ка без всяких "си-подобных".
> Вы не в состоянии выучить отличияЛол, вот занятся болше нечем
>> Вы не в состоянии выучить отличия
> Лол, вот занятся болше нечемНекогда изучать матчасть, нужно комментарии c особо ценным мнением на опеннете ваять!
Ну всяко лучше питоновского
А чего вдруг петон-то? Из-за попсовости? Такая аргументация - это уровень днища.
Синтаксис данного ЯП специально задумывался таким, для еще больших возможностей языка.
Но тогда какие возможности у BrainFuck!
Правильно, в BrainFuck, никакие. А в расте дженерики и навороты на типах.
> лучше просто запрещать комментарии сразуИли просто не постить эти новости, что будет куда меньшим неудобством.
всё правильно делают: давно уже пора избавляться от этой сишной помойкино есть два замечания:
1. не URL, а URI
2. у URI есть одна проблема - это древовидная структура - такой подход уже показал свою негибкость по сравнению с теговой системой.
Интересная система. Ее бы ещё на нормальном языке переписать. Ну там С, asm.
Лучше сразу ОС писатьй в байт кодах под конкретный процессор / конкретного вендора!!
Это самый оптимальный путь для ОС
Естественно лучше.К сожалению человеку слишком тяжело воспринимать байт-код. (
Байт-код у виртуальных процессоров (Лисп-машина). У "железной" машины машинный код.
Ты не умеешь в юмор, извини
Я на полном серьёзе. А если ты про сраст, то если он и юмор, то черный. Черней пердона.
После Раста писать на Си - это как с Ламборджини на Жигуль вернуться
а как со скоростью генерации новых уязвимостей
Хороший язык, годный. Каждые два месяца ломающие синтаксис изменения.
Примеры?
Попробуй следить за изменениями, а не сидеть только во вконтактиках.
Да, действительно какие примеры?
Что сломано то?Редакция 2018 года? или 2015? И вы вообще вкурсе редакций?? И то что код времен 2015 года компилируется и под редакцией современного 2018 без изменений?
Всегда было любопытно: огромное множество удивительных баек про Rust на opennet - это целенаправленная кампания по дискредитации языка в неокрепших умах ридонли-анонимов, не способных самостоятельно проверять факты, или это просто какая-то локальная мифология, сотканная из сказок, которые анонимы тут друг другу рассказывают, а потом все вместе начинают в совокупность этих историй верить - этакое порождение коллективного невежества. Просто, если второе, то это довольно забавный социальный феномен: уверен, примерно так появлялись первые религии.
А когда в очередной раз доказывают что хруст - помойка, все начинается с начала или правописания. Сам говоришь что об "адекватности" растофанов ходят басни и вские сказы.
Естественно хруст помойка, но с ж ещё хуже
Это просто попытка отыгратся на комто (на расте) с целью самоутверждения. Человек натура дикая.
> целенаправленная кампания по дискредитации языка
> утечки памяти
растаманы - s&m?
>В отличие от прошлых выпусков, ветка 0.6 рассматривается как пригодная для экспериментов на реальном оборудовании, а не только в QEMU и VirtualBox.Я вот попробовал его в virtualbox запустить, оно на "Redox Loader - Stage TWO 00000007#007F 0000:8A00" зависло. Уже минут 10 висит.
О боже, ассемблерщики от хруста - это химера...
>Выпуск операционной системы Redox OS 0.6, написанной на языке RustПридётся Мелкомягким ещё и WSR себе запилить ;)
А почему при установке раст компилятора и его std либы месте аж больше 300 мегабайт занимает?
Скомпилил хелоу ворлд, охренел - экзешник 11 мегабайт. Ещё компилятор думол полторы секунды, а gcc и g++ компилят моментально.
Как так?
> Скомпилил хелоу ворлд, охренел - экзешник 11 мегабайт.
> Ещё компилятор думол полторы секунды, а gcc и g++ компилят моментально.
> Глянул на руки - кривоваты.
> Как так?Кто ж его знает?
$ cat hello_world.rs && time rustc -O hello_world.rs && wc -c ./hello_world
fn main() {
println!("Hello Wrot!");
}
rustc -O hello_world.rs 0,26s user 0,11s system 140% cpu 0,262 total
392000 ./hello_worldcat hello_world.rs && time rustc -C prefer-dynamic -O -C link-args=-s hello_world.rs && wc -c ./hello_world
fn main() {
println!("Hello Wrot!");
}$ rustc -C prefer-dynamic -O -C link-args=-s hello_world.rs 0,19s user 0,11s system 137% cpu 0,213 total
6592 ./hello_world$ time gcc -O2 hello.c
gcc -O2 hello.c 0,09s user 0,03s system 87% cpu 0,138 total
Gcc меньше проверок делает, конечно он быстрее. Чем меньше программа делает, тем быстрее она работает.Тоже самое и с размером - бинари раста толще потому, что там больше кода который даёт больше фич, чем hello world на сях. Разматывание стека на панике с выводом где в коде была ошибка (типа жавовских стек трейсов), и тд. Кроме того, он содердит растовский libstd, в то время как сишные программы по-умолчанию не содержат, а линкуются с libc.
Всё это можно отключить и сделать бинарь такого же размера, как на сях. Подробнее тут https://github.com/johnthagen/min-sized-rust
Но лучше всего почитать блог где чел пишет операционку с нуля на расте, где всё это как раз отключается и показывается чё к чему: https://os.phil-opp.com/
> Gcc меньше проверок делает, конечно он быстрее. Чем меньше программа делает, тем
> быстрее она работает.
> Тоже самое и с размером - бинари раста толще потому, чтоКомментарий не читай, сразу бодро отвечай?
>> 11 мегабайт.
>> полторы секунды,
> $ rustc -C prefer-dynamic -O -C link-args=-s hello_world.rs 0,19s user 0,11s system 137% cpu 0,213 total
> 6592 ./hello_world
> $ time gcc -O2 hello.c
> gcc -O2 hello.c 0,09s user 0,03s system 87% cpu 0,138 totalВыжимка:
___
> 6592 (6.5KB) ./hello_world (rust)
> rustc 0,19s user 0,11s system 137% cpu 0,213 total
> gcc 0,09s user 0,03s system 87% cpu 0,138 total---
В общем, вышеотписавшийся в 176 анонимный "критик" выставил себя еще тем "знатоком" ;)
С этим понятно. Компилятору нужно правильные опции задавать. А как быть с перенесёнными с плюсов либами? Их в расте можно заметить по вызову типа С_function_name.unwrap(). Так напримёр все функции OpenGL на расте вызываются.
Как это вообще работает? Происходят ли какие-то потери в производительности?
> типа С_function_name.unwrap().Скорее так:
unsafe { C_function_name() };
unwrap() - это метод растовских типов std::result::Result и std::option::Option, сишные функции его не возвращают.
> Как это вообще работает? Происходят ли какие-то потери в производительности?
Никаких потерь. Просто вызов функции, как и в Си.
статическая линковка + отладочная сборка по-умолчанию
ЗОтО безОпаснОсть!!!!11111
Статическая линковка - это безопасно? А прикинь в стандартной библиотеке найдут критическую уязвимость. Вся их хваленная безопасность мигом накроется медным тазом.
Ну тогда в эту категорию попадают все те, кто вовремя не обновляет софт.
Даже при динамической линковке у юзера может быть устаревшая система с кучей уязвимостей.
При динамической линковке достаточно обновить одну разделяемую библиотеку. При статической надо пересобирать всё, что слинковано с библиотекой. Чувствуешь разницу?
> А прикинь в стандартной библиотеке найдут критическую уязвимость.Так и обратное верно - прикинь, в новую версию библы занесут баг и все программы окажутся уязвимы.
Динамическая линковка это здорово и жаль, что Cargo по-умолчанию её не делает. Но клёвая не тем, что можно зависимости на лету поменять (и потенциально сломать программу), а тем, что не надо один и тот же код сто раз в память загружать. То есть идеальный подход - это как в Винде: вот бинарь, вот рядом с ним DLL-ки. Хочешь - заменяй, хочешь - шарь их на всю систему. А не хочешь - ничё не делай, бинарь будет их использовать из текущей директории только для себя, и ни с кем в системе не будет пересекаться, не будет проблем с несовместимостями версий и тд.
Там надо для боевого компилинга включить оптимизации и выключить отладочные фигулины. И будет норм. По умолчанию там дебажно без оптов
>Для совместимости с существующими приложениями предоставляется специальная POSIX-прослойка, позволяющая запускать многие программы без портирования.Можно поподробнее. Я ставлю Редокс, качаю *.deb файл и спокойно его запускаю? А штатные родные пакеты имеют какой суффикс?
.deb это не про POSIX. Это ж формат пакета, для .deb надобно ещё dpkg запускать, ну сами понимаете. А позикс - это про API для программ
Нет, ты берёшь исходники, пытаешься их собрать и обламываешься либо потому что сборочная система ничего не знает про сабж, либо потому что разрабы использовали расширения, выходящие за рамки POSIX (скорее всего, и то и другое).
Если у вас статическая линковка, собирайте).
Если у вас динамическая, возможно подменив названия у вас чето и заведется.
Причём здесь линковка? Ты где вообще таких слов нахватался, мальчик?
>В новой реализации удалось избавиться от утечек памяти, которые создавали проблемы при использовании старого менеджера памяти.Фрактал! Зацени Растовые дырени!
Главный прикол в том, что растовые дырени на опеннете - ажиотаж и небывальщина, что как бы намекает ;)
...все прочитал ... х...ю мелете, ... бетка а все есть ... и все URL ... интересно ... интересно ... надо пробовать, набить шишек, поюзать ... х.з. пробую ...
"Полностью переписана система управления памятью ядра (rmm, kernel memory manager). В новой реализации удалось избавиться от утечек памяти, которые создавали проблемы при использовании старого менеджера памяти. Кроме того, повышена стабильность поддержки многоядерных систем. "
я канэшна дико извиняюсь, Раст как раз для того и придумывали чтобы этих утечек не было в принципе - или я сильно ошибаюсь?
Ты все правильно говоришь Раст это маркетинговый булшит.
Ты сильно ошибаешься.https://doc.rust-lang.org/reference/behavior-not-considered-...
https://doc.rust-lang.org/book/ch15-06-reference-cycles.html
Ты нам показал, что на Расте возможны утечки. Хорошо. Но на какой такой чёрт растаманы чмырят ЯП Си за дырени и утечки. Бревно в своём глазу не видят, а соломинку в чужок глазу видят.И тут я вспомнил слова Кена Томпсона, о том, что "Си не может быть опасным или безопастным". Сама постановка вопроса не правильная. Всё зависит от программиста.
Много программистов не умеют грамотно писать на чистом Си, и при возниконовении утечок или ошибок они и их окружение проклинают чистый Си. Но ведь Си тут не причём, эта рука программиста растёт из жопы.
Осталось найти способ клонировать пряморуких никогда не ошибающихся программистов и всё будет в ажуре.
Все таки Си создает риск что код получится с утечкой. Раст наоборот.
То есть надо уходить от Сей. На РАст или что еще.
Кэп
> Си создает риск что код получится с утечкой. Раст наоборот.Раст создаёт риск, что код получится без утечки?
Растаманам бы сначала разговорный язык подтянуть, потом уже ЯП изучать.
Потому что при существенное утечке памяти... у тебя закончится память (и возможно апп кильнут).
А при выходе за границы массива аппа напр. получит рут. Абсолютно никакой разницы, правда?
> Но на какой такой чёрт растаманы чмырят ЯП Си за дырени и утечки.За дырени. Что касается утечек, то их в Расте сделать сильно сложнее - надо специально постараться. Ну и плюс сам язык Си адски устарел и не умеет множества полезных вещей. Си++ умеет, но всё равно уступает в простоте и удобстве.
>сам язык Си адски устарелЯзык следующй структурной парадигме устареть не может никогда. Си вечнозелённый.
> Язык следующй структурной парадигме устареть не может никогдаНалицо подмена понятий. Парадигма может и не устарела, а язык - да.
В нём очень мало фич, что приводит к усложнению разработки. За 50 лет много полезного и удобного успели придумать, мягко говоря.
Мягко говоря все фичи к "процедурному стилю программирования" никакого отношения не имеют. Все фичи пилятся в рамках ООП или функциональщины.
Эта мысль для меня слишком глубока, извините, не осилил понять какое это имеет отношение к тезису "си - устарел".
>Эта мысль для меня слишком глубока, извините, не осилил понятьНу хорошо, смотри. Алмаз может устареть? Он всегда ценен, и люди во все времена хоят его добывать. Чистый Си - это процедурный алмаз.
> Всё зависит от программиста.Вот Растофанатики и усвоили урок что язык не имеет никакого значения. Программируешь ты на С++ или Расте, ни тот ни другой язык не даст тебе никакой безопасности если думать не умеешь.
И встречный вопрос если все зависит от программиста зачем нужен Раст? Ответ очевиден. Раст не нужен.
> если все зависит от программиста зачем нужен Раст?От программиста зависит только использование unsafe. Без ансейфа ты сегфолты не получишь.
Утечки без unsafe - насколько понимаю только через специальные для этого функции - std::mem::forget(), std::boxed::Box::leak(). Случайно ты их не вызовешь. Ну это как случайно вызвать std::process::exit(0) и жаловаться, что у тебя процесс завершается.
Как ты считаешь, если компилятор в силу устройства языка проверяет за тебя кучу ошибок работы с памятью и гарантирует отсутствие сегфолтов без unsafe - означает ли это, что ничего от языка не зависит? Как ты так интересно логические выводы-то строишь?
и да - у меня на железе сабж не загрузился, видимо ржавое.
И как это чудо подсунуть grub4dos? Запустится ли? :)
Не, надо переписать grub4dos на расте
По идее, они работают же с обычным грубом. Но могу и ошибаться.
Надо такие же истерики устраивать в языках с gc
'Они обещали что gc сам всё удалит, а он не удалил. Они врали!!!!!!111111'
Что насчет реального железа, кто нибудь запускал?
Не будет его это как РеактОС. Нужен только для того чтобы показать смотрите как мы умеем, а не для того чтобы реально где-то применять.
растаманы только показали, как они могут течь.
Эх... Эщё язык-то не допилили, а уже ОСь лабают ради понта. Ну что за кодеры пошли? Лучше бы решали проблему "стыка" между либами на разных ЯП-ах, а то конь уж лет двадцать как не валялся... Или пилили бы ЯП для бинарного кода LLVM под окружение браузерного API, чтобы выдать сие как распределённую платформу для приложух, поддерживая полиморфизм во всех позах и обмен исполняемым кодом в рантайме, но это ж религия не позволяет, Касперский не велит, Microsoft не одобряЕ, Google нИАсилил, Линус глаза выпучил, Ябло послал на хутор близ Диканьки, ибо у них менеджерский распил в самом разгаре. Про Завалишна все дружно забыли, ибо хайпо-жвачная публика не любит самоделкиных (на их фоне сама фальшиво выглядит).
Ядро Linux тоже ради понта было. Или вон GTK с гимпом.
Там был не столько понт, сколько протест, выраженный в массовом коддинге, когда куча студентов, коснувшихся Unix, решила понавтыкать AT&T за злобный монополизм. Но тогда и не было распространённой альтернативы. Теперь же нужно рожать новую концепцию, а не повторять пройденный путь только потому, что "оно на Rust-е".
Вообще-то мы в свое время сделали еще круче - СПЕРВА написали ОС (на чем под руку попало и кое-что вообще прямо в кодах, благо pdp7 имела человекочитаемый код) а потом написали язык для ее написания (и таки переписали на нем ОС, пару раз по дороге и язык поправив, потому что не все с первой попытки вышло удобно).Но есть одна мелкая деталь: мы это делали не чтобы всех удивить и осчастливить, а для себя, любимых - просто pdp7 была настолько унылая, что никакой ос для нее вообще не было, только монитор, а нам ТАК трахаться не хотелось.
Ну а потом нам еще захотелось пользу другим причинить, да и как-то оправдать отжатую 11ю вместо совсем уж сдохшей седьмой - мы еще текстовый форматтер сочинили и он тоже частью той ОС стал.
На нем потом еще долго доки к этой самой PDP печатали.Почувствуйте, как у вас когда-то говорили, разницу.
А обои, вообще-то, ничего так вышли, веселенькие...
Все что вы сделали это показали как не надо. И потом все пришлось писать с нуля как надо!
Так в том-то и дело, что мотив нынче не слишком убедителен. Я, вот, не могу придумать сферу применения для Redox кроме демонстрации пруфа для Rust-пиара.
Я думаю вы неправильно смотрите: нужно искать мотив не снаружи, а изнутри. Рано или поздно на Rust будут писать ОСи, и первой уже оказался Redox. В экосистеме раста идет конкуренция среди разработчиков за "первое место" и прочие блага, которые оно способно принести.
> Я думаю вы неправильно смотрите: нужно искать мотив не снаружи, а изнутри.
> Рано или поздно на Rust будут писать ОСи, и первой уже
> оказался Redox. В экосистеме раста идет конкуренция среди разработчиков за "первое
> место" и прочие блага, которые оно способно принести.В таком случае ОС на Rust должна предъявить какие-то преимущества.
Язык СИ достаточно универсален, но писать проще на C++. Архитектура драйверов под Linux проще для понимания, чем то же самое для Windows. Однако, код модулей ядра Linux вызывает желание рыдать... Не всех, конечно, бывают и адекватные... Иногда... И язык СИ тут ни в чём не виноват. Сама культура разработчиков порождает эти простыни смешанного в кучу кода без каких-либо адекватных комментариев. При разработке натыкаешься на отсутствие достаточной документации и просто лютейший снобизм "ядерщиков".
Достаточно, к примеру, просто написать ОС с совершенно иным подходом к организации кода. Тогда люди будут заменять тот же GNU/Linux на Embedded новой ОС-ю просто мотому, что писать модули под неё проще и удобнее. Попутно распиарят язык программирования.
Кстати, под винду драйверы можно и на C++ писать.
> Или пилили бы ЯП для бинарного кода LLVM под окружение браузерного API... сказал KroTozer и ушёл в криокамеру ещё на 30 лет. PNaCl уже успели запилить и закопать, а сейчас пилят Wasm, в который Rust умеет компилироваться искаропки.
Вы ошиблись, не пилят. А ДАВНО запускают и интегрируют.
>> PNaClПродукт от, извиняюсь за матерное слово, "Google", который пилили с понтом под зонтом до 2013, потом посеяли, потом откопали и обиженно ограничили ChromeOS, которой оно по идеологии не впёрлось? Замечательный продукт. Запихните его обратно в криокамеру и не вынимайте оттуда.
1. Эх... Эщё язык-то не допилили, а уже ОСь лабают.В языке есть действительно много моментов которые КАКТО вас ущемляют. Но нет ни одной преграды написать на нем ось, драйвер к линуксу, прогу с граф интерфейсом QT/GTK... Да и ядро языка никак не ломает ни 2015 редакцию языка, не 2018 (все компилируется и работает как надо)
Ясно, понятно?
2. Ну что за кодеры пошли?
Пошли и пошли:)
3. Лучше бы решали проблему "стыка" между либами на разных ЯП-ах, а то конь уж лет двадцать как не валялся
Я не знаю в чем проблема. Есть автогенератор сырых C в сырые Rust структуры и наоборот, единственное это всеже будут не по растовским правилам писаные структуры, без safe оберток. Есть Java/Wasm/Python/JavaScript с ними взаимодействие двухстороннее как желается.
Часто чтобы связать например Postgres exep на C++ и Rust надо: 1. сгенерировать сырые extern C структуры АВТОМАТИЧЕСКИ, 2. Написать безопасные и красивые Rust Api для этих С структур, 3. Используй, красиво и понятно и на растовском.
И где тут вопросы о проблемах взаимодейсвия?
4. Или пилили бы ЯП для бинарного кода LLVM под окружение браузерного API,
А раст завязан только под Firefox, браузеры и виртуальные машины?:) Не-не.
Да и растоманы хотели когда-нибудь от LLVM отойти в сторону MIR, но пока не выходит.
Далее нейкий странный бред у вас идет, еще раз Раст язык системного программирования (на нем хоть ОсЬ лепи, хоть с JavaScript общяйся, хоть Embedded)
>> В языке есть действительно много моментов которые КАКТО вас ущемляют.Вокруг все ездят на электромобилях? При том, что нет никакой проблемы сделать электромобиль под любые нужды. Неужели история ничему не учит? Ни один техдир не потянет в проект Rust, пока под него не появится выбор SDK и IDE хоть как-то сопоставимый с уже имеющимся у того же дизориентрованного C/C++, наркоманского Java, фашистского Python-а, безалаберного ECMAScrypt и остального зоопарка. Нормального языка нет и вряд ли когда будет. В среднем Rust ни лучше, ни хуже, но он — зародыш в яйце. Даже загнанный за плинтус D и то взрослее будет.
Ясно, понятно?
>> Пошли и пошли:)
как в том анекдоте:
- Да пошёл ты!!!
- Да, я посол, посол!>> Есть автогенератор сырых C в сырые Rust структуры и наоборот
И ради мнимого "стандарта" повторяется анахронизм на новый лад. Стандарты же бинарей общие. Может стоило развивать стандарт линковки функций? А то где у нас ООП? в Караганде. Не вылезает за пределы объектника вообще.
>> И где тут вопросы о проблемах взаимодейсвия?
Показываю на автомобиль с деревянными колёсами, а в ответ: "И чё? Он не ездит, что ли???".
>> А раст завязан только под Firefox, браузеры и виртуальные машины?:) Не-не.
Вот тут, пожалуй, справедливо. Но, как выше и упоминал, на рынке, где старые решения покрывают все потребности, развивать надо что-то новое. А среди нового — дать замену глумлению над железом коммуникаторов, которые Google (опять матерюсь...) обозвали "смартфонами". Да, замыкать на браузере может и не надо, но сейчас куда важнее сменить Java-бред на коммуникаторах чем-то нативным или полунативным, как упомянутые LLVM и MIR, чем сиюминутно выгонять СИ из модулей Linux-а. А то блудливый GC роняет "андрюшу" на любом аппарате раз в неделю обязательно вне зависимости от производительности последнего и версии ОСи.
>> Раст язык системного программирования (на нем хоть ОсЬ лепи, хоть с JavaScript общяйся, хоть Embedded)
Да ради Бога! Кто запрещает-то? Просто допилить его прежде надо. Так-то Rust много приятнее укурства под названием "GoLang", хоть и кочевыряжится с облостями видимости.
К тому же, если язык проектировался как "системный", то может разрабы уже решат, что именно они хотят заменить: СИ или C++ (это далеко не одно и то же). Сама проблема C++ кроется в попытке быть "хорошим" для СИ-кода. Так может не надо тащить этот горб Квазимодо в новый ЯП?
Почему вы всё это не делаете?
>> Почему вы всё это не делаете?А ещё глупее вопрос чем этот можно?
Наверное потому, что решаю прямые рабочие задачи, а свободное время уделяю семье, а не сношанию Клавы Мышкиной на разных языках. Хотя Rust, как идея, выглядит всё же получше GoLang-а. Там совсем уж процедурно укурились.
>а свободное время уделяю семьеНе ври, ты ведь в свободное время мощно бухаешь.
>Там совсем уж процедурно укурились.
Ага, так и запишем: "KroTozeR не знает алгоритмы".
>Лучше бы решали проблему "стыка" между либами на разных ЯП-ах, а то конь уж лет двадцать как не валялся....NET
Тупые поделки от мелкософта не нужны
Отличный проект! Благодаря ему всплывает куча проблем в языке и становится понятно, почему раст никогда не заменит С.
> Благодаря емукуча вкатывальщиков в ойти смогут почувтвовать себя программистами, потешить свое самомнение, рассказать что умеют писать на языке на котором пишут ось. Ну и потом с чистой совестью вернуться к папе/маме под крылышко или как часто бывает - гос паёк и учить всех жизни.
> гос паёк и учить всех жизни.А, так ты на госпайке…
Когда капитаклизменные войны закончатся разрухой уровня "ядрён-батон США против китайского Huawei" на фоне взаимного пожирания друг друга за ошмётки рынка, а граждане за упоминание слова "IT" будут бить в рожу не предупреждая, тогда только "госпаёк" и будет решать, куда чего и как развивать.
1. "Благодаря ему всплывает куча проблем в языке" расскажите? А то нам не понятно... КАКИЕ ПРОБЛЕМЫ?
Он не защищает от утечек памяти.*BA DUM TSS*
Местные хейтеры раста не знают матчасть, вот что стало понятно.
> Отличный проект! Благодаря ему всплывает куча проблем в языкеЭто правда. Язык допиливают по ходу возникающих нужд для нетривиальных задач. Не пытаясь выполнить эти задачи не всегда можно обнаружить как и что необходимо в языке запилить. И это касается любого проекта, а не только ЯП.
> и становится понятно, почему раст никогда не заменит С.
Разработчикам Раста непонятно, а тебе - понятно. Это здорово, всегда интересно встретить умных людей, которые додумались до чего-то, до чего не додумались остальные. Осталось только поделиться с окружающими - что же именно стало понятно, расскажи.
> файловая система TFS, развиваемая на основе идей ZFS (модульный вариант ZFS на языке Rust)Ширится зоопарк "наших ответов" ZFS. И, конечно же, каждый уверен, что вот уж его-то ФС порвёт всех, как тузик грелку :)
Вообще Rust, имхо, это попытка совместить в одну химеру C++ и Golang. Получилось забавно и стоит изучения, но примерно как Haskell - мозги и общий кругозор развивает, но денег на этом практически не заработать (по крайней мере, сейчас).
Насчет того, что не защищает от утечек памяти - для идиотов там черным по белому написано, что сам Rust - это энфорсинг RAII парадигмы из C++. Пока тебе для работы достаточно стековых объектов и movable семантики обычных референсов и ты работаешь через референсы - память гарантированно не утечет, т.к. компилятор вместе с borrow checker поймают утечку "за хвост" через lifespan-ы. А вот если тебе нужна динамическая память, например связный список или дерево в хипе, то простите, тут только старые-добрые смартпоинтеры, расставляемые кодером вручную и утечка памяти через Rc<> циклы.
В целом, где-то читал, что создать язык программирования для фон-Неймановской архитектуры, который бы своим синтаксисом и семантикой полностью ликвидировал случаи протечки, эквивалентно проблеме останова. Так что Rust и его memory management - не более чем best effort по водружению задачек на внимательность со стороны программиста на плечи компилятора.
> C++ и Golang— единственные языки, которые знает анонимус, лол. Потому что Rust — это практически ML с C-подобным синтаксисом (плюс боров-чекер). Первые версии rustc вообще на OCaml были написаны.
Вперед, покажи где в Rust монады, стрелки Клейсли, continuation passing style и тайпклассы. Тоже мне ML-потомок. Rust не поддерживает параметрический полиморфизм высших порядков (в частности, никаких родОв произвольной арности, как в Haskell/Scala). Это Golang с кучей "академических" идей и эксплуатацией бест практисов из C++.
Аноним слышал звон, но не отличает ML от гопник хаскеля, так и запишем.
Монаду можно в принципе эмулировать на любом языке. Это, считай, просто для Хаскела они стали идиоматической конструкцией для выполнения многих вещей, а так-то перенести хаскеловский интерфейс монад, чтобы те же монадические комбинаторы парсеров забацать, на другой язык никто не мешает
Rust всё же не ML и не вполне функциональный язык (я спрашивал у проженных ML-хаскельщиков). Ну то есть да, в Rust есть ML-подобные типы алгебраические, но в целом-то он не особо сопротивляется мутабельности, например. Это всё же скорее обязательный энфорсинг RAII с некоторыми плюхами ML'я, как один аноним сказал выше. Для меня Rust выглядит как экая такая попытка переосмыслить C и C++ с учётом уроков и шишек за более чем 40 лет развития. Ну естественно, что народившееся за это ФП тоже оставило на нём немалый след
ML - тоже не чисто функциональный язык, в отличие от Haskell.
1. Вообще Rust, имхо, это попытка совместить в одну химеру C++ и Golang.Мне интересно почему вы решили совместить C++ и Go и получить Rust?:)
Если:
1. C++: C + ... вот не помню что
2. GO: C++ + Java + ...
3. Rust: Haskell + OCaml + ...И GO никак не ложится в эту мешанину).
2. "Насчет того, что не защищает от утечек памяти - для идиотов там черным по белому написано, что сам Rust - это энфорсинг RAII парадигмы из C++. Пока тебе для работы достаточно стековых объектов и movable семантики обычных референсов и ты работаешь через референсы - память гарантированно не утечет, т.к. компилятор вместе с borrow checker поймают утечку "за хвост" через lifespan-ы. А вот если тебе нужна динамическая память, например связный список или дерево в хипе, то простите, тут только старые-добрые смартпоинтеры, расставляемые кодером вручную и утечка памяти через Rc<> циклы."Вот это уже хорошо, правильно!.
3. "Так что Rust и его memory management - не более чем best effort по водружению задачек на внимательность со стороны программиста на плечи компилятора."
Знаете, уже сколько языков за плечами: Java/PHP/C++/Delphi... а от всех после Rust хочется плеваться. Так как в расте все поиному, не то что на этих ваших... Здесь во время написания ПО и душа радуется, код хорошо масштабируется, нет старых практик с этими NullPointer, за все что надо платить тебе рассписано, компилятором проверится, unsafe выделен, репозиторий библиотек (похожий на свалку, но:)).
> 2. GO: C++ + Java + ...Go: Plan 9 C on steroids with smoothy and GC
> 3. Rust: Haskell + OCaml + ...
3. Rust: C++ + 2 bottles of vodka
Rust - модный язык. Кто хочет быть модным?
> Rust - модный язык. Кто хочет быть модным?Модный - javascript/golang/python. Там ваще думать не надо, берёшь да идёшь в ногу с модой. А rust - немодный, там думать надо, это тяжело.
>А rust - немодный, там думать надо, это тяжело.Раст - это высокая мода, ты знаешь что-такое высокая мода.
> А rust - немодный, там думать надо, это тяжело.Вот теперь полный ступор. Кричали же что Си это тяжело, а на расте даже домохозяйка может ось написать.
> Кричали же что Си это тяжело, а на расте даже домохозяйка может ось написать.Про лайфтаймы и овнершипы всё равно думать надо. Это гораздо проще, чем писать на Си, но думать всё равно надо сильно больше, чем на игрушечных языках. Плюс это требует более глубокого понимания низкоуровневого устройства. Например - чем куча отличается от стека. Откуда стек берётся и как примерно устроен. Жаваскриптисты скорее всего даже слов таких не знают, а про стек может быть что-то краем уха слышали когда из-за рекурсии у них переполнение раз в жизни случилось.
Ну и в целом раст позволяет, - а иногда и принуждает - думать и обрабатывать какие-то мелкие детали, которые в игрушечных языках спрятаны. Например, частный вопрос от новичков раста - а чё это у меня программа выводящая в stdout тормозит? А чел там фигарит println!() и не знает, что на каждый вызов лочится мутекс, и что бы оно быстро работало, нужно один раз взять мутекс себе и только потом в stdout всё записать, что неимоверно ускоряет процесс. На всяких жавах, жаваскриптах и прочем у тебя такого выбора нет, ты всегда будешь платить за синхронизацию каждого вызова.
>а чё это у меня программа выводящая в stdout тормозит? А чел там фигарит println!() и не знает, что на каждый вызов лочится мутекс, и что бы оно быстро работало, нужно один раз взять мутекс себе и только потом в stdout всё записать, что неимоверно ускоряет процесс.В Си поезд из точки А в точку Б приедет прямиком. В Расте, для того чтобы доехать до пункта Б, надо сначала проехать пункты В и Д.
https://doc.rust-lang.org/std/io/fn.stdout.html
>> Each handle returned is a reference to a shared global buffer whose access is synchronized via a mutex. If you need more explicit control over locking, see the Stdout::lock method.
> В Си поезд из точки А в точку Б приедет прямиком.Питонистам и ЖСникам оно конечно виднее, но в С11 говорится о
> §7.21.2 Streams
> Each stream has an associated lock that is used to prevent data races when multiple threads of execution access a stream, and to restrict the interleaving of stream operations performed by multiple threads. Only one thread may hold this lock at a timeА до этого машинист считал, что по умолчанию поезд на этом пути только один.
> В Си поезд из точки А в точку Б приедет прямиком. В Расте, для того чтобы доехать до пункта Б, надо сначала проехать пункты В и Д.Тебе уже поясинили почему неправ, но добавлю: даже если бы это было так, как ты говоришь, это означало бы только врождённую опасность функции вывода в stdout. Именно потому, что Раст как язык и его библиотеки в целом пекутся о корректности - программы на нём корректно работают, а не глючат или сегфолтятся. Не, "ой, я не подумал, ой а я не знал, ой а я не думал что эта ошибка реально может возникнуть", а тебя подталкивают или даже заставляют обработать все крайние случаи. В результате твоя программа имеет больший шанс быть надёжной, а не куском говна.
>сегфолтятсяУж лучше сегфолт на сях, чем вполне определённое, но не для пользователя, продолжение выполнения.
>, а тебя подталкивают или даже заставляют обработать все крайние случаи.
Часто встречал программы, где проверяется errno вызова close? Или как там на хрусте.
> Уж лучше сегфолт на сях, чем вполне определённое, но не для пользователя, продолжение выполнения.Не понял про что это.
> Часто встречал программы, где проверяется errno вызова close? Или как там на хрусте.
Я часто встречал где не проверяется, что существенно усложняло траблшутинг на продакшене. Сам же я всегда все ошибки проверяю и логирую если что-то не так.
Вообще, если интересует тема надёжных программ, сделанных для продакшена, а не для тестировщиков - рекомендую к прочтению https://www.amazon.com/Release-Design-Deploy-Production-Read... . Например, механизм "circuit breaker" придумал как раз автор этой книги, и популяризовал тамже, за много лет до того, как реализация CB стала появляться в некоторых фреймворках.
>Это гораздо проще, чем писать на Си, но думать всё равно надо сильно больше, чем на игрушечных языках. Плюс это требует более глубокого понимания низкоуровневого устройства. Например - чем куча отличается от стека.Что-то мне подсказывает, что наоборот. На сях, например, быстро доходит, чем отличается malloc, alloca и vla. И почему возвращать указатели последних - идиотизм.
Да и вообще си - высокоуровневая замена ассемблеру, разбавляемая разве что inline assembly.
s/удалось избавиться от утечек памяти/есть некоторые основания надеяться, что проблема не воспроизведётся на достаточно заметном количестве инсталляций/
Это оператор яп? Что-то из Перл?
> Это оператор яп? Что-то из Перл?s/<pattern>/<replacement>/<flags>
Это из sed (а может и каких-то его предков) прошло: https://www.gnu.org/software/sed/manual/html_node/The-_0022s... . Перекачевало в vi, потом в vim. Потом в первых интернет-чатах IRC, которые были популярны в 90-ые и даже немного 00-ые, таким образом матёрые юниксоиды друг другу остроумно показывали, что они типа исправляют опечатку в уже отправленном сообщении, т.к. IRC не позволяет отправленные изменять.
Ну и с тех пор ностальгирующие по давним временам, или просто люди с очень специфическим кругом общения, пишут вот так. То есть фактически это такой элитный способ сказать "у меня вон там опечатка, я типа заменяю такой-то кусок текста на другой" вместо того, что бы зарегистрироваться и иметь возможность редактировать собственные сообщения.
Или же, таким образом человек показывает, что он хочет заменить кусок текста в чужом сообщении. Сейчас, правда, это принято делать по-другому: ты выделяешь цитату и правишь в ней текст, а потом добавляешь "вот, поправил" - это гораздо смешнее получается, а главное всем понятно.
Пожалуйста.
Просто хочу сказать что РеактОС все еще топчется на месте. Тут уже и Раст возник, и продвинулся, и ОС возникла, много воды утекло..
> Раст возник, и продвинулся...в сторону текучести памяти.
Скажите пожалуйста, а какой собственно профит кроме выеженов со стороны растофилов, ведь уже давно есть всякие KolibriOS, что почти машинный код.
Пожалуйста: https://doc.redox-os.org/book/ch01-05-why-redox.htmlКроме того, авторы заявляли, что делают это не ради самой ОС, а ради развития языка.
Спасибо, из прочитанного стало ясно, что просто кто-то хочет свой блекджек с девами. Причины какие-то высосанные.....
А какие в твоих глазах были бы невысосанными? Ну что б понимать, что не любое обоснование было бы "плохим", а где-то есть всё-таки "хорошее".
А разработчики не обязаны лично тебе доказывать, что у них причины "правильные".