Обновить
4

Пользователь

1
Подписчики
Отправить сообщение

Абзац говорит про экспоненту вроде той, что в законе Мура, она безупречно вела себя до ~2010 года.

А потом начала жадничать
https://jcmit.net/flash2015.htm

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

На основе чего предложили бы делать прогнозы об этих оптических накопителях?

Старая шутка про экстраполяцию

Можно ведь смотреть на 5dmemorycrystal как на этап отмирания оптических накопителей.

Сначала повсеместно были DVD (и существовали диски "повышенной живучести": Data Tresor Disc, M-DISC).

Потом - менее популярные Blu-ray (тут тоже M-DISC и ещё BD-R HTL).

Потом - кипятившиеся в рекламе Archival Disc, которые не достались домашним пользователям.

И теперь - накопители, которые дороже всех перечисленных и привод к которым не сможет купить даже бизнес (запись и считывание теперь являются услугой). Которые напирают на плотность записи (5D) и бескомпромиссную живучесть, хотя нужно экспоненциальное удешевление (клиентам нужна цена, а не плотность) и было бы достаточно 100 лет (так нельзя, это реклама M-DISC).

В них можно было бы сохранить совместимость с CD/DVD/BD (нынешние ёмкости находятся на том уровне или ниже), но это распугает инвесторов - они заметят сходство со старой и давно реализованной идеей - использовать стеклянные мастер-диски для проигрывания вместо размножения и штамповки (кажется, примерно так устроены Syylex, SDG-Masterglass и ガラスCD).

Из комментариев под старым постом:

BabayMazay:

В конце концов, можно потратится и на неон, он таки продается, хоть и дорого.

...

Беглый поиск показал -- как будто бы несколько десятков литров неона можно дистанционно купить с пересылкой. Когда будут все материалы и нужное оборудование, отработана технология, можно попробовать лампы и с неоном.

https://habr.com/ru/companies/ruvds/articles/880712/comments/#comment_27921270

пару лет назад

Четырнадцать?..

Микрофоном при желании можно настоящую померять.

5400/5640/7200 об/мин = 90/94/120 Гц

Гуглится фото версии на 3 ТБ, если кому-то надо.

WD30EFPX

На community.wd.com неделю назад обсуждали поддельный WD30EFRX с AliExpress.

Он про то, что одной старой модели HDD от WD придали вид другой новой модели, не про появление новых производителей Western Gate, SeaKing и Shibaura Digitaru.

hg repack

Мда, это не то, о чём я думал, это часть расширения для кэширования данных с сервера.
А про хранение документация говорит, что "once an object is in the store, it is in its final place in the store and no further optimization is performed".
Ближе к теме revlog.reuse-external-delta=no и настройки сжатия (generaldelta, revlog-compression-zstd,...).

Ещё к вопросу первичности дельт vs снапшотов в разных системах:

Subversion manages versioned trees as first order objects (the repository is an array of trees), and the changesets are things that are derived (by comparing adjacent trees.) Systems like Arch or Bitkeeper are built the other way around: they're designed to manage changesets as first order objects (the repository is a bag of patches), and trees are derived by composing sets of patches together.

В Git Book интересно, что

  • заявление касается систем нового поколения (т.е. 2005+ и распределённых)

  • речь идёт в том числе о хранении: "storing data as changes to a base version of each file", "Git doesn’t think of or store its data this way"

  • есть чёткое противопоставление: наши дельты - это скрытая деталь реализации, их дельты - часть неудачного интерфейса (протекают в интерфейс)

  • где этот неудачный интерфейс в новых системах? hg repack, fossil repack существуют; с упомянутым в книге bazaar не знаком, но пишут, что он "stores a set of related file versions together, and then does gzip entropy compression across the whole set of them"

  • стиль этого раздела выглядит очень напористо (словно он должен провозглашать правильность отсутствия отслеживания переименований)

Наоборот, хранение снапшотов вместо дельт позиционируется как основное отличие Git от других систем контроля версий.

Снимки, а не различия [Snapshots, Not Differences]

Основное отличие Git от любой другой системы контроля версий (включая Subversion и её собратьев) — это подход к работе со своими данными.

...

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

- https://git-scm.com/book/ru/v2/Введение-Что-такое-Git%3F

Под снапшотами можно иметь в виду много чего, но в смежной сфере (бэкапы) под снапшотами часто понимают[1][2] уход от обычной негибкой цепочки из дельт к, эээ, "хардлинкам на блочном/файловом уровне". Мы можем удалить любой снапшот и физически удалятся только те блоки/файлы, на которые не осталось ссылок.

На самом деле, конечно, Git использует "цепочки из дельт разумной длины" ради сжатия, как и остальные системы контроля версий. И ему, конечно, нельзя удалять старые состояния как в бэкапах - в сфере контроля версий нужна вся история и иммутабельность. О какой тогда принципиальной разнице говорит Git Book? Либо это восторженная реклама, либо у Git на самом деле есть "более сильная абстракция снапшота", но верится с трудом и доказательств путём сравнения с, например, Hg не видно.

bleepingcomputer получили ответ от Espressif, что уязвимостью они это не считают, но команды уберут.

Update 3/10/25: Added Espressif statement

"While these debug commands exist, they cannot, by themselves, pose a security risk to ESP32 chips. Espressif will still provide a software fix to remove these undocumented commands," says Espressif.

