Category: it

Category was added automatically. Read all entries about "it".

moth

Программисты - не боги?

Мне знакомый сказал, что программисты - не боги. Это прям обидно, потому что с подразумеваемым квантором "всегда" это неверно. Программисты не боги всего лишь половину времени. В подтверждение - старый тырнетный мемчик:

states-of-a-programmer
moth

Компьютерное - Windows, Bitlocker NAS и не только

Я бы мог написать красивую захватывающую историю в формате приключений, но, к сожалению, на неё нет времени, а чисто информативно хочется зафиксировать, что произошло. Поэтому кратко, фактуально, тезисно, начну с источника проблем, а также с выводов, которые я для себя сделал.

Windows Storage Spaces плохо работают с битлокером - если битлокер в режиме расшифровки на Storage Spaces mirror-партиции, и в этот момент перезагрузиться, то все полимеры будут просраны (не поможет ни repair-bde, ни другое волшебство). Я не знаю, насколько хорошо это воспроизводится, но по разным косвенным данным, похоже, тут именно сочетание Storage Spaces и битлокера.

Выводы, которые я для себя сделал:

*) Не использовать Storage Spaces. Лучше Windows Dynamic Disk Mirror. Ещё лучше Mirror в виде cron job (Scheduled Task), запускающий rsync-like tool (robocopy, например, или rar), который будет регулярно достраивать копию на втором диске.

*) Надо защищаться от багов в алгоритмах шифрования. Например, если на одном диске битлокер, на mirror-копии пусть будет rar под паролем или VeraCrypt image, или ещё что-нибудь. Желательно даже, чтобы сам алгортим шифрования был иным.

*) Даже если файлы не очень важны (например, их можно всегда скачать заново), надо архивировать метаданные - список названий файлов. Чтобы заново скачать, надо помнить, что интересного и ценного у тебя было, а ты не помнишь -> вот это настоящая потеря.

Эта уязвимость стала проблемой благодаря другим проблемам, которые наложились:

