Вкратце: маячки AirTag, цветные iMac, iPad Pro на M1 и другие анонсы Apple с первой презентации в 2021 году Статьи редакции

То, что у тебя были проблемы с виндой не говорит о том, что у всех проблемы с виндой. Ещё не известно какой софт ты юзаешь.

Где аргументация то?) Я вот хз, как микроядерная система с IPC, завязанном на копировании (технически там COW, но легче сильно от этого не становится) и  сложной обработкой page faults может прям супер результаты показывать. И я не видел на практике, чтобы показывала, хотя маки почти непрерывно были с 2007 года. И не смог найти ничего, чтобы хоть как-то подтверждало твои слова, хотя честно пытался.

Ну во-первых, OS X не микроядерная и не понятно при чем тут IPC.
Во-вторых, COW везде. И Windows и Linux использует COW.
В-третьих, есть ты не ходишь на диск, то ты всегда выигрываешь. Этим и пользуется OS X. Она сначала пытается сжать инактивные страницы и только потом свапит их на диск в крайнем случае. Результаты показательны. Сейчас лень искать, выигрыш при переходе на бенчмарках был x3.

На практике у меня запущены CLion + GoLand + Idea + Safari + FF + Wireshark + Parallels с Linux в котором запущен Quartus и при этом я могу свободно смотреть сериальчики в 4k.

Ребята вернитесь на хабр, а то мы тут перестаем казаться умными.

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

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

https://developer.apple.com/library/archive/documentation/Darwin/Conceptual/KernelProgramming/Architecture/Architecture.html#//apple_ref/doc/uid/TP30000905-CH1g-CACDAEDC

Будешь спорить с документацией?

https://developer.apple.com/library/archive/documentation/Darwin/Conceptual/KernelProgramming/Mach/Mach.html#//apple_ref/doc/uid/TP30000905-CH209-CEGBBEBF

В OS X IPC не используется как в микроядрах в виде прерываний, которые шедулят сообщения для других user space сервисов, отвечающих за драйверы или другие компоненты микроядра.

В Linux нету, в Windows тормозит. В чем ржака?

Чё?) Сори, реально не понял, что ты имеешь ввиду :)

Там наворочено много рандомной херни в кестах, которая все еще общается с юзер спейсом по IPC. При этом просто дорогие ядерные вызовы становятся в среднем ппц какими дорогими. Ну и там много граблей наворочено еще для того, чтобы прикинуться позиксом. 

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

С 3.14 в ядре, с 4.4 включена по дефолту в андроиде.

Когда у тебя memory pressure - она везде тормозит. Мак не исключение. Когда у тебя хватает памяти - она везде работает нормально.

В микроядрах привилегированные операции исполняются в виде IPC сообщений, которые передаются такому же сервису в юзер спейсе. В OS X ядро само берет на себя эти функции как в монолитных ядрах. Это как раз и есть тот слой BSD.

Если речь идет о https://developer.apple.com/documentation/driverkit, то да. kext и dext разные вещи. И это как раз еще раз подтверждает то, что OS X не микроядро. Микроядро гарантирует, что падение драйвера условного RS232 плоттера не приведет к падению всей ОС. В Linux, OS X, Windows это не так.

https://lwn.net/Articles/545244/ это скорее блочное устройство с возможностью сжатия, на котором располагается своп, а не встроенный в ОС механизм сжатия.

Так а в чем разница? И там и там  делается swap out, просто обратно в память и она пожата :)

Они юзерспейсовые

syscall/sysctl очень лимитированные в макоси. Особенно syscall. Остальное - IPC. Не вижу большой разницы, с юзерспейсом сервисом и ядерным сервисом, если механизм, в целом, один и тот же :)

OS X реальную память жмет и не сразу кладет на диск. Здесь только вариант сжать то что пошло на диск.

Да, но все низкоуровневое живет в kext.

