Помню, как в 2013м летел в Турцию на самолёте и разводил на андроид планшете (4й андроид, кажется) платы в kicad под дебиан. И всё это прекрасно работало. Странно, что кого-то до сих пор удивляют такие вещи. Клавиатура - да, проблема. Нормальных компактных складных не находил. О подобных очках мечтаю давно, но всё ещё считал, что подходящих нет, ибо микродвижения головы сильно мешают стабильности позиционирования изображения перед глазами. Это, конечно, зависит от софта и концепции. Если движение головы не приводит к перемещению экрана - можно и попробовать. Опасение только одно - что нет статистики по долгосрочному использованию и влиянию на состояние зрения.
Насчёт ключей - я в этой индустрии работаю, в том числе взаимодействовал и с домилендом и с самолётом. Любые способы открытия точек прохода кроме RFID являются именно дополнительными, а не основными. Т.е. жилец обязан иметь при себе RFID пропуск, но если ему так удобнее/быстрее/комфортнее - может открывать дверь хоть с помощью мобильного устройства, хоть каким-либо иным способом. Раньше была возможность прохода на основании распознавания лиц, но для того, чтобы процессить биометрию, нужен уставной капитал в 500 млн.р., если не ошибаюсь, поэтому многие компании сейчас стараются обходить работу с биометрией за километр. Открывать дверь "через бекенд", (если имеется в виду отправка идентификатора карты на бекенд и принятие решения об открытии на стороне бекенда) в большинстве случаев просто не получится - домофонная панель как и скуд контроллеры имеет на борту список доверенных ключей доступа и не ходит за ними на бек, а также большинство панелей не отправляют коллбеков о событиях прохода). Но метод API для открытия двери у большинства панелей есть и нет проблем сделать кнопку в приложении "Открыть дверь", что и реализовано.
Я больше 15 лет пользуюсь vim'ом и это накладывает свой отпечаток. Можно считать, что это что-то вроде профдеформации и это удобно для меня и других пользователей вим. Впрочем, навигация с помощью обычных курсорных клавиш и pgup/pgdwn/home/end тоже работает, так что поддержка вим хоткеев скорее опция или бонус.
Я просто наблюдал в момент подгрузки логов за тем, как уменьшалась оперативная память и размеры сравнимы. Других объяснений у меня нет. Насчёт "с диска не намного медленнее" - не проверял, утверждать не буду, но есть сомнения, что выборка из sqlite базы с таблицей в 20гб, скажем, пусть даже с ssd или sas диска займёт сравнимое время, что и из оперативной памяти.
Тем, что решили вы переключить сервис в дебаг, а дебага там столько и он настолько ситуативный, что жалко этим нагружать ELK. Другой сценарий - контейнер, бегущий локально на машине разработчика. Для него поднимать елк или аналог - бессмысленно, как и подключать его локальный контур к центральному елк, а пару - тройку гигабайт дебаг лога проанализировать надо. Либо, как третий вариант - это может быть вообще пет проект.
Да, разработчики заявляют именно так и понятно, почему. На их месте я бы поступал также. Но де-факто применение awk преимущественно утилитарное. Нигде не видел, чтобы его использовали именно как интерпретатор ЯП в полном смысле этого слова. Скорее как аналог excel для cli.
Помню, как в 2013м летел в Турцию на самолёте и разводил на андроид планшете (4й андроид, кажется) платы в kicad под дебиан. И всё это прекрасно работало. Странно, что кого-то до сих пор удивляют такие вещи. Клавиатура - да, проблема. Нормальных компактных складных не находил. О подобных очках мечтаю давно, но всё ещё считал, что подходящих нет, ибо микродвижения головы сильно мешают стабильности позиционирования изображения перед глазами. Это, конечно, зависит от софта и концепции. Если движение головы не приводит к перемещению экрана - можно и попробовать. Опасение только одно - что нет статистики по долгосрочному использованию и влиянию на состояние зрения.
Насчёт ключей - я в этой индустрии работаю, в том числе взаимодействовал и с домилендом и с самолётом. Любые способы открытия точек прохода кроме RFID являются именно дополнительными, а не основными. Т.е. жилец обязан иметь при себе RFID пропуск, но если ему так удобнее/быстрее/комфортнее - может открывать дверь хоть с помощью мобильного устройства, хоть каким-либо иным способом. Раньше была возможность прохода на основании распознавания лиц, но для того, чтобы процессить биометрию, нужен уставной капитал в 500 млн.р., если не ошибаюсь, поэтому многие компании сейчас стараются обходить работу с биометрией за километр. Открывать дверь "через бекенд", (если имеется в виду отправка идентификатора карты на бекенд и принятие решения об открытии на стороне бекенда) в большинстве случаев просто не получится - домофонная панель как и скуд контроллеры имеет на борту список доверенных ключей доступа и не ходит за ними на бек, а также большинство панелей не отправляют коллбеков о событиях прохода). Но метод API для открытия двери у большинства панелей есть и нет проблем сделать кнопку в приложении "Открыть дверь", что и реализовано.
Наверное так. :)
Для этого можно вырезать нужный кусок пайпом с помощью других утилит и перенаправить выход на lnav.
Файла самого лога? Возможно, но скорее tmpfs, если файл продолжает дописываться в процессе анализа.
Всё так. С jl не сталкивался, но посмотрю, спасибо!
Я больше 15 лет пользуюсь vim'ом и это накладывает свой отпечаток. Можно считать, что это что-то вроде профдеформации и это удобно для меня и других пользователей вим. Впрочем, навигация с помощью обычных курсорных клавиш и pgup/pgdwn/home/end тоже работает, так что поддержка вим хоткеев скорее опция или бонус.
Я просто наблюдал в момент подгрузки логов за тем, как уменьшалась оперативная память и размеры сравнимы. Других объяснений у меня нет. Насчёт "с диска не намного медленнее" - не проверял, утверждать не буду, но есть сомнения, что выборка из sqlite базы с таблицей в 20гб, скажем, пусть даже с ssd или sas диска займёт сравнимое время, что и из оперативной памяти.
За наводку на goaccess - спасибо, изучу. Я вообще очень люблю tui ещё со времён расцвета fido и bbs. :)
Тем, что решили вы переключить сервис в дебаг, а дебага там столько и он настолько ситуативный, что жалко этим нагружать ELK. Другой сценарий - контейнер, бегущий локально на машине разработчика. Для него поднимать елк или аналог - бессмысленно, как и подключать его локальный контур к центральному елк, а пару - тройку гигабайт дебаг лога проанализировать надо. Либо, как третий вариант - это может быть вообще пет проект.
Да, разработчики заявляют именно так и понятно, почему. На их месте я бы поступал также. Но де-факто применение awk преимущественно утилитарное. Нигде не видел, чтобы его использовали именно как интерпретатор ЯП в полном смысле этого слова. Скорее как аналог excel для cli.