Спустя два года с момента основания проекта состоялся (https://github.com/redox-os/redox/releases/tag/0.2.0) выпуск операционной системы Redox 0.2 (http://www.redox-os.org), разработанной с использованием языка Rust и концепции микроядра. Наработки проекта распространяются (https://github.com/redox-os/redox) под свободной лицензией MIT. После сборки систему можно опробовать при помощи VirtualBox или QEMU.
Пользовательское окружение в Redox построено на базе графической оболочки Orbital. Операционная система использует концепцию микроядра, при котором на уровне ядра обеспечивается только взаимодействие между процессами и управление ресурсами, а вся остальная функциональность вынесена в библиотеки, которые могут использоваться как ядром, так и пользовательскими приложениями. Все драйверы выполняются в пространстве пользователя в изолированных sandbox-окружениях. Для совместимости с существующими приложениями предоставляется специальная POSIX-прослойка, позволяющая запускать многие программы без портирования.
Redox развивается в соответствии с философией Unix c заимствованием некоторых идей из SeL4, Minix и Plan 9. В системе применяется принцип "все есть URL". Например, для записи в лог может использоваться URL "log://", для взаимодействия между процессами "bus://", для сетевого взаимодействия "tcp://" и т.п. Модули, которые могут быть реализованы в форме драйверов, расширений ядра и пользовательских приложений, могут регистрировать свои обработчики URL, например, можно написать модуль обращения к портам ввода/вывода и привязать его к URL "port_io://", после чего можно использовать его для доступа к 60 порту через открытие URL "port_io://60".Проектом также развивается собственный пакетный менеджер (https://github.com/redox-os/pkgutils), набор стандартных утилит (binutils, coreutils, netutils, extrautils), командная оболочка ion (https://github.com/redox-os/ion), vim-подобный текстовый редактор sodiumъ (https://github.com/redox-os/sodium) и файловая система TFS (https://github.com/redox-os/tfs), развиваемая на основе идей ZFS (модульный вариант ZFS на языке Rust). Конфигурация задаётся на языке Toml (https://github.com/toml-lang/toml). Система поддерживает запуск на процессорах с архитектурой x86_64 c VBE-совместимой графической картой (nvidia, intel, amd), AHCI-дисками и сетевыми картами на базе чипов E1000 или RTL8168.
Из новшеств, добавленных в выпуске Redox 0.2, можно отметить:
- Проведение оптимизации производительности;
- Новый системный вызов sys:iostat для инспектирования открытых файлов;
- Поддержка изменения размера и прокрутки в редакторе;
- Расширение возможностей командной оболочки;
- Возможность установки пакетов;
- В графическом окружении выполнен рефакторинг панели программ.URL: https://github.com/redox-os/redox/releases/tag/0.2.0
Новость: http://www.opennet.me/opennews/art.shtml?num=46459
Амбициозность восхищает! Желаю удачи проекту.
Какое у неё предназначение и позиционирование? Потому что могут, научный интерес, just for lulz, proof of concept или глобальные планы по захвату мира? Или так развивают Rust, посредством написания ОС? Кто пишет и на какие деньги? Для каких устройств предназначена? Практическое применение?
Первый умный человек на опеннете, что написал выше, задает правильные вопросы.
пилится небольшой командой энтузиастов как пруф оф концепт джаст фор лулз
тогда этот проект загнется сразу как только разработчики столкнуться с настоящими проблемами
> Или так развивают Rust, посредством написания ОС?Думаю вот это ^^^. Ну и как ещё выучить новый язык, если не написав на нём <s>новый модный плеер</s> свою ОС?
Доказательство того, что на этом языке можно написать ОС. Все приличные языки такие доказательства имеют. См C#, Java, C++.
>> Практическое применение?Однажды ты проснешься, а 90% установок в мире — ОС с драйверами в юзерспейс, например.
> Однажды ты проснешься, а 90% установок в мире — ОС с драйверами в юзерспейс, например.В Linux уже очень давно реализуют и файловые системы и, даже, драйверы в user space (есть проект, который прокидывал драйвера PCI устройств (сетевых карт) в пользовательский процесс без особых потерь в производительности, да и сейчас есть несколько проектов, которые реализуют весь сетевой стек вместе с драйверами в пространстве пользователя). Только вот делают это, когда нужно, а не только_так_и_никак_иначе_потому_что_так_надо. В результате получается и максимальная скорость работы за счет отсутствия копирования данных между контекстами (и более эффективного использования кешей CPU) и надежность для драйверов устройств, которые хоть кому-то нужны и спецификации которых открыты (потому что при обнаружении ошибки, драйвер оперативно исправят) и возможность выноса в пользовательское пространство того, что там и должно быть. Т.е. по сути в линукс можно делать драйвера и в ядре и в пространстве пользователя.
Но только этого подхода фанатам микроядра и других ПравильныхТехнологий не понять.
P.S. Это относится только к проектам, предназначенным для широкого применения. Хобби-проекты, которые пишутся для себя могут использовать что угодно, главное чтобы автор был доволен.
>> бла-бла-блаС драйверами в юзерспейс by design, уважаемый Болген.
Можете подсказать что за проект с пробросом PCI ? Для общего развития, так сказать.А если подумать, то в будущем я думаю в Linux через опции сборки ядра можно будет указать какой драйвер будет собираться: для работы в userspace или модуль ядра, или же статическим линком. Это логичный шаг в развитии ядра как следующий этап от перехода, подобно тому как был переход от монолитного статиченого ядра, к ядру с динамическими модулями. Это не вопрос "будет или не буде" - это вопрос "когда будет".
>> В Linux уже очень давно реализуют … даже, драйверы в user space (есть проект, который прокидывал драйвера PCI устройств (сетевых карт) в пользовательский процесс без особых потерь в производительности, да и сейчас есть несколько проектов, которые реализуют весь сетевой стек вместе с драйверами в пространстве пользователя).
> Можете подсказать что за проект с пробросом PCI ? Для общего развития, так сказать.
спасибо, интересно
> Можете подсказать что за проект с пробросом PCIПроси у tailgunner на LOR'е. Я забыл название проекта. Там PCI драйвера сетевых карт реализовывали в user space. Это было гораздо раньше dpdk.
К сожалению на LOR не хожу принципиально из-за модераторов-пи#арасов.
> выпуск операционной системы Redox 0.2 (http://www.redox-os.org), разработанной с использованием
> языка RustЖду с нетерпением коллег с вердиктом:
«Оно ни по произвoдительности, ни по фичaм, ни по поддержке железа никак не дотягивает до линукса, а значит очередной хипстeрский убивeц Си облaжался!1»
Ненужно, написанное на ненужно.Так пойдет?
Surprise! По производительности местами рвёт сишные проги (там бенчмарки не голой ОСи, а прикладные задачи, например DNS-сервер).Вообще не удивлён, язык в сложном ПО уже перестаёт быть бутылочным горлышком. Всё сложное ПО пишут "тормозных" на питоне или жабе, а "быстрый" си никому нафиг не нужен.
И пример, МонгоДБ написано на сях. Полнотекстовый поиск просто 3.14здц какой тормозной, по моим бенчмаркам в _1000-10000_ раз медленнее, чем чисто жабовый Lucene (милисекунды против от 5с до 20мин). Вот такой былинный отказ у "быстрого" си. Скоро на Растике всё начнут писать и пока-пока могучий си по кличке стэковерфлоу.
нууу на asm тоже можно делать тормозной софт.
Зако_пайте уже давно монго, Постгре давно быстрее на родных монговских задачах. И надежнее и АСИД.
Сон такой приснился? Ну, во сне чего не бывает, хорошо хоть без ссылок на тесты!
Не все способны осилить SQL, и уж тем более - грамотное построение баз, смиритесь с этим. Для них существуют монги и прочий трэш.Нет, есть места, где noSQL действительно даст реальный выигрыш в силу отсутствия транслятора запросов, но это скорее совсем уж примитивные и критичные к производительности сегменты приложений, и ни разу не те приложения, под которые noSQL сейчас усиленно сватается.
> Нет, есть места, где noSQL действительно даст реальный выигрыш в силу отсутствия
> транслятора запросов, но это скорее совсем уж примитивные и критичные к
> производительности сегменты приложений, и ни разу не те приложения, под которые
> noSQL сейчас усиленно сватается.Если ты не троль, а на самом деле заблуждаешься, то расскажу тебе правду, по секрету:
-самые тупые задачи - голый НОСКЛЬ
-задачи средней сложности - РСУБД
-задачи большой сложности и или большой объём - НОСКЛЬ плюс аппсервер, а потом и распределенный вычисления.Если ты ни с чем кроме п.1 не сталкивался, с неким поползновением в п2, то когда школу закончишь, возможно что-то изменится :) главное поменьше пиши, побольше читай. Удачи, дружище! :)
>> Нет, есть места, где noSQL действительно даст реальный выигрыш в силу отсутствияИ ещё, следующая задача: построить граф связей по ЕГРЮЛ (10 млн юрлиц, в каждом от 1 до нескольких тысяч учредителей, 1 руководитель, 1 дочка, 1 головное, одная управляющая компания). Потом быстро искать по этому.
Работаю с Neo4J, скорость радует.
Удачи работать с этим из Слона 8))))
Гениальный пример - в обсуждении Монго (сливает всем) вставить пример на преимущество графа на граф-онли базе.А лучшее решение, на мой взгляд - гибридные модели вроде OrientDB и более близкая интеграция с ORM чем трансляция через слой SQL.
> Гениальный пример - в обсуждении Монго (сливает всем) вставить пример на преимущество
> графа на граф-онли базе.Тут в другом проблема. Распихаем документы в document-based storage, реляцию в SQL, графы в граф-онли...
А потом дружно за***мся поддерживать сразу три движка и коннектора.
Хотя для некоторых задач оправдано. Если бюджет позволяет.
Не вижу проблем построить граф как с реляционной БД так и с noSQL. Идентификаторы и признаки связи много памяти как бы не жрут.
> Не вижу проблем построить граф как с реляционной БД так и с
> noSQL. Идентификаторы и признаки связи много памяти как бы не жрут.Уже писал другим ораторам. Можно всё загрузить в Слона. Вопрос как это будет работать по сравнению с noSQL. Тут кто-то выше ляпнул, что Слон давно побеждает NoSQL (не Монго, а NoSQL). Так толсто, что я повёлся 8)))))
Для информации: импорт 20млн объектов и 50млн связей в Neo4j занимает 2 минуты на девелоперской машине (без ССД). Проход по графу пока не тестил, но по бенчмаркам в Инете, на порядки быстрее любых костылей на nosql или рсубд.
Если тебе можно жалобно заплакать и сказать "дядя не бейте, тут надо просто подождать относительно небольшое число секунд и запрос отработается", не надо делать выводов, что везде так. Кровавый ынтырпрайз не таков 8)))))
Ну да, я верю, что ты граф по ЕГРЮЛ строишь в реалтайме каждую секунду, и даже не кешируешь при этом.
> Ну да, я верю, что ты граф по ЕГРЮЛ строишь в реалтайме
> каждую секунду, и даже не кешируешь при этом.Закончил тесты, pure java решение Neo4j - скорость поиска shortestpath по графу с 17млн объектами 10-12 милисекунд (при глубине 10 шагов). Граф строится 1мин. ОЗУ 3.5ГБ ест. Шах и мат, слоник...
Ну и да.Ну вот реальная задача из жизни. Call-центр, 1.2 миллиона вызовов в месяц (40+К звонков в сутки). У каждого вызова могут быть дочерние вызовы (переводы звонка), надо найти ещё входной номер, потом очередь, пройти по цепочке очередей, найти агента в очереди, взять имя этого агента, при наличии внешнего номера - взять DID, определить время звонка и итог - отвечен, не отвечен, свалил в другую цепочку очередей, свалил на мобилку, etc., отфильтровать лишнее (например звонки от DID или мобильников агентов), всё это распихать по категориям/географии/клиентам/подразделениям, и выдать в виде агрегата по какому-либо признаку.
Всё это надо сделать за относительно небольшое число секунд, т.к. это "срезовая" выборка по запросу пользователя, с пачкой неизвестных заранее критериев, которые пользователь может "подкручивать". Может быть как за месяц, так и за произвольный период.
MariaDB/TokuDB/8G RAM. В качестве диска - SAN/iSCSI, достаточно нагруженный, т.е. "пилить" "диском" нежелательно. Работает и не жужжит.
К чему это всё? А к тому, что дело зачастую оказывается вовсе не в движке БД. По аналогии с автомобилем.
>"Ну вот реальная задача из жизни. Call-центр, 1.2 миллиона вызовов в месяц (40+К звонков в сутки). У каждого вызова могут быть дочерние вызовы (переводы звонка), надо найти ещё входной номер"Недостаточно информации, но предварительно - объем данных такой, что можно делать хоть на чём, чтобы отвечало за "относительно небольшое число секунд", хоть на sqlite.
А вот чтобы отвечало за "относительно небольшое число МИЛИСЕКУНД", welcome to NOSQL.
Если тебе разрешил насяльника, чтобы всё тупило или ты смог его убедить, что по-другому невозможно, возьмите с полки пирожок 8)))))
Граф по ЕГРЮЛ за несколько миллисекунд? Сочувствую, чо. Ну и кеширование не зря придумали.
Маленький нюанс. Есть еще этап проектирования структур данных. Можно так спроектировать, что будет тормозить, а можно так, что все сделается 1 запросом и быстро.
Ну например из последнего, 1.1 терабайта XML-ек с ЕГРЮЛ. XML-ки на русском, например <сведдолжнфл>блабла</сведдолжнфл> 8) Глубина порядка 5 уровней, количество уникальных элементов около 500. XSD нет.В Монгу грузанул за несколько часов, включая проганье. Потом индексы построил на нужных полях (на 1-2-3-4 уровнях) без проблем.
Флаг в руки грузить это в Слона, реляционный мой голубчик.
Загрузил егрюл в PG с реляциями и индексами. Конечно, закодировано это было не за несколько часов, а за неделю, но результат - полноценная аналитическая платформа
> Загрузил егрюл в PG с реляциями и индексами. Конечно, закодировано это было
> не за несколько часов, а за неделю, но результат - полноценная
> аналитическая платформаСвежо питание... 50млн xml-ек по 300-500 записей, разложенных на _минимум_ 20 таблиц. Только загрузка заняла намного больше недели.
Потом собирать карточку - join из 20+ таблиц. Доооо... полноценная аналитическая платформа.
45 таблиц. 9 млн. организаций, 82 млн записей Егрюл. Устаревшие XML-ки не грузились.
Если все, что тебе нужно от базы - собрать карточку, - конечно, тебе не нужна РСУБД, можно практически без парсинга XMLи эти грузить. Но и сбор карточки JOINом 45 таблиц проходит с вполне приемлемой производительностью.
А я бы посмотрел в сторону Apache Ignite — с одной стороны, поддержка SQL, с другой — высокая производительность и распределенный вычисления "из коробки". А персистенсом за Ignite поставил бы Cassandra.
> А я бы посмотрел в сторону Apache Ignite — с одной стороны, поддержка SQL, с другой — высокая производительность и распределенный вычисления "из коробки".До распределенных вычислений дорасти надо. Местные эксперты, судя по всему, застряли на "переросли голый nosql" и "ну теперь всё кульDBA могучего Слона, который всех рвёт".
До хайлоада ещё как до луны 8)))) зачем им РВ?
> 45 таблиц. 9 млн. организаций, 82 млн записей Егрюл. Устаревшие XML-ки не
> грузились.
> Если все, что тебе нужно от базы - собрать карточку, - конечно,
> тебе не нужна РСУБД, можно практически без парсинга XMLи эти грузить.
> Но и сбор карточки JOINом 45 таблиц проходит с вполне приемлемой
> производительностью.Полный показ карточки это одна из задач. Работа с разными полями, разумеется, тоже есть.
>"сбор карточки JOINом 45 таблиц проходит с вполне приемлемой"
Эхехе, представляю :)))) Вообще тут задвигали что "слон давно рвёт Монгу". Я даже не буду приводить среднее время ответа, чтобы вы не комплексовали. Намекну, что иногда это меньше 1мс (на одном сервере с прогретым кешем) (т.е. в журнале округляется до 0мс) 8))))
p.s. А грузилась база сколько? 8))))
> 45 таблиц. 9 млн. организаций, 82 млн записей Егрюл. Устаревшие XML-ки не
> грузились.
> Если все, что тебе нужно от базы - собрать карточку, - конечно,Кстати, ни в жизнь не поверю, что ты разобрался с ЕГРЮЛ за неделю, включая кодинг. И xsd на сайте налоговой кривой, там не проставлены min/max occurrences в итоге любое поле может быть пустым или единичным элементом или списком. Плюс всякие фирменные фишки в духе - у учредителя в выписке от 2015 года проставлен ИНН, в выписке 2016 не проставлен. Или например в последней версии у ЕИО должность ликвидатор. Дык, это потому что ЮЛ ликвидируется, а реальная должность в предыдущих выгрузках. А ещё приколы - в выгрузке 2014 контора действует, 2015 - ликвидирована - в 2016 регистрация аннулирована судом 8)))) все эти нюансы и многие другие пролетели мимо тебя как фанера мимо Парижа 8))))) либо ты очень сильно приврал про неделю.
Казалось бы, при чём тут noSQL. Правильно казалось.
P.S. XSD нашел, хоть и пришлось погуглить немного
и эти люди будут рассказывать нам сказки о bigdata?
> В Монгу грузанул за несколько часов, включая проганье. Потом индексы построил на
> нужных полях (на 1-2-3-4 уровнях) без проблем.Ключевой момент - что ты не тебе заниматься поддержкой этого хлама, особенно когда рассинхронизируется.
"Я слабал за полчаса базу и грузанул терабайт" - можно сказать про любую БД с нормальным дисковым массивом.
> 1.1 терабайта XML-ек с ЕГРЮЛБудем честными: это не много. Сколько самих XML'ок-то? Миллионов 20 наберётся хотя бы?
> Постгре давно надежнее.Нет.
Боже ж мой. Как так можно-то?> Surprise! По производительности местами рвёт сишные проги (там бенчмарки не голой ОСи, а прикладные задачи, например DNS-сервер).
ни 1 нормальный программист не напишет такое, т.к. ЭТО ЖЕ ВСЕМ ОЧЕВИДНО ЧТО результат сильно зависит от реализации.
лютый жабист__ это не учел> Вообще не удивлён, язык в сложном ПО уже перестаёт быть бутылочным горлышком. Всё сложное ПО пишут "тормозных" на питоне или жабе, а "быстрый" си никому нафиг не нужен.
ни 1 нормальный программист не будет удивляться, т.к. ЭТО ЖЕ ВСЕМ ОЧЕВИДНО ЧТО результат сильно зависит от прямоты рук разработчика.
лютый жабист__ это не учел> И пример, МонгоДБ написано на сях. Полнотекстовый поиск просто 3.14здц какой тормозной, по моим бенчмаркам в _1000-10000_ раз медленнее, чем чисто жабовый Lucene (милисекунды против от 5с до 20мин).
чтобы сравнить 1 к 1 надо реализацию архитектуры Lucene переложить 1 к 1 на Си, тогда сравнение будет справедливым, т.к. в противном случае получается попытка сравнения разных архитектур, и выбор ЯП тут уже вторичен
лютый жабист__ это не учел> Вот такой былинный отказ у "быстрого" си. Скоро на Растике всё начнут писать и пока-пока могучий си по кличке стэковерфлоу.
Какой "такой"? С учетом вышеуказанных поправок ваш "такой" внезапно вырождается в пустое множество. И вообще, стековерфлоу - это проблема криворуких программистов. То есть если вы апеллируете к этому - вы признаете себя криворуким.
лютый жабист__ это не учелСлишком много недочетов. Извините, но вы - [CENSORED] :((
ps: из-за таких как вы и php мне стыдно называть себя программистом
> чтобы сравнить 1 к 1 надо реализацию архитектуры Lucene переложить 1 к
> 1 на Си, тогда сравнение будет справедливым,Ну так переложи, потом приходи 8))) Абы-кабы, а вся Бигдата тем временем на жабке плотно сидит.
Перепишешь Люсю на сях (конечно же анси, плюсы тормозные ж!), начинай Spark переписывать, Кассандру, потом всю платформу JavaEE. Удачи, дружище! 8)))))
> Ну так переложине понял с чего вдруг вам взбрело что оно мне нужно
>Перепишешь Люсю на сяхSphinx на плюсах. А вообще вот: http://lucenenet.apache.org/
Такой узкий кругозор, что ... Вы точно джабист? :)
Вы *серьезно* сравниваете маргинальный Sphinx с Lucene, который за счет своей расширяемости как бы везде и на котором 100500 продуктов, включая рызные Solr, ElasticSearch, который может встраиваться в другие продукты (полнотекст в Ignite на Lucene) и т.д. Мы использовали Sphinx в одной из компаний (несколько сотен GiB данных), но перешли на Lucene именно из-за расширяемости и возможности встраивания. По Performance при этом не потеряли, а даже немного выиграли, когда стали умнее класть данные.
(это к тому, что Sphinx — это и близко не архитектура и возможности Lucene, переложенные на C)
Интересные персонажи которые апеллируют к "как бы везде" за остутствием внятной позиции.Моя история. У одной организации в их "bigdata" пошла рассинхронизация. Под задачей сбора и обработки данных был выделен отдельный мощный сервер (реальное железо) так как код на Java. Я раскопал до причины: оказалось что сервер не справляется с обработкой потока данных, часть UDP трафика теряется. Изучение кода Java показало что сделано все это было очень грамотно, фундаментальных ускорении не сделать, то есть почти предел. Технический директор фанател от Java и до последнего хотел сохранить работающую платформу любой ценой, но после подсчета стоимости затрат на новое железо ему пришла команда сверху разобраться с проблемой на текущем сервере. Это я позже я понял что технический директор ненавидел Си, все эти аллокаторы и указатели - это оказалось слишком сложно. Кстати, я много раз встречал как ламерье фанатеет от Java, C#, Python и прочего треша, но почему это так - для меня это до сих пор не ясно.
Сделал я все на Си. Хардкорно, практически без оверхеда, на уровне системных вызовов. Со своими дефайнами и своей архитектурой потоковой обработки и хранения принятых данных. Результат: пиковая загрузка сервера 15%, средняя рабочая - 2-5%. Обычный среднестатистический ПК в качестве тестового на Core2 полностью справлялся с задачей (единственное - нужен был была быстрая дисковая подсистема, поэтому строилось на RAID).
Всего получилось 24 Кб исходного кода, один Makefile и обзорная техническая документация за приличные деньги. Этот проект - моя "Мона Лиза", моя "Джоконда", до сих пор душу радует.Это все я к тому что одежда сшитая на заказ мастером своего дела их лучшего материала всегда лучше чем что-то купленное в магазине или даже в бутиках. Хотя у большинства обычно все заканчивается как только у них становится "как бы везде". Java ориентирован на создание ширпотреба на выходе с соответствующим качеством.
> Изучение кода Java показало что сделано все это было очень грамотно,
> фундаментальных ускорении не сделать, то есть почти предел.Это ты сделал выводы или другой эксперт? :))))) Леонардо, руку отдашь, если вдруг найдётся спец, который проблему решил силами жабы?
> Это ты сделал выводы или другой эксперт? :))))) Леонардо, руку отдашь, если вдруг найдётся спец, который проблему решил силами жабы?Ты знаешь что такое граница оптимизации, или из тех студентиков которые считают что всегда можно всегда оптимизировать код? Ты вообще когда-либо видел качественный код? До меня систему на Java уже дорабатывали и копали, причем это делалось профессионально не только в плане кодописания, организовано было очень хорошо. За сопровождением того проекта в свое время стояла компания-разработчик и за это им хорошо платили. По архитектуре проекта видно что это был не г-нокод. В свое время жабы хватало но нагрузка росла и она уперлась в мощность и дальше было некуда. Меня сначала пригласили помочь понять почему происходит рассинхрон базы и у них ожидался дальнейший рост нагрузки.
Силами жабы можно решать что упирается в мощность сервера уже не было смысла? Можно было выйти в биндинги и на с++ или си, но смысл?
Все упиралось в деньги и время, т.к. надо было апгрейдить или заменять сервер. Если бы решение было не сильно быстрым, то мне бы ниче не заплатили, т.к. в итоге пришлось бы все равно нарашивать мощность сервера из-за роста нагрузки.
Java - это кузница для производства ширпотреба. Поверь мне, как бывшему Java-девелоперу который тоже не один проект сдавал в свое время.
Получилось здорово, качественно и душевно. Никаких C++, "чистый" Си.
>Ты знаешь что такое граница оптимизацииЯ просто не верю в твою былину, либо это была жлобоконтора с 4-ядерным зионом 2.5ГГЦ.
Я ещё не видел сишных прожек (winrar или pbzip не в счёт), которые бы хорошо расползались на например весьма ширпотребные 12 ядер. А уж про кластер из 4 12 ядерных тазиков и подавно.
В то время как на жабе такие проги клепаются без включения мозга на штатных компонентах.
И в нормальных конторах давно поняли, что железо намного дешевле разрабов. Это не про вас, я уже понял ;)
> Я просто не верю в твою былину, либо это была жлобоконтора с 4-ядерным зионом 2.5ГГЦ.Вот мне какое дело верите вы или нет? Судя по коментариям, вы вообще мало что можете трезво оценивать.
> Я ещё не видел сишных прожек (winrar или pbzip не в счёт), которые бы хорошо расползались на например весьма ширпотребные 12 ядер. А уж про кластер из 4 12 ядерных тазиков и подавно.
Я подозревал чтоб вы вообще мало видели хорошего кода. Вы недавно еще студент?
> В то время как на жабе такие проги клепаются без включения мозга на штатных компонентах.
Я так и понял что у вас цель - лишь бы сделать "без включения мозга", это не мое.
> И в нормальных конторах давно поняли, что железо намного дешевле разрабов. Это не про вас, я уже понял ;)
Ну у вас с понималкой вообще как-то не особо сложилось. Технический директор тоже хотел чтобы купили новое железо и перенести туда Java. Но спросили меня, т.к. я был с рекомендацией. Я сказал как есть: что прежде всего надо проверить смогу ли я сделать быстрее и только потом решать насчет апгрейда их сервер-блейда если потребуется. На разбор проблемы рассинхрона, всю организационную беготню и программирование я потратил неделю с выходными включительно. Я считаю что за потраченное мной время мне заплатили очень хорошо учитывая что я программировал дома. Задачу уложил в ДВА (!) потока, этого хватает "за глаза" и по сей день. Java бы так не смогла.
На Java писать мне как-то не солидно, хотя я и это могу очень не плохо. На С++ посолиднее будет. Мне например позорно тащить за собой целый рантайм в продакшн чтобы твой софт хотя бы запустился на нем, а вам похоже нет.
Кассандра (pure java) прекрасно ест одним серваком 200к событий и параллельно столько же отдавать может. Так что называй себя правильным именем - неосилятор жабы ;)
Посунунь СУБД и назови оппонента неосилятором Java. Ничего что Java - это язык, а Cassanda - это всего лишь СУБД? Какой-то фатальной формы гуманитаризм у вас в голове.Решение на кассандре было бы еще медленне чем специализированная разработка которую мне пришлось переписать на Си. Я думаю что бесполезно пытаться вам довести что у узкоспециализированные решения всегда обладают рядом преимуществ перед универсальными решениями. Сегодня программист обладает таким уровнем "знании", что он даже не понимает почеу asm и си всегда обгоняет любой язык уровнем выше по скорости при должной реализации.
> Посунунь СУБД и назови оппонента неосилятором Java.И? Специализированное решение на сях медленнее ПО общего назначения на жабе. Шах и мат.
Ты че, туnой? Перечитай о чем аноним пишет. Удивляюсь тому как можно было прийти к такому выводу при условии работающего мозга.
>Это все я к тому что одежда сшитая на заказ мастером своего дела их лучшего материала всегда лучше чем что-то купленное в магазине или даже в бутиках.:))) Лови ответную прохладную былину, бро!
Год назад в одном провинциальном отдельчике тимлидом был любитель Оракла и анси си. Задачу рекурсивного поиска связей между разными контрагентами (в всего базе 200к штук) решали полгода (ПОЛГОДА, Карл!). При этом решение, там и не вышло из статуса альфы. В итоге "починили" тем, что прогу научили быстро подниматься после очередного "ой, buffer overflow". Ещё она иногда жрала всю ОЗУ, это тоже "починили" перезапусками сервака. Прожка, конечно, была однопоточной. Данные лежали в могучем Оракле, обрабатывались могучим си.
Потом пару месяцев на плюсы переписывали.
В итоге, бросили нафиг. Вот они "сшитые на заказ решения от мастеров-кудесников".p.s. Сегодня к задаче вернулись, тимлида того уже нет. Я за рабочий день на базе neo4j (oops! pure java solution) поднял поиск по всему ЕГРЮЛ (17млн объектов). Вот такой он ширпотреб...
Теперь понятно среди каких "программистов" вы вращаетесь и какова их способность к организации. Да и делаете вы ширпотреб.ps: Если вы думаете что здесь, на опеннете, сидят одни тролли и школьники - вы сильно ошибаетесь. Я лично знаю нескольких местных, если бы вы только знали какие это люди..
200к это для оракла маленький объем. Такую задачу можно было решить на PL\SQL за один рабочий день с чаепитиями. И реализация на Си ничего бы не ускорило, т.к. затык в подобных задачах не в языке.
>Вы *серьезно* сравниваете маргинальный Sphinx с LuceneА была задача такая? Человек просил переписать "Люсю на сях", но люсю написали на шарпе. Алё.
Алё, где задача под Lucene, с которой не справиться Sphinx?
Алё, вы значит берете всегда Люсю, потому что ничего другого не знаете, а потом решаете задачу. И внезапно, вы после узнаете, что люся не подходит под данную задачу и умываете руки. Так? ТАК!
>Мы использовали Sphinx в одной из компаний (несколько сотен GiB данных), но перешли на Lucene именно из-за расширяемости и возможности встраивания.
Есть что возразить?
> Surprise! По производительности местами рвёт сишные проги (там бенчмарки не голой ОСи, а прикладные задачи, например DNS-сервер).Игрушечный dns-сервер в игрушечной ОС рвёт решения промышленного уровня? Мне кажется, что это не сюрприз нисколько.
> Вообще не удивлён, язык в сложном ПО уже перестаёт быть бутылочным горлышком. Всё сложное ПО пишут "тормозных" на питоне или жабе, а "быстрый" си никому нафиг не нужен.
Да, потому что есть и другие узкие места. И производительностью жертвуют в пользу других выгод. И ты совершенно зря взял "торомозные" в кавычки. Мне приходится сталкиваться с софтом на питоне, и он реально тормозной. Взять тот же calibre: казалось бы, там ведь вообще ничего делать не надо, знай себе дёргай API графического тулкита, но работает он так неспешно, будто интерфейс он отрисовывает в перерывах между решениями NP-hard проблем вселенской значимости. Он запускается примерно так же медленно как и libreoffice. Держу в системе его ради скриптов ebook-convert -- сколько там эти скрипты тормозят при выполнении мне не очень важно.
> Surprise! По производительности местами рвёт сишные проги (там бенчмарки не голой ОСи, а прикладные задачи, например DNS-сервер).Да может он никак рвать сишные проги. Ещё скажи машинный код рвет. Умный аллокатор памяти можно и на сях забабахать, да под любую задачу свой (а в расте сколько разновидностей аллокаторов?) Менеджмент памяти аналогично. Какой хочу, так и сделаю.
Тут другой момент играет роль, немного меньше скорость разработки будет. Ну и кода больше (хотя про объем это смешно, аллокатор ты один раз написал, обкатал да и забыл про него).
А так на сях и плюсах вообще что хочешь можно тварить и никакой язык со встроенным GC или подсчетом ссылок или крутым менеджером памяти никогда не сможет его догнать по производительности кода.
Реально что может побить это "умный" JIT, который анализирует код. Однако оверхед на сам JIT не забываем.
>Да может он никак рвать сишные проги
>сях и плюсах вообще что хочешь можно тварить и никакой язык со встроенным GC или подсчетом ссылок или крутым менеджером памяти никогда не сможет его догнать по производительности кода.Вы вообще в курсе, как в rust обеспечивается безопасность работы с памятью? Все проверки выполняются в compile-time. В runtime ничего этого нет. И сгенерированный машинный код может так же без накладных расходов напрямую работать с памятью как и машинный код, который был сгенерирован из исходников на си или c++.
Нет, не в курсе, я про производительность говорил.Хотя момент интересный, то есть там запрещено обращаться по индексу к аналогу вектора или проще говоря массиву? Иначе как оно проверит какой пользователь введет индекс в компайл тайме
обращаться по индексам можно. Сейчас посмотрел, что касается массивов и векторов, то там таки есть реалтайм проверка на предмет выхода за пределы. И сделано это по причине того, что индексом может быть выражение, значение которого может быть неизвестно на этапе компиляции. Но при желании можно обращаться к массиву через слайс с отключенной проверкой, но делать это придется в unsafe блоке. Так что вы метко подметили тонкий момент в языке ))).
>Иначе как оно проверит какой пользователь
> введет индекс в компайл таймеТ.е. вы не проверяете ввод пользователя? Или проверяете? Но какая тогда разница, тем более, если автоматическую так же можно отключить?
> Хотя момент интересный, то есть там запрещено обращаться по индексу к аналогу
> вектора или проще говоря массиву?Я вас разочарую, но с 70ых техники компиляции, как и возможности железок - заметно продвинулись. В современном компиляторе, имея соответсвующие ограничения ЯП, вполне можно проследить вся цепочку "ввод -> проверка -> что-то еще -> обращение к индексу".
Опять же, если вы собрались пройтись по индексам [n..m), совсем-совсем не обязательно проверять каждый возможный индекс, можно просто проверить n и m. Такие вот пироги с котятами.
>можно просто проверить n и mЭтого недостаточно. В самой ячейке может быть мусор. Это тоже надо самому проверять? И зачем этот rust нужен, если все делаеть надо как в сишке? Что он проверяет? Банальщину? Это приходит с опытом.
>>можно просто проверить n и m
> Этого недостаточно.Этого обычно достаточно. Особенно при использовании итератора. А если недостаточно, компилятор может и предупредить. Но да, бензопилу можно легко запороть, наткнувшись на гвоздь, поэтому суровые погромистские мужики и далее будут использовать топор.
> В самой ячейке может быть мусор. Это тоже надо самому проверять?
Т.е. у вас может быт массив или вектор с мусором, но вы, все такие из себя красивые, волевым решением отменяете проверки?
В общем, сильно притянуто за уши.
Опять же, отследить инициализацию и высказать свое фи по этому поводу, для современного компилятора не сложнее аналогичного действа анонима опеннета.> И зачем этот rust нужен,
Чтобы подгорало у анонимных знатоков опеннета, очевидно же!
> если все делаеть надо как в сишке?
Нет, не надо. Надо хотя бы поверхностно ознакомиться с предметом обсуждения.
> Что он проверяет? Банальщину?
Время жизни, владения с заимствованиями. Банальщина это только на уровне хелловорлдов, а вот с увеличением размеров проекта быстро выясняется, что человек в способности прослеживания всего этого как-то сильно уступает железке и начинает городить абстрактности и всякие счетчики ссылок, что опять же хорошо урезает главный аргумент - производительность.
> Это приходит с опытом.
Опять будет про "криворукость неосиляторов" и "вот настоящие Погромисты…"?
Ну так welcome to the real world, Neo. Количество CVE и популярность в более-менее крупных проектах всяких дополнительных анализаторов, как бы, намекают.
>Опять же, отследить инициализацию и высказать свое фи по этому поводу, для современного компилятора не сложнее аналогичного действа анонима опеннета.Возможно. Так почему в этом примере мой gcc не ругается?
#define ARYSIZ 10
extern int
main ()
{
int i = ARYSIZ;
int test[ARYSIZ];while (--i >= 0)
test[i]++;return 0;
}
>>Опять же, отследить инициализацию и высказать свое фи по этому поводу, для современного компилятора не сложнее аналогичного действа анонима опеннета.
> Возможно.
> Так почему в этом примере мой gcc не ругается?
> код на сиМы тут вроде о современных компиляторах современных ЯП. Cм.
> В современном компиляторе, имея соответсвующие ограничения ЯПну и тред с веткой тоже о расте. Поэтому, конечно же логично "опровергать" наличие фичи, приводя в качестве примера сишку. Вы еще скажите, что отслеживать время владения совершенно невозможно, потому что gcc это не умеет.
Это раз.А теперь, фокус:
fn main() {
let mut array: [i32; 3];
for x in &array {
print!("{} ", x);
}
}
https://play.rust-lang.org/?gist=4b3b406d706ec597cd525090fa9...
rustc 1.16.0 (30cf806ef 2017-03-10)
error[E0381]: use of possibly uninitialized variable: `array`
--> <anon>:3:13
Это два.Третье:
Если вместо бессмысленного и беспощадного примера, который практически ничего не делает, вставить что-то более осмысленное ("побочные эффекты" или "взаимодействие с миром"):
#define ARYSIZ 10extern int
main () {
int i = ARYSIZ;
int test[ARYSIZ];while (--i >= 0) {
if (test[i] > 5) return test[i];
}
return 0;
}
то вдруг, совершенно внезапно:
gcc -Wall m.c
m.c: In function 'main':
m.c:10:14: warning: 'test[i]' may be used uninitialized in this function [-Wmaybe-uninitialized]
if (test[i] > 5) return test[i];
^
m.c:10:30: warning: 'test[i]' may be used uninitialized in this function [-Wmaybe-uninitialized]
if (test[i] > 5) return test[i];
>if (test[i] > 5) return test[i];Внезапно, все полезно, а предупреждения нет:
#include <stdio.h>
#define ARYSIZ 10extern int
main ()
{
int i = ARYSIZ;
int test[ARYSIZ];
while (--i >= 0)
test[i]++;for (i = 0; i < ARYSIZ; i++)
printf ("%d: %d\n", i, test[i]);if (test[0] == 10)
printf ("ok.jpg\n");return 0;
}
>>if (test[i] > 5) return test[i];
> Внезапно, все полезно, а предупреждения нет:Т.е. два первых пункта ты бодро проигнорировал и опять "опровергаешь" возможность каких-то фич их отсутсвием в сишном компиляторе? o_O
Я ничего не опровергаю. Пример не из воздуха, если что. Рабочий такой школоло-код. Дай, пожалуйста, версию на раст. Смысл не в том, где ты поставил return array[i], а в том, что "инициализация", неверная, произошла, результат после такого будет ИНЫМ. Не тем, что думает разработчик.Ты же сказал, что современные компиляторы улавливают, где не было должной инициализации. Так вот, в примере есть инициализация, но кривая. Надеюсь, у тебя хватает компетенции понять в чем прикол.
> Я ничего не опровергаю.Конечно же нет. Ты просто пишешь, что гцц этого не умеет, а значит этого не умеют компиляторы в целом.
> Пример не из воздуха, если что. Рабочий такой
> школоло-код. Дай, пожалуйста, версию на раст.https://play.rust-lang.org/?gist=77c9fe2a696cdad1720b881a797...
с инициализацией.
без:
https://play.rust-lang.org/?gist=95075e346ec65e2a6389e028fad...Оно?
> Смысл не в том, где ты поставил return array[i], а в том, что "инициализация", неверная, произошла,
> результат после такого будет ИНЫМ. Не тем, что думает разработчик.Слушай, ну ведь слишком же жырно, а?
> Ты же сказал, что современные компиляторы улавливают, где не было должной инициализации.
Не передергивай. Ты прекрасно понял, что за компилятор и ЯП имелись в виду. Хотя как раз растом это не ограничено, просто в нем более наглядная демонстрация.
> Так вот, в примере есть инициализация, но кривая. Надеюсь, у тебя хватает компетенции понять в чем прикол.Классика опеннета. Если нечего возразить...
Вижу проход и операции с неициализированным куском памяти. Не вижу никаких приколов или, тем более, инициализации. Видимо, не хватает компетентности.
>Оно?Оно. Спасибо.
>Классика опеннета. Если нечего возразить...
Хватит петушиться. Если такой гордый, мог бы не отвечать.
Т.к. я не умею в раст, хочу посмотреть на аналогичный пример выше (там где все полезно :). Не такая тривиальная задача для компилятора, если вдуматься.
> Т.к. я не умею в раст, хочу посмотреть на аналогичный пример вышеА что там уметь для хелловорлда-то?
> Не такая тривиальная задача для компилятора, если вдуматься.Угу, компилятор может отследить владения и время жизни переменных(для тех, кто в танке: да, для этого требуются некоторые ограничения ЯП и/или иногда подсказки), но проследить инициализацию -- ни-ни!
> Surprise! По производительности местами рвёт сишные проги (там бенчмарки не голой ОСи,
> а прикладные задачи, например DNS-сервер).Дай линк на этот бенчмарк
>си по кличке стэковерфлоуПервый раз слышу о такой кличке у си. А что, на rust нельзя получить тот же стэковерфлоу если сделать глубокую рекурсию? Уж на жабе это точно можно и Вы как лютый жабист не можете этого не знать ))
https://doc.redox-os.org/book/introduction/will_redox_replac...
Внимание опасность! Пыщ!
Торрентовский iso файл не совпадает с файлом с гитхаба.
Ну хоть кто-то проверяет!
за этой ОС будущее.
этот комент должен быть здесь
Занимайте очередь за GNU/Hurd.
> за этой ОС будущее.Ну да. Причём всегда.
Главное чтоб не забросили пилить поддержку железа в пользу не скучных обоев.
Где троекратное повторение слова "безопасность", как во всех новостях по руст, где заверение что глюки исключены безопасным языком?
Не все глюки, а только связанные с памятью. Проблемы в бизнес логике никакой язык не исправит за разработчика.
Ну если разработчик мyдaк, то да канешно.
ненавижу хелоуворлдщиков
Что мы тебе сделали и как?
> Что мы тебе сделали и как?Не приняли в клуб, очевидно.
> Не все глюки, а только связанные с памятью. Проблемы в бизнес логике
> никакой язык не исправит за разработчика.Именно это я и имел в виду. Фанаты хруста все как один выдают отсутствие реального опыта поддержки серьезных продуктов. Нет там "стаковерфлоу", а есть масса логических архитектурных ошибок, помноженных на многократные рефакторинги, переделки.
Оставлены только безопасные глюки.
Лучше бы модули дров и пользовательского окружения для SeL4 делали.Так нет, надо сделать очередной Minix, потешить эго.
https://doc.redox-os.org/book/introduction/why_redox.html
А вот на Go нет ни одной ОС, что какбы намекает.
потому что не нужен, эта ось все равно не взлетит, будут 1.5 калеки её использовать
Тем не менее, Rust пригоден для написания ОС (пример - эта новость), а Go нет.
>> Rust пригоден для написания ОС (пример - эта новость), а Go нет.ЕМНИП, разработчики Go придерживаются того же мнения... В чем соль?
На go тоже можно писать ос. на хабре даже был цикл статей по этому поводу.
На раузмность тех, кто использует Go по прямому назначению, а не на поиграться?
Потому как Go предназначен для прикладных задач, а Rust изначально разрабатывался как системный.
Rust изначально разрабатывался как язык для движка Firefox — это прикладная задача. Go разрабатывался как язык для програмирования облачных систем в Google — это системная задача, не прикладная.
> язык для движка ... — это прикладная задача
> язык для програмирования облачных систем ... — это системная задача, не прикладнаяЯ не понял классификации и её критериев.
lang/go собирается из исходников за 7 минут, включая go14.
lang/rust требует для своего построения полтора часа.
Разницу во вложенных усилиях чувствуете?
Изя, ты опять выходишь на связь?
А линукс ядро на каком-нибудь RPI Zero будет собираться несколько дней. Это значит, что раст лучше, а го - ещё лучше?
Важно не количество затраченных усилий, а результат. В Go изначально скорость сборки ставилась одной из основных целей и каждый релиз этому уделяют значительное внимание, несмотря на то, что он уже реактивный на фоне C, С++ или Rust. Так что создатели Go отлично поработали и продолжают работать над достижением поставленных целей.
> Важно не количество затраченных усилий, а результат.В эпоху непрерывного процесса тестирования, интеграции и развётывания кода скорость пересборки - один из важнейших показателей готовности программы к продакшену. Что будут делать тестировщики, пока компилируется несложная программа на Rust'е? Тестировать предыдущую версию или быстрее перейдут туда, где работают с Go и чисто интерпретативными инструментами?
Я тебе открою тайну, работа тестировщика не ждать бинарника, а писать тесты. Далее все настолько автомазируется, что тестер в случае ручного тестирования потратит в разы больше времени на проведение самих тестов, чем на ожидание, когда скомпилируется программа. Ну, и про юнит-тестирование забывать не надо.
> В системе применяется принцип "все есть URL".А браузер в системе есть? )
Вообще интересная новость, было бы классно, если бы на расте смогли бы запилить что-то реально работающее.
>> В системе применяется принцип "все есть URL".
>А браузер в системе есть? )Скачай те жалкие 18Mb исошки да посмотри.
>Вообще интересная новость, было бы классно, если бы на расте смогли бы запилить что-то >реально работающее.
Ты уже камент оставил в новости о чем-то реально работающем, запиленном на расте.
> написанная на языке RustЗачем написанная?
на главной странице сайта большими буквами об этом написано
> bring the innovations of Rustхм.. и что это за инновации такие?
Хотя бы то, что проги на Расте не падают.
> Хотя бы то, что проги на Расте не падают.Еще один helloworld заявляет о безглючности своего кода.
Так, красивые обои есть, калькулятор есть.. годнота!
судя по коммитам на гитхабе, проект развивает один человек плюс пару человек подтанцовки...может раст в 10..100 раз быстрее Си в плане скорости разработки?
Как и го ибо не нужно легаси тащить и читать легаси документацию к новым стандартам.
> легаси документацию к новым стандартамШта?
Что-то странное. С оф.сайта есть ссылка на github-репозиторий https://github.com/redox-os/redox
Странность заключается в том, что проект этот пилит один человек и там всего 3000 строк на rust.
> Странность заключается в том, что проект этот пилит один человек и там
> всего 3000 строк на rust.Извиняюсь, там вложенные репозитории. Не сразу заметил.
>> Странность заключается в том, что проект этот пилит один человек и там
>> всего 3000 строк на rust.
> Извиняюсь, там вложенные репозитории. Не сразу заметил.Круто. Мужики уже 2 года пишут ОС на Rust. Я так понимаю, в основном в 2 рыла. Интересно, кто их кормит при этом, и каковы цели проекта.
[здесь должен быть большой грустный смайлик]Но вот зачем каждую студенческую поделку в новости вытаскивать - понятно слабо.
Это первая рабочая FOSS OS на Rust с полноценным GUI, а это событие. Очевидно же!
Полноценный гуи через vbe. Пишите есчо.
А вам новую ОС выкати и сразу со steam-клиентом в первом же выпуске?
Вообще, по идее, сейчас не нужна новая ОС-убийца линуха или там винды. Реально стрельнула бы _безопасная_ ОСЬ умеющая притворяться одним типом железки для запуска в виртуалке. Ей ГУЙ вообще не нужен! serial хватит. Соответственно, на железе запускается XEN или QEMU, в инет никак не торчащий, все сервисы обслуживает безопасная кульОСЬ. Ляпота.
"Доступна операционная система Redox 0.2, написанная на языке Rust "
"...разработанной с использованием языка Rust"
Было бы гораздо больше пользы, если бы эта ось была рассчитона на iot/роутеры. В случае с десктопом шансов на практическое применение ровно нуль - по той же причине, что у syllable, haiku, kolibri и подобных - тупо нет драйверов.
А если заточиться под определенное железо? Как это сделала Apple?Зачем делать плохо для все устройств, если можно сделать хорошо для одного класса устройств?
И в данном случае да. Кто спонсирует разработку? С какой целью? Какая модель монетизации? Пока ощущается как "хипстеры на взлете". Но ведь мотивация может пойти вниз, а без должной денежной подпитки ничего не получится.
Основной разработчик побирается на патреоне. 1000 баксов ежемесячно уже есть. А запрашивал 2000/4000.
Даже для определённого железа сейчас тоже нужны драйвера. Нельзя просто взять и написать драйвер только для одного видеочипа, потратив на это в 10 раз меньше человекочасов, чем для 10 других того же семейства. Помимо драйверов есть ещё куча проблем. Почему, например, даже для роутеров или за основу ведроида был выбран линукс, а не бсд? Хотя бсд лицензия более вкусна для корпораций. Всё из-за этих самых фич, которые уже есть в линухе и которые себе дороже выйдет допиливать в *бсд или редоксе. Я бы с бОльшим пониманием отнёсся, если бы кто-то задумал переписать ядро линуха на расте. С совместимостью по вызовам, не по abi, ессно.
Когда уже забудут про архаизм и убожество файлов и урлов?
Человек ведь не открывает файл, он хочет получить текст или картинку, функцию или действие. И адрес сайта тоже мало интересует человека, он интересуется все теми же текстами или картинками, функциями или действиями.
Пора писать ОС в парадигме реальности а не высосанных из пальца архаичных абстракций.
Поддерживаю полностью. Потому что снова пишут программисты для программистов, а не люди для людей.
люди для себя-то ниче не могут, а вы хотите чтобы для других людей..
Человеку и не нужно видеть эти урлы. Это внутренний механизм адресации, как бонус - удобный для разработчика.
> Пора писать ОС в парадигме реальности а не высосанных из пальца архаичных абстракций.правильно. Будет ос с командами вида "отобразить мне последовательность байт (lest significant first) со смещением xxx от yyy на устройстве nnn как картинку формата png на устройство mmm в координатах x1y1x2y2 с z=topmost"
Это вот - реальность. А файлы, урлы, функция "открыть" - это как раз удобные высокоуровневые абстракции. Чем высокоуровневее - тем неэффективнее и тем менее универсально и понятно. (в очень высокоуровневой системе, можно, думая что скопировал картинку, вместо этого скопировать подпись под картинкой. Ну да, ну да - "полная флэшка ярлыков" - это по сути оно же, на более примитивном уровне.)
Ну или вон, тоже типичное для винды - удалил some-html-page_files\ - а оно заодно и some-html-page.html нахрен удаляет без спросу. Потому что пользователь же тyпой,чего его лишними вопросами беспокоить - все равно он ок нажмет.
>Когда уже забудут про архаизм и убожество файлов и урлов?Есть чем заменить?
>Человек ведь не открывает файл, он хочет получить текст или картинку, функцию или действие.
facepalm
Вангую, что слово "бэкап" тебе незнакомо.
>И адрес сайта тоже мало интересует человека
Особенно адрес сайта банка.
>Пора писать ОС в парадигме реальности а не высосанных из пальца архаичных абстракций.
Упаси Ктулху, не надо нам такого счастья.
В iOS так всё и есть.
Обои какие-то унылые. Одним словом скучные.
Я сюда зашел ради нескучных обоев. Я удовлетворен.
>файловая система TFS, развиваемая на основе идей ZFS (модульный вариант ZFS на языке Rust)Это достойно отдельной новости. Как там с многодисковыми хранилищами и CRC?
>все есть URLВиден уровень школоты. Все есть IRI, а то глядишь поддержку utf-8 завезут только через 30 лет.
> Виден уровень школоты. Все есть IRI, а то глядишь поддержку utf-8 завезут
> только через 30 лет.Лучше Punycode :)
Смотрю в заголовке: "...написанная на языке Rust". Заглянул в заметку. Уже "...с использованием языка Rust". Интересно, а если я теперь залезу в исходники, то выяснится, что это на самом деле старый добрый Plan 9 с файловым менеджером, написанным на Rust?
> Для совместимости с существующими приложениями предоставляется специальная POSIX-прослойка, позволяющая запускать многие программы без портирования.Кто-то может сказать что реально работает, а что нет?
Unix-way - ненужно. Можно забыть про это поделку. У нее нет серьезного будущего.
Приветствую. ОС на Rust, прикольно. А есть что-то подобное на Python?
Драйвера железа полностью в ring 3? О_о
Или, всё же, они их вынесли в ring 1 или 2?