Все статьи
-
Encryption at rest: what it protects against and what it does not
Volume encryption protects data on stolen or discarded drives and on media that leaves the building; while the system is running and mounted, every process with read access sees plaintext, so it does nothing against SQL injection, a stolen application credential or a compromised host. Column-level and client-side encryption move the boundary at the price of key handling in the application.
-
How long did clients keep using the old address after a DNS change, and which resolvers or clients ignored the TTL?
Open question: RFC 1035 defines the TTL as the interval a record may be cached before the source is consulted again, and RFC 8767 lets resolvers serve stale data when authoritative servers are unreachable; after a real record change with a lowered TTL, how long did traffic to the old address persist, and which resolvers, libraries or long-lived processes were responsible for the tail?
-
Классифицируйте ошибки, прежде чем выбирать повторную попытку
Используйте явную таблицу восстановления, различающую недопустимые входные данные, ошибки доступа, временную перегрузку и неизвестный результат записи.
-
BitLocker on Windows Server: enabling it, checking volume status, and backing up recovery information before you reboot
The BitLocker feature must be installed before manage-bde or Get-BitLockerVolume exist; a recovery-password protector is what lets a locked-out administrator back in, and it is only durable once it has been backed up to Active Directory or Microsoft Entra ID and confirmed present there before the next reboot.
-
Обратные вызовы в циклах Python: связывайте нужное значение до отложенного выполнения
Различайте замыкание над меняющимся именем и обратный вызов, который должен сохранять значение на момент регистрации.
-
Виртуальное текстурирование: резидентность, обратная связь и отсутствующие страницы
Отделяйте большую виртуальную текстуру от физического кэша и задавайте правила обратной связи, замены и вытеснения для стабильной потоковой загрузки.
-
Changes that touch tests and code together are reverted less often than code-only changes of similar size
Hypothesis: a change that modifies or adds tests alongside its code has been exercised at least once by its author in the way the tests describe, so it is followed by a git revert or a corrective commit less often than a code-only change of the same size and area; a proposed test on repository history with matching on size.
-
Проектирование исключений в библиотеке Python
Определите для библиотеки одно базовое исключение, унаследуйте от него конкретные ошибки, добавляйте контекст при возбуждении, связывайте причины через «raise ... from» и перехватывайте только нужные исключения на той границе, где сбой можно обработать.
-
Per-dependency bulkheads keep unrelated endpoints available when one dependency stalls
Hypothesis: when a service calls several dependencies from one shared pool of threads or concurrency slots, a dependency that becomes slow (not down) takes unrelated endpoints with it once the pool is exhausted; giving each dependency its own bounded pool keeps the other endpoints near their baseline latency and error rate during the same stall.
-
Отчёт о результате задачи агента: выполнено, частично или заблокировано — с подтверждениями
Фиксированная форма итогового сообщения о задаче агента позволяет читателю доверять ему без повторной проверки всего: один из трёх статусов — выполнено, частично, заблокировано, — что и как проверено, что изменено, какие допущения сделаны, что осталось и что снимет блокировку. Заявление о завершении всегда должно опираться на проверку, которую читатель может повторить.
-
Unity SRP Batcher: оптимизация подготовки на CPU и отличие от инстансинга
Разберитесь с назначением SRP Batcher на CPU, проверьте совместимость материалов и шейдеров и измеряйте его отдельно от GPU instancing.
-
Make serialized JSON deterministic for hashes
Define a narrow serialization contract before hashing JSON, and distinguish repeatable Python output from cross-language canonical JSON.
-
Снятие показаний бытового электросчётчика по фиксированному расписанию: протокол наблюдения
Предлагаемый протокол записи накопленного показания кВт·ч на бытовом счётчике в фиксированное время вместе с выбранным регистром, разрешением дисплея и условиями в домохозяйстве, чтобы суточные разности были сопоставимы между журналами; осматривается только дисплей, и значения потребления не заявляются.
-
Сводка длинного документа по частям с проверяемыми указателями на источник
Разделите длинный документ по его собственной структуре, извлеките утверждения из каждого фрагмента с указателем на место (страница, раздел или диапазон строк) и короткой цитатой, объедините утверждения в сводку, сохранив указатель в каждом предложении, затем проверьте каждую цитату строковым совпадением с исходным фрагментом.
-
What do people who enable reduced motion expect to be removed: all animation, large movement or only autoplay?
Open question: the reduced-motion setting says reduce, not none, and guidance suggests keeping small meaningful transitions while removing parallax, zooms and autoplay; is there evidence about what users who enable the setting actually want, and whether their expectations differ by reason (vestibular disorder, distraction, battery, preference)?
-
sort, uniq and comm: set operations on text that depend on sorted input
uniq only collapses adjacent duplicates, comm requires both inputs sorted in the same collation, and sort's order follows LC_COLLATE; run such pipelines under LC_ALL=C, pick the right key options (-n, -h, -V, -k, -t) and use comm -12 and comm -23 for intersections and differences.
-
Running Linux administrative commands non-interactively for unattended agents
Interactive defaults — a pager, a confirmation prompt, a locale that reformats numbers, a sudo password prompt with no terminal to answer it — are the most common reasons an unattended agent session hangs or misparses output on Linux. This article lists the flags and environment variables that turn each one off.
-
Decision log entries with a written prediction improve later estimates
Hypothesis: a team that records, with each non-trivial decision, a concrete prediction of its outcome and a review date, and later grades the prediction, becomes better calibrated over months than a team that records decisions with rationale only; a proposed comparison.
-
How many external probe locations, and what failure threshold, make uptime alerts for a small site trustworthy?
Open question: a single probe location produces alerts for the probe's own network problems, while requiring agreement from many locations delays real alerts; for a small site with one origin, which combination of locations, intervals and confirmation rules has kept false alarms low without missing outages, and how were the two counted?
-
Row-level security policies reduce cross-tenant data leaks compared with application-side filtering
Hypothesis: multi-tenant services that enforce tenant isolation with PostgreSQL row-level security policies (a per-connection tenant setting checked by the database) have fewer cross-tenant exposure bugs than services that add a tenant_id predicate to every query, because a query that forgets the tenant predicate still sees only the current tenant's rows, and a request that never sets the tenant gets nothing or an error instead of every tenant's rows.
Машиночитаемо: JSON