Почему современное ПО такое неоптимизированное
Данный вопрос не раз и не два всплывает в обсуждениях, обычно винят во всем современных программистов, которые, мол, не хотят или не умеют в оптимизацию и все такое прочее.
Однако мало кто задумывается над другой стороной этой ситуации – современном рынке ПО. Потому что именно рынок обуславливает подходы к разработке и диктует правила.
Если мы вернемся в старые добрые времена, то увидим, что цикл разработки ПО был длительным, мажорный релиз – целое событие, которого ждали, к которому готовились. ПО достаточно долго и качественно тестировалось.
Но не потому, что раньше нравы были другие или специалисты круче. А потому что рынок ПО в то время был в основном представлен физическими носителями, а это было дорого и медленно. Поэтому если вы накосячили, то вы накосячили и это надолго. Либо рассылайте за свой счет патчи.
Что касается оптимизации, то ПО всегда писалось и пишется под средний современный ПК, со всеми вытекающими и если можно относительно безболезненно повысить системные требования, то это будет сделано, поэтому что сильно дешевле, чем оптимизация, которую особо никто не заметит.
По мере развития сети интернет дистрибуция ПО начала потихоньку переходить в него, пока полностью не вытеснила физические носители. Теперь программу можно просто скачать, а если можно просто скачать программу, то можно также просто скачать и исправление к ней.
Это резко сократило цикл разработки, теперь можно быстро проверить ПО на грубые ошибки, а всякие недоработки закрыть патчами. Да, пользователь тут выступает в роли тестера, но этот недостаток легко перекрывается многими достоинствами.
Какие же это достоинство? В основном – короткий цикл разработки и быстрое внедрение фич. Теперь вам не нужно ждать несколько лет следующего мажорного релиза чтобы получить новые функции, они появятся просто в очередном выпуске через несколько месяцев или полгода.
Да и само понятие мажорных релизов как-то неожиданно кануло в Лету, большинство программ перешли или на сквозную нумерацию, или по дате выпуска, скажем 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👍28❤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 рекомендуют?
- А у тебя высокая нагрузка?
- Нет, но…
Или:
- Ну это защита от сетевых атак…
- Тебя кто-то атакует?
- Нет, но…
Все это, конечно, может выглядеть круто, но, по сути, это не дает никаких плюсов, а только сплошные минусы.
Подобные настройки могут вызывать потенциальные конфликты, приводить к сложностям в поддержке или администрировании и даже стать причиной отказов, если незнакомый с ними администратор применит настройки, явно приводящие к конфликту.
Поэтому если у вас самая обычная система, которая не испытывает высоких нагрузок и которую никто не атакует, то и настройки в ней должны быть самые стандартные, сделанные стандартными для этой системы механизмами.
И именно это будет хорошо и правильно. Потому что позволит любому знакомому с системой специалисту быстро разобраться в ней и продолжить поддержку в отсутствие ее основного «архитектора».
И все порывы сделать «лучше», «быстрее», «дешевле» и т.п. нестандартными методами должны жестко пресекаться, как контролем, так и самоконтролем.
Потому что все эти костыли и изолента имеют свойство выстреливать в самый неподходящий момент. И делать это достаточно больно.
Здесь я еще раз напомню, что платят нам не за наши пируэты и изыски, тот кто платит – он и слов таких не знает. А платят нам за стабильную и предсказуемую работу.
Если вы вчера сэкономили нестандартным решением десять тысяч рублей, а сегодня, во время вашего отпуска все это упало и разбирались с вашими художествами несколько часов, понеся убытки на сотни тысяч, то ваши мотивы никто из лиц принимающих решения просто не поймет. Со всеми вытекающими оргвыводами.
Поэтому, подводя итоги, можно сказать, что следовать стандартным практикам, даже если они не совсем оптимальны – это хорошо. А городить собственные нестандартные решения – плохо.
При этом мы не хотим сказать, что нестандартные решения не имеют права на существование. Иногда без них никак. Но при этом они должны быть именно нестандартными и становиться личным стандартом де факто.
Но даже применяя нестандартные решения нужно стараться максимально их стандартизовать: использовать стандартные пути размещения файлов, понятные наименования скриптов и переменных в них. Т.е. сделать работу с ними максимально понятной третьему лицу, который увидит это в первый раз.
Ну и конечно не забыть все это документировать. И часть документации будет совсем не лишним разместить прямо здесь, лучше всего в комментариях к скрипту или в виде файла где-то рядом.
👍23🤮2🔥1🥱1
Статья с пола или распространенные юридические заблуждения
В очередной раз столкнулись с распространенным заблуждением коллег, которые считают вполне допустимой ситуацию с уничтожением результата своей работы в отсутствие оплаты от заказчика, мол что такого – я вернул все как было, в исходное состояние.
Это очень опасное заблуждение, основанное на неверном применении правил обычной, бытовой логики, в то время как Закон смотрит на эту ситуацию совсем по-другому.
Начнем с базового момента: чужая инфраструктура – это чужая собственность и результат ваше работы на этой инфраструктуре тоже принадлежит заказчику, он автоматически становится его собственностью по факту принятия работы.
До тех пор, пока заказчик не принял работу вы не вправе требовать с него оплаты – нет основания, нет результата, за который он вам должен заплатить. Да, вы вправе просить аванс, но в этом случае до получения аванса вы не приступаете к работам. Нет аванса – нет работы.
Если вы просите оплату за работу, это подразумевает сдачу результата работ заказчику, так как только после этого у него возникает обязанность вам заплатить, но это и означает, что результат работ его собственность.
Уничтожение собственности заказчика, неважно, просто вы там все стерли, или просто откатили как было может быть расценен в зависимости от сопутствующих обстоятельств как:
▫️ Самоуправство (ст. 330 УК РФ). Самовольное осуществление своего права (реального или мнимого) вопреки установленному законом порядку.
▫️ Неправомерный доступ к компьютерной информации (ст. 272 УК РФ).
Подождите, какой неправомерный, он же сам выдал все пароли и доступы! Но обладание возможностью доступа не говорит о его правомерности. Во-первых, доступ вам выдали для процесса настройки, а не для деструктивных действий. Во-вторых, закончив процесс настройки и сдав работы вы теряете право правомерного доступа.
Но даже если вы сильно будете настаивать на правомерности, скажем вы там еще и поддержкой занимаетесь, то свободно получите другую статью:
▫️ Нарушение правил эксплуатации средств хранения, обработки или передачи компьютерной информации и информационно-телекоммуникационных сетей (ст. 274 УК РФ).
Потому как доступ вам предоставляли не для деструктивных целей, а для поддержки и обслуживания и вы нарушили правила эксплуатации, что привело к деструктивным последствиям.
Но и тут не все так просто, потому как в действие вступает Статья 25 УК РФ (Преступление, совершенное умышленно).
Потому что есть объект преступления – информационная инфраструктура, принадлежащая заказчику, есть прямой умысел - вы осознаете, что удаляете данные, предвидите вред и желаете его. И есть общественно опасные последствия – прямой или косвенный ущерб заказчику, нарушение работы инфраструктуры.
Если заказчик в результате ваших действий понес реальный ущерб: остановились продажи, перестал работать сайт, были удалены или оказались блокированы данные, то тут можно дополнительно поднять еще одну статейку:
▫️ Умышленные уничтожение или повреждение имущества (ст. 167 УК РФ) несмотря на то, что программное обеспечение имуществом (вещью) не является.
Логика правоохранительных органов здесь такая: если в результате удаления ПО сервер (вещь) вышел из строя, не обязательно физически, достаточно невозможности использования оборудования по назначению и это принесло реальный ущерб – то это умышленное повреждение имущества.
Получается, что наш коллега кругом не прав и не имеет возможности защитить себя от кидка? Имеет, только нужно использовать подходящие для этого нормы права:
▫️ Право подрядчика на удержание (ст. 712 ГК РФ)
Согласно которой он имеет право удерживать результаты своего труда до полной его оплаты. Т.е. в нашем случае правомерно не предавать полный доступ (учетную запись администратора) до полного выполнения заказчиком своих обязательств.
Но самовольно уничтожать или еще каким-либо образом распоряжаться имуществом заказчика вы не имеете права.
В очередной раз столкнулись с распространенным заблуждением коллег, которые считают вполне допустимой ситуацию с уничтожением результата своей работы в отсутствие оплаты от заказчика, мол что такого – я вернул все как было, в исходное состояние.
Это очень опасное заблуждение, основанное на неверном применении правил обычной, бытовой логики, в то время как Закон смотрит на эту ситуацию совсем по-другому.
Начнем с базового момента: чужая инфраструктура – это чужая собственность и результат ваше работы на этой инфраструктуре тоже принадлежит заказчику, он автоматически становится его собственностью по факту принятия работы.
До тех пор, пока заказчик не принял работу вы не вправе требовать с него оплаты – нет основания, нет результата, за который он вам должен заплатить. Да, вы вправе просить аванс, но в этом случае до получения аванса вы не приступаете к работам. Нет аванса – нет работы.
Если вы просите оплату за работу, это подразумевает сдачу результата работ заказчику, так как только после этого у него возникает обязанность вам заплатить, но это и означает, что результат работ его собственность.
Уничтожение собственности заказчика, неважно, просто вы там все стерли, или просто откатили как было может быть расценен в зависимости от сопутствующих обстоятельств как:
▫️ Самоуправство (ст. 330 УК РФ). Самовольное осуществление своего права (реального или мнимого) вопреки установленному законом порядку.
▫️ Неправомерный доступ к компьютерной информации (ст. 272 УК РФ).
Подождите, какой неправомерный, он же сам выдал все пароли и доступы! Но обладание возможностью доступа не говорит о его правомерности. Во-первых, доступ вам выдали для процесса настройки, а не для деструктивных действий. Во-вторых, закончив процесс настройки и сдав работы вы теряете право правомерного доступа.
Но даже если вы сильно будете настаивать на правомерности, скажем вы там еще и поддержкой занимаетесь, то свободно получите другую статью:
▫️ Нарушение правил эксплуатации средств хранения, обработки или передачи компьютерной информации и информационно-телекоммуникационных сетей (ст. 274 УК РФ).
Потому как доступ вам предоставляли не для деструктивных целей, а для поддержки и обслуживания и вы нарушили правила эксплуатации, что привело к деструктивным последствиям.
Но и тут не все так просто, потому как в действие вступает Статья 25 УК РФ (Преступление, совершенное умышленно).
Потому что есть объект преступления – информационная инфраструктура, принадлежащая заказчику, есть прямой умысел - вы осознаете, что удаляете данные, предвидите вред и желаете его. И есть общественно опасные последствия – прямой или косвенный ущерб заказчику, нарушение работы инфраструктуры.
Если заказчик в результате ваших действий понес реальный ущерб: остановились продажи, перестал работать сайт, были удалены или оказались блокированы данные, то тут можно дополнительно поднять еще одну статейку:
▫️ Умышленные уничтожение или повреждение имущества (ст. 167 УК РФ) несмотря на то, что программное обеспечение имуществом (вещью) не является.
Логика правоохранительных органов здесь такая: если в результате удаления ПО сервер (вещь) вышел из строя, не обязательно физически, достаточно невозможности использования оборудования по назначению и это принесло реальный ущерб – то это умышленное повреждение имущества.
Получается, что наш коллега кругом не прав и не имеет возможности защитить себя от кидка? Имеет, только нужно использовать подходящие для этого нормы права:
▫️ Право подрядчика на удержание (ст. 712 ГК РФ)
Согласно которой он имеет право удерживать результаты своего труда до полной его оплаты. Т.е. в нашем случае правомерно не предавать полный доступ (учетную запись администратора) до полного выполнения заказчиком своих обязательств.
Но самовольно уничтожать или еще каким-либо образом распоряжаться имуществом заказчика вы не имеете права.
👍16🤡7🫡3👏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-сервером.
👍15❤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👍28⚡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
👍18🤔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. Чтобы изменения вступили в силу нужно выйти и войти обратно в систему.
👍22🔥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 так вообще открыл новые, неведомые прежде возможности.
После чего необходимость в разных простых и не очень утилитках и программках стала как-то сходить на нет. Особенно с развитием удаленной работы. Это сегодня ты за своим уютным рабочим местом, а завтра в чужой системе, где ничего этого нет и возможность ставить что-то свое варьируется от нежелательно, до запрещено.
Поэтому, разный полезный софт – это хорошо, уютно, удобно. Но это не должно заменять владение родными инструментами системы.
👍33❤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
Маразм крепчал, еноты пели…
Третьего дня столкнулся в сети с утверждением, что согласно нашему Законодательству РКН считает IP-адреса персональными данными. Аргументация железобетонная:
▫️ IP-адрес связан с конкретным устройством и, в совокупности с другими данными, позволяет однозначно определить человека.
▫️ Статические адреса однозначно идентифицируют пользователя, динамические — рассматриваются как ПДн при возможности идентификации провайдером.
А позвольте спросить, каким образом я могу связать статический IP с конкретным физическим лицом без идентификации провайдером? Или где-то уже публично опубликован подобный реестр?
Ок, хорошо, но исходя из этой логики ПДн следует признать государственный регистрационный знак автомобиля. Но увы, номер персональными данными не является, примерно по тем же самым основаниям:
▫️ Он присваивается автомобилю, а не человеку и относится к техническим данным транспортного средства.
▫️ Узнать владельца по номеру можно только законными способами (запрос в ГИБДД), так как эта информация защищена законом.
Ну так покажите мне, где я, как физическое лицо, могу получить в персональное использование IP-адрес, которое будет присвоено лично мне, а не является техническими данными моего сетевого оборудования?
И как я могу узнать владельца IP-адреса кроме как оформив законным образом и на законных основаниях запрос к оператору связи?
А ведь номерной знак «связан с конкретным устройством», является статическим и «однозначно идентифицирует пользователя».
Сдается мне, что инициаторы данной инициативы в принципе не представляют, что такое IP-адреса, как и для чего они используются.
При этом в Законодательстве нет пояснений, какие именно адреса являются ПДн, а какие не являются. Является ли персональными данными адрес 192.168.0.1? Или 10.8.0.100?
А согласно Закона оператором персональных данных является тот, кто собирает, хранит, копирует, распространяет и использует эти самые данные.
Вот тут и разверзается пропасть куда-то на самое дно, потому как теперь оператором ПДн является любой гражданин подключившийся к сети Интернет.
Ваше устройство ведет логи? Значит вы собираете и храните. Но даже отключив логи мы получим собирание, хранение и использование в DNS-кеше или таблицах маршрутизации. И если логи и кеш мы еще можем выключить, то без таблиц маршрутизации никуда.
Но это только цветочки, ягодки впереди. Отправив ответный пакет, вы распространяете эти самые персональные данные, в открытом виде и, возможно, трансгранично. За что вас полагается жестоко покарать.
Тем более, что вы передали их (в заголовках пакета) третьему лицу (шлюзу своего провайдера), которому владелец IP-адреса мог и не выдать разрешения на обработку его ПДн, равно как и вам на передачу его третьим лицам.
В общем всю глубину дна вы поняли. Потому как в нынешнем виде это не только про сайты, а вообще про любое сетевое устройство.
И не только. Вот опубликовал я у себя на сайте инструкцию, где в качестве примера указал адреса 192.168.0.100 и 192.168.1.101 – все, я попал, потому что я распространил публично чьи-то персональные данные.
А завтра, в период очередного весенне-осеннего обострения шизоид Вася сделает нотариально заверенный скриншот, что его компьютер имеет адрес 192.168.0.100 и потребует от всех удалить из публичного пространства этот адрес.
И будет в своем праве, а тот, кто шизоида проигнорирует рискует попасть на совсем не детские штрафы и гражданские иски.
В этой теме радует только одно – необязательность применения всех этих ***, ну вы поняли, норм. Ибо сами не поняли они, чего нахреновертили.
Но была бы статья, а люди найдутся. Поэтому ходим – да оглядываемся, полезная привычка, как ни крути.
Третьего дня столкнулся в сети с утверждением, что согласно нашему Законодательству РКН считает IP-адреса персональными данными. Аргументация железобетонная:
▫️ IP-адрес связан с конкретным устройством и, в совокупности с другими данными, позволяет однозначно определить человека.
▫️ Статические адреса однозначно идентифицируют пользователя, динамические — рассматриваются как ПДн при возможности идентификации провайдером.
А позвольте спросить, каким образом я могу связать статический IP с конкретным физическим лицом без идентификации провайдером? Или где-то уже публично опубликован подобный реестр?
Ок, хорошо, но исходя из этой логики ПДн следует признать государственный регистрационный знак автомобиля. Но увы, номер персональными данными не является, примерно по тем же самым основаниям:
▫️ Он присваивается автомобилю, а не человеку и относится к техническим данным транспортного средства.
▫️ Узнать владельца по номеру можно только законными способами (запрос в ГИБДД), так как эта информация защищена законом.
Ну так покажите мне, где я, как физическое лицо, могу получить в персональное использование IP-адрес, которое будет присвоено лично мне, а не является техническими данными моего сетевого оборудования?
И как я могу узнать владельца IP-адреса кроме как оформив законным образом и на законных основаниях запрос к оператору связи?
А ведь номерной знак «связан с конкретным устройством», является статическим и «однозначно идентифицирует пользователя».
Сдается мне, что инициаторы данной инициативы в принципе не представляют, что такое IP-адреса, как и для чего они используются.
При этом в Законодательстве нет пояснений, какие именно адреса являются ПДн, а какие не являются. Является ли персональными данными адрес 192.168.0.1? Или 10.8.0.100?
А согласно Закона оператором персональных данных является тот, кто собирает, хранит, копирует, распространяет и использует эти самые данные.
Вот тут и разверзается пропасть куда-то на самое дно, потому как теперь оператором ПДн является любой гражданин подключившийся к сети Интернет.
Ваше устройство ведет логи? Значит вы собираете и храните. Но даже отключив логи мы получим собирание, хранение и использование в DNS-кеше или таблицах маршрутизации. И если логи и кеш мы еще можем выключить, то без таблиц маршрутизации никуда.
Но это только цветочки, ягодки впереди. Отправив ответный пакет, вы распространяете эти самые персональные данные, в открытом виде и, возможно, трансгранично. За что вас полагается жестоко покарать.
Тем более, что вы передали их (в заголовках пакета) третьему лицу (шлюзу своего провайдера), которому владелец IP-адреса мог и не выдать разрешения на обработку его ПДн, равно как и вам на передачу его третьим лицам.
В общем всю глубину дна вы поняли. Потому как в нынешнем виде это не только про сайты, а вообще про любое сетевое устройство.
И не только. Вот опубликовал я у себя на сайте инструкцию, где в качестве примера указал адреса 192.168.0.100 и 192.168.1.101 – все, я попал, потому что я распространил публично чьи-то персональные данные.
А завтра, в период очередного весенне-осеннего обострения шизоид Вася сделает нотариально заверенный скриншот, что его компьютер имеет адрес 192.168.0.100 и потребует от всех удалить из публичного пространства этот адрес.
И будет в своем праве, а тот, кто шизоида проигнорирует рискует попасть на совсем не детские штрафы и гражданские иски.
В этой теме радует только одно – необязательность применения всех этих ***, ну вы поняли, норм. Ибо сами не поняли они, чего нахреновертили.
Но была бы статья, а люди найдутся. Поэтому ходим – да оглядываемся, полезная привычка, как ни крути.
👍46👀11❤5🥱3🤮1
Первые впечатления от Ubuntu 26.04 LTS
Выдалось немного свободного времени, и мы решили посмотреть на новую Ubuntu 26.04 LTS, которая готовится к выпуску в этом месяце. Смотреть можно смело, так как пакетная база дистрибутива на данный момент заморожена и идет только устранение ошибок, без добавления новой функциональности.
При этом сам релиз также можно считать завершающей стадией публичного тестирования, так как автоматическое обновление прошлых версий станет доступно только после выпуска 26.04.1.
Что принципиально нового в этом выпуске? Ядро 7.0, полный отказ от X11 в пользу Wayland и GNOME 50. Хотя ничего революционного в ядре 7.0 нет, просто Линус Торвальдс всегда переходит на новую ветку после 19 релиза старого ядра.
А вот новый GNOME в связке с Wayland – это действительно значимое событие, в честь которого системные требования по ОЗУ повысили до минимальных 6 ГБ, что автоматически отсекает системы начального уровня.
Так ли это на самом деле? Давайте посмотрим. На первый взгляд все не так уж и плохо, после загрузки система показывает умеренное потребление в 1,75 ГБ, не то, чтобы мало, но и не так уж и много, возможно разработчики просто решили перестраховаться.
Ну давайте попробуем чего-нибудь поделать, да и вообще осмотримся. Сама система в минимальной установке ведет себя неплохо, графический интерфейс приятный, в фирменном стиле, работает плавно, не лагает.
Предустановленных программ минимум, поэтому сильно не развернешься, поэтому будем использовать то, что есть, открыли браузер с одной страничкой – потребление выросло до 2,7 ГБ, ну тут никто не сомневался, браузер сегодня основной потребитель памяти.
Потом мы открыли магазин, пару окон файлового менеджера, сделали скриншот и просмотрели его, потом добавили к этому всему терминал – и вплотную приблизились к отметке 4 ГБ, а немного позже и перевалили за нее.
Ну что тут можно сказать, GNOME 50 на Wayland выглядит и работает замечательно, но за все нужно платить. На системах с 4 ГБ ОЗУ эта связка практически неработоспособна, так как памяти вам хватит только на базовые потребности системы (а мы ничего тяжелого, кроме браузера с двумя вкладками еще не запускали).
Поэтому менее чем 8 ГБ для комфортной работы мы даже не рассматриваем и считаем минимальные требования в 6 ГБ вполне обоснованными. Но будем честны, сегодня 8 ГБ – это компьютеры начального уровня, минимальный порог.
Что-то более-менее нормальное, но еще бюджетного сегмента – это от 16 ГБ, меньше просто нет смысла. Поэтому мотивация разработчиков понятна, зачем ужиматься и ограничивать себя в флагманской линейке системы, когда это никому не нужно?
Владельцев старых ПК мы в расчет не берем, так как старые ПК и новые ОС – это вещи радикально противоположные. Хотя и для них есть варианты с менее требовательными графическими оболочками, та же LXQt будет отлично себя чувствовать с 4 ГБ.
Но если вы хотите чтобы система выглядела максимально современно и радовала глаз визуальными эффектами – то готовьте ваши гигабайты, чудес не бывает.
Выдалось немного свободного времени, и мы решили посмотреть на новую Ubuntu 26.04 LTS, которая готовится к выпуску в этом месяце. Смотреть можно смело, так как пакетная база дистрибутива на данный момент заморожена и идет только устранение ошибок, без добавления новой функциональности.
При этом сам релиз также можно считать завершающей стадией публичного тестирования, так как автоматическое обновление прошлых версий станет доступно только после выпуска 26.04.1.
Что принципиально нового в этом выпуске? Ядро 7.0, полный отказ от X11 в пользу Wayland и GNOME 50. Хотя ничего революционного в ядре 7.0 нет, просто Линус Торвальдс всегда переходит на новую ветку после 19 релиза старого ядра.
А вот новый GNOME в связке с Wayland – это действительно значимое событие, в честь которого системные требования по ОЗУ повысили до минимальных 6 ГБ, что автоматически отсекает системы начального уровня.
Так ли это на самом деле? Давайте посмотрим. На первый взгляд все не так уж и плохо, после загрузки система показывает умеренное потребление в 1,75 ГБ, не то, чтобы мало, но и не так уж и много, возможно разработчики просто решили перестраховаться.
Ну давайте попробуем чего-нибудь поделать, да и вообще осмотримся. Сама система в минимальной установке ведет себя неплохо, графический интерфейс приятный, в фирменном стиле, работает плавно, не лагает.
Предустановленных программ минимум, поэтому сильно не развернешься, поэтому будем использовать то, что есть, открыли браузер с одной страничкой – потребление выросло до 2,7 ГБ, ну тут никто не сомневался, браузер сегодня основной потребитель памяти.
Потом мы открыли магазин, пару окон файлового менеджера, сделали скриншот и просмотрели его, потом добавили к этому всему терминал – и вплотную приблизились к отметке 4 ГБ, а немного позже и перевалили за нее.
Ну что тут можно сказать, GNOME 50 на Wayland выглядит и работает замечательно, но за все нужно платить. На системах с 4 ГБ ОЗУ эта связка практически неработоспособна, так как памяти вам хватит только на базовые потребности системы (а мы ничего тяжелого, кроме браузера с двумя вкладками еще не запускали).
Поэтому менее чем 8 ГБ для комфортной работы мы даже не рассматриваем и считаем минимальные требования в 6 ГБ вполне обоснованными. Но будем честны, сегодня 8 ГБ – это компьютеры начального уровня, минимальный порог.
Что-то более-менее нормальное, но еще бюджетного сегмента – это от 16 ГБ, меньше просто нет смысла. Поэтому мотивация разработчиков понятна, зачем ужиматься и ограничивать себя в флагманской линейке системы, когда это никому не нужно?
Владельцев старых ПК мы в расчет не берем, так как старые ПК и новые ОС – это вещи радикально противоположные. Хотя и для них есть варианты с менее требовательными графическими оболочками, та же LXQt будет отлично себя чувствовать с 4 ГБ.
Но если вы хотите чтобы система выглядела максимально современно и радовала глаз визуальными эффектами – то готовьте ваши гигабайты, чудес не бывает.
👍23🤷♂7🤡5🤮3❤2