Существует множество разных операционных систем с открытым исходным кодом, и если вы пользуетесь одной из них, то почти наверняка она будет на базе ядра Linux и набора программ GNU. Многие думают, что дистрибутив GNU/Linux и был первой open source операционной системой. Но это не так. Его опередил проект Berkeley Software Distribution, или BSD. Причем будет справедливо сказать, что он был также более профессиональным и ориентированным на рынок. Но почему тогда BSD сейчас находится на задворках экосистемы open source, тогда как GNU/Linux играет одну из центральных ролей? Посмотрим на это с исторической перспективы.
История BSD тесно связана с Unix, операционной системой, которая была выпущена AT&T Bell Labs в 1969 году. В конце 70-х группа специалистов Калифорнийского университета в Беркли во главе с Биллом Джоем начала разработку проекта BSD как одного из дистрибутивов Unix. Какой-либо существенный разницы между ними на тот момент не было. Они просто добавили несколько дополнительных утилит, которые включали исходный код, принадлежащий AT&T.
Однако все начало меняться в начале 80-х, когда решение AT&T продавать Unix привело к появлению спроса на свободный клон Unix-а, но без дорогостоящей лицензии. Разработчики BSD в течение нескольких лет трудились над тем, чтобы отделить их код от кода AT&T. Они медленно, но верно шли к созданию собственной полноценной Unix-like операционной системы.
Их цель была достигнута в июне 1991 года, с выпуском BSD Net 2. В отличие от предыдущего релиза Net 1, который состоял по большей части из кода для работы с сетями и не был самостоятельной операционной системой, Net 2 была именно полноценной Unix-like системой.
И так как BSD Net 2 шла с лицензией, которая давала доступ к исходном коду и право свободно распространять как ее саму, так и любые ее производные, она была по сути первой open source операционной системой в истории. Хотя самого понятия «open source» в то время еще не было, и лицензия BSD не соответствовала требованиям Free Software Foundation Ричарда Столлмана, тем не менее Net 2 стала большим шагом вперед для всего сообщества свободного программного обеспечения. Это доказало, что написать свободный клон Unix — реально.
Выпуск Net 2 имел большое значение также и потому, что на тот момент это был единственный свободный клон Unix, который действительно работал. Линус Торвальдс выпустил первую версию ядра Linux лишь через несколько месяцев, причем прошло более чем два года, прежде чем оно стало достаточно применимым. Тогда как в проекте операционной системы GNU, которую с 1984 года разрабатывали Ричард Столлман и его сторонники, еще не было своего рабочего ядра.
Видео:Диагностика DME MSD80 проверка функционирования шины D_BSDСкачать
И если BSD Net 2 была первой свободной Unix-like операционной системой в своем роде, то почему она не смогла «выстрелить» и стать тем, чем стал GNU/Linux — главной платформой экосистемы open source?
В бой вступают юристы
Одной из причин были судебные тяжбы между Berkeley Software Design Inc. (BSDI) и Unix Systems Labs (USL). В начале 90-х компания USL стала владельцем операционной системы AT&T Unix и подала в суд на BSDI за нарушение своих авторских прав. Неудивительно, ведь они разрабатывали свободную альтернативу их продукту. В марте 93 года суд отклонил большинство их претензий, но юридические баталии все еще продолжались вместе с контр-иском Калифорнийского университета. И только в начале 94 года, когда уже компания Novell стала владельцем Unix, все юридические споры были окончательно урегулированы.
Если смотреть в целом, все эти юридические проблемы на самом деле не помешали распространять и использовать операционную систему BSD. Но возникшие сомнения в защищенности ее юридического положения однозначно замедлили это. По всей видимости, именно поэтому возник тот самый исторический шанс для ядра Linux, который позволил ему неожиданно «выстрелить». А ведь это был просто хобби-проект одного финского студента, в отличие от профессиональной разработки группой ученых ведущего американского университета.
Две разные лицензии
Медленный рост BSD не получится объяснить только лишь юридическими проблемами. В конце концов у GNU/Linux тоже были аналогичные серьезные проблемы в начале 2000-х, когда SCO Group подала в суд на нескольких крупных вендоров Linux и корпоративных пользователей. Эти тяжбы в целом завершились только в 2007 году в пользу Linux. Но тем не менее они не оказали такого негативного воздействия, популярность Linux-а продолжала расти.
Читайте также: Шина монтажная для полок 1000 мм
Одна из причин почему BSD не смогла обрести такую популярность среди технически продвинутых программистов и админов («хакеров») заключается в характере лицензии Net 2, которая разрешала практически все. В отличие от лицензии GPL проекта GNU, которая обязывает раскрывать исходный код всех производных продуктов, лицензия BSD к этому не обязывает. Программисты могут свободно заимствовать и модифицировать код для любых задач, не делая его публичным. Это очень хорошо для коммерческих проектов, но плохо для «хакеров», которые ценят открытость и прозрачность.
Две разные методологии
Третья важная причина заключается в том, что BSD разрабатывалась относительно небольшой организованной группой профессиональных программистов из Беркли. В то время как разработка ядра Linux велась Линусом Торвальдсом с помощью широкой и гибкой сети добровольцев раскиданных по всему миру. Используя сравнения Эрика Раймонда из его знаменитого эссе, создание BSD было подобно строительству величественного «собора», который тщательно возводила небольшая группа мастеров своего дела. Тогда как развитие Linux-а выглядело как стихийный «базар», в котором дела решались быстро, новые версии появлялись часто, и единственным требованием к членам этой разношерстной команды была способность решать насущные вопросы.
Видео:шина bsd, как увидеть и найти неисправность.Скачать
«Соборный» подход также был характерен для самого проекта GNU, еще задолго до появления Linux, но именно Linux показал как можно быстро обрести популярность через частые релизы. Таким образом Линус Торвальдс случайно открыл совершенной новый, более эффективный подход в разработке, благодаря которому Linux смог очень быстро эволюционировать, гораздо быстрее чем BSD.
Наследие BSD
Разумеется, проект BSD не мог просто исчезнуть после стремительного взлета Linux в 90-х. Более того, множество свободных операционных систем, берущих начало из Net 2, в первую очередь NetBSD, OpenBSD, FreeBSD, продолжает жить и здравствовать, пусть с небольшим, но зато преданным комьюнити.
В то же время, характер лицензии BSD привел к ее популярности среди разработчиков проприетарного ПО. Самый яркий пример — это компания Apple, которая использовала исходники BSD в своих операционных системах macOS и iOS. Учитывая это, BSD — в той или иной форме — имеет сегодня огромную армию поклонников, хотя большинство владельцев макбуков и айфонов даже не подозревают, что их устройства используют «open source» код, который разрабатывали в Беркли с 80-х до начала 90-х.
Возможно, это печально, ведь программные решения Apple закрыты настолько, насколько это возможно. Это прямая противоположность того, о чем мечтали создатели BSD, когда выпустили Net 2 в 1991 году. Как бы то ни было, итог получился интересный.
Примечания переводчика
Это был перевод статьи «Open Source History: Why Didn’t BSD Beat Out GNU and Linux?», автор Christopher Tozzi.
Отмечу, что на сайте FreeBSD приводятся немного другие сведения — о том, что первой полноценной операционной системой была не BSD Net 2, а 386BSD, вышедшая в 1992 году. На русском, на английском.
Еще одним ярким примером популярности наследия BSD является игровая приставка Sony Play Station — ее операционная система является форком FreeBSD.
Видео:Проверка шины bsd на msd85.1Скачать
Понимая, что затронута достаточно холиварная тема, прошу всех писать только взвешенные комментарии и уважать другую точку зрения. Давайте также сделаем небольшой опрос.
Путешествие в мир сервисных корпоративных шин на IBM WebSphere ESB
Данной статьей хочется открыть цикл, посвященный IBM WebSphere ESB (далее — ESB) в разрезе разработки под этот продукт. И, в первую очередь, придется познакомиться поближе с технологиями такого рода.
Enterprise service bus (сервисная шина предприятия) — связующее программное обеспечение, обеспечивающее централизованный и унифицированный событийно-ориентированный обмен сообщениями между различными информационными системами на принципах сервис-ориентированной архитектуры.
Конечно же, можно и без специального ПО (возможно, что-то общее таки придется разработать) строить корпоративную систему основываясь на таком подходе, и то, что в результате получится, называть сервисной шиной. Но в продукте от IBM есть не только уже готовый аппарат для централизованного обмена сообщениями и контроля этого процесса, но и полный набор возможностей для разработки гибких сервис-ориентированных приложений специально под ESB. В итоге, можно выделить следующие возможности и преимущества IBM WebSphere ESB:
- Порядок и единообразие архитектурных связей
- Централизованное управление
- Конфигурация приложений на стороне сервера
- Реализация технологии Service Component Architecture (SCA) в духе принципов сервис-ориентированной архитектуры
- Протоколо-независимость разрабатываемого программного кода
- Широкие возможности конфигурирования шины и приложений
Читайте также: Для чего при переломах человеку накладывают шину выберите ответ
При этом ESB обеспечивает транзакционный контроль, преобразование данных, сохранность и гарантированную доставку сообщений. Доступ ко всем сервисным службам через единую точку позволяет осуществлять конфигурирование коммуникации сервисов централизованно. Так же централизованно можно управлять сбойными событиями для массовой обработки ошибок.
Классическая топология сборки ESB – кластер, обеспечивающий горизонтальную масштабируемость и отказоустойчивость. По официальным рекомендациям, увеличение количества членов кластера увеличивает производительность более эффективно, чем наращивание мощности сервера при stand-alone топологии. Кроме этого, кластер можно перезагрузить (или его часть может отказать) без остановки обслуживания.
Обычно ESB используется как сервисная прослойка в IBM BPM, но вполне может играть ведущую роль в построении модели взаимодействия корпоративных систем как мощный интеграционный аппарат (имеется в виду ESB как надстройка над IBM WebSphere Application Server).
Это, по сути, требуется от ESB, так как это «точка сбора сервисов» — если вам нужен сервис, который будет работать с другими сервисами (возможно, внешними), то интеграцию между этими сервисами логичнее всего сделать именно на ESB. Для внешних или гетерогенных сервисов можно сделать «обертку» ESB-сервисом. Немного проиллюстрируем удобства использования «единого жилья» для сервисов:
Порядок
Чем большего размера система, тем более важен в ней порядок и единообразие. Если речь идет о комплексе систем большого предприятия, то его точно уж можно назвать системой большого размера. Конечно, всегда можно найти администратора, держащего в голове схему взаимодействия сотни серверов, или кучу томов несвязанной документации по каждому программному модулю, где описано, с чем и как он взаимодействует.
Но намного проще иметь сервис (ESB), который позволяет проводить все взаимодействие через себя. При таком подходе часть архитектуры взаимодействия в любой подсистеме уже понятна – нет бардака в связях между системами, серверами и приложениями: все связано с ESB и ESB связано со всем.
Видео:BMW F10 N52 Ремонт bsd шины - уровень масла в двигателе / Repair MSV90 BMW F10 N52 bsd problem.Скачать
Централизованное управление
Всегда удобнее производить настройку систем централизованно – будь то конфигурирование, адаптация к переезду серверов, обеспечение отказоустойчивости, распределение нагрузки, обработка ошибок либо мониторинг и аналитика.
Например, при переезде сервера БД не нужно залезать в конфигурацию всех существующих серверов приложений, и в настройки конкретных приложений в частности – достаточно иметь одну переменную среды в ESB, в которой указывается адрес БД, и тогда изменения нужно будет выполнить всего в одной точке.
Или же если одна из внешних систем была недоступна длительное время, а ни один запрос к ней не должен потеряться – можно воспользоваться сервисом обработки сбойных событий для «вбрасывания» недошедших сообщений тогда, когда это будет удобно.
Если вам нужно регулировать количество одновременных запросов к какой-либо системе, либо мониторить эти запросы, анализировать нагрузку, искать узкие места – вам нужно в центр управления обмена сообщениями – в консоль ESB-сервера.
Конфигурация на стороне сервера
«Единое жилье» для сервисов, с точки зрения конфигурирования, позволяет достичь нескольких полезных целей. Во-первых, это повторное использование конфигурации (по аналогии с повторным использованием кода и модулей, которое так полезно в SOA), поскольку разные модули и приложения могут использовать одни и те же параметры соединения с БД, ресурсы, параметры аутентификации, переменные среды и прочее.
Во-вторых, при конфигурировании на стороне сервера именно среда работы приложения во многом может на него влиять, что позволяет переносить приложения между разными контурами (тестовым и продуктивным), тюнинговать и даже исправлять баги без внесения изменений в приложение.
Если использовать все эти преимущества, приложения получают способности истинного хамелеона – они настолько гибкие, что стают частью среды, в которой работают, и при этом привносят свой важный функционал.
Но гибкость приложений под IBM WebSphere ESB не ограничивается средой их работы. Громадный вклад в это делают возможности разработки. Поскольку, системы не только нужно иметь, где запускать, но еще нужно разрабатывать и дорабатывать, эти интересные пункты упускать нельзя:
Читайте также: Как определить сторону шины nokian
Видео:Экспресс диагностика CAN шины на автомобиле. №21Скачать
SCA
Эта архитектура основывается на принципе предоставления компонентой своей функциональности в виде сервиса, доступного другим компонентам. В рамках одного модуля компонентами выступают программные блоки (java код), полностью реализующие некий функционал, описанный соответствующим интерфейсом. Логика выполнения компонент реализуется связыванием их в структуру по интерфейсам и reference’ам (Partner Reference).
Такую структуру модуля очень удобно разрабатывать, проверять, развивать, изменять и поддерживать. Атомарность функционала, реализованного в компонентах, позволяет оперировать компонентами в целом, не опускаясь до уровня кода. С другой стороны, она логично необходима ввиду выполнения имплементаций компонент в транзакционном контексте.
У каждой компоненты есть интерфейс(ы), имплементацию которого она предоставляет. Таким образом, связывая между собой компоненты, нет необходимости знать их внутренние особенности – достаточно того, что они реализуют необходимые интерфейсы.
Посредством данной архитектуры также можно решить все задачи, требующие параллельной работы, без «ручного» управления потоками (например, можно выполнять асинхронные вызовы нескольких компонент с отсроченным ответом).
Не java-компоненты, например, типов Export и Import, позволяют предоставлять сервисы для внешнего использования либо использовать внешние сервисы соответственно; компонента Mediation Flow обеспечивает низкоуровневый доступ к сообщениям, которыми обмениваются другие компоненты и позволяет производить различные преобразования при работе с гетерогенными интерфейсами.
Помимо интерфейсов, очень полезные возможности предоставляет IBM business object framework. Бизнес-объекты (БО), представлены xsd-схемами, используются как объекты для передачи данных в интерфейсах, как между компонентами, так и для коммуникации между модулями. Они же напрямую интегрируются, например, в wsdl-схему для описания веб-сервисов. То есть, например, если модуль «А» предоставляет свой функционал в виде веб-сервиса, модулю «Б» для его использования достаточно подключить интерфейс и готовые БО, и он сможет в полной мере работать с таким сервисом без создания каких-либо дополнительных java-объектов для передачи данных. БО также удобно использовать при обмене данными с БД, если эти данные используются другими компонентами (это, конечно, идет в разрез с паттерном «DAO», но избавляет от лишних java-объектов и операций переписывания данных «туда-сюда»).
Протоколо-независимость программного кода
Как можно было заметить, протоколо-независимость кода достигается путем использования компонент Export и Import. Поскольку связь с этими компонентами идет по интерфейсам и reference’ам, программный код полностью независим от используемого для взаимодействия протокола. Один и тот же функционал можно легким движением сделать доступным по любому количеству поддерживаемых протоколов и по любым нужным интерфейсам. На следующем рисунке показано добавление экспорта с SCA привязкой к компоненте, которая уже предоставляет свой интерфейс как HTTP, JMS и Web-сервис.
Удобства очевидны – гибкость, универсальность, повторное использование кода, быстрота разработки и модификации.
Кстати, SCA привязка использует особый протокол и предназначена для сообщения между модулями в рамках одного сервера/кластера. Взаимодействие через эту привязку менее ресурсоемкое и более быстрое по сравнению с другими протоколами.
Конфигурирование
Конфигурирование сервера и приложений осуществляется через IBM console сервера.
В ESB, как и в IBM WebSphere в общем, довольно много специфических возможностей и артефактов. Например, при использовании тех же импортов и экспортов, можно «на лету» конфигурировать end-point’ы соответствующих сервисов. Для вызовов сервисов можно настраивать policy set’ы с разнообразными правилами (например, можно установить поддержку механизма WS-AT, который позволяет вызывать веб-сервис в той же транзакции, в которой работает клиент; но транзакционность – это уже тема для полной статьи), устанавливать параметры аутентификации, подключать сертификаты и прочее.
Через конфигурирование можно настроить некоторые механизмы автоматической реакции на исключительные ситуации (например, автоматическое повторение выполнения компонент при ошибках). Можно «на лету» настроить трассировку компонент или изменить уровни логирования. Также доступен сервис управления сбойными событиями, который можно осознанно использовать для массовой обработки ошибок.
Ну и, конечно же, можно настроить много чего другого согласно спецификации Java2EE, которая, иногда довольно строго, реализована в IBM Application Server.
Все вышеприведенное утверждает ESB как удобный, мощный и гибкий интеграционный аппарат, пусть и не всегда легкий в освоении. В дальнейшем нужно всего лишь научиться им пользоваться.
В статье использованы следующие изображения: 1 2 3 4 5
Видео:BMW F10 523i ремонт bsd шины не показывает уровень масла / BMW F10 523i repair BSD no see level oilСкачать
- Свежие записи
- Нужно ли менять пружины при замене амортизаторов
- Скрипят амортизаторы на машине что делать
- Из чего состоит стойка амортизатора передняя
- Чем стянуть пружину амортизатора без стяжек
- Для чего нужны амортизаторы в автомобиле
🔥 Видео
CAN шина👏 Как это работаетСкачать
Проверка bsd шины msv90 на столеСкачать
Вот вам и китайская резинаСкачать
BSD DONNASTREET - САМЫЕ УЖАСНЫЕ ПОКРЫШКИСкачать
С чего начать ремонт ЭБУ: Типы шин данных, k lineСкачать
BMW F10 N52 Ремонт шины bsd MSV90 / bsd repair MSV90 BMW F10 N52Скачать
Какие зимние шипованные шины лучшие зимой 2024?Скачать
BMW F10 MSV90 N52 Ремонт уровня масла / Repair bsd oil level for ecu MSV90 BMW F10Скачать
Купил покрышки BSD DONNASTREETСкачать
Что означает МАРКИРОВКА НА ШИНАХ / Значение всех цифр и букв на резинеСкачать
BMW 523 F10 Ремонт эбу МСВ90 bsd шина / Repair MSV90 for bsd lin for BMW F10 523i N52Скачать
С чего начать ремонт ЭБУ: Типы шин данных, CANСкачать
BMW E70 X5M Ремонт эбу двигателя msd85.3 bsd шина / Repair msd85 BMW E70 X5MСкачать
BMW F10 Ремонт шины bsd эбу dme MSV90 / bsd repair MSV90 for BMW F10 N52Скачать
