Встречал на эту тему статьи, там для накопительных баков с водой использовалась аэрация. Там правда вода из скважины а не дождевая, но возможно аэрация в баках/баке и вам чем-то поможет. Ну и статьи на том сайте тоже интересные - умный дом и все такое.
С одной стороны - просто и достаточно удобно. С другой - переизобретаем уже изобретенное.
Для чего делать один файл с секциями если можно на каждую секцию сделать по файлу, и не копать общий файл через awk. Бонусом имеем просмотр всех тем-ключевых слов просто в виде имен файлов, и файловая система будет сама следить за их уникальностью. в одном файле следить за уникальностью секций придется самостоятельно, и в большом файле может быть неудобно.
По большому счету - это переизобретение классического man который есть в любой системе. Добавляем в конфиг мана свою папку, что бы свои читы не класть в системные папки, и все работает. Правда писать странички на языке разметки манов не очень удобно.
Именовать файлы можно с расширением .md и писать с применением разметки. Тот же nano при редактировании .md-файлов автоматом подсвечивает разметку. Даже без исполнения этой разметки, только с подсвечиванием - это уже удобнее. Вывести тест в консоль с подсветкий синтаксиса можно программкой bat (примерно как cat только умеет подсвечивать множество синтаксисов).
Если ключевых слов наберется много, можно написать скриптик с применением fzf который покажет этот список, зафильтрует, даст выбрать один из (или не один) и даже можно сделать показ превью, через тот же bat с подсветкой синтаксиса.
Можно сделать много файлов с уточнением ключей, что бы итоговые файлы получались небольшие. Что бы среди них выбрать - запускаем их список через fzf, набирая буквы быстро фильтруем большой список, уточняя его до потребного состояния, из оставшегося выбираем нужное, выводим на экран. Кстати, через fzf можно не только выбрать, но и передать в командную строку не выполняя, потом подставляем руками нужный аргумент или редактируем - и готово.
КГД и КЦГД - это уже ДВК 3 и выше, конструктив другой, со встроенным монитором, и корзиной установленной вертикально позади кинескопа в корпусе. А речь шла про ДВК-2М.
Помню такое. Причем, раз все равно компиляется в макроассемблер, то можно было в тексте паскаля писать вставки на макроассемблере, которые работали.
Еще помню что на одну системную дискету не влазили одновременно транслятор и линковщик, поэтому были две системные дискеты, она с редактором и транслятором, вторая - с линковщиком. Соответственно, перед линковкой системную дискету меняли. ОС, естественно не перегружали - ей было все равно :) Исходники и объектники - во втором дисководе.
Приточка с улицы - источник пыли, что для серверной очень плохо.
У нас в "серверной" два кондея, один летний, другой зимний. По смыслу они одинаковы, но у "зимнего" внешний блок висит не на улице а во входном коридоре-тамбуре, и зимой хорошо его отапливает. Зачем выкидывать тепло на улицу если можно использовать с пользой. У "летнего" кондея внешний блок на улице, и его приходится обслуживать, чистить от пыли. У "зимнего" внешний блок в помещении, и в таком обслуживании он не нуждается.
Ну и т.к. в серверной нет ни приточки ни вытяжки - пыль там не собирается, системники всегда чистые.
Два кондея - это еще и резервирование. Если летом сдохнет летний - можно включить зимний, открыв дверь из тамбура на улицу. Если зимой сдохнет зимний - то если не сильный мороз, то можно попробовать включить летний. Если сильный мороз - то придется просто проветривать, на время ремонта. На этот случай есть воздушный канал между серверной и it-отделом, с мощным вентилятором. Но для отопления it-отдела этот метод на постоянку не используется т.к. натянет пыль в серверную.
Там поди был какой-то старый Firebird архитектуры супер-сервер, который не умеет параллелиться. Старый сервер был, условно с одним ядром, но с большой частотой, и FB его успешно использовал. А на вашем новом сервере поди 64 ядра, но с частотой в 3-4 раза меньше, вот FB сел на одно медленное ядро, и слил всю скорость :)
На заглавной картинке КДПВ, в штампе подписи, указаны странные сроки. Дата окончания меньше даты начала действия. Там данные совсем с потолка, или где-то в коде есть ошибка?
Оно не узкое. После того как актуальность версий заканчивается, это место будет в дальнейшем использовано. Уборка "мусорных версий" производится при обращении к записи, сервер определяет какую из версий может видеть клиент, а какие версии уже никому не нужны. Т.е. убирать будет не тот кто эти версии создал, или удержал, а следующий за ними клиент/транзакция. От этого есть несколько решений - не держать длинных транзакций без необходимости. При удалении большого количества записей лучше тут же их прочитать, из той процедуры которая удаляла, но в новой транзакции. Таким образом замедление будет у того кто удалял а не у следующего, типа "необъяснимое торможение".
Так что совершенно не факт что " отдельный undo log лучше ".
В отличие от косилки управляемой человеком-оператором, робот может работать в нонстопе круглосуточно, прерываясь только на зарядку. За счет частого кошения скошенная часть очень мелкая и ее буквально не видно. Это даже не мульча а еще мельче. Она падает на грунт между травинок и очень быстро уходит в грунт, перегнивая.
Робот-косилка - это не скосить бурьян, это поддерживать в заданном состоянии газон, подготовленный для робота заранее. Высокую траву он не возьмет. Поэтому робот-косилка - это не вместо обычной косилки, а в дополнение к обычной. Иначе вы не сможете эксплуатировать робот в случае каких-то эксцессов. Ну и обычно не 100% площади покрыто роботом, остаются участки которые для робота подготавливать неэффективно (далеко кабель тянуть, препятствия, трава растет за забором за пределами вашего участка и выпускать туда робота опасно), поэтому всегда есть работа и для обычной косилки, но конечно в гораздо меньшем объеме.
Про робота-газонокосилку написана полная фигня, не имеющая отношение к жизни роботов :)
Роботам по самой идее автономной работы не нужен бункер для сбора травы. И никакого сена после робота не остается, и даже если постараться - после робота ничего граблями не соберешь.
Роботы бывают с разным принципом управления - через заложенный в землю/траву кабель, лограничивающий периметр и задающий зоны, или сейчас уже появились в продаже роботы которые умеют работать без кабеля, ориентируясь по датчику координат относительно базовой станции-излучателя.
Роботы бывают расчитаны на разную площадь кошения, и это существенно влияет на их цену.
Роботам дождь по барабану, могут косить и в дождь, просто это может создать проблемы как газону так и роботу (налипнет мокрая мульча на пузо, поотребуется чистка), поэтому на многих роботах стоит датчик дождя, и они в дождь не косят, если это не отключено в настройках.
Роботы бывают с управлением через сеть/интернет, или автономные. Автономные дешевле, но отсутствие информации о том чего там с роботом происходит, может быть критично. Например, в период интенсивного роста травы он заехал в ямку и застрял. Вы приезжаете через неделю - а весь участок уже зарос травой, которую робот уже не возьмет, нужно предварительно готовить участок обычной косилкой, плюс робот разрядился в ноль, плюс в нем завелись муравьи, через него проросла трава и т.п. Лучше знать про такую фигню вовремя, приехать и вытащить робота из ямки, отнести на базу на зарядку.
У Алексея Надежина весьма информативные обзоры про роботы-газонокосилки.
Лучшая защита от пыли - не пускать пыль внутрь, и не собирать ее. Засовываем комп в металлический ящик. Комп работает внутри, гоняет воздух внутри ящика, не получая притока пыли извне. Ящик сколько-то греется, отдавая тепло через поверхность. Если внутри не сильно греющееся устройство - то тепловой баланс сохраняется, комп не перегревается, пыли вообще не видит. Не нужно никаких фильтров и борьбы с пылью, за ее отсутствием.
БП ноута можно или оставить снаружи т.к. он пыли не боится, либо прикрутить к металлическому ящику изнутри или снаружи, что бы улучшить охлаждение. Если штатный БП совсем мелкий, расчитанный на втыкание прям в розетку, то можно купить универсальный, побольше мощностью, что бы меньше грелся.
Мне кажется что при сравнении не учтено что у PostgreSQL есть еще журнал транзакций который хранится вне базы, и растет при работе с базой, что вызывает необходимость его потом как-то урезать. У Firebird отдельного журнала нет, эта инфа пишется в самой базе.
Про экономию 200т.р. написано прямо в заголовке. Люди читают статью и не могут найти откуда такая экономия вообще получается.
Мне статья понравилась, но для того что бы понять про что она, потребовалось прочитать 2-3 раза. Сама задача выглядит странной, но интересно было посмотреть пример применения HomeAssistant и умных девайсов. Обычно примеры сильно притянуты за уши, а в данном случае получилось просто (с учетом что HA уже был) и эффективно (заменили одну лампочку на умную, сделали скрипты-настройки в HA).
Сейчас дофига машин где у АКПП есть ручной режим, а переключать передачи можно подрулевыми лепестками.
Но есть момент. Передач сейчас 7-9 и переключать их вручную задалбывает через несколько секунд. И при этом добиться плавности движения, как при автоматическим переключении передач, физически невозможно.
Мне смутно помнится, что когда Дуров первый раз хотел запустить свою валюту TON, то в США были сильно и продуктивно недовольны, и Дуров от TON отказался.
И вот, вроде бы недавно этот TON таки запустили в работу. Возможно с этим и связаны претензии - валюты-конкуренты никому не нужны.
Встречал на эту тему статьи, там для накопительных баков с водой использовалась аэрация. Там правда вода из скважины а не дождевая, но возможно аэрация в баках/баке и вам чем-то поможет. Ну и статьи на том сайте тоже интересные - умный дом и все такое.
https://ab-log.ru/smart-house/1-wire/water_cleaning
С одной стороны - просто и достаточно удобно. С другой - переизобретаем уже изобретенное.
Для чего делать один файл с секциями если можно на каждую секцию сделать по файлу, и не копать общий файл через awk. Бонусом имеем просмотр всех тем-ключевых слов просто в виде имен файлов, и файловая система будет сама следить за их уникальностью. в одном файле следить за уникальностью секций придется самостоятельно, и в большом файле может быть неудобно.
По большому счету - это переизобретение классического man который есть в любой системе. Добавляем в конфиг мана свою папку, что бы свои читы не класть в системные папки, и все работает. Правда писать странички на языке разметки манов не очень удобно.
Именовать файлы можно с расширением .md и писать с применением разметки. Тот же nano при редактировании .md-файлов автоматом подсвечивает разметку. Даже без исполнения этой разметки, только с подсвечиванием - это уже удобнее. Вывести тест в консоль с подсветкий синтаксиса можно программкой bat (примерно как cat только умеет подсвечивать множество синтаксисов).
Если ключевых слов наберется много, можно написать скриптик с применением fzf который покажет этот список, зафильтрует, даст выбрать один из (или не один) и даже можно сделать показ превью, через тот же bat с подсветкой синтаксиса.
Можно сделать много файлов с уточнением ключей, что бы итоговые файлы получались небольшие. Что бы среди них выбрать - запускаем их список через fzf, набирая буквы быстро фильтруем большой список, уточняя его до потребного состояния, из оставшегося выбираем нужное, выводим на экран. Кстати, через fzf можно не только выбрать, но и передать в командную строку не выполняя, потом подставляем руками нужный аргумент или редактируем - и готово.
КГД и КЦГД - это уже ДВК 3 и выше, конструктив другой, со встроенным монитором, и корзиной установленной вертикально позади кинескопа в корпусе. А речь шла про ДВК-2М.
Какая графика на ДВК-2М? Там же алфавитно-цифровой терминал 15-ИЭ-00-013, подключаемый через последовательный порт. :)
Помню такое. Причем, раз все равно компиляется в макроассемблер, то можно было в тексте паскаля писать вставки на макроассемблере, которые работали.
Еще помню что на одну системную дискету не влазили одновременно транслятор и линковщик, поэтому были две системные дискеты, она с редактором и транслятором, вторая - с линковщиком. Соответственно, перед линковкой системную дискету меняли. ОС, естественно не перегружали - ей было все равно :) Исходники и объектники - во втором дисководе.
Тем что РЕД База Данных - это форк Firebird.
Приточка с улицы - источник пыли, что для серверной очень плохо.
У нас в "серверной" два кондея, один летний, другой зимний. По смыслу они одинаковы, но у "зимнего" внешний блок висит не на улице а во входном коридоре-тамбуре, и зимой хорошо его отапливает. Зачем выкидывать тепло на улицу если можно использовать с пользой. У "летнего" кондея внешний блок на улице, и его приходится обслуживать, чистить от пыли. У "зимнего" внешний блок в помещении, и в таком обслуживании он не нуждается.
Ну и т.к. в серверной нет ни приточки ни вытяжки - пыль там не собирается, системники всегда чистые.
Два кондея - это еще и резервирование. Если летом сдохнет летний - можно включить зимний, открыв дверь из тамбура на улицу. Если зимой сдохнет зимний - то если не сильный мороз, то можно попробовать включить летний. Если сильный мороз - то придется просто проветривать, на время ремонта. На этот случай есть воздушный канал между серверной и it-отделом, с мощным вентилятором. Но для отопления it-отдела этот метод на постоянку не используется т.к. натянет пыль в серверную.
Там поди был какой-то старый Firebird архитектуры супер-сервер, который не умеет параллелиться. Старый сервер был, условно с одним ядром, но с большой частотой, и FB его успешно использовал. А на вашем новом сервере поди 64 ядра, но с частотой в 3-4 раза меньше, вот FB сел на одно медленное ядро, и слил всю скорость :)
На заглавной картинке КДПВ, в штампе подписи, указаны странные сроки. Дата окончания меньше даты начала действия. Там данные совсем с потолка, или где-то в коде есть ошибка?
Оно не узкое. После того как актуальность версий заканчивается, это место будет в дальнейшем использовано. Уборка "мусорных версий" производится при обращении к записи, сервер определяет какую из версий может видеть клиент, а какие версии уже никому не нужны. Т.е. убирать будет не тот кто эти версии создал, или удержал, а следующий за ними клиент/транзакция. От этого есть несколько решений - не держать длинных транзакций без необходимости. При удалении большого количества записей лучше тут же их прочитать, из той процедуры которая удаляла, но в новой транзакции. Таким образом замедление будет у того кто удалял а не у следующего, типа "необъяснимое торможение".
Так что совершенно не факт что " отдельный undo log лучше ".
Для Linux, видимо, должна быть несколько иная строка.
В отличие от косилки управляемой человеком-оператором, робот может работать в нонстопе круглосуточно, прерываясь только на зарядку. За счет частого кошения скошенная часть очень мелкая и ее буквально не видно. Это даже не мульча а еще мельче. Она падает на грунт между травинок и очень быстро уходит в грунт, перегнивая.
Робот-косилка - это не скосить бурьян, это поддерживать в заданном состоянии газон, подготовленный для робота заранее. Высокую траву он не возьмет. Поэтому робот-косилка - это не вместо обычной косилки, а в дополнение к обычной. Иначе вы не сможете эксплуатировать робот в случае каких-то эксцессов. Ну и обычно не 100% площади покрыто роботом, остаются участки которые для робота подготавливать неэффективно (далеко кабель тянуть, препятствия, трава растет за забором за пределами вашего участка и выпускать туда робота опасно), поэтому всегда есть работа и для обычной косилки, но конечно в гораздо меньшем объеме.
Про робота-газонокосилку написана полная фигня, не имеющая отношение к жизни роботов :)
Роботам по самой идее автономной работы не нужен бункер для сбора травы. И никакого сена после робота не остается, и даже если постараться - после робота ничего граблями не соберешь.
Роботы бывают с разным принципом управления - через заложенный в землю/траву кабель, лограничивающий периметр и задающий зоны, или сейчас уже появились в продаже роботы которые умеют работать без кабеля, ориентируясь по датчику координат относительно базовой станции-излучателя.
Роботы бывают расчитаны на разную площадь кошения, и это существенно влияет на их цену.
Роботам дождь по барабану, могут косить и в дождь, просто это может создать проблемы как газону так и роботу (налипнет мокрая мульча на пузо, поотребуется чистка), поэтому на многих роботах стоит датчик дождя, и они в дождь не косят, если это не отключено в настройках.
Роботы бывают с управлением через сеть/интернет, или автономные. Автономные дешевле, но отсутствие информации о том чего там с роботом происходит, может быть критично. Например, в период интенсивного роста травы он заехал в ямку и застрял. Вы приезжаете через неделю - а весь участок уже зарос травой, которую робот уже не возьмет, нужно предварительно готовить участок обычной косилкой, плюс робот разрядился в ноль, плюс в нем завелись муравьи, через него проросла трава и т.п. Лучше знать про такую фигню вовремя, приехать и вытащить робота из ямки, отнести на базу на зарядку.
У Алексея Надежина весьма информативные обзоры про роботы-газонокосилки.
Лучшая защита от пыли - не пускать пыль внутрь, и не собирать ее. Засовываем комп в металлический ящик. Комп работает внутри, гоняет воздух внутри ящика, не получая притока пыли извне. Ящик сколько-то греется, отдавая тепло через поверхность. Если внутри не сильно греющееся устройство - то тепловой баланс сохраняется, комп не перегревается, пыли вообще не видит. Не нужно никаких фильтров и борьбы с пылью, за ее отсутствием.
БП ноута можно или оставить снаружи т.к. он пыли не боится, либо прикрутить к металлическому ящику изнутри или снаружи, что бы улучшить охлаждение. Если штатный БП совсем мелкий, расчитанный на втыкание прям в розетку, то можно купить универсальный, побольше мощностью, что бы меньше грелся.
Мне кажется что при сравнении не учтено что у PostgreSQL есть еще журнал транзакций который хранится вне базы, и растет при работе с базой, что вызывает необходимость его потом как-то урезать. У Firebird отдельного журнала нет, эта инфа пишется в самой базе.
Опечатка: " В завяленные сроки ".
У draw.io есть и офлайн-версия, можно поставить приложение себе на комп.
Про экономию 200т.р. написано прямо в заголовке. Люди читают статью и не могут найти откуда такая экономия вообще получается.
Мне статья понравилась, но для того что бы понять про что она, потребовалось прочитать 2-3 раза. Сама задача выглядит странной, но интересно было посмотреть пример применения HomeAssistant и умных девайсов. Обычно примеры сильно притянуты за уши, а в данном случае получилось просто (с учетом что HA уже был) и эффективно (заменили одну лампочку на умную, сделали скрипты-настройки в HA).
Сейчас дофига машин где у АКПП есть ручной режим, а переключать передачи можно подрулевыми лепестками.
Но есть момент. Передач сейчас 7-9 и переключать их вручную задалбывает через несколько секунд. И при этом добиться плавности движения, как при автоматическим переключении передач, физически невозможно.
Мне смутно помнится, что когда Дуров первый раз хотел запустить свою валюту TON, то в США были сильно и продуктивно недовольны, и Дуров от TON отказался.
И вот, вроде бы недавно этот TON таки запустили в работу. Возможно с этим и связаны претензии - валюты-конкуренты никому не нужны.