waqur: (Default)
2017-08-02 06:29 pm
Entry tags:

О сочетании CDMA с LineageOS/CyanogenMod

Раньше было так: либо смартфон имеет поддержку CDMA, либо под него есть прошивки уровня LineageOS/CyanogenMod.

Мотивация для этого взаимного исключения была примерно такова: если в смартфоне есть поддержка стандарта связи CDMA, значит это чистокровный китаец (не международная версия), с соответствующей вилкой на зарядном устройстве, с инструкцией на китайском языке и т.д. Соответственно на международном рынке эта модель не продаётся, её нет на региональных сайтах вендора и под неё вендор не считает нужным публиковать исходники ядра (в Китае пипл и так схавает). Пример: HTC 609d. Такой телефон можно купить в местных магазинах или в ЦОА Интертелекома, но локализация будет любительской, а over-the-air обновления работать не будут.

Если же мы хотим поставить на телефон толковую прошивку уровня LineageOS/CyanogenMod (с функцией Privacy Guard, без встроенного vendor spyware, с нормальной локализацией, с нормально работающими обновлениями, с периодом поддержки 5+ лет и т.д.), тогда следует учитывать, что создать такую прошивку невозможно без наличия исходных кодов для всех драйверов встроенных в телефон устройств, а значит — эта модель должна продаваться на международном рынке, а значит с поддержкой CDMA в таком телефоне всё будет плохо.

Недавно наконец-то появились телефоны (Xiaomi), которые сочетают в себе эти два очень полезных свойства (поддержку CDMA и открытые исходники ядра). Не все модели Xiaomi открыты, но по одному такому устройству в каждом ценовом классе есть. Ну а вопрос с CDMA решается так: Xiaomi для каждой модели своих телефонов выпускает по две версии — международную и китайскую. Они отличаются только сигнальным сопроцессором (который всегда поддерживает GSM/UMTS/LTE, но не всегда CDMA/EVDO), а прикладной процессор и его прошивка — едины.
waqur: (Default)
2017-07-06 10:10 am
Entry tags:

Docker: всрамся, але не здамся

Чем народ только не мается, лишь бы не использовать FreeBSD jails и ZFS:

https://habrahabr.ru/post/332450/
https://thehftguy.com/2016/11/01/docker-in-production-an-history-of-failure/
waqur: (Default)
2017-07-02 04:41 pm

not-a-bug

systemd при разборе конфиг-файлов для сервисов, которые должны стартовать от имени пользователя с пониженным уровнем привилегий, внезапно воспринимает любое имя пользователя, начинающееся с цифры, как "root". Таким образом, сервис тихонько стартует с максимальными правами в системе, и если окажется удалённо взломанным через remote code execution, то вы узнаете об этом лишь постфактум, когда уже будет "поздно пить Боржоми".

Изначальный замысел авторов systemd был в том, чтобы в этом контексте допускать UIDы наряду с именами пользователей. Замысел неправильный — стандарт POSIX не запрещает имена пользователей, начинающиеся с цифры, в том числе — состоящие из одних лишь цифр (IEEE Std 1003.1-2001, пункт 3.426). Например, можно создать пользователя с именем 1234 и UIDом 4321.

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

Пока шла дискуссия о том, один баг это или два (первый — необходимость выдачи внятного сообщения об ошибке вместо тихой элевации до прав рута, второй — необходимость поддержки имён пользователей, начинающихся с цифры), внезапно появился Поттеринг и закрыл этот баг как not-a-bug. Лолшто?
https://github.com/systemd/systemd/issues/6237

systemd is a symptom of the memetic cancer that has probably irredeemably destroyed UNIX in the Linux ecosystem — травят FreeBSD'шники:
https://twitter.com/matthewjweaver/status/881307929349160960

Ещё: https://twitter.com/Xof/status/881305418080804864
https://twitter.com/SwiftOnSecurity/status/881936783482777600
waqur: (Default)
2017-06-12 02:42 pm

