Kernel_task будет виден в мониторинге системы, если выбраны все процессы или системные процессы. По умолчанию показаны только процессы текущего пользователя, насколько я помню. Об этих настройках можно почитать support.apple.com/ru-ru/HT201464
Виден ли этот процесс в мониторинге системы или нет — ничего не говорит о наличии или отсутствии проблем
Ок, видимо не троллинг, а незнание. kernel_task — это процесс ядра операционной системы. Он присутствует в макоси не зависимо от того, был апдейт с предыдущей версии или нет.
Задач у этого процесса очень много. Менеджмент памяти, процессов, тредов и еще миллион всего, если в двух словах. Этот процесс не зря ядром называется. Почитать про ядро можно к примеру ru.wikipedia.org/...Ядро_операционной_системы.
Обычно этот процесс потребляет немного ресурсов. В некоторых ситуациях — например, когда заканчивается оперативная память и происходит своп — много. Если kernel_task постоянно жрет много CPU — то да, явно что-то пошло не так. Вот описание как именно можно разобраться, о чем именно говорит high CPU usage у этого процесса, например — apple.stackexchange.com/...-kernel-task-memory-usage. Но такая диагностика — это не особо просто, требует довольно высокого уровня понимания внутренностей ОСи.
Допускаю, что ошибки обновления могут привести к высокому потреблению CPU процессом kernel_task. И это приведет к перегреву. Но это только 1 возможный вариант из 100500.
Это толстый троллинг. Kernel task — процесс ядра макоси, конечно он есть. Вот если его нет — то можно начинать волноваться.
О второй проблеме — twitter.com/...status/829463498702934016. У меня такой ступор вызывали сначала ARC, потом thread sanitizer :)
Я для себя решил ее довольно просто — закопался глубже туда, где мои старые навыки нужны. Очень четко осознаю, что «среднестатестический инженер» решит среднестатистическую задачу быстрее и эффективнее меня. И лично для себя решил выйти из этой гонки, и сфокусироваться на задачах, которые я хорошо умею решать, а этот самый «среднестатестический инженер» скорее всего просто впадет в ступор. Минус очевиден — гораздо меньше подходящих проектов. Зато если уж находится подходящий проект — то он обычно мне интересен.
Но да, все так.
Не ожидал тут увидеть знакомое лицо :)
70% времени на код — это очень даже неплохо. Меня, помниться, очень напрягало, когда пару дней подряд времени — в лучшем случае чужой код почитать. Потом привык. Сейчас опять больше пишу, тоже порякда 70% времени.
А вот 10 часов в офисе не считая дороги — это жестко. По личному опыту скажу — следи за эмоциональным состоянием. Выгорание — штука очень неприятная. И, как показывает практика, совершенно ненужная. Компании обычно нужен не top performer с вероятностью перегореть, а надежный сотрудник без проблем с психикой и внезапных депрессий, даже если он работает меньше положенного, но достаточно. А здоровье у тебя одно. Я сейчас пинками выгоняю себя из офиса в промежутке между 17:00 и 18:00, и принципиально не работаю из дому. Но от трудоголизма лечиться тоже сложно.
С математикой — тоже думал так же пару лет назад. Сейчас смирился. И без нее есть довольно много интересных областей. Но да, очень обидно, что серьезно недооценил ее в универе. А сейчас учить намного сложнее.
Про менеджмент тоже думал, где-то в тот же период. Сейчас точно понимаю, что нет и еще раз нет. Во первых — спрос на технарей на порядки выше. Менеджеру удачно уехать в другую страну — большая проблема, там своих менеджеров достаточно. А программисту — все и так знают. Во вторых — не для того я более 10 лет программированием занимался, чтоб сейчас его бросить и уйти в другую область.
А в целом — рад что у тебя все ок :)
Отказ от наличности на примере Скандинавии реализуем только при условии доверия к банковскому сектору. В Швеции представить себе, что банк навернется, практически нереально. В Украине мой банк навернулся в прошлом году. Я успешно получил возмещение средств со своих счетов, но на это ушло месяца
Смотря куда. Я без проблем перебрался в Швецию без диплома.
Смотря куда. Я совершенно без проблем перебрался в Швецию без диплома.
Лично не сталкивался, но ощущаю скорбь по этому поводу. Лично я ничего не имею против, и даже многое имею за обучение на работе. Но исключительно в разумных пределах и не в ущерб собственно работе. Платят мне за решение проблем, а не за то, чтоб я новую перделку выучил.
Соглашусь, что learning вместо working — ересь какая-то. Что не отменяет того, что они вполне могут сосуществовать. Конечно, баланс при этом однозначно в сторону working.
Как раз получится — проект полностью соответствует спецификации, и глубоко пофиг что он такой никому не нужен, так как требования под него написаны 3 года назад;
Наш диалог начинает напоминать мне историю про мудрецов и слона :)
Даже в Идеальном Скраме никто и никогда не говорил, что разработчик может сам решать что ему делать. Поправьте если ошибаюсь.
А вот учеба, на мой взгляд, проблемой как раз не является. Может мое личное везение, конечно. Но разработчик должен постепенно вникать в предметную область. Время на это тоже уходит. И при адекватном процессе расходы на эту часть работы взвешиваются заранее.
Запомнилась фраза моего менеджера — «У нас нет эксперта, который может решить этот вопрос. Это хорошая причина, чтоб ты стал таким экспертом»
На мой взгляд, оригинальный пост именно о том, что методологию начали нарушать все чаще и чаще. По моему опыту — прикрываясь тем, что фреймворк же, можно перепиливать как хочешь. Вот и получается в итоге outcome...
Даже не знаю, какую часть статьи процитировать...
The real problems are doing the wrong thing, building to a spec, unfocused resource allocation, etc
Наверное эту.
Скрамбат же
По моему опыту, если скрам правильно готовить — он может работать. Вот только то, что он представляет собой фреймворк, который рекоммендуют допиливать под конкретную ситуацию, развязывает руки. И в итоге получается ... то, что получается.
Именно. Но большинство комманд заменяет нормальный вариант карго-культом
Проблема в том, что в данном случае подумать и выкинуть можно было намного, намного раньше
А я и не говорю что дело конкретно в скраме. Дело в том, что в конкретно этом случае от итеративной разработки остались только регулярные отчеты заказчику что именно делается. Без намека на то, чтоб проверить а действительно ли требования адекватны.
Рад что моя информация была полезной.