Все виды путей в Windows в одной статье

(спойлер: их там восемь разных видов!)

https://googleprojectzero.blogspot.com/2016/02/the-definitive-guide-on-win32-to-nt.html

Как хорошо, что в UNIX всего два вида путей: абсолютные и относительные 😌

А теперь поговорим, что не так с путями в UNIX

Проблема в том, что в именах файлов в UNIX-подобных ОС (в Linux в том числе) запрещены лишь два символа: '\0' (он же нулевой символ) и /, а все остальное разрешено. В имени файла может быть даже перевод строки!

И эта особенность мешает правильно отображать имена (мало кто, думаю, умеет правильно показывать многострочные имена файлов). К тому же, становится невозможно парсить вывод утилит вроде ls или find надежным образом. Действительно, ls обычно разделяет файлы переводом строки, а что если в самом имени файла встретится перевод строки? Правда, у find есть флаг -print0, который разделяет имена файлов нулевыми символами, но данные в таком формате надо как-то предобрабатывать, чтобы скормить в пайп другой программе.

Еще происходят веселые вещи, если в имени файла есть специальные символы. Например:
$ touch $'\033[31;1mredfile\033[0m.txt'
$ ls
''$'\033''[31;1mredfile'$'\033''[0m.txt'
$ find .
.
./?[31;1mredfile?[0m.txt
$ echo *
redfile.txt

(после выполнения последней команды redfile будет выделен красным цветом)

Здесь видно, что GNU'шные find и ls заменяют спецсимволы на ?, поэтому вы никак не узнаете истинное имя файла, если будете парсить вывод этих утилит. Это поведение еще не портируемо; например, find из busybox выдаст

$ busybox find .
.
./a
b.txt
./redfile.txt

(и redfile снова будет красным)

А еще имя файла — произвольная последовательность байт, а в какой кодировке ее интерпретировать — остается на усмотрение пользовательских программ. Обычно в GNU/Linux все имена файлов записаны в UTF-8, но если криво установить локаль, то все имена на русском рискуют превратиться в тыкву.

На месте авторов UNIX я бы, наверное, запретил все символы с кодом меньше 32 в именах файлов. Еще я бы запрещал называть файлы невалидным UTF-8, но появление Юникода, увы, авторы оригинального UNIX предугадать не смогли бы. А добавить такой запрет позже сложно, потому что надо тянуть обратную совместимость.

Еще про пути в UNIX

(пример честно украден из The UNIX-HATERS Handbook)

У вас в домашней папке случайно оказался файл с именем -r. Вы хотели удалить все файлы на верхнем уровне (но не трогать подпапки) и набрали

$ rm *

Как нетрудно догадаться, эта команда удаляет рекурсивно все содержимое... кроме одного файла с именем -r :)

Правильно было бы написать rm ./* или даже rm -- *, чтобы такого безобразия не произошло.

Windows и TerminateThread

Советую почитать замечательную статью: https://devblogs.microsoft.com/oldnewthing/20150814-00/?p=91811

tl;dr:
> Originally, there was no Terminate­Thread function. The original designers felt strongly that no such function should exist because there was no safe way to terminate a thread, and there’s no point having a function that cannot be called safely. But people screamed that they needed the Terminate­Thread function, even though it wasn’t safe, so the operating system designers caved and added the function because people demanded it. Of course, those people who insisted that they needed Terminate­Thread now regret having been given it.

Примерный перевод:
> Мы не хотели делать TerminateThread, потому что считали, что нельзя безопасно прибить поток. Но нас очень просили его реализовать. Поэтому мы все-таки добавили TerminateThread, но сделали его сломанным, чтобы пользователи жалели о том, что захотели такую функцию.

В сломанности TerminateThread убедиться несложно. Достаточно запустить простой код, который запускает много потоков и сразу же их убивает. Не знаю, как у вас (кто может проверить, отпишитесь в комментах), а у меня на Windows 7 этот код наглухо зависал на какой-то итерации, не добегая до конца. И это при том, что здесь нет никаких примитивов синхронизации, а только создание потока!

Переполнение в Java, которое позволяет итерироваться после изменения массива

Как известно, если ArrayList<> поменять во время итерации, то Java кинет исключение java.util.ConcurrentModificationException. Однако это можно обойти. Рассмотрим такой код:

import java.io.*;
import java.util.*;

public class ExceptionHack {
    public static void main(String[] args) {
        ArrayList<Integer> arrayList = new ArrayList<>(List.of(1, 2, 3));
        Iterator<Integer> iter = arrayList.iterator();
        int item = iter.next();
        System.out.println(item);
        arrayList.add(0, 4);
        arrayList.add(1, 5);
        for (int i = 0; i < Integer.MAX_VALUE; ++i) {
            if ((i & 16777215) == 0) {
                System.out.println(i);
            }
            arrayList.add(0, 3);
            arrayList.remove(0);
        }
        iter.next();
        System.out.println(item);
    }
}

Он не кидает никаких исключений, хотя между увеличением и созданием итератора проходит много модификаций! Объяснение такое: у ArrayList<>, как и у итератора, хранится счетчик числа модификаций, при каждом изменении он увеличивается. Если счетчики не совпадают, то кидается исключение. Беда в том, что этот счетчик имеет тип int, поэтому его нетрудно переполнить. Чем, собственно, и занимается написанный выше код.

ААААААААА, ЭТО ОФИГЕННО!!!! 🤩 Клеточный автомат «Игра Жизнь» симулируется на самом себе бесконечно в обе стороны!!! Просто откройте!

https://oimo.io/works/life/

И еще в тему бесконечно-рекурсивных изображений:
https://xkcd.com/1416/

Впечатляет не так сильно, как рекурсивная игра «Жизнь», но тоже довольно залипательно. Можно поисследовать и отыскать всякие разные картинки. Увы, при слишком большом приближении все начинает лагать :(

Как погладить манула при помощи ChatGPT :)

(дисклеймер: не повторяйте описанные действия самостоятельно!)

Все основные кириллические раскладки делятся на три типа

1) ЙЦУКЕН-подобные
2) QWERTY-подобные
3) болгарская

Предположения о том, насколько плохо все со взломом LastPass

“Despite having her master password set to an astonishing 19 characters, our source claims to have experienced a wave of successful attacks against her through the sites and services she uses. These have included messing with her home thermostat to change the temperature to a sweltering 87F (About 30C for those who use sensible measurements).

As fun a prank as that sounds, our contact also reports the attackers used her Apple ID and ATT credentials to change the PIN on her phone, successfully simjacked her, and added a whole bunch of authorized devices to her LastPass account to bypass MFA.”

https://thecrow.uk/lastpass-data-breach-is-starting-to-look-truly-horrendous/

Немного комментариев по поводу предыдущего поста.

1) Подробности пугают, если здесь есть пользователи LastPass, то лучше срочно менять пароли, сбрасывать открытые сессии и смотреть, правда ли злоумышленник не успел зайти :)

2) Пока не очень понятно, как именно все описанное произошло, учитывая, что по заявлениям LastPass они шифруют все локально и не передают мастер-пароль на сервер (хотя я здесь не очень знаю их механику). Если описанное выше — правда, то будет интересно дождаться подробностей и почитать :)

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

Гораздо лучше те менеджеры паролей, которые позволяют хранить все локально и не делают никаких дополнительных удобств по синхронизации: если нужно синхронизировать пароли, то просто берешь и как-то копируешь зашифрованный файлик :) Если пароль для шифрования этого файлика достаточно надежный, и если мы верим в современную криптографию, то на подбор пароля могут уйти тысячи лет, а то и больше.

Например, рассмотрим пароль из 12 случайных маленьких латинских букв — всего 26^12 = 9.54 × 10^12 вариантов. На проверку каждого пароля уходит примерно секунда: дело в том, что для шифрования используется не сам пароль, а его специальный хэш. Этот хэш специально спроектирован так, чтобы для его вычисления потребовалось много времени и памяти (типично порядка секунды времени и гигабайта памяти, но зависит от настроек хэша). Таким образом, на подбор пароля потребуется примерно 3 × 10^9 лет :) Этот процесс можно распараллелить, но из-за лимита по объему памяти на одном сервере можно считать порядка сотен хэшей одновременно, а распараллеливание на GPU не поможет.

Конечно же, наличие уязвимостей в коде (если они есть) сильно упрощает процесс взлома.

Из примеров таких локальных менеджеров паролей могу привести pass и KeePassXC.

4) Из пунктов выше следует, что история в посте очень странная, и стоит ждать подробностей. Но в любом случае лучше поменять пароли, если история со взломом LastPass вас как-либо затронула.

Про будущее канала

Сегодня последний день года, а это значит, что пора поговорить о будущем :) К тому же, каналу уже почти два месяца.

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

Тем не менее, я писать не прекращаю и постараюсь приносить что-то интересное раз в 2-4 дня. Делать каждый день по посту уже, вероятно, не получится. К тому же, все мы страдаем от информационного перенасыщения, и лучше чуть уменьшить объем информации, чтобы и успеть сделать все дела, и успеть внимательно прочитать все посты :) Но главная причина скорее в том, что генерить или даже репостить интересный контент каждый день сложно.

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

Stay tuned!

2023 не будет простым

Потому что, как известно, 2023 = 7 × 17 × 17.

Надеемся на то, что 2023 год не доставит нам всем неожиданных неприятностей и неприятных неожиданностей, как 2022 :)

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

Всех с Новым годом! 🎉🎄

Снова забавный Юникод

1) Пусть в Python верно одновременно

>>> assert x != y
>>> assert len(x) == 1 and len(y) == 1
>>> assert x.upper().lower() == y.upper().lower()
>>> assert x.lower().upper() == y.lower().upper()
>>> assert x.upper().lower() == x
>>> assert y.upper().lower() != y

2) Пусть в Python верно одновременно

>>> assert x != y
>>> assert len(x) == 1 and len(y) == 1
>>> assert x.upper().lower() != y.upper().lower()
>>> assert x.upper().lower()[0] == y.upper().lower()[0]
>>> assert x.lower().upper() != y.lower().upper()
>>> assert x.lower().upper()[0] == y.lower().upper()[0]
>>> assert x.lower().upper() != x
>>> assert y.lower().upper() == y

Угадайте, какими могут быть x и y в обоих случаях

https://quick-lint-js.com/blog/cpp-vs-rust-build-times/

Текст про сравнение скорости сборки Rust vs. C++.

От кучи подобных текстов отличает монументальность подхода - коллега переписал 17 тыщ строк с С++ на Rust, для корректности сравнения.

Измеряется вообще ВСЕ - инкрементальные vs полные сборки, различные трюки для ускорения сборки как С++, так и для Rust, в том числе, (за это отдельный респект и уважуха) - попытка собрать тулчейны с #BOLT.

Короче, автор явно одержим скоростью, почитайте.

Выводы? Все сложно!

≥ 100

Ура, в Гнезде уже более 100 подписчиков :) Приветствую всех, кто присоединился недавно и надеюсь, что вам понравится контент здесь :)

Эх, теперь мне придется писать еще более годные посты :\ Ну ладно