Windows сходит с ума, когда у тебя много дисков - это проявляется:
- в невозможности поставить крупные апдейты, требующие изменений в коде загрузчика (например, заапгрейдиться с Windows 10 версии 1909 на версию 20H2, как было у меня - см. https://en.wikipedia.org/wiki/Windows_10_version_history про крупные апдейты, это, по сути, как новые версии операционки, устанавливаемые незаметно, под тем же брендом Windows 10), в том числе в невозможности поставить такой апдейт вручную, без каких-то разумных сообщений в логе,
- в невозможности выполнить Startup Repair, загрузившись с флешки,
- в невозможности выполнить установку новой винды на соседнюю партицию, загрузившись с флешки.

Есть сильное подозрение, что в деле замешаны RAID-драйвера, так что их точно надо отключить и не использовать built-in AMD RAID (кстати, про RAID-драйвера отдельная история - из-за них у меня крешается Veritas System Recovery, которую я использую для бэкапов системного диска, она крешается при enumeration других дисков уже после бэкапа; а ещё иногда крешалась винда при первом доступее к одному из дисков после sleep/reboot, например, когда когда rar-архив начинаешь создавать на бэкапный диск... одновременно с крешами Veritas AMD RAIDXpert2 ругался на диски, поэтому я грешу на RAID, но перевод дисков в режим non-RAID делу не помог, а драйвера так просто не снесёшь, надо переустанавливать винду).

Я так и не понял, нужно ли вытаскивать другие NVME диски (но на всякий случай, я вытаскиваю, благо, я заблаговременно позаботился, чтобы только системный NVME был труднодоступен, а два других легко вытаскивались), но совершенно точно надо вытащить хотя бы один из SATA дисков. Для надёжности я вытаскивал все.

Windows 10 время от времени ставит крупные апдейты, похожие на установку новой винды - т.е. требующие несколько перезагрузок и каких-то изменений в коде загрузчика. Зная, что могут быть проблемы и что винда может сломаться, осторожный человек, конечно же, отключит битлокер на системном диске и сделает image-бэкап. Когда я это сделал, у меня тут же начали дешифроваться все остальные диски, хоть я их об этом и не просил (они были в режиме auto-unlock, может, из-за этого?). Наверное, в следующий раз надо auto-unlock заранее отключать, чтобы предотвратить этот процесс. Конечно же, процесс дешифровки всего, очень долгий (может быть сутка для 12 TB) и это прямо рецепт для катастрофы, когда все диски одновременно почти полностью загружены, а ты при этом пытаешься использовать компьютер.

Во время всех сопутствующих этим проблемам и попыткам их решения танцев с бубном, были сделаны следующие выводы:

* EaseUS Todo Backup полное говно. У них красивый интерфейс и функционал создания бэкапов, но глючный, сырой, недоделанный и неработающий интерфейс для восстановления - мне не удалось с помощью него восстановить партицию, пришлось брать запасной бэкап от Veritas. (Благо, я на всякий случай, перед ответственной процедурой сделал бэкап двумя программами, так как новой не очень доверял - и правильно!). Вывод: надо backup software как следует гонять на реальных тестах, особенно image backups системного диска.

* UEFI это какой-то ужас-нах, который многократно усложняет все восстановительные процедуры (разные bootable ISOs сходят с ума, если загрузиться в UEFI - как с виндой, так и с инструментами для бэкапов, управления партициями и разной полезной всячины), а Veritas ещё и делает image backup'ы несовместимыми между BIOS mode vs UEFI mode. Т.е. если ты сохранил его, когда загрузка была в UEFI режиме, то будь добр, именно в этом режиме и восстанавливай. Я полностью отключил UEFI и решил, что мне дешевле жить с ограничениями, которые он накладывает, чем с ним бороться (ограничения: загрузочный диск должен быть MBR, а не GPT, т.е. не больше 2 TB и не больше 4 примарных партиций). Блин, работал же BIOS нормально 30 лет. Кому вздумалось его менять вместо того, чтобы пройтись напильником и добавить поддержку GPT дисков? Проработал бы он ещё 30 лет. Ан нет, сделаем новую технологию, чтобы заново понаступать на все возможные грабли.

Ещё интересный learning: Винда при установке создаёт 3 партиции (маленькую для EFI, большую системную и "reserved" на полгига). "Reserved" это какой-то шлак. EFI для BIOS mode не нужен. Но так просто ты создания 3 партиций не избежишь, а в MBR у тебя их всего 4. Т.е. если ты хочешь dual-boot из двух версий винды (одна старая плюс одна новая) по 500 GB каждая, то ты уже израсходовал все 4 партиции (EFI, 2 системных и Reserved), т.е. по сути, ты второй терабайт не можешь использовать. Workaround: партицию со второй виндой через diskpart отметить как "активную", первую удалить, так же удалить EFI партицию и Reserved партицию, после чего инсталлировать новую винду в начале диска. В этом случае она лишних партиций не создаст, а проинсталлирует свой загрузчик на партицию со второй виндой (заодно починив её, если она раньше не загружалась). Инсталляция соседней винды - похоже, более надёжный способ починить загрузку, чем "Startup Repair", который не работает почти никогда.

* Желательно держать в компьютере поменьше дисков. Желательно, чтобы они все были одного типа (не мешать M.2 и SATA). Ыы.... к сожалению, эта идея очень плохо вяжется с идеей "не иметь NAS". Что ж, ждём, когда появятся M.2 диски на 8-16 TB, которые, в сочетании с Cloud Backup решат все проблемы.

* * *

Подводя итоги - за эти несколько недель потрачено много времени (на позапрошлой неделе я был дней пять без компа, по сути дела, пока пытался восстановить попорченный загрузчик).

Из реальных полезных файлов - потеряно всё, на что я махнул рукой, решив, что "если надо, скачаю снова", поэтому не придерживался высоких стандартов сохранности (3-2-1 backup rule), а просто держал два диска в Bitlocker Mirror on Storage Spaces подвергнутые перезагрузке в процессе расшифровки битлокера, и никакие попытки извлечь данные, в т.ч. разные forensic analysis tools, сканирующие посекторно, мне не помогли. При том, что у меня был ключ (который почему-то вдруг, for all practical purposes, перестал работать). Всё остальное в добром здравии.

Это первый случай за очень много лет, когда я неосторожным движением руки (под уникальным сочетанием положения планет и звёзд) лишился файлов из своей коллекции. Мне казалось, что я по молодости лет получил болезненный опыт потерь данных уже в достаточном объёме. Но нет, оказалось, нужен был new learning.
moth

Нагуглил свой же солюшен - wow!

У меня, кажется, впервые в жизни опыт, когда по нетривиальному техническому вопросу я нагуглил свой собственный солюшен на Stackoverflow.

Я купил Synology, чтобы стримить на него внешний бэкап через robocopy (детали расскажу потом, как видоизменилась топология моего storage - это отдельная история). Но robocopy упорно копирует неизменившиеся файлы, как оказалось, потому что NAS не поддерживает ChangeTime, а винда-NTFS поддерживает.

Перепробовав несколько других гугл-запросов, я ввёл: robocopy ignore change time и по третьей ссылке пришёл вот сюда:

https://social.technet.microsoft.com/Forums/windows/en-US/19cb1186-fce5-415a-b520-923c26dc57b2/robocopy-can-not-ignore-timestamps?forum=winservergen

Нижний комментарий к этой статье показался мне каким-то особенно близким и понятным, как будто писала родственная мне душа (забегая вперёд - это я писал, и это мой комментарий :))

