Яндекс только на оплату электричества для обучения Алисы тратит больше чем вы вероятно представляете. Сделать своего ассистента лучше Алисы это прям очень не дёшево.
Для сравнения алгоритмов дедупликации пришлось бы провести полноценное исследование, включая сорсы zfs/btrfs bees, для подобной статьи потребуется затратить около 2х месяцев по вечерам и выходным, в данный момент я к сожалению не располагаю таким ресурсом.
Да и в целом мне хотелось сравнить и показать "а чё там из коробки доступно?"
Большинство пользователей или ИТ специалистов не хотят тратить дни и недели на допиливание кода и сборку на арчах под свои нужды.
Но в целом соглашусь что было бы интересно сделать прям научную статью со сравнением алгоритмов и разбором на разных дата сетах.
Я на самом деле ожидал что блочная дедупликация будет эффективнее чем файловая, вообще детального описания алгоритма от MS я не нашел, за исключением того самого описания на оффсайте, больше похоже что все таки оно работает на гибридном уровне.
Спасибо за технический комментарий. Я привел пример минимального рабочего варианта, честно, статья отняла сильно больше сил и времени чем я планировал, поэтому пример сервиса/юнита получился довольно кривой, я старался сфокусироваться больше на теме стати и результатах. Хотел еще подтащить OpenDedup, но с ним по быстрому не вышло, да и так портянка получилась не маленькая.
Если брать чисто кейс с моим дата сетом, то да согласен, но мне хотелось покопаться и сравнить именно разные варианты дедупликации. У меня в проде был когда то массив от PureStorage, уж не знаю на базе чего у них была построена FS, но массив дедупил на лету все и вся с очень хорошими коэффициентами, я надеялся что найду +- похожее решение на Linux.
Я бы сказал что для полноценного GitOps требуется очень высокая зрелость ИТ в компании, нужно что бы разработчики сами были и dev и ops и sre и так далее, для того что бы использовать прям GitOps GitOps.
Я предпочитаю смешанный подход, когда мы работаем вокруг git, но без чрезмерной абстракции и всяких модных и порой лишних (на мой взгляд) инструментов.
На весь хабр свой факап и батхерт расписал, а он внезапно стал на столько популярным что мне до сих пор люди в ТГ пишут на тему моего и их аналогичного опыта.
Подобный вариант рассматривал, но пока что не сошлись по условиям с потенциальными работодателями по подобной схеме.
В целом, у работодателя сильно снижается интерес когда он узнает что у меня есть семья и их тоже нужно релоцировать, я так понял что в основном ищут одиноких.
На самом деле классическая психология, человек которого скамят боится «потерять» то что уже заплатил и разводится на еще и еще и еще, полагаю может быть это такой план Б они и используют.
Да, хорошая мысль. =)
Яндекс только на оплату электричества для обучения Алисы тратит больше чем вы вероятно представляете. Сделать своего ассистента лучше Алисы это прям очень не дёшево.
Мне кажется будет отличным вариантом если ты опишешь свой опыт общения, и у нас получится серия статей на эту тему.
Я прям дежавю ловил, одно за другим.
Искренне сочувствую коллега.
Если есть желание можем созвонится.
По графикам zabbix видно что место не заканчивалось.
Получилось как есть, ничего не менял, не правил.
Для сравнения алгоритмов дедупликации пришлось бы провести полноценное исследование, включая сорсы zfs/btrfs bees, для подобной статьи потребуется затратить около 2х месяцев по вечерам и выходным, в данный момент я к сожалению не располагаю таким ресурсом.
Да и в целом мне хотелось сравнить и показать "а чё там из коробки доступно?"
Большинство пользователей или ИТ специалистов не хотят тратить дни и недели на допиливание кода и сборку на арчах под свои нужды.
Но в целом соглашусь что было бы интересно сделать прям научную статью со сравнением алгоритмов и разбором на разных дата сетах.
Возьму на заметку.
Интересно будет написать вторую часть статьи, когда найду в себе силы.
Может быть как раз добавить VDO, sdfs, lessfs.
Не совсем понимаю как трактовать ваш комментарий, если возможно ответьте более развернуто.
Спасибо!
Я на самом деле ожидал что блочная дедупликация будет эффективнее чем файловая, вообще детального описания алгоритма от MS я не нашел, за исключением того самого описания на оффсайте, больше похоже что все таки оно работает на гибридном уровне.
Спасибо за технический комментарий.
Я привел пример минимального рабочего варианта, честно, статья отняла сильно больше сил и времени чем я планировал, поэтому пример сервиса/юнита получился довольно кривой, я старался сфокусироваться больше на теме стати и результатах.
Хотел еще подтащить OpenDedup, но с ним по быстрому не вышло, да и так портянка получилась не маленькая.
Если брать чисто кейс с моим дата сетом, то да согласен, но мне хотелось покопаться и сравнить именно разные варианты дедупликации.
У меня в проде был когда то массив от PureStorage, уж не знаю на базе чего у них была построена FS, но массив дедупил на лету все и вся с очень хорошими коэффициентами, я надеялся что найду +- похожее решение на Linux.
Я бы сказал что для полноценного GitOps требуется очень высокая зрелость ИТ в компании, нужно что бы разработчики сами были и dev и ops и sre и так далее, для того что бы использовать прям GitOps GitOps.
Я предпочитаю смешанный подход, когда мы работаем вокруг git, но без чрезмерной абстракции и всяких модных и порой лишних (на мой взгляд) инструментов.
В целом, у работодателя сильно снижается интерес когда он узнает что у меня есть семья и их тоже нужно релоцировать, я так понял что в основном ищут одиноких.
По прочтении остался только 1 вопрос, удалось ли с эникея на разработчика перепрофилироваться?
Такое лучше в личку спрашивать.
Но решил что с семьей двойной переезд будет очень сложен, и стал искать варианты прямой релокации.