Вам просто повезло, что Вам нужно одновременно видеть так мало окон, что их можно разместить на экране таким образом, что одновременно нужные никогда не перекрывали бы друг друга и имели при этом комфортный размер для работы.
У меня, например, такие сочетания, что и 49" (сверхширокий) + 27" + 15" (родной ноута) мониторов не хватает. Например, хотя бы четверть Вашего экрана (1920x1080) явно нужны VS Code, DBEaver, Grafana, коммуникатору, на котором кто-то демонстрирует экран, во многих случаях RDP/VNC или VM и т.п. А ведь кроме этого нужно видеть консоль, мессенджеры, почту, wxMaxima, офисные приложения, Jira, Confluence, Bamboo, какую-то документацию в PDF и многое другое.
Причем почти каждое из перечисленных вполне может требовать 2-3 одновременно видимых окна.
Может у Вас иначе, но у меня поле зрения по горизонтали в два раза больше, чем по вертикали и явно превышает 180°. Да и поворачивать голову шея существенно меньше устаёт, чем если поднимать и опускать её.
Легко рассуждать только о своем личном мирке. Особенно, если РКН далеко и сам работаешь только в офисе. А в реальном мире люди работают удалённо с дачи/деревни, где даже при наличии оптики и резервного LTE канала легко можно или остаться без интернета, или увидеть VPN, отваливающийся каждые несколько минут. Когда такое происходит, явно эффективней поднять всё, что нужно для отладки и тестирования в локальном k8s, чем курить бамбук и объяснять работодателю, почему сроки завершения работ сдвигаются.
А с убунтой что-то с самого начала не складывается, по началу все неплохо, а через полгода начинает то тут, то там отваливаться... может карма не та ))
Может и карма, а может сами выбрали не LTS версию. Хотя snap c apparmor порой достают. Но из-за них "отваливается" с конкретными сообщениями в логах, что позволяет локализовать и исправить проблему на лету за минуты.
Впрочем, Debian тоже очень даже живой.
Ничего не имею против дистрибутивов с rolling обновлениями для прототипирования. Сам для этого Gentoo в VM держу. Но для продуктивной системы - это засада, так как очередное обновление легко может поставить систему или необходимое приложение раком, а работа может возникнуть неожиданно и срочная.
Из-за того, что MV обновляет только всё, а табличек с миллиардами строк у нас немало, от MV отказались полностью в пользу:
Инкрементального обновления хранимой процедурой. В частности, не только внутри текущей БД, но и в выделенной СУБД подготовки данных, получающей и отдающей данные через Кафка.
Двухступенчатого подхода, когда инкрементально в п.1 обновляются промежуточные таблицы, так как сам запрос не позволяет инкрементального обновления, но может быть на порядки ускорен этими промежуточными таблицами.
Партиционирования по условным сессиям с периодической перестройкой данных.
Ручной параллелизации запроса на несколько десятков ядер средствами dblink, с сохранением результатов запросов в нежурналируемые таблицы. Этот же механизм порой применяется в пунктах 1 и 2.
Использования колоночного хранения в ClickHouse и доступа к нему через FDW.
Для обеспечения конкурентности, используется как advisory_lock, так и переименование таблиц/партиций в БД. Но так как результаты почти всегда в нежурналируемых таблицах, то порой хватает штатных средств конкурентности.
Как-то меня коллега пытался уговорить на Микротик. Но мне тогда уже неинтересно было тратить часы, чтобы разобраться в его настройках. Другие роутеры – чик пык, за пять минут настроил, и интернет есть.
Так от задач исходим. Например, на подавляющем большинстве роутеров автоматическое переключение на резервный канал вообще никак не настроить без прошивки OpenWRT.
А если всё устраивает, то зачем искать приключений на свою голову?
Так Fedora по определению ориентирована на желающих принять участие в тестировании предполагаемых новых возможностей RHEL. Для продуктива лучше ставить Rocky, Oracle, Debian или хотя бы LTS релиз Ubuntu.
Недавно резервный комп настраивал. Полдня точно убил. Понятно, что в основном на установку и настройку приложений (почта, коммуникаторы, k8s, VS Code, Virtual Box, Wine и т.п.). Но в системе Kerberos, apparmor, cron, VPN (попробуйте поставить Citrix на Ubuntu 24.04 - поймете о чем я), firewall - это всё равно руками. Роутинг централизовано у меня по DHCP с OpenWRT.
На рюшечки мне вообще плевать. Всё равно 99% времени провожу в приложениях, развернутых на весь экран одного из мониторов. Десктоп вижу только при перезагрузке после обновлений системных компонентов. Midnight Commander или FAR мне как-то привычней.
Всё же не дошло и по прежнему настаиваете на том, что Вы демагог? Ну прощайте )))
Обсуждать это
смысла с демагогом не вижу. Вы даже не осознаёте, что среднее (!) время оборота грузового вагона на сетях РЖД сейчас более 22 суток. О каком "на следующий день" может идти речь, если SCM обязан использовать горизонт планирования в 2-3 месяца, как минимум?
На самом деле несложно посчитать самому. Спектральная эффективность 6G планируется всего в три раза выше, чем 5G, а пропускная способность - в 50-100 раз выше 5G при его работе на диапазонах от 24.25 ГГц до 71.0 ГГц, что и приводит нас к субтерагерцовому диапазону частот (свыше 100 ГГц) или даже к терагерцовому.
Давайте допустим, что ошибаюсь не я, а Вы!?))) И ваши примеры - это маленькая толика в море промпредприятий, для которых все не так, как Вы предполагаете, а так как предполагаю я!?)))
Давайте возьмём список ТОП-100 крупнейших предприятий РФ, исключим из них не промышленные, вроде банков, и посмотрим. Я не нашёл там ни одного, которое может обходится без долгосрочного планирования. Так что, увы, это допущение не оправдалось.
Тогда естественно предположить, что для первых нужен аппарат управления ERPlanning, а для вторых - ERReactioning.
Не естественно. Но можно утверждать, что горизонт планирования для разных целей требуется разный. Например, в логистике горизонт планирования может быть дни или часы в целях оперативного управления транспортом, месяцы - в целях техобслуживания и текущих ремонтов и годы - в целях капитальных ремонтов и иных капитальных вложений, включая обновления подвижного состава. Задачи краткосрочного планирования и SAP, и OEBS, и даже Dynamics замечательно решают. Там как раз с долгосрочным планированием больше проблем, что подвигло тот же SAP на интеграцию с River Logic.
с "высоты" моего 35-летнего профессионального опыта
Ой зря Вы применили демагогический приём Argumentum ad verecundiam. Неужели Вы думаете, что мой опыт меньше? )))
доля компаний 2ой группы 96%!
Докажите. Только не по количеству, а по доли в ВВП, прибыли, капитализации или хотя бы объемам реализации. А то даже по поверхностным прикидкам доля только ТЭК, который ну никак не может обойтись без долгосрочного планирования, занимает в РФ ~20% ВВП, что явно более Ваших 4%.
маркировать его как "ошибка"
Ошибка в концентрации на частности не видя общего.
Ваша главная ошибка в том, что Вы рассматриваете только некоторые виды бизнеса. Не то что АЭС, даже средних размеров завод без долгосрочного планирования не построить. Нефть или уголь добыть - тоже, так как нужно планировать геологоразведку и строительство транспортных магистралей. Даже в микроэлектронике, развивающейся огромными темпами, освоение новой технологии требует годы.
С учётом того, что 6G будет использовать если не терагерцовый, то субтерагерцовый диапазон частот, то или такие ДЦ должны быть чуть ли не в каждом доме, что вряд ли оправдано, или сигнал пойдет через спутник, что внесёт явно большую задержку, чем оптика.
Я к тому, что пока рекордная дальность прототипов 6G - мене километра, тогда как я у себя в деревне с ESP32-C3 умудрился тоже почти на километр по WiFi данные передавать. Так что даже если устанавливать ДЦ с GPU ближе к абоненту, то WiFi тут легко может на практике оказаться и дешевле и быстрее, чем 6G.
Я вижу явные преимущества 5G для IoT в большей энергоэффективности и меньших задержках.
Так как радиус действия 5G существенно меньше, чем LTE, то, кроме IoT, заметная польза от него только в местах массового скопления людей. Что же касается существенно более высокой скорости, то обычный пользователь в соцсетях этого и не заметит, а не обычный столкнется с совсем не снижающимися тарифами на мобильный интернет.
Я бы добавил главную беду - попытки перенести в CH реляционную структуру данных. Если разница между таблицами и справочнниками осознается сразу, то дублировать данные консерватизм мешает. И только столкнувшись с нехваткой памяти при JOIN, приходит понимание, что дублировать данные в CH необходимо. А Кодд пусть успокоится - CH не реляционная СУБД.
Во-первых, подобные функции безусловно полезны. Посему большое спасибо за публикацию на github.
Во-вторых, возможности, которые они предоставляют весьма ограничены. Например, без фильтра Калмана восстанавливать пропуски во временных рядах весьма проблематично.
Если вы работаете с временными рядами в PostgreSQL, скорее всего сталкивались с необходимостью в выгрузке данных в Python, а потом как-то возвращали результат обратно.
А вот от этого я отказался в пользу хранимых процедур на R (plr)
В принципе, тоже самое можно было делать и на plpython, но для моих задач R оказался удобней. В первую очередь, потому что тогда аналогов auto.arima из пакета forecast в Python просто не было, а фильтр Калмана я использовал именно в сочетании с ARIMA.
Если руководство, в первую очередь финдир при согласовании с главбухом, приняли решения возложить некоторые операции необходимые для управленческого и финансового учёта на бухгалтера - будет делать, как миленький. Проверено неоднократно в McDonalds, P&G, Bunge, Siemens и многих других компаниях, где я так или иначе принимал участие во внедрении ERP.
Ключевое - сейчас.
Бухгалтерский учёт - лишь ничтожная часть планирования ресурсов предприятия. И то, что 1С уже очень давно (с 2013 года) пытается из бухгалтерии сделать ERP без кардинального пересмотра архитектуры - это их проблемы.
Вы вообще всё перепутали. Одна из основных причин прокрастинации - физиологическая. Перегруженность работой, усталость и недостаток сна заставляют экономить ресурсы. Остальные причины - перфекционизм, страх неудачи и скучная рутина, так же не имеют никакого отношения ни к зажиточности, ни к условному изобилию.
Вам просто повезло, что Вам нужно одновременно видеть так мало окон, что их можно разместить на экране таким образом, что одновременно нужные никогда не перекрывали бы друг друга и имели при этом комфортный размер для работы.
У меня, например, такие сочетания, что и 49" (сверхширокий) + 27" + 15" (родной ноута) мониторов не хватает. Например, хотя бы четверть Вашего экрана (1920x1080) явно нужны VS Code, DBEaver, Grafana, коммуникатору, на котором кто-то демонстрирует экран, во многих случаях RDP/VNC или VM и т.п. А ведь кроме этого нужно видеть консоль, мессенджеры, почту, wxMaxima, офисные приложения, Jira, Confluence, Bamboo, какую-то документацию в PDF и многое другое.
Причем почти каждое из перечисленных вполне может требовать 2-3 одновременно видимых окна.
Может у Вас иначе, но у меня поле зрения по горизонтали в два раза больше, чем по вертикали и явно превышает 180°. Да и поворачивать голову шея существенно меньше устаёт, чем если поднимать и опускать её.
Легко рассуждать только о своем личном мирке. Особенно, если РКН далеко и сам работаешь только в офисе. А в реальном мире люди работают удалённо с дачи/деревни, где даже при наличии оптики и резервного LTE канала легко можно или остаться без интернета, или увидеть VPN, отваливающийся каждые несколько минут. Когда такое происходит, явно эффективней поднять всё, что нужно для отладки и тестирования в локальном k8s, чем курить бамбук и объяснять работодателю, почему сроки завершения работ сдвигаются.
Может и карма, а может сами выбрали не LTS версию. Хотя snap c apparmor порой достают. Но из-за них "отваливается" с конкретными сообщениями в логах, что позволяет локализовать и исправить проблему на лету за минуты.
Впрочем, Debian тоже очень даже живой.
Ничего не имею против дистрибутивов с rolling обновлениями для прототипирования. Сам для этого Gentoo в VM держу. Но для продуктивной системы - это засада, так как очередное обновление легко может поставить систему или необходимое приложение раком, а работа может возникнуть неожиданно и срочная.
Впервые слышу, что уязвимости в RHEL закрываются позже, чем в Fedora. Можете указать источник такой статистики?
Из-за того, что MV обновляет только всё, а табличек с миллиардами строк у нас немало, от MV отказались полностью в пользу:
Инкрементального обновления хранимой процедурой. В частности, не только внутри текущей БД, но и в выделенной СУБД подготовки данных, получающей и отдающей данные через Кафка.
Двухступенчатого подхода, когда инкрементально в п.1 обновляются промежуточные таблицы, так как сам запрос не позволяет инкрементального обновления, но может быть на порядки ускорен этими промежуточными таблицами.
Партиционирования по условным сессиям с периодической перестройкой данных.
Ручной параллелизации запроса на несколько десятков ядер средствами dblink, с сохранением результатов запросов в нежурналируемые таблицы. Этот же механизм порой применяется в пунктах 1 и 2.
Использования колоночного хранения в ClickHouse и доступа к нему через FDW.
Для обеспечения конкурентности, используется как advisory_lock, так и переименование таблиц/партиций в БД. Но так как результаты почти всегда в нежурналируемых таблицах, то порой хватает штатных средств конкурентности.
Так от задач исходим. Например, на подавляющем большинстве роутеров автоматическое переключение на резервный канал вообще никак не настроить без прошивки OpenWRT.
А если всё устраивает, то зачем искать приключений на свою голову?
Так Fedora по определению ориентирована на желающих принять участие в тестировании предполагаемых новых возможностей RHEL. Для продуктива лучше ставить Rocky, Oracle, Debian или хотя бы LTS релиз Ubuntu.
Недавно резервный комп настраивал. Полдня точно убил. Понятно, что в основном на установку и настройку приложений (почта, коммуникаторы, k8s, VS Code, Virtual Box, Wine и т.п.). Но в системе Kerberos, apparmor, cron, VPN (попробуйте поставить Citrix на Ubuntu 24.04 - поймете о чем я), firewall - это всё равно руками. Роутинг централизовано у меня по DHCP с OpenWRT.
На рюшечки мне вообще плевать. Всё равно 99% времени провожу в приложениях, развернутых на весь экран одного из мониторов. Десктоп вижу только при перезагрузке после обновлений системных компонентов. Midnight Commander или FAR мне как-то привычней.
Я же написал, не дошло, хотя я явно указал, как этот демагогический приём называется: Argumentum ad verecundiam.
А дискутировать с демагогом - бессмысленное занятие.
Всё же не дошло и по прежнему настаиваете на том, что Вы демагог? Ну прощайте )))
Обсуждать это
смысла с демагогом не вижу. Вы даже не осознаёте, что среднее (!) время оборота грузового вагона на сетях РЖД сейчас более 22 суток. О каком "на следующий день" может идти речь, если SCM обязан использовать горизонт планирования в 2-3 месяца, как минимум?
Легковесный - это aria2. Ну или, с некоторой натяжкой, transmission.
Например, отсюда, отсюда и отсюда. Хватит?
На самом деле несложно посчитать самому. Спектральная эффективность 6G планируется всего в три раза выше, чем 5G, а пропускная способность - в 50-100 раз выше 5G при его работе на диапазонах от 24.25 ГГц до 71.0 ГГц, что и приводит нас к субтерагерцовому диапазону частот (свыше 100 ГГц) или даже к терагерцовому.
Эта статья вообще-то про 5G, а не 6G.
Давайте возьмём список ТОП-100 крупнейших предприятий РФ, исключим из них не промышленные, вроде банков, и посмотрим. Я не нашёл там ни одного, которое может обходится без долгосрочного планирования. Так что, увы, это допущение не оправдалось.
Не естественно. Но можно утверждать, что горизонт планирования для разных целей требуется разный. Например, в логистике горизонт планирования может быть дни или часы в целях оперативного управления транспортом, месяцы - в целях техобслуживания и текущих ремонтов и годы - в целях капитальных ремонтов и иных капитальных вложений, включая обновления подвижного состава. Задачи краткосрочного планирования и SAP, и OEBS, и даже Dynamics замечательно решают. Там как раз с долгосрочным планированием больше проблем, что подвигло тот же SAP на интеграцию с River Logic.
Ой зря Вы применили демагогический приём Argumentum ad verecundiam. Неужели Вы думаете, что мой опыт меньше? )))
Докажите. Только не по количеству, а по доли в ВВП, прибыли, капитализации или хотя бы объемам реализации. А то даже по поверхностным прикидкам доля только ТЭК, который ну никак не может обойтись без долгосрочного планирования, занимает в РФ ~20% ВВП, что явно более Ваших 4%.
Ошибка в концентрации на частности не видя общего.
Ваша главная ошибка в том, что Вы рассматриваете только некоторые виды бизнеса. Не то что АЭС, даже средних размеров завод без долгосрочного планирования не построить. Нефть или уголь добыть - тоже, так как нужно планировать геологоразведку и строительство транспортных магистралей. Даже в микроэлектронике, развивающейся огромными темпами, освоение новой технологии требует годы.
С учётом того, что 6G будет использовать если не терагерцовый, то субтерагерцовый диапазон частот, то или такие ДЦ должны быть чуть ли не в каждом доме, что вряд ли оправдано, или сигнал пойдет через спутник, что внесёт явно большую задержку, чем оптика.
Я к тому, что пока рекордная дальность прототипов 6G - мене километра, тогда как я у себя в деревне с ESP32-C3 умудрился тоже почти на километр по WiFi данные передавать. Так что даже если устанавливать ДЦ с GPU ближе к абоненту, то WiFi тут легко может на практике оказаться и дешевле и быстрее, чем 6G.
Я вижу явные преимущества 5G для IoT в большей энергоэффективности и меньших задержках.
Так как радиус действия 5G существенно меньше, чем LTE, то, кроме IoT, заметная польза от него только в местах массового скопления людей. Что же касается существенно более высокой скорости, то обычный пользователь в соцсетях этого и не заметит, а не обычный столкнется с совсем не снижающимися тарифами на мобильный интернет.
Я бы добавил главную беду - попытки перенести в CH реляционную структуру данных. Если разница между таблицами и справочнниками осознается сразу, то дублировать данные консерватизм мешает. И только столкнувшись с нехваткой памяти при JOIN, приходит понимание, что дублировать данные в CH необходимо. А Кодд пусть успокоится - CH не реляционная СУБД.
Во-первых, подобные функции безусловно полезны. Посему большое спасибо за публикацию на github.
Во-вторых, возможности, которые они предоставляют весьма ограничены. Например, без фильтра Калмана восстанавливать пропуски во временных рядах весьма проблематично.
А вот от этого я отказался в пользу хранимых процедур на R (plr)
В принципе, тоже самое можно было делать и на plpython, но для моих задач R оказался удобней. В первую очередь, потому что тогда аналогов auto.arima из пакета forecast в Python просто не было, а фильтр Калмана я использовал именно в сочетании с ARIMA.
Если руководство, в первую очередь финдир при согласовании с главбухом, приняли решения возложить некоторые операции необходимые для управленческого и финансового учёта на бухгалтера - будет делать, как миленький. Проверено неоднократно в McDonalds, P&G, Bunge, Siemens и многих других компаниях, где я так или иначе принимал участие во внедрении ERP.
Бухгалтерский учёт - лишь ничтожная часть планирования ресурсов предприятия. И то, что 1С уже очень давно (с 2013 года) пытается из бухгалтерии сделать ERP без кардинального пересмотра архитектуры - это их проблемы.
Вы вообще всё перепутали. Одна из основных причин прокрастинации - физиологическая. Перегруженность работой, усталость и недостаток сна заставляют экономить ресурсы. Остальные причины - перфекционизм, страх неудачи и скучная рутина, так же не имеют никакого отношения ни к зажиточности, ни к условному изобилию.