Не думаю, что одни и те же инструменты - вкладка с Figm'ой, IDE или docker - как-то сильно по-разному расходуют память, в зависимости от ОС. Как пример: сейчас на MacOS у меня запущена Android Studio с парой открытых проектов и Activity Monitor показывает, что она "съела" 8Гб RAM. На Windows плюс-минус было бы то же самое, если бы я открыл те же самые проекты.
Один из важных недостатков такого способа - быстродействие и стоимость за него. 4 ГБ, упомянутых в статье, сегодня не хватит даже для адекватной работы в браузере (но даже такая машина стоит 1 тыс руб в месяц). А если вам нужно собирать проекты, разворачивать контейнеры или что-то еще такое, то нужно хотя бы 32Гб оперативы, что у упомянутого хостера стоит от 8 000 рублей в месяц. Процессорные ядра у виртуальных машин тоже вещь достаточно эфемерная. Выделить-то вам их выделят, а вот сколько еще виртуальных машин используют тот же физический CPU вам никто не скажет.
Статья о новой версии официального клиента. Ссылка на официальный клиент, в Google Play. Но вы его в своем предыдущем комментарии противопоставляете "этому" клиенту. Вот я и спросил что вы подразумеваете под "этим".
Это если вам субъективно нравится просыпаться с восходом солнца) я во всех квартирах, где жил больше пары месяцев, покупал блэкаут шторы, либо жалюзи. Сейчас живу в квартире с рольставнями и это кайф. Спишь в полной темноте, пока сам не решишь, что наступило утро. И вот тогда уже открываешь окна (включаешь свет)
в TOR многослойность, а я говорю о (де)мультиплексировании потоков. Упрощенно - каждый четный байт полезной нагрузки ТСР отправляется на порт 8443, а каждый нечетный на 8444. Приложение на стороне сервера слушает оба порта, и получая данные, собирает исходную последовательность. Немного погуглив, понял, что подобная идея лежит в основе Multipath TCP (MPTCP)
Чисто брейншторма ради: а нельзя ли чисто технически сделать TCP-over-many-TCP? Т.е. к примеру между хостом и сервером устанавливается не 1, а сразу несколько TCP соединений, на разных портах. Через каждое из которых передается только некоторая часть полезной нагрузки. Соответственно на обоих концах эти данные разбиваются по сессиям и собираются заново, по некоторому псевдослучайному алгоритму. Тогда для внешнего наблюдателя это будет выглядеть как несколько сессий с неизвестынми сигнатурами.
Интересно было бы попробовать на практике. Любой, кто ездил на двухколесной технике, на уровне рефлексов использует микруподруливания и контрруление, а здесь получается, что это скорее будет мешать.
Там нужно найти максимально длинную строку в содержимом файла, а не просто самую длинную возможную запись.
Очень gooрошо
Это только замедлит "акклиматизацию". Либо придется постоянно чехол снимать/надевать.
Не думаю, что одни и те же инструменты - вкладка с Figm'ой, IDE или docker - как-то сильно по-разному расходуют память, в зависимости от ОС. Как пример: сейчас на MacOS у меня запущена Android Studio с парой открытых проектов и Activity Monitor показывает, что она "съела" 8Гб RAM. На Windows плюс-минус было бы то же самое, если бы я открыл те же самые проекты.
Один из важных недостатков такого способа - быстродействие и стоимость за него. 4 ГБ, упомянутых в статье, сегодня не хватит даже для адекватной работы в браузере (но даже такая машина стоит 1 тыс руб в месяц). А если вам нужно собирать проекты, разворачивать контейнеры или что-то еще такое, то нужно хотя бы 32Гб оперативы, что у упомянутого хостера стоит от 8 000 рублей в месяц.
Процессорные ядра у виртуальных машин тоже вещь достаточно эфемерная. Выделить-то вам их выделят, а вот сколько еще виртуальных машин используют тот же физический CPU вам никто не скажет.
Клиент смотрит также на ключ сервера, прокси не решит эту проблему.
Коренные алкаши в 7-м поколении?
"Существеннее" это сравнительная степень
А в чем жульничество? И как, по вашему, должно быть?
plot twist: развод организован родствениками, которым автор и скинул бабло "на хранение" /irony
Забавно, что выдача Яндекса в картинках гораздо жестче, чем выдача гугла по тому же самому запросу
RDP-over-Telemost...
Статья о новой версии официального клиента. Ссылка на официальный клиент, в Google Play. Но вы его в своем предыдущем комментарии противопоставляете "этому" клиенту. Вот я и спросил что вы подразумеваете под "этим".
"Этот" это какой?
Это если вам субъективно нравится просыпаться с восходом солнца) я во всех квартирах, где жил больше пары месяцев, покупал блэкаут шторы, либо жалюзи. Сейчас живу в квартире с рольставнями и это кайф. Спишь в полной темноте, пока сам не решишь, что наступило утро. И вот тогда уже открываешь окна (включаешь свет)
Я тут подожду
в TOR многослойность, а я говорю о (де)мультиплексировании потоков. Упрощенно - каждый четный байт полезной нагрузки ТСР отправляется на порт 8443, а каждый нечетный на 8444. Приложение на стороне сервера слушает оба порта, и получая данные, собирает исходную последовательность. Немного погуглив, понял, что подобная идея лежит в основе Multipath TCP (MPTCP)
Чисто брейншторма ради: а нельзя ли чисто технически сделать TCP-over-many-TCP? Т.е. к примеру между хостом и сервером устанавливается не 1, а сразу несколько TCP соединений, на разных портах. Через каждое из которых передается только некоторая часть полезной нагрузки. Соответственно на обоих концах эти данные разбиваются по сессиям и собираются заново, по некоторому псевдослучайному алгоритму. Тогда для внешнего наблюдателя это будет выглядеть как несколько сессий с неизвестынми сигнатурами.
Дать доступ к карте LLM это идиотизм, согласен. Но дать токен типа "вот тебе 15 баксов, купи мне бумажную Войну и мир", - почему нет?
Интересно было бы попробовать на практике. Любой, кто ездил на двухколесной технике, на уровне рефлексов использует микруподруливания и контрруление, а здесь получается, что это скорее будет мешать.