Меня один банк на букву К блокировал... аж на целую неделю, огромнейший срок;) Не объяснили, почему, разблокировали молча.
У остальных такого не было, но есть одна существенная проблема -- идентификация. Во всех банках приходится её проходить каждые примерно 2-3 года, доказывая, что жив, здоров достаточно, чтобы пройти идентификацию, и документы прежние. Вот тут возникает интересный вопрос, что делать тем, кто и в стране внутри не находится, и Дию (которая позволяет это делать в онлайне) не может поставить (хм). Тут уже могут быть проблемы. Вот если кто-то, как АС, "уклонист", не имеет актуальных документов, не может обновить их в посольстве, тому тяжело. Но чтобы уже сразу с 22-го года получить полную блокировку счетов -- тут практически наверняка какие-то не совсем корректные, мягко говоря, действия были со стороны клиента.
Мыльным или мелким делает либо рукожопость либо сознательный саботаж.
Как-то на тему "мыльности" интерфейсов жёстко зацепились на RSDN. Разумеется, консенсуса в дискуссии не нашлось, но всплыло интересное наблюдение: что отношение к разным стилям рендеринга, сглаживания, подходам к спейсингу и лигатурам сильно зависит от персонального зрения, и в первую очередь от наличия/отсутствия близорукости. Близорукий значительно меньше реагирует на "мыльность", но больше -- на другие факторы. Как по мне (≈-4 и обычные очки на слегка неполную корректировку), наблюдение подтверждается. Цитата:
Тут есть такое соображение: те, кто видят хорошо, в основном предпочитают более контрастный рендеринг шрифтов. Потому, что "грязь" или "размазанность" вызывает у них ощущение, что картинка не в фокусе — и глаза, постоянно пытаясь подстроиться, устают. Те, у кого зрение и так блюрит картинку, больше обращают внимания на равномерность оптической плотности — им всё равно, отрисована ли линия шириной в один пиксел чёрного цвета или в два пиксела серого цвета.
Не то чтобы 100%, но имеет смысл как отправная точка для дальнейшего исследования.
Тем не менее в Accessibility настройках винды до сих пор нет соответствующей регулировки, в отличие от массы других настроек типа ярких траекторий мыши.
Ваше слепое высокомерие не даёт вам потратить две минуты и убедиться, что для большей части функциональности он был выпилен в 2000-2002, при разработке ветки 5.x. Остатки потому и лежат, что никому нет дела до той пары драйверов - но и их снесут в течение двух релизов.
даже ZFS просрали.
Работает вовсю.
В следующий раз попробуйте вначале ознакомиться с предметом обсуждения.
Я бы насчёт этого "удобнее" слегка поспорил. Во-первых, удобнее разделять постоянные и временные носители, поэтому в современных линуксах подкаталоги для вторых создаются в /media/$user/, а графические средства типа Dolphin или Windows Explorer это всё равно обобщают. Во-вторых, c динамическими дисками под LDM это уже становится заметно менее важным. В-третьих, как-то не очень смысла спамить общее пространство намонтированными структурами типа того, что в Ubuntu заводятся для каждого снапа... Если бы вместо букв и/или имён дисков была своя иерархия, которая бы позволяла делать что-то вроде /disk/root:/windows/explorer.exe с небольшим количеством алиасов типа root вместо /disk/root, то я бы вполне согласился.
Не-а, там другой механизм. Они не в том же пространстве, что имена дисков, а как бы встроены в любой каталог, причём с любым суффиксом, что само по себе диверсия. В RSX-11 с компанией они логично размещались, например, copy dk0:foo.txt lp0: (не помню точного названия для принтера) давало, что драйверу принтера уходило имя файла (внутри второй аргумент превращался в lp0:foo.txt), он мог выбрать от этого режим печати, нарисовать заголовки и так далее...
И не "поддерживались", а поддерживаются и сейчас, если путь не изначально передан в WinAPI как UNC.
Do not use the following reserved names for the name of a file: CON, PRN, AUX, NUL, COM1, COM2, COM3, COM4, COM5, COM6, COM7, COM8, COM9, COM¹, COM², COM³, LPT1, LPT2, LPT3, LPT4, LPT5, LPT6, LPT7, LPT8, LPT9, LPT¹, LPT², and LPT³. Also avoid these names followed immediately by an extension; for example, NUL.txt and NUL.tar.gz are both equivalent to NUL. For more information, see Namespaces.
Как вам устройство COM¹, неявно присутствующее в любом каталоге? 😱
В UNC режиме (префикс \\?\) этот разбор на такие имена выключается, вместе со многими другими (нельзя /, только \; нельзя относительные пути, только абсолютные).
D2n/1n, D3n/2n - намекает на деление двухразрядного числа на одноразрядное, и на деление 3-разрядного на 2-х )).
Это не то n. Первое означает, например, деление числа в 20000 лимбов на число в 10000 лимбов (или бит, или байт, или слов, любой однородной единицы). Второе - аналогично, например, 90000 на 60000. Алгоритм применяется рекурсивно, пока длина участников не упадёт до уровня, когда выгоднее применять более простой метод. https://github.com/python/cpython/blob/3.14/Lib/_pylong.py#L422
Почему-то нет подробного описания
В русской вики ссылка на оригинальную статью на английском, там, мне кажется, вы поймёте.
В те годы 640 кБ хватало всем, поэтому экономили каждый байт, делая систему минимально достаточной и с разумным заделом на будущее.
RT-11 работала на в десять раз меньшем объёме и при этом позволяла иметь имена дисков до трёх символов, вместо одного, как в CP/M с потомками типа MS-DOS. Поэтому во времена 640kB оправдания этому маразму уже не было.
Но MS-DOS 1.0 должна была работать на системе с 16kB. Вот там ещё можно было подумать...
Кнут потерял актуальность? Это тоже самое, что таблица умножения потеряла актуальность.
Таблица умножения, конечно, потерять актуальность не может. А вот правила, как делать умножение, например, в записи римскими цифрами, с тонкими приёмами, как из IX * IX получить LXXXI, например, имея промежуточную форму XXCI - уже мало кому нужны, кроме особых историков.
Сравнение может показаться жестковатым, но по отношению к TAoCP это так и есть для, наверно, половины классического состава I-III томов. Например, сортировки - почти все 100500 вариантов "внешних" ушли в историю. Надежды на хитрые методы, как Шелла, не оправдались. Во 2-м томе: метод Шёнхаге-Штрассена, который сейчас основной для самых длинных чисел, не разобран подробно даже во 2-м издании (конец 1990-х). Нет Бурникеля-Циглера. Нет представления Монтгомери. Генераторы ППСЧ: нет Xorshift семейства. Нет основ работы с плавающей точкой в современном виде (я даже не призываю вспоминать IEEE754, но то, на чём он основан, должно было войти в описания). Тут можно ещё пару страниц накатать, чего не вошло в TAoCP и не войдёт уже, но присутствует в современных аналогах, но и так уже заметно, я надеюсь.
В CPython для int на больших длинах значений используется алгоритм Бурникеля-Циглера. Это разработка середины 1990-х (я аж удивился, почему так поздно), и имеет логарифмическую сложность (точнее, O(M(N)*log(N)), где M(N) - сложность применённого умножения; для Шёнхаге-Штрассена это O(N*log(N)*log(log(N))). Кнут не смог выйти в своё время за пределы квадратичной сложности, но применил ряд приёмов, которые легли в основу метода Бурникеля-Циглера - нормализация и деление по сокращённой длине. (Потому и удивительно, что потребовалось 30 лет на завершить кусочек логики.)
Терминология у вас, похоже, своя, и запутывающая, и без предварительного знания предмета читать нереально тяжело.
Использование слова "разряд", мало того, что слабо пояснено, так и даёт постоянную путаницу с использованием "разряд" для одного бита, которая здесь типовая. В английском давно известно использование слова limb для данного назначения, см. например, библиотеку GMP.
Далее, откуда "половинчатое деление"? Я понимаю проблему подбора слова, но это как-то очень непонятно: вы в обоих случаях делите, например, 128-битное на 128-битное, но "половинчатое" намекает на половину результата.
Далее, я бы вспомнил архитектуры, где аппаратное деление "косое" (жаргон), как x86 и SystemZ, где может быть 128-битное делимое с 64-битными делителем, частным и остатком, и такие, где оно только равнодлинное (ARM, RISC-V и так далее), например, все по 64. Специфика второго варианта даёт, что фактически там для исходной задачи используется серия делений в "косом" стиле как 64/32. Так как новые архитектуры предпочитают этот вариант (и имеет смысл упомянуть, почему так), то алгоритм усложняется (как вы описывали про "четырёхразрядное" деление в ваших терминах). По современному, имело бы смысл привести готовый код на чём-то легкодоступном (типа Python).
Кнутовский TAoCP, конечно, фундаментален, но основа его книг не менялась как минимум с 1970-х и вряд ли уже поменяется, он давно потерял актуальность и имеет больше историческое значение. Если вы не используете для источников, кроме него, ничего, это в сильный минус.
Меня один банк на букву К блокировал... аж на целую неделю, огромнейший срок;) Не объяснили, почему, разблокировали молча.
У остальных такого не было, но есть одна существенная проблема -- идентификация. Во всех банках приходится её проходить каждые примерно 2-3 года, доказывая, что жив, здоров достаточно, чтобы пройти идентификацию, и документы прежние. Вот тут возникает интересный вопрос, что делать тем, кто и в стране внутри не находится, и Дию (которая позволяет это делать в онлайне) не может поставить (хм). Тут уже могут быть проблемы. Вот если кто-то, как АС, "уклонист", не имеет актуальных документов, не может обновить их в посольстве, тому тяжело. Но чтобы уже сразу с 22-го года получить полную блокировку счетов -- тут практически наверняка какие-то не совсем корректные, мягко говоря, действия были со стороны клиента.
Как-то на тему "мыльности" интерфейсов жёстко зацепились на RSDN. Разумеется, консенсуса в дискуссии не нашлось, но всплыло интересное наблюдение: что отношение к разным стилям рендеринга, сглаживания, подходам к спейсингу и лигатурам сильно зависит от персонального зрения, и в первую очередь от наличия/отсутствия близорукости. Близорукий значительно меньше реагирует на "мыльность", но больше -- на другие факторы. Как по мне (≈-4 и обычные очки на слегка неполную корректировку), наблюдение подтверждается.
Цитата:
Не то чтобы 100%, но имеет смысл как отправная точка для дальнейшего исследования.
Тем не менее в Accessibility настройках винды до сих пор нет соответствующей регулировки, в отличие от массы других настроек типа ярких траекторий мыши.
Поставил плюс только за картинки:) Для них явно потребовалось больше работы, чем мог себе вообразить в самом сложном случае:)
Ваше слепое высокомерие не даёт вам потратить две минуты и убедиться, что для большей части функциональности он был выпилен в 2000-2002, при разработке ветки 5.x. Остатки потому и лежат, что никому нет дела до той пары драйверов - но и их снесут в течение двух релизов.
Работает вовсю.
В следующий раз попробуйте вначале ознакомиться с предметом обсуждения.
Не перестанут, пока это по сути единственная альтернатива Linux. Вторая система нужна хотя бы для адекватного развития первой.
Гадать не надо. Команда
mountрасскажет всё что надо.В Unix тоже.
Точно так же, с учётом поддеревьев.
Если хочется залезть в эти детали -
mountдаёт список текущих монтирований. В случае LVM соответственно рассматривается, что входит в volume group.(повторюсь) Алиасы не обязаны были следовать этому. И вот это как раз было ценно для независимости от физических имён.
А алиасы были произвольными.
Я бы насчёт этого "удобнее" слегка поспорил. Во-первых, удобнее разделять постоянные и временные носители, поэтому в современных линуксах подкаталоги для вторых создаются в
/media/$user/, а графические средства типа Dolphin или Windows Explorer это всё равно обобщают. Во-вторых, c динамическими дисками под LDM это уже становится заметно менее важным. В-третьих, как-то не очень смысла спамить общее пространство намонтированными структурами типа того, что в Ubuntu заводятся для каждого снапа...Если бы вместо букв и/или имён дисков была своя иерархия, которая бы позволяла делать что-то вроде
/disk/root:/windows/explorer.exeс небольшим количеством алиасов типаrootвместо/disk/root, то я бы вполне согласился.О каких трёх буквах речь? (чисто интересно)
Не-а, там другой механизм. Они не в том же пространстве, что имена дисков, а как бы встроены в любой каталог, причём с любым суффиксом, что само по себе диверсия. В RSX-11 с компанией они логично размещались, например,
copy dk0:foo.txt lp0:(не помню точного названия для принтера) давало, что драйверу принтера уходило имя файла (внутри второй аргумент превращался вlp0:foo.txt), он мог выбрать от этого режим печати, нарисовать заголовки и так далее...И не "поддерживались", а поддерживаются и сейчас, если путь не изначально передан в WinAPI как UNC.
Зацените:
Как вам устройство COM¹, неявно присутствующее в любом каталоге? 😱
В UNC режиме (префикс
\\?\) этот разбор на такие имена выключается, вместе со многими другими (нельзя /, только \; нельзя относительные пути, только абсолютные).Это не то n. Первое означает, например, деление числа в 20000 лимбов на число в 10000 лимбов (или бит, или байт, или слов, любой однородной единицы). Второе - аналогично, например, 90000 на 60000. Алгоритм применяется рекурсивно, пока длина участников не упадёт до уровня, когда выгоднее применять более простой метод.
https://github.com/python/cpython/blob/3.14/Lib/_pylong.py#L422
В русской вики ссылка на оригинальную статью на английском, там, мне кажется, вы поймёте.
&- 0x26, не входит в диапазон 0x40-0x5F. Вы имели в виду обратную косую?В нативных приложениях Windows убили раздельные текущие каталоги на каждом диске, оставив только один на все диски.
RT-11 работала на в десять раз меньшем объёме и при этом позволяла иметь имена дисков до трёх символов, вместо одного, как в CP/M с потомками типа MS-DOS. Поэтому во времена 640kB оправдания этому маразму уже не было.
Но MS-DOS 1.0 должна была работать на системе с 16kB. Вот там ещё можно было подумать...
Таблица умножения, конечно, потерять актуальность не может. А вот правила, как делать умножение, например, в записи римскими цифрами, с тонкими приёмами, как из IX * IX получить LXXXI, например, имея промежуточную форму XXCI - уже мало кому нужны, кроме особых историков.
Сравнение может показаться жестковатым, но по отношению к TAoCP это так и есть для, наверно, половины классического состава I-III томов. Например, сортировки - почти все 100500 вариантов "внешних" ушли в историю. Надежды на хитрые методы, как Шелла, не оправдались. Во 2-м томе: метод Шёнхаге-Штрассена, который сейчас основной для самых длинных чисел, не разобран подробно даже во 2-м издании (конец 1990-х). Нет Бурникеля-Циглера. Нет представления Монтгомери. Генераторы ППСЧ: нет Xorshift семейства. Нет основ работы с плавающей точкой в современном виде (я даже не призываю вспоминать IEEE754, но то, на чём он основан, должно было войти в описания). Тут можно ещё пару страниц накатать, чего не вошло в TAoCP и не войдёт уже, но присутствует в современных аналогах, но и так уже заметно, я надеюсь.
В CPython для int на больших длинах значений используется алгоритм Бурникеля-Циглера. Это разработка середины 1990-х (я аж удивился, почему так поздно), и имеет логарифмическую сложность (точнее,
O(M(N)*log(N)), гдеM(N)- сложность применённого умножения; для Шёнхаге-Штрассена этоO(N*log(N)*log(log(N))).Кнут не смог выйти в своё время за пределы квадратичной сложности, но применил ряд приёмов, которые легли в основу метода Бурникеля-Циглера - нормализация и деление по сокращённой длине. (Потому и удивительно, что потребовалось 30 лет на завершить кусочек логики.)
Терминология у вас, похоже, своя, и запутывающая, и без предварительного знания предмета читать нереально тяжело.
Использование слова "разряд", мало того, что слабо пояснено, так и даёт постоянную путаницу с использованием "разряд" для одного бита, которая здесь типовая. В английском давно известно использование слова limb для данного назначения, см. например, библиотеку GMP.
Далее, откуда "половинчатое деление"? Я понимаю проблему подбора слова, но это как-то очень непонятно: вы в обоих случаях делите, например, 128-битное на 128-битное, но "половинчатое" намекает на половину результата.
Далее, я бы вспомнил архитектуры, где аппаратное деление "косое" (жаргон), как x86 и SystemZ, где может быть 128-битное делимое с 64-битными делителем, частным и остатком, и такие, где оно только равнодлинное (ARM, RISC-V и так далее), например, все по 64. Специфика второго варианта даёт, что фактически там для исходной задачи используется серия делений в "косом" стиле как 64/32. Так как новые архитектуры предпочитают этот вариант (и имеет смысл упомянуть, почему так), то алгоритм усложняется (как вы описывали про "четырёхразрядное" деление в ваших терминах). По современному, имело бы смысл привести готовый код на чём-то легкодоступном (типа Python).
Кнутовский TAoCP, конечно, фундаментален, но основа его книг не менялась как минимум с 1970-х и вряд ли уже поменяется, он давно потерял актуальность и имеет больше историческое значение. Если вы не используете для источников, кроме него, ничего, это в сильный минус.
Это должны быть не буквы, а имена произвольной длины (хотя бы до 8 символов).