Ну, осваивать можно и не месяц, а дольше. Но сразу несколько параллельно.
Да и уровень "освоения" не обязательно должен быть у всех одинаково высоким.
Например, я себя считаю себя нулевым админом MS SQL. Но это не мешает мне делать весьма грамотные планы обслуживания баз данных, в т.ч. служебных, и производить разные полезные настройки. Но я всем говорю, что в MS SQL я ничего не понимаю. И это почти соответствует истине.
Или вот настройка роутеров Mikrotik. Тоже я почти абсолютный нуль по Фаренгейту. Но когда начал писать инструкцию по его настройке в наших реалиях, то сам офигел, какая она длинная получается. А я ведь как-то разобрался в этом, кое в чем с помощью Интернета, кое-что сам придумал: резервирование, балансировка, черно-серые списки, ханипоты и прочее.
В общем, не надо осваивать все по очереди. Можно это делать одновременно по многим направлениям, но в объемах, минимально необходимых для решения текущих задач. Так получится и быстрее и качественнее.
Для сисадмина главное не то, что он знает, и умеет (это дело опыта, который достаточно быстро нарабатывается), а как умеет работать с тем, чего не знает и знать даже не может.
А тут может помочь только внимательность, усидчивость и даже упёртость. И умение выносить мозг косячникам на стороне - разработчиками, производителями, поставщиками, смежными отделами и службами. Потому что львиная доля проблем возникает не потому что сисадмин сделал что-то не то и не так, а потому что он сделал то, что надо и так, как надо по RFC и RTFM, но это так не работает.
Вот и приходится разбираться в проблеме медленно, уныло с настойчивостью дорожного катка.
Несколько примеров из личного опыта:
Лет 13 назад построили новую проходную. Установили два турникета, четыре бесконтактных терминала (два на вход, два на выход)..Лирическое отступление - сетевухи в терминалах убогие, работают в полудуплексе 10 MHz, пинги теряют или не считают нужным на все отвечать - так что даже не понятно сразу: он еще в сети или уже отвалился.
Так вот, стали поступать жалобы, что работают они паршиво - не срабатывают или срабатывают не с первого раза. Стал разбираться - прозвонил кабели, проверил доступность терминалов с разных точек. Подключаюсь к ним напрямую - потеря пингов около 25%, но это для них нормально. А включаю их в общую сеть - на двух из них потери до 75%. Причем, четко - пока один худо-бедно пингуется, второй вообще недоступен. Где-то через минуту они местами как-бы меняются. Апофеозом была картина, когда я собрал стенд из двух ноутов, двух свичей и четырех терминалов. К каждому свичу подключен свой ноут и два терминала, свичи соединены между собой. С ноутов пытаюсь пинговать все четыре терминала с каждого. И вижу, что с одного пингуются три из четырех и с другого тоже три из четырех. Но другие! В смысле - два терминала пингуются с обоих ноутов, третий только с одного ноута, а четвертый - только с другого.
Офигел, собрал как было, пошел к себе и ... проарпил эти терминалы. И вижу - у двух из низ одинаковые MAC-адреса.
Позвонил разработчику, он же поставщик, и смачно матерился в телефонную трубку.
Поиск источника проблемы занял 5 часов непоняток.
Несколькими годами ранее. Начали диспетчеризировать удаленные объекты для передачи теоеметрии в диспетчерскую. На тот момент диспетчеризировано было только два. И с одним из них связь постоянно рвалась. Причем в то время, когда директор перед началом рабочего дня и после окончания работы заходил в диспетчерскую. У директора мгновенно глаза становились красные, как сигнал аварии и он спускал всех собак.
Провайдер, через сети которого шло подключение, ушел в несознанку, мол проблема на вашей стороне - вы и решайте.
Продолжалось пару месяцев, обстановка накалялась. Я воспользовался программой мониторинга Netview, написал скрипт, отслеживания изменения статуса объекта. Если объект перестал пинговаться - в лог писалось время, его IP и ставился минус. Снова начинал пинговаться - писалось время, IP и плюсик.
Две недели собирал данные, потом построил гистограммы количества отвалов по 15-минутным интервалам. И оказалось, что больше всего отвалов на этом объекте в период с 7:00 до 7:30 и с 17:30 до 22:00.
Потом поехали к провайдеру. И когда их гендир опять начал бубнить, что проблема у нас, я показал ему эти графики и наорал матом. В результате наш директор попросил меня удалиться. Зато их технические службы получили мощного пинка.
Оказалось, что в том районе жил человек со старым ламповым телевизором. А у нас этот объект был подключен к провайдерским сетям по коаксиалу. Так вот, собираясь на работу и вечером, этот чел врубал свою шайтан-машину и по сети шли такие наводки, что наши пакеты пробивались с превеликим трудом.
Поиск виновника занял еще недели три. Но моя работа по сбору доказательств, что не мы виноваты - почти три месяца.
Год не вспомню - где-то между 2011 и 2017. Падает терминальный сервер. Сначала начинает тормозить, потом минут через 15-20 виснет. Причем, нагрузка на процессоры не критическая, температуры в норме, память не переполнена, но виснет. Причем, вис он изредка и раньше, а после резкого увеличения числа терминальных пользователей стал виснуть чуть ли не каждую неделю.
Помогала принудительная перезагрузка два раза в неделю, но это не точно.
Путем наблюдений определил, что в системе растет число открытых дескрипторов. При помощи утилиты PoolMon (вечная слава Марку Руссиновичу) удалось собрать данные по часам и выяснить, что в невыгружаемом пуле ядра ОС количество дескрипторов под одним тэгом постоянно растет. Этот тэг нашелся в DLL антивируса ESET NOD32.
Потом были долгие переругивания с ТП этого антивируса. Они, как всегда, не признавали свою вовлеченность в проблему. Я строил графики расхода дескрипторов по тэгам на протяжении длительного времени, высылал им эти графики и прочие скрины. В конце концов они признали, что утечка памяти невыгружаемого пула ядра ОС действительно есть и посоветовали перейти на 5-ю версию антивируса. Она как раз некоторое время назад была выпущена.
Кстати, на обычных компах, которые работают умеренно под одним пользователем и регулярно выключаются, эта утечка не успевала проявится в критической мере.
Все это заняло около полугода.
Так что, усидчивость, усидчивость и еще раз усидчивость.
P.S. Есть еще и другие байки из личного опыта про поиск причин трудноуловимых багов (т.е. фич.)
Боюсь, что в покере я понимаю немногим больше, чем ничего. Мне ближе преферанс. Например, стратегии сноса и ловли на угадаечных мизерах.
Понимаю, что в данном случае понять будет трудно уже вам, но попытаюсь объяснить на пальцах.
Вот, допустим, у играющего мизер после прикупа до сноса такая рука:
♠: 7 8 9 10
♣: 7 8 9 10 J
♦: 8
♥: K A
Третья рука, торговли не было. Т.е. два других игрока в свою очередь заявок на игру не делали. Какие две карты отправить в снос, чтобы оставшуюся карту не "поймали"?
Интуитивно без расчетов понятно, что скидывать надо две червы. Т.к. вероятность получить взятку на бланковую бубновую восьмерку - крайне мала. А раз она не ловится в большинстве случаев, то "ловить" станут черву. А вот она ловится практически в 100%. Т.е. черву оставлять никак нельзя.
А теперь предположим, что в бубне не восьмерка, а десятка. Что сносить?
Теперь без расчетов не обойтись. И они показывают, что нужно применять смешанную стратегию примерно 50/50: в половине случаев нести две червы, а в половине - черву с бубной. Дело в том, что бланковая десятка "ловится" гораздо чаще. И если оставлять всегда её (а оппоненты про это знают), то чаще её и поймают.
А если применять смешанную стратегию, то оппоненты в половине случаев снос не угадают. А еще в ряде случаев десятка не может быть поймана, а мы ее и оставили. Т.е. профит от неизвестного сноса превысит профит от того, что десятка может не ловиться.
А если в бубне не восьмерка и не десятка, а девятка? А вот это уже сложно. Расчеты показывают, что тоже надо применять смешанную стратегию, но это не точно: Во-первых, преимущество смешанной стратегии в данном случае невелико. А, во-вторых, грубые расчеты не берут во внимание некоторые трудноучитываемые факторы: Не было торговли. А если и была, то прекратилась после нашей заявки "мизер". Слева сидит игрок осторожный, а справа - рисковый (или наоборот). У одного из них после нашей заявки задергалось ухо. И многое другое.
А если структура мастей другая - в черных мастях не 4:5 карт, а 3:6?
Т.е. абстрактные расчеты итерационными методами здесь ответа не дадут. Сложно и трудно всё учесть. А вот глубокое машинное обучение с имитацией игры против различных игроков - результат дать может.
Но оно должно не просто дать ответ, применять ли смешанные стратегии, но и их частоты. А вот на это ИНС, кажется, не способна.
Тут я набрел на статью по поводу ИНС Libratus, играющей в безлимитный холдем:
Оказывается, расчетом этих смешанных стратегий в ней тоже занималась не сама ИНС, а она только сводила воедино расчеты, выполняемые блоком Monte-Carlo CFR. Но как она это делала?
В принципе, это тоже алгоритм нахождения оптимальных смешанных стратегий, как и упомянутый мною итерационный метод Робинсон-Брауна. Только более эффективный и быстрее сходящийся.
Но как подружить любой из этих методов с нейросетью - вопрос остается открытым.
CFR позволит найти (рассчитать) оптимальные смешанные стратегии для конкретных заданных рук. А ИНС должна найти (пусть даже приближенно) эти оптимальные смешанные стратегии для любых рук, в т.ч. и для необсчитанных. Просто на основе опыта обучения игрой с самой собой.
Тут не столько от магазина зависит, сколько от каналов поставок. Много подделок на Озоне или Ситилинке. Еще больше, если покупать на АлиЭкспресс. Но даже в дистрибуции 3LOGIC GROUP подделки всплывали.
В любом случае покупать лучше не через Интернет-магазин, а через торговый зал. Дороже будет, но с возвратом меньше мороки.
И это нам еще повезло, что SSD оказались полностью нерабочими. И подделка была очень грубой. Обычно же в более-менее похожей упаковке и корпусе продают какую-то галимую шнягу с убогим контроллером и маленьким буфером. В результате SSD работает, но скорости - никакой.
При этом качество упаковки и корпуса такое, что нужно с лупой лазить по ним, чтобы найти отличия.
Вот недавно прочитал, что у оригинальных Samsung на задней крышке головки винтов под 5-лучевую звездочку, а у подделок - под крест. А остальное - практически как настоящее. Даже посадочные отверстия. Но кто мешает закупить такие винты?
А так, хорошую подделку можно определить только через тесты, анализ параметров S.M.A.R.T. Да говорят, что Samsung Magician на такие SSD ругается, что не оригинальные. Но это же не в магазине всё делать.
На самом корпусе SDD есть надпись "Samsung" (и серый квадратик). А покупали мы SSD, а не коробку.
Кроме того, "870 EVO" является зарегистрированной торговой маркой Samsung. Правда, в РФ она не регистрировалась. Ну так и SSD эти не в России делались.
На форуме "F1News.ru" уже лет 10 назад была внедрена система, заменяющая непарламентские выражения на дипломатические аналоги: Я огорчен. Накипело. Это возмутительно.
Тут на днях приходил пацанчик устраиваться. С мамашей. А нач отдела - любитель байков. И у него на стене висит календарь с голой бабой на мотоцикле. Ну не совсем голой - в шлеме.
На файлопомойке Synology хотел использовать по расписанию команду, которая очищает папку от старых файлов. А она не работает. Потому что имя папки написано кириллицей.
А если попытаться выполнить ее не из планировщика, а из терминала, то удалится вся папка :(
Олды могут помнить, что в СУБД FoxPro (старой, еще DOSовской) обрезались строки с буквой "я".
Ну, осваивать можно и не месяц, а дольше. Но сразу несколько параллельно.
Да и уровень "освоения" не обязательно должен быть у всех одинаково высоким.
Например, я себя считаю себя нулевым админом MS SQL. Но это не мешает мне делать весьма грамотные планы обслуживания баз данных, в т.ч. служебных, и производить разные полезные настройки. Но я всем говорю, что в MS SQL я ничего не понимаю. И это почти соответствует истине.
Или вот настройка роутеров Mikrotik. Тоже я почти абсолютный нуль по Фаренгейту. Но когда начал писать инструкцию по его настройке в наших реалиях, то сам офигел, какая она длинная получается. А я ведь как-то разобрался в этом, кое в чем с помощью Интернета, кое-что сам придумал: резервирование, балансировка, черно-серые списки, ханипоты и прочее.
В общем, не надо осваивать все по очереди. Можно это делать одновременно по многим направлениям, но в объемах, минимально необходимых для решения текущих задач. Так получится и быстрее и качественнее.
Для сисадмина главное не то, что он знает, и умеет (это дело опыта, который достаточно быстро нарабатывается), а как умеет работать с тем, чего не знает и знать даже не может.
А тут может помочь только внимательность, усидчивость и даже упёртость. И умение выносить мозг косячникам на стороне - разработчиками, производителями, поставщиками, смежными отделами и службами. Потому что львиная доля проблем возникает не потому что сисадмин сделал что-то не то и не так, а потому что он сделал то, что надо и так, как надо по RFC и RTFM, но это так не работает.
Вот и приходится разбираться в проблеме медленно, уныло с настойчивостью дорожного катка.
Несколько примеров из личного опыта:
Лет 13 назад построили новую проходную. Установили два турникета, четыре бесконтактных терминала (два на вход, два на выход)..Лирическое отступление - сетевухи в терминалах убогие, работают в полудуплексе 10 MHz, пинги теряют или не считают нужным на все отвечать - так что даже не понятно сразу: он еще в сети или уже отвалился.
Так вот, стали поступать жалобы, что работают они паршиво - не срабатывают или срабатывают не с первого раза. Стал разбираться - прозвонил кабели, проверил доступность терминалов с разных точек. Подключаюсь к ним напрямую - потеря пингов около 25%, но это для них нормально. А включаю их в общую сеть - на двух из них потери до 75%. Причем, четко - пока один худо-бедно пингуется, второй вообще недоступен. Где-то через минуту они местами как-бы меняются. Апофеозом была картина, когда я собрал стенд из двух ноутов, двух свичей и четырех терминалов. К каждому свичу подключен свой ноут и два терминала, свичи соединены между собой. С ноутов пытаюсь пинговать все четыре терминала с каждого. И вижу, что с одного пингуются три из четырех и с другого тоже три из четырех. Но другие! В смысле - два терминала пингуются с обоих ноутов, третий только с одного ноута, а четвертый - только с другого.
Офигел, собрал как было, пошел к себе и ... проарпил эти терминалы. И вижу - у двух из низ одинаковые MAC-адреса.
Позвонил разработчику, он же поставщик, и смачно матерился в телефонную трубку.
Поиск источника проблемы занял 5 часов непоняток.
Несколькими годами ранее. Начали диспетчеризировать удаленные объекты для передачи теоеметрии в диспетчерскую. На тот момент диспетчеризировано было только два. И с одним из них связь постоянно рвалась. Причем в то время, когда директор перед началом рабочего дня и после окончания работы заходил в диспетчерскую. У директора мгновенно глаза становились красные, как сигнал аварии и он спускал всех собак.
Провайдер, через сети которого шло подключение, ушел в несознанку, мол проблема на вашей стороне - вы и решайте.
Продолжалось пару месяцев, обстановка накалялась. Я воспользовался программой мониторинга Netview, написал скрипт, отслеживания изменения статуса объекта. Если объект перестал пинговаться - в лог писалось время, его IP и ставился минус. Снова начинал пинговаться - писалось время, IP и плюсик.
Две недели собирал данные, потом построил гистограммы количества отвалов по 15-минутным интервалам. И оказалось, что больше всего отвалов на этом объекте в период с 7:00 до 7:30 и с 17:30 до 22:00.
Потом поехали к провайдеру. И когда их гендир опять начал бубнить, что проблема у нас, я показал ему эти графики и наорал матом. В результате наш директор попросил меня удалиться. Зато их технические службы получили мощного пинка.
Оказалось, что в том районе жил человек со старым ламповым телевизором. А у нас этот объект был подключен к провайдерским сетям по коаксиалу. Так вот, собираясь на работу и вечером, этот чел врубал свою шайтан-машину и по сети шли такие наводки, что наши пакеты пробивались с превеликим трудом.
Поиск виновника занял еще недели три. Но моя работа по сбору доказательств, что не мы виноваты - почти три месяца.
Год не вспомню - где-то между 2011 и 2017. Падает терминальный сервер. Сначала начинает тормозить, потом минут через 15-20 виснет. Причем, нагрузка на процессоры не критическая, температуры в норме, память не переполнена, но виснет. Причем, вис он изредка и раньше, а после резкого увеличения числа терминальных пользователей стал виснуть чуть ли не каждую неделю.
Помогала принудительная перезагрузка два раза в неделю, но это не точно.
Путем наблюдений определил, что в системе растет число открытых дескрипторов. При помощи утилиты PoolMon (вечная слава Марку Руссиновичу) удалось собрать данные по часам и выяснить, что в невыгружаемом пуле ядра ОС количество дескрипторов под одним тэгом постоянно растет. Этот тэг нашелся в DLL антивируса ESET NOD32.
Потом были долгие переругивания с ТП этого антивируса. Они, как всегда, не признавали свою вовлеченность в проблему. Я строил графики расхода дескрипторов по тэгам на протяжении длительного времени, высылал им эти графики и прочие скрины. В конце концов они признали, что утечка памяти невыгружаемого пула ядра ОС действительно есть и посоветовали перейти на 5-ю версию антивируса. Она как раз некоторое время назад была выпущена.
Кстати, на обычных компах, которые работают умеренно под одним пользователем и регулярно выключаются, эта утечка не успевала проявится в критической мере.
Все это заняло около полугода.
Так что, усидчивость, усидчивость и еще раз усидчивость.
P.S. Есть еще и другие байки из личного опыта про поиск причин трудноуловимых багов (т.е. фич.)
Откуда будет торчать?
А я вот тоже так говорю:
Сделаем 1000 итераций. Нет ... Давай, для ровного счета, сделаем 1024.
У 16-разрядного Змея Горыныча не может быть более 65535 голов.
Да подзабылось как-то :)
Боюсь, что в покере я понимаю немногим больше, чем ничего. Мне ближе преферанс. Например, стратегии сноса и ловли на угадаечных мизерах.
Понимаю, что в данном случае понять будет трудно уже вам, но попытаюсь объяснить на пальцах.
Вот, допустим, у играющего мизер после прикупа до сноса такая рука:
♠: 7 8 9 10
♣: 7 8 9 10 J
♦: 8
♥: K A
Третья рука, торговли не было. Т.е. два других игрока в свою очередь заявок на игру не делали. Какие две карты отправить в снос, чтобы оставшуюся карту не "поймали"?
Интуитивно без расчетов понятно, что скидывать надо две червы. Т.к. вероятность получить взятку на бланковую бубновую восьмерку - крайне мала. А раз она не ловится в большинстве случаев, то "ловить" станут черву. А вот она ловится практически в 100%. Т.е. черву оставлять никак нельзя.
А теперь предположим, что в бубне не восьмерка, а десятка. Что сносить?
Теперь без расчетов не обойтись. И они показывают, что нужно применять смешанную стратегию примерно 50/50: в половине случаев нести две червы, а в половине - черву с бубной. Дело в том, что бланковая десятка "ловится" гораздо чаще. И если оставлять всегда её (а оппоненты про это знают), то чаще её и поймают.
А если применять смешанную стратегию, то оппоненты в половине случаев снос не угадают. А еще в ряде случаев десятка не может быть поймана, а мы ее и оставили. Т.е. профит от неизвестного сноса превысит профит от того, что десятка может не ловиться.
А если в бубне не восьмерка и не десятка, а девятка? А вот это уже сложно. Расчеты показывают, что тоже надо применять смешанную стратегию, но это не точно: Во-первых, преимущество смешанной стратегии в данном случае невелико. А, во-вторых, грубые расчеты не берут во внимание некоторые трудноучитываемые факторы: Не было торговли. А если и была, то прекратилась после нашей заявки "мизер". Слева сидит игрок осторожный, а справа - рисковый (или наоборот). У одного из них после нашей заявки задергалось ухо. И многое другое.
А если структура мастей другая - в черных мастях не 4:5 карт, а 3:6?
Т.е. абстрактные расчеты итерационными методами здесь ответа не дадут. Сложно и трудно всё учесть. А вот глубокое машинное обучение с имитацией игры против различных игроков - результат дать может.
Но оно должно не просто дать ответ, применять ли смешанные стратегии, но и их частоты. А вот на это ИНС, кажется, не способна.
Тут я набрел на статью по поводу ИНС Libratus, играющей в безлимитный холдем:
https://www.ijcai.org/proceedings/2017/0772.pdf
Оказывается, расчетом этих смешанных стратегий в ней тоже занималась не сама ИНС, а она только сводила воедино расчеты, выполняемые блоком Monte-Carlo CFR. Но как она это делала?
Почитал я про CFR-minimization ...
https://dspace.spbu.ru/bitstream/11701/40152/2/VKR_Tokareva.pdf
В принципе, это тоже алгоритм нахождения оптимальных смешанных стратегий, как и упомянутый мною итерационный метод Робинсон-Брауна. Только более эффективный и быстрее сходящийся.
Но как подружить любой из этих методов с нейросетью - вопрос остается открытым.
CFR позволит найти (рассчитать) оптимальные смешанные стратегии для конкретных заданных рук. А ИНС должна найти (пусть даже приближенно) эти оптимальные смешанные стратегии для любых рук, в т.ч. и для необсчитанных. Просто на основе опыта обучения игрой с самой собой.
Тут не столько от магазина зависит, сколько от каналов поставок. Много подделок на Озоне или Ситилинке. Еще больше, если покупать на АлиЭкспресс. Но даже в дистрибуции 3LOGIC GROUP подделки всплывали.
В любом случае покупать лучше не через Интернет-магазин, а через торговый зал. Дороже будет, но с возвратом меньше мороки.
И это нам еще повезло, что SSD оказались полностью нерабочими. И подделка была очень грубой. Обычно же в более-менее похожей упаковке и корпусе продают какую-то галимую шнягу с убогим контроллером и маленьким буфером. В результате SSD работает, но скорости - никакой.
При этом качество упаковки и корпуса такое, что нужно с лупой лазить по ним, чтобы найти отличия.
Вот недавно прочитал, что у оригинальных Samsung на задней крышке головки винтов под 5-лучевую звездочку, а у подделок - под крест. А остальное - практически как настоящее. Даже посадочные отверстия. Но кто мешает закупить такие винты?
А так, хорошую подделку можно определить только через тесты, анализ параметров S.M.A.R.T. Да говорят, что Samsung Magician на такие SSD ругается, что не оригинальные. Но это же не в магазине всё делать.
На самом корпусе SDD есть надпись "Samsung" (и серый квадратик). А покупали мы SSD, а не коробку.
Кроме того, "870 EVO" является зарегистрированной торговой маркой Samsung. Правда, в РФ она не регистрировалась. Ну так и SSD эти не в России делались.
Тут всё про гостевую сеть, как я понял. А как же локальная частная сеть для работы? Она имеет физические пересечения с гостевой или совсем отдельная?
Там же четко сказано: имитация. Имитация вывода имитации полезной нагрузки на имитацию геостационарной орбиты.
Звёздочки - это пошло.
На форуме "F1News.ru" уже лет 10 назад была внедрена система, заменяющая непарламентские выражения на дипломатические аналоги: Я огорчен. Накипело. Это возмутительно.
И достаточно к месту получалось.
А с 1999 глда не только фото, но и видео. На котором человек, похожий на генпрокурора развлекается с двумя шлюшками.
Не в тему, но по поводу стажеров ...
Тут на днях приходил пацанчик устраиваться. С мамашей. А нач отдела - любитель байков. И у него на стене висит календарь с голой бабой на мотоцикле. Ну не совсем голой - в шлеме.
Правильно! СНИЛС будет достаточно.
... к нам попал в волненьи жутком, с растревоженным желудком и с номерочком на ноге (C)
На файлопомойке Synology хотел использовать по расписанию команду, которая очищает папку от старых файлов. А она не работает. Потому что имя папки написано кириллицей.
А если попытаться выполнить ее не из планировщика, а из терминала, то удалится вся папка :(
Олды могут помнить, что в СУБД FoxPro (старой, еще DOSовской) обрезались строки с буквой "я".
Перефразируя Чехова:
Нет такого американского имени, которое не могло бы стать фамилией.
Нах нейм?
Офигеть, как смеялся! Напомнило анекдот.
Стоит мужик возле Букингемского дворца:
-- I fuck this fucking country! I fuck this fucking smog! I fuck this fucking cost!
Подходит полисмен:
-- Stop swearing! This is the Queen's residence!
-- I fuck your Quinn!!!
-- Indeed?
-- In bed!
-- Oh! Sorry, sorry, sorry ...