Господа, а никому еще не приходила в голову идея, что к сотруднику можо попробовать относится как к человеку, с которым вы совместно/коллективно занимаетесь определенной деятельностью, а не как к животному, которое нужно просто правильно дрессировать?
Внезапно, но в IT большинство работающих достаточно интеллектуально развиты, чтобы выкупать все эти ваши методы манипуляций и дрессировки.
Прошу меня заранее простить, но хочется высказать крайне непопулярное мнение и немножко набросить на вентилятор. Прошу понять и простить. Не бейте сильно.
constexpr - это лучшее и, вместе с тем, худшее что случилось с языком за последнее десятилетие. Дело в том, что вычисления функций во время компиляции - это ценная оптимизация, которая должна поддерживаться на уровне компилятора, но никак не на уровне языка программирования. constexpr не дает программисту ничего с точки зрения выражения семантики реализуемых алгоритмов, и вместо этого дает инструмент для ручного управления оптимизацией кода и целый спектр вопросов, которые можно спрашивать на собеседованиях, для решения проблемы, которую компилятор может решать автоматически без участия программиста.
Подробнее можно познакомится с темой тут: https://0x1.tv/Constexpr_%E2%80%94_%D0%B1%D0%BE%D0%BB%D1%8C%D1%88%D0%BE%D0%B5_%D0%B1%D0%BB%D0%B0%D0%B3%D0%BE,_%D0%B2%D1%8B%D1%80%D0%B0%D0%B6%D0%B5%D0%BD%D0%BD%D0%BE%D0%B5_%D0%B2_%D0%BD%D0%B5%D0%BF%D1%80%D0%B0%D0%B2%D0%B8%D0%BB%D1%8C%D0%BD%D0%BE%D0%B9_%D0%B8%D0%B4%D0%B5%D0%B5_(%D0%95%D0%B2%D0%B3%D0%B5%D0%BD%D0%B8%D0%B9_%D0%9A%D0%BB%D0%B8%D0%BC%D0%B5%D0%BD%D0%BA%D0%BE%D0%B2,_ISPRASOPEN-2019) https://ieeexplore.ieee.org/document/8991150 (sci-hub.st вам в помощь)
так же вскоре появится статья по этой же теме с конференции IEEE CSIT 2021.
Ключевой ресурс для таких производств — это высококвалифицированные кадры. Где вы их возьмете в большом объеме в Индии? Как вы заставите существующих специалистов переехать в Индию? Такие фабрики строят и будут строить в районах крупных научно-образовательных центров.
Не все так просто. То на что вы ссылаетесь — это MBR-загрузчик. И он только первое звено в достаточно длинной цепочке загрузчиков и компонентов инициализации системы. Но как вы верно заметили, основные трудозатраты пойдут не на загрузчики, а на саму ОС. На ее адаптацию под новый набор команд. В ядре всегда есть куча ассемблера и всяческих интринсиков, так как оно по-умолчанию процессоро-зависимо. И вот перенастроить это все на новую архитектуру не так-то легко.
У меня к вам есть один очень странный вопрос: Вы специально отсеиваете капчами пользователей (не роботов), у которых стоит англоязычная версия ОСи и, соответственно, нет русской раскладки клавиатуры? Я вот был очень удивлен пытаясь как-то зайти к вам с неместного компьютера и просьбу ввести для капчи русское слово «аккумулятор». Может давайте сразу будем просить вводить китайские иероглифы или какие-нибудь символы тувимского алфавита? Ну чтобы уже наверняка только избранные могли к вам попасть?
Или же это все таки сознательный шаг и вы строите свой сервис с лозунгами «Русский посиковик — только для русскоязычных пользователей! Чемодан — вокзал — Google!»
Граждане, а почему в серьез не рассматривается идея бойкота участников сей эпопеи?
Насколько я понимаю, подавляющее большинство рассматривает разворачивающуюся драму даже не столько как атаку на конкретно Игоря Сысоева, но как атаку на всю индутрию в лице айтишников. Почему тогда и не ответить, не защитить себя всем миром? Предлагаю объявить тотальный байкот всем участникам сей эпопеи и всем кто за ней стоит, до кого сможем докопаться. Предлагаю каждому рассмотреть те варианты, которыми лично он может надавить/сделать больно агрессору. Тем кто пользуется прямо или опосредованно сервисами/услугами Рамблера рассмотреть возможность отказа от сотрудничества с ними. Тем кто предоставляет услуги Рамблеру — сделать тоже самое. Тем кто работает на Рамблер рассмотреть возможность перехода на другие места работы, а тем компаниям, которые проявляют сочувствие к ситуации по-возможности оказать содействие тем, кто будет уходить с Рамблера.
В дополнение к этому, предлагаю создать публичный сайт/сервис на защищенном ресурсе, где провести публичное расследование и выявить всех причастных лиц заказчиков/исполнителей/участников и вести их реестр на сайте. Создать этакий публичный черный список для лиц и компаний с испорченной репутацией не только для данного конкретного случая, но и для всех подобных случаев которые могут произойти в будущем. Таким образом сделать всю информацию максимально публичной и дать возможность всей индустрии давить на них всеми возможными способами. Те же IT-компании имея информацию о причастных к таким событиям будут иметь полную возможность адресно отказывать таким товарищам в услугах. Я думаю что если 90% тех же российских компаний по закрывают учетки и откажутся предоставлять услуги замазавшимся в грязи адвокатам, силовикам, заказчикам и т.д. то они дадут четкий сигнал о своем отношении к происходящему, и о том что отвечать в такой ситуации будут все. Не только заказчики но и исполнители.
Относительно самой компании. В случае реализации рейдерского захвата, все работники могут единомоментно уволиться просто бросив проект, и таким орбазом единомоментно обесценив как его так и компанию, и параллельно организовав компанию-клон в другой более дружественной юрисдикции.
Нужно дать понять, товарищам, что IT-индустрия, как профессиональное сообщество, в случае агрессии в ее сторону, будет отвечать не менее агрессивно. А еще лучше, дать понять что она будет отвечать на агрессию в свою сторону еще большей агрессией, вплоть до полного уничтожения агрессора. И таким образом, дать им понять что мы способны дать сдачи даже государству, сделать очевидным для всех, что такие агрессивные акции будут лишены смысла и даже очень не выгодны всем участникам.
Более того, если каждый согласится участвовать в этом движении, то в виду отсутствия организации и слабой координации всех участников, с нами будет практически невозможно бороться в ответ, потому что придется бороться со всеми сразу, что подобно вырезанию себе апендицита бензопилой без наркоза.
Вы кажется не улавливаете суть. Фактически, концепция unikernel меняет представление об организации вычислительного процесса. Это новая абстракция, которая уровнем выше чем процесс, и фактически объединяет совокупность процессов + «ядро», которые на самом деле реализуют один высокоуровневый сервис. Та же база данных как пример. Зачастую заводят целый физический сервер исключительно под БД. Но кроме самой БД туда входит ядро ОС, драйвера сетевого и дискового стека, сервисы, какие-то обслуживающие приложухи и утилиты, мониторинг тот же и т. д. плюс целый веер библиотек. Де факто, все они реализуют один мегасервис — БД. Вот идея unikernel это выделись весь этот зоопарк ПО который реализует БД и запаковать его в одно мегаприложение, попутно сняв по сути не особо нужную в таком случае изоляцию и тесно слинков и соптимизировав получившееся чудо. И вот это чудо — это что-то среднее между виртуальной машиной, контейнером и приложением.
С точки зрения надежности. Посмотрите на unikernel с перспективы вот этого вот конечного мегасервиса. Вам как клиенту без разницы почему оно крэшнулось. Из-за kernel panic или из-за ошибки в glibc или из-за бага в самой БД. Во всех случаях конечный результат один — сервис недоступен. Поэтому и нет особо большого смысла в изоляции между компонентами мегаприложения.
С точки зрения безопасности будет та же картина. Если ваше мегаприложение скомпрометировали со стороны «пользователя» — сервис попал к хакеру. Со стороны ядра — тоже самое. Да, есть всяческие нюансы, но в целом ситуация такая. Но! Как бы и с какой стороны не было скомпрометировано ваше мегаприложение, оно изолировано от других мегаприложений. То есть получив БД хакеру будет ну очень сложно пролезть в параллельно работающий на той же физической машине web-сервер. Даже если он смог залезть в «ядро» в БД.
Зато с точки зрения эффективности:
1) Низкий уровень абстракций ресурсов даваемых хостом unikernel-у позволяет всячески извращаться со стороны приложения (кастомные файловые системы и сетевые протоколы вам в руки).
2) Отсутствие изоляции может очень сильно снизить накладные расходы (в разы).
3) Тесная линковка и кросмодульная оптимизация может дать дополнительный прирост производительности.
Так что идея хоть и совершенно не новая (http://cnp.neclab.eu/projects/lightvm/lightvm.pdf) и корнями тянется вот аж сюда в 1995 год (https://pdos.csail.mit.edu/6.828/2008/readings/engler95exokernel.pdf), но вполне себе имеющая смысл. Особенно для всяких серверов и сложных апликух.
Однако! Говорить об unikernels как о замене того же монолита (Linux) имеет мало смысла. Потому что ОС смотрит как весь компьютер и думает как организовать вычисления на нем годным образом (мультиплексирование ресурсов, защита между приложениями и т.д.), а unikernel смотрит на отдельное, пусть и большое и сложное, приложение/сервис, и думает как бы это так получше его организовать.
Тезис N1: Spectre (S) и Meltdown (M) являются прямым следствием роста сложности реализаций процессоров. Современный ЦПУ обладает сумасшедшим уровнем сложности. В частности, SM-уязвимость возникает на стыке казалось бы независимых компонентов: предсказание ветвлений, спекулятивное выполнение, кэширование, механизмы организации безопасности, механизмы организации адресных пространств. Их можно закрыть аппаратно. Но! Очень сложно гарантировать отсутствие подобных уязвимостей при сохранении текущего уровня сложности ЦПУ.
Тезис N2: Уязвимости типа SM можно закрыть программно на уровне ОС. SM дает возможность читать из той части адресного пространтства текущего процесса, которая принадлежит ядру. Соответственно, нужно сделать так, чтобы в этой части адресного пространтства не было критически важной информации. Соответственно:
Вариант а) Микроядро в основе системы. В истинных микроядрах в пространстве ядра нет ничего интересного для чтения вредоносом. Все что интересно, находится в адресных пространствах ДРУГИХ процессов, куда нужно сначала переключится. Так что туда с помощью SM не залезть
Вариант б) Для Linux-подобных систем. Ядро выгружается в свое отдельное виртуальное адресное пространство (свой процесс). В пользовательских процессах остается только заглушка, которая по системному вызову (прерыванию) производит переход в виртуальное адресное пространство ядра и передает туда же управление. Опять же, прощай SM.
Так что закрыть SM чисто программно можно на уровне ОС. НО! Это не дешево! Потери производительности будут значительными! Стоимость холосного системного вызова выростет как минимум в 5-10 раз. И на это еще наложится трэшшинг кэша и TLB. Так что совокупные потери производительности могут легко дойти до величин в районе в два раза.
А вот тут интересная заковыка получается. Если отойти немного от темы и оглянуться вокруг, то мы увидим философию с диалектикой Гегеля и синергетику, которые пытаются понять как развиваются системы. И вот они как раз почему то констатируют что все развивается от простого сложному. Просто есть условно говоря «плохая» сложность, которая всем мешает, и «хорошая» сложность, которая служит фунадентом, для построения систем нового порядка. Переход от вычислений на бумаге и счетах к компьютерам тоже ж по своей сути был увеличением сложности, но… на нем выросли целые отрасли, поменялись экономические модели и социальные отношения. Все стало проще? Отнюдь. Увеличение сложности еще не значит что это плохо.
У меня такой вопрос. Я занимаюсь академическими исследованиями. Соответственно у меня есть несколько закрытых, академических (читай некомерческих проектов), которые нигде и ни с кем не расшарены и над которыми работаю я сам. Могу ли я воспользоваться бесплатной лицензией PVS-Studio для них (по схеме описанной здесь — www.viva64.com/ru/b/0457)?
P.S.: Вроде могу, но хотелось бы получить какое-то более менее формальное подтверждение
Мое ЛИЧНОЕ мнение: лучшее что могут сделать разработчики стандарта С++ это либо разбить язык на модули либо принять идею «стандарт языка С++ не может быть больше 1000 страниц» как святую истину. Уже ну очень много всего намешано и все со своими нюансами присыпанное тоннами undefined behavior. Язык превращается в свалку. Человеку который говорит я знаю С++ можно смело плевать в лицо. Сам Страуструп не знает всех нюансов описанных на over 1500 страниц мелким шрифтом. И все добавляют и добавляют… Это хорошо что добавляют… Но очень-очень плохо, что не упорядочивают и не убирают.
Поясню конкретно, на что я жалуюсь. Статья называется «как устроен R&D процесс». Это именно тот вопрос который меня интересует. Я хочу узнать как организуется работа в R&D. Ну то есть в настоящем R&D где R не для красоты и понта. И… и я не вижу в статье вообще ничего про R&D, и уж тем более про то как оно организовано. Тема заявленная в заголовке — не раскрыта! На мой субъективный взгляд, происходит вот эта вот самая маркетинговая замена понятия «D» на «R&D». Как следствие — разочарование. Расскажите как у вас организована работа R&D, который настоящий, который дает патенты, знания, понимание, ноухау и т.д.
ремарка:
1) Я не имею ничего против и не могу сказать ничего плохого про саму компанию
2) Я не имею ничего против того как организован у вас процесс разработки и не пытаюсь его критиковать.
Я, таки дико извиняюсь, и не хочу показаться грубым, но… где собственно R&D? Или, как сейчас модно, букву R для красоты пририсовали? Где инновации? Новые технологии? Ноу-Хау? Патенты? Статьи? Конференции?
Я прочитал статью, потому что мне интересно именно, то что вы указали в заголовке: какие подходы/методологии используются при организации труда в R&D? А нашел банальный рассказ суть которого можно выразить тезисом «Veeam Software — хорошая компания. У нас есть процессы».
Господа, а никому еще не приходила в голову идея, что к сотруднику можо попробовать относится как к человеку, с которым вы совместно/коллективно занимаетесь определенной деятельностью, а не как к животному, которое нужно просто правильно дрессировать?
Внезапно, но в IT большинство работающих достаточно интеллектуально развиты, чтобы выкупать все эти ваши методы манипуляций и дрессировки.
Господа...
Прошу меня заранее простить, но хочется высказать крайне непопулярное мнение и немножко набросить на вентилятор. Прошу понять и простить. Не бейте сильно.
constexpr - это лучшее и, вместе с тем, худшее что случилось с языком за последнее десятилетие. Дело в том, что вычисления функций во время компиляции - это ценная оптимизация, которая должна поддерживаться на уровне компилятора, но никак не на уровне языка программирования. constexpr не дает программисту ничего с точки зрения выражения семантики реализуемых алгоритмов, и вместо этого дает инструмент для ручного управления оптимизацией кода и целый спектр вопросов, которые можно спрашивать на собеседованиях, для решения проблемы, которую компилятор может решать автоматически без участия программиста.
Подробнее можно познакомится с темой тут:
https://0x1.tv/Constexpr_%E2%80%94_%D0%B1%D0%BE%D0%BB%D1%8C%D1%88%D0%BE%D0%B5_%D0%B1%D0%BB%D0%B0%D0%B3%D0%BE,_%D0%B2%D1%8B%D1%80%D0%B0%D0%B6%D0%B5%D0%BD%D0%BD%D0%BE%D0%B5_%D0%B2_%D0%BD%D0%B5%D0%BF%D1%80%D0%B0%D0%B2%D0%B8%D0%BB%D1%8C%D0%BD%D0%BE%D0%B9_%D0%B8%D0%B4%D0%B5%D0%B5_(%D0%95%D0%B2%D0%B3%D0%B5%D0%BD%D0%B8%D0%B9_%D0%9A%D0%BB%D0%B8%D0%BC%D0%B5%D0%BD%D0%BA%D0%BE%D0%B2,_ISPRASOPEN-2019)
https://ieeexplore.ieee.org/document/8991150 (sci-hub.st вам в помощь)
так же вскоре появится статья по этой же теме с конференции IEEE CSIT 2021.
Ключевой ресурс для таких производств — это высококвалифицированные кадры. Где вы их возьмете в большом объеме в Индии? Как вы заставите существующих специалистов переехать в Индию? Такие фабрики строят и будут строить в районах крупных научно-образовательных центров.
У меня к вам есть один очень странный вопрос: Вы специально отсеиваете капчами пользователей (не роботов), у которых стоит англоязычная версия ОСи и, соответственно, нет русской раскладки клавиатуры? Я вот был очень удивлен пытаясь как-то зайти к вам с неместного компьютера и просьбу ввести для капчи русское слово «аккумулятор». Может давайте сразу будем просить вводить китайские иероглифы или какие-нибудь символы тувимского алфавита? Ну чтобы уже наверняка только избранные могли к вам попасть?
Или же это все таки сознательный шаг и вы строите свой сервис с лозунгами «Русский посиковик — только для русскоязычных пользователей! Чемодан — вокзал — Google!»
Насколько я понимаю, подавляющее большинство рассматривает разворачивающуюся драму даже не столько как атаку на конкретно Игоря Сысоева, но как атаку на всю индутрию в лице айтишников. Почему тогда и не ответить, не защитить себя всем миром? Предлагаю объявить тотальный байкот всем участникам сей эпопеи и всем кто за ней стоит, до кого сможем докопаться. Предлагаю каждому рассмотреть те варианты, которыми лично он может надавить/сделать больно агрессору. Тем кто пользуется прямо или опосредованно сервисами/услугами Рамблера рассмотреть возможность отказа от сотрудничества с ними. Тем кто предоставляет услуги Рамблеру — сделать тоже самое. Тем кто работает на Рамблер рассмотреть возможность перехода на другие места работы, а тем компаниям, которые проявляют сочувствие к ситуации по-возможности оказать содействие тем, кто будет уходить с Рамблера.
В дополнение к этому, предлагаю создать публичный сайт/сервис на защищенном ресурсе, где провести публичное расследование и выявить всех причастных лиц заказчиков/исполнителей/участников и вести их реестр на сайте. Создать этакий публичный черный список для лиц и компаний с испорченной репутацией не только для данного конкретного случая, но и для всех подобных случаев которые могут произойти в будущем. Таким образом сделать всю информацию максимально публичной и дать возможность всей индустрии давить на них всеми возможными способами. Те же IT-компании имея информацию о причастных к таким событиям будут иметь полную возможность адресно отказывать таким товарищам в услугах. Я думаю что если 90% тех же российских компаний по закрывают учетки и откажутся предоставлять услуги замазавшимся в грязи адвокатам, силовикам, заказчикам и т.д. то они дадут четкий сигнал о своем отношении к происходящему, и о том что отвечать в такой ситуации будут все. Не только заказчики но и исполнители.
Относительно самой компании. В случае реализации рейдерского захвата, все работники могут единомоментно уволиться просто бросив проект, и таким орбазом единомоментно обесценив как его так и компанию, и параллельно организовав компанию-клон в другой более дружественной юрисдикции.
Нужно дать понять, товарищам, что IT-индустрия, как профессиональное сообщество, в случае агрессии в ее сторону, будет отвечать не менее агрессивно. А еще лучше, дать понять что она будет отвечать на агрессию в свою сторону еще большей агрессией, вплоть до полного уничтожения агрессора. И таким образом, дать им понять что мы способны дать сдачи даже государству, сделать очевидным для всех, что такие агрессивные акции будут лишены смысла и даже очень не выгодны всем участникам.
Более того, если каждый согласится участвовать в этом движении, то в виду отсутствия организации и слабой координации всех участников, с нами будет практически невозможно бороться в ответ, потому что придется бороться со всеми сразу, что подобно вырезанию себе апендицита бензопилой без наркоза.
С точки зрения надежности. Посмотрите на unikernel с перспективы вот этого вот конечного мегасервиса. Вам как клиенту без разницы почему оно крэшнулось. Из-за kernel panic или из-за ошибки в glibc или из-за бага в самой БД. Во всех случаях конечный результат один — сервис недоступен. Поэтому и нет особо большого смысла в изоляции между компонентами мегаприложения.
С точки зрения безопасности будет та же картина. Если ваше мегаприложение скомпрометировали со стороны «пользователя» — сервис попал к хакеру. Со стороны ядра — тоже самое. Да, есть всяческие нюансы, но в целом ситуация такая. Но! Как бы и с какой стороны не было скомпрометировано ваше мегаприложение, оно изолировано от других мегаприложений. То есть получив БД хакеру будет ну очень сложно пролезть в параллельно работающий на той же физической машине web-сервер. Даже если он смог залезть в «ядро» в БД.
Зато с точки зрения эффективности:
1) Низкий уровень абстракций ресурсов даваемых хостом unikernel-у позволяет всячески извращаться со стороны приложения (кастомные файловые системы и сетевые протоколы вам в руки).
2) Отсутствие изоляции может очень сильно снизить накладные расходы (в разы).
3) Тесная линковка и кросмодульная оптимизация может дать дополнительный прирост производительности.
Так что идея хоть и совершенно не новая (http://cnp.neclab.eu/projects/lightvm/lightvm.pdf) и корнями тянется вот аж сюда в 1995 год (https://pdos.csail.mit.edu/6.828/2008/readings/engler95exokernel.pdf), но вполне себе имеющая смысл. Особенно для всяких серверов и сложных апликух.
Однако! Говорить об unikernels как о замене того же монолита (Linux) имеет мало смысла. Потому что ОС смотрит как весь компьютер и думает как организовать вычисления на нем годным образом (мультиплексирование ресурсов, защита между приложениями и т.д.), а unikernel смотрит на отдельное, пусть и большое и сложное, приложение/сервис, и думает как бы это так получше его организовать.
Тезис N1: Spectre (S) и Meltdown (M) являются прямым следствием роста сложности реализаций процессоров. Современный ЦПУ обладает сумасшедшим уровнем сложности. В частности, SM-уязвимость возникает на стыке казалось бы независимых компонентов: предсказание ветвлений, спекулятивное выполнение, кэширование, механизмы организации безопасности, механизмы организации адресных пространств. Их можно закрыть аппаратно. Но! Очень сложно гарантировать отсутствие подобных уязвимостей при сохранении текущего уровня сложности ЦПУ.
Тезис N2: Уязвимости типа SM можно закрыть программно на уровне ОС. SM дает возможность читать из той части адресного пространтства текущего процесса, которая принадлежит ядру. Соответственно, нужно сделать так, чтобы в этой части адресного пространтства не было критически важной информации. Соответственно:
Вариант а) Микроядро в основе системы. В истинных микроядрах в пространстве ядра нет ничего интересного для чтения вредоносом. Все что интересно, находится в адресных пространствах ДРУГИХ процессов, куда нужно сначала переключится. Так что туда с помощью SM не залезть
Вариант б) Для Linux-подобных систем. Ядро выгружается в свое отдельное виртуальное адресное пространство (свой процесс). В пользовательских процессах остается только заглушка, которая по системному вызову (прерыванию) производит переход в виртуальное адресное пространство ядра и передает туда же управление. Опять же, прощай SM.
Так что закрыть SM чисто программно можно на уровне ОС. НО! Это не дешево! Потери производительности будут значительными! Стоимость холосного системного вызова выростет как минимум в 5-10 раз. И на это еще наложится трэшшинг кэша и TLB. Так что совокупные потери производительности могут легко дойти до величин в районе в два раза.
У меня такой вопрос. Я занимаюсь академическими исследованиями. Соответственно у меня есть несколько закрытых, академических (читай некомерческих проектов), которые нигде и ни с кем не расшарены и над которыми работаю я сам. Могу ли я воспользоваться бесплатной лицензией PVS-Studio для них (по схеме описанной здесь — www.viva64.com/ru/b/0457)?
P.S.: Вроде могу, но хотелось бы получить какое-то более менее формальное подтверждение
Поясню конкретно, на что я жалуюсь. Статья называется «как устроен R&D процесс». Это именно тот вопрос который меня интересует. Я хочу узнать как организуется работа в R&D. Ну то есть в настоящем R&D где R не для красоты и понта. И… и я не вижу в статье вообще ничего про R&D, и уж тем более про то как оно организовано. Тема заявленная в заголовке — не раскрыта! На мой субъективный взгляд, происходит вот эта вот самая маркетинговая замена понятия «D» на «R&D». Как следствие — разочарование. Расскажите как у вас организована работа R&D, который настоящий, который дает патенты, знания, понимание, ноухау и т.д.
ремарка:
1) Я не имею ничего против и не могу сказать ничего плохого про саму компанию
2) Я не имею ничего против того как организован у вас процесс разработки и не пытаюсь его критиковать.
Я прочитал статью, потому что мне интересно именно, то что вы указали в заголовке: какие подходы/методологии используются при организации труда в R&D? А нашел банальный рассказ суть которого можно выразить тезисом «Veeam Software — хорошая компания. У нас есть процессы».
Я разочарован.