blacklion79

А вот где найти закваску как на Шри-Ланке используется — эх, узнать бы. Продукт получается заметно отличающийся, без малейшей кислинки вообще, и как будто желированный. Больше всего напоминает, как ни странно, панакотту, которую делают на желатине. Безо всякого желатина.
Пол-года бьюсь — ничего похожего в России найти не могу, а та контрабанда, что я привёз из Шри Ланки, выродилась и стала невкусной :-(

Совет про йогурты: можно не добавлять сливки а разводить (в молоке, не в воде!) и вмешивать сухое молоко, 25% которое. Примерно две чайные ложки с горкой на литр молока. Вмешивается лучше сливок, результат не хуже. И, кажется, заметно дешевле, так как за сливки наши производители хотят каких-то совершенно сумасшедщих денег.

И не только компьютерных, тут вот один производитель очень хороших пистолетов так разорился, анонсировал новую модель с алюминиевый рамкой — а доделать не успел, заказы встали, оборотных средств ноль, полное банкротство с аукционом.

«В прошлых функциональных апдейтах Windows 10, установка на ПК начиналась автоматически. » — нет, если выставить пару групповых политик. Домен для этого не нужен, всё делается локально.
У меня ни разу винде (10-ая) без моего разрешения ничего не ставила и не перегружалась.

А то, что шведы проголосовали ПРОТИВ *УДАЛЕНИЯ* скандальных 11 и 13 статей ПО ОШИБКЕ (и именно этого голоса не хватило чтобы их УДАЛИТЬ) вы не написали.
Клоуны, блин.

с индукцией магнитного поля 1,5 Тл

Ждём когда их переделают в томограф? А что, модели на 1.5Тл — вполне годные уже для некоторых задач, не всё же на 3Тл смотреть.

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

Спасибо :-)

Что-то дорого, 970 Pro за эти же деньги найти можно. А он очевидно лучше. Он вообще лучше.

Это о их картах которые для своего времени были «студийного» качества по сравнению с SoundBlaster 16.