По ссылке я попал на Stackoverflow:

https://stackoverflow.com/questions/27534448/how-do-i-get-change-file-time-in-windows

С каким-то странным чувством дежа-вю и поводу поста, и по поводу "лучшего решения" :)

Потом я ушёл с этой страницы, вернулся на неё снова, и заметил, что комментарий с решением - мой. Потом заметил, что и пост - мой. А что коммент, который на него меня вывел - тоже мой! А потом я ещё поискал на диске и нашёл утилиту, которую я тогда наваял, которая делает то, что мне нужно - идёт по диску и сбрасывает ChangeTime, приравнивая его к LastWriteTime. Надо только поставить VisualStudio, чтобы её откомпилировать :)

Чудеса в решете. Наверное, у более активных стековервлоуеров такое случается часто, но у меня, вот, прям, впервые!
moth

Межсетевое

Перепощиваю шутку с другого форума.
К сожалению, смешно будет только айтишникам. Экстра поинтс, если вы сетевик.

12 лет уже этому ролику, прикиньте! Интересно, какая у него история. В смысле, мальчик специально стебался, или его кто-то подколол, чтобы вышел этот ролик с лулзами, или же он *сам до всего вот так догадался!* (если так, то вообще талантище!)

Итак, Tracer "T", dot-dot slash-slash, etc :)

"How to view someones IP address and connection speed!"



Ещё прекрасная штука, которую я обнаружил в комментах: сделайте ping eblan.us :)
moth

Освобождение от NAS и переход на клауд - 2

Я придумал концептуальную схему, которая позволит устранить основные bottlenecks - необходимость время от времени перезаливать в клауд "сразу всё" - при этом лишь с небольшим оверхедом по месту на диске.

Для системного диска всё остаётся по-старому, но его можно держать разумных пределах, 200 GB full backup + a bunch of incrementals, и время от времени будут перезаливаться 200 GB.

А вот для всего остального схема такая:

1. Реорганизовать файлы таким образом, чтобы на самом первом уровне было много директорий "разумного размера" - желательно до 10 GB, но можно больше для тех директорий, которые чаще всего я не трогаю вовсе.

2. Написать простой скрипт, который будет RAR-ом делать шифрованный архив каждого каталога. Не "solid", чтобы быстрее были обновления, когда файлы поменялись. Читать он будет с NVMe диска, а как временный архив, так и постоянный будут создаваться на дополнительном медленном диске, который синхронизирован с клаудом (временный архив будет в отдельной директории, которая не синхронизирована с клаудом). Таким образом не будет изнашиваться NVMe, записи будут редки, будет только много чтения.

Режим "обновления" (rar a -u -as) работает таким образом, что если изменений не было, то временный архив удаляется и целевой архив не перезаписывается. Т.е. лишней закачки в клауд не будет, хотя диском оно будет трещать каждый день.

RAR позволяет много разных других полезностей:
- разбивать архив на многотомный, скажем, кусками по 10 GB (чтобы вписываться в лимиты клауд провайдеров),
- сохранять дату создания и последней модификации файлов,
- сохранять recovery record - защита от bit rot,
- тестировать архив после создания или обновления.

3. Вишенка в торте - чтобы обращаться к файлам, которые открыты, например, к PST файлу Outlook'а, нужен механизм shadow copy. Оказывается есть простая утилита, которую можно тупо скопировать с серверного дистрибутива, позволяющая удобно заскриптовать временную shadow copy: https://superuser.com/questions/735559/zip-files-and-volume-shadow-copy