Ну т.е. не смущает, что основные IO операции работают как в монолитном ядре? Ну т.е. чуваки назвали свое ядро гибридным потому, что есть часть микроядра и часть монолитного ядра. Не?

Да даже на дефолтных настройках vm.swappiness все будет работать +/- точно также :) Inactive страницы будут сжиматься :) Как там называются конкретные абстракции - дело десятое.

Изначально дискуссия начиналась с того, что у макоси работа с ядром значительно построена поверх IPC, что унаследовано от микроядра OSFMK 7.3 (aka Mach 4). Причем macOS дальше всех подходы Mach и развила. Остальные поняли, что это дно и вернулись к истокам :) Есть гипотеза, что не просто так и не потому, что все остальные тупые.

То, что в ядро унесены сеть и FS не влияет на то, как организованно взаимодействие между ядром и юзер спейсом. Ни по скорости работы, ни по эффективности работы с памятью. Просто системой становится возможно пользоваться :)

BSD вызовы, за которые ты так топишь, в macOS сильно отличаются. Причем не только номерами :) В целом, BSD слой просто упрощает портирование, те же потоки живут поверх примитивов микроядра. 

Ну построено-то оно может быть хоть на QNX. Микроядром от этого оно не станет, если есть костыль сбоку. Микроядерные ОС сложны в реализации и в большинстве своем просто не оправдывают затрат. На HN был тред про чувака, который рассказывал про то как они локи делали в IBM в микроядерной ОС и как это все упиралось в процессор. Ну и можно вот этот пост почитать https://blog.darknedgy.net/technology/2016/01/01/0/ Там много всего.

Ну на специфичном железе QNX норм живет. Я не знаю что изменилось за 15 лет, кроме того, что они переползли на телефоны. В целом от QNX не было плохих ощущений.

Конечно влияет. Нужно же копировать память из кернел спейса в юзер спейс. Тот же sendfile в Linux не просто так изобрели.

Было бы странно, если бы оно не отличалось от 4.4BSD или от FreeBSD. Прошло уже не мало лет. Я когда общался по поводу того, чтобы может быть заскочить к ребятам пописать XNU одним из требуемых скиллов как раз было знание ядра FreeBSD.

Тогда не было этого обсуждения :)

Так между QNX и Mach ничего общего и нет. У эпла была тенденция брать разработки из академии и почти не адаптируя пихать их людям :) To bad, что в реальном мире это не работает.

Ну все еще нужно, what's the point?) Прям вот нужно. Никаких тебе человеческих мапов памяти ядра в юзерспейс :)

Ну QNX POSIX совместимая и полностью микроядерная.

И как мне замапить память в OS X, чтобы она была доступна на запись из юзер спейса?

а как под разные проекты разное окружение настраивать и разные версии?

Конкретно в мампе всё делается просто выбором из списка.

в мампе есть редис? в мамке есть кафка? Я в мампе могу поднять 2 ноды? Я не говорю про отдельно рнр я говорю про окружение в целом и если для вордпресса, который на сайте мампа в каждом предложении упоминается еще есть какой то смысл его ставить, то для проекта чуть повыше уровнем чем коробочная cms уже увы, надо докер.

Редис есть, но если вернуться к изначальному комменту, то «по некоторым проектам», кажется снимает вопросы. Не?

По некоторым да. Но мне кажется для некоторых вообще все на маке просто поднять можно. 

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

Бля, чел, ты тут давай тёплое с мягким не путай. Речь идёт не о проде, а о локальной разработке для которой мамп довольно удобная штука без лишней ебли.

если говорить о том что надо локально запустить php, то увы, проще поставить мамп, одной кнопкой и работать. Чем тянуть контейнеры, пробрасывать порты, тома, закидывать туда конфиги. Другой разговор что у тебя уже есть опыт и под разные задачи уже есть все собранное, только конфиги меняй, тут да. Все это вопрос в первую очередь задачи.

