Его профиль дропнул на работу, очистил историю и куки и у меня условно-чистый браузер с моими настройками.
И как получилось, что KDC и AD на работе и дома совпали? )))
да, случайно и работает.
Как он работать будет, если только установили рядом, условно, с PostgreSQL 17 PostgreSQL 18, причем последний вообще без БД? )))
Ну пусть даже initdb какой-то скрипт автоматом запустил. Но БД то всё равно получилась пустая без единой роли и паролей.
Ну и обновляя мажорные версии ПГ на серверах я надеюсь вы не стартуете каждый раз базу заново типа новый каталог и с чистого листа?
Новый каталог с чистого листа - это как раз обязательное требование. А дальше по обстоятельствам. Иногда можно использовать hard links в этот новый каталог и воспользоваться средствами pg_upgrade. Но чаще, конечно, СУБД поднимается с нуля, устанавливаются и проверяются все необходимых расширения, после чего данные заливаются из бекапа.
Конфиги, само собой правятся только в крайних случаях. Предпочитаю ALTER SYSTEM. Ну и вдумчивое чтение release notes обязательно. Например, я уже готов при переходе на 19-й PostgreSQL включать где нужно JIT компиляцию, которую в нем по-умолчанию вообще отключили.
И каким скриптом там настраиваете, например, kerberos авторизацию или плагин для ЭЦП? И какой скрипт позволяет решить проблему с расширениями, которые новую версию не поддерживают? Там просто отличий от базовой конфигурации требуется на два-три порядка меньше, чем у тех же Asterisk или PostgreSQL. Но суть та же.
Возвращаясь к конфигам серверного ПО, даже на мажорные вещи обновить их просто - кидаем оба в нотепад++ и сравниваем что появилось, меняем только то, что появилось (если надо) и всё работает.
Ну как-то оно может случайно и заработает, но скорее всего результат будет весьма печален. По крайней мере документация рекомендует обновлять конфигурационные файлы вдумчиво и руками. Вы вообще осознаёте, что каждая мажорная версия PostgreSQL устанавливается в свой каталог, создаёт свой сервис и может функционировать совершенно независимо от установленных ранее версий? Там же при установке автоматическое обновление мажорных версий даже не предполагается.
Я уже молчу про Asterisk, где при обновлении на мажорную версию может потребоваться использовать другие модули и драйвера.
Попробуйте, например, просто перенести Citrix VPN (nsgclient) с Ubuntu 16.04 на 18.04, а затем последовательно на 20.04, 22.04 и 24.04. На 26.04 ещё не пробовал. Может уже полегчало. И подобный софт попадается с завидной регулярностью.
Это даже не касаясь более-менее сложного ПО, вроде Asterisk или PostgreSQL, где переход на новую мажорную версию всегда требует вдумчивого анализа конфигурации, а сброс настроек там в принципе неприемлем.
Я убунтой даже не пользуюсь, по этому нисколько. Не понятно к чему аргумент.
Какая разница? Замените Canonical на любую организацию, поддерживающую дистрибутив Linux. Сколько Вы дохода они от Вас получили? А сколько от enterpise?
Я не думаю, что они платят каноникал, они для этого слишком жадные.
То есть, Вы искренне считаете, что Canonical зарабатывает на таких пользователях, как Вы? Сколько же Вы ежемесячно донатите в open source, раз так думаете?
Корпа самая жлобская байты считать не будет даже по нынешним ценам
С точностью наоборот. Это обычный домашний пользователь может закрыть глаза на 1-2 ГБ RAM. А enterprise на гипервизоре или k8s, где таких систем с сотня при общем объеме 256 ГБ RAM, на сотню лишних ГБ глаза не закроет, если их можно будет освободить просто сменой дистрибутива.
Я клиент и мне песочница важнее пары мегабайт (или даже гигабайт) памяти.
Какую долю в доходах Canonical составляют такие клиенты, как Вы? Сколько Вы им уже заплатили? А какую долю в этих же поступлениях составляет enterprise?
Ну так как раз в этом AI может существенно помочь. Преподаватель больше сможет уделять времени прямому общению с обучающимися, если значительную часть подачи и объяснения материала возьмёт на себя AI.
А вот и корень проблемы. Именно из-за наплевательского отношения к потребностям клиентов, например, Ubuntu, продвигая snap, теряет клиентов. И чем больше приложений будет поставляться в snap - тем сильней будет этот отток. Особенно в enterpise, где проблем с самостоятельным обслуживанием и поддержкой нет. Я точно знаю уже несколько крупных компаний, отказавшихся от Ubuntu именно по этой причине.
Если экономить я бы начал с браузера.
Проблема не браузерах, а в перегруженных сайтах. Отсюда, enterprise от этого совершенно не страдает.
Я не об этом. Винда требует перезагрузки после каждого чиха.
Я это указал:
"Ну так сервера под Linux тоже приходится перезагружать при некоторых обновлениях. Другое дело, что если под Linux большинство обновлений требуют лишь перезапуска сервисов, связанных с этими обновлениями, то под Windows почти любое обновление - это перезагрузка сервера. Но к стабильности это никакого отношения не имеет."
Это издержки того, каждый flatpak содержит все необходимые приложению so, а так как с точки зрения системы в разных flatpak - это разные файлы, даже если они идентичны по содержиомому, то и грузит в память их система отдельно для каждого приложения, вместо того чтобы все приложения использовали один и тот же so. То есть, shared objects перестают быть shared.
Так или иначе на круг там копейки для 99% применений.
В таких случаях указывают источник приводимой статистики. Где он?
Разница между VARCHAR и TEXT начинается с того, что исторически это разные oid в pg_type, что порой приводит к странным последствиям. Особенно в некоторых расширениях.
На брендовых рабочих станциях, сертифицированных AutoDesk - без проблем. Там же производитель действительно обеспечивает стабильность работы всех драйверов и дополнительных системных компонентов.
Линукс на том же железе заработал без проблем.
Так получилось, что для этого конкретного железа набор драйверов и системных компонентов Linux оказался стабильней, чем аналогичный, установленный в Windows. Легко могло получиться и наоборот.
Например, к проприетарным драйверам Realtek у меня (да и не только у меня) давно масса претензий к стабильности, тогда как opensource драйвера под Linux куда стабильней, хотя косяки с r8169 я ещё помню. Но это лишь один случай на моей памяти под Linux, против десятков кувырканий под Windows. Особенно с аудиодрайверами.
До этого несколько раз в час фризилась на пару секунд по непонятной причине.
Все средства для локализации подобных проблем в Windows есть. Другое дело, что их подробное описание потребует даже не статьи, а целой серии статей.
Это сейчас уже в разных модулях разных систем и не всегда там все перечисленные решения. Но все эти приёмы изначально были применены в модуле прогнозирования и оптимизации перевозок по сети РЖД довольно крупного оператора подвижного парка.
Упрощённо, для того чтобы оперативно посчитать доходность размещенной заявки на перевозку и решить, предлагать ли её выполнение и по какой цене, нужны все эти решения. Так как тут учитывается прогнозы времени подачи, перевозки и отвода ~100 тыс. вагонов в соответствии с их текущей и прогнозируемой дислокациями, а так же с прогнозируемым ремонтами и техобслуживанием.
Я же написал: "все so при этом будут занимать место в оперативке, не взирая на то, что такие же so уже были загружены другими приложениями."
Запустите несколько приложений, поставляемых в flatpak, которые тянут за собой Qt, GTK или хотя бы Chromium (Electron). Сразу заметите, что объем памяти, потребляемый очередным запускаемым приложением, не зависит от того, было ли приложение, использующее те же so, запущено ранее.
Опять же если сфт требует разные версии библиотек - никуда не денешься.
Ага, засуньте штук пять KDE приложений каждое в свой в flatpak. И вместо буквально сотни мегабайт на все, при уже загруженном KDE, получите несколько гигабайт сожранной оперативки. А разные версии so вполне можно подсунуть символическими ссылками в chroot. Или собрать из исходников, как надо.
С другой стороны, часто ли такое надо? У меня на ноуте такие пассы пришлось делать буквально только с двумя проприетарными приложениями, которые ну никак не пересобрать самому.
Я очень давно не админил винду, но перезагрузка сервера (отдельных сервисов) в те времена не была чем-то совсем экзотическим.
Ну так сервера под Linux тоже приходится перезагружать при некоторых обновлениях. Другое дело, что если под Linux большинство обновлений требуют лишь перезапуска сервисов, связанных с этими обновлениями, то под Windows почти любое обновление - это перезагрузка сервера. Но к стабильности это никакого отношения не имеет.
Но я про десктопную.
Тоже самое. Просто количество решаемых задач больше, чем на сервреах, что усложняет локализацию проблем. Суть та же. Например, у нас инженеры под Windows с AutoCAD годами свои рабочие станции не перезагружают. А noname ноут с кривыми драйверами от дядюшки Ляо может требовать перезагрузку каждый день. Кто тут виноват? Разве Windows?
Не надо, а проще. Но ценой того, что все so при этом будут занимать место в оперативке, не взирая на то, что такие же so уже были загружены другими приложениями. При росте количества приложений в snap/flatpak/appimage, это выливается постепенно в гигабайты дополнительной потребности в памяти.
Я не мало администрировал AD и Windows сервера. Преимущественно, с MS SQL, AX, Exchange, Share Point и т.п. На низкую стабильность пожаловаться не могу. Может всё же стабильность зависит от того какие и как задачи решаются на системе?
И как получилось, что KDC и AD на работе и дома совпали? )))
Как он работать будет, если только установили рядом, условно, с PostgreSQL 17 PostgreSQL 18, причем последний вообще без БД? )))
Ну пусть даже initdb какой-то скрипт автоматом запустил. Но БД то всё равно получилась пустая без единой роли и паролей.
Новый каталог с чистого листа - это как раз обязательное требование. А дальше по обстоятельствам. Иногда можно использовать hard links в этот новый каталог и воспользоваться средствами pg_upgrade. Но чаще, конечно, СУБД поднимается с нуля, устанавливаются и проверяются все необходимых расширения, после чего данные заливаются из бекапа.
Конфиги, само собой правятся только в крайних случаях. Предпочитаю ALTER SYSTEM. Ну и вдумчивое чтение release notes обязательно. Например, я уже готов при переходе на 19-й PostgreSQL включать где нужно JIT компиляцию, которую в нем по-умолчанию вообще отключили.
Поясните Вашу мысль. Как отказ от контейнеров может хоть что-то сэкономить?
И каким скриптом там настраиваете, например, kerberos авторизацию или плагин для ЭЦП? И какой скрипт позволяет решить проблему с расширениями, которые новую версию не поддерживают? Там просто отличий от базовой конфигурации требуется на два-три порядка меньше, чем у тех же Asterisk или PostgreSQL. Но суть та же.
Ну как-то оно может случайно и заработает, но скорее всего результат будет весьма печален. По крайней мере документация рекомендует обновлять конфигурационные файлы вдумчиво и руками. Вы вообще осознаёте, что каждая мажорная версия PostgreSQL устанавливается в свой каталог, создаёт свой сервис и может функционировать совершенно независимо от установленных ранее версий? Там же при установке автоматическое обновление мажорных версий даже не предполагается.
Я уже молчу про Asterisk, где при обновлении на мажорную версию может потребоваться использовать другие модули и драйвера.
Это хотя бы семантически верно. А, например, ИИ вместо AI - семантически уже не верно из-за появляющейся антропоморфной окраски.
Попробуйте, например, просто перенести Citrix VPN (nsgclient) с Ubuntu 16.04 на 18.04, а затем последовательно на 20.04, 22.04 и 24.04. На 26.04 ещё не пробовал. Может уже полегчало. И подобный софт попадается с завидной регулярностью.
Это даже не касаясь более-менее сложного ПО, вроде Asterisk или PostgreSQL, где переход на новую мажорную версию всегда требует вдумчивого анализа конфигурации, а сброс настроек там в принципе неприемлем.
Какая разница? Замените Canonical на любую организацию, поддерживающую дистрибутив Linux. Сколько Вы дохода они от Вас получили? А сколько от enterpise?
То есть, Вы искренне считаете, что Canonical зарабатывает на таких пользователях, как Вы? Сколько же Вы ежемесячно донатите в open source, раз так думаете?
С точностью наоборот. Это обычный домашний пользователь может закрыть глаза на 1-2 ГБ RAM. А enterprise на гипервизоре или k8s, где таких систем с сотня при общем объеме 256 ГБ RAM, на сотню лишних ГБ глаза не закроет, если их можно будет освободить просто сменой дистрибутива.
Какую долю в доходах Canonical составляют такие клиенты, как Вы? Сколько Вы им уже заплатили? А какую долю в этих же поступлениях составляет enterprise?
Дальше объяснять или не надо?
Ну так как раз в этом AI может существенно помочь. Преподаватель больше сможет уделять времени прямому общению с обучающимися, если значительную часть подачи и объяснения материала возьмёт на себя AI.
А вот и корень проблемы. Именно из-за наплевательского отношения к потребностям клиентов, например, Ubuntu, продвигая snap, теряет клиентов. И чем больше приложений будет поставляться в snap - тем сильней будет этот отток. Особенно в enterpise, где проблем с самостоятельным обслуживанием и поддержкой нет. Я точно знаю уже несколько крупных компаний, отказавшихся от Ubuntu именно по этой причине.
Проблема не браузерах, а в перегруженных сайтах. Отсюда, enterprise от этого совершенно не страдает.
Я это указал:
"Ну так сервера под Linux тоже приходится перезагружать при некоторых обновлениях. Другое дело, что если под Linux большинство обновлений требуют лишь перезапуска сервисов, связанных с этими обновлениями, то под Windows почти любое обновление - это перезагрузка сервера. Но к стабильности это никакого отношения не имеет."
Но при чем тут стабильность?
Это издержки того, каждый flatpak содержит все необходимые приложению so, а так как с точки зрения системы в разных flatpak - это разные файлы, даже если они идентичны по содержиомому, то и грузит в память их система отдельно для каждого приложения, вместо того чтобы все приложения использовали один и тот же so. То есть, shared objects перестают быть shared.
В таких случаях указывают источник приводимой статистики. Где он?
Разница между VARCHAR и TEXT начинается с того, что исторически это разные oid в pg_type, что порой приводит к странным последствиям. Особенно в некоторых расширениях.
Поэтому, рекомендую вместо
писать просто
без скобок и максимальной длины.
В PostgreSQL оптимизатор не использует объявленную максимальную длину строки, опираясь в этом вопросе на статистику.
На брендовых рабочих станциях, сертифицированных AutoDesk - без проблем. Там же производитель действительно обеспечивает стабильность работы всех драйверов и дополнительных системных компонентов.
Так получилось, что для этого конкретного железа набор драйверов и системных компонентов Linux оказался стабильней, чем аналогичный, установленный в Windows. Легко могло получиться и наоборот.
Например, к проприетарным драйверам Realtek у меня (да и не только у меня) давно масса претензий к стабильности, тогда как opensource драйвера под Linux куда стабильней, хотя косяки с r8169 я ещё помню. Но это лишь один случай на моей памяти под Linux, против десятков кувырканий под Windows. Особенно с аудиодрайверами.
Все средства для локализации подобных проблем в Windows есть. Другое дело, что их подробное описание потребует даже не статьи, а целой серии статей.
Это сейчас уже в разных модулях разных систем и не всегда там все перечисленные решения. Но все эти приёмы изначально были применены в модуле прогнозирования и оптимизации перевозок по сети РЖД довольно крупного оператора подвижного парка.
Упрощённо, для того чтобы оперативно посчитать доходность размещенной заявки на перевозку и решить, предлагать ли её выполнение и по какой цене, нужны все эти решения. Так как тут учитывается прогнозы времени подачи, перевозки и отвода ~100 тыс. вагонов в соответствии с их текущей и прогнозируемой дислокациями, а так же с прогнозируемым ремонтами и техобслуживанием.
Я же написал: "все so при этом будут занимать место в оперативке, не взирая на то, что такие же so уже были загружены другими приложениями."
Запустите несколько приложений, поставляемых в flatpak, которые тянут за собой Qt, GTK или хотя бы Chromium (Electron). Сразу заметите, что объем памяти, потребляемый очередным запускаемым приложением, не зависит от того, было ли приложение, использующее те же so, запущено ранее.
Ага, засуньте штук пять KDE приложений каждое в свой в flatpak. И вместо буквально сотни мегабайт на все, при уже загруженном KDE, получите несколько гигабайт сожранной оперативки. А разные версии so вполне можно подсунуть символическими ссылками в chroot. Или собрать из исходников, как надо.
С другой стороны, часто ли такое надо? У меня на ноуте такие пассы пришлось делать буквально только с двумя проприетарными приложениями, которые ну никак не пересобрать самому.
Ну так сервера под Linux тоже приходится перезагружать при некоторых обновлениях. Другое дело, что если под Linux большинство обновлений требуют лишь перезапуска сервисов, связанных с этими обновлениями, то под Windows почти любое обновление - это перезагрузка сервера. Но к стабильности это никакого отношения не имеет.
Тоже самое. Просто количество решаемых задач больше, чем на сервреах, что усложняет локализацию проблем. Суть та же. Например, у нас инженеры под Windows с AutoCAD годами свои рабочие станции не перезагружают. А noname ноут с кривыми драйверами от дядюшки Ляо может требовать перезагрузку каждый день. Кто тут виноват? Разве Windows?
Не надо, а проще. Но ценой того, что все so при этом будут занимать место в оперативке, не взирая на то, что такие же so уже были загружены другими приложениями. При росте количества приложений в snap/flatpak/appimage, это выливается постепенно в гигабайты дополнительной потребности в памяти.
Я не мало администрировал AD и Windows сервера. Преимущественно, с MS SQL, AX, Exchange, Share Point и т.п. На низкую стабильность пожаловаться не могу. Может всё же стабильность зависит от того какие и как задачи решаются на системе?
Я в курсе, но человек то писал про "всё поле зрения, включая переферическое" (орфография сохранена).