Завоздушило, так завоздушило…
Решили мы тут с сыном посмотреть новый интерфейс 1С:Предприятие 8.5, которые позиционируется как «воздушный». Для ознакомления взяли небольшую, полностью самописную конфигурацию, которую он в прошлом году написал в качестве школьного проекта.
Конфигурация для учета домашних финансов и проста как мычание: приход, расход, перемещение, учет по кошелькам и статьям расходов/доходов. Никаких сложных форм, все очень просто, что тут может пойти не так?
Для конвертации форм мы воспользовались встроенным инструментом в разделе Рефакторинг, который много чего исправил и оптимизировал. При этом мы надеялись, что официальный инструмент покажет нам как правильно, как это задумано самой 1С.
На первом скриншоте показано как было. Основная страница представляла собой журнал операций и список кошельков с балансом в каждом из них, между частями формы есть видимая граница, которую мы можем перемещать, например, сделав журнал по шире.
Табличная часть журнала при этом автоматом масштабируется, но даже в начальном виде никаких вопросов нет, вся информация прекрасно помещается по ширине, еще и места хватает.
А что мы видим в конвертированной конфигурации? При том же размере окна форма не поместилась по вертикали и у нас возникла вертикальная прокрутка, а откуда она возникла?
Смотрим на таблицу – это полное фиаско, таблица обрезана как по горизонтали, так и по вертикали, потому что не поместилась, а чтобы добраться до горизонтальной прокрутки таблицы нам нужно прокрутить вниз саму форму.
Вообще-то, всю жизнь было принято вписывать таблицу в видимую часть формы и добавлять в нее полосы прокрутки, доступные без скролла страницы. Зачем здесь сделано такое поведение – непонятно.
Ладно, если у нас не хватает места по горизонтали, давайте свернем левое меню и жизнь наладится. Свернули. И что??? И ничего, таблице как было плохо, так и осталось, зато справа появилось пустое место, которое мы никак использовать не можем.
Не лучше выглядят и документы. В старом интерфейсе Такси была другая беда – по умолчанию таблицу растягивало на всю форму, что в случае простых табличек, как у нас, смотрелось не очень. Но все равно таблица четко визуально выделялась, как и итог справа внизу.
Новая форма показала принципиально иной подход, таблица скукожилась по горизонтали, хотя ее шапка по-прежнему занимает почти всю ширину формы и там у нас всегда будет пустое место, если мы, конечно не растянем таблицу руками.
Визуального выделения таблицы у нас нет и итоги просто потерялись, так как невозможно сразу понять, что это за цифра внизу и зачем она там, особенно если таблица маленькая.
Откроем другой документ, точно с такой же структурой и что это??? Что??? Откуда в табличной части взялась горизонтальная прокрутка, если справа еще полно свободного места???
А документ перемещения вообще по высоте не поместился, предлагая нам его скроллить, хотя в исходной форме того же размера мы могли по вертикали поместить содержимое документа два раза.
И вообще, новый интерфейс показывает жуткий дефицит свободного места, особенно по вертикали, хотя в Такси его было с избытком. И если у нас не помещаются уже простые формы, то что говорить о сложных документах?
С таким подходом у нас даже шапка без вертикального скролла не поместится, не говоря уже о табличных частях, где содержится основная информация. А это, если кто забыл, учетная система, а не приложение для домохозяек с двумя большими кнопками.
Учитывая то, что основное разрешение рабочих мониторов – это FullHD, то работать с «воздушными» формами будет сущим мучением, вы же не думаете, что работодатели сразу побегут покупать 2K или 4K мониторы, на которых «воздушным» формам места уже хватает.
Пока все это выглядит как крайне сырой прототип и был бы это действительно прототип – вопросов бы не было, но на интерфейс 8.5 уже переводят рабочие конфигурации (пока только УНФ 3.0 и Розница 3.0), причем в безальтернативном варианте.
Решили мы тут с сыном посмотреть новый интерфейс 1С:Предприятие 8.5, которые позиционируется как «воздушный». Для ознакомления взяли небольшую, полностью самописную конфигурацию, которую он в прошлом году написал в качестве школьного проекта.
Конфигурация для учета домашних финансов и проста как мычание: приход, расход, перемещение, учет по кошелькам и статьям расходов/доходов. Никаких сложных форм, все очень просто, что тут может пойти не так?
Для конвертации форм мы воспользовались встроенным инструментом в разделе Рефакторинг, который много чего исправил и оптимизировал. При этом мы надеялись, что официальный инструмент покажет нам как правильно, как это задумано самой 1С.
На первом скриншоте показано как было. Основная страница представляла собой журнал операций и список кошельков с балансом в каждом из них, между частями формы есть видимая граница, которую мы можем перемещать, например, сделав журнал по шире.
Табличная часть журнала при этом автоматом масштабируется, но даже в начальном виде никаких вопросов нет, вся информация прекрасно помещается по ширине, еще и места хватает.
А что мы видим в конвертированной конфигурации? При том же размере окна форма не поместилась по вертикали и у нас возникла вертикальная прокрутка, а откуда она возникла?
Смотрим на таблицу – это полное фиаско, таблица обрезана как по горизонтали, так и по вертикали, потому что не поместилась, а чтобы добраться до горизонтальной прокрутки таблицы нам нужно прокрутить вниз саму форму.
Вообще-то, всю жизнь было принято вписывать таблицу в видимую часть формы и добавлять в нее полосы прокрутки, доступные без скролла страницы. Зачем здесь сделано такое поведение – непонятно.
Ладно, если у нас не хватает места по горизонтали, давайте свернем левое меню и жизнь наладится. Свернули. И что??? И ничего, таблице как было плохо, так и осталось, зато справа появилось пустое место, которое мы никак использовать не можем.
Не лучше выглядят и документы. В старом интерфейсе Такси была другая беда – по умолчанию таблицу растягивало на всю форму, что в случае простых табличек, как у нас, смотрелось не очень. Но все равно таблица четко визуально выделялась, как и итог справа внизу.
Новая форма показала принципиально иной подход, таблица скукожилась по горизонтали, хотя ее шапка по-прежнему занимает почти всю ширину формы и там у нас всегда будет пустое место, если мы, конечно не растянем таблицу руками.
Визуального выделения таблицы у нас нет и итоги просто потерялись, так как невозможно сразу понять, что это за цифра внизу и зачем она там, особенно если таблица маленькая.
Откроем другой документ, точно с такой же структурой и что это??? Что??? Откуда в табличной части взялась горизонтальная прокрутка, если справа еще полно свободного места???
А документ перемещения вообще по высоте не поместился, предлагая нам его скроллить, хотя в исходной форме того же размера мы могли по вертикали поместить содержимое документа два раза.
И вообще, новый интерфейс показывает жуткий дефицит свободного места, особенно по вертикали, хотя в Такси его было с избытком. И если у нас не помещаются уже простые формы, то что говорить о сложных документах?
С таким подходом у нас даже шапка без вертикального скролла не поместится, не говоря уже о табличных частях, где содержится основная информация. А это, если кто забыл, учетная система, а не приложение для домохозяек с двумя большими кнопками.
Учитывая то, что основное разрешение рабочих мониторов – это FullHD, то работать с «воздушными» формами будет сущим мучением, вы же не думаете, что работодатели сразу побегут покупать 2K или 4K мониторы, на которых «воздушным» формам места уже хватает.
Пока все это выглядит как крайне сырой прототип и был бы это действительно прототип – вопросов бы не было, но на интерфейс 8.5 уже переводят рабочие конфигурации (пока только УНФ 3.0 и Розница 3.0), причем в безальтернативном варианте.
🤣26🤮7🤔4❤2💯2
Что такое современная платформа 1С:Предприятие и нужно ли ее знать администраторам
До сих пор замечаем со стороны коллег пренебрежительное отношение к 1С:Предприятие и нежелание изучать эту платформу или вообще касаться ее. Мол есть «одинэсники» — вот пусть они и занимаются, а мы «тру админы» и у нас другие задачи.
Но позиция эта в корне неправильная и ниже мы постараемся пояснить почему. А начнем с того, что нравится это кому-то или нет, но именно 1С:Предприятие сегодня является стандартом учетной системы де-факто.
И надо сказать, что на свои лидирующие позиции фирма 1С вышла сама, в достаточно жесткой конкурентной борьбе, кто застал конец 90-х и начало нулевых – тот помнит существовавший зоопарк на рынке учетного ПО.
Так чем же 1С:Предприятие сумело привлечь к себе пользователей на фоне многочисленных конкурентов? А тем, что 1С была и есть открытая система – исходный код конфигураций открыт и доступен для свободной доработки любому пользователю, правомерно владеющему системой.
И этот момент трудно переоценить, учет – это такая тонкая вещь, которая вроде и одинаковая, но не совсем. Бизнес-процессы везде разные и владельцам бизнеса закономерно хочется, чтобы программа как-то учитывала их особенности.
1С:Предприятие, как и другие учетные системы – товар коробочный, массовый и отражает некоторый средний бизнес в вакууме. Да, можно сказать, мол адаптируйте свои бизнес-процессы под программу, но бизнес – это не про то, как красиво и правильно, а про то, как заработать денег.
В 1С код конфигурации открыт, и любой пользователь может свободно адаптировать типовое решение под нужды своего бизнеса, а если вы не готовы столь глубоко лезть в систему, то к вашим услугам внешние отчеты и обработки, которые помогут получить нужные данные или выполнить некоторые действия.
Именно это стало киллер-фичей, теперь любой бизнесмен знал, что, покупая коробку с 1С:Предприятие он получает не только типовой функционал, но и возможность допилить решение именно под особенности своего бизнеса и именно так, как нужно ему, а не как видит разработчик.
Вместе с этим росла и сама платформа 1С:Предприятие, начиная с небольших файловых баз в формате DBF платформа превратилась сегодня в полноценное клиент-серверное приложение с широкими возможностями.
Не забыто и сетевое взаимодействие, сегодня для интеграции с внешними системами 1С:Предприятие предлагает Web и HTTP (REST) интерфейсы, Odata, работу через веб-сервер, мобильные приложения.
Да, проблемы у платформы 1С:Предприятие есть, их много, но это не повод к отрицанию, потому что реального конкурента у 1С сегодня нет. Именно как платформы уровня предприятия.
Есть много онлайн-сервисов, типа «Моя Бухгалтерия» и т.п., но по мере роста бизнеса их пользователи неизбежно приходят к вопросу: а как нам отсюда перейти на 1С?
А причем здесь системный администратор? А при том, что 1С сегодня, это не какое-то там приложение на компьютере в бухгалтерии, а полноценная клиент-серверная система.
Это и сам сервер 1С:Предприятие, и СУБД, и веб-сервисы, многие не в единственном экземпляре и обслуживать все это хозяйство будет именно системный администратор.
Но 1С:Предприятие, как и любая иная система, имеет свои особенности и не понимая их трудно добиться стабильной и производительной работы системы. Спихнуть проблему на другую сторону тоже не получится.
Мир 1С:Предприятие уже вполне взрослый и сформировавшийся, со своими ролями и профессиями. И программист 1С не будет разбираться почему у вас там тормозит, это не его задача и не его проблема.
А 1С:Предприяитие сейчас, это как минимум контур Бухгалтерия + Зарплата и там есть крайне чувствительные моменты, скажем как сроки сдачи отчетности. За ее срыв никого по голове не погладят.
Поэтому следует признать, что 1С:Предприятие – это один из стандартов, который уважающий себя специалист обязан знать хотя бы на базовом уровне.
До сих пор замечаем со стороны коллег пренебрежительное отношение к 1С:Предприятие и нежелание изучать эту платформу или вообще касаться ее. Мол есть «одинэсники» — вот пусть они и занимаются, а мы «тру админы» и у нас другие задачи.
Но позиция эта в корне неправильная и ниже мы постараемся пояснить почему. А начнем с того, что нравится это кому-то или нет, но именно 1С:Предприятие сегодня является стандартом учетной системы де-факто.
И надо сказать, что на свои лидирующие позиции фирма 1С вышла сама, в достаточно жесткой конкурентной борьбе, кто застал конец 90-х и начало нулевых – тот помнит существовавший зоопарк на рынке учетного ПО.
Так чем же 1С:Предприятие сумело привлечь к себе пользователей на фоне многочисленных конкурентов? А тем, что 1С была и есть открытая система – исходный код конфигураций открыт и доступен для свободной доработки любому пользователю, правомерно владеющему системой.
И этот момент трудно переоценить, учет – это такая тонкая вещь, которая вроде и одинаковая, но не совсем. Бизнес-процессы везде разные и владельцам бизнеса закономерно хочется, чтобы программа как-то учитывала их особенности.
1С:Предприятие, как и другие учетные системы – товар коробочный, массовый и отражает некоторый средний бизнес в вакууме. Да, можно сказать, мол адаптируйте свои бизнес-процессы под программу, но бизнес – это не про то, как красиво и правильно, а про то, как заработать денег.
В 1С код конфигурации открыт, и любой пользователь может свободно адаптировать типовое решение под нужды своего бизнеса, а если вы не готовы столь глубоко лезть в систему, то к вашим услугам внешние отчеты и обработки, которые помогут получить нужные данные или выполнить некоторые действия.
Именно это стало киллер-фичей, теперь любой бизнесмен знал, что, покупая коробку с 1С:Предприятие он получает не только типовой функционал, но и возможность допилить решение именно под особенности своего бизнеса и именно так, как нужно ему, а не как видит разработчик.
Вместе с этим росла и сама платформа 1С:Предприятие, начиная с небольших файловых баз в формате DBF платформа превратилась сегодня в полноценное клиент-серверное приложение с широкими возможностями.
Не забыто и сетевое взаимодействие, сегодня для интеграции с внешними системами 1С:Предприятие предлагает Web и HTTP (REST) интерфейсы, Odata, работу через веб-сервер, мобильные приложения.
Да, проблемы у платформы 1С:Предприятие есть, их много, но это не повод к отрицанию, потому что реального конкурента у 1С сегодня нет. Именно как платформы уровня предприятия.
Есть много онлайн-сервисов, типа «Моя Бухгалтерия» и т.п., но по мере роста бизнеса их пользователи неизбежно приходят к вопросу: а как нам отсюда перейти на 1С?
А причем здесь системный администратор? А при том, что 1С сегодня, это не какое-то там приложение на компьютере в бухгалтерии, а полноценная клиент-серверная система.
Это и сам сервер 1С:Предприятие, и СУБД, и веб-сервисы, многие не в единственном экземпляре и обслуживать все это хозяйство будет именно системный администратор.
Но 1С:Предприятие, как и любая иная система, имеет свои особенности и не понимая их трудно добиться стабильной и производительной работы системы. Спихнуть проблему на другую сторону тоже не получится.
Мир 1С:Предприятие уже вполне взрослый и сформировавшийся, со своими ролями и профессиями. И программист 1С не будет разбираться почему у вас там тормозит, это не его задача и не его проблема.
А 1С:Предприяитие сейчас, это как минимум контур Бухгалтерия + Зарплата и там есть крайне чувствительные моменты, скажем как сроки сдачи отчетности. За ее срыв никого по голове не погладят.
Поэтому следует признать, что 1С:Предприятие – это один из стандартов, который уважающий себя специалист обязан знать хотя бы на базовом уровне.
2👍31🤡8❤3💯3🤝1
Почему современное ПО такое неоптимизированное
Данный вопрос не раз и не два всплывает в обсуждениях, обычно винят во всем современных программистов, которые, мол, не хотят или не умеют в оптимизацию и все такое прочее.
Однако мало кто задумывается над другой стороной этой ситуации – современном рынке ПО. Потому что именно рынок обуславливает подходы к разработке и диктует правила.
Если мы вернемся в старые добрые времена, то увидим, что цикл разработки ПО был длительным, мажорный релиз – целое событие, которого ждали, к которому готовились. ПО достаточно долго и качественно тестировалось.
Но не потому, что раньше нравы были другие или специалисты круче. А потому что рынок ПО в то время был в основном представлен физическими носителями, а это было дорого и медленно. Поэтому если вы накосячили, то вы накосячили и это надолго. Либо рассылайте за свой счет патчи.
Что касается оптимизации, то ПО всегда писалось и пишется под средний современный ПК, со всеми вытекающими и если можно относительно безболезненно повысить системные требования, то это будет сделано, поэтому что сильно дешевле, чем оптимизация, которую особо никто не заметит.
По мере развития сети интернет дистрибуция ПО начала потихоньку переходить в него, пока полностью не вытеснила физические носители. Теперь программу можно просто скачать, а если можно просто скачать программу, то можно также просто скачать и исправление к ней.
Это резко сократило цикл разработки, теперь можно быстро проверить ПО на грубые ошибки, а всякие недоработки закрыть патчами. Да, пользователь тут выступает в роли тестера, но этот недостаток легко перекрывается многими достоинствами.
Какие же это достоинство? В основном – короткий цикл разработки и быстрое внедрение фич. Теперь вам не нужно ждать несколько лет следующего мажорного релиза чтобы получить новые функции, они появятся просто в очередном выпуске через несколько месяцев или полгода.
Да и само понятие мажорных релизов как-то неожиданно кануло в Лету, большинство программ перешли или на сквозную нумерацию, или по дате выпуска, скажем 2506, где сразу понятно насколько давно выпущен этот релиз.
В последние годы крайне серьезным фактором стал ИИ, который значительно ускорил процесс написания кода, а следовательно, позволяет еще сильнее сократить релизный цикл.
Погодите, а кто мешает мне сделать все по старинке, качественно и выпустить на рынок действительно серьезный продукт? Никто не мешает, только этот «серьезный» продукт на массовом рынке (а мы говорим именно про массовый рынок) никому не нужен.
В чем ценность любого ПО? Оно закрывает какие-то потребности пользователя и должно это делать наилучшим для пользователя образом. А еще оно должно развиваться и соответствовать всем современным требованиям.
ПО с длительным циклом разработки конкуренции на современном рынке не выдержит. Никто не будет ждать год пока вы реализуете там новые фичи, пусть даже сделаете это идеально.
Есть такая поговорка: лучше плохо ехать, чем хорошо стоять. Она как раз отражает суть происходящего сегодня на рынке ПО. Ваша программа может быть неидеальна, но она уже есть здесь и сейчас и поэтому она найдет своего пользователя.
А дальше – проще, набрав пользовательскую базу уже можно развивать и дорабатывать продукт в нужную сторону. Тем более что бизнес уже закрутился, работает.
Тем более, что вы видите, как пользователь использует ваш продукт, что ему нравится, что не нравится, что ему хочется, а какие возможности он не использует вообще.
И это гораздо лучше, чем вложить в длительную разработку время и деньги, а после выяснить, что вы промахнулись мимо целевой аудитории. Сегодня рынок такого не прощает.
Поэтому нравится нам это или не нравится, но современное ПО будет именно таким – на уровне поздней бета версии, с ошибками, недоработками, но при этом будет быстро и динамично развиваться.
Что касается ресурсов, то об этом тоже думать никто не будет, как тогда, так и сейчас основной ориентир – средний современный ПК, тянуть старые системы никто не будет.
Данный вопрос не раз и не два всплывает в обсуждениях, обычно винят во всем современных программистов, которые, мол, не хотят или не умеют в оптимизацию и все такое прочее.
Однако мало кто задумывается над другой стороной этой ситуации – современном рынке ПО. Потому что именно рынок обуславливает подходы к разработке и диктует правила.
Если мы вернемся в старые добрые времена, то увидим, что цикл разработки ПО был длительным, мажорный релиз – целое событие, которого ждали, к которому готовились. ПО достаточно долго и качественно тестировалось.
Но не потому, что раньше нравы были другие или специалисты круче. А потому что рынок ПО в то время был в основном представлен физическими носителями, а это было дорого и медленно. Поэтому если вы накосячили, то вы накосячили и это надолго. Либо рассылайте за свой счет патчи.
Что касается оптимизации, то ПО всегда писалось и пишется под средний современный ПК, со всеми вытекающими и если можно относительно безболезненно повысить системные требования, то это будет сделано, поэтому что сильно дешевле, чем оптимизация, которую особо никто не заметит.
По мере развития сети интернет дистрибуция ПО начала потихоньку переходить в него, пока полностью не вытеснила физические носители. Теперь программу можно просто скачать, а если можно просто скачать программу, то можно также просто скачать и исправление к ней.
Это резко сократило цикл разработки, теперь можно быстро проверить ПО на грубые ошибки, а всякие недоработки закрыть патчами. Да, пользователь тут выступает в роли тестера, но этот недостаток легко перекрывается многими достоинствами.
Какие же это достоинство? В основном – короткий цикл разработки и быстрое внедрение фич. Теперь вам не нужно ждать несколько лет следующего мажорного релиза чтобы получить новые функции, они появятся просто в очередном выпуске через несколько месяцев или полгода.
Да и само понятие мажорных релизов как-то неожиданно кануло в Лету, большинство программ перешли или на сквозную нумерацию, или по дате выпуска, скажем 2506, где сразу понятно насколько давно выпущен этот релиз.
В последние годы крайне серьезным фактором стал ИИ, который значительно ускорил процесс написания кода, а следовательно, позволяет еще сильнее сократить релизный цикл.
Погодите, а кто мешает мне сделать все по старинке, качественно и выпустить на рынок действительно серьезный продукт? Никто не мешает, только этот «серьезный» продукт на массовом рынке (а мы говорим именно про массовый рынок) никому не нужен.
В чем ценность любого ПО? Оно закрывает какие-то потребности пользователя и должно это делать наилучшим для пользователя образом. А еще оно должно развиваться и соответствовать всем современным требованиям.
ПО с длительным циклом разработки конкуренции на современном рынке не выдержит. Никто не будет ждать год пока вы реализуете там новые фичи, пусть даже сделаете это идеально.
Есть такая поговорка: лучше плохо ехать, чем хорошо стоять. Она как раз отражает суть происходящего сегодня на рынке ПО. Ваша программа может быть неидеальна, но она уже есть здесь и сейчас и поэтому она найдет своего пользователя.
А дальше – проще, набрав пользовательскую базу уже можно развивать и дорабатывать продукт в нужную сторону. Тем более что бизнес уже закрутился, работает.
Тем более, что вы видите, как пользователь использует ваш продукт, что ему нравится, что не нравится, что ему хочется, а какие возможности он не использует вообще.
И это гораздо лучше, чем вложить в длительную разработку время и деньги, а после выяснить, что вы промахнулись мимо целевой аудитории. Сегодня рынок такого не прощает.
Поэтому нравится нам это или не нравится, но современное ПО будет именно таким – на уровне поздней бета версии, с ошибками, недоработками, но при этом будет быстро и динамично развиваться.
Что касается ресурсов, то об этом тоже думать никто не будет, как тогда, так и сейчас основной ориентир – средний современный ПК, тянуть старые системы никто не будет.
👍16🤔8🤮6❤3👎2
Сколько сегодня нужно ОЗУ для нормальной работы
Еще одна актуальная тема, которая часто сводится к тому, что раньше деревья были зеленее, небо синее, пиво вкуснее, девушки моложе…
Но живем мы не в тех далеких и светлых временах, а в нашей современности, со своими подходами, задачами и технологиями.
Если мы посмотрим минимальные требования современных ОС, таких как Windows 11 или Ubuntu 24.04, то увидим там от 4 ГБ и выше. У Windows 10 правда до сих пор стоит 2 ГБ, но это было написано давно и неправда, меньше 4 ГБ ей тоже лучше не предлагать.
А вот новая Ubuntu 26.04 вообще порадовала нас минимальными 6 ГБ ОЗУ, вот, как хотите, так это и понимайте…
Да куда же им столько??? Все туда, память – это ресурс и последние годы этот ресурс становился все более дешевым и все более доступным, текущий всплеск цен на рынке памяти общую тенденцию не меняет.
А если есть ресурс, то его надо использовать, иначе зачем он нам? И его используют, хотя многие инновации остаются под капотом и невооруженным глазом не видны. Хотя есть и хорошие примеры: в Windows 11 инструмент Ножницы обзавелся собственной OCR, теперь чтобы распознать текст со сканера, фото или скриншота вам не нужен сторонний софт.
В общем сегодня 4 ГБ — это нижний порог работоспособной системы и не важно, что вы на ней запускаете, Windows или Linux. Потому что основные потребители ОЗУ – это не ОС, а прикладное ПО, в первую очередь браузер.
И это мы не говорим про комфортную работу, 4 ГБ это про то, что у нас система просто как-то работает, но мы прямо чувствуем, что ограничены со всех сторон, как старой тесной одеждой, из которой выросли.
Если вы собираете сегодня ПК даже с самыми скромными требованиями, то смысла ставить туда менее 8 ГБ памяти нет, если вы только не хотите ежедневно и ежечасно страдать. Именно от 8 ГБ сегодня можно более-менее комфортно работать, но без претензий на что-то большее.
Сегодня 8 ГБ – стартовый уровень объема ОЗУ, меньше которого уже просто нет смысла и который уже совсем скоро может стать нижним порогом, смотрите требования Ubuntu 26.04 выше.
Если же мы говорим о системе начального уровня, но свободной от ограничений: нормальный офисный ПК, ноутбук для поездок и т.д. и т.п., когда мы хотим нормально работать и отдыхать, но сознательно не предполагаем запуска тяжелых приложений – то 16 ГБ сегодня норма жизни.
Игровая станция? Рабочий ПК специалиста? Меньше 32 ГБ даже не думайте, а лучше сразу 64 ГБ. Когда-то это было роскошью и признаком гиков или крутых спецов, которые знали зачем им столько ОЗУ, теперь это просто объективная реальность.
Поэтому сегодня берем на вооружение простую формулу: 16 - 32 - 64. Бюджет, средние системы, верхний уровень, при том, что мы указали минимальные рамки.
И не нужно говорить, что это дорого, недоступно и все такое прочее. Фарш в обратную сторону не проворачивается, а пользователи привыкли к определенному уровню возможностей ОС и приложений. И затягивать пояса они не готовы.
Технологии развиваются, они требуют ресурсов, но благодаря этим ресурсам пользователи получают различные возможности, которых раньше у них не было, хотя могут этого и не замечать.
Сегодня любой современный ПК спокойно переварит редактирование 4К видео, хотя еще лет 10 назад под это потребовалась бы мощная многопроцессорная рабочая станция.
Поэтому, если мы хотим оставаться в современном мире, то надо шагать в ногу. И выбирать объем ОЗУ не только с оглядкой на сегодня, но и прикинув что будет завтра. А как показывает практика – ОЗУ много не бывает.
Еще одна актуальная тема, которая часто сводится к тому, что раньше деревья были зеленее, небо синее, пиво вкуснее, девушки моложе…
Но живем мы не в тех далеких и светлых временах, а в нашей современности, со своими подходами, задачами и технологиями.
Если мы посмотрим минимальные требования современных ОС, таких как Windows 11 или Ubuntu 24.04, то увидим там от 4 ГБ и выше. У Windows 10 правда до сих пор стоит 2 ГБ, но это было написано давно и неправда, меньше 4 ГБ ей тоже лучше не предлагать.
А вот новая Ubuntu 26.04 вообще порадовала нас минимальными 6 ГБ ОЗУ, вот, как хотите, так это и понимайте…
Да куда же им столько??? Все туда, память – это ресурс и последние годы этот ресурс становился все более дешевым и все более доступным, текущий всплеск цен на рынке памяти общую тенденцию не меняет.
А если есть ресурс, то его надо использовать, иначе зачем он нам? И его используют, хотя многие инновации остаются под капотом и невооруженным глазом не видны. Хотя есть и хорошие примеры: в Windows 11 инструмент Ножницы обзавелся собственной OCR, теперь чтобы распознать текст со сканера, фото или скриншота вам не нужен сторонний софт.
В общем сегодня 4 ГБ — это нижний порог работоспособной системы и не важно, что вы на ней запускаете, Windows или Linux. Потому что основные потребители ОЗУ – это не ОС, а прикладное ПО, в первую очередь браузер.
И это мы не говорим про комфортную работу, 4 ГБ это про то, что у нас система просто как-то работает, но мы прямо чувствуем, что ограничены со всех сторон, как старой тесной одеждой, из которой выросли.
Если вы собираете сегодня ПК даже с самыми скромными требованиями, то смысла ставить туда менее 8 ГБ памяти нет, если вы только не хотите ежедневно и ежечасно страдать. Именно от 8 ГБ сегодня можно более-менее комфортно работать, но без претензий на что-то большее.
Сегодня 8 ГБ – стартовый уровень объема ОЗУ, меньше которого уже просто нет смысла и который уже совсем скоро может стать нижним порогом, смотрите требования Ubuntu 26.04 выше.
Если же мы говорим о системе начального уровня, но свободной от ограничений: нормальный офисный ПК, ноутбук для поездок и т.д. и т.п., когда мы хотим нормально работать и отдыхать, но сознательно не предполагаем запуска тяжелых приложений – то 16 ГБ сегодня норма жизни.
Игровая станция? Рабочий ПК специалиста? Меньше 32 ГБ даже не думайте, а лучше сразу 64 ГБ. Когда-то это было роскошью и признаком гиков или крутых спецов, которые знали зачем им столько ОЗУ, теперь это просто объективная реальность.
Поэтому сегодня берем на вооружение простую формулу: 16 - 32 - 64. Бюджет, средние системы, верхний уровень, при том, что мы указали минимальные рамки.
И не нужно говорить, что это дорого, недоступно и все такое прочее. Фарш в обратную сторону не проворачивается, а пользователи привыкли к определенному уровню возможностей ОС и приложений. И затягивать пояса они не готовы.
Технологии развиваются, они требуют ресурсов, но благодаря этим ресурсам пользователи получают различные возможности, которых раньше у них не было, хотя могут этого и не замечать.
Сегодня любой современный ПК спокойно переварит редактирование 4К видео, хотя еще лет 10 назад под это потребовалась бы мощная многопроцессорная рабочая станция.
Поэтому, если мы хотим оставаться в современном мире, то надо шагать в ногу. И выбирать объем ОЗУ не только с оглядкой на сегодня, но и прикинув что будет завтра. А как показывает практика – ОЗУ много не бывает.
1👍29❤7👎6🥱3🤮1
Про IPsec для самых маленьких
Набор протоколов IPsec широко используется для защиты сетевых соединений, но он же вызывает наибольшее количество затруднений у начинающих пользователей (и не только).
Очевидный плюс IPsec – высокий уровень надежности и защиты, а дальше пошли сплошные минусы. Как следует из названия IPsec работает на сетевом уровне и использует протокол IP, что делает его универсальным и прозрачным для любых вышестоящих протоколов.
При этом IPsec не плодит никаких лишних сущностей: новых соединений, интерфейсов и т.д. и т.п. Т.е. вы как работали с IP, так и продолжаете работать, а IPsec тихо и незаметно делает свое дело.
Это и обуславливает его широкое распространение, вам не нужно думать о поддержке IPsec со стороны своего сетевого приложения, достаточно того, что оно может работать с IP. И это же является основной сложностью для работающих с ним администраторов.
Правила обработки трафика IPsec задаются политиками и основаны на адресах источника и назначения пакета. Никаких интерфейсов - только адреса, маршрутизация тоже не работает. Точнее она работает, но там, где должна работать, на принятие решения о том, будет зашифрован IP-пакет или нет она не влияет.
IPsec может работать в двух режимах – туннельном и транспортном. Начнем с транспортного, в этом случае шифруется только полезное содержимое IP -пакета, заголовки оставляются в неизменном виде.
Это удобно для защиты трафика между узлами, имеющими внешние IP-адреса, что позволяет шифровать только полезное содержимое и исключить дополнительные накладные расходы.
В туннельном режиме пакет шифруется полностью, со всеми заголовками и помещается внутрь нового пакета, который отправляется второй стороне, указанной в настройках IPsec соединения.
В данном случае IPsec работает как классический туннель с инкапсуляцией пакетов, но то, какие пакеты будут инкапсулированы определяется также политиками, а не маршрутизацией.
А далее такой пакет и неважно туннельный или транспортный режим там используется пойдет, как и любой другой по всем правилам брандмауэра и установленным маршрутам.
Здесь появляется очередная сложность – избежать дополнительной обработки такого пакета брандмауэром и особенно NAT, в противном случае изменятся его адреса источника / назначения, и он перестанет соответствовать политикам IPsec. Все это решаемо, но требует определенных знаний и понимания.
Ну и, наконец, работать IPsec может совершенно на разных уровнях. Например, часто мы говорим, что подняли туннель GRE over IPsec, а кто-то может поднять IPsec over GRE. Казалось бы, какая разница, все равно у нас есть зашифрованный туннель. Но разница есть, и она огромная.
GRE over IPsec обозначает что мы поднимаем GRE-туннель не предусматривающий никакого шифрования поверх уже установленного IPsec соединения между узлами.
Что это значит? А то, что между узлами А и Б при помощи IPsec будет защищен любой IP-трафик, а не только GRE. Вы можете гонять там что угодно и все это будет также защищено при помощи IPsec.
А если мы поднимем IPsec over GRE, то в этом случае мы создаем между узлами А и Б незашифрованный туннель, но все что ходит в этом туннеле и только шифруется с помощью IPsec. Только то, что в туннеле, а не весь трафик между внешними узлами.
Причем право на жизнь имеют обе модели, все зависит от задач, но разница между ними более чем существенна и без понимания таких тонкостей можно наделать откровенно странных конструкций или недоумевать, почему сеть работает не так, как «задумано».
Поэтому перед тем, как бездумно настраивать IPsec уделите время на хотя бы обзорное знакомство с этим набором протоколов, чтобы вы хотя бы на базовом уровне имели представление как это взаимодействует между собой и почему работает именно так, а не иначе.
Набор протоколов IPsec широко используется для защиты сетевых соединений, но он же вызывает наибольшее количество затруднений у начинающих пользователей (и не только).
Очевидный плюс IPsec – высокий уровень надежности и защиты, а дальше пошли сплошные минусы. Как следует из названия IPsec работает на сетевом уровне и использует протокол IP, что делает его универсальным и прозрачным для любых вышестоящих протоколов.
При этом IPsec не плодит никаких лишних сущностей: новых соединений, интерфейсов и т.д. и т.п. Т.е. вы как работали с IP, так и продолжаете работать, а IPsec тихо и незаметно делает свое дело.
Это и обуславливает его широкое распространение, вам не нужно думать о поддержке IPsec со стороны своего сетевого приложения, достаточно того, что оно может работать с IP. И это же является основной сложностью для работающих с ним администраторов.
Правила обработки трафика IPsec задаются политиками и основаны на адресах источника и назначения пакета. Никаких интерфейсов - только адреса, маршрутизация тоже не работает. Точнее она работает, но там, где должна работать, на принятие решения о том, будет зашифрован IP-пакет или нет она не влияет.
IPsec может работать в двух режимах – туннельном и транспортном. Начнем с транспортного, в этом случае шифруется только полезное содержимое IP -пакета, заголовки оставляются в неизменном виде.
Это удобно для защиты трафика между узлами, имеющими внешние IP-адреса, что позволяет шифровать только полезное содержимое и исключить дополнительные накладные расходы.
В туннельном режиме пакет шифруется полностью, со всеми заголовками и помещается внутрь нового пакета, который отправляется второй стороне, указанной в настройках IPsec соединения.
В данном случае IPsec работает как классический туннель с инкапсуляцией пакетов, но то, какие пакеты будут инкапсулированы определяется также политиками, а не маршрутизацией.
А далее такой пакет и неважно туннельный или транспортный режим там используется пойдет, как и любой другой по всем правилам брандмауэра и установленным маршрутам.
Здесь появляется очередная сложность – избежать дополнительной обработки такого пакета брандмауэром и особенно NAT, в противном случае изменятся его адреса источника / назначения, и он перестанет соответствовать политикам IPsec. Все это решаемо, но требует определенных знаний и понимания.
Ну и, наконец, работать IPsec может совершенно на разных уровнях. Например, часто мы говорим, что подняли туннель GRE over IPsec, а кто-то может поднять IPsec over GRE. Казалось бы, какая разница, все равно у нас есть зашифрованный туннель. Но разница есть, и она огромная.
GRE over IPsec обозначает что мы поднимаем GRE-туннель не предусматривающий никакого шифрования поверх уже установленного IPsec соединения между узлами.
Что это значит? А то, что между узлами А и Б при помощи IPsec будет защищен любой IP-трафик, а не только GRE. Вы можете гонять там что угодно и все это будет также защищено при помощи IPsec.
А если мы поднимем IPsec over GRE, то в этом случае мы создаем между узлами А и Б незашифрованный туннель, но все что ходит в этом туннеле и только шифруется с помощью IPsec. Только то, что в туннеле, а не весь трафик между внешними узлами.
Причем право на жизнь имеют обе модели, все зависит от задач, но разница между ними более чем существенна и без понимания таких тонкостей можно наделать откровенно странных конструкций или недоумевать, почему сеть работает не так, как «задумано».
Поэтому перед тем, как бездумно настраивать IPsec уделите время на хотя бы обзорное знакомство с этим набором протоколов, чтобы вы хотя бы на базовом уровне имели представление как это взаимодействует между собой и почему работает именно так, а не иначе.
👍21❤3🤮1
Стандартное - Нестандартное
В админской среде всегда любили и любят всякое нестандартное, возводя это в достоинство и формируя мнение, что любой админ должен уметь нечто такое, что недоступно остальным и позволит выкрутиться из любой ситуации.
В итоге очень и очень многие решения идут вопреки стандартным практикам и фактически представляют из себя костыли и изоленту.
Кто-то виртуозно владеет скриптами, кто-то выучил справочник твиков реестра и т.д. и т.п. И считается что это хорошо.
Нет, знания и умения – это однозначно хорошо, но, когда они идут в разрез с общепринятыми практиками – это плохо.
Попытка решить стандартные вопросы нестандартными средствами – это плохо. И никакие оправдания тут не могут быть уместны.
Исключения – это специфические системы, например, высоконагруженные, но там админы прекрасно понимают, что делают и там у них есть свои стандартные практики, которые всем остальным просто не нужны.
Попытки применять нестандартные средства говорят только об одном – администратор не владеет базовыми навыками администрирования системы, подменяя их собственными костылями.
Столь же плохо применение в системах общего назначения каких-то специализированных практик, какими бы они «крутыми» и «навороченными» не казались.
Мы не раз сталкивались с нестандартными настройками и твиками, которые вызывали сложности на ровном месте. А когда начинали выяснять что это и зачем, то могли услышать примерно следующее:
- Ну это крутые пацаны из High Load рекомендуют?
- А у тебя высокая нагрузка?
- Нет, но…
Или:
- Ну это защита от сетевых атак…
- Тебя кто-то атакует?
- Нет, но…
Все это, конечно, может выглядеть круто, но, по сути, это не дает никаких плюсов, а только сплошные минусы.
Подобные настройки могут вызывать потенциальные конфликты, приводить к сложностям в поддержке или администрировании и даже стать причиной отказов, если незнакомый с ними администратор применит настройки, явно приводящие к конфликту.
Поэтому если у вас самая обычная система, которая не испытывает высоких нагрузок и которую никто не атакует, то и настройки в ней должны быть самые стандартные, сделанные стандартными для этой системы механизмами.
И именно это будет хорошо и правильно. Потому что позволит любому знакомому с системой специалисту быстро разобраться в ней и продолжить поддержку в отсутствие ее основного «архитектора».
И все порывы сделать «лучше», «быстрее», «дешевле» и т.п. нестандартными методами должны жестко пресекаться, как контролем, так и самоконтролем.
Потому что все эти костыли и изолента имеют свойство выстреливать в самый неподходящий момент. И делать это достаточно больно.
Здесь я еще раз напомню, что платят нам не за наши пируэты и изыски, тот кто платит – он и слов таких не знает. А платят нам за стабильную и предсказуемую работу.
Если вы вчера сэкономили нестандартным решением десять тысяч рублей, а сегодня, во время вашего отпуска все это упало и разбирались с вашими художествами несколько часов, понеся убытки на сотни тысяч, то ваши мотивы никто из лиц принимающих решения просто не поймет. Со всеми вытекающими оргвыводами.
Поэтому, подводя итоги, можно сказать, что следовать стандартным практикам, даже если они не совсем оптимальны – это хорошо. А городить собственные нестандартные решения – плохо.
При этом мы не хотим сказать, что нестандартные решения не имеют права на существование. Иногда без них никак. Но при этом они должны быть именно нестандартными и становиться личным стандартом де факто.
Но даже применяя нестандартные решения нужно стараться максимально их стандартизовать: использовать стандартные пути размещения файлов, понятные наименования скриптов и переменных в них. Т.е. сделать работу с ними максимально понятной третьему лицу, который увидит это в первый раз.
Ну и конечно не забыть все это документировать. И часть документации будет совсем не лишним разместить прямо здесь, лучше всего в комментариях к скрипту или в виде файла где-то рядом.
В админской среде всегда любили и любят всякое нестандартное, возводя это в достоинство и формируя мнение, что любой админ должен уметь нечто такое, что недоступно остальным и позволит выкрутиться из любой ситуации.
В итоге очень и очень многие решения идут вопреки стандартным практикам и фактически представляют из себя костыли и изоленту.
Кто-то виртуозно владеет скриптами, кто-то выучил справочник твиков реестра и т.д. и т.п. И считается что это хорошо.
Нет, знания и умения – это однозначно хорошо, но, когда они идут в разрез с общепринятыми практиками – это плохо.
Попытка решить стандартные вопросы нестандартными средствами – это плохо. И никакие оправдания тут не могут быть уместны.
Исключения – это специфические системы, например, высоконагруженные, но там админы прекрасно понимают, что делают и там у них есть свои стандартные практики, которые всем остальным просто не нужны.
Попытки применять нестандартные средства говорят только об одном – администратор не владеет базовыми навыками администрирования системы, подменяя их собственными костылями.
Столь же плохо применение в системах общего назначения каких-то специализированных практик, какими бы они «крутыми» и «навороченными» не казались.
Мы не раз сталкивались с нестандартными настройками и твиками, которые вызывали сложности на ровном месте. А когда начинали выяснять что это и зачем, то могли услышать примерно следующее:
- Ну это крутые пацаны из High Load рекомендуют?
- А у тебя высокая нагрузка?
- Нет, но…
Или:
- Ну это защита от сетевых атак…
- Тебя кто-то атакует?
- Нет, но…
Все это, конечно, может выглядеть круто, но, по сути, это не дает никаких плюсов, а только сплошные минусы.
Подобные настройки могут вызывать потенциальные конфликты, приводить к сложностям в поддержке или администрировании и даже стать причиной отказов, если незнакомый с ними администратор применит настройки, явно приводящие к конфликту.
Поэтому если у вас самая обычная система, которая не испытывает высоких нагрузок и которую никто не атакует, то и настройки в ней должны быть самые стандартные, сделанные стандартными для этой системы механизмами.
И именно это будет хорошо и правильно. Потому что позволит любому знакомому с системой специалисту быстро разобраться в ней и продолжить поддержку в отсутствие ее основного «архитектора».
И все порывы сделать «лучше», «быстрее», «дешевле» и т.п. нестандартными методами должны жестко пресекаться, как контролем, так и самоконтролем.
Потому что все эти костыли и изолента имеют свойство выстреливать в самый неподходящий момент. И делать это достаточно больно.
Здесь я еще раз напомню, что платят нам не за наши пируэты и изыски, тот кто платит – он и слов таких не знает. А платят нам за стабильную и предсказуемую работу.
Если вы вчера сэкономили нестандартным решением десять тысяч рублей, а сегодня, во время вашего отпуска все это упало и разбирались с вашими художествами несколько часов, понеся убытки на сотни тысяч, то ваши мотивы никто из лиц принимающих решения просто не поймет. Со всеми вытекающими оргвыводами.
Поэтому, подводя итоги, можно сказать, что следовать стандартным практикам, даже если они не совсем оптимальны – это хорошо. А городить собственные нестандартные решения – плохо.
При этом мы не хотим сказать, что нестандартные решения не имеют права на существование. Иногда без них никак. Но при этом они должны быть именно нестандартными и становиться личным стандартом де факто.
Но даже применяя нестандартные решения нужно стараться максимально их стандартизовать: использовать стандартные пути размещения файлов, понятные наименования скриптов и переменных в них. Т.е. сделать работу с ними максимально понятной третьему лицу, который увидит это в первый раз.
Ну и конечно не забыть все это документировать. И часть документации будет совсем не лишним разместить прямо здесь, лучше всего в комментариях к скрипту или в виде файла где-то рядом.
👍24🤮2🔥1🥱1
Статья с пола или распространенные юридические заблуждения
В очередной раз столкнулись с распространенным заблуждением коллег, которые считают вполне допустимой ситуацию с уничтожением результата своей работы в отсутствие оплаты от заказчика, мол что такого – я вернул все как было, в исходное состояние.
Это очень опасное заблуждение, основанное на неверном применении правил обычной, бытовой логики, в то время как Закон смотрит на эту ситуацию совсем по-другому.
Начнем с базового момента: чужая инфраструктура – это чужая собственность и результат ваше работы на этой инфраструктуре тоже принадлежит заказчику, он автоматически становится его собственностью по факту принятия работы.
До тех пор, пока заказчик не принял работу вы не вправе требовать с него оплаты – нет основания, нет результата, за который он вам должен заплатить. Да, вы вправе просить аванс, но в этом случае до получения аванса вы не приступаете к работам. Нет аванса – нет работы.
Если вы просите оплату за работу, это подразумевает сдачу результата работ заказчику, так как только после этого у него возникает обязанность вам заплатить, но это и означает, что результат работ его собственность.
Уничтожение собственности заказчика, неважно, просто вы там все стерли, или просто откатили как было может быть расценен в зависимости от сопутствующих обстоятельств как:
▫️ Самоуправство (ст. 330 УК РФ). Самовольное осуществление своего права (реального или мнимого) вопреки установленному законом порядку.
▫️ Неправомерный доступ к компьютерной информации (ст. 272 УК РФ).
Подождите, какой неправомерный, он же сам выдал все пароли и доступы! Но обладание возможностью доступа не говорит о его правомерности. Во-первых, доступ вам выдали для процесса настройки, а не для деструктивных действий. Во-вторых, закончив процесс настройки и сдав работы вы теряете право правомерного доступа.
Но даже если вы сильно будете настаивать на правомерности, скажем вы там еще и поддержкой занимаетесь, то свободно получите другую статью:
▫️ Нарушение правил эксплуатации средств хранения, обработки или передачи компьютерной информации и информационно-телекоммуникационных сетей (ст. 274 УК РФ).
Потому как доступ вам предоставляли не для деструктивных целей, а для поддержки и обслуживания и вы нарушили правила эксплуатации, что привело к деструктивным последствиям.
Но и тут не все так просто, потому как в действие вступает Статья 25 УК РФ (Преступление, совершенное умышленно).
Потому что есть объект преступления – информационная инфраструктура, принадлежащая заказчику, есть прямой умысел - вы осознаете, что удаляете данные, предвидите вред и желаете его. И есть общественно опасные последствия – прямой или косвенный ущерб заказчику, нарушение работы инфраструктуры.
Если заказчик в результате ваших действий понес реальный ущерб: остановились продажи, перестал работать сайт, были удалены или оказались блокированы данные, то тут можно дополнительно поднять еще одну статейку:
▫️ Умышленные уничтожение или повреждение имущества (ст. 167 УК РФ) несмотря на то, что программное обеспечение имуществом (вещью) не является.
Логика правоохранительных органов здесь такая: если в результате удаления ПО сервер (вещь) вышел из строя, не обязательно физически, достаточно невозможности использования оборудования по назначению и это принесло реальный ущерб – то это умышленное повреждение имущества.
Получается, что наш коллега кругом не прав и не имеет возможности защитить себя от кидка? Имеет, только нужно использовать подходящие для этого нормы права:
▫️ Право подрядчика на удержание (ст. 712 ГК РФ)
Согласно которой он имеет право удерживать результаты своего труда до полной его оплаты. Т.е. в нашем случае правомерно не предавать полный доступ (учетную запись администратора) до полного выполнения заказчиком своих обязательств.
Но самовольно уничтожать или еще каким-либо образом распоряжаться имуществом заказчика вы не имеете права.
В очередной раз столкнулись с распространенным заблуждением коллег, которые считают вполне допустимой ситуацию с уничтожением результата своей работы в отсутствие оплаты от заказчика, мол что такого – я вернул все как было, в исходное состояние.
Это очень опасное заблуждение, основанное на неверном применении правил обычной, бытовой логики, в то время как Закон смотрит на эту ситуацию совсем по-другому.
Начнем с базового момента: чужая инфраструктура – это чужая собственность и результат ваше работы на этой инфраструктуре тоже принадлежит заказчику, он автоматически становится его собственностью по факту принятия работы.
До тех пор, пока заказчик не принял работу вы не вправе требовать с него оплаты – нет основания, нет результата, за который он вам должен заплатить. Да, вы вправе просить аванс, но в этом случае до получения аванса вы не приступаете к работам. Нет аванса – нет работы.
Если вы просите оплату за работу, это подразумевает сдачу результата работ заказчику, так как только после этого у него возникает обязанность вам заплатить, но это и означает, что результат работ его собственность.
Уничтожение собственности заказчика, неважно, просто вы там все стерли, или просто откатили как было может быть расценен в зависимости от сопутствующих обстоятельств как:
▫️ Самоуправство (ст. 330 УК РФ). Самовольное осуществление своего права (реального или мнимого) вопреки установленному законом порядку.
▫️ Неправомерный доступ к компьютерной информации (ст. 272 УК РФ).
Подождите, какой неправомерный, он же сам выдал все пароли и доступы! Но обладание возможностью доступа не говорит о его правомерности. Во-первых, доступ вам выдали для процесса настройки, а не для деструктивных действий. Во-вторых, закончив процесс настройки и сдав работы вы теряете право правомерного доступа.
Но даже если вы сильно будете настаивать на правомерности, скажем вы там еще и поддержкой занимаетесь, то свободно получите другую статью:
▫️ Нарушение правил эксплуатации средств хранения, обработки или передачи компьютерной информации и информационно-телекоммуникационных сетей (ст. 274 УК РФ).
Потому как доступ вам предоставляли не для деструктивных целей, а для поддержки и обслуживания и вы нарушили правила эксплуатации, что привело к деструктивным последствиям.
Но и тут не все так просто, потому как в действие вступает Статья 25 УК РФ (Преступление, совершенное умышленно).
Потому что есть объект преступления – информационная инфраструктура, принадлежащая заказчику, есть прямой умысел - вы осознаете, что удаляете данные, предвидите вред и желаете его. И есть общественно опасные последствия – прямой или косвенный ущерб заказчику, нарушение работы инфраструктуры.
Если заказчик в результате ваших действий понес реальный ущерб: остановились продажи, перестал работать сайт, были удалены или оказались блокированы данные, то тут можно дополнительно поднять еще одну статейку:
▫️ Умышленные уничтожение или повреждение имущества (ст. 167 УК РФ) несмотря на то, что программное обеспечение имуществом (вещью) не является.
Логика правоохранительных органов здесь такая: если в результате удаления ПО сервер (вещь) вышел из строя, не обязательно физически, достаточно невозможности использования оборудования по назначению и это принесло реальный ущерб – то это умышленное повреждение имущества.
Получается, что наш коллега кругом не прав и не имеет возможности защитить себя от кидка? Имеет, только нужно использовать подходящие для этого нормы права:
▫️ Право подрядчика на удержание (ст. 712 ГК РФ)
Согласно которой он имеет право удерживать результаты своего труда до полной его оплаты. Т.е. в нашем случае правомерно не предавать полный доступ (учетную запись администратора) до полного выполнения заказчиком своих обязательств.
Но самовольно уничтожать или еще каким-либо образом распоряжаться имуществом заказчика вы не имеете права.
👍16🤡7🫡4👏2❤1
Настраиваем Forgejo с обратным прокси-сервером Caddy и TLS-защитой
Git сегодня плотно вошел в повседневную работу не только разработчиков, но и системных администраторов, особенно если вы придерживаетесь принципа инфраструктура как код или просто хотите хранить собственные скрипты и конфиги в версионированном хранилище.
Обычно используются внешние сервисы, тот же GitHub или GitLab, но в современных реалиях внешний сервис может стать точкой отказа или вы не хотите размещать на внешних серверах чувствительную информацию.
В этом случае вам потребуется собственный git-сервер и, если вам не требуется монстр вроде Self-hosting GitLab, то есть простые и нетребовательные решения. Одним из них была Gitea, но после перехода ее под контроль коммерческой организации сообщество выразило обоснованные лицензионные опасения.
В результате появился ее форк – Forgejo, который со временем стал развиваться самостоятельно и перестал быть полным аналогом Gitea, при этом оставаясь полностью открытым программным обеспечением.
Сегодня мы рассмотрим, как быстро поднять свой экземпляр Forgejo с СУБД PostgreSQL и обратным прокси на базе Caddy с TLS-защитой. Это готовое решение, которое вы можете разворачивать в продуктовых средах.
Для развертывания мы будем использовать Docker, так как готовых пакетов для проекта нет. Создадим папку проекта, в нашем случае
Набор переменных -
Здесь мы указываем домен, порт для SSH (родной 22 занят хостом) и параметры подключения к PostgreSQL и имя базы.
Затем создадим файл конфигурации Caddy – Caddyfile:
Опция
И наконец
Сохраняем и запускаем командой:
Затем переходим по указанному нами доменному имени. Вы попадете на страницу начальной настройки, там все понятно, но обратите внимание на порт SSH, его требуется указать таким, какой вы выбрали в переменных, т.е. 2222.
В остальном смотрите сами, первый зарегистрированный пользователь становится администратором, если вы не указали его явно.
А теперь вы можете перенести уже готовые репозитории из других сервисов или создать новый. А также управлять собственным git-сервером.
Git сегодня плотно вошел в повседневную работу не только разработчиков, но и системных администраторов, особенно если вы придерживаетесь принципа инфраструктура как код или просто хотите хранить собственные скрипты и конфиги в версионированном хранилище.
Обычно используются внешние сервисы, тот же GitHub или GitLab, но в современных реалиях внешний сервис может стать точкой отказа или вы не хотите размещать на внешних серверах чувствительную информацию.
В этом случае вам потребуется собственный git-сервер и, если вам не требуется монстр вроде Self-hosting GitLab, то есть простые и нетребовательные решения. Одним из них была Gitea, но после перехода ее под контроль коммерческой организации сообщество выразило обоснованные лицензионные опасения.
В результате появился ее форк – Forgejo, который со временем стал развиваться самостоятельно и перестал быть полным аналогом Gitea, при этом оставаясь полностью открытым программным обеспечением.
Сегодня мы рассмотрим, как быстро поднять свой экземпляр Forgejo с СУБД PostgreSQL и обратным прокси на базе Caddy с TLS-защитой. Это готовое решение, которое вы можете разворачивать в продуктовых средах.
Для развертывания мы будем использовать Docker, так как готовых пакетов для проекта нет. Создадим папку проекта, в нашем случае
/opt/forgejo и перейдем в него, там создадим следующие файлы с указанным ниже содержимым.Набор переменных -
.env, в который внесем:UID=1000
GID=1000
DOMAIN=git.example.com
SSH_PORT=2222
POSTGRES_DB=forgejo_db
POSTGRES_USER=forgejo_usr
POSTGRES_PASSWORD=forgejo_pwd
Здесь мы указываем домен, порт для SSH (родной 22 занят хостом) и параметры подключения к PostgreSQL и имя базы.
Затем создадим файл конфигурации Caddy – Caddyfile:
{$DOMAIN} {
# tls internal
reverse_proxy server:3000
}Опция
tls internal отвечает за получение самоподписанного сертификата, раскомментируйте ее для тестовой среды или отладки, если получение сертификата Let’s Encrypt невозможно.И наконец
docker-compose.yml:services:
caddy:
image: caddy:latest
restart: always
environment:
- DOMAIN=${DOMAIN}
ports:
- "80:80"
- "443:443"
- "443:443/udp"
volumes:
- ./Caddyfile:/etc/caddy/Caddyfile:ro
- caddy_data:/data
- caddy_config:/config
depends_on:
- server
networks:
- forgejo
server:
image: codeberg.org/forgejo/forgejo:14
restart: always
environment:
- USER_UID=${UID}
- USER_GID=${GID}
- FORGEJO__database__DB_TYPE=postgres
- FORGEJO__database__HOST=db:5432
- FORGEJO__database__NAME=${POSTGRES_DB}
- FORGEJO__database__USER=${POSTGRES_USER}
- FORGEJO__database__PASSWD=${POSTGRES_PASSWORD}
volumes:
- ./forgejo:/data
- /etc/localtime:/etc/localtime:ro
ports:
- "${SSH_PORT}:22"
depends_on:
- db
networks:
- forgejo
db:
image: postgres:17
restart: always
environment:
- POSTGRES_DB=${POSTGRES_DB}
- POSTGRES_USER=${POSTGRES_USER}
- POSTGRES_PASSWORD=${POSTGRES_PASSWORD}
volumes:
- ./postgres:/var/lib/postgresql/data
networks:
- forgejo
volumes:
caddy_data:
caddy_config:
networks:
forgejo:
Сохраняем и запускаем командой:
docker compose up -d
Затем переходим по указанному нами доменному имени. Вы попадете на страницу начальной настройки, там все понятно, но обратите внимание на порт SSH, его требуется указать таким, какой вы выбрали в переменных, т.е. 2222.
В остальном смотрите сами, первый зарегистрированный пользователь становится администратором, если вы не указали его явно.
А теперь вы можете перенести уже готовые репозитории из других сервисов или создать новый. А также управлять собственным git-сервером.
👍16❤4🤮2
Удаленное выполнение команд SSH
Сегодня еще немного об SSH, точнее о выполнении команд на удалённом сервере.
Чтобы это сделать - необязательно заходить на него, достаточно выполнить:
При этом важно понимать, что на удаленном узле выполняется только первая команда, все перенаправления или конвейеры будут работать уже локально.
Например:
А вот такая конструкция отлично сработает в Linux, но даст вам ошибку в Windows, так как в ней нет команды grep:
Чтобы выполнить команду полностью на удаленном узле ее нужно взять в одинарные кавычки.
С другой стороны никто нам не мешает решать часть задач другими инструментами:
Сегодня еще немного об SSH, точнее о выполнении команд на удалённом сервере.
Чтобы это сделать - необязательно заходить на него, достаточно выполнить:
ssh user@remotehost cat ~/myfile
При этом важно понимать, что на удаленном узле выполняется только первая команда, все перенаправления или конвейеры будут работать уже локально.
Например:
ssh user@remotehost mysqldump -uroot-p database > database.sql
А вот такая конструкция отлично сработает в Linux, но даст вам ошибку в Windows, так как в ней нет команды grep:
ssh user@remotehost dpkg -l | grep 1c-ent
Чтобы выполнить команду полностью на удаленном узле ее нужно взять в одинарные кавычки.
ssh user@remotehost 'dpkg -l | grep 1c-ent'
С другой стороны никто нам не мешает решать часть задач другими инструментами:
ssh user@remotehost dpkg -l | Select-String -SimpleMatch "1c-ent"
1👍29⚡2❤2🔥1
Почему современные приложения все чаще используют конфигурационные файлы в форматах JSON или YAML
Среди многих наших коллег очень часто возникает непонимание и даже возмущение, когда они сталкиваются с конфигурационными файлами в JSON или YAML. Основное нарекание вызывает «неудобный» формат, который заставляет контролировать пробелы или вложенность скобок.
То ли дело старый добрый текстовый конфиг. Когда-то я тоже не особо понимал это стремление и также временами возмущался свалившимися «на ровном месте» сложностями.
Но, по мере того как стал более плотно заниматься разработкой и разными обменами между разнотипными системами полностью поменял свое мнение.
Текстовый конфиг прост только на первый взгляд, с технической точки зрения это непрерывный поток символов, который нам нужно каждый раз полностью парсить и разбирать, при этом с учетом контекста, в случае, когда следующая запись относится к предыдущей.
Сложностей тут много, особенно учитывая, что строгого порядка написания конфигурационных файлов нет и тут может быть так, а там иначе.
А еще веселее становится, когда нам нужно настроить взаимодействие нескольких систем и вносит изменения в конфигурацию программно, допустим через API.
Особенно это касается всяких скриптов и панелек, которые должны сначала прочитать и показать вам текущую конфигурацию, а потом внести в нее изменения.
Каждый раз вам придется полностью читать и разбирать файл конфигурации, а потом еще решать задачу, как записать свои изменения правильно. Особенно если файл еще мог правиться вручную.
Поэтому истории известны множество историй, когда или панели ломали рабочие конфиги, либо после ручных правок ломалась работа панелей, либо сочетание этих обоих способов давало совершенно неожиданный результат.
Как быть?
Отказаться от текста в пользу структур. Основной особенностью JSON или YAML является то, что и то и другое набор объектов уровня ключ – значение, совокупность которых представляет из себя структуру.
Что такое структура хорошо известно любому, кто программирует на любом современном языке. И ее плюсы по сравнению с плоским текстом.
При этом каждый объект может как просто иметь значение, так и быть хранилищем еще одного объекта, позволяя создавать разветвленные структуры.
Но суть не в этом. Любая структура позволяет работать с собой избегая ее полного перебора.
Мы можем просто выполнить поиск по ключу и получить новую структуру, которая будет содержать только выбранные ключи и их значения.
Также просто и вносить изменения, мы находим нужный элемент структуры и добавляем в него новую пару ключ – значение.
И совершенно неважно, правили или будет править этот конфиг после нас руками. Благодаря структуре нам не надо анализировать текстовый файл и думать куда именно вставить изменения.
Есть структура и мы работаем именно с ней. В качестве примера, возьмем тот же Netplan.
Чтобы получить информацию о сетевых интерфейсах нам не надо читать весь файл, нам достаточно получить значение ключа ethernets, который будет содержать в качестве значения еще одну структуру, в которой уже ключом будет наименование сетевого адаптера.
Возможно, на первый взгляд, выглядит немного сложно, но на самом деле мы всегда знаем где что искать и откуда что удалять или добавлять, не боясь при этом пересечься с чьими-то правками и поломать синтаксис конфига.
Поэтому JSON или YAML будут все чаще использоваться для конфигурационных файлов по вполне объективными причинам.
Из минусов? Работать с ними в традиционных консольных текстовых редакторах неудобно, да это и не нужно.
В 21 веке существуют гораздо более удобные среды разработки, которые позволяют редактировать такие файлы с проверкой и подсветкой синтаксиса с рабочего ПК подключаясь к серверу по SSH.
Например, VS Code, про который мы рассказывали в нашей недавней статье:
🔹 Настраиваем Visual Studio Code для удаленной работы через SSH
Среди многих наших коллег очень часто возникает непонимание и даже возмущение, когда они сталкиваются с конфигурационными файлами в JSON или YAML. Основное нарекание вызывает «неудобный» формат, который заставляет контролировать пробелы или вложенность скобок.
То ли дело старый добрый текстовый конфиг. Когда-то я тоже не особо понимал это стремление и также временами возмущался свалившимися «на ровном месте» сложностями.
Но, по мере того как стал более плотно заниматься разработкой и разными обменами между разнотипными системами полностью поменял свое мнение.
Текстовый конфиг прост только на первый взгляд, с технической точки зрения это непрерывный поток символов, который нам нужно каждый раз полностью парсить и разбирать, при этом с учетом контекста, в случае, когда следующая запись относится к предыдущей.
Сложностей тут много, особенно учитывая, что строгого порядка написания конфигурационных файлов нет и тут может быть так, а там иначе.
А еще веселее становится, когда нам нужно настроить взаимодействие нескольких систем и вносит изменения в конфигурацию программно, допустим через API.
Особенно это касается всяких скриптов и панелек, которые должны сначала прочитать и показать вам текущую конфигурацию, а потом внести в нее изменения.
Каждый раз вам придется полностью читать и разбирать файл конфигурации, а потом еще решать задачу, как записать свои изменения правильно. Особенно если файл еще мог правиться вручную.
Поэтому истории известны множество историй, когда или панели ломали рабочие конфиги, либо после ручных правок ломалась работа панелей, либо сочетание этих обоих способов давало совершенно неожиданный результат.
Как быть?
Отказаться от текста в пользу структур. Основной особенностью JSON или YAML является то, что и то и другое набор объектов уровня ключ – значение, совокупность которых представляет из себя структуру.
Что такое структура хорошо известно любому, кто программирует на любом современном языке. И ее плюсы по сравнению с плоским текстом.
При этом каждый объект может как просто иметь значение, так и быть хранилищем еще одного объекта, позволяя создавать разветвленные структуры.
Но суть не в этом. Любая структура позволяет работать с собой избегая ее полного перебора.
Мы можем просто выполнить поиск по ключу и получить новую структуру, которая будет содержать только выбранные ключи и их значения.
Также просто и вносить изменения, мы находим нужный элемент структуры и добавляем в него новую пару ключ – значение.
И совершенно неважно, правили или будет править этот конфиг после нас руками. Благодаря структуре нам не надо анализировать текстовый файл и думать куда именно вставить изменения.
Есть структура и мы работаем именно с ней. В качестве примера, возьмем тот же Netplan.
Чтобы получить информацию о сетевых интерфейсах нам не надо читать весь файл, нам достаточно получить значение ключа ethernets, который будет содержать в качестве значения еще одну структуру, в которой уже ключом будет наименование сетевого адаптера.
Возможно, на первый взгляд, выглядит немного сложно, но на самом деле мы всегда знаем где что искать и откуда что удалять или добавлять, не боясь при этом пересечься с чьими-то правками и поломать синтаксис конфига.
Поэтому JSON или YAML будут все чаще использоваться для конфигурационных файлов по вполне объективными причинам.
Из минусов? Работать с ними в традиционных консольных текстовых редакторах неудобно, да это и не нужно.
В 21 веке существуют гораздо более удобные среды разработки, которые позволяют редактировать такие файлы с проверкой и подсветкой синтаксиса с рабочего ПК подключаясь к серверу по SSH.
Например, VS Code, про который мы рассказывали в нашей недавней статье:
🔹 Настраиваем Visual Studio Code для удаленной работы через SSH
👍19🤔6🤮6❤3
Как изменить командную оболочку Linux
Командная оболочка, она же интерпретатор командной строки – специальная программа, запускаемая при входе в систему и обеспечивающая для пользователя интерфейс командной строки.
Самой распространенной и популярной командной оболочкой в Linux является bash, но существуют и другие оболочки.
Начинающие пользователи редко задумываются над этим, до тех пор, пока не попадут в непонятную ситуацию.
Сегодня за советом обратился молодой коллега, он решил потренироваться в настройке веб-сервера и взял для этих целей бесплатную виртуалку у Cloud.ru о котором мы недавно писали.
Его «проблема» оказалась в том, что Linux там (а он установил Debian 12) какой-то непонятный, выглядит не так, стрелки не работают и вообще странно себя ведет. Он уже и систему переустановил, но ничего не помогает.
Любой опытный администратор Linux сразу же распознает симптомы и спросит какая командная оболочка установлена для пользователя. Проверить это можно командной:
В нашем случае ожидаемо получили ответ:
В Debian и Ubuntu данный файл является символической ссылкой на dash – минималистическую оболочку Debian Almquist shell портированную Almquist shell (ash) из NetBSD. Она очень легковесна, но не может похвастаться функциональностью и не является полностью POSIX-совместимой.
Вполне понятно, что, оказавшись в непривычной командной среде мой коллега растерялся и не сразу понял в чем дело.
Но этому горю легко помочь и установить в качестве командного интерпретатора привычный bash или что угодно другое.
Прежде всего ознакомимся со списком доступных командных оболочек:
В выводе вы получите что-то вроде:
Ничего иного в качестве командной оболочки указывать не следует иначе вы просто не сможете войти в систему.
Опытный пользователь заметит, что для многих оболочек присутствует два пути, ничего удивительного в этом нет, так как в современных системах каталог
Чтобы изменить командную оболочку используйте команду:
В данном случае мы установили себе оболочку bash. Обычный пользователь может изменить оболочку только себе, суперпользователь может сделать это для любого пользователя, например:
В данном случае указанная оболочка будет установлена пользователю user1. Чтобы изменения вступили в силу нужно выйти и войти обратно в систему.
Командная оболочка, она же интерпретатор командной строки – специальная программа, запускаемая при входе в систему и обеспечивающая для пользователя интерфейс командной строки.
Самой распространенной и популярной командной оболочкой в Linux является bash, но существуют и другие оболочки.
Начинающие пользователи редко задумываются над этим, до тех пор, пока не попадут в непонятную ситуацию.
Сегодня за советом обратился молодой коллега, он решил потренироваться в настройке веб-сервера и взял для этих целей бесплатную виртуалку у Cloud.ru о котором мы недавно писали.
Его «проблема» оказалась в том, что Linux там (а он установил Debian 12) какой-то непонятный, выглядит не так, стрелки не работают и вообще странно себя ведет. Он уже и систему переустановил, но ничего не помогает.
Любой опытный администратор Linux сразу же распознает симптомы и спросит какая командная оболочка установлена для пользователя. Проверить это можно командной:
echo $SHELL
В нашем случае ожидаемо получили ответ:
/bin/sh
В Debian и Ubuntu данный файл является символической ссылкой на dash – минималистическую оболочку Debian Almquist shell портированную Almquist shell (ash) из NetBSD. Она очень легковесна, но не может похвастаться функциональностью и не является полностью POSIX-совместимой.
Вполне понятно, что, оказавшись в непривычной командной среде мой коллега растерялся и не сразу понял в чем дело.
Но этому горю легко помочь и установить в качестве командного интерпретатора привычный bash или что угодно другое.
Прежде всего ознакомимся со списком доступных командных оболочек:
cat /etc/shells
В выводе вы получите что-то вроде:
/bin/sh
/bin/bash
/usr/bin/bash
/bin/rbash
/usr/bin/rbash
/bin/dash
/usr/bin/dash
Ничего иного в качестве командной оболочки указывать не следует иначе вы просто не сможете войти в систему.
Опытный пользователь заметит, что для многих оболочек присутствует два пути, ничего удивительного в этом нет, так как в современных системах каталог
/bin является символической ссылкой на /usr/bin и обе записи ведут в одно и тоже место.Чтобы изменить командную оболочку используйте команду:
chsh -s /bin/bash
В данном случае мы установили себе оболочку bash. Обычный пользователь может изменить оболочку только себе, суперпользователь может сделать это для любого пользователя, например:
chsh -s /bin/bash user1
В данном случае указанная оболочка будет установлена пользователю user1. Чтобы изменения вступили в силу нужно выйти и войти обратно в систему.
👍23🔥6👌5🤮1
О различных подходах к системному администрированию
Данная заметка написана как размышление по поводу одного обсуждения, где промелькнула интересная фраза об «уютном рабочем месте, где много чего есть». Под много чего подразумевается набор всяко-разных инструментов и утилит разной степени полезности.
Но зайдем мы сегодня издалека, сильно издалека, когда деревья были большие, а Windows 2003 еще не имел сервис-паков. Эпоха DOS стремительно уходила в прошлое, а новые версии Windows радовали новыми и удобными графическими интерфейсами.
Казалось, эпоха командной строки навсегда канула в прошлое. На любое, даже самое простое действие всегда можно было найти графическую утилиту и сделать все мышкой. Времена были тогда сильно попроще, и мы смело качали из сети все что под руку попадалось, особо не заморачиваясь ни насчет авторских прав, ни насчет двойного дна в программах.
Со временем у каждого собирался т.н. «джентельменский набор», который старательно записывался на дискеты, потом нарезался на диски, а затем уже и на флешки перекочевал. Можно ли что-либо из этого сделать просто так, средствами системы, мы не задумывались. А зачем?
Потом я начал осваивать мир Linux, естественно начал с графического интерфейса, потому как сразу нырять в глубину терминала классическому виндовому админу тех лет было не с руки. Там сразу кирпичом и на дно…
И сразу же стали всплывать вопросы вроде «а где мне найти аналог утилитки X или программки Y». Только вот интернет не спешил радовать порталами, где были бы сложены разные нужные программки для Linux, разной степени лицензионной чистоты.
Суровые и красноглазые «линуксоиды» чужаков не жаловали, все что от них можно было услышать, это про «курение манов» и репозитории.
Потихоньку выяснялось, что в Linux все есть и практически все это присутствует из коробки, а чего нет – быстро ставится одной командой. Но вот беда, все это было в основном заточено под консоль, что меня и моих коллег, привыкших к окошкам и мышке сильно пугало.
Первое, что мы пробовали делать, это искать графические оболочки для консольных утилит, но очень часто они выглядели так, как будто были написаны левым задним копытом в период ломового запоя. Ну и работали соответствующе.
Потом мы открыли для себя панели, и многие, включая меня на них подсели. Однако разочарование пришло довольно быстро. Системы время от времени ломались вместе с панелями. И становилось очень неуютно и тоскливо. Особенно если это была система заказчика.
В те времена многие сошли с этого трудного пути и вернулись обратно в простой и понятный, как нам тогда казалось, мир Windows.
Те, кто остался, стали осваивать сложный и непонятный мир терминала. Сколько раз в те годы я ругался, мол да это же MS DOS какой-то, ничего не видно, ничего не понятно, сплошная деградация.
Но потихоньку появлялись знания, нарабатывался опыт и в какой-то момент графика в Linux перестала быть нужна. А потом стало приходить понимание, что все что нужно – всегда у тебя под рукой, вместе с теми самыми «манами, которые нужно курить». Без этих ваших интернетов и СМС.
И, как это бывает, из чего-то чужого, непонятного и враждебного терминал превратился в теплую и уютную рабочую среду, где все есть и не нужно ничего искать, ну может сразу подкинуть парочку пакетов.
После чего, возвращаясь в мир окон стал возникать вопрос, а можно ли как-то решить эту задачу без привлечения сторонних утилит, средствами системы?
И оказалось, что да, что CMD, оказывается, не столь убог, как казалось. А PowerShell так вообще открыл новые, неведомые прежде возможности.
После чего необходимость в разных простых и не очень утилитках и программках стала как-то сходить на нет. Особенно с развитием удаленной работы. Это сегодня ты за своим уютным рабочим местом, а завтра в чужой системе, где ничего этого нет и возможность ставить что-то свое варьируется от нежелательно, до запрещено.
Поэтому, разный полезный софт – это хорошо, уютно, удобно. Но это не должно заменять владение родными инструментами системы.
Данная заметка написана как размышление по поводу одного обсуждения, где промелькнула интересная фраза об «уютном рабочем месте, где много чего есть». Под много чего подразумевается набор всяко-разных инструментов и утилит разной степени полезности.
Но зайдем мы сегодня издалека, сильно издалека, когда деревья были большие, а Windows 2003 еще не имел сервис-паков. Эпоха DOS стремительно уходила в прошлое, а новые версии Windows радовали новыми и удобными графическими интерфейсами.
Казалось, эпоха командной строки навсегда канула в прошлое. На любое, даже самое простое действие всегда можно было найти графическую утилиту и сделать все мышкой. Времена были тогда сильно попроще, и мы смело качали из сети все что под руку попадалось, особо не заморачиваясь ни насчет авторских прав, ни насчет двойного дна в программах.
Со временем у каждого собирался т.н. «джентельменский набор», который старательно записывался на дискеты, потом нарезался на диски, а затем уже и на флешки перекочевал. Можно ли что-либо из этого сделать просто так, средствами системы, мы не задумывались. А зачем?
Потом я начал осваивать мир Linux, естественно начал с графического интерфейса, потому как сразу нырять в глубину терминала классическому виндовому админу тех лет было не с руки. Там сразу кирпичом и на дно…
И сразу же стали всплывать вопросы вроде «а где мне найти аналог утилитки X или программки Y». Только вот интернет не спешил радовать порталами, где были бы сложены разные нужные программки для Linux, разной степени лицензионной чистоты.
Суровые и красноглазые «линуксоиды» чужаков не жаловали, все что от них можно было услышать, это про «курение манов» и репозитории.
Потихоньку выяснялось, что в Linux все есть и практически все это присутствует из коробки, а чего нет – быстро ставится одной командой. Но вот беда, все это было в основном заточено под консоль, что меня и моих коллег, привыкших к окошкам и мышке сильно пугало.
Первое, что мы пробовали делать, это искать графические оболочки для консольных утилит, но очень часто они выглядели так, как будто были написаны левым задним копытом в период ломового запоя. Ну и работали соответствующе.
Потом мы открыли для себя панели, и многие, включая меня на них подсели. Однако разочарование пришло довольно быстро. Системы время от времени ломались вместе с панелями. И становилось очень неуютно и тоскливо. Особенно если это была система заказчика.
В те времена многие сошли с этого трудного пути и вернулись обратно в простой и понятный, как нам тогда казалось, мир Windows.
Те, кто остался, стали осваивать сложный и непонятный мир терминала. Сколько раз в те годы я ругался, мол да это же MS DOS какой-то, ничего не видно, ничего не понятно, сплошная деградация.
Но потихоньку появлялись знания, нарабатывался опыт и в какой-то момент графика в Linux перестала быть нужна. А потом стало приходить понимание, что все что нужно – всегда у тебя под рукой, вместе с теми самыми «манами, которые нужно курить». Без этих ваших интернетов и СМС.
И, как это бывает, из чего-то чужого, непонятного и враждебного терминал превратился в теплую и уютную рабочую среду, где все есть и не нужно ничего искать, ну может сразу подкинуть парочку пакетов.
После чего, возвращаясь в мир окон стал возникать вопрос, а можно ли как-то решить эту задачу без привлечения сторонних утилит, средствами системы?
И оказалось, что да, что CMD, оказывается, не столь убог, как казалось. А PowerShell так вообще открыл новые, неведомые прежде возможности.
После чего необходимость в разных простых и не очень утилитках и программках стала как-то сходить на нет. Особенно с развитием удаленной работы. Это сегодня ты за своим уютным рабочим местом, а завтра в чужой системе, где ничего этого нет и возможность ставить что-то свое варьируется от нежелательно, до запрещено.
Поэтому, разный полезный софт – это хорошо, уютно, удобно. Но это не должно заменять владение родными инструментами системы.
👍34❤4🤔3🤡3👌1
Proxmox Manager – консольное меню для управления виртуальными машинами и контейнерами
Бывают случаи, когда подключение к веб-интерфейсу Proxmox VE не представляется возможным и имеется только консоль. Это не беда, так как у Proxmox существует богатый набор консольных инструментов, но если вы редко ими пользуетесь, то придется вспоминать синтаксис и читать документацию.
Но этого можно избежать, если использовать Proxmox Manager – скрипт на Bash, который использует только стандартные инструменты и представляет собой меню командной строки с наиболее часто используемыми действиями.
Для работы достаточно просто скачать скрипт со страницы с релизом:
Сделать его исполняемым:
И запустить:
После чего вы увидите общие сведения о гипервизоре и список виртуальных машин и контейнеров на нем. Для дальнейшей работы введите VMID и перед вами появится меню доступных действий.
Оно небольшое, но все нужные команды в нем есть, вы можете запустить, остановить, перезапустить гостевую систему, управлять снимками, подключиться в консоль гостевой системы или включить SPICE-доступ.
В целом утилита не представляет чего-то сверхъестественного, но позволяет при необходимости просто и удобно выполнять основные действия над виртуальными машинами и контейнерами.
Также имеется возможность установить скрипт в систему и зарегистрировать на постоянной основе как команду pman, что открывает возможности по автоматизации ряда действий с его помощью, для этого скачайте и запустите скрипт
▫️ curl — general HTTP client
▫️ git — version control
▫️ sc-shellcheck — Bash static analysis (CI/dev)
▫️ virt-viewer — SPICE/VNC viewer (for --spice workflow)
▫️ jq — JSON processor (for --json output)
Нужно это вам или нет – смотрите сами. Но в любом случае скрипт заслуживает внимания как простой и удобный инструмент для доступа к основным функциям Proxmox VE из консоли.
Бывают случаи, когда подключение к веб-интерфейсу Proxmox VE не представляется возможным и имеется только консоль. Это не беда, так как у Proxmox существует богатый набор консольных инструментов, но если вы редко ими пользуетесь, то придется вспоминать синтаксис и читать документацию.
Но этого можно избежать, если использовать Proxmox Manager – скрипт на Bash, который использует только стандартные инструменты и представляет собой меню командной строки с наиболее часто используемыми действиями.
Для работы достаточно просто скачать скрипт со страницы с релизом:
wget https://github.com/TimInTech/proxmox-manager/releases/download/v2.9.0/proxmox-manager.sh
Сделать его исполняемым:
chmod +x proxmox-manager.sh
И запустить:
./proxmox-manager.sh
После чего вы увидите общие сведения о гипервизоре и список виртуальных машин и контейнеров на нем. Для дальнейшей работы введите VMID и перед вами появится меню доступных действий.
Оно небольшое, но все нужные команды в нем есть, вы можете запустить, остановить, перезапустить гостевую систему, управлять снимками, подключиться в консоль гостевой системы или включить SPICE-доступ.
В целом утилита не представляет чего-то сверхъестественного, но позволяет при необходимости просто и удобно выполнять основные действия над виртуальными машинами и контейнерами.
Также имеется возможность установить скрипт в систему и зарегистрировать на постоянной основе как команду pman, что открывает возможности по автоматизации ряда действий с его помощью, для этого скачайте и запустите скрипт
install_dependencies.sh, но в качестве зависимостей он притащит вам следующий набор пакетов:▫️ curl — general HTTP client
▫️ git — version control
▫️ sc-shellcheck — Bash static analysis (CI/dev)
▫️ virt-viewer — SPICE/VNC viewer (for --spice workflow)
▫️ jq — JSON processor (for --json output)
Нужно это вам или нет – смотрите сами. Но в любом случае скрипт заслуживает внимания как простой и удобный инструмент для доступа к основным функциям Proxmox VE из консоли.
👍37🔥3❤1🤮1🤝1