Ваше слепое высокомерие не даёт вам потратить две минуты и убедиться, что для большей части функциональности он был выпилен в 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-х и вряд ли уже поменяется, он давно потерял актуальность и имеет больше историческое значение. Если вы не используете для источников, кроме него, ничего, это в сильный минус.
Исходно эта схема с одной буквой получена упрощением той, что была в операционных системах RSX-11 и родственных, где название диска могло содержать до 3 символов не считая двоеточия, например, DK0:, SY:, и алиасы были штатным свойством (SY был алиасом на системный диск). Когда делалась CP/M, уплощили до одной. Потом не вернули обратно всё время жизни DOS и Windows. Вот это действительно неудобно, букв слишком мало и в них слишком легко получить конфликты.
Unix система хороша, но не напрямую одной иерархией: внутри она совершенно не обязательно одна. С современными средствами можно, например, запустить процесс, у которого корнем будет /opt/foo хозяйской системы, а /var/db/foo будет доступен через отдельный дескриптор, и все доступы надо будет делать относительно него через *at() вызовы, как openat(), mkdirat() и тому подобные. В Windows так не работало бы: Windows внутри всегда требует полного пути и итерирует от общего корня.
Зачем монтировать диск в одно дерево и прятать где-то внутри структуры папок? Бред же.
Бред или нет, а в Windows это сделали, причём ещё менее понятно, по ссылке описано. Одна иерархия, в которой \\?\ задаёт, что дальше будет файл из файловой системы, а за пределами этого поддерева разные спецобъекты.
Вы, оказывается, отвечаете не кнопкой ответа, я случайно заметил. Если вас интересует продолжение дискуссии, пользуйтесь кнопкой "Ответить".
В цитате, которую Вы комментировали завершив эти утверждением, ничего такого нет. Наоборот, МФ-щики прекрасно встроились в ИТ на писюках.
Зато в личном опыте такое есть, знаю нескольких человек. Не все встроились.
Глядя на Ваш профайл на Хабре, я не вижу что Вы постоянно переучиваетесь. У меня, например, список скилсов на писюках побольше Вашего будет, не считая МФ-ских скилсов, количество которых за время работы только в Канаде упятерился.
1) Я не пишу туда совсем всё, что умею и когда-то делал. Некоторые вещи нет смысла писать, они покрываются общим умением. 2) Развитие возможно и в пределах одного пункта. Вообще, мне эти меряния органами не очень интересны, скажу лишь, что радикально менял направление, наверно, раз пять.
"Некоторые" свойства железа реализуются соответствующими механизмаи операционной системы zOS.
Вы не представляете себе, какие свойства я имел в виду, но говорите про zOS.
И какие, по-вашему, суперсвойства zOS тут настолько важны?
Ваше слепое высокомерие не даёт вам потратить две минуты и убедиться, что для большей части функциональности он был выпилен в 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 символов).
Исходно эта схема с одной буквой получена упрощением той, что была в операционных системах RSX-11 и родственных, где название диска могло содержать до 3 символов не считая двоеточия, например, DK0:, SY:, и алиасы были штатным свойством (SY был алиасом на системный диск). Когда делалась CP/M, уплощили до одной. Потом не вернули обратно всё время жизни DOS и Windows. Вот это действительно неудобно, букв слишком мало и в них слишком легко получить конфликты.
Unix система хороша, но не напрямую одной иерархией: внутри она совершенно не обязательно одна. С современными средствами можно, например, запустить процесс, у которого корнем будет /opt/foo хозяйской системы, а /var/db/foo будет доступен через отдельный дескриптор, и все доступы надо будет делать относительно него через *at() вызовы, как openat(), mkdirat() и тому подобные. В Windows так не работало бы: Windows внутри всегда требует полного пути и итерирует от общего корня.
Бред или нет, а в Windows это сделали, причём ещё менее понятно, по ссылке описано. Одна иерархия, в которой
\\?\задаёт, что дальше будет файл из файловой системы, а за пределами этого поддерева разные спецобъекты.Вы, оказывается, отвечаете не кнопкой ответа, я случайно заметил. Если вас интересует продолжение дискуссии, пользуйтесь кнопкой "Ответить".
Зато в личном опыте такое есть, знаю нескольких человек. Не все встроились.
1) Я не пишу туда совсем всё, что умею и когда-то делал. Некоторые вещи нет смысла писать, они покрываются общим умением. 2) Развитие возможно и в пределах одного пункта. Вообще, мне эти меряния органами не очень интересны, скажу лишь, что радикально менял направление, наверно, раз пять.
Вы не представляете себе, какие свойства я имел в виду, но говорите про zOS.
И какие, по-вашему, суперсвойства zOS тут настолько важны?