Мне показалось, что ваша серия статей о процессорах Эльбрус несколько предвзята (я три дня гналась за вами, чтобы сказать, как вы мне безразличны как ваша архитектура неудачна).
Тем временем. Я не припомню, чтобы где-то заявлялось о завоевании рынка Intel/AMD. Напротив. Все заявления крутятся вокруг специализированных решений для государства/бизнеса. Если компания не ставит себе таких задач, то может не стоит от неё ждать преодоления воображаемых рубежей?
Я подверился и посмотрел свежее видео (https://www.youtube.com/watch?v=OXN_YfbfeBg&t=1219s), где все тезисы (звучащие многие года) остались прежними. Из изменении для себя отметил: появление СХД, работа в энергетике/газотранспорте, ноутбуки и т.д.
Давайте не будем «драматизировать» раньше времени. Процессоры, это ведь не только архитектура в вакууме, но и технологические решения и производственные мощности. Развернуть диван в сторону x86 всегда можно, особенно когда компетенции «вдруг» появились.
Думал много раз по поводу этого всего. Цифровые «кладбища» с «поверенными» нужны.
Еще лучше, если будет специальный межсервисный API и offline пункт, куда можно прийти со своим аппаратным токеном, который оповестит нужных людей и/или опубликует данные. Если вкратце.
Да, согласен. Если все будут делать с первого раза и качественно — будет хорошо. Но суровая реальность говорит нам об обратном.
Я же писал про случаи, когда вот такая станция уже размещена и требуется исправить ситуацию с шумом. Гораздо проще установить шумозащитный экран, чем закупать новое оборудование и терять в прибыли/доставлять неудобства абонентам.
А что, все остальные варианты решения проблемы исчерпаны? Только закупка более качественного оборудования самой базовой станции? А как же шумозащитные экраны и другие подобные варианты?
en.wikipedia.org/wiki/Language_Server_Protocol как отправная точка
PS я ожидал ИДЕ для управления серверами, доступами, облаками и прочим девопсом, навороченная консоль. Как датагрип для ДБА только для девопсов.
Я начинаю понимать. Вы спроецировали свои желания иметь универсальный инструмент для разных вендоров, чтобы всё это было удобно/бесшовно.
Не буду повторяться — это не отвечает реальности — перечитайте мой комментарий выше.
PS. Сам я буду использовать того вендора (платить ему деньги), который даст мне наиболее удобный инструмент. Ждать, когда появится «универсальный универсал» с поддержкой всех и вся — не намерен.
Не понимаю о каких стандартах вы говорите (можно пример?), но что нам «говорит» реальность:
CS развивается семимильными шагами, инструментов очень много. Если в условном начале 2000-х их было совсем мало, то теперь проблема выбора продукта встала в полный рост. Какие стандарты могут появляться в столь динамичной среде? Насколько они будут актуальны, кто будет владелец и в какой стране они будут приниматься, какие гарантий развития и взаимодействия с сообществом?
То есть, если договориться по поводу протоколов трансграничного сетевого взаимодействия и геометрии шлюзов МКС мы еще как-то можем, то принимать какие-то стандарты в крайне динамичной среде со множеством участников — затея абсолютно нежизнеспособная (собственно, мы это наблюдаем сейчас).
Я не говорил, что это будет просто. Я говорил, что такие мысли возникнут при обновлении/покупке новых лицензий.
PS. Миграции тоже бывают разные, маленькой команде достаточно сдампить и импортировать нужное. Для больших — заморозка в RO существующих инструментов и перекатывание на новое место. Всё очень сильно зависит от.
Меня тревожит немного другое. Как бы вся эта политизированная движуха вокруг России не сыграла дурную шутку (нечестная конкуренция/протекционизм) с продуктами Jetbrains. Тьфу-тьфу-тьфу.
Время всё рассудит, но, имхо, при следующей итерации покупки/обновления лицензий многие подумают — «а нафига нам этот зоопарк, давайте попробуем Space, соседская тима пищит уже с год как ...».
В этом как раз и проблема. Все те, кто участвует в разработке вынуждены фокусироваться на разных инструментах (коих стало миллион). Лично мне было бы удобно начинать свои рабочий день в одно месте, где есть всё необходимое.
Теперь остается узнать насколько Space будет удобна в использовании (по коммиту протестировалось/отдеплоилось/откатилось/оповестило при фейле/выкатилось по записи в каледаре) и т.д.).
Всё очень и очень просто. Разработчикам Kubernetes/Openshift категорически надоело исправлять то, что с легкой руки ломал Docker в угоду своим целям. Предпосылки по замене runtime были еще до CRI-O. Сам Docker, выпустив джина из бутылки, всячески пытается запргынуть в уходящий поезд оркестрации контейнеров (попытки слабые, если честно).
Я, в своё время, получил ответ на канале IRC openvpn-dev. Суть всего этого:
1. Клиент соединяется с первым сервером из списка
2. На сервере запускается скрипт проверки клиента, если клиент соотвествует — пропускаем, если нет — отлуп.
3. Если отлуп пришел «понятный», то клиент мужественно пытается переподключиться к этому же серверу, если же отлуп «неизвестен», то клиент отчаявшись переходит к следующему серверу.
В более старых версиях OpenVPN клиент при получении любого отлупа переходил к следующему серверу, но с какой-то версии разработчики поменяли поведение, поэтому стоит начать с release notes к продукту.
Статичное количество клиентов на сервер и «балансировка» с помощью DNS — это не самое лучшее решение. В своё время решал аналогичную задачу для 1k+ клиентов. Это долгая история, но стоит упомянуть, что клиент OpenVPN будет переподключаться к следующему сереверу из списка при получении неизвестного control message от сервера (магия), то есть можно организовать централизованное управление подключениями клиентов (со временем доступа, весами/weight для серверов, отозванными сертификатами, гео перераспределением и т.д. и т.п.).
Если же вы спрашиваете о сихронизации самого теста в коде Robot Framework и описания теста в Testlink — это непрерывный процесс. Изменился функционал ПО -> измени тест -> измени описание к тесту.
Собственно, вопрос в том, как часто приходится «синхронизировать» код тестов и TestLink?
Не до конца понял суть вопроса, но:
1. Код теста не хранится в Testlink, совсем. В Testlink хранится только детальное описание теста + метка теста, которая совпадает с названием теста в Robot Framework. Testlink стоит рассматривать как «органайзер» тестов/тест-планов/платформ/отчётов и т.д. и т.п.
2. В Robot Framework можно «вести документацию», но это совершенно не репрезентативно + не отвечает требованиям ведения процесса тестирования.
Не было ли у вас странных желаний попробовать завести openvswitch вместо switchdev ?
как вы мне безразличныкак ваша архитектура неудачна).Тем временем. Я не припомню, чтобы где-то заявлялось о завоевании рынка Intel/AMD. Напротив. Все заявления крутятся вокруг специализированных решений для государства/бизнеса. Если компания не ставит себе таких задач, то может не стоит от неё ждать преодоления воображаемых рубежей?
Я подверился и посмотрел свежее видео (https://www.youtube.com/watch?v=OXN_YfbfeBg&t=1219s), где все тезисы (звучащие многие года) остались прежними. Из изменении для себя отметил: появление СХД, работа в энергетике/газотранспорте, ноутбуки и т.д.
Давайте не будем «драматизировать» раньше времени. Процессоры, это ведь не только архитектура в вакууме, но и технологические решения и производственные мощности. Развернуть диван в сторону x86 всегда можно, особенно когда компетенции «вдруг» появились.
Еще лучше, если будет специальный межсервисный API и offline пункт, куда можно прийти со своим аппаратным токеном, который оповестит нужных людей и/или опубликует данные. Если вкратце.
Я же писал про случаи, когда вот такая станция уже размещена и требуется исправить ситуацию с шумом. Гораздо проще установить шумозащитный экран, чем закупать новое оборудование и терять в прибыли/доставлять неудобства абонентам.
Я начинаю понимать. Вы спроецировали свои желания иметь универсальный инструмент для разных вендоров, чтобы всё это было удобно/бесшовно.
Не буду повторяться — это не отвечает реальности — перечитайте мой комментарий выше.
PS. Сам я буду использовать того вендора (платить ему деньги), который даст мне наиболее удобный инструмент. Ждать, когда появится «универсальный универсал» с поддержкой всех и вся — не намерен.
CS развивается семимильными шагами, инструментов очень много. Если в условном начале 2000-х их было совсем мало, то теперь проблема выбора продукта встала в полный рост. Какие стандарты могут появляться в столь динамичной среде? Насколько они будут актуальны, кто будет владелец и в какой стране они будут приниматься, какие гарантий развития и взаимодействия с сообществом?
То есть, если договориться по поводу протоколов трансграничного сетевого взаимодействия и геометрии шлюзов МКС мы еще как-то можем, то принимать какие-то стандарты в крайне динамичной среде со множеством участников — затея абсолютно нежизнеспособная (собственно, мы это наблюдаем сейчас).
PS. Миграции тоже бывают разные, маленькой команде достаточно сдампить и импортировать нужное. Для больших — заморозка в RO существующих инструментов и перекатывание на новое место. Всё очень сильно зависит от.
PS. Намекаю на случай с Gitlab.
Теперь остается узнать насколько Space будет удобна в использовании (по коммиту протестировалось/отдеплоилось/откатилось/оповестило при фейле/выкатилось по записи в каледаре) и т.д.).
1. Клиент соединяется с первым сервером из списка
2. На сервере запускается скрипт проверки клиента, если клиент соотвествует — пропускаем, если нет — отлуп.
3. Если отлуп пришел «понятный», то клиент мужественно пытается переподключиться к этому же серверу, если же отлуп «неизвестен», то клиент отчаявшись переходит к следующему серверу.
В более старых версиях OpenVPN клиент при получении любого отлупа переходил к следующему серверу, но с какой-то версии разработчики поменяли поведение, поэтому стоит начать с release notes к продукту.
Не до конца понял суть вопроса, но:
1. Код теста не хранится в Testlink, совсем. В Testlink хранится только детальное описание теста + метка теста, которая совпадает с названием теста в Robot Framework. Testlink стоит рассматривать как «органайзер» тестов/тест-планов/платформ/отчётов и т.д. и т.п.
2. В Robot Framework можно «вести документацию», но это совершенно не репрезентативно + не отвечает требованиям ведения процесса тестирования.