Комментарии 158
НЛО прилетело и опубликовало эту надпись здесь
Вы правы как никогда. Но, например,… новые ниши появляются — тот же интернет вещей, например.
Android/Ios мобильные устройства
пользуюсь OS X на работе. Теперь оказывается я даже не профессионал в IT. Пойду попрошу понизить мне зп :(
И передам еще остальным виндоразработчикам и разработчикам под мультиплатформы, чтоб они также сделали.
И передам еще остальным виндоразработчикам и разработчикам под мультиплатформы, чтоб они также сделали.
Кто же тогда я с своим Windows 10? :D
НЛО прилетело и опубликовало эту надпись здесь
И в чём же заключается невероятное удобство Linux в плане разработки ПО?
НЛО прилетело и опубликовало эту надпись здесь
Ну и чем же с git работать удобней из под Linux, вы так и не пояснили. У меня обратное замечание — к примеру, тот же SourceTree не имеет клиента под linux, что не очень удобно.
Свои рутинные действия я решаю при помощи python, опять же мультиплатформерность это очень удобно.
Про конфигурацию сервера совершенно не ясно. Поясните.
И какие еще мелочи то? Работаю с Linux уже много лет, но на домашнем компе как была Windows, так и осталась, на рабочем — как была os x, так и стоит.
Свои рутинные действия я решаю при помощи python, опять же мультиплатформерность это очень удобно.
Про конфигурацию сервера совершенно не ясно. Поясните.
И какие еще мелочи то? Работаю с Linux уже много лет, но на домашнем компе как была Windows, так и осталась, на рабочем — как была os x, так и стоит.
НЛО прилетело и опубликовало эту надпись здесь
У меня и дома и на работе Windows. И обоснованно это не личным желанием а необходимостью (хотя линукс я если честно и сам не люблю — но это личное). Куда уж профессиональнее — программирование промышленных контроллеров. Но ни одной среды программирования под линукс ни у одного серьёзного производителя нет. Наверное это чем то обусловлено. Так что всё таки так делить нельзя. Да и панельные промышленные компьютеры в большинстве своем на винде.
Отсутствие тормозного, глючного SourceTree на линуксе — не такой уж минус, честно сказать…
Даже под виндой есть клиенты, перейдя на которые после SourceTree, вздыхаешь с облегчением.
Даже под виндой есть клиенты, перейдя на которые после SourceTree, вздыхаешь с облегчением.
Консоль, например… :-D
Кстати SourceTree новые версии 1.8.* очень меня порадовали: шустро работает окно из файлами, которое раньше жутко подвисало. Так что сейчас не всё так плохо. Одно только спорное решение — они все иконки перерисовали в черно-белый стиль. Это бесит и нету настройки чтобы выбрать другие, но ради того что начало шустро работать можно и простить такую xрeнь :)
Для каждой задачи свой инструмент, бывают ситуации когда консоль незаменима, а бывают когда можно и GUI клиент поклацать. SourceTree очень даже достойный клиент по возможностям/удобству, жаль что его нету под линукс.
Для каждой задачи свой инструмент, бывают ситуации когда консоль незаменима, а бывают когда можно и GUI клиент поклацать. SourceTree очень даже достойный клиент по возможностям/удобству, жаль что его нету под линукс.
Если нужно собирать что-то из исходников (скажем специфическую библиотеку), работать с зависимостями, то на Linux это делать на порядок проще и приятнее.
Это скорее следствие того, что данная библиотека нормально нигде больше не умеет собираться, а не удобства ОС. А то так можно на линукс жаловаться, что под ним студийный проект не собрать. Нормальные проекты имеют частенько солюшн для студии, который собирает все одной кнопкой. А у других конечно приходится читать и править кривые make файлы, которые даже под cygwin все время ломаются.
Из чисто личных предпочтений, манера требовать рассовывать зависимости в папки ОС, чтобы потом make скрипт их мог найти — вот это настоящий маразм специфики сборки некоторых проектов.
Из чисто личных предпочтений, манера требовать рассовывать зависимости в папки ОС, чтобы потом make скрипт их мог найти — вот это настоящий маразм специфики сборки некоторых проектов.
Git, Python — это порты, которые с собой тянут кучу всего.
Git даже bash тянет с собой.
В каждой такой программе сидит маленький огрызок линукса разной степени древности и бажности.
Например Program Files/Git/mingw64/
Как если бы из лопаты торчала сосна, потому что не смогли отпилить. Жрите-с что дают.
А под линуксом всё органично вписано. Либы, инклуды всё на своём месте. Апдейт из репозитория и лёгкая интеграция и компиляция всего в пару команд.
В нулевых у меня под виндой стояло, ЕМНИП, 6 комплектов gcc (а-ля mingw) со всеми необходимыми тулзами для разработки под разные платформы =)
Git даже bash тянет с собой.
В каждой такой программе сидит маленький огрызок линукса разной степени древности и бажности.
Например Program Files/Git/mingw64/
Как если бы из лопаты торчала сосна, потому что не смогли отпилить. Жрите-с что дают.
А под линуксом всё органично вписано. Либы, инклуды всё на своём месте. Апдейт из репозитория и лёгкая интеграция и компиляция всего в пару команд.
В нулевых у меня под виндой стояло, ЕМНИП, 6 комплектов gcc (а-ля mingw) со всеми необходимыми тулзами для разработки под разные платформы =)
Скелеты в шкафу есть у любого более-менее большого и известного софта, что в вин мире, что в линуксовом. Но пока это остается внутренним делом этой софтины — меня это не трогает. Я вот впервые услышал про то, что там эта папка есть. Почему? Да потому что гит просто работает, и у меня ни разу не было необходимости туда лазить. А что они портанули что-то, чтобы не писать с 0 под винду — ну наверное им так лучше показалось. Не думаю, что порт виндовых утилит под линукс с аналогичными зависимостями чем-то отличался бы, скорее сказали бы что-то вроде «под винду уже нормальных разрабов не осталось, даже портировать прогу не могут нормально».
Вы смотрите на портированные программы в винде и ужасаетесь от их зависимостей? Тогда вы поймете меня, когда гребанная программа под мою убунту требует весь KDE и кусочек неизвестных мне библиотек, явно имеющих аналог под gnome окружение. Затем идут свистопляски с их внешним видом, так как после установки они выглядят как окна в windows 95.
Я уж лучше закрою глаза на папку старого порта баша в c:/program files, нежели буду постоянно плакать при запуске libre office.
Я уж лучше закрою глаза на папку старого порта баша в c:/program files, нежели буду постоянно плакать при запуске libre office.
Что за глупости… Все конфиги пишутся в VisualStudio, TortoiseHg работает прекрасно, вся автоматизация прописана в билд-скриптах и в макросах/аддонах студии, сервера у клиентов MSSQL.
НЛО прилетело и опубликовало эту надпись здесь
Однако сейчас тенденция ухода ПО в SaaS, где превалирует серверное ПО.
Которого на C# и Windows не бывает?
НЛО прилетело и опубликовало эту надпись здесь
Бывает, но когда руководство видит биллинговый отчет за использование клауда отдельно по Win/*nix то очень быстро принимается решение сменить платформу.
очень быстро принимается решение сменить платформу.
Это с учетом костов на миграцию?
С учетом всего
Во сколько в среднем "руководству" обходится миграция с C#/Windows-based ERP-системы на *nix-based?
Я где-то упоминал ERP-систему? Ваши тараканы могут быть намного больше и придирчивей.
У вас вообще может быть технически невозможно либо финансово нецелесообразно это делать.
Но в целом разница в стоимости заставляет, как минимум, задуматься.
У вас вообще может быть технически невозможно либо финансово нецелесообразно это делать.
Но в целом разница в стоимости заставляет, как минимум, задуматься.
Я где-то упоминал ERP-систему?
Нет, вы написали, что решение о смене платформы принимается по результатам чтения биллинга — безотносительно софта, который на платформе крутится.
У вас вообще может быть технически невозможно либо финансово нецелесообразно это делать.
А вы говорили — с учетом всего. Хотя финансовая нецелесообразность — это именно ситуация (например), когда косты миграции больше, чем профит от нее.
Но в целом разница в стоимости заставляет, как минимум, задуматься.
Разница в стоимости чего, кстати? Если платформы — так для SaaS это как раз не важно, в случае SaaS вам продают готовый продукт, и вам пофиг, на чем он крутится.
Я не понимаю о чем вы пытаетесь спорить.
Я говорю о том что в случае отсутствия жестких технических ограничений, после получения детализированного отчета по биллингу за использование облака, сразу же возникают мысли рассмотреть возможность смены платформы.
Я видел мало компаний компаний которые не пытаются уменшить OPEX по возможности.
Разница в стоимости виртуальных машин на которых ваш SaaS крутится.
Но это в случае если вы его таки продаете, а не покупаете :)
Я говорю о том что в случае отсутствия жестких технических ограничений, после получения детализированного отчета по биллингу за использование облака, сразу же возникают мысли рассмотреть возможность смены платформы.
Я видел мало компаний компаний которые не пытаются уменшить OPEX по возможности.
Разница в стоимости виртуальных машин на которых ваш SaaS крутится.
Но это в случае если вы его таки продаете, а не покупаете :)
Я всего лишь указываю, что ваше утверждение
когда руководство видит биллинговый отчет за использование клауда отдельно по Win/*nix то очень быстро принимается решение сменить платформу.
верно не для всякого руководства, а только для конкретных случаев. Ну и да, сравните ваше первоначальное "очень быстро принимается решение сменить" с теперешним "сразу же возникают мысли рассмотреть возможность смены".
Это как-то влияет на факт того что Windows дороже и при возможности с него пытаются слезть несмотря на ломку?
Не придирайтесь к словам, смотрите на суть
Не придирайтесь к словам, смотрите на суть
Это как-то влияет на факт того что Windows дороже и при возможности с него пытаются слезть несмотря на ломку?
А это факт? "Windows дороже" — возможно. "При возможности с него пытаются слезть" — нет. А уж если речь идет о SaaS, то, повторюсь, то, на чем этот софт написан, для покупателя значения иметь не должно — его волнует только финальная цена. И если какая-то компания может поставлять SaaS, поднятый на винде, и быть конкурентноспособной — значит, это возможно.
(с третьей стороны, я бы на месте этой компании потихоньку слезал с "SaaS, поднятый на винде" на "SaaS, поднятый на PaaS", и не парился вопросами того, винда ли там)
"Windows дороже" — возможно.
Вот кстати, неожиданный для меня факт. Возьмем амазоновский прайсинг, t2.micro, за час:
Linux $0.013
RHEL $0.073
SLES $0.023
Windows $0.018
Хоть я и линуксоид, но по работе вынужден использовать win7. И надо сказать, что PowerShell оказался приятнее (со сторонним терминалом и пакетом, исправляющим часть глюков тамошнего readline), чем bash. И git из него вполне удобно использовать.
С конфигами и установкой сторонних программ действительно беда. Но это разработчику не каждый день приходится делать.
С конфигами и установкой сторонних программ действительно беда. Но это разработчику не каждый день приходится делать.
А что там за беда с конфигами?
Их нет :-).
Программы настраиваются либо через рестр, либо с помощью GUI. Естественно, нет примеров конфигураций, которые можно посмотреть и исправить под свои нужды, нет комментариев к существующей настройке.
Программы настраиваются либо через рестр, либо с помощью GUI. Естественно, нет примеров конфигураций, которые можно посмотреть и исправить под свои нужды, нет комментариев к существующей настройке.
Реестр — чем не конфиг?
Примеры/документация в линуксовых конфигах тоже не блещют полнотой.
Невозможностью комментировать и использовать любимые системы контроля версий (обычно git) ля управления изменениями.
Ну вообще реестр можно экспортировать по частям и загнать в git. Если конфиг делается через стандартные .ini, то вообще никаких отличий и комментарии есть.
*.reg файлы вполне себе текстовые и поддерживают комментарии. Импортируются в реестр одной командой. Тот же Far Manager, например, вовсю ими кастомизируется под любые нужды, и поддерживает моментальный перенос конфигурации с машины на машину.
Другое дело, что разрабов чаще волнует удобство обычного юзера, а не админа, поэтому, потрудившись над GUI, о необходимости документировать ключи и значения реестра для админа забывают (или забивают).
Другое дело, что разрабов чаще волнует удобство обычного юзера, а не админа, поэтому, потрудившись над GUI, о необходимости документировать ключи и значения реестра для админа забывают (или забивают).
Экспорт/импорт в человекочитаемый формат решил бы проблему, если бы сторонние приложения в реестр ни чего бы не писали. А то получается, что я экспортировал реестр, переформатировал, прокомментировал, поместил в git, потом запустил какой-нибудь инсталятор и либо реестр и git разъезжаются, либо всю работу по оформлению придется повторить.
Не вполне понятна задача — чего хочется достичь?
Если вы админ, и вам нужно обеспечивать стабильную конфигурацию программ А, 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.
Если вы админ, и вам нужно обеспечивать стабильную конфигурацию программ А, 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.
Конфигурации серверов будут максимально приближены к продакшену.
Это вырождает изначальный посыл в «под Linux проще разрабатывать на Linux».
Ох эти бездоказательные доводы, что Linux удобнее для разработки. Уже сколько лет со всеми этими UNIX системами имею дело и так и не могу понять, что надо делать, чтобы windows стал менее удобен. Уж все ваши перечисленные задачи решаются идентично во всех ОС нынче. А когда дело доходит до специфики, то она удобнее там, где родное окружение. Поэтому вот эта фраза
Это очень такое ограниченное представление об ИТ. Или может уже для iOS стало удобнее там вести разработку, а то пацаны и не знают, все в xcode пишут.
В Linux на данный момент наиболее удобно вести разработку ПО
Это очень такое ограниченное представление об ИТ. Или может уже для iOS стало удобнее там вести разработку, а то пацаны и не знают, все в xcode пишут.
Чтобы Windows стал менее удобен, используйте eclipse взамен vs
Есть у линукса одно преимущество, которое сейчас довольно актуально — Docker. В винде и оси он пока через виртуалку только (хотя вроде под ось уже есть нативная бета)
Конечно, не показатель, но вот моя история. Делаю проект для души на D, нужна связка с libpng.
Windows: можно поставить медленный dmd, либо сборку ldc, к которому нужна еще и VS, плюс, выкачать исходники libpng и собрать их с помощью той же VS или MinGW.
Моя домашняя Kubuntu: «sudo apt-get install ldc libpng16-dev» и погнали.
Так что, бывают ситуации, особенно со всякой экзотикой, когда в Linux все проще.
Windows: можно поставить медленный dmd, либо сборку ldc, к которому нужна еще и VS, плюс, выкачать исходники libpng и собрать их с помощью той же VS или MinGW.
Моя домашняя Kubuntu: «sudo apt-get install ldc libpng16-dev» и погнали.
Так что, бывают ситуации, особенно со всякой экзотикой, когда в Linux все проще.
Подключение зависимостей и деплой в виндовсе до сих пор настоящий кошмар. Могу с уверенностью сказать: те, кому никогда в страшных снах не снился деплой под виндовс, ничего по-настоящему под него не разрабатывали. Уж я молчу про сидящие в печёнках апдейты, которые до сих пор не научились устанавливаться в фоне пока ты работаешь. Отдельно отмечу уникальную способность действовать погружённому в раздумья разработчику на нервы шурша и щёлкая жёстким диском. В линуксе всегда полная тишина, если ты сам лично ничего не запустил.
Чтобы конфигурации серверов были максимально приближены к продакшену запускают и отлаживают код, в виртуальном контейнере, с нужными настройками. Для каждой задачи свой контейнер, и свое окружение.
А разработка при этом ведется и на Windows, и MAC OS, и даже на Linux.
По поводу скриптов и автоматизации рутины — такие инструменты есть под любую популярную ОС.
Если говорить о Windows — повершелл не сказать что намного хуже баша. Ну и пайтон использовать никто не запрещает.
А разработка при этом ведется и на Windows, и MAC OS, и даже на Linux.
По поводу скриптов и автоматизации рутины — такие инструменты есть под любую популярную ОС.
Если говорить о Windows — повершелл не сказать что намного хуже баша. Ну и пайтон использовать никто не запрещает.
Linux используют — потому что Маки дорогие, а так же те, кто ни смог переучить горячие клавиши. OS X Лучшая среда разработки для популярных ЯП в настоящее время.
Сам я хоть и виндузятник, но пришлось поковырять и линукс и OS X. Никогда больше не свяжусь с OS X, кроме как в случае крайней необходимости.
Эта ось слишком много решает за меня. Так что спасибо, но тот же центос мне намного милее, а самой страшной проблемой было найти мануал по vim для работы по ssh.
PS. Про сами маки, как железки, ничего плохого сказать не могу. Тут уж они постарались, но цена явно не соответствует.
- Только в макоси я видел, что штатный текстовый редактор при сохранении показывает структуру папок от фонаря, а стандартную от корня, в стиле /usr/, открыть не может.
- Только для макоси пришлось гуглить, как отредактировать конфиги MySQL, Apache и PHP, т.к. они требовал рутового доступа, но гребаный редактор не позволял отрыть файл из произвольной папки.
- Только в макоси для обновление апача, нужно обновить ось.
Эта ось слишком много решает за меня. Так что спасибо, но тот же центос мне намного милее, а самой страшной проблемой было найти мануал по vim для работы по ssh.
PS. Про сами маки, как железки, ничего плохого сказать не могу. Тут уж они постарались, но цена явно не соответствует.
1. Показ скрытых файлов и папок включили?
2. sudo edit /usr/…
3. Что за ерунда? AFAIK, апач в стандартную поставку не входит и ставится из MacPorts или HomeBrew, откуда прекрасно обновляется до самых свежих версий без влезания в системную поставку файлов (по-крайней мере в HomeBrew точно). Что нужно было сделать, чтобы прийти к выводу «для обновления апача нужно обновить ось» – ума не приложу.
2. sudo edit /usr/…
3. Что за ерунда? AFAIK, апач в стандартную поставку не входит и ставится из MacPorts или HomeBrew, откуда прекрасно обновляется до самых свежих версий без влезания в системную поставку файлов (по-крайней мере в HomeBrew точно). Что нужно было сделать, чтобы прийти к выводу «для обновления апача нужно обновить ось» – ума не приложу.
При первом столкновении в чуть поглубже, от макоси я ожидал поведение, сходное с центосью, однако обломался уже с первых шагов.
3. На леопарде (не помню точно, была эта версия начальной или обновлялись уже до нее) апач уже был предустановлен, как штатное средство, но не сконфигурирован. И обновлялся вместе с осью.
PS. Так что все пункты — это мое имхо. Все таки линукс мне ближе, чем макось, т.к. вел он себя всегда именно так, как я этого от него ожидал.
3. На леопарде (не помню точно, была эта версия начальной или обновлялись уже до нее) апач уже был предустановлен, как штатное средство, но не сконфигурирован. И обновлялся вместе с осью.
PS. Так что все пункты — это мое имхо. Все таки линукс мне ближе, чем макось, т.к. вел он себя всегда именно так, как я этого от него ожидал.
Какие-то сугубо админские штуки, вполне возможно проще сделать на Линуксе (потом на iOS, потом, если, вообще, возможно, на Винде). Но я имел в виду наиболее популярные задачи. На Линукс даже Webstorm или IDEA без бубна не поставить, чтобы работал копипаст в русской раскладке, например. Про MySQL, Apache и PHP вы явно загнули. В позапрошлой компании велась разработка на этих технологиях под Маками без проблем.
Скажите, а вы всегда обо всех по себе судите? Обоснуйте, пожалуйста, ваше утверждение о том, что в Linux разработку вести удобнее. Удобнее благодаря чему? Благодаря отсутствию современных инструментов разработки. То, что есть, извините — вчерашний день. Открытием это могут называть лишь те, кто ни разу не сталкивался с аналогичными профессиональными инструментами.
Git удобнее? Ну может, может… когда не знаешь, что git под Windows работает так же. Хотя назвать git профессиональным инструментом — язык не поворачивается. Опять таки — открытие для тех, кто source control впервые встречает, ну, или, для тех кто предпочитает целыми днями манулы листать вместо производства, а затем нос задирать — сморите, мол, как я очередной мануал освоил. Впрочем команды разработчиков с огромным удовольствием переходят на TFS, когда показываешь им все преимущества профессионального продукта.
Хотя кому и Лада лучше коня, а кому Мерседес нужен, потому что ценит своё время, имидж, и качество.
Git удобнее? Ну может, может… когда не знаешь, что git под Windows работает так же. Хотя назвать git профессиональным инструментом — язык не поворачивается. Опять таки — открытие для тех, кто source control впервые встречает, ну, или, для тех кто предпочитает целыми днями манулы листать вместо производства, а затем нос задирать — сморите, мол, как я очередной мануал освоил. Впрочем команды разработчиков с огромным удовольствием переходят на TFS, когда показываешь им все преимущества профессионального продукта.
Хотя кому и Лада лучше коня, а кому Мерседес нужен, потому что ценит своё время, имидж, и качество.
хотя назвать git профессиональным инструментом — язык не поворачивается. [...] команды разработчиков с огромным удовольствием переходят на TFS, когда показываешь им все преимущества профессионального продукта.
Вот это сейчас, конечно, смешно. Во-первых, в TFS есть поддержка git как системы версионирования. Во-вторых, какие же преимущества профессионального продукта есть у TFVC?
Это не смешно. У TFS нет поддержки git. У Visual Studio Online — есть. Теперь ответ на ваш вопрос.
Если вы open source проект, то да — git ваше всё, так как pull request'ы именно под open source разработку. На этом преимущества git заканчиваются. Остаётся просто голое складирование изменений в файлах. С кучей проблем. Не будем себе врать, что git удобен. Все мы видели, как члены команды (зачастую профессиональные программисты, а не джуниоры), тратят часы на очередной коммит, потому что где-то что-то пошло не так. Можно это отрицать, можно это принимать. Многие команды не понимают как нормально пользоваться git'ом — в следствие чего он у них чаще всего ни разу не связан с ходом проекта. Просто склад изменений файлов. А когда требуется срочно поднять из системы контроля версий рабочую версию, выяснить какой «коммит» надо откатить, или просмотреть привязку коммитов к проекту — тогда просто начинается фестиваль танцоров с бубном.
Поэтому TFS — ваше всё, если вы руководите несколькими связанными проектами, в которых задействованы разные люди. И если вы понимаете, что успех проекта важнее гордости о того, что пользуетесь git'ом. Потому что TFS тупо не создаёт проблем, а имеющиеся *решает*. Поэтому и переходят на него целые команды, когда им его показываешь.
Честно говоря, я бы вообще запретил называть git системой *контроля версий*. Просто системой складирования изменений.
P.S. есть, конечно же, люди, чувства верующих которых оскорбляет всё, что связано с именем Microsoft (им даже $ мерещится в имени этом) — это отдельная категория. Для них и Microsoft, и многие другие открывают репозитории на GitHub.
Если вы open source проект, то да — git ваше всё, так как pull request'ы именно под open source разработку. На этом преимущества git заканчиваются. Остаётся просто голое складирование изменений в файлах. С кучей проблем. Не будем себе врать, что git удобен. Все мы видели, как члены команды (зачастую профессиональные программисты, а не джуниоры), тратят часы на очередной коммит, потому что где-то что-то пошло не так. Можно это отрицать, можно это принимать. Многие команды не понимают как нормально пользоваться git'ом — в следствие чего он у них чаще всего ни разу не связан с ходом проекта. Просто склад изменений файлов. А когда требуется срочно поднять из системы контроля версий рабочую версию, выяснить какой «коммит» надо откатить, или просмотреть привязку коммитов к проекту — тогда просто начинается фестиваль танцоров с бубном.
Поэтому TFS — ваше всё, если вы руководите несколькими связанными проектами, в которых задействованы разные люди. И если вы понимаете, что успех проекта важнее гордости о того, что пользуетесь git'ом. Потому что TFS тупо не создаёт проблем, а имеющиеся *решает*. Поэтому и переходят на него целые команды, когда им его показываешь.
Честно говоря, я бы вообще запретил называть git системой *контроля версий*. Просто системой складирования изменений.
P.S. есть, конечно же, люди, чувства верующих которых оскорбляет всё, что связано с именем Microsoft (им даже $ мерещится в имени этом) — это отдельная категория. Для них и Microsoft, и многие другие открывают репозитории на GitHub.
Это не смешно. У TFS нет поддержки git.
Да ладно. А что предлагают выбрать на слайде в туториале? Ну или вот: "In Team Foundation Server 2015 Update 1, a project administrator can add a Git repo to a team project".
Если вы open source проект, то да — git ваше всё, так как pull request'ы именно под open source разработку.
Какие-такие пулл-реквесты? В git нет пулл-реквестов.
Все мы видели, как члены команды (зачастую профессиональные программисты, а не джуниоры), тратят часы на очередной коммит, потому что где-то что-то пошло не так.
Не знаю насчет "мы все", я не видел. Зато я видел, как люди мучаются с коммитом в TFVC (а уж как люди мучаются с бранчами в TFVC — это вообще отдельный разговор.
Кстати, а с чем именно мучаются ваши "члены команды"?
Многие команды не понимают как нормально пользоваться git'ом
Так это проблема образования, а не версионной системы.
А когда требуется срочно поднять из системы контроля версий рабочую версию, выяснить какой «коммит» надо откатить,
А в чем проблема? Нет, вот конкретно — в чем проблема с каждым из этих пунктов?
или просмотреть привязку коммитов к проекту
Вот и началось. В терминах версионной системы все коммиты в одном репозитории привязаны к одному проекту (это верно и в git, и в TFVC). А если вы говорите о привязке коммита к задаче, то в этот момент мы покидаем границы собственно системы управления версиями, и начинаем говорить об ALM-системе.
Поэтому TFS — ваше всё, если вы руководите несколькими связанными проектами, в которых задействованы разные люди
Стоп-стоп. Поддержка управления проектами — не задача системы управления версиями. Вы точно не путаете VCS- и ALM-системы?
а имеющиеся [TFS] решает.
Простой вопрос. Вот у вас есть диапазон в 100 чейнджсетов. Вы знаете, что где-то в этом диапазоне было внесено изменение, сломавшее вашу систему, но не знаете, какое именно. Как именно TFS решает проблему нахождения этого изменения?
Честно говоря, я бы вообще запретил называть git системой контроля версий. Просто системой складирования изменений.
Простите, а в чем, по-вашему, разница? Система контроля версий — это именно система "складирования изменений" (если вы, конечно, не путаете систему контроля версия с системой управления релизами).
Фундаментальное достоинство — и одновременно проблема — TFS в том, что это монолит. В нем есть VCS (долгое время безальтернативная и далеко не идеальная), в нем есть управление задачами (среднее, на мой вкус), в нем есть билд-сервер (вот этот мне очень нравился, но мы и в нем постоянно бились головой в проблемы), есть система поддержи тестирования (мы так и не освоили ее), и, насколько я знаю (это было уже после того, как с него слез) добавили систему управления релизами. И все это — интегрировано: чейнджсеты привязываются к воркайтемам, воркайтемы — к билдам, из этой информации можно собрать чейнжлог и/или посмотреть тест-импакт и так далее. Очень круто, да. Пока ты сидишь внутри этого монолита. Как только ты начинаешь заменять его кусочки на что-то другое (например, тебе нужна другая система управления задачами), вся эта интеграция начинает трещать по швам.
Я повторю свой вопрос: какие преимущества "профессионального продукта" есть у TFVC?
Я писал «Это не смешно. У TFS нет поддержки git. У Visual Studio Online — есть». Это чтобы не вырывать из контекста.
Ну что я могу сказать на все ваши комментарии. В целом вы не ошибаетесь, но… и не совсем правы. Проблема монолитности решается ликбезом. А в последнее время кучей extension'ов. В целом да — большинство проблем — от незнания. Я работаю на европейском рынке, возможно в России — все в целом умнее (это не сарказм).
В целом скажу так: после перевода команд с git на TFS — продуктивность возрастает. Исчезают проблемы использования source control system. Команды начинают думать о проекте, а не об отдельных коммитах.
Со всем уважением: отвечать по пунктам не стану, т.к. время не резиновое.
Ну что я могу сказать на все ваши комментарии. В целом вы не ошибаетесь, но… и не совсем правы. Проблема монолитности решается ликбезом. А в последнее время кучей extension'ов. В целом да — большинство проблем — от незнания. Я работаю на европейском рынке, возможно в России — все в целом умнее (это не сарказм).
В целом скажу так: после перевода команд с git на TFS — продуктивность возрастает. Исчезают проблемы использования source control system. Команды начинают думать о проекте, а не об отдельных коммитах.
Со всем уважением: отвечать по пунктам не стану, т.к. время не резиновое.
Я писал «Это не смешно. У TFS нет поддержки git. У Visual Studio Online — есть». Это чтобы не вырывать из контекста.
Так я вам ссылку даю на on-premise TFS, при чем тут Visual Studio Online?
Проблема монолитности решается ликбезом
Как вы можете решить ликбезом проблему "я хочу использовать YouTrack вместо TFS WIM, но сохранить всю интеграцию"?
В целом скажу так: после перевода команд с git на TFS — продуктивность возрастает.
Вне зависимости от сложности проекта? При какой branching strategy?
Потому что лично мои наблюдения строго противоположны: переход с TFVC на git я воспринял как облегчение (особенно учитывая период в несколько месяцев, пока я пользовался ими параллельно), и эти наблюдения повторяются на многих людях.
Со всем уважением: отвечать по пунктам не стану, т.к. время не резиновое.
Я в таком случае сочту, что вы согласились со всеми моими возражениями — и при этом не смогли указать конкретных преимуществ.
git под Windows работает так же
Особенно учитывая, что виндовс не различает регистра в файлах.
«Особенно учитывая, что виндовс не различает регистра в файлах» — учите матчасть, а не слухами живите. А вообще за использование имён файлов, различающихся лишь регистром — тимлиды должны бить по рукам, и очень сильно.
Поясню предыдущего оратора — NTFS/FAT не различает, а не сама Windows.
И слава богу. Совсем не упало разрешать ситуации когда «veryImportantFile» не то же что и «VeryImportantFile».
А ситуация, в которой VeryImportantFile, veryimportantfile и VERYIMPORTANTFILE — одно и то же, чем-то лучше? Особенно, если имя файла фигурирует где-то в проекте (например, в конфиге).
Конечно. Вот файл с именем <>, ловить ошибки сборки/работы при неверно набранной букве (регистре буквы) — не шибко увлекательно.
Когда такая ситуация возникает в legacy code — ничего не поделаешь, приходится с ней жить (а по возможности искоренять). Когда такую ситуацию создают мои программисты — я с ними не спорю: предлагаю либо перестать так делать, либо оплачивать из своего кармана каждую проблему, возникшую из-за того, что VeryImportantFile, veryimportantfile и VERYIMPORTANTFILE — разные файлы. Желание повыёживаться лечится мгновенно.
Как говорится — в личных проектах хоть трамвай из буханки лепите. В профессиональных проектах — следуйте здравому смыслу.
Как говорится — в личных проектах хоть трамвай из буханки лепите. В профессиональных проектах — следуйте здравому смыслу.
Ну, когда-то говорили что и «640 килобайт хватит всем»
Вы должны были вовремя сказать это Торвальдсу, пока он не начал
Если уж браться за новую ОС, то почему на старых языках программирования?
Тот же Rust хорошо подходит для операционных систем, да и поддержка каналов в нем есть.
Тот же Rust хорошо подходит для операционных систем, да и поддержка каналов в нем есть.
потому, что годного софта на них за несколько десятилетий в мире уже много понаписано, да и число годных программистов на них очень велико. Но тут по языковому принципу никого не дискирминируют. Пусть будет и rust, если сможет
Было бы очень интересно посмотреть на ось на rust-e, да и растущее сообщество 100% поддержит такую идею
Пожалуй, для новой, «принципиально новой», ОС наличие уже написанного софта на C или C++ не так критично, т.к. подавляющая часть кода пишется с нуля. За исключением, возможно, действительно сложных подсистем вроде TCP/IP, для которых проще будет адаптировать уже существующий код (Linux, lwIP etc.)
А почему надо на новомодных писать? А почему до сих пор новые фреймворки пишутся на тех же плюсах? К примеру, TensorFlow.
И ведь пишут уже, тот же Redox
Почему в подобных постах авторам навязывают свой любимый язык? Я считаю, что причины «автор лучше знает этот язык» вполне достаточно.
Во первых — не любимый. Haskell и ELM мне нравится больше.
Во вторых — потому что он очень хорошо подходит к задаче.
Во вторых — потому что он очень хорошо подходит к задаче.
Так я не понял. Это только задумки, или уже что-то написано?
А почему ОС новая, а принципы старые? Так новую ОС не построишь.
Можно взять в качестве принципа например «всё ессть ветки дерева», чтобы вся система была гиганстким деревом, начиная от драйверов, и заканчивая каждой буквой на экране.
Или положить в основу функциональный подход — отсуствие состояний.
Можно взять в качестве принципа например «всё ессть ветки дерева», чтобы вся система была гиганстким деревом, начиная от драйверов, и заканчивая каждой буквой на экране.
Или положить в основу функциональный подход — отсуствие состояний.
У микрософт была попытка написать на c#.
А так хорошая идея, может нового ничего не изобретут зато поможет избавиться от мохнатого легаси.
А так хорошая идея, может нового ничего не изобретут зато поможет избавиться от мохнатого легаси.
Это была не попытка, а обычный учебный проект. Microsoft Singularity и не позиционировался как серьезная ОС.
Вот лично я смотрю на то, что Singularity не дал начало чему-то большему, с огромным сожалением. С тех пор, как первый раз прочитал про нее, мне невероятно понравилась концепция этой ОС. И всякие ОС-эксперименты с новыми (ну как новыми, относительно) подходами считаю только благом — взять тот же Фантом ОС.
Я следил в то время за проектом через всякие конференции и блоги, англоязычные. Как я понял — до определенного времени система была очень предсказуема и проста в написании, но по достижении кодовой базы реальных приложений, она просто стала громоздка и неповоротлива.
А нежизнеспособность системы, можно констатировать еще и по тому, что код открыт, а работы нет вообще…
А нежизнеспособность системы, можно констатировать еще и по тому, что код открыт, а работы нет вообще…
На самом деле при определенной привлекательности систем на управляемом коде и прочих интересных концепциях, у них есть огромный недостаток — в мире существует огромное количество кода на с\с++, а системы вроде Singularity, которая исполняет все в режиме ядра и безопасность осуществляется верификацией нативного кода принципиально (?) не смогут выполнять все то множество нативного кода без утраты безопасности.
ну а новые нескучные обои-то есть?)
кстати, название ROS для операционной системы уже используется
кстати, название ROS для операционной системы уже используется
Ну тут только можно посоветовать создать рабочую платформу в виде Гиперлуп Уан, и все желающие могут участвовать.
Если я правильно понял, канал — это менеджер задач + некая разделяемая память. Если я хочу прочитать из канала, я добавляю в него задачу, передавая параметрами то, что хочу прочитать. Когда данные будут готовы, канал их запишет в разделяемую память канала и вызовет мою задачу. Если я хочу записать в канал, то аналогично — я добавляю задачу, которая пишет в разделяемую память канала. Синхронизация не нужна, т.к. канал использует одно ядро процессора (через соответствующий канал процессора).
Если так, то…
Разве передача всех данных в канал через разделяемую память канала — это не излишество? У пишущей задачи, как правило, уже есть собственный буфер с данными и его придется копировать в память канала.
Зачем нужно различать экспортеров и импортеров?
export/import — нужен для маппинга канала в userspace и для удаленных(remote) каналов? В принципе, никто не мешает работать напрямую с исходным каналом, так?
Зачем каждому каналу собственный менеджер памяти?
Вообще не знаю как насчет операционных систем, но эта идея выглядит интересной для построения сетевых приложений…
Нет, увы, вы поняли неправильно. Менеджер задач — отдельная сущность, так же как и менеджер памяти. а канал -это канал :) данные копироваться не будут, будут отображаться. А насчёт сетевых приложений — да, для них тоже.
Ну, как автор единственного комментария по теме, я бы хотел получить более развернутый ответ :-)
Канал – это и есть разделяемая память в рамках локальной системы, так что задачи ничего лишнего не копируют, а спокойно работают с данными в канале. Неизбежные копирования возникнут только при репликации канала на удаленные системы.
Диспетчер задач не имеет непосредственного отношения к каналам, просто задачи могут легко передавать управление своим контрагентам, чтобы избежать неэффективных (во многих случаях) схем постоянного опроса данных.
Экспорт и импорт – это просто API для установления взаимодействия между задачами: одна задача должна сообщить окружающим, что она готова предоставить какую-то услугу и что эта услуга называется так-то и так-то и физически материализуется в такой-то память такого-то размера, а другая задача отображает эту материализованную услугу к себе в память и начинает общаться с первой.
Диспетчер задач не имеет непосредственного отношения к каналам, просто задачи могут легко передавать управление своим контрагентам, чтобы избежать неэффективных (во многих случаях) схем постоянного опроса данных.
Экспорт и импорт – это просто API для установления взаимодействия между задачами: одна задача должна сообщить окружающим, что она готова предоставить какую-то услугу и что эта услуга называется так-то и так-то и физически материализуется в такой-то память такого-то размера, а другая задача отображает эту материализованную услугу к себе в память и начинает общаться с первой.
Что такое "услуга"? Я думал, что канал — это и есть услуга. Т.е. сам факт существования канала означает, что кто-то предоставляет услугу.
Возьмем, к примеру, канал жесткого диска. Как некой задаче прочитать данные с диска?
- она формирует подзадачу и передает её каналу жесткого диска с параметрами (operation=READ, sector=123456)
- канал (?) или другая задача прикрепленная к каналу? (как тогда она узнает о п.1?) отправляет запрос на контроллер жесткого диска с просьбой прочитать данные в память (в память канала? в память вызывающей таски?) и добавляет таску в канал, владеющий прерываниями.
- когда чтение завершено, вызывается прерывание, которое приводит к вызову таски из канала прерываний, которая вызывает таску из п.1, сигнализируя вызывающему коду об окончании операции.
Так?
Попросила ответить автора ОС.
Для чтения с диска:
1. Привилегированная задача, обслуживающая диск, экспортирует некоторый канал. Канал, к примеру, может содержать поля с намером цилиндра, головки, сектора и типом операции, а также место под данные сектора.
2. Задача, желающая прочитать данные, импортирует этот канал, заполняет поля — цилиндр, головка, сектор, чтение — и передает упраление привилегированной задаче (yield-to).
3. Привилегированная задача получает управление, программирует аппаратуру в соответствии с запросом, перехватывает прерывание (запрашивает от ядра системы через системный канал) и «засыпает».
4. По завершении операции чтения аппаратура генерирует прерывание, привилегированная задача получает управление, проверяет данные, если надо — копирует их в канал (если аппаратура не может скопировать данные по адресу канала — например, он располагается слишком высоко в физической памяти), а потом передает управление обратно задаче-клиенту (yield-to).
5. Клиент просыпается — а у него в канале уже лежат данные нужного сектора диска.
Надеюсь, что это понятно (мне — да :) ) Но, если нет, советую написать автору — его контакт в тексте есть.
Для чтения с диска:
1. Привилегированная задача, обслуживающая диск, экспортирует некоторый канал. Канал, к примеру, может содержать поля с намером цилиндра, головки, сектора и типом операции, а также место под данные сектора.
2. Задача, желающая прочитать данные, импортирует этот канал, заполняет поля — цилиндр, головка, сектор, чтение — и передает упраление привилегированной задаче (yield-to).
3. Привилегированная задача получает управление, программирует аппаратуру в соответствии с запросом, перехватывает прерывание (запрашивает от ядра системы через системный канал) и «засыпает».
4. По завершении операции чтения аппаратура генерирует прерывание, привилегированная задача получает управление, проверяет данные, если надо — копирует их в канал (если аппаратура не может скопировать данные по адресу канала — например, он располагается слишком высоко в физической памяти), а потом передает управление обратно задаче-клиенту (yield-to).
5. Клиент просыпается — а у него в канале уже лежат данные нужного сектора диска.
Надеюсь, что это понятно (мне — да :) ) Но, если нет, советую написать автору — его контакт в тексте есть.
Не пугайте рядовых начинающих специалистов названиями типа «ROS», «GOS» и т.д. Первая мысль — новое детище инициатив российских депутатов.
А так спасибо за статью, интересно даже несмотря на объем статьи. )
А так спасибо за статью, интересно даже несмотря на объем статьи. )
походу сезон дипломных работ начался на хабре
А посмотреть на нее где нибудь можно? Код или какой-то рабочий прототип?
Интересно, но непонятно текущее состояние проекта.
Новая ос хорошо, но отсутствие тонны софта под любую задачу делает её такой же нужной как и виндоус мобаил.
Прежде чем создавать что-то новое, либо вы должны быть первыми, либо нужно найти того, кто откажется от старого.
К сожалению, в IT сфере множество новых технологий, которые значительно лучше старых, но выгода от них разбивается об затраты на внедрение.
К сожалению, в IT сфере множество новых технологий, которые значительно лучше старых, но выгода от них разбивается об затраты на внедрение.
И снова пост скатился до выяснения что лучше: окна или пингвины…
а что касается самого поста, то я почему-то очень скептично настроен… и уж точно на первых этапах будут проблемы с софтом, драйверами, безопасностью… это те шаги — которые не за один год проходят…
а что касается самого поста, то я почему-то очень скептично настроен… и уж точно на первых этапах будут проблемы с софтом, драйверами, безопасностью… это те шаги — которые не за один год проходят…
OS целиком написанная и развиваемая одним человеком — сомневаюсь в практическом результате.
Да просто по объему кода физически невозможно (я не про ядро и не про «микро» OS дипломных проектов).
В том, что этим можно заниматься — даже не сомневаюсь. Возможно даже идеи заложенные концепциях гениальные.
Но кто этим будет заниматься и проверять/развивать?
Типичный диплом (тема) в НГТУ на соответствующем факультете был (сейчас не знаю): RTOS под какой ни будь контроллер/процессор или разработка ядра процессора с микрокодом.
Естественно учебная и только для демонстрации работы.
В рассуждения о…
Intel закрывает разработку в России. Может быть появившаяся статья с этим связана… или нет…
Да просто по объему кода физически невозможно (я не про ядро и не про «микро» OS дипломных проектов).
В том, что этим можно заниматься — даже не сомневаюсь. Возможно даже идеи заложенные концепциях гениальные.
Но кто этим будет заниматься и проверять/развивать?
Типичный диплом (тема) в НГТУ на соответствующем факультете был (сейчас не знаю): RTOS под какой ни будь контроллер/процессор или разработка ядра процессора с микрокодом.
Естественно учебная и только для демонстрации работы.
В рассуждения о…
Intel закрывает разработку в России. Может быть появившаяся статья с этим связана… или нет…
Это концепт или уже что-то реальное? Из текста не до конца понятно.
Идея с каналами, кажется, уже была реализована в Amoeba.
QNX не?
Не скажу что я прям прочитал и все понял. Похоже на то как я понимаю микроядро (т.е. IPC в виде каналов) + некоторый трюк с тем что хранить контекст можно не всегда. Хотя в данном случае задачи которые используют каналы не обязательно изолированны как в микроядрах.
Наверное если построить аналог десктопной оси, то ядро в своем кернел спейсе будет вот так красиво работать без сохранения контекста, a userspace чаще всего как вытесняющая многозадачность как сейчас. Во встраиваемых или мобильных осях наверное можно попытаться эти канальные прелести вывести на уровень пользовательского API
Наверное если построить аналог десктопной оси, то ядро в своем кернел спейсе будет вот так красиво работать без сохранения контекста, a userspace чаще всего как вытесняющая многозадачность как сейчас. Во встраиваемых или мобильных осях наверное можно попытаться эти канальные прелести вывести на уровень пользовательского API
Если трансляторов нет, то могу сразу и идею языка предложить: https://habrahabr.ru/post/219419/
Пока подходит CLR — в связи с наличием управляемой памяти для функционального программирования.
Пока подходит CLR — в связи с наличием управляемой памяти для функционального программирования.
Я тоже новые проекты всегда с названия начинаю ;)
Почитал комментарии… Вы оффтопите! Написано — проект принципиально новой OS, созданный в нерабочее время одним из ведущих сотрудников. В нерабочее, остываем, включаем понимание. Может быть я наивен, и это действительно чей-то диплом… А может и нет! Чувак написал концепцию, отдал в руководство, а руководство сказало, а давайте ка мы напишем обзор в IT-сообщества и посмотрим, что об этом думают люди, которые собственно под эту ось и будут что-то писать. Извините, но половина комментариев это спор о том, какая ось у кого на работе. Уважаемый автор (инициатор) статьи, пишите пожалуйста, что именно Вы хотите узнать, потому что мы не понимаем что от нас требуется. На мой взгляд вы хотите обсудить детали реализации концепции. Явно писать об этом нужно, понимаете о чём я? Я бы хотел задать свой вопрос, если позволите. В операционных системах я не силён и у меня скорее общий вопрос. Вы описали серьёзные теоретические преимущества в плане минимального потребления системных ресурсов и масштабируемости по отношению к мощности железа. Ну клёво, а в цифрах сколько получается? По негативному и позитивному прогнозу, сколько мы сэкономим системных ресурсов по сравнению с Linux, Android, Mac. Было бы здорово если бы Вы показали нам таблицу. Спасибо.
В процессе разработки появятся проблемы с отладкой и тестированием, как мне кажется, так как очень сложно будет отследить цепочку выполнения, когда провайдеры будут перераспределяться и делегировать процессы друг другу, а стек, как я понимаю не будет хранить контекст задачи и информация о цепочки выполнения будет просматриваться только в рамках одной задачи. Поэтому фактор отладки нужно усмотреть изначально.
Наоборот, процесс отладки и тестирования упрощается, потому что все взаимодействия конкретной задачи с «внешним миром» известны менеджеру каналов и планировщику задач и могут быть сохранены и представлены задаче-отладчику в виде отдельного канала.
К сожалению, объем статьи не позволяет детально рассмотреть все аспекты ОС, но поверьте на слово, что вопросы отладки, трассирования и измерения производительности рассматривались и учитывались с самого начала. Есть несколько вариантов организации отладки: (1) непосредственное исполнение отлаживаемой задачи в контексте привилегированной задачи-отладчика (так как код любой задачи не зависит от адреса загрузки и от адресов отображения каналов) и (2) расширение системного канала (и, соответственно, ядра ОС), позволяющее получать привилегированным задачам информацию о поведении и производительности других задач, ну а также (3) любые комбинации подходов 1 и 2.
К сожалению, объем статьи не позволяет детально рассмотреть все аспекты ОС, но поверьте на слово, что вопросы отладки, трассирования и измерения производительности рассматривались и учитывались с самого начала. Есть несколько вариантов организации отладки: (1) непосредственное исполнение отлаживаемой задачи в контексте привилегированной задачи-отладчика (так как код любой задачи не зависит от адреса загрузки и от адресов отображения каналов) и (2) расширение системного канала (и, соответственно, ядра ОС), позволяющее получать привилегированным задачам информацию о поведении и производительности других задач, ну а также (3) любые комбинации подходов 1 и 2.
Вроде реально
НЛО прилетело и опубликовало эту надпись здесь
Спасибо за вопрос.
в частном случае каналов с кодом — да, это очень похоже на dll, об этом есть упоминание в тексте.
И да, если ничего не делать специально — применять ключи, цифровые подписи и прочие механизмы защиты, то вероятность подмены канала есть.
Но никто не мешает: 1) не пользоваться каналами с кодом для важных программ, и 2)ввести механизмы защиты, описанные выше.
В функции ОС вообще не входит защита программ от подобного фишинга, это задача самих приложений. ОС должна уметь защищать себя, и она это умеет.
в частном случае каналов с кодом — да, это очень похоже на dll, об этом есть упоминание в тексте.
И да, если ничего не делать специально — применять ключи, цифровые подписи и прочие механизмы защиты, то вероятность подмены канала есть.
Но никто не мешает: 1) не пользоваться каналами с кодом для важных программ, и 2)ввести механизмы защиты, описанные выше.
В функции ОС вообще не входит защита программ от подобного фишинга, это задача самих приложений. ОС должна уметь защищать себя, и она это умеет.
Вы привели пример кода на с++, для чего нужен модификатор channel? Десятки лет межпроцессное взаимодействие осуществлялось без модификаторов, а тут он вдруг понадобился?
Нда… данные и код, произвольно перемещаемые в памяти — это ад.
1) Разве нельзя никак обойтись без изменений в языках для поддержки передачи кода и данных в одном потоке? Скажем, настройками линкера, чтобы он складывал часть кода в блоке с данными?
2) При передаче кода ведь подразумевается, что везде используется одинаковый тип процессора? Это не так в случае сетей и это осложняет использование разных типов процессоров на одной материнке (мало ли что! менять мир — так уж универсальным образом!)
3) Также очень жалко статические переменные. Опять это требует изменения языков или компиляторов (ключи добавить с запретом статики придётся)
2) При передаче кода ведь подразумевается, что везде используется одинаковый тип процессора? Это не так в случае сетей и это осложняет использование разных типов процессоров на одной материнке (мало ли что! менять мир — так уж универсальным образом!)
3) Также очень жалко статические переменные. Опять это требует изменения языков или компиляторов (ключи добавить с запретом статики придётся)
К сожалению с фантазией на названия плохо (ибо судя по всему вся она уходит на генерацию идей, что я считаю даже лучше), поэтому годного названия предложить не могу. Однако название ROS OS оставлять нельзя. Я понимаю, аббревиатура расшифровывается очень красиво и несет в себе серьезный мессадж, но ROS не годится никуда. Что же это за Роснано? Уж извините, но в последнее время все эти конвульсии при отказе от всего зарубежного вызывают только тоску и какую-то… Какую-то брезгливость… Просто вырвалось, уж извините… Заранее благодарен за понимание!
И чем дело кончилось… или не кончилось?
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Создаем новую OS. Действительно новую, реально операционную, и правда – систему