О создании новой операционной системы в последнее время говорят немало, особенно в России. В сумме размер всех публикаций по данной теме наверняка превышает размеры исходного кода любой операционной системы. Так что остается только одна проблема – от этих разговоров никаких новых OS не появляется. Всё, что предъявляется публике (и на что тратятся бюджетные деньги), на поверку оказывается кастомизированными сборками OS семейства Linux, а значит, не содержит ничего принципиально нового. Но, если о чем-то не говорят, это не значит, что его не существует.
В этой статье – проект принципиально новой OS, созданный в нерабочее время одним из ведущих сотрудников (Principal Engineer) российского подразделения Intel.
Общие характеристики системы
Свойства предлагаемой ОС совпадают с целями ее создания. А именно:
- минимально возможное потребление системных ресурсов
- масштабируемость по отношению к мощности процессора, памяти, месту на диске, количеству одновременно выполняемых задач, то есть, применимость как в мощных серверах, так и в мобильных устройствах и даже таких специфических системах, как сети беспроводных сенсоров
- унифицированное решение для гетерогенных компьютерных систем, включая сетевые, то есть, поддержка совместной работы на системах CPU и GPU различной архитектуры, с оптимальным распределением работы между ними
- повышение надежности и безопасности (в сравнении с существующими системами)
- легкость разработки, распространения и обновления программного обеспечения при максимальном сохранении существующих сейчас языков и инструментов разработки софта.
Основные принципы, лежащие в основе работы ОС
Сначала – о том, что предполагается оставить без (существенных) изменений по сравнению с существующими системами либо просто вынести за рамки дизайна ОС, оставив это на усмотрение разработчиков конкретных имплементаций.
- Пользовательский интерфейс. Он может быть любым – от самых сложных вариантов до простой текстовой консоли, например, в случае системы беспроводных сенсоров.
- Модель работы с памятью. Виртуальная и физическая память, страницы… или линейное адресное пространство. Наличие или отсутствие свопа, защиты областей памяти..
- Разграничение прав доступа на пользовательские и привилегированные..
- Файловая система. Она также может быть любой из ныне существующих, либо реализовать современные идеи отказа от файлов и представления всего в виде объектов, либо вообще, как Гудвин, великий и ужасный, выглядеть по-разному для разных приложений….
А теперь о том, что будет новым.
Прежде всего, название ;). У предлагаемой ОС пока нет устоявшегося названия. Хотя обсуждаются разные варианты (можете предлагать свои в комментариях), рабочее название – ROS OS.
?Знакомьтесь, Resource-Owner-Service (ROS) модель
Основная идея устройства новой ОС, названная автором Resource-Owner-Service (Ресурс-Владелец-Услуга) и призванная обеспечить вышеприведенные характеристики системы, красива, проста и, на первый взгляд, знакома. Но только на первый взгляд. Итак:
- Все «компоненты» устройства, на котором работает ОС, – как железные (ЦПУ, место для хранения данных и т.п.), так и программные (например, участки кода, реализующие определенный алгоритм), – рассматриваются как ресурсы и разделяются между владельцами – программами/задачами.
- Все взаимодействия между задачами осуществляются исключительно посредством запросов и предоставлением услуг (сервисов).
Напоминает обычную модель клиент-сервер? Да, но есть еще третий принцип, в котором и состоит основное различие с данной моделью —
- «Овеществление» сервисов. А именно, сервис в ROS модели – это не просто функциональность или интерфейс для обмена данными, предоставляемые объектом, а новая коммуникационная и синхронизационная сущность – объект.
Назовем экземпляры этих объектов «каналами». Канал – это разделяемый объект, содержащий как код, так и данные и предназначенный для передачи данных и управления между задачами. Заметьте, что здесь намеренно отсутствует разграничение на провайдера и потребителя услуг (то есть, сервер и клиент), так как каждая задача может и предоставлять, и потреблять определенный набор сервисов. Из исключительности каналов как средства взаимодействия задач следует еще одно свойство ROS-модели: коммуникационная синхронизация. Любая передача управления между задачами по определению может осуществляться только в связке с получением\предоставлением услуги, то есть, каналы становятся синхронизационными объектами, однозначно определяющими место и назначение синхронизации задач.
ОС не имеет никакой информации и не делает никаких предположений о предназначении каждого канала. Так что каналы должны предоставлять идентификаторы, однозначно определяющие тип, цель или иную информацию, необходимую для конкретного взаимодействия.
Для обеспечения исполнения задач система создает для каждой задачи специальный системный канал.
Дизайн ОС включает в себя два вида каналов: дуальные и мульти. Как видно из названия, у первых число присоединенных задач не может превышать 2, а у последних ограничения по количеству подключенных задач отсутствуют (определяются исключительно объемом доступной памяти и особенностями конкретной реализации ОС). Каждый канал имеет два «противоположных» конца. Задачи, присоединенные к ним, называются экспортерами и импортерами канала, соответственно. Разница между этими двумя типами задач несущественна – оба должны создать экземпляр канала, то есть, выделить память и таким образом поместить канал в свое адресное пространство. Единственная цель разделения на экспортеров и импортеров – поддержка задач с традиционной семантикой клиент-сервер, т.е. производитель и потребитель услуг.
На рисунке ниже представлена принципиальная схема ROS OS:
Все крайне просто. Серо-голубым цветом помечены физические компоненты системы – процессоры (CPU), память (memory). Dev (Device) – это физическое устройство хранения данных.
Ядро ОС владеет ресурсами процессоров и памяти. Остальными ресурсами системы могут владеть привилегированные задачи (P-task), предоставляющие в свою очередь сервисы задачам пользовательского уровня (U-task) посредством коммуникационных каналов (channel).
ROS OS реализует: Менеджер Памяти (ME-M), Менеджер Каналов (CH-M), Менеджер Системных Каналов (SC-M), Менеджер Задач (TA-M), и Диспетчер Задач (TA-D). Ядро идентифицирует задачи и запросы на сервисы посредством системных каналов (syschan).
Управление задачами
?Скоординированное вытеснение (cooperative preemption)
В отличие от Windows и Linux, которые сохраняют контекст задач при их переключении, потребляя при этом значительное количество памяти на размещение стека, а также теряя производительность на инструкциях сохранения регистров, предлагаемая OS дает возможность каждой задаче сообщить ядру, что сохранять ее контекст не требуется.
Вместо этого, задачи предоставляют окружение исполнения, состоящее из четырех указателей в форме {func(chan, sys, loc)}, так что ядро может очистить стек задачи, а затем, непосредственно перед активацией, выделить задаче новый (или предоставить существующий пустой) стек, после чего позвать функцию func с данными параметрами. При этом, значения остальных, не используемых в передаче этого окружения регистров остаются неопределенными или обнуляются, что быстрее сохранения\восстановления корректного значения.
Непосредственно перед активацией задачи система очищает окружение из 4-ех указателей, чтобы исключить ошибочное преждевременное вытеснение задачи.
Заметим, что скоординированное вытеснение (при условии, что все задачи в системе ему следуют) означает, что при идеальных условиях исполнения для каждого ядра CPU будет существовать только один стек. Дополнительные стеки будут выделяться, только если задача будет вытеснена преждевременно, перед тем, как она инициализирует контекст из 4-ех указателей.
?Модель передачи управления для потоков (Yield-To)
Дизайн ОС не предполагает явных функций ожидания (wait) или взаимного исключения для потоков. Вместо этого межпотоковая синхронизация достигается явной передачей управления другим задачам, идентифицируемым при помощи указателя на канал и номера задачи в канале. То есть, управление передается не конкретной задаче, а любому агенту, который предоставляет соответствующий сервис и проиндексирован в своем сервисном канале. При этом, за конкретную эффективную внутреннюю реализацию протокола для синхронизации отвечают сами коммуникационные агенты.
Операционная система может поддерживать множественные стратегии передачи управления задачами, такие как «уступить любой», «уступить заданной» и «разрешить исполнение заданной». Последняя стратегия подразумевает, что уступающая задача не намеревается отдавать контроль на «своем» CPU, так что новая задача должна быть активирована в параллель с текущей на другом CPU.
?Детерминированное планирование задач
Каждая задача активируется системным таймером (как и в существующих ОС), но, с учетом применимости ROS OS к системам реального времени, каждая задача должна задать требования к планировщику задач в виде двух параметров: частоты и продолжительности активации. Помимо своего основного назначения, эти параметры используются для оценки предполагаемой загрузки системы, количества ожидаемых конфликтов задач и выделения в соответствии с этим необходимых ресурсов (тех же стеков)
В идеале, суммарная продолжительность активаций всех задач должна быть меньше или равна минимальному заданному периоду активации, а периоды должны быть кратны минимальному. Выполнение этих условий будет гарантировать отсутствие конфликтов планировки.
Но в нашем несовершенном мире некоторые задачи могут превысить свою заявленную продолжительность, в таком случае они могут быть вытеснены другими, готовыми к исполнению задачами и помещены в список «на будущее исполнение» в ближайшие свободные слоты.
?Производительность
Так как в ROS модели может существовать несколько провайдеров одного и того же сервиса (по сети или даже локально), единственным критерием выбора между различными провайдерами будет их производительность в данных конкретных условиях.
Для управления производительностью программ системный канал имеет счетчики-таймеры активного времени и времени ожидания, предоставляющие информацию о состоянии текущей задачи. Так как обычно известно, какой задаче (каналу) было передано управление, производительность может быть оценена просто по значению соответствующего таймера по возвращении в вызывающую задачу.
Сравнив производительности нескольких каналов, задача может переключиться на использование более быстрых из них, что может оказаться особенно полезным в условиях динамической адаптации к меняющимся условиям (обширные сети, физически нестабильные окружения и т.д.).
?Упрощение структуры кода
Поскольку каналы представляют собой динамические структуры данных, разделяемые между адресными пространствами задач и подверженные возможным перемещениям в памяти ядром ОС, код каналов, да и задач в общем случае должен быть написан так, чтобы не зависеть от статичного положения данных в памяти (или располагать их относительно вызывающего кода) и позиции самого кода. Отсутствие статичных структур, независимость от позиции и контекст из 4-ех указателей позволяют обойтись без сложных заголовков программ и определяет следующую простейшую структуру программы:
Каждая программа представляется в памяти в виде двух частей: кода и данных (с опциональным разграничением между ними для обеспечения защиты доступа). Начало куска кода – это стартовая функция задачи, принимающая на вход три указателя, как описано выше.
?Создание и структура задач
Задача может быть создана из любого фрагмента кода. Адрес начала кода будет являться адресом стартовой функции задачи – той самой, с прототипом четырех указателей – func(chan, sys, loc), где chan и loc – опциональные (так, loc – может указывать на локальные данные), а sys – указывает на созданный для задачи системный канал. Заметим, что код задачи копируется на новое место в памяти для упрощения дальнейших операций с каналами – например, если часть кода будет экспортирована в качестве канала.
Внутренняя структура задач выглядит так:
Каждая задача содержит дескриптор, описывающий ее тип (type) – пользовательский или привилегированный, а также указатели на: таблицы страниц адресного пространства (address space), локальную память (heap), стек (stack) и обработчик исключений (exception handler).
Помимо этого, дескриптор задачи включает список отображенных каналов – (task2chan), т.е. список пар: «индекс-дескриптор канала, указатель на код данного канала».
В случае, когда задачи разделяют общее адресное пространство, указатели каналов могут пропускаться с целью оптимизации использования памяти.
Первый элемент списка отображенных каналов – это всегда системный канал задачи. Он хранит контекст исполнения и другие свойства, как описано дальше.
?Диспетчеризация задач
Дизайн ОС предусматривает два типа активации задач: (а) по системному таймеру согласно запрашиваемому расписанию и (б) по явной передаче управления из другой задачи.
Расписание активации может быть запрошено в виде периода и продолжительности активации. Эти два параметра определяют следующую диаграмму состояния задачи
Граф изменения состояния задач.
Изначально, при активации задачи, она входит в защищенное (active-protected) состояние, то есть, она не подлежит вытеснению. После того, как задача превышает заявленную продолжительность, защита от вытеснения снимается. В случае, когда в листе готовых к исполнению задач (ready list) есть другая задача, система может вытеснить первую задачу, поместить ее дескриптор в ready list и активировать другую задачу. Вновь активированная задача возобновляет исполнение либо в активном состоянии (если она была вытеснена ранее), либо в защищенном состоянии (в случае запланированного исполнения или вообще для всех задач, в зависимости от конкретной реализации)
Важный момент: задание расписания исполнения на основе периода позволяет ядру системы гарантировать задачам реального времени определенную частоту активации, а не предельный срок ее начала. Таким образом, система может сдвигать задачи во времени, если это не нарушает частоту активации. Задание продолжительности позволяет избежать проблем, связанных с приоритетом задач, посредством определения для них предварительно запланированного (запрошенного) отношения активности/ожидания. Конкретные реализации ОС могут ограничить продолжительность максимальной длиной кванта времени, чтобы «жадные» задачи не занимали процессор бесконечно. Все вышесказанное упрощает схему планировщика и обеспечивает его быстрое функционирование.
Планировка на основе заданных периода и продолжительности активации позволяет планировщику определять неизбежные конфликты (см. рисунок ниже) и либо отклонять запрос на активацию, либо смягчать требования планировки реального времени.
Помимо вытесняющей многозадачности, система поддерживает и кооперативную. Явная передача управления может осуществляться с помощью специального системного метода yield(). Вызов этого метода приведет к передаче управления задаче, идентифицируемой при помощи указателя на канал и номера задачи в нем, и исполнению данной задачи на заданном процессоре. Также, как было сказано выше, возможно передать управление не конкретной задаче, а любому агенту, который предоставляет соответствующий сервис и проиндексирован в своем сервисном канале.
Каждый конфликт планировки (включая динамический, когда задачу вытесняют по превышению продолжительности исполнения) в общем случае приводит к выделению ядром ОС дополнительных ресурсов – нового стека для активированной задачи. Поэтому для оптимального использования системных ресурсов каждая задача может сообщить ядру ОС, что она не нуждается в сохранении регистров и данных стека. В этом случае ОС при вызове yield() может освободить стек задачи и сбросить содержимое регистров. При активации такой задачи система вызовет прототип {func(chan, sys, loc)} на пустом стеке и неопределенном содержании регистров.
Для обеспечения запланированной или вытесняющей активации задачи диспетчер задач поддерживает список готовых к выполнению задач. Это – кольцевой буфер, содержащий индексы-дескрипторы (или указатели) задач и запланированное время активации, как показано на рисунке ниже. Для вытесненных задач это время будет, конечно, нулевым.
Время может выражаться в абсолютных или относительных единицах (по отношению к максимальному периоду), и обновляться в соответствии с запрошенными периодами активации. Когда задача вытесняется или уступает контроль, ее дескриптор помещается в первый свободный слот кольцевого буфера. Отметим, что так как список упорядочен по времени, задача может быть вставлена в список перед другими, если крайний срок ее активации наступает раньше.
Готовые к исполнению задачи могут выбираться из листа, начиная с конца (хвоста) или с указателей на листы задач (task list pointers), содержащихся в Блоках управления процессорами, которые описаны ниже.
Накладные расходы планировки задач разделяются на статические и динамические. Первые – это постоянное время инициализации процессорного контекста задачи (напомним, что именно это время уменьшает кооперативная многозадачность), а вторые – накладные расходы самого диспетчера задач, пропорциональные количеству операций поиска в листе готовности задач (как для поиска текущей готовой к исполнению задачи, так и для вставки новой). При этом, нет необходимости поиска задачи для активации, так как она всегда будет находиться в «хвосте» списка.
Накладные расходы на вставку задач будут минимальными, если все задачи запросили периоды активации одинаковой продолжительности. Если же периоды разные, то поиск займет логарифмическое число операций, так как лист готовности включает набор следующих друг за другом, по большей мере, сортированных данных, а несортированные элементы могут быть найдены по цепочке ссылок.
?Управление каналами
Каждому каналу в системе присваивается дескриптор, который хранит информацию о топологии канала (type), его идентификатор (guid), а также указатели: на тело канала (body pointer) в общем адресном пространстве, где размещены все каналы; и на дескрипторы задач (chan2task), которые присоединены к данному каналу. То есть, система хранит таблицу дескрипторов каналов, показанную на рисунке ниже:
Обратные ссылки каналов на задачи необходимы для идентификации задач посредством указателя на канал и внутриканального индекса (для передачи управления между задачами). В этой схеме внутриканальный индекс – это позиция дескриптора задачи (task descidx) в соответствующем листе chan2task.
?Системные вызовы и управление контекстом
Системные каналы – это комплекс средств для идентификации задач, сохранения их контекста, получения системной информации, генерации системных вызовов и передачи управления другим задачам.
На рисунке ниже показана структура системного канала.
Как видно, аргументы системных вызовов не передаются через стек или регистры, а копируются в соответствующие структуры системного канала.
В системном канале размещается информация о свойствах и возможностях компьютерной платформы, позволяя ее использование без дополнительных накладных расходов на системный вызов.
Комбинация в одном канале четырех-указательного окружения исполнения и контекста исполнения может быть удобной для целей удаленной отладки\мониторинга.
Информация о хронометраже каждой задачи обновляется ядром ОС в реальном времени. Наличие полей, относящихся к каждому процессору системы, позволяет параллельную активацию задач (идентификация задач происходит на основе таблицы дескриптора канала).
Конкретные реализации системы могут выделить один регистр (доступный для чтения непривилегированным задачам – например, при наличии поддержки в железе, сегментный регистр) для хранения постоянного указателя на текущий системный канал задачи. В этом случае задачам не требуется сохранять указатель на системный канал, вместо этого они могут ссылаться на него через соответствующий макрос.
Системный канал должен обязательно поддерживать следующие функции, которые, фактически, будут являться системным API:
//(1) Создание новой задачи из заданной функции func указанного размера, типа и аргументов; возвращает статус {ok, err};
int exec(func, size, type, arg0, arg1);
//(2) Передача упpавления задаче, присоединенной к указанному каналу под заданным индексом subidx; либо любой готовой задаче. Вариант без аргументов предназначен для задания конкретного процессора для исполнения задачи (вызову предшествует заполнение соответствующих полей системного канала); возвращает статус {ok, err};
int yield(chan, subidx, strategy);
int yield();
//(3) Уничтожение вызывающей данную функцию задачи;
void exit();
//(4) Выделение буфера памяти заданного размера и типа. Возвращает указатель на выделенный буфер
void* malloc(size, type);
//(5) Освобождение буфера памяти, заданного указателем-аргументом; возвращает статус {ok, err};
int free(pointer);
//(6)Экспорт канала заданного ID (guid) и топологии (type) по заданному адресу. Возвращает новый адрес канала.
void* export(pointer, guid, type);
//(7) Импорт канала заданного ID (guid) и топологии (type) по заданному адресу. Возвращает новый адрес канала.
void* import(pointer, guid, type);
//(8) Отключение задачи от данного канала; возвращает статус {ok, err, channel_destroyed};
int disconnect(pointer);
//(9) Получение индекса задачи в заданном канале; искомый индекс – возвращаемое значение функции.
int self(pointer);
То есть, весь системный API состоит менее, чем из 10 функций!!
?Управление процессорами
Каждому процессору в системе присваивается Блок Управления Процессором, который содержит некоторые свойства текущей выполняемой задачи, как показано на рисунке ниже.
Также в соответствие процессору ставятся некоторые другие управляющие таблицы – прерываний (включая межпроцессорные) и таблица системных дескрипторов.
Уровни сложности системы
Сложность определенной реализации системы может зависеть от доступного объема памяти, процессорных возможностей и производительности конкретной платформы. Ниже описаны возможности регулировки сложности ядра ОС.
?Реализация управления каналами
Каналы, являясь основой дизайна ОС, допускают значительную вариативность. Например, разработчики ОС могут выбрать поддержку исключительно дуальных каналов, исключая таким образом необходимость динамического выделения списков членов каналов. Кроме того, система может не поддерживать каналы с кодом (или, по крайней мере, смешанные каналы для кода и данных), вследствие чего упрощается использование традиционных компиляторов и сред разработки, так как пропадает необходимость агрегирования кода и данных.
Каналы могут идентифицироваться уникальными 128-битными идентификаторами либо определенными индексами, валидность которых может контролироваться локальной (масштаба системы или сети) или глобальной службой.
Еще одна возможность – присвоение каналам имен, образованных в виде иерархических путей, подобных системным файловым путям существующих ОС.
?Реализация управления задачами
Так же, как и в современных ОС, предлагаемый дизайн операционной системы подразумевает возможность реализации задач как в форме процессов, так и в форме потоков, то есть, задачи могут быть как изолированными (логически и физически, если это позволяют возможности процессорной системы), так и разделять одно адресное пространство, а значит, и передавать данные через разделяемые переменные.
Еще одна возможная, но очень важная особенность реализации – это уровень привилегий задач, то есть, доступность задачам определенных системных и процессорных ресурсов (например, межпроцессорных прерываний, таблиц дескрипторов процессоров, входных-выходных портов).
Возможное решение – это поддержка исключительно привилегированных задач, что приведет к экономии усилий по реализации изоляции задач, защите памяти и процессорных ресурсов.
Если же поддерживаются как привилегированные, так и непривилегированные задачи, дизайн ОС предусматривает две возможности для реализации привилегированных операций.
В первом случае, все привилегированные операции могут исполняться только ядром, то есть, все привилегированные программы становятся частью ядра ОС и исполняются в его контексте (или контексте запрашивающей стороны). Назовем это «общей схемой». Достоинства этого подхода – обслуживание привилегированных операций может не требовать переключения контекста задач (операции выполняются в контексте запрашивающей стороны) в случае, когда адресное пространство ядра ОС отображается на адресное пространство каждой задачи. Кроме того, так как системное ядро всегда распараллелено по числу процессоров системы, параллельные задачи, запрашивающие привилегированные операции, не будут простаивать даже при отсутствии возможности исполнения их контекста. Недостаток – запрашивающая задача не сможет продолжить исполнение до тех пор, пока запрос не будет обработан.
Во втором случае все привилегированные задачи могут быть отделены от ядра («раздельная схема»).
Это решает проблему параллельного исполнения запрашивающих и выполняющих запросы задач, но вносит дополнительное переключение контекста по каждому запросу и получению прерывания (так как прерывания, принадлежащие привилегированным задачам, могут произойти во время исполнения любой другой задачи).
Поэтому полезным решением может стать объединение общей и раздельной схем. По умолчанию, все привилегированные операции могут быть выполнены от лица запрашивающих их задач (как часть ядра), но, по мере необходимости, могут создавать другие привилегированные задачи, исполняемые отдельно, и передать им управление и данные с помощью каналов.
Для реализации комбинированного подхода может потребоваться дополнительное расширение к вышеописанной функциональности ядра – системный вызов, соединяющий вектор прерываний и его обработчик – сервисную функцию, вызываемую ядром системы при передаче управления привилегированному каналу, владелец которого – часть ядра, а не отдельная задача.
//(10) Связь вектора прерываний с его обработчиком., функция возвращает статус {ok, err}
int connect(int vector, void* handler);
При вызове этой функции система проверяет привилегии инициатора запроса и текущий индекс задачи. Ядро ОС гарантирует при получении каждого прерывания из указанного вектора переключение контекста на привилегированную задачу – инициатора запроса. Нулевой параметр handler удаляет предварительно установленный обработчик прерываний.
Дескриптор канала в этом случае будет содержать функцию- обработчик прерываний.
Примеры коммуникаций посредством каналов
?Дуальные каналы
Простейшая модель коммуникации задач – это дуальные каналы. Они гарантируют обслуживание только двух коммуницирующих агентов, хотя каждый из них может соединяться с более чем одним каналом того же ID. То есть, и один провайдер сервиса может предоставлять его нескольким клиентам (каждому – в отдельном канале), и один потребитель получать одну и ту же услугу от разных поставщиков.
Дуальные каналы являются эффективным средством передачи данных в случае, когда присоединенные к ним агенты копируют свои данные в разделяемое внутриканальное хранилище и извещают друг друга о завершении операции копирования\обработки данных (так что ожидающие агенты не тратят попусту вычислительные ресурсы).
Дуальные каналы кода практически эквивалентны каналам с данными, единственное отличие – они предоставляют разделяемый интерфейс, который инкапсулирует операции обработки и передачи данных, что может оказаться более удобным в некоторых случаях объектно-ориентированного дизайна. В этом случае операции передачи управления могут осуществляться внутриканальным кодом по поручению текущей задачи.
Здесь и на последующих рисунках U-Task означает пользовтельскую задачу.
?Мульти-каналы
Мульти-каналы могут использоваться для обеспечения вычислительного сервиса – то есть, для разделения кода между несколькими задачами (подобно динамическим библиотекам во многих традиционных ОС).
Разделяемый код при этом необязательно должен поддерживаться своей задачей-экспортером.
Задача может первоначально экспортировать канал и завершиться, а внутриканальный код при импорте разместит локальные данные в адресном пространстве импортирующей задачи и, таким образом, будет являться как полностью интегрированным с импортером, так и изолированным от других импортеров (для случаев, когда конкретная реализация ОС поддерживает изоляцию адресных пространств).
Ниже обсуждаются более сложные случаи мульти-канальных конфигураций.
?Пулы задач
Предназначение пулов задач – поддержка синхронизационных моделей, традиционно используемых в симметричной многопроцессорности (SMP). Каналы данных, к которым присоединены несколько задач, могут быть как контейнером для разделяемых (обрабатываемых параллельно) данных, так и служить средством синхронизации, то есть, включать в себя счетчик числа задач-пользователей канала и, опционально, их индексов в канале.
Пулы задач могут использовать возможности планировки задач ОС и обеспечивать эффективную синхронизацию параллельных задач – в противоположность наиболее примитивным схемам опроса каналов для синхронизации.
Экспортер канала может взять на себя обязанности распределения работы и, так как количество процессоров и распределяемых задач известно, экспортер может передать управление определенным задачам на определенных ЦПУ. Когда задачи-исполнители завершат обработку данных, они могут вернуть управление распределяющей работу задаче.
?Пулы запросов
Пулы запросов могут оказаться эффективными в условиях, когда создание отдельного канала для каждого клиента потребовало бы значительных затрат памяти – при разделении больших буферов памяти и\или обслуживании большого числа клиентов.
Эти пулы обеспечивают интерфейсы, которые можно назвать арбитражными. Победитель арбитража может поместить запрос (передать данные), а другие инициаторы запросов могут быть переключены в неактивное состояние (прозрачным образом – с использованием внутриканального кода). Когда обслуживание победителя арбитража завершается, победитель извещается об этом, копирует свои выходные данные, и арбитражный процесс возобновляется – из остальных участников арбитража выбирается победитель, пробуждается операцией yield, и процесс полностью повторяется.
?Маркеры доступа
Маркеры доступа (Access tokens) позволяют реализовать модель разделения данных (и\или получения одинакового обслуживания ) между несколькими задачами без установки каналов передачи данных. Вместо этого, единственный провайдер сервисов управляет всеми ресурсами или обеспечивает сервисы всем активным агентам в системе. Каждый агент может запросить у него маркер доступа, который и будет являться ключом к разделяемым данным. Затем агенты могут «поделиться» маркером с другими доверенными агентами (посредством специального канала обмена), в результате чего доверенные агенты смогут получить тот же самый тип обслуживания или доступа к данным.
?Параллельный доступ к устройствам
Прежде чем говорить о работе с физическими устройствами, заметим, что драйвера в ROS OS – это не особые выделенные сущности, а обычные привилегированные задачи, предоставляющие свои сервисы посредством каналов.
Во многих случаях необходимо обеспечить нескольким задачам одновременный доступ к потокам данных, производимым или потребляемым физическим устройством. На рисунке ниже показаны 2 типичных примера параллельной коммуникации с устройством.
Первый будет эффективным, если ядро ОС различает процессы и потоки. В этом случае специальная задача может обрабатывать все операции с устройством и буферизовать входящие\исходящие потоки данных, в то время как фактическое обслуживание задач-потребителей данных будет производиться потоками, имеющими полный доступ ко внутренним буферам и, соответственно, возможности проверить наличие данных и избежать ненужных задержек. На рисунке данная схема показана слева.
Второй вариант реализации может быть использован в случае пакетной обработки данных. В этом случае обслуживающая задача, непосредственно взаимодействующая с устройством, может выделить необходимые буфера в экспортируемых ей каналах (так как размер пакета известен и ограничен – так же, как и размер буферов). Обе стороны, подключенные к каналам, будут сообщать о готовности данных друг для друга – так, что обслуживающая задача сможет по получении одного запроса безотносительно от того, откуда он получен, обслужить все каналы, таким образом облегчая реализацию параллелизма в системе. Эту схему иллюстрирует правая сторона рисунка.
?Удаленное использование каналов
В соответствии с дизайном ОC – независимостью работы с компонентами от их расположения, каждый агент в локальной системе может соединиться с каналом, экспортируемым удаленно. Для поддержки этого механизма в систему вводятся так называемые репликаторы каналов, которые помимо поддержки обычной функциональности экспорта\импорта каналов опрашивают свои локальные системы на предмет имеющихся каналов, проверяют наличие сетевых запросов на эти каналы, и, при их наличии, поддерживают пары (наборы) удаленно синхронизированных каналов максимально прозрачным образом для удаленных клиентов этих каналов. Иллюстрация описанному механизму – ниже.
Здесь и на последующих рисунках P-Task означает пользовтельскую задачу.
Отметим, что для эффективной поддержки удаленных репликаторов каналов необходим дополнительный системный вызов
//(11)запрос имеющихся каналов; Функция возвращает длину массива каналов или ошибку.
int query(guid[], size[], type[]);
Здесь guid[] – массив индексов каналов, size[]предоставляет размеры каналов, а type[] содержит типы\топологию запроса канала (импортированный, экспортированный или мульти).
?Поддержка со стороны языков программирования
Существующие языки программирования потребуют небольшого расширения для поддержки ROS модели и облегчения разработки для предлагаемой ОС. В случае C++, расширение, затрагивающее семантику языка, это модификатор типа – “channel”, показывающий тип содержимого, которое должно быть объединено в форму, пригодную для межпроцессной коммуникации. Оставшиеся проблемы, связанные с канальной коммуникацией, решаются с использованием функций ROS OS API, как показано ниже.
// объявление
channel class A // новый модификатор типа
{
int x;
virtual void f();
void g();
} *a, *b, *c, *d;
//системный канал для вызова системных функций
syschan_t* sys;
bool multi = false; // или true для мультиканалов
// выделение памяти
a = new A; // объединяет x, f, g и vft
b = new A; // выделение пространства для импорта
// служебные функции
c = export(a, sys, multi); // экспортировать канал типа A
if(c != a){ delete a; a = c; } // система переместила канал
d = import(b, sys, multi); // импортировать канал типа A
if(d != b){ delete b; b = d; } // система переместила канал
int i = self(a, sys); // получить свой индекс в канале
disconnect(a, sys); // отсоединить экспортированный канал
disconnect(b, sys); // отсоединить импортированный канал
//OS может освобождать дескрипторы каналов
То есть, сначала требуется объявить тип вашего канала (используя модификатор типа channel), а также выделить стандартным способом области памяти для экспортера и импортера канала. После чего канал, очевидно, должен быть присоединен посредством экспорта с одной стороны и импорта с другой. Для этого используются специальные функции export() и import(), в которые передаются указатели на ваш канал, системный канал и указывается вид канала (мульти или дуальный).
Проверки указателей, приведенные после вызовов этих функций, приведены здесь для сред с разделяемым адресным пространством, где существует вероятность, что ядро ОС передвинет тело канала в памяти с выделенного ранее места.
Каждые агент, подсоединенный к каналу, имеет свой внутриканальный индекс, получаемый функцией self(), который остается неизменным де тех пор, пока агент не отключится от канала (вызовом disconnect()) и не присоединится к нему снова (посредством import() и export()). Остальные связанные с каналами функции в соответствии с дизайном ОС рекомендуется определить так, чтобы они принимали указатель на ваш канал, текущий системный канал, а также указатель на локальное хранилище данных или опциональный параметр.
Ниже приведен прототип функции chanfunc, которая может являться как функцией запуска задачи с семантикой (arg0, sys, arg1), так и функцией инициализации канала (которая выделит локальное хранилище данных и вернет его указатель loc), либо вообще любой служебной внутриканальной функцией
/// sys – Указатель на системный канал
/// chan – указатель на сам канал
/// loc – указатель на локальные данные или опциональный параметр
void* chanfunc(chan, sys, loc);
?Генерация кода
При написании программ для ROS ОС с использованием существующих компиляторов, предназначенных для других ОС, надо соблюдать осторожность. Так, разработчик должен позаботиться о неиспользовании статических переменных и работать только с автоматически (стек) и динамически выделяемыми данными и/или пользоваться возможностями некоторых компиляторов по генерации кода, не зависящего от адреса загрузки. В идеале специальный компилятор для данной ОС должен быть способен обнаружить ссылки на статические данные и сгенерировать вычисление соответствующего адреса в памяти относительно к адресу использующей эти данные функции.
Еще одна проблема, которая не может быть решена традиционными компиляторами (кроме ассемблера) – это поддержание комбинированных каналов кода и данных. Специализированный компилятор данной ОС должен уметь объединять тела канальных функций и данные в единый монолитный объект, который может быть отображен, передвинут и обработан ОС.
Для процессорных архитектур, поддерживающих защиту исполнения данных, агрегация кода и данных должна проходить на базисе раздельных страниц, чтобы не компрометировать безопасность системы.
Выводы
Основа предлагаемой модели ОС – сервисно-ориентированный подход к параллельному исполнению программ реализует новые принципы передачи управления, планировки задач и управления ресурсами, а также новые логические топологии программной коммуникации и синхронизации, которые удовлетворяют потребности современных параллельных и распределенных компьютерных систем, включая как мощные сервера, так и сети беспроводных сенсоров.
При этом, система продумана с точки зрения связывания вместе железных и программных компонентов компьютерной системы, и максимально проста в реализации.
Многие из описанных принципов дизайна ОС были первоначально воплощены ее автором еще в прошлом веке (1999 году) как часть легковесной ОС, служившей предсказуемой и полностью контролируемой средой тестирования для исполняемых файлов Windows NT. И, конечно же, с тех пор многое было добавлено и улучшено.
Как видите, создать свою ОС на базе описанных принципов возможно. Было бы желание. Если оно у вас есть, то автор идеи, несомненно заинтересованный в ее реализации, с удовольствием вам поможет – проконсультирует и поддержит.
Комментарии (153)
potan
19.05.2016 16:01+7Если уж браться за новую ОС, то почему на старых языках программирования?
Тот же Rust хорошо подходит для операционных систем, да и поддержка каналов в нем есть.
vikky13
19.05.2016 16:05+1потому, что годного софта на них за несколько десятилетий в мире уже много понаписано, да и число годных программистов на них очень велико. Но тут по языковому принципу никого не дискирминируют. Пусть будет и rust, если сможет
burjui
20.05.2016 13:32Пожалуй, для новой, «принципиально новой», ОС наличие уже написанного софта на C или C++ не так критично, т.к. подавляющая часть кода пишется с нуля. За исключением, возможно, действительно сложных подсистем вроде TCP/IP, для которых проще будет адаптировать уже существующий код (Linux, lwIP etc.)
mefest
19.05.2016 17:13+2Почему в подобных постах авторам навязывают свой любимый язык? Я считаю, что причины «автор лучше знает этот язык» вполне достаточно.
potan
19.05.2016 18:16+1Во первых — не любимый. Haskell и ELM мне нравится больше.
Во вторых — потому что он очень хорошо подходит к задаче.kmu1990
20.05.2016 01:58+1Вы писали ОС на Rust, или вы просто кому-то поверили и проверять не стали?
potan
20.05.2016 13:28Я читал описание Rust и участвовал в разработке кода для ядра FreeBSD. Так что представляю, какие проблемы есть и как они могут быть решены.
kmu1990
20.05.2016 13:38+1Я участвовал в разработке ядра Linux и читал описание Rust, но это совершенно не имеет отношения к делу. На основании всего лишь прочитанного описания слишком оптимистично утверждать, что Rust
очень хорошо подходит к задаче
.
roller
19.05.2016 17:01+1А почему ОС новая, а принципы старые? Так новую ОС не построишь.
Можно взять в качестве принципа например «всё ессть ветки дерева», чтобы вся система была гиганстким деревом, начиная от драйверов, и заканчивая каждой буквой на экране.
Или положить в основу функциональный подход — отсуствие состояний.
roboter
19.05.2016 17:04У микрософт была попытка написать на c#.
А так хорошая идея, может нового ничего не изобретут зато поможет избавиться от мохнатого легаси.
daggert
19.05.2016 17:14Это была не попытка, а обычный учебный проект. Microsoft Singularity и не позиционировался как серьезная ОС.
Alex_ME
19.05.2016 19:24+1Вот лично я смотрю на то, что Singularity не дал начало чему-то большему, с огромным сожалением. С тех пор, как первый раз прочитал про нее, мне невероятно понравилась концепция этой ОС. И всякие ОС-эксперименты с новыми (ну как новыми, относительно) подходами считаю только благом — взять тот же Фантом ОС.
daggert
20.05.2016 10:29Я следил в то время за проектом через всякие конференции и блоги, англоязычные. Как я понял — до определенного времени система была очень предсказуема и проста в написании, но по достижении кодовой базы реальных приложений, она просто стала громоздка и неповоротлива.
А нежизнеспособность системы, можно констатировать еще и по тому, что код открыт, а работы нет вообще…Alex_ME
20.05.2016 20:27-1На самом деле при определенной привлекательности систем на управляемом коде и прочих интересных концепциях, у них есть огромный недостаток — в мире существует огромное количество кода на с\с++, а системы вроде Singularity, которая исполняет все в режиме ядра и безопасность осуществляется верификацией нативного кода принципиально (?) не смогут выполнять все то множество нативного кода без утраты безопасности.
dmitriy_novikov
19.05.2016 17:14+4ну а новые нескучные обои-то есть?)
кстати, название ROS для операционной системы уже используетсяvikky13
19.05.2016 17:17+2Обоев, паркетной доски и краски для потолка пока нет.
Я знаю про ROS, но там только одна R значащая, а здесь ROSOS.
eldarmusin
19.05.2016 18:25-1Ну тут только можно посоветовать создать рабочую платформу в виде Гиперлуп Уан, и все желающие могут участвовать.
Scf
19.05.2016 18:47+1Если я правильно понял, канал — это менеджер задач + некая разделяемая память. Если я хочу прочитать из канала, я добавляю в него задачу, передавая параметрами то, что хочу прочитать. Когда данные будут готовы, канал их запишет в разделяемую память канала и вызовет мою задачу. Если я хочу записать в канал, то аналогично — я добавляю задачу, которая пишет в разделяемую память канала. Синхронизация не нужна, т.к. канал использует одно ядро процессора (через соответствующий канал процессора).
Если так, то…
Разве передача всех данных в канал через разделяемую память канала — это не излишество? У пишущей задачи, как правило, уже есть собственный буфер с данными и его придется копировать в память канала.
Зачем нужно различать экспортеров и импортеров?
export/import — нужен для маппинга канала в userspace и для удаленных(remote) каналов? В принципе, никто не мешает работать напрямую с исходным каналом, так?
Зачем каждому каналу собственный менеджер памяти?
Вообще не знаю как насчет операционных систем, но эта идея выглядит интересной для построения сетевых приложений…
vikky13
20.05.2016 00:13Нет, увы, вы поняли неправильно. Менеджер задач — отдельная сущность, так же как и менеджер памяти. а канал -это канал :) данные копироваться не будут, будут отображаться. А насчёт сетевых приложений — да, для них тоже.
Scf
20.05.2016 09:54+2Ну, как автор единственного комментария по теме, я бы хотел получить более развернутый ответ :-)
vikky13
20.05.2016 17:11+1Канал – это и есть разделяемая память в рамках локальной системы, так что задачи ничего лишнего не копируют, а спокойно работают с данными в канале. Неизбежные копирования возникнут только при репликации канала на удаленные системы.
Диспетчер задач не имеет непосредственного отношения к каналам, просто задачи могут легко передавать управление своим контрагентам, чтобы избежать неэффективных (во многих случаях) схем постоянного опроса данных.
Экспорт и импорт – это просто API для установления взаимодействия между задачами: одна задача должна сообщить окружающим, что она готова предоставить какую-то услугу и что эта услуга называется так-то и так-то и физически материализуется в такой-то память такого-то размера, а другая задача отображает эту материализованную услугу к себе в память и начинает общаться с первой.Scf
20.05.2016 17:33Что такое "услуга"? Я думал, что канал — это и есть услуга. Т.е. сам факт существования канала означает, что кто-то предоставляет услугу.
Возьмем, к примеру, канал жесткого диска. Как некой задаче прочитать данные с диска?
- она формирует подзадачу и передает её каналу жесткого диска с параметрами (operation=READ, sector=123456)
- канал (?) или другая задача прикрепленная к каналу? (как тогда она узнает о п.1?) отправляет запрос на контроллер жесткого диска с просьбой прочитать данные в память (в память канала? в память вызывающей таски?) и добавляет таску в канал, владеющий прерываниями.
- когда чтение завершено, вызывается прерывание, которое приводит к вызову таски из канала прерываний, которая вызывает таску из п.1, сигнализируя вызывающему коду об окончании операции.
Так?
vikky13
21.05.2016 17:06+1Попросила ответить автора ОС.
Для чтения с диска:
1. Привилегированная задача, обслуживающая диск, экспортирует некоторый канал. Канал, к примеру, может содержать поля с намером цилиндра, головки, сектора и типом операции, а также место под данные сектора.
2. Задача, желающая прочитать данные, импортирует этот канал, заполняет поля — цилиндр, головка, сектор, чтение — и передает упраление привилегированной задаче (yield-to).
3. Привилегированная задача получает управление, программирует аппаратуру в соответствии с запросом, перехватывает прерывание (запрашивает от ядра системы через системный канал) и «засыпает».
4. По завершении операции чтения аппаратура генерирует прерывание, привилегированная задача получает управление, проверяет данные, если надо — копирует их в канал (если аппаратура не может скопировать данные по адресу канала — например, он располагается слишком высоко в физической памяти), а потом передает управление обратно задаче-клиенту (yield-to).
5. Клиент просыпается — а у него в канале уже лежат данные нужного сектора диска.
Надеюсь, что это понятно (мне — да :) ) Но, если нет, советую написать автору — его контакт в тексте есть.
sviato_divan
19.05.2016 20:57-1Не пугайте рядовых начинающих специалистов названиями типа «ROS», «GOS» и т.д. Первая мысль — новое детище инициатив российских депутатов.
А так спасибо за статью, интересно даже несмотря на объем статьи. )
degs
19.05.2016 22:23А посмотреть на нее где нибудь можно? Код или какой-то рабочий прототип?
Интересно, но непонятно текущее состояние проекта.Nikobraz
20.05.2016 01:12-1Вы не правы, новая ос даст пинка прогрессу операционных систем, не Линукс же единый пару веков мусолить. А wm лучшая когда-либо существовавшая мобильная ос для корпоративного использования.
degs
20.05.2016 01:50Вы это мне? Я просто сказал что выглядит интересно и спросил где можно поближе познакомиться. Я тоже обоими руками за прогресс и новые идеи.
dimatl
19.05.2016 22:33-3Новая ос хорошо, но отсутствие тонны софта под любую задачу делает её такой же нужной как и виндоус мобаил.
perfect_genius
20.05.2016 10:51«Меня не берут на работу, потому что нет опыта. А нет опыта, потому что не берут на работу»
dimatl
20.05.2016 12:15В этом и проблема, задачи решать надо сейчас, а инструменты будут готовы через 10 лет. Все текущие ОС с таким лохматым легаси, но это просто хоть как-то работает. Новое в обозримом будущем только при поддержке больших корпораций и больших денег.
Lauren
19.05.2016 23:58Прежде чем создавать что-то новое, либо вы должны быть первыми, либо нужно найти того, кто откажется от старого.
К сожалению, в IT сфере множество новых технологий, которые значительно лучше старых, но выгода от них разбивается об затраты на внедрение.
funnybanana
20.05.2016 01:20И снова пост скатился до выяснения что лучше: окна или пингвины…
а что касается самого поста, то я почему-то очень скептично настроен… и уж точно на первых этапах будут проблемы с софтом, драйверами, безопасностью… это те шаги — которые не за один год проходят…
mmMike
20.05.2016 08:58OS целиком написанная и развиваемая одним человеком — сомневаюсь в практическом результате.
Да просто по объему кода физически невозможно (я не про ядро и не про «микро» OS дипломных проектов).
В том, что этим можно заниматься — даже не сомневаюсь. Возможно даже идеи заложенные концепциях гениальные.
Но кто этим будет заниматься и проверять/развивать?
Типичный диплом (тема) в НГТУ на соответствующем факультете был (сейчас не знаю): RTOS под какой ни будь контроллер/процессор или разработка ядра процессора с микрокодом.
Естественно учебная и только для демонстрации работы.
В рассуждения о…
Intel закрывает разработку в России. Может быть появившаяся статья с этим связана… или нет…
Grox
20.05.2016 12:18+3OS целиком написанная и развиваемая одним человеком — сомневаюсь в практическом результате.
Linux так начался.
Но кто этим будет заниматься и проверять/развивать?
Энтузиасты, те, кому понравится идея, те, кто хочет иного, и т.д. Кто-то из 7 000 000 000 людей.
orcy
20.05.2016 13:56Не скажу что я прям прочитал и все понял. Похоже на то как я понимаю микроядро (т.е. IPC в виде каналов) + некоторый трюк с тем что хранить контекст можно не всегда. Хотя в данном случае задачи которые используют каналы не обязательно изолированны как в микроядрах.
Наверное если построить аналог десктопной оси, то ядро в своем кернел спейсе будет вот так красиво работать без сохранения контекста, a userspace чаще всего как вытесняющая многозадачность как сейчас. Во встраиваемых или мобильных осях наверное можно попытаться эти канальные прелести вывести на уровень пользовательского API
palexisru
20.05.2016 13:59-1Если трансляторов нет, то могу сразу и идею языка предложить: https://habrahabr.ru/post/219419/
Пока подходит CLR — в связи с наличием управляемой памяти для функционального программирования.
Botchal
20.05.2016 16:27Почитал комментарии… Вы оффтопите! Написано — проект принципиально новой OS, созданный в нерабочее время одним из ведущих сотрудников. В нерабочее, остываем, включаем понимание. Может быть я наивен, и это действительно чей-то диплом… А может и нет! Чувак написал концепцию, отдал в руководство, а руководство сказало, а давайте ка мы напишем обзор в IT-сообщества и посмотрим, что об этом думают люди, которые собственно под эту ось и будут что-то писать. Извините, но половина комментариев это спор о том, какая ось у кого на работе. Уважаемый автор (инициатор) статьи, пишите пожалуйста, что именно Вы хотите узнать, потому что мы не понимаем что от нас требуется. На мой взгляд вы хотите обсудить детали реализации концепции. Явно писать об этом нужно, понимаете о чём я? Я бы хотел задать свой вопрос, если позволите. В операционных системах я не силён и у меня скорее общий вопрос. Вы описали серьёзные теоретические преимущества в плане минимального потребления системных ресурсов и масштабируемости по отношению к мощности железа. Ну клёво, а в цифрах сколько получается? По негативному и позитивному прогнозу, сколько мы сэкономим системных ресурсов по сравнению с Linux, Android, Mac. Было бы здорово если бы Вы показали нам таблицу. Спасибо.
flbrd
20.05.2016 16:27В процессе разработки появятся проблемы с отладкой и тестированием, как мне кажется, так как очень сложно будет отследить цепочку выполнения, когда провайдеры будут перераспределяться и делегировать процессы друг другу, а стек, как я понимаю не будет хранить контекст задачи и информация о цепочки выполнения будет просматриваться только в рамках одной задачи. Поэтому фактор отладки нужно усмотреть изначально.
vikky13
20.05.2016 16:57+1Наоборот, процесс отладки и тестирования упрощается, потому что все взаимодействия конкретной задачи с «внешним миром» известны менеджеру каналов и планировщику задач и могут быть сохранены и представлены задаче-отладчику в виде отдельного канала.
К сожалению, объем статьи не позволяет детально рассмотреть все аспекты ОС, но поверьте на слово, что вопросы отладки, трассирования и измерения производительности рассматривались и учитывались с самого начала. Есть несколько вариантов организации отладки: (1) непосредственное исполнение отлаживаемой задачи в контексте привилегированной задачи-отладчика (так как код любой задачи не зависит от адреса загрузки и от адресов отображения каналов) и (2) расширение системного канала (и, соответственно, ядра ОС), позволяющее получать привилегированным задачам информацию о поведении и производительности других задач, ну а также (3) любые комбинации подходов 1 и 2.
Mixim333
20.05.2016 18:31Разработчик — молодец, но во время чтения у меня образовалось пара вопросов-выводов:
1)если я правильно понял, что подразумевается под «каналами», то чем это ни классическая система использования DLL-библиотек — точно также, нужна нам какая-то «услуга», мы обращаемся к DLL, загружаем ее в память, вызываем функцию\процедуру\метод из этой DLL, получаем результат — бинго?
2)если пункт 1 верен хоть в малейшей доле, то старая «Подмена DLL» (https://rsdn.ru/article/qna/baseserv/hookapi.xml, https://habrahabr.ru/company/eset/blog/102549/) не только остается актуальной, а становится гораздо более опасной — приложение «A» ожидает, что на ПК есть доверенное приложение «B», спокойно обращается к этому приложению, но на его место злоумышленник поставил свое приложение «Bad B» и получил возможность «вертеть» «А» как угодно. Теперь представим, что это какое-нибудь банковское ПО…
Посему, если бы эта ОС даже находилась не на стадии «идеи», а на стадии «вот ISO, установи, попробуй», на реальную машину ставить бы эту ОС я не стал, максимум — виртуалка.vikky13
21.05.2016 00:03+1Спасибо за вопрос.
в частном случае каналов с кодом — да, это очень похоже на dll, об этом есть упоминание в тексте.
И да, если ничего не делать специально — применять ключи, цифровые подписи и прочие механизмы защиты, то вероятность подмены канала есть.
Но никто не мешает: 1) не пользоваться каналами с кодом для важных программ, и 2)ввести механизмы защиты, описанные выше.
В функции ОС вообще не входит защита программ от подобного фишинга, это задача самих приложений. ОС должна уметь защищать себя, и она это умеет.
Jamdaze
20.05.2016 22:39-1Вы привели пример кода на с++, для чего нужен модификатор channel? Десятки лет межпроцессное взаимодействие осуществлялось без модификаторов, а тут он вдруг понадобился?
vikky13
21.05.2016 00:06там же сказано — модификатор нужен для указания компилятору, что код и данные надо объединить вместе.
ahdenchik
22.05.2016 17:181) Разве нельзя никак обойтись без изменений в языках для поддержки передачи кода и данных в одном потоке? Скажем, настройками линкера, чтобы он складывал часть кода в блоке с данными?
2) При передаче кода ведь подразумевается, что везде используется одинаковый тип процессора? Это не так в случае сетей и это осложняет использование разных типов процессоров на одной материнке (мало ли что! менять мир — так уж универсальным образом!)
3) Также очень жалко статические переменные. Опять это требует изменения языков или компиляторов (ключи добавить с запретом статики придётся)vikky13
23.05.2016 12:451)В в принципе можно. Но так
создал богзахотел автор. За подробностями — к нему.
2)Хороший вопрос, спасибо. Но нет. Когда речь идет об удаленном использовании, репликатор каналов прекрасно осуществит бинарную трансляцию.
3) ну это как раз реализуется проще всего.ahdenchik
25.05.2016 20:40-11) «захотел автор» — это не ответ :) (Думал, автор — вы)
2) как? байткод? (очередной?!)
3) избавление от static-переменных? Тогда хранение контекста переезжает в юзерспейс, принципиально никуда не пропадая
Acuna
25.05.2016 01:43К сожалению с фантазией на названия плохо (ибо судя по всему вся она уходит на генерацию идей, что я считаю даже лучше), поэтому годного названия предложить не могу. Однако название ROS OS оставлять нельзя. Я понимаю, аббревиатура расшифровывается очень красиво и несет в себе серьезный мессадж, но ROS не годится никуда. Что же это за Роснано? Уж извините, но в последнее время все эти конвульсии при отказе от всего зарубежного вызывают только тоску и какую-то… Какую-то брезгливость… Просто вырвалось, уж извините… Заранее благодарен за понимание!
DeLuxis
Сейчас писать ОС имеет смысл для наиболее эффективного решения спец задач.
Для выжимания максимума из определенного железа.
В остальном это плюс к саморазвитию или пустая трата времени и денег.
Windows для масс.
Linux, FreeBSD для профессионалов в IT и серверов.
KolibriOS для промышленности.
И еще ряд realtime OS и прочих мелких.
Короче все ниши заняты.
vikky13
Вы правы как никогда. Но, например,… новые ниши появляются — тот же интернет вещей, например.
zona7o
Иннополис на хабре?
artemonster
зачем?.. столько… многоточий в тексте?..
themtrx
NetBSD. Если что, упомянул её за лозунг — «Of course it runs NetBSD».
Apxont
Android/Ios мобильные устройства
darkAlert
пользуюсь OS X на работе. Теперь оказывается я даже не профессионал в IT. Пойду попрошу понизить мне зп :(
И передам еще остальным виндоразработчикам и разработчикам под мультиплатформы, чтоб они также сделали.
Viacheslav01
Кто же тогда я с своим Windows 10? :D
darkAlert
я вижу только один выход — накатить linux и предъявлять это как доказательство своего профессионализма в IT на собеседованиях.
AlexanderG
Или просто накатить и пойти работать на завод.
DeLuxis
Речь идет не о показателе пользователя, а об специфицированности продукта, которым пользуется человек.
В Linux на данный момент наиболее удобно вести разработку ПО, поэтому его предпочитает большинство людей, профессия которых тем или иным способом связана с IT, почему и применил слово «профессионалы», от слова «профессия».
Ваши личные предпочтения, это ваши предпочтения и выбор ОС ни о чем не говорит.
Прошу прощение, если мой комментарий тем или иным образом задел ваше ЧСВ.
Sixshaman
И в чём же заключается невероятное удобство Linux в плане разработки ПО?
DeLuxis
Даже такие элементарные вещи как настройка конфигов и работа с тем же git гораздо удобней.
Можно написать bash скрипты которые автоматизируют очень много рутинных действий. До Win 10 в окнах это было сделать не просто.
Конфигурации серверов будут максимально приближены к продакшену.
Да много мелочей, которых набирается на огромную кучу. Вы только начните работать и через пару лет вас с вашего любимого дистрибутива с руками не оторвешь.
darkAlert
Ну и чем же с git работать удобней из под Linux, вы так и не пояснили. У меня обратное замечание — к примеру, тот же SourceTree не имеет клиента под linux, что не очень удобно.
Свои рутинные действия я решаю при помощи python, опять же мультиплатформерность это очень удобно.
Про конфигурацию сервера совершенно не ясно. Поясните.
И какие еще мелочи то? Работаю с Linux уже много лет, но на домашнем компе как была Windows, так и осталась, на рабочем — как была os x, так и стоит.
DeLuxis
Ну вот, у меня на домашнем стоит тоже Win7, и понятно почему. Так как дома я отдыхаю и редко работаю.
У вас же на работе стоит ОС из семейства UNIX.
Я считаю что спор исчерпан. Если бы вы работали на Windows, то поняли бы меня.
totuin
У меня и дома и на работе Windows. И обоснованно это не личным желанием а необходимостью (хотя линукс я если честно и сам не люблю — но это личное). Куда уж профессиональнее — программирование промышленных контроллеров. Но ни одной среды программирования под линукс ни у одного серьёзного производителя нет. Наверное это чем то обусловлено. Так что всё таки так делить нельзя. Да и панельные промышленные компьютеры в большинстве своем на винде.
dmitriy_novikov
Отсутствие тормозного, глючного SourceTree на линуксе — не такой уж минус, честно сказать…
Даже под виндой есть клиенты, перейдя на которые после SourceTree, вздыхаешь с облегчением.
zagayevskiy
Консоль, например… :-D
gresolio
Кстати SourceTree новые версии 1.8.* очень меня порадовали: шустро работает окно из файлами, которое раньше жутко подвисало. Так что сейчас не всё так плохо. Одно только спорное решение — они все иконки перерисовали в черно-белый стиль. Это бесит и нету настройки чтобы выбрать другие, но ради того что начало шустро работать можно и простить такую xрeнь :)
Для каждой задачи свой инструмент, бывают ситуации когда консоль незаменима, а бывают когда можно и GUI клиент поклацать. SourceTree очень даже достойный клиент по возможностям/удобству, жаль что его нету под линукс.
Zifix
Если нужно собирать что-то из исходников (скажем специфическую библиотеку), работать с зависимостями, то на Linux это делать на порядок проще и приятнее.
creker
Это скорее следствие того, что данная библиотека нормально нигде больше не умеет собираться, а не удобства ОС. А то так можно на линукс жаловаться, что под ним студийный проект не собрать. Нормальные проекты имеют частенько солюшн для студии, который собирает все одной кнопкой. А у других конечно приходится читать и править кривые make файлы, которые даже под cygwin все время ломаются.
Из чисто личных предпочтений, манера требовать рассовывать зависимости в папки ОС, чтобы потом make скрипт их мог найти — вот это настоящий маразм специфики сборки некоторых проектов.
beeruser
Git, Python — это порты, которые с собой тянут кучу всего.
Git даже bash тянет с собой.
В каждой такой программе сидит маленький огрызок линукса разной степени древности и бажности.
Например Program Files/Git/mingw64/
Как если бы из лопаты торчала сосна, потому что не смогли отпилить. Жрите-с что дают.
А под линуксом всё органично вписано. Либы, инклуды всё на своём месте. Апдейт из репозитория и лёгкая интеграция и компиляция всего в пару команд.
В нулевых у меня под виндой стояло, ЕМНИП, 6 комплектов gcc (а-ля mingw) со всеми необходимыми тулзами для разработки под разные платформы =)
PsyHaSTe
Скелеты в шкафу есть у любого более-менее большого и известного софта, что в вин мире, что в линуксовом. Но пока это остается внутренним делом этой софтины — меня это не трогает. Я вот впервые услышал про то, что там эта папка есть. Почему? Да потому что гит просто работает, и у меня ни разу не было необходимости туда лазить. А что они портанули что-то, чтобы не писать с 0 под винду — ну наверное им так лучше показалось. Не думаю, что порт виндовых утилит под линукс с аналогичными зависимостями чем-то отличался бы, скорее сказали бы что-то вроде «под винду уже нормальных разрабов не осталось, даже портировать прогу не могут нормально».
stychos
Да, там таким портов, завёрнутых в вайн, тоже хватает.
daggert
Вы смотрите на портированные программы в винде и ужасаетесь от их зависимостей? Тогда вы поймете меня, когда гребанная программа под мою убунту требует весь KDE и кусочек неизвестных мне библиотек, явно имеющих аналог под gnome окружение. Затем идут свистопляски с их внешним видом, так как после установки они выглядят как окна в windows 95.
Я уж лучше закрою глаза на папку старого порта баша в c:/program files, нежели буду постоянно плакать при запуске libre office.
semmaxim
Что за глупости… Все конфиги пишутся в VisualStudio, TortoiseHg работает прекрасно, вся автоматизация прописана в билд-скриптах и в макросах/аддонах студии, сервера у клиентов MSSQL.
DeLuxis
Это хорошо для тех, кто пишет софт преимущественно на C# или для Windows.
Однако сейчас тенденция ухода ПО в SaaS, где превалирует серверное ПО.
Конечно есть Java, но на Linux можно очень удобно сделать переключение версий JDK. На винде может тоже можно, но лично я даже пытаться не буду, просто поставлю пингвина.
lair
Которого на C# и Windows не бывает?
DeLuxis
Конечно есть, потому и пишу о тех, кто пишет на C#. Только на серверах Linux встречается гораздо чаще. Масштабируемый опять же на нем производится очень просто, легко и быстро. Что очень важно, когда сервис набирает быстро популярность.
lair
Ну так не всех же интересует, что встречается часто, некоторых интересует то, что решает их задачи.
DeLuxis
Да, но статистика говорит о многом. Я же пишу как обстоят в общем и ни кого не хотел задеть.
lair
И как же именно статистика говорит о том, что "В Linux на данный момент наиболее удобно вести разработку ПО"? Не лично вам удобнее, а вообще всем удобнее?
totuin
На корпоративных серверах в большинстве своём все таки винда.
subirdcom
Не соглашусь, если идёт речь о продакшн серверах
darken99
Бывает, но когда руководство видит биллинговый отчет за использование клауда отдельно по Win/*nix то очень быстро принимается решение сменить платформу.
lair
Это с учетом костов на миграцию?
darken99
С учетом всего
lair
Во сколько в среднем "руководству" обходится миграция с C#/Windows-based ERP-системы на *nix-based?
darken99
Я где-то упоминал ERP-систему? Ваши тараканы могут быть намного больше и придирчивей.
У вас вообще может быть технически невозможно либо финансово нецелесообразно это делать.
Но в целом разница в стоимости заставляет, как минимум, задуматься.
lair
Нет, вы написали, что решение о смене платформы принимается по результатам чтения биллинга — безотносительно софта, который на платформе крутится.
А вы говорили — с учетом всего. Хотя финансовая нецелесообразность — это именно ситуация (например), когда косты миграции больше, чем профит от нее.
Разница в стоимости чего, кстати? Если платформы — так для SaaS это как раз не важно, в случае SaaS вам продают готовый продукт, и вам пофиг, на чем он крутится.
darken99
Я не понимаю о чем вы пытаетесь спорить.
Я говорю о том что в случае отсутствия жестких технических ограничений, после получения детализированного отчета по биллингу за использование облака, сразу же возникают мысли рассмотреть возможность смены платформы.
Я видел мало компаний компаний которые не пытаются уменшить OPEX по возможности.
Разница в стоимости виртуальных машин на которых ваш SaaS крутится.
Но это в случае если вы его таки продаете, а не покупаете :)
lair
Я всего лишь указываю, что ваше утверждение
верно не для всякого руководства, а только для конкретных случаев. Ну и да, сравните ваше первоначальное "очень быстро принимается решение сменить" с теперешним "сразу же возникают мысли рассмотреть возможность смены".
darken99
Это как-то влияет на факт того что Windows дороже и при возможности с него пытаются слезть несмотря на ломку?
Не придирайтесь к словам, смотрите на суть
lair
А это факт? "Windows дороже" — возможно. "При возможности с него пытаются слезть" — нет. А уж если речь идет о SaaS, то, повторюсь, то, на чем этот софт написан, для покупателя значения иметь не должно — его волнует только финальная цена. И если какая-то компания может поставлять SaaS, поднятый на винде, и быть конкурентноспособной — значит, это возможно.
(с третьей стороны, я бы на месте этой компании потихоньку слезал с "SaaS, поднятый на винде" на "SaaS, поднятый на PaaS", и не парился вопросами того, винда ли там)
lair
Вот кстати, неожиданный для меня факт. Возьмем амазоновский прайсинг, t2.micro, за час:
Linux $0.013
RHEL $0.073
SLES $0.023
Windows $0.018
Godless
с каким таким сторонним терминалом?
lair
Не очень понимаю, о чем вы.
Godless
Извините, оказалось в мобильном клиенте комментарий ушел очень сильно не туда.
Это было не вам.
potan
Хоть я и линуксоид, но по работе вынужден использовать win7. И надо сказать, что PowerShell оказался приятнее (со сторонним терминалом и пакетом, исправляющим часть глюков тамошнего readline), чем bash. И git из него вполне удобно использовать.
С конфигами и установкой сторонних программ действительно беда. Но это разработчику не каждый день приходится делать.
vintage
А что там за беда с конфигами?
potan
Их нет :-).
Программы настраиваются либо через рестр, либо с помощью GUI. Естественно, нет примеров конфигураций, которые можно посмотреть и исправить под свои нужды, нет комментариев к существующей настройке.
vintage
Реестр — чем не конфиг?
Примеры/документация в линуксовых конфигах тоже не блещют полнотой.
potan
Невозможностью комментировать и использовать любимые системы контроля версий (обычно git) ля управления изменениями.
MacIn
Ну вообще реестр можно экспортировать по частям и загнать в git. Если конфиг делается через стандартные .ini, то вообще никаких отличий и комментарии есть.
Bronx
*.reg файлы вполне себе текстовые и поддерживают комментарии. Импортируются в реестр одной командой. Тот же Far Manager, например, вовсю ими кастомизируется под любые нужды, и поддерживает моментальный перенос конфигурации с машины на машину.
Другое дело, что разрабов чаще волнует удобство обычного юзера, а не админа, поэтому, потрудившись над GUI, о необходимости документировать ключи и значения реестра для админа забывают (или забивают).
potan
Экспорт/импорт в человекочитаемый формат решил бы проблему, если бы сторонние приложения в реестр ни чего бы не писали. А то получается, что я экспортировал реестр, переформатировал, прокомментировал, поместил в git, потом запустил какой-нибудь инсталятор и либо реестр и git разъезжаются, либо всю работу по оформлению придется повторить.
Bronx
Не вполне понятна задача — чего хочется достичь?
Если вы админ, и вам нужно обеспечивать стабильную конфигурацию программ А, B и C на любой машине, то нужно эти программы установить на одной машине, настроить как нужно, экспортировать их настройки из реестра ([HKLM|HKCU]\Software\VendorX\ProgramA\* => ProgramX-Production-[YYYYMMDD].reg, [HKLM|HKCU]\Software\VendorY\ProgramB\* => ProgramY-Production-[YYYYMMDD].reg, etc ) в отдельные REG-файлы для каждой программы, и в последующем просто импортировать эти файлы в реестр на других машинах, грубо переписывая всё, что их инсталлеры понаконфигурировали по-умолчанию.
Если же вы разработчик программы, и вам нужно создать ветку конфигурации в реестре, и при этом вы хотите документировать его и дать админам возможность конфигурировать программу простым импортом нужных REG-файлов, то создайте набор REG-файлов для каждой фичи (FeatureX-On.reg, FeatureX-Off.reg, etc), которая хранит данные в реестре, и напишите там комментариии и возможные значения, точно так же как сделали бы для конфига в *никсах — как это сделано в том же FAR Manager.
potan
Я хочу упростить себе обслуживание своих (и семейных) компьютеров, а так же миграцию с одного на другой.
Сам я серверный разработчик, и в своих программах с виндовыми заморочками мне работать не приходится.
Bronx
Если хочется всё заскриптовать по-максимуму, то:
* DISM для развёртывания компонентов самой винды.
* Chocolatey для развёртывания приложений.
* PS + REG-файлы для миграции конфигураций приложений.
MacIn
Это вырождает изначальный посыл в «под Linux проще разрабатывать на Linux».
creker
Ох эти бездоказательные доводы, что Linux удобнее для разработки. Уже сколько лет со всеми этими UNIX системами имею дело и так и не могу понять, что надо делать, чтобы windows стал менее удобен. Уж все ваши перечисленные задачи решаются идентично во всех ОС нынче. А когда дело доходит до специфики, то она удобнее там, где родное окружение. Поэтому вот эта фраза
Это очень такое ограниченное представление об ИТ. Или может уже для iOS стало удобнее там вести разработку, а то пацаны и не знают, все в xcode пишут.
6opoDuJIo
Чтобы Windows стал менее удобен, используйте eclipse взамен vs
SamVimes
Есть у линукса одно преимущество, которое сейчас довольно актуально — Docker. В винде и оси он пока через виртуалку только (хотя вроде под ось уже есть нативная бета)
AlexanderG
Это, скорее, недостаток докера, который писался специфично под никсы.
sticks
Конечно, не показатель, но вот моя история. Делаю проект для души на D, нужна связка с libpng.
Windows: можно поставить медленный dmd, либо сборку ldc, к которому нужна еще и VS, плюс, выкачать исходники libpng и собрать их с помощью той же VS или MinGW.
Моя домашняя Kubuntu: «sudo apt-get install ldc libpng16-dev» и погнали.
Так что, бывают ситуации, особенно со всякой экзотикой, когда в Linux все проще.
darkAlert
также бывают ситуации, когда проще в винде. К примеру, opencv для винды идет вместе с собранными либами для последних версий mvs. Ни для linux, ни для os x такого в комплекте нет.
kmu1990
Ничего не знаю про opencv, но apt-cache search opencv показал, что что-то подозрительно похожее есть в репозиториях, так что, похоже, поставить его в Ubuntu, по крайней мере, это дело одной команды.
entw
Подключение зависимостей и деплой в виндовсе до сих пор настоящий кошмар. Могу с уверенностью сказать: те, кому никогда в страшных снах не снился деплой под виндовс, ничего по-настоящему под него не разрабатывали. Уж я молчу про сидящие в печёнках апдейты, которые до сих пор не научились устанавливаться в фоне пока ты работаешь. Отдельно отмечу уникальную способность действовать погружённому в раздумья разработчику на нервы шурша и щёлкая жёстким диском. В линуксе всегда полная тишина, если ты сам лично ничего не запустил.
Jump
Чтобы конфигурации серверов были максимально приближены к продакшену запускают и отлаживают код, в виртуальном контейнере, с нужными настройками. Для каждой задачи свой контейнер, и свое окружение.
А разработка при этом ведется и на Windows, и MAC OS, и даже на Linux.
По поводу скриптов и автоматизации рутины — такие инструменты есть под любую популярную ОС.
Если говорить о Windows — повершелл не сказать что намного хуже баша. Ну и пайтон использовать никто не запрещает.
Diverclaim
повершелл не сказать что намного хуже баша
А чем вообще powershell хуже баша?
tamtakoe
Linux используют — потому что Маки дорогие, а так же те, кто ни смог переучить горячие клавиши. OS X Лучшая среда разработки для популярных ЯП в настоящее время.
XAHOK
Сам я хоть и виндузятник, но пришлось поковырять и линукс и OS X. Никогда больше не свяжусь с OS X, кроме как в случае крайней необходимости.
Эта ось слишком много решает за меня. Так что спасибо, но тот же центос мне намного милее, а самой страшной проблемой было найти мануал по vim для работы по ssh.
PS. Про сами маки, как железки, ничего плохого сказать не могу. Тут уж они постарались, но цена явно не соответствует.
PashaPodolsky
1. Показ скрытых файлов и папок включили?
2. sudo edit /usr/…
3. Что за ерунда? AFAIK, апач в стандартную поставку не входит и ставится из MacPorts или HomeBrew, откуда прекрасно обновляется до самых свежих версий без влезания в системную поставку файлов (по-крайней мере в HomeBrew точно). Что нужно было сделать, чтобы прийти к выводу «для обновления апача нужно обновить ось» – ума не приложу.
XAHOK
При первом столкновении в чуть поглубже, от макоси я ожидал поведение, сходное с центосью, однако обломался уже с первых шагов.
3. На леопарде (не помню точно, была эта версия начальной или обновлялись уже до нее) апач уже был предустановлен, как штатное средство, но не сконфигурирован. И обновлялся вместе с осью.
PS. Так что все пункты — это мое имхо. Все таки линукс мне ближе, чем макось, т.к. вел он себя всегда именно так, как я этого от него ожидал.
tamtakoe
Какие-то сугубо админские штуки, вполне возможно проще сделать на Линуксе (потом на iOS, потом, если, вообще, возможно, на Винде). Но я имел в виду наиболее популярные задачи. На Линукс даже Webstorm или IDEA без бубна не поставить, чтобы работал копипаст в русской раскладке, например. Про MySQL, Apache и PHP вы явно загнули. В позапрошлой компании велась разработка на этих технологиях под Маками без проблем.
greendimka
Скажите, а вы всегда обо всех по себе судите? Обоснуйте, пожалуйста, ваше утверждение о том, что в Linux разработку вести удобнее. Удобнее благодаря чему? Благодаря отсутствию современных инструментов разработки. То, что есть, извините — вчерашний день. Открытием это могут называть лишь те, кто ни разу не сталкивался с аналогичными профессиональными инструментами.
Git удобнее? Ну может, может… когда не знаешь, что git под Windows работает так же. Хотя назвать git профессиональным инструментом — язык не поворачивается. Опять таки — открытие для тех, кто source control впервые встречает, ну, или, для тех кто предпочитает целыми днями манулы листать вместо производства, а затем нос задирать — сморите, мол, как я очередной мануал освоил. Впрочем команды разработчиков с огромным удовольствием переходят на TFS, когда показываешь им все преимущества профессионального продукта.
Хотя кому и Лада лучше коня, а кому Мерседес нужен, потому что ценит своё время, имидж, и качество.
lair
Вот это сейчас, конечно, смешно. Во-первых, в TFS есть поддержка git как системы версионирования. Во-вторых, какие же преимущества профессионального продукта есть у TFVC?
greendimka
Это не смешно. У TFS нет поддержки git. У Visual Studio Online — есть. Теперь ответ на ваш вопрос.
Если вы open source проект, то да — git ваше всё, так как pull request'ы именно под open source разработку. На этом преимущества git заканчиваются. Остаётся просто голое складирование изменений в файлах. С кучей проблем. Не будем себе врать, что git удобен. Все мы видели, как члены команды (зачастую профессиональные программисты, а не джуниоры), тратят часы на очередной коммит, потому что где-то что-то пошло не так. Можно это отрицать, можно это принимать. Многие команды не понимают как нормально пользоваться git'ом — в следствие чего он у них чаще всего ни разу не связан с ходом проекта. Просто склад изменений файлов. А когда требуется срочно поднять из системы контроля версий рабочую версию, выяснить какой «коммит» надо откатить, или просмотреть привязку коммитов к проекту — тогда просто начинается фестиваль танцоров с бубном.
Поэтому TFS — ваше всё, если вы руководите несколькими связанными проектами, в которых задействованы разные люди. И если вы понимаете, что успех проекта важнее гордости о того, что пользуетесь git'ом. Потому что TFS тупо не создаёт проблем, а имеющиеся *решает*. Поэтому и переходят на него целые команды, когда им его показываешь.
Честно говоря, я бы вообще запретил называть git системой *контроля версий*. Просто системой складирования изменений.
P.S. есть, конечно же, люди, чувства верующих которых оскорбляет всё, что связано с именем Microsoft (им даже $ мерещится в имени этом) — это отдельная категория. Для них и Microsoft, и многие другие открывают репозитории на GitHub.
lair
Да ладно. А что предлагают выбрать на слайде в туториале? Ну или вот: "In Team Foundation Server 2015 Update 1, a project administrator can add a Git repo to a team project".
Какие-такие пулл-реквесты? В git нет пулл-реквестов.
Не знаю насчет "мы все", я не видел. Зато я видел, как люди мучаются с коммитом в TFVC (а уж как люди мучаются с бранчами в TFVC — это вообще отдельный разговор.
Кстати, а с чем именно мучаются ваши "члены команды"?
Так это проблема образования, а не версионной системы.
А в чем проблема? Нет, вот конкретно — в чем проблема с каждым из этих пунктов?
Вот и началось. В терминах версионной системы все коммиты в одном репозитории привязаны к одному проекту (это верно и в git, и в TFVC). А если вы говорите о привязке коммита к задаче, то в этот момент мы покидаем границы собственно системы управления версиями, и начинаем говорить об ALM-системе.
Стоп-стоп. Поддержка управления проектами — не задача системы управления версиями. Вы точно не путаете VCS- и ALM-системы?
Простой вопрос. Вот у вас есть диапазон в 100 чейнджсетов. Вы знаете, что где-то в этом диапазоне было внесено изменение, сломавшее вашу систему, но не знаете, какое именно. Как именно TFS решает проблему нахождения этого изменения?
Простите, а в чем, по-вашему, разница? Система контроля версий — это именно система "складирования изменений" (если вы, конечно, не путаете систему контроля версия с системой управления релизами).
Фундаментальное достоинство — и одновременно проблема — TFS в том, что это монолит. В нем есть VCS (долгое время безальтернативная и далеко не идеальная), в нем есть управление задачами (среднее, на мой вкус), в нем есть билд-сервер (вот этот мне очень нравился, но мы и в нем постоянно бились головой в проблемы), есть система поддержи тестирования (мы так и не освоили ее), и, насколько я знаю (это было уже после того, как с него слез) добавили систему управления релизами. И все это — интегрировано: чейнджсеты привязываются к воркайтемам, воркайтемы — к билдам, из этой информации можно собрать чейнжлог и/или посмотреть тест-импакт и так далее. Очень круто, да. Пока ты сидишь внутри этого монолита. Как только ты начинаешь заменять его кусочки на что-то другое (например, тебе нужна другая система управления задачами), вся эта интеграция начинает трещать по швам.
Я повторю свой вопрос: какие преимущества "профессионального продукта" есть у TFVC?
greendimka
Я писал «Это не смешно. У TFS нет поддержки git. У Visual Studio Online — есть». Это чтобы не вырывать из контекста.
Ну что я могу сказать на все ваши комментарии. В целом вы не ошибаетесь, но… и не совсем правы. Проблема монолитности решается ликбезом. А в последнее время кучей extension'ов. В целом да — большинство проблем — от незнания. Я работаю на европейском рынке, возможно в России — все в целом умнее (это не сарказм).
В целом скажу так: после перевода команд с git на TFS — продуктивность возрастает. Исчезают проблемы использования source control system. Команды начинают думать о проекте, а не об отдельных коммитах.
Со всем уважением: отвечать по пунктам не стану, т.к. время не резиновое.
lair
Так я вам ссылку даю на on-premise TFS, при чем тут Visual Studio Online?
Как вы можете решить ликбезом проблему "я хочу использовать YouTrack вместо TFS WIM, но сохранить всю интеграцию"?
Вне зависимости от сложности проекта? При какой branching strategy?
Потому что лично мои наблюдения строго противоположны: переход с TFVC на git я воспринял как облегчение (особенно учитывая период в несколько месяцев, пока я пользовался ими параллельно), и эти наблюдения повторяются на многих людях.
Я в таком случае сочту, что вы согласились со всеми моими возражениями — и при этом не смогли указать конкретных преимуществ.
entw
Особенно учитывая, что виндовс не различает регистра в файлах.
greendimka
«Особенно учитывая, что виндовс не различает регистра в файлах» — учите матчасть, а не слухами живите. А вообще за использование имён файлов, различающихся лишь регистром — тимлиды должны бить по рукам, и очень сильно.
vintage
Поясню предыдущего оратора — NTFS/FAT не различает, а не сама Windows.
MacIn
И слава богу. Совсем не упало разрешать ситуации когда «veryImportantFile» не то же что и «VeryImportantFile».
Notimer
Ну, когда-то говорили что и «640 килобайт хватит всем»
greendimka
Вообще-то не говорили. Не поддерживайте ложные слухи.
vadimzz
Вы должны были вовремя сказать это Торвальдсу, пока он не начал