Хорошо иметь реальный план в случае реальной угрозы. Но гимп есть под винду, а майкрософту последние 40 лет не было дела до нарушителей вроде пиратов.
Сомневаюсь, что профессионалы будут рассматривать гимп - по некоторым функциям он начинает догонять фотошоп 1996 года. И не знаю, как это сформулировать, но гимп не нацелен на продуктивность. Разработка самого редактора ведётся таким образом, что в неё можно вложить $1'300'000 накопленных пожертвований, но проще их не трогать (вывод из BTC, юристы, налоги, найм...).
Наверное, можно обобщить, что такая опасность касается всего подписочного софта. Вот статья переводная, поэтому в ней есть Photoshop Online, а нас он встретит словами "Photoshop on the web is currently not available in your country".
Один из обзоров HM-SMR диска. Непонятно, есть ли у него требования к железу хоста (особенный SATA-контроллер) - на десктопном железе проверяли только с Windows (не запустилось), а с Linux проверяли только на новом сервере. Ставят на него в обзоре btrfs.
Из забавного: "Random 4K Write (4T/32Q): 2 IOPS Total before failing".
Ужасен Device Managed SMR, который доступен как обычный накопитель. Он не выставляет наружу информацию о SMR stripe'ах и CMR media cache и управляет ими самостоятельно.
А в ёмких серверных - Host Managed SMR. Он говорит компьютеру, что он Zoned Storage и пусть тот самостоятельно с этими зонами разбирается. Даже гикам HM-SMR вроде ни к чему, поэтому про них ничего толком не пишут. Предполагаю, что одна зона - один SMR stripe на 256 МБ, что необходим Linux, что желательна FS, знающая о Zoned Storage. Зоны используются и в SSD.
Хотя нет, у характеристики записи -20 дБ на 20 Гц, но я не учёл +20 дБ на 20 кГц. Итого требования вырастут где-то на 40 дБ при допущении, что ультразвуковой сигнал без корректора всегда слабее звукового (не знаю, как на самом деле). Т.е. переносить RIAA в цифру неразумно.
Иначе и те предыскажения не поправит, и свои внесет.
Хотя так можно рассудить, если нужна максимально точная оцифровка, ради чего можно перенести фильтр RIAA в цифру (но требования к АЦП вырастут на 20 дБ).
Хорошо, что необходимая часть системы на месте. Она не может сделать хуже (менять АЧХ "в неправильную сторону"), потому что нельзя по ошибке собрать ФВЧ вместо ФНЧ. Как нельзя ошибиться в гамме на *2.2 или /2.2 и потом ещё её крутить не туда.
Только меня смущает, что в устройстве для воспроизведения звука идеальной достоверности есть усилитель- корректор?
Он лишь специальные предыскажения отменяет. Это примерно как гамма в мониторе - если отказаться от цепочки внесения-->отмены искажений (камерой-->монитором, OETF-->EOTF), будет хуже и по теории неправильно.
Это же безумие. Выглядит или как другая ошибка, или как будто на самом деле забыли, но на низких частотах ещё какое-то ограничение сработало (на высоких - довольно точно сходится).
Мне вот как-то проще проводом. С любого компа, просто подключаешь телефон и видишь его как обычную флешку. Безо всяких дополнительных программ. Хоть виндовый комп, хоть линуксовый. Хоть есть интернет, хоть нет его.
В Android на провод тоже не очень удобно полагаться - как обычную флешку (usb mass storage) без рута запретили где-то 12 лет назад. USB 3.0 или быстрее по gsmarena стоит лишь в 10% новых смартфонов. Syncthing или KDE Connect в локалке оказывается практичнее, облако не обязательно.
Ну побайтовые копирования в другой тип и правда "не очень определены"
Описание std::bit_cast это просто более явно проговаривает.
По-моему, получилось так, что только в [bit.cast] описывают некоторые правила, которые на самом деле должны быть общими (охватывать и самописный memcpy), должны быть быть в разделе о представлении типов, как было в C (ссылка на ту же страницу, п. 5-6, upd: и 8? "unspecified which representation is used").
Спасибо за ответ. Меня привлекло, что даже выступающий на конференции может здесь засомневаться.
Раздел с тем пунктом описывает требования к представлению типов. И, внезапно, в отличие от аналогичного места в C, разрешает копирование* в символьный буфер и обратно && копирование* в объекты того же типа.
Это уже разрешено, потому что разрешён доступ** через char.
Зачем тогда повторное разрешение? Можно усомниться - потому что иные действия (побайтовое копирование в другой тип)... не очень определены? И некоторый бардак в стандарте может подкрепить эти сомнения - bit_cast так же избегает ссылок на другие разделы, словно аналогичные эффекты у стандартного и/или самописного memcpy не определены (курсив в скобках чуть подкрепляет и эти сомнения):
"Padding bits of the result are unspecified" - дублирует "Padding bits have unspecified value" из примечания(но примечания не нормативны)
"if there is no value of the object’s type corresponding to the value representation..." (дублирующей фразы не нахожу)
Или через эти разрешения хотели лишь запретить побайтовое копирование в случае нетривиально копируемых типов? Тогда пригодилось бы очередное "The intent is that...". Хотя бы.
* побайтовое копирование объектов тривиально копируемых типов, точнее говоря. ** с тем новым термином "type-accessible" (+ссылка на стандарт вместо cppreference).
----- Это ж какая языко-юридическая практика нужна. И standardese на уровне носителя языка.
----- Что ещё касается union, Страуструп говорит, что каламбуры только через его труп категорически против легализации существующей практики.
О, моя любимая мозоль. В C этот приём разрешён, потеря гарантий на уровне C на самом деле неочевидна. Оптимизации, ради которых могли пожертвовать гарантиями, тоже неочевидны. Если так решили упростить текст стандарта, то... это тоже неочевидно. То, что замена на memcpy избавляет от UB - по духу стандарта снова неочевидно, соответствующий пункт стандарта избегает описания memcpy между разными типами (T* вместо T1* и T2*), это замечал один из докладчиков на CppCon.
Воспользоваться гипотетическими оптимизациями из-за масштаба "трагедии" нельзя, можно пройтись по гитхабу:language:C++ /(?-i)union/. По-хорошему UB в нынешнем виде должен вызываться лишь новым атрибутом типа [[assume_no_punning]] специально для реализаций tagged union'ов. Обратная совместимость сохраняется. Можно учитывать новое правило только в новом коде. Исчезает нездоровая и отнимающая у всех время ситуация, когда стандарт не описывает поведение компиляторов, и когда отдельные энтузиасты пытаются вычерпать море (такой type punning везде, и в браузере тоже).
И может случиться то самое, что как бы чего не вышло! И о чём мы? Если есть технический запрет (ещё подумал - запретить протокол file:///), то говорить не о чем. Если его нет, то всё равно спасибо, от разговоров об этом надзирательстве вместо инфобеза поглупеть можно.
файлы/скрипты и прочее запрещено ... и - особенно! - исполнять на рабочем компе.
Э-э-э, так работает браузер. Если браузер можно, то надсмотрщика всё устроит.
---
Я бы сказал, что она может по возможностям потягаться с Obsidian, но не такая модная. Видно и объективные факторы (фрагментация: легаси-TiddlyWiki Classic и TiddlyWiki5; слишком много вынесено в плагины или предлагается для доработки напильником), и субъективные (культ цеттелькастена прошёл мимо неё).
Нет же, она самодостаточна - один локальный файл. И два в одном... как самораспаковывающийся архив - он и архив, и разархиватор. А здесь - html-файл с кучей джаваскрипта, в котором и вики-страницы, и скрипты, реализующие вики-движок.
Тяжёлое медиа из-за такой архитектуры внутрь (оно будет в base64) лучше не класть, но можно ссылаться на лежащее рядом (как в markdown).
На джаваскрипте, очевидно. Ну, её надо умудриться запретить - надо будет запретить загружать страницы в браузере. Или джаваскрипт. Или браузеры вообще.
Есть TiddlyWiki — вики-движок + сама вики (в роли личной базы знаний как тут) в виде одного html-файла. В самом простом варианте использования нужен только браузер, файл обновляется через "сохранение страницы" в браузере.
Почти все могут, столько звёзд сошлось: нужный инструмент утёк, утёк в общий доступ, утёк бесплатно и к нему создали инструкцию. Но терабайтный Optane за - сейчас - $146 должен быть и с доставкой выгоднее.
И надо прочувствовать момент: Optane был неудачен своей около-DRAM-ной ценой на обоих поколениях 3D XPoint (видимо, она не масштабируется как флеш-память). По задержкам это память из будущего, но в прошлом её портила цена, а в будущем на горизонте аналогов пока нет. SLC в 983 ZET и SZ1735 хуже (да и это тоже прошлое), SLC/MLC под брендом XL-FLASH хуже (это настоящее/будущее, из наиболее доступного видно Kioxia FL6 на ebay), а развитие протоколов здесь не поможет (от него только throughput: последовательные скорости и глубокие очереди).
Если не расставаться с ерундой* про pSLC и надёжность одного диска, то можно ещё попробовать аудиофилов окучить обрадовать. Сначала Sony продавала улучшающие звучание карты памяти, потом один форумчанин сумел запустить идею о pSLC с той же магией.
*Занудно* умничанье - это не демагогия. Назвать одноплатником - ошибка, она раз 10 в статье встречается. Назвать компьютером - допустимо, но зачем, если "плата с микроконтроллером" - привычнее и точнее.
Процессор общего назначения - внутри микроконтроллера. На мнение отдельной Foundation плевать, но если не плевать - она эти же основы в своей книжке повторяет. "Microcontrollers ... are computers stripped back to their bare essentials", "type ofcomputer, but it’s not the only type", "CPU: 32-bit dual-core ARM...".
Хорошо иметь реальный план в случае реальной угрозы. Но гимп есть под винду, а майкрософту последние 40 лет не было дела до нарушителей вроде пиратов.
Сомневаюсь, что профессионалы будут рассматривать гимп - по некоторым функциям он начинает догонять фотошоп 1996 года. И не знаю, как это сформулировать, но гимп не нацелен на продуктивность. Разработка самого редактора ведётся таким образом, что в неё можно вложить $1'300'000 накопленных пожертвований, но проще их не трогать (вывод из BTC, юристы, налоги, найм...).
Наверное, можно обобщить, что такая опасность касается всего подписочного софта. Вот статья переводная, поэтому в ней есть Photoshop Online, а нас он встретит словами "Photoshop on the web is currently not available in your country".
Кобол, люди, мейнфреймы, кониОдин из обзоров HM-SMR диска. Непонятно, есть ли у него требования к железу хоста (особенный SATA-контроллер) - на десктопном железе проверяли только с Windows (не запустилось), а с Linux проверяли только на новом сервере. Ставят на него в обзоре btrfs.
Из забавного: "Random 4K Write (4T/32Q): 2 IOPS Total before failing".
А это не этот SMR.
Ужасен Device Managed SMR, который доступен как обычный накопитель. Он не выставляет наружу информацию о SMR stripe'ах и CMR media cache и управляет ими самостоятельно.
А в ёмких серверных - Host Managed SMR. Он говорит компьютеру, что он Zoned Storage и пусть тот самостоятельно с этими зонами разбирается. Даже гикам HM-SMR вроде ни к чему, поэтому про них ничего толком не пишут. Предполагаю, что одна зона - один SMR stripe на 256 МБ, что необходим Linux, что желательна FS, знающая о Zoned Storage. Зоны используются и в SSD.
Хотя нет, у характеристики записи -20 дБ на 20 Гц, но я не учёл +20 дБ на 20 кГц. Итого требования вырастут где-то на 40 дБ при допущении, что ультразвуковой сигнал без корректора всегда слабее звукового (не знаю, как на самом деле). Т.е. переносить RIAA в цифру неразумно.
Хотя так можно рассудить, если нужна максимально точная оцифровка, ради чего можно перенести фильтр RIAA в цифру (но требования к АЦП вырастут на 20 дБ).
Хорошо, что необходимая часть системы на месте. Она не может сделать хуже (менять АЧХ "в неправильную сторону"), потому что нельзя по ошибке собрать ФВЧ вместо ФНЧ. Как нельзя ошибиться в гамме на *2.2 или /2.2 и потом ещё её крутить не туда.
Он лишь специальные предыскажения отменяет. Это примерно как гамма в мониторе - если отказаться от цепочки внесения-->отмены искажений (камерой-->монитором, OETF-->EOTF), будет хуже и по теории неправильно.
Это же безумие. Выглядит или как другая ошибка, или как будто на самом деле забыли, но на низких частотах ещё какое-то ограничение сработало (на высоких - довольно точно сходится).
График
Но важен ли ~1%?
Может, но придётся заплатить 25 миллионов евро.
В Android на провод тоже не очень удобно полагаться - как обычную флешку (usb mass storage) без рута запретили где-то 12 лет назад. USB 3.0 или быстрее по gsmarena стоит лишь в 10% новых смартфонов. Syncthing или KDE Connect в локалке оказывается практичнее, облако не обязательно.
По-моему, получилось так, что только в [bit.cast] описывают некоторые правила, которые на самом деле должны быть общими (охватывать и самописный memcpy), должны быть быть в разделе о представлении типов, как было в C (ссылка на ту же страницу, п. 5-6, upd: и 8? "unspecified which representation is used").
Спасибо за ответ. Меня привлекло, что даже выступающий на конференции может здесь засомневаться.
Раздел с тем пунктом описывает требования к представлению типов. И, внезапно, в отличие от аналогичного места в C, разрешает копирование* в символьный буфер и обратно && копирование* в объекты того же типа.
Это уже разрешено, потому что разрешён доступ** через char.
Зачем тогда повторное разрешение? Можно усомниться - потому что иные действия (побайтовое копирование в другой тип)... не очень определены? И некоторый бардак в стандарте может подкрепить эти сомнения - bit_cast так же избегает ссылок на другие разделы, словно аналогичные эффекты у стандартного и/или самописного memcpy не определены (курсив в скобках чуть подкрепляет и эти сомнения):
"Padding bits of the result are unspecified" - дублирует "Padding bits have unspecified value" из примечания (но примечания не нормативны)
"if there is no value of the object’s type corresponding to the value representation..." (дублирующей фразы не нахожу)
Или через эти разрешения хотели лишь запретить побайтовое копирование в случае нетривиально копируемых типов? Тогда пригодилось бы очередное "The intent is that...". Хотя бы.
* побайтовое копирование объектов тривиально копируемых типов, точнее говоря.
** с тем новым термином "type-accessible" (+ссылка на стандарт вместо cppreference).
-----
Это ж какая языко-юридическая практика нужна. И standardese на уровне носителя языка.-----
Что ещё касается union, Страуструп
говорит, что каламбуры только через его трупкатегорически против легализации существующей практики.О, моя любимая мозоль. В C этот приём разрешён, потеря гарантий на уровне C на самом деле неочевидна. Оптимизации, ради которых могли пожертвовать гарантиями, тоже неочевидны. Если так решили упростить текст стандарта, то... это тоже неочевидно. То, что замена на memcpy избавляет от UB - по духу стандарта снова неочевидно, соответствующий пункт стандарта избегает описания memcpy между разными типами (
T*вместоT1*иT2*), это замечал один из докладчиков на CppCon.Воспользоваться гипотетическими оптимизациями из-за масштаба "трагедии" нельзя, можно пройтись по гитхабу:
language:C++ /(?-i)union/. По-хорошему UB в нынешнем виде должен вызываться лишь новым атрибутом типа [[assume_no_punning]] специально для реализаций tagged union'ов. Обратная совместимость сохраняется. Можно учитывать новое правило только в новом коде. Исчезает нездоровая и отнимающая у всех время ситуация, когда стандарт не описывает поведение компиляторов, и когда отдельные энтузиасты пытаются вычерпать море (такой type punning везде, и в браузере тоже).И может случиться то самое, что как бы чего не вышло! И о чём мы? Если есть технический запрет (ещё подумал - запретить протокол file:///), то говорить не о чем. Если его нет, то всё равно спасибо, от разговоров об этом надзирательстве вместо инфобеза поглупеть можно.
Э-э-э, так работает браузер. Если браузер можно, то надсмотрщика всё устроит.
---
Я бы сказал, что она может по возможностям потягаться с Obsidian, но не такая модная. Видно и объективные факторы (фрагментация: легаси-TiddlyWiki Classic и TiddlyWiki5; слишком много вынесено в плагины или предлагается для доработки напильником), и субъективные (культ цеттелькастена прошёл мимо неё).
Нет же, она самодостаточна - один локальный файл. И два в одном... как самораспаковывающийся архив - он и архив, и разархиватор. А здесь - html-файл с кучей джаваскрипта, в котором и вики-страницы, и скрипты, реализующие вики-движок.
Тяжёлое медиа из-за такой архитектуры внутрь (оно будет в base64) лучше не класть, но можно ссылаться на лежащее рядом (как в markdown).
На джаваскрипте, очевидно. Ну, её надо умудриться запретить - надо будет запретить загружать страницы в браузере. Или джаваскрипт. Или браузеры вообще.
Есть TiddlyWiki — вики-движок + сама вики (в роли личной базы знаний как тут) в виде одного html-файла. В самом простом варианте использования нужен только браузер, файл обновляется через "сохранение страницы" в браузере.
Почти все могут, столько звёзд сошлось: нужный инструмент утёк, утёк в общий доступ, утёк бесплатно и к нему создали инструкцию. Но терабайтный Optane за - сейчас - $146 должен быть и с доставкой выгоднее.
И надо прочувствовать момент: Optane был неудачен своей около-DRAM-ной ценой на обоих поколениях 3D XPoint (видимо, она не масштабируется как флеш-память). По задержкам это память из будущего, но в прошлом её портила цена, а в будущем на горизонте аналогов пока нет. SLC в 983 ZET и SZ1735 хуже (да и это тоже прошлое), SLC/MLC под брендом XL-FLASH хуже (это настоящее/будущее, из наиболее доступного видно Kioxia FL6 на ebay), а развитие протоколов здесь не поможет (от него только throughput: последовательные скорости и глубокие очереди).
Если не расставаться с ерундой* про pSLC и надёжность одного диска, то можно ещё попробовать аудиофилов
окучитьобрадовать. Сначала Sony продавала улучшающие звучание карты памяти, потом один форумчанин сумел запустить идею о pSLC с той же магией.* "The vast majority of drive failures happen well before their P/E cycle limit is reached" - doi:10.1109/TDSC.2021.3131571; "Most of the [failed] devices have not used more than 1% of the PE cycles" - A Study of SSD Reliability in Large Scale Enterprise Storage Deployments.
*Занудно* умничанье - это не демагогия. Назвать одноплатником - ошибка, она раз 10 в статье встречается. Назвать компьютером - допустимо, но зачем, если "плата с микроконтроллером" - привычнее и точнее.
Процессор общего назначения - внутри микроконтроллера. На мнение отдельной Foundation плевать, но если не плевать - она эти же основы в своей книжке повторяет. "Microcontrollers ... are computers stripped back to their bare essentials", "type of computer, but it’s not the only type", "CPU: 32-bit dual-core ARM...".