• OS1: примитивное ядро на Rust для x86. Часть 3. Карта памяти, Page fault exception, куча и аллокации
    0
                chunk_count = size / KHEAP_CHUNK_SIZE;
                if KHEAP_CHUNK_SIZE * chunk_count != size {
                    chunk_count += 1;
                }

    Можно
    chunk_count = (size + KHEAP_CHUNK_SIZE - 1) / KHEAP_CHUNK_SIZE;
  • Микроядро seL4. Формальная верификация программ в реальном мире
    +1
    Какое отношение это имеет к доказательству корректности какой-либо конкретной программы?
  • Микроядро seL4. Формальная верификация программ в реальном мире
    0
    Так оно и будет для однопоточных, детерминированных, нераспределенных (т.е. тривиальных) программ.
  • Kronos: никаких путешествий во времени даже в распределенных системах
    0
    > векторные часы обладают неприятными свойствами: они вводят условную зависимость между событиями там, где ее нет, и теряют ее там, где она на самом деле есть.

    Если размер вектора равен числу процессов, то векторные часы точно отражают зависимости в системе.

    > Несуществующие зависимости возникают потому, что логические часы вводят полный порядок на событиях

    Показания векторных часов только частично упорядочены.
  • Обработка ошибок в Go 2
    –1
    handle err {… } это возрожденный ON-unit из PL/I? Казалось бы отцы-основатели структурного программирования высмеяли такие штуки навсегда, но нет.
  • Наконец появилась задача, которую смогут решить только квантовые компьютеры
    0
    Статья (или перевод) вводит в заблуждение. Классический компьютер, т.е. (детерминированная) машина Тьюринга, может решить любую задачу решаемую квантовым компьютером. В cтатье (или опять же, в переводе) утеряна разница между «решаемо» и «эффективно решаемо», и между «computability» и «complexity».
  • Законы рефлексии в Gо
    +1
    > и хотя во время выполнения значение, хранящееся в переменной интерфейса, может изменять тип, это значение всегда будет удовлетворять интерфейсу. (Никаких undefined, NaN и прочих ломающих логику программы вещей.)

    Во-первых, переводчик улучшил Пайка, добавив предложение в скобках. :-) Во-вторых, переменная интерфейсного типа может хранить nil — значение не удовлетворяющее интерфейсу и ломающее логику.
  • Что у программы между строк
    –1
    «Сильный» программист, наверное, заметит, что команды X(номер, цвет) для разных значений параметра «номер» коммутативны (могут выполняться в произвольном порядке), а для одинаковых — нет. Это наблюдение сразу дает все три варианта A, B и C. Ну и по завету Дейкстры («детерминизм — частный случай недетерминизма»), напишет параллельную программу, для которой ABC являются сериализациями.
  • Мой любимый алгоритм: нахождение медианы за линейное время
    0
    А почему pivot выбирается именно как элемент массива с некоторым индексом? В случае quicksort это понятно, но для quickselect можно выбрать любое значение (не обязательно из массива). Например, брать среднее (O(n)), тогда массив будет гарантированно хорошо делиться.
  • Удвоена производительность жестких дисков: технология Multi Actuator
    +1
    Считывать с нескольких блинов одновременно невозможно. Дорожки не расположены точно друг над другом (невозможно при современных плотностях записи). После позиционирования на цилиндр, головка делает более точное позиционирование на дорожку на конкретном блине, при этом дорожки на остальных блинах недоступны.
  • Разбираемся с новым sync.Map в Go 1.9
    +2
    Mutex.Lock() гарантировано содержит атомарную операцию, т.е. cache transfer там точно будет.
  • Управление памятью в Python
    +3
    Вывод show_sizeof() не соответствует коду: нет x.__class__.
  • NIST наконец-то меняет рекомендации по паролям: теперь рекомендуются длинные парольные фразы
    0
    В Ситибанке несколько лет назад для защиты от keylogger-ов пароль вводился через «виртуальную клавиатуру» (т.е. на сайте надо было мышкой кликать в нарисованные буковки), и на этой клавиатуре не было смены регистра. Клавиатура давно пропала, на пароли, ясно дело, остались с тех пор case insensitive.
  • Быстрое восстановление данных. Чем нам помогут LRC?
    0
    Так как поддерживается восстановление 2 блоков на страйп, то, наверное, каждый страйп должен содержать 2 Empty блока?
  • Быстрое восстановление данных. Чем нам помогут LRC?
    0
    Такие технологии становятся по-настоящему полезными только когда данные разнесены не только по устройствам на одной машине, но и по многим машинам в сети. Сетевой RAID сложно сделать на аппаратном уровне (как говорит raidixteam слишком гибкие конфигурации).
  • Сортировка пузырьком в коде Qualcomm
    +1
    X | A | B = (!A | A) | (B | !B) | !C = true | true | !C = true
  • Игры, в которых нужно писать код: Grid Garden, Elevator Saga и другие
    +1
  • Быстрое вычисление факториала — PrimeSwing
    0
    «в примарном разложении» — должно быть «в разложении на простые множители». «Примарное разложение» это немного другое (см. теорему Ласкера).
  • Интел усиливает позиции в HPC
    +1
    Ха, точно. Мир тесен.
  • Интел усиливает позиции в HPC
    0
    Первое, что я сделал для Люстры был OSX клиент, но он так и не был выпущен, потому что Apple поменял VFS интерфейс в следующей версии Дарвина. Потом было много чего: новый сервер мета-данных (http://wiki.lustre.org/images/b/b8/LUG08-head-mds-danilov.pdf), новый клиентский IO стек (http://wiki.lustre.org/images/6/66/CLIO-TOI.pdf) и пр. Про новую систему (Mero) есть обзор: http://www.pdsw.org/pdsw-discs16/wips/danilov-wip-pdsw-discs16.pdf.
  • Интел усиливает позиции в HPC
    0
    Я занимался Люстрой в 2004-2009, потом другой системой, для exascale.
  • Интел усиливает позиции в HPC
    0
    Из упущенного: DAOS, http://storageconference.us/2015/Presentations/Gorda.pdf.
  • Производительность сети малой латентности InfiniBand на виртуальном кластере HPC HUB
    0
    «Intel Infiniband»… Intel, конечно, всему голова, но стандарт просто Infiniband. :-)
  • Lock-free структуры данных. Concurrent map: разминка
    0
    Да, при прочих равных лучше в каноническом порядке отпускать локи. Меня просто смутила формулировка в статье. Статьи отличные, кстати. Спасибо.
  • Lock-free структуры данных. Concurrent map: разминка
    +1
    Вы можете описать ситуацию, когда неправильный порядок *разблокировки*, т.е. отпускания мьютексов, приводит к проблемам? Ситуации, когда { unlock(A); unlock(B); } корректно, а { unlock(B); unlock(A); } ведет к deadlock-y?
  • Lock-free структуры данных. Concurrent map: разминка
    0
    > и, наконец, разблокируем все мьютексы в обратном порядке — справа налево. Не забываем, что основная причина deadlock – несоблюдение порядка блокировки/разблокировки нескольких мьютексов.

    Разве порядок разблокировки может быть причиной deadlock? «Неправильная» разблокировка (слева направо, в данном случае) может привести к образованию конвоя или thundering herd, но никак не к deadlock-у.
  • Расширения языков C и C++. Часть 1
    0
    > Вы, похоже, пытаетесь выкрутиться из ситуации, придираясь к слову «разыменование».
    В моих комментариях, которые вам необходимо перечитать, с самого начала и неоднократно было указано, что я понимаю «разыменование», как применение unary operator *. Каким образом вы его понимаете — до сих пор непонятно.

    > Но это не так важно, ибо соответствующий раздел — «informative», а не «normative».
    Есть другие примеры undefined behaviour, которые авторы решили не включать в этот список, или это удивительное исключение?
  • Расширения языков C и C++. Часть 1
    0
    > Речь в данном разговоре идет о формальной легальности конструкции (size_t)&(((s *)0)-›m)
    Очень жаль, что вы все время об этом разговаривали, потому что я, как как и было написано в моем первом сообщении, говорю о том, что в этой конструкции нет разыменования (т.е. применения unary *), вне зависимости от того, легальна ли вся конструкция.

    Например (приходится повторить), в конструкции A[B] есть разыменование, потому что стандарт явно определяет ее как (*(A+B)). Для конструкции A->B такого сведения нет. Вы, кажется, пользуетесь каким-то своим неформальным пониманием разыменования, не определив его явно.

    > И этк конструкция — нелегальна, ибо содержит применение оператора -> к указателю, не являющемуся указателем на объект.
    Вы можете процитировать соответствующий пункт из списка undefined behaviours в конце стандарта?
  • Расширения языков C и C++. Часть 1
    0
    > Наоборот 6.5.3.2/1 это запрещает.
    Где конкретно? Там явно написано «The operand of the unary & operator shall be [...] unary * operator» и никаких ограничений на аргумент * нет, т.е. явно разрешается &(*(X)) для произвольного X.

    Что значит «предотвращает запрещенное разыменование»? Стандарт просто отмечает, примечанием, что результат &(*0) должен быть 0, там ничего не говорится ни про какую «аннигиляцию».

    > Оператор -> — это разыменование указателя.
    Смешались в кучу кони, люди. :-)

    С точки зрения стандарта, -> это не разыменование, семантика -> описана специальным образом (6.5.2.3), но стандарт гарантирует, что при некоторых условиях (X)->Y эквивалентно (*(X)).Y (примечание 69).

    С неформальной точки зрения, offsetof(A, B) это просто константа компиляции, и никакого разыменования, т.е. обращения к памяти, ее вычисление не требует.

    > На такой платформе такая реализация offsetof работать не будет.
    С этим никто не спорит, у offset() есть и гораздо менее экзотические проблемы. И также понятно, что традиционная реализация вызывает undefined behaviour. Но вовсе не из-за отсутствующего там разыменования, а потому, что семантика A->B стандартом не сводится к арифметике над указателями (в отличие от семантики A[B]).

  • Расширения языков C и C++. Часть 1
    0
    Обычный offsetof() может привести к undefined behaviour, когда применяется как offsetof(struct foo, array[n]), где n — больше числа задекларированных элементов в поле-массиве. Типичная ситуация: массив нулевой длины в конце структуры, фактически память под массив выделяется при аллокации.
  • Расширения языков C и C++. Часть 1
    0
    Во-первых, применять адресную арифметику к null pointer стандартом C явно разрешено (см. C99, 6.5.3.2, особенно примечание 74, где явно указано, что даже разыменование нулевого указателя бывает законно). Во-вторых «разыменование null pointer» это применение операции разыменования (unary * operator) к нулевому указателю, а в макросе offsetof() такая операция просто-напросто отсутствует: этот макрос ничего не разыменовывает.
  • Расширения языков C и C++. Часть 1
    0
    > А между тем еще в Турбо Паскале была возможность вкладывать одни функции в другие.
    Как уточнение: вложенные функции были в Паскале с самого начала и, вообще, присутствуют почти во всех языках, происходящих от Алгола-60, C здесь как-раз исключение.

    > Однако, это является неопределенным поведением по стандарту Си (из-за разыменования нуля)
    offsetof() NULL не разыменовывает, он выполняет арифметические операции над NULL-pointer, что совершенно законно.

  • Советские «Эльбрусы» — обзор архитектуры
    +1
    Да, он его изобрел и использовал в компиляторе Алгола-60.
  • Советские «Эльбрусы» — обзор архитектуры
    +1
    > Этот механизм в чем-то похож на уровень привилегий х86.
    Этот массив дескрипторов называется Dijkstra display: http://cs-exhibitions.uni-klu.ac.at/index.php?id=4&uid=9.
  • Дональд Кнут: как я занялся анализом алгоритмов и ради этого поехал в СССР (37,91,97/97)
    +1
    > 'direction'(*расстояние с англ.)
    «Направление».
  • Создание разделяемого хранилища на базе CEPH RBD и GFS2
    +1
    > Однако такая конфигурация обладает рядом свойств, которые сильно затрудняют работу с ней в случае, когда клиенты используют независимые виртуализированные кластера.

    Вы не могли бы пояснить, какие проблемы у Люстры в такой конфигурации?
  • Не все языки программирования одинаково полезны
    +1
    На отсканированных листочках «программирования в машинных кодах, без ассемблера» не видно, там обычный ассемблер.

    Кроме того, Алгол-68 (на котором приведен пример) и Алгол-60 это совершенно разные языки.
  • Пишем изящный парсер на Питоне
    0
    В BNF нужно заменить "," на "','".
  • История языков программирования: как Haskell стал стандартом функционального программирования
    +2
    Лисп изначально основан на теории рекурсивных функций, а не на лямбда исчислении.
  • Разбираемся в Go: пакет io
    0
    Почтальон звонит (дважды). :-)