Для некоторых данных можно поднять собственное "облако" и настроить бэкап туда без рута. Напр. для контактов/календаря/задач есть EteSync. Для приложений есть толпа утилит для бэкапа без рута, но насколько они рабочие (как много приложений не смогут корректно восстановить) - сложно сказать, последний раз я на них смотрел много лет назад и сильно разочаровался.
А теперь тоже нужен рут, только вместо титаниума - необэкап. Нео, конечно, несколько кривой и местами глючный, но из доступных альтернатив лучше всё-равно ничего нет, а нео более-менее справляется с задачей.
Поэтому рут и сторонняя утилита для бэкапа (требующая рут) - это жизненная необходимость. Тогда проблемы будут в единичных случаях (из мне известных - только whatsapp успешно сопротивляется восстановлению своих данных из бэкапа такими утилитами… и, да, забавно что при этом собственными средствами он нередко восстановить данные тоже не может).
А чего его не купить… если первым делом на него всё-равно ставится LineageOS. Впрочем, учитывая их последние меры по усложнению разблокировки загрузчика - может и не купить, но тут причина иная.
Смешно. Дайте угадаю, все 14 лет после кружка информатики Вы провели в бюджетной организации? Там это называется "младший специалист", "специалист", "старший специалист" и "ведущий специалист".
Пока это касается файлов связанных с проектом (полагаю, пример с __pycache__ выше из этой серии), т.е. таких, которые могут создаваться у всех разработчиков этого проекта - Вы правы, это должно быть в gitignore проекта.
Но вот что касается файлов, которые создают конкретные OS/IDE/редактор/etc. - эти файлы специфичны для окружения (и его настройки!) конкретного разработчика, поэтому они во-первых должны исключаться не только из этого проекта а из всех, и во-вторых только этот разработчик знает своё окружение и какой именно мусор оно создаёт, поэтому исключать их нужно в глобальном ignore-конфиге этого разработчика. Попытаться засунуть все возможные варианты таких файлов для всех возможных OS/IDE/etc. в gitignore проекта, конечно, можно. Но это дурная идея: во-первых это раздувает gitignore, во-вторых это дублируется в каждом проекте, в-третьих всегда найдутся оригиналы с нестандартными OS/IDE либо их нестандартными настройками из-за которых мусора в и работы по поддержке всей этой толпы gitignore в каждом проекте станет ещё больше.
Не знаю, насчёт 14 часов, но у меня в жизни были периоды, когда я очень продуктивно и без прокрастинации писал код часов по 10 в день (в среднем за месяц, без выходных - т.е. часов 300 продуктивных/рабочих в месяц выдавал). Оплата была почасовая конечно, но я так работал не ради денег, а просто потому, что было интересно. Долго я так работать не мог, но месяца 2-3 подряд - вполне (но потом приходилось отдыхать пару месяцев, либо работая мало, либо вообще не работая). И мне такой режим работы был очень комфортен - когда есть желание работать я работал не по 8 часов в рабочие дни а столько, сколько хотелось, а когда не было желания работать (в т.ч. из-за переутомления вызванного предыдущим периодом ударной работы) - не работал.
При этом я обходился без ноотропов, с личной жизнью было всё хорошо, бытовых обязательств на мне действительно почти не было, с гигиеной было всё хорошо, еда действительно либо заказная либо кто-то в семье готовил и ставил тарелку перед клавиатурой, высыпался всегда хорошо. В общем, в плане быта или здоровья это никаких серьёзных проблем не создавало.
Что характерно, я перестал работать в таком режиме не потому, что он мне перестал нравится, или здоровье уже не тянет, а потому, что проекты изменились: теперь практически ничего не пишется одним разработчиком, вся работа идёт в команде, а в команде в таком режиме работать невозможно.
Риск потери есть всегда - если деньги держать под подушкой то квартиру могут ограбить, если в некастодиальном кошельке то можно забыть от него пароль, валюта в которой средства может обесцениться, etc.
Поэтому вопрос не в самом существовании риска, а в том, насколько он большой с одной стороны, и что мы получаем взамен на этот риск с другой стороны. Традиционные банки дали нам не так и мало: возможность не носить с собой крупные суммы а платить картой, возможность оплачивать покупки через интернет, … и даже риск что банк лопнет нередко застрахован государством и (часть) средств всё-равно обещают компенсировать.
Так что - нет, банки это не скам. Но банки - это определённо опекуны, и далеко не все взрослые люди рады тому, что доступ к их собственным средствам в обязательном порядке должен контролировать какой-то опекун.
Я сам не фанат кастодиальных сервисов (не важно, это CEX или банки), но многие из них действительно создают какие-то ценности для пользователей (будь то возможность дёшево и быстро торговать на CEX или оплачивать покупки через интернет банковскими картами). Если не держать в кастодиальных сервисах крупные суммы, то риск потерять средства вполне может оказаться приемлемым, учитывая предоставляемые этими сервисами возможности.
AFAIK никаким ботам помимо @wallet даже этот уровень интеграции в само приложение телеги недоступен. Так что в теории @wallet сторонний бот никак не связанный юридически с телегой, а на практике все боты равны но конкретно этот явно привилегированный. Так что есть все основания утверждать, конкретно этот бот действительно интегрирует функционал кошелька в основное приложение телеги.
Что до того, насколько текущий функционал "полноценный", то это философский вопрос, и выход любой следующей версии телеги может в этом плане всё кардинально изменить. В этом плане намного важнее сам факт наличия интеграции, чем список реализованных на данный момент фич.
Вероятно, он не упомянут потому, что он никак не связан с темой статьи (суперапп) - это обычный некастодиальный кошелёк для очередной крипты, который по сути ничем не отличается от кучи других кошельков для других монет. На данный момент основная фишка монеты TON, отличающая её от всё остальной крипты, это именно интеграция с телегой - а при использовании TON Space никакой интеграции нет (максимум, если с натяжкой, то TON Space можно использовать в качестве "дополнения" к @wallet, держа в нём основную часть своих средств, перекидывая по необходимости в/из кастодиальный @wallet мелкие суммы на текущие расходы).
А что, тупо в лоб легально купить крипту переводом с банковского счёта в РФ нельзя (без мутных типов-менял и p2p)? Напр. через bestchange.ru (или Вы как раз эти обменки и записали в категорию "мутных типов-менял")?
По сути вопроса: на мой взгляд фокусироваться при написании нужно на сути документа/статьи, а не на процессе написания. (И, да, всё что можно удалить из финального документа не вредя сути - безжалостно выкидывать или сокращать.) Мне лично хватает в мелких/средних документах вставлять в середину фразы "TODO что-то", а в больших вести отдельный раздел "TODO" со списком задач, которые необходимо сделать для завершения написания документа.
Passkeys/WebAuthn вообще и не про сертификаты и не про CLI. Это про то, чтобы юзер пароли не запоминал. Совсем другая задача и другое решение. Как это может помочь организовать доступ CLI к API сайта более простым способом чем application passwords - мне лично пока неясно. Как минимум это создаст зависимость CLI от внешнего аутентификатора (хардварного или программного), а они пока не особо популярны и распространены.
Он непопулярен потому, что управление (выдача, установка в браузеры, обновление, отзыв) этими клиентскими сертификатами - достаточно сложная и неудобная штука. Поэтому mTLS активно используется только на бэке, для аутентификации между микросервисами, где всё управление всеми сертификатами может делать (и автоматизировать) девопс компании.
Для некоторых данных можно поднять собственное "облако" и настроить бэкап туда без рута. Напр. для контактов/календаря/задач есть EteSync. Для приложений есть толпа утилит для бэкапа без рута, но насколько они рабочие (как много приложений не смогут корректно восстановить) - сложно сказать, последний раз я на них смотрел много лет назад и сильно разочаровался.
А теперь тоже нужен рут, только вместо титаниума - необэкап. Нео, конечно, несколько кривой и местами глючный, но из доступных альтернатив лучше всё-равно ничего нет, а нео более-менее справляется с задачей.
Поэтому рут и сторонняя утилита для бэкапа (требующая рут) - это жизненная необходимость. Тогда проблемы будут в единичных случаях (из мне известных - только whatsapp успешно сопротивляется восстановлению своих данных из бэкапа такими утилитами… и, да, забавно что при этом собственными средствами он нередко восстановить данные тоже не может).
А чего его не купить… если первым делом на него всё-равно ставится LineageOS. Впрочем, учитывая их последние меры по усложнению разблокировки загрузчика - может и не купить, но тут причина иная.
Без бэкапа тоже не вариант. Просто данные должны быть зашифрованы стойким алгоритмом используя (достаточно сложный) пароль - тогда можно и в облако.
Смешно. Дайте угадаю, все 14 лет после кружка информатики Вы провели в бюджетной организации? Там это называется "младший специалист", "специалист", "старший специалист" и "ведущий специалист".
Пока это касается файлов связанных с проектом (полагаю, пример с
__pycache__выше из этой серии), т.е. таких, которые могут создаваться у всех разработчиков этого проекта - Вы правы, это должно быть в gitignore проекта.Но вот что касается файлов, которые создают конкретные OS/IDE/редактор/etc. - эти файлы специфичны для окружения (и его настройки!) конкретного разработчика, поэтому они во-первых должны исключаться не только из этого проекта а из всех, и во-вторых только этот разработчик знает своё окружение и какой именно мусор оно создаёт, поэтому исключать их нужно в глобальном ignore-конфиге этого разработчика. Попытаться засунуть все возможные варианты таких файлов для всех возможных OS/IDE/etc. в gitignore проекта, конечно, можно. Но это дурная идея: во-первых это раздувает gitignore, во-вторых это дублируется в каждом проекте, в-третьих всегда найдутся оригиналы с нестандартными OS/IDE либо их нестандартными настройками из-за которых мусора в и работы по поддержке всей этой толпы gitignore в каждом проекте станет ещё больше.
Фейсбук в какой-то момент вроде хотел свой стейблкоин выпустить, но им запретили.
Если бы у Lightning ещё не было проблем с безопасностью - было бы вообще хорошо.
Не знаю, насчёт 14 часов, но у меня в жизни были периоды, когда я очень продуктивно и без прокрастинации писал код часов по 10 в день (в среднем за месяц, без выходных - т.е. часов 300 продуктивных/рабочих в месяц выдавал). Оплата была почасовая конечно, но я так работал не ради денег, а просто потому, что было интересно. Долго я так работать не мог, но месяца 2-3 подряд - вполне (но потом приходилось отдыхать пару месяцев, либо работая мало, либо вообще не работая). И мне такой режим работы был очень комфортен - когда есть желание работать я работал не по 8 часов в рабочие дни а столько, сколько хотелось, а когда не было желания работать (в т.ч. из-за переутомления вызванного предыдущим периодом ударной работы) - не работал.
При этом я обходился без ноотропов, с личной жизнью было всё хорошо, бытовых обязательств на мне действительно почти не было, с гигиеной было всё хорошо, еда действительно либо заказная либо кто-то в семье готовил и ставил тарелку перед клавиатурой, высыпался всегда хорошо. В общем, в плане быта или здоровья это никаких серьёзных проблем не создавало.
Что характерно, я перестал работать в таком режиме не потому, что он мне перестал нравится, или здоровье уже не тянет, а потому, что проекты изменились: теперь практически ничего не пишется одним разработчиком, вся работа идёт в команде, а в команде в таком режиме работать невозможно.
Риск потери есть всегда - если деньги держать под подушкой то квартиру могут ограбить, если в некастодиальном кошельке то можно забыть от него пароль, валюта в которой средства может обесцениться, etc.
Поэтому вопрос не в самом существовании риска, а в том, насколько он большой с одной стороны, и что мы получаем взамен на этот риск с другой стороны. Традиционные банки дали нам не так и мало: возможность не носить с собой крупные суммы а платить картой, возможность оплачивать покупки через интернет, … и даже риск что банк лопнет нередко застрахован государством и (часть) средств всё-равно обещают компенсировать.
Так что - нет, банки это не скам. Но банки - это определённо опекуны, и далеко не все взрослые люди рады тому, что доступ к их собственным средствам в обязательном порядке должен контролировать какой-то опекун.
По этой логике и банки - скам.
Я сам не фанат кастодиальных сервисов (не важно, это CEX или банки), но многие из них действительно создают какие-то ценности для пользователей (будь то возможность дёшево и быстро торговать на CEX или оплачивать покупки через интернет банковскими картами). Если не держать в кастодиальных сервисах крупные суммы, то риск потерять средства вполне может оказаться приемлемым, учитывая предоставляемые этими сервисами возможности.
AFAIK никаким ботам помимо
@walletдаже этот уровень интеграции в само приложение телеги недоступен. Так что в теории@walletсторонний бот никак не связанный юридически с телегой, а на практике все боты равны но конкретно этот явно привилегированный. Так что есть все основания утверждать, конкретно этот бот действительно интегрирует функционал кошелька в основное приложение телеги.Что до того, насколько текущий функционал "полноценный", то это философский вопрос, и выход любой следующей версии телеги может в этом плане всё кардинально изменить. В этом плане намного важнее сам факт наличия интеграции, чем список реализованных на данный момент фич.
Вероятно, он не упомянут потому, что он никак не связан с темой статьи (суперапп) - это обычный некастодиальный кошелёк для очередной крипты, который по сути ничем не отличается от кучи других кошельков для других монет. На данный момент основная фишка монеты TON, отличающая её от всё остальной крипты, это именно интеграция с телегой - а при использовании TON Space никакой интеграции нет (максимум, если с натяжкой, то TON Space можно использовать в качестве "дополнения" к
@wallet, держа в нём основную часть своих средств, перекидывая по необходимости в/из кастодиальный@walletмелкие суммы на текущие расходы).Можно прогонять через прокси-счёт в другом банке, его не жалко если что и легко заменить другим аналогичным в другом банке.
А что, тупо в лоб легально купить крипту переводом с банковского счёта в РФ нельзя (без мутных типов-менял и p2p)? Напр. через bestchange.ru (или Вы как раз эти обменки и записали в категорию "мутных типов-менял")?
Вы явно не в теме. И стандарт есть, и альтернативные реализации есть (и давно). И UB никакого отношения к гонке не имеет.
А как же "краткость - сестра таланта"?
По сути вопроса: на мой взгляд фокусироваться при написании нужно на сути документа/статьи, а не на процессе написания. (И, да, всё что можно удалить из финального документа не вредя сути - безжалостно выкидывать или сокращать.) Мне лично хватает в мелких/средних документах вставлять в середину фразы "TODO что-то", а в больших вести отдельный раздел "TODO" со списком задач, которые необходимо сделать для завершения написания документа.
Passkeys/WebAuthn вообще и не про сертификаты и не про CLI. Это про то, чтобы юзер пароли не запоминал. Совсем другая задача и другое решение. Как это может помочь организовать доступ CLI к API сайта более простым способом чем application passwords - мне лично пока неясно. Как минимум это создаст зависимость CLI от внешнего аутентификатора (хардварного или программного), а они пока не особо популярны и распространены.
Он непопулярен потому, что управление (выдача, установка в браузеры, обновление, отзыв) этими клиентскими сертификатами - достаточно сложная и неудобная штука. Поэтому mTLS активно используется только на бэке, для аутентификации между микросервисами, где всё управление всеми сертификатами может делать (и автоматизировать) девопс компании.