Я так понимаю что вы ядро на никсе собирали тоже сами? или как макака поставили с коробки? там делов то херня.

это здесь причем? Речь о поставке и запуске софта. 

Речь о простоте установки для человека. Мне на данный момент тоже не составляет труда все что нужно стянуть и завернуть в окружение, но это не значит что это всем удобно, не так ли?

как в scala, например, которая внутри использует Java concurrency model. У жабки отбитый апи для многопоточности и стримов. 

Оу, скала, ну понятно :-) Один раз видел её на продакшене, оказалось дешевле во всех смыслах переписать на Go :)

вы еще не поняли, что натворили

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

omg, про native image и graalVM вам в ваших джунглях, видимо, не рассказывали. Про выжрать память - так вы безрукие. Дешевый... ну-ну, учитывая ЗПшечки гошников и их количество на рынке. 

есть множество альтернатив ПХП. ПХП пригоден для rm -rf *.php

Пока MMU не станет на лету отдавать данные с пожатых страниц счастья не будет.

https://github.com/AsahiLinux/docs/wiki/HW:Apple-Instructions вот как бы инструкции для сжатия страниц. В общем-то счастье уже есть.

Compress Page/Uncompress Page.

Счастье наступит, когда гранулярность уровня кеш линии будет. Или каким-то другим образом адрес можно будет отобразить прямо в пожатую страницу и прочитать с неё.

А пока ядро все равно должно найти пустую страницу, куда делать uncompress. Если память есть - то это будет работать фантасически быстро, что на M1 и видно. Если памяти нет - то особо и разницы нет. Всякие LZ4 и так быстрее памяти и диска.

Кэш линии чего? Иструкций? Данных? Так то можно зафигачить кэш в 10 Гб, правда тогда покупать макбуки будут только миллионеры, ибо один CPU будет стоить пару сотен тысяч долларов. Сейчас же проблема в балансировании объема/стоимости продукта, а не в том, чтобы запихнуть туда огромный кэш.

Там еще и эвекшен страниц надо делать умный. Но как бы это все не отменяет того, что техника Apple в текущей конфигурации дает возможность комфортнее работать с меньшим объемом задач. Думаю если посмотреть распределение нагрузки, то у большинства пользователей техники будет 100500 процессов и только один, который потребляет основной объем.

Я вот прямо хз, как ты решил, что я про увеличение кеша. Я про то, что счастье наступит, если при cache miss MMU сможет читать с пожатой страницы :) Сейчас, очевидно, это не так. Иначе вся user space память, была бы пожатой :)

Ох уж этот умный эвикшен. И что умного они изобрели?

Меня вот все убеждают, что с большим :)  А тут оказывается с меньшим. Ну тогда не удивительно :)

Я не решал. Я говорю о том, что логичнее не жать, а использовать большой объем, чтобы все влезало.

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

Я опечатался.

Вот я опять запутался. То ты меня убеждаешь, что жать хорошо, то оказывается логичнее использовать больший объем в железе. В чем твоя позиция в итоге?

Тогда зачем пишешь про умный эвикшен?) Когда кончалась память на маке, я обычно тупо зажимал кнопку питания, дождаться когда их менеджер памяти закончит свою умную работу терпения ни разу не хватило. Я охотно верю, что на M1 все лучше, но при этом есть утверждение, что там очень агрессивная запись на диск. Я не разделяю истерики про то, что SSD быстро сдохнет, но факт есть факт. Куда делся умный менеджер?)

Сжимать страницы пока самый дешевый вариант. Больший объем даже наша контора не сможет себе позволить закупить.

Потому, что эту задачу еще нужно решить.

зачем? для чего? Это как писать ПХП код на маке. Вам надо объединиться с с другой пхп-макакой, которая в этом чате пробегала.
Это бытовой компьютер. Купи себе прошку и решай бессмысленные синтетические задачи.