moozooh

Всё что угодно может быть похоже на шутку, глупость или магию, если не знать, как оно работает.

В случае с криптовалютами курс либо повышается с опережением, либо валюта становится нерентабельной и умирает. Чем больше веры в успех, тем больше курс опережает порог рентабельности. В этом смысле биток не сильно отличается от любого публично торгуемого предприятия сферы услуг.

В теории или на практике?

В отличие от большинства видов сырья стоимость добычи биткоина (т. е. требуемой энергии и вычислительных мощностей) растёт в геометрической прогрессии, то есть рост курса — неотъемлемое условие существования валюты. Рынок, зная это, работает на опережение.

Получается в разы быстрее и точнее чем по сенсорной клаве тыкать.

Вы безотрывным вводом не пользуетесь, что ли?

Стоимость добычи задаёт ценовой порог, а потолок зависит от спроса.

Разумеется.

А в чём смысл QWERTY-клавиатуры, на которой невозможно набирать текст ни десятью пальцами, ни одним?

Я бы не назвал это извращением по той простой причине, что любая файловая система сама по себе — частный случай БД. Многие системы контроля версий хранят или раньше хранили свои репы целиком в виде БД, хотя эта практика, насколько я понимаю, постепенно сходит на нет (возможно, это связано с общим прогрессом в ускорении дисковой подсистемы, которая уже не так сильно боится множества отдельных файлов, как когда-то давно). Вообще у обоих подходов есть свои плюсы и минусы, но я в них, признаюсь, не шибко силён, ибо совсем не мой профиль.

Обычными SSD решить можно, но даже не все MLC-HET они же eMLC там удовлетворяют требованиям по ресурсу.

Это очень сильно зависит от ситуации, но, например, у двухтерабайтных Samsung 960 Pro номинальный ресурс записи составляет 1,2 ПБ. База размером 100 ГБ, даже если полностью перезаписывается четырежды в день, выработает его ресурс только через ~8,6 лет, что превышает срок обслуживания сервера. Так что в описанных вами случаях, когда у компании небольшое число баз, в сумме не превышающих терабайта, вопрос ресурса обычно не встаёт.

Те же MLC имеют время стирания и перезаписи (чтение и запись в другую ячейку) весьма существенные. А для тех же БД, да и упомянутого пром. оборудования часто нужно «здесь и сейчас».

Существенные по сравнению с чем именно — с 3D XPoint, которого ещё недавно не существовало вовсе, или по сравнению с SLC, который уже по ряду причин не используется? Просто небольшой объём в конце концов можно и в оперативке кешировать, до чьих скоростей XPoint ещё не дорос. Плюс немалая часть задержек формируется уже за пределами ячейки — в контроллере, шине, сетевом интерфейсе, софте и пр. Или у вас какие-то конкретные примеры были на уме, где именно память MLC бутылила работу оборудования?

У моего бывшего работодателя, например. У него была своя система контроля версий, и поэтому даже код хранился в MySQL. В конторе работает больше сотни человек. В 2011–2012 работал на другую немаленькую компанию, которая хранила в MySQL изображения и другие медиафайлы, просто потому что это было самым очевидным решением их задач. На самом деле ситуация, когда на компанию приходится одна-две БД до сотни ГБ в сумме, вполне успешно решается и обычными SSD.

И мной это было написано

… с целью намекнуть на то, что вы уже знаете «правильный» ответ исходя из вашего понимания проблемы. По крайней мере именно это вычитывается из комментария.

По факту же, во-первых, наша информация о грузовике приходит примерно из тех же открытых источников, что и ваша, а во-вторых, я сильно сомневаюсь, что возможен предметный разговор с математическими выкладками (хотя если они у вас есть, буду признателен). Ну правда, на какой ответ вы рассчитывали? Вот лично мне было бы странно, если бы у тягача, который позиционируется как более экономный и неприхотливый в обслуживании, заметно быстрее изнашивался бы такой важный узел, как сцепление с прицепом.

в реальном использовании при нагруженном полуприцепе никто не будет газовать с пробуксовками

Тесла в принципе не газует с пробуксовками — там куча систем следит, чтобы их не было. В частности в презентации про защиту от складывания много слов было сказано, а это весьма актуальная проблема.

Ну опять же для кеша разве что. У среднего размера фирмы-разработчика разных баз с кодом как минимум на десятки терабайт, покупать сверхдорогущие Оптаны для хранения не целесообразно. А перед самыми загруженными базами кеш всё равно стоит.

Ну хватит уже, невозможно эту дичь читать. В 2011 я их на GTX 460 майнил. Тогда решил что не выгодно, а сейчас несколько недель майнинга в несколько десятков тысяч рублей превратились.

Больше ста компаний напрямую принимают биток в качестве оплаты. Советую внимательно просмотреть список, потому что некоторые имена вас сильно удивят.

Ну это само собой. Чтобы держать системный диск в пределах 64 или, тем более, 32 ГБ, нужно обращать на это очень несреднестатистическое внимание — а это мало кому интересно. На двух моих предыдущих рабочих местах даже админам было посрать на раздельное хранение системы и прочих файлов — причём что на рабочих машинах, что на серверах. Все клали яйца в одну корзину и поломки никого ничему не научили. Искренне благодарен своим друзям, которые ещё в 90-х открыли мне глаза на гигиену системы.

У вас необоснованно высокая планка нормального пользователя. Расположение этих папок меняют от силы несколько процентов пользователей.

Ответ Unforeseen на коментарий

Даже если кроме ОС ничего туда не класть, то система со временем имеет свойство распухать. К примеру, моей Win10 меньше года, на системном диске только ОС и программы, нет ни игр, ни пользовательских файлов, ни файла подкачки, ни поддержки гибернации, ни, даже, папок Temp. Занимает 58.7Gb.

Ну хрен знает. Вот моя после последней уборки (конец сентября), вот она же сегодня. Пухнет, конечно, но до 32 ГБ ей ещё очень далеко и я раз в полгода хлам подчищаю (прямо сейчас прошёлся RAPR'ом по старым драйверам и потом ещё штатной утилитой очистки диска по всему — отжал 732 МБ). Остальное сделано примерно так же, как у вас, хотя временные файлы у меня идут на этот же диск — просто в отдельную папку. Возможно, у вас программы очень много места занимают; у меня с NTFS-сжатием приходится около 12,5 на Program Files и Data и ещё 2,5 ГБ на AppData в пользовательском каталоге.

Ответ Guest_N на коментарий

16/32GB для ОСи — не хватит.

32 ГБ хватит, если ничего кроме ОС и файла подкачки туда не класть. Правда, и смысла в этом не то чтобы очень много.

Для нормального тестирования не хватило сравнения с SSHD (который по своему принципу примерно аналогичен связке HDD+Optane, только сильно дешевле) и с контрольным HDD+HDD, чтобы уйти от ситуации, когда служебные процессы забивают очередь диска (о чём в статье упоминали несколько раз, но почему-то по умолчанию определили, что эта проблема решается только добавлением кеширующего диска).

Теперь до сотни за 0,5 секунд разгоняются? Сурово.

Ответ nsktravel на коментарий

Коли насморка нет или какой-нибудь ушной непроходимости, то всё норм.

Ну как сказать. У меня есть друзья, которые во время взлёта-посадки спать нормально могут. А я если слюну не сглатываю каждые десять секунд, то уши так болеть начинают, что хоть на стенку лезь. :\