Степень логичности такая, что создали два сайта-бредогенератора, высмеивающих команды git'а.
https://git-man-page-generator.lokaltog.net/#YWRkJCRoaXN0b3J5
https://web.archive.org/web/20140413194418/http://www.antichipotle.com:80/git/
(для них ещё предлагали практическое использование: проверять знание git'а, показывая эти страницы)

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

Оптические накопители уходят в прошлое, 3D XPoint (память в SSD Intel Optane) была лучше флеша, но умерла из-за цены, про ДНК и кристаллы спекулируют, потому что футуристично и на слуху. Как углеродные нанотрубки. Было бы странно, если бы на них не сделали память.

А футуристичность - это плохое основание для прогнозов. Можно аналогично заметить, что голографию очень легко объявить технологией будущего. Сколько раз это делали? И где она сейчас? Сейчас это очень нишевое хобби, которое живёт на одном маленьком форуме, где несколько раз в год что-нибудь выкладывают.

Я про унобтаний пошутил, а ведь статья на securities.io ведёт на 5dmemorycrystal.com, которые свой продукт также называют Superman memory crystal. Они предлагают заказать гравировку данных в стекле, от 500 МБ за 3 тысячи долларов. Это несерьёзно и продаётся как сентиментальный подарок или атрибут для церемоний.

Это нагнетание от команды хабра.

От bleepingcomputer: "Depending on how Bluetooth stacks handle HCI commands on the device, remote exploitation of the commands might be possible via malicious firmware or rogue Bluetooth connections". То есть надо написать специальную прошивку, выставляющую по сети доступ к внутреннему интерфейсу... чтобы что? Чтобы было что взламывать?

Кажется, такого нет даже в оригинале Tarlogic, где они себя агрессивно рекламируют.

И там, и там дали заднюю насчёт "бэкдора".

На слайдах (DEMO 2, стр. 43) после слов "ЧТО МЫ МОЖЕМ ДЕЛАТЬ С ЭТИМИ КОМАНДАМИ?" шлют спам... без использования недокументированных команд. Выделяют красным команду смены MAC-адреса, словно для этого нет официальной функции. Или я чего-то совсем не понимаю, или они себя ведут как мудаки.

О ютуб-канале

Это опять поддельные бенчмарки. Доставать дорогущее железо до начала продаж ради слайд-шоу с диаграммами не нужно. Загрузка по 24 видеоролика за сутки тоже намекает.

Но результаты не обязательно будут врать, их ведь могут парсить из настоящих обзоров: https://videocardz.com/189651/amd-ryzen-7-9800x3d-review-roundup

Ответ A

Ответ Б: если бы на том сайте и не было поддельных данных, всё равно игровому компьютеру важна производительность в играх, а не "вообще". Играм надо 6-8 максимально быстрых ядер и кэш они любят.

Мечтать таким образом приятно, но если серьёзно...

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

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

И покупать диски на 20 лет вперёд - значит, переплатить в десятки раз.
2005: $365 / 500ГБ ~= $700 / ТБ (1200 современных $) против нынешних $15.

И двигать цель смысла нет. О нужности 80-100 ТБ в будущем сигнализирует наличие 20-30 ТБ сейчас. Если сейчас не куплены диски на 20-30 ТБ, то и в будущем 80-100 ТБ не возьмутся.

Это будет под тыщу долларов за диск. Ну, 700+ долларов, если цена за терабайт снизится в два раза (что с учётом нынешних темпов будет неплохо). Кассета на 50 терабайт сейчас примерно столько стоит.

Можно припомнить удивительную новость (оригинал), что каждая четвертая-пятая карта из продающихся сейчас в Корее - это RX 570 (ну, "RX 580 2048SP"). "На основе данных о продажах Danawa Research".

(ещё один некровзгляд на неполноценность типа массива)

Я бы сказал - ошибка в том, что array to pointer decay случается чаще, чем необходимо. Информация о размере массива слишком легко отваливается и обратно её нельзя прикрепить.

  • Функцию void f(int a[3]) можно вызвать на статическом массиве любого размера, ну ладно.

  • Но внутри функции sizeof a даже не вернёт 3*sizeof(int), распад до int *a случился. Ладно, всё равно полезность была бы ограничена - в качестве размера может быть только константа.

  • И тут в C99 добавляют VLA (variable length arrays), что разрешает конструкцию void f(int n, int a[n]);. Однако ошибка уже закреплена в языке и пользы практически нет: в других случаях sizeof вернёт размер VLA-массива, но только не для "VLA в списке аргументов".

  • Какая-то польза всё-таки есть? Она достаточно мала, чтобы поддержку "VLA в списке аргументов" сделали необязательной вместе с остальными VLA в C11. В C23 вернули обязательность этих VLA, чтобы имелась дополнительная возможность обнаруживать выход за границы массива, но GCC этой возможностью вроде не пользуется. Вместе с этим предлагали оператор lengthof, который бы тут игнорировал распад (и решал другие проблемы), но стандарт таких резких изменений не вынес. Аналогично известной передаче массива по ссылке в C++ (int (&a)[N]), в C доступна передача по указателю (int (*a)[n]), но использовать её ради sizeof мало кто станет (оверхеда в виде индирекции нет, есть нечитаемость: (*a)[10] = ..., f(&arr)).

Вообще, VLA создают впечатление, что в C не хватает только сахара для получения "массивов, размер которых никогда не теряется", но в реальности, скорее, была бы смерть от синтаксического диабета (size_t n, int a[n] ==> int a[..], как предлагал создатель языка D в 2009).

Да, как-то смысла не видно. Вместо зашивания размера в сигнатуру практичнее тело функции в макрос завернуть.

Если передавать параметром, то оптимизаций не будет. Можно получить разве что сомнительную надежду на проверки границ компилятором за счёт VLA-в-списке-аргументов (N2778, принятый в C23).

Информация

В рейтинге
Не участвует
Зарегистрирован
Активность