«Идеальная концентрация йогов» доступна каждому после тренировки. Кому-то больше придётся учиться, кому-то меньше. Но на пользу уму пойдёт, однозначно.
В Debian там в конфиге по дефолту стоит 1 строка DEVICESCAN …, поэтому имеет смысл завести баг в smartmontools на тему DEVICESCAN, т.к. smartd сканирует nvme по аналогии с /dev/sd[a-z]\d+, а надо бы ему игнорировать символьные устройства и брать /dev/nvme\d+n\d+.
В Европе много где подобных штук. Например, в Гамбурге поезд до аэропорта в какой-то момент расцепляется пополам и разъезжается в разные направления. Ещё, насколько знаю, в Бельгии такое практикуется (но сам лично не видел).
В Амстердаме тоже каждая платформа на центральном вокзале кроме номера имеет буквы «A» и «B» — два поезда могут на одних путях стоять.
Серьёзно. Например, брелок постоянно держит канал связи с машиной и проверяет его уровень. Если он резко изменился, то это может говорить о появлении ретранслятора. Либо, если имеется одновременно два источника сигнала (машина и ретранслятор), то это, думаю, тоже можно определить.
Это может быть, например, решено сменой частоты в процессе общения ключа и машины на заданную. Ретранслятор не успеет понять, куда ему передавать. Это то, что пришло в голову за пол-минуты, пока писал комментарий :)
Потому что каждый пакет данных переданный ключём или машиной будет годен только 1 раз. Как это делается? Ну как в TLS сейчас.
А передавать свои пакеты вместо ключа невозможно, т.к. каждый пакет данных подписывается цифровой подписью. Неправильная подпись — пакет отбрасывается.
Т.е. если нет физического доступа к ключу, то любой перехват и ретрансляция данных не будут иметь смысла.
Если сделать двусторонний канал с брелком (ну, например, LoRa или, хотя бы, bluetooth), использовать современные криптографические протоколы, то ретранслировать просто смысла никакого не будет.
Получается, то, что в интернете было придумано много лет назад, до сих пор в автомобилях нет? Сделать двусторонний канал между брелком и машиной, зашифровать, timestamp'ы ставить в пакеты — элементарные решения же.
но я не могу попросить Splotlight найти все книги по программированию мобильных приложений если не пропишу руками теги
Скорее всего, не было запроса к разработчикам ПО. Т.е. такие требования уже похожи на продвинутого пользователя, которых очень мало. А разработчики ориентируются на неквалифицированные массы.
Так-то можно было бы и нейросети подключить, чтобы они смотрели внутрь PDF/DJVU и, если там нет распознанного текста, пытались бы по сканам определить тематику.
Вопрос в том, кто это всё напишет.
инфраструктура для индексации есть, софт есть, даже тормоза есть
Ну и хочется, чтобы не было тормозов. Наверняка это можно оптимизировать.
Например, в Linux (и других UNIX'ах) никогда расширение файла не имело особого значения, зато есть команда file, которая по содержимому определяет типа и формат файла (JPEG/PNG/PDF/text/markdown/… определяет десятки разных) — вот уже первая классификация готова.
Ставить тег может сама ОС при создании файла. Либо libc.
Или как вы организуете эффективное использование дискового пространства
Никаких проблем не вижу. Начиная с того, что уже сейчас в файловых системах есть хардлинки (даже в NTFS) и расширенные аттрибуты. Если взять за основу идеи ZFS, то там уже все абстракции есть для реализации. Ну понятно, что придётся переписывать с нуля, т.к. у ZFS лицензия кривая.
запуск старого ПО, заточенного под древовидную, на новой
Например, когда к одному файлу ведёт несколько разных путей, типа:
/tags/:image/:png/:all/my_summer_2056.jpg
/tags/:image/:png/:2056/my_summer_2056.jpg
/tags/:image/:png/:(img.height > 1000)/my_summer_2056.jpg
/tags/:image/:(img.tone like blue)/my_summer_2056.jpg
/tags/:family/my_summer_2056.jpg
т.е. я сейчас «от балды» придумал какой-то язык запросов, который можно в виде древовидной структуры каталогов показывать. Можно даже какие-то частые запросы сохранять и они будут в каталоге /tags видны как подкаталоги.
Думаю, уже до меня такие штуки придуманы. Просто они, скорее всего, реализуются либо через 100500 симлинков, либо через FUSE (файловая система на user level), всё это громоздко и медленно.
Работодатель должен понимать, что «работать больше» и «платить меньше» никак не связано с качеством работы. Не бывает такой экономии бесплатно. Не смогут 2 джуна заменить сеньора. А 3-4 джуна — тем более (см. Брукса) не смогут.
прямо вот повсеместно являются основными критериями
А, ну есть ещё другой перекос — хотят «крутого», так сильно, что всех крутых на собеседовании отсеивают.
Но сейчас повсеместно на рынке ищут не толковых, а «под agile» (который, как мы уже выяснили, не является тем изначальным Agile). Т.е. молодёжь, которой можно платить меньше рынка, не доплачивать за переработки.
все эти люди выбирают такую позицию добровольно
Возможно, потому что в индустрию рванулось слишком много толпы? В Индии вон, за тарелку риса код пишут :) Весь upwork стонал одно время.
А тибетский язык, к примеру, похож на обратную польскую запись (постфиксную).
Машинисты проходят медосмотр, поэтому больных и с аллергией не допустят.
С другой стороны, умея концентрировать ум, можно и чихание подавить.
«Идеальная концентрация йогов» доступна каждому после тренировки. Кому-то больше придётся учиться, кому-то меньше. Но на пользу уму пойдёт, однозначно.
В командной строке теги работают?
nvme0/nvme1/… — это символьные устройства, почему они вообще отдают какую-то инфу smartmontools'у — вот это вопрос. Туда имеет смысл копать, по-моему.
Не надо устройства переименовывать. Там всё уже правильно названо.
Вот что надо сделать со
smartd.conf:Исправить по вкусу.
В Debian там в конфиге по дефолту стоит 1 строка
DEVICESCAN …, поэтому имеет смысл завести баг в smartmontools на тему DEVICESCAN, т.к. smartd сканирует nvme по аналогии с/dev/sd[a-z]\d+, а надо бы ему игнорировать символьные устройства и брать/dev/nvme\d+n\d+.Они ему вообще-то не нужны.
Мониторит smartd, ему в конфиг впишите имена дисков, которые надо мониторить явно.
Вообще, косяк smartctl лишь в том, что ему надо тут падать с ошибкой:
А вот тут всё хорошо:
А smartd должен просто игнорировать "/dev/nvme\d+".
В Европе много где подобных штук. Например, в Гамбурге поезд до аэропорта в какой-то момент расцепляется пополам и разъезжается в разные направления. Ещё, насколько знаю, в Бельгии такое практикуется (но сам лично не видел).
В Амстердаме тоже каждая платформа на центральном вокзале кроме номера имеет буквы «A» и «B» — два поезда могут на одних путях стоять.
Серьёзно. Например, брелок постоянно держит канал связи с машиной и проверяет его уровень. Если он резко изменился, то это может говорить о появлении ретранслятора. Либо, если имеется одновременно два источника сигнала (машина и ретранслятор), то это, думаю, тоже можно определить.
Это может быть, например, решено сменой частоты в процессе общения ключа и машины на заданную. Ретранслятор не успеет понять, куда ему передавать. Это то, что пришло в голову за пол-минуты, пока писал комментарий :)
Это устройство работает только потому, что автопроизводители не сделали нормальный протокол взаимодействия ключ←→машина.
Потому что каждый пакет данных переданный ключём или машиной будет годен только 1 раз. Как это делается? Ну как в TLS сейчас.
А передавать свои пакеты вместо ключа невозможно, т.к. каждый пакет данных подписывается цифровой подписью. Неправильная подпись — пакет отбрасывается.
Т.е. если нет физического доступа к ключу, то любой перехват и ретрансляция данных не будут иметь смысла.
Потому что криво by design.
Если сделать двусторонний канал с брелком (ну, например, LoRa или, хотя бы, bluetooth), использовать современные криптографические протоколы, то ретранслировать просто смысла никакого не будет.
Получается, то, что в интернете было придумано много лет назад, до сих пор в автомобилях нет? Сделать двусторонний канал между брелком и машиной, зашифровать, timestamp'ы ставить в пакеты — элементарные решения же.
Где именно камеры ставят? Они говорят об этом гостю?
Всегда так делаю.
Скорее всего, не было запроса к разработчикам ПО. Т.е. такие требования уже похожи на продвинутого пользователя, которых очень мало. А разработчики ориентируются на неквалифицированные массы.
Так-то можно было бы и нейросети подключить, чтобы они смотрели внутрь PDF/DJVU и, если там нет распознанного текста, пытались бы по сканам определить тематику.
Вопрос в том, кто это всё напишет.
Ну и хочется, чтобы не было тормозов. Наверняка это можно оптимизировать.
Это можно параллельно держать.
Например, для системных файлов и конфигов — дерево. Для личных файлов — дерево+теги.
Например, в Linux (и других UNIX'ах) никогда расширение файла не имело особого значения, зато есть команда
file, которая по содержимому определяет типа и формат файла (JPEG/PNG/PDF/text/markdown/… определяет десятки разных) — вот уже первая классификация готова.Ставить тег может сама ОС при создании файла. Либо libc.
Никаких проблем не вижу. Начиная с того, что уже сейчас в файловых системах есть хардлинки (даже в NTFS) и расширенные аттрибуты. Если взять за основу идеи ZFS, то там уже все абстракции есть для реализации. Ну понятно, что придётся переписывать с нуля, т.к. у ZFS лицензия кривая.
Например, когда к одному файлу ведёт несколько разных путей, типа:
т.е. я сейчас «от балды» придумал какой-то язык запросов, который можно в виде древовидной структуры каталогов показывать. Можно даже какие-то частые запросы сохранять и они будут в каталоге
/tagsвидны как подкаталоги.Думаю, уже до меня такие штуки придуманы. Просто они, скорее всего, реализуются либо через 100500 симлинков, либо через FUSE (файловая система на user level), всё это громоздко и медленно.
Было бы круто «из коробки» такое иметь.
Работодатель должен понимать, что «работать больше» и «платить меньше» никак не связано с качеством работы. Не бывает такой экономии бесплатно. Не смогут 2 джуна заменить сеньора. А 3-4 джуна — тем более (см. Брукса) не смогут.
А, ну есть ещё другой перекос — хотят «крутого», так сильно, что всех крутых на собеседовании отсеивают.
Но сейчас повсеместно на рынке ищут не толковых, а «под agile» (который, как мы уже выяснили, не является тем изначальным Agile). Т.е. молодёжь, которой можно платить меньше рынка, не доплачивать за переработки.
Возможно, потому что в индустрию рванулось слишком много толпы? В Индии вон, за тарелку риса код пишут :) Весь upwork стонал одно время.