Цитато: "WebSocket is a computer communications protocol, providing full-duplex communication channels over a single TCP connection." Че, реально?
gRPC - это еще одна реализация RPC, позволю себе процитировать wiki:
Request–response protocols date to early distributed computing in the late 1960s, theoretical proposals of remote procedure calls as the model of network operations date to the 1970s, and practical implementations date to the early 1980s. Bruce Jay Nelson is generally credited with coining the term "remote procedure call" in 1981.[1]
Remote procedure calls used in modern operating systems trace their roots back to the RC 4000 multiprogramming system,[2] which used a request-response communication protocol for process synchronization.[3] The idea of treating network operations as remote procedure calls goes back at least to the 1970s in early ARPANET documents.[4] In 1978, Per Brinch Hansen proposed Distributed Processes, a language for distributed computing based on "external requests" consisting of procedure calls between processes.
Вот что действительно относительно новое - это что у каждого клиента мы можем ожидать работающую виртуальную машину (Java или Javascript), но тоже началось в 90е, хотя конечно не в таком развесистом виде как сейчас.
Мне сложно сказать про криптографию, не специалист.
Остальное перечисленное вами - ну была другая аббревиатура или другая реализация, но "что-то подобное" уже было в прошлом веке.
Да, последний пункт ("сетевые протоколы" поверх базовых TCP/UDP) - туда масса усилий вложено после 2000, но вот каковы принципиально новые концепции, которых не было известно 25-30 лет назад? Возможно они есть, но вот прям такие что прям вау?
От того что конкретная реализация (сжатия, simd) появилась недавно - это же не становится новой концепцией, правда?
Слушайте, ну MPI придумали от тоски, в смысле от того, что задача перестала влезать на одну ноду. После чего сразу стали его ломать разными способами, только бы ускорить (RDMA очевидно же абсолютно не в парадигме MPI)
Пускать параллельные "тесно связанные" задачи внутри одной многопроцессорной системы на процессах и использовать средства ОС для синхронизации имеет смысл только если этой синхронизации у вас совсем немного и в реальности она на производительность практически не влияет и объемы передаваемых между процессами данных невелики.
Из C++ (текущего) вполне можно вырезать "простое и понятное", ну в некоторых пределах. Правда в разных случаях (командах, компаниях) эта вырезка будет сильно разной, то есть когда к вам приходит новый сотрудник - он будет долгое время переключаться на ваше, отчего будут всякие (решаемые) проблемы.
Проблема C++ в том, что сам язык слишком сложный, во всей его полноте его мало кто знает: для этого нужно прочитать и понять текущий (используемый) стандарт и все предыдущие и понимать чем вызвано конкретное изменение. Это делают не только лишь все, как следствие - знание языка у (большинства/всех) членов команды - фрагментарное и фрагменты эти не совпадают.
Причем, эта проблема ("слишком сложный язык") уже и 20 лет назад была, а с тех пор многократно усугубилась.
Коллега, я вот пишу на С++ уже более 30 лет и с ним случилась нехорошая метаморфоза: из достаточно простого и понятного С-с-классами получился чудовищно сложный, перетяжеленный язык, попытки исправить который делают только хуже (по причине возрастания сложности языка). Понятно что причина в legacy, код 30-летней давности должен собираться и работать.
Не знаю что с этим делать, замены C++/Qt действительно не вижу на сегодня, может быть плохо смотрел. Но она точно вот уже нужна.
"нефтяные скважины бурить стало дороже" но не настолько дорого, насколько могло бы быть. Ну и сравнивая цены на нефть - не забывайте про инфляцию, сейчас дешевле чем в 1980м
Судя по хелпу меги, там есть 1) folder links, то есть мы публикуем ссылку на папку - и все желающие могут скачать файлы из папки. Если на стороне меги не хранятся нешифрованые файлы - это получается что у всех файлов в папке один ключ шифрования.
2) shared folders (между пользователями меги) - что будет с ключами на файлы у таких папок? Общий на всех пользователей, втч на тех, кого пригласили позднее?
Ну смотрите, у фотонного шума, по определению, "дисперсия равна сигналу", то есть сигма равна корню из сигнала.
Представим себе сенсор в усилении "1 электрон - одна единица в RAW". Шум на разумных выдержках (единицы секунд и меньше) будет порядка нескольких единиц RAW. При сигнале 100 электронов (100 единиц raw) фотонный шум будет 10, то есть кратно больше темнового шума.
Это те самые "полутени" и есть, ну скажем при размахе сигнала в 14 бит, что типично сегодня, это в 160 раз или 7 с небольшим стопов ниже точки насыщения, самые что ни есть интересные сюжетные тени.
Ну "26ev" это же не на одной сцене, а вообще рабочий диапазон глаза. 26ev - это, округляя "60 млн раз". Это размах яркостей между солнечным днем (выдержка 1/16000 в фото) и глубокой безлунной ночью (выдержка 4 тысячи секунд, то есть ~час).
Ну да, человеческий глаз способен видеть кое-что и ночью, при свете звезд, и в солнечный полдень. Но я вот абсолютно точно знаю, что если вы при свете звезд на 10 секунд посветили фонариком - вы сбили ночное зрение и начнете опять видеть звезды - через минуты (много раз делал такую ошибку при ночной фотосъемке, вместо красного фонарика сдуру включал обычный). Глаз не может видеть такой размах яркостей (да даже и на много порядков меньший, фонарик - это не яркое солнце), а должен (многие) минуты адаптироваться.
Ну да, то что человеческий глаз ночью просто видит (сразу) - фотоаппарату нужны многоминутные выдержки, это правда. Но справляется. Причем время съемки оно примерно того же порядка, что и время адаптации зрения.
Сложная это все история, ну вот совсем грубо, если вы покажете молнию (конкретно молнию, про нее же пример) в 10 раз ярче листа бумаги, или в 100 раз ярче или 1000 раз ярче - никакой разницы для зрителя не будет: ну мелькнуло что-то яркое за окном и хорошо. Если/когда эту молнию снимали на пленку, эти 10-100-1000 раз сжимались в микроскопическую разницу в плотности (и так и так все/практически все серебро что было в эмульсии - засвечивалось), возможно монтажер и видел разницу, а зритель - точно нет.
А если вы хотите качественно (в смысле "количественно") захватить/воспроизвести разницу между "в 100 раз ярче" и в "1000 раз ярче" - вам нужно и в захвате различать эти дополнительные три стопа и, что еще хуже, при воспроизведении. Устройства воспроизведения будут сильно дороже (захвата - тоже, но камера при съемке одна, а кинотеатров/мониторов/проекторов при просмотре - тоже).
Непонятно ради чего эта борьба, если вот честно. Ну кроме, конечно, желания продать зрителю монитор с динамическим контрастом 1:1000000 вместо 1:1000 (а хватило бы и 1:400)
Цитато: "WebSocket is a computer communications protocol, providing full-duplex communication channels over a single TCP connection." Че, реально?
gRPC - это еще одна реализация RPC, позволю себе процитировать wiki:
Request–response protocols date to early distributed computing in the late 1960s, theoretical proposals of remote procedure calls as the model of network operations date to the 1970s, and practical implementations date to the early 1980s. Bruce Jay Nelson is generally credited with coining the term "remote procedure call" in 1981.[1]
Remote procedure calls used in modern operating systems trace their roots back to the RC 4000 multiprogramming system,[2] which used a request-response communication protocol for process synchronization.[3] The idea of treating network operations as remote procedure calls goes back at least to the 1970s in early ARPANET documents.[4] In 1978, Per Brinch Hansen proposed Distributed Processes, a language for distributed computing based on "external requests" consisting of procedure calls between processes.
Вот что действительно относительно новое - это что у каждого клиента мы можем ожидать работающую виртуальную машину (Java или Javascript), но тоже началось в 90е, хотя конечно не в таком развесистом виде как сейчас.
Мне сложно сказать про криптографию, не специалист.
Остальное перечисленное вами - ну была другая аббревиатура или другая реализация, но "что-то подобное" уже было в прошлом веке.
Да, последний пункт ("сетевые протоколы" поверх базовых TCP/UDP) - туда масса усилий вложено после 2000, но вот каковы принципиально новые концепции, которых не было известно 25-30 лет назад? Возможно они есть, но вот прям такие что прям вау?
От того что конкретная реализация (сжатия, simd) появилась недавно - это же не становится новой концепцией, правда?
По описанию (в код не вчитывался) это очень похоже на сильно упрощенный вариант Area Resize (у нас в стране известно как C3C resize) с целыми весами.
Слушайте, ну MPI придумали от тоски, в смысле от того, что задача перестала влезать на одну ноду.
После чего сразу стали его ломать разными способами, только бы ускорить (RDMA очевидно же абсолютно не в парадигме MPI)
Пускать параллельные "тесно связанные" задачи внутри одной многопроцессорной системы на процессах и использовать средства ОС для синхронизации имеет смысл только если этой синхронизации у вас совсем немного и в реальности она на производительность практически не влияет и объемы передаваемых между процессами данных невелики.
Ну, или если производительность не интересует.
Оторвать совместимость со старым кодом, остальное подчистить - будет так то неплохо. Но нет
На форте я со школы не писал, придется вспоминать.
Я не про говнякать и не про "проектировать постфактум". Наговнякать несложно.
Я именно про язык C++: он слишком сложный и его никто не знает на самом то деле. В этом проблема.
А наговнякать я могу и на фортране-4.
Из C++ (текущего) вполне можно вырезать "простое и понятное", ну в некоторых пределах. Правда в разных случаях (командах, компаниях) эта вырезка будет сильно разной, то есть когда к вам приходит новый сотрудник - он будет долгое время переключаться на ваше, отчего будут всякие (решаемые) проблемы.
Проблема C++ в том, что сам язык слишком сложный, во всей его полноте его мало кто знает: для этого нужно прочитать и понять текущий (используемый) стандарт и все предыдущие и понимать чем вызвано конкретное изменение. Это делают не только лишь все, как следствие - знание языка у (большинства/всех) членов команды - фрагментарное и фрагменты эти не совпадают.
Причем, эта проблема ("слишком сложный язык") уже и 20 лет назад была, а с тех пор многократно усугубилась.
Коллега, я вот пишу на С++ уже более 30 лет и с ним случилась нехорошая метаморфоза: из достаточно простого и понятного С-с-классами получился чудовищно сложный, перетяжеленный язык, попытки исправить который делают только хуже (по причине возрастания сложности языка). Понятно что причина в legacy, код 30-летней давности должен собираться и работать.
Не знаю что с этим делать, замены C++/Qt действительно не вижу на сегодня, может быть плохо смотрел. Но она точно вот уже нужна.
35 лет назад я получил первую зарплату за программирование. И продолжаю, не собираюсь прекращать....
"нефтяные скважины бурить стало дороже" но не настолько дорого, насколько могло бы быть.
Ну и сравнивая цены на нефть - не забывайте про инфляцию, сейчас дешевле чем в 1980м
Судя по хелпу меги, там есть
1) folder links, то есть мы публикуем ссылку на папку - и все желающие могут скачать файлы из папки.
Если на стороне меги не хранятся нешифрованые файлы - это получается что у всех файлов в папке один ключ шифрования.
2) shared folders (между пользователями меги) - что будет с ключами на файлы у таких папок? Общий на всех пользователей, втч на тех, кого пригласили позднее?
Что-то тут не бьется совсем.
как можно удалить файл не зная что в нем?
Ну тогда этот ключ знает и сервис, потому что там есть "сделать ссылку"
А как же потом можно скачать по публичной ссылке оттуда?
Ну смотрите, у фотонного шума, по определению, "дисперсия равна сигналу", то есть сигма равна корню из сигнала.
Представим себе сенсор в усилении "1 электрон - одна единица в RAW". Шум на разумных выдержках (единицы секунд и меньше) будет порядка нескольких единиц RAW.
При сигнале 100 электронов (100 единиц raw) фотонный шум будет 10, то есть кратно больше темнового шума.
Это те самые "полутени" и есть, ну скажем при размахе сигнала в 14 бит, что типично сегодня, это в 160 раз или 7 с небольшим стопов ниже точки насыщения, самые что ни есть интересные сюжетные тени.
Ну "26ev" это же не на одной сцене, а вообще рабочий диапазон глаза.
26ev - это, округляя "60 млн раз". Это размах яркостей между солнечным днем (выдержка 1/16000 в фото) и глубокой безлунной ночью (выдержка 4 тысячи секунд, то есть ~час).
Ну да, человеческий глаз способен видеть кое-что и ночью, при свете звезд, и в солнечный полдень.
Но я вот абсолютно точно знаю, что если вы при свете звезд на 10 секунд посветили фонариком - вы сбили ночное зрение и начнете опять видеть звезды - через минуты (много раз делал такую ошибку при ночной фотосъемке, вместо красного фонарика сдуру включал обычный). Глаз не может видеть такой размах яркостей (да даже и на много порядков меньший, фонарик - это не яркое солнце), а должен (многие) минуты адаптироваться.
Ну да, то что человеческий глаз ночью просто видит (сразу) - фотоаппарату нужны многоминутные выдержки, это правда. Но справляется. Причем время съемки оно примерно того же порядка, что и время адаптации зрения.
На практике, основной вклад в шум (кроме, конечно, самых-самых глубоких теней) - это сам сигнал. Фотонный шум.
Битов, конечно, много не бывает, надо же еще компьютеры продавать новые, сторадж и вот это вот все.
Но поверьте мне, вам не нужно записывать ту самую "молнию за окном" точно, лишнее это.
Сложная это все история, ну вот совсем грубо, если вы покажете молнию (конкретно молнию, про нее же пример) в 10 раз ярче листа бумаги, или в 100 раз ярче или 1000 раз ярче - никакой разницы для зрителя не будет: ну мелькнуло что-то яркое за окном и хорошо.
Если/когда эту молнию снимали на пленку, эти 10-100-1000 раз сжимались в микроскопическую разницу в плотности (и так и так все/практически все серебро что было в эмульсии - засвечивалось), возможно монтажер и видел разницу, а зритель - точно нет.
А если вы хотите качественно (в смысле "количественно") захватить/воспроизвести разницу между "в 100 раз ярче" и в "1000 раз ярче" - вам нужно и в захвате различать эти дополнительные три стопа и, что еще хуже, при воспроизведении. Устройства воспроизведения будут сильно дороже (захвата - тоже, но камера при съемке одна, а кинотеатров/мониторов/проекторов при просмотре - тоже).
Непонятно ради чего эта борьба, если вот честно. Ну кроме, конечно, желания продать зрителю монитор с динамическим контрастом 1:1000000 вместо 1:1000 (а хватило бы и 1:400)