Будет создаваться shadow copy (snapshot), монтироваться на диск S:, после этого RAR будет архивировать уже именно оттуда, а когда RAR всё закончит, можно будет снести диск S: и более ненужную shadow copy.

* * *

Свойства этого подхода:
- супердолгой будет только первая закачка, а если файлы меняются редко, то очень крупных закачек не будет; ожидаемо - несколько 10GB архивов в день, что вполне по силам даже 100 MBit/sec upload'у,
- дополнительное место требуется только для одной копии данных, да и то, на медленном диске.
- всё запаролено,
- удобство при работе с versioning-ом от клауд провайдера, т.к. versioning даст старую версию целого архива, его можно выкачать целиком и уже локально распаковывать.
moth

Освобождение от NAS и переход на клауд

Процесс очень активен, но, к сожалению, всё значительно труднее, чем я думал.

1. Консьюмерские клауд-storage-провайдеры не справляются с большим количеством маленьких файлов. Когда у вас миллион файлов и несколько терабайт объёмы:
- raw performance падает на порядок (т.е. вы и близко не можете утилизировать пропускную способность своего интернета),
- появляются разные ошибки и проблемы с синхронизацией (видимо они всегда появляются, но их вероятность завязана на файлы, а когда файлов много, вероятность, что хоть с одним будет что-то не так, поднимается на порядки),
- если добавляется что-то большое - реорганайзинг, бэкап или даже просто "скинул пару десятков гигабайт новых фоточек", то клаудом невозможно пользоваться, пока всё не засинхронизируется (что осложняет вообще пользование компьютером).

Выводы:
- image backup,
- сегрегация данных по разным уровням приватности, по частоте обновления и пр.

2. Никто не сохраняет атрибуты файла, кроме, может, даты-времени последней модификации. Дата-время создания - гибнет.

Выводы:
- либо image backup,
- либо написать какую-то утилиту, которая будет запоминать файловую метадату и, при необходимости, восстанавливать. Кстати, заодно за контрольными суммами можно следить. Возможность bit rot никто не отменял.

3. При image-level backup сталкиваешься с несколькими проблемами:
- ограничение на размер файла, причём у разных клауд-провайдеров оно разное. Я пока остановился на 32 GB, но так как я экспериментирую с разными провайдерами, не факт, что не придётся уменьшить; понятно, backupper'ы должны поддерживать image-level с пропуском свободного места, шифрование и разбивку на многотомные архивы, с поддержкой инкрементальности,
- надо schedule'ить закачку ночью, сразу после создания бэкапа, т.к. во время закачки другие вещи не будут закачиваться (Dropbox - приятное исключение, они приоритезируют файлы меньшего размера),
- проблема с full vs incremental backups: надо либо иметь место на клауде, чтобы сохранить два (!) full backup'а включая какое-то количество инкрементальных (грубо говоря, утроить требования по объёму), либо надо иметь отдельный локальный диск с таким количеством места, и дополнительным скриптом убивать предыдущий full backup и связанные с ним incrementals, прежде, чем синхронизировать эту директорию с другой, которая уже синхронизируется с клаудом (требует 4.5-кратного места на локальном диске - 3-кратный временный буфер и 1.5-кратный cloud storage полностью отражённый на локальном диске),
- проблема со скоростью интернета... full backups не должны занимать больше, чем полдня на закачку. 12 часов со скоростью 1 Gbit/sec это 5.2 терабайта. Реально можно достичь 50% утилизации, это уже 2.6 терабайт. Во-первых, это не так много (т.е. 2.6 терабайтами должен быть ограничен весь массив). Во-вторых, это слишком жёсткая зависимость на гигабитный интернет. Если я уеду из San Francisco, интернет, вероятнее всего, станет 100 мегабитным, поэтому объём информации, которую можно регулярно бэкапить в клауд, станет 250 GB.

У этой проблемы есть решения. Например, вместо бэкапов просто синхронизировать директорию. Но:
- это должны быть большие файлы. Т.е. это можно делать, скажем, с фото и видео, но не с мелкими файлами.
- если это sensitive файлы, которые нужно шифровать, то нужно использовать что-то вроде Cryptomator, а это дополнительная возможность огрести разные глюки. Что делает более важным вопрос регулярных бэкапов локально и их сохранность (чёрт возьми, мы же пытались избавиться от NAS, а теперь, получается, он снова нужен!)