Жаль, жаль. Зная отношение nVidia к Open source, это ни к чему хорошему для пользователей этих прекрасных сетевых карт не приведёт :-(

А теперь добавьте в анализ на сколько менее эффективным был при этом системный кэш. Без оценки всех уровней кэширования эти числа ничего не значат.
Несомненно, PrimoCache работает. Вопрос же не в его эффективности а в эффективности системы в целом. Кстати, хитрейт 17.8% это вообще ни о чём. На тех системах, где мне просто посмотреть (см. выше в другой ветке про торренты) я вижу 95% штатными средствами. На винде… Хмм… Надо поискать… Нашёл только моментальные показатели, там всё болтается на уровне 100%, но это фиговые показатели, хотелось бы, конечно, общее число байтов прочитанных из кэша и мимо кэша с момента старта системы. Пока не могу найти.
И, да, отложенная запись — это, повторю в который раз, — лотерея. И об этом знают и честно предупреждают авторы PrimoCache, за что им отдельный респект, что инженеры у них главнее маркетологов. Могли бы умолчать.
А красота идеи… Ещё во времена DOS 6.2 у MS была такая штатная утилита вообще-то (smartdrv). Сейчас, повторю, я на 95% уверен, что это не нужно, так как система и сама отлично справляется. Т.е. идея-то красивая, спору нет, но, во-первых, она стара примерно как иерархия памяти у вычислительной системы и, во вторых, очень трудно сделать правильно, множество тонкостей.

И, собственно, про deferred write, с которого и начлася весь этот разговор про кэширование, сами авторы PrimoCache пишут:

With the Defer-Write feature, PrimoCache can avoid the redundant writes and reduce wear on SSDs, thus prolonging the lifespan of SSDs. Of course, Defer-Write comes with a risk that data may be lost on system crashes or power failures. It is recommended that you may only enable Defer-Write on volumes where temporary, unimportant or reproducible data is to be stored.

.
Молодцы, честные.

Вот что у PrimoCache круто — это кэширование на SSD когда основной диск медленный. Это аналог L2ARC у ZFS и это действительно может быть очень полезно и совершенно безопасно.

Нет, им не всё равно, им дают разные команды (запись с разрешением кэширования и без разрешения), и они обязаны слушаться. Да, некоторые консьюмерские девайсы врут (не слушаются), и, да, это проблема. Конечно диски ничего не знают про файлы, но про каждую команду на запись группы блоков они знают, можно ли её кэшировать или надо давать ответ только после реальной записи. По крайней мере это так с тех пор как в SATA появился NCQ, до этого всё было чуть сложнее на ATA (у SCSI это было всегда).
Ещё раз: или мы слушаемся операционную систему и тогда всё наше кэширование только повторяет то, что уже сделала ОС сама в своих кэшах, или мы ей врём и тогда повышаем вероятность разрушения файловой системы.
Если бы у ОС не было кэша — как у DOS когда-то — то да, всё справедливо. Но нет, современные системы очень эффективно и агрессивно кэшируют все дисковые операции сами. У меня сейчас вот из 32 гигабайт памяти 19 гигабайт занято кэшом — как вы думаете, будет ли лучше, если я отрежу 8 гигабайт и буду кэшировать ещё раз, денржа кучу данных в памяти дважды?

Именно в работе с блоками и кроется подстава.
У любой FS есть два типа операций записи — те, что можно отложить ради увеличения эффективности (пользовательские данные если софт не сказал fsync() или его виндовый аналог а так же некоторые данные необходимые самой FS) и те, что откладывать нельзя, так как именно они обеспечивают целостность структур файловой системы. Любая FS спроектирована таким образом (ну, если не считать багов), что она остаётся в корректном состоянии именно потому что последовательность изменений её внутренних структур выстроена так, что когда все эти записи подтверждаются, то и файловая система не разрушена. Предпринимаются большие усилия на уровне дизайна файловых систем, что бы таких важных записей было поменьше потому что все понимают, что тормоза именно в них. Пример механизма группировки таких операций без риска нарушить целостность файловой системы — Soft Updates в файловой система FFS (я, увы, не знаком с последними достижениями файловых систем на Linux, так что примеров оттуда привести не могу).
В современных OS не бывает записи прямо на диск. Ну, почти не бывает, но, в общем, любая штатная запись проходит через тот или иной системный кэш. Причём, все современные OS (т.е. по сути Windows, MacOS, Linux и *BSD) настраиваются таким образом, что бы не держать свободную физическую память вообще. Как только появляется свободная физическая память — сразу же она отдаётся дисковому кешу. Если есть свободная память — это значит, нет ни тяжёлых программ ни дисковой активности вообще. Так вот, этот системный кэш — он знает про те записи, которые задерживать нельзя, потому что от их успеха зависит целостность файловой системы и драйвер файловой системы ждёт их честного подтверждения. И именно тут могут быть тормоза из-за частого обновления access time, например (а вы ещё не отключили его? А почему? А зачем вам atime, ну если вы вообще заботитесь о выжимании последних капель производительности?). Такую запись надо подтвердить во-первых, честно (т.е. не положить в кэш и подтвердить, а дождаться подтверждения от носителя что, впрочем, у бытовых носителей ничего не гарантирует, но это отдельная история) а, во-вторых, подтвердить быстро (потому что файловая система не делает никаких других операций пока не будет закончена эта).
Так вот, если мы встраиваем дополнительный уровень кэша в RAM (т.е. в непостоянной памяти), на уровне блоков, то у нас есть два пути: Первый путь — быть честными. И все важные (синхронные) записи пускать мимо кэша. Но тогда мы ничего не ускоряем а, скорее, замедляем, так как отъедаем память у системного кэша и данные кэшируются дважды. Один вред. Путь второй — врать. И откладывать даже такие синхронные записи. Ускорение некоторое будет, несомненно. Но вот тут мы играем с огнём — потому что мы врём. И если система рухнет в неудачный момент, то будут потеряны не только пользовательские данные записанные в последние секунды (это может быть и с системным кэшом, это ожидаемо), но и вместо согласованных структур данных файловой системы на диске может оказаться винигрет. Какие-то важные записи пройдут, какие-то нет, причём в худшем случае пройдут более поздние, сделанные в предположении, что предыдущие уже на диске. Так можно потерять гораздо больше, чем последние несколько минут данных. Так можно потерять и очень старые данные, и данные записанные час назад, и что угодно. Стоит ли небольшое ускорение этого? Решать вам. Но понимать это надо.
И есть ещё одна тонкость — так как операционная система и так старается раздуть свой кэш насколько это возможно, а мы теперь кэшируем ещё и блоки прямо с диска в той же памяти, то часть данных получается закэшированной дважды, а кэш системмы становится менее эффективным. Т.е. вообще-то можно получить даже проигрыш в производительности вместо выигрыша.
Вот на что будет интересно посмотреть — как файловые системы адаптируют к постоянным кэшам в памяти, когда NV-DIMM станут обыденностью. Вот тут наработки Rapid Mode и PrimoCache могут здорово пригодиться. Но пока NV-DIMM — серверная экзотика.

Никакой винды, файловая система ZFS с её штатным L2ARC. Выводы — имя терабайты торрентов и даже всего 16 гигабайт RAM, 120 гигов кэша второго уровня погоды не делают вообще никакой. У меня хитрейт в ARC (кеш в памяти) 95%, т.е. 5% чтений — с дисков, остальное уже в памяти. Из этих 5%, проскочивших мимо кэша, второй кэш на 120GB давал хитрейт всего в 10% (т.е. 0.5% относительно всех чтений), только зря SSD запили.

Проблема в том, что такое глубокое кеширование должно быть согласовано на уровне FS, т.е. FS должна про него знать. Иначе однажды мы получим разрушенную FS, так как ожидания и гарантии, которых FS ждёт от диска и которые ей необходимы для поддержания своей целостности, окажутся нарушенными. Если же этот кэш будет поддерживать все гарантии, то он ничего не сможет толком ускорить, так как все записи, которые FS ожидает увидеть синхронными («и система больше не ожидает сохранения изменённых данных, прежде чем они будут изменены вновь») он будет вынужден делать синхронно. А то, что не ожидается синхронным, и так может зависнуть в штатном буферном кэше операционной системы, NTFS, конечно, тупенькая, но не на столько что бы все записи делать синхронными.
Хороший пример встроенного глубокого кеширования — ZFS.

Ну, в локальных условиях, не обязательно домашних.

Загрузка винды — это первое чтение, никакое кеширование в RAM не может её ускорить.
РЕАЛЬНАЯ работа — это РЕАЛЬНЫЕ тесты, причём двойные-слепые.

Загрузка винды — нет, понятно почему. Приложений — лучше эти приложения смогут больше памяти использовать.
Ещё раз: это кеширование в RAM. Технология понятная, с понятными плюсами-минусами, но это не ускорение записи на SSD.

Ну какую реальную? Это кеширование в RAM.