Поделитесь списком компаний, если имеется — ну, чтобы туда не ходить на собеседования.
По факту — никто не расшифровывает HTTPS с подменой посередине сейчас, обычно просто black/whitelist держат. В век BYOD было бы странно наблюдать иное.
1. Правильно иметь тестовую машину такой же, как машину, на которую будете устанавливать роль. По этой причине плохо подходит вагрант — многовато отличий. Если у вас linux — поставьте один раз ubuntu в kvm и потом просто делайте с нее копии/снапшоты и на них тестируйте. Если у вас мак — один раз поставьте руками virtualbox и настройте в нем машину с сетью, потом копируйте ее и тестируйте на копиях. Это, конечно, не так просто, как сказать vagrant up, но зато вы не будете потом иметь неясного происхождения геморрой с запуском плейбуков.
2. Это зависит от того, что и как вам нравится устанавливать. Можно в pre_tasks его держать, можно в отдельном файле и импортировать.
3. Потому что до этого apt вызывается только если нужно устанавливать python и при этом явно зовется apt update. Его и не нужно раньше звать просто.
4. Можно не вызывать --sh, а зафиксировать версию munin, которую ставите и сделать все ln -sf, которые он вызывает, через модуль file. Это правильнее, потому что избежите ненужных changed, да и вообще неопределенного поведения, если вдруг версия munin обновится внезапно.
5. Дампы БД очень изменчивы. Обычно они нужны, если вы мигрируете с одного сервера на другой. На практике это довольно редкое занятие и я, например, делаю такие вещи руками — настолько нечасто это нужно делать. Бинарники — тут кто во что горазд. Для Go становится модно тянуть собранный бинарник с гитхаба, например. Мне этот подход не очень нравится, но это лучше, чем положить блоб в репу. В идеале, конечно, бинарь должен быть упакован в пакет под нужную ОС, но это в идеализированном мире девопсов с понями так происходит, а на практике делают костыли.
Сделал ремонт и в натяжные потолки поставил GX53 Ecola. Всего 29 штук, 4 холодные, 25 теплых 8-ваттных. Все холодные в порядке. Из теплых поменял уже 6 и еще две уже перегорели. Ремонт доделал в октябре прошлого года. То ли Ecola такое днище, то ли днище те, кто вешал потолок (но я их знаю и они мне мамой клянутся, что все сделали ок).
Мой опыт отличается от вашего и показывает, что если у вас есть, к примеру, команда, которая занимается в основном автоматизацией OpenStack с помощью Puppet и вы ищете человека, который знает хорошо Ruby + Puppet и немного слышал об OpenStack и Python — так вот, даже если этот человек не ключевой, шансы его найти на рыночные деньги стремятся к нулю. А людей с уровнем ключевого разработчика даже совсем не на рыночные деньги в эту команду не пришло ни одного за несколько лет.
Я предположу, что когда у вас совсем стандартные требования из серии «нужен разработчик Python», то найти человека попроще. Но мы говорим про ключевых разработчиков — к ним эти требования неприменимы, как правило. Это обычно люди, которые могут реально тащить какой-то большой кусок проекта, по пути улюлюкая, присвистывая и говоря «а давайте-ка мы вот тут еще прикрутим вот такую клевую штуку и вон там порефакторим на досуге».
«Не сильно» — это довольно субъективно. Один человек владеет продуктами X,Y,Z и умеет убеждать людей. А второй знает продукт U и еще хорошо знает в целом предметную область. Кто более ценен? Имхо — тот, кто сейчас нужен, тот и более ценен. Если срез зарплат таких людей составляет N, то вы можете выбирать — или платить K<=N и ждать у моря погоды (я видел ожидание, длящееся годами), или платить M>N и повысить свой шанс. M — и есть «не по рынку».
Не бойтесь потерять ключевых разработчиков. В большинстве случаев потеря быстро компенсируется.
Это если вы лидер в индустрии (Яндекс в России, Uber в US, FB во всем мире). А если вы контора даже уверенная в себе, но не лидер — вы очень долго будете искать ключевых разработчиков. Или нужно будет платить не по рынку, или мотивировать тех, которые есть. Это я вижу из практики своей и своих коллег.
Как уже выше замечали, это не рейтинг лучших команий, а рейтинг на лучший маркетологический отдел среди компаний. Конечно же, «не стреляйте в пианиста, он играет как умеет», но я бы с удовольствием посмотрел на рейтинг, разбитый по:
Возрастным группам (потому что Яндекс в Москве очень хорош для студентов, например; EPAM в Петербурге интересен для молодежи, которая хочет переехать; Avito идеален для senior-девелоперов, которым не хочется никуда ехать и везти семью; JetBrains понравится тем, кто любит профессию по-настоящему);
Тем, кто работал в компании и тем, кто не работал + можно было бы добавить какие-то реальные мнения людей (так можно было бы узнать что, скажем, Яндекс — чемпионы велосипедостроения и девопсам там несильно нравится, но нравится разработчикам; что Grid Dynamics это компания одного проекта, но очень большого; что EPAM классные, но конкурсы нравятся не всем; что WarGaming известные, но определенным специалистам придется ехать в головной офис работать);
По уровню специалиста (это позволило бы увидеть, что в EPAM-е есть реальный карьерный рост; что Luxoft старается увезти architect-ов из России; что Яндекс набирает дикое количество middle-ов на средние зарплаты; что Rambler ведет очень своеобразную политику найма людей)
В общем, значительно лучше можно было бы сделать этот рейтинг, если бы не опрашивать людей с улицы о том, что происходит в их собственной компании или у их соседей, а грамотно разделить их на фокус-группы и потом уже задавать каждой группе вопросы.
Мне кажется, что все, кто пишет про вим и про то, что он плох, постоянно подводят к тому, что в нем неудобно писать большие программы. Я с этим полностью согласен. Но мне кажется, что вим хорош не для этого. Коротко обо мне — сейчас мою профессию модно называть словом DevOps, в последние годы я занимаюсь OpenStack-ом, постоянно что-то пишу на ansible/puppet/python/bash. Бывает, что надо поправить пару конфигов руками или изучить что-то новое (последнее, что пришлось изучить — MS Azure cli).
Мне приходится много всего тестировать. Надо поджойнить количество VM-ок и процент свободных ресурсов облака? Открываем IPython, начинаем. В соседней вкладке tmux-а записываем то, что показалось правильным и интересным. Накидали несколько функций, потестировали из консоли — окей, можно открыть PyCharm, начать писать нормальный код — с логированием, try/except, правильными наследованием и композицией. Но вот эти несколько функций в консоли удобнее накидать в vim, чем в nano, потому что из коробки в vim есть автоотступы для python. Можно переключать консоль сразу в IDE, но интерфейс очень уж разный, фокус теряется постоянно.
Идем дальше. Понадобилось написать новую роль для ansible. Помню, что можно как-то явно указать синтаксис из docker-compose для docker_service, но не помню точный синтаксис. Окей, открываем в виме соседнюю вкладку с ролью, которую я писал месяц назад и в которой был docker_service и смотря на нее на том же экране пишем нашу новую роль. Очень удобно — гуглить не надо, постоянно переключаться никуда не надо. Можно, наверное и в IDE так делать, но мне неизвестны люди, которые так на самом деле вообще делают. Копировать без мышки опять же, быстрее и удобнее.
Окей. Написали роль, давайте потестируем. Вот у нас ELK в ансибл ролях — конфиги, сертификаты, пайплайн паттерны для Logstash и т.д. Кучка сервисов. Запустили ансибл, развернулось, но работает явно не так, как ожидалось. По опыту — значительно быстрее пойти на удаленную тестовую машину и руками разобрать все, чтобы понять, что случилось а потом уже rsync-нуть изменения, поменять немного роль и запустить ее снова, нежели пытаться каждый раз менять саму роль, запускать ее и смотреть, угадал ли в этот раз с изменениями. А на удаленной машине опять vim, потому что json и снова отступы из коробки.
Идем дальше. Надо потестировать rspec-ом тесты для паппетного модуля. Но только вот тестов в модуле 4970, а мне надо только те тридцать, которые я сейчас написал (а потом уже только будем запускать все остальные, если мои новые не сломаны). Как из IDE это быстро сделать — я не знаю, а из консоли — знаю. И оказывается, что сделать небольшие правки из консоли в случае чего быстрее, нежели переключать фокус на GUI. И правки эти делаются vim-ом, потому что к нему можно линтер в два щелчка прикрутить, а к nano нельзя.
Продолжаем. Звонят коллеги, просят подебажить немного удаленный сервер. Говорят, что это не прод и можно прямо на нем править, чтобы понять, что не так (это вообще очень частый кейс). Идем. Там питоновый сервис и куча конфигов. И vim. Ну вы поняли — отступы из коробки, удобное копирование, свернуть его можно, команду запустить из консоли, не выходя, на нужную строку быстро перейти и т.д.
И вот для такого использования оказывается, что nano неудобный — там он отступы не сконвертировал из табов в пробелы, тут ошибка линтера закралась и т.д. А vim в самый раз. И везде есть. К тому же непонятно мне, какое я количество IDE должен купить себе буду, если все эти мелочи захочу в IDE править. А когда у тебя к vim-у есть еще git, tmux, zsh etc. — оказывается, что комплекс этих утилит по удобству перекрывает любую IDE, потому что нельзя написать IDE, которая будет делать все очень хорошо (JetBrains пытаются, да). Но можно написать много утилит, каждая из которых будет делать свою функцию идеально. Если вы программист, пишущий на одном языке и иногда что-то делающий в консоли — мне кажется, вам вполне позволительно обо всех этих утилитах не знать. Но в IT мире полно людей, для которых программирование — побочная деятельность и для них иногда vim удобнее.
А в свободное время я пишу на Java. И как это делать в vim — я не хочу даже знать. Android Studio скрывает все шероховатости, которые мне неинтересно изучать в рамках хобби.
На одной работе айтишником — наверное, нигде. Только вот дело не в том, сколько вы зарабатываете, а в том, сколько вы тратите на сопоставимые вещи в России и за рубежом. К тому же все почему-то идут очень легкими путями — «где я заработаю на одной работе, ходя в офис»? Ну, наверное, нигде. Это как спрашивать «как мне заработать на яхту, работая в Воронеже». Заработать можно, но зачем вам в Воронеже яхта?
Лично я 10 лет работал в Москве по профессии а потом, наработав связи и знакомства, устроился удаленно в несколько компаний. Куда-то физиком, где-то ИП открыл. Работаю примерно 8 часов в день, претензий у работодателей никаких нет (им надо, чтобы работа была сделана, а не чтобы я в офисе у них сидел), получаю около 80k$ на руки в год до всех расходов. Но я тут за 10 лет уже заработал на квартиры-машины-дачи для себя и семьи, у меня расходов-то на еду и семью только. Зато я могу путешествовать, ездить везде с семьей, показывать ребенку мир и выбирать, когда мне работать.
А теперь, когда мы поняли варианты, у меня к вам встречный вопрос — а где я в США могу так устроиться? Это вопрос риторический, на самом деле. Устроиться можно. Просто придется заново нарабатывать те же самые связи и знакомства и на это уйдет еще 10 лет. Но зачем мне это? Поэтому когда меня каждый новый знакомый спрашивает, почему я не уеду в США, то он сначала очень удивляется, когда узнает, что я уже уехал *ИЗ* США, а потом часто соглашается, когда я объясняю, что есть смысл переезжать интерном в гугл или твиттер после института и нет — сеньором после 10-15 лет опыта работы в России при условии, что ты живешь не в своем воображаемом вакууме, а в реальном социуме.
Часто еще возникает спор про то, что «там, у них» лучше социальный лифт. Но это не так и не везде. Да, в США, например, много хорошей инфраструктуры. При этом там, например, полно районов в городах, в которые ночью лучше и не заходить. Везде есть минусы и плюсы и поэтому однозначно говорить «вот там лучше, а тут хуже» нельзя. Лучше для вас — однозначно. Хуже для всех — точно нет.
>Я не вижу для себя никаких преимуществ, которые я получу овладев данным инструментом.
Вот тут можно было закончить, если бы вы это сразу написали. Я вижу для себя преимущества, овладев любым инструментом.
Можно писать в IDE, а потом заливать по sftp. Скорость будет страдать, разумеется. И чем чаще вы будете сохранять, тем больше она будет страдать. Из таких маленьких страданий складывается большая боль. Но это кому что нравится — я часто вижу у людей желание делать вещи каким-то конкретным способом и не хочу им продавать свой подход. Но как мне кажется, спорить, что редактирование прямо на удаленной машине ощутимо быстрее, чем копирование целого файла каждый раз на эту машину, бессмысленно. Я в IDE занимаюсь только разработкой, например и почти никогда — тестированием новых вещей.
Про все остальные операции — notepad++ не кроссплатформенный. И если вы им пользуетесь, то скорее всего, у вас интерфейс системы не очень подходящ под удобную работу по ssh. А так — он хороший, да. Почти как vim. Только с окошками и мышкой надо побольше тыкать.
Про кучу конфигов и что-то не так — ну это очень голословно. У меня на одной работе постоянная разработка у людей на ажуре. Вот часто бывает, что надо заспавнить новую виртуалку, но что-то подхачить под нужды для тестирования. Вот прямо каждый день такое бывает. Что ж мне, оркестрировать каждую виртуалку, которая и живет-то часто несколько часов всего?
Вы не договариваете. Там dd if=dev/zero of=/dev/{device} bs=1M count=1. Не то, чтобы я как бывший разработчик защищал свое детище или мне сильно нравилась идея затирать диски таким образом, но надо быть чуть более честным :)
Меж тем, Fuel-а больше нет, так что все это уже неважно.
Ну вот есть задача потестить новый фреймворк. Можно для этого запускать IDE, конечно. Но как быть в случае с пайтоном, например, если машина для разработки удаленная? Как подебажить опенстек на удаленном сервере? Можно, конечно, ковырять скрипты в тысячи строк с nano, но это просто не так удобно, как с vim, да и не везде есть nano (как и права на его установку), а vi 100% есть везде. Что делать, если надо написать небольшой модуль к Puppet, купить RubyMine? Как быстро поправить конфиг (выровнять строки, закомментить что-то)? Как быть, в конце концов, если редактируешь файл из nano, а sudo вызвать забыл? Абсолютно все вышеперечисленное можно делать без vi/vim, но когда вы делаете это в нем, вы не думаете обо всех этих сопутствующих проблемах, вы думаете только о том, как решить задачу. Может, такое сравнение понравится не всем, но это как печатать 10 пальцами — вы не думаете о кнопках, вы думаете только о том что вы хотите напечатать. Это позволяет концентрироваться и выполнять поставленную задачу лучше.
На этом ресурсе большинство уведет карму в глубочайший минус просто за то, что им кажется, что выдвинутое мнение не совпадает с их собственным — поэтому нет никакой разницы, что именно здесь приветствуется.
Скорее всего у вас достаточно узкая специализация. Первые 10 лет работы в unix-like операционных системах я тоже думал, что мне нормально живется без знаний vi/vim.
Вот интересно как раз понять, как onDiskSpace считается. Хотелось бы знать не только, сколько выделено диска (это можно и из бэкенда узнать, если там, например, OpenStack или просто Ceph), но и сколько его реально используется вмкой (потому что ни один бэкенд такой информации не даст, конечно же).
Ну вы просто представьте себе, что договор заключается не с одним человеком, а с семьей. Вот есть люди, их, скажем, мама, папа, дед иногда приезжает, два сына и дочь. Теперь поделите терабайт на 5 и внезапно окажется, что выкачать 200 гигов в одного не так уж и сложно. Я вот сериалы смотрю в FHD, фильмы в BD — это по 2 гига на серию и 40 гигов на фильм. Пять фильмов — пока-пока. Как-то не очень много, вам не кажется?
По факту — никто не расшифровывает HTTPS с подменой посередине сейчас, обычно просто black/whitelist держат. В век BYOD было бы странно наблюдать иное.
docs.ansible.com/ansible/latest/user_guide/playbooks_reuse_roles.html#embedding-modules-and-plugins-in-roles
1. Правильно иметь тестовую машину такой же, как машину, на которую будете устанавливать роль. По этой причине плохо подходит вагрант — многовато отличий. Если у вас linux — поставьте один раз ubuntu в kvm и потом просто делайте с нее копии/снапшоты и на них тестируйте. Если у вас мак — один раз поставьте руками virtualbox и настройте в нем машину с сетью, потом копируйте ее и тестируйте на копиях. Это, конечно, не так просто, как сказать vagrant up, но зато вы не будете потом иметь неясного происхождения геморрой с запуском плейбуков.
2. Это зависит от того, что и как вам нравится устанавливать. Можно в pre_tasks его держать, можно в отдельном файле и импортировать.
3. Потому что до этого apt вызывается только если нужно устанавливать python и при этом явно зовется apt update. Его и не нужно раньше звать просто.
4. Можно не вызывать --sh, а зафиксировать версию munin, которую ставите и сделать все ln -sf, которые он вызывает, через модуль file. Это правильнее, потому что избежите ненужных changed, да и вообще неопределенного поведения, если вдруг версия munin обновится внезапно.
5. Дампы БД очень изменчивы. Обычно они нужны, если вы мигрируете с одного сервера на другой. На практике это довольно редкое занятие и я, например, делаю такие вещи руками — настолько нечасто это нужно делать. Бинарники — тут кто во что горазд. Для Go становится модно тянуть собранный бинарник с гитхаба, например. Мне этот подход не очень нравится, но это лучше, чем положить блоб в репу. В идеале, конечно, бинарь должен быть упакован в пакет под нужную ОС, но это в идеализированном мире девопсов с понями так происходит, а на практике делают костыли.
Я предположу, что когда у вас совсем стандартные требования из серии «нужен разработчик Python», то найти человека попроще. Но мы говорим про ключевых разработчиков — к ним эти требования неприменимы, как правило. Это обычно люди, которые могут реально тащить какой-то большой кусок проекта, по пути улюлюкая, присвистывая и говоря «а давайте-ка мы вот тут еще прикрутим вот такую клевую штуку и вон там порефакторим на досуге».
Это если вы лидер в индустрии (Яндекс в России, Uber в US, FB во всем мире). А если вы контора даже уверенная в себе, но не лидер — вы очень долго будете искать ключевых разработчиков. Или нужно будет платить не по рынку, или мотивировать тех, которые есть. Это я вижу из практики своей и своих коллег.
Возрастным группам (потому что Яндекс в Москве очень хорош для студентов, например; EPAM в Петербурге интересен для молодежи, которая хочет переехать; Avito идеален для senior-девелоперов, которым не хочется никуда ехать и везти семью; JetBrains понравится тем, кто любит профессию по-настоящему);
Тем, кто работал в компании и тем, кто не работал + можно было бы добавить какие-то реальные мнения людей (так можно было бы узнать что, скажем, Яндекс — чемпионы велосипедостроения и девопсам там несильно нравится, но нравится разработчикам; что Grid Dynamics это компания одного проекта, но очень большого; что EPAM классные, но конкурсы нравятся не всем; что WarGaming известные, но определенным специалистам придется ехать в головной офис работать);
По уровню специалиста (это позволило бы увидеть, что в EPAM-е есть реальный карьерный рост; что Luxoft старается увезти architect-ов из России; что Яндекс набирает дикое количество middle-ов на средние зарплаты; что Rambler ведет очень своеобразную политику найма людей)
В общем, значительно лучше можно было бы сделать этот рейтинг, если бы не опрашивать людей с улицы о том, что происходит в их собственной компании или у их соседей, а грамотно разделить их на фокус-группы и потом уже задавать каждой группе вопросы.
Мне приходится много всего тестировать. Надо поджойнить количество VM-ок и процент свободных ресурсов облака? Открываем IPython, начинаем. В соседней вкладке tmux-а записываем то, что показалось правильным и интересным. Накидали несколько функций, потестировали из консоли — окей, можно открыть PyCharm, начать писать нормальный код — с логированием, try/except, правильными наследованием и композицией. Но вот эти несколько функций в консоли удобнее накидать в vim, чем в nano, потому что из коробки в vim есть автоотступы для python. Можно переключать консоль сразу в IDE, но интерфейс очень уж разный, фокус теряется постоянно.
Идем дальше. Понадобилось написать новую роль для ansible. Помню, что можно как-то явно указать синтаксис из docker-compose для docker_service, но не помню точный синтаксис. Окей, открываем в виме соседнюю вкладку с ролью, которую я писал месяц назад и в которой был docker_service и смотря на нее на том же экране пишем нашу новую роль. Очень удобно — гуглить не надо, постоянно переключаться никуда не надо. Можно, наверное и в IDE так делать, но мне неизвестны люди, которые так на самом деле вообще делают. Копировать без мышки опять же, быстрее и удобнее.
Окей. Написали роль, давайте потестируем. Вот у нас ELK в ансибл ролях — конфиги, сертификаты, пайплайн паттерны для Logstash и т.д. Кучка сервисов. Запустили ансибл, развернулось, но работает явно не так, как ожидалось. По опыту — значительно быстрее пойти на удаленную тестовую машину и руками разобрать все, чтобы понять, что случилось а потом уже rsync-нуть изменения, поменять немного роль и запустить ее снова, нежели пытаться каждый раз менять саму роль, запускать ее и смотреть, угадал ли в этот раз с изменениями. А на удаленной машине опять vim, потому что json и снова отступы из коробки.
Идем дальше. Надо потестировать rspec-ом тесты для паппетного модуля. Но только вот тестов в модуле 4970, а мне надо только те тридцать, которые я сейчас написал (а потом уже только будем запускать все остальные, если мои новые не сломаны). Как из IDE это быстро сделать — я не знаю, а из консоли — знаю. И оказывается, что сделать небольшие правки из консоли в случае чего быстрее, нежели переключать фокус на GUI. И правки эти делаются vim-ом, потому что к нему можно линтер в два щелчка прикрутить, а к nano нельзя.
Продолжаем. Звонят коллеги, просят подебажить немного удаленный сервер. Говорят, что это не прод и можно прямо на нем править, чтобы понять, что не так (это вообще очень частый кейс). Идем. Там питоновый сервис и куча конфигов. И vim. Ну вы поняли — отступы из коробки, удобное копирование, свернуть его можно, команду запустить из консоли, не выходя, на нужную строку быстро перейти и т.д.
И вот для такого использования оказывается, что nano неудобный — там он отступы не сконвертировал из табов в пробелы, тут ошибка линтера закралась и т.д. А vim в самый раз. И везде есть. К тому же непонятно мне, какое я количество IDE должен купить себе буду, если все эти мелочи захочу в IDE править. А когда у тебя к vim-у есть еще git, tmux, zsh etc. — оказывается, что комплекс этих утилит по удобству перекрывает любую IDE, потому что нельзя написать IDE, которая будет делать все очень хорошо (JetBrains пытаются, да). Но можно написать много утилит, каждая из которых будет делать свою функцию идеально. Если вы программист, пишущий на одном языке и иногда что-то делающий в консоли — мне кажется, вам вполне позволительно обо всех этих утилитах не знать. Но в IT мире полно людей, для которых программирование — побочная деятельность и для них иногда vim удобнее.
А в свободное время я пишу на Java. И как это делать в vim — я не хочу даже знать. Android Studio скрывает все шероховатости, которые мне неинтересно изучать в рамках хобби.
Лично я 10 лет работал в Москве по профессии а потом, наработав связи и знакомства, устроился удаленно в несколько компаний. Куда-то физиком, где-то ИП открыл. Работаю примерно 8 часов в день, претензий у работодателей никаких нет (им надо, чтобы работа была сделана, а не чтобы я в офисе у них сидел), получаю около 80k$ на руки в год до всех расходов. Но я тут за 10 лет уже заработал на квартиры-машины-дачи для себя и семьи, у меня расходов-то на еду и семью только. Зато я могу путешествовать, ездить везде с семьей, показывать ребенку мир и выбирать, когда мне работать.
А теперь, когда мы поняли варианты, у меня к вам встречный вопрос — а где я в США могу так устроиться? Это вопрос риторический, на самом деле. Устроиться можно. Просто придется заново нарабатывать те же самые связи и знакомства и на это уйдет еще 10 лет. Но зачем мне это? Поэтому когда меня каждый новый знакомый спрашивает, почему я не уеду в США, то он сначала очень удивляется, когда узнает, что я уже уехал *ИЗ* США, а потом часто соглашается, когда я объясняю, что есть смысл переезжать интерном в гугл или твиттер после института и нет — сеньором после 10-15 лет опыта работы в России при условии, что ты живешь не в своем воображаемом вакууме, а в реальном социуме.
Часто еще возникает спор про то, что «там, у них» лучше социальный лифт. Но это не так и не везде. Да, в США, например, много хорошей инфраструктуры. При этом там, например, полно районов в городах, в которые ночью лучше и не заходить. Везде есть минусы и плюсы и поэтому однозначно говорить «вот там лучше, а тут хуже» нельзя. Лучше для вас — однозначно. Хуже для всех — точно нет.
Вот тут можно было закончить, если бы вы это сразу написали. Я вижу для себя преимущества, овладев любым инструментом.
Про все остальные операции — notepad++ не кроссплатформенный. И если вы им пользуетесь, то скорее всего, у вас интерфейс системы не очень подходящ под удобную работу по ssh. А так — он хороший, да. Почти как vim. Только с окошками и мышкой надо побольше тыкать.
Про кучу конфигов и что-то не так — ну это очень голословно. У меня на одной работе постоянная разработка у людей на ажуре. Вот часто бывает, что надо заспавнить новую виртуалку, но что-то подхачить под нужды для тестирования. Вот прямо каждый день такое бывает. Что ж мне, оркестрировать каждую виртуалку, которая и живет-то часто несколько часов всего?
Меж тем, Fuel-а больше нет, так что все это уже неважно.
«allocatedSpace»: 890,
«onDiskSpace»: 890,
«totalSpace»: 1000
Подскажите, что они значат в контексте libvirt?