Короче, все эти процессы непростые, и я в процессе экспериментов и исследования. От сервера я уже избавился, но купил дополнительный 12 TB диск, и навтыкал несколько больших дисков в desktop'ный комп, в дополнение к тем новым NVMe дискам, что я купил. Окончательный layout ещё не ясен. Ясно то, что владеть 10 терабайтами говна без полноценного NAS - невероятно дорого и накладно, и клауд на сегодня не спасает, поэтому основной effort надо направить в уменьшение размеров коллекции.
moth

Программирование для начинающих

Подскажите что-нибудь (игровое? забавное? увлекательное?), чтобы взрослому человеку - любознательному, располагающему временем, но без особого STEM-бэкграунда - заинтересоваться программированием. Цель - что-то вроде "чуть-чуть потрогать, чтобы получить общее представление", и решить для себя, имеет ли смысл углубляться (ну, т.е. "попробовать увлечься"). Желательно что-то, во что можно поиграться с планшета.
moth

Переход от NAS к Cloud Storage

Попытка отказаться от NAS оказалась непростым проектом и я всё ещё в процессе. Экспериментирую, смотрю.
Во время экспериментов жёстко соблюдаю такой стандарт:
- каждый файл есть минимум в трёх копиях на разных носителях, как минимум один из которых физически не подключен к компу,
- каждое копирование делается через robocopy с параметрами, чтобы включать все атрибуты,
- после каждого копирования я делаю побайтное сравнение источника и адресата.

У меня примерно 10 TB "полезной нагрузки", но в них много ненужного. На сервере это было 5 дисков по 5 "TB" (на самом деле, 5+6+6+8+8, но использовались они как 5+5+5+5+5 в RAIDZ-2, т.е. с избыточностью на два диска) плюс два диска на 12 "TB" в ротации для offsite backup'а. На один постоянно реплицируется весь массив, а с другим его можно swap'нуть раз в квартал. Плюс 1 TB данных на быстром storage на самом компьютере, и часть места на сервере занимали клиентские бэкапы - инкрементальные и не очень - этого массива.

Первая оптимизация - клиентские бэкапы. Их количество можно сократить, если в Cloud Storage использовать функцию файловой истории или снапшотов. В частности, Dropbox Professional (который даёт 3 TB за $200/год) имеет фичу полной файловой истории с возможным откатом директории с поддиректориями на любой момент из последних 180-дней, и я рассчитывал, что эта фича позволит мне отказаться от большого количества инкрементальных бэкапов. (Смысл которых, в основном, в том, чтобы найти что-то, что было случайно удалено.)

Вторая: есть вещи, которые можно заново скачать. Я параноик и не верю в доступность интернета, всё хорошее люблю хранить локально. Тем не менее, если есть возможность скачать заново, то это не настолько критичная информация, чтобы платить за её хранение в 5 экземплярах, тратить на неё NAS или Cloud Storage, etc. Вполне достаточно будет поставить два диска в mirror.

Изначальная идея была в том, что для всего оставшегося мне хватит 6-7 TB клауда, и ещё будет запас. Я куплю Dropbox Professional (3 TB), плюс у меня уже есть Office 365 Family, дающий 6 TB, но 6 отдельными кусками по 1 TB, я докуплю быстрого NVMe storage для "кэша" этого Cloud Storage.

Здесь надо сделать небольшое отступление и послать луч ненависти производителям железа для storage, которые за последние 10 лет попытались внедрить стандарт, будто в килобайте 1000 байт и 1 TB = 10^12 байт, а старое общепринятое значение (1 TB = 2^40) переименовать в TiB. У них это частично получилось. В новостях стали писать слово TiB, а также в некоторых утилитах. Но Windows держит оборону и показывает как в Explorer'е, так и во всех дисковых утилитах настоящие терабайты. Клауд-провайдеры тоже заняли Светлую Сторону Силы, и терабайты у них подлинные.

