Просто обычно в сц обращаются неквалифицированные в этом вопросе люди. Поэтому втюхать им батарейку — это просто и быстро, а перебирать батарею — это долго и дорого. Еще и автор забыл указать, что неоценил своей рабочее время, в сц время рабочего должно быть оценено по рыночной стоимости. И рабочий должен быть с такой квалификацией.
Из этого всего вывод такой: автор просто подхватил «гаражную» поломку, которую в рамках сц невыгодно ремонтировать, а выгодно самому в гараже.
Когда я пробовал его — там было все очень уныло.
Проблемы уже на этапе переноса своего контакта на другое устройство. Не знаю — может они эту проблему уже как-то решили.
Нефть падает, рубль падает — и биткоин тоже падает.
Вывод: в основном покупатели биткоина — это люди из стран, пострадавших от сложившейся ситуации: россияне и венесуэльцы. Меньше денег, значит меньше спрос, значит цена падает.
По другой версии всегда можно найти версию, оправдывающую любое наперед заданное поведение курса.
Не в любой.
В некоторых сортах нефти повышенное содержание серы, сера убивает катализатор практически сразу. Такие месторождения в основном находятся в россии.
В этом плане, топливные элементы весьма критичны к чистоте топлива. Шаг вправо-шаг влево — и ячейке хана. Один раз заправился некачественным топливом — и элемент можно выбрасывать.
Там не в кпд проблема, а в режиме горения водорода. Выгорает быстро (считайте — взрыв) и при более высоких температурах. Есть проблемы с ресурсом.
И кроме того — наверняка будут проблемы с экологией, в следующем плане. При температуре выше критической, азот, содержащийся в воздухе, соединяется кислородом, а потом оксид азота с водой с образованием паров азотной кислоты. Понятно, что эта проблема решается баллоном с кислородом, но таких балонов не настачишься и в идеале хотелось бы избежать необходимости возить с собой окислитель. Этой проблеме, кстати, подвержены и бензиновые двигатели, но если температура будет выше, то эффект только усугубится.
Есть разница между просто грязью, и объективными замечаниями. В нашей культуре и то и другое принято считать грязью, но на де-юре это не так.
К тому же надо понимать, что то, что говорится подобными людьми, отражает текущее состояние дел в среднесрочной перспективе. Примерно как фраза «640кб должно хватить всем». Она была сказана, если гугл не врет, в 1981, а стала неактуальной через 15-20 лет. И это с учетом, что отрасль интенсивно развивалась.
Это все, может быть, работет на компаниях, в которых предполагается, что калл-центр и остальные части компании (техотдел, например) работает качественно по умолчанию, а значит проблема всегда на стороне клиента, и она всегда решаема. Так же, подобный подход предполагает, что проблема клиента должна быть решена за 1 звонок. Тогда начинает работать вся эта теория. В остальных случаях, по моему убеждению, подобный подход оказывает негативный эффект и наносит вред. В некоторых случаях, так же, негативный эффект вызывает не сам факт наличия правил, а то, что они крайне безидейно написаны.
По личному опыту — когда звонишь в фирму, где каноны телефонного общения расписаны по пунктам, то даже если ты проблему решил — создается впечатление что они там тупые, и общее впечатление крайне удручающее. В некоторых случаях приходится даже преодолевать желание воспользоваться ненормативной лексикой.
Несколько стареньких (уже неактуальных) примеров.
1. Позвонил сотовому оператору и спросил о покрытии в стране Х. В ответ вопрос «как вас зовут?». Первая мысль — ну какое им дело? Почему он отвечает отвлеченным вопросом на конкретный вопрос? Потом уже понял — это обязывает спрашивать корпоративное правило. Но осадок остался.
2. Местный провайдер открыл жж и хвастается в нем, что его колл-центр самый лучший в стране, т.к. время ожидания на линии сократилось с 20минут до 10, что является очень высоким показателем. При этом то, что на решение простых проблем часто уходят недели — игнорируется. При этом сотрудники колл-центра все такие корпоративные, общаются по шаблонам — и это страшно бесит.
3. Этот же местный провадер. Колл-центр поставил на ожидание музыку в стиле «мы крутые». Периодически она прерывается и робот говорит «не отключайтесь! Ваш звонок очень важен для нас!». Круто? Да! В любой книге будет написано что-то типа — надо поставить крутую музыку, чтобы у клиента складывалось впечатление что он говорит с крутыми ребятами, которые обязательно ему помогут.
Но не учли вот что: такой подход для провайдера вообще не подходит!
Провайдеру обычно звонят клиенты когда проблемы связаны не с выбором альтератив, а с нерабочим оборудованием(при этом иногда оно ломается «на стороне провайдера»), или с непришедшими деньгами. Поэтому, музыка подобного стиля выглядит как жестокий стеб, а фраза «Ваш звонок очень важен для нас!» просто добивает, если ты ждешь 20минут. При этом, когда через 20 минут трубку берет очень вежливый но неквалифицированный сотрудник — это выглядит плохо, но еще хуже это выглядит если такой сотрудник начинает следовать корпоративным правилам общения.
4. Классика «не было ни единого разрыва» — это на самом деле хороший пример того, к чему приводят неверные корпоративные правила.
Возможно, правила должны быть, но только общего плана — типа не грубить, не тупить, не жевать разговаривая и тд и тп. Все остальное — это зло. Возможно, правильной тактикой будет «прощупывание» клиентов, дальнейшую его категоризацию и дальнейшие действия в зависимости от категории клиента.
Все равно, по моему мнению, это нелинуксовая технология. Какая будет завтра политика микрософта — мы знать не можем. При должном желании микрософт, как более крупная компания, может это моно как потопить, так и выкупить. Или выкупить и прекратить поддержку. Например.
Посмотрим, что будет дальше. Пока будущее моно неясно, а настоящее ненастолько светлое, чтоб можно было на эту технологию перейти.
Может, автору мягко так намекают, что он пиарит себя используя мощности сети, и поэтому неплохо бы на добровольных началах финансово простимулировать развитие проекта? Рашен бизнес ведь — он и в интернете рашн.
Честно говоря, глядя на то, как работает скайп под линуксом — я бы неособо надеялся, что в ближайшем обозримом будущем под линуксом будет полноценный стабильный шарп.
Насколько помню, студия делала mdb, а моно их просто не читало, хотя опцию --debug включал. Но инфа не 100%, т.к. это было давно. Делал еще какой-то финт ушами, но уже не помню что. Было это не менее, чем 2 года назад — т.е., так давно что уже точно неприпомню когда.
По этой же причине версию моно тоже не помню, могу лишь сказать что ставил самую последнюю на тот момент. Помню, что ставил из пакетов, с исходниками не возился. Поэтому какой там GC стоял — тоже сказать не могу.
Пару лет назад пришлось приводить в чувства проект под моно, доставшийся «в наследство». Сделал вывод — моно не подходит, на тот момент он был слишком сырой. Не думаю, что за это время что-то изменилось. Приложение было серверным и падало на продакшене где-то раз в два дня в коредамп. Установить истиную причину падений так и не удалось, хорошо что заказчика устроил перезапуск.
И еще там запомнился странный баг компилятора. Если в одном из файлов проекта в определенном месте добавить пробел — в шарпдевелопе под линуксом оно не собиралось. В последующих версиях, я пробовал — этот баг уже исправили, но все равно сам факт такого бага выглядит странным.
Кроме того, там была еще веб-морда, которая работала под вебсервером xsp2. И все хорошо, но стактрейсы оно показывало урезано — без номеров строк и имен процедур. Т.е., была видна только вложенность. Происходило это по той причине, что вижуалстудия дебажную информацию клала в отдельный файл, который под линуксом не понимался. Шарпдевелоп тогда вообще не умел делать проекты для xsp2, как сейчас — не знаю. Из за этого редкий глюк, который проявлял себя раз в несколько дней, найти так и не удалось. В итоге сошлись на том, что если глюк появляется — просто перегружают страничку.
С тех пор для меня решен вопрос «mono vs java». Если надо делать что-то под линукс — моно даже не рассматриваю как серьезную альтернативу.
Если вы про про доказательство формулы Эйлера — оно есть в википедии. А вот каким путем к ней пришел к ней Эйлер — мне б тоже было интересно посмотреть.
Нет, у меня все гораздо хуже с сетью. Если она медленная — она обычно еще и глючная.
Мне бы было гораздо полезней, если б оно пробивало nat и могло работать с меняющимся ip и на сервере тоже.
Т.е., исходим из того, что на клиенте и на сервере одновременно ip не меняется. И основываясь на этом, держим подключение.
На шаттлах — понятно, что не берут, но брали ли они его когда-либо раньше?
Из этого всего вывод такой: автор просто подхватил «гаражную» поломку, которую в рамках сц невыгодно ремонтировать, а выгодно самому в гараже.
Еще б добавить к каждому посту значок, указывающий откуда этот пост был подкачан.
Проблемы уже на этапе переноса своего контакта на другое устройство. Не знаю — может они эту проблему уже как-то решили.
Вывод: в основном покупатели биткоина — это люди из стран, пострадавших от сложившейся ситуации: россияне и венесуэльцы. Меньше денег, значит меньше спрос, значит цена падает.
По другой версии всегда можно найти версию, оправдывающую любое наперед заданное поведение курса.
Насколько я понимаю, немножко будет. Не так чтоб прям оно текло оттуда, но жизнь испортить хватит :)
Примерно, как оксиды серы с водой дают серную. Вроде ее мало — но глушитель за 2 года превращается в труху…
В некоторых сортах нефти повышенное содержание серы, сера убивает катализатор практически сразу. Такие месторождения в основном находятся в россии.
В этом плане, топливные элементы весьма критичны к чистоте топлива. Шаг вправо-шаг влево — и ячейке хана. Один раз заправился некачественным топливом — и элемент можно выбрасывать.
И кроме того — наверняка будут проблемы с экологией, в следующем плане. При температуре выше критической, азот, содержащийся в воздухе, соединяется кислородом, а потом оксид азота с водой с образованием паров азотной кислоты. Понятно, что эта проблема решается баллоном с кислородом, но таких балонов не настачишься и в идеале хотелось бы избежать необходимости возить с собой окислитель. Этой проблеме, кстати, подвержены и бензиновые двигатели, но если температура будет выше, то эффект только усугубится.
К тому же надо понимать, что то, что говорится подобными людьми, отражает текущее состояние дел в среднесрочной перспективе. Примерно как фраза «640кб должно хватить всем». Она была сказана, если гугл не врет, в 1981, а стала неактуальной через 15-20 лет. И это с учетом, что отрасль интенсивно развивалась.
По личному опыту — когда звонишь в фирму, где каноны телефонного общения расписаны по пунктам, то даже если ты проблему решил — создается впечатление что они там тупые, и общее впечатление крайне удручающее. В некоторых случаях приходится даже преодолевать желание воспользоваться ненормативной лексикой.
Несколько стареньких (уже неактуальных) примеров.
1. Позвонил сотовому оператору и спросил о покрытии в стране Х. В ответ вопрос «как вас зовут?». Первая мысль — ну какое им дело? Почему он отвечает отвлеченным вопросом на конкретный вопрос? Потом уже понял — это обязывает спрашивать корпоративное правило. Но осадок остался.
2. Местный провайдер открыл жж и хвастается в нем, что его колл-центр самый лучший в стране, т.к. время ожидания на линии сократилось с 20минут до 10, что является очень высоким показателем. При этом то, что на решение простых проблем часто уходят недели — игнорируется. При этом сотрудники колл-центра все такие корпоративные, общаются по шаблонам — и это страшно бесит.
3. Этот же местный провадер. Колл-центр поставил на ожидание музыку в стиле «мы крутые». Периодически она прерывается и робот говорит «не отключайтесь! Ваш звонок очень важен для нас!». Круто? Да! В любой книге будет написано что-то типа — надо поставить крутую музыку, чтобы у клиента складывалось впечатление что он говорит с крутыми ребятами, которые обязательно ему помогут.
Но не учли вот что: такой подход для провайдера вообще не подходит!
Провайдеру обычно звонят клиенты когда проблемы связаны не с выбором альтератив, а с нерабочим оборудованием(при этом иногда оно ломается «на стороне провайдера»), или с непришедшими деньгами. Поэтому, музыка подобного стиля выглядит как жестокий стеб, а фраза «Ваш звонок очень важен для нас!» просто добивает, если ты ждешь 20минут. При этом, когда через 20 минут трубку берет очень вежливый но неквалифицированный сотрудник — это выглядит плохо, но еще хуже это выглядит если такой сотрудник начинает следовать корпоративным правилам общения.
4. Классика «не было ни единого разрыва» — это на самом деле хороший пример того, к чему приводят неверные корпоративные правила.
Возможно, правила должны быть, но только общего плана — типа не грубить, не тупить, не жевать разговаривая и тд и тп. Все остальное — это зло. Возможно, правильной тактикой будет «прощупывание» клиентов, дальнейшую его категоризацию и дальнейшие действия в зависимости от категории клиента.
Все равно, по моему мнению, это нелинуксовая технология. Какая будет завтра политика микрософта — мы знать не можем. При должном желании микрософт, как более крупная компания, может это моно как потопить, так и выкупить. Или выкупить и прекратить поддержку. Например.
Посмотрим, что будет дальше. Пока будущее моно неясно, а настоящее ненастолько светлое, чтоб можно было на эту технологию перейти.
По этой же причине версию моно тоже не помню, могу лишь сказать что ставил самую последнюю на тот момент. Помню, что ставил из пакетов, с исходниками не возился. Поэтому какой там GC стоял — тоже сказать не могу.
И еще там запомнился странный баг компилятора. Если в одном из файлов проекта в определенном месте добавить пробел — в шарпдевелопе под линуксом оно не собиралось. В последующих версиях, я пробовал — этот баг уже исправили, но все равно сам факт такого бага выглядит странным.
Кроме того, там была еще веб-морда, которая работала под вебсервером xsp2. И все хорошо, но стактрейсы оно показывало урезано — без номеров строк и имен процедур. Т.е., была видна только вложенность. Происходило это по той причине, что вижуалстудия дебажную информацию клала в отдельный файл, который под линуксом не понимался. Шарпдевелоп тогда вообще не умел делать проекты для xsp2, как сейчас — не знаю. Из за этого редкий глюк, который проявлял себя раз в несколько дней, найти так и не удалось. В итоге сошлись на том, что если глюк появляется — просто перегружают страничку.
С тех пор для меня решен вопрос «mono vs java». Если надо делать что-то под линукс — моно даже не рассматриваю как серьезную альтернативу.
Мне бы было гораздо полезней, если б оно пробивало nat и могло работать с меняющимся ip и на сервере тоже.
Т.е., исходим из того, что на клиенте и на сервере одновременно ip не меняется. И основываясь на этом, держим подключение.