Я писал не про панику ядра, а про причины падения виртуалок, о которых, изначально, и был ваш вопрос. И тут, как вы правильно отметили, рулит netconsole. Именно ей мы, кстати, и мониторим.
А что касается kernel panic'ов, то у нас на KVM виртуалках пользователи получали их на RT ядрах или, например, при использовании zswap.
В общем, что хочу сказать — если говорить об отладке сообщений и падений ядра, то, с точки зрения хостера, правильнее для начала научиться ловить и уведомлять об оомах, упсах и багах, и уже потом думать про паники.
По той простой причине, что в реальной жизни их количество соотносится в пропорции 100 к 1. И это действительно лучше делать нетконсолью.
Если в настройках отключить пункт «Разрешить полезную рекламу».
В список полезной внесена только контекстная реклама на всех популярных поисковиках (Яндекс, Google, Bing, Ask).
Удивился что не используется Semaphore в worker'ах, потом вспомнил про запрет на util.concurrent.
Хотя он достаточно легко реализуется через wait-notify, и отлично ложится на задачу,
реализация ThreadPool'а получилась бы намного короче и понятнее.
Где-то читал интервью одного из разработчиков языка, он говорил что event'ы и делегаты это не православно, и в java их никогда не будет. Так что addListener и тысячи строк лишнего когда с нами навсегда:).
Я сейчас скажу достаточно спорную штуку, но все-таки: java в последнее время потихоньку перенимает у c# разные полезные фичи (поменялись они местами, да:)), но почему-то каждый раз через жопу.
Generic'и — вместо того, чтобы стянуть один-в-один поленились и сделали через приведение типов.
Имхо реализация generic'ов в шарпе более продумана.
Теперь extension-методы. Нет бы стянуть из шарпа, где это простая фича, по сути — это упрощение синтаксиса и не более. Но [i]множественное наследование[i] ради возможности писать типа-какбы-в-функциональном-стиле?
Ой не к добру, не к добру.
P.S. И еще, дорогие разработчики языка, если уж вы начали добавлять синтаксический сахар, где Properties вашу мать?
2) Он используется.
3) БД на отдельном сервере, само собой.
А что касается kernel panic'ов, то у нас на KVM виртуалках пользователи получали их на RT ядрах или, например, при использовании zswap.
В общем, что хочу сказать — если говорить об отладке сообщений и падений ядра, то, с точки зрения хостера, правильнее для начала научиться ловить и уведомлять об оомах, упсах и багах, и уже потом думать про паники.
По той простой причине, что в реальной жизни их количество соотносится в пропорции 100 к 1. И это действительно лучше делать нетконсолью.
Ну а падать — например от OOM-событий.
В список полезной внесена только контекстная реклама на всех популярных поисковиках (Яндекс, Google, Bing, Ask).
Хотя он достаточно легко реализуется через wait-notify, и отлично ложится на задачу,
реализация ThreadPool'а получилась бы намного короче и понятнее.
Спасибо, не знаю почему, но думал, что шарп был первым).
Чем вас не устраивает такой подход?
Generic'и — вместо того, чтобы стянуть один-в-один поленились и сделали через приведение типов.
Имхо реализация generic'ов в шарпе более продумана.
Теперь extension-методы. Нет бы стянуть из шарпа, где это простая фича, по сути — это упрощение синтаксиса и не более. Но [i]множественное наследование[i] ради возможности писать типа-какбы-в-функциональном-стиле?
Ой не к добру, не к добру.
P.S. И еще, дорогие разработчики языка, если уж вы начали добавлять синтаксический сахар, где Properties вашу мать?
Порядка больше получается.