Вы берете только частный случай. Вот, смотрите: есть видеопоток, у него есть русская звуковая дорожка, есть английская. В какой-то момент времени организаторы подсуетились и с середины потока появилась испанская звуковая дорожка. К фильму могут прикладываться видео и звук бэкстейджа. Для самого основного потока это все есть метаатрибуты. А не только дескрипторы безопасности, тип кодека, разрешение и пр. как вы считаете.
Вы предлагаете это все хранить в xattrs? Очевидно, что удобнее было бы иметь какие-то отдельные дорожки хранения в общем стриме. На каждой из них хранить свой контент - или видео основного потока или языковую озвучку или бэкстейдж.
Если все хранить в едином потоке, то для той же испанской дорожки в примере выше необходимо переделать на лету часть стрима, что выражается в оверхедах.
Опять же, напомню, не я это понятие придумал. Та же ms уже имеет в ntfs файловые стримы, где данные могут храниться параллельно, но в рамках одного объекта. Надо это лишь "допилить" до нужной кондиции.
Не очень понял о чем вы. Но попробую ответить как понял. Здесь же ниже уже озвучил, как можно заменить файл. Через снепшоты потока во времени. Детали см. в комменте рядом.
На самом деле уже есть первая попытка создать безразмерное хранилище контента. Это ipfs. Но здесь есть нюансы. Разрабатывать эту штуку начали парни, которым близок веб-контент. Т.е. возникла потребность в хранении большого именно веб-контента и они подходят к теме именно с позиции веб-технологий. Другими словами, доя целей хранения и передачи поток данных нужно оборачивать в http. Есть еще какой-то fuse метод доступа, но я не в курсе деталей. Возможно, это то, что надо.
Оборачивать данные стрима в веб не всегда хочется. Например, есть у вас корпоративная система наблюдения. Или камера обзора в авто. Зачем вам веб и накладные расходы на кодирование/декодирование в/из base64? Это приводит к прожорливости ОС и ПО в части железа. А сами веб-сервисы- достаточно медленные, с точки зрения их альтернатив.
Думаю, в ОС могла быть какая-то настройка, которая позволяла бы сохранять структура файла(цепочку кластеров или кусков) локально, а сами данные располагать где-то еще. Однако, облачные платформы сейчас предлагают другой подход - клиент отдает весь поток в облако и оно хранит весь поток целиков на своих раидах. Здесь надо думать, что лучше и где какой вариант подошел бы больше. Но я - за универсализацию. Т.е. технические возможности должны быть. А выпиливать их - если со временем этими возможностями никто не будет пользоваться. Для того - можно проводить какие-то публичные опросы.
Почему вариант с облаком не очень хорош? Ну, представьте центр видеонаблюдения крупного ТЦ. Допустим, стоят камеры 5Мп с битрейтом в районе 8-16Мбит/с. Понятно, что пятьдесят камер забъет канал 1гбит/с. А если взять центр видеонаблюдения Москвы? Да он один всю итернет-магистраль забьет. Поэтому, здесь может быть комплексный подход: пока сырые данные пишутся на местные hdd, в параллели они пакуются (я в курсе про аппаратные кодаки 264 и 265, здесь речь скорее о накоплении данных), в параллели же наиболее старые данные отправляются в облако. Но стрим-то должен быть один!!! Поэтому, должны быть блоки стрима, сохраненные локально и также должны быть блоки, помеченные как хранимые в облаке. Здесь же я говорю о том, что подобная схема повысит требования к пиковой пропускной способности, но во времени будет оставлять "дыры" для других пользователей той же сети.
Что мы имеем сейчас? Видеорегистраторы дробят стрим на независимые файлы. И хранят также. Но если для видеонаблюдения это допустимо, то для целей видеотрансляций - уже не очень. Напомню, любая видеотрансляция идет с задержкой хотя бы в несколько секунд. Понятно, что каждый видеокадр не летит прямо в сеть. Идет их накопление и потом выстреливают пакетом. Вот эти несколтко секунд кадры и копятся в пакет. В итоге, на клиента нужно загружать какой-то спец.плеер, который сумеет склеить разные файлы. Либо, на клеить сервере, применяя медиасервер. В любом случае, либо накладные расходы на сервере, либо неудобства на клиенте.
Хранение прямо в потоке позволит реализовать достаточно интересные схемы. Например, когда на клиента закидывается схема размещения стрима, затем идет вещание с первого сервера, потом согласно схеме стрима клиент просто переключается на другой сервер, где хранится очередная порция данных. В процессе вещания схему стрима можно дополнять, что удлиняет сам "файл" стрима, простите за каламбур. И это все очень интересно с точки зрения цифрового ТВ (кино/передача по запросу), где разные пользователи могут возжелать разный контент.
Технически, конечно, можно все это реализовать на файлах, но будут оверхеды по производительности и ресурсам. Пример см. пояснения про кластеры тут рядом в комментах.
во-первых, ничего я не перепутал. называть разные вещи одинаковыми названиями - это называется притягивать "за уши" и костылить. Потому, что и в том и в другом случае доступ к файлу идет через одно и то же api. Не зря же я в сабже указал широко известную фразу: "все есть файл". Она означает, что идеологи никсов сводят и первый и второй ваш случай к одному и тому же понятию. И реализуют через одни и те же механизмы. О том и статья.
Но раз уже такое есть, то - второе:
я сказал о том, что понятие "файл" изначально было введено для хранения данных. Потом придумали ему назначить функцию передачи данных.
Понятие "поток данных" помимо функций хранения и передачи имеет еще одну - "управление потоком". И эта функция очень плохо ложится на файловое api. Рассмотрите пример tls-потока. Здесь есть свой протокол, когда перед передачей данных, необходимо обменяться рядом сообщений, выбрать безопасные алгоритмы и установить общие криптографические ключи и только потом передавать данные. В этом и состоит функция управления потоком для tls. При передаче данных также идет работа над данными - они шифруются и дешифруются. И пытаться это управление впихнуть в файловое api -это получить гибрид бульдога с носорогом. Той же ms удалось сделать общее api ssl/tls, но совместили они его не с файловым api, а с api авторизации. Речь идет о sspi packages и их winapi. Для тех, кто не в курсе: там одни и те же функции используются и для windows авторизации и для организации ssl/tls соединения. Только выбираются разные провайдеры. Но методика вызова функций - одна и та же. Т.е. на этих функциях и реализовано управление потоком. К слову, с win2008 в винде появилось новое выделенное cng api для управления ssl. Т.о. сама ms признала, что предыдущая реализация управления потоком получилась не очень.
Т.о. понятие потока - оно существенно шире, чем понятие "файл".
Вероятно, если попытаться заменить файл стримами о 3 указанных выше функциях, то можно получить интересные решения. Например, рассматривать файл как snapshot потока во времени. Тогда весь стрим можно представить как ряд снепшотов (файлов). Замечу, что именно такую концепцию реализуют некоторые плееры видео, которые умеют проигрывать и склеивать в единое видео несколько последовательно переданных на клиента файлов. А делается это в некоторых видеостриминговых сервисах в целях защиты от скачивания видеофайла целиком.
В итоге, что получится? Условно "бесконечно" длинный файл. Современные файловые системы (фс) уже имеют такую возможность. Но здесь дело уже в том, что фс реализуют это через кластеры. Т.е. для достижения гигантских размеров файлов используются кластеры с бОльшим значением байт в каждом. Стрим же будет это делать более рационально. Опять же, в существующих реализациях каждый файл (как часть стрима) может иметь размер до 4 Гб, соответственно иметь мЕньший кластер. Но за счет объединения нескольких файлов в один стрим получается "файл" существенно бОльшего размера. Почему не оставить файл как есть, а придумывать какие-то "снепшоты" - это отдельный разговор.
если я правильно понял, то подобные проблемы стандартно решаются дополнительным объектом. т.е. исходные данные лежат не в буфере, а самописном байт-стриме. стрим основан на коллекции блоков разной длины. втыкаете новую дату в новом блоке в любое место стрима и итогом формируете свой буфер из стрима. если надо еще добавить, повторяете операцию обновление стрима-выгрузка из стрима. для 90% случаев, а тем более датаграмм до 64к будет работать шустро. в чем проблема?
программируйте на васике. там песочница не позволяет выпасть в осадок.
с и с++ задумывались как системные языки программирования. ну то есть, никто не пишет драйвера и осе на асме, это очень трудоемко.
естественно, что там полно низкоуровневых и небезопасных фич. и нифига они не obsolete. на поинтерах, например, весь язык держится. вы помните как происходит возврат значения из процедуры в с++? либо по ссылке, либо через поинтер. ссылку в ооп далеко не везде удобно применять, а вот поинтеры - самый рабочий механизм. а вы его в obsolete. ну потому что - небезопасные.
любой серьезный проект предполагает некую дисциплину - как надо делать и как не надо. совершенно очевидно, что бардак начинается там, где не настроена такая дисциплина. называется она best practice. и, например, в том же мелкософте она не настроена. потому как winapi часто взрывается exception при передаче неверных параметров. банально функции winapi не проверяют правильность входящих параметров.
вот пример. не далее как вчера обнаружил неправильную работу одной функции работы с сертификатом. в первый вызов она считает необходимое к-во байт для выходного буфера, выделяю сколько надо, а второй раз -опять сообщает, что размера буфера не достаточно. курил долго. оказалось, что в нее был передан контейнер, в котором не было ключа. а почему бы не выдать ей ошибку - в контейнере нет ключа? нет, мы сразу ломимся в бой на непроверенных данных. оттого и размер плавал, что какая-то подфункция смотрела на мусор.
и за 20 лет ситуация не поменялась. чем поможет здесь переход на rust, если входные параметры и там ровно также не будут проверять?
как vector<>.push_back() соотносится с проблемами утечек памяти? это просто более трудночитаемая и понимаемая конструкция шаблона. ваше фи - не по теме, хотя мнение имеет место быть.
по теме он сказал все правильно: используйте ссылку и тип автопоинтер вместо обычных поинтеров, применяйте raii (погуглите примеры кода, что это) где возможно - и будет вам безопасный код.
от себя добавлю еще пару вещей:
1) выделять и освобождать динамическую память для объектов нужно через паттерн проектирования фабрика или фабричный метод. они могут подсчитывать размер выделенной памяти и при своем закрытии сигнализировать об утечках, если что-то к этому моменту не успело освободиться. т.о. утечки памяти ловятся уже на этапе разработки. что предотвращает ошибки типа out of memory и исчерпание хендлов.
2)raii нужно использовать в том числе для механизмов блокировок в памяти. т.е. зашел в скоп программы - raii инициировала блокировку (если надо здесь). вышел из скопа - блокировка сама снялась.
3) пример ms показывает, как можно уйти от разных cast в с++. смотрите как работает метод iunknown.QueryInterface. он прекрасно работает на получение ссылок для разных интерфейсов (классов). нужные классы (в составе одного объекта) имеют динамическую типизацию и выгребаются по запросу с параметром типа.
ключевые слова - применение динамической типизации, которую так любят отключать компиляторы.
4) каждый метод должен проверять свои входяшие параметры. тогда не будет взрывов в тех методах, где exception не предусмотрены, в принципе. как пример - сейчас многие функции winapi генерируют исключения при неверных параметрах, вместо возвращения обычного hresult.
этих рекомендаций достаточно для того, чтобы иметь стабильный код. однако, зачем вникать в тонкости, когда можно перейти на rust... и оставить в коде все те же проблемы с дедлоками, о чем и сказал Страуструп. ну потому что rust проблемой блокировок не занимается?
про организацию потоков вынь могу немного рассказать.
ms была выбрана следующая концепция: на уровне обычного пользователя потоки в процессе переключаются не быстрее 16мс. т.е. если вам надо каждую миллисекунду че-то проверять, на обычном потоке без спец. ухищрений это сделать не получится. но технические варианты что делать -есть. отсюда и эффективное кол-во потоков процесса = 1сек/0.016с=62,5 шт. т.е. другими словами, если вы сделаете 63 и более потока в процессе винды, то весь цикл переключения всех потоков займет более 1 секунды. в этой связи, делать 1000 потоков в вынь - смысла никакого.
внутри ядра и драйверах скорость переключения потоков -другая, там уже речь идет о микросекундах.
сделано так ввиду того, что ms поощряет дробление логики в компоненты уровня ОС (напр. com+), каждый из которых является отдельным процессом со своими условными 62 потоками на 1 ядро проца.
например, есть задача сделать нейросеть таким образом, чтобы часть ее узлов обрабатывалась своим потоком. что делают в линухе? просто тупо запускают условную тысячу потоков и делят между ними узлы.
ровно также можно сделать на вынь, но эффективность -вы сами видите. надо делать по-другому: создавать com+ компонент, запускать тучу этих компонентов(а по-сути, процессов) и каждый из них будет запускать не более 62 потока. потоки разных процессов могут работать параллельно за счет того, что в ядре происходит переключение (между процессами) в 1000 раз быстрее.
т.о. подобную задачу в вынь нужно решать не тупым переносом исходного кода, а принципиально иначе.
вот, собственно, почему в синтетических тестах вынь проигрывает линуху. потому что адаптировать и перекопилировать исходный код линуха под вынь - это архитектурная ошибка в вынь. и программисты линуха этого тупо не понимают.
те проблемы, что перечислил автор- это не столько проблема windows, сколько проблема управления очень сложным программным продуктом.
давайте вспомним, как обновляется ядро линуха: модификация идет к Торвальду и только он решает, что войдет в ядро, а что нет. т.е. несмотря на вездесущий continuous integration, апрувит все-равно один чел. так не везде, но думаете от хорошей жизни торвальд этим занялся? или или не в курсе СI, полагаете?
возможно ли что-то подобное с вынь? определенно, нет. вынь определенно сложнее любого линуха по следующим причинам:
графическая подсистема вынь встоена в ядро, в линухе - это просто оболочки вне ядра. соответственно, разработчик оболочек - другой. отсюда в линухе почти нет конкурирующих команд разработки. они уже свои форки понаделали и развивают их кто в лес, кто по дрова отдельно друг от друга.
вынь в обязательном порядке содержит пользовательские компоненты уровня ОС - com/dcom/com+/activex/старые ole, которые экспортируют в ОС свое апи и импортируют чужое, в т.ч. таких же рядом лежащих компонентов. это апи имеет платформенный стандарт и описывается в tlb библиотеках, которые идут в паре с компонентом. и этот апи не имеет отношения к winap или сервисам вынь (они могут использовать несколько таких компонетов). никакого подобного механизма(пользовательские объекты на уровне ОС), и тем более, реализаций под него в линухах нет, имхо.
наличие объектных компонентов уровня ОС привело вынь к механизму интеграции оных в о внутреннюю безопасность вынь. т.е. компонент может запуститься по желанию стороннего кода согласно своих настроек, например, под учеткой админа, или вызывающего юзера или еще кого. и компонент будучи админом, может временами "прикидываться" юзером, чтобы внутренние механизмы безопасности сами разгребали, что доступно этому юзеру, а что нет. это очень глубокая интеграция.
обильное наличие внутренних сервисов на этих компонентах - вот причина проблем стабильности винды. совершенно понятно, что команда, которая делает iis не будет заниматься ms sql или сервисом выпуска сертификата. а оформлять любое функциональное решение в com/com+ - это требование ms и внутри компании оно четко соблюдается. отсюда - много команд, но механизмы ОС одни и те же (безопасность, доступ к файлам, памяти и пр.).
в качестве еще одного доказательства приведу пример того, что ms в считанные месяцы смогло включить внутрь вынь клон линуха. при этом, в отличие от виртуальных машин, линух видит родной диск вынь и даже пытается взаимодействовать с безопасностью вынь. т.е. это показывает, что вынь "проглотила" линух и не почти заметила этого.
также не согласен с идеей о том, что в линухе патчи способствуют исключительно стабильности и производительности. автор совершенно упустил из виду факты целенаправленного встраивания разных зловредов в исходный код открытых ОС. и мотивация здесь может быть совершенно иной: от желания любым способом "засветится" в качестве разработчика такого кода, до сомнительных решений в виде "закладок" на будущее.
стимул принимать внешние разработки для команд ms- есть. у каждой команды есть mvp и он не достижим без таких внешних вливаний. грубо говоря, релиз собственного модуля не выйдет в срок, если ранее было согласовано добавление внешнего кода. определенно, это злит всех. но нельзя сказать, что команда старается игнорировать такие вливания. наоборот, они там орут "давайте быстрее".
решение о mvp в вынь принимают руководители, а не программисты, как в линухе. т.о. руководители и программисты видят ценность своих продуктов по-разному. и это не имеет никакого отношения к продвижению в компании. "я реализую пару интересных проектов и меня подвинут на позицию рук. департамента" - это так не работает в коммерческих структурах. а работает следующее: чел отлично справляется на месте, вот он пусть и дальше этим же занимается.
интересно, что некоторые программисты отрицают наличие проблемы. т.е. факт есть, но он не вписывается в их концепцию мира и они предпочитают делать вид, что ничего подобного не существует и мир -прекрасен, а проблема безопасности решений в общедоступных репозиториях - надумана. и вот, возникает вопрос, что делать с такими? не замечать их??
у меня складывается впечатление, что есть категория программистов, которые не могут жить, чтобы не изучить новый язык за период времени Т. не новую технологию, а именно язык. как будто им существующих языковых средств не хватает.
вот при чем тут жабаскрипт и rust? на жабаскрипте кодят, в основном, фронтендеры. жабаскрипт на бэке используется только в очень крупных приложениях, которые могут себе позволить поддержку скриптинга и своей объектной модели под него. я даже не могу представить себе ситуацию, когда действующий фронтендер захочет как-то поменять жабаскрипт на rust. оно же вообще не для этого. т.о. этот пассаж про жабаскриптеров - вообще не понятен.
мечта парсить файлики тремя строчками кода - ну что за идиотизм? ну напишите вы один раз функцию и применяйте ее вечно. ее вызов - одна строка кода.
из статьи понял, что раст поддерживает в каком-то виде макросы, но что хотел сказать автор - остается загадкой. поговорил сам с собой и остался доволен. кажется так.
фигня. автоматизация не учитывает наличие внутренней щеколды. т.е. закрывать изнутри не обязательно на замок, можно на щеколду. в этом случае ваша поделка покажет, что дверь открыта, а она будет закрыта.
проблема обостряется, когда вас в квартире больше чем 1. например, жена на кухне - кричите: "я ушел, закрой дверь". и все. последняя запись в телеге "дверь открыта" и без изменений. то ли закрыла, то ли нет. а все ключи, как обычно, лежат на входе. 5 сек. на открыть дверь, взять ключи, закрыть. потом все замки менять будете. особенно обидно будет потому, что там стояла ваша поделка.
предположение о том, что ии вытеснит программистов (в ближайшем будущем) основано на ложных предпосылках. а значит, что и остальное все - просто демагогия для повышения рейтинга автора в сети.
ложные предпосылки основываются на том, что llm: а) осознают себя как личность б)вследствие а) устанавливают себе цели и задачи в) цели и задачи достигаются вовремя г)цели и задачи направлены на создание программного кода.
>режем входной сигнал с помощью разветвителя из резисторов
с помощью резистров изменить фазу не получится. возможны варианты только с помощью конденсаторов и индуктивностей.
без осциллографа разрабатывать электронные схемы вообще не имеет смысла. потому что реальные радиодетали не всегда ведут себя так, как в программе эмуляции.
в укв диапазоне ведется чм-модулированное вещание. если вы попали на станцию, прием будет чистый. помехи в приеме характерны для ам-модуляции. предполагаю, что в схеме смешались кони-люди. получить помехи при чм-модуляции - это еще уметь надо.
Создать свой проц - это Мечта творческого технического специалиста. Такая же, как - создать свою операционную систему. И если полететь на Марс ему не грозит даже в самых смелых грезах, то такая мечта выглядит осуществимой.
Однако, вы уже поняли к чему я веду. Реализовать даже одну мечту одному - очень сложно, об этом -ниже. Реализовать же вторую мечту ему же- практически невозможно. Допустим, вы сделали и отладили проц. Теперь под него нужно сделать операционную систему, компилятор и отладчик. Поскольку писать проги будете не на самом устройстве, нужен еще эмулятор устройства на ПК, совместимый с отладчиком. Ну, понятно, загрузчик программы в устройство, потому как флешка более подходит для финального варианта. а до того будет 100млн итераций отладки.
это я к чему? система команд мне кажется недостаточно проработана. лучше бы использовать какую-то из стандартных существующих процов. с одной стороны тогда можно было бы сравнивать промышленные образы с вашей поделкой с точки зрения производительности. с другой стороны, можно реиспользовать сущ. ПО. на низкой частоте работает куча процов арма. вот вариант.
стандартные битовые операции реализованы не все: нужно и, или, not, xor, битовый сдвиг влево, битовый сдвиг вправо. без этого криптографию - не реализовать. криптография нужна в ssl/tls, что в свою очередь сейчас нужно для всех сайтов в инете, потому как обычный http сейчас считается небезопасным.
не увидел выхода не то что на видеокарту, даже на обычный мини-дисплей. вы предлагаете под это дело занять все свободные gpio?
аппаратные прерывания любого современного проца - стандартны: деление на 0, ошибка доступа к памяти, прерывание отладки и др. не увидел поддерживаемого списка таких прерываний.
не увидел потуг на мультизадачность. зачем вам однопоточный проц? любой arm на 33мгц делает в этой части ваш проц.
я не убиваю вашу мечту. самому было бы интересно. но так понимаю, вы больше по аппаратной части и над программной составляющей (что надо то?) сильно не задумывались.
Вы берете только частный случай. Вот, смотрите: есть видеопоток, у него есть русская звуковая дорожка, есть английская. В какой-то момент времени организаторы подсуетились и с середины потока появилась испанская звуковая дорожка. К фильму могут прикладываться видео и звук бэкстейджа. Для самого основного потока это все есть метаатрибуты. А не только дескрипторы безопасности, тип кодека, разрешение и пр. как вы считаете.
Вы предлагаете это все хранить в xattrs? Очевидно, что удобнее было бы иметь какие-то отдельные дорожки хранения в общем стриме. На каждой из них хранить свой контент - или видео основного потока или языковую озвучку или бэкстейдж.
Если все хранить в едином потоке, то для той же испанской дорожки в примере выше необходимо переделать на лету часть стрима, что выражается в оверхедах.
Опять же, напомню, не я это понятие придумал. Та же ms уже имеет в ntfs файловые стримы, где данные могут храниться параллельно, но в рамках одного объекта. Надо это лишь "допилить" до нужной кондиции.
Не очень понял о чем вы. Но попробую ответить как понял. Здесь же ниже уже озвучил, как можно заменить файл. Через снепшоты потока во времени. Детали см. в комменте рядом.
На самом деле уже есть первая попытка создать безразмерное хранилище контента. Это ipfs. Но здесь есть нюансы. Разрабатывать эту штуку начали парни, которым близок веб-контент. Т.е. возникла потребность в хранении большого именно веб-контента и они подходят к теме именно с позиции веб-технологий. Другими словами, доя целей хранения и передачи поток данных нужно оборачивать в http. Есть еще какой-то fuse метод доступа, но я не в курсе деталей. Возможно, это то, что надо.
Оборачивать данные стрима в веб не всегда хочется. Например, есть у вас корпоративная система наблюдения. Или камера обзора в авто. Зачем вам веб и накладные расходы на кодирование/декодирование в/из base64? Это приводит к прожорливости ОС и ПО в части железа. А сами веб-сервисы- достаточно медленные, с точки зрения их альтернатив.
Думаю, в ОС могла быть какая-то настройка, которая позволяла бы сохранять структура файла(цепочку кластеров или кусков) локально, а сами данные располагать где-то еще. Однако, облачные платформы сейчас предлагают другой подход - клиент отдает весь поток в облако и оно хранит весь поток целиков на своих раидах. Здесь надо думать, что лучше и где какой вариант подошел бы больше. Но я - за универсализацию. Т.е. технические возможности должны быть. А выпиливать их - если со временем этими возможностями никто не будет пользоваться. Для того - можно проводить какие-то публичные опросы.
Почему вариант с облаком не очень хорош? Ну, представьте центр видеонаблюдения крупного ТЦ. Допустим, стоят камеры 5Мп с битрейтом в районе 8-16Мбит/с. Понятно, что пятьдесят камер забъет канал 1гбит/с. А если взять центр видеонаблюдения Москвы? Да он один всю итернет-магистраль забьет. Поэтому, здесь может быть комплексный подход: пока сырые данные пишутся на местные hdd, в параллели они пакуются (я в курсе про аппаратные кодаки 264 и 265, здесь речь скорее о накоплении данных), в параллели же наиболее старые данные отправляются в облако. Но стрим-то должен быть один!!! Поэтому, должны быть блоки стрима, сохраненные локально и также должны быть блоки, помеченные как хранимые в облаке. Здесь же я говорю о том, что подобная схема повысит требования к пиковой пропускной способности, но во времени будет оставлять "дыры" для других пользователей той же сети.
Что мы имеем сейчас? Видеорегистраторы дробят стрим на независимые файлы. И хранят также. Но если для видеонаблюдения это допустимо, то для целей видеотрансляций - уже не очень. Напомню, любая видеотрансляция идет с задержкой хотя бы в несколько секунд. Понятно, что каждый видеокадр не летит прямо в сеть. Идет их накопление и потом выстреливают пакетом. Вот эти несколтко секунд кадры и копятся в пакет. В итоге, на клиента нужно загружать какой-то спец.плеер, который сумеет склеить разные файлы. Либо, на клеить сервере, применяя медиасервер. В любом случае, либо накладные расходы на сервере, либо неудобства на клиенте.
Хранение прямо в потоке позволит реализовать достаточно интересные схемы. Например, когда на клиента закидывается схема размещения стрима, затем идет вещание с первого сервера, потом согласно схеме стрима клиент просто переключается на другой сервер, где хранится очередная порция данных. В процессе вещания схему стрима можно дополнять, что удлиняет сам "файл" стрима, простите за каламбур. И это все очень интересно с точки зрения цифрового ТВ (кино/передача по запросу), где разные пользователи могут возжелать разный контент.
Технически, конечно, можно все это реализовать на файлах, но будут оверхеды по производительности и ресурсам. Пример см. пояснения про кластеры тут рядом в комментах.
про идею со снепшотами потока - читайте ниже. нужно мыслить "ширше и ширее"?
во-первых, ничего я не перепутал. называть разные вещи одинаковыми названиями - это называется притягивать "за уши" и костылить. Потому, что и в том и в другом случае доступ к файлу идет через одно и то же api. Не зря же я в сабже указал широко известную фразу: "все есть файл". Она означает, что идеологи никсов сводят и первый и второй ваш случай к одному и тому же понятию. И реализуют через одни и те же механизмы. О том и статья.
Но раз уже такое есть, то - второе:
я сказал о том, что понятие "файл" изначально было введено для хранения данных. Потом придумали ему назначить функцию передачи данных.
Понятие "поток данных" помимо функций хранения и передачи имеет еще одну - "управление потоком". И эта функция очень плохо ложится на файловое api. Рассмотрите пример tls-потока. Здесь есть свой протокол, когда перед передачей данных, необходимо обменяться рядом сообщений, выбрать безопасные алгоритмы и установить общие криптографические ключи и только потом передавать данные. В этом и состоит функция управления потоком для tls. При передаче данных также идет работа над данными - они шифруются и дешифруются. И пытаться это управление впихнуть в файловое api -это получить гибрид бульдога с носорогом. Той же ms удалось сделать общее api ssl/tls, но совместили они его не с файловым api, а с api авторизации. Речь идет о sspi packages и их winapi. Для тех, кто не в курсе: там одни и те же функции используются и для windows авторизации и для организации ssl/tls соединения. Только выбираются разные провайдеры. Но методика вызова функций - одна и та же. Т.е. на этих функциях и реализовано управление потоком. К слову, с win2008 в винде появилось новое выделенное cng api для управления ssl. Т.о. сама ms признала, что предыдущая реализация управления потоком получилась не очень.
Т.о. понятие потока - оно существенно шире, чем понятие "файл".
Вероятно, если попытаться заменить файл стримами о 3 указанных выше функциях, то можно получить интересные решения. Например, рассматривать файл как snapshot потока во времени. Тогда весь стрим можно представить как ряд снепшотов (файлов). Замечу, что именно такую концепцию реализуют некоторые плееры видео, которые умеют проигрывать и склеивать в единое видео несколько последовательно переданных на клиента файлов. А делается это в некоторых видеостриминговых сервисах в целях защиты от скачивания видеофайла целиком.
В итоге, что получится? Условно "бесконечно" длинный файл. Современные файловые системы (фс) уже имеют такую возможность. Но здесь дело уже в том, что фс реализуют это через кластеры. Т.е. для достижения гигантских размеров файлов используются кластеры с бОльшим значением байт в каждом. Стрим же будет это делать более рационально. Опять же, в существующих реализациях каждый файл (как часть стрима) может иметь размер до 4 Гб, соответственно иметь мЕньший кластер. Но за счет объединения нескольких файлов в один стрим получается "файл" существенно бОльшего размера. Почему не оставить файл как есть, а придумывать какие-то "снепшоты" - это отдельный разговор.
если я правильно понял, то подобные проблемы стандартно решаются дополнительным объектом. т.е. исходные данные лежат не в буфере, а самописном байт-стриме. стрим основан на коллекции блоков разной длины. втыкаете новую дату в новом блоке в любое место стрима и итогом формируете свой буфер из стрима. если надо еще добавить, повторяете операцию обновление стрима-выгрузка из стрима. для 90% случаев, а тем более датаграмм до 64к будет работать шустро. в чем проблема?
лишний if прописать слабо? или оно само все должно у вас там раскорячиваться?
оборачиваете во wrapper и передаете хоть null, хоть не инициализирующее значение. без страуструпа никак не наваять?
программируйте на васике. там песочница не позволяет выпасть в осадок.
с и с++ задумывались как системные языки программирования. ну то есть, никто не пишет драйвера и осе на асме, это очень трудоемко.
естественно, что там полно низкоуровневых и небезопасных фич. и нифига они не obsolete. на поинтерах, например, весь язык держится. вы помните как происходит возврат значения из процедуры в с++? либо по ссылке, либо через поинтер. ссылку в ооп далеко не везде удобно применять, а вот поинтеры - самый рабочий механизм. а вы его в obsolete. ну потому что - небезопасные.
любой серьезный проект предполагает некую дисциплину - как надо делать и как не надо. совершенно очевидно, что бардак начинается там, где не настроена такая дисциплина. называется она best practice. и, например, в том же мелкософте она не настроена. потому как winapi часто взрывается exception при передаче неверных параметров. банально функции winapi не проверяют правильность входящих параметров.
вот пример. не далее как вчера обнаружил неправильную работу одной функции работы с сертификатом. в первый вызов она считает необходимое к-во байт для выходного буфера, выделяю сколько надо, а второй раз -опять сообщает, что размера буфера не достаточно. курил долго. оказалось, что в нее был передан контейнер, в котором не было ключа. а почему бы не выдать ей ошибку - в контейнере нет ключа? нет, мы сразу ломимся в бой на непроверенных данных. оттого и размер плавал, что какая-то подфункция смотрела на мусор.
и за 20 лет ситуация не поменялась. чем поможет здесь переход на rust, если входные параметры и там ровно также не будут проверять?
как vector<>.push_back() соотносится с проблемами утечек памяти? это просто более трудночитаемая и понимаемая конструкция шаблона. ваше фи - не по теме, хотя мнение имеет место быть.
по теме он сказал все правильно: используйте ссылку и тип автопоинтер вместо обычных поинтеров, применяйте raii (погуглите примеры кода, что это) где возможно - и будет вам безопасный код.
от себя добавлю еще пару вещей:
1) выделять и освобождать динамическую память для объектов нужно через паттерн проектирования фабрика или фабричный метод. они могут подсчитывать размер выделенной памяти и при своем закрытии сигнализировать об утечках, если что-то к этому моменту не успело освободиться. т.о. утечки памяти ловятся уже на этапе разработки. что предотвращает ошибки типа out of memory и исчерпание хендлов.
2)raii нужно использовать в том числе для механизмов блокировок в памяти. т.е. зашел в скоп программы - raii инициировала блокировку (если надо здесь). вышел из скопа - блокировка сама снялась.
3) пример ms показывает, как можно уйти от разных cast в с++. смотрите как работает метод iunknown.QueryInterface. он прекрасно работает на получение ссылок для разных интерфейсов (классов). нужные классы (в составе одного объекта) имеют динамическую типизацию и выгребаются по запросу с параметром типа.
ключевые слова - применение динамической типизации, которую так любят отключать компиляторы.
4) каждый метод должен проверять свои входяшие параметры. тогда не будет взрывов в тех методах, где exception не предусмотрены, в принципе. как пример - сейчас многие функции winapi генерируют исключения при неверных параметрах, вместо возвращения обычного hresult.
этих рекомендаций достаточно для того, чтобы иметь стабильный код. однако, зачем вникать в тонкости, когда можно перейти на rust... и оставить в коде все те же проблемы с дедлоками, о чем и сказал Страуструп. ну потому что rust проблемой блокировок не занимается?
про организацию потоков вынь могу немного рассказать.
ms была выбрана следующая концепция: на уровне обычного пользователя потоки в процессе переключаются не быстрее 16мс. т.е. если вам надо каждую миллисекунду че-то проверять, на обычном потоке без спец. ухищрений это сделать не получится. но технические варианты что делать -есть. отсюда и эффективное кол-во потоков процесса = 1сек/0.016с=62,5 шт. т.е. другими словами, если вы сделаете 63 и более потока в процессе винды, то весь цикл переключения всех потоков займет более 1 секунды. в этой связи, делать 1000 потоков в вынь - смысла никакого.
внутри ядра и драйверах скорость переключения потоков -другая, там уже речь идет о микросекундах.
сделано так ввиду того, что ms поощряет дробление логики в компоненты уровня ОС (напр. com+), каждый из которых является отдельным процессом со своими условными 62 потоками на 1 ядро проца.
например, есть задача сделать нейросеть таким образом, чтобы часть ее узлов обрабатывалась своим потоком. что делают в линухе? просто тупо запускают условную тысячу потоков и делят между ними узлы.
ровно также можно сделать на вынь, но эффективность -вы сами видите. надо делать по-другому: создавать com+ компонент, запускать тучу этих компонентов(а по-сути, процессов) и каждый из них будет запускать не более 62 потока. потоки разных процессов могут работать параллельно за счет того, что в ядре происходит переключение (между процессами) в 1000 раз быстрее.
т.о. подобную задачу в вынь нужно решать не тупым переносом исходного кода, а принципиально иначе.
вот, собственно, почему в синтетических тестах вынь проигрывает линуху. потому что адаптировать и перекопилировать исходный код линуха под вынь - это архитектурная ошибка в вынь. и программисты линуха этого тупо не понимают.
те проблемы, что перечислил автор- это не столько проблема windows, сколько проблема управления очень сложным программным продуктом.
давайте вспомним, как обновляется ядро линуха: модификация идет к Торвальду и только он решает, что войдет в ядро, а что нет. т.е. несмотря на вездесущий continuous integration, апрувит все-равно один чел. так не везде, но думаете от хорошей жизни торвальд этим занялся? или или не в курсе СI, полагаете?
возможно ли что-то подобное с вынь? определенно, нет. вынь определенно сложнее любого линуха по следующим причинам:
графическая подсистема вынь встоена в ядро, в линухе - это просто оболочки вне ядра. соответственно, разработчик оболочек - другой. отсюда в линухе почти нет конкурирующих команд разработки. они уже свои форки понаделали и развивают их кто в лес, кто по дрова отдельно друг от друга.
вынь в обязательном порядке содержит пользовательские компоненты уровня ОС - com/dcom/com+/activex/старые ole, которые экспортируют в ОС свое апи и импортируют чужое, в т.ч. таких же рядом лежащих компонентов. это апи имеет платформенный стандарт и описывается в tlb библиотеках, которые идут в паре с компонентом. и этот апи не имеет отношения к winap или сервисам вынь (они могут использовать несколько таких компонетов). никакого подобного механизма(пользовательские объекты на уровне ОС), и тем более, реализаций под него в линухах нет, имхо.
наличие объектных компонентов уровня ОС привело вынь к механизму интеграции оных в о внутреннюю безопасность вынь. т.е. компонент может запуститься по желанию стороннего кода согласно своих настроек, например, под учеткой админа, или вызывающего юзера или еще кого. и компонент будучи админом, может временами "прикидываться" юзером, чтобы внутренние механизмы безопасности сами разгребали, что доступно этому юзеру, а что нет. это очень глубокая интеграция.
обильное наличие внутренних сервисов на этих компонентах - вот причина проблем стабильности винды. совершенно понятно, что команда, которая делает iis не будет заниматься ms sql или сервисом выпуска сертификата. а оформлять любое функциональное решение в com/com+ - это требование ms и внутри компании оно четко соблюдается. отсюда - много команд, но механизмы ОС одни и те же (безопасность, доступ к файлам, памяти и пр.).
в качестве еще одного доказательства приведу пример того, что ms в считанные месяцы смогло включить внутрь вынь клон линуха. при этом, в отличие от виртуальных машин, линух видит родной диск вынь и даже пытается взаимодействовать с безопасностью вынь. т.е. это показывает, что вынь "проглотила" линух и не почти заметила этого.
также не согласен с идеей о том, что в линухе патчи способствуют исключительно стабильности и производительности. автор совершенно упустил из виду факты целенаправленного встраивания разных зловредов в исходный код открытых ОС. и мотивация здесь может быть совершенно иной: от желания любым способом "засветится" в качестве разработчика такого кода, до сомнительных решений в виде "закладок" на будущее.
стимул принимать внешние разработки для команд ms- есть. у каждой команды есть mvp и он не достижим без таких внешних вливаний. грубо говоря, релиз собственного модуля не выйдет в срок, если ранее было согласовано добавление внешнего кода. определенно, это злит всех. но нельзя сказать, что команда старается игнорировать такие вливания. наоборот, они там орут "давайте быстрее".
решение о mvp в вынь принимают руководители, а не программисты, как в линухе. т.о. руководители и программисты видят ценность своих продуктов по-разному. и это не имеет никакого отношения к продвижению в компании. "я реализую пару интересных проектов и меня подвинут на позицию рук. департамента" - это так не работает в коммерческих структурах. а работает следующее: чел отлично справляется на месте, вот он пусть и дальше этим же занимается.
интересно, что некоторые программисты отрицают наличие проблемы. т.е. факт есть, но он не вписывается в их концепцию мира и они предпочитают делать вид, что ничего подобного не существует и мир -прекрасен, а проблема безопасности решений в общедоступных репозиториях - надумана. и вот, возникает вопрос, что делать с такими? не замечать их??
у меня складывается впечатление, что есть категория программистов, которые не могут жить, чтобы не изучить новый язык за период времени Т. не новую технологию, а именно язык. как будто им существующих языковых средств не хватает.
вот при чем тут жабаскрипт и rust? на жабаскрипте кодят, в основном, фронтендеры. жабаскрипт на бэке используется только в очень крупных приложениях, которые могут себе позволить поддержку скриптинга и своей объектной модели под него. я даже не могу представить себе ситуацию, когда действующий фронтендер захочет как-то поменять жабаскрипт на rust. оно же вообще не для этого. т.о. этот пассаж про жабаскриптеров - вообще не понятен.
мечта парсить файлики тремя строчками кода - ну что за идиотизм? ну напишите вы один раз функцию и применяйте ее вечно. ее вызов - одна строка кода.
из статьи понял, что раст поддерживает в каком-то виде макросы, но что хотел сказать автор - остается загадкой. поговорил сам с собой и остался доволен. кажется так.
фигня. автоматизация не учитывает наличие внутренней щеколды. т.е. закрывать изнутри не обязательно на замок, можно на щеколду. в этом случае ваша поделка покажет, что дверь открыта, а она будет закрыта.
проблема обостряется, когда вас в квартире больше чем 1. например, жена на кухне - кричите: "я ушел, закрой дверь". и все. последняя запись в телеге "дверь открыта" и без изменений. то ли закрыла, то ли нет. а все ключи, как обычно, лежат на входе. 5 сек. на открыть дверь, взять ключи, закрыть. потом все замки менять будете. особенно обидно будет потому, что там стояла ваша поделка.
предположение о том, что ии вытеснит программистов (в ближайшем будущем) основано на ложных предпосылках. а значит, что и остальное все - просто демагогия для повышения рейтинга автора в сети.
ложные предпосылки основываются на том, что llm: а) осознают себя как личность б)вследствие а) устанавливают себе цели и задачи в) цели и задачи достигаются вовремя г)цели и задачи направлены на создание программного кода.
дальше объяснять?
>режем входной сигнал с помощью разветвителя из резисторов
с помощью резистров изменить фазу не получится. возможны варианты только с помощью конденсаторов и индуктивностей.
без осциллографа разрабатывать электронные схемы вообще не имеет смысла. потому что реальные радиодетали не всегда ведут себя так, как в программе эмуляции.
в укв диапазоне ведется чм-модулированное вещание. если вы попали на станцию, прием будет чистый. помехи в приеме характерны для ам-модуляции. предполагаю, что в схеме смешались кони-люди. получить помехи при чм-модуляции - это еще уметь надо.
Создать свой проц - это Мечта творческого технического специалиста. Такая же, как - создать свою операционную систему. И если полететь на Марс ему не грозит даже в самых смелых грезах, то такая мечта выглядит осуществимой.
Однако, вы уже поняли к чему я веду. Реализовать даже одну мечту одному - очень сложно, об этом -ниже. Реализовать же вторую мечту ему же- практически невозможно. Допустим, вы сделали и отладили проц. Теперь под него нужно сделать операционную систему, компилятор и отладчик. Поскольку писать проги будете не на самом устройстве, нужен еще эмулятор устройства на ПК, совместимый с отладчиком. Ну, понятно, загрузчик программы в устройство, потому как флешка более подходит для финального варианта. а до того будет 100млн итераций отладки.
это я к чему? система команд мне кажется недостаточно проработана. лучше бы использовать какую-то из стандартных существующих процов. с одной стороны тогда можно было бы сравнивать промышленные образы с вашей поделкой с точки зрения производительности. с другой стороны, можно реиспользовать сущ. ПО. на низкой частоте работает куча процов арма. вот вариант.
стандартные битовые операции реализованы не все: нужно и, или, not, xor, битовый сдвиг влево, битовый сдвиг вправо. без этого криптографию - не реализовать. криптография нужна в ssl/tls, что в свою очередь сейчас нужно для всех сайтов в инете, потому как обычный http сейчас считается небезопасным.
не увидел выхода не то что на видеокарту, даже на обычный мини-дисплей. вы предлагаете под это дело занять все свободные gpio?
аппаратные прерывания любого современного проца - стандартны: деление на 0, ошибка доступа к памяти, прерывание отладки и др. не увидел поддерживаемого списка таких прерываний.
не увидел потуг на мультизадачность. зачем вам однопоточный проц? любой arm на 33мгц делает в этой части ваш проц.
я не убиваю вашу мечту. самому было бы интересно. но так понимаю, вы больше по аппаратной части и над программной составляющей (что надо то?) сильно не задумывались.