Это не их концепция. Это пришло из kde. Тогда только подымали голову быстрые ssd и возникла идея хранить всю мету в унифицированной базе. Это давало ту самую интегрированность с точки зрения поиска. Что-то похожее на современный поиск в Винде и МакОси.
Сама по себе идея норм, но уж очень много ресурсов на это уходило. Поллучилось как с Вистой: после быстрых интерфейсов предыдущего поколения получили тормоза на пустом месте.
Хейта было море. И вот сия пучина и поглатила Амарок. Потом, конечно, фреймворки отладили, ssd стали доступными, но аудитория ушла.
Самый яркий для меня пример, когда лучшее враг хорошего. Когда Амарок только появился, на него перешли, казалось, все кто сидел на Линукс. Он был быстр, удобен, функционален и самобытен. А потом они выпустили версию два в какой-то странной попытке сделать толи Foobar, толи iTunes. Плюс они потянули в проект буквально все самые свежие фишки, что нашли вокруг. Монстр глючил, тормозил и раздражал аудиторию, которой не нужен был Фубар. В результате те кто был влюблен в оригинал разбежались по форкам, фанатов Фубара оказалось мало и плеер буквально умер. Несколько лет его вообще никто не разрабатывал. Сейчас там вроде появилась группа разрабов, но никто уже не вернет 2007.
Исследование мягко говоря не полное. Где статьи про thunderbolt, который вытеснит все стандарты? Где USB от Intel на оптическом кабеле? Передача данных через мигание лампочек (забыл как это называлось). Про телефоны от Майкрософт и Яндекс?
Если вспомнить такие статьи, то там скептики не будут выглядеть комично.
Я думаю противопоставление подхода Picodata и микросервисов несколько искусственное. На мой взгляд запрос на быстрое и надежное транзакционное ядро, в которое можно вынести состояние из сотен сервисов на рынке есть. Обратное тоже верно: вносить в grid абсолютно весь код не выглядит правильным. Особенно если этот код работает с внешними миром с высоким latency.
Что можно вынести в Picodata из микросервисов
MQ
кеши
общие ресурсы требующие конкурентного доступа (привет Redis)
менеджмент состоянии, в том числе DAG, Workflow, Inbox и подобные примитивы
Но при этом в микросервисах должно остаться:
Интерконнект со сторонними сервисами
Высоколатентные операции (например генерация документов)
На сколько я помню Гегель ввел пару тезис-антитезис, как основу формального мышления, а синтез ввели уже после него. Особенно эта триада зашла Марксу и его последователям и стала базовым приемом риторики и логики уже в СССР.
Я не могу себя заставить полюбить go. Основной источник раздражения необходимость механического набора кода, который в других языках просто не нужен. Да, читается это хорошо, но пишется с ненавистью. AI начинает помогать с этим, но эта тема еще развивается.
Не знаю точно, но немного. Можно скомпилировать статическое ядро, выкинув все лишнее и тогда размер в памяти будет измеряться единицами мегабайт. Хотя, конечно, для 486 и 8Mb это мое почтение.
Условно, я делаю на 10%-20% меньше рутинной работы, которая раньше могла отнимать 2-3 часа в день.
2-3 часа в день это до 37%. Мне эта оценка кажется завышенной. Уж очень много приходится перепроверять. А читать код бывает сложнее, чем писать. Особенно в тривиальных случаях.
в проекте всё ок с тестами.
Тут кажется яйцо и курица. Тесты пишем с помощью ИИ, код с помощью ИИ с оглядкой на тесты. И кажется, что ИИ может очень хорошо писать код, который формально проходит тесты, но не работает как надо.
Смысл есть, но и проблем много. Tcp и udp довольно старые и при этом не сказать, что идеальные протоколы. Например механика контроля соединения tcp при работе в локалке с большим потоком данных избыточен, но и отсутствие контроля доставки udp может напрягать.
Я понимаю почему совместимость с C нужна была в момент появления C++. Но сейчас это выглядит странно: C очень низкоуровневый язык, а C++ стремится доминировать в нише высокоуровневых языков. Возможно пришел момент полного развода? Но это нарушит обратную совместимость.
Основной фокус с Rust, который недоступен в Python состоит в том, что Cargo это дефолт. А poetry/uv/rye это очередной 15й стандарт из того знаменитого комикса.
Все эти, без сомнения, значимые проекты сработают в момент, когда pip и virtualenv будут признаны устаревшими и удалены из всевозможных поставок.
Как-то мне глобальный gitignore очень не здоровая тема. Gitignore должен быть одинаков у всех участников балагана работы иначе могут возникать очень странные коллизии при совместной работе.
Но 10Tb HDD это больше 25 килорублей! Поэтому экономика тут не такая очевидная. Да и дисковая полка и контроллер тоже стоит денег.
Там не дураки сидят и конкуренцию с HDD отслеживают. Сложно сказать с какой точки все это становится целесообразным, но не кажется, что это очень уж большой бюджет.
Помнится Facebook проводили эксперименты с DVD и BD дисками в качестве замены LTO. Интересно чем это у них закончилось. Понятно, что емкость BD-R всего 25G, но надежность значительно выше. А учитывая цены на картриджи LTO, может быть BD-R еще и выигрывает по цене.
Довольно долго пытался найти альтернативу Asana и понял, что ее фактически нет. Никто даже и не пытается сделать. В основном все бросились заменять Jira.
Я не понимаю как это должно работать. В принципе можно вообразить атаку на сервера УЦ с подменой IP на BGP где-нибудь в транзите. В отличии от корневых DNS, маршруты до которых хорошо защищены и чьи сертификаты заранее всем известны, распределение маршрутов и расположение AS не так хорошо контролируется. Да и вообще IP это сеть доверия под контролем ICAN в отличии от строго вертикальной системы DNS.
Можно пытаться распределять сертификаты сверху вниз через механизм похожий на делегирование через NS, но из этой схемы выпадают рекурсеры.
То что хотят сделать Let's Encrypt это скорее проблема защиты канала общения, но не задача подтверждения источника как в https. Т.е. от MITM это не защищает в полной мере.
Это не их концепция. Это пришло из kde. Тогда только подымали голову быстрые ssd и возникла идея хранить всю мету в унифицированной базе. Это давало ту самую интегрированность с точки зрения поиска. Что-то похожее на современный поиск в Винде и МакОси.
Сама по себе идея норм, но уж очень много ресурсов на это уходило. Поллучилось как с Вистой: после быстрых интерфейсов предыдущего поколения получили тормоза на пустом месте.
Хейта было море. И вот сия пучина и поглатила Амарок. Потом, конечно, фреймворки отладили, ssd стали доступными, но аудитория ушла.
Самый яркий для меня пример, когда лучшее враг хорошего. Когда Амарок только появился, на него перешли, казалось, все кто сидел на Линукс. Он был быстр, удобен, функционален и самобытен. А потом они выпустили версию два в какой-то странной попытке сделать толи Foobar, толи iTunes. Плюс они потянули в проект буквально все самые свежие фишки, что нашли вокруг. Монстр глючил, тормозил и раздражал аудиторию, которой не нужен был Фубар. В результате те кто был влюблен в оригинал разбежались по форкам, фанатов Фубара оказалось мало и плеер буквально умер. Несколько лет его вообще никто не разрабатывал. Сейчас там вроде появилась группа разрабов, но никто уже не вернет 2007.
Исследование мягко говоря не полное. Где статьи про thunderbolt, который вытеснит все стандарты? Где USB от Intel на оптическом кабеле? Передача данных через мигание лампочек (забыл как это называлось). Про телефоны от Майкрософт и Яндекс?
Если вспомнить такие статьи, то там скептики не будут выглядеть комично.
Я думаю противопоставление подхода Picodata и микросервисов несколько искусственное. На мой взгляд запрос на быстрое и надежное транзакционное ядро, в которое можно вынести состояние из сотен сервисов на рынке есть. Обратное тоже верно: вносить в grid абсолютно весь код не выглядит правильным. Особенно если этот код работает с внешними миром с высоким latency.
Что можно вынести в Picodata из микросервисов
MQ
кеши
общие ресурсы требующие конкурентного доступа (привет Redis)
менеджмент состоянии, в том числе DAG, Workflow, Inbox и подобные примитивы
Но при этом в микросервисах должно остаться:
Интерконнект со сторонними сервисами
Высоколатентные операции (например генерация документов)
BFF, API Gateway и подобные утилитарные системы.
На сколько я помню Гегель ввел пару тезис-антитезис, как основу формального мышления, а синтез ввели уже после него. Особенно эта триада зашла Марксу и его последователям и стала базовым приемом риторики и логики уже в СССР.
Я не могу себя заставить полюбить go. Основной источник раздражения необходимость механического набора кода, который в других языках просто не нужен. Да, читается это хорошо, но пишется с ненавистью. AI начинает помогать с этим, но эта тема еще развивается.
Не знаю точно, но немного. Можно скомпилировать статическое ядро, выкинув все лишнее и тогда размер в памяти будет измеряться единицами мегабайт. Хотя, конечно, для 486 и 8Mb это мое почтение.
2-3 часа в день это до 37%. Мне эта оценка кажется завышенной. Уж очень много приходится перепроверять. А читать код бывает сложнее, чем писать. Особенно в тривиальных случаях.
Тут кажется яйцо и курица. Тесты пишем с помощью ИИ, код с помощью ИИ с оглядкой на тесты. И кажется, что ИИ может очень хорошо писать код, который формально проходит тесты, но не работает как надо.
Можно тунелировать иностранный протокол внутри отечественного.
Смысл есть, но и проблем много. Tcp и udp довольно старые и при этом не сказать, что идеальные протоколы. Например механика контроля соединения tcp при работе в локалке с большим потоком данных избыточен, но и отсутствие контроля доставки udp может напрягать.
Но почти всегда просто делают что-то поверх udp.
Я понимаю почему совместимость с C нужна была в момент появления C++. Но сейчас это выглядит странно: C очень низкоуровневый язык, а C++ стремится доминировать в нише высокоуровневых языков. Возможно пришел момент полного развода? Но это нарушит обратную совместимость.
Основной фокус с Rust, который недоступен в Python состоит в том, что Cargo это дефолт. А poetry/uv/rye это очередной 15й стандарт из того знаменитого комикса.
Все эти, без сомнения, значимые проекты сработают в момент, когда pip и virtualenv будут признаны устаревшими и удалены из всевозможных поставок.
Как-то мне глобальный gitignore очень не здоровая тема. Gitignore должен быть одинаков у всех участников
балаганаработы иначе могут возникать очень странные коллизии при совместной работе.Но 10Tb HDD это больше 25 килорублей! Поэтому экономика тут не такая очевидная. Да и дисковая полка и контроллер тоже стоит денег.
Там не дураки сидят и конкуренцию с HDD отслеживают. Сложно сказать с какой точки все это становится целесообразным, но не кажется, что это очень уж большой бюджет.
Помнится Facebook проводили эксперименты с DVD и BD дисками в качестве замены LTO. Интересно чем это у них закончилось. Понятно, что емкость BD-R всего 25G, но надежность значительно выше. А учитывая цены на картриджи LTO, может быть BD-R еще и выигрывает по цене.
Это аналог Jira, а не Asana. Все же это очень разные подходы.
Из этого всего только Лидер Таск хоть как-то соответствует. Все остальное скорее доски.
Довольно долго пытался найти альтернативу Asana и понял, что ее фактически нет. Никто даже и не пытается сделать. В основном все бросились заменять Jira.
На самом деле во многих русскоязычных чатах и сейчас также. Например в больших пабликах на Твиче банят за такое.
Я не понимаю как это должно работать. В принципе можно вообразить атаку на сервера УЦ с подменой IP на BGP где-нибудь в транзите. В отличии от корневых DNS, маршруты до которых хорошо защищены и чьи сертификаты заранее всем известны, распределение маршрутов и расположение AS не так хорошо контролируется. Да и вообще IP это сеть доверия под контролем ICAN в отличии от строго вертикальной системы DNS.
Можно пытаться распределять сертификаты сверху вниз через механизм похожий на делегирование через NS, но из этой схемы выпадают рекурсеры.
То что хотят сделать Let's Encrypt это скорее проблема защиты канала общения, но не задача подтверждения источника как в https. Т.е. от MITM это не защищает в полной мере.