Я вообще не очень понимаю как некое соглашение не подтвержденное документально может иметь какую-то юридическую силу.
Чисто технически, если есть свидетели, то даже устный договор считается договором.
Но в данном случае это регулируется Гражданским кодексом РФ, а именно:
Начало использования таких программы или базы данных пользователем, как оно определяется этими условиями, означает его согласие на заключение договора.
Вы намеренно смещаете акценты вырезая мою фразу из контекста?
По Вашей логике, пользоваться OSS могут только те люди, которые имеют возможно самостоятельно исправлять ошибки конкретно в нём.
Даже близко не так. Пользоваться они могут и для этого есть такое понятие как лицензия. Давайте вспомним что там написано про ответственность? Взять тот же GPLv3 или MIT. Все привыкли, что такие проекты можно использовать, собирать, распространять и даже форкать. Но почему-то, некоторые забыли, что автор не несёт какой-либо ответственности за продукт и вы используете его на свой страх и риск.
Ричард Столман как раз именно эту идею продвигал, что вы свободны использовать, а разработчик свободен от ответственности — всё честно.
На самом деле когда прислалают гневный Issue, да ещё и по критическому багу — это большая удача для разработчика
Попахивает мазохизмом. Не важно какого рода баг — это не меняет того, что пользователь никакого ни юридического, ни морального права не имеет чего-то требовать от автора СПО.
Ты приходишь ко мне, требуешь чтобы я потратил своё время. Но ты делаешь это без уважения pull-request или патча.
(Адаптация)
Я думаю у вас не очень корректное сравнение. Более точным будет, если вы дадите вашему другу свою машину, в которой вы только перебрали двигатель, вложились и т.д., а он приедет и скажет: «Эй, чувак! Твоя машина отстой. У неё подлокотник справа слишком высоко. Исправь, а то я больше не буду у тебя брать машину.»
Одно дело, когда вы участвуете в жизни проекта, развиваете его и вы обнаружили какую-то критическую ошибку, которую не знаете как исправить. Вы пишите подробный step-to-reproduce, высказываете предположения где могла бы быть проблема и т.д.
Другое дело, если вы взяли уже собранный пакет, установили как зависимость и обнаружилось, что ваше приложение уязвимо из-за этой ошибки, и вы, вместо того, чтобы предложить исправление, начинаете писать автору гневно-требовательный issue, где требуете немедленного отчёта в том, почему автор ещё не закрыл эту уязвимость, ведь это вам так сильно нужно. И ладно если это ошибка. Иногда просто хочется какой-то функциональности, а она, оказывается, не планируется к внедрению в ближайшем будущем.
Я верю, что вы не относитесь ко второй категории, но простите — накипело. Всё желание в OpenSource выкладывать что-либо отбивают такие «кадры».
Мне кажется у нас с вами просто разный круг примеров. Правда я учитываю оба круга.
Вам не кажется, что проблему с единственным файлом в excel без бекапов VDI по факту и не решает?
Передайте это роскомнадзору. Частное облако это уже другое дело, но там и ресурсов нужно соизмеримо много.
Дисковая подсистема — рейд + бэкапы.
Рейд не панацея. Вышли из строя одновременно 4 SSD и рейд посыпался. Контроллер проглючило — рейд посыпался. Всё так или иначе приводит к единой точке отказа.
Смерть сервера означает что какие-то виртуалки выключились и включились на другом сервере.
Вот реальный пример: частное облако на OpenStack+KVM+Ceph. Всё хранится в распределённой системе, контроллеры и compute-ноды с большим запасом. В один прекрасный момент у Ceph происходит беда в виде split-brain. Понятно, что ошибка была в том, что не отмониторили вовремя, но из 20 VPC удалось восстановить только одну. Единственное что спасло от реальных потерь — распределённое дублирование ресурсов (git — это был отдел разработки). На всех компах по прежнему была копия данных, что позволило легко с нуля поднять всё.
Всё не так однозначно. Эти риски нужно так же учитывать, а значит и закладывать бюджет. Так, получается, что экономичным это решение не назовёшь. Но я ещё раз уточняю, что я не утверждаю, что это решение 100% не правильное и неудобное.
Но это не «серебрянная пуля» и, особенно для SMB, не всегда правильное решение.
Привет от Роскомпозора и Телеги. Опять же рубанули интернет в офисе — весь офис встал. VDI вообще никак не решает проблему вандалоустойчивости, особенно на сторонних ресурсах зависимых от канала связи.
сломался компьютер, взял с полочки коробочку 15 см на 15 и воткнул сеть,
А эта коробочка бесплатная что ли? Их стоимость соизмерима со стоимостью нормального компа. Есть такие же небольшие и достаточно удобные мини-PC, которые так же могут лежать с подготовленной системой, либо PXE.
Вы опускаете очень много этапов и деталей: покупку этих тонких клиентов, переход на VDI, стоимость лицензий, стоимость серверов (которые так или иначе придётся брать), отказоустойчивость, единая точка отказа и т.п.
Вырубили свет/интернет в центральном филиале — простой в двух остальных.
Знаете какой у них IT отдел? 12 человек
То что у них штат раздут и никакой автоматизации это не признак того, что VDI их спасёт. Скорее ещё админа для VDI возьмут или на кого-то ответственность установят + зп поднимут («ага, щас»), но штат не поменяют.
200к в месяц сэкономили. К концу года 2 миллиона можно тратить на новые сервера.
Откуда такие числа? С головы? В реальности другие совсем и с минусом впереди.
VDI хорош еще тем что он работает везде, его можно запустить в привычном виде и на Маке и планшете с андроидом
Взять ту же 1С-WEB. Я не большой сторонник 1С, но в целом она работает через браузер и с мобилки, и с Линукс, и с Mac, и с Форточек. А если добавить OnlyOffice, то будет и CRM, и Word/Excel, и централизованное хранилище документов, и почтовый сервер/клиент. Более того — всё через один защищённый порт 443 (если настроить https). Да и с доступом проще: зашёл на портал и всё. Никаких корявых RDP или VNC.
Если вы строите инфраструктуру не с нуля то как правила более половины оборудования уже у вас есть.
Почему это колхоз обычно рассказывают после шифровальшика...
Но, предположим что у вас есть 100 компьютеров, которые морально устарели и их надо обновлять до уровня i3 8г 500т = 30к (за 1 блок) по скромному.
Мне кажется вы рассматриваете какой-то очень богатый колхоз, где стоят реально мощные сервера без дела и реально большие проблемы с безопасностью. Не говоря уже о том, что приводите в пример единственно правильный сценарий, хотя всё бывает не только как у вас.
Как, например, такой вариант:
1. 2 относительно небольших сервера (24C на Socket604 и 64ГБ RAM) на Linux под БД PostgreSQL.
2. 2 совсем небольших сервера (8С и 32ГБ Ram) под 1С + Apache (1C WEB).
3. Mikrotik RB2011iL-IN в ядре сети.
4. 80 машин на Core2Duo 2.6GHz и 4Гб RAM в качестве рабочих мест на Win7 + антивирус и закрытые права для пользователей.
Как VDI улучшит положение? Как по мне текущая конфигурация даже удобнее и безопаснее для удалённой работы. А может улучшит достаточно легковесный дистрибутив Линукс внедрить + Ansible для оркестрации хостами. Если и обновлять машины, то только тем, кому это действительно нужно. Если нужно всем, то VDI всё равно не поможет, потому что нужно будет закупить реально много очень мощных серверов.
Там где до сих пор внедряют 1С + Терминал — надо по рукам бить. Там где это исторически сложилось — обновляться. Но вкладываться в новые сервера ради оркестрации — мне кажется сомнительной идеей.
Есть 19 стойка, есть UPS, есть пару серверов (1с, терминал, AD, ...) и это называется колхоз.
Так же мне не совсем понятно куда переедет 1С? Если под него брали такую мощь, что равносильно 30ПК с i3 (условно разделил), то непонятно где он будет теперь.
Тогда уж загрузка по PXE больше проблем решит с заменой блока у бухгалтера.
Проще говоря как я вижу: VDI никак не сэкономит деньги при обновлении, но может только улучшить ситуацию с гибкостью развёртывания и внедрения новых рабочих мест (по аналоги с Kubernates для веб-сервисов). Но стоить будет так же, а чаще всего и дороже. Уровень безопасности никак не улучшит (угроза шифровальщика остаётся при том же уровне безопасности). Никак тоже не защитит от смерти серверов, компов и «друзей из органов».
Есть ситуации, когда VDI может помочь, например, для разработки графики (NVidia Tesla), хотя как написали в комментах ниже, это тоже не панацея, или когда лицензия идёт на сервер, хотя сейчас с лицензиями тоже стараются закрутить гайки в этом вопросе. Но чаще все всего внедрение VDI делается там, где можно было бы сделать иначе, лучше и удобнее.
При VDI замена системного блока с сохранением всех данных дело 15 минут.
Вот мне интересно — почему когда говорят о рисках «VDI vs Standalone» никто не учитывает риски смерти сервера(ов)? Я понимаю, когда говорят о VDI как об удобном инструменте оркестрации (ведь действительно удобно), но когда говорят, что VDI сокращает риски, то говорят однобоко. Да, сервера умирают реже (зачастую), но по факту, когда они погибают, то страдает значительно больший сегмент предприятия.
Но, предположим что у вас есть 100 компьютеров, которые морально устарели и их надо обновлять до уровня i3 8г 500т = 30к (за 1 блок) по скромному.
А сервера морально не устаревают? А покупка новых сильно дешевле (чтобы 100 виртуалок аналогичной производительности держать)?
Как это помогает, когда они нашли ваш сервер (ферму)? Это выльется в ещё больший простой и потери (вы пробовали когда-нибудь диски вернуть?) Консолидация и безопасность не сильно совместимые вещи. IMHO: Лучше всего это решается как раз децентрализацией + быстрое автоматизированное развёртывание (в том числе из бэкапов).
Мне кажется если идею автора продлить и строить модели (классы) клеток на Python, то можно было бы тесты гонять и без физической лаборатории. Но для этого нужно было бы о-о-очень много данных собрать и разработать такую модель, которая именно эти данные брала и описывала типичное взаимодействие. Понятно, что были бы и недостатки, но исследования двигались бы гораздо быстрее.
Мне думается, что это круто двинуло бы фарму вперёд и укрепило бы развитие ИТ в науке.
Думаю проблема глубже, чем просто передвинуть расписание на час. Допустим, у кого-то в 18:00 заканчивается рабочий день и максимум через час он дома. В 19:00 у него урок. Тут робот меняет расписание и занятие передвигается на 18:00. Недовольный клиент звонит/пишет и просит сделать как было, а это невозможно, потому что на это время занятие у другого студента, у которого время не менялось и ему удобно только в это время. А минусуют, подозреваю, за то, что человек не понимая специфики и сути проблемы, даёт совет.
Я видел комбинированное приспособление у китайцев: бокс, внутри которого 6 мощных дюпелей, которые при срабатывании отключали диск от внешнего питания и sata, пробивали пластины насквозь и подавали высокое напряжение.
Недостатками были размеры (как 4 диска), диски только встроенные и опасность ложных срабатываний (китайские же).
Думаю всё просто: автор оригинальной статьи думает, что использование облака сводится к созданию в нём руками VPC и совершенно не использует оркестрацию. Для таких целей использовать AWS/DO/etc действительно расточительно.
Ну всё же цель Framework'а не из голов разработчиков бардак убирать, а минимизировать его влияние. Без FWа простор для багов всегда больше. А бардак в головах нужно убирать ещё одним слоем соглашений внутри команды, просто меньшим (например, используем такой framework, такие инструменты и так располагаем файлы). Проще говоря определяем стек.
А что мешало им всю оркестрацию на Ansible тогда сделать? Получилось бы тоже самое, но с большей производительностью (если bare-metal активнее использовать) и переезд в «облако» будет гораздо дешевле в будущем (например, на OpenStack или AWS). Притом не было бы такого лютого vendor-lock на k8s.
UPD: как подметил rsashka да, это я напутал с терминами. только что перепроверил.
Чисто технически, если есть свидетели, то даже устный договор считается договором.
Но в данном случае это регулируется Гражданским кодексом РФ, а именно:
Даже если кошка нажала, то вы фактически соглашаетесь, потому что программа не может быть установлена легальным способом без согласия с текстом лицензии. В частности «ПИСЬМО МИНЭКОНОМРАЗВИТИЯ РФ ОТ 05.05.2009 N Д05-2235 о правомерности использовании субъектами малого бизнеса свободного программного обеспечения, распространяемого под лицензией GNU GPL различных версий.» разъясняет:
Я пожалуй добавлю это в статью.
Даже близко не так. Пользоваться они могут и для этого есть такое понятие как лицензия. Давайте вспомним что там написано про ответственность? Взять тот же GPLv3 или MIT. Все привыкли, что такие проекты можно использовать, собирать, распространять и даже форкать. Но почему-то, некоторые забыли, что автор не несёт какой-либо ответственности за продукт и вы используете его на свой страх и риск.
Ричард Столман как раз именно эту идею продвигал, что вы свободны использовать, а разработчик свободен от ответственности — всё честно.
Попахивает мазохизмом. Не важно какого рода баг — это не меняет того, что пользователь никакого ни юридического, ни морального права не имеет чего-то требовать от автора СПО.
Я думаю у вас не очень корректное сравнение. Более точным будет, если вы дадите вашему другу свою машину, в которой вы только перебрали двигатель, вложились и т.д., а он приедет и скажет: «Эй, чувак! Твоя машина отстой. У неё подлокотник справа слишком высоко. Исправь, а то я больше не буду у тебя брать машину.»
Одно дело, когда вы участвуете в жизни проекта, развиваете его и вы обнаружили какую-то критическую ошибку, которую не знаете как исправить. Вы пишите подробный step-to-reproduce, высказываете предположения где могла бы быть проблема и т.д.
Другое дело, если вы взяли уже собранный пакет, установили как зависимость и обнаружилось, что ваше приложение уязвимо из-за этой ошибки, и вы, вместо того, чтобы предложить исправление, начинаете писать автору гневно-требовательный issue, где требуете немедленного отчёта в том, почему автор ещё не закрыл эту уязвимость, ведь это вам так сильно нужно. И ладно если это ошибка. Иногда просто хочется какой-то функциональности, а она, оказывается, не планируется к внедрению в ближайшем будущем.
Я верю, что вы не относитесь ко второй категории, но простите — накипело. Всё желание в OpenSource выкладывать что-либо отбивают такие «кадры».
Вам не кажется, что проблему с единственным файлом в excel без бекапов VDI по факту и не решает?
Серьёзно? DevOps — это не методология и тем более не только разработки ПО.
Откуда
ересьискажённая информация?Передайте это роскомнадзору. Частное облако это уже другое дело, но там и ресурсов нужно соизмеримо много.
Рейд не панацея. Вышли из строя одновременно 4 SSD и рейд посыпался. Контроллер проглючило — рейд посыпался. Всё так или иначе приводит к единой точке отказа.
Вот реальный пример: частное облако на OpenStack+KVM+Ceph. Всё хранится в распределённой системе, контроллеры и compute-ноды с большим запасом. В один прекрасный момент у Ceph происходит беда в виде split-brain. Понятно, что ошибка была в том, что не отмониторили вовремя, но из 20 VPC удалось восстановить только одну. Единственное что спасло от реальных потерь — распределённое дублирование ресурсов (git — это был отдел разработки). На всех компах по прежнему была копия данных, что позволило легко с нуля поднять всё.
Всё не так однозначно. Эти риски нужно так же учитывать, а значит и закладывать бюджет. Так, получается, что экономичным это решение не назовёшь. Но я ещё раз уточняю, что я не утверждаю, что это решение 100% не правильное и неудобное.
Но это не «серебрянная пуля» и, особенно для SMB, не всегда правильное решение.
Привет от Роскомпозора и Телеги. Опять же рубанули интернет в офисе — весь офис встал. VDI вообще никак не решает проблему вандалоустойчивости, особенно на сторонних ресурсах зависимых от канала связи.
А эта коробочка бесплатная что ли? Их стоимость соизмерима со стоимостью нормального компа. Есть такие же небольшие и достаточно удобные мини-PC, которые так же могут лежать с подготовленной системой, либо PXE.
Вы опускаете очень много этапов и деталей: покупку этих тонких клиентов, переход на VDI, стоимость лицензий, стоимость серверов (которые так или иначе придётся брать), отказоустойчивость, единая точка отказа и т.п.
Вырубили свет/интернет в центральном филиале — простой в двух остальных.
То что у них штат раздут и никакой автоматизации это не признак того, что VDI их спасёт. Скорее ещё админа для VDI возьмут или на кого-то ответственность установят + зп поднимут («ага, щас»), но штат не поменяют.
Откуда такие числа? С головы? В реальности другие совсем и с минусом впереди.
Взять ту же 1С-WEB. Я не большой сторонник 1С, но в целом она работает через браузер и с мобилки, и с Линукс, и с Mac, и с Форточек. А если добавить OnlyOffice, то будет и CRM, и Word/Excel, и централизованное хранилище документов, и почтовый сервер/клиент. Более того — всё через один защищённый порт 443 (если настроить https). Да и с доступом проще: зашёл на портал и всё. Никаких корявых RDP или VNC.
Мне кажется вы рассматриваете какой-то очень богатый колхоз, где стоят реально мощные сервера без дела и реально большие проблемы с безопасностью. Не говоря уже о том, что приводите в пример единственно правильный сценарий, хотя всё бывает не только как у вас.
Как, например, такой вариант:
1. 2 относительно небольших сервера (24C на Socket604 и 64ГБ RAM) на Linux под БД PostgreSQL.
2. 2 совсем небольших сервера (8С и 32ГБ Ram) под 1С + Apache (1C WEB).
3. Mikrotik RB2011iL-IN в ядре сети.
4. 80 машин на Core2Duo 2.6GHz и 4Гб RAM в качестве рабочих мест на Win7 + антивирус и закрытые права для пользователей.
Как VDI улучшит положение? Как по мне текущая конфигурация даже удобнее и безопаснее для удалённой работы. А может улучшит достаточно легковесный дистрибутив Линукс внедрить + Ansible для оркестрации хостами. Если и обновлять машины, то только тем, кому это действительно нужно. Если нужно всем, то VDI всё равно не поможет, потому что нужно будет закупить реально много очень мощных серверов.
Там где до сих пор внедряют 1С + Терминал — надо по рукам бить. Там где это исторически сложилось — обновляться. Но вкладываться в новые сервера ради оркестрации — мне кажется сомнительной идеей.
Так же мне не совсем понятно куда переедет 1С? Если под него брали такую мощь, что равносильно 30ПК с i3 (условно разделил), то непонятно где он будет теперь.
Тогда уж загрузка по PXE больше проблем решит с заменой блока у бухгалтера.
Проще говоря как я вижу: VDI никак не сэкономит деньги при обновлении, но может только улучшить ситуацию с гибкостью развёртывания и внедрения новых рабочих мест (по аналоги с Kubernates для веб-сервисов). Но стоить будет так же, а чаще всего и дороже. Уровень безопасности никак не улучшит (угроза шифровальщика остаётся при том же уровне безопасности). Никак тоже не защитит от смерти серверов, компов и «друзей из органов».
Есть ситуации, когда VDI может помочь, например, для разработки графики (NVidia Tesla), хотя как написали в комментах ниже, это тоже не панацея, или когда лицензия идёт на сервер, хотя сейчас с лицензиями тоже стараются закрутить гайки в этом вопросе. Но чаще все всего внедрение VDI делается там, где можно было бы сделать иначе, лучше и удобнее.
Вот мне интересно — почему когда говорят о рисках «VDI vs Standalone» никто не учитывает риски смерти сервера(ов)? Я понимаю, когда говорят о VDI как об удобном инструменте оркестрации (ведь действительно удобно), но когда говорят, что VDI сокращает риски, то говорят однобоко. Да, сервера умирают реже (зачастую), но по факту, когда они погибают, то страдает значительно больший сегмент предприятия.
А сервера морально не устаревают? А покупка новых сильно дешевле (чтобы 100 виртуалок аналогичной производительности держать)?
Мне думается, что это круто двинуло бы фарму вперёд и укрепило бы развитие ИТ в науке.
Недостатками были размеры (как 4 диска), диски только встроенные и опасность ложных срабатываний (китайские же).