Bitcoin: SegWit vs Unlimited

Как известно, криптовалюта Bitcoin в её текущей реализации имеет проблему: малый размер блока. По этой причине некоторые транзакции выполняются слишком долго или требуют черезчур высокой комиссии.

Предлагаемых решения два — Bitcoin Unlimited (просто увеличить размер блока) и SegWit (преобразовать одноранговую p2p-сеть в иерархическую). Оба потребуют изменений в исходном коде ПО Bitcoin, и, в принципе, оба являются ответвлениями (форками) от классического Bitcoin.

Скажу прямо — SegWit мне откровенно не нравится. Внедрение этой технологии может привести к тому, что в сети появятся более привилегированные узлы, которые будут осуществлять цензуру — эти транзакции мы пропускаем, эти не пропускаем. Критерии могут быть произвольные, например — идентификация клиентов по паспорту, по кредитной карте или по банковскому счёту; установка специфического клиентского ПО (например с рекламой или шпионскими функциями); повышенные комиссии; какие-то залоги или страховые фонды или прочие глупости. Причём эти глупости могут меняться на ходу по желанию весьма ограниченного круга лиц. Какая ирония, в Bitcoin будет свой центробанк! Против чего боролись, на то и напоролись.

Я исхожу из того, что кто бы не пытался контролировать Bitcoin (крупный частный бизнес или гэбня), контроль в Bitcoin'е — это плохо. Bitcoin — это вообще-то история не про контроль. Кто нуждается в том, чтобы его контролировали, у кого есть такая собачья тоска по палке — всегда могут просто открыть счёт в банке.

Пахнет это всё примерно как телеметрия в Windows 10, или как цензура приложений в AppStore, или преобразование децентрализованной p2p-архитектуры Skype в централизованную клиент-серверную, или как политика реальных имён в Facebook. Пахнет, скажем прямо, Родиной.