Я категорически отказываюсь использовать TB для фейковых терабайт и TiB для настоящих. Вместо этого фейковые у меня будут в кавычках ("TB", чтобы каждый раз смеяться над ними в местах упоминания объёмов), а настоящие без кавычек. 1 "TB" = 0.91 TB. Другими словами, в диске на 12 "TB" даже 11 настоящих терабайт нет, там 10.91 TB. А аргумент про систему "СИ" засуньте в жопу. Меры объёма памяти в компах всегда были привязаны к двоичной системе, потому что это единственный осмысленный вариант, а читить стали только производители хардов, потому что у них работали хитрожопые маркетологи. А потом подхватили неграмотные журналисты, которые повелись на аргумент про "СИ".

Я докупил NVMe хардов, так что у меня суммарно стало 8 "TB" NVMe, поставил два 8 "TB" харда в mirror для "менее важных" данных, и попробовал добавить в Dropbox какую-то часть файлов, что раньше были на сервере. Не все, конечно, но много - несколько сот тысяч файлов суммарно на 1 TB.

Отдельно исследовал вопрос шифрования на клиенте, чтобы взлом Dropbox account'а не позволил угнать важную инфу. Cryptomator имеет разные недостатки, но вроде неплох, "мышей ловит". Ему даёшь директорию, он её монтирует как "виртуальный диск", на этот диск можно писать файлы, а в физической директории будут появляться файлы в таком же количестве и с такими же размерами, но шифрованные и с изменёнными именами, похожими на случайные.

Какие я узнал интересности:

1. Если потрогать много файлов, Dropbox очень надолго подвисает, и пока он не разберётся с большим массивом, он не будет делать больше ничего полезного. Какой-то возможности приоритезировать апдейты у него нет.

2. Performance Dropbox синхронизации сильно падает, когда много маленьких файлов. Дропбоксу нужны большие файлы (десятки мегабайт и выше) для оптимальной скорости работы.

3. С большим количеством файлов в Windows Explorer'е невозможно работать, если эти файлы под управлением Дропбокса. Например, невозможно работать с фотографиями. Превьюшки не грузятся, всё адски медленно, а когда пытаешься переименовать фото, добавив в имя файла тэг, он делает какой-то странный рефреш, уничтожая выделенное имя файла прямо в процессе, пока я его редактирую.

4. Дропбокс навязчиво рекомендует online-only режим или Smart Sync, и когда играешь с этими сеттингами очень легко случайно перевести файлы в режим Online. После этого Cryptomator, естественно, сходит с ума, а чтобы всё восстановить, надо сутки ждать, пока заново скачается этот весь терабайт, и, конечно же, никакая разумная синхронизация нужных вещей, над которыми ты сейчас работаешь, одновременно с этим процессом работать не будет. Кстати, Дропбокс не сохраняет "created" timestamp, это отдельная проблема, которую надо будет решить. Timestamp'ы будут убиты при переводе файла из offline в online и обратно, а также при воссоздании Dropbox директории на другом железе.

Вывод, который я сделал, такой: Cloud Storage для больших коллекций файлов - полное говно. Надо будет глянуть лет через 5, а лучше 10.
До тех пор клауд можно использовать для малых объёмов (десятки гигабайт), а также, возможно, для бэкапов.

Кстати, это втрое увеличивает необходимость физического места на диске. На первом диске директория с миллионом файлов на несколько терабайт. На второй диск делается (скажем, ночной) partition/image-level бэкап всего - причём без компрессии и без шифрования - так, чтобы при небольшом изменении данных менялась лишь небольшая часть бэкпапа (для differential sync!). Бэкап либо сразу режется на куски от 100 MB до 5 GB, либо отдельным скриптом. Отдельным скриптом шифруется и копируется на третий диск, поверх того, что там было, а третий диск уже синхронизирован с клаудом. Тогда мы получаем сразу всё:

1. Отсутствие проблем с блокирующими обновлениями (это всё можно заскриптовать как ночной job).

2. Быстрое обновление, потому что будет differential backup, даже если бэкап каждый раз 2-терабайтный. Именно для этого он должен изначально делаться без компрессии и без шифрования, а только потом можно накладывать шифрование уже на отдельные куски, а не на весь stream.

3. Возможность делать image level backup любым софтом, и отдельно шифровать тоже любым софтом.

4. Возможность пользования оригинальной коллекцией файлов без какой либо тормозни из-за интеграции с cloud storage.

Собираюсь попробовать этот подход, пока ещё не настроил его. Но уже купил ещё один 12 "TB" диск, который я смогу использовать как дополнительный буфер.

