при том, что git - это, чаще всего, про коллективную разработку. и если в проекте решено игнорировать, упомянутые вами .DS_Store, то они должны быть проигнорированы всеми участниками разработки.
чем проще онбординг в проект, тем легче работается.
Если основной претензией к проекту является шифрование
совершенно верно!
Если не являешься экспертом в шифровании, не стоит придумывать какие-то свои шифры или комбинировать уже имеющиеся по своему усмотрению. Это, внезапно, может привести к совершенно любым последствиям от ослабления криптостойкости до багов в собственной реализации и последующей утечке данных - обо всём этом уже писали выше...
как уже написали все отметившиеся выше, первостепенный вопрос в программах класса "менеджер паролей" - это безопасность и сохранность данных (отчасти поэтому keepass2android выглядит, как гадкий утёнок) и именно на этот аспект нужно сильнее всего налегать, а не на модные цветовые акценты и прочее.
ну, а если цель проекта прокачать какие-то свои навыки (в чем нет совершенно ничего зазорного), это тоже надо явно отметить. не "хей, смарите, какой клёвый менеджер пороле получаиццо!", а "вот мой путь от А до Б, было интересно"
ни в коем случае не пытаюсь обесценить полученный опыт, но в этом плане гораздо безопаснее написать стопятисотый аудиоплеер с нескучными обоями. по крайней мере, об него никто не поранится, когда там обнаружится дырка в безопасности.
А чем не угодил, например, keepass2android? Добавьте в него немного тематизации на основе обоев или "перехват цвета, как ее называет Google, приносит сочетания ярких чистых цветов в каждый элемент ОС" и дело в шляпе.
по крайней мере, он проходил уже security audit и имеет обширную пользовательскую базу...
вот-вот. третий - ноунейм какой-то. а.. код безопасности, точно
а у нас есть три сертифицированных антивируса?! два только в руках держал... )
особенно, если это thin lvm, смайл.
хотя, остальные режимы работы тоже не привносят лёгкости выковыривания потерянного через dd..
GitHub по умолчанию включил защиту для
git push, чтобы предотвращать утечки.афтааар.. чини статью. и английский :)
при том, что git - это, чаще всего, про коллективную разработку. и если в проекте решено игнорировать, упомянутые вами .DS_Store, то они должны быть проигнорированы всеми участниками разработки.
чем проще онбординг в проект, тем легче работается.
не знаю, чего шикарного.. настройки игнорируемых файлов должны быть привязаны к проекту, а не к компьютеру. иначе какая-то каша получается.
Всегда ценно сослаться на первоисточник, а не на (свою же?) серию статей.
"вкрации": статья - вольный пересказ какого-нибудь туториала, например, первой половины вот такой презы: https://www.debian.org/doc/manuals/packaging-tutorial/packaging-tutorial.en.pdf
Если захочется вглубь, то продолжить можно "основным талмудом" - https://www.debian.org/doc/debian-policy/index.html
Вывод: цените первоисточники - в них сила.
Why so serious, Yuri... Why so serious...
Heading pic being like "GPT, show young Nicole Kidman, but if she was more into verilog, than actorship" 🤭
пишут, что в 16.7.2 )
Хотя бы, никто не спорит, какого цвета у неё платье...
стоит предположить очевидный вариант - "деньги не пахнут", а содержимое нерелевантной выдачи проплачено продавцами )
(списывают у старшего брата, в общем https://habr.com/ru/companies/first/articles/776960/)
Благодарю, информация передана ответственному лицу 🤭
Ждал-ждал, а рекламы предприятия так и не наступило. Печаль.. (а мы бы, может, и заинтересовались)
Может быть, надо исправить эту оплошность? )
И что же этот автослесарь забыл на IT-ресурсе позвольте уточнить?
// Понемногу начинают утомлять юмористы, не способные верно расшифровать, в том числе, эту аббревиатуру исходя из контекста...
совершенно верно!
Если не являешься экспертом в шифровании, не стоит придумывать какие-то свои шифры или комбинировать уже имеющиеся по своему усмотрению. Это, внезапно, может привести к совершенно любым последствиям от ослабления криптостойкости до багов в собственной реализации и последующей утечке данных - обо всём этом уже писали выше...
как уже написали все отметившиеся выше, первостепенный вопрос в программах класса "менеджер паролей" - это безопасность и сохранность данных (отчасти поэтому keepass2android выглядит, как гадкий утёнок) и именно на этот аспект нужно сильнее всего налегать, а не на модные цветовые акценты и прочее.
ну, а если цель проекта прокачать какие-то свои навыки (в чем нет совершенно ничего зазорного), это тоже надо явно отметить. не "хей, смарите, какой клёвый менеджер пороле получаиццо!", а "вот мой путь от А до Б, было интересно"
ни в коем случае не пытаюсь обесценить полученный опыт, но в этом плане гораздо безопаснее написать стопятисотый аудиоплеер с нескучными обоями. по крайней мере, об него никто не поранится, когда там обнаружится дырка в безопасности.
такие дела. успехов.
но это всё графические рюшечки.. в чем профит написания приложения такого класса именно с нуля?
мой предыдущий комментарий был робким намёком, почему не объединить силы с уже существующими проектами? дух опенсорса же, все дела...
А чем не угодил, например, keepass2android? Добавьте в него немного тематизации на основе обоев или "перехват цвета, как ее называет Google, приносит сочетания ярких чистых цветов в каждый элемент ОС" и дело в шляпе.
по крайней мере, он проходил уже security audit и имеет обширную пользовательскую базу...