Оказывается в Беркли есть курс по FreeBSD kernel internals :)
Пруф: extension.berkeley.edu
Пруф: extension.berkeley.edu
Мдя, пропустил релиз нового снапшота barrelfish от 2011-03-01: barrelfish.org
Из нововведений радуют: "Completely revamped message passing system (including bulk transport drivers)." и "the Phoenix MapReduce run-time."
будем посмотреть
Из нововведений радуют: "Completely revamped message passing system (including bulk transport drivers)." и "the Phoenix MapReduce run-time."
будем посмотреть
"This white paper provides a tutorial like overview of the fundamental issues that apply to multicore software operating systems implementation for the telecom/ networking space. It starts with consideration of the different generic application processing classes in telecom/networking (e.g. control plane, data plane). It then considers the mapping of these processing requirements to the two primary software processing models for multicore (e.g. SMP, AMP, etc)." eetimes.com
Для даунлода статьи нужен аккаунт на EETimes. Те, кому влом его заводить, могут скачать статью отсюда: dl.dropbox.com
Для даунлода статьи нужен аккаунт на EETimes. Те, кому влом его заводить, могут скачать статью отсюда: dl.dropbox.com
"Cooperation between independent agents depends upon establishing a degree of security. Each of the cooperating agents needs assurance that the cooperation will not endanger resources of value to that agent. In a computer system, a computational mechanism can assure safe cooperation among the system's users by mediating resource access according to desired security policy. Such a mechanism, which is called a security kernel, lies at the heart of many operating systems and programming environments.
I claim that the lambda-calculus can serve as the central component of a simple and flexible security kernel. The present report supports this thesis by motivating and describing such a lambda-calculus-based security kernel and by giving several lines of evidence of the kernel's effectiveness."
A Security Kernel Based on the Lambda Calculus fare.tunes.org
I claim that the lambda-calculus can serve as the central component of a simple and flexible security kernel. The present report supports this thesis by motivating and describing such a lambda-calculus-based security kernel and by giving several lines of evidence of the kernel's effectiveness."
A Security Kernel Based on the Lambda Calculus fare.tunes.org
На LWN интересная статья "The Hurd: GNU's quest for the perfect kernel" lwn.net
Отличная статейка: The Caernarvon Secure Embedded Operating System
"The Caernarvon operating system was developed to demonstrate that a high assurance system for smart cards was technically feasible and commercially viable. The entire system has been designed to be evaluated under the Common Criteria at EAL7, the highest defined level of assurance.
...
This approach facilitated implementation of a formally specified, mandatory security policy providing multi-level security (MLS) suitable for both government agencies and commercial users. The mandatory security policy requires effective authentication of its users that is independent of applications. For this reason, the Caernarvon OS also contains a privacy-preserving, two-way authentication protocol integrated with the Mandatory Security Policy."
dl.dropbox.com
Довольно интересно почитать про секурное ядрышко, запускаемое на smart cards. Жаль только, что IBMовцы сорцы не выложили. :(
"The Caernarvon operating system was developed to demonstrate that a high assurance system for smart cards was technically feasible and commercially viable. The entire system has been designed to be evaluated under the Common Criteria at EAL7, the highest defined level of assurance.
...
This approach facilitated implementation of a formally specified, mandatory security policy providing multi-level security (MLS) suitable for both government agencies and commercial users. The mandatory security policy requires effective authentication of its users that is independent of applications. For this reason, the Caernarvon OS also contains a privacy-preserving, two-way authentication protocol integrated with the Mandatory Security Policy."
dl.dropbox.com
Довольно интересно почитать про секурное ядрышко, запускаемое на smart cards. Жаль только, что IBMовцы сорцы не выложили. :(
"MAKER OF MOBILE GADGETS Research in Motion (RIM) has abandoned its own operating system for its forthcoming tablet in favour of one built by an outfit it just bought called QNX.
...
This apparently interests the maker of Blackberrys because it can take advantage of the software work that has been done by QNX to get enough consumer type products onto the new tablet."
theinquirer.net
Почему-то мне кажется, что эта затея заранее обречена на провал. :)
...
This apparently interests the maker of Blackberrys because it can take advantage of the software work that has been done by QNX to get enough consumer type products onto the new tablet."
theinquirer.net
Почему-то мне кажется, что эта затея заранее обречена на провал. :)
Попала мне в лапы статья Joel'а с громким названием "Biculturalism". Она объективно рассказывает про культурные различия unix и m$ идеологий, плавно подводя читателя к простой, но очень правильной мысли: "windows and unix are the same shit functionally but a bit different ideologically". Красноглазым адептам религии "linux" стоит почитать(красноглазых адептов религии "windows" не упомянаю, ибо подобных на жуйке не видел), может мозги немного вправятся: joelonsoftware.com
pages.cs.wisc.edu
Весьма любопытные classes ведёт этот Remzi. Радуют мозг и некоторые его публикации.
Весьма любопытные classes ведёт этот Remzi. Радуют мозг и некоторые его публикации.
2й снапшот barrelfish: barrelfish.org
QNX отвратительно работает на SMP системах. В ядре более 200 раз в идеологически разных ядерных подсистемах(IPC, timers, scheduler, etc), хватается big kernel lock(BKL). Когда такая лочка захвачена, таски с других CPU спинятся на точке входа в ядро. Таким образом с захваченым BKL таски только с одного CPU могут находится в пространстве ядра. Помимо отвратной производительности на SMP системах, это явный priority inversion. Если таск с низким приоритетом с CPU0 захватил BKL, а таск с высоким приоритетом с CPU1 делает сискол, он будет ждать окончания работы таска с низким приоритетом. А король-то голый.
У Тома Андерсона есть ряд очень любопытных исследований на тему структуры и реализации тредов в shared memory multiprocessor systems. С ростом колличества ядер на камушке и к растущей тенденции падения цен на многоядерные процессоры, исследования такого плана становятся всё более и более актуальными. A priori известно, что software threads(т.е. треды, сделанные на уровне user-space приложения) работают быстрее и стоят дешевле, чем operating system threads, т.е. треды предоставляемые ядром операционной системы. Основные проблемы первых заключаются в том, что они a) не могут прозрачно мигрировать на другие CPU, b) не вписываются в дефолтные политики шедулинга, т.к. ядро ничего про них не знает и c) не поддерживают систему приоритетов, а следовательно real-time(в общем случае)
Том Андерсон построил модель, в которой возможно существование software threads, о которых знает шедулер ядра операционной системы. cs.washington.edu
Профиты этого подхода очевидны, особенно в области виртуальных машин(i.e. java, pythonvm, rubyvm, etc), которые вынуждены реализовывать извращённый секс между operating system threads и своими собственными тредами.
Том Андерсон построил модель, в которой возможно существование software threads, о которых знает шедулер ядра операционной системы. cs.washington.edu
Профиты этого подхода очевидны, особенно в области виртуальных машин(i.e. java, pythonvm, rubyvm, etc), которые вынуждены реализовывать извращённый секс между operating system threads и своими собственными тредами.
В последнее время попадалось очень много ссылок(с тех же редитов и игриккомбинаторов) на восторженные посты блоггеров о светлом будущем заключающемся в совокуплении со сказочным концептом WebOS. Мол, дайте нам только браузер, а об остальном позаботится большой брат или гугл, хотя какая хрен разница. Не спорю, есть тенденция перехода, скажем так, "социальных" приложений (mail, документооборот, rss-readers, todo-lists, etc) с уютного local storage на сервер. Соглашусь, что скорее всего в ближайшую пятилетку список "социальных" приложений пополнится приложениями специализированными(бухгалтерия например, разные математические пакеты, etc). Но я вот одного понять не могу, почему люди думают, что сии шаги приведут отмиранию desktop софта и единому сферическому браузеру в вакууме? Это же поебень феерическая.
В браузере мы будем читать документы во всех форматах, писать код, манагить таски, смотреть порнуху и организовывать data storage? Булшит. Имхо более адекватна тенденция к "расчленению" браузера на взаимосвязанные, но функционально разные "органы".
По пунктам:
1) Нужен глобальный профиль пользователя, распознаваемый независимыми серверами. Т.е. если я себе создал некий vcard, в котором написано, что я Харитон Иванович, любой нормальный сервис должен встретить меня солью и хлебом, а не надписью "Anonymous user". Ну и создать N других "vcard", где я Dark Lord, чтобы ползать по порносайтам, и было не очевидно, что я на самом деле Харитон Иванович, белый и пушисто-мягкий воспитатель детского сада, например.
2) Допустим Вася пользуется гугль ридером для чтения rss, а его знакомые кореша с района пользуются какими-то другими ридерами. Все пацанчики хотят ч0тко шарить между собой понравившиеся линки, но переходить на Васин сервис(который умеет шарить посты между его(сервиса) пользователями) им западло. Васе тоже западло переходить на их сервис. А сервисов таких тысячи. Что делать?
Берётся RSS клиент, который знает API google reader'a и API сервисов Васиных корешей, с их сервисов сливаются shared items, а гугль ридер используется, как основной storage для записей.
3) То же самое с mail и todo. Гугль конвертит мылы в таски одним макаром, яху другим, адхост третьим, есть тот же rememberthemilk, который к мылу никакого отношения не имеет. Берётся стандартный мыл клиент, к нему добавляется кнопка "convert to task" при нажатии на которую активируется приложение todo, которое в свою очередь зная про google, яху и rememberthemilk уже шлёт event нужному сервису, пользуясь его протоколом.
4) Опять же у любого нормального параноика будет набор todo, которые он не хочет выкладывать на сервер. Например если человек ставит в todo "связаться с талибаном" или "свергнуть правительство", он скорее всего захочет воспользоваться локальным storage. А отдельному приложению todo поддерживать и совершенствовать эту возможность наряду с возможностью управления контентом на разных серверах гораздо проще, чем браузеру.
5) То же самое с pdf/djvu reader'ами и написанием текста/коммента/кода в браузере. Кликнув по ссылке на документ определённого формата гораздо я не хочу увидеть говнофлеш с текстом, который можно листать, я хочу, чтобы открылось определённое приложение, которое всё это прочитает(и сохранит по моему запросу, если сервер даёт такую возможность).
При ответе, скажем, на коммент гораздо лучше открывать таб в любимом редакторе юзера, например емаксе(который юзер задротно конфигурил годы, чтобы достичь максимального графоманского дзена) вместо убогого дефолтного textarea.
Вот уж где-где, а в вебосах unix way просто неизбежен.
Кончил.
В браузере мы будем читать документы во всех форматах, писать код, манагить таски, смотреть порнуху и организовывать data storage? Булшит. Имхо более адекватна тенденция к "расчленению" браузера на взаимосвязанные, но функционально разные "органы".
По пунктам:
1) Нужен глобальный профиль пользователя, распознаваемый независимыми серверами. Т.е. если я себе создал некий vcard, в котором написано, что я Харитон Иванович, любой нормальный сервис должен встретить меня солью и хлебом, а не надписью "Anonymous user". Ну и создать N других "vcard", где я Dark Lord, чтобы ползать по порносайтам, и было не очевидно, что я на самом деле Харитон Иванович, белый и пушисто-мягкий воспитатель детского сада, например.
2) Допустим Вася пользуется гугль ридером для чтения rss, а его знакомые кореша с района пользуются какими-то другими ридерами. Все пацанчики хотят ч0тко шарить между собой понравившиеся линки, но переходить на Васин сервис(который умеет шарить посты между его(сервиса) пользователями) им западло. Васе тоже западло переходить на их сервис. А сервисов таких тысячи. Что делать?
Берётся RSS клиент, который знает API google reader'a и API сервисов Васиных корешей, с их сервисов сливаются shared items, а гугль ридер используется, как основной storage для записей.
3) То же самое с mail и todo. Гугль конвертит мылы в таски одним макаром, яху другим, адхост третьим, есть тот же rememberthemilk, который к мылу никакого отношения не имеет. Берётся стандартный мыл клиент, к нему добавляется кнопка "convert to task" при нажатии на которую активируется приложение todo, которое в свою очередь зная про google, яху и rememberthemilk уже шлёт event нужному сервису, пользуясь его протоколом.
4) Опять же у любого нормального параноика будет набор todo, которые он не хочет выкладывать на сервер. Например если человек ставит в todo "связаться с талибаном" или "свергнуть правительство", он скорее всего захочет воспользоваться локальным storage. А отдельному приложению todo поддерживать и совершенствовать эту возможность наряду с возможностью управления контентом на разных серверах гораздо проще, чем браузеру.
5) То же самое с pdf/djvu reader'ами и написанием текста/коммента/кода в браузере. Кликнув по ссылке на документ определённого формата гораздо я не хочу увидеть говнофлеш с текстом, который можно листать, я хочу, чтобы открылось определённое приложение, которое всё это прочитает(и сохранит по моему запросу, если сервер даёт такую возможность).
При ответе, скажем, на коммент гораздо лучше открывать таб в любимом редакторе юзера, например емаксе(который юзер задротно конфигурил годы, чтобы достичь максимального графоманского дзена) вместо убогого дефолтного textarea.
Вот уж где-где, а в вебосах unix way просто неизбежен.
Кончил.
Скачал сорцы бочкорыбы. Я в щенячем восторге, ребятам из m$ research удалось совместить лучшие аспекты l4 и coyotos'a, сохранив минимальный code base. Пойду дальше мастурбировать на код.
Дико уважаю m$ research:
"Barrelfish is a new research operating system being built from scratch in a collaboration between ETH Zurich in Switzerland and Microsoft Research Cambridge in the UK. We are exploring how to structure an OS for future multi- and many-core systems. We are motivated by two closely related trends in hardware design: first, the rapidly growing number of cores, which leads to a scalability challenge, and second, the increasing diversity in computer hardware, requiring the OS to manage and exploit heterogeneous hardware resources."
...
"Barrelfish is released under the 3-clause BSD-style Open Source licence."
main: barrelfish.org
sources: barrelfish.org
"Barrelfish is a new research operating system being built from scratch in a collaboration between ETH Zurich in Switzerland and Microsoft Research Cambridge in the UK. We are exploring how to structure an OS for future multi- and many-core systems. We are motivated by two closely related trends in hardware design: first, the rapidly growing number of cores, which leads to a scalability challenge, and second, the increasing diversity in computer hardware, requiring the OS to manage and exploit heterogeneous hardware resources."
...
"Barrelfish is released under the 3-clause BSD-style Open Source licence."
main: barrelfish.org
sources: barrelfish.org
"Verifying the kernel – known as the seL4 microkernel – involved mathematically proving the correctness of about 7,500 lines of computer code in an project taking an average of six people more than five years." unsw.edu.au
Хм, "exokernel" на языке D: github.com
Exokernel включил в кавычки потому, что судя по сорцам ребята плохо себе представляют что такое exokernel и куда его еб^Wдят.
Но сам факт работающего ядра, полностью(включая весь low-level: interrupt management, ioapic, lapic, etc) написанно на D ломает мои архаичные представления о реализации ядер операционных систем. Хотелось бы ещё посмотреть, что там по скорости получается...
Exokernel включил в кавычки потому, что судя по сорцам ребята плохо себе представляют что такое exokernel и куда его еб^Wдят.
Но сам факт работающего ядра, полностью(включая весь low-level: interrupt management, ioapic, lapic, etc) написанно на D ломает мои архаичные представления о реализации ядер операционных систем. Хотелось бы ещё посмотреть, что там по скорости получается...
Не понимаю почему немалое колличество двуногих-прямоходящих так неистово душат налима на концепцию language protection operating systems (http://en.wikipedia.org/wiki/Language-based_system, см: javaos, singularity, midori, phantomos, inferno, etc), вопя направо и налево, что за ними, мол, будущее. Много курил, много думал на что там можно душить несчатного налима, где профит? Ну да, мы запихиваем VM в ядро, да у нас есть language protection, да такую систему проще верифицировать, но какими жертвами? Есть у нас, предположим, православный язык dick#, есть у нас кошерная VM для dick#, которую мы вбили молотком в ведро и что? Как только нам требуется использование языка, использующего другую VM(python, ocaml, lisp, scheme, ruby, java, etc), что мы делаем? Варианта ровно 3:
1) написать транслятор байткода языка X в байткод dick# VM. Дроубеки очевидны: мало того, что транслятор приведёт к менее эффективому байткоду, нежели было в оригинале, так его ещё постоянно придётся мейнтейнить для каждого языка Xi, когда фичи в его VM меняются.
2) Написать layout для языка X в байткод dick#. Опять же придётся мейнтейнить для каждого Xi, да и не факт, что фичи языка X без проблем лягут на байткод dick#.
3) Запретить юзеру использовать программы, написанные на языках, отличных от dick#. Самый простой и эффективнй способ.
Помимо этого можно забыть о разработке под такую платформу на языках с прямым доступом к памяти типа C, C++, pascal, etc.
И кстати как быть real-time приложениям? В системах с language based protection by default работает GC, а чтобы его адаптировать под real-time requirenments необходимы его(GC) нехреновые модификации(см. например real-time java GC: java.sun.com).
Такие(language protection based) ОС ещё сильнее ограничивают свободу программиста, ещё больше усложняя ему жизнь. Как быть разработчикам, скажем, баз данных, которые на обычных ОС были ограниченны в возможностях лишь стандартными механизмами memory allocator'а, page-replacement алгоритмом, файловой системой и block layer'ом? В системах типа singularity и ей подобным они будут абсолютно абстрагированны от физических ресурсов системы, что непременно скажется на их производительности. Чем больше я об этом думаю, тем больше прихожу к выводу, что Engler был прав, говоря: /"Applications know better than operating systems
what the goal of their resource management decisions should be and therefore, they should be given as much control as possible over their descitions."/
Так что будущее за extensible operating systems. В концепции экзоядра я верю слабо, ибо вижу там много проблем, но вот гибриды типа L4, K42, sawmill или nemesis показали, что профит от такого подхода можно поиметь неслабый.
Кончил.
1) написать транслятор байткода языка X в байткод dick# VM. Дроубеки очевидны: мало того, что транслятор приведёт к менее эффективому байткоду, нежели было в оригинале, так его ещё постоянно придётся мейнтейнить для каждого языка Xi, когда фичи в его VM меняются.
2) Написать layout для языка X в байткод dick#. Опять же придётся мейнтейнить для каждого Xi, да и не факт, что фичи языка X без проблем лягут на байткод dick#.
3) Запретить юзеру использовать программы, написанные на языках, отличных от dick#. Самый простой и эффективнй способ.
Помимо этого можно забыть о разработке под такую платформу на языках с прямым доступом к памяти типа C, C++, pascal, etc.
И кстати как быть real-time приложениям? В системах с language based protection by default работает GC, а чтобы его адаптировать под real-time requirenments необходимы его(GC) нехреновые модификации(см. например real-time java GC: java.sun.com).
Такие(language protection based) ОС ещё сильнее ограничивают свободу программиста, ещё больше усложняя ему жизнь. Как быть разработчикам, скажем, баз данных, которые на обычных ОС были ограниченны в возможностях лишь стандартными механизмами memory allocator'а, page-replacement алгоритмом, файловой системой и block layer'ом? В системах типа singularity и ей подобным они будут абсолютно абстрагированны от физических ресурсов системы, что непременно скажется на их производительности. Чем больше я об этом думаю, тем больше прихожу к выводу, что Engler был прав, говоря: /"Applications know better than operating systems
what the goal of their resource management decisions should be and therefore, they should be given as much control as possible over their descitions."/
Так что будущее за extensible operating systems. В концепции экзоядра я верю слабо, ибо вижу там много проблем, но вот гибриды типа L4, K42, sawmill или nemesis показали, что профит от такого подхода можно поиметь неслабый.
Кончил.
Кто может назвать несферические бенефиты persistent operating systems? (http://en.wikipedia.org/wiki/Orthogonal_persistence#Persistent_Operating_Systems) Интересуют бенефиты как с точки зрения юзера, так и с точки зрения программиста.
Я пока что вижу только 2:
1) В приложениях типа оффис/текстовый редактор не нужно самому имплементить autosave необходимого контекста.
2) В приложениях, делающих долгие мат. вычисления не нужно имплементить костыль save/restore execution.
Лично я больше бенефитов пока не вижу.
Я пока что вижу только 2:
1) В приложениях типа оффис/текстовый редактор не нужно самому имплементить autosave необходимого контекста.
2) В приложениях, делающих долгие мат. вычисления не нужно имплементить костыль save/restore execution.
Лично я больше бенефитов пока не вижу.