Ещё один отдельный вывод - надо стараться, чтобы файлов было вообще поменьше. Ну там, сканировать документы в худшем качестве и всё такое прочее. Сам факт наличия 10-терабайтного массива - это бардак и безобразие, которое требует куда большего физического железа, чем 10 TB, из-за всяких overhead'ов процесса синхронизации и бэкапа, и все операции требуют уйму времени.
moth

RAW vs No RAW - 2

После предыдущего поста (https://morfizm.livejournal.com/1410660.html):

* Попробовал DxO Photolab 4. Оно лишь немногим более быстрое, чем лайтрум, но куда более глючное, "сырое" и менее удобное. Мне вообще не понравилось.

* Попробовал Capture One. Он очень быстро, прям в самый раз, но адски неудобно. Там совершенно уёбищный тёмный скин, который нельзя поменять, и очень мелкий шрифт всех контролов, и это тоже нельзя поменять. Из плюсов Capital One - отмечу, что алгоритмы noise reduction сильно напоминают те, что встроены в камеру, и они мне куда больше нравятся, чем лайтрумовские. Лайтрум всё равно оставляет точечный шум, если смотреть на уровне пикселей, просто он делает так, что "издали" шум не виден. Встоенный JPEG-writer в камере, а также Capture One, как-то интерполируют эти точки так, что они не выглядят шумом, а выглядят непрерывной плоскостью. Может, по "количеству информации" там будет столько же, но мне это эстетически приятнее.

* Запустил Lightroom снова и попробовал агрессивно поменять параметры на "хуже качество, зато, может быть, быстрее". Стало действительно заметно быстрее, но я не знаю точно, какой именно параметр помог, потому что я изменил сразу несколько. Подозреваю, что Smart Previews. Я до этого использовал только 1:1 previews.

** Preferences -> Performance -> [x] Use Smart Previews instead of Originals for image editing (from [ ])
** Preferences -> Performance -> [x] Generate Previews in parallel (from [ ])
** Catalog Settings -> File Handling -> Standard Preview Size - 2048 (down from "Auto 2560")
** Catalog Settings -> File Handling -> Preview Quality - Medium (down from "High")

* Переключил на своих камерах режим JPEG-only. Буду привыкать и разбираться. Там, оказывается, в менюшках (перед снимком!) можно выбирать creative style, подкручивать яркость-контраст-saturation, etc - в общем, много всего того, для чего обычно используют post-processing. Кроме того, в режиме JPEG доступен цифровой зум - по сути, это возможность сразу делать нужный кроп, с дополнительным бонусом, что автофокус будет подстраиваться под выбранную зону.

* По наводке одного из читателей, dimka_rs, собираюсь поиграться с darktable - Open Source альтернатива Lightroom'у.
moth

Пассивный залог

Прошёл совершенно не нужный, но обязательный тренинг по письменному языку (на само деле это было больше по стандартам корпоративного общения и документооборота). Всё, что было в тренинге, я давно знал по опыту, но нашего главного вицепрезидента дивизии настолько довели безграмотные нечитаемые доки, что он решил заставить всех пройти тренинг.

Я и раньше избегал пассивного залога, мне кажется, что это бессмысленное отстранение от ответственности, когда всегда можно сказать, кто конкретно облажался. Скажем, сравните: "билд был сломан вчера" (бля, ну кем сломан?) или "команда Ломателей вчера сломала билд" (тут сразу всё понятно, я так и думал). Второй вариант несёт куда больше полезной информации при почти том же количестве слов (можно даже не писать слово "команда", тогда будет просто "Ломатели" и будет столько же слов!)

Оказалось, что пассивный залог считается плохим тоном в корпоративной документации не только поэтому, а ещё и потому, что он, оказывается, считается показателем сложности языка и, соответственно, трудночитаемости. Для работы всё должно читаться максимально легко, потому минимизируем. Мало того, Microsoft Office Word может выдавать статистику текста и показывать, сколько там предложений в пассивном залоге!

А ещё - забавный трюк, как определить, не пассивный ли залог. Если к фразе можно добавить "by zombies", значит, пассивный!
- "билд был вчера сломан зомбарями" - звучит корректно и логично! Значит, мы в пассиве.
- "Ломатели вчера сломали билд зомбарями" - звучит несколько экзотично и странновато. Значит, это актив!