MIDIMaker

Нам так на HP'шный сервер на замену пару блоков питания дали с формулировкой «Все равно они каждую весну горят»… и действительно — каждую весну сгорал блок питания.

Просто сверху надо было наклеить обычную защитную пленку.

Уже не один раз было такое, что в LibreOffice не отображались картинки из документов и даже часть текста, причем я бы не сказал, что там сложное форматирование было. И из-за этого даже вылез убыток под лям из-за того, что в документе отображался не весь текст — после этого MS Office есть у всех, кто работает с внешними документами. А таких обычно немало в организации несколько крупнее ларька. Да и какая вообще может быть экономия, если стоимость офиса — это зарплата на 1 неделю работы сотрудника, который в итоге неэффективно работает с LibreOffice?

10x по горизонтали и 10x по вертикали. Итого 100x, на выходе будет 0,2 Мп ;)

А вообще, с цифровым зумом только стыд является ограничителем цифры — у меня была камера Sony, еще аналоговая, с зумом 560x. Ну, 20x были оптическими, еще 28x — цифровыми… надо заметить, матрица там была примерно 384 точки по горизонтали, так что на максимальном приближении по горизонтали получалось 12 размазанных пикселов. И Sony было не стыдно.

В начале видео видно, что на уровне земли охват около 40-50 метров по горизонтали. При 50-кратном увеличении охват составит около 80-100 см. Вот до резкого рывка в конце похоже на 50x, дальше — уже гораздо больше 50x.

Да просто они так видят эту функцию :)

Именно что 2 — в CrystalDiskMark в тесте 4K Q1T1 она показывает 0,008 Мб/с за запись (этот тест характерен для имитации записи кучи мелких файлов). Причем эту цифру я видел на многих дешевых флешках. Стирание ведь очень длительная операция — она длится десятые доли секунды. Не зря SSD заранее готовят стертые блоки.

Из самого свежего — Perfeo S05 128 Gb USB 3.0 ;) А так — ситуация типичная для дешевых флешек — туда ставят самый тупой контроллер, который не умеет стирать блоки заранее, поэтому когда вы начинаете его долбить запросами по 4 кБ, он начинает выполнять read — modify — erase — write последовательность для каждого запроса. А поскольку блок там несколько мегабайт, канал один, и флеш самая медленная — то запись получается очень медленная. Кстати, еще одна причина, почему без кеширования записи будет медленнее — это как раз этот самый цикл read — modify — write, когда чтобы записать 64 кБ типичного запроса на запись, флешке придется стереть и перезаписать блок на 4 Мб или даже больше. Тогда как с кешированием может набраться достаточно команд, чтобы перезаписать блок полностью.
P.S. Самое что интересное — SD-карты в этом тесте показывают себя гораздо лучше — даже самые дешевые 200-400 IOPs на запись мелкими блоками выдают.

При отключении кеширования записи система будет постоянно обновлять метаданные — после каждой операции записи. Учитывая скорость в 2 IOPs на обычных ширпотребных USB флешках, скорость будет менее 1 Мб/с…

Что, шаблон рвется? Просто в системе нет всякой жрущей батарею фигни — там все еще стоит Android 4.2.2 с завода без обновлений, и ни одного установленного дополнительно приложения. Лежать в стандбае — много энергии не надо. Если не стоит приложений, которые постоянно «будят» процессор — поддерживать надо только GSM связь (причем оно все аппаратно делается с минимальным потреблением), для которой у тех же кнопочных телефонов 1000 мА*ч хватало на 2 недели.

Офигеть достижение… купленный за 50$ Huawei Y511 с аккумулятором на 1730 мА*ч держится в режиме ожидания + немного разговоров 16 дней… думаю, если бы просто лежал — дней на 20 хватило бы.

Зачем вообще какая-то зарядка, когда у каждого дома есть микроволновка. Положил девайсы в микроволновку, включил на 5 минут, вынул заряженные девайсы.

Ну просто много данных ввели, и таблиц в типовом решении дофига. Опять же, некоторые приложенные файлы в БД хранят вместо того чтобы настроить хранение в томах на диске.

А что вы ожидали там увидеть? Вычисления производятся в tempdb, а основная база хранит данные.

Сейчас почти все плохо оптимизировано. Это такой тренд — сокращение сроков разработки в ущерб производительности. Тот же MSSQL не может в общем случае безопасно использовать многоядерность при выполнении одного запроса — при определенных запросах и условиях возникают дедлоки — когда один поток блокирует другой, выполняющий этот же запрос. Чтобы безопасно использовать многопоточное исполнение запроса — надо тщательно тестировать каждый запрос, чтобы исключить такие ситуации. Это требует более высокой квалификации программистов и тестировщиков, а также увеличивает сроки разработки, что, в итоге, выливается в увеличение затрат на R&D, которые запросто могут перекрыть экономию на стоимости процессора, а также приводит к потере доли рынка, потому что конкуренты раньше выводят на рынок новый продукт. Ну и управляющий код, как ни крути, при обращении к критическим ресурсам будет упираться в производительность одного ядра.

Для 1С тоже не пойдет — ей нужна максимальная частота 1 ядра. Для максимального использования возможностей SSD тоже не подходит — драйвер один фиг упирается в 1 ядро в критических секциях (впрочем, такое много где случается — в тех же СУБД, например, при низкой частоте 1 ядра увеличивается время блокировок, что приводит к лавинообразному росту взаимоблокировок при увеличении нагрузки, и никакие ядра не помогут, т.к. при активной работе остальные будут ждать пока отработает одно ядро). В общем, довольно специфическое применение у этого процессора.

Ну, оснастка для литья может и больше пары миллионов стоить. Для производства нескольких экземпляров нет смысла запускать серийное производство.

Интересно, как перекомпилировать не имея исходных кодов? Или что-то рассчитанное только на Intel byte order…

Время, затраченное на LZMA сжатие, сильно зависит от настроек, и, собственно, реализации алгоритма (потому как LZMA — это именно алгоритм), и того, насколько реализация учитывает аппаратные особенности железа, на котором работает. Где еще, кроме GeekBench, используется эта же реализация LZMA? В этом контексте сравнивать надо реальный софт.