Я правильно понял, что у вас SPA работает с grpc на protobuf? И как на это смотрят фронтендеры? Им же обычно хочется graphql или хотябы REST с кучей гибких модификаторов.
Сложный вопрос на счет обычного пользователя. Есть возможность смотреть как супруга воюет с Linux на одном компе и Mac Air. В обоих случаях она теряется в казалось бы простых сценариях. Например на Маке ее ввела в ступор максимизация окна, из которой она не понимала как выйти. И я с удивлением понял, что MacOs не делает никаких подсказок в интерфейсе для неискушенного пользователя.
Сама идея делать sql на основе nosql попахивает махровой романтикой. Таких проектов за последние 15 лет было очень много и несмотря на красивые картинки они по-прежнему уступают в рыночной доле традиционным решениям.
Хотя, безусловно, с инженерной точки зрения Calcite впечатляет.
Пока это напоминает САПР из 70-х годов, когда проще на кульмане начертить, чем на компьютере
Чертить, возможно было и удобнее, но согласовывать разные чертежи между собой нет. Собственно это самое большое приемущество САПР в 70е. Поэтому тот же Airbas A320 делали полность цифровым способом. Хотя это уже начало 80х.
Они пытаются заставить нас думать как компьютер, а не наоборот — подчинить железо нашим потребностям. Чтобы понять, как работает код алгоритма, нужно представлять, как машина будет его выполнять. Я решил, что хочу уйти от этого подхода.
Любопытно, что функциональное программирование в целом пытается сделать то же самое, но другим путем: отказаться от конкретной реализации и идти по пути абстрактного математического языка (лямбда счисление, теория категорий, комбинаторика и т.д.).
На мой взгляд, потеть должна машина, а человек учиться, не выворачивая мозги наизнанку.
Мне всегда казалось, что любое обучение это всегда тяжело. Как говорил препод по матану в университете: "Вы думаете мне дается легко то что я вам преподаю? Я на это потратил 30 лет жизни и не все они были прекрасны, но мне нравится это делать, нравится преодолевать собственное непонимание."
Ну уж в пух и прах. Указал на две явные проблемы, про которые вроде как все и так знают и пытаются исправить. Похоже вы не застали те времена, когда Торвальдс мог такие трехэтажные перлы выдавать, что зачитаешься.
В целом судя по LKLM Rust в ядре однозначно быть ибо в этом заинтересованы почти все, кто должны, а кто не особо заинтересован (как Торвальдс) категорично не отрицают возможность.
Хм. А как же этическая сторона вопроса, особенно в пандемию? Я готов платить музыканту за его труд. И т.к. концерты сейчас не доступны, то покупая его альбомы или пользуясь стримингом я ему деньгу засылаю.
Да, конечно, посредников тут жуть сколько, но хоть и как-то.
Есть ли вообще смысл использовать ядро, если мы говорим о высокой производительности? Или надо уходить в bypass. Вот например хороший текст об этом от cloudflare https://blog.cloudflare.com/kernel-bypass/
Боюсь что 99% внедренцев CRM на деле в этом ничего не понимают. У меня тоже с этими гражданами сугубо негативный опыт. Это проблема современного IT: чудовищно низкий уровень персонала.
Сложный это вопрос. Если проще, то сейчас нет возможности сделать геокластер прямыми средствами. Единственно разумное решение это Dual ETL или что-то похожее на Dual ETL, когда после окончания записи осуществляет перенос данных на другой кластер через gpbackup/gprestore.
Но это если говорить про 6ю версию. В семерке планируются улучшения в этом плане, но это будет анонсировано позже.
— Я запустил оригинальный Doom в DosBox, который запущен на Linux, который запущен в VirtualBox, который работает под Windows. Кому жаловаться на неработающий звук?
— Санитарам.
Поддерживаю. Сам по себе вим устарел технически и не дотягивает до современных ide во многих аспектах, хотя проекты типа neovim пытаются это исправить.
Но в каждой ide есть вим мод. И наверное он там не зря.
Очень странно. Под Винду программируете? Из моего опыта разработки под никсы, на компанию в 50 человек всегда находится 1-2 вимера. Лично я к этому так давно привык, что не воспринимаю ту же idea без vim плагина.
Ну все же это просто совпадение по времени.
Да нет у меня выборки, просто личные впечатления.
Я правильно понял, что у вас SPA работает с grpc на protobuf? И как на это смотрят фронтендеры? Им же обычно хочется graphql или хотябы REST с кучей гибких модификаторов.
Сложный вопрос на счет обычного пользователя. Есть возможность смотреть как супруга воюет с Linux на одном компе и Mac Air. В обоих случаях она теряется в казалось бы простых сценариях. Например на Маке ее ввела в ступор максимизация окна, из которой она не понимала как выйти. И я с удивлением понял, что MacOs не делает никаких подсказок в интерфейсе для неискушенного пользователя.
Сама идея делать sql на основе nosql попахивает махровой романтикой. Таких проектов за последние 15 лет было очень много и несмотря на красивые картинки они по-прежнему уступают в рыночной доле традиционным решениям.
Хотя, безусловно, с инженерной точки зрения Calcite впечатляет.
Чертить, возможно было и удобнее, но согласовывать разные чертежи между собой нет. Собственно это самое большое приемущество САПР в 70е. Поэтому тот же Airbas A320 делали полность цифровым способом. Хотя это уже начало 80х.
Любопытно, что функциональное программирование в целом пытается сделать то же самое, но другим путем: отказаться от конкретной реализации и идти по пути абстрактного математического языка (лямбда счисление, теория категорий, комбинаторика и т.д.).
Мне всегда казалось, что любое обучение это всегда тяжело. Как говорил препод по матану в университете: "Вы думаете мне дается легко то что я вам преподаю? Я на это потратил 30 лет жизни и не все они были прекрасны, но мне нравится это делать, нравится преодолевать собственное непонимание."
Ну уж в пух и прах. Указал на две явные проблемы, про которые вроде как все и так знают и пытаются исправить. Похоже вы не застали те времена, когда Торвальдс мог такие трехэтажные перлы выдавать, что зачитаешься.
В целом судя по LKLM Rust в ядре однозначно быть ибо в этом заинтересованы почти все, кто должны, а кто не особо заинтересован (как Торвальдс) категорично не отрицают возможность.
Хм. А как же этическая сторона вопроса, особенно в пандемию? Я готов платить музыканту за его труд. И т.к. концерты сейчас не доступны, то покупая его альбомы или пользуясь стримингом я ему деньгу засылаю.
Да, конечно, посредников тут жуть сколько, но хоть и как-то.
Так есть же уже вроде готовые библиотеки, в которых все это сделано. Понятно, что они заточены под конкретные карточки, но они есть.
Есть ли вообще смысл использовать ядро, если мы говорим о высокой производительности? Или надо уходить в bypass. Вот например хороший текст об этом от cloudflare https://blog.cloudflare.com/kernel-bypass/
Все же раз существует так мало известных программ с UI на Java, значит есть какие-то более важные причины, нежели недостатки JavaFX
Этому оригиналу столько, что хорошо, что я хоть что-то помню
Боюсь что 99% внедренцев CRM на деле в этом ничего не понимают. У меня тоже с этими гражданами сугубо негативный опыт. Это проблема современного IT: чудовищно низкий уровень персонала.
Сложный это вопрос. Если проще, то сейчас нет возможности сделать геокластер прямыми средствами. Единственно разумное решение это Dual ETL или что-то похожее на Dual ETL, когда после окончания записи осуществляет перенос данных на другой кластер через gpbackup/gprestore.
Но это если говорить про 6ю версию. В семерке планируются улучшения в этом плане, но это будет анонсировано позже.
Поддерживаю. Сам по себе вим устарел технически и не дотягивает до современных ide во многих аспектах, хотя проекты типа neovim пытаются это исправить.
Но в каждой ide есть вим мод. И наверное он там не зря.
Если вы не знаете про пупырышки, то похоже и в слепую не печатаете. Это так? Если да, то тогда вим вообще вам не подходит.
Очень странно. Под Винду программируете? Из моего опыта разработки под никсы, на компанию в 50 человек всегда находится 1-2 вимера. Лично я к этому так давно привык, что не воспринимаю ту же idea без vim плагина.