Признаюсь, было искушение. Но побоялся оскорбить чьи-либо чувства. Нынче с этим нужно аккуратнее. Ну а в целом, изначально зацепился за книгу. А за ней оказалась целая история, причем, живых и активных в отрасли людей. Все не зря.
Это вопросы масштаба. Как и любой другой код, код ядра содержит уязвимости разного кода. Уязвимости в коде не находят тогда, когда им не пользуются. Как и код Windows, код ядра распространен настолько широко и используется в настолько разных сценариях, что баги и уязвимости в нём находятся часто. Как сказал Глеб Жеглов, «Правопорядок в стране определяется не наличием воров, а умением властей их обезвреживать!».
Код ядра, подход коммюнити к разработке, подход к релизам (http://kroah.com/log/blog/2018/02/05/linux-kernel-release-model/) предоставляют всё, что нужно разработчикам, чтобы минимизировать количество подобных проблем.
Качество кода — понятие субъективное, как я упомянул в начале статьи, у каждого разработчика свои примеры. Лично мне код ядра нравится и работать с ним было приятно, но дело не в этом. Этот код не идеален. Но это код, над которым работает, наверное, одно из самых больших и активных сообществ разработчиков. И это код, который, думаю, работает на наибольшем количестве устройств в мире. Я не могу с лету придумать другой пример кода, который работал бы в данный момент времени на сопоставимом количестве процессоров (я имею в виду процессоров в целом, всего, в мире), как код ядра Линукс. Это говорят о качестве кода и его сопровождаемости — плохой, некачественный код, который тяжело сопровождать, не получил бы такого распространения.
Когда я спрашивал HR на эту тему, коллеги говорили, что если это не носит системный характер и чередовалось относительно продолжительными периодами работы (год и более), то ок. Если из трёхлетки 10 мест работы, то явно напряжёт, хотя и тут многое зависит от работодателя. Если позиция горит, а задача срочная, то могут взять при наличии нужных навыков и опыта.
Коллеги из DaisyDisk прислали комментарий по теме.
Я Олег Крупнов, разработчик программы DaisyDisk, упоминаемой в статье.
Действительно, новая файловая система APFS обладает некоторыми
особенностями, которые часто вызывают недоумение у пользователей, хотя
и редко являются проблемой.
В частности, при удалении файлов свободное место не появляется
мнговенно. В статье правильно написано, что это происходит из-за
временных архивов, так называемых «локальных снимков» (local
snapshots) Time Machine. Файлы физически остаются на диске после
удаления, поскольку локальные снимки на них по-прежнему ссылаются. Эти
снимки составляют львиную долю так называемого «очищаемого
пространства» (purgeable), отображаемого в Finder и Disk Utility в
скобочках после свободного места. Эти локальные снимки существовали и
в предыдущих версиях macOS (в скрытой папке /.MobileBackups), но в
APFS они расположены вообще за пределами доступной пользователям части
диска – действительно, как будто в «черной дыре».
По идее, macOS должна автоматически удалять старые local snapshots в
случае если места на диске становится меньше 20%. Например, в Finder,
при копировании большого файла с внешнего диска в условиях почти
заполненного диска происходит практически мгновенное удаление старых
«снимков».
В описанном случае с iTunes и Disk Utility этого не происходит, видимо
потому, что перед началом операции программа запрашивает у системы
оценку не доступного места (с учетом «очищаемого»), а только реально
свободного места на данный момент, и соответственно показывает
сообщение, что его мало. Это похоже на недоработку. В других
программах все работает автоматически.
Пару дней назад как раз вышло бесплатное обновление DaisyDisk 4.5
(https://daisydiskapp.com/downloads/DaisyDisk.zip), в котором мы
добавили отображение этого «очищаемого пространства» на APFS (как еще
один элемент списка внутри «скрытого пространства», изображенного на
скриншоте в статье), таким образом можно сразу обнаружить эту «черную
дыру» и оценить ее размер. Более того, при желании можно перетащить
ее, как обычный файл, в «Коллектор» и таким образом вызвать
принудительную очистку локальных снимков Time Machine. Это удобнее,
чем вводить команды в Terminal :) Кроме того, DaisyDisk может удалять
не только локальные снимки, но и по максимуму все остальные компоненты
«очищаемого пространства». Такая очистка может быть полезна в
некоторых случаях, как например описанных в данной статье. (Больше
инфы тут: daisydiskapp.com/manual/4/en/Topics/PurgeableSpace.html)
Кстати, есть еще одна особенность macOS High Sierra, связанная с темой
статьи, которая также вызывает много вопросов у пользователей: в окне
«Об этом Mac» > «Хранилище» иногда раздел «Система» занимает чрезмерно
много места – до 80% диска. Как вы уже наверное догадались, это
происходит потому, что в «Систему» теперь включены local snapshots,
правда не совсем понятно зачем. Раньше «очищаемое пространство» было в
этом окне отдельной категорией. (Больше инфы тут: daisydiskapp.com/manual/4/en/Topics/SystemTooBig.html)
Разбирали эту ситуацию. Проблема там была не столько с самим OpenGL 3.x, сколько с тем как этот VTK OpenGL инициализирует. Это было исправлено и VTK 7.1 должен работать в Parallels Desktop 13.2. Попутно выяснилось, что VTK 8.x у нас (и скорее всего во фюжене тоже, но это не проверялось) работать действительно не будет. И причина ровно в том, что виндовые программы тупо уверены в наличии на виндах Compatibility profile-а. Т.е. программы (включая VTK 8) используют функциональность не проверяя ее наличия. А текст сообщения об ошибке – на совести его написавших.
Что касается вывода о «полной» или «не полной» поддержке OpenGL любой версии на основании единственной программы, то это выглядит несколько опрометчиво и не только в отношении OpenGL. Мы таки знаем, что в реализации OpenGL 3.x у нас много пробелов по сравнению с виндой, и тому есть причины (о чем и был пост), и мы над этим работаем. Но это не значит что OpenGL 3.2 у нас нет совсем. В любом случае, чтобы иметь какие-то гарантии любое (и каждое) приложение нужно проверять в ВМ. Обобщать не стоит, потому что тогда на основании того, что во фьюжен не работает Wolfenstein: The Old Blood надо будет сделать вывод, что у них OpenGL 3.2 нет совсем.
Привет!
Непонятно почему вы решили, VMWare Fusion 10 имеет полную поддержку OpenGL 3.2. И что Вы выкладываете в отделение «полная»? Фьюжн поддерживает 3.2 Core profile. И мы *тоже* его поддерживаем. Практически все программы для Windows пользуются Compatibility profile-ом просто потому, что в виндах он всегда есть. Фьюжен *не* поддерживает 3.2 Compatibility profile, и мы догадываемся почему. (Да потому что макось его не поддерживает!). Мы поддерживаем 3.2 Compatibility для *некоторых* приложений.
Спросил у Игоря. Вот что он прислал:
NASA Manager's Handbook for Software Development
NASA Virtual PM Challenge
Dale Carnegie
Steve Mcconnell
Максим Батырев
Joel Spolsky
Lido Anthony «Lee» Iacocca
Ichak Kalderon Adizes
Peter Ferdinand Drucker
Fred Brooks
Tom DeMarco
Черток Борис
Michael Abrashoff
Тайити Оно
Вот:
Я Олег Крупнов, разработчик программы DaisyDisk, упоминаемой в статье.
Действительно, новая файловая система APFS обладает некоторыми
особенностями, которые часто вызывают недоумение у пользователей, хотя
и редко являются проблемой.
В частности, при удалении файлов свободное место не появляется
мнговенно. В статье правильно написано, что это происходит из-за
временных архивов, так называемых «локальных снимков» (local
snapshots) Time Machine. Файлы физически остаются на диске после
удаления, поскольку локальные снимки на них по-прежнему ссылаются. Эти
снимки составляют львиную долю так называемого «очищаемого
пространства» (purgeable), отображаемого в Finder и Disk Utility в
скобочках после свободного места. Эти локальные снимки существовали и
в предыдущих версиях macOS (в скрытой папке /.MobileBackups), но в
APFS они расположены вообще за пределами доступной пользователям части
диска – действительно, как будто в «черной дыре».
По идее, macOS должна автоматически удалять старые local snapshots в
случае если места на диске становится меньше 20%. Например, в Finder,
при копировании большого файла с внешнего диска в условиях почти
заполненного диска происходит практически мгновенное удаление старых
«снимков».
В описанном случае с iTunes и Disk Utility этого не происходит, видимо
потому, что перед началом операции программа запрашивает у системы
оценку не доступного места (с учетом «очищаемого»), а только реально
свободного места на данный момент, и соответственно показывает
сообщение, что его мало. Это похоже на недоработку. В других
программах все работает автоматически.
Пару дней назад как раз вышло бесплатное обновление DaisyDisk 4.5
(https://daisydiskapp.com/downloads/DaisyDisk.zip), в котором мы
добавили отображение этого «очищаемого пространства» на APFS (как еще
один элемент списка внутри «скрытого пространства», изображенного на
скриншоте в статье), таким образом можно сразу обнаружить эту «черную
дыру» и оценить ее размер. Более того, при желании можно перетащить
ее, как обычный файл, в «Коллектор» и таким образом вызвать
принудительную очистку локальных снимков Time Machine. Это удобнее,
чем вводить команды в Terminal :) Кроме того, DaisyDisk может удалять
не только локальные снимки, но и по максимуму все остальные компоненты
«очищаемого пространства». Такая очистка может быть полезна в
некоторых случаях, как например описанных в данной статье. (Больше
инфы тут: daisydiskapp.com/manual/4/en/Topics/PurgeableSpace.html)
В процессе разработки этого обновления нам пришлось потратить большое
количество времени на эксперименты с APFS, поскольку документация по
ней почти отсутствует. Кроме того, я общался с инженерами Apple по
поводу их технических решений. Из их ответов я понял, что они
рассматривают пустое место на диске как ресурс. Зачем, задают они
вопрос, такому ресурсу простаивать, если его можно использовать? :)
Например для временных резервных «снимков». Благодаря APFS их создание
и удаление стало очень дешевым, поэтому они не видят проблемы в том,
чтобы диск был все время заполнен «очищаемым пространством», если его
можно в любой момент удалить. В идеале (пока недостижимом), с точки
зрения Apple, пользователи вообще не должны будут знать о том, сколько
места остается на диске, пока его достаточно :) It just works ©.
Кстати, есть еще одна особенность macOS High Sierra, связанная с темой
статьи, которая также вызывает много вопросов у пользователей: в окне
«Об этом Mac» > «Хранилище» иногда раздел «Система» занимает чрезмерно
много места – до 80% диска. Как вы уже наверное догадались, это
происходит потому, что в «Систему» теперь включены local snapshots,
правда не совсем понятно зачем. Раньше «очищаемое пространство» было в
этом окне отдельной категорией. (Больше инфы тут:
daisydiskapp.com/manual/4/en/Topics/SystemTooBig.html)
Что касается вывода о «полной» или «не полной» поддержке OpenGL любой версии на основании единственной программы, то это выглядит несколько опрометчиво и не только в отношении OpenGL. Мы таки знаем, что в реализации OpenGL 3.x у нас много пробелов по сравнению с виндой, и тому есть причины (о чем и был пост), и мы над этим работаем. Но это не значит что OpenGL 3.2 у нас нет совсем. В любом случае, чтобы иметь какие-то гарантии любое (и каждое) приложение нужно проверять в ВМ. Обобщать не стоит, потому что тогда на основании того, что во фьюжен не работает Wolfenstein: The Old Blood надо будет сделать вывод, что у них OpenGL 3.2 нет совсем.
Непонятно почему вы решили, VMWare Fusion 10 имеет полную поддержку OpenGL 3.2. И что Вы выкладываете в отделение «полная»? Фьюжн поддерживает 3.2 Core profile. И мы *тоже* его поддерживаем. Практически все программы для Windows пользуются Compatibility profile-ом просто потому, что в виндах он всегда есть. Фьюжен *не* поддерживает 3.2 Compatibility profile, и мы догадываемся почему. (Да потому что макось его не поддерживает!). Мы поддерживаем 3.2 Compatibility для *некоторых* приложений.