И я бы начинал с истоков. На мой взгляд проблема с++ как раз в том что люди пытаются не зная как оно изначально придумывалось вертеть с++ во все стороны. Т.е. те же самые «умные указатели» — это средство как не потерять память, как сделать RAII в «таксебе-RAII» среде. По сути «костыль». А у новичков я часто вижу обратное — «указатель это быстрая версия но усеченая умного указателя»
Сами разработчики — нет. Как и «джамшуты» на стройках. Но там и процесс другой.
Если уж сравнивать со строками, то всякие разные стартаперы это как колымшики на ремонтах… за сезон могут отличные деньги поднять, а дальше сидеть и искать работу ну или набрать клиентуру.
А сертифицированные застройщики это разные Микрософты, Гуглы и Яндексы, куда с улицы без образования попасть тоже непросто.
А и да если вы сварщик самоучка который «от бога» то толковое проектное бюро вас на вечерние курсы само отправит чтобы удовлетворить формальности.
ну на самом деле не так все в Плюсах плохо. Тем более после Джавы… На мой взгляд количество граблей с которыми приходится мужественно бороться примерно тоже. Только места другие. Моя старая шутка — в плюсах все пытаются придумать ссылки и manage_code с GC… В Jave и C# изобретают указатели.
ну справедливости ради, в СССР предпреимчивый «фарцовцик фирмЫ» получал не меньше шахтера… Если бы государство не так огульно запрещало бы это — то может быть и обошлось бы.
Ну как бы есть разница между «софтом самоучек» и «софтом лицензированным». Если вы захотите так влезьть например на рынок разработки софта для Ядренных станций — вы также обломаетесь на первом пункте.
А в строительстве — бригада самоучек легко может строить коробки на дачных участках и ремонтировать квартирки.
Дак собственно и проблема что в «Си-с-классами», который сильно условно «объектно ориентированый» и не очень «метапрограмированный» пытаются натянуть еще больше объектно ориентированности и метапрограммируемости. Все косяки плюсов на которые кивают опоненты из разряда «агааа вот как криво реализована эта фича, множество ограничений и UB». Ну дак новые стандарты кривости не исправляют, максимум подпирают костылями, а плюсом втыкают еще грабли… 99 стандарт «жил» 12 лет. а 11 стандарт только 3 года, и отнюдь не из за того что за 3 года «придумали новые хорошие плюшки». Зачем это делать лично мне непонятно.
Хороший пример, это собеседования… Когда вместо написания кода просят пояснить чем make_shared отличается от конструктора shared_ptr. Зачем forward, если есть move и прочее. Т.е. просят понимания ньюансов языка. При этом вопросы про ньюансы работы всяких «вызов виртуального метода в конструкторе» — никуда не ушли.
На самом деле все просто. «Не туда» это когда для того чтобы впсисать концепцию в язык приходиться измудряться со скобками. Даже в этой статье пример c# и linq. Хорошо читаемый и понятный код на шарпах… Представляю как будет выглядеть linq на с++.
Ну в хардваре это тоже есть. Ктото зарабатывает на продаже дорогих авто, а кто-то на ремонте дешевых — модели бизнеса аналогичные. Но все же никто не раздает дешевые авто бесплатно.
В софте даже интерпрайзном существует себестоимость только первой копии… а остальные копии дефакто — бесплатны и на них можно размазывать себестоимость первой сколько угодно.
Если что колесо было придумано человечеством 6-7 тысяч лет назад…
Методы обработки метала 4 тысячи.
Да что уж там — фабричность, конвееры, гидроэнергетика не позднее 19 века…
Так что Unix утилитам, tcp протоколам и прочему еще стареть и стареть…
Ну как бы я немного знаю «фронтедщиков из сферы оценки недвижимости» на ролях хотя бы мидлов в топовых компаниях. Не берем всяких «торговцев рабами на галерах» — те в принципе и дворника возьмут лишь бы продать смогли.
Найти толкового с++ программиста на оклад 4 х средняя_зп_по_городу задачка из крайне нелегких… Реально ВУЗы не справляются с поставкой нормальных — слишком быстро растет рынок. Даже в столь казалось бы консервативной части. А уж в фронтендах…
Дак просто же все. Для производства продукта в IT отрасли нужно минимум прослоек из всяческого «обслуживающего» персонала, и практически никаких материальных ресурсов. Собственно поэтому и существуют IT-шные стартапы. Поэтому и разбегутся если не платить.
Почему это не пузырь? Ну начнем с того что сама по себе стоимость информации — это пузырь. Однако очень такой твердый пузырь. Стоимость производимого програмистами софта — тоже пузырь, иначе попробуйте обосновать разницу в стоимости opensource продукта и его платного аналога. Например Linux vs Windows
Ну как то сравнивать ситуацию «тупой клиент / умная схд» и «умный клиент /тупая схд» несколько неправильно.
И кстати не сравнивал iSCSI (SCSI over IP) и Samba (тоже over IP) какие там будут накладные расходы. Но вот если у нас будет FC то там как раз плюх много. Тот же самый Multipath для пропускной способности и резервирования линков…
Данные с камер надо принять… наверное по ip мелкими фрагментами этих камер много… 10 тысяч. если каждая будет писать в свой пусть большой файл… это 10 тысяч iops… пусть и последовательно. Потом удалять — это фрагментация…
Я не спорю что решить с помощью NAS это можно. Но не так с наскоку… Придется группировать данные разных камер в один огромный файл. каким то образом строить в нем систему ссылок.
Дык так оно в этой сфере не бывает. «Опытная» означает что вас пустят на площадку, дадут работать с оборудованием/софтом, ну а если данные таки потеряют то грозный дядя майор не отправит вас на этап, а просто будет очень неприятно.
Еще это означает что у вас таки есть шанс согласовать простой на несколько минут на переключение чего либо куда либо.
Еще это означает что комплекс не принят на приемосдаточных испытаниях и денег разработчик могет и не получить.
А ну и еще означает что «вежливые люди» будут знать, что к комплексу имеют доступ разработчики и никаких особо секретных работ, которые могут раскрыть оперативные мероприятия проводить не надо.
если вы работаете с файлами — то задача размещения этих файлов по блокам решается СХД наверняка общего назначения. А она ничего не знает ни о будущих размерах файлов ни о порядке доступа к ним. Ну и тут сразу вопрос: а какая СХД и какая там файловая система и подходит ли она для вашего профиля нагрузки. (много мелких файлов / несколько но огромных). Кроме того плюсом идет затраты на обеспечение синхронизации доступа к файлам с нескольких инициаторов.
При блочном доступе — выбор ФС и порядок доступа определяется клиентом который знает что у него там за профиль нагрузки. Плюсом в помощь кэш операционной системы или вообще директная запись в блоки. А со стороны СХД совcем не надо заботиться о синхронизации доступа к LUN.
Нагрузка от десятка видеокамер — конечно не заоблачная… Беда в том что этих камер «несколько тысяч» раскиданных по всему городу…
Полпетабайта в месяц это примерно 200 мегабайт в секунду… Тю… пара дисков в зеркале…
Однако несколько тысяч камер наверняка гонят данные покадрово, пакетиками, да еще надо складировать наверняка каждую камеру отдельно… Вот вам уже «несколько тысяч IOPS». Если данные прибегают по IP то пакет килобайт-полтора… В идеальном H264overRTP 65k. Ну то есть от сотни тысяч до поллумиллиона IOPS.
Так что просто получить и просто записать в файлики «в лоб» уже не получается. У нас ведь не SSD… это несколько тысяч шпинделей надо. Придется аггрегировать/копить/последовательно писать/группировать.
Поэтому кстати и не файлы ибо блочные устройства последовательны и задачу группировки запросов будет решать не СХД, а файловая система на сервере, который хотябы представляет с какими данными работает сервер и как можно оптимизировать группировку. Ну и минус разные расходы на сетевые вещи самбы.
P.S. Я не сотрудник SoftLine и отношения к этой СХД не имею
Ну на самом деле странные доводы. Если сравнивать «Тупой Rest поверх TCP/IP» со специализированным протоколом… то наверное это как то бессмысленно.
1) раздельные каналы (не менее 10 по стандарту), в каждом из которых своё упорядочение сообщений;
Кто мешает сделать 10 логических каналов в TCP? Передавайте контролинг в одном канале, онлайн сообщения в другом, картинки качайте в третьем. Причем не тупо передачей файла а побив на фрагменты.
2) опции отправки сообщений с ограничением по количеству перепосылок или по времени доставки.
Аналогично это может быть на логике приложения.
Нарушение необходимости присылать ранее отправленные данные
Тут я не понял про что вы? tools.ietf.org/html/rfc2018 — SACK — по моему уже 100 лет везде по умолчанию включена.
Нет, конечно TCP не идеален, иначе не было бы разных специфических стеков. Но IMHO мессенджеры это не та сфера где уже исчерпаны все возможности TCP, чтобы жертвовать преимуществами его широкого распространения.
Конечно, если изобрести что-то очень очень узкозаточенное, причем и по функционалу и по условиям использования — есть шанс сделать лучше. Но это будет очень узко специализированное.
А например в настройках сетевого стека tcp у линукс 100500 всяких параметров. Там наверняка есть то что нужно, надо только найти нужное )))
Если уж сравнивать со строками, то всякие разные стартаперы это как колымшики на ремонтах… за сезон могут отличные деньги поднять, а дальше сидеть и искать работу ну или набрать клиентуру.
А сертифицированные застройщики это разные Микрософты, Гуглы и Яндексы, куда с улицы без образования попасть тоже непросто.
А и да если вы сварщик самоучка который «от бога» то толковое проектное бюро вас на вечерние курсы само отправит чтобы удовлетворить формальности.
А в строительстве — бригада самоучек легко может строить коробки на дачных участках и ремонтировать квартирки.
Хороший пример, это собеседования… Когда вместо написания кода просят пояснить чем make_shared отличается от конструктора shared_ptr. Зачем forward, если есть move и прочее. Т.е. просят понимания ньюансов языка. При этом вопросы про ньюансы работы всяких «вызов виртуального метода в конструкторе» — никуда не ушли.
В софте даже интерпрайзном существует себестоимость только первой копии… а остальные копии дефакто — бесплатны и на них можно размазывать себестоимость первой сколько угодно.
Методы обработки метала 4 тысячи.
Да что уж там — фабричность, конвееры, гидроэнергетика не позднее 19 века…
Так что Unix утилитам, tcp протоколам и прочему еще стареть и стареть…
Найти толкового с++ программиста на оклад 4 х средняя_зп_по_городу задачка из крайне нелегких… Реально ВУЗы не справляются с поставкой нормальных — слишком быстро растет рынок. Даже в столь казалось бы консервативной части. А уж в фронтендах…
Почему это не пузырь? Ну начнем с того что сама по себе стоимость информации — это пузырь. Однако очень такой твердый пузырь. Стоимость производимого програмистами софта — тоже пузырь, иначе попробуйте обосновать разницу в стоимости opensource продукта и его платного аналога. Например Linux vs Windows
И кстати не сравнивал iSCSI (SCSI over IP) и Samba (тоже over IP) какие там будут накладные расходы. Но вот если у нас будет FC то там как раз плюх много. Тот же самый Multipath для пропускной способности и резервирования линков…
Я не спорю что решить с помощью NAS это можно. Но не так с наскоку… Придется группировать данные разных камер в один огромный файл. каким то образом строить в нем систему ссылок.
Еще это означает что у вас таки есть шанс согласовать простой на несколько минут на переключение чего либо куда либо.
Еще это означает что комплекс не принят на приемосдаточных испытаниях и денег разработчик могет и не получить.
А ну и еще означает что «вежливые люди» будут знать, что к комплексу имеют доступ разработчики и никаких особо секретных работ, которые могут раскрыть оперативные мероприятия проводить не надо.
Но просто так грохнуть данные вам не разрешат…
При блочном доступе — выбор ФС и порядок доступа определяется клиентом который знает что у него там за профиль нагрузки. Плюсом в помощь кэш операционной системы или вообще директная запись в блоки. А со стороны СХД совcем не надо заботиться о синхронизации доступа к LUN.
Полпетабайта в месяц это примерно 200 мегабайт в секунду… Тю… пара дисков в зеркале…
Однако несколько тысяч камер наверняка гонят данные покадрово, пакетиками, да еще надо складировать наверняка каждую камеру отдельно… Вот вам уже «несколько тысяч IOPS». Если данные прибегают по IP то пакет килобайт-полтора… В идеальном H264overRTP 65k. Ну то есть от сотни тысяч до поллумиллиона IOPS.
Так что просто получить и просто записать в файлики «в лоб» уже не получается. У нас ведь не SSD… это несколько тысяч шпинделей надо. Придется аггрегировать/копить/последовательно писать/группировать.
Поэтому кстати и не файлы ибо блочные устройства последовательны и задачу группировки запросов будет решать не СХД, а файловая система на сервере, который хотябы представляет с какими данными работает сервер и как можно оптимизировать группировку. Ну и минус разные расходы на сетевые вещи самбы.
P.S. Я не сотрудник SoftLine и отношения к этой СХД не имею
Кто мешает сделать 10 логических каналов в TCP? Передавайте контролинг в одном канале, онлайн сообщения в другом, картинки качайте в третьем. Причем не тупо передачей файла а побив на фрагменты.
Аналогично это может быть на логике приложения.
Тут я не понял про что вы? tools.ietf.org/html/rfc2018 — SACK — по моему уже 100 лет везде по умолчанию включена.
Нет, конечно TCP не идеален, иначе не было бы разных специфических стеков. Но IMHO мессенджеры это не та сфера где уже исчерпаны все возможности TCP, чтобы жертвовать преимуществами его широкого распространения.
Конечно, если изобрести что-то очень очень узкозаточенное, причем и по функционалу и по условиям использования — есть шанс сделать лучше. Но это будет очень узко специализированное.
А например в настройках сетевого стека tcp у линукс 100500 всяких параметров. Там наверняка есть то что нужно, надо только найти нужное )))