Обновить
21
Артём Мельников@APXEOLOG

Пользователь

4
Подписчики
Отправить сообщение

И куда делась вся принципиальность?

А она была? Я думал она исчезла в тот момент, когда телегу сначала блокировали в РФ, а потом резко перестали, и всякие гос чиновники резко вернулись в нее обратно.

Я уверен, что "домашний реактор" всегда будет проигрывать по стоимости энергии нормальным стационарным решениям, об этом я и написал в посте выше. Поэтому никаких предпосылок для адаптации "бытовых реакторов" не видно - дешевле просто покупать энергию у сетей, которые построят "большой" и выбросят в электросеть.

Ну, конечно, кроме случаев, когда экономически выгоднее свой личный источник (удаленная география), но тут уж я даже не знаю, дешевле наверное будет газовый баллон возить или камаз дров, чем ядерную батарейку

Прослеживается четкая тенденция к децентрализации экономики

Что это вообще значит? Можете привести какие-то примеры?

Тенденции к деглобализации я вижу, но они никаким боком не относятся к "ядерному реактору в каждый дом".

Наоборот, есть вполне четкие соотношения между свойствами устройств генерации. Эффективность, компактность, безопасность, долговечность, и т.д. - нельзя сделать все сразу, что-то будет страдать. Если получится сделать 10-летнюю безопасную ядерную батарейку, значит сздоровый стационарный реактор за городом будет в 100 раз мощнее и энергия с него будет в 10 раз дешевле.

Ее и производят в том числе и атомными реакторами, только для этого не нужно тащить "реактор в каждый дом". Есть много проблем, которые можно и нужно решать, но "компактные бытовые ядерные батарейки для массвого использования" - не одна из них.

Очень сомневаюсь что это будет в таком виде. Раздавать радиоактивные элементы направо и налево - самый быстрый шаг к катастрофе. Какой-нибудь дурак кинет по приколу подобную штуку в костер посреди города, и что дальше будет?

Прогресс идет в направлении электроэнергии, как основного и единственноого топлива. И этому есть хорошая причина - это прекрасно ложится на существущую инфраструктуру, позволяя при этом обеспесчивать контроль и безопасность

Ответ генерируется на основе входа и рандома. Фильтры не идеальны и обходятся промптами. Просто поменяв пару знаков препинания можно получить совершенно другой результат. Поэтому возможно это "сигнал", а возможно просто так рандом лег на промпт. Делать новость на основе одного скрина с реддита это кринж.

Вы посмотрели пример того, как высосать статью из пальца

Я думаю тут, как и везде, нужно считать. Нужно понимать как именно строить арихтектуру и какие сервисы нужно использовать, чтобы было дешево. Для некоторых типов задач решение может быть крайне не очевидным.

Для сравнения, у моей команды суммарная стоимость на несколько продуктов (prod + dev каждый) выходит около $4k в месяц. У нас не дикий RPS, но сотня тысяч уникальных пользователей в месяц есть. Сравнимо с зарплатой, которую пришлось бы тратить на девопса, чтобы это поддерживать (уж не говоря про то сколько стоило бы само железо).

По моему мнению, serverless выходит дороже только в двух случаях:

  1. Ваш проект настолько маленький, что умещается на одном VPS. Тогда можно просто купить инстанс (или хостить контейнер в Fargate) и это будет дешевле.

  2. Ваш проект настолько большой/высоко нагруженный, что свое железо действительно получается дешевле даже с учетом всех накладных расходов. Но мне кажется, что это прям уровни всяких авито/озонов/и т.д.

Концептуально так и есть, с некоторыми оговорками (не всегда с нуля/умирает)

Да никакого веселья нету. Подходы те же самые, что и в монолите.

Serverless подход (лямбды в облаках) сочетает удобство монолита с масштабируемостью микросервисов (во всяком случае под нагрузки 99% среднестатистических приложений). Видимо люди не доверяют облакам (хотя можно и без вендорлока делать)

Изначально GQL был создан, чтобы минимизировать время рендера веб/мобильных страниц. Подавляющее большинство более-менее сложных и взрослых приложений может делать десятки REST запросов при открытии страницы. Причем часто часть запросов могут выполняться последовательно, ещё больше увеличивая время ожидания. Очевидное решение - просить все данные разом. Реализация подобного подхода через REST потребует делать по эндпоинту на каждый чих и дичайших накладных расходов на поддержку. Поэтому пришли к концепции "пусть сами просят, что им нужно"

Удобно для работы с paginated response

Я думаю тут все очень просто. Какие-нибудь мнительные политики внезапно обнаружили, что в ОС, которую используют по всему миру в том числе и в критической инфраструктуре принимают код от каких-то "русских хакеров", которые наверняка конечно же туда встраивают бекдоры.

Сложно ли представить похожую ситуацию в России? Как какой-нибудь росийский депутат внезапно обнаруживает коммиты от украинцев в скрепно-значимом отечественном программном продукте и что за этим последует. Мне очень легко представить. Дураков везде хватает.

Не понимаю к чему вы привели этот пример. Код остался открытым. Доступа никого не лишили.

Еще раз - мейнтейнеры сами решают какие изменения им принимать от сообщества, а какие нет. Те, кого это не устраивает всегда вольны сделать форк и пилить свою версию дальше. Так и работает опен сурс.

А в чем тут противоречие опенсурсу? Код как был открытый, так и есть. Бери и форкай.

Опенсурс это вовсе не значит, что мейнтейнер обязан принимать вклад любых участников и мержить все ПРы. Получается, что десятком человек, от которых принимали стало меньше.

К самому решению конечно вопросы есть, и как новость для хайпа смотрится красиво. Но в реальности, как по мне, никакого эффекта по сути нет. Выглядит как политический ход.

Интересно было бы узнать какому % людей вообще ващен startup time браузера. Мой выключается только при перезагрузке ОС.

Зачем в таком случае вообще группы? Просто сделайте несколько окон фаерфокса на разных мониторах.

Группы удобны именно тогда, когда хочется работать с одним окном.

Пробовал как замену хромовы группам, но это не то. Совершенно неудобно табаться между несколькими окнами

Информация

В рейтинге
Не участвует
Откуда
Россия
Дата рождения
Зарегистрирован
Активность