мне не удалось найти в открытом доступе скоро-нибудь подробных книг касающихся собственно газогенераторных котлов сходных тем, которые использовались в авто, за исключением только некоторой обрывочной информации
Да чего там долго искать - это не утерянное знание, до сих пор народ мастерит себе повозки на дровах.
Лет 5-7 назад на хабре были пара статей от какого-то человека из Луганска, кажется, где он вполне подробно описывал как сделал себе машину с газогенератором и вполне себе хорошо ездит. Пробега хватает и мощности вполне достаточные. Сейчас что-то не смог найти эти статьи, но вот есть в гугле белорус с таким же девайсом.
С одной стороны, я понимаю что вы имеете в виду. Однако, "я бы мог с вами согласиться, но тогда мы бы оба оказались неправы" (с)
Для меня это выглядит как легитимизация неправильного подхода. И после прочтения может остаться желание оставить всё как есть: "смотри, другие так же делают". Однако, когда я объясняю что-то коллегам, я часто говорю "я сделал это вот так, но это НЕПРАВИЛЬНО, должно быть вот так, мы это должны переделать когда сможем", заводится таск в Jira и мозолит глаза.
Я согласен, вы в начале статьи постарались об этом предупредить, но я бы даже статью писать не стал, на вашем месте, простите. Я поставил минус, кажется, с "не согласен", но не видел смысла сильно объяснять свою позицию до тех пор, пока прохожий сеньор программист не выразил недоумение.
У меня на продакшене 5 серверов и сетап у них примерно как у вас - тоже есть bash-скрипт с начальными шагами. Но мне это очень не нравится, и мы планируем серьёзно это всё переделать.
Повторюсь - я сам так делаю, но считаю что это неправильно и учить такому не стоит.
Если ключ скомпрометирован, то нужно сменить все защищённым им секреты.
В общем-то да. Но кроме этого есть более простые сценарии. Например у вас украли кошелёк с флэшкой, на которой был ключ. Пока до него доберутся и поймут что это - у вас есть как минимум несколько часов, чтобы его сменить. Менять все секреты - это уж перебор. Вдобавок, ключ желательно ротировать время от времени, чтобы случайно засвеченный бэкап трёхлетней давности его не слил..
Что касается хранения секретов - это боль. Мне не нравится ни один менеджер паролей и я уже год не спеша (времени нет) пишу свой (с картами и девушками). На продакшене секреты хранятся и используются в Docker Secrets (Swarm), а чтобы их удобнее менять - у меня самописный менеджер для Swarm их умеет подменять.
Для серверов, которые нужно пересоздавать раз в 2-3 года - можно использовать что угодно, даже просто текстовый файлик со списком софта.
Проблема со своими скриптами - и я на это уже много раз натыкался сам - в том, что через эти 2-3 года внезапно обнаруживаешь, что сами скрипты устарели. Wireguard ставится из другого репозитория.. Для установки докера в старой инструкции можно было сделать add-apt-repository , а теперь нужно в keyrings писать ещё.. ssh слушает порт через systemd вместо конфига.. И скрипты надо править каждый раз, причём обнаруживаются все эти проблемы в тот момент, когда уже надо бы срочно всё восстановить..
В нормальном плейбуке все эти обновления уже отражены и плейбук "установи докер" установит его самым правильным на текущий момент способом.
Опять же - я не критикую сам подход, но хочу указать, что рекламировать нужно не его.
а где Вы предлагаете хранить секреты для пары личных серверов?
Я храню в keepass. И на серверах пишу в конфиги руками если нужно.
Мне кажется очевидным, что хранить секрет в git репозитории, даже зашифрованным, очень небезопасно. Оно же всю историю коммитов хранит. Если ключ шифрования скомпрометирован, то даже если вы его смените и перешифруете секреты - предыдущие коммиты доступны со старым ключом. Разделения доступа нет - это только для одного человека с одним ключом. Если нужно временно дать доступ только на часть секретов для коллеги - это невозможно, и отозвать доступ тоже непросто. Если репозиторий не на своём сервере, а на Github - то это вообще чужое облако.. На серверах я никогда не делаю git clone чтобы не давать доступ (даже readonly). В общем, небезопасно это всё.
Извольте. Я поставил минус. На мой взгляд, подход вполне распространённый, я сам так иногда делаю. Однако, это, простите, колхоз, и писать об этом статью как о достижении - моветон.
Идемпотентность и удалённый бутстрап - это Chef/Puppet/Salt/Ansible/etc. В зависимости от масштабов. А писать свои скрипты - это несерьёзно.
Хранить секреты в git - я этого вообще не понимаю, ну да бог вам судья, у каждого свой подход.
Ну, опять же, мы не знаем что у него в других комнатах. У него целая печка из свинцовых кирпичей есть - не случайно они у него там оказались. Может он на кухне на радиевой сковородке жарит..
Несомненно, они гораздо умнее меня и у них были свои мотивы, но, хотелось бы понять для чего был приделан PlainDateTime - это же очередной выстрел в ногу?
Это то, что мы называем «временем на стене», потому что, если представить аналоговые часы на стене, они не учитывают переход на летнее время или часовые пояса.
Тем не менее, часы на стене у меня дома и на стене в Австралии в один и тот же момент времени будут показывать разное (правильное) время.
И браузер пользователя из Австралии, который в командировке в Китае, формируя запрос на сервер, расположенный в Нью-Йорке, живущий по UTC таймзоне, должен указать какое время имелось в виду.
Хочется посоветовать использовать Chromium-GOST - отдельный браузер на базе Chromium. Для того, чтобы не хранить сертификаты и расширение в основном Chromium в системе.
Ну и интересно бы ваш сетап иметь в виде какого-нибудь контейнера типа snap или flatpack, чтобы легче поддерживать.
свой коаксиальный детектор PGT из особо чистого германия n-типа, стоящий в гостевой спальне дома (в наименее радиоактивной комнате, как это и должно быть), экранированный свинцовыми кирпичами и градуированным внутренним экраном из листов меди и олова.
Сетап для гостевой спальни - моё почтение... Остаётся представлять что у него там в других спальнях стоит...
С одной стороны - читал и плакал. kesn, как всегда, жгёт по-живому. Можно ещё добавить Makefile как пример боли "чукча писатель". Про JavaScript - есть классическое WAT видео.
С другой стороны - ну глупо предъявлять претензии bash - он 35 лет назад был придуман чтобы немного улучшить ещё более неудобные проблемы sh , никто не знал к чему это приведёт. Длинные имена файлов с пробелами в 1989 году, хм? Какие там альтернативы были для скриптинга тогда? И программисты менее избалованные были этими вашими пробелами и отступами, так что сравнивать его с Python - автор немного передергивает и сам это знает.
css - тоже, я подозреваю, что автор знает как исторически развивался этот языкстандарт синтаксис и сколько разных групп в него вложило.. то что вложило.. Одни префиксы --my-feature , которые поддерживаются только одним каким-то браузером - чего стоят..
Мы все погрязли в легаси, и так просто это не решить - надо всё сжечь и сделать заново. Ну, как бы, всем понятно, что этого не будет. Даже просто новый браузер написать - нужно 100 человек и 100 лет, и никто не будет им пользоваться пока он не начнёт поддерживать старые кривые сайты, которые все показывают правильно как хочет пользователь.
И да, я проголосовал "Принятие", потому что знаю почему так, сам уже делал так и знаю что без такой ситуации обойтись сложно. Всё меняется.
Честно говоря, таких статей даже на хабре полно, а уж гитхаб такими темплейтами завален вообще. Не обижайтесь на критику, но ничего нового тут не присутствует.
Здесь мы имеем типичный монорепозиторий, заточенный под один конкретный тип проектов. Ну хорошо, вот у вас телеграм-боты. А если ещё веб будет - его тоже в эту же папку мешать, несмотря на то, что там своя структура будет?
Makefile - ну, может быть, вы его и любите, но совершенно он здесь не нужен - хватит и обычного sh/bash. make может по дефолту не стоять, это отдельный пакет build-essential (на Ubuntu), а на рабочие сервера вообще девелоперские инструменты не рекомендуется ставить.
Я всегда критикую привычку использовать переменные окружения, а также класть конфиги в одну папку с кодом. У вас, похоже, оба пункта присутствуют.
Да чего там долго искать - это не утерянное знание, до сих пор народ мастерит себе повозки на дровах.
Лет 5-7 назад на хабре были пара статей от какого-то человека из Луганска, кажется, где он вполне подробно описывал как сделал себе машину с газогенератором и вполне себе хорошо ездит. Пробега хватает и мощности вполне достаточные. Сейчас что-то не смог найти эти статьи, но вот есть в гугле белорус с таким же девайсом.
С одной стороны, я понимаю что вы имеете в виду. Однако, "я бы мог с вами согласиться, но тогда мы бы оба оказались неправы" (с)
Для меня это выглядит как легитимизация неправильного подхода. И после прочтения может остаться желание оставить всё как есть: "смотри, другие так же делают". Однако, когда я объясняю что-то коллегам, я часто говорю "я сделал это вот так, но это НЕПРАВИЛЬНО, должно быть вот так, мы это должны переделать когда сможем", заводится таск в Jira и мозолит глаза.
Я согласен, вы в начале статьи постарались об этом предупредить, но я бы даже статью писать не стал, на вашем месте, простите. Я поставил минус, кажется, с "не согласен", но не видел смысла сильно объяснять свою позицию до тех пор, пока прохожий сеньор программист не выразил недоумение.
У меня на продакшене 5 серверов и сетап у них примерно как у вас - тоже есть bash-скрипт с начальными шагами. Но мне это очень не нравится, и мы планируем серьёзно это всё переделать.
Повторюсь - я сам так делаю, но считаю что это неправильно и учить такому не стоит.
В общем-то да. Но кроме этого есть более простые сценарии. Например у вас украли кошелёк с флэшкой, на которой был ключ. Пока до него доберутся и поймут что это - у вас есть как минимум несколько часов, чтобы его сменить. Менять все секреты - это уж перебор. Вдобавок, ключ желательно ротировать время от времени, чтобы случайно засвеченный бэкап трёхлетней давности его не слил..
Что касается хранения секретов - это боль. Мне не нравится ни один менеджер паролей и я уже год не спеша (времени нет) пишу свой (с картами и девушками). На продакшене секреты хранятся и используются в Docker Secrets (Swarm), а чтобы их удобнее менять - у меня самописный менеджер для Swarm их умеет подменять.
Для серверов, которые нужно пересоздавать раз в 2-3 года - можно использовать что угодно, даже просто текстовый файлик со списком софта.
Проблема со своими скриптами - и я на это уже много раз натыкался сам - в том, что через эти 2-3 года внезапно обнаруживаешь, что сами скрипты устарели. Wireguard ставится из другого репозитория.. Для установки докера в старой инструкции можно было сделать
add-apt-repository, а теперь нужно в keyrings писать ещё.. ssh слушает порт через systemd вместо конфига.. И скрипты надо править каждый раз, причём обнаруживаются все эти проблемы в тот момент, когда уже надо бы срочно всё восстановить..В нормальном плейбуке все эти обновления уже отражены и плейбук "установи докер" установит его самым правильным на текущий момент способом.
Опять же - я не критикую сам подход, но хочу указать, что рекламировать нужно не его.
Я храню в keepass. И на серверах пишу в конфиги руками если нужно.
Мне кажется очевидным, что хранить секрет в git репозитории, даже зашифрованным, очень небезопасно. Оно же всю историю коммитов хранит. Если ключ шифрования скомпрометирован, то даже если вы его смените и перешифруете секреты - предыдущие коммиты доступны со старым ключом. Разделения доступа нет - это только для одного человека с одним ключом. Если нужно временно дать доступ только на часть секретов для коллеги - это невозможно, и отозвать доступ тоже непросто. Если репозиторий не на своём сервере, а на Github - то это вообще чужое облако.. На серверах я никогда не делаю git clone чтобы не давать доступ (даже readonly). В общем, небезопасно это всё.
Извольте. Я поставил минус. На мой взгляд, подход вполне распространённый, я сам так иногда делаю. Однако, это, простите, колхоз, и писать об этом статью как о достижении - моветон.
Идемпотентность и удалённый бутстрап - это Chef/Puppet/Salt/Ansible/etc. В зависимости от масштабов. А писать свои скрипты - это несерьёзно.
Хранить секреты в git - я этого вообще не понимаю, ну да бог вам судья, у каждого свой подход.
Пугает это всё конечно. Скоро они ему руки приделают и оно пойдёт жрать мои котлеты в холодильнике.
Как же заедолбали эти сгенерированные картинки для КДПВ. Вы хоть сами читайте что там понаписано, а то уже антиреклама какая-то получается.
Ну вот что это?
Ну, опять же, мы не знаем что у него в других комнатах. У него целая печка из свинцовых кирпичей есть - не случайно они у него там оказались. Может он на кухне на радиевой сковородке жарит..
Интересно было бы пригласить @kreosan, если он ещё жив.
Несомненно, они гораздо умнее меня и у них были свои мотивы, но, хотелось бы понять для чего был приделан
PlainDateTime- это же очередной выстрел в ногу?Тем не менее, часы на стене у меня дома и на стене в Австралии в один и тот же момент времени будут показывать разное (правильное) время.
И браузер пользователя из Австралии, который в командировке в Китае, формируя запрос на сервер, расположенный в Нью-Йорке, живущий по UTC таймзоне, должен указать какое время имелось в виду.
Хочется посоветовать использовать Chromium-GOST - отдельный браузер на базе Chromium. Для того, чтобы не хранить сертификаты и расширение в основном Chromium в системе.
Ну и интересно бы ваш сетап иметь в виде какого-нибудь контейнера типа snap или flatpack, чтобы легче поддерживать.
Сетап для гостевой спальни - моё почтение... Остаётся представлять что у него там в других спальнях стоит...
С одной стороны - читал и плакал. kesn, как всегда, жгёт по-живому. Можно ещё добавить Makefile как пример боли "чукча писатель". Про JavaScript - есть классическое WAT видео.
С другой стороны - ну глупо предъявлять претензии bash - он 35 лет назад был придуман чтобы немного улучшить ещё более неудобные проблемы
sh, никто не знал к чему это приведёт. Длинные имена файлов с пробелами в 1989 году, хм? Какие там альтернативы были для скриптинга тогда? И программисты менее избалованные были этими вашими пробелами и отступами, так что сравнивать его с Python - авторнемногопередергивает и сам это знает.css - тоже, я подозреваю, что автор знает как исторически развивался этот
языкстандартсинтаксис и сколько разных групп в него вложило.. то что вложило.. Одни префиксы--my-feature, которые поддерживаются только одним каким-то браузером - чего стоят..Мы все погрязли в легаси, и так просто это не решить - надо всё сжечь и сделать заново. Ну, как бы, всем понятно, что этого не будет. Даже просто новый браузер написать - нужно 100 человек и 100 лет, и никто не будет им пользоваться пока он не начнёт поддерживать старые кривые сайты, которые все показывают
правильнокак хочет пользователь.И да, я проголосовал "Принятие", потому что знаю почему так, сам уже делал так и знаю что без такой ситуации обойтись сложно. Всё меняется.
Напомнило фильм "Скалолаз" с молодым Сталлоне...
@dimonomid тут ваш nerdlog пытаются повторить, но статью не читали.
Нужен бот на зарубежном сервере, с которым можно сделать типа видео звонок в одноклассниках и гнать трафик в видеопотоке.
Если заниматься эспандером для кисти время от времени - это как-то предупреждает такое заболевание? Или наоборот усиливает нагрузку?
Честно говоря, таких статей даже на хабре полно, а уж гитхаб такими темплейтами завален вообще. Не обижайтесь на критику, но ничего нового тут не присутствует.
Здесь мы имеем типичный монорепозиторий, заточенный под один конкретный тип проектов. Ну хорошо, вот у вас телеграм-боты. А если ещё веб будет - его тоже в эту же папку мешать, несмотря на то, что там своя структура будет?
Makefile - ну, может быть, вы его и любите, но совершенно он здесь не нужен - хватит и обычного sh/bash. make может по дефолту не стоять, это отдельный пакет build-essential (на Ubuntu), а на рабочие сервера вообще девелоперские инструменты не рекомендуется ставить.
Я всегда критикую привычку использовать переменные окружения, а также класть конфиги в одну папку с кодом. У вас, похоже, оба пункта присутствуют.
Хмм, то есть - если всё плохо, депрессия, бытовуха замучала, то... Надо забухать, а потом перестать, и скоро появятся силы!