Веб-разработка не обязательно делится на front/back! Это просто де факто стандарт для сколько-нибудь сложных современных сайтов, но это не значит, что так делать обязательно. Более того, это вообще бич современного сайтостроения: каждая заурядная страничка с парой картинок и несколькими абзацами текста норовит превратиться в кривое "приложение" со свистоперделками, выжирающая память и процессор и тянущая мегабайт js-говнокода.
Для простых задач и вообще при отсутствии серьёзного опыта может быть намного быстрее, проще и эффективнее с этим не заморачиваться и накидать сайт на шаблонах с каким-нибудь типовым фреймворком (был бы python я бы назвал django, в этих ваших go я не очень понимаю).
Проще всего не массовый сервис под ключ реализовывать, а найти нескольких достаточно надёжных долгосрочных клиентов, которые будут платить денежку и сами со своими хотелками разбираться.
Я, например, довольно долго хостил у себя сайт на битриксе для знакомых.
FOUREX, потому что screen придумали для совсем другого. Вот текущий пример вполне показателен: скрипт не стартует, а почему - непонятно. В systemd причины неработы скрипта можно было бы увидеть в логах. Вместе с временем, когда он упал или перезапустился.
Ну я бы включил логгирование в screen, раз уж такое дело, можно будет глянуть что ему не нравилрось.
Жиза, у нас тут админка для интеграции была и вечно из автозаполнения пароль очередного пользователя админки подставлялся в пароль интеграции... Сменили type на text и стало хорошо.
А до этого я воевал с lastpass, в котором всё это автозаполнение управляется как-то криво...
Zmtrk62, я не очень слежу, но вроде бы до сих пор их используют и часто рекомендуют для долгосрочных бэкапов.
Если нужно прям меганадёжно, то есть такая штука M-DISC, но видимо это не очень дёшево, плюс реальная надёжность может оказаться ниже маркетингового хвастовства.
Так что из простого варианта - всё же диски с возможностью их класть на полку (NAS, док-станция, сервер с HotSwap итд). Диски можно докупать, да и прочитать их можно где угодно в случае чего.
Легко водить гоночный болид или печь торты, когда у тебя есть база: знания, опыт, возможно даже документальные подтверждения (диплом, права, лицензия на вид деятельности итд). Когда ты ничего не умеешь, то нагуглить прям на трассе на скорости 100 км/ч на что нажать уже не получится и легко не будет. Или когда торт уже пересолен, то гугл не поможет.
С ботами всё точно так же: их легко делать тому, кто умеет программировать. Но кто этого не умеет - ему не будет легко. И проблема тут не в ботах, а именно в отсутствии базы и нежелании её получить.
Anonim1238, в информационной безопасности всегда должен рассматриваться наихудший сценарий, в котором злоумышленник получил максимум данных и может воспользоваться ими всеми возможными методами. Так что меняем все критичные пароли. В частности, те, которые могли фигурировать в Телеграме в переписках с другими людьми. Или вот если где-то в переписке или в "сохранённых сообщениях" (их многие используют как записную книжку) есть какие-нибудь реквизиты банковских карт - обязательно затеваем их перевыпуск, а до тех пор по возможности выносим деньги с карт (можно открыть в том же банке счёт онлайн и перекинуть деньги туда).
Anonim1238, например, если "игра" стырила файл сессии телеграмного клиента и отдала злоумышленнику. Или повредила его. Так что вполне допускаю, что такое может быть.
Вова Дружаев, честно говоря я не интересовался глубоко в устройстве комментариев. Они по сути цитируют по цепочке от первоначального поста, но сам пост в чате будет иметь другой id, есть ли там что-то для идентификации поста в канале - я не в курсе.
Для простых задач и вообще при отсутствии серьёзного опыта может быть намного быстрее, проще и эффективнее с этим не заморачиваться и накидать сайт на шаблонах с каким-нибудь типовым фреймворком (был бы python я бы назвал django, в этих ваших go я не очень понимаю).