функции, возвращающие функции.

int (*blabla(int, int, int))(int, int);

И чо?

Жаль, лицензия у ОС не GPLv3, вот была бы у Linux такая, производители бы не стали клепать закрытые неперепрошиваемые железки.

Производители бы засунули туда BSD.

Микроядро. Зачем обязательно на расте? Главное же протокол реализовать, а так, хоть на бейсике. Не?

А когда телефоны перестали быть эмбеддедом?

Что-то мне подсказывает, что вместе с unsafe, overflow и на расте без проблем можно получить.

Доки почитай, чё на форуме шуметь?

Ожидал в новости почитать.

неплохие стартовые деньги

Кикстартер в помощь.

Например?

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

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

При помощи libastral, не иначе...

Нет, при помощи, например, генетических алгоритмов. Но как я и говорил, в тему не погружался, но пятой точкой чую, что такая система сейчас вполне возможна.

А когда телефоны перестали быть эмбеддедом?

Формально, Symbian поддерживал x86 (http://i.imgur.com/M3HE1YK.png ), другое дело, что массовые устройства были embedded. В любом случае, это не отменяет тот факт, что ОС с микроядром могут быть успешными.

Главное же протокол реализовать, а так, хоть на бейсике. Не?

К черту Basic! На Java: http://jnode.org/

для ее успеха требуется поддержка железа [...] с драйверами будут проблемы.

Щаз, все подорвались писать дрова на всрасте.

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

Вроде сам линь, от того что написан на сишке, не страдает.

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

т.к. для ее успеха требуется поддержка железа и наличие разнопланового софта.

достаточно внедрить поддержку драйверов линукс

Передай ей трубку, я с ней поговорю.

Я на связи. Задавай свои вопросы.

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

Итог Nokia показал, что они, мягко говоря, не всегда принимали логичные и оправданные решения :)

гибридное оно именно потому что негибридное тормозит

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

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

В данном случае больше важна скорость доступа к памяти, т.к. потери времени на сохранение-восстановление контекста и работу с TLB.

и делает memcpy данных в адресное пространство ext4
и memcpy данные ему
и опять memcpy
и делает два memcpy в адресное пространство SATA драйвера
...

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

В данном случае больше важна скорость доступа к памяти, т.к. потери времени на сохранение-восстановление контекста и работу с TLB.

Один фиг, контекст переключать нужно не миллиард раз в секунду. Пусть одно переключение занимает много времени, но между переключениями остаётся намного больше.

Проблема шареной памяти в том что шарится она по страницам, а это большой оверхед по выравниванию

Мы же только что рассматривали вариант записи на диск. А она итак блочная :) Кроме того, передача блока подразумевает отсутствие необходимости в долгом хранении. Так что даже с оверхедом — не страшно. Передали, обработали, освободили.

а в другой раз тратят месяци работы чтоб выдавить +5% перворманса

Если речь о единовременной задаче, то это прокол маркетинга. Месяцы работы команды программистов — проще купить вторую машину и получить не +5%, а +100% прирост производительности :) Если речь о продукте для широкого использования — ну, пусть покупатель приобретёт машину на 10% более быструю.

В общем, это очень специфические запросы и проблемы. Сегодня разброс производительности парка активно работающих машин, на порядок будет, так что 5% потери на ОС тут никакой роли не сыграют.

А смысл отдавать всю страницу если мне нужно записать 10 байт ?

А 10 байт можно передать и через копирование, оверхед смешной будет :)

НИ ОДНА существующая система не годится для «простого обывателя»

Да ладно, а как же Android? :)

Микроядра хороши для изоляции процессов друг от друга, но современные реализации как были говном, так и остались. «Оптимизаторы» вносят дыры, туда куда не надо вместо того, чтоб действительно заниматься построением быстрой отзывчивой безопасной системы. Прошлое и текущее железо потворствует «оптимизаторам» и это еще один печальный факт и шаг в сторону - «не взлетит». В таком виде и правда эталонное - НЕНУЖНО

а если есть 100 машин, то добавив 101 выйграешь меньше чем если каждую машину сделать на 5% быстрее

Очень узкая специфичная задача :)

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

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

Если речь о продукте для широкого использования — ну, пусть покупатель приобретёт машину на 10% более быструю.

Нет, не так: «Если речь о продукте для широкого использования — ну, пусть откажемся от 10% потенциальных покупателей».

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

MS DOS

по средствам того же libusb
о средствам системной абстрации V4L

Млять, такая сложная руская языка.

ну, пусть откажемся от 10% потенциальных покупателей

От 0.01%

...

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

И, да, в крупном бизнесе и от 10% легко отказываются в вопросах оптимизации расходов. Посмотри, как резво тот же Гугл убивает или кастрирует проекты. Скажешь, Гугл принимает финансово неверные решения? :) В ту же степь Microsoft, Apple...

