А вот и корень проблемы. Именно из-за наплевательского отношения к потребностям клиентов, например, 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 и т.п. На низкую стабильность пожаловаться не могу. Может всё же стабильность зависит от того какие и как задачи решаются на системе?
Если сложно посчитать самому могу и я. Получается 12-14.
Вот ни одного сценария не могу придумать, чтобы мне нужны были одновременно и ВсКоде, и Графана, и электронная почта...
Ну значит Вам повезло. Но из этого совершенно не следует, что и у других такая же ситуация. Что Вы хотите этим сказать? Что Вы образец и у всех должно быть так же? )))
прям завидую Вашей многозадочности и способности настолько быстро переключаться между кучей задач в моменте
Задача в примере как раз одна - локализация проблемы. А вот одновременно используемых для этого инструментов действительно изрядно.
При чем тут виртуальные рабочие столы? Они полезны, если на одном компьютере человек решает разные задачи. Но я же веду речь речь о решении одних и тех же задач в производственном процессе, требующих свыше десятка одновременно видимых окон.
с расстояния вытянутой руки он займёт всё поле зрения, включая переферическое
Ну так Вы бы с этого и начинали, что у Вас ограниченные способности. У подавляющего большинства людей поле зрение от 180° до 220° по горизонтали. У меня так точно не меньше 180°.
Физику с биологией не наеобманешь.
Вот именно. А исключения в виде людей с ограниченными способностями, естественно, есть. Тут Вам не позавидуешь. Так что Вам повезло дважды.
Вопрос не в том, что "стабильней и проще". Вопрос в том, какие именно задачи нужно решать. Если в приоритете AutoCAD, то естественно Windows "стабильней и проще". А если всю разработку приходится писать под Linux на беке и под браузер на фронте, то где тут место для Windows?
А далее, с какой системой больше приходится работать, та и становится субъективно "стабильней и проще".
Я то как раз отлично понимаю, что у разных сотрудников даже в моей команде совершенно разные потребности. Потому и написал, что Вам просто повезло.
А вот у Вас явные сложности с пониманием этого же. Ваша личная ситуация по определению не может претендовать на общее.
По сути у меня 4 монитора 43"
Далее Вы пишете совершенно противоположное:
Один большой монитор
А у меня, простите, только один из трёх мониторов 49".
Зачем вам одновлеменно, VS Code и мессенджеры?
Для примера, достаточно типовая ситуация, которая была в минувшую пятницу. Есть микросервисные системы у двух компаний в одном холдинге, которые связаны друг с другом по gRPC. Сотрудники из одной компании доступны, в основном, в IVA, из другой - в kTalk. Графаны у них тоже разные. Confluence хотя бы один. Итого для локализации этой проблемы мне нужно одновременно видеть две графаны, Confluence (часто больше одной страницы), два мессенджера и почту, в которой эта проблема описана со стороны её обнаружившего со всей нитью её последующих обсуждений. Кроме этого, само собой, мне необходимы VS Code, DBEaver (желательно два окна, чтобы не переключаться между табами), Kafka UI с kSQL да еще локальная консоль с gRPCurl и терминал с ssh.
А бывает, что ещё результаты расчётов надо проверять в wxMaxima и видеть документацию, которая в PDF, odt, ods или вообще размазана во всех трех форматах. В итоге, я уже подумываю, не заменить ли мне 27" монитор на второй 49".
P.S. Про окна с Rail-тариф и консолью ЭТРАН с АСОУП-3 еще забыл.
Как вы в ноутбук, например, вставите винт на 30TB или полноценную 5090 для нейросеток?
Технически, через OCuLink или десктоп/сервер в локальной сети. Вот только почему Вы решили что это необходимо всем, да еще и востребовано 100% рабочего времени? Необходимость резервирования таких средств если и есть у кого-то, то это скорее исключение, чем правило.
К чему это? Чем это сообщение может кому-то быть полезным?
Вы уже который замыкаетесь на своем уникальном мире, где оптику если и порвут, то восстановят меньше, чем за час, а резервный канал мобильного интернета не ляжет случайно в это же время и чуть ли не по тем же причинам.
А вот и корень проблемы. Именно из-за наплевательского отношения к потребностям клиентов, например, 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 и т.п. На низкую стабильность пожаловаться не могу. Может всё же стабильность зависит от того какие и как задачи решаются на системе?
Я в курсе, но человек то писал про "всё поле зрения, включая переферическое" (орфография сохранена).
Если сложно посчитать самому могу и я. Получается 12-14.
Ну значит Вам повезло. Но из этого совершенно не следует, что и у других такая же ситуация. Что Вы хотите этим сказать? Что Вы образец и у всех должно быть так же? )))
Задача в примере как раз одна - локализация проблемы. А вот одновременно используемых для этого инструментов действительно изрядно.
При чем тут виртуальные рабочие столы? Они полезны, если на одном компьютере человек решает разные задачи. Но я же веду речь речь о решении одних и тех же задач в производственном процессе, требующих свыше десятка одновременно видимых окон.
И пример с подробным описание привёл.
Ну так Вы бы с этого и начинали, что у Вас ограниченные способности. У подавляющего большинства людей поле зрение от 180° до 220° по горизонтали. У меня так точно не меньше 180°.
Вот именно. А исключения в виде людей с ограниченными способностями, естественно, есть. Тут Вам не позавидуешь. Так что Вам повезло дважды.
С этим как раз никто не спорит. Удивляет, что Вы тут усиленно пытаетесь доказать, что мобильность не нужна никому, раз она не нужна Вам )))
Человек же Вам открытым текстом написал, что ему нужна возможность мобильности! Что Вы тут пытались доказать?
Вопрос не в том, что "стабильней и проще". Вопрос в том, какие именно задачи нужно решать. Если в приоритете AutoCAD, то естественно Windows "стабильней и проще". А если всю разработку приходится писать под Linux на беке и под браузер на фронте, то где тут место для Windows?
А далее, с какой системой больше приходится работать, та и становится субъективно "стабильней и проще".
Я то как раз отлично понимаю, что у разных сотрудников даже в моей команде совершенно разные потребности. Потому и написал, что Вам просто повезло.
А вот у Вас явные сложности с пониманием этого же. Ваша личная ситуация по определению не может претендовать на общее.
Далее Вы пишете совершенно противоположное:
А у меня, простите, только один из трёх мониторов 49".
Для примера, достаточно типовая ситуация, которая была в минувшую пятницу. Есть микросервисные системы у двух компаний в одном холдинге, которые связаны друг с другом по gRPC. Сотрудники из одной компании доступны, в основном, в IVA, из другой - в kTalk. Графаны у них тоже разные. Confluence хотя бы один. Итого для локализации этой проблемы мне нужно одновременно видеть две графаны, Confluence (часто больше одной страницы), два мессенджера и почту, в которой эта проблема описана со стороны её обнаружившего со всей нитью её последующих обсуждений. Кроме этого, само собой, мне необходимы VS Code, DBEaver (желательно два окна, чтобы не переключаться между табами), Kafka UI с kSQL да еще локальная консоль с gRPCurl и терминал с ssh.
А бывает, что ещё результаты расчётов надо проверять в wxMaxima и видеть документацию, которая в PDF, odt, ods или вообще размазана во всех трех форматах. В итоге, я уже подумываю, не заменить ли мне 27" монитор на второй 49".
P.S. Про окна с Rail-тариф и консолью ЭТРАН с АСОУП-3 еще забыл.
Технически, через OCuLink или десктоп/сервер в локальной сети. Вот только почему Вы решили что это необходимо всем, да еще и востребовано 100% рабочего времени? Необходимость резервирования таких средств если и есть у кого-то, то это скорее исключение, чем правило.
К чему это? Чем это сообщение может кому-то быть полезным?
Вы уже который замыкаетесь на своем уникальном мире, где оптику если и порвут, то восстановят меньше, чем за час, а резервный канал мобильного интернета не ляжет случайно в это же время и чуть ли не по тем же причинам.