Похоже на кальку с США.
Сам был в шоке, когда в магазине заставили расписаться на сенсорном экране, а не на чеке. Можно же и подделать!
Вот только в Штатах клиент всегда прав. У него есть 30 дней на то, чтобы сказать «это не я платил» и тогда продавец должен доказывать факт покупки.
Там это работает на доверии, уж не знаю что делают с теми кто не оправдывает доверия.
Будет ли работать у нас — не знаю.
А вообще кассир супермаркета может столько карточек собрать за смену (в том числе и с подписями), что просто ужас. Самое надёжное — не держать много денег на засвеченной карте. Держать на счёте рядом и переводить по мере надобности. Ну и строить что-то умнее на замену картам.
Доставка товаров с оплатой курьеру.
Курьер обычно везёт фискальный чек, гарантийку, получает наличные и уходит. С этой фиговиной ему можно заплатить картой.
Если будет нагнетание, то будут и утечки.
Их система предотвращения утечек на том и работает, что если будет дырочка, то воздух будет засасываться, а не вода вытекать. Нельзя нагнетать воду, можно только всасывать её
Возьмем плотность жидкости за 0,998г/см3. Это с округлением 100 кг/м3
Нет, не 100 (сто), а 1000 (тысяча). Значит, что скорость в идеале будет 14 м/с
Сколько нагнетают насосы нам не важно, сосать сильнее чем 1 атмосфера они всё равно не смогут.
И что-то мне страшно из-за того, что они подают холодную воду и охлаждают воздух до комнатной температуры.
Typically operating between 14C and 18C
Пусть комнатная температура 30 градусов (как и вода на выходе), а вода на входе 14 градусов. Перепад 16 градусов, каждый грамм воды унесёт 16 калорий или 67,2 джоуля. 1 литр воды в секунду = 67 kW — как раз как они говорят.
Но это в идеальных условиях, интересно что у них в жизни будет. Чтобы вода хорошо нагревалась нужен длинный теплообменник, а чтобы текла с хорошей скоростью — короткий. Разве что несколько насосов стоит в дверце (и потихоньку растёт диаметр трубок). Но дверца будет весить побольше шкафа.
У меня все фотки лежат дома на сервачке.
С рождением сына их стало много. Обучаю бабушек тыкнуть пимпу и смотреть их. Купили видеокамеру, тоже много получается.
Тут надо скорости. Редко но быстро.
С появлением FullHD ноута стал обращать внимание на разрешение на youtube, хочется минимум 720p. Тоже траффик.
А вообще Google говорил, что это эксперимент, типа надо дать людям и посмотреть что из этого выйдет. Вот мы и посмотрим.
IMHO они клонят к переходу в облака и на Chromebook или Android. Если у тебя всё в облаке, то коннект должен быть быстрым, иначе оно не работает.
Рассчитано это на разработчиков, у них есть доступ в интернет. Это не потребительский телефон.
Очевидно, что Google может сделать супер телефон, но это же убьёт его отношения с производителями, это будет уже Apple какой-то. IMHO Google старается делать несколько ущербную (нет карточки, встроенный аккумулятор) модель обвешанную всеми возможными датчиками (та же зарядка беспроводная) у разных производителей (HTC, Samsung, LG).
Рекламы у Nexus'а тоже не очень много.
В итоге разработчики могут обкатать разные плюшки и написать программы/плагины/виджеты для любого «прибамбаса» (например, включения офисного режима, когда телефон оказывается на беспроводной зарядке в будний день).
Производители телефонов налаживают отношения с Google.
Для старенького Galaxy S (i9100) на стоковой прошивке помогло установить Dialer One и теперь система спрашивает чем звонить. При просмотре страницы это настораживает и позволяет не попадаться.
А вообще да, бяка страшная и не понятно как будут латать старые модели
Там есть несколько вариантов:
1. Втыкают растворимый (водо-растворимый) пластик. Напечатал, отмочил и крути.
2. Масса порошка (очень тонкого порошка), который подсыпают и поливают клеем. Надо будет вытрясти порошок из соединений
3. Тонкие подпорки из основного материала, который потом ломаются.
Есть проблема не только тепла, но и размера. Скорость света в ваккуме 300_000_000 м/с, скорость света в меди 200_000_000 м/с. То есть на 2GHz за 1 такт ток протечёт только 10 см. А если 4 GHz, то всего 5.
При том, что надо бы несколько транзисторов использовать за такт.
То есть мы просто не успеем бегать по большому кристаллу и не дотянемся до дальних транзисторов.
Если нужен «большой процессор», ставьте 2 рядом, или 200. Только разговаривать они между собой будут на низких скоростях.
Интересно, а как они с утечкой гелия собираются бороться?
И можно ли будет перевозить эти диски в самолёте, там же давление пониже будет, не разорвёт ли винт?
Надо 500 суток лететь туда-обратно. Всё это время космическая радиация будет жарить, где-то читал, что чтобы заменить атмосферу и магнитное поле земли надо стенку из железа всего 2,5 метра толщиной.
То есть люди будут лететь и просвещаться.
Ну и людей надо назад везти, в отличии от роверов.
Получается очень дорого и не понятно зачем. Роботы развиваются очень быстро и массу задач можно будет решить ими, а не людьми.
Мне показалось, что в aio будет проблема с сигналами, так как сообщения от ядра идут именно через сигналы. Не много ли вызовов будет?
Грубо, на один вызов select/poll/epoll мы можем получить сотню дескрипторов и их обработать. В случае aio это будет сотня сигналов.
Более того, мы в сигнале не можем особенно делать системные вызовы, поэтому мы всё равно сделаем свою очередь, которую будем пополнять в обработчике сигналов, а читать в общем цикле.
В aio круто то, что можно послать большой буфер в fd одним вызовом, но мы упираемся в память сервера на 10k больших буферов. Если же шлём контент из файла, то sendfile ничем не хуже.
Если бы не сигналы, а возможность выгребать события из очереди…
rrdcached выглядит каким-то половинчатым.
Он аккумулирует данные, но не даёт прочитать их из кеша. Только записать на диск. То есть если надо работать с данными, например посчитать агрегат или ещё чего, то есть записываем на диск и читаем с диска.
Плюс он сам пишет на диск в непредсказуемый момент.
Проблема в том, что никто не будет смотреть на 1000 графиков разом. У нас есть скрипты, которые собирают данные в несколько небольших dashboard и они читают много rrd'шек, сильно больше 1000. То есть кеш на ключевых метриках работать не будет и винт будет грузиться
Да, большинство метрик не жалко вообще стереть, но и на них кеш будет переполняться и грузить винт и не давать работать ключевым метрикам.
Я вообще сомневаюсь, что кеш будет хорошо работать в случае одновременного апдейта всех rrd раз в 5 минут.
Идея то в чём, в том, что с точки зрения диска что записать одно измерение, что 20 одинаково трудоёмко, считать файл с диска и записать на диск.
То есть надо держать в памяти по несколько измерений каждой метрики, плюс некая служебная информация (которая в нашем мире динамической памяти часто очень большая). При этом надо постоянно обращаться к кешу при каждом чтении/записи, что тоже нагрузка на процессор.
Почему бы не положить всё в память и работать с памятью? Особенно если оно туда влазит. Быстрее же будет и заметно проще.
А оно влазит! Память стоит всё дешевле и дешевле, причём закон Мура тут ещё будет долго работать, в отличии от процессоров.
Но мог же и спереть данные карты!
Сам был в шоке, когда в магазине заставили расписаться на сенсорном экране, а не на чеке. Можно же и подделать!
Вот только в Штатах клиент всегда прав. У него есть 30 дней на то, чтобы сказать «это не я платил» и тогда продавец должен доказывать факт покупки.
Там это работает на доверии, уж не знаю что делают с теми кто не оправдывает доверия.
Будет ли работать у нас — не знаю.
А вообще кассир супермаркета может столько карточек собрать за смену (в том числе и с подписями), что просто ужас. Самое надёжное — не держать много денег на засвеченной карте. Держать на счёте рядом и переводить по мере надобности. Ну и строить что-то умнее на замену картам.
Курьер обычно везёт фискальный чек, гарантийку, получает наличные и уходит. С этой фиговиной ему можно заплатить картой.
Их система предотвращения утечек на том и работает, что если будет дырочка, то воздух будет засасываться, а не вода вытекать. Нельзя нагнетать воду, можно только всасывать её
Нет, не 100 (сто), а 1000 (тысяча). Значит, что скорость в идеале будет 14 м/с
Сколько нагнетают насосы нам не важно, сосать сильнее чем 1 атмосфера они всё равно не смогут.
И что-то мне страшно из-за того, что они подают холодную воду и охлаждают воздух до комнатной температуры.
Пусть комнатная температура 30 градусов (как и вода на выходе), а вода на входе 14 градусов. Перепад 16 градусов, каждый грамм воды унесёт 16 калорий или 67,2 джоуля. 1 литр воды в секунду = 67 kW — как раз как они говорят.
Но это в идеальных условиях, интересно что у них в жизни будет. Чтобы вода хорошо нагревалась нужен длинный теплообменник, а чтобы текла с хорошей скоростью — короткий. Разве что несколько насосов стоит в дверце (и потихоньку растёт диаметр трубок). Но дверца будет весить побольше шкафа.
А вообще идея интересная
То есть смотреть HTTPS сайты им нельзя
В общем правильно делает, но попытка зайти на google play через переводчик не удалась :(
С рождением сына их стало много. Обучаю бабушек тыкнуть пимпу и смотреть их. Купили видеокамеру, тоже много получается.
Тут надо скорости. Редко но быстро.
С появлением FullHD ноута стал обращать внимание на разрешение на youtube, хочется минимум 720p. Тоже траффик.
А вообще Google говорил, что это эксперимент, типа надо дать людям и посмотреть что из этого выйдет. Вот мы и посмотрим.
IMHO они клонят к переходу в облака и на Chromebook или Android. Если у тебя всё в облаке, то коннект должен быть быстрым, иначе оно не работает.
И 10 градусов разницы с улицей тоже жесть. Если на улице комфортные +25, то внутри +35.
Очевидно, что Google может сделать супер телефон, но это же убьёт его отношения с производителями, это будет уже Apple какой-то. IMHO Google старается делать несколько ущербную (нет карточки, встроенный аккумулятор) модель обвешанную всеми возможными датчиками (та же зарядка беспроводная) у разных производителей (HTC, Samsung, LG).
Рекламы у Nexus'а тоже не очень много.
В итоге разработчики могут обкатать разные плюшки и написать программы/плагины/виджеты для любого «прибамбаса» (например, включения офисного режима, когда телефон оказывается на беспроводной зарядке в будний день).
Производители телефонов налаживают отношения с Google.
А простые люди будут покупать SGS III
А вообще да, бяка страшная и не понятно как будут латать старые модели
Наверное ультразвуковые ванночки помогут. Моют же печатные платы от флюса, в том числе и места под элементами.
Вот чего нашёл www.youtube.com/watch?v=MQtedzkmKlQ (модель двигателя, одним куском)
Говорит печатал 28 часов и 2 дня отмачивал.
Но это не Кубик Рубика, кубик надо будет дольше отмачивать.
1. Втыкают растворимый (водо-растворимый) пластик. Напечатал, отмочил и крути.
2. Масса порошка (очень тонкого порошка), который подсыпают и поливают клеем. Надо будет вытрясти порошок из соединений
3. Тонкие подпорки из основного материала, который потом ломаются.
При том, что надо бы несколько транзисторов использовать за такт.
То есть мы просто не успеем бегать по большому кристаллу и не дотянемся до дальних транзисторов.
Если нужен «большой процессор», ставьте 2 рядом, или 200. Только разговаривать они между собой будут на низких скоростях.
И можно ли будет перевозить эти диски в самолёте, там же давление пониже будет, не разорвёт ли винт?
То есть люди будут лететь и просвещаться.
Ну и людей надо назад везти, в отличии от роверов.
Получается очень дорого и не понятно зачем. Роботы развиваются очень быстро и массу задач можно будет решить ими, а не людьми.
Фобос-Грунт 2 раза откладывали. Может стоило и 3-ий раз отложить.
Меня вот удивляют кабели из США в США, из Китая в Китай и т.д.
На суше же легче обслуживать, легче питать. Ладно если голый кабель лежит, но каждый ретранслятор это же проблема.
Грубо, на один вызов select/poll/epoll мы можем получить сотню дескрипторов и их обработать. В случае aio это будет сотня сигналов.
Более того, мы в сигнале не можем особенно делать системные вызовы, поэтому мы всё равно сделаем свою очередь, которую будем пополнять в обработчике сигналов, а читать в общем цикле.
В aio круто то, что можно послать большой буфер в fd одним вызовом, но мы упираемся в память сервера на 10k больших буферов. Если же шлём контент из файла, то sendfile ничем не хуже.
Если бы не сигналы, а возможность выгребать события из очереди…
Он аккумулирует данные, но не даёт прочитать их из кеша. Только записать на диск. То есть если надо работать с данными, например посчитать агрегат или ещё чего, то есть записываем на диск и читаем с диска.
Плюс он сам пишет на диск в непредсказуемый момент.
Проблема в том, что никто не будет смотреть на 1000 графиков разом. У нас есть скрипты, которые собирают данные в несколько небольших dashboard и они читают много rrd'шек, сильно больше 1000. То есть кеш на ключевых метриках работать не будет и винт будет грузиться
Да, большинство метрик не жалко вообще стереть, но и на них кеш будет переполняться и грузить винт и не давать работать ключевым метрикам.
Я вообще сомневаюсь, что кеш будет хорошо работать в случае одновременного апдейта всех rrd раз в 5 минут.
Идея то в чём, в том, что с точки зрения диска что записать одно измерение, что 20 одинаково трудоёмко, считать файл с диска и записать на диск.
То есть надо держать в памяти по несколько измерений каждой метрики, плюс некая служебная информация (которая в нашем мире динамической памяти часто очень большая). При этом надо постоянно обращаться к кешу при каждом чтении/записи, что тоже нагрузка на процессор.
Почему бы не положить всё в память и работать с памятью? Особенно если оно туда влазит. Быстрее же будет и заметно проще.
А оно влазит! Память стоит всё дешевле и дешевле, причём закон Мура тут ещё будет долго работать, в отличии от процессоров.