Анонсирован (http://ninetimes.cat-v.org/news/2011/06/17/0-9front/) проект 9front (https://code.google.com/p/plan9front/), созданный группой энтузиастов из сообщества NineTimes (http://ninetimes.cat-v.org/about) с целью продолжения развития операционной системы Plan 9 (http://plan9.bell-labs.com/plan9/), независимо от Bell Labs. Как и код (http://plan9.bell-labs.com/sources/extra/plan9.tar.bz2) Plan 9, исходные тексты нового проекта распространяются под одобренной OSI открытой лицензией Lucent Public License (http://www.opensource.org/licenses/lucent1.02.php), основанной на IBM Public License, но отличающейся отсутствием требования публикации исходных текстов для производных работ.Основная идея (http://plan9.bell-labs.com/plan9/about.html) Plan 9 связана со стиранием различий между локальными и удаленными ресурсами, система представляет собой распределенную среду, базирующуюся на трех базовых принципах: все ресурсы можно рассматривать как иерархический набор файлов; нет различия ...
URL: http://ninetimes.cat-v.org/news/2011/06/17/0-9front/
Новость: http://www.opennet.dev/opennews/art.shtml?num=31210
Вот меня всегда удивляли попытки сделать так, что "нет различия в доступе к локальным и внешним ресурсам". Неужели не очевидно, что с ними должны применяться принципиально разные техники работы? Разница объёмов даных, которые есть смысл таскать, разная латентность (и как следствие - разная алгоритмика), разная вероятность возникновения ошибки, разная гранулярность и т.д. - ну какой смысл это перемешивать?
Файлы обрабатываются на удаленной машине, пользователю необходимо передать лишь его представление.
Не так все однозначно, имхо. Нельзя сказать, что локальным ресурсам всегда присущи большие объемы, высокая скорость и прочее, а удаленным наоборот. Так зачем их разделять. К тому же, некоторые нюансы можно учесть в реализации конкретного файлового сервера, а интерфейс оставить стандартным.
> Не так все однозначно, имхо. Нельзя сказать, что локальным ресурсам всегда присущи
> большие объемы, высокая скорость и прочее, а удаленным наоборот. Так зачем
> их разделять. К тому же, некоторые нюансы можно учесть в реализации
> конкретного файлового сервера, а интерфейс оставить стандартным.Придется добавлять к интерфейсу работы с файлами обработку, например, ошибок разрешения dns. Вам это надо?
При доступе к локальным ресурсам это не потребуется, а для удаленных придется реализовывать в любом случае, разве не так?
Учимся читать оригинальную статью до написания комментариев:
>>Основная идея Plan 9 связана со стиранием различий между локальными и удаленными ресурсами
>>все ресурсы можно рассматривать как иерархический набор файлов
И? Вас, как разработчика конкретного приложения, кто-то покарает если вы не обеспечите реализации всех идей заложенных в Plan 9?
Такое же возражение можно было бы выдвинуть против любого обобщенного интерфейса.Хотите, чтобы локальная камера была представлена файлом? Придется добавлять к интерфейсу работы с файлом обработку ситуации обрыва кабеля УПШ.
С другой стороны, сегодняшняя ситуация, когда для операций с близкой семантикой (скопировать файл локально, залить файл на сервер FTP, слить ресурс WWW в локальный файл) приходится применять существеннно разный синтаксис и лексику (cp, (s)ftp, wget на уровне интерфейса оператора, про уровень программиста вообще промолчим), просто скандальна. В XXI в это анахронизм айбиэмовско-майкрософтовского толка.
Отсутствие достаточно обобщенных интерфейсов на уровне ОС при наличии в них потребности заставляет прикладных программистов колхозить собственные "решения", и мы имеем тот зоопарк, который имеем.
Бла бла бла.
Откройте сорцы gnutools например cp. 85% кода обработка ошибок. Если файлы начнут выкидывать исключения ERR_DNS_RESOLV то этот процент повысится до 99%, так как сетевых ошибок много. И, что самое плохое упадет быстродействие. Java это прекрасно показала.
Намек: ошибки тоже могут обрабатываться обобщенно.
Чушь, глянь на сорцы cat (http://plan9.bell-labs.com/sources/plan9/sys/src/cmd/cat.c). Где там обработка ошибок вообще? В том и была задумка, чтобы избавить разработчиков от написания кучи стандартного кода.
Где там обработка сетевых ошибок вообще?
fixed.
> Где там обработка сетевых ошибок вообще?
> fixed.там базовый компилятор НЕ gcc...
он не допускает ошибок... :D
Да пофиг, речь о том, что в Plan 9 из ошибок остались только файловые.
Сколько ни тверди "нет различий между локальными и нелокальными данными", различия не исчезнут. Например, можно быть достаточно уверенным, что на локальном диске файл не изменится без ведома операционной системы, а можно ли быть уверенным в этом работая с файлом на ftp? Нет, тысячу раз нет. Файл может измениться даже во время скачивания!В таком случае возникает закономерный вопрос - эта красивая идиома о неразличении в реальной жизни даёт хоть какое-то преимущество в чём-то перед обычными методами работы, или это сродни попытке наполнить эфиром вакуум?
странно - когда один процесс читает, второй процесс пишет в файл - то файл может измениться и даже локально во время чтения.
Так в чем различие с FTP ?
А если этого локально диска нет вообще? Если вообще нет никаких локальных ресурсов в привычном вам понимании?
Интерфейс должен сказать "ошибка NNN" или бросить исключение. Если есть средство в системе, которое может разрешить эту стандартную ошибку, то оно его должно разрешать стандартным способом. И системе должно быть все равно какой интерфейс, какой программы дает ошибку NNN. Также как пользователю все равно почему файл не прочитался/записался, а программа должна обрабатывать ситуацию любой ошибки чтения/записи.
>> Не так все однозначно, имхо. Нельзя сказать, что локальным ресурсам всегда присущи
>> большие объемы, высокая скорость и прочее, а удаленным наоборот. Так зачем
>> их разделять. К тому же, некоторые нюансы можно учесть в реализации
>> конкретного файлового сервера, а интерфейс оставить стандартным.
> Придется добавлять к интерфейсу работы с файлами обработку, например, ошибок разрешения
> dns. Вам это надо?Ошибки разрешения DNS появляются на этапе запуска файлового сервера, а не при доступе к файлу.
> Неужели не очевидно, что с ними должны применяться принципиально разные техники работы?Нет, не очевидно.
Вот меня всегда удивляли попытки сделать компьютеры с заменяемой программой. Неужели не очевидно, что для каждой задачи должна быть своя железка.
Согласен, хотя буду менее категоричен.
Пусть существует такая фича на высоком уровне, но когда я захочу делать сетевой шутер или другие системы где отклик должен быть максимальным, мало вероятно, что реализованный где-то в недрах системы код будет отвечать требованиям. Но если речь идёт о разработке распределённой вычислительной системы, то пожалуй не так важно иметь низкоуровневый доступ к сети.
С Plan9 и 9front не знаком, но читал по Inferno. Как я понимаю подход там такой же и такая же есть замута с удалённым доступом. Звучит интересно. Низкоуровневый доступ к сети никуда не делся, но при этом ты бесплатно получаешь возможность работать с удалённым железом в точности как с локальным (в том числе использовать выход в сеть через удалённую Inferno используя её низкоуровневый интерфейс).
Пока что я не видел ни одной удачной реализации прозрачного сетевого доступа даже на уровне приложений, хотя там частные решения, а не общие. Вудь то VFS в Gnome/KDE или открытие файла по URL в PHP. По-моему, прозрачный сетевой доступ - это одна из тех leaking abstractions, которых надо избегать как чумы. В вебе, кстати, это уже поняли и ушли от RPC-вызовов к очередям сообщений и REST.
С прозрачной сетью есть, кстати, масса более тонких проблем - к примеру, такие данные надо обрабатывать как недоверенные, так как никто не гарантирует, что машина, к которой ты обращаешься, находится под твоим контролем и надлежащим образом защищена - и, соответственно, может отдавать что угодно. Это не говоря о Man in the Middle и т.п. Мало того - никто не гарантирует, что с другой стороны совместимый протокол, а не гривая реализация или просто другая версия. Поэтому, насколько я понимаю, гораздо прредпочтительнее частные решения, которые при желании можно увязать с другими компонентами системы - от netcat до AMQP какого-нибудь.
> Пока что я не видел ни одной удачной реализации прозрачного сетевого доступаА мне казалось у эпла на всё это патент 6343263 (http://www.google.com/patents?id=nCYJAAAAEBAJ&printsec=abstr... ) и вроде она как это в своем яфоне реализует и даже успешно почти засудила андроид за такие штуки...
ЗЫ хотя может я и совершенно не прав и патент говорит совершенно о другом... :)
> Но если речь идёт о разработке распределённой вычислительной системы, то пожалуй
> не так важно иметь низкоуровневый доступ к сети.Любой интерфейс межпроцессового взаимодействия можно представить как отправку и получение сообщений, что прекрасно укладывается в интерфейс работы с файлами. Записал в файл - отправил сообщение, прочел файл - получил сообщение. Работа с любым из ресурсов ОС - это ни что иное как взаимодействие между процессами.
Совершенно верно.
Ryan Dahl создатель node js приводил такое сравнение:
Для процессора получить данные из регистра все равно что взять листок со стола.
Получить данные из памяти -- найти в кладовке газету за прошлый год.
Получить данные из сети -- сесть на самолет слетать в Токио забрать книгу и прилететь обратно.
От такой разницы нельзя абстрагироваться.
Например, читать из сети в основном потоке, и блокироваться при этом - плохая идея.
Не соглашусь. Все зависит от надежности работы железок. Забыли уже времена когда время работы на компе до первого сбоя было сравнимо с временем загрузки ОС с флоппи диска ? И ничего, жгли еще как, и не только в тетрис и нортон командер. Сейчас обычный домашний комп состоит из такого количества компонентов, что позавидует суперкомпьютер из 1990-x. Да сам микропроцессор внутри кристалла со времен P2 это многомашинный комплекс по сути. С встроеным компилятором.И все это работает сутками без сбоев и перезагрузок.
Почему бы интернету будущего не стать таким же - безглючным и с задержкой сравнимой с временем прохождения электричесого сигнала по проводу? Это изменит мир до неузнаваемости, какой идиот быдет хранить данные в задрипаной локальной памяти и тем более обсчитывать их на желком локальном 100 ядерном процессоре, если есть бесплатные общедоступные 1000+ ядерные кластеры, надо просто выбрать ник и пароль.
> И все это работает сутками без сбоев и перезагрузок.С учетом недавнего падения Амазона и java приложений на GAE мой домашний компьютер работает стабильнее крупнейших облачных систем.
> Почему бы интернету будущего не стать таким же - безглючным и с
> задержкой сравнимой с временем прохождения электричесого сигнала по проводу? Это изменит
> мир до неузнаваемости, какой идиот быдет хранить данные в задрипаной локальной
> памяти и тем более обсчитывать их на желком локальном 100 ядерном
> процессоре, если есть бесплатные общедоступные 1000+ ядерные кластеры, надо просто выбрать
> ник и пароль.
>с временем прохождения электричесого сигнала по проводуА это разве быстро? Скорость света уже мешает настольный компьютерам с расстояниями метр, что говорить про расстояния в десятки тысяч километров.
Там более разница задержек со временем только растет.
SSD + multicore + DDR3 vs ?
У меня Openoffice грузится быстрее чем google docs.
Я говорил не про сейчас. Про будущее, и да, я помню как мечтал о покупке настоящего 486, который был конвеерным в отличии от 386. Если бы кто мне тогда сказал, что на дешевом домашнем компе будет картинка 1920x1280 и процессор сможет закрасить весь экран одним цветом меньше чем за пол секунды я бы просто рассмеялся ему в лицо.
Если честно, даже i386 не составит никакого труда закрасить 3 мегапиксела за долю секунды. Посчитайте.
Если графическая подсистема работает с памятью быстро.Если.
Я имел дело тогда с каким то полусамодельным ужасом где экономили каждыый бит (дизайн наверно времен когда память была дорогущей) для изменения цвета пиксела нужно было послать x и У в 2 порта, потом уже менять цвет в третьем порту. И по факту на экране это было видно как пикселы один за одним закрашивают все это дело. В черно белом режиме да, оно шустро работало, практически прямой доступ к памяти. А вот цветной режим... Зато он был ЦВЕТНОЙ...
Короче я понял, вы не верите что гигабитный низколатентный тырнет и дешевые как вода облачные кластеры забацают через жалких 7-10 лет, и считать на домашних компьютерах будут только непробиваемые фанатики динозавры? Не верьте. Оно вползет плавно, незаметно, даже внимания не обратите.
> Короче я понял, вы не верите что гигабитный низколатентный тырнет и дешевые
> как вода облачные кластеры забацают через жалких 7-10 лет, и считать
> на домашних компьютерах будут только непробиваемые фанатики динозавры? Не верьте. Оно
> вползет плавно, незаметно, даже внимания не обратите.Хранить данные в облаках будет только дурак, другое дело обработка, можно в принципе отдать это дело в облака, если это что-то не критически важное и не бизенс-тайна. Например научные расчеты и так далее, все то, что требует мощностей.
Просто мощности мобильных устройств постепенно уже дотягиваются до уровня P4, которого для повседневных задач хватит за глаза - почту почитать, музыку послушать, на форум написать, видео посмотреть и т.д. Даже в HD-формате, а в будущем и 3D.
Облака это очередной лохотрон, для хомячков. Тем более что хранить фото и музыку, в облаках, чревато из-за копирастов всяких.
> Да сам микропроцессор внутри кристалла со времен P2 это многомашинный комплекс
> по сути. С встроеным компилятором.Скорее, со встроенным ДЕкомпилятором (microcode ROM) который крушит сложные x86 инструкции в набор более простых элементарных команд.
Конечно! И gcc тож - "ДЕкомпилятор". И единственный "Компилятор" -- это таки ассемблер.
Это проблема удаленного доступа, она остается независимо от ОС. Плюс в том, что в Plan9, это будет худо-бедно, но работать, для остальных же придется писать все с нуля (если нужна сетевая прозрачность). И да, для некоторых приложений этого "худо-бедно" будет более чем достаточно, для других придется дорабатывать.
Да не нужна сетевая прозрачность. Нужны удобные средства работы с сетью - это да. Работа с локальными и удалёнными ресурсами не должна быть одинаковой.
к счастью, ты не в bell labs.
> Совершенно верно.
> Ryan Dahl создатель node js приводил такое сравнение:[...]
> Получить данные из сети -- сесть на самолет слетать в Токио забрать
> книгу и прилететь обратно.
> От такой разницы нельзя абстрагироваться.Это он погорячился. На сегодняшний день память - самая медленная часть системы, а сеть стала просто беспредельная. Всякими InfiniBand можно пихать хоть 10ГБ/сек, хоть 100.
А память была 3, стала в лучшем случае 6, да и то с дикой latency.
Plan 9 - попытка уменьшить количество абстракций в системе. Современные OS становятся неуправляемыми. Ядро, драйверы, HAL, DBus, Control Groups, сетевые стеки, безумные фреймворки. Когда-то я знал про каждый файл, зачем он у меня в системе. Сейчас я уже не могу разобраться, сколько подсистем обрабатывает даже клавиатуру.
об очевидностях.дело в том что /proc/NameProc - это слой абстрагирующий от нюансов.
Unix немножно начался с того что перестал отличать TTY от блочных устройсв и это привело к падению производительности.
FORmulaTRANслятор начался с того что был ацкий дефицит квалифицированых прогеров на уже имеющиеся несколько различных маш кодов для различных железок МеждународныхДеловыхМашин.Очевидно что языки высокого уровня не способны генерировать код который можно писать непосредственно в машкодах.
> Unix немножно начался с того что перестал отличать TTY от блочных устройствНу, эт вы загнули.
Сейчас TTY от блочных устройств не отличает только FreeBSD, насколько я помню. Ну, может быть, какие-то другие *BSD. А так -- для каждого блочного устройства есть две ноды в /dev -- "raw" и "cooked", а для неблочных -- только "raw".
> и это привело к падению производительности.
Это ещё почему?!
UNIX начался с того, что _устройства_ перестали отличаться от _файлов_.
>> и это привело к падению производительности.
> Это ещё почему?!падение(более коректно нерост) в случае отказа от специфичного интерфейса в пользу более абстрактного.
И в общем оно того стоит - узкое место обычно время программиста а не дефицит CPU.
>Неужели не очевидно, что с ними должны применяться принципиально разные техники работы?Нет, не очевидно. Особенно учитывая, что интерфейс и реализация - это разные вещи.
Ключевой момент: нет различия для пользователя, не для системы.
Опять всё добро по карманам распихали... ну и кому нужны они без исходников?
Обобщение подходов, усреднение, подведение всего под один знаменатель означает что мы потеряем плюсы некоторых отдельно взятых элементов. Обобщение это всегда палка о двух концах. Это как бегунок, где на одной стороне эффективность реализации, с другой красивая концепция обобщения, простота работы и программирования. Когда эффективность реализации не является ключевым моментом, получаются совершенно изумительные вещи. Обобщение работы с удаленными и локальными файлами, к сожалению, к таким вещам я отнести не могу, эффективность здесь никогда лишней не бывает.
Подскажите, пожалуйста, как называется программа -- кошачьи часы, изображенные на рисунке. Есть ли порт под Убунту?
games/catclockМожно собрать через plan9port.
> games/catclock
> Можно собрать через plan9port.Спасибо Вам большое.
> # Разработка с нуля собственной реализации ssh2 и Mercurial на языке Go;вообще, это не здоровая тенденция. вместо, того чтобы создавать что-то новое, занимаются велосипедостроением. хотя на то он и just for fun
Система построена на других принципах, портировать существующее затратно настолько, что приближается по сложности к написанию своего.
Забавные люди собрались на OpenNet'е...Спорят, надо ли унифицировать доступ к локальным и сетевым ресурсам...
А я отвечу: надо! И в Юниксе это делается уже давно: 'mount -t nfs' и 'mount -t smb' -- лучший тому пример. С точки зрения open(2) локальные и удалённые файлы (сюрприз! сюрприз!) неразличимы. С точки зрения траверса файловой иерархии -- тоже.
Что мешает продлить концепцию дальше?
P.S: Для тех, кто порекомендует мне сказать 'mount -t smb' на машину в Айове рекомендую сходить на http://grand.central.org/ -- гвозди надо забивать молотком. Да, _разные_ гвозди (по размеру, например) -- молотками _разной_ массы. Но всё равно молотком.
> И в Юниксе это делается уже давно: 'mount -t nfs' и 'mount -t smb' -- лучший тому пример. С точки зрения open(2) локальные и удалённые файлы (сюрприз! сюрприз!) неразличимы.Не различаются как же. Слышали о таком коде ошибке ESTALE ?
/me опустил руку на лицоДавайте, еще про 9atom напишите, "новостники", и про glendix не забудте.
> /me опустил руку на лицо
> Давайте, еще про 9atom напишите, "новостники", и про glendix не забудте.Это не форки, а сборки оригинального года Plan9 с дополнениями. В 9front создали полностью отдельный форк.
>> /me опустил руку на лицо
>> Давайте, еще про 9atom напишите, "новостники", и про glendix не забудте.
> Это не форки, а сборки оригинального года Plan9 с дополнениями. В 9front
> создали полностью отдельный форк.Глендикс это вообще линукс :)
>> /me опустил руку на лицо
>> Давайте, еще про 9atom напишите, "новостники", и про glendix не забудте.
> Это не форки, а сборки оригинального года Plan9 с дополнениями. В 9front
> создали полностью отдельный форк.Это темпоральный вопрос.
btw на очередной набор недоутилит с одим и тем же ядром гнулинукса новости отводятся.
Это удивительно: сколько оказывается на ОпенНете ярых критиков План9, учитывая что о каждом из них можно сказать "Пастернака не читал, но осуждаю". Скачать 70мб, поставить в виртуалку и потеститровать денек - не так уж сложно.
Угу. Не говоря уже явном непонимании отличий между абстракциями и реализациями. Очевидно, что организовывать работу в сети как работу с файлами невыгодно — ну так ведь это только с точки зрения пользователя всё выглядит как файлы. А реализация всё та же.
то то я думаю почему в последнее время так активно в рассылке [9fans]...
где-то написано направление ОС - на что она нацелена? (встраиваемые системы, рабочие станции или таки как ее предшественник на кластеры)
> то то я думаю почему в последнее время так активно в рассылке
> [9fans]...
> где-то написано направление ОС - на что она нацелена? (встраиваемые системы, рабочие
> станции или таки как ее предшественник на кластеры)http://aiju.de/b/plan9-faq ← ответы на все вопросы о plan9 от plan9 пользователей.
>> то то я думаю почему в последнее время так активно в рассылке
>> [9fans]...
>> где-то написано направление ОС - на что она нацелена? (встраиваемые системы, рабочие
>> станции или таки как ее предшественник на кластеры)
> http://aiju.de/b/plan9-faq ← ответы на все вопросы о plan9 от plan9 пользователей.я не о plan9 спрошал а о 9front
>>> то то я думаю почему в последнее время так активно в рассылке
>>> [9fans]...
>>> где-то написано направление ОС - на что она нацелена? (встраиваемые системы, рабочие
>>> станции или таки как ее предшественник на кластеры)
>> http://aiju.de/b/plan9-faq ← ответы на все вопросы о plan9 от plan9 пользователей.
> я не о plan9 спрошал а о 9frontВсе то же самое же, ну.
>>>> то то я думаю почему в последнее время так активно в рассылке
>>>> [9fans]...
>>>> где-то написано направление ОС - на что она нацелена? (встраиваемые системы, рабочие
>>>> станции или таки как ее предшественник на кластеры)
>>> http://aiju.de/b/plan9-faq ← ответы на все вопросы о plan9 от plan9 пользователей.
>> я не о plan9 спрошал а о 9front
> Все то же самое же, ну.тогда ясно. спасибо.
> http://aiju.de/b/plan9-faq ← ответы на все вопросы о plan9 от plan9 пользователей.Если честно, то не смешно.
>> http://aiju.de/b/plan9-faq ← ответы на все вопросы о plan9 от plan9 пользователей.
> Если честно, то не смешно.А с каких пор правда смешна?
Да... Такими темпами скоро пойдут новости о релизе Linux 2.0