Копии разделов логично создавать так, чтобы они были доступны для той системы, которой вы собираетесь их читать. Для вас это Windows.
До того, как я слез с акронисовой иглы, у меня система изготовления бекапов определяла систему, в которой я буду их просматривать, что, по моему мнению, не совсем правильно. ntfsclone — это мой способ развернуть ситуацию правильной стороной.
Ну я бы посмотрел в сторону btrfs и zfs. Они умеют инкрементальные копии, а регулярность можно устроить каким-нибудь кроном. А вот чтобы для любой файловой системы такое сделать — ну может класть образы в ту же zfs, а потом делать инкрементальный снапшот. Но это уже, конечно, не совсем без бубна.
Я тут поредактировал предыдущий ответ. Добавил, что ещё врядли штатный бекап монтируется линуксовым mount.
Что касается Клонзиллы — она общего назначения и не всё может. Если у меня очень узко очерченная задача, которая решается ntfsclone, которая есть везде — я предпочитаю ntfsclone.
Прежде всего тем, что работает не только для семёрки. Плюс врядли штатный бекап монтируется линуксовым mount. А в качестве антивирусника я использую Live CD от Касперского. Но и попутно не надо разбираться в том, как делается штатный семёрочный бекап.
Ну как же. Смысл в том, чтобы продемонстрировать, что свободное программное обеспечение это круто! Ну и собственно эта статья, как и две предыдущие, родилась из моего желания выяснить как заменить Акронис свободным софтом. Вот, публикую результаты по мере выяснения. Надеюсь, что будет полезно и кому-то кроме меня.
Рекомендации надо воспринимать как рекомендации. Создатели фреймворка формулируют их специально, чтобы разработчик мог избежать попадания на целый набор граблей.
Фреймвор — он и есть сборка из библиотек, которую надо использовать согласно рекомендациям создателя фреймворка. Если самостоятельно применить все эти библиотеки правильным образом — у вас будет фреймворк собственного изготовления.
Ну вопрос был собственно про сложности расширения проекта. Это они и есть.
Насчёт того, что никакой фреймворк не поможет — это не совсем так.
Конкретно вот с этими проблемами — поможет.
Фреймворки позволяют абстрагироваться от СУБД.
Фреймворки как правило имеют средтва миграции структуры данных (также абстрагированные от СУБД)
Фреймворки помогают структурировать код так, чтобы горизонтальное масштабирование впринципе было возможно.
Фреймворки зачастую имеют средства для поддержки многоязычности.
Фреймворки помогают с автоматизацией деплоя приложения.
Если фреймворка нет, то да, приложение наверняка придётся переписывать. Если фреймворк есть, а в бизнес логике — каша — тоже придётся. Но если с бизнес логикой всё хорошо, то можно отделаться малой кровью.
Если в проекте нет фреймворка — это может означать две вещи — его нет вообще или он есть, но только самописный. Если самописный фреймворк хороший или хотя бы средний, это естественным образом снимает кучу проблем, однако существует определённый набор граблей, на который систематически натыкаются проекты, не использующие сторонние фреймворки
— смена СУБД
— изменение структуры БД (как правило проводится руками)
— горизонтальное масштабирование
— многоязычность
— перенос в другое окружение (обновление вообще любого компонента системы)
Клиент один, потому что он один в данный момент времени. Нельзя же разрабатывать например сайт Сбербанка для нескольких клиентов. Может быть слово заказчик тут лучше подходит.
Понять, чего хочет заказчик на один релиз ещё более-менее реально, хотя сложно. Но понять, чего он захочет в следующем релизе может только Ванга.
Когда цилы релизов долгие, с аджайлом тяжеловато, да. Но в идеале релиз можно выпускать каждый месяц, а сбором отзывов заниматься перманентно, постоянно корректируя направление разработки согласно результатам.
PM он один из разработчиков. В том смысле, что он с нашей стороны команды. И если клиент сам не вполне понимает, что ему надо, то PM может решить за него. Но только если таких проектов у PM уже было много. И все они одинаковые. А если это не так, то слишком подробную картину мира лучше не рисовать — это незибежно влечёт за собой горы работы впустую.
Ну и я говорю о мире номер один. Который ширпотреб в русском варианте и Shrinkwrap в английском.
В эти мутные места нельзя внести ясность. Клиент — не в курсе что там будет. А если думает, что в курсе — то скорее всего ошибается. Разработчик, если он опытный — понимает что будет в этих мутных местах лучше клента, но тоже не владеет всей полнотой информации. Работать по мутным местам имеет смысл когда они прояснятся — не раньше. А до этого имеет смысл применить самое простое решение из возможных.
Слова CI, Code Review, тесты и менеджер вместе не употребляются.
Ты говоришь менеджеру тесты, он слышит — задачи будут закрываться на неделю позже.
Ты говоришь ему Code Review, он слышит — на одну задачу придётся выделять в 3 раза больше народу.
Ты говоришь ему CI, он слышит — деплой я сделаю не сейчас, а через 2 дня, после того, как всё настрою.
> То, что язык позиционирует себя именно как заменитель си, подразумевает, что он должен быть всё-таки удобнее, чем си.
Это также подразумевает, что область применения у него та же, что и у си и он удобнее, чем си именно в этой области. У языков, на которых пишут веб-программисты нет проблем с контролем памяти. Там либо есть gc, либо каждая программа, как в php, работает несколько секунд, а потом умирает и отдаёт всю память обратно.
Вообще у меня создалось впечатление, что единственная черта Rust, которая могла привлечь веб разработчиков — это похожий на javascript синтаксис.
До того, как я слез с акронисовой иглы, у меня система изготовления бекапов определяла систему, в которой я буду их просматривать, что, по моему мнению, не совсем правильно. ntfsclone — это мой способ развернуть ситуацию правильной стороной.
Что касается Клонзиллы — она общего назначения и не всё может. Если у меня очень узко очерченная задача, которая решается ntfsclone, которая есть везде — я предпочитаю ntfsclone.
Насчёт того, что никакой фреймворк не поможет — это не совсем так.
Конкретно вот с этими проблемами — поможет.
Фреймворки позволяют абстрагироваться от СУБД.
Фреймворки как правило имеют средтва миграции структуры данных (также абстрагированные от СУБД)
Фреймворки помогают структурировать код так, чтобы горизонтальное масштабирование впринципе было возможно.
Фреймворки зачастую имеют средства для поддержки многоязычности.
Фреймворки помогают с автоматизацией деплоя приложения.
Если фреймворка нет, то да, приложение наверняка придётся переписывать. Если фреймворк есть, а в бизнес логике — каша — тоже придётся. Но если с бизнес логикой всё хорошо, то можно отделаться малой кровью.
— смена СУБД
— изменение структуры БД (как правило проводится руками)
— горизонтальное масштабирование
— многоязычность
— перенос в другое окружение (обновление вообще любого компонента системы)
Большое спасибо!
Понять, чего хочет заказчик на один релиз ещё более-менее реально, хотя сложно. Но понять, чего он захочет в следующем релизе может только Ванга.
Когда цилы релизов долгие, с аджайлом тяжеловато, да. Но в идеале релиз можно выпускать каждый месяц, а сбором отзывов заниматься перманентно, постоянно корректируя направление разработки согласно результатам.
Ну и я говорю о мире номер один. Который ширпотреб в русском варианте и Shrinkwrap в английском.
Ты говоришь менеджеру тесты, он слышит — задачи будут закрываться на неделю позже.
Ты говоришь ему Code Review, он слышит — на одну задачу придётся выделять в 3 раза больше народу.
Ты говоришь ему CI, он слышит — деплой я сделаю не сейчас, а через 2 дня, после того, как всё настрою.
Это также подразумевает, что область применения у него та же, что и у си и он удобнее, чем си именно в этой области. У языков, на которых пишут веб-программисты нет проблем с контролем памяти. Там либо есть gc, либо каждая программа, как в php, работает несколько секунд, а потом умирает и отдаёт всю память обратно.
Вообще у меня создалось впечатление, что единственная черта Rust, которая могла привлечь веб разработчиков — это похожий на javascript синтаксис.