На самом деле самый большая ошибка производителей — попытка впарить этот SMR по тихому. Написали бы об этом явно, как это было с Advanced Format (4K секторами), проблем было бы меньше.
Ответ тут очень простой… Нормальные серверные диски умеют FUA, а обычные 'домашние' — нет. Из-за этого fsync на домашних дисках дорогой (эмулируется обычным cache flush)
Да просто нет открытого сервиса пробок… Тут сложно что-то придуматью
Чисто теоретически можно изобрести OsmAnd-only облако, собирающее данные среди пользователей, но не думаю что это будет достаточно точно.
OsmAnd-у бы пробки научиться подгружать и использовать при прокладке маршрутов… Но ту всё просто упирается в то, что никто прсто так данными делиться не будет...
Наоборот. 'Консольные' клиенты выведут листинг как есть (грубо говоря аналог ls -l). А GUI-ным нужно это как-то парсить, чтобы красиво показать. Понятно что под 'популярные' серверы парсеры уже написаны.
Это не так. Клиенты FTP совместимы до тех пор пока не ушли далеко от telnet-а. Как только к ним пытаются прикрутить какой-то UI, сразу появляются проблемы. Самая большая из них — в FTP никогда не было стандартизированной возможности получить список файлов с атрибутами (размер, права и т.д.). Точнее команда то есть, но её вывод не стандартизирован, так как предполагалось, что будет читаться человеком.
В 'современном' FTP это починено, только MLST умеют не все серверы и не все клиенты… Такой себе 'все друг с другом совместимы' честно говоря.
Так а смысл этот файл генерировать если он не в проекте? Он как минимум через #include используется. Это воспроизводится на том же примере с CPP-17487.
Спасибо. Да. Получается что если сначала собрать всё (чтобы эти ui_ файлы появились), и потом перезагруить CMake проект (Tools -> CMake -> Reload CMake project), то таки со второго раза начинает находить. Но при этом если в такой файл перейти, то сверху в плашечке отображает "This file doesn't belong to any project target, code insight features might not work properly".
А вот с Clang интересно. У меня такое ощущение что из-за Clang тормозов только добавляется. Такое ощущение что IDE много где синхронно ждет чего-то от clangd и из-за этого зависает. C тем же включеным ClangFormat много где даже текст нормально вводить нельзя. Вот, например, в CPP-16887 я специально видео записал...
Сейчас у меня вообще выключен "Use navigation via clangd".
C Qt-ными проектами сейчас грустновато немного. У меня CLion банально не может найти autogenerated файлы (типа uic_XXX.h). CPP-17487
На сравнительно небольших проектах/халтурках всё таки летает.
Но с чем-то тяжелым IDE таки начинает резко тормозить. По моим ощущениями тормоза пропорциональны количеству GTest-based кода. В моём случае это частично решилось хоткеем на 'killall clangd'… И частичным переключением в vim :)
Конкретно в этом случае спасает.
Поясняю: сейчас банальная подмена DNS для files.viva64.com или перехват траффика позволяет засунуть в apt keyring жертвы сгенерированый злоумышлеником ключ. Ну и дальше можно делать что хочешь, например предложить обновить любой пакет в системе, просто подписав левый репозиторий этим ключем.
Если бы тут был https, то эта атака загнулась бы еще на скачивании ключа. Понятно что владельцы files.viva64.com могут подсунуть левый пакет, но это заметно лучше чем когда это делает вообще кто попало.
Мне как-то тяжело придумать сферу применения этой штуке. Данных почти всегда больше чем чем системы. Гораздо проще взять упомятнутые уже в комментах restic/borg и бэкапить ими.
Если смотреть на 'околодомашнее' использование, то первое что приходит в голову — фото/видео и прочий тяжелый и плохосжимающийся уникальный контент, который заведомо невозможно найти на snapshot.debian.org.
Если рассматривать вариант контейнеров и не разводить зоопарка дистрибутивов, то по сути всё равно бинари и прочий /usr будет забэкаплен один раз. И с увеличением количества данных, доля установленной системы (5, 10, ну пусть даже 20GB) будет уменьшаться. Зато все данных для восстановления под контролем и доступны локально когда это нужно.
А даже если и поставить цель развести зоопарк дистрибутивов, то в случае debian это будет целых полтора релиза (stable и oldstable), а для остальных про аналог snapshot.debian.org hashget ничего не знает.
Зависимость же от сторонних сервисов вроде http://snapshot.debian.org в эпоху копирастов и прочих DMCA это скорее минус чем плюс… Даже беглого просмотра багтрекера для snapshot.debian.org достаточно, чтобы понять что это ни разу не вечный архив. Пакеты оттуда тоже удаляют: #737359, #610303, #779822, #581157. Плюс возможные проблемы с доступом как раз когда нужно будет восстановиться...
PPS. В случае с debian был еще раньше 'дедовский' способ в виде --exclude=/usr и дальше манипуляций с dselectи dpkg --unpack при восстановлении.
Бэкап может быть меньше исходника и без сжатия, если много дублирующихся блоков.
Я когда-то (около года назад) сравнивал borg со сзжатием и restic без… Разница на ~1.5TB данных была около 5-10% у меня. Просто из-за того что большая часть данных — фото/видео.
100% что не будет. Это ж попробуй их туда вместить.
Будет скорее всего как на Nokia N900 или Blackberry 10: по две кнопки и вторая вводится двойным нажатием..
Поздно уже про пользовательский опыт думать. Уже можно в любой ноутбук с Type-С пытаться вставить зарядку от первого попавшегося телефона.
На самом деле самый большая ошибка производителей — попытка впарить этот SMR по тихому. Написали бы об этом явно, как это было с Advanced Format (4K секторами), проблем было бы меньше.
Ответ тут очень простой… Нормальные серверные диски умеют FUA, а обычные 'домашние' — нет. Из-за этого fsync на домашних дисках дорогой (эмулируется обычным cache flush)
Через пару месяцев обновлений эти виртуалки разьедутся очень сильно…
Да просто нет открытого сервиса пробок… Тут сложно что-то придуматью
Чисто теоретически можно изобрести OsmAnd-only облако, собирающее данные среди пользователей, но не думаю что это будет достаточно точно.
OsmAnd-у бы пробки научиться подгружать и использовать при прокладке маршрутов… Но ту всё просто упирается в то, что никто прсто так данными делиться не будет...
Наоборот. 'Консольные' клиенты выведут листинг как есть (грубо говоря аналог
ls -l). А GUI-ным нужно это как-то парсить, чтобы красиво показать. Понятно что под 'популярные' серверы парсеры уже написаны.Вот как это выглядит в жизни:
https://github.com/curl/curl/blob/master/lib/ftplistparser.c
Я не могу это называть "стандартизированно". FTP давно уже пора похоронить и забыть как страшный сон.
Это не так. Клиенты FTP совместимы до тех пор пока не ушли далеко от telnet-а. Как только к ним пытаются прикрутить какой-то UI, сразу появляются проблемы. Самая большая из них — в FTP никогда не было стандартизированной возможности получить список файлов с атрибутами (размер, права и т.д.). Точнее команда то есть, но её вывод не стандартизирован, так как предполагалось, что будет читаться человеком.
В 'современном' FTP это починено, только MLST умеют не все серверы и не все клиенты… Такой себе 'все друг с другом совместимы' честно говоря.
Так а смысл этот файл генерировать если он не в проекте? Он как минимум через #include используется. Это воспроизводится на том же примере с CPP-17487.
Спасибо. Да. Получается что если сначала собрать всё (чтобы эти ui_ файлы появились), и потом перезагруить CMake проект (Tools -> CMake -> Reload CMake project), то таки со второго раза начинает находить. Но при этом если в такой файл перейти, то сверху в плашечке отображает "This file doesn't belong to any project target, code insight features might not work properly".
А вот с Clang интересно. У меня такое ощущение что из-за Clang тормозов только добавляется. Такое ощущение что IDE много где синхронно ждет чего-то от clangd и из-за этого зависает. C тем же включеным ClangFormat много где даже текст нормально вводить нельзя. Вот, например, в CPP-16887 я специально видео записал...
Сейчас у меня вообще выключен "Use navigation via clangd".
Зря кстати. Тех поддержка вполне себе ОК.
C Qt-ными проектами сейчас грустновато немного. У меня CLion банально не может найти autogenerated файлы (типа uic_XXX.h). CPP-17487
На сравнительно небольших проектах/халтурках всё таки летает.
Но с чем-то тяжелым IDE таки начинает резко тормозить. По моим ощущениями тормоза пропорциональны количеству GTest-based кода. В моём случае это частично решилось хоткеем на 'killall clangd'… И частичным переключением в vim :)
Как вариант, топливо 'сливать' на казеном авто.
У меня тоже на некоторых файлах тормоза такие что проще в vim редактировать:
https://youtrack.jetbrains.com/issue/CPP-16887
Это почти везде так… Thinkpad-ы тоже многие WWAN upgradable. Считается что модем можно докупить позже.
Конкретно в этом случае спасает.
Поясняю: сейчас банальная подмена DNS для files.viva64.com или перехват траффика позволяет засунуть в apt keyring жертвы сгенерированый злоумышлеником ключ. Ну и дальше можно делать что хочешь, например предложить обновить любой пакет в системе, просто подписав левый репозиторий этим ключем.
Если бы тут был https, то эта атака загнулась бы еще на скачивании ключа. Понятно что владельцы files.viva64.com могут подсунуть левый пакет, но это заметно лучше чем когда это делает вообще кто попало.
Здравствуй MITM… Вы бы хоть https какой-то прикрутили, если уж такое советуете...
Я про такую возможнсть не знаю… Возможно rclone умеет (restic может использовать rclone в качестве бэкенда).
Мне как-то тяжело придумать сферу применения этой штуке. Данных почти всегда больше чем чем системы. Гораздо проще взять упомятнутые уже в комментах restic/borg и бэкапить ими.
Если смотреть на 'околодомашнее' использование, то первое что приходит в голову — фото/видео и прочий тяжелый и плохосжимающийся уникальный контент, который заведомо невозможно найти на snapshot.debian.org.
Если рассматривать вариант контейнеров и не разводить зоопарка дистрибутивов, то по сути всё равно бинари и прочий /usr будет забэкаплен один раз. И с увеличением количества данных, доля установленной системы (5, 10, ну пусть даже 20GB) будет уменьшаться. Зато все данных для восстановления под контролем и доступны локально когда это нужно.
А даже если и поставить цель развести зоопарк дистрибутивов, то в случае debian это будет целых полтора релиза (stable и oldstable), а для остальных про аналог snapshot.debian.org hashget ничего не знает.
Зависимость же от сторонних сервисов вроде http://snapshot.debian.org в эпоху копирастов и прочих DMCA это скорее минус чем плюс… Даже беглого просмотра багтрекера для snapshot.debian.org достаточно, чтобы понять что это ни разу не вечный архив. Пакеты оттуда тоже удаляют: #737359, #610303, #779822, #581157. Плюс возможные проблемы с доступом как раз когда нужно будет восстановиться...
PPS. В случае с debian был еще раньше 'дедовский' способ в виде
--exclude=/usrи дальше манипуляций сdselectиdpkg --unpackпри восстановлении.Бэкап может быть меньше исходника и без сжатия, если много дублирующихся блоков.
Я когда-то (около года назад) сравнивал borg со сзжатием и restic без… Разница на ~1.5TB данных была около 5-10% у меня. Просто из-за того что большая часть данных — фото/видео.