Как бы там ни было — дата ответвления SegWit UASF (BIP-148) недавно была назначена его сторонниками на 1 августа этого года. А именно: софтфорк SegWit (изначально предполагавший, что самые консервативые пользователи Bitcoin'а без SegWit и с малым размером блока так и останутся на более высоком уровне двухуровневой иерархии, и продолжат самостоятельно подтверждать свои и чужие транзации) как бы незаметно (ловкость рук и никакого мошенничества) превратился в UASF (User-Activated Soft Fork), который таких консерваторов отсекает от блокчейна. Как по мне, UASF = hardfork, что технологически ничуть не лучше конкурирующего хардфорка Unlimited.

https://bitnovosti.com/2017/06/11/uasf-and-skin-game/

Итак, да начнётся битва. Сколько ж можно тянуть, ё-моё! Учитывая нынешнюю капитализацию Bitcoin'а, Bitcoin SegWit vs Bitcoin Unlimited будет гораздо более жёстким противостоянием, чем Ethereum vs Ethereum Classic — есть за что побороться. Вопреки ожиданиям некоторых полезных идиотов (или намеренной дезинформации со стороны заинтересованных лиц), разветвления биткоина на несколько криптовалют не избежать. Как и курсовых потерь. Но я подойду к разветвлению с нулевым балансом.
waqur: (Default)
2017-06-03 10:35 am

Flatpak

Flatpak — платформа дистрибуции настольных приложений для Linux.

Фичи:
* установка приложений в обход основного репозитория дистрибутива
* единая платформа для всех дистрибутивов
* приложение распространяется с зависимыми динамическими библиотеками, т.е. не зависит от динамических библиотек основной системы (которые могут быть несовместимы с приложением, или внезапно стать таковыми в результате обновления системы)
* можно устанавливать одновременно несколько версий одного приложения
* платформа использует контейнерные технологии ядра Linux для создания песочниц приложений (bind mounts, namespaces, seccomp)

http://flatpak.org/
waqur: (Default)
2017-05-21 12:04 pm

tmux quick start guide

Весь мой UNIX experience делится на две части: до того, как я впервые установил терминальный мультиплексор tmux, и после этого.

Первоначальная мотивация к инсталляции программы заключается в том, чтобы обрыв ssh-подключений к серверу не приводил к закрытию подключённых к виртуальному терминалу процессов в результате доставки им сигнала SIGHUP. Затем к хорошим вещам привыкаешь быстро: можно оставить на ночь на сервере любую долго выполняющуюся задачу (инсталляцию, компиляцию, обновление, ...); можно экономить мобильный трафик и время, не передавая ssh-клиенту весь тот мусор, который выдаётся на экран во время выполнения таких задач; можно держать постоянно открытые окна для мониторинга состояния сервера (top, iftop); можно легко и удобно менять клиентские устройства, не прерывая серверный контекст; можно даже видеть один и тот же экран и суммировать клавиатурный ввод при подключении с нескольких устройств.

Обычно советы для новичков сводятся к чтению объёмной manual page и запоминанию многочисленных клавиатурных комбинаций, но как по мне — это лишнее. Начать следует с самого простого:

~/.tmux.conf:
set -g status-fg white
set -g status-bg red
set -g prefix C-a
unbind C-b
bind C-a send-prefix
set -g base-index 1


~/.bash_profile:
if [ $TERM = "xterm" ]; then
 ( (tmux has-session -t remote && tmux attach-session -t remote) || \
   (tmux new-session -s remote) ) && exit 0
 echo "tmux failed to start"
fi
if [ $TERM = "screen" ]; then
 clear
 cat /etc/motd
fi


А далее запомнить только три комбинации:
"Ctrl+A цифра" переключает окна
"Ctrl+A C" создаёт новое окно
"Ctrl+A D" отсоединяет от сервера (без потери контекста на сервере)

Большего мне не понадобилось и через пять лет после начала использования программы. Может, я использую 1% возможностей tmux, но этого вполне достаточно, чтобы повысить удобство удалённого администрирования в разы.
waqur: (Default)
2017-04-22 10:40 pm

YesScript для шрифтов?

В последнее время всё чаще попадаются сайты, свёрстанные с использованием специальных шрифтов для Mac OS. Не до конца понимаю, чем альтернативно ориентированных дизайнеров не устраивают стандартные шрифты в их операционной системе (по слухам, на маках вроде сломан TrueType hinting, из-за чего системный шрифт выглядит в браузере как будто набранный полужирным стилем, но только если мелкий кегль и только на крупнозернистых экранах).

В любом случае, их пидарские альтернативно ориентированные шрифты под Windows выглядят вот так:



В идеале, было бы установить расширение для Firefox, которое подоменно блокирует загрузку и использование сайтом любых шрифтов, кроме системных. Т.е. делает с несистемными шрифтами то же самое, что делает с javascript'ом аддон YesScript. Никто не знает такого?
waqur: (Default)
2017-04-15 10:46 am

Алгоритмическая генерация текстур

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

https://github.com/mxgmn/WaveFunctionCollapse

Ключевые идеи:
– распределение паттернов в квадратных блоках исходного изображения совпадает с распределением паттернов в таких же квадратных блоках результирующего изображения (достаточно большого размера)
– такие распределения становятся гораздо более точными, если учесть инвариантность самых маленьких плиток относительно вращений и отражений (диэдральная группа D4)
– алгоритм постоянно стремится минимизировать Шэнноновскую энтропию (авторы называют это "коллапс волновой функции"
waqur: (Default)
2017-03-11 11:53 am
Entry tags:

О декомпиляторах

Поначалу подход к декомпиляции ассемблерного листинга в сишный код сводился к двум основным идеям:
– построение графа потока управления, а далее применение pattern matching в непрерывных блоках кода (так работает плагин HexRays к дизассемблеру IDA, и работает порой откровенно плохо, куда-то теряя существенные куски кода — наверное, когда не может подобрать подходящие паттерны)
– попытка "подобрать" исходный код, из которого бы порождался наперёд заданный бинарный код, путём вызова компилятора и перенаправления дальнейшего подбора в в нужную сторону, в зависимости от сопоставления выхлопа компилятора и заранее заданного бинарного кода (теоретический подход, рассматриваемый в нескольких диссерах по декомпиляции, на практике работает плохо из-за того, что во-первых, нужно точно угадать версию компилятора; во-вторых, из-за того, что такие блуждания неустойчивы с точки зрения обратной связи, и могут быстро зайти "не в те дебри"; в-третьих, компиляторы имеют тенденцию к переименованию регистров и разным другим перестановкам даже при множественной инвокации на одном и том же исходном коде — так что простым сравнением бинарного выхлопа не обойтись).

Декомпилятор FCD демонстрирует новый подход: декомпиляция через оптимизирующую компиляцию. Каждая инструкция архитектуры x86 или x86_64 преобразуется в несколько инструкций промежуточного кода LLVM-IR (включая все сайдэффекты, такие как изменения в регистре флагов), а затем для упрощения всего этого фарша применяется оптимизатор промежуточного кода из проекта LLVM.

Ну а промежуточный код LLVM-IR — это уже практически код на C. Остаётся только сформировать деревья выражений там, где были однократно используемые временные переменные.

Учитывая недавние теоретические успехи в реконструкции if-else-for-while-структур из графа потока управления, позволяющие всегда обойтись без goto, результаты работы FCD выглядят весьма неплохо, даже на фоне коммерческого HexRays.
waqur: (Default)
2017-02-23 03:40 pm

О расщеплении стека

Одна вещь, которую я никогда не понимал в контексте теории борьбы с эксплоитами, основанными на stack corruption в коде, написанном на C/C++ и других небезопасных языках — это почему не используется расщепление стека надвое:

1. Доверенный стек: там обязательно должны быть адреса возврата из функций, параметры вызываемых функций; а также там могут быть локальные переменные, на которые не берётся указатель.

2. Недоверенный стек: там обязательно должны быть все локальные переменные, на которые берётся указатель — и далее либо ускользает из локального контекста, либо используется таким образом, что компилятор не может статическим анализом доказать нахождение индекса в безопасных границах. Недоверенный стек, в отличие от доверенного, мог бы расти в виртуальной памяти снизу вверх, чтобы разного рода эксплоиты упирались либо в неотображённые страницы, либо перезаписывали мусорные данные в свободной области недоверенного стека.

Не хватает регистров? Но мы ведь уже давно пишем не для 8-битных микроконтроллеров: в процессорной архитектуре x86-64 вдвое больше регистров, чем в x86, а ещё они вдвое шире. "Второй RSP" отлично поместился бы в каком-нибудь R13. Доверенный стек может быть исполняемым, недоверенный — всегда нет. Это бы решило проблемы несовместимости DEP (Data Execution Prevention) с GCC Nested Functions и всякими прочими closures из других языков. Очевидно, что глобальная оптимизация (которая называется в разных компиляторах по-разному: LTO, LTCG, IPO) могла бы существенно сократить количество случаев, когда нужен недоверенный стек.

Компиляторы и операционные системы могли бы поддерживать разные уровни параноидальности в реализации недоверенного стека:
* просто обычный стек
* стек со вставкой канареек в фрейм каждой функции
* стек со вставкой канареек после каждого объекта
* стек с чередованием отображённых и неотображённых страниц и с таким выравниванием каждого объекта, чтобы на следующем байте начиналась неотображённая страница
* полный запрет на существование недоверенного стека — подходящее решение для аэрокосмической/автомобильной/военной промышленности и медицины

Вместо этого индустрия вот уже лет десять или двадцать полагается на благие пожелания в вольной художественной форме, такие как MISRA C, или городит какие-то ASLR (которые не всегда работают), W^X, DEP, разные попытки противодействия ROP (например G-free и CFG), принудительные автоматические обновления, Rust и прочие глупости, которые проблему в общем-то и не решают, а так, царапают по поверхности.
waqur: (Евро)
2017-01-03 08:32 pm
Entry tags:

Рост производительности процессоров закончился

Обозреватели Arstechica жалуются, что новейший процессор от Intel (Kaby Lake, i7-7700K) по тестам не быстрее предыдущего (Skylake, i7-6700K):
http://arstechnica.com/gadgets/2017/01/intel-core-i7-7700k-kaby-lake-review/
Он чуть лучше гонится, потому что зубную-пасту-вместо-нормального-термоинтерфейса под крышкой процессора наконец-то исправили, ну а так — то же самое.

Если кто не знает или не помнит, Intel в этом году впервые дала пас в своей знаменитой "стратегии tick-tock": переход с 14нм на более тонкий техпроцесс (tick) был задержан на год из-за технологической неготовности. Взамен были обещаны архитектурные улучшения (ещё один tock), но как видим, увы.

Картинка для привлечения внимания: Механизм трансляции виртуальных адресов в физические в процессорах Intel: 64-битный режим, гостевая ОС в условиях аппаратной виртуализации (источник).

waqur: (Евро)
2016-12-30 04:19 pm
Entry tags:

О 16-битном наследии платформы x86

После перехода Windows на UEFI-загрузку старые интерфейсы BIOS, такие как int 13h (доступ к диску) и int 10h (управление экраном), казалось бы, могут быть наконец отправлены на пенсию (кроме случаев, когда загрузка происходит в режиме совместимости и в firmware вашего компьютера активизирован модуль CSM). Для вывода текста есть console I/O protocol, для переключения видеорежимов и блитирования есть graphics output protocol, также в UEFI существуют протоколы для считывания EDID-данных с дисплея (в т.ч. родного разрешения LCD матрицы), для доступа к диску и тому подобного.

Однако все эти новые UEFI протоколы становятся недоступными после вызова ExitBootServices() в процессе загрузки платформы, в контексте UEFI-загрузчика (например, такого как BOOTMGR.EFI). Не вызывать эту функцию нельзя, потому что иначе UEFI-загрузчик не перейдёт с CPL=3 на CPL=0, т.е. не возьмёт процессор под свой полный контроль и не сможет передать управление ядру.

А ведь SVGA-драйверу Windows нужно уметь переключать видеорежимы не только во время загрузки, а ещё и например когда пользователь меняет настройки рабочего стола. Поэтому драйвер VIDEOPRT.SYS содержит полнофункциональный эмулятор процессора, с пошаговым исполнением 16-разрядных команд из обработчика int 10h (который переключает видеорежимы, получает EDID-информацию от монитора, осуществляет suspend/resume видеокарты и т.п. — всё это посредством команд IN/OUT, причём разных команд для разных моделей видеокарт; соответствующий 16-разрядный код предоставляет сама видеокарта через option rom).

Таким образом, UEFI firmware должно при инициализации платформы проинсталлировать 16-разрядный код VBE SHIM по адресу 0xC0000, защитить этот регион памяти от записи и так далее (пример, как это делается, можно посмотреть в TianoCore). Ни UEFI firmware, ни Windows никогда не переключают процессор в 16-разрядный режим для прямого выполнения этого кода, но 16-разрядный код по-прежнему остаётся обязательной частью UEFI-платформы, в роли такого себе байткода виртуальной машины.

Когда-то давно, во времена NT 4.0, Windows просто приостанавливала многозадачность, выключала страничную адресацию, запрещала прерывания и помолясь переведя процессор в 16-битный режим, делала прямой вызов BIOS(*). Очевидно, что в эпоху многоядерных процессоров (ядра которых могут активно слать IPI друг другу) и 64-битности, такой финт может закончиться летальным исходом, поэтому в современных версиях Windows драйвер минипорта VGA содержит вышеупомянутый эмулятор, откуда он и перекочевал на UEFI-платформу. В отличие от семёрки и последующих версий, виста при загрузке (во время демонстрации логотипа) ещё и переключается в адовый VGA-режим 680x480 с 16 цветами и планарной видеопамятью по адресу 0xA0000 (где плоскости переключаются через порты VGA-контроллера); редкая комбинация UEFI-прошивки и прошивки видеокарты способна выдержать такое издевательство. Ну а Windows XP/2003 отличается в этом смысле как от предыдущих, так и от последующих версий Windows — она не содержит эмулятор как NT 6.x, но и не делает прямых вызовов BIOS как NT 4; вместо этого она выполняет код VESA BIOS Extensions в режиме виртуального 8086 (т.е. задействует аппаратную эмуляцию 16-битного кода, доступную только когда процессор находится в 32-битном защищённом режиме).

FreeBSD тоже содержит эмулятор 16-битного кода BIOS в драйвере vesa(4), для той же цели — переключение видеорежимов на заранее неизвестной видеокарте после загрузки ядра. Этот драйвер работоспобен в 32-битных и 64-битных ядрах, но только в BIOS/CSM режиме (в режиме UEFI драйвер vesa недоступен, а переключение видеорежимов делается только в загрузчике через UEFI GOP протокол).

Linux не содержит такого эмулятора и может переключать видеорежимы (на заранее неизвестной видеокарте) только до загрузки ядра.




* В ту эпоху такие прямые вызовы BIOS с глобальным остановом всей системы делались отнюдь не только при переключении видеорежимов. Анекдот про Билла Гейтса, который обещает показать, что такое многозадачность в Windows, но только после того, как доформатирует дискету, взялся именно оттуда.
waqur: (Евро)
2016-10-23 01:15 am
Entry tags:

When Solid State Drives are not that solid

Intel S3700 200 Gb — четыре года, полёт нормальный.

Intel S3500 480 Gb — два года, полёт нормальный.

Kingston SSDNow 512 Gb — примерно через 60 дней непрерывной работы исчезает с шины SATA. Этот эффект подтверждён не менее трёх раз. После выключения-включения — появляется опять. Изоляция (возможно глючной) прошивки контроллера от TRIM-команд и поддающихся сжатию данных с помощью шифрующего слоя geli не помогает. В общем — consumer only устройство, рассчитанное на регулярный power cycling. Такое даже в не каждый ноутбук можно поставить.
waqur: (Евро)
2016-09-13 12:58 am

Об исправлении размеров шрифта системных меню в Firefox'е

Что мне не нравится в Firefox'е — это замыленные значки и шрифты при системной настройке 120 DPI (увеличенные до 125% шрифты в Windows). Поэтому, первым делом после установки этого браузера я захожу в about:config и задаю layout.css.devPixelsPerPx=1 и layout.css.dpi=96. Это решает проблему практически на 100%, за вычетом системных и контекстных менюшек, которые остаются с мелким шрифтом (на них не влияют даже настройки font.minimum-size.*).

До сегодняшнего дня я боролся с этой досадной мелочью браузерным аддоном Theme Font & Size Changer, который, кстати, весьма неприлично себя ведёт, открывая свою домашнюю страницу при каждом автообновлении. В общем, очевидно, что подобные аддоны не улучшают безопасность браузера. Сегодня этот аддон окончательно сломался, что подтолкнуло меня найти другое решение: оказывается, достаточно создать файл C:\Users\User\AppData\Roaming\Mozilla\Firefox\Profiles\...\chrome\userChrome.css с таким содержимым:
* { font-size: 15px !important; }
waqur: (Евро)
2016-08-21 06:26 pm
Entry tags:

О POSIX-семантике удаления и "файлах-невидимках"

С незапамятных времён существует такая вещь, как "POSIX-семантика удаления". Это означает, что в Linux или другой Unix-подобной ОС любая программа или пользователь может удалить файл или даже каталог, одновременно открытый в другой программе. Соответствующая запись будет удалена из родительского каталога, но занятые файлом или каталогом блоки не будут освобождены на диске, покуда последний хэндл (или дескриптор) файла не будет закрыт. Разумеется, открытому файлу могут выделяться и новые блоки. Если в условиях наличия открытых хэндлов на "файлы-невидимки" произойдёт незапланированная перезагрузка, тогда такие "файлы-невидимки" будут удалены при следующем монтировании файловой системы в контексте драйвера.

У Windows NT традиционно сложные отношения с POSIX-семантикой удаления. Подсистема Win32 вроде бы поддерживает её для файлов, но только при условии, что для всех открытых хэндлов данного файла был задан share-флаг FILE_SHARE_DELETE (по умолчанию он сброшен, потому что так было в DOS). Даже в таком случае, старое имя по-прежнему возвращается функциями GetFileInformationByHandleEx() и NtQueryInformationFile(); покуда не закрыт старый, нельзя создать новый файл или каталог с тем же именем; каталог-хозяин "невидимого файла" может оказаться в "интересном положении", когда он вроде бы пуст и закрыт, но удалить или переименовать его нельзя. Учитывая вышеизложенное, можно сказать, что Win32-подсистема Windows NT в целом не поддерживает POSIX-семантику удаления. Другое дело — POSIX-подсистема: там всё удаляется так, как положено по стандарту. Ну, не совсем удаляется, а переносится в скрытый подкаталог в корневом каталоге тома с одновременной установкой FILE_FLAG_DELETE_ON_CLOSE. (Если далее произошла незапланированная перезагрузка, то вам как бы предлагается вмешаться и вручную поудалять всех потеряшек.) Я специально не изучал, как новая подсистема WSL/LXSS натягивает сову на глобус, но подозреваю, что через аналогичную задницу.

Тем временем в Linux, где хэндлы открытых файлов архитектурно привязаны не к именам, а к inode'ам, эта концепция продолжает логически развиваться. Начиная с версии ядра 3.11, "файл-невидимку" можно получить не только удалением существующего файла, а изначально: с помощью флага O_TMPFILE у системного вызова open(2). Позже, когда файл будет наполнен данными, его можно "проявить" в файловой системе через linkat(2), используя "/proc/self/fd/%d" в качестве "старого имени" и AT_FDCWD в качестве файлового дескриптора старого каталога. Ещё до "проявления", все необходимые атрибуты можно задать с помощью fchown(2), fchmod(2) и т.д. Таким образом, можно атомарно создавать заполненные файлы в файловой системе. Этот странный интерфейс не годится для POSIX, но сама концепция интересная. Недавно низкоуровневой интерфейс драйверов файловых систем в Linux был специально доработан для того, чтобы всё это стало реальностью.

Сам стандарт POSIX и его реализации тоже, конечно, содержат несуразности и глупости, даже если ограничиться только той частью, которая касается файловых систем. Так, попытка перезаписать с помощью open(2) с флагом O_CREAT и без флага O_EXCL исполняемый файл, отображённый в один из выполняющихся процессов с помощью mmap(2), порождает странную ошибку ETXTBSY (Text file busy). Во-первых, речь идёт не о текстовом файле, а о секции .text в бинарном исполняемом файле, которая традиционно содержит машинный код. Во-вторых, ошибка тривиально обходится удалением файла (unlink) и созданием нового файла на его месте. Отображение в другом процессе при этом будет ссылаться на старый файл, незавимо от того, полон или неполон новый файл и что в нём содержится. Однако, по каким-то лунным причинам open при перезаписи файла ведёт себя иначе, чем unlink + open на пустом месте.

Ещё одна забавная особенность или отклонение от ожидаемого поведения: Windows всегда реализует POSIX-семантику удаления для альтернативных потоков данных файловой системы NTFS. Например, вы можете создать текстовый файл с расширением .txt, в ADSе которого разместить DLL-ку, загрузить её с помощью LoadLibrary, и затем удалить оригинальный текстовый файл (включительно со всеми ADSками). До вызова FreeLibrary DLLка останется загруженной в виртуальную память, а место на диске — распределённым, по всем правилам POSIX-семантики, включая возможность создания другого текстового файла с тем же именем и с тем же именем ADS-потока без затрагивания "невидимого оригинала". Создать изначально невидимый ADS в Windows, к сожалению, нельзя. Передавать владение существующим ADSом между разными файлами тоже нельзя.
waqur: (Евро)
2016-08-21 12:05 pm
Entry tags:

О лютых тормозах

Материнская плата ASUS P10S-I отличается какой-то беспрецедентной тормознутостью в режиме CSM (16-разрядный BIOS в UEFI-системах).

Операционная система MFSBSD, которой под VMware нужно 30 секунд, чтобы загрузиться, на этой материнской плате загружается примерно полчаса. Полностью установленная FreeBSD из десяти минут, требуемых на загрузку, девять проводит в 16-разрядном режиме.

Такое ощущение, что оказался в 1996 году и загружаешь сервер с дискеты.

UPD: Оказалось, что проблема была в медленном выводе текста на консоль. В FreeBSD 11 загрузчик починили, чтобы он реже обновлял на экране эту крутящуюся палочку (twiddle), и тормоза при загрузке исчезли.
waqur: (Евро)
2016-08-18 01:17 am

Отучение сайтов от загаживания буфера обмена в Firefox'е

Некоторые сцайты любят гадить в буфер обмена — добавлять "подробнее " и ссылку на страницу при нажатии Ctrl+C, или очищать буфер обмена по тому же событию, по сути мешая копировать текст с сайта в буфер обмена.

Разумеется, эти и многие другие последствия шаловливости рук чрезмерно инициативных погромистов легко лечатся отключением JavaScript'а кнопкой, которая всегда на виду (браузерный аддон JS Switch), но всё же, это очень неудобно — каждый раз нажимать эту чёртову кнопку и перезагружать страницу.

Особенно это раздражает при копировании небольших текстов — таких как код изделия или цена — с сайтов интернет-магазинов.

Есть лучший способ — раз и навсегда отучить все сайты от загаживания буфера обмена:
about:config -> dom.event.clipboardevents.enable = false

Попутно можно отключить перехват сайтами контекстного меню, которое открывается кликом правой клавиши мыши:
about:config -> dom.event.contextmenu.enable = false

А ещё есть полезный плагин YesScript, позволяющий запрещать/разрешать JavaScript не глобально на весь браузер, а индивидуально для каждого домена. Если какой-то сайт начинает наглеть (срёт в буфер обмена, мельтешит всплывающими окнами, воспроизводит звук, рисует на фоне страницы какой-то снег и тому подобный бред) — нажимаем на значок белого свитка (который сразу чёрнеет), обновляем страницу и дело в шляпе. "Научишься плавать — тогда и воду в бассейн нальём." (c)
waqur: (Евро)
2016-08-07 08:34 pm
Entry tags:

All your partitions are belong to us

Мило, неотключаемый Windows Update из Windows 10 уже ломает работу загрузчиков других ОС в dual-boot конфигурациях (перенумеровывает разделы):
http://www.opennet.ru/opennews/art.shtml?num=44914

Иногда даже не просто перенумеровывает, а и попутно удаляет. :D
http://windowsreport.com/partition-disappears-windows-10-anniversary-update/
waqur: (Евро)
2016-08-06 05:44 pm
Entry tags:

О недокументированных особенностях файловой системы FAT

Официальная спецификация файловой системы FAT от фирмы Microsoft (когда-то бывшая доступной для скачивания с сайта microsoft.com, а сейчас циркулирующая по сети под именем fatgen103.{doc,pdf}) обозначает как "зарезервированные для Windows NT" некоторые поля и флаги дисковых структур файловой системы. Действительно, Windows NT всех версий использует их.

Недокументированные особенности файловой системы FAT, которые реализует Microsoft`овский драйвер этой файловой системы, но упускает официальная спецификация )