Представлена (http://thread.gmane.org/gmane.comp.lang.lua.general/117370) новая гибридная распределённая операционная система Node9 (https://github.com/jvburnes/node9), в основе которой лежит вариант разработанной в Bell Lab's ОС Inferno, в котором вместо языка Limbo применяется скриптовый язык Lua, а вместо виртуальной машины DIS задействован LuaJIT (http://luajit.org/). Для обеспечения высокой эффективности обработки событий и управления потоками в проекта применяется библиотека libuv (http://docs.libuv.org). Исходные тексты операционной системы распространяются (https://github.com/jvburnes/node9) под лицензией MIT.Система предназначена как для решения традиционных задач распределённых вычислений и симуляции, так и для применения в облачных системах и сетевых системах управления и контроля. Одной из основных концепций архитектуры Node9 (https://github.com/jvburnes/node9/blob/master/doc/node9-hack...) является использование в событийно-ориентированных системах средств динамического скриптового языка, предоставляющего методы функционального и объектно ориентированного программирования. Вместо трудоёмкого определения callback-обработчиков для обработки асинхронных событий в Node9 предлагается использовать параллельно выполняемые сопрограммы Lua (coroutines), взаимодействующие с ОС через каналы обмена сообщениями. Система обладает всеми базовыми возможностями Inferno, такими как привязанные к процессам собственные пространства имён, представление всех ресурсов в виде иерархии файлов, отсутствие различий в доступе к локальным и внешним ресурсам.
При создании распределённых приложений авторы Node9 предлагают не изобретать новые способы, а воспользоваться уже проверенными технологиями Inferno. В окружении Node9 распределённые приложения строятся через связывание между собой имеющихся вычислительных узлов с развёртыванием инфраструктуры поверх единой совместно используемой иерархии ресурсов, построенной при помощи протокола 9p. Передаваемые между узлами данные могут шифроваться при при помощи SSL/TLS. Приложения на Lua могут связываться с приложениями на других языках, в которых можно использовать протокол 9p, таких как Go, Java и Chicken Scheme.
Node9 загружается в специализированную командную оболочку, поддерживающую выполнение выражений на языке Lua (Lua Shell). Приложения размещены в отдельных директориях, в которых собраны все необходимые для их работы библиотеки и файлы, что упрощает установку и удаления программ. Дополнительно предлагается простой управляющий web-интерфейс, который можно использовать в облачных окружениях вместо консоли. ОС Node9 также предоставляет обширные графическое возможности, если она установлена в хост-системе, поддерживающей шейдеры OpenGL/Vulcan.
Система развивается уже около года и уже вполне работоспособна, хотя и находится на стадии начального бета-тестирования. Из незаконченных работ отмечается завершение разработки сервисов уровня ядра и окончательный перевод уровня абстракции Inferno на libuv.
Система пока собирается только в OS X, но код изначально написан с оглядкой на обеспечение переносимости, что потребует минимальных усилий для портирования в Linux. Теоретически, Node9 может работать на любых платформах и архитектурах, которые поддерживаются в LuaJIT и Libuv, в том числе в POSIX-системах, Windows, Android, x86, ARM, MIPS.
URL: http://thread.gmane.org/gmane.comp.lang.lua.general/117370
Новость: http://www.opennet.me/opennews/art.shtml?num=42410
> параллельно выполняемые сопрограммы Lua (coroutines), взаимодействующие с ОС через каналы обмена сообщениямиЭто они чё, эрланг изобрели?
Этому до эрланга - далеко, скажем так
> Это они чё, эрланг изобрели?Это они все plan9 перепевают. Теоретически вроде круче только йайцы, по крайней мере по мнению академиков. А практически - никто не понимает нафейхоа все это надо.
Отучивайся говорить за всех. Если ты в силу своей ограниченности не понимаешь зачем это нужно, то это не значит что другие не понимают
Ограниченный - это тот кто пытается выдать желаемое за действительное, никак не желая признавать очевидное. Как можно быть такими инфантильными олухами? Надо все это кучке академзaдpoтов, поставивших расовую верноту над здравым смыслом. А весь остальной мир недвусмысленно вертел на известном месте такие прожекты. В технике по этому поводу целое понятие есть - прожектерство. Ну а сабж - образцовый пример прожЕкта, достойный парижской палаты мер и весов. Как эталон сферического прожекта в вакууме.
> Ограниченный - это тот кто пытается выдать желаемое за действительное, никак не
> желая признавать очевидное. Как можно быть такими инфантильными олухами? Надо все
> это кучке академзaдpoтов, поставивших расовую верноту над здравым смыслом. А весь
> остальной мир недвусмысленно вертел на известном месте такие прожекты. В технике
> по этому поводу целое понятие есть - прожектерство. Ну а сабж
> - образцовый пример прожЕкта, достойный парижской палаты мер и весов. Как
> эталон сферического прожекта в вакууме.Да-да, все это мы уже слышали про лисп, но почему-то во многих языках нынче GC юзают. Но аноним конечно же лучше знает кому, что и как надо правильно делать?
> Да-да, все это мы уже слышали про лисп, но почему-то во многих
> языках нынче GC юзают. Но аноним конечно же лучше знает кому,
> что и как надо правильно делать?Хз, я не фанат gc. Вы ими и пользуйтесь, если вам это надо. Можете также пользоваться lisp-ом. Или чем там еще. А мне этот ваш lisp - ни в п...у, ни в красну армию.
>> Да-да, все это мы уже слышали про лисп, но почему-то во многих
>> языках нынче GC юзают. Но аноним конечно же лучше знает кому,
>> что и как надо правильно делать?
> Хз, я не фанат gc. Вы ими и пользуйтесь, если вам это
> надо. Можете также пользоваться lisp-ом. Или чем там еще. А мне
> этот ваш lisp - ни в п...у, ни в красну армию.А ты хоть строчку кода написал-то, умник? Если да, то читай до просветления http://www.nestor.minsk.by/sr/2003/07/30710.html
Надо её в xen портировать
При всем моём уважении к ним, ко всему *9 и инферно в частности, но портировать это для xen... не выйдет, ибо это ОС-паразит, ей нужна другая ОС под ней, та, что обеспечивает все низкоуровневые операции с железом и прочее.
> При всем моём уважении к ним, ко всему *9 и инферно в
> частности, но портировать это для xen... не выйдет, ибо это ОС-паразит,
> ей нужна другая ОС под ней, та, что обеспечивает все низкоуровневые
> операции с железом и прочее.значит и ерланг с хаскилем тоже нельзя в хене запускать.
Их не пытаются называть ОС. Впрочем, хаскель - в любом случае тот ещё сферический конь в вакууме.
https://github.com/galoisinc/halvm
http://erlangonxen.org/
А некоторые вот уже и без Xen учатся обходиться https://github.com/mato/opam-rumprun
> А некоторые вот уже и без Xen учатся обходиться https://github.com/mato/opam-rumprunВо, отличные примеры сферических коняшек в вакууме.
> значит и ерланг с хаскилем тоже нельзя в хене запускать.Вообще-то известна эрланговая машина, запускаемая прямо под Xen.
О чём и говорю, и хаскилевая тоже есть, а то и не одна.
Вообще-то не только под Xen.
это ложь
Наставьте на путь истинный, чтоб сразу научиться на железе запускать, без всяких там vmlinuz
Че за глупость?
Любая абстракция, решающая комплекс специфических задач может называться "Операционной системой", то есть СИСТЕМОЙ осуществляющей решения определенных ОПЕРАЦИЙ
Интересная операционная система !
> Интересная операционная система !Ога, как рыбка прилипала. Устрашает всех целой акулой. Правда, для этого акула к которой можно прилепиться - должна все-таки быть. Иначе устрашение не срабатывает.
Ещё одна попытка реализовать идеально красивую абстракцию, угу. Ну никак люди не поймут, что не бывает "отсутствия различий в доступе к локальным и внешним ресурсам". Ну вот просто потому что отвалившийся локальный жесткий диск - это ЧП и не проблема ОС или прикладного софта. Отвалившийся смонтированный сетевой ресурс должен быть аккуратно обработан. О различиях в паттернах доступа и подобном я и не говорю. Тут регулярно хочется знать, на SSD или HDD данные лежат, а они - "отсутствие различий".Причём как полигон для исследования концепций, которые потом будут реализованы где-то в практически применимом виде подобные штуки хороши и нужны - или, как минимум, безвредны. Но надо понимать, что это именно полигон.
Вот подозреваю, что plan9 именно поэтому и не взлетела - практик интуитивно понимает, что слишком красивая архитектура - это всегда результат игнорирования реального мира, и использовать её - значит искать себе приключения.
Ну, блин, академики рафинированные же. Что ты как маленький. О том что кроме крЮтых 10Гбит линков у них в лабе бывает еще и сопливый GPRS, который, типа, тоже сеть - они подумают как-нибудь потом. Когда юзер будет по 20 минут ффтыкать на элементарные операции, которые на их гигабитах заканчивались за полсекунды.
> сопливый GPRSМежду нодами в кластере? Скорее 40Gbe и Infiniband.
> Между нодами в кластере? Скорее 40Gbe и Infiniband.Ну если дармое^W и грантопи^W, в общем, "очень полезным ребятам из bell labs" удалось вышибить денег из лох^W инвесторов на это - может быть. А так много ты кластеров видел под управлением этой требухи? Как впрочем и весь plan9. Вроде задумано крЮто, но как оказалось, реактивные двигатели - неважный движок для автомобиля. И стульчик с атомным двигателем - круто, но бывает только в "незнайке на Луне". А на улицу такие выпускать никто не собирается.
Э... я немного другое имел в виду. Академики рафинированные, которые сидят в своих лабах, обычно всё это понимают, занимаются исследованиями, пишут статьи и диссеры и редко кто из них настолько сходит с ума, чтобы исследовательские проекты в неизменном виде объявлять спасением для реального мира. А вот те, кто на них со стороны смотрит, иногда слишком перевозбуждаются. Вот я и напоминаю, что между красивым концептом и практически применимой системой - пропасть. Которая обычно заполняется уже существующими средствами и методами, и в результате вместо революций имеем эволюционное развитие существующих систем.Собственно, разница обычно очень заметна. Если какой-то лабораторный конструкт пытаются осторожно добавить к существующим готовым системам - как, допустим, в императивные языки добавляют как один из вариантов элементы функциональщины - то есть шанс. А если предлагают всё выкинуть и заменить на какое-то гениальное изобретение - значит, это либо академическое упражнение либо люди с головой не дружат.
К примеру, Sun много лет назад пыталась продвинуть NetPC или как там оно звалось - в виде сферического коня. В конце концов оно пришло - но в виде гибридных систем с самым разным уровнем "облачности", переплелось с локалом - и вот в таком виде жизнеспособно.
Да, если что - я сразу оговариваюсь, что вышесказанное не имеет отношения к лисп-машинам и прочей древности, когда мейнстрима, как такового, не было и вообще практического опыта в IT было наработано мало.
> "облачности", переплелось с локалом - и вот в таком виде жизнеспособно.Ну вот и получается что сказ про микроядра - закончился появлением гипервизоров, сказ про сетевую прозрачность - облаками и всякими сетевыми шарами. Но вот только все это как оказалось не имело ничего общего ни с plan9, ни с вот этим сферическим чудо-юдом в вакууме.
> и вообще практического опыта в IT было наработано мало.
Да я так смотрю, некоторые не против встать на старые грабли по второму разу :)
услышал звон да не знаешь где он
> Ещё одна попытка реализовать идеально красивую абстракцию, угу.Вы оцениваете применимо к персональному компьютеру.
> Ну никак люди не поймут, что не бывает "отсутствия различий в доступе к локальным и внешним ресурсам". Ну вот просто потому что отвалившийся локальный жесткий диск - это ЧП и не проблема ОС или прикладного софта. Отвалившийся смонтированный сетевой ресурс должен быть аккуратно обработан.
А может это и не правильно? Представьте, работаете вы, а система говорит - "Один из ваших локальных системных hdd больше не доступен, используются удаленные резервные копии. Пожалуйста, замените hdd для восстановления прежней скорости работы".
> О различиях в паттернах доступа и подобном я и не говорю. Тут регулярно хочется знать, на SSD или HDD данные лежат, а они - "отсутствие различий".
Я думаю не проблема, добавить атрибут показывающий текущее время отклика, пропускную способность и нагрузку.
> Вот подозреваю, что plan9 именно поэтому и не взлетела - практик интуитивно понимает, что слишком красивая архитектура - это всегда результат игнорирования реального мира, и использовать её - значит искать себе приключения.
Я тоже далеко не уверен - нужно ли мне что-то подобное. Но перспективы подобные ОС открывают интересные - появится возможность не только расшаривать часть данных (как мы это сейчас делаем через торренты), но и вычислительные ресурсы. Даже в локальном масштабе это выглядит интересно - можно запустить ресурсоемкую задачу на RBPi/телефоне/планшете, а тот задействует ближайшее доступные вычислительные мощности пк/сервера/ноутбука/игровой приставки. В глобально масштабе, появится возможность дома запускать задачи, сейчас доступные только суперкомпьютерам.
> А может это и не правильно? Представьте, работаете вы, а система говорит - "Один из ваших локальных системных hdd больше не доступен, используются удаленные резервные копии. Пожалуйста, замените hdd для восстановления прежней скорости работы".Скорее "ХЗ, что сломалось. ХЗ, что работает. Апсракция yopta."
> Я думаю не проблема, добавить атрибут показывающий текущее время отклика, пропускную способность и нагрузку.
Сначала добавим абстракцию, потом косвенные признаки для диференциации.
Убил бы, потому что уже имел опыт работы с таким API.
>> А может это и не правильно? Представьте, работаете вы, а система говорит - "Один из ваших локальных системных hdd больше не доступен, используются удаленные резервные копии. Пожалуйста, замените hdd для восстановления прежней скорости работы".
> Скорее "ХЗ, что сломалось. ХЗ, что работает. Апсракция yopta."Вы видите какие-то реальные проблемы с диагностикой при таком подходе?
>> Я думаю не проблема, добавить атрибут показывающий текущее время отклика, пропускную способность и нагрузку.
> Сначала добавим абстракцию, потом косвенные признаки для диференциации.
> Убил бы, потому что уже имел опыт работы с таким API.То есть вы за то, что бы для ssd/dvd/hdd/usb-flash/etc ввести отдельные open()/read()/write()/etc?
Насчёт правильно или нет - дискуссия долгая, я полагаю, что довольно бессмысленная идея - быть готовым к исчезновению чего угодно и для всего автоматом держать резервные копии. Банально неэффективно. Но, повторюсь, это отдельная тема.Вот если внятно разобраться с атрибутами, к примеру, построив иерархию хранилищ вроде той, что есть в STL у итераторов - было бы много пользы, даже без всех остальных идей.
А насчёт перспектив - я ж не против. Хотя то, что вы описали, с помощью акторов - в эрланге, Akka или ещё где - и сейчас делается довольно просто, и не распространено скорее из-за отсутствия спроса. При чём там это зрелая модель, показавшая свою практическую применимость. Но пусть эти перспективы отрабатываются в исследовательских проектах, а в реальное использование приходят как модули для уже существующих систем, без революций.
> Насчёт правильно или нет - дискуссия долгая, я полагаю, что довольно бессмысленная
> идея - быть готовым к исчезновению чего угодно и для всего
> автоматом держать резервные копии. Банально неэффективно. Но, повторюсь, это отдельная
> тема.Если ставить вопрос именно так - то да. В каждом конкретном случае нужно разбираться, какая надежность и время простоя приемлемы. Но имхо нужно стремится к повышению надежности - частично за счет дублирования (как данных так и железа).
По поводу ошибок hdd и сети - я часто работаю с ноутбука с сетевым диском, многие используют внешние usb диски. Софт в любом случае не должен полагаться на то, что диск будет доступен всегда.
Бездисковые машины появились еще в прошлом веке. При нынешних объемах памяти можно вообще всю ОС держать в памяти.
В перспективе локальные диски вообще могут стать просто кэшем и частью децентрализованных хранилищ (типа торрент).
> Вот если внятно разобраться с атрибутами, к примеру, построив иерархию хранилищ вроде
> той, что есть в STL у итераторов - было бы много
> пользы, даже без всех остальных идей.Всю иерархию не построишь - так как это потенциально весь интернет. ИМХО достаточно было бы добавить еще одну (или несколько) системных функций - в качестве параметра путь или имя файла, а на возврате время отклика/пропускная способность/etc.
> А насчёт перспектив - я ж не против. Хотя то, что вы
> описали, с помощью акторов - в эрланге, Akka или ещё где
> - и сейчас делается довольно просто, и не распространено скорее из-за
> отсутствия спроса. При чём там это зрелая модель, показавшая свою практическую
> применимость. Но пусть эти перспективы отрабатываются в исследовательских проектах, а
> в реальное использование приходят как модули для уже существующих систем, без
> революций.Спрос есть и не малый. До сих пор приходится ставить/запускать сервисы отдельно на каждой машине и для каждой задачи. В начале 2000-х интересовался параллельными вычислениями, про beowulf читал - но какие-то там сложности были и прозрачно задачу на другую машину перекинуть не получалось. Про эрланг не в курсе - нужно почитать. На данный момент нужно не только cpu расшаривать, но и gpu (opencl).
> В перспективе локальные диски вообще могут стать просто кэшем и частью децентрализованных хранилищ (типа торрент).
> Всю иерархию не построишь - так как это потенциально весь интернет. ИМХО достаточно было бы добавить еще одну (или несколько) системных функций - в качестве параметра путь или имя файла, а на возврате время отклика/пропускная способность/etc.man fscache ?
Про CPU и уж тем более GPU - это точно не к Erlang-у.
Вот сюда может быть интересным посмотреть https://wiki.haskell.org/GHC/CloudAndHPCHaskell
Эрланг замечательно умеет включать в себя написанное на сях и не только, и тяжелая обрабтка данных на нём так и делается - эрлангу оставляем взаимодействие по сети и управление процессами, саму работу делаем на чём удобно.
По мне - понимание софтом, можно или нет полагаться на наличие данного диска - лучшая политика, чем требовать гарантированную работу. Проще и дешевле.Насчёт иерархии - вы не поняли мены, видимо. В STL определено, какими свойствами обладает итератор - ну там, двунаправленный долджен с окнстантной сложностью отдавать предыдущий последующий элемент, random acces - кроме этого должен с константной сложнотсью отдавать проивольный элемент, и т.д. Так же для контейнеров определена сложность, котороая есть у методов. Вот в каком-то смысле похожую систему хотелось бы видеть для хранилищ. Ну там, "можно полагаться на наличие или нелья", скорость, задержка, равномерность скорости - что-то подобное. По идее - один IOCTL дополнительный, плюс чётко прописанные критерии, как именно вычисляются эти параметры.
Насчёт эрланга - инстансы приложения вам придётся запустить всё равно на каждой машине, конечно ну а дальше раскидывать нагрузку он хорошо умеет. Но синтаксис нечеловеческий. Akka - аналогичный функционал в виде JVM-библиотеки.
> - "Один из ваших локальных системных hdd больше не доступен, используются
> удаленные резервные копии. Пожалуйста, замените hdd для восстановления прежней скорости
> работы".ЧСХ, кому все это было реально надо (гугли там всякие) - давно забабахали сетевые распределенные отказоустойчивые ФС, где даже выгорание целого сервака синим пламенем ничего не решает. Собрано все это на ширпотребе типа линуха, который поддерживает кучу железя и нормально работает. С кастомным слоем распределенной ФС поверх. В таком виде оно даже имеет какой-то смысл. А на рафинированные академпoдeлия все клали. Потому что сферическая фигня в вакууме, не от мира сего.
А по GPRS в любом случае будет не работа а брань на истошные тормоза везде и всюду.
Вот и получается что большим инсталляциям проще использовать ширпотреб с небольшим слоем кастома. А хомячкам и вовсе проще при вылете харда перекачать фотки с инстаграмма, ну или с резервной копии, если она была. А половина хомяков вообще все льют в инстаграмм и их это не парит. В смысле, париться они начинают только если стограмм их аккаунт заблочил.
Ну а академики в этих схемах лишние элементы, не от мира сего.
> Я думаю не проблема, добавить атрибут показывающий текущее время отклика, пропускную
> способность и нагрузку.Я думаю что все это сферические концепции в вакууме. Открытие жыпега с котятами не за полсекунды а за 10 минут - юзер и без всяких атрибутов заметит. И если юзеря это устраивало - он давно закачал своих котят в-сто-грамм. Там их еще и другие хомяки посмотреть могут. Крупные корпорахи - собрали себе окружения из относительно ширпотребных вещей. Доработав то что не хватало "in situ". А все эти инициативы - сферическая хрень в вакууме.
А лично я предпочитаю достаточно явное и жесткое различие между локальными ресурсами и сетевыми. Потому что например у какого-нибудь ноута понятие сети и ее надежность - очень варьируются. Вот тут это 100М эзернет. А вон там - жпрс дохлый, на грани приема. А вот завинченный внутрях SATA винч - это таки быстрое и достаточно надежное хранилище. В отличие от GPRS оно не ловит 10 таймаутов линка в час. И перепутать состояние дел бы, скажем так, чревато досадными факапами. Ну то-есть если я уверен что мне надо файл на пару гигз - лучше его явно перетащить на локальный носитель, чем потом обнаружить что всего месяц ожидания - и я таки получу те же данные по GPRS, "зато совершенно прозрачно".
> перспективы подобные ОС открывают интересные -
Так plan9 с этими перспективами уже сто лет как есть. А на практике оказалось что стульчики с атомными двигателями - бывают только в книжках. А на практике - такие конструкции создают больше проблем чем решают и потому распостранения не получили.
> часть данных (как мы это сейчас делаем через торренты), но и
> вычислительные ресурсы.Реально как видим все пришло к совсем иным форматам. Кто явно хотел шарить ресурсы - используют виртуалки или всякие ремотные десктопы и прочие терминал серверы. Кто-то выгрузил тяжелые задачи на сервера и облака. Ну и так далее. Более костыльно? Может быть. Но реально plan9 с его бзиками по прозрачным сетям - есть дофига времени. И никому что-то особо не сдался. А это некое доразвитие тех же идей. Оно концептуально и симпатично. И ... оторвано от реального мира. По поводу чего будет развлечением высоколобых академиков. А на практике ниши займут всякие другие решения. Менее сферически-вакуумные и более практичные.
> запустить ресурсоемкую задачу на RBPi/телефоне/планшете, а тот задействует ближайшее
> доступные вычислительные мощности пк/сервера/ноутбука/игровой приставки.Только на практике "ресурсоемких программ" писаных на Lua - ноль целых, хрен десятых, а половина озвученных железок типа приставок - еще и огрожены куда подальше от пользователя. И там надо сделать минет вендору SDK и заплатить ему сотни нефти^W денег за право пользования и прочие ключи для подписей, для начала.
> масштабе, появится возможность дома запускать задачи, сейчас доступные только суперкомпьютерам.
Там где это было реально нужно - все это сделали без супер-осей. Понимаешь, большинство пользователей не гоняет моделирование ядерных взрывов в реальном времени. А если это обсчет 3D сцен, там сеть не пойдет: оно с PCI-E и локальную память то упирается по скоростям только в путь, а уж сеть там и вовсе таким задачам не товарищ с латенси, бандвизом и оверхедом на парсинг. А какой-нибудь bitcoin давно втыкает на специализированной задаче "брутфорс sha-256" вообще любому суперкомпьютеру. И без всяких мегаконцептуальных осей.
>> - "Один из ваших локальных системных hdd больше не доступен, используются
>> удаленные резервные копии. Пожалуйста, замените hdd для восстановления прежней скорости
>> работы".
> ЧСХ, кому все это было реально надо (гугли там всякие) - давно
> забабахали сетевые распределенные отказоустойчивые ФС, где даже выгорание целого сервака
> синим пламенем ничего не решает.Речь не о том как это реализовать, а о том, что загнувшийся винт == загнувшаяся система явно не предел мечтаний.
> А по GPRS в любом случае будет не работа а брань на
> истошные тормоза везде и всюду.Конкретная реализация может быть разной - от raid до выделенного сервера.
> А хомячкам и вовсе проще при вылете харда перекачать фотки
> с инстаграмма, ну или с резервной копии, если она была. А
> половина хомяков вообще все льют в инстаграмм и их это не
> парит. В смысле, париться они начинают только если стограмм их аккаунт
> заблочил.Даже "хомячков" не очень радует неработоспособный компьютер.
>> Я думаю не проблема, добавить атрибут показывающий текущее время отклика, пропускную
>> способность и нагрузку.
> Я думаю что все это сферические концепции в вакууме. Открытие жыпега с
> котятами не за полсекунды а за 10 минут - юзер и
> без всяких атрибутов заметит. И если юзеря это устраивало - он
> давно закачал своих котят в-сто-грамм. Там их еще и другие хомяки
> посмотреть могут. Крупные корпорахи - собрали себе окружения из относительно ширпотребных
> вещей. Доработав то что не хватало "in situ". А все эти
> инициативы - сферическая хрень в вакууме.На данный момент - да, так как "умные" устройства слабо интегрированы между собой. В перспективе подобные атрибуты понадобятся, дабы устройства сами между собой могли объясниться какими ресурсами они располагают и какие им нужны.
> А лично я предпочитаю достаточно явное и жесткое различие между локальными ресурсами
> и сетевыми. Потому что например у какого-нибудь ноута понятие сети и
> ее надежность - очень варьируются. Вот тут это 100М эзернет. А
> вон там - жпрс дохлый, на грани приема. А вот завинченный
> внутрях SATA винч - это таки быстрое и достаточно надежное хранилище.
> В отличие от GPRS оно не ловит 10 таймаутов линка в
> час. И перепутать состояние дел бы, скажем так, чревато досадными факапами.Речь в первую очередь о том, что софт должен нормально работать не только с sata hdd, но и с удаленным диском покинутым через gprs.
> Ну то-есть если я уверен что мне надо файл на пару
> гигз - лучше его явно перетащить на локальный носитель, чем потом
> обнаружить что всего месяц ожидания - и я таки получу те
> же данные по GPRS, "зато совершенно прозрачно".Думаю ты сразу поймешь что надо что-то делать, когда увидишь расчетное время операции ;) Если добавить атрибуты - то можно будет увидеть расчетное время до начала операции.
Никто ведь не заставляет использовать уделенные ресурсы (разве что гугл/эппл/etc :), сетевая прозрачность позволяет это делать проще, без внедрения кучи протоколов в каждую софтину.> А если это обсчет 3D сцен, там сеть не пойдет:
> оно с PCI-E и локальную память то упирается по скоростям только
> в путьman renderfarm
Но это костыль. Нужна возможность прозрачной миграции процесса на доступное в сети железо. Передаться должен сам процесс и входные данные, по завершении процесса выходные данные передаются обратно. Насколько я понимаю, примерно так работают суперкомпьютеры.
> загнувшийся винт == загнувшаяся система явно не предел мечтаний.Поэтому давно придумали RAID, например. В общем академики сделали как всегда очень концептуально и ... оторванно от реалий.
Потому что у SATA линка к "запасному" винчу бандвиз и латенси - предсказуемые. А сеть - понятие очень растяжимое. И сказ про прозрачность - это круто в лаборатории в быстрыми и стабильными линками, сравнимыми с sata интерфейсом по параметрам. Но когда это случится у юзера в чистом поле с его сельским GPRS ... ну обычно программа работающая с диском при чтении 100Мб даже прогресс не рисует: ожидается что это завершится ну самый край за пяток секунд. А если там вместо диска окажется GPRS - юзерь взвоет. Сеть - потенциально ненадежная, зачастую не очень быстрая и не очень подконтрольная среда, где всегда есть множество факторов, отсутствующих в локальном диске с SATA проводом в контроллер на мамке. И ставить их в один ряд - как бы круто и концептуально. Но - чревато уймой дурных проблем из-за сферичности концепций и того что в результате в одну телегу пытаются впрячь лань и ломовую лошадь.
> Конкретная реализация может быть разной - от raid до выделенного сервера.
Ну вот кому это было надо - давно сделали себе RAID-ы и прочие распределенные файлухи. Менее расово верно, менее концептуально. Но работает, не требует "до основанья, а затем" и лучше приспособлено к фактически имеющимся реалиям чем сферические концепты в вакууме.
> Даже "хомячков" не очень радует неработоспособный компьютер.
А если хомячку придется качать 100Мб данных по GPRS - хомячкок вообще гвоздь в экран заколотит, глядя на зависшее все и вся (рисовать прогресс ради чтения 100Мб с локального диска всем очень лень).
> собой. В перспективе подобные атрибуты понадобятся, дабы устройства сами между собой
> могли объясниться какими ресурсами они располагают и какие им нужны.Теоретически все как бы правильно. Практически - там где все это было реально надо, появились виртуалки всякие. Кластеры. Распределенные вычисления. И прочая. А чрезмерная прозрачность этого процесса приведет лишь к тому что в результате у хомяков весь дом начнет усиленно майнить биткоины. На пользу какого-то шустрого веника. Потому что хомяк на плохо контролируемом телефоне принес "вражеский процесс-странник". Тот оценил - ресурсов завались. И вот все телевизоры, микроволновки, тостеры и холодильники, сервер управления и что там еще - дружно впахивают. Все тормозит, счет за электричество выросший в три раза - вызывает а...й. Фантастика? Вовсе нет. Посмтрите на современные ботнеты и на то как хомяки мыкаются например ну хоть со списком услуг наподключенных oпcocoм...
> Речь в первую очередь о том, что софт должен нормально работать не
> только с sata hdd, но и с удаленным диском покинутым через gprs.Никто никому ничего не должен. Если юзер запустил игрушку а она 2 гига ресурсов в RAM грузила, на GPRS это просто априори тухлое начинание. Ну право - нафига вам запустившаяся через месяц игрушка? Вы такой терпеливый? И старт CAD-пакета два дня - меня тоже не устроит. Это просто заведомо тухлые начинания и я предпочту чтобы это сразу обломалось. Вместо неопределенного ожидания величиной в месяц, при том что вроде "почти работает" и "вот-вот загрузится".
> Думаю ты сразу поймешь что надо что-то делать, когда увидишь расчетное время операции ;)
Для чтения 100М с винча никто обычно вообще прогрессбар не делает. Поэтому есть шансы понять тухлость этой операции несколько опосля. Кроме того, при полной сетевой прозрачности - поимение такой инфраструктуры будет быстрым и масштабным. А вот вытряхнуть потом из распределенной сетевой структуры вредиетеля... никогда не видели как админы в большой виндовой сети не могут выбить msblast даже с адскими усилиями? Пока они окучивают те или иные машины, оно при достаточном размере сети успевает найти новых жертв. В результате нечто (порой реально бестелесное) летает по сети и это крайне проблематично вывести совсем. Наевшись этих благ цивилизации, большинство ISP просто накрыли все порты виндовых шар медным тазом, т.к. иначе самоходное ПО начинает ощущать себя слишком уж вольготно, раскидывая себя на туеву хучу компьютеров.
> Если добавить атрибуты - то можно будет увидеть расчетное
> время до начала операции.Осталось всего ничего - убедить програмеров кодить показ всей этой муиты. Много возни при малоочевидном выигрыше.
> Никто ведь не заставляет использовать уделенные ресурсы (разве что гугл/эппл/etc :),
Ну вот по совокупности я предпочитаю четкое разделение на локальные операции и сетевые. С совершенно разными ожиданиями по скоростям и латенси для одних и для других.
И когда cp исошки на гиг не показывает прогресс - да и болт с ним. А когда его не показывает качалка - это уже "ай-яй-яй, плохая качалка".
> сетевая прозрачность позволяет это делать проще, без внедрения кучи протоколов
> в каждую софтину.Де факто я хочу некий fine graned контроль кому вообще в сеть можно и что именно он там будет делать. Летающие по всей инфраструктуре самоходные боевые малварины которые хрен выведешь - лично мне все-таки ни к чему. А то что потенциал для этого имеется - показали еше виндовые шары и прочие msblast. Получить этой граблиной с ТАКОГО размаха мне как-то не очень охота.
> man renderfarm
Я про реалтаймный рендеринг говорил - когда юзеря волнует FPS, т.к. при его нехватке сцена становится дерганой, и вообше - иллюзия плавной картинки - рассыпается.
> Но это костыль. Нужна возможность прозрачной миграции процесса на доступное в сети железо.
Не уверен что мне надо именно это. Вот возможность fine graned выделить ресурсов задаче, например "рендеринг вон того кульного мувика" - может быть. Но я пожалуй предпочту чтобы это было таки отдельной программой-клиентом, который я явно раскидаю на системы где использование ресурсов допустимо.
> Передаться должен сам процесс и входные данные, по завершении процесса
> выходные данные передаются обратно. Насколько я понимаю, примерно так
> работают суперкомпьютеры.Единственная проблема: у хомяков после этого начнется форменный трындец, когда вся хата начнет дружно майнить коины на каждом утюге и микроволновке, потому что хозяин хаты необдуманно поставил программу на смартфон. А программа без особого спроса раскидала себя по всей хате, да еще к соседу пролезла и там еще ресурсов юзанула. Ну в общем видал я как это работает, на примере msblast и виндовых шар. Второй раз на одни грабли мне не хочется. Если в лабах академики еще с этим могут совладать, то in field это будет источник кучи проблем.
>[оверквотинг удален]
> - это ЧП и не проблема ОС или прикладного софта. Отвалившийся
> смонтированный сетевой ресурс должен быть аккуратно обработан. О различиях в паттернах
> доступа и подобном я и не говорю. Тут регулярно хочется знать,
> на SSD или HDD данные лежат, а они - "отсутствие различий".
> Причём как полигон для исследования концепций, которые потом будут реализованы где-то в
> практически применимом виде подобные штуки хороши и нужны - или, как
> минимум, безвредны. Но надо понимать, что это именно полигон.
> Вот подозреваю, что plan9 именно поэтому и не взлетела - практик интуитивно
> понимает, что слишком красивая архитектура - это всегда результат игнорирования реального
> мира, и использовать её - значит искать себе приключения.Вы не врубились в ключевое слово - облако. В облаке - я не знаю и не хочу знать о различиях, у меня лишь ресурсы, которые виртуализированы. Она выглядит многообещающе. Особенно учитывая скорость LuaJit (а она поразительна).
Во-первых, там облака указаны только как один из вариантов применения. В-вторых - я не спец в облаках и привожу пример из той области, в которой разбираюсь.Я в принципе считаю, что подход "Представим всё как X" не работает. Работает "представим вся как X1, X2, X3... зная, что количество этих разновидностей будет увеличиваться, а после того, как их станет слишком много - мы выкинем эту абстракцию и подберём что-то более подходящее к нашим условиям".
Кроме того - если нечто претендует на применимость везде - это заведомый мусор. Один из важных признаков прилично спроектированной системы - понимание разработчиком, где эта система работать перестаёт.
> Я в принципе считаю, что подход "Представим всё как X" не работает. Работает "представим вся как X1, X2, X3... зная, что количество этих разновидностей будет увеличиваться, а после того, как их станет слишком много - мы выкинем эту абстракцию и подберём что-то более подходящее к нашим условиям".Расскажите мне в чем различие локального HDD примонтированого по пути XXX,
iSCSI по пути YYYY, и какой нить сетевой FS - по пути ZZZZ.кроме тривиального что iSCSI, и сетевая FS тупо быстрее и работают на скоростях близких к скорости RAM (10-60 Gbyte/s) ? Кстати покажите мне такой локальный дисковый сервис - который сможет обеспечить такие скорости?
Первое. Ещё раз я не сторонник утверждений на все случаи жизни. Вполне вероятно, что может быть система, где сетевое хранилище будет по всем параметрам эквивалентно локалу. Но фишка в том, что может и не быть.Второе. Если у вас есть что-то заведомо быстрее, чем локальный диск - приложению, в идеале, об этом надо бы знать.
Третье. Скорость - не всё. например, к сетевой ФС возможен конкурентный доступ невесть чего, и в результате скорость может непредсказуемо деградировать в произвольный момент - уж оверселлинг все видели. Локальный же диск как был, так и есть. То же самое касается доступного дискового пространства.
Четвёртое. Ещё раз - не всё сводится к облакам. Из новости: "Система предназначена как для решения традиционных задач распределённых вычислений и симуляции, так и для применения в облачных системах и сетевых системах управления и контроля".
Пятое - как ни крути, между машиной и удалённым сетевым хранилищем больше узлов, которые могут сфейлить. Разумеется, это решается резервированеим и прочим, но закончится это всё ещё одной идеальной системой в вакууме - только теперь это будет СХД, на которую потрачено в десять раз больше, чем можно было бы.
Шестое. Особенности легко проигнорировать, навернув сверху обобщённый протокол. А вот обратное сделать несколько затруднительно.
Седьмое. Диски были одним примером, вы к ним как-то тщательно привязались. Наверняка есть масса ситуаций, где подход "а мы всё сделаем коллбеками на Lua" даст сбой.
Достаточно?
> Первое. Ещё раз я не сторонник утверждений на все случаи жизни. Вполне вероятно, что может быть система, где сетевое хранилище будет по всем параметрам эквивалентно локалу. Но фишка в том, что может и не быть.
> Второе. Если у вас есть что-то заведомо быстрее, чем локальный диск - приложению, в идеале, об этом надо бы знать.У приложения будет особенный read(2) ? или специальный write()?
> Третье. Скорость - не всё. например, к сетевой ФС возможен конкурентный доступ невесть чего, и в результате скорость может непредсказуемо деградировать в произвольный момент - уж оверселлинг все видели. Локальный же диск как был, так и есть. То же самое касается доступного дискового пространства.
Мисье - вы точно имеете только 1 работающую программе на хвосте? Вы точно уверены что за локальный диск не может быть конкуренции? давайте я вам покажу забавный момент.
есть директория - пока она читается - удалить вы ничего не сможете.
пока происходит поиск файла - вы не можете ее модифицировать.
Вот блин такие засады в linux VFS.> Четвёртое. Ещё раз - не всё сводится к облакам. Из новости: "Система предназначена как для решения традиционных задач распределённых вычислений и симуляции, так и для применения в облачных системах и сетевых системах управления и контроля".
Кончай курить. Где я говорил о облаках? Не надо приписывать мне слова которые я не говорил.
> Пятое - как ни крути, между машиной и удалённым сетевым хранилищем больше узлов, которые могут сфейлить. Разумеется, это решается резервированеим и прочим, но закончится это всё ещё одной идеальной системой в вакууме - только теперь это будет СХД, на которую потрачено в десять раз больше, чем можно было бы.
Сдай своего драг-диллера. Хочу такую же траву. Сразу видно человека который Big Data видел только на рисунках.
> Достаточно?
Да достаточно. что бы увидеть вашу глупость мисье.
Я задал один простой вопрос - ответа на него не увидел, зато приписаны мне куча левых слов и тп.
Учись отвечать на поставленный вопрос.
>У приложения будет особенный read(2) ? или специальный write()?В идеале - должен бфть API, дающий список устройств с их свойствами. А дальше - приложение может выбрать, куда писать - самым обычным write().
> Мисье - вы точно имеете только 1 работающую программе на хвосте? Вы точно уверены что за > локальный диск не может быть конкуренции? давайте я вам покажу забавный момент.
> есть директория - пока она читается - удалить вы ничего не сможете.
> пока происходит поиск файла - вы не можете ее модифицировать.
> Вот блин такие засады в linux VFS.Я точно имею на серверах одну нагруженную программу на инстанс. Так проще и дешевле. И все, кого я знаю, делают именно так за исключением ситуаций, когда нагрузка совсем мала.
Что касается возни с метаданными - кэш ОС в помощь.> Кончай курить. Где я говорил о облаках? Не надо приписывать мне слова которые я не говорил.
А, да, перепутал авторов маленько. Неважно. Если не в облаках - тем более. Вне облаков систем, имеющих действительно надёжную и не перегруженную СХД - раз-два и обчёлся. Потому что невыгодно.
>Сдай своего драг-диллера. Хочу такую же траву. Сразу видно человека который Big Data видел только на рисунках.
Отлично. Так и пиши - "меня не интересуют никакие области кроме Big Data". И не забыдь добавить, что имели в виду Big Data, где денег не жалеют - потому что то, с чем я имел дело (а я пару раз таки имел) хранило-то много и довольно шустро, но, закономерно, периодически затыкалось разными способами - от странностей NFS до затыков с сетью. Что логично, ставится то, чего хватает для бизнеса, а не то, что хотелось бы в идеале. Этой штуки хватало - с некоторыми костылями,но без больших вложений в апгрейд.
>Я задал один простой вопрос - ответа на него не увидел, зато приписаны мне куча левых слов и тп.
>Учись отвечать на поставленный вопрос.Ок, отвечаю ещё раз, специально для тупого анонима, решившего, что имеет значени только случай с крутыми СХД на толстых линках..
Локальный диск предоставляет некоторые гарантии - минимальная скорость, гарантированное присутствие. ну, то есть может быть и не так, но это маргинальные случаи, вроде неисправной машины. Сеть в общем случае этих гарантий не даёт. Может быть выделенный 10Gb линк, а может быть 100Mbitб шаренный еще с десятком машин в стойке. А может быть Wi-Fi до домашнего медиасервера. И это, блин, РАЗНЫЕ случаи. А то, что где-то и когда-то характеристики могут совпасть или у сетевого хранлилища они будут лучше, чем у локального - ну да, бывает. Только закладываться на это нельзя.
> Локальный диск предоставляет некоторые гарантии - минимальная скорость, гарантированное
> присутствие. ну, то есть может быть и не так, но это
> маргинальные случаи, вроде неисправной машины.Ничего он не может гарантировать и рассчитывать на это нельзя. По сей день система встает колом, если винт заснул и нужно ждать пока он раскрутится. Мы не можем гарантировать скорость - работающие на фоне приложение может съесть весь io (тот же торрент, особенно во время хеширования). А может кто-то другой по сетке работает с этим же винтом. По возможности все файловые (и естественно сетевые) операции должны быть асинхронными (особенно при больших объемах) - приложение не должно безответно висеть, если io по какой-то причине замер или очень медленный.
ps. напомню что локальный диск ограничен SAS bus, который выше 6Gbit/s прыгать не научился, а нормальные сетевые стораджи они упираются в IB EDR (300 Gbit/s, продаются с начала этого года), или Intel TruePath (с прошлого года, похожие скорости).
Что-то во всем предыдущем обсуждении никто особо не упирал на то что "локальный=быстро, сетевой=медленно и в этом всё дело", а вы чё-то всё свели к скорости и доказываете (зачем-то?) что "сетевое бывает существенно быстрее". Ну бывает и что? Далеко не только из-за отличий в скоростях (в любую сторону) с сетевым и локальным работают по-разному.
Да человек тут вообще упустил, что диски - это всего лишь пример, и не более, и зачем-то упёрся в один конкретный случай облака с крутыми СХД и 10GB сетью. Основная идея - не о дисках вообще, а что подход "единственно верного решения" не работает на практике.
> Да человек тут вообще упустил, что диски - это всего лишь пример,
> и не более, и зачем-то упёрся в один конкретный случай облака
> с крутыми СХД и 10GB сетью. Основная идея - не о
> дисках вообще, а что подход "единственно верного решения" не работает на
> практике.СХД - применяются не только в облаках, и не только в хостинга. Неожиданно так.
А для остальных - еще раз - в чем отличие для приложения - которое хочет
1) открыть,
2) прочитать, записатьв некий файл в этих трех случаях. Знание где именно файл расположен - очень и очень редко когда надо.
Не смотря на утверждения местных "аналитиков".
Логика админчега.
> Ещё одна попытка реализовать идеально красивую абстракцию, угу. Ну никак люди не поймут, что не бывает "отсутствия различий в доступе к локальным и внешним ресурсам".Почему?
SSI кластер (каждый процесс видит все процессорные ядра в сети и всю оперативку) узлы кластера динамически входят и выходят с него. Жаль в разжирелых последних ядрах Линукса SSI кластер уже не реализовать. Вот по этому и появляются подобные проекты DragonFlyBSD была первой ласточкой!
> Ну вот просто потому что отвалившийся локальный жесткий диск - это ЧП и не проблема ОС или прикладного софта.
HA кластер, где по верху DRBD лежит кластерная фс. Да при сбое диска/узла в систему мониторинга отправляется сообщение о аварии. Но все проги использующие кластерную ФС будут продолжать работать не заметив потерь.
Типа как у зергов колективный разум ?
вы мало общались с зергами, у них нет коллективного разума там жесткая иерархия всем правит королева.
коллега аноним перепутал боргов с зергами :)
А как билл будет впаривать ее всем если она одна на всех
Дурдом, люди никогда не решавшие подобные задачи оставляют комментарии типа "не нужно". Админы локалхоста и вебни вопят "ос паразит, да что она может без X, да как они посмели назвать это ОС" и "посмотрим как будет работать на gprs!"Займитесь лучше дипломом, или уроками на понедельник ))
отличная идея, снять разграничения между "локально" и "удаленно". только для этого надо с самого основания закладывать верные принципы построения программ.проблемы же обычно вылезают там, где плохо спланировали алгоритмы. например, в линуксе, когда носитель (DVD-Rom, HDD, microSD...) вдруг перестаёт отвечать, происходят очень неприятные вещи. подозреваю, что это из-за того, что программисты где-то не предусмотрели как стоит такую вероятность. поэтому, естественно, что и пропадение сети заставляет систему вставать колом из-за примонтированного NBD. проблемы не в плохих технологиях "всё есть доступный файл", а в качестве реализации, в самой тщательности проработки.
Это не проблема тщательности разработки, а проблема инфраструктуры. Если у тебя ресурс может механически, электрически отвалится, то на достаточно больших масштабах он обязательно отвалится. И тогда будут проблемы.Например в мире баз данных есть такое понятие как распределенная транзакция. Т.е. операция, которая должна быть проведена согласована на двух и более базах данных. Как ты не модифицирую и ускоряй алгоритм, ты рано или поздно станешь перед необходимостью подтвердить (закоммитить) транзакцию на всех узлах. И рано или поздно ты окажешься в ситуации, что один узел закоммитил, а второй упал, стал недоступен. Вот как это разрулить? Откат в обоих точках и исключение в юзерспейс? А если он через миллисекунду вдруг станет доступен? Жалко терять работу. Нужен таймаут. А какой? 30 ms или 30 min? Да и как, блин откат делать? Я же уже закоммитил на одной ноде и этими данными, возможно, кто-то воспользовался? Система "псевдокоммитов"? Короче даже на таком примере видно, что вопросов больше чем ответов. Чаще дешевле полагаться на инфраструктуру, что программисты и делают, предполагая каждый сбой фаталом и страшным факапом.
Проблема в том, что если везде рассматривать недоступность файла как восстановимый сбой - получится монстр. А линукс - штука практичная - плевать на идеи, главное эффективная работа.
Драйвера на сколько железяк есть?
Оно работает с аппаратными акселерациями?
Задумка интересная. P9 и Inferno волнуют меня уже не первый год. Сможет ли Lua заменить Limbo/Oberon?