В мире опенсорса ситуация похожая. Gnome, Systemd, PulseAudio и т.п... Многие очень легко идут на потерю 1-10% пользователей ради оптимизации ресурсов разработки.

Я бы изначально сделал паскалевский вариант.

Это уже вопрос привычки: кому что ближе. Я сомневаюсь, что те же авторы паскаля задумывались об авто-типизации. Просто так получилось, что их вариант более подходящий.

Кз грамматика

У раста как-будто регулярная

Товарищ, ты генетикой одни ключи сборки на хорошем сервере под свой software stack будешь неделю считать.

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

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

Только вот есть один нюанс в расте - надо явно разыменовывать переменную при вызове функции. То есть, он в этом ещё меньше напоминает пасклаль, чем кресты.

Может, уже хватит переводить стрелки на кресты? Речь о С и Rust.

Вообще-то, он ещё в сисярпе появился.

Так это может, rust на C# похож, а не на C? (не могу сам судить, с шарпом не знаком, но слышал, что его пилили беглые дельфисты).

От 0.01%

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

Посмотри, как резво тот же Гугл убивает или кастрирует проекты.

Посмотрел, не увидел, чтобы гугл хоть раз убил проект, непосредственно приносящий прибыль. Даже от 0,01% не отказываются. В ту же степь Microsoft, Apple...

Gnome, Systemd, PulseAudio
Многие очень легко идут на потерю 1-10% пользователей ради оптимизации ресурсов разработки.

Не увидел связи.

Возможность делать более высокоуровневые абстракции там, где можно. Ну, и safety.

Для этого уже есть плюсы с их обратной совместимостью с сишным кодом. Все-таки, в rust низкоуровневое программирование прилеплено отдельной фичей к общему safe-way-ю, а не наоборот. По этой причине и громоздкие записи низкоуровневых операций по сравнению со штатными, и отсутствие таких фич как goto, сложно реализуемых и практически ненужных в языках высокого уровня.

А далее любое приложение запрашивает, скажем, /HW/UserInput/Keyboard - «дай свой API». В этом API есть две стандартных (для ОС) функции GetInfo и GetKey.

Что же мне это напоминает? Да это же Plan9! Не взлетело.

Одна из фич - безопасность работы с памятью без GC. И где это по твоему нужно, если не на низком уровне?

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

Видимо, ты говоришь о схожести ЯП глядя на используемые ключевые слова и знаки

Именно.

я оцениваю сложность портирования кода с одного на другой

У мня даже мыслей о таком портировании никогда не было (кроме вырожденных случаев, вроде C -> C++, Python2 -> Python3).

Может, уже хватит переводить стрелки на кресты?

Я просто привел кресты как курьёзный пример паскалеподобия по твоей логике.

шарп ... пилили беглые дельфисты

Не знаю, кто его там пилил, но это причёсанная Жабка, и по синтаксису, и по семантике, и по идеологии.

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

Пример С++ показывает, что работа с памятью прекрасно заворачивается в высокоуровневые абстракции без оверхеда.

Все-таки, в rust низкоуровневое программирование прилеплено отдельной фичей к общему safe-way-ю, а не наоборот.

Растовский safe-way - это повальное RAII + проверки времени компиляции + строгая типизация, они не дают рантайм-оверхеда.

По этой причине и громоздкие записи низкоуровневых операций по сравнению со штатными

Только тех, которые потенциально небезопасны, вроде арифметики указателей и nullable pointers. В safe-коде, наоборот, операции с рантайм-оверхедом намерено сделали boilerplate-ом.

Я просто против подмены понятий. Никто не говорил, что они вообще не могут быть успешными. Утверждалось, что могут быть успешными для embedded. Собственно, на серверном рынке, десктопе этого самого успеха и не видно. Думаю, и не будет. Особенно когда речь будет идти о хайлоад или отклике в любимом шутере.

В Minix 3 до недавнего времени даже динамического связывания не было.

Только http://www.helenos.org/ имеет небольшие шансы взлететь.

Что ж ты делаешь, содомит. У helenos до сих пор динамического связывания нет.

А эта тотальная обмазанность корутинами...

Что ж ты делаешь, содомит. У helenos до сих пор динамического связывания нет.

Её довольно активно пилят, однако ж.

Очередной жирный вброс от тылгуннера.

Её довольно активно пилят, однако ж.

Ага, лет 5 уже. Если не больше.

Они там хеш-таблицу запилили?

Привет всем, кто использует Линукс — Я делаю (свободную) операционную систему (всего лишь хобби, она не будет большой и профессиональной, как Андроид) для клонов 686 (ARM)

Небольшая и хорошо обоснованная провокация.

магические числа

Ты даун? Справа видно, что они значат.