hdparm нужно запускать без кэширования: "sudo hdparm -t-direct /dev/nvme0n1p2" - будут реальные результаты чтения. Также, dmesg выдает результаты загрузки ядра, и там внутри можно найти строки, в каком режиме поднят NVME. У меня при загрузке с NVME так: [ 4.773173] pci 0004:41:00.0: 2.000 Gb/s available PCIe bandwidth, limited by 2.5 GT/s PCIe x1 link at 0004:40:00.0 (capable of 15.752 Gb/s with 8.0 GT/s PCIe x2 link) А при загрузке с Micro-SD так: [ 6.932612] pci 0004:41:00.0: 4.000 Gb/s available PCIe bandwidth, limited by 5.0 GT/s PCIe x1 link at 0004:40:00.0 (capable of 15.752 Gb/s with 8.0 GT/s PCIe x2 link) Если в вашем логе - первый вариант, то это PCI-E 1.0 x1. И это 200 Мб/с максимум.
Orange Pi 5 построен на Rk3588s - а это радикально урезанный NVME. В данном случае - 1 (одна) линия PCI-E 2.1. Максимально достижимая производительность SSD на нем - 400 Мб/сек(350-380 реально). Причем в существующем ядре linux от rockchip 5.10.110...5.10.160 существует баг: если система загружается с NVME - то стандарт PCI-E сбрасывается на 1.0, а это 200 Мб/сек. Данное ядро используют и официальные linux, и armbian, и ubuntu от Joshua Riek. Я решил проблему так: изготовил Micro-SD с образом Ubuntu Joshua и залил его же на NVME. Загружаюсь с Micro-SD, а rootfs монтирую из раздела NVME - в итоге получается на нем PCI-E 2.1, жить можно))
Когда на tauri появится хотя бы одна вакансия в hh (в отличие от десятков и сотен на flutter) - появится хоть какой-то смысл в вопросе "Зачем использовать tauri"
Встречался с такой задачей часто на больших таблицах. Безусловно, должен быть join. С масштабируемостью in (...) - начинаются проблемы от 10к+ элементов, к тому же где-то этот массив в памяти надо разместить. Ну и P должен быть проиндексирован, а иначе Nested loops.
Этот синьорЦарь не виноват, ему дали строгие интерфейсы, разрешили наследование реализации, насыпали дженериков — вот он и написал библиотеку, в которой порезвился в compile-time, оверинжинирил по полной, попрятал в реализации грабли, да так что первый же мидлкузнец уволился.
Мне кажется мораль такова:
Не наследуй реализацию! Типизация интерфейсов должна быть утиная, чтобы не было соблазна валидировать на типах. Вообще не занимайтесь мета-программированием на типах, кривая дорожка заведет неизвестно куда.
Получается, кузнец ушел на Кипр в Go? Или в Rust? Криптоподковы на нем очень знатные, но на типах можно порезвиться пожестче. Непонятно.
Интереснейшая статья, спасибо. Подробный анализ от человека непосредственно "с полей", внимательно прочитал, во многом мои ощущения подтвердились. Похожее мнение у Attila Vágó в его статье "I Am Falling Out Of Love With Flutter" на медиуме.
Ограничения. Она сделана как "слегка приоткрытый закрытый продукт". Сравните с Community версиями нормального мэйнстрима — VS, например, которая по сути ничем не отличается от полноценной версии.
Зависимость от "доброй" воли 1С, которая может эту самую лицензию отобрать — а четких правил нет. Мы знаем историю с лицензированием 1С, когда даже честно купленные продукты переставали работать. Проблема 01.02.2021 знакома?
Я понимаю, что мое разочарование связано, в основном, с обманутыми ожиданиями.
Ожидания были, что появится Community-версия, такая как у всех. А появился совершенно не соответствующий названию продукт, полностью в стиле закрытой 1С.
Извините, но по этой статье можно сделать вывод, что вы абсолютно не разбираетесь в том, о чем пишете. Ни в 1С, ни в резервировании, ни в том, как вести учет.
Я искренне надеюсь, что курсы otus ведут гораздо более компетентные специалисты.
Полностью поддерживаю. Пробежался по другим статьям автора. Их уровень производит удручающее впечатление.
Непонятно даже, как объяснить автору в комментариях, где ошибка. С чего начать — с самых азов 1С, с оперативного учета или основ SQL? Поскольку даже в таких вопросах обнаруживается отсутствие системных знаний.
Не раскрыт вопрос: кому это "нам" не хватает настолько экзотических возможностей?
Если имеются в виду разработчики и архитекторы 1С — то нам совершенно точно не хватает только произвольного индексирования регистров накопления (но это касается всех прикладных объектов). В платформе много проблем, но регистры накопления — одна из самых беспроблемных вещей, что там есть.
Если по вопросу неотрицательных остатков у меня просто возникло недоумение (что??), то по поводу распределения глаза начали вылезать на лоб (вы вообще понимаете, что такое ORM и реляционные СУБД?), а по поводу точки актуальности в Заключении вы нагородили такой сонм логических и терминологических ошибок ("Функциональное" проведение???), что, честное слово, можно ответить только словами Филиппа Филипповича про советы космического масштаба и космической же глупости...
Ну, true-разработчикам ничего не мешает и при таких ограничениях делать из справочника регистр накопления (видел лично), а также из справочника — документ (внезапно, типовой 1С Документооборот: Справочник.ДокументыПредприятия).
Мне кажется, автор имел в виду не просто необходимость как-то расширить базовый Справочник, скажем, а общую бедность языка и фреймворка.
Нет никакого ООП, нет функционального программирования, нет хотя бы функций высшего порядка. Нет вообще ничего, у нас примитивнейший бэйсик!
Приведу конкретный пример. Мы не можем создать некий общий виджет, скажем "Согласование документа" с кучей кнопочек/менюшек, отображением состояния и прочего, инакпсулировать в него все обработчики, а потом просто кидать его на формы нужного документа, как это было бы в нормальном языке на современном фреймворке.
Вместо этого на формы нужных документов кидаем целую группу элементов копипастой, в коде формы делаем кучу отсылок и обработчиков всего этого опять таки копипастой, а в общих модулях делаем некий общий API. И такое дублирование — везде, не только в формах.
Поэтому нам приходится поддерживать 10 млн строк кода в ERP вместо 1 млн.
Асинхронность в виде колбеков пришла в 1С в 2013. Недостатки известны были всем, кроме фирмы 1С, видимо. Даже .Net уже перешел к тому времени на псевдосинхронность. Подзадержался только js.
Недавно, в 2020, в 1С наконец-то добавили псевдосинхронность. Теперь подождем еще лет 10, пока лапша из колбеков в БСП и типовых конфигурациях будет переписана.
Таким образом, временной лаг по сравнению с мэйнстримом составляет 5...15 лет.
Как 1Сник со стажем в 20+ лет, скажу — всё так, спасибо за статью и ощущение, что я не одинок. В 1С есть масса преимуществ. В 7.7 они превалировали. Но сейчас недостатки перевешивают драматически:
Клетка, отдельный мир. Весь ваш опыт будет нерелевантным, чтобы уйти в другие технологии хотя бы на уровне мидла.
Собственные велосипеды. Причем они всегда хуже, чем общепринятые технологии.
"Новая" IDE на базе уже мертвой Eclipse. Она ужасна. А старый конфигуратор просто бросили и не развивают. Мы сидим с плохим тулингом для разработки. Никаких VSCode или чего-то подобного.
Внедрили асинхронные колбеки, когда весь мир уже перешел на async/await. В формах лапша из безумного количества колбеков с похожими названиями, разобраться в которых решительно невозможно. На них же построена БСП, которую ни понять (overengineering), ни отладить (из-за разрыва контекста нет пошаговой отладки).
Сделали скриптовый язык со статической (!!!) типизацией, а платформа с тысячами модулей и зависимостями — остается с динамической. Смешно? Плакать хочется.
Непрерывное внедрение фич, которые зачастую — костыли на уровне платформы. Что характерно — багов добавляется больше. О стабильности работы хотя бы на уровне 10-летней давности я уже забыл — падает регулярно и клиент и сервер.
Обещали Community-версию платформы год назад. Выпустили тестовую версию. Она увешана кучей ограничений и при этом еженедельной отсылкой неких данных в 1С, на основании которых сама 1С может эту лицензию отозвать. Четких правил отзыва нет, всё зависит от "доброй воли" самой 1С. Вы понимаете всю пропасть между 1С и любой другой технологией?
Доверие к адекватности вендора подорвано окончательно. Когда выяснилось, что из себя представляет Community версия — для меня это стало последней каплей. Они не способны меняться. Они были, есть и будут закрытыми, устаревшими и некачественными. Они будут отставать от рынка всё сильнее и сильнее и похоронят в своей клетке всех разработчиков, кто делал на них ставку.
Поэтому я принял решение уйти из 1С.
Всё так. Только непонятно, зачем в эти Bad practices затесался прием №8? Конструкция прекрасно работает, сам пользуюсь и всем советую. А если запрос вернул вам миллиард строк, то это проблема запроса, а не загрузить-выгрузить. Как будто построчное заполнение тут может спасти)
hdparm нужно запускать без кэширования: "sudo hdparm -t-direct /dev/nvme0n1p2" - будут реальные результаты чтения. Также, dmesg выдает результаты загрузки ядра, и там внутри можно найти строки, в каком режиме поднят NVME. У меня при загрузке с NVME так:
[ 4.773173] pci 0004:41:00.0: 2.000 Gb/s available PCIe bandwidth, limited by 2.5 GT/s PCIe x1 link at 0004:40:00.0 (capable of 15.752 Gb/s with 8.0 GT/s PCIe x2 link)
А при загрузке с Micro-SD так:
[ 6.932612] pci 0004:41:00.0: 4.000 Gb/s available PCIe bandwidth, limited by 5.0 GT/s PCIe x1 link at 0004:40:00.0 (capable of 15.752 Gb/s with 8.0 GT/s PCIe x2 link)
Если в вашем логе - первый вариант, то это PCI-E 1.0 x1. И это 200 Мб/с максимум.
Orange Pi 5 построен на Rk3588s - а это радикально урезанный NVME. В данном случае - 1 (одна) линия PCI-E 2.1. Максимально достижимая производительность SSD на нем - 400 Мб/сек(350-380 реально). Причем в существующем ядре linux от rockchip 5.10.110...5.10.160 существует баг: если система загружается с NVME - то стандарт PCI-E сбрасывается на 1.0, а это 200 Мб/сек. Данное ядро используют и официальные linux, и armbian, и ubuntu от Joshua Riek. Я решил проблему так: изготовил Micro-SD с образом Ubuntu Joshua и залил его же на NVME. Загружаюсь с Micro-SD, а rootfs монтирую из раздела NVME - в итоге получается на нем PCI-E 2.1, жить можно))
Есть позиции с 1 по 10. Есть с 21 по 50. А где самая мякотка с 11 по 20?
Когда на tauri появится хотя бы одна вакансия в hh (в отличие от десятков и сотен на flutter) - появится хоть какой-то смысл в вопросе "Зачем использовать tauri"
Встречался с такой задачей часто на больших таблицах. Безусловно, должен быть join. С масштабируемостью in (...) - начинаются проблемы от 10к+ элементов, к тому же где-то этот массив в памяти надо разместить. Ну и P должен быть проиндексирован, а иначе Nested loops.
В пресс-релизе скромно умолчали про самое главное — удаление flatpak.
Этот
синьорЦарь не виноват, ему дали строгие интерфейсы, разрешили наследование реализации, насыпали дженериков — вот он и написал библиотеку, в которой порезвился в compile-time, оверинжинирил по полной, попрятал в реализации грабли, да так что первый жемидлкузнец уволился.Мне кажется мораль такова:
Не наследуй реализацию! Типизация интерфейсов должна быть утиная, чтобы не было соблазна валидировать на типах. Вообще не занимайтесь мета-программированием на типах, кривая дорожка заведет неизвестно куда.
Получается, кузнец ушел на Кипр в Go? Или в Rust? Криптоподковы на нем очень знатные, но на типах можно порезвиться пожестче. Непонятно.
Ваш технический прогресс:
Как вы постите котеек — На блокчейне, али без?
— Йес!
Интереснейшая статья, спасибо. Подробный анализ от человека непосредственно "с полей", внимательно прочитал, во многом мои ощущения подтвердились. Похожее мнение у Attila Vágó в его статье "I Am Falling Out Of Love With Flutter" на медиуме.
Я понимаю, что мое разочарование связано, в основном, с обманутыми ожиданиями.
Ожидания были, что появится Community-версия, такая как у всех. А появился совершенно не соответствующий названию продукт, полностью в стиле закрытой 1С.
а кто не может управлять — пишет статьи, как обустроить
вселенную1СВ удивительном мире мы живем.
Кто может работать — работает. Кто не может — учит.
Полностью поддерживаю. Пробежался по другим статьям автора. Их уровень производит удручающее впечатление.
Непонятно даже, как объяснить автору в комментариях, где ошибка. С чего начать — с самых азов 1С, с оперативного учета или основ SQL? Поскольку даже в таких вопросах обнаруживается отсутствие системных знаний.
Не раскрыт вопрос: кому это "нам" не хватает настолько экзотических возможностей?
Если имеются в виду разработчики и архитекторы 1С — то нам совершенно точно не хватает только произвольного индексирования регистров накопления (но это касается всех прикладных объектов). В платформе много проблем, но регистры накопления — одна из самых беспроблемных вещей, что там есть.
Если по вопросу неотрицательных остатков у меня просто возникло недоумение (что??), то по поводу распределения глаза начали вылезать на лоб (вы вообще понимаете, что такое ORM и реляционные СУБД?), а по поводу точки актуальности в Заключении вы нагородили такой сонм логических и терминологических ошибок ("Функциональное" проведение???), что, честное слово, можно ответить только словами Филиппа Филипповича про советы космического масштаба и космической же глупости...
Ну, true-разработчикам ничего не мешает и при таких ограничениях делать из справочника регистр накопления (видел лично), а также из справочника — документ (внезапно, типовой 1С Документооборот: Справочник.ДокументыПредприятия).
Мне кажется, автор имел в виду не просто необходимость как-то расширить базовый Справочник, скажем, а общую бедность языка и фреймворка.
Нет никакого ООП, нет функционального программирования, нет хотя бы функций высшего порядка. Нет вообще ничего, у нас примитивнейший бэйсик!
Приведу конкретный пример. Мы не можем создать некий общий виджет, скажем "Согласование документа" с кучей кнопочек/менюшек, отображением состояния и прочего, инакпсулировать в него все обработчики, а потом просто кидать его на формы нужного документа, как это было бы в нормальном языке на современном фреймворке.
Вместо этого на формы нужных документов кидаем целую группу элементов копипастой, в коде формы делаем кучу отсылок и обработчиков всего этого опять таки копипастой, а в общих модулях делаем некий общий API. И такое дублирование — везде, не только в формах.
Поэтому нам приходится поддерживать 10 млн строк кода в ERP вместо 1 млн.
Асинхронность в виде колбеков пришла в 1С в 2013. Недостатки известны были всем, кроме фирмы 1С, видимо. Даже .Net уже перешел к тому времени на псевдосинхронность. Подзадержался только js.
Недавно, в 2020, в 1С наконец-то добавили псевдосинхронность. Теперь подождем еще лет 10, пока лапша из колбеков в БСП и типовых конфигурациях будет переписана.
Таким образом, временной лаг по сравнению с мэйнстримом составляет 5...15 лет.
Как 1Сник со стажем в 20+ лет, скажу — всё так, спасибо за статью и ощущение, что я не одинок. В 1С есть масса преимуществ. В 7.7 они превалировали. Но сейчас недостатки перевешивают драматически:
Доверие к адекватности вендора подорвано окончательно. Когда выяснилось, что из себя представляет Community версия — для меня это стало последней каплей. Они не способны меняться. Они были, есть и будут закрытыми, устаревшими и некачественными. Они будут отставать от рынка всё сильнее и сильнее и похоронят в своей клетке всех разработчиков, кто делал на них ставку.
Поэтому я принял решение уйти из 1С.
Идёт программист по рынку труда, видит - стартап появился. Ну, он устроился в него и сгорел...